早在十几年前，中国移动就着手建设了以数据仓库技术为核心的经营分析系统。这几年大数据的话题非常火爆，业界也非常关注运营商在大数据领域的探索和实践。今年5.17"世界电信与信息社会日"的主题确定为"发展大数据，扩大影响力（Big Data for Big Impact）"，所以启动一个新的连载，说说我对这方面的理解。
第一部分：报表的名义。
2001年年初，中国移动启动了BOSS省级系统集中化改造，经过几个月的努力，集团公司发布了BOSS1.0的业务规范和技术规范，之后就游说各省立项实施。
这是一项非常艰苦的工作，当时很多省公司并没有意识到，省级集中化的BOSS系统对企业经营管理以及业务拓展等方面都有很大好处，所以建设意愿并不强烈；而由总部的"业务支撑中心"（后来更名为业务支撑系统部）来推动此事，对省公司的压力和控制力也不强。所以足足花了半年时间，才有几个省动了起来。
看到BOSS建设终于开工了，总部的业务支撑中心立即启动了经营分析系统的规范编制工作。在生产系统之外建设数据仓库，当时我们理解这是海外运营商的普遍做法，后来才知道，这是相关厂商的片面宣传。
对于业务支撑部门来说，除了常规性的计费、结算、出账等工作之外，生产任务还包括输出各种类型的统计报表，此外还有很多临时的统计需求。比如某个领导要见国际友人了，需要统计一下这个国家和中国的通信业务往来情况，这就需要自己编段程序，在系统中跑一遍数据，不仅要花很长时间（几个小时甚至几天），还会对正常的生产有影响。所以报表，尤其是临时性的统计报表，是上个世纪IT人员的噩梦。
如果有一套数据仓库系统专门进行多维的数据统计和分析，会很大程度上减轻生产的负荷压力。但是数据仓库投资巨大，不能说业务目标只为解决报表问题啊！好在相关厂商提供了很多案例，尤其是沃尔玛那个啤酒和尿布的案例通俗易懂，让很多客户对数据挖掘充满了期待。
理想很丰满，现实很骨感。中国移动编写数据仓库规范的消息传出来之后，各类厂商趋之若鹜，都说自己是做数据仓库的，都说自己能实现啤酒和尿布的分析，但几次细聊之后，发现完全不是那么回事。
来的最多的，是数据仓库的工具类厂商，这里既有原厂商，也有各种代理。而且工具种类繁多，有做数据ETL（清洗加载转换）的，有做元数据管理的，有做报表展示的，还有做算法和分析挖掘工具的。大概过了一个多月，我们才渐渐把这些分类整明白，同时也意识到，这些都是辅助性工具，核心问题还是要搭建数据库。
当时核心数据库的技术选择本质是两大数据仓库建设流派的碰撞。一类是以IBM、ORACLE为代表的，倾向于从应用出发，通过小规模数据的聚合来解决具体问题，再逐步扩大规模，最终形成企业级数据仓库。另一类是以Teradata为代表，强调基于所有数据构建完整的数据仓库，再根据需求去开发应用。
当时中国的移动通信市场是绝对的卖方主导，只要网络能力建成，号码资源到位，用户就大量涌入，相对而言，精细化管理和分析的需求并不旺盛。而BOSS系统建成后，会有大量的客户资料、通话和行为数据产生，如果这些宝贵的资源没有积累沉淀下来，就太可惜了。所以尽管那时IBM和ORACLE在电信市场方面的营销推广和客户关系能力都比Teradata强，但基于当时的情况，最终我们还是选择了重数据轻应用的路线。
经营分析系统最初的规范是什么时候写的，我自诩记性好，对这事却恍惚了。2001年初（2月19号——4月29号）我组织写BOSS规范，然后就去各省推动BOSS建设，然后再几乎是从零开始学习数据仓库，这些都没错。可是我电脑里经营分析系统规范文档的时间戳是2001年10月，到底我们是在什么时间做完了这个里程碑性质的规范文档？难道2001年做了那么多不可思议的事情？
在经营分析系统1.0的规范里，赫然写着这么几个关键点：
第一，本规范的适用范围是省级经营分析系统，集团级的经营分析系统建设工作不包含在内。在这一系列文章后面的内容里，将详细阐释集团和省级经营分析系统的业务目标、设计思想，以及这种设计的原因。
第二，在数据访问和应用方面，考虑到当时的技术条件和需求成熟度，规范里虽然提到了OLAP和数据挖掘，但强调近期以OLAP为主。在我理解，数据挖掘就像淘金，投入了资源但未必有结果；而在数据仓库起步阶段，这种投入往往难以有足够的产出。
所以，当经营分析系统1.0建成的时候，最普遍的应用还是以报表，看不到什么高大上的高科技，为此经分系统也被戏称为"昂贵的报表系统"；但经分系统在数据统计方面承担起主要工作，对生产系统的减负发挥了重要价值，这并不是多少人能意识到的。
总结一下：立足于当时的技术条件和业务需求成熟度，再加上合作伙伴等多方面的扰动因素，经营分析系统1.0规范的编制主要聚焦在多维分析报表方面。如今看起来可能觉得这样的系统很"土"，技术的选择和方案不漂亮，但只要大方向判断准确，在正确的时间点上出台规范启动建设，这才是最关键的。
