2007-05-23 00:21
“2001下半年,神州数码的数据处理能力,充其量,也就像是开了个摩托,还是挂斗的!”
“那时候,神州数码营销管理部每个数据分析人员的精神压力都处于超负荷状态,而且还在不断增加,看不到完结。我们部门的五位员工每个都是救火队员,在日益增长的数据量与管理层对数据更高的分析要求之间疲于奔命。”
“除了满耳朵的抱怨在消磨我们的‘坚强’意志,在精力及时间上的损耗也非常大,BI上马前,支持的业务请求同发个数只有10~15个; 一次数据抽取的时间需要夜间8个小时,白天5个小时,要有人一直值守;
出现故障需要花费2~3个小时的恢复时间; 仅是运维工作就占用了全部5名员工80%的工作量。”
神州数码的BI主管陈广地回味起那段“痛苦”的经历,话就收不住了。
需求起源于数据处理效率的低下。1999年以来,神州数码推进了以DSS(决策支持系统)、ERP、e-Bridge三个系统为标志的数字神经网络建设,以降低成本和提高效率为目标,大力加强内部信息化和网络化建设。基于当时数据量并不是非常大,所以数据仓库还不是很实用,仅靠架构在业务系统上的DSS系统就可以很好地满足需求。但是随着信息化发掘的不断深入,数据开始泛滥,神州数码发展至今,本身的数据积攒了约1~2个TB。翻了好几倍的元数据和经过初加工的信息堆在面前,老DSS确实难堪重负。为此,神州数码数据管理部提出了上马BI的DSS改造解决方案,高层领导对此非常支持,指示要立即展开项目调研并予以实施。
2002年3月,随着神州数码BI系统的成功上线运行,套在陈广地等人“脖子上的绳套”终于松开了。
神州数码是幸运的,但观之国内历来的BI项目成功率,却并不乐观,成功的例子也少。Gartner Group于2000年末发表了数据仓库相关项目的调查结果,结果显示数据项目的失败率高达40%。于是,以数据仓库为基础的BI系统成功率被拖进了“先天不足”的窘境。
国内,由于认识的误区,很多企业的领导层盲目认为软件应是低成本投入项目。规模宏大的企业信息化建设项目,在软件方面却投资很少的钱; 而经验的不足,引致许多项目在需求调研阶段就没有明确的范围或偏离了方向。这样,先天不足又遇上了错误的引导思路。
先天不足后天补,及时纠正错误的方向,有效的管理及前期的充分准备成为项目成功的必要条件。
神州数码在BI实施之前,在高层领导的直接推动下,项目组和BI顾问制定了翔实、完备的实施方案,成功也是理所当然。对于一家以“稳重”见长的企业,经历过热闹纷乱的BI建设,一定会盘点收获到的“彻悟”。“一向打着服务大旗的神州数码,在实施BI的基础方面的确具备一定优势。但整个项目过程中,80%的工作量是在前期,真正的实施只占用了20%,正因为前期的充分准备,项目实施得很成功,大多数日后的隐患得以及时除去”,陈广地将神州数码BI的成功故事娓娓道来,“系统数据处理能力的旧患加上前期准备不足的新伤,发作起来可不得了,我们可不能背着棉花过河。”
“M”形的压力线
神州数码从2001年12月与Sagent签约,2002年1月份开始实施,3月份上线运行。算来,神州数码实施BI全程历时近四个月。期间,随着实施进程的不断延伸,项目组成员身上承载的压力也似同股市的大盘走势,攀高趋低,“将那些点连接起来,可以明显地勾勒出一道M形曲线”,陈广地的回忆像是在放一部怀旧电影。
选型阶段的轻松——“我们项目组虽然只有5个人,但个个都是有技术、有经验的老ERP了。”陈广地很自信,“选型阶段的轻松是丰富的经验和清晰的思路换来的。”
“销售数据的分析结果,再等一会儿就出来了”,某员工神色紧张地第三次走进郭为的办公室解释。“怎么这么慢,纯粹耽误事,上了BI,必须要改变现状”,郭为终于发火了。
“不要在老板拍桌子的时候,再去找计算器”,陈广地生动地描述前期调研中,合理定义目标和量化收益的重要性,毕竟领导需要明白,公司花的钱到底能带来些什么。没有一个清晰的项目成功的定义,是很难去界定一个BI项目是否能真正给企业带来效益。
量化的目标不一定是数字或金融表达式,它们只需要明确、有意义即可。许多机构都采用金融衡量标准,比如投资收益率(ROI),来对收益进行量化。经过陈广地及其同事的细致计算,神州数码后来取得的ROI数据是176%。
另外,为全局考虑,在建立第一个面向特定部门或应用的BI系统时,一定要保证现在所使用的模型与结构能够向将来企业范围的BI系统扩展。神州数码在部门之间进行了一致性数据定义,并促使每位员工都能够遵守。陈广地举例,“如何构成一个‘销售体系’?是预约登记、开发票还是付款?在这些定义上的一致性协议会使以后部门数据的联合更加可行、有效。”
接下来是选择能够与用户需求匹配的系统,在BI系统的实际运行过程中,实现数据抽取、清洗、转换、加载和传输的整个过程称作ETL。它约占整个工作量的70%,也是构建BI无法回避的关键环节。
(未完待续)