本文是我在7月份人人都是產品經理舉辦的產品經理大會杭州站的主題演講，基于演講提綱重新撰寫了文章，意圖從全新的角度探討、解讀中臺產品建設問題，讓你更加深刻地理解中臺設計精要。

前言

中臺建設，是近兩年非?；馃岬囊粋€話題，從產品中臺，到技術中臺，再到組織中臺，各種概念、理念，以及方法論被深度的研究、探討。

對于互聯網產品領域來講，中臺更多的是2B產品建設中涉及的課題，因為軟件系統的抽象復用，更多的是做復雜B端系統建設中面臨的問題。因此，中臺產品設計，是所有B端產品經理應該深度關注的課題。

針對B端產品設計領域，中臺產品到底該如何設計？有何特點？設計的本質是什么？有何挑戰？本文將從全新的視角，重新審視中臺產品建設，讓您更加深刻地理解中臺產品設計精要。

1. 經典視角下的中臺建設

首先，我們有必要回顧下經典的中臺建設視角。一般來講，行業內往往從組織中臺、產品中臺、數據中臺、技術中臺這四個主題切入并探討中臺建設。

（1）組織中臺

組織中臺研究的是企業內部的組織結構設計，如何通過合理的權責劃分，以及管理架構搭建，提高業務部門的經營能力，迅速響應市場變化，并且能夠讓企業提升整體跨部門跨業務線協作效率，降低運營成本，實現標準化管理。

所謂組織中臺的設計思路，實際上已經存在了很多年了，在集團企業中，往往采取事業部制的組織形態，再配合各種共享服務中心的建設，實現前后端業務分離，前端業務保持機動性，后端業務提供火力支援。

類似于財務共享服務中心FSSC（Financial Shared Service Center），人力資源共享服務中心HRSSC（Human Rersources Shared Service Center），其實就是典型的中臺管理思路下的組織形態和職能部門建設的方法，如下圖。

一個常見的事業部制的組織機構圖

（2）產品中臺

產品中臺研究的是企業內部的軟件系統如何進行抽象和設計，從而讓企業的軟件系統就像搭建積木一樣靈活，可以重復高效利用現成的軟件組件，快速組裝開發出新的軟件系統，從而節約軟件開發成本，并能夠快速支持新業務開展。很多文章也把這類中臺產品稱作業務中臺，或業務中臺產品。

目前被廣泛討論的產品中臺包括電商交易中臺、賬號中心中臺等，其中電商交易線又被更加廣泛的探討，包括了訂單中臺、支付中臺、商品中臺、促銷中臺等。產品中臺還有另一層含義，即能夠給全公司全企業提供一致服務的管理軟件產品，也可以納入產品中臺的范疇，例如呼叫中心、項目管理軟件。從某種程度上來講，這些標準化軟件產品也是中臺產品。

（3）數據中臺

數據中臺研究的是企業內部的數據管理、治理問題，以及數據產品體系和數據底層結構的搭建問題。數據中臺研究的范疇，包括企業統一的數據安全、數據規范、元數據管理、數據編碼管理，以及數據倉庫、數據集市的拓撲架構，也包括大數據底層和運算能力建設和復用。

要注意的是，數據中臺更多的關心從業務和產品層面對數據的治理、管理、應用，而非技術層面問題。

（4）技術中臺

技術中臺研究的是軟件產品的技術實現過程中，哪些技術上的處理能力和架構可以進行抽象復用，例如：消息中間件MQ，分布式計算框架Hadoop，分布式服務框架HSF，各種Open API等等。技術中臺是純粹從技術實現底層來思考基礎服務和基礎模塊的復用能力，其設計思路和產品中臺一脈相承，是技術人員需要深度思考的問題。

以上四個主題，涵蓋了互聯網模式下對于企業中臺建設的所有課題范圍:。其中，對于產品經理來講，工作相關性最強，最需要關注的是產品中臺和數據中臺。

實際上，上述四個主題，也正是傳統企業信息化建設中非常核心的企業架構EA（Enterprise Architecture）理論，對企業業務管理的IT視角下的切分。

其中組織中臺對應EA中研究的企業業務架構EBA（Enterprise Business Architecture）中的組織架構治理部分，產品中臺對應EA中研究企業應用架構的EAA（Enterprise Application Architecture），數據中臺對應EA中研究企業數據架構的EDA（Enterprise Data Architecture），技術中臺對應EA中研究企業技術架構的ETA（Enterprise Technology Artchitecture）。

關于EA的論述，可能讓很多純互聯網背景的同學讀起來很困惑，但實際上，互聯網企業所謂的中臺建設思路，逃不出經過幾十年沉淀的信息技術理論框架，以及管理理論框架。而傳統信息技術理論，在互聯網企業的B端產品建設中具有極強的參考、借鑒價值。

然而，我們今天討論的主題，還不是研究企業架構EA對中臺建設的指導，而是嘗試從更加深層次的角度，去探索產品中臺、數據中臺的設計本質，尤其是對于B端產品經理來講非常核心的產品中臺的設計精要。

對于產品中臺，目前公認的關鍵要點包括如下關鍵詞：企業級、抽象、下沉、復用，這些關鍵詞代表了產品中臺建設的特點，同時也是在企業應用架構設計中需要深層次思考的問題。（所謂企業應用架構，是指企業內部的各個軟件系統，應該以什么樣的形式建設、組合，從而高效的支持企業的經營運作）

因此，如果要深層次的思考軟件產品的企業級抽象、下沉、復用問題，可以從以下三個角度進行全新的審視，分別是：基于抽象復用的視角，基于架構合理性的視角，基于業務統一管理的視角。

我們通過從這三個視角切入，可以全面的解構中臺產品設計的要義，并且可以更加全面的窮舉中臺建設的方法論、要點和難點。

基于抽象復用的視角建設中臺

1. 建設的目的

所謂抽象復用，是指對軟件中重復的功能和模塊進行抽象并下沉一層。

什么叫抽象？什么叫下沉？我們舉例說明：

如下圖，有兩個系統I和II，其中系統I中具有模塊M，系統II中具有模塊N，經過分析發現，模塊M和N的功能高度類似重復，完全可以抽象合并，避免重復建設。

識別共性模塊

現決定將模塊M和N分別從系統I和II中剝離出來，如下圖：

抽離共性模塊

將M和N剝離出來后，我們對其功能進行抽象合并。M和N合并后，得到模塊A + B + C，其中A是M和N中共有的功能，B和C分別是針對系統I和II提供的一些定制化功能。雖然有少量功能無法做到完全合并和復用，但新模塊中絕大多數功能集合A已經被高度抽象，可以被系統I和II復用。而被剝離合并后的全新模塊A+B+C，將會下沉一層，作為基礎服務，為系統I和II提供支持。

如下圖：

合并共性模塊

以上案例，演示了系統功能如何被合并、抽象、下沉，這種設計思路，節約了軟件研發成本，是一種非常經典的中臺設計思路。

接下來，我們通過一個實踐案例，進一步演示這種設計思路。

2. 案例：統一客戶視圖建設

案例背景：

某流量型互聯網公司，變現模式主要為針對中小企業的廣告售賣，業務團隊包括電話銷售團隊（IS，Inbound Sales），外勤線下銷售團隊你（OS，Outbound Sales），以及客服團隊。

三個業務團隊有著各自獨立的業務系統支持其運轉，每個業務系統中既有個性化功能，例如：針對IS的外呼管理、針對OS的拜訪管理、針對客服的關懷回訪；也有功能高度類似的重復功能，例如：客戶管理列表，客戶詳情頁。

系統架構圖如下圖所示：

重復的客戶詳情頁建設

遇到的問題：

三套業務系統各自有產品研發團隊維護，系統早期為了快速支持業務從而分別建設，快速響應業務訴求，為業務發展立下了汗馬功勞。但隨著系統的逐步成熟，其中一些問題也逐漸凸顯，首要問題就是功能重復開發建設問題。雖然三個業務部門對客戶關注的側重點不同，但基本訴求是一致的，希望能看到客戶所有的重要信息。

因此，三個系統的客戶詳情頁功能已經高度類似，而每次針對客戶資料的調整變化，需要三個研發團隊分別重復開發三遍，非常浪費人力資源。

解決方案：

為了解決三套業務系統中高度類似的客戶詳情頁的重復開發問題，也為了給業務人員提供一致的、準確的客戶視圖，公司決定將客戶詳情頁模塊從三個業務系統中剝離，將功能合并后，建設“統一客戶視圖（ECIF）”模塊，該模塊擁有一致的客戶數據底層，并提供完整的客戶信息查詢服務化接口，以及可以嵌入業務系統直接使用的客戶詳情頁面組件。

“統一客戶視圖”將作為中臺產品，為各個業務系統提供企業客戶數據查詢的服務以及視圖。如下圖：

將客戶詳情頁抽象下沉建設統一客戶視圖中臺

任何業務系統，既可以調用該模塊的成熟接口查詢客戶數據并自己設計前端頁面，也可以直接嵌入“統一客戶視圖”提供的現成的客戶詳情頁組件，并且該頁面組件還可以進行靈活的權限配置，定義針對不同的業務系統、不同用戶角色的數據查看、編輯范圍。

由此，我們完成了對客戶詳情頁的抽象下沉，三套曾經重復開發的頁面被合并成了一套，以后研發團隊只需要維護這一套頁面，研發人力得到了釋放。

這就是典型的基于抽象復用的視角設計的中臺產品。這種模式有一個顯著特點，即軟件的抽象和復用是成本問題，不影響業務。案例中，雖然有三套客戶詳情頁被重復建設，但只是個資源浪費問題，并不會影響到業務的開展。

3. 面臨的挑戰

對軟件功能模塊進行抽象復用，是具有很強挑戰性的工作。如果分析不當或經驗不足，有可能做出錯誤的抽象方案。

我們總是希望能夠對軟件和功能進行正確的抽象決策，讓抽象出的系統和模塊具有高度重疊的特性，例如下圖這樣：

期望的抽象結果

然而受限于經驗不足，或掌握的信息不足，很可能做出錯誤的判斷和設計，做出了錯誤的抽象決策，最后被抽象的系統模塊，并不能被充分復用，只是制造了一個畸形的別扭的模塊，生硬的把一堆毫無關聯的功能強行捏在一起，給研發工作反而帶來的更大的麻煩，如下圖。

錯誤的抽象結果

我們將通過實際案例，給大家演示這種設計錯誤。

4. 案例：訂單中心的建設

案例背景：

某互聯網公司同時開展了電商業務和電影票業務。每條業務線都有獨立的C端系統、后臺交易系統（包括商品管理、訂單管理、促銷管理）來支持業務。為了追逐潮流，公司決定將兩條業務線的訂單中心合并，實現訂單中臺，如下圖：

并不一定正確的訂單中臺

錯誤的決策：

實際上，公司經營的B2C電商業務和影票業務，在交易形態上有較大區別，尤其體現在訂單模塊的設計上，訂單的狀態機、數據模型和財務賬務處理模式完全不同，強行將兩者合并后，并沒有太多的共性模塊和功能，最終只是表面上看起來實現了訂單中臺，但是里邊的功能模塊各自獨立，各自運轉，完全沒有抽象和復用。

擴展難題：

現在，公司管理者以為擁有了強大的“訂單中臺”，可以為任何新業務的快速開展提供支持。很快，公司決定開展機票售賣業務，針對機票業務，有獨立的C端，商品管理，促銷管理。但是當產品經理和工程師開始期待訂單中臺的強大能力時，遺憾的發現訂單中臺無法給機票業務提供任何現成的功能復用能力，機票的訂單模型和電商以及影票都不相同。

機票業務線的設計人員面臨一個尷尬的局面，要么“政治正確”的將機票訂單中心納入訂單中臺統一建設，但實際上這會嚴重降低開發效率。因為中臺研發團隊肯定不會像機票業務自己的研發團隊那樣重視新業務的開展，要么就拋棄訂單中臺，自己獨立開發訂單模塊，但這樣做又會顯得訂單中臺沒有產生該有的價值。

如果你是機票業務的負責人，該怎么權衡取舍呢？此時的系統架構如下圖：

訂單中臺并不能很好的支持機票業務

可見，訂單中心，在不同業務模式下，并不一定適用于中臺化建設，設計人員要有足夠的思辨能力，判斷產品形態上是否值得抽象下沉，是否能夠提供復用能力。然而這也是軟件工程設計中非常難的部分。

任何軟件系統的設計，都是基于歸納法，而非演繹法，即軟件設計人員總是通過對現有世界和業務的總結提煉，完成軟件設計，而無法通過推測演繹，完成軟件設計。設計人員無法對業務的未來做出預測，只能基于有限的經驗，盡量的保證設計的靈活性和正確性。

理解這一點非常重要，這會讓你在軟件設計、產品設計時心存敬畏之心，不會一味地追求短期無法論證的結論而產生的嚴重的過度設計。

5. 實踐中的建議

以下是基于抽象復用的視角建設中臺的幾條建議。

（1）明顯具備共性的模塊盡早抽象

B端產品的體系化設計中，很多形態的產品是具備明顯共性的，可以盡早的進行抽象設計，這樣在系統架構建設的早期，就能做出正確的設計方案，而且并不會增加多少研發工作量，但會讓未來的系統擴展更加輕松。例如：業務系統的統一權限管理系統、單點登錄系統、組織架構系統、公告系統、短信系統，這些系統都應該盡早抽象建設。

（2）不確定共性的模塊事后抽象
例如統一客戶視圖、訂單中心、商品系統，這些軟件模塊，很難判斷在多業務線場景下能夠完全復用，如果對于是否抽象拿不準主意，完全可以先不做抽象，等業務漸漸明確后，有足夠的信息作出充分的分析和判斷，再決定是否合并抽象。

（3）避免人力外包中臺

中臺的建設一定要有合理的原因，如果只是為了中臺而中臺，會讓系統的架構混亂，工作效率反而降低。而且很容易產生“人力外包中臺”現象，即下游業務團隊把中臺團隊當做乙方來合作，“反正你們要幫我們打理好這些模塊，不管是否合理，需求提交給你就必須得高優支持，否則就是不支持業務一線”，這樣會讓中臺產品和中臺團隊失去該有的氣質，形成團隊間的敵意和隔閡。

基于架構合理性的視角建設中臺

1. 建設的目的

軟件的應用架構設計，不是隨意任性的系統、模塊組合，而是有著深刻的設計方法論與合理性訴求。為了滿足應用架構合理性的要求，很多時候需要將軟件抽象并下沉一層。

所謂應用架構合理性，是為了避免因為應用架構設計的不合理，而造成業務問題。企業中軟件系統的建設，很容易出現兩個常見問題，一個叫做煙囪應用，一個叫做數據孤島。

企業內部的軟件系統，很多都是為了某個獨立的業務部門而設計研發，例如：CRM，WMS，OA。這些系統設計初衷是支持業務部門的獨立運作，而企業內部跨部門的業務流程和數據傳遞是無處不在的。

如果業務系統沒有做很好的架構設計或服務化處理，那么系統之間就無法通信交流，業務流程就會被割裂，每一個應用系統就像一根根煙囪一樣，互無聯系，這就是“煙囪應用”。煙囪應用會造成部門墻，讓企業的業務無法順暢流轉運作。

煙囪應用

因為煙囪應用的存在，每個應用系統生產的數據會更加孤立，系統之間數據沒有關聯，沒有打通，系統之間的數據就像一座座孤島，彼此獨立，數據的價值被嚴重弱化，數據孤島會造成嚴重的業務問題。接下來的案例，會演示數據孤島問題，以及如何通過中臺化的架構設計思路解決該問題。

數據孤島

2. 案例：客戶主數據的建設

案例背景：

某公司開展了線下零售店和線上商城兩條業務線，由于這兩條業務線開展之初是獨立經營建設管理，因此系統建設也是由兩個產研團隊分別負責，這就造成了線上和線下業務分別有一套客戶數據庫。

現在公司設立了獨立的客服一級部門同時服務于線上線下業務，而客服人員使用的客服業務系統，是不能同時訪問兩套客戶數據庫的。因此只能將兩套客戶數據庫冗余成一套針對客服業務系統使用的客戶數據庫。此時，公司內部一共有三套客戶數據庫，各自像孤島一樣存在。

如下圖所示：

客戶數據存在孤島

遇到的問題：

顯然，上述應用架構存在嚴重的數據孤島問題，并且會產生嚴重的業務問題。具體如下：

• 線上客戶如果想體驗線下服務需要重新注冊會員，客戶體驗極差
• 線下客戶如果想體驗線上業務需要重新注冊賬號，客戶體驗極差
• 線上線下客戶數據重復，無法識別唯一性
• 呈現給客服人員的客戶數據是同步后的具有滯后性
• 客服無法準確識別客戶信息并幫助客戶修改資料
• 企業無法做線上線下客戶消費的關聯性分析，無法做交叉銷售

解決方案：

因為應用架構設計的不合理，導致業務受到嚴重影響，客戶體驗差。如何解決多個業務系統中存在的數據孤島問題呢？

實際上解決辦法也很簡單，就是將客戶數據庫合并后只保留唯一的一份客戶數據資料，所有下游業務系統都訪問這個唯一的客戶數據庫，進行客戶數據的增刪改查操作。此時，系統之間的拓撲結構發生了改變，新的應用架構圖如下圖：

通過主數據設計思路解決孤島問題

這種針對企業的核心的、相對穩定不容易變化的、被充分共享的數據，叫做主數據MDM（Master Data Management），通過主數據的設計思路，可以很好地解決煙囪應用和數據孤島問題，尤其是數據孤島問題。主數據作為一種基礎服務，正是一種中臺化的治理理念。企業內常見的主數據包括客戶主數據、供應商主數據、組織機構主數據、商品主數據等等。你可能之前沒有聽到過主數據的概念，但仔細想想，實際上主數據在B端產品的架構設計中時刻存在。

基于應用架構合理性的視角來構建中臺，這種模式的特點，是軟件的抽象和架構設計會影響業務，這和基于抽象復用的視角構建中臺有著顯著地區別，前者如果不做抽象和下沉，會造成很多業務問題，例如案例中提到的客戶管理問題；后者如果不做抽象和下沉，只是成本問題，不影響業務，例如之前統一客戶視圖的案例，雖然開發資源浪費，但系統的問題并不會影響業務開展。

3. 面臨的挑戰

有時候，對于企業來講，正確的架構并不一定是合理的選擇，反而錯誤的架構可能更有益于業務發展。理想化的架構設計，可能反而會拖慢業務節奏。這是架構設計中經常面臨的問題，我們通過一個案例來進行闡述。

4. 案例：賬號中心的建設

背景：

某互聯網公司起家于短視頻業務，業務發展良好，市場占有率高，短視頻產品功能形態豐富。公司基于各方面考慮，決定同時開展理財業務，希望在火爆的P2P市場中狂歡一場。

公司的短視頻業務的賬號中心，建設初期就采用了服務化的思路，因此很好的和短視頻前臺業務的C端APP實現了解耦合，實際上已經實現了中臺化的建設部署。面對新開展的理財業務，產研負責人決定復用一套賬號中心（Passport），從而發揮中臺產品優勢，為新業務賦能。

理財業務的產品技術體系是獨立的，雖然想完全獨立研發所有的前后端系統，但是迫于壓力，不敢違背公司搞大中臺、小前臺的指導思想，決定復用基于短視頻業務構建的賬號中心中臺來開展業務。

整個架構圖如下圖：

理財業務復用了短視頻業務的賬號中心中臺

遇到的問題：

賬號中心作為中臺產品，除了為短視頻業務提供服務，還能快速賦能新業務，支持理財業務開展業務。理財業務只需要建設對應的APP C端和簡單的管理后臺，對于比較復雜的賬號中心，完全不用浪費人力從頭開發?？雌饋?，完美的架構發揮了優勢，支持了業務。產研負責人很開心，中臺理念得到了落地，在老板面前有面子。然而事實真的如此么？

理財業務開展過程之中，需要針對賬號中心做較多的個性化功能定制，例如需要實線賬號的信用認證管理，地址管理，銀行卡管理等等，相對于短視頻業務的賬號中心，理財業務對賬號中心的功能要求、安全性要求、風控要求更高。

理財團隊給賬號中心提交了一堆需求，但是賬號中心的響應速度非常緩慢，因為兩個團隊不是一個產研體系，也沒有管理關系，賬號中臺團隊總是將理財業務的需求優先級調到最低。

因為賬號中臺的響應速度慢，理財業務負責人多次找老板溝通協調，但公司對待理財業務的態度又變的有些曖昧，并沒有保持最強有力的支持。這下就比較尷尬了，理財業務雖然有自己的研發團隊，但是賬號中心用的卻是中臺的，而中臺團隊又不是很支持理財業務（按照中臺團隊的說法，理財業務提交的需求個性化太強，工作量巨大，對短視頻業務一點價值都沒有，投入產出比低，優先級低），導致業務進展緩慢，不能很好地支持客戶需求和業務發展訴求，浪費了寶貴的競爭時間，只能眼睜睜的看著對手攻城略地，越走越遠。

可見，設計了正確的中臺產品，以及保證了架構的合理性，在某些情況下，反而會影響到業務的快速發展。

5. 實踐中的建議

架構設計的核心目標是支持業務發展，某些時候可以允許不合理的架構存在。

在Passport的案例中，理財業務實際上是按照獨立公司、獨立品牌運作的，包括產品研發團隊都是獨立的。作為一個不確定性高、市場變化迅速的創新業務，極有可能運作半年后項目就中止了。

這時候業務上更希望保持快速的響應和落地能力，而不是考慮軟件架構是否合理，即便理財業務獨立開發了Passport，即便理財業務發展成功、最后又需要將兩套Passport合并，即便兩套Passport合并非常麻煩，成本高。但是，至少業務通過快速響應，迅速切入市場，取得了成功。

而且，有些時候，所謂的中臺化改造，架構合理性設計，會嚴重影響到原有系統和業務的穩定性。例如：假設新開展的B2B業務，要復用B2C業務的訂單中心，將B2C業務的訂單中心實現中臺化改造。

B2C業務作為公司的核心主營業務，承擔了每日十幾萬的訂單交易量，營收占公司整體營收的95%。而B2B業務作為創新實驗項目，預計每個月只能帶來幾十萬的GMV，并且，如果要將B2C的訂單中心中臺化，兼容B2B業務，要承擔非常高的系統改造風險。

那么問題來了，有必要為了架構合理的中臺化建設，而承擔高風險（甚至有可能把主營業務的核心B2C訂單系統干趴下），去支持小體量的創新業務么？

產品設計人員、架構師、產研負責人，在面臨這些問題時，必須謹慎思考，基于對業務、市場、系統、代碼、架構、人員、團隊，各方面進行綜合判斷后，做出決策，即便有時候做出的決策在系統架構上看起來是錯誤的，但對于公司和業務的長遠利益來講上是正確的。

基于業務統一管理的視角建設中臺

1. 建設的目的

企業發展到一定階段后，往往會出現集中化管理的訴求，對之前各自獨立的子公司、事業部，在某些方面實現集中化的管理控制，一方面為了加強集團管控能力，另一方面也是因為業務協同經營需要。

如果想實現這類業務訴求，就必須通過對軟件的下沉和抽象，來實現業務的集中化管控。下邊，我們來通過案例進行說明。

2. 案例：集團多業務線的統一客戶銷售管控

案例背景：

某保險集團經過多年發展，實現了壽險、財險、理財穩定的業務三角。三條業務線分別由獨立的全資控股子公司經營，三家公司的所有業務系統，從C端到B端，也全部獨立建設，互無交集。簡化版的系統架構如下圖。

某集團三條業務線下的系統架構

業務訴求：

三家公司獨立經營，保持了充分的靈活性，能夠快速響應市場變化，取得了成功。但是，隨著經營的深入，有一些問題也逐步暴露，并且變得越來越嚴重，總部高度關注，需要盡快解決，典型問題如下：

• 三家公司經常出現重復采購流量的現象，浪費集團營銷成本；
• 三家公司往往對同一個客戶重復營銷，造成客戶投訴；
• 客戶價值不能充分挖掘，跨業務線的交叉銷售和向上銷售做的不好；

現在，集團下定決心解決這些問題，而解決這些問題，必須通過軟件產品的中臺化建設來實現。

解決方案：

針對集團面臨的三點問題，解決方案如下：

1. 建立集團的統一客戶標識數據庫（作為集團統一客戶管理中心的核心模塊來建設），從集團層面識別客戶唯一性，確保各個業務線采買流量時能夠正確過濾已有客戶，節約成本。
2. 具備客戶唯一性識別的能力后，可以實現集團層面的統一客戶營銷管理、客戶旅程管理、以及防騷擾控制。通過統一客戶管理中心實現客戶旅程模塊、防騷擾控制模塊，將控制策略插入到各個子公司的銷售系統中，確保各個子公司的銷售觸達任務開始之前首先要經過集團層面的控制中心的校驗和管理，從而確保同一客戶不會同時被幾條業務線的銷售重復騷擾。
3. 統一客戶管理中心還可以實現交叉銷售模塊，針對某些業務場景下的客戶數據，進行跨業務線的銷售任務分發，例如識別某壽險客戶經濟實力較好，則將客戶推送到理財業務的銷售系統，嘗試二次銷售轉化。

整個系統架構如下圖：

通過集團統一客戶管理中心實現跨業務線的客戶銷售管控

綜上可見，集團層面，如果想對各個子公司的客戶資料、客戶營銷、客戶觸達進行統一管理，就必須建立統一客戶管理中心，首先實現客戶唯一性標識，其次基于客戶唯一性標識落地各種統一客戶管理策略。集團統一客戶管理中心，正是中臺設計思路的實踐應用。而集中化的業務管理訴求，則必須通過軟件的抽象和架構設計來實現，這也是這種中臺建設模式的特點。

3. 面臨的挑戰

業務集中管控的策略，總是滯后的，這是因為業務開展很長的一段時間中，各個業務線獨立運作，相安無事，即便有一些小問題，也是可以容忍的，或無關緊要的。但是當企業規模增長到一定階段，業務線之間的管理問題會越來越突出，之間的協同問題也會越來越明顯，此時就有必要進行集中化的管理和控制。

滯后的業務管理決策，會對系統建設帶來較大的挑戰，因為各個業務線、事業部、子公司的系統已經發展的非常成熟，針對成熟的系統，去調整架構，改變系統和業務的邏輯，置入新的外部邏輯，是一件很有挑戰的事情。

針對未來可能的集中管控訴求，是否能夠在系統架構上提前布局，做好結構性的設計，以便未來的某一天，業務需求發生時，能夠順暢、輕松的進行支持么？

實際上這也是不現實的，因為業務上的需求是一個未知數，沒必要對未知的需求做架構上的過度設計。

總之，集中化的業務管理訴求總是滯后的，這會給系統、中臺的設計和實現帶來挑戰。設計人員要對這個問題有清晰地認知。

4. 實踐中的建議

針對業務集中管控訴求下的中臺建設，有以下建議：

（1）不要過多考慮未來不一定發生的事情

集中管控是不一定發生的需求，產品設計初期和中期，沒有必要為未來不確定的事情提前做過多的布局，因為很有可能未來根本用不到，卻會產生過度設計，造成開發資源的浪費，甚至也會讓系統架構看起來非常奇怪。

例如：案例中的集團客戶管理中心，在壽險、財險發展初期和中期，有必要在系統上做出這樣復雜的架構設計么？在各自獨立經營的子公司推進這種架構的落地，如果沒有明確的收益和價值，難度和成本巨大。

（2）通過業務價值和業務訴求驅動系統迭代抽象

沒有明確的收益和價值，卻采用了這種集中控制調度的軟件架構設計，這會讓各個事業部的核心銷售系統被割裂，被控制，被牽制，恐怕各個事業部是不會愿意配合這種項目的。即便這種架構很合理，在可預期的未來一定是必須的，但是在當前階段下卻沒有任何價值，還會影響各個事業部各自的工作。沒有業務價值和業務訴求的系統迭代抽象工作，是很難推動落地的。

（3）項目必須有高管介入確保推進

即便業務上已經有明確的訴求，公司決定了執行架構調整，實現集中管控，項目的推進，依然會阻力重重，因為這種調整首先會打破原有的利益格局，也會造成工作習慣的巨大改變。這類集中管控的項目，如果想成功落地，必須有集團層面的，超越了各個下游業務線的非常高級別的管理人員牽頭掛帥，管理團隊必須有統一的認識，通過強有力的項目管理手段，才能保證在項目執行過程中化解任何困難，成功落地。

三種視角下中臺建設模式的總結

我們已經分別介紹了基于抽象復用的視角、基于架構合理性的視角、基于業務統一管理的視角，這三種視角下的中臺建設模式，以及每種模式的建設目的、建設特點、面臨的挑戰。

匯總后得到下表：

這三種視角（或叫三種模式），從左到右，業務屬性從弱到強。即最左側的抽象復用的視角，純粹是成本問題，和業務關系不大；中間的架構合理性的視角，具備了一定的業務含義和業務價值；最右側的業務統一管理的視角，則完全是個業務問題了。

任何系統的中臺化建設，都可以從這三個視角中找到影子，要么是基于其中的某個視角建設，要么是基于其中的某兩個視角來建設。

例如：統一客戶視圖、報表引擎，這類產品純粹是成本問題，遵循著抽象復用視角下的中臺建設特點。主數據、賬號中心、數據集市，這類產品兼具了架構問題和業務問題，遵循著后兩種視角下的中臺建設特點；而防騷擾、大積分體系（即集團多套積分體系的打通和匯兌中心），則純粹是基于業務出發而建設的產品中臺，遵循著業務統一管理視角下的中臺建設特點。

在很多情況下，中臺產品兼具了多種屬性，例如，訂單中心、賬號中心、組織機構管理、權限管理，這些中臺產品，既是研發成本問題，也是架構問題，同時還會影響業務。再例如，支付、清結算、促銷重心、商品中心等中臺產品，則既是為了解決業務問題，也是為了解決架構問題，同時也可能還解決了成本問題。

總之，上述三種中臺建設的視角，在一定程度上窮舉了產品中臺（即產品經理關注的軟件產品的中臺化，也就是媒體上常說的業務中臺）建設中的所有出發點和可能性。你可以思考下，目前你所接觸的中臺，是否處于上述三種視角下的某一種或某幾種，通過我們的論述，你是否對相關中臺產品設計的特點和要點有了更深刻的認識和理解呢？

插播一條廣告

大家好，我是《決勝B端》作者楊堃，曾在VIPKID任產品總監一職。在工作中，遇見有很多優秀的B端產品經理，但缺少體系化、針對B端產品的實操訓練，在成長中走了許多彎路。

我努力將自己多年做B端產品的經驗提煉總結出來，和起點學院聯合打造了一門B端產品體系課——《To B產品實戰訓練營》希望能給需要的同學一些實質性的幫助。

幫助大家構建B端產品知識體系脈絡，掌握B端產品建設，從業務診斷、需求分析，到抽象建模、設計落地的全過程的方法思路，最終直接應用于工作實踐。

掃碼即可報名，還可為大家爭取到的專屬優惠~

立即搶座，報名成功后即可領取詳細課程資料！

作者：楊堃，《決勝B端》作者，微信號公眾號：goYangKun，11年互聯網研發、產品設計經驗，曾就職于傳統外資保險公司、百度，現就職于vipkid。

本文由 @楊堃 原創發布于人人都是產品經理。未經許可，禁止轉載。