商業智慧專案錯誤經驗總結（一） 確認意向

lcm_zq發表於2010-05-07
我所在的公司是一家房地產開發公司。上BI專案的起因也很有意思，當時公司上了銷售系統和財務系統，業務部門對於報表的新需求非常頻繁（管理問題所致，這裡不詳述），由此所帶來的問題就是報表開發問題：
1、銷售系統是分公司管理資料的，不能出集團類的報表，所以集團類的報表是人工統計製作的；
2、oracle 財務系統的報表開發週期需要3-7天時間，領導認為時間太長，效率低，成本高；且開發人員必須是資訊部的技術人員或乙方技術人員，導致部門工作量很大；
3、銷售系統裡有售樓管理、採購、專案進度管理等資料，oracle 是財務資料，若要出一份包括這2個系統資料的綜合報表，也需要人工製作；
4、由於很多報表還是需要人工製作，其需要從系統中收集相關資料，其製作週期很長，管理層無法實時瞭解實時瞭解公司現狀，且資料準確性備受質疑，常常是在開會的時候，一個報表，2個部門製作的資料竟然不同（口徑問題）；
針對以上現狀，IT部經理想尋求一個報表製作工具，能夠由業務部門人員根據自己的需求自己製作報表，而不是依靠乙方和資訊部人員，並且這個報表製作工具能同時從銷售系統和oracle裡取數。
基於這樣的設想，我進行了分析和了解，提煉出來這裡麵包括如下幾點的意向：
1、要出綜合報表（包括銷售資料和財務資料），銷售系統的資料庫必須要和oracle 財務系統整合；報表包括月度和年度，若直接在業務系統資料庫進行查詢，會影響業務系統效能；（有些軟體，如潤乾報表工具就不需要整合資料庫，可同時從多個資料庫中取數，其實現原理還是基於關係型資料庫實現）
2、讓不懂技術的業務部門自定義報表，那麼必須要做語義處理，且自定義方式必須簡潔，不需要編寫程式碼，若直接能用拖拉拽的方式實現最好；
這樣看來，BI技術似乎對於上面的條件都可以滿足，DW可以做資料整合，BI產品可以簡單的實現報表和查詢製作，且管理層看報表就是為了分析，若利用BI技術來進行分析，則比之前的意向更加強大了。
於是，我將此設想告訴了IT經理（後面就叫leader吧），他也非常贊同此觀點，表示：現在公司上了那麼多系統，但就沒有一個管理層使用的系統，這樣，BI即解決了報表製作的問題，也可以讓高層更加直觀的分析資料。進展到這一步，看似很順利，實際上風險也隨之而來了。
leader想直接上BI專案，認為這個專案對於資訊部來說很有價值，可以在老闆和高層面前好好的show一下，他已經被BI的“華麗外表”迷惑了。在發現這個預兆後，我立即和leader進行了溝通，表示目前上BI不太合時宜，理由如下：
1、公司的歷史資料還不至於用BI來分析，才幾年的資料，首要是解決報表製作所需要的綜合資料問題。
2、之前提到的採用DW來做整合，目前是為了以後擴充套件到BI而設想，其實現過程可以通過專案分期來實現，這第一期可考慮先用ODS來做資料整合；
3、各系統之間的資料現狀不瞭解，銷售系統和oracle 財務系統還在做改善，資料結構隨時都有變化。若通過這個專案一期，在乙方的配合下，瞭解下目前業務系統的弊病，比如：基礎資料管理，垃圾資料清理等，為以後BI的實現掃除部分障礙；
4、考慮到做房地產BI的乙方不多，通過這一期專案讓乙方瞭解我們的業務系統資料結構和房地產行業業務，通過房地產行業的價值鏈（資金流）來為以後的BI做規劃。
這樣，先設立較低的期望，降低應有的風險，保證最開始設想的需求能夠順利實現。但是，leader已經聽不進去了，堅持直接上BI，讓我不要放在心上，就當拿這個專案練練手，這為專案以後埋下了一個定時炸彈。
 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11773705/viewspace-662113/，如需轉載，請註明出處，否則將追究法律責任。

相關文章