2005 年，我在一家小型公用事业公司做咨询，该公司在数据迁移之前实施数据质量评估项目。我让大家都在一个房间里，开个简单的信息链研讨会，在白板上贴上一大堆便利贴来绘制对团队而言重要的人员、流程和数据链。我们详细讨论了人们从数据中看到的问题。大家都很高兴，但有一个人很安静。所以我问他们都做了什么。结果得知，这个人的职责是从一个主要的外部数据供应商那里获取相同的数据，保存到我们的数据库中，每月都要来一次。每个月，他们都坐在电脑前，费力地手动修复数据缺陷。更重要的是，他们必须一次又一次地修复相同类型的缺陷。好在他们有某种“数据质量防火墙”来防止有质量问题的数据入库，但他们采用的方法存在明显缺陷：
- 公司并不直接拒绝供应商，而要求供应商签订数据质量服务水平协议 (SLA)。是的，这可能是一个挑战，但在这种情况下，他们并没有想方设法拒绝质量不佳的数据。
- 这个人脑中有大量没有形成文档的知识，而且情绪不高。他有很高的流失风险，如果他辞职了，显然对公司来说是一个很大风险。
- 以数据质量的名义一遍又一遍地重复做事情只是不好的做法（而且成本非常高）。
- 数据清理的前置时间，意味着下游消费者的大量成本。
那么他们做对了什么？
- 有人负责这个“防火墙”（是的，尽管这是一个搞砸的过程，但至少有人负责）
- 这些人很敬业（根据下游用户的说法，到现在没有什么不好的事情发生）
- 他们在源头采集数据（在准备好之前没有任何东西从他们身边溜过）
事实是，许多组织都是通过以下错误的方式建立了和数据供应商之间关系：
- 假设供应商数据将具有“足够好”的质量，因为他们有供应合同约束
- 在下游应用手动修改和调整数据（供应商应承担的成本）
- 在入口点安排专门的人员或团队（而不是建立自动化和数据质量监控来释放劳动力并将缺陷推回供应商）
令人难以置信的是，我遇到的太多公司都接受来自公司墙外的数据并假设它是正确的，或者认可“缺陷是现实存在的，我们可以忍受它们”。
千万不要做这样的假设。
采用以下步骤作为入门指南，采取积极主动的立场扭转局面。
数据质量防火墙和 SLA 的简单路线图
在创建数据质量防火墙和 SLA 时，您可能会发现以下策略很有价值。映射从供应商到消费者的信息流流入组织的所有信息源都要做好映射。如果没有购买昂贵建模工具的预算，一包便利贴就足以支持一个建模研讨会。确定存在哪些数据规范（并增补缺失的地方）当信息来自外部数据源时，确定是否存在以下信息：
- 正式的数据规范（例如字段格式、交付频率、预期值、允许范围）
- 发现缺陷时的升级程序或标准操作流程
没有规范、文档或流程信息吗？那就创建包含上述内容的新文档，但别忘记添加：
- 简单的信息链图，解释这些信息的来源和流向
- 在供应商和消费者两方，与此数据相关的联系人姓名和联系方式
展示在数据质量方面的发现和建议将此提交给利益相关者，说明希望改进此入站信息源，以便：
- 当不良数据影响其他业务部门时，防止利益相关者感到尴尬
- 减少没完没了构建消除废品和返工活动流程所节省的成本（基于过去事件的成本在这里是理想的）
- 提高利益相关者团队作为高度专业、创新资源的整体认知能力（他们会喜欢这个）
- 缩短交货时间并改进利益相关者负责的各种其他指标
- 让他们确认，他们需要最终对该流程负责，将向其定期提供有关流程如何工作以及为业务带来价值的报告
推荐试点数据质量管理计划：
记录与这些流入数据源有关的所有已知问题、调查以及与数据工作者、DBA、应用程序设计人员以及下游接触此数据的任何其他人的对话信息，借助这些信息，有助于创建强大的数据质量评估流程：
- 使用现在可用的许多免费（或商业）工具来剖析数据
- 严格记录认为应该管理数据的数据质量规则，例如
及时性——数据必须在每个工作日早上 9 点到 10 点之间到达
完整性——必须填写客户姓名和地址字段，必须有有效的订单号等。
格式——如订单号必须是 NN-LLLL-NN 格式，不允许例外
重载——每条记录的零件编号只能有一个，同一字段中不能有多个零件编号
等等…。
- 将这些数据质量规则转换为实时监控过程，例如：使用各种可用的数据质量和数据集成工具，使用 SQL 或 Unix 中的标准脚本，或任何数据处理平台使用的脚本
- 实施流程并开始跟踪发现的问题
查看数据缺陷的影响，并向数据供应商要求更可靠的“数据质量 SLA”
- 运行此过程至少一个月，发现问题并在适用的情况下手动修复
- 创建一个包含所有已知问题及其对组织产生的影响的评估文件
- 与数据供应商联系，概述您的发现、所做的创新以及遇到的问题
- 如果不存在关于数据质量的 SLA 或正式定义和协议，请与利益相关者和供应商合作，以达成一致
- 同意与供应商分享您的技术和方法，以便他们提高数据质量（也有可能将其提供给其他公司）
- 协同工作以迭代方式创建最强大的数据质量防火墙和 SLA 流程
数据质量 SLA 的示例请注意，以下信息仅作为介绍性指南提供，不给予评判，不作为法律建议，在创建法律文件时要记得始终寻求专业帮助。网络上有数百个 SLA 模板，但下面这个示例有助于说明如何将SLA应用于数据质量：1. 简介本服务水平协议 (SLA) 记录了 [供应商] 向 [接收方] 提供数据的约定服务条款。本文件提供了一份具有法律约束力的合同，规定了双方在服务协议期限内将执行的服务和质量水平。2. 协议各方列出已审核并批准 SLA 的人员。3. 范围要提供的数据和服务的高级概述。4. 期限指明 SLA 的开始和结束日期。5. 约定列出整个 SLA 中引用的所有标准、术语和定义。例如：
- “办公时间”是指格林威治标准时间上午 9 点至下午 5 点。
- “工作日”是指周一至周五，指定节假日除外。
- “CSV”是指采用“逗号分隔”，用在开放标准中描述原始文本的文件格式：http: //mastpoint.curzonnassau.com/csv-1203/csv-1203.pdf
- 等等…
6. 服务水平
- 数据交付时间表：说明应提供数据的频率，例如格林威治标准时间上午 9 点至上午 10 点之间的每个工作日。
- 数据交付规范：数据将如何构建？哪些字段必须是必填项？存在哪些标准数据类型？必须遵守什么 CSV 标准？必须遵守哪些标识符和代码标准？数据如何加密，例如 zip 文件？属性 A、B、C、…、n 的数据标准和规范是什么？
- 数据交付流程：概述数据交付所需步骤的高级图表。
- 问题升级流程：当发现问题时，将如何通知供应商，对他们的期望是什么？
7. 服务水平目标和处罚措施描述每个服务级别、衡量标准和目标。例如：
- 衡量标准：及时性
- 描述：必须在批准的数据交付时间表内提供数据
- 目标：95% 每年在批准的数据交付计划内交付，97% 在批准的数据交付计划内 + 30 分钟，100% 在批准的数据交付计划内 + 60 分钟
- 罚则：每延迟 60 分钟，罚款 10 英镑。过去 60 分钟延误每小时 1000 英镑。
8. 奖励概述供应商为满足其 SLA 目标而获得的任何奖励结构。9. 联系信息双方参与服务的关键人员名单。10. 签名使协议具有约束力的授权签名列表。11. 附录、词汇表和参考文献提供其他资源，例如示例文件摘录、详细词汇表以及与 SLA 相关的其他标准和外部信息的链接。
译者简介：马欢：DAMA 会员，DAMA数据管理专家，《DMBOK数据管理知识体系（第1&2版）》中文版主译者，项目管理师，系统分析师，架构师，PMP，CDMP。