分享：如何為一個商業銀行設計業務架構？

從實際操作的角度講，企業級業務架構設計及其建模過程是一個充滿可能性和爭議的過程，並沒有一個直觀的量化標準能夠用於判斷一個架構方案的好壞，我們可以透過一個虛擬的例子體會一下。

假定我們為 A 商業銀行設計企業級業務架構，為了集中感受元件和標準化的過程，我們跳過戰略分析，不匯入更多目標，比較單純地從簡化的現狀入手，推導可能的目標架構。

價值鏈設計

假定只分析存款和貸款這兩個大家耳熟能詳、無論做沒做過銀行系統都能基本瞭解的業務，並且假定產品只面向對公客戶。首先派出我們的架構設計團隊，設計團隊的組成人員最好是具有豐富專案設計、實施經驗的人員（能拉上開發人員更好），瞭解業務分析、資料分析、架構設計，由他們與業務人員（或者叫需求方）共同組成工作團隊。團隊搭好後，按照套路，既然做企業級，就先設計那一“橫”——價值鏈，我們先暫定 A 行價值鏈由五個環節組成：產品設計、客戶營銷、運營管理、風險控制、統計分析五大環節，產品設計主要指金融產品上市前的設計過程，包括分析客戶需求、開發系統、配置引數等；客戶營銷則包括客戶資訊管理、細分客戶、銷售產品、簽訂合約等；運營管理一般指需要後臺集中處理的業務或者配送服務；風險控制是銀行業務的重點領域，通常考慮各類風控模型的設計、風險檢視的構建等；統計分析是指各類報表，包括業務報表、分析、監管報表等。這五個環節基本可以構成金融產品從設計到銷售再到售後管理的完整過程。從這五部分的定義可以看出，價值鏈側重於劃定業務環節並分析環節包括的業務能力。由於是虛擬案例，我們只考慮前兩個環節的簡化分析，不對整個價值鏈做展開。

存款領域的模型設計

設計了價值鏈，我們就先開始分析存款領域。先來看下存款領域的“產品設計”環節，我們可以將這個過程起名為“設計上架產品”，定義為一個活動，其大致流程可以如下圖：

​

​

圖一 存款領域產品設計流程圖

在這個活動中由三個角色：產品經理、IT 人員、業務人員；三個角色分別有三個任務：設計產品、實現產品、上架產品。產品經理負責分析產品需求，設計並運用產品模板為業務部門整理業務需求，並提交給 IT 人員去開發。這個崗位在不少銀行的開發團隊中是需求分析崗，但某宇宙行確實具有此類崗位。產品經理設計好產品模板之後交給開發團隊，由於實現產品的過程是個複雜的開發過程，因此，在業務模型中可以用一個虛擬的任務代表。開發完成後，業務人員新增關於產品的基本資訊、標籤資訊等，做上架前的最後配置，配置完成後就成為了一個待售產品，可以隨時出售。這個活動中，我們主要關注產品需求、產品模板、待售產品這三個實體，前兩個由任務“設計產品”建立，最後一個由任務“上架產品”建立。

之後，進入“客戶營銷”環節。營銷中我們通常一定會遇到“獲取新客戶”、“維護老客戶”、“存款”這三個活動，第一個活動當然是面向銀行剛剛挖門子盜洞搶來的新客戶，第二個活動則是已有的存量客戶資訊發生了變動，第三就是營銷的目的了——拉存款。這三個活動簡要情況如下：

圖二 獲取新客戶、維護老客戶、存款的簡要流程

對公客戶資訊在銀行，尤其是規模較大的銀行中通常是由管戶的客戶經理負責錄入，一般也無需稽核，自己搞定。客戶資訊發生了變動自然要維護，比如聯絡資訊。這兩個活動都可以只包含一個任務，至於是否是分成兩個活動，其實取決於建模習慣，當然，合併成一個活動就需要更改活動的定義和範圍了，畢竟這兩個活動中的任務都是在圍繞同一個實體做文章，“錄入客戶資訊”是建立“客戶資訊”實體，“維護客戶資訊”是變更“客戶資訊”實體。客戶資訊建好以後，就進入業務辦理過程。客戶到會計櫃檯去開立對公存款賬戶，開戶是個麻煩的過程，要審一堆證件，不過這裡我們略過這些內容，僅關注“開立賬戶”任務對“賬戶資訊”實體的建立。完成賬戶開立後，就是存入存款了，其實客戶無論是存活期還是存定期，都是跟銀行建立了一個“存款合約”，代表了一種債權債務關係，而合約主要記錄的要素其實來自我們在上一個環節中建立的“待售產品”。因此，“存入款項”這個任務讀取了“待售產品”實體，將其例項化建立了“存款合約”、“賬戶變動”這兩個實體，由於餘額的變化，該任務還變更了“賬戶資訊”實體。

以上這兩個價值鏈環節的分析雖然簡單，但也包括銀行業務的基本過程：設計金融產品、營銷客戶、銷售產品。由於是企業級設計，我們可以先不急著分析元件結構，可以再分析下貸款領域再做決定。

貸款領域的模型設計

先來看貸款領域的產品設計，其實，從產品設計的抽象流程來看，兩者過程上並沒有太大差別，從產品模型的角度，是產品結構和引數項的差別；而從開發視角，則是功能上的差異。因此，從業務模型的角度，二者在設計階段可以共用一套模型：

圖三 貸款產品設計流程

這實際上表示，當把開發過程剝離出去時，負責產品設計的元件可以是企業級的。

接下來進入“客戶營銷”環節，可以理解，“獲取新客戶”、“維護老客戶”也是一樣的過程，區別在於銷售產品：

圖四 獲取新客戶、維護老客戶、貸款的簡要流程

讓客戶簽訂貸款合約是我們的“終極目標”，但是貸款不同關於存款，客戶要提供一定的保證，保證通常有抵押、質押、擔保等形式，對公客戶中，非常優質的客戶也可以採用信用貸款的形式，不提供任何保證。本例我們假定是由其他客戶為該客戶提供了擔保，在貸款合約之外簽訂了附屬合約——擔保合約，合約中記錄了擔保人資訊、擔保比例等。對公貸款通常是簽訂貸款合約之後再開立貸款賬戶，然後才是發放貸款。資料實體就不再一一介紹。

跨領域的標準化

如果不搞企業級，就是豎井式開發，那這樣兩套業務模型就可以分別使用了，各自構建一個業務系統；但是搞企業級，就需要一起分析了。

對於“產品設計”環節，我們之前已經分析了，可以放在一起，這樣就可以有一個“產品管理”主題域，包含“產品需求”、“產品模板”、“待售產品”三個實體；處理這三個實體的是“設計產品”、“上架產品”這兩個任務，後者可以聚合成“產品管理”元件。這樣我們就根據資料關係的緊密程度將與之相連的任務設計成了元件，這個元件的定義和範圍就是對這些任務和實體的概括性描述。按此類推，“客戶營銷”環節中“客戶資訊”實體可以構成“客戶”主題域，而“錄入客戶資訊”、“維護客戶資訊”則可以聚合成“客戶資訊管理”元件。再往下就到了相對複雜的業務部分，這裡我們有兩個問題要考慮，一是，擔保合約中的擔保人資訊與客戶資訊非常類似，而且維護需求也類似，而且這種維護可能會不必要地造成擔保合約的變化，因此可以考慮將其從擔保合約中剝離，但是直接交給客戶資訊實體處理在概念上又不合適，因此，可以增加一個“角色資訊”實體，專門記錄客戶在銀行中不同業務領域可能承擔的不同角色，但是這樣原來的“客戶資訊”實體再叫客戶資訊也不太合適，所以我們可以在抽象程度上上升一格，將其改為“參與人資訊”，這個實體應當是一個“客戶”在銀行有且僅有一個，並且是與業務無關的，其在各種業務中承擔的角色由“角色資訊”實體記錄，這樣也有利為“客戶”構建更完整的全景檢視。一個比較容易理解的比喻就相當於一個初創企業的領袖——董事長兼 CEO，這種情況下，人都是這一個人，但是有兩個不同的身份、不同的職責，所以，把他本人定義為“參與人”，而把他擔任的兩個不同職務定義為“角色”，沒準兒哪天他又兼任了 CTO，我們都可以很方便從他本人的資訊出發，看到“角色”實體記錄了哪些角色，而不用把董事長、CEO、CTO 的個人資訊拿過來比較看是不是一個人。當然，這種抽象不是一層不變的，取決於實際需要和系統建設目標。最佳化後如下：

圖五 最佳化後的獲取新客戶、維護老客戶、貸款流程圖

第二個問題是工作流的順序，存款開戶在前，簽約在後，貸款則相反。從實際業務中考慮，首次開戶時，開戶和存入款項的順序一定是開戶在前，貸款實際上也是開戶在前，涉及記賬的放款在後；除去首次開戶外，都是利用已有賬戶存錢或放款，並不需要考慮開戶問題，因此，不考慮合約時，兩個領域間的流程也是可以整合的。那麼引入合約之後呢？其實這就遇到了企業級設計很常見的一類問題，涉及跨領域整合時，流程可以調整嗎？這不是指建模能不能改，圖上當然很容易，但是實際業務能不能改？願不願意改？有的時候大家會覺得，既然都決定做企業級了，那不是有了尚方寶劍了，實際工作還真未必，想想之前舉的綜合積分的例子，如果搞不定利益分配，企業級也不是那麼容易做到。回到當前的例子，我們可以設想，把存款合約部分從“存入款項”任務中分離出來，考慮建立一個簽訂存款合約的任務，實際執行過程中其實客戶還是無感的，畢竟無論開戶在前還是簽訂存款合約在前，客戶都是提交了申請之後就在櫃檯前邊等著，是櫃員在裡邊操作；那麼對櫃員而言呢？如果是賬戶開立在前，那就意味著不管客戶存活期還是存定期，都是先稽核開戶資料，再選擇存款產品。如果簽訂存款合約在前，那就是客戶先選擇存款產品，建立合約資訊，如果系統發現客戶沒開戶，那就彈出開立賬戶介面，或者存款簽約介面中直接嵌入開立賬戶功能，如果客戶沒有賬戶，展開這項功能；如果有賬戶，這部分就不展開。也就是說，其實也可以調整流程，那麼存款流程就跟貸款流程很類似了，具體的流程圖我們就不再畫了。

元件設計

根據上述過程，我們在可以把資料實體“貸款合約”、“存款合約”、“擔保合約”都放在“合約”主題域下，而與之相關的“簽訂存款合約”、“簽訂貸款合約”任務聚合成“合約管理”元件；資料實體“賬戶資訊”、“賬戶變動”放在“賬戶”主題域下，而與之相關的“開立賬戶”、“存入款項”、“發放貸款”任務可以聚合成“賬戶管理”元件。業務架構設計如下：

這只是一種設計方式，也可以根據客戶實際需要等其他因素變更設計。比如，將“存入款項”和“發放貸款”中的記賬動作分離出來，增加一個“記錄賬務”的任務，這樣“存入款項”和“發放貸款”將更加關注流程，也就是“交易”，而“記錄賬務”會更加關注記賬，於是賬戶管理元件中就會變成“記錄賬務”、“開立賬戶”兩個任務，而在合約管理元件中填入“存入款項”和“發放貸款”，延長了合約管理的範圍；進一步，如果並不關注企業級合約管理，更關注的是產品級的合約管理，則可以將合約管理元件拆分成存款和貸款兩個元件，存款元件下放入“簽訂存款合約”、“存入款項”，貸款元件下放入“簽訂貸款合約”、“發放貸款”兩個任務。可見，根據關注點、設計思路的不同，架構設計也會有變化，並沒有絕對的對錯之分。此外，上述劃分產生的元件，是不是也有“中臺”的意思呢？我們可以清楚地看到一個用於今後中臺沉降過程的起點。

總結

本節的例子是為了說明問題而虛擬的例子，實際業務場景比例子中複雜的多，但是透過這個簡單的模擬，我們可以意識到：

業務架構設計並沒有簡單的衡量標準；

設計思路和關注點對架構方案有很直接的影響；

架構設計需要迭代和反覆，雖然我們不情願，但是實際操作中是難免的；

基於上一點，架構師經驗很重要，可以減少反覆，尤其是關鍵設計的反覆。

架構設計是一個不斷精煉和確認的過程，因此，需要架構人員、技術人員在設計過程中努力“培養”客戶，這是一個深度融合的過程，而且上述設計思路對於業務人員日常分析自己的工作環境、設計工作方案、改進工作流程都有幫助，是一個可以跨出 IT 邊界的工作方法，對於這一個過程的投入，是雙贏的。