数据中台数据治理可以从六个模块理解：标准与指标、元数据与目录、质量、主数据、安全、持续运营。实施时先确定范围和责任，再把规则嵌入开发与发布，通过监控、整改、复验和运营复盘持续维护。下面按核心模块、治理流程与职责分工展开，并给出可用于立项沟通和评审的概览模板。
治理概览可用于立项前对齐边界、建设中协调业务与IT、年度复盘检查运行情况，让管理层了解投入、业务部门明确责任、数据团队确定优先工作。
很多团队把概览写成名词解释和架构图，评审时没有人反对，落地时没有人认领。问题出在概览没有回答四个问题：治理哪些数据，按什么流程治理，谁对结果负责，怎么判断做成了。下面的写法围绕这四个问题展开，依次覆盖边界、模块、流程、职责、模板和验收。
一、治理概览的范围与读者
1. 概览解决什么问题
治理概览服务于三类读者。拍板的人关心投入、优先级和风险；业务负责人关心自己要认领什么、能得到什么；数据团队关心先做哪个域、按什么标准做。概览要让这三类人在同一页上看到同一件事。
一份能用的概览，至少要让读者带走四个结论：治理范围有边界，核心模块有对象，流程有门禁，责任有归属。范围写得越大，第一版越难落地。 选一到两个业务价值高、问题明显的域先跑通，比一次性铺开所有系统更现实。
2. 概览、建设方案、制度文件各管什么
这三份文件经常被混在一起写，评审时看起来内容很全，执行时却找不到重点。它们的分工可以这样理解：
| 文件 | 主要回答 | 主要读者 | 典型产出 |
|---|---|---|---|
| 治理概览 | 管什么、怎么管、谁负责、怎么验收 | 管理层、业务负责人、数据团队 | 一页结论、模块清单、流程门禁、RACI、验收指标 |
| 建设方案 | 建什么、分几期、投多少、什么时候上线 | 项目决策组、实施团队 | 目标架构、实施计划、预算、资源 |
| 制度文件 | 必须怎么做、违反怎么办 | 全员或相关岗位 | 管理办法、实施细则、考核条款 |
概览负责形成共识，建设方案负责安排项目，制度文件负责强制约束。三份文件可以互相引用，合成一本会让读者分不清哪些是共识、哪些是承诺、哪些是必须执行。
3. 开始写之前准备四类输入
写作前先整理四类输入：
- 业务痛点： 如财务和销售的指标口径不一致、营销触达退信率高、取数排期较长。
- 数据域与系统清单： 列明客户、订单、商品、供应链等域及对应源系统、核心表和指标。
- 制度与组织： 核对已有分类分级、权限管理、考核办法和治理角色。
- 约束条件： 写清预算、人力、监管要求和上线时间。
缺哪一类材料，就在概览里标“待确认”，不要用行业通用说法把空白填满。 概览的价值在于暴露分歧，提前暴露比上线后返工便宜。
二、数据中台治理包含哪些模块
国家标准 GB/T 36073-2025《数据管理能力成熟度评估模型》于 2026 年 7 月 1 日实施，把数据管理能力划分为九个能力域，包括数据战略、数据治理、数据架构、数据资产、数据标准、数据质量、数据安全、数据生存周期和数据应用流通。这套标准常被称为 DCMM 2.0，适合做能力盘点和评估。
标准框架可以直接参考，不适合直接抄成治理概览的目录。企业要管的是自己的数据域、系统、指标和责任人。结合数据中台的常见场景，概览可以收敛为六个模块：
| 模块 | 主要治理对象 | 概览里写什么 | 典型产出 |
|---|---|---|---|
| 数据标准与指标口径 | 业务术语、数据元、编码、指标 | 谁定义、谁审批、怎么变更、在哪些系统落地 | 标准清单、指标字典、变更记录 |
| 元数据与资产目录 | 表、字段、血缘、负责人、更新频率 | 采集范围、维护责任、血缘层级、发布流程 | 数据地图、血缘图、资产目录 |
| 数据质量 | 完整性、准确性、一致性、及时性、唯一性、有效性 | 质量目标、规则、监控频率、问题分级、修复时限 | 质量规则库、监控报告、问题台账 |
| 主数据与参考数据 | 客户、供应商、商品、组织、科目 | 唯一可信源、创建变更流程、跨系统同步、冲突裁决 | 主数据标准、主数据清单、同步机制 |
| 数据安全与合规 | 分类分级、权限、脱敏、加密、审计 | 谁定级、谁授权、什么场景脱敏、审计留痕 | 分类分级清单、权限矩阵、审计报告 |
| 治理运营 | 制度、会议、度量、培训、考核 | 例会节奏、指标看板、问题升级、年度复盘 | 治理日历、指标看板、复盘纪要 |
数据战略和架构不单列模块，它们体现在治理目标、范围和平台约束里；数据资产在元数据与资产目录模块中落地。
1. 数据标准与指标口径
数据标准解决同一个词在不同系统里含义不一样的问题。概览里要写清标准的范围、业务定义、编码规则、审批人、变更流程，以及标准在哪些系统落地。指标口径要单独列，写清名称、定义、计算公式、统计周期、数据来源和负责人。
常见缺口是只写字段命名规范，不写业务定义和审批机制。标准发下去，开发还是按老习惯建表，业务还是按自己的理解取数。标准的权威来自业务确认和系统落标，不来自文档厚度。
2. 元数据与资产目录
元数据与资产目录回答三个问题：有什么数据、数据在哪、数据从哪来。概览里要写清元数据采集范围、业务元数据和技术元数据的维护责任、血缘覆盖到什么层级、资产目录怎么发布和更新。
如果只登记表名和字段名，不记录业务含义、负责人和更新频率，目录很快会变成一张过期清单。业务人员找不到、看不懂、不敢用，资产目录就失去了入口价值。
3. 数据质量
数据质量模块要写清质量目标、规则、监控频率、问题分级、修复时限和复验方式。质量维度可以从完整性、准确性、一致性、及时性、唯一性、有效性里选，和业务痛点相关的优先。
规则数量可以少，关键是每个问题都能落到责任人和修复时限。质量问题如果没有分级和复验，很容易变成一份长期不关闭的台账。
4. 主数据与参考数据
主数据与参考数据管理客户、供应商、商品、组织、科目这类共享实体。概览里要写清唯一可信源、创建和变更流程、跨系统同步机制，以及冲突时谁裁决。
主数据的第一条规则是一处创建、多处引用，第二条是变更要有影响分析。客户名称、商品编码这类字段一旦在多套系统里各自维护，跨系统分析就会出现对不上的结果。
5. 数据安全与合规
数据安全与合规要覆盖分类分级、权限申请、脱敏、加密、审计和事件响应。概览里要写清谁定级、谁授权、什么场景必须脱敏、审计记录保留多久。
安全条款要和业务场景绑定，例如营销触达能用哪些字段、客服能看到哪些信息、测试环境怎么处理敏感数据。写在概览里，比只写一句“加强权限管理”更能指导执行。
6. 治理运营
治理运营把制度、会议、度量、培训和考核串起来。概览里要写清例会节奏、指标看板、问题升级路径、责任考核和年度复盘。治理进入日常运营后，才会从一次项目变成持续能力。
当治理开始引入 AI Agent 做元数据补全、质量规则推荐或自然语言取数，概览要额外写清 Agent 能读什么、能写什么、哪些动作必须人工确认、执行记录怎么审计。ThinkingAI 的 Agentic Engine 支持私有化部署和多 Agent 协作，这类能力可以承接部分重复劳动，前提是权限和审计边界先写进制度。
理解企业智能体的能力与责任边界，可参阅什么是企业级AI Agent。
数据生命周期从采集、存储、使用到归档销毁，贯穿六个模块。概览不必单列第七块，但要在每个模块的门禁里写清保留期限、归档条件和销毁审批。
三、数据治理流程如何运行
治理流程容易写成一条审批链，实际运行时却卡在三个地方：标准定完没人用，质量问题没人认领，跨部门争议没人裁决。把流程写成闭环，每个节点有输入、输出、责任人和不通过的处理方式，才能落到日常。
| 步骤 | 关键动作 | 主要输入 | 主要输出 | 常见卡点 |
|---|---|---|---|---|
| 1. 定范围和基线 | 选业务域，盘点系统、表、指标、问题和责任人 | 业务痛点、系统清单、现有制度 | 范围清单、基线报告、问题清单 | 第一版范围铺得太大 |
| 2. 定标准和责任人 | 定义业务口径、编码和审批机制 | 业务规则、监管要求、历史数据 | 标准清单、指标字典、责任人清单 | 只有 IT 参与，业务不确认 |
| 3. 嵌门禁 | 在建模、开发、发布环节设置检查点 | 标准、质量规则、安全分级 | 门禁清单、检查记录 | 标准停留在文档里 |
| 4. 管问题 | 监控、定级、派单、修复、复验 | 质量规则、问题台账 | 闭环记录、根因分析、复盘纪要 | 问题无人认领 |
| 5. 评运营 | 看指标、开例会、考核、扩展 | 度量指标、复盘结果 | 治理日历、改进计划 | 运动式治理，做完就散 |
图1：数据治理流程闭环
1. 定范围和基线
先选一到两个业务价值高、问题明显的域，例如客户域、订单域或财务域。盘点系统、表、指标、质量问题、现有制度和责任人，形成基线。范围要写清做什么和不做什么，避免第一版铺得太大。
基线不需要一次盘到所有字段。核心表、核心指标、核心问题先覆盖，非核心内容在后续迭代补充。没有基线，后面的目标值和验收就缺少参照。
2. 定标准和责任人
标准由业务 Owner 牵头定义，数据管家整理，IT 评估落地成本。每个核心数据项要有业务定义、口径、编码、来源系统和责任人。标准评审要有业务、IT、安全三方参加，变更要有版本记录。
责任人要写到岗位和姓名，不能只写部门。部门会调整，岗位会换人，只有具体的人和明确的决策权限，才能在出现争议时把问题推动下去。
3. 把门禁嵌进研发与发布
把治理动作嵌进数据开发和发布流程。这里的做法是让标准在建模阶段生效、质量规则在开发阶段绑定、安全要求在配置阶段落实。落到概览里，就是三个门禁：建模前检查标准和命名，开发中绑定质量规则，发布前检查权限和分级。
每个门禁写清三件事：谁检查、检查什么、不通过怎么办。门禁没有责任人和处理方式，就会变成一句“请遵循规范”。
4. 监控、派单、修复、复验
质量问题按影响分级，明确响应时限、修复责任人和复验方式。问题台账要记录发现时间、影响范围、根因、修复动作和复验结果。跨系统问题要能追到源系统和责任岗位。
修复完成不等于问题关闭。复验要回到业务场景，确认报表、接口或分析结果已经恢复正常，再把问题关闭并沉淀规则。
5. 运营度量与扩展
用少量指标看治理是否运转，例如标准覆盖率、质量规则闭环率、问题平均修复时长、资产目录使用率。每月或每季度复盘一次，把有效做法固化成流程，再扩展到下一个业务域。
扩展速度要和组织的承接能力匹配。一个域还没有进入稳定运营，就急着铺开三个域，最后往往是标准越写越多，执行越来越少。
四、数据治理的职责如何分工
1. 三层组织怎么分
中大型企业常见三层治理组织。决策层是数据治理委员会，由高管牵头，批准战略、制度、预算和跨域争议。管理层是数据治理办公室或数据管理部门，负责方法、标准、平台、度量和培训。执行层是业务域的数据 Owner、数据管家、数据架构师和安全合规人员，负责把标准和质量动作落到日常。
华为云 DataArts Studio 的治理组织文档把领域治理工作组拆成数据 Owner、数据代表、数据管家、数据专员和数据架构师。数据 Owner 对领域治理结果负责，数据管家负责元数据、标准和质量问题的日常维护。这个划分把“谁决策”和“谁执行”分开，便于落到岗位。
2. 关键活动 RACI
RACI 是一张责任分配表，用来把活动、角色和决策权放在同一张表里。RACI 里，A 是最终负责，R 是执行，C 是事先咨询，I 是事后告知。每个关键活动只保留一个 A。
| 关键活动 | 治理委员会 | 治理办公室 | 数据 Owner | 数据管家 | 数据架构师 | 安全合规 |
|---|---|---|---|---|---|---|
| 治理范围与优先级 | A | R | C | I | I | C |
| 标准制定与变更 | I | C | A | R | C | I |
| 质量规则与问题整改 | I | C | A | R | R | I |
| 资产发布与权限审批 | I | C | A | R | C | C |
| 敏感数据授权 | I | C | C | I | I | A |
| 跨域争议裁决 | A | R | C | I | I | C |
| 治理考核与复盘 | A | R | C | C | C | C |
这张表可以直接放进概览，再按企业实际岗位改名。表格比组织架构图更容易检查：每个活动只有一个 A，执行角色和咨询角色都能对应到具体岗位。
3. 三个常见错法
常见问题可以从三处检查：
- 只有部门，没有岗位和人员： 人员变化后，责任容易中断。
- 一个活动有多个最终负责人： 出现争议时，决策权不清楚。
- 只有职责，没有时限和升级路径： 问题可能长期停留在沟通群里。
对应的改法很具体：责任人写到岗位和姓名，关键活动只留一个 A，争议写清几个工作日内升级到谁、由谁裁决。责任分工的可执行性，体现在出现问题时能不能找到人。
五、治理概览模板包含哪些内容
一份可评审的概览，可以按六个部分组织。页数由评审任务决定；下面的十到十五页正文、一页结论及十二个月里程碑，只是材料组织与规划示例，不是统一要求。
| 部分 | 必须回答的问题 | 建议形式 |
|---|---|---|
| 1. 一页结论 | 目标、范围、基线、十二个月里程碑、需要拍板的事项 | 一页纸，先给结论 |
| 2. 治理对象与模块 | 六个模块各自管什么、不做什么、产出是什么 | 模块清单加范围表 |
| 3. 治理流程与门禁 | 五步闭环怎么走，每个门禁谁检查、不通过怎么办 | 流程图加门禁清单 |
| 4. 职责与决策机制 | 谁最终负责、谁执行、争议怎么升级 | RACI 表加会议机制 |
| 5. 制度、平台与数据 | 现有制度、平台能力、数据域和系统清单、缺口 | 清单加缺口说明 |
| 6. 度量、风险与验收 | 指标基线、目标值、复盘节奏、风险和依赖 | 指标表加验收清单 |
1. 一页结论怎么写
一页结论单独抽出来，放在最前面。它包含五件事：治理目标、范围、基线、十二个月里程碑、需要拍板的事项。目标用业务语言写，例如“让核心报表的口径一致，质量问题能在规定时限内闭环”，不写“提升数据治理水平”这类无法验收的话。
基线没有现成数据就写“待盘点”，并给出盘点时间，不要编一个好看的数字。需要拍板的事项要具体，例如谁担任数据 Owner、预算多少、哪些系统先接入、考核是否纳入部门绩效。
图2：治理概览的一页结论
2. 示例：客户域手机号治理概览
下面用客户域手机号治理做一个示例，展示六个部分怎么填。示例只说明写法，数值和目标由企业按自己的基线确定。
| 概览部分 | 示例内容 |
|---|---|
| 业务问题 | 营销短信退信率高，客户手机号存在空值、重复和格式错误 |
| 治理目标 | 手机号有统一业务定义和质量标准，问题能定位到源系统和责任人 |
| 涉及模块 | 数据标准与指标口径、数据质量、数据安全与合规 |
| 治理流程 | 盘点源系统，定义手机号标准，在接入和开发环节加校验，监控空值率、重复率和格式错误率，派单修复，连续四周复验 |
| 职责分工 | 市场部数据 Owner 对口径和质量目标负责，客服数据管家维护规则和问题台账，数据平台开发实现校验，安全合规确认可使用的字段范围 |
| 度量与验收 | 标准发布并被核心系统引用，质量规则上线，问题台账闭环，连续四周达到企业设定的目标值 |
这个示例可以直接改成订单域、商品域或财务域。替换业务问题、治理对象、责任角色和指标，流程与模板保持不变。
六、不同规模企业如何调整治理范围
不同规模的企业，概览的厚度和组织方式差别很大。三层架构适合需要跨部门协调权责的中大型组织，小团队不必复制。
| 场景 | 组织方式 | 模块优先级 | 流程门禁 | 概览厚度 |
|---|---|---|---|---|
| 小团队 | 数据负责人牵头，Owner 兼管家 | 标准、质量、安全 | 发布前检查 | 三到五页 |
| 中型企业 | 虚拟治理办公室，三到五个业务域 | 标准、质量、安全，再补元数据和主数据 | 建模、开发、发布三道门禁 | 八到十二页 |
| 集团企业 | 委员会、治理办公室、域工作组 | 六个模块分期建设 | 分级门禁和跨域裁决 | 十五页以上，另加附件 |
小团队一个人可以兼多个角色，关键是每个关键活动只有一个 A。集团企业要防止委员会只有协调权没有决策权，数据 Owner 有名无实。组织形态可以简化，责任归属不能省略。
七、治理概览如何验收
概览写完，开一次评审会，用八项检查判断能不能用。
| 检查项 | 通过信号 | 常见失败 |
|---|---|---|
| 1. 范围有边界 | 写清做什么、不做什么、为什么 | 只写目标，不写排除项 |
| 2. 模块有对象 | 每个模块有治理对象、产出、责任人 | 模块名称很全，没有具体对象 |
| 3. 流程有门禁 | 每个节点有检查项、检查人、不通过处理 | 流程图画了，门禁没有责任人 |
| 4. 权责有唯一 A | 关键活动只有一个最终负责人 | 多个领导都负责，等于没人负责 |
| 5. 度量有基线 | 指标有口径、统计时间、当前值 | 只有目标值，没有基线 |
| 6. 行动有九十天清单 | 最近九十天做什么、谁做、交付什么 | 计划写到三年后，近期没人动 |
| 7. 争议有升级路径 | 几天内升级到谁、谁裁决 | 争议停在群里 |
| 8. 复盘有节奏 | 月度或季度复盘，问题闭环 | 运动式治理，做完就散 |
1. 常用度量指标
常用度量可以选五到八个：标准覆盖率、标准落标率、质量规则闭环率、问题平均修复时长、资产目录覆盖率、资产使用率、权限审批时长、治理培训覆盖率。指标先定口径和统计频率，再谈目标值。
指标要能反映业务痛点。质量问题导致报表返工，就重点看问题平均修复时长和重复问题占比；业务找不到数据，就重点看资产目录覆盖率和检索成功率。指标多并不等于有效，能支持判断更重要。
2. 评审会怎么开
评审会控制在半小时到一小时，只问三个问题：是否同意范围和优先级，是否认领角色和资源，是否同意验收指标和复盘节奏。会后输出会议纪要、责任人清单和九十天行动清单。
评审会没有拍板，概览就还停留在草稿。把需要拍板的事项单独列出来，在会上逐项确认，比会后反复沟通更有效。
如果现在就要开始，先选一个业务域，用六个部分写一版，哪怕只有五页。把范围、责任人、门禁和验收写清楚，再开一次评审会。治理概览的第一版可以先粗糙一些，只要能推动下一步行动。ThinkingAI 已服务全球超 1500 家企业、接入产品超 8000 款，多系统、多角色的数据环境并不少见，治理概览要做的，是把这些系统和角色之间的边界写清楚，让数据平台的能力被业务用起来。
常见问题
1. 数据中台数据治理概览要写多少页？
可以将十到十五页正文加一页结论作为编排示例，不必按页数验收。评审场景可以压缩到五页，只保留范围、模块、流程、权责和验收。页数服从评审需要，关键在能否回答管什么、怎么管、谁负责、怎么验收。
2. 没有独立的数据治理团队，能做概览吗？
可以。先设一个虚拟治理办公室，由数据负责人牵头，业务 Owner 和 IT 骨干兼任。一个人可以兼多个角色，每个关键活动只留一个 A。第一版从一个业务域开始，跑通再扩展。
3. 概览和建设方案、制度文件怎么分工？
概览定边界和共识，建设方案定项目排期、架构、预算，制度文件定强制规则和处罚。三份文件可以互相引用，合成一本会让读者分不清哪些是共识、哪些是承诺、哪些是必须执行。
4. 六个模块必须全做吗？
不必。按业务痛点和数据域选三个先行。标准和责任是所有模块的前提，质量和安全通常优先，主数据和资产目录在核心实体多、共享需求强时优先。没有涉及的模块在概览里写清暂不纳入和原因。
5. 怎么让业务部门认领数据 Owner？
用具体问题谈，不用抽象职责。把口径冲突、报表返工、监管风险算给业务看，把 Owner 的职责写进岗位说明和考核，并给 Owner 决策权和资源。只给头衔，Owner 很难负责。
6. 数据中台和数据治理是什么关系？
数据中台是数据接入、加工、服务和资产化的载体，数据治理是让这些数据可信、可查、可合规使用的机制。概览把平台建设、治理流程和责任分工放在一张图上，避免平台上线后没人用、没人信。
