治理要设计进 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。