【BI】 商业智能(BI)项目的介绍 Part 4:由上至下的实施流程

【BI】 商业智能(BI)项目的介绍 Part 4:由上至下的实施流程_第1张图片
BI项目介绍 Part 4

我在前面几部分介绍了传统BI项目的7层结构和关注点。内容以经验总结为主,偏理论。在接下来的部分我会介绍BI项目的两种实施方法,算是对理论的落地。

【BI】 商业智能(BI)项目的介绍 Part 4:由上至下的实施流程_第2张图片
传统BI项目框架

介绍前,我想先说一下由上至下(Top-Down)和由下至上(Bottom-Up)的区别。由上至下可以简单的认为是某个业务组、部门老大、或者公司老大来授权或者牵头的“轻量级”BI实施项目,目的是解决某个小组,某项业务,或者某个部门的业务痛点或者需求。在您写此类项目的标书或者启动报告时会深有体会。

由下至上的项目正相反。其目的是优先摸清整个公司的数据,系统,流程,组织结构,业务重点等,然后通过数据和业务的整合,统一建模,开发出集中的数据仓库或平台,然后通过这个平台来解决不同用户的业务痛点或需求。由下至上的BI项目一般是“重量级”的,其用时长,资源耗费大,单一业务部门很难驾驭,通常由IT部门发起并管理。

本文重点是介绍由上至下的BI实施方法。

项目建立

由上至下的项目目的一般都很明确,某个业务组,某个经理,某个部门老大都可以牵头实施这样的项目。它主要有以下几个特点。

首先是实施团队比较灵活。可以是内部IT帮助实施,也可以聘请外部顾问或者实施团队来完成。由于此类项目的时间、范围、和涉及的业务都相对较小,聘请外部团队会更加合算。一般4到5人的小团队就足够了(采用敏捷方式和新型BI工具。对于SAP等传统大型项目要另行考虑),有业务专家助阵的话还可以事半功倍。如果是业务部门自己牵头的项目,聘请外部团队在数据、资金、和产品所有权方面可以灵活操作。完成之后要么交付给IT,要么继续由外部公司来维护,应该都不是问题。(『牛牛爸的专栏』出品,请勿转载。)

其次是需求明确。第二部分重点描述了过度期待、需求变更、和项目范围蔓延等BI项目常见的问题。我认为这些是国内大部分BI项目失败的主因之一。由上至下强调的是“小范围”,“小流程”,“小部门”。业务部门一般都带着明确的痛点或者需求,不会无厘头地要求项目组跑东跑西。另外此类项目大多是老大牵头,只要优先满足老大的意见和方向,其他人都好说。因此需求分析会相对简单。

数据是BI的灵魂。由上至下因为范围相对小,项目组在先期可以把数据的功课做足,这样项目经理可以更准确地预估时间和风险。此外由于此类项目是业务老大牵头,遇到突发的或者范围外的数据,由业务部门帮忙获取的成功率一般要高于IT或者外部顾问去获取(如果您的公司正相反,IT很强势,那您现在就约饭吧,打好关系嘛)。

由上至下的项目在时间上大多有明确的起点和终点,不会纠缠没完。起点可能就是老大的一句话,或者某个部门的RFQ,终点就是测试完成,解决了用户痛点或需求,并成功上线。由于项目时间相对短,用户不必等很久就能享受分析的结果。对于外部公司,参与这种项目的风险要远小于由下至上的项目。

具体的项目操作流程

介绍完特点之后我们上干货。先看看牛牛爸总结的项目实施7步骤:

【BI】 商业智能(BI)项目的介绍 Part 4:由上至下的实施流程_第3张图片
由上至下的7步实施流程

1.了解用户需求和优先级(Understand Business Needs and Priorities)

由上至下的BI项目目的明确,启动快。因此项目组在初期就可以直奔主题:收集客户需求。我的建议是从“头”开始,先单独了解组长或者经理的目的,痛点,或者需求,然后再接触下面的业务人员。

很多人会建议通过讨论会(Workshop)的形式一次性地收集需求,但从我目前的经验来看,讨论会效率非常低,大多都会演变成吐槽大会。另外管理人员和业务人员坐在一起,很多话不好说,也不会说。因此如果有条件的话,一对一或者小范围的面试(Interview)是最高效的。这里有一个例外:如果公司已经有BI系统,或者大家对BI很熟悉,那么集中起来开讨论会还是可以的。

一个容易被忽视的地方是优先级。80/20原则大家都知道。掌握了用户尤其是经理的优先级,项目组就可以从重点着手,优先分析数据,尝试整理模型,早发现问题早解决。只要达成80%的目标,尤其是高优先级的目标,到后期项目时间或者资源紧迫时,我们可以忽略不重要的内容来避免项目延迟和用户不满。

2.分析相关系统和数据(Analyze Linked Applications and Data)

很多业务人员没有BI或者技术基础,因此他们会完全站在业务的角度提出需求或者痛点 。这就需要项目组分析用户需求,找出背后所隐含的业务流程,系统,和数据,逐一分析它们,并最终转化为技术人员能够看得懂的文档。

此外业务人员往往会重点描绘自己的部分,而忽略别人的部分。因此项目组还要分析了解流程的上游和下游,关键点和瓶颈在哪里,每个点都涉及到哪些人和部门,每个环节会涉及到哪些数据,数据权限如何,访问权限如何等等要素。

系统分析的困难可能会多一些,例如没有访问权限,帮助文档不足,系统所有者不配合,IT不配合,或者大量技术缺陷等。如果系统很老或者是内部开发的,就涉及到将来怎么抽取数据的问题,以及数据质量问题。这些都要在这个阶段分析并解决。

数据的分析是最费功夫的,例如业务人员会简单地要求项目组做出PPT里的某张图,但是他不知道也不关心后面包含了多少历史数据,数据质量如何,数据所有权,有没有手动调整的痕迹,数据维度有哪些,维度是否有变化,多数据整合问题,数据口径问题等等。这些都需要项目组辛辛苦苦地去发掘和注意的。

先码到这。下一部分会介绍操作框架里的第3到第7步骤。

你可能感兴趣的:(【BI】 商业智能(BI)项目的介绍 Part 4:由上至下的实施流程)