Галактика ERP: планирование, качество и простои с ИИ-агентом

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

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

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

Коротко: что добавляет ИИ-агент к Галактика ERP

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

Содержание

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

Что такое Галактика ERP и какие процессы в ней живут

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

В производственном контуре система опирается на стандарт MRP-II (Manufacturing Resource Planning — планирование ресурсов производства) и включает следующие блоки:

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

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

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

Где граница системы: учёт есть, решения нет

Галактика ERP отвечает на вопросы «что заказано», «какие нормы», «сколько материалов нужно», «какие затраты сложились». Она точно фиксирует факт: сколько изготовлено, сколько ушло в брак по документам, сколько времени оборудование стояло.

Чего система по своей природе не делает — и не должна:

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

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

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

Типовой круг ручной работы на среднем производстве выглядит так:

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

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

Что делает ИИ-агент поверх Галактика ERP

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

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

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

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

Риски идут первыми, потому что они и есть предмет разговора: часы и деньги — уже следствие. Формулировки ниже — не «снижение рисков вообще», а конкретные сценарии.

Срыв сроков по заказу и санкции по договору

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

Брак, который находят у заказчика, а не в цехе

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

Простой, который растягивается на полсмены

Компания Siemens опубликовала оценку потерь от незапланированных остановок: у участников исследования предприятие теряет в среднем 27 часов в месяц из-за незапланированных простоев, а среднее время восстановления выросло с 49 минут до 81 минуты за пять лет — то есть ждать стали реже, но чиниться дольше. Причина, по мнению авторов отчёта, не в оборудовании, а в знаниях: опыт ушёл вместе с людьми. Агент не ремонтирует станок, но передаёт наладчику историю: что делали в прошлый раз, какая деталь отказывала, кто и когда это закрыл.

Незакрытая смена и спор о причинах

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

Перегрузка одних переделов при простое других

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

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

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

Ошибки в отчётности и выводах

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

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

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

Показатель	Вручную	С агентом
Пересборка графика после сбоя (20 сбоев × 90 и 10 минут)	30 часов	3,5 часа
Разбор сменных отчётов по качеству (60 отчётов × 25 и 4 минуты)	25 часов	4 часа
Сбор причин простоев (30 записей × 20 и 3 минуты)	10 часов	1,5 часа
Итого в месяц на площадке	65 часов	9 часов

Расчёт в минутах: 20 сбоев × 90 минут = 1 800 минут, то есть 30 часов; 60 отчётов × 25 минут = 1 500 минут, то есть 25 часов; 30 записей × 20 минут = 600 минут, то есть 10 часов. С агентом остаётся проверка выводов: 20 × 10 минут, 60 × 4 минуты и 30 × 3 минуты — около 9 часов.

Высвобождается примерно 56 часов в месяц на одной площадке. При оценке стоимости часа в 1 000 рублей это около 56 000 рублей в месяц; на трёх цехах одного предприятия — порядка 168 000 рублей. Часы — уже следствие снятых рисков: главный эффект в том, что решение по сбою принимается в первые минуты, а не в конце смены.

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

Расчёт эффекта на вашем объёме

Модель собирается из четырёх чисел, которые у вас уже есть:

1. Объём операций в месяц. Сколько раз в месяц пересобирается график, сколько сменных отчётов по качеству проверяется, сколько записей о простоях закрывается.
2. Минуты на операцию. Сколько времени занимает одна такая операция вручную и сколько занимает проверка вывода агента.
3. Число сотрудников, у которых это в работе. Диспетчер, технологи, мастера — и сколько их времени реально уходит на эти операции, а не на управление производством.
4. Стоимость часа. Полная стоимость часа с учётом взносов и накладных, по данным вашей учётной системы.

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

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

• Утверждение графика. Агент предлагает вариант, планово-диспетчерский отдел утверждает. Решение о переносе заказа и приоритете клиента — управленческое.
• Остановка производства и решение по браку. Остановить линию, вернуть ли партию на передел, списать ли сырьё — решает мастер и технолог. Агент только готовит основание.
• Работа с людьми и оборудованием. Наладка, ремонт, обучение, дисциплина смен — за людьми. Агент не отдаёт команды станкам и не пишет в технологические карты.
• Ответственность перед заказчиком. Подтверждение сроков и обоснование переноса — за руководителем, а не за программой.
• Настройка правил. Какие отклонения считать значимыми, от какого порога поднимать сигнал — задаёт человек.
• Данные. Качество входных данных остаётся зоной ответственности компании: агент читает то, что записано в системе.

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

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

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

Чеклист перед стартом

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

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

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

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

1. Аудит данных. Смотрим, что реально есть в системе: заказы, спецификации, сменные отчёты, журнал простоев, ремонты. Фиксируем, чего не хватает для сценария.
2. Замер ручной работы. Считаем по вашим числам, сколько часов в месяц уходит на пересборку графика, разбор качества и сводку простоев. Здесь же считаем бесплатный разбор стратегии внедрения ИИ.
3. Один процесс, один цех. Берём самый частый сценарий — обычно пересборку графика после сбоя — и делаем его на данных одного цеха.
4. Правила и границы. Формулируем, что агент делает сам, где требуется подтверждение и от какого порога поднимается сигнал.
5. Пилот на смене. Агент работает параллельно с привычным порядком: диспетчер видит и ручной вариант, и предложение агента. Сравниваем, где вывод точнее.
6. Тиражирование и метрики. Расширяем на качество и простои, переносим на другие цеха, ведём ежемесячный отчёт по метрикам.

Чем измеряется эффект

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

Что в итоге

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

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

Источники

• Средние потери предприятия от незапланированных простоев — 27 часов в месяц (против 39 часов в 2019 году) и 326 часов в год; среднее время восстановления производства после остановки выросло с 49 до 81 минуты, что авторы объясняют разрывом в знаниях после ухода опытных специалистов; совокупные потери 500 крупнейших компаний мира — 1,4 трлн долларов в год, или 11% выручки: The True Cost of Downtime 2024 — Siemens (181 интервью со специалистами по обслуживанию и ИТ на промышленных предприятиях, данные за апрель 2019 — март 2023).
• Разбор отчёта Siemens по промышленным отраслям с разбивкой стоимости потерянного часа и выводом о смещении инвестиций от предотвращения отказов к сокращению времени восстановления: Cost of Unplanned Downtime per Hour (2024 Data) — VSight (разбор данных Siemens, не вендорская оценка эффекта продукта).
• В крупных и средних российских организациях технологии ИИ применяют 5,2% (на 0,4 п.п. больше, чем годом ранее), в компаниях с численностью более 500 человек — 17%; 51,1% организаций отметили повышение качества и эффективности производственных процессов; среди барьеров называют высокие затраты (54%), недостаточность и качество данных (34%) и нехватку квалифицированных кадров (33%): Крупный бизнес наиболее активно внедряет ИИ — ИСИЭЗ НИУ ВШЭ по данным сплошных обследований Росстата, 2025–2026.
• В 2024 году рынок систем автоматизации в России вырос почти наполовину и превысил 120 млрд рублей; отечественные решения занимают порядка 50–70% (ранее 30–40%); доля России в мировых затратах на промышленное программное обеспечение с ИИ — 1,3%, что соответствует примерно 88 млн долларов (около 7 млрд рублей); в 2025 году рынок цифровых решений растёт на 15–20% в год: Обзор «Цифровизация промышленности в России 2025» — TAdviser (данные вендоров и экспертов рынка).
• Состав производственного контура системы: планирование производства до цехового уровня по стандарту MRP-II, спецификации продуктов и маршрутные карты, управление заказами, материально-техническое обеспечение, управление производственной логистикой, техническое обслуживание и ремонт оборудования, контроллинг, корпоративное производственное планирование; внесение продукта в Единый реестр российского программного обеспечения: Галактика ERP — АО «Корпорация Галактика» (данные вендора).

Смежные материалы по производству: планирование производства и пересборка графика, кейс планирования с загрузкой станков, информационные системы управления производством, диспетчеризация и производственный учёт в SCADA и MES, MES «ИндаСофт» на данных I-DS, контроль качества, входной контроль и рекламации, простои, смены и брак, ИИ в машиностроении, что автоматизирует ИИ-агент поверх систем, внедрение ИИ-агентов от аудита до сопровождения.