Home » Headline, 网站分析经验分享

数据驱动的电子商务组织架构的迷局和反思

21 一月 2012 20 Comments

【每期一句】It’s a beautiful day, and I can’t see it.

【前言】

  莫道我不迷惘,我比任何时候都更迷惘。上次说到游泳的例子,我得承认,在游泳的时候,各种“怪异的姿势”,往往不仅仅是因为冰冷的河水,更是因为水中难保没有漩涡湍流,水草拽脚,以及一群混乱游动的人群的相互制肘。或许这些人是推着一条往前行驶的船,但可惜,力气未必是朝同样的方向的。

  这就是组织的困境。组织越大,力量反而未必越大。数据在这个组织中扮演什么样的角色呢?数据驱动的实现,需要什么样的组织结构,甚至,不仅仅是组织结构本身能够解决的?

  希望我能和大家一起找到答案。

【正文】

  人人都渴望数据,但这可能隐藏着陷阱。

  拥有数据意味着什么?——Nothing。数据不等于信息,更不等于真相。数据在大多数情况下,要么是没有得到利用,要么就干脆是纯粹的误导!

  人人都渴望数据,可没人尊重数据。矛盾吗?不,其实这幕天天上演。

  我们怎么样才能真正建立起称得上“数据驱动”四个金字的电子商务组织?为什么数据驱动的组织那么困难?这个问题困扰了我很久,我几次演讲,有被听众问到这个问题,我都觉得没有给出很好的回答。今天,2011年12月31日,岁末,我想这个问题我不能再带到新的一年才去解决了。(文章开始于12月31日,但完成于1月21日,作者后注)

迷局1:决定数据驱动型组织形成的关键是什么?

  数据驱动,这四个字中的“驱动”二字本质上直刺企业的核心。所谓驱动,即发号施令。没有发号施令,还驱动什么?因此数据驱动本质上,就是用数据来发号施令。

  但发号施令的决策通常来自于三个不同的方式:感觉(guts),经验(experience)和认知(insights)。相对而言,由于感觉和经验虽然模糊却得来容易,因此决策者常常不由自主的利用这两种方式作出判断,从而很迅速地作出决定,发号施令。

  显然,感觉和经验并非数据,虽然有时候人们也通过数据来形成感觉和经验,但更多时候人们倾向于选择那些与感觉和经验一致的数据进行研究和推导,而不愿相信那些与感觉和经验不相符合的数据。因此,感觉和经验,实际上是形成所谓数据驱动组织的最大障碍。

image   不过,请读者朋友们注意,我丝毫没有贬薄感觉和经验的意思。那些具有卓越感知和经验的操盘手,例如人人景仰的乔布斯,他们的感知和经验甚至可以凌驾一切之上,更何况在不太尊重数据的中国古代,还是涌现出相当多智勇双全,决策英明的英雄。而中国今天的商业智慧中绝对多的部分也是感觉和经验,绝非数据,这说明感觉和经验甚至是决定成败的。只是,我们今天的命题是数据驱动的组织,因此,我必须重申,如果一个组织确实依赖于感觉和经验,那么,数据驱动本身就并非一个重要的命题,在这个情况下,数据驱动与否根本就不会影响这个组织作出明智的决策。

  另一个困难的地方在于,从组织架构的角度讲,数据并不是只拿给CEO看的。所以,有朋友问,CEO或者管理层的态度对推进数据驱动组织的形成,是否具有关键性的作用?我认为,如果CEO或者董事会,不认可数据驱动型的组织,数据驱动当然就无从谈起。但是,CEO或者管理层支持数据驱动型组织的建立,这一组织也未必能够真正建立起来。

  我这么说可能并不会让你太吃惊。管理层可能有很多想做的事情,未必能够真正实现,或者未必能够按照原先的设想实现。数据的意义不在于仅仅提供给CEO一个报告或者参考,数据如果不渗透每一个执行层面,其意义会大打折扣。我认为,数据驱动的组织一定是宏观和微观的结合,即宏观层面上,要提供供管理层使用的策略型数据,不至让这个组织进退失措;微观层面上必须指导业务执行者的行动,让他们能够进行准确的选择,不用通过不断地“试错”才能知晓真正有用的下一步什么。宏观的确重要,但微观则更加致命,尤其是对电子商务组织而言。

  电子商务组织需要快速的反应和高度强大的执行力,管理层发起的那些至上而下的推动,在真正推动起来的时候,往往已经错过了时机。电子商务组织的时机很多时候并非是管理层发现的,而来自执行层面的敏感的嗅觉,这些嗅觉在一些场合下甚至直接影响公司的成败;另一方面,无论管理层多么强悍的推动,所有最终的实现都必须依靠“下面的人”,因此,“下面的人”——他们是否能够实现管理层的想法,才真正决定这个组织的成败。

  所以,回到我们上面的问题——就算CEO和管理层特别支持数据驱动型的组织,如果下面的执行者没有真正数据驱动的意识和需求,那么数据驱动型的组织也毫无实现的可能。

  我的观点是——数据驱动型的组织能否实现,要看需求方。真正的需求方是执行团队。执行团队是依赖于感觉和经验,还是依赖于数据,这才是数据驱动型组织能否实现的关键。如果执行团队渴望数据,利用数据,依赖数据,这个组织的数据驱动文化就很容易实现,而跟CEO和管理层其实关系没那么大。CEO和管理层要做的,是建立这样的执行团队,而不是生硬地自上而下的推动所谓某种以前并不存在的数据驱动的文化。

  从这个角度看,我们的电子商务企业中,大部分执行团队都或多或少需要数据,依赖的程度高低,便是这个企业数据化驱动程度的高低。不过,我想很多国内电子商务企业,执行团队应该都还是靠着感觉和经验吧!这便是数据驱动组织并非那么容易实现的根本原因。

  因此,数据驱动型的电子商务组织,基础性的第一步,是要建立真正的来自执行层面对数据的旺盛需求。这个需求不是CEO或者管理团队有一天忽然觉得数据无比重要而风风火火要求下来的政令,而是发自自然的,如同人们食色性也的需求。没有这样的需求,无论电子商务组织,还是任何其他组织,都不存在真正的所谓数据驱动。

迷局2:使能(enable)的误区

  现在,假设我们的电子商务组织的执行团队是一群真正欣赏数据的人,数据驱动型的组织是否就实现了?

  仍然很难。

  在封闭系统内,有需求未必就会有供给。你欣赏iPhone5,但你没这个能力自己做一个;你渴求数据,但未必你能通过自己的力量获得。

  所以,希望建立数据驱动文化的组织,一开始都把视线集中在建立能力上(当然,你要记住,如同我在迷局1中所写,首先是建立需求,而非建立能力)。

  构建能力被称为“使能(enable)”,让这个组织能提供数据,有多种办法,但最常见的想法,是我们下面的这个图所展示的解决方式:

image

图1:经典数据组织架构——hub模式 

  数据部门是个hub,这群人解决一个组织大部分的数据需求。当业务部门需要数据的时候,他们提交需求给数据部门,然后数据部门开始抽取、运算和分析,把数据和结果返回给业务部门。

  唉,说实话,这真是一种笨办法,这使我想起了过去无所不包无所不揽的计划经济。我相信这个方法的初衷是好的,这么建立数据能力有如下几个动因:

  1. 显然,这个方法能够让CEO或者管理层非常牢固的控制数据。数据比较安全——至少看上去是那样。
  2. 数据部门可以集中起来工作,这似乎对做数据的同事是不错的一点。
  3. 节省人力,组织看起来规划清晰。不用在各处安插做数据做分析的人,确实省下一大笔人力和管理成本。
  4. 相对简单的数据系统。因为数据部门管理数据,诸如权限之类的系统设计,可能就不是那么重要了,反正人来提供数据报表即可。该给哪些部门,不给哪些部门,人工去每次划分确定就好了。数据的模型——也没那么重要,人去分析就行了,不需要太高的自动化,也不需要太强大的BI。

引申阅读:网站流量数据无秘密

  将数据部门作为hub的一个重要原因,是因为希望数据能够被放在一个“保险箱内”从而“确保”了数据的安全。

  但这个想法多少有一点“一厢情愿”,我一直相信,网站流量其实无秘密。

  例如,想要知道一个网站的流量并不复杂,有太多的工具,免费的,付费的,还可以用我之前说的对比法:《如何获知陌生网站的流量?》。

  如果足够细心,甚至也能参透一个电子商务网站大致的销量和销售额。

  毕竟,电子商务网站本身就有很多信息可以透露给你。例如,商品消费的数量是可以查到的,而如果参考购买者做出评论的时间(在各个时间段发出评论数量的比例),则几乎可以确定一段时间内某个商品或者全部商品的销售量。

  销售量和客单价之间简单的关系——做出销售额不算困难。

  有销售量,又有流量,你能把转化率也估计出来。

  还有,流量渠道也不困难。很多工具都能告诉你一个网站的主要流量来源是什么,例如Hitwise。

  不仅如此,每一个电商网站都因为要与各种市场营销第三方企业合作,而被布上了各种代码。这些代码无时无刻不在透露着这个网站相关的流量和销售信息。对他们而言,一个网站就像被X光反复扫描一样。除非你不跟他们做任何合作,否则这些数据总还是要被第三方知道,而且签署所谓的NDA协议,也不过是“防君子不防小人”。

  其实,我认为,电子商务网站真正的数据秘密,是那些运营的细节。当然,还包括财务数据、商品的进货价格等等。但流量无秘密,用不着太紧张。

  但前面说过,这是一种笨办法,如果这样规划数据部门,可能会产生一些意想不到的结果。最可能产生的结局是:数据部门会——疯掉?

  这不是耸人听闻,如果数据部门要负责所有业务部门的数据,得需要多少人呢?肯定超出你的想象。此外,业务部门肯定不会仅仅只是满足于数据被提供出来,他们希望数据快些,更快些,他们希望实时数据。手工作业,实时太难,追求速度就意味着大量的人力和脑力的消耗。

  好吧,就算数据部门能够提供实时数据,又能怎么样呢?数据不是策略,数据总得再经过分析和处理。数据部门不了解业务,他们能分析好吗?如果不去做这些分析,那么业务部门还得自己去分析,实时性不仅得不到保证,数据部门的价值发挥也大打折扣。

  这种组织方式下,数据部门的价值和定位都很容易被质疑,而且他们还会苦逼地干得没日没夜。

  如果确实是这样一种组织方式,那么对数据部门的工作定义确实要非常谨慎。数据部门应该承担提供基础数据的工作,但他们没有职责,也不应该为业务层面提供战术性的分析,他们忙不过来,也必然缺乏业务概念。但这绝对不是任何一个真正“数据驱动组织”所应该具有的定义,这是“暴殄天物”的定义。

  因为这些不完美,有一种更先进一点的方式去解决上面的一些问题,并且开始被大家注意,且有被神话的趋势。

  这个方式,就是BI系统。

  BI系统的本质是用来取代人手和人脑。这是一个好方法。把人从机械的工作中解放出来,提供给业务部门自动化的报表,而且还能承担一定的思考的工作,BI系统是一个伟大的发明。

image

图2:BI驱动的数据组织架构

  这也是为什么,一个真正具有数据驱动文化的公司,必须要有一个确实好用的BI系统。或者,较浅浅层次的,得有一个自动化的报表系统。但是,据我所知,很多电子商务公司这个系统要么缺失,要么非常难以使用。

引申阅读:被神话的BI系统

  BI被神话不奇怪。凡是人们不那么了解却又外表光鲜的事情,都容易被神话。:) (网站分析多少也被这么神话着。这并不是好事情。)

  BI被神化的另一个原因,在于人们确实对友好聪明的数据系统抱有太多的期望。

  在Gartner的一次调查中,超过80%的美国电子商务公司期待更好的BI系统。

  但BI最大的问题是——机器终究是机器。

  BI可以解决一些机械的工作,能够建立数据模型帮助人们快速得出一些结论。但跟业务相关的细节分析,BI能够帮你发现现象,但无法告诉你原因。(我觉得,网站分析工具,其实就是BI工具的一种,它一样能够非常sharp的帮你发现现象,但同样无法告诉你原因)

  所有的答案,都需要人去寻找,去解答。

  此外,BI系统的效用,本身也极大的依赖于人。

  首先,BI系统的设计,必须与一个公司自身的业务相契合。人才能完成这个让BI与业务需求相契合和匹配的工作。

  其次,BI系统的建模和规则,全部是人来完成的。

  最后,前面说了,BI不可能给你答案,唯有人才能做到。

  所以,BI被神化的地方在于,认为一个BI系统就解决问题是不可能的。或者说,一个BI系统,不是狭义的硬件软件系统,而是IT系统+BI团队的结合。人,占90%,或者,占99%。

  尽管有被神话的趋势,但BI的意义重大,作为不可或缺的基础设施,若没有BI系统,或者连一个自动化的报表系统都没有,这个组织的数据驱动的文化很难建立。原因无他,若有需求而无供给,只会引发严重的饥荒。

迷局3:数据误读,比没有数据更可怕

  无论是按照图1所示的hub模式,还是图2所示的有BI系统参与的hub模式。业务部门都面临着很大的风险。一方面,前面我们说了,hub本身存在资源和响应的矛盾。另一方面,数据误读比没有数据更可怕。

  电子商务业务部门更强调业务能力,因此在数据的分析和解读上,能力相对较弱。与传统零售行业不同,传统零售的BI系统和分析团队往往经过了超过10年的进化,因此早已形成体系和一套具体的方法。电子商务虽然也属于零售业,但很显然,这些公司要年轻太多,让业务部门拿到数据后,自己去做分析和评估,是困难的。我最大的担忧,在于数据分析事实上容易变成一个粗暴简单并不断被“自以为是”的经验所干扰的工作。即使在做了很多的案例之后,我仍然认为,我没有哪一次没有被主观的感觉影响过判断,直到有更多的数据充实上下文才可能避免不客观的分析。而业务部门在拿到数据后,因为时间的压力和数据分析经验的缺乏,他们容易在短时间内得到结论,但误读数据,并进而造成这个结论背离事实的情况是时有发生的。而且,业务部门背负业绩压力,他们可能在一开始就主观上倾向于让自己不那么客观。

  我曾在心里默念,对于数据应该常常怀着敬畏的心,因为简单粗暴适用于网络营销,但绝对不适用于营销分析。数据误读,我记得派代上有一位专家专门写了一个帖子探讨,我不能同意更多,甚至也有完全相似的例子。如果你只是那么一点点粗心,或延续了“简单粗暴”的办法,那些数据中给你揭示的细微的差别,你可能会忽略,而这些差别可能会让你得出完全不一样甚至是相反的结论。

  例如下面的这个例子:

  对于下面两个图的数据实际上是完全一样的,可是,两个图给你的心理上的感觉却是完全不同的。

image

图3:利润趋势(1)

image

图4:利润趋势(2)

  尽管数据一样,但图3和图4用了不同的数据显示区间(Scaling)。由图3得出的结论,是利润在近期剧烈的波动,而图4的结论则是利润在近期平稳维持在低位。这两个结论并不能简单说明它们正确与否,取决于实际的商业环境。例如,如果你的生意平常一天是1000以上的利润,那么显然图4给你的结论更有参考意义,你应该探求为什么最近的生意几乎停滞了。

  但是,如果你的生意一天的确最多不超过100的利润,那么图3更有价值。而且你可能会觉得,利润数据还不错,这几天还有明显的上涨的趋势。不过,或许你还是不能高兴的太早。下面这个图(图5)和图3在利润上的数值是完全一样的,不过增加了另一个数据项:收入(蓝色点)。

image

图5:利润和收入趋势

  你可以看到尽管利润上升了,收入上升的趋势更为显著。这意味着,我们的利润增长并没有收入增长的快。或者换句话说,我们的投资回报率(ROI)下降了。因此利润虽然上涨,但完全不值得我们高兴。我们反而应该检讨,为什么效率降低了。

  数据的误读很多时候并非是故意的,而是跟经验有关。这些经验在于两点,第一点,对于数据的运算和把握。例如,合理建模,合理的数据可视化(Data Visualization),以及对工具合理的应用。第二点,在于对于业务的准确把握——做到看数说话,与实际业务几无偏差。第二点是建立在第一点的基础上的。如果第一点出现了一些问题,或是没有技能,或是没有经验,第二点便会遭殃,即使对于业务有很好的感觉和清晰敏捷的头脑,也会为数据所累。

  来看另一个真实的例子。

  我的朋友Johnny,他在为在美国销售某一个商品而投放Google AdWords的广告。这个商品的利润额在2011年每个月的表现如下图所示:

image

图6:Johnny全年每月SEM投放利润情况

  很显然这个商品的生意出了什么问题,有必要找出原因。

  利润下降,要么是收入减少,要么是支出增加,要么是二者同时发生了。从支出上看,每个月的支出变化不大,而且实际上,当利润降低的那些月份,支出反而也是略有降低的。那么很明显,收入下降是造成利润下降的主要原因。收入为什么下降呢?

  很快,他们找到了一个相当有说服力的数据关系:当SEM关键词的平均排名下降了之后,销售收入也非常明显的下滑。如图7所示。

image

图7:销售收入和关键词平均排名的关系

  现在,假设一个情景:有一个非常非常缺乏经验的初级SEM专员,他很可能给出的结论是:利润降低,是因为收入降低,而收入降低,是因为关键词排名降低,因此我们需要提升关键词排名,以获得更多收入提升利润。

  你当然相信这个结论是简单粗暴,并非反映事实。事实是,关键词排名升高,当然会获得更多的点击从而获得更多的销售额,但成本同时也会提高。所以,这个结论并不一定是正确的。于是,更有经验一些的SEM专员,会继续坐下来寻找下一个关系,如下图8所示。

image

图8:利润和关键词平均排名的关系

  这个图简直是上一个图(图7)的翻版,只是一个是收入,一个是利润,数据的比例尺不同而已。看起来,利润和关键词平均排名的关系和收入与关键词排名的关系也非常一致。现在,我们可以放心大胆的得出结论——我们应该提升排名,以获得更多的利润!

  于是他们提高了出价,提升了排名,并且在2012年1月份的这几天,得到了结果——利润不仅没有升高,反而更加下降了——甚至某些天是负的,尽管关键词的排名又重新回到了3位左右。

  之前数据反映了某种似乎确定无疑的关系,但按照这种关系行事,并没有带来预期的结果。

  我们必须承认,SEM投放是一个复杂的策略过程,并且因为瞬息万变的外部环境(竞争对手的出价),而造成最优化的出价方式总是动态的。

  上面的例子,Johnny认为原因很简单,这个商品的关键词投放可能已经遇到了瓶颈,因为外部的环境发生了变化。Johnny查看了其他的数据(我们当然不能忽略其他数据的关系),例如,CPC(Cost Per Click)数据,Johnny发现在这12个月中,CPC的变化并不大。CPC没有明显变化,而排名在逐渐降低,说明竞争对手在不断增加出价,这样,相同的投入情况下,排名降低,收入减少,利润减少。如图9。

image

图9:CPC(出价)没有太大变化,但排名却一落千丈

  可是,增加出价后,我们解决了一个问题,却带来了另外一个问题——出价增加,收入增加,同时成本也上升了。由于竞争环境的影响,要达到以前的排名,所出的价格甚至是之前价格的3、4倍。因此,虽然收入增加,但成本上升的更可怕,利润空间被压缩的非常厉害。

  由于这个商品60%的销售都是由一个最主要的词(大词)带来(这是我之前没有揭示的一个线索),也许我们可以因此得出另一个结论:大词的ROI表现日益下滑,因此或许应该拓展其他的词,例如长尾词,从其他的竞争不大的词上找机会。

  不过,从目前的情况看,这个商品的长尾词并没有多少流量,它仍然依赖于大词的表现。所以,我们认为,这个商品本身的市场环境已经发生了变化,高ROI的好日子过去了。现在的策略,是在微利的情况下生存,尽量更精细化更实时的优化,保证不亏损,并着手开发新的商品。

  或许这个SEM的例子并不是一个非常典型的例子,因为SEM的分析仍然是相对结构化和流程化的。我们通过BI的建模完全可以自动化,但如果没有好的BI系统(事实上因为百度的原因,国内的SEM是很难真正的BI化的),那么这些工作需要人来完成,需要有经验的、相当数量的人来完成。SEM是数据分析的较为特殊的类别,相对而言,其他的运营分析,则更不具有预先的结构化和流程化,例如对EDM营销(或数据库营销)的研究,需要大量的测试;对一次campaign或是promotion的销售预测,需要很有经验的分析师;或是对于商品生命周期的研究,需要精通零售的数据挖掘专家。这些都不是运营简单粗暴能够实现的。

  所以,人们渴求数据,尤其是运营部门。但人们却很容易面对数据变得焦虑和不信任。我常常会听到这样的反馈:“数据是错的!”——我相信永远没有他所希望的正确的数据。无论是数据误读,还是根本数据就是数据,从来没有转化成有价值的信息,都意味着反面的效果,甚至,还远不如根本就没有数据。

  因此,数据驱动的企业文化的要件,除了对数据有渴求,除了对数据有“使能”,还需要对数据正确的解读。

  我们需要从组织结构上保证数据能够被正确解读,或者至少是尽可能的被正确地解读。

反思:数据民主化和数据驱动型组织的架构

  一个组织的自下而上都有数据驱动的需求(上面的需求部分),而且也有决心投入资源建立数据部门(上面的使能部分),那么剩下的就是如何正确的利用数据,准确的获得信息,并以最快的速度利用在运营和执行策略上。

  在我们上面的“迷局2”和“迷局3”中,我提出了对于“集中化”数据组织的疑问。我相信这种数据组织是蕴含风险的,无论这种集中是人力资源的集中,还是数据自动化系统的集中。如果我们需要一种健康的数据驱动的企业组织,那么我们需要“数据民主化(Data Democratization)”。这个想法,来自于我之前工作的Adobe Omniture,也来自于凯文·凯利的《失控》,这些思想告诉我们,上帝创立世界,从没有让世界按照“中央控制”模式运行。自大爆炸以来(如果我们不考虑“虚时间”,那么我们可以认为大爆炸理论是合理的,当然,今天这个理论被进一步进化以帮助人们探求大爆炸之前有什么),上帝就只是给出了规则,而让万事自我发展,他并不插手。我也记得,当按照中央计划的生产和消费活动被举国执行时,只能在某些极端情况下暂时的运转良好,但当市场成为经济的核心构建的时候,一切变得自主而民主化,事情反而在混沌中有了自我秩序。image

  人体是最大的“民主化系统”。大脑的思维并不会指挥消化系统的工作,心跳的速度提升和变缓也是它自发完成的。心理学家告诉我们,大脑的主动意识甚至仅仅支配了人的行为的不到10%,潜意识却无时无刻不决定我们的行为。有些生物,例如蜜蜂,这些几乎连大脑都没有的生物却展现出高级群体特征,并通过特定手段传递相当复杂的信息(这些信息连人类都要进行复杂的描述才能实现),这些都不可能来源于一个集中化的“中央控制系统”的主动指令。

  一个组织的数据驱动类似于人的神经系统。大脑负责核心的运转(关键执行)和高级的思维(战略),各系统(消化系统、循环系统……,各经营部门)根据机体的内在和外在环境变化自主运行,形成一个反应灵敏,步调协调的统一组织。因此,数据驱动组织,不仅仅依赖于中央思考部门(数据和策略部门),同样依赖于各运营部门自身的神经单位。

  按照这样的思想,理想的数据驱动的组织分为三个层次:中央控制的战略层、拥有自己“神经”的运营层,以及实现这一切的基础设施层。

image

  与这种模式相对的模式,则是集中化的模式——高层(例如一个集中的数据部门)拥有数据,然后指挥运营层的执行。这种模式难度太高。

image

  可是我们在“迷局3”中说了,数据民主化之后,中层(运营层)如果没有数据正确解读的能力,可能比数据误读更可怕。因此,为实现数据驱动组织结构,数据民主化不仅仅只是让“数据本身”民主,也是让数据能力变得更加民主,即数据资源和数据分析资源的共同民主。

  让数据分析师回归业务部门,而不是龟缩在数据部门中。

  数据属于业务,数据分析师当然也属于业务。这是对他们最好的,也是对这个组织最好的。除此之外,还能有什么方式能够让他们发挥更大的效力呢?如下图所示,我们拆散数据部门的集中结构,让数据分析师分布到各个业务部门去。他们帮助业务部门运用数据系统、获取数据、处理数据,并与业务人员一起(结合实际业务)更直接更快捷地解读数据,并将结果直接应用于业务。这样,数据部门则只负责两块,即上面三角形结构中的最高层(竞争环境研究、全局性跨部门的策略研究、战略研究以及绩效跟踪)和最底层(数据仓库、报表和BI,以及对它们的维护)。中间的运营层面,应该是数据分析师和业务部门共同完成的。

Data-Driven-Org

  这或许是最类似于人体组织的“民主化形式”——我们的大脑不是神经系统系统中唯一的器官,而能够进行“思考”的器官,也绝不仅仅只是大脑。

结论

  我有些偏执的相信,数据驱动型的组织一定不是人们主观期望它实现就能实现的。这个组织需要自下而上的需求,尤其是那些真正干活的人,他们对于数据的需求,决定了这个组织数据文化的根基。如果他们确实有需求,那么我们应该确保这个公司有数据的输出和处理,以及确保对于数据的处理(解读)是正确的,且能够最快速度的直接应用于业务的需求。

  我相信,自上而下并非数据驱动组织形成的要件。或者,更偏激点,数据驱动组织不是CEO或者董事会希望它能够实现就能够实现的。这其中一定包含历史原因、政治阻力以及人本身的情况。而人本身的情况,才是数据文化的核心,哦,不,应该说,是一切文化的核心。

题外

  在圣诞季以及过年期间,我关闭了博客的评论系统,因为每天有数以百计甚至千计的垃圾回复。今天我重新打开这个功能。希望大家畅所欲言。最后,祝大家龙年大吉!身体健康,合家幸福!

20 Comments »

  • Will Lin said:

    当有权力调动资源的管理者自己懂得解读关键数据,业务部门懂得从哪里要数据和讨论时能交流各种来源的数据,技术部门能主动沟通哪些数据可以用什么方式获得时。而不只是追求有漂亮图表的日报,周报,月报时。这才算是一个数据驱动的组织吧。

  • Todid said:

    春节也发文章?楼主强大!

  • joegh said:

    <p>Sidney说得太好了,深有感触呀!
    <p>数据驱动的发起依赖高层的重视,数据部门的实施,但真正成功与否的关键在于中下层甚至整个公司全体,所以"数据驱动"被认为是一种企业文化。数据的应用在于业务部门的数据理解和掌控力,所以非常认同数据分析师跟进到业务部门,矩阵式的组织架构比较合适数据部门,纵向是数据获取和分析,横向是业务需求和数据应用。

  • abbo said:

    文章从数据与组织构成、数据部门在企业、数据部门自身问题依次谈了数据驱动及一些想法。按我拙见,所谓数据驱动即为一种思想,分析思考解决问题流程更多依据数据来说话。文中谈到神话般的BI系统其实也可以理解,事实上都是一种对企业架构的信息化,来提高组织效率,名字叫什么无所谓,目的要明确。所谓商业智能,我比较赞成这样一种说法:业务辅助(业务部门熟练使用Excel等都是),流程优化(根据现有流程,以信息化手段合理优化,有能力可以适度开发工具固化简化一些流程),决策支持(老板看分析结果做决策,中层适当选择,底层最好是简单的执行与否)…太多问题需要解决,电商互联网肯定是走在商业智能,数据分析驱动的先列,与君共勉。

  • 生姜 said:

    其实对数据驱动型电商来说,高层的影响是很重要的——他们的重要性并非体现在英明睿智的指挥中层和基层做什么以及如何做,而是:
    1. 别瞎指挥,做好自己该做的事。各位老大已经离实际业务很远了,别以为自己聪明到可以随时给运营层面支招的程度。高层要做的事是把控并及时调整战略,以确保组织资源投向(尽可能)正确的方向;确立并优化组织结构以使各部门的利益与组织战略目标一致,通过制度和机制来减少内耗;招募、甄别、奖励合适的中层员工,了解他们工作中所需要的支持,并尽可能给到他们支持。
    2. 在尊重数据的同时怀疑数据。要明白:对一个事情往往要通过多个角度、多个指标综合来看,才能大致搞清事实是怎样,少犯盲人摸象里边瞎子们的错误,这类错误往往会导致上述第一条“瞎指挥”的发生。
    3. 在做到以上两点的基础上,倡导、鼓励数据化运营,并给下属试错乃至犯错的机会。
    —————————————————————————————-
    高层如果没能把这些基本而重要的事情做好,创造好实施数据化运营的大环境,中层即使想做真正科学的数据化运营,往往也会被不断打扰,很难持续坚持地做下去。

  • 生姜 said:

    再说说Sidney文章中的一小点——将数据分析人员分布到业务部门中去。
    这点原则上是同意的。事实上年末我们就拉了一个数据分析部的高手到我们部门共同做一个数据分析项目,效果非常之好。
    只是这里边要注意的是:业务部门的分析需求不能太过随意。不能今天要一张报表、明天要一张报表,而这些报表往往用过一次之好就无人问津,浪费了数据分析部门宝贵的人力资源。
    但也不宜按Sidney 文章中所说的“只承担提供基础数据的工作,但他们没有职责,也不应该为业务层面提供战术性的分析”,具体业务报表让业务部门人员自己出。要知道,业务部门的同事对报表工具的掌握水平往往比较低,数据分析同事半小时就可以完成的报表,业务部门的同事经常要搞个大半天。尽管可以通过培训提高业务部门的数据分析工具掌握能力,但毕竟术业有专攻,业务部门做报表的相对效率还是不高的。
     
    我们年末这次数据分析项目的做法是:由业务部门一名懂业务也了解基本数据分析概念的同事,与数据分析部门一名专业能力强、同时愿意认真理解业务的同事对接,确定指标及报表格式,再做出样表,将样表发其他业务部门同事讨论其可用性,确认后做出整套报表。业务部门的同事再根据报表中与自己相关的数据,做出分析、判断和策略规划。
     
    我是业务部门的,所以我一直的看法是,业务部门的同事不应该把时间花在做报表上,而应该基于那些全面的、高可用性的报表(不知道这是否就是actionable insight的概念)做分析、判断、规划、执行和改善。

  • cnukaus said:

    你的图7 图8,粗看上去关键词和收入是反比的关系啊?坐标轴太误导了。。能否把顺序改过来,1在上
     

  • seo said:

    谢谢宋星的分享,学习了。

  • Sidney Song (author) said:

    回复:cnukaus

    谢谢您的意见。排名的表示方法是Google AdWords的,这里只是沿用。我猜直接操作SEM的朋友可能对此习惯。

  • Sidney Song (author) said:

    回复:生姜:

    生姜同学说的太好了。如下回复说到我心坎上了。重复如下:

    只是这里边要注意的是:业务部门的分析需求不能太过随意。不能今天要一张报表、明天要一张报表,而这些报表往往用过一次之好就无人问津,浪费了数据分析部门宝贵的人力资源。

    但也不宜按Sidney 文章中所说的“只承担提供基础数据的工作,但他们没有职责,也不应该为业务层面提供战术性的分析”,具体业务报表让业务部门人员自己出。要知道,业务部门的同事对报表工具的掌握水平往往比较低,数据分析同事半小时就可以完成的报表,业务部门的同事经常要搞个大半天。尽管可以通过培训提高业务部门的数据分析工具掌握能力,但毕竟术业有专攻,业务部门做报表的相对效率还是不高的。

  • 小强 said:

    感触很深!尤其是第一部分。
    我也很赞同自下而上的方式,自上而下的东西很少不变质!

  • 站翼 said:

    企业管理,是一项很高深的艺术,不同的管理方式都会有自己优点和缺点呢!数据驱动,首先要塑造重视数据的企业文化,从下而上的数据分析,能让数据作用最大化,执行的更加完美. 

  • 楠楠-Cady said:

    这篇文章真是太棒了,让我醍醐灌顶,我目前正处于“经典数据组织架构——hub模式”中,感觉疲于应对
    sindey提出的三层结构,“中央控制的战略层、拥有自己“神经”的运营层,以及实现这一切的基础设施层”的模式值得尝试
    非常感谢sidney的文章

  • 晓东 said:

    佩服宋星能写这么长帖子的耐心和布道精神。也佩服自己,一口气读完。
    随便说两句:
    1、宋星是值得尊敬的科学家,有这么好的科学家的组织是值得尊敬和幸运的。但商业组织里最好的内部资源,往往掌握在那些内部流氓的手里。所以,要资源就要会一点武术。这篇帖子我读到的有那么点悲催的地方,我个人觉得是因为科学家还不太会武术。
    2、武术指:仗义的能力;讲故事的能力;标准化的能力;
    2.1、仗义是一种味道。组织都是由人构成的,光有纯数学化的因为所以没太大用处,要有人情味在里面,而仗义是被普遍喜欢的一种人情味道。仗义就是有难同当有福同享,但更牛逼一点的仗义是我做决策,结果大家同享同当。很有意思的一种现象是:有没有足够多的资源愿意和你一起同享同当结果,决定了你能做多少决策。
    2.2、讲故事的能力就是上面很多朋友说的获取支持的能力。这同样是一种非数学化的能力。亚里士多德也说过所谓说服,是逻辑情感信任三者的组合,缺一不可。其实我一直觉得,数据分析能力强悍的人如果愿意讲故事,这个故事会非常非常精彩而且充满力量,这不是什么坏事情。可惜大多数科学家都是严谨的,他们不愿意站在未来看今天,讲那些以终为始的故事,而且一讲故事就心虚,一心虚就磕巴。
    2.3、标准化的能力,个人认为这个最重要了。标准化就是解放军踢正步。你说正步要怎么踢才好看?其实怎么踢都TMD不好看。但是1000个人按照一个姿势一个频率踢,怎么都好看。一起往地上打滚估计也很震撼。标准是个动作的框架,很多人一起做这个动作就是标准化。有时候,思维和行动一样也是需要并可以做到标准化的,尤其是大组织N多团队协同的时候。标准化,其实可能是一个商业组织中最完美的,最自由的一种艺术。而一旦有了标准化的作业流程和责任矩阵,所谓的发散的,主观的浪漫主义色彩就会弱很多了。
    3、文章快看完看到这句:数据分析师应该去业务部门。如果是流氓们来写这篇文章,这句话会放到第一句。我想。
    PS:这个回复写完了给朋友看了看,朋友问我是个流氓还是科学家,哈哈……真诚祝愿宋星兄弟成为一个会武术的科学家!尤其是在已经离开了实验室之后!

  • bobo said:

    cnukaus:图7、图8关键词的排名是序数,数值越大表示排名越靠后.

  • Nick Hu said:

    1) 数据部门成立的原因
    互联网日新月异,大环境,竞争对手,市场需求变化很快,于是需要有这样的一个部门-数据部门来为CEO们提供数据,方便通过数据的得到insights(认知),从而掌控方向。
    2) 集中化的数据部门
    集中化后,数据组门的专业能力会有大幅度的提高,但硬伤则是远离业务部门,疲于数据处理和运算,很难做出深刻的分析。
     
    3)民主化的数据分析
    能够以业务为出发点,做出非常切合实际的报表和分析,解决业务部门的难题,但是久而久之,人员的能力则很长时间都会停留在某一个水平,不能得到提高,或者说提高的速度非常缓慢。
     
    理想建议:数据部门定期抽取人员下放到业务部门,解决业务问题,这个期间,其他的数据需求全部不用他干,解决后,将业务与数据分析的知识待会到数据部门,并且进行分享,然后进行相关业务的数据建模。但让这种下放不能拘泥于某一个人,如果老是某一个人,那么这个人的数据分析专业能力就会低于数据部门的平均水平,还是应该定期回炉,接受专业的培训。(PS:如果组织内数据分析人员稀缺,不太可能实现)

  • 晓星726 said:

    数据只是客观问题和客观状态的显示,将数据拆接到相关部门甚至直达个人然后通过流程和规则整合资源推进项目或者公司的运作,再加上人性化的沟通和管理。这就是运营的艺术了!不错不错!小小年纪就能有这样的参悟力,看好你+1!

  • chrisy said:

    我们现在采用的架构就是这个三层架构,因为集中管理的数据分析根本无法代替业务自己的分析,通过日常固化的报表为业务提供快速的分析数据(流量、转化、活动效果等),由业务部门自己开展日常分析,但业务部门比较分散,需求零散,由数据分析部门根据业务需求进行数据仓库的规划和实施,并推动帮助业务开展精准营销和数据分析,由简单到复杂,BI的应用其实未必要很复杂的模型或算法,能够快速帮助业务分析、销售和优化才是最重要的。
    但由业务会比较着眼于短期KPI,推动BI的应用也应该是数据分析部门的职责,需要一个长期分析和优化的过程
    PS,个人觉得,对于业务所处的不同阶段,数据分析部门的职能和架构应该会有差别,业务开展初期提供快速数据是最重要的,有一定规模之后,数据分析部门不仅需要的是快速提供数据,而要能够具有分析和BI能力,并主动的了解业务和开展分析应用。

  • zbzdm said:

    知识有点点深,得好好消化一下。anyway,写得不错。

  • Roy said:

    开始考虑分析系统和制度的问题~楼主考虑问题越来越有高度了~

Leave your response!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

Be nice. Keep it clean. Stay on topic. No spam.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <font color="" face="" size=""> <span style="">

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.

备案/许可证编号为: 京ICP备09063066号

Coupons and Deals, CheaperSeeker Coupons and Deals, Sharkcoupons