ИИ-агент для управления сменой

3 октября 2026

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

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

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

Почему сменный план быстро теряет актуальность

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

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

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

ИИ-агент полезен именно как держатель общего контекста. Он не заменяет ERP, MES, APS или специализированный планировщик. Его задача — соединить формальный план, фактические события, производственные ограничения и решения людей в один управляемый процесс.

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

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

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

Получив новое событие, агент действует последовательно:

1. Проверяет источник, время и идентификаторы.
2. Находит затронутые заказы, партии, операции и ресурсы.
3. Сопоставляет факт с актуальной версией сменного плана.
4. Проверяет формальные ограничения и стоп-условия.
5. Оценивает влияние на следующие операции, очереди и сроки.
6. Готовит несколько допустимых вариантов с понятным описанием компромиссов.
7. Направляет запрос сотруднику с нужными полномочиями.
8. После подтверждения создаёт задачи и уведомляет участников.
9. Контролирует исполнение и фиксирует фактический результат.
10. Сохраняет причину изменения, использованные данные и автора решения.

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

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

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

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

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

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

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

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

Архитектура безопасного решения

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

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

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

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

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

Исполнительный сервис записывает подтверждённые изменения в ERP, MES и систему задач. Перед записью он повторно проверяет роль пользователя и актуальность исходных данных. В журнал попадают исходное событие, использованные сведения, предложенные варианты, решение человека и результат выполнения.

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

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

Сценарий 1. Аварийный простой оборудования

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

Вместо общего предупреждения диспетчер получает несколько вариантов:

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

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

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

Сценарий 2. Материал не готов к операции

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

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

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

Сценарий 3. Задержка предыдущей операции

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

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

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

Сценарий 4. Срочный заказ клиента

Коммерческая служба просит поставить новый заказ в начало очереди. Агент не выполняет просьбу напрямую. Сначала он проверяет:

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

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

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

Сценарий 5. Ограничение со стороны качества

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

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

Каким должен быть вариант перепланирования

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

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

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

Каждый вывод должен вести к первичным данным. Пользователь открывает заказ, событие простоя, складской статус или правило маршрута и проверяет основание. Фраза «модель считает этот вариант лучшим» ничего не доказывает.

Полезно также отделять факт от предположения. Например:

• факт: операция не завершена, последнее подтверждение получено из MES;
• расчёт: при текущем темпе завершение ожидается в заданном диапазоне;
• допущение: темп не снизится;
• решение: подтвердить последовательность должен диспетчер.

Такой формат снижает риск, что вероятностная оценка будет воспринята как гарантированное событие.

Роли и границы ответственности

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

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

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

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

Как внедрять агента по этапам

1. Выбрать узкий пилотный контур

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

2. Связать объекты и идентификаторы

Команда проверяет, можно ли однозначно сопоставить заказ, партию, операцию, ресурс, материал, оснастку и результат контроля. Одновременно назначаются владельцы справочников и определяется допустимая задержка каждого источника.

3. Формализовать правила

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

4. Запустить теневой режим

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

5. Разрешить задачи и подтверждения

Когда качество контекста стало приемлемым, агенту позволяют создавать задачи, собирать согласования и контролировать исполнение. Изменение плана по-прежнему подтверждает человек.

6. Автоматизировать только узкие действия

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

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

Как проверить пилот

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

Для каждого сценария проверяют:

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

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

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

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

Автоматизировать устные договорённости

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

Подменить планировщик языковой моделью

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

Игнорировать готовность операции

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

Считать любое отклонение аварией

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

Не учитывать цену переналадки

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

Не фиксировать основания решения

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

Слишком рано дать права на запись

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

Скрывать неопределённость

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

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

• Для каждого заказа определены партия, маршрут и актуальная версия документов.
• Операции связаны с конкретными ресурсами и разрешёнными альтернативами.
• Готовность включает материал, оснастку, программу, персонал и контроль.
• Статусы оборудования поступают вместе со временем обновления.
• Материалы из карантина исключены из доступных запасов.
• Приоритеты меняются только сотрудниками с подтверждёнными полномочиями.
• Сроки и загрузка рассчитываются детерминированно.
• Агент показывает источники, допущения и отсутствующие данные.
• Для каждого отклонения определены владелец и порядок реакции.
• Варианты содержат последствия для других заказов.
• Учитываются наладка, перемещения и дополнительные проверки.
• Оповещения по одному событию объединяются.
• Передача между сменами сохраняет причины и незавершённые действия.
• Все действия агента журналируются.
• Для записей предусмотрена отмена там, где она возможна.
• Есть ручной режим на случай недоступности модели или интеграции.
• Пилот проверен на поздних, повторных и неполных событиях.
• Метрики оценивают качество решений и производственный результат, а не активность чата.

FAQ

Заменит ли ИИ-агент производственного диспетчера?

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

Нужна ли APS-система для запуска?

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

Может ли агент сам менять очередь заказов?

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

Что делать, если часть данных ведётся вручную?

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

Как агент учитывает срочные заказы?

Он проверяет полномочия инициатора, готовность производства и последствия для действующего плана. После этого показывает варианты и затронутые сроки. Само слово «срочно» не должно автоматически менять очередь.

Как избежать лишних уведомлений?

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

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

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

Как понять, что пилот готов к расширению?

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