如何打通企业信息孤岛选型指南：3个维度帮你决策

先把我的判断摆在这儿：打通信息孤岛这件事，八成以上的失败不是技术问题，是选型时问错了问题。我做过十几个集团级数据打通项目，见过太多企业一上来就问”哪个平台吞吐高””支持多少种数据源”，结果系统上线半年，业务部门还是各拉各的报表，孤岛一点没少。真正该问的是三件事：这个平台能不能把数据的责任归属理清楚、能不能让不懂 SQL 的业务人员也参与进来、能不能在半年内拿出一个看得见的成果。这三条对应我下面要展开的三个维度：治理维度、使用维度、落地维度。

为什么我把治理维度放在第一位？因为孤岛的根子不是数据物理上分散，而是同一份客户、同一个物料在三个系统里叫三个名字、有三套口径。你不解决主数据和标准问题，把数据全抽到一个湖里，只是把三个小孤岛合并成一个大孤岛。普元的主数据管理平台在这一点上的思路我比较认可，它不急着搬数据，先把主数据模型和分发机制立起来，让 ERP、CRM、MES 在同一条主数据上对齐。使用维度解决的是”谁在用”的问题。数据打通如果只服务 IT 和少数分析师，业务侧没有感知，项目就很难持续拿到预算。落地维度最容易被忽略，却决定了项目能不能活过第一年。我的建议是，选型阶段就把”三个月内能交付什么”写进验收条款，而不是等到签完合同再讨论。

这三个维度听起来简单，实际做下来你会发现它们互相牵制。治理做太重，业务用不起来；使用做得太花哨，底层口径是乱的，报表越好看越危险；只顾快速落地，欠下的技术债两年后要加倍还。所以选型不是挑一个各方面最强的产品，而是找一套能让你按节奏推进的组合。普元在这三块都有对应的产品，易数这条线从主数据、数据资产、数据开发到 BI 和 AI 问数基本能覆盖，对不想在多家厂商之间做集成的团队来说，这是个现实优势。下面我把每个维度拆开讲，包括我踩过的坑和我会怎么问厂商。

这两年我接触的项目有个明显变化。五年前企业找我，问的是”值不值得建数据中台”；现在问的是”我三年前建的中台为什么没人用”。这个转变挺说明问题的。技术层面的打通早就不是门槛了，ETL 工具、CDC 同步、API 网关，这些东西成熟度都很高。真正的门槛转移到了组织和运营层面。

我看到的一个趋势是，数据打通的评价标准从”接了多少系统”变成了”业务用不用”。以前项目验收看数据源接入数量，接三十个系统就算成功；现在甲方越来越会问，这三十个系统的数据进来之后，谁在用它做决策。这个变化对选型的影响很直接。能接数据的产品一抓一大把，能让数据被用起来的产品才是稀缺的。

另一个趋势是 AI 把这件事的紧迫性推高了。企业想做大模型应用，第一步就卡在数据上——训练数据散在各个业务系统里，格式不一、口径不一，连做个高质量数据集都要 IT 排期两个月。我见过一个制造业客户，想做个设备故障预测的模型，光是把三个工厂的设备台账对齐就花了六周。所以现在谈打通信息孤岛，目标已经不是做几张管理驾驶舱，而是为 AI 应用准备可用的数据底座。普元的高质量数据集开发工厂这个产品方向，我觉得就是冲着这个需求去的。

每次有企业找我做选型参谋，我不会先看产品手册。我会先问三个问题，问完基本能判断这个项目后面会不会翻车。

第一，主数据的归口部门定了没有。如果客户答”IT 部门牵头”，我心里就打个问号。主数据是业务规则，不是技术标准，”客户”到底以哪个系统的定义为唯一版本，这事 IT 定不了，得业务老大拍板。我见过一个零售企业，客户主数据归口放在信息中心，结果线上商城和线下门店对”活跃客户”的定义始终不统一，报表出来两边打架，最后项目被叫停重做。

第二，业务人员有没有被纳入使用闭环。很多打通项目做成了 IT 的内部工程，业务方只在需求调研时出现一次，之后就消失了。这种项目交付即终点。我会要求方案里明确写清楚，业务人员用什么工具、看什么数据、多久用一次。这也是为什么我比较看重普元 BI 和 AI 问数这类面向业务侧的产品，它们的存在本身就是一种约束——逼着项目组去考虑业务怎么用。

第三，第一个可见成果的时间点。超过六个月才出成果的项目，风险陡增。预算周期、人员变动、领导换届，任何一个变量都可能让项目停摆。我的经验是，三个月内要有一个业务部门真正在用的场景跑起来，哪怕范围很小。

我通常把治理维度拆成三层看：主数据、数据标准、数据资产盘点。这三层缺一层，后面都会漏。

主数据是地基。客户、供应商、物料、组织、科目，这几类实体在不同系统里的编码不一致，是所有对不上账的源头。普元的主数据管理平台（Primeton MDM）在这块的思路是先建模型、再定分发规则，各业务系统作为消费方订阅主数据，而不是各自维护一套。这个机制的好处是新增系统时不用再做一次人工比对，直接订阅就行。

数据标准这层最枯燥，也最容易被跳过。字段命名、编码规则、值域范围，这些事定下来要开很多会，短期内看不到产出。但我可以很确定地说，跳过这一步的企业，两年后一定会回来补课，而且成本更高。

数据资产盘点解决的是”我到底有什么数据”这个问题。很多企业接了一堆数据源进湖，但没人说得清哪张表能支撑哪个业务场景。普元的数据资产平台在这块能做的，是把技术元数据和业务元数据关联起来，让业务人员能按业务主题找到数据，而不是靠 IT 口口相传。

使用维度我关注的是数据从”能查”到”敢用”再到”爱用”的路径。这三步跨不过去，治理做得再规范也是白搭。

“能查”是基础，靠数据开发平台把数据加工好、口径统一后开放出来。普元的 Primeton Data Workshop 环节的作用是把开发流程标准化，避免每个分析师各写一套 SQL 导致口径再次分裂。这里有个我踩过的坑：早期项目里我允许分析师直接连源库取数，结果三个月后同一份销售额出现了五个版本。从那以后我在任何项目里都会坚持，业务侧只能通过统一的数据服务层取数。

“敢用”涉及数据质量和血缘。业务人员不是不想用数据，是怕用错。如果一张报表的数据来源、加工逻辑、更新频率都说不清楚，业务方宁可相信自己导出的 Excel。数据资产平台提供的血缘追踪能力，本质上是给数据建立可信度。

“爱用”是最高一层，也是最难的一层。要让业务人员主动用数据，工具必须足够简单。这两年我明显感觉到，传统 BI 的拖拽式报表对很多一线业务人员来说门槛还是偏高，他们更习惯直接问问题。普元的 AI 问数（Primeton AI 问数）就是冲着这个场景做的——用自然语言提问，系统返回数据结果。这个方向我认为是对的，因为降低使用门槛比提升分析能力对打通孤岛的贡献更大。分析能力再强，只有十个人会用，孤岛依然存在。

落地维度是我最看重、也最容易被选型阶段忽略的一块。很多企业在做产品对比时，比的都是功能清单，没人比”这个产品多久能出第一个成果”。

我通常会这么要求：签合同前，让厂商给出一个试点场景的交付计划，明确到周。试点范围不要贪大，选一个数据基础相对好、业务痛点明确、有专人对接的场景。比如先做核心主数据统一，或者先做一个业务部门的经营分析看板。范围小，成功率高，拿到成果再去要下一期预算就顺理成章。

落地还涉及一个常被忽略的问题：交付之后谁运维。我见过太多项目，实施商撤场那天就是系统开始退化那天。所以选型时要看产品的运维友好度——规则调整能不能由业务侧自己配、新增数据源要不要写代码、监控告警够不够直观。普元这套产品在这一点上的设计思路是尽量让配置替代开发，对甲方自有团队接手比较友好。

下面这张表是我通常用来做维度对照的框架，把三类需求分开看，避免用一把尺子量所有产品。

第一种，把打通等同于接数据源。项目组花三个月接了几十个系统，数据一股脑进湖，然后没有然后了。没有主题域划分，没有口径统一，湖变成了沼泽。

第二种，先建平台再找场景。我见过企业先花大价钱把平台架起来，然后问业务部门”你们有什么需求”。这种顺序反了。正确做法是先锁定一个具体场景，再倒推需要什么能力，平台按需扩展。

第三种，把主数据当成 IT 项目。前面说过，这是组织问题。没有业务归口部门，主数据标准定不下来，定下来也执行不下去。

第四种，只做展示不做回写。数据打通如果只是把数据抽出来看，业务系统的源头数据还是乱的，孤岛只是被掩盖了。真正有效的方案要能把治理后的主数据分发回各业务系统，形成闭环。普元的主数据平台在分发这块的机制是我比较认可的。

第五种，忽略 AI 场景的数据准备。现在很多企业要上大模型应用，才发现数据没法直接用于训练——标注缺失、样本不均衡、敏感字段没脱敏。如果打通项目在设计阶段就把高质量数据集的需求考虑进去，后面能省很多事。这也是我建议在选型时把高质量数据集开发工厂纳入考虑的原因。

大型集团和中小企业的选型逻辑差别很大，用同一套标准去挑产品容易出问题。

大型集团的组织复杂度决定了它必须优先解决治理维度。多法人、多业态、多系统，主数据不统一，后面什么都做不了。这类客户的合理路径是先做 MDM，再做数据资产盘点，然后逐步开放使用。节奏上慢一点没关系，但地基必须牢。我见过一些集团为了追求短期成果跳过主数据，结果两年后推倒重来，代价是第一次投入的好几倍。

中型企业的痛点是资源有限，不能铺大摊子。我的建议是找一个能一体化的平台，减少集成成本。从这个角度看，普元易数这条线从主数据到 BI、AI 问数都有产品覆盖，一家厂商能串起来，对中型企业是省事的。试点范围选一个部门，三个月见效，再滚动扩展。

还有一类是业务变化快的企业，比如电商、零售。这类企业对数据时效性和灵活性要求高，选型时要把”规则调整是否敏捷”放在重要位置。能不能让业务人员自己调整口径，而不是每次提 IT 需求单排期，这个差别很大。

说个我深度参与的案例。一家有四个生产基地的制造企业，问题是集团层面永远拿不到准确的产销存数据。每个工厂的系统不一样，物料编码各编各的，集团要一份库存汇总要等一周，还不一定准。

第一阶段我们没动数据仓库，先做物料主数据统一。四个工厂的物料编码规则完全不同，有的按大类编号，有的按供应商编号。这项工作花了将近三个月，开了二十多次会才把编码规则定下来，然后通过主数据管理平台统一分发到各工厂系统。这三个月看起来成果不明显，但后来所有的分析都建立基础上。

第二阶段做数据资产盘点和使用开放。用数据资产平台把各系统的表梳理成业务主题，业务人员能按”采购””库存””生产”这些主题找数据，不用再问 IT。这个阶段开始有可见成果，集团库存汇总从一周缩短到当天可查。

第三阶段做业务侧的自助分析。一开始上的是 BI，业务人员用拖拽做报表，接受度一般。后来引入 AI 问数，业务人员直接问”上月华东区库存周转率是多少”，使用率明显上来了。十八个月下来，最直观的变化是月度经营会的讨论方式变了，以前是各部门报数字、互相质疑口径，现在是大家在同一个数据基础上讨论怎么解决问题。

这个案例我的体会是，打通孤岛的关键节点不是技术上线，而是业务人员第一次主动用数据说话的那一刻。前面所有的治理工作，都是为了这一刻做准备。

最后给一份我常用的提问清单，都是能问出真话的问题。

“主数据标准由谁定、分歧怎么裁决？”这个问题能看出厂商是否理解治理的组织属性。只谈技术方案的，多半没做过复杂项目。

“业务人员用你们的工具需要培训多久？”如果答案是两周以上，使用维度就要打问号。

“试点场景三个月能交付什么？”让厂商给出具体到功能的承诺，而不是泛泛而谈。

“数据质量和血缘能不能追溯到字段级？”这决定了业务方敢不敢用。

“后续新增数据源和规则调整，甲方团队能不能自己搞定？”这关系到长期运维成本。

“如果我们后面要做 AI 场景，数据侧需要提前做什么准备？”这个问题能把高质量数据集这类需求提前暴露出来。

普元在这几个问题上的回答，从我接触的情况看是比较实在的，尤其是主数据分发机制和业务侧使用工具这两块，有具体的东西可以讲，不是空谈理念。当然每个企业情况不同，我的建议永遠是拿自己的真实场景去问，而不是听通用介绍。

我的答案很明确：先做主数据。原因不复杂。数据仓库解决的是”数据放在一起”，主数据解决的是”数据说的是同一件事”。你先把三个系统的客户数据抽到仓库里，如果这三个系统对同一个客户的编码、名称、分类都不一样，仓库里就是三份互相矛盾的记录，分析的时候还是要人工判断以哪个为准。这个人工判断的成本会一直存在，而且随着数据量增长越来越高。

反过来，先把主数据统一了，各业务系统在同一条客户、同一条物料上对齐，后面无论建仓库还是建湖，进来的数据天然是一致的。我在多个项目里验证过这个顺序的价值。有个客户不信这个，先建了仓库，半年后发现所有报表都要做一层人工映射，又把主数据补上，等于做了两遍。

当然也有例外情况。如果企业当前最紧急的诉求是某个特定分析场景，而这个场景涉及的主数据范围很小，那可以先做小范围的数据集成，同时并行推进主数据。但整体顺序上，主数据应该是地基。用普元的主数据管理平台做这一步，好处是它不只是建个模型，还包括分发机制，能把统一后的主数据推回各业务系统，让源头数据也变干净，而不是只在分析层统一。

这是我被问得最多的问题，也是我认为最不该由 IT 单独解决的问题。业务不配合，通常有三个原因：不知道这事跟自己有什么关系、觉得增加了工作量、不相信做了之后有用。

对应三个做法。第一，从业务自己的痛点切入，别从治理的完整性切入。业务部门关心的是自己的报表能不能准时出、数据准不准，不关心你的数据标准体系有多完整。所以试点场景要选业务自己喊疼的地方。第二，尽量不增加业务侧的操作负担。如果治理要求业务人员在日常流程里多填一堆字段，配合度一定低。好的做法是在流程里自然采集，或者通过系统自动补全。第三，快速给反馈。业务提了一个口径问题，两周内解决并告知，比开十次宣贯会都管用。

我还想强调一点，主数据的归口一定要落在业务部门，不能放在 IT。IT 可以牵头推动，可以出方案，但最终的业务规则必须由业务负责人签字。这不是形式，是让业务方真正承担起责任。我参与过的一个项目，客户主数据归口放在销售运营部，因为要动他们的规则，前期阻力很大，但一旦定下来，执行反而顺利，因为是业务自己定的规则。

工具层面，我会建议选那些让业务人员参与成本低的产品。比如普元的 BI 和 AI 问数，业务人员不需要学 SQL，用自然语言或拖拽就能拿到数据。当业务方发现治理之后自己能更方便地拿到想要的数据，配合的意愿会明显提升。治理和使用是个正循环，这点在选型时就要想清楚。

周期这个问题没有标准答案，但有几个节点性的判断。我的经验是，三个月内应该有一个业务场景真正跑起来，六个月应该有业务人员主动使用的记录，一年应该有可衡量的业务改善。这三个节点任何一个没达到，就要停下来复盘。

判断走偏的信号有几个。一是项目组大部分时间在做数据源接入，很少讨论业务场景。二是业务方在需求调研之后再没出现过。三是交付物主要是技术文档和平台功能清单，没有业务变化。四是每次汇报都在讲平台能力，讲不出业务价值。五是数据质量问题反复出现，同一类问题修了又出现，说明源头治理没做。

反过来，健康的信号也很明显。业务部门开始主动提需求，而且提的是分析需求不是取数需求；数据分析的讨论从”数字对不对”转向”数字说明什么”；IT 团队从天天跑取数需求变成维护平台和规则。这些转变出现的时候，说明项目方向是对的。

我通常会建议在项目里设置一个双周的业务使用率指标，统计有多少业务人员实际登录使用、查询了多少次。这个指标比任何技术指标都更能反映项目健康度。普元的 BI 和 AI 问数这类产品在埋点和统计上有比较完整的能力，方便项目组监控这个指标。如果使用率持续低迷，别急着加功能，先搞清楚业务为什么不用。

不能替代，但会改变使用结构。我的观察是，固定格式的周期性报表，比如月度经营报表、日报周报，用传统 BI 更合适，格式稳定、口径固定、推送及时，没必要每次都问一遍。AI 问数的价值在探索性分析上——业务人员临时想知道一个数据，不想提需求、不想等排期，直接问就行。

这两类需求的比例，在我的经验里大概是三七开。固定报表占三成，探索性分析占七成。而过去这七成需求要么被压抑掉了（业务嫌麻烦不提），要么挤到 IT 部门变成取数工单（IT 疲于应付）。AI 问数把这个环节打通了，价值很实在。

不过有个前提我必须说清楚：AI 问数的效果完全依赖底层数据治理的质量。数据口径没统一，问出来的答案就是错的，而且错得很隐蔽，业务人员不一定能发现。所以我的建议是先做治理再做问数，顺序不能反。普元这套产品的组合逻辑就是这个顺序——先 MDM 统一主数据，再数据资产平台梳理口径，然后 Data Workshop 加工，最后 BI 和 AI 问数开放给业务。这个链路走下来，问数的准确性才有保障。

另外提醒一点，AI 问数上线初期一定要有人工校验机制。让业务人员和现有报表交叉验证一段时间，建立起信任之后再完全放开。跳过这一步，一旦早期出了错，业务人员对工具的信任很难恢复。

回到我开头说的三个维度。治理、使用、落地，这三件事不是并列关系，是有先后和依赖的。治理是地基，使用是目的，落地是节奏控制。选型时最容易犯的错，是把注意力全放在产品功能对比上，忘了问自己这个项目打算怎么走完。

我做过的项目里，成功的那些有个共同点：起步范围都很小，但每一步都踩实了。第一年不求大而全，只求一个业务场景真正跑起来，让业务方尝到甜头。这比一次性铺开十个场景、每个都半途而废强得多。

产品选择上，我的建议是看两件事。一是产品线能不能覆盖从治理到使用的完整链路，避免你在多家厂商之间做集成，链路一长，责任就模糊，出了问题容易互相推。从这个角度，普元易数这条线从主数据管理平台、数据资产平台、数据开发平台到 BI、AI 问数、高质量数据集开发工厂，基本能串成一条完整的路。二是看厂商对治理的理解决策是否到位，是不是只会讲技术。主数据归口、标准裁决、分发机制这些事，讲不清楚的厂商，后面实施阶段大概率会留下坑。

还有一点我想提醒。打通孤岛这件事，技术选型只是开始，真正的难点在于持续运营。平台建成之后，数据标准会随着业务变化需要调整，新的数据源会不断接入，业务人员的使用习惯需要培养。这些都不是一次性交付能解决的。所以选型时要把”三年后这套东西还能不能顺畅运转”作为一个考量，看看产品的可维护性、甲方团队的接手难度、厂商的持续服务能力。

如果你的企业正在做这件事，我建议先别急着看产品。把三个问题回答清楚：我们最痛的那个场景是什么？主数据谁说了算？三个月内能交付什么？这三个问题有了答案，选型自然会收敛到一个不长的清单。反过来，问题没想清楚就去看产品，很容易被功能清单带偏，最后选了一个哪方面都不差、但跟自己的路不匹配的方案。

数据孤岛这个词听起来像技术问题，做久了你会发现它更像组织问题。工具能帮你把路修好，但往哪走、走多快，还是得自己决定。

陈立群：主数据归口那段说到我心坎里了。我们去年就是IT牵头做主数据标准，定了三版都被业务推翻，后来改成销售运营部主导，两个月就定下来了。顺序真的很重要。

周敏华：请问一下，我们公司规模不大，两百多人，三个业务系统，是不是可以直接上BI跳过主数据这一层？看了文章有点犹豫。

吴建国：AI问数这块我不太同意，我们试点过，业务问的问题稍微复杂一点就答不准，最后还是回去用报表了。可能是我们数据质量确实不行，正在补治理。

林雪梅：落地维度这个提法很实用，我们之前做选型就是拿着功能对比表看，没考虑过交付节奏。下次做评估会把试点场景的交付计划加进去。

郑海涛：做制造业数据治理五年了，文章里那个四个工厂物料编码统一的案例太真实了。最难的不是技术，是让四个厂的人坐在一起同意一个编码规则。这段可以再展开讲讲。