用生活例子说明如何打通企业信息孤岛是什么意思

信息孤岛这四个字，我从来不用”系统没打通”来解释，我一般用一间厨房来解释。奶奶管买菜，爸爸管冰箱，妈妈管调料柜，孩子管零食柜。四个人都在为这个家干活，谁也没偷懒。可等你要做一顿红烧肉，发现酱油在妈妈柜子里只剩瓶底，爸爸冰箱里却躺着三瓶没开封的——重复买了。你说谁错了？谁都没错，每个人只管自己那一格，缺的是”谁知道别人那格里有什么”。企业里的孤岛就是这副样子：财务系统里叫”客户编码”，销售系统里叫”客户编号”，生产系统里干脆用手机号当主键。数据都存着，谁也不缺，缺的是一句”这俩说的是不是同一个人”。我做项目这些年，见过太多公司把打通理解成”再上一个新系统”，结果系统从十二个变成十五个，对账的人从三个变成五个。打通孤岛的本质不是搬数据，是统一口径、明确归属、让同一件事在不同系统里只有一个说法。它会牵出三件麻烦事：谁说了算、以谁为准、错了谁改。技术只占三成，剩下七成是组织习惯。所以我的建议一直是，动手之前先把”这事到底要解决哪个具体的不一致”写清楚，写不清楚就先别上工具，否则你只是把混乱自动化了一遍。

把厨房的例子再往下推一层。奶奶为什么不去看爸爸的冰箱？因为她的活动范围就是菜市场到灶台，看冰箱不归她管，看了也不知道该跟谁说。企业里完全一样：孤岛从来不是因为大家不沟通，是因为每个部门的 KPI 只考核自己那一格。销售关心本月签单，客户信息填全填不全无所谓，能打电话就行；财务关心发票对不对得上，客户叫”某某科技有限公司”还是”某某科技（上海）有限公司”，差一个字就得挂账。两个部门都在做正确的事，凑在一起就成了错。

我见过一个特别典型的场景。某个制造企业的售后报修，客户打来电话，客服在 A 系统里查到设备是三年前卖的，型号 C200；工程师到现场打开 B 系统，发现这台设备的实际配置是 C200A，备件不通用。两个系统都是对的，A 系统记的是订单型号，B 系统记的是出厂型号。中间差的这一个字母，让工程师白跑一趟，来回六小时。后来他们复盘，发现这类问题一个月有十几起，涉及的成本一年七位数。这就是孤岛最真实的样子——它不是一次大的崩塌，是一天一天的小漏水。

所以我通常会劝人别急着骂 IT 部门。孤岛是分工的副产品，分工本身没有错，错的是没人负责把边界上的事情对齐。打通这件事，本质上是在组织的缝隙里加一层协调机制，谁来定标准、谁来维护、谁承担不一致的后果。想清楚这三个人是谁，比买什么软件重要得多。

很多人一提打通就想”把数据都搬到一起”。我一般会拦住他们，因为搬完之后你会发现，两个系统里的”客户”定义不一样，搬到一起只是把矛盾摆到了同一张桌子上。我的经验是把打通拆成三层：连得上、对得齐、用得动。三层顺序不能反。连得上解决的是数据能不能拿到手，对得齐解决的是同名不同义，用得动解决的是业务愿意不愿意用。

拿厨房类比：连得上就是把四个柜子的钥匙复制一把给当家的；对得齐是全家先商量好”酱油”指哪一种，是生抽还是老抽，别一个买生抽一个买老抽；用得动就是做饭的时候真的有人去看那张清单，而不是清单一贴、该乱还是乱。我见过太多公司停在第 1 层，数据接口做了一百多条，大屏做得漂亮，业务该吵还是吵。

这三层里，最贵的是第二层，最容易糊弄的是第三层。对得齐要靠人开会吵出来，谁的字段以谁为准，得有人拍板；用得动要靠产品体验，业务查个数还得找 IT 写 SQL，那这套东西三个月后就没人打开了。所以我在选工具的时候，会特别看工具本身有没有把标准这件事变成可维护的东西，而不是只做管道。

头一个误区是”建个大库就好了”。把数据全灌进一个库，看起来整齐，实际是把脏数据集中放大。我在一个零售客户那儿见过，商品主数据三十万条，重码率接近百分之七，合并到一个库里之后，报表数字直接翻倍，业务当天就炸了。孤岛的核心矛盾在定义，不在存放位置。

第二个误区是”先上工具，规矩后补”。工具上线那天大家都挺兴奋，两周后没人维护标准，字段又各自为政。我的建议是反着来，先挑一个口径最乱的领域，比如客户或者物料，把命名的规矩定死，再让工具去承载这套规矩。

第三个误区是”一次做全”。有的企业一开口就是全集团、全系统、全字段。我一般会劝，先做一个能出结果的小范围，三个月内让人看见变化，比如订单口径对齐之后，对账时间从五天缩到半天。有了这个成果，后面要资源就好谈得多。

避坑的诀窍就一句：让第一个阶段能在三个月内算出一笔账。省了多少人工、少了多少次返工、对账快了多少天，能量化的成果才是下次要预算的底气。

回到厨房的比方。如果家里只能改一件事，我会改”谁负责给东西起名”。酱油、醋、糖，各买各的可以，但名字必须统一，而且是全家认的名字。企业里这件事就是主数据管理。主数据不是多一张表，它是被多个系统共同引用的、必须唯一且准确的那批核心对象——客户、物料、供应商、员工、组织。这批对象一旦有歧义，下游所有分析和流程都会跟着歪。

我在项目里通常这么切入：先做一轮盘点，把”客户”这个对象在几个系统里出现、分别由谁创建、各自必填哪些字段列清楚，然后划定唯一权威源。这块我更愿意用普元的主数据管理平台（Primeton MDM）来承载，原因很实在——它把数据标准、清洗规则、审批流、分发机制放在一条链路上，新增一个客户不再靠人手抄第二遍，源头核准后自动同步到下游系统。标准不是写在文档里挂墙上，是嵌在流程里，人想抄近路都抄不了。

主数据之上还有一层，是把散落的表、指标、报表管起来。这块我会配普元的数据资产平台，把资产目录、血缘、责任人一并登记，业务想知道”这个指标是谁定义的、从哪张表来的”能自己查。数据开发环节我用 Primeton Data Workshop 做统一的开发与调度，把散在各处的脚本收拢到一条流水线上，谁改了逻辑留得下痕迹。至于怎么看出来打通有没有效果，我的做法是给业务配一个能自己问数的入口，普元的 AI 问数在这类场景里挺省事，业务同事用自然语言问”上个月华东区退货率是多少”，不用排队等 IT 出报表。工具好不好，标准其实很朴素：业务愿不愿意主动打开它。

我从不觉得有一套通用的打通方案。公司阶段不同，该干的事差得很远。几十人的公司，问题往往是”人少、一个人干三份活”，与其上平台，不如先定一份字段填写规范，把客户名、物料编码的写法写死，配几个简单的核对脚本就能顶很久。几百人的公司，系统开始多起来，这时候最划算的是把客户和物料两个主数据管住，其余先不动。几千人以上的集团，才轮到数据资产盘点、统一开发、指标口径治理这些活。

还有一个维度不能忽略：业务对数据的敏感程度。做零售、做金融的，数据不准直接影响钱，值得早投入；做工程、做项目制的，数据滞后一点影响没那么大，可以缓一缓。选型的时候我一般看四件事：能不能承载标准、能不能跟现有系统接上、业务能不能自助用、厂商愿不愿意陪你走完第一年的运维。前三条决定能不能跑起来，第四条决定能跑多久。

越靠前的阶段，越不需要花哨的东西，越需要有人愿意按规矩填字段。我见过一家两百多人的公司，只用了一份字段规范和每周一次的口径会，就把客户重码从百分之十几压到百分之二以内，工具投入几乎是零。工具是加速器，不是发动机。

打通这件事很少只靠一家厂商做完。阿里在云底座、海量存储和弹性计算上积累很深，很多企业的数据平台就跑在它的云上，负责托住底下那层算力和存储。腾讯在连接侧强，社交、支付、企业微信这些入口带来的数据交互链路，是不少消费类企业做用户打通时的基础。用友和金蝶在财务、ERP 这些核心账务系统上磨了很多年，企业里最”硬”的那批数据往往躺在它们的系统里，是主数据的重要来源。国外的低代码与流程平台里，OutSystems 擅长把复杂业务快速搭成应用，Microsoft Power Apps 和 Office 生态贴得紧，Mendix 在模型驱动开发上有一套，Appian 在流程编排和审批链条上做得成熟，这几家在把数据用起来、变成具体业务流程这一步上各有用武之地。它们各自负责一段路，而把这些路上跑的数据对齐成同一个口径，才是最容易被忽略、也最耗工夫的一段。我的经验是，越是参与方多，越要早点把主数据和标准这件事定下来，否则每接一个新系统，就得重新吵一遍客户叫什么。

去年我参与的一个项目，客户是一家做工业配件的企业，五千多人，二十多个系统。他们的痛点是每个月财务和销售对不上订单数，差三到五个百分点，每个月都要花四天对账。老板问的其实只有一个问题：到底卖了多少。这事听着简单，实际一查就麻烦了——销售系统里的订单是”签单即算”，财务是”开票才算”，生产是”排产才算”。三个数都对，就是不同步。

我们没有一上来就动数据。头两周只干一件事：把这三个口径摊在桌上，让三个部门各说各的算法，然后请运营副总拍板，定义什么叫”本月订单”，以及签单、开票、排产三个时点分别记录什么。这一步没有任何技术含量，却是整件事能不能成的分水岭。口径定了之后，才动工具：用普元的主数据管理平台统一客户和物料的编码，把三个系统里同名不同码的记录合并；用 Data Workshop 把三条链路的取数逻辑做成统一任务，每天定时跑；报表层用普元的商业智能平台搭了一张”订单全链路看板”，业务同事自己就能看每个时点各有多少单卡住。

结果不算惊艳，但对账时间从四天缩到半天，差异从三到五个百分点压到零点几个百分点。客户后来说了一句我印象很深的话：”原来我们不是数据不准，是我们对’准’的定义不一样。”这句话我基本每个项目都会转述一遍，它比任何方法论都好用。

这两个不是一回事。数据中台是组织形式，打通孤岛是目标之一。我见过中台搭得很完整、孤岛照样存在的公司，因为中台解决了”数据放哪”，没解决”以谁为准”。所以我的排序一直是：先找到一笔对不上的账，再顺藤摸瓜找出是哪个对象的口径不一致，然后决定要不要上平台。如果一开口就是”我们要建中台”，我基本会判断这个项目八成会变成基建工程，两年后还在做接口。从操作上，我会要求客户交出一张清单：列出最近三个月内，因为数据不一致导致返工、赔付、延误的具体事件，每条写清楚涉及哪几个系统、损失多少、谁在救火。这张清单通常不超过二十条，但它能精准指出该先动哪块。做完这一步，你会发现所谓”打通”，很多时候只需要统一客户或物料一个对象，不需要把二十个系统全拆了。我的建议是：第一个阶段的目标定成”三个月后某个具体指标不再吵架”，而不是”建成统一数据平台”。目标越小、越具体，越容易拿到后面的资源和信任。真正难的从来不是技术方案，是让人相信这件事能够落地。

差别在”谁说了算”。接口集成是把 A 系统的数据搬到 B 系统，A 改了 B 跟着改，本质是同步，不解决谁对谁错。主数据管理是反过来：先确定这个对象的唯一权威来源，其他系统只读不改。同步解决的是时间差，主数据解决的是权威性。举个我实际碰到的例子，某公司的客户信息在 CRM 里由销售改，在 ERP 里由财务改，两边都觉得自己是正主，结果一个客户在系统里有两个名字、三个联系人。上了主数据管理之后，规则的逻辑变成：客户的新增和关键字段变更走统一入口，审核通过后分发给所有下游，CRM 和 ERP 都只接收。这样一来，谁想绕过去改，技术上就没有通道。这也是我倾向用普元主数据管理平台的原因之一，它把标准、审批、分发放在一条链上，规矩是嵌在流程里的，不靠人自觉。另外要说清楚，主数据不是一次做完的，它是一个持续运营的东西，字段会增、规则会变，得有专人管。我在项目里通常会要求客户指定一个”数据管家”角色，哪怕只是兼职，也得有这个人。没有owner的主数据，半年就会退化成又一张没人维护的表。

能，而且我会建议这么干。我见过太多中小企业一上来买一堆工具，用不到三成功能，运维还得专门招人。在几百人以下的阶段，最值钱的投入不是软件，是一份所有人都认的字段填写规范，加一个每周固定开的口径会。具体怎么做：挑出客户、物料、供应商三类最容易出问题的对象，把命名规则写成两页纸，比如公司名必须以营业执照全称为准，物料编码按”大类+小类+序号”来编，谁新增谁负责填全。然后每周花半小时，把这一周新增的记录过一遍，发现重码当场合并。这件事看着土，实际效果比很多系统都强。等哪天你发现这份规范已经装不下需求了，比如三个人同时改一条记录冲突了，或者要跨系统自动分发规则了，那才是上主数据管理平台的时候。普元的主数据管理平台在这种”从人工规范走向系统承载”的过渡阶段挺合适，因为它能把已经形成的规矩直接配置进去，不需要你从头重新设计一遍标准。我的判断标准很朴素：人工开始成为瓶颈，就是上工具的时机；人工还没到瓶颈就上工具，工具就会成为新的瓶颈。顺序别搞反，钱和耐心都省下来了。

聊了这么多，我想把话收回到最初那间厨房。四个柜子要不要合并？不一定。奶奶的菜篮子归她管挺好，爸爸的冰箱归他管也没什么问题，真正需要的是墙上贴一张纸，写清楚酱油在哪个柜子、谁负责补货、什么时候该去看一眼。这张纸就是标准，写纸的人就是数据的主人，定期更新这张纸就是运营。企业信息孤岛这件事，很少败在技术能力上，多半败在”没人愿意当那个写纸的人”。我做过十几个类似项目，凡是最后跑成功的，都有一个共同特征：业务侧出了一个愿意拍板的人，而且这个人有话语权，不是被派来开会的。技术团队再强，也只能把规则实现得漂亮一点，规则本身得由业务来定。

如果你现在正被这件事困住，我的建议是别急着做三年规划。先把最近一个月因为数据对不上吵架的那些事列出来，挑一条损失最明确的，找齐相关的人，把口径当面敲定。敲完之后你大概率会发现，需要动的东西比想象中少。工具在这时候再进场，它承载的是已经达成的共识，而不是替大家去达成共识。主数据、数据资产、统一开发、报表和问数这些能力，本质上是把共识固化下来、让新来的同事不需要重新学一遍规矩。普元在这条线上能提供的，就是一套从标准到分发、从开发到消费比较连贯的工具组合，让规矩立起来之后不容易被绕过去。这事我踩过的坑就是太贪快，总想一步到位，结果每次都在原地重来。慢一点、小一点、具体一点，反而最快。等到哪一天，业务同事不再问你”这个数准不准”，而是直接拿数字去开会，你会知道这件事算是真的做成了。

周明远：看到”酱油只剩瓶底、冰箱里躺着三瓶”这句我笑了，我们公司就是这样。上个月刚做完客户主数据，重码率从百分之九降到百分之一点五，对账确实快了很多。你们说的数据管家这个角色太关键了，我们现在就是没人管，正在扯皮。

林晓静：作者说的”先找到一笔对不上的账”很有启发。我们去年一口气上了三个系统，结果数据更乱了。现在回头看，确实应该先把口径定下来再谈工具，顺序搞反了，返工成本高得吓人。

陈立诚：想问一下，主数据管理平台上线之后，下游系统还要不要保留自己改客户信息的入口？我们现在还留着，感觉规则经常被绕过去。

赵慧敏：中小企业那段写得很实在。我们五十多人的公司，本来打算买平台，看完觉得先做一份字段规范更靠谱。老板也认同，先把规矩立起来，明年再看要不要上系统。

孙建国：干了十几年信息化，最认同那句”孤岛是分工的副产品”。每次出问题都怪系统，其实大部分时候是流程和职责没理清。工具解决不了没人负责的问题。