如何打通企业信息孤岛落地分几步？这份SOP直接照做

一、我判断企业能不能真打通孤岛，先看这三件事

我做过十几个数据类项目，见过太多企业把”打通信息孤岛”当成一个技术活，上来就问接口怎么调、中间件选哪个、要不要上一个数据中台。实际跑下来，信息孤岛从来不是技术问题，而是权责问题、标准问题和顺序问题。一个 ERP 里的客户编码和 CRM 里的客户编码对不上，你写再多的 ETL 脚本也是白搭；销售部不愿意把客户数据交出来，你上一套再贵的数据平台，数据也进不来。所以我看一个企业能不能真打通孤岛，先看三件事：一是有没有一个人或一个部门能对全公司的数据标准拍板；二是有没有把主数据这类”公共资产”单独拎出来管；三是有没有按”先定标准、再通数据、后做应用”的顺序走，而不是反过来。

这三件事听着简单，落地时九成企业会栽在顺序上。我见过一家制造企业，先花大价钱买了一套 BI 工具，想让老板看实时报表，结果发现各系统数据口径完全不同，报表做出来两个部门对不上数，项目直接停摆。后来他们换了个思路，先上主数据管理平台 Primeton MDM 把客户、物料、供应商这几类核心主数据统一起来，再去谈数据打通，半年后同样的 BI 需求，两周就交付了。这个对比很说明问题：孤岛的本质是”同一个东西在不同系统里有不同名字和不同定义”，你不先把定义统一，通道修得再宽，流的也是浑水。

所以这份 SOP 我不打算写成技术方案，而是按我实际操盘的顺序，拆成可照做的几步。如果你正被”数据对不上、报表出不来、跨部门扯皮”困住，按这个顺序走，比盲目上工具靠谱得多。下面我会先从趋势和真实场景讲起，再讲痛点和误区，然后给出分步做法，穿插一张对比表和一张能力对照表，方便你对照自己企业的情况做取舍。

二、孤岛不是一天形成的，也不会靠一个项目消失

2.1 我观察到的三个真实变化

过去五年，我接触的企业在数据这件事上有三个明显变化。第一个变化是系统越来越多，不是越来越少。十年前一家中型企业可能就一套 ERP 加一套 OA，现在动辄 ERP、CRM、MES、SRM、HR、财务共享、电商中台十几套，每上一套系统就多一个数据源，系统上得越多，孤岛的墙就越厚。第二个变化是业务对数据时效的要求从”月报”变成了”实时”。以前财务月底出报表就行，现在老板开会就要看昨天的销售数据，运营要看实时的库存周转，时效要求一上来，原来靠人工导数、Excel 拼表的土办法立刻撑不住。

第三个变化是 AI 来了以后，数据质量的短板被彻底暴露。我见过不少企业兴致勃勃要做 AI 问数、要做智能分析，结果一问”上个月华东区毛利率是多少”，系统给出的答案和财务口径差一大截。AI 不会替你解决数据口径问题，它只会把口径混乱放大。这也是我为什么一直强调，做数据打通要先打地基：主数据、数据标准、数据质量这三样不稳，上面盖什么楼都晃。

2.2 一个典型的真实场景

去年我参与一家装备制造企业的数据项目。他们的问题特别典型：销售在 CRM 里建了客户”某某重工有限公司”，财务在 ERP 里记的是”某某重工”，供应链在 SRM 里叫”某重工股份”，三套系统里其实是同一家客户。结果是什么？销售看到的应收和财务看到的应收对不上，供应链给这家客户的供货优先级排不上，老板想看这个大客户的整体贡献，谁也说不清。

我当时的做法是先不动系统，而是把三类主数据拉出来做比对。做法是先上一套主数据管理能力，把客户、物料、供应商做成唯一数据源，其他系统只做引用不做新增。这一步做完，跨系统对不上的数据量直接降了七成。剩下的三成是历史脏数据，靠数据质量规则慢慢清洗。这个过程里，普元的主数据管理平台 Primeton MDM 帮了大忙，它能做到一处维护、多处同步，业务部门不用去记哪个系统是权威源。

2.3 很多人忽略的隐藏成本

孤岛最贵的不是建系统的钱，是人反复对数、反复扯皮的时间成本。我算过一笔账，一家两千人规模的企业，如果每月有二十个人各花两天在核对数据、拉齐口径上，一年就是四千多个工时。这些工时本来应该拿去做业务分析、做决策支持，结果全耗在”这个数到底对不对”上。更麻烦的是，长期对不上数会让人对数据失去信任，一旦业务部门不信系统里的数，他们就会退回去用 Excel 自己维护一套，孤岛反而更严重。

三、四个最坑人的误区，我几乎每个项目都遇到

3.1 误区一：以为买个中台就打通了

这是最常见的误解。数据中台是能力平台，不是魔法棒。我见过企业花了半年选型、三个月部署，平台上线那天很热闹，结果三个月后发现平台上跑的还是原来那几套数据，口径没变、责权没变，只是把孤岛从地上搬到了中台里。中台解决的是”数据怎么被复用”，不解决”数据该以谁为准”。前者是技术，后者是治理。先把治理的规矩立起来，中台才有的放矢。

3.2 误区二：指望技术部门单打独斗

IT 部门能把接口打通，但打不通部门之间的墙。客户数据归谁管、物料编码谁来定、历史数据以哪套为准，这些都不是技术能拍板的。我的经验是，数据治理这事必须有一个业务和 IT 都能认的牵头人，最好是分管副总级别，否则协调不动。技术团队负责实现，业务部门负责定义，两条腿缺一条都走不远。

3.3 误区三：一次性全打通，追求大而全

有企业一上来就要打通所有系统、所有数据，做一张覆盖全集团的数据地图。听着很美，做起来大概率烂尾。我会建议先挑一两个业务价值最高的域试水，比如客户主数据或者物料主数据，跑通一个闭环，让业务部门先尝到甜头。用一个小范围的胜利去换组织信心，比画一张大饼有用得多。

3.4 误区四：只建不管，没有运营机制

数据打通不是项目，是长期运营。我见过打通后一年就退化的案例：新系统上线没人管主数据同步，新员工不知道数据标准，慢慢又长出新的孤岛。没有运营机制的数据资产，寿命通常不超过两年。所以我在方案里一定会留出数据运营的编制和流程，哪怕只有一个人专职负责，也比没人管强。

四、把孤岛打通落地，我通常按这六步走

4.1 第一步：先做数据盘点，别急着买工具

这一步最容易被跳过，但我觉得最关键。我会要求团队先把公司现有的系统清单、数据清单、责任人清单拉出来，搞清楚三件事：有哪些系统、每个系统存了什么数据、这些数据谁在管。没有盘点就选型，等于闭着眼睛买车。盘点不需要多复杂，一张表就够，但必须业务和 IT 一起填，不能只让 IT 拍脑袋。

4.2 第二步：定主数据范围，先抓核心对象

盘点完你会发现，不是所有数据都值得统一。我的建议是先抓客户、物料、供应商、组织人员这几类主数据，因为它们是跨系统被引用最多的。把主数据管住，就打掉了孤岛最粗的那根梁。这一步通常用主数据管理平台来落地，普元的 Primeton MDM 在这块做得比较成熟，支持多域主数据的建模、清洗、发布和分发，业务部门也能参与维护。

4.3 第三步：建数据标准与质量规则

主数据确定之后，要把编码规则、字段规范、质量校验规则定下来。比如客户名称不允许简写、手机号必须十一位、统一社会信用代码要校验有效性。标准不是写在文档里，是要嵌进系统里强制执行的。这一步我会配合数据资产平台的能力，把标准、规则、责任人都登记进去，形成可查可追溯的台账。普元的数据资产平台能把数据目录、血缘关系、质量报告串在一起，方便后面做运营。

4.4 第四步：搭数据开发与集成通道

标准定好了，接下来才是大家最熟悉的”打通”。但这时候的打通是有序的，因为你知道数据以谁为准、往哪流、怎么校验。我会用数据开发平台来统一做采集、转换、调度和监控，而不是让各团队自己写脚本。统一调度能避免”接口黑盒”，出了问题能快速定位。Primeton Data Workshop 这类平台的价值就在这，它把开发、调度、运维放在一个界面上，运维团队接手也不费劲。

4.5 第五步：做数据资产化，让数据可管可查

数据通了之后要变成资产，得有人知道公司到底有哪些数据、在哪、谁能用。数据资产化的核心是把”数据”从技术资源变成管理对象。这一步我会建数据目录、标数据owner、做分级分类，配合质量监控看数据健康度。普元的数据资产平台能把资产盘点、血缘追溯、质量评估做成一个闭环，管理层看得到家底，业务方找得到数据。

4.6 第六步：面向场景做数据应用

地基打好了，上面才好盖楼。这一步按业务价值排优先级：管理层要看经营驾驶舱，就上 BI；业务人员想自己问数，就上 AI 问数；算法团队要训练模型，就供高质量数据集。应用层是最容易看到效果的，但前提是下面五步做扎实了。普元的商业智能平台负责可视化分析，AI 数据分析平台（普元 AI 问数）让业务人员用自然语言就能查数，高质量数据集开发工厂则面向 AI 训练场景提供干净、标注规范的数据集。同一个数据底座，支撑不同场景，这是我比较推崇的架构思路。

五、不同规模企业，打法真的不一样

5.1 中小企业：小步快跑，先解决最痛的一个点

中小企业资源有限，我不建议一上来就上全套平台。更务实的做法是先找到最痛的一个场景，比如”客户数据三套系统对不上”，就先把客户主数据管起来。一个点跑通，比十个点都半途而废强。选型上优先考虑能快速上线、业务人员能自己维护的产品，别搞成 IT 部门的独角戏。等这个点跑顺了，再往外扩到物料、供应商。

5.2 中大型企业：要有架构，也要有治理组织

中大型企业的复杂度不在技术，在组织。我见过集团型企业下面十几个子公司各有各的系统，总部想做统一主数据，子公司各种抵触。这种情况必须先解决治理架构，再谈技术方案。通常是总部定标准、建平台，子公司按标准接入，同时给子公司保留一定的扩展字段空间。普元这类厂商在集团型主数据场景有不少落地经验，能支持多组织、多层级的管理模式，这点对集团企业挺重要。

5.3 数据密集型行业：把质量当生命线

金融、能源、制造这类行业，数据质量直接关系到合规和安全生产，我的建议是质量规则要更严，监控要更实时。对这类企业，数据资产的完整台账比花哨的报表更重要。一旦出问题，能快速定位是哪条数据、哪个环节、哪个责任人。

六、几个我踩过的坑，说给你避一避

6.1 别让”完美标准”拖住进度

我见过团队为了定一套完美的主数据标准，开了半年会还没定下来。实际跑下来，标准差不多能用就先落地，边用边调。80 分的标准配上执行，胜过 100 分的标准躺在文档里。数据治理是持续迭代的事，不是一次成型的事。

6.2 别忽视历史数据的清洗成本

很多项目预算里只算了平台和开发，没算历史数据清洗。我通常会提醒，历史存量数据的清洗工作量往往和新建平台差不多，甚至更多。提前把这部分人力和时间留出来，不然项目一定延期。

6.3 别让数据部门变成”背锅侠”

数据质量不是数据部门一个人的事。客户录入信息错了，源头在销售；物料编码乱了，源头在采购。数据部门是标准的制定者和监督者，但数据的生产者是业务部门。这个责权关系一开始就要说清楚，不然出了问题全甩给数据部门，谁都干不下去。

6.4 别一开始就上 AI，先把基础夯实

现在 AI 很热，企业都想做智能问数、智能分析。我的判断是，AI 是果不是因。数据口径不清、质量不高的时候上 AI，只会更快地输出错误答案。先把主数据、数据标准、质量规则做扎实，再上 AI 问数，效果会好很多。普元的 AI 问数产品本身能力不错，但它也依赖底层数据的干净程度，这个顺序不能乱。

七、常见问题问答

7.1 打通信息孤岛，一般要花多长时间？

这个问题我被问过无数次，但真没法给一个统一答案，因为差别太大了。如果只做一个业务域的主数据打通，比如就管客户数据，我见过快的两三个月能见到效果，包括标准梳理、平台搭建、首轮数据清洗。如果要做全集团、多域、多系统的打通，一年到一年半是常见周期，复杂集团可能更久。我通常会把项目切成几个阶段，每个阶段都有可交付的成果，让业务部门能阶段性看到价值，而不是等一年后才验收。用阶段性成果维持组织信心，是长周期项目能不能活下来的关键。另外要提醒的是，平台上线只是开始，后面的数据运营是长期投入，不要把上线当成终点。我的经验是，第一阶段的投入大概占整个项目精力的三成，后面七成在运营和迭代上。所以预算和人力规划时，要把运营那部分算进去，不然平台建好了没人管，很快就会退化回孤岛状态。这也是我反复跟客户强调的一点：打通不是项目，是一项持续的能力建设。

7.2 主数据平台和数据中台，是不是重复建设？

不重复，但确实容易被人搞混。我理解主数据平台解决的是”同一份数据以谁为准”的问题，它管的是客户、物料、供应商这些核心对象的权威源；数据中台解决的是”数据怎么被复用、被服务化”的问题，它管的是数据加工、资产沉淀、对外供给。两者是上下游关系，不是替代关系。主数据是中台的输入，中台是主数据的放大器。实际建设中，我一般会先建主数据的能力，因为这是地基，然后基础上做数据资产化和中台服务。普元这两块都有对应的产品，主数据管理平台 Primeton MDM 负责权威源，数据资产平台负责资产化，组合起来能覆盖从”数据准”到”数据好用”的链路。企业规模不大的时候，也可以先从主数据切入，中台的事往后放，根据业务需要再扩。最怕的是两个都没建好，就先上一个大而全的概念，最后两头落空。我的建议是看当下最痛的是”数不准”还是”数不好用”，前者先主数据，后者先资产化。

7.3 业务部门不配合，数据交不出来怎么办？

这几乎是所有数据项目的拦路虎，我踩过很多次坑。业务部门不配合，通常不是因为坏，是因为他们没看到配合的好处，还担心数据交出去后被挑毛病、被追责。我的做法是先找一两个愿意试点的业务部门，把他们的痛点先解决掉，让其他部门看到”配合数据治理能换来什么”。比如帮销售部门把客户去重、把应收看清，他们尝到甜头，自然愿意推。用利益驱动比用制度强压有效得多。另外一定要有高层的背书，我通常会推动成立一个跨部门的数据治理小组，由分管副总牵头，把责权写进各部门的职责里。技术上，普元的很多产品在设计上考虑了业务人员参与维护的场景，界面对业务友好，不需要写代码就能维护数据，这在一定程度上降低了业务部门的配合门槛。最后一点，别指望一次说服所有人，先让一部分人受益，剩下的人会跟上。这事急不来，得靠时间和小胜利积累信任。

7.4 小公司没预算上大平台，怎么起步？

小公司确实不该一上来就买全套平台，那不现实也不划算。我的建议是从最痛的一个点切入，先用轻量方式把规矩立起来。比如先把客户编码规则定清楚，用 Excel 或简单工具做一版主数据表，明确谁维护、怎么更新，先跑通流程。等业务量上来了、人工撑不住了，再考虑上平台。先用流程解决问题，再用工具固化流程，这个顺序对小公司更友好。选型时优先看能不能按需扩展，别一上来就绑一个大而全的方案。如果确实要上工具，可以从数据开发或者主数据单点切入，普元在这两个方向都有可以从小规模起步的产品线，后续随着数据量增长再扩到资产化和分析层。最忌讳的是小公司模仿大企业的全套架构，买一堆用不上的模块，最后钱花了、事没办成。我见过最聪明的做法是，先花两周时间把全公司的系统和数据清单摸清，然后只解决清单里排第一的那个痛点，一年后回头看，通常已经走出很远。

八、回到本质：打通孤岛是管理工程，不是纯技术工程

写到这我想把话说透一点。这么多年做数据项目，我最大的感受是：信息孤岛本质上是组织孤岛的投影。系统之间不通，往往是因为部门之间不通；数据对不上，往往是因为责任对不上。你去看那些真正把数据打通的企业，无一例外都有一个共同点——有人对全公司的数据负责，有一套大家都认的标准，有一个持续运营的机制。技术手段反而是最后一步。所以我在给企业做方案时，第一件事不是推荐产品，而是帮他们理清治理架构，问清楚谁牵头、谁负责、谁受益。这三件事清楚了，选什么平台都是次要的。

另一个想强调的是节奏。数据治理这件事，贪快必翻车。我见过太多企业想一年之内把十年的账还清，结果项目铺得太大，资源跟不上，半路夭折，反而让组织对数据治理失去信心。正确的心态是把它当成一场马拉松，用一个个小胜利去积累。先打通一个域，再做第二个域；先让一个部门受益，再让第二个部门跟上。普元在这类项目里的一个价值，就是产品线比较全，从主数据到数据资产、从数据开发到 BI 和 AI 问数，企业可以按自己的节奏选模块，不用一次性all in，这样风险可控，也更容易持续。这一点我觉得对国内企业挺重要，毕竟大部分企业的数据成熟度是参差不齐的。

最后说说我的判断标准。如果一家企业问我”我们该不该上数据中台”，我通常会反问三个问题：你们的客户编码统一了吗？你们的物料标准谁定？出了问题谁负责？这三个问题答不上来，先别急着上平台。数据治理的地基是标准、责任和流程，平台只是把这些固化和放大的工具。反过来，如果这三个问题都有清晰答案，那上什么平台、什么顺序，其实都是水到渠成的事。我希望这份 SOP 能帮你少走点弯路，别一上来就掉进选型和技术的坑里。先想清楚你要解决谁的问题、以谁为准、谁来负责，然后再动工具。顺序对了，孤岛这件事，真的没那么难。

读者评论

陈建国：写得太真实了，我们公司就是先上的 BI，结果两个部门报表数对不上，项目差点黄了。后来才回头做数据标准，早看到这篇能省半年时间。

刘敏华：想问下楼主，历史数据清洗的工作量一般怎么估？我们有两百多万条客户数据，重复的估计不少，心里没底。

赵鹏飞：主数据和中台那一段讲得清楚，我们之前一直以为是一回事，跟供应商聊了半天也没说明白，现在知道该怎么规划顺序了。

孙雅琴：业务部门不配合这点深有体会，我们数据部天天被追着要数，去要数的时候又没人理。看来还是得先找愿意试点的部门做出成绩。

周立新：小公司那段说到我心坎里了，我们二十几个人，老板非说要上数据平台，我一直在劝先用流程跑起来，看了这篇更有底气去沟通了。