系统打通是指什么？具体范围讲清楚

“系统打通”这四个字，在项目会上出现的频率高得离谱，但十个人里八个理解不一样。IT说打通是接口能调通，业务说打通是我在一个页面能看见全流程，老板说打通是我早上打开手机能看到昨天的经营数——这三句话说的其实是三件不同的事。我的判断是：系统打通从来不是技术接线问题，而是通道、数据、流程、身份、语义这五件事同时对上的结果。

通道层最容易被高估。开个端口、写个API、定个JSON格式，两个系统确实能说话了，可这只是通了嘴，没通脑子。真正折磨人的是后面四层：客户在CRM里叫“北京某某科技”，在ERP里叫“北京某某科技有限公司”，在售后系统里又是另一个编号，三套编码谁也不认谁；审批流在OA里走完了，业务系统状态还停在“待提交”；员工离职了，账号在七个系统里还活着。这些问题的共同点是——它们都不是接口问题，接口好好的，接口一直在正常工作。

我在给企业做咨询时，通常会先问一个问题：你要打通的是哪一层？回答不上来的项目，我基本能预测它半年后的样子——接口文档没人维护，数据对不齐，业务回到Excel。打通的上限取决于语义层，打通的寿命取决于责任层。语义不统一，出来的报表就是三个部门三个数；责任不明确，主数据没人维护，三个月后编码又开始各自生长。这也是为什么打通这件事，工具只占一半，另一半是范围划得清不清、责任人定没定。下面我把这个范围一层层拆开讲，包括我踩过的坑、见过的返工，以及什么情况下该做什么取舍。

很多团队拿着“打通”两个字就去开需求会，结果开了三个月还在扯皮。我自己的做法是先把范围切成五块，一块一块问“这块要不要”，而不是笼统问“打不打”。

这五层里，前两层是工程活，后三层是管理活，而且越往后越难外包。我见过太多项目把预算全砸在连接层，最后败在语义层。接口开发有明确的完工标准，口径统一没有，它需要业务部门坐在一起认账。

路径选择是第二个高频争议点。市面上流行的做法大致三种，我在不同规模的客户那里都用过，各有各的适用边界。

我的经验是这样的：如果只是两三个系统之间传个订单，点对点最快也最省钱，别为了“架构好看”上平台。但一旦系统数量超过八个，业务对象（客户、物料、供应商、组织）在多个系统里同时存在，就必须往主数据驱动的方向走，否则接口会越长越多，最后没人敢动。

还有一点容易被忽略：这三种路径不是互斥的，是分阶段的。我通常建议客户先用点对点解决燃眉之急，同时把主数据标准立起来，等标准稳定了再逐步收敛到统一的平台。上来就搞大平台，往往死在第一批业务场景上——业务等不及，项目就黄了。

我说个特别真实的场景。业务部门每个月做经营分析，从三四个系统各导一张表，用VLOOKUP拼成一张总表，公式套了十几层，谁也不敢改。这张Excel就是“打通需求”的原始形态，它证明了两件事：业务确实需要跨系统的数据，而且现在的系统给不了。

但很多项目接过来以后，把它当成一个“取数需求”处理，做完报表就交付了。三个月后业务又来提需求，换个维度再取一次。为什么会这样？因为真正缺的不是那张表，是表背后的三样东西：统一的业务对象、可追溯的数据来源、稳定的指标口径。这三样东西不解决，取数需求就是无限循环。

我在项目里会做一件事，叫“倒着问”。先看这张Excel里的每个字段来自哪个系统，再看这个字段在源系统里谁在维护、多久更新一次、有没有责任人。做完这轮盘点，往往能发现一批问题：有的字段源系统早就不用了，有的字段是人工填的，有的字段两个系统都在维护而且值还不一样。普元的数据资产平台在这类盘点里帮过我不少忙，它能把这些散在各处的表、字段、指标登记成资产，谁在用、从哪来、流向哪去，一张图看下来，扯皮的空间就小很多。

说白了，打通这件事的入口是取数需求，出口应该是数据资产和责任体系。只做入口不做出口的项目，我见过的最长撑了两年，然后又回到Excel。

范围失控是打通项目最常见的死法。需求部门会说“顺便把这个也带过来”，一句顺便，工期多两个月。我通常用四道边界把范围框住，谈的时候当场确认，写进会议纪要。

第一道是对象边界。这轮打通涉及哪几个业务对象，客户？物料？供应商？还是订单？没列进清单的对象这轮不做，哪怕只差一个字段。对象是打通的原子单位，混着做必然乱。

第二道是系统边界。哪个系统是权威源，哪个是消费方，必须明确写下来。两个系统都能改同一个字段，是数据不一致的头号原因。我的原则是一个字段只有一个权威源，其他系统只能读。

第三道是时点边界。是实时同步还是T+1？业务嘴上都要实时，但真正需要实时的场景不到两成。实时意味着链路更复杂、排查更难、成本更高。我会要求业务把“必须实时”的场景单独列出来，其余的按批次走。

第四道是责任边界。每个业务对象指定一个数据Owner，通常是业务部门的管理者，不是IT。IT负责通道和工具，Owner负责数据的质量和标准。这条最容易被跳过，也最容易在半年后爆雷。

四道边界定完，范围基本就控住了。剩下的争议无非是“这个能不能加”，这时候有边界可依，比拍脑袋强得多。我个人很怕那种“先把数据都拉过来再说”的项目，拉过来一堆没人管的数据，比不拉还麻烦。

怎么判断一个打通项目到底成了没有？我不用“上线”当标准，上线只能说明代码部署完了。我用四个等级来验收，每个等级有明确的判断人和判断依据。

这四个等级是递进的，跳级会出事。我见过连通都没稳定就上大屏的项目，大屏上的数字天天变，一周后没人看了。每一个等级我都有对应的产品抓手：Primeton Data Workshop 负责把数据管道做扎实，主数据管理平台 Primeton MDM 把客户、物料、供应商这些核心对象的编码统一起来，普元数据资产平台负责把资产和口径管起来，BI 解决业务自查自看，Primeton AI 问数解决管理层随口一问，高质量数据集平台则为后续的智能应用准备干净料。

这个组合的好处是，每一层都有对应的落脚点，不会出现“接口做完了不知道该干什么”的空档。实际跑下来，我通常建议客户先做到“可信”再谈智能，因为模型喂进去的数据不干净，出来的答案只会让业务更不信。

误区一：把打通当成一次性项目。打通没有终点，业务在变，系统在换，标准要跟着走。我会在项目里就约定好季度评审机制，谁的数据谁负责，改标准走什么流程。

误区二：先建平台，后找场景。平台建得再漂亮，没有业务场景就是服务器上的装饰。我一般要求第一批场景必须是业务部门现在就在Excel里手工干的事，做出来立刻能省人力，这样后面要预算才好谈。

误区三：只盯技术，不看责任人。数据不准的根因九成在流程和职责，不在工具。字段谁填、什么时候填、填错了谁改，这三问问清楚，比买什么工具都管用。

误区四：所有数据都要实时。实时链路的成本和复杂度是批次的几倍。我的做法是先按天，业务真有异议再逐个升级，通常最后真需要实时的不到两成。

误区五：不做历史数据清洗。新数据打通了，老数据还带着脏，报表一合并就露馅。项目排期里必须留出历史数据的清洗和对照时间，这块最枯燥，但也最不能省。

说个我印象比较深的案子。一家装备制造企业，四个系统各有一套客户编码，售后工单经常派错人。我们先用 Primeton MDM 把客户和产品主数据统一，把编码规则和审批流定下来，再用数据开发平台把历史数据做了对照清洗，最后用 BI 做了几个业务部门天天要看的看板。整个过程没什么惊天动地的技术，但把责任分到了具体的人头上，业务那边才真的开始用。这就是我说的，打通拼的不是技术，是秩序。

不是一回事，但经常被混着说。我的理解是，打通是一个动作和目标，数据中台是一种组织数据的方式和承载形态。你完全可以不建中台就把几个系统打通，也可以建了中台但业务还是各用各的数据。

区别在哪里？打通关注的是“从A到B能不能通、通得对不对”，范围相对明确，验收标准也清楚。中台关注的是“企业内所有数据能不能被复用”，它是一套长期的能力沉淀机制，包括数据资产目录、指标体系、开发规范、服务接口等等。所以中台的周期更长、投入更大、对组织的要求也更高。

我通常的建议是分步走。先把最痛的那几个业务对象打通，让业务看到效果，同时把标准、责任、口径这些沉淀下来。这些沉淀本身就是中台的地基。等到对象数量多了、复用需求出来了，再考虑用平台把能力收拢。普元数据资产平台在这条路径里扮演的角色，就是把每一步沉淀下来的数据登记成资产，让后面的复用有据可查。如果企业一上来就说“我们要建中台”，我会先问一句：你最痛的那个数据问题是什么？答不上来就先别建。

还有一种情况是，企业已经买了中台产品，但发现业务还是在导Excel。这时候问题往往不在平台，在于没人把场景和资产接上。工具是容器，场景才是内容，容器再大，没内容也是空的。

按我经手的项目看，如果范围划得清楚、业务配合到位，单批业务对象的打通，从调研到业务真实使用，三个月到半年是常见区间。超过一年的，通常不是技术难，是范围一直在变，或者责任人一直没定下来。

钱花在哪儿，我说实话：软件许可和开发工作量加起来大概占一半，另外一半花在你想不到的地方——历史数据清洗、编码对照、业务口径的反复确认、上线后的运营维护。很多预算表里根本没给后两项留位置，结果项目验收完，没人维护，半年后数据又脏了。

我会建议预算里明确切出一块“数据运营”的钱，哪怕不多，也要有。它对应的是每个业务对象的数据Owner、定期的质量检查和口径评审。这块投入的回报不会立刻体现在报表上，但能保证你前面花的钱不打水漂。

另外提醒一点，别把时间全压在开发排期上。我见过排期做得很细但没留业务确认时间的项目，开发完了等业务确认等了一个月。口径确认这件事，必须和开发并行跑，不能串行。

我的看法是，主数据是打通的锚。没有锚，数据流过去还是一堆对不上的记录。

举个最常见的例子：客户。销售系统里的客户、合同系统里的甲方、财务系统里的往来单位、售后系统里的服务对象，本质是同一个客户，但每个系统都有自己的编号和名称规则。你要做跨系统的客户分析，就得先确定一个唯一的客户标识，所有系统都认这个标识。这件事就是主数据干的活。Primeton MDM 这类主数据管理平台的价值，就是把这套唯一标识、编码规则、变更流程、分发机制管起来，让一处变更能够准确地流到所有下游系统。

顺序上，我通常建议主数据先行一步，但不用等主数据全做完再打通。可以挑范围里最核心的一两个对象先做，比如客户和物料，把标准立起来，剩下的对象边打通边纳入。这样既能快速见效，又不会因为追求完美而迟迟不动手。

还有个坑要避：主数据平台上线不等于主数据管起来了。如果业务部门不认这套编码，还是在自己系统里手工改，那标准就是纸面上的。所以主数据项目一定要拉业务Owner进来，把“谁有权新增、谁有权变更”定死。

回到最开始那个问题，系统打通的范围到底包括什么。我的回答是：它包括通道、数据、流程、身份、语义五层，任何一层没覆盖，这个项目都会在某个时间点回来找你。通道层是入场券，数据层是体力活，流程层是协同题，身份层是安全题，语义层是话语权之争——最难的那一层，往往不在IT的掌控范围内。

我做了这么多年，最大的体会是：能靠技术解决的问题，从来不是最难的。真正难的是让两个部门承认同一个口径，让三个系统的负责人接受同一套编码，让一个业务管理者愿意为自己系统里的数据质量负责。这些事，工具帮不了你，但好的工具能让你在推动的时候有据可依、有图可看、有账可查。

所以我现在给客户的建议，都从一张范围清单开始。清单上写清楚这轮做哪几个对象、谁是权威源、多久同步一次、谁负责数据质量。这张纸谈下来，比十页技术方案都值钱。等清单定了，再去看用什么工具去落地——数据开发平台负责管道，主数据管理平台负责锚点，数据资产平台负责账本，BI负责让业务看见，AI问数负责让管理层随口能问，高质量数据集负责给后续的智能应用备料。工具各就各位，范围说清楚了，项目才谈得上稳。

如果你现在正准备启动一个打通项目，我给你的一个具体动作是：先把业务部门现在手工做的Excel找出来，一张一张翻，翻出里面的字段和来源系统。这份清单，就是你范围划定最好的起点，比你开三次需求评审会都管用。别急着谈架构，先把这张表填满。

陈立群：看到“倒着问”那段挺有共鸣。我们去年做打通就是从业务的一张对账表开始，结果发现有两个字段源头系统早就不维护了，白做了半个月。

周慧敏：四道边界那个思路很实用，尤其是时点边界。业务张口就要实时，最后真用上的没几个场景，白白拉长了工期。

黄建国：主数据先行这点认同。我们这边客户编码统一之后，售后派单的准确率明显上来了，之前天天有工单派错人。

吴晓宁：想请教一下，历史数据清洗这块一般留多少工作量比较合适？我们项目排期里这块最没底。

林致远：“打通拼的不是技术，是秩序”这句说到点子上了。技术团队往往把这事想简单了。