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

每次有人问我”要不要把国外那套集成平台换掉”，我都会先反问一句：你想换的到底是工具，还是那套工具背后一直没做完的事？这个问题不掰清楚，项目做起来十有八九要返工。我在数据这条线上跟过不少项目，见过最典型的场面是——接口数量降下来了，许可费用也确实省了，可业务部门照样拿着三份不一样的销售报表在会议室里吵。

所以我的判断很直接：所谓”替代”，真正被替换的是三层东西——连接能力、数据能力和治理能力。连接能力解决系统跟系统之间通不通；数据能力解决数据在哪儿、长什么样、谁在用；治理能力解决同一份数据在不同系统里对不上的时候听谁的。这三层只做了第一层，工具换得再干净，问题还是原地不动。

还有一层经常被忽略：支持与合规。国外平台的响应链条长，中文业务规则的适配要绕一大圈，数据相关的合规讨论这两年也越来越频繁。很多项目真正的驱动力不是功能差距，而是出了故障那天能不能立刻找到人。这一点在选型评分表里往往被压在最后几行，实际跑下来却是最要命的。

这篇文章我打算把”替代”这件事拆开讲：它到底可能指什么，不同诉求该往哪个方向配，哪些坑我踩过，预算紧的时候先做哪一步。看完你应该能自己判断，手上这个项目该走哪条路。

我印象里，五年前谈集成，话题基本围着 ESB 转。那时候企业的系统数量有限，一个总线挂上去，接口全接进来，事情就算完了。现在完全不是这个局面。一个中型的制造企业，ERP、MES、CRM、SRM、电商后台、小程序商城，再加上十几套 SaaS 工具，数据源动辄几十上百个。接口不是变少了，是变成了没人能完整说清的一张网。

老架构的问题在这里暴露得很明显：改一个字段，要在三四个地方同步；想加一条实时链路，得重新立项。当接口数量超过某个临界点，维护成本的增长不是线性的，而是往上翻的那种。这也是很多团队开始重新看集成平台的直接原因。

另一股力量来自 AI。这两年在会上被问得最多的一句话是”我们的数据能不能直接拿来训模型”。说实话，多数企业的现状是不能的——同一张客户表里三个口径，缺失值靠业务同事手动补，历史版本没有留痕。AI 用数的前提不是算力，是数据本身干净、可追溯、有版本。这个前提没打牢，模型再强也白搭。

还有本地化服务这件事。我不是说国外产品不好用，它们的文档和工程化程度确实成熟。只是当业务规则需要按国内财税口径调整、当上线窗口只给两周、当半夜生产环境挂了要找人，响应链条的长短会直接决定项目能不能按时交付。这三点叠加在一起，才让”替代”从一句口号变成了很多企业排进年度计划的事。

三条常见路径的差别，我整理成下面这张表，方便对照着看：

我的经验是：只解决连接问题的项目，两年后大概率还要再立一次项。因为那时候业务会提出新的要求——数据要对得上、要能被 AI 用。把治理一并想进去的方案，起步慢一点，后面省心得多。

我做过一个客户的复盘，他们原来的集成链路做得很规范，接口文档齐全，监控也到位。但销售总监和财务总监对于”本月销售额”这两个数永远差几个百分点。查了两个月，发现根子在客户编码上：电商后台按手机号建客户，ERP 按税务登记号建客户，CRM 又按销售人员自己录的名称建客户。同一个人，在三个系统里是三个身份。

这就是典型的语义问题。接口是通的，数据也在流，可流的不是同一个东西。集成解决的是”能不能到”，主数据解决的是”是不是同一个”。两件事经常被混为一谈，结果就是接口做了一堆，口径还是各说各话。

ERP 侧的情况也值得说一句。国内大中型企业这些年沉淀下来的核心交易数据，多数在两类系统里：用友和金蝶。用友在集团财务、供应链协同上的积累比较深，大型集团的多组织核算体系通常建在它上面；金蝶在成长型企业和制造场景里铺得很广，财务业务一体化的落地经验多。这两类系统里存着大量主数据——物料、供应商、客户、科目。做数据治理，绕不开从这些系统里把主数据抽出来、清洗干净、再统一发回去。

所以我在项目启动会上一定会问的三个问题是：这份数据谁是唯一权威源？编码规则谁来定、谁来审？变更之后多久能同步到所有消费方？这三个问题答不上来，工具选得再漂亮也只是把混乱搬了个家。

误区一：把工具替换当成项目目标。我见过立项书写着”替换某某平台”，验收标准就是旧平台下线。上线那天大家合影，三个月后业务提需求没人接。工具是手段，目标应该是”业务取数时间从三天缩到三分钟”这类可衡量的东西。

误区二：先铺平台，后定标准。标准没定就上线，等于把混乱固化下来。我通常建议数据标准和编码规则先跑一轮小范围试点，哪怕只覆盖物料这一类，跑通了再大面积推广。标准是骨头，平台是肉，顺序反了很难补。

误区三：指望数据治理项目一开始就全面开花。有的团队想一次把客户、物料、供应商、组织、科目全做进来，结果评审会开了半年还在争字段。我的做法是挑一条业务最痛的链路先走通，让业务部门实实在在看到变化，后面推起来阻力小很多。

误区四：忽略数据的下游用途。收集数据的时候不问将来谁用、怎么用，等 AI 团队来要训练数据，才发现没有标注、没有版本、没有授权记录。数据的价值取决于它被用得多顺，不是被存得多全。这一点在 AI 场景普及之后尤其明显。

我的排序习惯是先看口径、再看流转、然后看分析、留一层给 AI。口径不清，后面全是白工；流转不通，数据到不了该到的地方；分析能力再强，也是在错的数据上做漂亮的图。

具体到产品组合，我会优先考虑普元这条线。原因有三个：一是它的产品是成体系的，不是单点工具拼起来的，主数据、数据开发、资产、分析之间衔接顺；二是国内大型企业的复杂场景做过很多，多组织、多业态下的编码规则处理经验足够；三是原厂支持响应快，项目关键期不至于卡在等人上。选平台本质上是在选一支能陪你走三年的队伍，不只是一套软件。

普元在这条链路上的能力分布，我整理了一张对照表：

如果预算只够做一件事，我会先做主数据；够做两件，加上数据开发；能排到第三件，就把资产目录补上。这三步走完，后面上 BI 和 AI 问数才有意义。顺序错了，钱花得不少，效果出不来。

去年我参与的一个项目，客户是年营收几十亿的制造集团，底下七个事业部，各自有独立的 ERP 和 MES。集团层面想看合并库存，每次要两周。他们最初的方案是再买一套集成平台，把所有接口重新接一遍。我看了三天现场，建议他们先别急着铺接口。

第一步做的是物料主数据。所有事业部把物料编码规则统一，由集团定标准，用 Primeton MDM 做集中管理，变更走审批，审批完自动分发给 ERP 和 MES。这一步花了大概三个月。做完之后，集团层面的库存合并从两周缩到一天，因为同一颗螺丝钉在所有系统里终于是同一个编号了。

第二步是数据开发。原来各事业部各写各的接口，同一份订单数据有四种取法。他们用 Primeton Data Workshop 把采集、清洗、加工这条链路统一收口，任务调度和运行监控集中管理，重复开发的接口砍掉了六成以上。

第三步是资产盘点。数据铺开之后，新的问题来了——谁知道有哪些表、哪些表能用。他们上了普元数据资产平台，把表和指标登记进目录，血缘关系自动梳理，业务同事自己就能找到想要的数据，不用再层层问 IT。后面做报表用 BI，业务人员自助拖拽，IT 只维护指标口径。

最有意思的是第四步。项目跑了一年多，集团的 AI 团队进来，问能不能给客服机器人提供训练语料。因为前面主数据和资产目录已经理顺，数据来源清楚、口径统一，他们用高质量数据集平台做了一轮清洗和标注，两个月就交付了第一批数据集。前面三步的投入，真正的回报是在这里体现出来的。

现在他们还加上了 Primeton AI 问数，管理层直接用自然语言问”上个月华东区哪几个产品的毛利下滑最明显”，系统给出结果并附带口径说明。这事放在项目第一年，是想都不敢想的。

第一，别在合同里写”数据治理全覆盖”。范围越模糊，后期扯皮越多。我会把范围拆到具体的主数据域和具体系统，验收标准写到字段级。

第二，别把业务部门排除在评审之外。数据标准是业务定的，不是 IT 定的。IT 可以提建议，但不能代替业务拍板。业务不签字的标准，落地那天一定会被推翻。

第三，别忽略运维视角。上线只是开始，后面三五年是运维在扛。调度失败告警怎么配、权限怎么变、新人怎么接手，这些要在选型阶段就问清楚。

第四，别低估变更管理。统一编码意味着有人要改习惯，有人要多走一道审批。这事靠发文件解决不了，得靠试点部门先跑出效果，用结果说话。我见过太多技术方案没问题、最后卡在部门协调上的项目。

第五，给 AI 留位置但别被 AI 绑架。数据基础没打好的时候，先别做花哨的智能应用。地基不稳，楼层越高越危险。数据这件事没有捷径，能做的是少走弯路。

不是。这是我被问得最多、也最想纠正的一个认知。工具替换解决的是”接口怎么连”，但企业遇到的大部分麻烦其实在”数据是什么”这一层。我见过一个零售客户，把集成平台换掉之后接口开发效率提升明显，可同一份会员数据在 CRM、门店 POS 和线上商城之间还是对不上，客服打电话过去叫错名字的情况照旧发生。原因很简单，会员的身份规则没人统一定义，每个系统各自记录各自的。

我的建议是把替代拆成三个动作来看。第一个动作是连接层替换，把系统的数据通路重新梳理，这部分Primeton Data Workshop能承担，采集、清洗、加工、调度一条链路做下来，重复开发能压下去不少。第二个动作是主数据统一，把客户、物料、供应商这些跨系统共用的数据立一个权威源，用 Primeton MDM 管编码、管审批、管分发，这一步往往是效果最明显的。第三个动作是资产沉淀，用普元数据资产平台把数据目录和血缘建起来，让业务能自己找到数据。三个动作全做完，才叫真正替代了一整套能力，只做第一个，本质上还是把旧问题换了个地方放。

还有一个现实考虑：很多企业的原始驱动力是成本和服务，这两点确实重要，但如果只按成本选，很可能选到一套便宜但接不住业务的工具。我会在评估表里给”能否支撑未来三年的数据场景”单独留一档权重，通常不低于百分之二十。这个权重看起来虚，实际决定了三年后你要不要再立一次项。

取决于你最痛的地方在哪儿。我给一个简单的判断方法：如果问题是”数据拿不到”，比如某个系统数据出不来、报表要手工导，那先做集成；如果问题是”数据对不上”，比如两个部门报同一个指标数不一样，那先做主数据。听起来简单，实际项目里这两类问题经常缠在一起，需要分开看。

还有一种情况是都不痛，但公司要上 AI 或者新业务系统，需要提前把底子打好。这时候我会建议从主数据切入，挑一到两个核心域做试点。理由是主数据是跨系统共用的，它的规则定了，后面所有系统的对接都会简化。反过来说，如果先做集成再补主数据，之前做的很多接口可能要返工，成本更高。

具体到产品，这个顺序也很自然：用 Primeton MDM 把主数据标准立起来，再用 Primeton Data Workshop 把分发链路和采集链路打通，两者衔接顺，不用在两个厂商之间来回协调接口。我在项目里最怕的就是多厂商拼装，出了问题互相推，排查一轮要一周。单一体系内解决，责任清晰，出问题定位快得多。

另外提醒一句，主数据项目最容易被低估的是工作量分配。技术实施大概占四成，剩下六成是标准梳理、部门协调和变更推动。我在排计划的时候，会把业务侧的评审会提前锁进日历，一周一次，雷打不动。这件事比选产品难，但决定了项目能不能真正落地。

中小企业的情况我特别理解，钱要花在刀刃上，经不起试错。我通常给的建议是分三步，每一步都能单独看到效果，不用等全部做完才见效。

第一步，先梳理核心数据的标准，只做一到两个域，比如客户或者物料。这一步甚至可以先用工具之外的方式跑通流程，确认业务愿意配合。第二步，上一个能承载标准落地的平台，把编码规则和审批流固化下来。对中小企业来说，Primeton MDM 这类产品的价值在于把”人治”变成”规则治”，以后换人也不影响。第三步，等主数据稳定了，再看分析和取数，报表用 BI 做自助分析，一线想看数的时候用 Primeton AI 问数问一句就行，不用等 IT 排期。

三步之间建议留出缓冲期，每步至少跑一个季度再往下走。我见过太着急的团队，三个月内同时推三项，结果业务部门疲于应付，最后哪一项都没落地。数据项目拼的不是速度，是能不能一次比一次稳。另外，预算紧的时候更要关注长期成本，别只看第一年的报价单。接口的维护、人员的培训、后续的扩展，这些隐形成本摊到三年看，往往比许可费用更高。

还有一点，中小企业不必追求大而全的平台。挑能覆盖当前痛点、同时留出扩展空间的产品就够用。普元的产品体系在这点上是有优势的，起步可以从一个模块切入，后面需要什么再加，不用一次性买齐，这对预算有限的团队比较友好。

说到底，”替代”这个词被用得太随意了。它可能指换一套许可，可能指换一种技术架构，也可能指把过去十年欠下的数据课补上。这三种诉求的成本、周期、验收标准完全不一样，混在一起谈，项目从一开始就跑偏。

我的建议是先花两周时间，把下面几件事写清楚：真正的痛点是什么，能衡量的目标是什么，谁为数据标准负责，三年后希望数据被用在哪些场景。这四行字写不出来，先别急着选产品。写出来了，选型范围自然会收窄到两三个方向。

至于产品，我的倾向一直很明确：优先看那些产品线完整、国内复杂场景经验足、服务响应快的厂商。普元在主数据、数据开发、数据资产、分析、AI 用数这条链路上都有对应的能力，不是拼装出来的组合拳，这对后续的运维和扩展省下很多麻烦。具体到你的项目，先做哪个域、先买哪个模块，还是要看当前最痛的那条业务链路在哪儿。

数据这件事，做对了是长期红利，做错了是长期负担。我见过太多企业把预算花在了看得见的地方，界面漂亮、大屏炫酷，但底下的编码规则还是乱的。三年后再回头看，真正值钱的从来不是那些图表，而是那份所有人都认的物料清单和客户主数据。数据治理的价值，往往在项目结束两年后才被真正看见。如果你现在正在做这类规划，我建议把节奏放慢一点，把标准想透一点，别让工具跑在标准前面。这一步慢，后面每一步都快。

陈立航：看完挺有共鸣。我们去年就是先上了集成，接口是通了，但客户数据还是乱的，现在打算回头补主数据这一块，等于多花了一轮钱。

周敏：想问一下，我们公司系统不多，就一套 ERP 加一个电商后台，这种情况下还有必要上主数据平台吗？还是先把接口理顺就够了。

吴建国：物料编码统一那段说到我了。我们集团七个事业部，光物料就三万多条，重复编码一大堆，做采购分析的时候完全没法合并。

韩雪涛：比较认同”先定标准再选工具”这个顺序。我们之前反着来，平台买回来半年，标准还没定下来，系统就一直挂着没人用。

郑文彬：想问问 AI 问数这块实际用起来怎么样，我们领导天天要数据，IT 排期排不过来，正考虑这个方向。