Ошибка распознавания не должна становиться учётной ошибкой
Сотрудник получает скан документа, перепечатывает номер, дату, контрагента и строки, затем проверяет итог. Кажется, что достаточно подключить распознавание и убрать ручную работу. Но если неверное значение автоматически попадает в рабочую систему, поиск ошибки становится сложнее: её уже используют другие сотрудники и процессы.
OCR — преобразование изображения текста в машиночитаемые символы. После этого ещё нужно определить смысл полей, сопоставить их со справочниками и проверить взаимосвязи. Прочитать цифры и создать корректную запись — разные задачи.
Поэтому проектировать стоит весь путь документа: приём, извлечение, проверку, решение оператора, загрузку и обработку отказа. Его цель — сократить повторный ввод, сохранив управляемость результата.
Выберите один вид документа и одну операцию
Начните с понятного потока, например входящих перечней поставки от постоянных контрагентов. Не объединяйте сразу счета, договоры, письма и рукописные приложения: у них различаются поля и правила проверки.
Для выбранного потока опишите действие, которое выполняет сотрудник. Возможно, ему нужна предварительная карточка поступления, а не окончательная запись. Тогда система должна создавать именно черновик, не имитируя завершённое оформление.
Составьте карточку задачи:
- Вход: файл определённого типа из согласованного канала.
- Результат: набор полей для конкретной операции.
- Обязательные значения: номер, дата, контрагент, позиции и другие действительно нужные сведения.
- Проверяющий: роль, которая имеет право исправлять и подтверждать данные.
- Исключение: документ не относится к поддерживаемому потоку.
- Завершение: получен номер записи в целевой системе либо понятный отказ.
Уже на этом этапе можно обнаружить, что часть документов приходит в структурированном виде. Для них прямой обмен данными может оказаться полезнее распознавания изображения.
Условный пример с ошибкой в количестве
Возьмём вымышленный документ на две позиции без дополнительных начислений. В первой строке указано 12 изделий по 250 условных рублей, сумма 3 000. Во второй — 8 изделий по 400, сумма 3 200. Общий итог: 6 200.
Распознавание прочитало первое количество как 72. Это правдоподобное число, поэтому проверка «поле заполнено цифрами» не помогает. Но 72 × 250 = 18 000, что не соответствует строковой сумме 3 000.
Документ попадает оператору. На экране рядом видны распознанные поля и соответствующий фрагмент оригинала. Сотрудник исправляет 72 на 12, после чего система заново проверяет обе строки и итог.
Такой контроль не гарантирует правильность всех данных. Если одновременно ошибочно прочитаны количество и сумма, арифметика может сойтись. Поэтому нужны дополнительные проверки по допустимому ассортименту, основанию операции и выбранным реквизитам.
Проверяйте несколько независимых признаков
Оценка уверенности распознавания полезна для приоритизации внимания, но сама по себе не подтверждает бизнес-смысл поля. Внешне чёткий символ может быть извлечён неверно, а необычный шрифт — распознан правильно.
Разделите проверки по назначению:
- Формат: дата существует, число записано допустимым способом, обязательное поле не пустое.
- Арифметика: количество и цена согласуются с суммой в рамках заданных правил округления.
- Справочник: контрагент и товар найдены либо требуют сопоставления.
- Основание: документ относится к ожидаемому заказу или процессу.
- Повтор: похожая запись уже зарегистрирована.
- Согласованность: реквизиты разных частей документа не противоречат друг другу.
Правила округления, скидок и начислений определяет предметный специалист компании. Их нельзя выводить из одного красивого образца. Эта статья описывает организацию обработки данных, а не правила бухгалтерского или налогового учёта.
Сохраняйте происхождение каждого исправления
Оригинальный файл должен оставаться доступным по устойчивой ссылке внутри процесса. Исправление распознанного значения не меняет изображение документа. Система хранит извлечённый результат, подтверждённую версию и автора решения.
Для существенного поля полезна связь с областью страницы. Тогда оператор сразу видит, откуда взялось значение. Если документ многостраничный, номер страницы тоже входит в контекст.
Условная запись исправления:
- Поле: количество первой позиции.
- Распознано: 72.
- Подтверждено: 12.
- Причина: ошибка чтения символа.
- Основание: первая страница, строка позиции.
- Результат повторной проверки: строка и итог согласованы.
Если позднее меняется сопоставление товара, не следует переписывать уже подтверждённые документы задним числом. Новое правило применяется по согласованному порядку, а прошлые решения остаются объяснимыми.
Дубли ищите до создания новой записи
Один документ может прийти по почте, через форму и повторным сообщением менеджера. Файлы при этом различаются: один цветной, другой чёрно-белый, третий содержит дополнительную страницу.
Проверка точного совпадения файла полезна, но недостаточна. Для поиска возможного дубля используют сочетание контрагента, номера, даты, суммы и других признаков конкретного потока. Совпадение не всегда означает дубль: например, файл может содержать исправленную версию.
Поэтому результат проверки — обоснованный сигнал сотруднику. Ему показывают существующую запись и различия. Решение «новый документ», «повтор» или «исправление» сохраняется вместе с объяснением.
Отдельно защитите повтор загрузки после сбоя. Если целевая система уже создала запись, потерянный ответ не должен приводить к появлению второй.
Организуйте очередь исключений
Все непрошедшие проверки документы не стоит помещать в одну бесконечную папку. Причина должна определять владельца и следующее действие.
Нечитаемый файл возвращается за новой копией. Неизвестный товар требует сопоставления специалистом. Расхождение с заказом направляется владельцу операции. Технический отказ загрузки остаётся у ответственного за обмен, если содержимое уже проверено.
В карточке исключения нужны причина, необходимые сведения, ответственный и состояние. После исправления запускаются затронутые проверки, а не просто снимается красный значок.
Для первой версии разумно сохранить подтверждение сотрудником перед передачей каждого документа. Позже можно отдельно рассмотреть автоматический маршрут для устойчивых, проверенных сценариев. Его границы должны быть явными и обратимыми.
Готовый сервис или собственный процесс
Готовое распознавание стоит оценивать на ваших обезличенных документах: хороших сканах, фотографиях, разных макетах и сложных исключениях. Демонстрация одного идеального файла не показывает пригодность решения.
Собственная разработка чаще нужна вокруг распознавания: для связи с заказами, проверки справочников, интерфейса исправлений и управляемой передачи в целевую систему. Создавать собственный механизм OCR с нуля требуется далеко не каждому проекту.
Сравнивайте варианты по полному рабочему пути. Материал о приёмке внутренней системы поможет перевести впечатления от демонстрации в проверяемые сценарии.
Оценивайте нагрузку на проверяющего
Скорость извлечения символов мало говорит о пользе всего процесса. На пробном наборе наблюдайте, сколько действий требуется сотруднику до подтверждения документа: открыть оригинал, найти поле, исправить значение, сопоставить позицию и повторить проверку.
Если оператор вынужден сверять весь документ из-за непонятных подсказок, автоматизация лишь добавила ещё один экран. В интерфейсе должны быть заметны причины внимания, а не только общий показатель качества.
Разбирайте повторяющиеся исправления отдельно. Одни указывают на плохое качество входящих файлов, другие — на недостаточный справочник или ошибочное правило извлечения. Исправлять эти причины должны разные владельцы процесса.
Что подготовить для первой версии
Соберите небольшой разнородный набор обезличенных образцов и эталонные значения, подтверждённые специалистом. Добавьте документ с дублем, неизвестной позицией, неверной арифметикой и отказом загрузки.
Проверяйте не только правильность извлечения, но и возможность заметить ошибку, исправить её, повторить проверку и восстановить историю передачи. В конце каждого сценария должно быть понятно, где находится документ и кто отвечает за следующий шаг.
С ExtentLab можно обсудить такой процесс на конкретных образцах. Начать полезно с одного вида документа и одной целевой операции: это позволит отделить возможности распознавания от необходимой заказной логики.