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

ЭХД э(28) нередко являются частью реализации более широкой системы и содержат инструменты организации совместной работы, позволяющие нескольким пользователям э(68) участвовать в составлении проекта (черновика) документа э(26).

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

Следующая таблица показывает наиболее типичные различия между ЭХД э(28) и СУЭОД э(32).

ЭХД э(28)…	СУЭОД э(32)…
позволяет изменять документы э(26);	предохраняет официальные документы э(52) от изменения;
позволяет существование документа э(26) в нескольких версиях э(72);	позволяет существование единственной последней версии э(72) официального документа э(52);
может позволять их владельцам э(44) удалять документы э(26);	предохраняет официальные документы э(52) от удаления, кроме удаления при определенных строго контролируемых обстоятельствах;
может включать  некоторые функции управления сохранностью;	обязательно должна включать строгие механизмы управления сохранностью;
может включать структуру хранения документов э(26), которая может находиться под управлением пользователей э(68);	обязательно должна включать строгую структуру размещения официальных документов э(52) (схему классификации э(14)), которая обслуживается ролью администратора э(1);
имеет своей основной целью поддержать повседневное использование документов э(26) в текущей деятельности.	может поддерживать повседневную работу, но основная цель –  обеспечить безопасную сохранность деловых официальных документов э(52).

Далее в этом разделе приведены основные требования, которые должны приниматься во внимание при создании интегрированного СУЭОД э(32) / ЭХД э(28) решения. Эти требования применимы только когда ЭХД э(28)  является составной частью СУЭОД э(32). Центральной характеристикой этих требований является положение о том, что простые документы э(26) могут храниться (т. е. быть классифицированными э(12)) в тех же самых классах э(11) и делах э(34), что и официальные документы э(52), хотя это является опциональным (т. е. на усмотрение организации). Это позволяет проектам (черновикам) документов э(26) быть помещенными в те же агрегации э(3), что и окончательные их версии э(72), которые и являются официальными документами э(52).

Следует заметить, что слово «документ э(26)» используется здесь специально, чтобы описать информацию или объект, который не был провозглашен как официальный документ э(32) в СУЭОД э(32).

№	Требование	Тест
СУЭОД э(32) должна быть способна управлять электронными документами э(30) и электронными официальными документами э(31) в контексте одной классификационной схемы э(14), используя одни и те же механизмы контроля доступа.	Д
Цель данного требования – дать возможность пользователям э(68) сохранять документы э(26), являющихся проектами (черновиками), в тех агрегациях э(3), в которые возможно будут помещены соответствующие официальные документы э(52). Это требование является опциональным.
Там где СУЭОД э(32) управляет как (неофициальными) документами э(26), так и официальными документами э(52) в одной и той же схеме классификации э(14), обязательно должно быть четко указано, какие из них являются (неофициальными) документами э(26), а какие официальными документами э(52).	Д
MoReq2 не указывает, как это осуществляется.
Там где СУЭОД э(32) управляет как (неофициальными) документами э(26), так и официальными документами э(52) в одной и той же схеме классификации э(14), она обязательно должна разрешать ролям пользователей э(71) выполнять следующие действия по отношению к каждому указанному классу э(11) или делу э(34): провозглашать все (неофициальные) документы э(26) как официальнее документы э(52); удалять все (неофициальные) документы э(26), оставляя только официальные документы э(52); удалять все (неофициальные) документы э(26), превысивших установленный срок хранения.	Д
Там, где СУЭОД э(32) управляет как (неофициальными) документами э(26), так и официальными документами э(52) в одной и той же схеме классификации э(14), она обязательно должна уведомлять роль администратора э(1) о существовании (неофициальных) документов э(26) внутри класса э(11) или дела э(34), которые экспортируются э(33), и обеспечить возможность выбора: обеспечить удаление (неофициальных) документов э(26); провозгласить их как официальные документы э(52); экспортировать э(33) их вместе с официальными документами э(52)	Д
Там где ЭХД э(28) является частью СУЭОД э(32) или тесно интегрирована в нее, ЭХД э(28) обязательно должна быть способна автоматически передавать (неофициальные) электронные документы э(30), появляющиеся в ходе делового процесса, в СУЭОД э(32) для автоматического их  захвата э(8) в качестве официальных документов э(52).	В
Это особенно актуально в сценариях структурированной деятельности – смотри также раздел 10.5.
СУЭОД э(32) обязательно должна разрешать пользователям э(68):  захватывать э(8) (неофициальный) электронный документ э(30) и провозглашать его в качестве официального документа э(52) одним действием; или захватывать э(8) (неофициальный) электронный документ э(30), сохранять его и завершать процесс захвата э(8) провозглашением его в качестве официального документа э(52) через некоторый срок.	Д
СУЭОД э(32) обязательно должна быть способна копировать содержание официального электронного документа э(31) с целью создания нового отдельного (неофициального) электронного документа э(30) без автоматического создания нового официального документа э(52), гарантируя при этом, полную сохранность подлинного официального документа э(52).	Д
Например, пользователь э(68) может копировать официальный документ э(52), чтобы отправить копию получателю, который не является пользователем э(68) СУЭОД э(32). Эта копия может провозглашаться или не провозглашаться в качестве нового официального документа э(52) в зависимости от контекста.
СУЭОД э(32) обязательно должна разрешать ролям пользователей э(71) (смотри э10.3.11) выдавать (из системы для внесения изменений) документ э(26) при наличии у них  надлежащих прав доступа.	Д
СУЭОД э(32) обязательно должна разрешать ролям пользователей э(71) возвращать (в систему после внесения изменений) любой документ э(26), который они ранее выдали, предоставляя пользователю э(68) выбор возврата его как новой версии э(72) или нет (см. э10.3.20).	Д
СУЭОД э(32) должна разрешать пользователю э(68), который возвращает (в систему после внесения изменений) документ э(26), вводить, по усмотрению, текстовое объяснение изменений, которые были в него внесены за период с момента его выдачи.	Д
Когда пользователь э(68) выдает (из системы для внесения изменений) документ э(26), СУЭОД э(32) обязательно должна блокировать для других пользователей э(68) возможность его выдачи и изменений (в соответствии с э10.3.13).	Д
Когда документ э(26) выдан (из системы для внесения изменений), только пользователь э(68), который получил его (на свой локальный компьютер), может его редактировать.
Это относится только к неофициальным документам э(26). По определению, СУЭОД э(32) никогда не должна разрешать изменение официального документа э(52) и выдачу (из системы для внесения изменений) официального документа э(52).
Если документ э(26) выдан (из системы для внесения изменений), а любой другой пользователь э(68) пытается его получить (на свой персональный компьютер для внесения изменений), СУЭОД э(32) обязательно должна запретить повторную выдачу, при этом обязательно должна информировать пользователя э(68) о том, что документ э(28) выдан, и обязательно должна либо: показать, какому пользователю э(68) выдан; или не указывать, какому пользователю э(68) выдан. в соответствии с опцией, указанной на этапе конфигурации э(20).	Д
СУЭОД э(32) обязательно должна позволять роли администратора э(1) отменять выдачу (из системы для внесения изменений) документа э(26).	Д
Это делается с целью разрешения ситуаций, когда пользователь э(68), который получил (на свой персональный компьютер для изменений) документ э(26), не может возвратить (в систему после изменений) документ э(26). Такая ситуация может возникнуть по нескольким причинам, например: пользователь э(68) получил его в персональный компьютер, который сломался или был украден; извлеченный документ э(26) разрушился; пользователь э(68) забыл возвратить документ э(26) (в систему после внесения изменений) до ухода в отпуск.
Пользователь э(68) никогда не должен иметь возможности возвратить (в систему после внесения изменений) версию э(72) того же документа э(26), в случае если его выдача (из системы) была отменена (как в э10.3.13).	Д
Если производится попытка закрыть э(16) агрегацию э(3) в СУЭОД э(32), которая включает извлеченный (из системы для внесения изменений) документ э(26), она обязательно должна уведомлять об этом роль администратора э(1) как об исключении.	Д
Пользователи э(68) должны быть способны захватывать э(8) документ э(26) из ЭХД э(28).	Д
Пользователи э(68) обязательно должны быть способны легко перемещаться в СУЭОД э(32) и из нее для провозглашения неофициального документа э(26), полученного непосредственно из ЭХД э(28), в качестве официального документа э(52).	Н
Это требование особенно важно там, где ЭХД э(28) и СУЭОД э(32) используются в качестве основной офисной среды.
При существовании нескольких версий э(72) документа э(26), СУЭОД э(32) обязательно должна быть способна захватывать э(8) (неофициальный) документ э(26) как официальный документ э(52)  любым из следующих способов, один из которых должен быть установлен как значение по умолчанию на этапе конфигурации э(20), пользователь э(68) должен иметь возможность выбрать во время захвата э(8): самую последнюю версию э(72); одну версию э(72), выбранную пользователем э(68); все сохраненные версии, сохраняемые как единый документ э(52); все сохраненные версии э(72), сохраняемые как разные, но связанные с официальными документами э(52).	Д
СУЭОД э(32) обязательно должна поддерживать несколько версий э(72) для каждого документа э(26), и они обязательно должны быть ясно видны во время поиска или извлечения документа э(26).	Д
СУЭОД э(32) обязательно должна автоматически увеличивать номер версии э(72) документа э(52), когда документ э(26) возвращается (в систему после внесения изменений) в новой версии э(72).	Д
СУЭОД э(32) должна разрешать позволять определять схему нумерации версий э(72) на этапе конфигурации э(20), позволяя как минимум следующие опции: простая последовательная нумерация версий э(72), как числа 1, 2, 3; главная и второстепенная нумерация версий э(72), как числа в паре x. y., где “х” является главной версией э(72), а “у” второстепенной версией э(72), и пользователь э(72) решает, какую из версий э(72) приращивать; и если приращивается главная версия э(72), второстепенной версии э(72) автоматически будет присвоен «0».	Д
Допустимо применение и других схем нумерации.
СУЭОД э(32) обязательно должна разрешать роли администратора э(1), на этапе конфигурирования э(20) или позже, настраивать хранилище версий э(72) документов э(26) на уровне класса э(11) и дела э(34) внутри схемы классификации э(14), позволяя как минимум следующие опции по умолчанию для каждого класса э(11) и дела э(34): все версии э(72) всех документов э(28) хранятся в классе э(11) или деле э(34); только самая последняя версия э(72) (с возможностью для роли администратора э(1) указывать главные и второстепенные версии э(72)) каждого документа э(26) хранится в классе э(11) или деле э(34); несколько версий э(72) каждого документа э(26) хранятся в классе э(11) или деле э(34), их количество определяется ролью администратора э(1).	Д
Это делается для обеспечения возможности использования контроля версий э(72) в случае, если потребуется проследить историю создания документа э(26). В тех случаях, когда эта история не требуется, число хранимых версий э(72) и, следовательно, требуемая емкость хранилища могут быть сокращены.
СУЭОД э(32) должна позволять пользователям э(68), которые хранят документ э(26), превышать определенное по умолчанию число сохраняемых версий э(72) этого документа э(26) (как определено в э10.3.22).	Д
СУЭОД э(32) обязательно должна разрешать пользователю э(68) вводить значения метаданных э(40) для официального документа э(52) во время захвата э(8).	Д
Например, время создания и автор документа э(26), а также метаданные э(40), которые могут быть идентифицированы из структурированных полей документа э(26), если они представлены, такие как дата и тема.
СУЭОД э(32) обязательно должна гарантировать, что любые захваченные э(8) метаданные э(40) управляются в соответствии с «Моделью метаданных MoReq2» (см. приложение 9).	Д
СУЭОД э(32) должна разрешать уполномоченному пользователю э(6) проецировать элементы метаданных э(40) ЭХД э(28) в соответствующие поля метаданных э(40) СУЭОД э(32).	Н
В случае возникновения какого-либо конфликта в метаданных э(40) между СУЭОД э(32) и системой, генерирующей документы э(26), СУЭОД э(32) обязательно должна предупредить пользователя э(68).	Д
Такое может произойти в случае, когда у СУЭОД э(32) отсутствует контроль над элементами метаданных э(40) документа э(26).
СУЭОД э(32) должна быть способна к интеграции с новыми версиями ЭХД или иными системами, если они внедряются в организации.	Н
MoReq2 не указывает, как это достигается. Организациям следует принять во внимание необходимость рассмотрения этих возможностей более детально.
СУЭОД э(32) обязательно должна быть способна  контролировать версии э(72), а именно, управлять различными версиями э(72) электронного документа э(30) как единым объектом.	Д
Это поддерживает процесс подготовки проектов (черновиков) документа э(26) и организует коллективную работу.
СУЭОД э(32) должна быть способна ограничивать пользователей э(68) предоставляя просмотр: только последней версии э(72) документа э(26); избранных версий э(72) документа э(26); всех версий э(72) документа э(26); версий э(72), которые были захвачены э(8) или которые были зарегистрированы э(56) как официальные документы э(52); выбор должен делаться ролью администратора э(1) на этапе конфигурации э(20) или позже.	Д
СУЭОД э(32) должна разрешать пользователям э(68) иметь «персональное» рабочее пространство для документов э(26).	Д
Это рабочее пространство может применяться пользователями э(68)  для хранения персональных документов э(26), которые не предполагается захватывать э(8) в качестве официальных документов э(52), например, ранних проектов (черновиков), не предназначенных для корпоративного доступа, или других документов э(26). Использование этого рабочего пространства должно быть опциональным (а именно, СУЭОД э(32) может быть конфигурирована без предоставления такой возможности).
Если СУЭОД э(32) включает персональное рабочее пространство, то роль администратора э(1) обязательно должна иметь возможность устанавливать лимит размера персонального рабочего пространства для каждого конкретного пользователя э(68).	Д
Если СУЭОД э(32) включает персональное рабочее пространство, она должна разрешать доступ  к нему только его владельцу э(44).	Д

Управление рабочими процессами

Международная организация “Workflow Management Coalition” (WfMC) – разработчик стандартов в сфере управления рабочими процессами – определяет термин «рабочий процесс / workflow» как «автоматизированное выполнение бизнес-процесса, полное или частичное, во время которого документы э(26), информация или задания передаются от одного участника другому для выполнения действия согласно установленным процедурам». В этом определении под «участником» может подразумеваться пользователь э(68), группа э(37) (например, рабочая группа, проектная команда) или программное приложение.