MES и ERP: разделение ответственности и схема данных цеха

Зачем вообще разделять MES и ERP в цехе

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

Когда MES и ERP начинают вести одно и то же, появляется двойной учет. В одной системе заказ уже «выполнен», а в другой еще «в работе». Или наоборот: в ERP списали материалы по норме, а в цехе реально ушло больше из-за переналадки. На уровне отчетов это выглядит как небольшая неточность, но на уровне управления быстро превращается в конфликт между производством, планированием и финансами.

Обычно боль проявляется в трех местах:

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

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

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

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

Если вы работаете с системным интегратором, заранее договоритесь о границах и словаре данных. В проектах для производственных организаций в Казахстане это особенно важно: так учет, цех и поддержка быстрее сходятся в единую схему, и 24/7 сервис поддерживает процесс, а не «чинит отчеты».

Роли MES и ERP простыми словами

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

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

В ERP обычно оставляют то, что должно быть единым для всей компании:

• заказы клиентов и производственные заказы на уровне изделия
• плановые сроки и объемы, плановые маршруты как норматив
• закупки, склады, финансы, затраты, начисления в учете
• нормативно-справочные данные (номенклатура, единицы измерения, счета учета)

MES берет на себя то, что меняется каждую минуту на площадке и важно для управления сменой:

• диспетчеризацию: очередь работ по оборудованию и бригадам
• фактические операции: старт, стоп, количество, брак, передел
• фактическое потребление материалов и выпуск полуфабрикатов
• события цеха: простои, причины, измерения, контроль качества по точкам

Ключевая граница, которую стоит утвердить до интеграции, звучит просто: «кто хозяин факта». Если факт родился в MES (выпуск, брак, время, простой), ERP не должна «исправлять» его задним числом. Она должна принять факт и отразить его в учете.

Небольшой пример. ERP запланировала на сегодня 100 штук и рассчитала потребность в материалах. В реальности станок встал на 40 минут, смена выпустила 92, из них 3 ушли в брак. Это не «ошибка плана», это факт производства. MES фиксирует событие и результат, а ERP на основе факта пересчитывает остатки, затраты и выполнение плана.

Такое MES и ERP разделение ответственности лучше закрепить отдельным документом (RACI или регламент). Иначе интеграция превращается в бесконечные «почему цифры не совпали» вместо управления производством.

Матрица ответственности по объектам данных (кто владелец)

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

Ниже практичная матрица: кто создает и утверждает, а кто использует и фиксирует факт.

Чтобы это работало без споров между ИТ и производством, заранее закрепите правила управления данными:

• Один владелец на объект и один канал изменений (без ручных правок «в обход» интеграции).
• Версионность для BOM и маршрутов, чтобы факт всегда привязывался к конкретной версии.
• Права: ERP утверждает норматив и финальные бизнес-статусы, MES фиксирует факт и отклонения.
• Протокол расхождений: что делать, если в MES операция выполнена, а в ERP заказ еще не выпущен.
• Единые справочники причин брака, простоев и отклонений.

Пример из цеха: технолог меняет норму расхода материала. Изменение утверждается в ERP и уходит в MES как новая версия спецификации. MES на ее основе фиксирует фактическую выдачу и перерасход с причиной (например, «переналадка»), а ERP считает себестоимость и отклонения плана от факта.

Сквозной процесс: от плана в ERP до факта в MES

Сквозной процесс работает устойчиво, когда ERP отвечает за «что и когда нужно сделать» и «как это отразится в деньгах», а MES - за «как именно это сделали в цехе». Так проще удержать единую логику: план живет в ERP, факт фиксируется на месте в MES.

Старт обычно происходит в ERP. Там появляется потребность: заказ клиента, прогноз или внутренний заказ. ERP проверяет запасы и закупки, доступность мощностей на уровне календаря и выпускает производственные заказы. Здесь важны сроки, приоритеты, спецификации изделия (BOM), маршрут (операции) и плановые нормы.

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

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

• ERP -> MES: производственный заказ, операции, нормы времени, плановые количества, сроки, назначенные ресурсы (если есть)
• MES фиксирует: запуск/завершение операций, учет простоев, фактический выпуск, брак, переработки, фактическое время и исполнителей
• MES -> ERP: подтверждение выпуска и движений (выпуск/полуфабрикаты), списания материалов, трудозатраты, отклонения от норм, статусы заказа

Во время исполнения MES фиксирует реальность. Например: в смене запустили 100 штук, сделали 92 годных и 8 брака; был простой 35 минут из-за переналадки; материал заменили на аналог по согласованному правилу. Эти детали критичны для анализа причин и улучшений, но в ERP обычно хранятся в свернутом виде.

Возврат факта в ERP нужен для финансовой части: закрыть этапы, отразить выпуск на складе, списать материалы, посчитать себестоимость и увидеть отклонения. Хорошая практика - возвращать в ERP агрегированный факт по операции или по смене, а детальную историю оставлять в MES.

Мини-сценарий: ERP выпустил заказ на 500 рабочих станций на неделю, а MES по сменам показал, что на одном участке упали скорости из-за дефицита компонента. MES вернул отклонение и фактическую производительность, ERP пересчитал сроки и влияние на себестоимость. План и факт остаются согласованными, но каждый в своем контуре.

Схема данных: какие сущности живут в ERP, а какие в MES

Чтобы MES и ERP не спорили за одну и ту же «правду», заранее фиксируют владельца каждой сущности. Простой принцип: ERP хранит то, что нужно для планирования, учета и денег, а MES - то, что происходит на линии по минутам и событиям. Это и есть MES и ERP разделение ответственности на уровне данных.

Базовые справочники и «кто главный»

Справочники часто общие, но лучше назначить мастер-систему и вторичную копию.

Обычно в ERP держат мастер-данные: номенклатуру (код, единицы, учетные характеристики), структуру изделия (BOM), нормативы и учетные разрезы. MES получает эти данные для исполнения и детализации в цехе.

MES может быть мастером для «цеховых» справочников, где важны частые изменения: рабочие центры с реальными параметрами (доступность, ограничения), оснастка, сменные бригады, причины простоев. При этом ERP хранит укрупненные версии для отчетов.

Плановые сущности в ERP, фактические в MES

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

MES хранит фактическое выполнение: события запуска и окончания операций, статусы (работает, простой, наладка), фактические времена, фактический выпуск, потребление материалов «как было», разрез по партиям/серийникам и по рабочим местам.

Качество почти всегда удобнее вести в MES, потому что оно привязано к моменту и месту: результаты контроля, дефекты, причины, блокировки партии, корректирующие действия. В ERP обычно уходит итог: годно/негодно, количество брака, списания и финансовые последствия.

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

ERP (план)                         MES (факт)
-------------------------------    -------------------------------
ProductionOrder (OrderID)   -->    Dispatch/WorkOrder (OrderID)
Operation (OrderID+OpNo)    -->    OperationExecution (OrderID+OpNo)
Item (ItemID)               -->    MaterialConsumption/Production (ItemID)
WorkCenter (WCID)           -->    Machine/Line (WCID)
Batch/Lot (LotID)           -->    Traceability/Quality (LotID)

Пример: ERP создает заказ на 1 000 корпусов и планирует 3 операции. MES по этому OrderID фиксирует, что в смене №2 была наладка 18 минут, выпуск 920 годных, 30 в брак с причиной «повреждение кромки», и списывает фактический материал. ERP принимает итоги, считает отклонения и отражает их в себестоимости и отчетности.

Интеграции и обмен: что, когда и в каком виде передавать

Хорошая интеграция MES ERP держится на одном правиле: ERP задает «что и когда надо сделать» и считает деньги, а MES фиксирует «как реально сделали» на уровне операций, людей, станков, партий и серий.

Что идет из ERP в MES

Из ERP в MES обычно уходит все, что описывает план и нормативы, чтобы цех работал по единой версии данных и не гадал, «как правильно».

• Производственные заказы: номер, изделие, количество, сроки, приоритет, склад/цех назначения
• Маршруты и операции: последовательность, рабочие центры, допустимые альтернативы, правила переналадки
• Спецификации (BOM) и версии: состав, замены, коэффициенты, дата вступления в силу
• Нормы и допуски: плановые времена, нормы расхода, контрольные характеристики, правила выборочного контроля
• Ограничения и документы: статус разрешения к производству, требования по качеству и прослеживаемости (партии, серийные номера)

Важно договориться, что MES не правит маршрут и спецификацию, а использует опубликованную ERP версию. Если нужно отклонение, MES фиксирует причину, а норматив меняется в ERP как новая версия с датой начала.

Что возвращает MES в ERP

Обратно в ERP должны возвращаться факты, достаточные для учета, себестоимости, складов и выполнения заказа клиента. Подробная телеметрия станков может оставаться в MES, а в ERP идти агрегаты и движения.

• Выпуск: количество годного, полуфабрикатов, по партиям/сериям, с привязкой к заказу и операциям
• Брак и переделка: количество, коды причин, где возник, что списали, что отправили на передел
• Потребление материалов: фактическое списание, замены, возвраты, привязка к партиям и серийникам при необходимости
• Трудозатраты и время оборудования: фактические часы, смена, бригада, простой с причиной (если влияет на учет)
• Статусы исполнения: «запущено», «в работе», «частично выполнено», «выполнено», «остановлено», плюс дата-время событий

Чтобы данные «склеивались», нужны единые идентификаторы: коды номенклатуры, единицы измерения, рабочие центры, а также сквозные ссылки на производственный заказ и операцию. Для партий и серийных номеров заранее определите, кто их выдает: часто партия материала рождается в ERP/складе, а серийный номер изделия присваивает MES при сборке.

По частоте обмена обычно так: статусы и ключевые факты (запуск, выпуск, списание) лучше отправлять онлайн событиями через API/шину сообщений, а расширенную отчетность (свод по смене, детализация простоев) можно передавать пакетно по расписанию.

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

Как внедрять по шагам, чтобы не остановить производство

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

Базовое правило простое: ERP хранит план и деньги, MES хранит факт выполнения. Дальше по объектам (заказ, операция, материал, партия, брак, простой) фиксируйте, где источник, а где копия.

Пошаговый подход

Надежнее идти небольшими контурами, каждый из которых дает пользу и не ломает текущую работу:

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

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

Как снизить риск на старте

Выберите одну линию или один тип продукции и отработайте на нем полный цикл. Например, ERP создает заказ на 100 изделий, MES фиксирует по сменам выпуск 60/40 и причины отклонений (переналадка, ожидание материала). ERP получает итог выпуска и отклонения по срокам, а MES хранит детализацию по операциям и событиям.

Критично договориться о «праве правки»: факт в MES не редактируется задним числом без причины и следа, а план в ERP меняется только через понятную процедуру. Тогда внедрение идет без остановок и без потери доверия к цифрам.

Пример сценария: один заказ, план в ERP и факт в MES

Представим заказ на 20 изделий, которые собираются из 5 компонентов (корпус, плата, кабель, крепеж, упаковка). Есть входной контроль комплектующих и финальный контроль качества. Смысл разделения простой: ERP отвечает за план и деньги, MES - за реальное выполнение в цехе. Это и есть MES и ERP разделение ответственности на практике.

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

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

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

Чтобы ERP могло посчитать себестоимость и сделать отчеты, из MES обычно уходит ограниченный набор фактов:

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

Разбор отклонений начинается с сравнения план vs факт. ERP видит: план был 20, на склад поступило 18 годных, 2 в браке; материалы списаны с перерасходом по кабелю; трудозатраты выше из-за 40 минут простоя. MES дает расшифровку по операциям и причинам, ERP переводит это в деньги: себестоимость партии, потери от брака, влияние простоев на выполнение сроков. MES объясняет, что произошло, ERP отвечает, сколько это стоило и что планировать дальше.

Частые ошибки и ловушки при разделении ответственности

Самая частая проблема в проектах MES и ERP не в интерфейсах, а в границах: кто за что отвечает и кто прав, когда цифры не сходятся. Если это не зафиксировать в правилах и данных, система начинает «спорить сама с собой».

Когда справочники размножаются и никто не главный

Обычно все начинается безобидно: в MES заводят свои материалы, операции, рабочие центры, потому что «так быстрее». Параллельно те же объекты живут в ERP. Через пару месяцев появляются разные названия, разные единицы измерения, разные нормы, и интеграция превращается в ручные правки.

Практичное правило: у каждого справочника должен быть один владелец (ERP или MES) и понятный регламент изменений (кто создает, кто согласует, как обновление попадает во вторую систему, что делать с историей).

Двойной учет себестоимости и «две правды»

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

Рабочая договоренность такая: MES отдает факты (выпуск, списания, время, брак) в нужной детализации, а ERP превращает это в деньги по правилам учета.

Вот что чаще всего ломает разделение ответственности на практике:

• Нет единого идентификатора партии/серии: в MES одно, в ERP другое, прослеживаемость рвется на приемке или отгрузке.
• Обмен слишком редкий: ERP живет вчерашним планом, а факт из MES приходит, когда уже поздно реагировать.
• Нет процедуры сверки: расхождения копятся до конца месяца, и потом их «чинят» вручную.
• События в MES фиксируются поздно: оператор вводит факт в конце смены, а диспетчер весь день смотрит на неверную картину.
• Изменения в нормах и маршрутах проходят «в обход»: план в ERP уже другой, а MES продолжает работать по старой версии.

Хороший контрольный пример: ERP выпустила производственный заказ на 100 единиц с партией P-001. В MES реально сделали 98, 2 ушли в брак, и был заменен материал по согласованию. Если партия и причины отклонений оформлены по-разному, в конце периода вы получите: в ERP «выпуск 100», в MES «выпуск 98» и спор, кто ошибся.

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

Быстрый чеклист и следующие шаги

Чтобы MES и ERP разделение ответственности работало в реальном цехе, договоритесь не только о «кто что делает», но и о том, кто владеет какими данными и какие события считаются фактом. Иначе системы превращаются в спорный справочник вместо опоры для управления.

Перед стартом интеграции проверьте базовые вещи:

• Назначены владельцы данных по доменам: НСИ (материалы, изделия, операции), заказы и план, качество, складские движения, финансы и себестоимость.
• Определен минимальный набор событий из MES, которые фиксируют реальность: старт и завершение операции, выпуск годного, брак, простой, списание материалов, перемещение партии.
• Введены единые идентификаторы и они «живут» во всех системах: заказ, операция/переход, партия, серийный номер (если нужен), рабочий центр.
• Согласована частота обмена: что идет онлайн (например, критичные статусы), а что пакетом (например, закрытие смены). Отдельно описаны правила повторной отправки и дедупликации.
• Описан сценарий ошибок: что делать при недоступности ERP или MES, где хранится очередь сообщений, кто и как разбирает расхождения.

Понятный признак, что вы на верном пути: диспетчер видит в MES «что реально происходит сейчас», а экономист в ERP получает «что это значит для денег и отчетности» без ручных таблиц.

Дальше полезно двигаться небольшими шагами, чтобы не остановить производство:

• Выберите один поток или участок и ограничьте интеграцию 3-5 ключевыми событиями (например, выпуск, брак, списание, статус операции).
• Проведите инвентаризацию инфраструктуры: где будет контур MES, где интеграционный слой, какие требования к отказоустойчивости и журналированию.
• Зафиксируйте «эталон» НСИ и правила изменений (кто заводит, кто утверждает, как обновления попадают в другую систему).
• Протестируйте сверку факта: один заказ, одна партия, одна смена. Добейтесь совпадения по количеству и статусам до расширения.
• Если нужен проект «под ключ», заранее оцените контур: серверы для MES и интеграции, рабочие места в цеху, регламент поддержки. В Казахстане такие задачи часто закрывают вместе с системными интеграторами вроде GSE.kz, особенно когда важны локальная инфраструктура и сопровождение.