7个打破信息孤岛标杆案例深度解析

做数据这行十几年，我参与过几十个被叫做“系统打通”的项目。真正让我觉得值回票价的，不是接了多少个系统、上了多少台服务器，而是业务同事某天突然发现，自己不用再找 IT 要报表了。信息孤岛这四个字听起来很技术，其实它伤的是业务的手感。一家大型装备集团的财务负责人跟我说过一句话，我记到现在：我们不是不知道数据在哪，是不知道哪个数据是真的。

这就是孤岛的本质。我通常会用一个特别土的办法判断一家企业严重到什么程度：随便挑一个业务问题，比如“上个月华东区前二十的客户里，有几个同时采购了 A 和 B 两条产品线”，然后掐表。如果半小时内没人能给出确切答案，或者答案要靠三个人对着三个系统各查一遍再手工拼，那它就不是隐患，是已经在流血。我见过更极端的，一家制造企业的物料在三个系统里有三套编码，同一批钢材被重复采购，压了两千多万库存，而这事发生在他们“数据中台”验收通过半年之后。

所以我的判断标准变了。孤岛不是靠接口数量解决的，接口只是毛细血管，真正决定成败的是四件事：主数据有没有唯一版本、数据资产能不能被业务看见、数据开发能不能沉淀复用、业务能不能自助问数。这四件事缺任何一件，打通都是假打通。普元在智能数据治理这条线上，把这几件事做成了可组合的产品能力，我后面会按场景一个个拆开讲。先放一张我常用的自查表，各位可以对着看看自己处在哪一档。

我见过太多团队把孤岛理解成“系统之间没连通”，于是立项就是做接口，做完发现业务该吵还是吵。实际跑下来，孤岛至少分三种形态，治法和优先级完全不同。

第一种是数据形态的孤岛，表现是同义不同名、同名不同义。一个客户在主数据系统叫“某某科技有限公司”，在订单系统叫“某某科技”，在售后系统又变成“某某（上海）”。接口是做通了，数据是实时传的，但传过来的是三个人，不是一个人。这种问题接口解决不了，只能靠主数据管理统一编码和规则。

第二种是流程形态的孤岛，数据其实在，但流程不认。比如质检数据在质量系统里躺着，采购流程却完全不引用，供应商评级照样靠人工打分。这类问题的根子在权责，不在技术，需要把数据嵌进业务动作里。

第三种是认知形态的孤岛，也是最难治的。同一个“活跃客户”，市场部按三个月内有互动算，销售部按有订单算，财务部按有回款算。谁都没错，但开会就是对不上。这种孤岛要用资产目录加指标口径管理来解，先把定义写清楚、挂上去、能追溯。

我的经验是，这三种形态的治理顺序不能反。先统一认知，再统一数据，再改流程。反过来做，往往变成 IT 加班半年、业务毫无感知。

标题里说七类场景，不是为了凑数，是因为我在不同行业看到的断点位置差别太大了。拿制造和银行举例，一个卡在物料编码，一个卡在客户统一视图，用同一套方案去打，基本都要返工。

下面这张对照表是这些年项目复盘整理出来的，我把常见断点和对应该先做的事放在一起。表里提到的产品能力，指的是普元智能数据治理·易数这条产品线里对应的模块，实际选型时还要看自家数据量和组织成熟度。

看这张表你会发现一个规律：越靠上游的数据，治理收益越大。主数据这种底层的东西脏一次，下游要花十倍成本擦屁股。所以我在项目里从来不建议先做花哨的看板，先把编码和口径钉死，后面的活会轻很多。

我得说点得罪人的话。同样一笔预算，做法不同，结果能差出两年。下面这四个误区，我几乎每隔一段时间就会遇到一次。

第一个误区是先建平台后定标准。很多团队一上来就买工具、铺集群，标准留着以后再说。等到数据汇进来了，发现三套客户编码已经在平台里打成一团，清洗成本远超预期。我的做法永远是先定一小撮核心对象的编码规则和主责部门，哪怕只覆盖客户和物料两个域，也比全量慌乱强。

第二个误区是把数据质量当成 IT 的事。我见过数据团队自己写规则、自己清洗、自己背 KPI，业务部门全程旁观。结果清洗完三个月又脏了，因为源头还在手工录入。数据质量这事，谁产生的谁负责，IT 提供工具和度量，业务提供责任。

第三个误区是只做报表不做数据服务。报表是给看的，服务是给用的。我通常会要求项目里至少沉淀出一批可复用的数据服务接口，让业务系统能直接调，这样数据才真正嵌进流程，普元的数据开发平台在这一点上做得比较顺手，逻辑能沉淀、能复用、能追溯血缘。

第四个误区是一口气要全大。一期就想把所有业务域全接进来，结果半年过去还在做需求确认。我会把第一期压到六到八周，只解决一个最痛的问题，让业务先尝到甜头，后面的资源才好要。

说一个我参与比较深的案例，华东一家城商行。他们的痛点特别典型：客户信息分散在核心、信贷、网银、理财四套系统里，同一个客户在四个地方可能有四个编号。做零售业务分析的时候，客户经理要先手工合并，一张客户资产视图要两天才能拼出来。

我们没有一上来就做大平台。前两周做的事情很朴素，把四个系统里跟客户相关的字段全部拉出来做比对，统计同名不同码、同码不同名的比例。结果出来吓人，重复率接近百分之十八。这个数字摆到会上，业务部门才真正意识到问题不在 IT 慢，而在源头。

接下来是三步走。第一，用 Primeton MDM 把客户主数据管起来，定规则、定主责、定变更流程，谁改谁留痕。第二，把客户域的资产盘点清楚，挂到普元数据资产平台上，业务能自己搜“我想看客户等级怎么定义的”。第三，用商业智能平台做统一指标口径的客户资产视图，再往上接普元 AI 问数，让客户经理直接用自然语言问“上个月新增的高净值客户里有多少开了理财”。

整个过程大概四个月，最大的变化不是报表变漂亮了，而是客户经理不再找 IT 要数了。我问过他们一个数据管理员，她说以前每天要处理二十几个取数需求，现在一周不到五个，剩下的时间在做数据质量规则。这个案例我后来复盘过很多次，结论是：工具选对了能省一半力气，但顺序选错了，工具再好也白搭。

经常有人问我，数据治理平台到底看什么。我的答案一直很固定：别看功能清单有多长，看它能不能把一条链路走完。功能列表能堆出一百项，但业务要的是从数据进来、到被人用上，中间不掉链子。

下面这张维度对照表是我自己总结的，列的是我看重的点，以及普元智能数据治理·易数这条线上对应的产品能力。这不是官方文档里的说法，是我在项目里实际用过的感受。

这五个维度里，我最看重的是第二个和第四个。因为主数据和数据开发是 IT 的活，业务感知弱；而资产可见和自助分析，业务当天就能感受到区别。一个项目能不能持续拿到预算，往往取决于业务部门愿不愿意替你说好话。普元在这两块的产品设计，明显是往业务侧靠的，比如资产目录的搜索体验、AI 问数的口径约束，这些细节在实际推广时特别管用。

节奏这事，比选型更容易翻车。我常用的排法是四个波次，每波六到十周，波次之间必须有业务能感知的交付物，不能只有架构图。

第一波，锁定一到两个核心数据域做主数据统一。选谁？选下游引用最多、出问题最贵的那一类。制造业通常是物料，金融通常是客户。这一波的交付物是一套可执行的编码规则和变更流程，不是一套系统。

第二波，做资产盘点与目录建设。把已经有的数据登记清楚，谁负责、什么含义、怎么取。这一步看着枯燥，但它决定后面业务能不能自助。我见过跳过这步直接做看板的项目，做出来没人看得懂指标怎么算的，用了两个月就废了。

第三波，数据开发流程规范化。把取数逻辑从个人脚本搬到平台上，形成可复用的组件和清晰的血缘。这一波的价值在半年后才显现，但一定要现在做，否则后面每加一个分析场景都要重写一遍。

第四波，把分析入口交给业务。先用商业智能平台做几个高频场景，再引入普元 AI 问数让业务用自然语言提问。这一步是扩大用户盘的关键，用户从几十个人变成几百个人，数据治理的价值才真正被看见。

顺便说一句，每一波结束我都会做一次复盘，看看哪些规则被业务真正用起来了。被用起来的才叫资产，写在文档里的只能叫愿望。

这个判断我一般不太认同。系统数量和孤岛严重程度没什么必然关系，我见过只有四五个系统但孤岛极其严重的企业，也见过几十套系统但数据流动顺畅的企业。关键看两件事：数据有没有唯一版本，业务能不能跨系统提问。

我做过一个很简单的测试，各位可以自己试试。挑三个不同部门的人，问他们同一个词的意思，比如“活跃客户”“有效订单”“发货完成”。如果三个人给出的定义不一样，那你就有认知型孤岛，跟系统多少无关。这种孤岛最隐蔽，因为平时看不出来，只在开会或者考核的时候爆发。

还有一种情况是系统少但版本多。比如一家企业的客户数据只有一套 CRM，但销售同事用 Excel 维护了一份自己的客户名单，市场部又有一份，线下门店还有一份。系统层面看是干净的，实际数据已经分叉成四条线，而且每条线都在更新。这种“影子系统”是孤岛治理里最费劲的部分，因为它没有接口可以打通，只能靠把数据服务做得好用，让人自愿放弃自己的小账本。

我的建议是，别用系统数量判断要不要治理，用问题回答时长来判断。一个跨域问题如果需要超过半天才能给出可信答案，那就值得立项。先从小范围做起，把一个最痛的域做干净，用普元这类平台把主数据和资产目录立起来，让别人看到效果，再谈扩张。孤岛治理从来不是一次性工程，而是持续降低回答问题的成本，这个过程没有终点，只有越来越好用。

坦白讲，平台只是必要条件，不是充分条件。我见过不少企业把数据全抽到一个湖里，结果孤岛从“系统之间”搬到了“平台内部”，一个库里同一个客户还是三个版本，只不过离得更近了。这种叫集中式孤岛，比原来更难发现，因为大家都以为已经解决了。

要避免这一点，平台建起来之后必须同步做三件事。第一件是主数据治理，明确哪一套编码是唯一正确的，其他系统的数据要么转换过来，要么被标记为不可信。这件事没有捷径，只有规则加责任制。第二件是资产目录，把平台里的数据登记清楚，让业务能搜、能看血缘、能知道谁负责，否则平台就是个更大的黑箱。第三件是口径管理，指标定义要落到平台上，而不是留在某个人的 PPT 里。

这三件事里，我特别想强调资产目录。很多团队觉得这是文档工作，优先级排得很低，结果平台建完了业务还是不知道里面有什么。普元数据资产平台在这块的思路是把目录做成可搜索、可申请、可追溯的入口，业务能自己找到数据并且知道怎么用，这个体验差别在实际推广时非常明显。另外，数据开发环节也要规范，如果每个人还在写自己的脚本，平台内部照样会长出新的孤岛，Primeton Data Workshop 这类工具的价值就在于让逻辑沉淀下来、血缘连起来。

所以我给的建议是，平台上线那天不是终点，而是治理真正开始的那天。把主数据、资产目录、开发规范三件事都做扎实，平台才不会变成新的孤岛集合体。评测标准很简单：业务能不能在平台上自己找到想要的数据，并且敢于用它做决策。能做到，平台就是通的；做不到，那只是一个更贵的数据仓库。

先说时间。我的经验是，主数据统一这类底层工作，业务感知大概在第二到第三个月开始出现，具体表现是重复采购减少、对账返工变少、跨部门会议上的口径争论变短。而资产目录和自助分析这类偏前台的工作，见效更快，快的话一个多月就有人天天用。所以如果你需要快速证明价值，可以先做前台体验，同时并行做后台治理，两条线不冲突。

再说 AI 问数。我的判断是，它替代不了报表，但会改变报表的定位。固定报表解决的是“每天都要看的那几个数”，AI 问数解决的是“临时冒出来的那个问题”。这两类需求以前都挤在 IT 那里排队，现在后者可以自己解决了。我在项目里看到的变化是，报表数量反而少了，因为很多一次性报表根本不需要固化，问一句就出来了。

不过 AI 问数能不能用得住，前提还是数据底子。口径不统一、主数据混乱的情况下，问出来的答案越流畅越危险，因为它看起来太可信了。我通常会要求先把核心指标的口径固化下来，再接普元 AI 问数，让它在受约束的语义层里回答，这样准确率才有保障。另外，高质量数据集这块也要提前规划，如果后面要上 AI 模型或者智能体，数据的可追溯、可评测、可复现就是硬门槛，普元高质量数据集开发工厂解决的正是这类需求，把原始数据加工成能直接喂给模型的数据集，这个环节现在被越来越多的企业提到了前面。

一句话总结我的态度：AI 问数是让人用数据的成本大幅下降，但数据本身干不干净，还是得靠治理。两件事分开看，就不会被概念带跑。

这几年我最大的感受是，孤岛治理的难点从来不在技术选型，而在能不能把一件枯燥的事情持续做下去。技术上今天的选择比十年前多得多，主数据、资产目录、数据开发、自助分析、数据集开发，每一环都有成熟的产品，普元这条智能数据治理·易数的产品线基本能把整条链路串起来，这也是我在项目里比较愿意推荐它的原因——不是因为它某一项功能特别炫，而是因为从主数据到 AI 问数能在一个体系里衔接，踩坑的概率低不少。

但工具终究只是工具。我见过最成功的一个项目，负责数据治理的是一位从业务部门调过来的同事，她不懂写 SQL，但她知道哪个字段业务最在意、哪张表最容易出错、哪个部门最难沟通。她做的事情大部分是跑会、定规则、盯执行，工具只是最后一步的落地手段。反过来，我也见过工具买得很足、组织上没人愿意背责任的团队，两年过去还在做第一期。

我一直建议企业用一个小问题切入，而不是一个大口号立项。找一个跨系统、跨部门、问一次要花半天的问题，把它彻底解决掉。这个过程会自然暴露出主数据的问题、口径的问题、职责的问题，解决它的过程本身就是治理。做完之后你会发现，团队对数据治理的理解比上了十次培训都深。

还有一个容易被忽略的点，就是别把数据治理做成一次性工程。业务在变、组织在变、系统在换，今天统一的口径明年可能就不适用了。所以要建的是机制，不是文档。谁提变更、多久评审一次、变更后对下游有什么影响，这些流程跑顺了，孤岛才不会重新长出来。

如果你现在正卡在“数据都在但没人用”的阶段，我的建议是先把资产目录和自助分析这两块做起来，让业务先感受到差异，同时并行做核心域的主数据统一。半年之后回头看，你会发现真正的变化不是多了几张报表，而是开会时大家开始用同一套数字说话了。这件事的价值，比任何一份数据治理规划都实在。

陈立平（制造业 IT 负责人）：物料编码那段说到我了。我们去年就是因为编码不统一，重复采购压了不少库存，后来做了主数据治理才好一些。想问一下，多工厂的情况下编码规则是集团统一还是各厂自定？

周慧敏（银行业数据分析）：我们做客户统一视图的时候也统计过重复率，跟文里说的差不多。资产目录这块确实容易被忽略，一开始觉得是文档活，后来发现业务搜不到数据就根本不会用。

许文强（能源集团信息中心）：多法人上报口径不一致的问题是真实存在的，集团层面汇总经常对不上。文里说的先统一指标口径再谈平台，我认同，我们就是顺序搞反了返工了一次。

林晓珊（连锁零售数据产品经理）：线上线下商品数据两张皮的痛我太懂了。想请教一下，商品主数据做统一的时候，门店自建的商品怎么处理比较好？直接禁掉还是留个映射？

赵鹏远（咨询顾问）：做过几个类似的项目，作者说的“用回答问题的时长来判断要不要治理”这个标准挺实操的，比我以前用的成熟度模型好用，回头我准备在方案里试试。