读DAMA数据管理知识体系指南41数据质量活动

1. 定义高质量数据

1.1. 高质量的数据能满足数据消费者的需要
1.2. 在启动数据质量方案之前，有益的做法是了解业务需求、定义术语、识别组织的痛点，并开始就数据质量改进的驱动因素和优先事项达成共识
1.3. 了解业务战略和目标
1.4. 与利益相关方面谈，以识别痛点、风险和业务驱动因素
1.5. 通过资料收集和其他剖析形式直接评估数据
1.6. 记录业务流程中的数据依赖关系
1.7. 记录业务流程的技术架构和系统支持
2. 定义数据质量战略

2.1. 提高数据质量要有一定的战略，应考虑到需要完成的工作以及人们执行这些工作的方式
2.2. 数据质量优先级必须与业务战略一致
2.3. 了解并优先考虑业务需求
2.4. 确定满足业务需求的关键数据
2.5. 根据业务需求定义业务规则和数据质量标准
2.6. 根据预期评估数据
2.7. 分享调查结果，并从利益相关方那里获得反馈
2.8. 优先处理和管理问题
2.9. 确定并优先考虑改进机会
2.10. 测量、监控和报告数据质量
2.11. 管理通过数据质量流程生成的元数据
2.12. 将数据质量控制集成到业务和技术流程中
2.13. 数据质量工作和对高质量数据的承诺需要嵌入组织实践
3. 识别关键数据和业务规则

3.1. 并非所有的数据都同等重
3.2. 数据质量管理工作应首先关注组织中最重要的数据

• 3.2.1. 如果数据质量更高，将为组织及其客户提供更多的价值
  
• 3.2.2. 可以根据监管要求、财务价值和对客户的直接影响等因素对数据进行优先级排序
  

3.3. 数据质量改进工作从主数据开始，根据定义，主数据是任何组织中最重要的数据之一
3.4. 识别能描述或暗示有关数据质量特征要求的业务规则

• 3.4.1. 大多数业务规则都与如何收集或创建数据相关，但数据质量度量则围绕数据是否被适当使用进行
  
• 3.4.2. 数据创建和数据使用是相关的，人们之所以想使用数据，正是因为它代表的含义以及数据创建
  

3.5. 知道数据的所有使用方法是不可能的，但可以理解创建或收集数据的过程和规则
3.6. 完整性规则反映了字段是强制的还是可选的，如果是可选的，还反映了填充字段的条件
3.7. 有效性规则依赖于规定有效值的域以及在某些情况下字段之间的关系
3.8. 因为大多数人不习惯用规则来思考数据，故定义数据质量规则具有很大挑战性

• 3.8.1. 为了评估数据，不需要一次了解所有规则
  
• 3.8.2. 发现和完善规则是一个持续的过程，获得规则的最好方法之一是分享评估结果，这些结果通常会让利益相关方对数据有一个新的视角，告诉他们想知道的数据信息，帮助他们更清晰地阐明规则
  

4. 执行初始数据质量评估

4.1. 一旦确定最关键的业务需求和支持它们的数据，数据质量评估的最重要部分就是实际查看数据、查询数据，以了解数据内容和关系，以及将实际数据与规则和期望进行比较
4.2. 初始数据质量评估的目标是了解数据，以便定义可操作的改进计划
4.3. 最好从聚焦一项较小工作开始——一个基本的概念证明(Proof of Concept, POC)——来演示改进过程是如何工作的
4.4. 步骤

• 4.4.1. 定义评估的目标
  
  
  
  • 4.4.1.1. 这些目标将推动工作进展
    
  
  
• 4.4.2. 确定要评估的数据
  
  
  
  • 4.4.2.1. 重点应放在一个小的数据集，甚至一个数据元素，或一个特定的数据质量问题上
    
  
  
• 4.4.3. 识别数据的用途和数据的使用者
  
• 4.4.4. 利用待评估的数据识别已知风险，包括数据问题对组织过程的潜在影响
  
• 4.4.5. 根据已知和建议的规则检查数据
  
• 4.4.6. 记录不一致的级别和问题类型
  
• 4.4.7. 根据初步发现进行额外的深入分析，以便
  
  
  
  • 4.4.7.1. 量化结果
    
  • 4.4.7.2. 根据业务影响优化问题
    
  • 4.4.7.3. 提出关于数据问题根本原因的假设
    
  
  
• 4.4.8. 与数据管理专员、领域专家和数据消费者会面，确认问题和优先级
  
• 4.4.9. 使用调查结果作为规划的基础
  
  
  
  • 4.4.9.1. 解决问题，最好是找到问题的根本原因
    
  • 4.4.9.2. 控制和改进处理流程，以防止问题重复发生
    
  • 4.4.9.3. 持续控制和汇报
    
  
  

5. 识别改进方向并确定优先排序

5.1. 需要识别潜在的改进措施，并确定其优先顺序
5.2. 执行全面的数据剖析和分析的步骤基本上与执行小规模评估的步骤相同：定义目标、了解数据使用和风险，根据规则衡量、记录并与领域专家确认结果，利用这些信息确定补救和改进工作的优先级
5.3. 剖析数据只是分析数据质量问题的第一步

• 5.3.1. 它有助于识别问题，但无法确定问题的根本原因，也无法确定问题对业务流程的影响
  
• 5.3.2. 确定影响需要数据链上的利益相关方的介入
  

6. 定义数据质量改进目标

6.1. 初步评估获得的知识为特定的数据质量提升目标奠定了基础
6.2. 数据质量提升可以采取不同的形式，从简单的补救（如纠正记录中的错误）到根本原因的改进
6.3. 许多事情都会阻碍改进工作：系统限制、数据龄期、正在进行的使用有问题数据的项目、数据环境的总体复杂性、文化变革阻力
6.4. 价值来自改进的好处：减少客户投诉、减少纠正错误的时间等，通过测量这些东西来解释改进工作的价值
6.5. 当发现问题时，根据以下内容确定改进的投资回报率

• 6.5.1. 受影响数据的关键性（重要性排序）​
  
• 6.5.2. 受影响的数据量
  
• 6.5.3. 数据的龄期
  
• 6.5.4. 受问题影响的业务流程数量和类型
  
• 6.5.5. 受问题影响的消费者、客户、供应商或员工数量
  
• 6.5.6. 与问题相关的风险
  
• 6.5.7. 纠正根本原因的成本
  
• 6.5.8. 潜在的工作成本
  

7. 开发和部署数据质量操作

7.1. 从通过数据质量评估结果确定的一组改进项目开始的
7.2. 管理数据质量规则

• 7.2.1. 剖析和分析数据的过程将帮助组织发现（或反向工程）业务和数据质量规则
  
• 7.2.2. 预先定义规则
  
  
  
  • 7.2.2.1. 对数据质量特征设定明确的期望
    
  • 7.2.2.2. 提供防止引入数据问题的系统编辑和控制要求
    
  • 7.2.2.3. 向供应商和其他外部方提供数据质量要求
    
  • 7.2.2.4. 为正在进行的数据质量测量和报告创建基础
    
  
  
• 7.2.3. 规则
  
  
  
  • 7.2.3.1. 记录的一致性
    

    7.2.3.1.1. 建立记录规则的标准和模板，使其具有一致的格式和含义
    

    
    
  • 7.2.3.2. 根据数据质量维度定义
    

    7.2.3.2.1. 质量维度帮助人们了解正在测量的内容
    

    7.2.3.2.2. 维度的一致应用将有助于度量和管理问题的过程
    

    
    
  • 7.2.3.3. 与业务影响挂钩
    

    7.2.3.3.1. 虽然数据质量维度能够帮助理解常见问题，但它们本身并不是目标
    

    7.2.3.3.2. 标准和规则应该与它们对组织成功的影响直接相关
    

    7.2.3.3.3. 不应采取与业务流程无关的度量
    

    
    
  • 7.2.3.4. 数据分析支持
    

    7.2.3.4.1. 数据质量分析人员不应猜测规则，而应根据实际数据测试规则
    

    
    
  • 7.2.3.5. 由领域专家确认
    

    7.2.3.5.1. 规则的目标是描述数据的形态
    

    7.2.3.5.2. 需要通过组织过程的知识确认规则正确地描述了数据
    

    7.2.3.5.3. 当主题专家确认或解释数据分析的结果时，知识就产生了
    

    
    
  • 7.2.3.6. 所有数据消费者都可以访问
    

    7.2.3.6.1. 所有数据消费者都应该能够访问记录的规则，这样既可以让他们更好地理解数据，同时也有助于确保规则正确和完整，确保使用者能够就规则提出问题并提供反馈
    

    
    
  
  

7.3. 测量和监控数据质量

• 7.3.1. 向数据消费者通报质量水平
  
• 7.3.2. 管理业务或技术流程，改变引入的变更风险
  
• 7.3.3. 应将从过去的问题中获得的知识应用于风险管理
  
  
  
  • 7.3.3.1. 与风险管理相关的度量应该集中在过去出错的关系以及将来可能出错的关系上
    
  
  
• 7.3.4. 数据质量规则为数据质量的操作管理提供了基础
  
  
  
  • 7.3.4.1. 无论是通过现成的商业成品组件(COTS)数据质量工具、用于监视和报告的规则引擎和报告工具，还是自定义开发的应用程序，均可以将规则集成到应用程序服务或数据服务中，以补充数据生命周期
    
  
  

7.4. 制定管理数据问题的操作过程

• 7.4.1. 诊断问题
  
  
  
  • 7.4.1.1. 目的是审查数据质量事件的症状，跟踪相关数据的血缘，确定问题及其来源，并查明问题的根本原因
    
  • 7.4.1.2. 在适当的信息处理流程下查看数据问题，并隔离出现缺陷过程的位置
    
  • 7.4.1.3. 评估是否存在任何可能导致错误的环境变化
    
  • 7.4.1.4. 评估是否有其他过程问题导致了数据质量事件
    
  • 7.4.1.5. 确定外部数据是否存在影响数据质量的问题
    
  
  
• 7.4.2. 制订补救方案
  
  
  
  • 7.4.2.1. 纠正非技术性根本原因，如缺乏培训、缺乏领导支持、责任和所有权不明确等
    
  • 7.4.2.2. 修改系统以消除技术类的根本原因
    
  • 7.4.2.3. 制定控制措施以防止问题发生
    
  • 7.4.2.4. 引入额外的检查和监测
    
  • 7.4.2.5. 直接修正有缺陷的数据
    
  • 7.4.2.6. 基于变更的成本和影响对比更正后的数据的价值分析，不采取任何操作
    
  
  
• 7.4.3. 解决问题
  
  
  
  • 7.4.3.1. 评估替代方案的相对成本和优点
    
  • 7.4.3.2. 推荐计划中的一个备选方案
    
  • 7.4.3.3. 提供开发和实施该解决方案的计划
    
  • 7.4.3.4. 实施该解决方案
    
  • 7.4.3.5. 事件跟踪系统将收集与解决问题、分配工作、问题数量、发生频率，以及做出响应、给出诊断、计划解决方案和解决问题所需时间相关的性能数据
    
  • 7.4.3.6. 事件跟踪数据也可以帮助数据消费者
    
  • 7.4.3.7. 标准化数据质量问题和活动
    

    7.4.3.7.1. 由于不同行业描述数据问题的术语可能千差万别，因此为所用的概念定义标准词汇表非常重要
    

    
    
  • 7.4.3.8. 提供数据问题的分配过程
    

    7.4.3.8.1. 操作过程指导分析人员将数据质量事件分配给个人进行诊断，并提供解决方案
    

    
    
  • 7.4.3.9. 管理问题升级过程
    

    7.4.3.9.1. 数据质量问题处理需要根据问题的影响、持续时间或紧急程度制定明确的升级机制，明确规定数据质量服务级别协议(SLA)中的升级顺序
    

    
    
  • 7.4.3.10. 管理数据质量解决方案工作流
    

    7.4.3.10.1. 数据质量服务水平协议(SLA)规定了监控、控制和解决的目标，所有这些定义了操作工作流的集合
    

    
    
  
  

7.5. 制定数据质量服务水平协议

• 7.5.1. 数据质量服务水平协议(SLA)规定了组织对每个系统中数据质量问题进行响应和补救的期望
  
• 7.5.2. 协议涵盖的数据元素
  
• 7.5.3. 与数据缺陷相关的业务影响
  
• 7.5.4. 与每个数据元素相关的数据质量指标
  
• 7.5.5. 从每个已确定指标的数据元素出发，识别数据价值链上每个应用程序系统中的质量期望
  
• 7.5.6. 测量这些期望的方法
  
• 7.5.7. 每次测量的可接受性阈值
  
• 7.5.8. 如果不满足可接受性阈值，应通知数据管理专员
  
• 7.5.9. 预期解决或补救问题的时间和截止日期
  
• 7.5.10. 升级策略，以及可能的奖励和惩罚
  
• 7.5.11. 数据管理专员和业务数据质量人员在维护数据质量服务水平的同时，应考虑其数据质量SLA限制，并将数据质量与个人绩效计划联系起来
  
• 7.5.12. SLA报告可以根据业务和运营需求按计划进行
  
  
  
  • 7.5.12.1. 特别关注的是报告趋势分析，如果在SLA框架中构建了此类概念，则重点定期关注奖励和惩罚
    
  
  

7.6. 编写数据质量报告

• 7.6.1. 数据质量评分卡
  
  
  
  • 7.6.1.1. 可从高级别的视角提供与各种指标相关的分数，并在既定的阈值内向组织的不同层级报告
    
  
  
• 7.6.2. 数据质量趋势
  
  
  
  • 7.6.2.1. 随时间显示数据质量是怎样被测量的，以及数据质量趋势是向上还是向下
    
  
  
• 7.6.3. 服务水平协议(SLA)指标
  
• 7.6.4. 数据质量问题管理
  
  
  
  • 7.6.4.1. 监控问题和解决方案的状态
    
  
  
• 7.6.5. 数据质量团队与治理政策的一致性
  
• 7.6.6. IT和业务团队对数据质量政策的一致性
  
• 7.6.7. 改善项目带来的积极影响
  
• 7.6.8. 报告应尽可能与数据质量SLA中的指标保持一致，以便团队的目标与客户的目标保持一致
  
• 7.6.9. 数据质量方案还应报告改进项目带来的积极影响，最佳的做法是持续地提醒组织数据为客户带来的直接影响
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！