你的公司裡,有多少資料是沒人敢刪、沒人看過,卻默默躺了十幾年的?又有多少系統,是同一件事被重複建立了三次?
這些不是偶然。資料管理的許多核心觀念,都和我們的直覺相反。以下是我從 DAMA-DMBOK 的內容中挑出的七個,看完你可能會重新思考自己的日常資料管理/處置作業。
1. 好的安全政策,是讓人「懶得違規」
我們談資訊安全時,直覺是加規則、加限制、加處罰。但 DMBOK 的思路相反:制定並傳
達安全政策,是為了確保……
遵循比不遵循更容易
規則再嚴,只要遵守起來很麻煩,人就會找捷徑。把「對的做法」設計成阻力最小的路,比寫十頁禁令有用。安全不是靠防堵,而是靠設計。
2. 重複建立同樣的系統,是「架構」出了問題
假設一家公司這幾年換了三套 CRM,每套的資料結構都不一樣。你會怪誰?選型的人?廠商?
答案是資料架構。架構的職責,是在企業層級定出藍圖與標準,確保每個新專案都照著長。沒有人守住這件事,每個專案就各自重新發明一遍。
這也解釋了為什麼資料架構團隊更像「策略規劃與合規單位」,而不是一群很強的 DBA。DBA 負責把房子蓋穩,架構團隊負責決定城市怎麼規劃。
3. 沒價值的資料不刪,因為「留著比丟掉便宜」
為什麼組織明明知道有些資訊毫無價值,還是不處置?
不是因為捨不得,而是因為儲存太便宜、也太容易擴充。留著不花什麼錢,丟掉卻要有人判斷、審核、執行。
這就是資料肥胖症的根源:沒有任何一個當下的決定是錯的,累積起來卻成了問題。要對抗它,需要的是制度(組織的保存與處置政策),而不是等大家某天自動變得自律。
4. 「人工導向修正」其實是機器先動手
資料品質的修正方式,從全自動到全人工,中間有一種叫 manual directed correction。很多人看到 manual 就以為是人在改,其實剛好相反:
工具自動做清理與修正,人只在結果提交前把關。
這個設計很聰明。機器負責量,人負責判斷,把人力花在最需要判斷力的地方。「人在迴圈裡」不等於「人在動手」,這點在今天談 AI 輔助作業時,一樣適用。
5. 資料品質不是專案,是組織長期運作的事
專案有起點、有終點、有驗收。但 DMBOK 特別強調資料品質管理是一個「計畫(program)」,同時包含專案工作、日常維運,還有溝通與培訓。
原因很簡單:資料每天都在產生,錯誤也每天都在產生。專案一結束就收工,品質就會慢慢退回原樣,先前的投入也跟著白費。
如果你的資料品質工作有「結案日」,值得問問自己:結案之後,誰接手?
6. 「最佳版本」可以是一個系統,也可以是一筆紀錄
主資料管理裡有兩個常被搞混的詞:
System of record(記錄系統):存放權威版本的那個系統,資料衝突時以它為準。
Golden record(黃金紀錄):把多個來源比對、合併、清理後,產出的那一筆最完整的紀錄。
一個是「地方」,一個是「那筆資料」。分不清楚時,問自己:我指的是一個系統,還是一筆紀錄?有趣的是,兩者都在回答同一個問題:當大家說法不一,我們該信誰?
7. 為什麼要把資料畫成好幾個層次?
因為人腦裝不下
資料模型有概念層、邏輯層、實體層,為什麼要分這麼多層?標準答案不是什麼技術理由,而是:
組織的資料量,超過了任何個人能理解並據以決策的範圍。
抽象不是為了好看,而是為了讓不同角色在自己能掌握的複雜度裡工作。管理者看全貌,開發者看細節,兩邊都不會被淹沒。
順帶一提,這個思路也解釋了一個細節:同一個東西在不同層級有不同的名字,邏輯層的「實體」到了實體層就叫「資料表」。名字不同,只是因為你站的高度不同。
結語:資料管理,管的其實是「人」
回頭看這七件事,你會發現它們的共同點:沒有一個是純技術問題。讓合規變容易、補上
架構的空缺、設計人機分工、接受資料工作沒有終點,這些都在處理同一件事:
人在複雜系統裡會怎麼行動
資料不會自己變亂,是人們在每個「這樣比較方便」的瞬間,一點一點把它弄亂的。
那麼,在企業的一堆原則/政策/標準/規則,有哪一條其實是在逼員工繞路?