治理要設計進 org
另有 28 種語言版本
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
第 1 個模組，共 6 個，屬於 Data Architect 課程第 5 章資料品質與治理。每個模組都可以單獨閱讀。 下一篇：把壞資料擋在門外
**本模組回答的問題：**資料治理對架構師意味著什麼，誰做什麼？
人們聽到資料治理時，想到的是會議：委員會、政策、標準，一份解釋誰該如何處理資料的文件。這些也許都是治理計劃的一部分。作為架構師，我關心的是另一個問題：這項策略在哪裡執行？
如果策略規定只有財務部門可以修改某個欄位，是什麼來執行它？如果策略規定 ERP 擁有法定客戶記錄，是什麼阻止 Salesforce 裡的某人修改它？如果策略規定配送小組只能在當天、只為自己的停靠點看到收貨人的地址，是什麼真正讓這一點成真？如果策略規定保留七年，是什麼在七年後把它歸檔或刪除？**一項沒有執行點的策略，基本上只是一個願望。**當這些決定被構建進系統時，治理就變成了架構。
治理永遠沒有完成的一天
Section titled “治理永遠沒有完成的一天 ”讓我先把這一點說清楚：**治理是做不完的。我見過它時起時落。一家公司真正關注資料品質，情況就會好轉。注意力轉移到別處，品質就會下滑。一個新的整合上線，一個業務部門改變了流程，有人匯入了一個檔案，公司收購了另一家公司，一個代理程式開始寫入記錄，問題就又變了。目標不是一個每條記錄永遠完美的神話般的狀態，而是讓資料對業務來說足夠可信，並且把最糟糕的壞資料擋在門外。**這是持續的工作。
當 Salesforce 基本獨立存在時，治理意味著在一個地方清理資料。當它是第 4 章那張全景圖中的一個節點時，治理就變得更難，也更必要。現在客戶存在於 Salesforce、ERP、資料倉儲、合作夥伴系統、Data 360 中。誰擁有它？誰可以修改它？哪一份副本是權威的，哪些屬性可以流動，它們保留多久，出錯時誰來回答？這些不是配置問題，而是會變成配置的治理問題。
記錄所有人不等於資料所有者
Section titled “記錄所有人不等於資料所有者 ”從「所有者」這個詞開始，因為 Salesforce 讓它變得容易混淆。開啟一個客戶，你會看到一個所有人：比如一位銷售代表。這位代表擁有客戶資料嗎？不一定。在 Salesforce 上，有所有人的物件上的記錄歸一個使用者或一個佇列所有；所有人擁有完全存取權限，並且所有人通過角色階層和共用規則驅動分配和共用（Sharing and Record Access Features (opens in a new tab)，英文）。這就是記錄所有權：一種平台機制。
資料所有者是另一回事：作為業務資產對資料負責的那個人或職能。財務部門可能擁有法定客戶資訊，運營部門擁有配送狀態，人力資源部門擁有員工資料。Salesforce 甚至給了你一個記錄它的地方：每個欄位上的 Data Owner 分類欄位（Data Classification Metadata Fields (opens in a new tab)，英文）。
在 Steve Trucking，一個零售合作夥伴的客戶記錄可能歸管理這個合作夥伴的銷售主管所有。但合作夥伴的法定身分由財務部門治理，並在財務 ERP 中主控。銷售、服務、運營和合作夥伴入口網站都需要這個客戶；但這些都不意味著，一旦財務部門確立了合作夥伴的法定身分，這位銷售主管就應該去修改它。我見過團隊看著所有人欄位，就以為自己解決了資料所有權問題。他們沒有。記錄分配不等於業務問責。
所有者、資料專員、資料保管人
Section titled “所有者、資料專員、資料保管人 ”三種治理角色，三份不同的工作。
**資料所有者制定策略。**他們回答這些問題：資料是什麼意思，誰可以建立和修改它，它必須多準確，保留多久，誰可以看到它，哪個系統是權威的，以及出錯時怎麼辦。架構師不應該去編造這些答案。這是我最堅定的立場之一：**所有者制定策略；架構師負責執行。**如果財務部門說，一旦客戶處於活躍狀態，法定名稱就只能通過 ERP 流程來修改，那是一個治理決定。讓它在機制上成真，是我的工作。
資料專員讓它持續運轉。資料專員貼近資料的日常健康狀況：關注品質訊號，調查重複，解決例外，協調修復，維護定義，發現那個不斷產生壞資料的流程。還有兩項工作也歸資料專員。當兩個團隊對一個欄位的含義、誰擁有它或誰可以看到它意見不一時，資料專員把爭議提交給資料所有者，並跟進到決定落實。此外，資料專員還要培養資料素養：幫助錄入和使用資料的人理解資料的含義，以及這些規則為什麼存在。資料專員需要的不只是組織架構圖上的一個名字。他們需要時間、可見性、一套流程，以及推動問題得到修復的權限。否則，「資料專員」就會變成某人的第八項職責，每個季度才看一次。
**資料保管人運營系統。**管理員、平台團隊、安全團隊：任何運營儲存和處理資料的技術的人。所有者說只有這些角色可以看到它；保管人運營讓這一點成真的控制措施。名稱沒有那麼重要，重要的是讓每一項問責都清清楚楚，而在一個小組織裡，一個人可能身兼兩職。
治理專案如何運作
Section titled “治理專案如何運作 ”治理專案通常有三種形態。**集中式：**一個團隊為每個領域編寫策略和標準。它很一致，但可能成為瓶頸，遠離真正做事的人。聯邦式（分散式）：每個領域，比如財務、銷售或運營，在幾條共用規則之內治理自己的資料。它貼近工作，但各領域之間的定義會逐漸走樣。**混合式：**一個小型中央團隊負責標準和共用定義，各領域的資料所有者和資料專員管理自己的資料。我見過的大多數企業最終都落在混合式的某個位置。對架構師來說，這種形態回答了一個實際問題：在我執行一項策略之前，由誰簽字批准？共用定義又放在哪裡？
**考點。**瞭解運作治理專案的三種方式：集中式、聯邦式（分散式）和混合式，以及每種方式對由誰制定策略、共用定義放在哪裡意味著什麼。
讓 RACI 名副其實
Section titled “讓 RACI 名副其實 ”RACI（誰負責執行 Responsible、誰負最終責任 Accountable、諮詢誰 Consulted、通知誰 Informed）是有幫助的，但不是因為治理「需要一個」就做一張巨大的電子表格。我希望它回答架構問題，從第 4 章的三個問題開始（類別背後的四個問題）：**資料在哪裡建立，在哪裡編輯，在哪裡被引用？**這往往是不同的系統。拿一個產品來說：ERP 建立它，Salesforce 引用它，入口網站展示它，資料倉儲分析它。現在業務改變了「有效產品」的含義。變更從哪裡開始，誰來批准，它如何傳播，哪些副本是隻讀的？如果你回答不了，你就還沒有治理。你只有副本。一份好的 RACI 恰恰會暴露這種模糊。
治理必須變成機制
Section titled “治理必須變成機制 ”業務方說只有財務部門可以修改客戶的法定名稱。我不希望架構上的答案是「我們會在培訓中講到」。培訓有幫助，但它不是執行。也許是欄位級存取權限、一條驗證規則、一個只有整合才能寫入的欄位，或者一個代替直接編輯的受控流程。機制取決於需求，但必須有一個：
| 治理策略 | 由誰決定 | 可能的執行點 |
|---|---|---|
| ERP 擁有法定客戶身分 | 財務 | 只允許整合寫入的欄位、權限、驗證 |
| 只有有需要的人才能看到個人資料 | 隱私、安全 | 共用、權限、欄位存取 |
| 客戶識別符號是唯一的 | 業務所有者 | 唯一的外部 ID、重複規則 |
| 受治理的記錄不能手工建立 | 資料所有者 | 權限、自動化、整合 |
| 敏感資料有設定的保留期限 | 隱私、法務 | 保留或刪除流程 |
| 重要的變更必須可以證明 | 合規 | 欄位歷史記錄、稽核軌跡 |
| 資料的來源保持可識別 | 資料所有者 | 來源欄位、血緣後設資料 |
我有意說可能的執行點。這不是一張挑選功能的表。它是思考的順序：策略是什麼，誰擁有它，以及架構中是什麼讓它成真？
資料所有者制定策略；架構師執行策略。
不要依賴自覺
Section titled “不要依賴自覺 ”「永遠不要修改 ERP 客戶 ID。」人人都知道，直到有人改了：無意中改了，通過資料載入改了，通過自動化改了，通過整合改了，通過代理程式改了。如果修改它會破壞企業資料，「請不要這樣做」就不是控制措施。把控制措施建起來。信任，但要驗證。人、整合、自動化和 AI 都會犯錯，所以架構應該假定遲早會有東西去嘗試策略所禁止的事。那時會怎樣？
治理跨越系統邊界
Section titled “治理跨越系統邊界 ”回到全景圖。ERP 擁有客戶；Salesforce、資料倉儲和一個客戶資料平台持有副本；一個合作夥伴拿到其中一部分。這項策略適用於哪個系統？全部。Salesforce 可能正確地阻止了一次法定名稱的修改，而某個整合卻讓一個下游系統把它覆蓋了。Salesforce 可能刪除了資料倉儲仍然持有的個人資料。一個在 Salesforce 中被分類為敏感的欄位，可能會落到別處一個未分類的文字欄位裡。治理不能止步於 org 的邊緣，因為資料不會止步於此。這就是為什麼第 4 章要放在前面：全景圖告訴你治理必須延伸到多遠。
治理要恰當，而不是事無鉅細
Section titled “治理要恰當，而不是事無鉅細 ”相反的失敗同樣真實。我們發現治理很重要，於是把一切都鎖死：沒人能建立，每次修改都要審批。資料是受治理了，但沒人能做自己的工作了。治理意味著為資料施加恰當的控制：對一些資料要嚴，對另一些要松。有些記錄可以自由建立，有些需要審批；有些欄位幾乎任何人都能編輯，有些只有整合能編輯。下一個模組會具體講這一點。
而且因為治理永遠做不完，執行就需要反饋。重複在增加嗎？必填欄位被填滿了垃圾嗎？整合在失敗嗎？使用者在找變通辦法嗎？例外在增長嗎？資料專員整天都在處理同一個問題嗎？這些訊號告訴你設計是否在起作用，有時也告訴你控制措施或策略本身需要改變。
**考試之外：AI 改變了什麼。**治理有了一個新的消費者：代理程式。資料所有者仍然決定什麼可以被使用、用於什麼；架構師仍然讓它變得可執行。改變的是速度和規模。代理程式讀取、組合受治理的資料並據此行動的速度遠遠快於人，所以一項只存在於文件中的策略，提供的保護就更少了。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 誰對每一個重要的資料領域負責，以及這與記錄所有權有何不同。
- 誰擔任資料專員，誰作為資料保管人來運營它。
- 在整個全景中，重要的資料在哪裡被建立、編輯、引用和主控。
- 什麼執行點讓每一項重要的策略在機制上成真。
- 架構如何顯示治理是否在起作用，或者開始出現下滑。
當我聽到一項治理要求時，我會把它翻譯出來。「ERP 擁有這個。」「只有這些人能看到這個。」「我們需要證明是誰改了這個。」「這個要保留七年。」每一次都是：給我看執行點。架構師不決定策略。我們設計執行它的系統。治理正是在這裡不再是一份文件，而變成了架構。
- Salesforce Help，Sharing and Record Access Features (opens in a new tab)（英文），查閱日期 2026-10-14。
- Salesforce Help，Data Classification Metadata Fields (opens in a new tab)（英文），查閱日期 2026-10-14。