中臺規(guī)劃深度解析:用戶、機制、系統(tǒng)
編輯導(dǎo)語:中臺這一概念從提出到大熱,如今,已有不少企業(yè)開始組織架構(gòu)的調(diào)整,搭建中臺,那么如何更好的了解和規(guī)劃中臺呢?本篇文章中作者對中臺規(guī)劃進行了深度的解析,一起來學習一下。
一、問題:業(yè)務(wù)有經(jīng)營指標,中臺有沒有?
之前在參加OKR匯報會時候,發(fā)現(xiàn)一個非常明顯的現(xiàn)象。
前臺業(yè)務(wù)團隊的OKR,幾乎都每一條都有可量化的指標。
例如:
- 訂單業(yè)務(wù)部門,有單量、GMV、營收、NPS等指標;
- 金融、商業(yè)等營收部門,有收入指標;
- 就算履約,也有各種人效、產(chǎn)能、滿意度等指標;
有指標,就代表你的OKR結(jié)構(gòu)和你日常做事情的框架基本上是穩(wěn)定的。
你需要做的就是不斷讓指標變得更好。
另外,就是除了指標之外,業(yè)務(wù)部門和履約部門,還有一個特點,就是他們都會一個集中服務(wù)的用戶,這個用戶可能是C、可能是B、也可能是作業(yè)人員(例如客服、倉配等)。
過程中,大家會對用戶保持高度聚焦,并不斷研究如何服務(wù)得更好。
那中臺呢?
我在寫OKR的時候,其實就很少能具備以上2個屬性來拆解。
我用的最多的框架,就是分為【業(yè)務(wù)重點項目支持】、【口碑體驗】、【中臺內(nèi)部建設(shè)】、【團隊】,大概邏輯就是按照我服務(wù)的用戶來劃分的。
我可以講解每個事情的邏輯閉環(huán),但是從匯報效果來看,大家可能還是覺得我們在搞一個個項目,沒有一條主線。
在日常工作中,其實也不止一次被童鞋問起以下問題:
例如:
- 中臺面向的用戶是多樣化的,有時候跨度很大。那這些用戶的關(guān)系是怎么樣的?
- 中臺大部分時間,是在做一個個項目的交付。這樣做只是簡單的資源換輸出么?
- 中臺提供了一個個不太可視化的“能力”,還有一些工具、頁面。那中臺的“產(chǎn)品”到底是什么?
那么,用戶、項目、能力這些詞匯,我們又該以一個什么樣的框架來理解它們之間的關(guān)系呢?
而做中臺,又如何從這些東西里面找到所謂的主線呢?
接下來,我用中臺規(guī)劃一張圖來嘗試回答下這個問題。
二、解法:起點看用戶,過程看機制,結(jié)果看系統(tǒng)
上圖,我從用戶分類(起點)出發(fā),到需求和交付實現(xiàn)(過程),到產(chǎn)品沉淀(結(jié)果),做了環(huán)節(jié)的拆解。
接下來,我們就分別從3個環(huán)節(jié)詳細看下:
1. 起點,看用戶
——洞察用戶需求,才能知道我們努力方向,才有規(guī)劃和路線。
中臺的用戶其實是比較多元的,每一種用戶的訴求和建設(shè)路線可能不太相同,所以我們需要分類來看。
當前轉(zhuǎn)轉(zhuǎn)中臺的建設(shè)思路下,我把用戶大概分為4類:
1)業(yè)務(wù)方用戶:
用戶描述:即上游業(yè)務(wù),對中臺提需求,實現(xiàn)特定業(yè)務(wù)模式和能力的用戶,也是最大最高優(yōu)先級的用戶。
核心訴求:能力。中臺項目化結(jié)果輸出的能力,和業(yè)務(wù)做的功能,一起構(gòu)成了服務(wù)上游終端用戶的產(chǎn)品形態(tài)。
交付特點:項目化。因為業(yè)務(wù)上游有表現(xiàn)層,中臺更多是能力層,所以中臺交付是以項目為顆粒度一次次交付。
衡量指標:A-業(yè)務(wù)感受,要讓業(yè)務(wù)感受到中臺支持的專業(yè)度和協(xié)作順暢程度;B-項目質(zhì)量,要盡可能保障項目的功能可用性、易用性、不出bug等;C-項目交付效率,中臺比較復(fù)雜,涉及面也比較廣,業(yè)務(wù)希望交付是高效的、及時的。
建設(shè)導(dǎo)向:項目流程化、一攬子打包(系統(tǒng)化+解決方案專家)。項目化交付要想保證質(zhì)量和效率,流程化是非常重要的一個環(huán)節(jié)(下邊會講到);產(chǎn)品需求環(huán)節(jié),更是中臺架構(gòu)最困難的點,因為要業(yè)務(wù)對中臺產(chǎn)品域一對多,所以一攬子打包解決業(yè)務(wù)問題,不讓業(yè)務(wù)多點溝通,就是中臺的建設(shè)導(dǎo)向。
需求來源:需求自然來自于上游業(yè)務(wù)方。為了解決業(yè)務(wù)方眾多、后置等問題,目前中臺實現(xiàn)的是業(yè)務(wù)BP機制,主動跟進業(yè)務(wù)動態(tài)和需求的邏輯在跑,效果非常好。
2)公司內(nèi)產(chǎn)品/研發(fā)/運營用戶:
用戶描述:即公司內(nèi)部同學,在前臺產(chǎn)品運行之前和過程中,這些用戶需要通過后臺產(chǎn)品做配置和管理操作。
核心訴求:提效。本質(zhì)上產(chǎn)品形態(tài)為管理后臺類型,核心就是操作效率。
交付特點:工具化。產(chǎn)品本身不涉及邏輯或邏輯已經(jīng)確定,更多就是操作工具屬性。
衡量指標:高效、易用。工具核心就是讓操作用戶能夠非常有預(yù)期地便捷地完成對應(yīng)操作,所以高效、易用性是工具化的核心指標。
建設(shè)導(dǎo)向:去人工、場景化。管理相關(guān)工具如果不完善,那對應(yīng)的補位就是產(chǎn)品運營或研發(fā)的手動操作,而這個就會存在很多的遺漏、準確性、操作重復(fù)等問題,所以去人工系統(tǒng)化是要持續(xù)堅持的;而場景化,表達意思是說,我們在考慮工具設(shè)計時候,不要僅僅考慮功能已經(jīng)實現(xiàn)界面操作,而應(yīng)該考慮用戶實現(xiàn)何種目的,然后將相關(guān)操作集成到一個場景(優(yōu)先考慮線性流程引導(dǎo)、checklist檢查引導(dǎo))。
需求來源:內(nèi)部建設(shè),更多時候,會隨著能力交付,作為配套內(nèi)部產(chǎn)出。規(guī)劃上,整體就是各類操作后臺的終端,如XX運營后臺,XX商戶后臺,XX管理平臺等等。
3)外部用戶(C、B終端用戶):
用戶描述:即外部用戶,跟上游業(yè)務(wù)面對的用戶是一個層級,分為C、B終端用戶。因為中臺很多場景下,也會封裝提供終端產(chǎn)品服務(wù)于用戶(通用性較強、與業(yè)務(wù)指標弱關(guān)聯(lián)的產(chǎn)品功能)。例如交易支付領(lǐng)域的交易鏈路(購物車、下單、收銀臺、訂單管理、錢包優(yōu)惠券等)、商家后臺(入駐、營銷、對賬、IM等)等。
核心訴求:價值&體驗。因為要面向終端用戶,一定是滿足了用戶某種價值的訴求。這里面用戶對產(chǎn)品的使用可能代表著他權(quán)益的確認,例如交易、資金、貨物的交割等。體驗對終端產(chǎn)品來講,也一定是要考慮的因素,一方面是因為代表平臺產(chǎn)品的“面子”,另一方面體驗不好,可能會影響到功能使用,也就可能影響到價值。
交付特點:產(chǎn)品化。不同于項目用戶對于能力的訴求,也不同于內(nèi)部用戶對于工具的訴求,終端用戶感知一定是產(chǎn)品化的,產(chǎn)品化代表著更高的交付標準。
衡量指標:穩(wěn)定、易用。中臺提供的終端產(chǎn)品,一般都是交易鏈路節(jié)點相關(guān)的功能。這些功能的穩(wěn)定性應(yīng)該要求是第一優(yōu)先級的;而易用性呢,有則可能不一定加分,但沒有則一定減分。
建設(shè)導(dǎo)向:體驗也是功能的一部分。對于中臺,無論項目、工具還是端產(chǎn)品,穩(wěn)定性都是打底的要求,而體驗恰恰更多是中臺人“不擅長”的。而經(jīng)過越來越多的case發(fā)現(xiàn),有時候體驗不好,會影響到正常的功能使用,輕則用戶操作不便捷,重則引起很多不必要的客訴。
需求來源:終端用戶調(diào)研和反饋。這些信息,被動通道我們會關(guān)注客服online信息,主動通道會主動調(diào)研和做用戶體驗。
4)團隊內(nèi)部產(chǎn)研用戶:
用戶描述:即中臺自身的成員,包含產(chǎn)研同學。沒錯,我們應(yīng)該把自己也當作用戶來考慮,考慮下我們的痛點和訴求。
核心訴求:性能。這個性能其實是廣義的,不僅是響應(yīng)時長、QPS、可用性等技術(shù)指標,還包含中臺體系在業(yè)務(wù)對接過程中的靈活性、擴展性,以及中臺在業(yè)務(wù)維度的風險預(yù)警能力。
交付特點:專業(yè)化。中臺體系內(nèi)的交付,不是面向業(yè)務(wù)方、內(nèi)部產(chǎn)品運營、終端用戶,而是面向我們自己的未來發(fā)展。內(nèi)部做得好與不好,其實短期內(nèi)外部可能感知不到。但是我們一定要以最專業(yè)的標準要求自己,就像建設(shè)一條99%人看不到的下水道一樣。不為給別人交付,只為我們的專業(yè)信仰。
衡量指標:穩(wěn)定安全、擴展性。穩(wěn)定安全,是一切中后臺的基本要求;擴展性,對中臺也應(yīng)該是基本要求,如果做不到,那中臺就會成為中樞的瓶頸,最終失去立身之本。
建設(shè)導(dǎo)向:風險意識、架構(gòu)。每次跟老板匯報時候,老板總會提到一句話,說沒問題找到中臺時候,其實就代表你們做的很好,找你們時候準是出現(xiàn)什么大問題了。這句話就能看出,中臺必須在天晴的時候修房頂,把風險意識提前落實準備。架構(gòu)其實對應(yīng)的是復(fù)雜解耦和靈活擴展,中臺時刻面對多樣本,抽象后再簡化應(yīng)用接入。
需求來源:中臺內(nèi)部調(diào)研分析和規(guī)劃。自己的痛苦只有自己知道,上游用戶關(guān)注不到我們。所以,周期性挖掘團隊內(nèi)部每個人的反饋、復(fù)盤每一個問題,就是我們規(guī)劃的原素材。
PS:每家中臺建設(shè)路線可能不太相同,不是標準,參考邏輯即可。
2. 過程,看機制
——用機制牽引“人”沉淀“系統(tǒng)”,再應(yīng)用“系統(tǒng)”。
以上,4類用戶,指標、建設(shè)方向,以及給他們提供的產(chǎn)品特性,我們都已經(jīng)比較清晰了。
那從用戶需求到產(chǎn)品,有起點,有結(jié)果,過程到底該怎么做呢?這個也是我們本文核心要探討的問題。
交付,主要分為2個環(huán)節(jié):需求交付環(huán)節(jié)與項目實現(xiàn)環(huán)節(jié)。
對應(yīng)中臺來講,項目實現(xiàn)反而不是問題,但需求交付才是最棘手的。為什么?
在這里,我引用玄難在談阿里業(yè)務(wù)中臺建設(shè)歷史上的一段話,讓大家感受下:
我們?nèi)粘T谥信_建設(shè)中,也確認能非常感同身受。
接下來,我們就分別聊聊項目和需求(下邊篇幅重點聊這個環(huán)節(jié))。
1)項目維度的交付:
基于項目角度,常規(guī)的開發(fā)實現(xiàn)環(huán)節(jié)沒什么可聊的。
重點,我們關(guān)注兩端:需求處理和收益復(fù)盤,建立對應(yīng)機制。
需求立項分級機制,謹慎確定優(yōu)先級,確保資源花在刀刃上。
度量收益復(fù)盤機制,針對過程中各環(huán)節(jié)協(xié)作問題,不斷總結(jié)沉淀完善流程,并且check當初立項的收益是否達到。
PS:因為本文重點側(cè)重于產(chǎn)品層面問題,項目角度暫不詳述。
2)需求維度的交付:
接著上邊聊阿里玄難提的那段話。
中臺需求確定比較復(fù)雜,這個復(fù)雜分為橫向和縱向。
先看橫向,一個需求的實現(xiàn),大概率會跨域進行拼裝。
就拿我們業(yè)務(wù)中臺來說,幾乎所有的中大需求,都會包含以下產(chǎn)品域的review。
① 準備模塊:用戶、商戶、商品、促銷、服務(wù)
② 信息流模塊:訂單、逆向售后、仲裁
③ 資金流模塊:支付、清結(jié)算、對賬、財稅合規(guī)
④ 實物流模塊:履約、倉配、質(zhì)檢、退換修
⑤ 其他模塊:風控、客服、數(shù)據(jù)統(tǒng)計
這么多產(chǎn)品域拼裝起來,相關(guān)有關(guān)聯(lián),相關(guān)有影響。這個確實是一個復(fù)雜的事情。
再看縱向,每個產(chǎn)品域幾乎都需要極強的專業(yè)積累,有的還需要行業(yè)積累(例如財務(wù)、物流、支付)。
所以,縱向?qū)ν馓峁┮粋€能力,是需要非常多復(fù)雜問題的思考的,只不過外部感受不到。例如拿支付為例,收單、結(jié)算,這些從交易層感知,到支付層邏輯,再到賬戶層記賬,最后還要考慮資金,牽一發(fā)而動全身。
那既然,橫向和縱向都很復(fù)雜,那如何破解這個難題呢?
我的答案是:建立系統(tǒng),應(yīng)用系統(tǒng)。注意,這里的系統(tǒng),不僅僅是產(chǎn)品系統(tǒng),更多是系統(tǒng)化的意思。
那可能有人會問?這么復(fù)雜的東西,要變?yōu)橄到y(tǒng)要到猴年馬月。
沒錯,建立和應(yīng)用系統(tǒng),永遠在路上,就是我們本章節(jié)的主題:“過程,看機制”。
機制是什么?
機制就是牽引“人”將過去的問題、經(jīng)驗總結(jié)變?yōu)椤跋到y(tǒng)”,而再牽引“人”去應(yīng)用這些“系統(tǒng)”。不斷打磨不斷沉淀,逐漸將每個人的經(jīng)驗變?yōu)橄到y(tǒng)(流程、規(guī)范、標準、工具、結(jié)構(gòu)化歸檔),而逐漸不依賴個人。
接下來,就分別圍繞上邊講到的“橫向”和“縱向”機制做些講述。
A. 橫向機制:中臺平臺化建設(shè)
大家都知道,中臺會面向很多的業(yè)務(wù)模式。那在中臺能力范疇,也會逐漸積累很多穩(wěn)定模式的能力,也會去設(shè)計新的模式的能力。
我們先把橫向需求分為2個大類,這兩種應(yīng)對起來方法是不同的。
便于后續(xù)理解,先對上圖中的幾個名詞做下解釋(這里只介紹作用,輔助大家理解本文,以后有單獨文章來具體講解系統(tǒng)設(shè)計和實踐):
① [系統(tǒng)]規(guī)則中心:每一個模式在中臺全域(包含準備、信息流、資金流、實物流、其他)實現(xiàn)的所有邏輯和參數(shù)聲明;你可以理解為產(chǎn)品需求規(guī)則文檔,但是是經(jīng)過高度結(jié)構(gòu)化之后的(結(jié)構(gòu)化就是產(chǎn)品域-角色-交易節(jié)點-產(chǎn)品功能點,已經(jīng)被抽象出來了,后邊都是邏輯和參數(shù))。規(guī)則中心對外是讀操作。
② [系統(tǒng)]配置中心:以全域業(yè)務(wù)線為id主鍵,可以指引業(yè)務(wù)自助拆解需求并做預(yù)配置,指引中臺審核配置的一站式平臺,可通俗理解為一個需求通過配置中心,可以在很多時間內(nèi),基本無開發(fā)無測試快速完成上線。注意,配置中心中的配置項,理論上屬于規(guī)則中心參數(shù)的子集,配置中心收納配置項一定是從高頻到低頻的。配置中心對外是寫操作。
③ [系統(tǒng)]開放平臺:以域能力為顆粒度立體式介紹中臺能力,從應(yīng)用場景、能力描述、接入流程、技術(shù)對接、產(chǎn)品運營等維度信息,目的是希望上游業(yè)務(wù)用戶能實現(xiàn)自助理解和接入,也能實現(xiàn)中臺跨域產(chǎn)研之間進行橫向熟悉能力。開放平臺對外是讀操作。
④ [人]解決方案專家:對上能夠理解戰(zhàn)略、理解業(yè)務(wù),對下能夠熟悉中臺全域能力并具備拼裝能力的專家人才。
⑤ [人]垂直溝通:解決方案專家熟悉各域能力的程度,更多是基于拼裝串聯(lián)時候橫向與垂直域的接觸點。那對新模式來講,更多時候需要垂直域內(nèi)做一些較為專業(yè)的評估,這時候就需要垂直溝通。
OK,了解完這些名詞解釋之后,讓我們回到文章主線。
按照我描述的“人牽引系統(tǒng)”的做法,機制運行如下:
① 對“已有模式”的需求實現(xiàn),可以依賴系統(tǒng)【規(guī)則中心】、【配置中心】;
② 對“新模式”的需求實現(xiàn),可以依賴系統(tǒng)【開放平臺】,再加上人的能力【解決方案專家】和【垂直溝通】。
③ 然后等“新模式”成熟之后,把對應(yīng)的【規(guī)則中心】【配置中心】能力更新到系統(tǒng)中,逐漸循環(huán)起來。
以上機制,我們經(jīng)過一段時間的運作,已經(jīng)初見成效,目前也在持續(xù)建設(shè)中。
B. 縱向機制:垂直能力域
在垂直能力域運行機制,其根本原理跟上述橫向中臺平臺化建設(shè)是一樣的。
核心就是希望沉淀系統(tǒng)的思維,將存量能力的應(yīng)用成本變得越來越低。
對于增量能力,只能依賴專家的垂直域知識和經(jīng)驗,然后等能力穩(wěn)定再代入到存量能力系統(tǒng)去循環(huán)。
C. 橫向與縱向協(xié)同:雙向牽引
橫向來講,是對垂直能力的引用和規(guī)則配置。
縱向來看,垂直能力有很多應(yīng)用方在引用,這時候不僅僅包含橫向項目,也可能都獨立應(yīng)用或其他非中臺業(yè)務(wù)方直接引用。
橫向和縱向,如何協(xié)同?
說下當前轉(zhuǎn)轉(zhuǎn)中臺當前階段,我對這兩者關(guān)系的看法:
① 在中臺橫向項目即模式能力范圍內(nèi),更多是讓橫向牽引縱向閉環(huán)完交付。例如【配置中心】【規(guī)則中心】,這些都是跨全域的系統(tǒng)。
② 站在垂直域視角,需要把垂直能力與模式/項目解耦。例如【開放平臺】,站在能力的角度來交付,支持應(yīng)用場景是全樣本的,不僅僅只考慮中臺范圍內(nèi)。
3. 結(jié)果,看系統(tǒng)
——逐漸用系統(tǒng)把人的不確定因素消除掉,變?yōu)橘Y產(chǎn)。
1)系統(tǒng)的分類:
按照最上邊,我們中臺面向的4類用戶,其實我們的結(jié)果“系統(tǒng)”也會有不同的形態(tài)。
上邊在論證“起點”、“過程”的篇幅中,已經(jīng)基本描述到了,這里稍微做下總結(jié):
① 業(yè)務(wù)方用戶:【配置中心】、【規(guī)則中心】、【開放平臺】、【綜合查詢】、【其他路由】。前3個上邊名詞解釋時候已經(jīng)說明了,簡單說下后兩者:
【綜合查詢】系統(tǒng)是發(fā)揮中臺基礎(chǔ)特性“數(shù)據(jù)連通性”來做的應(yīng)用產(chǎn)品,可以讓各類用戶在這個系統(tǒng)中做到全信息查詢,不用再離散各個地方拼信息。例如查看某個訂單歷史、當前、未來的全部信息(包含準備、信息流、資金流、實物流等)。
【其他路由】更多是除了項目之外,做的信息收斂措施。例如中臺有非常多的后臺系統(tǒng),就可以做一個導(dǎo)航站,便于各類用戶使用;例如SOP和培訓(xùn),也是希望將業(yè)務(wù)對中臺,可以變?yōu)?對1的交互點。
② 公司內(nèi)產(chǎn)品/研發(fā)/運營用戶:【垂直-配置生效類】、【垂直-運營工具類】。前者主要是內(nèi)部產(chǎn)研用戶使用,為產(chǎn)品運行提供基礎(chǔ)策略/數(shù)據(jù)配置等管理操作的,例如交易鏈路節(jié)點、收單清結(jié)算規(guī)則配置等;而后者主要是內(nèi)部運營使用,為產(chǎn)品運行提供運營策略/數(shù)據(jù)配置等管理操作的,例如促銷活動設(shè)置、專題設(shè)置、商戶管理等。
③ 外部用戶(C、B終端用戶):C端產(chǎn)品主要圍繞交易上下游的終端產(chǎn)品,B端產(chǎn)品主要圍繞商戶經(jīng)營提供終端產(chǎn)品。
④ 團隊內(nèi)部產(chǎn)研用戶:為輸出上游產(chǎn)品能力提供的一些不可見的底層能力。例如各類交易鏈路是上游能力,但是具備很容易拼裝搭建鏈路的能力就是底層能力;再比如專題自助拼裝系統(tǒng)是上游能力,但是如何實現(xiàn)模塊化拼裝且支持中臺、業(yè)務(wù)多方共建模塊的能力就是底層能力。
至此,我們已經(jīng)完成了“起點-用戶”、“過程-機制”、“結(jié)果-系統(tǒng)”的全部講解。
2)中臺的指標:
最后,讓我們回到文章開頭提的問題:“業(yè)務(wù)有經(jīng)營指標,中臺有沒有?”
我想答案是明確的,一定是有的。只不過對于中臺,我們需要按照用戶分類、系統(tǒng)屬性來拆分設(shè)置。
指標可能有很多,但是我們一定階段性要聚焦,找當下最核心的矛盾,建立指標去攻破。
當前轉(zhuǎn)轉(zhuǎn)中臺建設(shè)階段,我們將【中臺平臺化】-【存量能力】-【配置中心】的完成質(zhì)量和時間,作為了我們的北極星指標,因為我覺得它可以牽動全局去改變。
其他指標,根據(jù)需求,也會有單獨的指標在關(guān)注。例如online的數(shù)量和處理時效指標,是對項目質(zhì)量和用戶客訴滿意度的衡量。
作者:減形簡遠,微信公眾號:產(chǎn)品雜談(life_pm)
本文由@減形簡遠 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
體系化思考和構(gòu)建,學習了,謝謝~
連著看了博主的四篇內(nèi)容,受益匪淺,感謝~
建議名稱加上電商中臺,制造業(yè),b端管理系統(tǒng)的中臺,不是這樣的。不要以偏概全,中臺的含義很廣。
好的 感謝建議。
作者從用戶、機制、系統(tǒng)這三大方面對中臺規(guī)劃解析得很透徹,合理。
中臺是一個泛概念功能,啥都往里裝,,結(jié)果,,眼下,很悲涼,,現(xiàn)在說的中臺需求和實現(xiàn),早已有之,只是不斷變換著實現(xiàn)路徑和新技術(shù)。工具,,,,,,
贊同。太陽底下無新鮮事,世界上沒有太多新的輪子。erp或現(xiàn)在很多saas的產(chǎn)品都是先驅(qū),本質(zhì)上就是如何提升復(fù)用性達到整體降本的目的。自己對中臺概念沒有執(zhí)念,就是奔著以上目的看如何為企業(yè)找到最優(yōu)解。
是的,,完成一個商業(yè)項目
有道理
有道理
想法和感悟很不錯,給作者點個贊
感謝認可。