六、資料治理與管理機制

資料治理確保儀表板資料的準確性、一致性和可信度。

1. KPI 定義文件管理（KPI Definition Sheet）

建立 KPI 定義表

每個 KPI 都必須有完整的定義文件，包含：

必要欄位：

• 指標名稱
• 計算公式
• 單位
• 資料來源
• 責任人

KPI 定義表範本

定義文件管理

• 集中管理：統一存放於文件管理系統
• 版本控制：記錄每次變更
• 定期審查：每季檢視是否仍符合需求
• 變更管理：重大變更需經委員會核准

2. 更新與驗證流程（Data Governance）

標準作業流程

資料品質檢查

自動化檢查項目：

✅ 完整性檢查

-- 檢查是否有遺漏日期
SELECT
    date_series
FROM generate_series('2025-01-01', '2025-01-31', '1 day') AS date_series
WHERE date_series NOT IN (SELECT order_date FROM orders);

✅ 合理性檢查

-- 檢查異常數值（超過3個標準差）
SELECT *
FROM kpi_data
WHERE value > (平均值 + 3 * 標準差)
   OR value < (平均值 - 3 * 標準差);

✅ 一致性檢查

-- 檢查加總是否一致
SELECT
    CASE
        WHEN 總計 = 各部門加總 THEN '一致'
        ELSE '不一致'
    END AS 檢查結果
FROM ...

3. 指標負責制度（KPI Owner）

KPI Owner 職責

每個 KPI 指定一位專責主管（KPI Owner），負責：

1. 數據正確性

   • 確保資料來源準確
   • 驗證計算邏輯正確
   • 處理異常數據

2. 目標設定

   • 制定合理的目標值
   • 調整預警門檻
   • 定期檢討目標

3. 改善行動

   • 分析未達標原因
   • 提出改善方案
   • 追蹤改善成效

4. 溝通協調

   • 向使用者說明指標意義
   • 處理使用者疑問
   • 跨部門協調資料問題

KPI Owner 矩陣

4. 版本與權限控管

版本管理

版本號規則：主版本.次版本.修訂號（例：v2.1.3）

• 主版本：重大架構變更
• 次版本：新增或移除 KPI
• 修訂號：公式調整、門檻修正

變更記錄範例：

權限控管

分級權限架構：

Level 1: 檢視權限（Viewer）

• 可瀏覽儀表板
• 可使用篩選器
• 可匯出可見資料

Level 2: 分析權限（Analyst）

• 包含 Level 1 所有權限
• 可下鑽查看明細
• 可建立自訂視圖
• 可匯出完整資料

Level 3: 編輯權限（Editor）

• 包含 Level 2 所有權限
• 可調整佈局
• 可新增圖表
• 可設定提醒

Level 4: 管理權限（Admin）

• 包含 Level 3 所有權限
• 可管理使用者權限
• 可修改 KPI 定義
• 可調整資料來源

權限矩陣範例

資料層級權限

Row-Level Security（行級安全）：

-- 區域經理只能看到自己區域的資料
CREATE POLICY regional_manager_policy
ON sales_data
FOR SELECT
USING (
    region = (SELECT region FROM users WHERE user_id = current_user_id())
    OR user_role = 'admin'
);

Column-Level Security（列級安全）：

-- 非財務人員看不到成本欄位
SELECT
    product_name,
    revenue,
    CASE
        WHEN user_role IN ('admin', 'finance') THEN cost
        ELSE NULL
    END AS cost
FROM sales_data;

5. 資料來源管理

主資料系統（Master Data Systems）

建立資料來源清單：

資料整合原則

✅ 單一真實來源（Single Source of Truth）

• 每個資料欄位只有一個官方來源
• 避免從多個系統提取同一資料

✅ ETL 流程

Extract（提取）→ Transform（轉換）→ Load（載入）

✅ 資料血緣（Data Lineage）

• 追蹤資料從來源到儀表板的完整路徑
• 記錄每一步的轉換邏輯

6. 異常處理機制

異常類型與處理

Type 1: 資料遺漏

問題：某日訂單資料未匯入
處理：
1. 自動發送通知給 KPI Owner
2. 標記該日期資料為「不完整」
3. 追蹤修正並重新載入

Type 2: 異常數值

問題：營收突然暴增 500%
處理：
1. 自動標記為「待審核」
2. 暫停發佈
3. 人工檢查原因
4. 確認後發佈或修正

Type 3: 系統故障

問題：資料來源系統無法連接
處理：
1. 顯示「資料更新中斷」警告
2. 顯示最後更新時間
3. IT團隊介入排查
4. 恢復後補齊資料

異常通知範本

Email 通知範例：

主旨：【資料異常】月營收數據待確認

負責人您好，

系統偵測到以下異常：
- KPI: 月營收
- 日期: 2025-01-15
- 異常值: $15,000,000
- 預期範圍: $8M - $12M
- 異常原因: 超出歷史平均值 3 個標準差

請盡快確認資料正確性：
[檢視詳細資料] [確認無誤] [回報問題]

系統管理員

7. 稽核與合規

稽核追蹤

記錄以下活動：

• 使用者登入/登出
• 資料存取（誰、何時、存取哪些資料）
• KPI 定義變更
• 權限調整
• 資料匯出

稽核日誌範例：

合規要求

GDPR / 個資法：

• 使用者有權查詢其資料被如何使用
• 使用者有權要求刪除其資料
• 敏感資訊需加密或遮罩

SOC 2：

• 存取控制
• 資料加密
• 變更管理
• 災難復原計劃

資料治理檢查清單

• [ ] 所有 KPI 都有完整的定義文件
• [ ] 每個 KPI 都指定了責任人
• [ ] 建立了資料驗證流程
• [ ] 設定了異常偵測與通知機制
• [ ] 實施了權限分級管理
• [ ] 記錄了資料來源與血緣
• [ ] 啟用了稽核日誌
• [ ] 定期審查 KPI 的有效性
• [ ] 建立了版本管理機制
• [ ] 符合資料保護法規要求

上一章：視覺化設計原則 下一章：運作機制（PDCA）