商業(yè)智能（BI）大家可能早已耳熟能詳。從早期的報表自動化，到現(xiàn)在的復雜靈活分析，多平臺支持，優(yōu)秀的人機互動，多數(shù)據(jù)抽取，大數(shù)據(jù)整合，甚至和當下最火的人工智能都有結(jié)合點�？赡芤惶岬紹I，大家都會自然而然地把這個話題丟給IT。但是由IT主導的BI項目最終是否能夠落地？
為什么以技術(shù)為主導的IT部門做不好BI項目？
首先我認為BI是最直接，最重要地服務(wù)于商業(yè)決策者的，尤其是管理層。BI應(yīng)用是否符合用戶習慣，數(shù)據(jù)是否準確及時，是BI能否活下來的關(guān)鍵之關(guān)鍵。試想一個難以操作，擠滿了圖表，而且錯誤百出的BI應(yīng)用，哪個經(jīng)理會有興趣去使用它？一旦失去存在的價值（credibility），被拋棄就成了自然而然的事情。
其次國內(nèi)的IT人員普遍熱衷于技術(shù)而忽略業(yè)務(wù)，對于很多開發(fā)人員來說，看InfoQ的興趣要遠大于CEO年終總結(jié)里的數(shù)字。由于業(yè)務(wù)知識和經(jīng)驗的缺失，很多時候IT閉門造車搞出來的BI應(yīng)用根本不是業(yè)務(wù)人員需要的。慢慢地雙方的激情消退，抵觸情緒滋長，失敗是早晚的事。
另外很多IT部門現(xiàn)在還停留在維護傳統(tǒng)大型項目的框架里。當今的商業(yè)瞬息萬變，與之配對的決策系統(tǒng)也應(yīng)該具備靈活變化的能力。我相信很多商業(yè)決策者經(jīng)歷過類似的痛苦，例如從提出某個報表的修改意見到正式上線往往要等很長時間。但這不能完全怪IT，因為他們需要審批，獲取權(quán)限，收集數(shù)據(jù)，測試，寫文檔...。所以一個小的修改可能要在6個月后release里才能實現(xiàn)。轉(zhuǎn)型需要時間，但作為重要的決策者，您會等嗎？
站在商業(yè)和IT之間，BI主要包含了什么？
國外很多大牛都定義過BI的框架。在此，我只是根據(jù)前人的經(jīng)驗和一些國內(nèi)項目的經(jīng)歷總結(jié)出自己的內(nèi)容。從下往上，我的BI各元素框架（BI Component Framework)主要分為3個部分：基礎(chǔ)部分（Foundation），實現(xiàn)部分（Enablement），和輔助部分：
圖1 BI元素框架
BI框架之基礎(chǔ)部分（Foundation）
從業(yè)務(wù)層面來講整個框架的根基應(yīng)該是商業(yè)或者管理層的“覺醒”和授權(quán)。很多公司現(xiàn)在還依賴于excel報表。業(yè)務(wù)部門習慣于從excel中生成圖表，粘貼到PPT里，然后把周報，月報，或者年報呈現(xiàn)給管理層。這樣做會面臨幾個主要的問題：首先是數(shù)據(jù)的準確性。Excel報表肯定難以避免手工錯誤，而且在充滿大量的 vLookup 或者公式的excel里找出錯誤是十分痛苦和低效的。其次是資源壓力。越復雜的報告所需要的數(shù)據(jù)和人力越多。期限前集體趕報告的經(jīng)歷很多人應(yīng)該都有吧。再次是時效性。商業(yè)決策講究的是快速靈活。有些報告，例如公司年報確實不要求實時，但是很多底層的業(yè)務(wù)決策是不能等到周末或者月末才能開始制定的。最后是安全性。數(shù)據(jù)和分析結(jié)果全都在excel或PPT里。IT部門可以限制email，封鎖網(wǎng)盤，但是直接考取那？面對這些問題，管理層必須思考是否需要一個完備的BI系統(tǒng)。
BI應(yīng)用的靈魂來自于數(shù)據(jù)。數(shù)據(jù)就好似血液一樣支撐著整個BI系統(tǒng)。但很多時候公司的數(shù)據(jù)是最為敏感的，例如供應(yīng)商數(shù)據(jù)或財務(wù)數(shù)據(jù)。此外一些部門會把數(shù)據(jù)當成“私有財產(chǎn)”而拒絕或者有限度地與其他部門分享。單純的BI實施團隊（不管是IT主導還是業(yè)務(wù)主導），在沒有高層甚至頂層授權(quán)的情況下很難持續(xù)地推動BI項目。因此管理層的“覺醒”和授權(quán)是我認為完成一個BI項目最優(yōu)先，最重要的基礎(chǔ)。
接下來是了解公司業(yè)務(wù)。前面已經(jīng)說過了，IT部門通常精于前沿的技術(shù)而忽略業(yè)務(wù)，但是BI作為業(yè)務(wù)部門最直接的決策工具，失去了業(yè)務(wù)的支撐就好比給一個厭食癥患者做了一桌子滿漢全席。業(yè)務(wù)的構(gòu)成有很多，例如公司有哪些KPI，各個部門的核心業(yè)務(wù)是什么，報告流程是什么，瓶頸在哪里，業(yè)務(wù)流程都需要哪些職能，是否需要內(nèi)外合作等等。對于業(yè)務(wù)的理解，IT技術(shù)人員容易習慣性地用用例圖（use case）或者系統(tǒng)架構(gòu)圖（system architecture）來表達。但是問一下哪一個經(jīng)理或者業(yè)務(wù)員能一下子看懂那些圓圓圈圈代表的意思？在這里我的經(jīng)驗是用最傳統(tǒng)的流程圖和excel列表，因為大部分非IT人員基本不需要工程培訓就可以輕松的理解你要表達的意思。
了解公司的系統(tǒng)和數(shù)據(jù)是重點�，F(xiàn)在只有極罕見的公司還僅使用office或者手工作業(yè)，基本上大家都多多少少有些系統(tǒng)，一些大的公司甚至會上馬全套的ERP，sales force，CRM等。對BI團隊來說，系統(tǒng)本身的迭代，之間的接口，承載能力，權(quán)限設(shè)置，技術(shù)特點等都是需要了解的。數(shù)據(jù)分析則需要更多的精力。從范圍來說除了分析系統(tǒng)內(nèi)已有的數(shù)據(jù)，BI團隊還要了解手工生成的數(shù)據(jù)，例如excel報表。從屬性來說要分析數(shù)據(jù)的歷史情況，數(shù)據(jù)的完整性，數(shù)據(jù)質(zhì)量，數(shù)據(jù)層級（hierarchy），數(shù)據(jù)從屬，維度變化（包含緩慢變化維的情況）等等。根據(jù)目前的經(jīng)驗，我遇到的數(shù)據(jù)分析最大的痛點：一是數(shù)據(jù)質(zhì)量，尤其是歷史數(shù)據(jù)。很多業(yè)務(wù)部門，尤其是缺乏控制的部門，其數(shù)據(jù)都是五花八門的。在清洗的時候會遇到各種問題。二是數(shù)據(jù)定義。很多公司沒有主數(shù)據(jù)系統(tǒng)，或者根本不遵循主數(shù)據(jù)。同樣一個主體，這個部門或系統(tǒng)定義這個code，另一個部門或系統(tǒng)使用別的code。在數(shù)據(jù)需要聯(lián)通的時候我們需要耗費大量的時間去協(xié)調(diào)和校對。
分析完公司的業(yè)務(wù)，系統(tǒng)和數(shù)據(jù)之后真正的難點來了：整合。之前的分析都可以是獨立的，但是在這里我們必須在熟知公司業(yè)務(wù)和數(shù)據(jù)的情況下把所有信息整合在一起。例如我們要知道在每一個流程里數(shù)據(jù)進口在哪里，出口在哪里，誰生成數(shù)據(jù)，誰更新數(shù)據(jù)，誰使用數(shù)據(jù)，怎么使用的，同樣的數(shù)據(jù)是否被重復定義或多次使用，主數(shù)據(jù)是什么，數(shù)據(jù)屬性又是什么等。我認為這個時候BI團隊還是要更多的和業(yè)務(wù)部門坐在一起，交流的方式還是以流程圖為主，只不過更加復雜，例如加入數(shù)據(jù)流和不同的人物信息。描述數(shù)據(jù)情況的時候則不拘于形式，但要把現(xiàn)狀和問題說明白，千萬不可以隱藏，否則將來的BI系統(tǒng)一定是垃圾進，垃圾出（rubbish in，rubbish out）。
在以上元素都介紹完之后，我們終于可以和IT坐下來談?wù)劯星椋槺懔囊幌聰?shù)據(jù)存儲，建模以及BI工具的實施了。
數(shù)據(jù)不會像水一樣從源頭直接流進BI系統(tǒng)。通常我們需要通過一個叫做ETL（技術(shù)術(shù)語，全拼是Extraction，Transformation，Loading）的流程來把數(shù)據(jù)從源頭抓取到BI的數(shù)據(jù)倉庫（data warehouse）。除了業(yè)務(wù)部門的終端系統(tǒng)和數(shù)據(jù)之外還有各種介于“中間層”的輔助數(shù)據(jù)，例如主數(shù)據(jù)，也要通過ETL流程把它們保存到BI倉庫里。不同的IT部門會使用不同的技術(shù)來實現(xiàn)數(shù)據(jù)倉庫，例如MySQL，微軟的SQL，或者云端的數(shù)據(jù)庫技術(shù)等等。
BI建模和普通的數(shù)據(jù)庫建模有很大區(qū)別。一般系統(tǒng)數(shù)據(jù)庫建模更多的是考慮數(shù)據(jù)存儲，而BI本身只消費數(shù)據(jù)，其模型主要是為了服務(wù)將來的報表和分析。因此負責BI建模的架構(gòu)師除了能夠駕馭兩種數(shù)據(jù)庫的思維之外，還要有很強的技術(shù)能力和業(yè)務(wù)理解力。好的模型除了能針對不同的業(yè)務(wù)需求做出快速反應(yīng)之外，還要有足夠的拓展性以防備未來的業(yè)務(wù)變更或者新需求。因此好的數(shù)據(jù)建模師特別值錢。
有了BI所依賴的數(shù)據(jù)倉庫和模型之后，我們可以開始用BI工具來開發(fā)對業(yè)務(wù)用戶有意義的信息和應(yīng)用。別忘了到目前為止大多數(shù)業(yè)務(wù)部門和管理層是不知道或者看不懂BI團隊在干什么的，直到我們在屏幕上把表格或者圖形做出來。BI工具有很多種，例如傳統(tǒng)的SAP，IBM，Oracle等提供的重型BI工具，也包括時下流行的新型工具，例如QlikView，Tableau，PowerBI還有帆軟公司的FineBI等等。當然一些大公司也可以使用自己開發(fā)的BI工具。
當數(shù)據(jù)、模型和工具都敲定之后，之后就可以開始真正的BI實施了。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
相關(guān)文章
