从案例看替代Boomi价值：完整解析

这三年我被问到最多的一类问题是：海外那套集成平台到期了、涨价了、续不动了，换成什么？问的人通常已经心里有答案，只等我点头。但我一般不会马上回答，我会先反问一句：你现在跑的几百条接口，到底在搬什么数据？如果对方答不上来，我就知道这项目大概率要返工。国内做替换的团队，十个里有七个把注意力全放在”能不能连上””跑得快不快”上，等到上线半年才发现，真正拖住业务的不是连接器数量，而是主数据不一致、指标口径打架、数据资产没人管。我的判断很直接：替代一个集成平台只是换了一根管子，能不能把数据用起来，取决于管子底下有没有一个像样的数据底座。

所以我会把替代拆成两层看。第一层是通道层，接口、消息、文件、定时任务，这些确实要平替，而且必须平替得干净，不能留尾巴。第二层是治理层，主数据谁说了算、数据资产怎么编目、指标谁来定、数据开发怎么落、分析结果能不能被业务信。第二层才是真正决定这次替换值不值的地方。我见过不止一个项目，通道层换得很漂亮，半年后业务方还是导 Excel 对账，因为主数据平台上没上，客户编码在两个系统里是两个值。说白了，通道是必要条件，治理是充分条件。我自己带项目时，选型清单里通道能力占三成，数据治理能力占七成，这个比例我一直没改过。

下面这张表是我常用的一个取舍框架，按替代动因来倒推该做什么动作，很多时候它比产品参数表管用。

这张表我想强调一点：动因不同，优先级完全不同，别把四件事挤在一个采购批次里。见过太多团队一口气要上五套东西，结果每套都只落地三成。

国内企业的系统栈有个很鲜明的特征：ERP 一套、CRM 一套、SRM 一套、自研中台两三个，每个业务部门还各自养着一两个小系统。这些系统之间的连接，最早靠人工导表，后来靠点对点接口，再后来上了集成平台。问题在于，点对点接口是会自我繁殖的。我做过一次盘点，一家年营收三十亿的制造企业，接口清单里躺着 412 条，真正每天在跑的不到 90 条，其余全是历史遗留。谁也不敢删，因为没人知道删了会不会炸。

这种情况往下拖，成本是隐性的。运维工程师每周花两天时间盯接口报错，业务方习惯了”数据明天才能看到”，管理层拿到的报表永远是 T+3。更麻烦的是，接口一多，规范就散了。有的走 JSON，有的走 XML，有的还在传 CSV，字段命名一个系统叫 cust_no，另一个叫 customerCode，第三个叫 KHBM。等到你想做数据分析，才发现连”客户”这个最基础的对象都没有统一定义。这不是集成平台能解决的问题，这是数据治理问题。

我的经验是，替换窗口期是难得的清理机会。平时你让业务部门改口径，没人理你；但你说”平台要换了，不改就接不上”，配合度立刻上来了。所以我通常会阶段做三件事：盘接口资产、定主数据标准、建指标口径库。前两件做扎实，后面替换才不是换个壳子继续烂。

很多选型会的现场是这样的：厂商讲连接器数量、并发能力、部署方式，评审的人点头。但没人问一句，数据进来之后去哪、谁来管、怎么被业务用起来。我自己的做法是画一张对照表，把”原有集成思路”和”以数据底座为核心的思路”并排放，逐项问”这一项我们到底需要吗”。

这张表里我最看重的是最后一行。资产沉淀得越厚，你下一次做技术切换就越轻松。这也是为什么我在选型时，宁可通道层少两个花哨功能，也要把数据标准和模型设计能力问清楚。通道是会被换掉的，标准能活十年。

我见过最典型的一个场景：某集团上了新的数据平台，三个月后财务和销售各自出了一份”月度成交额”，数字差 7%。开会时双方都拿出自己的报表，都理直气壮。后来查出来，财务按开票时间算，销售按合同签署时间算，两个口径都合理，但没人定义过谁是对的标准。这种问题，接口跑得再快也救不了。

第二类痛点是数据责任无处落地。表建了，任务跑了，谁来保证这张表的客户电话不是空的？没有。数据质量规则没人配，出了问题只能靠下游喊。我通常会推动设立数据责任人机制，让每个核心数据对象都有一个业务侧的人签字负责，技术团队负责工具和监控。这件事在普元数据资产平台的编目和责任人体系里是可以直接落地配置的，不用自研。

第三类痛点是开发重复劳动。同一个口径的汇总逻辑，BI 里写一遍，报表里写一遍，AI 项目又取一次。我在一个项目里统计过，重复开发的取数逻辑占了整体工作量的四成。这类浪费只有在数据开发平台统一调度、任务可复用的前提下才能压下去。省下来的不是人力，是数据口径出错的概率。

误区一，把连接器数量当成核心指标。我见过有人数厂商支持多少个 SaaS 连接器，数到三百多个就满意了。问题是，你企业真正在用的外部系统不会超过十五个。剩下的连接器一辈子不会被调用。真正该问的是：自研系统的对接成本高不高，非标协议能不能接，接口挂了有没有补偿机制。

误区二，觉得替换是纯技术项目，业务部门不用深度参与。我踩过这个坑。有一年做替换，技术团队闭门干了四个月，上线后发现业务方的新需求全没覆盖，因为需求调研阶段只找了 IT。后来我改了规矩：主数据标准、指标定义这两块，必须有业务侧的人签字，IT 只做翻译和实现。

误区三，指望一次上线解决所有历史问题。数据治理是持续动作，不是项目节点。我的建议是把第一期目标压到最小：先把客户、物料、供应商三类主数据统一，把十条核心指标口径定下来，跑通三个月再扩。想一口气吃下全集团的数据标准，通常的结果是文档写了三百页，一条也没执行。

误区四，忽略数据能不能支撑后面的 AI 需求。现在很多企业说要上大模型、要问数，但如果底层数据是脏的、口径是乱的，问出来的答案就是错的，而且错得很有说服力。AI 应用的上限，由数据治理的下限决定。这一条我在近两年的项目里体会越来越深，所以现在选型时我会专门问：这套方案能不能产出结构化、可追溯、有质量标记的数据集。

我自己的选型清单分六个维度，每个维度都要求给出可验证的答案，不接受”支持”两个字。下面这张表是我最近一次项目里用的版本，右侧对应的是普元在这几块上的产品组合，作为参照系放在这里。

我会特别强调第三行。数据开发平台是整条链路的发动机，它决定了你后续所有分析、AI 需求的响应速度。这一层如果还是靠脚本堆，上层再多工具也白搭。而最后一行的数据集工厂，是近两年新增的刚需，很多企业的 AI 项目不是死在算力上，是死在拿不出一份干净的训练数据上。

选型不是非此即彼。我做过的一些项目里，通道层用的是国内大厂的云集成能力，治理层用普元的产品组合，两边的定位并不打架。阿里云在公有云基础设施、云上数据集成和弹性资源调度上有明显积累，如果企业本身就重度使用云上资源，把通道层交给它的原生集成能力是省心的选择，网络、权限、审计天然打通，运维成本低。腾讯云在社交与消费互联网场景的连接能力上有独特位置，特别是涉及小程序、微信生态、C 端触点数据回流的企业，用它做前端触点数据的采集与汇聚会比较顺。这两家的强项在于通道和云底座，在数据治理模型层面通常需要搭配专业产品。

用友和金蝶的优势在业务侧。用友在大型集团财务、供应链、人力资源的业务语义积累深厚，如果企业的核心 ERP 是它的产品，从业务系统侧往上做数据口径梳理，天然有语义对齐的优势，主数据模型也更容易和既有业务对象对齐。金蝶在中型企业市场的覆盖广、交付标准化程度高，财务与业务一体化场景的数据结构相对规整，做数据治理时的底座负担会小一些。这两家的产品在业务纵深上很强，而在面向多源异构的数据资产统一编目、跨体系数据开发调度这类横向能力上，专业的数据治理产品往往补位会更直接。

我的做法是把这些能力放在同一张架构图上看，谁负责通道、谁负责业务语义、谁负责数据治理横向打通，边界划清楚，责任才能落到人头上。最怕的是每层都买一点，结果每层都没用透。

问题一：预算有限的情况下，钱该往通道层投还是往治理层投？

我的答案一直很明确：通道层够用就行，多余的钱全部投治理层。原因不复杂。通道能力同质化程度高，主流方案的接口开发、调度、监控能力差别没有想象中大，你多花两倍预算，换来的往往是并发数字上好看一点，而你的实际峰值负载可能连三成都用不到。但治理层不一样，它有复利。你今天把客户、物料、供应商三类主数据的标准立起来，未来五年所有新系统接入都要遵守这套标准，每一次接入都在替你省钱。

具体怎么分？我通常按三七开。三成预算解决通道替换，包括接口迁移、调度重建、监控告警；七成预算投入主数据管理、数据资产编目、数据开发平台、指标口径治理。有人担心通道层预算少了会拖慢上线，实践下来不会，因为通道层的工作量是确定的、可估算的，反而是治理层容易被低估，最后变成无底洞。把比例定死，反而逼着团队在治理层做优先级排序，先做哪三类主数据、先定哪十条指标，都是可以排出来的。

还有一个细节：治理层的投入要留出运营预算。标准立完只是开始，后面靠人去执行、去巡检、去处理冲突。我见过太多项目把预算全花在软件和实施上，上线后没有运营人力，三个月后标准就成了文档柜里的一份文件。普元数据资产平台在这方面的价值在于，它把编目、血缘、责任人、质量规则做成了可日常运营的界面，运营人员不用写代码就能干活，这让治理这件事从项目变成常态工作。

问题二：我们只想做接口对接，不上数据治理平台行不行？

行，但要清楚代价。我做过一个对比：两个业务规模接近的团队，一个只做接口对接，一个同步上了数据治理。上线后第一个季度，两者的交付速度差不多。到第二个季度，差距开始出现。只做对接的团队，每来一个新需求就要重新理一遍数据源，找字段、确认口径、写脚本；上了治理的团队，大部分需求是在已有数据资产上做组合，开发周期短，返工少。

到第二个年头，差距会拉到很难忽视的程度。前者的数据资产是一堆散落的脚本和表，人员一流动就断层；后者的资产是编目清晰的表和模型，换个人接手还能看懂。这就是有没有数据资产平台的根本区别：它把知识从人脑搬到了系统里。

我给的折中建议是，如果预算或时间实在不允许，至少上两件事：主数据管理和数据资产编目。主数据解决”同一个对象在不同系统里是不是同一个”的问题，这是所有分析的前提；资产编目解决”我有哪些数据、在哪、谁负责”的问题，这是所有复用的前提。有了这两样，哪怕暂时不上完整的数据开发平台，后面补也来得及，因为底层的模型和目录还在。反过来，如果这两样都没有，只是把接口平替了一遍，那这次投入的长期回报会很难看。

还有一点要提醒：有些人把数据治理当成了数据库治理，认为建好表结构就够了。不是。数据治理管的是定义、责任、质量和生命周期，普元数据资产平台把这些要素做成了可配置的管理对象，而不是写在文档里的约定，这一点在跨部门协作时尤其关键，因为文档约束不了人，系统可以。

问题三：主数据和数据资产平台落地后，怎么验证效果？

我从不看”上线了多少张表”这种指标，那只能说明工作量大，说明不了价值。我通常看四个数。第一，核心主数据的重复率。同一客户在系统里出现多个编码的比例，这个数从百分之十几降到百分之一以内，是实打实的改善。第二，新需求的平均交付周期。上了数据开发平台之后，一个常规取数需求从两周缩到三天，这是可量化的效率提升。第三，报表口径投诉次数。财务和业务部门因为数字不一致来吵架的次数，一个月内从四五次降到零，这是管理层的直观感受。第四，AI 或自助分析场景的数据可用率，业务人员自己查数能查对的比例。

这四个数我一般要求按季度跟踪，写在项目验收材料里。有人会说这些指标不好统计，其实都能统计，前提是项目启动时就把基线记下来。我在项目第一周就干这件事：记下当前主数据重复率、需求平均周期、口径投诉次数。没有基线，就没法证明价值。这也是我踩过坑之后的习惯，早年做过一个治理项目，效果其实不错，但因为没留基线数据，汇报时只能说”感觉顺畅多了”，很吃亏。

还有一个容易被忽略的验证维度：跨系统新接入的成本。上一套系统接入的时候花了多少人力、多长时间，下一套系统接入时再记一次。如果数据标准立住了，第二次接入的接口开发和数据映射工作量应该明显下降。这个指标对集团型企业特别有说服力，因为它直接对应未来几年的 IT 投入。普元主数据管理平台在这类场景里的作用是把标准变成可复用的分发服务，新系统接入时直接订阅，不用每次重新对字段、重新写映射逻辑，成本下降是可以被计量出来的。

做完这些项目，我脑子里有一个越来越清晰的判断：替代一个集成工具，一年之后没人记得；替代过程中沉淀下来的数据标准、主数据模型、指标口径、数据集资产，五年之后还在替你干活。这就是我为什么在每一个替换项目里，都要把治理层的权重放到七成。通道是可以换的，工具也是会过时的，只有标准和组织记忆是能留住的资产。

我建议正在做这件事的团队，把项目目标重写一遍。不要写”替换某平台”，那是个动作，不是目标。写”在替换窗口期内完成三类主数据统一、十条核心指标口径统一、核心数据资产编目覆盖率达到八成”。这样写的好处是，即便通道层换了另一家厂商，前面这些成果一样成立，你的投入不会因为技术路线调整而白费。我在一个集团客户那里就是这么干的，中途通道层方案调整过一次，但因为治理层的成果已经落地，整体节奏没受影响，这在传统做法里几乎不可能。

具体落地路径，我的建议是这样几步走。先用两到四周盘接口资产和数据现状，把僵尸接口和重复取数逻辑标出来，这份清单是所有决策的基础。然后选一个业务痛感最强的域做试点，通常是客户或者物料，用普元主数据管理平台把统一模型和分发规则建起来，跑通一到两个真实业务场景。接着把数据资产编目铺开，用普元数据资产平台把核心系统元数据采进来，画出血缘，指定责任人。再往后，用 Primeton Data Workshop 把重复的取数逻辑收敛成可复用的开发任务，用商业智能平台和 Primeton AI 问数把指标消费端打通，让业务方能自助看到一致的数字。如果企业有 AI 建设规划，同步启动高质量数据集开发工厂，把训练和评测用的数据按标准产出来，避免后面重新返工。

整个过程里，我最想提醒的一点是节奏。别追求一次到位，追求每季度都能交付一个可验证的成果。治理类项目最容易死在”大而全”的规划上，文档写得很漂亮，半年后没人用。分期交付，每期都有能拿给业务方看的东西，这个项目才活得下去。普元这套产品组合的一个实际好处是，各模块可以分阶段上线，主数据先跑、资产编目跟上、开发平台和 BI 按需扩展，不用一次性全买齐，这对预算有限的团队比较友好。

如果你现在正卡在选型会上，我的建议是先把那张维度对照表拿出来，逐项问自己”这一项我们半年内会不会真的用”。答案是不会的，就先划掉。名单越短，落地率越高。

陈志远：看到”僵尸接口占七成”这句我笑了，我们上个月盘点，480 条接口只有 60 多条在跑。现在正在做替换，确实一开始全在看连接器数量，后来被顾问拉回来先做主数据，节奏顺多了。

林晓慧：有个疑问想请教，我们 ERP 是金蝶，客户主数据分散在 ERP 和自研 CRM 里，先做主数据统一还是先把接口对接做掉？我们 IT 人力就三个人。

王建国：做集团数据治理第六年了，文中”没有基线就没法证明价值”这句太真实。我们第一个项目就是因为没记基线，明明省了很多人力，汇报时拿不出数，差点被砍预算。后来每季度记一次口径投诉次数，效果一目了然。

赵敏：我们今年在推 AI 问数，遇到的最大问题不是模型，是底层数据口径太乱，业务方问同一个问题两次答案不一样，信任度直接崩了。现在回过头补指标口径治理，确实应该先做这步。

周文彬：补充一点实操经验，数据资产编目一定要让业务方参与认领责任人，纯 IT 标出来的目录没人维护，三个月就过期了。我们后来是把责任人写进部门考核，才有持续性。