数据质量框架失效的七个迹象

大多数组织都拥有某种版本的数据质量框架。但真正行之有效的却寥寥无几。从拥有框架到拥有有效运行的框架之间存在着巨大的差距，而且这种差距往往在悄无声息中扩大——源于逐渐的忽视、累积的技术债务，以及因无人专门负责而导致责任感的慢慢侵蚀。

以下是数据质量框架失效的七个迹象，以及每个迹象所揭示的根本问题。

1. 您的质量指标显示正常，但业务投诉不断

这是最常见的模式，也最具诊断意义。数据质量仪表板在完整性、准确性和及时性维度上显示出可接受或良好的评分。与此同时，业务分析团队经常标记数据问题，分析师在使用数据之前需要花费大量时间进行清洗，并且报告偶尔会发布与现实不符的数据。

当存在这种差距时，说明框架衡量的内容错误，或者衡量的粒度层级不当。例如，技术完整性指标仅确认字段已填充。它们无法确认值是否正确、是否使用一致的逻辑进行填充，或在不同系统中是否具有相同的含义。

解决方法是从实际的业务痛点反向推导。记录最近造成业务影响的数据质量失败案例。询问如果当时存在某项指标，它能否捕捉到每次失败。基于该列表构建您的测量框架，而不是基于通用的数据质量模型。

当出现数据质量问题时，会发生什么情况？如果答案涉及一段调查期以确定数据所属领域，随后就是关于该问题是源系统问题还是转换问题的协商，最后由某人提交一个在队列中积压的工单，那么该框架就存在责任缺失。

质量框架需要明确的所有权。这不是RACI 文档中列出的名义所有权，而是运营所有权：即指定专人对定义的数据集承担明确责任，拥有采取纠正措施的权力，并拥有当问题超出其范围时的明确升级流程。

如果您的框架缺乏这一点，质量问题将被发现、讨论，但得不到充分解决。同类问题将反复出现，因为没有人负责防止其复发。

许多组织已投资于运行自动检查并生成异常报告的数据质量工具。检查确实在运行。异常不断累积。报告要么无人阅读，要么由某人确认后便置之不理。

自动化质量检查是流程的输入，而非流程本身。它们需要一个具有明确响应阈值的人工审查循环：异常率超过 X 触发调查，重复出现的异常触发根本原因分析，系统性故障触发向数据治理团队的升级。如果没有这个循环，您只是在生成关于质量问题的日益准确的数据，却未采取任何行动。

审查当前质量工具中未处理异常的体积。如果数量庞大，说明框架在检测与解决之间存在流程缺口。

数据质量标准应反映使用

免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。