2016年，短視頻熱浪開始襲來，筆者所在集團也提出了入局短視頻賽道，做業務中臺化的決策。然而在組建數百人團隊、投入大量資源后，這項中臺建設項目還是以失敗告終。

繼《鬼話連篇數據中臺（一）：透過中臺看數據中臺》后，這是該系列的第二篇，從另一個角度看來也算非常特別的一篇，這是一個不是那么成功的業務中臺建設實際案例的回顧，改為獨立篇章。

春節前與上個 BU 的成員聚會時還是回顧這個中臺建設的話題，就是“開局一條狗，裝備全憑抖”，這塊業務算很好的業務中臺建設的切入點，但是經過很多人努力去建設，結局就是說撤就被撤了，是什么問題引起的？在整個文章中會逐漸稍微展開分享一下的。

另外自己以往寫文章都是偏數據產品、BI 類，第一次來寫業務類的文章，對于自己來講也算是一個小的挑戰。

ps：關于各種中臺的定義還是一如既往的不給出定義，因為定義都已經滿天飛，大家要系統化了解中臺這個方向還是去看其他文章。

01 背景與起因

大約在 2016 年的秋天，集團某業務線的產品負責人說：“有一個很有意思創業項目，具體的是關于 是關于短視頻的創業項目，考慮加入嗎？” 經過更詳細的了解后得知：這位產品線負責人與事業群頭頭一起勾兌提到“短視頻賽道”可以做，努力一次，可能在短視頻賽道上做出蠻不錯的成績的。一群人多次合計了下都覺得這個事情蠻靠譜的，在當時是個不錯的新方向選擇，但是呢需要構建一個新獨立的 BU 來運作這個事情。

因為這個計劃中的業務是涉及到很復雜人力調度，為了組建這個新的業務單元，經過大 HRG 的前后協調，從不同事業群選擇了一些小伙伴加入了進來，分別從南方某事業群調來了產品 A 線、審核線、技術線、BD 線、審核線。從北京的某集團調來了 產品 B 線，算法線，審核線、BD 線。我自己作為當時 BI 線從其他線進入了新的 BU 的。前后經歷了多次碰撞以及共建后，順利地召開了個一個聲勢浩大的啟動大會。

由此由一個多國部隊組成的新業務線就宣誓成立，提出的口號是 4 月份上線，7 月份 DAU 3 千萬，潛臺詞是我們財大氣粗，不需要考慮成本與投入，完成業務目標與占領行業就可以。

新組建這個 BU，主要任務是要完成一款傳奇的短視頻客戶端的產研與推廣，在實際的執行過程中，受到歷史包袱問題以至于這款客戶端在很長的一段時間內一直承載長視頻、動畫的播放，需要在很短時間內向短視頻信息流轉變，結果就是這款 APP 的 90% 長視頻消費用戶受到打擾逐步在流失。

產品運營各業務方就需要去考慮這個事情，結果如何在這篇文章是中不重要的，重要的是，要完善這款短視頻，除了在完善必須的客戶端外，還得配套有推薦引擎與內容庫。在構建內容庫就需要根據來源分為爬取或者是自生產，通過不斷的完善內容創作生態來維持一個高質量的內容來源。如果要做內容創作生態，那更是一系列的業務鏈條需要建立。

在當時接觸到的北方的某事業群、南方某事業群都分別有類似的生態業務在運作——南方某事業群有自己的圖文內容生態，北方的某集團有自己的視頻內容生態，各自的生態又分別為各自客戶端業務提供內容生產審核等，帳戶體系、內容評定標準、獎勵機制各不相同。

各自的數據體系，其中兩個子集團或成為事業群的業務都是各自的數據體系，尤其是在帳戶數據、圖文、視頻、粉絲互動、內容庫的、消費數據上都在那時沒有打通，還有蠻多其它的的問題像平臺眾多、模式相近、同質化嚴重、變現不足等，但是聚焦幾個比較突出的問題分別是：

• 賬號體系問題，賬號沒有打通、賬號評估與分級體系不統一；
• 內容評定標準不統一、品類不統一、標簽體系不統一、獎勵機制各自執行；
• 審核問題，但凡做內容必須有審核，不同子公司在審核的投入上都很巨大；
• 采購問題，跟 BD 采購流程不同，或簽約多個主體；
• 內容生態所涉及到的帳戶數據、圖文、視頻、粉絲互動、內容庫的、消費數據、內容審核等較容易整合并服務化。

現在回顧一下，這塊是很明顯需要進行業務中臺化，因為可以圍繞統一的一點接入多點分發的方式來支撐各端的業務，做好內容生態供給。在建設過程中這個中臺是需要拉通各種信息、標準化建設、帳戶、數據等一系列的打通，就是業務流、內容流、分發流、數據流、商業流的這些相近業務中臺化。

但是，結局為什么會做的比較偏向了呢？這個中臺化業務，最終不聲不響地逐步淡出了大家的視野，而沒有在內容生態這條線上形成有著強力壁壘的根據地。這又是為什么呢？

02 中臺的考核目標是什么

在當時冬天，某次內容生態業務會時老板問小班委一個問題：

“這塊業務是做內容生態、創作者的生態，但是咱們只有創作者、內容生產、內容審核、內容庫、內容的獎勵，沒有內容的出口，面向 C 端的出口都在其他的 BU。我們這個中臺業務該做怎么？我們的考核目標是什么？”

期間，對于這個問題，自己經過思考后認為的答案是（這段是整理來自我當時的回答筆記）。

企業在業務不同階段業務會瘋狂的擴張的，那在業務瘋狂擴張的過程中由于各個 BU 業務自我閉環，導致大廠內部存在著很多重復造輪子的工作。

怎么理解重復造輪子呢，就是獨立 BU 做了一款 APP A 、獨立 BU B 做了一款 APP B，這里面做了一個功能相似功能，但是這在功能在內部是的必要性沒有那么強，如果繼續搞存在著人力成本的浪費。這個時候我們會通過一個公共抽象出來的業務模塊去獨立處理。（ps 現在看來膚淺多了）結合內容生態這個業務來看，有幾個點想法分別是：

1. 這塊內容業務的根基與出發點定位的是中臺性質，是偏業務型的中臺建設

在內容的生態系中，從創作者、入住、生產、下發、端消費來看，這個業務的生態來講，中間內容生態是一層非常關鍵的業務平臺，內容生產、內容提供、內容投放、內容創作激勵、內容歸一化、內容數據反饋閉環。

只要是涉及到信息流類的 APP 端或嵌入頁面、都會涉內容這塊，這些各個端的信息流的來源都是基于自己的業務平臺的建立，很多業務的組成形式也是通過不同的業務平臺進行串聯的，在業務平臺中包含了?創造者引入、管理、審核、機器識別、內容質量、內容層次化管理、優質內容管理、內容標簽豐富度、資金與分潤等更多的基礎平臺來做管理。

這些都是內容生態的基礎功能，通過對于平臺的這些基礎功能再加上較為復雜的抽象業務和業務邏輯來進行控制的，這些都是在業務內做了較為深層次的固化，從集團角度來看形成了煙筒式的建設。每一個煙筒的能力直接決定了業務的發展速度與業務創新的成本，業務的快速更新與創新需要一個像樂高一樣的體系去快速搭建。

比如我是一個廚子我要做披薩，全程我可以自己做，但是非常麻煩，我有三個方案：

• 方案一，別人提供廚房、爐子、煤氣，我使用這些基礎設施，用自己的披薩皮來烤披薩。
• 方案二，有人提供披薩餅皮，只要把自己的配料灑在餅皮上，讓別人幫忙烤出來就行了。也就是說，我要做的就是設計披薩的味道（海鮮披薩或者雞肉披薩），別人提供平臺服務，讓我把自己的設計實現。
• 方案三，別人直接做好了披薩，不用我自己的介入，到手的就是一個成品。我只需要做的就是把它賣出去，最多再包裝一下，印上自己的 Logo。

這個烤批薩隨著生態的復雜度、業務的復雜度、系統復雜度的升級，平臺化解決了技術平臺的問題，每個單元業務的執行都要跨多個領域來完成。

比如說淘寶的寶貝，商品發布規則、交易規則、營銷規則散落在各個系統，進行一個動作時沒有一個人能說清楚全局，做一個需求結果要評估 1 個月，開發幾天、測試幾天，效率太低，這已經不是一個流程能夠解決的，是一個比較復雜的生態協作問題。

2. 作為業務中臺承擔的 KPI 是什么？

一個業務型中臺如何考核呢？考核指標該如何定義呢？

• 從衡量這個生態該如何定義指標呢？比如從規模角度、品質角度、活躍、消費、互動、收益在這六個維度定義十幾個指標嗎？
• 從月日均活躍賬戶數量、月日均賬戶生產文章數量，再加上賬號內容在端的月日均播放量以及閱讀量，賬號內容在端的月日均播放量以及閱讀量超過十萬的內容數量 ?

無論從那個角度看來，都略感不太合適，這些指標都受到端的影響，沒有一個是完全因為這個中臺業務能完全起到作用的指標。

比如有的人提到既然是圍繞創作者的生態，那就只看創作者、內容生產就好了。

但是呢，每一塊都是要成本，生產出來的內容下發有問題，在不同端消費很差，或許是引出的供需不匹配的問題，因為這個供需不匹配到底是算法的問題還是內容質量問題、還是標簽的問題、還是在下發側的 C 端畫像刻畫問題，這是一個鏈條的問題，因為都同屬于業務都要承擔 KPI，自然這個 KPI 將會打架。

3. 中臺拉通各種標準各大金主業務線是否認這個玩意，也就是說這個業務板塊如何有話語權，還是做背后的默默無聞的奉獻者

獎勵與成本的問題，當以前各端的創作者獎勵機制相當于成本部分，因為都歸到了中臺來承擔了，從財務角度只看到了成本，那收益利潤該如何算呢？創造出來的直接經濟價值是什么？因為出口在各端，不同端的信息流中商業化收入會算到各各自端的業務側，在內容商業這塊探索了一些但沒有想象中那么好。

“大中臺”的概念就是從較為復雜的協作生態上來縱向的從服務的鏈路來做資源整合，技術中臺是重于能力沉淀與整合，業務中臺是注重鏈路、效率、成本、流程的優化。業務中臺在我的眼里變成了規則引擎執行者與可定制化能力服務輸出方，規則的輸出是通過數據的控制來做進行。

從內容生態來看在子公司、放眼集團，個人認為是一個很好的切入點，集團是某體系的巨無霸，在內容生態這塊一般，是需要一個具有支撐內容生態的一個業務中臺來支撐的。

所以在自己眼里這個內容生態中臺：

• 內容生產與管理的組合、也是內容生態一堆規則的執行者，這些能力是面向組件化的設計與面向點的集成。
• 是一個集成化的解決方案，有平臺、數據、接口規范、系統規范，包含解決信息呈現，快速匹配，解決供需撮合機制。
• 也是業務支撐、能力應用、能力運營、能力管理、協調能力、配置管理的體現。
• 其余的剩下的應該就是與各個業務團隊進行共建的了。

回到烤披薩的這個小案例，從簡單的烤批薩到中臺級烤批薩，會忽略一個很重要的因素，那就是隨著烤批薩生態的復雜度、烤披薩上下游產業的復雜度、工藝復雜度不斷的提升，自己的流程、工藝、邊界都在發生變化，隨設時間的沉淀，中臺的建設也會要逐步的去迎合與能夠快速去支撐這些變化，否則中臺的建設將會影響到未來業務的變化。

當時剛接觸這塊業務也是特別喜歡，從本質上說將會建立成為一個非常好的內容業務型中臺，對于內容創作者來講，一點接入多點分發，在這個偏業務型中臺的體系建設上也是用了一些蠻有意思的方法, 而且這塊業務是數據體系的強力支撐、對與在生態的內的供求平衡、偏移平衡分析、時間序列供求與變遷份都是很好的參照物。

03 緩慢的中臺建設與快速變化的業務需求

偏業務型中臺在建設中是有自己的難題的，首先要服務好下游的內部業務方，其次要完成對自己中臺的所服務的外部業務對象的支撐、最后還需要完成自身的建設。

這個中臺是要將原有分在不同端的內容生態這塊的業務邏輯重構，并整合類似的業務模塊。

自身建設含有產品建設、內部運營工具建設，對用戶的運營工具建設，在這個資源是有限的情況下，如何能做到這幾個方向的平衡呢？

業務中臺所服務業務與對象來講分別有幾個角色，分別是完成對端的的業務支撐、完成對于自身創作者與內容的支撐、完成自身建設，分別展開來講一下：

1. 端的業務支撐

需要服務好各個內容信息流下發端，比如一個集團內不同業務線的各種含有信息流、內容頻道的 APP ，在這里大概只列舉幾條：

• 各端對于這個中臺的需求分為幾方面，適合自己端的高質量、豐富度的可下發內容庫，以及、符合自己端內容消費的創作者引入以及從端上來的內容審核效率等，消費數據；
• 能夠承接住端訴求的對應的產品體系；
• 適合短的內容采購等一系列的問題；
• 端自己去做各種垂直品類的差異化運營所需的內容；
• 不同端對于創作者的星級評價；
• 商業化統一結算。

每一塊的內容都會影響到端的下發以及端 APP 本身指標以及內容消費指標。如果沒有這些內容出口端，內容中到底做什么呢， 所以有句話必須得服務好?。?！

2. 服務好用戶

這個內容中臺的特點之一需要完成自身的業務建設， 那個業務對象是誰呢？可以說是一個 To 內容創作者的一個業務。

把內容創作引入進來后需要從業務自身角度去維持這個賬號的可持續創作能力，優質內容創作能力，不管是從產品角度提供 創作輔導、創作工具賦能、數據工具分析，還是從運營手段的獎勵機制、激勵機制、分潤機制都是唯一的目的讓這個創作者活著。

具體來講從產品角度會有：

• 比如內容覆蓋、賬號拓展；
• 入駐體驗、信息合規；
• 內容同步工具、生產工具、促產工具；
• 內容分發分析、收益結算等；
• 商業化統一結算。

從自身業務的賬戶角度、內容角度分別又是兩部分內容：

• 帳戶級別：賬號信息結構化與歸一化，質量、品類、試運營、賬號體系、星級評價體系、管控方面等。
• 內容級別：內容識別、價值認定、管控等方面。

如果在從運營角度分類還有：

• 賬號的分層運營、頭部賬號的差異化運營、優質與高潛賬號挖掘；
• 激勵體制、收益策略等；
• 活動與培訓體系；
• 社區等。

如果分解得更完全還會有很多內容與工作去做：

自身建設：

除了上述產品的一堆內容外，還有標準化、組件化的建設，支撐內部運營的工具建設，分別可以從內容引入、內容管理、內容消費、以及數據體系建設分別去細化。

以上這些方向如果按照中臺的角度來做拆解，還是需要一定節奏去建設與實施的。否則“產研運”再牛，也不能短時間內建設好一套支撐各業務方的業務中臺來。。

中臺的建設節奏是最要命的，有一個矛盾點——業務線在發展中是快速變化的，快速變化必然就會有需要強烈渴望得到各種資源支持，但是中臺在建設大部分是在緩慢建設與推進，兩者之間會產生訴求與承接能力的不匹配問題。對于現有業務進行中臺化的過程中這塊如何做好平衡是必須的，就涉及到不同問題先做什么，后做什么。

寫到這里偶爾提一下，現在市面上對于中臺的所有文章千變一律的都是在講中臺的概念，講中臺藍圖，有沒有經過是實踐驗證呢？如果按照那些去實施成功的概率到底有多大？ 每一步該怎么走。

04 失敗的原因

資源問題我相信是所有管理層最關心的問題了。在這個項目中，包含了七十左右的產研、六十多位運營、幾十位數據人員、四十多位采購 BD，以及大概幾百人的審核團隊。如果算上流動，前后大概有好幾百人。

“業務中臺”項目被拆之后，產品轉崗了，大部分運營被協解（只留了小部分運營）， 但保留了較為完整的數據團隊。因為數據業務的獨特性適合中臺化，且是“主動建設”，所以一直跑在業務前面，并強化了核心資產、應用模式、核心業務模型和縱向場景。但我們這個切入點很好的業務單元，經過很多人的努力，結局卻是說撤就被撤了，非常值得回味…

回顧那一年的外部大環境，在內容這個領域很多公司是快速崛起與布局，為什么當時的這個中臺會在一形式大好的情況下，失去了這個陣地呢。在規劃中要進行中臺化的關鍵要素團隊都拆解到了，為什么還會黯然失色了呢？

前面我們從矛盾論的角度、因果角度、建設角度，對這個業務做了不同角度復盤。在今天，總結來看還有幾方面：

• 數據團隊需要在幾個業務團隊中尋找一個平衡點。
• 人的因素，想法太多，都想驅動這個中臺。
• 人員能力問題，做中臺的難度與做普通產品相比，有量級的差異。能力不足，真的搬不動這塊石頭，還砸了所有人的腳。
• 中臺建設是一種思考方式，但是在過程因為各有所需，變成了腳痛醫腳、頭痛醫頭的傳統估計的一條線到頭的建設，多條線交織成一個復雜網狀比較難以拆解的問題（表象看是一個資源問題），具體中臺達成什么樣子，承擔哪些沉淀， 還是要慢慢迭代的。
• 流程的問題，太多過長。
• 其它。

05 為什么保留了數據團隊

為了碼字而寫的一段，有人問我為什么數據團隊是基本保留了下來，總結下來有這么幾點：

• 獨特特性就適合中臺化；
• 主動建設、跑在業務前面，盤與梳并行，強化核心資產，沉淀應用模式、核心業務模型和縱向深化場景；
• 數據團隊需要在幾個業務團隊中尋找一個平衡點。

展開詳細講一下：

在數據的建設階段除了考慮基礎的要整合原有不同端的數據外，還在中臺業務還沒有摸清自己打法時要主動一些，帶著個責任“讓業務看的更加清晰”去做的，在短時間內快速的去建立衡量業務的全鏈路的關鍵指標漏斗體系外，還需要做異動分析，全局 ROI 、局部 ROI 、類 ROI 還有動態 ROI 都是要去主動建設。

在數據體系建設上，我們需要思考整合不同端外，還需要按照分析的主題域去做整合。 但是還必須站在中臺角度去思考我數據該如何平躺能夠提供中臺能力的服務，還有建設進度如何。

比如在數據標準上從整合角度、管理角度、消費角度如何做到閉環，分別從數據安全、數據標準上做了什么，從策略角度的制定、推進、信息暢通，從接入標準、開發標準上也做了大量工作。

在數據對業務的模型抽象上，從分析的角度供求關系角度抽取了大量的高階模型與可落地的分析模型。

• 偏流量方面的分析模型，一堆指標如何關聯行程一個可視化的分析圖，每一實體中有哪些分析要素，
• 內容創作的這個復雜分析模型。
• 在內容創作與信息流商業化分析模型。

拿著這些模型，一個業務、分析比較很清晰的就能看到自己看什么、上下游該研究誰，該如何分析。

比如從數據指標與分析角度快速去建立關鍵指標到拆解分析指標的體系，比如下面樣例，周活做拆解，會拆解為周發文不同頻次的監控。

數據團隊需要在幾個業務團隊中尋找一個平衡點。

當然了，我自身還是 BI 與數據產品領域，那段時間的做業務與數據價值積累，也讓自己在內容生態與信息流這個業務領域變的很熟悉，學會了很多有意思分析思維。

06 小結

一個業務型中臺尤其是背著考核指標的中臺該如何去建設，節奏是什么、中臺的幾個顯著特性優先建設哪一個呢都是需要待考慮的問題，而且最難解決的一點就是關于對中臺的認知問題、人的因素問題、流程因素、問題都是需要去重點思考的，當然了還有一點該選擇什么關鍵指標最為考核指標與觀察指標都是勢在必行的。

相關閱讀

鬼話連篇數據中臺（一）：透過中臺看數據中臺

作者：松子（李博源），自由撰稿人，數據產品 & BI 資深總監。2000 年開始數據領域，互聯網數據考古工作者一枚，經歷了互聯網古生代、中生代、今生代。作者公眾號：songzi2016。

本文由 @松子 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Pexels，基于 CC0 協議