一、“数据孤岛”是什么？

企业发展到一定阶段，必然会跟随时代发展进行信息化建设。而信息化建设的不平衡，催生了“数据孤岛”现象的产生。

企业内部通常存在多个事业部，每个事业部都有各自的数据，事业部之间的数据往往都各自存储，各自定义，形成不同的子系统。而子系统之间并未建立有效的数据交换服务，各业务系统数据描述标准不一，造成严重的数据不一致。各个子系统内所存储占有的数据，就像一个个孤岛，难以和企业内部的其他数据进行连接互动。

这样的情况就被称为“数据孤岛”现象。简单来说，就是企业内部的数据间缺乏关联性，彼此无法兼容。

二、“数据孤岛”的危害

企业内不同部门数据的“各自为政”，大大制约着企业管理和业务的顺畅开展：

1、数据重复：由于数据流通不畅，企业各部门在收集数据时会产生重复行为，造成了数据的重复、冗余、无效等情况，降低了数据的质量和准确度。

2、错误决策：数据的不准确、不及时，往往导致企业决策错误或决策迟缓，从而影响企业的口碑和在市场中的竞争地位。

3、协作不良：企业内部数据孤岛现象的显著，会在很大程度上使得企业各个部门、团队之间，因难以获取工作需要的数据，而关系紧张、协作不良。

4、效率低下：由于不同部门对数据的理解和定义不同，企业内部的沟通成本上升。同时，各部门对数据的重复管理，造成了时间和金钱的浪费、工作效率的低下。

5、客户体验差：企业内各部门拥有的数据不一，容易造成客户端到端的体验混杂，总体评价低。

三、为何会产生“数据孤岛”现象

1、以功能为标准的部门划分导致数据孤岛。企业各部门之间相对独立，数据各自保管存储，对数据的认知角度也截然不同，最终导致数据之间难以互通，形成孤岛。也因此集团化的企业更容易产生数据孤岛的现象。

2、缺少企业内信息化建设的战略和标准，如果不能做到信息系统建设的统一，由不同部门，不同公司来建设的话，必须有一个标准能够使得日后的互通比较容易实现。

3、不同类型、不同版本的信息化管理系统导致数据孤岛。人事部门用OA系统，生产部门用ERP系统，销售部门用CRM系统，甚至一个人事部门使用一家考勤软件的同时，却在同时使用另一家的报销软件，后果就是一家企业的数据互通越来越难。

三、数据治理的八种方法？

8种方法，分别是：顶层设计法、技术推动法、应用牵引法、标准先行法、监管驱动法、质量管控法、利益驱动法、项目建设法。

01 顶层设计法

顾名思义，顶层设计法就是先做一个数据治理顶层设计的规划，然后按照规划执行即可。

做过咨询的朋友都知道，顶层设计、战略咨询都会根据战略目标拆解KPI，然后设立对应的支撑项目，并且根据优先级别进行排序，最后形成一个执行的路径。

之后就按图索骥就行。大致的逻辑就像下图一样：

这样的好处很明显，先有面，再有线，最后是各个点状的项目，一点点的落实。

但是这样的方案是非常非常奢侈的，因为这种方案见效慢，对组织的要求非常非常高。耐得住性子的组织很少，通常都要快速见效。

基本上也只有一些政府单位和极少数的企业使用这种方式获得了数据治理的成功。

02 技术推动法

其实这种方法是绝大多数企业采用的数据治理方法。原因是什么呢，其实很简单，因为数据治理项目大多是在信息部门立项和实施的。

既然是技术部门的事儿，那当然是技术部门推动了。讲真，笔者见过太多类似的事情，很少有效果很好的。

《华为数据之道》里说要“业务主导”，话是真没错，但几乎没有做到的。原因很简单，屁股决定脑袋。业务负责人的主责主业是搞业务，根本不会也不可能要主动做数据治理的事情。

技术驱动的套路没啥说的，就是针对数据问题，从技术层面进行解决。套路就是信息系统建设的逻辑，立个项，做调研，各种概要设计、详细设计，各种开发、集成、测试、部署，然后验收。

然后开始上指标系统、数据质量系统，一个补丁贴一个补丁，到最后谁都不敢动了。

归根结底，就是因为数据的问题是一个系统性的，技术层面的原因只是其中之一而已。造成这种现象的原因就是业务参与度不够。

在企业，谁挣钱，谁的话语权就大。业务自然是利润中心，而技术一般都是成本中心。纯让技术去推动数据治理，就像是让儿子督促爸爸戒烟一样不靠谱。

03 应用牵引法

如果说技术推动是小孩推车，那么应用牵引则是壮牛拉车得心应手啊。有应用在前面牵引，后面的各种事情就显得非常自然。

很多企业建数据体系都喜欢先弄一个大屏不是没有道理的。因为没有“用”的东西是没有价值的。

大屏虽然用户比较单一，实用价值比较低，但毕竟还是有使用场景的，比单纯没有使用场景的纯技术开发建设强的不是一星半点。

以数据应用为牵引，反向要求各链路的数据高质量供给，促进数据治理体系的建设，也是一个很好的选择。

但是这种方式做数据治理，始终还是会陷入到片面、局部胜利的结果。有应用的地方，数据质量就能得到治理，没有应用的数据质量就没人管了。

04 标准先行法

甲方在建业务系统的时候，把数据标准和业务系统绑定起来。所以他们在做信息化建设的时候，就已经把所有的数据标准都已经建立好了。

过去的时候，发现数据治理真的就这么简单，完完全全就是一个纯技术活儿，不用考虑人的因素。

所有表都是按照统一的数据模型建设的，所有字段中的键值都在最新发布的数据字典里，甚至为某个“主数据”单独建了一套管理系统。

我过去就是按照标书里的要求，建库建表，开发ETL，把数据收上来，然后整个规则引擎，按照配置结果，自动计算数据质量，定期出数据质量报告。

为什么有那么多的数据质量问题？很简单，没有标准。没有标准就没有对错，自然就会乱到一塌糊涂！

标准有了，就能确定什么是对的，什么是错的。后面的执行、监测和控制就有了依据，数据质量才有保障。

05 监管驱动法

强监管通常是上级单位发政策，下级单位执行。而且做不好，还会有惩罚。

银行、保险等强监管的行业就是跟着政策走的。不好好做数据治理，不按照EAST、1104的要求报送数据，罚单马上就来。

当然了，在企业内部其实也可以执行这种强监管的模式，但这需要“特权”。这个前提通常很难达到。

有种取巧的方法，就是贯标。贯标有一个特别的好处，就是把“贯标评级”列到组织年度目标中，这样就能在企业内部形成一个巨大的“势能”，形成强监管的态势。

我们给某企业做DCMM贯标的时候，发现技术部门早就制定并颁发了数据安全的制度、流程。但是跟大多数企业一样，发完之后就成一纸空文了。业务觉得安全管控太费事了，压根就不执行。

现在不一样了，技术部门借着“贯标”的理由，要求业务贯彻执行之前发布的制度和流程。业务虽然不情不愿，但是贯标是企业级目标，大家不得不做，也就半推半就的推行起来了。

其实说到底，监管驱动法，就是在借势，借上级政策要求的势，借国家标准的势。用大势推动原本推不动的部门，疏通原本阻力大的流程。

06 质量控制法

质量控制法其实是没有办法，也算是数据管理早期的雏形。因为说起来，数据管理理论体系往前追溯，其实是来自于质量管理体系。

ISO9000（质量管理标准体系）、TQM（全面质量管理体系）、CMMI（能力成熟度集成模型），都属于通用管理体系。

ISO9000后发展出ISO8000（数据质量管理标准体系），TQM延展出TDQM（全面数据质量管理体系）。而CMMI协会也在2014年推出了DMM（企业数据管理能力成熟度模型）。这是数据领域质量管理体系。

中国则参考CMMI等一众数据管理体系，在2018年正式发布数据管理成熟度评估模型（DCMM）国家标准，这是后话了。

与其他行业情况一样，质量是绕不过去的关。不管是做业务的，还是搞技术的，相信各位彭友没少为数据质量的问题挠头。质量有问题，数据就没法用，甚至会影响错误决策。

于是，迫于各种数据质量问题，企业内外部才认真对待，逐步解决数据质量问题。

数据质量管控很明显，是问题导向。但是也不能头疼医头脚疼医脚，还得有个方法论。

一般来说得有一个具体的需求，包括数据质量管控目标、评估标准、判定规则等等。

然后再以阶段性的目标和需求出发，从事前防范、事中监控、事后核查三方面进行质量管控，对各类数据问题予以解决。

在解决的时候，一般会立一个数据质量改进的专项，从技术、流程、制度、机制等层面进行改进，定期开展评估，对数据质量问题及解决办法建立知识库，便于之后遇到类似问题能快速定位和解决。

在这个过程中，以数据质量问题为牵引，综合使用元数据、主数据、数据标准、制度规范等各类手段，“建”以致用，自然就不会出现用不起来的情况了。

07 利益驱动法

利益驱动法其实也很有意思。这是我偷偷观察并总结的招，而且这招貌似特别好用。

其实说白了，也没啥，就是一招：以利益共享为根本，以“成就” 为导向，建立一个符合部分核心人员利益的目标，然后推一下就行了。

具体的操作手法有很多，比如成功案例法、合作致胜法、评奖法、出书法、会议法等，还有互联网企业保命大法“开源法”。

08 项目建设法

这个很容易理解，就是弄个数据治理项目，慢慢建设。

其实数据治理这件事情开展到现在，也已经形成了一整套非常完善的流程了，相关产品能力也已经非常全面了。

目前效果比较好的，是咨询和实施结合起来做。

做个咨询，对数据现状进行盘点，全面掌握企业未来的战略和目前的现状，然后根据数据管理体系，做出差距分析，拟定具体执行的工作任务，根据时间进度安排，拆解并规划项目。

然后在实施项目中，先穿透一个场景，再慢慢从纵深和横向两个层面不断扩大战果，建元数据、主数据、指标体系、数据质量管理体系等等，不断夯实数据基建，为前端数据应用提供高质量数据供给。

140页深度干货，囊括15个典型成功案例，覆盖金融、集团、政务、制造、港口5大行业，全书从方法论到实践全面解码数据治理，开辟数据治理新范式，丰富内容可免费获取！

免费获取链接：https://fs80.cn/4w2atu