我这人最不禁忽悠，本来已经没有什么要说的了，被人一激，就写个四吧。那么主题呢？说说经营分析系统的厂商吧。

    前面说了，在移动的经营分析系统里面，数据仓库、BI、CRM等等概念搅和在一起，本来就够晕了，每个概念和系统里又有不同的厂商和利益团体，就更使这个系统是雾里看花。我不能说已经看得清清楚楚明明白白真真切切，只是说说自己的理解。

    数据仓库由不同的模块构成，与BOSS不一样，这个系统的集成者其实不是SI，而是中国移动自身，将不同的技术产品和应用整合在一起，技术实现是靠开发商，但是其核心理念完全是在移动的主导之下完成的。从数据仓库的构成来看，由数据获得层、数据存储层、应用层和展现层构成，除此之外，还有数据质量管理、安全管理等等。

    数据获取层的主要工具是ETL工具，负责进行数据的清洗、转换、加载；而光有工具是不能完成ETL的，所以数据获取层还需要开发商，而这个开发商一方面要对工具很熟悉，另一方面要对业务熟悉，对数据熟悉，否则怎么能将清洗的规则制定、开发好？

    在数据存储层里，数据存储于数据仓库和数据集市两种方式。技术方面，各个数据仓库厂商都有自己的解决方案，中国移动选型范围内的是IBM的DB2、NCR的TERADATA和ORACLE，而业界用得比较多的还有SYBASE和微软，至于数据集市，则可更开放一些，很多做应用和数据挖掘的工具厂商也可以将其数据子集看作数据集市。如果是纯粹的数据仓库体系，数据集市的数据只能来自于数据仓库，也就是说，如果数据集市本身具备ETL的功能，从数据仓库之外获得了数据，严格来说，这个就不是数据集市，而是另外一个数据仓库了。如果在一个企业里出现两个数据仓库，那么对企业来说是场灾难，因为除了投资方面的浪费之外，数据一致性的问题就足够企业的高层和IT部门头疼的了，因此如果应用需要引入新的数据源，比较合理的做法是先将数据导入企业的数据仓库，再从数据仓库生成数据集市，再去开发应用，这样虽然周期可能会加长，但是企业拥有完整的数据仓库，对未来的发展至关重要，从这个意义上来说，牺牲一些效率也是值得的。

    补充一句，虽然我强调数据仓库的唯一性和技术要求，但是如果一些开发商开发出比较好的分析和应用，初期放在数据仓库外面，也应该是允许的。就象BOSS的外挂系统一样，开始让应用自己完成开发等工作，数据仓库也可以配合提供部分数据，允许应用厂商自己从别的数据源获得数据，来保证应用的最终效果。但是，当系统稳定，真正成为成熟的应用纳入数据仓库体系的时候，还应该从数据获取层开始完成融合。

    接下来说应用层了，这个层面是最活跃、最具商业价值的部分，无论是CUBE的构建还是分析模型的设计，都是数学和计算机技术运用得相当纯熟的人才能掌握的，技术含量很高。其中的各种工具，包括是报表工具（cognes、brio、BO等等），数据挖掘工具（SPSS、SAS）等等，还有些软件是多种技术和工具合一的（这方面我只是自己的理解，不对的请多指正）。而应用的开发商更呈现多元化，无论是数学好、IT技术好还是对业务熟悉、经营和管理理论熟悉，都可以开发出非常好的分析应用软件。而既然在应用层软件与业务结合得更多些，自然业务部门在应用的选择和开发方面占据比较大的优势。

    最后是展现层，个性化的展现方式也是丰富多彩的。我个人不太赞成建立一个面向所有使用者的门户，因为使用者的特点不同，专业不同，给他们一个同样的界面会让每个使用者都不习惯，因此我认为展现应该按照使用者分别建立。比如管理人员的界面和实际接触客户的操作人员界面，就不应该统一。所以说我觉得应该在每个面向使用者的门户上，如OA、呼叫中心、营业终端等多个界面上嵌入经营分析的应用，让他们在实际工作中自觉不自觉地用到经营分析，而不是急于突出经营分析系统的专业性，也许这才是我理想的经营分析使用的境界。

    除此之外，还有数据质量管理的工具和软件，这方面从建模到验证，又有很多门道，我就不详细说了，再说真的可以写出一本教材。但是，我还要强调两点：第一是没有任何一个厂商或产品可以完成数据仓库体系的全套工作，即使象某些厂商一直强调自己提供完整的数据仓库解决方案，但在实际上，他们也只完成了数据仓库系统建设的部分工作，换句话说，就是数据仓库绝对不是某个单一厂商能建成的，必须需要多方配合。第二是我对数据仓库的憧憬，就是中国移动的生产分析会议上，各个部门都在拿数据说话，因为各自的角度和观点不同，他们讲的内容甚至可能是相互矛盾的；但有一点是共同的，就是所有的分析数据（注意，不是说分析，而是说分析所需要的数据）都来自于业务支撑系统部的数据仓库系统。