“數(shù)據(jù)治理”這個詞，在最近這幾年時間一下子火了起來。不知從何時起，江湖中流傳出了：“數(shù)字經(jīng)濟轉(zhuǎn)型、治理發(fā)展先行”的說法。
但只有真正做到數(shù)據(jù)治理的人才知道: 數(shù)據(jù)治理不僅是辛苦，還吃力不討好，往往要承擔責任，領(lǐng)導還看不到你做的價值。
為什么說數(shù)據(jù)治理是臟活累活呢？
1. 源數(shù)據(jù)
?
煙囪式開發(fā)： 業(yè)務(wù)繁多、數(shù)據(jù)庫多而亂，系統(tǒng)與系統(tǒng)之間錯綜復雜。
?
數(shù)據(jù)庫種類： 架構(gòu)經(jīng)歷多次變遷，切換不完全，需要從Mysql、oracle、hbase甚至excle表中跨庫、跨實例、跨種類才能獲得有效業(yè)務(wù)數(shù)據(jù)。
?
數(shù)據(jù)結(jié)構(gòu)混亂： 同一字段，類型、命名都不一致。
?
文檔缺失： 無數(shù)據(jù)庫文檔或文檔陳舊。
2. 變遷
?
系統(tǒng)版本升級： 每一次升級都只是掩蓋之前的錯誤，數(shù)據(jù)治理需要從源頭。
?
人員變更： 梳理過程中的大部分問題最終答案： “不清楚，原來維護人已離職”。
?
數(shù)據(jù)流轉(zhuǎn)： 數(shù)據(jù)從源頭經(jīng)過很多次不規(guī)范的同步。
3. 存量
?
各自為政： 各業(yè)務(wù)部門已有自己的統(tǒng)計邏輯和報表，同一指標匯總維度又不一致，梳理、治理、輸出還要盡量不影響已有報表結(jié)果。
?
半途而廢： 前任都知道數(shù)據(jù)治理、統(tǒng)一出口的重要性，但只完成一部分就放棄了。 問題在于“完成的一部分”有人還在用。
數(shù)據(jù)治理是一項長期而繁雜的工作，很多時候數(shù)據(jù)治理廠商做了很多工作，當把咨詢成果落地到實處的時候，但客戶卻認為沒有看到什么成果，這是因為在進行數(shù)據(jù)治理時存在了各種誤區(qū)。
1客戶需求不明
客戶既然請廠商來幫助自己做數(shù)據(jù)治理，必定是看到了自己的數(shù)據(jù)存在種種問題。但是并沒有考慮做什么，怎么做，做多大的范圍，先做什么后做什么，達到什么樣的目標，業(yè)務(wù)部門、技術(shù)部門、廠商之間如何配合做這些問題，也就是說很多客戶其實并沒有想清楚自己真正想解決的問題，很難在數(shù)據(jù)治理方面找到一個切入點。
2問題來源不明
在大數(shù)據(jù)時代，很多組織認識到了數(shù)據(jù)的價值，也成立了專門的團隊來負責管理數(shù)據(jù)，有的叫數(shù)據(jù)管理處，有的叫大數(shù)據(jù)中心，有的叫數(shù)據(jù)應(yīng)用處，名稱不一而足。這些機構(gòu)往往由技術(shù)人員組成，本身的定位也屬于技術(shù)部門，它們的共同點是：強技術(shù)，弱業(yè)務(wù)。當數(shù)據(jù)治理項目需要實施的時候，往往就是由這些技術(shù)部門來牽頭。技術(shù)部門大多是以數(shù)據(jù)中心或者大數(shù)據(jù)平臺為出發(fā)點，受限于組織范圍，不希望擴大到業(yè)務(wù)系統(tǒng)，只希望把自己負責的范圍管好。但數(shù)據(jù)問題產(chǎn)生的原因，往往是業(yè)務(wù)>技術(shù)，可以說大部分的數(shù)據(jù)質(zhì)量問題，都是來自于業(yè)務(wù)。
3數(shù)據(jù)標準難行
很多客戶一說到數(shù)據(jù)治理，馬上就說我們有很多數(shù)據(jù)標準，但是這些標準卻統(tǒng)統(tǒng)沒有落地，因此，我們要先做數(shù)據(jù)標準的落地。數(shù)據(jù)標準真正落地了，數(shù)據(jù)質(zhì)量自然就好了。我們首先需要全面梳理數(shù)據(jù)標準，而數(shù)據(jù)標準的全面梳理，范圍很大，包括國家標準，行業(yè)標準，組織內(nèi)部的標準等等，需要花費很大的精力，甚至都可以單獨立一個項目來做。所以，首先需要讓客戶看到梳理數(shù)據(jù)標準的廣度和難度。其次，就算是花很大精力梳理，也很難看到效果，結(jié)果往往是客戶只看到了一堆Word和Excel文檔，時間一長，誰也不會再去關(guān)心這些陳舊的文檔，這是最普遍的問題。
