一、当数据质量"塌房"时，为什么没人站出来？

几乎所有做过数据治理的团队，都经历过这样的场景——

周一早晨，经营分析会上的月度报表数字对不上。财务总监指着"客户数量"字段问：这个口径到底算不算已注销用户？数据团队的回答是"这是业务系统推过来的"，业务部门的回答是"这是 IT 部门建的表"，IT 部门的回答是"这是三年前外包公司做的"。

三层皮球踢完，问题依然悬在空中。

有句话说：“数据质量的问题，本质上是组织问题在数据层面的投影。”

这不是技术难题。字段校验、数据清洗、血缘追溯——这些工具早已成熟。真正卡住企业数据治理进程的，是一个看似简单却极难回答的问题：这份数据，到底归谁管？

没有明确的所有权，就没有明确的责任。没有明确的责任，数据质量就永远处于"公地悲剧"状态——所有人都在使用，没有人愿意维护。

这正是本文要拆解的核心命题：如何在一个跨部门、多系统、长链路的企业环境中，把"数据所有权"从一句口号变成一套可执行的权责矩阵。

二、数据所有权为什么这么难界定？

在传统 IT 治理中，资产归属相对清晰——服务器归运维、应用归开发、网络归网管。但数据的特殊性在于，它同时具备三重属性：

• 业务属性：数据是业务活动的记录，它的含义、口径、生命周期由业务定义。
• 技术属性：数据存储在数据库、数据湖、文件系统中，它的物理管理依赖技术团队。
• 治理属性：数据涉及合规、安全、隐私，需要跨部门的策略协调。

这三重属性分别指向不同的组织角色，而"数据所有权"的模糊地带，恰好就产生在三个属性的交叉区域。

2.1 典型的"三不管"地带

你会发现，三方都有道理，但三方都没有错。问题出在没有预设的责任框架——当问题出现时，没有人被事先指定为"第一个该站出来的角色"。

2.2 数据确权与资产确权的本质差异

固定资产有物理边界，一份数据没有。同一个"客户"实体，在 CRM 里叫 customer_id，在 ERP 里叫 buyer_code，在数据仓库里又叫 dim_user_key。三个系统的三个字段，描述的可能是同一个业务概念，但分属三个团队维护。

这就引出了数据治理领域的经典分层模型——Data Owner、Data Steward、Data Custodian，三层角色各司其职，共同构成数据权责矩阵的骨架。

三、三层角色模型：Owner、Steward、Custodian

3.1 角色定义速查

3.2 Data Owner：谁为数据"拍板"

Data Owner 是数据治理中最具决策权的角色，也是最容易被虚设的角色。

一个合格的 Data Owner 需要回答三个问题：

1. 这个数据域的业务目标是什么？ ——客户数据域的目标可能是"支撑精准营销与合规风控"。
2. 数据质量的底线标准是什么？ ——比如客户手机号完整率不低于 98%。
3. 数据出问题时，谁来第一个响应？ ——Owner 本人或其指定的 Steward。

在实践中，Owner 的任命经常犯两个错误：

• 粒度太粗：把整个公司的数据都挂在 CTO 或 CDO 名下，名义上"全权负责"，实际上一个字段都管不到。
• 只有名没有权：给了某业务总监一个"数据所有者"的头衔，但没有配套的资源调配权和考核指标。

某大型零售企业的数据治理负责人曾总结：“Data Owner 如果不在绩效考核里体现，就只是一张组织架构图上的虚线。”

正确的做法是按数据域（Data Domain）拆分 Owner。一家典型的企业可以拆出 6-12 个核心数据域：

• 客户域（Customer）
• 产品域（Product）
• 订单域（Order）
• 财务域（Finance）
• 供应链域（Supply Chain）
• 人力资源域（HR）

每个域指定一位业务线负责人作为 Owner，对该域的数据质量、合规性和业务价值承担最终责任。

3.3 Data Steward：数据治理的"毛细血管"

如果说 Owner 是数据治理的"大脑"，那 Steward 就是"毛细血管"——深入业务肌理，把治理策略传导到每一个字段、每一条规则。

Steward 的日常职责包括但不限于：

• 维护业务术语表：定义"活跃用户"“GMV"“库存周转率"等业务概念的精确口径。
• 制定数据质量规则：与 Owner 协商后，将业务要求转化为可执行的校验规则（如"订单金额 > 0"“收货地址非空”）。
• 处理数据质量问题：当质量监控告警触发时，Steward 是第一响应人，负责判断是业务原因还是技术原因，并推动修复。
• 跨系统数据对齐：当同一个业务概念在不同系统中有不同表达时，Steward 负责建立映射关系并维护一致性。

一个常被忽视的设计要点是：Steward 最好来自业务侧，而不是 IT 侧。 原因是数据质量的根源 80% 以上来自业务端——录入不规范、口径变更未通知、流程变更未同步。一个懂业务的 Steward 能更快定位问题根因，而不必每次都"提工单给 IT 排查”。

3.4 Data Custodian：技术层面的"守夜人”

Custodian 负责的是数据的物理层管理。他们不关心"客户手机号该不该 11 位"，但关心"这张表是否有索引、是否按天分区、备份策略是 RPO 几小时"。

Custodian 的典型职责：

• 数据库与存储架构设计
• 数据管道的建设与运维
• 访问控制与权限管理的技术实现
• 数据备份、恢复与灾备
• 性能调优与容量规划
• 数据脱敏与加密的技术执行

Custodian 与 Steward 的协作边界可以这样理解：Steward 说"这个字段需要加密"，Custodian 决定"用 AES-256 还是 RSA，密钥放 KMS 还是 Vault"。

在云原生环境中，Custodian 的角色正在被平台化——很多底层运维工作被数据平台自动承接（如自动分区、自动备份、自动扩缩容）。但这不意味着 Custodian 消失了，而是其职责上移到了平台治理层：定义平台的使用规范、资源配额策略、成本优化规则。

四、权责矩阵的设计方法

有了三层角色的定义，下一步是把它们落成一张可执行的权责矩阵（RACI Matrix）。RACI 四个字母分别代表：

• R（Responsible）：执行者，实际动手做事的人
• A（Accountable）：负责人，最终为结果负责的人
• C（Consulted）：咨询方，决策前需要征求意见的人
• I（Informed）：知情方，决策后需要被告知的人

4.1 数据治理核心活动的 RACI 分配

4.2 设计原则

在搭建这张矩阵时，有几条原则值得反复强调：

每个活动有且只有一个 A。 如果两个角色都是 A，出了问题就会互相推诿。Owner 是大多数治理活动的最终负责人，Steward 是执行层面的负责人。

R 可以多个，A 只能一个。 修复一个数据质量问题可能同时需要 Steward 排查业务原因、Custodian 执行 SQL 修复，但最终为"这个问题是否被关闭"负责的，只有一个人。

C 不要太多。 如果每项决策都需要咨询七八个人，流程就会陷入瘫痪。一般控制在 2-3 个关键咨询方。

I 要有机制保障。 “知情"不是发一封邮件就完事。需要通过数据治理平台的自动通知、周报、仪表盘等方式，确保关键方及时获取信息。

五、落地案例：某金融机构的数据确权实践

为了让上述框架更具操作性，下面以一个真实场景为蓝本，展示三层角色矩阵是如何在组织中落地的。

5.1 背景

某中型金融机构在监管报送中频繁出现数据质量问题。监管机构在年度审查中指出了三类典型问题：

1. 客户风险等级字段在核心系统与风控系统中不一致
2. 交易数据的时间戳格式在不同渠道（柜面、网银、手机银行）中不统一
3. 部分历史客户记录缺少反洗钱所需的必要身份信息

这三个问题的共性是：都涉及跨系统、跨部门的数据，但没有人被明确指定为问题的第一责任人。

5.2 确权过程

该机构的数据治理委员会（由 CRO 牵头）启动了数据确权项目，分为四个阶段：

第一阶段：数据域划分

将全行数据资产划分为 8 个数据域：客户域、账户域、交易域、产品域、渠道域、风控域、财务域、监管报送域。每个域对应一组核心业务实体和流程。

第二阶段：Owner 任命

每个数据域指定一位 Owner，由对应业务条线的部门总经理担任。例如：

• 客户域 Owner：零售银行部总经理
• 交易域 Owner：运营管理部总经理
• 风控域 Owner：风险管理部总经理

关键设计：Owner 的数据治理绩效被纳入年度 KPI，权重占 10%。这一条是整个项目能否成功的分水岭。

第三阶段：Steward 配备

每个 Owner 配备 1-3 名 Steward。Steward 从业务条线的数据分析骨干中选拔，要求同时具备业务理解能力和基本的数据分析技能（SQL、Excel 高级功能、数据质量工具操作）。

Steward 的汇报线采用双线制：日常向所属业务部门汇报，数据治理相关事务向治理委员会虚线汇报。

第四阶段：Custodian 对齐

IT 部门按数据域分配了对应的 Custodian 团队。每个 Custodian 团队负责该域数据在技术层面的全生命周期管理——从源系统到数据仓库、从在线存储到归档。

5.3 落地后的运作机制

确权完成后，该机构建立了一套常态化的运作机制：

5.4 效果

实施一年后，监管机构在次年审查中对该机构的数据治理改进给予了正面评价。内部指标方面：

• 数据质量问题的平均修复周期从 23 天缩短到 6 天
• 跨系统数据不一致问题数量下降了 67%
• 监管报送数据的退回率从 12% 降至 2%

某位参与项目的架构师评价道：“最大的变化不是工具升级，而是每个数据问题都有了一个明确的第一联系人。以前大家的第一反应是’这个问题该找谁’，现在翻开权责矩阵，三秒钟就能定位到 Steward。”

六、落地过程中的常见陷阱

即便有了完善的框架，实际落地时仍然有不少坑需要绕开。以下是从多个企业实践中总结出的高频陷阱。

6.1 “全员 Owner"等于"无人 Owner”

有些企业为了让数据治理看起来"很重要”，把 Owner 角色赋予了大量人员——十几甚至几十个 Owner，覆盖了每一个字段。结果反而稀释了责任：当所有人都是 Owner 时，没有人觉得"这是我的事"。

建议：Owner 的粒度控制在数据域级别，一家企业通常 6-15 个 Owner 即可。

6.2 Steward 变成"兼职打杂"

很多企业在任命 Steward 时，只是在现有岗位描述上加了一行"兼任数据管家"。这些 Steward 本身就有繁重的业务分析工作，数据治理变成了"有空才做的事"。

建议：如果数据治理确实是战略优先级，至少为核心数据域配备专职 Steward。退而求其次，也要在 Steward 的绩效中明确数据治理的权重（建议 20%-30%）。

6.3 Custodian 与 Steward 的边界模糊

当 Steward 来自 IT 部门时（这本身就不太推荐），很容易与 Custodian 的职责混淆。Steward 说"我要加一个字段"，Custodian 说"这个字段加不了，会影响性能"，两个人吵半天发现其实是一个人在两个角色之间左右互搏。

建议：坚决把 Steward 放在业务侧，Custodian 放在技术侧。两者的张力恰恰是数据治理需要的制衡机制。

6.4 只有任命没有赋能

给了头衔、给了职责，但没给工具和培训。Steward 不知道怎么用数据质量平台，Owner 看不懂数据治理仪表盘，Custodian 不了解新的合规要求。

建议：配套的培训计划、操作手册和工具使用指南是确权项目的必要交付物，不是"后续补充"。

6.5 忽视变更管理

组织架构调整、业务线合并、系统迁移——这些变更都会打乱已建立的权责矩阵。如果矩阵是一份静态文档，很快就会过期失效。

建议：将权责矩阵纳入数据治理平台的元数据管理模块，当组织架构或系统架构发生变更时，触发矩阵的自动审查与更新流程。

七、从"三层角色"到"治理文化"

三层角色模型提供了数据确权的骨架，但要让这套机制真正运转起来，还需要一层更柔软的东西——组织文化。

具体来说，有三个层面的文化建设值得关注：

认知层面：让全员理解"数据是资产，不是副产品"。这需要持续的内部宣导——不是发一封全员邮件，而是通过真实案例（“因为客户地址字段缺失，导致 XX 万元的营销预算浪费”）让业务人员感受到数据质量的切肤之痛。

激励层面：将数据治理成果与个人绩效挂钩。不只是 Owner 和 Steward，普通的数据录入人员也应该在绩效考核中有"数据质量"这一项。有些企业采用了"数据质量红黑榜"的方式，每月公示数据质量最优和最差的业务单元，效果显著。

协作层面：打破"数据治理是 IT 的事"这种根深蒂固的认知。数据治理委员会的成员构成应该是业务占多数、技术占少数。当业务部门的负责人亲自坐在治理委员会的会议桌上时，数据治理才真正从"技术项目"升级为"组织工程"。

八、小结：权责清晰是数据治理的"第一性原理"

回到开头那个经营分析会的场景——如果这家企业已经建立了三层角色矩阵，那么当"客户数量"口径出现分歧时，故事会这样展开：

1. 数据分析师发现问题，在治理平台提交工单。
2. 工单自动路由到客户域的 Data Steward。
3. Steward 查阅业务术语表，确认"客户数量"的标准口径定义。
4. 发现定义确实存在歧义（“是否包含已注销”），Steward 升级给 Data Owner。
5. Owner 在 48 小时内做出裁决：包含已注销，但在报表中单独标注。
6. Steward 更新术语表，Custodian 在数据仓库中调整口径逻辑。
7. 下一次报表自动采用新口径，问题闭环。

整个流程清晰、可追溯、有闭环。没有踢皮球，没有"拉会对齐"，没有"建议后续跟进"。

数据治理从来不是一蹴而就的项目，而是一个持续运转的机制。在这个机制中，三层角色矩阵是基石——它解决的不是"如何做好数据质量"这个技术问题，而是"谁来做、谁负责、谁兜底"这个组织问题。

把权责理清楚了，技术问题自然有人去解决。把组织问题悬在空中，再好的工具也只是摆设。