副标题#e#
从最初接触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 ),转载时请注明作者及出处,并保留本文链接。
阅读原文”查看。
#p#副标题#e##p#分页标题#e#