Внедрение системы внутреннего электронного документооборота (СЭД)
TBD
В разработке!
Подготовка внедрения системы электронного документооборота
Введение
Внедрение системы электронного документооборота – это мероприятие, в большей степени требующее организационной и методологической подготовки, по сравнению с ИТ составляющей. При этом подготовка достаточно проста и может быть осуществлена без специальных навыков. При этом, обычно, этот этап составляет значительную часть стоимости проекта, если внедрение ведет подрядчик, поскольку требуете времени на погружение в специфику организации.
Руководствуясь инструкциями и шаблонами, приведенными в данном документе, можно подготовить техническое задание, на основании которого настройка любой системы документооборота даже с участием подрядчика может быть проведена быстро и недорого.
Следующие разделы описывают подходы к формированию разделов или документов, входящих в техническое задание, а некоторые разделы могут использоваться и в дальнейшем для управления изменениями составом документов и маршрутов их согласования.
Описание объекта автоматизации
Описание объекта желательно формировать даже если внедрение проводится самостоятельно. Эти материалы потребуются для выбора программного решения, расчета стоимости лицензий, расчета требований к инфраструктуре и для настройки справочников.
Описание автоматизируемого объекта (предприятия)
- Структура предприятия
- Важно определить - одиночное, предприятие с филиалами или холдинг. Если в предприятии более одной организации или есть филиалы, то приложить графическую схему структуры предприятия.
- Организационная структура.
- Желательно указывать и в табличном виде и в графическом.
- Количество пользователей
- Рассчитывайте исходя из функционала, который планируете внедрять. Обычно, наибольшее количество пользователей использует функционал поручений.
Определение реестра подлежащих переносу в ЭДО документов
Укажите все документы, которые вы планируете переводить в электронную форму.
Обратите внимание, что в некоторых случаях, можно не просто перевести документ в электронную форму, а и вообще от него отказаться, просто наладив прямую интеграцию информационных систем. Поэтому при составлении этого реестра обязательно задайте себе вопрос, а действительно ли нужен конкретный документ и зафиксируйте ответ на него в документации. Также надо иметь в виду, что некоторые документы принципиально не подлежат переводу в электронную форму.
Обратите внимание, не нужно пытаться сразу перевести все документы в электронную форму. Это трудоемко, сложно и рискованно. Более оптимальным является подход, когда сначала переводятся самые простые документы, и потом по одному переводятся прочие.
Не забывайте отражать по итогам перевода документа в электронную форму этот факт в номенклатуре дел формального документооборота.
Определение владельцев маршрутов согласования
Целесообразно определять владельцев маршрутов согласования – сотрудников, которые отвечают за разработку и согласование маршрутов.
Обычно это аналитики, но в случае их отсутствия в компании может быть назначен и другой специалист.
Задачи владельца маршрута:
- Сформировать полное и непротиворечивое описание маршрута (руководствуясь, например, приведенными в настоящем документе рекомендациями).
- Согласовать маршрут с заинтересованными лицами (владельцами процессов, в которых задействован соответствующий документ).
- Оформить и утвердить распорядительный документ, устанавливающий маршрут в качестве обязательного к исполнению.
- Убедиться в корректности настройки маршрута документа в автоматизированных системах.
- Принимать и реагировать на замечания и предложения по совершенствованию маршрута от коллег.
Жизненный цикл документа
Жизненный цикл электронного документа, определяет какие возможные состояния может принимать документ и что может являться причиной для изменения этих состояний.
Наиболее удобно для описания жизненного цикла использовать диаграмму статусов. В прямоугольниках описывается статус, стрелки обозначают действия, которые переводят документ из одного статуса в другой.
При этом не стоит путать жизненный цикл документа с маршрутом согласования.
Ролевая модель документа
В разные моменты времени и для разных документов разные сотрудники могут выполнять разные роли. Так, один и тот же человек может выполнять, например, для одного письма роль инициатора письма, для другого - согласующего, для третьего - исполнителя.
Поэтому целесообразно оперировать именно ролями. Для каждого документа определите свой набор ролей. В некоторых случаях, есть возможность объединить некоторые виды документов под один процесс.
Например, наиболее часто используемые роли:
- Автор
- Инициатор
- Согласующий
- Канцелярия
- Получатель
- Исполнитель
- Ролевая модель оформляется в виде списка, например такого (для простой служебной записки):
| Наименование роли | Назначение роли |
| Автор | Сотрудник, непосредственно формирующий служебную записку. |
| Инициатор | Сотрудник, инициировавший написание служебной записки |
| Подписант | Сотрудник, имеющий полномочия направлять служебную записку |
| Получатель | Адресат служебной записки |
| Исполнитель | Исполнитель, которому получатель расписывает служебную записку на исполнение. |
Маршруты согласования
Маршрут согласования определяет последовательность участия участников документооборота в процессах жизненного цикла документа, а также дополнительные характеристики документооборота, в том числе максимальную длительность этапов жизненного цикла и эскалации.
Изобразить маршрут согласования можно в графическом виде и в табличном. Лучше всего делать оба вида описания маршрута.
Графическое описание маршрута согласования.
Графическое обозначение маршрута согласования можно оформить в любой пригодной нотации. Наиболее полно можно это сделать с помощью нотации BPMN, но можно воспользоваться и более простыми вариантами. Например, изображенным на следующей диаграмме:
В данном случае, прямоугольники обозначают состояние (статус) документа, стрелки – доступные для пользователя действия (решения).
Прямоугольники (состояния) размещаются в полосах, обозначающих участников согласования.
Табличное описание маршрута согласования
Ниже приведены примеры описания маршрутов табличным видом.
Пример 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 | Генеральный директор | Утвердить. Отклонить | Подтвердить необходимость закупки в обход процедур | Только для заявок по управленческому решению | Не предусмотрено | Виза на бумажном документе |
В этом примере согласование может идти параллельно.
Доступ к документу (статусно-ролевая матрица)
Доступ для разных ролей на разных этапах жизненного цикла документа может быть разным и это не всегда модно описать маршрутами. Эти особенности доступа описываются Статусно-ролевой матрицей.
Описание задания на разграничение доступа может выглядеть следующим образом (для входящего документа).
- Ч – чтение карточки и файлов.
- К – редактирование карточки.
- Д – возможность добавления файлов.
- Д(К) – возможность создания копии файла.
- Р – возможность редактирования файлов (создание новой версии на основе предыдущей).
- У – возможность удаления файлов.
Статусно-ролевая матрица выглядит следующим образом:
| Роль
|
Регистратор | Получатель | Исполнитель | Секретариат | Юристы | Руководство |
| Зарегистрировано | ЧКДРУ | Ч | Ч | Ч | ||
| На рассмотрении | ЧКД | ЧД(К) | ЧД(К) | ЧКД | Ч | Ч |
| Рассмотрено | ЧК | Ч | Ч | ЧК | Ч | Ч |
Состав карточки документа (таблица атрибутов)
Разные документы могут (и должны) иметь разный набор данных, описывающих документ. Для описания этого набора удобно пользоваться таблицей атрибутов.
В ней указывается какие поля важны для учета, отбора, сортировки и поиска документов.
Такие поля дополнительно заполняются в карточке документа, даже если эта информация и так имеется в тексте документа.
Пример таблицы атрибутов для поручения:
| Название поля | Тип заполняемых данных | Настройки | Значение по умолчанию | Описание поля |
| Дата создания | Дата/время | Только для чтения | Текущая дата/время | Дата/время создания поручения |
| Вид документа | Вид документа | Только для чтения,
заполняется автоматически |
Поручение | |
| Тема | Строка | обязательное для заполнения | Указывается тема поручения | |
| Номер | значение из автоматического нумератора, строка | Только для чтения,
заполняется автоматически |
||
| Срок исполнения | Дата/время | обязательное для заполнения | 1 рабочий день для типа поручения «Для принятия мер» и 15 календарных дней для других типов поручений | Срок может быть изменен Автором по запросу Исполнителя |
| Автор | сотрудник из справочника сотрудников | Только для чтения,
заполняется автоматически |
Сотрудник, создавший поручение | |
| Статус | состояние документа | Только для чтения | Проект | Должно изменяться автоматически в процессе обработки поручения |
| Текст поручения | Строка | обязательное для заполнения | ||
| Исполнитель | сотрудник из справочника сотрудников | обязательное для заполнения | ||
| Соисполнители | сотрудник из справочника сотрудников
Коллекция |
Сотрудники, которые могут привлекаться Исполнителем для исполнения поручения (временные подчиненные в рамках конкретного поручения) | ||
| Наблюдатели | сотрудник из справочника сотрудников
Коллекция |
Сотрудники получающие уведомления о выданном поручении. В исполнении не участвуют. Имеют доступ к карточке и файлам на чтение. | ||
| Контролёр | сотрудник из справочника сотрудников | Подтверждает исполнение поручения |
Дополнительные требования
Иногда существуют такие требования к документу, которые не могут быть зафиксированы в ранее описанных форматах.
В этом случае из можно описать отдельно в произвольной форме.
Пакет документов описания документа маршрута
Для подготовки описания документа к автоматизации нужно сформировать следующие документы:
- Жизненный цикл документа (диаграммой).
- Ролевая модель документа.
- Маршрут документа (диаграммой или таблицей).
- Статусно-ролевая матрица.
- Таблица атрибутов.
- Дополнительные требования.

