數據治理——落地總結

6 評論 7761 瀏覽 73 收藏 13 分鐘

數據治理團隊如何組成,有幾個小組,職責是什么?誰為治理結果負責,又是誰來推動治理?數據治理是否能夠落地需要關注哪些問題?作者對以上問題進行了一個總結,并分享了一些自己的感悟探索和認知迭代。

前言

這是我數據治理系列文章的最后一期,回顧1-4期內容,我們分別以數據治理的完整性、規范性、唯一性、及時性、準確性和安全性這6性為目標,然后介紹資產中心、DQC、SLA和安全中心這四大治理工具,按理數據治理也就這些內容,沒有它途,但為什么我還想再開一期話題,這主要是我在參加各家單位組織的數據治理分享的時候發現,大家的治理方法、策略、手段和工具基本都是一致的,但卻很少有分享數據治理的落地核心問題,即組織問題。

我每次參與這類分享的時候,我必問的一個問題,就是你們數據治理團隊,產研是如何組成的,分成幾個小組,各自什么定位和職責?我問這些問題,本質不是我想挖他們的組織架構,我其實是關心,數據治理在對方團隊內是如何定位和落地的,需求方是誰?供給方是誰?平臺方又是誰?誰為治理結果負責,又是誰來推動治理?這些問題,才是數據治理能否落地最核心的問題,反而治理工具倒相對是簡單的了。

因此,針對以上靈魂拷問,簡單聊一聊我自己的一些感悟探索和認知迭代,作為我數據治理系列文章的收官吧。

01 核心結論

第一,數據治理是一個系統性工程,需要解決用戶心智、組織保障和生產管理提效問題,如果僅靠組織授權往往曲高和寡,調子起的高但往往陷入運動式治理,領導問到哪就治理哪,業務感知上可能覺得問題非但沒解決,還徒然增加各類做表統計、應對調研等的工作負擔;如果僅靠運營case by case跟進,短期雖然容易見效果,但投入大、戰線長,往往只能頭疼醫頭腳疼醫腳,長期陷入被動,無法根本解決問題;如果僅靠開發工具或者購買第三方治理套件,則短期成本暴增,但見效慢,業務可能會因短期看不到效果而失去耐心,且誰來使用工具也是一個問題。

因此,數據治理是一個需要組織保障、運營實施和工具建設三位一體跟進的工作。

第二,數據治理又是一個抓大放小的工程。世界本質是一個熵增的過程,即任何事物本質是一個自發的由有序向無序發展的過程,這個既是人性也是客觀規律,而數據治理本質是減熵的過程,也就是要建立秩序,但任何秩序的建立本身都是逆人性和逆客觀規律的,需要源源不斷投入能量(資源)才能維持熵值平衡。

但問題就在于,人性天然有建設性和破壞性兩面,想要秩序的存在并維持下去,本身就是需要投入非常大的建設精力和成本的,而且這個成本還不是一成不變的,它是隨著公司資產的累加而增加的,也是會隨著公司戰略、制度和文化的革新變化而變化的。

因此,數據治理工程中追求完美主義是不可取的,我們要學會分類分級,學會判斷優先級,學會抓大放小,允許有序和無序的并存。

第三,數據也是一種商品,是商品,自然就存在生產商品的供給側,消費商品的需求側,以及提供商品售賣的貨架,也就是平臺側。類比現實生活,如果消費者投訴一家超市售賣變質蔬菜,那市場監管部門處罰的應該是超市而不是菜農,菜農,或者蔬菜運輸和倉儲物流環節應該由誰來監管和處罰呢,應該由超市來處罰,怎么處罰,可以退貨,可以要求賠款,可以中斷合作選擇其他供應商,但無論這樣,消費者只關心花錢買到的蔬菜是新鮮的,市場監管部門只關心超市沒有售賣劣質食品。

如果數據是蔬菜,那生產“蔬菜”的菜農,應該指的就是數據采集和開發團隊,自然售賣“蔬菜”的超市就應該是數據應用開發團隊,這些團隊平時負責提供的工具有報表工具、畫像工具、AB工具等分析工具,最后,消費“蔬菜”的自然就是我們的業務運營、分析師、銷售等業務團隊了。

因此,與現實生活類似,如果數據出現質量問題,首要負責團隊是平臺團隊,但最后真正為數據質量負責的,卻應該是數據生產團隊。

02 問題分析

結論部分,第一個結論和第二個結論,相信大家也比較好理解,我就不進行進一步拆分分析了,但第三個結論,卻實實在在涉及到數據治理是否能夠落地,還涉及到各方應該如何分工合作,因此,我就針對結論部分的第三個結論,做一個詳細的問題分析。

數據不是憑空產生,需要經過埋點采集——加工生產——指標定義——分析應用,最后才會呈現到業務手上作為可參考的分析依據,甚至可以直接應用于業務流程,正因為數據生產環節鏈條長,涉及多方團隊。

因此,數據質量出現問題,從全局看,不單單只是某一方的責任,但實際運行過程中,我們應當理解,業務其實并無法知道數據背后這么長的生產邏輯,用戶在哪消費的數據,就認為誰應該為數據負責!

所以,無論數據的口徑定義、計算統計是否由平臺方來負責,最終為數據指標負責的,一定首先是平臺方,這個是怎么也脫不掉干系的,如果平臺方遇到用戶反饋數據問題,只是簡單的做工單轉移,或者做問題匯總,都無法解決數據質量問題,這就好比超市只是把顧客對蔬菜變質的投訴傳達給供應商或者菜農一樣,這次出現質量問題,下次一定也會繼續出現。

那平臺方到底應該是一個什么角色?目前部分公司將平臺方定義為數據治理的主R,主要手段就是開發和提供相關治理、監管工具,以期通過治理和監管工具達到數據治理的目的,但落地效果往往不佳。

為什么數據治理落地不佳,這里我們就要看另外一個問題了,平臺側不推卸責任,主動主R起治理的職能,也投入資源去開發治理工具,但為什么最后還是難落地?

超市買了很多檢測蔬菜是否新鮮的測試儀,確實是可以檢測出蔬菜是否可以售賣,但數據平臺與超市的區別在于,超市檢測出不合規蔬菜,是可以退貨的,強勢的是超市方,但數據平臺因為不生產數據,且公司內基本不可能有存在可替代的其他數據生產團隊。

所以平臺側光靠數據監控工具,數據治理工具,但你缺乏數據內容,你沒有治理抓手,就算你有組織保障,你也很難持續性去從根本上解決質量問題,最后只能落不著好,生產團隊會抱怨你不干實事,只會拋問題。

因此,此時,我們發現,就因為公司內部,平臺側不負責數據生產,不負責數據內容本身的建設,如果只負責制定標準和監管標準執行的話,其實是很難有抓手去持續推動數據質量優化的。

最后,讓我們來看一張圖,以數據質量的好壞為飛輪的起點,數據質量一旦無法得到及時保證,會慢慢的開始侵蝕供給團隊和平臺團隊在用戶群體中的口碑,進而產生信任危機。

如果要讓數據正向流轉起來,核心本質就是要首先保障數據質量,先讓用戶對數據產生信任和依賴,進而再去挖掘供給,不斷豐富供給才是有意義的,那數據質量的好壞,對誰有核心利益的相關信性,我認為是對數據生產團隊。

因此,這就是我結論三里說的,如果數據出現質量問題,首要負責團隊是平臺團隊,但最后真正為數據質量負責的,卻應該是數據生產團隊,這也就是部分公司做數據治理,方向跑偏了的原因,為了解決質量問題,成立中臺團隊,開發很多治理工具,但只要數據內容不在中臺手里,中臺其實很難對質量治理的落地最終負責。

03 策略概述

核心就一句話,數據治理,首先應該圍繞數據內容生產建設才能玩得轉!也就是,做數據治理,核心還是要抓住數據內容生產建設,如果公司規模較小, 不存在多個生產團隊,或者數據內容并不是分散在多個部門中,則直接由數據生產團隊做數據治理比較合適。

如果是公司規模較大,數據內容分散在不同的數倉團隊,或者分散中不同的部門中,則應該成立一個數據中臺團隊,由這個中臺團隊負責匯總各個分散團隊的數據內容,然后統一進行加工、定義和認證,平臺為經過認證的數據質量負責。

這樣,數據的出處,以及數據內容的定義全部統一到中臺團隊,此時中臺團隊自身就是一個數據生產和服務團隊,自然有動力去豐富數據供給,去保證數據質量,也能從全局的視野去管控數據流程。

作者:明明

本文由@一個數據人的自留地 原創發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 框架圖中的3個體系具體是指什么呢?

    來自北京 回復
  2. 這篇文章不是原創

    來自江西 回復
  3. 太贊了,初步了解到數據治理是一項體量龐大的工程。
    另外,文章中提到的“數據治理系列的文章”~前1-4期分別是哪幾篇呀,翻了一下您發表的文章,暫時沒辦法通過文章命名來找到這個系列的文章,求告知,感謝。

    來自廣東 回復
  4. 數據治理系列的文章~前1-4期分別是哪幾篇呀,翻了一下您發表的文章,暫時沒辦法通過文章命名來找到這個系列的文章,求告知,感謝。

    來自廣東 回復
    1. 我也在找1-4期

      來自福建 回復
  5. 在實施層,遇到的問題有很多,可以說業務視角不同,產生數據需求也不盡相同,解決心智問題,或者說解決指標定義才能更好推進,當前企業中同樣叫做比如產品類型的標簽多入牛毛,首先需要共識名稱,最后做實施

    來自北京 回復