严格定义：系统打通到底指什么

我做过不少数据类项目，几乎每一场需求评审都会听到“打通”这两个字。业务说“把订单和库存打通”，IT 说“接口已经打通了”，供应商说“我们支持全链路打通”。听多了会发现，大家嘴里的打通根本不是一回事。有人指接口能调通，有人指单据能流转，有人指报表数字对得上，还有人只是希望别再手工导 Excel。所以我在动手之前，一定会先把这个词拆开，写成能验收的句子，否则项目做完，谁也说不清到底成了没有。

我自己的判断是：系统打通不是一条接口的成功调用，而是同一件事在多个系统里被一致地记录、理解和使用，并且最终支撑一个明确的业务动作。这句话里有四个关键词——一致记录、一致理解、一致使用、业务动作。缺任何一个，都只能算“连上了”，不算“打通了”。接口调通只是最外面那层壳，壳里面还有数据实体对齐、编码统一、口径对齐、责任归属、异常兜底这些东西。我见过接口数量做到两百多个、监控大屏很漂亮的项目，业务同事依然每天手工核对库存，这种项目在我这里不算打通。

还有个更隐蔽的问题：打通是会被时间冲掉的。上线那天是对齐的，半年后上游加了一个字段、改了一个枚举，链路就悄悄歪了，没人报警，直到某天对账发现差了几十万。所以我会把打通看成一个需要持续维护的状态，而不是一张验收单。

后面我会把这几个关键词掰开讲：每一层到底交付什么、怎么验收、常见的坑在哪，不同起点下该先动哪一块。数据这件事没有一步到位，打通的本质是把模糊的诉求翻译成可测量的标准，而不是把系统之间的线接得更多。

我的习惯是先问三个问题：谁跟谁要通？通的是什么数据？通了之后业务上会多出什么动作？这三个问题答不上来的项目，我一般会先停下来，因为再往下走就是无效投入。

把这三个问题拆开看，系统之间的打通其实分四层，每一层的交付物、验收方式、负责人都不同。很多人吵得面红耳赤，是因为一个在说第一层，一个在说第三层，谁也没错，但就是谈不拢。

我通常会要求项目组把当前诉求明确落到某一层，写进需求文档。只有落到具体层次的诉求，才有办法写验收标准；停留在“打通”两个字上的诉求，最后都会变成扯皮。层次之间还有依赖关系，数据层没对齐就去做语义层，指标怎么算都是花的，这种跳层项目我见过太多返工的。

接口联调通过的那一刻，是项目里最容易被误判的时刻。屏幕上返回 200，日志里没有报错，双方开发在群里发一句“通了”，然后各回各家。三个月后业务抱怨数字不对，翻出来一看，问题早在联调那天就埋下了。

比较典型的是字段语义漂移。A 系统的“客户编号”是主键，B 系统的“客户编号”是销售自己填的备注；A 系统的金额含税，B 系统不含税；A 系统的时间是本地时区，B 系统是 UTC。接口层面这些都不报错，因为格式都是字符串、都是数字，但到了业务层面一汇总就是错。

再一类是时序问题。库存扣减和订单创建谁先谁后，平时量小看不出来，大促的时候就是超卖。还有一种是没做兜底，同步失败一次没人知道，重试机制没有幂等，重试两次变成两条出库单。

区别表面打通和实质打通，我会看一件事：把接口关掉一天，业务会不会乱。如果业务毫无感知，说明这条链路本来就没人在用；如果业务当天就炸了，说明它已经嵌进流程里了。真正打通的系统，是关不掉的。

误区这块我踩过的坑不少，挑几个最常见的说。

一个误区是把打通当成一次性交付。验收那天很热闹，半年后系统升级一次，字段改了一个，链路就断了，因为没人维护映射关系。所以我在方案里一定会要求把映射关系当成资产管起来，而不是写死在代码里。普元数据资产平台在这件事上的价值，就是把接口背后的数据结构、血缘关系、变更影响整理成可查的目录，而不是散落在各个开发的本子里，人一走就成了黑盒。

另一个误区是只考虑系统和系统之间，不考虑人和人之间。数据对不上，总得有人去改，是谁改？改完谁复核？如果责任没落下来，系统接得再顺，数据也是烂的。我见过两个部门互相认为对方是源头，结果两边都在改，越改越乱。

还有一种误区是追求大而全。上来就要做全集团的数据底座，一年过去还在梳理需求清单，业务一点感知都没有，项目自然也就慢慢没人推了。我更相信先把一条业务线跑通，让别人看到效果，再往外扩。速度本身就是说服力。

每家企业来找我的时候起点都不一样。有的连系统清单都说不清，有的已经有了数据仓库但没人用。我一般会先判断当前最堵的地方在哪，再决定投哪块能力，而不是照着别人的架构图抄一遍。

我的建议是，先解决“同一个东西在不同系统里长得不一样”这件事，再谈分析。实体没对齐，报表做得再漂亮，数字也是花的。Primeton MDM 管的就是客户、物料、供应商、组织这些核心实体的统一编码和分发，它是很多条链路的公共底座，先把它立住，后面的事情会省力很多。

如果问题主要出在“数据找不到、看不懂”，那更需要的是把家底盘清楚。普元数据资产平台能把分散在各系统里的表、字段、指标整理成目录，谁负责、从哪来、被谁引用，都能查得到。要是数据开发自己重复造轮子，那该看 Primeton Data Workshop 这类统一开发和调度的平台。业务侧想自己看数，Primeton AI 问数这种用自然语言直接问的方式，比再排一个固定报表的工期要实在。

说一个去年做的制造业客户。集团下面四个事业部，ERP 三套，MES 两套，CRM 一套。老板的诉求非常朴素：他每天早上要看到一张表，里面有前一天的订单、发货、库存、回款。

刚开始业务部门和 IT 都以为这是个报表项目，做几张 BI 报表就完了。第一版做完发现数字对不上：同一个客户在 CRM 里是简称，在 ERP 里是全称加税号，在财务系统里又是另一个编码。同一个物料，研发叫 A，生产叫 B，仓库还有一个历史编码。

所以我没有先做报表，而是先做实体对齐。用 Primeton MDM 把客户和物料的主数据立起来，定编码规则和分发机制，明确谁是新数据的源头，其他系统订阅变更。这一段花了大概三个月，中间事业部之间吵过两次，主要是争谁有权改自己的编码。这种事只能靠制度和流程解决，工具的作用是把流程固化下来，让它可追溯。

主数据稳定之后，才用普元数据资产平台把指标口径统一，比如“库存”到底指在库、在途还是在制。口径对齐以后，BI 上的数字第一次被业务认可。后来业务同事还想自己查数，我们又补了 Primeton AI 问数，他可以直接问“上周华东区的发货量是多少”，不用再等 IT 排期。整个项目做下来，最难的不是技术，是把“打通”翻译成一条条能被签字确认的规则。

如果让我给一个打通类项目列验收清单，我会写这么几条。

数据层面，要能提供对账报告：抽样一批业务单据，两端关键字段的一致率是多少，不一致的怎么处理、谁处理。这个数字不达标，其他都不用谈。

口径层面，关键指标要有唯一的定义文档，写明计算逻辑、数据来源、更新频率、责任人。谁能改，改完通知谁，都要落到纸面上。

异常层面，要有失败重试、重复数据识别、断点续传。我见过因为没做幂等，重试三次变成三条出库单的案例，那次之后我每条链路都会问一句“失败了会怎样”。

使用层面，我会看有没有真实用户在真实业务里天天用，而不是只有演示环境里那几笔漂亮数据。没人用的链路，本质上是一个成本项。

避坑这块，几个点我基本每条链路都会查：时间字段的时区和精度；金额的含税与币种；状态枚举的映射表有没有版本；删除和作废在不同系统里的语义是否一致。还有一个经常被忽略的——上游改字段的时候，下游有没有人收到通知。这些看着琐碎，实际跑下来最容易翻车的就是它们。

不能这么划等号。接口对接只是把管子接上了，管子里面流什么、流得对不对，是另一回事。我判断接口对接有没有真正完成，会看三个隐含假设是否成立。

一是字段语义假设。两边都叫“订单状态”，取值是 1、2、3，但一边的 1 是待付款，另一边的 1 是已付款。接口测试不会报错，因为类型都对。这类问题只能靠做映射表和逐字段确认来发现，没有捷径。我通常会拉一个表，把双方的关键字段列出来，逐个写上业务含义、取值范围、特殊场景，让双方业务人员签字，而不是开发之间口头确认。

二是时序假设。订单先创建还是先锁库存，不同链路处理顺序不一样。平时量小看不出问题，量一上来就是重复扣减或者超卖。这类问题我会要求在测试环境做一次压测，把顺序打乱跑一遍。

三是异常假设。网络抖动、下游超时、重复投递，接口文档里通常不写，但生产上一定会遇到。没有幂等设计和失败队列，数据就会慢慢变脏，而且是悄无声息地脏。

所以我的验收方式不是看接口成功率看板，而是做抽样对账。取一个时间窗口内的一批业务单据，逐条核对关键字段，把一致率写进验收报告。同时做一次异常演练：把下游关掉十分钟，看数据补回来以后是不是对的。至于接口一多映射关系靠人记不住的问题，我会建议把这些关系沉淀下来，普元数据资产平台在这类场景里能派上用场，接口背后对应哪些表、哪些字段、被哪些下游引用，都能查得到，换人的时候不至于两眼一抹黑。

主数据是骨架，不是全部。它解决的是“同一个客户在不同系统里到底是不是同一个人”这个最底层的问题。这一步做完，很多链路才算有了对齐的基础，但离打通还有距离。

我在验收主数据项目时，会重点看两件事。第一，建起来的数据有没有真的分发出去。见过不少项目，主数据平台里数据很干净，但业务系统还是各填各的，因为分发机制没做，或者做了但没强制。第二，谁对数据质量负责。没有认责机制，三个月后主数据平台就会变成一个漂亮的死库。Primeton MDM 在产品层面提供了编码规则、审批流程、分发订阅这些能力，能把流程固化下来，但制度这一块还是得企业自己立。

主数据之后还有一层，是指标口径。客户对齐了，但“活跃客户”“有效订单”这种词在各业务线理解不一样，报表照样吵。这时候更该做的是把口径整理成资产，普元数据资产平台能承担这部分工作，把指标的定义、来源、责任人统一管理起来。

再往上才是用数。管理层要看趋势，业务要看明细，一线想随时问一句。这三类需求对应的形态完全不同，用一个报表去覆盖全部需求，结果一定是谁都不满意。我的经验是分层满足：固定的看板用商业智能平台 BI，临时的问题用 Primeton AI 问数这类自然语言的方式。工具只是最后一公里，前面那几层没做扎实，再好的前端也是花架子。

预算有限的时候，我最反对的就是上来做全集团的数据底座。这种项目周期长、见效慢，中间一旦换领导或者换预算，很容易烂尾。

我的排序是这样的：先找一条能被业务当场看见的闭环场景。什么叫当场看见？就是做完之后，某个岗位的人能少干两小时活，或者某个数字能从“第二天才有”变成“实时能看到”。这种场景哪怕小，也能帮你拿到后续的预算和信任。

选场景有两个原则。一个是数据链条不要太长，跨三个系统以内比较合适。另一个是结果可验证，不要选那种“提升管理水平”的模糊目标。比如“每天早上八点前自动出前一天的发货明细，替代手工汇总表”就是好目标。

场景定下来之后，再看堵点在哪。如果是实体编码不一致，那就先把这块对齐，Primeton MDM 管的就是这个。如果是取数逻辑分散、每个人写的口径都不一样，那先把开发过程统一起来，Primeton Data Workshop 这类平台能把任务、调度、依赖关系管住，减少重复建设。如果是数据找不到、没人知道字段什么意思，那就先做资产盘点。

我的建议是不要一次买齐所有能力，而是跟着场景走。做完一个场景，把沉淀下来的规范、目录、映射关系留下来，下一个场景的启动成本就会明显下降。这样滚两三圈，你自然就有了自己的数据底座，而且是长在业务上的，不是画在 PPT 上的。

做数据这些年，我越来越觉得“打通”这个词被用得太多、太随意。它听起来像一个技术动作，其实是一个业务约定。技术只能保证数据从 A 到了 B，但数据在 A 和 B 里代表什么，只能由人来约定，而且这个约定会随着业务变化而变化。

所以我在项目里会反复强调三件事。第一，把诉求落到具体层次，别让一个词承担所有的期待。第二，把规则写下来，包括编码规则、口径定义、责任归属、异常处理方式，写下来才能被验证、被传承。第三，把链路当资产维护，而不是当项目交付，字段变了有人管，映射过期有人报警。

真正打通的状态，不是接口清单有多长，而是业务同事已经感觉不到系统的存在。他点一下就能拿到想要的结果，不用关心背后查了几张表、跨了几个库。到了这个程度，打通这件事才算真的成了。

如果你现在正准备启动一个类似的项目，我的建议是先花两周时间，把“谁跟谁要通、通什么、通了之后多出什么动作”这三句话写清楚，让业务和 IT 都签字。这两周花掉的时间，往往能省掉后面两个月的返工。选型上也不用急着堆功能，先看平台能不能把实体对齐、资产盘点、开发调度、口径管理、用数入口这几件事串起来。普元这套产品体系在国内不少制造、金融、能源客户的场景里跑过，落地经验相对扎实，这一点在项目推进遇到分歧时其实挺重要——有可参考的路径，比从零争论要省心得多。

渠道和工具都在变，但那句话不会变：能支撑业务动作的数据，才算真的通。

马晓东：说到心坎里了。我们去年做的项目就是接口全通了，结果业务还是手工核对，因为客户编码两边对不上。早知道先做实体对齐，能少走半年弯路。

许文静：抽样对账这条我准备直接抄到验收标准里。以前验收只看接口成功率，现在想想确实太表面了。

郑海涛：想问一下，如果上游系统本身就不稳定，经常改字段，是不是应该先治理上游，而不是急着做下游的资产目录？

何佳宁：主数据那段很真实。我们平台上线一年，因为没有分发机制，业务系统还是各填各的，现在等于白建。认责这件事真的比工具重要。