Почему RPA спотыкается на нетиповых документах и где нужен ИИ-агент

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

Как это устроено сейчас

Типовой маршрут выглядит так: письмо попадает в общий ящик, вложение открывается, из него извлекают номер, дату, контрагента, позиции и суммы. Затем данные сверяют с 1С и создают черновик документа. Сотрудник проверяет результат и отправляет его дальше.

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

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

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

Условный пример журнала исключений

Все записи и минуты ниже вымышлены для иллюстрации формата. Это не данные клиента и не измеренный результат внедрения.

• Счёт PDF. Товар и доставка указаны отдельными строками; сценарий не определил сумму заказа. Сотрудник сверил условия и подтвердил итог. Время разбора: 7 минут (условно).
• Скан накладной. Одна строка размыта; позиция не распознана. Сотрудник сверил её с исходником и внёс вручную. Время разбора: 12 минут (условно).
• Письмо с вложениями. Два заказа и два счёта связались с одной заявкой. Сотрудник разделил заявки и сопоставил вложения. Время разбора: 9 минут (условно).

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

Почему обычные решения не закрывают проблему целиком

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

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

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

Заменить всё агентом. Это тоже не универсальный ответ. Агент может неверно прочитать слабый скан, спутать реквизиты в приложениях или предложить значение, которого нет в документе. Нужны проверка по источнику, правила отказа и контроль человеком для неоднозначных случаев. Там, где вход строго типовой, существующий робот может быть проще.

Как соединить агента и RPA

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

Приём. Сохраняйте исходное письмо и вложение вместе с идентификатором заявки. Если в письме несколько документов, их связь должна остаться видимой.

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

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

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

Запись. После проверки данные передаются через API, если оно доступно. Если нужное действие возможно только в интерфейсе, его выполняет RPA. На этом участке робот остаётся полезным: он делает повторяемое действие по уже подготовленным данным.

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

Что это даёт и что остаётся человеку

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

В одном из проектов команды проверка договора по чек-листу занимала у юриста 4–5 часов; агент проходил чек-лист за 5–10 минут и передавал список расхождений. Этот результат относится к конкретной проверке договора: его нельзя переносить на весь поток счетов или обещать такой же эффект для любого RPA-сценария.

Titanium AI разбирает именно связку «неструктурированный вход → проверка по правилам → действие в рабочей системе». Агента можно поставить перед уже действующим роботом. Решение о том, оставлять ли RPA, заменять участок интеграцией или вообще не внедрять агента, принимается после разбора одного процесса.

С чего начать

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

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