Categories
程式開發

鬼話連篇數據中台(一):透過中台看數據中台


發生在某個週末的對話,與一個有了幾輪公司老闆對話。
他開門見山的提了一個問題:“想問一個問題, 我想搞一個數據中台。”
我驚了一下問到:“啥?搞數據中台?沒燒壞吧?”

“那想搞這個這個數據中台的目的是啥?是要支撐業務,還是在融資上搞啥?”
老闆:“現在這個中台很火啊,我們也想搞一下。搞個數據中台、再搞個運營中台,未來面向xxx這個群體,就是一個saas。”
我:“你真有錢,其它中台不好說,但是數據中台我認為就公司目前的這個業務情況,還在初級階段,業務一直在快速奔跑,組織結構還沒成為業務發展的瓶頸。另外從中台的難度上來講,在產品、架構規劃等方面強調的是服務、組件化、業務抽像等方面,其天然的起點已經比普通業務形態與產品有數量級的差異。業務的快速頻繁變化,如何讓中台來做沉澱?當心中台的不完善拖累業務,搬不動這塊鐵,把自己砸暈了。個人建議,拋開所有概念,就圍繞自己的要解決問題,解析出適合自己的商業模型到分析模型,在圍繞分析模型來看如何做埋點與數據拼圖,用數倉的方式,數據平台的實施來支撐好自己。”
老闆: “那你幫我出一個方案吧。”
“我#¥%……&*()——”

過幾天,類似的對話,還是持續著, 只是換了不同的人、不同的場景、不同的公司。讓自己陷入一個沉思,自己2019年中旬離開一家大航母后,到現在半年時間嘗試去推動一個數據中台化,其中遇到了各種有意思的問題,期間花了漫長時間來盤點問題並嘗試尋找一種適合的演進方案。

但是發現,一般的一上來就喊中台化的基本都是死的很慘, 用演進的辦法來做實施是個非常不錯的選擇

結合自己這幾個月在從對中台的實施中實際情況來看到以及遇到的問題,引出來了想把之前的對於數據中台的想法來做一個呈現與分享。

現在這個時代,一個企業沒有自己數據平&中台,或一個人不知道數據平台&中台等都有點不太好意思說出口,線下各種分享、線上各種視頻與文章,完全的充斥著數據平台/中台的建設成功的案例。

一個企業構建一個數據平台是否已經標誌著企業的數據應用能力就完全上一個新的台階呢?或許不是絕對,與一些企業管理者溝通起來得到的信息就是成本太高,如何節省成本。

從數據平台大的方向是沒問題,但是在具體的執行中因為細節的緣故會讓數據平台反復建設很多遍,來一波建設一波。

數據平台建設是企業數據體系建設的基礎, 蒐集好的數據需要產生價值。數據的蒐集、存儲、顯示、產生價值是一個鏈路,相輔相成的。一個公司如何想實施好一個數據體系,是需要從數據、產品、工具、技術、應用等多個角度,來共同實施與落地才能完全做好的。

非互聯網時代,企業的一個營銷方案可能需要幾個禮拜到幾個月,是企業為中心,生產為嚮導的模式,但是現在變為市場為中心,又再變為客戶&用戶為嚮導的持續規模化。企業的業務響應能力和規模化的創新能力,是區別於傳統企業與互聯網企業的綜合能力的。企業擁抱這樣的變化就意味著業務必須逐步完全信息化,對客戶的觸達方式也極具的縮短,中間所有的數據記錄模式也發生信息化的變化。

業務數據結構變化,由傳統企業的單純文本,結構化數據轉為非結構化的聲音、視頻、日誌、定位信息等。

企業有成千上萬,不同企業發展不同階段,對於上數據建設的意願度與驅動力也是不同,有的企業還在準備上馬數據倉庫,有的已經建立自己比較完善的數據平台, 而大廠、準大廠已經數據中台化,也或是走在中台化的路上。

相信每位老闆、每位數據建設者在面對數據倉庫、數據平台、數據中台這個宏大的多概念混洗在一起時,會是一種怎麼樣萬馬奔騰。在實施的過程中到底使用什麼方法論?倉庫、平台、中台到底有什麼區別?

當還在為在實施數據倉庫、一套BI的時候;結果有數據平台,當還在努力為了數據平台而在投入資源實施時,風起了數據中台。不管三七二十一,搶先發布博人眼球甚是“高大上“全套解決新概念,隨著阿里的中台戰略以及鄧中華的神一般的指導中台問世後,到現在各種培訓都來了,如“中台產品經理”、 “實施中台戰略”、 “如何實施中台” 。甚至在一些數據產品經理群裡還會有招聘數據中台產品經理。

與外界不同企業交流時我也被提問到了好多次: 如何要上數據中台的、該怎麼做、要不要上數據中台?什麼情況下上數據中台?數據中台與數據平台有啥區別?一年的時間能把數據中台實施完畢嗎?

在開始“鬼話數據中台”之前,我們先回到企業上數據的基本上來。企業到底要一個什麼樣的數據管理體系,到底要什麼樣的功能、為了解決什麼問題?需要根據什麼原則去設計與實施?

總結下來,公司嘗試在做一個非常強大數據平台,對企業內部提昇運營效率、決策效率、在線精準,對外支撐各種場景應用。

  • 在實施上,想把數據來龍去脈梳理特別清楚,把數據加工、存儲、分析、建模等與數據有有關的所有事情都可以輕鬆的解決。
  • 對於管理上,想有一個可以管理一切的入口,把一切的數據、口徑、項目、工程等都管理起來。
  • 面對的客戶上,想讓客戶可以一站式在這個平台上獲取到任何想要的東西,並可以獲取到足夠的數據應用能力。

為了這個願望,大部分的數據人朝著這個終極目標去努力,但是到頭卻發現,這是個泥潭越陷越深。大家都在泥潭中不停的掙扎,需要面對天天變化的業務與嚴重不規範的數據結構、確定什麼樣的數據源,數據的含義是什麼,數據的上下文是什麼。數據質量頭痛問題,還面臨業務數據中元數據的丟失、業務文檔基本沒有, 問了一圈還沒人知道等各方面的問題。

個人相信以上提出的來的這些問題,不管是數據倉庫、數據平台、數據中台都是要幫助企業達到這些目的的手段,而不是目標的本身,以用戶為中心的持續規模化創新,是數據體系建設的核心目標。

特別贊同一個句話“資源整合,降低成本,同時探索新的商業應收模式”,這個不管是在平台階段、數據中台階段都是要必須去滿足。

曾經看過一段話:“隨著企業為了適應需求端(市場和消費者)的變化,早期工具各自產生新的、孤立的、片面的客戶數據,卻無法快速同步,甚至團隊之間還懷疑對方數據是否正確。因此,企業急需調整和改革供應端(生產製造和供應鏈),也就是需要一個統一真實的數據源來描述客戶,而不是任由客戶的不同維度數據由不同部門各自存儲,於是在這樣的場景下數據中台應運而生。數據中台跟之前大數據平台最大的區別,在於數據中台距離業務更近,能更快速地響應業務和應用開發的需求,可追溯,更精準。” 如果把這段話中的數據中台替換到數據平台會怎麼樣呢?是不是有點換湯不換藥? !

在這個乾中台的不如講中台的時期,希望不要繼續誤導企業上什麼平台。其實中台到底是什麼並不重要,這只是一個概念。每個公司有每個公司的方法,如何想方設法持續提高企業對⽤戶的響應⼒才是建設背後最核心的邏輯,更好的服務前台規模化創新,進而更好的響應服務。不管是中台還是平台能夠去的顯著成效就好。

自己也看了很多,但是也沒把中台這個概念想的特別清晰。其實不用糾結概念,還是那句話:“中台是什麼並不重要,每家公司找到適合自己的方案並推進落地。”

在上面開篇時提到了企業上數據需要解決的問題與面臨的困難,那該用什麼方案去實施?現在數據這幾種方案有什麼異同點?

回顧為什麼會提到這個問題,不管是傳統企業還是互聯網企業,因為企業的發展速度、形態與數據量等都不同,在開始進行中台轉型時會從不同的接入開始切入。像接觸幾家家企業實施一樣,還是處在數據倉庫的時代,不停的無限滿足業務的統計、看數需求,就要嘗試開始數據中台轉型。一個業務成熟、相似並行業務較多的企業、數據體系成熟的公司往中台轉型將會是更簡單一點。在一些業務的單一模式,業務變化還非常迅速、不停的試錯的時候,是在想不到有什麼能力可以往中台上去做沉澱,不如先搞平台來做支撐。

在寫這個系列時,我的觀點是非常明確的:我不反對中台這個概念,反而認為中台是很有必要的,“隨著時間的沉澱,中台會逐漸的沉澱出來”。

在後面的章會繼續分享自己在實施中的一些方案、思考與碰壁。

作者簡介

松子(李博源),自由撰稿人,數據產品 & BI資深總監。 2000 年開始數據領域,互聯網數據考古工作者一枚,經歷了互聯網古生代、中生代、今生代。歡迎關注個人微信訂閱號:songzi2016。