第3章 理解業務

在0.3.2節中已經知道，好的數據分析師基本技能第一條就是“懂業務”。懂業務會增強對數據的敏感，在拿到數據后能夠有自己的級別判斷，不僅明白這個數字代表什么意義，還知道數字是高了還是低了，有沒有出現異常值，以及增長是來源于行業大勢好轉還是公司產品的競爭優勢等。

本章討論對于一個原來沒有接觸過的新行業的新業務系統切入的方法，當然首先是需要有一定的IT行業其他業務系統的工作經驗，包括業務和技術兩方面的積累，那么在這種情況下如何快速地切入一個新的業務系統，就需要注意相關的方式和方法方面的問題。

3.1 全局了解——業務模型

接觸一個全新的業務系統，首先要搞清楚這個業務系統主要是支撐什么樣的業務?而對于支撐的業務本身又有兩個核心內容，即核心的業務流程是如何的?核心的業務對象模型是如何的?在了解清楚后就可以繼續了解這個業務系統大致會有哪些核心的業務功能模塊，業務模塊之間的相互關系是如何的?以及如何銜接的?

有時候了解到這個層面可能還不夠，還需要了解這個業務系統可能是支撐端到端業務流程或共享業務數據的一部分，那么還需要了解到這個業務系統或支撐的業務在端到端流程中所處的位置，該業務系統和上游業務、下游業務的關系，相互間的協同和接口。

業務系統支撐了什么樣的業務?存儲了哪些核心業務對象和數據?這是對一個業務模型最基礎的全局理解。

3.2 動態了解——流程模型

在對業務模型有了一個全局的理解后，需要開始進一步考慮流程模型方面的內容。注意在這里指的流程模型不是指工作流或人工審批流模型，而是指業務流程模型。或者說了解業務系統本身在分析設計中所涉及的業務建模方面的內容。

一個業務流程模型需要解決的問題是，一個業務系統為何會存在這些業務模塊，這些業務模塊之間是如何進行協同來支撐業務流程的。任何業務模塊都會有輸入和輸出，了解清楚業務模塊的輸入輸出后就能夠比較清楚業務模塊之間是如何串接和集成來支撐上層核心業務的。

如果一個業務系統按SOA思想來建設，那么可能會看到有哪些上層的核心業務模塊，核心的領域服務層和底層的數據模型層，核心的業務模塊本身是如何調用核心領域服務來進行協同和銜接的。只有清楚了業務流程才可能理解清楚業務模塊之間的協同和集成關系，否則將看到的是孤立的業務模塊，業務模塊和業務流程之間出現斷點而無法真正清楚業務模塊間如何協同來支撐業務的。

如果一個業務系統本身是流程型的業務系統，這些流程又大量以審批流為主，那么即使審批流定義再復雜，整個業務系統本身也是簡單的，因為不存在上面所說的大量業務模塊間協同情況。

3.3 靜態了解——數據模型

一個業務系統的復雜往往體現在兩個方面，一方面是本身業務模塊間的協同和交互復雜，另一方面是底層的數據模型和關系復雜。在解決了第一個層面的動態分析問題后，就需要開始考慮第二個層面的數據模型。

任何業務流程，模塊間動態的協同最終都將持久化到數據庫中，成為數據庫中的數據表和數據表之間的關聯依賴關系、映射關系。業務系統在前面談到過或者是以流程為中心的業務系統，或者是以數據為中心的業務系統，對于以數據為核心的業務系統必須理解底層的數據模型。這種數據模型的理解首先是要理解元模型結構，這種結構不是簡單的單個數據對象，而是多個數據對象之間的關聯關系、映射關系、層次關系等。正是由于數據之間有這些關系，而形成了一個復雜的數據網絡。

對于數據模型的理解可從以下幾個方面考慮：一種是單對象的結構，包括主從、層次等各種結構；然后才是對象和對象之間的關聯依賴結構，如一對多、多對多結構等；對于較為復雜的業務系統，可能還會看到為了保證底層數據模型的可擴展性和靈活性，往往在數據模型層會根據面向對象的思路做進一步的抽象，那么在這種情況下還必須將面向對象的對象模型和面向結構的數據庫模型共同來參考理解，以分析和了解清楚最終數據存儲的方式、數據存儲后最終呈現的方式。

3.4 動靜結合——關鍵業務分析

對于新切入一個新的業務系統，如果能夠理解到這一步，基本就對一個業務系統有比較全面的理解和認識。首先是了解業務流程和模塊間協同，然后是了解數據模型和數據間關系，最后則是真正地根據核心業務來進一步理解在流程協同過程中最終數據的落地存儲。由動態的業務流程驅動的最終靜態數據的存儲落地和關系的建立。只有這樣流程和數據的分析最終才會融合為一個整體。

對于關鍵業務的分析將會看到，這些關鍵業務中需要理解清楚究竟涉及哪些模塊的協同，在模塊的協同過程中最終會產生哪些核心的數據，或者說會更改哪些核心數據的狀態或數據間的關系。真正需要關注的往往不是單個數據對象中某些數據熟悉的變更和修改，而更多的是關注核心業務流程驅動下，數據對象狀態的修改、數據對象間關聯關系的修改、數據間映射模型的調整等。

對于一個完整的業務系統，按道理只要有基本的數據對象維護功能即可，但是要真正能夠支撐業務，由于數據對象中的關鍵屬性、關鍵依賴關系的變更，最終都是由上層的業務模塊和流程來支撐的，那么就必須要真正地理解所有的核心業務流程最終對底層數據模型造成的影響。

3.5 數據業務化

數據分析必須非常注重相關的業務實踐，這已經達成共識。但是，怎樣才能把“業務實踐”帶入到數據分析過程中（數據業務化），卻沒有統一的認識。其中有一種看法就是：參加數據建模比賽（如Kaggle）。毋庸置疑，數據建模比賽是一個非常優秀的平臺，備受全球數據科學愛好者追捧，這些比賽所使用的數據都是非常棒的真實業務數據，有非常具體的實際應用價值，對數據分析技能培養幫助很多，但是，這不是“數據業務化”!

所謂“數據業務化”是要在真實的業務環境中，讓數據產生可被產品化的商業價值。從這個角度看，“數據業務化”至少有三個關鍵環節：數據業務定義、數據分析與建模、數據業務實施。

（1）數據業務定義

在一個真實的企業環境中，數據并不是人們關心的根本。人們關心的根本所在是業務。因為，業務是企業之所以存在的根本原因。如果一個企業核心業務的發展，不需要數據助力，那就沒人關心數據分析。事實上，這樣的企業非常多，甚至是大多數。一個企業之所以關心數據分析建模，根本原因一定是因為：數據可以助力核心業務發展。

那么，在這個前提下，一個數據科學家來到一個企業，沒有人會告訴你該分析什么數據，更不會有人告訴你應該如何分析。相反，老板會告訴你他關心什么業務問題。接下來需要把這個業務問題定義為一個數據可分析問題。如果不能把業務問題定義為數據可分析問題，那么數據就無法助力。如果可以，接下來就是數據分析與建模問題。

首先分享一個有趣的故事：一個做貨車車聯網的朋友提到一個問題，說他們有一個物流客戶非常認可他們的數據價值，希望通過貨車車聯網數據幫助手下貨車司機改進駕駛行為。

這是一個非常典型的業務問題。但是，這個業務問題應該如何成定義成為一個數據可分析問題呢?首當其沖的挑戰是：如何定義一個貨車司機的駕駛行為什么叫作“好”，什么叫作“壞”?如果沒有一個清晰定義的標準，后續的數據分析就會缺乏一個業務認可的因變量Y。在缺乏因變量Y的前提下做的任何數據分析，都不可避免地需要太多主觀介入，進而很容易產生糾紛。這么復雜的一個過程，沒有唯一正確答案，這恐怕是任何數據建模比賽都無法模擬的。

（2）數據分析與建模

一旦業務問題被定義為數據可分析問題，它的核心業務訴求就清晰明了了，這構成了因變量Y。此外，相關的業務知識被頭腦風暴，就構成了解釋性變量X。從Y、X出發，人們可以嘗試各種經典的回歸分析模型、機器學習模型。而這一步因為Y和X都定義清晰了，所以非常適合做各種數據建模比賽。

（3）數據業務實施

數據分析與建模完成了，接下來，需要把這些成果轉化成為一個在商業環境中可以被實施的產品。這一步非常艱難，各種數據科學比賽經常喜歡考慮，如個性化推薦類型的預測問題。此類問題的業務實施方案是清晰定義的，經驗積累非常充足。

但是，事實上在更多的業務場景中，即使模型做得很好，但是最后如何同業務結合，變成可執行的產品，是非常不清晰的，極具挑戰。這里涉及企業資源、政策法規等眾多問題。例如，國外的業務經驗表明，基于車聯網數據的UBI保險產品是一個不錯的商業模型。但是，在我國由于有不同的政策環境、市場環境和消費者習慣，因此，時至今日，也沒有在市場上看到一款真正的UBI保險產品。這里的主要困難就是數據業務實施。因此這么復雜的事情，不是任何數據建模比賽可以模擬的。

簡單總結一下，數據業務化的核心是讓數據產生價值。為此，需要三個環節：

1）將業務問題定義為數據可分析問題。

2）對數據可分析問題做分析建模。

3）對最后的分析結果和模型進行業務實施。

以Kaggle為代表的一大類優秀的數據建模比賽能夠對2）提供很大的幫助，但是，對1）和3）幫助甚微，最具挑戰、最有價值的恰恰是1）和3）。