編輯導語：中臺是面向企業內部提供服務，提供半成品生產能力，同時提供配套服務；本文作者詳細介紹瞭如何使用MSS建設模型，去完成一箇中臺服務中心的建設，我們一起來看一下。
在正式講述建設方案之前，我們需要對一個小概念進行一個辨析：服務中心。
當下如果你在網上去搜索中臺，會發現中臺二字前面被灌注了很多的業務屬性，例如訂單中臺、會員中臺營銷中臺；事實上這些都不能稱之為一箇中臺，而只能稱之為中颱中的一個服務中心。
讓我們正確的去理解一下這兩個概念：
- 服務中心：獨立解決一個業務域內的完整需求，例如訂單、會員、商品，因此市面上的這些模組中臺，正確的稱呼應該為訂單服務中心，商品服務中心與會員服務中心；
- 中臺：是若干個服務中心組成的一個系統解決方案。目的是為了解決公司的整個業務沉澱，而既然是既然是公司級的業務沉澱；那麼大家肯定沒見過有哪個電商平臺的業務是隻處理訂單，而不需要理會會員或不處理商品的，肯定是這三者的一個集合。
搞清楚了這兩個概念後，我們就可以去進行實戰建設了，接下來讓我們具體來看如何打造一個支付服務中心的完整歷程。
二、業務調研根據MSS建設模型，要想去建設一箇中臺，首先第一步我們要對現有業務進行調研，瞭解現有業務的組成以及服務特徵。
這裡的業務調研具體分為兩個步驟：
讓我們來一個個看：
1. 步驟1：業務模式調研所謂業務模式調研，就是指調研這個公司一共向外提供哪些服務或者產品，從而清楚的知道公司是依靠哪些業務來進行盈利的；而公司所要優先沉澱的內容，其中很大一部分就是將能盈利的業務構成沉澱下來。
據此我們得出了現有支付業務的三大服務型別：
- 代扣服務：指定應用的自動扣款，如會員自動充值；
- 支付通道服務：為交易方提供快捷扣款，收款的服務；
- 聚合支付：支付寶，微信，雲閃付等混合掃碼支付。
這三類業務分別有三組不同事業線進行維護，提供技術開發，這三組事業線也被稱之為前臺服務部門。
2. 步驟2：客戶合作模式調研所謂客戶合作模式，其實就是對一家公司如何從客戶引入以及完成客戶服務交付這兩個環節的流程定義，瞭解了這個我們就能知道公司是如何具體展開業務的。
據此現有的服務方式調研結果如下：內部完成客戶合作共分為三個角色：銷售、運營、銷售支援，而這三類角色是公司三個業務線條公用的。
角色1銷售：
角色2運營：
- 開通A服務商戶賬戶（服務金鑰）+配置；
- 開通B服務商戶賬戶（服務金鑰）+配置；
角色3銷售支援：
- 計算各使用者費用加總並收款，開票；
- 計算通道費用並支付（給銀行費用）；
完整服務流程如下：
完成了這兩部調研，我們其實對一家公司內部整體的業務就有了一個清晰的認知：
在梳理完成業務現狀後，下一步要做的就是定位現有業務中存在問題？
在客戶合作模式中下面三個問題是日常工作中痛點的：
- 每個商戶存在多個服務的接入金鑰，不易管理；
- 多個服務的收入計算沒有打通：在每月給商戶計算賬單時，需要首先挨個計算各個服務產生的費用再由財務進行彙總得到總賬單，這中間流程較長且容易出現錯誤；
- 使用者發生合同變動時各項服務都需要調整：此外由於商戶對接了多個服務，當用戶在升級套餐或需要其他額外輔助項時，使用者的一個單次調整例如賬期延長，需要協同多個業務線都在內部進行賬期配置調整，這效率無疑是太低的。
由於客戶合作支撐部門是一個公共部門，解決他們的問題就可以同時提升各前臺業務線的運營效率；因此面對他們的技術服務解決，便被納入到了中臺開發之中。
三、服務標準化要想解決上面所提到的問題，根據MSS建設模型，我們就來到了第二步，要去將現有的服務標準化。
具體來說，標準化就是按照如下兩步去重新定義服務：
步驟1：拆分原產品:到最小顆粒度。
我們將上一階段的三個業務，進一步細化可以得到具體每個業務的支撐環節。
例如：支付渠道業務 = 銀行支付服務 + 第三方支付服務 + 結算服務
步驟2：支援自定義組合：各服務可獨立提供服務。
面對上面問題中，我們每個商戶存在多個服務多個接入金鑰的模式，這裡給出的解決方案是在公司內部為每個商戶去建立全域性唯一商戶號，並只配發一個金鑰；通過後臺識別該商戶賬號下所配置的服務，實現一個金鑰管理多個服務。
四、中臺解決方案在上一步對於具體的業務，我們在現階段很難去進行每個業務線內部的業務調整，所以我們在這裡增加了一個全域性配置中心。
具體實現兩個功能：
1）全域性商戶號
透過全域性唯一商戶號作為中颱中商戶唯一ID，來關聯各業務線的服務，從而使服務主體、結算主體都可以統一為一個商戶號。
取代以往商戶需要開通多個服務時，要在每個業務線內去獨立建立一個商戶號，結算主體在公司內部出現多個的異常情況。
在有了全域性商戶號後，該商戶所有的呼叫次數都可以記錄在該商戶號下，並以具體的服務來細分；使呼叫服務的同時在每個服務下記錄具體在該服務中產生的費用，最終由系統自動將多個服務費用加總得到該商戶的統一結算金額。
2）協議：主協議（系統級）+補充協議（服務級）
將每個商戶的服務配置升級成為服務協議，統一放在全域性配置中心進行管理，據此我們將使用者的一個使用者服務要求拆分為了兩個部分：
- 主協議：指客戶與公司簽訂的全域性服務配置，如商戶服務資訊/計費模式/賬期天數；
- 補充協議：指各業務線內部服務配置服務，如聚合支付需要支援哪幾個平臺的配置。
透過此方案，我們就將商戶在公司內部建立起了全域性的概念，所有業務線的服務都只有一個商戶，從而實現了唯一化管理。
五、中臺特異性管理看到這大家覺得這樣的服務中心設計，對於中臺專案來說是否可以說已經完成了？
事實上這樣的設計還是有一點不足，在中臺建設的過程中，我們經常會遇到的一類問題，就是業務的發展會導致新需求必須要不滿足於中臺的設計才能跑的通。
這樣說可能大家還是不理解我繼續來帶大家看這個支付中心所遇到的問題。
透過上面的商戶全域性商戶號與全域性協議，我們實現了對商戶的唯一化管理，但是隨著我們業務的發展，特別是當我們與一些頭部客戶合作時；頭部的客戶對我們提出要求，要求我們在原有賬期到期後，在打款期間依舊能臨時使用我們的服務。
也就是需要我們在這段時間給予商戶一個授信額度，允許在規定賬期之外對我們進行賒賬。
但是這個時候，已經標準化了的整個商戶管理服務和支付中心不支援這樣的服務，在到達賬期後，商戶不進行結款，不會允許商戶進行使用。
面對這樣的業務需求，我們不得不跳過中臺所提供的部分功能，從而滿足這位客戶的個性化需求。
當時我們有兩種解法，第一種解法立即啟動中臺升級，在支付中心中增加授信模組，但是這樣做等待時間比較長，無法及時響應客戶現在的需求。
第二種方法就是我們要去介紹的通用中臺特異性管理方法，由業務線提供個性化服務的程式碼段來跳過中臺的限制；從而既不破壞中臺的要求，又能符合業務的新需求。
這個程式碼段有它自己特殊的名稱，也就稱之為中颱的外掛，他的特徵有如下兩個：
具體落地到業務上來看，我們是這樣實現的：
- 1.0中臺中的計費不支援授信，此時我們使用外掛；
- 呼叫中臺還是商戶預充值服務：虛擬充值金額2萬，以此讓中臺認為該商戶已經完成還款充值，此處的還款充值額度就為給商戶開的授信額度；
- 在外掛中記錄2萬為授信額度，在月底的商戶賬單中自動沖銷2萬元，從而實現金額的閉環。
所以我們看到外掛就是在滿足不影響底層業務的情況下的一個繞彎，當然之所以不把這個業務單獨拉出去去做，是因為目前我們只對接了一個客戶。
該模式的規模化特徵還不明顯，此時我們如果貿然的將它加入到中臺中來，只用一次的需求對於中臺來說，無疑是開發資源的巨大浪費。
所以我們會先選用外掛的模式，從而快速複用中臺其他的邏輯，當新模式出現規模化特徵時，我們再進行中臺對應模組的開發，由外掛變為中颱內部的一個服務。
也就是當出現多個外掛使用服務時：
所以我們中臺解決方案的2.0也就生成了：
在有了中臺服務中心後，整個服務的提供方式變為：
總結一下在本次服務中心的建設中，我們實際上使用了這樣的一箇中臺建設方案：也就是基礎能力與配置分離的設計方法：
我們將一個商戶服務拆分為了三個部分：
- 基礎能力：各個業務線所提供解決80%商戶需求；
- 協議配置：記錄商戶的合作方式與全域性配置；
- 外掛：滿足使用者的個性化需求；
至此根據MSS建設模型一個完整的服務中心就搭建完畢了，全文的完整建設路徑可以用一張圖來概況：
可以看到MSS模型能幫助我們快速的完成中臺服務中心的搭建。
對了，如果想要了解更多高階產品經理必備的業務建模技能與更多中臺建設相關內容可以看看我的新書《中臺產品經理寶典》，相信會給你帶來不少啟發！
#相關閱讀#中臺實戰（11）：中臺產品經理能力模型
中臺實戰（12）：中臺建設的三大誤區
中臺實戰（13）：為什麼你需要懂一點中臺思維
#專欄作家#三爺，微信公眾號：三爺茶館，人人都是產品經理專欄作家。《中臺產品經理寶典》一書作者，曾任萬達高階產品、MBA特約講師、獨立創業者，現某支付公司產品線負責人，擁有多款集團專案從零到一經驗並帶領實現商業化佈局。
本文原創釋出於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議。