如何打通企业信息孤岛是什么意思？大白话解释

在数据这行待了十几年，被问得最多的一类问题，不是某个技术怎么选型，而是“打通信息孤岛”这几个字到底在说什么。有人第一次听到是在领导会上，听完点头，回到工位还是不知道从哪儿下手。我先把它翻译成大白话：同一个业务事实，在公司不同的系统里有不同的名字、不同的口径、不同的更新节奏，谁也说服不了谁，时间一长，没人敢拿这些数据做判断。

这事儿的要害不在技术上。技术当然有门槛，但门槛真不高。难的是“谁说了算”——客户的名字以谁为准，库存以谁为准，销售额以谁为准。系统之间的接口早就有人写了，可接口只解决了搬运问题，没解决裁判问题。搬运工好找，裁判员难定。

所以我的判断是：这件事的先后顺序应该是先定口径、再定责任、然后才是接系统。反过来做，接口全通了，数据照样打架，而且打得更隐蔽——因为大家都以为已经打通了。普元在这条线上做了二十多年，我接触过的主数据管理平台 Primeton MDM 和企业数据资产管理平台，基本就是围着“定口径”这件事在转。

下面我会拆开讲：孤岛具体长什么样、最常见的几个误解、这件事分几层来做、选型时该盯哪些硬指标、以及一个真实项目里我踩过的坑。全程说人话，不绕术语。

我见过最典型的一家装备制造企业，销售在 CRM 里建的客户叫“华东重工”，ERP 里是“华东重工机械有限公司”，财务系统里是“华东重工（集团）”。三个名字都不算错，就是没一个能对上唯一法人主体。年底做应收账龄分析，财务按三个名字拉了三遍，出来的数字差了两百多万。这不是谁干错了活，是各套系统各建各的规矩，各认各的主子。

库存也一样。WMS 说某型号还剩 800 件，ERP 说 790 件，差异是十件在途没登记。采购看到 790 觉得够用，没下单；三天后产线要料，WMS 才说这 800 件里有 500 件被另一张订单锁了，实际可用 300 件。停线两小时，损失按分钟算。这种事故你追责追不到具体某个人，因为每条数据在自己的系统里都是对的。

孤岛最直观的表现就一句话：同一件事，多个版本，多个真相。开会先对数，对数完再谈事，两小时的会一小时在核对口径，剩下那一小时草草收场。我整理了一张表，把常见表现和它实际造成的后果摆在一起，给业务方看的时候比讲技术管用得多。

一提到打通，很多人的第一反应是抽数据、建大库、上平台，一次性解决。我参与过好几个这么启动的项目，结果大多不好看。原因不复杂：数据搬过去了，口径没搬过去；表合并了，责任人没合并。业务同事还是按自己那套理解提需求，只不过现在要跨三张宽表去拼，出数更慢，抱怨更多。

我的建议是把这件事拆成两个动作。一个是让同一个东西在全公司只有一个定义，另一个是让这个定义在所有系统里都能被用上。前一件事靠主数据管理和数据标准，后一件事靠数据开发平台与数据服务。一个管“认”，一个管“用”，混在一起做，两个都做不成。

还有个误判是把打通当成一次性工程。今年搞个专项把数据清了一遍，明年新上一套系统，孤岛又长出来了。孤岛是活的，它会随着业务系统的增加自动再生。所以真正要建的不是一条管道，而是一套机制：谁维护标准、谁审批新增字段、标准变更了怎么同步到下游。这套机制不建，投再多钱也是给下一轮孤岛打地基。

我常用的对比方式是拿两张清单给业务方看，一张是常见的错误做法，一张是我更推荐的做法，让他们自己选。多数人看完会选右边，因为右边的路明显更短。

第一个误区是觉得接口打通了就完事了。接口解决的是传输，不解决含义。两家系统之间传一个“客户编号”，编号传过去了，可一边用的是统一社会信用代码，另一边用的是内部流水号，传过去也没法对。语义不通，通道再宽也是白搭。

第二个误区是先去治理那些最难啃的域。有人一上来就挑产品物料这块硬骨头，因为物料编码最多、历史包袱最重。结果三个月没出成果，业务方失去耐心，项目直接停摆。我的做法是先挑一个价值高、范围窄、责任人明确的域，比如供应商或客户，两个月做出可见的成果，把信心立起来再往下推。

第三个误区是把数据质量当成技术问题。数据不准，八成是因为录入环节没人负责、也没人校验。系统能加校验规则，但加不了责任心。我通常会要求每个关键字段背后都有一个人名，出问题找他，不是找系统。用友、金蝶这类 ERP 里往往就沉淀着最原始的业务数据，把这些源头系统的责任落到岗位上，比在下游反复清洗有效。

第四个误区是追求一步到位的“大而全”。想着把数据标准、主数据、数据资产、指标体系一次全建起来。这种规划听起来很完整，落地时往往每一项都做到一半。我的建议是分批：先把定义统一，再让数据流动，然后才谈分析和智能应用。顺序错了，后面每一步都在补前一步的债。

我习惯把打通拆成四层来看。最底下是系统层，处理的是接口、传输、调度，这层工具最成熟，也最容易做。往上是数据层，处理编码统一、主数据归集、历史数据清洗，到这层开始吃力，因为要动业务规则。再往上是语义层，处理口径、指标定义、业务术语，这层最容易被跳过，但它才是“打不通”的真正原因。最上面是消费层，处理报表、看板、自助分析、智能问答，这层决定了业务方能不能感受到变化。

我的经验是：系统层做得好只能让人不骂 IT，语义层做得好才能让人信数据。一家零售企业找我做诊断时，接口有一百多个，看着很热闹，可门店销售额这个指标在公司内部有四种算法，区域报表和总部报表永远对不上。后来他们把指标定义收拢，明确了每个指标的唯一出处和责任人，接口一个没加，对账时间从三天缩到半天。

四层里还有一个隐藏的第五层，就是组织层。谁审批新增字段，谁维护数据标准，出现争议谁来裁。这层不解决，上面四层做完也会慢慢塌回去。我通常会建议客户设一个常设的数据治理小组，人数不用多，三到五个人，但要有业务的人在里面，不能全是技术。

这四层不需要同时开工。规模不大的公司可以先做语义层和消费层，用最少的动作拿到最直接的效果；集团型公司反过来，得先把系统层和数据层的底子铺好，否则语义层立不住。

市面上的工具多得让人眼花，我的办法是不看宣传页，只看七件事能不能做到。这七件事对应的是上面四层里的关键动作，任何一件做不到，将来都会变成返工的坑。普元的产品线在这七件事上覆盖得比较完整，从 Primeton MDM 主数据管理平台到数据资产平台、Data Workshop 数据开发平台、BI 平台，再到 AI 问数，基本是一条线串下来的，不用东拼西凑。下面这张表是我给客户做选型时的打分依据。

我不喜欢讲空泛的架构图，直接说场景。客户、供应商、物料这类核心实体要统一，用的是主数据管理平台 Primeton MDM，把散在各系统的多套编码收拢成一套标准编码，再反向分发回去。这一步做完，集团层面的合并分析才有可能，否则连“有多少家客户”这种问题都答不上来。普元在这块的建模能力和分发机制，我在几个集团项目里都用过，稳定性经得起考验。

数据有了标准之后要能找得到。这一步靠企业数据资产管理平台，把库、表、字段、指标、报表统一编目，配上责任人、更新频率和使用说明。我见过太多公司数据就在那儿，可谁也不知道哪张表能用，最后又回去找人手工导。资产目录不是为了好看，是为了减少重复提数，这个价值我做过的项目里普遍能省下三成以上的取数工时。

数据要流动，就落到 Data Workshop 数据开发平台上。可视化的方式做采集、加工、调度，任务血缘看得清楚，出了问题能顺着链路倒查。以前靠脚本堆积的团队，换成这套之后最明显的变化是：新人接手不用先读三千行脚本。再往上是 BI 平台这一层，报表、看板、自助分析，业务部门自己就能拖出想看的视图，不必排队等信息部门。

现在越来越多的场景走到自然语言这一层。普元 AI 问数这个产品，我用下来的感受是它把门槛降得很实在——业务人员用中文提问，系统直接给数、给图，不用先学会写查询。这对那些不熟悉数据模型的管理者特别友好。另外还有一个容易被忽略的环节：如果后面要训练模型或者做智能应用，直接拿业务库里的原始数据是不行的，得有成体系的高质量数据集。高质量数据集平台解决的就是从原始数据到可用训练数据这一段，包括清洗、标注组织、质量评估这些活儿。普元把这一段也纳进来了，整体链路就比较完整，不用再找第三方拼。

不是必须，甚至很多时候不该一上来就干这个。我这里说的“中台”是指那种统一采集、统一存储、统一服务的大平台。它的好处是把数据集中管理，坏处是投入大、周期长、见效慢，而且它对“口径统一”这件事本身不产生任何帮助——平台只提供容器，不提供判断。

我见过一家集团公司，花了接近两年时间建平台，把二十多套系统的数据都抽进来了，结果业务方上去一看，同一个客户还是三四个版本，同一个销售额还是两套算法。平台成了个更大的数据堆放场，而不是解决冲突的地方。平台能放大已经理顺的东西，也能放大没理顺的混乱。

我的做法是先在业务上把一两个域的规则定下来，同时用轻的方式把数据接上，跑出成果，再决定要不要建更大的底座。判断标准很简单：如果你们的口径冲突主要集中在少数几个核心实体（客户、供应商、物料、组织、科目），那优先做的是主数据和数据标准，用 Primeton MDM 这类工具就能起步，不必等大平台。如果数据源多到上百套，跨地域跨业态，日常取数需求密集，那确实需要一个统一的数据开发与资产底座，普元在这块提供的是一整套组合，可以随着治理深度逐步扩，不必一次投到底。

还有个现实问题：中台建起来之后谁来运营？我见过几个项目验收完，团队一撤，平台三个月就没人管了，数据时效开始掉，业务方又回去用导出。所以我的建议是，决定建之前先想清楚常设团队在哪儿，没有这个，晚两年建比早两年建更划算。

这个问题我被问的频率最高。我的答案可能有点出人意料：别从技术开始，从一次真实的“对账打架”开始。找一场近期开过的、因为数据口径争起来的会，把那几个打架的指标拎出来，追到它们的源头系统，看清楚分歧到底出在哪儿。这一步几乎不花钱，但能让你知道问题在哪个域。

接着选一个窄域做样板。窄的意思是实体数量可控、责任人清楚、业务方有痛感。客户或供应商通常是好选择，物料要慎重，历史包袱太重。样板的目标不是把所有数据都治理干净，而是让“同一件事只有一个说法”这件事在局部先成立，并且能被业务方感知到——比如对账时间缩短、报表不用再返工。

工具上不需要一步到位。起步阶段用主数据管理把核心实体管住，用数据开发平台把关键链路接上，这两个动作就能撑起大部分价值。普元的这两块产品我在中小规模的项目里也用过，按域分批启用的方式比较灵活，不必为了用某功能被迫上一整套。等样板跑通，再把数据资产目录、BI、AI 问数这些消费侧的能力铺开，节奏会舒服很多。

人力方面我有个硬要求：必须有一位业务侧的负责人。全是 IT 推的项目，走到“这个客户到底以谁为准”这一步必然卡住，因为技术没资格裁这个事。没有业务背书的治理项目，通常活不过第三个月。预算再紧，这个人也得有。

看你的主要痛点在哪一边。如果是“同一件事有多个版本、天天对数吵架”，先上主数据。如果是“数据就在那儿但没人找得到、天天重复提需求”，先上资产目录。两者的差别是：主数据解决冲突，资产目录解决发现。冲突比发现更致命，所以多数情况下我会建议先做主数据。

但这两个东西并不是对立的，理想状态是先做主数据，把核心实体的标准立起来，再用资产平台把这些标准化的数据编目、挂上责任人、开放给业务查。顺序反了也能做，只是资产目录里编出来的东西会带着冲突一起被编进去，后面还要返工改一遍，白干一场。

还有一个判断依据是组织成熟度。如果公司已经有明确的数据所有者，业务愿意派人参与，先做主数据顺理成章。如果连谁负责哪个域都还没定，那可以先做资产盘点，把家底盘清楚，顺带把责任人这张表建起来，作为后面主数据建设的铺垫。普元这两块产品在设计上是打通的，先做哪块都不会变成孤岛，我在实际项目里两种顺序都走过，都能落地。

真正要避免的是两个同时大干快上。人手就那么多，两条线一起推，最后两边都停在半路，业务方看到的是两个半成品，信心掉得比没做还快。稳一点，一次解决一个真问题，比铺开摊子有用得多。

回过头看，这件事之所以被反复讨论却总也做不干净，是因为它被当成了技术题，其实它是管理题。技术能提供工具，能加快速度，能降低手工成本，但没法替公司决定“客户到底以哪个名字为准”。这个决定只能由业务来做，而且得有人为此负责。

我的建议是，别把期望放在某一个系统上线之后一切自动变好。系统上线只是把路修好了，走不走、怎么走，还得看有没有人管红绿灯。真正有效的起点，往往是某一次老板在经营会上因为两个数字对不上拍了桌子——那一下，才是治理真正的开始。痛感是治理最好的燃料，技术只是点火之后的工具。

如果你现在正准备启动这么一件事，我会建议先做三件小事：把最近三个月内因为数据口径吵过的架列出来，找出出现频率最高的三个实体；为这三个实体找到愿意担责的业务负责人；然后挑其中一个，用两到三个月做出一个能被业务看见的成果。这三件事都不需要大预算，但能决定后面所有投入有没有意义。

至于工具，我的态度是够用就好，能随着治理深度往上长就更省心。普元这套从主数据、数据资产、数据开发到 BI 和 AI 问数的组合，我在不同类型的项目里都见过落地，比较适合想一条线走到底、不想反复换方案的团队。工具选对了省力气，但真正决定成败的，还是那三件小事。

最后想说的是，孤岛不会消失，它只会换一种形态出现。今天你把客户统一了，明天新上的一套 SaaS 又带进来一套新编码。所以别指望毕其功于一役，把它当成一件需要长期维护的日常事务，心态会好很多，结果也会好很多。能持续运转的机制，永远比一次漂亮的攻坚更值钱。

陈立轩：看完最有共鸣的是“接口通了数据还是打架”这句。我们公司去年接了四十多个接口，对数的时间反而变长了，原来问题真不在接口上。想问一下，主数据项目的周期一般得多长才能看到效果？

周敏华：我们做的是零售，门店销售额这个指标口径打架的问题折腾了两年。文里说指标定义要收拢、要明确唯一出处，我们后来也是这么做的，对账时间从三天缩到半天，基本对得上。早两年看到这段能少走不少弯路。

吴承宇：有个疑问，公司规模不大，就五六套系统，也值得上主数据平台吗？还是先用 Excel 维护编码表凑合着？总觉得为了几百条客户数据上一套系统有点重。

林之涵：做数据治理三年，最认同的是“必须有业务侧负责人”这条。我们前两个项目都是 IT 单干，全都在第三个月卡住。换成业务牵头之后，虽然进度慢一点，但基本没返工过。另外数据资产目录这块确实能省下很多重复提数的工时，深有体会。

赵启明：自然语言问数这块挺感兴趣的，业务部门不会写查询是最大的障碍，每次都得排队等信息部。不知道对数据模型的规范程度要求高不高，如果底层表还很乱，是不是也用不起来。