在寫完30萬字的中臺100講後，再來談談中臺

各位關於中臺讀者，大家好！好久沒和大家再聊聊中臺相關的內容了。

最近在我寫完中臺100講（《中臺產品經理寶典》一書+中臺實戰30講）的內容後，我終於有空在我的公眾號上去回答和接受邀請去往很多企業參與中臺方案的評審。

在這將近一個多月的沉澱與走訪中，讓我對中臺這個概念在一線戰場使用的人群中有了新的瞭解，也正是如此我決定再寫一篇中臺本質探索的文章，來對近期我遇到的中臺高頻疑問進行一個梳理。

一、中臺的爭議

最近關於中臺爭議最大的一個訊息，莫過於張勇近期在阿里內網釋出的一段話，大概意思如下：“張勇對目前阿里的中臺建設並不滿意，他直言道現在阿里的業務發展太慢，要把中臺變薄，變得敏捷和快速。”

而這段話在流出後，被自媒體一番加工後變為了阿里開始要拆中臺，於是乎很多人閱讀完這些文章後，也開始說中臺已經成為被阿里拋棄的產物。

那事實真的是這樣嗎？這裡我想說其實這些自媒體其實已經從中臺的概念源頭出現了理解偏差。

也就是說如果有人認為中颱是一個具體的產物或一個系統，那麼此人對中臺概念已經產生了相當大的誤區。

如果仔細拆解這裡的誤區，可以發現他們的思考鏈條是這樣的：

中臺的錯誤認知：中臺 = 一套神奇系統 = 降本提效的軟體工具。

基於這個錯誤的認知，加上市場一些SaaS企業的惡意炒作，在市場中很多IT企業主就產生了這樣的認知：

企業主的決策認知：我要降低成本 = 所以要上中臺系統 = 我不清楚中臺是什麼，我也沒有能力自研 = 我要去買一箇中臺系統。

大家試想下，無論是之前的某酒廠的中臺失敗案例，還是某電商的3千萬的中臺流產專案，這背後其實都是這樣的企業主在把中臺與一套神奇系統畫等號後，進行的一系列錯誤決策。

二、中臺究竟是什麼？

那麼中臺究竟是什麼呢？

這裡我想說：中臺概念其實只是一種設計思路，本質來說就是當企業發展到一定規模後，一次企業內部改建。

眾所周知在網際網路公司內部的產品其實都是為企業業務所服務的，在很多時候產品的建設都需要優先滿足於業務的需求。

因此在很多公司中，會出現為了追風口趕業務新產品會在現有產品基礎上進行臨時搭建，快速拼湊出一個臨時產品。

這種場景，舉個形象的例子就很像現實生活中的違章建築。

違建雖然在一定程度上臨時滿足了我們的需求，但是他給整座大樓帶來了安全隱患，會影響到樓層的穩定性，同時也將原有的樓層主體進行了破壞。

而且更重要的是這種臨時建築由於沒有進行全域性的設計，只是在現有的結構基礎上臨時拼湊出來的，就會導致其自身的使用效能與使用體驗遠低於正常水平。

所以很多時候，在新業務發展到一定時間後，我們都會選擇重構來為新業務重新設計產品。因此中臺這個概念，本質上就是一種企業內部全產品線的一次改建方案，具體來說分為兩點：

1. 對企業內部的這些違章建築進行一次改建，拆除原有的違章建築，並將這些違章建築的原有訴求進行合併；
2. 為了避免在企業後期再次出現違章建築，我們需要將時下已經跑通並且驗證了業務功能變成可複用的原子元件，讓其他業務方可以在出現訴求時，直接用現有的元件去拼裝出自己的解決方案。

第二點這裡我再舉個不怎麼正確但是很好理解的例子，就是當我們需要再開發一個新的商城時，在公司內部我們可以選擇把做的最完整那條業務線的PRD與程式碼拿過來，此時我們就有了個現成的商城。

當然為了讓一份PRD與程式碼可以全公司複用，我們在設計時就需要儘可能的抽象，比如在某業務線中設計的入庫模組，他們根據業務需要在入庫型別中定義了海淘商品入庫單、殘次品退貨入庫單兩種型別。

但是大家試想，如果在新的業務中，商城中不涉及海淘的業務，那麼在拿到這個業務線的程式碼時，就會覺得這裡的入庫單還需要二次開發。所以我們在將自己的程式碼交給別人複用時，我們應該先將自己業務的邏輯剝離掉。

比如這裡，我們就應該將海淘商品入庫單、殘次品退貨入庫單進行業務剝離，得出抽象後的入庫單與退貨入庫單兩種原子元件。

當然這裡的例子不是很正確，只是為了幫助大家理解。在實際的中臺抽象中我們需要大量的建模，原子元件定義等等，這裡我就不展開詳述了，感興趣的可以去看看我的《中臺產品經理寶典》一書。

三、中臺落地產物

涉及到中臺的另一個問題就是，中臺的落地產物到底是什麼？

當我以外部專家身份，參與了多家企業的中臺方案評審後，再來看這個問題，我的答案就是：中臺產物其實就是六個字，“下定義、給標準”。

1. 下定義

當有多個業務線都存在同一事物時，我們要透過中臺的改建將這些不同的事物進行統一化。例如在電商中，一提起指標，在不同業務線中就變得五花八門。

例如毛利、核心使用者群，每個業務線都有自己的定義，而我們要做的就是要給這些不同業務線都有而又定義不同的事物一個標準的定義。

這樣定義的好處是，以後在任何場景大家都能以“同一國語言”來進行溝通了。

當然這裡的定義我們不能一味地為了大而全就把所有的業務概念進行統一，就像上文提到的核心使用者群，在不同的業務線中確實是存在不同的定義：

• A業務線：對下單頻次高，客單價高的使用者稱之為核心使用者群；
• B業務線：對單位週期內訂單總金額為前20%的使用者稱之為核心使用者群。

此時這樣的定義可以看出存在明顯的業務訴求，因此我們應該保留而不需要中臺進行統一定義。

2. 給標準

除了要對企業內部同一事物進行下定義外，在很多時候我們還會遇到，很多業務線確實對同一事物有個性化的需求。

例如訂單中心，由於各個業務線的業務模式不同，我們最終落地的訂單就會有對應的業務場景所需的功能嵌入。

例如：

• 海淘訂單：有複雜的關稅相關邏輯；
• 大客戶訂單：有賬期邏輯，履約配送倉庫邏輯等。

此時進行中臺化，我們要做的內容就是對這些訂單定一個標準，告訴各個業務線你的訂單生成邏輯需要有什麼樣的標準、什麼樣的資料格式、業務線的個性化需求插入方式。這樣當我們去統計各個業務線的訂單時，我們就有了一套標準的訂單格式。

這樣在中臺看到的訂單，就不會存在有的訂單是10個欄位，有的是15個欄位；儲存的資訊範疇也不同，有的儲存商戶ID，有的儲存商戶CODE等等。

本質上中臺讓各個業務線的訂單建立流程、欄位數、儲存格式上都有了一套標準。

四、最後

最後，中臺並不是一個具象化的系統，而是企業內部進行資訊化自我升級的一次改建工程。

因此中臺要能夠順利的完成企業內部的建設與實施，所必經之路就是要對企業內部的業務與資訊化有充分的調研，在此基礎上以強定製化的方式給出適合本企業的中臺解決方案。

最後的最後，說一句會觸動現在市面上很多軟體服務公司利益的大實話：任何企業都絕不可能憑空給出一招鮮吃遍天的通用中臺解決方案或軟體。

#專欄作家#

三爺，微信公眾號：三爺茶館，人人都是產品經理專欄作家，2019年年度作者。《中臺產品經理寶典》作者，原萬達高階產品、MBA特約講師、獨立創業者，現叮咚買菜B端產品線負責人，擁有多款集團專案從零到一經驗並帶領實現商業化佈局。

本文原創釋出於人人都是產品經理。未經許可，禁止轉載

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