基于项目的数据认责实施指引

1. 数据认责的定义

明确数据价值链上相关参与方及其职责，包括责任的认清（明确责任边界）和认领（对数据问题负责，尤其是数据质量问题）。

2. 数据认责的原因

数据的质量问题驱动数据认责，包括两个方面：

Ø 当前数据质量问题解决：需要确定明确的角色和个人/组织，来认领该责任；

Ø 数据质量的长期保障：为了保障数据质量的长期稳定，需要明确的负责角色和个人/组织。

3. 数据认责的基础

在开展数据认责之前，基于现有的业务和系统现状，绘制基于CRUD矩阵的数据流，客观描述数据如何在业务流程和系统中流动，并以此数据流图作为后续数据认责的基础。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

如上图所示，以客户数据为例，可以清晰地看到客户实体数据由市场销售业务环节产生（配合CRM系统），

后续在订单管理、生产、物流、开票等业务环节使用。通过该图，完成了核心数据实体与业务流程、业务系统、业务部门的映射，更加便于后续的数据认责。

4. 数据认责的原则

Ø 谁生产，谁负责

Ø 谁先生产，谁负责

Ø 责任主体限在企业内部

Ø 问题升级途径清晰

Ø 数据质量公示

5. 数据认责的要素

• 范围
  • 关键数据（对业务影响大）优先
• 粒度
  • 数据粒度：
    • 表级别：工作量较小，有问题的表-->系统-->部门-->责任岗位
    • 字段级别：需要逐个字段核对，工作量较大
    • 记录级别：难度更大！
  • 责任主体粒度：
    • 部门
    • 岗位
    • 人员
• 角色
  • 明确数据价值链的参与方的角色定位
  • 一般，包括录入者、维护者、开发者、使用者、所有者和管理者的6个角色
• 职责
  • 明确数据价值链的参与方的职责分工
  • 数据责任定义规范矩阵，参考下表：

 

 

 

 

 

 

 

 

 

 

 

 

 

  

 

• 机制
  • 确保数据认责常态化运转。数据认责管理办法及流程附件，详见另一个随笔：《基于项目的数据认责实施指引.docx》 
• 认责的维度
  • 业务流程/业务系统/业务部门/业务岗位 
• 认责的领域
  • 数据质量，数据治理的其他领域涉及较少
• 认责的工具
  • 功能工具：数据流图、认责矩阵、认责书
  • 工具载体：Excel，数据认责系统（多为定制化）
• 认责的实施方法
  • “先试点，再推广”（选择合适的业务部门或者数仓部门），确保可行性
• 认责的职责定义
  • 基本上采用“单一责任主体”的方式。争议少，责任明确
  • 责任明确到岗位，力争明确到具体的人。

6. 数据认责矩阵

数据认责矩阵是数据认责工作的重点和基础，数据认责矩阵将数据按照条件划分并映射到对应人员上，数据责任明确清晰。

数据认责矩阵是一个较大的工程，一般是放在集团/公司层面来做，但是如果公司的数据管理能力较弱，也可以基于项目层面来做试点，更有利于加以双方的项目交付，不过项目级别的数据认责需要公司CIO/CDO的强力支持，尤其协调各个业务部门和技术部门的配合，甚至是battle。下面具体剖析项目级别的数据认责矩阵的形成过程：

1） 形成：由数据管理部门牵头，协同业务部门、技术部门一起确定数据认责矩阵。一般认责矩阵需要多方、多次开会讨论确定并报备到CIO/CDO，并且有正式/非正式的协作流程。

2） 粒度：

a) 数据粒度：数据认责矩阵的粒度越细约好（比如记录级别），但是处于数据管理基础和工作量的考量，项目级别的数据认责矩阵的粒度可以确认为表和核心字段级别：针对一些业务/业务系统相对独立，可以直接以表为粒度；如果有业务流程的协作（比如同一条记录多部门多人维护），建议做到字段粒度的认责；针对“一数多源”的情况（客户数据可以从App，小程序，CRM等渠道录入），则需要每个渠道的数据都有认责，可以表/字段粒度；针对“一数多权”的情况（普通销售录入普通客户数据，高级销售录入大客户数据），建议做到数据集（表的一部分）/字段粒度。

b) 责任主体粒度：如下表的认责矩阵，主要解决的是数据项（字段）与角色岗位的映射关系，并没有到人。针对数据基础一般、基于项目范围来做认责（非公司级别），建议先做到岗位即可，工作量相对较小。可以根据公司的组织架构找认责矩阵中对应的责任人，然后根据上面的数据责任定义规范矩阵确认具体的职责范围。

数据领域	系统名称	数据对象	数据项	数据所有者	数据使用者	数据管理者	数据生产者	数据维护者	数据开发者
参与者	CRM	客户	客户电话	客户关系专员	营销业务专员	数据管理专员	客户关系专员	客户关系系统专员	数据开发专员

 

 

 

 

 

 

 

 

更加详细的责任主体粒度（比如 按照不同地区条件，确认不同的人员/岗位），不建议在项目级别的认责中完成，工作量太大，也不见得有好的成果。针对这种类型的数据，可以通过认责矩阵 + 人工确认 的方式来完成。

3） 生命周期：数据的生命周期涉及规划、创建、传输、加工、使用、归档和销毁的七个环节。在项目执行层面，这7个环节的框架搭建要全面，但具体执行可以裁剪，一般在项目上重点关注创建、加工和使用这三个角色。

4） 使用：数据认责矩阵是后续数据质量定责的依据，如果有数据质量问题，则通过该矩阵可以清楚地确认负责人是谁。此外，数据质量规则的定义也要依据护具认责矩阵找到对应的责任人。

5） 变更：针对内容变更，需要三方开会讨论后报备；针对人员的变更，需要将公司级数据管理员的角色添加到人员变更流程中，确保变更人员的数据管理角色有良好交接，交接妥当后修改数据认责矩阵。

6） 公开：数据认责矩阵报备且通过审批后，需要在公司内部公开发布，让数据认责的问题和绩效接受全公司的监督。

7） 争议：针对有争议的问题，则先经过数据管理办公室协商解决，解决不了的话，则升级到数据管理委员会。

7. 数据认责效果

项目级别的数据认责效果：

1） 业务方面：

数据质量提升，更加利于业务使用。尤其是源业务系统的数据质量提升（空值率、值域、乱码等基础的数据质量问题）

2） 管理方面：

a) 建立了基于数据认责流程的数据质量管理机制：发现问题 - 明确责任 - 改进问题 - 跟踪改进 - 标准化

b) 明确数据管理人员、业务人员、技术人员在数据管理工作中的职责分工及配合机制，有利于数据文化的建设和数据管理效率的提升

c) 展现数据质量治理的效果，为整个公司级数据治理打下一个良好的基础。

3） 技术方面：

在与业务有效互动的前提下，更能发挥技术在数据（质量）管理中的价值，提升技术服务业务能力

8. 数据认责问题

1） 元数据不完善：数据项没有业务含义 [逐一人工核对，与业务人员或业务系统供应商]

2） 自己员工的数据质量支撑不够：HR系统更新迟缓，或者旧老信息未删除等[以用促改]

3） 很多数据未线上化：暂时搁置，先做线上化数据的数据认责。

 

参考

DAMA专家陈韩霏先生的分享