編輯導讀：在中臺建設歷程中，在MSS模型的指導下幫助我們完成了中臺服務中心的設計與建設後，下一步便進入中臺實施與運營的環節。“業務系統與中臺流程衝突”一直是中臺實施與運營中一個痛點問題，本文作者基於三種常見處理方式，淺析其中利弊，並結合具體案例與大家分享使用“服務中心外掛”工具的解決方案。推薦童鞋們閱讀學習～
一、目標：特異性流程接入
中臺建設在解決了方案設計這一難題後，需要面對的另一大難題就是特異性問題的管理，這也是我們在中臺實施過程中必然會遇見的問題。
所謂特異性問題就是不管在之前業務模型怎麼抽象，在中臺實施過程中一定還會發現存在由於中臺系統與業務系統在功能上存在差異而無法接入的的現象，從而導致與中臺的對接出現阻塞。
例如可能是因為這個業務線當年與你介紹的時候他沒有提到某個特殊流程，或者因為在中臺研發的時候，業務線系統同步在發展，導致有一些新的流程把以前的流程推翻了，那這個時候就會出現特異性問題，本質上這個問題的來源屬於業務的發展導致新業務場景與中臺原有設計不再匹配。
這裡我想先問問此時正在閱讀的你，中臺系統和業務系統功能相沖突或違背，那這個時候我們應該怎麼辦？
這裡有幾個常見的做法供你選擇：
選擇直接放棄，也就是不把該業務線的系統接入到中臺中，該業務系統遊離於中臺體系外自己迴圈；
中臺團隊根據該業務的現狀，去進行量身打造，由中臺給你進行定製化改造，適配你現在的流程；
強制業務系統根據中臺定義出的流程進行相容，也就是由業務系統去按中臺的流程進行開發改造。
那這三種模式各自有什麼優缺點呢？
由於業務特異性而放棄接入，在出現一例不接入中臺的先河後，又因為中颱的建設過程中是業務逆向感知的，也就是不僅沒有給業務帶來新的價值，反而還要佔用大量的工時和工期，那這個時候業務是不買賬的。導致別的業務線聽到後，會說他不接入中臺，我也不接入，那這樣的情況下整個中臺就會在企業內部被邊緣化；
為業務線量身定製，這樣做的背後存在巨大的專案風險，一般情況下需要定製往往是因為這些業務還不成熟，由於這是一個探索業務，很有可能在中臺改造完成之後或者改造過程中，這個業務就被下馬了。那這個時候我們的改造就浪費掉了，此外作為公司的基礎服務中臺，為了穩定性本身也不事宜頻繁變動；
強制業務系統按照中臺流程改造，此時中臺反而成為了制約業務發展的瓶頸。
二、工具：服務中心外掛
所以我們解決方案是什麼呢？
在《中臺產品經理寶典》一書的實施環節中，我提出過一個非常好的解決特異性問題的方案就是外掛，透過外掛讓特異性的業務部分接入到中臺中。
所謂外掛也就是中臺開放一些對應的介面，允許業務方去插入一個自定義的程式碼段，自定義程式碼段可以去呼叫我們中臺的上層服務，去跳過部分場景。
從而實現在符合現有邏輯中臺邏輯的一個呼叫，然後在具體的業務層去替換這部分的含義，使它賦予新的業務含義，從而讓他接入到中臺中。
我舉個例子來說，我經歷過一個新孵化的業務想要呼叫客服服務中心的服務，但是由於新業務中人員較少，原有的客服流程較長，且每一步都有對應的單據，導致新業務的客服工作壓力巨大，此時我們就讓該業務線以外掛的形式接入中臺，並在部分環節呼叫中臺介面自動產生單據，這樣就解決了新業務線的問題。
可以說外掛可以幫助業務線既接入中臺，同時又去符合了新業務的特性，那麼這就是外掛帶來的意義。
假以時日等到這條業務線變得越來越健壯了之後，這個業務越來越成熟，越來越多業務線都需要該外掛的功能後，我們再把這個外掛拆掉，讓外掛升級為中颱的一個能力，這樣的情況下是中臺最安全最節省成本的一種方式。
那這裡我們還是以一個具體的案例來看，在L電商內部是怎麼使用外掛解決這個問題的。
三、案例：L電商公司中臺外掛引入
在之前的文章中，我闡述過L公司中透過商戶全域性商戶號與全域性協議，我們實現了對商戶的唯一化管理，但是隨著業務的發展，特別是當我們與一些頭部客戶合作時，頭部的客戶對我們提出要求，要求我們在原有賬期到期後，在打款期間依舊能臨時使用我們的服務。
也就是需要我們在這段時間給予商戶一個授信額度，允許在規定賬期之外對我們進行賒賬。
但是這個時候，已經標準化了的整個商戶管理服務和支付中心不支援這樣的服務，在到達賬期後，商戶不進行結款，不會允許商戶進行使用。
面對這樣的業務需求，我們不得不跳過中臺所提供的部分功能，從而滿足這位客戶的個性化需求。
當時我們有兩種解法，第一種解法立即啟動中臺升級，在支付中心中增加授信模組，但是這樣做等待時間比較長，無法及時響應客戶現在的需求。
第二種方法就是我們要去介紹的通用中臺特異性管理方法，由業務線提供個性化服務的程式碼段來跳過中臺的限制，從而既不破壞中臺的要求，又能符合業務的新需求。
根據前面的介紹我們知道這個程式碼段有它自己特殊的名稱，也就是
中臺的外掛
，他的特徵有如下兩個：
符合現有邏輯的呼叫；
在業務層替換的該部分業務含義；
具體落地到業務上來看，我們是這樣實現的，如圖所示
1。0中臺中的計費不支援授信，此時我們使用外掛；
呼叫中臺還是商戶預充值服務：虛擬充值金額2萬，以此讓中臺認為該商戶已經完成還款充值，此處的還款充值額度就為給商戶開的授信額度；
在外掛中記錄2萬為授信額度，在月底的商戶賬單中自動沖銷2萬元，從而實現金額的閉環。
所以看到外掛就是在滿足不影響底層業務的情況下的一個繞彎，當然之所以不把這個業務單獨拉出去去做，是因為目前我們只對接了一個客戶。該模式的規模化特徵還不明顯，此時我們如果貿然的將它加入到中臺中來，只用一次的需求對於中臺來說，無疑是開發資源的巨大浪費。
所以我們會先選用外掛的模式，從而快速複用中臺其他的邏輯，當賬期需求在多個業務線都出現，成規模化需求時，再進行中臺對應模組的開發，由外掛變為中颱內部的一個服務。
也就是當出現多個外掛使用服務時：
開始將該外掛合併至中臺；
由中臺進行統一維護；
綜上我們透過外掛實現了中臺實施的特異性管理。
三爺，微信公眾號：三爺茶館，人人都是產品經理專欄作家，2019年年度作者。《中臺產品經理寶典》作者，原萬達高階產品、MBA特約講師、獨立創業者，現叮咚買菜B端產品線負責人，擁有多款集團專案從零到一經驗並帶領實現商業化佈局。
本文原創釋出於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議。
