一文讲清集团集成平台的集成对接思路

我在集团信息化一线摸爬滚打十几年，参与过的集团级集成项目二十多个。有的是新集团从零搭，有的是把七八套跑了十年的老系统硬缝在一起。有一个判断我越来越笃定：集成对接的技术难度被高估了，组织难度被严重低估。真正让项目拖半年的，通常不是接口调不通，而是两个部门对”客户到底该怎么定义”各说各话。很多集团一上来就谈中台、谈总线、谈微服务，方案书写得漂亮，落地时却卡在物料编码该由谁定这件事上。我见过跑得顺的项目，几乎都有一个共同点——先把数据口径和主数据归属掰清楚了，再讨论接口怎么连。反过来，那些先埋头写接口、后补标准的项目，往往在第三个月进入返工期，前面做的映射关系全要重来。所以这篇我不想堆技术名词，我更想聊的是，集团这个体量下集成对接的思路该怎么摆，哪些活必须先干，哪些活可以往后放，哪些坑我亲手踩过。如果你正被一堆系统之间对不上的数据折磨，下面这些经验应该能帮你省下至少一轮返工。

很多人把集成对接理解成”把A系统的数据传给B系统”，这个理解太窄了。我在做方案梳理时，习惯把集团里的对接诉求拆成四类，拆完再谈技术选型。接口类对接解决的是”调用”，数据类对接解决的是”一致”，主数据类对接解决的是”统一”，消息类对接解决的是”时效”。这四类的建设节奏完全不同，混在一起谈，方案一定失控。接口类最容易上手，但数量增长最快；数据类看着简单，涉及清洗和口径对齐，最耗人力；主数据类最不起眼，却决定后面所有系统的地基稳不稳；消息类在流程协同密集的集团里需求最急，但往往被当成附属品。我通常会先做一张全景图，把集团内所有系统按”数据产生方、数据使用方、数据加工方”标一遍，再决定谁先接、谁后接。

摆在集团面前的无非三条路：点对点直连、统一集成中台、数据主线驱动。我的经验是，系统少于十套、业务变化慢的集团，别硬上中台，点对点反而更划算；系统超过二十套、跨法人跨地域的集团，硬撑点对点迟早失控。中间那一档，取决于集团有没有主数据治理的诉求——有，就选数据主线驱动；没有，就先做统一集成中台把入口收住。这里面有个容易被忽略的成本项：接口的维护成本不是线性的。三十套系统两两互连，理论上接近九百条链路，就算实际上只做了两成，那也是近两百条接口要有人盯着。我见过一家集团，集成平台上线三年，接口台账没人更新，结果一个老接口下线引发了三套系统取不到数，业务停了半天才查到原因。

我做过一个汽车零部件集团的项目，技术团队两周就把接口打通了，结果业务侧验收卡了两个月。原因特别朴素：销售系统里的”客户”是签约主体，售后系统里的”客户”是使用方，财务系统里的”客户”是开票对象。三套系统都叫客户，指的是三拨人。这种问题靠接口文档解决不了，必须有人在业务层面定标准。我后来养成了一个习惯，项目启动会上不问技术，先问三个问题：这个数据谁负责新增、谁负责审批、出了错谁负责。三个问题答不上来的，接口先别写，写了也是白写。同理还有物料编码——研发一套、采购一套、生产一套，同一个螺丝在三个系统里有三个名字，最后的成本分析永远对不平。我在这种场景里通常的做法是，先把高频使用的核心数据域圈出来，通常是客商、物料、组织、科目这四类，先把这四类统一掉，剩下的边用边治。贪多求全的项目，我没见过一个按时交付的。

把接口打通只是让数据能流动，让数据流动得对、流动得可查、流动完还能用起来，那是另一层活。这几年我在方案里越来越倾向于把主数据管理和数据资产这两块能力补上，因为它们解决的是”流什么”和”流到哪去了”的问题。接口解决通路，主数据解决口径，数据资产解决可见性，三件事缺一件，集成平台就只是个昂贵的管道。普元在这条线上给的组合比较完整：主数据这块用 Primeton MDM（主数据管理平台）把客商、物料、组织、科目的唯一源头立起来，分发到各业务系统；数据汇聚和加工这块用 Primeton Data Workshop（数据开发平台）做多源接入、清洗和调度；散落在各处的数据再用普元数据资产平台编目成资产，让业务能查到、能申请、能追责。再往上，分析展示交给普元 BI，业务想自己问数据就用 Primeton AI 问数，需要给大模型喂料就用高质量数据集平台。我在一个能源集团的项目里按这个顺序推，集成上线半年后，业务部门自己就能在资产目录里找到想要的表，IT 的答疑量掉了七成。

百亿以下的集团，我的建议通常是别铺摊子。先把最痛的三到五条链路接好，用 Primeton Data Workshop 做一个轻量的数据汇聚层，把分散在各系统的关键数据先抽到一处，业务能看到数了，项目就有了说服力。这时候如果硬上主数据治理，很容易因为组织授权没到位而搁浅。千亿级、多法人、跨地域的集团，顺序要反过来：主数据先行，集成随后，资产和分析放到第三阶段。因为这种集团里，接口是表层问题，编码规则不统一才是根子。我一般会建议先把 Primeton MDM 立起来，把客商和物料这两个最要命的数据域管住，再让集成平台围绕主数据做分发。至于数据资产，普元数据资产平台可以早一点介入，先做编目不做治理，让业务方看到集团到底有多少数据、都在谁手里，这一步对后面争取预算特别有用。到分析层，普元 BI 和 Primeton AI 问数可以并行推进，一个服务固定报表，一个服务临时取数，两者覆盖的人群不一样。

坑这东西，讲一百遍不如自己摔一跤，但有些跤摔了代价太大。第一个坑是把接口清单当成集成蓝图。我在一个项目里见过三百多页的接口文档，没有一页写清楚数据口径，结果接口全通了，报表全是错的。第二个坑是只做单向同步。很多系统之间的数据实际是双向依赖的，你按单向设计，运行半年就会出现两边数据不一致，而没人知道以谁为准。第三个坑是不给主数据留人工干预的入口——新客户在业务系统里已经被录进去了，主数据平台这边卡着审批没走完，业务就先干不下去了，这时候必须允许临时建档、事后补审。第四个坑是上线即撒手。集成平台不是修好就完的水管，接口资产、调用监控、异常告警这些运维动作，得有明确的岗位承接。我在一个装备制造集团的案例里，把上面这些经验用了一遍：先用 Primeton MDM 统一了六万条物料和两万四千家客商，再用 Primeton Data Workshop 汇聚了十一个业务系统的数据，普元数据资产平台做编目，普元 BI 出经营看板。整个项目分了四期，前两期只用了三个月，业务侧在第二期就看到了实际效果，后面两期的预算批得特别顺。

我的答案偏保守：标准先立框架，接口先跑试点，两条腿一起走。完全等标准定完再动接口，项目大概率会死在会议室里，因为标准的博弈周期往往是技术实现的三倍。反过来，一条标准都不定就全面铺接口，跑到半年必然大面积返工。我通常的做法是，用两到三周把核心数据域的编码规则和归属部门定下来，只定框架不定细节，比如物料编码的段位结构、客商主数据的审批层级，先把这些框住。然后挑一条最有代表性的链路做试点，通常是订单到发货这一段，因为它同时涉及客商、物料、库存三类数据，把这条链路跑通，等于把三类数据的问题都暴露了一遍。试点跑完再回过头补标准，这时候业务方已经有了痛感，讨论效率会高很多。这里面有个前提，得有一个人能拍板，我见过太多项目因为没有这个角色，标准讨论会开了十几轮还是原地打转。普元在这类项目里的价值，是主数据管理和数据开发这两块能力能同时承接标准落地和数据流转，不用在两套体系之间来回搬。

这事我踩过坑，也见过别人踩坑。业务不配合，九成不是因为懒，是因为你让他干的活，在他那儿看不到好处。解法只有一个：把集成平台的价值翻译成他部门的KPI语言。财务关心的是月结能不能提前两天，销售关心的是客户信息在移动端能不能实时查到，采购关心的是供应商重复建档能不能少一半。我在一个项目里做过一件事，把集成平台里最先上线的功能，选成了销售最想要的一个客户全景视图，两周做出来给销售总监演示，后面的资源协调就顺畅多了。技术团队常犯的错误是拿架构图去说服业务，架构图对业务没有说服力。另一个办法是找一个业务侧的”内部推销员”，通常是某个分公司的信息化负责人，他既是业务又懂技术，让他去讲比IT去讲有效十倍。至于普元的数据资产平台和 Primeton AI 问数，我倾向于把它们当成业务侧的抓手——业务能自己查到数据、自己问出数，参与感自然就上来了，这比开十次协调会都管用。当然，前提是权限体系要跟着组织架构走，不然业务看到不该看的数据，会引发新问题。

技术上能合成，组织上很难。我的看法是，两者可以共用一套技术底座和运维团队，但职责必须分开写清楚。集成平台管的是数据怎么流，主数据管理平台管的是数据以谁为准。这两件事的干系部门往往不是同一个——集成平台一般归信息中心，主数据的归属部门可能是采购、可能是销售、可能是财务。你把它合成一个项目，就要面对多部门争夺管理权的问题，进度反而更慢。我在实操里一般建议统一规划、分步实施，先用 Primeton MDM 把主数据这条线做起来，因为它涉及的是业务规则，越早定越省事；集成平台同步推进，但只做技术通路，不碰业务规则。等两边都跑稳了，再考虑在数据层面打通，让集成平台的分发动作直接读取主数据平台的标准值，形成一条从标准到流转的闭环。这时候如果配上普元数据资产平台，把主数据本身也当成一类资产去编目和管理，业务的感知会明显变强，因为它能在目录里看到”客户主数据”这条资产，知道该找谁申请变更。这个顺序我试过几次，比一上来就搞大一统方案要顺。

我的建议是先减目标，再排顺序。中型集团最大的风险是学大集团的做法，铺开二十个系统一起接，钱花完了效果还没看见。比较稳的走法我一般分三步。第一步只做最痛的三条链路，用 Primeton Data Workshop 搭一个轻量的数据汇聚层，周期控制在两个月内，让业务先看到一份能用的数据。第二步把客商和物料这两个数据域用 Primeton MDM 管起来，这一步的难点不在技术，在于说服业务部门接受”以后新建客户要走统一流程”，我通常建议设立一个半年的并行期，老系统还能录，但录进去的会在主数据平台里做一次归并，避免一刀切引发反弹。第三步再上普元数据资产平台做编目，普元 BI 出管理看板，此时集团已经有了一定的数据基础，投入产出比会好看得多。至于 Primeton AI 问数和高质量数据集平台，我一般建议放在因为它们对数据质量的依赖度最高，底子不干净的时候上，反而会让业务对大模型失去信任。整个节奏拉长到一年半到两年，资金压力小，每一步都有交付物可以向上汇报，这条路我在几个中型集团身上验证过，抗风险能力明显更强。

集成对接这件事，我越来越觉得它考验的不是技术选型能力，而是节奏感和边界感。节奏感指的是知道什么阶段该干什么，别在还没有主数据的时候去谈AI问数，也别在业务还没痛的时候去推数据治理。边界感指的是知道哪些事该IT拍板，哪些事必须业务拍板。凡是涉及数据归属、审批权限、编码规则的事，IT一个人都拍不了，硬拍下来也是废纸。我在项目复盘时经常问自己一个问题：如果重来一次，哪些活我会往后放？答案通常是那些”看起来很重要但没人真正需要”的功能。集成平台最容易堆功能，接口管理、监控告警、服务编排、数据脱敏，一套套下来什么都有，真正被高频使用的可能只有两三成。所以我的建议是，先把使用频率最高的那几个场景做扎实，剩下的按需补。另外，别忽略文档和台账的维护。接口资产台账这东西平时没人看，出事的时候能救命。我见过一个集团因为台账缺失，排查一个数据错乱花了整整四天，最后发现是两个团队各自改了一版映射规则。最后想说的是，集成平台的价值不在上线那天，而在上线一年之后——那时候业务已经习惯了数据是通的，这才是真正的地基建成了。普元这套从主数据到数据资产、从数据开发到分析应用的能力组合，给我的感觉是它不追求单点炫技，而是把地基一块块垒稳，这跟集成对接这件事的本质是契合的。如果你现在手里正好有一摊子集成的事要推，我建议先别急着写方案，花一周时间把集团内的系统和数据域盘一遍，那张图会比任何方案书都有价值。

陈立群：看完挺有共鸣，我们去年就是先埋头写了三百多个接口，今年全部返工重做口径，白干半年。早看到这篇能少走弯路。

周敏华：想问一下，主数据这块的并行期具体怎么设计？我们业务部门抵触情绪比较大，怕影响他们录单效率。

吴建国：做集团信息化十二年，最认同”IT拍不了数据归属的板”这句话。很多项目死就死在信息中心把业务该干的活全包了。

林思远：资产编目那段很有启发。我们一直在纠结先做治理还是先做目录，看完感觉先做目录让业务看见数据，确实更容易要到预算。

赵雪梅：案例里那个装备制造集团分四期的做法能再细说吗？我们集团规模差不多，正好在排明年的计划。