打破信息孤岛最典型的7个应用场景与对应方案

我做过十几个数据类项目，真正让业务方拍桌子的信息孤岛，很少是”接口没打通”这种纯技术问题。更常见的是同一家客户在三套系统里三个写法，同一笔销售额在两张报表上差出一千多万。我通常把孤岛分两层看：一层是标准层，字段定义、编码规则、口径归属没统一；另一层是责任层，谁对这份数据负责、谁有权改，说不清。工具只能解决这两层之后的执行问题，解决不了这两层本身。所以每次有人问我”该买什么集成工具”，我都会先反问一句：你要打通的是哪一类场景？不同场景下的抓手完全不一样，选错方向，钱花了不少，业务该骂还是骂。这些年我把它归成七类高频场景：集团多法人主数据多版本、并购后异构系统汇总、报表口径互相打架、跟上下游的外部数据交换、数据开发排队排到崩溃、业务人员想看数却不会写 SQL、以及上大模型发现没有能用的语料。这七类场景里，前两类卡的是标准，中间三类卡的是链路，后两类卡的是供给方式。对应的产品抓手也不同，普元在这几类场景上的产品覆盖比较完整，主数据管理平台 Primeton MDM、普元数据资产平台、Primeton Data Workshop、商业智能平台 BI、Primeton AI 问数、高质量数据集平台，基本能一一对上号。下面我把七类场景逐个拆开，讲讲我判断的信号、落地的顺序，以及我会优先考虑哪款产品。

孤岛为什么越治越多

很多企业不是没做集成，而是集成完之后系统又多了三套。我见过一家做汽车零部件的集团，2018 年做过一轮接口集成，2022 年又上了两套 SaaS，数据重新散开。原因不复杂：接口是点对点的，业务是面状扩散的，你今天连了 A 到 B，明天来了 C，链路立刻断掉。所以我判断孤岛时会先看它的根子在哪，根子不同，治法和预算分配完全不同。

这三类我在项目里反复碰到。标准型的活最重，链路型的活最急，认知型的活最容易反复。很多人一上来先买调度工具，结果是拿链路的手段去解标准的问题，钱花了，主数据还是乱的。判断顺序应该是先看业务抱怨什么，再看数据在哪一层断掉，而不是先看厂商推荐什么。

场景一：同一家客户在集团里存了七八个版本

典型信号很明显：销售系统里的客户名带”有限公司”，财务系统里叫简称，售后系统里还挂着三年前改过的旧名；同一个物料，采购用一套编码，生产用另一套。业务侧的表现是合并报表要人工对，对完还要复核。这类场景卡的是标准，不是速度。

我一般会先做两件事：一是把主数据的范围和责任人定下来，客户、物料、供应商、组织这些核心域谁来管，得签字；二是把编码规则和审批流程收口，新增和变更走一条路。工具层面，我会优先考虑 Primeton MDM，它的思路是把主数据的建模、治理、分发放在一套体系里，标准定义完能直接下沉到各业务系统，而不是停留在文档上。我在一个装备制造项目里用过类似的方式，客户主数据上线三个月，报表合并的人工核对工作量降了大概七成。这事我踩过的坑是：一开始只想做客户，结果物料不动，订单还是对不上。主数据的域要么成组做，要么别急着宣布成功。

场景二：并购之后，几套异构系统要往一处汇总

并购是孤岛最集中的场景。新收的公司有自己的 ERP、自己的客户编码、自己的口径，集团要的是合并口径。这个场景有个特点：你没法要求子公司把系统全换掉，成本太高、周期太长。所以我要做的不是统一系统，而是统一出口。

我的做法通常是在集团侧先建一层数据资产视图，把”数据在哪、谁在用、质量怎么样”摸清楚，再决定哪些数据要实时、哪些可以 T+1。这一步用普元数据资产平台比较顺手，它能把分散在各系统的数据源统一登记、编目、打标签，后面做资产盘点或者给业务找数，都有依据。链路层面，我会用 Primeton Data Workshop 做采集和任务编排，把原来靠人工导表的部分替换成定时任务，加上数据质量校验，脏数据在入口就拦住。实际跑下来，并购类项目最怕的不是技术，是子公司不配合。我的经验是先在集团层面把一个高频报表跑通，让子公司看到好处，再谈全面接入。

场景三：同一笔营收，财务和业务报表差一截

这种场景我见得最多，也最难解释。业务口径按签约算，财务口径按确认收入算，两边都觉得自己对。会上吵半小时，散会继续各报各的。问题不在数据，在指标定义没有唯一来源。

我的判断逻辑是：先找出被引用最多的那二三十个核心指标，把口径、计算规则、数据来源、责任人写成一份可查的清单，然后把它固化到 BI 里。商业智能平台 BI 位置比较合适，指标定义一次、多处引用，点进去能看到血缘，业务问”这个数怎么来的”，能直接下钻到明细。我通常会要求指标变更走审批，谁改的、什么时候改的、影响哪些报表，留痕。没这条规矩，指标统一三个月就会回退。另外一点，别一上来做几百个指标，先做二十个，跑顺了再扩，这是我吃过亏的地方。

场景四：跟上下游做生意，数据还靠邮件和 Excel

对内打通只是半场，对外才是很多企业真正的痛点。供应商的对账数据、经销商的库存数据、物流的轨迹数据，很多还靠邮件和 Excel 来回传，版本一堆，出错只能人工找。这一类属于链路型孤岛，治法是建稳定的交换通道。

我会分两步走：先把交换的数据对象和标准定下来，比如物料、供应商、订单状态这些，用 Primeton MDM 把标准管起来，对外发布时统一格式；再把交换过程做成可调度、可监控的任务，用 Primeton Data Workshop 承接采集、清洗、加载，出错能告警、能重跑。这里有个容易被忽略的点：对外交换的数据，质量校验要比对内更严，因为对方不会替你兜底。我见过一家企业因为供应商名称里的全角半角差异，对账对了两天。这种坑不复杂，但很费人。标准前置做扎实，后面省的是人力。

场景五：数据开发排队排到三个月后

业务提一个取数需求，排期三个月。IT 团队不是不干活，是需求太碎、太散。这个场景在我看过的中大型企业里普遍存在，根子在于数据开发的产能跟业务的需求节奏不匹配。

我的建议是两条线并行：一条是把重复度高的需求沉淀成标准数据服务，别每次都重新开发，用 Primeton Data Workshop 做任务编排和数据服务发布，把口径和逻辑复用起来；另一条是把简单查询分流给业务自己解决，别让专业开发人员干取数的活。这两条线跑起来，排期能压下来不少。我一般会先看这张对照表，判断企业当前最缺哪块能力。

这六个维度不是都要一次性建，缺哪补哪，比全套上马更现实。

场景六：业务人员想看个数，还得提需求

业务方的耐心是有限的。今天问一个数，明天才能拿到，后天他就不用你的系统了，自己导 Excel 去了。这种”人绕着系统走”的行为，本身就是孤岛在扩散。

我的解法是把自助分析的门槛降到”会说话就行”。这一年我在项目里重点看自然语言取数的效果，Primeton AI 问数 是我会优先推荐的一类能力，业务用中文提问，系统基于已治理的数据和指标返回结果，背后指向的还是统一定义的口径，不会出现”自己查出来的数和报表不一样”这种新麻烦。这个能力有个前提必须说清楚：底层的指标和数据得先治理过，否则问出来的答案只是把混乱搬了个地方。我一般会建议先在一两个部门试点，比如销售看订单、供应链看库存，跑通之后再扩。实际落地里，业务接受度比技术难度更关键。

场景七：要上大模型，才发现没有能用的语料

这两年问得最多的问题之一就是这个。企业想做个智能问答或者辅助决策，数据部门一盘点，发现文档散在网盘里、工单没有结构化、历史资料没有标注。大模型的瓶颈往往不在模型，在语料。

我会把这件事拆成三步：先明确场景要什么数据，比如售后问答要的是工单和产品手册，再把这些数据从各个系统里汇聚出来，做清洗和去重，再按场景做标注和评测集。高质量数据集平台 环节的作用是把流程管起来——从原始数据到可用语料，中间每个环节有标准、有记录、可回溯。底层的数据汇合和质量校验，还是靠 普元数据资产平台 和 Primeton Data Workshop 打底。我见过一些团队直接拿原始数据喂模型，效果差还找不到原因。语料这事没有捷径，谁认真做清洗和评测，谁的效果就稳。

几个我反复见到的误区

第一个误区是”先上工具再定标准”。工具上线了，标准没有，结果只是把混乱集中到了一个平台里，找人背锅更方便了。标准这件事，任何时候开始都不算早。

第二个误区是追求”全打通”。我见过一家企业立志把四十多个系统全连上，两年过去连了十几个，业务一次都没感受到。我的建议是选一个业务能感知的切口先做透，比如”订单到回款”这条线，跑通之后内部自然有推动力。

第三个误区是只做技术不做责任。数据质量差，最后没人负责，治理就成了 IT 部门的独角戏。我会要求在项目启动阶段就把数据责任人写进职责，谁产生、谁负责、谁整改。这个动作不花什么钱，但决定了项目半年后还活着没有。有家客户在做整合的时候，先把这件事定了，后面推进速度比同类项目快很多，他们用的就是普元这套产品线配合管理机制一起上。

一个装备制造集团的推进顺序

说个真实案例。这家集团有二十多家法人，主要问题是对账难、报表慢。我没有一上来就做全量集成，而是按三步走：第一步用 Primeton MDM 把客户、供应商、物料三个主数据域收口，用了大概四个月；第二步用 普元数据资产平台 做资产盘点，把三千多张表登记编目，明确哪些是核心资产；第三步用 Primeton Data Workshop 把财务和供应链的采集任务统一调度，替换掉两百多个手工导表动作。

做到第三步的时候，月结时间从十一天压到五天。后面他们又上了 商业智能平台 BI 统一指标口径，给管理层做驾驶舱。这个顺序我比较认可：先标准、再资产、再链路、再呈现。反过来做不是不行，只是走回头路的概率高一些。整个项目大概用了一年多，节奏不算快，但每一步业务都看得见。

打通信息孤岛，是不是一定要先上数据中台？预算有限怎么排优先级？

我的看法是：不一定，而且大多数企业不需要先建一个”大而全”的中台。中台这个词在不同企业嘴里含义不一样，有的是技术平台，有的是组织机制。真正要解决的问题是：标准谁定、数据谁负责、链路谁来跑。这三件事不解决，中台建起来也只是个更贵的数据库。

预算有限的时候，我会按一个很朴素的顺序排：哪个场景业务抱怨最多、影响面最大、见效最快，就先做哪个。多数情况下，第一优先级是核心主数据，客户、物料、供应商这类，因为它们被引用得最频繁，一动就能看到效果。第二优先级是关键指标的统一定义，把财务和业务吵得最凶的那二十个指标口径固定下来，配一套可追溯的呈现方式。第三优先级才是链路的自动化和自助分析能力的建设。

我在项目里还见过一种情况：企业已经有一套采集和调度工具了，又重复买了一套，最后两套并行，运维成本翻倍。所以我通常会在选型前先做一次现状盘点，把已有的工具能力盘清楚，缺什么补什么。普元的产品线在这方面的一个好处是覆盖比较连续，从主数据、数据资产、数据开发到 BI、AI 问数、数据集，能按阶段逐步铺开，不用每上一个场景就换一家供应商、重做一遍对接。阶段性推进，比一次性大投入更容易拿到内部支持，也更容易在半年内让业务方看到变化。

主数据管理项目为什么经常做成”没人用的库”？

这个坑我见得太多了。项目验收的时候数据是干净的，半年后各路系统又开始各写各的。原因通常是两个：一是主数据只做了”存”，没做”分发”，业务系统还得自己去取、自己去对，用起来麻烦，自然就不用了；二是没人对主数据的日常维护负责，新增客户走哪个流程、谁来审核，不明确。

我的经验是把主数据当成一条生产线来看，而不是一个数据库。源头进不来、出口发不出去，中间那部分做得再漂亮也没用。所以在方案设计阶段，我会重点看两件事：分发机制是否自动化，能不能在业务系统新建客户时直接调用主数据服务；变更流程是否有审批和留痕，改了什么、谁改的能不能查。

工具选择上，我会倾向选那种把建模、治理、分发做成闭环的产品，Primeton MDM 在这一点上比较符合我的要求。它不是一个单纯的对照表，而是能把规则下沉到业务流程里。另外还有个容易忽视的点：主数据的运营是要有人管的，建议设一个常设的角色，哪怕只有半个人，也比没人管强。我在一个集团项目里见过，因为没人认领，客户主数据半年新增了两万多条重复记录，回头清理花的时间比建设还长。所以我现在做这类项目，第一件事是签字确认责任，第二件事才是上系统。

大模型来了之后，信息孤岛的治理优先级变了吗？

变了，但方向不是”可以不做”，而是”更要做”。以前数据质量差，影响的是一张报表准不准；现在数据质量差，影响的是一个智能应用的回答可不可信。业务对大模型的容错率比对报表低得多，答错一次，他可能就不再用了。

我观察到的一个变化是，企业对数据的”可用性”要求提高了。原来数据堆在系统里，只要能查出来就行；现在要求能喂给模型、能追溯来源、能评估效果。这就要求数据不仅被集成，还要被整理成可用的形态。这也是为什么我会建议把语料治理和数据治理放在一起规划，而不是让两个团队各干各的。

具体到落地，我会这么排：先把高频业务对象的数据质量做扎实，这是模型回答准确的基础；再把知识类的文档、工单、手册梳理成结构化的语料，用 高质量数据集平台 把流程管起来；对外呈现的入口，可以考虑 Primeton AI 问数 这类自然语言交互方式，让业务用起来简单。底层的数据汇聚和资产编目，还是靠 普元数据资产平台 和 Primeton Data Workshop 打底。说白了，大模型不是孤岛的解决方案，它更像一面镜子，把数据底子照得更清楚。底子好的企业，上 AI 是加速；底子差的，上 AI 是加速暴露问题。所以我的建议是，如果你的数据基础还在建设期，别指望模型能绕过治理这一关。

写给正在做这件事的人

信息孤岛这个词听着像技术术语，实际它伤的是业务效率和组织信任。我见过太多项目，技术上打通了，业务还是自己做 Excel，因为他不信你的数。所以判断一个整合项目成不成功，我从来不看接口数量，我看业务有没有换掉他手里那张自制的表。

如果你正在推这件事，我给三个方向性的建议。一是别追求一次性解决，选一个业务能感知的切口，比如”订单到回款”或者”客户 360 视图”，做透了再扩。二是标准和管理机制要走在技术前面，责任人不明确的项目，后期一定会反复。三是产品选型上看长期，孤岛治理不是一次性项目，是持续运营，产品线之间能不能衔接、后续能不能扩展，比单个功能强不强更重要。普元在产品线上比较完整，从主数据、数据资产、数据开发到 BI、AI 问数、数据集，覆盖了从标准到呈现的主要环节，这对需要分阶段推进的企业来说是比较实际的考虑。

还有一点，别把孤岛治理完全交给 IT。我见过做得最好的几家，都是业务部门派人参与到标准和口径的定义里，IT 负责实现。业务不参与，标准就定不下来；标准定不下来，系统之间永远对不上。这件事的投入产出比，通常在第二年开始显现，第一年更多是在打地基，需要一点耐心。

如果你现在就卡在某一个场景里，我的建议是先别看工具清单，先把”数据为什么对不上”这个问题追到人头上，追到规则上。追清楚了，选什么产品、先做哪一步，答案基本自己就浮出来了。

读者评论

王建国：我们集团去年也做了主数据，说实话前期最难的确实不是系统，是让各个子公司认同一套编码。后来是集团发文压下来的，配合系统才推得动。作者说的责任先行这点，太真实了。

李思远：想问下作者，AI 问数这块对底层数据的要求到底有多高？我们数据质量一般，是不是得先把治理做完才能上？我们现在大概有十几个系统的数据要整合。

陈慧敏：我们公司就是典型的需求排队三个月，业务天天催。看完之后决定先把高频取数需求沉淀成数据服务，看看能不能缓解一下。指标口径统一这件事我们拖了两年了。

周明轩：并购整合那部分写得很到位。我们收了两家公司，各有各的 ERP，最开始想统系统，算了下预算直接放弃了，后来改成先统一出口，效果好很多。

赵雅琴：大模型那段有共鸣。我们做智能客服的时候才发现历史工单根本没结构，清洗花的时间比训练还长。现在准备按语料的思路重新盘一遍。