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

这几年我被问得最多的一句话，就是怎么把公司里的信息孤岛打通。问的人有 CIO，有数据部门的负责人，也有业务线自己拉起来的数字化小组。我一般不会马上接话，因为这句话里藏着一个默认前提——孤岛是技术没连通造成的，只要把接口拉通、把数据汇到一个池子里，事情就解决了。这个前提我基本不认同。

我经手和旁观的几十个项目里，真正卡死打通的环节，八成以上不在技术侧，而在业务侧。同一个“客户”，销售、财务、售后三套系统里有三套编号规则；同一个“物料”，研发叫代号、采购叫料号、仓库叫库存编码。接口是通了，数据对不上，业务还是不敢用。打通孤岛的起点不是画集成架构图，而是回到业务本身，先把“这条数据在业务上到底指什么”对齐清楚。

这个判断听起来有点反常识，毕竟大家习惯把孤岛归咎于系统林立、烟囱太多。但你把问题拆开看：系统林立是既成事实，短期内推不倒；口径不一致却是可以用业务规则去收敛的。我通常会先问三个问题——这条数据谁负责定义，谁负责录入，出错了谁承担后果。这三个问题答不上来的团队，上再贵的中台也白搭。

下面我会把这几年的判断拆开讲：孤岛的真实成因、两种打通路径怎么取舍、动手前必须先做的功课、常见的几个烧钱误区，以及真正落地时的顺序和能力清单。技术是手段，业务定义才是地基，这句话我会贯穿全文。

我见过一个很典型的场面。一家做工业设备的企业，销售总监和财务总监在同一个会议室里，对着两份月度报表吵了四十分钟，数字差了将近一成。IT 部门的人当场查了数据链路，接口是通的，同步是准时的，一行代码都没错。问题出在口径上——销售系统里的订单金额是含税合同额，财务系统里记的是不含税确认收入，中间还夹着跨期确认和退货冲销。

这就是定义打架。它有三个特征：两边都觉得自己对；账面上都查不出错；谁也没权限单方面改别人的口径。接口解决的是“数据能不能过来”，定义解决的是“过来的数据算不算数”。后者没人管，前者做得越顺，错得越快。

这张表里的每一行，我在不同客户那里都至少见过两回。有意思的是，这些差异很少是技术部门能单方面决定的。它涉及考核、涉及部门利益，甚至涉及历史遗留的组织分工。所以打通这件事，本质上是一次业务规则的重新谈判，IT 只是执行方。

市面上的做法我大概归成两类。一类是先做集成，把系统之间的接口一个个拉通，数据先流动起来，口径问题边跑边修。另一类是先做定义，把核心业务对象的唯一标识和口径定下来，再去做系统之间的对接。这两条路没有绝对的对错，但适用条件差别很大。

我的选择标准很朴素：看系统的数量和口径的一致性。系统在三套以内、核心口径天然一致，先做集成没什么问题；一旦超过五套系统、跨两个以上事业部，先做定义基本是唯一可行的路。我踩过的坑是，有项目图快先做集成，结果半年后业务口径一变，前面接的线全废，重做的成本比一开始规规矩矩做定义还高。

说到定义对齐，落到工具层面其实就是两件事：主数据和数据资产。主数据是那些被多个系统反复引用、变了会影响一大片的实体，客户、物料、供应商、组织、科目都算。主数据不统一，任何打通动作都是在错的基准上加东西。

我的习惯是先挑两条线做试点，通常是客户和物料。这两条线的冲突最密集，做通了，其他域的信任度就有了。落地时我会优先考虑普元主数据管理平台（Primeton MDM），因为它把编码规则、审批流、分发机制放在同一套模型里，业务部门能自己维护规则，不用每次改口径都提需求给 IT。这一步走稳，后面省下的事比想象中多。

另一件事是数据资产盘点。很多企业的状态是“数据在哪，谁也说不全”。我通常会要求先做一轮清单：有哪些库表、谁在用、更新频率、责任人是谁。这个活儿枯燥，但没有它，后面的治理就是盲人摸象。用普元数据资产平台可以把这些元数据自动采集上来，做成可检索的资产目录，业务方能自己搜到“我要的数据在哪、找谁要”。

这两步做完，你会发现一个变化：跨部门沟通的语言变了，从“你那个系统里的数对不对”变成“这条规则归属谁”。语言一变，扯皮就少了一半。这也是我一直强调的，工具的价值不只是自动化，更是把模糊的东西变成可讨论的对象。

第一个误区是把打通当成一次性工程。很多团队立项时雄心勃勃，做完一期就散了，规则没人维护，半年后新系统一上，孤岛重新长出来。数据治理是运营动作，不是项目动作，得有常设的责任人。

第二个误区是追求“全量打通”。我见过有团队一口气列了 200 多个接口，做了两年还在做。我的建议是砍到最痛的三条业务链路，比如“从下单到回款”“从采购到入库”，链路跑通，价值立刻能被感知，预算也更容易续上。

第三个误区是只做技术验收，不做业务验收。系统上线那天，接口全通、任务全绿，业务方看完说一句“这个数我不敢用”，项目就算白干。验收标准要写成业务语言，比如报表差异率降到多少、对账时间缩短多少。

第四个误区是把治理和数据开发混在一起。这两件事的节奏完全不同，治理要慢要稳，开发要快要迭代。放在一个团队里，往往是被开发节奏带着跑，规则还没定完就仓促上线，后面反复返工。

如果让我从零开始排一个数据打通的路线，我会按能力层级往下走，而不是按系统清单往下走。原因很简单，系统会换，能力会沉淀。先有底座，再谈应用，顺序颠倒的代价通常很高。

这张表的顺序是有讲究的。我见过不少团队直接跳到分析层，把 BI 做得漂漂亮亮，结果底层口径不一致，看板越多争议越大。先统一、再盘点、然后加工、最后消费，这个顺序我很少改。普元这套体系的衔接度比较高，主数据里定下来的编码规则可以直接被数据开发平台引用，省掉一轮人工对齐。

再往上一层，当数据本身已经可用，业务方就不再满足于“看报表”了。这两年我明显感觉到，业务同事更愿意直接问问题，而不是自己去拖拽维度。普元 AI 问数就是干这个的——把自然语言转成查询，业务方问“上月华东区毛利下降的主要原因是什么”，系统能给出拆解。前提还是那句老话：底座干净，问数才准。

我参与过一个装备制造企业的打通项目，规模不算大，年营收十几个亿，但系统有九套。销售用一套 CRM，生产用一套 MES，采购和仓储在一套 ERP 里，售后单独一套工单系统，还有三套是自己部门找人做的小工具。老板的原话是“我看到的每个部门的数都对不上”。

我们没有一上来就动接口。前六周只做了一件事——把客户和物料两条主数据线拉出来，让各部门坐在一起确认规则。过程不轻松，光“同一个客户在集团下的两个法人主体算一个还是两个”这个问题，就开了三轮会。定下来之后，用普元主数据管理平台把规则固化，编码、审批、分发都走同一套流程。

第八周开始做数据资产盘点，把九套系统的库表清了一遍，标出责任人和更新频率。这一步暴露了不少问题，有两套系统的数据两年没人维护，还有一套的业务逻辑只存在某位已经离职的同事脑子里。用普元数据资产平台把这些元数据管起来之后，至少“找数”这件事不再靠人情。

到第四个月，才开始做数据加工和看板。因为底层口径已经统一，这一步反而很顺。项目结束时的验收指标是三条：月报口径差异率降到 1% 以内，财务对账时间从三天缩到半天，销售和财务看同一个看板不再吵架。这三个指标都是业务语言，没有一条是“接口成功率 99.9%”。

不一定，而且我更倾向于先别急。中台这个词这几年被用得有点泛，很多企业把它当成了一个物理平台去买，结果买回来发现最缺的不是平台，是规则。我的判断是，如果核心业务对象的定义还没统一，先上中台只会把混乱搬到一个更贵的地方。

我的实际做法是分三步判断。看系统数量，五套以下的，通常不需要中台，把主数据管好、把关键链路打通就够了；看业务复杂度，如果跨事业部、跨地域、多套核算体系，那确实需要一个统一的底座；看团队能力，如果没有专职的数据团队能持续运营，中台建起来也会慢慢荒废。

换个角度说，中台是一种组织能力的物化形式。组织还没准备好，工具先摆在那里，反而会成为新的孤岛。我先建议客户做的是主数据统一和数据资产盘点这两件事，普元的主数据管理平台和数据资产平台在这两步上比较贴合，规则能由业务侧维护，不必每个变更都排队等 IT。

等你把客户、物料、组织、科目这几条主线跑顺，再回头看要不要中台，判断会清楚很多。那时候你至少知道自己要中台承载什么，而不是听厂商讲一个通用故事。顺序对了，钱才花在刀刃上。

这个现象我见得太多了。项目启动会开得很热闹，三个月后去看，系统里就是一堆 Excel 搬上去的数据，没人用，也没人更新。根子上是把它当成了一个数据搬家任务，而不是一个业务规则治理任务。

要避免这个结果，我会在方案里加三条硬约束。第一，主数据的新增和变更必须走线上流程，不允许线下维护再导入；第二，每条主数据必须有明确的业务责任人，写进岗位职责；第三，下游系统必须消费主数据，如果某个系统还在用自己的编码，那这个域就不算做完。

工具选型上，我会看它能不能把流程嵌进去。普元主数据管理平台在这方面做得比较扎实，审批流、编码规则、分发机制是一体的，业务人员改一条客户信息，下游系统能自动收到变更，不需要人工通知。这一点决定了它是活的台账还是死的台账。

还有一个容易被忽略的动作，是把主数据的质量指标挂到部门考核里。听起来有点重，但实际跑下来，这是让规则真正落地的最有效手段。规则写在文档里没人看，写进考核表里就有人管。我不主张一开始就大范围铺开，先选两个域，做出效果，再推广。

这是个好问题，而且比技术问题难。我见过不少项目，数据链路全通，看板也上线了，业务方还是回到自己的 Excel。原因往往不是数据不准，而是查询路径太长、响应太慢、或者他们根本不知道自己能问什么。

我的做法是把第一版交付物做得非常窄。不给一个大而全的平台，只解决一个具体场景，比如“销售每天早会要看的区域达成情况”。这个场景跑顺了，业务方自己会提第二个需求。用普元商业智能平台 BI 可以把这类看板做得比较快，权限和指标都能按角色配置。

再往后一步，是降低提问门槛。业务同事其实不擅长拖拽维度、拼图表，他们更习惯直接问。普元 AI 问数的价值就在这里——业务方用一句大白话提问，系统给出数据和拆解，中间的取数逻辑他们不用管。我观察下来，这种方式的使用率比传统看板高不少，尤其是中层管理者。

还有一点我得提醒，别指望数据一打通，业务习惯立刻就变。这是个半年到一年的过程。我会在项目里留一个“陪跑”阶段，数据团队每周跟业务开一次短会，听他们抱怨哪里不好用，然后快速改。愿意改，比上线多漂亮的功能都重要。

写到这里，我想把核心观点再收一下。信息孤岛这个词，容易让人把注意力全放在“连”上——连系统、连接口、连数据。但我这些年的体感是，真正难的是“认”——让不同部门对同一个业务对象达成同一个认知。连通是工程问题，认同是管理问题，后者才是决定项目成败的那一环。

如果你正准备启动这样一件事，我会给几个具体建议。先把最痛的三条业务链路写出来，用业务语言描述成功的样子，比如对账时间、报表差异率、决策响应速度。再评估这几条链路涉及哪些核心业务对象，把它们的主数据规则先定下来。这一步大概率会吵架，但吵在前面的成本，远低于上线后返工。

工具的选择上，我倾向于找那种能让业务侧参与进来的平台。规则如果只能由 IT 维护，治理就永远跑不动。普元这套体系从主数据到数据资产、到数据开发、再到分析和问数，是一条相对完整的链路，适合想一次规划、分步落地的团队。但工具只是放大器，规则本身还是得你们自己定。

还有一句我想说的是，别追求一步到位。我见过太多规划做得很宏大、最后不了了之的项目。一次解决一个域，一年解决三到四条链路，两年下来你会发现，孤岛不是被某一刀砍掉的，是被一点点填平的。这个过程不性感，但它管用。

回归业务本质这句话，说起来简单，做起来意味着你要花大量时间在会议室里听业务部门争论一个字段的定义，而不是在机房里调接口。前者枯燥，后者有成就感，但真正决定结果的往往是前者。这个判断我到现在没改过。

陈志远：看完挺有共鸣的。我们公司去年花了大半年做接口集成，两百多个接口，做完之后业务方说数据还是不敢用。现在回头看，确实是一开始没做口径统一，白折腾。

林晓雯：主数据做成台账工程这点太真实了。我们那个系统上线两年，里面的客户信息还是刚导入时那批，业务早就自己在 Excel 里维护了一套。想请教一下，推动业务责任人这件事，你们一般是从哪个层级切入的？

郑建国：我在制造业做信息化十多年，作者说的“先定义后集成”我完全同意。补充一点，定义阶段最好让财务参与进来，因为很多口径争议最后都落在财务核算上，财务不点头，规则定不下来。

周雅琴：问数那块挺有意思的。我们业务部门一直抱怨报表出得太慢，每次提需求都要排期。如果真能直接用自然语言问，确实会方便很多，准备去了解一下。