ИИ для планирования производства: разбор отклонений без автоперепланирования

Может ли ИИ составлять производственный план?

Лучше отделить три действия: ERP/MRP фиксирует план и исходные события; приложение выбирает подозрительные отклонения по явным правилам; языковая модель готовит объяснение для диспетчера. Перепланирование остаётся штатной операцией системы и человека. На странице 1С:ERP описаны собственные диагностика ограничений размещения этапа, изменение графика и оповещения о критических отклонениях s1. Эти функции уже принадлежат 1С:ERP: предложенный здесь помощник не выполняет их за систему и не подключён к ней автоматически.

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

Какие данные нужны для разбора отклонения?

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

В качестве примера различий полей документация Odoo 18.0 описывает фильтры Delayed Productions, Late и Late Availability: задержка начала, окончание после дедлайна и недоступность нужного компонента до дедлайна не одно и то же s2. Там же отдельно оговорено, что дедлайн заказа и плановая дата окончания различаются s2. Не копируйте эти названия как универсальные поля 1С. В отчёте Odoo Production Analysis есть, в частности, Quantity Demanded, Quantity Produced и длительность операций s3. В 1С:ERP механизм диагностики этапа показывает ограничения, повлиявшие на размещение заказа s1. Для любого стека нужна согласованная карта полей, а не свободный текст «производство отстаёт».

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

Как собрать локальный контур без права менять план?

Один кандидат для проверки текста, а не «лучшая модель для завода», — Qwen3-8B: в закреплённой карточке разработчик заявляет мультиязычность и указывает apache-2.0; качество на русских заказах и производственных сокращениях этим не подтверждено s5. Для локального API можно рассмотреть Ollama: каталог содержит тег qwen3:8b и команду ollama run qwen3:8b s6. Это отдельный дистрибутив: не считайте его конкретный файл побайтово идентичным файлу HF и отдельно проверьте условия выбранной упаковки. Размер файла весов не служит расчётом минимальной RAM/VRAM; выбор железа требует конкретного кванта, длины карточки и собственной проверки памяти.

Архитектура пилота — однонаправленная выгрузка только разрешённых полей из ERP в отдельное приложение, без учётных данных на запись, команд изменения графика, закупки материалов и отправки сообщений. Это предложение по ограничению прав, не штатная интеграция 1С/Odoo. Если нельзя подтвердить, кто читает выгрузку и куда идут сетевые запросы, используйте только синтетические данные и проверьте контур до работы с реальными заказами. Локальный адрес Ollama сам по себе не доказывает изоляцию всей цепочки.

Для ответа задайте JSON Schema с полями order_id, plan_version, observations[], source_field, source_timestamp, risk_type, unknowns[], proposed_check — не new_schedule и не approve. Документация Ollama показывает передачу JSON Schema через format и валидацию ответа кодом приложения s4. Валидный JSON означает только соблюдение формы: независимо проверьте, что order_id, значения и даты в ответе точно присутствуют в выгрузке. Пример структурированного вывода поможет настроить техническую проверку.

Как проверять объяснение и защищаться от ошибок?

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

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

План проверки: соберите обезличенные исторические случаи с известным исходом, в том числе с пропущенной датой, неверной единицей, старым планом и противоречащими записями. До запуска определите, сколько ложных объяснений критично, какую долю рисков эксперт должен обнаружить и сколько времени занимает ручная сверка. Сравните объяснение с диспетчерским разбором тех же заказов; сохраняйте версию выгрузки, модель/тег, настройки и ошибки. NIST AI RMF Measure 2.1 рекомендует документировать тестовые наборы, метрики и инструменты оценки s8. Никакого порога «достаточно точно для производства» он за вас не устанавливает.

Когда оставить только штатные средства ERP?

Если нужны детерминированное перепланирование, учёт ограничений оборудования и гарантированный расчёт графика, начните со штатного механизма ERP/MES и специалиста по планированию: 1С:ERP уже описывает свои инструменты перепланирования и диспетчирования s1. Модель полезна только там, где её объяснение можно быстрее сверить и исправить по исходным записям. Если это не доказано на ваших случаях, дополнительный ИИ-слой не нужен.

Следующий шаг: соберите две обезличенные карточки заказа — одну с подтверждённым отклонением, другую с пропущенным полем — и задайте схему проверяемого ответа. Диспетчер вручную сверяет каждое объяснение, исходное поле и время обновления с ERP; до этого момента график не меняется.