編輯導讀：自從阿里提出中臺概念後，各行各業不斷推出了中臺的應用與落實。關於中臺的概念和應用已經有很多文章都講過了，但是具體的企業建設的文章還是比較少。本文作者就以自身工作實踐為基礎，分享了自己關於企業中臺建設的一些思考和實踐，與大家分享。
最近開始做中臺產品經理了，中臺這個詞是這兩年很火的詞，市面上也聽到很多企業在說中臺，有虛的有實的，有人對此嗤之以鼻，覺得只是一個噱頭，不過在我做我們企業中臺一些從0到1的建設時候，的確感受到了實實在在的一些變化。
比如業務接入速度，可以幫助某些從0-1的業務，在人力投入比較少的情況下，很快的上線。本來想寫一個系列文章，從中臺是什麼開始寫，不過正好最近在做下半年規劃，在某些建設方法論上已經有所沉澱，所以先把這個比較深的感悟，先寫出來。
總體概述這個方法論是看了阿里中臺建設方法論，結合自身公司實際落地，進行了一些修改，還是比較適用的，藉此一些實際操作，對於如何有公司特色的中臺，做一些說明：
中臺建設方法論流程圖：
以下從能力地圖、需求結構化、業務清單、業務度量、能力釋出幾個方面進行闡述。
一、能力地圖1. SOP流程什麼是SOP流程：SOP流程是一個標準作業程式,以統一的格式描述一個事件的標準作業程式和要求,以指導和規範日常工作（百度）。
簡單的說，就是把一件事情透過流程圖的方式表示出來，如果在企業中，很多不同的部門都在做同一件事情，可能會有不同的流程，但是不同的流程中都會涉及到一些相同的部分，那這個部分就是可以被中臺化沉澱的部分。
舉例，比如對於一個電商下單流程一般是這樣的（做了刪減）：
透過上面的流程圖，就可以抽取出，如果要做一個支撐電商的中臺，可能需要的中心層會包含商品中心、營銷中心、交易中心等等。業務也需要有對應的前後端做自己的業務邏輯的判斷。
那可以看出，為什麼要梳理企業的SOP流程：
- 明確邊界：透過SOP流程的梳理，可以更好地知道業務的邊界在哪裡，同時對於中臺來說流程梳理下來，將共用的能力就可以進行抽象，根據業務優先順序，進行中臺化的沉澱。
- 幫助企業提效及規範：中臺產品與B端產品類似的點在於很多時候是為企業服務的，所以標準SOP流程，可以規範企業的一些做法，有時候做系統並不是單純的做系統，更多要站在組織的角度考慮
對於中臺來說，我們已經有什麼能力，業務方可以如何去接入。
我對於我們公司中臺分為了管理後臺與服務中心能力，這個和每個公司自身情況有關，比如我們公司小一些，需要又做能力，又做後臺，所以分為兩層：
管理後臺是運營使用的，服務中心是底層一些能力的抽象。針對電商平臺，業務大部分中臺提供的能力地圖可能是這樣的：
透過我們的能力地圖，可以更好的與外界進行溝通，作為中颱的產品或者業務的負責人，需要更好的做到一個橋樑的作用，將我們的中臺能力在內部推廣出去，賦能業務。
二、 需求結構化業務商業化需求提過來之後，很多業務方是不關心對接邏輯的，所以中臺建設初期，需要進行需求結構化，就像滾輪子一樣，邊做業務邊做中臺。看哪些是可以進行沉澱的，是中心化能力，哪些用配置就可以了。將沉澱的能力，全部變成可配置的方式，讓下次接入更快。
剛剛可以看到中臺需要做的內容很多，可能支撐企業電商業務，就需要商品中心、交易中心、營銷中心等等，那如果停下了直接做中臺，沒有對應的業務，可能很多企業如果看不到成效會放棄繼續做下去。比如我們在建設我們企業中臺時候，則是根據業務的迭代需求，比如需要先售賣再營銷，那就先把商品中心、交易中心做了。做的時候發現我們會員業務比較多，那就再去做權益中心。
所以中臺建設的初期，不能用業務接入速度去衡量，但是建設相對穩健一段時間後，越來越多的業務透過配置即可上線，就可以看出成效。
三、業務全景圖業務列表和業務清單，應該是對於一個公司業務全景圖的梳理。我們有哪些業務，這些業務有什麼能力，接下來他們要發展成什麼樣子。
目的主要是需要清楚知道自己能力輸出後，對於業務的價值在於什麼。而不是悶頭進行能力建設。
這裡需要有一個符合公司特色的業務全景圖。
四、業務度量業務的優先順序是什麼，我認為需要評估兩點：
- 每個業務的目標和KPI是什麼：目標是否清晰可量化，在公司總體目標裡面，他佔據了什麼比重。在接下來進行中臺化支援的時候，可以用此作為優先順序。
- 業務的靠譜程度：也許每個業務提了很多需求，但是需求不是提完就結束的，產品需要做閉環就需要持續關注，比如支援了某個業務，他資料效果如何，好和不好的原因，這些也是評估業務的方式
中臺作為業務側強大的炮火團，在技術上要求應該需要滿足以下幾點：
- 豐富度：像產品一樣，是可以逐步迭代的。不是一下子就是一個很豐富但沒人用的中臺，而是像滾輪子的方式，邊做業務邊做中臺，只是需要有預判性的提前做一些內容
- 質量：即使速度放慢，也需要對於質量有所保證，這個可能和一些流程上的要求密不可分。測試流程、釋出流程、迭代流程
- 可讀性：除了介面的可讀性，還需要對於接入文件有相關可讀性，除了開發速度，怎麼減少溝通成本和技術聯調速度
- 架構穩定性與規劃：穩定性想指的在於架構上面的穩定性，可能中臺建設後，由於接入業務方變多了，你的一點點小小改動，都會造成業務方介面的更換，所以架構上也需要保持相對的穩定性。
從技術的角度上，考慮到面的角度更多，怎麼從架構的角度讓程式碼更加優雅。從產品的角度上，不管是中臺產品還是前臺產品，也需要考慮到業務全景圖，產品規劃不是一個虛的東西，而是自己要知道至少半年，產品形態是什麼。
對於產品來說，產品穩定性是一個很好地驗證產品力的方式，像微信，這麼多年那4個tab還是沒怎麼變過，可以支援到各種功能的疊加和承載。所以很多東西不是一個點，修改一下UI就解決的事情。
2. 作為一個橋樑對於能力側，如中臺、企業IT等團隊，對於產品或者業務負責人來說，需要有一個橋樑的作用，定期同步中臺能力，與業務側定期溝通他們後續一個規劃，不要矇頭做能力。
對於業務來說產品是需要運營的，對於中臺來說，其實也是需要運營的，需要和公司內部推廣出去，更好的賦能業務。
3. 不要當工具人如果不主動思考就會成為一個工具人，比如程式碼的搬運工、產品的抄襲者。除了做支援，更多的還需要往前再走一步，每一個產品/技術主要思考做什麼事情可以對業務產生價值。
有了業務感覺的產品/開發/測試，可以更好的對業務說不。拒絕不合理的需求和臨時方案，做更多有價值的事情。這一些其實是在於賦能的同時可以更往前走一步，反推動業務。
作者：周玥，微信公眾號：粥dayday的腦細胞
本文由 @周玥 原創釋出於人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。