前言

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

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

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

正文

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

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

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

我们怎么样才能真正建立起称得上“数据驱动”四个金字的电子商务组织？为什么数据驱动的组织那么困难？这个问题困扰了我很久，我几次演讲，有被听众问到这个问题，我都觉得没有给出很好的回答。今天，我想要解决这个问题。

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

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

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

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

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

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

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

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

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

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

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

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

迷局2：使能（enable）的误区

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

仍然很难。

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

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

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

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

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

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

显然，这个方法能够让CEO或者管理层非常牢固的控制数据。数据比较安全——至少看上去是那样。

数据部门可以集中起来工作，这似乎对做数据的同事是不错的一点。

节省人力，组织看起来规划清晰。不用在各处安插做数据做分析的人，确实省下一大笔人力和管理成本。

相对简单的数据系统。因为数据部门管理数据，诸如权限之类的系统设计，可能就不是那么重要了，反正人来提供数据报表即可。该给哪些部门，不给哪些部门，人工去每次划分确定就好了。数据的模型——也没那么重要，人去分析就行了，不需要太高的自动化，也不需要太强大的BI。

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

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

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

例如，想要知道一个网站的流量并不复杂，有太多的工具，免费的，付费的，还可以用我之前的一篇博客文章：《如何获知陌生网站的流量？》。

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

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

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

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

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

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

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

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

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

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

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

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

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

这个方式，就是BI系统。

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

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

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

例如下面的这个例子：

对于下面两个图的数据实际上是完全一样的，可是，两个图给你的心理上的感觉却是完全不同的。
数据驱动的互联网业务组织架构的迷局和反思

图3：利润趋势（1）

图4：利润趋势（2）

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

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

图5：利润和收入趋势

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

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

来看另一个真实的例子。

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

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

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

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

很快，他们找到了一个相当有说服力的数据关系：当SEM关键词的平均排名下降了之后，销售收入也非常明显的下滑。如图7所示。
数据驱动的互联网业务组织架构的迷局和反思

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

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

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

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

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

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

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

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

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

图9：CPC（出价）没有太大变化，但排名却一落千丈

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

结论

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

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