人工智能、能源电力、芯片、AI基础设施、服务器与整机、存储、网络安全、智算中心、模型、AI应用、端侧AI、物理AI、AI科学与公共服务、智能经济、云资讯。
罗克韦尔自动化2026年7月对17个国家1560名制造业决策者的调查显示，93%的制造商已在使用MES软件（制造执行系统），但仅有28%实现了企业级全面部署，只有23%完成了与ERP、PLM、质量管理和运营技术（OT）系统的全面集成。
这是一项供应商主导的调查，并非独立研究，但其数据本身已能说明问题。44%的受访者将集成能力列为MES采购的首要需求，33%将其视为最大的数据集成难题。
罗克韦尔的Anthony Murphy表示："MES的采用已不再是障碍，但企业级规模化部署仍是挑战。"Govindaraju和Putra早在十年前、在没有任何利益关联的情况下，就得出了相同的结论。
两人在2016年对万隆某钢铁厂的研究中发现，功能集成是"最困难的挑战"。采购问题已解决，集成问题仍悬而未决。
低代码MES的历史渊源
低代码MES以"新技术"自居，实则并非如此。早在1997年9月，MESA国际就在第6号白皮书中定义了制造执行系统这一品类："用户可以对这套功能进行配置，以满足其企业和工厂目标。"
同一文件对此直言不讳："配置方式和优先级可能因厂而异。"1997年语境下的"配置"，指的是选择工厂部署哪些功能模块，而非在拖放式界面中建模工作流。
逐厂差异化从来不是低代码技术发现的缺陷，而是MES从一开始就要应对的既定规格。
为何MES需要配置而非开箱即用
NIST GCR 19-022报告（佐治亚理工Leon McGinnis执笔）解释了MES为何需要配置而非直接交付成品。在第三层级以下，"控制由执行预定义操作构成"，这一层已"相当成熟"。
而在第三层级，调度是"一个极其复杂的决策问题"，没有任何精确方法能在指数时间以内完成求解。第三层级以下的车间自动化是已解决的闭环控制问题，第三层级则是需要逐厂摸索、往往到后期才能厘清的决策问题。
ISA-95是否真的明确规定SCADA位于第二层级？直接查阅该标准委员会页面可以发现，ISA-95从未将SCADA或MES置于任何具体层级，而是将该标准描述为"控制功能与其他企业功能之间的接口"，专注于第三、四层级的边界。
NIST说是第二层级，常被引用的页面说是第三层级，从业者争论第一或第二层级，而ISA-95本身对此一概未答。
机器数据集成才是真正的瓶颈
罗克韦尔自己的数据鸿沟——93%的采购率对比23%的集成率——直接指向机器数据集成这一核心问题，这一问题早在评估任何MES功能之前就可量化。
On Time Edge的Kim Burndred将每台资产分为两类：第一类设备具备OPC或MTConnect等原生连接能力，第二类则没有，需要借助IIoT网关。他建议"在制定推广计划之前，甚至在排定时间表之前"，就应先完成设备清点。
慕尼黑工业大学研究人员仅为三台实验室设备的数据采集编写了989行代码，仅通信层就如此庞大。Dreher咨询公司的项目周期数据印证了同样的规律：绿地项目4至6个月，棕地项目9至15个月，即便是Dreher自己分享的低代码成功案例，实际也历时8个月，消耗了1.5个技术全职人力。
低代码压缩的是工厂自动化软件项目的应用层，而机器连接层依然原封未动。
OPC UA的承诺与现实
OPC UA本应填补这一鸿沟。但启用一个协议，真的能在传递信号的同时传递语义吗？OPC基金会声称其框架"将数据转化为信息"，但工程师们反映，这套模型在实践中往往被束之高阁。
Marcus Ilgner经过18个月的OPC UA实践后发现，节点"被直接放入命名空间ns=1"（通用分类桶），因为完整模型的开销"在短期和中期内不一定能带来投资回报"。设备制造商Wautoma Biotech将这一现象描述为"提供一根电缆与提供一张地图之间的差距"。
这种语义化映射工作，而非某种新协议，才是工业数据管理平台真正需要完成的任务。这个说法并无虚假之处。
模型可以承载语义，但没有任何协议能替你逐台设备、逐个工厂地完成这项填充工作。生产数据管理的核心，大多是这种映射工作，而非线路本身。
行业常引用数据的真实来源
MES供应商页面反复引用的三组数据，追溯下来均站不住脚。"制造周期时间平均缩短45%"这一数据，源自MESA第1号白皮书中"1993年小样本调查"，而供应商引用时总是省略白皮书自身的注意事项——"每个用户的结果将有所不同"。
这一数据在MESA 1997年的文件中原封不动地再次出现，到2026年仍在供应商页面上以"实时生产监控收益"的面目存在。麦肯锡则在相差一年的两份报告中给出了两组数字：2017年列出"停机时间减少30%至50%"，未附任何方法论说明；2018年又列出"资产可用率提升5%至15%"，同时附上了对将预测性维护"视为万能药"的警告。
至于"准时交货率提升22%"和"净利润率提升19.4%"这两组被归因于MESA的数据，在任何人实际引用的原始文件中均未出现。
独立研究数据的缺位
目前没有任何独立的、对照组设计的多工厂研究，能够证明MES带来的平均OEE提升幅度。原因何在？弗劳恩霍夫IVV研究所给出了直白的解释：相关材料"通常隐藏在'经验教训'章节中……投入技术方案的努力并未以科学方式发表"。
这批研究中唯一有方法论支撑的数据，来自一份基于80次访谈的NIST简报，其结论是整体可实现的机会约为"车间生产成本降低约3.2%"——比智能制造平台供应商宣传的数字低一个数量级。
这一证据缺失适用于该品类的每一家供应商，包括发布本文的厂商。任何引用两位数OEE提升数字的文章，引用的都是供应商，而非研究报告。
数字化与生产率的关系
弗劳恩霍夫ISI 2019年对德国制造业调查数据的回归分析发现，数字技术"对全要素生产率没有任何统计显著影响"。
将机器人与数字技术结合使用甚至产生了"干扰效应，导致两种技术对生产率的影响均有所下降"。这些数据来自2012年，覆盖的是广义数字化而非MES本身——两点均需注意。
好时公司1999年的上线失败案例展示了仓促推进对准备不足的流程的破坏力：三套系统被压缩到30个月完成，而建议时间是48个月，测试被缩短，上线时间恰好选在万圣节旺季之前。
《食品工业管理者》报告了现代MES项目中相同的规律，验收测试"从不模拟真实的换产、过敏原清洁或召回场景"。
一种降低了将制造工作流自动化弯曲适应工厂现有习惯的成本的工具，若不先修正这些习惯，只会加大暴露于这类失败模式的风险。
人的因素比代码更关键
gbo datacomp记录了巴伐利亚某企业MES部署的案例：技术规划周密，但上线六个月后数据质量依然低下。gbo的诊断直截了当——"班组长从未参与概念设计阶段"。
解决方案不是代码。三名班组长作为项目推进者加入，参与设计数据录入表单，四个月内数据采集率从不足60%提升至超过92%，零开发投入。即便是MES供应商gbo也承认，"软件是最小的问题"。
Panorama咨询公司作为没有立场偏向的独立审计方，将反复出现的失败根源列为：流程设计、主数据和班组长支持，变更延迟并不在其中。
低代码MES供应商Tulip本有充分理由持相反立场，却指出了上线后真正发生的情况：一个表单修改变成了"一张IT工单、一次供应商介入和一个发布周期……质量团队停止提需求，开始绕过系统自行处理"。这一说法尚无独立来源加以证实。
低代码与工业自动化的概念分歧
Gartner 2025年7月发布的企业低代码应用平台魔力象限评估了十二家供应商，从Appian、Mendix到ServiceNow和Zoho，没有一家为工厂构建MES平台。分析师口中的"低代码"指企业应用交付，工厂口中的"低代码"则是另一回事。
这种分歧是否意味着底层规律无关紧要？不尽然。《实证软件工程》2023年刊载的一项研究（Alamin、Uddin和Malakar）挖掘了38个低代码平台上约33000条Stack Overflow帖子，发现"应用定制"是40个聚类中最大的一个，占比30%，原因是"低代码平台原生不支持的定制变得困难"。
这些都是企业工具，车间现场几乎不出现在Stack Overflow上。将这一规律套用于MES，是本文提出的推论，而非该论文的结论：平台原生支持范围内的工作很容易压缩，超出范围的则不然。
PLCtalk上一位经验丰富的系统集成商在2024年点出了同样的问题："如果只有基础MES需求，比如OEE，可以直接在Ignition中用脚本实现。如果是完整的批次追溯，可能需要去参加SepaSoft的培训课程。"OEE不过是对Tag的算术运算，批次追溯则是物料标识的建模——这个差距，而非低代码与纯代码之争，才是真正值得探讨的变量。
以Iotellect为例
Iotellect的MES模块是围绕这一边界构建的一个案例。该供应商将其描述为"基于完全可编辑低代码核心的即用型MES模块"，涵盖计划排程、OEE、批次追溯和实时监控，符合ISA-95标准，支持云端、本地或混合边缘部署。
其定位是：将低代码MES软件作为生产管理软件交付，满足工厂的通用需求，同时提供开放的底层模型，应对个性化需求。
以上内容支撑的是"即用型模块"的那一半。市场确实分化为企业低代码和工业物联网MES两个方向，针对特定功能命名的模块是可核实的主张。
但"可编辑核心"并非同一类型的主张，本文的证据倾向于对其持保留态度。Alamin的规律表明，脱离平台原生能力的工作是难的一面，而非容易的一面。
本次研究未发现任何有文件记录、经独立验证的案例——无论是该供应商还是其他供应商——证明某低代码平台在生产规模下完整运行ISA-95第三层级执行，且配置处于版本控制之下、并可由工厂员工在集成商离场后独立维护。
此类案例或许存在，但本文未能找到，这一缺失应当明言，而非回避。
连接能力与语义理解的差距
上述一切都离不开前文描述的那一层——将原始信号转化为有模型支撑的数据。Iotellect的更广泛平台定位为工业物联网平台，通过50多种协议连接"40000多种设备和数据源"，采用固定订阅定价而非按设备计费——这是一项商业事实，而非节省成本的承诺。
对于一个由互联工厂系统构成的工厂而言，这个协议数量所能带来的，是规模略小但本质相同的问题：连接，而非自动得到语义。
ISA-95自身的范围保证了这一问题永远不会彻底消解。KTH的综述将"配置管理"列为第三层级的支撑活动——模型版本控制并非平台的锦上添花，而是MES本应承担职责的具名组成部分。
Mike Hadlow在2012年指出了这一失败模式：一个团队的配置语言，若干年后"回到了原点……把一切都硬编码了，只不过现在用的是一种更糟糕的语言"。这句话之前的核心观点更为深刻："在超过一定复杂度之后，硬编码一个解决方案可能是危害最小的选择。"
可版本化的配置是最低门槛，但这一门槛也极易声称达到：答案可以是产品说明中的一个要点，而非一个可验证的制品。没有任何供应商页面能预先回答更难的问题——展示上个季度交付的一次谱系模型变更的差异比对记录：谁审核了它，什么出了问题，如何发现的。
可编辑性是计时的起点，而非终点。
Q&A
Q1：MES软件的集成率为何远低于采购率？
A：根据罗克韦尔自动化的调查，93%的制造商已采购MES软件，但仅有23%完成了与ERP、PLM、质量管理和OT系统的全面集成。核心原因在于机器数据集成难题：大量设备缺乏OPC或MTConnect等原生连接能力，需要额外部署IIoT网关；即便连接成功，原始信号也需要逐台设备、逐个工厂进行语义映射，才能转化为有价值的信息。低代码工具只压缩了应用开发层，对机器连接层毫无影响。
Q2：MES厂商宣传的OEE提升数据可信吗？
A：可信度存疑。供应商页面常引用的数据，如"制造周期缩短45%"，源自MESA 1993年的小样本调查，且白皮书本身注明"每个用户结果不同"。麦肯锡在相邻两年给出了差异悬殊的两组数字，且均未附方法论说明。目前没有独立、对照组设计的多工厂研究能证明MES带来的平均OEE提升。唯一有方法论支撑的NIST数据显示，可实现的机会约为车间生产成本降低3.2%，远低于供应商宣传的两位数数字。
Q3：低代码MES是否能真正降低工厂实施难度？
A：在平台原生支持范围内，低代码确实能压缩应用配置工作量。但超出原生能力边界后，定制难度并不比传统开发低，这一结论已被Stack Overflow大规模研究所证实。更关键的是，MES项目失败往往源于班组长未参与设计、流程习惯未梳理、主数据质量差等人的因素，而非代码本身。一个降低了迁就现有习惯成本的工具，若不先修正这些习惯，反而会放大失败风险。