上周一位做制造业的朋友向我吐槽：他们工厂引入了一套MES系统，投入了200多万元，用了8个月，结果车间主任依然在用Excel排产。

我询问原因。

他说，系统过于僵化。每次调整工艺路线，都得提交需求单等待供应商排期，至少需要两周时间。

车间等不起，索性自己用Excel表格管理，想怎么改就怎么改。

这件事其实折射出MES系统的一个普遍痛点。

MES对制造企业来说是刚性需求，但传统定制开发模式太重、太慢、太贵，根本难以灵活调整。当下流行的低代码开发工具，能否真正解决这个难题？今天就来深入探讨一下。

一、MES到底管理什么？

先明确MES的定义。

MES（Manufacturing Execution System），即制造执行系统，负责管理车间层面的生产执行。

ERP负责“计划”，MES负责“执行”。ERP告诉你“这个月要生产1000个零件”，MES则告诉你“第317个零件现在在哪台设备上加工，进行到哪道工序，良品率是多少”。

两者是什么关系？打个比方：ERP是司令部，制定作战计划；MES是前线指挥所，执行计划并实时反馈战况。

两者缺一不可。只有ERP没有MES，计划就是纸上谈兵；只有MES没有ERP，执行就像无头苍蝇。

MES的核心功能模块，拆解来看主要包括以下几块：

生产调度

将ERP的生产计划分解为车间可执行的工单，分配到产线、设备和人员。调度需要考虑产能约束、物料齐套率、订单优先级，不是简单地把计划往下推。

生产执行

工单下达到车间后，工人按工序报工，系统记录每道工序的开始时间、结束时间、产量和不良品数量。这是最基础也最核心的功能，所有数据追溯都源于此。

质量管理

包括来料检验、过程检验和成品检验，记录数据并触发不良品处理流程。质量管理做得好，产品追溯才有意义，出现问题时才能快速定位到批次、工序、设备和人员。

物料管理

车间物料的领用、消耗和退料，与ERP库存对接，确保账物一致。很多工厂的车间物料管理是个黑洞，领了多少、用了多少、剩了多少，常常是一笔糊涂账。

设备管理

包括设备台账、保养计划、维修记录和设备OEE统计。设备管理直接影响产能利用率，OEE低于60%的产线，问题通常出在设备停机和换线时间上。

数据采集

通过PLC、传感器、扫码枪等设备自动采集数据，减少人工录入。自动采集的准确率和实时性远高于人工录入，是MES数据质量的关键保障。

这几块功能，不同企业的需求深度差异很大。离散制造（如机械加工、电子装配）偏重工序管理和数据采集，流程制造（如化工、食品）偏重配方管理和批次追溯。

但无论哪种类型，MES都必须与ERP打通、与设备打通、与人打通。

二、为什么传统MES开发这么难？

传统MES开发，说白了有三个老大难问题：

第一个，需求变化快。

制造业的工艺路线、产品型号和质检标准，经常需要调整。今天客户要求增加一道清洗工序，明天新产品要新增三个检验项目。传统开发改一个字段，要改数据库、改接口、改页面、改报表，牵一发而动全身。比如某企业，MES上线一年后提出了300多条变更需求，供应商光是评估就花了两个月。

第二个，集成对接多。

MES要与ERP对接订单和库存，与PLM对接工艺路线和BOM，与设备对接数据采集，与WMS对接物料流转。每个接口都是一个难点——协议不同、数据格式不同、实时性要求不同。光是对接这一项，就能吃掉项目30%的预算。更麻烦的是，设备厂商往往不开放协议，还得找第三方做协议转换，又是一笔费用。

第三个，行业差异大。

汽车零部件的MES与食品饮料的MES，名称听起来一样，实际上几乎没多少可复用的部分。通用MES软件为了覆盖不同行业，功能做得又多又杂，企业买回来发现80%用不上，真正需要的20%又得定制。定制出来的东西与标准版格格不入，升级时又是一场灾难。

这三个问题叠加，导致传统MES项目的典型路径是：需求调研3个月，开发6个月，实施3个月，试运行3个月，正式上线时需求已经变了。然后进入“改需求，改代码，再上线”的死循环，项目越拖越长，预算越超越多。

行业里有句老话：MES项目不做三年算快的，不超预算50%算省的。

三、低代码怎么解决MES的难题？

低代码不是万能药，但在MES这个场景里，它确实能直击传统定制开发的几个痛点：

痛点1：需求变化快，低代码改得快

传统开发改一个表单字段，要改数据库表结构、改后端接口、改前端页面、改报表模板，快则一周，慢则两周。在低代码平台上呢？表单字段是配置出来的，加一个字段就是拖一个组件、改一个配置的事，10分钟就能搞定。工艺路线变了？在流程设计器里拖几个节点，改一下流转条件，当天就能上线。车间主任自己就能动手调整，完全不用等IT排期。

痛点2：行业差异大，低代码搭得快

通用MES软件覆盖不了所有行业，定制开发又太贵。低代码平台提供基础组件（表单、流程、报表、数据模型、API接口），企业可以像搭积木一样，根据自身行业特点搭出专属MES。电子厂要增加一个SMT贴片工序的采集点？配置一下就行。食品厂要增加一个保质期预警？拖个定时任务组件，设一下规则就行。不需要懂代码，但需要懂业务。

痛点3：集成对接多，低代码连得快

低代码平台通常自带API构建器和连接器。ERP的接口、设备的OPC UA协议、PLC的Modbus通信，通过预置的连接器或自定义API就能对接。不用从零写接口代码，配置一下参数，映射一下字段，半天就能跑通一个接口。即使设备没有预置连接器，用自定义API的方式对接，也比从头写原生代码快得多。

但这里必须泼一盆冷水：低代码能解决“快”和“灵活”的问题，但解决不了“不懂制造”的问题。MES不是一个纯IT项目，它需要对制造业务有深度理解。工艺路线怎么建模、车间排产怎么算、质量追溯怎么设计——这些不是拖几个组件就能搞定的。你得懂制造，才能用低代码把MES搭对。

四、低代码开发MES，分几步走？

第一步：梳理业务流程，花2到4周。

这一步最重要，也最容易被跳过。千万别上来就打开低代码平台拖组件。先拿张纸，把车间的业务流程画出来：从销售订单到生产计划，从生产计划到工单下达，从工单下达到工序报工，从工序报工到质量检验，从质量检验到成品入库。

每一步谁来做、输入什么、输出什么、系统要记录什么，全部理清楚。

这一步做不好，后面全白搭。

第二步：搭建数据模型，花1到2周。

数据模型是MES的骨架。生产订单、工单、工序、报工记录、检验记录、物料台账、设备台账——这些实体之间的关系得设计好。低代码平台通常有可视化的数据建模工具，建表、设字段、定关系，比写SQL快多了。

注意一个原则：先做最小可用模型，不要一上来就把所有字段都加上。用着用着发现缺字段再加，比一开始就想追求完美要靠谱得多。

数据建模有个常见的坑：很多人把工单和工序混在一张表里，到后面要查某道工序的耗时、某台设备的产出时，发现数据根本取不出来。工单和工序是父子关系——一张工单对应多道工序，这个关系建模型的时候就得想清楚。

第三步：配置表单和流程，花2到4周。

这是低代码最擅长的部分。工单下达的审批流程、报工的表单界面、检验记录的录入页面、异常处理的触发规则，全都在可视化界面里配置。

表单字段拖组件，流程节点拖连接线，规则引擎设条件。不用写一行代码，但必须做充分的测试——配置出来的东西，逻辑正确性得自己保证。

有个建议：先配最核心的报工流程和检验流程，让车间先用起来。其他功能（设备管理、物料管理、看板报表）后面再加。别想着一步到位，MES是迭代出来的，不是设计出来的。

第四步：对接外部系统，花2到4周。

利用低代码平台的API能力对接ERP、PLM、WMS等系统。对接顺序建议：先对接ERP（订单和库存是MES的数据源），再对接设备（数据采集是MES的核心价值），最后对接其他系统。

对接ERP时，重点关注工单同步、物料消耗回写、成品入库回写这三个接口。对接设备时，先搞清楚设备支持什么协议（OPC UA、Modbus TCP、MQTT），再选对应的连接器。

对接ERP有个常见问题：ERP的工单数据结构和MES的工单数据结构往往不一样。ERP的工单可能只有产品编码和数量，MES需要的是按工序拆分的详细工单。这个映射关系在对接前必须梳理清楚，否则同步过来的数据MES用不了。

第五步：报表和看板，花1到2周。

MES的数据最终要可视化呈现。车间看板显示什么？当日产量、实时OEE、各产线计划完成率、不良品率、设备运行状态。管理看板看什么？周度和月度产量趋势、质量异常分布、交付准时率、库存周转率。

低代码平台的报表组件一般都能拖拽配置，但复杂的分析逻辑可能需要写一点SQL或脚本。

看板设计有个原则：车间看板要大字少字，工人扫一眼就知道今天的任务和进度；管理看板要多维度对比，管理者能从数据里发现趋势和异常。

第六步：试运行和迭代，持续进行。

上线不是结束，而是开始。先选一条产线试跑，跑两周，发现问题改配置，改完再跑。稳定了再推广到第二条产线、第三条产线。

低代码的优势就在这里——改配置比改代码快得多，迭代周期从周级缩短到天级。

试运行期间重点关注三个指标：报工及时率（工人是否按时报工了）、数据准确率（报上来的数据跟实际对不对得上）、系统使用率（车间有多少人在用系统而不是绕回Excel）。

五、低代码开发MES的常见误区

1、别以为低代码不需要业务梳理

低代码降低了技术门槛，但没有降低业务门槛。如果你连自己的工艺路线都说不清楚，低代码也帮不了你。业务梳理永远比技术实现重要。有个做汽车零部件的企业，用低代码两周就搭出了MES原型，但跑了三个月还是不好用，原因就是业务流程没梳理清楚，系统跟实际操作对不上。

2、数据模型设计不要太随意

低代码建表太容易了，点几下就建好了，结果很多人不认真设计数据模型。表与表之间的关系乱七八糟，字段命名随心所欲，到了要做报表和数据分析的时候，发现数据散落在各处，关联不起来，只能推倒重来。数据模型要当数据库设计来做——要有规范、有文档、有评审。

3、不要忽视系统性能问题

低代码平台在处理复杂查询和大数据量时，性能可能不如原生代码。MES场景下，数据采集频率可能是秒级的，一条产线一天产生的报工记录可能就有几万条。做架构设计时就要考虑数据量增长后的性能瓶颈，提前做好分表、索引、缓存等优化。性能问题不是上线后才考虑的事，是设计阶段就要规划好的。

六、什么时候可以选择低代码？

简单说一个判断标准：

如果你们的MES需求比较标准（生产排产、工序报工、质量检验、数据采集这些通用功能），而且业务变化比较频繁，选低代码。上线快、改得快、成本低。

另外还有一种中间路线：用低代码平台搭建MES的主体框架和通用功能，特殊的深度定制部分则利用低代码平台提供的自定义组件功能。一些低代码产品支持高代码开发，并且无需通过API集成，能实现系统功能的无缝融合。选对产品，既能享受低代码的快捷，又不牺牲定制能力。

七、总结

MES不是一个纯技术问题，而是业务理解加上技术实现的组合命题。

这几年，AI智能体的兴起，让低代码进一步降低了技术实现门槛，业务人员通过语言描述需求就能参与到系统搭建中，也让系统迭代的速度能更快跟上业务变化的速度。但值得提醒的是——低代码不等于不用动脑子。业务梳理、数据建模、流程设计这些工作，该做还得做。