系统打通的10个认知误区，很多人第一个就错了

我做过十几年企业数据类项目，经手的系统打通需求少说也有七八十个。真正让我记住的，不是哪套技术架构多先进，而是那些花了小几百万、接口接了三四百个，业务部门开会还是拍桌子说“你们这数据不对”的项目。复盘下来，问题几乎都不在接口开发本身，而是出在最初那几个判断上。有人立项时就把打通理解成“把接口连起来”，有人默认主数据建一次就能用十年，还有人觉得这是IT部门自己扛的活，业务不用深度参与。系统打通的成败，七成在认知，三成在技术。认知对了，工具选型、实施节奏、组织分工都还能商量；认知错了，再贵的平台也只是把错误放大一遍。下面这10个误区，是我在不同行业、不同规模企业里反复见到的，按踩坑频次排了序，第一个我敢说至少一半团队正在中招。

过去五年我跑过的企业里，ERP、CRM、MES、SRM、WMS、OA这些系统几乎没有一家是少的。中型制造企业七八套，集团型企业二三十套很常见。

三年前大家关心的是接口能不能通、报表能不能出。现在业务方张嘴就是“这个客户的销售额在两个系统里为什么不一样”。需求的重心已经从连接层下沉到了数据和语义层。

这个变化直接决定了打通的抓手。下面这张表是我通常用来跟客户对齐认知的，把前后的差别摊开看会清楚很多。

这张表我一般会在启动会上直接投出来。它不是为了讲道理，而是让业务方和IT方在同一个坐标系里说话。实际跑下来，凡是启动阶段就没对齐这几行的项目，后面返工的概率高得离谱。

我见过最典型的一个场景：一家零售企业，集成平台上线两年，接口数量从60个涨到400多个，IT汇报时说打通率90%以上。结果财务和电商两个部门对同一场促销的GMV，差了将近三成。

问题出在哪？接口解决的是“传得过去”，系统打通解决的是“算得一样”。前者是管道问题，后者是语义问题。

这两件事的目标、抓手和衡量方式完全不同，我在下面这张表里做了对照，你也可以拿它去对照自己手上的项目。

看这张表就明白，为什么很多企业接口越接越多，业务却越来越不信任数据。管道的活可以外包、可以自动化，语义的活必须有人对业务规则负责。

这也是为什么普元主数据管理平台 Primeton MDM这类工具会被放到打通项目的核心位置。它管的不是传不传得过去，而是同一个客户、同一个物料在所有系统里是不是同一个东西。

我把这些年见到的误区归了归，认知层面的有五个，共同点是它们在项目还没开始写代码的时候就已经发生了。

太多人把打通写进立项书，定好上线日期，验收完就撤人。可主数据的维护、口径的修订、新系统的接入，哪一件都不是一锤子买卖。我见过一家企业，项目验收后三个月新并购了一家公司，客户主数据直接乱了套。打通更像一种运营机制，不是一个交付物。

我通常会问客户一句：你打算先把哪三条数据流打通？答不上来的，往往就是什么都想连。系统是连了几十个，但核心的客户、物料、组织三套主数据还是各说各话。打通的深度从来不是用接入数量衡量的。

编码只是结果。真正难的是谁有权新增、谁负责审批、变更之后怎么分发到下游。我见过主数据表建得漂漂亮亮，但没人愿意当数据Owner，三个月后表里全是脏数据。主数据的难点在治理机制，不在表结构。

同步是搬运，打通是统一。把一个字段从A系统搬到B系统，字段名一样、值一样，但如果两边对“生效日期”的定义不同，搬到哪儿都是错的。我一般会要求团队先把口径文档写出来，再谈技术同步。

这一条是我最想强调的。业务不参与口径定义，IT只能靠猜。猜出来的规则上线后一定被推翻。打通的规则必须由业务签字，IT负责实现，这个分工不能反。

如果说认知偏差决定方向，那下面这五个坑决定的是进度和成本。这些坑我几乎每个项目都会遇到一两个。

字段映射表做得很细，但没人管手机号是不是11位、客户名称有没有重复。数据传过来了，质量却没跟上。我参与的一个项目里，客户主数据重复率一度超过18%，报表上的客户数虚高了一大截。质量规则得和映射同步设计。

打通解决的是“同一份事实”，报表准不准还取决于指标定义。销售额含不含税、退换货算不算、跨期订单怎么归，这些不定义清楚，数据再统一报表也对不上。指标口径要单独治理，它不会自动跟着打通一起完成。

老系统改了要重新测试，厂商要收人天，业务不能停机。我一般会建议先做旁路方案：权威数据先在新平台上跑，老系统按原样运行，通过分发机制逐步对齐，别一上来就要求全部改造。

我见过一份打通清单列了2000多个字段，做到一半团队就崩了。真实情况是，八成业务价值集中在两成核心数据上。先把客户、物料、供应商、组织机构这几类主数据做扎实，收益远比铺开面大。

数据一致性不会自己保持。新系统接入、字段改版、业务规则调整，都会让之前的努力慢慢失效。我通常会要求上一套数据质量监控看板，把一致率、及时率做成指标盯着，出了问题当天能发现。

经常有人问我：打通到底应该先做什么？我的回答从来不是一套固定方案，而是先看三个条件——数据复杂度、业务紧迫度、组织成熟度。

单点业务、系统不到十套的中型企业，我一般建议从客户和物料主数据入手，先把最痛的两类数据统一，见效快、阻力小。系统超过二十套、跨多个法人主体的集团型企业，就要配套数据资产盘点，不然连自己有哪些数据都说不清。

下面这张表是我给客户做方案时常用的一张能力对照，按数据治理的环节拆开看，比笼统谈“上一个中台”要实在得多。

这张表的价值在于，它把“打通”从一句口号拆成了可以逐项验收的能力。普元这条产品线的好处是各环节能接得上，主数据做完可以直接进资产目录，开发完的数据能进BI，也能喂给AI问数和数据集工厂，中间不用再拼第三方组件。对预算有限的企业，完全可以先选其中一两项启动。

去年我跟进过一家做工程机械的中型企业，年营收十几亿，系统八套，ERP、PLM、CRM、SRM各一套，还有自研的服务系统。

他们最初的诉求是“把CRM和ERP的客户数据对上”。我进去聊了两轮，发现问题比预想的大：同一个客户在CRM里叫全称，在ERP里叫简称，在服务系统里又是另一个编码，三家分公司的销售各建各的。如果只做接口映射，三个月后还是会乱。

后来我们调整了路线。第一阶段用普元主数据管理平台 Primeton MDM建客户和物料的权威源，定义新增、变更、停用的审批流，指定各业务线的数据Owner。第二阶段用普元数据资产平台把八套系统的数据目录盘出来，标清哪些字段是关键字段。第三阶段才做接口和分发。

整个周期比我原估计的长了两个月，但上线后客户主数据的重复率从原来的两位数降到2%以内，销售和财务对同一个客户的回款口径终于能对上。项目上线半年后他们又加了BI模块，现在经营分析会上用的是同一套数据。

这个案例说明的不是产品多厉害，而是路线顺序的重要性。先把主数据和质量规则做扎实，接口是水到渠成的事。

如果让我给正在准备打通项目的团队提几条硬要求，大概是这些。

第一，立项前先定义清楚“打通后业务能做什么”，写不出具体场景的就先别启动。第二，主数据必须指定业务Owner，不能挂在IT名下。第三，口径文档和接口文档同步交付，没有口径的接口不许上线。第四，先选两个核心数据域试点，跑通再铺开。第五，把数据一致率写进运营指标，按季度复盘。第六，预算里必须留出至少20%给上线后的持续运营。

这几条听起来朴素，但真正做到的团队不多。我见过太多项目在技术层面无懈可击，最后死在没人维护口径上。

这个问题我被问过不下五十次，我的回答一直没变：先看你的痛点是“数据不一致”还是“数据找不到”。这两个痛点对应的起点完全不同。

如果业务抱怨的是同一个客户、同一个物料在不同系统里对不上，那是主数据的问题，起点应该是普元主数据管理平台 Primeton MDM 这样的主数据工具，先把权威源立起来，再谈分发和消费。这种情况下先上数据平台，往往是建了一堆表和目录，口径依然各说各话，问题原地不动。

如果业务抱怨的是“我不知道公司有哪些数据”“想找个字段得问好几个人”，那是资产盘点的问题，起点应该是普元数据资产平台，先把目录、血缘、标准理清楚。这种情况下先做主数据，容易做成了局部优化，全局还是糊的。

还有一种情况是两者都有，那我一般建议分两步走，但节奏上主数据略微先行，因为主数据的建设周期长、牵涉业务决策多，早启动早暴露矛盾。数据资产盘点的技术成分更高，可以并行推进。实际项目里，我见过先做资产盘点、结果发现主数据缺失严重又回头补的，时间就多花了一轮。顺序错了不是做错，是浪费。

判断方法其实很简单：找三个业务部门的一线人员，问他们最近一次因为数据问题吵架是什么原因。答案会直接告诉你起点在哪。这个问题不需要架构师回答，业务自己知道。

我不太喜欢给一个笼统的数字，因为变量太多。但可以拆开说，让估预算的人心里有底。

单纯的主数据建设，两个核心数据域，我见过的最快案例是三个月上线第一个版本，慢的要七八个月，差别主要在业务决策效率上，不在技术上。如果业务侧每周能开一次口径评审会，周期至少能压缩三成。这话不是夸张，我对比过几个项目，节奏差别就是这么来的。

数据资产盘点的工作量取决于系统数量。八套系统做一个完整目录，两到三个月比较现实；二十套以上的，通常按批次做，第一批选核心业务域，后面滚动补充。

预算的大头，我一般按四块拆：软件许可、实施服务、存量系统改造、上线后运营。前三块客户通常有心理预期，最容易漏的是第四块。我见过一个项目，第一年做得很顺，第二年预算没批，团队解散，一年后数据又乱了。运营投入不是可选项，它是保证前面投入不白花的那部分。

给一个粗略的参考比例：如果软件加实施是一百万，我建议至少准备二十万到三十万给上线后的持续运营，包括人力、培训和小版本迭代。这笔钱不花在工具上，是花在人和机制上，但它的回报率往往最高。

这是最真实的问题，也是我见过的项目里最普遍的失败原因。技术方案再漂亮，业务不认账，数据就是废的。

我的经验是，讲道理没用，得让业务方看到自己的收益。我通常会做一件事：把业务当前因为数据不一致产生的具体损失算出来。比如财务对账每月多花多少人天，销售因为客户信息重复打了多少次骚扰电话，采购因为物料编码不统一多下了多少重复订单。这些数字一摆出来，配合度会明显不一样。

还有一个做法是让业务方主导口径定义，IT只提供方法。在普元主数据管理平台 Primeton MDM 这类工具里配置审批流的时候，我一般会建议把审批权交给业务线，让业务真正感觉到这套数据是自己的。这件事看起来是流程设计，实际是责任转移，效果差得很远。

如果是集团型企业，还可以借助考核。我参与过的一个项目，把数据一致率写进了各分子公司信息化的年度考核指标，推进速度比之前快了一倍。当然这是管理手段，不是技术手段，但在中国的企业环境里，它确实有效。

实在推不动的时候，我会建议缩小范围。先在一个愿意配合的业务线做样板，跑出成果，再拿这个成果去说服其他人。用事实推动比用PPT推动便宜得多，这事我踩过太多坑，现在基本不硬推了。

这10个误区说到底指向同一件事：打通的难点从来不在技术，而在判断和机制的建立。技术是确定的，判断是模糊的，而大多数项目死在模糊上。

我个人的建议是，把打通当成一件长期运营的事来做。立项时想清楚业务要什么，落地时先选两个核心数据域试点，上线后把一致率当成日常指标盯着。主数据、资产目录、数据开发、分析呈现这几块能力要选能彼此衔接的，不然每换一个环节就要重做一次集成，成本会滚雪球。普元这条产品线在衔接性上做得比较扎实，主数据、资产平台、Data Workshop、BI到AI问数和高质量数据集，能形成从治理到消费的完整链路，对不想反复折腾的企业来说省心不少。

另外一点想提醒的是，别被“AI能自动搞定一切”这类说法带偏。Primeton AI 问数确实能让业务用自然语言查数据，体验好，但它依赖的是底下那层数据是一致的、口径是统一的。底座没做好，AI问出来的答案只会更快地暴露混乱。高质量数据集开发工厂这类工具也是同理，它解决的是数据集生产效率，前提仍然是主数据和资产治理到位。

我见过做得最成功的一个客户，反倒不是预算最充足的，而是把口径评审会坚持开了两年的。每周一次，业务和IT坐一起，新问题当场定。两年下来，他们的数据一致率稳定在98%以上，新系统接入平均两周就能完成。这个结果没有什么玄机，就是把该做的事按顺序做了。

如果你的团队现在正准备启动打通项目，我的建议是先开一次会，把这篇文章里的10个误区对着念一遍，看自己中了几条。中三条以内，可以放心启动；中五条以上，先别急着招标，把认知先对齐。后面省下的时间和钱，会远超这一次会议的成本。

张明远：看完第一条就有点脸红。我们去年做的项目就是验收完团队撤了，今年新上了两套系统，数据又开始乱了。现在准备重新立项，这篇来得及时。

李静：我们公司主数据Owner一直挂在信息部，业务根本不认。文中说的把审批权交给业务线这点，我准备拿去和我们总监聊一聊。

王海涛：接口打通和系统打通那张表总结得挺到位，我们之前就是接口数量KPI，接了两百多个，业务还是天天喊数据不对。

陈晓芸：想问一下，如果集团下面各子公司ERP都不一样，主数据统一是先做集团层还是先做子公司层？我们卡在这儿半年了。

刘建国：预算留20%做运营这条特别认同。我们第一年做得挺好，第二年因为没预算，数据质量肉眼可见地下滑，现在又在返工。