前面的文章中我們分析了企業戰略、理清了組織結構，是不是就該進入業務分析了呢？先別急，業務分析，特別是對於具有多個不同業務線的企業而言，是一種垂直式的分析，如果直接開始業務分析，那就走上了豎井式開發的老路，就算有共同的戰略目標，也未必建得出企業級的業務架構和業務系統來。業務架構強調的是橫向視角，強調通觀整個企業的生產過程，因此，展開垂直的業務分析之前，我們必須先確立一個統一的業務分析框架做爲觀察各個業務線的統一方法，這樣才能將企業需要的業務能力進行分類彙集，產生合理的組件結構。
價值鏈分析
我們首先講一下這個用來做橫向分析的方法，通常管理學上分析企業競爭力多是使用價值鏈模型。價值鏈(value chain)概念首先由邁克爾·波特(Michael E.Porter)於1985年提出。最初，波特所指的價值鏈主要是指針對垂直一體化公司的，強調單個企業的競爭優勢。隨着國際外包業務的開展，波特於1998年進一步提出了價值體系(value system)的概念，將研究視角擴展到不同的公司之間，這與後來出現的全球價值鏈(global value chain)概念有一定的共通之處。之後，寇伽特(Kogut)也提出了價值鏈的概念，他的觀點比波特的觀點更能反映價值鏈的垂直分離和全球空間再配置之間的關係。2001年，格里芬在分析全球範圍內國際分工與產業聯繫問題時，提出了全球價值鏈概念。全球價值鏈概念提供了一種基於網絡、用來分析國際性生產的地理和組織特徵的分析方法，揭示了全球產業的動態性特徵。具體採用哪一種價值鏈模型，要看企業的實際需要，比如，是否更關注上下游關係等。這種模型的建立往往不是企業自身能簡單搞定的，可能需要一定的諮詢或者學習過程。波特價值鏈如下圖所示：
價值鏈主要包括基本活動和支持性活動，基本活動是主要生產過程，支持性活動則是對基本活動起輔助作用及維持企業基本運轉的各類活動。實際使用中不必完全一模一樣的照搬，因爲波特價值鏈一看就知道偏重製造業，偏重生產類型的企業，對於服務業而言就需要適當變形，其實，價值鏈主要描述的是企業的價值創造過程，引入價值鏈分析主要是爲企業橫向審視自身業務能力提供分析框架，因此，價值鏈如何設計，完全是可以個性化的，只要確認好能夠符合企業特點，覆蓋其價值創造過程即可。
業務領域設計
做好這一“橫”之後，我們就可以畫出多個“豎”了。科學地講，業務領域的劃分取決於企業的戰略和價值定位，企就是業打算爲什麼類型的客戶提供什麼類型的服務或產品，比如，銀行爲個人客戶提供金融服務，就產生了個人金融業務線，這裏邊存款、貸款、金融市場、非金融服務等等，會有一大堆東西，而如果覺得這樣劃分依然太粗，那麼很有可能私人銀行這類高端客戶服務就會獨立出來，爲其設計的一些業務功能聚類成的業務組件可能不會爲普通客戶提供服務。劃分領域其實可以有兩種方式，從客戶出發和從產品出發，選擇哪一種，要看企業的特點以及企業更關注什麼。還以銀行業爲例，銀行業有不少產品是同時適用於個人和企業客戶的，因此，從客戶出發，很多產品會交叉；而從產品出發，會避免這一問題，畢竟業務系統的設計多數還是以產品爲主線的，但要注意，這裏指的不是具體的某一個產品，而是一組同類產品的集合，比如存款、貸款、託管、資管、投行等。選好維度之後，就有了橫軸——價值鏈和縱軸——業務領域兩個維度，接下來就可以去分析業務流程了。
業務流程分析
業務流程的分析實際上就是將一個業務領域中的所有業務處理過程按照價值鏈約定的分解方式分解，形成每一個價值鏈環節中的一個或者多個工作流，具體每一個工作流程的設計可以採用常見的VISIO設計工具，可以遵循BPMN語法標準，也可以採用其他製作工作流的語法標準，但是要注意，必須整個企業統一採用一種，不然是沒法整合的。以BPMN語法爲例，一個工作流在BPMN語法中稱爲一個活動，每個活動可能會有多個不同的角色共同參與，具體涉及到哪些角色就又涉及到企業的組織結構了。每個角色在活動中承擔的職責稱爲任務，其實工作流分析重點在任務，活動的範圍並不那麼嚴格，甚至不是非常重要，活動之間在BPMN語法中是可以靠事件串接起來的，既然能夠串接，那麼範圍或者說流程圖的長度就不是特別重要。我們甚至可以把一個業務領域中不同價值鏈環節下的所有活動都連接成一個特別複雜的活動，只不過這樣可讀性會非常差。所以，操作上，還是建議活動儘可能在每個價值鏈的範圍內，而每個價值鏈內有多少個活動，可以自由些，可以多參照對業務場景的劃分。業務流程的分析重點在任務，因爲任務在後續設計中對功能、組件內部結構的影響比較大，這個後邊章節還會陸續介紹。一個常見的BPMN工作流如下：
綜上，業務領域其實是企業確定以某類產品服務某類客戶的一個業務範圍，在建模上，它表現爲，爲實現這一價值定位，企業在整個價值鏈上的各種業務活動的有機結合，一個業務領域實際上就是由一組業務活動構成的，通過活動中的角色和任務，體現了所有參與到價值創造過程中的組織單元的分工協作關係。
要注意的是，這一階段完成的模型通常是不夠準確的，因爲還沒有經過“精煉”的過程，其對企業級設計的貢獻還只是個開始。業務領域及流程的分析中，還有一點要強調的是，別在忙於細節時忘了大方向，業務架構設計是從企業戰略開始的，那麼做到業務領域分析時，要時刻提醒自己，業務領域內的活動是否能夠有力地支持戰略的實現，是否能夠有效地服務客戶，是否能夠有效地應對行業競爭，也就是先進性的衡量，把這三個問題如同曾子三問一樣看待，“日叄省乎己，則知明而行無過矣”。
上一章概述了業務流程建模的過程，流程建模其實“一言難盡”，需要不斷的練習、摸索，自己總結套路，也就是之前說過的，模型質量嚴重依賴建模者的經驗。軟件設計主要研究的是行爲和數據，流程模型分析了行爲，數據模型當然就是要分析數據。數據模型在很多系統分析、軟件工程的教材上都有介紹，所以我不去贅述三範式之類的數據建模規則，而是從企業級數據模型、業務模型與數據模型協作關係的角度，講講數據模型。
企業級數據模型
提起數據模型大家可能第一反應都是ER圖，實體關係圖是我們做關係型數據庫設計的基礎。實體圖是按照對業務對象的劃分，將數據屬性按照實體聚類，並描述實體間的關係，從而指導程序設計和數據庫設計。我們通常做ER圖是面向單個系統構建的，而要構建企業級數據模型時，就需要橫向分析所有業務領域的ER圖，所以，我們也需要以一種總體結構先建立分析框架，比如金融類企業常用的FSDM(financial services data model)，它是IBM的一個企業級數據模型，囊括了銀行約80%的業務數據。FSDM將數據分爲九大類，分別是參與人、合約、條件、產品、分類、時間、資源向、位置、業務方向，具體定義如下：
| 分類名稱 | 簡稱 | 定義 |
|---|---|---|
| 關係人 | IP | 銀行的業務開展過程中的相關各方，個人、機構、櫃員。。 |
| 合約 | AR | 參與者之間達成的 合約、合同、協議等 |
| 條件 | CD | 描述銀行的業務正常開展，所需要的前提條件、資格標準和要求 |
| 產品 | PD | 產品是爲客戶所提供，以換取利潤的產品和服務，產品也包括合作伙伴或競爭對手的產品和服務，是金融機構銷售或提供的可市場化的產品、組合產品和服務。 |
| 地點 | LO | 參與人相關的所有地址，如家庭地址、公司地址、郵政信箱、電話號碼、電子地址、網址等或地理位置區域。 |
| 分類 | CL | 適用於其它數據概念的分類或者分組。 |
| 業務方向 | BD | 銀行或參與人開展業務所在的環境和方式 |
| 事件 | EV | 是參與人和銀行的交互，以及銀行內部的業務交互，它包含最詳細的行爲和交易數據，例如存款、提款、付款、信用/借記卡年費、利息和費用、投訴、查詢、網上交易等。 |
| 資源項目 | RI | 是銀行有形或無形的有價值資源項目，是銀行擁有，管理，使用的，或支持特定業務目的的． |
通過這個框架可以將數據實體、數據屬性進行歸類，形成統一的企業級邏輯模型。做爲企業級模型，數據實體和屬性都要保證唯一，這一點在建模中好說，通過工具篩查就可以比較出名稱、定義、取值重複的數據項，從而保證數據唯一性。但是重點在於生產階段的管控，而非建模階段。生產階段要通過數據管控平臺或工具對數據字典進行嚴格管理，沒有進數據字典的數據項，無法生成企業唯一的數據項ID，無法在設計時被使用，從而達到嚴防死守一般的控制，雖然也讓生產上一頓抱怨，但這個方法很有效。企業級數據模型說起來容易，做起來難，要首先對業務數據進行全面建模，再對生產進行嚴格管理，並對歷史數據進行處理。本人原所在單位經歷了兩年多的努力，成爲行業內首家真正建成企業級數據模型、真正實現企業級數據管控的大型金融機構。
與流程模型的配合
流程模型與數據模型是描述業務需求的一對兒“難兄難弟”，流程模型表達的是“處理”，數據模型表達的是“輸入”和“輸出”，合起來就是計算機的基本工作流。數據模型和流程模型的組合，可以清楚的描述出，什麼樣的事件或條件可以觸發一組業務活動，業務活動需要的輸入有哪些，經過業務流程的處理，輸出又有哪些。如果將該業務系統化，就成爲實現業務活動的計算機程序是在什麼樣的場景（事件）下開始執行，程序需要讀取哪些數據（實體），依據什麼樣的順序（活動）、規則（任務）由誰（組織、角色）執行，執行之後產生哪些數據（實體）。任務會直接處理數據，而這種處理通常分爲增加、修改、刪除、查詢四類。
一個業務領域是由一組活動構成的，而這些活動分佈在價值鏈的不同環節，如果粗糙地劃分業務組件，則將每一個價值鏈環節設爲一個業務組件也未嘗不可，不過這樣未免太“偷懶”，對於業務複雜的大型企業而言，組件的內聚性會很差，所以我們需要更爲精細的劃分。數據模型都有主題域這個層級，就是將關係較近的數據實體聚合成一個分類，這種關係我們可以給出一個主題名稱，比如，當按照產品劃分主題時，FSDM中產品分類下就可以建立一個“存款”主題域，將存款業務相關的數據實體放入其中，並使用ER圖的方式表達。
在軟件設計上，是可以考慮將關係較近的數據實體聚在一起，按照行爲接近數據的原則，再將相應的功能聚合成一個組件。結合業務模型，就可以將與主題域中與實體相關的任務聚在一起構成業務組件。聚類過程中要注意：
- 數據主題域中的數據實體可能存在引用其他主題域數據實體的情況，這種情況下，在進行任務聚類時不會考慮此類數據實體，因爲它們應當由其所在的數據主題域相關的組件創建，以保證在企業級業務系統中，數據生成職責的唯一性，這是應用企業級數據模型時非常重要的一點。
- 與數據實體相關的任務主要指對數據實體進行新增、修改、刪除的任務，對同一數據實體進行新增、修改、刪除操作的任務應當歸屬同一組件。只有這些任務具有數據的寫權限，其他任務只具有讀權限，這也是保證企業級數據一致性的重要措施。
上述原則會在一定程度上影響任務邊界的劃分，是否需要因爲在任務中要表達對不同主題域數據實體的寫操作，就需要將任務切分開，或者直接複用其他組件中已有的對該數據實體進行寫操作的任務？表達上，當然切分開或複用任務最好，甚至可能複用活動，但是實際建模過程中則要具體問題具體分析了，這一方面是建模的問題，但另一方面其實也是應用模型過程中很重要的一個環節——解讀模型的問題，如果兩者比較統一，那模型具體長成什麼樣子就不必太糾結了。所以，該如何處理，同時取決於這兩方面的情況，考驗的是“統一語言”是否真的建立了。
熟悉DDD的朋友可能會問，任務與實體的關聯主要基於對實體的增刪改，這不是有點兒“貧血模型”的意味嗎？其實不然，流程對數據的更豐富的處理規則其實可以包含在任務的描述中，從而擺脫“貧血模型”的問題。
企業級數據模型與企業級流程模型相互支持，而其中最重要的概念都是企業級，企業級在操作層面上，說到底是個標準化問題，我們將在下一講闡述這個問題。
相關文章：
中臺之上（一）：重視業務架構，不要讓“業務的歸業務、技術的歸技術”
中臺之上（二）：爲什麼業務架構存在 20 多年，技術人員還覺得它有點虛？
中臺之上（三）：戰略和組織結構，業務架構設計中不應被忽視的關鍵因素
作者介紹：付曉巖，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計。公衆號：曉談巖說。