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