Как ИИ-агент отслеживает партии

27 сентября 2026

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

Короткий ответ: ИИ-агент помогает восстановить путь конкретной партии от приёмки сырья до отгрузки готового изделия. Он связывает номера партий, операции, оборудование, исполнителей, результаты контроля и документы в единую цепочку, замечает разрывы и просит человека подтвердить спорный переход. Агент не решает, безопасна ли продукция, не придумывает отсутствующие сведения и не заменяет обязательные процедуры. Его практическая задача — быстро собрать проверяемые факты, не смешать разные статусы и сократить время расследования или отзыва.

Прослеживаемость часто сводят к маркировке: нанесли код, записали номер в ERP — значит, всё под контролем. Но код полезен только тогда, когда по нему можно ответить на конкретные вопросы. Из какого сырья изготовлена деталь? На каком оборудовании и в какую смену прошла операция? Какие результаты контроля относятся именно к ней? В какие заказы вошла партия? Кому уже отгружена продукция? Какие единицы нужно остановить, если обнаружено отклонение?

Ответы обычно лежат в разных местах: ERP, MES, WMS, QMS, лабораторной системе, журналах оборудования, файлах и сменных записях. ИИ-агент выступает координатором между этими источниками. Он не создаёт ещё одну «главную таблицу», которую придётся вручную поддерживать, а собирает цепочку событий вокруг устойчивого идентификатора и показывает, где есть доказательство, а где его не хватает.

Где прослеживаемость ломается

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

Вот типовые проблемы:

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

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

Что делает ИИ-агент

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

В рабочем контуре агент может:

• сопоставить внешние и внутренние идентификаторы партии;
• связать сырьё, полуфабрикат и готовую продукцию отношениями «из чего произведено»;
• обнаружить пропущенное сканирование между двумя операциями;
• проверить, что использовались актуальный маршрут и нужная версия технологической инструкции;
• получить фактическое время операции и идентификатор оборудования из MES или журнала станка;
• привязать пробу, измерение и решение контролёра к нужной партии;
• остановить автоматический переход, если доказательство отсутствует или противоречит другому источнику;
• построить прямую цепочку от сырья к отгрузкам и обратную — от изделия к его происхождению;
• подготовить предварительные границы отзыва и список затронутых заказов;
• сохранить, кто подтвердил исключение, на каком основании и когда.

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

Прямой и обратный маршрут партии

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

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

Агент строит оба маршрута на одной модели связей. Это важно: отдельный отчёт «сырьё — выпуск» и отдельный отчёт «серийный номер — операции» могут показывать разные границы. Настоящая проверка проходит от начала до конца и обратно без ручного соединения выгрузок. Если обратный путь не приводит к тем же исходным партиям, которые видны в прямом маршруте, цепочка считается неполной.

Сценарий: партия сырья разделена между тремя заказами

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

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

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

Такой подход уменьшает избыточную блокировку. Компания изолирует доказанно связанные и неопределённые единицы, а не останавливает весь месячный выпуск. При этом неопределённая ветка не считается безопасной: по ней назначают ручную проверку с владельцем и сроком.

Сценарий: смешение компонентов

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

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

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

Сценарий: жалоба клиента и локальный отзыв

Клиент сообщает о трещине в корпусе и называет серийный номер. Сотрудник качества открывает карточку случая. Агент связывает номер с партией готовой продукции, производственным заказом, операцией мехобработки, партией заготовок и результатами контроля.

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

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

Какие данные нужны

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

Минимальный набор сущностей выглядит так:

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

Для каждого поля назначают главный источник. ERP отвечает за заказы и движение стоимости, MES — за операции, WMS — за физические перемещения, QMS и LIMS — за контроль. Это распределение нужно зафиксировать до запуска: агент не должен выбирать «более удобную» цифру из двух систем. Если источники расходятся, он регистрирует конфликт и направляет его владельцу данных.

Интеграция с ERP, MES, WMS и QMS

В ERP агент получает заказы, партии, списания и отгрузки. В MES — маршрут, операции, оборудование и фактические параметры. В WMS — контейнеры, ячейки и перемещения. В QMS или LIMS — планы контроля, пробы, результаты и решения.

Интеграцию лучше строить через события и разрешённые API, а не через прямое редактирование баз. Например, событие «контейнер выдан на заказ» содержит идентификатор контейнера, заказ, количество, время и пользователя. Агент проверяет его и связывает с общей цепочкой. Если следующая система временно недоступна, событие попадает в очередь, а процесс получает видимый статус ожидания. После восстановления связи запись обрабатывается повторно без потери первоначального времени.

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

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

Контрольные правила и исключения

Полезный агент не просто отвечает на вопросы. Он постоянно проверяет базовые правила процесса. Например:

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

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

Полезно разделить как минимум три состояния: «связь подтверждена», «связь опровергнута» и «данных недостаточно». Если оставить только варианты «да» и «нет», неопределённость быстро превратится в ложное подтверждение. Для расследования это особенно опасно: зелёный статус будет выглядеть убедительно, хотя за ним нет исходной записи.

Безопасность и ответственность

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

Все действия агента журналируются: что он прочитал, какое правило сработало, кому отправлена задача и какое изменение предложено. Источник каждого факта должен открываться из карточки. Если запись исправили, предыдущая версия остаётся в истории вместе с автором, временем и причиной изменения.

Особое ограничение касается выводов модели. Текстовый комментарий может подсказать гипотезу, но не подтверждает происхождение партии. Критические решения опираются на идентификаторы, утверждённые правила и подтверждение человека. При отсутствии данных честный ответ звучит так: «На этом участке цепочка не доказана». Это не сбой агента, а полезный результат, который показывает реальный риск процесса.

Как внедрить: план на шесть шагов

1. Выбрать один маршрут

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

2. Нарисовать генеалогию партии

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

3. Проверить данные на контрольной выборке

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

4. Запустить агента в режиме наблюдения

Сначала агент ничего не блокирует. Он собирает события, находит разрывы и сравнивает свой вывод с проверкой специалиста. Такой режим показывает ложные срабатывания, задержки обмена и реальные проблемы интеграции без риска остановить производство.

5. Подключить безопасные действия

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

6. Провести учебный отзыв

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

Метрики пилота

Эффект оценивают не количеством ответов агента, а качеством процесса:

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

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

Частые ошибки

Начать с распознавания документов

Извлечь номер партии из сертификата полезно, но это только один шаг. Без связи с физическим контейнером, приходом и дальнейшим расходом прослеживаемость не появляется. Распознанное поле должно пройти проверку и попасть в управляемую цепочку.

Использовать название вместо идентификатора

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

Автоматически закрывать пробелы

Вероятная связь опасна именно потому, что выглядит убедительно. Неопределённость нужно показывать отдельным статусом и направлять человеку. Автоматическое решение допустимо только там, где правило однозначно, проверяемо и заранее утверждено.

Оцифровать старый хаос без владельцев

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

Не проверить реальный отзыв

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

Практический чек-лист

Перед запуском убедитесь, что:

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

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

FAQ

Чем ИИ-агент отличается от обычного отчёта по партиям?

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

Можно ли запустить прослеживаемость без MES?

Да, если для пилотного маршрута есть устойчивые идентификаторы и достоверные события из ERP, WMS, оборудования или форм операторов. Но ручные источники нужно контролировать, а переход к критическому статусу — подтверждать. Отсутствие MES повышает требования к дисциплине регистрации операций, но не делает пилот невозможным.

Может ли агент сам определить границы отзыва?

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

Что делать со старыми партиями без полной истории?

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

С какого процесса лучше начать пилот?

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

Сколько времени нужно на первый результат?

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

Что произойдёт, если одна из систем временно недоступна?

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

Как понять, что агенту можно разрешить автоматические действия?

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