在一次数据治理平台选型评审会上，三家厂商都展示了“数据质量管理能力”。第一家强调内置规则数量，第二家展示了质量报表，第三家重点介绍告警看板。听起来都不错，但治理经理真正关心的问题并没有得到完全回应：这些规则从哪来？能不能对应企业的数据标准？发现问题后能不能定位到源系统、源表、字段？责任部门怎么修？修完后是否自动复验？
这正是数据质量平台评估中最常见的误区：把质量规则数量当成质量管理能力。
真正的数据质量管理，不能只停留在检查层面。它应覆盖质量定义、规则配置、质量监测、问题定位、责任修复、复验归档和持续运营。否则，规则越多，可能只是告警越多，治理团队反而增加了新的人工处理负担。
因此，评估数据治理平台的数据质量能力，需要一套更完整的模型。本文采用“双框架”思路：用 DCMM 2.0 看数据质量管理能力，用 GB/T 36344-2018 看数据质量评价指标，再把两者落到平台能力检查项上。
二、标准锚定：DCMM 管能力，GB/T 36344 管指标
DCMM 2.0（GB/T 36073-2025）关注的是企业数据管理能力成熟度。它从企业级管理视角考察数据战略、治理、架构、资产、标准、质量、安全、生存周期和应用流通等能力域。对于数据质量而言，DCMM 更关注企业是否建立了质量管理机制，是否能持续发现、分析、改进数据质量问题。
GB/T 36344-2018《信息技术 数据质量评价指标》则更偏指标层。它定义了数据质量评价的六个维度：规范性、完整性、准确性、一致性、时效性和可访问性。
这两套框架不应混为一谈。更合理的使用方式是：用 DCMM 看管理流程是否成熟，用 GB/T 36344 看质量评价是否全面。
| GB/T 36344 维度 | 评估含义 | 平台检查点 |
|---|---|---|
| 规范性 | 是否符合字段、格式、代码规则 | 数据标准、代码集、格式校验 |
| 完整性 | 关键字段是否缺失 | 非空规则、缺失率报告 |
| 准确性 | 数据是否真实、合理 | 业务规则、交叉校验 |
| 一致性 | 跨系统同一对象是否一致 | 主数据、映射关系、重复识别 |
| 时效性 | 数据是否及时更新 | 采集频率、延迟监测 |
| 可访问性 | 授权用户是否能获取 | 权限、目录、API 可用性 |
需要特别注意的是，GB/T 36344 是六个维度。在讨论 AI 或业务分析场景时，可以说“六个维度中，除可访问性外，其余五个直接影响分析结果的可信度”，但不能把标准简化成“五个维度”。
三、提出评估模型：六维指标 × 六段流程
基于上述标准，可以把数据治理平台的质量能力拆成“六维指标 × 六段流程”。
六维指标回答“查什么”。也就是规范性、完整性、准确性、一致性、时效性、可访问性是否都能被覆盖。
六段流程回答“怎么管”。它包括定义、配置、监测、定位、修复和复验。
| 流程 | 关键问题 | 平台能力 |
|---|---|---|
| 定义 | 什么算好数据？ | 数据标准、数据元、业务规则 |
| 配置 | 谁来配规则？ | 可视化规则、业务参与 |
| 监测 | 如何发现问题？ | 旁路监测、定时扫描 |
| 定位 | 问题在哪里？ | 元数据、血缘、源表字段 |
| 修复 | 谁负责处理？ | 工单、责任人、期限 |
| 复验 | 是否真的修好？ | 自动复扫、趋势报告 |
这套模型的价值在于，它把“数据质量管理”从一个模块名称拆成了可验证的能力链条。选型阶段可以用它做 POC，运维阶段也可以用它看质量治理是否持续有效。
四、平台能力一：标准和质量规则要能关联
质量规则不应孤立存在。一个“手机号格式校验”规则，背后应对应客户或人员数据元标准；一个“行政区划代码值域校验”规则，背后应对应代码集；一个“企业名称不能为空”规则，背后应对应业务对象的关键字段要求。
如果规则只是由技术人员临时写出来，后续会出现两个问题：规则来源不清，业务部门难以参与；规则更新滞后，标准变了但质量检查没有同步。
因此，平台评估时要看标准和规则是否能关联。比较有效的 POC 方法是：现场创建一个数据元标准，再基于这个标准配置非空、格式、值域或长度规则，看平台是否能记录标准来源、规则版本和执行结果。
华东某数据局在数据质量治理中，就不只是做问题修复，还编制了公共数据标准管理制度、公共数据元标准、自然人数据元标准、综合法人库数据元标准，并推动关键标准落实到核心数据表中。这个做法说明，质量治理不能脱离标准体系。
五、平台能力二：旁路监测要能支撑常态化扫描
质量监测有两类常见方式。少数关键链路可以做前置强校验，确保不合规数据不能进入后续流程。但在大规模公共数据、企业经营数据和多源归集场景下，更常见、更稳妥的方式是旁路监测。
旁路监测的核心是：数据正常入仓，质量模块并行扫描，发现问题后打标记、发告警、生成工单，不阻断业务链路。这种模式适合在不改造业务系统的前提下建立常态化质量治理机制。
江苏某大数据中心的实践很有代表性。项目围绕高频共享数据建立覆盖归集、治理、应用三层级的数据质量监测机制，累计评测高频共享资源超 300 个，处理数据量达 10 亿条，定位近 1000 万个数据质量问题，修复率达到 95%。同时，项目沉淀了 5000 个覆盖完整性、规范性、准确性、一致性、时效性等维度的数据质量规则。
这类案例说明，质量管理不是一次专项检查，而是需要持续扫描、持续反馈、持续优化。
六、平台能力三：问题定位要依赖元数据和血缘
数据质量问题如果只能告诉你“某张表异常”，还不够。治理团队需要知道异常来自哪个系统、哪张表、哪个字段、哪条规则、哪个责任部门。否则问题会在 IT、业务和数据团队之间来回流转，修复周期被拉长。
这就需要元数据和血缘能力支撑。
元数据帮助平台理解数据对象的基本信息，包括字段含义、类型、来源系统、责任人和更新频率。血缘帮助平台理解数据流转过程，包括数据从哪里来、经过哪些加工、最终去了哪里。
这里也要避免过度承诺。平台内的数据集成、归集、开发、共享环节，可以自动记录输入输出关系；但对于外部脚本直写、历史任务或未纳入平台的处理链路，仍然需要支持手动维护节点和连线。
华东某数据局在项目中建立了问题台账和问题修复知识库，将典型问题归纳为业务操作、业务规范、信息化技术、共享交换等类型。这样做的价值，是让问题不再只靠单次人工排查，而是沉淀为后续可复用的治理经验。
七、平台能力四：质量结果要回到资产目录和业务使用
质量管理如果只停留在治理后台，就很难对业务产生直接影响。成熟的数据治理平台，应当把质量结果反馈到资产目录和数据服务中。
例如，业务人员在资产目录中搜索数据资源时，应该能看到数据质量评分、最近更新时间、责任部门、申请条件和可用状态。对于质量风险较高的数据，平台可以给出提示，或要求额外审批。对于高频共享数据，平台可以持续跟踪调用情况和质量趋势。
可访问性维度也在这里体现。数据质量不只是“数据本身准不准”，还包括授权用户能不能在合理流程下找到和获取数据。
华东某数据局治理前，资源目录存在命名随意、摘要缺失、字段类型错误等问题，目录初始合格率仅 6.34%。经过标准化整改后，目录合格率提升至 94.74%，整体合格率达到 99.93%。治理后的目录被更多业务申请共享，说明高质量目录本身会提升数据使用意愿。
八、用理采存管用看质量模型的位置
数据质量主要落在“管”阶段，但它并不是孤立环节。
在“理”阶段，企业要定义数据标准、质量目标和责任机制。没有标准，就没有判断好坏的依据。
在“采”阶段，企业要记录数据来源、采集频率和采集方式。没有来源和频率，时效性和准确性很难评估。
在“存”阶段，企业要通过模型分层和主题域建设统一口径。没有模型，跨系统一致性很难保障。
在“管”阶段，平台通过标准、元数据、主数据、质量规则和安全管控形成治理闭环。
在“用”阶段，质量结果要进入资产目录、API 服务、报表和 AI 用数入口，帮助业务判断数据是否可信、是否适合使用。
因此，质量评估模型不是一个孤立的质量模块评估，而是对数据治理平台全链路能力的一次检验。
九、评估清单：拿这张表去做 POC
| 检查项 | 现场验证动作 |
|---|---|
| 标准关联 | 建一个数据元标准并关联质量规则 |
| 规则配置 | 让业务人员配置一条非空、值域或逻辑规则 |
| 旁路监测 | 跑一次扫描，看是否影响入库链路 |
| 问题定位 | 从问题记录追到源表、字段和责任部门 |
| 工单闭环 | 指派、修复、复验、归档是否完整 |
| 质量入目录 | 资产目录是否展示质量评分或可用状态 |
这张清单可以直接用于厂商 POC。它不追求一次验证所有功能，而是抓住质量管理最关键的闭环。如果平台能在真实数据上跑通这条链路，质量能力的可信度会比单纯看演示报表高得多。
对于还没有启动正式选型、只是想先摸清数据质量现状的团队，也可以先用轻量工具做一次数据体检。龙石数据质量管理平台·社区版就是这类入口：它面向 MySQL、Oracle、SQL Server、PostgreSQL 等主流数据库，支持一行命令部署，通常 10-20 分钟即可完成环境启动；企业可以按“数据源接入 → 元数据采集与管理 → 数据质量评测 → 问题数据统计与分析”的流程，先跑出一版质量现状报告。
社区版适合回答一个很朴素的问题：在上重型治理平台之前，我们的数据到底哪里有问题？它提供 12 类可视化质检规则，覆盖空值、唯一性、值域、格式、引用完整性、一致性、逻辑检查、交叉比对等常见场景，并支持从发现问题到分配修复、验证关闭的闭环。对于预算有限、团队还在建立治理认知的企业来说，这种“先体检、再决策”的路径，比直接进入大平台选型更稳妥。
十、FAQ
Q1：质量规则越多越好吗？
不是。规则要覆盖核心业务对象和高频共享数据，并能形成修复闭环。没有责任和复验的规则，只会制造告警堆积。
Q2：GB/T 36344 和 DCMM 是什么关系？
DCMM 更偏数据管理能力成熟度，GB/T 36344 更偏数据质量评价指标。做平台评估时，可以用 DCMM 看管理流程，用 GB/T 36344 看质量维度。
Q3：旁路监测是不是不如强校验严格？
两者适用场景不同。旁路监测适合不改业务系统、不阻断数据流的持续治理；强校验适合少数关键链路的前置控制。多数企业会采用组合方式。
Q4：质量评估模型适合选型还是运维？
两者都适合。选型阶段用于 POC 验证，运维阶段用于持续观察规则覆盖、问题修复、复验归档和质量趋势。
Q5：如果企业暂时没有预算上完整治理平台，能先做什么？
可以先做一次数据质量体检。比如用龙石数据质量管理平台·社区版接入一两个核心数据库，完成元数据采集和质量评测，先看清空值、重复、格式、值域、一致性等基础问题，再决定后续是补规则、建流程，还是升级到企业级数据治理平台。
参考来源
1.国家市场监督管理总局、国家标准化管理委员会，《数据管理能力成熟度评估模型》（GB/T 36073-2025）
2.GB/T 36344-2018《信息技术 数据质量评价指标》
