需求调研，是做好商业智能BI的第一步

商业智能BI，一个高大上的名字，一直被很多人认为是企业信息化中的“面子工程”。美其名曰“可视化大屏”，什么经营驾驶舱，什么管理仪表盘，都是花里胡哨的东西，老板不会看，企业不会用，就是领导来了做做门面工具。

BI是什么？为什么会成为面子工程？

商业智能BI，它是一套完整的解决方案，用来将企业中现有的数据进行有效的整合，快速准确地提供报表并提出决策依据，帮助企业做出明智的业务和管理决策。BI是以数据为中心，涵盖了数据仓库、数据ETL、数据分析、数据挖掘和数据可视化等内容。

Gartner定义：商业智能（BI）描述了一系列的概念和方法，通过应用基于事实的支持系统来辅助商业决策的制定。 我们看到，不论是笔者的个人理解，还是权威机构的定义，BI的本质是“辅助商业决策”。

但是，一些商业智能（BI）项目的建设失败，引起了人们的质疑和诟病，有人认为BI只是“花花哨哨”的面子工程，对业务没有任何帮助！

为什么BI项目会失败，又如何才能做好BI？这是今天我们要分享的主题。 导致BI项目失败的原因有很多，例如：目标不明确、需求不清晰、领导不重视、数据质量不高、指标定义混乱、设计不人性、界面不美观、程序响应慢等等。

基于以上原因，我们到底该如何做好BI？

交付好BI，从需求调研开始！

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

第一、上BI项目前，要准备好，瞄准目标再出发。

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

第二、立项阶段：项目背景及大致需求

前期背景的调研和大致需求的挖掘很重要，决定了项目的内驱力，也决定了推动项目从哪些痛点和人群去着手。

背景的调研，比如公司的主营业务、需求体量、数据体量以及软硬件实力，然后本次项目需要哪些产品功能模块，参考哪些成果，借鉴了哪些行业经验等等。

明确大致需求，就是要弄清楚当前企业中各方人员的痛点，找到必须建设BI项目的理由和共识，并确定项目范围。能够支撑BI项目的立项和工具选型。对于BI项目，通常的痛点和需求有：

数据报表多，且多为人工汇算，需求响应慢，数据跟不上业务；

各业务系统分散独立，数据孤岛严重，数据标准不一致，数据质量差，指标口径不一致；

有数据无分析：分析报告主要以表格为主，维度单一、形式固化，对分析需求响应的时效性差，无法满足快速灵活多变的数据分析需求；

企业经营转型、业务创新困难，急于从数据应用上寻求转型突破。

第三、启动阶段：详细需求

项目正式启动阶段要弄清楚详细需求，也就是具体到业务、数据、技术等层面的需求，这关乎项目的落地。

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

明确用户。商业智能BI项目的规划一切以用户需求为导向，首先需要明确各层次的需求用户、及应用场景，用了后能够带来多少价值，例如工作量的。

有了大致的需求，就可以进行需求调研，收集和明确详细需求进行项目蓝图方案的设计了。

详细需求设计是对大致需求的深入和细化，要具体到可执行的粒度，例如每一个业务指标的分析与展示的维度和单位等。这个过程涉及业务、技术、数据等方面，需要通过细致的需求调研来完成。

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

需求调研方法与步骤

收集和明确需求并非易事，尤其是挖掘用户详细的、深层次的需求。

很多企业在做需求调研时，经常由于双方对问题描述和理解上的差异，使得需求在不断传递的过程中发生较大的偏差，最终开发出来的功能与原始需求大相径庭。

图1 需求的传递偏差

上图形象地描述了需求的传递偏差，业务人员说不清，技术人员不理解，导致最终的开发结果无法满足真实业务场景的需求。那么，如何才能做好需求调研，使真实业务环境中的需求准确无误地传达给最终的开发人员呢？

总结起来有两点：把握好总体思路，做好三个关键环节。需求调研的总体思路是深入浅出、化繁为简，找对需求决策人、拍板者。需求调研的时候要考虑全面性，做到对全局心中有数。落地的时候有所选择，控制需求和范围，这是相对比较合适的方式。但往往还是会忽略一个问题：需求谁拍板？在需求调研的时候面可以广，广泛听取意见和声音。但一定要分析、摸清楚谁是需求真正的决策人，贡献需求的和拍板人可能是完全不一致的。

往往实际的情况就是在一线各个部门调研了一圈，收集了很多的需求，也整理出来一些分析指标和分析思路，做了大量的工作，但最后到拍板的时候没有人能拍板。并且有可能和具体负责这条业务线高层过会的时候，以前很多收集的需求或者思路都被否定掉了。需要重新纠正、重新设计，最后才发现，具体负责这个业务条线、业务板块的高层领导才是真正需求的决策人、拍板者。领导的习惯是你们先调研、先梳理，各个部门配合，配合完了我来做决策。

所以在实际调研的时候广泛收集想法和意见，摸一个大面就可以了，快速反馈给领导，让领导做完决定后再回头深入下去，这样可以节省至少一半的时间。如果一开始就深入很深，看似很充分、很完整，但实际上都不能拍板。因此在 BI 需求调研的时候一定要找到真正的决策人、拍板者。

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

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

需求调研从三个层面展开：

首先是管理层面：主要调研与企业战略相关的指标分析需求，方法是将企业战略目标层层拆解到不同的层级。例如，将战略目标拆解到某个部门后，该部门就需要通过BI系统分析部门的KPI或OKR（目标与关键成果）、项目进度、部门业绩，以及人员各项指标的完成情况等。可以参考表1拆解企业战略目标，并进行分析和记录。简单的方法是根据管理层目前看数需求（日常内部财报或经营报表）进行梳理，在这基础之上再进行深入。

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

其次是调研业务部门在一些日常分析场景中的需求，可以通过表2进行收集。同样可以根据目前用数需求进行梳理深入。

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

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

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

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

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

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

图2 某企业营销主题需求指标梳理

（2）调研数据质量

数据质量的好坏是导致BI项目是否成功的最关键的因素。

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

对业务系统数据进行调研时，项目团队需要明确各业务系统对接人，获取相关数据接口和数据字典，若无法获取则需要协商，制定应对策略。

对于手工数据，项目团队可先行收集历史手工数据资料，此项工作可与业务部门的需求调研同步进行。

对于外部数据，可参考业务系统数据的调研方式，重点关注数据的可获取性和使用场景。

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

图3 某企业部分需求数据来源

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

设计数据体系时主要考虑原始表和基础表两个层级，结合之前调研时所考虑的数据使用要求的最小粒度，以及分析中可能用到的维度、指标，尽可能做到对分析场景的全覆盖，满足各类数据粒度要求。对数据体系的确认和修改主要包括数据维度、指标、粒度的增/删/改，字段含义及逻辑口径统一。

完成确认和修改之后，项目团队还需要输出需求调研确认书，得到项目领导和各个团队认可后方可进入下一阶段。

图4 某企业部分需求调研文档