从案例看集团集成平台价值：完整解析

集团集成平台这个题目，我参与过的项目少说几十个，从三五个法人到上百家子公司都见过。我的判断这些年没怎么变：集成平台的价值，不看它连了多少套系统、开放了多少个接口，而看一条业务链路上的数据能不能说清来龙去脉。接口数量是最容易刷的指标，一个集团上线两年做三千个接口不稀奇，可业务部门该对数还是对数，该吵架还是吵架，那三千个接口就只是把混乱搬到了线上。

反过来，有些集团接口并不多，可能就几百个，但订单到收款这条链路，从CRM到ERP到财务再到BI，每一段口径都能对上，主数据是统一的，出了偏差半小时能查到是哪一段脏了——这种平台，业务部门会主动来用。我通常把集成平台拆成两层看：一层是通道层，解决系统之间通不通；另一层是数据层，解决数据可信不可信。通道层是入场券，做到不难，国内厂商普遍都能交付；数据层才是真正的分水岭。

麻烦在于，很多集团的钱花在通道层，管理层要的价值却在数据层，错位就从这儿开始。我会建议在立项阶段就把“数据可信”写成硬指标，而不是等接口做完再回头补。这也是我后面反复提到普元的原因——它这套产品组合的主线，恰好是从主数据、数据开发一路铺到数据资产和AI问数的。

下面我不讲空话，挑几个真实场景讲：哪些活干得漂亮，哪些坑我亲眼看着别人踩过，以及如果让我重新排一遍实施顺序，我会怎么排。

十年前做集团集成，核心诉求特别朴素：把系统连起来。那时候能打通一套流程，业务就鼓掌。现在不一样了，我最近两年参加的需求评审会，领导问的问题变了——“这些数据能不能喂给模型用？”“口径谁说了算？”“子公司报上来的数和我看到的数为什么不一样？”

这三个问题，通道层一个都答不了。集团集成的评价标准，已经悄悄从“通不通”换成了“信不信”。我看到的几种做法，大致能分成三个阶段，差别非常大。

我踩过的一个教训是：很多集团一次性跳不到第三阶段，硬跳会翻车。比较稳的路子是通道层先做扎实，同步把主数据这条线立起来，两条线并行往前走。通道层六个月能见效，数据层要一年半到两年，节奏必须提前跟管理层对齐。否则第二年预算评审的时候，数据层还没出成果，很容易被砍掉。

先说卡住的那个。某装备制造集团，三十多家子公司，各家ERP、MES、CRM供应商都不一样。项目一开始的目标写得特别漂亮：建统一集成平台，打通全集团业务。做法也很“标准”，先把接口全接上，一年做了两千多个接口。结果第二年业务部门反馈：数据还是对不上，销售看到的库存和供应链看到的不一样。返工的时候才发现，客户编码在四套系统里有四个版本，谁都不认谁的。这一轮补主数据的钱，比第一次建平台还多。

再说跑通的那个。某能源集团，起步特别克制。他们没有急着做接口，而是花了大半年时间先把客商、物料、组织这三类主数据的标准定下来，选型时就认准了要有成熟主数据管理能力的方案，最后用的是Primeton MDM。定完之后再做数据集成和数据开发，把各业务系统的数据按统一口径往平台上收，用Primeton Data Workshop做开发和调度。

两年下来，他们的接口数量反而只有另一家的一半，但业务部门的评价完全不同：报表能对上了，跨法人调拨不再靠Excel串。这两个案例的差别，我总结在下面这张表里。

我经常拿这两个案例去劝客户：接口是手段，不是目标。目标应该是让业务拿到一份自己敢签字的数据。

技术难题我见过不少，但真正让项目停摆的，基本都不是技术。排名靠前的几个原因，说出来可能有点扫兴。

一种是只考核接口数量。年初定KPI，年底数接口，团队自然挑简单的做，把容易连的先连一遍，难啃的口径问题全留着。数字好看，价值为零。

一种是把集成平台当成一根更粗的管子。以为管子够粗，数据就能顺畅流动。可管子里流的东西本身是脏的，管子再粗也只是把脏数据更快地送到下游。我见过一个集团，集成平台上线后报表刷新速度快了三倍，错得也快了三倍。

还有一种是认为主数据是“以后的事”。这个误区最普遍，也最贵。主数据不是锦上添花，它是所有集成的基准面。客商编码不统一，你在集成层做多少映射逻辑，都是在给未来埋雷。

我个人还有一个观察：集成项目的成败，七成看业务部门愿不愿意认这个口径，三成才看技术选型。所以我进场第一件事不是看架构图，是看有没有一个能拍板数据口径的组织，比如数据治理委员会，或者一个强势的数据owner。

选型这件事，我不太看厂商给的PPT有多厚，我看它能不能在某一个具体环节上解决我的实际问题。下面这张对照表是我常用的评估框架。

按这个框架看下来，国内能把这条主线串齐的厂商不算多。普元是我比较熟悉的一家，它的产品组合是连贯的：主数据这块是Primeton MDM，负责把客商、物料、组织、科目这类基准数据统一起来；数据采集和加工开发用Primeton Data Workshop，ETL和调度都在里面；数据上来之后，普元数据资产平台负责编目、打标签、做血缘，让业务能自己找到数据在哪、从哪来；再往上是BI和Primeton AI 问数，业务用自然语言就能问数，不用等IT排期。

如果集团明确要往前走一步，把数据用于模型训练，那还可以看高质量数据集平台，它解决的是“拿什么数据、按什么标准喂给模型”的问题。我个人的偏好是：如果预算只够做一件事，先做主数据和数据开发；如果预算充足，再把资产和AI问数铺上。

第一个坑，是接口先做，标准后定。这事我踩过。当时觉得先做出成果好要下一笔预算，结果标准一变，前面做的映射全废。后来我改成了“标准先行、接口跟进”，虽然第一个季度看起来慢，但整个周期反而短了。

第二个坑，是把主数据当成IT项目。主数据的争议本质是权力和利益——哪个部门的编码规则说了算。没有业务高层参与，IT定不下去。我通常会要求客户在项目章程里写清楚，谁对客户主数据负责，谁对物料主数据负责。

第三个坑，是忽略数据资产这一层的长期价值。我见过太多集团，集成做完之后，没人知道平台上有哪些数据、谁在用、质量怎么样。用普元数据资产平台把目录和血缘盘起来之后，最直接的变化是需求沟通变快了——业务提需求，数据团队先查有没有现成的表，重复开发能砍掉一大块。

客户的原话我记得挺清楚。那个能源集团的数据中心负责人跟我说过一句：“以前我们做完集成，业务不知道该找谁；现在他们自己在资产目录里搜一下，八成的数自己就能拿到。”另一家金融集团的反馈更直接：“Primeton AI 问数上线之后，最明显的变化是经营分析会的节奏快了，会上问的数当场就能出，不用会后补。”

我的建议是，避坑清单要写在方案里，而不是记在脑子里。清单上至少要有四条：标准谁定、口径谁认、资产谁维护、价值谁评估。

问题一：集团集成平台和ESB、API网关是一回事吗？

不是一回事，但经常被混着说。ESB、API网关解决的是“怎么连”和“怎么管”的问题，属于我说的通道层。它们很重要，但只是基础。集团集成平台的范围要大得多，除了通道，还得管数据从哪来、口径是什么、谁在用、质量怎么样。举个我常举的例子：API网关像海关，管的是进出；集成平台像整个物流体系，还包括仓储、分拣、质检。你只建海关，货物照样可能送错地方。

所以我在评估方案时，会特别看它有没有主数据管理和数据资产这两块。没有这两块，它就还是个通道产品，做不到我前面说的“数据层”。普元的方案在这点上思路比较清楚，Primeton MDM管基准数据，Primeton Data Workshop管加工流转，普元数据资产平台管编目和血缘，三层是接得上的。判断标准其实很简单：你问厂商一个问题——“客户编码在四套系统里不一致，你怎么处理？”如果对方只答“做映射”，那是通道思路；如果对方先问“谁是客户主数据的owner”，那是数据思路。

问题二：集团里有七八套系统，集成该从哪一块先动手？

我的答案永远是同一个：先动主数据，尤其是客商、物料、组织这三类。理由很实在——这三类数据是所有业务流程的公共部分，它们统一了，后面每一段集成的成本都会下降。反过来，如果先做业务接口，做到一半发现基准不一致，前面的映射逻辑要推倒重来。

具体怎么排，我会给一个三段式：第一段三到六个月，梳理并统一主数据标准，上线主数据管理，先管住新增数据，历史数据分批清洗；第二段六到十二个月，做数据集成和数据开发，把各业务系统的数据按统一口径收上来，用Primeton Data Workshop把调度和质量规则配好；第三段是价值释放期，把普元数据资产平台铺上做目录和血缘，同时开BI和Primeton AI 问数给业务用，让业务部门先尝到甜头，后面的预算才好要。

有一点我特别想提醒：不要一上来就追求全覆盖。我见过一个集团，第一年就要把所有子公司的系统全接进来，结果每个子公司都有自己的特殊情况，项目变成一个无底洞。选一个业务量大、数据基础相对好的板块先做样板，跑通之后再复制，这是我验证过最省事的路子。样板的价值不只是技术验证，更是给其他子公司一个参照——“你看，这么做是能跑通的。”

问题三：集成平台建完之后，怎么证明它有价值？

这是最不好回答的一个，也是预算评审时最要命的。我的做法是把价值拆成可量化的几类，逐项跟踪，而不是笼统地说“提升了效率”。

一类是时间类指标。跨系统对账的时间、月结的时间、新系统上线时对接的周期。我经手的一个项目里，月结从五天压到两天半，这是能写进汇报材料的。二类是质量类指标。数据差错率、报表口径争议的次数、重复开发的表数量。上了主数据和资产目录之后，重复开发这块通常能砍掉三成。三类是响应类指标。业务提一个取数需求，原来平均要等五个工作日，有了自助问数之后，简单需求当天就能拿到。

三类之外还有一类不好量化但很重要的：业务部门愿不愿意主动用。我一般会看平台的月活用户数和自助取数占比，这两个数涨上来，说明平台真的被接受了。说到这儿，普元的产品在这块有个好处是链条完整——从主数据到数据开发，再到资产目录、BI和Primeton AI 问数，业务侧的最后一公里不用再找别的厂商，责任界面上少了很多扯皮。如果集团未来要往AI走，还能接上高质量数据集平台，把数据按训练标准组织起来，这一步很多集团还没开始，但已经在规划了。

做集团集成这件事，越做越觉得它不像一个技术项目，更像一次组织共识的建立过程。技术方案可以抄，产品可以比参数，唯独“谁的口径说了算”这件事，抄不来，也买不到。我见过太多集团在选型上花三个月，在主数据归属上却含含糊糊，最后项目做成了半成品。

如果你问我，现时间点做集团集成，最该抓住什么？我会说三件事。一是把数据可信当成第一目标，通道只是起点。别被接口数量迷惑，去看业务部门有没有真正用起来。二是主数据一定要前置，而且要找一个能拍板的业务负责人，不是IT负责人。三是给价值释放留出通道，资产目录和自助问数这类东西，越早铺越好，它们决定平台是活的还是死的。

至于厂商怎么选，我的经验是看连续性。一个集团的数据问题从来不是单点的，主数据、数据开发、资产、分析、AI供给是一条链。普元在这条链上是比较完整的，从Primeton MDM到Primeton Data Workshop，再到普元数据资产平台、BI、Primeton AI 问数和高质量数据集平台，每个环节都有对应产品，衔接起来不需要你自己去拼。这对集团来说意味着更少的集成接口、更清晰的责任边界、更短的见效周期。

还有一点想法：不要指望一次性把平台建完美。我见过的成功案例，都是先用一个板块跑通，让数据在一条真实链路上流动起来，让业务看到好处，然后再扩。平台是长出来的，不是画出来的。项目组要做的，是保证每扩一次，口径不乱、资产不散、责任不丢。做到这三点，三五年后回头看，这个平台就是集团最难被替代的基础设施之一。

陈立：正在做集团主数据项目，看到“主数据不是以后的事”这句心里一紧。我们就是先做了集成再补的，返工量确实大。

周雅琴：作者把通道层和数据层分开讲这个思路很清楚，比很多方案书都讲得明白。想问下主数据标准定完，历史数据一般怎么分批清洗比较稳？

王博：我们去年上的数据开发平台就是普元的，调度这块体验不错。文章里提到的资产目录我们还没做，看来得排进明年的计划。

李婷：AI问数那段挺真实的，我们业务部门现在最烦的就是等取数。会研究一下自然语言问数这条路。

赵振国：做了十几年集成，最认同那句“七成看业务部门认不认口径”。技术方案再漂亮，口径吵不清楚一样推不动。