BI项目都是由企业需求驱动的,而且后续的项目方案也只有和企业的需求契合才能产生价值。通常情况下,BI项目主要由企业信息化建设与数据应用需求驱动。项目前期的立项阶段要明确大致需求,这些需求要能支撑BI项目的立项和工具选型;项目正式启动阶段要弄清楚详细需求,也就是具体到业务、数据、技术等层面的需求,这关乎项目的落地。

1.大致需求与详细需求

明确大致需求,就是要弄清楚当前企业中各方人员的痛点,找到必须建设BI项目的理由和共识,并确定项目范围。

不同行业的企业BI建设的价值诉求点并不相同,因此在项目前期要注意收集和整理,多跟企业领导层、业务部门沟通,挖掘他们的关注点,弄清楚他们真正想要的是什么,再整理出项目的应用场景、功能需求、交互需求、管理需求,预估项目周期等。

BI项目成功与否,最终要看项目完成后企业能不能将它用起来。很多企业的BI项目之所以失败,就是因为没想清楚需求就开始建设,导致一步错,步步错,做出来的系统并不能解决企业的问题,甚至根本用不上,领导也会质疑IT部门的价值和BI系统的意义。所以,上BI项目前,要准备好,瞄准目标再出发。

要大致了解BI系统是哪些部门用,用在哪些场景中,用了后能够带来多少价值,最好能带来企业整体业绩或者利润的提升(即有可见的、可量化的价值)。

例如,企业每个月月底都要制作财务报表,一直采用的方式是财务部门从企业各个系统中取出数据,经过手工整理,然后用Excel汇总和制表。整个过程不但耗时耗力,还会产生很多问题,例如维度的问题、统计口径的问题、数据真实性的问题等,财务部门一到月底便苦不堪言。这个时候就可以说企业有了一个明确的BI应用需求,并且有可落地的场景,那么BI项目才有价值,能够解决实际问题。

有了大致的需求,企业明确要上BI项目后,就可以正式立项了,初步梳理出来的部门需求和场景可以作为工具选型时的考量因素。收集和明确详细需求是设计项目蓝图方案前的主要任务,是对大致需求的深入和细化,要具体到可执行的粒度,例如每一个业务指标的分析与展示的维度和单位等。这个过程涉及业务、技术、数据等方面,需要通过细致的需求调研来完成。总体来看,大致需求确定BI项目的核心价值和边界,详细需求确定BI项目的落地和验收,两者相辅相成,前者指明出发的本心,后者规范前行的里程碑。

2.需求调研

收集和明确需求并非易事,尤其是挖掘需求方详细的、深层次的需求。很多企业在做需求调研时,经常由于双方对问题描述和理解上的差异,使得需求在不断传递的过程中发生较大的偏差,最终开发出来的功能与原始需求大相径庭。图1形象地描述了需求的传递偏差,业务人员说不清,技术人员不理解,导致最终的开发结果无法满足真实业务场景的需求。

图1  需求的传递偏差

那么,如何才能做好需求调研,使真实业务环境中的需求准确无误地传达给最终的开发人员呢?总结起来有两点:把握好总体思路和原则,做好三个关键环节。

需求调研的总体思路是以模块为线,以整体为面,由粗到细,先整体后局部,先集团后部门。在总体思路的基础上,一个非常重要的原则就是在收集和确认需求时做到“抓痛点而不是抓痒点”。

通过一层层地抓痛点,让管理层、业务人员明确其需求,也就是项目边界,IT人员的开发就不会偏离方向。最后即便BI系统不能保证完美契合需求,但是核心需求得到了满足,BI系统在企业中能用起来,项目也不算是失败的。

需求调研的三个关键环节是调研业务部门分析场景,调研数据质量,设计、确认及修改数据体系。

(1)调研业务部门分析场景

在调研业务部门分析场景前,首先要做的就是依据BI系统的使用者确定需要调研的业务部门,可以一次性调研所有希望用BI系统的业务部门,也可多次循环调研。对于需要调研的每个部门,都应指定对应的数据对接人和业务对接人,当然也可以由同一个人兼任。

具体的调研可以从三个层面展开。首先是管理层面,主要调研与企业战略相关的指标分析需求,方法是将企业战略目标层层拆解到不同的层级。例如,将战略目标拆解到某个部门后,该部门就需要通过BI系统分析部门的KPI或OKR(Objectives and Key Results,目标与关键成果)、项目进度、部门业绩,以及人员各项指标的完成情况等。可以参考表1拆解企业战略目标,并进行分析和记录。

表1  业务部门需求调研——企业战略目标拆解

其次是调研业务部门在一些日常分析场景中的需求,可以通过表2进行收集。

表2  业务部门需求调研——日常分析场景

最后是调研业务部门的一些隐性需求,这些需求与日常分析场景不同,需要通过头脑风暴或访谈的方式去挖掘,可分别参考表3和表4。

表3  业务部门需求调研——隐性需求(头脑风暴)

表4  业务部门需求调研——隐性需求(访谈)

在完成这些需求调研后,可以依据场景维度指标化与数据体系化的原则,对收集的所有场景需求进行总结。例如,某时尚企业的BI项目团队对各个业务部门进行需求调研后,根据类型、需求指标、指标定义和公式、数据粒度商品/渠道、数据频度、数据来源等维度,将需求总结为如图2所示的Excel表格,并且在场景维度指标化的基础上,对数据表进行梳理,最终形成企业的数据指标体系。

图2 某时尚企业业务部门需求总结示例

(2)调研数据质量

企业中的数据按来源主要分为业务系统数据、手工数据、外部数据等。对数据质量的调研也从这三个来源展开,本质是梳理企业已有的数据。
对业务系统数据进行调研时,项目团队需要明确各业务系统对接人,获取相关数据接口和数据字典,若无法获取则需要协商,制订应对策略。对于手工数据,项目团队可先行收集历史手工数据资料,此项工作可与业务部门的需求调研同步进行。对于外部数据,可参考业务系统数据的调研方式,重点关注数据的可获取性和使用场景。

需要注意的是,在调研数据质量阶段,需要清晰地定义组织架构、用户及权限体系等项目的核心架构数据。其中,权限不仅包括模块功能权限,还包括数据权限,即不同的用户、角色能够看到哪些数据,例如城市销售经理能够看到所负责城市的销售数据,区域销售经理则能够看到所负责区域的销售数据等。

(3)设计、确认及修改数据体系

设计数据体系时主要考虑原始表和基础宽表两个层级,结合之前调研时所考虑的数据使用要求的最小粒度,以及分析中可能用到的维度、指标,尽可能做到对分析场景的全覆盖,满足各类数据粒度要求。

对数据体系的确认和修改主要包括数据维度、指标、粒度的增/删/改,字段含义及逻辑口径统一。完成确认和修改之后,项目团队还需要输出需求调研确认书,得到项目领导委员会和各个团队认可后方可进入下一阶段。