背景：企業核心資料的分散困境
多數企業長期將客戶資料、產品目錄、銷售記錄等核心資訊集中儲存，形成「中心基準系統」。隨著系統擴展，使用者分為三大角色：
- 消費者：終端用戶或下游系統，依賴基準資料執行業務。
- 貢獻者：在基準系統中建立/更新資料的用戶或系統。
- 資料管理者：維護資料完整性、定義中繼資料、防止遺漏的治理角色。
問題在於：各子系統（如 CRM、ERP、PIM、HR）各自為政，資料變更無法即時同步，導致資料不一致、決策錯誤、介面維護成本高。
案例：X 公司的六大獨立管理工具
| 系統代號 | 職責 | 關鍵資料實體 |
|---|
| ProMan | 產品管理 | 產品名稱、商標、規格文件 |
| FormMan | 配方/成分管理 | 產品成分、處方、安全文件 |
| GraphMan | 圖形/商標庫 | Logo、商標、使用規範 |
| HRMan | 人事管理 | 員工檔案、組織架構 |
| LabelMan | 標籤管理 | 標籤模板、列印記錄 |
| PackMan | 包裝管理 | 包裝規格、材質、供應商 |
表面看管理良好，實則存在嚴重資料孤島：
- FormMan 的處方未必對應 ProMan 當前銷售產品。
- LabelMan 的標籤內容可能與 PackMan 包裝規格脫節。
- 新產品上市需在六系統重複錄入，命名慣例、大小寫、語系（美式/英式英語）不一致。
- 介面整合採點對點（EAI/ETL/EDI），系統變更牽一髮動全身。
解決方案：建立單一主基準系統（Master Reference System）
核心架構原則
- 單一事實來源：所有主資料實體（產品、客戶、供應商、員工等）僅在主基準系統權威定義。
- 發布/訂閱機制：下游系統透過訂閱主系統發布的變更事件（CDC/事件流）同步資料，不再直接寫入主實體。
- 資料治理流程：建立資料擁有者、管家、品質規則、變更審核流程，確保主資料準確、完整、及時。
- 統一識別碼：跨系統採用全域唯一識別碼（GUID/企業統一編號），消除鍵值映射表。
實施路徑建議
階段 1：資料盤點與建模
- 識別所有主資料域（Party, Product, Location, Asset...）。
- 定義黃金記錄屬性、生命週期狀態、關聯規則。
- 選擇 MDM 平台（Informatica, IBM InfoSphere, Talend, 微軟 MDS, 或自建）。
階段 2：主系統建置與遷移
- 優先遷移高價值、高變更頻率的域（如產品、客戶）。
- 建立資料清洗、去重、合併規則（Survivorship Rules）。
- 開發發布服務（REST/訊息佇列/資料庫同步）。
階段 3：下游系統解耦
- 逐步將下游系統改為「唯讀訂閱」模式，移除本地主資料維護功能。
- 保留本地交易資料（訂單、發票）與主資料的外鍵關聯。
- 建立資料品質監控儀表板（完整性、一致性、時效性指標）。
階段 4：治理常態化
- 設立資料管家委員會，定期審核主資料變更請求。
- 自動化品質規則（如：產品必須有商標、包裝規格、至少一張標籤）。
- 擴展至參考資料管理（代碼表、分類體系、匯率、稅碼）。
關鍵技術棧對照
| 能力 | 傳統點對點 | MDM 中心化 |
|---|
| 資料一致性 | 最終一致，延遲不可控 | 近即時一致，單一來源 |
| 介面數量 | N×M 點對點 | N 個發布 + M 個訂閱 |
| 變更影響面 | 全鏈路回歸 | 僅影響發布契約 |
| 資料品質 | 分散驗證，規則不一 | 集中規則引擎，統一度量 |
| 新系統接入 | 需與所有相關系統建介面 | 僅需訂閱主系統主題 |
常見誤區與避坑指南
- 誤區：MDM = 大型專案、必須一次上線 → 採用領域驅動分階段交付，先解決最痛點域。
- 誤區：MDM 取代所有操作系統 → MDM 只管「主資料」，交易資料仍留在 ERP/CRM。
- 誤區：買軟體就能解決 → 技術佔 30%，治理流程、組織變革、資料清洗佔 70%。
- 避坑：主鍵設計 → 使用無意義代理鍵，業務鍵加唯一約束，避免業務意義變更導致主鍵變動。
- 避坑：歷史資料保留 → 主系統保留完整變更歷史（SCD Type 2），支援時點查詢與稽核。
結語
從分散的「中心基準系統」演進為統一的「主基準系統」，不僅是技術架構重構，更是企業資料治理成熟度的躍升。核心在於建立單一權威來源、標準化發布訂閱、落地資料治理流程，讓資料真正成為企業資產而非負擔。
