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

Источник: https://modelium.tech/zhurnal/ii-dlya-planirovaniya-proizvodstva/

Для планирования производства ИИ разумно сначала использовать как помощника по разбору отклонений: он готовит объяснение из проверяемых полей заказа, дат и обеспеченности материалами. План и приоритеты остаются в ERP/MRP; диспетчер сверяет каждое объяснение с исходными записями и принимает решение сам. Описанная схема — проект пилота, а не измеренное улучшение сроков или готовая интеграция с 1С.

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

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

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

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

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

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

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

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

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

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

Архитектура пилота — однонаправленная *выгрузка только разрешённых полей* из ERP в отдельное приложение, без учётных данных на запись, команд изменения графика, закупки материалов и отправки сообщений. Это предложение по ограничению прав, не штатная интеграция 1С/Odoo. Если нельзя подтвердить, кто читает выгрузку и куда идут сетевые запросы, используйте только синтетические данные и [проверьте контур](/zhurnal/proverka-offline-kontura-ii/) до работы с реальными заказами. Локальный адрес 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](#src-s4). Валидный JSON означает только соблюдение формы: независимо проверьте, что `order_id`, значения и даты в ответе точно присутствуют в выгрузке. [Пример структурированного вывода](/zhurnal/structured-output-lokalno-json-schema/) поможет настроить техническую проверку.

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

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

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

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

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

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

**Следующий шаг:** соберите две обезличенные карточки заказа — одну с подтверждённым отклонением, другую с пропущенным полем — и [задайте схему проверяемого ответа](/zhurnal/structured-output-lokalno-json-schema/). Диспетчер вручную сверяет каждое объяснение, исходное поле и время обновления с ERP; до этого момента график не меняется.

## Источники

1. [1С — управление производством в 1С:ERP](https://v8.1c.ru/erp/production/) — получено 2026-09-26
2. [Odoo 18.0 — Delays in manufacturing](https://www.odoo.com/documentation/18.0/applications/inventory_and_mrp/manufacturing/reporting/delayed.html) — получено 2026-09-26
3. [Odoo 18.0 — Production analysis](https://www.odoo.com/documentation/18.0/applications/inventory_and_mrp/manufacturing/reporting/production_analysis.html) — получено 2026-09-26
4. [Ollama — Structured Outputs](https://docs.ollama.com/capabilities/structured-outputs) — получено 2026-09-26
5. [Qwen — Qwen3-8B model card, fixed revision](https://huggingface.co/Qwen/Qwen3-8B/resolve/b968826d9c46dd6066d109eabc6255188de91218/README.md) — получено 2026-09-26
6. [Ollama — каталог qwen3:8b](https://ollama.com/library/qwen3:8b) — получено 2026-09-26
7. [OWASP — LLM01 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) — получено 2026-09-26
8. [NIST — AI RMF Core, Measure 2.1](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) — получено 2026-09-26