1704272320
1704272321
技术成熟度曲线（Hype-Cycling）
1704272322
1704272323
信息技术总是“说大话”，承诺很多事情，就好像这些事情在短时间内都会实现一样。这种现象由来已久，是老生常谈，老得就跟第一台计算机一样。这种现象强烈地影响了IT产业从业人员的心态，也逐渐影响了美国IT行业的特质。所有新科技好像就没有不重要的，研发者和销售人员都觉得是颠覆性的创新研发。这种情况有时令我们也很抓狂，事情总是这样，肯定是不行的。
1704272324
1704272325
信息技术总是“说大话”，承诺很多事情，就好像这些事情在短时间内都会实现一样。这种现象由来已久，是老生常谈，老得就跟第一台计算机一样。
1704272326
1704272327
鼓吹信息技术进步的言论是对一种理念坚信不疑的反映，即从长远看，创新技术肯定会得到应用，在一定时期之后，个人、社会组织及企业事实上也会消费创新技术，届时，那些从一开始就对技术创新抱有（过于）积极的态度的主体就会受益。早在20年前（第一个浏览器刚刚使普通人浏览网页成为可能），软件分析师杰姬·芬恩（Jackie Fenn）就提出了一个了不起的、结论性的分析框架，即高德纳公司的技术成熟度曲线分析。
1704272328
1704272329
1704272330
1704272331
1704272332
许多本书的读者对这个曲线并不陌生。用物理学家的话描述这个曲线就是，具有指数特性特征的一条光滑曲线在经历了一个飞跃式上涨的波峰之后，逐步接近一个有走高趋势的平衡位置。如果是在经济领域，这条曲线表示，从指数上看，经过市场上的大肆渲染和宣传，新信息技术首先将经历不断提高的市场关注度。与此同时，对新IT产品的期望值也逐步攀升，但是这些尚不成熟的产品在1.0版时是不可能满足这些期望的。从某种程度上来说，这种期望后产生的失望是意料之中的。如果这些新产品生产企业掌握信息技术资源，很快他们就会推出优化后的2.0版本。
1704272333
1704272334
这些新版本可以实现人们意想不到的优化，比如可以治愈儿童疾病，或是增加了新功能。在这个阶段，对新产品的公众关注度明显降低，人们会更切合实际地去衡量这些新产品的市场潜力和技术局限性。（能够经受住市场检验的）成功的信息技术而后会达到“实际生产高峰期”阶段。此时，消费者知道自己想要什么，他们也非常清楚，这些新产品虽然已经不是最受追捧的了，但是这些新产品基本成熟的功能会使他们所在的机构或组织受益。
1704272335
1704272336
有很多新技术、新产品在跌入谷底之后，就不了了之了，市场低谷成了死亡之谷。
1704272337
1704272338
2011年，大数据作为类概念第一次出现在高德纳年度技术成熟度曲线报告中，在随后的2013年，大数据达到了曲线期望值的顶峰（达到“过高期望的峰值”阶段）。2014年，大数据以“坐过山车”的速度冲向市场关注度的低谷，预计2015年将继续加速向谷底俯冲。[1]这些只是预测层面的，不可回避的是，像施皮格哈尔特这类对大数据持批判态度的顶尖专家绝不会就此认定，大数据会朝着曲线上“实际生产高峰期”方向发展。这是因为，技术成熟度曲线毕竟不是统计分析方面的“再保险曲线图”（具有极高的预测准确度），不是所有时髦的新信息技术都会像技术成熟度曲线预测的那样，在经历了比较长的时间之后，会获得市场的认可。出于回顾验证预测结果的目的，高德纳的分析师们特意关注了一些已经上市的新产品的市场表现，结果发现有很多新技术、新产品在跌入谷底后，就不了了之了，市场低谷成了死亡之谷。
1704272339
1704272340
大数据这个概念的表述还是太模糊，涵盖了许多不同的产品和应用实例，在战略和实操决策层面都引起了一定程度的困惑。没有人能说清楚，在未来的5~10年，我们在企业经营中会用到哪些大数据分析方法。我们也不知道，到那时，我们使用哪些被大肆宣传的“秘密武器”时，会让我们不止一次地回想起“大数据”这个名词。此处有两个原因，一是大数据这个概念中的“大”不能用数量来衡量，二是对于多少数据量是容易或者不容易被运用的，判断过于主观。对有些企业来说，几Pb（10的15次方字节）的数据量就大得不可想象了，对另一些企业来说，处理Eb级的数据量（10的18次方字节）都很轻松。从我们在大数据的大部分商业应用领域的经验来看，企业能够处理的数据量的多寡，在决定某个企业能否达到“实际生产高峰期”阶段方面，是最不关键的因素。后续我们会对此进行更详细的分析，此时，我们大胆预测，在一段或长或短的时间之后，大数据这个概念在企业中将不仅仅作为一个高高在上的抽象化概念存在。
1704272341
1704272342
没有“大爆炸”的大数据
1704272343
1704272344
去年，我们从大企业和较大的中小企业的数据项目中获得了一些经验，在整合这些经验时，我们发现，在对大数据的认识和态度方面，存在如下自相矛盾的现象：
1704272345
1704272346
决策层越高，就越会涉及大数据这一概念，同时对大数据的期望值也越高。如果此时，首席执行官、董事或者战略决策部门还没有深入了解在他们的业务领域面临的最重要的数字化挑战是什么，他们对大数据的期望值还会更高。简而言之就是：
1704272347
1704272348
越是没有大数据应用经验，对大数据应用于企业管理的期望值就会越高，越会希望通过大数据的应用获得“多快好省”的收益。
1704272349
1704272350
这些期望主要是集中在能够借助大数据发掘出企业尚未涉足过的、全新的商业模式上。这种期望会在各种媒体报道的影响下越发强烈。比如媒体会报道：
1704272351
1704272352
1.早在客户意识到他们自己是多么迫切需要某样商品前，亚马逊就已经开始出售这些日常商品了。
1704272353
1704272354
2.由于有一定的大数据意识，在线影片租赁提供商网飞（Netflix）对那些观看连续剧成瘾的用户的欣赏偏好非常了解，网飞自己制作电视剧并且进行恰当的销售，例如凯文·史派西主演的《纸牌屋》。
1704272355
1704272356
3.未来汽车保险公司借助于全球定位系统数据，在“按里程付费模型”框架内核算出了保费收费标准，从而可以提供极具市场竞争力的优惠保险产品。
1704272357
1704272358
具体的表象往往还没有形成，例如这些基础性的经济领域技术创新在个别企业内是如何呈现的，等等。但是对大数据的基本态度已有定论，即数据为我们指明了方向。这不仅仅是效率的问题，还有实惠，因为现在信息技术的使用成本极低。这一点在去年与大数据相关的演讲中可以看出来。
1704272359
1704272360
另一方面，我们认识到，决策层级越低，大数据带来的失望情绪就越大，但是这种情绪多多少少都有所隐藏。这种情绪上的对立有多种原因。一方面，IT部门往往已经制定了工作方案，使企业可以更加有效地使用数据，但是方案在企业内部并未得到响应和贯彻。另一方面，如果公司将信息技术问题作为基础性工作来抓，那么原本相安无事的技术部门将陡然变为众矢之的，对于这一点，公司信息技术操作层面的负责人原则上是十分清楚的。随着信息技术的进步，IT部门意外地发现自己变成了影响公司决策的强有力的“刹车器”。在这方面，IT部门常用的话术是：“我们的系统不支持这个功能。”从IT部门的角度看，他们（这样说了以后）往往会是幸运的，不用再去为了公司的数字化快速发展做更多辛苦的努力，因为上层决策者往往会关注大数据应用所需的短期的、实际的、可预期的投入，有时对投入关注得越多，继续投入资源的热情便会有所减弱。当上层决策者们慢慢意识到，在他们的企业内必须进行哪些深入的改变，才可以借助数字化长效地发掘公司真正的市场潜力时，决策者们才会慢慢改变内心的抵触情绪，逐渐厘清认识。这里指的当然是，发掘自己公司的市场潜力，而不是别人的。
1704272361
1704272362
在一些大数据概念相对模糊的公司，常出现如下问题：决策层认识到了大数据分析是发掘新商业模式的一种可尝试的途径，同时他们对此寄予厚望。在项目中，他们很快意识到，数据确实是一种资源，可以在短期内，沿着企业本身的价值链——从组织生产、供应商管理、后勤保障、销售运营直到客户售后服务——去优化企业的核心业务。而后，人们不可避免地会将大数据的应用潜力与商业模式的持续优化联系起来。在排除其他并行的商业模式优化因素的情况下，人们尝试着去预估数据带来纯增量的潜力，结果是，在节省资源和增加销售额或者利润方面，大数据带来的纯贡献值是低于预期的。故而人们对没有带来惊喜的大数据就不再有兴趣了。
1704272363
1704272364
一次对企业影响深远的、致力于寻求数据驱动下优化解决方案的尝试，迅速将各种有经验的、熟悉企业文化的“反对者”引向了“雷区”：
1704272365
1704272366
1.必须开放数据库。通过利用运营数据，企业的业绩可能提升，但也可能降低。但遗憾的是，部门主管们对此持有很矛盾的心态，他们遵循的行为原则是，如果我从数据中获益则没问题，但是如果我没有获益，则无法接受。
1704272367
1704272368
2.数据技术的“恶魔”通常存在于细节中。小问题总是能演变成大问题，进而导致IT投入（尽管有IT行业的各种美好承诺）经常一路飙高，就如同柏林机场和易北河音乐厅在筹建时不断增加的预算一样。哪些处于职业上升期的领导会去冒这种风险？此外，让事情变得更困难的是，因为从商业角度出发数据应用似乎是值得期待的，故而数据库的经营管理人员的职权越来越大。在一个公司里，如果想投产一个创新性的客户数据应用，就需要对SQL（结构化查询语言）代码进行修改。谁能够估计出为此修改5000行SQL代码究竟有多复杂？肯定是实际操作修改的人。
1704272369