这个问题如果只从工具层面看，很容易得出一个乐观答案：低代码、无代码已经能拖表单、配流程、做报表，客户当然可以自己开发。

但在项目现场，事情通常没有这么轻松。

ERP、MES这类系统一旦进入企业主流程，牵动的就不是几张页面。它牵动的是物料怎么编码，BOM怎么变更，工单怎么下发，库存怎么锁定，质检结果怎么回写，成本怎么归集，权限谁能改，接口失败后谁来补单。

把开发交给客户，表面上交出去的是页面和流程配置权，实际交出去的是一整套系统责任。

很多项目出问题，就出在这里。

客户以为自己拿到了一个更灵活的工具，厂商以为客户以后可以自己维护。上线之后才发现，业务部门会提需求，但未必能建模型；IT会管系统，但未必懂制造现场；管理层想省实施费，但后面每一次变更都要有人兜底。

所以我的判断很明确：

低代码、无代码可以参与ERP、MES重构，也可以把一部分开发工作交给客户侧完成。但如果想把ERP、MES这种标准化软件完全交给客户自己搭，前提非常重。它考验的是客户能不能把业务、数据、流程、权限、集成和运维一起管起来，拖控件只是最浅的一层。

一、先说清楚，ERP、MES不是“表单加流程”

很多人第一次接触低代码，容易把企业系统想简单了。

建一个采购申请表，配置一个审批流，加几个字段，再做一张统计报表，看起来就像一个小型业务系统。做OA类轻流程、行政登记、资产申领、客户拜访记录、售后工单，这条路确实能跑起来。

但ERP、MES不是这个量级。

ERP管的是企业资源。销售订单进来以后，要影响库存、采购、生产计划、应收、发货、开票、成本。采购订单下出去以后，要影响供应商、在途、到货检验、入库、应付、付款。一个物料编码错了，后面采购、库存、生产、成本都跟着错。

MES管的是制造执行。工单下达到哪条线，工序怎么走，人员怎么报工，设备状态怎么采集，检验点放在哪里，返工返修怎么处理，批次号怎么追溯，线边库存怎么消耗，这些都不是普通审批流能解决的。

所以ERP、MES系统里最麻烦的地方，往往不在页面，而在页面背后的业务关系。

比如一个生产订单，在系统里至少会牵动这些东西：

• 产品BOM版本是否正确。

• 工艺路线是否已经生效。

• 库存是否需要锁定或预留。

• 领料是按套料、按工序，还是按线边仓消耗。

• 不良品进入返工、报废，还是让步接收。

• 完工入库以后，成本是否能归集到正确对象。

• 质量数据能不能追溯到物料批次、设备、班组和时间。

这些问题如果没有想清楚，低代码平台搭出来的就只是一个“能录数据的壳”。刚上线时看着还能用，业务量一上来，变更一多，问题就会集中出现。

二、技术难点：数据模型比页面更难

用低代码重构ERP、MES，第一个难点是数据模型。

传统软件厂商做ERP、MES，难在什么地方？按钮怎么摆只是表层，长期沉淀下来的对象模型和业务规则才难。

以制造业为例，系统里至少有这些基础对象：

• 物料。

• 客户。

• 供应商。

• BOM。

• 工艺路线。

• 工作中心。

• 设备。

• 工序。

• 仓库和库位。

• 批次和序列号。

• 生产订单、采购订单、销售订单。

这些对象之间有关系，也有生命周期。

物料有启用、停用、替代、版本；BOM有设计BOM、工艺BOM、制造BOM；工艺路线有生效日期、适用产品、标准工时；工单有下达、开工、暂停、完工、关闭；库存有可用、冻结、检验中、在途、预留。

客户自己用低代码开发时，如果只是把这些东西做成几张表，很快就会遇到麻烦。

字段能不能随便改？

一个物料被工单引用后还能不能删除？

BOM变更以后，未开工工单是否同步更新？

已经领料的工单还能不能改数量？

质检不合格以后，库存状态如何变化？

这些都属于系统规则。规则不设计，系统就靠人记；人一换，规则就断；业务一复杂，系统就乱。

真正成熟的低代码平台，应该能承载对象关系、权限、流程、计算规则、接口、日志、版本和扩展代码。像织信这类企业级低代码开发平台，适合放在这个层面理解：它要让企业把表单、流程、权限、报表、接口和数据模型放到一个可管理的平台里，而不是停留在业务人员拖一个表单。简单应用可以用零代码配置，复杂规则可以低代码开发，关键接口和特殊逻辑也可以通过高代码补上。

这类能力对ERP、MES重构很重要。因为企业主流程里，总会有一部分规则靠配置能解决，也总会有一部分规则必须写代码。平台如果只能无代码，遇到复杂业务容易卡住；平台如果只有代码，又回到了传统定制开发的老路。

三、施工难点：客户懂业务，但业务不会自动变成系统

很多人说，客户最懂自己的业务，所以开发交给客户最合适。

这句话只说对了一半。

业务部门确实懂现场。销售知道客户怎么催货，采购知道供应商怎么拖期，仓库知道哪些料经常账实不符，车间知道报工为什么经常补录，质量知道哪些检验点容易被绕过去。

但懂现场，和能把现场建成系统，中间还隔着一层工程转换。

系统建设要回答的问题，比业务口头描述细得多。

比如采购收货，业务说“到货以后质检，合格就入库，不合格就退货”。听起来很简单。真正落系统时，要继续追问：

• 到货单由谁创建，是采购、仓库，还是供应商协同门户？

• 质检是全检、抽检，还是按物料类别决定？

• 质检不合格时，库存状态是冻结、待处理，还是直接不入库？

• 退货会不会影响供应商评分？

• 部分合格、部分不合格怎么拆单？

• 已经生成应付暂估以后，退货如何冲销？

• 到货批次和生产批次如何关联？

这些细节，业务人员未必一次说得出来。很多时候是系统做到一半，才发现“原来这里还有一种情况”。如果项目里没有实施顾问、业务架构师、IT负责人一起把规则梳理出来，客户自建很容易变成线上Excel。

线上Excel的特点是：看起来已经系统化，实际还是靠人兜底。字段很多，规则很少；流程很多，责任不清；数据能录，错误很难防；报表能出，口径经常对不上。

所以低代码项目里，施工能力仍然重要。

厂商无需包办一切，但客户和厂商之间必须有清楚分工。客户提供业务规则、组织责任、数据口径和验收标准；厂商或实施团队提供建模方法、平台能力、集成方案和质量把关。双方如果都想省掉这部分工作，后面一定会在上线和运维阶段补课。

四、企业难点：开发权交出去以后，谁负责？

低代码最容易被低估的地方，是治理问题。

传统软件开发虽然慢，但责任边界相对清楚。需求由业务提，方案由实施做，开发由厂商做，测试由双方验，运维由IT和厂商一起处理。

客户自己用低代码搭系统以后，责任边界会变得更复杂。

一个销售经理改了客户字段，影响合同审批怎么办？

一个车间主管改了报工流程，导致成本归集异常怎么办？

一个业务骨干离职，他搭的应用没人敢改怎么办？

多个部门各自建了供应商档案，编码规则不一致怎么办？

低代码给了企业更高的自主权，也会放大企业内部管理水平的差异。

如果企业没有建立平台治理机制，最后会出现几类问题：

• 应用越来越多，但没人知道哪些还在用。

• 字段越来越多，但没人维护数据字典。

• 流程越来越长，但审批责任不清楚。

• 报表越来越多，但口径互相打架。

• 接口越来越多，但失败重试和补偿机制没人管。

• 权限越来越复杂，但离职、转岗、外协账号清理不及时。

这时候低代码不但没有降低复杂度，反而把复杂度摊开到了更多人手里。

所以企业要把开发交给客户侧，至少要配几类角色：

• 业务负责人：决定流程怎么走，规则怎么定。

• 数据负责人：维护主数据、字段含义、编码规则和质量要求。

• 平台管理员：管理应用、权限、发布、版本和日志。

• IT架构人员：把关接口、安全、性能和系统边界。

• 关键用户：负责日常配置、测试、反馈和小范围优化。

没有这些角色，所谓“客户自己开发”，最后会变成“谁会拖页面谁开发”。这在小应用里还能忍，放到ERP、MES上就很危险。

五、标准化软件能不能被低代码重构？

可以，但要分层看。

第一层，标准主干流程，建议保留成熟产品或成熟模板。

比如财务总账、应收应付、存货核算、采购订单、销售订单、生产订单、质量检验、批次追溯，这些流程已经被大量企业验证过。企业如果从零开始自建，投入会非常大，试错成本也很高。

第二层，行业和企业个性化流程，适合低代码承接。

比如项目型制造的过程管控、非标设备企业的设计变更、注塑行业的模具管理、电子行业的替代料审批、汽配行业的客户交付计划、食品行业的批次追溯补充流程。这些需求经常卡在标准ERP、MES之外，改标准系统又太重，用低代码做扩展反而更合适。

第三层，报表、看板、移动端、协同入口，适合低代码快速搭建。

很多企业真正缺的未必是一套全新的ERP，更多是主系统旁边的业务补位。比如销售要看订单交付进度，老板要看库存金额和缺料风险，车间主任要用移动端看工单，质量部门要做异常闭环。这些场景用低代码搭在ERP、MES旁边，效果往往更好。

第四层，老系统改造和系统集成，适合用低代码做中间层。

有些企业ERP已经跑了十几年，直接推倒重来风险太大。但老系统没有移动端，没有灵活流程，没有AI问数，没有跨系统看板。这时可以用织信这类支持私有化、本地化和复杂权限的企业级低代码平台，围绕老ERP、MES补充应用层、流程层和集成层。主数据、订单、库存、工单仍然要和原系统打通，现场变化则通过低代码应用来承接。

这比直接让客户从零重写ERP、MES更稳。

六、从技术、施工、企业三个角度看，真正卡点在哪里

从技术角度看，卡在“平台能力够不够深”。

轻量无代码工具适合做部门级表单和简单审批。ERP、MES这类系统需要对象模型、复杂流程、权限体系、接口编排、日志审计、数据校验、批量处理、性能优化和扩展代码能力。平台如果缺少这些能力，只能做外围小应用，很难承接主流程。

从施工角度看，卡在“有没有人把业务翻译成系统结构”。

业务说的是现象，系统要的是对象、字段、状态、流程、规则、异常和权限。采购说“供应商来料要检验”，系统要知道抽检规则、检验项目、不合格处置、库存状态和财务影响。车间说“工人报工”，系统要知道工序、设备、班组、工时、良品、不良品、返工和完工入库。这一层翻译工作省不掉。

从企业角度看，卡在“客户愿不愿意接住长期责任”。

开发交给客户以后，客户就要维护应用生命周期。谁建，谁审，谁改，谁发布，谁回滚，谁查日志，谁处理故障，谁对数据质量负责，这些都要明确。只想要低代码的快，不愿意建立治理机制，系统迟早会乱。

七、哪些企业适合这样做？

我认为有几类企业比较适合。

第一，有一定IT团队的中大型企业。

这类企业内部有人懂系统，有人能做权限、接口、数据库、运维和安全管理。低代码可以提高交付效率，让IT不用把时间都耗在重复页面和普通流程上。

第二，业务变化快，但主流程已经比较清楚的企业。

比如ERP、MES主干已经跑起来，但还有大量现场流程、部门协同、数据补录、异常闭环和管理看板需要快速响应。这种情况下，低代码的价值会比较明显。

第三，有明确数字化治理意识的企业。

企业愿意定主数据、定编码、定流程责任、定版本管理和验收机制，低代码平台才能越用越稳。

第四，愿意采用“客户共建”而不是“客户单干”的企业。

比较稳的模式，是厂商提供平台、模板、方法和关键技术兜底，客户负责业务规则、日常配置和持续优化。双方把边界说清楚，项目成功概率会高很多。

八、哪些情况不建议这么做？

也有几类情况，我不建议贸然把ERP、MES开发完全交给客户。

第一，企业基础数据很差。

物料编码混乱，BOM版本不准，库存账实不符，工艺路线没有维护，供应商和客户档案重复。这种情况下，上什么平台都只是把混乱搬到新系统里。

第二，老板只想省实施费。

如果出发点只是“让业务自己搭，省掉顾问和开发”，大概率会翻车。ERP、MES项目真正贵的地方，经常是业务梳理、数据治理、接口调试、测试验证和上线切换。工具能提高效率，不能把这些工作变没。

第三，没有IT负责人把关。

低代码应用一多，如果没有IT统一管权限、接口、数据模型、命名规范和发布流程，很快会形成新的系统孤岛。

第四，客户对系统边界没有概念。

什么放ERP，什么放MES，什么放WMS，什么放PLM，什么放低代码平台，如果一开始不画清楚，后面就会互相侵入。结果是每个系统都能做一点，每个系统都不完整。

九、比较合理的落地方式

我更建议企业按这条路走：

第一步，先定系统边界。

ERP负责订单、采购、库存、财务、成本等企业资源主线。MES负责工单、工序、报工、质量、设备、批次等制造执行。低代码平台负责个性化流程、移动应用、扩展表单、业务看板、跨系统协同和部分轻量业务系统。

第二步，先做主数据。

物料、客户、供应商、BOM、工艺路线、组织、人员、仓库、设备这些对象要先管起来。没有主数据，后面低代码搭得越快，数据问题扩散得越快。

第三步，先从外围场景切入。

不要一上来就重写ERP、MES主流程。可以先做异常处理、质量整改、设备点检、模具管理、交付跟踪、供应商协同、项目进度、经营看板等场景。先验证平台能力和组织协同能力。

第四步，建立应用治理规范。

字段命名、表结构、权限、流程发布、测试、版本、回滚、日志、接口文档，都要形成标准。低代码项目一旦进入企业级应用，就不能靠个人习惯。

第五步，再考虑主流程替换。

当企业已经掌握业务建模、数据治理、平台开发和运维机制以后，再逐步替换部分传统系统模块。否则，从零重构ERP、MES主流程，风险太高。

十、结论

用低代码、无代码技术重构ERP、MES，可行，但不能把它理解成“客户自己拖拖页面就能做一套标准软件”。

ERP、MES背后有大量企业管理规则：主数据、BOM、工艺、库存、工单、质量、成本、权限、接口、日志和运维。低代码能提升交付效率，也能让客户更深入参与系统建设，但它不会自动补齐企业缺失的管理能力。

开发能不能交给客户，关键看客户能不能同时接住四件事：

• 把业务说清楚。

• 把数据管起来。

• 把责任定下来。

• 把系统长期维护好。

如果这四件事做不到，低代码会变成另一种形式的定制混乱。如果这四件事做得扎实，低代码反而会成为企业重构ERP、MES外围能力、个性化流程和智能化应用的一条现实路径。

所以我会把它看成一种交付模式的变化：厂商从一次性交付软件，转向提供平台、方法、模板和技术兜底；客户从单纯提需求，转向参与建模、配置、测试和持续运营。

这条路能走，但它要求企业成熟起来。工具越灵活，对管理能力的要求就越高。低代码真正发挥价值的地方，也正在这里。

阅读原文：点击这里​