最近在公司内给同事们讲了企业数据平台建设历程，在这里和大家分享下。

1、什么是企业数据平台产品

个人定义「数据产品」为：数据产品是指利用数据辅助用户了解客观世界，做出决策甚至行动的一种产品形式。

首先从整体数据产品的分类讲起，划分的依据是使用者所属群体，分为 ToC，ToB 和企业内部三种。而在企业内部，又可细分为：「业务型」和「平台型」。

业务型的企业数据产品，更加专注于解决某个具体的业务问题或者部门问题，如客服数据监控系统和建立在集团平台的事业部决策分析系统。而平台型的目的，就是为前者提供更好的支撑。

在明确了宏观的定义后，我们再细拆下「企业数据平台」六个字。窃以为，重要性应按「数据」、「平台」和「企业」三个排列。

（1）数据，界定了产品的边界

我们思考的是怎么利用数据去优化业务，去推动业务，数据组不产生数据，只是数据的搬运工，要和非常底层的业务逻辑保持适当距离。对于日志的打印，业务库的设计等这些数据原料，我们可以根据经验提出更优的方案，但不适合去做具体的落地和执行。

很多数据 PM 在一些业务需求的实现过程中会觉得非常低效和别扭，部分原因就是参与业务需求太深，导致在数据聚合层次掺杂了太多业务逻辑，业务方稍微更改下 PM 就会非常痛苦。

（2）平台，强调的是面向各个业务提供服务，这要求产品具备较高的标准化和抽象化

标准化指的是主动出击，定下一些关键的数据资产规范，方便在企业中流通使用，如：埋点管理、指标管理和数据库表管理等等。

抽象化则指的是不能只关注于解决一两个具体的需求点，而是关注整个面的抽象和满足，是一个由点及面的过程。

（3）企业，在企业内部，会决定了反馈回路短，种类繁多，相对琐碎的需求特征

很多需求，可能就是业务方走到你工位旁说一句话的事情。

另外一方面，企业内用户层级价值明显，越到高层越能体现数据的价值，即以前我介绍过数据产品两大原则之一：「数据价值体现在数据使用者手中」。

**，市场竞争激烈，数据安全及权限也是头等大事。常见的权限模型为 RBAC（Role-Based Access Control，基于角色的访问控制），它抽象出「用户-角色-权限」三个概念，通过角色控制菜单权限，再为用户赋予相应角色，角色一般根据业务部门和领导层级综合划定。

2、企业数据平台的目标

借用 GrowingIO CEO Simon 的理念，企业如同人类建立的水资源使用系统，而数据如水。企业数据平台的建设目标，应当是让数据像水资源一样在企业中流动。

这意味着数据要像水一样做到：

1. 干净无毒
2. 随用随取
3. 场景丰富

这恰好对应数据准确、全面、及时、易用四个衡量维度。

进入人类资源使用系统的水资源需要经过一定的清洗和沉淀，确保「干净无毒」，然后根据不同的水用途存储，进入不同的管道，这对应于数据的「准确」。而「随用随取」对应着在人类社会中，拧开水龙头就能来水，及时，易用。

「场景丰富」则意味着在不同场景里，水会有不同用途，饮用水、清洁用水、灌溉用水各取所需。即使饮用水，也分城市用水、矿泉水、纯净水等不同使用方式，通过挖掘和丰富数据的使用场景，深化数据本身的「全面」涵义。

达成这个目标的企业数据平台，便能通过丰富场景，赋能业务，提升整个企业使用数据的意愿和效率，赋予业务方高效使用和挖掘数据的能力。

在使用场景上，个人归结为以下主要场景，其他还待继续补充：

建立数据流程，从产品上，是帮助业务方更好地完成使用数据的流程，包括采集存储，展示分析到**的挖掘落地三个层次。

从需求上，即建立一个比较完善的需求分流解决机制，将零散需求、常规需求、业务需求等等分类处理完毕，并能将进展和结果及时反馈给需求方。优化用户体验，是通过掌握用户数据，为用户提供更加顺畅的使用体验，更加精准的营销等等。

挖掘数据资产，包括标准化数据资产，以及不断挖掘回馈原有数据，丰富数据维度，即车老师在《决战大数据》中提到的「养数据」概念。

在转转的发展过程中，我们曾经利用各种数据猜测出用户的身份后进行定向业务推广，通过推广活动的反馈再回过头来修正用户身份，也是「挖掘数据资产」的一个例子。

3、如何搭建企业数据平台

一个完善的平台应该由以上三个框架组成，其中技术框架非我所长，暂且略过。数据框架主要是在数据模型，安全及质量模块。其中，数据模型主要是先对所属业务出现出对应的领域模型，然后定下来对应的主题域划分和维度模型。

产品框架上，依然遵循 What-Why-How 的划分方式，**解决的是采集存储，「是什么」的问题，先把数据采集后清洗存储下来。其次解决「为什么」的问题，利用分析架构和数据可视化展示，帮助用户寻找原因。

**解决「怎么做」，通过价值的深入挖掘，和业务紧密结合等方式，来确定具体的内容和方向。

接下来简单介绍下产品框架中的每个步骤要解决的问题和对应的方案。