为什么数据湖也好，数据平台也好，在过去都没有像今年数据中台这么热门，那么业务部门为什么这么热衷于数据中台？

数据实际上是一个非常传统的行业。

有软件开始的那一天起，数据这个行业就存在了。比如说原来最早的时候，有非常多的数据报表数据可视化，然后到后来，有了商业智能，有了Data Warehouse（就是数据仓库），然后数据挖掘，并且在数据这个行业里面是有非常多的巨头的，比如：teradata、cognos，biee、microstrategy等。

数据这个行业不仅仅是软件，它还有管理的部分，也就是说数据治理，即如何让企业的数据治理的质量更好。所以数据这个行业本身是一个非常传统的行业，每个大型一点的企业都有自己的数据分析部门，数据仓库部门。

那么为什么数据湖也好，数据平台也好，在过去都没有像今年数据中台这么热门。而且关注数据中台的还不仅仅是技术部门，很多都是业务部门。那么业务部门为什么这么热衷于数据中台，业务部门以前不是特别关注这些技术的数据平台和这些技术的概念。

大概在04，05年，我就开始从事一些跟数据相关的工作，在06年的时候做过一个数据仓库的项目。

讲到数据中台，我们就要提到平台化。我们现在所讲的SARS也好，所讲的path也好，所讲的数据中台也好，所讲的业务中台也好，它实际上根本的思想来源是来自于平台化，就是platform。

平台化的概念

举个例子：我们拿一个饮料厂的产品线来讲，那么他可以生产果汁，可以生产饮料，还可以生产其他的产品，它可能是三四条不同的生产线。从原材料加工成饮料，它有很多环节，虽然品种不一样，但是它很多环节是类似的，比如装瓶、搅拌。

那么这几个不同的生产流程、生产线，我们可以把那些公共的部分合并起来，更加专业化，然后并且让他们独立去维护，之后把那些不同的产品面向客户，使客户体验不同的产品，使它独立出来，这就是平台化的思路。

所以，平台化的思路很重要的就是把那些有共性的资源，有共性的能力合并在一起，然后把那些面向客户的价值独立出来。

这样的话，专业的人做专业的事情，并且对于企业的绩效也非常的有利，不揉在一块了，更加的清晰，所以这就是平台化的思路。

那么不管什么中台，它实际上都是平台思想的一个体现，一种具象。

所以从软件角度来看，那么这个图是十几年前，所谓的EAI，即企业应用集成。

最早的时候企业的应用集成是一种点对点的形式，以前没有前后台之分，比如说所有的业务系统可能最后都要结账，都要算账，那就叫财务系统。然后所有的财务系统在结账的时候，WBS code，我们所讲的项目编码，叫项目系统。

所以这样的话在这里面有很多的系统，它的功能要被多个其他的系统所调用，原来的网状点对点集成结构很复杂而且一团麻，摩擦非常多，经常搞不清楚，数据不统一、规则也不一致。

这种情况下，平台化思路怎么解决？

以前我们称ESB，为企业的服务总线，然后将多个服务，用SOA的方式，把多个这种会复用的服务，抽象出来，变成企业级的service。ESB上可以提供其他的服务消费者所调用，中间的ESB，实际上它也是一个平台。所以平台化的优势就是能力复用，减少摩擦。

所有的这种无论是你的信息技术系统还是业务系统，只要它能够抽象出来，能够被复用，则复用的这一层，那我们都可以把它理解为是中台。

中台是介于前台和后台之间的一个系统，那么后台实际上对我们现在来讲的话，大部分情况下指的就是企业里的SAP，后台的财务，hr系统，客户距离市场跟进的系统。

中台里面很重要的两个中台，一个是业务中台，一个是数据中台。业务中台是提供可复用的业务，API数据中台是提供数据洞察和智能的。

我们前面介绍了一下背景，从平台化到中台，我们下面进入到数据中台。

数据中台为什么这么火？

1. 数据中台和传统的数据系统出发点不一样

这里举个例子，原来的数据平台也好，数据湖也好，数据仓库也好，它们的出发点很多时候有局限性，应该说更是一个支撑性的技术系统，即一定要去考虑我先有什么数据，然后我能干什么，这是传统的数据平台，数据湖，依赖于现有数据的质量，现有数据的状况来做的这样的一个支撑性的技术平台。

但是数据中台在我们现在所讲的概念里面，它更多的是从业务出发，比如说：我们现在所设计的一套精益数据的方法，它就是从业务出发，一开始都不用看你系统里面有什么数据，重点的是去解决你的业务需要什么样的数据服务？

作为第一出发点，作为切入点。然后再来看这些业务，你需要这些数据服务，它有什么价值？至于说这些数据服务所依赖的数据有没有，那是我们的实现方式，只要这个服务有价值，那我们就去想办法去拿到数据，如果没有能力，我们去建技术能力，去完成数据服务的提供。

所以数据中台最重要区别于传统数据平台，技术类平台的区别在于数据中台的思维是业务思维，他从业务问题出发，这也就是为什么业务部门对数据中台会这么欢迎。

我们的目标是哪怕我的数据只有50%的准确性，那么在我提高数据质量同时，我也希望这50%准确的数据也能为我产生业务价值。这句话是我们现在正在尝试的，也是用来做的。

在过去，业务部门跟技术部门同数据仓库的人提需求，数据仓库的人说不行，没有数据，数据质量不好，现在做不到，现在我们只有这些数据，然后看看在这些数据里面，你们能干点啥，这是原来的思路。
但是我们所讲的数据中台指的是业务需要什么，我们就用数据中台提供什么，哪怕说现在可能你连数据库都没有，但是只要业务需要这样的数据服务，我们手工的去录入构建这样的一个API也要让它实现，也要为业务产生价值。然后慢慢的我们再来完善数据服务，把它自动化。

所以这就是我们所讲的业务中台第一个最大的区别，一定是从业务价值出发，所以业务部门过去这么多年里，实际上对数据的需求和业务的需求从来没有发生过变化。从来没有说原来因为数据平台没有数据中台的概念，所以我提的需求少一点。

业务对于数据的需求没有变化，但是它需要一种新的思维方式，一种新的技术平台，帮他去快速解决从数据到业务价值到业务服务的这个过程。所以这是第一点，数据中台是面向业务的，它不依赖于你现在数据中台的建设方法，不依赖于你现在有什么数据。

2. 度量不同

为什么在过去我们所讲的数据治理这么火，而现在，实际上我们越来越觉得数据治理可能是一种企业级的大而全的数据治理，但这可能是个伪命题，因为它数据质量是不可能同你的真实的业务百分之百一致。

但是数据的系统数据平台，数据仓库，很多时候是以你的数据质量作为度量标准的，即现在这个数据平台存储了多少数据，数据报表开发了多少张报表，这个是你的价值。但是在数据中台层面上，我们所讲的数据中台的价值度量，是它为你的业务提供了多少有价值的数据服务。至于说这个数据服务后面的数据质量可能不是那么的好，但是只要它能够给业务带来价值，这个就是好的数据服务。

所以我们很快地拆解一下，从数据中台这四个字上来看，实际上它也能够快速的让我们大家理解什么是数据中台，首先是数据，数据让业务更智慧。数据中台提供数据分析，数据挖掘，将数据提供给前台，是以数据为核心，它介于前台与后台之间。

在某种角度上来讲，大家会问是不是也会有数据后台？

是的，在有的维度里面，我们把传统的数据湖作为数据后台，前台中也有数据，提供消费数据服务的就是数据前台。中台是为多个业务系统提供服务的，能够使一个系统变成一个数据服务的生态，它是不断演进的。

用一句话来概括数据中台，我们把数据中台理解为是企业的数据服务工厂。所谓的数据服务工厂在我看来，以后所有的企业中的本质就是加工处理数据，产生数字化世界里的产品，然后把它连接到物理世界，生产出来，销售出去。所以数据中台对企业来讲，它是数据服务的工厂。

过去那么多年，建设的系统是把业务数据化，现在我们很多的企业在后台系统建设好以后，在做的业务系统实际上是把数据业务化，而且有一点也是我们现在行业里面重点强调的，原来我们讲先有业务，后有数据，先有应用系统，后有数据系统。这个观点从今年开始要发生改变了，在业务系统还没有建立起来的时候，我们就要有数据思维，就要把数据集成到业务系统的架构里面去。

原来我们所讲的业务系统叫OLTP，即在线交易系统，然后数据类的系统叫OLAP，即在线分析性系统。

现在可以看到一个趋势，这个趋势就是OLTP和OLAP在融合，也就是很多企业所讲的P流一体，即为批处理和实时流数据处理一体化。原来我们的OLTP、OLAP是平行的关系，先要通过OLTP系统产生数据，然后ETL，然后抽取到OLAP里面，再把多个OLTP的系统抽在一起，之后在OLTP、OLAP的系统里面产生洞见，变成数据可视化报表给业务部门去看，再去改变你的OLTP的做法，这里的OLTP和OLAP是平行的关系。

我们现在提到得是OLAP和OLAP的融合，每个业务系统都会需要都会趋于具有大数据处理能力，智慧能力的交易系统，之前把它叫做在线交易系统和在线分析系统，我们现在把它叫做在线分析型交易系统，它是有跨域的，有历史的集成数据分析交易系统。

这样的话，原来的数据百分之七八十在企业里的应用都是数据可视化，都是BI，都是data house报表，让人看，这叫人机接口，这个是人看完数据以后，然后再去提取，之后去做你的决策，改变你的行为，去看数据。

从今年开始，数据中台更多强调的是机器与机器的接口，就是我的数据分析出来的结果，不仅仅以报表可视化的形式让人看，而更多的是把这些API这样的一些数据服务直接地嵌入到交易系统里面产生影响，变成你的价格策略，变成你的推荐引擎，变成你的风险管控。

那么我们所讲数据中台，它不仅仅是一个技术平台，它还是一个体系。

数据中台会对应到一个企业里的一个部门一个组织，也要有数据战略的支撑，要有数据治理，数据中台上面生长一个数据服务，数据服务提供给我们业务系统，提供给我们业务中台，然后我们所接收到的数据消费者，就都生长在数据中台之上。数据中台是一个生态，是一个平台，是一个数据服务，是生产、加工、交易、度量、运营的平台，所以我们把数据中台实际上叫做一个体系。

这张图，我们认为未来所有的企业都是一个数据工厂，看上去现在华为在生产的是手机、电脑、电信设备，但是只要他掌握了用户的数据，B端、C端，它知道用户喜欢什么，行为模式，消费模式，它完全可以在现有的用户数据基础上开发出产品。然后至于说这个产品可能是农业的，可能是汽车的，然后它快速的把用户产品的画像连接到供应链上，让行业里帮它生产出这样的产品。所以未来的企业都会是数据工厂，都是加工生产数据的工厂。

这样的一个数据工厂需要什么东西，需要什么样的结构，我们可以看到它需要有数据员，就是原材料的加工，然后把原材料取过来过磅，原材料经过质检检验，进入到原材料仓库，这就是我们所讲的数据湖。

然后不同的数据产品它会有不同的生产线，这就是我们所讲的data plan数据流水线，然后数据流水线生产出数据服务，这个数据模型就放到数据集市里面，它就是半成品的数据的服务。

生产数据的厂房会有创新实验室，专门研发新产品，会有治理数据的管理办公室，去保证工厂整个运营的效率，也有控制中心，监控中心，保证整个data pipeline、数据处理的性能，安全性和稳定性。然后最顶上是你的数据服务商店，把这个数据产品，一个一个的数据服务，一个一个的智能模型，算法模型放到这个商店里面，供数据消费者去调用和使用。所以我们把这个理解为成广义的数据中台。

数据中台对企业的价值

1. 应用开发要快于数据开发的速度

原来我们在做一张报表，或者是在业务系统里面需要查询一个数据结果的时候，它的过程是比较麻烦的，而且它的测试往往也是比较复杂的，因为业务系统是有业务属性的，但是数据是跨业务的，是融合的。

在OLAP领域中，很多这种情况，比如说我的企业，Java开发工程师很好找，做应用的人很好找，懂data，知道如何做数据建模，如何做算法的人相对来讲是比较少的。但是在我们应用开发过程当中，我们会发现有太多的数据需求，这种情况下应用开发的速度是快于数据开发的速度。

2. 加速从数据到价值的服务产生过程

在很多时候我们会发现不同的应用开发项目组，他们都会调用同样的数据模型，同样的数据服务，但是由于不了解数据，并且他们也不知道底层的数据结构。所以他们不同的项目组可能对同样的数据处理会用不同的方法，自己做自己的，然后出来的结果不一样。有的是错误的，所以开发速度慢，并且数据结果不准确，质量低，这就是过去应用开发和数据开发所面临的矛盾。

但是现在数据中台就要解决这个问题，数据中台要把那些复用的数据模型，要把那些数据模型data派对中一些数据复用的能力，变成一个数据的能力平台，让那些做数据的人专注在做数据，把数据变成一个乐高积木，数据服务提供给应用开发。

然后不同的应用开发项目组可以共同的去调用唯一的SARS数据服务，去保证它的数据质量和一致性，加速从数据到价值的服务产生过程，打造高响应力且更加智慧的业务。

回顾

数据中台解决的核心问题：

• 解决应用开发快于数据开发的效率问题。
• 解决数据开发与数据产生价值的协作问题。
• 解决在很多企业，它的开发人员，技术人员没有数据能力的问题，这是它从技术层面的核心问题上来解决问题。

那是不是一定要做到保证数据质量百分之百，在没有问题的情况下，才能够去做数据系统，才能去做数据服务？

从这点上来讲，实际上数据和业务之间的速度一直是不一致的，我们的业务永远比这个系统的开发速度要快，就是我们物理世界里的业务一定比你的软件的开发要快。然后软件从软件本身到沉淀出数据，这又是一个滞后的过程，所以数据与你的企业的业务一定是不一致的。

数据的及时性，数据的一致性和数据的集成性问题，在某种角度上来讲，它是不可能百分之百彻底解决的，除非你的业务是静态的。因为你的业务呈现是在变化的，你的用户天天在变，我们的业务部门天天在思考创新，天天在希望找到新的客户的模式，这一切的创新落地下来就是数据，你的数据时时刻刻在发生变化。

就是说，有的企业的业务报表系统上线以后，上线两个月很好，上线到第三个月的时候就发现报表不对了，而且他也不知道问题在哪里，然后他就需要去查看整个的过程。因为数据系统它有很强的不确定性，因为它的来源控制不了，它的来源是来自于它的业务系统，然后业务系统是变化的。

如何加快从你的业务到数据到你的数据产品之间的反馈的速度响应力，也是数据中台要解决的问题。它要把应用的价值，应用的速度，和你数据产生的速度中间的差异，时间的差异和有时候业务理解上的差异，通过数据中台去把它弥补起来。

数据中台应该具备的能力

下面这个图，我们把它定义成是现在数据驱动的智能企业的一个模型，然后我们可以看到这里面有六大功能，其中除了灰色的部分，我们认为是传统的数据平台提供的功能。那么之外的这五大功能，我们认为这就是现在企业里面所讲的数据中台所应该具备的能力。

如果有一个数据中台所谓的厂商找到大家说我们给大家提供数据中台，我们可以对比一下，他有没有现在所讲的五个功能，五大领域的功能。

1. 数据资产的规划和治理

你有什么数据资产要存什么数据，这个东西一定是要有统一的规划的，而且是要有系统经营管理的，所以每一个数据中台一定要有一个数据资产目录。至于数据资产目录是长什么样子的，要怎么去构建，那么在其他的topic里面我们去讨论，这里就不详细去讲了。

2. 数据资产的采集、获取和存储

这就是传统的数据湖数据仓库所做的事情。

3. 数据资产的共享和协作

数据仲裁很重要的一个功能是让企业的数据，企业拥有的数据，能够在内部开放，对你的生态开放、用户、员工开放、数据的消费者开放共享和协作。在很多时候我们看到有些企业，他自己的部门之间都不清楚他企业有哪些数据，数据在哪里，有什么价值，如果这一点数据中台解决不了，那它就不能称之为是一个完整的数据中台。
这个是怎么去做的？我们把它叫data is great。就是数据探索的平台。

4. 数据业务价值的探索和分析

数据中台一定要有一个能力，就是除了存储数据，然后管理数据资产之外，它一定要能够提供面向用户的这种价值探索工具。让用户，让不同层面的用户，比如说有数据分析人员，有业务分析人员，让他们能够在数据中台提供的工具里面去探索业务价值。

比如说我们现在在研发，当然行业里面有很多也有这样的系统，它能够让你把你企业里的数据服务，同你企业的数据集放在一起，然后让业务部门，让你的业务人员做self service，自己去探索这些数据集，发现它的业务价值，我们把它叫做datenight。

然后当你发现这个数据集很有价值，对你的业务很有帮助的时候，数据中台能够提供一个能力，那就是快速的把这些数据数据集以一种合适的方式发布成数据服务。

5. 数据服务的构建和治理

当然这个数据服务一定是要有治理的，不能出现数据服务重叠，然后浪费好多服务放在那里没有人用。

6. 数据服务的度量和运营

数据类的项目一定是一个持续的项目，它一定是不断迭代不断分析的项目，它不仅仅是说我产生完数据我就完事了，或者说我把数据报表开发出来我就不管了，一定不是这样，所有数据的项目都是要持续的去运营的。

运营的目的就是去看我产品数据服务是有谁在用，他们用的反馈如何，哪些报表，哪些数据产品没有人用，哪些产品它是可以合并的，使用这些产品的用户画像是什么，他们有什么特点，如何更好地为他们提供服务，所以数据中台一定要具备数据产品运营的能力。

刚才我们所讲的这六大功能，在这个数据服务工厂里面都能一一得到映射。

我们所讲的是一个广义的数据中台，然后同时我们现在在很多企业里面，我们也会看到，有的企业它不可能一上来就构建一个这么庞大的数据服务工厂，如果他要做数据平台，它先做什么？他现在可能连数据湖都没有，数据平台也没有，那怎么办？他还要不要做数据中台？

我们所讲过的，只要你的前台业务系统有多个，而且你希望你的数据服务未来是可复用的，被多个业务系统所使用，提供平台性的能力的话，你就要构建数据中台。

那么你的数据中台可以简单到它就是只提供一个data API，哪怕它后面没有数据库，没有数据湖，没有数据平台，然后是人去维护一个excel表，然后把这个excel表的数据变成一个data API让业务部门去调用，我们觉得这就是数据中台的一个核心，那就是提供数据服务。所以我们所讲狭义的数据中台，那就是数据服务data API。

data API和传统的数据报表很大的区别在于数据报表是单向的，是人机接口，人看报表。数据API是什么数据？

API是可被监控的，是可被调度的，它是一个机器与机器之间的接口，是由你的电脑，你的应用去消费数据，不是由人去看数据。

所以这是很重要的，数据服务是我们所讲的狭义的数据中台最重要的部分。如果你要做一个最简单的数据中台，那么很简单，你只需要去把你的数据变成服务提供给你的多个业务用户，或者是你的多个业务系统，它就可以被称之为一个数据中台。

数据中台、数据仓库和数据湖传统的区别

数据中台距离业务更近，数据平台、数据湖是被动地响应业务需求，用户说我要什么，然后你有什么数据，然后我来给你提供什么数据服务，但是数据中台是业务需求驱动的业务服务平台。比如说，现在很多企业在做数据中台规划的时候，第一件事情不是去看他的数据，他有什么数据，那是第二件事情，第一件事情先看他需要什么样的数据服务，什么样的数据对他有价值。

小结

数据平台、数据仓库和数据中台的关键关系？

数据仓库是分析报表及服务，数据平台和数据湖是提供数据集，我把一个数据集给到你，然后业务部门根据这个数据集拿到数据库的链接，自己去做开发。

数据中台是什么数据？数据中台最核心的就是data API，它提供一个一个的可以复用的标准，这种数据服务给到业务系统。

构建数据中台和构建数据平台也有很大的区别，构建数据中台一定是业务价值出发，而且数据中台一定不是一个单体的产品，数据中台里面的组件是有的是可以产品化的，比如数据存储，比如说你的数据分析工具，比如说你的数据探索的工具，你是可以有产品去组合的。

但是数据中台一定不是一个产品，每个企业的数据中台会依赖于他企业的业务模式，他企业的信息化水平，他企业的投资预算，依赖于很多他的个体化，个性化的因素。所以数据中台对于不同的企业来讲，它一定是一个定制化的系统。因为它跟业务息息相关。数据中台的架构一定不是一个固定的，它一定是眼镜式架构。

比如我们现在在有一个客户那里，一个做全球润滑油的零售客户，我们跟他们合作已经两年多了，将近三年了，他们最早的时候还没有数据中台的概念，但是从他们最早的时候，由于在中国没有it，所以他们最早的预算非常低，非常小。

但是在那样的情况下，可能也就很少的预算，我们也能构建一个数据中台的雏形，然后一点一点地快速地为他们的业务产生价值，并且持续的演进到现在他们已经有了自己真正的数据中台，做的是比较完善的了。

数据中台的建设要有战略耐心

投资方要有战略耐性。

不是说我给你钱，给你1000万，你赶紧给我买个数据平台回来，然后买完了以后赶紧要产生业务价值，往往这样的项目，我们认为数据中台的构建一定要是平台就是数据的部分，技术的部分和业务的部分要同时前进。

但是它一定会有一定的过程，你的数据价值的探索，到你的数据价值变成一个数据产品的设计，然后变成一个可用的软件上线，这是一个需要时间的，所以我们认为投资方要有战略耐心。要认识到从数据到业务价值是有一个过程的。

建设方也要有耐心。

建设方不能好高骛远，一上来就做一个庞大的能力，然后在上面再生长，因为变化太快，技术更新太快，业务变化太快。所以我们所讲的数据中台的构建方式一定是敏捷的，然后是不断的迭代。

思考：数据治理是伪命题吗？

是因为在五年以前，十年以前，我在做传统的数据，做了很多数据治理项目，那样的数据治理项目在他看来很多是不成功的。之前我们所讲的成功是项目系统验收了叫成功，但是现在我们理解成功指的是它对企业的业务带来价值。

我们回想起来，过去的数据治理的项目，会产生三大类的服务：

• 第一类，一堆流程，一堆标准，就是一堆文档。
• 第二类，产生一堆岗位，就是会有很多的人，原来做业务的，做技术的，现在专门出来给它个名词叫数据管理员，或者给它个名词叫数据管理委员会，或者是物料审批员，像这样的名词会产生一堆岗位。
• 第三类，会产生一堆系统，元数据管理系统，但是数据治理的项目都往往做起来都很庞大，因为我们希望就从根本上解决企业级数据质量的问题。但是现在我们回过头来看，我们觉得这种方式不一定是最有效的，而且很多时候当你把这些标准做出来，把系统做出来，实际上当时认为你可以解决的这些问题的这些数据已经发生了变化。

刻舟求剑是一个很好的名词来形容这个数据类项目数据治理的特点，因为数据在企业里面它是流动的，像河水一样，永远是在流动的。

而我们企业追求的是什么？

就是数据的流动速度。我的数据流动越快，我产生的数据越多，我对用户的维度越细分，我的企业的经营就越有活力，我在市场上就越具有竞争力。但是你流动的越快，你很难保证。因为它一定会有你想不到的东西，你的系统响应力一定没那么快。

这种情况下，我们希望现在用做一个数据标准做一个数据模型，然后做一个数据治理，然后就好像是说在河水上加标准化的检测站一样，这是做不到的。所以我们现在所讲的治理，把它叫精益数据治理，在业务层面跟业务一起去治理数据，而且我们追求的不是说一定要把数据质量设计到好多完美，做不到，这是不可行的，达不到的。

我们的目标是哪怕我的数据只有50%的准确性，那么在我提高数据质量同时，我也希望这50%准确的数据也能为我产生业务价值。这句话是我们现在正在尝试的，也是用来做的。

数据中台和业务中台的区别

业务中台让前台开发更敏捷，为什么业务中台起的作用是把多个交易权，比如用户查用户创建订单的API，你的生成库存入库单的这种API全部把它合并成一个，然后让前台去调用，它是为了让前台开发更敏捷，速度更快，而且更标准。

数据中台是什么？

数据中使前台更智慧。当然它也可以加快前台的开发速度，但它更重要的是使前台更智慧。

业务系统，原来是跨类的，是分领域的财务系统，我只有财务系统的数据，我就看不到物资系统的数据，我的物资系统的数据，只能看到物资的，我看不到我的设备。所有的跨域的数据融合在一起，形成数据动产，形成数据有洞察跨域的历史的融合，将这些数据服务提供给前台，能够让前台更智慧。

举个例子：最直接的就是动态价格，像滴滴每时每刻的价格一定是不一样的，在不同时间点怎么出来的，一定有当时现在的空间上的，不同地点的这种价格的一个匹配，同时它应该也会有历史的在这个时间，在这个地点的一个价格的数据，然后融合在一起，快速地生成这种实时性的价格。就是OLAP的这些数据服务，从原来的数据报表的形式变成一个一个的这种API时时的去驱动着业务的变化。

数据中台和业务中台的关系，在行业中认为最经典的就是数据中台在提供服务到前台业务，同时它也提供数据服务给到业务中台。

业务中台和数据中台的服务的区别，刚才提到了，这个数据中台是智慧的服务，有这种智能的数据服务，也有查询类的，还有搜索类的，它总的来讲就是给业务系统提供你的数据动产，提供你的这种智慧的决策，提供你的业务规则。

业务中台是什么？

业务中台是产生数据。我去产生一个订单，我去生成一个库存，生成一个项目编码，这是业务中台。

所以总的来讲，数据中台是企业的数据服务的工厂。那么这样的一个工厂是企业运营数据、加工数据、交易数据的一个平台。在把这个数据中台做好以后，我们还需要运营。

我们认为数据正在逐渐成为一个新的领域，新的行业。像现在的很多原生的数据，原生的这种数字化企业，它实际上加工生产的就是数据，像今日头条，它本身没有任何的实物，数据是它的原材料，它生产出来的都是数据产品。

数据中台的绩效体系

前面讲到数据，中台一定是一个组织，是个团队。那么如何对这样一个组织团队进行绩效，很重要的就是度量数据服务调用的满意度，你这个数据中台产生的数据服务运营，被你的消费者所使用，他们的满意度产生资产，带来业务价值。

所以我们希望通过数据和智能这样的技术，通过数据中台能够赋给企业以数据和智能的能力，我们认为这是数据中台应该承载的价值作用。

Q & A

问题一：企业构建数据中台是否存在一个量化或判断的标准？

对这个问题有几种解读：

第一种解读是说企业是否要构建自己的数据中台，这个问题有没有标准？以这个问题来讲的话，我们认为所有的企业它都需要数据中台，因为他需要从数据里面获得洞察，从数据里面获得它业务经营的指导。

那么这个问题的第二个解读就是如何去度量和判断数据中台做得好不好？数据中台做得好不好，有没有给企业带来价值？我们有一个非常简单粗暴的度量方法，就是数据服务被业务系统和业务人员使用的满意度如何？第一我们认为数据中台本身应该具备快速的将数据变成API的能力，而不需要让技术人员一个一个去开发API。

数据中台里面的六个能力里，数据中台很重要的一个能力，就是数据服务的构建和治理。数据中台要具备一键式的数据API的生成和一键式的发布，包括数据API的治理，比如说数据API的搜索，数据API的编排，数据API的发现监控，都要有。

问题二：数据中台之外，还有哪些方法进行优化？如何能更好的以业务驱动数据？

我们认为数据中台是一个体系，除了技术的因素之外，有一个非常重要的因素，那就是数据思维。

所以在构建数据中台的同时，企业一定要加强培训，让业务人员具备数据思维。数据思维是数字化的系统里面的这种语言和交流方法，所以我们在构建数据中台的同时，一定要有配套的培训，配套的技能培训、理念培训。

配套的这种案例分享，让业务人员知道行业里面其他的这种公司，其他的行业再用数据做什么，只有这样的话，数据中台能得到更广泛地使用，才能得到业务部门的认可，否则的话会像原来的传统数据湖那样不被业务所接受。

在这一点上我们又会发现，现在数据中台所受到的欢迎，不仅仅是受业务人员的欢迎，它也很受技术人员的欢迎。那些原来做数据仓库，做数据湖的技术人员，原来离业务太远，他们做的东西开发出来了，然后给到业务，业务说不行，这东西不是我要的。但实际上他们很苦的是在最早的时候，这就是业务部门提供给他的需求，等于是前面提的需求后面又发生了变化，他们就很痛苦。

所以根本的原因是什么？

• 第一点，根本原因是他们太依赖于数据本身。业务人员不懂数据，技术人员不懂业务，这是原来数据平台的这种团队和业务团队脱节的地方。那么数据中台，我们认为它从结构上，从理念解决了这些问题。
• 第二点，是业务驱动数据，业务要懂数据，数据要懂业务。它俩之间是要拉通的，否则的话业务提供出来的需求很多时候是不具可行性的，或者说它是用原来的技术和方法思维再提需求，它在提需求的本身已经提出了对这个问题的设计。所以它俩之间一定要是拉通的，所以业务价值出发。
• 第三点，小步迭代。不断的去优化和演进的，而不是做大而全的这种数据系统。
• 第四点，要持续的改进，持续的去运营。数据的系统有一个特别典型的特点，那就是不确定性。

每个企业都希望自己的河水跑得更快，如何在这样河水里面去做系统？怎么去操作？怎么样去产生业务价值？

很重要的一点就是不断的持续优化，随着你河流水的速度，水的温度，水的配方，就是它的里面的元素不一样，你要产生不同的应对的方法。

问题三：数据中台的产品化和定制化比例？

是个很好的问题。刚才我们回到这个图，这个图就很清楚。这里面灰色的部分我们认为是存储、采集，除了集成工作之外这些东西，这些部分相对是比较标准的，结构化，有结构化的存法，非结构化有非结构化的存法，然后你的IOT的数据有IOT的产品去存储，所以这一部分基本上可以产品化，可以用开源的套装或者是产品化去解决。

然后在这个数据资产的共享和协作这一块，基本上百分之百都是要定制的，因为不同企业的数据模型，企业里的数据安全的管理方式都是不一样的。所以这一部分数据资产从规划到治理到共享到协作这一块，可能里面有的小部分的组件可以产品化，但是对于数据资产的管理来讲，一定是要控制在企业自己的手里。

也就是说它的知识产权和它的技术核心是要掌握在企业自己手里面的，因为数据资产未来是一个最重要的资产，它的数据安全性是企业里面重要的命脉。

至于业务价值的探索和分析，这个相对来讲可以有一部分的产品化，比如说像现在行业里面的data库这样的数据科学平台，比如说像有的行业里的这种机器学习平台，它部分跟你的业务关联，但是业务关联不是那么的大，它是比较偏技术的，这部分是可以用。

你的数据服务的构建和发布，还有治理这一块，一半一半吧，我们觉得有技术能力的企业尽可能的还是自己研发，你可以用开源的产品，因为你从数据到数据产品的构建过程，实际上也是非常核心的企业的竞争力。

最后数据服务的度量和运营，这个一定是客户化的，因为凡是涉及到数据资产的，当然这里面我们再提另外一个概念，数据资产在很多时候被认为是原数据。但是我们现在认为数据资产还包括那些二次加工的数据产品，还包括我们的数据报表，包括我们的数据服务，所有能够产生价值的数据的资源都叫数据资产。

所以与数据资产相关的我们认为尽可能的定制，因为它是企业的核心资产，它要变成企业的核心能力。

所以这样来看，我们总结一下，基本上产品化和定制化的比例，我们认为可能在三七，也就是30%的纯产品，70%的定制。

问题四：投资行业如何解决中台产品的跨行业问题？

这是一个比较有意思的行业，因为我知道投资行业，它跨的维度非常的广，虽然每个投资公司不一样，他们的选择的行业，选择的投资航道不一样，但是即使是同一个行业，他的里面的细分还是很多的。

所以这个问题坦率来讲有一定的专业度，但是我们举个例子，在17年的时候，我们做过一个数据资产创新平台，实际上它就是现在数据中台的前身，基本上是一样的，只不过那时候数据中台的名字还没有产生。那个案例的客户就是一个有五个业态，60多家企业的一个超大型的集团。

它有航空业、物流业、仓储业、跨境电商、通关贸易，还有供应链金融，这么多的这种行业，我们做数据中台怎么做？

很重要的一点就是抓最重要的数据先集成。比如说在那个项目里面，我们最先集成整合的核心数据是哪些？

• 第一，是用户数据，订单数据和支付数据。这样的话，我们能快速地产生业务价值。
• 第二，构建数据资产平台。我们把不同的业态，对它进行整个的data治理，我们把它叫精益数据治理。精益数据探索是把这些不同业态的企业，它的信息化程度，它的核心梳理出来。

我们如何确定它是不是数据资产呢？

很重要的一个标准，就是他会不会被别人所调用，会不会产生价值？所以第一件事情，制定最核心的数，把最核心的数据变成价值。第二，建立全量的数据资产平台，也就是数据资产目录，现在这行业里面叫Data Catalog。

这样的话，不管他有多少行业，能我们都能够抓住他最有价值的，最快速产生利润的产生收益的这部分数据，同时又可以整个企业集团，在跨行业的高度上，把企业的数据资产梳理出来，所以这两件事情是非常重要的。

如何解决跨行业的问题呢？

我觉得这个问题作为投资行业来讲，如果你投的公司是不同的行业，你的数据中才有必要，跨行业可能有时候是不可能，有时候没有必要，但是如果你希望说你投资的这些公司，跨行业之间产生价值拉通，把不同的行业变成一个贯穿的价值流。

这个就很有意思，这个就跟我们17年讲的案例是一样的。它把原来五个业态的业务通过用户订单和支付穿在一起，在数据资产创新平台上，利用现有的数据，融合了用户订单和支付产生了新的产品，构成了一个新的价值流，甚至创造了把过去五大业态的这些不同的API不同的服务，全部整合在一个平台上的一个入口，然后营销，这就是非常典型的一个跨行业的数据中台案例。

讲师：史凯

本文由 @史凯 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议