你的公司裡，有多少資料是沒人敢刪、沒人看過，卻默默躺了十幾年的？又有多少系統，是同一件事被重複建立了三次？
這些不是偶然。資料管理的許多核心觀念，都和我們的直覺相反。以下是我從 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. 為什麼要把資料畫成好幾個層次？
因為人腦裝不下
資料模型有概念層、邏輯層、實體層，為什麼要分這麼多層？標準答案不是什麼技術理由，而是：
組織的資料量，超過了任何個人能理解並據以決策的範圍。
抽象不是為了好看，而是為了讓不同角色在自己能掌握的複雜度裡工作。管理者看全貌，開發者看細節，兩邊都不會被淹沒。
順帶一提，這個思路也解釋了一個細節：同一個東西在不同層級有不同的名字，邏輯層的「實體」到了實體層就叫「資料表」。名字不同，只是因為你站的高度不同。
結語：資料管理，管的其實是「人」
回頭看這七件事，你會發現它們的共同點：沒有一個是純技術問題。讓合規變容易、補上
架構的空缺、設計人機分工、接受資料工作沒有終點，這些都在處理同一件事：
人在複雜系統裡會怎麼行動
資料不會自己變亂，是人們在每個「這樣比較方便」的瞬間，一點一點把它弄亂的。
那麼，在企業的一堆原則/政策/標準/規則，有哪一條其實是在逼員工繞路？
