Планирование производства: как ИИ-агент в 1С:ERP пересобирает график после сбоя

Производственная компания планировала работу цехов в 1С:ERP (ERP, Enterprise Resource Planning — управление ресурсами предприятия): производственный блок системы был внедрён и работал не первый год. Там жили спецификации и маршрутные карты, рабочие центры с их доступностью, заказы на производство, план выпуска и загрузка оборудования. Данные были, маршруты описаны, нормативы времени заведены. Но сам график после сбоя — встал станок, не пришла партия материала, вклинился срочный заказ — собирал человек: диспетчер обходил участки или обзванивал мастеров, сводил факт с планом в Excel, пересчитывал загрузку и согласовывал перестановку с начальником цеха и снабжением. Новая версия графика появлялась в системе только в конце этой цепочки, а до тех пор поток шёл без действительного плана. Ниже — что делает поверх 1С:ERP ИИ-агент (программа, которая по заданному правилу сама читает данные систем, сопоставляет их и выполняет шаги), какие риски он снимает и сколько часов это возвращает.

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

Это не история одного завода, а общая точка роста. По обзору рынка российского программного обеспечения, который подготовили S+Consulting и Ассоциация КП ПО, в 2024 году системы управления производственными процессами (MES, Manufacturing Execution System) использовали 52% промышленных компаний, а объём рынка этих систем составил около 15 млрд ₽ при среднегодовом росте порядка 15%. Системы планирования предприятия в том же обзоре оценены в 100 млрд ₽, и 70% этого рынка принадлежит 1С. Проще говоря, учётная система есть почти везде, а вот момент, когда отклонение превращается в новое решение, всё ещё держится на человеке.

Коротко

ИИ-агент читает план выпуска, загрузку рабочих центров и факт по операциям из 1С:ERP, а после сбоя пересчитывает варианты и приносит диспетчеру готовый разбор: что сдвинется, на какие сроки и где узкое место. Решение и оформление новой версии графика остаются за человеком. Часы и деньги здесь следствие, а не цель.

Содержание

• Почему пересборка графика видна поздно
• Что съедает время между сбоем и решением
• Что делает ИИ-агент поверх 1С:ERP
• Какие риски это снимает
• Сколько часов это возвращает
• Что остаётся за человеком
• Как это выглядит на практике
• Как внедрить поэтапно
• Источники

Почему пересборка графика видна поздно

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

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

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

Причина третья — эффект никто не измеряет. Загрузку оборудования принято считать через OEE (Overall Equipment Effectiveness — общая эффективность оборудования): показатель складывается из доступности, производительности и качества. Пока эти три составляющие собираются постфактум за месяц, улучшать приходится то, что видно в отчёте, а не то, что ломается в смене. Зарубежная практика даёт ориентир и по самому процессу перепланирования: по описанию задач планирования производства в отраслевом каталоге AI for Manufacturing, ручная пересборка графика после сбоя — будь то поломка станка, срочный заказ или задержка материала — занимает часы, тогда как автоматический контур пересчёта укладывается в минуты. Разрыв в скорости здесь и есть предмет разбора.

Масштаб задачи видно и по рынку. По исследованию Axenix и TAdviser о российском рынке систем управления производством, конкуренция среди разработчиков высокая — на рынке представлены более 60 отечественных систем, — но предприятия при выборе новой платформы по-прежнему ориентируются на поэтапные проекты и стартуют с отдельных участков. Инструмент купить можно, а порядок в процессе — нет.

Отдельная часть картины — прогноз, на котором стоит график. Если план выпуска собран под спрос, который не подтвердился, сбоев становится больше: партии переставляют чаще, оснастку готовят не под ту номенклатуру, склад получает не то, что уходит первым. Как эта связка работает на данных о спросе, мы разбирали в материале про прогнозирование спроса в 1С и WMS. Поясним термин: WMS (Warehouse Management System) — система управления складом, где живут остатки, приёмка и отгрузка.

Что съедает время между сбоем и решением

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

1. Заметить сбой. Информация приходит от мастера, наладчика или оператора: станок встал, материал не привезли, партия не прошла проверку. Это звонок или сообщение, а не отметка в системе.
2. Собрать факт. Нужно понять, какие операции по этому рабочему центру реально закрыты, какая партия на нём стоит, что уже готово к следующему переходу. Данные берутся из выгрузки, из журнала смены и со слов людей.
3. Пересчитать загрузку. Освободившийся центр — это возможность поднять другой заказ. Надо найти те операции, которые можно переставить, и проверить, что по ним есть материал, оснастка и исполнитель нужного разряда.
4. Согласовать. Перестановка затрагивает снабжение, начальника цеха и продажи: клиенту обещан срок, склад ждёт партию. Каждое изменение — это звонок и договорённость.
5. Оформить. Новая версия графика попадает в систему, но только после того, как решение принято. До этого момента в 1С:ERP стоит прежний план, и любой, кто посмотрит на него, увидит неправду.
6. Забыть. Итог решения обычно нигде не сохраняется: почему переставили именно так, кто подтвердил, что при этом отодвинули. В следующий сбой этот опыт пригодился бы, но его нет.

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

Что делает ИИ-агент поверх 1С:ERP

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

1. Читает план и нормативы. Берёт из 1С:ERP маршрутные карты, спецификации, состав заказов на производство, доступность рабочих центров и плановые сроки. Это исходные данные, которые никто вручную не переписывает.
2. Читает факт. Подтягивает отметки о выполнении операций, данные сканирования и терминалов, сведения о ремонтах оборудования и журналы смен. Если по операции факта нет, это фиксируется как пробел, а не додумывается.
3. Находит событие, которое сломало график. Поломка центра, отсутствие материала, срыв по качеству, срочный заказ — агент определяет, какие операции встали и какие центры при этом освободились.
4. Считает варианты перестановки. Перебирает 3–5 сценариев с учётом доступности центра, материала, оснастки и исполнителя, и для каждого показывает срок выхода заказа, загрузку участка и то, что придётся отодвинуть.
5. Показывает цену каждого варианта. Не «график пересобран», а список сдвинутых заказов и дата, до которой решение нужно принять, иначе срок уедет дальше.
6. Готовит черновики сообщений. Текст для снабжения, для начальника цеха, строка для планёрки: что произошло, что предлагается, что требуется подтвердить.
7. Пишет журнал решений. Фиксирует, какой вариант выбрал человек, когда и почему — по каждому сбою. Через месяц из этого журнала видно, какие рабочие центры ломают график чаще остальных.

Важно, что агент ничего не переписывает в системе. Он читает 1С:ERP, считает и возвращает результат в виде разбора. Новая версия графика появляется только после того, как её подтвердил человек и оформил в системе.

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

Чем это отличается от автоматического планирования

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

Где здесь узкое место

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

Какие риски это снимает

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

Срыв срока поставки и неустойка по договору

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

Простой рабочего центра, который мог работать

Когда один центр встал, соседние не обязательно загружены полностью. Освободившийся ресурс — это возможность поднять другую партию, но найти её нужно быстро и с проверкой материала и оснастки. Пока цифры сводят в Excel, окно закрывается: подходящий заказ уходит на следующий день. Ручная пересборка съедает часы работы не только диспетчера, но и оборудования: по описанию задач планирования в отраслевом каталоге AI for Manufacturing, производители, применяющие автоматический пересчёт, сообщают о росте загрузки оборудования на 10–20% и сокращении времени переналадки на 20–40% — эффект здесь берётся именно из того, что освободившийся ресурс используется сразу.

Незавершённое производство, в котором заморожены деньги

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

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

Пересборка графика «к утру» — это вечерняя работа диспетчера и переговоры в нерабочее время. Когда сбоев несколько в неделю, это превращается в регулярную переработку, за которую платят по повышенной ставке, а качество решения падает: уставший человек выбирает первый приемлемый вариант, а не лучший. Агент снимает рутину перебора, оставляя человеку выбор.

Зависимость от одного человека

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

Потеря управляемости и разговор «на глаз»

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

Сколько часов это возвращает

Часы — уже следствие, а не цель. Но они считаются, и вот как. Возьмём типовой расчёт для одного участка: график на 120–150 операций, сбои, требующие пересборки, происходят около 12 раз в месяц — примерно три в неделю. Это не пиковый сценарий, а обычный режим мелкосерийного производства с несколькими участками.

Ручная пересборка после одного сбоя раскладывается так: собрать факт по звонкам и выгрузкам — около 20 минут, найти и проверить варианты перестановки в Excel с учётом материала и оснастки — около 40 минут, согласовать с начальником цеха и снабжением — около 30 минут. Итого — примерно 90 минут на один сбой. Эта цифра совпадает с тем, что мы видели в измеренном кейсе пересборки графика: там ручная пересборка занимала те же 90 минут, а после внедрения агента на модели через программный интерфейс сократилась до 3 минут — разбор этого случая с загрузкой станков и цифрами вынесен в отдельный материал про планирование производства в 1С:ERP. Для расчёта ниже мы берём более осторожную оценку — 8 минут: пересборка с подтверждением человеком и оформлением в системе.

Агент считает иначе: сбор факта из 1С:ERP и источников участка — секунды, перебор вариантов с проверкой ограничений — минуты, подготовка разбора и черновиков сообщений — минуты. На выходе — готовый разбор, который человек проверяет и подтверждает. На подтверждение и правку уходит около 8 минут вместо 90.

Показатель	Вручную	С агентом
Время на пересборку графика после одного сбоя	около 90 минут	около 8 минут
Кто собирает факт по операциям	диспетчер по звонкам и выгрузкам	агент из 1С:ERP и данных участка
Сколько вариантов перестановки проверяется	один-два, из опыта	три-пять, с пересчётом загрузки
Что остаётся человеку	весь расчёт и согласование	выбор варианта и оформление графика
Сбоев в месяц на участке	около 12	около 12
Часов на пересборку в месяц	около 18 часов	около 1,6 часа

Арифметика открытая. Экономия на одном сбое — около 82 минут, то есть примерно 1,4 часа. При 12 сбоях в месяц это около 17 часов в месяц на одном участке. Если час работы планировщика стоит 1 200 ₽ (это ориентир, а не замер по рынку: подставьте свою ставку), получается около 20 000 ₽ в месяц на участке. На двух участках — порядка 40 000 ₽, на трёх — около 60 000 ₽ в месяц. В расчёте нет ни стоимости простоя оборудования, ни цены сдвинутого срока отгрузки: они считаются отдельно и в большинстве случаев весят больше, чем время диспетчера.

Для сравнения — отраслевые ориентиры по эффекту автоматического планирования, а не по экономии часов диспетчера. По данным отраслевого каталога AI for Manufacturing, производители с автоматическим пересчётом сообщают об улучшении поставок в срок на 15–30% и о снижении времени переналадки на 20–40%. По обзору консалтинговой компании Startup House, типичная европейская фабрика тратит около 60% времени планировочной команды на «тушение пожаров» — ручную пересборку линий, поиск материалов и объяснение задержек продажам, — а внедрение ИИ снижает время планирования примерно на 40% и поднимает уровень поставок в срок с 92–94% до 97–99% за 12–18 месяцев. Здесь важно, что это зарубежные данные: по российской практике публичных замеров по этому процессу мало, и подставлять их вместо своих цифр нельзя — свой замер нужно делать на первом контуре.

Что остаётся за человеком

Границы здесь не формальность, а условие работоспособности схемы.

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

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

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

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

Как внедрить поэтапно

1. Описать один процесс. Выбрать один участок и один сценарий: пересборка графика после сбоя. Зафиксировать, как это происходит сейчас, кто участвует и сколько занимает времени.
2. Договориться о числах. Определить четыре метрики до старта: доля заказов в срок, время между сбоем и решением, доля отклонений, найденных до планёрки, и доля операций с расхождением факта в системе и в цехе.
3. Собрать данные. Проверить, откуда агент будет брать факт по операциям, и что именно из этого реально заполняется. Пробелы в данных лучше найти до запуска, а не после.
4. Задать правила. Что агенту разрешено предлагать, что запрещено, какие решения всегда идут человеку. Это набор правил, а не настройка «на глаз».
5. Запустить первый контур. Ограниченный участок, один процесс, режим подсказок: агент считает и приносит разбор, диспетчер решает как обычно. Сравнить время и качество решений с прежним порядком.
6. Расширять после подтверждения. Если числа сошлись — подключать следующие участки и процессы: контроль выполнения операций, загрузку оборудования, отклонения по качеству. Если числа не сошлись, расширение только размножит проблему.

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

Что в итоге

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

Источники

• Российский рынок ПО в 2024 году: доля промышленных компаний, использующих системы управления производственными процессами, и объём рынка — novostiitkanala.ru (обзор S+Consulting и Ассоциации КП ПО)
• Российский рынок систем управления производством: число отечественных решений и переход от пилотных проектов к масштабированию — novostiitkanala.ru (исследование Axenix и TAdviser)
• Использование цифровых технологий крупными и средними организациями России в 2025 году: распространённость продвинутых производственных технологий — itrn.ru (данные ИСИЭЗ НИУ ВШЭ по обследованию Росстата)
• Скорость автоматического пересчёта графика после сбоя и эффект по поставкам в срок, загрузке оборудования и переналадке — aiformanufacturing.org
• Доля времени планировочной команды, уходящая на ручную пересборку, и ориентиры по времени планирования и поставкам в срок — startup-house.com
• Время, которое уходит на ручное планирование производства, по оценке вендора — productionplannerpro.com (данные вендора)