很多团队在数据治理上的投入并不少，但效果常常卡在同一个地方：制度定得清清楚楚，落地却稀稀拉拉。标准写了、规范发了，实际执行还是靠人盯人，时间一长就回到原样。
DCMM 2.0（GB/T 36073-2025，2026 年 7 月 1 日起实施）[1] 正是针对这一痛点做了升级——评估方式从定性判断转向量化度量，486 项指标要求可复验的执行证据 [2]。这意味着，仅靠制度文档已经难以支撑评估，规则的执行、监测、追溯和持续改进，需要一套数据治理平台来承载。
制度管"应不应该做"，平台管"有没有在做"。本文以"理采存管用"五阶段方法论为主线，分析平台在每个环节应承担的工作，并给出选型评估的五个维度。
一、DCMM 2.0 对"制度"的要求——以及制度的边界
DCMM 2.0 在"数据治理"能力域中明确要求建立数据治理组织、制度建设和文化建设 [3]。这三者共同构成了数据治理的"软件层"——谁对数据负责、标准怎么定、质量谁兜底、安全谁划界，都需要制度来定义。
制度的本质是解决一致性问题：确保全员在同一套规则下工作。一个有效的数据管理制度体系通常覆盖数据生命周期各环节的操作规范和权责分工，让每项数据活动都有据可依。DAMA-DMBOK2 将数据治理定义为"对数据资产管理行使权力和控制的活动集合"，这一界定本身就说明制度层面的组织设计与权责分配是先决条件 [4]。
但制度的边界同样清晰。当评估师追问"标准覆盖了多少字段""质量问题的闭环周期是几天""资产目录最近一次更新是什么时候"，制度回答不了这些问题。制度告诉团队"应该做"，但无法告诉管理层"做到了没有、做到了什么程度"。制度是组织的骨架，但骨架需要肌肉和神经系统——也就是平台——才能真正运转起来。
截至 2025 年 11 月，全国 DCMM 贯标企业已达 10,448 家，其中获评最高等级（L5）的仅 33 家 [2]。大量企业处于 L2-L3 阶段，瓶颈往往不在制度文件是否齐全，而在于制度的执行缺乏可量化的抓手。从多数贯标实践来看，当数据域超过三个、涉及系统超过十套时，纯人工执行制度会迅速触达管理天花板。
二、制度的尽头，平台的开端：理采存管用的工程化落地
业内常用的"理采存管用"五阶段方法论，将 DCMM 2.0 的九大能力域转化为可执行的建设路径 [5]。需要说明的是，"理采存管用"与 DCMM 2.0 能力域之间并非严格意义上的一一对应——"理"侧重战略、组织与制度建设，横跨数据战略、数据治理等多个能力域；"存"侧重数据仓库开发与数据架构建设，与数据资产域各有侧重。二者的对应关系示意如下：
注：上图为对应关系示意，"理采存管用"与 DCMM 2.0 能力域之间并非严格一一对应。
在每一个环节，制度给出方向，平台给出动作。以下以"理采存管用"为主线，逐一展开分析。
2.1 理：定战略、建体系、摸家底——制度主导，平台摸底
"理"是五阶段中最偏向制度侧的一个环节。其核心工作是制定数据战略、建立治理组织、明确权责分工——这些主要由制度驱动。
但平台在"理"阶段同样能发挥作用。传统的数据资产盘点依赖人工访谈和 Excel 逐表登记，覆盖面有限且更新滞后。一个合格的数据治理平台应能自动连接核心业务系统，完成数据资产的初次扫描，生成资产目录初稿并同步输出数据质量基线报告——让"摸家底"从主观申报走向客观扫描。
从多数企业的实践经验来看，"理"阶段如果只有制度文件而没有平台支撑的资产摸底，后续的"采存管用"往往会缺乏准确的起点。
2.2 采：聚数据，打通业务系统——制度定接入规范，平台自动化执行
"采"的核心任务是将分散在多系统中的数据按需归集到统一平台。制度在这个环节的职责是定义数据源接入标准、归集频率和接口规范——哪些系统需要接入、以什么频率同步、全量还是增量、数据格式如何统一。
平台则承担实际的归集执行工作。一个成熟的数据治理平台，其多源异构归集应覆盖数据库、API、文件和消息队列等多种数据源类型，支持批量归集、多表归集和实时归集三种模式。其中，多表归集允许通过向导式操作一次同步多张表，适合快速接入大量业务表；批量归集流程开发则提供拖拽式画布，适合需要在归集过程中做清洗转换的精细化场景。
制度定义了"接什么、怎么接"，平台保证"实际在接、按规范接"。制度写得再详细，如果平台能力不匹配——比如只支持单一数据源类型或无法处理异构环境——制度的落地就会在第一步卡住。
2.3 存：绘模型，标准化数据分层——制度定模型规范，平台强制约束
"存"是数据架构的工程化环节。制度侧需要定义数据仓库分层标准——ODS 操作数据层、DW 数据仓库层、ADS 应用数据服务层的命名规范和设计原则——以及各层之间的流转规则。
平台在这个环节的价值体现在两个层面。第一是约束层面：模型在线设计时，平台能强制校验命名是否符合规范、字段类型是否与定义一致，从源头上减少"设计时一套、落地时另一套"的问题。第二是效率层面：流批一体的计算引擎让离线加工和实时处理在同一套架构下完成，避免维护两套代码的成本。
2.4 管：管数据——平台承载最密集的环节
"管"是"理采存管用"中平台承载度最高的环节，也是 DCMM 2.0 评估中平台证据需求最集中的区域。制度在这个环节的职责是定义规则，但规则从定义到执行之间，需要平台完成大量工程化工作。
数据标准与落标稽核。制度定义字段级的数据标准——编码规则、值域范围、格式规范等。平台则需要将标准转化为可自动执行的稽核规则。以字段级落标稽核为例：标准定义了"客户编号为 18 位统一社会信用代码"，平台在新数据入库时自动扫描该字段，发现不符合格式的记录立即标记。标准变更后，平台自动感知下游影响链路——这个字段被哪些报表、哪些 API 引用了——避免标准修改引发连锁故障。
数据质量与旁路监测。制度定义质量规则——非空约束、值域限制、一致性规则等。平台以旁路监测模式执行：数据正常入库，质量检查在旁路并行扫描，发现问题打标记、发告警、生成整改工单，不阻断业务流程。这种"旁路"设计的关键在于：治理不影响业务运行，但治理结果对管理层完全可见。当团队规模扩大、数据量增长后，手工逐条检查的效率和覆盖率都会快速下降，旁路自动化监测是较为稳妥的解决路径。
元数据管理与血缘解析。制度定义元数据的采集范围和更新频率。平台自动采集表结构、字段信息和注释，减少人工录入维护的工作量。血缘关系解析方面，平台能自动记录数据在归集、清洗、加工和共享各环节的输入输出关系——哪个源表经过哪些转换后进入了哪个报表或 API。对于平台外的操作，通常也提供手动补录入口。
数据安全管理。制度定义数据分类分级策略和访问权限规范。平台自动执行敏感数据打标——如身份证号、手机号字段自动识别和标记——并在查询和导出时联动脱敏规则。细粒度的权限控制确保不同角色看到不同层级的数据。
主数据管理。制度定义主数据的编码规范和实体准入标准。平台统一实体管理，自动查重和关联，解决"同一个客户在三个系统叫不同的名字"等典型问题。
案例：华东某化工企业在启动数据治理项目时，首先从顶层成立了专门的数据管理部，并在此基础上利用数据治理平台统一物料编码和标准管理。项目实施一年后，该企业的库存周转率提升了近两成，订单交付及时率也有同等幅度的改善。比这些经营指标更重要的变化是——数据管理部已能独立承接新业务域的治理需求，制度变成了日常运转的操作基础，而非应付评估的归档文档。
2.5 用：促共享、重应用——制度定义共享规则，平台量化使用成效
"用"是数据价值兑现的环节。制度侧的定义包括：数据共享审批流程、API 管理规范、数据退役规则等。平台侧的工作则围绕"让数据被找到、被理解、被使用"展开。
资源目录的自动化编目让业务人员在平台上搜索和申请数据，替代传统的人工对接方式；API 共享和并发管理让数据服务从"发文件"升级为"调接口"；自然语言问数能力进一步降低了数据使用门槛——业务人员不需要掌握 SQL，直接以日常语言提问即可获得分析结果。
"用"的成效是检验前面四个环节的最好标准：理得清、采得进、存得下、管得住，最终都是为了用得好。
三、选型视角：五个评估维度
理解了平台在每个环节应承担的工作之后，选型评估就有了清晰的标尺。以下是五个建议的评估维度，每个维度都围绕"制度能否在平台上落地执行"这个核心问题展开。
关于产品能力，市面上部分数据治理平台已将标准管理、质量稽核、元数据血缘和资产目录整合在同一框架下，治理闭环不必跨多套工具拼接。在架构开放性方面，部分数据中台产品采用"一集团一中台、一公司一空间"的工作空间模型，让总部统一制定治理标准，各分子公司在独立工作空间中自主管理本地数据，兼顾了标准一致性与业务灵活性。在长期运营维度上，部分厂商已配套了培训与陪跑机制——培训建立认知，陪跑完成能力转移，目标不是"厂商帮你把数据治好了"，而是"你们自己能治了"。
四、从制度走到平台：三阶段推进路径
制度与平台的协同不需要一步到位。参照"理采存管用"的建设节奏，以下是三阶段推进路径的参考框架。
第一阶段的核心目标是"看清现状"——制度覆盖了哪些环节、缺失在哪里，同时通过平台完成资产盘点，建立量化的数据质量基线。第二阶段用一个小范围闭环验证方法论和平台的有效性——让业务方在短时间内感受到治理带来的实际变化。第三阶段将验证后的模式铺开到更多数据域，制度与平台形成持续的反馈循环：平台运行数据为制度迭代提供依据，制度优化又通过平台落地执行。
