crm-data-governance

CRM 数据治理

为 CRM 构建并运行字段级治理体系。交付成果是一份持续更新的规则手册，加上一套会议节奏——“治理的消亡是因为缺少会议，而不是缺少文档”（ORM Tech）——由以下内容构成：

• 有治理要求的字段目录，每个字段指定一名负责人。
• 每个字段各自的权威数据源映射，以及写入优先级和冲突规则。
• 刷新和数据过期 SLA。
• 按单位投入所创造的价值排序的执行计划。
• 字段申请、审批和弃用生命周期。
• 让这一切持续运转的定期会议节奏。

基本原则

• 治理收入关键字段，而非所有字段——这是范围界定的首要决策。CRM 中有数百个字段；治理全部字段既不可能，也适得其反（从业者共识）。从 references/field-ownership-and-dictionary.md 中列出的字段清单入手，仅通过接收流程逐步扩展。
• 每个字段指定一名明确的人类负责人——“不是一个团队，而是一个人。”（RevBlack）。将字段分配给使用它的职能部门，而非填充它的职能部门。
• 按字段指定权威数据源，绝不按系统或对象指定。其他所有副本都必须明确标记为派生数据。无论时间戳显示什么，空值都不得覆盖已有值。
• 绝不能把销售代表当作最后一道强制执行手段。“不能要求销售代表负责数据录入……他们的薪酬、目标和心理激励都会推动他们去销售，而不是管理数据”（Jared Barol）。与其施压要求填写必填字段，不如优先使用自动化、集成写入、数据丰富和默认值。
• 设计并运营一个常设体系。没有负责人映射、生命周期和定期节奏的清理工作不算治理；清理结束当天，数据质量就会再次衰退。
• 为每个阈值标注其来源：已公开的公司实践、从业者共识，或根据用户自己的数据推导得出。对流传的统计数据保持警惕——“每年 30% 的 CRM 数据会衰退”和“CRM 数据准确率只有 40%–60%”这两种说法都没有注明出处，绝不能当作事实陈述。应说明背后的机制：存储值之下的现实会发生变化（人员会换工作，公司会发展壮大并更名），而没有按字段确定权威来源的多方写入同步会悄无声息地相互覆盖。绝不要把供应商自行创造的专有综合评分说成行业标准。
• 范围边界：记录去重和合并机制不在本文讨论范围内。定期数据维护、阶段退出标准、预测可靠性和路由逻辑属于参考部分中的相关技能——本技能制定这些工作所需的字段规则。

B2B 和 B2C

差异：

• B2B 依赖稀疏、变化缓慢的数据：销售周期长、账户层级复杂、采购委员会参与，并且默认不应信任销售代表录入的数据层（“你绝不能假设销售团队中的任何人会帮你补充数据”——Stefano Mazzalai）。治理工作需要协调多个职能部门向同一账户写入数据。
• B2C 依赖海量、实时的行为数据，由没有销售代表参与的系统写入。同意/偏好字段和数据保留计划会成为首要治理字段（营销部门负责同意政策，平台运维负责同步可靠性；即使页面创意由各团队自行管理，同意逻辑仍应集中管理）。
• 身份解析 在 B2C 中需要跨渠道匹配（确定性精确标识符匹配与概率匹配），在 B2B 中没有对应概念。B2B 则通过匹配域名在账户层面解析身份。

两者相同的部分： 按字段指定权威数据源、空值不得覆盖已有值、按风险等级划分数据丰富操作，以及明确区分“上次验证时间”和“上次修改时间”。这一等同性是根据通用表述的来源推理综合得出的，并非已公开的论断——应在交付成果中说明。

访谈

设计任何方案前先提问。每条消息只问一个问题；尽可能提供多选项；已回答的问题跳过。

• 使用的是哪个 CRM？还有哪些系统会向其中写入数据：营销自动化、计费、产品数据库、数据丰富服务商、支持工单系统、数据仓库？
• 能否导出（或让我查询）范围内对象的字段列表？每个核心对象大约有多少个自定义字段？
• 目前哪些字段用于预测、路由、薪酬或高管报告？（以此确定受治理字段集。）
• 当前有哪些问题：字段在不同系统间相互矛盾、值莫名其妙地恢复、数据过时、字段泛滥、没人知道谁负责什么？
• 目前谁负责数据运营：专职 RevOps、CRM 管理员、IT，还是无人负责？
• 是否有任何字段文档或字典？存放在哪里？
• 哪些数据丰富服务商会向 CRM 写入数据？写入哪些字段？
• 面向 B2B、B2C，还是两者都有？范围内是否有任何同意/数据保护方面的义务？
• 是否已有治理论坛？目前由谁审批新字段？
• 典型销售周期有多长，记录量有多少？（用于校准 SLA 和阈值。）
• 必须在什么日期前落实：审计、董事会报告周期、CRM 迁移，还是目前无人信任的预测？
• 你想一次性修正目前有误的字段，还是建立一个随着字段增加仍能持续发挥作用的治理体系？
• 工作量上限是什么：本季度管理员可投入多少小时、是否有任何集成工程能力，以及销售组织在绕过你之前能接受多少阻力？

最后三个问题决定 Workflow 步骤 4 和 6 中各选项的排序，因此设计任何方案前都要先问：

• 明确的截止日期会提升仅需配置的层级（受限选项列表、默认值、定时拉取、仅补充式数据丰富），并将有条件验证和实时推送安排到下一周期，而不是直接取消。
• 持续治理要求会提升按角色分配权限、按阶段设置有条件必填，以及生命周期和节奏本身的优先级；降低默认值的优先级，因为默认值只能修补症状，无法建立规则。
• 没有集成工程能力就彻底排除实时推送。
• 销售组织已对必填字段抱有抵触情绪就排除要求销售代表填写的硬性必填字段。

在规范中记录每一项排除的选项——被排除后搁置在列表底部的选项，会在下一次升级时重新成为范围内容。

工作流

1. 执行访谈；确认范围边界（字段规则——不包括重复数据清理、数据卫生检查或阶段设计）。

2. 界定受治理字段集：从 references/field-ownership-and-dictionary.md 中的收入关键字段列表开始，添加所有用于预测/路由/薪酬/报告的字段，并有意识地控制范围。

3. 为每个字段指定负责人：遵循使用方负责原则，指定一位具体负责人，默认按职能划分 RACI（同一参考文档）。

4. 为每个字段构建系统记录映射：权威系统、写入优先级、复制模式、按风险级别划分的数据丰富写入策略，以及冲突解决层级——参见 references/system-of-record-rules.md。这一步包含两个有优先级顺序的选项，二者都在此处确定，而不是在参考文档中确定：

   • 复制方式，效率：scheduled pull > reconciliation-only > real-time push。默认所有受治理字段都按其新鲜度 SLA 要求的频率定时拉取；只有在一次过时的同步周期会改变操作而非报告时，才将字段提升为实时推送。实时推送是此排序中最不占优的选项——新鲜度最佳，性价比最差——因此降级时要在规范中注明；如果事件总线或 iPaaS 已在运行，且增加字段的边际成本为零，则反转排序。
   • 丰富方式，效率：augment > append > overwrite。默认整个受治理字段集都采用增强；只有在提供方按定义具有权威性，且存储值不带任何验证标记时，才改为覆盖。覆盖在此处同样不占优，原因也相同；而且它是唯一能纠正已有错误值的模式。

   参考资料说明了这两种排序背后的价值、工作量和合规成本维度、各项之间的平局情况，以及会直接排除某个选项而非仅将其降级的约束。在编写映射表前，根据访谈中了解到的团队情况重新评定两种排序。

5. 按字段类别设定刷新 SLA，并设计基于触发条件的重新验证机制，跟踪上次验证时间——references/freshness-slas.md。为每项 SLA 标注来源。

6. 根据references/enforcement-menu.md为每个字段选择强制措施，并按单位工作量的价值排序，而非按措施有多轻量排序：

   • 效率：picklist > conditional-required > defaults > permissions > layout > hard-required。第一轮默认采用受限选项列表加默认值；对于决策在已知阶段转换时会读取的任何字段，提升为该阶段的条件必填。
   • 按此排序，按角色设置权限和硬性必填最不占优：两者都能提供廉价选项无法带来的实际价值，而且在每一轮效率排序中都落败。当某个受治理字段出现两个编写者无视其记录系统指定的情况时，立即提升权限措施；只有在缺少该值会导致记录无法判定时，才设为硬性必填。
   • 切勿默认采用硬性必填——只挑选廉价选项的项目，最终会得到一份没人信任的字段字典。

7. 建立生命周期和节奏：收集问题集、批准/拒绝标准、弃用流程、委员会成员、会议频率、决策权限——references/field-lifecycle.md。

8. 使用工作默认列集（所有权参考）编制字典。当实时 CRM 可直接查询时，根据其元数据生成初始行；否则根据用户导出内容构建，并将未经验证的行标记为未验证。

9. 一次输出一个章节的交付内容（输出格式），供用户验证，并以references/worked-examples.md中的对应示例为依据。

10. 检查通过门槛；反复迭代，直至满足要求。如果你的运行环境支持持久记忆，请存储受治理字段列表、所有权映射和记录系统决策，以便周期审查和争议解决从这些信息开始；否则，字典本身就是持久交付物——告知用户应将其视为此类产物。

输出格式

每条门槛都必须带有来源标签。

CRM FIELD GOVERNANCE SPEC - <company>, <date>
Scope            : objects in scope; governed-field count vs total field count;
                   motion (B2B / B2C / both); options deleted by the user's
                   constraints, and which constraint deleted each
Ownership map    : field -> named owner (a person) + owning function
System of record : field -> authoritative system, write precedence, replication
                   pattern, enrichment strategy + risk tier, conflict rule
Freshness SLAs   : field/category -> refresh cadence, re-verification triggers,
                   last-verified tracking plan
Enforcement      : field -> mechanism + why it beat the rung below it +
                   rollout note
Dictionary       : column set, initial rows, dictionary-vs-live-CRM
                   reconciliation plan
Lifecycle        : intake form, approval/rejection criteria, deprecation
                   process, utilization-review threshold
Cadence          : council membership, weekly/monthly/quarterly rhythm,
                   decision rights, escalation path
Metrics          : baseline values captured, KPI targets, first review date

达标标准

• 每个受治理字段都具备：
  • 一名明确指定的个人负责人（不能是团队名称）。
  • 唯一一个权威数据源。
  • 对所有涉及该字段的同步，明确声明写入优先级和冲突处理规则。
  • 刷新 SLA，或明确标记为事件驱动。
  • 至少一种强制执行机制。
  • 一条数据字典记录。
• 任何受治理字段都不能有两个写入方却未声明优先级；扩充数据绝不会自动应用于身份字段或下游触发字段。
• 数据字典抽查：从实时 CRM 中抽查 10-15 个受治理字段（类型、可选值、是否必填、是否有描述），至少 95% 一致。这是可根据用户自身的数据偏差情况进一步收紧的实用门槛，并非已发布的标准。
• 会议节奏已列入日历，包含明确列出的参会者和有记录的决策权限——仅有政策文档按定义不符合此门槛。

持续迭代，直到以上四项全部达标。如果本次无法验证实时 CRM，请将抽查标记为待办，并安排为委员会的首个议程事项。

常见失败模式

缺陷	后果	修复方法
字段由团队负责（“RevOps 负责”）	人人负责等于无人负责；问题遭到忽视，或在多个系统中重复出现	每个字段指定一名具体负责人，并在数据字典中显示其姓名
管理所有字段	精力被稀释；治理被认为难以实施而遭放弃	管理对收入至关重要的字段；仅通过受理流程扩展范围
条件反射式地设为必填	“不适用”和垃圾数据也能通过门槛；采用率骤降	按效率顺序处理：先设置可选值和默认值，再做条件验证，最后才设为强制必填
扩充数据覆盖已验证的值	可信数据遭到无声破坏	默认采用补充/追加；仅在扩充数据被指定为权威来源时才覆盖；对所有写入进行风险分级
双向同步，但未明确各字段的权威来源	值来回变动、无声覆盖，并引发“数据有误”的升级处理	为每个字段指定权威数据源，并检测上次同步后的冲突
将一次性清理误认为数据治理	数据立即再次劣化	建立生命周期和固定节奏；清理是系统的产出，而不是系统本身
委员会从不召开会议	政策逐渐失效；请求绕过受理流程	安排每周分流会议并赋予决策权；会议本身就是执行机制
将治理交给 IT	业务部门不再信任定义	由 RevOps 负责；数据管理是业务职能
无人负责的一次性字段	字段泛滥、重复字段、知识只掌握在少数人手中	通过受理流程检查重复项；审查使用情况；建立弃用队列
将成功衡量为“销售代表填写了更多字段”	填写率上升，准确率下降	衡量冲突率、数据陈旧度和已验证覆盖率，而非填写量

KPI

• 跟踪：
  • 纳入治理的字段填充率，而非所有字段的填充率。
  • 字段使用率：是否用于报告或自动化，而不只是已填充。
  • 过时分布：各字段自上次验证以来的时间。
  • 每次同步运行的跨系统冲突率。
  • 验证失败率。若该比率飙升，说明存在阻力——在庆祝规则执行到位之前，先检查是否有人用垃圾值应付。
  • 字段申请的审批耗时。实践目标：从申请到发布不超过一周。
  • 自定义字段数量趋势；申请流程启动后，这一趋势应趋于平缓。
• 绝不要把“销售代表填了更多字段”当作成功——规则强制填写垃圾内容时，填充率会上升，准确率却会下降。
• 每季度重新抽查一次数据字典；偏差增加意味着协调闭环出了问题。

调用示例

• “我们的 CRM、计费系统和营销自动化系统分别记录了不同的员工人数。请逐字段决定以哪个系统为准。”
• “任何人都能添加自定义字段，而 account 对象上已经有 400 个字段。请建立字段申请流程和所有权模型。”
• “请为预测所依赖的字段建立数据字典和刷新 SLA——其中一半已经过时，而且没有人负责。”

参考资料

• 在界定治理范围、指定负责人或构建数据字典时，阅读 references/field-ownership-and-dictionary.md——其中包含所有权模型、收入关键字段清单、实用的默认列集和偏差控制。
• 在梳理各系统的权威来源时，阅读 references/system-of-record-rules.md——其中包含逐字段指定、写入优先级、按价值／投入／合规维度排序的复制与数据增强方案、数据增强风险等级以及反复切换检测。
• 在制定刷新频率时，阅读 references/freshness-slas.md——其中包含带来源的频率表、上次验证与上次修改的区别，以及重新验证触发条件。
• 在选择执行机制时，阅读 references/enforcement-menu.md——其中包含按效率、价值、投入和合规成本排序的六种机制、选项列表治理、必填字段何时适得其反，以及可选的供应商说明。
• 在建立申请流程、弃用机制和委员会时，阅读 references/field-lifecycle.md——其中包含问题集、审批标准、频率和决策权。
• 在设计交付成果时，阅读 references/worked-examples.md——其中包含一份完善的五字段治理规范示例，以及一份错误示例。
• 查看 mbfinotti/revops-skills@sales-pipeline-hygiene，了解定期清理过时商机和完整性审计——它会按周执行本技能一次性定义的规则。
• 查看 mbfinotti/revops-skills@pipeline-stage-definition-audit，了解阶段退出标准设计——阶段字段在此仅作为受治理的选项列表出现。
• 查看 mbfinotti/revops-skills@sales-forecast-diagnostic，了解基于受治理字段构建的预测可靠性。
• 查看 mbfinotti/revops-skills@lead-routing，了解使用受治理路由字段的路由逻辑。
• 查看 mbfinotti/revops-skills@revenue-data-governance-strategy，了解公司级数据治理和跨团队数据契约——本技能的范围仅限 CRM 字段。