单域一个季度
把范围限定在一个业务域与一组核心指标，通常一个季度可完成闭环。为什么强调单域？跨域治理涉及多套主数据与审批链，周期难以预估；先做一个域，能验证方法是否适配本组织，再谈复制，风险也可控。
盘点与负责人同步
资产盘点如果只由技术团队完成，产出的清单业务不认。怎么做？盘点表由业务确认字段含义，技术补技术属性，双方在同一张表上签字；这一步多花一周，后面可以少返工一个月，整体更划算，责任也更清楚。
字典编制留评审
指标定义初稿由数据团队起草，评审由业务与财务共同参与，争议项单独列出并指定裁决人。怎么避免评审拖长？提前把争议收敛到三条以内，其余按初稿通过，后续按版本迭代，不追求一次定稿，评审才能结束。
稽核整改是硬约束
规则上线后要跑完整一轮稽核，问题分派到责任人并限期整改。边界在于：整改率不设为对外承诺，但超期未处理项必须在例会上逐条说明；没有这一约束，稽核报告会变成归档文件，问题依旧滞留在原地。
适用与不适用
适合谁
- 需要给出治理项目时间表的负责人
- 准备先做单域试点、再逐步扩围的企业
- 有年度考核或审计节点、需要按期交付的组织
不适合谁
- 要求一次性覆盖全集团全指标的紧急项目
- 尚未确定首个试点域、也没有负责人的组织
典型场景
某能源企业选择燃料成本作为首个治理域，排期十三周：痛点确认一周、盘点与负责人确认三周、字典编制与评审三周、规则上线与首轮稽核四周、整改复盘两周。评审阶段争议集中在分摊口径，由财务裁决后写入字典，最终按期闭环。
可执行步骤
- 确定首个治理域与一组核心指标，写入确认单并由双方签字
- 盘点表由业务确认含义、技术补属性，双方共同签字后定稿
- 字典初稿评审，争议项指定裁决人并在会后收敛到三条以内
- 规则上线后跑完整一轮稽核，分派整改，并复盘三项结论
常见坑
- 首期就覆盖多个域，主数据与审批链交织，半年仍在盘点，管理层失去耐心，项目被叫停。
- 字典评审不设裁决人，争议反复讨论，排期被无限延长，规则上线被迫推迟到下一个季度。
- 稽核发现问题不限期整改，报告逐年累积，同一差异反复出现，治理最终被视为形式工作。
自检与验收清单
- 首个治理域与核心指标是否书面确定
- 盘点表是否有业务与技术双方签字
- 争议项是否指定裁决人并留有记录
- 稽核问题是否限期整改并跟踪闭环
常见问题
一个季度够吗？
单域、核心指标有限、主数据基本可用时通常够。若涉及跨系统主数据改造或历史数据清洗，需要另算；建议把主数据改造单独立项，不要与首域闭环混在同一张排期表里，容易互相拖累。
能不能多域并行？
可以但风险高：并行会稀释业务负责人的注意力，评审与整改同时堆积。若确有并行需要，建议各域错开两周启动，并共用一套字典与稽核模板，避免方法分裂，也便于横向比较。
里程碑怎么设定？
用可核对产出：字典签字版、首轮稽核报告、整改闭环清单。避免用完成治理这类无法判定的表述，否则验收时双方对是否完成会有完全不同的理解，进度也无法跟踪，返工也说不清。