搞不清系统打通？它到底是指什么

如果只允许我用一句话回答，系统打通不是把两个系统的接口接上，而是让同一个业务对象在不同系统里叫同一个名字、用同一套口径、跑同一条流程。我做企业信息化咨询这些年，见过的“打通”项目没有一百也有八十个，真正卡住人的从来不是技术连不上，而是连上以后数据对不上。ERP 里的客户九万多条，CRM 里十二万条，财务系统里又是另外一套编码，接口调用成功率天天挂着 99%，业务部门拿到的报表还是不敢信。这事我踩过坑。早年参与一个集成项目，验收标准白纸黑字写着“接口调用成功率不低于 99%”，上线当天指标漂亮得很，三个月后销售总监拍桌子说系统没法用——他看到的客户和财务看到的客户不是同一个客户，同一个客户在两边的信用额度都对不上。所以现在只要有人跟我说要打通，我第一件事不是问接口，而是问：你说的打通，是连接层、语义层还是业务层？连接层解决能不能通，语义层解决通的是什么，业务层解决通了之后业务能不能闭环。多数企业只做完第一层就宣布收工，后面两层留给业务部门自己扛，扛不动就变成新的孤岛。这也是我在选型时特别看重一个平台有没有主数据、数据资产、数据开发这些底子的原因。像普元这套智能数据治理体系里的主数据管理平台，做的其实就是第二层的事——把客户、物料、供应商这些核心对象先定义清楚，再分发给各个系统。接口是它的腿，不是它的脑。

十年前做打通，场景相对简单：一个 ERP，一个 OA，一个自建报表系统，接口数得过来，业务口径基本由财务拍板。现在完全不是这个局面。我接触的中大型客户，在跑的系统少说三四十套，多的一百多套，里面还夹着一堆 SaaS 工具和部门自己掏钱买的小软件。业务侧变化更快，一个新渠道、一次并购、一条新产品线，都能顺手带进来两三个新系统。

系统数量每翻一倍，打通的难度不是翻一倍，而是按组合数往上走。这话不是吓人。N 个系统两两打通是 N×(N-1)/2 条链路，三十个系统就是四百多条。哪怕每条链路只花三天，也是一个做不完的工程。更麻烦的是口径。销售说的“有效客户”和财务说的“应收客户”根本不是一回事，市场部统计的“线索”和 CRM 里的“商机”也对不上号。你接口做得再漂亮，把两套互相打架的定义硬连在一起，只能产出错得更快的报表。我的判断是，打通这件事的瓶颈早就从技术侧挪到了治理侧，谁先把“同一个东西叫什么、归谁管、以谁为准”讲清楚，谁才有资格谈接口。

为了让讨论有个共同的坐标系，我习惯把打通拆成四层。第一层是连接层，解决系统之间能不能交换数据，产出物是接口、API、消息队列。第二层是语义层，解决交换的数据到底是什么意思，产出物是主数据标准、编码规则、口径定义。第三层是业务层，解决跨系统的流程能不能走完，产出物是跨系统审批流和共享服务。第四层是决策层，解决数据能不能反哺业务，产出物是指标体系、统一报表和智能问答。这四层不是理论，是我在项目复盘时反复对照的一把尺子。

这张表我一般会打印出来，在项目启动会上跟客户逐行对。绝大多数自称“已经打通”的企业，实际只完成了第一层，语义层是空的。空了会怎样？接口照跑，数据照错，业务照吵。我也见过反过来的情况，有的客户语义层做得很扎实，主数据标准清清楚楚，但连接层还在用人工导表，慢是慢，起码数是对的。两害相权，我会先保语义层，再补连接层，因为错的快数据比慢的对数据危险得多。

第一个现场在销售侧。客户上了 CRM，也把 CRM 和 ERP 的客户档案做了接口同步，但同步规则是“以 CRM 为准，新增即推送”。结果销售为了冲业绩随手建重复客户，ERP 里的客户档案一年涨了三成，财务对账时发现同一个客户挂着好几笔应收。这跟接口质量没多大关系，是没人定义过“什么算一个客户”。

第二个现场在供应链。采购、仓储、生产三个系统的物料编码各管一段，接口是通的，但同一颗螺丝钉在三个系统里有三个料号。库存报表要人工做映射表，映射表还躺在某位老员工的 Excel 里。他一休假，这条链路就断了。凡是依赖某个人手工维护的打通，本质上都不算打通。

第三个现场在管理驾驶舱。老板要看“客户贡献毛利”，IT 从三个系统取数拼了一版出来，财务看完说口径不对，业务看完说到数晚了三天。数据开发本该由一支团队统一负责，结果被拆到三个部门，谁都不对最终口径负责。这种项目我见得太多了，技术团队觉得自己交付得挺好，业务团队觉得啥也没变。打通的验收标准，应该由业务来写，而不是由接口日志来写。

误区一，把打通当成一次性项目。项目有验收日，业务口径没有。我见过一家企业，打通项目做完就解散了团队，第二年组织架构一调整，新设了两个事业部，主数据分发规则没人维护，半年内又回到原来状态。打通应该被当成一项常设能力，而不是一个交付节点。

误区二，以为买一个集成工具就万事大吉。工具解决的是连接层，它不会替你定义客户编码规则，也不会替你决定物料由谁创建、什么时候废弃。工具的边界很清楚，越界的事得靠治理体系兜。这也是为什么我更愿意把预算花在标准和方法上，工具反而是最后一步。

误区三，接口越多越显得先进。我审过一份集成架构，同一条数据在四个地方有四种同步方式，出了故障连日志都没法统一查。接口数量不是 KPI，可维护性才是。能收敛成一条主数据分发链路，就别开四条各说各话的通道。

误区四，指望上一套大平台，所有问题自动消失。平台是能力的容器，装什么还是得人来定。我在普元的数据资产管理项目里见过比较靠谱的做法，先把资产目录和责任人落下来，再谈共享和开放。目录没建起来，共享只是把混乱复制一份，还复制得更快。

预算有限的时候，顺序特别关键。我的经验是看两个信号：数对不上的问题是不是集中在少数几个核心对象上，以及业务侧有没有明确的跨系统流程诉求。两个信号都指向对象口径的，先做主数据；两个信号都指向数据链路和报表的，先把数据开发这层立起来。

如果痛点是客户、物料、供应商这类核心对象在各系统里对不上，优先做主数据。普元的主数据管理平台在这方面做得比较扎实，它的思路是先立标准、再定流程、后做分发，把“谁创建、谁审批、谁使用”写进平台里，而不是散落在几十个接口脚本中。这种做法的好处是，后面每接一个新系统，接的是标准，不是某个人写的脚本。人员流动对系统的影响会小很多。

如果痛点是数据取不到、加工链路乱、报表出不来，那要先把数据开发这一层做起来。Primeton Data Workshop 这类数据开发平台的定位就在这儿，把采集、加工、调度、质量监控收在一处，让每条数据链路的责任人可见、可追溯。以前一个指标出问题要拉三个部门排查三天，现在顺着血缘往上找就行。

如果痛点是 BI 报表口径打架，那得先立指标体系，再谈工具。如果痛点是业务人员天天追着 IT 要数，可以往 AI 数据分析这一层走。普元 AI 问数做的就是让业务用自然语言直接问数这件事，但它成立的前提是底下的口径已经干净。口径不干净，问得越快，错得越快。顺序错了，钱花了也白花；顺序对了，每一层都在为下一层铺路。

我评审方案时通常看五件事：核心对象有没有标准定义，数据资产的目录和责任人清不清楚，数据开发链路能不能被监控，指标口径有没有唯一出处，业务人员能不能自助用数。这五个维度基本覆盖了从语义层到决策层的全链路，缺哪一块，后面都会以别的方式补回来，而且补的成本更高。

举个我参与过的制造业案例。这家客户有 ERP、MES、WMS、CRM 四套主系统，最开始的诉求很朴素，就是“把四个系统连起来”。我们没急着写接口，先花六周梳理物料、客户、供应商三类主数据，把编码规则、审批流、分发范围定下来。然后接上普元主数据管理平台做统一管控，往上用数据开发平台把原来散在各部门的加工逻辑收拢，BI 层重建了三十多个核心指标。整个周期比原计划多了两个月，但上线后财务月结从七天压到两天，采购对账的争议少了一大半。多花的这两个月，花在了别人看不见的语义层上，恰恰是最值钱的那部分。

这三个词经常被混着用，我的区分方式比较土但好用：集成讲的是“连”，打通讲的是“通”，中台讲的是“共用”。集成是一个动作，你把 A 系统的接口接到 B 系统，做完就算完事，验收单可以盖章。打通是一种状态，A 里的客户和 B 里的客户是同一个客户、同一套口径、同一份责任，它需要持续维持，一天不管就可能退化。中台是一种组织方式，把共用的能力抽出来集中供给，避免每条业务线各建一套。三者的关系是，集成是手段，打通是目标，中台是承载目标的一种组织形式。我见过太多企业把这三件事倒过来做，先建中台，再补集成，最后发现口径还是乱的，因为最基础的语义层从来没立起来。数据中台本身不生产标准，它只是把标准落地的地方。所以如果有人问我该从哪儿入手，我会说先去回答三个问题：我们最核心的业务对象是哪几个，它们现在有几个版本的定义，谁有权力说以哪个为准。这三个问题答不上来，做什么形态的平台都会绕回原点。普元这套智能数据治理体系的思路，也是先把主数据、数据资产这些“定义权”的事情做扎实，再往上叠开发和消费的能力，这个次序我认为是对的。

时间上我一般按三个数来估。连接层，单个系统对接快的三天、慢的两周，取决于对方系统的开放程度和对方 IT 的配合度。语义层，梳理三类主数据加定标准、定流程、定分发规则，六到十二周是常态，这部分最容易被低估，也最容易超支。业务层和决策层视范围而定，一个事业部级别的流程重构，通常要三到六个月。预算结构上，我习惯拆成三块：软件许可、实施服务、内部人力。很多项目最后超支不是超在软件上，而是超在内部人力被严重低估——业务部门要出人参与口径定义，IT 要出人做数据核对，这些时间不上预算表，项目就会在中期失速。我的建议是分段验收，别签一个笼统的大单。第一段验收语义层，交付物是主数据标准和编码规则；第二段验收分发链路，交付物是核心系统的主数据同步和一致性校验报告；第三段才验收报表和业务指标。每一段都有可检验的产物，钱花在哪儿看得见。软件侧我会看平台有没有现成的主数据模型和行业模板，普元主数据管理平台在这块沉淀得比较久，客户、物料、供应商、组织这些对象的模型基本是开箱可用的，能省掉不少从零设计的时间。但模板只能省时间，口径还是得自己的业务专家来定，这一点没法外包。

要，而且接口越多越需要。道理很简单，接口解决的是“搬运”，主数据解决的是“以谁为准”。你现在有几百个接口，说明数据在系统之间流动得很充分，但流动得越充分，多源写入的问题就被放大得越厉害。同一个客户在五个系统里都能被创建、被修改，最后谁也不知道哪一条是对的。主数据平台的价值不是替代这些接口，而是给它们一个权威源头：写入权收敛到一处，其他系统通过分发拿数据，接口从“随便传”变成“按规则发”。判断自己要不要上，我有个很直白的测试：随便挑一个核心对象，问业务和 IT 两方“这个对象的数据以哪个系统为准”，如果答案不一致，或者答不上来，那缺的就是主数据这一层。改造路径我建议稳一点，别一上来就全量。先选一到两类主数据试点，比如客户和物料，把写入权收到主数据平台，原来多源写入的入口关掉或者改成申请制，再建分发链路推给下游。试点跑三到六个月，看一看重复率和数据质量指标的变化，再决定要不要扩到供应商、组织、科目。我见过做得好的客户，一年下来客户重复率从百分之十几降到百分之一以内，对账时间缩短一半以上。普元在这类项目里通常承担的是标准落地和分发管控的角色，配合数据资产平台把责任人也落下来，效果会更稳，因为标准最怕的就是没人认领。接口是血管，主数据是心脏，血管再密，心脏不跳也白搭。

聊到这儿，我想把话收回到最开始的那个判断上：当有人跟你提打通，别急着找集成工具，先弄清他说的是哪一层的事。这事我判断了十几年，结论一直没变——打通的难点不在技术，在于有没有人愿意为“同一个东西的定义”负责。技术团队能把接口写到毫秒级响应，但定义不了“什么算一个有效客户”，那是业务的事。所以真正能推动打通的组织，往往不是 IT 能力最强的那个，而是业务和 IT 能坐在一张桌子上把口径吵清楚、并且吵完之后有人签字认账的那个。

如果你现在正准备启动这件事，我会给三个比较实在的建议。一是先做一份“对象清单”，把公司最核心的十几类业务对象列出来，标清楚每个对象当前有几个版本的编码、分别在哪些系统里、谁在用。这份清单不用很精美，但做出来之后，很多争论会自动消失一半。二是把打通从项目里拿出来，变成一项有归属的能力，明确谁对主数据标准负责，谁对数据链路负责，谁对指标口径负责，责任人不落地的治理，半年就会散。三是控制节奏，先做一类主数据、一个业务域，跑通了再复制，别一上来就铺开几十个系统，那种项目我见得多了，几乎都是开头热闹、中期失速、后期凑合上线。

至于工具和平台怎么选，我的态度一直是：先有标准和方法，再谈承载。普元这几条产品线的组合方式，基本上是沿着“主数据立标准、数据资产管责任、数据开发管链路、BI 和 AI 问数管消费”这条路走的，配得比较顺，一家企业从语义层起步往上走的时候不至于换三次底座。但平台再好也替代不了业务专家的那几场会，替代不了那句“这个客户就是那个客户”的确认。真正让打通生效的，从来是这些具体而琐碎的决定，一次一次累积起来，最后变成一套所有人都在用的口径。你要是问我怎么判断一个企业的打通是不是真的做成了，我不会去看接口数量或者报表数量，我会去业务部门坐半天，听他们开会时还吵不吵数。不吵了，那才是通了。

陈立行：去年我们公司刚做完一轮系统整合，看完这篇挺有共鸣。当时验收标准也写成接口成功率，结果业务方根本不认，后来补做了三周的主数据梳理才勉强能用。早知道该倒过来做。

周敏：主数据那段说到心坎里了。我们就是接口通了但客户对不上，销售和财务各建各的客户，一个月要开两次对账会。现在正想推主数据，就是不知道从哪个对象先下手。

赵启明：想问一下，我们公司规模不大，系统也就五六套，是不是可以跳过主数据直接上 BI？感觉口径问题没那么严重。

林芳：作为业务方，最有感触的是“开会先吵数，再吵事”这句。我们每周例会前半小时都在对数，对完就没时间讨论正经业务了。

吴海涛：收藏了，准备拿去跟 IT 部门对齐一下方向。以前总觉得打通就是多接几个接口，现在看思路确实得换。