這是一個四年前的中臺建設案例。作爲國內早期進行中臺實踐的大廠，最終也沒有逃開失敗的結局。
正值 2016 年“直播元年”，在短視頻風口上，國內某大集團開始調動各業務線的精兵強將，組建新的業務單元，以“業務中臺”的形式集合公司力量，想要迅速佔領行業高地。
公司對這個“業務中臺”的投入也是實實在在的：產研七十人左右，運營六十多人，數據團隊幾十人，採購團隊四十多人，審覈團隊幾百人... 前後涉及大幾百人。
然而在短短十幾個月之後，這個“業務中臺”就宣佈被撤，團隊成員有人轉崗，有人被裁，最後只保留了數據中臺團隊。
這個直播項目最終不聲不響地逐步淡出了大家的視野，並沒有激起短視頻內容生態上任何水花。
四年後，在“中臺”風盛行的今天，這個項目的重要參與成員，從不同角度對這個項目進行了“覆盤”。
1起因：想在風口上進軍短視頻
大約在 2016 年的秋天，某產品線負責人對我說：“有一個關於短視頻的創業項目，很有意思，要不要考慮加入？” 那年被稱爲”直播元年“，短視頻平臺逐漸興起，並以不可阻擋之勢發展着。集團想在”短視頻賽道”發力，覺得努力一下可能會做出不錯的成績。大家也都覺得這個事情很靠譜，這在當時是個不錯的方向，只不過需要新建一個獨立 BU 來運作。
這個新業務單元的目標，是要完成一款傳奇短視頻客戶端的產研與推廣。此外在推進過程中還需對內容進行相應配套——而內容生態恰好是個更加複雜的單元，要涉及到很複雜的人力調度。爲了組建這個新的業務單元，經過大 HRG 的前後協調，從不同事業羣選擇了一些小夥伴加入進來：從南方某事業羣調來了產品線、審覈線、技術線、BD 線、審覈線；從北京某集團調來了產品線、算法線、審覈線、BD 線......
人員調齊後，經過多次碰撞，公司召開了一個聲勢浩大的啓動大會，希望大家儘快完成目標並佔領行業高地。
過程中前前後後投入了大幾百人的資源，但這個中臺項目並沒有很好地推進下去，僅僅經過十幾個月，業務單元就被分拆了。項目也不聲不響地淡出大家的視野，並沒有爲企業的內容生態形成強力壁壘。這是爲什麼呢？結合當時的筆記和現在的思考，我總結出了一些關鍵點。
2爲什麼要進行中臺化建設？
從當時的條件與思考來看，平臺化解決了技術平臺的問題，但是每個單元業務的執行都要跨多個領域來完成，複雜度會隨之升級。比如說淘寶的寶貝，商品發佈規則、交易規則、營銷規則散落在各個系統中，進行一個動作時，無法做到靠一個人就能說清楚全局。結果就是一個需求要評估一個月，開發需要幾天，測試又需要幾天，這已經不是一個流程能夠解決的，是一個比較複雜的生態協作問題。
-
“大中臺”的概念就是從較爲複雜的協作生態上來縱向地從服務鏈路來做資源整合，技術中臺注重能力沉澱與整合，業務中臺注重鏈路、效率、成本、流程優化。業務中臺在我的眼裏變成了規則引擎執行者與定製化服務輸出方，規則的輸出通過對數據的控制來進行。
-
大企業的很多業務在最初都會經歷瘋狂的擴張過程，在這個過程中由於各個 BU 自我閉環，導致大廠內部存在着很多重複造輪子的工作。比如同樣在內容領域，獨立 BU A 做了一款 App ，獨立 BU B 做了一款 App，都有很多詳細功能。但是這些功能在內部的必要性又沒有那麼強，繼續做存在着人力成本的浪費。這個時候我們會通過一個抽象出來的公共業務模塊去單獨處理。
雖然這個集團是某體系當中的巨無霸，但是在內容生態這塊其實還是較爲薄弱的，需要一個業務中臺來支撐內容生態。當時的情況是：好幾個事業羣都有類似的生態業務在運作。比如南方某事業羣有自己的圖文內容生態，北方某事業羣有自己的視頻內容生態，各自的生態又分別爲各自客戶端業務提供內容生產審覈，帳戶體系、內容評定標準、獎勵機制各不相同。具體到數據體系上，其中兩個子集團或成爲事業羣的業務方都有各自的數據體系，造成的問題是：
-
賬號沒有打通，賬號評估與分級體系不統一；
-
內容評定標準不統一、品類不統一、標籤體系不統一、獎勵機制各不相同；
-
審覈問題，但凡做內容必須有審覈，不同子公司在審覈的投入上都很巨大；
-
採購問題，不同 BD 採購流程不同，或簽約多個主體；
-
內容生態所涉及到的帳戶數據、圖文、視頻、粉絲互動、內容庫、消費數據、內容審覈等較容易整合並服務化。
從集團角度來看，這就形成了煙囪式的建設。每一個煙囪的能力直接決定了業務的發展速度與業務創新的成本，但實際上業務的快速更新與創新更需要像樂高一樣的體系去快速搭建。結合內容生態這個業務來看，根基與出發點是偏業務型的中臺建設。實際上我們可以通過一點接入、多點分發的方式來支撐各端業務，做好內容生態供給。在建設過程中對信息、標準、帳戶、數據做一系列打通，將業務流、內容流、分發流、數據流、商業流這些相近的單元進行業務中臺化。
3未決的問題：中臺的 KPI 誰來背？
幾個月後，領導提出了一個問題：“這個業務中臺的考覈目標是什麼？”
這塊業務是做內容生態、創作者生態，但是當時只有創作、內容生產、內容審覈、內容庫等等從內容維度的獎勵，沒有內容的出口。面向 C 端的出口都在其他 BU，那這個中臺業務如何進行考覈？考覈指標該如何制定？
-
要從規模、品質、活躍、消費、互動、收益這六個維度定義十幾個指標嗎？
-
要從月 / 日均活躍賬戶數量、月 / 日均賬戶生產文章數量，再加上賬號內容在端的月 / 日均播放量、閱讀量等等維度進行考覈嗎？
無論從哪個角度來看，都感覺不太合適。這些指標都受到端的影響，沒有一個指標僅僅跟中臺業務本身相關聯。比如有的人提到既然是圍繞創作者的生態，那就只看創作者、內容生產就好了，但實際上每一部分都有成本，如果生產出來的內容在不同端效果很差，到底是用戶畫像的問題，還是算法的問題，還是內容質量的問題？各個業務都要承擔 KPI，自然就會打架。
另外，以前各端的創作者獎勵相當於成本，現在因爲都歸到中臺來承擔了，從財務角度只看到成本，那收益和利潤該如何算呢？因爲出口在各端，不同端的信息流中商業化收入會算到各端業務側，在內容商業化探索上，也沒有想象得那麼容易。
4緩慢的中臺建設與快速變化的業務需求
偏業務型中臺在建設中是有自己難題的，首先要服務好下游的內部業務方，其次還要完成對外部業務方的支撐，最後還需要完成自身建設。這個中臺是要將原本分散在不同端內容生態上的業務邏輯進行重構，並整合類似的業務模塊。自身建設含有產品建設、內部運營工具建設、對用戶的運營工具建設，在資源有限的情況下，如何能做到這幾個方向的平衡呢？
業務中臺所服務的業務對象有幾個，分別完成對端的業務支撐，對自身創作者與內容的支撐，完成自身建設。
在端的業務支撐上，需要服務好各個內容信息流下發端。比如一個集團內不同業務線的各種含有信息流、內容頻道的 App；再比如需要能夠承接住端訴求的對應產品體系，端自己去做各種垂直品類的差異化運營所需的內容，商業化統一結算、類目統一化、標籤統一化、評級體系統一化、端需求差異化與統一採購...... 每一塊的內容都會影響到端的下發以及端 App 本身指標以及內容消費指標。
在對創作者與內容的支撐上，需要完成自身的業務建設。把內容創作引入進來後需要從業務自身角度去維持這個賬號的可持續創作能力和優質內容創作能力，不管是從產品角度提供創作輔導、創作工具賦能、數據工具分析，還是從運營手段提供獎勵機制、激勵機制、分潤機制，都是出於“讓這個創作者活着”的目的。
在自身建設上，除了上述產品外，還有標準化、組件化建設，以及支撐內部運營的工具建設。分別可以從內容引入、內容管理、內容消費以及數據體系建設上進行細化。
以上這些方向如果按照中臺的角度來做拆解，還是需要一定節奏去建設與實施的。否則“產研運”再牛，也不能短時間內建設出來一套支撐各業務方的業務中臺來。
中臺的建設過程中節奏是最要命的。這其中有一個矛盾點，就是業務線在發展中是快速變化的，快速變化必然就會渴望得到各種資源支持。但是中臺大部分是在緩慢建設與推進，兩者之間會產生訴求與承接能力不匹配的問題。這塊如何做好平衡，就涉及到先做什麼、後做什麼的問題。
現在市面上對於中臺的所有文章千變一律都是在講概念，講藍圖，有沒有經過實踐驗證呢？成功的概率到底有多大、 每一步該怎麼走？
5避免不了的“失敗”結局
十幾個月後，因爲項目建設不盡人意，我們的項目組被拆。回顧那一年的外部大環境，在這個領域很多公司都是快速崛起與佈局，而我們這個中臺項目卻在當時形勢一片大好的情況下失敗了。這是爲什麼呢？
前面我們從矛盾論的角度、因果角度、建設角度做了不同維度的覆盤。今天回過頭再看，還有幾方面原因：
-
數據團隊需要在幾個業務團隊中尋找一個平衡點。
-
人的因素——想法太多，都想驅動這個中臺。
-
人員能力問題：做中臺的難度與做普通產品相比，有量級的差異。能力不足，真的搬不動這塊石頭，還砸了所有人的腳。
-
中臺建設是一種思考方式，但是在過程中因爲各有所需，變成了“腳痛醫腳、頭痛醫頭”的傳統方式。原本想象的是一條線到頭的建設，實際上是多條線交織成一個複雜網狀，成爲了比較難以拆解的問題（表象看是一個資源問題）。具體中臺該達成什麼目標，承擔哪些職能， 還是需要慢慢沉澱、迭代。
-
流程的問題，太多太長。
-
其它。
資源問題我相信是所有管理層最關心的問題了。在這個項目中，包含了七十左右的產研、六十多位運營、幾十位數據人員、四十多位採購 BD，以及大概幾百人的審覈團隊。如果算上流動，前後大概有好幾百人。
“業務中臺”項目被拆之後，產品轉崗了，大部分運營被裁了（只留了小部分運營）， 但保留了較爲完整的數據團隊。因爲數據業務的獨特性適合中臺化，且是“主動建設”，所以一直跑在業務前面，並強化了核心資產、應用模式、核心業務模型和縱向場景。但我們這個切入點很好的業務單元，經過很多人的努力，結局卻是說撤就被撤了，非常值得回味......