数据仓库_BI商业智能／数据仓库实施杂谈

从最初接触BI商业智能到现在已经十多年的时间，一直以乙方角色工作。今天忽然想就BI在甲方公司的应用情况做些总结，以及提一些设想，也希望有兴趣的朋友一起交流。与具体工具无关，偏重于方法论的讨论。

早期的BI实施情形大概类似于这样，大家都没太经历过BI项目，抱有美好的期望，反正大家都吹的很厉害，KPI，仪表盘，即席查询，OLAP 等等，这些看起来非常先进（相较于，纸质手工报表，电子化的手工报表，没有报表，或 Excel）. 实施的结果是，不论甲方还是乙方都发现没有那么美好（比如像我这样的乙方菜鸟，在培训后觉得这些BI工具非常先进，不用写代码就可轻易产生报表，生成图形），一些习以为常的样式不能实现（比如中国式报表常用的左上角斜线），使用起来非常不习惯。或者更惨，开发的东西业务单位基本不需要，项目结束时因好奇来看两眼，之后就束之高阁了（我有一个客户ETL服务有故障，停了2个星期居然没人抱怨...）.

接下来比较多的一个情形是某个业务项目带入BI产品，比如分析性CRM项目，审计项目，风险评估项目等等。这一类的BI应用结局稍好一些，因为应用需求明确，但缺点是一般只限于基本报表查询，配以少量图形，KPI以装点美化；只是作为报表工具存在，因为是其他项目的附属，投入有限，提供的报表灵活度，用户自定义程度普遍较低。这种模式下的BI应用造成甲方客户的重复采购，常常一个甲方拥有多套BI工具。

传统意义上最正统的应用模式是，数据仓库DW+商业智能BI, 前者负责后台数据处理，数据集成，按粒度存储；后者负责面向用户数据展现，报表Portal管理；也有很多人将这前后台统称为BI框架。这一类的BI应用大多也是成本最昂贵的模式，主要是银行/电信等企业率先实施。让一些国际大鳄类的乙方吃得满嘴流油，实施效果总体来看也只能说勉强堪用，这个过程额外的好处是让一批本土的实施顾问有了经验。

近年还有一种模式是基于BI工具或方法开发完整的应用，或者是应用模板。常见的有绩效管理，BSC战略管理，财务分析，渠道分析，行业分析 等等，前两个例子算是基于BI应用的产品化，后两个就纯粹是模板化应用了。基于BI的产品化其实就和传统的软件项目/软件产品就比较接近了，将业务知识固化在系统中，BI也只是作为报表工具存在。重点提一下的是，BI模板化应用是在乙方在项目实施经验基础上提炼而来，什么财务分析，杜邦分析，销售，库存周转等等模板指标看起来非常全，好像很容易快速应用，但真正实施起来就比较麻烦了。这一类的实施逻辑是倒推法来做，用已有的模板套在企业中，再强行将企业的数据环境与模板需求匹配。这一块做的比较多的像Oracle 的 BIEE中有一个应用套件，做了很多成品化的分析模板，为了解决企业数据环境匹配的问题，该应用只能接SAP R/3, Sieble CRM等几个非常有限的业务系统，而且这些系统还不能有大规模的客制化。

现在就形成了一个矛盾，BI项目中，甲方希望能看到一个快速实现的成果，而如果乙方提供的应用也好，模板也罢，完整度越高，越接近成果则灵活性越差，和不同企业的环境匹配就越困难，满足不同客户的个性需求就越麻烦。而传统的BI开发理论上可实现客户的任意需求，但周期长，工作量大，数据流的路径比较长（从数据源到最终呈现给用户，中间要经过很多步骤，像排程，抽取，多级存储等等）整个项目的可控性差，项目管理非常困难。

针对这种种难题，各实施团队都在总结自己的数据项目方法论。工具厂商也在尝试，像 QlikView、Tableau 等，他们不再强调数据仓库端，而把更多的功能放到数据展现端，让用户快速使用，也有更多的自主权。 下一篇文章会讨论 数据仓库项目的众多失败点，以及新的发展方向。 

本文为中国统计网原创文章，需要转载请联系中国统计网（info@itongji.cn ），转载时请注明作者及出处，并保留本文链接。