商業智慧系統建置成功的要素

很多企業想做商業智慧(Business Intelligence;BI)的應用,往往不知道如何著手;常看到有些使用者導入了報表工具,就自認已具備「商業智慧」了。其實要建置BI系統,還是必須先建立對於BI的正確認識。

BI建置的基本認識
 
絕大多數的BI系統如統計報表、決策支援、樞紐分析、戰情報告等,並不會自己產生資料,而是從各個系統來源蒐集資料,包括檔案交換、網路上的XML檔案,或是其他AP介接過來。為了避免影響前端AP系統效能,資料必須整合在獨立資料庫後,才能進行分析,也可依不同的產業需求所建立的模型而進行優化,執行效能會比在OLTP資料庫上執行來得更好。因為應用不同,資料庫可分為二種類型:一、交易型(OLTP),I/O需求頻繁但一次處理的資料量小,強調的是反應時間,如ERP等AP;二、分析型(OLAP),少數的作業但每個作業處理的資料量通常相當大,對反應時間的要求不高,這是BI採用的類型。
 
一般而言,BI系統的專案可以分為五個階段:
  • 需求階段—確認及記錄需求;
  • 規劃階段—了解資料、架構、模型設計及資料對應;
  • 建置階段—作業開發、流程設計及資料驗證;
  • 上線階段—批次作業執行、資料品質監控;
  • 維運/變更階段—日常維運、異常處理機制及快速反應需求變更。
很多企業以為只要系統上線,專案就結束了,結果忽略了後續的維運及變更。但BI系統與一般AP的差別,就在於系統並非上線即結束,而須不斷變更。BI的價值就是能夠因應市場的變化,提供適當的資訊;因此面對現今市場瞬息萬變,BI系統必須不斷快速且即時的回應需求變動。這是我們強調「維運/變更階段」的原因。
 
BI系統成功的七大要素
 
本文就筆者十餘年BI開發與建置專案經驗,總結成功七大要素,提出以供業界朋友參考。
 
一、[需求階段] 做好元數據(Metadata)管理
 
元數據是指用來描述資料/系統/定義的說明,更是做好資訊治理(Information Governance)的基礎。BI的元數據管理應包含三項目:除了一般專案都會建置的資料系統元數據(資料庫層級的資料描述)外,應用系統的元數據與資料字典常被忽略,如下圖。
 
應用系統元數據包括系統/服務/程式層級描述資訊,因BI系統一定會與其他系統關聯,加入應用系統層級之描述才能補資料庫層級之不足。資料字典則建立一致性的抽象資料溝通基礎,包含Business Term、Code Table等,避免專案資訊認知不一致的問題。唯有透過建置資料字典,才能真正做好資訊治理。
 
 
二、[需求階段] 了解所處理的資料
 
通常資料格式會與預期認同出現不同的原因,包括系統需求變更、文件遺漏或未更新及不同系統來源,因此建置BI一定要做好資料剖析(Data Profiling),包括檢查數據內容是否與元數據中所定義描述的一致、找出是否有遺漏值、可能的內定值、無效值的存在,並檢查內容格式是否有不一致的狀況等。
 
三、[規劃階段] 選擇適切的ETL開發工具
 
讓工程師直接寫程式開發,雖可於專案初始降低成本,但隨著系統日趨複雜,其人力成本將會會大於工具購置成本。採用程式開發除了長期人力成本墊高外,往往會因為人員流動,而導致作業程式不易維持一致標準、技術交接費時且不易落實、容易產生資安漏洞等問題;這將導致開發速度及執行效能因此降低,造成後續修改成本提高,進而造成人力開發的整體開發費用,要比工具建置來得高。如下表。
 
 
        
人力開發
工具建置
初始工具投資成本
僅適用小型專案
開發成本 程式開發一致性 難控管
開發速度
維運成本 執行效能 難校調至高效能
維護與異動 難且慢 易且快
交接傳承 易疏漏 有保障
資安控管 易疏漏 嚴謹
 
我們有客戶原需5人日的需求變更於導入ETL工具後,縮短至0.5人日,績效提昇10倍。
 
四、[規劃階段] 基礎架構須涵蓋End-to-End作業
 
從來源資料彙整作業,一直到前端報表產生作業,BI系統的作業往往橫跨多套AP或程式。若系統設計讓作業流程讓各程序保持各自排程而鬆散串接,則流程整體難以控管。故BI系統之基礎架構須涵蓋End-to-End(來源資料彙整一直到報表產生)作業之整體流程控管,這有賴於導入一個批次作業管理平台,如下圖。
 
 
五、[建置階段] 資料品質清理與監控
 
並非有了資料,經由BI系統就能夠就產出具價值的資訊。因為資料持續匯集進來,其格式、品質都可能有問題,如果無法適時修正,所產生的資訊即不正確,甚或「Garbage In、Garbage Out」。因此BI系統須有資料品質管理機制,以預防提供錯誤資訊、避免產生昂貴錯誤,及強化資料清理能力等。對於來源資料品質監控程序,必須持續性進行;除了從資料的來源,來發現資料格式的錯誤,也要針對產生的資訊進行監控。請參考「資料品質白皮書」。 資料品質管理機制如下圖。
 
 
六、[上線階段] 批次作業與異常處理機制
 
根據Gartner統計,有70%的資訊是透過批次作業產生,而複雜的BI系統往往會有2000~3000個 批次作業,IT人員必須考慮的因素很多,包括如何在異常發生時通知負責人員、如何有效監控作業執行狀況、如何規劃良好的批次作業執行機制、作業分散在多台機器上的協同控制機制及重新執行作業時的權限控管與稽核機制等。
 
七、長期維運規劃
 
因為開發人員及維 運人員的任務其實不同,開發人員重視的是如何快速反應需求變更與降低維運人力成本,維運管理卻比較重視如何提供簡易有效的系統監控介面給維運人員。因此應該建置一個兼具開發與維運的平台,可大幅降低建置及維運成本。