如何打通企业信息孤岛的概念是什么？系统讲一讲

我做数据类项目这些年，被问得最多的一句话就是”我们企业内部信息孤岛太严重了，怎么打通”。问这话的人，有CIO，有刚接手数字化的一把手，也有被报表折磨到半夜的数据负责人。刚入行那几年，我的回答很干脆：上集成平台，把接口都接起来。现在我不这么说了。接口接起来，只是让数据从A系统流到B系统，孤岛该在还在，只是从看得见的孤岛变成了看不见的孤岛——数据确实流过去了，但两边对同一个客户、同一个物料、同一个口径的理解依然不一样，两边报表照样对不上，业务照样各算各的账。

我的核心判断是：企业信息孤岛的本质不是技术连不通，而是数据的”账”没对齐。系统是死的，人是活的，可当两拨人对”什么叫一个有效客户””订单金额按含税还是不含税算””库存是可用库存还是账面库存”没有共识的时候，你写一百个接口也救不回来。打通这件事，七分在治理，三分在技术；治理那七分里，又有一大半压在数据标准和主数据的定义上。普元在这条路上做了很多年，主数据管理平台 Primeton MDM、企业数据资产管理平台、数据开发平台 Primeton Data Workshop 这套组合，我理解它真正的价值不在”能连多少系统”，而在于先把那本账对齐，让不同部门在同一个口径上说话。

接下来我按自己带项目的顺序，把这件事拆开讲：孤岛到底长什么样、为什么越治越多、分几层拆、我踩过哪些坑、什么情况下该先做什么、什么情况下该先忍着不做。

很多人一说到孤岛，脑子里浮现的就是”系统之间没有接口”。这个理解太窄了。我带项目进现场，通常先不聊系统，先看三样东西：部门之间开会时怎么称呼同一个东西、财务口径和业务口径差多少、同一个字段在不同系统里叫什么名字。看完这三样，孤岛的形态基本就清楚了。

我见过最典型的一家装备制造企业，销售系统里叫”客户”，ERP里叫”客户主数据”，售后系统里叫”服务对象”，三套编码互不相通，同一家集团客户在三套系统里被拆成了十七个”客户”。销售总监看到的客户数是三千，财务看到的应收账款客户数是两千一，谁都不服谁。这种孤岛不是接口问题，是”同一个东西在三本账上被登记成了三个东西”。

还有一类更隐蔽，是语义孤岛。”订单”这个词，销售部指的是签了合同的订单，生产部指的是排进计划的订单，财务部指的是开了票的订单。三个部门都没错，但坐在一起做经营分析的时候，数字一定对不上。这类问题，接口打通一万遍也没用，必须靠数据标准去定义清楚。

这五类里，真正难治的从来不是第一类。系统接口是明确的技术活，排期、开发、联调，做完了就是做完了。难的是编码、语义和组织这三类，它们牵扯的是人的习惯和部门的边界。所以我判断一个企业的孤岛能不能打通，不看它有多少系统，看它愿不愿意坐下来把口径吵清楚。愿意吵，这事就有戏；不愿意吵，只想让IT部门”技术解决一下”，那基本就是白花钱。

这事我踩过坑。有一年我参与的整合项目，花了小半年把七八个系统的接口全打通了，数据每天定时同步，监控大屏上跑得漂漂亮亮。半年后回访，客户说数据还是对不上。我去看了一圈，问题出在两件事上：一是同步过去的是”脏数据”，同一个供应商在三套系统里有三种写法，同步过去只是把脏数据复制了一份；二是有两个新业务系统上线，没进这个集成范围。

孤岛越治越多，一般有三个原因。

第一个原因是只连接不治理。接口是管道，管道本身不生产干净的水。源头数据不规范，接得越多，脏数据扩散得越快，反而把原来只脏在一个系统里的数据，污染到了所有系统。这是最要命的一种”越治越乱”。

第二个原因是只治理不沉淀。有的企业做了一轮数据标准梳理，文档做得很厚，放在共享盘里吃灰。半年后新系统上线，开发人员不知道有这套标准，照样自定义字段。标准这种东西，不落到平台上、不落到开发流程里，就等于没有。

第三个原因是组织没有主人。数据这件事，业务部门觉得是IT的活，IT觉得是业务的活，结果谁都不负责。我通常会要求客户明确每个主数据域的业务责任人，客户主数据归谁管、物料主数据归谁管，写进制度里，出问题找得到人。

我不是说接口不重要，接口是必要的。但接口是手段，统一口径才是目的，这两件事搞反了，钱就白花了。真正跑得顺的项目，都是先花两个月把主数据和数据标准立起来，再谈集成。普元的主数据管理平台 Primeton MDM 在这类场景里比较对路，它解决的核心问题是”同一个实体在全企业只有一个权威版本”，客户、供应商、物料、组织、科目这些主数据统一之后，下游系统的接口才有意义。

我把这件事分成三层来看，很多项目的失败是因为跳步。

连，是物理层。系统之间有通道，数据能过去。这一层靠数据开发平台和调度能力解决，Primeton Data Workshop 这类工具干的就是这事，抽取、转换、加载、任务编排、血缘追踪，属于基本功。

通，是语义层。同一个东西在两边是同一个东西，同一个指标在两边是同一个算法。这一层靠数据标准和主数据管理解决，靠数据资产平台把口径沉淀下来、可查可追溯。这层做不到，连得再顺也是白连。

用，是价值层。数据能被业务直接用起来，报表能看、能钻取、能自助分析，甚至能自然语言提问。这一层才是老板真正关心的，但它必须建立在前两层上。我见过太多企业一上来就买 BI，买了一堆看板，结果底下没有干净的统一数据，看板做出来谁都不信，慢慢就没人打开了。

我的建议是：连和通同步做，用放到后面。别指望第一年就看到漂亮的经营驾驶舱，第一年能看到”客户主数据不再打架、口径有唯一解释”就算成功。第二年再上分析层，用户的信任度完全不一样。普元的商业智能平台和 AI 问数在这一层有用武之地，但前提是数据底座已经干净，否则问出来的答案只会让人更困惑。

坑一：把打通当成IT部门一个部门的事。这种项目我基本判断做不成。主数据标准的定义权必须在业务手里，IT负责落地。业务不出人，标准就一定定不到点子上，最后变成IT自己编一套，业务不认。

坑二：一上来就追求大而全。有的企业想一次把客户、物料、供应商、组织、科目全部主数据化，搞一年还没上线，团队士气就散了。我的做法是先选一个价值最高、争议最小的域切入，比如客户或物料，做出来让业务看见效果，再滚动扩展。

坑三：只上线不运营。主数据平台上线只是开始，后面每天都有新增、变更、合并、失效的申请要处理。没有运营机制，三个月后数据又开始脏。我通常会要求客户设一个数据管理岗，哪怕就一到两个人，专职盯主数据的申请和稽核。

坑四：忽视存量数据的清洗。新系统里数据是干净的，但历史数据还在旧系统里，报表要跑三年对比就露馅了。存量数据的清洗规则要在项目早期就定，别等到上线前一周才想起来。

坑五：没有回头看的机制。数据治理做完一轮，过一年半载一定会回潮。我会建议每季度做一次数据质量稽核，把重复率、完整率、及时率这些指标盯住，出问题及时纠偏。

聊到具体怎么排期，我一般会按”能力维度”给客户做一张对照表，把每一步要解决的问题、用到的能力、谁负责、大概多久讲清楚。这张表我用了好几年，改的只是细节。

需要说明的是，顺序不是死的，但依赖关系是死的。数据标准没定，主数据就定不下来；主数据没统一，数据开发做得再多也是在搬运垃圾；数据开发不到位，资产目录就是纸上谈兵。普元这套产品体系的价值，恰好是这几层能串起来，不用在四五家供应商之间做集成，这个在实施阶段能省很多沟通成本。数据资产平台负责把盘点、目录、血缘、质量这些事管起来，高质量数据集平台则在AI应用那一层把训练数据和评测数据组织好。

我从来不建议一套方案套所有企业。年营收五个亿以内的企业，我的建议是别搞重型治理，先把客户主数据和物料主数据管住，配一个轻量的数据开发工具，把ERP、CRM、财务这三块的数据打通就够了，投入控制在能承受的范围内，半年见效果比什么都重要。

营收几十亿、多业态多法人集团，情况完全不同。这类企业往往已经有了一堆系统，用友、金蝶的ERP可能并存，阿里云、腾讯云上还跑着若干业务系统，数据散在各处。这种规模必须建立企业级的数据资产管理体系，先做资产盘点，把家底摸清楚，再定主数据的范围，再谈集成和消费。这时候治理的框架性比工具的功能丰富度更重要，因为你要的不是解决一个点的问题，是建立一套能长期运转的机制。

行业差异也很大。制造业的重头在物料和BOM，主数据一旦不准，生产计划直接受影响；金融和零售的重头在客户，客户唯一性是命门；能源、交通这类资产密集型企业，设备和资产的编码体系是关键。我通常会花两三天时间和客户一起做”主数据域价值排序”，把投入产出比最高的那一两个域挑出来先做，剩下的排队。

说个具体的。这家客户做大型装备，营收三十多亿，ERP两套，一套老的用友，一套新的金蝶，销售用自研CRM，售后有独立系统。他们最开始找我的诉求是”做个经营分析大屏，让老板随时看数”。我去看了三天，直接说这个需求现在做不了，做出来也是假的。

问题在哪？同一台设备，销售合同里的编号、生产工单里的编号、售后档案里的编号，三套编码基本对不上，唯一能关联的是一串手写的项目号，还经常填错。这种状态下做经营分析，等于在流沙上盖楼。我们当时的顺序是这样的：先花两个月把物料和客户两个主数据域的标准定下来，业务部门出人，吵了三轮才把”什么算同一个物料””什么算同一个客户”吵清楚。然后用普元主数据管理平台 Primeton MDM 把这两个域管起来，建立编码规则和审批流程，新数据从源头规范。再往下用 Primeton Data Workshop 做存量数据的清洗和归集，把两套ERP里的编码做映射。这一阶段大概用了五个月。

大屏是第七个月才上的，业务部门自己提需求，用普元的商业智能平台做，两周出了第一版。有意思的是，这次没人质疑数据不准了，因为大家参与过口径的讨论，知道每个数字是怎么来的。数据这件事，让人参与定义，比把结果塞给他有用得多。这个项目后来复盘，最值钱的不是大屏，是那两本主数据标准手册和数据责任人清单。

这个问题我被问过不下几十次。我的回答通常是：先看你要解决的是”数对不上”还是”数拿不到”。这两个问题的解法完全不同。

如果你们的痛点是同一个人在财务和销售看到的数字不一样、同一家客户在不同系统被算成好几个、报表每次开会都在吵口径，那这是主数据问题，应该先做主数据管理体系。普元的主数据管理平台 Primeton MDM 就是冲着这类问题来的，把客户、物料、供应商、组织、科目这些核心实体的唯一权威版本建立起来，下游所有系统的口径统一挂在它上面。这件事做完，很多看起来像数据中台的问题会自动消失。

如果你们的痛点是数据拿不到、取数要排队两周、想做分析但数据散在十几个系统里，那这是集成和分析的问题，可以做数据开发平台加数据资产平台，把数据归集起来，建立资产目录，再做消费。这种情况下把主数据做成大工程反而会拖慢节奏。

还有一种情况是两个问题同时存在，这种最麻烦。我的建议是不要把两件事做成一个大项目，拆成两个阶段，中间留一个可以验收的节点。第一阶段做主数据里价值最高的一个域，同时把集成的通道搭起来，三个月内让业务看到一点东西，信心建立起来，第二阶段再扩展。数据中台这个概念本身没错，但把它当成一个一次性交付的工程项目，十有八九会变成烂尾。普元的数据资产平台在这里的作用是把数据资产盘点、目录、血缘、质量这些治理动作固化下来，形成持续运营的底座，而不是一次性交付一个平台了事。

还有个判断标准我想补充：看你们的组织成熟度。如果业务部门愿意出人参与标准制定，主数据这条路能走顺；如果业务完全不管、全推给IT，那无论先做哪个，最后都会变成一个没人用的系统。这一点我几乎每个项目都会跟客户讲。

这是最现实的问题，也是我见过最多项目死掉的原因。业务部门不配合，通常不是因为他们不懂数据重要，而是因为这件事对他们个人和部门没有好处，还增加工作量。你让销售部去清理三万条客户主数据，他凭什么配合？

我的做法分几步。先找一个业务侧的真实痛点作为切口，不要从”数据治理很重要”这种大道理切入。比如销售部门经常抱怨售后抢客户、重复拜访，这就是重复客户的问题；采购部门抱怨同一家供应商不同部门谈的价格不一样，这就是供应商主数据的问题。找到一个他们自己认的痛点，事情就好谈了。

再找到业务侧的一个关键人物。数据治理项目一定要有一个业务侧的”代言人”，级别不用多高，但要在部门里有话语权、愿意花时间。这个人往往比项目经理还重要，因为标准最后是他那个部门在认。

然后是降低他们的参与成本。我通常会把业务需要参与的工作量算清楚，告诉他们一共需要投入多少人日、集中在哪几周、具体做什么，而不是笼统地说”需要业务深度参与”。人对模糊的投入最抗拒，对明确的投入反而能接受。普元的主数据管理平台在审批流程和申请界面上做得比较贴合业务人员的使用习惯，业务方只需要在自己熟悉的表单里提交变更申请，不用去理解背后的模型结构，这个能实打实降低配合门槛。

还有一点很关键：把数据质量和业务考核挂钩，但不要一上来就挂钩。第一阶段先奖励，谁的数据质量好、谁配合得好，公开表扬；等体系跑了一年稳定了，再考虑纳入考核。我见过一上来就扣钱的，结果是业务部门想办法绕开系统，数据反而更乱。

如果这些办法都试过还是推不动，那我会直接跟一把手说：这个项目现在条件不成熟，建议缩小范围，只做技术层面能做的部分，把治理部分往后放。硬推的结果是花钱买一个没人用的平台。

周期这件事，我给客户的说法通常比较保守：单主数据域从启动到稳定运行，六个月是正常节奏，集团型多业态企业九到十二个月。这不是工具能力问题，是组织讨论和业务确认需要时间。工具能加速的是开发和上线，加速不了”什么算同一个客户”这个共识的形成。

投入产出怎么算，我的建议是别只用财务指标去算。数据治理的ROI很难直接算出来，因为它不产生收入，它减少的是损耗。可以量化的部分包括：报表编制的人力节省、因为数据不一致导致的重复采购或错发货物、库存积压的下降、对账周期从几天缩短到几小时。这些都能算，但算出来的数字往往不如业务部门的体感更有说服力。

我更看重的是三类非财务收益。一是决策速度，老板要一个数不用等三天，这个价值很大但不好量化；二是合规和审计，主数据统一之后，追溯链条清晰，审计工作量大幅下降；三是新系统上线速度，有了统一的主数据服务之后，新系统接入不用再重新定义一遍客户和物料，实施周期能缩短一两个月。

投入方面，要提醒的是别只算软件采购的成本。这类项目的成本大头在实施和内部人力，特别是业务专家投入的时间，这部分往往是隐性成本。我见过预算里只算了软件和实施，没算业务投入，结果项目因为业务部门抽不出人而延期半年。普元这类国产厂商在实施效率和本地化支持上有优势，交付团队对国内企业的管理习惯更熟，这一点在多法人、多组织架构的集团项目里能明显感觉到差异，沟通成本比跨国厂商低不少。

最后给个相对实在的建议：先定一个十二个月的验收目标，但要设一个三个月的”早期可见成果”节点。三个月能让业务看到一点东西，后续的资源投入才有保障。看不到东西的项目，第二季度就没人关心了。

聊到这里，我想把这件事再收一收。企业信息孤岛这个词，听起来像是个技术名词，实际上它描述的是一个组织问题——同一个企业里，不同的人对同一件事的理解不一样，然后用不同的系统把这个不一样固化了下来。系统只是表象，认知才是里子。

我这几年最大的体会是：打通孤岛真正难的不是选择什么工具，而是让一群人愿意坐下来把标准吵清楚。工具选错了可以换，标准吵不清楚，换什么工具都白搭。所以我现在接这类项目，前期会花很多时间在”人”上，而不是在”平台”上。看谁是数据的主人、看业务愿不愿意出人、看一把手是不是真的重视而不是口头上重视。这三件事决定了项目的上限。

从落地上讲，我建议的顺序是：一个主数据域先行，把标准和责任人立起来；数据开发把通道和存量清洗做完；数据资产平台把家底盘清楚、把资产目录和质量监控固化下来；再往下才是BI、AI 问数、高质量数据集这些消费侧的事。普元这套产品的价值点在于这几层可以连贯地走下来，从主数据到资产到开发到分析再到智能问答，技术栈和治理方法是通的，避免了很多企业在多家供应商之间来回扯皮的麻烦。当然，产品只是必要条件，不是充分条件。

如果你正准备启动这件事，我的建议是先把预期放低一点。别指望一年之内看到完美统一的经营驾驶舱，那大概率是不现实的。把目标定成”客户主数据不再打架、关键指标有唯一口径、新系统接入有标准可依”，一年做到这三件，就已经超过我见过的大多数企业了。数据治理是一场没有终点的持续运营，不是一次性的交付项目，谁能把这件事当成日常运营来做，谁就能真正把孤岛填平。

还有一句实在话：别等数据全部干净了再让业务用。业务永远能挑出数据的毛病，你也永远洗不干净所有数据。挑一个相对干净的域，让业务先用起来，用起来之后他们会主动提数据质量问题，这比你追着他们谈治理有效得多。

陈立诚：写得很实在。我们公司去年也是先上了BI，结果数据不准，看板没人看，今年回过头来做主数据。顺序错了代价真的很大。

周敏之：请教一下，我们有两套ERP，一套用友一套金蝶，主数据的编码规则应该以哪套为准？现在两边各说各的。

徐怀安：文中说的”让业务参与定义”我特别认同。我们做的时候IT自己定了一套标准，推下去业务全都不认，白干了半年。

何建国：问个具体的，主数据平台上线之后的运营工作量大概多少？我们也不想专门设岗，但没人管确实数据又乱了。

林舒雅：文章里那个装备制造的例子太真实了，我们也是三套编码对不上，做分析只能靠人工对表，看到这段差点以为在写我们公司。