編輯導語：在前面的系列文章中，作者為大家介紹了中臺MSS建設框架的概念，在本文中我們具體看看要如何實踐MSS框架。作者從理解中臺和建設中臺兩個方面出發，對MSS建設框架進行了詳細闡述，並總結了自己的相關思考，與大家分享。
以下內容來自作者的線下演講稿：
我分享的主題是中臺通用建設方法論：MSS建設框架，本次的分享我會分為三個部分來展開：
中臺為什麼火了以及中臺火熱背後的深層次原因；在主導了多個中臺項目後，自己總結出的一套MSS中臺建設框架，希望能幫助大家更好的能完成中臺產品的設計與規劃；在經歷過多個中臺項目後我的一個建設感悟。接下來讓我們一個個來看：
01 為什麼中臺概念突然火了？大家都知道中臺概念最早誕生於18年前後，也是從那時候開始整個網際網路圈開始興起一股中臺的風潮，一直到今天中臺都還是一個相當熱門的概念。
那麼中臺概念火熱的背後，除了簡單的歸納為企業跟風外，能持續這麼久這背後肯定有深層次原因，而深層次原因就是這張圖：
（中國信息通信研究院(CAICT)：2018年手機出貨量統計）
我這裡為大家放了一張國內機構給出的中國手機出貨量統計表，大家現在都知道中臺概念在18年興起，但是大家可能不知道的是18年對中國手機市場其實也是一個非常特殊的年份，為什麼這麼說呢？
我們從圖中可以看到，在紅框圈出來的部分，代表著中國手機市場首次出現了一個現象叫做整季度出貨量為負增長。
這個現象意味著什麼呢？其實就意味著網際網路第二次流量紅利，也就是由PC機換到智能機的移動網際網路流量紅利開始步入殆盡了。
也就意味著傳統粗放型的業務運作模式行不通了，以往在公司中為了短平快上馬，我們經常會拋棄原有的條條框框，拋棄舊系統，根據新業務的特性來另起爐灶，雖然這種方式相對於舊系統的改造來說速度最快，但是成本也極高。
特別是在流量越發稀少時候，這樣的做法就變的成本更高了，因此越來越多的公司開始思考能不能讓已有的現成產物去重複多次使用。
也就是說因為流量紅利的減少，導致網際網路獲客成本提升，所以以往企業在面對新業務可以不計成本進行拓新的場景已經不復存在了，企業開始想如何在新的場景中去復用之前的一些產出從而實現以最小的成本去進行新業務拓展。
這其實才是中臺誕生的深層次原因——「中臺是因為企業的焦慮以及網際網路下半場流量的零和博弈而誕生的。」
講完了中臺誕生的深層次原因，下面我再談談中臺的本質是什麼。
經常會一些想使用中臺概念的企業負責人，通過公眾號後臺找到我，和我聊天，他們問我最多的一個問題就是：SaaS、微服務能否與中臺劃上等號？
我想說這樣的認知其實是對中臺的一個割裂的認知，怎麼理解這句話呢？
SaaS屬於一個服務需求方的成熟產品（雖然與中臺的復用思想很像），但是相對於中臺來說缺少技術屬性，也就是幫助業務線快速開發的能力
具體來說中臺的技術屬性是A與B：
復用能力中心：如何將原有代碼進行封裝讓其他業務線復用；快速接入使用：傻瓜化，不需要複雜的參數就能去接入。這種技術屬性在SaaS端是缺少的。
再來看微服務，微服務屬於中臺的實現手段之一但不是中臺的全部，因為他缺少業務屬性。
所謂業務屬性也就是特定場景下全解決方案，例如以往使用微服務復用登錄註冊功能，只是復用了一個登錄註冊的接口，但是除了登錄服務外，解決登錄註冊我們還需要驗證碼服務，重置密碼服務，防止密碼暴力破解的風控，登錄統計這一系列的完整流程。
而這種一次性解決全場景的復用，其實就是中臺。
「中臺是原有單點復用的升級，稱之為場景復用。」
因此總結下中臺的本質：
「中臺解決方案是一個多重屬性的集合，包含技術屬性與業務屬性。」
如果用做菜的例子理解中臺的話，原有的做菜的流程是：（1）買菜；（2）配菜；（3）做菜，三大步驟。
在很多小餐館這三個步驟基本都是廚師一個人完成，而為了提升做菜效率，我們通常會引入配菜小哥來幫助廚師進行預處理，也就是提前將食材變成洗好，切好，配好的半成品，來用戶訂單後，只需要由廚師按照用戶口味進行二次加工調味，這樣一道菜就做成了。
類比上面的兩個屬性，技術屬性就是配菜小哥給業務線的大廚們洗好，切好菜品，這叫預處理，業務屬性就是還額外提供裝盤，擺盤，這就是配套的全套解決方案了。
02 中臺MSS建設框架：業務建模講完了中臺概念，我們先以一家生鮮電商為例來看一個真正的中臺實戰框架，就是下面這張圖：
大家看到這個圖的第一感受是什麼？
我當時第一次在做中臺規劃時，查到一些類似的資料給出這樣中臺架構時，我問自己了兩個問題：
這種中臺的完整方案是如何一步步規劃成這樣的？為什麼要這樣進行中臺規劃設計？就像現在在大屏幕上展出的這張圖，它一開始規劃的時候可不是這樣，也不可能一開始就設計成這樣，而事實是我經過4次迭代才有了這樣的一個完整的全景解決方案。
帶著這兩個問題在我完成了多個中臺項目建設後，我自己總結出來了一個中臺的通用解決方案，下來我們就來談談剛才那個全景圖是如何建設出來的。
在講解通用方案前，首先我們要有一個正確的認知：
「中臺建設不存在通用方案，想要一招鮮吃遍天在中臺裡是行不通的」
原因也很簡單，就是因為：
中臺不僅僅是一個系統的建設，而是上升到一個企業維度，是企業在去尋找自身信息化最優解的建設；每個企業內部的信息化需求都不同，只有最貼合企業才能適合企業，因此必須要去高度定製化（就像每家公司都有會員管理，但是每家管理的側重點都不同）。所以沒有可以照搬的通用方案，只有通用的建設思路。
這裡的通用建設思路，就是我在《中臺產品經理寶典》一書中提出的，在我經歷多個中臺項目建設經驗後，總結出的一個MSS建設框架。
具體來說為三步：
調研解讀：市場認知；準備階段：企業標準化預建；建設階段：中臺解決方案設計。第一步市場認知，這裡我們還可以分為兩小步：公司外部研究與公司內部研究，讓我們先看外部研究。
所謂公司外部研究就是指：
研究公司產品背後的細分行業現狀是什麼，公司整體業務在行業中所佔地位，以及未來行業發展趨勢是什麼；研究公司的目標市場是什麼人群，基於什麼場景，通過什麼方式，解決什麼問題。我們以A生鮮電商為例子來說：
通過產業分析，可以拆解出生鮮行業是由圖中的這五個角色組成的。
掌握了整個產業後，可以嘗試去解讀一些企業發展的問題，例如生鮮電商與社區團購的競爭，原有的生鮮電商要如何應對社區團購的衝擊？
因為在中國這個物流配送解決方案可以以極低成本實現的現狀下，留給生鮮電商在未來的發展方向必然會是進軍上遊供應側，也就是走向產地，與農場合作降低商品進貨成本，所以這裡紅框圈出的部分就是企業的未來發展方向。
講到這肯定有朋友要問了，我們不是進行中臺系統建設嗎？為什麼要來分析產業以及企業發展方向呢？
其實這麼做是很有必要的，眾所周知中臺建設是一個很漫長的系統工程，而中臺建設最害怕遇到的局面就是當我們建設完畢後，企業的重心發生了變化，原有的業務方向已經不是公司的重點了。
因此產業研究與公司發展方向預判的目的，也就是為了搞清楚未來發展中什麼業務才是公司未來所戰略依賴的。
通過此我們就可以在中臺規劃的過程中，動態調整要優先支持的相關業務。只有這樣在中臺建設過程中，才不會出現建設完畢後，因公司的重心發生了轉移而導致的中臺項目無法遲遲切換的困境。
總結一下，我們去進行不同顆粒度業務研究的目的，就是為了讓我們能基於調研，更好的理解公司所應對的場景與服務的人群，從而幫助我們更好的評估在中臺建設匯總中的取捨與迫切程度。
下一步我們就要將視角回歸到企業內部，來看看企業內部的系統，也就是研究下企業內部的IT架構是什麼。
我們還是以A生鮮電商為例來看，一家生鮮電商企業的IT架構是什麼？也就是依靠什麼系統完成業務閉環的。
首先我們可以看到A生鮮電商內部有三條業務線，A1，A2，A3業務線，我們在這以A1業務線進行拆解，看看內部都有哪些系統。
通過梳理我們得到了整個A1業務線內部的IT架構，分為三大類，9個系統：
業務承載 = 商城小程序+商城APP+商城H5業務支撐 = 運營後臺+CRM業務履約 = WMS+SCM+TMS+MES通過這樣的梳理我們就完成了對一條業務線的認知，清楚的知道這條業務線是怎麼用系統實現業務閉環的，如法炮製就可以將公司內所有產品線的系統按照這樣的結構梳理出來，就能將任意模式的公司業務做到胸有成竹了。
完成IT架構的梳理後，下一步我們要進行的工作就是要完成企業業務標準化建設。
所謂業務標準化，就是將內部不同業務線的內部人員運作模式進行統一，從而實現內部效率最優化。
這裡我想提問下大家，不知道大家是否已經在自己公司內部開始中臺建設了？
這裡我想說在中臺建設中最大的一個誤區就是一上來就開始開發。
我去過很多已經啟動中臺建設的公司，他們最經常遇到的一個現象就是內部團隊在費盡九牛二虎之力將中臺建設完成後，各個業務線的團隊卻不願意對接，說中臺不符合自己業務需求。
而中臺業務負責人也很委屈，說自己已經盡最大可能的兼容你們了，但是你們每個業務在任意環節的需求都不同，大家能不能克服下。
這裡我想說這種做法其實從一開始就錯了：
「中臺建設不應該是直接建設系統，而是應該先規範化各業務線作業流程，再開始建設」
只有這樣我們才能讓中臺建設的流程是公司內的主流程，這也是為什麼中臺被稱之為「一把手工程」的原因，我們要先改造業務，將原來各個業務線自由發揮的作業流程進行標準化。
具體來說這裡的核心任務就是要完成：
梳理企業業務關鍵節點；定義各業務運營SOP。「這樣做本質上也是幫助企業完成了一次內部管理升級。」
所以很多時候中臺業務負責人，也被稱之為企業內部的諮詢專家，因為他需要比更多業務人員還要懂業務。
接下來我們就具體來看這兩個任務要如何推進，首先我們來看一下如何梳理不同系統中的關鍵節點。
通過前幾步的工作，知道了我們想要幹什麼，以及有什麼，這一步就是在為我們有多個業務團隊時進行內部標準化。
還是以A生鮮電商這個案例為例，我們將整個電商體系的日常工作按照前面的關鍵角色/關鍵事件/關鍵動作，進行一次梳理，可以發現一個電商中可以拆成三大事件：
（1）採購事件；（2）商城事件；（3）供應鏈事件；
而每一事件又可以拆分為多個節點，以採購事件為例可以拆分為：
（1）供應商節點；（2）採購節點；（3）結算節點；
而每個節點下面又可以拆分為多個任務，以供應商節點為例可以拆分為：
（1）選擇供應商；（2）結算方式談判；（3）供應商合同籤訂
依舊如法炮製我們可以找到全公司的事件、節點、任務，據此也就可以得到一家公司的關鍵節點牆，如下圖所示：
通過這些節點一家企業內部業務的運作模式是被清晰的表示出來了。
第二步我們來看看如何梳理業務的SOP，所謂SOP就是為每一個業務節點都定義一個最優的標準流程，例如商品上架，我們定義一個標準流程，並讓全公司的所有商品運營都按照這個流程執行。
這樣做了之後，就不會出現因為流程不同帶來的中臺化需求不同的問題。
我們還是舉個A生鮮電商內部的例子，在公司內部A1,A2兩條業務線的商品管理流程有說不同，其中最大的差異就是A業務線是由採購進行商品建檔，並且進行匯總，B業務線由商品運營進行建檔，因為操作人員的不同，在這兩條業務線內部也就擁有了不同的商品管理流程。
此時中臺建設難道要支持兩套流程嗎？肯定不能這樣做，所以在建設A生鮮電商中臺之前，我們就先需要對這裡的流程的進行一個統一。也就是需要制定一個商品管理的SOP來規範各個業務線的操作。
那麼如何去定義SOP呢？這裡我給大家推薦兩個抓手，可以從這兩個抓手來進行：
抓手1：工作流：業務線各人員的工作流程；抓手2：信息流：業務線工作中流轉的信息；於是乎我們就得到這樣的一個商品管理SOP，如下圖所示：
此時在中臺開發時，如果基於此進行開發，就可以大大減少各個業務方的個性化需求與上線後的切換推進難度。
那我們也能看到，其實在做這樣的操作的時候，我們同時幹了這樣的三件事情：
去統一了各業務線的作業規範；讓擬規劃的中臺數據結構變成了各業務線都能接受的通用化數據（因為通過前面的梳理已經完成了業務的標準化）；其實此時的中臺數據結構就是公司級的主數據。到這通過產業研究、IT架構梳理、節點牆拆解，SOP定義這4步工作的完成，我們就得到了A生鮮電商的標準化業務框架。
這裡的框架分為如下四個部分：
業務環節：對應前面梳理的IT架構，也就是三層體系的系統：採購/商城/供應鏈；業務對象與業務屬性：對應前面梳理出的SOP，告訴我們具體要處理那些對象的信息流轉，以及每個對象的信息流是什麼？業務模式：基於前三者建立的系統，支撐起了我們一開始調研的產業結構中企業當下所在產業鏈中的定位與商業模式。這裡的業務對象就是我們的服務中心，業務屬性就是我們的服務中心內的關鍵業務場景。可以看到通過這一系列的步驟，就讓我們很清晰將一個生鮮業務翻譯成了，在開頭那張中臺架構全景圖中的中臺需要實現的需求範圍。
03 中臺MSS建設框架：方案建設可以說至此我們整個中臺的預建階段工作就完畢了：
「在中臺建設中，完成了業務預建其實整個中臺建設的進度也完成了80%的工作」
接下來我們就只需要按照這個統一的業務框架進入中臺的開發環節中既可。
具體來說中臺的建設方案可以分為這5步：
由於今天演講的時間有限我就挑重點的幾個部分來講，首先我們來看下中臺的落地方案組成的最小單元——服務中心。
在前面我們多次提到服務中心這個概念，其實在中臺具體落地方案中，中臺的組成就是由一個個的服務中心之和構成的。
而服務中心是用於解決一個完整的領域內的問題，就像今天其他分享者談到的領域建模，這裡的落地產物就是服務中心。
如果將服務中心再拆解一下，可以看到：
「服務中心 = 業務組件 + 數據組件 + 拓展服務」
組件服務就是前面提到的中臺技術屬性落地產物，提供技術復用；
拓展服務就是前面提到的中臺業務屬性落地產物，提供場景化復用；
要想建設一個服務中心，這裡為大家帶來一個標準的服務中心建設方法，也就是Summary-Details分離設計。
中臺既然是要做一個可復用的一個模塊，就必須要去響應不同的業務線場景，那麼這裡為了能實現場景響應，我們就需要去把業務信息從服務中心中進行剝離，只管理摘要信息，具體的詳情信息和具體的場景解決方案是由業務線去進行實踐。
例如在訂單服務中心中中臺只存儲了訂單id和訂單標的，其他具體的詳細信息，由業務線進行設計，只有這樣的建設情況下，我們的服務中心才可以去兼容各種不同的場景的訂單。這實際上來說就是我們服務中心建設過程中常用的一個方法。
看完了服務中心建設後，我們最後再來看一個東西，叫做中臺特異性管理。
什麼是特異性呢？其實就是我們在中臺建設過程中，不管設計的多麼好，都會遇到有一些場景它是跳出我們的中臺原有流程。
這裡最常見的例子就是說當我們新孵化了一個業務，他有很多流程是不按照原有公司流程去走的，那麼這個時候我們要怎麼去把接入中臺呢？
此時中臺有兩種方案，一種徹底不接，第二種就是去改造中臺去把他兼容進來，但是如果我們貿然去選擇改造中臺，由於這是一個探索業務，很有可能在中臺改造完成之後或者改造過程中，這個業務就被下馬了。
那這個時候我們的改造就浪費掉了，況且作為公司的基礎服務中臺，為了穩定性本身也不能頻繁改動，所以我們要怎麼解決這個問題呢？
這裡就需要我們使用插件概念，讓他去接入到中臺中。
所謂插件也就是中臺開放一些對應的接口，允許業務方去插入一個自定義的代碼段，自定義代碼段可以去調用我們中臺的上層服務，去跳過部分場景。
我舉個例子來說，我經歷過一個新孵化的業務想要調用客服服務中心的服務，但是由於新業務中人員較少，原有的客服流程較長，且每一步都有對應的單據，導致新業務的客服工作壓力巨大，此時我們就讓該業務線以插件的形式接入中臺，並在部分環節調用中臺接口自動產生單據，這樣就解決了新業務線的問題。
可以說插件可以幫助業務線既接入中臺，同時又去符合了新業務的特性，那麼這就是插件帶來的意義。
所以有了插件之後，我們中臺解決方案又做了一次升級，就得到了完整的方案架構：
「中臺 = 服務中心（組件 + 拓展服務） + 插件」
讓我們最後總結下MSS框架得出的完整中臺架構內容：
調研階段完成了完整的企業內外雙重調研預建階段完成了企業內部標準化建設建設階段完成了服務中心與特異性性管理04 中臺實戰建設的復盤感悟在我們完成了整個中臺建設方法論的講解之後，接下來我來談一談，在我經過了這麼多中臺項目之後，對於中臺建設的一個感悟：中臺為什麼難建？
從這張圖上我們其實看到一家企業的信息化過程實際就是從左至右的四步，我們看到所有產品功能的本質都是在為企業戰略服務的。
因此就是我前面所說的中臺建設的本質是企業自身管理上的一次升級，所以需要管理者能去規範企業內部運營管理，而規範管理的本質就是這三個框出來的部分（IT架構/企業架構/企業戰略架構）的一次標準化
所以中臺建設的核心難點在於如何將不同業務線的這三部分標準化，找出一套統一的規則。
「中臺建設的根本難點是企業的內部管理如何升級而不是中臺系統開發」
今天就先分享這麼多，謝謝大家！
#專欄作家#三爺，微信公眾號：三爺茶館，人人都是產品經理專欄作家，2019年年度作者。《中臺產品經理寶典》作者，原萬達高級產品、MBA特約講師、獨立創業者，現叮咚買菜B端產品線負責人，擁有多款集團項目從零到一經驗並帶領實現商業化布局。
本文原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議。