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

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

我們分為三個(gè)層面討論這個(gè)問題。

多維分析

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

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

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

關(guān)聯(lián)查詢

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

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

一個(gè)可用于檢驗(yàn)BI產(chǎn)品關(guān)聯(lián)能力的通俗例子：查詢女經(jīng)理的男員工。這個(gè)很簡單的查詢需求中涉及到同一數(shù)據(jù)集的多次關(guān)聯(lián)，大多數(shù)BI產(chǎn)品都處理不了(除非事先建模)。

有了關(guān)聯(lián)查詢能力后，BI產(chǎn)品能解決的自助需求占比能提高到20%-30%，具體程度要看產(chǎn)品提供的關(guān)聯(lián)能力的強(qiáng)弱。

過程計(jì)算

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

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

在沒有更好的交互計(jì)算技術(shù)出現(xiàn)之前，這些問題還是需要技術(shù)人員才能解決。在這個(gè)前提下，BI產(chǎn)品能做的事就不是讓業(yè)務(wù)人員自己實(shí)現(xiàn)過程計(jì)算，而是要想法提高業(yè)務(wù)人員獲取技術(shù)資源的效率，以及技術(shù)人員實(shí)現(xiàn)需求的開發(fā)效率。

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

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