編輯導讀：中台系統是一個很矛盾的闆塊，一方面人們知道它很有用，能夠降本增效；另一方面，很多公司花費了大量時間精力去做中台，卻沒有多大的效果。本文作者從自身工作經驗出發，圍繞“建立屏障”這一思維展開分析，希望對你有幫助。

備注：文中所述的中台，特指電商業務中台。

一、“屏障”思維的由來

在我之前寫的一篇總結文章《我做中台這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協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部