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

Термин «досье / case files э(9)» в глоссарии MoReq2 определяется как дело э(34), относящееся к одной или более транзакциям, произведенным полностью или частично структурированным путем. В данном контексте «структурированный» означает, что транзакции следуют правилам, которые указаны (или могут быть) документированы, являются последовательным процессом  (они не позволяют пользователям э(68) изобретать абсолютно  новые части процесса), и что они повторяются во многих случаях похожих транзакций. Содержимое официальных документов э(52) в досье э(9) может быть структурированным (например, заполненные компьютерные формы) или неструктурированными (например, сообщения электронной почты или отсканированные изображения бумажных форм), в любой комбинации; ключевой отличительной характеристикой досье э(9) является то, что они являются результатом процессов, которые структурированы хотя бы частично.

Типичными характеристиками досье являются следующие:

они многочисленны; они структурированы или частично структурированы; они используются и управляются посредством известного и предопределенного процесса; они должны сохраняться в течение определенного периода времени, в соответствии с законодательными и нормативными актами; у них похожее содержимое и/или структура; у них известна дата открытия э(43) и закрытия э(16); они могут открываться э(43) и закрываться э(16) исполнителями э(10) (специалистами, сотрудниками канцелярий или системами обработки данных) без получения разрешения руководства.

Поскольку досье э(9) часто структурированы, они, как правило, содержат несколько разделов э(66), обычно конфигурированных посредством шаблонов. Они также могут содержать тома э(74). Смотри раздел 3.3 для описания деталей функциональности, все из которых применимы к досье э(9) так же, как и к другим делам э(34).

Управление структурированной деятельностью часто включает другие деловые прикладные системы (например, система обработки информации обращений за лицензией или система отслеживания запросов). Оно также часто зависит от рабочих процессов (как описано в разделе 10.4).

№	Требование	Тест
Роль администратора обязательно должна быть способна конфигурировать СУЭОД э(32) возможностью предоставлять хотя бы одной роли э(62) «исполнителя э(10)» (смотри глоссарий) с указанными функциями, иметь разные разрешения доступа для классов э(11) структурированной деятельности  и классов э(11) неструктурированной деятельности.	Д
Во многих случаях исполнители э(10) будут способны создавать, открывать э(43) и закрывать э(16) досье э(9) в ходе их ежедневной работы, но у них не будет разрешений создавать, открывать э(43) и закрывать э(16) неструктурированные дела э(42). В случае работы с неструктурированными делами э(42), этот уровень полномочий может быть предоставлен только ролями администраторов э(1).
СУЭОД э(32) должна поддерживать опциональный механизм присвоения заголовков делам э(34), конфигурируемым ролью администратора э(1), который включает имена (например, имена людей) и/или даты (например, даты рождения) или уникальные идентификаторы дела э(34), такие как имена дела э(34), извлеченные и автоматически утвержденные из внешних списков.	Д
Метаданные э(40), используемые для автоматического конструирования заголовков дел э(34) (как в э10.5.2), должны являться обязательными метаданными э(40) или при определении механизмов составления заголовков должны быть использованы соответствующие стандарты.  СУЭОД э(32) не должна автоматически обновлять заголовок дела э(40) в случае модификации важных значений метаданных э(40) (например, имен, дат и др.), которые использовались для создания заголовка.	Д
Правила автоматического конструирования заголовков дел э(34) (как в э10.5.2) должны быть конфигурируемы с тем, чтобы быть разными для разных классов э(11).	Д
Три выше обозначенных требования могут быть применимыми для досье э(9). Любой список, используемый для утверждения, может управляться самой СУЭОД э(32) или извне.
Если заголовок дела э(34) был присвоен автоматически с использованием механизма, включающего метаданные э(40), такие как имя человека, дата рождения и пр., возможна ситуация,  когда оригинальные метаданных э(40), на которых базируется заголовок, изменятся. Например, имя человека может измениться, дата рождения могла быть введена неправильно, и др. В этих случаях имя дела э(34), основанное на метаданных э(40), не должно модифицироваться автоматически для отражения изменений, так как заголовок дела э(34) мог быть уже использован (например, в корреспонденции, зарегистрирован в другой системе и др.). Помимо требования о том, что заголовок дела э(34) не должен обновляться автоматически, MoReq2 не предъявляет требований к другим возможным действиям.
Возможны несколько разных действий, включая: Изменение метаданных э(40) игнорируется, и заголовок дела э(34) остается прежним; Роль администратора э(1) предупреждена, о том что метаданные э(40) были изменены, и роль э(62) имеет возможность (по выбору) обновить заголовок дела э(34); Пользователь э(68), вносящий изменение, предупрежден, что метаданные э(40) использованы в заголовке дела э(34), и он должен подтвердить изменение метаданных э(40); Пользователю э(68), вносящему изменение, не разрешается обновлять метаданные э(40) и рекомендуется адресовать предполагаемые изменения роли администратора э(1), который имеет возможность редактировать метаданные э(40).
СУЭОД э(32) обязательно должна разрешать создание досье э(9) любым пользователям э(68) с полномочиями исполнителя э(10).	Д
СУЭОД э(32) обязательно должна разрешать пользователям э(68) доступ к досье э(34) и его открытие э(43) путем введения структурно-специфичного идентификатора дела э(34).	Д
В большинстве досье э(9) идентификатор дела э(34), например, заголовок или номер ссылки, будет предоставляться внешней системой. Для этого интерфейс должен дать возможность пользователю э(38) подтвердить правильность введенного вручную идентификатора. Это отличается от системного идентификатора и кода классификации э(13) и является дополнением к ним.
СУЭОД э(32) обязательно должна поддерживать технологию API (Application Programming Interface – интерфейс прикладного программирования) (или сравнимые возможности) для предоставления возможности интеграции с другими бизнес-приложениями. Это обязательно должно включать как минимум следующее: другие бизнес-приложения для создания, открытия э(43) и закрытия э(16) досье э(9) СУЭОД э(32); другие бизнес-приложения для формирования заголовка досье э(9) СУЭОД э(32); код классификации э(13) вновь созданного досье э(9) для передачи другому бизнес-приложению; другое бизнес-приложение для передачи официальных документов э(52) для провозглашения (захвата э(8)) в досье э(9) СУЭОД э(32); другое бизнес-приложение для применения порядка хранения, отбора и передачи э(61) к существующему закрытому э(17) делу э(31); устранение ошибок в случае, если любая из систем инициирует действия, которые признаются недействительными другой системой.	В
В этих случаях, СУЭОД э(32) не должна делать различий между действиями бизнес-приложения и действиями обычного пользователя э(68).
MoReq2 не указывает природу устранения ошибок. Однако, возможные действия устанавливаются в двух следующих требованиях.
СУЭОД э(32) обязательно должна при получении очевидно некорректного запроса из внешнего бизнес-приложения: не завершать любое некорректное действие; не приводить к сбою программного обеспечения ни в СУЭОД э(32), ни во внешнем приложении.	Д
СУЭОД э(32) должна при получении очевидно некорректного запроса из внешнего бизнес-приложения предупреждать уполномоченного пользователя э(6) для принятия корректирующих действий.	Д
Когда СУЭОД э(32) взаимодействует с другим бизнес-приложением,  роль администратора э(1) обязательно должна иметь возможность ограничивать действия другого приложения для одного или более указанных классов э(11) в схеме классификации э(14) СУЭОД э(32).	Д
Другими словами, не должно быть возможным, другому приложению выполнять любые действия, влияющие на классы э(11), дела э(34) или официальные документы э(34) за пределами класса(ов) э(11) для досье э(9).
Если СУЭОД э(32) взаимодействует с другими бизнес-приложениями, должно быть возможным для пользователя э(68) легко переключаться между связанными делами э(34) в обоих приложениях.	Н
Другими словами, пользователь э(68), который использовал возможности другого бизнес-приложения для определения местонахождения или идентификации ситуации или досье э(9) (например, используя функции приложения поиска почтового адреса для идентификации определенной ситуации), обязательно должен иметь возможность легко открыть э(43) это досье э(9) в СУЭОД э(32), без необходимости повторного ввода идентификатора досье э(9). Похожим образом пользователь э(68), который открыл э(43) дело э(9) в СУЭОД э(32) (просматривая схему классификации э(14), ведя поиск или любым другим способом), должен иметь возможность переходить к соответствующей структурированной информации в другом бизнес-приложении таким же образом.
Если СУЭОД э(32) позволяет другому бизнес-приложению создавать новое досье э(9), она обязательно должна быть в состоянии получать соответствующие метаданные э(40) дела э(34) из другого приложения.	Д
СУЭОД э(32) обязательно должна разрешать конфигурировать досье э(9) с элементами метаданных э(40), которые являются специфическими для досье э(9).	Д
Например, досье э(9) может требоваться один или более элементов метаданных э(40) для обозначение «статуса» или «очереди задания».
СУЭОД э(32) обязательно должна разрешать пользователям э(68) извлекать, провозглашать официальные документы э(52) и производить все другие допустимые действия с досье э(9), используя идентификатор досье э(9) вместо кода классификации э(13).	В
Большинство досье э(9) идентифицируются уникальным идентификатором досье, таким как номер счета или номер жалобы. Пользователи э(68) должны быть способны работать с этими делами э(34), просто указывая этот идентификатор, и без необходимости использовать код классификации э(13) СУЭОД э(32) (хотя использование идентификатора остается возможным).
Если СУЭОД э(32) получает официальные документы э(52) структурированного содержания из другого бизнес-приложения, она должна быть способна извлекать метаданные э(40) из официальных документов э(52) автоматически.	Д
Когда СУЭОД э(32) получает официальные документы э(52) структурированного содержания из другого бизнес-приложения, одна должна быть способна использовать извлеченные метаданные э(40) для провозглашения (захвата э(52)) официальных документов э(52) в соответствующее дело э(34).	Д
Например, если СУЭОД э(32) получает электронные э(29) формы заявки из приложения для обработки заявок на льготы, она должна быть способна извлекать идентификатор заявок и тип формы, затем использовать их для классификации форм в правильное досье э(9) (используя идентификатор заявок) и подраздел (используя тип формы).
СУЭОД э(32) обязательно должна гарантировать, что все действия, примененные к любому классу э(11), делу э(34) или официальному документу э(52) уполномоченным пользователем э(6) или другим бизнес-приложением, зарегистрированы в протоколе аудита э(4).	Д
СУЭОД э(32) обязательно должна быть способна выдавать отчеты обо всех действиях, совершаемых уполномоченным пользователем э(6) или другой бизнес-системой с любым указанным делом(ами) э(34).	Д
СУЭОД э(32) обязательно должна выдавать отчеты для ролей администраторов э(1), показывая как минимум: количество официальных документов э(52), провозглашенных (захваченных) в досье э(9) автоматически из других бизнес-систем за определенный период времени: количество официальных документов э(52), провозглашенных (захваченных) в досье э(9) вручную за определенный период времени; количество досье э(9), открытых э(43) и закрытых э(17) автоматически другими бизнес-системами за определенный период времени; количество досье э(9), открытых э(43) и закрытых э(17) вручную за определенный период времени.	Д

Интеграция с системами управления содержимым

Этот раздел устанавливает требования для интеграции «Систем управления содержимым / Content Management Systems» (СУС / CMS) э(18) в СУЭОД э(32). Современные системы управления содержимым э(18) включают в себя большинство или все функции ЭХД э(28) (см. раздел 10.3). В данном разделе рассматриваются только функциональные требования к СУЭОД э(32), специфические для СУС э(18), – он не описывает функциональные требования к СУС э(18) или ЭХД э(28) и не включает достаточное число функций для выполнения СУЭОД э(32) задач, которые обычно характерны для СУС э(18).