Планирование производства: кейс — ИИ-агент на LLM поднял загрузку станков с 58% до 74% и сократил пересборку графика с 90 минут до 3

Название компании и часть цифр изменены по договорённости о конфиденциальности — бизнес-модель, отрасль и порядок величин сохранены.

К нам обратилась производственная компания из металлообработки — оборот около 380 млн рублей в год, 140 сотрудников, три цеха: заготовительный, механическая обработка, сборка. Формальный запрос звучал широко: «у нас всё работает, но постоянно что-то горит, хотим автоматизацию». За полтора месяца диагностики узкое место оказалось одно — планирование производства.

Содержание

• С чем пришла компания
• Что показала диагностика
• Почему эта проблема типична для производств
• Решение: ИИ-агент диспетчера на LLM поверх 1С:ERP
• Команда, сроки и стоимость
• Как внедряли: этапы и трудности
• Результаты через 4 месяца
• Что не так с термином «ИИ» в этом кейсе
• Рекомендации: как не наступить на те же грабли
• Что дальше

С чем пришла компания

У клиента уже стояла 1С:ERP — система вела учёт материалов, заказы клиентов, себестоимость. Формально план производства в ней тоже был: диспетчер вручную расставлял заказы в очередь на основе своего опыта и звонков от начальников цехов. На практике график перестраивался вручную по 3-4 раза в день, потому что менялись приоритеты, обнаруживалась нехватка заготовок или ломался станок.

Директор описывал ситуацию так: «Мы вроде всё видим в системе, но реальная картина в цехе — в голове у диспетчера и двух мастеров. Как только один из них в отпуске, начинается хаос».

Что показала диагностика

Мы подняли данные из 1С:ERP за 6 месяцев и сопоставили их с фактическим временем выполнения заказов, зафиксированным на терминалах в цехах. Разрыв оказался существенным.

Загрузка ключевого оборудования — пяти станков механической обработки, через которые проходило 70% заказов — держалась на уровне 58%. При этом паспортная и разумно достижимая загрузка для этого парка составляла 80-85%. Разница объяснялась не поломками и не нехваткой заказов, а простоями в ожидании решения диспетчера: какой заказ ставить следующим, если приоритеты каждый час меняются, а видимости по остаткам заготовок у диспетчера нет.

Второй показатель — доля заказов, отгруженных с опозданием больше двух дней. За полгода она составила 23%. Для B2B-клиентов с контрактной неустойкой это означало прямые потери, которые в финансовой отчётности были размазаны по статье «прочие расходы» и никто их отдельно не считал.

Третье — время на пересборку графика при форс-мажоре (поломка станка, брак партии, срочный заказ). Диспетчер тратил на это от 40 минут до полутора часов, в течение которых цех фактически работал по старому плану, который уже не соответствовал реальности.

Почему эта проблема типична для производств

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

Это системная проблема, а не следствие плохой работы конкретных людей: большинство ERP-систем, включая 1С:ERP, хранят все нужные данные — остатки, заказы, техкарты, — но не пересчитывают оптимальную очередь автоматически при каждом изменении. Пересчёт вручную требует времени, поэтому диспетчер работает эвристиками, а не расчётом.

Масштаб проблемы измерен и в отрасли. В опросе Siemens («The True Cost of Downtime 2024», крупные производственные компании) площадка теряет в среднем 27 часов в месяц и 326 часов в год на незапланированных простоях, а стоимость каждого часа простоя с 2019 года выросла минимум на 50% — при том что число самих инцидентов снизилось. По оценке Aberdeen Research, которую приводит Reliable Magazine, час незапланированного простоя в промышленности стоит в среднем около 260 тыс. долларов, а в автомобильной отрасли — более 2,3 млн долларов. Существенная часть этих потерь приходит не от поломок, а от ожидания решения: какой заказ ставить следующим.

Решение: ИИ-агент диспетчера на LLM поверх 1С:ERP

Полная замена ERP клиенту была не нужна и экономически не оправдана — данные в 1С:ERP были в порядке, проблема была в слое принятия решений над ними и в интерфейсе, через который человек этот слой трогает. Мы предложили не отдельный экран с графиками, а ИИ-агента: диспетчер работает с производством через чат на естественном языке, а агент на LLM сам решает, какие данные поднять и какой инструмент вызвать, чтобы ответить или пересчитать план.

Технически это выглядит так. В основе — LLM с поддержкой function calling (вызова инструментов), которой доступны три инструмента: чтение данных 1С:ERP (заказы, остатки, техкарты — через OData, раз в 5 минут), решатель на основе constraint programming, который считает допустимую очерёдность с учётом ограничений по станкам, сменам и материалам, и запись обратно в 1С:ERP и на терминалы сбора данных (ТСД) в цехах. Диспетчер пишет или говорит агенту: «что с загрузкой на завтра», «сдвинь заказ 1123 на четверг, материалов пока нет», «станок 4 сломался, пересобери план» — агент разбирает намерение, вызывает нужный инструмент, получает результат и отвечает понятным языком, а не сырыми цифрами.

Здесь принципиально важно не путать, кто что считает. Расчёт очереди — это не LLM. Языковой модели нельзя доверить арифметику комбинаторной оптимизации: она может «правдоподобно» предложить график, который на самом деле физически невыполним, потому что LLM генерирует наиболее правдоподобный по форме ответ, а не гарантированно корректный расчёт. Поэтому в архитектуре есть жёсткое правило: агент не имеет права показать диспетчеру план, который не прошёл через решатель. Любое предложение по графику — это вызов инструмента, а не текст, придуманный моделью. LLM отвечает за две вещи, где она объективно сильна: понять неструктурированный запрос человека (текст, голос, обрывочная фраза о поломке) и объяснить результат расчёта простым языком, включая обоснование — почему станок сдвинут, а не просто «новый план готов».

Отдельно агент разбирает входящие заявки от отдела продаж: часть заказов приходила не в 1С:ERP, а свободным текстом в письмах и на бумажных техзаданиях, и раньше их вручную переносил менеджер, теряя 10-15 минут на заказ и иногда ошибаясь в спецификации. Теперь агент сам структурирует такую заявку и регистрирует заказ в 1С:ERP, а менеджер только подтверждает результат.

Из-за требований клиента по конфиденциальности производственных данных (номенклатура, объёмы, контрагенты) API внешних провайдеров не рассматривали — модель развернули в контуре клиента: open-weight LLM уровня 30-70 млрд параметров через локальный инференс-сервер, без выхода данных за периметр завода. Это медленнее и дороже в эксплуатации, чем облачный API, но было условием, без которого проект не согласовали бы со службой безопасности клиента.

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

Команда, сроки и стоимость

Со стороны интегратора в проекте были заняты архитектор решения (проектировал границы между агентом, решателем и 1С:ERP), backend-разработчик, отвечавший за инструменты и интеграцию с OData, и ML/AI-инженер, который занимался развёртыванием LLM в контуре клиента, промптами и — что заняло больше всего времени — набором тестовых диалогов (eval-датасетом), на котором проверяли, не пытается ли агент выдать план без вызова решателя. Со стороны клиента — главный технолог, штатный специалист по 1С и служба информационной безопасности, без согласования которой самостоятельный хостинг модели был бы невозможен.

Бюджет проекта — в диапазоне 3-4 млн рублей, включая инфраструктуру для локального инференса LLM, работы по интеграции инструментов и настройке под номенклатуру клиента. Это выше, чем стоил бы просто модуль-решатель без агентного слоя — разница ушла на GPU-сервер для локальной модели и на тестирование агента, а не на саму LLM как таковую. При снижении штрафов по контрактам и высвобождении мощности, эквивалентной одному станку, проект окупился за 9 месяцев с момента запуска пилота — эту цифру клиент считал сам, по своей методике учёта, мы её только подтвердили на сверке.

Как внедряли: этапы и трудности

Внедрение заняло 4 месяца и шло в три этапа.

Первый месяц — пилот на одном участке, механической обработке, том самом узком месте. Мы настроили инструменты агента (чтение 1С:ERP, вызов решателя) и запустили его в режиме «советчика»: диспетчер общался с агентом в чате, видел рекомендованную очередь, но решения принимал сам. Это было осознанное решение — резко переключать цех на автоматические решения без доверия к системе со стороны диспетчера означало риск саботажа или игнорирования рекомендаций.

Главных трудностей на этом этапе было две. Первая — качество исходных данных: техкарты в 1С:ERP у трети номенклатуры были устаревшими, нормативное время операции не совпадало с фактическим на 15-30%. Решатель на таких данных давал нереалистичные рекомендации, и первые две недели ушли на сверку и актуализацию техкарт вместе с технологами клиента — без этого шага никакая автоматизация планирования работать не могла. Вторая трудность специфична именно для LLM-агента: в первые дни тестирования агент дважды сформулировал диспетчеру план «от себя», не дождавшись ответа решателя — по сути, красиво придумал правдоподобные цифры вместо расчёта. Оба случая поймал не диспетчер, а наш guardrail-слой, который на этапе тестирования прогонял тысячи синтетических диалогов и сверял каждый предложенный агентом план с фактическим вызовом решателя; после этого мы дополнительно ужесточили промпт и добавили жёсткую проверку в код — агент физически не может показать план, для которого не было вызова инструмента.

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

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

Результаты через 4 месяца

Загрузка ключевого оборудования выросла с 58% до 74% — на путь к целевым 80-85% компания вышла в течение следующих двух месяцев уже без нашего сопровождения. Доля заказов с опозданием больше двух дней снизилась с 23% до 9%. Время пересборки графика при форс-мажоре сократилось с 40-90 минут до 2-3 минут: диспетчер пишет агенту фразу о поломке, получает пересчитанный решателем план с объяснением и утверждает его в том же чате.

Отдельно мы отслеживали метрику именно для агентного слоя: долю ответов, где агент предложил бы диспетчеру план без реального вызова решателя. За весь месяц пилота guardrail-слой отфильтровал 12 таких попыток модели — до диспетчера они не дошли, но сам факт, что их пришлось ловить системно, а не полагаться на «модель же умная», — довод в пользу того, что закладывать проверку в архитектуру нужно с первого дня, а не после первого инцидента.

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

Что не так с термином «ИИ» в этом кейсе

Стоит сказать честно: в маркетинговых материалах это назвали бы «ИИ-агентом, который сам планирует производство», и звучит эффектно, но по сути это система с жёстким разделением труда между двумя разными технологиями. Решение о том, какой заказ пойдёт следующим на какой станок, принимает детерминированный решатель — это не LLM, и не должна быть LLM, потому что языковая модель не гарантирует, что предложенный ею график физически выполним: она заточена генерировать правдоподобный текст, а не проверенно корректный расчёт. LLM в этом кейсе — оркестратор и переводчик: она понимает, чего хочет диспетчер, решает, какой инструмент вызвать, и объясняет результат простым языком. Без guardrail-слоя, который физически блокирует показ плана без вызова решателя, агент рано или поздно «красиво соврёт» — как это дважды случилось у нас на тестировании, ещё до пилота.

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

Рекомендации: как не наступить на те же грабли

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

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

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

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

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

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

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

Что дальше

Следующий этап — добавить агенту ещё один инструмент: прогноз спроса на основе истории заказов, чтобы закупка заготовок планировалась не по факту нехватки, а на 3-4 недели вперёд, и диспетчер мог спросить агента напрямую «хватит ли металла под план на следующую неделю». Это должно закрыть оставшийся разрыв между планированием производства и планированием закупок, который сейчас остаётся ручным.

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

Источники

• Siemens, «The True Cost of Downtime 2024» (опрос крупных производственных компаний) — 27 часов простоев в месяц и 326 часов в год на площадку, рост стоимости часа простоя минимум на 50% к 2019 году: assets.new.siemens.com (PDF)
• Aberdeen Research в публикации Reliable Magazine — средняя стоимость часа незапланированного простоя в промышленности около 260 тыс. долларов, в автомобильной отрасли — более 2,3 млн долларов: reliamag.com
• «Что есть APS и почему он «тоже» не делает план производства» (Хабр) — почему расчёт плана остаётся задачей планировщика, а не диспетчера, и как эта граница выглядит в реальных проектах: habr.com/ru/articles/473074
• «Производственное планирование в 1С:ERP» (Первый Бит) — как в типовом 1С:ERP устроены графики производства и что остаётся ручным: 1cbit.ru

Частые вопросы

Инструмент для планирования выпуска: если план выпуска есть, а мощность цеха и факт живут отдельно, — есть готовый файл: шаблон план-графика выпуска продукции в Excel. Четыре листа: план по неделям, факт и выполнение, план в деньгах и загрузка производственных центров со статусами «резерв», «на пределе» и «перегруз».