先說一個現象：BI數據類系統與業務系統在開發模式上是一致的，核心流程都是采用“瀑布模型”，即：需求分析、系統分析、系統設計、開發、測試、上線。

二者采用相同的模式，但最終效果有很大差別。數據類系統常常有上線即過時的問題，而最常見的解決方法也僅僅是縮短項目周期。

為什么會這樣？因為BI數據類系統與業務系統在很多方面存在差異，先看一下業務系統的特點：

§ 需求類型：功能需求。

§ 需求時效性：功能需求盡管也存在變更的需要，但其功能框架流程的變化相對較小，更多是流程中的某些環節、參數的變更。

§ 系統架構：業務系統可以通過流程標準化、參數化，及微服務、ESB等技術來增強系統的可擴展性。

與此對應，BI數據類系統的特點如下：

§ 需求類型：統計分析需求，或內容需求。

§ 需求時效性：統計分析業務框架也相對保持穩定，同時，具體的統計內容會根據運營、監管、管理的需要而變化。

§ 系統架構：數據類系統更多關注數據架構，及數據的分布、模型。

對比一下，業務系統的需求可以簡單總結為：業務流程框架+參數，同時，系統架構中對應地實現了框架與參數的分離。

BI數據類系統的需求也可以簡單總結為：業務分析框架+具體內容，很不幸，系統架構中沒有考慮業務分析框架的實現。

為什么這樣？需求提出分析方面，二者存在巨大的差別。

業務系統。

業務人員提需求時，關注業務流程，自然而然地表達：先做***，然后**，如果遇到**情況，就如何如何，如果遇到這種情況，就如何如何。

顯然，一個合格的需求分析人員是很容易將需求提煉為：業務流程框架+參數的模式。

在看一下BI數據類系統。

業務人員提需求時，大都關注具體的內容：我需要***張報表，每個報表的表樣***，報表的統計口徑***，報表之間的核對關系***。或，我需要查詢***信息，包括哪些數據項，需要***的過濾條件。

根據業務人員的需求，需求分析人員很容易地就整理一個完備的需求清單（報表清單、查詢清單、文件服務清單），按照這個清單進行設計、開發、測試是順理成章的，且以此進行項目管理也非常清晰。

看，BI數據類系統的業務分析框架很難出現。

怎么走出這個困境？無他，通過項目的知識積累，以及需求分析的“五連問”來解決。“五連問”指，面對業務提出的需求如一張報表，分析人員需要明確：

1.    為什么需要這張報表？

2.    報表使用的場景？

3.    在這些場景中，你關注哪些信息？

4.    采用什么方法來分析、監控這些信息？

5.    這張報表與哪些報表有關聯？

在與業務人員調研、討論這些問題過程中，需求分析人員將設計、完善“業務分析框架”。

業務分析框架包含哪些內容？

業務分析框架應該包括：場景、指標、分析方法、可視化、工具功能、數據及可得性、人員技能要求等。

提煉整理業務分析框架，肯定需要更多、更高級的人員投入，明顯增加項目成本。如果一個金融企業招標中過于強調價格因素，不論中標廠商是否擁有框架的咨詢設計能力，廠商大概率不會提供這類“五連問”的服務。

更多關于BI數據軟件的話題和資訊，歡迎登陸慧都科技//fc6vip.cn/zt/qlik/index.html與我們溝通交流。