業務架構的起點：解讀企業戰略
業務架構最大的特點就是要從企業整體視角出發思考問題，要有居高臨下的俯視視角，時刻有一張企業整體的業務能力地圖印在腦子裏，而企業的業務能力是服務於業務目標的，業務目標有不同的層次，高級管理者、中層管理者、操作層都有不同的目標訴求，但是所有的目標都會聚焦在最高層次的企業目標——企業戰略上，所以，企業戰略也就自然成爲了企業級業務架構設計的起點和檢驗標準。
企業戰略聽起來是一個非常“高大上”的詞彙，也有人會覺得企業戰略有點兒畫大餅的嫌疑。其實企業戰略沒有那麼神祕，也不是非得智商180的人中龍鳳才配談起，企業無論大小，都有自己的目標、路線、方法，企業戰略就是對這些內容的提升性描述。隨着研究的不斷深入，企業戰略也有了更加豐富的內容和種類，但是說到底，企業戰略仍是企業爲達成某項目標而確定的過程與方法。關於企業戰略的各類資料已經浩如煙海，我也無意在這裏喧賓奪主、浪費時間，我還是介紹一個設計企業戰略或者說分解戰略目標的有效方法，畢竟從目標出發引導出業務架構設計纔是我們關心的內容。
蓋個房子
我介紹一個很容易掌握的企業戰略設計模型，該模型應該是由BMGovernance公司設計的，模型如下圖所示：
該模型從企業願景、使命這種相對宏觀的概念入手，向下分解出可度量的目標，這三部分做爲“屋頂”，描述的是企業爲自身發展所設定的目標和成功的標準，無法衡量的目標只能是個精神口號，不能被轉化爲行動。這不是說不能喊口號，而是這個口號必須能夠被分解成可以指揮行動的具體度量，比如，願景定義爲“讓全世界都使用清潔能源”，使命就是 “逐步使用風電、太陽能、水電等能源取代具有污染及潛在污染可能性的火電、核電等能源”，那目標自然就是“清潔能源使用量佔世界能源使用量的百分之百”。衡量起來也容易，看統計數據就行了。
無論是世界級企業給自己定下的改變全人類的宏大誓願，還是小企業只盼明天還能夠生存的小夢想，都必須要“量化”出來，成爲可執行的目標。這一點是業務架構設計人員在設計企業戰略時必須特別注意的，千萬不要把戰略只當口號，漂亮就行，而是要能夠做爲一個參天大樹的根，可以堅實地向上生長、開枝散葉。
願景、使命、目標這三個經常被大家詬病爲“假、大、空”的戰略元素在一個可靠的業務架構設計中，被如何強調都不過分，因爲它是“屋頂”，搞錯了，就成了“上樑不正下樑歪”，所以務必與企業的管理者溝通清楚，務必讓所有參與方都達成一致認識。這是項目中最高層級的概念一致性，絕對不能“輸在起跑線上”。不少技術人員不重視企業戰略，認爲跟開發人員無關，這是大錯特錯，如果一個企業的戰略會讓員工覺得跟自己無關，那隻能說明這個戰略本身以及對戰略宣導的失敗。不落實到流程中的戰略是無法被執行的戰略，而跟戰略落地無關的流程到底是在幹什麼呢？創造的是什麼價值呢？爲這樣的流程開發的系統又是在幹什麼呢？如果一個企業花了幾百萬、上千萬開發的業務系統，其設計人員連企業的戰略都不知道，那這個系統能支持企業的發展嗎？業務與技術的融合就更無從談起了。
屋頂之下左側是戰略、右側是戰略能力。戰略是爲了完成上邊提到得目標所需要採取的路線、方法，這類似於銀行的分行每年爲了完成總行下派的經營指標所制定的各種經營策略，比如大力挖潛，激活存量客戶。戰略能力則是爲了完成這一策略需要的能力，比如爲了採取激活存量客戶的行動，需要的客戶分析、營銷組織、渠道應用、業務處理、合作伙伴管理等。
再下一層級就涉及到了具體工作，左側表述的是爲實現戰略而在客戶一側採取的行動，包括渠道、客戶關係、客戶細分，實際上就是指面向哪一類客戶、在什麼渠道上、如何爲其提供服務。繼續上邊的例子，激活存量客戶要先考慮激活哪類客戶，是一般客戶還是高端客戶，不同的細分客戶需要不同的策略。現在大家都講求精準營銷，在大數據、人工智能的加持下，從“千人千面”一路飆升到“億人億面”。選擇了客羣之後就要考慮渠道類型，是通過互聯網渠道、電話渠道、手機銀行渠道、微信渠道還是櫃面服務。確定了渠道之後，還要考慮激活行動的消息如何送達客戶、如何讓客戶願意接受以及相應的售後服務，這些屬於客戶關係範疇。
左側最下邊的是收入，也就是說上述行動成功後，應當產生預期的收入。右側對應的三個方塊則是在企業內部還需要採取的行動，關鍵活動是支持激活客戶戰略所必備的業務處理過程，包括交易流程、積分規則調整流程、積分兌換流程等。
關鍵資源則是爲支持促銷戰略需要提供的資金、人員、物品、參加活動的網點等；合作伙伴則是爲了補充銀行能力的不足引入的外部力量，比如爲了激活一般客戶所提供的交易積分兌換電影票、爲了獎勵高交易量客戶提供的體檢、高爾夫球等活動，都需要與第三方合作才能辦到。右側最下邊的是成本，也就是說上述行動會帶來合理的成本支出。收入與成本的差額就是收益了，這就是對激活存量客戶策略的最終檢驗。
居中的是價值定位，企業爲什麼類型的客戶提供什麼類型的服務就是企業的價值定位，方塊左右兩邊描述的其實就是這個含義，企業的價值定位是否準確、可持續，也就是看左邊的活動產生的收入是否能覆蓋右側的活動帶來的成本，如果是，企業就能夠長期發展，如果否，企業就需要重新思考價值定位了，而這種反思很可能帶來“屋頂”的變化。
在這個模型中，大家可以看到上一講中提到的三角形也包含其中，如果說那個三角形是“大道至簡”，那這個模型就可以看作是“衍化致繁”了。
廉價沙盤
這種建模過程也是對戰略的一次“廉價”沙盤推演，能夠衡量戰略的合理性、可行性，這種分析是非常有價值的，可以避免工作的盲目性。相信大家在日常工作中都遇到過“不計成本”、“不計代價”的“強硬”需求，那麼今後大家可以試試通過這個模型對“強硬”需求做個全面的合理分析，也許能夠幫助需求方發現戰略缺陷，找到改進方法，使業務方案更符合各方的期望。否則，一個連沙盤推演都走不通的戰略如何能指導業務發展呢？更別提去爲此開發系統了。
經過之前建模大家已經能夠看到隱藏其中的業務架構了，渠道管理、客戶信息管理、客戶細分、客戶關係管理、金融產品組件、合作伙伴管理、財務覈算、績效考覈等業務能力組件已經呼之欲出，你心心念唸的“中臺”也是若隱若現，就等更爲細化的建模工作了。此外，大家也不妨思考一下，既然企業戰略沒那麼神祕，那無論對於各種規模的客戶，是不是都該鼓勵大家享受一下戰略的“樂趣”呢？
不可迴避的問題：組織對架構設計的影響
前面提到過，業務模型描述的就是企業的組織和運作過程，可見組織在業務架構中的地位。有些瞭解過業務建模或者企業級架構理念的小夥伴可能會問，既然業務架構要橫向看問題，那做企業級不是更應該要打破部門限制，實現企業級的統一嗎？是的，但那是目標，不是過程，也未必真能是結果。下面我們就來談談組織結構對業務架構設計的影響。
組織要背 “鍋”嗎？
說到組織結構對系統設計的作用，很多人都會想起“康威定律”。Melvin Conway於20世紀60年代後期確定的Conway法則告訴我們，任意一個軟件都反映出製造它的團隊的組織結構，這是因爲人們會以反映他們組織形式的方式工作。換句話說，分散的團隊可能用分散的架構生成系統。項目團隊的組織結構中的優點和弱點都將不可避免地反映在他們生成的系統中。這個規律延伸到需求方身上也一樣適用：需求方的組織結構不可避免地會影響到系統的組件結構。俗話說：“幹活兒不由東，累死白搭工”，簡直是對這個問題最直觀的解釋。
做業務模型，我之前說過，有兩個原則要注意，其中之一是整體性，設計業務架構，我們當然希望能夠整個企業通盤考慮，不要因爲部門利益影響組件邊界的劃分，影響功能設計，做出來的東西，凡是公用的部分，應該照顧到所有利益相關方的需求；凡是已實現的功能都應該對新的需求方開放並支持必要的擴展，這是企業級設計應該追求的目標，但是，實現上常常很困難。企業無論大小，一旦系統的設計邊界跨越了單個部門的職能範圍時，都會出現部門利益問題，無非是企業規模、文化差異造成的協調難度的差別。
在企業內部，部門利益是部門需求的天然邊界，即便要做企業級，大家肯定也是先要說清楚自己的需求，才能考慮別人的需求，種了別人家的田，荒了自家的地是絕對不行的。所以，大家在坐到企業級這個談判桌上來的時候，都是先揣了自家賬本的，首先要滿足自己的業務訴求。這就要求，做爲業務架構的設計者，你拿出來的方案最好是以一種更有效的方式滿足所有相關方的需求，而不是單純做抽象、歸併，要大家你讓一隴地，他少一棵樹的方式搞折衷，這樣實際上失去了做企業級的核心價值，因爲這樣的折衷即無法保證系統先進性的，也無法保證用戶體驗，甚至可能退步。部門利益是做企業級最大的障礙，跨越這個障礙是對業務架構師設計能力的最高挑戰，當然，要客觀，沒有更好解決方案時，不動也是一種選擇，因爲，同樣接受這個挑戰的還有企業文化。
舉個例子，銀行都有積分系統，近年來大家也都做了綜合積分，其實這裏邊的難度很大的，主要問題不在技術而在業務。理想的綜合積分是企業只有一個積分系統，支持所有產品的不同積分規則，對不同客戶羣、不同營銷方案可以進行參數化配置，最重要的是，支持以單一積分形式統一用於獎勵兌換，而不是要換個包包，得分別去花信用卡積分、黃金交易積分、基金業務積分，這樣客戶會瘋掉。但是都用一個積分，內部問題就上來了，信用卡部門爲了促銷，提高積分發放，這樣信用卡用戶就在兌換獎勵時佔了便宜，黃金交易就可能下去，黃金交易的管理部門一激動，也開始刷積分，結果會造成積分的營銷費用提前被花光，反應慢的部門已經沒機會促銷了。說到這裏，大家也就明白了，綜合積分背後的博弈是營銷費用，搞綜合積分以前，這個費用其實是劃分到各部門的，各部門自行支配，蛋糕先分好，如果綜合積分設計不考慮清楚這個問題，就會動了大家的蛋糕。所以，如果能解決這個問題，綜合積分就能真正做到一個組件裏，解決不了，就還是各自爲政，那放不放在一個組件中就沒有實際意義了，只是解決積分綜合查詢問題的話，有很多方法都好過功能遷移。
組織問題會延伸到項目上
即便設計好了上層的業務架構方案，是不是就能順利實現企業級了呢？也未必。企業的組織結構會影響其內部溝通效率，壁壘森嚴的大型企業，溝通效率通常較低。大家可能知道，組織的溝通方式主要是正式和非正式兩種，其中，正式溝通在大企業中最常見的方式就是開會。如果項目少可能還好些，但是大型企業通常會有多個項目同時施工，一般都是項目羣、項目組合的方式，而如果下決心搞企業級轉型項目，十幾個、甚至幾十個項目長年同時施工也是很正常的，互聯網企業相信更是如此，每天都在挑燈夜戰。那麼由此帶來的一個問題就是項目組之間爲執行企業級設計藍圖，在開發過程中可能需要對組件協同問題、邊界問題頻繁溝通，項目經理、業務經理、技術經理這些角色甚至會成爲職業開會人，如果會議效率難以保證，一個問題久拖不決，就會產生兩種結果，一是項目組擔心工期延誤直接改變架構方案；二是採用非正式溝通方式，項目組間通過私下交流解決問題，而後者也極有可能是以改變架構方案爲代價的。
這兩種結果都會令企業架構很“尷尬”，導致架構失靈。而應對這種問題並沒有特別好的方法，只有加強企業級架構人員的能力與數量，讓企業級架構人員以BP（合作伙伴）的方式走入項目組，在項目組間搭建起企業級架構協作網絡，提升架構決策效率，才能不讓企業級架構成爲瓶頸。當然，有個牛人居中，在最高層領導的支持下，強行拍定各種決策，也是一種選擇，但是，企業越大，尤其是業務居於主導地位的企業中，這種結構也很難形成。
企業的組織結構在業務架構的設計與實現中具有很重要的影響，其實，理想的企業級系統建設與組織結構轉型是相輔相成的，一個在組織結構上高度部門化的企業是很難建成一個真正的企業級業務系統的，這一點在做業務架構設計時務必要考慮，方案與組織結構要匹配，否則很可能在落地時困難重重、面目全非。企業級轉型多數是需要時間的，休克療法、瞬間跨越很難，這一點上，業務和技術要通過業務架構設計過程互相影響、互相協作、互相改變。阿里的“中臺”建設也經歷了一個“砸煙囪”的過程，其實無論你砸的多賣力氣，“煙囪”總還是會有的，對於企業級設計來講，這是大家必經的“坑”。
相關文章：
中臺之上（一）：重視業務架構，不要讓“業務的歸業務、技術的歸技術”
中臺之上（二）：爲什麼業務架構存在 20 多年，技術人員還覺得它有點虛？
作者介紹：付曉巖，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計。公衆號：曉談巖說。