Внедрение системы внутреннего электронного документооборота (СЭД): различия между версиями
Нет описания правки |
Нет описания правки |
||
| Строка 1: | Строка 1: | ||
== 1 Введение == | |||
Внедрение системы электронного документооборота – это мероприятие, в большей степени требующее организационной и методологической подготовки, по сравнению с ИТ составляющей. При этом подготовка достаточно проста и может быть осуществлена без специальных навыков. При этом, обычно, этот этап составляет значительную часть стоимости проекта, если внедрение ведет подрядчик, поскольку требуете времени на погружение в специфику организации. | |||
Руководствуясь инструкциями и шаблонами, приведенными в данном документе, можно подготовить техническое задание, на основании которого настройка любой системы документооборота даже с участием подрядчика может быть проведена быстро и недорого. | |||
== 2 Описание объекта автоматизации == | |||
Описание объекта желательно формировать даже если внедрение проводится самостоятельно. Эти материалы потребуются ИТ специалистам для расчета требований к инфраструктуре и для настройки справочников. | |||
=== 2.1 Описание автоматизируемого объекта (предприятия). === | |||
* Структура предприятия – одиночное, предприятие с филиалами или холдинг. Схема предприятия. | |||
# | * Количество пользователей. Рассчитывайте исходя из функционала, который планируете внедрять. Обычно, наибольшее количество пользователей использует функционал поручений. | ||
* Организационная структура. | |||
=== 2.2 Перечень подлежащих переносу в ЭДО документов. === | |||
Укажите все документы, которые вы планируете переводить в электронную форму. | |||
Обычно формально этот список выражается в Реестр объектов электронного документооборота. | |||
Обратите внимание, что в некоторых случаях, можно не просто перевести документ в электронную форму, а и вообще от него отказаться, просто наладив прямую интеграцию информационных систем. Поэтому при составлении этого реестра обязательно задайте себе вопрос, а действительно ли нужен конкретный документ и зафиксируйте ответ на него в документации. | |||
== 3 Определение владельцев маршрутов согласования == | |||
Целесообразно определять владельцев маршрутов согласования – сотрудников, которые отвечают за разработку и согласование маршрутов. | |||
Обычно это аналитики, но в случае их отсутствия в компании может быть назначен и другой специалист. | |||
Задачи владельца маршрута: | |||
1. Сформировать полное и непротиворечивое описание маршрута (руководствуясь, например, приведенными в настоящем документе рекомендациями). | |||
2. Согласовать маршрут с заинтересованными лицами (владельцами процессов, в которых задействован соответствующий документ). | |||
3. Оформить и утвердить распорядительный документ, устанавливающий маршрут в качестве обязательного к исполнению. | |||
4. Убедиться в корректности настройки маршрута документа в автоматизированных системах. | |||
5. Принимать и реагировать на замечания и предложения по совершенствованию маршрута от коллег. | |||
== 4 Жизненный цикл документа == | |||
Понимание жизненного цикла электронного документа (ЭД) — это ключ к выстраиванию оптимальных маршрутов обработки ЭД, то есть к построению эффективного электронного документооборота. | |||
Жизненный цикл электронного документа (ЖЦЭД), так же, как и традиционного, зависит от принадлежности к конкретному документопотоку (поступающему (ПД), внутреннему (ВД) и исходящему (ИД)). Кроме того, на жизненный цикл определяется и типом документа. | |||
При этом не стоит путать жизненный цикл документа с маршрутом согласования. | |||
== 5 Ролевая модель документа == | |||
В разные моменты времени и для разных документов разные сотрудники могут выполнять разные роли. Так, один и тот же человек может выполнять, например, для одного письма роль инициатора письма, для другого - согласующего, для третьего - исполнителя. | |||
Поэтому целесообразно оперировать именно ролями. Для каждого документа определите свой набор ролей. В некоторых случаях, есть возможность объединить некоторые виды документов под один процесс. | |||
Например, наиболее часто используемые роли: | |||
· Автор | |||
· Инициатор | |||
· Согласующий | |||
· Канцелярия | |||
· Получатель | |||
· Исполнитель | |||
Ролевая модель оформляется в виде списка, например такого (для простой служебной записки): | |||
{| class="wikitable" | |||
|'''Наименование роли''' | |||
|'''Назначение роли''' | |||
|- | |||
|Автор | |||
|Сотрудник, непосредственно формирующий служебную записку. | |||
|- | |||
|Инициатор | |||
|Сотрудник, инициировавший написание служебной записки | |||
|- | |||
|Подписант | |||
|Сотрудник, имеющий полномочия направлять служебную записку | |||
|- | |||
|Получатель | |||
|Адресат служебной записки | |||
|- | |||
|Исполнитель | |||
|Исполнитель, которому получатель расписывает служебную записку на исполнение. | |||
|} | |||
== 6 Маршруты согласования == | |||
Маршрут согласования определяет последовательность участия участников документооборота в процессах жизненного цикла документа, а также дополнительные характеристики документооборота, в том числе максимальную длительность этапов жизненного цикла и эскалации. | |||
Изобразить маршрут согласования можно в графическом виде и в табличном. | |||
=== 6.1 Графическое описание маршрута согласования. === | |||
Графическое обозначение маршрута согласования можно оформить в любой пригодной нотации. Наиболее полно можно это сделать с помощью нотации BPMN, но можно воспользоваться и более простыми вариантами. Например, изображенным на следующей диаграмме: | |||
В данном случае, прямоугольники обозначают состояние (статус) документа, стрелки – доступные для пользователя действия (решения). | |||
Прямоугольники (состояния) размещаются в полосах, обозначающих участников согласования. | |||
=== 6.2 Табличное описание маршрута согласования === | |||
Ниже приведены примеры описания маршрутов табличным видом. | |||
''Пример 1:'' | |||
{| class="wikitable" | |||
|'''№ этапа''' | |||
|'''Роль''' | |||
|'''Доступные решения''' | |||
|'''Параллельное согласование''' | |||
|'''Цель согласования''' | |||
|'''Основание для принятия решения/примечание''' | |||
|'''В случае отклонения возврат на этап''' | |||
|'''Инструмент согласования''' | |||
|'''Максимальная длительность этапа''' | |||
|- | |||
|1 | |||
|Инициатор | |||
|Отправить на согласование | |||
| | |||
| | |||
| | |||
| | |||
|СЭД | |||
| | |||
|- | |||
|2 | |||
|Работник склада | |||
|Согласовать, изменить способ обеспечения | |||
| | |||
|Подтверждение наличия на складе | |||
|В случае наличия запрошенного материала на складе выбрать способ обеспечения перемещением со склада | |||
|Не предусмотрено | |||
|СЭД | |||
|1 час | |||
|- | |||
|3 | |||
|Директор проекта | |||
|Согласовать, отклонить, изменить количество | |||
| | |||
|Подтверждение потребности | |||
|При отсутствии необходимости – отклонить или изменить количество. | |||
|1 | |||
|СЭД | |||
|8 часов | |||
|- | |||
|4 | |||
|Работник службы снабжения | |||
|Согласовать, отклонить, изменить способ обеспечения | |||
| | |||
|Подтвердить отсутствие возможности перемещения с других складов | |||
|При наличии на других складах филиала или в других филиала рассмотреть целесообразность перемещения. | |||
|Не предусмотрено | |||
|СЭД | |||
|4 часа | |||
|} | |||
В этом примере предполагается, что согласование идет строго последовательно. | |||
''Пример 2:'' | |||
{| class="wikitable" | |||
|'''№ этапа''' | |||
|'''Роль''' | |||
|'''Доступные решения''' | |||
|'''Параллельное согласование''' | |||
|'''Цель согласования''' | |||
|'''Основание для принятия решения/примечание''' | |||
|'''В случае отклонения возврат на этап''' | |||
|'''Инструмент согласования''' | |||
|'''Максимальная длительность этапа''' | |||
|- | |||
|1 | |||
|Инициатор | |||
|Отправить на согласование | |||
| | |||
| | |||
| | |||
| | |||
|ERP | |||
| | |||
|- | |||
|2.1 | |||
|Работник службы снабжения | |||
|Согласовать, отклонить | |||
| rowspan="3" |И (должен согласовать каждый) | |||
|Подтвердить возможность поставки в запрошенные сроки | |||
| | |||
|1 | |||
|ERP | |||
| | |||
|- | |||
|2.2 | |||
|Работник планово-экономического управления | |||
|Согласовать, отклонить | |||
|Подтвердить наличие бюджета | |||
| | |||
|1 | |||
|ERP | |||
| | |||
|- | |||
|2.3 | |||
|Работник ответственного сервиса | |||
|Согласовать, отклонить | |||
|Подтвердить целесообразность и состав заявки | |||
| | |||
|1 | |||
|ERP | |||
| | |||
|- | |||
|3.1 | |||
|ЗДФ по направлению | |||
|Согласовать, отклонить | |||
| rowspan="2" |ИЛИ (достаточно согласования одного из указанных ЗДФ) | |||
| rowspan="2" |Подтвердить отсутствие возможности перемещения с другого объекта | |||
| | |||
|1 | |||
|КИС-1С и | |||
Виза на бумажном документе | |||
| | |||
|- | |||
|3.2 | |||
|ЗДФ по бурению | |||
|Согласовать, отклонить | |||
| | |||
|1 | |||
|КИС-1С и | |||
Виза на бумажном документе | |||
| | |||
|- | |||
|4 | |||
|Генеральный директор | |||
|Утвердить. Отклонить | |||
| | |||
|Подтвердить необходимость закупки в обход процедур | |||
|Только для заявок по управленческому решению | |||
|Не предусмотрено | |||
|Виза на бумажном документе | |||
| | |||
|} | |||
В этом примере согласование может идти параллельно. | |||
== 7 Доступ к документу (статусно-ролевая матрица) == | |||
Доступ для разных ролей на разных этапах жизненного цикла документа может быть разным и это не всегда модно описать маршрутами. Эти особенности доступа описываются Статусно-ролевой матрицей. | |||
Описание задания на разграничение доступа может выглядеть следующим образом (для входящего документа). | |||
· Ч – чтение карточки и файлов. | |||
· К – редактирование карточки. | |||
· Д – возможность добавления файлов. | |||
· Д(К) – возможность создания копии файла. | |||
· Р – возможность редактирования файлов (создание новой версии на основе предыдущей). | |||
· У – возможность удаления файлов. | |||
Статусно-ролевая матрица выглядит следующим образом: | |||
{| class="wikitable" | |||
| ''' Роль''' | |||
'''Состояние''' | |||
|'''Регистратор''' | |||
|'''Получатель''' | |||
|'''Исполнитель''' | |||
|'''Секретариат''' | |||
|'''Юристы''' | |||
|'''Руководство''' | |||
|- | |||
|Зарегистрировано | |||
|ЧКДРУ | |||
| | |||
| | |||
|Ч | |||
|Ч | |||
|Ч | |||
|- | |||
|На рассмотрении | |||
|ЧКД | |||
|ЧД(К) | |||
|ЧД(К) | |||
|ЧКД | |||
|Ч | |||
|Ч | |||
|- | |||
|Рассмотрено | |||
|ЧК | |||
|Ч | |||
|Ч | |||
|ЧК | |||
|Ч | |||
|Ч | |||
|} | |||
== 8 Состав карточки документа (таблица атрибутов) == | |||
Разные документы могут (и должны) иметь разный набор данных, описывающих документ. Для описания этого набора удобно пользоваться таблицей атрибутов. | |||
В ней указывается какие поля важны для учета, отбора, сортировки и поиска документов. | |||
Такие поля дополнительно заполняются в карточке документа, даже если эта информация и так имеется в тексте документа. | |||
'''Пример таблицы атрибутов для поручения:''' | |||
{| class="wikitable" | |||
|'''Название поля''' | |||
|'''Тип заполняемых данных''' | |||
|'''Настройки''' | |||
|'''Значение по умолчанию''' | |||
|'''Описание поля''' | |||
|- | |||
|Дата создания | |||
|Дата/время | |||
|Только для чтения | |||
|Текущая дата/время | |||
|Дата/время создания поручения | |||
|- | |||
|Вид документа | |||
|Вид документа | |||
|Только для чтения, | |||
заполняется автоматически | |||
|Поручение | |||
| | |||
|- | |||
|Тема | |||
|Строка | |||
|обязательное для заполнения | |||
| | |||
|Указывается тема поручения | |||
|- | |||
|Номер | |||
|значение из автоматического нумератора, строка | |||
|Только для чтения, | |||
заполняется автоматически | |||
| | |||
| | |||
|- | |||
|Срок исполнения | |||
|Дата/время | |||
|обязательное для заполнения | |||
|1 рабочий день для типа поручения «Для принятия мер» и 15 календарных дней для других типов поручений | |||
|Срок может быть изменен Автором по запросу Исполнителя | |||
|- | |||
|Автор | |||
|сотрудник из справочника сотрудников | |||
|Только для чтения, | |||
заполняется автоматически | |||
|Сотрудник, создавший поручение | |||
| | |||
|- | |||
|Статус | |||
|состояние документа | |||
|Только для чтения | |||
|Проект | |||
|Должно изменяться автоматически в процессе обработки поручения | |||
|- | |||
|Текст поручения | |||
|Строка | |||
|обязательное для заполнения | |||
| | |||
| | |||
|- | |||
|Исполнитель | |||
|сотрудник из справочника сотрудников | |||
|обязательное для заполнения | |||
| | |||
| | |||
|- | |||
|Соисполнители | |||
|сотрудник из справочника сотрудников | |||
Коллекция | |||
| | |||
| | |||
|Сотрудники, которые могут привлекаться Исполнителем для исполнения поручения (временные подчиненные в рамках конкретного поручения) | |||
|- | |||
|Наблюдатели | |||
|сотрудник из справочника сотрудников | |||
Коллекция | |||
| | |||
| | |||
|Сотрудники получающие уведомления о выданном поручении. В исполнении не участвуют. Имеют доступ к карточке и файлам на чтение. | |||
|- | |||
|Контролёр | |||
|сотрудник из справочника сотрудников | |||
| | |||
| | |||
|Подтверждает исполнение поручения | |||
|} | |||
== 9 Дополнительные требования == | |||
Иногда существуют такие требования к документу, которые не могут быть зафиксированы в ранее описанных форматах. | |||
В этом случае из можно описать отдельно в произвольной форме. | |||
== 10 Как формировать требования к системе: == | |||
Для подготовки описания документа к автоматизации нужно сформировать следующие документы: | |||
1. Жизненный цикл документа (диаграммой). | |||
2. Ролевая модель документа. | |||
3. Маршрут документа (диаграммой или таблицей). | |||
4. Статусно-ролевая матрица. | |||
5. Таблица атрибутов. | |||
6. Дополнительные требования. | |||
# | |||
[[Категория:Цифровизация]] | [[Категория:Цифровизация]] | ||
Версия от 19:18, 3 сентября 2025
1 Введение
Внедрение системы электронного документооборота – это мероприятие, в большей степени требующее организационной и методологической подготовки, по сравнению с ИТ составляющей. При этом подготовка достаточно проста и может быть осуществлена без специальных навыков. При этом, обычно, этот этап составляет значительную часть стоимости проекта, если внедрение ведет подрядчик, поскольку требуете времени на погружение в специфику организации.
Руководствуясь инструкциями и шаблонами, приведенными в данном документе, можно подготовить техническое задание, на основании которого настройка любой системы документооборота даже с участием подрядчика может быть проведена быстро и недорого.
2 Описание объекта автоматизации
Описание объекта желательно формировать даже если внедрение проводится самостоятельно. Эти материалы потребуются ИТ специалистам для расчета требований к инфраструктуре и для настройки справочников.
2.1 Описание автоматизируемого объекта (предприятия).
- Структура предприятия – одиночное, предприятие с филиалами или холдинг. Схема предприятия.
- Количество пользователей. Рассчитывайте исходя из функционала, который планируете внедрять. Обычно, наибольшее количество пользователей использует функционал поручений.
- Организационная структура.
2.2 Перечень подлежащих переносу в ЭДО документов.
Укажите все документы, которые вы планируете переводить в электронную форму.
Обычно формально этот список выражается в Реестр объектов электронного документооборота.
Обратите внимание, что в некоторых случаях, можно не просто перевести документ в электронную форму, а и вообще от него отказаться, просто наладив прямую интеграцию информационных систем. Поэтому при составлении этого реестра обязательно задайте себе вопрос, а действительно ли нужен конкретный документ и зафиксируйте ответ на него в документации.
3 Определение владельцев маршрутов согласования
Целесообразно определять владельцев маршрутов согласования – сотрудников, которые отвечают за разработку и согласование маршрутов.
Обычно это аналитики, но в случае их отсутствия в компании может быть назначен и другой специалист.
Задачи владельца маршрута:
1. Сформировать полное и непротиворечивое описание маршрута (руководствуясь, например, приведенными в настоящем документе рекомендациями).
2. Согласовать маршрут с заинтересованными лицами (владельцами процессов, в которых задействован соответствующий документ).
3. Оформить и утвердить распорядительный документ, устанавливающий маршрут в качестве обязательного к исполнению.
4. Убедиться в корректности настройки маршрута документа в автоматизированных системах.
5. Принимать и реагировать на замечания и предложения по совершенствованию маршрута от коллег.
4 Жизненный цикл документа
Понимание жизненного цикла электронного документа (ЭД) — это ключ к выстраиванию оптимальных маршрутов обработки ЭД, то есть к построению эффективного электронного документооборота.
Жизненный цикл электронного документа (ЖЦЭД), так же, как и традиционного, зависит от принадлежности к конкретному документопотоку (поступающему (ПД), внутреннему (ВД) и исходящему (ИД)). Кроме того, на жизненный цикл определяется и типом документа.
При этом не стоит путать жизненный цикл документа с маршрутом согласования.
5 Ролевая модель документа
В разные моменты времени и для разных документов разные сотрудники могут выполнять разные роли. Так, один и тот же человек может выполнять, например, для одного письма роль инициатора письма, для другого - согласующего, для третьего - исполнителя.
Поэтому целесообразно оперировать именно ролями. Для каждого документа определите свой набор ролей. В некоторых случаях, есть возможность объединить некоторые виды документов под один процесс.
Например, наиболее часто используемые роли:
· Автор
· Инициатор
· Согласующий
· Канцелярия
· Получатель
· Исполнитель
Ролевая модель оформляется в виде списка, например такого (для простой служебной записки):
| Наименование роли | Назначение роли |
| Автор | Сотрудник, непосредственно формирующий служебную записку. |
| Инициатор | Сотрудник, инициировавший написание служебной записки |
| Подписант | Сотрудник, имеющий полномочия направлять служебную записку |
| Получатель | Адресат служебной записки |
| Исполнитель | Исполнитель, которому получатель расписывает служебную записку на исполнение. |
6 Маршруты согласования
Маршрут согласования определяет последовательность участия участников документооборота в процессах жизненного цикла документа, а также дополнительные характеристики документооборота, в том числе максимальную длительность этапов жизненного цикла и эскалации.
Изобразить маршрут согласования можно в графическом виде и в табличном.
6.1 Графическое описание маршрута согласования.
Графическое обозначение маршрута согласования можно оформить в любой пригодной нотации. Наиболее полно можно это сделать с помощью нотации BPMN, но можно воспользоваться и более простыми вариантами. Например, изображенным на следующей диаграмме:
В данном случае, прямоугольники обозначают состояние (статус) документа, стрелки – доступные для пользователя действия (решения).
Прямоугольники (состояния) размещаются в полосах, обозначающих участников согласования.
6.2 Табличное описание маршрута согласования
Ниже приведены примеры описания маршрутов табличным видом.
Пример 1:
| № этапа | Роль | Доступные решения | Параллельное согласование | Цель согласования | Основание для принятия решения/примечание | В случае отклонения возврат на этап | Инструмент согласования | Максимальная длительность этапа |
| 1 | Инициатор | Отправить на согласование | СЭД | |||||
| 2 | Работник склада | Согласовать, изменить способ обеспечения | Подтверждение наличия на складе | В случае наличия запрошенного материала на складе выбрать способ обеспечения перемещением со склада | Не предусмотрено | СЭД | 1 час | |
| 3 | Директор проекта | Согласовать, отклонить, изменить количество | Подтверждение потребности | При отсутствии необходимости – отклонить или изменить количество. | 1 | СЭД | 8 часов | |
| 4 | Работник службы снабжения | Согласовать, отклонить, изменить способ обеспечения | Подтвердить отсутствие возможности перемещения с других складов | При наличии на других складах филиала или в других филиала рассмотреть целесообразность перемещения. | Не предусмотрено | СЭД | 4 часа |
В этом примере предполагается, что согласование идет строго последовательно.
Пример 2:
| № этапа | Роль | Доступные решения | Параллельное согласование | Цель согласования | Основание для принятия решения/примечание | В случае отклонения возврат на этап | Инструмент согласования | Максимальная длительность этапа |
| 1 | Инициатор | Отправить на согласование | ERP | |||||
| 2.1 | Работник службы снабжения | Согласовать, отклонить | И (должен согласовать каждый) | Подтвердить возможность поставки в запрошенные сроки | 1 | ERP | ||
| 2.2 | Работник планово-экономического управления | Согласовать, отклонить | Подтвердить наличие бюджета | 1 | ERP | |||
| 2.3 | Работник ответственного сервиса | Согласовать, отклонить | Подтвердить целесообразность и состав заявки | 1 | ERP | |||
| 3.1 | ЗДФ по направлению | Согласовать, отклонить | ИЛИ (достаточно согласования одного из указанных ЗДФ) | Подтвердить отсутствие возможности перемещения с другого объекта | 1 | КИС-1С и
Виза на бумажном документе |
||
| 3.2 | ЗДФ по бурению | Согласовать, отклонить | 1 | КИС-1С и
Виза на бумажном документе |
||||
| 4 | Генеральный директор | Утвердить. Отклонить | Подтвердить необходимость закупки в обход процедур | Только для заявок по управленческому решению | Не предусмотрено | Виза на бумажном документе |
В этом примере согласование может идти параллельно.
7 Доступ к документу (статусно-ролевая матрица)
Доступ для разных ролей на разных этапах жизненного цикла документа может быть разным и это не всегда модно описать маршрутами. Эти особенности доступа описываются Статусно-ролевой матрицей.
Описание задания на разграничение доступа может выглядеть следующим образом (для входящего документа).
· Ч – чтение карточки и файлов.
· К – редактирование карточки.
· Д – возможность добавления файлов.
· Д(К) – возможность создания копии файла.
· Р – возможность редактирования файлов (создание новой версии на основе предыдущей).
· У – возможность удаления файлов.
Статусно-ролевая матрица выглядит следующим образом:
| Роль
|
Регистратор | Получатель | Исполнитель | Секретариат | Юристы | Руководство |
| Зарегистрировано | ЧКДРУ | Ч | Ч | Ч | ||
| На рассмотрении | ЧКД | ЧД(К) | ЧД(К) | ЧКД | Ч | Ч |
| Рассмотрено | ЧК | Ч | Ч | ЧК | Ч | Ч |
8 Состав карточки документа (таблица атрибутов)
Разные документы могут (и должны) иметь разный набор данных, описывающих документ. Для описания этого набора удобно пользоваться таблицей атрибутов.
В ней указывается какие поля важны для учета, отбора, сортировки и поиска документов.
Такие поля дополнительно заполняются в карточке документа, даже если эта информация и так имеется в тексте документа.
Пример таблицы атрибутов для поручения:
| Название поля | Тип заполняемых данных | Настройки | Значение по умолчанию | Описание поля |
| Дата создания | Дата/время | Только для чтения | Текущая дата/время | Дата/время создания поручения |
| Вид документа | Вид документа | Только для чтения,
заполняется автоматически |
Поручение | |
| Тема | Строка | обязательное для заполнения | Указывается тема поручения | |
| Номер | значение из автоматического нумератора, строка | Только для чтения,
заполняется автоматически |
||
| Срок исполнения | Дата/время | обязательное для заполнения | 1 рабочий день для типа поручения «Для принятия мер» и 15 календарных дней для других типов поручений | Срок может быть изменен Автором по запросу Исполнителя |
| Автор | сотрудник из справочника сотрудников | Только для чтения,
заполняется автоматически |
Сотрудник, создавший поручение | |
| Статус | состояние документа | Только для чтения | Проект | Должно изменяться автоматически в процессе обработки поручения |
| Текст поручения | Строка | обязательное для заполнения | ||
| Исполнитель | сотрудник из справочника сотрудников | обязательное для заполнения | ||
| Соисполнители | сотрудник из справочника сотрудников
Коллекция |
Сотрудники, которые могут привлекаться Исполнителем для исполнения поручения (временные подчиненные в рамках конкретного поручения) | ||
| Наблюдатели | сотрудник из справочника сотрудников
Коллекция |
Сотрудники получающие уведомления о выданном поручении. В исполнении не участвуют. Имеют доступ к карточке и файлам на чтение. | ||
| Контролёр | сотрудник из справочника сотрудников | Подтверждает исполнение поручения |
9 Дополнительные требования
Иногда существуют такие требования к документу, которые не могут быть зафиксированы в ранее описанных форматах.
В этом случае из можно описать отдельно в произвольной форме.
10 Как формировать требования к системе:
Для подготовки описания документа к автоматизации нужно сформировать следующие документы:
1. Жизненный цикл документа (диаграммой).
2. Ролевая модель документа.
3. Маршрут документа (диаграммой или таблицей).
4. Статусно-ролевая матрица.
5. Таблица атрибутов.
6. Дополнительные требования.
