作爲 CIO，構建一個商業智能 BI 分析平臺應該重點關注什麼？

商業智能 BI 分析平臺構建重點

企業級商業智能 BI 分析平臺的構建是一個系統型的工程，涉及業務分析需求的把控、各類數據資源的整合清洗、數據倉庫的架構設計、可視化分析報表邏輯設計、IT 部門與業務部門的工作邊界劃分與配合等等居多環節。

每一個環節的重要性都不容忽視，今天我們重點選擇兩個環節進行闡述。第一是業務分析需求的把控，第二是數據倉庫的構建，這兩個問題處理的好壞也在很大程度上決定了一個商業智能 BI 項目的成敗。

業務分析需求層面

碰到的痛點與解決方式

對於很多準備或者正在規劃商業智能 BI 項目的企業來說，業務分析需求的梳理是整個項目開始的第一步，往往也是最困難的：

1. 業務部門往往提不出比較具體的分析需求。

2. IT 部門很難深入到業務，也提不出適合業務部門的分析需求。

3. BI 實施方很難在短時間內梳理清並通過一種非常直觀的方式和業務用戶進行有效的溝通。

4. 對於管理層、上級領導部門，特別希望可以直接看到可視化報表分析的成果。他們不會去關心技術和如何實現的問題，能不能先讓看到效果。只有看到效果，纔會有比較直觀的認知，這個項目纔有可能被認可和立項。

5. BI 項目需求分析涉及到很多部門，有的時候內部資源的溝通、協調和推動往往比外部（乙方）的推動要困難的多。

以上這些點集中起來其實就是一個問題：如何能夠非常清晰的梳理好一個完整的業務分析需求，並且能夠用業務部門能夠理解的語言進行有效溝通？

我們的解決方式是什麼呢？就如同下面的房屋裝修一樣，如果要我們自己從頭到尾來設計和裝修實際上是一件很困難的事情。

你不能一直給業務講我們的工具有多麼的好用，多麼的強大，未來這個房子可以裝修成什麼樣子，這種方式是很難行的通的。

正確的做法是提供一個或者很多個不同角度的設計圖或者方案給到用戶，有了設計原型參考，用戶就一定會有很多潛在的想法表達出來。

有了這種原型，大家始終站在對方可以理解的角度上進行溝通，最終出來的效果也一定是自己所期望的。

所以當我們的用戶沒有這種數據分析思維意識的情況下，讓業務用戶提出一些分析的想法，或者讓領導提出分析的內容是非常不現實的。但是讓他們參考一個比較成熟的分析體系或者方案，再來提出自己的想法這樣還是比較容易的。

派可數據的做法是：結合客戶需求以及派可數據在各個行業多年沉澱下來的業務經驗快速的提供各類分析圖表，客戶可以選擇適合企業自身的分析維度和指標、分析模板，或者基於派可數據的各類指標分析體系提出自己的想法，所有可視化分析內容可隨時調整以完全達到客戶的分析需求。

派可數據的一個獨立顧問可以在很短的時間完成用戶的分析需求梳理和分析頁面搭建，包括各類動態效果、鑽透、聯動、跳轉等等，並且在這個階段我們不需要連接用戶的實際數據源。

派可數據 BI 可視化圖表之間的鑽取、聯動等效果

某客戶的業務分析模型梳理

派可數據一個顧問一天半的工作成果

17 個報表頁面 250 多個報表原型各種動圖

100 多個分析指標，比較真實的模擬數據

類似於上面的這種工作成果

換成其它的 BI 工具至少需要 7- 8 天時間

是派可數據的至少 5 倍投入

數據倉庫架構與開發層面

碰到的痛點與解決方式

數據倉庫的開發，可以理解爲一種技術，也可以理解爲一種方法論或解決方案。在商業智能 BI 中，數據倉庫就是最核心的那一層，起到的就是一個承上啓下的作用。往下承接各類數據源中的數據，往上支撐各類分析報表。再形象一點，數據倉庫就如同人身體中的腰腹一樣，腰腹力量是人的最核心的力量，所有的運動都離不開腰腹力量的支撐，重要性不可忽視。

但目前的現狀是越來越多的企業爲了追求所謂的 "敏捷" 基本上已經放棄了傳統數據倉庫的構建。敏捷快速開發是沒有錯的，但很多人錯就錯在沒有分清楚什麼時候應該敏捷，什麼時候應該保留傳統數據倉庫的架構。關於這一點，會在以後的文章中專門講到。

同時，數據倉庫的構建水平將直接影響到商業智能 BI 項目的整體質量。潛在的問題也恰恰出在這裏：數據倉庫的架構設計對開發人員的能力要求相對較高，並且在同一個項目上，不同開發人員對數據倉庫理解的不一致也可能會造成設計的缺陷。

我們在一些項目上看到的普遍問題是：

1. 完全沒有數據倉庫的搭建，基本上使用大寬表、臨時表組成臨時的數據集市，沒有統一的維度設計，邏輯基本不可複用。一旦業務邏輯或者維度層次結構發生調整，整個受依賴的所有分析報表基本上全都得改一遍。碰到極端的情況，基本上開發人員寧願重做也不願意去改報表，因爲沒有辦法改。這種情況在新項目上線的第一年沒有太大問題，但是隨着業務需求的增加與調整，這種問題越來越明顯。

2. 有數據倉庫的架構，但缺少統一的開發標準和規範。一個數據倉庫的設計與維護，不同的開發人員能力各不相同，對於數據倉庫的理解程度高低不一。這就造成在設計和開發數據倉庫的時候沒有統一的標準，大家各自開發各自的，能省事就省事，造成數據倉庫系統維度冗餘、事實冗餘，這對後期的開發維護造成極大的困難。

造成這種問題的原因有很多，有幾個點我可以在這裏簡單總結一下：

1. 現在很多的 BI 分析產品工具整體的設計思路就是在弱化數據倉庫的作用，過度的追求前端可視化的效果，過度的追求快速敏捷開發。這類產品的定位實際上更加適用於個人或者部門級的數據分析場景，並不適合一個真正企業級的 BI 項目構建。對於真正注重企業級 BI 的項目開發，我們不應該削弱數據倉庫的作用，反而更應該加強。

在這樣的一種刻意營造的"行業趨勢"推動下，新進入商業智能 BI 行業的開發人員至少有很大一部分很難有機會再深入數據倉庫的學習和實踐，大部分人的主要工作就是取數和做報表。

2. 大部分經歷過傳統數據倉庫搭建的這批人員要麼逐步退出一線開發，要麼進入比較穩定的甲方企業或大型諮詢機構繼續大型的數據倉庫設計與架構貢獻自己的專業能力，因此仍然活躍在市場上且能夠把控一個企業級數據倉庫架構設計的乙方專家也越來越少。

目前在項目上比較常見的 BI 開發形式就是來一張報表寫一組 SQL 語句，再來一張報表再寫一組 SQL 語句。由於項目進度和工期，或者經驗水平的缺乏，底層的數據倉庫架構設計基本上是缺乏統一規劃和深度考慮的。

所以企業級的 BI 項目離不開數據倉庫的規劃與設計，而這種規劃與設計對人的依賴相對較高，當市場上這類人越來越稀缺的時候，企業想要構建一個穩定可擴展的數據倉庫難度就更大。

要解決的問題是什麼？就是如何讓數據倉庫的構建可以不依賴於某一個人，而是在某一個平臺上直接賦予企業一個完整的企業級數據倉庫開發能力，並且讓所有的 BI 開發人員都自動的遵守同一種開發準則，這個問題就迎刃而解了。

基於多年的 BI 實施交付經驗沉澱，派可數據將數據倉庫已經完全產品化了，通過產品化的方式動態配置維度和分析指標，將整個數據倉庫的開發過程標準化和規範化，極大的減少了對個人開發者的依賴。並且針對部分 ERP 業務系統，例如用友的 U8\NC 等，我們已經內置了核心的分析維度和指標，以及相關的取數計算邏輯。