数据化建设：面向数据流的产品迭代与业务闭环

Sharer: 人人都是产品经理 July 12, 2019 at 6:20 am

Link Share :http://www.woshipm.com/kol/2551438.html - via RSS

2019年4月13-14日，人人都是产品经理举办的【 2019产品创新大会·深圳站】完美落幕。神策数据创始人&CEO桑文锋老师，他的分享主题是《面向数据流的产品迭代及业务闭环》。

一、数据与产品创新的关系

数据产品创新，是不是意味着产品创新都依赖于数据？

显然不是。在我来看，一些小的创新，可以不依赖于数据，但是大的创新和需求处理是离不开数据的。这不仅仅是相对于现在互联网创业来说的，在历史上，也有许多这种案例。

毛泽东在1927年撰写的湖南农民运动考察报告，就是在做数据收集。根据这个数据收集，后来得出了一个产品创新——建立了一个井冈山革命根据地，改变了整个中国的格局。

假如当时没有经过数据收集，直接把已经实践成功的苏联城市暴动的思路拿到中国来，行不行？很明显，这是别人的产品，它不一定就符合你的自身发展情况，所以，是不可取的。

又如深圳特区，没有前面对整个经济发展数据的关心，以经济建设为中心，就不会有现在的深圳特区。

所以，很多时候只要前面这些数据的事情做到位了，它会孕育大的创新。对于国家来说如此，我相信对于一个企业来说，更是如此。

所以，我们现在就要考虑：在我们的日常工作中，能不能把数据做好？能不能让数据发挥更大的价值？

二、从“IT化”到数据化建设

从2000年到2015年，中国就在干一件事情——“IT化”，比如：上ERP、上CM、上财务软件、建个官网。

但是，我认为，从2015年到未来2030年，将会进入另外一个阶段—— 数据化建设 。

当然，现在我们去谈数据也很重要，但是如果再换到五年之前，大家会不会这么想？

大家想一想，假如在五年之前，我提这些与数据相关的东西，肯定会有很多人会觉得：大数据其实就是忽悠，根本看不到大数据有什么用。所以，数据化思维的普及，其实也是需要一步步去渗透到人们的脑子里的。

许多公司可能会说：我之前有个业务数据库，业务数据库里面有一些数据，那么这不就已经是大数据了吗？数据规模只要大到一定程度，不就是大数据了吗？这不就已经把整个数据化建设完成了吗？

是不是这么回事？

其实不是的，从整个理念上来说，还是有非常大的差异。一些传统企业，比如银行，他们整个业务运转可能是：组合业务部门与IT系统的功能，形成一个业务流程；在业务流程里面，IT与人的相互配合，最终把这个业务完成了。

这也就是说，以前我们整个信息化建设的过程是面向业务流的。在这种情况下，它肯定是要比那些纯粹靠堆人做起来的业务效率要高很多。

而我们互联网领域可能是这样的：比如说我之前工作了八年的百度，百度可以说整个业务全部都是线上的，有一堆IT系统。假如今天全百度的人都休假，都不在上班，没关系，整个百度搜索引擎还是依旧能够很好地运作。

1. 数据只是IT化的一个副产品

这里有一个问题：在这些用户去使用IT系统的过程中，相关的数据是不是也会被有效地收集起来了？

以前我们在进行一些IT化建设中， 数据只是IT化的一个副产品 ——也就是说他是顺带产生一些数据。虽然以前的IT化建设中也会有一些数据，但是它的目的却不是为了生成数据，而是为了满足业务。

所以，当你拿着IT化进程中产生的数据，去实现更多数据化运营的事情的时候，你就会发现他们其实是缺胳膊少腿的，它们缺少一些环节——有些数据该采集的没有采集，有些数据该打通的没有打通。

这是一个非常大的一个问题。所以，我们整个理念上需要做一个转变——我们要目光从 面向业务流的IT化建设的过程 ，转向 面向数据流的信息化建设的过程 。

这意味着什么？

意味着我们整个IT建设的逻辑需要改变一下——我们要去想，人做的一些事情，能不能通过一个IT系统去做配套。比如产品经理就应该考虑，自己做的许多事情是不是都能用IT系统去支撑，而不是只将这些事情装在脑子里，没能有效地落地下来。

2. 建设IT系统，不是最终的目的，而是一种手段

我们在建IT系统的时候，我们要相信一点，它的目的是为了生成数据流。

每建一个IT系统，我们都要问：我们能够得到什么数据？这个数据能够支撑整个数据体系去完成什么事情？最终形成一条数据流，然后在这个数据流上去构建应用，所有的一些分析，还有一些产品的流程，都是在这个数据流上去做的。

当然，有些人可能会问：“比如，我们要怎么把长江、黄河这两条河打通？可不可以接一个直径四厘米的管子，然后把长江黄河通一下，就说这两条已经变成同一条流了呢？”

显然，是不能这么说的。但实际上，我们在进行一些IT构造的时候，可能就是这样的——你会觉得很多地方是可以相互打通的，是能够去结合起来的。但如果你从数据流的角度去看的话，你会发现数据之间根本没办法很顺畅地去交流，连贯起来。我们做to B服务的，要卖数据、分析相关的产品，就会牵扯到很多这种系统。

在我看来， To B其实要比To C复杂，因为To B有许多环节是靠人去做的，甚至有一半的环节都是靠人的。To C可能你能做到不需要人去干预，就能把事情做好。所以，To B不管是市场营销、销售、还是客户成功环节，我们都会用一些IT系统。

IT系统本身都会产生一些数据，把这些数据组合起来，同样可以形成一条数据流。在数据流的基础上，我们可以去做很多应用——比如：营销销售一样的全漏斗分析、销售过程分析、全生命周期分析与预警。

3. IT只是数据的一种支撑而已

在这种理念下重新去构造整个数据体系，而不是想要某一个指标，就围绕这个指标去采集数据，然后去做一些数据的可视化，就觉得数据平台建好了。这是远远不够，这也无非是围绕一些需求点做的一些修修补补而已。更重要的一点还是：我们要从底层去改变这种理念——要以面向数据流的这种思路去构建整个信息化的体系。

那有了底层数据流，我们能干什么事情？数据到底有什么价值？

“数据驱动”不是意味着有了数据就不用人为去思考了，数据只是支撑和驱动作用。就算未来有AI技术加持，这些数据可以被收集得更全更细，但数据依旧替代不了人。人的创造性是无可替代的，而数据只能起到支撑的作用，让你整个产品思路能够得到一些验证。

三、数据的价值两个方面：业务决策以及产品智能

1. 业务决策

数据是用来去支撑我们做业务决策的。这些业务决策是与我们的日常工作直接相关的，关系到两个方面——产品迭代和用户运营。

3.1.1 产品迭代

首先，传统的产品迭代，就是先有点子，然后再去做产品。

许多时候我们都会比较希望有好的点子，认为有好的这点子就能做出好的产品，就能改变世界了。

但是，我们知道这并不现实。其实，在我看来，在一些创业公司，一个产品经理就相当于一个小的CEO。也就是说，CEO去关注的东西，可能除了融资之外，剩下的产品经理都需要关注。这也就要求产品经理需要有综合能力。

但是，其实有很多创业公司的产品经理都非常初级——可能刚毕业，或者刚做个一两年，往往都是一拍脑袋，然后就立马去做决策。在这种情况下去做产品，要怎么保证这个产品本身的效果？除非你是张小龙，你每次拍都是对的。但是，我觉得更多的时候你没有能力，你还是要靠学习，还是要不不断的这种积累才能达到一个境界。

事实上，我们还可以用一种更加科学的方式去干。我们要转变一下思路，把从这个点子到产品的两个环节，变成三个环节——把数据去引入进去变成“点子-产品-数据”。

首先，我们来看一下从“点子”到“产品”。

我们在进行一些点子到产品的转变过程中，我们还需要去考虑一点：在这过程中，我们要去搜集什么样的数据，来验证我们提出的点子是否具备可行性？

这个时候我们就要去做一些预计——预计哪些指标会上升？哪些指标会下降？然后，通过指标去衡量，我们这个事情做了之后会不会效果？

所以，在产品设计之初，就应当把数据指标的需求提出来，再从数据指标中去评估产品思路是否具有可行性。

很多时候你决定要不要做一件事情，都要有数据支撑，要用数据来展示最终做的效果怎么样？所有的东西都是要看数据的，而不是说许多时候只是凭感觉，或者只是凭收集到几条好的反馈，就真的是认为这个产品是好的。

所以，我们要从点子到产品这个环节就开始去考虑：我们要收集哪些数据，要怎么去搜集数据？

从产品本身来说，只要它运转起来，就会产生数据，我们要从产生的数据中，去学习以下两个方面：

第一，我们要通过我们的产品、系统，去搜集一些数据，做一些效果评估，做实际的，关于用户的深入洞察。

第二，就是向外部学习，去做一些行业的调研，收集一些外部的数据，进行评估。

首先，要获取信息之间的差别：

我们要获取不一样的一些信息，然后在这个信息基础上，我们再得到一些新的点——哪些东西跟与预期是一样的，哪些东西是超出预期的，把这些去搜集起来你，再聚合成新的点子。

我们要把产品迭代当做是科学实验一样去完成，要在不断地进行假设，再去检验。

大部分互联网公司都是基于这个逻辑去做产品迭代的，但事实上，许多公司都因为数据流不完善，导致产品迭代没能做好。虽然我做为一个产品经理，很希望做好产品迭代，但是团队不给力，没办法给我提供数据，我想要的东西都拿不到，那我也无能为力。

所以，这就是我为什么会用大篇幅去讲整个数据流的建设——因为那是基础，没有基础，后面我们想做这些事情，其实都是做不了的；有了这些数据，我们在产品迭代的时候就会更加省力。

1）面向数据流的产品迭代案例1：电子银行贷款业务引导语优化

比如在一个简单的贷款应用中，贷款用户进来之后进行的一系列操作——比如他进行一个搜索，然后填一些信息，最终完成贷款。

其实这个环节里面，它每一个环节其实都会产生数据。如果我们以数据流的这种角度来说，我们都应该把每一个操作流程中产生的数据都去收集起来。收集起来之后，从中去看到底哪些环节出现问题。

可能搜索小区环节里面用户转化率是比较低的，有许多到这一步就流失了，我们就想我们怎么去改进它？

这里我们可能只是简单的去改一下引导语，这引导语可能就会让效果略微提升一点，但是我们一个产品的这种打造其实就是这样。就是一些小的点，然后去改造它，然后让它变的更好。

2）面向数据流的产品迭代案例2：互金完成页引导设计优化

一些流程比较复杂的一些产品，比如：金融类产品，其实用户的操作是有若干的步骤，他可能注册成功了，又要让他充值，充值之后又要进行理财产品的购买，之后又要引导他去推荐给新的用户。

所以，大家要考虑这一系列流程里面的每一步操作，用户是不是知道下一步怎么做？他是不是到某一步之后就会卡住，就不知道下面是怎么做的？再不断地优化迭代。

3）面向数据流的产品迭代案例3：海外电商提升新客购买流程转化率

问题： 8月中旬之后，订单量下降到一个较低区间。客户急需提升订单量来提升业务。

目标： 如何在当前投放基础上，将新客购买转化率提升1-2个百分点？

分析购买流程思路：

我们可以为用户操作的一整个流程创建一个漏斗，然后去分析：有没有哪一个环节的数据比较不符合预期，然后再去改进它。

改进之后，要进行数据分析，看看是不是变得像预期一样好了。我们去可以去做一个简单的拆解，比如：用户在下单，进行购买的过程中，客单价、订单、价格会产生怎样的不同的变化？哪些订单环节的用户流失率会比较高？

在进行数据监测、数据分析的时候，要注意的一点就是：指标本身应该也是有改变的可能性的——也就是说，我们看到这些数据指标，我们能够从中得到一些洞察，这些洞察能够指导我们进行下一步。

很常见的一个操作步骤就是分解，按照不同的区间，或者按照不同的类型去拆开来看，是不是有些环节这个问题更大？

得出核心问题：$50 以下区间，一半的结算用户流失

这里我们可能就发现：50美元以下的用户，结算流失率是非常高的。

这时，我们就要去进一步分析：这问题到底出在哪里？

提出假设：在线支付方式成为用户购买流程最后的障碍。

我们可能会怀疑这是不是支付问题，然后再进一步去查支付到底怎么失败的。

基于这个数据，我们可能发现：许多人是非授权交易。

非授权交易也就是：它本身就没开这个功能，当用户每次操作失败之后，就会想反正就买了这几十美元的东西，这个我反正完不成，就放弃了。

所以，你会发现这个环节中，你有两种选择：

这一类用户根本不是我的目标用户，我把它直接这个去掉——这是一种思路，但就要看你的产品定位是怎么样的。
我们想去挽救这些用户，去提供给这些用户更好的服务。比如：改一下包邮的门槛，或者去改进一下账单设置或付款的这种最小金额。

在通过以上分析后，产品经历了一系列的调整：

优化后的数据表现：

最终，我们要看这个结果是不是符合预期的。

所以，综上，一整个过程中，我们要发现问题要改进，就要先看数据。同样的，分析解决之后的效果会是怎么样的，同样也是看数据的。

4）面向数据流的产品迭代案例4：站内坑位归因分析

正常的一个电商类的产品，总是有一些坑位。这些坑位应该放什么样的产品，放什么样的这种商品，才会有更好的效果？同样，我们也需要去做一些数据分析。

用户访问一个商品，它可能有多种途径，比如：它可能通过搜索；可能是通过我们的分类栏目，或者通过一些其他的手段，也可能通过广告然后跳转。而哪种途径会比较有效果，哪种途径会更加带来更大的影响？

要分析这些问题，我们还是得看数据：

有一些电商类的产品，根本就不会去区分这些不同的坑位，不同的来源之间的区别，只会去看最终的转化情况——这就会导致一些栏目的转化效果跟你的预期是不一样的。

当时产品经理在设计之初可能想过：我们分类页其实不好用，但这块应该没什么人用，所以没关系。

但实际去看数据的时候，又发现：分类页其实对整个营收产生着非常大的影响，跟订单量之间有非常大的这种关系。

如果产品经理得知这个数据分析结果之后，就去想我们要怎么去把分类页，有重点地去投入改造——去做成一些专题，创造更多的内容，或者在这个内容基础之上再去不断的去找、写一些新话题，去整理更多内容，就有可能带来很大的新的订单转化。

我们应该是要基于数据去做运营，而不是说只是凭感受去做运营。

比如：当一些商品上架的时候，我们要考虑哪个商品放到哪个位置。如果我们没有数据，就只能凭借运营的感知——我们觉得哪些应该卖得更好一些，就往前安排；觉得某个不好，就往后排一下。

而在这个过程里面，实际情况可能跟他想的是不一样的。我们要去看看数据排在第几位，最终销售情况怎么样，再基于这些数据，去进行一些人工的调整。

当然，我们还可以引入个性化推荐，让它变成机器，自动地一步步去改进，最终带来业务效果的提升。

综上，产品迭代，就是：我们在做产品的过程里面，我们有了数据可以让整个产品的过程让它更加科学化，而不是说都是依赖于一些点子或者悟性这些东西。

3.1.2 用户运营

在我看来，许多时候，运营跟产品是不分家的。如果你产品做得非常好，咱们是不是运营可以轻松一点，或者反过来运营非常强；有时候产品这个弱一点，好像问题也不大，他本身之间是一个互相协作的一个关系。

但是，用户运营这个事情，到目前为止，国内做得还是非常的原始的。虽然说我们是一个脑力工作者，但实际上，我们在做事情的时候，还是按照一些体力工作者做事的这种方式去做的。

我们想开展一个活动，就要进行一些数据的调研，再去做一些评估；评估之后，我们要去把一些人抽出来，去订一个投放的策略，然后去投放；投放之后我们又要想办法，怎么把活动数据拿出来做一个评估——整个过程可能周期非常漫长。

我们可能花两个月时间才开展了一个活动，因为整个想拿的东西中间总是隔几天隔几天，然后才能做到，这就是效率问题。

另一方面，假如运营经理干了两年离职了，离职之后之前积累的一些经验，就完全没用了，完全就丢失掉了。

咱们能不能做一些改进，去把这些环节的效率提升？

我们能不能直接给运营经理一个数据平台，让他能够去抽取一些数据，直接订一些运营策略？直接把推送结果直接告诉他，整个环节数据团队不去干预，直接让运营经理去做，是不是效率就会提升很多？

其实，现在许多公司是做不到这一点的，所以，我希望大家都能把每一次运营都变成一次学习。

比如我们推送一个活动触达到一些用户，这用户里面有哪些人最终被转化了，哪些没有被转化？我们应该把这些东西都给他数据化下来，之后我们再去做的时候，我们可能是基于上一次活动的数据——比如触达到，没触达到的，或者用户做了什么反应。

然后，在这个基础上，进行下一次的运营，在这个基础上去迭代，然后一步一步往前去做。

在这里面有一些关键环节：我们要去构建整个标签体系。

底层虽然有很多数据，但这些数据还需要去组织的，用户的这种行为数据就是当产品展现给他的时候，与他进行交互的时候，这些都是用户心理、用户诉求的表现；我们要把这些信息都给它抽象出来，抽象出来用于我们整个标签的这种打造。

“互联网+”模式下的一些企业，特别是一些既有线上业务，又有线下的企业，有其实都会产生一些数据。这些数据产生之后，我们需要去想怎么去把他们有效地打通，然后组织起来。这个时候，标签就是一个桥梁。

我们需要把底层的标签去建好，抽象成更好的标签，这样，去做运营的时候才会更加容易。

在做的时候，我们要把业务跟整个标签的建设之间的关系打通，要明确做标签的目的是为运营服务。

另一方面，我们要思考的是：在添加标签、更新标签的时候，能不能调高效率？

有了底层数据，我们就要在运营中尽量让建立标签变得更加自动化——基于这些标签，通过制定一些运营策略，去触达用户最终的效果评估，再将整个环节串起来，这个过程尽量是通过运营策略的作用自动完成的。

现在许多产品，要加一个引导语，或者中间需要针对某些用户进行一些具体的操作，动不动都会牵扯到一些产品的改造，都是需要靠产品跟开发去实现的，运营经理做不了。

但我觉得更理想的状态是：有针对性地给用户推送消息，或者对用户的操作增加引导语，这些操作应该让运营能够独立地去操作。

在这个过程中，通过产品去搭框架，然后框架内容，要什么人过来就上什么菜，能够灵活去配置出来。这样的话，就不会过于依赖产品和开发。

接下来讲一下to b的运营：

ToB 为什么也要做数据化运营？

数据建设的痛点：

营销和服务端都缺乏用户行为的数据。
客户相关的数据散落在 CRM 等多个系统，信息孤岛严重。
同一客户信息在多个系统中不统一。

实际上，to B产品的运营，要比to C差劲得多——因为to B很多环节都是通过完全人工的方式来实现的，不管营销环节、销售环节，还是后面的客户服务环节；这些环节如果你本身没有把它很好地IT化、数据化的话，想提高效率，去改造的空间就比较有限。

业务工作的痛点：

CEO：

想了解一个客户的现状，只能问人。
想了解整体客户满意度，使用情况。

营销负责人：

不能追踪营销全流程的转化漏斗，找阶段问题。
不能准确计算ROI，指导营销策略。

客户成功负责人：

客户决定不续约，什么原因。
团队总是被动应对客户问题，士气不高。

就像我自己，作为一个CEO我需要去关注整体客户的情况——我们所服务的这些客户的状态是怎么样的？

我经常会见到一些我们to B圈的一些创始人，我问他们：“你们现在服务的客户的状态是怎么样的？”

——“挺好的。”

我说：“具体来说，好是有多大比例好，有多大比例不好，现在活着的有多少个？”

其实很多公司都是这样的：“一把手”的脑子里面，对客户的信息可能是模糊的，没有一个精确数据，只有靠感觉来思考用户的整体情况是怎么样。但实际情况是怎么样的，他们是完全不知道的，这个时候再进行一些决策的时候，很可能就是走偏的。

这里面有一些经营道理，比如：我们一个客户经理，他可能跟进了50个客户，但他绝对没有精力，把每一个客户都跟进到位，有可能把某一个客户忘了，下一次就流失掉了，这是完全有可能。

所以，我们能不能把整个to B进行数据化？

就像我前面讲的数据流，把营销销售、客户成功这些环节，通过IT系统产生的数据去把它抽象出来，抽象出来之后，去指导我们整个运营工作。

如果你把整个底层的数据建好之后，你可以从中发现异常，然后去有针对性地改进，再去进行效果评估，这就是完全科学化的一个过程。

有时候参加活动，某个创始提起我们两家正在合作，而我完全不知道这件事（毕竟我不可能每一个客户都能接触到），我就只能到我们自己微信群里面发个消息，问谁在跟进，让他们把情况给我说一下。然后我再跟创始人可能聊天，去谈谈合作。经常都是这样的，这些情况归根到底就是信息不同步。

假如我们公司有几十个销售，每个销售对接几个客户，这些客户的信息都在他们脑子里。我是不是也只有通过去问，才能知道某一个客户的具体情况。

所以，想要再做全局判断的时候，更有效率地去判断清楚，我们就需要把整个客户的情况完全数据化。之后，当客户经理再去跟进一批客户的时候，这些客户本身服务的好与不好，状态是怎么样的？哪些客户需要去拜访？哪些客户需要进行一些挽救措施了？这些他都可以通过数据化去有效管理起来。

2. 产品智能

业务决策只发挥了数据20%的价值，数据更大一个价值，是在产品智能——也就是： 让产品本身变得更加智能化。

我认为，智能化就是学习能力，所谓的学习能力就是：我们有了数据，套上一定的这种算法，然后把这个结果回归到一个产品里面去，让产品本身它可以迭代。

因为引入了数据，它本身具有一种自我更新能力。有了产品智能，我们可以作出用户画像，更加个性化，精准地推荐广告，以及反作弊。这些都是一些基本的应用，我相信未来在这些应用点上会越来越丰富。像一些视频的“猜你喜欢”，电商页面上的商品推荐，这些都是因为引入数据，并通过不断地学习，而让产品本身其实变得更加智能化。

产品智能其实就是使产品本身它具有一种学习能力，而不是靠人的学习能力去支撑。

在整个这种产品智能里面，核心就是四个环节：首先，拥有底层数据，构建整个数据流；其次利用这些数据进行建模；建模之后，根据场景需要去进行一些推荐；最后一个环节就是进行分析。

有时候就引入一个算法，它实际效果可能还不如你人工去配置的效果。更多的时候，我们需要在基础上进行调整——就是调参，要不断的去试一些策略。

比如：我们在进行客户推荐的时候，我们是决定是推荐一些热门的，还是一些推荐一些买的更多的，或者说推荐一些多样化的东西。你不能说她喜欢周杰伦，全部都推成周杰伦的东西，这就会出现问题。这个策略到底怎么制定，肯定还是要结合一些业务，结合一些业务场景，然后再去对它进行验证。

这里面就需要一些数据，我们要分析这些数据，去从不同的角度对比，到底这些策略有没有效果，最终这分析环节是必不可少的。

所以，这就是为什么有时候公司引入一个好的系统，但我们做了却没被人的效果好。

大家要知道一点：策略本身需要不断地改进的。

四、总结

未来会是一个数据时代。

一个企业的数据化建设程度，我们该怎么去评价呢？你现在所处的阶段是怎么样？别人有个报表，我们也有个报表，别人也建了这个数据仓库，我们也建了数据仓库，那是不是大家都是等价的？

一个企业要实现数据化，绝对不是仅仅靠引入一个平台，引入一个工具，这是远远不够的。对于一个企业数据化建设程度的判定，我认为应该从四个维度综合地去看：

1. 第一个维度就是：IT化

我们要实现数据化，IT化是一个前提，因为只有IT化的时候，我们才能落地，才有一个载体去产生数据。

我们很少谈农业大数据，为什么很少谈呢？因为农业IT化就不行，比如每一粒每一棵庄稼，它的长势如何，你根本就没有信心去收集起来，也根本就没能去建一个IT系统把他们管理起来。

那我们怎么可能实现数据化呢？

我们首先要考虑的一点：我们IT化程度如何？

2. 第二个维度：DT化

DT化就是围绕整个数据流的建设，从数据采集、传输、建模、存储查询、分析、可视化或者反馈，来展示：我们整个流程到底做了什么？现在所处的阶段是怎么样的？

3. 第三个维度：数据意识

现在许多企业，从一把手来说，具备数据思维肯定是没有问题的，但一线可能没就那么有数据意识——虽然说老大交代了我们要进行数据化，但怎么数据化呢？流程还是原来的流程，然后工作该怎么干还是怎么干？

这个是不行的，在实际业务中学会该如何更好地利用数据十分重要。

但，相反的，也有些创业公司的创始人是草根出身，没有太多数据意识，假如产品经理比较重视数据的话，他就得去说服老大，难度也是非常大的。

所以，我觉得一整个企业的数据意识包括两个层面：高层以及一线，都需要建立一个比较好的数据意识。

4. 第四个维度：组织与流程

因为我前几天正好上湖畔大学的课，我也是最近一期的学生，就听马云讲一个观点：一个公司战略调整，组织架构要跟着调整。如果战略调整了，组织架构没有跟着调整，那等于战略没有调整——因为你战略只是一种思路，你这种思路的落地是靠人的。

所以，我觉得整个一个企业数据化如何，还是要靠组织与流程。

企业的组织架构的建构中，需要为企业设立专门的岗位，需要有专员负责组织架构的建构。另外，产品迭代流程、用户运营流程、服务流程，这些环节完全是要依赖于数据的。

所以，我们可以回过头来看自己所在的企业：我们在这四个方面——IT化、DT化、数据意识、组织流程，围绕整个数据化建设做了哪些事情，是不是还有很大的改进余地？

相信从这个角度去看，大家能够更清楚地看到自己所在的企业有哪些不足，我们可以朝对的方向去努力。