上周一个做制造业的朋友跟我吐槽：他们工厂上了套MES，花了200多万，用了8个月，结果车间主任还是用Excel排产。
我问为什么。
他说，系统太死板了，每改一个工艺路线要提需求单，等供应商排期，少说两周。
车间等不起，干脆自己搞个表格，想怎么改怎么改。
这事让我想了很久。
MES对制造企业来说是个刚需，但传统定制开发太重、太慢、太贵，改不动。当下最流行的AI低代码快速开发工具能不能解决这个问题？今天我就把这个事掰开了聊聊。
一、MES到底管什么？
先说清楚MES是什么。
MES（Manufacturing Execution System），制造执行系统，管的是车间这一层的事。
ERP管的是"计划"，MES管的是"执行"。ERP告诉你"这个月要生产1000个零件"，MES告诉你"第317个零件现在在哪台设备上加工，做到第几道工序了，良品率多少"。
MES跟ERP的关系，打个比方：ERP是司令部，负责定作战计划；MES是前线指挥所，负责执行作战计划并实时汇报战况。
两者缺一不可，光有ERP没有MES，计划就是纸上谈兵；
光有MES没有ERP，执行就是无头苍蝇。
MES的核心功能模块，拆开看主要分为这几块：
1、生产调度：把ERP的生产计划拆成车间能执行的工单，分配到产线、设备、人员。调度要考虑产能约束、物料齐套率、订单优先级，不是简单地把计划往下推。
2、生产执行：工单下达到车间，工人按工序报工，系统记录每个工序的开始时间、结束时间、产量、不良数。这是MES最基础也最核心的功能，所有数据追溯都从这里来。
3、质量管理：来料检验、过程检验、成品检验，记录检验数据，触发不良品处理流程。质量管理做得好，产品追溯才有意义，出了问题才能快速定位到批次、工序、设备、人员。
4、物料管理：车间物料的领用、消耗、退料，跟ERP的库存对接，做到账物一致。很多工厂的车间物料管理是个黑洞，领了多少、用了多少、剩了多少，一笔糊涂账。
5、设备管理：设备台账、保养计划、维修记录、设备OEE（综合设备效率）统计。设备管理直接影响产能利用率，OEE低于60%的产线，问题往往出在设备停机和换线时间上。
6、数据采集：从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集成，无缝融合系统功能。选对低代码产品，既享受低代码的快，又不牺牲定制能力。像织信低代码平台就支持这种方式，标准组件覆盖大部分场景，需要深度定制的时候可以写自定义脚本和java代码，两者无缝衔接。
七、总结
MES不是一个纯技术问题，是业务理解加上技术实现的组合命题。
这几年，AI智能体的兴起，让低代码有进一步的降低了技术实现门槛，让业务人员通过语言描述需求，也能参与到系统搭建中去，也让系统迭代的速度能更快跟得上业务变化速度。但值得提醒的是——低代码不等于不用动脑子，业务梳理、数据建模、流程设计这些工作该做，还得做！！
