起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識鬼話連篇數據中臺（一）：透過中臺看數據中臺
如何想方設法持續提高企業對?戶的響應?才是建設背后最核心的邏輯，更好服務前臺規?；瘎撔?，進而更好響應服務，不管是中臺還是平臺能夠有顯著成效就好。
不管是傳統企業還是互聯網企業，因為企業的發展速度、形態與數據量等都不同，在開始進行中臺轉型時會從不同的接入開始切入。
關于數據中臺的對話：
場景一：
發生在上周周末，與一個公司的老板對話。
老板開門見山提了一個問題：“想問一個問題， 我想搞一個數據中臺?！?/p>
我驚了一下問到：“啥？搞數據中臺？沒燒壞吧？”
“那想搞這個這個數據中臺的目的是啥？是要支撐業務，還是在融資上搞啥？”
“現在這個中臺很火啊，我們也想搞一下。搞個數據中臺、再搞個運營中臺，未來面向xxx這個群體，就是一個 SaaS。”
“你真有錢，其它中臺不好說。但是數據中臺我認為就公司目前的這個業務情況，還在初級階段，業務一直在快速奔跑，組織結構還沒成為業務發展的瓶頸。
另外，從中臺的難度上來講，在產品、架構規劃等方面強調的是服務、組件化、業務抽象等方面，其天然的起點已經比普通業務形態與產品有數量級的差異。
業務的快速頻繁變化，如何讓中臺來做沉淀？當心中臺的不完善拖累業務，搬不動這塊鐵，把自己砸暈了。
個人建議，拋開所有概念，就圍繞自己要解決的問題，解析出適合自己的商業模型到分析模型，再圍繞分析模型來看如何做埋點與數據拼圖，用數倉的方式，數據平臺的實施來做支撐。”
老板： “那你幫我出一個方案吧?！?/p>
“我#￥%……&*（）——”
場景二：
發生在一個數據群。
一個同學問：“什么是中臺，什么是數據中臺呢，我看的一臉懵逼?！?/p>
“我們公司要招中臺產品經理了，都是來干嘛的呢？”
“我看了很多材料，還是沒懂啥叫中臺，最近有個公司出了一本數據中臺的書，買來再看看?！?/p>
然后呢，再過幾天，在不同的群不同的場合，類似的很多關于數據中臺的對話將繼續神話般勾兌著。
中臺的建設是一個復雜的系統工程，正如某大神說的“中臺的建設要想比較成熟且有體系至少要三年以上時間，是要分階段去實施的”。
中臺的實施在現階段只能是摸索、實踐，因為大家對中臺的理解是根據所處的當下環境與狀態而進行思考的。
現在，中臺的實施將會在做事的方式、思維的高度、系統框架方面有所改變。但是，實際上很多打著“中臺”這個詞，在按照技術組件、技術產品或一個技術平臺的的方式在實施，只是“被”成為了中臺。
總結自己2019年半年職業生涯，中旬離開一家“大航母”后，這半年也是在跟中臺打交道，并且到現在也是在嘗試去推動一個數據中臺化。其中遇到了各種有意思的問題，期間花了漫長時間來盤點問題并嘗試尋找一種適合的演進方案。
那我能在這里做點什么呢？
一般一上來就喊中臺化的基本入不敷出，不是人員投入問題、就是實施方向以及定位到底是什么。
但是，有的企業用演進的辦法來做實施是個非常不錯的選擇。
那成功與失敗的關鍵要素是什么呢？是認知的因素？還是人的因素？還是組織因素？還是期望與落差的因素？標準的中臺是什么樣子？
我們如何衡量是在做中臺而不是在做平臺？做中臺從具體事情層面來講，有哪些維度？該如何落地？
現在中臺的書已經有好幾本，網上的各種文章有很多，或多或少都有在回答“中臺”的相關問題，我在后面的篇章也會逐漸展開講我所理解的這些問題。
伴隨著業務的多元化發展，公司各部門紛紛建設各自的業務系統，在產生大量的系統、功能與應用重復建設的同時，也導致了系統之間的數據處于未能及時打通的割裂狀態。大量的數據被阻斷在了不同的系統中，就像一個又一個的‘堰塞湖’，可能滿足了單一的業務場景，卻阻塞了企業數據資產的全鏈路管理，使得企業數據難以被全局規劃與定義，這就是數據中臺應運而生的源動力。
首先，數據中臺是根據企業的實際情況所打造的數據產品與實施方案的結合物，它可以融合企業內外數據，打破數據隔閡，解決企業面臨的數據孤島、數據標準不一致等問題。其次，又是一種戰略選擇與運營解決方案，是一套行之有效的數據運營機制。
這段話是來自一篇科普文章，在行家的眼里看會怎么樣呢？
我特別想問問這個作者，企業級數據集成、數據倉庫、數據平臺的定位什么。
透過數據中臺看數據平臺
我在寫這個小標題的時候，內心是糾結的，一直在想如何系統化說明數據中臺、數據平臺的的相似性與區別呢？
我總結了一些維度，比如復用性、資源整合、能力沉淀，按照業務橫向相關聯，把數據做深度整合并最終沉淀為公共的數據服務能力等。
但是，我發現每一篇文章，每一個定義都是非常隨性，沒有本質上顯著的區別，難道在平臺的實施中直接換個詞就能成為數據中臺？
開始老板給了非常高期望，希望花一年時間投入三五十個研發、十幾個數據產品經理就能完成中臺的建設？到頭來不斷降低的預期、難以忍受的產出與不成正比的投入，最終會怎么樣呢？
能力沉淀，這個相對來稍廣泛一點、數據的接入能力、計算能力、存儲能力、業務支撐能力、展現能力都算在能力沉淀中，只有想不到沒有做不到。
一般的平臺化是因為業務需求繁多、響應及時要求高，需要平臺，因為企業的業務發展也是成生物生態的特點。平臺化也是需要降低成本、提升效率，并快速支撐與響應業務，但是平臺的邊界非常清晰與管理很規范。
比如，在實施平臺后，可以實現柔性的支撐業務，能解放技術同學并發精力，投入到穩定行、高性能、技術改造等一系列的其它重要事情上；并能提高人效，降低公司成本。
比如，平臺化后對業務分治與歸口的管理，業務邊界變得更加清晰，歸口管理使得各團隊對自己業務管理更規范與高效，避免了一件事情找半天沒人理，需要更多的PMO與建立更多的流程與規章制度保障工作。讀到這里是不是有些讀者已經意識到什么了，后續再展開講。
總之，平臺化是在業務層面、功能層面、接口層面、應用層面去做具體的落地。
回歸數據體系建設，企業的一個營銷方案可能需要幾個禮拜到幾個月，是企業為中心，生產為向導的模式。但是，現在變為市場為中心，又再變為客戶 & 用戶為向導的持續規模化。
企業的業務響應能力和規?；膭撔履芰Γ菂^別于傳統企業與互聯網企業的綜合能力的。企業擁抱這樣的變化就意味著業務必須逐步完全信息化，對客戶的觸達方式也極具的縮短，中間所有的數據記錄模式也發生信息化的變化。
業務數據結構變化，由傳統企業的單純文本，結構化數據轉為非結構化的聲音、視頻、日志、定位信息等。所以，需要數據處理的技術架構、產品架構、甚至相關的組織結構也是不同。
在這種平臺結構下構建起來的數據平臺，是企業數據體系建設的基礎， 搜集好的數據需要產生價值。數據的搜集、存儲、顯示、產生價值是一個鏈路，相輔相成的。一個公司如何想實施好一個數據體系，是需要從數據、產品、工具、技術、應用等多個角度，來共同實施與落地才能完全做好的。
數據平臺這個詞本身含有平臺，平臺這個詞內部的含義已經包含組件化、服務化、系統化。建設數據的主要目的就是屏蔽數據異構性、構建統一的數據源，這個不管是在數倉、還是在數據平臺都是必須要做的基本任務之一。
與大家一起拆解2個內容：
平臺中的關于組件、服務與系統化：數據域的建設分為內容建設、工具建設與內容價值探索，其中工具體系化建設是數據平臺的基石，內容透過工具把價值提現出來，工具如何構建與聯合將會將會發揮出不同的價值來。
例如，以前我們的ETL過程、數據工具、調度工具、元數據工具、指標字典、庫表字典、數據質量等一系列工具是一個個的工具產品，每一個工具產品解決的是特定領域的問題。
比如，指標字典是解決公司離線級別指標管理與指標口徑管理問題，或者是可以增加在線指標的配置管理。庫表字典，有的公司如果是數倉主導可能就是給自己服務，里面就是針對數倉的表做查詢；如果把業務系統庫表整合進來，那就是面向其它技術群體等一款小的服務產品。
有人說，這個屬于元數據的范疇，我把一個數據地圖做扎實做透了，把庫表字典、指標字典里面的所有元數據通過有機的關系整合起來查詢多好，并且可以提供對外的查詢服務；或者是在某個流程中，比如ETL的過程、調度的過程隨時隨地可以查詢相關的信息與影響多好。
舉的這個例子中，單個工具與單個工具耦合性很差，缺少相互聯合作用的功能?，F在，有不少公司在做產品時往往都是一個個的工具獨立的存在，說是成為一個平臺，但是更多的僅是個工具。從架構與定位上來看，僅僅是打通一些點，無法聯合起來形成一個工具體系提供豐富的不同場景應用。
這個小案例就思考到了組件化、服務化這幾方面，來做規劃與設計。
關于統一，不管是在工具建設、內容建設中不可避免的要去面對多個業務線、多個業務系統來做數據等整合，可能會涉及不同的內容需要“歸一化”、“統一”。
我們要統一的建模、統一的開發、建立統一的標準，所謂的統一就是做數據必須要去完成的一個使命。
數據倉庫本身具備的一個責任之一就是數據整合，屏蔽數據的異構性，完成對不同術語的統一。如果拿到中臺的這個ID統一，本質上只不過是數據倉庫、數據平臺本身所必須的職責之一。
下圖是比較久遠的一個數據項目的目標，感覺與現在有多大的差異性？
但服務的范圍不同了，就像APP日志采集一樣，埋點統一也是流量必須要做的事情。
（圖例是在 12 年前一個項目中項目模塊介紹）
強大數據中臺是每個企業的夢想
每個企業都夢想要一個非常強大數據平臺或中臺，對企業內部提升運營效率、決策效率、在線精準，對外支撐各種場景應用。
從實施角度、管理、面對客戶上總結為：
- 在實施上，想把數據來龍去脈梳理特別清楚，把數據加工、存儲、分析、建模等與數據有有關的所有事情都可以輕松的解決。
- 在管理上，想有一個可以管理一切的入口，把一切的數據、口徑、項目、工程等都管理起來。
- 面對客戶，想讓客戶可以一站式在這個平臺上獲取到任何想要的東西，并可以獲取到足夠的數據應用能力。
為了這個愿望，大部分的數據人朝著這個終極目標去努力，但是到頭卻發現，這個泥潭越陷越深。大家都在泥潭中不停掙扎，需要面對天天變化的業務與嚴重不規范的數據結構、確定什么樣的數據源，數據的含義是什么，數據的上下文是什么。數據質量令人頭痛，還面臨業務數據中元數據的丟失、業務文檔基本沒有，問了一圈還沒人知道等各方面的問題。
個人相信，以上提出來的這些問題，不管是數據倉庫、數據平臺、數據中臺都是要幫助企業達到這些目的的手段，而不是目標的本身。以用戶為中心的持續規?；瘎撔拢菙祿w系建設的核心目標。
企業有成千上萬，不同企業發展不同階段，對于上數據建設的意愿度與驅動力也是不同的。有的企業還在準備上馬數據倉庫，有的已經建立自己比較完善的數據平臺，而大廠、準大廠已經數據中臺化，也或是走在中臺化的路上。
當還在為在實施數據倉庫、一套BI的時候，當還在努力為了數據平臺而在投入資源實施時，風起了數據中臺。不管三七二十一，搶先發布博人眼球甚是“高大上”全套解決新概念。
隨著阿里的中臺戰略對外宣傳與更加的火熱起來，到現在各種培訓都來了，如“中臺產品經理”、“實施中臺戰略”、“如何實施中臺”，甚至在一些數據產品經理群里還會有招聘數據中臺產品經理。
相信每位老板、每位數據建設者在面對數據倉庫、數據平臺、數據中臺這個宏大的多概念混洗在一起時，會是怎么樣一種萬馬奔騰的心情。在實施的過程中到底使用什么方法論？倉庫、平臺、中臺到底有什么區別？
我們先回到企業上數據的基本上來，企業到底要一個什么樣的數據管理體系，到底要什么樣的功能？為了解決什么問題？需要根據什么原則去設計與實施？
筆者特別贊同一句話：“資源整合，降低成本，同時探索新的商業應收模式”。其中要求，不管是在平臺階段、數據中臺階段都是要必須去滿足。
在這個干中臺的不如講中臺的時期，希望不要繼續誤導企業上什么平臺。其實，中臺到底是什么并不重要，這只是一個概念。每個公司有每個公司的方法，如何想方設法持續提高企業對?戶的響應?才是建設背后最核心的邏輯，更好服務前臺規?；瘎撔拢M而更好響應服務，不管是中臺還是平臺能夠有顯著成效就好。
自己也看了很多，但是也沒把中臺這個概念想得特別清晰。其實不用糾結概念，還是那句話“中臺是什么并不重要，每家公司要找到適合自己的方案并推進落地”。
在上面開篇時提到了企業上數據需要解決的問題與面臨的困難，那該用什么方案去實施？現在數據這幾種方案有什么異同點？
一個企業構建一個數據平臺，是否已經標志著企業的數據應用能力就完全上一個新的臺階呢？或許不是絕對，與一些企業管理者溝通起來得到的信息就是成本太高，如何節省成本？
回顧為什么會提到這個問題，不管是傳統企業還是互聯網企業，因為企業的發展速度、形態與數據量等都不同，在開始進行中臺轉型時會從不同的接入開始切入。像接觸幾家家企業實施一樣，還是處在數據倉庫的時代，不停無限滿足業務的統計、看數需求，就要嘗試開始數據中臺轉型。
一個業務成熟、相似并行業務較多的企業、數據體系成熟的公司往中臺轉型將會是更簡單一點。在一些業務的單一模式，業務變化還非常迅速、不停試錯的時候，是在想不到有什么能力可以往中臺上去做沉淀，不如先搞平臺來做支撐。
在寫這個系列時，我的觀點是非常明確的：我不反對中臺這個概念，反而認為中臺是很有必要的，“隨著時間的沉淀，中臺會逐漸的沉淀出來”。
作者：松子（李博源），自由撰稿人，數據產品 & BI 資深總監。2000 年開始數據領域，互聯網數據考古工作者一枚，經歷了互聯網古生代、中生代、今生代。作者公眾號：songzi2016。
本文由 @松子 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
所以這篇文章到底寫了些啥 沒有一點干貨
公司不同階段會面臨不同的問題，阿里、貝殼等之所以強推中臺，是因為了破局，為了減少人員及系統的的冗余，最終目的是提升組織效率和靈活性。但他們的方式并不能適用所有公司，得看階段，得看業務現狀。
大多數中臺的建設都是以數據為破局點的，因為足夠小，可塑性和靈活性極高；打通數據之后再疊加業務能力，往業務中臺演進，而不是一上來就想著把業務能做的都抽象出來，這樣死的會很快。
請求轉載
這一塊不是家大業大的，基本上搞不起來。
繼續
這是個系列