1、a,1,BI項(xiàng)目的實(shí)施過程,a,2,BI項(xiàng)目實(shí)施的方法論與過程,當(dāng)前各家BI的軟件廠商都有各自不同的BI實(shí)施方法論和過程，他們大多大同小異. 這里以SAP BW的實(shí)施方法論和微軟BI通用流程為例，來闡述BI項(xiàng)目實(shí)施的基本過程和需要注意的事項(xiàng),a,3,SAP BI項(xiàng)目實(shí)施的大致流程,a,4,項(xiàng)目計(jì)劃和準(zhǔn)備,在項(xiàng)目準(zhǔn)備和計(jì)劃階段，考量項(xiàng)目是否已經(jīng)“萬事俱備”可以從3個方面入手。 用戶需求是否清楚？ 是否已經(jīng)明確BI的技術(shù)標(biāo)準(zhǔn)？ 業(yè)務(wù)部門是否有所準(zhǔn)備？ 在這3個方面中尤為重要的是:用戶需求是否清楚。 實(shí)際情況是用戶在開始階段并不能完全清楚自己需要什么,可能會在以后的過程中修正自己的需求,故在設(shè)計(jì)階段

2、需要充分考慮到擴(kuò)展性.但一些主要的需求必須要在項(xiàng)目計(jì)劃階段搞清楚,a,5,缺乏高層領(lǐng)導(dǎo)的支持。BI的目標(biāo)用戶不同于ERP，它覆蓋的面從高層領(lǐng)導(dǎo)到一線員工都有，并且更側(cè)重于管理層。他們可能是BI的最終用戶，并且直接介入管理層的日常工作。如果領(lǐng)導(dǎo)層不理解項(xiàng)目的意義并支持項(xiàng)目的實(shí)施，將對項(xiàng)目產(chǎn)生巨大的不利影響。 沒有制定BI的技術(shù)標(biāo)準(zhǔn)。BI的項(xiàng)目實(shí)施是一個長期的過程，分階段來實(shí)現(xiàn)，通常不會一個項(xiàng)目就解決所有的問題。因此在選擇BI軟件，硬件，架構(gòu)等問題上必須有長期的考慮，為企業(yè)制定可擴(kuò)展的BI技術(shù)標(biāo)準(zhǔn)是關(guān)鍵。 沒有獲得業(yè)務(wù)部門的資源支持。BI項(xiàng)目同ERP一樣需要大量的業(yè)務(wù)部門的資源，IT只能負(fù)責(zé)其中的

3、一部分，業(yè)務(wù)部門必須承諾在項(xiàng)目中投入相應(yīng)的資源。 在項(xiàng)目準(zhǔn)備階段沒有相應(yīng)的咨詢公司的參與。大多數(shù)的企業(yè)對于BI應(yīng)用的認(rèn)識仍然處于相對初級的階段，因此在項(xiàng)目準(zhǔn)備階段就選擇咨詢公司并讓他們參與規(guī)劃對項(xiàng)目的實(shí)施有重要的意義。,這個階段可能的陷阱有以下這些：,a,6,設(shè)計(jì)階段,設(shè)計(jì)階段是BI項(xiàng)目最重要的階段，其重要性甚至超過了具體的開發(fā)階段。該階段大致需要覆蓋以下方面：,a,7,設(shè)計(jì)階段的注意事項(xiàng),本階段中的關(guān)鍵的關(guān)鍵是業(yè)務(wù)分析和模型設(shè)計(jì) 應(yīng)該如何展開業(yè)務(wù)分析？ 業(yè)務(wù)分析事實(shí)上包括了兩方面，源系統(tǒng)分析和用戶需求分析。以下圖示是比較通用的業(yè)務(wù)分析方式：,a,8,業(yè)務(wù)分析人員應(yīng)該同時(shí)從用戶需求和源系統(tǒng)兩端

4、同時(shí)展開分析，并且其中的重點(diǎn)在于源系統(tǒng)的數(shù)據(jù),是最終該BI應(yīng)用可以滿足多少用戶需求的必要條件。一個好的業(yè)務(wù)分析應(yīng)該在充分理解源系統(tǒng)數(shù)據(jù)的基礎(chǔ)上，不但能滿足用戶的需求，并且能超越或預(yù)見用戶未來可能的需求從而予以相應(yīng)的考慮。,a,9,如何進(jìn)行模型設(shè)計(jì),業(yè)務(wù)分析所產(chǎn)生的文檔將直接指導(dǎo)數(shù)據(jù)倉庫的模型設(shè)計(jì)。模型設(shè)計(jì)與業(yè)務(wù)分析經(jīng)常是同一個人來負(fù)責(zé)，但也因此對建模師的要求抬高了。目前數(shù)據(jù)倉庫建?；旧嫌袃煞N模式，一種是Bill Inmon所首先提出的ER模型，另一種是Kimbal的維度建模方式。數(shù)據(jù)集市一般都是維度建模的（也叫星型模型）。也有將這兩種模型混合使用的。,如何驗(yàn)證所建模型的好壞,客戶經(jīng)常反復(fù)檢驗(yàn)

5、的是報(bào)表或分析的質(zhì)量而非常少的來檢驗(yàn)?zāi)Ｐ偷馁|(zhì)量。殊不知，模型的好壞很大程度上將影響前端分析的質(zhì)量，系統(tǒng)的速度，ETL開發(fā)的難易等一系列的問題。可見，檢驗(yàn)?zāi)Ｐ唾|(zhì)量是如何重要了，但是目前而言還沒有一個業(yè)界公認(rèn)的標(biāo)準(zhǔn)方法和流程來檢驗(yàn)?zāi)Ｐ偷馁|(zhì)量。下面是一個經(jīng)常用到的方法:,a,10,第一步：如果是ER模型則首先應(yīng)檢驗(yàn)是否所有的實(shí)體表已經(jīng)在模型中正確的建立了。比如，項(xiàng)目包含了銷售主題的分析，那么銷售相關(guān)的實(shí)體表是否已經(jīng)包含在了模型中？（假設(shè)發(fā)現(xiàn)銷售訂單表或客戶表沒有包含，那么顯然有問題）。如果是維度建模，那么總是首先確認(rèn)是否所有的維度表已經(jīng)明確。接下來，就要檢驗(yàn)實(shí)體表之間的關(guān)系（ER建模）或維度和事實(shí)表

6、之間的關(guān)系（維度建模）。 第二步:如果是維度建模那么檢驗(yàn)事實(shí)表和粒度是相當(dāng).顯而易見，如果是ER建模同樣要檢驗(yàn)是否在ER模中包含足夠細(xì)的數(shù)據(jù)粒度。同時(shí)在這一步中可以檢驗(yàn)是否因?yàn)橄到y(tǒng)性能優(yōu)化的需求而進(jìn)行了相關(guān)的設(shè)置，比如增加了某些聚合表，或進(jìn)行了索引的優(yōu)化，或進(jìn)行了分區(qū)等等。,a,11,第三步:如果是維度建模在重點(diǎn)在檢驗(yàn)?zāi)Ｐ蛯τ诰徛兓蚩焖僮兓木S度是如何解決的。如果是ER模型，則需要考慮基于該模型的數(shù)據(jù)集市應(yīng)該如何管理維度的變化。最后應(yīng)該嘗試對模型使用相應(yīng)的業(yè)務(wù)需求來進(jìn)行檢驗(yàn)，通?？梢酝ㄟ^提問回答的方式來檢驗(yàn)（因?yàn)榇藭r(shí)前端和ETL還沒有完成）。比如，提問：客戶需要產(chǎn)生月度的銷售報(bào)表，并可以按

7、產(chǎn)品進(jìn)行分類?；卮穑耗Ｐ椭幸呀?jīng)包含了月度的銷售聚合表，可以按產(chǎn)品維度進(jìn)行分析。,a,12,設(shè)計(jì)階段可能的陷阱,在用戶需求分析和設(shè)計(jì)的時(shí)候沒有同時(shí)從源數(shù)據(jù)和用戶需求出發(fā) 忽略了架構(gòu)設(shè)計(jì) 忽略了對數(shù)據(jù)模型進(jìn)行檢驗(yàn)的重要性 數(shù)據(jù)建模時(shí)沒有對緩慢變化和快速變化的維度進(jìn)行適當(dāng)?shù)奶幚?為滿足用戶需求在前端設(shè)計(jì)時(shí)加入了過多的客戶化或額外編程的要求。,a,13,開發(fā)階段,完成設(shè)計(jì)以后的開發(fā)階段是BI項(xiàng)目中占用大多數(shù)人工和時(shí)間的階段，在這個階段項(xiàng)目將進(jìn)行一系列的開發(fā)，比如ETL的開發(fā)，前端報(bào)表或分析的開發(fā)，元數(shù)據(jù)管理，權(quán)限設(shè)置等等。但是有意思的是，在這個階段最有難度的并不是具體的開發(fā)有如何的難度，最難以控制的是

8、這樣一個問題：“我們開發(fā)的是否正是用戶需要的？ 聽上去這個問題不是應(yīng)該在設(shè)計(jì)階段已經(jīng)解決的嗎？沒有錯，設(shè)計(jì)階段應(yīng)該要解決這個問題，通過理解用戶的要求和源數(shù)據(jù)的狀態(tài)。但是相比于用戶對于數(shù)據(jù)模型的無法理解，用戶對于前端報(bào)表和分析的要求通常是非常高，并且經(jīng)常變化的。隨著BI項(xiàng)目的進(jìn)展，用戶對于他們想要得前端報(bào)表和分析的要求是在不斷變化的，我們并不能通過一個設(shè)計(jì)階段就期望能夠確定所有前端的需求?？梢哉f，設(shè)計(jì)階段只能夠給我們一個前端需求的基礎(chǔ)版本，它的最終確定會隨著項(xiàng)目的進(jìn)展而變化，而我們需要做的就是要不斷地發(fā)現(xiàn)這些變化并在開發(fā)階段更新我們的設(shè)計(jì)來滿足這些變化。,a,14,開發(fā)階段的陷阱大致有如下這些：

9、 1.缺乏項(xiàng)目變化控制流程 2.缺乏項(xiàng)目質(zhì)量控制尤其是數(shù)據(jù)質(zhì)量監(jiān)控 3.在開發(fā)階段沒有讓最終用戶參與 讓最終用戶參與開發(fā)，目的就是要及時(shí)反饋用戶對開發(fā)結(jié)果的意見，并通過項(xiàng)目變化控制流程來決定是否要改變設(shè)計(jì)文檔以反映最新情況。問題是如何才能有效地來讓最終用戶參與？,a,15,同步開發(fā)，分步驗(yàn)收,在這種開發(fā)方式下，ETL隊(duì)伍和前端開發(fā)隊(duì)伍需要協(xié)同工作，將所有的開發(fā)需求先分成幾個組，每個組包含開發(fā)前端所需要的ETL。如此，前端開發(fā)團(tuán)隊(duì)就無需等待ETL團(tuán)隊(duì)開發(fā)完所有的ETL才進(jìn)行開發(fā)。當(dāng)前端團(tuán)隊(duì)開發(fā)完第一組前端報(bào)表時(shí)，ETL團(tuán)隊(duì)就可以配合加載真實(shí)數(shù)據(jù)，這個時(shí)候就可以讓最終用戶馬上參與進(jìn)來檢驗(yàn)前端報(bào)表是

10、否符合他們的需求，以及數(shù)據(jù)是否正確。 這種開發(fā)方式的最大優(yōu)點(diǎn)就是，它減少了在測試階段用戶有可能提出的需求變更，并增加了用戶對項(xiàng)目結(jié)果的信心。,a,16,a,17,測試和部署階段,測試和部署階段最重要的任務(wù)是檢驗(yàn)整個項(xiàng)目的結(jié)果。大致有以下的關(guān)鍵點(diǎn)： 除了集成測試以外，需要特別指出的是性能優(yōu)化和業(yè)務(wù)流程重組是容易被忽略的部分。特別是業(yè)務(wù)流程重組，普遍的誤解在于BI項(xiàng)目由于其產(chǎn)出是報(bào)表和分析，不同于ERP，似乎不涉及業(yè)務(wù)流程變化。其實(shí)不然，BI項(xiàng)目的根本目的不在于僅僅產(chǎn)出報(bào)表，重點(diǎn)是通過使用BI應(yīng)該如何優(yōu)化企業(yè)的決策流程。也就是說，有了更多更強(qiáng)大的數(shù)據(jù)和分析，應(yīng)該如何改變企業(yè)的行為？比如，銷售經(jīng)理應(yīng)

11、該通過BI的分析來指導(dǎo)他的銷售員進(jìn)行具體的銷售活動？每周或每月的銷售會議在有了BI之后應(yīng)該如何改變以最大化的利用BI,a,18,在這個階段的陷阱通常是：,1.缺乏業(yè)務(wù)流程變更的準(zhǔn)備和沒有相應(yīng)的資源 2.缺乏足夠的用戶培訓(xùn)和推廣 3.在最后一分鐘，對項(xiàng)目的需求進(jìn)行修改,a,19,系統(tǒng)上線,系統(tǒng)上線階段，不過這并不是BI項(xiàng)目的結(jié)束。BI應(yīng)用對企業(yè)來說不是一個或兩個項(xiàng)目，而是一個長期的實(shí)施和不斷優(yōu)化過程。系統(tǒng)上線階段，除了要對已經(jīng)完成的項(xiàng)目進(jìn)行總結(jié)和安排系統(tǒng)維護(hù)的流程以外，重要的是應(yīng)該重新來審視企業(yè)的BI戰(zhàn)略，調(diào)整長期的規(guī)劃，預(yù)算下一階段的項(xiàng)目。 這里的陷阱就是： 1.認(rèn)為BI實(shí)施已經(jīng)結(jié)束 2.缺乏

12、長期的規(guī)劃,a,20,總結(jié),BI項(xiàng)目的實(shí)施沒有捷徑，試圖跳過以上的關(guān)鍵階段，盲目的壓縮項(xiàng)目的時(shí)間和資源都將不可避免的帶來失敗的危險(xiǎn)。,a,21,微軟BI項(xiàng)目實(shí)施的通用流程,a,22,首先，從報(bào)表下手可以很容易的掌握用戶所關(guān)注的東西，結(jié)合業(yè)務(wù)系統(tǒng)以及數(shù)據(jù)結(jié)構(gòu)可以有助于對主題有個大體的印象，同事對一些用戶比較關(guān)注的維度和度量才能有個概念。 但是理解業(yè)務(wù)是個需要經(jīng)驗(yàn)和理解能力的過程，不同行業(yè)都會有不同的特點(diǎn)，所以這里需求人員和業(yè)務(wù)專家的參與就比較重要。另外同樣也不可忽視掉包括項(xiàng)目相關(guān)的文檔的重要性。 前四個步驟要求一定是有BI經(jīng)驗(yàn)人參與的。這樣看過報(bào)表以及系統(tǒng)后，對主題，度量維度等才能有個大體的規(guī)劃

13、。試想如果連主題，度量維度都不清楚為何物，那么此處根本無法進(jìn)行，包括后續(xù)的維度建模。,a,23,模型驗(yàn)證，根據(jù)已建立的維度模型驗(yàn)證是否能滿足所有的報(bào)表需求。同上，此步驟必須要有BI經(jīng)驗(yàn)的人做。如果模型滿足不了統(tǒng)計(jì)的要求則重新建模。這里是需要一個反復(fù)迭代的過程，每次迭代的結(jié)果都要沉淀下來并且形成文檔。 反向確認(rèn)數(shù)據(jù)倉庫結(jié)構(gòu)，手動或者系統(tǒng)自動均可，自動生成來說SQLServer從2005就已經(jīng)支持了，不過為了命名規(guī)范，還是手動來生成數(shù)據(jù)倉庫比較有必要。 分析數(shù)據(jù)來源及SSIS開發(fā)。最好是由相關(guān)模塊的開發(fā)人員參與，因?yàn)殚_發(fā)人員是對數(shù)據(jù)結(jié)構(gòu)比較了解的，并且有SQL功底，而且還掌握業(yè)務(wù)。這一步的目的是填

14、充數(shù)據(jù)倉庫?？赡苄枰m當(dāng)SSIS培訓(xùn)。不過，這一步公認(rèn)是最耗時(shí)的。同時(shí)，不是所有的統(tǒng)計(jì)項(xiàng)就是能從業(yè)務(wù)那邊解釋的了的，比如某些統(tǒng)計(jì)概念，可能在業(yè)務(wù)系統(tǒng)從來就沒出現(xiàn)過，但是通過基本數(shù)據(jù)組合都可以計(jì)算出來。所以類似概念，確認(rèn)計(jì)算公式等就需要BI人員承擔(dān)起需求的工作去確認(rèn)。,a,24,BI人員需要與業(yè)務(wù)開發(fā)人員協(xié)同制作開發(fā)數(shù)據(jù)增量的方案，以配合SSIS的開發(fā)。還有一種比較好的方法就是開發(fā)人員寫SQL然后BI人員用BI的方法將其整合到方案中，總之方法很靈活，關(guān)鍵的就是跟開發(fā)人員的溝通。 SSAS開發(fā)，生成多維數(shù)據(jù)集，確認(rèn)分區(qū)，增量等操作，建議這里一定要符合SSAS的規(guī)范，命名約定等，這樣會給后續(xù)工作減少

15、很多麻煩。 SSRS等其它開發(fā)。這一步需要參與的人員可以靈活來定，因?yàn)槭切枰欢ǖ腗DX經(jīng)驗(yàn)，而且有可能需要對團(tuán)隊(duì)進(jìn)行報(bào)表開發(fā)培訓(xùn)。,a,25,數(shù)據(jù)驗(yàn)證，等同于測試的過程，觀察統(tǒng)計(jì)出的數(shù)據(jù)是否有異常，比如通過單個SQL查詢的方式對報(bào)表數(shù)據(jù)進(jìn)行驗(yàn)證。如果出險(xiǎn)問題，根據(jù)問題的實(shí)際情況再去確認(rèn)是哪個環(huán)節(jié)出的問題。 生產(chǎn)環(huán)境的部署,a,26,SQL SERVER BI項(xiàng)目實(shí)施過程中的四最,最關(guān)鍵的部分：維度建模，這里準(zhǔn)確與否將決定整個項(xiàng)目的成敗，這里也最需要經(jīng)驗(yàn)。 最有難度的部分：主題確認(rèn)。對于業(yè)務(wù)復(fù)雜的系統(tǒng)來說，這是一個需要時(shí)間的過程，而且需要反復(fù)迭代。 最累人的部分:SSIS開發(fā)。SQL腳本工作比較多，很累人，而且也需要耐心。 最需要的支持