起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識中臺系統建設之“屏障”思維
編輯導讀：中臺系統是一個很矛盾的板塊，一方面人們知道它很有用，能夠降本增效；另一方面，很多公司花費了大量時間精力去做中臺，卻沒有多大的效果。本文作者從自身工作經驗出發，圍繞“建立屏障”這一思維展開分析，希望對你有幫助。
備注：文中所述的中臺，特指電商業務中臺。
一、“屏障”思維的由來
在我之前寫的一篇總結文章《我做中臺這5年：轉轉中臺發展的整體回顧》中，我將過去轉轉中臺的發展分為了5個階段。
其中，對第四階段定義的關鍵詞就是“建立屏障”。也正在這個時間點之前，我腦海中有了屏障這個思維。
回顧當時的中臺內外環境，正如上邊圖中描述的那樣。
因為中臺在此之前，一直處于在能力建設和項目集中攻堅的階段，對公司對業務我們的交付原則是先有后優，導致中臺在內部建設投入的資源幾乎為0。
這種現在回想起來，只想別人不想自己的做法，其實是我的一個失誤。
因為問題集中爆發，不僅導致了中臺內部的并發事情壓力很大，同時業務對中臺評價負面也讓大家情緒很低。
二、定位問題與解法
面對以上狀態，其實感官上我們都能知道有很多問題，但是我們還是想要比較系統化地全面定位下問題。
于是，我們開始了較大范圍的內部產研訪談和外部反饋收集。
我們將問題歸納分析之后，按照以中臺為中心，大概有3個大的交互角色：上游業務方、終端用戶、下游業務方。
接下來，我們分別展開講解：
1. 上游業務與中臺之間
1）問題：溝通成本比較高，交付質量與效率低，對接感受不太好
經過深層次的分析，我們發現溝通成本高，是因為我們面向的溝通節點太多，畫了一張圖：
中臺面向的上游業務有很多，而中臺子域也有很多。它們之間的信息往來，基本就是以上雜亂的線條。
站在業務視角，中臺縱深邏輯復雜以及橫向聯動性強，造成每個業務需要與中臺多個人進行溝通，并且可能前后反復，對接效率降低；
站在中臺視角，每個子域，都會同時遇到有多個業務方與他溝通，響應質量變差，更別提能夠前置去了解業務動態，做動態預留和架構設計了。
于是，就形成了整體溝通成本高，對接感受差的結局。
2）解法：中臺BP機制&中臺平臺化系統建設
面對以上2個問題，我們找到了2個解題舉措：
第一個，是減少溝通節點，進而提升整體溝通效率，即形成“BP機制”的屏障。
第二個，是減少非必要溝通，讓系統沉淀取代人，即形成“平臺化系統”的屏障。
① 重構溝通協作節點
從業務視角來看，如何減少我的溝通節點呢？答案是一對一服務。
其實就是中臺BP的概念，這個BP概念其實很多人可能一點都不陌生，公司內很多部門也基本都設置有BP角色，例如hrbp、財務bp等。
中臺面向業務設置BP，應該能解決業務與中臺溝通1V1。但中臺與hr、財務還有一點不同，那就是對內對接成本也很高，因為中臺內部各產品域其實專業跨度非常大，例如支付、財務、物流、營銷等等。
所以，對業務的BP（第1重身份），有時候可能很難做到內部全局cover。那怎么辦呢？只能設置項目產品負責人（第2重身份），來具體橫向協作中臺內部各域的產品實現。
以上BP的設置，并不代表要新增人員，而只是讓人具備多重身份而已。
加上中臺自身垂直方向，產品天然的崗位職責（第3重身份），一個中臺PM可能最多會具備3重身份，畫個圖：
圖中，大家能很容易看出來，業務與中臺內部各域的關聯關系，由之前很雜亂的狀態，變為了以上較為有序的狀態。
在協作中，角色職責清晰，整體對業務大體做到了1V1。
當然，這個要想完全做到很完美的狀態，幾乎不可能。因為對中臺產品的要求太高了。
既然對業務的良好理解做到超前判斷，又要對內部全域系統做到全面了解，還有對上對下的強大溝通協作能力。
下圖中，大家感受下大中臺產品域的分類：
能勝任以上多重身份的人才，我們稱之為“業務架構師”。
不過，這個也是過去在實踐中，得到的唯一最優解。我們只能不斷完善和迭代，多多培養這樣的人才出來。
② 系統代替人：減少成熟場景下人的參與
以上BP機制，我們解決了信息流轉節點雜亂的問題。
對業務對接成本和效率來講，確實有了很大的提升。
但是，大家對中臺產品來講，從一個需求到落地，中臺所做的事情比之前應該是沒有任何減少的，甚至還由于身兼多重身份變得更多了。
所以，做到節點有序和減少還不夠，還需要讓信息流轉的次數變少和流速變快。
那怎么做呢？
在上篇公眾號文章《中臺規劃深度解析：用戶、機制、系統》中，我介紹中臺平臺化章節中，我提到了4個系統：
分別是：規則中心、配置中心、開放平臺、綜合查詢，我對它們也都有詳細的描述，見下圖：
其實，以上系統的核心，就是將重復的事情結構化，變為系統化，然后在業務與中臺之間建立漏斗。
一方面，可以讓業務自助解決一些問題，這樣信息就不用穿透到中臺。如開放平臺、規則中心、綜合查詢。
另一方面，通過系統化的方式，讓實現一個需求的過程變得有指引有配置，速率提升。如配置中心。
當然過程中，我們還做的有后臺系統統一導航、中臺對接人導航等等，道理也是類似。
2. 端用戶與中臺之間
業務與中臺之間的矛盾解決了，中臺產研面對另外一類用戶也會遇到難題。
因為這些用戶就是我們的終端用戶，即服務的線上C端買/賣家（回收會有C1賣家）和B端商家，還有一部分是線下作業人員（例如倉儲物流等）。
相對業務方這一內部項目需求用戶來講，終端用戶遇到問題一般都是緊急的線上問題，要求要及時響應。
1）問題：用戶穿透到中臺產研，沒有緩沖層，造成熱點嚴重
中臺本身提供交易能力，橫跨用戶交易的全部生命周期。一旦遇到問題，跟中臺的關聯度是極大概率。
而中臺本身的產品資源是稀缺的，我們有的崗位基本就是1個人，甚至半個人。
那么，就很容易會產生嚴重的熱點問題，導致產品精力受到牽制，會關聯影響其他更多的事情處理效率。
下面一張圖，是之前我們質檢方向一位產品的企業微信日常，大家感受一下：
一段時期內，中臺各個方向的PM，基本都是以上的狀態，99+的消息鋪開全屏幕，天天看消息看不過來。
2）解法：引入產品運營角色，工具賦能給運營
從中臺產研視角來看，如何減少咨詢和干擾呢？
面向以上問題，我們找到了解題思路：
就是必須在組織層面增加節點，招聘產品運營角色，形成“緩沖區”的屏障。
產品運營角色，需要發揮2個作用：
一個是由外到內，起到收攏信息、過濾信息、轉化信息的作用，提升產研處理信息的有效性；
另一個是由內到外，起到沉淀解決問題方法、宣導培訓用戶的作用，提升上游自助解決問題，減少問題到中臺。
另外，除了解決線上問題之外，產品運營角色還會牽引各種對接sop的建立，讓問題流轉機制趨于更加有序。
過程中，產品需要花費一些資源，做一些小工具，賦能給運營，提升解決問題的效率。
3. 中臺與下游（非生產系統，如客服、大數據、財務）之間
以上中臺打交道的兩類用戶，其實都會比較顯性，在交付上一個是“最重要”業務方，一個是“用戶第一”的用戶。
那其實還有一類用戶，我們會較難注意到他們，因為他們屬于非生產系統，一定程度上不會影響用戶交易進程。
但是，他們確實也服務著公司內部很多中后臺的業務用戶。例如，客服、大數據、財務等。
那中臺與他們之間會存在什么樣的問題呢？
1）問題：中臺業務數據分散，會造成下游與上游業務多點對接，成本高，數據統一性差
因為處于下游，很多時候，他們沒有太多話語權，所以過程中，慢慢也就會接受了很多現狀，不向上游提需求或提需求上游沒空“搭理”。
你想，在上邊這種中臺本身都沒有時間做內部建設的環境下，更不會有太多精力花在更下游的系統基建上。
以上造成最直觀的結果，就是下游需要兜底中臺沒有封裝掉的業務場景，需要一對多去進行解決問題。
畫個圖，大概就是這個邏輯：下游業務需要對接除中臺之外，還需要跟很多業務個性化信息去做識別和交互。
那這時候，下游各個業務的實現成本，其實是比較高的。
2）解法：中臺核心數據分散問題統一化
那怎么辦呢？還是用我們的屏障思維來解題。
即中臺數據統一化項目，將下游業務依賴的發散場景收斂到中臺，由中臺與下游一對一交互。即形成“數據統一化”的屏障。
畫個圖解釋邏輯如下：
在這里，中臺用框架包住了業務個性化的觸點，邏輯還是個性化，只是不對下游感知了，中臺變為了和下游對接的唯一觸點。
到這里，我們將中臺對接的3類用戶，所遇到需要建立屏障的情況做了詳細說明。
總結一張圖，便于大家記住。
到這里，就是我過去在中臺建設實踐中，關于“屏障”思維的一些思考。
其實，也都不是很多東西一開始就能想到，而是遇到問題一點點去解決，后續慢慢形成的歸納總結。
見招拆招，只要一心去解決問題，就必然會有所悟、有所得。
作者：減形簡遠，微信公眾號：產品雜談（life_pm）
本文由@減形簡遠 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
中臺BP的這個思路真的獲益匪淺，能請教一個問題嗎？如何給中臺BP這個職位制定考核指標？
具體到事情上，會看輔助對口業務一個個項目的推動和落地結果。因為bp本質是希望增加鏈接效率，所以也會看業務、中臺內部 這上下兩層的滿意度反饋。
以中臺為中心，大概有3個大的交互角色：上游業務方、終端用戶、下游業務方。