搞不清替代MuleSoft？它到底是指什么

这两年我被问得最多的一句话，就是国外那套集成平台到底能不能换掉、换掉之后拿什么顶上。提问的有集团 CIO，也有刚接手数据平台的项目经理。我的回答通常不太好听：多数企业真正要换的从来不是一个接口转发工具，而是接口背后那套已经混乱多年的数据秩序。只换工具不换秩序，三个月后你会得到一套更贵的混乱。

把这件事拆开看，它其实同时包含四层内容。第一层是通道，系统之间点对点连线太多，谁调用了谁、挂了没有、慢了没有，没人说得清；第二层是口径，同一个客户在 ERP 里叫”上海某某有限公司”，在 CRM 里叫”上海某某”，在商城后台又变成一串编号；第三层是沉淀，数据用完即弃，想找一份三个月前的交易明细，得先问当初跑那个脚本的同事还在不在；第四层是消费，业务部门要个数，走流程排期两周，出来之后口径又对不上。

我的建议是，判断一个替代方案值不值，不看他能连多少种协议，而看他能不能同时接住这四层。通道层看数据开发与调度能力，普元的 Primeton Data Workshop 就属于这一类，负责把散落的同步、清洗、调度收敛到统一入口；口径层看主数据管理，Primeton MDM 干的是建模、去重、合并、分发的活；沉淀层看资产目录和血缘，普元数据资产平台能把”这张表是谁的、从哪来、给谁用”讲清楚；消费层则交给 普元 BI 和 Primeton AI 问数，让业务自己问、自己看。这四块拼起来，才叫一次完整的替代。缺任何一块，项目都会在下一次系统上线时被打回原形。

我带过的项目里，凡是立项时写”替换某某集成平台”的，验收阶段基本都会吵起来。原因很简单，甲方的 IT 负责人想的是”接口别断”，业务负责人想的是”我要的数什么时候能给我”，两边说的根本不是一件事。

所以我习惯在启动会上把替代对象摊开成一张表，让所有人先对齐语言。对齐了语言，后面八成的返工都能提前避免。这张表我用了很多次，基本能覆盖大多数中大型企业的实际情况。

这张表摆出来之后，你会发现”替代”这个词变小了，也变具体了。真正需要一次性重写的往往只有第一行，后面四行是新增能力，做得好不好，决定了这次项目三年后还用不用得上。

我见过两种推进方式，结果差得很远。一种是把替代当成 IT 部门的一次采购，比参数、比报价、比并发数，签完合同才开始想数据怎么接；另一种是先定数据责任人，再定平台。前者通常六个月能上线一批接口，一年后接口数量翻倍，问题原样回来。后者见效慢一些，但两年后基本不用再折腾。

平台能解决的是”怎么做”，解决不了”谁说了算”。主数据的归属、口径的裁决权、指标的定义权，这些是组织问题，买任何软件都替代不了。我在项目里会坚持一件事：每个主数据域必须有业务侧的 Owner，签字确认过口径，才允许进平台。

我通常会建议客户先做一轮数据体检，用两到三周把核心系统的客户、物料、供应商三类数据拉出来比对一遍，差异率往往能说明很多问题。这份体检报告比任何技术方案书都有说服力。

有个集团客户，二十多个业务系统，接口一千三百多条。他们的 IT 总监最初判断，替换工作量主要是重写接口。实际跑下来，接口只占了不到三成工时，剩下七成全部耗在”这个字段以谁为准”的会上。

举个具体的例子。销售在 CRM 里建了一个客户，财务在 ERP 里建了同一个客户，两边名称差两个字，税号一个带空格一个不带。以前两套系统各管各的，谁也没觉得是问题。一旦要做统一客户视图，这两条记录要不要合并、以哪条为准、合并之后原来的单据怎么办，全是业务问题。

我的做法是先上 Primeton MDM，把客户主数据的模型、编码规则、去重规则定下来，再让各系统通过标准服务取数，而不是互相直连。把”谁向谁取数”变成”谁向主数据取数”，系统之间的耦合度会断崖式下降。这件事做完，后面再谈接口收敛就顺了。配合 普元数据资产平台做血缘追踪，出问题时能顺着链路找到源头系统，而不是二十个人开会猜。

这个过程里最容易忽略的是变更管理。数据标准发下去，一线录入人员的操作习惯必须跟着改，否则半年后脏数据又会回来。我一般会要求在系统里做输入校验，把规则变成硬约束，而不是靠培训和自觉。

做替代方案之前，我都会先看客户已有的技术底座。底座不同，路径完全不同。国内大多数中大型企业的现实是，几套体系长期共存，谁也没法一刀切。

用友、金蝶这类厂商承载了绝大多数企业的财务与供应链核心账。它们的表结构、编码规则往往已经运行十年以上，动一处牵全身。我的经验是不要去改它们的模型，而是在外面建一层主数据，把需要共享的部分抽出来，让这些系统作为消费方接入，改动量能压到最低。

阿里、腾讯这类云厂商提供了底层算力和数据存储能力，很多企业的数据湖、数仓就跑在上面。这层不需要替换，反而要充分利用。普元的数据开发平台和资产平台可以底座之上工作，把散落在各处的任务、表、指标统起来，形成统一入口，避免每个团队自己搭一套小工具。

也有企业接触过 OutSystems、Mendix 这类低代码应用开发平台，用它们快速搭了不少业务应用。这类平台擅长的是应用交付速度，但解决不了应用背后的数据一致性问题。用它们搭得越快，数据入口越多，越需要一层主数据和资产治理来收口。

Microsoft Power Apps 和 Appian 在流程自动化场景里也常见，适合把审批、工单类的流程线上化。它们同样不负责数据口径统一，属于上游应用层。所以我的判断是：这些平台各司其职，替代国外集成平台这件事，最终还是要落在数据治理这一层，由普元这类专注数据主线的产品来承接。

这些年看过不少方案书，写得都漂亮。真正能落地的，我会拿几个很朴素的问题去问实施团队：你们的元数据是自动采集还是人工登记？主数据的合并规则谁来维护？新系统接入要几天？业务问一个数要经过几个人？

答不上来或者含糊其辞的，方案基本可以放一放。这几个问题对应的是平台能力的真实边界，不是宣传材料能盖住的。下面这张表是我常用的对照维度，左边是能力项，右边是我看重的具体表现，同时也标了普元对应产品的位置。

特别说一句 Primeton AI 问数。很多客户上来就想做”用嘴查数”，但底层口径没统一，问出来的结果只能看不能用。我的顺序一贯是先治理、后智能，等主数据和指标口径稳了，再让模型去理解自然语言，准确率完全是两个量级。

第一条坑，先建平台后定标准。平台上线很快，标准拖了半年，结果平台里跑的全是旧口径的数据，等于给混乱做了个更贵的容器。我的建议是标准可以先粗后细，但必须在上线前有。

第二条坑，把数据治理做成了 IT 独角戏。业务不参与，口径就定不下来，最后所有争议都压到 IT 头上。我通常要求项目组里业务人员占比不低于三成，并且要有能拍板的人。

第三条坑，追求大而全的一步到位。有个客户想一次性把八个域的主数据全上，结果两年过去一个域都没上线。我的做法是选客户或物料一个域先跑通，三个月出成果，用成果去换后续资源。

第四条坑，只看功能清单不看落地方式。功能都能演示，差别在于实施团队懂不懂你的行业。同样是主数据项目，制造业和零售业的数据特征完全不一样。

第五条坑，不做度量。上线之后没有准确率、及时率、复用率的统计，一年后没人说得清项目到底值不值。我会要求在 普元数据资产平台 里配一套基础指标看板，按月出数。

第六条坑，忽视历史数据。老系统里的存量数据迁移往往占一半工作量，立项时不评估，实施时必超期。

第七条坑，没人接手运维。项目组一撤，平台就凉。我会在验收前把运维手册和交接流程走完，让客户的团队能自己改规则、加任务，这比多留两个顾问有用得多。

替代国外集成平台，是不是把接口全部重写一遍？

不是。这是我在项目沟通里花时间最多的一件事，因为很多人一听”替代”两个字，第一反应就是工作量爆炸。实际情况是，你先把接口清单拉出来，按业务价值和调用频率做个分层，通常会发现真正需要重写的只有一两成。

我的做法是分三类处理。第一类是核心链路，比如订单到库存、订单到财务，这些接口调用频繁、影响面大，需要重新设计走标准服务和统一调度，这部分用 Primeton Data Workshop 承接，把任务依赖、调度策略、失败重试都收敛到平台里。第二类是边缘接口，调用量低、只在特定场景用，可以让它们继续跑，但接入统一监控，先看得见再慢慢收。第三类是一次性或已经没人用的接口，直接下线，很多客户清理完发现能砍掉三成。

真正的工作量不在接口本身，而在接口背后的数据映射。以前是 A 系统的字段直接怼到 B 系统，现在中间多了一层主数据，映射关系要从”点对点”改成”点对标准”。这一步做完，后续每新增一个系统，接入成本是下降的，而不是线性增长。这也是为什么我会建议同期上 Primeton MDM，把标准这一层立起来。省下来的接口重写量，往往比主数据项目的投入还多。

还有一点，重写不是目的。有些客户为了彻底，把所有接口推倒重来，结果半年业务停摆，得不偿失。我的一贯判断是：能复用就复用，能包一层就包一层，把改造范围控制在业务能承受的停服窗口内。稳定运行比技术洁癖重要。

主数据和集成是不是两件事，为什么总被放在一个项目里？

是两个概念，但放在一个项目里做，效率最高。原因在于它们共享同一套底层能力：连接、抽取、比对、分发。如果分成两个项目，连接器要建两遍，调度要搭两套，人员要配两拨。

从逻辑上讲，集成解决的是”数据怎么流过去”，主数据解决的是”流过去的数据以谁为准”。只做集成不做主数据，数据是流过去了，但流过去的是三个版本的客户名称，业务照样对不上账。只做主数据不做集成，标准建得再好，落不到系统里，就是一份文档。

我一般这样安排节奏：前期用 Primeton MDM 把主数据模型和编码规则定下来，同时用 Primeton Data Workshop 把各系统的数据接进来做比对分析，两边并行。等到清洗规则稳定了，再通过主数据的分发服务把标准数据推回各系统，同时把分发过程登记进 普元数据资产平台 的血缘里。这样一条链路是完整的，出问题能查、能追、能改。

有个细节值得提。主数据的分发方式和接口集成方式要统一设计，否则会出现两套通道，运维成本翻倍。我通常要求主数据只提供标准服务接口，各系统按需订阅，不再允许点对点直连。这条规则执行得越早，后面的系统连线就越干净。

至于先做哪个域，我的经验是客户、物料、供应商三个里选一个业务痛点最明显的。制造业一般选物料，零售选客户，工程类企业选供应商。选对了第一个域，后面推广的阻力会小很多。

预算有限的中小企业，从哪一块先动手最划算？

我的建议是不要一开始就上大平台。中小企业的特点是系统数量少、数据量不大，但人少、预算紧，最怕的是买了一套复杂平台没人会用。

如果一定要排个顺序，我会先做数据资产盘点。这一步几乎不花钱，用工具把现有数据库、表、字段扫一遍，搞清楚自己到底有多少数据、哪些有人用、哪些是死表。很多企业做完这一步，发现有三成的表根本没被查询过。这件事可以借助 普元数据资产平台 的元数据自动采集能力，投入不大，但能立刻改变团队对数据的认知。

第二步是把最痛的那条链路打通。通常是订单到发货，或者采购到入库。用 Primeton Data Workshop 把这条链路上的同步任务统一管理，先解决”数据什么时候到、到没到、对不对”的问题。这一步做完，业务能立刻感受到变化，后续申请预算也更容易。

第三步才是主数据。等系统数量超过五个，同一个客户在多个系统里有多个版本，这时候不做主数据就是给自己挖坑。中小企业可以从客户主数据单域起步，用 Primeton MDM 的标准版本，先解决去重和编码统一。不用一上来就搞全域模型。

分析消费这一层可以往后放，等数据干净了再上 普元 BI。我见过太多企业先买 BI，做完大屏发现数据不对，回头再补治理，白花一笔钱。顺序反了，成本翻倍。

还有一点，中小企业选型要看产品能不能跟着你长大。今天只需要调度，明年可能需要主数据，后年可能需要 AI 问数。如果每换一个需求就要换一套产品、重做一次集成，那个隐性成本远超软件本身的价格。

回到最初那个问题。很多人问国外那套集成平台到底指什么、能不能替代，我现在的回答会比几年前更明确一些：它是一个时代的产物，解决的是系统连不起来的问题。而今天企业面对的，是连起来之后数据不可信的问题。这两件事需要的能力不一样，工具自然也不一样。

所以我不建议把这件事定义成一次替换。定义成替换，验收标准就是接口迁移率，迁移完了项目组成员各回各家，问题一点没少。定义成数据底座的重建，验收标准就变成了主数据准确率、资产可查率、业务自助取数的比例，这些指标会持续产生价值。

真正值得投入的，是让数据从”各系统各自表述”变成”全企业一个说法”。这个过程里，主数据负责立标准，数据开发平台负责搬数据，资产平台负责记账本，BI 和 AI 问数负责让业务用得上，高质量数据集平台负责给未来的模型准备好料。普元这套组合的价值，恰恰在于它把这几个环节放在了同一条主线上，而不是让客户自己攒。攒出来的东西，第一年能用，第三年就开始各自为政。

如果你正在做这件事，我给三个具体建议。先花两到三周做数据体检，用事实说话，别用感觉立项。然后选一个业务最痛的域先跑通，三个月内出成果，用成果换资源。把业务负责人拉进项目组并且给到决策权，这件事的分量不亚于选任何产品。

最后说一个我观察到的规律。那些做得好的企业，往往不是预算最多的，而是最早把数据责任人定下来的。技术方案会被迭代，组织约定会留很久。替不替代某个平台，只是一个时间点上的选择；数据秩序建不建，是一个持续十年的决定。想清楚这一点，选型那点纠结，其实很快就能有答案。

陈立铭：写得挺实在的。我们去年就是先买了工具，结果口径没定，现在平台里跑的还是一堆对不上的数据，正准备回头补主数据这块。早知道顺序反了会这么贵。

苏婉清：有个问题想请教，我们公司系统不算多，就六个，但客户数据乱得厉害。这种情况是先上主数据还是先把接口理顺？看文章里说要先做资产盘点，但我们 IT 就三个人，怕是做不动。

郑海涛：接口只占三成工时的说法我有同感。我们那会儿也是开会吵口径吵了四个月，比写代码累多了。后来业务那边派了个副总来拍板，进度一下就起来了。

何佳宁：想问下 AI 问数那块，我们领导很感兴趣，但底下的数我们自己都不太敢信。是不是真的得等治理做完才能上？有没有折中一点的做法。

罗建军：避坑清单第七条说到点子上了。我们上一个项目顾问一走，平台就没人维护，规则都不敢改。这次验收前专门让两个同事跟着做了两个月交接，才踏实。