Кейс - производство

Document AI для контроля качества

Европейский промышленный производитель заменил ручную обработку документов контроля качества от поставщиков на Document AI. 78% документов проходят сквозную автоматическую обработку по более чем 30 шаблонам поставщиков, а проект окупился за 8 месяцев.

Исходная точка

Европейский промышленный производитель прецизионных компонентов для автомобильной, авиационной отраслей и промышленного машиностроения: около 1400 сотрудников на трёх производственных площадках. Сырьё и входящие компоненты приходили с документацией качества от поставщика: сертификаты соответствия, протоколы состава материала, отчёты о размерном контроле и записи о корректирующих действиях, если в прошлых поставках были отклонения. Каждую неделю поступало около 1200 таких документов, распределённых более чем по 30 шаблонам поставщиков - от чистых структурированных PDF до сканов устаревших форм.

Пятеро техников контроля качества обрабатывали каждый документ вручную: извлекали ключевые поля, сверяли их со спецификацией из заказа на закупку, помечали отклонения и заносили структурированные данные в ERP. Этот процесс был узким местом при выпуске компонентов в производство. Руководитель качества хотел проверить, способен ли Document AI взять на себя рутинные случаи и оставить техникам работу с настоящими отклонениями.

В чём была сложность

Предельная неоднородность документов

Более 30 шаблонов поставщиков без общей схемы. Часть - чистые структурированные PDF от крупных поставщиков, другая часть - сканы устаревших форм от мелких, иногда с правками от руки. Универсальный подход «OCR плюс языковая модель» рисковал дать тихие ошибки извлечения именно на устаревших шаблонах.

Плотная интеграция с ERP

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

Инженерные силы внутри

У ИТ-команды производителя был сильный опыт в ERP и интеграциях, но почти никакого - в AI и машинном обучении. Модель работы должна была передать достаточно знаний, чтобы команда могла поддерживать и расширять систему после передачи, а не получить чёрный ящик.

Как применялась методология

Общая длительность работы: 16 недель на этапы 1-3 плюс расширенное сопровождение на этапе 4 для поддержки внутренней команды на период разработки и стабилизации.

Этап 1 - обследование (2 недели)

В объём вошёл только процесс документов качества от поставщиков, без внутренних документов качества: у них другое управление и другие потребители. Базовая метрика: обработанных документов на техника в день, на старте около 48. Классификация риска: ограниченный риск по EU AI Act. Заметное решение по объёму на этом этапе: документы о корректирующих действиях были выведены из первой итерации, потому что они запускают договорные обязательства дальше по цепочке и были признаны слишком рискованными для первого внедрения.

Этап 2 - архитектура (3 недели)

Гибридный конвейер извлечения: структурированные шаблоны, около 12 из 30, направлялись в детерминированный экстрактор полей. Неструктурированные и устаревшие шаблоны шли в Document AI, то есть OCR плюс языковая модель со структурированной схемой вывода. Для каждого поля считалась оценка уверенности, и документ, в котором хотя бы одно поле опускалось ниже настраиваемого порога, попадал в очередь ручной проверки вместо записи в ERP. Интеграция шла через staging-таблицы ERP, где и применялись правила валидации: неудачная валидация отбраковывала весь документ в ручную обработку.

Этап 3 - проектирование управления (2 недели, параллельно этапу 2)

Внедрён базовый набор из 12 контролей. Заметные решения: откат был сделан флагом конфигурации для каждого поставщика отдельно, чтобы можно было вернуть конкретного поставщика на ручную обработку, не выключая систему целиком, если его шаблон неожиданно изменился. Мониторинг фиксировал точность извлечения по поставщику и по полю, с недельными отчётами о дрейфе. Ответственность была закреплена поимённо за руководителем качества, эскалация - на ИТ-директора.

Этап 4 - сопровождение внедрения (9 недель)

Разработку целиком вела внутренняя команда, а Slavin AI проводила недельные архитектурные ревью, давала замечания на уровне кода по проверкам управления и вела совместные проектные сессии по более сложным схемам извлечения. Две проверки управления: первая на 4-й неделе (точность извлечения против эталонного набора), вторая на 7-й (интеграция с ERP и проверка откатов). Команда сознательно решила подключать поставщиков волнами по 5-6 шаблонов, а не все 30 сразу: первая волна проверила архитектуру конвейера, последующие шли быстрее.

Измерено относительно базовой линии

Сквозная автоматическая обработка

78% входящих документов обрабатывались без участия человека. Остальные 22% попадали в очередь ручной проверки - из-за низкой уверенности по какому-то полю или потому, что шаблон ещё не был подключён.

Перераспределение людей в контроле качества

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

Точность извлечения на уровне поля

От 96% до 99% по каждой паре «поставщик - шаблон» в стабильном режиме. Поставщики, опускавшиеся ниже 95%, проверялись на изменения шаблона и возвращались на ручную обработку до повторного подключения.

Срок окупаемости

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

Задержка в производстве

Снизилась в среднем с 26 часов до менее 4 часов для компонентов с рутинной документацией качества. Для компонентов, требующих ручной инспекции качества, срок не изменился.

Качество передачи

Полная операционная передача на шестом месяце. Продолжение работы со Slavin AI для поддержки не потребовалось. За шесть месяцев после передачи команда самостоятельно подключила ещё 4 шаблона поставщиков.

Что сделали бы иначе

Волны подключения должны быть меньше, быстрее и чаще

Первые волны подключения поставщиков по 5-6 шаблонов оказались слишком крупными: часть шаблонов в волне была заметно сложнее остальных и тормозила всю волну. В следующих проектах: 2-3 шаблона в волне, больше волн, более высокий темп.

Вернуть документы о корректирующих действиях в объём раньше

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

Флаги конфигурации по поставщику были главным архитектурным решением

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

Другие проекты

Финансовые услуги - помощник комплаенс-офицера

Инвестиционная компания среднего размера, AI-помощник для комплаенс-офицеров, рост пропускной способности проверок в 3,1 раза с атрибуцией источников аудиторского уровня.

Читать кейс

Методология

Четырёхэтапная модель работы, по которой шёл этот проект.

К странице методологии

Планируете AI-инициативу на производстве?

Архитектурное ревью определяет процесс с наибольшим рычагом, решения о выводе из объёма и ограничения интеграции, которые зададут форму разработки.