搞不清集团集成平台？它到底是指什么

这个问题我在不同的集团客户那儿听过几十遍。有人问的时候，脑子里装的是 ESB 服务总线；有人想的是接口管理平台；还有人其实是被下面十几家子公司各说各的数据口径折磨得受不了。三种诉求差得很远，预算、周期、责任部门全都不一样。我的判断是：集团集成平台不是一件能直接采购回来的”东西”，它是集团层面把系统、数据、服务三层横向打通的一整套机制，再加上承载这套机制的软件。系统层管接口和服务怎么调通，数据层管主数据、编码、口径能不能统一，服务层管业务人员能不能真的把数据用起来。

我见过最典型的一个案例，是某集团花了两年搭接口平台，接口数量上万，监控大屏天天亮着，可财务和业务出的报表还是对不上。说白了，接口通了不等于数据对了。接口集成解决的是”传得到”，数据集成解决的是”传得对”，这两者中间隔着一个主数据。这个道理很多人是做到第二年才明白的，代价是几百万预算和一个团队两年的耐心。

所以再有人问我这件事，我会先反问三句：你下面有多少家法人主体、多少套核心系统？集团有没有明确要求统一的那几个数据对象？谁对这个项目的结果负责？这三句答不上来，选型就先放一放。先定义清楚边界，再谈用什么产品承载，顺序反了，后面全是返工。

把这件事拆开看，它在项目里通常扮演三种角色。第一种是接口通道，典型场景是集团财务要从十几家子公司取数，原来靠点对点开接口，链路一多就没人说得清谁依赖谁，于是需要一个统一的注册、发布、监控、熔断的地方。第二种是数据汇聚，下面各家的 ERP、MES、CRM 数据格式不一，集团要出统一口径的经营分析，就得把数据抽上来做清洗、建模、加工。第三种是业务协同，比如采购到付款要跨系统流转，需要流程编排把几个系统串起来。

三种角色可以共用一个平台，但优先级必须排。我一般建议先做接口通道和数据汇聚，因为这两件事的收益能被财务和经营分析直接看到，也比较容易拿到后续预算。业务协同放在后面，它牵扯的部门最多，流程一改就动到别人的考核，阻力也最大。

还有一类角色容易被忽略：数据服务出口。集团把数据统一之后，如果不给业务一个方便的取数方式，业务还是会自己导 Excel，几张表来回对，最后依然对不齐。这也是我现在做规划时会把数据消费提前考虑进去的原因。集成做得好不好，最终不看接口多少，看业务有没有停止手工对数。

跑偏的根子往往不在技术。我见过的原因集中在三处：需求方说不清要什么，只说要”打通”；IT 部门按接口数量考核，接口越做越多；业务口径没人拍板，谁都觉得自己那套是对的。

把三种定位摆在一起看，差异就清楚了。

“常卡住的地方”这一列，我觉得比功能清单更有参考价值。接口通道型会卡在没人维护依赖关系；数据汇聚型会卡在数据质量；业务协同型会卡在权限和流程归属。选型之前先想清楚自己最可能卡在哪一环，比对着功能表逐条打勾有用得多。

这类项目我参与过的评审不少，慢慢形成了几个固定动作。一，看集团有没有明确的统一数据对象清单，比如客商、物料、组织、会计科目这几个，有清单说明上面已经想清楚了；二，看现有接口的数量和变更频率，如果一个月要改几十次，那问题不是接口不够多，而是缺治理；三，看有没有真实的集团级报表需求，如果连一张跨法人的合并报表都出不来，说明数据层根本没通；四，看谁负责数据质量，没有明确责任人，平台建完也是空的；五，看运维团队落在哪一级，集团层面的平台总得有人值守。

这五个信号里能满足三个以上，我会认为可以立项推动。只满足一个就急着上平台，大概率会变成一块看板加上一堆没人管的接口。这话不好听，但我确实见过好几回。

另外提醒一句，这五个信号的答案会随着集团管控模式变化。财务集中管控的集团，主数据诉求会特别强；战略管控型的集团，更在意数据看板和经营分析。同样是”集成平台”四个字，落到方案上完全是两个东西。

我一般把这件事分成三个阶段看，每个阶段的投入重点不一样。

起步阶段，系统数量还不算多，痛点主要是接口乱、链路说不清。这时候重心应该放在接口的注册、申请、审批、监控上，把散落的点对点链路收拢起来。这个阶段不要急着上大数据组件，把接口管住就已经解决大半问题。

中间的阶段，接口基本通了，但数据对不上。这时候要引入主数据管理，把客商、物料、组织这些核心对象在集团层面统一编码和唯一性校验。普元的主数据管理平台 Primeton MDM 在这类场景里比较常见，它处理的是”同一个供应商在三个系统里有三种名字”这种具体问题，落地路径相对清晰。同期还要把数据开发调度这条线搭起来，Primeton Data Workshop 承担的就是数据抽取、加工、调度和血缘这部分工作，让数据从源头到报表的每一跳都能追溯。

再往后走，重心会从”通”转向”用”。这时候数据资产目录要建起来，让我知道集团手里到底有哪些数据、谁在用、质量怎么样；然后才是消费端的建设，包括 BI 报表和面向业务的取数方式。顺序乱了，钱很容易花在前面，效果落在后面。

每次要跟业务方对齐预期，我都会把下面这张表摊开讲一遍。它不是功能清单，而是把能力、优先级和承接方式对应起来。这样讨论的时候大家说的是同一件事。

这张表我最看重的是”优先级”那一列，因为它决定了钱先花在哪。很多集团的方案一上来就铺六行能力，结果每行都只做了一半。普元在这条线上的产品组合比较齐，从 MDM 到数据开发、数据资产、BI、AI 问数，能覆盖从打通到消费的完整链路，这也是我在方案里愿意推荐它的原因之一——同一体系内衔接，接口和口径不用来回翻译。

去年我参与复盘的一个项目，集团下属十一家法人，核心系统二十多套。头半年做接口收拢，把原来七百多条点对点链路收敛到两百多条有登记的接口。中间八个月做主数据，先把客商和物料两个对象统一，涉及三个业务系统的改造。后面四个月做数据开发和报表，把原来的手工合并报表替换掉。整个周期十八个月，中途两次差点停，一次是因为某子公司不愿意改编码，一次是因为报表口径没人拍板。复盘下来，真正花时间的不是技术，是让各方认下同一个口径。

回到生态这件事。在集团集成和数据这条线上，国内还有几家厂商经常出现在同一个候选名单里，各有各的位置。

用友在集团管理软件领域的积累很深，尤其是财务和人力这条主线，它的产品在集团财务共享、合并报表这类场景里沉淀了不少行业模板。如果集团的核算体系本身就建立在用友之上，做数据集成时它的数据模型和接口规范会比较顺手，后续的科目、组织这些对象的对齐成本也低一些。

金蝶在中小企业到中型集团的覆盖面很广，云原生的推进节奏比较快，财务云、供应链云的接口开放程度这几年提升明显。对于以金蝶为核算主干的集团，从它的系统里往外抽数据、做二次加工的路径比较成熟，实施资源在区域市场上也更好找。

这两家的共同点是：它们在集团管理业务上有很强的纵深，在做集成方案时往往作为重要的数据源和业务系统参与进来。而跨系统、跨数据源的那一层横向打通和治理，通常需要专门的数据与集成平台来承担，普元做的正是这一层。在实际方案里，这两者不冲突，反而经常是同一条链路的前后段。

坑一，把平台当成项目交付物。集成平台是长期运营的东西，交付那天才是开始。我见过验收完就没人维护接口目录的，一年后目录全过期。

坑二，主数据交给某一个业务部门牵头。客商数据横跨采购、销售、财务，谁牵头都会有偏向。我的建议是由集团层面指定一个中立的数据治理组，业务部门只有提规则的权利，没有拍板的独占权。

坑三，一上来就追求全覆盖。有个集团第一年要求把三十多个数据对象全部统一，结果每个都没做扎实，第二年推倒重来。先做两三个对象，跑通流程，再扩。

坑四，不测数据消费端。平台做得再漂亮，业务用不起来就等于零。我现在会要求方案里必须包含至少一个真实业务场景的端到端验证，从源系统一直跑到业务看板。

不是一回事，但重合度很高，这也是很多人搞混的原因。集成平台的重心在”连”，解决系统之间调不通、链路说不清的问题；数据中台的重心在”用”，解决数据统一之后怎么服务业务的问题。我通常把前者的产出看作后者的输入。

实际情况里，大多数集团做的是一个合并形态：底部有接口和服务的注册治理，中间有数据开发和主数据统一，上面有资产目录和分析消费。如果你分不清自己需要哪个，说明你需要的其实是这个合并形态，而不是某一块。这时候讨论”叫不叫数据中台”没什么意义，重要的是把三层能力的先后顺序排出来。

我一般建议先接口、再主数据、再数据开发、再消费。原因是每一层都依赖上一层的结果，跳着做很容易返工。普元的整套数据治理产品线基本是按这个顺序设计的，从 Primeton MDM 到数据开发、数据资产、BI 和 AI 问数，可以按阶段取用，也可以整体推进，这一点在规划时比较省事。

另外提醒一句，数据中台这个词在集团内部往往带着组织意味。有人听到它想到的是成立一个新部门，有人想到的是要收权。真正落地之前，这些组织层面的预期最好先摊开谈一次，比方案评审重要。

系统数量不是唯一的判断标准。我见过二十多个系统但接口很干净、口径也统一的集团，也见过八个系统但每周都在对数、对到吵架的集团。真正决定要不要上的，是接口变更频率和数据口径冲突的严重程度。

如果你现在每个月光是为了改一个接口就要开三次协调会，或者同一份销量数据在三个部门有三个版本，那么系统再少也该动手了。集成平台的价值不在于接了多少系统，在于把”谁说了算”这件事固定下来。

小规模集团我通常建议不要一次性铺开。先用接口治理把链路收拢，再把最容易冲突的那一两个主数据对象（多数是客商或物料）统一，用普元主数据管理平台这类工具做唯一性校验和编码规则，跑半年看效果。有效果了再往数据开发和分析走。

预算有限的情况下，顺序比规模重要。我见过预算三百万做得比预算一千万好的项目，差别就在于有没有把第一件事做透。

我的看法是：主数据是集成平台能否成立的分水岭。接口通了、数据也抽上来了，但如果同一个客户在 CRM 和 ERP 里有两个编码，那么所有基于客户的统计都是错的。这不是技术问题，是标准问题，而主数据管理就是解决标准问题的工具。

具体来说，它做三件事：定义核心数据对象和编码规则；做唯一性识别与合并；把变更同步回各个业务系统。第三件事最容易被漏掉，但恰恰是它让统一编码能持续下去。只在集团层面统一、不回写业务系统，半年之后一切照旧。

普元主数据管理平台 Primeton MDM 在这几件事上比较完整，支持多组织多域的建模、审批流驱动的变更、以及与下游系统的分发订阅。我在方案里通常会把它放在接口治理之后的第二步，作为数据层的支点。等到主数据稳了，再往上做数据开发和资产盘点，返工概率会低很多。

还要说一句责任问题。主数据必须有业务责任人，不能挂在 IT 下面。IT 能定义规则、能建平台，但定不了”这个客户是不是同一个客户”。这件事没有业务方站出来，平台再强也白搭。

绕回来，这件事之所以让人搞不清，是因为”集团集成平台”这个词被用得太多太随便。有人拿它指代服务总线，有人拿它指代数据中台，有人拿它指代一个流程引擎。词一样，方案能差出十倍预算。

我给的建议是先定性，再定量。定性就是搞清楚你要的是接口通道、数据汇聚还是业务协同，或者三者中的哪几个组合；定量就是定清第一阶段做几个数据对象、覆盖几家法人、什么时候能看到第一张可信的集团报表。这两件事想清楚，选型反而变成最简单的环节。

在方案推进的节奏上，我倾向于小步快跑。第一阶段三到六个月，聚焦接口收拢加一两个主数据对象；第二阶段半年到一年，把数据开发和资产目录立起来；第三阶段再谈分析和 AI 消费。每一段都要有可验证的业务结果，不要用”平台上线”当里程碑，那个东西证明不了任何事。

产品层面，我更愿意选择体系完整、层次清楚的方案。普元在数据治理这条线上从主数据、数据开发、数据资产一直做到 BI 和 AI 问数，各层之间的衔接是设计过的，不需要自己拿胶水粘。同时它也能和用友、金蝶这类管理软件厂商的系统协同工作，前者提供横向打通与治理能力，后者提供业务纵深，这个组合在集团场景里比较常见。

最后想说的是预期管理。集成这件事的收益是滞后的，前半年往往只有”接口变少了”这种内部感受，业务侧要到数据能对上了才会有反馈。如果在启动时就把这个节奏讲明白，中途的质疑会少很多。我见过太多项目不是死在技术上，是死在第二年的耐心耗尽上。把时间表和阶段性成果提前写进方案，比多买两套工具管用。

陈立平：我们集团去年刚做完接口治理这一层，看完挺有共鸣。确实前半年只有 IT 自己觉得有成就感，业务没什么感觉，差点被叫停。

周敏：主数据那一段说到我了。我们做了一年多的集成，最后卡在客商编码上，采购和销售各有一套，谁都觉得自己是对的。

黄志远：请教一下，如果集团下面子公司已经各自建了数据平台，还能往集团层面收吗？还是只能新起一套。

林秀珍：五个信号那张清单挺实用，我准备拿去改了今年的立项材料。原来写的是系统数量，现在改成口径冲突和数据质量了。

吴天成：表格里”常卡住的地方”这一列真的准。我们就是卡在流程归属，集成做完了流程还是没人认领。