我的Data Governance 之路

很多人會問我：做完前幾篇提到的規章訂立和元資料治理，資料的問題是不是就會消失？ 答案其實是「不會」。 元資料治理的規範和方法，頂多只是幫大家在 取得資料 、 處理資料糾紛 的時候，建立一個全局的Base Line。這能加速你找資料來源、溝通協調、盤點GDPR時知道有哪些資料等，讓解決問題的效率大幅提升。 這也是為什麼你常常聽到大家在談資料治理KPI時，通常只能說「提升效率」、「加快落地」，卻很少有人跟你說他用資料治理直接解決了什麼銷售或研發上的業務痛點。因為這些痛點的真正解決， 還是得回到「流程」和「系統」本身的資料設計與修改 。 舉個例子—— 假設你的客戶資料沒有建立主檔，所有銷售在輸入訂單時都是自由填寫（Free Key in），那未來你要做客戶行為分析時，連「是不是同一個人」都難以辨認，更不用說進行行為疊加或進階分析了。 這時候的問題，其實不是靠資料治理活動本身就能解決的，而是 流程與系統設計的問題 。 要解決這個痛點，必須修改業務流程，規定所有客戶下訂單前要先建立身分，並且業務只能從已建檔的客戶清單中選擇。只有透過這樣的流程規範和系統改善，這個資料品質的痛點才有機會被徹底解決。 當然，資料治理還是可以用來 系統性盤點公司內部的主檔資料 ，並制定明確的R&R（角色與責任），確保重要主檔有清楚的ownership（負責人），結合MDM（主資料管理）的概念來管理主檔的生命週期，甚至搭建統一的主資料平台，加速主檔管理和資料改善。但「每一筆資料到底該長什麼樣子？該配合什麼流程？要不要合併或拆分？」這類根本性的業務流程問題， 終究還是得靠專案一個個分析、設計和修正 。 總結一句： 資料治理能加速處理資料相關的各種問題，但不能單靠治理本身，去解決資料本質上的業務問題。 要徹底解決這些根本問題，還是得回歸流程優化和系統設計本身。

  元資料到底是什麼? 其實元資料就是「資料的說明書」。 我自己這幾年在做元資料治理，最常碰到的三個基本問題： 資料定義 （這個欄位到底代表什麼？是什麼單位？怎麼算的？） 資料在哪 （Linkage，想找這個東西時，要去哪裡查？） 誰負責 （Ownership，出問題要找誰，這欄位的老大是誰？） 但這邊有個重點，元資料不是只有一種，有分「 業務元數據 」跟「 技術元數據 」。 業務元數據 比較像是讓業務、需求單位看的，舉例：這份資料是做什麼的、有什麼商業意義，屬於哪個領域、哪個業務對象，誰是Business Data Steward，誰是Data Owner。 技術元數據 則是IT同仁的世界，像是：這筆資料存在哪個DB？哪張Table？哪個Column？IT Admin又是誰？這些才是「真的可以查得到、連得上的」底層資料資訊。 兩邊資料對得上，才不會業務說A、IT找不到A，永遠雞同鴨講。 為什麼元資料這麼重要？ 說真的，資料治理大部分的進階玩法，都要靠前面這些東西站穩腳步。 你有沒有遇過這種狀況——想要盤點GDPR，結果根本沒人知道公司到底有哪些資料？或者想要強化某些資料品質、加速查詢效率，但資料定義模糊，越做越亂？ 只要你有把元資料搞清楚，未來要加什麼敏感性標註、資料分級、資料品質註記、甚至資料分類，只要往那個表格加一欄，大家就會一目了然！ 我自己碰過，像主資料治理，如果那時候早一點把元資料盤點到位，很多奇怪的遺留問題都不用再三討論。 元資料治理實務怎麼開始？ 1. 準備元資料管理平台（推薦Open Source） 老實說現在開源選擇超多，大家只要挑一個有社群、功能夠用的就可以上手： DataHub （我自己最推這個，血緣、API全都搞定，畫面也乾淨） Amundsen （偏向資料探索、查詢） Apache Atlas （如果你有大數據或Hive/ETL，這個很強） CKAN （如果你有開放資料需求） 建議一開始可以小範圍PoC一下，不要一開始就全公司大規模導入，先找到自己流程最容易上手的切入點。 2. 元資料分層管理：業務元數據 & 技術元數據 最重要的一點是——元資料要「分層管理」！ 我都會建議從「業務元數據」跟「技術元數據」兩條路線同步...

資料治理的範圍真的很大，從解決某個資料定義上的問題、撰寫定義、標準化、到Dashboard指標的管理，都在資料治理的輻射範圍內。 這時候就會有人問：不管是解決標準化的問題，還是Dashboard指標不準確，不都是一般專案可以處理的事情嗎？ 沒錯，一般專案確實能搞定這些事情，但資料治理注重的重點是在「個案之上」： 我要怎麼樣可以 快速 解決這個問題？ 我要怎麼樣可以 避免 這種問題再次發生？ 所以可以理解，資料治理就是將處理資料問題的手法，透過固化的流程、方法、組織、角色，把企業中常見的資料問題，系統性地加以解決，並從源頭預防問題再次出現。 這也是我第一個想跟大家分享的重點： 不要為了治理而治理 。資料治理的核心，還是在於「有事要解決」。只要能把這套解決框架固化下來，恭喜你，你已經在進行資料治理了！ 這邊也舉幾個常見痛點和對應解法，讓大家感受一下： 1. 有了資料倉儲，但資料本身的定義不清，無法讓業務人員自助查詢（Self Service） 透過資料中台規章，規範所有要進入資料中台的資料／產出的報表相關資料，都必須進行元資料治理，將定義與資料表格綁定。 這樣可以 讓業務人員清楚理解資料的意義與範疇，大幅提升自助查詢能力，降低對IT部門的依賴，同時也確保資料在各個環節被正確理解與應用 。 2. 重要資料每次更新都需專案內部進行上下游串接分析，導致進度緩慢，影響範圍不易盤點 透過制定系統開發規範，要求對外接口開放時必須明確定義資料標準，並於下游系統建立串接紀錄。 再搭配流程中綁定資料血緣（Lineage）維護規範， 可實現即時盤點上下游影響範圍，讓變更風險可視化，提升變更效率並降低專案溝通成本 。 3. 公司內大家常說的指標計算結果都不同，造成成果比較無法對齊 透過資料中台的導入，將計算公式於中台ETL層統一運算，由下游系統引用；同時要求所有報表專案在BA過程中確認指標定義，並與報表資料建立Linkage綁定， 可確保組織內所有指標「定義一致」、「公式一致」、「來源一致」，避免數字打架，也讓指標管理與溝通成本大幅下降 。

網路上有太多關於資料治理的文章，一開頭就開始談組織、談架構，搞得許多企業剛開始推動資料治理時，以為只要把R&R（角色與責任）分完、制度建好，好像就已經完成資料治理了。結果，吃苦的往往是Working Level（實際執行層）的同仁：一邊困惑什麼是資料治理，一邊摸索到底要怎麼開始，怎麼讓公司的資料真的被「治理」起來。 如果沒有找過有經驗的顧問公司協助，通常大部分人都會在「治理在幹嘛」和「怎麼開始」這兩個問題上打轉，結果是疑惑、試錯，甚至浪費不少資源和成本。 這時，常常會出現以下幾種情境： 公司內有高手，很快就掌握資料治理精髓，避開了組織內的政治角力，把公司流程都逐步綁進資料治理規範中。 倒在最後一哩路——流程有了，但沒人願意配合，變成紙上作業。 弄了老半天，寫了一堆莫名其妙的定義，自己也不知道怎麼用，最後不了了之。 N的公司就是一路從第3種，慢慢進步到第2種，現在大約在1.5（還不能說完全到第1種），算是初步喚起大家對資料治理的認同。 說實在的，能夠在沒有顧問輔導的情況下，摸索出一套真正屬於自己公司的資料治理規範，真的很少見。甚至不少公司就算請了顧問，最後的成果也只是一個資料倉儲，至於資料治理的成效，大家一言難盡——不是說不滿意，是連自己都說不清到底做了什麼。 所以，N決定用「嘔心瀝血」來形容，把這幾年在資料治理路上踩過的坑都記錄下來，希望幫大家少走點冤枉路。藉由整理和分享，也讓我自己重新檢視目前的資料治理框架。 這系列的分享會先從Working Level（執行層）的角度，談談怎麼從小地方開始導入資料治理。等大家對這些基礎觀念有一定了解後，再帶到如何透過組織和規範，讓資料治理能夠在公司內真正延續、疊代、發展出屬於自己的治理文化。 俗話說：「獨樂樂不如眾樂樂。」如果這些經驗有幫助到你，也歡迎多多轉發我的部落格給有需要的朋友。一方面幫助更多人，一方面如果能獲得大家的credit，也能在我未來的職涯發展上留下寶貴的紀錄——這對我來說，是資料治理之路上的另一份收穫！