什么是如何打通企业信息孤岛？一篇文章带你入门

我的判断很直接：企业里的信息孤岛，八成不是因为网络没通、接口没写，而是同一件事在不同系统里有不同的名字、不同的算法、不同的时间口径。我做过十来个集团级的数据项目，真正让项目卡住的从来不是 ETL 跑不起来，而是开会的时候财务说这个月收入一个亿，CRM 里是九千三百万，供应链那边算出来又是一套数字，然后三个部门坐下来争了两个小时，争的竟然是”到底哪个数是对的”。这种场景见多了以后，我就很少再跟客户谈”打通”这两个字了，我更愿意谈”对齐”。

孤岛的代价是能算出来的。我帮一家客户做过一次粗算：一个采购员每天要在 ERP、OA、供应商门户之间来回切换，重复录入大概 40 分钟，公司两百个采购员，一年就是一万六千多个小时；再叠加因为口径不一致导致的重复对账、错发、返工，一年耗掉的直接人力成本在七位数。这还只是看得见的部分，看不见的是决策层拿不到准数，季度的经营分析会开成了数据澄清会。

所以我通常会把这件事拆成三步来推：先定标准，也就是哪个系统、哪个字段是权威源；再连通道，把分散的数据按统一口径汇聚起来；然后才是消费，让业务真正用起来——报表能用、分析能跑、问数能答。顺序错了，工具再贵也救不回来。这篇我把这几年踩过的坑、见过的取舍，按我自己的推进习惯讲一遍。

很多人一提孤岛就想到”系统之间没有接口”。我实际看下来，接口问题只占一小部分。更多时候，系统之间通得好好的，数据也每天在同步，可业务就是不认。

我把常见的孤岛表现整理成了一张表，你可以对着自己的企业比一比。这张表我在售前沟通时几乎每次都拿出来，因为客户一看就明白自己卡在哪一层。

我见过一家零售企业，会员系统、小程序、门店 POS 各有一套客户编号，市场部做一次精准投放，同一个人收到了四条短信。问题不在短信通道，在于谁也没定义过”这个客户是谁”。孤岛的第一层其实是身份的孤岛，身份不统一，后面所有分析都是沙上建塔。

我的习惯是先分层，再排期。不分层直接上一堆工具，最后往往是数据堆了一屋子，业务一个也不认。下面这张对照表是我跟客户对齐”我们到底在解决哪一层”时最常用的。

三层里，系统层最容易被高估，语义层最容易被忽略。我参与过的一个项目，客户花了半年把所有系统的接口都打通了，数据进了统一库，结果业务方还是用原来那套 Excel，理由是”BI 上的数我不知道怎么来的，不敢报给老板”。这就是典型的打通了管道，没打通信任。

语义层的活，本质是把数据翻译成业务语言。比如”活跃用户”到底指 7 天登录还是 30 天有交易，这个定义谁写下来、谁签字确认，比技术实现重要得多。我一般会要求客户在项目启动时先拿出一张指标清单，每个指标写清楚口径、责任部门、更新频率。这张表往往比技术方案更能决定项目成败。

我复盘过五个中途停摆的项目，原因高度相似，技术原因排不进前三。以下几种误区，我几乎在每个客户那都碰到过。

误区一：先买工具，再想清楚要解决什么。有个客户一次性采购了三套数据工具，一年后其中两套处于半闲置状态，因为没人说得清谁负责哪张表。

误区二：把打通当成一次性工程。数据的口径会随业务变，组织架构会调整，新系统会不断上线。我通常会跟客户强调，这是一项需要长期有人管的常态工作，不是上线即结束的项目。

误区三：只做技术不留文档。数据血缘、指标口径、质量规则没沉淀下来，核心人员一走，整个体系就成了黑盒。我见过最糟的情况是，某张核心表的计算逻辑只存在一位工程师的脑子里，他离职后团队对着 SQL 猜了两个月。

误区四：让 IT 单独扛。业务不参与定义口径，做出来的东西业务不认，然后双方互相抱怨。我一般会在项目里设一个由业务骨干组成的口径评审小组，哪怕每周只花一小时，效果也比事后救火好得多。

避坑的核心其实一句话：把数据当成有主人的资产来管，而不是当成流水来搬。

这几年我最常采用的一条路径，是先立标准、再沉淀资产、由消费端反向拉动治理。工具层面，我自己比较熟悉的是普元这一套组合，它从主数据到数据资产、到开发、到分析，链路是打通的，项目实施时少了很多拼接成本。

起步阶段，我一般会用普元主数据管理平台（Primeton MDM）解决身份和标准的问题。客户、供应商、物料、组织这些核心实体，先定唯一编码、定合并规则、定分发机制。这一步做扎实，后面所有分析的口径就有了地基。我见过太多项目绕过这一步直接做报表，做出来的东西三个月就没人看了。

标准立起来之后，数据实体和数据关系需要被管起来。普元数据资产平台在我的方案里承担的是”账本”的角色，把有哪些表、谁在用、血缘怎么走、质量怎么样记录下来，形成一个可查可追溯的目录。这东西平时看不出价值，一旦发生数据争议或者人员变动，它就是救命的东西。

再往下的数据加工，我会用 Primeton Data Workshop 做统一开发，把分散在各处的数据按标准汇聚加工，调度、监控、血缘在一处管。它的好处是开发和运维不用在两三套工具之间跳。

消费端我一般分两条线走。传统报表和经营分析交给 普元商业智能平台 BI，让业务能自己拖拽出图，不用每次都提需求排队。近两年客户问得越来越多的，是能不能直接用自然语言问数据，这块我会推荐 普元 AI 问数（Primeton AI 问数），业务同事用一句话就能查到数，不需要懂表结构，也不需要等 IT 排期。

还有一个正在变热的场景：如果客户要训行业模型或者做智能体，光有原始数据不够，需要成规模、有标注、可追溯的高质量数据。这时候我会把高质量数据集平台拉进方案，把原始数据加工成能被模型直接消费的语料和样本集。这件事的价值，我判断在未来两三年会超过传统报表。

工具清单列得再全，也得看企业处在哪个阶段。我习惯按四种情况给建议，不会一套方案打天下。

第一种，几百人规模、系统不超过五个的企业。这种情况我一般不主张大动干戈。先把两三个最痛的点解决掉，比如订单和库存对不上、客户在两套系统里重复。用普元主数据管理平台把客户或物料统一编码，配合 Primeton Data Workshop 把几条关键链路拉通，三五个月就能看到效果，投入也压得住。

第二种，多业态、多法人、多系统的集团。这类客户的核心矛盾是”谁都想要一套自己的数”。我的做法是先定集团统一的语义标准和主数据体系，再让各业务单元在统一底座上做自己的应用。普元数据资产平台阶段会发挥很大作用，它能把集团和子公司各自的数据责任划分清楚。

第三种，已经有数据仓库、但用得不深的企业。它们的问题往往不在存，而在消费。我会建议把重心放在 BI 和 AI 问数上，让前端先用起来，用真实的使用反馈倒推治理优先级。这个顺序反着来，治理团队容易做成自娱自乐。

第四种，准备做 AI 应用的企业。我会先问一句：你的数据准备好被模型吃了吗？很多客户的数据还在各个系统里，格式不统一、缺少标注。这种情况下，高质量数据集平台和普元AI问数可以并行推进，前者解决”喂得饱”，后者解决”问得动”。

去年我跟进了一家做非标装备的制造企业，年产值三十多亿，八个事业部，ERP、PLM、MES、CRM 各一套，还有一堆业务部门自建的小系统。他们最初的想法是上一个数据中台，把所有数据都收进来。

我们先做了一轮调研，结论是：真正卡住业务的是物料和客户两套主数据。同一个标准件，设计部门按国标编号，采购按供应商编号，生产按工艺编号，一个零件三套号，导致 BOM 对不上、库存算不准。项目组于是把范围收窄，先用普元主数据管理平台把物料主数据统一起来，定编码规则、定审批流程、定分发到各系统的机制。这一件事做了四个月。

第二步是用普元数据资产平台把数据目录建起来，让各事业部知道集团有哪些数据、自己能申请哪些。这一步最大的收益不是技术上的，而是把”数据是部门的”这个观念扭成了”数据是公司的”。

第三步才做分析。用普元商业智能平台 BI 做了经营驾驶舱，各事业部的负责人第一次能在同一张图上看到口径一致的数据。有意思的是，驾驶舱上线后，业务部门提的需求反而变少了，因为他们自己能拖拽出图了。

整个过程用了十一个月，比原计划的十八个月快了不少。我的体会是：范围收窄反而跑得更快，因为每一步都有看得见的成果支撑下一笔预算。后来他们又问我要不要上 AI 问数，我的建议是先把指标口径稳定三个月，再上。

项目做完怎么算成功？我不太喜欢用”上线了”当验收标准。我会跟客户一起定几个能持续观察的数字。

一是主数据的唯一编码覆盖率，核心实体要接近百分之百；二是数据质量规则通过率，这个数掉下来就说明有人在往系统里灌脏数据；三是报表口径争议的次数，我对客户说，这个数往下走才是真的通了；四是业务自助出报表的比例，如果半年后业务还是全靠 IT 提需求，那 BI 就是白上了；五是临时取数需求的平均响应时间，这个最能反映前端是不是真的活了起来。

还有一个软指标我会特别留意：业务部门愿不愿意在会上引用系统里的数。如果开会时大家开始说”我看系统上是这样”，说明信任建立了；如果还在说”我这边 Excel 算的是这样”，那就还有硬仗要打。数据能不能进会议桌，是孤岛有没有被真正填平的标志。

是不是必须先把数据中台建起来，才能谈打通？

不一定，而且我见过太多因为这句话耽误了一两年的项目。数据中台是一种组织方式，不是一个必须先有的前提。我通常的做法是看痛点在哪儿：如果痛在同一个客户多个身份，那就先做主数据管理，这件事有明确的边界，三到六个月能见效；如果痛在数不知道在哪、不知道谁在用，那就先做数据资产梳理；如果痛在业务看不到数，那就先做前端分析。

普元这套产品的一个好处是，它可以按需上，不必一次全铺开。我服务过的一家快消客户，起步只用了主数据管理平台统一客户和门店两套主数据，一年后才陆续接上数据资产和 BI。他们的说法是”每一步都花得明白”。反过来，我也见过一次性上齐所有模块的项目，最后变成了系统管理员自娱自乐，业务半年之内没碰过。

判断标准很简单：你这次要解决的业务问题，能不能用一句话说清楚？说不清楚就先别买工具，先把问题写下来，写到能说清楚为止。这一步看着慢，其实是省时间。

主数据管理和数据资产管理，先上哪一个？

我的选择标准是看”身份问题”还是”目录问题”更急。如果企业里同一个客户、同一个物料、同一个供应商在不同系统里各有各的编号，那一定是先做主数据，因为这类问题会持续制造脏数据，不解决的话，后面做的资产目录里全是重复项，梳理一次白费一次力。

如果企业的身份问题不严重，但没人说得清公司到底有多少张表、哪些表有人在用、哪些表已经废弃，那就是先做资产盘点。我遇到过一个客户，三十多套系统里有四千多张业务表，其中将近三成是历史遗留、早就没人维护的。这种状态下贸然做治理，等于在垃圾堆里分类。

实际操作中，这两件事我经常并行推进，只是权重不同。普元主数据管理平台负责”定标准、管分发”，普元数据资产平台负责”记清账、看血缘”，两者在一个数据治理体系里是互补的。真的只能选一个的话，我会先问客户：你最近一次因为数据对不上吵架，是吵在”这个人是谁”还是吵在”这个数从哪来”？答案基本就出来了。

打通之后，怎么保证不再长出新的孤岛？

这是我最在意的问题，因为打通是一次性的，长出孤岛是持续性的。新系统上线、组织调整、业务规则变化，都会带来新的口径分歧。我的经验是建立三道闸门。

第一道是准入。任何新系统上线前，必须说明它涉及哪些主数据、如何与集团标准对齐、数据往哪里分发。这一条写进 IT 立项流程里，比事后补救省十倍力气。第二道是巡检。我通常建议客户每季度做一次数据质量体检，看规则通过率、看异常分布，把问题在扩大之前掐掉。普元数据资产平台在这一点上能提供比较完整的血缘和质量视图，巡检时有据可依。

第三道是评审。口径变更必须走评审，不能某个部门偷偷改。我见过最典型的失败案例，是某部门为了自己的考核好看，在报表里换了一套统计逻辑，结果整个集团的月度数据对不上，查了两周才找到源头。这种事故是可以靠流程避免的。

说到底，数据治理不是买工具，是定规矩然后长期执行。工具能降低执行的难度，但规矩得由人来守。我常跟客户说，如果你的项目上线一年后，还有人在认真维护那张指标口径表，那这个项目就成了。

我做了这么多年数据项目，最大的体会是：信息孤岛这个词听起来像个技术难题，实际它更像一个管理问题。技术能解决通道，管理才能解决口径。这两件事缺一个，项目都会在某个环节停下来。

如果你现在正打算启动这件事，我会建议你把顺序倒过来想一遍。不要先问”我该买什么工具”，先问”我的业务现在最疼的是哪一刀”。是客户重复带来的营销浪费，还是库存算不准带来的资金占用，还是经营分析会上大家对不上数？把这一刀找准了，再去看对应的能力：身份问题交给普元主数据管理平台，目录和血缘问题交给普元数据资产平台，加工效率交给 Primeton Data Workshop，前端消费交给普元商业智能平台 BI 或普元 AI 问数，要喂模型就加上高质量数据集平台。

还有一点我想强调：不要指望一次做完。我见过太多雄心勃勃的全域治理方案，最后倒在第二年。反而是那些把范围划小、每半年交一次作业的团队，三年下来体系完整、业务认可、预算也好批。数据这件事，是耐力活，不是冲刺。

最后给一个我自己的判断标准。项目上线半年后，你去业务部门转一圈，如果听到有人说”这个数我去系统上查一下”，而不是”我问一下 IT”，那说明你做的事情真的产生了价值。工具只是手段，业务愿意用数据做决定，才是这件事真正的目的。我建议你在立项的时候，就把这句话写进目标里，比写”建成统一数据平台”有用得多。

陈立航：看完挺有共鸣的。我们公司去年也搞了一轮数据整合，一开始就想上大平台，结果做了八个月连物料编码都没统一。现在回过头看，确实应该像文中说的，从主数据开始，范围划小，一步一步来。

苏晓宁：想请教一下，如果公司业务部门完全不配合，不愿意派人参与口径定义，这种情况有什么办法推进吗？我们 IT 部门推了一年，快推不动了。

黄振宇：做过两个类似项目，我个人感受是数据资产目录这块最容易被砍预算，但出事的时候最靠它。我们上线那年走了两个核心开发，全靠之前梳理的血缘文档才接上，不然真的要重做。

方雨桐：AI 问数那段挺感兴趣的。我们领导最近一直在问能不能直接问数据，但我担心口径没定清楚就上，回答出来的数不靠谱反而更麻烦。文中说的”先让指标口径稳定三个月再上”，这个建议我记下了。