Просмотр кода страницы Внедрение системы внутреннего электронного документооборота (СЭД)

TBD

В разработке!

== Подготовка внедрения системы электронного документооборота ==

== Введение ==
Внедрение системы электронного документооборота – это мероприятие, в большей степени требующее организационной и методологической подготовки, по сравнению с ИТ составляющей. При этом подготовка достаточно проста и может быть осуществлена без специальных навыков. При этом, обычно, этот этап составляет значительную часть стоимости проекта, если внедрение ведет подрядчик, поскольку требуете времени на погружение в специфику организации.

Руководствуясь инструкциями и шаблонами, приведенными в данном документе, можно подготовить техническое задание, на основании которого настройка любой системы документооборота даже с участием подрядчика может быть проведена быстро и недорого.

Следующие разделы описывают подходы к формированию разделов или документов, входящих в техническое задание, а некоторые разделы могут использоваться и в дальнейшем для управления изменениями составом документов и маршрутов их согласования.

== Описание объекта автоматизации ==
Описание объекта желательно формировать даже если внедрение проводится самостоятельно. Эти материалы потребуются ИТ специалистам для расчета требований к инфраструктуре и для настройки справочников.

=== Описание автоматизируемого объекта (предприятия). ===

* Структура предприятия – одиночное, предприятие с филиалами или холдинг. Схема предприятия.
* Количество пользователей. Рассчитывайте исходя из функционала, который планируете внедрять. Обычно, наибольшее количество пользователей использует функционал поручений.
* Организационная структура.

== Определение реестра подлежащих переносу в ЭДО документов ==
Укажите все документы, которые вы планируете переводить в электронную форму.

Обычно формально этот список выражается в Реестр объектов электронного документооборота.

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

== Определение владельцев маршрутов согласования ==
Целесообразно определять владельцев маршрутов согласования – сотрудников, которые отвечают за разработку и согласование маршрутов.

Обычно это аналитики, но в случае их отсутствия в компании может быть назначен и  другой специалист.

Задачи владельца маршрута:

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

== Жизненный цикл документа ==
Понимание жизненного цикла электронного документа (ЭД) — это ключ к выстраиванию оптимальных маршрутов обработки ЭД, то есть к построению эффективного электронного документооборота.

Жизненный цикл электронного документа (ЖЦЭД), так же, как и традиционного, зависит от принадлежности к конкретному документопотоку (поступающему (ПД), внутреннему (ВД) и исходящему (ИД)). Кроме того, на жизненный цикл определяется и типом документа.

[[Файл:Пример схемы жизненного цикла документа.png|безрамки|600x600пкс]]



При этом не стоит путать жизненный цикл документа с маршрутом согласования.

== Ролевая модель документа ==
В разные моменты времени и для разных документов разные сотрудники могут выполнять разные роли. Так, один и тот же человек может выполнять, например, для одного письма роль инициатора письма, для другого - согласующего, для третьего - исполнителя.

Поэтому целесообразно оперировать именно ролями. Для каждого документа определите свой набор ролей. В некоторых случаях, есть возможность объединить некоторые виды документов под один процесс.

Например, наиболее часто используемые роли:

* Автор
* Инициатор
* Согласующий
* Канцелярия
* Получатель
* Исполнитель
* Ролевая модель оформляется в виде списка, например такого (для простой служебной записки):

{| class="wikitable"
|'''Наименование роли'''
|'''Назначение роли'''
|-
|Автор
|Сотрудник, непосредственно  формирующий служебную записку.
|-
|Инициатор
|Сотрудник, инициировавший  написание служебной записки
|-
|Подписант
|Сотрудник, имеющий  полномочия направлять служебную записку
|-
|Получатель
|Адресат служебной записки
|-
|Исполнитель
|Исполнитель, которому  получатель расписывает служебную записку на исполнение.
|}

== Маршруты согласования ==
Маршрут согласования определяет последовательность участия участников документооборота в процессах жизненного цикла документа, а также дополнительные характеристики документооборота, в том числе максимальную длительность этапов жизненного цикла и эскалации.

Изобразить маршрут согласования можно в графическом виде и в табличном. Лучше всего делать оба вида описания маршрута.

=== Графическое описание маршрута согласования. ===
Графическое обозначение маршрута согласования можно оформить в любой пригодной нотации. Наиболее полно можно это сделать с помощью нотации BPMN, но можно воспользоваться и более простыми вариантами. Например, изображенным на следующей диаграмме:

[[Файл:Пример графического описания маршрута согласования.png]]

В данном случае, прямоугольники обозначают состояние (статус) документа, стрелки – доступные для пользователя действия (решения).

Прямоугольники (состояния) размещаются в полосах, обозначающих участников согласования.

=== Табличное описание маршрута согласования ===
Ниже приведены примеры описания маршрутов табличным видом.

''Пример 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
|Генеральный директор
|Утвердить. Отклонить
|
|Подтвердить необходимость закупки в обход процедур
|Только для заявок по управленческому решению
|Не предусмотрено
|Виза на бумажном документе
|
|}
В этом примере согласование может идти параллельно.

== Доступ к документу (статусно-ролевая матрица) ==
Доступ для разных ролей на разных этапах жизненного цикла документа может быть разным и это не всегда модно описать маршрутами. Эти особенности доступа описываются Статусно-ролевой матрицей.

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

* Ч – чтение карточки и файлов.
* К – редактирование карточки.
* Д – возможность добавления файлов.
* Д(К) – возможность создания копии файла.
* Р – возможность редактирования файлов (создание новой версии на основе предыдущей).
* У – возможность удаления файлов.

Статусно-ролевая матрица выглядит следующим образом:
{| class="wikitable"
| '''                         Роль'''  

 


'''Состояние'''
|'''Регистратор'''
|'''Получатель'''
|'''Исполнитель'''
|'''Секретариат'''
|'''Юристы'''
|'''Руководство'''
|-
|Зарегистрировано
|ЧКДРУ
|
|
|Ч
|Ч
|Ч
|-
|На  рассмотрении
|ЧКД
|ЧД(К)
|ЧД(К)
|ЧКД
|Ч
|Ч
|-
|Рассмотрено
|ЧК
|Ч
|Ч
|ЧК
|Ч
|Ч
|}

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

В ней указывается какие поля важны для учета, отбора, сортировки и поиска документов.

Такие поля дополнительно заполняются в карточке документа, даже если эта информация и так имеется в тексте документа.

'''Пример таблицы атрибутов для поручения:'''
{| class="wikitable"
|'''Название  поля'''
|'''Тип  заполняемых данных'''
|'''Настройки'''
|'''Значение по  умолчанию'''
|'''Описание  поля'''
|-
|Дата создания
|Дата/время
|Только для  чтения
|Текущая дата/время
|Дата/время создания поручения
|-
|Вид документа
|Вид документа
|Только для  чтения,

заполняется  автоматически
|Поручение
|
|-
|Тема
|Строка
|обязательное  для заполнения
|
|Указывается тема поручения
|-
|Номер
|значение из автоматического нумератора, строка
|Только для  чтения,

заполняется  автоматически
|
|
|-
|Срок исполнения
|Дата/время
|обязательное  для заполнения
|1 рабочий день  для типа поручения «Для принятия мер» и 15 календарных дней для других типов  поручений
|Срок может быть изменен  Автором по запросу Исполнителя
|-
|Автор
|сотрудник из справочника сотрудников
|Только для  чтения,

заполняется  автоматически
|Сотрудник,  создавший поручение
|
|-
|Статус
|состояние документа
|Только для  чтения
|Проект
|Должно изменяться  автоматически в процессе обработки поручения
|-
|Текст поручения
|Строка
|обязательное  для заполнения
|
|
|-
|Исполнитель
|сотрудник из справочника сотрудников
|обязательное  для заполнения
|
|
|-
|Соисполнители
|сотрудник из справочника сотрудников

Коллекция
|
|
|Сотрудники, которые могут  привлекаться Исполнителем для исполнения поручения (временные подчиненные в  рамках конкретного поручения)
|-
|Наблюдатели
|сотрудник из справочника сотрудников

Коллекция
|
|
|Сотрудники получающие  уведомления о выданном поручении. В исполнении не участвуют. Имеют доступ к  карточке и файлам на чтение.
|-
|Контролёр
|сотрудник из справочника сотрудников
|
|
|Подтверждает исполнение  поручения
|}

== Дополнительные требования ==
Иногда существуют такие требования к документу, которые не могут быть зафиксированы в ранее описанных форматах.

В этом случае из можно описать отдельно в произвольной форме.

== Пакет документов описания документа маршрута ==
Для подготовки описания документа к автоматизации нужно сформировать следующие документы:

# Жизненный цикл документа (диаграммой).
# Ролевая модель документа.
# Маршрут документа (диаграммой или таблицей).
# Статусно-ролевая матрица.
# Таблица атрибутов.
# Дополнительные требования.

[[Категория:Цифровизация]]