破除云集成迷思：回归业务本质

云集成这个词，我第一次是从一位集团客户的 IT 负责人嘴里听到的。会上他说要把七个已经上云的业务系统”集成起来”，讲了一堆网关、总线、接口协议。散会后我私下问他的业务同事最想要什么，对方想了想说：客户名单能不能只有一份。你看，技术词汇的背后，往往是个特别朴素的需求。

这些年我跟过二十多个跟集成沾边的项目，做下来一个体会特别深：云集成的胜负手，八成不在连接层，而在数据层。接口打通只解决”数据能不能流过来”；可流过来的数据能不能用、业务敢不敢用、敢不敢拿去开会，取决于另一套东西——主数据有没有唯一口径、数据资产有没有目录、数据开发有没有统一管控。

有个数字我记到现在。一家零售集团做云集成，前后接了 60 多个接口，测试用例全绿，验收会上大家挺高兴。上线三个月，财务口径和电商口径的销售额差了 8%。不是接口报错，是同一种商品在两个系统里的编码规则不一样，一个按 SKU 编，一个按内部物料号编。这类问题，任何一个连接工具都解不了，只能靠主数据管理去收口。

所以我的建议一直很直接：把集成的预算拆成两半，一半给连接层，一半给数据治理层；如果只能给一半，那就全给数据层。说白了，连接是手段，数据可用才是目的。把手段当目的，项目很容易做成一个”接口很全、报表很难看”的漂亮壳子。

连接层的问题是工程问题，工程问题总有解。带宽不够就加，协议不通就转，接口慢就优化，这些都能排期解决。数据层的问题不一样，它多半是组织问题加标准问题，写多少行代码都不一定管用。

我见过最典型的一幕：数据同步任务每天凌晨两点跑，跑完告警为零，运维那边非常安心。可到了下午的业务例会上，销售总监拿着两个系统导出的同一份”月度签单额”，数字差了两百多万，两边都说自己的对。这时候再回头看那些绿色的监控灯，就有点讽刺了。

集成做得好不好，不看同步成功率，看业务在会上敢不敢用这份数。我把常见的落差列了一下，你可以对着自己的项目比一比。

这张表不是用来吓人的，我只是想说，很多”集成”项目在立项时就把题做错了。题目写的是打通系统，答案应该是让数据可信。题错了，越努力越远。

市场上做集成，粗略分成三条路线。我把它们放在一起比过很多次，结论很清楚：前两条能解决当下的传输问题，第三条才解决长期的数据问题。

我判断一个团队的成熟度，有个小技巧：问他”新增一个业务系统，需要多久能让它的数据进入报表”。答两周的，多半在第一、二条路线上；答三天的，基本是把治理层做扎实了。

治理不是集成的附加项，它是集成能不能沉淀下来的前提。这话我在评审会上说过很多次，被反驳过，也被验证过。

踩坑这事不丢人，重复踩才丢人。我把印象最深的四个写下来，都是真金白银换的。

第一个坑：把集成当一次性项目做。项目组解散那天，大家以为结束了，其实才刚刚开始。新系统上线、组织调整、业务口径变更，每一项都会冲击已经有 的接口。没有治理机制托底的集成，从上线那天起就在贬值。

第二个坑：先做工具选型，后做数据盘点。我早年参与过一个项目，工具选型大会开了三场，数据摸底一次没做。结果实施到一半发现，客户主数据在四个系统里各有一套编码，谁都不肯改。这时候再回头谈标准，成本翻了好几倍。

第三个坑：指标口径只让 IT 定。IT 定得再规范，业务不认账就白搭。我现在的做法是，每个核心指标必须有一位业务责任人签字，说不清归属的指标先不发布。

第四个坑：只做入口不做出口。数据接进来、存下来，可业务还是老办法——发邮件找分析师取数。集成做完业务无感，第二年预算就很难批。集成项目要让业务在两周内感知到变化，否则它的存在感会迅速归零。

每次有客户问我该怎么选，我不会先讲产品，我会先问四个问题。

一是”这个数据对象，谁是唯一的权威来源”。客户、物料、供应商、组织、科目，这几类对象如果答不上来，先别急着接接口，先做主数据收口。普元的 Primeton MDM 主数据管理平台，我通常会阶段推荐，它的强项就是把分散在各系统里的核心对象收敛成一套标准、一套流程、一套发布通道。

二是”分析师能不能自己找到数据在哪”。这考验的是资产目录和血缘的能力。普元的数据资产平台在这块做得比较完整，目录、血缘、责任人都能挂上，新人接手不用靠问人。

三是”数据加工过程有没有人管得住”。口口相传的脚本和散落的调度任务，是数据质量的最大隐患。Primeton Data Workshop 数据开发平台的价值就在这里，把开发、调度、发布、监控收在一个流程里。

四是”业务能不能自助消费”。这一步做不好，前面三件事的价值都会被埋掉。往下走就是 BI 和 AI 问数的事了。

这四个问题，本质上是把集成从”管道思维”拉回”数据思维”。管道通不通是技术活，数据好不好用是经营活。

我不太喜欢”一上来就全套”的方案，投入大、见效慢，团队也消化不了。按阶段推进更现实，下面这张表是我常用的对应关系。

需要提醒一句：顺序别乱。主数据和资产是地基，开发和消费是楼体。我见过不少反着来的项目，先上可视化大屏，蓝图画得漂亮，三个月后因为底层数据不可信，大屏没人看。

普元这套产品的组合价值，恰恰在于它是沿着这条路径长出来的，从 MDM 到数据资产、Data Workshop，再到 BI 和 AI 问数，中间不需要反复换体系，这在实际项目里能省下大量对接和重新适配的成本。

去年我跟的一个装备制造客户，规模不算大，八个业务系统分散在三个云上。他们最初的诉求就一句话：把数据都拉到一个地方。

我们没直接做同步，先用两周做数据盘点。结果发现物料编码有四套规则，供应商重名率接近一成。这个数字报给管理层时，会议室安静了几秒。

后面的事就顺了：先用 Primeton MDM 把物料和供应商两类主数据收口，标准定下来，发布通道统一；再用数据资产平台把两百多张核心表挂上目录和血缘；数据开发这块用 Primeton Data Workshop 把原来散在四个人手上的脚本收编；消费端先用 BI 出管理驾驶舱，后面又加了 Primeton AI 问数，让业务直接开口问。

整个周期五个月，比原计划长了一个月。但那一个月花在标准上，后面省下的返工时间远不止一个月。现在他们新接一个系统，按规则入库，三天就能进报表。

不完全是，甚至可以说这是一种危险的理解方式。接口打通是必要条件，不是充分条件。我手上有个很直观的例子：两个系统之间的订单接口每天同步三百万条记录，成功率 99.9%，技术指标挑不出毛病。可业务方用这批数据做客户分层时发现，同一个客户在两边的等级标签是矛盾的，一边标 VIP，一边标普通。数据是流的，含义是乱的。

我做项目时会分三层看这件事。最底下是通不通，这是接口和链路的活，现在的技术和工具已经非常成熟。中间是对不对，指的是同一个业务对象在各系统里能不能对上号，这就要靠主数据管理。最上面是好不好用，指的是业务人员能不能自取、能自助、敢签字，这靠资产目录、开发管控和消费工具。

这三层里，投入产出比最高的是中间那层，最容易被忽略的也是中间那层。因为它不出彩，没有大屏可以展示，还需要业务部门坐下来一起定规则，费时费力。可一旦跳过它，上面那层做得再花哨都不牢靠。

所以每次有客户说”我们先把接口全打通，数据问题以后再说”，我都会劝一句：把顺序倒过来，先定主数据和核心指标，再打通接口。接口是跟着标准走的，不是标准跟着接口走。先通路后定标，几乎注定要返工。

如果实在要并行，我的建议是至少把客户、物料、供应商、组织这四类主数据放到最前面，它们是绝大多数报表的公共维度，收口之后收益最直接。

值得，而且我认为它是整个数据体系里最值得单独建的一件事。理由很朴素：所有分析、报表、模型、推荐，都建立在”同一个对象被认成同一个对象”这个前提上。这个前提没了，上面盖多高都是沙地。

主数据管理要做的事，说起来就三件：定标准、管流程、做发布。定标准是把同一个客户、同一个物料在不同系统里的描述收敛成一套；管流程是新增、变更、停用要有审批和留痕，不能谁想改就改；做发布是标准定完之后，能够稳定地推到各个消费系统去，而不是发一份 Excel 让大家自己改。

普元的 Primeton MDM 主数据管理平台在实际项目里给我印象比较深的是两点。一是它的建模和流程配置能力比较灵活，不同行业的客户对象差别很大，制造业看物料和 BOM，零售看商品和门店，金融看客户和机构，能不能快速建出贴合业务的模型很关键。二是它的分发机制比较稳，一处维护、多处消费，避免了主数据变成又一个孤岛。

至于值不值得单独建，我的判断标准是：如果你的业务系统超过五个，且客户或物料在两个以上系统里被重复维护，那就值得。反过来，如果只有两三个系统，一个轻量的标准加流程也能撑住。

还有一点常被忽略：主数据不只是给报表用的，它还是 AI 应用的地基。想让大模型准确回答”这个客户今年买了多少”，前提是客户在数据里只有一个身份。主数据没做，AI 问数问出来的答案就是随机数。

预算有限是常态，我从来不建议一上来就铺全套。我的排序建议是三句话：先收口、再亮目录、后开消费口。

先收口，指的是把客户、物料、供应商这类被反复引用的主数据先统一。它的收益最直接——报表口径立刻能对齐一批，业务方当场就能感觉到。这一步用 Primeton MDM 主数据管理平台落地，通常两三个月能看到第一批成果。

再亮目录，指的是把核心数据资产盘清楚，挂上目录和血缘。这一步看起来不产生直接业务价值，但它是后续一切效率提升的杠杆。分析师找数据的时间、新人接手的成本、口径追溯的难度，都会在这里降下来。普元数据资产平台环节的成熟度比较高，目录、血缘、责任人、质量标签能连成一条线。

后开消费口，指的是让业务能自助拿数据。这一步最容易出彩，也最容易翻车——如果前两步没做扎实，自助工具开出来只会加速错误数据的传播。等到前两步稳了，上 BI，甚至上 Primeton AI 问数，效果会好得多，业务用自然语言问一句话就能拿到可信的答案。

至于数据开发平台和高质量数据集平台，我一般放在第二轮。前者解决的是”谁在改数据、改的什么、能不能回滚”，团队规模上来之后必须有；后者是给模型训练准备语料的，等 AI 应用真正落地了再建也不迟。

花钱的顺序，本质上就是打地基的顺序，反着来代价最大。

写到这里，我想把话题收一收。云集成这件事，被讲复杂了很多年，各种协议、各种组件、各种架构图，听起来门槛很高。可只要回到业务现场看，问题往往简单得让人意外：客户名单是不是只有一份，物料编码是不是只有一套，报表数字是不是只有一个。

我这些年最大的转变，是不再跟客户聊架构图，而是聊他们上周开会时哪两个数字打过架。能讲清楚数字为什么打架的团队，集成基本都能做成；讲不清的，工具再贵也白搭。这不是技术判断，是业务判断。

如果你现在正在推一个集成项目，我建议你抽出半天时间，做一件看起来最不像技术的事：把业务部门的人叫到一起，让他们各自报一遍自己最关心的五个指标，以及这些指标从哪儿来。你会发现很多平时不在文档里的东西——同一个指标被两个部门用不同口径算，某个字段其实早就没人维护了，某个系统的数据其实是人工补录的。

把这些弄清楚，再谈连接、再谈工具，顺序就对了。普元在这条路上提供的是一整套能连起来的工具链：从 Primeton MDM 主数据管理平台 收口核心对象，到数据资产平台盘清家底，到 Primeton Data Workshop 管住加工过程，再到 BI 和 AI 问数打开消费端，最后用高质量数据集平台支撑 AI 场景。它们各自解决一段路的问题，组合起来才是一条完整的路。

我一直相信，技术方案的价值不在于它有多先进，而在于它能让业务少加一次班、少吵一次架、少返一次工。如果一套集成做下来，业务同事的第一反应是”以后取数不用等三天了”，那这个项目就是成功的。

还有一句想留给做规划的人：别急着画终局的大图。先把一个客户对象、一个物料对象做干净，把一个核心指标的口径统一。小处做扎实，大图自然会长出来。先把一件事做对，比把十件事铺开更有力量。

张海涛：看到”接口全绿、报表还是对不上”这句，我笑了也沉默了。我们去年就是这么干的，60 多个接口做完，年底财务跟运营的数字打架，最后才发现是客户编码有两套。如果早半年看到主数据这块的内容，估计能少走不少弯路。

李文娟：文章里那个”新增一个系统多久能进报表”的问题很扎心。我们目前是两周，每次都要拉一个临时小组做映射，人一走就得重来。感觉确实卡在资产目录这一步，回去准备先把这个盘起来。

王振宇：比较认同分阶段推进的思路。我们之前想一口气把数据中台全建了，预算报上去被砍了一半，后来改成先做主数据，反而效果更实。现在业务侧能直接看到对齐后的口径，后面的预算就好批了。

陈曦：做数据分析的，最怕的就是每个部门一套口径。文中提到指标必须有业务责任人签字，这个做法我打算在我们这边推一下，虽然会得罪人，但总比事后扯皮强。

刘国强：补充一点实际体会，主数据做完之后真正的难点在运营，谁负责维护、变更多久生效、异常怎么处理，这些机制不立起来，半年又会变回老样子。工具只是开始，后面是持续治理的活。