資料團隊是如何演進的?
2004年進的公司,至今18年了,今天來聊聊自己所經歷的資料團隊的演進過程。
1、2004年 原始狀態
在剛進公司的時候,IT部門裡沒有專門的資料科室,只有一個開發科室,OLTP和OLAP混在一起,當時加上我一共3個人從事報表取數工作,每天大約1-2個取數單子,每月幾張報表開發任務,外加維護報表庫,那個時候,沒有合作伙伴。
2、2005年 經營分析室1.0
2005年公司還處於話務經營的時代,當時就啟動了第一代資料倉儲的建設,在IT部門下專門成立了經營分析室,自己是其中一員,記得共4個人吧,1人負責資料倉儲建設運營,1人負責KPI+報表開發,我負責取數,還有一位主管,由於資料倉儲和報表取數的工作越來越多,因此有了固定的合作伙伴團隊。
這種組織架構比較精煉,沒有什麼層級,溝通成本也很低,滿足了當時公司資料生產的基本要求。
3、2008年 經營分析室2.0
2008年公司進入流量經營時代,業務部門對於精確營銷提出了越來越多要求,經營分析室在原有資料倉儲、KPI、報表、取數的基礎上,陸續增加了專題應用、營銷管理平臺、標籤庫等工作內容,人員也增加到了8人,這種職能架構延續了6年。
4、2009年 資訊管理室
由於特殊的原因,當時管理資訊室(MSS)和經營分析室進行了短暫合併,改名成了資訊管理室,但兩個科室的人員還是各做各的,管理資訊室做資訊化,經營分析室則拼命做精確營銷,沒有什麼交匯點,但冥冥之中似有定數,現在MSS成了公司數字化轉型的急先鋒,與資料的關係日益緊密。
5、2014年 資料運營部
2014年大資料概念火熱,公司意識到了資料的巨大價值,希望有部門能針對公司海量的資料進行挖掘、分析和運營,顯然經營分析室這個名字有點小了,因此改名成了資料運營部。這個時候,大家都認識到資料運營是非常專業的工作,因此需要專業的組織分工,資料運營部下設五個小組:
匯通保障組:負責大資料採集(含資料交換)、建模(基礎和融合模型)、運維及優化,可以看到,匯通保證組是以提升資料本身的效率為核心的。
平臺工具組:負責資料中臺工具建設及優化,資料開發及挖掘服務環境建設及優化,平臺工具組是以提升資料使用效能為核心的。
報表取陣列:為公司提供及時、準確的資料,報表取數是一隻資料團隊核心的生產職能。
挖掘服務組:為公司各個領域提供資料探勘創新服務,以前這個職能與報表取數混在一起,但發現兩邊難以兼顧,因此做了拆分。
對外變現組:進行資料價值變現的探索,這是資料管理團隊從內轉向外的起點。
2014年不僅是資料中臺建設的元年,也是資料變現的元年,那一年,我們的資料價值變現實現了0的突破,但由於很多人身兼數職,因此推進上問題還是很多。
6、2015年 大資料中心
探索了一年後,公司認為時機成熟,決定成立大資料中心,將資料運營部進行拆分,傳統的報表取數職能劃歸OLTP的需求管理部,其他職能劃到大資料中心,包括對外價值變現、對內資料探勘及資料中臺等等,這個時候,我們的資料組織架構已經跟大多數公司不太一樣了,大資料中心下設三個部室:
資料管理部:負責大資料採集、開發、建模、挖掘及大資料管理體系的建立
應用產品部:負責大資料產品的規劃、設計、開發、測試、應用及運營
運營變現部:負責大資料變現的商務擴充、需求管理、合作運營及業務管理等
大家可以看到,大資料中心的職能覆蓋了從資料到產品再到商務的端到端全過程,類似於一個小事業部,在IT部門設定商務擴充這種職能在業界還是比較少見的。
現在看來也是合理的,因為在大資料創新的初期,IT的驅動力會強一點,一方面源於大資料這種業務的特殊性,另一方面對傳統業務部門來講,大資料變現初期那點收入可能不夠看,這會扼殺創新,正如《創新的窘境》說得那樣。
當然大資料中心不僅要對外價值變現,也要做好對內的賦能,因此有點雙線作戰的意思,但我認為這種兩邊作戰的組織架構在當時帶來了好處。
傳統做資料的人價值出口偏少,每天就圍著幾個業務部門轉,這限制了資料人的視野和格局,大資料中心對外開了口子,讓長期做內部資料支援的人看到了真實的市場,潛移默化的影響著每個人做事的方式。
比如對外做過資料產品後,對內做產品的時候就會比較強調客戶感知,對外做了模型後,就會知道原來某個資料特別有價值,因此會想著如何把對內也做做好。
自己2016年開始寫文章,一個原因就是發現外面的世界太大,自己那點專業知識在大市場面前不值一提,不知道自己不知道是最大的問題。
7、當下 企業資料管理部
公司原來對資料的應用主要侷限在決策支援和精確營銷領域,但近幾年隨著公司數字化轉型的深入,公司各個領域都開始嘗試擴充資料的應用範圍,希望基於資料的運營來推動流程優化和流程重構,《華為資料之道》碰到的問題,我們也碰到了,這個時候,企業級資料治理的必要性變大了。
康威定律說得好,組織架構決定系統架構,要承擔企業級的資料治理工作,就需要企業級資料治理組織的保障,公司近期成立了企業級資料治理委員會,明確了公司和領域資料責任人職責,資料管理部也從大資料中心重新回到了本部,但跟原來的資料運營組的職能已經有了很大的差別,企業資料管理部的一種小組劃分方式如下:
資料治理組:負責頂層設計、建章立制、流程管理、主資料管理等等
資料服務組:負責資料中臺運營和資料開發、挖掘、開放等等
技術運營組:負責資料工具鏈建設和運維保障
綜合協同組:負責綜合事務、外部協同、宣傳推廣、培訓競賽等等
你會看到,資料管理部承擔的更多是企業級的資料支援工作,無論是資料治理、資料中臺還是工具鏈等等,即使是去做資料開發和挖掘工作,也跟領域的資料團隊有明顯的區別,比如只做基礎標籤,不做營銷標籤,同時會去做一些領域的補位,比如某個領域如果沒有資料支撐團隊,那麼資料管理部就會頂上去,那些空白領域的資料賦能往往是從0到1,因此邊際效益會比較高。
最後要說一句,分久必合,合久必分,沒有固定形態的資料團隊,我們只能跟隨著時代的腳步起舞。
來自 “ 與資料同行 ”, 原文作者:傅一平;原文連結:https://mp.weixin.qq.com/s/dbcxYNuxBsMN_9CEykbLeg,如有侵權,請聯絡管理員刪除。
相關文章
- 如何組建高效的資料分析團隊?
- 團隊介紹及演講
- 百分點大資料技術團隊:輿情平臺架構實踐與演進大資料架構
- 我們團隊是如何落地DDD的(1)
- 資料團隊工作全貌
- 團隊演講影片及其ppt展示
- 如何讓IT團隊和安全團隊之間更好地進行協作
- 資料治理:資料整合架構的演進架構
- LBS定位系統架構是如何演進的架構
- 資料基礎架構如何演進,西部資料有話說架構
- 團隊如何組織?前後端團隊與業務功能團隊的比較後端
- 美團是如何進行指標管理的?指標
- 小菜前端的技術棧是如何規劃和演進的前端
- 未來十年,資料團隊最核心的能力到底是什麼?
- 企業資料庫工作2:團隊培養,如何高效閱讀資料庫文件資料庫
- 分析工程師 – 資料團隊中的新角色 - KDnuggets工程師
- 滴滴資料通道服務演進之路
- 網易數帆資料治理演進
- 【恩墨學院】美團點評資料庫高可用架構的演進與設想資料庫架構
- 如何管理一個散漫的團隊
- 如何實現高效的團隊合作?
- AIGC時代的算力基石,未來的資料平臺將如何演進?AIGC
- 提升團隊效能:如何與下屬進行有效溝通
- 探究如何使用敏捷專案管理進行團隊協作?敏捷專案管理
- 如何激勵敏捷團隊成為高績效團隊敏捷
- Pipefy如何使用團隊拓撲方法建設敏捷團隊?敏捷
- 資料儲存技術的演進趨勢研判
- 如何打造合作型團隊
- 技術管理進階——如何提升團隊的合作和技術氛圍
- 技術管理進階——如何規劃團隊的技術發展方向
- 什麼是Spotify模型的團隊拓撲?模型
- 談談資料產品團隊的角色和職責
- SkyReach 團隊團隊展示
- MySQL資料庫架構——高可用演進MySql資料庫架構
- 如何管理好團隊的工時表?
- 一個研發團隊是如何堅持7年技術分享的?
- 這是騰訊兩大雲遊戲團隊的一些最新進展遊戲
- 遠端辦公促進團隊之間高效協作的方法是什麼?