Как выбрать систему автоматизации документооборота

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

Для каждого значимого типа документа нужно зафиксировать:

• откуда поступает документ;
• в каком формате приходит оригинал;
• кто создаёт или регистрирует карточку;
• какие реквизиты обязательны;
• какие данные берутся из других систем;
• кто проверяет документ;
• кто и в какой последовательности согласует его;
• когда требуется возврат на доработку;
• кто имеет право изменить реквизиты;
• где хранится итоговая версия;
• какие сроки контролируются;
• какие действия требуют подтверждения человека.

Рассмотрим условный пример.

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

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

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

Список из формулировок вроде «гибкие маршруты», «удобный поиск» и «поддержка интеграций» плохо подходит для выбора. Разные поставщики могут вкладывать в эти определения разный смысл.

Требование должно описывать действие, которое можно воспроизвести.

Например, вместо требования «система должна поддерживать сложные маршруты» можно задать сценарий:

> Договор определённой категории проходит юридическое и финансовое согласование параллельно. Если после их подтверждения изменяется существенное условие, документ должен вернуться обеим ролям на повторную проверку.

Такой сценарий можно показать нескольким поставщикам и сравнить результат, а не рекламные формулировки.

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

Перед демонстрациями разделите требования минимум на три категории.

Обязательные. Без них решение нельзя использовать в целевом процессе. Например, необходимая интеграция, определённая модель прав или поддержка конкретного маршрута.

Желательные. Они упрощают работу, но их отсутствие не блокирует внедрение.

Не относящиеся к первому этапу. Возможности, которые интересны теоретически, но не участвуют в выбранном процессе.

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

Матрица для сравнения вариантов

Удобно использовать одну таблицу для всех рассматриваемых решений.

В ячейках полезнее фиксировать не субъективные оценки вроде «5 из 5», а результат проверки: «работает стандартно», «нужна настройка», «нужна разработка», «не поддерживается».

Так становится видно не только количество функций, но и объём будущих доработок.

Система документооборота редко становится единственной информационной системой компании. Документ может поступить из почты или ЭДО, данные контрагента храниться в учётной системе, клиент — в CRM, а файлы — в корпоративном хранилище.

Поэтому недостаточно получить от поставщика ответ «API есть».

Нужно проверить конкретный маршрут:

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

Для каждой интеграции определяют:

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

Например, если контрагент может независимо редактироваться в CRM, СЭД и учётной системе, техническая интеграция не решит проблему: сначала нужно определить владельца данных.

На странице автоматизации документооборота и согласований показан именно процессный подход: входящий документ связывается с правилами маршрута, рабочими системами и действиями сотрудников, а не обрабатывается изолированно.

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

AI не нужен для проверки заполненного поля, передачи записи в 1С или запуска заранее определённого маршрута.

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

Такой сценарий представлен в кейсе AI-системы для тендерного отдела: система работает с тендерными документами и готовит структурированный результат, а решения остаются за специалистами.

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

Права доступа — не техническая настройка после внедрения, а часть бизнес-процесса.

В одном документе могут одновременно действовать разные ограничения:

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

При демонстрации нужно проверить не только наличие ролей, но и конкретные операции:

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

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

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

Для пилота лучше выбрать один распространённый маршрут и пройти его полностью.

Рассмотрим условный пример.

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

В тестовый набор включают:

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

Протокол приёмки пилота

После проверки по каждому сценарию фиксируется четыре значения:

Входные данные → ожидаемое поведение → фактическое поведение → результат проверки.

Например:

Такой протокол даёт больше информации для выбора, чем сравнение интерфейсов или общего списка возможностей.

Даже подходящий маршрут со временем изменится. Появятся новые подразделения, роли, типы документов и правила согласования.

Поэтому при выборе нужно выяснить, какие изменения сможет выполнять собственная команда.

Например:

• добавить поле карточки;
• создать новый тип документа;
• изменить последовательность согласования;
• добавить условие маршрута;
• поменять права;
• создать уведомление;
• изменить справочник;
• подключить новый отчёт.

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

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

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

При оценке разделите расходы на три части.

Пилот:

• настройка ограниченного процесса;
• подготовка тестовых данных;
• прототипирование интеграций;
• проверка прав;
• тестирование исключений.

Промышленное внедрение:

• настройка всех требуемых маршрутов;
• интеграции;
• перенос документов и справочников;
• настройка пользователей и прав;
• разработка нестандартной логики;
• инфраструктура;
• тестирование;
• обучение сотрудников.

Эксплуатация:

• лицензии;
• инфраструктура;
• поддержка;
• обновления;
• мониторинг;
• резервирование;
• изменение процессов;
• новые интеграции;
• сопровождение индивидуальных доработок.

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

Даже хорошо автоматизированный документооборот не означает отсутствие человека.

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

Это может быть:

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

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

Иногда проблема находится не в отсутствии программы.

Сначала нужно изменить процесс, если:

• сотрудники не могут одинаково описать маршрут одного типа документа;
• неизвестно, кто отвечает за конкретный этап;
• один объект независимо редактируется в нескольких системах;
• одинаковые документы обрабатываются по разным неформальным правилам;
• исключения решаются только через личные договорённости;
• неизвестно, где должна храниться финальная версия;
• невозможно определить, какие решения может принимать система, а какие — только человек.

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