編輯導讀：自從阿里提出中臺概念后，各行各業不斷推出了中臺的應用與落實。關于中臺的概念和應用已經有很多文章都講過了，但是具體的企業建設的文章還是比較少。本文作者就以自身工作實踐為基礎，分享了自己關于企業中臺建設的一些思考和實踐，與大家分享。

最近開始做中臺產品經理了，中臺這個詞是這兩年很火的詞，市面上也聽到很多企業在說中臺，有虛的有實的，有人對此嗤之以鼻，覺得只是一個噱頭，不過在我做我們企業中臺一些從0到1的建設時候，的確感受到了實實在在的一些變化。

比如業務接入速度，可以幫助某些從0-1的業務，在人力投入比較少的情況下，很快的上線。本來想寫一個系列文章，從中臺是什么開始寫，不過正好最近在做下半年規劃，在某些建設方法論上已經有所沉淀，所以先把這個比較深的感悟，先寫出來。

總體概述

這個方法論是看了阿里中臺建設方法論，結合自身公司實際落地，進行了一些修改，還是比較適用的，借此一些實際操作，對于如何有公司特色的中臺，做一些說明：

中臺建設方法論流程圖：

以下從能力地圖、需求結構化、業務清單、業務度量、能力發布幾個方面進行闡述。

一、能力地圖

1. SOP流程

什么是SOP流程：SOP流程是一個標準作業程序,以統一的格式描述一個事件的標準作業程序和要求,以指導和規范日常工作（百度）。

簡單的說，就是把一件事情通過流程圖的方式表示出來，如果在企業中，很多不同的部門都在做同一件事情，可能會有不同的流程，但是不同的流程中都會涉及到一些相同的部分，那這個部分就是可以被中臺化沉淀的部分。

舉例，比如對于一個電商下單流程一般是這樣的（做了刪減）：

通過上面的流程圖，就可以抽取出，如果要做一個支撐電商的中臺，可能需要的中心層會包含商品中心、營銷中心、交易中心等等。業務也需要有對應的前后端做自己的業務邏輯的判斷。

那可以看出，為什么要梳理企業的SOP流程：

• 明確邊界：通過SOP流程的梳理，可以更好地知道業務的邊界在哪里，同時對于中臺來說流程梳理下來，將共用的能力就可以進行抽象，根據業務優先級，進行中臺化的沉淀。
• 幫助企業提效及規范：中臺產品與B端產品類似的點在于很多時候是為企業服務的，所以標準SOP流程，可以規范企業的一些做法，有時候做系統并不是單純的做系統，更多要站在組織的角度考慮

2. 梳理自身中臺能力列表/能力地圖

對于中臺來說，我們已經有什么能力，業務方可以如何去接入。

我對于我們公司中臺分為了管理后臺與服務中心能力，這個和每個公司自身情況有關，比如我們公司小一些，需要又做能力，又做后臺，所以分為兩層：

管理后臺是運營使用的，服務中心是底層一些能力的抽象。針對電商平臺，業務大部分中臺提供的能力地圖可能是這樣的：

通過我們的能力地圖，可以更好的與外界進行溝通，作為中臺的產品或者業務的負責人，需要更好的做到一個橋梁的作用，將我們的中臺能力在內部推廣出去，賦能業務。

二、 需求結構化

業務商業化需求提過來之后，很多業務方是不關心對接邏輯的，所以中臺建設初期，需要進行需求結構化，就像滾輪子一樣，邊做業務邊做中臺?？茨男┦强梢赃M行沉淀的，是中心化能力，哪些用配置就可以了。將沉淀的能力，全部變成可配置的方式，讓下次接入更快。

剛剛可以看到中臺需要做的內容很多，可能支撐企業電商業務，就需要商品中心、交易中心、營銷中心等等，那如果停下了直接做中臺，沒有對應的業務，可能很多企業如果看不到成效會放棄繼續做下去。比如我們在建設我們企業中臺時候，則是根據業務的迭代需求，比如需要先售賣再營銷，那就先把商品中心、交易中心做了。做的時候發現我們會員業務比較多，那就再去做權益中心。

所以中臺建設的初期，不能用業務接入速度去衡量，但是建設相對穩健一段時間后，越來越多的業務通過配置即可上線，就可以看出成效。

三、業務全景圖

業務列表和業務清單，應該是對于一個公司業務全景圖的梳理。我們有哪些業務，這些業務有什么能力，接下來他們要發展成什么樣子。

目的主要是需要清楚知道自己能力輸出后，對于業務的價值在于什么。而不是悶頭進行能力建設。

這里需要有一個符合公司特色的業務全景圖。

四、業務度量

業務的優先級是什么，我認為需要評估兩點：

• 每個業務的目標和KPI是什么：目標是否清晰可量化，在公司總體目標里面，他占據了什么比重。在接下來進行中臺化支持的時候，可以用此作為優先級。
• 業務的靠譜程度：也許每個業務提了很多需求，但是需求不是提完就結束的，產品需要做閉環就需要持續關注，比如支持了某個業務，他數據效果如何，好和不好的原因，這些也是評估業務的方式

五、能力發布

中臺作為業務側強大的炮火團，在技術上要求應該需要滿足以下幾點：

• 豐富度：像產品一樣，是可以逐步迭代的。不是一下子就是一個很豐富但沒人用的中臺，而是像滾輪子的方式，邊做業務邊做中臺，只是需要有預判性的提前做一些內容
• 質量：即使速度放慢，也需要對于質量有所保證，這個可能和一些流程上的要求密不可分。測試流程、發布流程、迭代流程
• 可讀性：除了接口的可讀性，還需要對于接入文檔有相關可讀性，除了開發速度，怎么減少溝通成本和技術聯調速度
• 架構穩定性與規劃：穩定性想指的在于架構上面的穩定性，可能中臺建設后，由于接入業務方變多了，你的一點點小小改動，都會造成業務方接口的更換，所以架構上也需要保持相對的穩定性。

總結：做中臺需要怎樣的能力？

1. 業務架構/技術架構考慮

從技術的角度上，考慮到面的角度更多，怎么從架構的角度讓代碼更加優雅。從產品的角度上，不管是中臺產品還是前臺產品，也需要考慮到業務全景圖，產品規劃不是一個虛的東西，而是自己要知道至少半年，產品形態是什么。

對于產品來說，產品穩定性是一個很好地驗證產品力的方式，像微信，這么多年那4個tab還是沒怎么變過，可以支持到各種功能的疊加和承載。所以很多東西不是一個點，修改一下UI就解決的事情。

2. 作為一個橋梁

對于能力側，如中臺、企業IT等團隊，對于產品或者業務負責人來說，需要有一個橋梁的作用，定期同步中臺能力，與業務側定期溝通他們后續一個規劃，不要蒙頭做能力。

對于業務來說產品是需要運營的，對于中臺來說，其實也是需要運營的，需要和公司內部推廣出去，更好的賦能業務。

3. 不要當工具人

如果不主動思考就會成為一個工具人，比如代碼的搬運工、產品的抄襲者。除了做支持，更多的還需要往前再走一步，每一個產品/技術主要思考做什么事情可以對業務產生價值。

有了業務感覺的產品/開發/測試，可以更好的對業務說不。拒絕不合理的需求和臨時方案，做更多有價值的事情。這一些其實是在于賦能的同時可以更往前走一步，反推動業務。

作者：周玥，微信公眾號：粥dayday的腦細胞

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

題圖來自Unsplash，基于CC0協議。