BI需求收集方法论

末蓝、 2022-10-27 12:17 77阅读 0赞

# #

收集和明确需求

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

### **1.大致需求与详细需求** ###

明确大致需求，就是要弄清楚当前企业中各方人员的痛点，找到必须建设BI项目的理由和共识，并确定项目范围。第1章讲过BI对企业的价值，但不同行业的企业价值诉求点并不相同，因此在项目前期要注意收集和整理，多跟企业领导层、业务部门沟通，挖掘他们的关注点，弄清楚他们真正想要的是什么，再整理出项目的应用场景、功能需求、交互需求、管理需求，预估项目周期等。

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

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

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

总体来看，大致需求确定BI项目的核心价值和边界，详细需求确定BI项目的落地和验收，两者相辅相成，前者指明出发的本心，后者规范前行的里程碑。

### **2.需求调研** ###

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h6cDY2Ng_size_16_color_FFFFFF_t_70][]

![20210204095405619.gif][]![图片][df8c40dec66d0831d60fd15cbfaf8160.png]

图1  需求的传递偏差

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

需求调研的总体思路是以模块为线，以整体为面，由粗到细，先整体后局部，先集团后部门。在总体思路的基础上，一个非常重要的原则就是在收集和确认需求时做到“抓痛点而不是抓痒点”。通过一层层地抓痛点，让管理层、业务人员明确其需求，也就是项目边界，IT人员的开发就不会偏离方向。最后即便BI系统不能保证完美契合需求，但是核心需求得到了满足，BI系统在企业中能用起来，项目也不算是失败的。

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

**（1）调研业务部门分析场景**

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

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

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

![图片][30c0e58ec31ff596df92225473b8da16.png]

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

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

![图片][b0fde87832414c8f21b78d62df73a6bf.png]

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

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

![图片][b1de67462d1f66299236a69f3b06e849.png]

表4  业务部门需求调研——隐性需求（访谈）

![图片][585a25d7a2202d09de1e658313cf27ee.png]

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

![图片][9421e0458bd8861ff89bea51e29bf086.png]

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

**（2）调研数据质量**

企业中的数据按来源主要分为业务系统数据、手工数据、外部数据等。对数据质量的调研也从这三个来源展开，本质是梳理企业已有的数据。

对业务系统数据进行调研时，项目团队需要明确各业务系统对接人，获取相关数据接口和数据字典，若无法获取则需要协商，制订应对策略。对于手工数据，项目团队可先行收集历史手工数据资料，此项工作可与业务部门的需求调研同步进行。对于外部数据，可参考业务系统数据的调研方式，重点关注数据的可获取性和使用场景。

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

**（3）设计、确认及修改数据体系**

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

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h6cDY2Ng_size_16_color_FFFFFF_t_70]: /images/20221024/e5c18c90a9034290b4aaa90b1fe1f7d0.png
[20210204095405619.gif]: https://img-blog.csdnimg.cn/20210204095405619.gif
[df8c40dec66d0831d60fd15cbfaf8160.png]: https://img-blog.csdnimg.cn/img_convert/df8c40dec66d0831d60fd15cbfaf8160.png
[30c0e58ec31ff596df92225473b8da16.png]: /images/20221024/5fdd16f7f4a74f1ab424315baff52d80.png
[b0fde87832414c8f21b78d62df73a6bf.png]: /images/20221024/07f1375e34354e349eac16f9e9eadf78.png
[b1de67462d1f66299236a69f3b06e849.png]: /images/20221024/f2c25f6f9cef45079f7421501fa5ca03.png
[585a25d7a2202d09de1e658313cf27ee.png]: /images/20221024/09747148b656440a889e88215c0b4295.png
[9421e0458bd8861ff89bea51e29bf086.png]: /images/20221024/eb3745625afc4114a8eaebc9786f9831.png