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