2、数据Owner的定义与角色：谁是数据Owner？——业务Owner、技术Owner、数据管理员的职责边界
好，咱们接着聊。上一章我们讲了数据Owner为什么重要，这一章就直击核心——到底谁是数据Owner？
这个问题，我在不少企业都遇到过。每次问下去，答案五花八门。有人说“IT管数据”，有人说“业务部门说了算”，还有人干脆说“老板是Owner”。嗯，其实都不全对。
数据Owner不是一个人，而是一个角色体系。说白了，就是三拨人：业务Owner、技术Owner、数据管理员。他们各管一摊，又互相配合。
核心观点：数据Owner不是“一个人”，而是“一个角色组合”。业务Owner拍板，技术Owner落地，数据管理员执行。缺一个，数据治理就转不起来。
2.1 业务Owner：数据的“老板”
业务Owner是谁？就是那个对数据内容负责的人。他决定“这个数据该怎么定义、谁可以用、用到什么程度”。
我举个例子。客户信息表，业务Owner应该是谁？销售总监？市场负责人？还是客服经理？
我个人习惯是：谁最依赖这个数据做决策，谁就是Owner。客户信息，销售总监最依赖，他拍板最合适。
业务Owner的核心职责，我列一下：
- 定义数据标准——比如“客户状态”字段，是“活跃/沉默/流失”还是“A/B/C类”？业务Owner说了算。
- 审批数据访问权限——谁能看、谁能改、谁能导出，业务Owner签字。
- 判定数据质量——数据准不准？业务Owner说了算，不是IT说了算。
- 处理数据争议——两个部门对同一数据口径有分歧，业务Owner拍板。
我的经验：业务Owner最好是个“能拍板的人”，不是挂名的。我曾经见过一个项目，业务Owner是部门副职，每次决策都要请示正职，结果数据治理进度拖了三个月。后来换了正职当Owner，效率翻倍。
2.2 技术Owner：数据的“管家”
技术Owner，就是那个负责“把业务需求变成技术实现”的人。他不管数据内容，只管数据怎么存、怎么跑、怎么保证不丢。
技术Owner通常是数据架构师、数据平台负责人，或者资深DBA。他的职责很明确：
- 设计数据存储方案——用MySQL还是HBase？分库分表怎么做？
- 保障数据安全——加密、备份、容灾，技术Owner兜底。
- 优化数据性能——查询慢？接口超时？技术Owner调优。
- 执行数据治理工具——数据血缘、元数据管理、质量监控，这些工具技术Owner来部署。
你想想看，业务Owner说“我要这个报表每天8点出”，技术Owner就得保证数据管道在7点59分跑完。这就是配合。
避坑指南：我曾经见过一个公司，技术Owner把数据权限全开放了，理由是“方便开发”。结果业务Owner发现销售数据被竞品部门看到了，差点闹到老板那里。记住：技术Owner只负责“怎么实现”，不负责“谁可以看”。权限审批是业务Owner的事。
2.3 数据管理员：数据的“执行者”
数据管理员，也叫数据 steward。他是具体干活的人。
业务Owner没时间天天盯着数据，技术Owner也不管数据内容。那日常的数据维护谁来做？数据管理员。
他的工作更接地气：
- 数据质量检查——每天跑质量规则，发现异常就上报。
- 元数据维护——字段描述更新、数据字典维护、血缘关系补充。
- 权限执行——业务Owner批了权限，数据管理员去配置。
- 问题跟踪——数据问题从发现到解决，数据管理员全程跟进。
数据管理员可以是业务部门的骨干，也可以是数据治理团队的成员。关键是：他得懂业务，也得懂一点技术。
一个真实的例子：我参与过一家零售企业的数据治理。他们的数据管理员是门店运营主管，每天检查“库存数据”是否准确。有一次他发现某个SKU的库存数据连续三天异常，追查下去，原来是仓库扫码枪坏了。业务Owner和技术Owner都没发现，数据管理员解决了。这就是执行者的价值。
2.4 三者的职责边界对比
光说概念还不够，咱们直接上表格。这样一看就清楚了：
| 职责维度 | 业务Owner | 技术Owner | 数据管理员 |
|---|---|---|---|
| 数据定义 | 拍板数据标准和口径 | 提供技术可行性建议 | 执行定义落地 |
| 数据质量 | 判定质量是否达标 | 搭建质量监控工具 | 日常检查与上报 |
| 数据安全 | 审批访问权限 | 实施加密与备份 | 配置权限策略 |
| 数据争议 | 最终裁决 | 提供数据支撑 | 记录争议过程 |
| 日常维护 | 不参与 | 保障系统稳定 | 执行维护操作 |
你看，三个角色各司其职，又互相依赖。业务Owner不拍板，技术Owner不知道往哪个方向做；技术Owner不搭好平台，数据管理员没法干活；数据管理员不执行，前面两个就是空中楼阁。
2.5 职责边界不清的后果
为什么会出问题？我总结了几种常见情况：
- 业务Owner缺位——数据标准没人定，各部门各搞一套，数据对不上。
- 技术Owner越位——技术Owner替业务Owner做决策，结果数据口径不符合业务实际。
- 数据管理员背锅——出了问题，业务和技术互相推，最后怪数据管理员没执行好。
我曾经在一个项目里，业务Owner和技术Owner吵了两个月，就为了“订单金额”这个字段要不要含税。业务说含，技术说不含。最后数据管理员夹在中间，数据质量报告都不敢出。后来我建议：业务Owner拍板含税，技术Owner执行，数据管理员更新元数据。三天解决。
我的建议：在项目启动时，就把这三个角色的职责边界写进《数据治理章程》里。白纸黑字，谁也别赖。我习惯用RACI矩阵来定义，清晰明了。
2.6 数据Owner体系结构图
下面这张图，把三者的关系画清楚了。你看一眼就明白：
2.7 如何落地？三步走
光知道概念还不够，得能落地。我建议分三步走：
- 第一步：盘点数据资产——把公司有哪些核心数据列出来，比如客户数据、产品数据、订单数据、财务数据。
- 第二步：指定Owner——每类数据，指定一个业务Owner、一个技术Owner、一个数据管理员。注意：业务Owner必须是业务部门的人，不能是IT。
- 第三步：明确职责并签字——把职责写清楚，让三个角色签字确认。我习惯用RACI矩阵，谁负责（R）、谁批准（A）、谁支持（S）、谁知情（I），一目了然。
一个成功的案例：我辅导过一家金融公司，他们按照这个三步走，三个月内把核心数据的Owner全部落实。半年后，数据质量问题下降了60%，跨部门数据争议减少了80%。业务Owner和技术Owner不再吵架，数据管理员也有了明确的汇报线。
好了，这一章的核心就是：数据Owner不是一个人，而是一个角色组合。业务Owner拍板，技术Owner落地，数据管理员执行。边界清晰，配合默契，数据治理才能跑起来。