【BI】 BI項目的介紹 Part 2：項目的實現

05-14

接前文，Part 1解釋了BI元素框架（BI Component Framework）里的基礎部分（Foundation），現在由下及上繼續聊。首先還是先溫習一下前面的架構圖：

數據搬來了，工具選好了，實施就能成功？

前面我解釋了大多數以技術為主導的IT部門做不好BI項目。如果說那些關鍵點是一個公司始終都要注意的，那麼在實現部分（Enablement），我要提醒幾個特別的風險點。

首先是業務部分或者管理層的過度期待（over expectation）。隨著BI項目的推進，我相信很多以前沒有聽說過商業智能的人會多多少少地去網路了解這個新事物。IT有一個特點，那就是「壞事不出門，好事傳千里」。我想您要是去百度搜索商業智能，看到的更多是「優秀產品」、「開創者」，等等神乎其神的宣傳和各種如科幻片一樣的圖表分析。因此很多沒有項目基礎和實際經驗的人容易對BI產生幻覺，認為只要公司擁有這樣的系統，就好似有了一個超級大腦來保駕護航。或者認為BI同excel一般靈活，隨便改一下公式就可以看到結果。

其次是IT或者BI實施團隊的過度承諾（over promising）。相對於傳統的商業系統，BI算是一個新生事物，因此很多公司的實施團隊經驗有限，容易樂觀地估計項目的結果。例如當項目組在基礎階段發現底層數據的質量高於預期時，便容易樂觀地認為項目時間會大大縮短，或者過早地保證實現某種高級分析。BI項目的鋪墊一般都很長，業務用戶只有等技術人員把分析結果投影到幕布上時才能真正看到問題的所在。在這個階段因為數據或者模型缺陷而把BI應用推倒重來的案例比比皆是。因此過早或過度地承諾可能會在後期給實施團隊帶來巨大的壓力。

再次是用戶需求變更（user requirement changes）。因為BI屬於新事物，很多業務用戶在初期的需求收集階段無法給出準確的意見，只有等看到演示（demo）時才大致明白BI是什麼東西，並且會隨著應用的完善而不斷地提出修改意見。此外BI用戶通常包含部門經理和一般業務人員。不同級別的人對公司業務的側重點會有不同，因此BI團隊經常要面對完全對立的修改意見。如何控制好用戶意見和修改原則是BI團隊要早早考慮的問題。

最後是項目範圍蔓延（scope creep）。基於國內項目的特點和從我個人的經驗，沒有一個交付的BI應用是完全按照設計文檔來實施的。不是因為我們沒有能力做好設計，而是當用戶看到A功能後會立刻要求B功能，甚至提出C功能的預想。對於一般業務人員提出的新需求我們可以找些不明覺厲的理由來拒絕，但是面對管理層，我們可能會失去話語權（BI項目碰到高級經理的機會要遠大於其他項目）。因此BI團隊要按照項目實施方法論和自身的特點儘早做出調整。

BI框架之實現部分（Enablement）

不知道大家是否注意到實現部分的三層順序。為什麼分析會放在報表之後哪？其原因就是防止過度期待和過度承諾而最終導致大家不歡而散。

通常BI項目會在後期碰到各種各樣無法預先準備的問題，例如數據無法打通，模型設計缺陷，維度交叉造成的錯誤，或者無法達成某種分析結果等。此外BI應用是基於業務流程和數據的，IT測試人員僅能夠檢查計算結果是否準確，但無法判斷分析圖表是否符合業務要求，數據結果是否有商業意義等。這些功能上的測試必須在後期業務人員的配合下才能完成，也就是UAT。因此實施團隊如果過早地承諾分析功能，那麼將來等用戶提出質疑的時候，我們很難判斷這是數據的問題，邏輯理解的問題，模型的問題，還是前端代碼的問題。如果在時間壓力下開發人員開始補丁疊補丁，那麼離惡夢就不遠了。

因此牛牛爸強烈建議BI項目先從簡單的報表（reporting）開始！一張報表看似簡單，實際上我們可以發現底層數據的問題，數據倉庫和模型問題，系統性能如何，工程師是否合格，業務和演算法的理解是否到位等等。公司報表一般都有固定的格式和業務流程，因此報表開發不會招致大量的用戶需求變更和範圍變更。快速實現報表自動化還可以拉近BI項目組和業務人員的關係，並增強管理層的滿意度（buy in）。

除了報表，範圍小、用戶少、需求明確的任務也可以作為我們初期的著力點。例如單一產品MTD， QTD， YTD， YoY的銷售數據匯總，一些簡單的目標達成率等。簡單任務完成之後，我們可以逐步加入例如競品數據，然後就可以和業務部門坐下來制定一些相對複雜的分析功能了。

報表是測試數據質量和理解業務的好機會。當報表完成之後，BI團隊和業務人員可以繼續挑戰複雜靈活分析（analysis）。複雜分析的範圍千變萬化，有的是把PPT圖表自動化，有的是根據業務經驗提出更優化的分析（可能需要外部業務專家的介入）。BI團隊可以和業務人員坐在一起共同研究和討論分析方法，併當場向用戶演示開發結果。BI團隊也可以依賴自有經驗和業務專家的能力，先內部設計，開發，然後再向業務人員演示，並收集意見。從我目前的項目經驗來看，效率最高的方法是和專家初步制定設計方案，簡單開發之後再和業務用戶確認。

大數據（big data）是時下流行的概念。很多公司的高層可能會要求實施團隊直接完成大數據項目。但是我認為直接從零到大數據的跳躍基本是自討苦吃，除非公司有富有意義的海量數據，拓展的興趣，和富有經驗的實施人員和用戶。因此我是在報表和複雜分析完成之後才建議公司去嘗試探討大數據項目。但請記住，大部分的公司在現階段是不需要上馬大數據項目的！請做好充分的調查和選型之後再考慮是否做這樣的投資。

如果報表和分析都一帆風順，那麼恭喜您，可以開始挑戰目前BI行業里的最高難度：預測分析（prediction）。預測什麼哪？如果您負責銷售，那麼BI可以預測未來的市場空間和合理的銷售目標。如果您從事投資，那麼BI可以預測公司未來的現金流甚至估值。目前受限於預測的複雜程度，絕大多數公司還是通過線下的方式，使用excel模擬多種參數，然後反覆論證，最終敲定某業務的預測值或者目標值。因此牛牛爸到目前為止還沒有這類項目的成功案例。我的經歷更多是相對簡單的情景（scenario）分析。

所謂情景分析，就是在現有數據的基礎上，通過手動或自動調整某些參數而達到檢查其他指標的目的。例如我們可以通過調整工廠里某個環節的生產率來計算產品在未來市場可能的佔有情況。無論是公司的一般業務人員還是高層，情景分析的用戶參與度最高，得到的反饋也最豐富。作為實施者，能看到BI工具在實打實地幫助業務部門制定公司戰略，心裡還是很滿足的。

從工業角度而非學術角度，我認為預測分析和人工智慧（artificial intelligence）在某種意義上存在交叉。人工智慧既然是通過計算機來幫助和擴展人類的智能，那麼通過對現有數據的分析和挖掘，然後做出對公司最優化的建議無疑就是最高等級的預測分析。當然AI不僅限於此，例如我們可以通過它來更高效地收集數據，通過它來建立業務模型，甚至通過它來編寫演算法程序等。這個話題目前還太遙遠，因此我就不多介紹了。

後文將會給您介紹傳統BI項目框架中餘下的部分。