起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識中臺產品經理實戰（7）：繞不開的企業架構
中臺實際上就是一個餐廳中配菜的小工，職責就是負責向前臺的各位大廚配菜，，但在梳理中臺需求的時候，我們必須要清楚的知道前臺到底有多少位廚師？各個廚師的偏好是什么樣子的？我們怎么樣的工作才能配合上每位廚師的炒菜節奏？也就是完成一次新的企業架構定義。
談到設計中臺繞不過去的一個概念就是企業架構！
為什么這么說呢？
是因為設計中臺就不能像以往設計傳統的單一產品線的產品那樣，僅僅是面向特定的人群進行思考，而是需要站在公司的視角，面向于整個公司業務對象與公司內部生產關系進行設計。實現對內提升企業運作效率，對外提升產品交付效率。
記得在本系列的第一篇文章里我已經給大家闡明了中臺實際上就是一個餐廳中配菜的小工，職責就是負責向前臺的各位大廚配菜，但是在梳理中臺需求的時候，我們必須要清楚的知道前臺到底有多少位廚師？各個廚師的偏好是什么樣子的？我們怎么樣的工作才能配合上每位廚師的炒菜節奏？也就是完成一次新的企業架構定義。
再用更白的話說一下就是，我們搭個工棚可能不需要設計，拿著磚就干了，但是如果我們要建個迪拜塔就必須要好好設計了，整個建筑的上下水，電怎么接等都需要思考，而這就是企業架構的活。
一、我們先來看看企業架構到底是個什么東西？
企業架構(Enterprise Architecture)這一概念最早是由IBM的咨詢顧問John Zachman，于1987年提出的。
也就是在隨著企業管理精細化，企業內部引入了多套不同領域的管理軟件之后，絕大多數企業出現了相類似的信息化企業病，我稱之為“人肉接口”與“為系統工作”的兩種病癥。
具體來說這兩者的根本癥結就是存在當公司內部采購了多個軟件后，由于各個軟件之間數據無法互相傳遞，事件狀態無法相互推進，導致不得不由員工將上一個系統產生的結果手動輸入到另一個系統進行下一步流轉。
此外由于系統間天然的隔離性，導致在上一個系統做過的審批以及操作，在下一個系統中很有可能還需要進行。
舉個例子來看，某公司的信息系統體系如下：
- HRM：類似italent等系統
- OA：企業某信+郵件
- 郵箱：內部搭建
- 產品研發管理：JIRA
- 財務系統：財務
- 銷售管理：某CRM
以員工離職這個場景來看，當我們要為某員工做個退工操作時：
- 第一步：需要進入HRM系統進行退工封檔；
- 第二步：需要進入OA系統里關閉權限；
- 第三步：關閉郵箱權限；
- 第四步：關閉JIRA項目權限；
- ……
這正是由于數據無法互通，導致我們不得不在多個系統之間進行操作，尤其注意的是這其中任何一個系統的權限遺漏都有可能會造成不可挽回的損失。
可以說上述的場景在現在的很多企業中都是非常常見的，那么現在企業中是怎么解決這個問題的呢？
由于無法實現系統間的互聯，因此往往是由公司人事部門整理了一份離職list，在每個人員離職的時候，按照list進行逐個手動關閉系統權限。
大家回想下自己離職的時候，是不是也會收到這樣一份list要你按照上面的流程去找不同的人關閉權限并簽字確認?？梢哉f這大大加大企業內部的風險與對應人員工作流被打斷次數。
其實這個問題并不是這幾年才暴露出來的，早在1987年這位咨詢師就已經發現了這樣的問題，并給出了自己的解決方案這就是企業架構：他認為在企業信息化建設之初就應該考慮到多個部門之間的協作，并且在系統上體現出來，也就是A部門的協作結果很有可能成為B部門的信息來源，所以在系統之間必須有。對應的數據接口進行數據傳遞，此外還必須要為系統的后續迭代保留可拓展的部分。
讓我們具體來看看企業架構到底是由什么組成的，如果繞過那些特別繁瑣的實施方法，僅從產出物上來看，我引用一張在我書中的圖來概括企業架構是什么東西：
- 業務架構：如何將企業抽象的商業理論變為具體的執行層面，例如馬云提出的讓天下沒有難做的生意落實到具體的執行層面，就是建立一個由支付體系（支付寶）+全球交易平臺（泛淘寶平臺）+物流體系（菜鳥驛站）組成的業務架構；
- IT架構：如何管理企業內部在運作中產生的數據，不同的應用軟件，以及底層的實現技術。
當然完整的企業架構構造不會這么簡單，按照John Zachman的理論，企業架構具體分為這6類角色：
- 企業擁有者
- 業務管理者
- 系統分析者
- 系統設計者
- 系統建設者
- 系統本身
而這6類角色各自關注的問題也是有所不同的，具體關注的問題如下表所示（可點擊放大哈）：
既然聊企業架構，我就再展開點引用一位明白人談談目前發展的現狀：
工業和信息化部副部長楊學山在一次內部座談時提到：與西方發達國家比，國內的信息化建設在硬件方面已經不相上下，在軟件方面有5年的差距，在信息化管理方面有大概10年的差距，在企業架構方面則有20年的差距。
二、了解了企業架構后的中臺建設
了解完了企業架構的概念后，我們再回到中臺建設思考上，中臺本質也是一個業務系統。
所以當我們研制中臺的時候我們就需要考慮企業原有的企業架構（業務+現有IT系統），在中臺加入后的新企業架構會是什么樣的？
如何既符合原有業務架構又能封裝整個IT架構，為產品交付提供便利。
當然我們不需要像傳統的軟件咨詢行業一樣去規劃企業藍圖，中臺建設中更多關注的是企業的業務現有流程，以及現有各系統之間的關系，在中臺層面需要如何進行支撐與服務。
舉個例子我們作為一個外賣APP，我們內部有商城系統，商戶管理系統，物流調度系統，客服系統，當我們新拓展出的外賣派送、同城派送與超市派送等業務時，雖然應用場景各不相同，但這背后的業務核心流程是完全相同的：都是為用戶提供周邊5公里的派送服務。
對此我們可以將這派送機制抽離并整合進中臺中，由中臺提供一個全公司業務的派送調度服務，而由不同的前臺業務線來根據具體場景設計對于的用戶交互流程與訂單的下單與進度顯示。
這其中本質上就是要梳理企業各業務線中原有的調度系統關聯關系，以及原來的派單業務的運營模式、流程體系、業務人員的組織結構。
讓我們再來看中臺的完整建設流程（也就是在我的書中介紹過的MSS建設模型）：
該流程的前三步其實就是在進行業務架構的梳理（當然本系列中臺實戰文章的寫作路徑也就是在按照企業架構的梳理方法進行一步步展開的）。
例如在上一篇文章《中臺實戰（6）：業務邊界的劃定》里，我們其實談的就是企業架構里業務架構的梳理，我們結合前面學習過的商業模式識別與已經標準化的企業流程，對我們各業務線的SOP進行評估以及最終產出了一個業務標準建模：
Part1：生鮮電商商業模式（業務架構）
Part2：業務架構承載方：業務線定義（業務標準建模步驟1）
Part3：業務線SOP梳理（業務標準建模步驟2）
經過這些的梳理我們得出的是一家公司中的完整業務架構，并在此基礎上去進行中臺系統的定義。
中臺在IT架構中起到的作用用一個詞概括就是封裝底層。
具體來說建設完成后的業務中臺與前臺的交互模式，由業務中臺負責去定義需求的范圍與內容，并將具體的業務數據與處理結果返回給前臺，由前臺業務線負責具體展示形式。
如果用我們經常聽到的產品設計五層模型來對應的話，加入中臺后的企業IT架構就如下圖所示：
可以清楚的看出業務中臺是五層模型里的結構層，而框架層與表現層由前臺業務團隊進行定義。
最后
中臺建設本質上就是對企業業務架構了一次升級，所以如果我們想要建設一個好的中臺，就必須對企業架構特別是業務架構進行充分的梳理與歸整，只有這樣中臺才能發揮起自己的作用。
PS：本文是即將出版的《中臺產品經理寶典》10.1節企業架構概念的拓展，建議可以再結合書第10章一起閱讀。
#相關閱讀#
#專欄作家#
三爺，微信公眾號：三爺茶館，人人都是產品經理專欄作家。曾萬達高級產品、MBA特約講師、獨立創業者，現某支付公司產品線負責人，擁有多款集團項目從零到一經驗并帶領實現商業化布局。
本文原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
- 目前還沒評論，等你發揮！
