IT項目的失敗率在商業(yè)環(huán)境中一直是偏高的。BI作為IT的一個分支，自然也遇到了相似的問題。在失敗的案例里，有些是因為用戶要求的變化，有的是因為超過時間、超過預(yù)算，或用戶要求的不切實際。此文總結(jié)了五個需要關(guān)注的方面。通過對這五個方面的管理，BI項目可以有效的規(guī)避很多常見的困難，降低項目失敗的幾率。
1、項目范疇制定和管理
很多人會自然地把這個步驟理解為用戶需求的收集和制定。其實用戶需求只是這個過程中的一個手段和結(jié)果。不管是自主開發(fā)，還是集成商為商業(yè)用戶開放的項目，最終目的都是為用戶解決工作中的問題，同時提高和改進工作的效果。
而技術(shù)人員最常犯的錯誤，是把用戶當(dāng)成軟件設(shè)計專家。比如在BI項目里，技術(shù)人員往往會問用戶，你們需要什么樣的報表，什么格式，數(shù)據(jù)在哪里。而用戶就拿出一疊紙面的報表說，就把這些弄到電腦上去吧。本來意在提高商業(yè)效率的BI項目，就變成了一個硬生生把紙面文件通過軟件重新實現(xiàn)的低效率工作。
所以項目的范疇制定，不能只限于直接用戶能夠看到的。作為信息處理的專業(yè)人士，我們必須首先要了解用戶的商業(yè)需求?，F(xiàn)在在信息應(yīng)用上遇到什么問題?決策者有沒有必要的信息和工具?具體操作人員有沒有能力最有效地進行他們的工作?所生成的信息是不是足夠相關(guān)人員解決問題?用戶是否可以主動地分析和發(fā)現(xiàn)問題及最佳方案?
對商業(yè)問題的解決應(yīng)該是BI項目范疇的出發(fā)點。但即使在用戶需求已經(jīng)確定之后，對項目范疇的管理也是一個需要一直進行的工作。只有在一個明確的指導(dǎo)之下，才能把整個項目的工作和用戶的需求完美地結(jié)合起來。
2、設(shè)立符合現(xiàn)實的預(yù)期
BI項目往往是一個涉及很廣的工作。從數(shù)據(jù)的收集，清理，存儲，到數(shù)據(jù)的計算，呈現(xiàn)，分析，和信息的發(fā)布和監(jiān)控。根據(jù)企業(yè)不同的現(xiàn)狀，BI的實現(xiàn)往往需要分成幾個階段來實現(xiàn)。假設(shè)一個企業(yè)還沒有建立起一套相關(guān)的架構(gòu)，一個BI項目就必須首先解決數(shù)據(jù)收集和存儲，建立數(shù)據(jù)倉庫。在數(shù)據(jù)得到了保障之后，再進行報表設(shè)計，Dashboard，及數(shù)據(jù)分析等工作。
在一些新引進BI概念的企業(yè)里，用戶往往會產(chǎn)生一些過度樂觀的想法。常常會把目標(biāo)定得很高。這樣不僅會對項目的預(yù)算和時間造成影響，在把范圍擴大太多后，也常常不能有效地計劃和利用人員和資源。
近年來敏捷(Agile)BI的概念開始被大家接受。這里的Agile和軟件開發(fā)是同一個概念。但應(yīng)用到BI領(lǐng)域，就包含了一些自己的概念。比如對數(shù)據(jù)倉庫的必要與否，數(shù)據(jù)清理的方式等等，都有一些不同的理念。這些我們在下一個章節(jié)仔細(xì)描述。
3、了解架構(gòu)和不同的技術(shù)選擇
BI作為IT的一個分支，技術(shù)上的考慮也是一個很重要的方面。在這里我們討論幾個對項目成敗影響最大的幾個技術(shù)層面。
BI極少是一個獨立的系統(tǒng)。首先，作為一個數(shù)據(jù)處理和信息呈現(xiàn)工具，任何BI的實現(xiàn)都是建立在其它系統(tǒng)的基礎(chǔ)之上的。在計劃一個BI項目時，我們必須對現(xiàn)有的軟件架構(gòu)有一個十分完整的理解。什么樣的產(chǎn)品可以最好的嵌入到現(xiàn)有的架構(gòu)里?什么接口可以最容易和高效地提取數(shù)據(jù)?BI工具是否提供了足夠的集成功能?
在確定了架構(gòu)的選擇之后，第一個需要面臨的是對數(shù)據(jù)倉庫的選擇和設(shè)計。數(shù)據(jù)的整合，清理，及存取是BI項目成功與否的決定性因素。傳統(tǒng)上BI的最佳模式往往是建立在一個高度集中的大型數(shù)據(jù)倉庫基礎(chǔ)上的。在Agile BI的理念影響下，近年來也出現(xiàn)了一些其它的解決方案。比如用全內(nèi)存數(shù)據(jù)處理的(Qlikview)及時匯總技術(shù)，采用云計算技術(shù)的分