Настоящим узким отображением в программном обеспечении MES с низким кодом является не код.

Опрос 1560 руководителей производственных предприятий в 17 странах, проведенный компанией Rockwell Automation в июле 2026 года, показал, что 93% производителей уже используют программное обеспечение MES. Только 28% внедрили его в масштабах всего предприятия, и лишь 23% полностью интегрировали его с системами ERP, PLM, контроля качества и OT.

Это опрос поставщиков, а не независимое исследование, но его собственные данные подтверждают прочитанное. 44% считают интеграцию главным требованием при покупке MES-системы, 33% называют ее своей самой большой проблемой при интеграции данных.

«Внедрение MES больше не является препятствием, препятствием остается масштаб предприятия», — сказал Энтони Мерфи из Rockwell. Говиндараджу и Путра достигли того же результата десять лет назад, не имея никакого отношения к этому вопросу.

Функциональная интеграция — «самая сложная задача», как показало исследование, проведенное в 2016 году на металлургическом заводе в Бандунге. Проблема внедрения решена. Проблема интеграции — нет.

Системы управления производственными процессами были определены как конфигурируемые в 1997 году.

Системы MES с низким уровнем кодирования позиционируют себя как новые. Это не так. Компания MESA International определила категорию систем управления производством в сентябре 1997 года в Белой книге № 6: «Пользователи могут настраивать этот набор функций в соответствии со своими корпоративными и производственными целями».

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

Различия между отдельными установками никогда не были обнаружены как дефект при разработке программного обеспечения с использованием low-code. Это было связано со спецификацией, на основе которой MES поставлялась с самого начала.

Что на самом деле говорится в стандарте ISA-95 об уровне 3, и чего в нем не говорится.

В документе NIST GCR 19-022 (автор Леон МакГиннис из Технологического института Джорджии) объясняется, почему MES конфигурируется, а не поставляется в готовом виде. Ниже уровня 3 «управление состоит в выполнении предопределенных операций», и этот уровень уже «достаточно хорошо изучен».

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

Действительно ли в стандарте ISA-95 указано, что SCADA находится на 2-м уровне? На странице самого комитета, которую я привожу для этой статьи, SCADA и MES нигде не отнесены к какому-либо уровню. Стандарт описывается как интерфейс «между функциями управления и другими функциями предприятия», а именно уровнями 3 и 4.

NIST утверждает, что уровень 2, на широко цитируемой странице говорится об уровне 3, специалисты спорят об уровне 1 или 2, а сам стандарт ISA-95 не дает ответа ни на один из этих вопросов.

Узкое место находится на уровне машины, а не в конструкторе приложений.

Собственный показатель Rockwell — 93% внедрения против 23% интеграции — прямо указывает на необходимость интеграции машинных данных, что поддается измерению еще до оценки какой-либо отдельной функции MES.

Ким Берндред из компании On Time Edge делит каждый актив на две категории: машины категории 1 имеют встроенные средства подключения, такие как OPC или MTConnect, машины категории 2 — нет и нуждаются в шлюзе IIoT. По его словам, их следует учитывать «еще до того, как будет разработан план внедрения, и задолго до того, как будет определен график».

Исследователям из Технического университета Мюнхена потребовалось 989 строк кода для сбора данных на трех лабораторных машинах, только на уровне связи. В графике Dreher Consulting указано то же самое: 4-6 месяцев на разработку нового проекта, 9-15 месяцев на реконструкцию существующего, и даже собственный успешный проект Dreher с использованием low-code кода все равно занял 8 месяцев и потребовал 1,5 штатных технических специалистов.

Технология low-code сжимает прикладную часть проекта программного обеспечения для автоматизации производства, оставляя при этом нетронутой часть, отвечающую за взаимодействие с оборудованием.

Связность — это не то же самое, что контекст.

Протокол OPC UA должен был устранить этот пробел. Действительно ли включение протокола передает смысл вместе с сигналом? Фонд OPC утверждает, что его структура «превращает данные в информацию». На практике же инженеры сообщают, что эта модель остается неиспользованной.

Маркус Илгнер, после 18 месяцев работы с OPC UA, обнаружил, что узлы «просто помещаются в пространство имен ns=1» (универсальный сегмент), поскольку полная модель влечет за собой накладные расходы, которые «не обязательно принесут какую-либо отдачу от инвестиций в краткосрочной и среднесрочной перспективе». Компания Wautoma Biotech, производитель оборудования, называет этот результат «разницей между предоставлением кабеля и предоставлением карты».

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

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

Откуда берутся самые популярные цифры в этой категории

Три показателя, повторяющиеся на страницах поставщиков MES-систем, имеют четкую обратную связь, и ни один из них не выдерживает критики. «Среднее сокращение времени производственного цикла на 45%» восходит к Белой книге № 1 компании MESA, небольшой группе лиц, «опрошенных в 1993 году» — документу, в котором поставщики всегда оговаривают, что результаты «будут разными для каждого пользователя».

Та же самая цифра вновь появляется, без изменений, в статье MESA 1997 года и по-прежнему обещает выигрыш в мониторинге производства в режиме реального времени на страницах поставщиков в 2026 году. McKinsey опубликовала два диапазона с разницей в год: сокращение времени простоя на 30-50% в 2017 году (без методологии), а затем доступность активов на 5-15% в 2018 году, наряду со своим собственным предупреждением о том, что не следует рассматривать предиктивное техническое обслуживание «как панацею».

Приписываемые компании MESA показатели «22% своевременной доставки» и «19,4% чистой прибыли» не фигурируют ни в одном из документов, на которые никто не ссылается.

Никто этого не измерял, включая компанию, опубликовавшую эту статью.

Ни одно независимое контролируемое исследование, охватывающее несколько предприятий, не устанавливает среднего повышения общей эффективности оборудования (OEE), обусловленного применением MES. Почему? Институт Фраунгофера IVV объясняет это просто: этот материал «обычно скрывается в разделах типа „извлеченные уроки“… усилия, вложенные в техническое решение, не публикуются в научных изданиях».

Единственная методологически обоснованная цифра в этом исследовании, взятая из аналитического обзора NIST, основанного на 80 интервью, оценивает весь потенциальный потенциал в «приблизительно 3,2% снижения себестоимости продукции на производственном участке» — на порядок ниже того, что заявляют поставщики платформ для интеллектуального производства.

Отсутствие доказательств относится ко всем поставщикам в этой категории, включая того, кто опубликовал эту статью. Статья, в которой цитируется двузначное значение OEE, цитирует поставщика, а не исследование.

Скорость не является автоматическим преимуществом.

В ходе регрессионного анализа, проведенного институтом Fraunhofer ISI в 2019 году на основе данных опроса об обрабатывающей промышленности Германии, было установлено, что цифровые технологии «не оказали статистически значимого влияния на общую факторную производительность».

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

Неудачная попытка компании Hershey’s внедрить новые системы в 1999 году показывает, к чему приводит скорость неподготовленного процесса: три системы были внедрены в течение 30 месяцев вместо рекомендованных 48, тестирование было сокращено, а запуск в эксплуатацию приурочен к пику сезона Хэллоуина.

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

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

Внедрение, провалившееся по причинам, связанным с персоналом, а не с техническими проблемами.

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

Решение заключалось не в программировании. Три руководителя присоединились в качестве инициаторов и помогли разработать формы ввода данных, и за четыре месяца показатель сбора данных вырос с менее чем 60% до более чем 92% без каких-либо изменений. Даже компания gbo, поставщик MES-систем, признает, что «программное обеспечение — это самая незначительная проблема».

Независимый аудитор Panorama Consulting, не имеющий отношения ни к одному из ответов, перечисляет повторяющиеся причины: проектирование процессов, основные данные и поддержка со стороны руководства. Задержка внесения изменений в этот список не входит.

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

Переменная, о которой стоит поспорить

В июльском отчете Gartner «Магический квадрант 2025 года для корпоративных платформ разработки приложений с использованием низкокодового подхода» оцениваются двенадцать поставщиков, от Appian и Mendix до ServiceNow и Zoho. Ни один из них не разрабатывает MES-платформу для заводов. Когда аналитик говорит о низкокодовом подходе, он подразумевает разработку корпоративных приложений. Когда же об этом говорит предприятие, это слово означает нечто другое.

Делает ли этот разрыв лежащий в его основе градиент неактуальным? Не совсем. В исследовании 2023 года, опубликованном в журнале Empirical Software Engineering (Аламин, Уддин и Малакар), было проанализировано около 33 000 сообщений на Stack Overflow по 38 платформам с низким уровнем кодирования, и было обнаружено, что кастомизация приложений является крупнейшей из 40 групп, составляя 30%, поскольку кастомизация, «которая не является изначально присущей платформам LCSD, становится сложной».

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

Один из работающих интеграторов на PLCtalk высказал ту же мысль в 2024 году: «Если у вас есть только базовые требования к MES, такие как OEE, их можно напрямую настроить в Ignition с помощью скриптов».

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

Одна из архитектурных схем, занимающих эту позицию.

Модуль MES от Iotellect — один из примеров, построенных на основе этой концепции. Поставщик описывает его как «готовые к использованию модули MES на базе полностью редактируемого ядра с низким уровнем кодирования», охватывающие планирование, OEE, отслеживание и мониторинг в реальном времени — совместимый с ISA-95, развертываемый в облаке, локально или в гибридной/периферийной среде.

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

Всё вышесказанное подтверждает точку зрения о поставляемых модулях. Рынок действительно разделён между корпоративными системами с низким уровнем кодирования и промышленными IoT-системами MES, и именованные модули для именованных функций являются проверяемым требованием.

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

В ходе данного исследования не было обнаружено ни одного задокументированного, независимо подтвержденного случая — ни для этого поставщика, ни для любого другого — когда платформа с низким уровнем кодирования работала бы в полном объеме по стандарту ISA-95 уровня 3 в производственных масштабах, имела бы конфигурацию под контролем версий и могла бы поддерживаться персоналом предприятия после ухода интегратора.

Такой случай может существовать. Здесь он не был обнаружен, и об этом следует заявить, а не обходить стороной.

Под ним находится слой данных.

Ничто из этого не работает без описанного ранее слоя, который преобразует необработанные сигналы в смоделированные данные. Более широкая платформа Iotellect, позиционируемая как промышленная платформа IoT , соединяет «более 40 000 типов устройств и источников данных» через более чем 50 протоколов по фиксированной абонентской цене, а не по оплате за каждое устройство — это бизнес-факт, а не заявление об экономии.

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

Вопрос, на который маркетинговая страница не может дать предварительный ответ.

В рамках стандарта ISA-95 гарантируется, что эта проблема никогда не будет решена. В обзоре KTH «Управление конфигурацией» указано как задача поддержки 3-го уровня — версионирование модели не является особенностью платформы, а входит в перечень функций MES.

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

Версионируемая конфигурация — это минимальный уровень. Ответ на этот вопрос также можно легко получить: это пункт списка, а не артефакт. То, на что нельзя дать предварительный ответ на странице поставщика, сложнее — показать различия в модели генеалогии, которая была выпущена в прошлом квартале. Кто это проверил. Что сломалось. Как это было обнаружено.

Возможность редактирования — это отправная точка отсчета времени.

Это еще не конец.

Читать полностью на источнике