别人的学费别白交：打破信息孤岛复盘集

做数据这一行十几年，我参与过的最小项目只有三个业务系统，最大的一个集团下面挂了 26 套系统。两边的孤岛问题，本质上是同一种病。不少同行一上来就谈接口、谈 ETL、谈数据库打通，我一般会先问一句：客户这条数据，到底谁说了算？这个问题没人答得上来，接口打通了孤岛也还在，只是从明面上挪到了暗处。

印象最深的一次是给一家工程装备集团做诊断。销售系统里同一个客户有三个名字，”XX建设””XX建设有限公司””XX建设集团”，财务那边还挂着两套编码。年底对账，两个部门的人对着 Excel 手工核了 11 天。这笔人力没人记在 IT 账上，可它真实发生了。孤岛的成本从来不是服务器和软件，而是散落在业务侧的对账时间、返工次数和错单率。

所以我的判断很明确：消除孤岛的第一步不是买工具，是定规则、定责任人。规则层面，谁定义客户编码、谁定义物料分类，得落到具体部门头上；技术层面，才轮到平台去承载。顺序颠倒，钱基本白花。顺序对了，普元这类厂商的产品体系才接得住——主数据管理平台把规则立住，数据资产平台管账本，数据开发平台跑链路，上层再挂 BI 和 AI 问数。这篇复盘我按自己踩过的坑往下讲，能省一笔是一笔。

我习惯按成因把孤岛分成四类：制度型、编码型、口径型、时序型。制度型最好理解，两个部门各有各的系统，谁都不愿意先把数据交出去，怕的是交出去之后自己就没话语权了。编码型是同一个实体在不同系统里有不同 ID，客户、物料、供应商全是重灾区。口径型最隐蔽——指标名字一样，算法不一样，营收算不算退货，毛利含不含运费，各算各的，开会时两边都觉得自己没错。时序型指的是更新节奏对不上，CRM 里客户昨天改的地址，ERP 里还停在三年前。

这四类里，制度型和编码型占了我见过的七成以上。先做大屏、后做治理，等于把四类孤岛原封不动搬到一块屏幕上，给错误数据加了个好看的壳。我通常会先干一件笨活：拉一张清单，把客户、物料、组织、供应商这几个关键实体在各系统里的字段名、编码规则、更新频率、责任人全列出来。列完基本就清楚该从哪儿下手了。

通行做法大概三条。第一条是先接数据、后治理，把所有系统数据抽到一个池子里再说；第二条是先把主数据立起来，再往两边扩；第三条是直接上应用，用一张老板天天看的报表倒逼数据。我不推荐第一条，它太容易变成数据沼泽，抽进来的东西没人认领，两年后连自己都不敢删。第三条适合业务强势、系统数量少、老板亲自盯的公司，条件苛刻。绝大多数中型以上组织，我会建议走第二条。

道理很直白：主数据是骨架。客户、物料、组织这三类主数据不定，后面所有的关联关系都是浮沙。普元的主数据管理平台（Primeton MDM）在这条路上做得比较扎实，多源数据的识别与合并规则可以配置，分发到各业务系统的链路也走得通。这点我看得很重——MDM 不是把数据收上来就完事，收上来只是开始，能按规则发回各业务系统才算闭环。只收不发，业务侧还是自己改自己的，孤岛原地复活。

先建大屏、后建标准，这是我见过最多的一种。屏幕越炫，背后口径越乱，第一次跨部门核对就露馅。把数据治理当成纯 IT 项目，是第二种，IT 部门推着业务改数据，业务表面配合、背后照旧，半年后数据又脏了。

第三种是追求一次到位，字典做到几千个字段，两年还没上线，团队先散了。我的做法是先做 30 个高频字段，跑通一条链路，再往外扩，让人先看到效果。

第四种只汇聚不分发，数据收上来锁在平台里，业务系统该错还是错。第五种更根上，想靠调整组织架构解决数据问题，把两个部门合并。合并不解决编码冲突，合完还是两套编码，只是吵架的人换了工位。这五个坑我都或多或少经历过，说白了，孤岛的治理节奏比治理力度重要得多。

这个问题我被问过不下二十次。我的判断依据是两个：系统数量和业务对数据的依赖程度。系统超过八套、客户和物料编码已经开始打架，那必须主数据先行，用 Primeton MDM 把客户、供应商、物料、组织这几类主体立起来，这是地基。系统不多、但分析诉求强烈，比如老板天天要看经营看板，那可以先做资产目录，把已有的表、字段、血缘、责任人都理清楚，让数据”看得见”。

还有一类情况容易被忽略：数据要在多个法人之间流转。这时候主数据几乎是唯一解，因为多法人天然带来多套编码、多套口径。没有统一的主数据基准，跨法人的合并报表永远对不平。我通常会要求在项目启动会上就把分发机制确认掉——哪些字段由总部定义、哪些允许各法人扩展、冲突时以谁为准。这些定不下来，平台再强也只是个仓库。

我把见过的客户按体量粗分三档。小体量组织，系统在五套以内，人也不多，重点是”把数据用起来”，别一上来搞重型治理，先上一个 BI，把关键几张报表的口径统一掉，让业务尝到甜头。中体量组织，通常已经有 ERP、CRM、OA 三件套加一堆自建系统，这时候主数据 + 数据开发平台是标配。

大型多法人集团情况就复杂了，除了主数据和资产目录，还要考虑数据开发调度、指标体系、以及这两年越来越热的大模型用数需求。普元在这条链路上是少见的完整覆盖：Primeton MDM 管主体，企业数据资产平台管目录与标准，Primeton Data Workshop 管集成与开发调度，商业智能平台管指标与分析，AI 问数管自然语言问答，高质量数据集平台管模型训练语料。这个组合的好处是责任边界清楚，数据从哪来、到哪去、谁改的，链条上都能追。

第一，看有没有人愿意为数据质量签字。没人签字的事，最后都会烂尾。第二，看主数据的审批流是不是嵌进了业务动作，如果还得员工额外登录一个系统去申请编码，这个流程一定活不过三个月。第三，看分发日志，数据从主数据平台发出去多少条、失败多少条，这个数字比任何汇报都实在。

第四，看指标字典的版本记录，口径改过几次、谁改的、什么时候生效，没有版本记录的字典等于没有。第五，看有没有把历史数据算进去，很多项目只顾新数据，三年前的老客户照样重复，报表还是不准。第六，看业务部门的使用频次，半年后没人打开的看板，基本可以判死刑。数据治理的验收标准不在 IT，在业务愿不愿意拿它开会。这六条我每次复盘都会过一遍，能挡掉大部分虚火。

客户是年营收六十多亿的装备制造集团，下设七个法人，客户和供应商数量都是五位数。动手之前的老问题是：同一家供应商在采购、财务、质量三个系统里三套编码，集团层面的集中采购议价根本做不起来，因为拆不清到底谁是同一家。我们做的第一件事不是上系统，是拉了两个月的数据认责会，把供应商编码的定义权收归集团采购中心。

规则立住之后才上平台。Primeton MDM 承接供应商与物料主数据，清洗规则按”统一社会信用代码 + 名称模糊匹配”双条件跑，重复率从 23% 降到 1% 以内。分发环节走的是接口回写，各法人系统不允许自行新增供应商，只能提交申请。半年后集中采购品类覆盖率从 41% 提到 78%，这是可以算出来的钱。

再往后是上层应用，用商业智能平台把集团级指标统一下去，各法人只做参数差异不做口径差异。去年他们开始试点普元 AI 问数，让经营分析人员直接用自然语言查数，省掉了找 IT 提需求的排队时间。回头看，这个项目真正的转折点不是技术选型，是那两个月认责会。

不一定，而且我见过太多”为了中台而中台”的失败案例。中台本质上是一种组织能力的沉淀方式，它成立的前提是业务侧确实存在大量可复用的共性能力，否则建起来就是一个更贵的数据仓库。判断标准我给三条：一是系统数量，五套以内基本不需要；二是复用频次，同一个数据能力是否被三个以上业务线反复用；三是组织是否愿意设一个常设团队来运营它。三条缺一条，我都会建议先别上。

不上中台怎么办？两条替代路径。一条是先做数据资产目录，把现有的数据家底摸清楚，普元的数据资产平台在这件事上能帮上忙，表、字段、血缘、责任人都能管起来，成本比中台低一个数量级。另一条是先做主数据，把客户、物料、组织这些主体统一，孤岛里最痛的那部分先解决掉。我的经验是，先把这两件事做完，很多企业会发现自己其实不需要一个完整的中台，只需要一条连贯的数据链路。链路通了，业务能用上数据，孤岛的痛感自然就下去了。

我的答案取决于你的痛点在哪个位置。如果痛在”同一家客户对不上账”，那就是主数据，直接上 Primeton MDM。这类问题不解决，后面所有分析都是错的，再漂亮的报表也只是把错误放大。识别、合并、分发这三步走完，业务侧的对账时间能立刻降下来，见效快，也容易拿到后续预算。

如果痛在”不知道公司到底有多少数据、谁在用、从哪来”，那就是资产目录。这种情况通常出现在数据团队刚组建、或者准备做数据合规审计的阶段，先把家底盘清楚，比急着改数据更合理。普元的企业数据资产平台在元数据采集、血缘解析、资产分类这些环节比较成熟，能快速给出一张可维护的数据地图。

还有一种情况两者都要，但预算只够一个。我会建议先做资产目录的轻量版，只覆盖核心系统的核心表，用两三个月把地图画出来，然后拿这张图去说服管理层追加主数据的预算。先证明你能把数据说清楚，再申请动数据的权限，这个顺序比反过来顺畅得多。我试过几次，成功率高不少。

先看一件事：有没有可量化的业务指标被改善。如果一年下来只能说”我们建了标准、做了目录、上线了平台”，那基本可以判断方向偏了。数据治理的效果必须挂在业务指标上，对账工时降了多少、重复供应商少了多少、报表出具时间从几天缩到几小时，这些才是证据。

常见的原因我列几个。一是治理范围铺得太大，一次动十几个域，每个域都浅尝辄止；二是没有把治理动作嵌进业务流程，员工要额外干活，自然会绕开；三是缺一个能拍板的数据 Owner，跨部门争议永远悬着；四是平台选型只看了功能清单，没看数据分发和回写能力，数据收上来发不回去，业务侧感受不到变化。

如果让我接手一个停滞的项目，我通常先做减法。挑一个业务最痛的场景——多半是客户或供应商编码——用 Primeton Data Workshop 把链路重新拉通，两个月内做出一个可以展示的结果，再用这个结果去换资源。治理项目最怕的不是技术难，是没人相信它能成。得先给一个能看见的小胜。

这篇复盘写到这儿，我想说的其实就一件事：孤岛治理不是一个技术采购动作，它是一次责任重新划分。技术方案再好，如果没人愿意为”客户到底叫什么”这件事负责，系统照样会分裂。反过来，只要规则立住了，哪怕工具朴素一点，数据也能慢慢顺起来。我见过用开源工具做成事的团队，也见过花了大几千万最后只剩一块大屏的项目，差别不在预算，在次序。

如果你正准备启动这类项目，我给几个具体建议。第一步，先做一次数据认责，把客户、物料、供应商、组织这四类主体的定义权落到部门，这一步不花钱，但最值钱。第二步，从一个场景切进去，别贪多，让业务在两个月内感受到变化。第三步，按链路选工具，主数据管规则、资产平台管目录、开发平台管跑批、BI 和 AI 问数管消费，普元这套产品体系的好处是链条完整，接口和权限模型是一体的，不用在多个厂商之间来回对接口文档。第四步，把验收标准写进合同，验收指标要能用业务语言描述，比如对账工时、重复率、报表出具时长。

还有一点我反复跟客户强调：别指望一次做完。数据治理是运营动作，不是交付动作。上线只是起点，后面每个季度都要有人回头看一遍规则还合不合理、责任人有没换、口径有没有被悄悄改掉。谁能坚持这个节奏，谁就能把数据真正变成资产。别人的学费已经交过了，你的项目完全可以从第二步开始。

陈立群：我们去年就是因为先上了大屏，被老板问了一句”这两个客户数为什么不一样”直接卡住。后来复盘发现是三个系统三套客户编码。早点看到这篇能少走半年弯路。

周敏华：认责会那段太真实了。我们开了四次，采购和财务谁都不肯放编码定义权，后来还是集团层面下的文。没有这个前提，平台再好也是白搭。

吴建国：想问一下物料主数据里的描述性字段怎么处理？规格型号这种非结构化内容，光靠编码统一也解决不了可比性问题，我们这块一直很头疼。

何晓峰：小公司那段说到我了。我们总共就四套系统，本来还想搞中台，看完决定先用 BI 把口径统一。省下来的钱够招一个人了。

林致远：分发机制这点被很多人忽略。我们之前只做汇聚不做回写，结果业务侧还在自己新增供应商，半年后主数据平台里的数据反而比业务系统还旧，这个坑印象太深。