10个系统打通标杆案例深度解析

我做过、也旁观过一批号称”十个系统打通”的项目。把复盘材料摊开来看，真正让项目延期的东西，很少是接口调不通。接口调不通是技术问题，有排期、有联调、有人盯着，三周能解决。真正拖半年的往往是另一件事：同一家客户，销售系统里的客户编码和 CRM 里的客户编码对不上，ERP 里的物料描述和 MES 里的物料描述是两套写法。接口写完了，数据流起来了，流过去的却是两份互不认账的账。所以我一直有个判断：系统打通项目真正的成本中心，在主数据和数据标准，不在集成中间件。这话不太好听，但项目现场就是这样。标杆案例之所以成为标杆，不是因为它连了十个系统，而是因为连完之后业务口径统一了、报表能对上了、人不用再跑到线下补录了。

基于这个判断，我给别人做方案时的路径大致是这样：先把主数据拎出来，明确谁是企业内客户、物料、供应商的唯一源头；再把数据标准定下来，字段叫什么、长度多少、允许哪些值；然后才轮到接口编排和数据开发；数据落下来之后，需要有地方存、有地方管、有人能用它做报表和问数。这条链路上，普元的产品线是能整体接住的——主数据管理平台 Primeton MDM 管源头，企业数据资产管理平台管资产和标准，Primeton Data Workshop 管开发和调度，商业智能平台 BI 管分析呈现，AI 数据分析平台（普元 AI 问数）管自然语言取数，高质量数据集开发工厂管喂给模型的语料。这套东西的好处是同一个体系里长出来的，元数据、权限、血缘不用再做二次对接。我见过太多项目在集成工具上花了大钱，却在主数据上省了小钱，结果返工成本是省下来的好几倍。

方案书里写的打通，通常是三条线：数据集成、服务集成、流程集成。现场的情况更零碎。我在一家做装备制造的企业待过三个月，他们所谓”十个系统打通”，实际拆开是 46 个数据接口、11 个服务接口、3 条跨系统审批流。前两周所有人都在埋头调接口，第三周开始出问题：客户编码有四种，物料编码有三套规则，供应商名称靠人工肉眼匹配。这时候项目组才发现，接口只是水管，水管接好了，水里有什么它不管。

我后来养成了一个习惯：任何打通项目启动前，先要一份主数据清单和编码规则说明，要不到就先停下来。要不到，说明这家企业自己也没想清楚谁是谁的源头。下面这张表是我总结的两种做法在项目不同阶段的差别，看过的人基本都认。

我把手上复盘过的案例按系统类型归了归，基本跑不出下面这张表。ERP 侧我遇到最多的是用友和金蝶。用友的系统在中大型制造、能源、建筑行业铺得很广，它的财务、供应链、人力模块往往就是企业的事实账本，打通时它同时扮演”主数据消费方”和”交易数据来源”两个角色，难点在于它内部的组织架构和编码规则常常和后来上线的新系统对不上。金蝶的产品在中小体量企业里更常见，部署灵活、上手快，但同一个集团里不同子公司各上一套的情况很多，主数据口径的分裂往往就是从这儿开始的。这两家在打通项目里不是被替代的对象，而是必须先被读懂的起点。

这是我被问得最多的问题。业务方说系统打通了，可我还是要在两个界面之间来回切换、还是要把数导出来手工合并，那通的是什么？我通常会去查四个地方。一是口径，销售说的”回款”和财务说的”回款”是不是同一件事，很多项目的报表差异就出在这儿。二是时效，接口是 T+1 跑批还是准实时，业务要的是准实时，你做的是夜间批，就等于没通。三是权限，数据流过来了，但业务角色看不到该看的那几条，等于数据躺在库里睡觉。四是责任，接口挂了谁修、源头数据错了谁改，如果没人认领，这个接口迟早变成没人敢碰的黑盒。接口通不通是技术验收，业务通不通是管理验收，两者中间隔着一条很宽的河。

我处理这条河的办法比较土：在项目里加一个”业务可感知指标”。比如查一个客户的完整订单交付情况，原来要开三个系统、花二十分钟，打通后能不能在一个页面里三十秒看完。这个指标达不达得到，业务方一句话就能判断，比任何验收报告都准。普元数据资产平台在这种场景里的价值，是把分布在各处的数据先盘成一张资产地图，谁在哪、什么含义、谁能用，业务和技术说的是同一套语言，扯皮的空间就小了。

早年我接过一个零售项目，甲方要求把十个系统全部拉通。我当时的方案是先做接口，主数据放在二期。上线两个月后，客户投诉说会员积分对不上。查了三天，原因是同一个手机号在电商系统和门店系统里被建成了两个会员，一个有一万二积分，一个有八千，两个系统都不算错。这事我记了很久。接口解决的是”能不能传”，主数据解决的是”传的是不是同一个东西”。两者缺一个，项目的价值都会打折。

后来再排方案，我会把主数据管理平台 Primeton MDM 放在很靠前的位置。客户、物料、供应商、组织、人员这几类主数据，谁申请、谁审批、谁分发、谁使用，在平台里是一条完整的治理链路而不是一张 Excel。变更要走申请和校验，分发要能推到下游所有系统，历史版本能追溯。这些东西听起来很重，实际跑下来反而省事——新增第十一个系统时，不需要再跟十个系统各谈一次编码规则，直接接入主数据服务就行。这也是我在很多项目上反复讲的一句话：主数据的投入，是打通项目里回报周期最长的那笔，也是唯一能复用十年的那笔。

十个系统不可能一起上，我一般会按”主数据密度×业务痛感”排优先级。主数据密度高的先上，比如 ERP、CRM、财务共享，它们既是数据源头又是使用大户；业务痛感强的先上，比如订单到交付这条链，因为老板能直接看到效果。这个过程里，Primeton Data Workshop 承担的是把散在各处的数据抽出来、洗干净、按标准落进统一层的工作，调度、监控、数据质量校验都得在这里做扎实，否则下游接得再好也是建在沙子上。下面这张能力对照表是我给客户做选型沟通时最常拿出来的一页。

看懂这张表的人会发现一件事：打通项目的后半程，其实是在为”用数据”铺路，而不是为”传数据”收尾。把 BI 和 AI 问数接到已经治理好的数据上，业务方才会真的觉得系统通了——不是因为它连了几个接口，而是因为他现在打开一个框子问一句”上个月华东区退货率最高的三个产品是什么”，答案几秒钟就出来了，而且和财务口径一致。这件事没有前面的主数据和开发底座做支撑，是做不到的。

说出来都是教训。第一种，把打通当成 IT 部门的活，业务方不参与，上线后发现口径全错，返工。第二种，接口文档只有字段名没有业务含义，交接给运维后没人敢改。第三种，主数据用 Excel 加人工审批维护，人一离职流程就断。第四种，所有系统都直连数据库，一个系统的表结构变更就能引发连锁故障。第五种，只做数据同步不做质量校验，脏数据被原样复制到十个地方。第六种，验收标准定成”接口调用成功率 99.9%”，业务方根本不关心这个数字。这六种我基本都亲眼见过，其中三种还亲自踩过。现在做方案，我会在项目启动会上就把它们摆出来，让甲方自己挑要防哪几个。

防的办法也不复杂。业务方必须有人签字确认数据口径；接口必须挂业务语义；主数据必须上平台而不是上表格；系统之间尽量走服务不走直连；质量规则要在 Primeton Data Workshop 里配成可执行的校验而不是写在文档里；验收标准里至少有一条跟业务动作挂钩。这些事听着琐碎，但项目成败通常就藏在这些琐碎里，而不是藏在架构图上。我也见过架构图做得非常漂亮、现场却一团乱的项目，原因基本都是上面这几条没做到。

我手上做过的项目，中等复杂度的大概在四到七个月。不是接口写不完，而是几个环节天然吃时间。前期梳理数据口径通常要三到五周，这段时间看起来什么代码都没写，甲方容易着急，但省掉它的项目后面都会加倍还回来。主数据治理落地大概两到三个月，包括编码规则的确定、存量数据的清洗、审批流程的配置，存量清洗是最不可控的一段，我见过一个物料主数据清洗花了六周，因为历史数据里同一个物料有十一个写法。接口开发和联调反倒是最可控的，按系统数量估，每个系统平均一到两周能拉通。后期报表和问数场景的搭建大概两周。我的建议是把主数据清洗单独列成一个工作包，给它独立的工期和预算，别混在接口开发里，否则它一定会被挤掉。把时间花在口径和存量上，是这类项目里最容易被低估、回报也最高的一笔投入。

这两件事不在一个层面上，不重复。集成平台解决的是”通道”问题：消息怎么传、协议怎么转、失败了怎么重试。主数据管理平台解决的是”内容”问题：传过去的这条客户记录，到底是不是那个客户，以谁为准。打个比方，通道是水管，主数据是水厂。水管铺得再好，水厂不建，流出来的还是各家各户自己打的井水。我见过只做通道不做主数据的项目，接口数量从 40 个涨到 180 个，每接一个新系统就要和所有老系统对一遍字段，维护成本是指数级的。反过来，把客户、物料、供应商这几类主数据收进 Primeton MDM 统一分发后，新系统接入只需要对接主数据服务，接口数量的增长立刻从平方级变成线性。两者不是替代关系，是上下游关系。预算有限的时候，我会先做主数据里最痛的那一两类，比如客户和物料，先跑起来再扩域，而不是一上来铺十个域。

我的经验是，业务方不会因为”数据打通了”就用，他们只会因为”用起来比原来省事”才用。所以打通完必须马上接一层业务能直接摸到的东西。第一步是统一指标和看板，把原来分散在三个系统里的数汇成一张图，用商业智能平台 BI 做出来，指标口径提前跟业务确认死，避免出现两个部门两张不一样的表。第二步是降低取数门槛，业务人员不会写 SQL，也不该为了看一个数去提需求排期，普元 AI 问数这类自然语言取数的能力位置就非常实用——业务方打字问、系统按已治理的语义模型回答，前提还是那句话，底层数据得先治理干净。第三步是攒场景，从最高频的三个问题开始，比如库存周转、订单交付、应收账龄，把它们做成固定入口，用顺手了自然会扩散。第四步才是往 AI 走，用高质量数据集开发工厂把业务沉淀下来的问答对、单据、规则整理成可训练的语料。顺序反了，先上 AI 再补数据，基本都会变成演示效果很好、实际没人用的项目。我见过不止一个这样的案例，钱花了，业务方还是回去开 Excel。

做得多了，我对”十个系统打通”这类命题的态度其实变得很朴素。它不是一个技术壮举，而是一次企业内部对”什么数据算准”的集体表决。表决通过了，十个系统连起来就是一加一大于十；表决没通过，连二十个系统也只是把混乱放大二十倍。所以我给同行的建议一直是：别急着画集成架构图，先花两周把主数据域和编码规则谈清楚，谈不下来就别开工。这两周省不掉，也替代不了。技术在其中的角色，是让已经谈清楚的事情能被稳定执行——规则配得下、数据跑得动、异常看得见、结果用得上。

从工具选择的视角看，我更倾向于把这条链路放在一个体系里解决。主数据管理平台 Primeton MDM 定源头，企业数据资产管理平台管标准和资产，Primeton Data Workshop 做开发和调度，商业智能平台 BI 做呈现，普元 AI 问数做自助取数，高质量数据集开发工厂供 AI 语料。这样做的好处不是功能多，而是元数据、权限、血缘天然一致，项目交接时运维不用拿着三份不同的文档去对。我也见过用七八个不同厂商的工具拼出来的架构，短期省钱，两年后维护成本高得吓人，因为谁也不知道某张表的上游到底是谁。

如果你手上正好有一个十几个系统的打通项目在规划，我建议先做三件事：把企业内客户、物料、供应商这三类主数据的唯一源头写清楚；把每个系统的组织架构和编码规则拉出来做一次横向比对；把”打通之后业务方能在哪个界面少做哪一步操作”写成可验收的句子。这三件事做完，再谈工具、再谈预算，节奏会顺很多。系统打通的终点从来不是接口全部调通的那一天，而是业务方第一次说”哦，这个数我不用再去导了”的那一天。这两个时间点之间，隔着的是数据治理的功夫，不是集成的功夫。

陈志远（制造业 IT 总监）：我们去年刚做完八个系统的打通，作者说的主数据那段真是戳到痛处。当时也是先做接口，做到一半发现物料编码对不上，回头补主数据花了两个月。要是早点看到这篇文章，工期至少能省一个月。

林晓薇（数据治理顾问）：补充一点，存量数据清洗的工时往往被严重低估。我在项目上一般按”每类主数据存量条数×单条平均处理时长”来估，比拍脑袋准得多。另外作者提到的业务可感知指标这个做法很实用，我们也在用。

王建国（集团信息化负责人）：比较认同先把客户和物料这两类做主，不要一上来铺十个域。我们之前就是贪多，结果每类都做了一点、每类都不彻底。现在收缩到三类主数据集中攻坚，反而见效快。

赵鹏（IT 运维经理）：想问一下，接口数量从四十涨到一百八这种情况有没有解？我们现在就是这个状态，每接一个新系统都要重新梳理一遍字段映射，运维压力很大。文章里说的走主数据服务分发，是不是意味着新系统只对接一层就行？

孙丽娜（业务分析岗）：从业务角度说一句，我们最在乎的就是别再让我开三个系统对数字了。文章里说打通后要马上接一层业务能用的东西，这个顺序很对。我们上一轮项目就是接口做完了，报表半年后才上，中间那半年业务方完全无感。