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