一家准备做 DCMM 评估的企业，最初以为难点在材料准备。制度文件可以补，组织架构可以画，平台功能截图也能凑。但真正进入自查阶段后，问题开始变得具体：数据标准在哪里执行？质量问题发现后谁来修、怎么复验？一张经营报表里的指标能不能追到源系统字段？数据资产目录是不是只有 IT 人员看得懂？
这时团队才意识到，DCMM 三级关注的不是“有没有一个数据治理平台”，而是企业的数据管理能力是否真正运行起来。
DCMM 2.0（GB/T 36073-2025）是企业数据管理能力成熟度评估模型。它关注的是企业在数据战略、数据治理、数据架构、数据资产、数据标准、数据质量、数据安全、数据生存周期、数据应用流通等能力域上的综合成熟度。对于正在建设数据治理平台的企业来说，平台不是评估的全部，却是很多能力从制度走向执行的关键载体。
换句话说，三级评估不会只问“系统里有没有这个菜单”，而会继续追问：这个能力是否被使用，是否有记录，是否能复验，是否能支撑业务。
二、三级评估最容易卡住的四类证据
从平台建设角度看，企业在 DCMM 三级准备中常卡在四类证据上。
| 证据类型 | 评估常见追问 | 平台需要提供的支撑 |
|---|---|---|
| 标准执行证据 | 标准是否只是文档？ | 标准编制、发布、落标、执行记录 |
| 质量闭环证据 | 问题发现后谁修、怎么验？ | 质量规则、监测、告警、工单、复验台账 |
| 元数据与血缘证据 | 数据从哪来、影响到哪？ | 元数据采集、血缘解析、变更影响分析 |
| 资产使用证据 | 数据是否真的被业务使用？ | 资产目录、申请审批、API 调用、使用统计 |
这四类证据背后，其实对应着同一个要求：数据管理能力要从“说得清”走向“做得到”。制度和流程是前提，但如果没有平台把执行过程记录下来，很多能力既难以持续运行，也难以被验证。
三、数据标准要从“写出来”变成“跑起来”
很多企业并不缺数据标准文档。字段命名规范、代码集、指标口径、数据元定义，文件夹里都有。但一到新系统接入，字段仍然按项目组习惯命名；同一个客户、供应商、物料，在不同系统里仍然各有各的说法。
DCMM 三级所要求的数据标准能力，不应停留在“制定标准”，还要能证明标准被执行。落到平台上，至少要能回答三个问题。
第一，标准是否可以在线管理。数据元、代码集、业务术语、指标口径，不能只存在于 Word 和 Excel 里，而应能在平台中被编制、审核、发布和更新。
第二，标准是否能关联到真实数据对象。一个标准字段发布后，能不能关联到对应的数据库表、字段、主题域和数据资产？如果标准和物理数据之间没有关系，标准就很难进入日常开发和治理流程。
第三，标准执行是否有记录。哪些字段已落标，哪些字段未符合规范，整改是否完成，都应形成可追踪的过程。
华东某大型化工企业（企业名称已脱敏）在建设数据中台时，就不是先追求大屏展示，而是先统一物料、产品、指标口径等核心标准。该企业原本 MES、ERP、CRM 等系统相互独立，物料编码不统一，经营分析依赖人工对账。项目中通过建立企业级数据标准管理机制、编制业务术语和指标说明书，为产销协同和经营分析打下了统一语言。
对于数据治理平台来说，数据标准模块的价值不在于“能录入多少条标准”，而在于标准能否进入数据接入、建模、质量检查和资产发布流程。
四、质量管理要形成“发现—定位—修复—复验”闭环
数据质量是三级评估中最容易暴露问题的领域。很多平台可以配置质量规则，也能生成质量报告，但问题在于：报告出来之后怎么办？
如果质量问题只是停留在“发现异常”阶段，治理能力仍然是不完整的。一个更完整的质量闭环，应当包含发现、定位、分派、修复、复验和归档。
这里要特别区分两种模式。部分场景适合前置强校验，例如关键主数据新增时必须符合编码规则。但在大规模数据归集场景中，如果把所有质量检查都做成入库拦截，容易影响数据流转效率。更稳妥的做法通常是旁路监测：数据正常入仓，质量模块并行扫描，发现问题后打标记、告警、生成整改工单，不阻断原有数据链路。
江西某国控集团的案例可以说明这一点。该集团原有协同办公、产权管理、投资管理、财务、人力、党建等 10 余套系统分散独立，监管数据质量无管控，领导难以获得可信的统一数据视图。项目中，平台构建了完整性、准确性、一致性、及时性、唯一性等稽核规则，实现数据自动检测、异常告警、问题定位和整改跟踪。质量管理不再只是“查出问题”，而是进入监管数据的日常运行机制。
DCMM 三级看重的正是这种可持续运行的质量管理能力。规则数量不是关键，闭环是否跑得起来才是关键。
五、元数据和血缘要支撑“可追溯”
当业务部门问“这个指标从哪来”时，如果数据团队只能去翻脚本、问开发、查历史工单，说明元数据能力还没有真正建立。
元数据不是简单的表清单。它至少应包括表和字段的技术信息、业务含义、责任人、更新频率、来源系统、加工过程和下游使用关系。血缘分析的价值也不只是画图，而是帮助团队回答两个问题：数据从哪来，改了以后影响谁。
从平台能力看，元数据和血缘至少要满足三层要求。
第一，基础元数据自动采集。接入数据库后，平台应能自动采集表结构、字段类型、字段注释、数据量等基础信息，减少人工维护成本。
第二，平台内链路自动记录。当数据在平台内完成集成、加工、归集、共享时，输入输出关系应被自动记录，便于后续追溯。
第三，平台外链路允许手动补全。现实中很多企业仍有外部脚本、第三方工具或历史任务。对于平台未覆盖的环节，血缘关系需要支持手动维护节点和连线，不能简单承诺“所有链路一键自动完成”。
江苏某市监局建设数据治理平台时，就把全盘元数据管理作为基础能力之一。平台建立全局统一的数据资源目录，实现元数据自动采集、变更同步和版本追溯，让监管数据资产“看得见、找得到、读得懂”。这类能力是后续质量定位、资产目录和共享服务的基础。
六、资产目录要从“台账”走向“业务入口”
很多企业的资产目录，本质上还是一张技术台账。表名、字段名、库名都有，但业务人员看不懂，也不知道能不能申请、怎么使用。这样的目录很难证明数据资产已经进入业务流通。
在 DCMM 2.0 背景下，数据资产和数据应用流通的重要性进一步提高。数据治理平台如果只管“管数据”，不管“用数据”，能力链条是不完整的。
一个更成熟的资产目录，应具备几个特征：业务语言可检索，数据质量状态可见，权限申请在线化，API 或数据集可以被服务化发布，调用和使用情况可以被统计。
江苏某市监局项目中，平台不仅建设了数据管理能力，还提供自助式 API 服务和统一门户。监管人员日均登录系统次数减少 90% 以上，数据需求响应从天级缩短至分钟级。这个变化说明，资产目录和共享服务不只是“展示数据”，而是在改变业务使用数据的方式。
这也是三级能力建设中容易被忽视的一点：数据治理不是把数据管在平台里，而是让可信数据被业务安全、稳定、可控地使用。
七、用“理采存管用”把三级要求拆成落地路线
DCMM 给出能力目标，但企业还需要一条工程化路径，把目标拆成能排期、能实施、能验收的任务。龙石数据提出的“理采存管用”方法论，可以作为一种落地视角。
| 理采存管用 | 对应建设重点 | 平台动作 |
|---|---|---|
| 理 | 目标、组织、资产家底 | 数据资产盘点、治理职责、标准框架 |
| 采 | 数据来源与归集 | 多源异构接入、全量/增量同步 |
| 存 | 模型与架构 | ODS-DW-ADS 分层、主题域模型 |
| 管 | 标准、质量、安全 | 元数据、主数据、质量规则、分类分级 |
| 用 | 共享和应用 | 资产目录、API、报表、AI 用数 |
需要说明的是，这是一种工程实施视角下的对应关系示意，并不是将 DCMM 能力域与产品模块做严格的一一对应。比如“理”不仅包含战略规划，也涉及组织、制度和资产盘点；“管”也不只是质量规则，还包括标准、主数据、安全和责任闭环。
部分数据治理平台，例如龙石数据中台，会将标准管理、数据质量、元数据、资产目录、API 服务等模块组织在同一套方法论下。对于准备 DCMM 三级评估的企业来说，选型时不应只看模块名称，而应看这些模块能否串成一条可执行的治理流程。
八、FAQ
Q1：DCMM 三级是不是只要买数据治理平台就能过？
不是。平台只能提供执行、留痕和复验能力，组织、制度、责任机制仍然需要企业自己建立。没有治理组织和业务责任人，平台里的流程也跑不起来。
Q2：平台演示时应该重点看什么？
建议用一条真实数据链路做验证：从数据接入、标准关联、质量监测、问题定位，到资产发布和业务申请。能跑完一条闭环，比看完整功能清单更有价值。
Q3：旁路监测会不会影响数据入库效率？
旁路监测的设计是不阻断入库。数据正常入仓，质检并行扫描，发现问题后生成告警和整改任务。它适合在不改业务系统的前提下建立持续质量治理机制。
Q4：三级建设从哪里开始比较稳妥？
较为稳妥的做法是先选择一个高价值数据域，完成标准、质量、元数据和资产目录的最小闭环。跑通后，再横向扩展到更多业务域。
参考来源
国家市场监督管理总局、国家标准化管理委员会，《数据管理能力成熟度评估模型》（GB/T 36073-2025）
DAMA International，《DAMA-DMBOK: Data Management Body of Knowledge》
