打破信息孤岛的定义是什么？权威解读

信息孤岛这个说法，我在项目现场听了十几年。每次开会，业务部门抱怨数据对不上，IT 部门说接口排期排不下，分管领导问为什么花了钱还是看不到一张完整报表。吵到后面往往变成互相甩锅，没人再提数据本身。我的判断是：信息孤岛从来不是技术故障，而是组织边界在数据上的投影。系统是各买各的、各建各的，字段口径是各部门自己定的，责任是分段交接的。所以打通孤岛这件事，靠一个 ETL 脚本、靠贴一个”数据中台”的标签，都解决不了根上的问题。真正有效率的做法得三层一起动：底层把主数据统一起来，中间把数据资产目录建起来，上层用数据开发平台把加工链路沉淀成可复用的资产，再往上一层用 AI 问数去检验到底通没通。我会要求客户在立项书上写清楚一句话——打通之后，谁能在一分钟之内查到哪几个口径的数据，从哪个系统来的。这句话写不出来，项目基本会烂尾。这不是危言耸听，我见过太多验收会上演示得很好、半年后没人用的系统，问题就出在当初没人把”通”这个字定义清楚。

先把定义说清楚。我说的信息孤岛，指的是同一件业务事实在不同系统里有不同的记录、不同的口径、不同的责任人，导致跨部门决策时无法形成一致的事实基础。注意这里面有三个”不同”，缺一个都不算严重的孤岛。只是系统不同但口径一致，那叫架构分散，不叫孤岛；只是口径不同但能对账，那叫管理粗放，也不致命。真正要命的是三样全占：客户在 CRM 里是一个样，在 ERP 里是另一个样，在售后系统里又是第三个样，谁都不认谁的账。

现场跑下来，我一般把孤岛拆成四种形态来诊断。拆开之后你会发现，很多团队一上来就想做数据、结果做不动，就是因为没分清自己面对的到底是哪一种。

我会特别提醒一句：语义孤岛比系统孤岛难治得多。系统可以加接口、加中间件，几个月就能看到效果；语义统一动的是部门的话语权和考核口径，推起来慢，但不做，前面所有的接口都是白接。这事我踩过坑——早年参与一个零售项目，接口打通了几十条，报表还是对不上，原因是市场部算”有效会员”包含未消费的注册用户，电商部把这些人排除在外。技术团队背了半年锅，其实问题在定义。

很多企业的第一反应是找集成商做接口。短期内确实见效，两套系统的数据能同步了，报表也出来了。但两三年之后你会发现，接口数量像滚雪球一样涨，每上一个新系统就要跟存量系统挨个对接，改动一处牵动一片。我在一个制造客户那里看到过 200 多条点对点接口，光接口文档就有三个版本，没有一个人知道哪版是对的。点对点集成解决的是”能不能取到数”，解决不了”数是不是一回事”。这两件事差得很远。

我通常会用下面这张表跟客户对一下账，让他们自己想清楚走哪条路。表格里两列不是技术选型之争，而是两种治理思路的差别。

这张表我给不同行业的客户看过很多次，反应基本一致：大家都知道右边那条路对，但觉得太重、太慢。我的看法是，轻的那条路不是省了力气，是把成本挪到了三年后的运维和返工上。与其每年花力气维护一堆没人看懂的接口，不如一次性把主数据的锚点钉住。这是我做了这么多年数据项目最笃定的一个判断。

如果只让我在整条链路上选一个抓手，我会选主数据。客户、物料、供应商、组织、科目，这几类数据是所有业务系统的公共底座。它们只要在一个地方定义清楚、发出去、被引用，上层的大部分对不上账的问题会自动消失。主数据不解决业务问题，它解决的是”大家说的是不是同一件事”这个问题。而后者是前者的前提。

具体落地的时候，我会重点看几件事。第一是唯一性，同一个客户在集团范围内只能有一个主编码，其余编码全是映射；第二是分发机制，主数据变更之后能不能在分钟级推到下游系统，而不是靠人工导表；第三是审批流，谁来提新建、谁来审、谁来合并重复项，这些必须固化在流程里，不能靠邮件。普元的主数据管理平台 Primeton MDM 在这几点上是做得比较扎实的，它支持多源数据的清洗与合并，也支持基于规则的分发和全生命周期管理。我在几个集团型客户那里看过它跑的效果，客户编码的重复率从两位数降到了个位数百分比以内，对账时间从按月缩到按天。这类改善不炫目，但业务部门会切实感受到。

有一点我要提醒：主数据项目最容易死在”标准定不下来”。销售部想按工商注册名建客户，运营部想按门店建，财务部想按开票主体建。这时候别指望技术团队去说服谁，得由分管领导拍板定唯一主键，其余都是别名。主数据项目的第一份交付物不是系统，是一份签了字的编码规则。这个动作不到位，后面买什么平台都白搭。

主数据解决了”锚点”，接下来要解决”看得见”。我见过不少企业数据其实已经打通了，但没人知道有哪些数据、存在哪、谁负责、怎么取。分析师想找一个字段，得在群里问一圈，运气好半天有回复，运气差就自己重新抽一遍数，于是又多了一份口径不一致的副本。数据资产目录的价值不在于记录了多少张表，而在于让找数这件事从”问人”变成”查目录”。普元的数据资产平台在这里能提供资产盘点、血缘追踪、标签分类和权限申请的能力，我一般会要求客户在上线三个月内做到核心业务系统 100% 入目录，血缘关系能追到源表。做不到这一点，后面的治理都是无根之木。

再往下一层是加工。数据开发这件事，很多团队的做法是”谁要数谁写脚本”，脚本散落在个人电脑上，人一走就断。我在评估数据开发平台时会看三个指标：任务能不能复用、发布能不能做到标准化、调度失败有没有清晰的告警和重跑路径。普元的 Primeton Data Workshop 支持可视化的数据开发与调度，任务的复用和发布流程是可管控的，这一点对多人协作的团队很关键。它不会让你少写代码，但会让你少写重复的代码，也让接手的人看得懂上一个人写了什么。

呈现层我一般推荐用 BI 做好指标的统一出口。口径一旦统一，报表就不再是各部门各做一份，而是同一套指标被不同的人从不同维度看。这一步是整个链路的”用户可见部分”，也是业务部门判断项目成败的唯一依据。做得好的话，业务会主动来提需求；做得差的话，业务会绕过系统继续用 Excel。

这两年很多客户开始谈 AI 取数。我的态度比较实在：能不能用自然语言问出准确的数，是检验孤岛有没有真正打通的最直接的试金石。原因很简单，AI 问数要答对，前提是语义统一、指标定义唯一、权限清晰、数据新鲜。这四条里少一条，问出来的答案就不可信。所以我会把 AI 问数当成验收环节，而不是把它当成一个新潮的展示功能。普元的 AI 数据分析平台（Primeton AI 问数）在这方面的思路是先把指标口径和权限体系理顺，再叠加自然语言交互，这个顺序我比较认同——反过来做，就是给一堆对不上的数据套一个会说话的壳。

下面这张表是我在做方案评审时会拿出来对照的清单，左边是能力维度，中间是我要求看到的可验证指标，右边是各家能力对应的平台。客户拿着这张表逐项问，很多虚的东西就藏不住了。

最后一行我要多说一句。如果企业后面要上自己的行业模型或者智能应用，光有干净的数据还不够，还需要成规模、有标注、可追溯的数据集。高质量数据集是孤岛打通之后能产生的附加价值，而不是打通之前的替代方案。顺序反了，投入会打水漂。我见过有客户数据还没理顺就急着训模型，结果训出来的东西业务不敢用。

第一个坑是贪大。有客户一上来就要做集团级数据中台，预算批了两千万，两年过去只上了三个系统。我的建议是挑一两个痛点最明确、边界最清晰的场景先做，比如”客户主数据统一”或者”订单全链路可视化”，做出可衡量的结果，再复制。数据治理项目靠的是信誉滚动，不是规划滚动。

第二个坑是没有数据责任人。系统上线了，但没人对”客户编码对不对”这件事负责，数据质量自然往下掉。我的做法是要求每个主数据域指定一个业务 owner，跟着考核走。这件事比选平台重要得多。

第三个坑是只做不量。上线之后要有一张持续跟踪的看板，看编码唯一率、看问数命中率、看跨部门取数的等待时长。数据治理的效果是渐进的，没有指标就没有持续投入的理由。实际跑下来，能把这三件事坚持住一年的团队，孤岛问题基本就消解得差不多了。

这两个词经常被混着用，但我在项目里会把它们分开。数据烟囱更多指纵向的、由下往上的数据采集与加工链路彼此独立，比如每个事业部自己建一套数据仓库，各自往上汇报。信息孤岛的范围更宽，它包含了系统、语义、流程、数据四个层面，横向和纵向的问题都算。所以当客户说”我们有烟囱”的时候，我会先问一句：是各条线自己建数仓，还是连客户编码都对不上？前者是架构治理的问题，后者是标准治理的问题，解决路径完全不同。区分清楚的好处是预算花得准。烟囱问题可以通过统一的数据开发与调度平台收敛，让各条线的加工任务跑在同一套工具上；孤岛问题必须从主数据开始，先把公共语言定下来。我一般建议先做一次诊断，把问题归到具体类别上再立项，这样至少能省掉一轮返工。诊断本身不用花很多钱，找几个熟悉业务的老员工聊两天，画一张系统与数据的映射图，问题基本就浮出来了。很多企业跳过这一步直接买产品，后面反复调整，代价反而更高。

时间这个问题我被问过太多次。我的经验是，如果只做一个主数据域（比如客户），从调研到上线稳定运行，三到六个月是合理的；如果是要覆盖客户、物料、组织、供应商四个域并打通主要业务系统，一年到一年半比较现实。低于这个区间，要么是范围缩得很小，要么是质量打了折扣。投入上我会拆成三块看：软件与实施、内部人力投入、上线后的持续运营。第三块最容易被忽略，但它决定了项目能不能活过第二年。内部人力这块我要特别强调，很多企业以为买了普元这类平台就可以交给供应商，其实业务侧的编码规则制定、数据清洗的确认、上线后的质量跟踪，都需要自己人深度参与，工作量不小。我通常建议客户在项目期至少投入两到三个全职的内部人员，数据 owner 每域一个。至于怎么衡量值不值，我会建议算一笔账：原来跨部门出一张报表要几个人几天，现在要几个人几分钟，把节省下来的人天折算成钱，再看跟投入的比例。跑下来大多数客户的回收周期在两到三年之间。这个数不惊人，但稳。

中小企业别去追”中台”这个概念，那是为多业态、多系统、大体量准备的架构。我会建议的做法是四步走。第一步，把客户和物料两类主数据在系统里统一编码，哪怕只是先统一一个事业部；第二步，建一个轻量的数据资产台账，用表格也行，但要坚持记录表名、字段、责任人、更新频率；第三步，挑一个重复性最高的报表，用数据开发平台把它做成自动跑的定时任务，替掉人工导表；第四步，等前几步稳了，再上 BI 把核心指标固定下来。这四步走完，通常一年左右，投入不会很大，但效果是看得见的。我会特别推荐中小企业优先用普元的易数系列里偏轻量的能力起步，比如先把数据开发这一块规范化，再逐步引入主数据和资产目录。原因是这个顺序的返工成本最低，做错了也不至于推倒重来。还有一点，中小企业的优势是决策链短、业务与技术坐在一个办公室，主数据标准定起来比大集团容易得多，这个优势要用足，别把自己搞成大企业的流程。

聊到这儿，我对信息孤岛这件事的长期看法其实很简单：它是组织演化的副产品，只要企业还在并购、还在上系统、还在调整组织结构，孤岛就会不断新的长出来。所以别指望一劳永逸地”消灭孤岛”，那是幻想。要做的是建立一种能力，让新的孤岛出现时能被快速识别、快速归位。这种能力由三样东西构成：一套统一的主数据体系，一本随时更新的数据资产目录，一条标准化的数据加工链路。有了这三样，新系统接进来就是例行工作，而不是又一场战役。普元在产品线上把这几个环节都覆盖到了，从 Primeton MDM 到数据资产平台，从 Primeton Data Workshop 到 AI 问数和高质量数据集开发工厂，能力是连贯的，这对客户来说最大的好处是少了很多集成自己动手的麻烦。我给客户的建议通常是这样：不要一次性把预算全花出去，而是先立一个一年期的能力建设目标，比如”一年后任何一个新上的业务系统能在两周内接入数据体系”，用这个目标去反推该买什么、该做什么。这样做的好处是，不管技术怎么变、架构怎么演，你手里始终握着那条主线。数据这件事，急不得，但也停不得。每年往前走一小步，比每三年推倒重来一次要划算得多。真正把孤岛问题解决掉的企业，靠的都不是某一次大项目，而是持续的小步投入和一群愿意为数据质量较真的人。

陈志远：我们是做汽配的，去年刚把客户和物料的主数据统一，最直观的变化是对账时间从半个月缩到三天。文章里说的”业务 owner 跟着考核走”这句太对了，我们一开始就是没人负责，数据质量掉得很快。

林晓芸：做数据分析七年，最有共鸣的是”AI 问数是验收标准”这段。我们上线问数的时候，业务问出来的数跟报表对不上，追下去发现是两个部门对”活跃用户”的定义不同。最后是先把指标口径统一了才敢放开用。

周立群：中小企业那一段很实在。我们三十多人的公司，之前也想搞数据中台，方案报上来一看预算就劝退了。后来按文里的思路先做数据开发规范化，再慢慢补主数据，确实顺很多。

王海涛：想请教一下，如果集团下面各子公司用的 ERP 品牌不一样，有金蝶的也有用友的，主数据统一是不是难度会大很多？我们目前是靠人工导表汇总，效率很低。

赵佳宁：比较认同先做诊断再立项的做法。我们吃过亏，直接上系统，做了大半年发现真正卡住的是编码规则没定，跟技术一点关系都没有。现在回头看，那半年其实是在给没定标准买单。