從早期的多維分析(OLAP)到近年來的敏捷BI，BI產品廠商一直在強調自助能力，宣稱可以由業務人員自己分析數據，而用戶方也常常有強烈的此類需求，雙方一拍即合，很容易形成購買行為。但是，BI產品的自助功能真地能讓業務用戶自己隨心所欲地分析數據嗎?

“分析”這個詞并沒有一個業界公認的嚴格定義，所以不能說這些BI產品是否過份宣傳了。不過，就大多數缺乏BI應用經驗的用戶所期望的工作內容而言，自助分析的目標就可以說遠遠達不到!從經驗上看，***情況也就能解決30%左右的問題而已，而大多數BI產品連這個數也達不到，只能處理10%左右的需求。

我們分為三個層面討論這個問題。

多維分析

多維分析是指針對某個事先建好的數據集(稱為立方體)做交互操作。這是大多數BI產品目前能夠提供出來的分析能力，盡管新一代產品在界面美觀度和操作方便度上有了不小的進步，但能完成的運算功能并沒有本質變化。

多維分析的主要問題是有個建模過程，也就是事先準備數據集。如果要分析的數據都可以限定在某個數據集中，且動作只限于產品提供的那些(旋轉、鉆取、切片之類)，那么沒有問題。但這是個小概率事件，實際應用中會經常超出這個范圍。增加一個以前沒想到的數據項，和另一個數據集做一個關聯運算，都會導致再建模。而建模需要求助于技術人員，這樣業務人員的自助就無從談起了。

做到多維分析這一步，只能解決10%左右的自助需求，這是BI產品最常見的自助能力。

關聯查詢

為解決多維分析的局限性，有些BI產品開始提供關聯查詢能力。一般是在多維分析前面增加一步，能夠基于多個數據集關聯計算出新的數據集再來做多維分析，或者在多維分析過程中支持多個立方體間的某些關聯運算。這相當于允許業務用戶一定程度可以自己建模。

不過，實現關聯查詢并不容易，其根源是關系數據庫對關聯運算(JOIN)的定義過于簡單造成的，導致數據集之間的關聯關系看起來過于繁瑣，超出許多業務人員的理解能力。這個困境在BI產品的界面協助下能有一些改善，好的BI產品能夠讓業務人員正確處理沒有形成環的關聯關系。但是，要從根本上解決問題，就要改變數據庫層的數據組織模型。而幾乎所有的BI產品都不會重新定義數據庫的數據模型，其關聯查詢能力就會受限。這些較深入的技術問題我們將在后續文章中逐步談及。

一個可用于檢驗BI產品關聯能力的通俗例子：查詢女經理的男員工。這個很簡單的查詢需求中涉及到同一數據集的多次關聯，大多數BI產品都處理不了(除非事先建模)。

有了關聯查詢能力后，BI產品能解決的自助需求占比能提高到20%-30%，具體程度要看產品提供的關聯能力的強弱。

過程計算

剩下70%左右或更多的需求，都會涉及到多步驟有過程的計算。而過程計算完全超出BI產品的設計目標，甚至可以不被認為是數據分析，但卻是用戶特別希望解決的問題，也就是讓業務人員能夠隨心所欲地(在其權限范圍內)獲取數據。

一個簡單辦法是使用BI產品導出基本數據，由業務人員自己用Excel等桌面工具去做。但是，Excel并不擅長處理多層次數據的關聯運算(我們后續會討論到)，而且數據量大了也撐不住，在許多應用場景無法勝任。

在沒有更好的交互計算技術出現之前，這些問題還是需要技術人員才能解決。在這個前提下，BI產品能做的事就不是讓業務人員自己實現過程計算，而是要想法提高業務人員獲取技術資源的效率，以及技術人員實現需求的開發效率。

具體來講有兩個方面：一是建立歷史問題庫，某些以前曾經做過的問題，可以直接由業務人員直接調出算法改變參數執行;即使是新需求，也可以找到類似問題以協助技術人員準確理解，技術人員和業務人員的理解不一致是造成事務延期的主要因素之一;二是提供高效且可管理的開發技術，讓技術人員能快速編寫和修改計算代碼，并可將這些代碼存入歷史算法庫中保管和再次執行。目前業界并沒有多少適合的技術，SQL可管理性較好，但編寫繁瑣而難以處理有過程計算;存儲過程需要再編譯而不方便再次執行;Java代碼也要再編譯而基本上不可管理;其它腳本語言的集成性又較差也難以入庫管理和再次執行。

針對于用戶最普遍的自助數據需求，當前BI產品的能力實際上是相當弱的。經常的情況是：BI廠商說的是多維分析，而用戶想的是那些需要過程計算才能解決的問題，這個錯位就會導致期望高而失望大的局面。用戶要清楚自己的自助需求：是否做到多維分析就夠了?有多少關聯查詢需求?業務人員是否會提出大量需要過程計算的問題?這樣才能設定合理的期望值，知道BI產品對自己的作用在哪里，不被產品的花哨界面和流暢操作迷惑，避免事后的遺憾。