Типовые требования к управлению электронными официальными документами (стр. 8 )

На диаграмме сущности – дела э(34), официальные документы э(52) и др. – представлены в виде прямоугольников. Соединяющие их линии представляют отношения между сущностями. Каждое отношение снабжено текстовым комментарием, смысл которого следует трактовать в соответствии с направлением стрелки. На каждом конце линии, отображающей связь, находится признак чала вхождений (строгое значение или множество). Эти признаки поясняются в легенде диаграммы. Например, диаграмма 2.3 означает, что один официальный документ э(52) состоит из одного или более компонентов э(19) (см. направление стрелки связей).

Диаграмма 2.3

Дуга, пересекающая две или более связи, означает, что связи являются взаимоисключающими для данного конкретного случая. Так, например, дуга на диаграмме 2.4 означает, что «каждый официальный документ э(52) сохранен либо в томе э(74), либо в разделе э(66), но не в обоих».

Диаграмма 2.4

Следует отметить, что сущность «класс э(11)» связана сама с собой отношением «состоит из». Это отношение (рекурсивное отношение) формально описывает связь между классами э(11) в иерархической схеме классификации э(14), где класс э(11) может состоять из других классов э(11). Если это отношение (иногда называемое рекурсивное отношение) убрать, модель аналогично применима к неиерархическим отношениям.

В дальнейшем тексте MoReq2 термины, выделенные голубым цветом, будут означать, что термин из глоссария употребляется впервые. В электронной версии это гиперссылка к определению, так CTRL + click на термин отошлет к определению в глоссарии, а CTRL + click на определение в глоссарии отошлет обратно к термину.

Диаграмма 2.5

СХЕМА КЛАССИФИКАЦИИ И ОРГАНИЗАЦИЯ ДЕЛ

Эта глава содержит требования к управлению схемой классификации э(14) и к организации дел э(34).  В начале главы, в разделе 3.1, перечисляются требования по настройке схемы классификации э(34), затем перечисляются требования к классам э(11) и делам э(34) (раздел 3.2), томам э(74) и разделам э(66) (раздел 3.3). В разделе 3.4 излагаются требования по поддержке схемы классификации.

Схема классификации э(14) является основой любой СУЭОД э(32).  Она позволяет электронным официальным документам э(31) быть сохраненными вместе с другими официальными документами э(52),  включенными в данный контекст, определяя способ, которым электронные официальные документы э(31) могут быть организованы в электронные э(29) дела э(34), а также отношения (связи) между этими делами э(34).

Значимым различием между MoReq2 и ее предшественницей является то, что MoReq2 позволяет сразу провозглашать официальный документ э(52) принадлежащим непосредственно классу э(11), также как и делу э(34). Первая версия MoReq не позволяла непосредственно провозглашать (официальный документ э(52)) принадлежащим определенному классу э(11), она позволяла провозглашать (официальный документ э(52)) принадлежащим только делу э(34).

MoReq2, таким образом, позволяет захватить э(8) официальный документ э(52) в любой из следующих:

Класс э(11); Дело э(34); Раздел э(66); Том э(74).

Официальные документы э(52) чаще всего захватываются э(8) в тома э(74). Объяснение необходимости захвата э(8) официальных документов э(52) в дела э(34) и разделы э(66), см. э3.3.1, э3.3.2 и э3.3.3.

Захват э(8) официальных документов э(52) в классы э(11) проиллюстрирована на диаграмме 3.1, которая добавляет такие официальные документы э(52)  (серого цвета) к диаграмме 2.1.

Диаграмма 3.1

Эти изменения были внесены, чтобы соответствовать требованиям много-томных э(74) систем управления досье э(9). Эти изменения, однако, не исключают обязательности иерархической схемы классификации э(14) или существования дел э(34). Неправильное использование данного изменения может нести риск возникновения проблем в управлении официальными документами э(52) в будущем, и пользователям э(68) MoReq2 рекомендуется использовать данные функции только после тщательного анализа. Большинству пользователей э(68) MoReq2 вряд ли понадобятся данные функции, так что MoReq2 включает требование о блокировании их применения.

Соответственно, MoReq2 содержит требование поддержки иерархической классификации э(12).  Это необходимо, поскольку:

иерархические схемы способны обеспечивать эффективную, стабильную и четкую организацию официальных документов э(52); иерархические схемы являются наиболее распространенными в Европе.

Они также поддерживают совместимость с предыдущей версией MoReq.  Многие требования основываются на понятии «класс э(11)». Во многих случаях допускается применение требований к неиерархическим схемам классификации э(14), но это не всегда возможно.

Существенно важно, что схема классификации э(14) (технически, схема классификации э(14) официальных документов э(52)) тесно связана с потребностями бизнеса организации. Практика подсказывает, что организация в первую очередь определяет схему классификации э(14)  бизнеса (деятельности), а уже после этого создает схему классификации э(14) официальных документов э(52).

Настройка схемы классификации

№	Требование	Тест
СУЭОД э(32) обязательно должна поддерживать и быть совместимой со схемой  классификации э(14) деятельности организации.	Н
Это требование чаще всего нетестируемо; оно включено в качестве напоминания пользователям э(68) MoReq2 о необходимости приведения в соответствие схемы классификации э(14), используемой в СУЭОД э(32), бизнес-потребностям организации. Эти потребности должны быть отражены в систематизации официальных документов э(52) вне СУЭОД э(32).
СУЭОД э(32) обязательно должна постоянно поддерживать внутреннюю целостность (ссылочная целостность и др.) вне зависимости от: выполнения административных действий; действий других пользователей э(68); сбоев системных компонентов э(19).	В
Иными словами, должно быть невозможным возникновение ситуации когда любое действие пользователя э(68) или любой сбой системы приводит к нарушению целостности СУЭОД э(32) или ее базы данных.
СУЭОД э(32) должна позволять ролям администраторов э(1) обозначать каждую схему классификации э(14) заголовком, описанием и должна автоматически присваивать схеме классификации э(14)  идентфикатор.	Д
Эти  метаданные э(40) будут поддерживать такие функции, как экспорт э(33) схемы классификации э(14) и официальных документов э(52).
СУЭОД э(32) обязательно должна быть способной поддерживать схему классификации э(14), которая может представлять дела э(34) и официальные документы э(52) организованными в иерархию классов э(11).	Д
Использование иерархической схемы классификации э(14) является обязательным для соответствия MoReq2.  Это необходимо для обеспечения принципов наследования для порядка хранения, отбора и передачи э(61) и других метаданных э(40), а также облегчения навигации.
Поддержка по крайней мере трех уровней – является минимальным требованием; во многих случаях потребуется большее количество уровней.
СУЭОД э(32) обязательно должна разрешать управление схемой классификации э(14) только роли администратора э(1), в соответствии с требованием 3.1.6.	Д
В данном требовании «управление» понимается как действия, описанные в разделе 3.1 и разделе 3.4.
СУЭОД э(32) должна разрешать управление индивидуальными классами э(11) в соответствии с определенными ролями пользователей э(71) и/или в соответствии с определенными группами э(37) пользователей э(68).	Д
В данном требовании «управление» понимается так же, как в требовании 3.1.5. Оно применяется в двух случаях, когда: Большие схемы классификации э(14), которые являются слишком большими, чтобы быть поддержанными централизованно (и как вследствие этого, имеющие централизованное управление для верхних уровней и распределенное управление для нижних уровней); Схемы классификации э(14) которые включают классы э(11) для управления досье э(9), которыми нужно управлять в структурном подразделении, работающем с этими досье э(9), согласно предоставленным уполномоченным пользователям э(6) правам доступа.
СУЭОД э(32) ни в коем случае не должна ограничивать число уровней иерархии в схеме классификации э(14).	В
В большинстве настроек число необходимых уровней не превышает десяти.
СУЭОД э(32) обязательно должна обеспечивать создание схемы классификации э(14) на этапе конфигурации э(20) системы, чтобы обеспечить ее  готовность для захвата э(8) и/или импорта э(38) электронных официальных документов э(31).	Д
Данное требование позволит создать схему классификации э(14) во время конфигурации СУЭОД э(32), еще до ее использования для управления официальными документами э(31).
СУЭОД э(32) обязательно должна позволять роли администратора э(1) на этапе конфигурации э(20) настраивать механизм(ы) именования.	Д
СУЭОД э(32) должна разрешать вводить текстовые примечания (описания) ко всем классам э(11), делам э(34), разделам э(66) и томам э(74).	Д
Текстовые примечания делаются с целью пояснения содержания и/или описания исключительных ситуаций для классов э(11), дел э(34) и разделов э(66) и томов э(74) в помощь пользователям э(68).
Если формальная XML-схема MoReq2  опубликована, СУЭОД э(32) обязательно должна обладать способностью импортировать э(38) и экспортировать э(33) официальные документы э(52) и т. п. в форме, соответствующей этой схеме.	Д
СУЭОД э(32) обязательно должна поддерживать импорт э(38) всей схемы классификации э(14) или ее частей, как на этапе конфигурации э(20), так и на любом другом этапе (жизненного цикла СУЭОД э(32) – прим. переводчика).	Д
Это требование позволяет создать схему классификации э(14) во время конфигурации СУЭОД э(32), еще до ее использования для управления официальными документами э(52). По мере импортирования э(38) любой(ых) ее части(ей) можно их добавлять к существующей схеме или можно создать новую схему классификации э(14), если она не существует.
Когда СУЭОД э(32) импортирует э(38) всю схему классификации э(14) или ее часть(и), она обязательно должна позволять импортировать э(38) соответствующие метаданные э(40), порядок хранения, отбора и передачи э(61) и протокол аудита э(4), если они существуют.	Д
В идеальном случае, схема классификации э(14) которая была  импортирована э(38) будет содержать метаданные э(40) класса э(11) и порядок хранения, отбора и передачи э(61). В противном случае они могут отсутствовать или быть неполными.
Там где СУЭОД э(32) импортирует э(38) метаданные э(40) схемы классификации э(14), она обязательно должна обладать возможностью отвергнуть любой класс э(11), не имеющий заголовка, и создать отчет для роли администратора э(1), со указанием классов э(11), которые были отвергнуты.	Д
В СУЭОД э(32), не соответствующих MoReq2, допустимо, чтобы у класса э(11) не было заголовка (значение не определено), но такой класс э(11) будет невозможно использовать в СУЭОД э(32), соответствующих MoReq2.
В случае если СУЭОД э(32) импортирует э(38) метаданные э(40) схемы классификации э(14), СУЭОД э(32) обязательно должна присваивать каждому импортируемому э(38) классу э(11) иерархический код одним из следующих способов в соответствии с набором опций, установленных ролью администратора э(1): следуя тем же правилам, которые использовались для ручной настройки схемы классификации э(14); сохраняя оригинальные коды во всей их полноте (возможно только в случае совместимости структур); добавляя оригинальные коды к кодам принимающей схемы.	В
Если иерархия, которая импортируется э(38), уже включает в себя коды иерархического класса э(11) (например, 4/6/4), то их использование в качестве кодов для СУЭОД э(32) может оказаться невозможным, т. к. последовательность и уникальность могут быть гарантированы.
Существует много возможных сценариев такого импорта э(38), с различными видами совместимости между иерархическими схемами нумерации. MoReq2 не предписывает результат попытки выбора варианта, который логически невозможен ввиду несовместимости схем.
Если существующие коды не могут использоваться, они могут быть обработаны в соответствии с ситуацией, например, скопированы в элемент метаданных э(40) под названием «старый код класса э(11)».
В случае если СУЭОД э(32) импортирует э(38) метаданные э(40) и порядок хранения, отбора и передачи э(61) для схемы классификации э(14), она обязательно должна проверить их, используя те же правила, которые использовались бы при ручной настройке схемы классификации э(14) (см. главу 12). Там где процесс проверки правильности находит ошибки (например, отсутствие обязательных метаданных э(40) или ошибки формата э(36)), это должно быть доведено до внимания роли администратора э(1), выполняющего импорт э(38) с идентификацией вовлеченных метаданных э(40).	Д
В идеальных случаях, схема классификации э(14), которая импортируется э(38), будет содержать метаданные э(40) (например, метаданные э(40) для ее классов э(11)), которые будут полностью соответствовать «Модели метаданных MoReq2» (см. приложение 9). В других случаях метаданные э(40) могут не соответствовать. В таких случаях возможны несколько решений, MoReq2 не обязывает использовать какое-либо из них. Возможные варианты включают следующие: Полный импорт э(38) отменен, и лицо, выполняющее роль администратора э(1) информировано о причине отмены, Импорт э(38) класса э(11), содержащего несоответствующие метаданные э(40), отменен, и лицо, выполняющее роль администратора э(1), информировано о причине отмены; Лицу, выполняющему роль администратора э(1), требуется выбрать между исправлением ошибки и отменой импорта э(38) несоответствующего класса э(11); Импорт э(38) продолжается, несмотря на то, что часть метаданных э(40) является несовместимой; несоответствующие метаданные заменяются значениями по умолчанию, установленными для ошибочных элементов, и  выдается отчет об ошибке.
Информирование лица, исполняющего роль администратора э(1), не означает, что процесс импорта э(38) происходит интерактивно или в режиме реального времени; приемлемым является процесс происходящий в фоновом или пакетном режиме.
СУЭОД э(32) должна поддерживать экспорт э(33) всей или части схемы классификации э(14).	Д
В случае если СУЭОД э(32) поддерживает экспорт э(33) всей или части  схемы классификации э(14), это обязательно должно включать ассоциированные метаданные э(40); лицо исполняющее роль администратора э(1) должно иметь возможность выбрать какие метаданные э(40) экспортируются э(33).	Д
В случае если СУЭОД э(32) поддерживает экспорт э(33) всей или части схемы классификации э(14), это обязательно должно включать ассоциированные порядки хранения, отбора и передачи э(61) по усмотрению лица исполняющего роль администратора э(1).	Д
В случае если СУЭОД э(32) поддерживает экспорт э(33) всей или части схемы классификации э(14), это обязательно должно  включать все или избранные данные протокола аудита э(4), в соответствии с выбором лица исполняющего роль администратора э(1).	Д
В случае если СУЭОД э(32) поддерживает экспорт э(33) (для любого из вышеуказанных требований),  она обязательно должна использовать полностью документированный метод для связи сущностей друг с другом.	Д
Документация метода должна определять, как официальные документы э(52), дела э(34), классы э(11) и т. д. и их отношения друг с другом будут выражены. См. также 3.1.22.
В случае если СУЭОД э(32) поддерживает экспорт э(33) (любого из вышеуказанных требований), она должна экспортировать э(33) информацию в XML или эквивалентном открытом стандартном формате э(36).	Д
В случае если СУЭОД э(32) поддерживает копирование всей или части схемы классификации э(14), это обязательно должно включать все ассоциированные метаданные э(40).	Д
В случае если СУЭОД э(32) поддерживает копирование всей или части схемы классификации э(14), это обязательно должно включать все ассоциированные порядки хранения, отбора и передачи э(61).	Д
СУЭОД э(32) должна позволять лицам исполняющим роль администратора э(1) добавлять новые классы э(11) в любом пункте в любом классе э(11), пока дела э(34) или официальные документы э(52) не сохранены в этом пункте.	Д
MoReq2 не позволяет делам э(34) и классам э(11) существовать на одном и том же уровне в пределах класса э(11) (другими словами, дела э(34) и классы э(11) не могут смешиваться в одном узле в иерархии схемы классификации э(14)). Это диктуется передовым опытом управления официальными документами э(52).
СУЭОД э(32) должна поддерживать определение и одновременное использование множественных схем классификации э(14).	Д
Для многих организаций будет обязательным использование единственной схемы классификации э(14) для первичной классификации э(12) всех дел э(34) в СУЭОД э(32). Это требование позволяет некоторым делам э(34) в СУЭОД э(32) принадлежать к одной схеме классификации э(14), а остальным делам э(34) – принадлежать к другой. Это может потребоваться, например, после слияния двух организаций, или когда разные наборы официальных документов э(52) в одной организации требуют разных режимов управления.

Классы и дела

В данном разделе приведены требования применительно к классам и делам.