
不同於前幾年的熱潮,最近一段時間,互聯網大廠關於「中台」的討論,似乎總是瀰漫着一股質疑與悲觀的氣氛。
2021年12月,阿里巴巴集團董事會主席兼CEO張勇宣布,從2015年的中台戰略升級為「多元化治理體系」。張勇在2015年提出的「大中台、小前台」戰略,是阿里過去幾年最重要的組織戰略,目的就是為了支撐前台的一線業務變得更加敏捷。
不僅僅是阿里一家對中台做出調整,2021年11月,字節跳動新任CEO、董事長梁汝波上任後最新一輪架構調整中,新合併成立6個業務板塊,將原先的通用性中台發展為企業服務業務。總言之,思路也是拆分「大中台」,合併「小前台」,從過去的職能架構轉變成事業群架構,把中台能力分拆至各事業群。
如今,在互聯網大廠內部,中台似乎成了效率低的代名詞,質疑聲四起。互聯網公司內外都到了復盤與反思「中台」的時刻。
傳說,2015年,阿里對標芬蘭遊戲企業Supercell建立了「中台」,無意中引領了一股互聯網業界的潮流。
從2009年成立「共享事業部」,再到2015年啟動「中台戰略」,阿里一直是中台建設的堅定探路者與踐行者。這也為其業務的快速發展帶來了巨大好處。例如,阿里僅用1個半月就上線了團購平台(聚划算),而同類團購平台投入的研發資源可能是阿里的幾十倍,準備時間可能是阿里的幾倍。
互聯網大廠迅速感知到中台的魅力,並在2018年末至2019年初密集推行中台戰略。至今,中台建設似乎已經成為標配。但在中台如火如荼之際,我們依然可以聽到不絕於耳的反對之聲。不少從業者甚至感嘆,中台在「理想國」的表象下是一個猙獰的「葬送場」。

什麼是中台?
中台,作為平台型組織的一部分,是在前台作戰單元和後台資源部門之間的組織模塊。這些模塊多半是傳統組織中所謂的成本中心,它們負責把後台的資源整合成前台打仗所需的「中間件」,方便隨需調用。
打一個通俗的比方:糖醋排骨、魚香肉絲、松鼠桂魚這幾道菜,都需要糖、醋、生抽、老抽、澱粉等調料做成的糖醋汁,廚師可以提前調製好糖醋汁,在做某道菜時直接加進去就行。
其實,這背後有一個沒有被大眾熟知的概念——模塊化(modularity),即把一個系統里緊密連接的兩個部分進行「鬆散耦合(Loosely Coupled,也稱退耦、解耦)」,減少模塊間的關聯,增強其獨立性。說通俗點,就是把一個整體做成樂高積木式的拼接結構。這樣一來,某些頻繁被使用的組織模塊就成為共用「中間件」,即中台。其實,從20世紀60年代起,模塊化的思路已經在產品設計、組織設計、企業間關係設計上流行了起來。
但有意思的是,互聯網企業的影響力太強了,當它們開始遵循這種組織設計基本原理時,這種運動就變成了潮流。於是,當下人人都在談中台,這似乎又變成了一種創新。
從互聯網的技術邏輯上去找中台建設的方向,絕對是一個進步。模塊化的原理是舊的,但互聯網的技術是新的,在舊原理下做出新解決方案,是需要水平的。現在提到的技術中台、研發中台等概念,都是在做一種技術架構,並以這種架構來重新規劃組織。因此,我們也沒有必要強行去調整這個潮流中的概念,而是將其歸納為「業務中台」。
當然,互聯網企業對於中台的信心不僅在於模塊化實現的「退耦」,還在於利用IT技術實現的「全域數據化打通」,阿里稱其為「數據中台」,業界稱之為「中台的中台」。當企業的各類資源都被數據化,且數據孤島被連通到一個平台上,資源的供給、業務的需求、界面的協作等一目了然。

為什麼要上中台
傳統的組織設計,永遠是在三個約束條件中求最優解的過程。
靈活性——建立的組織結構能否應對市場的各類需求,這是企業生存的基礎。
經濟性——能否用最精簡的人員和機構支持業務,因為人員和機構不僅會形成顯性成本,還會產生大量隱性成本(內部交易成本)。
規範性——能否對擴張出去的分支機構進行有效管理,確保其路徑規範、不踩紅線、有效協同。絕大多數老闆寧願企業發展得慢一點,也不願失控,因為風險太大。
中台的建設顯然是後一種情況。面對互聯網時代變幻莫測的市場,企業不可能為諸多的小前台單獨配置職能。以電商企業為例,當線上、線下、ToB、ToC業務團隊都需要開發「訂單功能」,此時就沒有必要在每個業務里都單獨開發一次,而是將其放到中台統一開發、大量復用。這樣一方面更有經濟性,另一方面為後來打通數據做好了鋪墊。
另外,中台似乎也沒有犧牲靈活性。當抽取出來的職能實現了「鬆散耦合」,就能夠被前台隨需調用。小前台在市場上無孔不入,靈活探測客戶需求,而後調用強大中台的功能模塊來實現交付,這是多麼美好的畫面!
除此之外,互聯網時代為組織設計靈活性提出了新要求——體驗感。互聯網時代的信息透明,導致了產品之間競爭激烈,嬌慣的用戶對體驗感的要求前所未有。以前企業把產品做到60分就行,現在必須做到90分,它們需要「靈活的深度交付」。
用戰爭來做個比喻:以前要攻克堡壘,組建一個「獨立團」,配上衝鋒鎗、手雷、火箭筒就行;而現在的攻堡難度增加了,需要調用無人機、轟炸機、導彈等進行重度火力打擊。從這個意義上說,中台建設就是構築「重度火力」。
如此看來,企業為什麼如此積極地建設中台,就不言自明了。

上中台的挑戰
中台自然有諸多的好處,但建設中台卻必須要通過三道「鬼門關」。
1.建設成本
從前台抽取出業務的共性,再進行統一建設,看似原理簡單,實則兇險無比。中台畢竟遠離一線,不可能100%了解業務需求,它們需要先與業務部門一起梳理需求,再抽取出共性建設公共模塊,最後還要保證這個公共模塊與前台業務的適配性。這個過程中需要投入大量的人力。據以中台作為服務內容的外包商反饋,項目耗費的人力多到誇張,人力成本是項目成本的大頭。

大多數企業遇到的問題,並不是因為建設中台的邏輯存疑,而是因為中台沒有建好。俗話說「舉重才能若輕」,中台沉澱得越好,才能夠應對各類需求,並在交付上實現超高的體驗感。大多數企業沒有相應的沉澱,前台調不出支持,好比打仗時大後方不給彈藥補給。這時候你不應該討論是否要建彈藥庫的問題,而應該想想平時做了什麼,導致彈藥庫如此匱乏。
2.改革成本
大多數業務領導都會選擇「做大勢力範圍」和「屏蔽上級監控」。前者意味着更大的權力範圍和更多的預算撥付,後者意味着更大的決策空間。想當「藩王」是人性使然,如果控制在一定的範圍內,危害不大。
而上中台意味着組織變革,顯然與人性相悖。在企業內呼風喚雨的前台部門要將職能讓出相當一部分放到中台,相當於「割地」;它們還需要將數據打通,使自己部門的業務全部可視化,相當於「戴上緊箍咒」。這種「削藩」的動作太大,只有一把手敢做,還必須是對企業有超強控制力的一把手。
典型的例子是阿里。2015年末,在張勇提出「大中台、小前台」的組織戰略後,阿里在2016~2019年內進行過19次組織調整,當中涉及諸多高管換崗、部門合併,動靜之大可想而知,這也為中台建設掃清了障礙。
3.改革後成本
這道「鬼門關」最讓人絕望。建中台本來就是一種挑戰,要面對的是前台的官僚主義,但當企業建設出一個大中台,又會面臨中台更大的官僚主義。
2010年,海爾在改造倒三角組織結構時,將企業內的部門裂變為2000多個自主經營體。其中,一級經營體是研產銷三大職能的若干小團隊,而二級經營體也稱「資源平台」,包括銷售平台、研發平台、供應鏈平台等。除了沒有當前這樣極致的IT化要求外,二級經營體就是現在的中台。
原來的想法是由前台團隊來拉動平台資源,二級經營體被要求建立資源豐富、定價清晰的「資源超市」,與一級經營體簽訂市場化的服務協議。但這個層級本身就是各級資源的「管理者」,而且在內部是壟斷的,要它們「聽從前台指揮」,顯然太難了。
典型的場景是,一個小地區的市場經營體雖然與國內銷售平台這個二級經營體簽訂了服務協議,但其面對一個集團的「大部門」和「大領導(銷售平台經營體體長)」,基本是沒有話語權的。更讓人無奈的是,當上游只有一個壟斷的內部供應商,定價更是說不清。
大約十年前,中興和華為也面臨過相似的問題,它們提出「一線主戰,專業主建」,將中台稱為「XX體系」,同樣帶來了官僚主義。中興通訊的一位中層稱:「體系里都是大爺,要調動資源得使出十八般武藝。」這些企業在碰壁之後,都開始尋找新的解決方案。但現在不少文章還在引用它們十年前的組織結構來支持中台建設的觀點,這是錯誤的。

中台的未來
在上中台的潮流中,大量IT廠商一擁而上,資本也開始追逐此類項目,看起來,中台似乎變成了一門好生意。從2015年開始,以中台名義獲得融資的筆數一路走高。2020年3月,明略科技集團在E輪獲得了3億美元的融資,考慮到中國SaaS企業普遍估值較低的現狀,這樣的融資規模實在讓人意外。
這些企業最初的想法是,完成一個標杆項目後,中台的解決方案可以在簡單修改後遷移到下一個項目。但這個想法顯然太過天真,別說跨行業,就連一個行業內的兩家企業,情況都大不相同。不同的商業模式、不同的業務流程、不同的組織結構、不同的人員素質……中台建設似乎天然就是無法模板化、標準化。
所以,這更像是以總集成商的身份來做「深度諮詢+IT解決方案」,需要堆人頭來解決問題。而且,堆人頭只能解決建設成本問題,無法解決改革和改革後的成本問題。由於缺乏可複製性,上不了規模,作為生意前景存疑。
2019年初,阿里雲智能事業群總裁張建鋒(行癲)在內部戰略會議上提出,如果阿里雲一味沖在前面做總集成商——客戶的特性可能千差萬別,總包就要做定製化方案和實施——會透支阿里雲的品牌。
如果不做總集成商,IT廠商可能需要從SaaS走向PaaS,提供一個平台支持ISV(Independent Software Vendors,獨立軟件開發商)和客戶的快速自主開發。國內不少企業認為,SaaS層面已經不能提供客戶需要的獲得感了,尤其是具備支付能力的大客戶,迫切需要更深度的定製化。
但這樣的方式也需要巨大的投入,盈利性和易用性都必須有龐大客戶規模的支撐。在當下國內IT廠商所處的階段上,極有可能是個「深坑」。
這可能是大廠才玩得起的遊戲。2019年阿里雲峰會上,行癲甚至表示「阿里雲自己不做SaaS,讓大家來做更好的SaaS」。顯然,阿里雲已經做好了「練好內功被集成」的準備。當前,阿里雲提得更多的是「數據中台」而不是「業務中台」,業務千差萬別,而數據中台的產品更容易標準化。數據中台實現的「全域數據打通」才是中台的威力所在,以這種方式推動「企業上雲」儘管稍顯緩慢,但也許更為可行。

綜合來看,將中台作為一門生意對大多數IT廠商而言並不可靠。從產品角度看,中台不是一個IT產品,也不是一個「諮詢+IT」產品,而應該是企業為自己定製的「高奢品」。從企業角度看,中台不是一套組織架構,只是平台型組織模式(架構+機制)的一個戰略要地。如果僅僅以建中台的視野來行動,是解決不了問題的。相當於你手臂的力氣再大,也不可能把自己全身舉起來。
以海爾為例,在意識到這類中台會產生更大的官僚主義後,海爾打造了由後台的財務、人力、戰略等部門派出的多角色BP(Business Partner,業務夥伴)團隊。這些團隊在內部被稱為「三自」,它們能推動前台團隊的自創業、自組織、自驅動。它們進入前台與其協同作戰,並代表後台加速資源和機制的精準配置。
BP團隊在激勵方案里將前台和中台關鍵節點的利益綁在一起,就實現了分配上的共同劣後。說通俗點,錢在一起了,心就在一起了。
這類團隊是前後台之間的連接器,是平台型組織「真正的中台」。在中台的研究里,有人將這類中台冠以「組織中台」之名。顯而易見的是,沒有組織中台,即使有了全域打通的數據中台,業務中台也很難發揮出期待的作用。
企業經歷千辛萬苦建設業務中台和組織中台,走向平台型組織,背後應該是老闆「堅定的相信」和「洶湧的野心」。他們相信未來業務的擴展空間,相信變化的市場需要超強的組織柔性,更相信傳統金字塔組織只能實現線性增長,平台型組織才能實現指數級增長。他們要做的不是一個單體企業,而是要打造一個行業生態,所以他們才會不遺餘力地將企業打造為平台型組織,建設好生態的底層。若非如此,他們很難對於過程中的艱險視而不見。
說白了,要不要建中台,最終還是要看老闆是怎樣的人。離開了這個原點,再多的分析也是白搭。



