企業資料治理採購完整指南：MDM、資料目錄、權限治理——6 個關鍵決策、3 個報價區間、5 條合約紅線

最近我們在客製化系統的諮詢中遇到一個重複的場景——客戶找上門通常是想做 AI 客服、AI 報表、AI 分析，但聊到第三句就會發現他們真正的問題不是 AI，是「資料散在 7 個系統、欄位定義對不上、權限沒人管」。換句話說，資料治理（Data Governance）這層地基沒打好，上面蓋什麼樓都會歪。

這篇給的是企業老闆 / 採購評估者的角度——資料治理該怎麼採購、找廠商該問什麼、報價區間在哪、合約裡哪幾條是紅線。不是 IT 經理那種「DAMA-DMBOK 11 個 domain」的學術版本，是中小企業要怎麼用 60-300 萬 把這件事做到 AI 跑得起來、稽核問得出來、員工不會抱怨的版本。

有一個數字值得先放在這邊——Gartner 2026 Data Governance Maturity Survey 顯示，只有 24% 的企業有正式的資料治理計畫，但宣稱要在 12 個月內導入 AI 的比例卻高達 73%。這個落差說明一件事——大多數公司是「沒有資料治理就先衝 AI」，等 AI 跑出爛結果才回頭補基礎。BCG 在 2026 AI Impact Gap 報告 也指出，企業 AI 專案延宕的前三大原因，「資料品質與權限」獨佔第一名（43%）。

這篇要拆解的是：作為中小企業老闆，怎麼用 6 個關鍵決策框架、3 個報價區間、5 條合約紅線，把資料治理這件事從「IT 抽象名詞」變成「採購決策清單」。如果你正在評估 AI 導入、ERP 整合、或多系統串接，這份指南就是你跟廠商談判前該先過一遍的功課。

背景補充——還在前期評估階段的老闆，可以先看 你的公司還不該導入 AI 的 5 個訊號 跟 企業內部知識庫建置完整指南：從 RAG 選型、權限治理到 90 天落地，這篇是把它們前面那一層「資料地基」單獨拆出來講。

資料治理到底在治什麼？老闆版的定義

學術版的定義很長——「資料治理是組織用以管理資料資產的人、流程、政策與技術的整體架構」。老闆版的定義就一句：「讓正確的人，在正確的時間，用正確的資料做決策；錯的時候追得到責任。」這四個「正確」對應到四個工作流：身分（誰）、時序（什麼時候）、品質（資料對不對）、稽核（出問題能不能追）。

中小企業常見的失敗是把治理當作「再加一套軟體」——買了 master data 系統卻沒人維護資料字典、買了權限平台卻沒人定 role；結果系統閒置、員工繞道。我們的看法是——資料治理 ≠ 工具，是一套有人在跑的「流程 + 文件 + 工具」三件套，少任何一邊都會崩。

我們不認同「中小企業不需要資料治理、那是上市櫃的事」這種說法——你公司今天不到 100 人也許可以靠老員工的肉腦記住「客戶 A 的折扣是業務 B 給的」，但你下一個 AI agent 跑起來那天，它沒辦法讀肉腦。沒有資料治理的中小企業，AI 導入後最大的成本不是 token，是「人工 review AI 輸出的時間」——這個成本通常是 token 的 5-10 倍。

6 個關鍵決策：採購前先把這幾條釐清

找廠商談資料治理之前，下面這 6 個問題你心裡要有答案。多數小企業卡住不是廠商不行，是自己沒想清楚就丟需求，最後變成廠商 「告訴你你想要什麼」——這在資料治理這種需要組織配合的案子上特別危險。

這 6 個決策決定了你的報價會落在哪個區間。決策都選保守版（綁 ERP / Excel 目錄 / RBAC / 抽檢 / 1 年）→ 60-100 萬就夠；都選擴充版（獨立 MDM / DataHub / ABAC / 規則引擎 / 7 年）→ 200-300 萬起跳。多數中小企業合理的版本在中間——我們會建議從「先治客戶 + 訂單 / ERP 綁 master / Excel 目錄 / RBAC + 簡單抽檢 / 3 年日誌」這個組合開始，落在 100-150 萬區間。

3 個報價區間：60 萬、150 萬、300 萬各包什麼

為什麼要拆「一次性 + 年費」兩塊？因為資料治理不是蓋好就閒著——資料字典每季要更新、權限每月要 review、稽核要持續跑。沒有年費維護的版本三個月就會荒廢，等於白做。如果廠商只報一次性、不講年度維護——這條紅線就過了，下面合約紅線那節會講。

5 條合約紅線：這幾條沒寫進去你就會被綁住

我們在客製化系統的合約諮詢經驗中，看過太多客戶把資料治理外包之後變成「廠商不續約我就動不了系統」——資料字典在廠商那邊、權限規則在廠商那邊、稽核 log 也在廠商那邊。這 5 條紅線一定要寫進合約：

紅線 1：資料字典與 Schema 文件交付

合約裡明定——每季交付完整資料字典（含欄位定義、來源、owner）跟資料 schema 文件，格式採用通用標準（如 dbt schema.yml 或 OpenLineage）。沒有這條，廠商換約那天你的「主資料定義」就跟著走。

紅線 2：權限規則的可移植性

RBAC / ABAC 規則要以「標準格式（OpenFGA / Cedar / 純 SQL view）」交付。廠商用自家 proprietary 格式寫死你的權限——三年後換廠商，光重寫權限規則就要 3-6 個月。

紅線 3：稽核日誌的所有權與存放位置

稽核日誌必須存在「你的雲帳號」（你的 S3 / 你的 BigQuery / 你的 Postgres），不是廠商的 SaaS。廠商可以有讀取權限做監控，但 raw data 不能在他那邊。否則出資安事件那天，你連 log 都拿不回來。

紅線 4：年度退場條款（Exit Clause）

合約裡明寫「廠商需於合約終止前 90 天，協助客戶將所有資料字典、規則引擎設定、稽核日誌、權限模型完整匯出至客戶指定環境，匯出格式為通用標準」。沒這條，分手成本可能比一次性報價還高。

紅線 5：SLA 不能只看「系統可用率」

資料治理 SLA 要看四個指標：(a) 資料字典更新時效（新增欄位 X 天內入字典）、(b) 權限變更 SLA（員工離職 N 小時內撤權）、(c) 稽核日誌完整率（≥ 99.9%）、(d) 品質報告交付時程。光寫「系統可用率 99.5%」沒意義——服務可用但資料字典過期一年也是廢的。

如果這篇有用，再延伸三篇相關的：企業單一登入 SSO 完整指南：SAML / OAuth / OIDC 帳號治理、客製化系統開發交付驗收完整 SOP、老闆做 AI 採購決策的 3 道防線。四篇加起來，從資料地基 → 帳號治理 → 系統驗收 → AI 採購防線一條線整理完。

看完想直接動手——可以把你公司目前的系統地圖（有哪幾套主系統、客戶資料散在哪、誰能看 / 改）丟過來，我們陪你看 從哪一塊先治起最划算。這個階段我們陪你想，後面真的要動手再談範圍跟費用。