中台：BAT們的下一個戰場！

內容來源：本文內容來自三節課（ID：sanjieke01）公眾號,筆記俠經授權發布。

作者| 張成翼

封面設計&責編| 亞飛

第3753篇深度好文：4970 字 | 6 分鐘閱讀

精選筆記·商業思維

本文優質度：★★★★★口感：回鍋肉

筆記君說：

互聯網公司為什麽都開始建設自己的中台？怎樣才能建設好公司的中台？

以下，盡情享用~

大約從去年年底開始，中台的概念開始被廣泛討論。

但與此同時，關於中台究竟是什麽，卻是眾說紛紜。

在有些人眼裡：中台就是技術平台，像微服務開發框架、Devops平台、PaaS平台，容器雲之類的，人們都叫它“技術中台”。

在有些人眼裡：中台就是微服務業務平台，像最常見的什麽用戶中心，訂單中心，各種微服務集散地，人們都叫它“業務中台”。

在有些人眼裡：中台應該是組織的事情，在釋放潛能：類似於企業內部資源調度中心和內部創新孵化組織，人們叫它“組織中台”。

這些理解都對，但也都有不夠準確或不夠完整的部分。

中台，作為一個還在被定義當中的概念，正處在一個大家都有感覺，但又難以被定義的狀態。

而且可預見的是，這種相對模糊的狀態可能還要維持相當長的一段時間。

與此同時，在查閱了大量資料、並與京東等大廠的中台相關負責人溝通後，我們發現：

目前行業內對於中台討論的視角還是多偏於戰略或組織架構層面，而中台更多是因為公司業務在發展到某一階段時，遇到瓶頸與障礙後，為解決實際問題而提出的解決方案。

雖然基於戰略的角度去看，確實能夠讓大家視野開闊，從更高維度理解中台。

但戰略是基於實際業務而制定的，如果撇開業務去空談，就如同空中樓閣，還是無法了解中台到底是什麽。

基於此，本文將會站在實際業務的角度，探討一下中台的“前世今生”，以及如果想要成為一個中台產品經理，你應該具備哪些能力。

一、為什麽需要中台？

市面上講到中台，一定會提到兩個例子。

一個是13年馬雲參觀supercell，然後在15年確定了阿里的中台戰略；

另一個是華為的中台戰略轉型，也就是那句著名的“讓聽得見炮火的人指揮戰鬥”。

這似乎會給大家一個錯覺，似乎中台是一種自上而下的戰略選擇。老闆覺得中台好，所以要搭建中台。

不過，現實情況，或許與絕大多數人想象不太一樣，中台的產生，並非完全是自頂向下的戰略設計，也並非是為了追隨某種行業風口，而是隨著公司業務高速發展、組織不斷膨脹的過程中暴露的種種問題需要被解決。

而這時，中台的概念恰好對應了這個問題，所以大家接受了中台。

過去幾年中，借著移動互聯網的紅利，許多公司都高速發展，進行大規模業務拓展，業務拓展的速度足夠快，對公司自然是好事，但是隨著而來的問題就是，公司內部出現了大量的重複建設和資源浪費的現象。

阿里的共享服務部發展歷程就是如此。

公司剛開始只有淘寶，後來意識到B2C模式的業務也會是電商領域重要的組成部門，所以出現了天貓，隨著天貓的不斷發展，逐漸獨立成一個部門，但是這兩套都包含訂單、商品、庫存、價格、倉儲、物流等基本業務系統。

這兩個系統互相獨立，各自運行。

等到10年左右，阿里開始上線1688、聚劃算等業務的時候發現，這些業務針對的領域雖然各不相同，但是他需要用到的系統功能也高度類似，主要也是訂單、商品、庫存、價格、倉儲、物流等系統。

如果這些新業務的系統也都要全部重新開發一遍，這無疑是很大的資源浪費。

明明既有的系統調整一下就可以滿足新業務的需求，為什麽還要繼續開發新系統呐？

在這個大的背景之下，阿里內部將共享服務部的職權不斷提升，統一將各個業務業務部門重複使用，反覆建設的功能和系統統一規劃和管理。

其實，很多公司的中台部門，或者平台業務部門的出現都有類似的背景和情況。

比如說，滴滴在15年末開始啟動自己的中台戰略，這與滴滴當時的業務發展階段也是相關的。

2015 年末，滴滴在短時間內形成了包括快車、計程車、專車、順風車、代駕等多業務的垂直化架構。

這些業務雖然會有一些差別，但是核心系統和流程都是類似的。如果各自獨立開發，也會出現各種各樣的問題。

比如說，開發成本過高，滴滴旗下的每個業務，其實都是可以單獨支撐起一家公司的。

如果每個業務都獨立做到極致，那麽開發成本和人力成本就會非常巨大，而如果為了控制成本，就把系統的建設放緩，則意味著，無論是核心系統本身的質量，還是對外的用戶體驗都不太好。

在這樣的背景下，滴滴也開始考慮將諸多業務，以及各個城市的系統統一規劃，統一建設，提升服務前台的能力。

其實，剛剛我們提到的，以及許多正在實踐中台業務的公司，都有類似的問題，這些問題，大約會是兩類：

一類是，許多業務需求或功能需求高度類似、通用化程度很高，但是由於沒有專門的團隊負責規劃和開發，大量的系統重複開發、重複建設，導致複用性低、效率低、產研資源浪費、用戶體驗不統一。

另一類是，早期業務發展過程中，為了解決一些當下的業務問題，垂直的、個性化的業務邏輯與基礎系統耦合太深。

由於沒有平台性質的規劃，橫向系統之間、上下遊系統之間的交叉邏輯也非常多，這樣導致在新業務、新市場的拓展過程中，系統沒法直接複用，甚至沒法快速迭代。

這兩類問題，在軟體開發領域，有專門的名稱，叫做“重複造輪子”和“煙囪式架構”。

這兩類問題本質上是企業在發展過程當中，為了解決當下的業務問題，快速上線了很多功能，而欠下了許多技術債，當企業進入成熟期之後，發現這些問題的存在，嚴重影響了企業的運行效率和運營成本。

如何能夠機制化，產品化地解決這些問題，能夠更好地通過產品的形式？

將企業內部具有很強的通用性的數據、功能、產品甚至經驗進行統一規劃和開發，進而更好地幫助前台業務部門更多地關注業務，提高業務運營效率，進而提升企業競爭力，是企業開發中台的基本出發點。

現階段，大多數提出中台戰略或是建設大中台的公司，大多都有類似的困境。

業務高速發展多年，許多問題積重難返或者大量在解決“重複造輪子”的問題，中台這個概念，很多情況下是因為契合了大公司業務的發展的情況，而被大家廣泛認可。

二、中台能解決什麽問題？

前面的內容，我們大致介紹了中台要解決的問題。

這給我們一種感覺是，中台是只有大公司才能做的事情，因為畢竟只有大公司在會有這種多條業務線，需要大量通用功能的場景，也只有只有大公司有能力拿出如此大的資源打造個中台。

現實情況也如我們所說，很多公司的中台業務，實際業務發展到一定階段，進入一個瓶頸之後，為了能夠應對接下來的問題，才一點一點從內部開始推動解決之前的問題。

但這其實只是中台建設的一個層面。

中台作為一種產品設計思路，或者系統架構思路，並不受限於公司的規模。

理論上講，任何一家即將或者正在面臨業務高速增長的狀態時，都很值得利用和借鑒中台的思路，將目前業務當中大量可複用的功能和場景進行梳理，為業務的高速增長做好準備。

這在中小公司當中，是有現實意義的。

對於很多中小公司，當他們走出生存困境，進入到高速發展階段時，會遇到很多的問題，但大概率會遇到的一個問題是，過往的業務模型，產品能力很有可能沒法完全承接住大規模用戶增長帶來的壓力。

而當你具體到每個用戶的時候，你又能發現，他們遇到的問題你之前都遇到過，只不過，因為一下來的太多，你沒法像過去一樣提供達預期，甚至超預期的服務時，對方就會產生不滿。

這也是為什麽許多公司會生於拉新，死於留存的一個原因。

很多公司在這個階段的選擇都是為了臨時解決一個問題，快速上線一個功能，也不是不可以，只不過，很有可能你的解決方案會不斷帶來新的問題，最後陷入到功能太過複雜，以至於積重難返的地步。

所以，在有可能的情況下，公司將一些大概率長期有價值的功能，專門模塊化，進行開發和優化，確保即使業務規模進一步擴大，也能夠滿足業務需求。

甚至，隨著能力或方法論的不斷優化，甚至有可能某一天成為整個行業的方法論。

這個過程，就很像是在高速飛行過程中修飛機一樣。

一方面，機翼已經千瘡百孔，搖搖欲墜。

另一方面，發動機還在運轉，你還能往前飛，但你知道，如果再進入到下一場戰鬥，你不見得還能確保飛機不會墜落，所以，必須搶在下一次戰鬥前把飛機修好。

隨著業務的發展，你對飛機的要求，也不僅僅是修好，可能會希望，能夠提前預防一些問題。

或者，知道你的飛機哪裡戰鬥力最強，就把哪裡做到最好。或許，就能夠回避之後的一些問題。

這或許是中台這個概念，對於中小公司內部產品規劃的一個啟發。

當然，需要提示的一點是，對於中小公司而言，中台的理念不見得是單獨拉幾十人搭建一個中台產研團隊。

可以將一些關鍵流程先行標準化，把一些反覆出現的場景當中的解決方案進行沉澱，部分需要產品化的功能先行產品化，可能對於一家業務剛剛開始起步的公司來說，就已經很重要。

三、中台產品經理的挑戰

之前的內容，我們其實花了很大的篇幅來討論，為什麽會有中台，中台解決怎樣的問題，以及中台適用怎樣的場景。

但是，具體到業務場景當中，中台產品經理又在做什麽事情，解決怎樣的問題？如果想要成為一名優秀的中台產品經理，又會遇到怎樣的困難和挑戰？

我們採訪了一些大公司的中台部門之後，會發現，中台產品經理面對很多挑戰，其中，最主要要是最困難的挑戰，主要集中在這樣兩個方面。

一方面，是思維的差異。

很多產品經理並不是從一開始就從事中台相關的事宜，也不是一開始就有中台這樣的定位。

更多情況下，他們是從前台業務部門，或者以業務為導向的產研部門轉型到中台產研部門。

這時，其實要面臨很大的思維方式、做事方法的轉變。

在業務部門或者以業務為導向的產研部門，最核心的目的就是達成業務目標，要求你速度足夠快、功能高效地解決當下的業務問題，當前業務發展的效率是最關鍵的。

至於說，這個功能將來有沒有可能適用於別的場景，有沒有可能解決別的問題，這個問題實在是沒那麽重要。

但是，對於中台不能如此。

對於中台產品經理來說，必須思考的問題是，這個功能在現在或者將來能滿足多少業務場景？如果將來有新的業務出現，是不是能夠複用？

或者說，需要做多大的調整才可以複用？甚至於，這個功能有沒有可能對外輸出，提供SaaS化的服務。

這些問題，是中台部門需要思考的問題。這是思維上的差異。

另一方面，是環境的變化。

當你在業務部門的時候，響應業務是相對輕鬆的。但是，在中台部門，響應多個業務，就沒有那麽輕鬆了。

更可怕的是，同樣一個問題，由於業務的發展階段不同，對於問題的態度也全然不同：

有的部門業務已經非常成熟，自己流程也很清晰，所以不太希望你來調整他們現有的流程；但是，有的部門還處於探索期，還沒有遇到你提出的問題，可能壓根就不理你……

這時，對於中台產品經理的挑戰就非常大。

他們可能會將大量的精力耗散於不同部門之間的溝通協調，反覆對同一個需求進行確認，很長時間沒有明顯突破。

這個時候，就要求中台產品經理有很強的溝通、協調和協作能力。

並且，因為他們接下來要做的解決方案，是要服務於多個業務。

這個時候，需要中台產品經理有很強的邏輯思考能力，看到不同需求之間的共性需求，並提煉出一個產品化的解決方案。

甚至於，對於一些尚未遇到這個問題的業務部門，可能還要幫他們前置地思考解決方案。

這又很要求產品經理的邏輯思考和抽象思考能力。

既需要溝通協作的軟技能，又需要邏輯抽象的硬思考，這可能才是中台產品經理最有挑戰的地方。

結語

對於中台產品經理來說，剛剛我們提到的內容，也只是幫助中台產品經理，對於中台產品這個崗位所要面臨的挑戰和工作，能夠有一些初步框架性的理解。

但是，在實際業務場景當中要解決的很多複雜問題。對於中台產品而言，他們的能力要求其實跨越非常大。

一方面，需要極強的邏輯思維和戰略分析能力，能夠看到業務當中的關鍵流程，理解業務接下來的發展方向，並將其轉化為產品功能，與研發一起實現。

另一方面，又需要極強的溝通和交流能力，能夠在與多個業務線，需求、背景、想法各不相同的相關方一起，推動完成相關功能的實現。

這背後，是技術，也是藝術。

某種意義上，能夠掌握掌握這兩種似乎有些對立思維，並能夠靈活運用，可能距離成為一個優秀的中台產品經理，就不太遠了。

好看就點在看