不要把中臺當后臺，會消化不良，還容易得罪人

導語：在上一篇數據中臺的實戰文章《數據中臺實戰：以圓猿買手為案例談如何從0到1搭建實時標簽引擎》中，作者為我們講了如何打造一個實時的標簽平臺，這篇文章，作者分享了做中臺項目時的失敗案例以及怎么避免中臺項目失敗。

一、先看一個中臺經典的失敗案例

當阿里巴巴在2009年完成了分布式架構的改造后，淘寶平臺整體能力得到了質的提升。此時卻面臨了新的挑戰和問題，隨著淘寶商家交易量的爆發式增長以及越來越多大型的零售快消行業入駐淘寶和天貓，原有平臺所提供的商品管理、庫存管理等功能顯得捉襟見肘，大大影響了商家的運營效率。

這些幾百萬的商家從某種程度對于淘寶和天貓來說是衣食父母，沒有這些商家在淘寶和天貓上開店，也就沒有了電商平臺存在的價值，所以面對這些商家的訴求，淘寶團隊第一時間就調集了當時在ERP、CRM業界最為專業的團隊，開發了一套針對淘寶和天貓上商家提供統一CRM服務的平臺，以提升商家對于商品、庫存、促銷、物流各方面的運營能力。

經過近百人、幾個月的浴血奮戰，淘寶統一CRM平臺很快推出上線，商家使用CRM的服務所需的服務費用也非常低廉，甚至對于一些商家是提供免費服務。當大家都以為這樣將大大提升商家的開店體驗，商家對淘寶平臺的滿意度會顯著提升時，結果卻讓人大跌眼鏡，大部分商家對于淘寶建設的統一CRM平臺怨聲載道，淘寶團隊在一段時間內對CRM平臺進行了全力優化和改進，但還是沒有改變CRM平臺最終下線的結局。

究其原因，我認為本質上是統一CRM平臺建設前，對于所服務客戶的需求并沒有清晰的認識，在當時淘寶近200萬商家中，有來自家電、服務、數碼、生鮮、玩具等上百個不同行業；有像雙11那天一天交易金額超10億的大型商家，也有一年交易額可能幾千塊的商家；這些客戶存在的差異導致對于CRM平臺的需求差別是巨大的，所以寄希望用一套統一的平臺解決需求差異這么大的用戶群體，最終的結果一定是所有人都不滿意。

在項目失敗后，淘寶團隊對項目進行了復盤，總結和定位出失敗的原因，痛定思痛之后，開始了淘寶開放平臺的建設。淘寶開放平臺是將淘寶和天貓上商家后臺數據開放給商家授權的技術團隊，基于商家后臺系統開放的權限能實現商家針對商品、庫存、訂單、物流和客服等個性化的業務流程。

商家自身的開發團隊或者第三方的開發商基于淘寶所開放的商家數據，經過定制和擴展后，實現了商家各自不用的需求，從而根本上提升了一直困擾商家很長時間的運營效率問題。

二、做中臺，千萬不總要想著蛇吞象，很容易消化不良

幾年前做數據中臺項目時也犯過同樣的錯誤，當時運營團隊要定期給某個排行榜前十的用戶發優惠券，以刺激他們復購。由于排行榜規則比較復雜，業務線產品研發團隊很難搞定，需要數據中臺團隊提供排行榜數據。因為是周期性的發券任務，此時業務團隊提出要做一個排行榜用戶展示及數據導出的功能。

當時屬于數據中臺項目初期，數據中臺就連一個可視化的組件都沒有，這個排行榜做起來還是有一定的工作量，我們團隊就十分糾結排行榜展示及導出的功能該由誰來做。當時業務產品研發團隊是不想做這個事的，因為他們覺得既然那么復雜的排行榜的數據是由你計算的，那開發一個展示及導出的功能，豈不是非常簡單？就想推給我們來做這個事。

當時我們的團隊也是這么想，既然這么復雜的排行榜算法我們就搞定了，如果把數據拱手讓人，交給其他團隊，那我們數據中臺的價值怎么體現呢？最后在這種想法的驅動下，數據中臺還是硬著頭皮把這件事給做了。

不過現在想想這件事是犯了一個中臺團隊極其典型的錯誤：

把自己當后臺，什么都想做。中臺是什么？中臺就是中心化的能力復用平臺，無論業務中臺還是數據中臺提供的都是底層的通用的能力。

上面排行榜案例中其實犯了很大的錯誤，作為數據中臺，你要非常清晰哪些應該你來做，哪些應該業務團隊來做。那個排行榜的功能，數據中臺要做的只應該是提供排行榜的數據接口給業務團隊，然后由業務團隊承擔展示及導出的功能。

現在由數據中臺團隊來做，就導致運營團隊每當做這個活動，一邊要登錄數據中臺來取數，一邊要登錄業務系統來配置優惠券活動，業務團隊做活動時還是更習慣用業務系統，這樣不是浪費他們的時間嗎？另外數據中臺做的這個針對這個業務線的排行榜功能，真的能夠復用給其他的業務團隊使用嗎？其實很難。

當時經過反思，為了不犯同樣的錯誤，給團隊定下了幾個規則：

• 數據要開發的功能能不能節省業務團隊2個小時以上的時間？（保證數據中臺研發的功能能提高業務團隊的效率）
• 數據中臺要開發的相關指標能不能直接反饋公司的問題或者幫助公司增長？（確保數據中臺開發的數據指標對公司有價值）
• 數據中臺開發的功能未來能否開放給商家使用？（做為一個電商平臺，針對業務人員開發的功能要能夠復用給商家，保證數據中臺的復用性）

阿里做CRM的項目也是犯了同樣的錯誤，不把自己當中臺，把自己當后臺，想通過一個幾百人的團隊搞定200萬商家的所有需求，簡直是癡心妄想。

阿里引入的新的角色第三方開發商，簡直是神來一筆，由原來自己的幾百人的團隊，變成與幾千甚至幾萬人的第三方開發商合作共同服務200萬的商家，這樣就能保證大部分的商家需求能得到滿足。

我這里提到一個了一個關鍵詞“合作”，對于中臺團隊，合作能力及其重要，合作能力決定一個人的上限，也決定一個團隊的上限。

中臺是站在公司全局的角度去搭建系統的，就必定觸碰到公司下面某些部門的利益。我做業務中臺項目經常被問，這個功能憑什么要交給你來開發，我自己做不是更快嗎？做數據中臺項目遇到的最大問題也是，我的數據為什么要給你？

怎么解決這一系列的問題？

其實都是合作的問題，做中臺，你不僅要向業務線團隊推你的中臺系統，還要向業務線團隊推公司為什么要搭中臺，中臺怎么幫你們業務部門等等這些問題，給他們洗腦。

不但要洗腦還要真正的通過中臺幫助業務部門解決問題，這樣才能慢慢的與他們合作起來，他們才會越來越依賴中臺，否則你一根筋，自己什么都想干，到最后什么都干不好，還得罪一群人。

三、中臺項目成功案例：推薦系統

當時公司電商平臺發展到一定階段要引入推薦系統，推薦系統最核心的其實還是算法，應該由數據中臺團隊主導，但數據團隊的強項是做算法，業務線產品、運營團隊對業務流和數據流更加了解。

當時我們遇到一個情況是，業務線產品技術團隊已經開發了一個輕量的推薦系統，已經在試行。這個問題就比較難搞了，我們是推翻業務線產品、技術團隊搭的推薦系統重新來做呢？（因為他們搭的推薦系統是針對自己的業務來設計，通用性不強）還是在他們的基礎上去做呢？如果推翻他們好不容易搭的推薦系統重新去做，業務線的產品、運營團隊肯定是不樂意的，這種感覺就好像他們正在打牌，突然來了個數據中臺掀翻了他們的桌子，擱誰誰都生氣。

當時我們梳理了他們現有的系統，發現他們做的推薦系統，一部分功能是可以復用的，比如說用戶行為（訪問、瀏覽、加購、下單）權重的設置，這些功能我們采用同步數據的方式來讀取運營人員設置的權重，這樣一方面保證了業務產品技術團隊開發的功能不被浪費，另外一方面可以讓運營人員參與進來，由他們設置初期的用戶行為權重，這樣做，他們是有參與感的。

但是他們做的算法模塊是真的不行，太個性化，沒辦法通用。推薦系統是需要按照召回、排序、過濾的標準流程分大塊，來設計系統的，這樣才能保證推薦系統后面能復用給其他業務團隊，所以算法這塊，我們決定推倒重來，由數據中臺算法團隊主導，當時還給業務線產品運營 團隊做了培訓，講清楚為什么要這么做。

另外只有干巴巴的算法是不行的，還需要業務線產品、運營團隊的配合。業務線的產品技術團隊幫助梳理了核心的業務流和數據流以及補充了新版推薦需要的數據埋點。業務線的運營團隊更加了解業務，比如做為一家快時尚電商平臺，針對新款的權重應該更高、什么時候是用戶的訪問高峰期（決定計算時間）、高退款率的商家該怎么處理等等，把這些因素都考慮進去加入了算法。

最最要的是數據中臺團隊和業務線產品、運營團隊，當時定了一個目標：選擇了幾個平行的坑位中的一個當推薦坑位，這個推薦坑位的轉化率（訪問/支付）至少要和由人工組貨的平行坑位持平。最終我們一起合作做了3個大的版本，半年的時間做到推薦坑位的轉化率是人工組貨平行坑位的2-3倍。

這算是一個中臺團隊和其他部門合作做的一個非常典型，從結果來看效果還算不錯的案例。為什么最后的效果還不錯，就是因為各個團隊合作的很好，各自發揮自己的優勢，大家參與感都很強，都覺得自己是有價值的，發揮出了1+1大于2的效果。

四、最后總結兩句話

做中臺，千萬不要把自己當成了后臺，總想著蛇吞象，什么都做，這樣很容易消化不良，還容易得罪人。

做中臺，與其他部門的合作能力極其重要，合作能力也決定中臺團隊的上限，有時候該當孫子就當孫子，該當爺的時候也盡量要憋著，畢竟完成目標才最重要嘛。

#專欄作家#

Wilton董超華，微信公眾號：改變世界的產品經理，人人都是產品經理專欄作家。暢銷書《數據中臺實戰》作者，曾任職科大訊飛，現任富力環球商品貿易港數據中臺產品負責人。主要分享商業、產品、運營、數據中臺相關原創文章。

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

題圖來自 Unsplash，基于 CC0 協議