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

Главная задача — не «оцифровать папки», а сделать движение документа наблюдаемым. У каждого объекта должна быть карточка, источник, версия, статус, ответственный, контрольная дата, история действий и понятное правило завершения.

Базовый контур выглядит так:

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

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

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

Обычно в карточке фиксируют:

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

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

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

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

Пример правила:

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

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

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

Контроль сроков работает только тогда, когда заранее определено, от какого события начинается отсчёт и что считается исполнением. Поле «срок» без этих правил создаёт видимость контроля.

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

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

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

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

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

Для электронных архивных документов российские правила архивного хранения предусматривают работу не только с файлом, но и с метаданными; для передаваемого электронного архивного документа основной файл предусмотрен в формате PDF/A, а при наличии отдельно учитываются приложения и файлы электронной подписи. Также правила устанавливают требования к правам доступа и поддержанию юридической значимости в течение установленного срока хранения. Конкретный режим зависит от статуса организации и категории документов.

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

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

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

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

Автоматизация делопроизводства редко состоит из одного компонента. Практический контур разделяют по функциям.

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

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

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

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

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

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

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

Автоматизация должна сокращать механические действия, а не размывать ответственность.

Ниже — практическое распределение:

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

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

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

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

Похожим образом обрабатываются другие исключения:

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

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

Пилот лучше начинать не со всего корпоративного архива, а с одного документопотока. Например: входящие письма определённого типа → регистрация → назначение подразделения → контроль срока → завершение → электронное дело.

До разработки нужно собрать реальные примеры и зафиксировать эталонный процесс:

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

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

Если в потоке есть свободный текст, сканы и сложные вложения, отдельный подход к извлечению и ручной проверке описан в материале об AI для обработки писем и PDF.

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

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

Реальный кейс engineer. с документами и интеграциями — AI-система для B2B-поставщика: в опубликованном сценарии заявки из почты, мессенджеров, Excel и PDF сопоставляются с данными 1С, склада и CRM, а менеджер сохраняет проверку и финальное решение.