AI-интеграция в СЭД: автоматизация входящих документов

Интеграция AI в документооборот: где ломается ручная обработка

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

Потеря документов редко выглядит как удаление. Чаще это письмо, пересланное на личный адрес «разберусь потом», вложение, которое не открылось, обращение без ответа из-за неверной ветки переписки. Найти такое можно только сверкой ящика с реестром, а её не делают ежедневно.

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

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

Автоматизация входящих: сроки, ошибки, разгрузка операторов

Входящий поток — это сканы, письма, PDF с накладными, вложенные архивы. Сейчас оператор открывает каждый документ, читает реквизиты и вручную заводит карточку в СЭД: номер, дату, контрагента, сумму, предмет. На потоке в несколько сотен документов в день это не «медленно», а очередь: документ ждёт регистрации часами, а пиковая нагрузка утра размазывается на весь рабочий день.

Мы ставим на входе разбор документа: извлечение реквизитов, сверку по справочникам и правилам, а спорные случаи отправляем человеку. Каждое извлечённое значение хранит ссылку на источник, поэтому проверка занимает секунды — видно, из какого фрагмента взято поле. Основной класс отказов — ошибка в реквизите, которая всплывает позже, в оплате или сверке, — уходит: поле либо заполнено уверенно, либо помечено на проверку.

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

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

Способы извлечения данных из входящих документов

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

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

Конвейер обработки: этапы внедрения от аудита до передачи

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

1. Аудит потока документов и систем. Выгружаем статистику по типам входящих за период, смотрим точки входа — почта, сканы, портал, электронный обмен — и фиксируем, какие системы отдают и принимают документы.
2. Схема обработки и маршрутов. Согласуем, что идёт полностью автоматически, что уходит оператору на проверку, а что отклоняется. Отдельно описываем поведение при низкой уверенности распознавания.
3. Настройка извлечения реквизитов. Собираем словари полей, шаблоны типовых форм, правила нормализации дат, номеров и контрагентов — под реальные документы заказчика.
4. Проверка на исторических документах. Прогоняем настройки на выборке уже обработанных входящих и сверяем результат с тем, что операторы проставили вручную.
5. Интеграция с учётной системой и правами доступа. Проверяем, что документ попадает в нужную карточку, а доступ остаётся в рамках существующих ролей.
6. Опытная эксплуатация. Запускаем на одном подразделении или направлении, сравниваем фактическую точность с замером на выборке.
7. Передача в эксплуатацию и обучение команды. Передаём регламенты, настройки и понятные инструкции: как поправить правило, что делать при разборе спорного документа.

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

Комплект поставки: схемы потоков, правила, регламенты

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

Что остаётся у вас на руках:

• Конфигурации извлечения — какие реквизиты берём из входящего документа, с разметкой эталонных образцов и примерами нестандартных форм.
• Схема маршрутов — карта типов входящих документов и точек, где включается автоматическая обработка, а где обязателен человек.
• Правила маршрутизации — по типу документа, отправителю и подразделению, с условиями передачи на ручной разбор.
• Правила приоритезации — что уходит вперёд при пиковой нагрузке и как ведёт себя очередь, если внешний сервис недоступен.
• Политики доступа — какие роли видят исходный документ, извлечённые поля и историю обработки.
• Регламент обработки — порядок действий при низкой уверенности модели, спорном реквизите или повторной регистрации.
• Инструкции операторов — как подтвердить или исправить извлечённые данные и куда смотреть при сбое.
• Журнал и метрики — доля документов, прошедших без участия человека, и время от поступления до регистрации.

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

Кейс: обработка входящих без ручной сортировки и потерь

Входящий поток у заказчика шёл по трём каналам — корпоративная почта, сканы с бумаги и портал контрагентов — и разбирался вручную. Оператор открывал документ, определял тип, вводил реквизиты и выбирал маршрут: на документ уходило 5–8 минут, а 12–14% маршрутов оказывались ошибочными. Счёт попадал не в тот отдел, срок ответа контрагенту срывался, часть писем вообще оставалась в личных папках.

Разбор перенесли на модель: классификация по типам — договоры, счета, претензии, служебные записки, — извлечение реквизитов и сумм, сверка со справочником контрагентов. Документы с высокой уверенностью уходят в 1С:Документооборот сами, остальные попадают в очередь на доработку с уже заполненными полями, а не с пустой карточкой.

Что показали метрики

Время регистрации сократилось с 6 минут до 35 секунд, без участия человека разбирается 88% входящих, доля ошибочных маршрутов упала с 14% до 2%. Ни один документ не лежит необработанным дольше суток — раньше такие терялись.

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

Чем извлечение правилами отличается от работы модели?

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

Каждое поле прослеживается до конкретного совпадения — это и есть проверяемость: видно, какое условие сработало и почему. Обратная сторона — жёсткость. Сменился бланк поставщика, документ ушёл в скан под наклоном, штамп перекрыл область — правило молча вернёт пустое значение.

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

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

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

Технические сомнения: точность AI, разметка, права доступа

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

Где обрабатываются документы и кто видит содержимое?

Обработка идёт в контуре заказчика, внешним сервисам данные не отдаются. Права наследуются из СЭД: сотрудник видит те же документы, что и раньше, а обращения к системе журналируются. Удаление документа означает удаление его текста и в хранилище.

Сколько примеров нужно разметить?

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

Точность держится после запуска?

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

Обсудим задачу: что нужно для оценки вашего потока

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

• Типы документов: что идёт массово, а что требует исключений — счета, акты, договоры, входящая корреспонденция.
• Объём потока: документов в день, пиковые периоды, доля операций, которые сейчас делаются руками.
• Текущие системы: что стоит сейчас, кто владелец контура, какие есть каналы обмена данными.
• Точки интеграции: где встраиваемся — приём, регистрация, маршрутизация, согласование, архив.
• Требования к доступам: где хранятся данные, кто имеет доступ, есть ли ограничения на внешние сервисы.
• Критерии приёмки: чем измерим результат — доля документов, обработанных без правок, время до регистрации.
• Приоритеты: какой участок запускаем первым и что считаем готовым результатом этапа.

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