數據治理是一項長期而繁雜的工作，很多時候大家都為如何做好數據治理而感到困惑，甚至很多時候對此失去了信心。怎么避免數據治理這些問題？
技術部門牽頭，大而全的管理
數據治理當前大部分的立項都是信息技術部門，原因在于業務部門往往覺得數據治理和我沒什么關系，技術部門大多是以數據中心或者大數據平臺為出發點，受限于組織范圍，不希望擴大到業務系統，只希望把自已負責的范圍管好。
這種情況呈現出的狀態，即客戶遇到了數據質量的問題，也意識到要通過數據治理來解決，很多時候，客戶所立的項目就叫數據治理，殊不知數據治理是一個很大的概念（這里指廣義的數據治理），包括很多內容，想在一個項目里就做完是不可能的，很多人認為我們只做了元數據、數據質量、數據標準，內容不算多，但其實內容真的不少。很容易導致最后哪個也做不好，用不起來。
我們仔細分析一下客戶的問題。
第一，范圍不聚焦。有時候我們認為已經減少范圍了，就拿元數據為例。元數據管理的類型很多種，業務元數據、技術元數據、管理元數據三大類，技術元數據又包括：表、字段、視圖、存儲過程、作業、數據流向關系、作業依賴關系、索引、分區等幾十種技術元數據。從管理范圍講，管理系統的元數據范圍又很多，包括大數據中心各層、以大數據中心的上游來源系統、下游的應用分析系統，很多公司有上百個信息系統，每個系統里上百張表，每張表兩三百個字段，其中還涉及到人工梳理的工作。如此大量的元數據，里面還需要涉及到怎么管，流程、人員、工具、制度規范等。這樣多的內容想一個項目都做了，而且還沒討論數據質量、數據標準的內容，怎么可能都做好，沒有辦法聚焦。況且就算花了很多錢，加班加點做了許多的工作，最后，所做的工作沒辦法短期見效，也得不到領導的認可，很難再開展二期的計劃，從而失去信心。
第二、需求不明確。很多客戶看似需求明確，其實是沒有想清楚自已真正想解決的問題。從我們的經驗看，以具體的數據問題或應用需求為出發點是比較合適的切入點，例如我們可以找數據質量問題比較突出的，反饋問題比較多的業務部門，收集數據質量問題，根據問題進行分析，最后發現導致這些問題的原因有數據標準的問題、元數據的問題、主數據的問題等，然后再根據這些問題去開展數據標準，元數據、主數據等工作。所展開的工作也是有方法的，例如梳理的數據標準范圍也僅是以這次問題所涉及的信息項去做，最后這些問題得到了解決，也獲得了業務部門的認可，總結經驗，再逐步擴大范圍。
當然，很多時候，需求并不總是清晰的，如果想不清楚需求，建議先啟動一個小型的咨詢項目，通過專業的團隊，大家一起找到切入點，其實很多時候并不是大家沒需求，只是需求是籠統的，模糊不清晰的，而單純的請來公司做交流，企業都是抱著自已的心思來的，都是有意引導到對企業自已有利的方向中，但真正是不是適合客戶自已的情況就不一定了，結果客戶聽了很多觀點，覺得自已經搞清楚怎么弄了，其實不知道，數據治理哪能僅靠幾次售前交流就都能弄清楚的呢。就像近幾年為什么付費內容這么火一樣，免費的不一定就好，付費了，企業可以花費時間和精力幫助客戶找到真正目標，這樣才不致于后續花更多的錢來交學費。
業務部門牽頭，專做流程
傳統數據治理很多是信息技術部牽頭來做的，但是往往效果不好，于是業務部門決定牽頭來做，那是不是業務牽頭就會好了呢？業務部門提出，要做全生命周期的管理，業務部門決定從流程入手，開始建立流程，從需求、設計、開發、測試、上線，運維，將所有環節都用統一的流程來管理。結果導致流程超級復雜，為開發人員實際增加了很多工作量，遇到緊急需求，要求當天必須上線，于是領導一紙公文，跳過流程直接上線。最終的結果是：一方面由于增加了操作人員的工作量，另一方面領導沒有見到實效，于是逐漸邊緣化，最后束之高閣。
第一、全生命周期管理不是萬金油。其實，做數據的全生命周期管理沒錯，但問題是很多時候，業務人員只是單純的知道一個名詞，對怎么做數據治理沒有一個完整的認識，只是按照自已想象的去做。那么如何避免呢，是不是完全不要流程就是效率了呢？不是的，流程還是要做的，為了效率而不考慮后續的管理，會帶來更大的低效。例如說上線時ETL流向關系設計信息缺失，參考碼值沒有維護，導致后續業務變更時，難以理解之前的設計，業務變更困難，只能重新開發。
第二、做流程不要執念線上化。其實流程工具只是手段，他并不能約束人的活動，就像我可以不走流程直接上線，流程只能是提高我們工作效率的技術工具而，因此，建議先從線下流程開始，先把流程走通，不斷獲得反饋，不斷改進，當流程穩定下來后，再去做線上化的流程工具支撐，這樣做才能真正做到務實的管理。
第三、單一部門難落地。只有業務部門或技術部門部分參與也是不行的。我們知道數據是流動的，數據的問題涉及多個部門，僅有技術部門的參與是很難推動數據治理的活動，只有讓技術和業務部門都參與進來，以業務為導向，技術部門配合，才能夠達成較好的結果。例如以某幾個關鍵業務指標為切入點，針對這幾個指標加工數據流向所涉及的方面去梳理，結果是這幾個指標的數據質量得到了大幅提高，同時也積累了治理的經驗。
完全依賴工具，唯工具論
很多公司都認為，數據治理就是買一些工具，認為工具做好了，數據治理就沒問題了。結果是：一方面功能越做越多，另一方面實際上線后，功能復雜，大家使用不起來。其實這是錯誤的想法，數據治理本身包含很多的內容，制度規范、流程、組織、工具四項缺一不可，工具只是其中一部分內容，大家在做數據治理最容易忽視的就是組織人員，所有的活動流程、制度規范都需要人來執行、落實和推動，沒有對人員的安排，后續工作很難得到保障。一方面治理推廣工作沒人做，流程能否堅持執行得不到保障。另一方面沒有相關的數據治理培訓，導致大家對數據治理的工作不重視，認為與我無關，從而導致整個數據治理項目注定會失敗。建議大家在做數據治理的時候將組織人員放在第一位，有組織的存在，就會有人去思考這方面的工作，怎么去推動，持續把事情做好，以人為中心的數據治理工作，才更容易推廣落地。
為了做數據標準而做標準
很多公司上來就說要做數據標準，卻不知道數據標準的全面梳理，范圍很大，很難以一個項目的方式都做完，而且就算是花很大精力梳理，也沒辦法看到效果，結果是客戶只看到了一堆文檔，這是最普遍的問題。
數據標準落地困難。很多客戶覺得數據標準落地難，問我怎么能讓業務系統改標準，其實數據標準落地有幾個方法，有源系統落地、大數據中心落地、數據接口規范落地。要不要在源系統落地是取決于具體的數據標準問題，而不是泛泛的談論落地。企業數據標準的落地，應該細化到數據標準項，再分析其必要性，涉及面、重要程度等方面，只有把這些問題都搞清楚，才能夠做出改和不改的意義。例如有些字段客戶編號，涉及多個系統范圍廣、重要程度高、影響大，因此需要針對這個標準信息項制定一個可行的數據標準落地方案，如此才具有可落地的可行性。
企業做數據治理切忌貪大求全，要做小而精。把一個具體的數據標準問題，從前到后都理清楚，真正把這一個標準項所涉及的問題都理順，這樣一個數據標準問題才能夠得到真正的解決。同時也要注意優先級，因為數據標準問題很多，需要根據重要性、緊迫性來進行選擇。
?總結一下
? ? ? ?企業做數據治理，要避免大而全，要做小而精
?業務部門與技術部門合作，協同推進數據治理工作
?重視數據治理組織，避免唯工具論
?要明確需求問題，不要盲目做數據標準
（部分內容來源網絡，如有侵權請聯系刪除）
