（中国移动/宁宇）
什么是经营分析系统？
作为中国移动经营分析系统的创始者，我问出了这样的问题，不是因为失忆，而是觉得在这个时候需要对经营分析系统进行再认识。
中国移动的经营分析系统是2003年开始建设的，关于经营分析系统的前生今世，我在之前的《对于当前经营分析系统的理解》系列中写过了，有兴趣的读者可以参阅一下去年7月份写的那五篇。有趣的是，当我刚才寻找以前文章的链接时才注意到，每篇文章都有上百的阅读量，但却鲜有评论者，毕竟业务支撑是电信和IT 行业中的小专业，所以比起炒得热火朝天的漫游费，受关注的程度差远了。
扯远了，再扯回来。对于经营分析系统，有两种理解。其一，是满足经营分析需求的系统；其二，是中国移动的数据仓库系统。
2003年的时候，竞争还处在粗放阶段，市场竞争激烈程度比现在差远了，因此对于经营分析的需求并不丰富。这个时候建“经营分析系统”，规划驱动的成分更多些，借助业务部门呼吁的“经营分析需求”，建的其实是数据仓库，为今后的竞争储备系统、数据和人才，同时摸索经营分析的发展方向。因此2003年的时候建的经营分析系统是按照第二种理解做的。
国外的经营分析是BI（商业智能）系统的一类，属于第一种理解方式的产物——面向具体的商业智能应用，通过IT技术和手段，实现对于某种经营分析功能和能力，满足运营商在这方面的需求。如同其他的IT系统发展规律，BI系统最初是满足具体需求的小系统，一个系统完成一个或一组特定的功能，所以经营分析系统定位在实现经营分析需求（就是第一种理解）时，那么它更类似于一个外挂系统，以实现特定需求为目的。这样的外挂系统效率高，但是当多了的时候，维护、边界、整合等问题就出来了，因此要进行IT整合，将系统按照专业化的方式进行分类，形成了操作型系统和分析型系统。
对于中国移动来说，目前的操作型系统主要有已建成的BOSS和即将建设的CRM；而数据仓库加各种分析应用则属于分析型系统。为什么当时建经营分析系统的时候选择了第二种理解，我之前的博客说得很清楚：一是应该建设数据仓库系统，而按照运营商的工程建设模式，必须有业务驱动才能建系统，所以借用了经营分析的名义来建数据仓库；二是当时业务部门对经营分析的需求还比较初级，如果只是将业务部门的零散需求作为系统建设驱动，是难以形成完整的IT支撑系统的。
但是现在不同了，业务部门对于经营分析的需求逐步被培养和激发了出来，面向分析的需求越来越多，经营分析、商业智能的需求逐渐成熟，这时候，分歧就出现在了BOSS和经营分析系统，或者说分析型系统与操作型系统的边界上。换句话讲，如果经营分析系统的定位是数据仓库系统，那么它和BOSS等操作型系统的关系是非常清晰的，一个是OLAP，一个是OLTP，系统各自发挥自己的技术特点，形成完整的业务支撑能力。但是，如果经营分析系统的定位是满足经营分析的需求，那么它和BOSS的关系就说不清了，因为如果将经营分析的需求进行分解，我们就会发现，其中一些功能在BOSS上开发更合理，成本更低，效果更好。
说来说去，恐怕又有不少人看晕了，不过我倒是希望一些厂商看明白，不要自己和自己打架。经营分析系统和BOSS、CRM等系统是平行的、共存的、互补的业务支撑系统，他们组合在一起之后，去支持经营分析、业务开发、CRM的需求，CRM和经营分析一样，既可以是系统的名字，又可以是需求的类别，但是满足经营分析需求的系统不是只靠经营分析系统，满足CRM需求的系统也不是只有CRM，就如同漫游费和漫游发生的费用是两个完全不同的概念，做规划的人自己要想清楚，千万别把人往沟里带。