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

不懂技术怎么做产品?15天在线学习,补齐产品经理必备技术知识,再也不被开发忽悠。了解一下>

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美元以下的用户,结算流失率是非常高的。

这时,我们就要去进一步分析:这问题到底出在哪里?

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

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

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

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

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

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

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

优化后的数据表现:

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

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

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化、数据意识、组织流程,围绕整个数据化建设做了哪些事情,是不是还有很大的改进余地?

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

相关阅读

所有的创新,最后都是人的问题

远望资本程浩:渐进式创新都是给行业老大打工!

好创新坏创新:如何实施营销创新推动品牌增长?

产业互联网,到底如何才能落地

一位好的产品经理,也是一位好的掌舵手

容许产品有缺点,不许产品无特点

创新:一段充满风险的向死而生的道路

研究完95后群体,我发现了这几点新机会

 

嘉宾演讲视频已经上架起点学院,视频地址:https://vip.qidianla.com/course/detail/1hl0j.html

课程限时特价9.9元,起点学院会员可免费观看。了解起点学院会员,详见 https://vip.qidianla.com/member.html

 

本文为【2019产品创新大会·深圳站】现场分享整理内容,由@Suri 整理发布。

未经许可,禁止转载,谢谢合作

题图来自大会现场

评论
欢迎留言讨论~!
圈子
关注微信公众号
大家都在问