量化管理是指以数字为基础,用数学的方法来考察和研究事物的运动状态和性能,以求对事物存在和发展的规模、程度等做出精确的数字描述和科学控制,实行标准化操作的管理模式。本书中的Metrics作为“以求对事物存在和发展的规模、程度等做出精确的数字描述”的工具出现,是一种为改善某种东西对其进行详细描述的手段,用来支持决策,帮助改善组织、提升绩效。

数据仓库的概念植根于信息技术,由比尔•恩门(Bill Inmon)在1991年出版的《建立数据仓库》(Building the Data Warehouse)一书中提出。其最初的定义是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策。构建数据仓库考虑的也大多是信息技术问题,比如数据生命周期、元数据、数据质量,以及ODS(操作数据存储)、ETL(抽取—转换—装载)。当然也有根据业务需求确定的主题域、信息、指标以及数据集市。但在构建数据仓库的知识体系中,对数据集市、主题域、信息和指标的论述,一般都局限在软件行业的需求调研方法以及数据建模,属于业务知识体系向信息技术体系的转换过渡方法。但如何提炼出一个组织的量化信息需求,确立业务知识体系,或者说如何进行描述,我在看到这本书之前,还没见过一种能把这个过程解释清楚的方法。

随着大数据概念的提出,各种IT技术也应运而生,比如Hadoop生态体系对MapReduce概念的开源实现,用于统计分析的R语言,MPP架构的数据分析处理平台,甚至号称处理速度无与伦比的内存数据库。厂商们都在狂热地鼓吹自己的产品可以更快速、更有效地处理堆积如山的数据,从数据中淘金,把数据变成信息,用信息构成知识。虽然决策支持、数据挖掘和数据分析喊了很多年,但直到最近,这些高级系统仍然停留在电信、金融和零售业(电子商务)等几个领域。虽然越来越多的管理者看到了BI(BA)的力量,但对于如何掌握这种力量,还是丈二和尚摸不着头脑。甚至在BI得到成功应用的领域,也有点儿摸着石头过河的感觉。项目团队经常承受着很大的压力,不知道怎么找出客户自己也不知道是什么的需求。

我曾参与过一个BI项目。这个项目的缘起,是因为公司在另一个行业BI项目上的成功。客户算是慕名而来,按他们的理解,我们的经验是可以套用到他们那个行业上的。你会在本书中看到,这是一个错误,而且是大家都会犯的错误。作者还专门为此编了一个悲剧版王子的小故事。灰姑娘留下了一双鞋,可王子没能找到红颜,所以冲冠一怒,颁布了一条触怒天下的法令,最终导致王国被颠覆。虽然我们没有王子那么悲惨,却也在跟客户磨合的过程中承受了很多痛苦。最初,我们向客户介绍各种主流的BI生态系产品,介绍各种数据分析算法,提供了整套的BI项目实施文档模板,确定了一部分主题域和指标体系,甚至还根据客户提供的测试数据训练了一个神经网络模型用于客户分群。但我们很长时间也没能给出客户想要的描述。客户和我们都很痛苦。因为从一开始,我们就没有确定根本问题,像作者说的,发动引擎开始了一段不知道要去哪儿的旅行。由于我们对新行业缺乏了解,也没有答案纲要的指导,不知道怎么帮客户确定根本问题,甚至也不知道让客户找出自己的根本问题。我们虽然知道怎么按客户已有的数据结构搭建数据仓库模型,知道怎么实现ETL,知道怎么保证数据质量,知道怎么做数据分析,知道怎么展现分析结果,但我们不知道怎么向客户做一个完整的描述。所以在那个项目中,我们消耗了很多时间来寻找向客户描述的方法。好在我遇到了这本书,它帮助了我,所以我希望它也能帮助曾经和我一样痛苦挣扎过的人。

“量化分析”的含义要比统计分析丰富得多,但在某些方面又不如统计分析。这本书中没有关联分析、回归分析,更别提决策树和神经网络了。也没有维度和雪花模型,没有SQL语句,没有R语言。但我希望所有数据分析师或准备做数据分析的人都能读一读这本书,如果把数据分析、数据挖掘和数据仓库建模当作术,那么这本书中讲的内容就是道,是内功心法。虽然它不能帮你解决掉SQL中的某个bug,不能告诉你怎么把数据画成一幅南丁格尔玫瑰图,但它可以帮你架起数据仓库到量化管理的桥梁,让你的技术能为业务服务。

感谢图灵给我翻译本书的机会,感谢傅志红老师在我翻译初期的悉心指导和耐心解释,感谢编辑朱巍、楼伟珊和张霞对本书认真负责的审校和中肯的修改建议,使得本书最终不至于语句不通,惨不忍睹。他们的认真和敬业令人钦佩!

还要感谢我的同事们,他们和我一起经历了项目的煎熬,一起和客户交流。他们教会了我很多数据仓库方面的知识,在我的翻译工作中也提供了很多帮助和支持。最后感谢我的母亲和妻子。她们承担了家里的大部分工作,如果没有她们的理解和支持,我不可能每天抽出那么多时间来完成本书的翻译工作。