做过项目的都知道， 收集和明确需求并非易事 ，尤其是挖掘需求方详细、深层次的需求。

(资料图片)

很多企业在做需求调研时，经常由于双方对问题描述和理解上的差异，使得需求在不断传递的过程中发生较大的偏差，结果导致最终开发出来的功能与业务原始需求大相径庭。 业务人员说不清，技术人员不理解，导致最终的开发结果无法满足真实业务场景的需求。

那么，怎样才能做好详细的需求调研，使真实业务场景中的需求能准确地传达给最终的开发人员呢？

总结起来有两点：把握好总体思路和原则，做好三个关键环节。

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

先把完整方案分享给大家，需要详细看的直接下：

环节一：调研业务部门分析场景

在调研业务部门分析场景前，首先要做的就是依据 BI 系统的使用者确定需要调研的业务部门，可以一次性调研所有希望用BI系统的业务部门，也可多次循环调研。

对于需要调研的每个部门，都应指定对应的数据对接人和业务对接人，当然也可以由同一个人兼任。项目经理需要分别 对各业务部门的「数据分析师」以及「业务人员」进行调研，配合完成数据情况整理。

其中，具体的业务场景需求调研可以从以下三个层面展开收集。

首先是管理层面。主要调研与企业战略相关的指标分析需求，方法是层层拆解企业和部门的战略目标，然后从数据支撑战略目标的角度进行分析，获取需求数据。

例如，从某企业的公司战略拆解到支撑战略目标的部门

该部门支撑战略目标的 OKR 及对应的业务动作； 为了衡量该业务动作而制定的衡量指标和衡量的维度； 该数据当前是否已有数据的存放位置等。

通过逐步的拆解来确认需要开发的数据表并进行分析和记录：

其次是调研业务部门在一些日常分析场景中的需求：

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

在完成这些需求调研后，可以依据场景维度指标化与数据体系化的原则，对收集的所有场景需求进行总结。

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

环节二：调研数据质量

企业中的数据按来源主要分为 业务系统数据、手工收集数据、外部数据 等。

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

在这个过程中，项目经理需要与信息部 IT 人员沟通清楚以下 2 点：

共同整理现有的数据库数据并确认数据质量 双方确认哪些能够满足需求，哪些不能。不可满足的需求需要回退业务重新调研，可满足的需求则直接提供或提供新表。

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

其中，权限的按人分配支持按照部门和角色进行分配，适合不同架构的公司。

分配数据权限还可以通过 Excel 进行划分标记，某集团总部的权限需求文档就如下图：

环节三：设计、确认及修改数据体系

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

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

总结

需求收集是项目建设过程中重要的一环，按照上述环节去做，至少能省去30%的时间和人力。完整的项目建设包含 企业BI项目该做什么、该谁来做、该怎么做 ，以及 如何在企业内把BI项目成功运营起来 从而产出实际业务价值等问题 ，具体的BI搭建工具如下。

标签：