开篇：一个常见的技术误判
很多企业花了几百万建设数据中台，Hadoop 集群跑起来了，Flink 流批一体上了，甚至 AI 大模型也接入了------但 DCMM 贯标评估一到三级就卡住。
为什么数据汇聚了、报表上线了，评估时数据标准、数据质量、元数据管理仍然大量失分？
问题往往不在技术栈选了谁，而在于：企业把数据中台当成了 IT 基础设施项目来建，却没有按照 DCMM 定义的数据管理体系来建。
打个比方：数据中台是发动机，DCMM 是驾驶手册------光有马力没有方向，最多在原地打转，搞不好还会翻车。
本文从技术落地视角，逐层拆解 DCMM 八个能力域如何通过中台架构实现，并结合龙石数据在多个项目中的实践经验，给出一条可复制的中台 + DCMM 对齐路线。
一、DCMM 八域速览：中台能承载什么
DCMM（GB/T 36073-2018）1 定义了八个能力域和五级成熟度。八个域中，一半是战略和组织层面的，一半是执行和技术层面的------数据中台能直接承载的是后者。
| 能力域 | 类别 | 中台承载度 | 中台能做什么 |
|---|---|---|---|
| 数据战略 | 战略 | 低 | 提供数据支撑决策，战略制定靠组织 |
| 数据治理 | 组织 | 中 | 提供元数据/标准/质量工具，制度靠人 |
| 数据架构 | 设计 | 高 | 数据模型、数据分布、数据流转的核心载体 |
| 数据标准 | 执行 | 高 | 标准落标、字典管理，中台直接执行 |
| 数据质量 | 执行 | 高 | 质量规则、问题追溯、质量报告自动化 |
| 数据安全 | 执行 | 中 | 分类分级、脱敏、权限管控的技术手段 |
| 数据应用 | 价值 | 高 | 报表、API、资产门户、AI智能用数 |
| 数据生存周期 | 管理 | 中 | 归档、销毁策略，配合制度和流程 |
1.1 DCMM 2.0：即将到来的变化
截至 2024 年 7 月，全国累计 3298 家次完成 DCMM 贯标评估2。2026 年 7 月 1 日起，新版 GB/T 36073-2025（DCMM 2.0） 将正式实施3。相较 2018 版，DCMM 2.0 在以下方面变化显著：
-
评估粒度更细：过程域的评估指标从定性描述转向可量化指标（如字段合规率、质量问题闭环率等）
-
数据安全权重提升：新增数据分类分级、跨境数据管理等子域，与《数据安全法》《个人信息保护法》深度对齐
-
数据应用向智能化延伸：明确要求企业具备"数据驱动决策"的机制和工具支撑，AI 辅助用数成为加分项
-
组织保障要求强化：要求设立数据管理归口部门并明确首席数据官（CDO）职责
对于已有数据中台的企业，DCMM 2.0 意味着：平台不仅要"建起来"，还要"可量化、可审计、可追溯"。
二、技术视角诊断：为什么中台建了，DCMM 还是上不去
2.1 典型场景还原
某制造企业的技术现状很典型：
技术栈：Hadoop + Spark + Flink + Kafka + minIO
数据源：ERP (SAP)、MES (自研)、CRM (Salesforce)、OA (钉钉)
中台状态：全量数据已接入，实时 + 离线双链路，200+ 报表上线但 DCMM 评估时一查------
-
数据标准域失分：客户名称在三个系统里三种写法（"华为技术"、"华为技术有限公司"、"Huawei Tech"），产品编码各厂区不统一（物料号 vs SKU vs 内部编码混用）
-
数据质量域失分：同一个"月产能"指标在三个报表里三个数字，且无法追溯到源头------不知道是 ETL 转换时出的问题还是源系统本身就错了
-
元数据管理域失分：元数据采集覆盖了数据库表和字段，但没有血缘关系------当"周产值"报表数据异常时，无法快速定位到上游哪张源表、哪个字段出了问题
-
数据架构域失分：数据模型分散在各业务域各自维护，没有企业级数据模型和数据流转架构视图
根因就一条：中台建设完成 ≠ 数据管理能力形成。
DCMM 评估考察的不是"你有没有平台"，而是"你有没有能力"。八个能力域里，数据标准、数据质量、元数据管理、数据架构这四个域，直接把这家企业的分数拉到了二级以下。
注：本文聚焦数据管理能力评估（DCMM）。制造业企业在智能制造能力评估方面应关注 CMMM（GB/T 39116-2020、GB/T 39117-2020）。DCMM 与 CMMM 评估维度不同，不可相互替代。
2.2 技术层面缺失的关键能力
从架构视角看，这四个域缺失对应的是一组技术能力的空白：
| DCMM 能力域 | 缺失的技术能力 | 中台应补上的模块 |
|---|---|---|
| 数据标准 | 标准定义 → 自动校验 → 不合规阻断的自动链路 | 标准落标引擎 |
| 数据质量 | 质量规则配置 → 实时监测 → 问题工单 → 修复验证的闭环 | 质量监控平台 |
| 元数据管理 | 元数据自动采集 → 血缘自动解析 → 影响分析 | 元数据 + 血缘引擎 |
| 数据架构 | 企业级数据模型 → 数据流转图 → 架构版本管理 | 数据地图 + 模型管理 |
补齐这些能力之后，DCMM 三级才有技术底。
三、理采存管用 × DCMM：方法论与落地的系统对照
在进入具体技术实现前，先建立方法论层面的认知框架。
龙石数据中台在实践中总结并严格遵循的"理采存管用"五步方法论，可以和 DCMM 的八个能力域做系统性对照4：
| 方法论 | 对应 DCMM 能力域 | 中台动作 | 对应龙石数据模块 |
|---|---|---|---|
| 理 | 数据战略 → 数据架构 | 梳理业务流程、盘点数据资源 | 数据源接入 元数据接入 |
| 采 | 数据架构 → 数据生存周期 | 打通数据、汇聚数据 | 数据集成 （数据源接入、数据归集）； 数据填报 |
| 存 | 数据架构 → 数据标准 | 模型规划，规范数仓 | 数据底座 （底层存储与计算）； 数据规划（数据模型管理）； |
| 管 | 数据治理/标准/质量/安全 | 全域管理，提升质量 | 数据治理 （元数据、主数据、标准登记/制定）； 数据质量管理 ； 数据安全管理。 |
| 用 | 数据应用 | 便捷应用，促进数据价值释放 | 数据应用 （数据查询、数据可视化）； 数据开发 （数据标签、数据指标）； 数据共享 （API共享、数据共享）； 数据资产（目录发布与应用）。 |
龙石数据中台的设计哲学：严格遵循"理采存管用"方法论进行模块化设计。各模块既可独立部署（应对不同成熟度阶段的企业需求），也能协同工作（支撑数据全生命周期的治理与应用）。当一个企业的中台按这五个阶段建设时，DCMM 评估所需的制度文档、技术能力、执行证据都是"现成的"，而非临时拼凑。
这个对照表的核心价值在于：当 DCMM 评估师问"数据标准怎么落地的""数据质量怎么管的"，如果中台是按"理采存管用"建的，每个问题在系统中都有对应的执行路径和审计记录------答案不是 PPT 里写的，而是从系统里查出来的。
四、四个关键能力域的技术落地详解
以下是 DCMM 评估中最容易失分、也是中台最能发挥技术价值的四个能力域，逐项拆解落地路径。
4.1 数据标准：从 Word 文档到自动执行
DCMM 要求：不仅要"制定标准"，更要"执行标准"------标准不能只停留在文档里，要能在数据流转的每个环节自动校验。
技术落地路径：
标准定义层 → 标准发布层 → 标准执行层 → 标准审计层
│ │ │ │
▼ ▼ ▼ ▼
字段命名规范 元数据注册 接入自动校验 合规率看板
字典值域定义 主数据管理 入库自动校验 不合规工单
编码规则配置 标准版本管理 ETL自动映射 趋势分析报告关键实现：
-
字典管理：在元数据管理模块中定义字段标准（名称、类型、长度、值域、编码规则）。支持版本化管理，每次标准变更产生新的版本记录。
-
自动落标 ：数据接入时，中台自动校验源端数据是否符合已发布标准。比如"客户类型"字段的值域必须是
[个人, 企业, 政府]，源系统传了 "个体户" 就自动标记为不合规。 -
不合规阻断策略：可配置为"告警不阻断""阻断+人工放行""强制阻断"三级策略，根据业务场景灵活选择。
实战效果：龙石数据在多个项目中通过标准自动落标，将字段合规率从初始的 60% 提升到 95% 以上。这个数字本身就可以作为 DCMM 评估中的量化证据。
4.2 数据质量：从事后救火到持续监控
DCMM 要求：数据质量域涵盖质量需求、检查、分析和提升四个过程域5，要求形成完整的 PDCA 闭环。
技术落地路径：
质量需求 → 规则配置 → 质量检查 → 问题追踪 → 质量提升
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
业务定义 完整性检查 定时巡检 问题工单 根因分析
质量SLA 唯一性检查 实时监测 责任追溯 规则优化
优先级分级 一致性检查 入库校验 修复验证 趋势报告
准确性检查 使用前校验 时效监控 SLA达成率
及时性检查核心设计 ：质量规则配在入库 和使用两个环节------
-
入库环节：数据进入数仓 ODS 层时执行质量规则校验，不通过的数据进入"待处理区"，同时生成质量事件
-
使用环节：业务人员通过资产门户申请数据时，能看到每张表的质量评分卡（完整性、准确性、及时性等维度），低质量数据被自动标记警示
实战效果：江西某国控集团通过建立质量闭环管理机制，半年内将核心数据质量问题的修复周期从两周缩短到两天。技术上实现的关键是：质量问题自动生成工单 → 自动路由到数据责任人 → 修复后自动回归验证 → 质量趋势自动上报。
4.3 数据架构：从静态 ER 图到动态数据地图
DCMM 要求：管理数据模型、数据分布、数据流转和数据集成交付。
技术落地路径：
最重要的两个技术组件是元数据血缘引擎 和数据地图：
元数据自动采集
│
▼
SQL解析 → 字段级血缘关系
│
▼
数据流转图（自动生成 + 手动补充）
│
▼
影响分析 / 溯源分析 / 架构合规检查关键能力：
-
自动化血缘：通过解析 ETL 脚本（SQL、Spark、Flink Job）自动构建字段级血缘关系，不需要人工维护
-
数据地图：将血缘关系可视化为企业级数据地图，支持"这数据从哪来的"和"这数据被谁用了"双向追溯
-
影响分析：当上游表结构变更时，自动分析下游影响范围并通知相关责任人
实战价值：当业务部门想关联分析两个不同域的数据（比如"客户投诉数据"和"订单交付数据"），一分钟内就能在数据地图上看到它们的血缘通路------不用再跨部门找人问"这数据从哪来的"。这一点在 DCMM 评估的数据架构域中是明确的加分项。
4.4 数据应用：从 IT 排期到业务自助
DCMM 要求：DCMM 的最高成熟度要求是"数据驱动决策"6，体现在技术上就是降低用数门槛。
技术落地路径：
数据资产门户（业务语言）
│
├── 数据目录（按业务域分类，非技术表名）
├── 数据检索（自然语言搜索）
├── API 超市（RESTful API，零代码调用）
├── 自助分析（拖拽式报表 + SQL 智能生成）
└── AI 智能用数（NL2SQL，自然语言查询）关键设计：
-
资产门户的业务语言层 ：数据目录不是列
ods_sap_mseg_2024这样的技术表名，而是 "SAP 物料移动明细（2024）" 这样的业务描述。业务人员用自己熟悉的术语就能找到数据。 -
API 共享与自动审批：数据服务接口统一管理，业务部门在线申请 → 数据 Owner 在线审批 → 自动生成 API Token 和调用文档。审批时间从天级降到分钟级。
-
AI 智能用数：接入大模型（LLM），支持自然语言转 SQL。业务人员输入 "上个月华东区销售额 Top 10 的产品"，系统自动生成查询并返回结果------不会 SQL 的人也能做数据分析。
实战效果：某市监局通过中台将多个业务条线的数据归集后，统一对外提供数据服务接口，业务部门从"找 IT 排期（平均 5 个工作日）"变成了"在线申请、自动审批（5 分钟内开通）"。
五、DCMM 五级成熟度：你的中台在哪个位置
| 成熟度 | 中台表现 | 典型技术特征 | 关键差距 |
|---|---|---|---|
| 1级 初始级 | 数据分散，手工出报表 | Excel + 邮箱，无平台 | 数据不可复用 |
| 2级 受管理级 | 数据接进来了，有基础治理 | 元数据采集了、质量标准定义了，但自动化率 < 30% | 标准和质量依赖人工 |
| 3级 稳健级 | 治理形成闭环，业务开始用 | 标准自动落标、质量持续监控、血缘自动解析、业务自助用数 | --- |
| 4级 量化管理级 | 可量化评估 | 使用率、质量趋势、业务贡献度有 Dashboard 可查 | 数据价值难以量化 |
| 5级 优化级 | 持续优化、自动演进 | 治理规则自优化、AI 辅助决策、数据产品化 | 需要组织级数据文化 |
5.1 从 2 级到 3 级的技术实施路线
大部分上了中台的企业卡在 2 级------数据集中了、基本治理做了，但下一步怎么走不清楚。
从 2 级到 3 级的核心转变：把数据标准和数据质量的执行从"人工"变成"自动"。
具体技术动作：
| 阶段 | 周期 | 技术动作 | 验收标准 |
|---|---|---|---|
| 第一阶段 | 1-3个月 | 完成全量元数据采集，建立基线 | 元数据覆盖率 > 90% |
| 第二阶段 | 3-6个月 | 核心字段标准制定 + 自动落标上线 | 字段合规率 > 85% |
| 第三阶段 | 6-9个月 | 质量规则配置 + 自动巡检 + 工单闭环 | 质量问题闭环率 > 80% |
| 第四阶段 | 9-12个月 | 血缘自动解析 + 数据地图上线 | 血缘覆盖率 > 70% |
| 第五阶段 | 12-18个月 | 资产门户 + 自助用数 + API 共享 | 业务自助用数率 > 50% |
| 第六阶段 | 18-24个月 | AI 智能用数 + 质量趋势预测 | 智能用数覆盖核心场景 |
这个 12-24 个月的周期不是技术实施慢------而是组织的用数习惯和数据 Owner 的责任意识需要时间建立。技术上 3-6 个月就能把标准落标和质量监控跑起来，但让一线业务人员从"找 IT 取数"切换到"自己去资产门户查"，才是真正花时间的部分。
六、常见问题（技术视角）
Q1：DCMM 必须先建数据中台吗？
不一定。DCMM 评估的是能力，不是平台。但没有中台的企业在数据架构、数据标准、数据质量这几个域很难拿到三级以上------因为这些能力需要平台承载和自动化执行7。纯靠人工管理在面对 PB 级数据和上百个系统时不可持续。
Q2：理采存管用和 DCMM 是什么关系？
不冲突。DCMM 是国家标准（GB/T），告诉你"管什么"------检查清单；理采存管用是龙石数据在实践中总结的落地方法论，告诉你"怎么管"------施工图纸。DCMM 看结果，理采存管用管过程。两者配合使用：用 DCMM 框架做差距分析，用理采存管用方法做建设规划。
Q3：企业多久能提升一个 DCMM 等级？
-
1级 → 2级：6-12 个月（上中台 + 基础治理，元数据采集、质量标准定义）
-
2级 → 3级：12-24 个月（标准和质量从人工变自动，最关键的跃迁）
-
3级 → 4级：12-18 个月（量化管理体系建设，数据文化形成）
-
4级 → 5级：18+ 个月（持续优化，AI 辅助决策）
关键是持续投入，不是突击冲刺。见过太多企业花 3 个月突击准备材料拿了个三级，第二年复查时又掉回二级------因为自动化治理体系是突击不出来的。
Q4：DCMM 2.0 对技术架构有什么新要求？
DCMM 2.0 新增/强化了以下技术相关要求：
-
数据安全：需要技术手段支撑数据分类分级、脱敏策略执行、安全审计日志，不再只是制度层面
-
数据共享：要求有统一的 API 管理和计量计费能力
-
AI 伦理：使用 AI 处理数据时需要考虑公平性、可解释性
-
量化指标：从"有没有"到"好不好"，要求系统能产出合规率、闭环率、使用率等量化数据
七、写在最后
很多企业有一个认知惯性：建了数据中台，就等于做好了数据管理8。
但 DCMM 用八个能力域和五级成熟度告诉我们：平台只是工具，能力才是目标。
DCMM 回答的是"企业应该具备什么数据管理能力"------这是方向。数据中台回答的是"这些能力如何通过技术手段落地"------这是路径。两者缺一不可。
DCMM 2.0 即将实施的窗口期（2026年7月1日），每一个正在建设或已经建成数据中台的企业，都值得用 DCMM 的框架重新审视自己的建设思路------你建的到底是平台（能跑数据），还是能力（能管好数据、能用好数据）？
企业未来竞争的核心，不是拥有多少数据，而是能否把数据变成持续创造价值的资产。而这个转变的第一步，就是用 DCMM 校准方向，用数据中台铺好路。
参考来源
1 GB/T 36073-2018，数据管理能力成熟度评估模型，全国信息技术标准化技术委员会(TC28)，2018年3月发布，2018年10月实施 --- openstd.samr.gov.cn
2 中国电子信息行业联合会，DCMM贯标评估年度报告，2024
3 GB/T 36073-2025（DCMM 2.0），2026年7月1日起实施 --- 全国标准信息公共服务平台
4 DAMA International, "What is Data Management?" --- dama.org
5 中国信息通信研究院，《数据要素白皮书（2023年）》，2023年9月 --- caict.ac.cn
6 艾瑞咨询，《2024年中国企业数据治理白皮书》，2024 --- iresearch.cn
7 DAMA International, "DAMA-DMBOK2R," 2nd ed., revised. Technics Publications, 2024 --- dama.org
8 信通院，DCMM标准全文公开信息 --- openstd.samr.gov.cn