在寫完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協議。