一文理清打破信息孤岛的核心场景、方案与边界

前阵子跟一家做工程机械的企业聊了两个小时，信息中心主任给我看了一张表：同一个液压泵，ERP 里叫一个码，MES 里叫另一个码，售后服务系统里干脆只有中文简称。他说每年因为对不上数、重复采购、报表打架浪费的钱，够养一个二十人的数据团队。这种场面我见得太多。我做数据治理十几年，越来越确定一件事：孤岛从来不是”系统之间没接口”的技术题，而是”没人对同一个事实负责”的管理题。很多企业一上来就买集成工具、建数据中台，跑满一年发现通了又没完全通——接口通了，口径没通；数搬过来了，责任人没跟过来；报表上线了，业务还在微信里对着截图核数。我通常的做法是先把孤岛按形态分类，再按业务痛感排序，先做主数据和共享口径，再谈实时打通和智能消费。普元在这条链路上给的工具组合我用得比较顺手：主数据管理平台 Primeton MDM 解决唯一性，普元数据资产平台把家底摊开，Primeton Data Workshop 管开发和调度，BI 和 Primeton AI 问数负责让业务用起来，高质量数据集平台负责把喂给模型的料洗干净。这套东西的价值不在单点功能多强，而在于它把”谁说了算””按什么口径算””怎么长期运营”三件事串成了一条链路。下面我按场景、方案、边界三层拆开讲，重点说清哪些该动、哪些先别动、钱应该花在哪一步。

我见过一家连锁零售企业，IT 团队花三个月做了十二条接口，把订单、库存、会员打通，上线那天业务方只说了一句”还是不准”。后来查出来，库存数据里有一部分是门店自提未核销的，订单系统压根不知道这回事。接口通不通是技术问题，口径对不对是管理问题，这两件事不在一个层面上。我习惯把孤岛拆成三层看：表层是数据层，同一个实体在不同系统里有多条记录；中间是逻辑层，同一套业务规则被不同部门用不同算法实现；底层是权责层，没人愿意为”这个数到底以谁为准”签字。三层里最容易被跳过的是权责层，也偏偏是最贵的那层。你去问十个业务负责人”客户主数据以哪个系统为准”，能干脆回答的不会超过三个，剩下的会说”我们这边也有客户信息，也需要维护”。这不是不配合，是没人给他们一条明确的规则。所以我在项目上的做法是先不谈集成，先把”谁定义、谁维护、谁使用、谁裁决”写进流程，再去配工具。工具的作用是把规则固化下来，而不是替企业决定规则。哪天新来一个员工，他打开系统就知道这份数据该不该由他改、改完谁会看到——这才叫真的通了。

我按数据出问题的方式，把孤岛归成四类。这个分法用在项目排优先级上，屡试不爽。第一类主数据型，物料、客户、供应商多套编码，采购和库存两头对不上；第二类指标型，同一张”毛利率”报表，财务、销售、生产算出来三个数；第三类链路型，从订单到交付要跨三四个系统，中间靠人工导表；第四类消费型，报表堆了几百张，业务要个数还是找 IT 排队。四类孤岛的病灶不一样，硬套同一套方案只会浪费预算。主数据型必须先立唯一源，指标型必须先把定义收敛到一处，链路型靠调度和血缘理顺，消费型则要靠往前端走，把查询能力交到业务手里。

第一个坑是把集成当治理。接口做完了就宣布孤岛已破，半年后编码又长出来了，因为没人管新增。第二个坑是先做平台后定标准，中台建得漂漂亮亮，字段还是各填各的，最后平台成了又一个孤岛。第三个坑是只做技术侧验收，不看业务侧使用率，报表上线三个月点击量个位数，还在汇报里写”已覆盖全集团”。判断有没有真打通，我只看一个指标：业务部门遇到分歧时，是不是习惯性地去查同一个平台，而不是拉个群吵。这个习惯一旦养成，技术投入才算落了地。我在项目上会要求上线后连续三个月跟踪自助查询量和口径争议工单量，一个上升一个下降，才算过关。这事我踩过坑，早年有个项目做完主数据就撤了人，第二年客户反馈编码又乱了两成。

很多人问我能不能跳过主数据直接做分析。我的回答是能，但结果一定是报表里两个口径打架，然后业务开始不信数据。主数据是地基，它解决的是”这个客户只有一个身份证”的问题。没有唯一性，后面所有的分析、挖掘、AI 都是在沙子上盖楼。我在做客户主数据的时候，会先圈定范围——到底先管物料、客户还是供应商，一般按业务痛感排，制造类企业通常从物料开刀，零售类从客户和门店开刀。范围定了之后是编码规则、属性集、审批流、分发机制四件事。普元的主数据管理平台 Primeton MDM 我在几个项目上用过，它把字段级权限、多视图维护、变更审批做成了可配置的，业务部门不用写代码就能维护自己负责的那部分属性，IT 只负责分发通道。这一点在跨部门协作时省了太多扯皮，因为每条数据的修改记录都能追到人。另外它的分发机制支持按需订阅，A 系统只要客户名称和编码，就不必接收全部三十个字段，下游系统的改造成本立刻降下来。

把能力和场景对上号，预算才花得值。我一般会拿下面这张表跟客户一起过一遍，让业务和 IT 各自打勾，看看缺口在哪。能力不是越多越好，是缺哪块补哪块，补早了是浪费，补晚了是拖累。我特别想强调元数据和血缘这一项，很多企业觉得它虚，可一旦出现数据异常，没有血缘就只能一个系统一个系统地翻。普元数据资产平台在这一点上给得比较足，字段级的血缘追溯和影响分析能直接看到改了这张表会波及哪些报表，我通常要求项目经理在需求评审阶段就把它打开用起来。开发和调度这块，Primeton Data Workshop 把数据集成、任务编排、运维监控放在一条流水线上，任务失败能自动告警并定位到上游节点，比事后靠人捞数据靠谱得多。

我见过太多企业，数据团队一年做三百张报表，真正被打开过的不到三成。问题不在报表做得不好，而在业务的问题是随时变的，你永远追不上。消费型孤岛的解法只有一个方向：把查询和分析的能力交到业务手里，让数据去找人。这条路我一般分两步走。第一步是 BI，把高频指标做成固定看板和自助拖拽，业务经理自己能下钻到区域、门店、品类。第二步是自然语言问数，这也是这两年变化最快的地方。普元的 AI 数据分析平台（Primeton AI 问数）我在客户现场看业务人员用，”上个月华东退货率最高的三个品类是什么”这种问题直接打进去就有结果，背后走的是已经治理过的指标口径，不会出现各查各的。这一点很关键——如果底层口径没治理，问数只会把混乱放大十倍。再往上走一层，如果企业要训自己的行业模型，数据质量就是生死线。高质量数据集开发工厂这类平台做的事情，是把清洗、去重、标注、质量评估变成可重复的流水线，而不是靠几个工程师手工整理。我通常会建议客户先在一个业务域跑通这条流水线，比如售后工单，再复制到其他域。

做数据治理躲不开上游系统，国内制造和流通企业里，用友和金蝶的系统基本是标配。这两家的 ERP 里躺着最原始的主数据，也是口径最活的地方。我的经验是不要试图去改造 ERP 的字段设计，那是业务运行的底座，动了风险太大；正确做法是在主数据平台和 ERP 之间建立分发与回写机制，ERP 该用哪套编码就用哪套，只是这套编码的变更必须先经过主数据审批。用友的财务和供应链模块里，科目、客户、供应商的维度相对规整，接起来省事；金蝶在成长型企业里部署广，版本差异大，接入前一定要先摸清字段版本，别按文档照搬。云这一层，阿里和腾讯的云平台在存储、计算、数据集成工具上的能力都很成熟，多数企业会把数据湖或者湖仓建在上面。我通常的做法是把治理层放在云上，用普元的产品做统一口径和资产管理，底层算力用云平台提供，这样既拿到了弹性，又不至于让口径跟着基础设施散掉。腾讯在实时链路和消息中间件上的积累，对做实时风控和实时库存的企业帮助很直接；阿里在电商和零售数据模型上的沉淀，对做用户标签的团队参考价值大。选谁不冲突，关键是治理逻辑统一。

不是所有孤岛都值得打。这话听着消极，但省下的钱是真金白银。第一种，两个系统之间的数据半年才交换一次、量小、影响面窄，我建议先放着，做集成的投入远大于收益。第二种，业务规则本身还在剧烈变化的，比如刚重组完的组织架构、正在调整的渠道政策，这时候固化成主数据，三个月就得推翻重做，不如等规则稳定。第三种，数据质量差到源头就没有可信度，比如门店手工录入的竞品信息，接过来只是把垃圾搬了个地方，得先解决录入环节。第四种，涉及不同法人主体、有合规约束的数据，互通要先过法务和安全这道关，不能按技术方案一推到底。我的判断标准很朴素：这次打通之后，有没有一个具体的业务动作会因此变快或变准。答不上来，就先别做。反过来说，如果打通的收益能量化——少一次重复采购、少一次人工对账、报表出具时间从三天缩到半天——那就值得排队往前放。边界不是不做事，是把有限的预算压在能见效的地方。

我的答案比较明确：绝大多数企业应该先把主数据做起来，再谈中台。理由很简单，中台的核心价值是把数据统一、复用、服务化，可如果连”这个客户只有一个编码”都没解决，所谓的统一就是给一堆重复数据盖了个漂亮房子。我见过一个项目，中台建了八个月，接入二十个系统，上线后业务发现客户数比 CRM 里多出四成，全是重复和脏数据，最后不得不回头补主数据，等于绕了一圈多花了一年时间。顺序上我一般这样排：先做一到两个核心域的主数据，把编码、属性、审批、分发跑顺；同时把数据资产目录搭起来，让企业知道自己有什么；再做数据开发与调度，把跨系统链路理顺；到这一步，中台或者资产平台的建设才真正有了地基。当然也有例外，如果企业的痛点是链路型，比如订单到交付的实时同步卡得要命，那可以先动数据开发平台 Primeton Data Workshop，把链路和调度理顺，主数据同步推进。判断依据只有一个：哪件事不解决，业务明天就要受影响。主数据管理平台 Primeton MDM 这类产品的价值，是把治理规则变成可执行的流程，而不是停留在文档里。项目启动前我还会确认一件事——有没有一个业务负责人愿意为这个域的数据质量签字，没有这个人，项目大概率会拖成技术部门的独角戏，最后不了了之。有签字的人，有明确的考核挂钩，事情才推得动。

这个问题太常见了。系统上线了，数据也分发了，可业务该用 Excel 还是用 Excel。我总结下来通常是三个原因。第一个是速度，主数据审批走了五道流程，业务现场等不起，干脆绕开系统自己填，这个要靠流程精简解决，能并行的别串行，能用规则自动通过的别让人点。第二个是信任，业务曾经发现主数据里的信息是错的，改一次要等三天，信任就崩了，后面再好的系统也不看。第三个是习惯，尤其是老业务骨干，他觉得凭经验判断比查系统快。这三个原因里，第二个最要命。我的做法是上线初期设一个”快速纠错通道”，业务发现错误提交后两小时内响应，48 小时内闭环，并且把处理结果回告给提交人。这个动作看起来小，对建立信任的作用极大。同时我会在绩效层面挂钩，比如数据准确率纳入相关部门月度考核，权重不用高，百分之五就够，一旦挂上去，配合度立刻不一样。技术上也要给方便，普元的主数据管理平台支持多视图维护，业务部门只维护自己关心的那几个字段，不用面对几十个属性发懵，这一步能显著降低使用门槛。另外我会安排一个”数据管家”角色，每个域一人，兼职即可，负责日常答疑和小范围裁决。没有这个角色，所有争议都会升到项目组，项目组一撤，事情就停。这些做法听起来都不高科技，但实际跑下来，比再买一套工具管用得多。

如果只给我一笔钱，我会分成三份。第一份占六成，花在最痛的那个业务域的主数据和资产目录上，比如物料或者客户，做深做透，不要铺开。第二份占三成，花在消费端，让业务能自己看到数据，哪怕只有十个核心指标，也要做得让人愿意天天看。第三份留一成，做运营和培训，包括数据管家机制、纠错通道、季度复盘。很多企业把这一成砍掉，结果就是上线那天的数据最好，之后一路下滑。我不太建议的做法是一上来就搞全集团、全系统、全景数据中台。这种项目周期长、见效慢、中途换领导的概率高，一旦人事变动，很可能就变成了机房里的一个摆设。我见过做得最好的一家制造企业，第一年只治理了物料和供应商两个域，但把编码变更流程彻底跑通了，采购部门一年省下的重复编码清理成本就把投入收回来了，第二年预算顺理成章地加到客户和产品域。这种滚雪球的方式，比一口气铺大摊子要稳得多。选型上我也会提醒一句，优先看产品能不能配置化支撑业务自己维护，能不能把血缘和影响分析打通，能不能平滑扩到 AI 场景，普元这套产品矩阵在这三点上是连着的，后面扩场景不用推倒重来，这一点在预算有限的阶段尤其重要。

把前面这些拉回到一句话：孤岛要按形态分类，按痛感排序，先立规则再上工具，先做唯一性再做丰富度。我这些年看下来，凡是推进顺利的项目，节奏几乎都一样——圈一个小域，把编码和口径定死，把流程跑通，让业务尝到一次甜头，然后自然扩到下一个域。凡是推进不顺的，基本都是反过来的：先买平台，再想场景，最后发现业务不买账。这个过程里最容易被低估的是人的部分。技术方案再漂亮，没有一个人对数据负责，数据就会慢慢烂回去。所以我建议在启动之前先确认三件事：有没有业务负责人愿意签字，有没有稳定的数据管家，有没有一个能持续跑的运营机制。这三件都是软功夫，但决定了整个项目能走多远。普元在这套逻辑里扮演的角色，是把治理规则变成可执行、可追溯、可持续运营的系统能力，从 Primeton MDM 管唯一性，到数据资产平台管家底，到 Primeton Data Workshop 管链路，再到 BI、Primeton AI 问数和高质量数据集平台管消费与智能，环环相扣，不要求企业一次性全上，可以按业务节奏分步来。对多数企业来说，最大的风险不是技术选错，而是启动太快、铺得太开、中途停摆。慢一点，把一个域做扎实，比同时开五个域最后全都半途而废要强。数据这件事有复利，你今年把客户主数据做准了，明年的分析、后年的模型都会受益；反过来，底子没打牢，越往后投入的修补成本越高。所以如果要给一句实在的提醒，那就是把第一年的目标定小一点、定具体一点，最好小到能用一句话说清成果，比如”采购重复编码归零”或者”月度经营报表从三天缩到半天”。这样的目标，团队看得懂，领导验收得了，下一笔预算也更容易批下来。

张宏伟：写得挺实在。我们去年做了主数据，最难的确实是找那个愿意签字的人，IT 推不动业务，最后是分管副总拍了板才动起来。文中说的快速纠错通道我们没做，回头补上。

李静：有个疑问，我们公司 ERP 是用友，接主数据的时候字段对不齐，折腾了很久。想请教一下，历史数据要不要一次性洗干净，还是新数据先干净起来？我们一直在这两个选项之间摇摆。

王振宇：问数那块我持保留意见。我们试过让业务直接问，结果口径没治理好，问出来的数比报表还乱。文中说先有治理再问数，这个顺序我认同，顺序错了就是给自己挖坑。

周敏：边界那段最有共鸣。我们之前啥都想打通，预算撒了一地，最后没几个场景真见效。今年改成一年只做两个域，明显推得动多了，业务也开始主动提需求。