序

1、将数据进行标签化的就像微积分（微分是把一个大的东西切分成足够微小的部分，积分是把切分后的微小部分组织合成）。标签的设计过程就是把各种对象充分“微分”的过程，解析和拆分得足够惊喜；而标签的使用过程就是将场景中涉及的对象标签拼装在一起使用，是一个“积分”的过程。

2、传统的数据处理往往是业务到数据再回到业务的快速贯通。适用于小企业对所需的数据局服务产出时效有严格限制，只关注当前某一个局部的应用场景。

3、标签化的数据处理则意味着数据需求经过标准化组织后规模复用。是一种中台模式：将生成好的数据全部入库编号，并检查标签项是否完整、规范、准确。将经常用到的信息、技术、功能进行标准化封装以供业务场景多样化的大型集团企业：通过=一次建设、反复享用的方式可以节省成本，形成规模效益，同时还可以为企业沉淀核心的数据资产。

4、中台的核心本质是将可复用的能力、技术和工具汇聚在一起，帮助前段业务快速响应变化。中台从定义上就超出了技术范畴，它所涉及的系统领域并不局限与技术层面。技术驱动数据中台建设从方向上就错了（搭建开发集成环境进行一站式开发，利用数据管理工具对数据标准、数据安全、元数据进行管理，利用API网管对所有服务接口进行调用监控）。

5、数据资产是能给业务带来经济价值的数据资源。数据中台的价值在于让业务快速试错，在千百次的试验中找到并发挥数据的商业价值。

6、数据资产设计师应运而生，专心研究业务所需标签，将其设计哈开发出来并在数据中台的数据资产库中上架，让业务人员能自己查看、选择、使用标签，从而极大地缩短数据资产使用周期，降低业务试错成本，通过反向推动链将数据价值发挥到极致。

第1章 因：6大数据困局

一、 数据孤岛，无法打通

1、技术原因

不同厂家的数据库或数据存储方式就像海平面下的岛屿，相互之间无法连通，这种情况属于因技术原因无法打通。既然是技术原因，就可以通过日新月异的技术手段来进行数据交换、汇聚和打通。

2、管理制度原因

数据使用一般分为三个层次：

• 数据使用1.0：自生自用，即部门、企业的数据自己加工，自己使用。
• 数据使用2.0：自生他用，即部门、企业的数据自己生产、加工、授权后供他人使用。
• 数据使用3.0：共生公用，即多部门或多企业将数据进行融合在加工，授权后供多部门、企业共同使用。共生共用并不是把所有数据倾倒在一起，使用时从数据池中直接捞数据的野蛮方式。共生共用意味着数据的接入、生产、使用、管理进入系统化阶段；所有数据的来源、现状、去向都清洗可查，生命周期都得到有效管理，使用有章可循。

各部门对自身数据进行加工并形成分析报告，查找原因以进行针对性改进，实现了业务数据化——数据业务化的小循环。这样，一方面使数据价值得到了体现，但另一方面也在部门间铸起了数据交换的壁垒。部门间数据不共享的情况源于公司管理制度的欠缺，公司内有很厚的部门墙。

3、数据观原因

部门各自为政，数据并不打通。因为技术、工具可以通过学习或直接采购快速获得。最容易解决的是技术问题，因为技术、工具可以通过学习或直接采购快速获得。

稍难解决的是部门间数据不共享问题，这类问题往往需要由公司总部来统筹解决。数据是一种特别的资源，它可再生，融合价值大于原有价值之和，越用越有价值。因此只有把数据汇聚在一起，才能实现数据世界的完整复刻。

最难解决的就是企业自上而下的数据的认知偏差问题。数据是有认知门槛的，并不是所有的业务人员都知道如何读懂数据或操作数据，而数据人员又缺少向业务人员生动解释数据的能力。因此企业需要一种数据和业务间的转化术语，来帮助业务人员、运营人员、职能人员等快速理解数据、掌握数据应用技能，进而认识到数据的重要性，实现数据的共生共用。

当企业需要切实解决数据孤岛问题时，建议采用从难倒易的方式：

• 塑造企业的数据认知
• 促进推动数据部门间的数据融合
• 选择数据同步的技术或工具

二、烟囱式建设，重复造轮子

1、烟囱越建越高，难以支撑

从部门出发的数据梳理工作实施过程中，年轻的数据工程师并没有充分考虑数据底层的系统梳理和清洗溯源，就进行了快速的数据开发工作；在开发过程中，也缺乏数据逻辑和建模分层上的思考和指导。一切都以业务为导向，为了及时产出最终的数据结果，中间步骤是否合规合理、代码程序是否稳健正确都可能会被忽略。这样进行的数据建设极容易倾斜倒塌。

2、数据治理在局部难以成功

企业要用数据反映企业的真实情况，只有数据加工逻辑准确无误，最终的数据结果才能反映出问题的本质。如果数据建设是各业务林立的烟囱式做法，并没有统一的部门来进行源头管理，那么数据治理汉南在局部获得成功。

3、重复投入容易造成资源浪费

烟囱式的数据建设的最大弊端是造成了企业在数据建设上的重复投入，造成资源浪费。如果各部门都自建一套数据系统，会发生反复存储、反复计算的问题，导致资源浪费。这种浪费会随着数据量的增加而越发凸显。

三、各说各话，没有统一口径

原始数据的清洗方式，中间数据的统计逻辑、结果数据的汇总差异都会影响最终的数据结果。企业如需要对外分享或披露数据，也需要谨慎选择指标，防止数据口径不一致的情况发生。有3条帮助企业统一数据口径的建议：

• 形成数据工作的标准流程与规范
• 完成对数据信息项的全面梳理
• 授权数据部门对指标进行统一定义。

四、鸡同鸭讲，无法穿透业务层

• 数据人员基于他们的认知体系进行数据宣讲，沉浸在自己的数据世界中，没有将自己代入业务人员的思维方式中感统深受，结果由于这些数据知识过于专业，缺乏恰当的诠释转化和案例讲解，业务人员无法理解。
• 业务人员对数据学习也心存障碍。业务、运营、智能部门的人员在认识事物时往往用的是感性思维，对数据学习需要的理性思维不太习惯，因而很少会冷冰冰的数据产生兴趣。

五、数据人员的梦魇，数据治理永远没有尽头

1、传统数据治理的专业门槛较高

传统数据治理涉及对数据的标准进行统一制定，对数据的安全进行分级分类，对数据的质量进行控制和迭代优化，对数据的元素进行一一梳理并归档，对数据的生命周期进行全链路跟踪并构建溯源机制。。。这些工作需要有具备更高视野的数据管控者进行全局考虑，并且具体执行者需要掌握数据治理专业技能，才能进行具体操作和衔接。

2、传统数据治理涉及的板块多，周期长

在数据治理项目实施过程中，可能会面临不同板块之间的衔接问题，因此需要一个治理总工程师来统筹规划：确定统一的治理目标和原则，安排好合理的治理计划和路径，选择适配治理目标和流程的工具产品，挑选并培养数据治理队伍，制定确保数据治理平稳推进的工作机制等。但在漫长的治理过程中，可能会出现人员更替、信息缺失、事项遗漏等无法避免的问题，这些都是数据治理工作中不得不面对的困难。

3、治理工作一遍又一般，治理不完

• 治理工作初始阶段定下的目标，很可能在治理到一半的时候，因为数据的来源、生产、使用等重要环节发生变化而不得不修正，治理工作需要重新进行。
• 数据治理完成后，在使用某部分数据的过程中，业务端可能会提出进行质量调优或变更原有数据开发代码的需求，那么数据治理的其他相关模块都要相应修正。

4、治理工作难以对外扩展，获得配合

传统的数据治理项目往往是由技术部门或数据部门来主导，但数据部门其实智能影响数据生命周期的中间环节，即数据的生成和加工环节。数据的两端（来源端和使用端）并不属于数据部门能掌控的范围，更多属于业务部门控制的范围；而数据治理所包含的多项重要工作，如数据标准、数据安全、数据质量、数据生命周期等，都是全链路工作项，如果缺乏两端的配合与支持，是无法顺利完成的。

5、治理难度太大，是一项系统工程

数据治理是一项模块多、跨度周期长、技能要求门槛高、受外界环境影响大、需要多部门联动配合的系统工程。这个系统工程如果仅由数据部门来强力推进，很难做好。

六、数据部门的尴尬，被命运扼住咽喉的成本中心

数据部门示弱，主要原因在于业务部门强势，这从部门职能定位和项目推动力两点上可见端倪。

1、部门职能定位：业务部门是利润中心，数据部门是成本中心

• 业务部门作为企业的利润中心，持续养活后端的研发部门、生产部门、职能部门等，因此业务部门自然掌握了话语权，能够得到全公司最多的资源和支持。
• 数据部门被视为成本中心。数据负责人总是需要不停地向董事长、CEO解释为什么需要这么多数据基础投入，数据预算为什么不能在降低，数据到底可以为企业带来多大的价值。
• 数据部门的KPI设定往往是自我建设和对外赋能：完成企业数据架构设计，完成数据平台底座建设，完成数据资产目录梳理，完成数据产品体系开发；支撑业务部门对数据的规模调用，支撑数据赋能下的业务持续增长，支撑企业经营管理中的数据呈现和数据决策，支撑企业数字化转型战略。。。。其实，在企业领导和财务人员眼中，数据部门的投入为支持成本，收入项为0。

2、项目推动力：业务部门无往不利，数据部门步履维艰

• 由业务部门牵头主导的项目方案往往无往而不利，数据项目的目标和价值往往比较基础且沉闷；
• 尝试将数据部门作为一家数据公司看待，其所采购的服务器、数据源、工具平台等可看作成本支持，其所产出的数据服务、数据应用可看作定价售卖的数据产品，各业务部门需要为数据价值进行收益上的定量拨付或财务核算，这就是数据部门的利润收入。
• 数据资产复用价值越高，数据服务越健壮、高效、每单位投入下的收益回报越客观。