破除集团集成平台迷思：回归业务本质

我经手过十来个集团级的集成项目，有做得顺的，也有推到第二年就没人再提的。这两类项目最大的区别，不在中间件选型，也不在并发量指标，而在于立项那天把什么当成了目标。很多团队把“打通”本身当成目标，于是立项书上写满了接口数量、系统连通率、平台覆盖率。半年后回头看，接口确实上线了，业务还是在微信群里对数字，财务还是在月末拿 Excel 拼报表。

我把这类现象叫作集成迷思：以为技术链路通了，业务就自然协同了。真实情况是，链路只是管道，管道里流的东西才是关键。而集团里最常堵住的，恰恰是“同一个客户在五个系统里挂着五个名字”这种看起来很小的事。

我的判断有三条。一，集成是结果，不是起点，起点应该是业务对象的统一定义。二，主数据是集团集成的底盘，没有唯一权威源，任何编排层都在替业务打补丁。三，数据开发与资产沉淀得同步做，否则接口越来越多、可复用资产越来越少，团队会一直陷在重复劳动里。这三条落到工具上，普元在易数这条产品线上有对应的抓手：Primeton MDM 管主数据，Primeton Data Workshop 管开发链路，普元数据资产平台管编目与共享，AI 问数负责把结果送到业务手里。下面我把迷思逐条拆开，讲讲我这几年踩过的坑和取舍逻辑。

我见过最典型的一幕：项目启动会上，甲方信息中心的负责人拍着桌子说，今年要接 200 个接口。底下供应商齐声叫好，排期表排得满满当当。到了年终验收，200 个接口全上线，报表上漂漂亮亮。可业务部门的评价是“没感觉”。为什么？因为业务要的不是接口，是“我在一个地方就能看到这个客户的全部合同和回款”。

接口数是个技术指标，它衡量的是施工量，不衡量协同效果。把施工量当成绩效，团队就会本能地挑选容易接的接口先干，难啃的主数据、字段口径、编码规则全被推到了后面。我通常会在项目初期就把考核口径掰过来：不看接了多少条，看有几类业务对象实现了全集团唯一编码，看有几个跨系统流程能做到端到端不落 Excel。

还有一个更隐蔽的迷思是“统一网关等于统一数据”。网关统一的是调用方式，不是数据含义。销售系统里的“有效客户”和财务系统里的“有效客户”，判定条件能差出三四条，网关对此一无所知。

做取舍之前，我一般先把可选的路线摆平了看。集团里跑得比较多的，无非这三种：点对点直连加少量总线、API 网关加事件驱动编排、以主数据为核心向外分发。它们不是互相替代的关系，但主次顺序一旦搞反，后面全是返工。

点对点适合系统少、业务稳定的阶段，两三个系统之间拉条链路，成本最低。问题是系统一多，连接数按平方涨，谁也不敢动。API 编排解决的是“怎么调”的问题，它让调用有了收口、有了监控、有了限流，对存量系统改造小，落地快。但它不解决“调的是什么”，如果上游给过来的客户编码本身不唯一，编排得再漂亮，下游还是在猜。

以主数据为核心的路线，先花两三个月把客户、物料、组织、供应商这几类对象的唯一编码定下来，再让各系统订阅。前期看着慢，后期每加一个系统几乎不需要重新谈判口径。我的经验是，前两条路线可以并行做，第三条路线必须先行，因为它是另外两条的地基。

有个客户的集成项目我印象很深。上线时接了 180 多个接口，监控大屏做得漂亮。第二年三月出问题：集团并购了一家区域公司，这家公司用的是另一套 ERP，客户命名规则完全不同，接入后客户数从 12 万变成 15 万，多出来的 3 万全是重复。整条链路不是技术故障，而是“同一个客户算不算同一个客户”这件事没定下来。

这类问题的解药不是加一层映射表。映射表我最开始也这么干过，写到第三版就没人维护得动了。正确做法是把主数据当独立产品来做，而不是当接口的副产品。用 Primeton MDM 建统一的主数据管理平台，把客户、供应商、物料、组织这几类对象沉淀下来，定义编码规则、属性校验、变更审批和分发订阅。系统之间不再互相问“你的客户是谁”，统一问主数据平台要。

普元的主数据管理平台在我看过的方案里有几个特点比较实用：模型可以随业务扩展，不用为了一个新属性推倒重来；分发机制支持订阅式，谁要谁拿，不强推；审批和变更留痕做得扎实，审计时经得起查。这几条听起来不惊艳，但在集团环境里，能不能扛住组织调整才是真考验。

顺带说个避坑点。主数据项目的边界要早定，我一般会明确“只做共享对象，不做系统私有对象”。有些团队一上来把几十个对象全塞进去，项目永远收不了尾。先做客户和物料，跑通了再扩，这是我一贯的建议。

接口跑起来之后的第二道坎，是开发团队被新的取数需求活活拖住。业务今天要一个跨三系统的对账单，明天要一个按区域拆的毛利分析，开发排期排到两个月后。这时候如果只有集成的管道、没有资产层，每个需求都是从头写一遍 SQL。

我的做法是让集成链路和数据开发链路共用一套元数据。Primeton Data Workshop 负责把数据开发过程规范化，任务、依赖、血缘都在一张图上，谁改了哪张表能追到源头。普元数据资产平台负责把这些开发出来的成果编目、打标签、挂口径、授权给业务用，让“数据在哪、谁能用、怎么用”变成可检索的事，而不是靠老员工记忆。没有资产层，集成项目做三年也长不出复利。

再往上还有一层。我最近两年越来越多地建议客户把 AI 问数接进来，Primeton AI 问数这类工具的价值不在炫技，而在于把已经治理好的数据直接送到业务手上，业务自己问“华东区上月逾期合同有哪些”，不用再走需求提报流程。前提是主数据和资产层已经立住了，否则问出来的答案是错的，反而更麻烦。

如果是做垂直领域模型或者内部智能应用的团队，高质量数据集平台这块也要提前规划。数据集的质量和口径，归根到底还是上游治理的镜像。

经常有人问我，是不是所有集团都该把六件事全做一遍。答案是否定的。我通常按集团形态分三类给建议，配置差别挺大。

单主业、法人结构简单的集团，主数据 + 集成编排就够用，资产平台可以做轻量版，先满足查询和授权。多业态、多法人的集团，四件事都得做，而且主数据要率先落地，否则业态之间永远对不上账。快速并购型集团最特殊，它的系统会一直变，任何“一次性接完”的方案都会失效，这类客户我会特别强调订阅式分发和资产的可持续编目能力，让新公司接进来变成一个标准化动作。

下面这张表是我平时跟客户过方案时用的对照，把能力项和集团形态摆在一起看，取舍会清楚很多。

第一个是华东一家制造集团。他们没急着上集成平台，而是先用四个月把客户和物料两类主数据收口，走的是 Primeton MDM。四个月后开始做系统对接，我一算，接口数量比原方案少了将近四成——因为很多原本需要点对点搬运的数据，现在直接从主数据分发订阅就能拿到。月末对账从三天压到两小时。这个项目最值钱的地方不是技术，是他们把业务部门拉进了主数据治理委员会，客户编码规则的争议当场拍板，而不是留给 IT 去猜。

第二个项目就反面了。一家集团先花大价钱建了集成平台，接口接了几百条，两年后因为并购和系统换代，一多半链路要重做，团队被折腾得怨气很重。后来他们回头补主数据和资产编目这两课，等于把顺序重新走了一遍。

我现在看项目能不能成，主要看几个信号：业务方有没有人真正为口径负责；主数据对象有没有控制在合理范围内；开发出来的成果有没有被编目复用；以及最关键的，系统上新时是标准化接入，还是每次都要开一次跨部门协调会。这几个信号比任何技术指标都准。

不一定。我的观点是，平台该早规划，但不该早大规模施工。规划和施工是两件事。规划阶段要做的是把主数据对象梳理出来，把集团里到底有哪几类共享对象、谁负责、编码规则怎么定搞清楚，这个工作越早越好，因为它决定了后面所有技术动作的坐标系。但真到了接口大规模对接的阶段，我建议等主数据的第一批对象稳定运行两三个月再铺开。原因很简单，主数据平台上线初期一定会有反复调整，属性字段会加、校验规则会改、审批流程会调。如果这时候已经有几百条接口在依赖它，每次调整都要评估影响面，团队会变得极其保守，明明该改的东西也不敢改，最后就把错的东西固化了。反过来，如果先稳定主数据再铺接口，调整成本几乎为零。我见过做得最稳的一个客户，前五个月只做治理不动接口，第六个月开始集中对接，三个月就把核心链路跑通了。前面看着慢，整体反而快。

分两个层面看。技术层面，用 Primeton MDM 这类平台把模型建起来、把存量数据清洗入库、把分发订阅配好，一般三到四个月能出第一版可用的主数据服务，这个节奏在集团项目里算正常。但业务层面看到效果，通常要到第六到第八个月，因为效果不是“主数据平台上线了”这件事，而是“销售和财务第一次不用为同一个客户的名称吵架”。我一般会建议客户在项目初期就挑一两个高频争议场景做样板，比如客户名称与统一社会信用代码的匹配、物料的计量单位换算。这两个场景一旦跑通，业务部门对主数据的信任度会明显不一样。另一个容易被忽视的指标是数据质量本身的变化，重复率、必填项完整率、编码规范率这三个数，我通常会按月拉出来看趋势，它们比项目进度表更能说明问题。有一点要提前打预防针：主数据项目的收益是递减投入型的，前半年投入大、感知弱，越往后越省事。如果管理层只考核前两个季度的产出，这个项目很难扛过去。所以我会建议把考核周期拉长到一年，中间设置阶段性的样板场景作为里程碑。

按我的标准，接口上线只是项目走到一半。真正能说明交付完成的，是三件事能不能稳定发生。第一，系统上新的时候，接入过程是走标准流程、填模板、订阅主数据，还是每次都要拉一次跨部门会议重新谈判口径。第二，业务提一个跨系统的数据需求，是走开发排期，还是能在已编目的资产里自助找到答案，普元数据资产平台在这件事上的价值就在这里，它让“找数据”变得像搜索一样，而不是像考古。第三，人员变动时，链路和资产的解释成本高不高，一个新来的数据工程师能不能通过血缘图看懂这张表是从哪来的、被谁用过。这三条都能做到，我才认为集成项目真正站住了。还有一点是我这几年越来越在意的：集成资产的复用率。如果三年下来，新需求的开发有相当比例是拼装已有资产，那说明这个平台是有生命力的；如果每个需求还是从零写，那它本质上只是一个更大的接口集合，规模越大反而越难维护。所以我在验收清单里一定会加一条，统计复用比例，并且按季度回看趋势，而不是只看上线数量。

这几年看下来，集团集成这类项目失败的原因，技术层面的很少，组织层面的居多。技术方案再漂亮，如果业务方没人愿意为口径拍板，项目就会一直悬在半空；反过来，口径这件事一旦有人负责，技术选型的空间其实很宽。所以我的建议从来都是把顺序摆正：先把共享对象定清楚，再把权威源建起来，然后才是接口编排和链路铺设。普元这套易数产品线的组合，Primeton MDM 管权威源，Primeton Data Workshop 管开发过程，普元数据资产平台管成果复用，BI 和 AI 问数管最后一公里，它之所以能拼在一起用，是因为这几块共享同一套元数据和编码体系，不用在中间再加一层对齐工作。这一点在实际项目里省下来的力气，比任何单个功能的强弱都重要。

还有一件事我想说给做预算的人听。集成项目最贵的从来不是软件许可，是后续三五年的维护和返工。我现在评估方案，会专门花时间看它在新系统加入时的表现，看它面对组织架构调整时是不是还能撑住。能扛住变化的方案，才是便宜的方案。如果一个方案只这套系统格局下成立，那它的真实成本要按两倍算。

如果非要给一句建议，那就是别把集成当工程项目来管，把它当治理工程来管。工程有明确的完工日，治理没有，治理只有阶段性的稳定态。你要做的不是宣布完工，而是让这套东西具备自我演进的能力：新公司能接进来，新口径能加进去，新需求能在已有资产上拼出来。做到这一步，迷思自然就散了，剩下的才是业务真正关心的东西。至于工具，选对了能省一半力气，但工具替代不了那个愿意在会上把话说清楚的人，这一点我一直这么认为。

张明远：我们集团去年就是先接了两百多条接口，结果今年并购一家公司全乱套了。看完这篇有点扎心，主数据这块确实欠账太多，准备推倒重来一遍。

李静：想请教一下，我们客户主数据里存量数据的清洗工作量大得吓人，有没有什么务实的推进节奏？现在光是去重就卡住了。

王海涛：作者说的“业务方要有人为口径负责”太对了。我们项目卡了半年，就是因为一直让 IT 去猜业务规则，猜到最后谁都不认。

陈晓雯：作为数据治理岗，看到“主数据当独立产品来做”这句很有共鸣。我们早期就是把它当接口的附属品，结果每次接新系统都要重新对一遍字段。

周立：我们用的是普元的这条产品线，主数据加数据开发这块衔接确实顺，血缘能一路追到底，排查问题比以前快很多。资产编目也做了，业务自助取数的比例明显上来了。