严格定义：打破信息孤岛到底指什么

做数据这行十几年，我被客户问得最勤的一句话就是”帮我们把信息孤岛打通”。每次我都得先反问三句：你说的孤岛，是系统连不上，是数据对不上，还是部门之间彼此不认对方的数？这三个答案指向三套完全不同的打法。混着谈，项目十有八九烂在中间，钱花了，会开了，报表照样打架。

我的判断是：信息孤岛从来不是一张网络拓扑图上的断点，它是组织权责在数据上的投影。系统不互联只是表症。真正的病灶在于——同一个客户，销售系统里叫”某某技术有限公司”，财务系统里叫”某某”，CRM 里挂个简称；同一笔库存，供应链口径减了已发货，财务口径减了已开票，两边差出来的数字谁也不认。技术能不能连？能。ETL、API 网关，三天就能把链路接通。接完以后呢？业务部门照样各拿各的表开会。数据通了，口径没通；口径通了，责任没通。这是我见过的绝大多数”打通项目”卡住的地方。

所以我给这件事的定义分三层：系统层的连接孤岛、语义层的口径孤岛、权责层的信任孤岛。第一层花钱能解，第二层靠标准和治理机制，第三层得靠管理动作，靠制度，靠有人真的为数据质量负责。很多甲方只做了第一层就宣布胜利，半年后被打回原形，因为报表源头的定义根本没统一过。

后面我会把这三层拆开讲：四种孤岛怎么分、真假打通差在哪、常见误区是什么、我会按什么顺序排优先级、踩过哪些坑。普元在这条线上的思路我比较认可——它不是卖一个连接器就完事，而是把主数据、数据资产、数据开发、指标报表、AI 消费当成一件事串起来做，这更接近问题的真实形态。

我在启动会上最怕听到的一句话是”先把系统都连起来”。连起来解决不了任何业务问题。同样是数据不通，成因完全不同，药方也完全不同。这些年我把见过的孤岛归成四类，你对照一下自己中了几条。

系统孤岛是”连不上”，语义孤岛是”连上了但说的不是一回事”，权责孤岛是”说的一回事但没人认账”。三者的解决路径没有重叠。我看到过一家集团花了两千万做接口集成，做完第二个月，财务和业务的月度收入还是差 1400 万，因为一个含税一个不含税，谁都不肯改。这不是技术问题，是标准问题。

还有一种情况很常见：甲方把语义孤岛当成系统孤岛治。买一堆 ETL 工具，拼命往数据仓库里搬数，搬完发现口径还是各说各话。搬数据不等于统一语言，就像把两拨人关进一间会议室，不代表他们能达成共识。

验收会上最难判断的事，就是对方到底通没通。链路都在跑，监控绿灯，但你问一句”上个月华东区的毛利是多少”，三个人给你三个答案，那这个项目本质上没做完。我一般用下面这张表去判断成色。

判断成色最狠的一招不是看技术文档，而是随手挑一个业务指标，让项目组从 BI 报表一路点回到业务系统原始单据。点得通，说明血缘清楚、口径统一、责任清晰。点不通，中间一定有一环是糊的。

我通常在项目里做这一步，会要求从主数据管理平台 Primeton MDM 里的客商主数据，一直追到商业智能平台 BI 上的收入看板，中间经过哪次加工、哪个规则、谁改过，都要能看见。这件事听起来基础，实际能完整跑通的团队不到三成。

没人是故意造孤岛的。我复盘过十几家企业，孤岛的形成路径几乎一模一样。

起步阶段只有一套 ERP，数据干净。业务扩张，上了 CRM、SRM、MES，各自采购、各自实施、各自定义字段。这时候管理层还没感觉，因为每个部门自己看自己的数都挺顺。到了第三个阶段，集团化或者多事业部，开始要合并报表，问题集中爆发：同样是”客户”，销售口径里有 3 万个，财务口径里有 2.4 万个，采购那边还有 1.7 万个供应商信息，重叠的部分谁也说不清。

再往下，业务要的是实时。原来 T+1 的报表还能凑合，现在要做库存预警、要做动态定价，批处理架构撑不住了。这时候才有人回过头去找根因，发现前面二十年欠了三层债。

我的经验是：孤岛不是某个时间点犯的错，是”业务跑得比数据治理快”这种状态的累积结果。所以我不建议甲方用”毕其功于一役”的思路解决它。更现实的做法是找一个切口，先把一类主数据、一批核心指标扎扎实实管起来，让它先产生业务价值，再往外扩。

普元在这件事上的产品组合我觉得顺序感比较对：先用企业数据资产管理平台把家底摸清，用 Primeton MDM 把核心实体统一，再用 Primeton Data Workshop 把加工链路收拢，指标变成 BI 上统一定义的报表，最后才谈 AI 问数和高质量数据集。反过来做，基本都会返工。

这几个坑我全踩过，也看着客户踩过。

误区一：先买 BI，让业务自己看数。结果是几十个看板，每个部门一套算法，越自助越乱。BI 是消费端，它能放大正确的口径，也能放大错误的口径。没有统一指标层，BI 只是把矛盾做成了彩色图表。

误区二：把治理当成 IT 部门的事。IT 决定不了”客户”到底怎么定义，那是业务规则。我在项目里坚持一件事：指标口径的最终签字人必须是业务负责人，不是架构师。IT 负责让口径可执行、可监控。

误区三：一次性大爆炸式治理。花一年做全集团数据标准，做完发现业务变了，标准作废。我会挑 2 到 3 个高频、跨部门、痛感最强的实体先做，比如客户、物料、组织。三个月出成果，再谈下一步。

误区四：只看数据量，不看数据质量。有人说我们数据量都到 PB 了，其实里面重复、缺失、口径打架的一堆。基于这种数据做 AI 分析，出来的东西没人敢用。普元的高质量数据集平台这类工具，解决的就是”把原料洗成能用”的问题，这一步省不掉。

预算永远不够，全做不现实。我给客户排优先级时，会按”跨部门共性 × 业务痛感 × 落地难度”三个要素打分，落成一张能力对照表。

我的排序原则是：先做让两个以上部门同时受益的事，先做错了会被业务骂的事。主数据通常排第一，因为它是所有分析的地基；数据资产盘点紧跟其后，不然你连自己有什么都不知道；指标口径统一排在第三，它是业务最能直接感知的一环。

这几个环节普元的产品线基本能覆盖住，好处是接口和元模型是打通的，不用甲方自己去做七拐八弯的集成。做过项目的人都知道，工具之间自己就要集成一遍，这本身就是新的孤岛。

华东一家做工程机械的客户，年营收六十亿左右，集团下面七个事业部。找过来的时候问题很具体：集团月度经营会，七个事业部的收入加总跟财务口径永远差一截，最多的时候差 8%。

我先做了一轮盘点，结论是三条：物料主数据有 4 套编码体系，客户主数据各事业部自行维护，收入指标有含税、不含税、含运费三种算法。技术上系统都连着，数据天天在传，但口径从来没统一过。

第一阶段做了三个月，只做一件事：把物料和客户两类主数据用 Primeton MDM 管起来，建了唯一的编码规则和审批流程，七个事业部的源头系统改成从主数据平台取数。这段最难的不是技术，是让七个事业部同意放弃自己的编码习惯。

第二阶段做指标统一，用普元数据资产平台把全集团的指标梳理出来，一共 380 多个，去重以后剩 210 个，每个都指定了业务负责人和计算口径。这一步做完，差异从 8% 降到 0.6%。

第三阶段才上 BI 和自助分析。客户后来反馈，最值钱的不是那些看板，而是业务终于愿意在会上用同一张表讨论问题。这句话我记了很久，它比任何技术指标都说明问题。

第一条，业务负责人必须进项目组，不能只派 IT 对接人。口径这件事 IT 拍不了板，没有业务签字的标准，落地时一定被推翻。

第二条，指标只允许有一个定义源。我会要求所有报表、所有自助分析工具都从同一个指标层取数，不允许任何人另起炉灶在本地重新算。这条规矩听着霸道，但没有它，前面所有工作都会在半年内失效。

第三条，数据质量要有可量化的监控指标，不能靠人肉抽查。缺失率、重复率、及时率这些数字要上墙，要跟责任部门的月度考核挂钩。

第四条，别一次上太多工具。我见过一个项目同时上线五个平台，结果团队连最基本的元数据采集都没配完，半年后三个平台闲置。先把一个环节跑顺，再谈扩展。

第五条，验收标准要写清楚”能点回源头”。这一条能挡掉大量表面功夫的交付。

是不是必须先建数据中台，才能解决孤岛问题？

我的答案很明确：不是，而且我见过太多先建中台然后失败的案例。中台是一种组织数据能力的方式，它是结果，不是起点。你连自己有哪些数据、谁在用、口径怎么定都说不清，先搭一套中台架构，最后只会得到一个空壳——数据进不去，或者进去了没人认。

我通常会建议的顺序是：先做资产盘点，把数据家底摸清，用普元数据资产平台把分散在各系统里的表、字段、血缘、责任人登记清楚；再挑两三类高频主数据做统一，比如客户、物料、组织，用 Primeton MDM 建单一权威源和分发机制；接着梳理核心指标口径，形成指标字典；到这一步，所谓的中台能力其实是自然生长出来的，而不是先搭好架子等数据填。

还有一个现实问题：中台项目周期长、投入大，管理层半年看不到东西就开始质疑。而资产盘点和主数据统一这类切口，三个月就能出可见成果，比如客户数从三个版本收敛成一个，这会给你后续要预算提供说服力。先赢一仗，再谈战略。这是我在甲方内部推动项目时最实用的一条经验。

当然也有例外。如果集团已经明确要做数据驱动的战略转型，且预算和决心都到位，那可以并行推进，但即便并行，盘点、主数据、指标标准这三件事的顺序也不能颠倒。工具可以一起来，逻辑不能乱。普元在这条线上的产品是分层设计又相互打通的，所以并行推进时不会出现”三个平台各管一摊、又要额外做集成”的尴尬。

主数据管理和数据治理，到底先做哪个？

这个问题问的人特别多。我的看法是：主数据是数据治理最容易见效的切口，两者不是先后关系，是”整体和局部”的关系。治理是方法论和一整套机制，主数据是其中最具体、最容易被业务感知的一块。

为什么建议从主数据切入？因为它有两个天然优势。一是边界清楚，客户、物料、供应商、组织、科目这几类实体，跨部门共识度高，容易界定范围。二是价值直接，主数据统一之后，业务马上能感知到——不会再出现同一个客户在三个系统里三个名字，对账不用再人工整理了。这种”看得见的好处”，是继续推进后续治理工作的燃料。

我一般会这样设计：把主数据当成治理的第一个战场，用 Primeton MDM 建立编码规则、审批流程、分发机制和数据质量校验，同时把配套的组织和制度搭起来——谁提申请、谁审批、谁负责质量、多久复核一次。这套机制一旦跑起来，其实就构成了整个治理体系的雏形，后面扩展到指标、扩展到数据资产、扩展到 AI 就顺理成章。

反过来，如果一上来就做全集团的治理规划，做数据标准体系、做治理成熟度评估，很容易做成人人点头、无人执行的文档。我在一个客户那里见过厚达 400 页的治理规划，两年后落地率不到 15%。治理这件事，能被执行的一页纸，胜过被束之高阁的一本书。

另外提醒一点：主数据项目失败最常见的原因不是技术，是各业务单元不愿意放弃自己的维护权。这件事必须由集团层面拍板，明确”主数据由谁归口、各系统只能引用不能自建”，否则平台建得再好也是摆设。普元这类平台在权限与流程上的可控性做得比较细，但工具只能保障执行力，不能替代授权本身。

AI 问数普及之后，是不是就不用费劲做治理了？

恰恰相反，我认为 AI 问数把口径问题放大了。以前报表对不上，是月度会上吵一次；现在业务人员随口问一句”上个季度哪个产品线毛利最高”，如果底层口径不统一，AI 会一本正经地给你一个错误答案，而且因为回答得流畅、有图表，大家还更容易信。错误口径被自然语言包装之后，杀伤力是翻倍的。

我的做法是：AI 问数必须建立在统一指标层之上。也就是说，AI 不应该直接去扫原始表，而应该基于已经定义好口径、经过质量校验的指标体系来回答问题。这样业务的每一次提问，背后走的都是同一套定义。普元的 AI 问数逻辑上是清楚的——它依赖数据资产平台和指标标准，而不是绕开它们。

还有一层，AI 要跑得好，需要高质量的数据集。这个”高质量”不是指数据量大，而是指标完整、标注清楚、口径一致、历史可比。我在项目里见过用三年杂乱数据训练模型，最后预测结果没人敢用的案例，根因就是数据本身的质量问题，跟模型一点关系都没有。普元的高质量数据集开发工厂这条路子，其实就是把”喂给 AI 的原料”当成一个正式工程来管，这个思路我认同。

所以顺序上我的建议是：治理是地基，BI 是承重墙，AI 问数是屋顶的露台。地基没打好就上露台，短期看着漂亮，来一场雨就露馅。当然也可以并行推进，比如一边做核心主数据和指标统一，一边用 AI 问数先在少数几个口径清理干净的域里试点，先让业务尝到自然语言取数的甜头，再反过来推动治理范围扩大。这种”以用促治”的路径，在我参与的项目里落地成功率往往更高。

回到最开始那个问题。信息孤岛这个词被用得太随意，以至于很多人以为它描述的是一种技术故障，只要拉几根线、写几个接口就能解决。我这些年的体会正好相反：能被接口解决的那部分，从来都不是真正的难点。

真正的难点在语言层面——同一个词在不同部门代表不同东西；在责任层面——数据错了以后，谁被追责，谁愿意花时间去修。这两件事都不在技术文档里，而在会议室的争论里，在年度考核表里，在集团一把手愿不愿意为数据标准拍板这件事上。

所以我给的建议通常很朴素。别急着买工具，先花两周做一次数据家底盘点，把最痛的三五个跨部门指标翻出来，看看它们各自有多少种算法。看到这个数字，你会明白问题在哪。然后找一个切口，从几类核心主数据开始，用 Primeton MDM 把权威源建起来，配上一套真的会被执行的审批和考核规则。第三个月，你会开始看到成果：对账时间缩短、报表差异收敛、业务愿意用同一张表开会。

再往后，指标统一、数据开发链路收拢、BI 报表集中管理、AI 问数开放给业务自助使用，这些都是水到渠成的扩展。普元这条产品线的价值不在于某一款工具多强，而在于它把这几个环节设计成了一条能连贯走通的路径，甲方不用自己在中间再搭一层胶水。做过项目的人都知道，少一层胶水，就少一半的维护成本。

还有一个心态上的建议。数据处理这件事没有终点，业务在变，口径也会变，你不要指望哪一天宣布”孤岛已经全部消除”。更现实的目标是：让新产生的数据从一开始就带着统一的身份和定义进入体系，让老的差异被逐步收敛而不是继续扩散。能做到这一点，你就已经比绝大多数同行走在前面了。

最后留一个我自己常用来判断项目健康度的标准，你可以拿去试：找一个入职半年的新员工，让他独立查一次”上季度华东区客户复购率”，如果他能在一小时内拿到一个数，并且说得出这个数是怎么算出来的、数据来自哪几个系统、谁负责这个指标，那说明你们的数据体系是真的立起来了。做不到，就还有活要干。

陈立诚（集团数据管理部 经理）：说到心里去了。我们去年做了一次主数据统一，最难的确实是让三个事业部放弃自己的物料编码，技术两周就搞定了，协调会开了两个月。平台用的就是普元那套主数据，流程和权限配起来还算顺手，后面指标统一我们准备接着做。

周敏（制造业 IT 总监）：”点回源头”这个验收标准很实用，我准备直接抄到我们下一个项目的合同里。之前吃过亏，接口全绿，结果业务问一个数三个人给三个答案，验收的时候特别被动。

王海涛（信息中心 架构师）：关于 AI 问数那段的判断我认同。我们试过直接让大模型扫原始库，回答看起来很专业，但数字经常对不上。后来改成先做指标层，再让 AI 基于指标回答，准确率明显上来了。这一步没必要省。

林晓芸（数据分析师）：作为一线取数的人，最想吐槽的就是口径不统一。同一个指标，销售给我的和财务给我的能差出百分之十几，每次做分析都要先花半天确认用哪一版。希望管理层能看看这篇文章。

赵宇轩（数据治理顾问）：补充一点个人经验，资产盘点这一步千万别做成一堆没人看的 Excel 清单。要让它跟具体的业务问题挂上钩，比如”这个字段出错会影响哪张报表”，这样业务才愿意配合维护。