На встрече всё выглядит убедительно.
В систему загружают счёт. Через несколько секунд на экране появляются поставщик, реквизиты, позиции и итоговая сумма. Ещё одно действие, и данные готовы к передаче в учётную систему.
Кажется, ручной перенос можно убирать из процесса.
Потом вы загружаете документы своей компании. Один приходит в виде скана, второй содержит таблицу на нескольких страницах, третий поставщик присылает повторно с исправленной ценой.
Где-то пропадает строка. Где-то неверно определяется количество. Обновлённый документ система принимает за новый.
Сотрудник открывает исходный файл и начинает проверять всё заново.
Демонстрация показывает, что решение способно выполнить задачу в показанных условиях. Для решения о внедрении нужно выяснить, как оно справляется с вашим потоком документов и сколько работы оставляет человеку.
Разберём, как проверить это до большой интеграции. В конце у вас будет основа проверочной выборки, таблица оценки ошибок и список вопросов подрядчику.
Почему успешная демонстрация ещё не подтверждает готовность к работе
Для короткой презентации обычно выбирают понятный сценарий. Это нормально: за ограниченное время нужно показать принцип работы.
Но повседневный процесс состоит не только из удачного распознавания.
Система должна понять, какой документ получила, извлечь нужные данные, заметить пропуски, обработать повторную отправку и передать результат дальше. Иногда ей придётся остановиться и запросить проверку.
Представим условный пример: компания хочет автоматически переносить позиции из счетов поставщиков в учётную систему.
На демонстрации показали один PDF с чёткой таблицей. В реальной работе встречаются:
- сканы с печатями поверх текста;
- фотографии с обрезанными краями;
- документы с разными единицами измерения;
- таблицы, которые продолжаются на следующей странице;
- исправленные версии ранее полученных счетов;
- файлы с неполными реквизитами;
- документы, защищённые паролем.
Успешная обработка первого PDF ничего не говорит о качестве работы с остальными вариантами. Их нужно проверить отдельно.
Что именно может сломаться
Фраза «ИИ неправильно распознал документ» слишком общая. Для бизнеса важно понять, где возникла ошибка и какое действие последовало за ней.
Ошибки обработки документов и способы проверки| Что произошло | Почему это важно | Что проверить |
|---|
| Пропущена строка таблицы | Заказ или запись в системе окажутся неполными | Сверяется ли состав позиций с источником |
|---|
| Перепутаны штуки и упаковки | Может измениться фактический объём заказа | Как обрабатываются единицы измерения |
|---|
| Ошибочно прочитана сумма | Данные для согласования или оплаты будут неверными | Есть ли арифметические проверки |
|---|
| Повторный файл принят за новый | Может появиться дублирующая запись | Как обнаруживаются повторные отправки |
|---|
| Исправленная версия не связана с предыдущей | В работе могут остаться старые условия | Как учитываются версии документов |
|---|
| Отсутствующее поле заполнено догадкой | Сотрудник может принять выдуманные данные за исходные | Что происходит при недостатке информации |
|---|
| Данные извлечены, но не переданы дальше | Сотруднику всё равно придётся переносить их вручную | Как проверяется завершение всей операции |
|---|
Не все эти проблемы относятся непосредственно к модели ИИ. Некоторые связаны с правилами проверки, сопоставлением данных и интеграцией.
Поэтому принимать нужно весь рабочий сценарий: от получения файла до корректного результата в нужной системе.
Начните с результата, который нужен сотруднику
До тестирования сформулируйте, что должно получиться после обработки документа.
«Распознать счёт» недостаточно конкретно.
Более полезная постановка:
Получить поставщика, номер и дату счёта, позиции, количества, единицы измерения и суммы. Проверить обязательные поля и арифметику. Подготовить черновик записи в учётной системе. Неоднозначные значения передать сотруднику вместе со ссылкой на исходный фрагмент.
Теперь понятно, что проверять.
Отдельно определите, какие действия система может выполнять самостоятельно. Подготовка черновика и создание окончательной записи требуют разного уровня контроля. Для финансово значимых действий могут понадобиться дополнительные согласования.
Хорошее требование описывает и успешную обработку, и поведение в ситуации, когда система не может получить надёжный результат.
Как собрать документы для проверки
Не ограничивайтесь несколькими аккуратными файлами, которые легко прочитать человеку.
Начните с документов за обычный рабочий период. Посмотрите, какие форматы и поставщики встречаются, где сотрудники исправляют данные и какие файлы возвращают на уточнение.
Соберите три группы.
1. Обычные документы
Это основная часть потока: типовые счета, заявки, акты или другие документы, ради которых создаётся решение.
Важно представить распространённые варианты оформления. Если компания работает с несколькими крупными поставщиками, проверка одного шаблона не заменяет проверку остальных.
2. Сложные, но рабочие документы
Сюда входят файлы, с которыми команда действительно сталкивается:
- сканы невысокого качества;
- многостраничные таблицы;
- объединённые ячейки;
- примечания с важными условиями;
- разные валюты и единицы измерения;
- несколько документов в одном файле.
Задача этой группы состоит в том, чтобы проверить реальные сложности вашего процесса. Случайный нечитаемый файл, которого никогда не бывает в работе, мало поможет оценке.
3. Исключения
Добавьте повторную отправку, исправленную версию, неподходящий тип документа, недоступный файл и документ без обязательных данных.
Здесь правильным результатом может быть остановка обработки и понятное уведомление сотруднику.
Количество файлов зависит от разнообразия и объёма потока. Небольшая подборка поможет найти первые проблемы, но её недостаточно для обещания определённой точности на всей работе компании.
Часть документов используйте для настройки, а часть оставьте для независимой проверки после неё.
Подготовьте правильные ответы до запуска теста
Чтобы оценка не превратилась в спор о впечатлениях, заранее зафиксируйте ожидаемый результат.
Для каждого проверочного документа запишите необходимые поля и правильные значения. Если исходный файл неоднозначен, отметьте, что требуется уточнение.
Не заставляйте проверяющего придумывать ответ, которого нет в документе.
Для учёта результатов подойдёт такая таблица:
Таблица для оценки результатов пилота| Поле проверки | Что записать |
|---|
| Документ и сценарий | Тип, источник, обычный случай или исключение |
|---|
| Ожидаемый результат | Правильные значения и необходимое действие |
|---|
| Результат системы | Что извлечено и куда передано |
|---|
| Ошибка | Какое поле или действие неверно |
|---|
| Последствие | Требуется исправление, остановка или повторная обработка |
|---|
| Время сотрудника | Сколько заняли проверка и исправления |
|---|
| Итог | Принято, отправлено на уточнение или отклонено |
|---|
Так вы получите основу для решения: что работает, что нужно доработать и какие ошибки мешают запуску.
Почему «точность 98%» мало говорит без пояснений
Прежде чем оценивать красивый процент, спросите, что именно посчитали.
Это доля правильно распознанных символов, заполненных полей или документов, в которых не было ни одной значимой ошибки?
Представим условный счёт с 50 проверяемыми полями. Одно поле распознано неверно. На уровне полей результат составляет 98%.
Но если ошибка оказалась в банковском реквизите или количестве товара, принимать такой документ без проверки нельзя.
Поэтому полезно отдельно оценивать:
- корректность критичных полей;
- долю документов, пригодных для следующего шага без исправлений;
- долю случаев, отправленных на ручную проверку;
- ошибки, которые система не заметила;
- время проверки и исправления.
Доля ручной проверки тоже требует контекста. Если система уверенно пропускает ошибки, низкое количество проверок не является преимуществом. Если она отправляет человеку почти каждый документ, ожидаемая экономия времени может не появиться.
Посчитайте работу, которая остаётся после ИИ
Быстро получить результат недостаточно. Сотрудник должен суметь его использовать.
Допустим, вручную обработка документа занимает 10 минут.
Система извлекает данные за 20 секунд, но затем сотрудник тратит 7 минут на сверку и ещё 2 минуты на исправления. В таком сценарии человеческая работа сократилась лишь на одну минуту.
Это условный пример. Он показывает, почему скорость модели нельзя выдавать за экономию рабочего времени.
Для оценки сравнивайте весь путь:
Подготовка файла + обработка + проверка + исправления + перенос в рабочую систему.
Активное время сотрудника и полное время прохождения документа учитывайте отдельно. Автоматическая операция может выполняться в фоне, пока человек занимается другой задачей.
Проверяйте также удобство исправлений. Если ради одного спорного значения нужно заново открыть многостраничный файл и найти нужную строку, качество интерфейса будет напрямую влиять на результат внедрения.
Договоритесь о критериях приёмки до интеграции
Критерии стоит определить вместе с владельцем процесса и сотрудниками, которым предстоит работать с системой.
Универсального допустимого процента ошибок нет. Требования зависят от последствий: неверная категория внутреннего документа и неверные данные для платежа создают разные риски.
Зафиксируйте:
- Какие документы входят в первый этап.
- Какие поля обязательны.
- Какие ошибки недопустимы для автоматического продолжения.
- Когда система должна запросить проверку.
- Кто отвечает за разбор исключений.
- Сколько ручной работы должно остаться.
- Какие результаты позволят расширить внедрение.
Нужен и порядок действий при техническом сбое. Например, если учётная система недоступна, документ не должен незаметно исчезнуть из очереди. Повторная попытка передачи не должна создавать дубликат.
Это часть рабочего процесса, которую полезно проверить до запуска на полном потоке.
Что спросить подрядчика на следующей демонстрации
Вместо общего вопроса «Насколько точно работает ваш ИИ?» предложите разобрать несколько конкретных ситуаций.
- Можно ли проверить решение на документах, которые не использовались при настройке?
- Что произойдёт, если в файле нет обязательного значения?
- Как сотрудник увидит, откуда взято спорное поле?
- Что будет при повторной отправке того же документа?
- Как обрабатывается исправленная версия?
- Сколько времени занимает проверка результата человеком?
- Что произойдёт, если следующая система недоступна?
- Какие материалы и действия входят в стоимость пилота?
Ответы помогут понять границы решения и состав работ. Честно обозначенное ограничение полезнее обещания обработать любые документы без ошибок.
Как начать без большого проекта
Выберите один тип документов и один результат. Например, подготовку черновика счёта для проверки сотрудником.
Соберите реальные файлы, зафиксируйте ожидаемые значения и измерьте текущие трудозатраты. После настройки проверьте решение на отложенной выборке и сравните весь процесс, включая исправления.
На первом этапе можно оставить подтверждение за человеком. Расширять самостоятельные действия системы стоит по результатам проверки конкретных сценариев.
В Futureinapps мы внедряем обработку документов и данных с помощью ИИ. Для первого обсуждения подготовьте несколько обезличенных файлов, пример нужного результата и описание того, что происходит с документом после получения.
Это поможет определить границы пилота, требования к проверке и возможную интеграцию.
Результатом пилота должно стать обоснованное решение: внедрять, дорабатывать или остановиться. Чем раньше вы получите этот ответ на своих документах, тем меньше времени и бюджета потратите на неподходящее решение.
