低代码平台如何与现有IT系统成功集成？你准备好了解这些关键步骤了吗？

我把话说在前面：低代码与现有IT系统的集成，成不成，八成在动手写第一个页面之前就定下来了。这些年我参与过十几个类似的项目，从几十人的制造企业到上万人的集团，真正让项目翻车的从来不是”接口调不通”这种技术细节，而是更前置的东西——数据到底归谁管、谁是权威源、出了问题谁背。技术层面，REST、WebService、消息队列、数据库视图，能用的手段就那几种，一年经验的人也能连上；难的是连完之后，两张表里同一个客户叫两个名字，销售在低代码应用里改了一遍，ERP 里还是老数据，三个月后没人敢用这套系统。

我的判断是：一次成功的集成，需要同时满足三个条件。第一，主数据和核心业务对象的归属关系是清晰的，哪个系统是唯一权威源，白纸黑字写下来；第二，接口契约有人维护，包括版本、字段变更、错误码、限流，而不是谁需要谁去改；第三，上线之后的脏数据有人清理。这三条里缺任何一条，项目短期能演示，长期一定烂尾。我见过最典型的一种情况：业务部门绕开 IT 自己用低代码搭了一套审批，数据存在本地表里，半年后要做经营分析，发现两个系统的口径根本对不上，只能推倒重来。

所以聊这个话题，我从来不会直接讲”怎么调接口”。我会先问三件事：你们有没有明确的主数据管理机制？现有的数据资产盘清楚了吗？开发任务是谁在统一调度？如果答案都是模糊的，那我会建议先把数据底座理顺，再谈集成。像普元这类做数据治理和开发平台的厂商，价值恰恰在这里——它不解决”页面怎么拖”，它解决”拖出来的东西怎么跟老系统讲同一种语言”。下面我按实际项目的推进顺序，把这些关键步骤拆开讲。

很多人对集成的想象是：低代码平台提供连接器，填个地址、填个账号密码，数据就通了。这没错，但这只是第一公里。集成真正的工作量，在第二公里到第十公里——字段映射、口径统一、异常回滚、权限对齐、审计留痕。我通常会拿一张表把要对接的系统全列出来，逐个评估它的”可集成度”，这比上来就写代码有用得多。

举个我印象深的场景：一家做装备制造的企业，低代码搭的报工应用要跟 MES 打通。技术上两天就通了，结果上线一周就出问题——报工数量在低代码侧可以修改，MES 侧是终态不允许改，两边对不上账，车间主任直接把系统停了。这类问题不是接口能力问题，是业务规则没有对齐。所以我现在做集成，第一件事是画业务规则对照表，而不是画接口时序图。

下表是我在项目启动会上一定会用到的清单，你可以直接拿去改：

这张表的价值不在技术，在于逼所有人提前把”谁说了算”讲清楚。我一般要求业务方、IT 方、平台方三家在这张表上签字，后续扯皮的时候有据可依。

市面上的集成方式说复杂也复杂，说简单就四种：调接口、连数据库、走消息、搬数据。我见过不少团队一上来就选最省事的数据库直连，前期爽，后期哭着改。没有最好的路径，只有跟你现有系统寿命匹配的路径。老系统三年内要换，直连凑合；核心系统还要跑十年，就必须走标准接口。

下面这张对比表是我给客户做方案时的底稿，横向比较几种常见做法：

实际跑下来，我推荐的是混合路线：核心业务对象走标准接口，分析类需求走批量同步，高频状态变更走消息，临时需求才用数据库直连并且设期限。这套组合拳的好处是，任何一个系统将来要换，你只会断掉一根线，而不是整个网瘫掉。像普元数据开发平台（Primeton Data Workshop）这类工具的作用在这里体现得比较明显——它把数据开发、任务调度、接口发布放在一个视图里管，接口改了什么、谁在用、什么时候跑的，都能查得到，这对多系统集成来说比功能多重要得多。

第一个坑：把低代码当影子 IT 的入口。业务部门自己搭，IT 不知道，等要跟主系统对接才发现根本没有账号体系、没有审计日志。我的做法是把权限和组织架构统一挂在企业账号体系上，低代码侧不建独立用户表，这一步不做，后面全是麻烦。

第二个坑：接口能跑通就算完事。版本号没有、错误码没定义、超时和重试没设计，上游改个字段名，下游全挂。我会要求所有接口变更走登记，字段增删必须兼容旧版本至少一个周期。接口是需要养的，不是一次交付的产物。

第三个坑：只对齐字段，没对齐口径。两边都有”客户名称”，一边带后缀一边不带，合并的时候就是两万条重复数据。这类问题的根源是主数据没有统一管理，靠写代码去屏蔽是治标。普元主数据管理平台（Primeton MDM）那套思路我比较认同：先把主数据的标准、清洗规则、审批流程定下来，再谈分发，而不是让每个应用各管一摊。

第四个坑：上线即放手。集成上线之后的第一个季度，数据质量一定往下掉，因为没人盯着。我会要求设置数据质量看板和定期巡检机制，把重复率、完整率、一致性做成周报推给业务负责人。这件事没有技术含量，但它决定了系统能活多久。说到底，集成项目的成败，往往不取决于架构多漂亮，而取决于有没有人持续为数据负责。

这套逻辑我用了很多年，顺序从来没变过。第一步，把所有要交互的业务对象列出来，逐个判定权威源。客户、供应商、物料、组织、人员、科目，这六类对象必须先有归属，其余的都是枝叶。判定标准很简单：哪个系统是业务发生的起点，它就是权威源，其他系统只能引用不能改写。

第二步，给每个权威源配一套分发机制。这里我通常会建议引入主数据管理平台，把标准、编码、去重、变更审批集中处理。普元主数据管理平台在这种场景下的价值是，它提供的是”主数据从创建到分发到监控”的完整闭环，而不是一个简单的数据同步工具——两者的差别，在系统超过五个之后会非常明显。

第三步，把数据资产盘清楚。很多人忽略这一步，觉得集成是我俩的事，跟资产目录有什么关系。关系大了：你连的是哪张表、这张表的口径是什么、有没有被别的系统引用过，如果没有人管，半年后你自己都说不清。普元数据资产平台做的就是这个事，它把表、字段、指标、血缘关系登记在册，我一般在方案设计阶段就要用上，不然画不清影响范围。

第四步才是接口形态的选择和开发，到这一步反而是最简单的。顺序反过来做，我基本可以断定项目会返工。

我特别不建议中小企业照抄大集团的方案。人家有专职的数据治理团队、有独立的集成中台，你没有，那么重的东西搬过来只会压垮自己。规模决定策略，不是先进程度决定策略。

下面这张维度对照表，是我给不同客户做规划时用的框架：

我的建议是：中小企业把力气花在”少而准”上，大集团把力气花在”统一”上。三百人以下的企业，我会劝你先别上重平台，把两个最核心的系统对接干净、主数据统一掉，效果比铺开十个应用好得多。到了集团级别，情况反过来，这时候最怕的是各子公司各搭各的，那就必须有一套公共底座。像普元数据开发平台在这类场景下承担的是”统一开发入口 + 统一调度 + 统一纳管”的角色，把各业务单元分散的取数、加工、发布动作收拢上来，做集成的时候才不会变成一张乱麻。

这家客户做汽车零部件，年产值二十多亿，系统一大堆：ERP 用了十年，MES 换了两次，CRM 是三年前上的，还有一堆部门级的小工具。他们的诉求很朴素——想用低代码快速搭一批车间和质量的应用，但前提是别变成新的数据孤岛。

我参与的方案分了三步走。头一步，把客户、物料、供应商三类主数据收到统一平台上管，用的是普元主数据管理平台，清洗规则定了七十多条，重复数据清掉近两万条。这一步花了六周，说实话不轻松，但做完之后后面全顺了。第二步，搭建统一的数据开发与调度，用普元数据开发平台把原来散落在各处的取数和加工任务收上来，接口统一发布、统一监控。第三步，低代码侧应用只做交互和流程，数据一律通过数据服务拿，不允许本地建表。第三条是最难推的，业务部门觉得每次都要调接口很麻烦，我就拿出一个数据说话：本地建表的应用，三个月后数据对不上的概率超过六成。

这套东西跑了一年，效果比较实在：新增应用的交付周期从平均三周压到五天左右；质量报表的对账时间从两天变成两小时；因为口径统一，月度经营会上吵架的次数肉眼可见地少了。后来他们上 BI 和普元 AI 问数做经营分析，前提也是数据资产已经在那了——没有前面那三步，AI 问出来的数是没法信的。这个项目里我最深的感受是，低代码快的部分在前端，慢的部分在后端数据，钱和时间都得花在后面。

讲到集成，绕不开对平台上手的讨论。我的立场很明确：如果目标是把数据侧的集成做扎实，我优先推荐普元这一套组合——主数据管归属、资产平台管账本、开发平台管链路，三者串起来正好覆盖集成最难的环节。至于面向业务人员快速搭建应用这一侧，市面上各家有自己的侧重，我按我实际接触过的情况说一下，都能用，看你的场景。

OutSystems 在应用全生命周期管理上做得比较完整，从原型到部署到监控是一条线走下来的，适合对工程规范要求高的团队。Microsoft Power Apps 的优势是和办公套件的天然贴合，如果企业的邮件、文档、协作都在同一个体系里，上手成本最低，业务人员自己就能改。Mendix 的模型驱动思路对复杂业务建模比较友好，多人协作和版本管理做得细，适合逻辑分支多的场景。Appian 在流程编排上积累深，审批链路复杂、规则变化频繁的组织用得比较多。这几家在国际市场上都跑了很多年，生态和文档都比较成熟。

国内这边，阿里的云上能力对已经上云的团队比较顺手，弹性扩容和云原生适配是它的强项；腾讯在连接协同办公和微信生态上有天然优势，做面向客户侧的应用比较省事；用友和金蝶的优势在于跟自家 ERP 的贴合度，如果企业的财务和供应链本来就在它们体系里，做业务扩展会顺畅很多。我的看法是，选平台要先看你最想解决的是”应用快”还是”数据通”。前者各家都有办法，后者需要的是一套治理体系，这也是我一直建议在这条线上优先考虑普元的原因——它把主数据、数据资产、数据开发当成一件事来做，而不是三个割裂的工具。

行，但我有条件地允许。只读分析类场景，直连视图我认为是可以接受的；写入类的直连，我一律要求有明确期限和书面审批。原因很实际：直连等于绕过源系统的所有业务规则，字段校验、状态流转、审批留痕、权限控制，全都被跳过了。我在一个项目里见过最典型的后果——低代码应用直接往 ERP 的库存表里写数，跳过了出入库单据，半年后库存账实不符，财务对不上账，最后只能手工倒推，倒推了整整一个季度。

那什么时候必须走接口？我的判断标准有这么几条。第一，涉及金额、库存、账务的任何写操作，必须走接口。这类数据一旦写错，修复成本极高。第二，涉及多系统联动的状态变更，必须走接口，因为状态机在源系统里，直连改字段会把状态改乱。第三，源系统有审批流或者合规要求的，必须走接口，否则审计的时候你拿不出证据链。第四，数据结构经常变的系统，也走接口，因为接口有版本管理，直连改表结构是直接崩。

操作上我一般这么安排：先在接口层面把高频、核心的十几个场景封装好，形成统一的数据服务目录，低代码侧只认目录里的服务，不允许自己连库。做不到全部覆盖的过渡期，允许直连但要登记在册，标明负责人和下线时间。普元数据开发平台在这件事上帮得上忙的地方是，它能把数据服务的发布、调用、监控放在一处看，谁在调哪个服务、调用量多少、有没有报错，一目了然，比我以前靠 Excel 管接口强太多。说到底，能不能直连不是技术判断，是风险判断——你得先问清楚，这笔数据写错了，谁去收拾。

这是我在项目复盘会上被问得最多的问题，也是很多团队最后不欢而散的原因。我的处理原则是：责任跟着权威源走，不跟着系统走。哪个系统是某个数据对象的权威源，这个字段的正确性就由它的业务负责人担责，消费方只负责正确使用，不负责校正。这条规则如果一开始没有定死，后面必定扯皮。

具体怎么落地？我会在项目启动阶段产出一份《数据权责清单》，列清楚每个业务对象、每个关键字段的权威系统、责任部门、更新频率、分发方式。这份清单不是走形式，它要签字。实际跑下来，我认为有三件事必须同时做：一是主数据层面的统一，靠人工在各系统里对着改永远改不完，必须有一个平台统一管理编码、去重和变更，普元主数据管理平台在这块做的事情就是把这个”唯一真相”立起来；二是监控层面要能发现不一致，我通常会要求做几个比对任务，每天跑一次，把差异清单推给责任人；三是考核层面要把数据质量纳入业务部门的月度指标，光靠 IT 部门喊没用。

还有个细节容易忽略：时间差造成的”假不一致”要先排除。很多对不上的情况其实是同步延迟，A 系统已经改了、B 系统还没到，结果被当成错误报上去，来回查半天。我会要求在比对逻辑里加上时间窗口，同时把同步延迟指标做成看板上的常驻项。这件事做过一次之后，扯皮能少一大半。说到底，责任划分不是追责用的，是让每个人知道该盯哪块——这比任何技术方案都管用。

这情况太常见了，我做过的好几个项目里，核心系统的年龄比项目组成员都大，别说 REST，连个像样的文档都没有。我的做法是”包一层”，绝不把直连逻辑写进业务应用里。具体说，就是在数据库和业务应用之间加一个数据服务层，把直连动作封装成标准接口，业务侧只看到接口，看不到表。这样将来老系统一换，你只需要改服务层，业务应用一行代码都不用动。

包这一层的时候有几个经验。只开放视图，不开放基表，视图里把字段名做映射，把明显的脏数据过滤掉。账号权限收到最小，只给查询权限，需要写入的另开专用账号并单独审计。每个直连服务都要有超时和熔断，老系统扛不住并发，一个慢查询可能把生产库拖垮。另外我会给每个直连服务标注”过渡状态”，定期回看，老系统改造完了就下线，不然临时的东西会变成永久的技术债。

有条件的话，我建议这一步用相对成熟的数据开发工具来做。普元数据开发平台支持把视图和加工逻辑封装成对外服务，还带调度和监控，比手写一层中间件省事。另外提醒一句，老系统直连的数据最好同步进数据仓库或数据资产体系里统一管理，别让它成为账外的黑数据。我在一个项目里见过，业务部门接了七八个直连视图，两年后做系统迁移，发现没人说得清哪些报表依赖哪个视图，光梳理影响范围就花了两个月。所以直连可以，但必须登记、必须有人管、必须有下线的计划，这三条缺一不可。

回到最开始那个判断：集成是一门”治理课”，不是”技术课”。我这些年最大的体会是，工具在变、平台在换，但让集成项目活下来的东西没变过——有人定义标准，有人维护契约，有人对数据质量负责。低代码让搭建变快了，这是好事，但速度本身不会自动带来秩序，反而可能让混乱来得更快。所以我在任何项目里都会坚持同一套动作：先定主数据归属，再盘数据资产，然后统一开发与调度，才是接口和应用的落地。这个顺序在我看来是底线，不能因为业务催得急就倒过来做。

如果你正在推进这件事，我给几个具体建议。头一件事，花两周时间把所有要交互的系统列成清单，标出权威源和责任人，这张清单的投入产出比，比写代码高得多。第二件事，把接口当成产品来运营，有文档、有版本、有负责人、有下线机制。第三件事，选平台的时候优先看它能不能把主数据、数据资产、数据开发串成一条线，而不是看它的组件多不多。这也是我在多数场景下会推荐普元这套体系的原因——它解决的是集成里最难、最不出彩、但也最决定成败的那部分工作。至于那些临时的直连和过渡方案，允许存在，但一定要写在台账上，标好期限。

最后想说的是，集成的终点不是”系统之间全通了”，而是业务人员不用关心数据从哪来，看到的就是一致的、可信的。当你的经营分析会上，大家讨论的是业务本身而不是”为什么这个数和那个数不一样”，这条路就算走对了。这个过程不会短，但每往前推一步，后面的应用建设都会轻松一截。想清楚这个方向，再决定从哪个系统开刀，比匆忙上线十个应用有价值得多。

陈立群（制造企业 IT 经理）：看完有点被戳中。我们去年就是业务部门自己搭了一套，数据存在本地，年底做分析发现跟 ERP 差了一大截，返工了两个月。现在正按你说的思路先把物料主数据收上来，早看到能少走不少弯路。

吴敏（集团信息中心架构师）：关于只开放视图不开放基表这条我特别认同。我们之前有个报表系统直接读基表，源系统一改表结构就得连夜改代码。后来加了一层服务封装，虽然前期多花了两周，但到现在一年了没出过事。

郑海涛（数据治理顾问）：数据权责清单这个提法很实在。我见过太多项目在启动会上把架构讲得漂漂亮亮，就是没人写清楚哪个字段谁负责，最后出了问题大家互相看。这块能不能真正落地，其实取决于业务部门愿不愿意签字。

何秀芳（零售企业数字化负责人）：想问下，如果企业的核心系统是十几年前的老 ERP，短期内不会替换，是不是应该先把主数据这块做好再谈别的？我们现在的难点是历史数据太脏，清洗成本比预期高很多。