«Коробочные» решения набирают все большую популярность среди малых и средних компаний. Такой вариант выгоден как клиенту, так и вендору: оба могут сократить свои расходы на поддержку за счет поставки типовой конфигурации. Однако даже в небольших компаниях, при всей их готовности менять процессы под систему, есть свои особенности. И тут уже возникает вопрос, как наиболее оптимально адаптировать систему под специфику организации? Рассмотрим на примере процесса согласования документов и его реализации в системе DirectumRX. Вариантов адаптации немного: заказная разработка или использование возможностей настройки механизма согласования. Их и разберем, но прежде углубимся в сам процесс согласования.
Вариации согласования
До 30% всех процессов в организации – это процедуры согласования тех или иных документов. В зависимости от вида документа меняются согласующие, сроки, порядок рассмотрения – все это зафиксировано, как правило, во внутренних регламентах. Упростив и обобщив имеющийся опыт, получим примерные вариации процессов согласования.
Внутренние документы, требующие утверждения (Приказы, распоряжения):
- Согласование.
- Печать.
- Утверждение.
- Регистрация.
- Исполнение или ознакомление.
Внутренние документы, требующие рассмотрения адресатом (Служебные записки):
- Согласование (если требуется).
- Рассмотрение адресатом.
- Исполнение (если требуется.
Исходящая корреспонденция (Официальные письма):
- Согласование.
- Печать.
- Подписание.
- Регистрация и отправка корреспондент.
Договорные документы (Договоры, дополнительные соглашения, спецификации:
- Согласование.
- Печать.
- Подписание.
- Регистрация.
- Отправка контрагенту.
- Контроль возврат.
Бухгалтерские документы (Входящие счета на оплату):
- Согласование.
- Утверждение оплаты.
- Исполнение (оплата)
Итого, на каждую компанию приходится как минимум 6 разных процессов. Попытаемся справиться с ними с помощью механизма настройки.
Настраиваем процесс согласования документов
В контексте системы электронного документооборота DirectumRX настройка процесса сводится к заполнению правил согласования в специальном конструкторе в соответствии с внутренним регламентом. Процесс фиксируется в виде схемы. Схема состоит из этапов согласования, условий и переходов между ними.
Этапы сгруппированы:
- Согласование: непосредственное согласование, подписание, рассмотрение.
- Обработка документа: отправка на исполнение, печать и передача на подпись, регистрация, задание, уведомление.
- Переписка с контрагентом: отправка контрагенту, контроль возврата от контрагента. Для каждого этапа настраиваются параметры:
- Исполнитель/исполнители. В качестве исполнителей могут быть как конкретные сотрудники, так и предопределенные роли, например, руководитель инициатора.
- Срок. Может быть задан в днях или часах. Также может быть настроена отсрочка создания задания, например, для контроля возврата от контрагента. В таком случае оно придет исполнителю ближе к сроку и не будет подолгу мешаться в общем списке входящих заданий.
- Порядок получения заданий: если в этапе есть несколько согласующих, то они могут согласовывать одновременно или по очереди.
- Порядок доработки: если в этапе есть несколько согласующих, то можно вернуть документ на доработку сразу после первого не согласовавшего или подождать пока все согласующие выполнят задания.
- Порядок подписания документа: если руководитель не работает в системе, то вместо задания на подписание его секретарь получит задание на внесение результата подписания в систему.
Разберем настройку согласования договорного документа. Фактически, мы фиксируем в системе ключевые этапы обработки документа и условия их прохождения. 
- Первым согласовывает непосредственный руководитель инициатора.
- Если договор нетиповой – его согласовывает руководитель технического отдела и доп. согласующие.
- Если договор нетиповой, и его сумма больше 100 000 руб. – дополнительно согласовывает главный бухгалтер.
- Далее юрист печатает два экземпляра договора и передает на подпись.
- Директор подписывает договор.
- Юрист регистрирует договор и передает для отправки в секретариат.
- Секретарь отправляет оба экземпляра договора контрагенту.
- Юрист отслеживает возврат подписанного контрагентом экземпляра договора.
- По возвращении договор отправляется на исполнение.
Сочетание наборов блоков и гибкости их параметров позволяет закрыть бизнес-процессы согласования настройкой. При этом в DirectumRX правило согласования настраивается интерактивно и удобно.
Разрабатываем процессы согласования документов
В некоторых ситуациях гибкости настройки может быть недостаточно. У крупных компаний или гос. органов встречаются специфичные только для них особенности согласования. Может потребоваться изменение карточек заданий, например, для добавления специфического функционала, такого как действия по интеграции с другими системами или формирования отчетных форм. В таком случае можно разработать новый тип задачи или доработать существующий. Тип задачи – это представление бизнес-процесса на уровне разработки. Схема такого процесса состоит из атомарных частей – блоков, таких как задание и уведомление. Разработчик самостоятельно реализует и дополнительные действия для типа задачи:
- Определение участников и последовательности согласования.
- Выдача прав на документы.
- Изменение статусов документов.
- Обработка «негативных» сценариев: отказ в подписании документа, прекращение задачи.
- Визуальная логика: результаты выполнения заданий, темы заданий и подсказки, проверка введенных пользователем данных.
Пример бизнес-процесса для разработки: нужно добавить для бухгалтера возможность принять к оплате входящий счет и сразу провести документ в 1С.Для этого в системе потребуется добавить новый тип задания.
Также нужно добавить возможность настраивать новый этап обработки счета бухгалтером. Чтобы система могла понять, кто такой «бухгалтер» нужно добавить вычисляемую роль.
И еще нужно реализовать защиту от ошибочных ситуаций: чтобы нельзя было добавить этап принятия к оплате для приказов или служебных записок. Все это требует знания системы и умения программировать.
Также потребуется отдельный стенд для разработки и тестирования, что усложняет инфраструктуру. И, конечно, внесенные изменения нужно будет поддерживать дальше, в том числе и при обновлениях на новую версию системы.
Настройка vs. Разработка
Чтобы подвести некий итог, предлагаю взглянуть на сложившуюся картину и сравнить возможности обоих вариантов.
Критерий сравнения / Настройка / Разработка
Требования к квалификации - Все настройки производит администратор или бизнес-пользователь, ответственный за процесс - Требуется обученный разработчик или привлечение сторонних разработчиков (вендора или партнера) Трудоемкость реализации - От 0,5 часа на процесс - От 8 часов на процесс Простота внесения изменений - Можно быстро добавлять новые бизнес-процессы, состоящие из типовых этапов.
В том числе и после внедрения системы без привлечения вендора или разработчика - Для добавления новых бизнес-процессов требуется разработчик Поддержка новых версий продукта - Добавленные вендором возможности будут доступны автоматически - Новый функционал типовой версии нужно адаптировать с привлечением разработчика Полнота покрытия - Может не закрыть специфичные процессы - Полная кастомизация, закрывает 100% кейсов Возможность заказной доработки системы для сложных бизнес-процессов всегда остается востребованной. Она актуальна для крупных компаний, готовых к масштабным внедрениям и зачастую предъявляющих специфические требования к системе. Но важными факторами выбора системы для среднего бизнеса являются стоимость и простота внедрения и поддержки.
Мы уверены, что такой простой и удобный инструмент, который предполагает использование готовых этапов без необходимости программирования будет широко востребован средними организациями.
Денис Колесников