介紹前，我想先說一下由上至下（Top-Down）和由下至上（Bottom-Up）的區(qū)別。由上至下可以簡單的認(rèn)為是某個(gè)業(yè)務(wù)組、部門老大、或者公司老大來授權(quán)或者牽頭的“輕量級”BI實(shí)施項(xiàng)目，目的是解決某個(gè)小組，某項(xiàng)業(yè)務(wù)，或者某個(gè)部門的業(yè)務(wù)痛點(diǎn)或者需求。在您寫此類項(xiàng)目的標(biāo)書或者啟動報(bào)告時(shí)會深有體會。

由下至上的項(xiàng)目正相反。其目的是優(yōu)先摸清整個(gè)公司的數(shù)據(jù)，系統(tǒng)，流程，組織結(jié)構(gòu)，業(yè)務(wù)重點(diǎn)等，然后通過數(shù)據(jù)和業(yè)務(wù)的整合，統(tǒng)一建模，開發(fā)出集中的數(shù)據(jù)倉庫或平臺，然后通過這個(gè)平臺來解決不同用戶的業(yè)務(wù)痛點(diǎn)或需求。

由下至上的BI項(xiàng)目一般是“重量級”的，其用時(shí)長，資源耗費(fèi)大，單一業(yè)務(wù)部門很難駕馭，通常由IT部門發(fā)起并管理。

項(xiàng)目建立

由上至下的項(xiàng)目目的一般都很明確，某個(gè)業(yè)務(wù)組，某個(gè)經(jīng)理，某個(gè)部門老大都可以牽頭實(shí)施這樣的項(xiàng)目。它主要有以下幾個(gè)特點(diǎn)。

首先是實(shí)施團(tuán)隊(duì)比較靈活?？梢允莾?nèi)部IT幫助實(shí)施，也可以聘請外部顧問或者實(shí)施團(tuán)隊(duì)來完成。由于此類項(xiàng)目的時(shí)間、范圍、和涉及的業(yè)務(wù)都相對較小，聘請外部團(tuán)隊(duì)會更加合算。一般4到5人的小團(tuán)隊(duì)就足夠了（采用敏捷方式和新型BI工具。對于SAP等傳統(tǒng)大型項(xiàng)目要另行考慮），有業(yè)務(wù)專家助陣的話還可以事半功倍。

如果是業(yè)務(wù)部門自己牽頭的項(xiàng)目，聘請外部團(tuán)隊(duì)在數(shù)據(jù)、資金、和產(chǎn)品所有權(quán)方面可以靈活操作。完成之后要么交付給IT，要么繼續(xù)由外部公司來維護(hù)，應(yīng)該都不是問題。

其次是需求明確。第二部分重點(diǎn)描述了過度期待、需求變更、和項(xiàng)目范圍蔓延等BI項(xiàng)目常見的問題。我認(rèn)為這些是國內(nèi)大部分BI項(xiàng)目失敗的主因之一。由上至下強(qiáng)調(diào)的是“小范圍”，“小流程”，“小部門”。業(yè)務(wù)部門一般都帶著明確的痛點(diǎn)或者需求，不會無厘頭地要求項(xiàng)目組跑東跑西。另外此類項(xiàng)目大多是老大牽頭，只要優(yōu)先滿足老大的意見和方向，其他人都好說。因此需求分析會相對簡單。

數(shù)據(jù)是BI的靈魂。由上至下因?yàn)榉秶鄬π?，?xiàng)目組在先期可以把數(shù)據(jù)的功課做足，這樣項(xiàng)目經(jīng)理可以更準(zhǔn)確地預(yù)估時(shí)間和風(fēng)險(xiǎn)。此外由于此類項(xiàng)目是業(yè)務(wù)老大牽頭，遇到突發(fā)的或者范圍外的數(shù)據(jù)，由業(yè)務(wù)部門幫忙獲取的成功率一般要高于IT或者外部顧問去獲取。

由上至下的項(xiàng)目在時(shí)間上大多有明確的起點(diǎn)和終點(diǎn)，不會糾纏沒完。起點(diǎn)可能就是老大的一句話，或者某個(gè)部門的RFQ，終點(diǎn)就是測試完成，解決了用戶痛點(diǎn)或需求，并成功上線。由于項(xiàng)目時(shí)間相對短，用戶不必等很久就能享受分析的結(jié)果。對于外部公司，參與這種項(xiàng)目的風(fēng)險(xiǎn)要遠(yuǎn)小于由下至上的項(xiàng)目。

具體的項(xiàng)目操作流程

介紹完特點(diǎn)之后我們上干貨。先看看總結(jié)的項(xiàng)目實(shí)施7步驟：

由上至下的7步實(shí)施流程

1.了解用戶需求和優(yōu)先級（Understand Business Needs and Priorities）

由上至下的BI項(xiàng)目目的明確，啟動快。因此項(xiàng)目組在初期就可以直奔主題：收集客戶需求。我的建議是從“頭”開始，先單獨(dú)了解組長或者經(jīng)理的目的，痛點(diǎn)，或者需求，然后再接觸下面的業(yè)務(wù)人員。

很多人會建議通過討論會（Workshop）的形式一次性地收集需求，但從我目前的經(jīng)驗(yàn)來看，討論會效率非常低，大多都會演變成吐槽大會。另外管理人員和業(yè)務(wù)人員坐在一起，很多話不好說，也不會說。因此如果有條件的話，一對一或者小范圍的面試（Interview）是最高效的。這里有一個(gè)例外：如果公司已經(jīng)有BI系統(tǒng)，或者大家對BI很熟悉，那么集中起來開討論會還是可以的。

一個(gè)容易被忽視的地方是優(yōu)先級。80/20原則大家都知道。掌握了用戶尤其是經(jīng)理的優(yōu)先級，項(xiàng)目組就可以從重點(diǎn)著手，優(yōu)先分析數(shù)據(jù)，嘗試整理模型，早發(fā)現(xiàn)問題早解決。只要達(dá)成80%的目標(biāo)，尤其是高優(yōu)先級的目標(biāo)，到后期項(xiàng)目時(shí)間或者資源緊迫時(shí)，我們可以忽略不重要的內(nèi)容來避免項(xiàng)目延遲和用戶不滿。

2.分析相關(guān)系統(tǒng)和數(shù)據(jù)（Analyze Linked Applications and Data）

很多業(yè)務(wù)人員沒有BI或者技術(shù)基礎(chǔ)，因此他們會完全站在業(yè)務(wù)的角度提出需求或者痛點(diǎn) 。這就需要項(xiàng)目組分析用戶需求，找出背后所隱含的業(yè)務(wù)流程，系統(tǒng)，和數(shù)據(jù)，逐一分析它們，并最終轉(zhuǎn)化為技術(shù)人員能夠看得懂的文檔。

此外業(yè)務(wù)人員往往會重點(diǎn)描繪自己的部分，而忽略別人的部分。因此項(xiàng)目組還要分析了解流程的上游和下游，關(guān)鍵點(diǎn)和瓶頸在哪里，每個(gè)點(diǎn)都涉及到哪些人和部門，每個(gè)環(huán)節(jié)會涉及到哪些數(shù)據(jù)，數(shù)據(jù)權(quán)限如何，訪問權(quán)限如何等等要素。

系統(tǒng)分析的困難可能會多一些，例如沒有訪問權(quán)限，幫助文檔不足，系統(tǒng)所有者不配合，IT不配合，或者大量技術(shù)缺陷等。如果系統(tǒng)很老或者是內(nèi)部開發(fā)的，就涉及到將來怎么抽取數(shù)據(jù)的問題，以及數(shù)據(jù)質(zhì)量問題。這些都要在這個(gè)階段分析并解決。

數(shù)據(jù)的分析是最費(fèi)功夫的，例如業(yè)務(wù)人員會簡單地要求項(xiàng)目組做出PPT里的某張圖，但是他不知道也不關(guān)心后面包含了多少歷史數(shù)據(jù)，數(shù)據(jù)質(zhì)量如何，數(shù)據(jù)所有權(quán)，有沒有手動調(diào)整的痕跡，數(shù)據(jù)維度有哪些，維度是否有變化，多數(shù)據(jù)整合問題，數(shù)據(jù)口徑問題等等。這些都需要項(xiàng)目組辛辛苦苦地去發(fā)掘和注意的。