半年后，团队负责人复盘时发现了一个尴尬的局面：告警数量在涨，但真正被修复的问题并没有同步增加。治理团队大量时间花在了"判断哪些告警值得处理"上，业务部门觉得这些告警和实际业务问题关系不大。一位业务主管的反馈很直白："我们知道数据有问题，但你们发的那个报表我们看不懂，也不知道这些问题对我们的业务到底有什么影响。"
这个场景引出了一个数据治理领域容易被忽视的问题：配了规则就等于做好了数据质量管理吗？
国家标准 DCMM 2.0（GB/T 36073-2025）[1] 给出了不同的视角。在其九大能力域中，数据质量域包含四个能力项：数据质量需求、数据质量检查、数据质量分析和数据质量提升。注意，"检查"只是四个环节之一。这意味着标准在意的不仅仅是"能否检测到问题"，更是"发现问题之后有没有一套持续改进的机制"。
一、当"发现问题"本身成了新的问题
在许多企业的数据治理实践中，质量管理的推进路径高度相似：选一个核心业务域 → 梳理数据资产 → 配置质检规则 → 产出问题报告。到这里为止，逻辑是通的。但问题的分岔出现在下一步——报告产出了，然后呢？
较为常见的情况是，规则越配越多，但闭环始终没建起来。具体表现为三种典型症状：
规则数量在涨，但实际被修复的问题没有同步增加。 规则从几十条扩展到几百条，每天产出的告警从几百条升到几千条，但真正被修复、被验证、被归档的问题占比很低。治理团队在"发现"这个环节投入了大量资源，但在"解决"这个环节上缺乏对等的投入。
治理团队变成了"告警分类员"。 当告警量超过一定规模，治理团队大量时间消耗在判断哪些告警值得处理上——优先级排序、影响范围评估、与业务部门反复沟通确认。这些工作有价值，但它们本质上是在弥补"问题管理流程缺失"带来的手动成本。
业务部门对质量告警逐渐麻木。 同类告警反复出现，每次处理后过一段时间又冒出来。业务部门最初的配合意愿在一次次的"反复"中被消耗——"反正都是那些问题，修了还会再出现"。
从 DCMM 2.0 的视角审视这种状态，实质上是把"数据质量检查"从数据质量域四个环节中孤立了出来——做了检查，没做需求定义、根因分析和流程提升。行业观察显示，大量企业数据质量项目因缺乏闭环管理机制而难以达到预期效果。这个判断的指向很明确：单点检测和闭环管理之间的差距，才是数据质量能力真正的分水岭。
二、DCMM 2.0 数据质量域到底在要求什么
DCMM 2.0（GB/T 36073-2025）在第 11 章专门定义了数据质量管理能力域，包含四个能力项。这四个能力项之间的顺序关系和逻辑关联，恰恰是理解"为什么不能只做检测"的关键。
| 能力项 | 核心问题 | 如果缺失会怎样 |
|---|---|---|
| 数据质量需求 | 什么算"好数据"？质量标准在哪？ | 没有统一的判断依据，每个系统各自定义，跨部门口径不一致 |
| 数据质量检查 | 数据是否符合既定标准？ | — |
| 数据质量分析 | 问题的根因是什么？影响范围多大？ | 同类问题反复出现，无法从源头根治 |
| 数据质量提升 | 怎么防止问题复现？流程怎么改进？ | 治理停留在发现-修复-再发现-再修复的循环中 |
DCMM 2.0 将这四个能力项放在同一个能力域中，不是偶然。它们构成了一条逻辑链：先定义标准，再检查合规性，然后分析问题根因，最后推动流程改进。 这是一条完整的质量管理链路，缺少任何一个环节，整个链条都会断裂。
从实践中观察，最容易出问题的两个断裂点分别位于"检查之后"和"分析之后"。检查之后——很多企业的质量工作到"出了报告"就停止了，缺少问题认领、责任指派和修复跟踪机制。分析之后——即使做了根因分析，也缺少将分析结论转化为流程改进动作的推力，导致同类问题在下一次业务操作中再次出现。
这可以类比为医疗场景：量体温只是诊断的起点，真正的治疗需要结合化验分析、开处方、用药、复查，以及根据疗效调整方案。量了体温但不开药，或者开了药但不复查——这个医疗过程是不完整的。
作为补充参照，GB/T 36344-2018《信息技术 数据质量评价指标》[2] 从数据本身的特性出发，定义了六个质量评价维度：规范性、完整性、准确性、一致性、时效性和可访问性。在制定数据质量需求（首个能力项）时，这个六维框架可以作为定义"好数据"标准的起点。
三、从检测到闭环：八个关键环节
DCMM 2.0 数据质量域的四个能力项提供了顶层框架，但落地到日常运营中，还需要更细颗粒度的操作步骤。从企业实践来看，较为有效的做法是将四环节展开为八个可操作的关键步骤：
标准定义 → 规则配置 → 评测 → 发现 → 认领 → 整改 → 复核 → 改进
这八个步骤环环相扣，以"改进"节点反馈到"标准定义"，形成持续优化的闭环。逐一来看每个步骤的定位：
标准定义是整个闭环的起点。它回答的是"什么是好数据"——哪个字段不能为空、哪个取值范围是合理的、哪些跨表数据需要保持一致。标准不是凭空制定的，需要基于业务规则、行业规范和监管要求来确立。行业实践中，业务规则的显式化定义也普遍被视为质量管理的首要步骤。
规则配置将标准转化为可自动执行的质检规则。这一步的关键在于让业务人员能够参与配置而非全部依赖 IT——业务部门对"什么是异常数据"有最直接的经验，但如果没有低门槛的配置工具，这个经验就无法转化为规则。
评测是运行质量扫描、生成问题报告的环节。采用旁路监测模式（数据正常入库，质量检查在旁路并行扫描）可以确保不阻断业务流程。DAMA-DMBOK2[3] 将数据质量评估分为初始评估和持续监测两类，评测环节承担的正是在不中断业务运行前提下的常态化监测职能。
发现将扫描结果提炼为可操作的问题项——不仅要标出"哪张表有异常"，还要精确到"哪个字段的哪些记录有问题"，标记字段级根因，为后续的认领和整改提供明确目标。
认领将问题推送到责任部门或责任人，明确整改期限。这一步在整个闭环中看似简单，却是最容易断裂的环节。如果问题没有明确的责任归属，前面的检测工作就全部悬空。
整改是对问题数据的实际修复。这一步经常是整个闭环中最脆弱的环节——涉及跨部门协同、业务系统操作权限和生产环境影响评估。如果整改动作长期未被跟踪和督促，闭环就是名义上的闭环。
复核在整改完成后自动复扫，确认问题确实被修复，而非被临时遮盖。这是对整改质量的验证，也是闭环"闭"起来的标志。
改进将高频问题归类，追溯系统性根因，反向优化质量规则和业务规范。例如，如果某类格式错误在三个月内出现了二十余次，不仅需要修复当前数据，还需要检查录入界面的校验逻辑是否缺失。
观察这八个步骤可以明显看到：检测（评测 + 发现）只是八步中的两步。后面的认领 → 整改 → 复核 → 改进才是质量闭环的核心价值所在。 单纯追求检测规则的覆盖率，而忽视闭环的完整性，从长期来看是投入产出比不高的做法。
市场上已有部分数据治理平台将这八个环节整合为可在线流转的闭环体系。以龙石数据质量管理平台为例，它将标准管理、规则配置、质量评测、问题分析和整改闭环串联在同一系统中——从标准到规则、从规则到扫描、从扫描到工单、从工单到复验归档，每一步都在同一平台上完成，避免了"系统A发现问题→线下沟通→系统B处理"的信息断裂。
四、以华东某电子制造企业为例
闭环的价值，在实际业务场景中看得更清楚。
华东一家中大型电子制造企业，日常运转依赖 ERP、MES、WMS 等多个业务系统。随着业务规模扩大，三个环节的数据问题逐步暴露：一是跨部门协同——同一个物料在研发、采购、仓库三个部门的系统中有不同的编码和名称，每次跨部门对账都是一场"翻译"；二是经营指标口径——财务和运营部门对"产值"的计算逻辑不同，月度经营会上管理层经常要先确认"以哪个数字为准"；三是报表周期——经营分析报表依赖人工从多个系统取数、手工汇总，一个完整的月度报告需要数天时间。
从数据层面看，根因集中在三个方向：主数据缺少统一编码和管理机制、数据标准缺失、以及数据质量问题缺乏闭环——业务人员虽然经常发现数据错误，但缺乏系统化的规则配置和问题追踪机制，同类问题反复出现。
企业在明确方向后，分四个阶段推进数据治理建设：
第一阶段：摸清家底。 从物料、客户、供应商等核心业务对象入手，逐一盘点各系统中的存量数据，识别重复、缺失和不一致问题。这一阶段产出了一份完整的数据质量评估报告，让管理层第一次看清了数据治理的起点在哪里。
第二阶段：建标准、立规则。 统一了多类核心主数据对象的编码规则，制定了数十项校验规则，明确了数据录入、审核和维护的权责边界。
第三阶段：系统对接与质量治理。 将核心业务系统的数据接入统一数据底座，配置质量检核规则，对已识别的百万级物料数据进行清洗去重。
第四阶段：服务化落地。 建设经营指标看板和数据服务门户，覆盖多个业务部门。在这个阶段，数据质量的闭环机制初步成型——系统自动扫描质量问题，定位责任部门，生成整改工单，修复后自动复验。
闭环带来的效果是直接的：核心物料数据重复率大幅压降，采购、生产和财务终于用上了"同一本账"；经营报表的生成周期从数天压缩到小时级；跨部门数据口径差异基本消除。更重要的变化在组织层面——各部门开始主动关注数据质量，不再把"数据不准"当作别人的问题。
这个案例的一个关键启示在于：质量规则要配闭环。发现数据问题不是终点——配置规则、自动检核、推动责任部门整改、跟踪处理结果，这个闭环跑通了，数据质量才能持续改善。企业最初面临的问题并非"检测不到问题"，而是"检测到了问题却没有有效的处理机制"。
五、从"能做到"到"能持续"
DCMM 2.0 的五级成熟度模型为质量闭环的推进提供了一个清晰的进阶参照。
在 L2"受管理级"，数据质量管理通常在部门层面推进，规则是配了，但修复主要靠人工协调和催促。在 L3"稳健级"，组织建立了统一的质量管理体系，问题能被系统地发现和记录，修复有流程支撑。在 L4"量化管理级"，闭环数据可量化——平均修复时长、问题复发率、规则有效覆盖率等指标成为衡量质量能力的关键参数，标准要求在此阶段"引入人工智能等先进技术"[1] 驱动效能提升。
从大多数企业的实际情况来看，较为稳妥的做法是先从核心业务域做起。选三五个最痛的数据表，配十几条核心规则，把"发现 → 认领 → 整改 → 复核"的闭环先跑通，再根据运行数据逐步扩展覆盖范围和改进节奏。这种方式投入可控、见效快，也更容易获得业务部门的认可和支持。
对于那些希望先摸清数据质量现状再决定投入规模的企业，市场上已有免费可用的数据质量工具。例如，龙石数据质量管理平台·社区版覆盖了 GB/T 36344 标准定义的核心评价维度，支持空值检查、唯一性检查、值域检查、一致性检查等十余类质检规则，可以通过一次快速的部署获得一份系统化的数据质量体检报告。
截至 2025 年 11 月，全国已有超过一万家企业完成了 DCMM 贯标评估[4]。在贯标实践中，数据质量域往往是差距最大的能力域之一——不是因为企业没有质量规则，而是因为规则和闭环之间仍然存在断裂。从"能做到检测"到"能持续改进"，这一步的距离，正是 DCMM 2.0 数据质量域的核心关切所在。
六、FAQ
Q1：我们已经有几百条质量规则了，为什么 DCMM 评估还是说我们的质量域不够？
DCMM 2.0 的评估看的不只是规则数量，而是质量管理的闭环机制。数据质量域的四个能力项——质量需求、质量检查、质量分析、质量提升——需要每个环节都有可验证的证据链支撑。有规则但缺少需求定义文件、有问题记录但缺少根因分析和提升记录、有整改但缺少复核验证，这些都会影响评估得分。换句话说，评估关注的是"管理"而非"工具"。
Q2：旁路监测会不会导致问题数据已经流入下游才被发现？
旁路监测的执行延迟取决于数据量、调度频率和数据库性能，可根据业务时效要求配置执行频率。对于时效性要求极高的场景，可以在关键链路上配合前置强校验。在实际部署中，大多数企业场景下旁路监测的延迟在可接受范围内——质检结果在下一次调度周期（通常为数分钟到数十分钟）即可产出，不影响正常的业务数据流转。
Q3：闭环管理需要多大的组织投入？
闭环的核心是责任机制，不是人力投入。关键是把三步跑通：问题能推送到具体责任人、整改有明确期限、修复后有复验确认。在平台支撑下，不一定需要新设独立的数据质量团队——但必须明确质量负责人、数据责任人和整改流程。从组织角度来看，把质量责任嵌入现有的数据管理和业务操作流程中，比新建一个专职团队更为可持续。
参考来源
[1] 国家市场监督管理总局、国家标准化管理委员会，《GB/T 36073-2025 数据管理能力成熟度评估模型》（DCMM 2.0），2026年7月1日实施
[2] 国家市场监督管理总局、国家标准化管理委员会，《GB/T 36344-2018 信息技术 数据质量评价指标》
[3] DAMA International,《DAMA数据管理知识体系指南（第二版）》(DAMA-DMBOK2)
[4] 中国电子信息行业联合会，DCMM 贯标统计数据，第四届数据治理年会（2025年11月）
