華為、阿里都在說的“中台”究竟是什麽？

如今，你會在各種大會的演講 PPT 上越來越多看見「中台」二字的身影。尤其是阿里、騰訊、美團等一眾互聯網巨頭，正不約而同地掀起「中台化」革新浪潮，上一個令人感到困惑的類似

術語還是 OKR

。如果說 OKR 更多是對於「人與業績」的調整，那麽中台則是基於「業務組織架構」，按本文作者的話來說，它相當於是連接「前台」和「後台」業務中間的變速齒輪。

來源 | 公號“健薦”

作者 | 王健

中台究竟是什麽？它對於企業的意義又是什麽？當我們談中台時，我們到底在談些什麽？

想要找到答案，僅僅沉寂在各自“中台”之中，如同管中窺豹，身入迷陣，是很難想清楚的。不如換個?度，從各類的“中台迷陣”中跳脫出來，嘗試以更高的視角，從企業均衡可持續發展的角度來思考中台的價值，試圖反推它存在的價值。

所以，為?搞明白中台存在的價值，我們需要回答以下兩個問題：

第一個問題：企業為?麽要平台化？

先給答案，其實很簡單：

因為在當今互聯網時代，?戶才是商業戰場的中心，為了快速響應用戶的需求，借助平台化的力量可以事半功倍。

不斷快速響應、探索、挖掘、引領?戶的需求，才是企業得以?存和持續發展的關鍵因素。

那些真正尊重用戶，甚?不惜調整?己顛覆?己來響應?戶的企業將在這場以?戶為中心的商業戰爭中得以?存和發展；?反之，那些在過去的成就上故步?封，存在僥幸??希望?戶會像之前一樣繼續追隨?己的企業則會被用戶淘汰。

很殘酷，但這就是這個時代最基本的企業?存法則。

?平台化之所以重要，就是因為它賦予或加強了企業在以用戶為中心的現代商業戰爭中最核心的能?：?戶響應?。這種能力可以幫助企業在商戰上先發製?，始終搶得先機。

在互聯網時代，商業的鬥爭就是對於用戶響應力的比拚。

我們來看?個?子:

1、阿里

說起中台，最先想到的應該就屬是阿里的“?中台，?前台”戰略。阿里?通過多年不懈的努?，在業務的不斷催化滋養下，將自己的技術和業務能?沉澱出一套綜合能?平台，具備?對於前台業務變化及創新的快速響應能?。

2、華為

華為在幾?前就提出了“?平台炮火支撐精兵作戰”的企業戰略，“讓聽得到炮聲的人能呼喚到炮火” 這句話形象的詮釋了大平台?撐下小前台的作戰策?。這種極度靈活又威?巨?的戰法，使之可以迅速響應瞬息萬變的戰場，一旦鎖定目標，通過大平台的炮火群，迅速精準對於戰場進?強大的火?支援。

可?，在互聯?熱火朝天，第四次工業革命的曙光即將到來的今日，企業能否真正做到“以用戶為中心”，並不斷提升自己的用戶響應?來追隨甚至引領用戶的腳步，持續規模化創新，終將決定企業能否在這樣充滿挑戰和機遇的市場上笑到最後，在商業上長久保持創新活力與競爭力。

而平台化恰好可以助力企業更快更好的做到這些，所以這回答了第一個問題，企業需要平台化。

第二個問題：企業為什麽要建中台？

好，想明白了第一個問題，為什麽需要平台化。但是平台化並不是一個新概念，很多企業在這個方向上已經做了多年的努力和積澱。那為什麽最近幾年“中台”這個相對較新的概念又會異軍突起？對於企業來講，傳統的“前台+後台”的平台化架構又為什麽不能滿足企業的要求呢?

好，這就引出了我們的第二個問題：企業為什麽要建中台？

先定義一下前台與後台

因為平台這個詞過於寬泛了，為了能讓大家理解我在說什麽，我先定義一下本篇文章上下文下我所說的前台和後台各指什麽：

前台：由各類前台系統組成的前端平台。每個前台系統就是一個用戶觸點，即企業的最終用戶直接使用或互動的系統，是企業與最終用戶的交點。例如用戶直接使用的網站，手機 app，微信公眾號等都屬於前台範疇。

後台：由後台系統組成的後端平台。每個後台系統一般管理了企業的一類核心資源（數據+計算），例如財務系統，產品系統，客戶管理系統，倉庫物流管理系統等，這類系統構成了企業的後台。基礎設施和計算平台作為企業的核心計算資源，也屬於後台的一部分。

後台並不為前台而生

定義了前台和後台，對於第二個問題（企業為什麽要建中台），同樣先給出我的答案：

因為企業後台往往並不能很好的支撐前台快速創新響應用戶的需求，後台更多解決的是企業管理效率問題，而中台要解決的才是前台的創新問題

大多數企業已有的後台，要麽前台根本就用不了，要麽不好用，要麽變更速度跟不上前台的節奏。

我們看到的很多企業的後台系統，在創建之初的目標，並不是主要服務於前台系統創新，而更多的是為?實現後端資源的電子化管理，解決企業管理的效率問題。這類系統要不就是當年花大價錢外購，需要每年支付大量的服務費，並且版本老舊，定製化困難；要不就是花大價錢自建，年久失修，一身的補丁，同樣變更困難，也是企業所謂的“遺留系統”的重災區。

總結下來就兩個字“慢”和“貴”，對業務的響應慢，動不動改個小功能就還要花一大筆錢。

有人會說了，你不能拿遺留系統說事兒啊，我們可以新建後台系統啊，整個2.0問題不就解決了。

但就算是新建的後台系統，因為其管理的是企業的關鍵核心數據，考慮到企業安全、審計、合規、法律等限制。導致其同樣往往?法被前台系統直接使用，或是受到各類限制?法快速變化，以?持前台快速的創新需求。

此時的前台和後台就像是兩個不同轉速的?輪，前台由於要快速響應前端用戶的需求，講究的是快速創新迭代，所以要求轉速越快越好；?後台由於?對的是相對穩定的後端資源，?且往系統陳舊複雜，甚至還受到法律法規審計等相關合規約束，所以往往是穩定至上，越穩定越好， 轉速也自然是越慢越好。

所以，隨著企業務的不斷發展，這種“前台+後台”的?輪速率“匹配失衡”的問題就逐步顯現出來。

隨著企業業務的發展壯大，因為後台修改的成本和?險較?，所以驅使我們會盡量選擇保持後台系統的穩定性，但還要響應用戶持續不斷的需求，自然就會將大?的業務邏輯（業務能?）直接塞到?前台系統中，引入重複的同時還會致使前台系統不斷膨脹，變得臃腫，形成了一個個??球的“煙囪式單體應用”。漸漸拖垮?前台系統的“?戶響應?”，用戶滿意度降低，企業競爭?也隨之不斷下降。

對於這樣的問題，Gatner在2016年提出的一份《Pace-Layered Application Strategy》報告中，給出了一種解決方案，即按照“步速”將企業的應用系統劃分為三個層次（正好契合前中後台的三個層次），不同的層次採用完全不同的策略。

而 Pace-Layered Application Strategy 也為“中台”產生的必然性，提供了理論上的支撐。

在這份報告中，Gatner 提出，企業構建的系統從 Pace-Layered 的?度來看可以劃分為三類: SOR（Systems of record），SOD（Systems of differentiation）和 SOI（Systems of innovation）。

處於不同 Pace-Layered 的系統因為?的不同，關注點不同，要求不同，變化的“速率”自然也不同，匹配的也需要采?不同的技術架構，管理流程，治理架構甚至投資策?。

?前面章節我們提到的後台系統，例如 CRM、ERP、財務系統等，它們?多都處於 SOR 的 Pace-Layered。這些系統的建設之初往往是以規範處理企業底層資源和企業的核?可追溯單據（例如財務單據，訂單單據）為主要?的。

它們的變更周期往往比較?，?且由於法律?審計等其他限制，導致對於它們的變?需要嚴謹的申報審批流程和更高級別的測試部署要求，這就導致了它們往往變化頻率低，變化成本高，變化?險高，變化周期?。?法滿?由?戶驅動的快速變化的前台系統要求。

我們又要盡?保持後台（SOR）系統的穩定可靠，?要前台系統（SOI）能夠?而美，快速迭代。就出現了上文提到的”齒輪匹配失衡“的問題，感覺魚與熊掌不可兼得。

正當陷入僵局的時候，天空中飄來一聲 IT 諺語：

軟體開發中遇到的所有問題，都可以通過增加?層抽象?得以解決!

?此，?聲驚雷滾過，“中台”腳踏七彩祥雲，承載著 SOD（Systems of differentiation）的前世寄托，橫空出世。

我們先試著給中台下個定義：

中台是真正為前台而生的平台（可以是技術平台，業務能力甚至是組織機構），它存在的唯一目的就是更好的服務前台規模化創新，進而更好的響應服務引領用戶，使企業真正做到自身能力與用戶需求的持續對接。

中台就像是在前台與後台之間添加的?組“變速?輪”，將前台與後台的速率進行匹配，是前台與後台的橋梁。它為前台而生，易於前台使用，將後台資源順滑流向用戶，響應用戶。

中台很像 Pace-Layered 中的 SOD，提供了比前台（SOI）更強的穩定性，以及?後台（SOR）更高的靈活性，在穩定與靈活之間尋找到??種美妙的平衡。中台作為變速齒輪，鏈接了用戶與企業核心資源，並解決了配速問題。

有?“中台”這?新的 Pace-Layered 斷層，我們即可以將早已臃腫不堪的前台系統中的穩定通用業務能?“沉降”到中台層，為前台減肥，恢復前台的響應?；又可以將後台系統中需要頻繁變化或是需要被前台直接使用的業務能力“提取”到中台層，賦予這些業務能力更強的靈活度和更低的變更成本，從而為前台提供更強大的“能力炮火”?援。

——這就是為什麽企業在平台化的過程中，需要建設自己的中台層（同時包括技術中台，業務中台和組織中台）。

進入【獨家精選】菜單或點擊下列關鍵詞

微信ID：idg_capital

長按右側二維碼，關注「IDG資本」