Как настроить data capture: от документов до записи в ERP/CRM
Автоматизация ввода данных (data capture) — это настройка процесса, который превращает письма, PDF и сканы в проверенные структурированные поля и автоматически записывает их в ERP/CRM/ECM. Работает не «сам OCR», а связка: извлечение → валидация → сверка со справочниками → интеграция → разбор исключений.
Цель data capture — убрать ручной ввод, а не «убрать человека»: оператор нужен точечно, только там, где низкая уверенность или конфликт правил.
Оглавление
Где data capture дает быстрый эффект
Начинайте с процессов, где есть объем, повторяемость и понятная цена ошибки:
- счета/акты/УПД: номер, дата, поставщик, суммы, НДС, договор/заказ;
- входящие заявки (почта/формы): ФИО, контакты, тема, вложения;
- логистика: накладные, номера отправлений, даты, получатель;
- HR-рутина: заявления и анкеты (при строгих правах доступа).
Быстрый пилот — это один процесс «конец-в-конец»: получили документ → извлекли поля → проверили → создали запись в системе → приложили оригинал.
Что выбрать: OCR, IDP, RPA и LLM
OCR отвечает на вопрос «какой текст на картинке/скане». Этого мало, потому что бизнесу нужны поля (сумма к оплате, ИНН, дата), а не просто распознанный текст.
IDP (intelligent document processing) добавляет «понимание документа»: классификацию, извлечение полей, нормализацию (даты/валюты), уверенность (confidence) и маршрут на проверку.
RPA полезна, если нет API и нужно «занести данные как пользователь» через интерфейс легаси-системы: открыть карточку, заполнить поля, нажать кнопки, приложить файл.
LLM/GenAI уместны как усилитель на слабоструктурированных входах (письма, свободный текст, “грязный” OCR), но результат обязательно фиксируйте правилами и проверками.
Не делайте LLM «источником истины». Истина — это валидации, справочники, контрольные суммы и журналирование; LLM помогает разбирать исключения и приводить данные к нужной схеме.
Как устроить контур: схема, контракт данных, валидации
Минимальный рабочий pipeline:
- прием (почта/скан/папка/портал) → 2) подготовка (чистка, поворот, разбиение страниц) → 3) классификация → 4) OCR → 5) извлечение полей (IDP/правила/ML) → 6) нормализация → 7) валидация → 8) человек-в-контуре для спорного → 9) интеграция в ERP/CRM → 10) мониторинг.
Ключевой артефакт — data contract (схема целевых полей). Пример для счета: supplier_name, supplier_tax_id, invoice_number, invoice_date, total_amount, vat_amount, currency, po_number. Сразу договоритесь:
- какие поля обязательны;
- что считать «не найдено» (null + причина);
- какие поля критичные (класс A), важные (B), желательные (C).
Валидации, которые окупаются почти всегда:
- проверка форматов (дата/валюта/ИНН/КПП);
- контроль сумм (итого, НДС, скидки — по вашим правилам);
- сверка контрагента со справочником (включая неточное совпадение + подтверждение);
- дедупликация (один и тот же документ/номер/сумма).
Внедрение и метрики, чтобы качество росло
План внедрения без лишней «теории»:
- зафиксируйте KPI (скорость, стоимость, ошибки по критичным полям);
- выберите 1 тип документов и 1 систему-приемник;
- соберите набор реальных документов, включая плохие сканы и исключения;
- настройте извлечение + валидации до интеграции;
- запустите поток с human-in-the-loop;
- включите журналирование (версия правил/модели, confidence, кто исправил и почему);
- масштабируйте: новые шаблоны, новые источники, расширение схемы.
Метрики для управления data capture
| Метрика | Как считать | Что улучшает |
|---|---|---|
| STP-rate | авто / всего | долю «безручной» обработки |
| Accuracy A-полей | совпадения по полям класса A | риск ошибок в деньгах/реквизитах |
| Exception rate | в ручную / всего | нагрузку на операторов |
| Cycle time | медиана и перцентили | узкие места процесса |
| Cost per doc | затраты / количество | экономику проекта |
Частые ошибки
- Автоматизируют «распознавание», а не бизнес-процесс (в итоге данные не доходят до учетной системы).
- Нет контракта данных: непонятно, какие поля обязательны и что делать при пропуске.
- Сразу целятся в 100% STP и игнорируют исключения (дубликаты, сторно, нестандартные формы).
- Нет сверки со справочниками и контрольных проверок, из-за чего ошибки «красиво» уезжают в ERP/CRM.
- Не измеряют качество после запуска: сменился шаблон — точность упала, а никто не заметил.
FAQ
Можно ли автоматизировать ввод данных полностью?
Да, но обычно только для узкого набора стабильных документов. Реалистичная цель: высокий STP на типовых входах + быстрый разбор исключений.
Что важнее: IDP или RPA?
IDP извлекает и проверяет поля из документов, RPA переносит данные в системы без API. В практике часто нужны оба: IDP «понимает документ», RPA/интеграция «доставляет данные».
С чего начать, если документы очень разные?
С классификации и одного «денежного» процесса (например, счета). Параллельно улучшайте вход: требования к сканам, единые правила отправки, обязательные поля в формах.