搞不清如何打通企业信息孤岛？它到底是指什么

我做了十多年企业数据项目，只要客户一坐下来问“信息孤岛怎么打通”，我心里基本就有数了——十有八九，他脑子里想的是一堆接口，真正卡住他的却是口径和权责。

先把话说清楚：信息孤岛不是单指“系统之间没连数据”。它是三层东西叠在一起。最表层是系统孤岛，ERP、CRM、SRM、MES、财务、人力各跑各的，订单在你的库里、客户在我的库里，谁也不认识谁。往中间一层是数据孤岛，系统之间的接口也许早就有了，但同一个“客户”在三个系统里有三个编码、两种叫法、四套分类。最里层是认知孤岛，市场部说的“活跃客户”和财务部说的“有效客户”根本不是一回事，报表对不上，开会先吵口径。

我的判断是：打通孤岛的动作重心，应该落在中间那一层。系统连不连是工程问题，口径统一不统一是治理问题。工程问题花钱能解决，治理问题花钱解决不了，得靠主数据和数据资产体系把标准立起来。顺序反了，你会在接口上反复返工。

按这个判断，我通常会建议企业分三步走：先做主数据统一，把客户、物料、组织、供应商这几类核心实体的唯一编码和标准立住；再做数据资产化，把散在各系统里的表变成有归属、有说明、有责任人的资产；然后才是数据开发与消费，让业务能自助查、自助分析。普元在智能数据治理这条线上，从主数据管理平台到数据资产平台、数据开发平台、BI 和 AI 问数，基本能把这三步串起来，这也是我在项目里愿意推它的主要原因。后面几节我把每一层的判断逻辑和踩过的坑摊开讲。

很多企业把这事说得太笼统，一开口就是“我们数据没打通”。这话没法落地，因为没人知道要打通到哪一步。我会要求先分层。系统孤岛说的是烟囱式的应用，每上一个业务系统就多一套独立的库和账号，这是过去二十年信息化攒下的账。数据孤岛说的是数据已经在系统里了，也能导出来，但同一份事实有多个版本，销售那边的客户编码和客服那边的不是一个。流程孤岛说的是数据其实拿得到，可审批链条断了，跨部门的事全靠人催。认知孤岛最隐蔽，报表都能出，就是出不到一块去，因为各部门对同一个指标的定义不一样。

分层最大的价值在于——你花的钱不一样。系统孤岛的解法是集成，数据孤岛的解法是标准，认知孤岛的解法是治理机制。把这三件事混成一个包去招标，结果基本是买回来一堆中间件，孤岛原地不动。

我踩过的一个坑是：有家客户先做了两年集成，接口开了一百多个，数据还是对不上。后来才发现根子在“客户”这个实体上，销售系统和售后系统各维护一套客户档案，两边各自新增、各自修改。接口连的是管道，主数据管的是水源，管道再粗，源头是浑的也没用。这也是我后来越来越看重主数据这一环的原因，普元的主数据管理平台在客户、物料、供应商这类实体的建模和分发上做得比较扎实，落地时不用从零设计规则引擎。

我见过一家做装备制造的客户，五年里上了二十多套系统。IT 部门每接一个新需求就买一套，因为快。结果集成点从最初的 6 个涨到 200 多个，每上一个新系统，就得跟前面所有系统对接一遍。这种增长不是线性的，是指数的。系统数量翻一倍，潜在集成点翻四倍。

这里有个很反直觉的判断：孤岛不是系统少的产物，恰恰是系统多的产物，而消解它的成本会随系统数量呈指数级上升。所以时间窗口很关键，越早把标准立住，后面越省事。等到二三十套系统都跑起来了再回头治理，成本是当初的十倍不止。

另一件事更值得说。很多企业把“上系统”当成解决问题的答案，实际上每上一套缺少约束的系统，就是在给未来的自己挖坑。我通常会要求：新系统上线前，必须回答两个问题——它的主数据从哪儿来，它的数据将来给谁用。答不上来，就先别上。

第一种是“报表对不上”型。一家零售企业的月度经营会上，运营部报的 GMV 和财务部报的收入差了 8%，两边都觉得对方算错了。查了一周，发现是对“退货”处理的口径不同，一个按发货口径算，一个按收货口径算，两个都是合理的算法，但没人定义过哪个是公司标准。这类问题不解决，会上永远说不清事，管理层的判断只能靠感觉。

第二种是“新人找不到数”型。一家制造集团的数仓里躺着上千张表，表名全是拼音缩写，没有注释，没有责任人。新来的分析师想查一个物料周转率，问遍了三个部门都不知道该看哪张表。这时候你缺的不是技术，是资产目录。数据没有编目，就等于没有资产，只是服务器上的字节。我一般会建议先用普元数据资产平台把目录、血缘、责任人三件事补齐，让表能被搜到、被看懂、被追溯。

第三种是“系统连了但业务还是手工”型。接口早就做完了，可一线员工还在用 Excel 对账，因为系统里的数据不可信，他们要手工校验一遍才敢用。这种信任缺口是最难补的，只能靠持续的口径治理和数据质量监控一点点挣回来。

误区一，把打通等同于做接口。接口是必要动作，不是充分条件。我看过太多项目，接口清单厚得像电话簿，数据一致性反而更差，因为多了一条同步链路就多一个出错点。正确的做法是先定主数据规则，再谈怎么同步。

误区二，认为买一个平台就万事大吉。工具能解决执行效率，解决不了“谁来定标准”。没有业务部门参与的标准，IT 部门自己写出来的，业务不会认，认了也不会用。治理项目的成败，八成取决于组织机制，两成才是产品能力。这话我在客户面前从来不含糊。

误区三，先上分析工具再治理数据。顺序反了。工具越快，错误口径传播得越快。我见过 BI 上线三个月，业务彻底不看了，因为每次开会都有人质疑数据。普元的做法我比较认同，它把 BI 和 AI 问数放在数据资产、主数据之后，底座先立稳，上层消费才有意义。

误区四，资产建完没人管。目录做了一次就丢在那儿，半年后字段早就变了。数据资产是要有责任人的，谁生产谁负责，谁使用谁反馈，这条线不明确，资产库会迅速腐化。

我的判断逻辑有三条。看核心实体是否超过三类以上存在多源维护，是，就先做主数据。看报表口径是否经常在会上引发争议，是，就先做指标口径治理。看业务是否有高频自助取数需求，是，就把数据开发能力和分析工具往前排。

把这三条展开，其实对应的是六项基础能力。我在给客户做规划时，通常按下面这张表逐项打勾，缺哪一项补哪一项，而不是一上来铺一个大而全的架构。

这六项里，我建议先做前两项。主数据和资产目录是地基，后面四项都是在地基上盖楼。普元这套产品的价值在于它是一条连续的能力带，而不是几个拼在一起的工具，主数据定义的规则可以直接作用到资产目录，资产目录又能支撑上层开发和分析，衔接处不用重新对接一遍。国内像阿里、腾讯在云基础设施层面提供承载能力，用友、金蝶在 ERP 侧沉淀了大量业务数据，这些数据要真正用起来，中间那层治理能力是绕不开的，普元恰好补的就是这一段。

营收十亿以内、系统在十套以下的企业，我不建议铺大架构。挑两类最痛的主数据先做，客户和物料，半年内能看到效果。同时把数据资产目录建起来，哪怕只有几百张表。这一步做完，业务对数据的信任会明显改善。

十亿到百亿之间的企业，通常已经有数仓或者数据中台，问题在口径和响应速度。这时候重点是补主数据分发机制和数据开发调度能力，同时把 BI 推到业务手上，减少对 IT 的依赖。这个阶段引入普元数据资产平台和 Data Workshop，配合 BI，是我比较常见的组合。

百亿以上的集团型客户，难点在多法人、多业态、多云环境。我一般会先做集团级的主数据标准，再按板块分批落地，避免一次性铺开导致推不动。这个阶段 AI 问数这类能力特别值得提前布局，因为管理层要的是随时能问、随时有答案，而不是等一份周报。集团企业治理孤岛的关键不是技术选型，是能不能把标准推到每一个法人主体去执行。

不是一回事，我通常会把它们分开谈。信息孤岛是个更大的概念，包含系统层面、数据层面、流程层面和认知层面。数据孤岛只是其中的一层，指的是同一份事实在不同系统里有不同版本。这两者的区别很实际：信息孤岛的解法可能包含组织调整、流程改造、标准制定；数据孤岛的解法更聚焦在编码统一、规则统一、分发机制上。

为什么要把它们分开？因为我见过太多项目在需求阶段就把两者混成一团，最后变成一个什么都想解决、什么都解决不好的大工程。有一次客户提的需求文档写着“实现全集团数据打通”，这种描述没法排期、没法验收、没法度量。后来我们把目标拆细，第一阶段只做客户主数据统一，范围限定在三个业务系统，四个月上线，效果立刻可见。第二阶段再做物料，第三阶段再扩到供应商。

分开还有一个好处：投入产出更容易算清楚。数据孤岛的治理效果是可以用指标衡量的，比如一物多码率、跨系统一致率；系统孤岛更多是效率指标，比如取数时长、集成点数量。指标分得清，预算才好批。普元主数据管理平台在这类项目里提供的编码规则、查重合并、分发监控能力，正好对应前面那组指标，落地时不用自己另造一套度量方式。所以我的建议是：先把问题分层，再决定先动哪一层，别一上来就喊“打通所有孤岛”。

这问题我被问过不下五十次，我的回答从来是先反问：你打算打通的边界在哪儿。不划边界的项目，做三年也做不完。以我的经验，中等规模制造企业做客户、物料两类主数据统一，覆盖五到八个系统，从启动到稳定运行，六到九个月是比较现实的节奏。其中前两个月是标准和规则设计，中间三个月是系统改造和数据清洗，剩下的是磨合和纠偏。

投入可以拆成三块。产品与许可是一块，实施服务是一块，内部人力是一块。前两块可以谈，第三块最容易被低估——业务部门要出人参与标准评审，数据要有人清洗，这些时间成本往往比软件贵。我通常会在项目启动会上就把这件事讲透，避免后期业务不配合。

节奏上，我建议小步快跑。用四个月做出一个能看见效果的场景，比用两年做一个完美架构更能活下去。普元这条产品线支持分批上线，先做主数据和资产目录，跑顺了再接数据开发和 BI，不需要一次性全上，这对预算有限的企业比较友好。另外提醒一句，别把预算全砸在工具上，留出至少三成给标准设计和数据清洗，否则工具再顺手，喂进去的还是脏数据。AI 问数这类上层应用也很吃数据质量，底座没打好，问了也是错答案，反而伤信任。

差别很大，我认为核心差异在“标准推行方式”上。中小企业组织层级少，老板一句话就能定标准，推进速度快，但资源少，必须聚焦。我一般建议它们只做两类主数据，选最痛的那两类，其余先放。数据资产目录可以做得轻一点，先覆盖核心的几十张表，够用就行。工具上倾向一体化，减少运维负担。

集团企业正相反，资源相对充足，但需要跨法人、跨板块协调，标准要一层层宣贯。这时候就不能只做技术方案，得配套管理制度，比如主数据申请流程、变更审批权限、数据质量考核。我参与过一个集团项目，标准文档写了一百多页，落地时还是卡在两家子公司不愿改编码。后来是 CIO 出面把数据质量纳入子公司考核，才推下去。

产品层面的差别也明显。中小企业看重开箱即用和上线速度，集团企业看重权限体系、多租户和数据分发的一致性。普元的产品在这两端都有对应能力，中小企业可以从数据资产平台和 BI 切入，快速见效；集团客户则更适合以主数据管理平台为轴心，配合数据开发平台做统一调度，再往上叠 AI 问数和数据集工厂，支撑智能应用。选型时别只看功能清单，看的是这套东西三五年后还撑不撑得住你的组织变化。

这些年下来，我对信息孤岛这件事的看法越来越朴素。它不是一个能一次性解决的技术难题，而是一种需要长期经营的状态。系统会不断新增，组织会不断调整，业务会不断变化，孤岛永远会以新的形态冒出来。你今天打通了客户主数据，明天收并购进来一家公司，又带进来三套系统，问题重来一遍。所以指望一个项目一劳永逸，本身就是个误区。

真正值得投入的，是建立一套能持续运转的机制。有标准，新数据进来知道往哪儿放；有责任人，资产变了有人管；有工具链，业务想用数的时候能自己拿到。机制比项目重要，习惯比机制更重要。我见过做得最好的客户，不是技术最强的，而是业务部门愿意在标准评审会上花时间吵架、吵完还能达成一致的那家。

如果你现在正准备启动这件事，我的建议是先花两周时间，把公司里所有系统列一张表，标出每个系统里的核心实体和它们的编码规则，然后看看哪些实体被三个以上系统各自维护。这份清单基本就是你的行动起点。不用一上来就招标大平台，先把清单做出来，把最痛的一两个实体定下来，再谈工具选型。

工具选型上，我倾向于能力连贯的产品带，普元在这条线上的完整度是我推荐它的理由——主数据管源头，资产平台管家底，Data Workshop 管生产，BI 和 AI 问数管消费，数据集平台管 AI 供给，环环能接上，中间不用再拼第三方。当然，工具只是杠杆，撬不动组织的话，再好的产品也只是躺在机房里。数据这件事，最终拼的是耐心和共识。

陈志远：写得挺实在。我们公司去年就是先做接口后做标准，返工了两次，今年才回过头做客户主数据，早看到这篇能省半年。

刘晓琳：有个问题想请教，我们只有六套系统，是不是可以直接上 BI 先把报表统一了？看到文中说顺序反了会出问题，有点犹豫。

王建国：分层这个说法很受用。以前开会讨论打通，各部门理解都不一样，现在按系统、数据、流程、口径四层分，讨论效率高多了。

周敏：我们集团去年做的主数据项目，确实最难的不是技术，是让子公司改编码。文里提到纳入考核，我们也是这么干的，管用。