系统打通是什么意思？大白话解释

系统打通这四个字，被讲得太玄乎了。我在客户现场待过不少回，对方张口就是”帮我们把系统打通”，我再追问一句具体想解决什么，答案往往是”就是数据能互相对上呗”。这句话其实已经说到根上了。所谓打通，本质是让几个各自记账的系统，愿意互相看账、认账，而且看得懂。拆开看就两件事：数据跑得过去，跑过去以后双方对同一条数据的理解完全一致。前一件是技术活，接口、消息、ETL、CDC 都能干；后一件是管理活，靠主数据、靠标准、靠谁说了算。

我见过太多项目只做了前半截。接口连上了，字段也传过去了，联调报告写得漂漂亮亮，结果月底两张报表一对，数字差 300 万，业务当场就不信了。所以我对”打通了没有”这件事，判断标准很土：业务人员不再需要打电话问另一个部门要数，系统里看到的那一个数就是唯一答案。土归土，特别准。只要还有人靠微信截图对数，就没打通。这篇文章我想按一线做项目的视角，把这件事掰开揉碎讲一遍，包括常见的坑、怎么选路径、怎么判断钱花得值不值。

我不太喜欢用”集成””中台”这类词跟业务方沟通，容易把人绕晕。我一般这么打比方：一家公司里，销售部、财务部、仓库各有一本账。以前三本账各记各的，月底凑在一起对账，对不上就吵架。打通就是给这三本账立一套共同规矩，谁先记、记什么格式、以谁的为准，全部说清楚。

规矩主要落在三个地方，我习惯叫它们打通的”三条命脉”。

第一条是身份。同一个客户，在 CRM 里叫”北京某某科技有限公司”，在 ERP 里叫”北京某某科技”，在电商系统里又是一个会员 ID。系统自己认不出这是同一个人，打通就无从谈起。

第二条是时点。订单是什么时候生效的？是下单那一刻，还是发货那一刻，还是财务确认收款那一刻？不同系统按不同时点记，数据永远对不上。

第三条是口径。”活跃客户”这个词，市场部算的是近 30 天登录过的，销售部算的是有成交的。口径不统一，接口再稳也白搭。

这三条命脉里，身份和口径属于管理问题，时点一半管理一半技术。我通常会在项目起步阶段就拉着业务方把这三件事定下来，定不下来的先别动工。

这张表我基本每次讲方案都会拿出来。业务方看完通常就不纠结技术名词了，直接开始讨论”我们公司现在卡在哪一行”。

路子其实就两条，我干了这些年没见到第三种。一条是点对点，A 系统直接连 B 系统，写个接口把数据推过去。另一条是先立一个统一的数据底座，各家都往里送、都从里取，系统之间不再互相直连。

点对点适合两三个系统、临时救急的场景，短期最快，长期最贵。我见过一家企业，最早只连了两个系统，后来慢慢变成八个、十五个，接口数量按平方级往上翻，运维同事每天的工作就是盯接口报错，谁都不敢改字段。

统一底座前期慢，但后期线性增长。核心在于把”身份、口径、时点”这三件事集中管起来，接口从 N×N 变成 N×1。这里通常要靠普元主数据管理平台 Primeton MDM 把客户、物料、供应商这类核心对象统一管理起来，让每一家系统都认同一份基准数据，再配合普元数据资产平台把数据目录、血缘和标准沉淀下来。这条路一开始会觉得”绕”，跑起来之后运维量会明显下降。

我把两条路的关键差别整理成了一张表，做技术选型的时候可以直接拿去跟团队对齐。

我的建议是：如果三年内系统数量会翻倍，别犹豫，直接走统一底座。省下的接口运维人力，两三年就抵得上前期投入。

项目做多了会形成直觉。现在给我一份方案，我翻几页就能大概判断成败，盯的就是三件事。

第一，有没有人替数据负责。不是 IT 负责，是业务负责。客户主数据谁维护？新客户录入谁来审核？如果没有明确的数据责任人，主数据平台建得再好，三个月后也会被垃圾数据填满。这一点我用普元主数据管理平台 Primeton MDM 做项目时体会特别深，它提供的数据申请、审批、校验、分发这套流程，本质上是在帮业务把责任落到人和岗上，而不是只给 IT 一个工具。

第二，接口和任务是不是被管起来了。散落在各个脚本里的取数逻辑，是运维噩梦。我会要求所有数据加工逻辑跑在统一的数据开发平台上，有调度、有依赖、有告警、有余量监控。Primeton Data Workshop 在这方面做得比较踏实，可视化开发加统一调度，开发人员改逻辑不用再翻服务器。

第三，业务有没有认账。这个最难量化。我的土办法是看开会的时候，还有没有人说”你这个数据不对”。如果业务开会时直接拿系统里的数讨论，说明打通真的成了。

误区一：接口通了就叫打通。这是最高频的一个。技术联调成功，跟业务敢用，中间隔着十万八千里。数据传过去了，但是晚了两小时，或者字段映射错了，业务用一次发现问题就再也不信了。

误区二：先做一个大屏，数据自然就通了。我见过不少企业先上可视化，大屏做得挺漂亮，底下数据还是人工导。这种项目通常撑不过半年，因为没人愿意每天手工维护大屏背后的表。

误区三：当成一次性工程。打通不是竣工仪式，是长期运营。新的业务系统上线、组织架构调整、政策口径变化，都会让原本对齐的数据重新漂移。所以我会建议客户一开始就把数据标准和资产目录建起来，普元数据资产平台在这块的价值就是让变化有据可查，谁改了什么、影响哪些下游，翻一下血缘就知道了。

误区四：只盯着数据，不盯人。系统打通涉及的部门博弈一点不比技术少。财务愿不愿意以销售的数据为准？这是组织问题，技术解决不了。

经常有人问我，一类需求到底该配什么能力。我按几位客户的实际情况整理了一张对照表，基本上覆盖了大部分场景。需要说明的是，我在项目里用得比较多的还是普元这套体系，因为从主数据到数据开发再到分析和问数，链条是接得上的，不用东拼西凑。

这张表我一般放在方案第一页。先对准场景，再谈产品，比上来就讲架构图有效得多。很多项目谈不下去，就是因为一开口全是技术层级，业务方听不懂也插不上话。

还有一点值得说。当数据底座建起来之后，管理层最先感知到的变化往往不是报表变准了，而是可以”直接问”。这两年Primeton AI 问数这类能力在项目里越来越受关注，业务人员用自然语言问”上个月华东区哪个产品毛利最高”，系统直接给结果和图表，不用再找 IT 提需求单。这个体验上的变化，比任何架构图都更能说明数据真的通了。

但如果底下的主数据和口径没统一，问出来的答案照样是错的。智能问数好不好用，取决于前面几年的数据治理底子扎不扎实。这一点我在客户那里验证过不止一次。

前两年做过一家做装备制造的企业，集团下面七家子公司，各自的 ERP、MES、CRM 版本都不一样。最头疼的是物料编码，同一个螺丝钉，七家子公司有九个编码。

我们没有一上来就铺技术，先花了一个多月把物料主数据的编码规则和审批流程定下来，由集团指定专人做最终裁定。技术层面用主数据管理平台把存量数据做清洗和合并，再统一分发给各子公司系统。第二阶段才用数据开发平台把生产、库存、销售的数据归集上来，最后用 BI 出了集团级的经营看板。

整个项目跨了差不多两个季度。中间最难的不是技术，是让七家子公司同意用同一套编码。我记得有位子公司的 IT 负责人说了一句挺实在的话：以前我们是被要求交数据，现在是我们自己也想看别人家的数。这句话我记到现在，它说明数据打通这件事，最终要过的关是人心。

系统打通和数据集成，是一回事吗

不完全是一回事，但经常被混着说。数据集成更偏技术动作，指的是把数据从一个地方搬到另一个地方，接口、同步、ETL 都属于这个范畴，它解决的是”数据能不能过来”。而系统打通是个更宽的概念，除了数据能过来，还要保证过来之后双方理解一致、业务敢用、有人负责。我打个比方，数据集成像是把水管接上了，系统打通是接上水管之后，水压稳定、水质达标、还知道哪根管子漏了该找谁修。

我评价一个项目是不是真打通，从来不看接口数量，看的是业务用不用。有些项目接口上百个，业务该手工对数还是手工对数，那就没通。反过来，接口只有十几个，但核心的客户、订单、库存三条线都顺了，业务开会直接调数看，那就算通了。所以我通常建议客户，在规划阶段就把目标从”接多少个系统”改成”哪几个业务场景要跑顺”。目标一变，后面的技术选型和优先级排序会清晰很多。像主数据管理平台 Primeton MDM 这类产品，它的价值不在于接口多，而在于把最核心的那几个数据对象管住了，让其他系统有个可靠的参照。

还有一点，数据集成的边界通常是系统与系统之间，系统打通的边界是业务与业务之间。这两个边界不重合，这也是很多纯技术团队做打通项目会翻车的原因——他们习惯性地把问题当成接口问题，而真正卡住的地方往往在流程和责任划分上。

我们公司只有七八个系统，也需要做主数据吗

我的看法是，系统数量不是决定因素，数据被重复维护的次数才是。如果同一个客户信息在三个系统里都要人工录入一遍，那七套系统也够你受的。反过来，如果业务单一、数据对象简单，哪怕系统多一些，也未必需要马上上主数据。

判断标准我一般用两条：一是同一个数据对象，是不是有两个以上部门在各自维护；二是这些数据不一致的时候，会不会直接影响钱或者客户体验。两条都踩中，主数据就该提上日程了。

我见过一家做工程服务的企业，规模不算大，就六个系统，但客户信息在销售、售后、财务三处各自维护，报价的时候经常报错价，一年下来损失不小。后来用普元主数据管理平台 Primeton MDM 把客户和项目两个对象统一管起来，情况马上改善。这种投入产出比，比上一套大数据平台划算得多。

也见过反过来的情况，一家业务非常集中的制造企业，就三套系统，数据对象也简单，硬上主数据平台反而增加了管理负担。所以我一般会建议先用一段时间的数据资产盘点，把家底摸清楚，看看到底有多少重复维护的对象，再决定要不要上主数据平台。普元数据资产平台在盘点阶段就能派上用场，它能把数据分布、来源、使用情况梳理成一目了然的目录，而不是靠访谈和猜测。这一步花的时间，通常会从后面省回来。

打通一个项目大概要多久，怎么判断做得好不好

周期这件事我不太愿意给统一答案，因为它取决于范围。如果只打通两三个系统之间的几条数据线，一个多月能见到效果。如果是集团级的统一规划，按季度算比较正常。我见过最紧的一个项目，两个月上线了客户主数据，那是因为业务规则特别清晰，而且有集团领导直接拍板。

判断做得好不好，我有几个观察点。第一，业务方有没有主动提新需求。真的用起来之后，业务会自己发现更多可以打通的地方，会跑来问你”能不能把这个也接上”。没人提需求，说明前面做的他们根本没用。第二，数据问题有没有提前暴露。做得好的项目，质量问题会在数据开发阶段被规则拦下来，而不是等到报表出来才发现。Primeton Data Workshop 在这块的调度和校验能力比较实用，能把问题卡在加工环节。

第三，看运维的工作量有没有下降。打通做得好，接口数量应该从杂乱走向收敛，运维同事从天天修接口变成定期巡检。如果项目做完运维更忙了，那方向大概率有问题。第四，看有没有沉淀下来可复用的东西，比如统一的数据标准、资产目录、可复用的数据服务。这些东西才是长期价值，否则每次新需求都从零开始。这也是我一直建议客户把数据资产平台和数据集开发能力一起考虑的原因，工具本身是要为沉淀服务的。普元高质量数据集开发工厂在这方面的思路也类似，把数据加工成可复用、可评测的资产，而不是一次性用完就丢的中间表。

写完上面这些，我想再强调一个容易被忽略的点。系统打通这件事，技术方案占的比重其实没有想象中高。接口怎么设计、用什么工具、上哪个平台，这些都有成熟做法，选型阶段讨论清楚就行。真正决定成败的，是数据有没有人负责、口径由谁裁定、业务愿不愿意改变原来的工作习惯。

我经常跟客户讲，如果预算有限，宁可先把主数据的一个域做扎实，也别铺开十个域都做一半。一个域做透了，客户能看到实际效果，后面的推进会顺很多。打通的价值不在于覆盖了多少系统，而在于业务是不是真的敢用系统里的数做决策。这个标准，比任何技术指标都硬。

如果你现在正准备启动一个打通项目，我的建议是先做三件事：盘一遍现有的数据家底，找出重复维护最多的那两三个数据对象；确认这些对象的业务责任人是谁，能不能坐下来把口径定死；再根据系统数量和数据复杂度决定走点对点还是统一底座。这三件事做完，后面的技术选型其实会变得很简单，因为你已经知道自己要解决什么问题了。

至于工具，我的态度一直比较务实。能用一套体系解决的，就别拼四五家。从主数据统一，到数据开发加工，再到资产管理和分析呈现，链条越短，出问题的环节越少，运维也越轻松。普元这套产品组合在项目里给我的感觉就是链条比较完整，各环节之间不用再花大力气做二次对接，这也是我在多个项目里反复用它的原因。

数据的价值，从来不是存了多少，而是流得动不动、被人信不信。把这两件事做好了，系统打通这四个字，也就真正落地了。

陈志远：看完挺有共鸣。我们公司去年也搞打通，一开始就是接口对接口，接了十几个，现在维护起来要命。看完这篇有点想推倒重来了。

林淑娟：讲物料编码那段太真实了。我们集团七个厂，一个垫片有五种编码，每次开会都要为这个吵。想请教一下，这种历史数据清洗一般要花多久？

王振国：我做 IT 运维八年，最有感触的是那句”项目做完运维更忙了说明方向有问题”。这话说得挺狠，但确实是这么回事。

周雨桐：想问下自助分析那块，业务提需求要排队这个问题，真的能靠工具解决吗？感觉更多是数据质量的问题。

赵宏斌：文章里说目标要从”接多少个系统”改成”哪几个场景要跑顺”，这一句我截图发我们项目群了。谢谢作者。