編輯導語：業務的變更，會影響到我們的業務架構。那么，在面對業務大的調整的時候，我們的架構該怎么調整？本文作者從業務視角，分析應該如何應付業務模式變更，希望能給你帶來幫助。

我們在遇到業務變化的時候，一定想過一個問題：系統能不能少改，或者不改，來滿足業務需求?；蛘咴诿鎸I務大的調整的時候，我們都會問：這個影響架構么？架構要怎么調整？

如果業務調整如“汽車金融兩種數字化業務模式創新”文中所說：我們業務模式需要變更，有更多的合作方提供價值支持；有更多種類的細分客戶，需要我們從不同渠道服務，我們怎么來應對？

既然是業務的變更，首先受到影響的一定是我們的業務架構，本文中，我們先拋開技術架構，單聊業務架構，一起從業務視角，來看看，我們能做些什么。

一、什么是業務架構

既然談到了業務架構，先看看什么是業務架構。

業務架構是把企業的業務戰略轉化為日常運作的渠道，業務戰略決定業務架構，它包括業務的運營模式、流程體系、組織結構、地域分布等內容。

業務架構在不同角色視角中的定義不盡相同，包含的內容也比較廣泛。而本文中所指的業務架構，更多的是指如何將戰略拆解到系統實踐中，而這里的實踐并不是說采用什么技術棧，什么架構模型，這里是從戰略，拆解到業務，再細分到業務模塊和業務服務。到了這種顆粒度之后，技術如何支持將會變得相對明朗可見了。

二、汽車金融面臨的挑戰

業務架構從來都不是獨立存在的。

曾經有個客戶問我：我希望嘗試新的東西，做出一些改變，但是我有時候不知道為什么要做這種改變，或者改變能帶給我什么。

這樣的問題，其實很常見，現有的傳統企業中，業務和技術往往是分開的。業務會定義大的方向和戰略，技術也會有自己的技術目標，但兩者怎么結合？業務的戰略目標如何實現？技術的目標如何體現業務價值。搭在中間的，是一個拆解和匹配，而業務架構就架在了這兩者之間。

我們再來看看汽車金融面臨的問題，現如今，傳統汽車金融需要考慮：如何支持直銷業務流，如何支持多前端觸點的趨勢，如何應對多業務場景流程并行，如何快速調整我們的系統支持業務的多變？而問題存在于當下，同時也涉及到未來。

1. 業務模式的變化與細分

業務模式從傳統的經銷商模式，逐步向直銷傾斜的時候，我們的業務和系統需要做雙向支持，一方面，經銷商屬于專業人員，提供專業精準支持；另一方面，直銷面對的普通客戶，不具備專業知識，需要提供便捷易懂的服務。

而隨著業務的成熟，業務劃分也越來越精細，包括新車，二手車，展車，公司車，網約車。也包括乘用車、輕卡、重卡等。

顯然，我們無法針對每一個細分做一套流程系統。當然，也不會為了應對新的模式新打造一套系統。

2. 觸點的多樣性

從經銷商來講，越來越靈活的服務方式已經不再局限在桌面辦公，從網頁端會慢慢地過渡到手機端，但這并不代表著網頁端會廢棄不用，我們就面臨著多端支持。

同時支持直銷的C端，支持客戶自己完成，為了提供便利，我們根據業務的訴求和客戶的場景細分，也許會支持客戶的APP、小程序、公眾號、網頁端等方式。

當然，每增加一個渠道以及觸點前端，都不會用單獨的系統和流程支持。

三、以不變應萬變的業務架構

面對上文中提及的變化誘因和可能性，或者現在為了快速迎接不遠的未來挑戰，在我們構建，或者改善系統的時候，要如何應對。正如我們的共識，不會為每一個新增做全新構建，因此就要求我們的系統有足夠的靈活性。

說到了靈活性，我們就需要提一提很火的名詞：服務化。所謂的服務化是指把一個大型系統中的各個業務進行抽象以后，以服務為單位進行開發和管理的方法。因此，我們看到重點在抽象，和以服務為單位上。

1. 業務抽象

正如我們所說，汽車金融的業務場景有多種細分，而我們又無法針對每一個內容進行流程獨立開發，因此就需要針對這些內容進行業務抽象。這就要求我們能夠將所有的業務內容進行梳理，在這個過程中，我們不去想怎么合并，不去想怎么構建，只做一件事情——梳理。這個過程是一個尋找問題的過程，只有問題清晰了，解決方法才有的放矢。

而梳理的過程需要我們將所有的業務以及對應的上下游理清楚，從購買流程，到邊緣場景，事無巨細的流程都展現出來。

在這之后，將每一個流程中涉及到的問題歸納到一起，成為我們的“抽象”，例如下圖中的內容，抽象出來的結果看上去所有的業務流都或多或少的會涉及其中的幾個或者所有“抽象”。

2. 業務架構

架構的關系其實就是在表達一種關系，從左到右（上下游關系）或者從上到下（架構層級關系），按照我們通常的理解，上下關系中，越往下越抽象越基礎。

借用軟件架構中的三層架構，三層架構的特點：高內聚低耦合，也恰恰符合了我們對于業務架構的期待，因此我們復用到業務架構中來。

對比三層架構：

• 表現層，相當于觸點渠道，真正的觸達用戶
• 業務邏輯層，服務于特有的業務場景，和功能，相當于特有模塊，只有特定場景和內容才會使用的內容
• 數據訪問層，相當于共有能力，每一個業務邏輯都離不開數據支持，等同于業務中的共享模塊，而共享模塊并沒有數據那么底層，還是在說業務邏輯，只不過這個業務邏輯會更通用

將我們識別出來的“抽象”對應到這三層是什么樣的呢？舉個例子來講：

• 前臺觸點：我們可以有H5頁面，小程序，網頁，APP等等方式接觸客戶，同時也有需要我們提供服務的合作方?？梢允亲苑盏姆绞?，也可以是經銷商渠道的方式。
• 特有模塊：我們看到申請和激活過程屬于貸前特有，而合同和日常服務屬于貸后特有。當然，我們可以有別的劃分方式，比如說根據上面說的車輛劃分新車二手車，輕卡重卡等等。特有模塊的劃分方式不同，模塊能力的組別劃分也會隨之改變。
• 共享模塊：抽離我們的實際業務細分和車輛細分，公用的部分，比如說客戶和線索，比如說文檔報報表等，都屬于可以剝離特有業務場景獨立使用的能力。

這樣的業務架構，可以更好地支持我們的現有業務，能做到資源的最大化利用而避免了重復建設。對于未來，也同樣，可以很好地支持。

3. 靈活應變

對于未來業務模式的改變以及客戶需求的改變，我們的業務架構也能夠做到支持，當然靈活的調整是必然的。當我們新增了業務場景或者特有模塊場景的時候，有些特有模塊就會同時被新增場景使用，逐漸就會變成共有模塊。當然，當我們做了業務調整，減少了特定場景之后，共有模塊也有可能調整到特有模塊中去。

同樣，前臺觸點也會隨著我們的業務調整進行適當的改變，每一個前臺觸點，會影響業務流和業務場景，因此也會間接的影響我們的模塊分類。

當我們的“抽象”具備了高內聚低耦合的特征之后，調整就是基于“抽象”之間的，對于“抽象”本身，我們就可以在短時間內不做過多的關注了。而這個“抽象”就是我們識別出的能力，就是我們說的模塊

寫在最后，當我們的模塊足夠的獨立的時候，每一個模塊專注于自己的能力，不受前臺觸點的操作影響，單純的新增觸點或者業務流順序調整，模塊將不會受到影響。當然，沒有任何一個結構能一直適用于各種潮流，我們能做的只能是盡量靈活適配，或者小步調整，支持未來的無限可能。

#專欄作家#

兔小吱，公眾號：冬眠小記，人人都是產品經理專欄作家。探索數字化轉型。

本文原創發布于人人都是產品經理。未經許禁止載。

題圖來自Unsplash，基于CC0協議。