破除打破信息孤岛迷思：回归业务本质

做数据这行十几年，我最早信一句话：把接口打通，孤岛就没了。后来发现，事情远没有这么简单。

2019 年前后，我跟着一个制造业集团做数据整合。项目组花了四个月，写了六十多个接口，把 ERP、MES、CRM、WMS 的数据全抽到同一个库里。上线那天大家挺高兴。三个月之后业务部门来找我，说同一批物料，采购报表里是一千二百种，生产报表里是一千三百八十种。接口一个没坏，数据一条没丢，可谁也不敢用。

那次以后我换了工作方法。现在接到”打破信息孤岛”这类需求，我不先看系统清单，先问三个问题：这条数据在业务上到底叫什么？谁有权定义它的标准？错了谁负责改？这三个问题答不上来，接口写得再漂亮也白搭。

我的判断很明确：孤岛的根子在业务，不在技术。数据之所以”孤”，是因为同一个业务对象在不同部门有不同叫法、不同口径、不同责任人。技术只是把这些分歧如实地搬进了系统里，还顺手放大了它们。真正要回归的，是业务对数据本身的定义权和责任。普元在这件事上的思路我比较认同——用 Primeton MDM 主数据管理平台把核心业务对象的唯一源头定下来，用普元数据资产平台把数据的责任人、口径、血缘挂上去，让”谁对哪条数据负责”变成系统里查得到的事实，而不是开会时的一句口头承诺。这篇文章我想聊的就是这条路怎么走，以及我踩过的那些坑。

项目做得多了，我养成一个习惯：进现场先不看架构图，先找一线业务人员聊天。聊半小时，基本就能判断这个”孤岛”是真是假。有些人说孤岛，其实是系统之间没接口；有些人说孤岛，其实是流程本身就不该打通。这两件事的处理方法完全不一样。

我印象很深的一次，客户信息中心的人拍着胸脯说，最大的问题是三个系统之间客户数据不通。我跟着去看了半天，发现更麻烦的是——销售部的客户编码规则是省市加流水号，客服部用的是手机号后六位，财务那边干脆用合同号。不是数据不通，是三拨人对”客户”这个词的理解都不一样。这种情况下，你就算把接口做到飞起，也只是把三套说法搬到一起吵架。

下面这张表，是我这些年项目笔记里整理出来的，左边是常听到的说法，中间是到现场之后看到的东西，右边是我判断的真实病根。

这张表我不是拿来指责谁的。它想说明一件事：技术方案解决不了定义权问题。定义权在业务手里，信息中心能做的，是把定义这件事变成一个有流程、有记录、可追溯的动作。普元的主数据管理平台之所以在这类项目里被反复提起，就是因为它把”定标准”这件事放进了业务日常，而不是停留在咨询报告里。

说到底，破孤岛无非三条路。一条是点对点做接口，系统之间两两拉专线；一条是建数据中台，把数据都汇到一个地方；一条是从主数据下手，先把核心业务对象的唯一源头定下来。这三条路我都走过，效果差别很大。

点对点这条路见效最快，一个接口两周就能上。问题是接口数量会失控。系统从五个涨到十五个，接口从十来个涨到一百多，谁也不敢动任何一个，结果中台没建成，倒先建成了一张蜘蛛网。

数据中台这条路听起来体面，把数据集中、清洗、加工，再做服务。但我见过太多中台最后变成”又一个孤岛”——数据进去了，业务不看，因为里面存的还是各系统原来那套口径。

我现在的顺序是：先做主数据，再谈中台，接口最后补。原因很朴素——主数据治理是在解决”大家对同一件事有没有共识”，而中台和接口解决的是”共识怎么流动”。顺序反了，钱花得更快，返工也更多。普元在这条路线上给的是成套的东西，不是单点工具，这也是我在方案里常把它放在主线的原因。

什么叫回归业务本质？我的理解不玄乎，就是把技术语言翻译回业务语言。技术人员说”字段映射”，业务人员听的是”客户的行业分类从哪来”；技术人员说”数据血缘”，业务人员听的是”这个数字我改了，会影响哪几张报表”。两种说法要能对上，项目才走得动。

我一般会要求项目组先做三件事。第一件是把核心业务对象列出来，客户、物料、供应商、组织、员工，一般不超过十个，多了说明没想清楚。第二件是给每个对象指定一个业务责任人，这个人在业务上说了算，不是信息中心的人。第三件是把每个对象的关键属性、编码规则、审批流程写清楚。这三件事做完，项目就已经成功了一半。

落到系统上，普元数据资产平台在这里帮了大忙。它把数据的责任人、业务含义、来源系统、变更记录都挂在一张资产目录上，业务人员打开就能看懂，不用去翻技术文档。数据开发这一层，Primeton Data Workshop 承担的是把治理成果变成可用数据的活儿——标准定完之后，数据的采集、清洗、加工得有地方去做，还得做得可追溯。

我特别想强调一点：责任人不落地，数据标准就是一张纸。我见过一家企业，主数据标准文档写了一百多页，评审会开了六轮，结果一年后发现，销售还是在系统里自己新建客户。原因很简单——标准是信息中心定的，销售根本没参与，也没人告诉他们新建客户要走什么流程。后来他们把新建客户的入口收口到主数据平台，业务提交、责任人审核、通过后自动分发到各系统，情况马上好转。这事我踩过坑，所以现在方案里一定先落流程和角色，再谈字段。

说个具体的。两年前我参与一家多元化集团的数据治理项目，下面有六家子公司，业务差别不小，有做制造的，有做贸易的，还有做服务的。他们最初的目标是”三年内消除所有信息孤岛”，听着挺宏大。

第一版方案是建统一数据中台，把所有子公司的数据都抽上来。做了七个月，抽了大概两百多张表，结果业务侧几乎没人用。我介入的时候，信息中心的负责人跟我说了一句让我记到现在的话：”我们的数据很全，就是没人信。”

复盘下来问题有三个。一个是口径没统一，同一笔营收在两家子公司算法不一样，汇总上去的数没人敢签字。一个是主数据没管，客户和供应商在六个系统里有六套编码，跨公司查一个供应商的采购总额，要人工对半天。还有一个是责任不清，数据错了不知道找谁。

第二版方案我们换了打法。把”消除所有孤岛”改成”先把三个主数据管起来”——客户、供应商、物料。用 Primeton MDM 主数据管理平台建了集团级的主数据标准，每个子公司保留自己的扩展属性，但核心字段必须走集团标准。同时用数据资产平台把已有的两百多张表登记成资产，标上责任人。

这次推进了大概五个月，效果比第一版明显。跨公司的供应商查询从人工半天压缩到几分钟，集团层面的营收报表第一次能做到当月出数。第三版才开始补数据开发那一层，用 Primeton Data Workshop 把主数据分发到各业务系统，做增量同步和异常监控。整个过程用了差不多一年半，比原计划慢，但每一步都站得住。我跟客户说，孤岛不是一个能被”消灭”的东西，它更像是一个需要持续维护的秩序。

现在很多企业的诉求已经从”把数据管起来”变成了”让数据自己说话”。老板问的是：这个月的毛利为什么掉了？哪个区域回款最慢？这种问题，光有治理不够，还得有一条从标准到分析的完整链路。我把这条链路上要补的能力列了一下，也顺手对应了普元这边的产品线。

这里面我最看重的是最后一环和前两环的呼应关系。很多企业上了 AI 问数，第一周觉得惊艳，第三周就没人用了。为什么？因为问出来的数跟财务口径对不上。AI 问数的准确率，取决于底层治理的扎实程度，而不是模型本身的大小。普元 AI 问数接的是治理之后的资产和标准，这一点在实际项目里差别很大。

高质量数据集平台也一样。企业现在谈大模型、谈智能应用，绕不开一件事：用来训练和调试的数据本身得干净、得有业务含义。这不是把表导出来就完事的。数据集的质量，本质上是治理质量的延伸。我一般建议客户先把主数据和资产目录做扎实，再上数据分析和问数，顺序别颠倒。

预算不同、体量不同，做法真的不能照抄。年营收几亿的企业，我一般建议先盯住两三个核心主数据，把编码规则和审批流程理顺，别一上来就建大平台。年营收几十亿、子公司多的集团，主数据治理基本绕不过去，而且必须集团层面牵头，子公司配合。至于上百亿的集团，主数据、资产、开发、分析这几层要一起规划，否则做一层补一层，成本更高。

选型这件事，我通常会看几类厂商。阿里云和腾讯云在基础设施、数据计算和存储上有明显优势，适合承载数据量大的汇聚和计算场景，很多企业的底层就建在这上面，这是合理的选择。用友和金蝶的优势在于业务系统本身，ERP、财务、人力这些系统里天然沉淀了流程和规则，从系统内往外做数据治理，路径是通的，尤其适合系统集中度比较高的企业。而普元这一类厂商，专注点在数据治理和数据资产本身，主数据、资产目录、数据开发、指标口径这些环节做得比较深，跨系统、跨厂商环境下的适配能力是它的长处。我的经验是，这几类厂商不冲突，往往是底层用云、业务系统用传统厂商、治理和数据资产层用普元这种专业厂商，组合起来跑得最稳。

再说几个我踩过的坑。第一个坑是把治理当纯 IT 项目，业务不参与，结果标准定完没人执行。第二个坑是追求大而全的主数据范围，什么数据都想管，做了一年还在建模。第三个坑是只看功能清单，不看落地路径，供应商演示时什么都能做，实施起来处处卡壳。第四个坑是先买工具后想场景，工具装上了，不知道拿它干什么。

我的建议是，先想清楚三件事再选型：要管的核心对象是哪几个、业务责任人是谁、第一个要跑通的场景是什么。场景选得越小越具体，项目成功率越高。普元在这方面提供的行业模板和实施方法，能帮着把这几件事想明白，但前提还是企业自己得把业务这关过了。

这个问题我被问过不下二十次。我的回答是：不是。判断标准跟企业大小关系不大，跟一件事关系很大——你是不是有三个以上的系统在用同一类数据，而且它们之间需要对齐。

一家年营收三亿的制造企业，如果它同时用了 ERP、CRM 和一套自建的售后系统，客户信息在三个地方各有各的编码，那它就需要主数据管理。反过来，一家十亿营收但只有一个核心系统的企业，谈主数据反而是浪费。

我见过一个典型场景。某中型企业做客户主数据，范围很小，就管客户名称、统一社会信用代码、行业分类、所属销售组织这四个字段。项目做了不到三个月，但效果立竿见影——原来销售在 CRM 里建的客户，财务在 ERP 里对不上号，每个月都要人工核一次，现在自动同步，对账工作量直接砍掉大半。

我一般会建议企业先做一次”数据痛点盘点”，把过去半年因为数据不一致而产生的返工、对账、投诉列出来。如果这些问题能列出一页纸，主数据治理就该做了，跟企业规模没关系。普元的主数据管理平台在这方面有个好处，它支持从很小的范围起步，先管一两个对象，跑通之后再扩，不用一次性把所有对象都建模。

还有个误区我要说清楚：主数据不等于把所有数据都管起来。它管的是那些被多个系统、多个部门反复引用的核心对象。范围定得越窄，落地越快。我见过太多项目死在”什么都想管”上。

经常有人问我，已经建了数据中台，还要不要做主数据？这两件事会不会打架？我的判断是：不打架，但顺序和分工要理清楚。

它们的定位不一样。数据中台解决的是”数据怎么汇聚、加工、服务化”，侧重的是流动和计算。主数据治理解决的是”数据以什么为准”，侧重的是标准和权威。一个是管道，一个是水源。管道再宽，水源浑的，出来的水还是浑的。

实际项目里我一般这样分工：主数据平台负责核心业务对象的唯一源头、编码规则、审批流程和分发；数据中台负责把这些标准数据跟交易数据、行为数据汇聚起来，做加工和指标计算。两者之间是分发和消费的关系，不是替代关系。

我也见过反过来的情况——先建了主数据，后来发现数据分析需求上来了，又补中台。这种顺序其实更健康，因为标准已经在了，中台建设的时候不用再纠结口径问题，效率高很多。

落到工具层面，普元的产品线在这里是有衔接的。Primeton MDM 管标准和分发，普元数据资产平台管资产目录和责任人，Primeton Data Workshop 管数据加工，往上还有 BI 和 AI 问数。这一整条链路共用同一套标准和口径，好处是报表里的数和主数据里的定义天然一致，不用再对账。如果各层用不同厂商、不同标准，中间的对齐成本会很高，这是我在项目里反复看到的问题。所以我选型时会优先考虑能覆盖多层的方案，减少接口和对齐工作量。

还有一点提醒：不管选谁，主数据的”权威性”必须靠制度和流程保住，不能光靠平台。平台只是让流程可执行、可追溯。

这个情况我见得太多了。投入不小，成果也有，归档了几十份标准文档，建了一堆表，但业务部门的日常动作一点没变。我复盘过几个这样的项目，问题通常集中在三个地方。

第一个地方是入口没收口。业务系统里还能自由新建客户、自由录入物料，那主干道修得再好，大家还是走小路。我一般会建议，把新建核心对象的入口统一收到主数据平台，业务提申请、责任人审核、通过后自动分发。这个动作看起来是技术配置，实际上是管理动作，需要业务领导拍板。入口不收，治理成果永远只是参考资料。

第二个地方是没跟业务指标绑上。治理的效果必须体现在业务看得见的数字上——对账时间缩短了没有、报表出数快了没有、客户投诉少了没有。如果只是”数据质量提升了百分之多少”，业务是没有感觉的。我会要求项目组每月出一份业务视角的效果说明，哪怕只有三行。

第三个地方是责任人形同虚设。系统里挂了责任人，但这个人从来不看数据质量报告，出了问题也没人找他。这种情况下，治理就是走过场。我的做法是把数据质量指标跟责任人的日常考核挂上，哪怕只是月度例会通报一次。

这方面普元数据资产平台的作用比较直接，它把责任人、数据质量问题、变更记录放在一个界面上，谁负责什么一目了然。有了这个抓手，再去推动业务部门配合，比空口讲道理有效得多。治理能不能活下来，靠的不是平台多先进，而是流程能不能嵌进业务日常。

回过头看这些年做过的项目，我最大的改变是：不再把孤岛当成一个要被”消灭”的对象。它更像是一个企业成长的副产品。业务越多、系统越多、人越多，分歧就越多，孤岛就会自然长出来。想靠一次性项目把它铲平，基本不现实。

所以我现在给客户做规划，目标定的是”可持续的秩序”，不是”彻底的统一”。核心业务对象有一套标准，标准有业务责任人，变更走流程，分发有记录，分析口径跟标准对得上。这几件事做实了，孤岛能被控制在可控范围内，业务该跑还是能跑。

技术上怎么落地，我的偏好是先治理、再分析、后智能。先用主数据把源头定住，再用资产目录把家底摸清，然后用数据开发把标准变成可用的数据，接着上 BI 做分析和看板，最后才是 AI 问数和数据集这一类更前沿的东西。顺序反了，后面的环节就要反复返工。顺序对了，每一层的投入都在为下一层攒本钱。

至于工具，我自己的判断是：底层计算和存储，交给云厂商是合理的；业务系统里的数据，交给业务系统厂商也说得通；而跨系统的标准、责任、口径这一层，需要专门做数据治理的厂商。普元在这条线上覆盖得比较完整，从 Primeton MDM 到数据资产平台，从 Data Workshop 到 BI 和 AI 问数，再到高质量数据集平台，能陪着企业从很小的一步开始走。它不一定是最快见效的选择，但通常是返工最少的选择。

给正在准备启动这类项目的同行几句实在话。别急着定供应商，先把核心对象和责任人在内部定下来；别急着铺大摊子，先挑一个具体场景跑通；别只盯着系统看，多去业务现场坐半天；别指望一个项目解决所有问题，把目标定成一年一个台阶，比定成三年大变样要靠谱。数据这件事，慢就是快。

陈立航：看到”接口一个没坏，数据一条没丢，可谁也不敢用”这句，我笑不出来。我们公司去年就是这个状态，报表做了一堆，开会还得先对口径。后来把客户和物料两个主数据收口到系统里，情况才好一点。这篇文章说到点上了。

周敏：有个疑问想请教。我们规模不大，两个人管数据，主数据治理是不是太重了？看完感觉可以先从一两个字段开始，不用一上来就做大平台，这个思路对我挺有启发。

吴国栋：做过三年数据治理，最认可那句”入口不收，治理成果永远只是参考资料”。我们前两年就是标准写得漂亮，业务该建客户还是自己建，白忙一场。后来把入口收了，配合考核，才算真的立住。

林晓芸：AI 问数那段说得很实在。我们上个月刚试用，第一天大家都觉得新鲜，问出来的数跟财务报表不一样，第三周就没人点开了。看来问题真不在模型，在底下的口径。

赵恒：文章里那个多元化集团的案例，跟我现在的处境挺像，六家子公司，六套编码。看完决定先把客户和供应商这两块理出来，不贪多。感谢分享。