01.06.2014 Views

Типовые требования к управлению электронными ... - DLM Forum

Типовые требования к управлению электронными ... - DLM Forum

Типовые требования к управлению электронными ... - DLM Forum

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

ТИПОВЫЕ ТРЕБОВАНИЯ<br />

К УПРАВЛЕНИЮ ЭЛЕКТРОННЫМИ ДОКУМЕНТАМИ<br />

ИСПРАВЛЕННОЕ И ДОПОЛНЕННОЕ ИЗДАНИЕ, 2008<br />

Специфи<strong>к</strong>ации MoReq2<br />

Данные специфи<strong>к</strong>ации<br />

были подготовлены<br />

для Европейс<strong>к</strong>ой Комиссии<br />

<strong>к</strong>омпанией Serco Consulting,<br />

работа финансировалась<br />

по программе IDABC


ТИПОВЫЕ ТРЕБОВАНИЯ<br />

К УПРАВЛЕНИЮ ЭЛЕКТРОННЫМИ ДОКУМЕНТАМИ<br />

ИСПРАВЛЕННОЕ И ДОПОЛНЕННОЕ ИЗДАНИЕ, 2008<br />

Специфи<strong>к</strong>ации MoReq2<br />

Данный до<strong>к</strong>умент доступен в эле<strong>к</strong>тронной форме по интернет-адресам:<br />

http://dlm-network.org/moreq2<br />

http://ec.europa.eu/transparency/archival_policy<br />

а та<strong>к</strong>же на других веб-сайтах. Ожидается, что переводы на другие язы<strong>к</strong>и та<strong>к</strong>же будут<br />

доступны на этих сайтах.<br />

Печатную <strong>к</strong>опию данного до<strong>к</strong>умента можно получить через Управление официальных<br />

публи<strong>к</strong>аций Европейс<strong>к</strong>ого сообщества (the Office for Official Publications of the European<br />

Communities) <strong>к</strong>а<strong>к</strong> Приложение VIII <strong>к</strong> «Информационному бюллетеню по вопросам архивного<br />

дела» (Information Summary on Archives, INSAR).<br />

© CECA-CEE-CEEA, Bruxelles- Luxembourg, 2008<br />

© Перевод на русс<strong>к</strong>ий язы<strong>к</strong>, Н.А.Храмцовс<strong>к</strong>ая, А.В.Храмцовс<strong>к</strong>ий, 2008<br />

Reproduction autorisée, sauf à des fins commerciales, moyennant mention de la source.<br />

Reproduction is authorised, except for commercial purposes, provided the source is<br />

acknowledged.<br />

Допус<strong>к</strong>ается воспроизведение в не<strong>к</strong>оммерчес<strong>к</strong>их целях, при условии наличия ссыл<strong>к</strong>и на<br />

первоисточни<strong>к</strong>.<br />

Предупреждение: Права на данную публи<strong>к</strong>ацию принадлежат Европейс<strong>к</strong>ому Сообществу.<br />

Европейс<strong>к</strong>ая Комиссия не гарантирует точность в<strong>к</strong>люченной в данный отчет информации, и<br />

не несет <strong>к</strong>а<strong>к</strong>ой-либо ответственности за её использование. Европейс<strong>к</strong>ое Сообщество и/или<br />

его учреждения, а та<strong>к</strong>же лица, действующие от их имени, не отвечают за <strong>к</strong>а<strong>к</strong>ие бы то ни<br />

было убыт<strong>к</strong>и и потери, возни<strong>к</strong>шие вследствие использования данной публи<strong>к</strong>ации.


Специфи<strong>к</strong>ации MoReq2<br />

Содержание<br />

ПРЕДИСЛОВИЕ К MOREQ2...................................................................................................1<br />

ПРЕДИСЛОВИЕ ПЕРЕВОДЧИКОВ........................................................................................3<br />

1. ВВЕДЕНИЕ ...................................................................................................................10<br />

1.1 История разработ<strong>к</strong>и....................................................................................10<br />

1.2 Взаимосвязь между MoReq и MoReq2......................................................10<br />

1.3 Назначение и область применения специфи<strong>к</strong>аций .................................11<br />

1.4 Что та<strong>к</strong>ое СЭД?...........................................................................................12<br />

1.5 Ка<strong>к</strong> можно использовать специфи<strong>к</strong>ации MoReq2? ..................................13<br />

1.6 Права интелле<strong>к</strong>туальной собственности..................................................14<br />

1.7 Принципы разработ<strong>к</strong>и требований и ограничения на <strong>к</strong>руг<br />

рассматриваемых вопросов ......................................................................14<br />

1.8 Учёт особенностей отдельных стран-членов Евросоюза .......................15<br />

1.9 Использование специфи<strong>к</strong>аций MoReq2....................................................16<br />

1.10 Стру<strong>к</strong>тура специфи<strong>к</strong>аций MoReq2 ............................................................17<br />

1.11 Тестирование на соответствие <strong>требования</strong>м MoReq2 ............................18<br />

1.12 Обязательные и желательные <strong>требования</strong>..............................................19<br />

1.13 Замечания и предложения.........................................................................19<br />

2. ОБЗОР ТРЕБОВАНИЙ К СЭД.....................................................................................20<br />

2.1 Основные термины.....................................................................................20<br />

2.2 Основные понятия ......................................................................................24<br />

2.3 Модель взаимосвязей между объе<strong>к</strong>тами СЭД.........................................32<br />

3. КЛАССИФИКАЦИОННАЯ СХЕМА И УПОРЯДОЧИВАНИЕ ДЕЛ ..............................36<br />

3.1 Настрой<strong>к</strong>а <strong>к</strong>лассифи<strong>к</strong>ационной схемы .....................................................37<br />

3.2 Рубри<strong>к</strong>и и дела ...........................................................................................43<br />

3.3 Тома и суб-дела..........................................................................................46<br />

3.4 Ведение <strong>к</strong>лассифи<strong>к</strong>ационной схемы.........................................................50<br />

4. УПРАВЛЕНИЕ ДОСТУПОМ И БЕЗОПАСНОСТЬ ......................................................58<br />

4.1 Управление доступом.................................................................................58<br />

4.2 Контрольная информация (audit trails)......................................................64<br />

4.3 Резервное <strong>к</strong>опирование и восстановление ..............................................68<br />

4.4 Важнейшие до<strong>к</strong>ументы...............................................................................70<br />

5. СРОКИ ХРАНЕНИЯ, УНИЧТОЖЕНИЕ И ПЕРЕДАЧА ДОКУМЕНТОВ .....................73<br />

5.1 Сро<strong>к</strong>и хранения (Retention and Disposition Schedules) ............................73<br />

5.2 Э<strong>к</strong>спертиза ценности и отбор до<strong>к</strong>ументов на постоянное хранение,<br />

передачу и уничтожение ............................................................................83<br />

5.3 Передача, э<strong>к</strong>спорт и уничтожение ............................................................85<br />

6. ВВОД И РЕГИСТРАЦИЯ ДОКУМЕНТОВ ...................................................................92<br />

6.1 Ввод (capture)..............................................................................................93<br />

6.2 Массовый ввод до<strong>к</strong>ументов .....................................................................104<br />

6.3 Управление эле<strong>к</strong>тронной почтой.............................................................107<br />

Версия 1.04<br />

8 сентября 2008 Стр. i


Специфи<strong>к</strong>ации MoReq2<br />

6.4 Типы до<strong>к</strong>ументов ......................................................................................114<br />

6.5 С<strong>к</strong>анирование и управление графичес<strong>к</strong>ими образами (imaging)..........115<br />

7. ИДЕНТИФИКАТОРЫ ОБЪЕКТОВ (REFERENCING) ...............................................121<br />

7.1 Классифи<strong>к</strong>ационные <strong>к</strong>оды .......................................................................124<br />

7.2 Системные идентифи<strong>к</strong>аторы...................................................................127<br />

8. ПОИСК, ИЗВЛЕЧЕНИЕ И ОТОБРАЖЕНИЕ.............................................................129<br />

8.1 Поис<strong>к</strong> и извлечение ..................................................................................129<br />

8.2 Отображение: по<strong>к</strong>аз до<strong>к</strong>ументов на э<strong>к</strong>ране............................................136<br />

8.3 Отображение: вывод на печать...............................................................138<br />

8.4 Отображение: прочее...............................................................................141<br />

9. АДМИНИСТРИРОВАНИЕ..........................................................................................142<br />

9.1 Общие вопросы администрирования......................................................142<br />

9.2 Создание отчетов .....................................................................................143<br />

9.3 Изменение, удаление и цензурирование до<strong>к</strong>ументов ...........................149<br />

10. ОПЦИОНАЛЬНЫЕ МОДУЛИ .....................................................................................155<br />

10.1 Управление физичес<strong>к</strong>ими (неэле<strong>к</strong>тронными) делами и до<strong>к</strong>ументами.156<br />

10.2 Передача и уничтожение физичес<strong>к</strong>их до<strong>к</strong>ументов ................................161<br />

10.3 Управление информационными материалами и<br />

<strong>к</strong>олле<strong>к</strong>тивная работа ................................................................................161<br />

10.4 Управление процессами (workflow).........................................................169<br />

10.5 Работа с досье (casework) .......................................................................175<br />

10.6 Интеграция с системами управления <strong>к</strong>онтентом ...................................181<br />

10.7 Эле<strong>к</strong>тронные подписи ..............................................................................185<br />

10.8 Шифрование .............................................................................................190<br />

10.9 Защита прав интелле<strong>к</strong>туальной собственности на эле<strong>к</strong>тронные<br />

объе<strong>к</strong>ты (Digital Rights Management).......................................................191<br />

10.10 Распределенные системы .......................................................................194<br />

10.11 Автономная и удаленная работа (Offline and Remote Working) ............198<br />

10.12 Интеграция с фа<strong>к</strong>с-системами ................................................................201<br />

10.13 Категории защиты (грифы доступа) ........................................................203<br />

11. НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ ..................................................................211<br />

11.1 Удобство использования .........................................................................212<br />

11.2 Производительность и масштабируемость............................................218<br />

11.3 Доступность и работоспособность системы (system availability) ..........221<br />

11.4 Техничес<strong>к</strong>ие стандарты............................................................................222<br />

11.5 За<strong>к</strong>онодательные и нормативные <strong>требования</strong> ......................................224<br />

11.6 Аутсорсинг и передача обработ<strong>к</strong>и данных поставщи<strong>к</strong>ам услуг............225<br />

11.7 Обеспечение долговременной сохранности и<br />

устаревание технологий...........................................................................228<br />

11.8 Деловые процессы ...................................................................................234<br />

12. ТРЕБОВАНИЯ К МЕТАДАННЫМ..............................................................................239<br />

12.1 Принципы ..................................................................................................239<br />

Версия 1.04<br />

8 сентября 2008 Стр. ii


Специфи<strong>к</strong>ации MoReq2<br />

12.2 Общие <strong>требования</strong> <strong>к</strong> метаданным ..........................................................239<br />

13. ЭТАЛОННАЯ МОДЕЛЬ СЭД .....................................................................................245<br />

13.1 Глоссарий..................................................................................................245<br />

13.2 Модель взаимосвязей между объе<strong>к</strong>тами СЭД.......................................261<br />

13.3 Пояснения <strong>к</strong> модели взаимосвязей между объе<strong>к</strong>тами..........................264<br />

13.4 Модель управления доступом .................................................................266<br />

ПРИЛОЖЕНИЕ 1 - ЛИТЕРАТУРА ......................................................................................271<br />

ПРИЛОЖЕНИЕ 2 - ИСТОРИЯ РАЗРАБОТКИ СПЕЦИФИКАЦИЙ....................................273<br />

ПРИЛОЖЕНИЕ 3 - ИСПОЛЬЗОВАНИЕ СПЕЦИФИКАЦИЙ В ЭЛЕКТРОННОЙ ФОРМЕ276<br />

ПРИЛОЖЕНИЕ 4 - БЛАГОДАРНОСТИ..............................................................................278<br />

ПРИЛОЖЕНИЕ 5 - ВЗАИМОСВЯЗЬ С ДРУГИМИ МОДЕЛЯМИ МЕТАДАННЫХ............282<br />

ПРИЛОЖЕНИЕ 6 - ОБРАБОТКА ДАТ ................................................................................286<br />

ПРИЛОЖЕНИЕ 7 – СТАНДАРТЫ И ДРУГИЕ РУКОВОДСТВА ........................................287<br />

7.1 Стандарты .................................................................................................287<br />

7.2 Другие ру<strong>к</strong>оводства ..................................................................................289<br />

7.3 Ру<strong>к</strong>оводства и ресурсы по обеспечению доступности (accessibility)....290<br />

7.4 Ру<strong>к</strong>оводства по обеспечению долговременной сохранности<br />

эле<strong>к</strong>тронных до<strong>к</strong>ументов и информационных материалов...................291<br />

7.5 Графичес<strong>к</strong>ая модель взаимосвязей MoReq2 с другими<br />

стандартами и ру<strong>к</strong>оводствами.................................................................291<br />

ПРИЛОЖЕНИЕ 8 - ОТЛИЧИЯ ОТ ПРЕДЫДУЩЕЙ ВЕРСИИ ТРЕБОВАНИЙ MOREQ ...299<br />

8.1 Изменения, не являющиеся совместимыми с предыдущей версией .299<br />

8.2 Связи между разделами ..........................................................................299<br />

ПРИЛОЖЕНИЕ 9 – МОДЕЛЬ МЕТАДАННЫХ ..................................Публи<strong>к</strong>уется отдельно<br />

Версия 1.04<br />

8 сентября 2008 Стр. iii


Специфи<strong>к</strong>ации MoReq2<br />

ПРЕДИСЛОВИЕ К MOREQ2<br />

Исправленное и дополненное издание<br />

Типовых требований <strong>к</strong> <strong>управлению</strong> эле<strong>к</strong>тронными до<strong>к</strong>ументами<br />

С момента первой публи<strong>к</strong>ации в 2001 году, первоначальные специфи<strong>к</strong>ации MoReq –<br />

«<strong>Типовые</strong> <strong>требования</strong> у <strong>управлению</strong> эле<strong>к</strong>тронными до<strong>к</strong>ументами» (Model Requirements for<br />

the management of electronic records) – широ<strong>к</strong>о использовались <strong>к</strong>а<strong>к</strong> в Европе, та<strong>к</strong> и за её<br />

пределами. Потенциальные пользователи систем эле<strong>к</strong>тронного до<strong>к</strong>ументооборота из стран<br />

Евросоюза оценили удобство использования типовых требований типа MoReq в <strong>к</strong>ачестве<br />

основы при проведении за<strong>к</strong>упо<strong>к</strong> систем эле<strong>к</strong>тронного до<strong>к</strong>ументооборота (СЭД) 1 , а<br />

поставщи<strong>к</strong>и программного обеспечения стали ориентироваться на MoReq в процессе<br />

разработ<strong>к</strong>и своих проду<strong>к</strong>тов.<br />

MoReq рассматривается в настоящее время <strong>к</strong>а<strong>к</strong> несомненно удачный до<strong>к</strong>умент, <strong>к</strong>оторый<br />

много<strong>к</strong>ратно цитировался на многих <strong>к</strong>онтинентах, и <strong>к</strong>оторый сейчас играет центральную<br />

роль в сфере управления эле<strong>к</strong>тронными до<strong>к</strong>ументами.<br />

Одна<strong>к</strong>о с 2001 года информационные технологии заметно изменились. Рост и<br />

эволюционные изменения наблюдались во многих технологичес<strong>к</strong>их областях,<br />

непосредственно влияющих на процессы создания, ввода и управления эле<strong>к</strong>тронными<br />

до<strong>к</strong>ументами. В MoReq2 – новой версии специфи<strong>к</strong>аций MoReq – учтены последствия этих<br />

технологичес<strong>к</strong>их изменений, а та<strong>к</strong>же новые стандарты и своды хорошей пра<strong>к</strong>ти<strong>к</strong>и, <strong>к</strong>оторые<br />

были разработаны за последние нес<strong>к</strong>оль<strong>к</strong>о лет. Соответственно, специфи<strong>к</strong>ации MoReq2<br />

представляют собой эволюционное развитие первоначальных специфи<strong>к</strong>аций MoReq.<br />

В MoReq2 впервые предусматривается возможность проведения тестирования<br />

программного обеспечения, и специфи<strong>к</strong>ации специально написаны та<strong>к</strong>им образом, чтобы<br />

поддерживать проведение независимого тестирования на соответствие <strong>требования</strong>м.<br />

Одновременно с собственно типовыми <strong>требования</strong>ми был разработан и опубли<strong>к</strong>ован набор<br />

соответствующих тестов. Потребность в точно сформулированных, проверяемых<br />

<strong>требования</strong>х повле<strong>к</strong>ла за собой многочисленные <strong>к</strong>орре<strong>к</strong>тиров<strong>к</strong>и содержания и стиля<br />

специфи<strong>к</strong>аций.<br />

На<strong>к</strong>онец, многолетний опыт использования MoReq по<strong>к</strong>азал необходимость национальных<br />

вариаций, позволяющих учесть язы<strong>к</strong>овую, за<strong>к</strong>онодательную и нормативную специфи<strong>к</strong>у и<br />

национальные традиции делопроизводства и до<strong>к</strong>ументооборота. В этой связи впервые<br />

вводится модерируемый механизм 2 – в виде т.н. «нулевой главы» - позволяющий странамчленам<br />

Евросоюза добавлять в MoReq2 свои специфичес<strong>к</strong>ие национальные <strong>требования</strong>.<br />

MoReq2 был разработан <strong>к</strong>омпанией Serco Consulting для Европейс<strong>к</strong>ой Комиссии<br />

(правительства Евросоюза). Финансирование осуществлялось в рам<strong>к</strong>ах осуществляемой<br />

Евросоюзом программы «эле<strong>к</strong>тронного правительства» IDABC 3 . Ход процесса разработ<strong>к</strong>и<br />

1<br />

2<br />

3<br />

Electronic Records Management Systems, ERMS (прим. переводчи<strong>к</strong>а)<br />

Согласно п.1.6, Евро<strong>к</strong>омиссия оставляет за собой право одобрять «нулевые главы». На<br />

пра<strong>к</strong>ти<strong>к</strong>е <strong>к</strong>онтролировать содержание «нулевых глав» будут, с<strong>к</strong>орее всего, э<strong>к</strong>сперты <strong>DLM</strong>форума<br />

(прим. переводчи<strong>к</strong>а)<br />

«О<strong>к</strong>азание (посредством обеспечения совместимости систем) услуг европейс<strong>к</strong>ого<br />

эле<strong>к</strong>тронного правительства государственным органам, <strong>к</strong>оммерчес<strong>к</strong>им организациям и<br />

гражданам» (Interoperable Delivery of European e-Government Services to Public Administrations,<br />

Businesses and Citizens, IDABC) (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 1


Специфи<strong>к</strong>ации MoReq2<br />

<strong>к</strong>онтролировался Евро<strong>к</strong>омиссией в тесном сотрудничестве с <strong>DLM</strong>-форумом. Э<strong>к</strong>сперты <strong>DLM</strong>форума<br />

проводили рецензирование прое<strong>к</strong>та специфи<strong>к</strong>аций на всех <strong>к</strong>лючевых стадиях<br />

разработ<strong>к</strong>и. Эти рецензии дополнили предложения и замечания, представленные<br />

многочисленными пользователями, <strong>к</strong>онсультантами, поставщи<strong>к</strong>ами, представителями нау<strong>к</strong>и<br />

и профессиональных организаций 4 . В результате MoReq2 становится уни<strong>к</strong>альным по<br />

авторитетности до<strong>к</strong>ументом, <strong>к</strong>оторый будет весьма полезен для всех, <strong>к</strong>то вовлечен в<br />

управление эле<strong>к</strong>тронными до<strong>к</strong>ументами <strong>к</strong>а<strong>к</strong> в Европе, та<strong>к</strong> и во всем мире.<br />

4<br />

В рецензировании MoReq2 приняли участие и российс<strong>к</strong>ие специалисты, см. списо<strong>к</strong><br />

рецензентов в Приложении 4 (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 2


Специфи<strong>к</strong>ации MoReq2<br />

ПРЕДИСЛОВИЕ ПЕРЕВОДЧИКОВ<br />

В отличие от ряда других известных требований <strong>к</strong> системам эле<strong>к</strong>тронного<br />

до<strong>к</strong>ументооборота, MoReq2 – высо<strong>к</strong>оуровневый до<strong>к</strong>умент, в <strong>к</strong>отором большое внимание<br />

уделено принципиальным вопросам управления эле<strong>к</strong>тронными до<strong>к</strong>ументами, архите<strong>к</strong>туре<br />

СЭД и т.д.<br />

С<strong>к</strong>азывается та<strong>к</strong>же и то, что в разработ<strong>к</strong>е данных Специфи<strong>к</strong>аций принимали участие<br />

специалисты многих стран Европы и мира, и MoReq2 впитал опыт нес<strong>к</strong>оль<strong>к</strong>их различных<br />

систем управления до<strong>к</strong>ументами. Во многом именно поэтому, <strong>к</strong>а<strong>к</strong> нам <strong>к</strong>ажется, MoReq2<br />

будет гораздо ближе и понятней отечественному читателю, чем, например, амери<strong>к</strong>анс<strong>к</strong>ий<br />

стандарт DoD 5015.2-STD 5 .<br />

О том, <strong>к</strong>а<strong>к</strong> можно использовать MoReq2, хорошо с<strong>к</strong>азано в разделе 1.5. К этому хотелось бы<br />

добавить, что использовать Специфи<strong>к</strong>ации следует <strong>к</strong>ритичес<strong>к</strong>и – хотя в целом уровень<br />

до<strong>к</strong>умента очень высо<strong>к</strong>, все же и в нем есть разделы, <strong>к</strong>оторые можно было бы улучшить на<br />

основе отечественного опыта. Это, например, раздел 10.13 «Категории защиты (грифы<br />

доступа)», где, по сути, речь идет об организации работы с <strong>к</strong>онфиденциальными и<br />

се<strong>к</strong>ретными до<strong>к</strong>ументами.<br />

Хочется отметить, что в публичном обсуждении прое<strong>к</strong>тов MoReq2 приняли участие и<br />

российс<strong>к</strong>ие специалисты. В группе э<strong>к</strong>спертов от профессиональных организаций и<br />

объединений Россию представляли члены Гильдии Управляющих До<strong>к</strong>ументацией<br />

(С.И.Афанасьев, С.Б.Ма<strong>к</strong>аров, В.И.Тихонов, С.Л.Кузнецов), а в группе пользователей -<br />

специалисты <strong>к</strong>омпании «Эле<strong>к</strong>тронные Офисные Системы» (Н.А.Храмцовс<strong>к</strong>ая.<br />

А.В.Храмцовс<strong>к</strong>ий).<br />

Ка<strong>к</strong> читать MoReq2<br />

Специфи<strong>к</strong>ации MoReq2 опираются на терминологию стандарта ISO 15489, поэтому<br />

читателям ре<strong>к</strong>омендуется предварительно позна<strong>к</strong>омиться либо с этим стандартом, либо с<br />

его официальным переводом на русс<strong>к</strong>ий язы<strong>к</strong> – стандартом ГОСТ Р ИСО 15489-1-2007.<br />

К сожалению, стру<strong>к</strong>тура MoReq2 не упрощает жизнь тем, <strong>к</strong>то читает специфи<strong>к</strong>ации впервые.<br />

Для начинающих мы ре<strong>к</strong>омендуем следующий порядо<strong>к</strong> чтения:<br />

<br />

<br />

<br />

<br />

Глава 1 «Введение»;<br />

Раздел 2.1 «Основные термины»;<br />

Раздел 2.2 «Основные понятия» - вместе с разделом 13.3 (это единственное место в<br />

специфи<strong>к</strong>ациях, где <strong>к</strong>рат<strong>к</strong>о и чет<strong>к</strong>о описаны взаимосвязи рубри<strong>к</strong>, дел, суб-дел, томов и<br />

до<strong>к</strong>ументов);<br />

Раздел 13.1 «Глоссарий»;<br />

5<br />

Стандарт Министерства обороны США DoD 5015.2-STD "Требования <strong>к</strong> программным<br />

средствам эле<strong>к</strong>тронного до<strong>к</strong>ументооборота" (Design Criteria Standard For Electronic Records<br />

Management Software Applications), http://jitc.fhu.disa.mil/recmgt/standards.html (прим.<br />

переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 3


Специфи<strong>к</strong>ации MoReq2<br />

<br />

Введения в главы 3-7, 10; введения в разделы 10.1, 10.3-10.9, 10.13, 11.7. В этих<br />

введениях можно найти полезную информацию по <strong>к</strong>онцептуальным вопросам,<br />

отсутствующую в главе 2;<br />

После этого можно переходить <strong>к</strong> чтению основного материала – глав 3 -12 .<br />

В случае возни<strong>к</strong>новения сомнений в точности перевода, мы ре<strong>к</strong>омендуем обращаться <strong>к</strong><br />

оригинальному те<strong>к</strong>сту MoReq2 на английс<strong>к</strong>ом язы<strong>к</strong>е. В ряде случаев смысл требований<br />

помогают понять материалы для тестирования (особенно тогда, <strong>к</strong>огда в них пошагово<br />

описаны действия, выполняемые при провер<strong>к</strong>е СЭД на соответствие <strong>к</strong>он<strong>к</strong>ретному<br />

требованию).<br />

Следует иметь в виду, что разработчи<strong>к</strong>и MoReq2 приняли решение о возможности выпус<strong>к</strong>а<br />

с<strong>к</strong>орре<strong>к</strong>тированных версий Специфи<strong>к</strong>аций. На момент написания, опубли<strong>к</strong>овано уже четыре<br />

та<strong>к</strong>ие версии (1.01, 1.02, 1.03 и 1.04), в <strong>к</strong>оторых исправлен ряд ошибо<strong>к</strong>.<br />

Концептуальные вопросы и терминология<br />

Понятие «<strong>к</strong>лючевые слова»<br />

Понятие «<strong>к</strong>лючевое слово» (keyword, key term) можно встретить в целом ряде требований<br />

MoReq2 (3.4.28-29, 6.1.23-26, 6.1.28, 8.1.14-15, 8.1.18, 8.1.20, 8.3.13, 11.1.6, 11.1.32, 11.8.8,<br />

11.8.11), – при этом нигде (<strong>к</strong>роме очень туманного определения в Глоссарии) не<br />

объясняется, зачем эти <strong>к</strong>лючевые слова нужны, и почему этот вид метаданных обязательно<br />

должен поддерживаться СЭД. Получается, что это не<strong>к</strong>ая вспомогательная фун<strong>к</strong>циональная<br />

возможность, <strong>к</strong> <strong>к</strong>оторой, одна<strong>к</strong>о, предъявляются очень строгие <strong>требования</strong>.<br />

Разгад<strong>к</strong>а здесь лежит в предыстории создания MoReq2. В ранних реда<strong>к</strong>циях прое<strong>к</strong>та<br />

специфи<strong>к</strong>аций MoReq2 допус<strong>к</strong>алось использование неиерархичес<strong>к</strong>их <strong>к</strong>лассифи<strong>к</strong>ационных<br />

схем, в <strong>к</strong>оторых взаимосвязь объе<strong>к</strong>тов устанавливалась через присвоенные делам наборы<br />

<strong>к</strong>лючевых слов. Ниже приводится фрагмент из те<strong>к</strong>ста первой реда<strong>к</strong>ции прое<strong>к</strong>та MoReq2:<br />

Неиерархичес<strong>к</strong>ий подход связан с у<strong>к</strong>азанием <strong>к</strong>лючевых слов (key terms) для<br />

отдельных дел. Обычно для <strong>к</strong>аждого дела у<strong>к</strong>азываются три <strong>к</strong>лючевых слова, <strong>к</strong>аждое<br />

из <strong>к</strong>оторых выбирается из отдельного <strong>к</strong>онтролируемого словаря; и, <strong>к</strong>а<strong>к</strong> правило, у<br />

<strong>к</strong>аждого дела имеются отдельные элементы метаданных для <strong>к</strong>аждого из трех<br />

<strong>к</strong>лючевых слов. Можно использовать (хотя и нес<strong>к</strong>оль<strong>к</strong>о ис<strong>к</strong>усственно) понятие<br />

«рубри<strong>к</strong>и», рассматривая <strong>к</strong>а<strong>к</strong> рубри<strong>к</strong>у <strong>к</strong>аждое значение <strong>к</strong>аждого из этих элементов<br />

метаданных. В данном случае, одна<strong>к</strong>о, рубри<strong>к</strong>и не являются ре<strong>к</strong>урсивными.<br />

Ключевые слова были основным «строительным материалом» неиерархичес<strong>к</strong>их схем, и<br />

отсюда логичес<strong>к</strong>и выте<strong>к</strong>али <strong>требования</strong>, ограничивающие возможность их изменения,<br />

<strong>требования</strong> по использованию <strong>к</strong>онтролируемых словарей и тезаурусов, и т.д.<br />

В о<strong>к</strong>ончательной версии MoReq2 неиерархичесих схем уже нет, а вот большинство<br />

рассчитанных на них требований сохранилось.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 4


Специфи<strong>к</strong>ации MoReq2<br />

Термины «document» и «record»<br />

Особое внимание следует обратить на использование терминов «document»<br />

(информационный материал) и «record» (до<strong>к</strong>умент). Если, например, в ГОСТ Р ИСО 15489-<br />

1-2007 оба термина переводятся <strong>к</strong>а<strong>к</strong> «до<strong>к</strong>умент», и там это не создает ни<strong>к</strong>а<strong>к</strong>их проблем, то в<br />

MoReq2 – это существенно разные понятия.<br />

Есть ряд особенностей использования термина «до<strong>к</strong>умент» в MoReq2, связанных с<br />

необходимостью точно и однозначно формулировать <strong>требования</strong> <strong>к</strong> СЭД<br />

Если в традиционной делопроизводчес<strong>к</strong>ой терминологии англоса<strong>к</strong>сонс<strong>к</strong>их стран<br />

используется принцип «вся<strong>к</strong>ий до<strong>к</strong>умент – это информационный материал, но не вся<strong>к</strong>ий<br />

информационный материал - до<strong>к</strong>умент» (т.е. до<strong>к</strong>ументы рассматриваются <strong>к</strong>а<strong>к</strong><br />

подмножество множества информационных материалов), то в MoReq2, напротив,<br />

использован нестандартный подход, при <strong>к</strong>отором объе<strong>к</strong>т может быть либо информационным<br />

материалом, либо до<strong>к</strong>ументом. В определении понятия «информационный материал» (см.<br />

раздел 2.1 либо 13.1) подчер<strong>к</strong>ивается, что «в MoReq2 термин «информационный материал»<br />

используется для обозначения информации, не получившей статуса до<strong>к</strong>умента»<br />

Далее, <strong>к</strong>а<strong>к</strong> отмечено в подразделе «До<strong>к</strong>умент и эле<strong>к</strong>тронный до<strong>к</strong>умент» раздела 2.2, «в<br />

MoReq2 … термин «до<strong>к</strong>умент» используется для обозначения информационного <strong>к</strong>онтента –<br />

образующих до<strong>к</strong>умент информационных материалов, без метаданных».<br />

Термин «retention and disposition schedule»<br />

Для <strong>к</strong>рат<strong>к</strong>ости данный термин переводится <strong>к</strong>а<strong>к</strong> «сро<strong>к</strong> хранения». В MoReq2 этот термин, <strong>к</strong>а<strong>к</strong><br />

правило, обозначает объе<strong>к</strong>т 6 СЭД, содержащий информацию о правилах отсчета сро<strong>к</strong>а<br />

хранения, и о тех действиях, <strong>к</strong>оторые следует выполнить с до<strong>к</strong>ументами по истечении сро<strong>к</strong>а<br />

хранения.<br />

Объе<strong>к</strong>ты данного типа существуют отдельно от до<strong>к</strong>ументов и наборов до<strong>к</strong>ументов. Сро<strong>к</strong>и<br />

хранения назначаются путем установления связи между до<strong>к</strong>ументом или набором<br />

до<strong>к</strong>ументов, и одним или нес<strong>к</strong>оль<strong>к</strong>ими объе<strong>к</strong>тами «сро<strong>к</strong> хранения». Пос<strong>к</strong>оль<strong>к</strong>у на один и тот<br />

же объе<strong>к</strong>т «сро<strong>к</strong> хранения» могут ссылаться нес<strong>к</strong>оль<strong>к</strong>о до<strong>к</strong>ументов и наборов до<strong>к</strong>ументов,<br />

то модифи<strong>к</strong>ация объе<strong>к</strong>та повлияет сразу на все эти до<strong>к</strong>ументы и наборы до<strong>к</strong>ументов. Ка<strong>к</strong><br />

отмечено в примечании <strong>к</strong> п.5.1.7, это опасная возможность, <strong>к</strong>оторой следует пользоваться с<br />

осторожностью.<br />

В тех случаях, <strong>к</strong>огда данный термин используется в своем обычном «делопроизводчес<strong>к</strong>ом»<br />

значении, он может, в зависимости от <strong>к</strong>онте<strong>к</strong>ста, обозначать <strong>к</strong>а<strong>к</strong> сово<strong>к</strong>упность у<strong>к</strong>азаний по<br />

сро<strong>к</strong>ам хранения и действиям по истечении этих сро<strong>к</strong>ов (что является аналогом<br />

отечественных перечней с у<strong>к</strong>азанием сро<strong>к</strong>ов хранения), та<strong>к</strong> и одно та<strong>к</strong>ое у<strong>к</strong>азание<br />

(соответствует отдельной статье перечня).<br />

Концепция «дело» - «суб-дело» - «том»<br />

На начальной стадии разработ<strong>к</strong>и MoReq2 использовалась простая и понятная <strong>к</strong>онцепция,<br />

за<strong>к</strong>лючавшаяся в том, что:<br />

<br />

Вся<strong>к</strong>ое дело содержит <strong>к</strong>а<strong>к</strong> минимум одно суб-дело;<br />

6<br />

Т.е. не<strong>к</strong>оторая стру<strong>к</strong>тура данных в СЭД (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 5


Специфи<strong>к</strong>ации MoReq2<br />

<br />

<br />

<br />

Вся<strong>к</strong>ое суб-дело содержит <strong>к</strong>а<strong>к</strong> минимум один том;<br />

Суб-дела разбиваются на тома независимо друг от друга;<br />

Там, где существует толь<strong>к</strong>о одно суб-дело или толь<strong>к</strong>о один том, пользователю не нужно<br />

знать об их существовании.<br />

Следы этого подходя и сейчас можно видеть в ряде требований.<br />

Уже по завершении публичного обсуждения, авторы решили сменить эту <strong>к</strong>онцепцию на<br />

более сложную (см. раздел 13.3). На наш взгляд, сделано это было вследствие смешения<br />

идеализированной логичес<strong>к</strong>ой стру<strong>к</strong>туры дел, и того, <strong>к</strong>а<strong>к</strong> эту стру<strong>к</strong>туру видит пользователь.<br />

В итоге те<strong>к</strong>сты требований стали сложнее, но сами <strong>требования</strong> не стали от этого лучше или<br />

понятнее.<br />

Если же взглянуть на этот вопрос шире, то, с нашей точ<strong>к</strong>и зрения, выделение дел, суб-дел и<br />

томов <strong>к</strong>а<strong>к</strong> отдельных видов объе<strong>к</strong>тов является пережит<strong>к</strong>ом «бумажной» эпохи. По своей<br />

сути дела, суб-дела и тома ничем принципиально не отличаются от рубри<strong>к</strong> – и читатель<br />

может видеть, <strong>к</strong>а<strong>к</strong> часто в те<strong>к</strong>сте <strong>требования</strong> формулируются сразу для «рубри<strong>к</strong>, дел, субдел<br />

и томов». С нашей точ<strong>к</strong>и зрения, ограничение внутренней стру<strong>к</strong>туры эле<strong>к</strong>тронных дел<br />

ма<strong>к</strong>симум двумя уровнями (суб-дело и том) ничем не оправдано.<br />

Ка<strong>к</strong> нам <strong>к</strong>ажется, уже сейчас более естественно было бы строить <strong>к</strong>лассифи<strong>к</strong>ационную схему<br />

по тем же принципам, <strong>к</strong>а<strong>к</strong> и дерево папо<strong>к</strong> (дире<strong>к</strong>торий) в операционной системе – из рубри<strong>к</strong>,<br />

<strong>к</strong>оторые могли бы одновременно содержать <strong>к</strong>а<strong>к</strong> подрубри<strong>к</strong>и, та<strong>к</strong> и до<strong>к</strong>ументы. Делом могла<br />

бы быть объявлена любая рубри<strong>к</strong>а (вместе с её подрубри<strong>к</strong>ами). Но это – дело будущего.<br />

Концепция «досье»<br />

Наряду (и в тесной связи) с использованием средств автоматизации процессов (workflow),<br />

одним из быстро развивающихся направлений в управлении до<strong>к</strong>ументами сейчас является<br />

использование разнообразных досье (case files), <strong>к</strong>оторые могут <strong>к</strong>омпле<strong>к</strong>товаться<br />

различными видами до<strong>к</strong>ументов. При этом необходимо решать ряд интересных вопросов,<br />

связанных, например, со сро<strong>к</strong>ами хранения, грифами и т.д.<br />

В MoReq2 использована <strong>к</strong>онцепция досье, разработанная Национальными Архивами<br />

Вели<strong>к</strong>обритании и ориентированная на поддерж<strong>к</strong>у workflow-процессов. В связи с этим<br />

данное в MoReq2 определение досье достаточно сложно для понимания теми, <strong>к</strong>то привы<strong>к</strong><br />

работать, например, с бумажными личными делами.<br />

С нашей точ<strong>к</strong>и зрения, досье, создаваемы в «ручном» режиме, заслуживают не меньшего<br />

внимания – хотя бы потому, что часто именно в них можно найти наиболее ценные<br />

до<strong>к</strong>ументы.<br />

Приведем, для сравнения, определение «досье», <strong>к</strong>оторое предлагалось во время<br />

публичного обсуждения (<strong>к</strong>а<strong>к</strong> синтез определений из ряда авторитетных источни<strong>к</strong>ов):<br />

Досье<br />

Дело, содержащее до<strong>к</strong>ументы и/или информационные материалы, относящиеся <strong>к</strong><br />

<strong>к</strong>он<strong>к</strong>ретному, обычно ограниченному во времени, объе<strong>к</strong>ту, действию или событию,<br />

та<strong>к</strong>ому <strong>к</strong>а<strong>к</strong> отдельный челове<strong>к</strong>, место, прое<strong>к</strong>т или организация.<br />

Замечание: досье иногда называются делами по прое<strong>к</strong>там<br />

Версия 1.04<br />

8 сентября 2008 Стр. 6


Специфи<strong>к</strong>ации MoReq2<br />

Замечание: Примером досье является личное дело – вся содержащаяся в личном<br />

деле информация относится <strong>к</strong> одному лицу, во время его работы в<br />

организации. Другими примерами досье могут служить уголовные дела;<br />

истории болезни; дела по прое<strong>к</strong>там, <strong>к</strong>онтра<strong>к</strong>там или транза<strong>к</strong>циям; опросы и<br />

исследования. Каждое из серии однотипных досье содержит те же или очень<br />

похожие виды до<strong>к</strong>ументов и/или информационных материалов.<br />

Замечание: Досье ограничены во времени. Это означает, что событие или<br />

действие должны произойти до того, <strong>к</strong>а<strong>к</strong> досье будет от<strong>к</strong>рыто или за<strong>к</strong>рыто.<br />

Например, дело по прое<strong>к</strong>ту от<strong>к</strong>рывается толь<strong>к</strong>о после того, <strong>к</strong>а<strong>к</strong> принимается<br />

решение о выполнении прое<strong>к</strong>та, и за<strong>к</strong>рывается по причине о<strong>к</strong>ончания прое<strong>к</strong>та.<br />

Замечание: основными хара<strong>к</strong>терными особенностями досье являются:<br />

<br />

<br />

<br />

То, что они представляют собой набор отдельных до<strong>к</strong>ументов и/или<br />

информационных материалов различных видов;<br />

Во время а<strong>к</strong>тивного использования уничтожение или передача до<strong>к</strong>ументов<br />

и информационных материалов из состава досье осуществляется согласно<br />

правилам ведения деловой деятельности;<br />

С момента о<strong>к</strong>ончательного формирования, досье обычно управляется <strong>к</strong>а<strong>к</strong><br />

единый до<strong>к</strong>умент. Возможно, одна<strong>к</strong>о, что, в соответствии с правилами и<br />

процедурами деловой деятельности, у отдельных до<strong>к</strong>ументов, суб-дел и<br />

томов в составе досье будут свои сро<strong>к</strong>и хранения и правила уничтожения и<br />

передачи по истечении этих сро<strong>к</strong>ов.<br />

Замечание: Суб-дела часто используются для того, чтобы отделить и<br />

сгруппировать различные материалы в составе досье, та<strong>к</strong>ие <strong>к</strong>а<strong>к</strong> интервью,<br />

сообщения в прессе, запросы и отчеты о лабораторных исследованиях,<br />

подтверждающую до<strong>к</strong>ументацию, фотографии, аудио- и видеозаписи, и другие<br />

до<strong>к</strong>ументы<br />

Замечание: В отличие от досье, дела, не являющиеся досье, обычно содержат<br />

до<strong>к</strong>ументы, <strong>к</strong>оторые:<br />

<br />

<br />

<br />

Относятся <strong>к</strong> определенной теме или вопросу,<br />

Поступают из одного и того же источни<strong>к</strong>а,<br />

Относятся <strong>к</strong> одному типу.<br />

Физичес<strong>к</strong>ие до<strong>к</strong>ументы<br />

Используемая в MoReq2 тра<strong>к</strong>тов<strong>к</strong>а понятия «физичес<strong>к</strong>ий до<strong>к</strong>умента» - наверное, наиболее<br />

спорный терминологичес<strong>к</strong>ий элемент Специфи<strong>к</strong>аций. С одной стороны, она опирается на<br />

понятное положение о том, что эле<strong>к</strong>тронный носитель информации (будь то съемный<br />

носитель или целая информационная система), о внутренней стру<strong>к</strong>туре <strong>к</strong>оторого СЭД<br />

ничего не знает, может управляться ею та<strong>к</strong> же, <strong>к</strong>а<strong>к</strong> и бумажное дело.<br />

С другой стороны, использование подобной терминологии может запутать пользователей<br />

Специфи<strong>к</strong>аций. Например, нельзя, взяв в ру<strong>к</strong>и съемный носитель информации, однозначно<br />

с<strong>к</strong>азать, что это – физичес<strong>к</strong>ий до<strong>к</strong>умент или <strong>к</strong>онтейнер с эле<strong>к</strong>тронными до<strong>к</strong>ументами.<br />

Возможны и различные «пограничные» ситуации: в СЭД может быть зарегистрирована по<br />

отдельности толь<strong>к</strong>о часть содержащихся на носителе до<strong>к</strong>ументов; или же СЭД может ничего<br />

не знать о до<strong>к</strong>ументах на носителе, но носитель может быть сформирован та<strong>к</strong>им образом,<br />

Версия 1.04<br />

8 сентября 2008 Стр. 7


Специфи<strong>к</strong>ации MoReq2<br />

что при его под<strong>к</strong>лючении в СЭД будут автоматичес<strong>к</strong>и переданы <strong>к</strong>а<strong>к</strong> до<strong>к</strong>ументы, та<strong>к</strong> и их<br />

метаданные.<br />

С нашей точ<strong>к</strong>и зрения, было бы та<strong>к</strong>же полезно чет<strong>к</strong>о различать управление съемным<br />

носителем <strong>к</strong>а<strong>к</strong> физичес<strong>к</strong>им объе<strong>к</strong>том (отслеживание его местоположения и т.д.), и<br />

управление содержащимися на нем эле<strong>к</strong>тронными до<strong>к</strong>ументами.<br />

Категории защиты<br />

В процессе публичного обсуждения быстро стало ясно, что ни<strong>к</strong>то из авторс<strong>к</strong>ой группы не<br />

имел опыта работы с се<strong>к</strong>ретными до<strong>к</strong>ументами, и из-за этого первоначальные<br />

формулиров<strong>к</strong>и требований содержали немало ошибо<strong>к</strong>. Хотя большая часть ошибо<strong>к</strong> была<br />

устранена, часть все же осталась, - поэтому <strong>требования</strong>м данного раздела следует<br />

использовать с осторожностью.<br />

Следует та<strong>к</strong>же иметь в виду, что механизм <strong>к</strong>атегорий защиты способен решать и другие<br />

задачи, помимо поддерж<strong>к</strong>и грифов се<strong>к</strong>ретности и <strong>к</strong>онфиденциальности. Фа<strong>к</strong>тичес<strong>к</strong>и это ещё<br />

один полезный инструмент для управления доступом <strong>к</strong> до<strong>к</strong>ументам и наборам до<strong>к</strong>ументов. В<br />

<strong>к</strong>ачестве примера, в те<strong>к</strong>сте MoReq2 упоминается, возможность <strong>к</strong>онтролировать та<strong>к</strong>им<br />

образом доступ <strong>к</strong> бухгалтерс<strong>к</strong>им до<strong>к</strong>ументам.<br />

Другие вопросы терминологии<br />

В большинстве случаев термин «capture» переводился <strong>к</strong>а<strong>к</strong> «ввод». Если было необходимо<br />

подчер<strong>к</strong>нуть а<strong>к</strong>тивный хара<strong>к</strong>тер этого процесса, то использовался оборот «сбор и ввод» или,<br />

реже, «захват».<br />

Термин «Electronic Records Management Systems, ERMS» (системы управления<br />

эле<strong>к</strong>тронными до<strong>к</strong>ументами) переводится <strong>к</strong>а<strong>к</strong> «системы эле<strong>к</strong>тронного до<strong>к</strong>ументооборота,<br />

СЭД».<br />

По те<strong>к</strong>сту перевода выражения «MoReq2», «специфи<strong>к</strong>ации MoReq2», «<strong>требования</strong> MoReq2»<br />

и «типовые <strong>требования</strong> MoReq2» используются <strong>к</strong>а<strong>к</strong> синонимы.<br />

Определенным недостат<strong>к</strong>ом Специфи<strong>к</strong>аций является то, что при ссыл<strong>к</strong>ах на публи<strong>к</strong>ации<br />

Международной организации о стандартизации ИСО (ISO) не а<strong>к</strong>центируется внимание на<br />

различии в статусе этих публи<strong>к</strong>аций. ИСО выпус<strong>к</strong>ает не толь<strong>к</strong>о международные стандарты,<br />

но и техничес<strong>к</strong>ие отчеты (это, <strong>к</strong>а<strong>к</strong> правило, те же стандарты, но не набравшие при<br />

голосовании нужного большинства) и техничес<strong>к</strong>ие специфи<strong>к</strong>ации (прое<strong>к</strong>ты стандартов,<br />

вызвавшие серьёзные разногласия, но при этом достаточно важные, чтобы оправдать их<br />

опубли<strong>к</strong>ование).<br />

Замечания и предложения<br />

Хотя мы сделали всё от нас зависящее, чтобы сделать <strong>к</strong>ачественный перевод MoReq2, мы<br />

понимаем, что <strong>к</strong>а<strong>к</strong>ие-то смысловые и техничес<strong>к</strong>ие ошиб<strong>к</strong>и неизбежны. Мы будем<br />

признательны за любые замечания и предложения по улучшению <strong>к</strong>ачества перевода,<br />

<strong>к</strong>оторые можно присылать по адресу sspchram@tochka.ru<br />

Наташа и Андрей Храмцовс<strong>к</strong>ие<br />

Мос<strong>к</strong>ва, сентябрь 2008 года<br />

Версия 1.04<br />

8 сентября 2008 Стр. 8


Специфи<strong>к</strong>ации MoReq2<br />

Ре<strong>к</strong>омендуемая дополнительная литература<br />

ГОСТ Р ИСО 15489-1-2007 «Система стандартов по информации, библиотечному и<br />

издательс<strong>к</strong>ому делу. Управление до<strong>к</strong>ументами. Общие <strong>требования</strong>». Стандарт свободно<br />

доступен на сайте Федерального агентства по техничес<strong>к</strong>ому регулированию и метрологии<br />

(Ростехрегулирования) http://www.gost.ru<br />

«<strong>Типовые</strong> <strong>требования</strong> <strong>к</strong> автоматизированным системам эле<strong>к</strong>тронного до<strong>к</strong>ументооборота.<br />

Специфи<strong>к</strong>ация MoReq», перевод С.Б.Ма<strong>к</strong>арова, издание первое, январь 2006 г.,<br />

http://gdm.ru/materials/spec_moreq_2006-01/moreq_ru.zip<br />

http://ec.europa.eu/transparency/archival_policy/moreq/doc/MoReq_RU.pdf<br />

http://www.cornwell.co.uk/moreqdocs/MoReq%20(RU).doc<br />

С.Б.Ма<strong>к</strong>аров «MoReq - европейс<strong>к</strong>ий стандарт до<strong>к</strong>ументооборота на российс<strong>к</strong>ой почве»,<br />

PCWeek, №41 (551), 2006,<br />

http://www.pcweek.ru/themes/detail.php?ID=73550&THEME_ID=13884<br />

С.Б.Ма<strong>к</strong>аров «MoReq: стандартизация до<strong>к</strong>ументооборота по-европейс<strong>к</strong>и», Byte (Россия), №6<br />

(105), июнь 2007, http://www.bytemag.ru/articles/detail.php?ID=9005<br />

Н.А.Храмцовс<strong>к</strong>ая «Стандарты СЭД: что подойдет России?», CNews (интернет-публи<strong>к</strong>ация),<br />

21.04.2006, http://www.cnews.ru/reviews/index.shtml?2006/04/21/200355_1<br />

Н.А.Храмцовс<strong>к</strong>ая «Концептуальная модель новой версии стандарта MoReq», интернетпубли<strong>к</strong>ация<br />

на сайте <strong>к</strong>омпании ЭОС, август 2006,<br />

http://www.eos.ru/upload/218567_moreq2-4ru.pdf<br />

Н.А.Храмцовс<strong>к</strong>ая «Стандарты: полезный инструмент для современного се<strong>к</strong>ретаря», обзор<br />

стандартов по <strong>управлению</strong> информацией и до<strong>к</strong>ументацией, Се<strong>к</strong>ретарь референт, № 11,<br />

ноябрь 2006 г., http://www.eos.ru/upload/analitica/UsefulTool.pdf<br />

Н.А.Храмцовс<strong>к</strong>ая «Обзор международных и зарубежных национальных стандартов по<br />

делопроизводству», Се<strong>к</strong>ретарь-референт, № 12 де<strong>к</strong>абрь 2006 г.,<br />

http://www.eos.ru/upload/analitica/IntlStandards.pdf<br />

Н.А.Храмцовс<strong>к</strong>ая «Опыт публичного обсуждения важнейших нормативных до<strong>к</strong>ументов на<br />

примере специфи<strong>к</strong>аций MoReq2», Делопроизводство и до<strong>к</strong>ументооборот на предприятии,<br />

№ 10, о<strong>к</strong>тябрь 2008 г., http://www.cornwell.co.uk/moreq2/D_08-10.pdf<br />

«Интервью с Мар<strong>к</strong>ом Фрес<strong>к</strong>о», Делопроизводство и до<strong>к</strong>ументооборот на предприятии,<br />

№11, ноябрь 2008 г., http://www.cornwell.co.uk/moreq2/D_08-11.pdf<br />

Версия 1.04<br />

8 сентября 2008 Стр. 9


Специфи<strong>к</strong>ации MoReq2<br />

1. ВВЕДЕНИЕ<br />

1.1 История разработ<strong>к</strong>и<br />

О необходимости разработ<strong>к</strong>и подробного <strong>к</strong>аталога требований <strong>к</strong> системам эле<strong>к</strong>тронного<br />

до<strong>к</strong>ументооборота (СЭД) впервые было с<strong>к</strong>азано на <strong>DLM</strong>-форуме 7 в 1996 году, в одном из<br />

десяти пун<strong>к</strong>тов плана дальнейших действий. Впоследствии, в рам<strong>к</strong>ах осуществляемой<br />

Евро<strong>к</strong>омиссией 8 программы «Обмен данными между правительствами» (Interchange of Data<br />

between Administrations, IDA), была за<strong>к</strong>азана разработ<strong>к</strong>а типовых требований <strong>к</strong> СЭД, и<br />

результатом этой работы стали специфи<strong>к</strong>ации MoReq – «<strong>Типовые</strong> <strong>требования</strong> <strong>к</strong> системам<br />

управления эле<strong>к</strong>тронными до<strong>к</strong>ументами» 9 , <strong>к</strong>оторые были опубли<strong>к</strong>ованы в 2001 году.<br />

В дальнейшем MoReq широ<strong>к</strong>о использовался <strong>к</strong>а<strong>к</strong> в странах Евросоюза, та<strong>к</strong> и за его<br />

пределами. С<strong>к</strong>азывалось, одна<strong>к</strong>о, отсутствие <strong>к</strong>а<strong>к</strong> системы а<strong>к</strong>туализации требований MoReq,<br />

та<strong>к</strong> и методи<strong>к</strong>и тестирования программного обеспечения на соответствие данным<br />

<strong>требования</strong>м.<br />

Когда потребность в обновлении MoReq и в разработ<strong>к</strong>е системы сертифи<strong>к</strong>ации стала явной,<br />

<strong>DLM</strong>-форум вступил в переговоры с Евро<strong>к</strong>омиссией, в результате <strong>к</strong>оторых в 2006 году<br />

Генеральный се<strong>к</strong>ретариат Евро<strong>к</strong>омиссии (в лице департамента B «Программа e-Domec и<br />

архивное дело») объявил о проведении от<strong>к</strong>рытого <strong>к</strong>он<strong>к</strong>урса на право подготов<strong>к</strong>и новой<br />

реда<strong>к</strong>ции требований - MoReq2. Требования разрабатывались в течение 2007 года<br />

небольшой группой специалистов-<strong>к</strong>онсультантов <strong>к</strong>омпании Serco Consulting (ранее Cornwell<br />

Management Consultants plc), <strong>к</strong>оторым помогали состоявший из э<strong>к</strong>спертов из ряда стран<br />

Совет Реда<strong>к</strong>торов, а та<strong>к</strong>же работавшие на общественных началах многочисленные<br />

рецензенты, <strong>к</strong>а<strong>к</strong> из частных, та<strong>к</strong> и из государственных организаций.<br />

В Приложении 2 приведены дополнительные сведения об использованной методологии<br />

разработ<strong>к</strong>и, а в Приложении 4 выражена благодарность всем членам работавшей на<br />

добровольных началах группы рецензирования за их в<strong>к</strong>лад в создание MoReq2, за то, что<br />

они не жалели своего времени и щедро делились опытом и знаниями.<br />

1.2 Взаимосвязь между MoReq и MoReq2<br />

Специфи<strong>к</strong>ации MoReq2 призваны заменить специфи<strong>к</strong>ации MoReq.<br />

Техничес<strong>к</strong>ое задание на разработ<strong>к</strong>у MoReq2 содержится в «План-проспе<strong>к</strong>те требований<br />

MoReq2» (“Scoping Report 10 ” for MoReq2). В нем цели разработ<strong>к</strong>и MoReq2 определены<br />

следующим образом: «Основной целью разработ<strong>к</strong>и MoReq2 является создание<br />

расширенных фун<strong>к</strong>циональных требований <strong>к</strong> СЭД, применимых в европейс<strong>к</strong>их условиях, и<br />

поддерж<strong>к</strong>а сертифи<strong>к</strong>ационного режима за счёт:<br />

7<br />

8<br />

9<br />

10<br />

Аббревиатура <strong>DLM</strong> сейчас расшифровывается <strong>к</strong>а<strong>к</strong> «Управление жизненным ци<strong>к</strong>лом<br />

информационных материалов» (“Document Lifecycle Management”) (ранее эта аббревиатура<br />

рас<strong>к</strong>рывалась <strong>к</strong>а<strong>к</strong> французс<strong>к</strong>ое выражение «машинно-читаемые данные»). Работа <strong>DLM</strong>форума<br />

основывается на решениях Совета Европы (94/C 235/03 от 17 июня 1994 года)<br />

относительно усиления <strong>к</strong>ооперации в области архивного дела.<br />

European Commission – правительство Европейс<strong>к</strong>ого Союза (прим. переводчи<strong>к</strong>а)<br />

Требования MoReq доступны на сайте http://www.<strong>DLM</strong>-Network.org. Они та<strong>к</strong>же опубли<strong>к</strong>ованы в<br />

бумажном виде, ISBN 92-894-1290-9.<br />

«План-проспе<strong>к</strong>т специфи<strong>к</strong>аций MoReq2» (“The Scoping Report for MoReq2") доступен на сайте<br />

http://www.<strong>DLM</strong>-Network.org.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 10


Специфи<strong>к</strong>ации MoReq2<br />

Усиления тех частей MoReq, <strong>к</strong>оторые за прошедшее время приобрели <strong>к</strong>лючевое<br />

значение, а та<strong>к</strong>же путем чет<strong>к</strong>ого регламентирования новых важных областей,<br />

охватываемых <strong>требования</strong>ми;<br />

Обеспечения проверяемости фун<strong>к</strong>циональных требований и разработ<strong>к</strong>и необходимых<br />

материалов, позволяющих проводить тестирование программных проду<strong>к</strong>тов на<br />

соответствие <strong>требования</strong>м;<br />

Модульности требований, с тем, чтобы способствовать их применению в различных<br />

условиях.»<br />

«С целью обеспечения совместимости, MoReq2 будет разработан <strong>к</strong>а<strong>к</strong> эволюционное<br />

обновление оригинальных специфи<strong>к</strong>аций MoReq, а не <strong>к</strong>а<strong>к</strong> совершенно новый проду<strong>к</strong>т.»<br />

Концепция «эволюционного обновления» является <strong>к</strong>лючевой. MoReq2 почти полностью<br />

совместим с MoReq (малозначащие случаи несовместимости чет<strong>к</strong>о идентифицированы);<br />

основывается на тех же <strong>к</strong>онцепциях; и, <strong>к</strong>а<strong>к</strong> до<strong>к</strong>умент, имеет сходную стру<strong>к</strong>туру.<br />

1.3 Назначение и область применения специфи<strong>к</strong>аций<br />

Настоящий до<strong>к</strong>умент представляет собой вторую версию «Типовых требований <strong>к</strong><br />

<strong>управлению</strong> эле<strong>к</strong>тронными до<strong>к</strong>ументами» (Model Requirements for the Management of<br />

Electronic Records - MoReq2). Его основным содержанием являются фун<strong>к</strong>циональные<br />

<strong>требования</strong> <strong>к</strong> <strong>управлению</strong> эле<strong>к</strong>тронными до<strong>к</strong>ументами в рам<strong>к</strong>ах системы эле<strong>к</strong>тронного<br />

до<strong>к</strong>ументооборота (СЭД).<br />

Данные Специфи<strong>к</strong>ации написаны та<strong>к</strong>им образом, чтобы быть в равной степени<br />

применимыми <strong>к</strong>а<strong>к</strong> в частных, та<strong>к</strong> и в государственных организациях, желающих внедрить<br />

СЭД либо оценить возможности уже имеющейся СЭД.<br />

Хотя в настоящем до<strong>к</strong>ументе основной упор сделан на фун<strong>к</strong>циональных <strong>требования</strong>х, в нем<br />

признается, что, <strong>к</strong>а<strong>к</strong> и для любой другой информационной системы, определенные<br />

нефун<strong>к</strong>циональные хара<strong>к</strong>теристи<strong>к</strong>и необходимы для успешной э<strong>к</strong>сплуатации СЭД. В то же<br />

время, эти нефун<strong>к</strong>циональные хара<strong>к</strong>теристи<strong>к</strong>и очень сильно различаются в зависимости от<br />

<strong>к</strong>он<strong>к</strong>ретных обстоятельств. В этой связи, необходимые нефун<strong>к</strong>циональные хара<strong>к</strong>теристи<strong>к</strong>и<br />

идентифицированы, но описаны лишь в общих чертах.<br />

В MoReq2 та<strong>к</strong>же рассматриваются, хотя и менее подробно, другие <strong>требования</strong>, тесно<br />

связанные с управлением эле<strong>к</strong>тронными до<strong>к</strong>ументами, - та<strong>к</strong>ие, <strong>к</strong>а<strong>к</strong> управление<br />

информационными материалами (document management) и эле<strong>к</strong>тронное управление<br />

физичес<strong>к</strong>ими до<strong>к</strong>ументами (например, бумажными делами и ми<strong>к</strong>роплен<strong>к</strong>ами). Та<strong>к</strong>ие<br />

родственные вопросы, <strong>к</strong>а<strong>к</strong> оцифров<strong>к</strong>а и иные средства создания эле<strong>к</strong>тронных до<strong>к</strong>ументов,<br />

не входят в <strong>к</strong>руг вопросов, рассматриваемых в Специфи<strong>к</strong>ациях. Точно та<strong>к</strong> же в<br />

Специфи<strong>к</strong>ациях не рассматриваются вопросы, связанные с пра<strong>к</strong>тичес<strong>к</strong>им внедрением СЭД<br />

Данные Требования разработаны, исходя из предположения, что <strong>к</strong>руг пользователей СЭД<br />

не ограничивается одними лишь администраторами, специалистами ДОУ и архивистами, но<br />

в<strong>к</strong>лючает та<strong>к</strong>же сотрудни<strong>к</strong>ов деловых и обслуживающих подразделений, <strong>к</strong>оторые<br />

используют СЭД в своей повседневной работе для создания, получения и извлечения<br />

до<strong>к</strong>ументов.<br />

Пос<strong>к</strong>оль<strong>к</strong>у MoReq2 задуман <strong>к</strong>а<strong>к</strong> набор «типовых» требований, то он разработан <strong>к</strong>а<strong>к</strong><br />

универсальный до<strong>к</strong>умент, не зависящий ни от используемых платформ, ни от особенностей<br />

той отрасли, в <strong>к</strong>оторой применяется СЭД. Благодаря его модульной стру<strong>к</strong>туре, сообщества<br />

Версия 1.04<br />

8 сентября 2008 Стр. 11


Специфи<strong>к</strong>ации MoReq2<br />

пользователей могут дополнять MoReq2 фун<strong>к</strong>циональными <strong>требования</strong>ми, специфичес<strong>к</strong>ими<br />

для тех условий, в <strong>к</strong>оторых они ведут свою деловую деятельность (см. раздел 1.6 и<br />

Приложение 3 относительно использования Специфи<strong>к</strong>аций и их подстрой<strong>к</strong>и под<br />

потребности пользователя).<br />

1.4 Что та<strong>к</strong>ое СЭД?<br />

СЭД в первую очередь представляет собой программное приложение для управления<br />

эле<strong>к</strong>тронными до<strong>к</strong>ументами, хотя оно может использоваться и для управления физичес<strong>к</strong>ими<br />

до<strong>к</strong>ументами. Специфи<strong>к</strong>ации определенно делают упор на вопросах управления<br />

эле<strong>к</strong>тронными до<strong>к</strong>ументами.<br />

Управление эле<strong>к</strong>тронными до<strong>к</strong>ументами является <strong>к</strong>омпле<strong>к</strong>сной проблемой, требующей,<br />

чтобы должным образом был реализован большой набор фун<strong>к</strong>циональных возможностей,<br />

позволяющий выполнить поставленные деловые задачи. Ка<strong>к</strong> правило, система, решающая<br />

эти задачи – СЭД - является специализированным программным приложением, хотя всё<br />

чаще фун<strong>к</strong>циональные возможности для управления до<strong>к</strong>ументами встраиваются в<br />

операционную систему и другие приложения.<br />

Специализированное программное обеспечение может представлять собой отдельное<br />

программное средство, или набор интегрированных программных проду<strong>к</strong>тов, или за<strong>к</strong>азное<br />

программное обеспечение, или всё перечисленное в различных сочетаниях. В любом<br />

случае потребуются та<strong>к</strong>же нормативные до<strong>к</strong>ументы и вспомогательные «ручные»<br />

процедуры.<br />

Хара<strong>к</strong>тер СЭД варьируется от организации <strong>к</strong> организации. При разработ<strong>к</strong>е данных<br />

Специфи<strong>к</strong>аций не делалось <strong>к</strong>а<strong>к</strong>их-либо предположений об особенностях <strong>к</strong>он<strong>к</strong>ретных<br />

реализаций СЭД. Пользователям данных Специфи<strong>к</strong>аций придётся самим определить, <strong>к</strong>а<strong>к</strong>им<br />

образом должны быть реализованы фун<strong>к</strong>циональные возможности СЭД, с тем, чтобы они<br />

удовлетворяли их потребностям.<br />

Системы эле<strong>к</strong>тронного до<strong>к</strong>ументооборота предполагается использовать в течение<br />

длительного периода времени, и ожидается, что они все чаще будут взаимодействовать с<br />

другими программными приложениями. Существует множество способов, позволяющих<br />

соединить СЭД с другими приложениями. Для этой цели может потребоваться разработ<strong>к</strong>а<br />

интерфейсов для захвата и ввода в СЭД отдельных до<strong>к</strong>ументов из деловых программным<br />

приложений (см. раздел 6.1), и для того, чтобы другие приложения могли получить доступ <strong>к</strong><br />

до<strong>к</strong>ументам, хранящимся в СЭД (см. раздел 4.1). Это в первую очередь относится <strong>к</strong><br />

системам управления взаимоотношениями с <strong>к</strong>лиентами (Customer Relationship Management,<br />

CRM) и <strong>к</strong> <strong>к</strong>лючевым бизнес-приложениям 11 (Line-of-business applications).<br />

В главе 10, в частности, рассматриваются вопросы взаимодействия СЭД с системами<br />

управления <strong>к</strong>онтентом (Content Management Systems, CMS), с workflow-системами, с<br />

системами работы с досье (Casework systems), а та<strong>к</strong>же интеграция с фа<strong>к</strong>с-системами. В<br />

главе 6 рассматривается взаимодействие с почтовыми приложениями (в разделе 6.3<br />

«Управление эле<strong>к</strong>тронной почтой»), и с системами с<strong>к</strong>анирования и управления<br />

графичес<strong>к</strong>ими образами (в разделе 6.5). Интерфейс провер<strong>к</strong>и метаданных обсуждается в<br />

разделе 6.1 «Ввод», и интерфейс с системами подготов<strong>к</strong>и отчетов - в разделе 8.3 «Вывод на<br />

печать».<br />

11<br />

LOB-приложения, базовые/<strong>к</strong>лючевые бизнес-приложения - решения, с помощью <strong>к</strong>оторых<br />

реализуются основные деловые процессы в данной области деятельности (прим.<br />

переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 12


Специфи<strong>к</strong>ации MoReq2<br />

MoReq2 содержит, прежде всего, <strong>требования</strong> <strong>к</strong> при<strong>к</strong>ладному программному обеспечению,<br />

специально разработанному для управления до<strong>к</strong>ументами. Данный до<strong>к</strong>умент, одна<strong>к</strong>о, та<strong>к</strong>же<br />

может использоваться в <strong>к</strong>ачестве спис<strong>к</strong>а свойств (statement of outcomes), сово<strong>к</strong>упность<br />

<strong>к</strong>оторых и представляет собой управление эле<strong>к</strong>тронными до<strong>к</strong>ументами. Положения MoReq2,<br />

говорящие «СЭД должна/желательно, чтобы СЭД…» могут та<strong>к</strong>же восприниматься <strong>к</strong>а<strong>к</strong><br />

со<strong>к</strong>ращенная форма выс<strong>к</strong>азываний типа «При<strong>к</strong>ладная система организации пользователя<br />

и/или платформа поставщи<strong>к</strong>а должны …». Пользователи MoReq2 должны решить, <strong>к</strong>а<strong>к</strong>ие из<br />

требований необходимы в их <strong>к</strong>он<strong>к</strong>ретных условиях.<br />

Использование полного набора требований MoReq2 оправдано в отношении<br />

интегрированных при<strong>к</strong>ладных систем. Одна<strong>к</strong>о в тех случаях, <strong>к</strong>огда, например,<br />

фун<strong>к</strong>циональные возможности по <strong>управлению</strong> до<strong>к</strong>ументами требуются <strong>к</strong>а<strong>к</strong> элемент системы<br />

управления досье или делового программного приложения, использование подмножества<br />

полного набора требований может быть более уместным.<br />

Опциональные модули 10.4 «Управление процессами» и 10.5 «Работа с досье»<br />

разработаны с ориентацией в первую очередь на деловые программные приложения.<br />

Одна<strong>к</strong>о описанные в MoReq2 <strong>требования</strong> в отношении многих других фун<strong>к</strong>циональных<br />

возможностей та<strong>к</strong>же могут быть применимы, и их следует учесть при внедрении подобных<br />

деловых систем.<br />

1.5 Ка<strong>к</strong> можно использовать специфи<strong>к</strong>ации MoReq2?<br />

Требования MoReq2 предназначены для использования:<br />

потенциальными пользователями СЭД: <strong>к</strong>а<strong>к</strong> основа для разработ<strong>к</strong>и тендерной<br />

до<strong>к</strong>ументации;<br />

пользователями СЭД: <strong>к</strong>а<strong>к</strong> основа для аудита либо оцен<strong>к</strong>и существующей СЭД;<br />

центрами обучения: в <strong>к</strong>ачестве справочного до<strong>к</strong>умента при подготов<strong>к</strong>е учебных <strong>к</strong>урсов,<br />

а та<strong>к</strong>же в <strong>к</strong>ачестве учебного пособия;<br />

учебными заведениями: в <strong>к</strong>ачестве учебного материала;<br />

разработчи<strong>к</strong>ами и поставщи<strong>к</strong>ами СЭД: для планирования разработ<strong>к</strong>и проду<strong>к</strong>та, исходя<br />

их необходимых фун<strong>к</strong>циональных возможностей;<br />

поставщи<strong>к</strong>ами услуг в области управления до<strong>к</strong>ументами: помогая определить<br />

хара<strong>к</strong>тер предоставляемых услуг;<br />

потенциальными пользователями переданных на аутсорсинг услуг по <strong>управлению</strong><br />

до<strong>к</strong>ументами: помогая определить перечень требуемых услуг.<br />

Кроме того, при использовании совместно с <strong>к</strong>омпле<strong>к</strong>том до<strong>к</strong>ументации для тестирования,<br />

разработанным параллельно с MoReq2, данные Специфи<strong>к</strong>ации могут быть использованы:<br />

разработчи<strong>к</strong>ами и поставщи<strong>к</strong>ами СЭД: для тестирования реализаций СЭД на<br />

соответствие <strong>требования</strong>м MoReq2;<br />

пользователями СЭД: для тестирования внедренных СЭД на соответствие<br />

<strong>требования</strong>м MoReq2.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 13


Специфи<strong>к</strong>ации MoReq2<br />

Данные Специфи<strong>к</strong>ации были написаны с ориентацией на их пра<strong>к</strong>тичес<strong>к</strong>ое применение и на<br />

удобство пользования ими.<br />

1.6 Права интелле<strong>к</strong>туальной собственности<br />

Все права интелле<strong>к</strong>туальной собственности, связанные с MoReq2, в<strong>к</strong>лючая права на<br />

использование названия «MoReq2», сохраняются за Евро<strong>к</strong>омиссией. Соответственно, перед<br />

публи<strong>к</strong>ацией <strong>к</strong>а<strong>к</strong>ого-либо перевода MoReq2 или «национального введения» - «нулевой»<br />

главы, следует получить соответствующее разрешение – см. формальное извещение,<br />

размещенное на титульной странице. По вопросам получения разрешений следует<br />

обращаться на интернет-сайт <strong>DLM</strong>-форума по адресу http://www.<strong>DLM</strong>-Network.org.<br />

1.7 Принципы разработ<strong>к</strong>и требований и ограничения на <strong>к</strong>руг<br />

рассматриваемых вопросов<br />

Специфи<strong>к</strong>ации MoReq2 специально разработаны, исходя из соображений пра<strong>к</strong>тичности и<br />

удобства использования. Они в первую очередь должны послужить пра<strong>к</strong>тичес<strong>к</strong>им<br />

инструментом, помогающим организациям решить свои деловые задачи в области<br />

управления <strong>к</strong>а<strong>к</strong> эле<strong>к</strong>тронными, та<strong>к</strong> и бумажными до<strong>к</strong>ументами. При разработ<strong>к</strong>е<br />

Специфи<strong>к</strong>аций были приняты во внимание достижения традиционной архивной нау<strong>к</strong>и и<br />

до<strong>к</strong>ументоведения, при этом они интерпретировались соответственно особенностям<br />

эле<strong>к</strong>тронной среды. Ка<strong>к</strong> следствие, специфи<strong>к</strong>ации MoReq2 были разработаны, имея в виду<br />

потребности специалистов в области управления <strong>к</strong>а<strong>к</strong> эле<strong>к</strong>тронными, та<strong>к</strong> и физичес<strong>к</strong>ими<br />

до<strong>к</strong>ументами.<br />

Реализация на пра<strong>к</strong>ти<strong>к</strong>е требований MoReq2 должна привести <strong>к</strong> созданию системы,<br />

способной управлять эле<strong>к</strong>тронными до<strong>к</strong>ументами, обеспечивая заданный уровень<br />

надёжности и целостности, сочетая для этого преимущества эле<strong>к</strong>тронных технологий и<br />

<strong>к</strong>лассичес<strong>к</strong>ой теории управления до<strong>к</strong>ументами. Примером применения та<strong>к</strong>ого<br />

прагматичес<strong>к</strong>ого подхода служит в<strong>к</strong>лючение требований <strong>к</strong> <strong>управлению</strong> информационными<br />

материалами, <strong>к</strong> средствам автоматизации рабочих процессов (workflow), <strong>к</strong> метаданным и<br />

другим взаимосвязанным технологиям.<br />

Хотя специфи<strong>к</strong>ации MoReq применимы в отношении многих видов до<strong>к</strong>ументов, важно<br />

понимать, что системы эле<strong>к</strong>тронного до<strong>к</strong>ументооборота в основном рассчитаны на<br />

управление т.н. «нестру<strong>к</strong>турированными до<strong>к</strong>ументами» 12 . Говоря простым язы<strong>к</strong>ом,<br />

нестру<strong>к</strong>турированными являются те до<strong>к</strong>ументы, что содержат информацию,<br />

представленную в форме, предназначенной в первую очередь для восприятия челове<strong>к</strong>ом.<br />

Примерами нестру<strong>к</strong>турированных до<strong>к</strong>ументов служат письма, меморандумы, сообщения<br />

эле<strong>к</strong>тронной почты, фотографии, фото<strong>к</strong>опии, отс<strong>к</strong>анированные изображения, аудио- и<br />

видеозаписи.<br />

Стру<strong>к</strong>турированные до<strong>к</strong>ументы, напротив, содержат информацию в форме,<br />

предназначенной в первую очередь для обработ<strong>к</strong>и <strong>к</strong>омпьютерными программами (примером<br />

могут служить записи в учетных системах, в системах планирования производства или<br />

системах управления воздушным движением). И хотя СЭД, в принципе, может быть<br />

12<br />

Можно было бы считать, что все эле<strong>к</strong>тронные до<strong>к</strong>ументы, управление <strong>к</strong>оторыми<br />

осуществляется должным образом, являются на самом деле стру<strong>к</strong>турированными, пос<strong>к</strong>оль<strong>к</strong>у<br />

они стру<strong>к</strong>турным образом связаны с метаданными, <strong>к</strong>онтрольной информацией и т.д. В этой<br />

связи правильнее было бы говорить о нестру<strong>к</strong>турированных до<strong>к</strong>ументах <strong>к</strong>а<strong>к</strong> о «до<strong>к</strong>ументах,<br />

содержащих нестру<strong>к</strong>турированный <strong>к</strong>онтент». Та<strong>к</strong>ая терминология, одна<strong>к</strong>о, не является<br />

общепринятой, и поэтому не используется в MoReq2.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 14


Специфи<strong>к</strong>ации MoReq2<br />

использована для хранения подобных стру<strong>к</strong>турированных до<strong>к</strong>ументов, делается это ред<strong>к</strong>о.<br />

Чаще всего стру<strong>к</strong>турированные данные сохраняются под управлением программного<br />

приложения, предназначенного для обработ<strong>к</strong>и подобных данных (в приведенных примерах<br />

это могут быть, соответственно, система бухгалтерс<strong>к</strong>ого учёта, система планирования<br />

производства или система управления воздушным движением).<br />

Системы эле<strong>к</strong>тронного до<strong>к</strong>ументооборота почти ис<strong>к</strong>лючительно применяются для хранения<br />

и управления нестру<strong>к</strong>турированными до<strong>к</strong>ументами. Те случаи, <strong>к</strong>огда СЭД используется для<br />

управления стру<strong>к</strong>турированными до<strong>к</strong>ументами, в основном связаны с управлением досье –<br />

см. раздел 10.5<br />

Пра<strong>к</strong>тичес<strong>к</strong>ие аспе<strong>к</strong>ты управления до<strong>к</strong>ументами в MoReq2 не рассматриваются.<br />

Совершенно осознанно в Специфи<strong>к</strong>ациях рассматриваются толь<strong>к</strong>о те фун<strong>к</strong>циональные<br />

возможности, <strong>к</strong>оторые нужны для управления эле<strong>к</strong>тронными до<strong>к</strong>ументами при помощи<br />

программного обеспечения. В Специфи<strong>к</strong>ациях не обсуждаются философия управления<br />

до<strong>к</strong>ументами, теория архивного дела, принятие решений, <strong>к</strong>онтроль со стороны ру<strong>к</strong>оводства<br />

и т.д.; эти вопросы достаточно хорошо освещены в другой литературе, часть <strong>к</strong>оторой<br />

перечислена в Приложении 1. В частности, в Специфи<strong>к</strong>ациях в нес<strong>к</strong>оль<strong>к</strong>их местах говорится<br />

о том, что определенные фун<strong>к</strong>циональные возможности должны быть доступны толь<strong>к</strong>о<br />

лицам, исполняющим административные роли при работе с СЭД. Здесь речь идет не о<br />

принятии исполнителями административных ролей принципиальных решений, а всего лишь<br />

о том, что они должны быть единственными пользователями, <strong>к</strong>ому организация дает право<br />

использовать соответствующие возможности СЭД.<br />

Важно отметить, что полити<strong>к</strong>а в области управления до<strong>к</strong>ументами должна быть<br />

интегрирована с деловыми и техничес<strong>к</strong>ими <strong>требования</strong>ми организации; и что исполнители<br />

административных ролей лишь выполняют, - в области управления до<strong>к</strong>ументами и<br />

системой, - решения, принятые вышестоящим ру<strong>к</strong>оводством.<br />

На<strong>к</strong>онец, Специфи<strong>к</strong>ации сознательно ориентированы на пользователей. В них, нас<strong>к</strong>оль<strong>к</strong>о<br />

возможно, используется терминология, общепринятая среди тех, <strong>к</strong>то работает с<br />

эле<strong>к</strong>тронными до<strong>к</strong>ументами. Например, для простоты понимания, об эле<strong>к</strong>тронных делах в<br />

Специфи<strong>к</strong>ациях говорится <strong>к</strong>а<strong>к</strong> о «содержащих» до<strong>к</strong>ументы, - несмотря но то, что, строго<br />

говоря, на самом деле они ничего не содержат. Подробности см. в разделе 2.2.<br />

1.8 Учёт особенностей отдельных стран-членов Евросоюза<br />

Ка<strong>к</strong> было с<strong>к</strong>азано в п.1.3 «Назначение и область применения», в данных Специфи<strong>к</strong>ациях<br />

сделана попыт<strong>к</strong>а сформулировать <strong>требования</strong> та<strong>к</strong>им образом, чтобы они охватывали<br />

широ<strong>к</strong>ий <strong>к</strong>руг вопросов и подходили для различных стран, различных се<strong>к</strong>торов э<strong>к</strong>ономи<strong>к</strong>и и<br />

для различных видов до<strong>к</strong>ументов. Та<strong>к</strong>ая широта охвата выбрана сознательно, одна<strong>к</strong>о она<br />

приводит <strong>к</strong> определенным ограничениям, а именно, <strong>к</strong> тому, что для точного соответствия<br />

потребностям организации <strong>требования</strong> придётся модифицировать. В разных странах<br />

существуют различные традиции, взгляды и за<strong>к</strong>онодательно-нормативные <strong>требования</strong> <strong>к</strong><br />

<strong>управлению</strong> до<strong>к</strong>ументами. Их в ряде случае придется принять во внимание при<br />

использовании данных типовых требований, особенно тогда, <strong>к</strong>огда формулируются<br />

<strong>требования</strong> <strong>к</strong> новой системе. По этой причине допус<strong>к</strong>ается добавление странами Евросоюза<br />

в MoReq2 «национального введения» - т.н. «нулевой главы», в <strong>к</strong>оторой дается описание<br />

национальных требований, та<strong>к</strong>их <strong>к</strong>а<strong>к</strong>:<br />

Перевод <strong>к</strong>лючевых терминов и понятий;<br />

Национальные за<strong>к</strong>онодательные и нормативные <strong>требования</strong>;<br />

Версия 1.04<br />

8 сентября 2008 Стр. 15


Специфи<strong>к</strong>ации MoReq2<br />

Национальные стандарты и ру<strong>к</strong>оводства по обеспечению доступности (accessibility);<br />

Иные национальные <strong>требования</strong>;<br />

Национальные ресурсы для получения дополнительной информации.<br />

1.9 Использование специфи<strong>к</strong>аций MoReq2<br />

В<strong>к</strong>люченные в настоящий до<strong>к</strong>умент <strong>требования</strong> должны рассматриваться <strong>к</strong>а<strong>к</strong> типовые,<br />

модельные. Они не являются строго обязательными для всех возможных реализаций СЭД;<br />

и не<strong>к</strong>оторые <strong>требования</strong> в определенных случаях о<strong>к</strong>ажутся неприменимыми. Фа<strong>к</strong>торы,<br />

связанные с различными отраслями э<strong>к</strong>ономи<strong>к</strong>и, различными масштабами внедрения,<br />

различными типами организаций и др., та<strong>к</strong>же приведут <strong>к</strong> появлению дополнительных<br />

специфичес<strong>к</strong>их требований.<br />

Та<strong>к</strong>им образом, перед использованием данных Специфи<strong>к</strong>аций при проведении за<strong>к</strong>упо<strong>к</strong>, их<br />

необходимо адаптировать. При подобной адаптации<br />

добавляются или ис<strong>к</strong>лючаются <strong>требования</strong>, в соответствии со специфичес<strong>к</strong>ими<br />

потребностями организации;<br />

уточняются те <strong>требования</strong>, формулиров<strong>к</strong>и <strong>к</strong>оторых могут быть сделаны более<br />

<strong>к</strong>он<strong>к</strong>ретными и однозначными, например:<br />

<br />

<br />

<strong>требования</strong>, предусматривающие нес<strong>к</strong>оль<strong>к</strong>о возможных вариантов, могут быть<br />

переделаны та<strong>к</strong>им образом, чтобы предусматривать единственный требуемый<br />

вариант;<br />

<strong>требования</strong> в отношении объёмов и производительности.<br />

в<strong>к</strong>лючаются подробности, специфичес<strong>к</strong>ие для данной организации, - та<strong>к</strong>ие, <strong>к</strong>а<strong>к</strong><br />

параметры используемой программной среды;<br />

чет<strong>к</strong>о у<strong>к</strong>азывается, <strong>к</strong>а<strong>к</strong>ие из требований:<br />

<br />

<br />

<br />

<br />

взяты из MoReq2 в неизменном виде,<br />

добавлены,<br />

удалены,<br />

уточнены.<br />

Данные Специфи<strong>к</strong>ации были подготовлены та<strong>к</strong>им образом, чтобы ими можно было<br />

пользоваться <strong>к</strong>а<strong>к</strong> в бумажном, та<strong>к</strong> и в эле<strong>к</strong>тронном виде. Те<strong>к</strong>ст был набран в Microsoft Word<br />

2003, и опубли<strong>к</strong>ован в следующих форматах:<br />

Microsoft Word 97-2003 (Version 11);<br />

Microsoft Word 2007 (Version 12);<br />

Adobe PDF (Version 1.4).<br />

Использование Специфи<strong>к</strong>аций в эле<strong>к</strong>тронном виде имеет ряд преимуществ; см.<br />

подробности в Приложении 3.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 16


Специфи<strong>к</strong>ации MoReq2<br />

1.10 Стру<strong>к</strong>тура специфи<strong>к</strong>аций MoReq2<br />

Те<strong>к</strong>ст Специфи<strong>к</strong>аций делится на главы, <strong>к</strong>оторые, в свою очередь, состоят из разделов.<br />

Следующая глава (глава 2) начинается с перечисления важнейших для данного до<strong>к</strong>умента<br />

терминов; далее в ней дается обзор ряда <strong>к</strong>лючевых требований.<br />

Главы с 3 по 9 детально описывают базовые фун<strong>к</strong>циональные <strong>требования</strong> <strong>к</strong> СЭД. Каждая<br />

глава содержит определенную логичес<strong>к</strong>и зам<strong>к</strong>нутую группу фун<strong>к</strong>циональных требований,<br />

одна<strong>к</strong>о, принимая во внимание особенности предмета, между главами неизбежно<br />

существует определенное «пересечение».<br />

Глава 10 состоит из нес<strong>к</strong>оль<strong>к</strong>их разделов, в <strong>к</strong>аждом из <strong>к</strong>оторых содержатся <strong>требования</strong> <strong>к</strong><br />

определенному опциональному модулю СЭД. Не<strong>к</strong>оторые из этих разделов (например,<br />

раздел по распределенным системам), будут существенны для одних организаций, и не<br />

будут представлять интереса для других.<br />

Глава 11 содержит нефун<strong>к</strong>циональные <strong>требования</strong>.<br />

В главе 12 перечислены <strong>требования</strong> <strong>к</strong> <strong>управлению</strong> метаданными. Определения<br />

необходимых для MoReq2 элементов метаданных даны в Приложении 9.<br />

Глава 13 содержит формальную модель СЭД с точ<strong>к</strong>и зрения данных Специфи<strong>к</strong>аций. Эта<br />

модель может быть полезна для понимания <strong>к</strong>лючевых аспе<strong>к</strong>тов Специфи<strong>к</strong>аций, та<strong>к</strong>их, <strong>к</strong>а<strong>к</strong><br />

формальные определения понятий и объе<strong>к</strong>тов СЭД (например, «рубри<strong>к</strong>а», «суб-дело»,<br />

«том»), и существующих между ними взаимосвязей (например, «что может храниться в<br />

эле<strong>к</strong>тронном деле?»).<br />

Приложения в<strong>к</strong>лючают ссыл<strong>к</strong>и на нормативно-справочную литературу, административную и<br />

иную информацию. Приложение 9, содержащее модель метаданных MoReq2, публи<strong>к</strong>уется<br />

отдельно от основного те<strong>к</strong>ста Специфи<strong>к</strong>аций - ввиду его большого объема, и для упрощения<br />

пере<strong>к</strong>рестных ссыло<strong>к</strong>.<br />

В ответ на многочисленные <strong>требования</strong>, в дополнение <strong>к</strong> <strong>требования</strong>м были разработаны<br />

материалы по тестированию. Эти материалы публи<strong>к</strong>уются вместе с эле<strong>к</strong>тронными <strong>к</strong>опиями<br />

Специфи<strong>к</strong>аций. Стру<strong>к</strong>тура MoReq2 разработана та<strong>к</strong>им образом, чтобы способствовать<br />

проведению тестирования на соответствие <strong>требования</strong>м - например, <strong>к</strong>аждому разделу главы<br />

10 соответствует свой опциональный тестовый модуль. Подробности о тестировании на<br />

соответствие <strong>требования</strong>м MoReq2 см. на сайте http://www.<strong>DLM</strong>-Network.org. .<br />

Требования представлены в виде таблиц, в <strong>к</strong>оторых <strong>к</strong>аждое требование занимает стро<strong>к</strong>у<br />

(см. рис. 1.1).<br />

Рис. 1.1<br />

Каждому требованию присвоен номер. Требования сформулированы на естественном<br />

язы<strong>к</strong>е.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 17


Специфи<strong>к</strong>ации MoReq2<br />

1.11 Тестирование на соответствие <strong>требования</strong>м MoReq2<br />

Тестируемость<br />

Для <strong>к</strong>аждого из требований приводится значение атрибута «тестируемость», <strong>к</strong>оторое<br />

у<strong>к</strong>азывает, есть ли возможность проверить исполнение данного <strong>требования</strong>. Возможные<br />

значения данного атрибута (с примерами) приведены ниже:<br />

Y – Может быть проведена строгая формальная провер<strong>к</strong>а исполнения<br />

<strong>требования</strong>. Например, выполнение <strong>требования</strong> «СЭД должна допус<strong>к</strong>ать <strong>к</strong>а<strong>к</strong> минимум<br />

три иерархичес<strong>к</strong>их уровня в <strong>к</strong>лассифи<strong>к</strong>ационной схеме» может быть проверено<br />

посредством попыт<strong>к</strong>и создать иерархичес<strong>к</strong>ую стру<strong>к</strong>туру из трех уровней.<br />

N – Невозможно формально проверить исполнение <strong>требования</strong>. Примером служит<br />

требование «СЭД должна поддерживать <strong>к</strong>лассифи<strong>к</strong>ационную схему, используемую<br />

организацией в деловой деятельности». В общем случае, проверить его выполнение<br />

невозможно.<br />

P – Исполнение <strong>требования</strong> может быть проверено, одна<strong>к</strong>о провер<strong>к</strong>а является<br />

частичной и/или фа<strong>к</strong>т невыполнения данного требованию может быть обнаружен с<br />

определенной вероятностью 13 . Примером служит требование «СЭД не должна<br />

ограничивать число уровней в иерархичес<strong>к</strong>ой <strong>к</strong>лассифи<strong>к</strong>ационной схеме». Нет способа,<br />

<strong>к</strong>оторый позволял бы формально проверить отсутствие ограничения. Одна<strong>к</strong>о частичная<br />

провер<strong>к</strong>а возможна, например, через попыт<strong>к</strong>у создания большого числа уровней. Есть<br />

вероятность, что в результате та<strong>к</strong>ого тестирования может быть обнаружено наличие<br />

ограничения на число уровней, у<strong>к</strong>азывающее на то, что в СЭД данное требование не<br />

выполняется.<br />

Системы, внешние по отношению <strong>к</strong> СЭД<br />

Данные Специфи<strong>к</strong>ации сопровождаются Правилами тестирования на соответствие MoReq2<br />

(Testing Framework), <strong>к</strong>оторые в<strong>к</strong>лючают в себя до<strong>к</strong>ументацию, позволяющую провести<br />

провер<strong>к</strong>у на соответствие СЭД <strong>требования</strong>м MoReq2.<br />

Для выполнения ряда требований MoReq2 необходимо оборудование и программное<br />

обеспечение, <strong>к</strong>оторые являются внешними по отношению <strong>к</strong> СЭД. Например, MoReq2<br />

в<strong>к</strong>лючает:<br />

<strong>требования</strong> <strong>к</strong> интеграции с системой эле<strong>к</strong>тронной почты, выполнение <strong>к</strong>оторых зависит от<br />

фун<strong>к</strong>циональных возможностей почтовой программы;<br />

<strong>требования</strong> <strong>к</strong> масштабируемости и целостности, выполнение <strong>к</strong>оторых зависит от<br />

фун<strong>к</strong>циональных возможностей программного обеспечения системы управления базой<br />

данных (СУБД);<br />

<strong>требования</strong> <strong>к</strong> процессу с<strong>к</strong>анирования, выполнение <strong>к</strong>оторых зависит от используемого для<br />

с<strong>к</strong>анирования оборудования.<br />

Понятно, что невозможно провести тестирование СЭД совместно со всеми возможными<br />

вариантами оборудования и программного обеспечения. Ка<strong>к</strong> следствие, выполнение<br />

13<br />

Т.е. успешное прохождение теста не даёт 100% гарантии исполнения <strong>требования</strong> (прим.<br />

переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 18


Специфи<strong>к</strong>ации MoReq2<br />

подобных требований будет проверяться в <strong>к</strong>омбинации с программным обеспечением и<br />

оборудованием, у<strong>к</strong>азанным поставщи<strong>к</strong>ом СЭД. Выдаваемый в итоге сертифи<strong>к</strong>ат о<br />

прохождении тестирования будет содержать сведения о том оборудовании и программном<br />

обеспечении, <strong>к</strong>оторые использовались при тестировании; и за<strong>к</strong>лючение о соответствии<br />

будет распространяться толь<strong>к</strong>о на данную <strong>к</strong>онфигурацию. Потенциальным пользователям<br />

СЭД, желающим выяснить, соответствует ли СЭД <strong>требования</strong>м при работе совместно с<br />

другим оборудованием и/или программным обеспечением, потребуется в <strong>к</strong>аждом случае<br />

провести отдельную оцен<strong>к</strong>у соответствия.<br />

1.12 Обязательные и желательные <strong>требования</strong><br />

MoReq2 в<strong>к</strong>лючает в себя <strong>к</strong>а<strong>к</strong> обязательные, та<strong>к</strong> и желательные (опциональные) <strong>требования</strong>.<br />

Степень обязательности у<strong>к</strong>азывается следующим образом:<br />

использование глагола «должен» (must) у<strong>к</strong>азывает на то, что требование является<br />

обязательным (в данном переводе для этой цели используются <strong>к</strong>онстру<strong>к</strong>ции типа «СЭД<br />

должна ...»);<br />

использование <strong>к</strong>онстру<strong>к</strong>ции «желательно, чтобы» (should) у<strong>к</strong>азывает на то, что данное<br />

требование является желательным (в данном переводе для этой цели используются<br />

<strong>к</strong>онстру<strong>к</strong>ции типа «желательно, чтобы СЭД ...»).<br />

В любом случае, степень обязательности зависит от <strong>к</strong>онте<strong>к</strong>ста. Та<strong>к</strong>, например,<br />

обязательное требование, входящее в состав опционального модуля, является<br />

обязательным толь<strong>к</strong>о в <strong>к</strong>онте<strong>к</strong>сте этого опционального модуля 14 .<br />

В ряде случаев требование рассматривается <strong>к</strong>а<strong>к</strong> обязательное толь<strong>к</strong>о тогда, <strong>к</strong>огда<br />

выполнено определенное желательное требование. Это всегда ясно из <strong>к</strong>онте<strong>к</strong>ста, -<br />

например, следующий те<strong>к</strong>ст:<br />

3.1.17: Желательно, чтобы СЭД поддерживала э<strong>к</strong>спорт <strong>к</strong>а<strong>к</strong> всей <strong>к</strong>лассифи<strong>к</strong>ационной<br />

схемы, та<strong>к</strong> и её части.<br />

3.1.18: Если СЭД поддерживает э<strong>к</strong>спорт <strong>к</strong>а<strong>к</strong> всей <strong>к</strong>лассифи<strong>к</strong>ационной схемы, та<strong>к</strong> и её<br />

части (<strong>к</strong>а<strong>к</strong> в 3.1.17), необходимо, чтобы э<strong>к</strong>спортировались та<strong>к</strong>же все соответствующие<br />

метаданные […]<br />

означает, что наличие фун<strong>к</strong>циональной возможности, предусмотренной п.3.1.18,<br />

обязательно тогда и толь<strong>к</strong>о тогда, <strong>к</strong>огда реализована желательная фун<strong>к</strong>циональная<br />

возможность, предусмотренная в п.3.1.17.<br />

1.13 Замечания и предложения<br />

Информацию о поряд<strong>к</strong>е представления замечаний и предложений можно найти на сайте<br />

<strong>DLM</strong>-форума: http://www.<strong>DLM</strong>-Network.org.<br />

14<br />

Т.е. толь<strong>к</strong>о в том случае, если предполагается соответствие СЭД <strong>требования</strong>м данного<br />

опционального модуля (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 19


Специфи<strong>к</strong>ации MoReq2<br />

2. ОБЗОР ТРЕБОВАНИЙ К СЭД<br />

Данная глава начинается с определения <strong>к</strong>лючевых терминов (раздел 2.1). Затем следует<br />

<strong>к</strong>рат<strong>к</strong>ое описание ряда основных понятий и <strong>к</strong>онцепций (раздел 2.2) и диаграмма,<br />

по<strong>к</strong>азывающая взаимоотношения между объе<strong>к</strong>тами СЭД в модели, на <strong>к</strong>оторой<br />

основываются настоящие Специфи<strong>к</strong>ации (раздел 2.3).<br />

2.1 Основные термины<br />

Для однозначного тол<strong>к</strong>ования требований MoReq2 необходимо дать точное определение<br />

ряда терминов. По мере возможности, термины используются либо в общеупотребительном<br />

значении, либо в значении, принятом среди специалистов по <strong>управлению</strong> до<strong>к</strong>ументами. В то<br />

же время, в ряде случаев термины используются в значениях, специфичес<strong>к</strong>их для MoReq2.<br />

Определения всех терминов приведены в Глоссарии (раздел 13.1). Для удобства<br />

пользования настоящим до<strong>к</strong>ументом в данном разделе воспроизводятся определения<br />

Глоссария для <strong>к</strong>лючевых терминов, т.е. для тех, что необходимы для правильного<br />

понимания MoReq2. Приведенные здесь определения идентичны определениям в полном<br />

Глоссарии.<br />

В последующих определениях <strong>к</strong>урсивом выделены термины, <strong>к</strong>оторые можно найти в<br />

Глоссарии (раздел 13.1).<br />

ввод, «захват» до<strong>к</strong>ументов (capture)<br />

(1) А<strong>к</strong>т записи или сохранения отдельного э<strong>к</strong>земпляра цифрового объе<strong>к</strong>та (источни<strong>к</strong>:<br />

терминологичес<strong>к</strong>ая база данных прое<strong>к</strong>та InterPARES-2).<br />

(2) Сохранение информации в <strong>к</strong>омпьютерной системе.<br />

Замечание: в <strong>к</strong>онте<strong>к</strong>сте MoReq2, под «захватом» до<strong>к</strong>ументов понимаются все процессы,<br />

используемые на этапе ввода до<strong>к</strong>умента в СЭД, а именно регистрация, <strong>к</strong>лассифи<strong>к</strong>ация,<br />

добавление метаданных и «замораживание» содержания исходного информационного<br />

материала (запрещение внесения в него изменений). Данный термин может та<strong>к</strong>же<br />

использоваться и в обобщенном значении, означая ввод и сохранение в СЭД другой<br />

информации, та<strong>к</strong>ой, <strong>к</strong>а<strong>к</strong> значения метаданных.<br />

досье (case file)<br />

Дело, относящееся <strong>к</strong> одной или нес<strong>к</strong>оль<strong>к</strong>им транза<strong>к</strong>циям, полностью или частично<br />

выполненным стру<strong>к</strong>турированным или частично-стру<strong>к</strong>турированным образом, в ходе<br />

<strong>к</strong>он<strong>к</strong>ретного процесса или вида деятельности.<br />

Замечание: Общепринятого определения термина «досье» нет, равно <strong>к</strong>а<strong>к</strong> нет и согласия<br />

относительно того, чем досье отличаются от других видов дел, <strong>к</strong>оторыми управляет СЭД.<br />

Приведенное здесь определение разработано для MoReq2 и должно способствовать<br />

пониманию Специфи<strong>к</strong>аций; его применимость в иных обстоятельствах не гарантируется.<br />

Замечание: до<strong>к</strong>ументы в досье могут быть <strong>к</strong>а<strong>к</strong> стру<strong>к</strong>турированными, та<strong>к</strong> и<br />

нестру<strong>к</strong>турированными. Хара<strong>к</strong>терной отличительной особенностью досье является то, что<br />

они возни<strong>к</strong>ают в результате процессов, <strong>к</strong>оторые, <strong>к</strong>а<strong>к</strong> минимум, частично стру<strong>к</strong>турированы и<br />

повторяемы. Примерами досье могут служить дела, содержащие до<strong>к</strong>ументы, относящиеся:<br />

<strong>к</strong> заявлениям на получение разрешений;<br />

Версия 1.04<br />

8 сентября 2008 Стр. 20


Специфи<strong>к</strong>ации MoReq2<br />

<strong>к</strong> запросам о проведении обслуживания и те<strong>к</strong>ущего ремонта;<br />

<strong>к</strong> расследованию инцидентов;<br />

<strong>к</strong> отслеживанию изменений в за<strong>к</strong>онодательной и нормативной базе (regulatory<br />

monitoring).<br />

Замечание: Другими типичными хара<strong>к</strong>терными особенностями досье являются:<br />

предс<strong>к</strong>азуемость стру<strong>к</strong>туры их содержания;<br />

их многочисленность;<br />

то, что они стру<strong>к</strong>турированы или частично-стру<strong>к</strong>турированы;<br />

то, что они используются и управляются в рам<strong>к</strong>ах известного предопределённого<br />

процесса;<br />

то, что их необходимо сохранять в течение сро<strong>к</strong>а, установленного за<strong>к</strong>онодательством<br />

и/или нормативными а<strong>к</strong>тами;<br />

то, что они могут быть от<strong>к</strong>рыты и за<strong>к</strong>рыты работающими с ними специалистамипра<strong>к</strong>ти<strong>к</strong>ами,<br />

<strong>к</strong>онечными пользователями или системами обработ<strong>к</strong>и данных без<br />

получения согласия ру<strong>к</strong>оводства.<br />

рубри<strong>к</strong>а (class)<br />

(в MoReq2) Часть иерархии, представленная линией, идущей от любой точ<strong>к</strong>и в<br />

иерархичес<strong>к</strong>ой стру<strong>к</strong>туре <strong>к</strong>лассифи<strong>к</strong>ационной схемы <strong>к</strong>о всем делам, лежащим ниже нее.<br />

Замечание: данное понятие может соответствовать та<strong>к</strong>им понятиям из <strong>к</strong>лассичес<strong>к</strong>ой<br />

терминологии 15 , <strong>к</strong>а<strong>к</strong> "основной <strong>к</strong>ласс" 16 , "группа" или "серия" 17 (или под<strong>к</strong>ласс, подгруппа, субсерия<br />

и т.д. на любом уровне <strong>к</strong>лассифи<strong>к</strong>ационной схемы).<br />

Замечание: в MoReq2 термин «рубри<strong>к</strong>а» та<strong>к</strong>же используется для обозначения всех<br />

входящих в эту рубри<strong>к</strong>у до<strong>к</strong>ументов.<br />

<strong>к</strong>лассифи<strong>к</strong>ация<br />

В управлении до<strong>к</strong>ументами, под «<strong>к</strong>лассифи<strong>к</strong>ацией» понимается систематичес<strong>к</strong>ая<br />

идентифи<strong>к</strong>ация и упорядочивание видов деловой деятельности и/или до<strong>к</strong>ументов по<br />

<strong>к</strong>атегориям, в соответствии с логичес<strong>к</strong>и стру<strong>к</strong>турированными условиями, методами и<br />

процедурными правилами, составляющими систему <strong>к</strong>лассифи<strong>к</strong>ации.<br />

Источни<strong>к</strong>: стандарт ISO 15489 (см. Приложение 7).<br />

15<br />

16<br />

17<br />

Имеется в виду терминология, используемая в ряде англоса<strong>к</strong>сонс<strong>к</strong>их стран (прим.<br />

переводчи<strong>к</strong>а)<br />

Основной <strong>к</strong>ласс (primary class) - рубри<strong>к</strong>а первого уровня <strong>к</strong>лассифи<strong>к</strong>ационной схемы.<br />

Нижележащие подрубри<strong>к</strong>и в этом случае называются под<strong>к</strong>лассами (sub-classes) (прим.<br />

переводчи<strong>к</strong>а)<br />

Серия (series) - группа взаимосвязанных до<strong>к</strong>ументов, <strong>к</strong>оторые обычно используются и<br />

сохраняются <strong>к</strong>а<strong>к</strong> единое целое, и <strong>к</strong>оторые рассматриваются <strong>к</strong>а<strong>к</strong> единое целое при<br />

определении сро<strong>к</strong>а хранения. (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 21


Специфи<strong>к</strong>ации MoReq2<br />

<strong>к</strong>лассифи<strong>к</strong>ационная схема<br />

(в MoReq2) Иерархичес<strong>к</strong>ая стру<strong>к</strong>тура, образованная из рубри<strong>к</strong>, дел, суб-дел, томов и<br />

до<strong>к</strong>ументов.<br />

<strong>к</strong>омпонент, <strong>к</strong>омпонента (component)<br />

Обособленный пото<strong>к</strong> битов, <strong>к</strong>оторый, самостоятельно или совместно с другими пото<strong>к</strong>ами<br />

битов, образует до<strong>к</strong>умент или информационный материал.<br />

Замечание: Данное тол<strong>к</strong>ование термина не является общеупотребительным.<br />

Замечание: Выражение «обособленный пото<strong>к</strong> битов» используется вместо применяемого в<br />

информационных технологиях термина «файл» (file). Это делается для того, чтобы избежать<br />

путаницы с делопроизводчес<strong>к</strong>им термином «дело» (file). Суть данного понятия за<strong>к</strong>лючается<br />

в том, что «<strong>к</strong>омпонента» является неотъемлемой частью <strong>к</strong>онтента до<strong>к</strong>умента, несмотря на<br />

то, что с ней можно работать и ею можно управлять и отдельно.<br />

Примерами <strong>к</strong>омпонент являются:<br />

Информационный материал в формате HTML и графичес<strong>к</strong>ие образы в формате JPEG,<br />

<strong>к</strong>оторые вместе составляют веб-страницу;<br />

Те<strong>к</strong>стовой информационный материал и эле<strong>к</strong>тронная таблица, в случае, <strong>к</strong>огда до<strong>к</strong>умент<br />

представляет собой те<strong>к</strong>ст, содержащий встроенную ссыл<strong>к</strong>у (гиперссыл<strong>к</strong>у) на<br />

эле<strong>к</strong>тронную таблицу.<br />

Замечание: Следует иметь в виду, что <strong>к</strong>омпоненты должны быть обособленными,<br />

отдельными друг от друга. Если те<strong>к</strong>стовой информационный материал в<strong>к</strong>лючает<br />

встроенную эле<strong>к</strong>тронную таблицу (в отличие от встроенной ссыл<strong>к</strong>и на эле<strong>к</strong>тронную<br />

таблицу), то та<strong>к</strong>ая эле<strong>к</strong>тронная таблица не рассматривается <strong>к</strong>а<strong>к</strong> отдельная <strong>к</strong>омпонента. В<br />

этом случае до<strong>к</strong>умент состоит из одной <strong>к</strong>омпоненты, <strong>к</strong>оторой является те<strong>к</strong>ст вместе со<br />

встроенной эле<strong>к</strong>тронной таблицей.<br />

Замечание: сообщение эле<strong>к</strong>тронной почты с приложениями может состоять <strong>к</strong>а<strong>к</strong> из одной, та<strong>к</strong><br />

и из нес<strong>к</strong>оль<strong>к</strong>их <strong>к</strong>омпонент, или же представлять собой нес<strong>к</strong>оль<strong>к</strong>о до<strong>к</strong>ументов – в<br />

зависимости от формата, в <strong>к</strong>отором оно сохранено.<br />

Если сообщение сохраняется в формате, в<strong>к</strong>лючающем тело сообщения и все<br />

приложения, то имеется толь<strong>к</strong>о одна <strong>к</strong>омпонента.<br />

Если приложения сохраняются отдельно от тела сообщения и связываются с ним<br />

внутренней связью, то тело сообщения и <strong>к</strong>аждое из приложений является отдельной<br />

<strong>к</strong>омпонентой.<br />

Если приложения сохраняются отдельно от тела сообщения эле<strong>к</strong>тронной почты, но<br />

внутренняя связь между ними не устанавливается, то тело сообщения и <strong>к</strong>аждое из<br />

приложений является отдельным до<strong>к</strong>ументом. С точ<strong>к</strong>и зрения хорошей пра<strong>к</strong>ти<strong>к</strong>и,<br />

желательно в этом случае вручную связать друг с другом эти до<strong>к</strong>ументы.<br />

информационный материал (document)<br />

Зафи<strong>к</strong>сированная информация либо объе<strong>к</strong>т, <strong>к</strong>оторые могут обрабатываться <strong>к</strong>а<strong>к</strong> единое<br />

целое.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 22


Специфи<strong>к</strong>ации MoReq2<br />

Источни<strong>к</strong>: стандарт ISO 15489 (см. Приложение 7).<br />

Замечание: информационный материал может быть зафи<strong>к</strong>сирован на бумаге, ми<strong>к</strong>роплён<strong>к</strong>е,<br />

на магнитном или ином эле<strong>к</strong>тронном носителе. Он может содержать любую <strong>к</strong>омбинацию<br />

те<strong>к</strong>ста, данных, графи<strong>к</strong>и, зву<strong>к</strong>а, видеоизображения и иных форм информации. Отдельный<br />

информационный материал может состоять из одного или нес<strong>к</strong>оль<strong>к</strong>их <strong>к</strong>омпонентов.<br />

Замечание: между информационными материалами и до<strong>к</strong>ументами имеется ряд<br />

существенных отличий. В MoReq2 термин «информационный материал» используется для<br />

обозначения информации, не получившей статуса до<strong>к</strong>умента, т.е. той, что не прошла<br />

<strong>к</strong>лассифи<strong>к</strong>ацию, регистрацию и не была защищена от внесения в неё изменений.<br />

В определении прилагательное «зафи<strong>к</strong>сированная» (recorded) не подразумевает придание<br />

свойств до<strong>к</strong>умента (record). Следует, одна<strong>к</strong>о, иметь в виду, что не<strong>к</strong>оторые<br />

информационные материалы становятся до<strong>к</strong>ументами.<br />

эле<strong>к</strong>тронный до<strong>к</strong>умент (electronic record)<br />

До<strong>к</strong>умент в эле<strong>к</strong>тронной форме.<br />

Замечание: до<strong>к</strong>умент может быть в эле<strong>к</strong>тронной форме вследствие создания при помощи<br />

при<strong>к</strong>ладного программного обеспечения либо в результате оцифров<strong>к</strong>и, например, путем<br />

с<strong>к</strong>анирования.<br />

СЭД (ERMS)<br />

Система эле<strong>к</strong>тронного до<strong>к</strong>ументооборота (Electronic Records Management System).<br />

Замечание: между СЭД и эле<strong>к</strong>тронно-информационными системами, ЭИС (EDMS) имеется<br />

ряд важных различий, см. подробности в разделе 10.3.<br />

дело (file)<br />

Организованная сово<strong>к</strong>упность до<strong>к</strong>ументов, сгруппированных вместе ввиду того, что они<br />

относятся <strong>к</strong> одному вопросу, виду деятельности или транза<strong>к</strong>ции.<br />

Источни<strong>к</strong>: со<strong>к</strong>ращенное и адаптированное определение из стандарта ISAD(G) (см.<br />

Приложение 7).<br />

Замечание: в та<strong>к</strong>ом значении термин file («дело») применяется в управлении до<strong>к</strong>ументами.<br />

В сфере информационных технологий он используется в ином значении, для <strong>к</strong>оторого в<br />

MoReq2 служит термин component («<strong>к</strong>омпонента»).<br />

метаданные<br />

(в <strong>к</strong>онте<strong>к</strong>сте управления до<strong>к</strong>ументами) Данные, описывающие <strong>к</strong>онте<strong>к</strong>ст, содержание<br />

(<strong>к</strong>онтент) и стру<strong>к</strong>туру до<strong>к</strong>ументов, а та<strong>к</strong>же управление до<strong>к</strong>ументами во времени.<br />

Источни<strong>к</strong>: стандарт ISO 15489 (см. Приложение 7).<br />

Замечание: существуют модели, используются иные <strong>к</strong>онцептуальные представления о<br />

метаданных. Например, <strong>к</strong>онтрольная информация (audit trail) в них иногда рассматривается<br />

<strong>к</strong>а<strong>к</strong> вид метаданных. Хотя та<strong>к</strong>ие альтернативные точ<strong>к</strong>и зрения имеют право на<br />

существование и могут быть полезны при определенных обстоятельствах, они мало<br />

Версия 1.04<br />

8 сентября 2008 Стр. 23


Специфи<strong>к</strong>ации MoReq2<br />

помогают при разработ<strong>к</strong>е требований <strong>к</strong> фун<strong>к</strong>циональным возможностям систем, и поэтому<br />

здесь не рассматриваются.<br />

до<strong>к</strong>умент (record)<br />

Информация, созданная или полученная организацией или отдельным лицом, и<br />

сохраняемая в дальнейшем в <strong>к</strong>ачестве до<strong>к</strong>азательства и сведений, - для выполнения<br />

требований за<strong>к</strong>онодательства, или же в интересах деловой деятельности.<br />

Источни<strong>к</strong>: стандарт ISO 15489 (см. Приложение 7).<br />

Замечание: Могут та<strong>к</strong>же применяться национальные определения.<br />

Замечание: до<strong>к</strong>умент может в<strong>к</strong>лючать в себя один или нес<strong>к</strong>оль<strong>к</strong>о информационных<br />

материалов (например, <strong>к</strong>огда имеются приложения <strong>к</strong> одному из информационных<br />

материалов), и может быть на любом виде носителя и в любом формате. Ка<strong>к</strong> следствие,<br />

до<strong>к</strong>умент может состоять из одного или нес<strong>к</strong>оль<strong>к</strong>их <strong>к</strong>омпонентов. Желательно, чтобы, в<br />

дополнение <strong>к</strong> содержанию информационных материалов, до<strong>к</strong>умент та<strong>к</strong>же в<strong>к</strong>лючал<br />

<strong>к</strong>онте<strong>к</strong>стуальную информацию и, где это уместно, стру<strong>к</strong>турную информацию (например,<br />

информацию, описывающую <strong>к</strong>омпоненты до<strong>к</strong>умента). Ключевой особенностью до<strong>к</strong>умента<br />

является то, что его нельзя изменить.<br />

Замечание: СЭД способна управлять <strong>к</strong>а<strong>к</strong> эле<strong>к</strong>тронными до<strong>к</strong>ументами, та<strong>к</strong> и физичес<strong>к</strong>ими<br />

до<strong>к</strong>ументами.<br />

суб-дело (sub-file)<br />

Смысловая (логичес<strong>к</strong>ая) составная часть дела<br />

Замечание: суб-дела чаще всего используются при работе с досье. Обычно <strong>к</strong>аждое суб-дело<br />

имеет имя, и используется (в <strong>к</strong>аждом отдельном досье) для хранения до<strong>к</strong>ументов<br />

определенного вида (видов), - например, та<strong>к</strong>их, <strong>к</strong>а<strong>к</strong> «инвойсы», «результаты э<strong>к</strong>спертизы»<br />

или «<strong>к</strong>орреспонденция». Суб-дела, одна<strong>к</strong>о, могут та<strong>к</strong>же аналогичным образом<br />

использоваться и при управлении делами, не являющимися досье.<br />

том (volume)<br />

Составная часть суб-дела.<br />

Замечание: Тома создаются для улучшения управляемости содержимым суб-дел за счет<br />

разделения их на не слиш<strong>к</strong>ом большие по объему и поэтому более удобные в управлении<br />

части. Деление на тома чаще бывает механичес<strong>к</strong>ое (т.е. основывающееся на <strong>к</strong>оличестве<br />

до<strong>к</strong>ументов, или на диапазоне номеров либо дат), чем смысловое.<br />

2.2 Основные понятия<br />

Ключевыми понятиями, необходимыми для понимания настоящих Специфи<strong>к</strong>аций, являются:<br />

до<strong>к</strong>умент и эле<strong>к</strong>тронный до<strong>к</strong>умент;<br />

заслуживающий доверия («авторитетный») до<strong>к</strong>умент;<br />

эле<strong>к</strong>тронное дело, суб-дело и том;<br />

Версия 1.04<br />

8 сентября 2008 Стр. 24


Специфи<strong>к</strong>ации MoReq2<br />

<strong>к</strong>лассифи<strong>к</strong>ационная схема;<br />

рубри<strong>к</strong>а;<br />

СЭД;<br />

«захват» (ввод в систему) до<strong>к</strong>ументов;<br />

роли пользователей.<br />

До<strong>к</strong>умент и эле<strong>к</strong>тронный до<strong>к</strong>умент<br />

В ру<strong>к</strong>оводстве по наилучшей пра<strong>к</strong>ти<strong>к</strong>е управления эле<strong>к</strong>тронной информацией,<br />

подготовленное <strong>DLM</strong>-форумом (<strong>DLM</strong> <strong>Forum</strong> Guidelines on Best Practices for Electronic<br />

Information, 1997, п.2.4, - см. та<strong>к</strong>же Приложение 1) предлагается <strong>к</strong>онцепция, согласно<br />

<strong>к</strong>оторой до<strong>к</strong>умент представляет собой сово<strong>к</strong>упность:<br />

содержания (<strong>к</strong>онтента);<br />

стру<strong>к</strong>туры;<br />

<strong>к</strong>онте<strong>к</strong>ста, и<br />

представления (presentation) 18 .<br />

Содержание (<strong>к</strong>онтент) присутствует в одном или нес<strong>к</strong>оль<strong>к</strong>их физичес<strong>к</strong>их и/или эле<strong>к</strong>тронных<br />

информационных материалах, <strong>к</strong>оторые передают содержащееся в до<strong>к</strong>ументе<br />

информационное сообщение (информационный <strong>к</strong>онтент). Эти информационные материалы<br />

сохраняются та<strong>к</strong>им образом, чтобы будущим пользователям были понятны <strong>к</strong>а<strong>к</strong> они сами, та<strong>к</strong><br />

и их <strong>к</strong>онте<strong>к</strong>ст. Та<strong>к</strong>ая точ<strong>к</strong>а зрения подразумевает, что управляемый должным образом<br />

до<strong>к</strong>умент, в дополнение <strong>к</strong> содержанию входящих в его состав информационных материалов,<br />

та<strong>к</strong>же содержит сведения о своей стру<strong>к</strong>туре и метаданные, дающие информацию о его<br />

<strong>к</strong>онте<strong>к</strong>сте и о его представлении пользователям.<br />

В MoReq2, одна<strong>к</strong>о, термин «до<strong>к</strong>умент» используется для обозначения информационного<br />

<strong>к</strong>онтента – образующих до<strong>к</strong>умент информационных материалов, без метаданных.<br />

Представление до<strong>к</strong>умента зависит от его содержания, стру<strong>к</strong>туры и (в случае эле<strong>к</strong>тронных<br />

до<strong>к</strong>ументов) от программного обеспечения, используемого для по<strong>к</strong>аза до<strong>к</strong>умента (см.<br />

Глоссарий).<br />

В мире физичес<strong>к</strong>их до<strong>к</strong>ументов, подавляющее их большинство – бумажные до<strong>к</strong>ументы,<br />

<strong>к</strong>оторые формируются в дела, физичес<strong>к</strong>и состоящие из одного или нес<strong>к</strong>оль<strong>к</strong>их томов. Чтобы<br />

пользователи не могли вносить изменения в до<strong>к</strong>ументы или же изменять расположение<br />

до<strong>к</strong>ументов в деле, приходится использовать соответствующие процедуры и меры защиты.<br />

Похожие подходы применимы в отношении эле<strong>к</strong>тронных до<strong>к</strong>ументов. До<strong>к</strong>умент состоит из<br />

одного или нес<strong>к</strong>оль<strong>к</strong>их информационных материалов, <strong>к</strong>оторыми могут быть те<strong>к</strong>стовые<br />

материалы, сообщения эле<strong>к</strong>тронной почты, эле<strong>к</strong>тронные таблицы, изображения, видео- и<br />

аудиофайлы, и любые другие типы цифровых объе<strong>к</strong>тов. Информационные материалы<br />

становятся до<strong>к</strong>ументами тогда, <strong>к</strong>огда они «от<strong>к</strong>ладываются», т.е. «захватываются» и<br />

18<br />

В настоящее время, особенно в связи с динамичес<strong>к</strong>ими до<strong>к</strong>ументами, говорят ещё и о<br />

поведении (behaviour) (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 25


Специфи<strong>к</strong>ации MoReq2<br />

вводятся в СЭД. После ввода в СЭД до<strong>к</strong>ументы <strong>к</strong>лассифицируются - им присваиваются<br />

<strong>к</strong>оды, позволяющие СЭД управлять ими и соответствующие той рубри<strong>к</strong>е<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы, <strong>к</strong>оторой они принадлежат. До<strong>к</strong>ументы обычно (хотя и не всегда<br />

– см. ниже) помещаются в дела 19 .<br />

В плане обеспечения долговременной сохранности, необходимо принять во внимание, что<br />

многие эле<strong>к</strong>тронные до<strong>к</strong>ументы состоят из нес<strong>к</strong>оль<strong>к</strong>их <strong>к</strong>омпонент (термин «<strong>к</strong>омпонента»<br />

введен в MoReq2 для того, чтобы не использовать слово «файл» (file) из ле<strong>к</strong>си<strong>к</strong>она<br />

информационных технологий и уменьшить вероятность путаницы его с делопроизводчес<strong>к</strong>им<br />

термином «дело» (file)). Компоненты представляют собой объе<strong>к</strong>ты, управляемые<br />

операционной системой <strong>к</strong>омпьютера. Формат <strong>к</strong>омпонент может быть различным, но все они<br />

нужны, пос<strong>к</strong>оль<strong>к</strong>у толь<strong>к</strong>о вместе они составляют до<strong>к</strong>умент. Не все до<strong>к</strong>ументы состоят из<br />

нес<strong>к</strong>оль<strong>к</strong>их <strong>к</strong>омпонент: многие до<strong>к</strong>ументы состоят толь<strong>к</strong>о из одной <strong>к</strong>омпоненты – <strong>к</strong>а<strong>к</strong>,<br />

например, большинство те<strong>к</strong>стовых до<strong>к</strong>ументов. Примером до<strong>к</strong>умента, состоящего из<br />

нес<strong>к</strong>оль<strong>к</strong>их <strong>к</strong>омпонент, может служить веб-страница, содержащая те<strong>к</strong>ст, графи<strong>к</strong>у и стилевые<br />

таблицы. Часто веб-страница состоит из одной HTML-<strong>к</strong>омпоненты, десят<strong>к</strong>ов графичес<strong>к</strong>их<br />

изображений в формате JPEG и нес<strong>к</strong>оль<strong>к</strong>их стилевых таблиц CSS 20 .<br />

Важнейшей отличительной хара<strong>к</strong>теристи<strong>к</strong>ой до<strong>к</strong>ументов является неизменность их<br />

информационного <strong>к</strong>онтента. Вследствие этого, при выполнении с эле<strong>к</strong>тронными<br />

до<strong>к</strong>ументами <strong>к</strong>а<strong>к</strong>их-либо действий нельзя допус<strong>к</strong>ать, чтобы эти действия <strong>к</strong>а<strong>к</strong>-то повлияли на<br />

взаимосвязи между <strong>к</strong>омпонентами. Иначе говоря, при любых действиях с до<strong>к</strong>ументами<br />

должны сохраняться правильные взаимосвязи между всеми <strong>к</strong>омпонентами до<strong>к</strong>ументов.<br />

Поэтому, например, перемещение или <strong>к</strong>опирование до<strong>к</strong>умента должны выполняться та<strong>к</strong>,<br />

чтобы сохранились все его <strong>к</strong>омпоненты и все связи между ними.<br />

Заслуживающие доверия до<strong>к</strong>ументы (authoritative records)<br />

В стандарте ISO 15489 в <strong>к</strong>ачестве «заслуживающих доверия» («авторитетных») до<strong>к</strong>ументов<br />

рассматриваются до<strong>к</strong>ументы со следующими <strong>к</strong>ачествами:<br />

аутентичность;<br />

надёжность (достоверность);<br />

целостность;<br />

годность <strong>к</strong> использованию.<br />

Ка<strong>к</strong> объясняется в ISO 15489, целью всех систем управления до<strong>к</strong>ументами должно быть<br />

обеспечение того, чтобы хранимые в них до<strong>к</strong>ументы рассматривались <strong>к</strong>а<strong>к</strong> заслуживающие<br />

доверия. Суммируя, в отношении заслуживающих доверия до<strong>к</strong>ументов можно с<strong>к</strong>азать<br />

следующее:<br />

может быть до<strong>к</strong>азано, что они являются именно тем, чем претендуют быть;<br />

может быть до<strong>к</strong>азано, что они были созданы или посланы именно тем лицом, <strong>к</strong>оторое<br />

у<strong>к</strong>азано в <strong>к</strong>ачестве его создателя или отправителя;<br />

19<br />

20<br />

В оригинале используется формулиров<strong>к</strong>а "assigned to files" - "приписываются <strong>к</strong> делам", что<br />

точнее отражает тот фа<strong>к</strong>т, что на "физичес<strong>к</strong>ом уровне" дела и рубри<strong>к</strong>и СЭД, вообще говоря,<br />

ничего не содержат (см. последний абзац п.1.7) (прим. переводчи<strong>к</strong>а)<br />

Cascading Style Sheet – иерархичес<strong>к</strong>ая стилевая таблица (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 26


Специфи<strong>к</strong>ации MoReq2<br />

может быть до<strong>к</strong>азано, что они были созданы или посланы именно в у<strong>к</strong>азанное время;<br />

на них можно положиться, пос<strong>к</strong>оль<strong>к</strong>у можно верить, что их содержание полно и точно<br />

отражает те транза<strong>к</strong>ции, действия и фа<strong>к</strong>ты, о <strong>к</strong>оторых эти до<strong>к</strong>ументы свидетельствуют;<br />

они являются полными и неизменными;<br />

их можно найти, извлечь, представить и интерпретировать.<br />

Требования, содержащиеся в MoReq2, разработаны с целью обеспечить, чтобы до<strong>к</strong>ументы,<br />

сохраняемые в системах эле<strong>к</strong>тронного до<strong>к</strong>ументооборота, соответствующих <strong>требования</strong>м<br />

MoReq2, были заслуживающими доверия. Одна<strong>к</strong>о одного лишь соответствия настоящим<br />

<strong>требования</strong>м недостаточно; требуется та<strong>к</strong>же, чтобы были разработаны и строго<br />

исполнялись <strong>к</strong>орпоративные полити<strong>к</strong>и и регламенты.<br />

Эле<strong>к</strong>тронное дело, суб-дело и том<br />

Бумажные до<strong>к</strong>ументы обычно на<strong>к</strong>апливаются в «физичес<strong>к</strong>их» делах, <strong>к</strong>оторые представляют<br />

собой бумажные пап<strong>к</strong>и. Бумажные дела организованны в стру<strong>к</strong>туру – <strong>к</strong>лассифи<strong>к</strong>ационную<br />

схему.<br />

В СЭД эле<strong>к</strong>тронными до<strong>к</strong>ументами можно управлять та<strong>к</strong>им образом, <strong>к</strong>а<strong>к</strong> если бы они<br />

на<strong>к</strong>апливались в эле<strong>к</strong>тронных делах и хранились в эле<strong>к</strong>тронных пап<strong>к</strong>ах. Строго говоря,<br />

эле<strong>к</strong>тронные дела и пап<strong>к</strong>и не обязаны существовать в реальности; они являются<br />

виртуальными, - в том смысле, что они ничего в себе не «содержат». На самом деле они<br />

состоят из элементов метаданных приписанных <strong>к</strong> ним до<strong>к</strong>ументов.<br />

Далее, во многих случаях в эле<strong>к</strong>тронных системах нет нужды различать дело и пап<strong>к</strong>у.<br />

Одна<strong>к</strong>о та<strong>к</strong>ие детали обычно с<strong>к</strong>рыты от пользователей СЭД; программное обеспечение СЭД<br />

даёт возможность пользователям видеть и управлять пап<strong>к</strong>ами, <strong>к</strong>а<strong>к</strong> если бы они физичес<strong>к</strong>и<br />

содержали информационные материалы, логичес<strong>к</strong>и приписанные <strong>к</strong> делам. Подобная<br />

«пользовательс<strong>к</strong>ая» точ<strong>к</strong>а зрения используется в настоящих Специфи<strong>к</strong>ациях: для простоты,<br />

об эле<strong>к</strong>тронных делах в дальнейшем говорится та<strong>к</strong>, <strong>к</strong>а<strong>к</strong> если бы они действительно<br />

«содержали» в себе до<strong>к</strong>ументы.<br />

Следует иметь в виду, что хотя в настоящем до<strong>к</strong>ументе содержатся фун<strong>к</strong>циональные<br />

<strong>требования</strong> <strong>к</strong> <strong>управлению</strong> эле<strong>к</strong>тронными делами, он не предписывает <strong>к</strong>а<strong>к</strong>ого-либо<br />

определенного способа реализации <strong>к</strong>онцепции эле<strong>к</strong>тронного дела.<br />

В определенных случаях дела удобно подразделять на суб-дела. Суб-дела обычно<br />

используются для смысловой логичес<strong>к</strong>ой стру<strong>к</strong>туризации дела, и решение о том, в <strong>к</strong>а<strong>к</strong>ое<br />

суб-дело поместить до<strong>к</strong>умент (обычно) принимается челове<strong>к</strong>ом. Суб-дела чаще всего<br />

применяются при работе с досье; примером может служить досье по продаже земли, в<br />

<strong>к</strong>отором могут быть выделены суб-дела для <strong>к</strong>аждого из видов деловой деятельности,<br />

выполняемых в процессе продажи (та<strong>к</strong>их, <strong>к</strong>а<strong>к</strong> ре<strong>к</strong>лама, за<strong>к</strong>лючение <strong>к</strong>онтра<strong>к</strong>тов,<br />

взаимодействие с юристами, и т.д.).<br />

Суб-дела, та<strong>к</strong>им образом, используются для стру<strong>к</strong>туризации дела по типу <strong>к</strong>онтента. Ка<strong>к</strong><br />

следствие, суб-дела могут служить и для того, чтобы установить группам входящих в дело<br />

до<strong>к</strong>ументов свои сро<strong>к</strong>и хранения и инстру<strong>к</strong>ции в отношении их судьбы по истечении этих<br />

сро<strong>к</strong>ов.<br />

Независимо от наличия суб-дел, дела иногда «механичес<strong>к</strong>и» делятся на тома, в<br />

соответствии с заранее установленными соглашениями. Термин «механичес<strong>к</strong>и»<br />

Версия 1.04<br />

8 сентября 2008 Стр. 27


Специфи<strong>к</strong>ации MoReq2<br />

подразумевает простое исполнение подобных правил, основывающееся не на смысловом<br />

содержании дел, а на объёме и числе содержащихся в делах до<strong>к</strong>ументов, или на периодах<br />

времени. Подобная пра<strong>к</strong>ти<strong>к</strong>а возни<strong>к</strong>ла в бумажном делопроизводстве, с целью ограничить<br />

разумными пределами размер и вес папо<strong>к</strong> с до<strong>к</strong>ументами. Эту пра<strong>к</strong>ти<strong>к</strong>у можно продолжить в<br />

отношении эле<strong>к</strong>тронных дел, ограничивая их размер та<strong>к</strong>им образом, чтобы удобно было<br />

проводить их э<strong>к</strong>спертизу ценности, передачу и т.п. Она особенно подходит для управления<br />

делами, <strong>к</strong>оторые остаются от<strong>к</strong>рытыми в течение длительных периодов времени, и/или число<br />

до<strong>к</strong>ументов в <strong>к</strong>оторых становится большим.<br />

Если различие между делами и томами дел достаточно прозрачно, то последствия<br />

разделения дел на тома гораздо менее очевидны, пос<strong>к</strong>оль<strong>к</strong>у они зависят от <strong>к</strong>он<strong>к</strong>ретных<br />

потребностей и обстоятельств. Возможны следующие варианты:<br />

Дела за<strong>к</strong>рываются по истечении <strong>к</strong>онечного промежут<strong>к</strong>а времени, и основным объе<strong>к</strong>том<br />

управления является дело (даже если оно состоит из нес<strong>к</strong>оль<strong>к</strong>их томов). Примером<br />

может быть дело по определенной сравнительно небольшой за<strong>к</strong>уп<strong>к</strong>е, или дело по<br />

одному прое<strong>к</strong>ту;<br />

Дела могут оставаться от<strong>к</strong>рытыми в течение неограниченного (или почти<br />

неограниченного) периода времени, и, та<strong>к</strong>им образом, основным объе<strong>к</strong>том управления<br />

является том. Примерами могут служить: дело, в<strong>к</strong>лючающее в себя до<strong>к</strong>ументы,<br />

относящиеся <strong>к</strong> определенной географичес<strong>к</strong>ой области; дело по вопросу, не зависящему<br />

от времени (та<strong>к</strong>ому, <strong>к</strong>а<strong>к</strong> разработ<strong>к</strong>а и а<strong>к</strong>туализация не<strong>к</strong>оторых видов полити<strong>к</strong> и<br />

регламентов); или дело, содержащее счета, в <strong>к</strong>отором новый том от<strong>к</strong>рывается в начале<br />

<strong>к</strong>аждого года.<br />

В достаточно ред<strong>к</strong>их случаях, до<strong>к</strong>ументы могут храниться вне дел – путем размещения их в<br />

рубри<strong>к</strong>ах, см. объяснения в разделе 3.2.17.<br />

Классифи<strong>к</strong>ационная схема<br />

В ходе управления до<strong>к</strong>ументами дела объединяются в определенную стру<strong>к</strong>туру, и хорошая<br />

деловая пра<strong>к</strong>ти<strong>к</strong>а требует, чтобы эта стру<strong>к</strong>тура отражала деловые фун<strong>к</strong>ции. Схема,<br />

описывающая эту стру<strong>к</strong>туру дел, называется <strong>к</strong>лассифи<strong>к</strong>ационной схемой. Обычно<br />

<strong>к</strong>лассифи<strong>к</strong>ационная схема представляет собой иерархичес<strong>к</strong>ую стру<strong>к</strong>туру 21 . Дальнейшая<br />

часть MoReq2 использует «иерархичес<strong>к</strong>ий» подход; другие подходы <strong>к</strong> построению<br />

<strong>к</strong>лассифи<strong>к</strong>ационных схем в MoReq2 не рассматриваются, и иерархичес<strong>к</strong>ая стру<strong>к</strong>тура<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы является необходимым условием для соответствия <strong>требования</strong>м<br />

MoReq2..<br />

Та<strong>к</strong> же <strong>к</strong>а<strong>к</strong> <strong>к</strong>ажется, что дела существуют «на самом деле», в то время, <strong>к</strong>а<strong>к</strong> в<br />

действительности они являются не более чем объединениями (наборами) до<strong>к</strong>ументов, -<br />

та<strong>к</strong>же и более высо<strong>к</strong>ие уровни иерархии в <strong>к</strong>лассифи<strong>к</strong>ационной схеме (рубри<strong>к</strong>и) <strong>к</strong>ажутся<br />

реально существующими, хотя в действительности они есть лишь объединение дел и/или<br />

рубри<strong>к</strong> низшего уровня. Ка<strong>к</strong> и в случае эле<strong>к</strong>тронных дел, в Специфи<strong>к</strong>ациях сформулированы<br />

<strong>требования</strong> <strong>к</strong> иерархичес<strong>к</strong>ой <strong>к</strong>лассифи<strong>к</strong>ационной схеме, но не предписывается <strong>к</strong>а<strong>к</strong>ой-либо<br />

определенный способ её пра<strong>к</strong>тичес<strong>к</strong>ой реализации.<br />

21<br />

На пра<strong>к</strong>ти<strong>к</strong>е иногда используются неиерархичес<strong>к</strong>ие варианты построения <strong>к</strong>лассифи<strong>к</strong>ационных<br />

схем, - например, на основе <strong>к</strong>лючевых слов и тезаурусов. Неиерархичес<strong>к</strong>ие подходы имеют<br />

свои достоинства, и первоначальная реда<strong>к</strong>ция специфи<strong>к</strong>аций MoReq2 даже содержала<br />

специальный раздел, посвященный <strong>к</strong>лассифи<strong>к</strong>ационным схемам та<strong>к</strong>ого рода. (прим.<br />

переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 28


Специфи<strong>к</strong>ации MoReq2<br />

Рис. 2.1<br />

Дела могут появляться в рубри<strong>к</strong>ах любого уровня иерархичес<strong>к</strong>ой стру<strong>к</strong>туры. Это<br />

иллюстрирует приведенная на рис. 2.1 диаграмма, на <strong>к</strong>оторой по<strong>к</strong>азана гипотетичес<strong>к</strong>ая<br />

<strong>к</strong>лассифи<strong>к</strong>ационная схема и её рубри<strong>к</strong>и, - причем дела размещаются толь<strong>к</strong>о в рубри<strong>к</strong>ах, не<br />

имеющих подрубри<strong>к</strong>. Эта гипотетичес<strong>к</strong>ая схема, разумеется, намного проще по сравнению с<br />

реальными <strong>к</strong>лассифи<strong>к</strong>ационными схемами.<br />

Следует иметь в виду, что данный рисуно<strong>к</strong> лишь иллюстрирует не<strong>к</strong>оторые возможные<br />

взаимосвязи между рубри<strong>к</strong>ами, делами и до<strong>к</strong>ументами, и не по<strong>к</strong>азывает всех возможных<br />

уровней рубри<strong>к</strong>ации и всех возможных <strong>к</strong>онфигураций.<br />

Рубри<strong>к</strong>а<br />

В MoReq2 термин «рубри<strong>к</strong>а» 22 используется для описания части иерархичес<strong>к</strong>ой стру<strong>к</strong>туры,<br />

представляемой линией, идущей от определенной точ<strong>к</strong>и в иерархичес<strong>к</strong>ой стру<strong>к</strong>туре <strong>к</strong>о всем<br />

нижележащим делам. Та<strong>к</strong>им образом, «рубри<strong>к</strong>а» соответствует используемым в ряде<br />

публи<strong>к</strong>аций терминам «группа» (group) и «серия» (series) (а та<strong>к</strong>же подгруппа, суб-серия и<br />

т.д.).<br />

Визуально рубри<strong>к</strong>а иерархичес<strong>к</strong>ой <strong>к</strong>лассифи<strong>к</strong>ационной схемы соответствует ветви<br />

«дерева». Та<strong>к</strong>им образом, рубри<strong>к</strong>а может содержать другие рубри<strong>к</strong>и (подрубри<strong>к</strong>и), подобно<br />

тому, <strong>к</strong>а<strong>к</strong> серии могут содержать суб-серии и суб-суб-серии. Продолжая начатый выше<br />

пример, на приведенной на рис. 2.2 диаграмме рубри<strong>к</strong>а по<strong>к</strong>азана при помощи затенённых<br />

бло<strong>к</strong>ов и толстых линий.<br />

22<br />

Т.е. данный термин используется в значении «рубри<strong>к</strong>а вместе со всеми её подрубри<strong>к</strong>ами»<br />

(прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 29


Специфи<strong>к</strong>ации MoReq2<br />

Классифи<strong>к</strong>ационная схема<br />

Рубри<strong>к</strong>а<br />

Рубри<strong>к</strong>а<br />

Рубри<strong>к</strong>а<br />

Рубри<strong>к</strong>а<br />

Рубри<strong>к</strong>а<br />

Рубри<strong>к</strong>а Рубри<strong>к</strong>а Рубри<strong>к</strong>а<br />

Рубри<strong>к</strong>а<br />

Рубри<strong>к</strong>а<br />

Дело<br />

Дело<br />

Дело<br />

Рубри<strong>к</strong>а<br />

Рубри<strong>к</strong>а<br />

Рубри<strong>к</strong>а<br />

Дело<br />

Рубри<strong>к</strong>а<br />

Дело<br />

Дело<br />

Дело<br />

Дело<br />

Class<br />

Рубри<strong>к</strong>а<br />

Дело<br />

Рис. 2.2<br />

В MoReq2 термин «рубри<strong>к</strong>а» та<strong>к</strong>же используется для обозначения всех дел, до<strong>к</strong>ументов и<br />

т.д., связанных с рубри<strong>к</strong>ой – та<strong>к</strong> же, <strong>к</strong>а<strong>к</strong> слово «бутыл<strong>к</strong>а» может быть использовано для<br />

обозначения <strong>к</strong>а<strong>к</strong> одной толь<strong>к</strong>о ем<strong>к</strong>ости, та<strong>к</strong> и ем<strong>к</strong>ости вместе с содержащейся в ней<br />

жид<strong>к</strong>остью. Та<strong>к</strong>ая «перегруз<strong>к</strong>а» термина делается умышленно, а соответствующее его<br />

тол<strong>к</strong>ование всегда ясно из <strong>к</strong>онте<strong>к</strong>ста.<br />

В MoReq2 термины «предо<strong>к</strong>» (parent) и «потомо<strong>к</strong>» (child) используются для описания<br />

взаимосвязей между объе<strong>к</strong>тами СЭД. Потомо<strong>к</strong> объе<strong>к</strong>та – это объе<strong>к</strong>т, расположенный ниже<br />

данного объе<strong>к</strong>та в иерархичес<strong>к</strong>ой стру<strong>к</strong>туре Предо<strong>к</strong> объе<strong>к</strong>та – объе<strong>к</strong>т, расположенный<br />

выше в иерархичес<strong>к</strong>ой стру<strong>к</strong>туре. Та<strong>к</strong>им образом, потом<strong>к</strong>ами рубри<strong>к</strong> могут быть другие<br />

рубри<strong>к</strong>и, дела или (в ред<strong>к</strong>их случаях) до<strong>к</strong>ументы. 23<br />

В MoReq2 допус<strong>к</strong>ается при<strong>к</strong>репление до<strong>к</strong>ументов <strong>к</strong> рубри<strong>к</strong>ам (иначе говоря, хранение их<br />

непосредственно в рубри<strong>к</strong>ах), вне дел. Та<strong>к</strong>ая возможность предусмотрена на случай<br />

довольно ред<strong>к</strong>их обстоятельств, <strong>к</strong>оторые описаны в те<strong>к</strong>сте MoReq2.<br />

Система эле<strong>к</strong>тронного до<strong>к</strong>ументооборота, СЭД (ERMS)<br />

СЭД – это в первую очередь программное приложение для управления эле<strong>к</strong>тронными<br />

до<strong>к</strong>ументами, хотя оно та<strong>к</strong>же может использоваться и для управления физичес<strong>к</strong>ими<br />

до<strong>к</strong>ументами.<br />

СЭД часто тесно интегрирована либо с соответствующей эле<strong>к</strong>тронно-информационной<br />

системой, ЭИС (Electronic Document Management System, EDMS), либо с деловым<br />

программным приложением. Техничес<strong>к</strong>и, СЭД управляет до<strong>к</strong>ументами, в то время <strong>к</strong>а<strong>к</strong> ЭИС<br />

управляет информационными материалами, не имеющими статуса до<strong>к</strong>умента. Одна<strong>к</strong>о<br />

разделить фун<strong>к</strong>циональные возможности ЭИС и СЭД довольно сложно, особенно в<br />

повседневной работе. Это вопрос подробнее рассматривается в разделе 10.3, посвященном<br />

вопросам управления информационными материалами (Document Management).<br />

23<br />

С<strong>к</strong>азанное означает, что при использовании этих терминов игнорируется внутренняя<br />

стру<strong>к</strong>тура дел – не учитываются суб-дела и тома, и принимаются во внимание толь<strong>к</strong>о те<br />

до<strong>к</strong>ументы, <strong>к</strong>оторые размещены непосредственно в рубри<strong>к</strong>ах, вне дел. (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 30


Специфи<strong>к</strong>ации MoReq2<br />

Ввод («захват») до<strong>к</strong>ументов в систему<br />

Информационные материалы, созданные или полученные в ходе деловой деятельности,<br />

становятся до<strong>к</strong>ументами тогда, <strong>к</strong>огда они «от<strong>к</strong>ладываются», т.е. «захватываются» и<br />

вводятся в СЭД. В процессе ввода в СЭД до<strong>к</strong>ументы «<strong>к</strong>лассифицируются» - им<br />

присваиваются <strong>к</strong>оды, позволяющие СЭД управлять ими и соответствующие той рубри<strong>к</strong>е<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы, <strong>к</strong>оторой они принадлежат. Им та<strong>к</strong>же присваивается уни<strong>к</strong>альный<br />

идентифи<strong>к</strong>атор.<br />

Во многих случаях информационные материалы, <strong>к</strong>оторые захватываются в СЭД, становятся<br />

до<strong>к</strong>ументами ввиду их связи с деловым процессом, - <strong>к</strong>а<strong>к</strong>, например, часто происходит при<br />

использовании средств автоматизации деловых процессов (workflow). Например, <strong>к</strong>огда<br />

выставляется инвойс, то это событие должно автоматичес<strong>к</strong>и приводить в «захвату»<br />

соответствующего до<strong>к</strong>умента.<br />

В других случаях соответствующая полити<strong>к</strong>а (регламент) может предусматривать, что<br />

вся<strong>к</strong>ий информационный материал, относящийся <strong>к</strong> определенному деловому вопросу,<br />

должен стать до<strong>к</strong>ументом, даже если формально он и не участвует в деловом процессе.<br />

При иных обстоятельствах процесс ввода выборочно инициируется пользователем.<br />

Решения о том, <strong>к</strong>а<strong>к</strong>ие информационные материалы должны быть введены в систему<br />

эле<strong>к</strong>тронного до<strong>к</strong>ументооборота, должно основываться на анализе за<strong>к</strong>онодательнонормативной<br />

среды, на потребностях деловой деятельности и <strong>требования</strong>х <strong>к</strong> обеспечению<br />

подотчётности, а та<strong>к</strong>же на анализе рис<strong>к</strong>ов, связанных с несохранением соответствующих<br />

до<strong>к</strong>ументов.<br />

Примером может служить выпущенный организацией меморандум, в <strong>к</strong>отором<br />

рассматриваются вопросы, связанные с полити<strong>к</strong>ой организации. Организация может<br />

решить, что до<strong>к</strong>ументами становятся толь<strong>к</strong>о меморандумы, имеющие существенное<br />

значение (т.е. что незначащие меморандумы, например, те, что связаны с организацией<br />

встреч, обычно до<strong>к</strong>ументами не становятся).<br />

В одних обстоятельствах прое<strong>к</strong>там до<strong>к</strong>ументов (drafts) будет придаваться достаточное<br />

значение, чтобы сохранять их <strong>к</strong>а<strong>к</strong> до<strong>к</strong>ументы, - в то время, <strong>к</strong>а<strong>к</strong> в иных ситуациях прое<strong>к</strong>ты<br />

до<strong>к</strong>ументов до<strong>к</strong>ументами считаться не будут.<br />

Данные <strong>требования</strong> разработаны та<strong>к</strong>им образом, чтобы охватить все эти сценарии. Иными<br />

словами, <strong>требования</strong> MoReq2 описывают офисную систему общего пользования, а не<br />

уз<strong>к</strong>оспециализированную (либо предназначенную ис<strong>к</strong>лючительно для использования<br />

архивистами и администраторами) систему управления до<strong>к</strong>ументами.<br />

Пользовательс<strong>к</strong>ие и административные роли<br />

В MoReq2 понятие «пользователь» означает любое лицо, имеющее за<strong>к</strong>онное право<br />

использовать СЭД. Та<strong>к</strong>им образом, пользователями является все, <strong>к</strong>ому разрешено входить<br />

в СЭД, - в<strong>к</strong>лючая администраторов. Одна<strong>к</strong>о провести грань между администраторами и<br />

другими пользователями порой достаточно сложно, и она может о<strong>к</strong>азаться размытой. В<br />

связи с этим при формулировании многих требований в MoReq2 используется <strong>к</strong>онцепция<br />

«ролей».<br />

Различные организации внедряют СЭД по-разному. Например, небольшой организации при<br />

внедрении СЭД достаточно иметь одного администратора, - в то время, <strong>к</strong>а<strong>к</strong> <strong>к</strong>рупной<br />

организации может потребоваться нес<strong>к</strong>оль<strong>к</strong>о различных административных должностей, для<br />

Версия 1.04<br />

8 сентября 2008 Стр. 31


Специфи<strong>к</strong>ации MoReq2<br />

<strong>к</strong>аждой из <strong>к</strong>оторых будут определены свои права доступа. По этой причине в данных<br />

типовых <strong>требования</strong>х нет смысла специфицировать <strong>к</strong>он<strong>к</strong>ретные профили доступа; вместо<br />

этого в MoReq2 используется <strong>к</strong>онцепция «ролей».<br />

В MoReq2 выделяются два вида ролей: «пользовательс<strong>к</strong>ие роли» и «административные<br />

роли». На пра<strong>к</strong>ти<strong>к</strong>е в большинстве организаций в <strong>к</strong>аждой из этих ролей выступает ряд лиц; а<br />

многие организации определяют дополнительные роли. Примерные роли, с у<strong>к</strong>азанием<br />

возможных прав доступа, описаны в матрице доступа в разделе 13.4.<br />

Та<strong>к</strong>им образом, «роль» в MoReq2 напоминает профиль пользователя – это не должность и<br />

не вид выполняемой работы, а «набор», в <strong>к</strong>оторый входят ответственность и права на<br />

использование фун<strong>к</strong>циональных возможностей, разделяемые нес<strong>к</strong>оль<strong>к</strong>ими пользователями.<br />

В MoReq2 выделяются, в <strong>к</strong>ачестве примера, две административные и две<br />

пользовательс<strong>к</strong>ие роли.<br />

Исполнители административных ролей выполняют действия, относящиеся <strong>к</strong> <strong>управлению</strong><br />

самими до<strong>к</strong>ументами; они более заинтересованы в управлении до<strong>к</strong>ументами <strong>к</strong>а<strong>к</strong> объе<strong>к</strong>тами,<br />

чем в содержании до<strong>к</strong>ументов или в соответствующем деловом <strong>к</strong>онте<strong>к</strong>сте. В их обязанности<br />

та<strong>к</strong>же может входить управление относящимся <strong>к</strong> СЭД оборудованием, программным<br />

обеспечением и системой хранения, выполнение резервного <strong>к</strong>опирования и обеспечение<br />

производительности СЭД.<br />

В отличие от исполнителей административных ролей, исполнители пользовательс<strong>к</strong>их ролей<br />

имеют доступ толь<strong>к</strong>о <strong>к</strong> тем фун<strong>к</strong>циональным возможностям (в число <strong>к</strong>оторых входят<br />

добавление, поис<strong>к</strong> и извлечение до<strong>к</strong>ументов), <strong>к</strong>оторые нужны сотрудни<strong>к</strong>у офиса и<br />

исследователю при работе с до<strong>к</strong>ументами. Они больше заинтересованы в содержании<br />

до<strong>к</strong>ументов, чем в управлении ими, - иными словами, они заинтересованы в деловых<br />

процессах, свидетельством выполнения <strong>к</strong>оторых являются до<strong>к</strong>ументы.<br />

2.3 Модель взаимосвязей между объе<strong>к</strong>тами СЭД<br />

В данном разделе на рис. 2.5 представлена модель взаимосвязей между объе<strong>к</strong>тами СЭД,<br />

<strong>к</strong>оторую можно использовать в <strong>к</strong>ачестве справочного материала, помогающего понять<br />

Специфи<strong>к</strong>ации. Раздел 13.3 содержит <strong>к</strong>рат<strong>к</strong>ое описание и объяснение этой модели.<br />

Существенной особенностью этой модели является то, что она не предназначена для<br />

иллюстрации тех стру<strong>к</strong>тур хранения данных, <strong>к</strong>оторые на самом деле используются в<br />

реальных СЭД. Модель отражает теоретичес<strong>к</strong>ое представление о взаимосвязях<br />

ассоциированных с до<strong>к</strong>ументами объе<strong>к</strong>тов СЭД. Система эле<strong>к</strong>тронного до<strong>к</strong>ументооборота<br />

использует эти связи для управления до<strong>к</strong>ументами та<strong>к</strong>им образом, <strong>к</strong>а<strong>к</strong> если бы по<strong>к</strong>азанная<br />

на диаграмме стру<strong>к</strong>тура реально существовала. Подробнее этот вопрос освещён в разделе<br />

2.2.<br />

На приведенной на рис. 2.5 модели по<strong>к</strong>азаны взаимосвязи между следующими <strong>к</strong>лючевыми<br />

объе<strong>к</strong>тами СЭД::<br />

Рубри<strong>к</strong>а;<br />

Дело;<br />

Суб-дело;<br />

Том;<br />

Версия 1.04<br />

8 сентября 2008 Стр. 32


Специфи<strong>к</strong>ации MoReq2<br />

До<strong>к</strong>умент;<br />

Компонента.<br />

Модель в<strong>к</strong>лючает и ряд других объе<strong>к</strong>тов<br />

Объе<strong>к</strong>ты СЭД – дела, до<strong>к</strong>ументы и т.д. – по<strong>к</strong>азаны на диаграмме прямоугольни<strong>к</strong>ами. Линии,<br />

соединяющие прямоугольни<strong>к</strong>и, по<strong>к</strong>азывают взаимосвязи между объе<strong>к</strong>тами. Каждая связь<br />

снабжена описанием, расположенным на середине линии, и соответствующий те<strong>к</strong>ст следует<br />

читать в направлении, у<strong>к</strong>азанном стрел<strong>к</strong>ой. На <strong>к</strong>аждом <strong>к</strong>онце связи у<strong>к</strong>азана мощность связи<br />

(cardinality), см. бло<strong>к</strong> «Обозначения» на диаграмме.<br />

Например, приведенный на рис.2.3 фрагмент означает: «один до<strong>к</strong>умент состоит из одной<br />

или нес<strong>к</strong>оль<strong>к</strong>их <strong>к</strong>омпонент» (обратите внимание на направление связи, обозначенное<br />

стрел<strong>к</strong>ой).<br />

Рис. 2.3<br />

Дуга, пересе<strong>к</strong>ающая две и более линии, в <strong>к</strong>аждом случае обозначает взаимоис<strong>к</strong>лючающие<br />

взаимосвязи. Например, дуга на рис.2.4 означает, что «<strong>к</strong>аждый до<strong>к</strong>умент сохраняется либо в<br />

томе, либо в суб-деле – но не в том и другом одновременно».<br />

До<strong>к</strong>умент<br />

0 -<br />

*<br />

0 -<br />

*<br />

СОХРАНЯЕТСЯ В<br />

<br />

1<br />

Том<br />

1<br />

Суб-дело<br />

Рис. 2.4<br />

Следует обратить внимание, что объе<strong>к</strong>т «Рубри<strong>к</strong>а» связан сам с собой связью «состоит из».<br />

Та<strong>к</strong>ая ре<strong>к</strong>урсивная связь формально описывает взаимосвязи между рубри<strong>к</strong>ами в<br />

иерархичес<strong>к</strong>ой <strong>к</strong>лассифи<strong>к</strong>ационной схеме, в <strong>к</strong>оторой рубри<strong>к</strong>а может содержать одну или<br />

нес<strong>к</strong>оль<strong>к</strong>о подрубри<strong>к</strong>. Если эту ре<strong>к</strong>урсивную связь убрать, то полученная модель будет<br />

равно применимой и <strong>к</strong> неиерархичес<strong>к</strong>им <strong>к</strong>лассифи<strong>к</strong>ационным схемам.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 33


Специфи<strong>к</strong>ации MoReq2<br />

В оставшейся части MoReq2 термины из Глоссария выделяются жирным синим шрифтом<br />

при первом их употреблении. В эле<strong>к</strong>тронной версии Специфи<strong>к</strong>аций - это гиперссыл<strong>к</strong>а,<br />

ведущая <strong>к</strong> определению, и при щелч<strong>к</strong>е мышью по та<strong>к</strong>ому термину с одновременным<br />

удерживанием <strong>к</strong>лавиши CTRL происходит переход <strong>к</strong> определению в Глоссарии. То же<br />

действие в Глоссарии возвращает пользователя обратно <strong>к</strong> термину в те<strong>к</strong>сте.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 34


Специфи<strong>к</strong>ации MoReq2<br />

Классифи<strong>к</strong>ационная схема<br />

1<br />

CONTAINS<br />

СОДЕРЖИТ<br />

0 -<br />

*<br />

СОСТОИТ ИЗ<br />

1 -<br />

*<br />

Рубри<strong>к</strong>а<br />

11<br />

1<br />

1 -<br />

*<br />

MAY МОЖЕТ<br />

CONTAIN СОДЕРЖАТЬ<br />

0 -<br />

*<br />

Дело<br />

1 -<br />

*<br />

1 -<br />

*<br />

ПРИМЕНИМ<br />

К<br />

Сро<strong>к</strong><br />

Хранения<br />

0 - 1<br />

1 1 1<br />

МОЖЕТ<br />

MAY BE<br />

ДЕЛИТЬСЯ DIVIDED<br />

INTO НА<br />

0 -<br />

*<br />

Суб-дело<br />

1 1<br />

МОЖЕТ<br />

MAY BE<br />

ДЕЛИТЬСЯ DIVIDED<br />

НА INTO<br />

МОЖЕТ<br />

MAY BE<br />

ДЕЛИТЬСЯ DIVIDED<br />

INTO НА<br />

1 -<br />

*<br />

<br />

ПРИМЕНИМ<br />

К<br />

Тип информ.<br />

материала<br />

1<br />

0 -<br />

*<br />

0 -<br />

*<br />

Том<br />

1<br />

1 -<br />

*<br />

ИМЕЕТ<br />

1 -<br />

*<br />

Информационный<br />

материал<br />

1<br />

СОСТОИТ<br />

ИЗ<br />

0 -<br />

*<br />

1 -<br />

*<br />

1 -<br />

*<br />

ФОРМИРУЕТСЯ<br />

ИЗ<br />

IS ХРАНИТСЯ STORED IN В<br />

До<strong>к</strong>умент<br />

1<br />

<br />

СОСТОИТ<br />

ИЗ<br />

1 -<br />

*<br />

1 -<br />

*<br />

ИМЕЕТ<br />

1<br />

1 -<br />

*<br />

Тип<br />

До<strong>к</strong>умента<br />

Обозначения:<br />

1 -<br />

*<br />

1 -<br />

*<br />

Компонента<br />

Ноль<br />

Ноль или<br />

1 Ровно один 0 – 1 0 - * 1 - *<br />

или один нес<strong>к</strong>оль<strong>к</strong>о<br />

Рис. 2.5<br />

Один или<br />

нес<strong>к</strong>оль<strong>к</strong>о<br />

Ис<strong>к</strong>лючающее<br />

ИЛИ<br />

Версия 1.04<br />

8 сентября 2008 Стр. 35


Специфи<strong>к</strong>ации MoReq2<br />

3. КЛАССИФИКАЦИОННАЯ СХЕМА И УПОРЯДОЧИВАНИЕ ДЕЛ<br />

В данной главе перечислены <strong>требования</strong> <strong>к</strong> ведению <strong>к</strong>лассифи<strong>к</strong>ационной схемы и <strong>к</strong><br />

упорядочиванию дел (organisation of files). Сначала приводятся <strong>требования</strong>, относящиеся <strong>к</strong><br />

разработ<strong>к</strong>е и настрой<strong>к</strong>е <strong>к</strong>лассифи<strong>к</strong>ационной схемы (см. раздел 3.1). Затем идут <strong>требования</strong><br />

<strong>к</strong> рубри<strong>к</strong>ам и делам (раздел 3.2), томам и суб-делам (раздел 3.3). В разделе 3.4<br />

перечислены <strong>требования</strong>, связанные с ведением <strong>к</strong>лассифи<strong>к</strong>ационной схемы.<br />

Классифи<strong>к</strong>ационная схема является основой СЭД. Она даёт возможность сохранить<br />

эле<strong>к</strong>тронный до<strong>к</strong>умент вместе с другими до<strong>к</strong>ументами, <strong>к</strong>оторые составляют его <strong>к</strong>онте<strong>к</strong>ст,<br />

пос<strong>к</strong>оль<strong>к</strong>у она определяет, <strong>к</strong>а<strong>к</strong>им образом эле<strong>к</strong>тронные до<strong>к</strong>ументы будут формироваться в<br />

эле<strong>к</strong>тронные дела, а та<strong>к</strong>же связи между делами.<br />

Существенным отличием MoReq2 от его предшественни<strong>к</strong>а MoReq является то, что MoReq2<br />

допус<strong>к</strong>ает помещение до<strong>к</strong>умента <strong>к</strong>а<strong>к</strong> в дело, та<strong>к</strong> и непосредственно в рубри<strong>к</strong>у. В MoReq<br />

размещение до<strong>к</strong>ументов непосредственно в рубри<strong>к</strong>е не разрешалось, и допус<strong>к</strong>алось лишь<br />

их помещение в дела.<br />

Та<strong>к</strong>им образом, MoReq2 допус<strong>к</strong>ает ввод и помещение до<strong>к</strong>умента в любой из следующих<br />

объе<strong>к</strong>тов:<br />

Рубри<strong>к</strong>а;<br />

Дело;<br />

Суб-дело;<br />

Том.<br />

В большинстве случаев до<strong>к</strong>ументы помещаются в тома, что подразумевает их помещение<br />

та<strong>к</strong>же и в дела и суб-дела, см. разделы 3.3.1, 3.3.2 и 3.3.3.<br />

Рис. 3.1<br />

Версия 1.04<br />

8 сентября 2008 Стр. 36


Специфи<strong>к</strong>ации MoReq2<br />

Ввод до<strong>к</strong>ументов непосредственно в рубри<strong>к</strong>и проиллюстрирован на рис.3.1, на <strong>к</strong>оторой<br />

подобные до<strong>к</strong>ументы (выделены серым цветом) добавлены <strong>к</strong> в одну из рубри<strong>к</strong>, по<strong>к</strong>азных на<br />

рис. 2.1.<br />

Эти изменения были введены главным образом для того, чтобы отразить потребности<br />

систем, управляющих большим <strong>к</strong>оличеством досье. Они, одна<strong>к</strong>о, не нацелены на то, чтобы<br />

умалить значение иерархичес<strong>к</strong>ой <strong>к</strong>лассифи<strong>к</strong>ационной схемы и существования дел.<br />

Непродуманное использование новых возможностей чревато появлением впоследствии<br />

проблем в управлении до<strong>к</strong>ументами, поэтому пользователям MoReq2 ре<strong>к</strong>омендуется<br />

применять эти фун<strong>к</strong>циональные возможности толь<strong>к</strong>о по итогам тщательного анализа.<br />

Пос<strong>к</strong>оль<strong>к</strong>у эти фун<strong>к</strong>циональные возможности большинству пользователей MoReq2 вряд ли<br />

<strong>к</strong>огда-либо понадобятся, в Специфи<strong>к</strong>ациях есть требование о том, чтобы их можно было<br />

от<strong>к</strong>лючать.<br />

Для соответствия <strong>требования</strong>м MoReq2 необходима поддерж<strong>к</strong>а иерархичес<strong>к</strong>ой<br />

<strong>к</strong>лассифи<strong>к</strong>ации, пос<strong>к</strong>оль<strong>к</strong>у:<br />

иерархичес<strong>к</strong>ие <strong>к</strong>лассифи<strong>к</strong>ационные схемы способны обеспечить эффе<strong>к</strong>тивную,<br />

устойчивую и понятную стру<strong>к</strong>туризацию до<strong>к</strong>ументов;<br />

в Европе наиболее широ<strong>к</strong>о используются именно иерархичес<strong>к</strong>ие <strong>к</strong>лассифи<strong>к</strong>ационные<br />

схемы.<br />

Кроме того, поддерживается совместимость с предшествующей версией MoReq. Во многих<br />

<strong>требования</strong>х используется понятие «рубри<strong>к</strong>а». Часто подобные <strong>требования</strong> могут быть<br />

применимы и в отношении неиерархичес<strong>к</strong>их <strong>к</strong>лассифи<strong>к</strong>ационных схем; но не всегда это<br />

может о<strong>к</strong>азаться возможным.<br />

Очень важно, чтобы <strong>к</strong>лассифи<strong>к</strong>ационная схема (техничес<strong>к</strong>и, <strong>к</strong>лассифи<strong>к</strong>ационная схема для<br />

до<strong>к</strong>ументов) была тесно увязана с деловыми потребностями организации. Хорошая<br />

пра<strong>к</strong>ти<strong>к</strong>а предполагает, что организация сначала определяет <strong>к</strong>лассифи<strong>к</strong>ационную схему<br />

своей деловой деятельности, а уже затем приступает <strong>к</strong> разработ<strong>к</strong>е <strong>к</strong>лассифи<strong>к</strong>ационной<br />

схемы для до<strong>к</strong>ументов.<br />

3.1 Настрой<strong>к</strong>а <strong>к</strong>лассифи<strong>к</strong>ационной схемы<br />

№ Требование Тест.<br />

3.1.1 СЭД должна поддерживать и быть совместимой с <strong>к</strong>лассифи<strong>к</strong>ационной<br />

схемой деловой деятельности, используемой в организации.<br />

N<br />

Это требование, в общем случае, непроверяемое; оно в<strong>к</strong>лючено в<br />

<strong>к</strong>ачестве напоминания пользователям MoReq2 о необходимости<br />

согласовать используемую в СЭД <strong>к</strong>лассифи<strong>к</strong>ационную схему с<br />

деловыми потребностями организации. Желательно, чтобы эти<br />

деловые потребности та<strong>к</strong>же нашли свое отражение в стру<strong>к</strong>туре<br />

до<strong>к</strong>ументов, внешних по отношению <strong>к</strong> СЭД.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 37


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

3.1.2 СЭД должна постоянно поддерживать свою внутреннюю целостность<br />

(ссылочную целостность и т.д.), вне зависимости от:<br />

P<br />

действий, связанных с техничес<strong>к</strong>им обслуживанием системы;<br />

действий пользователей;<br />

сбоев и от<strong>к</strong>азов <strong>к</strong>омпонент системы.<br />

Иными словами, должно быть ис<strong>к</strong>лючено возни<strong>к</strong>новение та<strong>к</strong>их<br />

ситуаций, в <strong>к</strong>оторых <strong>к</strong>а<strong>к</strong>ие-либо действия пользователей или сбои в<br />

работе программного обеспечения приводили бы <strong>к</strong><br />

несогласованностям внутри СЭД или её в базе данных.<br />

3.1.3 Желательно, чтобы СЭД давала возможность исполнителям<br />

административных ролей снабжать <strong>к</strong>аждую из <strong>к</strong>лассифи<strong>к</strong>ационных<br />

схем Названием и Описанием; СЭД должна автоматичес<strong>к</strong>и присваивать<br />

<strong>к</strong>аждой <strong>к</strong>лассифи<strong>к</strong>ационной схеме Идентифи<strong>к</strong>атор.<br />

Y<br />

Эти метаданные будут использоваться при выполнении та<strong>к</strong>их<br />

фун<strong>к</strong>ций, <strong>к</strong>а<strong>к</strong> э<strong>к</strong>спорт <strong>к</strong>лассифи<strong>к</strong>ационной схемы и до<strong>к</strong>ументов.<br />

3.1.4 СЭД должна быть способна поддерживать <strong>к</strong>лассифи<strong>к</strong>ационную схему, в<br />

<strong>к</strong>оторой дела и до<strong>к</strong>ументы могут быть упорядочены в виде<br />

иерархичес<strong>к</strong>ой стру<strong>к</strong>туры рубри<strong>к</strong>.<br />

Y<br />

Использование иерархичес<strong>к</strong>ой <strong>к</strong>лассифи<strong>к</strong>ационной схемы обязательно<br />

для соответствия <strong>требования</strong>м MoReq2. Это необходимо для<br />

обеспечения возможности наследования сро<strong>к</strong>ов хранения и других<br />

метаданных, а та<strong>к</strong>же для удобства перемещения по рубри<strong>к</strong>ам<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы.<br />

Минимальным требованием является поддерж<strong>к</strong>а трёх уровней<br />

иерархичес<strong>к</strong>ой стру<strong>к</strong>туры; во многих случаях потребуется большее<br />

число уровней.<br />

3.1.5 К <strong>управлению</strong> <strong>к</strong>лассифи<strong>к</strong>ационной схемой СЭД должна допус<strong>к</strong>ать<br />

толь<strong>к</strong>о исполнителя административной роли (с учетом <strong>требования</strong><br />

3.1.6).<br />

Y<br />

В рам<strong>к</strong>ах данного <strong>требования</strong> под «управлением» понимается<br />

выполнение операций, описанных в разделах 3.1 и 3.4.<br />

3.1.6 Желательно, чтобы СЭД допус<strong>к</strong>ала, чтобы управление отдельными<br />

рубри<strong>к</strong>ами осуществлялось исполнителями определенных<br />

пользовательс<strong>к</strong>их ролей и/или определенными группами<br />

пользователей.<br />

Y<br />

Версия 1.04<br />

8 сентября 2008 Стр. 38


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

В рам<strong>к</strong>ах приведенного выше требовании, термин «управление»<br />

имеет то же значение, что и для <strong>требования</strong> 3.1.5. Данное<br />

требование предназначено для ситуаций, <strong>к</strong>огда:<br />

используются большие <strong>к</strong>лассифи<strong>к</strong>ационные схемы, <strong>к</strong>оторые<br />

слиш<strong>к</strong>ом вели<strong>к</strong>и для того, чтобы осуществлять их<br />

централизованную поддерж<strong>к</strong>у (поэтому для та<strong>к</strong>их<br />

<strong>к</strong>лассифи<strong>к</strong>ационных схем используется централизованное<br />

управление на высших уровнях, и децентрализованное – на<br />

низших);<br />

используются <strong>к</strong>лассифи<strong>к</strong>ационные схемы, в<strong>к</strong>лючающие рубри<strong>к</strong>и<br />

для хранения досье, и необходимо, чтобы управление этими досье<br />

осуществлялось (после предоставления привилегий<br />

авторизованного пользователя) в стру<strong>к</strong>турных<br />

подразделениях, работающих по данной темати<strong>к</strong>е.<br />

3.1.7 Желательно, чтобы СЭД не ограничивала число возможных уровней в<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схеме.<br />

P<br />

В большинстве случаев маловероятно, чтобы необходимое<br />

<strong>к</strong>оличество уровней о<strong>к</strong>азалось больше десяти.<br />

3.1.8 СЭД должна поддерживать первоначальное создание<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы, готовой <strong>к</strong>о вводу и/или импорту<br />

эле<strong>к</strong>тронных до<strong>к</strong>ументов, во время <strong>к</strong>онфигурирования системы<br />

Y<br />

Назначение этого <strong>требования</strong> – обеспечить возможность создания<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы во время установ<strong>к</strong>и и настрой<strong>к</strong>и СЭД, и до<br />

того, <strong>к</strong>а<strong>к</strong> СЭД начнет использоваться для управления до<strong>к</strong>ументами.<br />

3.1.9 СЭД должна поддерживать возможность во время <strong>к</strong>онфигурирования<br />

системы задания исполнителем административной роли правила<br />

(правил) присвоения названий (заголов<strong>к</strong>ов) (titling mechanisms).<br />

3.1.10 Желательно, чтобы СЭД давала возможность вводить <strong>к</strong>рат<strong>к</strong>ие<br />

те<strong>к</strong>стовые описания (scope notes, descriptions) для всех рубри<strong>к</strong>, дел,<br />

суб-дел и томов.<br />

Y<br />

Y<br />

Крат<strong>к</strong>ие те<strong>к</strong>стовые описания представляют собой пояснения и<br />

<strong>к</strong>омментарии, информирующие пользователей о предполагаемом<br />

содержании (и/или ис<strong>к</strong>лючениях, особенностях) рубри<strong>к</strong>, дел, суб-дел и<br />

томов.<br />

3.1.11 После опубли<strong>к</strong>ования формальной XML-схемы для MoReq2, СЭД<br />

должна быть способна импортировать и э<strong>к</strong>спортировать до<strong>к</strong>ументы и<br />

т.д. в виде, соответствующем этой схеме.<br />

3.1.12 СЭД должна поддерживать импорт всей <strong>к</strong>лассифи<strong>к</strong>ационной схемы или<br />

её частей, <strong>к</strong>а<strong>к</strong> во время <strong>к</strong>онфигурирования СЭД, та<strong>к</strong> и в любое другое<br />

время.<br />

Y<br />

Y<br />

Версия 1.04<br />

8 сентября 2008 Стр. 39


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Назначение этого <strong>требования</strong> – обеспечить возможность создания<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы во время установ<strong>к</strong>и и настрой<strong>к</strong>и СЭД, и до<br />

того, <strong>к</strong>а<strong>к</strong> СЭД начнет использоваться для управления до<strong>к</strong>ументами.<br />

Импорт частей <strong>к</strong>лассифи<strong>к</strong>ационной схемы может проводиться <strong>к</strong>а<strong>к</strong> с<br />

целью добавления их в существующую схему, та<strong>к</strong> и для создания<br />

новой <strong>к</strong>лассифи<strong>к</strong>ационной схемы (в случае, <strong>к</strong>огда <strong>к</strong>лассифи<strong>к</strong>ационная<br />

схема в СЭД еще не создана).<br />

3.1.13 Когда СЭД импортирует всю <strong>к</strong>лассифи<strong>к</strong>ационную схему или <strong>к</strong>а<strong>к</strong>ую-либо<br />

её часть, она должна давать возможность импортировать<br />

взаимосвязанные со схемой метаданные, сро<strong>к</strong>и хранения и<br />

<strong>к</strong>онтрольную информацию, если та<strong>к</strong>овые имеются.<br />

Y<br />

В идеальном случае, импортируемая <strong>к</strong>лассифи<strong>к</strong>ационная схема будет<br />

снабжена метаданными рубри<strong>к</strong> и сро<strong>к</strong>ами хранения. В остальных<br />

случаях метаданные и/или сро<strong>к</strong>и хранения могут отсутствовать или<br />

быть неполными.<br />

3.1.14 Если СЭД импортирует метаданные <strong>к</strong>лассифи<strong>к</strong>ационной схемы, то она<br />

должна отвергать рубри<strong>к</strong>и, не имеющие названия (title), и создавать для<br />

исполнителя административной роли отчет об ошиб<strong>к</strong>ах импорта,<br />

перечисляя в нем отвергнутые рубри<strong>к</strong>и.<br />

Y<br />

В СЭД, не соответствующей <strong>требования</strong>м MoReq2, может иметься<br />

возможность создать безымянную рубри<strong>к</strong>у (с «пустым» значением в<br />

поле наименования); одна<strong>к</strong>о та<strong>к</strong>ую рубри<strong>к</strong>у невозможно будет<br />

использовать в СЭД, соответствующей <strong>требования</strong>м MoReq2.<br />

3.1.15 Если СЭД импортирует метаданные <strong>к</strong>лассифи<strong>к</strong>ационной схемы, то СЭД<br />

должна присвоить <strong>к</strong>аждой импортированной рубри<strong>к</strong>е иерархичес<strong>к</strong>ий<br />

<strong>к</strong>од 24 в соответствии с выбором, сделанным исполнителем<br />

административной роли, одним из следующих способов,:<br />

P<br />

следуя тем же правилам, <strong>к</strong>а<strong>к</strong>ие были бы использованы при создании<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы вручную;<br />

полностью сохраняя оригинальные <strong>к</strong>оды (возможно толь<strong>к</strong>о в том<br />

случае, если стру<strong>к</strong>туры <strong>к</strong>лассифи<strong>к</strong>ационных схем совместимы);<br />

присоединяя (appending) оригинальные <strong>к</strong>оды <strong>к</strong> <strong>к</strong>одам в<br />

принимающей <strong>к</strong>лассифи<strong>к</strong>ационной схеме.<br />

Если импортируемая иерархичес<strong>к</strong>ая схема уже содержит<br />

иерархичес<strong>к</strong>ие <strong>к</strong>оды рубри<strong>к</strong> (например: 4/6/4), то может о<strong>к</strong>азаться<br />

невозможным использовать эти <strong>к</strong>оды в СЭД, пос<strong>к</strong>оль<strong>к</strong>у невозможно<br />

гарантировать их уни<strong>к</strong>альность и согласованность.<br />

24<br />

Об иерархичес<strong>к</strong>их <strong>к</strong>лассифи<strong>к</strong>ационных <strong>к</strong>одах расс<strong>к</strong>азывается в главе 7 (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 40


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Возможны различные сценарии подобного импорта, в <strong>к</strong>оторых могут<br />

встретиться различные виды несовместимости между<br />

иерархичес<strong>к</strong>ими схемами нумерации. MoReq2 не регламентирует<br />

последствия попыт<strong>к</strong>и использовать вариант, логичес<strong>к</strong>и<br />

невозможный вследствие несовместимости схем.<br />

Если существующие иерархичес<strong>к</strong>ие <strong>к</strong>оды рубри<strong>к</strong> невозможно<br />

использовать «по прямому назначению», то с ними можно поступить<br />

сообразно обстоятельствам, - например, они могут быть<br />

с<strong>к</strong>опированы в элемент метаданных под названием «старый <strong>к</strong>од<br />

рубри<strong>к</strong>и».<br />

3.1.16 Если СЭД импортирует метаданные и сро<strong>к</strong>и хранения<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы, то СЭД должна проверить их правильность,<br />

используя те же правила, <strong>к</strong>оторые используются при создании<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы вручную (см. главу 12). Если в процессе<br />

провер<strong>к</strong>и обнаруживаются ошиб<strong>к</strong>и (например, отсутствие обязательных<br />

метаданных, или ошиб<strong>к</strong>и в формате данных), то СЭД должна поставить<br />

об этом в известность выполняющего импорт исполнителя<br />

административной роли, идентифицировав соответствующие<br />

метаданные.<br />

Y<br />

В идеальном случае, импортируемая <strong>к</strong>лассифи<strong>к</strong>ационная схема будет<br />

иметь метаданные (например, метаданные рубри<strong>к</strong>), полностью<br />

соответствующие модели метаданных MoReq2. В прочих случаях<br />

метаданные схемы могут не соответствовать модели метаданных,<br />

и тогда возможны нес<strong>к</strong>оль<strong>к</strong>о исходов (MoReq2 не предписывает ни<br />

один из них), а именно, следующие:<br />

Операция импорта полностью пре<strong>к</strong>ращается, и исполнитель<br />

административной роли извещается о причине пре<strong>к</strong>ращения<br />

операции;<br />

Отменяется импорт рубри<strong>к</strong>и, метаданные <strong>к</strong>оторой не<br />

соответствуют модели метаданных, и исполнитель<br />

административной роли извещается о причине пре<strong>к</strong>ращения<br />

операции;<br />

Исполнитель административной роли должен сделать выбор:<br />

либо исправить ошиб<strong>к</strong>у, либо отменить импорт<br />

соответствующей рубри<strong>к</strong>и;<br />

Операция импорта продолжается, несмотря на то, что часть<br />

метаданных не соответствует модели метаданных.<br />

Несоответствующие модели метаданные заменяются<br />

значениями по умолчанию, установленными для<br />

соответствующих элементов метаданных; создается отчет об<br />

ошиб<strong>к</strong>ах.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 41


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Необходимость извещать исполнителя административной роли не<br />

означает, что процесс должен быть приоритетным (foreground), или<br />

же выполняться в реальном времени; приемлемо, если процесс<br />

выполняется <strong>к</strong>а<strong>к</strong> фоновый или в па<strong>к</strong>етном режиме.<br />

3.1.17 Желательно, чтобы СЭД поддерживала э<strong>к</strong>спорт всей<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы или её части.<br />

3.1.18 Если СЭД поддерживает э<strong>к</strong>спорт всей <strong>к</strong>лассифи<strong>к</strong>ационной схемы или<br />

её части, необходимо, чтобы э<strong>к</strong>спортировались та<strong>к</strong>же соответствующие<br />

метаданные, и исполнитель административной роли должен иметь<br />

возможность у<strong>к</strong>азать, <strong>к</strong>а<strong>к</strong>ие именно метаданные будут<br />

э<strong>к</strong>спортироваться.<br />

3.1.19 Если СЭД поддерживает э<strong>к</strong>спорт всей <strong>к</strong>лассифи<strong>к</strong>ационной схемы или<br />

её части, необходимо, чтобы, по желанию исполнителя<br />

административной роли, э<strong>к</strong>спортировались та<strong>к</strong>же все соответствующие<br />

сро<strong>к</strong>и хранения.<br />

3.1.20 Если СЭД поддерживает э<strong>к</strong>спорт всей <strong>к</strong>лассифи<strong>к</strong>ационной схемы или<br />

её части, необходимо, чтобы полностью или выборочно<br />

э<strong>к</strong>спортировались та<strong>к</strong>же <strong>к</strong>онтрольная информация (audit trail data).<br />

Отбор э<strong>к</strong>спортируемой <strong>к</strong>онтрольной информации осуществляется<br />

исполнителем административной роли.<br />

3.1.21 Если СЭД поддерживает э<strong>к</strong>спорт (в смысле любого из приведенных<br />

выше требований), то она должна использовать полностью<br />

до<strong>к</strong>ументированный метод для описания взаимосвязей между<br />

объе<strong>к</strong>тами.<br />

Y<br />

Y<br />

Y<br />

Y<br />

Y<br />

До<strong>к</strong>ументация по данному методу должна устанавливать, <strong>к</strong>а<strong>к</strong><br />

отображаются до<strong>к</strong>ументы, дела, рубри<strong>к</strong>и и т.д., а та<strong>к</strong>же их<br />

взаимосвязи. См. та<strong>к</strong>же 3.1.22.<br />

3.1.22 Если СЭД поддерживает э<strong>к</strong>спорт (в смысле любого из приведенных<br />

выше требований), то желательно, чтобы информация<br />

э<strong>к</strong>спортировалась в формате XML или в э<strong>к</strong>вивалентном от<strong>к</strong>рытом<br />

стандартизованном формате.<br />

3.1.23 Если СЭД поддерживает <strong>к</strong>опирование всей <strong>к</strong>лассифи<strong>к</strong>ационной схемы<br />

или её части, то необходимо, чтобы <strong>к</strong>опировались та<strong>к</strong>же и все<br />

соответствующие метаданные.<br />

3.1.24 Если СЭД поддерживает <strong>к</strong>опирование всей <strong>к</strong>лассифи<strong>к</strong>ационной схемы<br />

или её части, то необходимо, чтобы <strong>к</strong>опировались та<strong>к</strong>же и все<br />

соответствующие сро<strong>к</strong>и хранения.<br />

Y<br />

Y<br />

Y<br />

Версия 1.04<br />

8 сентября 2008 Стр. 42


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

3.1.25 СЭД должна давать возможность исполнителям административных<br />

ролей добавлять новые рубри<strong>к</strong>и в любое место любой рубри<strong>к</strong>и, если в<br />

этом месте не размещены дела или до<strong>к</strong>ументы. 25<br />

Y<br />

MoReq2 не допус<strong>к</strong>ает, чтобы дела и рубри<strong>к</strong>и существовали на одном<br />

уровне внутри рубри<strong>к</strong>и (иными словами, в одном узле иерархичес<strong>к</strong>ой<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы нельзя смешивать дела и рубри<strong>к</strong>и). Это<br />

требование введено, исходя из принципов хорошей пра<strong>к</strong>ти<strong>к</strong>и<br />

управления до<strong>к</strong>ументами.<br />

3.1.26 Желательно, чтобы СЭД поддерживала создание и одновременное<br />

использование нес<strong>к</strong>оль<strong>к</strong>их <strong>к</strong>лассифи<strong>к</strong>ационных схем.<br />

Y<br />

В большинстве организаций является обязательным использование<br />

единственной <strong>к</strong>лассифи<strong>к</strong>ационной схемы для <strong>к</strong>лассифи<strong>к</strong>ации и<br />

размещения всех дел в СЭД. Настоящее требование, одна<strong>к</strong>о,<br />

допус<strong>к</strong>ает, чтобы одни дела размещались в одной <strong>к</strong>лассифи<strong>к</strong>ационной<br />

схеме, а прочие – в другой. Это может быть нужно, например,<br />

вследствие слияния двух организаций, или же тогда, <strong>к</strong>огда различные<br />

массивы до<strong>к</strong>ументов одной организации требуют различных режимов<br />

управления.<br />

3.2 Рубри<strong>к</strong>и и дела<br />

В этом разделе перечислены <strong>требования</strong> в отношении дел и рубри<strong>к</strong> <strong>к</strong>лассифи<strong>к</strong>ационной<br />

схемы<br />

Рубри<strong>к</strong>и и дела представляют собой различные <strong>к</strong>онстру<strong>к</strong>ции. Рубри<strong>к</strong>и обеспечивают<br />

логичес<strong>к</strong>ую стру<strong>к</strong>туру для <strong>к</strong>лассифи<strong>к</strong>ации, в то время, <strong>к</strong>а<strong>к</strong> в делах на<strong>к</strong>апливаются<br />

до<strong>к</strong>ументы; рубри<strong>к</strong>и являются теми бло<strong>к</strong>ами, из <strong>к</strong>оторых строится <strong>к</strong>лассифи<strong>к</strong>ационная<br />

схема, а дела – нет. Одна<strong>к</strong>о, несмотря на та<strong>к</strong>ие глубо<strong>к</strong>ие различия, удобно перечислить<br />

вместе ряд требований, пос<strong>к</strong>оль<strong>к</strong>у они являются общими для обеих <strong>к</strong>онстру<strong>к</strong>ций.<br />

№ Требование Тест.<br />

3.2.1 СЭД должна поддерживать сбор, ведение и отображение метаданных<br />

дел и рубри<strong>к</strong> <strong>к</strong>лассифи<strong>к</strong>ационной схемы в соответствии с моделью<br />

метаданных MoReq2.<br />

3.2.2 СЭД должна ограничивать возможность добавления метаданных для<br />

дел и рубри<strong>к</strong>, в соответствии у<strong>к</strong>азаниями, приведенными в модели<br />

метаданных MoReq2.<br />

Y<br />

N<br />

25<br />

Та<strong>к</strong>ая сложная формулиров<strong>к</strong>а возни<strong>к</strong>ла из-за того, что в MoReq2 под "рубри<strong>к</strong>ой" понимается<br />

рубри<strong>к</strong>а со всеми ее подрубри<strong>к</strong>ами. Если же под "рубри<strong>к</strong>ой" понимать толь<strong>к</strong>о саму рубри<strong>к</strong>у,<br />

без входящих в нее объе<strong>к</strong>тов, то все упрощается: внутри рубри<strong>к</strong>и MoReq2 позволяет<br />

размещать либо дела и до<strong>к</strong>ументы, либо подрубри<strong>к</strong>и – но не те и другие вместе. (прим.<br />

переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 43


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

3.2.3 СЭД должна иметь механизм автоматичес<strong>к</strong>ого присвоения<br />

иерархичес<strong>к</strong>ого <strong>к</strong>лассифи<strong>к</strong>ационного <strong>к</strong>ода <strong>к</strong>аждому делу, суб-делу,<br />

тому и рубри<strong>к</strong>е в <strong>к</strong>лассифи<strong>к</strong>ационной схеме (если та<strong>к</strong>ой <strong>к</strong>од ещё не<br />

назначен - см. 3.1.15).<br />

Y<br />

См. та<strong>к</strong>же 7.1.1.<br />

3.2.4 СЭД должна давать возможность исполнителям пользовательс<strong>к</strong>их<br />

ролей присваивать название (заголово<strong>к</strong>) <strong>к</strong>аждому эле<strong>к</strong>тронному делу,<br />

суб-делу, тому и рубри<strong>к</strong>е.<br />

Y<br />

Данное требование применимо тогда, <strong>к</strong>огда не ведётся работа с<br />

досье. В тех случаях, <strong>к</strong>огда нужно управлять досье, требуется<br />

альтернативный подход <strong>к</strong> присвоению названий, <strong>к</strong>оторый описан в<br />

разделе 10.5.<br />

3.2.5 Должна иметься возможность использовать и <strong>к</strong>лассифи<strong>к</strong>ационный <strong>к</strong>од,<br />

и те<strong>к</strong>стовой заголово<strong>к</strong> дела - <strong>к</strong>а<strong>к</strong> вместе, та<strong>к</strong> и по отдельности.<br />

3.2.6 СЭД должна давать возможность исполнителю административной роли<br />

задать, - во время <strong>к</strong>онфигурирования системы либо позднее, - правила<br />

формирования <strong>к</strong>лассифи<strong>к</strong>ационных <strong>к</strong>одов.<br />

3.2.7 Желательно, чтобы в <strong>к</strong>онфигурацию (правила формирования)<br />

<strong>к</strong>лассифи<strong>к</strong>ационного <strong>к</strong>ода входили:<br />

Y<br />

Y<br />

Y<br />

формат идентифи<strong>к</strong>атора, назначаемого <strong>к</strong>аждому уровню иерархии, -<br />

например, числовой, те<strong>к</strong>стовой;<br />

начальное значение этого идентифи<strong>к</strong>атора для <strong>к</strong>аждой рубри<strong>к</strong>и, -<br />

например, 1, 1000;<br />

приращение, используемое при формировании идентифи<strong>к</strong>аторов<br />

для последовательно идущих рубри<strong>к</strong>, - например, 1, 10;<br />

наличие или отсутствие ведущих нулей;<br />

глобальный префи<strong>к</strong>с, - например, "<strong>к</strong>орпоративные/";<br />

глобальное расширение, - например, суффи<strong>к</strong>с, обозначающий<br />

страну;<br />

символ-разделитель идентифи<strong>к</strong>аторов, составляющих полный <strong>к</strong>од, -<br />

например, "/", "-".<br />

3.2.8 СЭД должна фи<strong>к</strong>сировать дату от<strong>к</strong>рытия и дату за<strong>к</strong>рытия рубри<strong>к</strong>и или<br />

дела в метаданных рубри<strong>к</strong>и или дела.<br />

Y<br />

Даты от<strong>к</strong>рытия и за<strong>к</strong>рытия рубри<strong>к</strong> и дел представляют собой<br />

важный элемент <strong>к</strong>онте<strong>к</strong>ста для размещенных в них до<strong>к</strong>ументов. См.<br />

та<strong>к</strong>же 3.3.9.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 44


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Если рубри<strong>к</strong>а или дело от<strong>к</strong>рыты, в них могут быть помещены<br />

до<strong>к</strong>ументы. Если рубри<strong>к</strong>а или дело за<strong>к</strong>рыты, поместить в них<br />

до<strong>к</strong>ументы невозможно.<br />

3.2.9 СЭД должна фи<strong>к</strong>сировать дату создания новой рубри<strong>к</strong>и, дела, суб-дела<br />

или тома в метаданных рубри<strong>к</strong>и или дела.<br />

Y<br />

У физичес<strong>к</strong>их дел дата от<strong>к</strong>рытия может о<strong>к</strong>азаться более ранней,<br />

чем зафи<strong>к</strong>сированная в СЭД дата создания. Это может произойти в<br />

том случае, если та<strong>к</strong>ое дело физичес<strong>к</strong>и создано и от<strong>к</strong>рыто до того,<br />

<strong>к</strong>а<strong>к</strong> оно заведено в СЭД.<br />

У эле<strong>к</strong>тронных дел дата от<strong>к</strong>рытия та<strong>к</strong>же может о<strong>к</strong>азаться более<br />

ранней, чем зафи<strong>к</strong>сированная в СЭД дата создания. Это может<br />

произойти в том случае, если эле<strong>к</strong>тронное дело импортировано в<br />

СЭД из другой системы.<br />

3.2.10 Вся<strong>к</strong>ий раз, <strong>к</strong>огда от<strong>к</strong>рывается новая рубри<strong>к</strong>а или дело, СЭД должна<br />

автоматичес<strong>к</strong>и в<strong>к</strong>лючать в метаданные рубри<strong>к</strong>и или дела те атрибуты,<br />

<strong>к</strong>оторые наследуются вследствие положения рубри<strong>к</strong>и или дела в<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схеме.<br />

Y<br />

Например, если дело «Собрания» расположено в иерархичес<strong>к</strong>ой<br />

стру<strong>к</strong>туре с именем:<br />

План регионального развития : Публичное обсуждение : Собрания<br />

и исполнитель административной роли добавляет новое дело с<br />

названием «Письменные <strong>к</strong>онсультации» на том же уровне иерархии,<br />

что и дело «Собрания», то новое дело должно автоматичес<strong>к</strong>и<br />

унаследовать префи<strong>к</strong>с<br />

«План регионального развития : Публичное обсуждение».<br />

Следует иметь в виду, что унаследованные метаданные не<br />

обязательно должны быть явным образом сохранены; наследование<br />

может осуществляться неявным образом. См. подробности в<br />

приложении 9.3.<br />

3.2.11 СЭД должна предоставлять исполнителю административной роли<br />

возможность модифицировать унаследованные значения метаданных,<br />

в пределах, допус<strong>к</strong>аемых моделью метаданных MoReq2.<br />

Y<br />

Унаследованные значения часто используются в <strong>к</strong>ачестве<br />

первоначальных значений или значений по умолчанию. Та<strong>к</strong>ое<br />

поведение может быть изменено, при условии, что изменения<br />

совместимы с моделью метаданных.<br />

3.2.12 Желательно, чтобы любое добавление, внесенное в унаследованные<br />

метаданные рубри<strong>к</strong>и, по умолчанию наследовалось всеми<br />

подчиненными рубри<strong>к</strong>ами и делами.<br />

Y<br />

Версия 1.04<br />

8 сентября 2008 Стр. 45


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

3.2.13 Желательно, чтобы СЭД, в дополнение <strong>к</strong> другим <strong>требования</strong>м данного<br />

раздела, поддерживала выбор и присвоение терминов из<br />

<strong>к</strong>онтролируемого словаря, соответствующих стандарту ISO 2788, в<br />

<strong>к</strong>ачестве описательных терминов (subject terms) в полях метаданных<br />

рубри<strong>к</strong> и дел.<br />

3.2.14 Желательно, чтобы СЭД, в дополнение <strong>к</strong> другим <strong>требования</strong>м данного<br />

раздела, поддерживала выбор и присвоение терминов из<br />

<strong>к</strong>онтролируемого словаря, соответствующих стандарту ISO 5964, в<br />

<strong>к</strong>ачестве описательных терминов (subject terms) в полях метаданных<br />

рубри<strong>к</strong> и дел.<br />

Y<br />

Y<br />

Требования 3.2.13 и 3.2.14 отличаются друг от друга лишь тем, что<br />

первое специфицирует одноязычный тезаурус, а второе –<br />

многоязычный.<br />

3.2.15 СЭД не должна на<strong>к</strong>ладывать <strong>к</strong>а<strong>к</strong>их-либо пра<strong>к</strong>тичес<strong>к</strong>и значимых<br />

ограничений на число рубри<strong>к</strong> и дел, <strong>к</strong>оторые могут быть созданы.<br />

3.2.16 Желательно, чтобы СЭД могла э<strong>к</strong>спортировать списо<strong>к</strong> (часто<br />

называемый описью - repertory) всех дел или же дел, размещенных в<br />

определенной рубри<strong>к</strong>е (вместе с её подрубри<strong>к</strong>ами-потом<strong>к</strong>ами) в<br />

формате XML и/или в челове<strong>к</strong>о-читаемом формате.<br />

3.2.17 СЭД должна давать возможность исполнителю административной роли<br />

устанавливать параметры рубри<strong>к</strong>и та<strong>к</strong>им образом, чтобы разрешать<br />

либо запрещать размещение до<strong>к</strong>ументов непосредственно в этой<br />

рубри<strong>к</strong>е.<br />

P<br />

P<br />

Y<br />

Иными словами, должна быть возможность та<strong>к</strong> с<strong>к</strong>онфигурировать<br />

систему, чтобы до<strong>к</strong>ументы необязательно было держать в делах,<br />

суб-делах и томах..<br />

3.3 Тома и суб-дела<br />

В системах хранения бумажных до<strong>к</strong>ументов разделение объёмных дел на части необходимо<br />

с точ<strong>к</strong>и зрения эргономи<strong>к</strong>и и обеспечения физичес<strong>к</strong>ой сохранности папо<strong>к</strong>, с<strong>к</strong>оросшивателей,<br />

<strong>к</strong>онвертов и т.д. Обычно толщина бумажных дел не должна превышать 2 см, что<br />

достигается разделением дел на тома. Когда дело (а на самом деле, несмотря на<br />

использование термина «дело» – это первый том дела) достигает предельной толщины (в<br />

данном примере – 2 см), оно рассматривается <strong>к</strong>а<strong>к</strong> за<strong>к</strong>рытый том, и от<strong>к</strong>рывается новый том.<br />

Иначе обстоит дело с эле<strong>к</strong>тронными делами – эле<strong>к</strong>тронное дело может разрастаться до<br />

пра<strong>к</strong>тичес<strong>к</strong>и любого объёма, не создавая упомянутых выше проблем.<br />

На пра<strong>к</strong>ти<strong>к</strong>е, одна<strong>к</strong>о, разделение больших эле<strong>к</strong>тронных дел на тома может о<strong>к</strong>азаться<br />

полезным, например:<br />

<strong>к</strong>огда пользователям необходимо работать в удаленном режиме (т.е. используя<br />

соединение с низ<strong>к</strong>ой пропус<strong>к</strong>ной способностью; или в случае, <strong>к</strong>огда нужные для работы<br />

до<strong>к</strong>ументы с<strong>к</strong>ачиваются на мобильный/персональный <strong>к</strong>омпьютер, либо записываются на<br />

носитель ограниченной ём<strong>к</strong>ости);<br />

Версия 1.04<br />

8 сентября 2008 Стр. 46


Специфи<strong>к</strong>ации MoReq2<br />

<strong>к</strong>огда дела ни<strong>к</strong>огда не за<strong>к</strong>рываются, пос<strong>к</strong>оль<strong>к</strong>у, например, они имеют «географичес<strong>к</strong>ую<br />

привяз<strong>к</strong>у» (geographically linked). 26<br />

Кроме того, бумажные дела часто делятся на суб-дела – особенно при работе с досье. Субдела<br />

используются для упорядочивания содержащихся в деле материалов, часто – в<br />

соответствии с типом информационных материалов.<br />

Соответственно, в ряде случаев деление эле<strong>к</strong>тронных дел на суб-дела может о<strong>к</strong>азаться<br />

полезным, например:<br />

за счёт улучшения навигации по материалам дела;<br />

за счет предоставления возможностей для управления до<strong>к</strong>ументами, имеющими<br />

специфичес<strong>к</strong>ими <strong>требования</strong> по сро<strong>к</strong>ам хранения, отличающиеся от требований <strong>к</strong><br />

остальным до<strong>к</strong>ументам дела, - например, это могут быть до<strong>к</strong>ументы, подпадающие под<br />

за<strong>к</strong>онодательство о защите персональных данных.<br />

В данном разделе содержатся <strong>требования</strong> в отношении томов и суб-дел. И тома, и суб-дела<br />

обычно используются для разделения на части дел, <strong>к</strong>оторые в противном случае могли бы<br />

стать неуправляемо объёмными. MoReq2 не предписывает, чтобы та<strong>к</strong>ое деление<br />

использовалось на пра<strong>к</strong>ти<strong>к</strong>е; одна<strong>к</strong>о требуется, чтобы соответствующее MoReq2<br />

программное обеспечение имело эти фун<strong>к</strong>циональные возможности, - для использования в<br />

случае необходимости.<br />

Понятие «суб-дело» отсутствует в предыдущей версии MoReq.<br />

Суммируя с<strong>к</strong>азанное:<br />

Каждое дело может содержать одно или нес<strong>к</strong>оль<strong>к</strong>о суб-дел;<br />

Каждое суб-дело может содержать один или нес<strong>к</strong>оль<strong>к</strong>о томов;<br />

Тома различных суб-дел создаются независимо друг от друга;<br />

Все суб-дела от<strong>к</strong>рытого дела могут от<strong>к</strong>рываться и за<strong>к</strong>рываться пользователями по мере<br />

необходимости;<br />

В <strong>к</strong>аждом суб-деле может быть от<strong>к</strong>рыт толь<strong>к</strong>о один том.<br />

Более подробную информацию о суб-делах и томах см. в разделе 2.2.<br />

№ Требование Тест.<br />

3.3.1 Исполнитель административной роли должен иметь возможность<br />

с<strong>к</strong>онфигурировать СЭД, во время <strong>к</strong>онфигурирования системы либо в<br />

иное время, та<strong>к</strong>им образом, чтобы в масштабе <strong>к</strong>лассифи<strong>к</strong>ационной<br />

схемы от<strong>к</strong>лючить возможность создания в делах суб-дел и/или томов.<br />

Y<br />

26<br />

"Географичес<strong>к</strong>и-привязанные" означает "содержащие любые географичес<strong>к</strong>ие атрибуты, та<strong>к</strong>ие<br />

<strong>к</strong>а<strong>к</strong> ссыл<strong>к</strong>и на статистичес<strong>к</strong>ие о<strong>к</strong>руга, пространственные <strong>к</strong>оординаты, адреса или <strong>к</strong>адастровые<br />

номера" (http://www.leg.wa.gov/pub/billinfo/1991-92/Wpd/Bills/House%20Bills/1752-S.wpd) Вероятно,<br />

имеются в виду дела, относящиеся <strong>к</strong> определенному месту, объе<strong>к</strong>ту, организации и т.д. (прим.<br />

переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 47


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

3.3.2 Исполнитель административной роли должен иметь возможность<br />

с<strong>к</strong>онфигурировать СЭД, во время <strong>к</strong>онфигурирования системы либо в<br />

иное время, та<strong>к</strong>им образом, чтобы в делах, относящихся <strong>к</strong><br />

определенным рубри<strong>к</strong>ам <strong>к</strong>лассифи<strong>к</strong>ационной схемы, можно было<br />

создавать одни толь<strong>к</strong>о суб-дела.<br />

3.3.3 Исполнитель административной роли должен иметь возможность<br />

с<strong>к</strong>онфигурировать СЭД, во время <strong>к</strong>онфигурирования системы либо в<br />

иное время, та<strong>к</strong>им образом, чтобы в делах, относящихся <strong>к</strong><br />

определенным рубри<strong>к</strong>ам <strong>к</strong>лассифи<strong>к</strong>ационной схемы, можно было<br />

создавать одни толь<strong>к</strong>о тома.<br />

Y<br />

Y<br />

Приведенные выше три <strong>требования</strong> дают возможность<br />

организациям разрешать или бло<strong>к</strong>ировать использование суб-дел<br />

и/или томов в различных частях <strong>к</strong>лассифи<strong>к</strong>ационной схемы.<br />

Одновременное использование суб-дел и томов даёт ма<strong>к</strong>симальную<br />

гиб<strong>к</strong>ость, одна<strong>к</strong>о платой за эту гиб<strong>к</strong>ость может быть сложность и<br />

возможное непонимание пользователями.<br />

Если часть <strong>к</strong>лассифи<strong>к</strong>ационной схемы с<strong>к</strong>онфигурирована та<strong>к</strong>им<br />

образом, чтобы допус<strong>к</strong>ать создание суб-дел, то все дела в ней<br />

должны содержать <strong>к</strong>а<strong>к</strong> минимум одно суб-дело. Если часть<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы с<strong>к</strong>онфигурирована та<strong>к</strong>им образом, чтобы<br />

допус<strong>к</strong>ать создание томов, то все дела (или суб-дела, если их<br />

создание разрешено) должны содержать <strong>к</strong>а<strong>к</strong> минимум один том.<br />

Та<strong>к</strong>им образом, система должна быть "прозрачной" для<br />

пользователей, например:<br />

Если суб-дело содержит толь<strong>к</strong>о один том, то допус<strong>к</strong>ается,<br />

чтобы суб-дело и том были неразличимы для <strong>к</strong>онечных<br />

пользователей;<br />

Если дело содержит толь<strong>к</strong>о одно суб-дело, <strong>к</strong>оторое, в свою<br />

очередь, содержит толь<strong>к</strong>о один том, то допус<strong>к</strong>ается, чтобы все<br />

три объе<strong>к</strong>та, - дело, суб-дело и том, были неразличимы для<br />

<strong>к</strong>онечных пользователей.<br />

Цель с<strong>к</strong>азанного - подчер<strong>к</strong>нуть, что СЭД не должна навязывать<br />

пользователям стру<strong>к</strong>туру «дело, суб-дело, том». СЭД должна<br />

поддерживать возможность использования суб-дел и томов,<br />

позволяя, в то же время, пользователям думать в терминах одних<br />

толь<strong>к</strong>о дел, если их им удобно.<br />

Суть с<strong>к</strong>азанного за<strong>к</strong>лючается в том, что пользователь видит<br />

толь<strong>к</strong>о то, что существенно с точ<strong>к</strong>и зрения выполнения делового<br />

процесса, - и его не обременяют избыточными, способными<br />

запутать вариантами действий.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 48


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

3.3.4 СЭД должна поддерживать <strong>к</strong>онцепцию «от<strong>к</strong>рытых» и «за<strong>к</strong>рытых»<br />

эле<strong>к</strong>тронных томов, следующим образом:<br />

Y<br />

толь<strong>к</strong>о последний созданный том суб-дела может быть от<strong>к</strong>рыт;<br />

все остальные тома этого суб-дела должны быть за<strong>к</strong>рыты.<br />

3.3.5 СЭД не должна давать пользователями возможность добавлять<br />

эле<strong>к</strong>тронные до<strong>к</strong>ументы в за<strong>к</strong>рытый том.<br />

3.3.6 СЭД должна давать возможность исполнителям административных<br />

ролей добавить эле<strong>к</strong>тронный том в любое неза<strong>к</strong>рытое эле<strong>к</strong>тронное<br />

суб-дело.<br />

Y<br />

Y<br />

Процесс добавления нового тома в<strong>к</strong>лючает за<strong>к</strong>рытие от<strong>к</strong>рытого в<br />

данный момент тома и создание нового от<strong>к</strong>рытого тома.<br />

3.3.7 СЭД должна давать возможность исполнителям административных<br />

ролей добавлять суб-дела в любое неза<strong>к</strong>рытое эле<strong>к</strong>тронное дело.<br />

3.3.8 СЭД должна давать пользователям возможность в любое время<br />

за<strong>к</strong>рыть суб-дело.<br />

3.3.9 СЭД должна сохранять дату от<strong>к</strong>рытия нового тома или суб-дела дела<br />

в их метаданных.<br />

3.3.10 При от<strong>к</strong>рытии нового тома или суб-дела, СЭД должна автоматичес<strong>к</strong>и<br />

в<strong>к</strong>лючать в его метаданные те элементы метаданных<br />

«родительс<strong>к</strong>ого» дела, <strong>к</strong>оторые являются общими (в соответствии с<br />

моделью метаданных MoReq2).<br />

Y<br />

Y<br />

Y<br />

Y<br />

Доступ <strong>к</strong> содержащимся в томе до<strong>к</strong>ументам возможен независимо<br />

от того, от<strong>к</strong>рыт том или за<strong>к</strong>рыт.<br />

3.3.11 При от<strong>к</strong>рытии нового тома, СЭД должна автоматичес<strong>к</strong>и присвоить ему<br />

идентифи<strong>к</strong>атор, уни<strong>к</strong>альный в рам<strong>к</strong>ах его родительс<strong>к</strong>ого суб-дела.<br />

P<br />

В <strong>к</strong>ачестве идентифи<strong>к</strong>аторов может использоваться простая<br />

последовательность номеров, начинающаяся у <strong>к</strong>аждого суб-дела с 1.<br />

3.3.12 СЭД должна сохранять даты за<strong>к</strong>рытия томов и суб-дел в их<br />

метаданных.<br />

3.3.13 При размещении до<strong>к</strong>умента пользователю, по умолчанию, должен<br />

быть предложен для этого последний из созданных в выбранном<br />

пользователем суб-деле томов.<br />

3.3.14 СЭД должна допус<strong>к</strong>ать создание в любом деле нес<strong>к</strong>оль<strong>к</strong>их<br />

одновременно от<strong>к</strong>рытых суб-дел.<br />

Y<br />

Y<br />

Y<br />

Версия 1.04<br />

8 сентября 2008 Стр. 49


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

3.3.15 СЭД должна давать исполнителю административной роли<br />

возможность удалить пустой том.<br />

3.3.16 СЭД должна давать исполнителю административной роли<br />

возможность в ходе единой операции удалить пустой том и<br />

переот<strong>к</strong>рыть предыдущий том суб-дела, фи<strong>к</strong>сируя это событие в<br />

составе <strong>к</strong>онтрольной информации.<br />

Y<br />

Y<br />

Эта возможность предназначена для исправления ошибо<strong>к</strong>,<br />

следствием <strong>к</strong>оторых стало не<strong>к</strong>орре<strong>к</strong>тное за<strong>к</strong>рытие тома.<br />

3.3.17 Желательно, чтобы СЭД допус<strong>к</strong>ала создание исполнителем<br />

административной роли для определенной рубри<strong>к</strong>и «шаблона» субдел.<br />

Та<strong>к</strong>ой шаблон устанавливает, <strong>к</strong>а<strong>к</strong>ие суб-дела будут<br />

автоматичес<strong>к</strong>и создаваться в <strong>к</strong>аждом новом деле, впоследствии<br />

созданном в этой рубри<strong>к</strong>е.<br />

Y<br />

Это требование предназначено, в первую очередь, для работы с<br />

досье. Например, в страховой <strong>к</strong>омпании подобный шаблон для<br />

рубри<strong>к</strong>и, связанной со страховыми полисами <strong>к</strong>лиентов, мог бы<br />

определять следующие суб-дела: «Полисы и поправ<strong>к</strong>и <strong>к</strong> ним»,<br />

«Внутренняя перепис<strong>к</strong>а», «Перепис<strong>к</strong>а с медицинс<strong>к</strong>ими<br />

специалистами», «Счета», «Прочая перепис<strong>к</strong>а с <strong>к</strong>лиентами».<br />

Впоследствии <strong>к</strong>аждое новое дело в этой рубри<strong>к</strong>е автоматичес<strong>к</strong>и<br />

создавалось бы с этим набором суб-дел.<br />

3.3.18 При за<strong>к</strong>рытии дела СЭД должна автоматичес<strong>к</strong>и за<strong>к</strong>рывать все<br />

от<strong>к</strong>рытые суб-дела этого дела.<br />

3.3.19 СЭД должна давать пользователям возможность за<strong>к</strong>рывать тома,<br />

принадлежащие различным суб-делам, независимо друг от друга. 27<br />

Y<br />

Y<br />

3.4 Ведение <strong>к</strong>лассифи<strong>к</strong>ационной схемы<br />

Данный раздел начинается с требований <strong>к</strong> перемещению (reclassifying), объединению,<br />

разделению и <strong>к</strong>опированию рубри<strong>к</strong> (с 3.4.1 по 3.4.4). Все эти фун<strong>к</strong>циональные возможности<br />

предназначены для использования толь<strong>к</strong>о в особых обстоятельствах, - например, в случае<br />

слияния организаций или иной реорганизации; или же для исправления техничес<strong>к</strong>их ошибо<strong>к</strong>;<br />

или тогда, <strong>к</strong>огда <strong>к</strong>лассифи<strong>к</strong>ационная схема не слиш<strong>к</strong>ом хорошо соответствует деловым<br />

потребностям. Эти возможности не предназначены для регулярного использования в рам<strong>к</strong>ах<br />

хорошо продуманной <strong>к</strong>лассифи<strong>к</strong>ационной схемы. Требования желательно читать совместно<br />

с разделами 9.3.3 и 9.3.4. Завершают данный раздел прочие <strong>требования</strong>, связанные с<br />

ведением <strong>к</strong>лассифи<strong>к</strong>ационной схемы (3.4.17 и далее).<br />

27<br />

Достаточно туманно написанная формулиров<strong>к</strong>а оригинала (The ERMS must allow users to close<br />

volumes individually) уточнена по материалам для тестирования (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 50


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

3.4.1 СЭД должна давать возможность исполнителю административной<br />

роли в ходе одной транза<strong>к</strong>ции переместить рубри<strong>к</strong>у в другое место<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы.<br />

Y<br />

В данном <strong>к</strong>онте<strong>к</strong>сте, перемещение (relocation) означает изменение<br />

места рубри<strong>к</strong>и или дела в <strong>к</strong>лассифи<strong>к</strong>ационной схеме - т.е.<br />

передвижение их в другую точ<strong>к</strong>у <strong>к</strong>лассифи<strong>к</strong>ационной схемы.<br />

Перемещение может происходить <strong>к</strong>а<strong>к</strong> в место, расположенное на<br />

том же уровне <strong>к</strong>лассифи<strong>к</strong>ационной схемы, та<strong>к</strong> и на любой другой<br />

уровень. При перемещении должны выполняться нес<strong>к</strong>оль<strong>к</strong>о<br />

дополнительных требований, описанных ниже в данном разделе.<br />

3.4.2 СЭД должна давать возможность исполнителю административной<br />

роли в ходе одной транза<strong>к</strong>ции объединять две рубри<strong>к</strong>и.<br />

Y<br />

В данном требовании, «объединение» понимается следующим<br />

образом: если одна рубри<strong>к</strong>а объединяется с другой, то:<br />

все потом<strong>к</strong>и и все содержание первой рубри<strong>к</strong>и перемещаются<br />

та<strong>к</strong>им образом, что становятся потом<strong>к</strong>ами и содержанием<br />

второй рубри<strong>к</strong>и;<br />

первая рубри<strong>к</strong>а за<strong>к</strong>рывается.<br />

3.4.3 СЭД должна давать возможность исполнителю административной<br />

роли в ходе одной транза<strong>к</strong>ции разделить рубри<strong>к</strong>у на две.<br />

Y<br />

В данном требовании, «разделение» понимается следующим<br />

образом: если рубри<strong>к</strong>а разделяется, то:<br />

создается новая рубри<strong>к</strong>а, являющаяся потом<strong>к</strong>ом того же<br />

родительс<strong>к</strong>ого <strong>к</strong>ласса, что и разделяемая рубри<strong>к</strong>а<br />

(подразумеваются все <strong>требования</strong>, связанные с созданием новой<br />

рубри<strong>к</strong>и, та<strong>к</strong>ие, <strong>к</strong>а<strong>к</strong> ввод и наследование метаданных);<br />

пользователь у<strong>к</strong>азывает место в стру<strong>к</strong>туре 28<br />

рубри<strong>к</strong>и;<br />

разделяемой<br />

содержимое рубри<strong>к</strong>и, расположенное ниже у<strong>к</strong>азанной точ<strong>к</strong>и (т.е.<br />

имеющее больший <strong>к</strong>лассифи<strong>к</strong>ационный <strong>к</strong>од) перемещается во<br />

вновь созданную рубри<strong>к</strong>у.<br />

Содержание разделяемой рубри<strong>к</strong>и может быть любого допустимого<br />

типа, а именно, это могут быть рубри<strong>к</strong>и, дела и до<strong>к</strong>ументы.<br />

28<br />

В оригинале – «в содержании» (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 51


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

3.4.4 Желательно, чтобы СЭД давала возможность исполнителю<br />

административной роли в ходе одной транза<strong>к</strong>ции выполнить<br />

<strong>к</strong>опирование любой из рубри<strong>к</strong> <strong>к</strong>лассифи<strong>к</strong>ационной схемы.<br />

Y<br />

В данном требовании, под «<strong>к</strong>опированием» понимается создание<br />

<strong>к</strong>опии рубри<strong>к</strong>и со всем её содержимым в другой точ<strong>к</strong>е<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы, оставляя при этом исходную рубри<strong>к</strong>у<br />

неизменной. Копирование может проводиться <strong>к</strong>а<strong>к</strong> в место,<br />

расположенное на том же уровне <strong>к</strong>лассифи<strong>к</strong>ационной схемы, та<strong>к</strong> и на<br />

любой другой уровень. При <strong>к</strong>опировании должны выполняться<br />

нес<strong>к</strong>оль<strong>к</strong>о дополнительных требований, описанных ниже в данном<br />

разделе.<br />

Та<strong>к</strong>ая возможность нужна для репли<strong>к</strong>ации ветвей<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы, что иногда требуется, например, при<br />

создании части <strong>к</strong>лассифи<strong>к</strong>ационной схемы, <strong>к</strong>оторая разработана не<br />

на основе строго фун<strong>к</strong>ционального подхода.<br />

Использование сначала операции э<strong>к</strong>спорта, а затем импорта не<br />

считается подходящим способом выполнения данного <strong>требования</strong>,<br />

ввиду его сложности.<br />

3.4.5 При перемещении или <strong>к</strong>опировании рубри<strong>к</strong>, СЭД должна обеспечить,<br />

чтобы перемещенные или созданные при <strong>к</strong>опировании дела и весь их<br />

<strong>к</strong>онтент получили новые <strong>к</strong>лассифи<strong>к</strong>ационные <strong>к</strong>оды, соответствующие<br />

их новому положению в <strong>к</strong>лассифи<strong>к</strong>ационной схеме.<br />

Y<br />

Это означает, что <strong>к</strong>аждое дело, суб-дело, том, до<strong>к</strong>умент и<br />

<strong>к</strong>омпонента, <strong>к</strong>оторые были перемещены или созданы при<br />

<strong>к</strong>опировании, получают новый <strong>к</strong>лассифи<strong>к</strong>ационный <strong>к</strong>од и новый<br />

полный <strong>к</strong>лассифи<strong>к</strong>ационный <strong>к</strong>од (fully-qualified classification code).<br />

Правила назначения новых <strong>к</strong>одов те же, что и правила, используемые<br />

при создании новых рубри<strong>к</strong>, дел, до<strong>к</strong>ументов и т.д.<br />

3.4.6 СЭД не должна требовать от исполнителя административной роли,<br />

осуществляющего перемещение, разделение, объединение или<br />

<strong>к</strong>опирование рубри<strong>к</strong>, выполнения раздельных операций э<strong>к</strong>спорта и<br />

импорта.<br />

Y<br />

Суть данного <strong>требования</strong> состоит в обеспечении удобства работы;<br />

не следует заставлять пользователей выполнять, для получения<br />

желаемого результата, серию несвязанных между собой операций .<br />

Версия 1.04<br />

8 сентября 2008 Стр. 52


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

3.4.7 СЭД не должна допус<strong>к</strong>ать та<strong>к</strong>ие перемещения или <strong>к</strong>опирования,<br />

<strong>к</strong>оторые бы приводили <strong>к</strong> возни<strong>к</strong>новению стру<strong>к</strong>туры данных,<br />

противоречащей правилам, подразумеваемым используемой в<br />

MoReq2 моделью взаимосвязей между объе<strong>к</strong>тами СЭД (см. раздел<br />

13.2), или явно у<strong>к</strong>азанным в других <strong>требования</strong>х. В частности, СЭД не<br />

должна допус<strong>к</strong>ать та<strong>к</strong>ие перемещения или <strong>к</strong>опирования, <strong>к</strong>оторые бы<br />

приводили:<br />

Y<br />

<strong>к</strong> сохранению суб-дел или томов в рубри<strong>к</strong>е <strong>к</strong>лассифи<strong>к</strong>ационной<br />

схемы, для <strong>к</strong>оторой был установлен запрет на использование субдел<br />

или рубри<strong>к</strong> (см. 3.3.1, 3.3.2, 3.3.3);<br />

<strong>к</strong> сохранению до<strong>к</strong>ументов непосредственно в рубри<strong>к</strong>е, <strong>к</strong>оторая уже<br />

содержит дела (или наоборот);<br />

<strong>к</strong> сохранению дел в рубри<strong>к</strong>е, <strong>к</strong>оторая уже содержит подрубри<strong>к</strong>и<br />

(или наоборот).<br />

3.4.8 СЭД должна обеспечить, чтобы в процессе перемещения сохранялась<br />

правильная «привяз<strong>к</strong>а» всех эле<strong>к</strong>тронных до<strong>к</strong>ументов <strong>к</strong><br />

перемещаемым рубри<strong>к</strong>ам и/или делам, а та<strong>к</strong>же сохранялись<br />

взаимосвязи между делами, суб-делами и томами.<br />

3.4.9 СЭД должна обеспечить, чтобы в процессе <strong>к</strong>опирования сохранялась<br />

правильная «привяз<strong>к</strong>а» всех <strong>к</strong>опий эле<strong>к</strong>тронных до<strong>к</strong>ументов <strong>к</strong><br />

созданным <strong>к</strong>опиям рубри<strong>к</strong> и/или дел, а та<strong>к</strong>же сохранялись правильные<br />

взаимосвязи между <strong>к</strong>опиями дел, суб-дел и томов.<br />

3.4.10 В случае перемещения рубри<strong>к</strong>, дел, суб-дел, томов или до<strong>к</strong>ументов 29 ,<br />

все за<strong>к</strong>рытые дела должны оставаться за<strong>к</strong>рытыми, сохраняя свои<br />

ссыл<strong>к</strong>и на <strong>к</strong>лассифи<strong>к</strong>ационную схему до внесения изменений<br />

(<strong>к</strong>лассифи<strong>к</strong>ационные <strong>к</strong>оды).<br />

3.4.11 В случае перемещения рубри<strong>к</strong>, дел, суб-дел, томов или до<strong>к</strong>ументов 30 ,<br />

все от<strong>к</strong>рытые дела должны:<br />

P<br />

P<br />

Y<br />

Y<br />

либо быть за<strong>к</strong>рыты, с сохранением их ссыло<strong>к</strong> на<br />

<strong>к</strong>лассифи<strong>к</strong>ационную схему до изменений (<strong>к</strong>лассифи<strong>к</strong>ационных<br />

<strong>к</strong>одов), и с созданием и сохранением в метаданных пере<strong>к</strong>рестных<br />

ссыло<strong>к</strong> на новые дела в измененной <strong>к</strong>лассифи<strong>к</strong>ационной схеме;<br />

либо быть «привязаны» (получить ссыл<strong>к</strong>и) <strong>к</strong> измененной схеме, но<br />

сохранив в явном виде в метаданных все прежние ссыл<strong>к</strong>и на<br />

<strong>к</strong>лассифи<strong>к</strong>ационную схему до изменений.<br />

в соответствии с выбором, делаемым проводящим перемещение<br />

исполнителем административной роли<br />

29<br />

30<br />

Суб-дела, тома и до<strong>к</strong>ументы упоминаются здесь напрасно (прим. переводчи<strong>к</strong>а)<br />

Суб-дела, тома и до<strong>к</strong>ументы упоминаются здесь напрасно (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 53


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

3.4.12 В случае перемещения или <strong>к</strong>опирования рубри<strong>к</strong>, СЭД должна<br />

обеспечить, в <strong>к</strong>ачестве опциональной возможности, наследование<br />

рубри<strong>к</strong>ами и их <strong>к</strong>онтентом (или, соответственно, <strong>к</strong>опиями) метаданных<br />

новой родительс<strong>к</strong>ой рубри<strong>к</strong>и.<br />

Y<br />

Наследуются, среди прочих, та<strong>к</strong>ие элементы, <strong>к</strong>а<strong>к</strong> права доступа и<br />

<strong>к</strong>атегории защиты (грифы доступа).<br />

3.4.13 В случае перемещения или <strong>к</strong>опирования рубри<strong>к</strong>, СЭД должна быть<br />

способна применять <strong>к</strong> перемещенным или созданным при <strong>к</strong>опировании<br />

рубри<strong>к</strong>ам и их <strong>к</strong>онтенту все наследуемые (inheritable) от новой<br />

родительс<strong>к</strong>ой рубри<strong>к</strong>и сро<strong>к</strong>и хранения, в дополнение <strong>к</strong> уже имеющимся<br />

сро<strong>к</strong>ам хранения.<br />

Y<br />

Данное требование устанавливает минимальный уровень<br />

фун<strong>к</strong>циональных возможностей; СЭД может предложить<br />

дополнительные способы управления сро<strong>к</strong>ами хранения.<br />

В результате возможны <strong>к</strong>онфли<strong>к</strong>ты между сро<strong>к</strong>ами хранения.<br />

Конфли<strong>к</strong>ты, в случае их возни<strong>к</strong>новения, должны разрешаться та<strong>к</strong>,<br />

<strong>к</strong>а<strong>к</strong> описано в разделе 5.1 (см., в частности, 5.1.18 и 5.1.33).<br />

3.4.14 В случае перемещения или <strong>к</strong>опирования рубри<strong>к</strong>, СЭД должна<br />

требовать, чтобы исполнитель административной роли ввел в виде<br />

метаданных причину перемещения или <strong>к</strong>опирования.<br />

Y<br />

Ввод причины перемещения является обязательным, пос<strong>к</strong>оль<strong>к</strong>у<br />

операции перемещения и <strong>к</strong>опирования выполняются толь<strong>к</strong>о в<br />

ис<strong>к</strong>лючительных обстоятельствах, и потенциально способны, если<br />

их тщательно не <strong>к</strong>онтролировать, поставить под угрозу<br />

целостность до<strong>к</strong>ументов.<br />

3.4.15 При перемещении или <strong>к</strong>опировании рубри<strong>к</strong>, дел или до<strong>к</strong>ументов, СЭД<br />

должна сохранять сведения об их состоянии до перемещения или<br />

<strong>к</strong>опирования в составе <strong>к</strong>онтрольной информации.<br />

3.4.16 При перемещении рубри<strong>к</strong>, СЭД должна сохранить значения их<br />

метаданных до перемещения.<br />

Y<br />

Y<br />

Оба предыдущих <strong>требования</strong> введены для того, чтобы была<br />

возможность проследить историю перемещенных до<strong>к</strong>ументов.<br />

3.4.17 Желательно, чтобы СЭД давала возможность исполнителю<br />

административной роли отметить рубри<strong>к</strong>у или дело <strong>к</strong>а<strong>к</strong> неа<strong>к</strong>тивные, с<br />

тем, чтобы предотвратить размещение новых дел в рубри<strong>к</strong>е или новых<br />

до<strong>к</strong>ументов в деле.<br />

3.4.18 Желательно, чтобы СЭД давала возможность исполнителю<br />

административной роли удалять пустые рубри<strong>к</strong>и.<br />

Y<br />

Y<br />

Версия 1.04<br />

8 сентября 2008 Стр. 54


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

3.4.19 СЭД не должна допус<strong>к</strong>ать удаления эле<strong>к</strong>тронного дела или <strong>к</strong>а<strong>к</strong>ой-либо<br />

части его <strong>к</strong>онтента (содержания).<br />

Y<br />

Ис<strong>к</strong>лючениями из этого <strong>требования</strong> являются:<br />

уничтожение в связи с истечением установленного сро<strong>к</strong>а<br />

хранения и в соответствии с у<strong>к</strong>азаниями о дальнейшей судьбе<br />

до<strong>к</strong>ументов - <strong>к</strong>а<strong>к</strong> объясняется в п. 5.1.25;<br />

либо<br />

удаление исполнителем административной роли в ходе<br />

<strong>к</strong>онтролируемой и прото<strong>к</strong>олируемой (audited) процедуры - <strong>к</strong>а<strong>к</strong><br />

объясняется в разделе 9.3.<br />

3.4.20 СЭД должна давать возможность исполнителям пользовательс<strong>к</strong>их<br />

ролей за<strong>к</strong>рывать эле<strong>к</strong>тронные дела.<br />

Y<br />

Это требование отличается от соответствующего <strong>требования</strong> в<br />

MoReq, в <strong>к</strong>отором использование данной фун<strong>к</strong>циональной<br />

возможности разрешалось толь<strong>к</strong>о администраторам.<br />

3.4.21 Желательно, чтобы СЭД могла автоматичес<strong>к</strong>и за<strong>к</strong>рыть эле<strong>к</strong>тронный<br />

том по выполнении определенных <strong>к</strong>ритериев, установленных при<br />

<strong>к</strong>онфигурировании системы, - поддерживая, <strong>к</strong>а<strong>к</strong> минимум, следующие<br />

варианты <strong>к</strong>ритериев:<br />

Y<br />

создание томов в ходе ежегодной «отсеч<strong>к</strong>и» (cut-off), проводимой в<br />

определенный день года - например, в <strong>к</strong>онце <strong>к</strong>алендарного года,<br />

финансового года, или иного заданного годового ци<strong>к</strong>ла;<br />

истечение заданного периода времени с момента наступления<br />

определённого события, - например, с момента последнего<br />

добавления эле<strong>к</strong>тронного до<strong>к</strong>умента в данный том;<br />

число эле<strong>к</strong>тронных до<strong>к</strong>ументов, содержащихся в томе.<br />

В ряде случаев другие <strong>к</strong>ритерии могут о<strong>к</strong>азаться желательными, -<br />

например, в ситуации, <strong>к</strong>огда размер тома приближается <strong>к</strong> ём<strong>к</strong>ости<br />

съёмного дис<strong>к</strong>а.<br />

3.4.22 СЭД должна обеспечить, чтобы содержание за<strong>к</strong>рытых рубри<strong>к</strong>, дел, субдел<br />

и томов было столь же доступно для чтения, что и содержимое<br />

соответствующих от<strong>к</strong>рытых объе<strong>к</strong>тов, не делая в этом отношении<br />

ни<strong>к</strong>а<strong>к</strong>ого различия между от<strong>к</strong>рытыми и за<strong>к</strong>рытыми объе<strong>к</strong>тами.<br />

Y<br />

Иными словами, пользователям, <strong>к</strong>оторые ведут поис<strong>к</strong> или<br />

просматривают информацию в СЭД, не нужно знать, являются ли<br />

дела и т.д. от<strong>к</strong>рытыми или за<strong>к</strong>рытыми; и в отношении и тех, и<br />

других должны применяться одни и те же средства поис<strong>к</strong>а и правила<br />

доступа.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 55


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

3.4.23 Желательно, чтобы СЭД давала возможность пользователям<br />

создавать пере<strong>к</strong>рёстные ссыл<strong>к</strong>и (т.е. ссыл<strong>к</strong>и типа «смотри та<strong>к</strong>же»)<br />

между взаимосвязанными делами.<br />

3.4.24 Желательно, чтобы СЭД поддерживала возможность создания<br />

нес<strong>к</strong>оль<strong>к</strong>о «входов» в эле<strong>к</strong>тронный до<strong>к</strong>умент 31 , размещенных в<br />

различных рубри<strong>к</strong>ах, делах. суб-делах и томах, без физичес<strong>к</strong>ого<br />

дублирования соответствующего до<strong>к</strong>умента или информационных<br />

материалов, из <strong>к</strong>оторых он формируется.<br />

Y<br />

Y<br />

MoReq2 не предписывает способ реализации данного <strong>требования</strong>.<br />

Одним из способов может быть использование у<strong>к</strong>азателей в тех<br />

случаях, <strong>к</strong>огда вводится нес<strong>к</strong>оль<strong>к</strong>о до<strong>к</strong>ументов 32 , базирующихся на<br />

одном и том же информационно материале.<br />

3.4.25 В СЭД должны иметься средства создания отчётов для выдачи<br />

исполнителям административных ролей статистичес<strong>к</strong>их данных по<br />

различным аспе<strong>к</strong>там деятельности, затрагивающей<br />

<strong>к</strong>лассифи<strong>к</strong>ационную схему, в<strong>к</strong>лючая данные о числе и объёмах<br />

созданных, за<strong>к</strong>рытых и удалённых за определенный период времени<br />

рубри<strong>к</strong>, дел, томов, суб-дел и до<strong>к</strong>ументов.<br />

Y<br />

Желательно, чтобы можно было получать <strong>к</strong>а<strong>к</strong> сводную отчетность,<br />

та<strong>к</strong> и данные в разрезе пользователей или рубри<strong>к</strong>.<br />

3.4.26 Желательно, чтобы в СЭД имелись средства создания<br />

специализированных (ad hoc) отчетов по различным аспе<strong>к</strong>там<br />

деятельности, затрагивающей <strong>к</strong>лассифи<strong>к</strong>ационную схему.<br />

3.4.27 Пользователь, работающий с рубри<strong>к</strong>ой, делом или до<strong>к</strong>ументом,<br />

должен иметь возможность быстро и лег<strong>к</strong>о установить <strong>к</strong>онте<strong>к</strong>ст этой<br />

рубри<strong>к</strong>и, дела или до<strong>к</strong>умента, - иными словами, метаданные, а та<strong>к</strong>же<br />

«родительс<strong>к</strong>ое» дело или рубри<strong>к</strong>у (рубри<strong>к</strong>и). Пользователь должен<br />

иметь возможность переместиться из рубри<strong>к</strong>и, дела или до<strong>к</strong>умента в<br />

соответствующие «родительс<strong>к</strong>ие» объе<strong>к</strong>ты.<br />

P<br />

Y<br />

Должна иметься возможность установить этот <strong>к</strong>онте<strong>к</strong>ст, не<br />

по<strong>к</strong>идая рубри<strong>к</strong>у или дело, и та<strong>к</strong>им образом, чтобы можно было, не<br />

прерываясь, продолжать работу с делом.<br />

3.4.28 В случае изменения присвоенных делу <strong>к</strong>лючевых слов 33 , СЭД<br />

должна потребовать от исполнителя административной роли, чтобы<br />

тот у<strong>к</strong>азал причину изменений.<br />

Y<br />

31<br />

32<br />

33<br />

Речь идет о том, что один и тот же эле<strong>к</strong>тронный до<strong>к</strong>умент (точнее – ссыл<strong>к</strong>а на него) может<br />

проявиться в нес<strong>к</strong>оль<strong>к</strong>их рубри<strong>к</strong>ах, делах и т.д. См. амери<strong>к</strong>анс<strong>к</strong>ий стандарт DoD 5015.2-STD,<br />

где о подобной фун<strong>к</strong>циональной возможности говорится более подробно. (прим. переводчи<strong>к</strong>а)<br />

Мы считаем, что правильнее говорить не о вводе нес<strong>к</strong>оль<strong>к</strong>их до<strong>к</strong>ументов, а о возможности<br />

видеть один и тот же до<strong>к</strong>умент в разных рубри<strong>к</strong>ах, делах и т.д. (прим. переводчи<strong>к</strong>а)<br />

По поводу <strong>к</strong>лючевых слов см. <strong>к</strong>омментарий в «Предисловии переводчи<strong>к</strong>а» (прим.<br />

переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 56


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

3.4.29 В случае изменения присвоенных делу <strong>к</strong>лючевых слов, СЭД должна<br />

сохранить сведения об их состоянии до изменения, с тем, чтобы можно<br />

было лег<strong>к</strong>о определить историю изменений.<br />

Y<br />

Эти меры <strong>к</strong>онтроля над изменениями в <strong>к</strong>лючевых словах нужны,<br />

чтобы ма<strong>к</strong>симально снизить рис<strong>к</strong> того, что до<strong>к</strong>ументы<br />

«затеряются» вследствие изменений в <strong>к</strong>лючевых словах. Пос<strong>к</strong>оль<strong>к</strong>у<br />

<strong>к</strong>лючевые слова используются для поис<strong>к</strong>а до<strong>к</strong>ументов, необходимо<br />

отслеживать все изменения в <strong>к</strong>лючевых словах, с тем, чтобы<br />

предотвратить ситуацию, <strong>к</strong>огда пользователь мог бы попытаться<br />

спрятать до<strong>к</strong>умент, изменив его <strong>к</strong>лючевые слова.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 57


Специфи<strong>к</strong>ации MoReq2<br />

4. УПРАВЛЕНИЕ ДОСТУПОМ И БЕЗОПАСНОСТЬ<br />

В данной главе собраны вместе <strong>требования</strong>, относящиеся <strong>к</strong> широ<strong>к</strong>ому <strong>к</strong>ругу мер и средств<br />

<strong>к</strong>онтроля и управления, связанных с обеспечением безопасности до<strong>к</strong>ументов. Эти<br />

<strong>требования</strong> обеспечивают наличие фун<strong>к</strong>циональных возможностей, необходимых для<br />

поддержания и защиты хара<strong>к</strong>теристи<strong>к</strong> 34 до<strong>к</strong>ументов, перечисленных в п.7.2 стандарта ISO<br />

15489.<br />

Пос<strong>к</strong>оль<strong>к</strong>у до<strong>к</strong>ументы могут содержать персональные данные, <strong>к</strong>оммерчес<strong>к</strong>ую или<br />

оперативную <strong>к</strong>онфиденциальную информацию, то очень важно, чтобы организации могли<br />

<strong>к</strong>онтролировать, <strong>к</strong>ому и при <strong>к</strong>а<strong>к</strong>их обстоятельствах разрешен доступ <strong>к</strong> до<strong>к</strong>ументам.<br />

Может та<strong>к</strong>же возни<strong>к</strong>нуть необходимость в установлении ограничений доступа в отношении<br />

«внешних» пользователей. Например, в ряде стран, в <strong>к</strong>оторых за<strong>к</strong>онодательство о свободе<br />

доступа <strong>к</strong> информации разрешает доступ <strong>к</strong> определенным публичным до<strong>к</strong>ументам, <strong>к</strong>лиенты<br />

могут пожелать их увидеть. Далее, не<strong>к</strong>оторые организации могут принять решение о<br />

предоставлении доступа <strong>к</strong> части хранилища СЭД своим партнерам. Требования в<br />

отношении соответствующих мер <strong>к</strong>онтроля и управления приведены в разделе 4.1..<br />

Для обеспечения юридичес<strong>к</strong>ой силы до<strong>к</strong>ументов, а та<strong>к</strong>же для помощи в восстановлении<br />

данных, необходимо прото<strong>к</strong>олировать и сохранять в составе <strong>к</strong>онтрольной информации (audit<br />

trail) сведения о предоставлении доступа и о других операциях с до<strong>к</strong>ументами и связанными<br />

с ними информационными материалами и данными. Соответствующие <strong>требования</strong><br />

приведены в разделе 4.2. Эти <strong>требования</strong> главным образом направлены на обеспечение<br />

та<strong>к</strong>их хара<strong>к</strong>теристи<strong>к</strong> до<strong>к</strong>ументов, <strong>к</strong>а<strong>к</strong> целостность и аутентичность (см. ISO 15489, п.7.2).<br />

Обеспечение безопасности до<strong>к</strong>ументов та<strong>к</strong>же подразумевает их защиту от последствий<br />

системных сбоев за счёт резервного <strong>к</strong>опирования, и возможность восстановления<br />

до<strong>к</strong>ументов с резервных <strong>к</strong>опий. Требования <strong>к</strong> этим фун<strong>к</strong>циональным возможностям<br />

содержатся в разделе 4.3. Данные <strong>требования</strong> связаны с та<strong>к</strong>ой хара<strong>к</strong>теристи<strong>к</strong>ой до<strong>к</strong>ументов,<br />

определенной в стандарте ISO 15489 (п. 7.2), <strong>к</strong>а<strong>к</strong> «годность <strong>к</strong> использованию».<br />

К числу «важнейших» (vital records) относятся те до<strong>к</strong>ументы, <strong>к</strong>оторые <strong>к</strong>ритичес<strong>к</strong>и важны для<br />

выполнения организацией своих целей и задач, и <strong>к</strong>оторые необходимо быстро получить<br />

после возни<strong>к</strong>новения чрезвычайной ситуации или <strong>к</strong>атастрофы. Важнейшие до<strong>к</strong>ументы<br />

рассматриваются в разделе 4.4.<br />

4.1 Управление доступом<br />

Организациям необходимо иметь возможность <strong>к</strong>онтролировать доступ <strong>к</strong> своим до<strong>к</strong>ументам.<br />

Ка<strong>к</strong> правило, это достигается за счёт разработ<strong>к</strong>и и реализации на пра<strong>к</strong>ти<strong>к</strong>е полити<strong>к</strong> в<br />

области безопасности, т.е. доступ <strong>к</strong> до<strong>к</strong>ументам предоставляется, исходя из того, <strong>к</strong>а<strong>к</strong>ую<br />

роль сотрудни<strong>к</strong> играет в деловой деятельности организации. Управление пользователями<br />

обычно осуществляется централизованно, и им одновременно предоставляются права<br />

доступа <strong>к</strong> ряду <strong>к</strong>орпоративных систем, в<strong>к</strong>лючая СЭД.<br />

Управление правами доступа в СЭД путем назначения <strong>к</strong>аждому из пользователей<br />

индивидуальных прав на доступ <strong>к</strong> <strong>к</strong>он<strong>к</strong>ретным объе<strong>к</strong>там не считается хорошей пра<strong>к</strong>ти<strong>к</strong>ой.<br />

Поэтому права доступа будут обычно назначаться для ролей и/или групп пользователей,<br />

34<br />

Это: аутентичность, надёжность, целостность и годность <strong>к</strong> использованию (прим.<br />

переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 58


Специфи<strong>к</strong>ации MoReq2<br />

позволяя им сохранять и использовать до<strong>к</strong>ументы в определенных рубри<strong>к</strong>ах и делах<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы.<br />

Помимо от<strong>к</strong>рытия доступа <strong>к</strong> определенным частям <strong>к</strong>лассифи<strong>к</strong>ационной схемы, права<br />

доступа та<strong>к</strong>же используются для ограничения <strong>к</strong>руга операций, <strong>к</strong>оторые пользователь,<br />

исполнитель роли или член группы может выполнить над объе<strong>к</strong>тами СЭД, - та<strong>к</strong>их, например,<br />

<strong>к</strong>а<strong>к</strong> просмотр метаданных и содержимого объе<strong>к</strong>тов, модифи<strong>к</strong>ация и удаление объе<strong>к</strong>тов, или<br />

создание либо просмотр объе<strong>к</strong>тов определенного типа.<br />

Например, исполнитель пользовательс<strong>к</strong>ой роли может вести поис<strong>к</strong> и читать до<strong>к</strong>ументы,<br />

одна<strong>к</strong>о ролевая схема обеспечения безопасности может ограничивать его возможности,<br />

допус<strong>к</strong>ая поис<strong>к</strong> и чтение до<strong>к</strong>ументов толь<strong>к</strong>о в пределах определенных подмножеств<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы.<br />

Права могут назначаться группам и наследоваться членами этих групп. Назначение прав<br />

доступа на уровне групп, а не на уровне пользователей, облегчает управление СЭД во<br />

времени – <strong>к</strong>огда приходят новые пользователи, уходят старые, а права существующих<br />

пользователей меняются.<br />

Посредством назначения в СЭД исполнителей ролей, пользователю или группе могут<br />

автоматичес<strong>к</strong>и предоставляться многочисленные права доступа. Позднее, <strong>к</strong>огда<br />

пользователь или группа перестают выполнять данную роль, все эти права автоматичес<strong>к</strong>и<br />

отбираются.<br />

СЭД должна быть способна ввести ограничения, при <strong>к</strong>оторых выполнение операций по<br />

установление прав доступа разрешено толь<strong>к</strong>о исполнителям определенных ролей. В<br />

таблице в разделе 3.14 по<strong>к</strong>азано, что та<strong>к</strong>ие возможности предоставляются исполнителям<br />

административных ролей.<br />

Следует, одна<strong>к</strong>о, иметь в виду, что, с системной точ<strong>к</strong>и зрения, исполнители<br />

административных ролей лишь реализует на пра<strong>к</strong>ти<strong>к</strong>е «политичес<strong>к</strong>ие» решения, принятые<br />

ру<strong>к</strong>оводством более высо<strong>к</strong>ого уровня. Регламенты обеспечения безопасности, и<br />

установление ответственности индивидуальных <strong>к</strong>онечных пользователей за их исполнение,<br />

обычно базируются на деловых потребностях пользователей в отношении доступа <strong>к</strong><br />

информации, на полити<strong>к</strong>е организации в области управления до<strong>к</strong>ументами, на за<strong>к</strong>онах и<br />

нормативных а<strong>к</strong>тах (та<strong>к</strong>их, <strong>к</strong>а<strong>к</strong> за<strong>к</strong>оны об информации, о защите персональных данных, об<br />

архивном деле), и на отраслевых нормах (соответствующие вопросы обсуждаются в<br />

разделе 11.5).<br />

В одних случаях управление правами доступа <strong>к</strong> ресурсам СЭД цели<strong>к</strong>ом осуществляется в<br />

самой СЭД. В других случаях управление рядом прав ведётся с использованием отдельного<br />

программного обеспечения, - например, с использованием соответствующей утилиты<br />

сетевой операционной системы. Оба подхода являются приемлемыми при обеспечении<br />

соответствия приведенным ниже <strong>требования</strong>м.<br />

Описанные здесь роли являются лишь примерными. Желательно, чтобы сама организация<br />

определилась с числом и набором прав у используемых ею ролей, - а та<strong>к</strong>же с тем, будет ли<br />

она, исходя из собственных потребностей, вообще использовать роли.<br />

№ Требование Тест.<br />

4.1.1 СЭД должна давать возможность выполнять в ней <strong>к</strong>а<strong>к</strong>ие-либо действия<br />

толь<strong>к</strong>о авторизованным пользователям, успешно прошедшим<br />

идентифи<strong>к</strong>ацию и аутентифи<strong>к</strong>ацию.<br />

Y<br />

Версия 1.04<br />

8 сентября 2008 Стр. 59


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

MoReq2 не предписывает природу механизма аутентифи<strong>к</strong>ации. Во<br />

многих случаях считается, что использование идентифи<strong>к</strong>атора<br />

пользователя и пароля обеспечивает достаточную<br />

аутентифи<strong>к</strong>ацию. Организации, использующие MoReq2 при<br />

проведении за<strong>к</strong>упо<strong>к</strong>, должны позаботиться о том, чтобы<br />

обеспечение должного уровня аутентифи<strong>к</strong>ации было в<strong>к</strong>лючено в<br />

число требований.<br />

4.1.2 СЭД должна давать возможность исполнителям административных<br />

ролей разрешать определённым пользователям, пользовательс<strong>к</strong>им<br />

ролям и группам пользователей, на определенный период времени,<br />

доступ <strong>к</strong> до<strong>к</strong>ументам, делам, суб-делам, рубри<strong>к</strong>ам и метаданным.<br />

4.1.3 СЭД не должна на<strong>к</strong>ладывать ограничений на число ролей или групп,<br />

<strong>к</strong>оторые могут быть созданы.<br />

4.1.4 СЭД должна давать возможность исполнителям административных<br />

ролей управлять правами, предоставляемыми всем ролям и группам.<br />

Эти права определяют те фун<strong>к</strong>циональные возможности, элементы<br />

метаданных, до<strong>к</strong>ументы и дела, <strong>к</strong> <strong>к</strong>оторым исполнители ролей и групп<br />

имеют доступ, а та<strong>к</strong>же разрешённые виды доступа.<br />

4.1.5 СЭД должна давать возможность исполнителям административных<br />

ролей использовать механизм прав для того, чтобы:<br />

Y<br />

P<br />

Y<br />

P<br />

разрешить доступ толь<strong>к</strong>о <strong>к</strong> определенным делам и до<strong>к</strong>ументам;<br />

разрешить доступ толь<strong>к</strong>о <strong>к</strong> определенным рубри<strong>к</strong>ам <strong>к</strong>лассифи<strong>к</strong>ационной<br />

схемы;<br />

ограничить доступ в соответствии с уровнем допус<strong>к</strong>а<br />

пользователя <strong>к</strong> работе с <strong>к</strong>онфиденциальной и се<strong>к</strong>ретной<br />

информацией (где это уместно);<br />

разрешить использование толь<strong>к</strong>о определенных фун<strong>к</strong>ций и<br />

фун<strong>к</strong>циональных возможностей (например, чтение, а та<strong>к</strong>же<br />

модифи<strong>к</strong>ацию и/или уничтожение определенных элементов<br />

метаданных);<br />

запретить доступ после наступления определенной даты;<br />

разрешить доступ после наступления определенной даты.<br />

Механизм прав следует использовать для того, чтобы<br />

предоставлять доступ в соответствии с полити<strong>к</strong>ой (регламентом)<br />

организации в области безопасности.<br />

Требуемый уровень детализации по<strong>к</strong>азан в разделе 13.4.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 60


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

4.1.6 Желательно, чтобы СЭД могла быть с<strong>к</strong>онфигурирована та<strong>к</strong>им образом,<br />

чтобы от<strong>к</strong>рывать доступ при выполнении интегрированной процедуры<br />

входа пользователя в сеть (integrated network log-on).<br />

4.1.7 СЭД должна предоставлять исполнителям административных ролей<br />

возможность в любое время добавлять пользователей в группы и<br />

удалять их из групп, а та<strong>к</strong>же назначать пользователей исполнителями<br />

ролей и снимать их с ролей.<br />

Y<br />

Y<br />

Является приемлемым, если исполнители административных ролей<br />

управляют группами с использованием отдельного программного<br />

обеспечения для управления справочни<strong>к</strong>ами (directory management<br />

software).<br />

4.1.8 СЭД должна поддерживать возможность предоставления прав на<br />

администрирование различных се<strong>к</strong>ций <strong>к</strong>лассифи<strong>к</strong>ационной схемы<br />

различным исполнителям административных ролей.<br />

Y<br />

См., например, модель прав доступа, приведенную в разделе 13.4.<br />

4.1.9 СЭД должна давать возможность исполнителям административных<br />

ролей отметить отдельного пользователя <strong>к</strong>а<strong>к</strong> «неа<strong>к</strong>тивного», не удаляя<br />

при этом его из системы.<br />

Y<br />

Является приемлемым, если исполнители административных ролей<br />

управляют пользователями с использованием отдельного<br />

программного обеспечения для управления справочни<strong>к</strong>ами (directory<br />

management software).<br />

4.1.10 СЭД должна давать исполнителям административных ролей<br />

возможность назначать пользовательс<strong>к</strong>им ролям та<strong>к</strong>ие же права<br />

доступа, <strong>к</strong>а<strong>к</strong> и отдельным пользователям.<br />

Y<br />

Данная фун<strong>к</strong>циональная возможность позволяет исполнителям<br />

административных ролей управлять правами доступа<br />

ограниченного числа ролей, вместо того, чтобы индивидуально<br />

управлять правами гораздо большего числа отдельных<br />

пользователей. Примерами ролей могут быть: Менеджер,<br />

Операционист, Аналити<strong>к</strong> по вопросам безопасности,<br />

Администратор базы данных.<br />

4.1.11 СЭД должна поддерживать использование <strong>к</strong>омбинации прав доступа<br />

путем одновременного назначения пользователя на нес<strong>к</strong>оль<strong>к</strong>о ролей. 35<br />

Y<br />

35<br />

В оригинале здесь стоит довольно туманная фраза: "The ERMS must be able to apply<br />

selections of access requirements across roles". Предлагаемый перевод основан на том, <strong>к</strong>а<strong>к</strong><br />

данное требование тра<strong>к</strong>туется в материалах по тестированию. Выполняемый тест<br />

описывается в них следующим образом: «Пользователь, уже назначенный на <strong>к</strong>а<strong>к</strong>ую-то роль,<br />

запрашивает доступ <strong>к</strong> другой части <strong>к</strong>лассифи<strong>к</strong>ационной схемы. Исполнитель<br />

административной роли выполняет запрос, назначая пользователя на соответствующую роль,<br />

<strong>к</strong>оторая имеет нужное право доступа». (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 61


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Примеры см. в разделе 13.4.<br />

4.1.12 СЭД должна давать возможность исполнителю административной роли<br />

создавать группы пользователей и управлять ими.<br />

Y<br />

Примерами та<strong>к</strong>их групп могут быть: Отдел <strong>к</strong>адров, Отдел продаж.<br />

4.1.13 СЭД должна давать пользователю возможность быть членом одной<br />

или нес<strong>к</strong>оль<strong>к</strong>их групп, либо не состоять ни в одной из групп.<br />

Y<br />

Вполне вероятно, что у не<strong>к</strong>оторых пользователей потребности в<br />

доступе <strong>к</strong> разным частям <strong>к</strong>лассифи<strong>к</strong>ационной схемы могут быть<br />

различными. В любом случае, пользователи в<strong>к</strong>лючаются в группы<br />

исполнителями административных ролей, в соответствии с<br />

полити<strong>к</strong>ой организации и с деловыми потребностями.<br />

4.1.14 СЭД должна давать возможность исполнителям административных<br />

ролей создавать специальные спис<strong>к</strong>и отдельных пользователей с<br />

целью управления доступом <strong>к</strong> определенным частям<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы или до<strong>к</strong>ументам. 36<br />

4.1.15 Доступ <strong>к</strong> системным фун<strong>к</strong>циям и соответствующим событиям СЭД<br />

должна предоставлять толь<strong>к</strong>о исполнителям административных ролей.<br />

Y<br />

Y<br />

Это необходимо для обеспечения доверия <strong>к</strong> эле<strong>к</strong>тронным<br />

до<strong>к</strong>ументам (т.е. для защиты та<strong>к</strong>ого их <strong>к</strong>ачества, <strong>к</strong>а<strong>к</strong><br />

авторитетность).<br />

4.1.16 Толь<strong>к</strong>о исполнителям административных ролей СЭД должна давать<br />

возможность создавать профили пользователей, и управлять<br />

назначением пользователям ролей и в<strong>к</strong>лючением их группы.<br />

Y<br />

См. та<strong>к</strong>же раздел 13.4.<br />

4.1.17 СЭД должна давать исполнителям ролей – владельцам до<strong>к</strong>ументов<br />

возможность у<strong>к</strong>азать, <strong>к</strong>а<strong>к</strong>ие другие пользователи или группы<br />

пользователей могут иметь доступ <strong>к</strong> этим до<strong>к</strong>ументам.<br />

Y<br />

О том, <strong>к</strong>а<strong>к</strong> в MoReq2 используется понятие "владелец", см.<br />

Глоссарий. Желательно, если это не противоречит полити<strong>к</strong>е<br />

организации, чтобы владельцами до<strong>к</strong>ументов были исполнители<br />

административных ролей.<br />

4.1.18 Толь<strong>к</strong>о исполнителям административных ролей СЭД должна давать<br />

возможность внесения та<strong>к</strong>их изменений, <strong>к</strong>а<strong>к</strong> добавление,<br />

<strong>к</strong>орре<strong>к</strong>тиров<strong>к</strong>а или удаление профилей для групп, ролей или<br />

отдельных пользователей.<br />

Y<br />

36<br />

Непонятно назначение этого <strong>требования</strong>, <strong>к</strong>оторое, в дополнение <strong>к</strong> группам и ролям, похоже,<br />

вводит еще один механизм управления доступом (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 62


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Имеются в виду та<strong>к</strong>ие атрибуты, <strong>к</strong>а<strong>к</strong> права доступа, привилегии,<br />

назначение и управление паролями.<br />

4.1.19 СЭД должна давать возможность исполнителям административных<br />

ролей установить и <strong>к</strong>орре<strong>к</strong>тировать правила, регламентирующие<br />

доступ пользователей <strong>к</strong> фун<strong>к</strong>циям СЭД, та<strong>к</strong>ие, что исполнители<br />

различных ролей имеют доступ <strong>к</strong> различным наборам фун<strong>к</strong>ций. СЭД<br />

должна обеспечить возможность установления та<strong>к</strong>их правил со<br />

степенью детализации не меньшей, чем та, <strong>к</strong>оторую можно видеть в<br />

примерной таблице прав доступа в разделе 13.4.<br />

Y<br />

У различных организаций <strong>требования</strong> в отношении управления<br />

доступом <strong>к</strong> фун<strong>к</strong>циональным возможностям СЭД могут различаться;<br />

в связи с этим, нет смысла создавать <strong>к</strong>а<strong>к</strong>ую-либо типовую модель.<br />

Вместо этого данное требование устанавливает уровень<br />

детализации при управлении доступом, <strong>к</strong>оторый СЭД должна<br />

обеспечить.<br />

4.1.20 СЭД должна давать возможность исполнителям административных<br />

ролей создавать дополнительные роли, помимо ролей, описанных в<br />

разделе 13.4.<br />

Y<br />

В организации могут быть определены та<strong>к</strong>ие роли со<br />

специфичес<strong>к</strong>ими правами доступа, <strong>к</strong>а<strong>к</strong>: «специалист по работе с<br />

досье», «ру<strong>к</strong>оводитель» и т.д.<br />

4.1.21 Желательно, чтобы СЭД имела API-интерфейс для при<strong>к</strong>ладного<br />

программирования, позволяющий получить доступ <strong>к</strong> до<strong>к</strong>ументам из<br />

другой при<strong>к</strong>ладной программной системы.<br />

4.1.22 При выполнении пользователем поис<strong>к</strong>а по <strong>к</strong>онтенту (обычно, но не<br />

обязательно, это полноте<strong>к</strong>стовой поис<strong>к</strong> или свободный поис<strong>к</strong> по<br />

те<strong>к</strong>сту), СЭД не должна в<strong>к</strong>лючать в списо<strong>к</strong> результатов поис<strong>к</strong>а те<br />

до<strong>к</strong>ументы, <strong>к</strong> <strong>к</strong>оторым пользователь не имеет прав доступа.<br />

N<br />

Y<br />

Это требование необходимо для того, чтобы помешать<br />

пользователям использовать те<strong>к</strong>стовой поис<strong>к</strong> для изучения<br />

содержания тех до<strong>к</strong>ументов, <strong>к</strong> <strong>к</strong>оторым они не имеют прав доступа.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 63


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

4.1.23 Если пользователь запрашивает доступ, или пытается переместиться,<br />

или ведёт поис<strong>к</strong> (не используя при этом поис<strong>к</strong> по <strong>к</strong>онтенту) любого<br />

объе<strong>к</strong>та, та<strong>к</strong>ого <strong>к</strong>а<strong>к</strong> до<strong>к</strong>умент, том, суб-дело, дело или рубри<strong>к</strong>а, <strong>к</strong><br />

<strong>к</strong>оторым у него нет права доступа, - то СЭД должна реагировать одним<br />

из перечисленных способов (выбираемым на этапе <strong>к</strong>онфигурирования<br />

системы, или в другое время):<br />

Y<br />

Не выдавать ни<strong>к</strong>а<strong>к</strong>ой информации об объе<strong>к</strong>те, тем самым не<br />

рас<strong>к</strong>рывая, существует этот объе<strong>к</strong>т или нет;<br />

Подтвердить фа<strong>к</strong>т существования и, возможно, назвать владельца<br />

объе<strong>к</strong>та (т.е. по<strong>к</strong>азать идентифи<strong>к</strong>атор до<strong>к</strong>умента или дела), но не<br />

по<strong>к</strong>азывать название и иные метаданные;<br />

По<strong>к</strong>азывать толь<strong>к</strong>о название (заголово<strong>к</strong>), тип объе<strong>к</strong>та (рубри<strong>к</strong>а,<br />

до<strong>к</strong>умент и т.д.), дату создание и владельца;<br />

По<strong>к</strong>азывать название (заголово<strong>к</strong>) и другие метаданные объе<strong>к</strong>та.<br />

Первый вариант <strong>требования</strong> подразумевает тот же результат,<br />

что и при использовании поис<strong>к</strong>а по <strong>к</strong>онтенту (см 4.1.22). Остальные<br />

три варианта, расположенные в поряд<strong>к</strong>е ослабления режима<br />

безопасности, сознательно предлагают иные возможности,<br />

<strong>к</strong>оторые могут подойти не<strong>к</strong>оторым организациям. Желательно,<br />

чтобы выбор варианта осуществлялся исполнителями<br />

административных ролей.<br />

Это требование применимо толь<strong>к</strong>о в отношении тех попыто<strong>к</strong><br />

получения доступа, <strong>к</strong>огда не используется поис<strong>к</strong> по <strong>к</strong>онтенту<br />

до<strong>к</strong>ументов. Данное требование следует читать совместно с п.<br />

4.1.22, в <strong>к</strong>отором рассматривается случай поис<strong>к</strong>а по <strong>к</strong>онтенту.<br />

4.1.24 Желательно, чтобы СЭД давала возможность задавать для отдельных<br />

рубри<strong>к</strong> перечисленные в п. 4.1.23 варианты реагирования, - в <strong>к</strong>ачестве<br />

альтернативы общесистемной установ<strong>к</strong>е, устанавливаемой в момент<br />

<strong>к</strong>онфигурирования системы или в более позднее время.<br />

Y<br />

4.2 Контрольная информация (audit trails)<br />

Контрольная информация (audit trail) – это прото<strong>к</strong>ол действий, выполненных с<br />

использованием СЭД, в<strong>к</strong>лючая <strong>к</strong>а<strong>к</strong> действия исполнителей пользовательс<strong>к</strong>их и<br />

административных ролей, та<strong>к</strong> и действия, автоматичес<strong>к</strong>и инициируемые самой СЭД<br />

вследствие определенных системных настрое<strong>к</strong> и установо<strong>к</strong>. Формальное определение<br />

данного термина см. в Глоссарии (раздел 13.1).<br />

Контрольная информация позволяет проверить, соблюдаются ли правила ведения деловой<br />

деятельности, и даёт возможность выявить и отследить неавторизованные действия.<br />

Для обеспечения подотчётности очень важно, чтобы СЭД могла фи<strong>к</strong>сировать в составе<br />

<strong>к</strong>онтрольной информации любые действия, при выполнении <strong>к</strong>оторых в системе в <strong>к</strong>а<strong>к</strong>ой бы<br />

Версия 1.04<br />

8 сентября 2008 Стр. 64


Специфи<strong>к</strong>ации MoReq2<br />

то ни было степени используется автоматичес<strong>к</strong>ая или автоматизированная обработ<strong>к</strong>а.<br />

Примеры та<strong>к</strong>ого взаимодействия приводятся в разделе 10.5 «Работа с досье».<br />

Контрольная информация, в составе <strong>к</strong>оторой сохраняется полная история всех действий со<br />

всеми до<strong>к</strong>ументами (в рам<strong>к</strong>ах ограничений, связанных с уровнем безопасности техничес<strong>к</strong>ой<br />

среды), является <strong>к</strong>лючевым фа<strong>к</strong>тором, позволяющим СЭД выполнить у<strong>к</strong>азанные<br />

<strong>требования</strong>.<br />

При прото<strong>к</strong>олировании всех действий объём <strong>к</strong>онтрольной информации может стать очень<br />

большим. В связи с этим, в ряде случаев, ру<strong>к</strong>оводство может принять решение о том, что<br />

определенные действия, с момента принятия та<strong>к</strong>ого решения, прото<strong>к</strong>олировать не<br />

требуется.<br />

Во многих случаях хранимая «он-лайн» <strong>к</strong>онтрольная информация периодичес<strong>к</strong>и<br />

переносится в автономные системы хранения (off-line storage). Копия, сохраняемая в<br />

автономной системе хранения, может быть уничтожена тогда и толь<strong>к</strong>о тогда, <strong>к</strong>огда все<br />

соответствующие до<strong>к</strong>ументы уничтожены или переданы; либо тогда, <strong>к</strong>огда это допус<strong>к</strong>ается<br />

за<strong>к</strong>онодательством и полити<strong>к</strong>ой организации.<br />

Эти вопросы регулируются за<strong>к</strong>онодательно-нормативными <strong>требования</strong>ми и/или<br />

внутренними нормативными до<strong>к</strong>ументами организации. MoReq2, та<strong>к</strong>им образом, содержит<br />

<strong>требования</strong>, позволяющие реализовать в системе соответствующие операции, но не<br />

устанавливает, <strong>к</strong>а<strong>к</strong> и в <strong>к</strong>а<strong>к</strong>ом объеме они будут использованы.<br />

№ Требование Тест.<br />

4.2.1 СЭД должна сохранять в защищённом от изменений виде <strong>к</strong>онтрольную<br />

информацию (audit trail), в <strong>к</strong>оторую автоматичес<strong>к</strong>и в<strong>к</strong>лючаются<br />

сведения:<br />

Y<br />

о всех действиях, совершённых с до<strong>к</strong>ументами, наборами<br />

до<strong>к</strong>ументов или <strong>к</strong>лассифи<strong>к</strong>ационной схемой;<br />

о пользователе, выполнившем действие;<br />

дата и время совершения действия.<br />

Например, в число действий, фи<strong>к</strong>сируемых в составе <strong>к</strong>онтрольной<br />

информации, должны входить (списо<strong>к</strong> не является исчерпывающим):<br />

ввод в систему эле<strong>к</strong>тронных до<strong>к</strong>ументов;<br />

перемещение эле<strong>к</strong>тронного дела в <strong>к</strong>лассифи<strong>к</strong>ационной схеме (см.<br />

п. 3.4.1);<br />

любые изменения в у<strong>к</strong>азаниях по сро<strong>к</strong>ам хранения и последующим<br />

действиям с до<strong>к</strong>ументами;<br />

любые действия, выполненные исполнителями<br />

административных ролей в ходе э<strong>к</strong>спертизы ценности<br />

до<strong>к</strong>ументов;<br />

наложение и снятие запрета на уничтожение эле<strong>к</strong>тронного<br />

дела (disposal hold);<br />

Версия 1.04<br />

8 сентября 2008 Стр. 65


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

любые изменения метаданных рубри<strong>к</strong> <strong>к</strong>лассифи<strong>к</strong>ационной схемы,<br />

эле<strong>к</strong>тронных дел и эле<strong>к</strong>тронных до<strong>к</strong>ументов;<br />

внесение изменений и уничтожение метаданных пользователем;<br />

изменения в правах доступа;<br />

создание, модифи<strong>к</strong>ация и уничтожение пользователя или группы<br />

пользователей;<br />

э<strong>к</strong>спорт и передача;<br />

создание представления (presentation) до<strong>к</strong>умента;<br />

стирание/уничтожение до<strong>к</strong>ументов.<br />

Под словами «в защищенном от изменений виде» в данном<br />

требовании понимается то, что внесение изменений либо удаление<br />

<strong>к</strong>а<strong>к</strong>ой-либо части <strong>к</strong>онтрольной информации пользователями и<br />

администраторами должно быть невозможно. Необходимая степень<br />

уверенности зависит от потребностей организации; достижимый<br />

уровень уверенности будет зависеть от уровня безопасности,<br />

обеспечиваемого базовой операционной системой и программным<br />

обеспечением системы.<br />

Допус<strong>к</strong>ается, одна<strong>к</strong>о, реорганизация и <strong>к</strong>опирование <strong>к</strong>онтрольной<br />

информации в автономные системы хранения, если это требуется,<br />

например, в интересах СУБД, - при условии сохранения<br />

целостности <strong>к</strong>онтрольной информации.<br />

4.2.2 Если СЭД поддерживает передачу <strong>к</strong>онтрольной информации в<br />

автономную систему хранения (off-line storage), то СЭД должна<br />

поддерживать защищённые процессы управления данными в<br />

автономной системе, и должна по<strong>к</strong>азать, <strong>к</strong>а<strong>к</strong>им образом данные из<br />

автономной системы будут, <strong>к</strong>огда потребуется, возвращены в онлайндоступ.<br />

СЭД должна обеспечить, чтобы этот механизм невозможно<br />

было использовать для обхода средств <strong>к</strong>онтроля СЭД (например,<br />

просто выводя <strong>к</strong>онтрольную информацию из СЭД, и изменяя или<br />

удаляя её уже вне СЭД).<br />

4.2.3 Желательно, чтобы СЭД могла автоматичес<strong>к</strong>и фи<strong>к</strong>сировать в составе<br />

<strong>к</strong>онтрольной информации все случаи доступа <strong>к</strong> до<strong>к</strong>ументам и наборам<br />

до<strong>к</strong>ументов, а та<strong>к</strong>же вид доступа - чтение, печать или иное<br />

отображение информации.<br />

P<br />

Y<br />

Обычно это нужно толь<strong>к</strong>о в среде с очень высо<strong>к</strong>ими <strong>требования</strong>ми<br />

по безопасности.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 66


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

4.2.4 В СЭД должна иметься возможность настраивать процесс сохранения<br />

<strong>к</strong>онтрольной информации, с тем, чтобы исполнители<br />

административных ролей могли выбрать те действия, сведения о<br />

<strong>к</strong>оторых будут автоматичес<strong>к</strong>и прото<strong>к</strong>олироваться.<br />

4.2.5 Все изменения в настрой<strong>к</strong>ах процесса сохранения <strong>к</strong>онтрольной<br />

информации сами должны прото<strong>к</strong>олироваться в составе <strong>к</strong>онтрольной<br />

информации.<br />

Y<br />

Y<br />

Желательно, чтобы невозможно было от<strong>к</strong>лючить прото<strong>к</strong>олирование<br />

изменений в настрой<strong>к</strong>ах процесса сохранения <strong>к</strong>онтрольной<br />

информации, - например, в попыт<strong>к</strong>е избежать записи в <strong>к</strong>онтрольную<br />

информацию сведений о том, <strong>к</strong>то и <strong>к</strong>огда изменил эти настрой<strong>к</strong>и.<br />

4.2.6 После установ<strong>к</strong>и параметров процесса сохранения <strong>к</strong>онтрольной<br />

информации, СЭД должна отслеживать соответствующие действия в<br />

автоматичес<strong>к</strong>ом режиме, и вносить сведения о них в <strong>к</strong>онтрольную<br />

информацию.<br />

4.2.7 СЭД должна сохранять <strong>к</strong>онтрольную информацию столь<strong>к</strong>о времени,<br />

с<strong>к</strong>оль<strong>к</strong>о требуется согласно полити<strong>к</strong>е организации в области<br />

управления до<strong>к</strong>ументами.<br />

Y<br />

N<br />

Часто этот период времени должен быть не менее, чем сро<strong>к</strong><br />

существования эле<strong>к</strong>тронных до<strong>к</strong>ументов, <strong>к</strong> <strong>к</strong>оторым относится<br />

<strong>к</strong>онтрольная информация. Одна<strong>к</strong>о возможны ситуации, в <strong>к</strong>оторых<br />

применяется иная полити<strong>к</strong>а, - например, проводится периодичес<strong>к</strong>ий<br />

анализ <strong>к</strong>онтрольной информации, после чего <strong>к</strong>онтрольная<br />

информация уничтожается и заменяется сертифи<strong>к</strong>атом о<br />

прохождении та<strong>к</strong>ого рода провер<strong>к</strong>и.<br />

4.2.8 СЭД должна обеспечить сохранение <strong>к</strong>онтрольной информации обо<br />

всех действиях, выполненных над до<strong>к</strong>ументами, томами, суб-делами,<br />

делами, рубри<strong>к</strong>ами, сро<strong>к</strong>ами хранения, - независимо от того,<br />

затрагивает ли совершенное действие один или нес<strong>к</strong>оль<strong>к</strong>о из<br />

перечисленных объе<strong>к</strong>тов.<br />

4.2.9 СЭД должна обеспечить сохранение <strong>к</strong>онтрольной информации обо<br />

всех изменениях в значениях метаданных, <strong>к</strong>оторые затрагивают<br />

элементы метаданных, перечисленные в модели метаданных MoReq2.<br />

4.2.10 Любые внесенные в до<strong>к</strong>умент поправ<strong>к</strong>и, или аннотации <strong>к</strong> нему, должны<br />

быть зафи<strong>к</strong>сированы в составе <strong>к</strong>онтрольной информации для данного<br />

до<strong>к</strong>умента.<br />

4.2.11 СЭД должна обеспечить автоматичес<strong>к</strong>ое сохранение <strong>к</strong>онтрольной<br />

информации обо всех изменениях в параметрах администрирования.<br />

P<br />

P<br />

Y<br />

Y<br />

Например, в том случае, если исполнитель административной роли<br />

изменяет права доступа пользователя или параметры процесса<br />

записи <strong>к</strong>онтрольной информации.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 67


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

4.2.12 СЭД должна обеспечить доступность <strong>к</strong>онтрольной информации для<br />

инспе<strong>к</strong>ции по требованию, та<strong>к</strong>им образом, чтобы была возможность<br />

идентифицировать определённое событие и получить все связанные с<br />

ним данные.<br />

4.2.13 СЭД должна иметь фун<strong>к</strong>циональные возможности, позволяющие<br />

авторизованным пользователям, в<strong>к</strong>лючая та<strong>к</strong>их, <strong>к</strong>то мало или совсем<br />

не зна<strong>к</strong>омым с данной системой, вести, тем не менее, поис<strong>к</strong> сведений в<br />

массиве <strong>к</strong>онтрольной информации.<br />

Y<br />

P<br />

Данное требование обеспечивает удобство пользования системой.<br />

Не<strong>к</strong>оторые из пользователей могут быть «внешними» по<br />

отношению <strong>к</strong> организации, - например, внешние аудиторы. Тем не<br />

менее, с точ<strong>к</strong>и зрения СЭД, они та<strong>к</strong>же являются её пользователями.<br />

4.2.14 СЭД должна давать пользователям возможность ис<strong>к</strong>ать в <strong>к</strong>онтрольной<br />

информации сведения, связанные с определенными событиями,<br />

объе<strong>к</strong>тами (рубри<strong>к</strong>ами, до<strong>к</strong>ументами и т.д.), пользователями, группами,<br />

ролями, моментами или интервалами времени.<br />

4.2.15 В СЭД должна иметься возможность э<strong>к</strong>спортировать <strong>к</strong>онтрольную<br />

информацию, относящуюся <strong>к</strong> определённым до<strong>к</strong>ументам, томам, субделам,<br />

делам и рубри<strong>к</strong>ам, не внося при этом <strong>к</strong>а<strong>к</strong>их-либо изменений в<br />

<strong>к</strong>онтрольную информацию, хранящуюся в СЭД, за ис<strong>к</strong>лючением<br />

добавления <strong>к</strong>онтрольной информации о самом процессе э<strong>к</strong>спорта.<br />

Y<br />

Y<br />

Эта фун<strong>к</strong>циональная возможность нужна, например, для того,<br />

чтобы дать возможность внешним аудиторам изучать и<br />

анализировать а<strong>к</strong>тивность в системе.<br />

4.2.16 В СЭД должна иметься возможность выявления и прото<strong>к</strong>олирования,<br />

где необходимо, попыто<strong>к</strong> преодоления системы управления доступом<br />

(т.е. попыто<strong>к</strong> пользователей получить неавторизованный доступ <strong>к</strong><br />

до<strong>к</strong>ументам, томам, суб-делам или делам).<br />

Y<br />

Пример обстоятельств, <strong>к</strong>огда возможна попыт<strong>к</strong>а нарушить правила<br />

доступа, см. в п. 4.1.23. Данное требование неприменимо в том<br />

случае, <strong>к</strong>огда система с<strong>к</strong>онфигурирована та<strong>к</strong>им образом, чтобы<br />

с<strong>к</strong>рывать от пользователя все сведения об информации, <strong>к</strong> <strong>к</strong>оторой<br />

тот не имеет прав доступа.<br />

4.3 Резервное <strong>к</strong>опирование и восстановление<br />

Ка<strong>к</strong> за<strong>к</strong>онодательно-нормативные <strong>требования</strong>, та<strong>к</strong> и потребности деловой деятельности<br />

требуют, чтобы в СЭД имелись полноценные средства для регулярного резервного<br />

<strong>к</strong>опирования до<strong>к</strong>ументов и их метаданных. В СЭД должны иметься возможности для<br />

восстановления до<strong>к</strong>ументов с резервных <strong>к</strong>опий в случае их утраты, например, из-за сбоя<br />

системы, аварии, нарушения системы безопасности.<br />

Регулярное автоматизированное резервное <strong>к</strong>опирование и восстановление могут быть<br />

реализованы либо в самой СЭД, либо за счет интеграции со службами или утилитами<br />

Версия 1.04<br />

8 сентября 2008 Стр. 68


Специфи<strong>к</strong>ации MoReq2<br />

эле<strong>к</strong>тронно-информационной системы, ЭИС (EDMS), или со средствами используемой в<br />

СЭД системы управления базами данных, или с иным программным приложением. В рам<strong>к</strong>ах<br />

данного раздела, термин «СЭД» та<strong>к</strong>же подразумевает соответствующие средства<br />

резервного <strong>к</strong>опирования и восстановления.<br />

На пра<strong>к</strong>ти<strong>к</strong>е обязанности по резервному <strong>к</strong>опированию и восстановлению данных чаще<br />

относятся <strong>к</strong> сфере деятельности ИТ-службы организации, чем распределяются между<br />

исполнителями административных ролей в СЭД.<br />

№ Требование Тест.<br />

4.3.1 СЭД должна содержать или допус<strong>к</strong>ать возможность под<strong>к</strong>лючения<br />

автоматизированных процедур резервного <strong>к</strong>опирования и<br />

восстановления, позволяющих проводить регулярное полное или<br />

выборочное резервное <strong>к</strong>опирование рубри<strong>к</strong>, дел, до<strong>к</strong>ументов,<br />

метаданных, параметров администрирования и <strong>к</strong>онтрольной<br />

информации; а та<strong>к</strong>же, при необходимости, их восстановление.<br />

4.3.2 СЭД должна предоставлять исполнителям административных ролей<br />

возможность установить графи<strong>к</strong> выполнения процедур резервного<br />

<strong>к</strong>опирования:<br />

Y<br />

Y<br />

у<strong>к</strong>азывая частоту выполнения резервного <strong>к</strong>опирования;<br />

у<strong>к</strong>азывая рубри<strong>к</strong>и, дела и до<strong>к</strong>ументы, подлежащие<br />

резервированию;<br />

выделяя носители информации, системы или места хранения<br />

резервных <strong>к</strong>опий (это может быть, например, автономная система<br />

хранения, отдельная система или удалённый сайт).<br />

4.3.3 Возможность восстановления информации с резервных <strong>к</strong>опий СЭД<br />

должна предоставлять толь<strong>к</strong>о авторизованным исполнителям<br />

административных ролей.<br />

4.3.4 Когда в СЭД выполняется восстановление данных с резервных <strong>к</strong>опий,<br />

должна быть в полном объёме обеспечена целостность данных<br />

(в<strong>к</strong>лючая <strong>к</strong>онтрольную информацию) по завершении процесса<br />

восстановления.<br />

Y<br />

P<br />

Желательно, чтобы до<strong>к</strong>ументы, <strong>к</strong>оторые были <strong>к</strong>орре<strong>к</strong>тно<br />

уничтожены или переданы из СЭД, и <strong>к</strong>оторые остались на резервных<br />

<strong>к</strong>опиях, не восстанавливались (за ис<strong>к</strong>лючением особых<br />

обстоятельств).<br />

4.3.5 Если в СЭД поддерживается создание «<strong>к</strong>онтрольных точе<strong>к</strong>» и<br />

возможность «на<strong>к</strong>ата» 37 изменений в базе данных, начиная от<br />

восстановленного состояния (roll-forward), - то возможность провести<br />

«на<strong>к</strong>ат» базы данных СЭД должна предоставлять толь<strong>к</strong>о<br />

авторизованным исполнителям административных ролей.<br />

P<br />

37<br />

«На<strong>к</strong>ат» - процедура, при <strong>к</strong>оторой после восстановления данных с полных резервных <strong>к</strong>опий,<br />

сохраненных на определенную дату (например, ежемесячных), выполняется<br />

последовательное восстановление данных с более свежих частичных резервных <strong>к</strong>опий<br />

Версия 1.04<br />

8 сентября 2008 Стр. 69


Специфи<strong>к</strong>ации MoReq2<br />

4.4 Важнейшие до<strong>к</strong>ументы<br />

Важнейшими считаются до<strong>к</strong>ументы, абсолютно необходимые для того, чтобы организация<br />

могла выполнять свои деловые фун<strong>к</strong>ции, - в <strong>к</strong>рат<strong>к</strong>осрочном и/или в долгосрочном плане (см.<br />

та<strong>к</strong>же Глоссарий). Это могут быть <strong>к</strong>а<strong>к</strong> до<strong>к</strong>ументы, жизненно необходимые организации для<br />

выполнения её миссии, – в смысле способности справиться с последствиями чрезвычайных<br />

происшествий и <strong>к</strong>атастроф, - та<strong>к</strong> и до<strong>к</strong>ументы, необходимые для защиты её долгосрочных<br />

правовых и финансовых интересов.<br />

Выявление и защита важнейших до<strong>к</strong>ументов чрезвычайно важны для любой организации. С<br />

большой вероятностью именно эти до<strong>к</strong>ументы первыми понадобятся в случае<br />

чрезвычайных происшествий или <strong>к</strong>атастроф.<br />

До<strong>к</strong>ументы могут считаться важнейшими <strong>к</strong>а<strong>к</strong> для организации в целом, та<strong>к</strong> и для её<br />

отдельных частей. 38<br />

№ Требование Тест.<br />

4.4.1 СЭД должна давать исполнителям административных ролей<br />

возможность помечать определённые дела <strong>к</strong>а<strong>к</strong> содержащие<br />

важнейшие до<strong>к</strong>ументы, а определенные до<strong>к</strong>ументы – <strong>к</strong>а<strong>к</strong> важнейшие.<br />

Y<br />

Желательно, чтобы эта призна<strong>к</strong> в<strong>к</strong>лючался в метаданные в<br />

<strong>к</strong>ачестве их элемента.<br />

4.4.2 СЭД должна поддерживать два различных вида резервного<br />

<strong>к</strong>опирования:<br />

Y<br />

<br />

«полное» резервное <strong>к</strong>опирование, при <strong>к</strong>отором выполняется<br />

резервное <strong>к</strong>опирование всех (или определенных) данных СЭД;<br />

резервное <strong>к</strong>опирование важнейших до<strong>к</strong>ументов, при <strong>к</strong>отором<br />

выполняется резервное <strong>к</strong>опирование толь<strong>к</strong>о <strong>к</strong>онфигурации СЭД, а<br />

та<strong>к</strong>же дел и до<strong>к</strong>ументов, отмеченных <strong>к</strong>а<strong>к</strong> «важнейшие».<br />

Два вида резервного <strong>к</strong>опирования нужны для того, чтобы:<br />

проводить плановое резервное <strong>к</strong>опирование важнейших<br />

до<strong>к</strong>ументов чаще, чем плановое «полное» резервное <strong>к</strong>опирование<br />

данных СЭД;<br />

при резервном <strong>к</strong>опировании важнейших до<strong>к</strong>ументов, записывать<br />

резервную <strong>к</strong>опию на другие носители информации и сохранять<br />

отдельно (возможно, обеспечивая бóльшую защиту) от «полных»<br />

резервных <strong>к</strong>опий.<br />

38<br />

(например, еженедельных или ежедневных) и/или установ<strong>к</strong>а обновлений программного<br />

обеспечения, выпущенных с момента снятия полной резервной <strong>к</strong>опии. Та<strong>к</strong>им образом, база<br />

данных «подтягивается» до а<strong>к</strong>туального состояния. (прим. переводчи<strong>к</strong>а)<br />

Подробнее о важнейших до<strong>к</strong>ументах см. в статье Н.А.Храмцовс<strong>к</strong>ой «Программа сохранения<br />

важнейших до<strong>к</strong>ументов <strong>к</strong>омпании», Делопроизводство и до<strong>к</strong>ументооборот на предприятии,<br />

№ 6, июнь 2004, г., http://www.eos.ru/eos_delopr/eos_analitics/detail.php?ID=13377 (прим.<br />

переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 70


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Это та<strong>к</strong>же позволяет организовать более управляемый процесс<br />

восстановления работоспособности СЭД, пос<strong>к</strong>оль<strong>к</strong>у восстановление<br />

важнейших до<strong>к</strong>ументов может проводиться полностью независимо<br />

от «полного» восстановления, и в другое время.<br />

Ка<strong>к</strong> отмечено в разделе 4.3, резервное <strong>к</strong>опирование может<br />

выполняться <strong>к</strong>а<strong>к</strong> средствами самой СЭД, та<strong>к</strong> и за счет интеграции<br />

с другим программным обеспечением.<br />

4.4.3 СЭД должна обеспечивать, чтобы, после восстановления с «резервной<br />

<strong>к</strong>опии важнейших до<strong>к</strong>ументов», система была полностью<br />

работоспособна.<br />

P<br />

После восстановления с «резервной <strong>к</strong>опии важнейших до<strong>к</strong>ументов»<br />

многие дела и до<strong>к</strong>ументы будут отсутствовать. В остальном,<br />

одна<strong>к</strong>о, необходимо, чтобы работоспособность СЭД и<br />

предоставляемые ею пользователям фун<strong>к</strong>циональные возможности<br />

ни<strong>к</strong>оим образом не были ограничены.<br />

4.4.4 Желательно, чтобы СЭД поддерживала два способа восстановления с<br />

«полной» резервной <strong>к</strong>опии:<br />

Y<br />

восстановление системы «заново», <strong>к</strong>огда в процессе<br />

восстановления данные с «полной» резервной <strong>к</strong>опии<br />

перезаписывают и заменяют СЭД;<br />

восстановление "поверх" существующей среды СЭД, <strong>к</strong>огда в<br />

процессе восстановления производится слияние данных из<br />

«полной» резервной <strong>к</strong>опии с данными существующей среды СЭД.<br />

Первый способ восстановления будет часто использоваться в<br />

организациях, не создающих «резервные <strong>к</strong>опии важнейших<br />

до<strong>к</strong>ументов».<br />

Второй метод восстановления будет применяться в тех случаях,<br />

<strong>к</strong>огда ранее СЭД уже была частично восстановлена с «резервной<br />

<strong>к</strong>опии важнейших до<strong>к</strong>ументов» и начала нормально работать. В<br />

этом случае возни<strong>к</strong>ает необходимость провести слияние с данными<br />

«полной» резервной <strong>к</strong>опии, не перезаписывая при этом <strong>к</strong>а<strong>к</strong> ранее<br />

восстановленные важнейшие дела и до<strong>к</strong>ументы, та<strong>к</strong> и добавленные<br />

в СЭД с момента возвращения <strong>к</strong> нормальной работе новые объе<strong>к</strong>ты;<br />

и не теряя сделанные за это время изменения.<br />

Если СЭД поддерживает два способа восстановления с «полной»<br />

резервной <strong>к</strong>опии, <strong>к</strong>а<strong>к</strong> это описано в п. 4.4.4, то восстановление с<br />

«резервной <strong>к</strong>опии важнейших до<strong>к</strong>ументов» (если она существует)<br />

всегда будет проводиться в первую очередь. Вариант<br />

восстановления с «резервной <strong>к</strong>опии важнейших до<strong>к</strong>ументов» после<br />

восстановления с «полной» резервной <strong>к</strong>опии не рассматривается.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 71


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

При выполнении подобного двухэтапного восстановления системы,<br />

исполнителям административных ролей, возможно, придётся в<br />

ручном режиме разрешать возни<strong>к</strong>ающие <strong>к</strong>онфли<strong>к</strong>ты. Например,<br />

<strong>к</strong>лассифи<strong>к</strong>ационная схема, сохраненная в одной резервной <strong>к</strong>опии,<br />

может отличаться от той, что сохранена в другой резервной <strong>к</strong>опии.<br />

4.4.5 СЭД должна давать исполнителям административных ролей<br />

возможность отметить, что определенные дела или до<strong>к</strong>ументы более<br />

не рассматриваются <strong>к</strong>а<strong>к</strong> важнейшие. Данное действие должно быть<br />

зафи<strong>к</strong>сировано в <strong>к</strong>онтрольной информации.<br />

Y<br />

Например, может истечь сро<strong>к</strong> действия <strong>к</strong>онтра<strong>к</strong>та или договора<br />

аренды, и они уже не будут рассматриваться <strong>к</strong>а<strong>к</strong> важнейшие<br />

до<strong>к</strong>ументы.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 72


Специфи<strong>к</strong>ации MoReq2<br />

5. СРОКИ ХРАНЕНИЯ, УНИЧТОЖЕНИЕ И ПЕРЕДАЧА<br />

ДОКУМЕНТОВ<br />

В данной главе перечисляются <strong>требования</strong>, относящиеся <strong>к</strong> использованию у<strong>к</strong>азаний по<br />

сро<strong>к</strong>ам хранения и по действиям с до<strong>к</strong>ументами по истечении этих сро<strong>к</strong>ов (retention and<br />

disposition schedules) (далее - "сро<strong>к</strong>и хранения") для управления хранением в течение<br />

установленного сро<strong>к</strong>а (retention) и о<strong>к</strong>ончательным решением судьбы до<strong>к</strong>ументов,<br />

образующихся в ходе те<strong>к</strong>ущей деятельности. Сро<strong>к</strong>и хранения устанавливают, в течение<br />

<strong>к</strong>а<strong>к</strong>ого времени до<strong>к</strong>ументы должны сохраняться СЭД, и что с ними произойдет потом.<br />

Требования <strong>к</strong> сро<strong>к</strong>ам хранения приведены разделе 5.1; а формальное определение<br />

термина можно найти в Глоссарии.<br />

В последующих разделах описаны процессы, <strong>к</strong>оторые могут происходить по истечении<br />

установленного в перечнях сро<strong>к</strong>а хранения. Требования <strong>к</strong> процессам э<strong>к</strong>спертизы ценности и<br />

отбора до<strong>к</strong>ументов на постоянное хранение, передачу или уничтожение, приведены в<br />

разделе 5.2, а <strong>требования</strong> <strong>к</strong> процессам передачи, э<strong>к</strong>спорта и уничтожения – в разделе 5.3.<br />

Ка<strong>к</strong> объясняется в подразделе «Эле<strong>к</strong>тронное дело, суб-дело и том» раздела 2.2, в<br />

зависимости от деловых потребностей, до<strong>к</strong>ументами можно управлять на уровне рубри<strong>к</strong>,<br />

дел, суб-дел или томов. В зависимости от обстоятельств, сро<strong>к</strong>и хранения устанавливаются<br />

для рубри<strong>к</strong>, дел, и/или суб-дел и/или томов. Сро<strong>к</strong>и хранения та<strong>к</strong>же могут быть установлены<br />

для типов до<strong>к</strong>ументов, с тем, например, чтобы можно было установить <strong>к</strong>орот<strong>к</strong>ие сро<strong>к</strong>и<br />

хранения для до<strong>к</strong>ументов, содержащих <strong>к</strong>онфиденциальные персональные данные; или ;t<br />

длительные сро<strong>к</strong>и хранения - для <strong>к</strong>онстру<strong>к</strong>торс<strong>к</strong>их чертежей. Предусматривается та<strong>к</strong>же<br />

механизм разрешения <strong>к</strong>онфли<strong>к</strong>тов между сро<strong>к</strong>ами хранения.<br />

В MoReq2 в<strong>к</strong>лючено понятие «замораживания» (запрета) процесса решения судьбы<br />

до<strong>к</strong>ументов (далее – «запрет на уничтожение»), <strong>к</strong>оторое отсутствовало в предыдущей<br />

версии MoReq. Запреты на уничтожение используются для реагирования на<br />

непредвиденные события, позволяя гарантировать, что определенные до<strong>к</strong>ументы не будут<br />

уничтожены. Типичным примером является случай, <strong>к</strong>огда до<strong>к</strong>ументы, <strong>к</strong>оторые требуются<br />

(или могут потребоваться) в <strong>к</strong>ачестве до<strong>к</strong>азательств в суде, не должны уничтожаться в<br />

рам<strong>к</strong>ах регулярного процесса уничтожения до<strong>к</strong>ументов на основании решений, принятых в<br />

ходе э<strong>к</strong>спертизы ценности.<br />

5.1 Сро<strong>к</strong>и хранения (Retention and Disposition Schedules)<br />

№ Требование Тест.<br />

5.1.1 Толь<strong>к</strong>о исполнителям административных ролей СЭД должна<br />

предоставлять возможность создавать и модифицировать сро<strong>к</strong>и<br />

хранения (объе<strong>к</strong>ты СЭД, содержащие у<strong>к</strong>азания в отношении сро<strong>к</strong>ов<br />

хранения и действий, выполняемым по истечении этих сро<strong>к</strong>ов).<br />

Y<br />

5.1.2 СЭД не должна ограничивать <strong>к</strong>оличество сро<strong>к</strong>ов хранения. P<br />

5.1.3 Желательно, чтобы СЭД могла организовать сро<strong>к</strong>и хранения в<br />

иерархичес<strong>к</strong>ую стру<strong>к</strong>туру, напоминающую стру<strong>к</strong>туру типовых и<br />

ведомственных перечней с у<strong>к</strong>азанием сро<strong>к</strong>ов хранения, утвержденных<br />

соответствующими органами.<br />

N<br />

Версия 1.04<br />

8 сентября 2008 Стр. 73


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Подобная иерархичес<strong>к</strong>ая стру<strong>к</strong>тура упрощает управление<br />

многочисленными сро<strong>к</strong>ами хранения.<br />

5.1.4 При создании сро<strong>к</strong>а хранения, СЭД должна присваивать ему<br />

уни<strong>к</strong>альный идентифи<strong>к</strong>атор.<br />

5.1.5 При создании сро<strong>к</strong>а хранения, СЭД должна давать возможность ввести<br />

для него уни<strong>к</strong>альное наименование.<br />

5.1.6 СЭД должна вести и сохранять в защищенном от изменений виде<br />

историю внесения изменений и уничтожения сро<strong>к</strong>ов хранения<br />

(<strong>к</strong>онтрольную информацию), в<strong>к</strong>лючающую дату изменения или<br />

уничтожения, и информацию о пользователе, внесшем изменения.<br />

5.1.7 СЭД должна обеспечить, чтобы любые исправления в сро<strong>к</strong>ах хранения<br />

немедленно распространялись на все объе<strong>к</strong>ты, <strong>к</strong>оторым этот сро<strong>к</strong><br />

хранения установлен. 39<br />

5.1.8 СЭД должна требовать, чтобы исполнитель административной роли,<br />

изменяющий или уничтожающий сро<strong>к</strong> хранения, у<strong>к</strong>азывал причину<br />

изменений; и должна сохранять эту причину в <strong>к</strong>онтрольной<br />

информации.<br />

Y<br />

Y<br />

Y<br />

Y<br />

Y<br />

Внесение изменений и уничтожение сро<strong>к</strong>ов хранения должны<br />

тщательно <strong>к</strong>онтролироваться, с целью минимизации рис<strong>к</strong>а<br />

несан<strong>к</strong>ционированного уничтожения до<strong>к</strong>ументов.<br />

5.1.9 СЭД должна быть способна импортировать и э<strong>к</strong>спортировать сро<strong>к</strong>и<br />

хранения.<br />

5.1.10 СЭД должна обеспечить, чтобы <strong>к</strong>аждой рубри<strong>к</strong>е, делу, суб-делу и тому<br />

всегда был назначен <strong>к</strong>а<strong>к</strong> минимум один сро<strong>к</strong> хранения.<br />

P<br />

Y<br />

Данное требование введено для того, чтобы ис<strong>к</strong>лючить<br />

возможность создания объе<strong>к</strong>тов, не имеющих сро<strong>к</strong>ов хранения, а<br />

та<strong>к</strong>же для удобства работы в СЭД.<br />

5.1.11 Желательно, чтобы сро<strong>к</strong> хранения, устанавливаемый по умолчанию<br />

для <strong>к</strong>аждой вновь созданной рубри<strong>к</strong>и, дела, суб-дела или тома,<br />

наследовался от их родительс<strong>к</strong>ого объе<strong>к</strong>та.<br />

Y<br />

39<br />

Администраторы СЭД, управляющие сро<strong>к</strong>ами хранения, должны отдавать себе отчет в том,<br />

что потенциально это очень опасная фун<strong>к</strong>циональная возможность. Например, <strong>к</strong>огда в<br />

за<strong>к</strong>онодательстве изменяется сро<strong>к</strong> хранения определенного вида до<strong>к</strong>ументов, это решение не<br />

имеет обратной силы, - т.е. для до<strong>к</strong>ументов, созданных до изменения в за<strong>к</strong>онодательстве,<br />

продолжает действовать старый сро<strong>к</strong> хранения. Новый сро<strong>к</strong> хранения может быть установлен<br />

старым до<strong>к</strong>ументам толь<strong>к</strong>о в том случае, если это специально оговорено за<strong>к</strong>онодательством.<br />

В этой ситуации нельзя будет (по <strong>к</strong>райней мере, без детального анализа последствий) просто<br />

взять и модифицировать существующий сро<strong>к</strong> хранения в СЭД, пос<strong>к</strong>оль<strong>к</strong>у тогда изменения<br />

могут охватить все до<strong>к</strong>ументы данного вида. (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 74


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Там, где это невозможно (для рубри<strong>к</strong>, расположенных на верхнем<br />

уровне <strong>к</strong>лассифи<strong>к</strong>ационной схемы, или же в случаях, <strong>к</strong>огда<br />

отсутствуют сро<strong>к</strong>и хранения, <strong>к</strong>оторые можно было бы<br />

унаследовать - см. п.5.1.18), - желательно, чтобы назначался сро<strong>к</strong><br />

хранения по умолчанию.<br />

5.1.12 Каждому до<strong>к</strong>ументу, размещенному непосредственно в рубри<strong>к</strong>е, всегда<br />

должен быть установлен <strong>к</strong>а<strong>к</strong> минимум один сро<strong>к</strong> хранения.<br />

5.1.13 Сро<strong>к</strong>и хранения, устанавливаемые по умолчанию <strong>к</strong>аждому новому<br />

до<strong>к</strong>ументу, размещенному непосредственно в рубри<strong>к</strong>е (см. п.3.2.17<br />

раздела 3.2), должны наследоваться от этой родительс<strong>к</strong>ой рубри<strong>к</strong>и.<br />

5.1.14 СЭД должна давать возможность исполнителю административной<br />

роли в любой момент применить сро<strong>к</strong> хранения <strong>к</strong> любой рубри<strong>к</strong>е, делу,<br />

суб-делу, тому и типу до<strong>к</strong>умента.<br />

Y<br />

Y<br />

Y<br />

Слова «в любой момент» означают, что исполнитель<br />

административной роли может заменить сро<strong>к</strong> хранения или (если<br />

система поддерживает одновременное применение <strong>к</strong> объе<strong>к</strong>ту<br />

нес<strong>к</strong>оль<strong>к</strong>их сро<strong>к</strong>ов хранения, см. п.5.1.16) назначить дополнительный<br />

сро<strong>к</strong> хранения для любой рубри<strong>к</strong>и, дела, суб-дела, тома или типа<br />

до<strong>к</strong>умента. Примером может служить замена сро<strong>к</strong>а хранения,<br />

установленного по умолчанию; еще один пример – назначение<br />

дополнительного сро<strong>к</strong>а хранения для до<strong>к</strong>ументов, относящихся <strong>к</strong><br />

проводимому <strong>к</strong>онтролирующим органом расследованию. В<br />

результате может возни<strong>к</strong>нуть <strong>к</strong>онфли<strong>к</strong>т между сро<strong>к</strong>ами хранения:<br />

см. п.5.1.23.<br />

5.1.15 Желательно, чтобы СЭД могла устанавливать типам до<strong>к</strong>умента сро<strong>к</strong><br />

хранения по умолчанию.<br />

Y<br />

Подразумевается, что возможно существование типов до<strong>к</strong>умента,<br />

для <strong>к</strong>оторых сро<strong>к</strong> хранения не установлен. Это допустимо,<br />

пос<strong>к</strong>оль<strong>к</strong>у любой отдельный до<strong>к</strong>умент будет иметь <strong>к</strong>а<strong>к</strong> минимум<br />

один сро<strong>к</strong> хранения, - ввиду того, что все до<strong>к</strong>ументы хранятся в<br />

делах и рубри<strong>к</strong>ах, а <strong>к</strong>аждому делу и рубри<strong>к</strong>е, согласно требованию<br />

5.1.10, обязательно должен быть установлен <strong>к</strong>а<strong>к</strong> минимум один сро<strong>к</strong><br />

хранения.<br />

5.1.16 СЭД должна давать возможность назначить любой рубри<strong>к</strong>е, делу, субделу<br />

или тому более одного сро<strong>к</strong>а хранения.<br />

Y<br />

Версия 1.04<br />

8 сентября 2008 Стр. 75


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Это необходимо для того, чтобы справляться с встречающимися<br />

на пра<strong>к</strong>ти<strong>к</strong>е ситуациями, в <strong>к</strong>оторых приходится учитывать ряд<br />

требований по сро<strong>к</strong>ам хранения, возни<strong>к</strong>ающих в связи с различными<br />

за<strong>к</strong>онодательно-нормативными <strong>требования</strong>ми и деловыми<br />

потребностями. Ниже приводится в <strong>к</strong>ачестве иллюстрации один<br />

пример, выбранный из множества возможных.<br />

В этом примере, у дела имеется единственный сро<strong>к</strong> хранения,<br />

установленный исходя из деловых потребностей, пос<strong>к</strong>оль<strong>к</strong>у<br />

предполагается, что содержащиеся в деле до<strong>к</strong>ументы не<br />

подпадают под за<strong>к</strong>онодательно-нормативные <strong>требования</strong> <strong>к</strong> сро<strong>к</strong>ам<br />

хранения. Назначенный данному делу сро<strong>к</strong> хранения та<strong>к</strong>же назначен<br />

многим другим делам.<br />

В <strong>к</strong>а<strong>к</strong>ой-то момент времени становится ясно, что в связи с<br />

определенным вопросом, связанным с безопасностью на рабочем<br />

месте, это дело, возможно, придется хранить дольше, чем<br />

предусмотрено его те<strong>к</strong>ущим сро<strong>к</strong>ом хранения. Кажется вероятным,<br />

что содержимое данного дела может стать предметов провер<strong>к</strong>и<br />

органом, <strong>к</strong>онтролирующим исполнение требований по охране труда.<br />

В этой связи делу назначается второй сро<strong>к</strong> хранения, учитывающий<br />

эти обстоятельства.<br />

Позднее может выясниться, что проблем с техни<strong>к</strong>ой<br />

безопасности на самом деле не было. В этом случае второй сро<strong>к</strong><br />

хранения может быть отменен, оставляя в <strong>к</strong>ачестве действующего<br />

первоначальный сро<strong>к</strong> хранения.<br />

5.1.17 Длительность хранения и дальнейшая судьба (уничтожение или<br />

передача) <strong>к</strong>аждого до<strong>к</strong>умента должна определяться сро<strong>к</strong>ом (сро<strong>к</strong>ами)<br />

хранения, установленными для рубри<strong>к</strong>и, дела, суб-дела, тома и для<br />

того типа до<strong>к</strong>умента, <strong>к</strong> <strong>к</strong>оторым данный до<strong>к</strong>умент принадлежит, а та<strong>к</strong>же<br />

соответствующими запретами на уничтожение (см. п. 5.1.34).<br />

Y<br />

Ка<strong>к</strong> толь<strong>к</strong>о сро<strong>к</strong> хранения установлен, он с этого момента<br />

определяет порядо<strong>к</strong> хранения и уничтожения до<strong>к</strong>ументов,<br />

ассоциированных с тем объе<strong>к</strong>том, <strong>к</strong>оторому он назначен (если<br />

толь<strong>к</strong>о его не "пересиливает" другой сро<strong>к</strong> хранения).<br />

5.1.18 СЭД должна поддерживать возможность наследования сро<strong>к</strong>ов<br />

хранения и вносимых в них изменений вниз по иерархичес<strong>к</strong>ой<br />

стру<strong>к</strong>туре <strong>к</strong>лассифи<strong>к</strong>ационной схемы, опционально используемую<br />

исполнителем административной роли.<br />

Y<br />

Будет ли наследоваться сро<strong>к</strong> хранения или нет, определяется<br />

исполнителем административной роли с использованием<br />

соответствующих средств. MoReq2 не предписывает <strong>к</strong>а<strong>к</strong>ого-то<br />

<strong>к</strong>он<strong>к</strong>ретного способа. Возможны следующие варианты:<br />

выбор делается в момент создания сро<strong>к</strong>а хранения (и<br />

используется вся<strong>к</strong>ий раз, <strong>к</strong>огда данный сро<strong>к</strong> хранения<br />

назначается <strong>к</strong>а<strong>к</strong>ому-либо объе<strong>к</strong>ту) ;<br />

Версия 1.04<br />

8 сентября 2008 Стр. 76


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

выбор делается в момент назначения сро<strong>к</strong>а хранения объе<strong>к</strong>ту (в<br />

этом случае он распространяется на все объе<strong>к</strong>ты-потом<strong>к</strong>и);<br />

в момент создания объе<strong>к</strong>та принимается решение, наследовать<br />

ли ему сро<strong>к</strong>и хранения родительс<strong>к</strong>ого объе<strong>к</strong>та.<br />

5.1.19 Объе<strong>к</strong>т СЭД «сро<strong>к</strong> хранения» должен содержать:<br />

Y<br />

собственно сро<strong>к</strong> хранения (5.1.25) и событие, инициирующее отсчет<br />

сро<strong>к</strong>а хранения (trigger event) (5.1.25);<br />

либо<br />

<br />

дату о<strong>к</strong>ончания сро<strong>к</strong>а хранения.<br />

5.1.20 Объе<strong>к</strong>т СЭД «сро<strong>к</strong> хранения» должен содержать:<br />

Y<br />

у<strong>к</strong>азание о дальнейших действиях с до<strong>к</strong>ументами по истечении<br />

сро<strong>к</strong>а хранения (5.1.24);<br />

обоснование.<br />

5.1.21 Желательно, чтобы объе<strong>к</strong>т СЭД «сро<strong>к</strong> хранения» содержал:<br />

Y<br />

описание;<br />

нормативную ссыл<strong>к</strong>у.<br />

Нормативная ссыл<strong>к</strong>а (mandate) обосновывает правомерность сро<strong>к</strong>а<br />

хранения. Часто это ссыл<strong>к</strong>а на за<strong>к</strong>он, нормативный а<strong>к</strong>т или<br />

внутренний нормативный до<strong>к</strong>умент организации.<br />

5.1.22 Когда у до<strong>к</strong>ументов за<strong>к</strong>анчивается назначенный им сро<strong>к</strong> хранения,<br />

СЭД должна автоматичес<strong>к</strong>и инициировать процесс выполнения<br />

решения о дальнейшей судьбе до<strong>к</strong>ументов.<br />

Y<br />

Это может означать <strong>к</strong>а<strong>к</strong> исполнение этого решения (в<br />

соответствии с п.5.2.4), та<strong>к</strong> и обращение <strong>к</strong> исполнителю<br />

административной роли с требованием выполнить<br />

соответствующее действие (см. п.5.1.23). В связи с рис<strong>к</strong>ами,<br />

связанными с автоматичес<strong>к</strong>им выполнением решений об<br />

уничтожении или передаче до<strong>к</strong>ументов, не<strong>к</strong>оторые организации<br />

могут предпочесть для реализации второй вариант.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 77


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

5.1.23 Когда СЭД инициирует выполнение решения о дальнейшей судьбе<br />

до<strong>к</strong>ументов (см. п.5.1.22), то в случае, <strong>к</strong>огда одновременно применимы<br />

другие сро<strong>к</strong>и хранения, устанавливающие иное время о<strong>к</strong>ончания<br />

периода хранения и/или содержащие иные решения, то возни<strong>к</strong>ает<br />

<strong>к</strong>онфли<strong>к</strong>т. Должна иметься возможность та<strong>к</strong> с<strong>к</strong>онфигурировать СЭД,<br />

чтобы при возни<strong>к</strong>новении <strong>к</strong>онфли<strong>к</strong>та она автоматичес<strong>к</strong>и<br />

информировала об этом исполнителя административной роли, с тем,<br />

чтобы тот разрешил этот <strong>к</strong>онфли<strong>к</strong>т.<br />

Y<br />

Фраза "должна иметься возможность..." в<strong>к</strong>лючена в связи с<br />

отсутствием <strong>требования</strong> о том, чтобы исполнитель<br />

административной роли вмешивался в любых ситуациях.<br />

Допус<strong>к</strong>ается, чтобы СЭД автоматичес<strong>к</strong>и разрешала <strong>к</strong>онфли<strong>к</strong>ты;<br />

одна<strong>к</strong>о должна иметься возможность с<strong>к</strong>онфигурировать СЭД та<strong>к</strong>им<br />

образом, чтобы в случае <strong>к</strong>онфли<strong>к</strong>та требовалось вмешательство<br />

исполнителя административной роли.<br />

Конфли<strong>к</strong>т может возни<strong>к</strong>нуть вследствие того, что:<br />

согласно одним сро<strong>к</strong>ам хранения, процесс решения судьбы<br />

до<strong>к</strong>ументов должен быть инициирован, в то время, <strong>к</strong>а<strong>к</strong>, согласно<br />

другим, этого делать не следует;<br />

и/или<br />

различные объе<strong>к</strong>ты СЭД «сро<strong>к</strong> хранения» содержат разные<br />

у<strong>к</strong>азания о дальнейшей судьбе до<strong>к</strong>ументов по истечении сро<strong>к</strong>ов<br />

хранения.<br />

В большинстве случаев будет достаточно просто определить,<br />

<strong>к</strong>а<strong>к</strong>ой из сро<strong>к</strong>ов хранения имеет преимущество.<br />

Возможны два сценария возни<strong>к</strong>новения <strong>к</strong>онфли<strong>к</strong>тов:<br />

все <strong>к</strong>онфли<strong>к</strong>тующие сро<strong>к</strong>и хранения относятся <strong>к</strong>о всему набору<br />

до<strong>к</strong>ументов (та<strong>к</strong>ому, <strong>к</strong>а<strong>к</strong> дело) в целом;<br />

одни сро<strong>к</strong>и хранения относятся <strong>к</strong>о всему набору до<strong>к</strong>ументов, а<br />

другие - <strong>к</strong> отдельным до<strong>к</strong>ументам в этом наборе (последние<br />

установлены для определенных типов до<strong>к</strong>ументов, <strong>к</strong>оторые<br />

встречаются в наборе).<br />

Вмешательство исполнителя административной роли может<br />

потребоваться в тех ситуациях, <strong>к</strong>огда непра<strong>к</strong>тично заниматься<br />

разработ<strong>к</strong>ой правил, позволяющих правильно разрешать та<strong>к</strong>ие<br />

<strong>к</strong>онфли<strong>к</strong>ты в автоматичес<strong>к</strong>ом режиме. Например:<br />

два сро<strong>к</strong>а хранения, опирающихся на различные за<strong>к</strong>онодательнонормативные<br />

<strong>требования</strong>, устанавливают различные периоды<br />

хранения. Типичным решением здесь было бы сохранение<br />

до<strong>к</strong>ументов до более поздней из дат о<strong>к</strong>ончания периодов<br />

Версия 1.04<br />

8 сентября 2008 Стр. 78


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

хранения;<br />

один из сро<strong>к</strong>ов хранения устанавливает дату, по достижении<br />

<strong>к</strong>оторой определенные до<strong>к</strong>ументы должны быть уничтожены<br />

(<strong>к</strong>а<strong>к</strong> правило, в связи с <strong>требования</strong>ми за<strong>к</strong>онодательства о<br />

защите персональных данных). Если эта дата - более ранняя по<br />

сравнению с той, что устанавливает <strong>к</strong>онфли<strong>к</strong>тующий сро<strong>к</strong><br />

хранения, то принимаемое решение будет зависеть от<br />

относительной "весомости" соответствующего<br />

за<strong>к</strong>онодательства и/или от потребностей деловой<br />

деятельности.<br />

Подобные ситуации могут возни<strong>к</strong>нуть тогда, <strong>к</strong>огда тип до<strong>к</strong>умента<br />

допус<strong>к</strong>ает назначение и наследование сро<strong>к</strong>а хранения от него, а не<br />

от набора до<strong>к</strong>ументов, <strong>к</strong> <strong>к</strong>оторому соответствующий до<strong>к</strong>умент<br />

принадлежит.<br />

При разрешении <strong>к</strong>онфли<strong>к</strong>та исполнитель административной роли<br />

может выполнять любые из перечисленных действий:<br />

отменять один или нес<strong>к</strong>оль<strong>к</strong>о из <strong>к</strong>онфли<strong>к</strong>тующих сро<strong>к</strong>ов<br />

хранения для затронутых <strong>к</strong>онфли<strong>к</strong>том отдельных до<strong>к</strong>ументов<br />

или наборов до<strong>к</strong>ументов;<br />

изменять один или нес<strong>к</strong>оль<strong>к</strong>о из <strong>к</strong>онфли<strong>к</strong>тующих сро<strong>к</strong>ов хранения<br />

с целью устранения <strong>к</strong>онфли<strong>к</strong>та;<br />

отменять все <strong>к</strong>онфли<strong>к</strong>тующие сро<strong>к</strong>и хранения и назначать<br />

новый сро<strong>к</strong> хранения;<br />

использовать возможности по удалению до<strong>к</strong>ументов при<br />

ис<strong>к</strong>лючительных обстоятельствах, описанные в разделе 9.3.<br />

В отсутствие тщательного <strong>к</strong>онтроля, все эти действия могут<br />

привести <strong>к</strong> появлению сомнений в добросовестности управления<br />

до<strong>к</strong>ументами. По этой причине их использование - внесение<br />

изменений в сро<strong>к</strong>и хранения или удаление до<strong>к</strong>ументов - должно<br />

регламентироваться до<strong>к</strong>ументированными процедурами. При<br />

определенных обстоятельствах будут уместны дополнительные<br />

организационные меры, та<strong>к</strong>ие <strong>к</strong>а<strong>к</strong> разделение выполняемых задач.<br />

Если процедура разрешения <strong>к</strong>онфли<strong>к</strong>та приводит <strong>к</strong> тому, что в<br />

массиве до<strong>к</strong>ументов остаются те до<strong>к</strong>ументы, <strong>к</strong>оторые в<br />

противном случае не были бы сохранены, то организации, возможно,<br />

нужно будет та<strong>к</strong>же подготовить ре<strong>к</strong>омендации по их дальнейшему<br />

хранению, <strong>к</strong>оторые могут предусматривать оставление массива<br />

до<strong>к</strong>ументов <strong>к</strong>а<strong>к</strong> есть, либо перемещение (см. раздел 3.4) подобных<br />

"уцелевших" до<strong>к</strong>ументов.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 79


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

5.1.24 СЭД должна, <strong>к</strong>а<strong>к</strong> минимум, допус<strong>к</strong>ать задание в сро<strong>к</strong>ах хранения<br />

следующих вариантов действий с до<strong>к</strong>ументами по истечении сро<strong>к</strong>а<br />

хранения (см. 5.1.20):<br />

Y<br />

хранить постоянно;<br />

провести э<strong>к</strong>спертизу ценности;<br />

уничтожить в автоматичес<strong>к</strong>ом режиме;<br />

уничтожить после получения разрешения (авторизации) от<br />

исполнителя административной роли;<br />

передать на хранение в архив или иное хранилище (см. Глоссарий).<br />

Использование описанного в данном требовании варианта<br />

уничтожения в автоматичес<strong>к</strong>ом режиме влечет за собой<br />

определенные рис<strong>к</strong>и; организациям нужно сбалансировать эти рис<strong>к</strong>и<br />

и выгоду от автоматизации.<br />

5.1.25 СЭД должна, <strong>к</strong>а<strong>к</strong> минимум, допус<strong>к</strong>ать задание в сро<strong>к</strong>ах хранения<br />

следующих <strong>к</strong>омбинаций инициирующих событий и собственно сро<strong>к</strong>ов<br />

хранения (см. п. 5.1.19):<br />

Y<br />

истечение определённого периода времени с момента от<strong>к</strong>рытия<br />

рубри<strong>к</strong>и, дела, суб-дела или тома;<br />

истечение определённого периода времени с момента за<strong>к</strong>рытия<br />

рубри<strong>к</strong>и, дела, суб-дела или тома;<br />

истечение определенного периода времени с момента помещения<br />

в рубри<strong>к</strong>у, дело, суб-дело или том последнего до<strong>к</strong>умента;<br />

истечение определённого периода времени с момента последнего<br />

обращения <strong>к</strong> до<strong>к</strong>ументу из состава рубри<strong>к</strong>и, дела, суб-дела или<br />

тома;<br />

истечение определенного периода времени с момента наступления<br />

внешнего по отношению <strong>к</strong> СЭД события (описание этого события<br />

в<strong>к</strong>лючается в объе<strong>к</strong>т СЭД "сро<strong>к</strong> хранения"; <strong>к</strong>а<strong>к</strong> правило, СЭД<br />

получает извещения о наступлении та<strong>к</strong>их событий от исполнителя<br />

административной роли, а не дете<strong>к</strong>тирует их автоматичес<strong>к</strong>и)<br />

(например, «...после подписания <strong>к</strong>онтра<strong>к</strong>та» или «...спустя 100 лет<br />

со дня рождения»);<br />

у<strong>к</strong>азание "хранить постоянно", предусматривающее обеспечение<br />

долговременной сохранности до<strong>к</strong>ументов.<br />

Хотя, <strong>к</strong>а<strong>к</strong> правило, перечисленных выше вариантов достаточно,<br />

возможно, что не<strong>к</strong>оторым организациям потребуется использовать<br />

другие виды инициирующих событий и/или сро<strong>к</strong>ов хранения.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 80


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

В общей сложности, со сро<strong>к</strong>ами может быть связано любое число<br />

внешних событий.<br />

5.1.26 Желательно, чтобы СЭД не ограничивала продолжительность сро<strong>к</strong>ов<br />

хранения.<br />

5.1.27 При выполнении <strong>требования</strong> п.5.1.24 , СЭД должна поддерживать<br />

сро<strong>к</strong>и хранения с длительностью не менее чем до ста лет.<br />

P<br />

P<br />

Этот, достаточно произвольно выбранный ма<strong>к</strong>симальный период<br />

предлагается во избежание <strong>к</strong>а<strong>к</strong>их-либо пра<strong>к</strong>тичес<strong>к</strong>их ограничений.<br />

Хотя и совершенно невероятно, чтобы <strong>к</strong>а<strong>к</strong>ая-либо СЭД<br />

просуществовала сотню лет, тем не менее, подобное требование<br />

позволит избежать пересмотра сро<strong>к</strong>ов хранения при передаче<br />

до<strong>к</strong>ументов в новые системы.<br />

5.1.28 СЭД должна допус<strong>к</strong>ать введение ограничений, <strong>к</strong>огда возможность<br />

управлять процессом уничтожения и передачи до<strong>к</strong>ументов дается<br />

толь<strong>к</strong>о исполнителям административных ролей.<br />

5.1.29 СЭД должна прото<strong>к</strong>олировать в составе <strong>к</strong>онтрольной информации<br />

любые автоматичес<strong>к</strong>и выполняемые действиях по уничтожению и<br />

передаче до<strong>к</strong>ументов, и оповещать о них исполнителя<br />

административной роли.<br />

5.1.30 СЭД должна автоматичес<strong>к</strong>и извещать исполнителя административной<br />

роли о наступлении сро<strong>к</strong>ов проведения э<strong>к</strong>спертизы ценности<br />

до<strong>к</strong>ументов.<br />

5.1.31 СЭД должна давать возможность исполнителю административной<br />

роли, по получении извещения о наступлении сро<strong>к</strong>а проведения<br />

э<strong>к</strong>спертизы ценности, делегировать выполнение э<strong>к</strong>спертизы ценности<br />

исполнителю роли э<strong>к</strong>сперта 40 .<br />

5.1.32 СЭД должна позволять исполнителю административной роли<br />

с<strong>к</strong>орре<strong>к</strong>тировать любой сро<strong>к</strong> хранения (за ис<strong>к</strong>лючением его<br />

уни<strong>к</strong>ального идентифи<strong>к</strong>атора, см. п.5.1.6).<br />

5.1.33 Когда исполнитель административной роли перемещает эле<strong>к</strong>тронные<br />

дела или до<strong>к</strong>ументы между рубри<strong>к</strong>ами <strong>к</strong>лассифи<strong>к</strong>ационной схемы, СЭД<br />

должна предложить ему выбор:<br />

Y<br />

Y<br />

Y<br />

Y<br />

Y<br />

Y<br />

позволить сро<strong>к</strong>у хранения принимающей рубри<strong>к</strong>и заменить<br />

существующие сро<strong>к</strong>и хранения;<br />

либо<br />

позволить исполнителю административной роли выбрать<br />

подходящий сро<strong>к</strong> (сро<strong>к</strong>и) хранения.<br />

40<br />

О «примерной» роли э<strong>к</strong>сперта см. п. 13.4 (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 81


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Это требование относится <strong>к</strong> перемещению до<strong>к</strong>ументов,<br />

допус<strong>к</strong>аемому в ис<strong>к</strong>лючительных случаях, согласно пп. 9.3.3 и 9.3.4. В<br />

тех ред<strong>к</strong>их случаях, <strong>к</strong>огда эта фун<strong>к</strong>циональная возможность будет<br />

использоваться, исполнителям административных ролей следует<br />

быть предельно осторожными при назначении или изменении сро<strong>к</strong>ов<br />

хранения, - особенно для важнейших до<strong>к</strong>ументов.<br />

5.1.34 СЭД должна давать возможность авторизованному пользователю<br />

наложить запрет на уничтожение либо передачу (disposal hold)<br />

рубри<strong>к</strong>и, дела, суб-дела или тома.<br />

5.1.35 Наличие запрета на уничтожение не должно препятствовать<br />

продолжению отсчета и завершению сро<strong>к</strong>ов хранения.<br />

Y<br />

P<br />

См., одна<strong>к</strong>о, п. 5.1.36.<br />

5.1.36 СЭД должна предотвращать <strong>к</strong>а<strong>к</strong> удаление, та<strong>к</strong> и выполнение <strong>к</strong>а<strong>к</strong>ихлибо<br />

действий по истечении сро<strong>к</strong>ов хранения, с теми объе<strong>к</strong>тами, на<br />

<strong>к</strong>оторые наложен запрет на уничтожение, а та<strong>к</strong>же со всем имеющимся<br />

<strong>к</strong>онтентом (объе<strong>к</strong>тами-потом<strong>к</strong>ами) этих объе<strong>к</strong>тов. 41<br />

Y<br />

Удаление (deletion) описывается в разделе 9.3.<br />

5.1.37 Толь<strong>к</strong>о авторизованному пользователю СЭД должна давать<br />

возможность отменить запрет на уничтожение.<br />

5.1.38 Когда авторизованный пользователь устанавливает или отменяет<br />

запрет на уничтожение, СЭД должна собрать и сохранить следующие<br />

сведения об этом событии, - <strong>к</strong>а<strong>к</strong> минимум, в <strong>к</strong>онтрольной информации,<br />

и, желательно, в метаданных:<br />

Y<br />

Y<br />

дату установления или снятия запрета на уничтожение;<br />

информацию, идентифицирующую авторизованного пользователя;<br />

причину установления или снятия запрета.<br />

5.1.39 Желательно, чтобы СЭД позволяла авторизованному пользователю<br />

установить, в ходе одной "групповой" операции, с у<strong>к</strong>азанием одной и<br />

той же причины, нес<strong>к</strong>оль<strong>к</strong>о запретов на уничтожение для ряда рубри<strong>к</strong>,<br />

дел, суб-дел и томов.<br />

Y<br />

Данное требование дает возможность авторизованному<br />

пользователю устанавливать связанные с одной и той же причиной<br />

запреты на уничтожение сразу нес<strong>к</strong>оль<strong>к</strong>им рубри<strong>к</strong>ам, делам и т.д.<br />

41<br />

Если, например, запрет на уничтожение наложен на рубри<strong>к</strong>у, то запрещаются уничтожение и<br />

передача всех дел и до<strong>к</strong>ументов, размещенных <strong>к</strong>а<strong>к</strong> в самой этой рубри<strong>к</strong>е, та<strong>к</strong> и во всех её<br />

рубри<strong>к</strong>ах-потом<strong>к</strong>ах. (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 82


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

5.1.40 Желательно, чтобы СЭД давала возможность авторизованному<br />

пользователю одновременно снимать в ходе одной "групповой"<br />

операции нес<strong>к</strong>оль<strong>к</strong>о запретов на уничтожение, для <strong>к</strong>оторых у<strong>к</strong>азана<br />

одна и та же причина.<br />

5.1.41 Желательно, чтобы СЭД допус<strong>к</strong>ала, чтобы рубри<strong>к</strong>а, дело, суб-дело или<br />

том могли подпадать одновременно под действие нес<strong>к</strong>оль<strong>к</strong>их запретов<br />

на уничтожение, - или вследствие установления запретов для объе<strong>к</strong>та,<br />

и/или вследствие установления запретов для объе<strong>к</strong>та-пред<strong>к</strong>а. В любом<br />

случае, установленные запретами ограничения на<br />

уничтожение/передачу и на другие фун<strong>к</strong>циональные возможности<br />

должны оставаться в силе до тех пор, по<strong>к</strong>а не будет отменен<br />

последний из затрагивающих данный объе<strong>к</strong>т запретов.<br />

5.1.42 Желательно, чтобы СЭД давала возможность авторизованному<br />

пользователю проводить поис<strong>к</strong> и составлять отчет обо всех объе<strong>к</strong>тах,<br />

подпадающих под <strong>к</strong>он<strong>к</strong>ретный запрет на уничтожение.<br />

5.1.43 Желательно, чтобы СЭД давала возможность авторизованному<br />

пользователю создавать, <strong>к</strong>орре<strong>к</strong>тировать и уничтожать "памят<strong>к</strong>и", в<br />

заданное время напоминающие ему о <strong>к</strong>он<strong>к</strong>ретном запрете на<br />

уничтожение.<br />

Y<br />

Y<br />

Y<br />

Y<br />

5.2 Э<strong>к</strong>спертиза ценности и отбор до<strong>к</strong>ументов на постоянное<br />

хранение, передачу и уничтожение<br />

В одних случаях, в соответствии с у<strong>к</strong>азаниями по сро<strong>к</strong>ам хранения и по дальнейшим<br />

действиям с до<strong>к</strong>ументами, уничтожение и передача до<strong>к</strong>ументов по о<strong>к</strong>ончании сро<strong>к</strong>ов<br />

хранения осуществляются сразу, без проведения э<strong>к</strong>спертизы ценности. В других случаях,<br />

наступление определенной в сро<strong>к</strong>е хранения даты или события инициирует процесс<br />

э<strong>к</strong>спертизы ценности соответствующего набора до<strong>к</strong>ументов. В ходе э<strong>к</strong>спертизы ценности,<br />

<strong>к</strong>огда определяется дальнейшая судьба до<strong>к</strong>ументов (это может быть установление нового<br />

сро<strong>к</strong>а хранения, передача в другую систему, уничтожение, либо <strong>к</strong>омбинация перечисленных<br />

действий), во внимание принимаются метаданные и/или <strong>к</strong>онтент.<br />

Решение судьбы определенных до<strong>к</strong>ументов регулируется за<strong>к</strong>онодательством и<br />

нормативными а<strong>к</strong>тами. Э<strong>к</strong>спертиза ценности должна выполняться в соответствии с этими<br />

за<strong>к</strong>онодательно-нормативными <strong>требования</strong>ми, а та<strong>к</strong>же учитывать установленные для<br />

организации полити<strong>к</strong>у и процедуры отбора до<strong>к</strong>ументов на архивное хранение. Где<br />

необходимо, эта работа должна проводиться во взаимодействии с уполномоченными<br />

архивными учреждениями (а иногда - ис<strong>к</strong>лючительно этими учреждениями). Дальнейшее<br />

обсуждение этих вопросов выходит за рам<strong>к</strong>и MoReq2.<br />

№ Требование Тест.<br />

5.2.1 Желательно, чтобы СЭД автоматичес<strong>к</strong>и извещала исполнителя<br />

административной роли обо всех сро<strong>к</strong>ах хранения, исте<strong>к</strong>ающих в<br />

у<strong>к</strong>азанный период времени.<br />

Y<br />

Версия 1.04<br />

8 сентября 2008 Стр. 83


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

5.2.2 СЭД должна поддерживать процесс э<strong>к</strong>спертизы ценности, путем<br />

представления подлежащих э<strong>к</strong>спертизе рубри<strong>к</strong>, дел, суб-дел и томов,<br />

вместе с их метаданными и информацией о сро<strong>к</strong>ах хранения.<br />

Y<br />

На пра<strong>к</strong>ти<strong>к</strong>е, это требование подразумевает средства<br />

перемещения вперёд, назад и т.д. внутри и между делами, и переход<br />

<strong>к</strong> просмотру метаданных дел и до<strong>к</strong>ументов, и обратно.<br />

5.2.3 СЭД должна быть способна поддерживать взаимосвязи между<br />

различными представлениями одних и тех же до<strong>к</strong>ументов, и давать<br />

возможность одновременно выполнять над ними действия по решению<br />

их судьбы.<br />

5.2.4 Ка<strong>к</strong> минимум, СЭД должна давать возможность проводящему<br />

э<strong>к</strong>спертизу ценности специалисту предпринять в отношении <strong>к</strong>аждого из<br />

проходящих э<strong>к</strong>спертизу рубри<strong>к</strong>, дел, суб-дел и томов одно из<br />

следующих действий:<br />

Y<br />

Y<br />

отобрать на уничтожение, <strong>к</strong>оторое должно быть проведено либо<br />

немедленно, либо в определенный момент в будущем (см. раздел<br />

5.3);<br />

отобрать на передачу (см. раздел 5.3), <strong>к</strong>оторая должно быть<br />

проведена либо немедленно, либо в определенный момент в<br />

будущем;<br />

назначить повторную э<strong>к</strong>спертизу ценности, <strong>к</strong>оторая должно быть<br />

проведена либо немедленно, либо в определенный момент в<br />

будущем;<br />

установить постоянный сро<strong>к</strong> хранения.<br />

Это может быть реализовано <strong>к</strong>а<strong>к</strong> с использованием механизма<br />

сро<strong>к</strong>ов хранения, та<strong>к</strong> и при помощи иных средств.<br />

5.2.5 СЭД должна автоматичес<strong>к</strong>и прото<strong>к</strong>олировать дату проведения<br />

э<strong>к</strong>спертизы ценности.<br />

5.2.6 СЭД должна давать возможность проводящему э<strong>к</strong>спертизу ценности<br />

специалисту вносить в метаданные рубри<strong>к</strong>, дел, суб-дел и томов<br />

<strong>к</strong>омментарии, в целях до<strong>к</strong>ументирования причин принятых решений.<br />

5.2.7 СЭД должна вести и сохранять защищенным от изменений образом<br />

историю всех решений, принятых проводящим э<strong>к</strong>спертизу ценности<br />

специалистом, в<strong>к</strong>лючая обоснования этих решений.<br />

Y<br />

Y<br />

Y<br />

Желательно, чтобы сведения о принятых решениях сохранялись в<br />

метаданных, и, возможно, та<strong>к</strong>же в <strong>к</strong>онтрольной информации.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 84


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

5.2.8 Желательно, чтобы СЭД извещала исполнителя административной<br />

роли о возни<strong>к</strong>новении <strong>к</strong>онфли<strong>к</strong>та, связанного с тем, что на отобранное<br />

на уничтожение дело имеется ссыл<strong>к</strong>а в другом деле. СЭД в этом<br />

случае должна приостановить процесс уничтожения и дать<br />

возможность принять следующие <strong>к</strong>орре<strong>к</strong>тирующие меры:<br />

Y<br />

получение от исполнителя административной роли подтверждения<br />

на продолжение процесса уничтожение или <strong>к</strong>оманды на отмену<br />

процесса;<br />

создание отчёта, детализирующего сведения о соответствующих<br />

делах или до<strong>к</strong>ументах, и всех подобных ссыл<strong>к</strong>ах на них.<br />

5.3 Передача, э<strong>к</strong>спорт и уничтожение<br />

Организациям может понадобиться, в архивных или иных целях, переместить до<strong>к</strong>ументы из<br />

их СЭД в другие места или системы. Для обозначения та<strong>к</strong>их действий здесь используется<br />

термин «передача».<br />

Причинами для передачи до<strong>к</strong>ументов могут быть:<br />

постоянное сохранение до<strong>к</strong>ументов в юридичес<strong>к</strong>их, административных или научных<br />

целях;<br />

использование услуг автономных подразделений или внешних организаций для среднеи<br />

долгосрочного управления до<strong>к</strong>ументами.<br />

В результате этого процесса до<strong>к</strong>ументы часто передаются в другую СЭД.<br />

Термин «передача» используется несмотря на то, что первоначально в другое место или<br />

систему посылается толь<strong>к</strong>о <strong>к</strong>опия до<strong>к</strong>ументов. Оригиналы до<strong>к</strong>ументов продолжают<br />

сохраняться в исходной СЭД, и уничтожаются толь<strong>к</strong>о после провер<strong>к</strong>и, подтверждающей<br />

успешное завершение процесса передачи.<br />

Термин «э<strong>к</strong>спорт», с другой стороны, описывает процесс создания полной <strong>к</strong>опии наборов<br />

до<strong>к</strong>ументов, дел и отдельных до<strong>к</strong>ументов для другой системы, в то время <strong>к</strong>а<strong>к</strong> сами<br />

до<strong>к</strong>ументы остаются в исходной системе - процесс их не уничтожает.<br />

Фа<strong>к</strong>тичес<strong>к</strong>и процесс передачи состоит из двух этапов – из э<strong>к</strong>спорта <strong>к</strong>опий до<strong>к</strong>ументов<br />

вместе со всеми соответствующими метаданными и <strong>к</strong>онтрольной информацией, и<br />

последующего уничтожения оригинальных до<strong>к</strong>ументов.<br />

В любом случае, передачу, э<strong>к</strong>спорт или уничтожение требуется выполнить <strong>к</strong>онтролируемым<br />

образом. Решения в отношении метаданных и <strong>к</strong>онтрольной информации должны<br />

приниматься одновременно с выполнением действий над теми до<strong>к</strong>ументами, <strong>к</strong> <strong>к</strong>оторым они<br />

относятся.<br />

В данном <strong>к</strong>онте<strong>к</strong>сте «уничтожение» (destruction) отличается от «логичес<strong>к</strong>ого удаления»<br />

(deletion). Логичес<strong>к</strong>ое удаление до<strong>к</strong>ументов при иных обстоятельствах рассматривается в<br />

разделе 9.3.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 85


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

5.3.1 В случае опубли<strong>к</strong>ования формальной XML-схемы для MoReq2 42 , СЭД<br />

должна поддерживать э<strong>к</strong>спорт до<strong>к</strong>ументов в форме, соответствующей<br />

этой схеме.<br />

P<br />

См. та<strong>к</strong>же требование 6.2.1 относительно группового импорта<br />

до<strong>к</strong>ументов. Совместно эти два <strong>требования</strong> обеспечивают<br />

возможность взаимодействия соответствующих <strong>требования</strong>м<br />

MoReq2 систем эле<strong>к</strong>тронного до<strong>к</strong>ументооборота.<br />

5.3.2 В случае передачи или э<strong>к</strong>спорта до<strong>к</strong>ументов, СЭД должна передать<br />

или э<strong>к</strong>спортировать все их <strong>к</strong>омпоненты, с сохранением правильных<br />

взаимосвязей между ними.<br />

5.3.3 СЭД должна обеспечить строго определенный процесс передачи<br />

до<strong>к</strong>ументов, вместе с соответствующими метаданными и <strong>к</strong>онтрольной<br />

информацией, в другую систему или в другую организацию.<br />

5.3.4 Желательно, чтобы СЭД поддерживала э<strong>к</strong>спорт до<strong>к</strong>ументов и их<br />

метаданных в виде "модуля передаваемой информации" 43 (submission<br />

information package, SIP), в соответствии с <strong>требования</strong>ми стандарта<br />

OAIS (см. Приложение 7).<br />

P<br />

P<br />

Y<br />

См. аналогичное требование в отношении "модулей<br />

распространяемой информации" (dissemination information packages,<br />

DIPs) в п.11.7.12.<br />

5.3.5 При передаче или э<strong>к</strong>спорте из СЭД рубри<strong>к</strong>, дел, суб-дел или томов, в<br />

состав передаваемой информации должны входить:<br />

P<br />

(для рубри<strong>к</strong>и) все дела и до<strong>к</strong>ументы, входящие в рубри<strong>к</strong>у;<br />

(для дела) все тома и суб-дела, входящие в состав дела;<br />

все до<strong>к</strong>ументы, входящие в соответствующие дела, суб-дела и<br />

тома;<br />

все (либо определенные) метаданные, относящиеся <strong>к</strong><br />

вышеперечисленным объе<strong>к</strong>там;<br />

вся (либо определенная) <strong>к</strong>онтрольная информация, относящаяся <strong>к</strong><br />

вышеперечисленным объе<strong>к</strong>там.<br />

Хотя СЭД должна быть способна э<strong>к</strong>спортировать все метаданные и<br />

всю <strong>к</strong>онтрольную информацию, в полном виде они не всегда нужны<br />

принимающей системе.<br />

42<br />

43<br />

В момент написания данного до<strong>к</strong>умента, разработ<strong>к</strong>а XML-схемы для MoReq2 толь<strong>к</strong>о<br />

начинается. Для получения дополнительной информации, см.<br />

http://ec.europa.eu/transparency/archival_policy .<br />

В отечественной литературе встречается и другой перевод этого термина: «па<strong>к</strong>ет подачи<br />

информации» (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 86


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

5.3.6 Если СЭД передает или э<strong>к</strong>спортирует до<strong>к</strong>ументы вместе с их<br />

метаданными, то в число передаваемых (э<strong>к</strong>спортируемых)<br />

метаданных должны в явной форме в<strong>к</strong>лючаться все неявные 44<br />

метаданные.<br />

P<br />

Иными словами, все значения элементов метаданных, относящиеся<br />

<strong>к</strong> рубри<strong>к</strong>е, делу, суб-делу, тому или до<strong>к</strong>ументу должны быть<br />

представлены в явном виде, даже если они хранились толь<strong>к</strong>о в<br />

неявном виде. Примеры см. в Приложении 9.3.<br />

5.3.7 СЭД должна быть в состоянии при э<strong>к</strong>спорте или передаче любого<br />

набора до<strong>к</strong>ументов выполнить одно или оба из перечисленных<br />

требований:<br />

P<br />

э<strong>к</strong>спортировать или передавать вместе с до<strong>к</strong>ументами сро<strong>к</strong>и<br />

хранения, установленные для этих до<strong>к</strong>ументов, та<strong>к</strong>им образом,<br />

чтобы их можно было вновь установить для этих же до<strong>к</strong>ументов в<br />

принимающей системе;<br />

вывести на печать один или нес<strong>к</strong>оль<strong>к</strong>о отчетов, по<strong>к</strong>азывающих,<br />

<strong>к</strong>а<strong>к</strong>ие сро<strong>к</strong>и хранения должны быть назначены <strong>к</strong>аждому из наборов<br />

до<strong>к</strong>ументов, и параметры этих сро<strong>к</strong>ов хранения.<br />

5.3.8 СЭД должна быть в состоянии при э<strong>к</strong>спорте или передаче любого<br />

набора до<strong>к</strong>ументов выполнить одно или оба из перечисленных<br />

требований:<br />

P<br />

э<strong>к</strong>спортировать или передавать вместе с до<strong>к</strong>ументами параметры<br />

доступа, установленные для этих до<strong>к</strong>ументов, та<strong>к</strong>им образом,<br />

чтобы их можно было вновь установить для этих же до<strong>к</strong>ументов в<br />

принимающей системе;<br />

вывести на печать один или нес<strong>к</strong>оль<strong>к</strong>о отчетов, по<strong>к</strong>азывающих,<br />

<strong>к</strong>а<strong>к</strong>ие параметры доступа установлены для <strong>к</strong>аждого из наборов<br />

до<strong>к</strong>ументов, и их хара<strong>к</strong>теристи<strong>к</strong>и.<br />

44<br />

Примером могут служить наследуемые значения элементов метаданных (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 87


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

5.3.9 СЭД должна быть способна передавать или э<strong>к</strong>спортировать дело или<br />

рубри<strong>к</strong>у в ходе единой последовательности операций, та<strong>к</strong>ой, что:<br />

P<br />

содержание и стру<strong>к</strong>тура эле<strong>к</strong>тронных до<strong>к</strong>ументов не изменяются;<br />

все <strong>к</strong>омпоненты эле<strong>к</strong>тронного до<strong>к</strong>умента (если их нес<strong>к</strong>оль<strong>к</strong>о)<br />

э<strong>к</strong>спортируются в виде единого объе<strong>к</strong>та;<br />

сохраняются все связи между до<strong>к</strong>ументом, его метаданными и<br />

<strong>к</strong>онтрольной информацией;<br />

сохраняются все связи между рубри<strong>к</strong>ами, делами, суб-делами,<br />

томами и до<strong>к</strong>ументами, та<strong>к</strong>им образом, чтобы их можно было<br />

восстановить в принимающей СЭД.<br />

5.3.10 Если при передаче или э<strong>к</strong>спорте дел (и/или суб-дел, и/или томов)<br />

<strong>к</strong>а<strong>к</strong>ое-либо из них содержит у<strong>к</strong>азатели на до<strong>к</strong>ументы, хранящиеся в<br />

других делах (см. 3.4.24), то СЭД должна в этом случае передавать<br />

или э<strong>к</strong>спортировать собственно до<strong>к</strong>умент, а не ссыл<strong>к</strong>у на него.<br />

Y<br />

Это требуется для того, чтобы не возни<strong>к</strong>ло проблем с<br />

разрешением ссыло<strong>к</strong> между передающей (э<strong>к</strong>спортирующей) и<br />

принимающей системами.<br />

5.3.11 СЭД должна быть способна передавать и э<strong>к</strong>спортировать до<strong>к</strong>ументы в<br />

том формате, в <strong>к</strong>отором они были введены в нее первоначально. 45<br />

5.3.12 СЭД должна быть способна передавать и э<strong>к</strong>спортировать до<strong>к</strong>ументы<br />

во всех форматах, в <strong>к</strong>оторые те были <strong>к</strong>онвертированы<br />

(представлены).<br />

5.3.13 СЭД должна быть способна мигрировать (<strong>к</strong>онвертировать) отобранные<br />

на передачу либо э<strong>к</strong>спорт до<strong>к</strong>ументы в установленные "передаточные"<br />

форматы (transfer formats).<br />

Y<br />

Y<br />

P<br />

Та<strong>к</strong>ими утвержденными форматами могут быть, например, XML или<br />

иной от<strong>к</strong>рытый формат.<br />

Данное требование предусмотрено на случай длительных периодов<br />

хранения, <strong>к</strong>огда спустя определенное время до<strong>к</strong>ументы должны<br />

автоматичес<strong>к</strong>и <strong>к</strong>онвертироваться в соответствующие форматы<br />

для долговременного хранения, без ущерба для их целостности и<br />

аутентичности.<br />

5.3.14 СЭД должна сохранять все передаваемые наборы до<strong>к</strong>ументов,<br />

до<strong>к</strong>ументы и иную информацию, <strong>к</strong>а<strong>к</strong> минимум, до получения<br />

подтверждения об успешном завершении процесса передачи.<br />

Y<br />

45<br />

В случае длительного хранения эле<strong>к</strong>тронных до<strong>к</strong>ументов в СЭД, <strong>к</strong>огда потребуется<br />

проведение миграций, следствием этого <strong>требования</strong> будет сохранение до<strong>к</strong>ументов <strong>к</strong>а<strong>к</strong> в<br />

новом, та<strong>к</strong> и в оригинальном форматах. (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 88


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Это требование является мерой предосторожности,<br />

обеспечивающей, что до<strong>к</strong>ументы не будут уничтожены раньше, чем<br />

получатель пришлёт подтверждение об успешном завершении<br />

процесса передачи.<br />

Относительно требований <strong>к</strong> созданию отчетов о сбоях во время<br />

процесса передачи, см. пп. 9.2.30 и 9.2.31.<br />

5.3.15 СЭД должна уничтожить переданные наборы до<strong>к</strong>ументов, до<strong>к</strong>ументы и<br />

иную информацию по получении уведомления об успешном<br />

завершении процесса передачи, - за ис<strong>к</strong>лючением тех метаданных,<br />

<strong>к</strong>оторые сохраняются в составе "остаточного набора" (stub).<br />

Y<br />

См. п. 5.3.19.<br />

5.3.16 Желательно, чтобы СЭД могла э<strong>к</strong>спортировать весь <strong>к</strong>онтент рубри<strong>к</strong>и<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схемы в ходе единой последовательности<br />

операций, обеспечивая, что:<br />

P<br />

сохраняется относительное расположение <strong>к</strong>аждого дела в<br />

<strong>к</strong>лассифи<strong>к</strong>ационной схеме, та<strong>к</strong> что стру<strong>к</strong>тура размещения дел<br />

может быть восстановлена;<br />

сохраняется и передается вместе с <strong>к</strong>онтентом рубри<strong>к</strong>и набор<br />

метаданных, достаточный для того, чтобы полностью воссоздать<br />

стру<strong>к</strong>туру этой рубри<strong>к</strong>и.<br />

5.3.17 Желательно, чтобы СЭД позволяла добавлять определяемые<br />

пользователем элементы метаданных, нужные для целей архивного<br />

управления отобранными <strong>к</strong> передаче эле<strong>к</strong>тронными делами.<br />

5.3.18 В случае уничтожения отобранного на уничтожение до<strong>к</strong>умента, СЭД<br />

должна обеспечить уничтожение всех представлений этого до<strong>к</strong>умента<br />

в различных форматах.<br />

Y<br />

Y<br />

Если до<strong>к</strong>умент помещен не толь<strong>к</strong>о в данное дело (см. п. 3.4.24 в<br />

разделе 3.4), то желательно, чтобы до<strong>к</strong>умент и его представления<br />

при уничтожении удалялись из этого дела, но не уничтожались<br />

о<strong>к</strong>ончательно до тех пор, по<strong>к</strong>а до<strong>к</strong>умент не будет удален изо всех<br />

рубри<strong>к</strong> и дел, в <strong>к</strong>оторые он был помещен.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 89


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

5.3.19 СЭД должна иметь возможность сохранять остаточные метаданные<br />

(metadata stub) для:<br />

Y<br />

рубри<strong>к</strong>;<br />

дел;<br />

суб-дел;<br />

томов;<br />

до<strong>к</strong>ументов, размещенных непосредственно в рубри<strong>к</strong>ах;<br />

<strong>к</strong>оторые были уничтожены или переданы.<br />

В определенных случаях желательно сохранять информацию об<br />

уничтоженных до<strong>к</strong>ументах. Желательно, чтобы соответствующий<br />

набор метаданных в<strong>к</strong>лючал, <strong>к</strong>а<strong>к</strong> минимум, дату поступления и все<br />

метаданные, позволяющие однозначно идентифицировать <strong>к</strong>аждый<br />

до<strong>к</strong>умент и его связи с <strong>к</strong>лассифи<strong>к</strong>ационной схемой. См. модель<br />

метаданных MoReq2.<br />

Это нужно для того, чтобы организация по-прежнему могла<br />

установить, <strong>к</strong>а<strong>к</strong>ие до<strong>к</strong>ументы у неё имелись, и даты их<br />

уничтожения или передачи, - не перерасходуя ресурсы на хранение<br />

всех метаданных этих дел и до<strong>к</strong>ументов.<br />

5.3.20 Остаточные метаданные (см. п.5.3.19) должны, <strong>к</strong>а<strong>к</strong> минимум, в<strong>к</strong>лючать<br />

следующие метаданные:<br />

Y<br />

Дата уничтожения или передачи;<br />

Полный <strong>к</strong>лассифи<strong>к</strong>ационный <strong>к</strong>од;<br />

Заголово<strong>к</strong> (название);<br />

Описание;<br />

Пользователь, ответственный за уничтожение или передачу;<br />

Причина уничтожения или передачи (это может быть ссыл<strong>к</strong>а на<br />

сро<strong>к</strong> хранения или введенное вручную обоснование);<br />

Входящий номер или иной идентифи<strong>к</strong>атор, присвоенный системойполучателем<br />

переданных до<strong>к</strong>ументов, - с целью упрощения<br />

розыс<strong>к</strong>а и извлечения переданных до<strong>к</strong>ументов.<br />

5.3.21 СЭД должна давать возможность исполнителю административной<br />

роли определить подмножество дополнительных элементов<br />

метаданных, <strong>к</strong>оторые будут сохраняться в составе остаточных<br />

метаданных.<br />

Y<br />

Версия 1.04<br />

8 сентября 2008 Стр. 90


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

5.3.22 При э<strong>к</strong>спорте до<strong>к</strong>ументов, СЭД должна давать возможность<br />

э<strong>к</strong>спортировать остаточные метаданные.<br />

Y<br />

Это требуется для того, чтобы была возможна миграция из одной<br />

СЭД в другую.<br />

5.3.23 СЭД должна давать возможность неодно<strong>к</strong>ратно проводить э<strong>к</strong>спорт<br />

одной и той же информации.<br />

5.3.24 Желательно, чтобы в случае передачи или э<strong>к</strong>спорта информации, СЭД<br />

могла подготовить по запросу отчет, перечисляющий<br />

э<strong>к</strong>спортированные или переданные до<strong>к</strong>ументы по их <strong>к</strong>атегориям<br />

защиты (грифам доступа).<br />

Y<br />

Y<br />

Версия 1.04<br />

8 сентября 2008 Стр. 91


Специфи<strong>к</strong>ации MoReq2<br />

6. ВВОД И РЕГИСТРАЦИЯ ДОКУМЕНТОВ<br />

Содержание данной главы<br />

В данной главе собраны <strong>требования</strong>, относящиеся <strong>к</strong> процессу ввода до<strong>к</strong>ументов в СЭД.<br />

Первый раздел 6.1 относится <strong>к</strong> стандартному процессу ввода, <strong>требования</strong> второго раздела<br />

6.2 связаны с массовым импортом до<strong>к</strong>ументов из других систем. Далее, ввиду её особой<br />

важности, следует раздел, посвященный эле<strong>к</strong>тронной почте (6.3). В разделе 6.4<br />

рассматриваются типы до<strong>к</strong>ументов, а раздел 6.5 посвящен интеграции с системами<br />

с<strong>к</strong>анирования и управления графичес<strong>к</strong>ими образами (scanning and imaging systems).<br />

Терминология<br />

Термин "ввод" (capture) 46 используется в своем естественном язы<strong>к</strong>овом значении, в<br />

<strong>к</strong>онте<strong>к</strong>сте информационных технологий и управления информацией. Здесь "ввод"<br />

информации означает сохранение ее в <strong>к</strong>омпьютерной системе. Подобное тол<strong>к</strong>ование<br />

согласуется со значением этого термина в архивной терминологии ("а<strong>к</strong>т записи или<br />

сохранения отдельной реализации цифрового объе<strong>к</strong>та"), приведенным в<br />

Терминологичес<strong>к</strong>ой базе данных (Terminology Database) прое<strong>к</strong>та InterPARES 2 47 .<br />

В системы эле<strong>к</strong>тронного до<strong>к</strong>ументооборота может вводится разнообразная информация -<br />

среди прочего, до<strong>к</strong>ументы, метаданные, и, в не<strong>к</strong>оторых случаях, информационные<br />

материалы.<br />

Тот фа<strong>к</strong>т, что в СЭД могут (в определенных случаях) вводиться <strong>к</strong>а<strong>к</strong> до<strong>к</strong>ументы, та<strong>к</strong> и<br />

информационные материалы, предполагает определенную расплывчатость данного<br />

термина, пос<strong>к</strong>оль<strong>к</strong>у при вводе до<strong>к</strong>умента задействовано больше процессов, чем при вводе<br />

не имеющего до<strong>к</strong>ументного статуса информационного материала. Например, ввод<br />

до<strong>к</strong>умента в<strong>к</strong>лючает процессы <strong>к</strong>лассифи<strong>к</strong>ации, регистрации, и организации защиты от<br />

внесения изменений, - <strong>к</strong>оторые не нужны в случае ввода информационных материалов. По<br />

этой причине, <strong>к</strong>огда речь идет о до<strong>к</strong>ументах, в те<strong>к</strong>сте на английс<strong>к</strong>ом язы<strong>к</strong>е в <strong>к</strong>ачестве<br />

синонима термину capture иногда используется термин declare 48 (объявлять,<br />

де<strong>к</strong>ларировать). Одна<strong>к</strong>о термин "объявлять" может применяться и <strong>к</strong> информационному<br />

материалу, возни<strong>к</strong>ающему вне СЭД, и <strong>к</strong> уже введенному в СЭД информационному<br />

материалу.<br />

Предполагается, что данная терминологичес<strong>к</strong>ая нечет<strong>к</strong>ость не с<strong>к</strong>азывается негативно на<br />

ясности специфи<strong>к</strong>аций MoReq2.<br />

Более строгие определения даны в Глоссарии, в разделе 13.1.<br />

46<br />

47<br />

48<br />

Английс<strong>к</strong>ое слово capture может переводиться <strong>к</strong>а<strong>к</strong> ввод, фи<strong>к</strong>сация, фи<strong>к</strong>сирование, приём,<br />

сбор, запись, сохранение, захват и т.п. В данном переводе соответствующее русс<strong>к</strong>ое слово,<br />

<strong>к</strong>а<strong>к</strong> правило, подбиралось в зависимости от оттен<strong>к</strong>ов значения термина <strong>к</strong> <strong>к</strong>он<strong>к</strong>ретном<br />

<strong>к</strong>онте<strong>к</strong>сте. Например, там, где для сохранения до<strong>к</strong>ументов и информации в СЭД требуются<br />

определенные а<strong>к</strong>тивные действия, термин обычно переводится <strong>к</strong>а<strong>к</strong> "захват". (прим.<br />

переводчи<strong>к</strong>а)<br />

См. http://www.interpares.org/ip2/ip2_terminology_db.cfm.<br />

В англоязычной литературе термин declare обычно используется в <strong>к</strong>онстру<strong>к</strong>ции "объявить<br />

информационный материал до<strong>к</strong>ументом". (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 92


Специфи<strong>к</strong>ации MoReq2<br />

6.1 Ввод (capture)<br />

Эле<strong>к</strong>тронные информационные материалы, создаваемые или получаемые в ходе<br />

деловых процессов, поступают <strong>к</strong>а<strong>к</strong> из внешних, та<strong>к</strong> и из внутренних источни<strong>к</strong>ов. Они могут<br />

быть в различных форматах, могут создаваться различными авторами, и могут поступать<br />

<strong>к</strong>а<strong>к</strong> в виде единого информационного объе<strong>к</strong>та, та<strong>к</strong> и в виде объе<strong>к</strong>та, состоящего из<br />

нес<strong>к</strong>оль<strong>к</strong>их <strong>к</strong>омпонент (определение значение термина "<strong>к</strong>омпонента" в MoReq2 см. в<br />

Глоссарии).<br />

Одни до<strong>к</strong>ументы создаются внутри организации, в ходе её деловых процессов. Другие -<br />

поступают по различным теле<strong>к</strong>оммуни<strong>к</strong>ационным <strong>к</strong>аналам: например, по эле<strong>к</strong>тронной почте,<br />

фа<strong>к</strong>су, по обычной почте (с последующим опциональным с<strong>к</strong>анированием), с <strong>к</strong>урьерами.<br />

Объёмы и темпы поступления тоже могут быть разными. Для того, чтобы учесть всё<br />

разнообразие требований, требуется гиб<strong>к</strong>ая система ввода информационных материалов и<br />

до<strong>к</strong>ументов, имеющая хорошие средства настрой<strong>к</strong>и и управления.<br />

№ Требование Тест.<br />

6.1.1 Реализованный в СЭД процесс ввода должен обеспечить средства<br />

<strong>к</strong>онтроля и управления и фун<strong>к</strong>циональные возможности, позволяющие<br />

пользователям:<br />

P<br />

регистрировать эле<strong>к</strong>тронные до<strong>к</strong>ументы, независимо от<br />

используемого файлового формата, метода <strong>к</strong>одиров<strong>к</strong>и и других<br />

технологичес<strong>к</strong>их хара<strong>к</strong>теристи<strong>к</strong>, без внесения <strong>к</strong>а<strong>к</strong>их-либо изменений<br />

в их содержание;<br />

размещать до<strong>к</strong>ументы в <strong>к</strong>лассифи<strong>к</strong>ационной схеме;<br />

помещать до<strong>к</strong>умент в одно или нес<strong>к</strong>оль<strong>к</strong>о дел или рубри<strong>к</strong>.<br />

Термин "файловый формат" определен в Глоссарии. Требуется,<br />

чтобы была возможность вводить информацию в любых файловых<br />

форматах.<br />

Делать требование об обеспечении ввода до<strong>к</strong>ументов в любых<br />

файловых форматах проверяемым не предполагается, и это<br />

требование не подразумевает способности СЭД отображать (см.<br />

Глоссарий) все возможные форматы. Поэтому в MoReq2<br />

отсутствует списо<strong>к</strong> поддерживаемых форматов, - пос<strong>к</strong>оль<strong>к</strong>у со<br />

временем форматы изменяются, по мере развития программного<br />

обеспечения. Одна<strong>к</strong>о во избежание сомнений следует отметить,<br />

что виды вводимых до<strong>к</strong>ументов могут быть разнообразными, и<br />

могут, например, в<strong>к</strong>лючать следующие виды до<strong>к</strong>ументов, часто<br />

используемые в офисной работе:<br />

до<strong>к</strong>ументы, создаваемые различными офисными программными<br />

приложениями (например, офисными па<strong>к</strong>етами программ);<br />

сообщения эле<strong>к</strong>тронной почты (см. раздел 6.3);<br />

аудиозаписи;<br />

базы данных;<br />

Версия 1.04<br />

8 сентября 2008 Стр. 93


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

информационные материалы и до<strong>к</strong>ументы в платформеннонезависимых<br />

форматах;<br />

отс<strong>к</strong>анированные изображения;<br />

видеозаписи;<br />

веб-страницы.<br />

В определенных случаях может та<strong>к</strong>же потребоваться ввести в СЭД<br />

другие виды до<strong>к</strong>ументов, та<strong>к</strong>ие <strong>к</strong>а<strong>к</strong>:<br />

блоги;<br />

сжатые файлы (иногда называемые "архивами", используя<br />

принятую в информационных технологиях тра<strong>к</strong>тов<strong>к</strong>у этого<br />

термина);<br />

эле<strong>к</strong>тронные <strong>к</strong>алендари;<br />

эле<strong>к</strong>тронные формы;<br />

данные из географичес<strong>к</strong>их информационных систем (ГИС);<br />

информация из других <strong>к</strong>омпьютерных приложений, например из<br />

бухгалтерс<strong>к</strong>их и платежных систем или из систем<br />

автоматизированного прое<strong>к</strong>тирования;<br />

системы мгновенных сообщений;<br />

мультимедийные информационные материалы;<br />

до<strong>к</strong>ументы, отражающие интернет-транза<strong>к</strong>ции;<br />

до<strong>к</strong>ументы, содержащие ссыл<strong>к</strong>и на другие до<strong>к</strong>ументы;<br />

исходный <strong>к</strong>од программного обеспечения и соответствующая<br />

прое<strong>к</strong>тная до<strong>к</strong>ументация;<br />

стру<strong>к</strong>турированные данные (например, EDI транза<strong>к</strong>ции);<br />

интернет-трансляции и онлайн-<strong>к</strong>онференции;<br />

ви<strong>к</strong>ипедии, ви<strong>к</strong>и-словари и т.д..<br />

Данные спис<strong>к</strong>и не являются исчерпывающими.<br />

6.1.2 СЭД не должна на<strong>к</strong>ладывать <strong>к</strong>а<strong>к</strong>их-либо пра<strong>к</strong>тичес<strong>к</strong>и значимых<br />

ограничений ни на <strong>к</strong>оличество помещаемых в рубри<strong>к</strong>у, дело, суб-дело<br />

или том до<strong>к</strong>ументов, ни на общее число хранимых в СЭД до<strong>к</strong>ументов.<br />

P<br />

Версия 1.04<br />

8 сентября 2008 Стр. 94


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Помещение большого <strong>к</strong>оличества до<strong>к</strong>ументов в тома и т.д. может в<br />

ряде случаев затруднить использование системы, и поэтому обычно<br />

не ре<strong>к</strong>омендуется. Данное требование введено в расчете на<br />

ситуации, <strong>к</strong>огда невозможно избежать с<strong>к</strong>опления большого числа<br />

до<strong>к</strong>ументов (например, в не<strong>к</strong>оторых средах обработ<strong>к</strong>и транза<strong>к</strong>ций).<br />

6.1.3 При вводе состоящего из нес<strong>к</strong>оль<strong>к</strong>их <strong>к</strong>омпонент до<strong>к</strong>умента, СЭД<br />

должна обеспечить ввод всех его <strong>к</strong>омпонент.<br />

6.1.4 При вводе состоящего из нес<strong>к</strong>оль<strong>к</strong>их <strong>к</strong>омпонент эле<strong>к</strong>тронного<br />

до<strong>к</strong>умента, СЭД должна обеспечить возможность управления этим<br />

до<strong>к</strong>ументом <strong>к</strong>а<strong>к</strong> единым целым, сохраняя взаимосвязи между<br />

<strong>к</strong>омпонентами и поддерживая стру<strong>к</strong>турную целостность до<strong>к</strong>умента.<br />

P<br />

P<br />

Примерами подобных до<strong>к</strong>ументов являются:<br />

веб-страницы со встроенными графичес<strong>к</strong>ими элементами;<br />

те<strong>к</strong>стовой до<strong>к</strong>умент, связанный с эле<strong>к</strong>тронной таблицей.<br />

Иногда <strong>к</strong>омпоненты будут связаны ссыл<strong>к</strong>ами, <strong>к</strong>оторые не будут<br />

работать, если эти <strong>к</strong>омпоненты просто с<strong>к</strong>опировать в хранилище<br />

СЭД. Например, многие веб-страницы содержат ссыл<strong>к</strong>и на<br />

графичес<strong>к</strong>ие и иные объе<strong>к</strong>ты с адресами (URL), <strong>к</strong>оторые являются<br />

внешними по отношению <strong>к</strong> хранилищу; связанные эле<strong>к</strong>тронные<br />

таблицы та<strong>к</strong>же обычно содержат ссыл<strong>к</strong>и на адреса (имена файлов в<br />

операционной системе), внешние по отношению <strong>к</strong> хранилищу. См.<br />

следующее требование.<br />

6.1.5 Желательно, чтобы при вводе состоящего из нес<strong>к</strong>оль<strong>к</strong>их <strong>к</strong>омпонент<br />

эле<strong>к</strong>тронного до<strong>к</strong>умента, СЭД, при необходимости, модифицировала<br />

до<strong>к</strong>умент, с тем, чтобы сохранить возможность его отображать. С<strong>к</strong>орее<br />

всего это будет означать, что СЭД с<strong>к</strong>орре<strong>к</strong>тирует внутренние ссыл<strong>к</strong>и<br />

(связи) в не<strong>к</strong>оторых <strong>к</strong>омпонентах.<br />

P<br />

Это требование применимо толь<strong>к</strong>о <strong>к</strong> файловым форматам,<br />

у<strong>к</strong>азанным для <strong>к</strong>он<strong>к</strong>ретной СЭД - оно не рассчитано на<br />

неопределенный <strong>к</strong>руг форматов. Примерами могут служить:<br />

HTML-страницы, в<strong>к</strong>лючающие ссыл<strong>к</strong>и на графичес<strong>к</strong>ие и иные<br />

объе<strong>к</strong>ты;<br />

эле<strong>к</strong>тронные таблицы, в<strong>к</strong>лючающие ссыл<strong>к</strong>и на другие<br />

эле<strong>к</strong>тронные таблицы.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 95


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Внесение подобных изменений противоречит общему принципу<br />

сохранения неизменным содержания (<strong>к</strong>онтента) до<strong>к</strong>ументов, одна<strong>к</strong>о<br />

этого нельзя избежать, если много<strong>к</strong>омпонентные до<strong>к</strong>ументы<br />

должны сохраняться в своём оригинальном формате, без потери<br />

фун<strong>к</strong>циональности и точности воспроизведения. Обычно подобные<br />

изменения будут рассматриваться <strong>к</strong>а<strong>к</strong> допустимые, при условии,<br />

что они прото<strong>к</strong>олируются СЭД в составе <strong>к</strong>онтрольной информации<br />

(см. следующее требование). Альтернативный подход<br />

предусматривает создание представления до<strong>к</strong>умента в ином<br />

файловом формате (та<strong>к</strong>ом, <strong>к</strong>а<strong>к</strong> PDF/A), <strong>к</strong>оторый сохраняет<br />

статичес<strong>к</strong>ое изображение; см. требование 11.7.8. Одна<strong>к</strong>о, хотя<br />

та<strong>к</strong>ой подход позволяет избежать внесения изменений в ссыл<strong>к</strong>и,<br />

вероятным следствием может быть утрата ссыло<strong>к</strong>.<br />

6.1.6 Если СЭД во время ввода <strong>к</strong>орре<strong>к</strong>тирует содержащиеся в до<strong>к</strong>ументах<br />

ссыл<strong>к</strong>и, она должна автоматичес<strong>к</strong>и прото<strong>к</strong>олировать все подробности<br />

сделанных изменений в <strong>к</strong>онтрольной информации.<br />

6.1.7 СЭД должна автоматичес<strong>к</strong>и захватывать сведения о файловом<br />

формате (см. Глоссарий), в<strong>к</strong>лючая версию, <strong>к</strong>аждой из вводимых<br />

<strong>к</strong>омпонент, и должна сохранять эти сведения в метаданных<br />

<strong>к</strong>омпоненты.<br />

Y<br />

P<br />

Это требуется в интересах обеспечения долговременной<br />

сохранности до<strong>к</strong>ументов - их доступности во времени. См. раздел<br />

11.7.<br />

Определенную информацию о формате <strong>к</strong>омпоненты обычно можно<br />

получить, исходя из расширения имени соответствующего файла<br />

(например, “.htm” или “.pdf”). Порой по расширению однозначно<br />

определить формат невозможно, - например, под расширением “.doc”<br />

могут с<strong>к</strong>рываться нес<strong>к</strong>оль<strong>к</strong>о не связанных между собой форматов.<br />

Одна<strong>к</strong>о по одному толь<strong>к</strong>о расширению зачастую невозможно<br />

установить не толь<strong>к</strong>о версию формата, но и сам формат. Во<br />

многих случаях это приемлемо, хотя о<strong>к</strong>ажется недостаточным<br />

там, где требуется обеспечить долговременную сохранность, или в<br />

случаях, где требуется высо<strong>к</strong>ая точность представления<br />

(например, точность отображения цвета).<br />

Файловых форматов много, и они подвержены частым изменениям, -<br />

следовательно, неразумно требовать от СЭД, чтобы она могла<br />

захватывать информацию обо всех возможных файловых форматах.<br />

Поэтому приемлемо:<br />

установить для СЭД списо<strong>к</strong> файловых форматов, <strong>к</strong>оторые<br />

могут быть распознаны;<br />

полагаться на авторитетный реестр файловых форматов, -<br />

предпочтительно специально разработанный в интересах<br />

обеспечения долговременной сохранности эле<strong>к</strong>тронных<br />

до<strong>к</strong>ументов.<br />

Версия 1.04<br />

8 сентября 2008 Стр. 96


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

В любом случае, организация-пользователь должна убедиться, что<br />

набор распознаваемых форматов достаточен с точ<strong>к</strong>и зрения ее<br />

требований <strong>к</strong> сохранности до<strong>к</strong>ументов.<br />

6.1.8 В процессе ввода до<strong>к</strong>ументов в СЭД должна проверяться<br />

правильность значений метаданных, вводимых в СЭД одновременно с<br />

до<strong>к</strong>ументами, - <strong>к</strong>а<strong>к</strong> минимум, на соответствие правилам модели<br />

метаданных MoReq2.<br />

Y<br />

См. та<strong>к</strong>же п. 6.1.34 данного раздела.<br />

6.1.9 Желательно, чтобы СЭД поддерживала <strong>к</strong>онтроль правильности<br />

значений элементов метаданных, используя алгоритмы с <strong>к</strong>онтрольной<br />

цифрой.<br />

Y<br />

Например, дела могут идентифицироваться при помощи 16-значного<br />

номера <strong>к</strong>редитной <strong>к</strong>арты. Последняя цифра этого номера является<br />

<strong>к</strong>онтрольной, вычисляемой по остальным пятнадцати цифрам<br />

(последняя цифра их суммы).<br />

Обычно будет считаться приемлемой реализация данной<br />

фун<strong>к</strong>циональной возможности путем предоставления при<strong>к</strong>ладного<br />

программного интерфейса (API), позволяющего организации<br />

под<strong>к</strong>лючить предпочитаемый ею алгоритм.<br />

6.1.10 СЭД должна давать пользователям возможность вводить эле<strong>к</strong>тронный<br />

до<strong>к</strong>умент в отсутствие программного приложения, использованного для<br />

его создания.<br />

Y<br />

Например, пользователь может получить, в <strong>к</strong>ачестве приложений <strong>к</strong><br />

сообщению эле<strong>к</strong>тронной почты, план прое<strong>к</strong>та и чертеж,<br />

выполненный в системе автоматизированного прое<strong>к</strong>тирования<br />

CAD/CAM. Если у пользователя нет доступа <strong>к</strong> программному<br />

приложению для планирования прое<strong>к</strong>та или <strong>к</strong> CAD/CAM-системе, он,<br />

возможно, не сможет просмотреть эти приложения. Желательно,<br />

чтобы, несмотря на это, у пользователя была возможность ввести<br />

эти приложения в <strong>к</strong>ачестве до<strong>к</strong>ументов в СЭД. СЭД может иметь<br />

программное обеспечение для просмотра та<strong>к</strong>их до<strong>к</strong>ументов<br />

(“viewer”),- но MoReq2 этого не требует.<br />

6.1.11 СЭД должна быть способна собирать и сохранять метаданные об<br />

эле<strong>к</strong>тронных до<strong>к</strong>ументах в соответствии с моделью метаданных<br />

MoReq2.<br />

6.1.12 Желательно, чтобы СЭД могла автоматичес<strong>к</strong>и извле<strong>к</strong>ать значения из<br />

полей, у<strong>к</strong>азанных исполнителем административной роли для<br />

определенных типов информационных материалов, автоматичес<strong>к</strong>и<br />

используя эти значения для заполнения элементов метаданных, в<br />

соответствии с моделью метаданных MoReq2.<br />

Y<br />

Y<br />

Версия 1.04<br />

8 сентября 2008 Стр. 97


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Фун<strong>к</strong>циональные возможности для выполнения данного <strong>требования</strong><br />

нужны толь<strong>к</strong>о для отдельных видов эле<strong>к</strong>тронных объе<strong>к</strong>тов, -<br />

например, для писем, созданных с применением определенного<br />

шаблона в определенном те<strong>к</strong>стовом реда<strong>к</strong>торе.<br />

Многие виды до<strong>к</strong>ументов, в<strong>к</strong>лючая не<strong>к</strong>оторые виды офисных<br />

до<strong>к</strong>ументов 49 и PDF-файлы, содержат определяемые пользователем<br />

элементы метаданных. Желательно иметь возможность та<strong>к</strong><br />

с<strong>к</strong>онфигурировать СЭД, чтобы она автоматичес<strong>к</strong>и извле<strong>к</strong>ала<br />

значения этих элементов метаданных и сохраняла их вместе с<br />

до<strong>к</strong>ументом.<br />

6.1.13 СЭД должна поддерживать заполнение всех элементов метаданных,<br />

у<strong>к</strong>азанных при <strong>к</strong>онфигурировании системы, и обеспечивать постоянное<br />

их сохранение в неразрывной связи с эле<strong>к</strong>тронным до<strong>к</strong>ументом.<br />

6.1.14 Желательно, чтобы в случае, <strong>к</strong>огда пользователь хочет ввести<br />

до<strong>к</strong>умент в СЭД, но не в состоянии обеспечить заполнение всех<br />

обязательных элементов метаданных, СЭД позволяла временно<br />

сохранить в ней та<strong>к</strong>ой до<strong>к</strong>умент.<br />

Y<br />

Y<br />

Иными словами, желательно, чтобы в СЭД имелись средства<br />

сохранения до<strong>к</strong>ументов даже в отсутствие полного набора<br />

обязательных метаданных, т.е. не завершив нормальный процесс<br />

ввода. Подразумевается создание отчетов об особых ситуациях и<br />

<strong>к</strong>онтроль над дальнейшей судьбой та<strong>к</strong>их до<strong>к</strong>ументов. Не<br />

подразумевается <strong>к</strong>а<strong>к</strong>их-либо требований в части возможности<br />

обработ<strong>к</strong>и та<strong>к</strong>их до<strong>к</strong>ументов наравне с нормальными до<strong>к</strong>ументами с<br />

целью выполнения э<strong>к</strong>спорта, передачи, создания представления и<br />

т.д. MoReq2 не предписывает способ выполнения данного<br />

<strong>требования</strong>.<br />

На более поздней стадии допус<strong>к</strong>ается изменение толь<strong>к</strong>о<br />

разрешенных для реда<strong>к</strong>тирования значений метаданных, а<br />

остальные метаданные (например, сведения о прохождении<br />

сообщения эле<strong>к</strong>тронной почты) должны оставаться неизменными.<br />

6.1.15 СЭД должна обеспечить, чтобы значения определённых элементов<br />

метаданных эле<strong>к</strong>тронного до<strong>к</strong>умента могли быть изменены толь<strong>к</strong>о<br />

авторизованными пользователями и исполнителями<br />

административных ролей, в соответствии с правилами, описанными в<br />

главе 12.<br />

6.1.16 СЭД должна обеспечить, чтобы вся<strong>к</strong>ий до<strong>к</strong>умент при вводе помещался<br />

<strong>к</strong>а<strong>к</strong> минимум в одну рубри<strong>к</strong>у или дело (или в суб-дело 50 дела, где это<br />

уместно).<br />

Y<br />

Y<br />

49<br />

50<br />

В оригинале здесь использован термин «информационные материалы» (documents). (прим.<br />

переводчи<strong>к</strong>а)<br />

Не очень понятно, зачем потребовалось специально упоминать суб-дело, ничего при этом не<br />

с<strong>к</strong>азав о томе (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 98


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

6.1.17 Желательно, чтобы в СЭД имелись средства автоматизации процесса<br />

ввода эле<strong>к</strong>тронных до<strong>к</strong>ументов 51 путем автоматичес<strong>к</strong>ого извлечения<br />

ма<strong>к</strong>симально возможного <strong>к</strong>оличества метаданных из ма<strong>к</strong>симально<br />

возможного числа видов до<strong>к</strong>ументов.<br />

N<br />

Основанием для этого <strong>требования</strong> является желание:<br />

минимизировать объем ручного ввода данных пользователем<br />

(опыт по<strong>к</strong>азывает, что во многих случаях необходимость<br />

вводить метаданные вручную приводит <strong>к</strong> тому, что<br />

пользователи от<strong>к</strong>азываются использовать систему);<br />

<br />

повысить точность метаданных.<br />

То, <strong>к</strong>а<strong>к</strong>ие именно элементы метаданных, и из <strong>к</strong>а<strong>к</strong>их видов<br />

до<strong>к</strong>ументов могут быть извлечены, зависит от <strong>к</strong>он<strong>к</strong>ретных<br />

обстоятельств. Не<strong>к</strong>оторые ре<strong>к</strong>омендации по этому поводу даны в<br />

модели метаданных.<br />

6.1.18 СЭД должна способствовать автоматизации процесса ввода и<br />

сохранения исходящих и внутренних информационных материалов<br />

(например, стандартным образом оформленных меморандумов и<br />

те<strong>к</strong>стовых писем в определённом файловом формате) <strong>к</strong>а<strong>к</strong> до<strong>к</strong>ументов,<br />

путем автоматичес<strong>к</strong>ого извлечения из них следующих метаданных:<br />

Y<br />

дата до<strong>к</strong>умента (у<strong>к</strong>азанная в теле до<strong>к</strong>умента);<br />

списо<strong>к</strong> получателей;<br />

списо<strong>к</strong> получателей <strong>к</strong>опий (если есть);<br />

название (заголово<strong>к</strong>. тема сообщения);<br />

списо<strong>к</strong> авторов;<br />

исходящий или внутренний регистрационный номер или ссыл<strong>к</strong>а<br />

(обычно обозначаемые <strong>к</strong>а<strong>к</strong> “наша ссыл<strong>к</strong>а”);<br />

по мере их наличия.<br />

51<br />

В оригинале везде в этом требовании используется термин documents (информационные<br />

материалы). Он заменен на термин «до<strong>к</strong>ументы» из соображений «читаемости», и в надежде,<br />

что это не ис<strong>к</strong>азит смысл <strong>требования</strong>. До<strong>к</strong>ументы, напомним, являются частным случаем<br />

информационных материалов (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 99


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

MoReq2 не устанавливает, <strong>к</strong>а<strong>к</strong>ое программное обеспечение и<br />

форматы офисных до<strong>к</strong>ументов и сообщений эле<strong>к</strong>тронной почты<br />

должны использоваться при подобной обработ<strong>к</strong>е. Извлечение<br />

метаданных может осуществляться путем ло<strong>к</strong>ализации<br />

метаданных внутри до<strong>к</strong>умента; путем использования шаблона<br />

до<strong>к</strong>умента для выделения метаданных и для заполнения блан<strong>к</strong>а<br />

до<strong>к</strong>умента; или же с использованием иных методов.<br />

6.1.19 СЭД должна фи<strong>к</strong>сировать дату и время ввода до<strong>к</strong>умента <strong>к</strong>а<strong>к</strong> в<br />

метаданных, та<strong>к</strong> и в <strong>к</strong>онтрольной информации.<br />

Y<br />

Если дата и время входят в состав уни<strong>к</strong>ального идентифи<strong>к</strong>атора<br />

до<strong>к</strong>умента, и если их можно явным образом из него извлечь, то<br />

отдельно сохранять дату и время необязательно.<br />

MoReq2 не предписывает необходимую точность значения времени.<br />

В большинстве СЭД время фи<strong>к</strong>сируется с точностью не хуже, чем<br />

до се<strong>к</strong>унды.<br />

В ряде юрисди<strong>к</strong>ций требуется проставление отмето<strong>к</strong> времени с<br />

использованием сертифицированного устройства или услуг<br />

сертифицированной службы времени. Там, где это имеет место,<br />

соответствующие <strong>требования</strong> должны быть в<strong>к</strong>лючены в<br />

национальное введение - "нулевую главу".<br />

6.1.20 Для <strong>к</strong>аждого введенного до<strong>к</strong>умента, СЭД должна быть способна<br />

по<strong>к</strong>азать на э<strong>к</strong>ране его метаданные, в<strong>к</strong>лючая те, что были у<strong>к</strong>азаны при<br />

<strong>к</strong>онфигурировании системы.<br />

Y<br />

Метаданные, у<strong>к</strong>азываемые при <strong>к</strong>онфигурировании системы, могут<br />

представлять собой произвольный набор элементов из<br />

соответствующего раздела главы 12.<br />

6.1.21 СЭД должна обеспечить наличие всех обязательных метаданных для<br />

<strong>к</strong>аждого введенного до<strong>к</strong>умента.<br />

6.1.22 В процессе ввода до<strong>к</strong>умента СЭД должна запрашивать у пользователя<br />

ввод тех обязательных метаданных, <strong>к</strong>оторые не были извлечены и<br />

сохранены автоматичес<strong>к</strong>и.<br />

6.1.23 СЭД должна поддерживать назначение <strong>к</strong>аждой рубри<strong>к</strong>е, делу, суб-делу<br />

и до<strong>к</strong>ументу нес<strong>к</strong>оль<strong>к</strong>их <strong>к</strong>лючевых слов.<br />

Y<br />

Y<br />

Y<br />

MoReq2 не требует наличия возможности назначать <strong>к</strong>лючевые<br />

слова томам.<br />

6.1.24 Желательно, чтобы СЭД давала возможность исполнителю<br />

административной роли установить во время <strong>к</strong>онфигурирования<br />

системы, является ли наличие <strong>к</strong>лючевых слов обязательным или<br />

необязательным для всех рубри<strong>к</strong>, дел и суб-дел.<br />

Y<br />

Версия 1.04<br />

8 сентября 2008 Стр. 100


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

6.1.25 СЭД должна допус<strong>к</strong>ать создание нес<strong>к</strong>оль<strong>к</strong>их объе<strong>к</strong>тов (рубри<strong>к</strong>, дел и<br />

т.д.), имеющих одну и ту же <strong>к</strong>омбинацию <strong>к</strong>лючевых слов. 52<br />

6.1.26 Желательно, чтобы СЭД давала возможность создающему<br />

определенный объе<strong>к</strong>т пользователю с<strong>к</strong>опировать, в ходе одной<br />

операции, <strong>к</strong>лючевые слова другого объе<strong>к</strong>та.<br />

6.1.27 Желательно, чтобы СЭД давала возможность пользователю для<br />

любого до<strong>к</strong>умента ввести идентифи<strong>к</strong>аторы одного или нес<strong>к</strong>оль<strong>к</strong>их<br />

язы<strong>к</strong>ов.<br />

6.1.28 СЭД должна поддерживать возможность выбора <strong>к</strong>лючевых слов и<br />

значений других элементов метаданных из <strong>к</strong>онтролируемых словарей<br />

(или из спис<strong>к</strong>ов допустимых значений), или возможность их провер<strong>к</strong>и<br />

по этим словарям (спис<strong>к</strong>ам).<br />

Y<br />

Y<br />

Y<br />

Y<br />

Например, путем использования спис<strong>к</strong>ов для выбора значений (pick<br />

lists) или тезаурусов. См. та<strong>к</strong>же требование 11.8.11.<br />

6.1.29 СЭД должна давать возможность вводить другие описательные и иные<br />

метаданные в момент ввода и/или на дальнейших стадиях обработ<strong>к</strong>и<br />

до<strong>к</strong>умента.<br />

6.1.30 В случае попыт<strong>к</strong>и ввести либо переименовать объе<strong>к</strong>т, используя уже<br />

существующее в рам<strong>к</strong>ах родительс<strong>к</strong>ого объе<strong>к</strong>та название (заголово<strong>к</strong>),<br />

СЭД должна сообщить об этом пользователю.<br />

Y<br />

Y<br />

См. та<strong>к</strong>же 11.8.6.<br />

6.1.31 В СЭД должна иметься возможность ввести ограничения,<br />

позволяющие толь<strong>к</strong>о исполнителю административной роли и другим<br />

авторизованным пользователям <strong>к</strong>орре<strong>к</strong>тировать название (заголово<strong>к</strong>)<br />

эле<strong>к</strong>тронного до<strong>к</strong>умента.<br />

Y<br />

Организация сама решает, будет она использовать эту<br />

фун<strong>к</strong>циональную возможность или нет.<br />

6.1.32 Когда пользователь вводит в СЭД информационный материал,<br />

существующий более чем в одной версии, то СЭД должна, <strong>к</strong>а<strong>к</strong><br />

минимум, дать пользователю возможность выбрать один из<br />

перечисленных вариантов:<br />

Y<br />

зарегистрировать все версии информационного материала <strong>к</strong>а<strong>к</strong> один<br />

до<strong>к</strong>умент;<br />

зарегистрировать в <strong>к</strong>ачестве до<strong>к</strong>умента толь<strong>к</strong>о одну определенную<br />

версию;<br />

52<br />

По поводу <strong>к</strong>лючевых слов см. <strong>к</strong>омментарий в «Предисловии переводчи<strong>к</strong>а» (прим.<br />

переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 101


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

зарегистрировать <strong>к</strong>аждую из версий в <strong>к</strong>ачестве отдельного<br />

до<strong>к</strong>умента.<br />

6.1.33 Желательно, чтобы СЭД могла автоматизировать процесс принятия<br />

решений по размещению (<strong>к</strong>лассифи<strong>к</strong>ации) эле<strong>к</strong>тронных до<strong>к</strong>ументов, за<br />

счёт использования <strong>к</strong>а<strong>к</strong> минимум одной из перечисленных мер:<br />

P<br />

предоставляя пользователю либо исполнителю определенной роли<br />

доступ толь<strong>к</strong>о <strong>к</strong> подмножеству <strong>к</strong>лассифи<strong>к</strong>ационной схемы;<br />

предлагая пользователю последние использованные им рубри<strong>к</strong>и<br />

или дела;<br />

предлагая пользователю наиболее часто используемые им рубри<strong>к</strong>и<br />

или дела;<br />

предлагая рубри<strong>к</strong>и или дела в соответствии с результатами<br />

анализа метаданных до<strong>к</strong>умента (например, по результатам анализа<br />

значащих слов в названии до<strong>к</strong>умента или в теме сообщения<br />

эле<strong>к</strong>тронной почты);<br />

предлагая рубри<strong>к</strong>и или дела в соответствии с результатами<br />

анализа содержимого до<strong>к</strong>ументов.<br />

6.1.34 Желательно, чтобы СЭД не требовала выполнения всего процесса<br />

ввода одним и тем же пользователем, допус<strong>к</strong>ая участие нес<strong>к</strong>оль<strong>к</strong>их<br />

пользователей.<br />

Y<br />

Желательно, чтобы СЭД допус<strong>к</strong>ала возможность разделить процесс<br />

ввода на этапы, выполняемые различными пользователями. Обычно<br />

это означает, что один пользователь вводит определенные<br />

метаданные, а затем передает эле<strong>к</strong>тронный до<strong>к</strong>умент другому<br />

пользователю, <strong>к</strong>оторый вводит остальные метаданные и<br />

<strong>к</strong>лассифицирует до<strong>к</strong>умент (размещает его в системе).<br />

6.1.35 Желательно, чтобы в СЭД имелись простые средства автоматизации<br />

процессов (workflow), поддерживающие простую маршрутизацию<br />

информационного материала на согласование и утверждение до его<br />

ввода; а та<strong>к</strong>же прото<strong>к</strong>олирование принятых решений, их авторов, и<br />

возможность для <strong>к</strong>аждого автора у<strong>к</strong>азать обоснование принятого<br />

решения.<br />

Y<br />

Следует отметить, что для этого нужны толь<strong>к</strong>о базовые<br />

возможности по <strong>управлению</strong> процессами (workflow). Здесь<br />

сознательно не рассматривается полный набор возможностей<br />

workflow, описанный в главе 10.<br />

6.1.36 Желательно, чтобы СЭД предоставляла API-интерфейс для<br />

при<strong>к</strong>ладного программирования, позволяющий принимать из другой<br />

при<strong>к</strong>ладной системы и вводить в реальном времени в СЭД отдельные<br />

до<strong>к</strong>ументов и транза<strong>к</strong>ции.<br />

N<br />

Версия 1.04<br />

8 сентября 2008 Стр. 102


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Ка<strong>к</strong> отмечено в разделе 1.4, СЭД с её фун<strong>к</strong>циональными<br />

возможностями может использоваться <strong>к</strong>а<strong>к</strong> составная часть более<br />

масштабной системы. В этом случае может потребоваться, чтобы<br />

СЭД принимала через API-интерфейс до<strong>к</strong>ументы из другой системы,<br />

- например, от <strong>к</strong>орпоративного бизнес-приложения, та<strong>к</strong>ого, <strong>к</strong>а<strong>к</strong><br />

система управление взаимоотношениями с <strong>к</strong>лиентами (Customer<br />

Relationship Management, CRM); или от программного приложения,<br />

поддерживающего основную деловую деятельность, - для того,<br />

чтобы дать возможность СЭД захватывать и сохранять<br />

отдельные до<strong>к</strong>ументы.<br />

6.1.37 Желательно, чтобы, где это возможно, СЭД выдавала предупреждение<br />

при попыт<strong>к</strong>е пользователя ввести до<strong>к</strong>умент, представляющий собой<br />

сообщение эле<strong>к</strong>тронной почты, <strong>к</strong>оторый уже был помещен в это же<br />

дело (или, в случае размещения до<strong>к</strong>умента непосредственно в<br />

рубри<strong>к</strong>е, - в эту же рубри<strong>к</strong>у).<br />

Y<br />

MoReq2 не устанавливает, <strong>к</strong>а<strong>к</strong>им образом идентифицируется<br />

сообщение эле<strong>к</strong>тронной почты. Подходящим способом может быть,<br />

например, использование интернет-идентифи<strong>к</strong>атора сообщения<br />

(internet message ID).<br />

В определенных случаях выполнение этого <strong>требования</strong> может<br />

о<strong>к</strong>азаться невозможным вследствие логи<strong>к</strong>и работы системы,<br />

например, тогда, <strong>к</strong>огда до<strong>к</strong>умент - сообщение эле<strong>к</strong>тронной почты<br />

был помещен в дело, <strong>к</strong> <strong>к</strong>оторому у пользователя нет доступа.<br />

6.1.38 Желательно, чтобы, где это возможно, СЭД выдавала предупреждение<br />

при попыт<strong>к</strong>е пользователя ввести до<strong>к</strong>умент (за ис<strong>к</strong>лючением<br />

до<strong>к</strong>ументов - сообщений эле<strong>к</strong>тронной почты, <strong>к</strong>оторые рассматриваются<br />

в п. 6.1.37), имеющий тот же <strong>к</strong>онтент (содержание), что и другой<br />

до<strong>к</strong>умент, <strong>к</strong>оторый уже был помещен в это же дело (или, в случае<br />

размещения до<strong>к</strong>умента непосредственно в рубри<strong>к</strong>е, - в эту же рубри<strong>к</strong>у).<br />

6.1.39 Желательно, чтобы, где это возможно, СЭД выдавала предупреждение<br />

при попыт<strong>к</strong>е пользователя ввести до<strong>к</strong>умент (за ис<strong>к</strong>лючением<br />

до<strong>к</strong>ументов - сообщений эле<strong>к</strong>тронной почты, <strong>к</strong>оторые рассматриваются<br />

в п. 6.1.37), имеющий те же значения идентифицирующих метаданных,<br />

что и другой до<strong>к</strong>умент, <strong>к</strong>оторый уже был помещен в это же дело (или, в<br />

случае размещения до<strong>к</strong>умента непосредственно в рубри<strong>к</strong>е, - в эту же<br />

рубри<strong>к</strong>у).<br />

Y<br />

Y<br />

Под идентифицирующими метаданными в данном требовании<br />

понимаются: 53<br />

Название;<br />

53<br />

В наших условия желательно та<strong>к</strong>же выдавать предупреждение при попыт<strong>к</strong>е ввести в то же<br />

дело или рубри<strong>к</strong>у до<strong>к</strong>умент с регистрационным номером, совпадающим с регистрационным<br />

номером уже имеющегося в этом деле или рубри<strong>к</strong>е до<strong>к</strong>умента. (прим. переводчи<strong>к</strong>а)<br />

Версия 1.04<br />

8 сентября 2008 Стр. 103


Специфи<strong>к</strong>ации MoReq2<br />

№ Требование Тест.<br />

Дата;<br />

Автор;<br />

Адресат.<br />

6.1.40 Желательно, чтобы, где это возможно и уместно, СЭД выдавала<br />

сообщение при попыт<strong>к</strong>е ввести до<strong>к</strong>умент, неполнота или<br />

несогласованность <strong>к</strong>оторого ставят под сомнение его надежность.<br />

N<br />

Например, распоряжение о за<strong>к</strong>уп<strong>к</strong>е, не имеющее правильной<br />

эле<strong>к</strong>тронной подписи; или счет от неизвестного поставщи<strong>к</strong>а..<br />

6.1.41 СЭД должна давать возможность исполнителю административной роли<br />

(но не исполнителям пользовательс<strong>к</strong>их ролей) добавить до<strong>к</strong>умент в<br />

ранее за<strong>к</strong>рытый том, при условии, что дата до<strong>к</strong>умента не позднее даты<br />

за<strong>к</strong>рытия тома. В случае, <strong>к</strong>огда та<strong>к</strong>ое добавление имеет место:<br />

Y<br />

СЭД должна потребовать, чтобы исполнитель административной<br />

роли ввел в метаданные <strong>к</strong>а<strong>к</strong> тома, та<strong>к</strong> и до<strong>к</strong>умента сведения о<br />

причине возни<strong>к</strong>новения подобной особой ситуации;<br />

Эти сведения о причине СЭД должна автоматичес<strong>к</strong>и сохранить в<br />

<strong>к</strong>онтрольной информации.<br />

При выполнении подобного действия не должна обновляться<br />

сохраненная в метаданных дата за<strong>к</strong>рытия тома.<br />

Эта возможность предназначена для исправления ошибо<strong>к</strong>, сделанных<br />

пользователями, - например, в случае, <strong>к</strong>огда том был неумышленно<br />

за<strong>к</strong>рыт. В этой связи важно, чтобы особая ситуация, повле<strong>к</strong>шая за<br />

собой использование данного средства, была должным образом<br />

задо<strong>к</strong>ументирована.<br />

MoReq2 не предписывает способа реализации данного <strong>требования</strong>.<br />

Оно может быть реализовано за счет временного переот<strong>к</strong>рытия<br />

за<strong>к</strong>рытого тома, или же иным способом.<br />

6.2 Массовый ввод до<strong>к</strong>ументов<br />

Массивы до<strong>к</strong>ументов могут поступать в СЭД различными путями, например:<br />

массовая передача из совместимой эле<strong>к</strong>тронно-информационной системы (EDMS);<br />

массовая передача из совместимой СЭД;<br />

<strong>к</strong>а<strong>к</strong> отдельный совместимый файл данных, содержащий массив однотипных до<strong>к</strong>ументов<br />

(например, поступившие за день инвойсы);<br />

из совместимой системы с<strong>к</strong>анирования или управления графичес<strong>к</strong>ими образами;<br />

Версия 1.04<br />

8 сентября 2008 Стр. 104


Специфи<strong>к</strong>ации MoReq2<br />

до<strong>к</strong>ументы из иерархичес<strong>к</strong>ой стру<strong>к</strong>туры («дерева») дире<strong>к</strong>торий (папо<strong>к</strong>) операционной<br />

системы.<br />

СЭД должна быть в состоянии принять эти до<strong>к</strong>ументы, и должна иметь фун<strong>к</strong>циональные<br />

возможности для управления процессом массового ввода и для сохранения <strong>к</strong>онтента и<br />

стру<strong>к</strong>туры импортируемых до<strong>к</strong>ументов.<br />

При выполнении массового ввода СЭД должна обеспечить ввод той же информации, что и в<br />

процессе обычного ввода, - а именно, самих до<strong>к</strong>ументов и их метаданных. СЭД должна<br />

та<strong>к</strong>же разместить до<strong>к</strong>ументы в <strong>к</strong>лассифи<strong>к</strong>ационной схеме, - если нужно, расширяя её (см. п.<br />

3.1.12), - и, возможно, вводя та<strong>к</strong>же <strong>к</strong>онтрольную информацию. На<strong>к</strong>онец, должна быть<br />

предусмотрена обработ<strong>к</strong>а особых ситуаций и ошибо<strong>к</strong>, <strong>к</strong>оторые могут возни<strong>к</strong>нуть в процессе<br />

массового ввода.<br />

В момент написания данного до<strong>к</strong>умента, разработ<strong>к</strong>а XML-схемы для MoReq2 толь<strong>к</strong>о<br />

начинается. Ожидается, что в этой схеме будет реализована модель метаданных MoReq2, и<br />

что она послужит идеальным прото<strong>к</strong>олом для массового импорта эле<strong>к</strong>тронных до<strong>к</strong>ументов<br />

из других СЭД, соответствующих <strong>требования</strong>м MoReq2.<br />

№ Требование Тест.<br />

6.2.1 После опубли<strong>к</strong>ования формальной XML-схемы для MoReq2, СЭД<br />

должна быть способна выполнять массовый импорт до<strong>к</strong>ументов в<br />

виде, соответствующем этой схеме.<br />

P<br />

См. та<strong>к</strong>же требование 5.3.1 относительно э<strong>к</strong>спорта до<strong>к</strong>ументов.<br />

Совместно эти два <strong>требования</strong> обеспечивают возможность<br />

взаимодействия соответствующих <strong>требования</strong>м MoReq2 систем<br />

эле<strong>к</strong>тронного до<strong>к</strong>ументооборота.<br />

6.2.2 В СЭД должна иметься возможность ввода создаваемых другими<br />

системами транза<strong>к</strong>ционных до<strong>к</strong>ументов. Сюда входят:<br />

P<br />

поддерж<strong>к</strong>а «па<strong>к</strong>етного» режима импорта транза<strong>к</strong>ций;<br />

поддерж<strong>к</strong>а реда<strong>к</strong>тируемых правил, позволяющих настраивать<br />

процесс автоматичес<strong>к</strong>ого ввода до<strong>к</strong>ументов;<br />

провер<strong>к</strong>а целостности данных.<br />

MoReq2 не предписывает способ реализации данной фун<strong>к</strong>циональной<br />

возможности.<br />

6.2.3 В ходе массового ввода СЭД должна быть способна автоматичес<strong>к</strong>и<br />

вводить ассоциированные с до<strong>к</strong>ументами метаданные (допус<strong>к</strong>ая<br />

ручной ввод недостающих или неверных метаданных).<br />

P<br />

Версия 1.04<br />

8 сентября 2008 Стр. 105


Специфи<strong>к</strong>ации MoReq2<br />

6.2.4 В тех случаях, <strong>к</strong>огда СЭД вводит метаданные ряда до<strong>к</strong>ументов в<br />

процессе импорта, она должна проверять их правильность по тем же<br />

правилам, <strong>к</strong>оторые использовались бы при ручном вводе до<strong>к</strong>ументов.<br />

Если в процессе провер<strong>к</strong>и обнаруживаются ошиб<strong>к</strong>и (например,<br />

отсутствие обязательных метаданных, ошиб<strong>к</strong>и в формате), то СЭД<br />

должна поставить об этом в известность пользователя, выполняющего<br />

импорт, идентифицировав соответствующие метаданные, а та<strong>к</strong>же<br />

сохранить в <strong>к</strong>онтрольной информации сведения об ошиб<strong>к</strong>ах и<br />

<strong>к</strong>орре<strong>к</strong>тирующих действиях.<br />

Y<br />

В идеальном случае, импортируемые до<strong>к</strong>ументы будет иметь<br />

метаданные, полностью соответствующие модели метаданных. В<br />

ряде случаев метаданные могут не соответствовать модели<br />

метаданных, и тогда возможны нес<strong>к</strong>оль<strong>к</strong>о исходов (MoReq2 не<br />

предписывает ни один из них), а именно, следующие:<br />

процесс импорта полностью пре<strong>к</strong>ращается;<br />

отменяется импорт до<strong>к</strong>умента, метаданные <strong>к</strong>оторой не<br />

соответствуют модели метаданных;<br />

пользователь должен сделать выбор: либо исправить ошиб<strong>к</strong>у,<br />

либо отменить импорт соответствующей рубри<strong>к</strong>и;<br />

Данные импортируются и сохраняются в виде неполного<br />

временного до<strong>к</strong>умента (этот вариант идейно близо<strong>к</strong> с<br />

требованием о возможности разделить процесс ввода на этапы,<br />

выполняемые нес<strong>к</strong>оль<strong>к</strong>ими пользователями, см. 6.1.34).<br />

6.2.5 СЭД должна быть способна импортировать до<strong>к</strong>ументированную<br />

<strong>к</strong>онтрольную информацию (audit trail records), по<strong>к</strong>азывающую историю<br />

импортируемых до<strong>к</strong>ументов.<br />

6.2.6 СЭД не должна размещать сопровождающую импортируемые<br />

до<strong>к</strong>ументы до<strong>к</strong>ументированную <strong>к</strong>онтрольную информацию в<br />

собственных стру<strong>к</strong>турах для хранения <strong>к</strong>онтрольной информации. Эту<br />

до<strong>к</strong>ументированную <strong>к</strong>онтрольную информацию следует сохранить<br />

отдельно.<br />

Y<br />

Y<br />

Импортированная до<strong>к</strong>ументированная <strong>к</strong>онтрольная информация<br />

должна сохраняться отдельно в связи с тем, чтобы избежать<br />

создания механизма, <strong>к</strong>оторый бы позволил исполнителям<br />

административной роли изменить <strong>к</strong>онтрольную информацию либо<br />

с<strong>к</strong>омпрометировать ее целостность. MoReq2 не предписывает, <strong>к</strong>а<strong>к</strong><br />

этого достичь. Импортированная <strong>к</strong>онтрольная информация может,<br />

например, сохраняться в виде до<strong>к</strong>умента вместе с<br />

импортированными до<strong>к</strong>ументами; или же в <strong>к</strong>ачестве отдельного<br />

объе<strong>к</strong>та, распознаваемого системой <strong>к</strong>а<strong>к</strong> <strong>к</strong>онтрольная информация,<br />

импортированная из другой системы.<br />

6.2.7 СЭД должна иметь средства управления очередями ввода (input<br />

queues).<br />

Y<br />

Версия 1.04<br />

8 сентября 2008 Стр. 106


Специфи<strong>к</strong>ации MoReq2<br />

Ожидается наличие следующих возможностей:<br />

просмотр очередей;<br />

приостанов<strong>к</strong>а всех или не<strong>к</strong>оторых очередей;<br />

возобновление работы всех или не<strong>к</strong>оторых очередей;<br />

уничтожение очереди.<br />

6.2.8 СЭД должна предоставлять исполнителю административной роли<br />

опциональную возможность настроить СЭД та<strong>к</strong>, чтобы<br />

импортированные рубри<strong>к</strong>и, дела и тома автоматичес<strong>к</strong>и за<strong>к</strong>рывалис