收集和明确需求
BI項目都是由企業需求驅動的，而且後續的項目方案也隻有和企業的需求契合才能産生價值。通常情況下，BI項目主要由企業資訊化建設與資料應用需求驅動。項目前期的立項階段要明确大緻需求，這些需求要能支撐BI項目的立項和工具選型；項目正式啟動階段要弄清楚詳細需求，也就是具體到業務、資料、技術等層面的需求，這關乎項目的落地。
1.大緻需求與詳細需求
明确大緻需求，就是要弄清楚目前企業中各方人員的痛點，找到必須建設BI項目的理由和共識，并确定項目範圍。第1章講過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）設計、确認及修改資料體系
設計資料體系時主要考慮原始表和基礎寬表兩個層級，結合之前調研時所考慮的資料使用要求的最小粒度，以及分析中可能用到的次元、名額，盡可能做到對分析場景的全覆寫，滿足各類資料粒度要求。
對資料體系的确認和修改主要包括資料次元、名額、粒度的增/删/改，字段含義及邏輯口徑統一。完成确認和修改之後，項目團隊還需要輸出需求調研确認書，得到項目上司委員會和各個團隊認可後方可進入下一階段。