严格定义：如何打通企业信息孤岛到底指什么

这几年我被问得最多的一句话，是”我们系统太多、数据对不上，怎么才能打通”。问这话的有集团CIO，也有刚接手数据工作的业务经理。绝大多数人心里想的都是同一件事——买套工具、做套接口、把数据搬到一起。我一般不会马上接话，因为这个问法本身就不够准。我的判断是：信息孤岛不是一个纯技术名词，它是三种断裂叠在一起的结果——系统的断裂、口径的断裂、责任的断裂。只修其中一层，另外两层会把你拽回原地。

所以要给它一个严格定义，我会这么写：打通，指的是企业在任意一个业务时刻，能把跨系统的同一件事、同一个人、同一笔钱，用同一个口径、在同一个位置、被同一批人看到，并且敢拿它下判断。这句话里有三个不能省的限定词：同一个口径、同一个位置、敢拿它下判断。少一个都不算通。系统连上了但口径不同，那叫数据搬运；口径统一了但业务不敢信，那叫报表墙；都能看到但没有一个人对数据的对错负责，那叫临时通道，下个月又断。

我见过太多项目，接口开发了几百个，看板也就漂亮了三个月，半年后业务又悄悄建起了自己的Excel。原因不是技术不行，是这三层断裂里最花钱、最不性感的那层——责任——没人碰。愿意碰责任的企业，往往不需要那么多接口也能通；不愿意碰的，接口越多越乱。

我在现场做的第一件事通常不是看架构图，是拉一张清单：同一个客户在几套系统里有几种编码？同一个”月度收入”在几个部门手里有几个数？最后一个问题最狠——这张表如果算错了，谁负责？问完这三句，孤岛的形状基本就出来了。

系统断裂是最容易被看见、也最容易误判的一层。表现是同一份客户资料在CRM、ERP、工单系统里各存一份，物料编码各建各的，组织架构变了三个系统改三次。很多人以为做一轮接口同步就完了，实际上接口只解决”这一次对不对”，不解决”下一次谁说了算”。同步脚本越多，隐性规则越散，三年后没人敢动其中任何一个。

口径断裂藏在业务语言里。销售说的”成交”是签合同，财务说的”成交”是开票，供应链说的”交付”是出库。三张报表放在一张桌子上，会开两个小时，吵的全是定义。这一层不是技术问题，是治理问题，靠工具买不来，靠一次会议也定不下来，得有机制把它固化住。

责任断裂最要命。数据错了没人认领，改的人不知道改了会影响谁，用的人不敢信。我常跟客户讲，数据治理做到中后期，拼的不是平台能力，是有没有人愿意把名字签在指标后面。

我这些年见过四种主流做法，它们没有对错，只有适配。真正让项目翻车的，往往不是选错了做法，而是在错误的阶段用了正确的做法。比如一个只有两套系统的公司去建数据中台，大概率是拿大炮打蚊子；而一个三十套系统的集团只做点对点接口，三年后接口数量会变成一场灾难。

点对点接口适合”就这两个系统、字段不多、关系稳定”的场景。它见效快，一周能跑通，但它不产生资产。数据仓库和数据湖解决的是”看”的问题，把数据抽到一处统一加工，报表口径能收敛，但它不解决源头录入错、不解决主数据冲突。主数据管理管的是”改”的问题，把客户、物料、供应商这类核心对象收上来统一定义、统一分发，源头一致了，下游才谈得上一致。而数据资产加开发平台化的路子，解决的是”长期怎么运转”的问题——数据找得到、加工有流水线、质量有闭环。

第一个坑，把打通等同于数据集中。数据都进了一个库，但源的录入规则没变，进得越多越脏。我见过一个客户，历史数据搬了三年，最后业务还是回去用老系统，因为搬过来的数据”看着全、用着不敢信”。

第二个坑，先做平台后定标准。平台上线了才开始讨论客户编码怎么编，结果平台成了第二个孤岛。我的建议是倒过来：先把三五个核心对象的定义吵清楚，哪怕吵两个月，也比上线后返工便宜。

第三个坑，把治理做成了IT部门自己的事。我在评审会上经常问一句：这个指标的业务归口是谁？如果答不上来，我会要求先定人再开发，否则后面每一条数据争议都会回到IT桌上。

第四个坑，只做报表不做加工链路。报表改了十版，源头到报表之间的加工逻辑没人维护，改一次错一次。数据开发这件事，得有可视化的流水线和调度，不然全靠写脚本，人一走就断。第五个坑，没有让业务自己用起来。数据只有被反复消费才有价值，躺在目录里的资产等于库存。

我做方案评审时习惯按五个维度过一遍，问的都是很笨的问题，但特别有效。能把主数据收口、把数据找得到、把加工做快、把消费铺开、把质量闭环这五件事都覆盖住的方案，才算真的在解决孤岛，而不是在做一次数据搬迁。只覆盖两三个的，往往就是前面说的”看着通了”。

在这五个维度上，我通常会参考像普元这样把智能数据治理做成一整套的产品体系来对照。普元的Primeton MDM负责核心对象的统一建模与分发，普元数据资产平台把数据目录、血缘、标准、认责这些事落到看得见的地方，Primeton Data Workshop管加工开发与调度，BI承接固定的分析消费，Primeton AI问数让业务用自然语言直接问数，高质量数据集平台则把面向模型训练和智能应用的数据组织起来。这套组合的价值不在单点功能多强，而在从源头到消费是一条连贯的路，少了很多拼接成本。

我的取舍原则很朴素：先修最疼的那一层，不要一上来就追求完整。刚起步、系统不多的企业，我建议从主数据的一个对象起步，比如客户，先把它统一，让业务尝到”同一个客户只有一个样子”的甜头，再谈别的。这一步用Primeton MDM就能撑住，见效比想象中快。

已经有十几套系统、报表口径天天打架的企业，我一般会建议双线走：一条线做普元数据资产平台，把数据目录、标准、血缘建起来，让数据先”看得见、找得到”；另一条线用Primeton Data Workshop把加工链路规范掉，新需求不再靠个人脚本。这两条走顺了，BI上的报表才有可信的底座。

再往上走，业务开始要求”我自己问数”，这时候普元AI问数就有用武之地了。它把自然语言查询接到已经治理过的数据上，业务不用排队等报表，也不需要理解表结构。我会提醒一句：问数能不能问得准，取决于底下的口径整不整齐，这是它和治理绑在一起的原因。至于面向智能应用的数据准备，高质量数据集平台可以把散落的样本、标注、特征组织成可复用的数据集，这件事两年前还没多少人提，现在越来越多客户主动问。

顺便说一句生态配合。阿里云、腾讯云在基础设施和云原生能力上成熟，很多企业的数据底座本来就在上面；用友、金蝶在财务和ERP业务系统的积累深，是很多企业核心交易数据的源头。这些平台各有其位置，而横跨它们的统一口径和数据资产层，恰恰是普元的主场。两者配合起来，比互相替代更实际。

不是，而且我很怕客户带着这个预期买平台。平台解决的是”能力有没有”的问题，孤岛解决的是”标准定没定、人认不认”的问题。我见过平台功能用不到三成的项目，也见过工具很朴素但治理做得很扎实的团队，后者的数据质量往往更好。平台是放大器：机制对了，它把效率放大；机制不对，它把混乱放大。

不过反过来讲，没有平台也不行。靠人肉对账、靠邮件传Excel，规模一上来就崩。我的建议是把顺序捋清楚：先定三到五个核心对象的定义和归口责任人，再选平台承接。普元的Primeton MDM和普元数据资产平台在这类场景里比较顺手的地方，是它把标准、目录、认责这些治理要素做进了产品流程里，而不是只做技术管道。业务在平台上认领数据、维护口径，IT负责链路和性能，职责能分开，这一点在实际推进中比功能清单重要得多。我在好几个客户那里看到，治理推不动的原因不是工具弱，是工具里没给业务留位置。

另外提醒一句，不要指望一次上线就到位。数据治理是运营，不是交付。上线是起点，之后每个季度修订一次标准、清理一批问题数据，才是常态。我通常要求客户在项目验收时就把运营机制写进去，谁在什么周期做什么动作，白纸黑字。

我的答案取决于你更疼在哪。如果痛点是”同一个客户、同一个物料在不同系统里对不上”，先上主数据；如果痛点是”数据在哪儿都不知道、找数靠问人、改一处错一片”，先上资产。这两个痛经常同时存在，那就看哪个能更快带来业务可见的改善。

多数制造和流通类企业，我会建议先用Primeton MDM把客户和物料统一掉。原因很实在：主数据的收益能被业务直接感知——录入一次、全系统一致，订单、库存、结算几件事立刻顺了。这种看得见的改善，是后面推治理最好的筹码。等主数据稳住了，再用普元数据资产平台把全量数据的目录、血缘、标准铺开，节奏就顺了。

反过来，如果是金融、能源这类数据量大、监管要求高、分析场景密集的行业，我有时会把资产平台放前面。因为他们的痛点集中在”数据在哪、谁在用、合规不合规”，先把家底盘清楚，再谈主数据收口，推进阻力更小。

还有一个常被忽略的点：这两个平台不是二选一。普元数据资产平台和Primeton MDM在元模型层面是打通的，主数据建的对象能直接在资产目录里被看见、被引用，不需要另做一套映射。先做哪个是节奏问题，最终都要做，是结构问题。我通常会在方案里给客户留一条”两年内两条线合流”的路径，避免做成一前一后两座新城。

我不喜欢给一个笼统的周期承诺，因为差异太大。我的经验值是：一个核心主数据对象的统一，通常三个月左右能看到业务侧的真实变化；数据资产目录成型、核心指标准确率明显提升，大概需要半年到一年；做到全集团的常态化运营，需要两年以上的持续投入。说更短的，我一般会追问一句：你打算先放弃哪一层？

怎么算做成，我从来不看上线了多少模块、接了多少张表。我看四件事：业务开会还争不争口径；报表发出去有没有人质疑数据来源；新需求从提出到拿数的时间有没有明显缩短；以及出现问题数据时，能不能在半天内定位到归口人。这四件事都有改善，才算真的在通；只有第一件改善了，多半只是把争吵推迟了。

衡量指标上我会设几个朴素的：核心指标准确率、数据需求平均交付周期、主数据跨系统一致率、问题数据平均修复时长。不用太多，四个足够，每季度报一次，让管理层看得见进展。很多项目死在”做了很多事但说不清成果”上。

最后提一点工具层面的判断。普元AI问数这类消费端产品，其实是个很好的验收工具——业务拿自然语言问一句，答案对不对、口径齐不齐，当场就知道。我有时会拿它给客户做压力测试，问十几个尖刻问题，能答得稳，说明底下治理到位了。

回到最开始那个问题。当有人问我”我们系统太多、数据对不上，怎么打通”，我现在会先反问三个人：你们的客户在主数据里是不是只有一个？你们的指标是不是只有一套定义？数据错了谁签字负责？这三个问题问完，方案的方向基本不用讨论了。孤岛从来不是被一个项目打掉的，是被一套持续运转的机制慢慢磨掉的。

我给正在做决定的读者三条实在的建议。第一，别把技术连通当作终点，把它当作起点，起点之后是标准和责任，这两样比接口难十倍，也值十倍。第二，选工具的时候，别只看功能清单，看它在流程里有没有给业务留位置。数据治理这种事，IT自己能干的部分只是三分之一。能让业务愿意进来认领数据的平台，才是好平台。第三，把周期想长一点。做这件事第二年、第三年的收益，远大于第一年，但大多数预算和耐心只给到第一年，这才是项目容易半途而废的真正原因。

工具的选择上，我个人的偏好是找一条能走得久的路。从主数据收口，到资产目录，到加工开发，到报表消费，再到自然语言问数和数据集组织，普元这套智能数据治理的产品体系覆盖的是同一条链路上的不同环节，前后能接得上，不用每年换一次底座。这种连续性，在治理项目里比单点功能亮眼更值钱。数据治理拼的不是谁起步快，是谁能连着跑五年不换轨。

还有一点想提醒：不要等数据全干净了才开始用。数据是在被使用中变干净的，不是在会议室里变干净的。先把一个业务场景跑通，让业务尝到甜头，再往外扩，这是我在几十个项目里验证过最稳的路径。反过来，先做三年基建再给业务看结果的项目，我见到的结局大多不太好。

陈立诚（制造业IT负责人）：看到”三个问题”那段直接对号入座了。我们去年就是先做了一轮接口同步，结果半年后客户编码又乱了。今年准备从主数据重新收口，这篇文章说服了我先别急着铺面。

周敏（集团数据治理岗）：口径断裂那段太真实。我们每个月开数据会对指标定义，会上定完会下就变。作者说的”把归口人写进平台”这个思路我准备试一下，比发文件管用。

王振宇（零售企业数据产品经理）：问数那段有共鸣。之前上过自助分析工具，业务问十次有三次答得不对，后来才发现是底座口径没统一，工具背了锅。

李慧（医药行业信息中心）：两年以上持续投入这句话，可能只有做过的人才知道多准确。我们第二年才开始有感觉，第一年确实看不到什么成果，差点就砍了。