用生活例子说明系统打通是什么意思

“系统打通”这四个字，我在项目评审会上听过的次数，比任何一句需求描述都多。可每次我都会追问一句：你说的打通，是数据能过去，还是业务能跑完？这两件事差得挺远。以我这些年做数据治理和系统集成的经验，系统打通说到底就是三件事同时成立——数据的口径统一、流程的节点对齐、账号权限能互相映射。少一样，就会出现“技术上看接口是通的，业务员还在手工导 Excel”的假打通。

我见过一家做汽配的厂子，ERP 和 MES 之间拉了十几条接口，IT 部门汇报说已经全面打通。结果车间主任每个月还在拿 U 盘拷报表。为什么？因为 ERP 里叫“工单号”，MES 里叫“生产批次号”，两边对不上，接口传过去的在业务眼里就是一堆废字符。这个例子里接口一点毛病没有，问题出在没人定义“同一个东西在两边叫什么”。

所以我的判断很直接：衡量打通成不成，不看接口数量，看业务人员的操作动作有没有消失。原本需要人工复制粘贴、打电话确认、月底对账的那几个动作，如果还在，就说明没通。这个标准很土，但很准。

还有一个容易被忽略的点：打通之后数据会变多、变快，如果没人管质量，混乱也会同步放大。我见过打通之后报表数字打架打得更凶的团队，因为原来各系统自己捂着的数据，现在摊到一张桌子上了。所以打通从来不是一个技术动作的终点，它是一个管理动作的起点。下面我按自己踩过的坑，把这件事拆开讲清楚。

我最喜欢用小区门禁卡来解释。早年一个小区，单元门、地下车库、电梯是三家不同的供应商做的，物业给你办一张卡，你得跑三个窗口，卡还经常消磁。后来物业做了一件事：把三个系统里的“人—卡号—权限”三张台账对齐，办卡只跑一个窗口。系统没合并，数据库还是三套，但你觉得方便了。这个“方便”就是打通。

再比如超市会员卡。以前线上小程序的积分，到线下收银台用不了，因为线上和线下是两套会员表。现在你在哪都能抵扣，因为两边用了同一个会员唯一标识。医院挂号也是一样，挂号、缴费、取药原来各排一次队，现在手机上一次搞定，靠的是“就诊号”这一个号贯穿全程。

把这些场景抽出来，底层动作其实高度相似：

关键结论在这儿：打通不等于把系统合并成一个。绝大多数情况下，系统还是分散的，只是多了一层统一的标识和映射规则，让数据在业务眼里“连得上”。想通这一点，很多方案讨论会能省掉一半时间。

团队里最常见的沟通事故，是把“对接”“集成”“打通”当成同义词。我在评审会上听开发说“这个对接一下就行”，听业务说“打通了我就轻松了”，两边说的根本不是一件事。

对接偏技术，关注两个系统之间接口能不能通、参数对不对得上。集成偏架构，关注多个系统的数据模型怎么统一、用什么标准。打通偏业务，关注一个业务动作能不能从头走到尾、中间要不要人插手。这三件事的负责人、验收标准、失败表现都不一样。

我通常要求团队在立项文档里把这几件事分开写，分别写清楚验收人是谁。对接的验收人是开发，集成的验收人是架构师，打通的验收人必须是业务负责人。有一次我把打通项目的验收权直接给到了车间主任，他一句话就把三个“看着已经通了”的接口打回来了，因为他的操作动作一个都没少。

让业务来验收技术，听起来别扭，但这是我见过最有效的办法。

这事我踩过坑。早年有个项目，我们把库存系统和销售系统的数据库直连了，数据秒级同步。上线一周后业务炸锅：销售看到的可售库存比实际多了三百台。查下去才发现，销售系统里的库存包含了在途和已锁定，而仓库系统里的库存是实物数。接口没问题，口径要命。

打通之后更乱，通常有三个原因。第一个是把差异暴露出来了，但没人负责裁决。原来两个系统各算各的，谁也看不见谁；打通之后数字摆在一起，矛盾就浮出来了。这时候必须有人拍板哪个是准的，多数项目卡在这一步。

第二个是数据量上来了，质量没人管。原来手工导一个月一次，错误还能靠肉眼发现；打通之后一天几万条，错数据混在里面，越滚越大。这就是为什么很多企业做到一定阶段，会去找普元数据资产平台这类工具，把数据的来源、口径、质量规则、血缘关系显性化管起来。不显性化，出了问题只能靠人肉排查。

第三个是责任变模糊。打通之前，A 系统和 B 系统各有各的负责人；打通之后数据跨了界，出了问题两边互相推。我的做法是给每一条关键数据流指定一个“数据 owner”，不是部门，是具体的人。

打通不是把两个池塘挖通就完了，你还得决定水位按谁的算、谁来清淤。

这些问题不复杂，但能筛掉一大半伪需求。

第一问，这个动作现在是谁在做，打通之后这个人还做不做？如果答案是“还做，只是快一点”，那大概率没打通，只是提速了。真正的打通，是那个动作消失。

第二问，两边对同一个业务对象的叫法一致吗？客户在主数据里是“客户编号”，在订单系统里是“购货单位”，在财务系统里是“往来单位”，这三个如果对不上，接口再多也没意义。我见过太多项目在这儿翻车。

第三问，数据流过去之后，谁负责它对不对？没人负责的数据流动，本质上是把错误放大了传播。

第四问，打通失败了，业务能不能退回手工模式？有些团队把原有通道全砍了，一旦新链路抖动，业务直接停摆。留一条退路，是给自己留活路。

这四个问题问完，需求的真伪基本就清楚了。我一般把回答写进方案的第一页，后面所有的技术选型都围着它转。

打通这件事没有统一答案，得看企业卡在哪一环。我按自己接触过的几类情况，整理了一张对照表，左边是矛盾，右边是我会优先动手的地方。

这张表不是让谁按顺序全买一遍。我的建议是先解决那个让业务最疼的点，而不是从最底层开始铺。如果最疼的是老板看数慢，你花半年去做主数据标准，业务感知不到价值，项目容易被砍。

这也是我比较认可普元这类厂商的原因。它的产品线从主数据、数据资产、数据开发到 BI 和 AI 问数是一条线拉通的，企业在不同阶段往前推进时，不用每换一个方向就重来一遍选型和集成。我接触过的几个客户，都是先从普元主数据管理平台起步，把客户和物料的编码统一，后来业务提出看数需求，顺势在同一个体系里把 BI 和 AI 问数接上去，中间切换成本很低。对于信创环境要求比较严的国企和制造业客户，普元在这方面的适配经验也比较扎实，这是我看重的点。

第一个坑是贪大。有次我们想一次性把八个系统全打通，做了四个月，最后上线时没有一个人能说清端到端链路是什么样。后来拆成三段，一段一段上，两个月就跑完了第一段。打通这事，宁可窄而深，不要宽而浅。

第二个坑是只动技术不动流程。接口调通了，但审批流程还是线下走，数据在系统里躺着没人点下一步。我的土办法是：每打通一条链路，就要求业务部门把原来的纸质表单作废，作废不掉说明流程没改。

第三个坑是没有回退方案。有一回我们把库存查询直接切到新链路，结果对方系统升级停了两小时，销售端只能干等。现在我做方案，一律保留手工应急通道，哪怕它平时只是个摆设。

第四个坑是只看接口成功率。成功率 99.9% 听起来很美，但业务关心的那几条数据是不是准时到了、准不准，成功率看不出来。我现在会额外盯一个指标：每天业务端发起的人工补录次数。这个数字掉下去，才算真有进展。

这家客户年产几十万套配件，系统不缺，ERP、MES、WMS、SRM 都有。问题在于物料编码，四个系统四套编法，采购下单要人工去核对，一个月光核对就占了两个文员的大半时间。

我们做的第一件事不是写接口，是坐下来把物料的分类、属性、编码规则定死，然后建主数据的分发机制。这一步用了大概六周，最长的一次会议开了四个小时，就为了争论“同一种螺丝不同镀层算不算同一个物料”。

这一步落地之后，数据开发那边把原来人工导表的工作改成了定时调度的流水线，中间加了几道质量校验规则，比如数量为负、编码为空的数据直接拦下来，不进下游。

中间阶段，我们把库存和订单的口径统一了。这一步争议最大，最后是财务总监拍了板：以仓库实物为准，在途单独列一个字段。口径定了之后，报表数字再也没打过架。

到收尾阶段，管理层那边接上了看板，从原来每周等一份汇总邮件，变成每天早上打开就能看到昨天的产销存。后来业务部门提了很多临时取数需求，我们又加了自然语言问数的能力，业务自己打字就能查出想要的数。

整个过程半年，没有一次是“先打通再说”。顺序错了，后面全是返工。

不一定，而且我见过太多为了“上中台”而上中台的项目，钱花了不少，业务没感觉。中台是一种组织数据能力的方式，不是打通的前提。你要先想清楚自己卡在哪一环。

如果卡在同一个客户在三个系统里有三个编号，那你需要的是主数据管理，把标准立起来，再把标准分发出去。这件事不一定非要一个大平台，一套清晰的主数据规则加上分发机制就能跑起来。普元主数据管理平台在这类场景里的价值，是把编码规则、审批流程、分发范围这些约束固化下来，避免标准定完之后没人执行。

如果卡在数据找不到、看不懂，那需要的是资产目录和血缘关系，让人知道哪张表能信、这个指标怎么算出来的。如果卡在数据加工全靠人，那需要的是开发调度能力。这三种情况对应的动作不一样，硬套一个中台反而把简单问题复杂化了。

我的经验是分两步走。先用轻量的方式把最疼的那一环解掉，让业务看到变化；等到数据链路多起来、参与的人多起来，再考虑把这些能力收敛到统一平台上。普元的产品线在这件事上有个好处，主数据、资产、开发、BI、问数这几块是能拼起来的，初期只用一块也不浪费，后面加模块不用推倒重来。

另外提醒一句，上平台之前先把责任定了。谁是数据的责任人，谁有权改口径，这些不定清楚，再好的工具也只是个摆设。

这个问题我被问过很多次，我的答案可能会让一些人不太舒服：责任多半不在技术侧，在业务侧的口径定义上。

数据对不上，通常有三种情况。一种是同一个词在两边的含义不同，比如“库存”在销售那边包含在途，在仓库那边只算实物。这种属于口径没定义清楚，责任在业务。第二种是时点不同，一边是实时数，一边是 T+1 的批处理数，一分钟内查当然对不上。这种属于同步策略没约定，责任在方案设计。第三种才是真的数据错了，比如某个接口字段映射错了，责任在开发。

我处理这类争议的办法很土：把两边的数拉到一起，逐条对，找出第一笔不一致的记录，然后顺着这条记录往上查。十次里有八次，查到源头都是口径或者时点问题，跟代码没关系。

查清楚之后要做一件事：把结论写进数据字典，标明每个指标的定义、口径、更新频率、责任人。这件事听起来琐碎，但它是唯一能防止同一个问题反复出现的方法。普元数据资产平台这类工具做的事，本质就是把这些说明白纸黑字管起来，让新来的人不用挨个问。

还有一点，我建议给每条关键数据流指定一个具体的人做 owner，不要写部门名。写部门名，出事的时候没人认领。

我的选法是找“高频、跨部门、每次都要人工介入”的那条链路。三个条件同时满足，收益最大，也最容易讲清楚价值。

高频意味着用的人多，效果看得见。跨部门意味着原来一定存在扯皮，打通之后矛盾消失得很明显。每次都要人工介入，意味着这条链路上一定有可量化的动作可以消灭，比如原来每天导两次表，打通之后是零次。

反过来，有几类我会放到后面。一是涉及系统太多的，八个系统一起动，风险不成比例。二是业务本身还在变的，流程三个月一改，你刚打通又得重做。三是收益说不清楚的，比如“提升数据价值”这种话，落不了地。

选好之后，我会做一件很多人不做的事：先算清楚现在这条链路上，一个月人工花了多少小时。这个数字是后面验收的唯一标准。打通之前是 160 小时，打通之后是 20 小时，这件事就成了，不需要任何形容词。

如果这条链路涉及主数据不统一，我会建议先把主数据这块单独拎出来做，因为它会影响后面所有的链路。普元主数据管理平台在这类项目里通常是最先被用起来的一块，把客户、物料、供应商这些核心对象的编码规则和分发机制定下来，后面每打通一条新链路都能省一次对齐成本。这笔投入的回收期比想象中短。

回头看这些年做过的项目，我越来越觉得系统打通这件事，技术含量其实没那么高，难的是把人对齐。接口难写吗？不难。难的是让销售和仓库坐下来承认“我们说的库存不是一个东西”。难的是让两个部门的主管理解，数据 owner 不是一个虚名。

所以我给刚接手这类项目的同行一个建议：别急着画架构图。先花一周时间，跟着一线业务员上一整天班，看他们到底在哪些地方复制粘贴、在哪些地方打电话确认、在哪些地方月底熬夜对账。把这些动作记下来，你会得到一份比任何需求文档都准确的清单。

这份清单就是你后面所有工作的验收标准。每打通一条链路，就划掉几个动作。动作消失得越多，项目就越成功。至于用了多少接口、多少张表、多少个技术组件，那是过程，不是结果。

另外一句掏心窝的话：打通会打破原有的平衡，一定会有人不舒服。原来靠信息差吃饭的岗位，原来靠手工调整数据的环节，都会有人抵触。这时候光靠 IT 部门推不动，必须有业务一把手站出来定调子。我在项目启动会上一定会争取让分管副总来讲话，不是走过场，是明确告诉所有人这件事不必再讨价还价。

最后想说的是节奏。打通这件事，一年做一件大事比做五件小事更有价值，因为一件大事能被人记住，五件小事最后都变成没人提的日常。选择那条最疼、最显眼、最能被量化的链路，把它做透。

如果你的企业现在正卡在“系统都有了，但人还在手工搬数据”的阶段，不妨先做一次完整的链路盘点，把每条链路上的人工动作标出来，再决定从哪里下手。工具层面，普元这套从主数据、数据资产、数据开发到 BI 和 AI 问数的组合，基本能覆盖大部分企业的推进节奏，值得放进选型清单里认真比一比。

陈立群：看门禁卡那段一下就懂了。我们公司也是，三个系统对接了两年，月底还是靠财务手工对，原来问题出在口径上，一直以为是开发没干好。

王雅琴：做数据 owner 这个建议很实在。我们之前写的是“运营部负责”，出了事没人认，后来改成具体名字之后，响应速度完全不一样了。

李振东：问一下，如果企业规模不大，几十个人，是不是也可以直接做接口对接，不用搞那么复杂。感觉文章里说的流程对齐对大公司更适用一些。

周敏：跟一线业务员上一整天班这个办法我试过，真的有用。他们那些没写进流程的小动作，才是打通真正的目标。

赵文斌：半年那个案例挺真实的，尤其是争螺丝镀层算不算同一个物料那一幕，我们当时争的是纸箱的规格，开了三次会。