導語：隨著支付寶小前臺，大中臺的概念獲得成功實踐後，越來越多的企業進入到中臺搭建的領域，但是不是所有的企業都需要中臺呢？本文作者以所在支付業務為例，向大家展示是否所有企業都需要搭建中臺。
在搭建業務中臺前，首先看一下是否有搭建中臺的必要，分析一下支付行業整體的發展方向。
自從2004年支付寶作為第一家第三方支付公司出現至今，支付行業經歷了從藍海到紅海的。以前支付牌照是香餑餑，監管不嚴格，利用牌照特性賺錢非常的容易。
現在央行也被支付公司一次次的套路中，學會如何進行監管，近年來鉅額的罰單接連不斷。監管意味著支付市場的空間被擠壓，中小支付公司更是前有AT兩大巨頭，後有監管。面臨以上種種情況，支付公司目前做的選擇有一下幾種：
1. 深耕支付領域、切入行業根據艾瑞資料《2020Q2第三方支付行業資料釋出報告》得知，支付行業依舊是支付寶財付通保持領先地位，但是在第二梯隊的情況在垂直的行業蓬勃發展。
例如：平安旗下壹錢包深耕在零售、金融、商旅行業，份額逆勢而上佔到了1.5%。
中小支付公司可以依據自身多年的經營特點，深入商戶的支付場景，根據行業特點與商戶共同搭建合規的支付系統，共同建立穩固的護城河。
同時還可以深入到平臺上下游的廠商、經銷商、品牌商等各個環節，透過支付服務、賬戶服務、供應鏈服務，並聯合物流服務平臺、金融服務機構幫助企業疏通產業鏈的各個堵塞環節，幫助整個產業鏈實現效能提升，進而達到對交易量、交易效率的改善效果，成功促成交易。
隨著近年來產業網際網路的推進，普通的產業會升級成數字化、線上化經營，這就伴隨著支付也必須進行線上支付。
這就給第三方支付公司對外輸出支付平臺的機會，支付機構可以轉型成為系統服務商，對外輸出技術服務，可以收取相應的技術服務費用。例如可以為政府繳費平臺、分銀聯支付平臺搭建支付底層服務與完整支付的賬戶體系。
根據艾瑞資料查詢的資料得知，目前第三方產業支付市場已經達到了百億級別，中小支付企業可以乘勢而上，加入產業支付升級的網際網路大軍中。
在面對支付寶、微信兩座大山面前，挑戰是必輸無疑的選。
那麼唯有選擇進行合作。在移動支付還沒有盛行之前，各支付機構主流採用的都是快捷支付、網銀等支付方式。部分商戶系統對接能力較差的，無法對接多個支付機構。
但是系統的支付穩定性又沒有保障，這時候就出現了四方支付機構。四方支付機構的特點就是一站式服務，解決商戶對接困難問題，保證支付的成功率。對接四方的費率就會高一些。
以前只有沒有牌照的支付企業才做聚合支付專案，稱作是服務商，主要針對的是B端的商戶。
但是中小的支付企業目前也是在搶佔聚合支付的市場，依靠自身擁有支付牌照，可以建立支付賬戶體系，可以進行清算的特性，搭建一站式聚合支付服務，為商戶提供一站式接入雲閃付、支付寶、微信支付、銀行APP等主流支付工具進行收款。
近期看到位元組跳動、攜程、京東、拼多多系列的牌照收購事件，在被央行監管、支付寶、微信多種擠壓下，很多中小型的支付公司已經沒有變現盈利的能力了，只能夠尋找新的變現渠道，那就是出售牌照。
而同時呢，行業巨頭有支付牌照的需求，不希望在自己的場景內，把支付業務的主動權拱手，但卻無法再申請新的支付牌照，兩者的需求互動，產生了一門新的生意——牌照收購。
所以許多擁有牌照的中小企業，可以依附於行業巨頭的樹蔭下，或者直接出售牌照的所有權，直接金盆洗手，不幹支付行業了。
5. 行業分析結果從目前來看，聚合支付市場以及行業支付領域都是比較飽和的市場，處於一片紅海，唯有外包服務服務，還是市場比較大 ，傳統的企業需要數字化轉型需要大量的外包業務服務。這就給支付公司的業務模式有很大的挑戰性。
一般支付公司的後端的邏輯是比較穩定的，為了契合業務方的需求，不斷的複製同一套程式碼，做定製化的業務改造，有些相同的業務也是在重複搭建，維護的時候相當的複雜。
在底層有變更時，需要同步變更多個服務，還需要評估變更對這些業務的影響有多少，可能有的影響多，有的不受影響，這就給中臺提供了機會。
二、業務框架梳理按照業務線的形式，梳理了兩條的業務線的產品架構，具體內容如下：
根據以上梳理的業務框架可以看出，兩條業務線之間重合部分比較多。這就導致了兩條業務線之間都分別重複搭建業務重合部分，這就造成了很多的資源的浪費。
除此之外並且會造成以下幾個問題點：
- 後端邏輯有改動時，兩邊業務得同時更改。這就造成後端上線有部分無法相容所有業務的內容，前端必須反過來相容後端的業務邏輯。
- 後臺的業務系統日漸趨於成熟，改動點比較難，如果有業務線有新需求接入時，需要相容的內容太多，會導致迭代的速度非常慢。
- 商戶資料未打通，各業務線容易形成資料孤島，無法聯合進行營銷、風控等。
以上圖框架中以雲閃付產品舉個例子，分別對應以上的問題點：
- 例如銀聯雲閃付業務變更，此時後端的邏輯邏輯進行了變更，需要必傳引數增多，此時需要同時聚合支付業務線和快捷業務線都得相應的進行改造。
- 聚合支付業務線向後臺業務提了一個需求，希望後端更新雲閃付的紅包功能，但是這個業務功能並不是快捷業務線所需要的，此時後臺就需要相容快捷線做相容考慮，可能會導致迭代的效率較慢。
- 由於聚合支付業務線剛起步，希望針對雲閃付的商戶做補貼。需要精準的找到補貼使用者有些，這些使用者在快捷業務線才有。此時聚合支付業務線只能依賴線下傳輸方式才能完成此時的補貼，使用者資料不斷變化的，每次做營銷活動都得進行線下活動整合資料形式才能完成，並且資料並非是實時資料，還不能和自身業務進行相匹配。
以上的三個案例充分說明了，當有多條業務共用一個後臺時，此時就會陷入多方同時維護同一個功能的地步，造成資源極大的損耗。同時會在公司內部不同業務線之間存在極大的資訊孤島，不利於公司的後續發展。
三、中臺業務梳理透過上面的資料分析完成後，說明還是很有必要構建業務中臺，在構建之前需要考慮清楚什麼業務的才能成中臺業務，這些業務如何才能體現中臺價值。搭建業務中臺最終目的是為了節約成本，包括人力成本、資源成本、時間成本等。
即當公司需要發展多條業務線時，這幾個業務有高度重合部分時，可以快速的進行迭代，並且所使用的資源是最少，簡單來說就是做一個產品需要價效比高，或者ROI（投入產出比）高。
1. 功能在各業務線使用的頻次在計算業務線使用的頻次之前，得先梳理系統的業務邏輯，需要具體到每個業務流程都使用了哪些功能。
以收銀為例梳理整個過程所用到的功能：
- 登入商家賬號使用的模組：商戶管理（商家狀態校驗、商戶資訊查詢）；
- 選擇收款方式：商戶管理（商戶開通產品）；
- 掃碼使用者二維碼：商戶管理（商戶資訊查詢、商戶狀態校驗）、賬務管理（賬戶狀態）、路由管理（路由查詢可用支付渠道）、訂單管理（建立訂單、優惠資訊計算）、通道管理（往上游上傳交易相關資訊，獲取使用者支付資訊）；
- 使用者確認支付：無（PS:使用者端輸入支付密碼，屬於微信、支付寶、銀聯等客戶端輸入支付密碼，與B端商家側系統無關，此處是為了流程更加暢通，方便閱讀）；
- 收款完成：商戶管理（校驗商戶資訊）、訂單管理（更新訂單狀態）、賬務管理（計算手續費、計算分潤、生成賬務流水）、賬戶管理（更新商戶賬戶餘額、更新手續費賬戶餘額、更新代理商分潤賬戶餘額）。
整理上述的功能模組複用情況如下：
根據上圖可以得知，聚合支付業務線商戶管理、訂單管理的複用次數最多，同時將其他行業線也一同梳理，最終將不同行業，相同功能模組的模組整理成一個表。
例如下圖展示：
以上表可以得出商戶管理、訂單管理佔據在整體比重較大，可以優先抽取至業務中臺，剩餘的模組需要根據公司業務進行評估處理。
2. 公司戰略目標在設計業務中臺時，還需要和公司的整體戰略目標相一致，中臺的威力才能完全體現。
因為中颱最大的作用就是複用能力，當公司業務重心在某一領域時，業務中臺應該契合公司業務重心，才能發揮作用，不然又是陷入重複建設的陷阱。
公司想把所有的賬戶進行打通，讓商戶接入不同業務線時，資金可以在不同業務線之間共用，而每個業務都有賬戶管理模組，此時就可以將賬戶管理模組統一化，建立統一的賬戶體系。當一個商戶對接多條業務線，資金不需要重複的進行提現充值動作，可以直接在不同業務線之間劃轉。
四、新業務框架根據業務梳理的情況，構建了新的業務框架，具體如下：
將前臺相同模組的業務進行抽取，簡化前端的業務邏輯，將大量的運算放置在中臺，同時前端業務不直接對接到後端。
後端有變動時，只需要中臺進行修改相容就可以，而不需要每個業務線都進行相應的整改，並且將業務資料進行打通，便於前端進行推廣或冷啟動時提供更多的商戶資料。
五、總結關於業務中臺是否需要搭建，主要還是根據公司業務情況而定，總結一下幾點：
- 如果企業業務是橫向拓展，並且相互之間沒有太大的關聯性，同時公司戰略也不是同時多業務線並行開發的，這種搭建中臺的必要性就不高。
- 如果業務集中在某一個領取或者業務之間的功能重合度比較高，此時可以考慮先抽取重合部分抽取組成業務中臺。
- 搭建中臺還需要關注行業動態，必須的捕捉行業的發展趨勢，因為中颱建立後，所有的前臺的業務都對接中臺，相關的業務承接方變成中臺。得中臺建立完成後，前臺才能完成相關動作，所以中臺尤為關鍵的就是捕捉行業的動態。不然跟不上發展趨勢，前臺業務可能會另起爐灶，自己重新建立業務系統。
本文由 @TOM 原創釋出於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。