Автоматизация процесса согласования в СЭД. Настройка или разработка?

«Коробочные» решения набирают все большую популярность среди малых и средних компаний. Такой вариант выгоден как клиенту, так и вендору: оба могут сократить свои расходы на поддержку за счет поставки типовой конфигурации. Однако даже в небольших компаниях, при всей их готовности менять процессы под систему, есть свои особенности. И тут уже возникает вопрос, как наиболее оптимально адаптировать систему под специфику организации? Рассмотрим на примере процесса согласования документов и его реализации в системе DirectumRX.

Вариантов адаптации немного: заказная разработка или использование возможностей механизма согласования. Их и разберем, но прежде углубимся в сам процесс согласования.

Вариации согласования

До 30% всех процессов в организации – это процедуры согласования тех или иных документов. В зависимости от вида документа меняются согласующие, сроки, порядок рассмотрения – все это зафиксировано, как правило, во внутренних регламентах.

Упростив и обобщив имеющийся опыт, получим примерные вариации процессов согласования:

Итого, на каждую компанию приходится как минимум 6 разных процессов. Попытаемся справиться с ними с помощью механизма настройки.

Настраиваем процесс согласования документов

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

Этапы сгруппированы:

• Согласование: непосредственное согласование, подписание, рассмотрение.
• Обработка документа: отправка на исполнение, печать и передача на подпись, регистрация, задание, уведомление.
• Переписка с контрагентом: отправка контрагенту, контроль возврата от контрагента.

Для каждого этапа настраиваются параметры:

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

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

Первым согласовывает непосредственный руководитель инициатора.
Если договор нетиповой – его согласовывает руководитель технического отдела и доп. согласующие.
Если договор нетиповой, и его сумма больше 100 000 руб. – дополнительно согласовывает главный бухгалтер.
Далее юрист печатает два экземпляра договора и передает на подпись.
Директор подписывает договор.
Юрист регистрирует договор и передает для отправки в секретариат.
Секретарь отправляет оба экземпляра договора контрагенту.
Юрист отслеживает возврат подписанного контрагентом экземпляра договора.
По возвращении договор отправляется на исполнение.

Сочетание наборов блоков и гибкости их параметров позволяет закрыть бизнес-процессы согласования настройкой. При этом в DirectumRX правило согласования настраивается интерактивно и удобно:

Разрабатываем процессы согласования документов

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

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

• Определение участников и последовательности согласования.
• Выдача прав на документы.
• Изменение статусов документов.
• Обработка «негативных» сценариев: отказ в подписании документа, прекращение задачи.
• Визуальная логика: результаты выполнения заданий, темы заданий и подсказки, проверка введенных пользователем данных.

Пример бизнес-процесса для разработки: нужно добавить для бухгалтера возможность принять к оплате входящий счет и сразу провести документ в 1С.

Для этого в системе потребуется добавить новый тип задания. Также нужно добавить возможность настраивать новый этап обработки счета бухгалтером. Чтобы система могла понять, кто такой «бухгалтер» нужно добавить вычисляемую роль. И еще нужно реализовать защиту от ошибочных ситуаций: чтобы нельзя было добавить этап принятия к оплате для приказов или служебных записок.

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

Настройка vs. Разработка

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

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

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

Подробнее о том, как это реализовано в DirectumRX можно посмотреть в роликах:

• Правила согласования. Корреспонденция и внутренние документы (DirectumRX 2.3)
• Правила согласования. Договорные документы (DirectumRX 2.3)