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