低代码如何实现与企业现有系统（如ERP、MES、CRM）的无缝集成？

有个现象挺常见。

企业系统越上越多，老板看业务反而越来越费劲。

CRM里有客户，ERP里有订单，MES里有工单，WMS里有出入库，财务系统里有发票和回款。每套系统单独看都没闲着，销售每天录跟进，计划每天看订单，车间每天报工，仓库每天做出入库，财务月底还要对账。

可老板问一句：“这个重点客户的交付风险在哪？”

事情就没那么简单了。

销售导一份重点客户清单，计划导一份订单交期表，仓库导一份库存占用表，车间导一份生产进度表，财务再导一份应收账龄表。几张表摆在一起，数据都是真的，但要回答这个问题，还得有人手工拼：客户是哪一个，订单是哪一批，库存被谁占了，工单做到哪一步，延期会不会影响回款。

这事麻烦就麻烦在这里。

企业系统已经不少，数据也在持续产生。真正缺的，往往是一条能把业务问题串起来的链路。

ERP回答资源和财务问题，MES回答生产执行问题，CRM回答客户和销售过程问题。可客户交付、项目履约、质量异常、售后追责、供应商延期这些问题，天然跨系统、跨部门、跨岗位。它们不会老老实实停在某一个软件模块里。

低代码和ERP、MES、CRM的集成，真正要解决的就是这种问题。

低代码在这里更适合做一层跨系统业务应用。员工在一个入口里提交、审批、查询、追踪；后台再按规则去读ERP、查MES、连CRM、写日志、推通知。主系统继续负责核心数据和业务规则，低代码负责把跨部门动作组织起来。

所谓“无缝集成”，听起来像一句技术话，落到企业现场，其实要回答几个很朴素的问题：

•这条业务数据到底以哪个系统为准？

•谁可以看，谁可以改，谁改了以后要审批？

•低代码平台只是查询，还是要向ERP、MES、CRM写入数据？

•接口失败以后，业务人员能不能看懂原因？

•出了问题以后，能不能查到是哪一步、哪个字段、哪个人、哪个系统出了问题？

这些问题回答清楚了，低代码集成才有意义。

一、低代码要补的是“业务夹层”

很多企业一听低代码能集成ERP、MES、CRM，就容易想偏。

有人觉得可以用低代码把老系统全部替掉。有人觉得低代码就是做几个表单，最多拉个审批流。还有人把它当接口工具，哪个系统缺连接，就让低代码去补一下。

这些看法都只说中了一部分。

ERP、MES、CRM本身都有明确分工。

ERP通常管订单、库存、采购、成本、财务和主数据。企业要知道有什么资源、资源怎么流转、钱和货怎么对应，ERP必须承担主干角色。

MES管车间现场。工单下发、工序报工、设备状态、质量记录、物料投放、生产异常，这些东西离现场更近，不能全部靠ERP里的单据去想象。

CRM管客户。客户是谁，销售跟进到哪一步，商机概率如何，客户投诉和服务记录是什么，这些内容不适合放到ERP里硬管。

问题在于，企业实际经营活动经常卡在这些系统之间。

比如客户临时要求提前发货，销售只看CRM没有用，计划要看ERP订单和库存，车间要看MES产能，仓库要看WMS备货和库位。再比如售后发现质量问题，客服系统里有投诉，MES里有生产批次，ERP里有销售订单，QMS里有检验记录，财务还关心是否要赔付或冲减收入。

这些场景都有一个共同点：单个系统管不了全程，强行改主系统又太重。

低代码适合补的，就是这一层“业务夹层”。

它可以把跨部门表单、审批流程、接口调用、权限控制、通知提醒、异常记录和数据看板放在同一个应用里。员工看到的是一个业务场景，系统背后再去调ERP、MES、CRM的数据和服务。

比如做一个“客户交付风险看板”，前台展示客户、订单、库存、工单、发货和回款状态；后台分别从CRM取客户等级，从ERP取订单和库存，从MES取生产进度，从财务系统取应收数据。管理者不必每天等几个人导表拼表，销售、计划、仓库、财务看到的也是同一条风险记录。

这就是低代码集成的价值。它让原来散在系统边缘的业务动作，变成可提交、可审批、可查询、可追踪的应用。

像织信这类企业级低代码平台，公开资料里可以看到它把表单、流程、权限、报表和接口能力放在同一个平台结构里。对已经有ERP、MES、CRM的企业来说，这类平台更适合做跨系统业务应用和流程协同层，主系统仍然负责订单、库存、工单、客户等核心数据和业务规则。

二、集成前先定主责，不然接口越多越乱

企业做系统集成，最容易犯的错误，是太早谈接口。

CRM要给ERP推客户，ERP要给MES推工单，MES要给ERP回写报工，ERP要给CRM返回库存和发货状态。会议开得很热闹，字段表也拉得很长。

可只要一个问题没讲清楚，后面就会乱：这条数据到底归谁管？

客户名称以CRM为准，还是以ERP财务客户档案为准？

物料编码由ERP维护，还是由PLM或MES维护？

销售订单号在哪个系统生成？CRM里的商机编号能不能当订单编号用？

工单状态到底以ERP生产订单为准，还是以MES现场工单为准？

库存数量看ERP现存量，还是看WMS库位库存，还是看MES线边库存？

这些问题没有标准答案，要看企业系统架构和管理习惯。但不管怎么定，必须有一个明确说法。

举个客户主数据的例子。

CRM里销售需要维护客户联系人、跟进记录、商机阶段。ERP里财务更关心客户开票名称、税号、信用额度、结算方式。两个系统都叫客户，管理重点并不一样。

如果低代码平台做“客户资料变更”应用，不能简单让销售在表单里改完就同步所有系统。比较稳的做法是：

•销售发起客户资料变更，说明变更原因。

•系统自动带出CRM客户信息和ERP客户编码。

•联系人、拜访地址、客户行业这类字段，可以由销售主管审核。

•开票名称、税号、银行账号、信用额度这类字段，要由财务或主数据管理员审核。

•审批通过后，系统通过接口把对应字段写回主责系统。

•每一次字段变更，都要保存改前值、改后值、审批人、接口返回结果。

这套流程不复杂，但它把责任说清楚了。

销售负责客户事实，财务负责结算口径，主系统负责最终数据，低代码负责流程、权限、记录和接口编排。以后客户名称对不上，至少能查到谁提交、谁审批、写到了哪个系统、接口有没有成功。

低代码集成ERP、MES、CRM之前，建议做一张“业务对象主责表”。不用做得很花哨，把关键对象讲明白：

•客户：哪个系统创建，哪些字段可由销售维护，哪些字段必须财务审核。

•物料：编码从哪里来，规格、单位、版本、替代料由谁维护。

•订单：订单号在哪生成，价格、数量、交期、库存承诺由哪个系统确认。

•工单：谁下发，谁接收，谁报工，谁关闭。

•库存：现存量、可用量、占用量、待检量、线边量分别来自哪里。

•合同和发票：业务信息从哪里来，财务口径由谁确认。

这张表做完，后面的接口才知道怎么写。否则接口越多，系统之间互相改数据，最后谁都说自己是对的。

三、查询、写入、事件，不要混成一种集成

低代码平台和已有系统集成，常见方式无非几类：API、WebAPI、HTTP请求、数据库视图、外部数据源、事件监听、消息推送、页面嵌入，老系统实在没办法时还会用RPA。

从产品资料看，企业级低代码平台基本都会强调连接能力。织信文档里能看到开放API、WebAPI、HTTP请求、事件监听、应用依赖、外部数据库等能力。其他企业级低代码产品，也经常会提到连接器、数据源、服务编排、系统嵌入等能力。

但项目现场不能只看能力名称。更重要的是看业务动作。

（一）查询类动作，重点是口径和权限

查询看起来最简单，实际也容易出问题。

比如销售要查库存。ERP里显示某个产品还有1000件，销售就以为都能承诺给客户。但仓库一看，其中600件已经被其他订单占用，200件还在待检，真正能立即发的只有200件。

这时候问题不在接口，而在口径。

给销售看的不应该只是“现存量”，更应该是“可承诺库存”。给计划看的可能要包括在途采购、已占用数量、生产中数量。给仓库看的又要细到库位、批次、质检状态。

所以查询集成要先问：谁要查，查出来用于什么决策，字段代表什么含义，数据多久刷新一次，是否允许导出。

低代码平台可以把不同系统里的数据汇总到一个页面，但不能把业务口径混在一起。字段名相同，含义未必相同；字段名不同，也可能指向同一件事。

（二）写入类动作，必须经过主系统规则

写入比查询危险。

创建客户、修改物料、生成采购申请、调整订单交期、关闭工单、回写报工数量，这些动作一旦写错，会影响库存、成本、财务和交付。

这类集成尽量通过主系统开放的业务接口处理，不要直接改数据库表。

比如低代码平台提交采购申请，写入ERP时不能只往采购申请表里塞一行数据。ERP可能要校验供应商是否有效，物料是否允许采购，采购组织是否匹配，税率、币种、预算和合同是否完整。绕过这些校验，表面上数据进去了，后面收货、付款、成本核算都会冒问题。

写入动作至少要留下几类记录：

•谁发起了写入，对应哪个组织和业务角色。

•写入对象是什么，如客户、订单、工单、采购申请。

•写入前后关键字段分别是什么。

•主系统返回成功、失败，还是部分成功。

•失败原因是什么，是字段缺失、权限不足、状态不允许，还是接口服务异常。

业务人员不一定懂接口代码，但他需要知道这张单为什么没有同步成功，下一步找谁处理。

（三）状态变化类动作，适合用事件触发

企业系统之间最容易断的地方，常常是状态变化。

CRM商机赢单了，ERP要准备建销售订单。

ERP采购订单审批通过了，供应商协同应用要通知供应商确认交期。

MES工单完工了，ERP要更新生产入库或成本归集。

QMS发现质量异常了，MES要暂停后续工序，ERP要冻结相关批次。

这些动作如果靠人工每天刷新，效率低，也容易漏。更好的方式，是把关键状态变化定义成事件。事件发生后，低代码平台根据规则触发后续流程、通知或接口。

不过事件也要克制。

字段变化要分轻重。销售改一句备注，没有必要惊动计划和仓库；但交期、数量、产品版本、收货地址变了，就可能影响库存、生产、物流和财务。哪些字段是关键字段，哪些状态变化要通知谁，哪些变化要审批，必须提前写进规则。

（四）页面嵌入和RPA只能当过渡办法

有些老系统没有API，也没有稳定数据接口。企业又急着把入口统一起来，就会想到页面嵌入、单点登录，甚至用RPA模拟人工点击。

这些办法可以用，但不要放到核心交易链路上。

页面嵌入适合把老系统的查询页放到统一工作台里。RPA适合低频、规则稳定、短期无法改造的操作。页面结构一变、弹窗一多、登录会话一过期，RPA就可能中断。用它救急可以，长期跑采购、库存、财务这种关键动作，风险太高。

四、低代码最适合从哪类场景切入

低代码和ERP、MES、CRM集成，不宜一上来就做全量打通。

全量集成听起来很完整，实际很容易拖成大项目。字段太多，系统太多，责任人太多，最后每个部门都提需求，谁也不愿意先验收。

比较稳的方式，是从一个高频、跨部门、责任清楚、结果看得见的场景切进去。

（一）客户交付风险

这是很多制造企业、贸易企业都关心的场景。

客户在CRM里，订单在ERP里，生产在MES里，库存和发货在WMS里，回款在财务系统里。单独系统都能查，但管理层要看的是风险。

哪些客户订单可能延期？

延期原因是库存不够、采购没到、工单排不上，还是质量异常？

谁正在处理？预计什么时候恢复？会不会影响回款？

低代码可以把这些信息组织成一个风险应用：销售提交客户需求，系统自动读取订单、库存、工单和回款状态；计划、仓库、生产、财务分别处理自己负责的部分；最终形成一条风险记录和处理结果。

（二）生产异常处理

车间出现设备停机、物料短缺、质量异常时，现场往往先在群里喊一声。喊完以后，谁记录？谁判断影响哪些订单？谁通知客户？谁调整排产？谁处理责任和成本？

如果全靠群消息，后面复盘时很难查。

低代码可以做一个异常处理应用。班组长提交异常，系统带出MES工单和设备信息，关联ERP订单和物料信息；质量、设备、计划、仓库按流程处理；处理结果回写MES或ERP，并保留异常原因、停机时长、影响订单、责任部门和改善措施。

（三）采购延期和供应商协同

采购订单在ERP里，供应商回复可能在邮件、微信、供应商门户或Excel里。物料延期后，影响哪些生产订单，哪些客户订单，是否需要改交期，计划员往往要手工查。

低代码可以把供应商确认、延期申请、影响分析、内部审批和客户通知串起来。它不替ERP做采购主数据，也不替MES做排产，但能把“供应商延期”这件事从一条消息变成一条流程。

（四）客户资料和合同变更

客户资料、合同主体、开票信息、收货地址、信用额度，这些字段涉及销售、财务、法务、仓库和客服。变更看起来只是改资料，实际会影响开票、发货、结算和风险控制。

低代码适合做变更申请和审批，把CRM里的业务信息和ERP里的财务客户档案关联起来。哪些字段销售能改，哪些字段财务审核，哪些字段同步ERP，哪些字段只同步CRM，都可以按规则处理。

这些场景有一个共同特点：主系统都有数据，但业务动作跨系统。低代码的作用，是把动作组织起来，把相关数据带出来，把处理过程留下来。

五、真正决定成败的是异常处理

很多集成项目验收时，只看成功链路。

提交一张申请，ERP收到了，MES收到了，页面显示成功。演示通过，项目上线。

可企业系统每天跑，真正考验系统的往往是失败链路。

接口超时怎么办？

ERP成功了，MES失败了怎么办？

同一张申请重复提交，会不会生成两张采购申请？

字段缺失时，业务人员能不能自己补？

主系统返回“状态不允许变更”，页面到底显示什么？

这些问题提前没设计，上线后一定会变成IT救火。

低代码集成至少要准备四个机制。

第一，幂等。

同一个业务动作重复提交，主系统只能处理一次。比如采购申请同步ERP，要用低代码申请单号作为外部业务流水号。用户重复点击、接口重试、网络中断后重新发送，都不能生成两张采购申请。

第二，失败队列。

接口失败不能只弹一个红色提示。系统要保存失败时间、失败原因、请求内容、返回内容、处理状态。临时网络失败可以自动重试；字段错误、状态冲突、权限不足，要转给责任人处理。

第三，对账。

低代码显示已同步，ERP里却没有对应单据，这种问题最麻烦。每天或每周比对关键单据数量、状态、金额、工单号、客户编码、物料编码，可以发现不少隐藏问题。

第四，人工接管。

自动化流程不能把人堵在外面。客户交付风险、采购延期、生产异常这类场景，一旦接口失败，责任人应该能看到失败原因，补充字段，重新同步，或转人工处理。处理完以后，结果也要写回流程记录。

没有这些机制，集成项目看起来能跑，实际经不起长期使用。企业真正怕的是失败以后没人知道，知道以后没人处理，处理完以后查不到。

六、权限和日志要从第一天设计

低代码把多个系统的数据放到一起，权限风险也会被放大。

原来销售只能看CRM，仓库只能看库存，计划只能看工单。现在一个低代码页面可能同时展示客户信用、订单金额、库存状态、生产进度、售后投诉和回款情况。如果权限不分清楚，集成越方便，风险越大。

权限要按三层设计。

第一层是人。

销售、计划、采购、仓库、财务、质量、管理层，对应不同组织、部门和岗位。一个人能看到哪些客户、哪些订单、哪些工单，不能只靠页面隐藏，要有真实的数据权限控制。

第二层是数据。

同样是客户信息，销售可以看联系人、跟进记录、交付状态；财务可以看税号、信用额度、回款和应收；仓库可能只需要看收货地址和发货要求。字段权限要拆开。

第三层是动作。

能看，不代表能改。能改，不代表能直接写主系统。有些字段要审批，有些接口要二次确认，有些动作只能由系统自动触发，有些动作必须人工复核。

日志也要跟上。

一个低代码集成应用，至少要能回答这些问题：

•谁在什么时候发起了申请？

•系统从ERP、MES、CRM分别读取了哪些关键数据？

•用户改了哪些字段，改前改后是什么？

•谁审批通过，谁驳回，意见是什么？

•接口向哪个系统写入了什么，返回结果是什么？

•失败后谁处理，处理结果是什么？

平时没人爱看日志。一旦出问题，日志就是恢复业务、追溯责任、优化流程的依据。

七、选低代码平台，别只看页面拖拽

如果企业的目标只是做几个内部表单，平台选择相对简单。

如果目标是和ERP、MES、CRM集成，选型就要严肃得多。

第一，看连接能力。

平台能不能调用API，能不能配置HTTP请求，能不能连接外部数据库，能不能接收事件，能不能提供开放接口给其他系统调用，能不能和企业统一认证、权限体系对接。

第二，看数据模型能力。

企业业务很少只有一张简单表。销售订单有主表和明细，生产工单有工序、物料、报工和质检记录，客户资料有联系人、地址、合同、开票信息。低代码平台如果只能做简单字段，遇到主从表、子表、关联对象、版本和状态就会很吃力。

第三，看流程能力。

审批、会签、加签、退回、条件分支、超时提醒、自动触发、人工接管，这些在跨系统业务里很常见。流程能力弱，后面就会回到线下沟通。

第四，看权限和审计。

有没有组织权限、角色权限、字段权限、数据范围权限、接口调用日志、操作日志。涉及ERP写入、MES工单变更、CRM客户资料修改时，这些能力属于底线。

第五，看部署和扩展。

很多中大型企业对系统集成有内网访问、私有化部署、数据安全、国产化、信创、接口白名单、审计留痕等要求。平台如果无法进入企业内网，很多ERP、MES、财务系统根本接不上。

这也是为什么企业级低代码平台和普通表单工具的差异会越来越明显。像织信这样的企业级低代码平台，定位更偏中大型企业应用搭建和复杂业务承载，既要能做表单和流程，也要能处理权限、接口、报表、外部数据和一定程度的工程扩展。企业选型时，最好拿真实场景试，不要只看演示页面。

八、一个比较稳的实施顺序

低代码集成既有系统，最怕一开始口号太大。

“打通所有系统”“建设统一门户”“实现数据中台化”，这些话写在方案里好看，落地时往往一堆细节没人认。

更务实的顺序可以这样走。

第一步，选一个具体场景。

不要从“集成ERP、MES、CRM”这个大词开始。从客户交付风险、生产异常处理、采购延期协同、客户资料变更这类具体问题开始。场景越具体，责任越清楚。

第二步，画业务流。

谁发起，谁审核，谁处理，查哪个系统，改哪个系统，最后形成什么结果。业务流画不清，技术架构图画得再漂亮也没用。

第三步，定系统边界。

哪些数据以ERP为准，哪些以MES为准，哪些以CRM为准，低代码里只保存流程记录，还是也保存业务快照。这里要写清楚，不能靠口头理解。

第四步，做字段映射。

字段名相似不代表含义相同。客户交期、计划交期、承诺交期、要求到货日期，听起来都差不多，系统里可能是四个口径。字段映射表要写字段含义、数据类型、必填规则、枚举值、默认值和变更规则。

第五步，设计接口和异常。

查什么，写什么，什么时候触发，失败后怎么重试，谁能人工补救，如何对账。这一步要让业务负责人参与，不能只让开发人员自己定。

第六步，小范围试运行。

先让一个部门、一条产线、一个销售区域或一个产品线试用。试运行期间重点看提交量、驳回原因、接口失败次数、人工补录次数、处理周期和用户反馈。

第七步，再扩到类似场景。

第一个场景运行稳定以后，再复制到类似流程。比如先做客户交付风险，再做采购延期，再做生产异常，再做售后质量追溯。每扩一个场景，都复用前面已经验证过的主责表、字段映射表、接口规范、日志规则和对账办法。

这个顺序看起来慢，实际少返工。

九、不要把“无缝”理解成没有边界

很多企业希望系统之间无缝集成，最后把边界弄模糊了。

CRM能改客户，ERP也能改客户，低代码表单里还能改客户；MES能改工单，ERP能改生产订单，计划员手里还保留一个Excel版本。短期看每个人都方便，过一段时间再看，数据会越来越乱。

好的集成，边界反而更清楚。

哪个系统负责主数据，哪个系统负责交易单据，哪个系统负责现场执行，哪个系统负责流程协同，哪个系统负责报表分析，都要有分工。

低代码可以让企业更快补应用、更快做流程、更快把ERP、MES、CRM周边业务动作系统化。但它不能替企业跳过管理问题。

企业越复杂，越要把数据源头、业务规则、权限边界、异常处理和日志追溯讲清楚。

如果只是做一个临时填报工具，低代码可以很轻。

如果要让低代码接入ERP、MES、CRM，甚至触发审批、改订单、改工单、改客户资料，那它已经进入企业核心业务链路。到了这一步，项目就不能只按“做页面”的方式管理，要按系统集成项目管理。

十、最后给企业一张检查清单

准备做低代码和既有系统集成前，可以先问十个问题。

•这个场景到底解决哪一个业务问题？

•ERP、MES、CRM各自承担什么责任？

•哪些数据只读，哪些数据允许写入？

•每个核心对象的主责系统是谁？

•字段含义是否已经对齐，枚举值是否一致？

•接口失败以后谁能看到，谁负责处理？

•重复提交会不会造成重复单据？

•审批记录、接口日志、字段变更记录能不能查到？

•权限是否按角色、字段、数据范围和操作动作拆开？

•上线后有没有对账和复盘机制？

这些问题如果大部分还回答不上来，暂时还谈不上真正的无缝集成。

低代码能让企业更快补应用、更快做流程、更快把ERP、MES、CRM之间的业务动作连起来。可它真正发挥价值的前提，是企业知道哪些数据归主系统，哪些流程放在低代码，哪些动作必须经过接口、审批、日志和对账。

把这些讲清楚，低代码集成才有意义。

否则，企业只是把原来散在Excel、微信群和人工口头通知里的混乱，换成了一个更好看的入口。