編輯導語：中台是面向企業內部提供服務，提供半成品生產能力，同時提供配套服務；本文作者詳細介紹瞭如何使用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協議。