摘要：DCMM 2.0（GB/T 36073-2025）[1]于2025年12月31日发布、2026年7月1日实施，能力域从8个扩展到9个、能力项增至33个、评估指标升级到486项。本文对九大能力域逐一深度解读，结合五级成熟度阶梯、486项量化指标和企业落地实践，为CDO和数据治理负责人提供一份从标准到实施的参考框架。 一、为什么 DCMM 2.0 是一次"代际升级" DCMM 2.0不是"改了个版本号"那么简单。 三股力量正在同时推动企业数据管理能力的升级。第一股是政策倒逼——《企业数据资源相关会计处理暂行规定》[2]已将数据资产入表从概念推入实操，企业不能再说"我们的数据值多少钱说不清楚"。第二股是标准升级——DCMM 2.0（GB/T 36073-2025）[1]新增"数据资产"能力域，能力域从8个扩展到9个，能力项从28个增至33个，评估指标从441项升级到486项。这是对整个评估体系的一次重构。第三股是竞争压力——截至2025年11月，全国已有10,448家企业完成DCMM贯标评估，DCMM 5级（最高等级）企业已达33家。当越来越多的同行开始用同一把尺子衡量数据能力时，还没有上桌的企业，差距不是"分数高低"的问题，而是"有没有入场资格"的问题。 DCMM 2.0的核心变化可以归纳为五个方面： 能力域 8→9：新增"数据资产"能力域（排第4位），能力项为权属管理、价值评估、资产运营。这不是简单"加一个域"，而是把数据管理的终点从"建好平台"推到了"产生资产价值"。 能力项 28→33、评估指标 441→486：评估体系从"有没有"升级为"做到了什么程度"。 安全要求较1.0显著增强：安全域能力项从旧版的"数据安全策略/数据安全管理/数据安全审计"变更为"数据合规管理/数据安全防护/数据安全审计"——这是一次能力结构的重组和合规要求的升级，而非简单的"权重要求提高"。 L4量化管理级引入人工智能技术：DCMM 2.0首次将AI应用作为能力要求写入标准——L4级明确要求"引入人工智能等先进技术，全面提升数据管理工作效率"。 评估基准等级为L2受管理级：L1初始级不可申报评估。 综合来看，DCMM 2.0做了一件事：把评估焦点从"有没有治理"升级为"能不能资产化、能不能AI化"。这是一个从"过程导向"到"结果导向"的范式升级。 二、九大能力域速览：一张全景地图 在深入每个域之前，先建立一张全景地图。DCMM 2.0的九个能力域覆盖了数据管理的全生命周期，按组织属性可以大致分为战略层、设计层、执行层和价值层： 能力域 核心考察 属性 中台承载度 数据战略 是否有中长期规划、愿景目标和路线图 战略 低 数据治理 是否有治理组织、制度体系和沟通机制 组织 中 数据架构 数据模型、分布、流转是否清晰统一 设计 高 数据资产 ⭐ 数据是否可盘点、可评估、可入表 价值 高 数据标准 标准是否制定、发布并在系统中执行 执行 高 数据质量 是否有质量需求定义和闭环管理机制 执行 高 数据安全 分类分级、权限控制、加密脱敏、审计溯源 管控 中 数据生命周期 创建→采集→存储→使用→归档→销毁全流程 管理 中 数据应用 数据是否被共享、使用、产生业务价值 价值 高 这张表透露出一个重要信息：九个能力域中，"高承载度"的五个域（数据架构、数据资产、数据标准、数据质量、数据应用）的执行层面都绕不开数据中台。DCMM考察的虽然是管理能力，但大部分能力域的技术落地必须依赖一个标准化的数据基础设施——从这个意义上说，数据中台不是DCMM评估的"加分项"，而是"必答题"。 新增的"数据资产"域被放在第4位——介于"数据架构"和"数据标准"之间——这个排位本身就有深意：资产化不是治理完成后的"最后一公里"，而是贯穿整个数据管理体系的内核。 三、五级成熟度：企业在哪个位置 DCMM 2.0的五级成熟度框架没有变，但每个等级的评判标准变得更加量化。以下是一个速览对照： 等级 名称 核心特征 典型企业画像 DCMM 2.0 关键要求 L1 初始级 无正式数据管理流程 数据散落各部门，手工出报表 2.0不可申报 L2 受管理级 项目级管理 数据接进来了，有基础治理但使用率低 2.0评估基准等级 L3 稳健级 组织级标准化管理 治理形成闭环，业务开始用数据 至少6个域达标 L4 量化管理级 量化指标体系 可量化评估（如修复时长≤2h，标准覆盖率≥95%） 引入人工智能技术 L5 优化级 数据驱动持续优化 治理规则自优化、AI辅助决策 行业标杆级 L3→L4是关键跃迁。从标准化到量化管理，从人工执行到自动监控——这个转变不只是技术升级，更是组织习惯的改变。从项目统计来看，多数建了数据中台的企业目前在L2-L3区间，通往L4通常需要12到24个月。 L4的AI门槛尤其值得注意。DCMM 2.0首次将AI应用写入标准要求——这意味着企业在数据管理上不仅要"管得好"，还要"用AI管"。从比较务实的角度来看，AI用数能力建立在数据治理到位的基础上：如果元数据没有讲清字段含义、标准没有统一业务术语，AI来了也读不懂数据。 数据中台不是项目，是能力——从L2走到L4的过程，本质上是这个能力从"能跑"到"能量化"再到"能自优化"的过程。 四、486项评估指标：从定性描述到量化体系 DCMM 1.0时代的评估以定性描述为主——"有没有制度""有没有流程""做还是没做"。这种方式的天然局限是：企业可以"搭个架子"拿出书面制度来应对评估，但制度是否真正执行、执行效果如何，很难验证。 DCMM 2.0将评估指标从441项扩展到486项，核心变化不是多了45项数字，而是评估逻辑从"有没有"升级为"做到了什么程度"。 486项指标大致可以归为四类： 制度类：有没有书面制度？是否定期评审和更新？制度覆盖哪些业务范围？ 执行类：标准覆盖率多少？质量规则启用率多少？问题修复及时率多少？这些不是看"有没有做"，而是看"做了多少、做得多快"。 效果类：数据质量趋势是向好还是恶化？业务部门的数据使用率在上升还是下降？已修复的问题复发率多少？ AI类（L4+新增）：AI辅助治理的覆盖率？智能推荐的采纳率？自动化的数据分类分级比例？ 对企业来说，486项指标意味着什么？最直接的影响是：不能再"建一个平台、写几份制度"就期望通过评估。DCMM 2.0要求的是持续的执行记录和可量化的效果数据——系统里有没有实际运行的规则、质量问题的修复有没有时间戳、标准的覆盖和落标有没有统计数字。这些都需要一个真正在运转的数据治理平台，而不是一堆架在文档服务器上的制度文件。 五、数据战略：评估不是考PPT，是考"路径" 数据战略是DCMM 2.0的第一个能力域，也是很多企业最容易"应付"的一个。它的三个能力项——数据战略规划、数据战略实施、数据战略评估——逐层递进，本质上是追问企业一个问题：你的数据投入有没有清晰的方向和可验证的进度？ 常见的问题是：战略在PPT里，规划在架子上，和实际建设脱节。许多企业的数据战略可以概括为"我们要成为数据驱动型企业"——这句话放在任何行业、任何规模的企业都能用，但既没有明确数据要支撑哪些业务目标，也没有倒推需要什么能力、怎么分阶段投入。 DCMM 2.0对数据战略的评估，考的其实是"路径"——你能不能把愿景拆解为三个可执行的动作：第一，明确当前业务最需要数据解决什么问题；第二，倒推解决这些问题需要什么数据能力；第三，制定分阶段的投入计划、资源保障和效果度量方式。如果战略评估发现一年前的战略目标和今天的实际建设之间没有关联，那说明战略本身没有起到"导航"作用。 理采存管用方法论从"理"阶段切入——梳理业务流程、盘点数据资源、明确数据权责——本质上就是在帮助企业把数据战略从一份PPT文档转化为一套可执行的工作计划。 六、数据治理：先解决"谁来管"，再谈"怎么管" 数据治理域的三个能力项——数据治理组织、数据制度建设、数据文化建设——在DCMM 2.0中的排列顺序本身就说明了优先级：先有组织，再有制度，最后才形成文化。 这与行业中的一个共识高度一致：数据治理首先是组织治理，其次才是技术治理。 很多企业的数据治理推进困难，不是因为缺平台、缺工具，而是因为"谁来管"这个问题一直没有被真正解决。以下三个误区反复出现： 误区一："建了中台=治理到位"。 平台是治理的技术载体，但平台不会自动产生治理。如果没有明确的治理组织、岗位职责和决策机制，中台只是一个数据存放系统——DCMM评估考的是"组织有没有建立跨部门的治理委员会""数据Owner有没有被任命并实际履行职责"。 误区二："这是IT部门的事"。 数据治理表面上看涉及模型设计、质量规则、元数据管理，好像都是IT工作。但数据标准的定义需要业务部门参与——"客户"是什么口径、哪个系统的"销售额"算数——这些问题IT部门回答不了。没有业务参与，标准推不动，质量闭环形不成。 误区三："任命了CDO就算有组织了"。 DCMM 2.0要求的是实体岗位和虚拟组织相结合的治理架构——CDO或数据管理部门是实体岗位，跨部门的数据治理委员会是虚拟组织，数据Owner和数据管家是业务侧的具体责任人。三者缺一不可。 从落地实践来看，上海某化工企业（企业名称已脱敏，下同）的做法值得参考：该企业成立了数据管理部并设立数据管家岗位，将数据治理纳入绩效考核——治理从"项目驱动"转变为"机制驱动"，从"IT部门的任务"转变为"各部门的日常工作"。数据中台工作空间模型支持的"一集团一中台、一公司一空间"的多组织适配，在技术层面为这种治理组织的落地提供了支撑。 七、数据架构：模型要在系统里"跑"，不只在文档里"存" 数据架构域四个能力项——数据模型、数据分布、数据集成与共享、元数据管理——核心考察的不是"模型文档写得有多详细"，而是"模型有没有在系统中落地执行"。 一个典型的失分场景：企业的数据架构设计文档非常完整，ER图、分层架构、数据流转图一应俱全。但实际去看数据仓库——ODS层、DW层、ADS层混在一起，跨层引用随处可见，当初精心设计的主题域模型被后来不断接入的新系统打破，没有人维护也没有人更新。模型在文档里"存"着，但在系统里并没有"跑"起来。 DCMM 2.0对数据架构的评估，关注的是架构的"可执行性"和"可维护性"——数据模型是否经过了评审和版本管理？数据分布是否能够展示核心业务数据在哪些系统中？数据集成是否规范统一而非每次临时写脚本？元数据是否被持续采集和维护？ 江西某国控集团（企业名称已脱敏，下同）在数据中台建设过程中，将10余个系统的数据进行整合，统一构建了十大主题库，形成分类明确、来源权威的数据仓库。这个过程的关键不是"把数据搬过来"，而是通过统一的数据架构设计，让分散在不同业务系统中的数据有了统一的结构和语义——这是DCMM数据架构域考察的核心能力。 数据中台的数据规划模块支持从模型设计到物理落地的全链路管理，数据底座实现ODS-DW-ADS分层架构——这些技术能力确保了架构设计不会停留在纸面上。 八、数据资产：从"管数据"到"管资产" 这是DCMM 2.0最重要的新增域。三个能力项——权属管理、价值评估、资产运营——各自对应数据资产化的三个核心问题：数据是谁的？值多少钱？怎么用起来？ 要理解这个域为什么在DCMM 2.0中单独成域，需要看三件事的时间线：2023年《企业数据资源相关会计处理暂行规定》发布，数据资产入表从学术讨论进入政策实操；2024年数据要素市场建设加速，各地数据交易所陆续开业；2025年DCMM 2.0发布，新增"数据资产"能力域。这三件事不是巧合——标准的升级是政策落地的配套动作，DCMM 2.0新增这一域，是在问企业一个尖锐的问题：你把数据管理起来了，但你知不知道自己的数据资产在哪里、值多少、能不能用？ 从工程落地的视角来看，数据资产域的能力建设可以拆为四步： 第一步：资产盘点。 全量扫描企业的数据资源——不是简单的"有多少张表"，而是识别哪些数据是核心业务依赖的、哪些有对外流通价值、哪些属于高价值但利用率低的数据。这一步的产物是数据资产目录的初稿。 第二步：质量保障。 对拟入表或拟流通的数据进行质量评价。这里涉及GB/T 36344-2018《信息技术 数据质量评价指标》[3]的六个维度——完整性、一致性、准确性、唯一性、时效性、可访问性。六个维度除可访问性外，其余五个直接影响数据资产的价值可评估性。 第三步：价值评估。 从成本法或收益法切入，协同律所完成合规审核、协同会计师事务所完成会计确认。 第四步：资产运营。 资产目录发布→业务申请使用→使用情况统计→目录持续迭代——这是一个持续运营的过程，不是一次性的盘点项目。 福建某交投集团（企业名称已脱敏，下同）的实践提供了一个完整的参考样本：该企业面对上千张表"家底不清"的现状，从数据确权入手，经过合规审核、质量评价（最终得分99.53分）、估值到入表，完成了首批数据资产的入表工作。这个案例说明，数据资产域不是理论上的"加分项"，而是已经走通的企业实践路径。 从行业趋势来看，数据资产化是数据治理的终极目标——DCMM 2.0新增这一域，本质上是在用标准的语言告诉企业：数据管理的终点，是让数据成为可计量、可运营、可产生财务价值的资产。 九、数据标准：从"写出来"到"跑起来" 数据标准域五个能力项——业务术语、主数据、参考数据、数据元、指标数据——覆盖了企业数据标准化的完整范围。DCMM 2.0考察的不是"有没有标准文档"，而是"标准有没有在系统中被执行"。 这是很多企业数据治理中最大的断层。标准体系文件可能有上百页，业务术语、代码集、指标口径都定义得清清楚楚。但新系统接入时，开发人员还是按照自己的习惯命名字段——"customer_id"、"cust_id"、"c_id"三张表是同一个意思，但系统不知道，人也不知道。标准"写出来"了但没有"跑起来"，问题的根因在于：标准文档没有和实际的数据管理平台打通。 落地的关键在于"在线管理+自动落标"三个环节：数据元、代码集、指标口径在数据管理平台中在线定义和发布；标准发布后与物理表的字段自动关联；数据接入时平台自动校验合规性——违规字段被标记、通知责任人、限期整改。 上海某化工企业的实践提供了典型场景：该企业统一了物料编码、业务术语和指标口径，解决了长期困扰的经营分析"口径不一"问题——销售部门报的"销售额"和财务部门的"收入确认"在统一标准后终于对应上了。数据中台标准管理模块支持从标准制定、发布、关联到落标校验的完整流程，让标准从"写在纸上"变成"跑在平台上"。 十、数据质量：形成"发现→定位→修复→复验"闭环 数据质量域四个能力项——数据质量需求、数据质量检查、数据质量分析、数据质量提升——构成了一个完整的质量闭环。DCMM 2.0在这里追问的，不是"你配了几条质量规则"，而是"问题发现之后谁来修？修了有没有验证？同类问题的复发率是多少？" 理解DCMM数据质量域，可以用一个"双框架"思路来定位： DCMM管能力成熟度：质量管理的流程是否闭环、是否有持续提升机制——这是"能力"视角。 GB/T 36344-2018管指标维度：从完整性、一致性、准确性、唯一性、时效性、可访问性六个维度定义具体查什么——这是"指标"视角。 两个框架互补——DCMM告诉你质量管理的流程应该长什么样，GB/T 36344告诉你质量检查的具体维度应该覆盖哪些方面。 从实践角度看，数据质量管理有两种技术模式： 强校验模式：在关键业务链路上前置拦截，数据不合规不入库。适合对数据准确性要求极高的核心业务系统（如财务核算、合规报送）。 旁路监测模式：数据正常入仓，质量检查在旁路并行扫描，发现问题打标记、生成告警、创建工单——不阻断正常的数据流转和业务使用。这种模式更适合多源归集和公共数据场景，因为不同来源的数据质量参差不齐，在入口处强拦会导致大量数据堵在管道里。 江西某国控集团的实践展示了质量闭环的效果：通过自动化质量稽核，核心数据质量问题从"人工发现→层层上报→跨部门协调→手动修复"的漫长流程，转变为"系统自动检测→告警推送责任人→修复后系统复验"的闭环，问题的修复周期从两周缩短到了两天。数据中台质量管理模块支持旁路监测模式和12类规则的可视化配置，覆盖从问题发现、标记、告警、工单到复验的完整闭环。 十一、数据安全：显著增强的分量 DCMM 2.0的安全域有三个实际变化值得关注。第一，能力项名称变更：从旧版的"数据安全策略/数据安全管理/数据安全审计"变更为"数据合规管理/数据安全防护/数据安全审计"——这不是换了个说法，"策略"变成"合规管理"意味着从内部管控视角转向外部法规遵从视角，"管理"变成"防护"意味着从制度要求转向技术执行——防御能力要可验证。第二，安全域的评估要求较DCMM 1.0显著增强，与《数据安全法》[4]和《个人信息保护法》[5]的合规要求对齐。第三，新增了外部数据流通中的数据安全考量——这与"数据应用流通"域的外部数据管理能力项形成呼应。 安全域的落地通常分三个层次： 第一层：分类分级。 首先要搞清楚敏感数据在哪里、什么级别。这一步是后续所有安全管控措施的基础——不知道数据敏感级别，加密和脱敏都是"盲打"。 第二层：权限管控。 谁能看、谁能改、谁能导出——基于数据分类分级的精细化权限控制，而不是"有账号就能看到所有数据"的粗放模式。 第三层：审计溯源。 谁在什么时间、什么IP、对什么数据做了什么操作——记录完整、可追溯、可举证。这一步看似是事后管控，但它的震慑作用往往比前面的防护措施更强——知道"被盯着"，行为自然会收敛。 数据中台的安全防护能力支持分类分级打标、敏感数据自动识别、动态脱敏和完整的审计日志功能，在技术层面为企业满足DCMM安全域要求提供了基础。 十二、数据生命周期：不只是"归档"那么简单 数据生命周期域（DCMM 2.0中称为"数据生存周期"）四个能力项——数据需求、数据设计与开发、数据运维、数据退役——覆盖了数据从"诞生"到"消亡"的全过程。 很多企业最容易忽略的是最后一个环节：数据退役。数据量在爆炸式增长——业务系统持续产生数据、数仓持续归集数据、分析层持续派生数据——如果没有生命周期策略，数据湖最终会变成数据沼泽。存储成本持续走高，查询性能持续下降，而大部分历史数据可能再也不会被访问。 DCMM 2.0对数据生命周期域的评估，关注的是企业有没有清晰的策略：数据的保留期限如何定义？热数据、温数据、冷数据如何分层存储？数据的归档和销毁有没有审批流程和执行记录？这些看似是运维层面的工作，但如果在平台建设初期没有纳入设计考量，后期补课的成本会很高。 数据中台的数据生命周期管理能力需要从"采"和"存"两个阶段就纳入设计——数据归集时标注数据源和时效性，数仓分层时明确各层的数据保留策略，确保数据在生命周期各阶段都是可管理的。 十三、数据应用：最终目的是"让数据被用起来" 数据应用流通域四个能力项——数据应用、外部数据管理、数据开放、数据服务——覆盖了数据价值释放的完整路径。DCMM 2.0考察的不是"你有没有BI报表"，而是"数据是否被业务部门实际使用并产生可衡量的业务价值"。 从企业数据应用的演进来看，大致可以分为三个阶段： 1.0 报表阶段：IT部门出报表，业务部门看报表。数据的使用是单向的、被动的，业务的用数需求需要排期、等待IT资源。 2.0 自助阶段：业务人员通过数据资产门户自主找数据、申请数据、使用数据。数据目录让业务知道"有什么数据"，API共享让业务接入数据的过程从"提需求→排期→开发"缩短为"申请→审批→调用"。 3.0 智能阶段：AI用数——用自然语言提问，系统自动转换为SQL查询并返回图表结果。这是DCMM 2.0 L4引入人工智能技术应用的技术落脚点之一：AI用数不是替代BI，而是降低用数门槛——让不懂SQL的业务人员也能直接向数据提问。 江西某国控集团的实践展示了数据应用释放价值的具体路径：通过API共享平台，数据快速赋能财务监管、科创数转等业务场景，业务人员的数据获取工作量减少了60%以上。DCMM 2.0 L4引入人工智能技术应用，意味着企业不仅要让数据能被用起来，还要让数据能被"智能地用起来"——AI用数智能体支持自然语言查询、无需SQL，是这一技术趋势的工程化回应。 十四、常见误区：DCMM贯标中最容易踩的五个坑 误区 实际情况 "建了数据中台=DCMM自然高分" DCMM考察的是数据管理能力，不是平台本身。有平台不等于有能力——平台是载体，治理组织、制度体系、闭环流程才是能力的内核。 "DCMM是IT部门的事" 数据战略和治理组织都是跨部门的事。从数据战略的制定到数据标准的落地，没有业务部门参与，推进难度会成倍增加。 "过了评估就万事大吉" DCMM是持续的能力建设，不是一次考试。尤其是数据资产域，资产目录需要持续运营、价值评估需要定期更新——"过了"只是开始。 "我们数据量不大，不需要DCMM" DCMM考察的是管理成熟度，和数据量大小没有直接关系。中小企业一样可以用DCMM框架建立规范的数据管理流程——规模小不代表不需要标准化。 "先买平台再做DCMM" 顺序反了。DCMM的框架告诉你应该具备什么能力，再据此评估需要什么平台。先做能力规划再匹配工具——"需要什么"比"买什么"更优先。 十五、从标准文本到企业落地："理采存管用"如何承载DCMM 2.0 DCMM 2.0搭建了评估框架，但标准本身回答的是"应该具备什么能力"，而不是"怎么一步步建起来"。在企业落地实践中，有三个框架常常同时出现，各自的角色定位不同： 框架 角色 一句话定位 DCMM 2.0 评估标尺 告诉企业数据管理能力到了什么水平 DAMA-DMBOK[6] 知识体系 告诉企业数据全生命周期中应该管理什么 理采存管用 工程路径 告诉企业从哪开始、按什么顺序、分几步走到资产化 三个框架不是替代关系，而是逐层递进——DCMM说目标、DAMA说范围、理采存管用说路径。 理采存管用与DCMM 2.0九大能力域在工程落地层面的对应关系如下： 理采存管用 对应 DCMM 2.0 能力域 中台动作 理 数据战略 → 数据治理 → 数据架构 梳理业务流程、盘点数据资源、建立治理组织 采 数据架构 → 数据生命周期 打通多源异构系统、流批一体数据归集 存 数据架构 → 数据标准 数仓分层建模、统一数据模型 管 数据治理/标准/质量/安全 元数据+主数据、质量规则配置、分类分级 用 数据资产 → 数据应用 资产目录发布、API共享、AI智能用数 说明：上表为工程落地视角下的对应关系示意，并非DCMM能力域与理采存管用阶段的严格一一对应。例如，"理"侧重战略、组织、制度与路线规划，而不仅是运营保障层面；"存"更侧重数仓开发和模型管理，与资产层各有侧重。 市场上已有部分数据中台产品将"理采存管用"方法论作为产品设计的底层逻辑。以康桥数据中台为例，从"理"阶段的数据资产权属梳理和标准规划，到"采"阶段的异构系统对接，再到"存"阶段的数仓分层建模、"管"阶段的元数据/标准/质量/安全一体化管控，直到"用"阶段的资产目录、API共享和AI智能用数——五个阶段对应DCMM 2.0九大能力域，形成"国标定目标、方法论定路径、产品定落地"的三层映射。康桥作为中国信通院《数据治理产业图谱3.0》[7]入选厂商和DCMM标准工作组成员单位，其方法论与产品设计本身就是对DCMM 2.0要求的工程化回应。 十六、企业贯标自查清单 以下检查清单按DCMM 2.0的九个能力域和三档目标等级给出关键自查项，企业可根据自身目标定位对照评估： 能力域 L2（受管理级）自查 L3（稳健级）自查 L4（量化管理级）自查 数据战略 有书面数据规划？ 规划定期更新？有投资保障？ 战略执行效果可量化评估？ 数据治理 有数据管理岗位？ 有治理委员会？制度覆盖核心域？ 治理效能有指标可查？ 数据架构 核心系统有数据模型？ 模型统一管理？有数据分布图？ 架构变更影响可预判？ 数据资产 —（新增域起步） 有资产目录？知道核心数据在哪？ 资产价值可评估？可入表？ 数据标准 核心字段有标准？ 标准在系统中执行？有落标记录？ 标准覆盖率≥95%？ 数据质量 有质量问题记录？ 有质量闭环（发现→修复→复验）？ 修复时长≤2小时？复发率可查？ 数据安全 有数据安全制度？ 完成分类分级？有审计日志？ 安全事件可举证可追溯？ 数据生命周期 有备份策略？ 有归档/销毁流程？ 生命周期策略自动执行？ 数据应用 有BI报表？ 业务部门能自助找数用数？ 已部署AI用数能力？ 起步建议：从较为稳妥的做法来看，通常先锚定一个高价值数据域（如客户域、财务域），用3到6个月跑通"标准→质量→资产目录"的最小闭环，验证效果后再横向扩展到其他域。 十七、FAQ Q1：DCMM 2.0 和 1.0 的核心区别是什么？之前的评估结果怎么办？ 最重要的变化是新增了"数据资产"能力域（排第4位），能力域从8个变成9个，评估指标升级到486项。安全要求较1.0显著增强，L4量化管理级引入人工智能技术，L2为新的评估基准等级。DCMM 2.0（GB/T 36073-2025）于2026年7月1日实施后，旧版标准（GB/T 36073-2018）已废止。此前按1.0完成的评估结果，在新版评估中需按2.0框架重新对标。 Q2：企业数据量不大，DCMM评估有必要吗？ DCMM评估考察的是数据管理能力的成熟度，和企业数据量大小没有直接关系。即使是中小企业，也可以用DCMM框架建立规范的数据管理流程——规模小不代表不需要标准化。DCMM 2.0的L2评估基准等级对企业的起步要求也相对友好。 Q3：L4引入AI技术应用，目前没有AI能力怎么办？ 这是DCMM 2.0让不少企业感受到压力的一个变化。从项目统计来看，多数建了数据中台的企业目前在L2-L3区间，距离L4通常需要12到24个月。比较稳妥的做法是先在L3阶段把数据底座夯实——标准、质量、元数据——同时评估AI应用场景。AI用数能力建立在数据治理到位的基础上：元数据没有讲清字段含义、标准没有统一业务术语，AI来了也读不懂数据。 Q4：九个能力域应该从哪个开始做？ 从DCMM 2.0各能力域之间的依赖关系来看，数据治理和数据架构是两个基础域——治理回答了"谁来管"，架构回答了"数据怎么放"。然后数据标准→数据质量→数据安全是三个执行域。数据资产域依赖前面几个域的基础能力——没搞清楚有什么数据、数据质量不可信，资产化就缺乏根基。数据应用是最终价值出口。不过，企业在实践中通常不需要等所有域都建完再推进下一个域——可以从当前最突出的问题域入手，同时在低投入的域（如数据战略梳理）上同步启动。 Q5：理采存管用和DCMM 2.0九大能力域怎么对应？ 理→战略/治理/架构（规划和组织），采→架构/生命周期（数据归集），存→架构/标准（模型设计），管→治理/标准/质量/安全（全域管控），用→资产/应用（价值释放）。详见第十五节的对照表和三层映射图——工程落地层面的大致对应关系，不是严格一一映射。 参考来源 [1] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），国家市场监督管理总局、国家标准化管理委员会，2025年12月31日发布 — openstd.samr.gov.cn [2] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号），2023年8月 — gov.cn [3] GB/T 36344-2018《信息技术 数据质量评价指标》，国家市场监督管理总局、国家标准化管理委员会，2018年6月 — openstd.samr.gov.cn [4] 《中华人民共和国数据安全法》，全国人民代表大会常务委员会，2021年6月10日通过，2021年9月1日起施行 — flk.npc.gov.cn [5] 《中华人民共和国个人信息保护法》，全国人民代表大会常务委员会，2021年8月20日通过，2021年11月1日起施行 — flk.npc.gov.cn [6] DAMA International，《DAMA数据管理知识体系指南（DAMA-DMBOK2）》（第二版），机械工业出版社，2020年 [7] 中国信息通信研究院，《数据治理产业图谱3.0》，2024年12月 作者注：本文基于DCMM 2.0（GB/T 36073-2025）标准框架和行业公开数据编写，案例均来自已脱敏的企业实践（企业名称已脱敏，下同）。文中产品相关内容仅为说明方法论落地方式，不代表任何商业推荐。 [8] 康桥数据，《数据治理实战指南》，— dg-guide.html
一、为什么数据质量不能只看“规则数量” 在一次数据治理平台选型评审会上，三家厂商都展示了“数据质量管理能力”。第一家强调内置规则数量，第二家展示了质量报表，第三家重点介绍告警看板。听起来都不错，但治理经理真正关心的问题并没有得到完全回应：这些规则从哪来？能不能对应企业的数据标准？发现问题后能不能定位到源系统、源表、字段？责任部门怎么修？修完后是否自动复验？ 这正是数据质量平台评估中最常见的误区：把质量规则数量当成质量管理能力。 真正的数据质量管理，不能只停留在检查层面。它应覆盖质量定义、规则配置、质量监测、问题定位、责任修复、复验归档和持续运营。否则，规则越多，可能只是告警越多，治理团队反而增加了新的人工处理负担。 因此，评估数据治理平台的数据质量能力，需要一套更完整的模型。本文采用“双框架”思路：用 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《信息技术 数据质量评价指标》 3.DAMA International，《DAMA数据管理知识体系指南（DAMA-DMBOK，第2版）》
盛夏正好，宜入山水。这个周末，康桥数据以“数智赋能·聚力前行”为主题的团建活动圆满结束。
一、选型误区：功能越多，不代表越适合 “这家厂商功能很全，标准、质量、元数据、主数据、资产目录、AI 都有。但我们上线后，业务部门还是不知道去哪找数据。” 一位企业 CDO 在复盘数据治理平台选型时提到的这句话，很能代表很多团队的困惑。选型阶段，厂商功能清单看起来都很完整，演示环境也很顺畅。真正落地后才发现，企业需要的不是一套“什么都有”的系统，而是一套能贴合自身治理阶段、组织结构和业务痛点的平台能力。 数据治理平台选型最容易掉进一个误区：把功能数量当成能力深度。功能列表越长，越容易让人产生安全感。但数据治理不是功能堆叠，而是一个从摸清家底、汇聚数据、建立模型、治理管控到业务使用的闭环。 “理采存管用”可以作为一套更清晰的选型语言。它不先问“这个平台有多少功能”，而是依次追问五个问题：家底是否理得清，数据是否采得稳，模型是否存得住，质量和标准是否管得好，业务是否用得上。 二、选型前先问三个问题 在接触厂商之前，企业最好先问清楚三个问题。 第一个问题：当前最痛的是哪一类问题？ 如果核心问题是数据孤岛，重点应放在数据集成和数据架构能力上。如果核心问题是数据不可信，质量规则、主数据、标准管理和问题闭环更关键。如果核心问题是业务部门用不上数据，资产目录、API 服务和 AI 用数能力就要提前纳入评估。 第二个问题：组织形态有多复杂？ 单体企业、集团企业、政务多部门场景，对平台架构的要求不同。单体企业可能更关注轻量部署和快速见效；集团企业则要考虑总部统一标准与子公司自治；政务场景还要考虑跨部门共享、权限边界和数据安全。 第三个问题：是一次性建设大平台，还是先跑通一个数据域？ 很多企业适合先选择一个高价值数据域做样板，比如客户域、供应商域、物料域、监管对象域。先在一个域里跑通“理采存管用”的闭环，再扩展到更多业务域，通常比一开始追求全域覆盖更稳妥。 三、模块一“理”：平台能不能帮你摸清家底 “理”是选型中最容易被跳过的一步。很多项目一上来就谈数据接入、报表和大屏，却没有先问清楚：企业到底有哪些核心数据资产？哪些数据需要治理？谁对这些数据负责？标准在哪里？ 选型时，理这一模块至少要看四类能力。 第一，是否支持数据资产目录初建。平台要能把数据资源按业务域、系统来源、责任部门、更新频率、质量状态等维度组织起来，而不是简单列出数据库表。 第二，是否支持数据标准管理。数据元、代码集、指标口径、业务术语，应能在线编制、审核、发布和迭代。 第三，是否支持主数据管理。对于客户、供应商、物料、组织、项目等核心实体，平台要能帮助企业建立统一编码和映射关系。 第四，是否支持责任配置。数据资产、数据标准和质量问题都应有责任人，否则后续治理闭环很难落地。 江苏某建筑装饰集团（企业名称已脱敏）就是典型场景。该集团旗下 200 余家区域子公司、近百个项目部，同一材料在不同子公司有不同名称，供应商和项目部编码也各自为政。项目中，团队先统一物料、供应商、项目部等核心主数据编码，再建设集团级数据底座。治理后，跨公司对账从 5 天缩短至 1 天，数据纠纷减少 80%。 这说明，选型时不能只问“有没有主数据模块”，还要问平台能不能支撑企业先把核心实体理清楚。 四、模块二“采”：不是能接就行，要看接得稳不稳 “采”解决的是数据如何进入平台。很多厂商都会说自己支持多源接入，但企业在 POC 阶段要验证的不是“支持”两个字，而是真实环境下能否稳定运行。 选型时建议重点看四点。 第一，支持哪些数据源。常见数据源包括 Oracle、MySQL、SQL Server、PostgreSQL、国产数据库、API、文件、消息等。需要注意的是，数据治理平台通常不直接处理物联网协议；如果涉及设备数据，应先由物联网平台完成接入，数据中台再对接该平台获取数据。 第二，是否支持全量和增量。很多项目初期全量同步跑得通，但后续增量同步、失败重跑、断点续传、任务调度才是长期运行的关键。 第三，配置方式是否友好。可视化任务配置、拖拽式数据加工、日志查看和异常预警，会显著影响团队后续运维成本。 第四，是否使用标准接口。过度依赖定制接口，会让企业在后续系统变更时持续付出集成成本。 POC 时可以让厂商接入一套真实数据库，跑一次全量同步，再配置一次增量同步，观察配置步骤、运行日志、异常处理和任务重跑机制。这个测试比看兼容列表更有说服力。 五、模块三“存”：模型和工作空间决定平台能不能扩展 数据采进来以后，如果仍然像原系统一样散乱堆放，治理平台的价值会打折扣。“存”关注的是数据如何建模、分层和组织。 企业可以从两个角度评估。 一是模型能力。平台是否支持 ODS、DW、ADS 等分层？能不能按主题域组织数据？模型定义是否只是文档，还是会影响真实的数据存储、开发和治理规则？ 二是组织扩展能力。对于集团企业和多部门场景，工作空间模型很关键。平台是否支持总部统一标准，同时允许子公司或部门在自己的空间内独立管理数据资产、权限和应用？是否支持跨空间共享和审批？ 江苏某建筑装饰集团的“集团中台+公司空间+项目场景”就是这类能力的体现。总部统一主数据和治理标准，子公司保留独立操作空间，项目部可以根据场景使用数据。这种架构既满足集团管控，也保留了业务灵活性。 选型时，可以要求厂商现场创建两个业务空间，验证标准继承、权限隔离和跨空间数据共享。这个动作能快速看出平台是真正支持多组织治理，还是只是用角色权限模拟组织边界。 六、模块四“管”：治理平台的核心在这里 “管”是数据治理平台最核心的部分。它决定数据是否读得懂、信得过、管得住。 子能力 选型问题 POC 动作 元数据 是否自动采集？是否支持手动补全？ 接入 50 张表，看元数据采集和字段解释 主数据 是否能统一核心实体编码？ 建一个供应商或物料主数据标准 数据质量 是否支持旁路监测？ 配一条真实规则，跑扫描、告警、工单、复验 数据安全 分类分级、脱敏、权限粒度如何？ 用不同角色访问同一数据集 这里有几个术语需要说清楚。自动采集元数据，指平台自动抓取表结构、字段、注释、变更等信息，而不是靠人工逐表录入。旁路监测，指数据正常入仓后，质量模块并行扫描，发现问题后打标记、告警或生成工单，不阻断原有数据链路。落标，则是把已发布的数据标准关联到真实表字段和数据对象上，检查实际数据是否符合标准。 选型时，不建议只听厂商介绍“支持数据质量”。更有效的办法是拿一个真实痛点做 POC，比如“同一供应商在三个系统里名称不一致”，让厂商现场演示规则配置、扫描、定位、分派、修复和复验。 七、模块五“用”：业务部门能不能自己找到并使用数据 很多数据治理平台失败，不是因为数据没接进来，而是业务部门仍然用不上。 “用”模块要看四类能力：资产目录能不能被业务语言检索，数据申请是否线上化，API 或数据集能否自助发布，业务人员是否能通过报表或 AI 用数入口获得数据。 江苏某市监局的数据治理平台建设就体现了这一点。该局原本存在数据散、标准乱、共享难、监管繁等问题。项目中，平台建设了全盘元数据管理、数据质量管理、API 全生命周期管理和统一门户。上线后，监管人员日均登录系统次数减少 90% 以上，数据需求响应从天级缩短至分钟级。 这类成果说明，“用”不是最后简单做几张报表，而是把前面理、采、存、管形成的可信数据，转化成业务人员可访问、可申请、可调用的数据服务。 POC 阶段可以安排一名非技术用户参与测试：让他用业务语言搜索一个数据资源，查看质量状态，发起申请，并将一个查询结果发布为 API 或数据集。这个过程能直接检验平台是否真正面向业务使用。 八、五模块选型速查表 模块 核心问题 必看能力 不建议接受的回答 理 家底清不清 资产目录、标准、主数据 “先实施后慢慢整理” 采 数据进得来吗 多源接入、增量、调度 “接口可以定制开发” 存 架构撑得住吗 分层模型、工作空间 “一个实例管所有组织” 管 数据信得过吗 元数据、质量、权限 “质量规则要写 SQL” 用 业务用得上吗 目录、API、AI 用数 “业务找 IT 提需求即可” 这张表的作用不是替代详细招标文件，而是帮助决策者抓住主线。功能清单可以很长，但真正决定项目成败的，往往是这五个模块能否形成闭环。 九、从方法论到产品模块：对应关系示意 理采存管用不是厂商宣传话术，而是一套检查产品能力是否闭环的框架。选型时看“理”，是在看资产盘点、标准、主数据和治理责任；看“采”，是在看数据接入和集成稳定性；看“存”，是在看模型、分层和空间架构；看“管”，是在看标准、元数据、质量、安全是否能运行；看“用”，是在看数据是否能被业务持续使用。 部分产品如康桥数据中台，在产品设计上按这一路径组织数据标准、数据集成、数仓建模、质量管理、资产目录、API 服务和 AI 用数等模块。企业选型时需要关注的，不是这些模块名称是否都出现在菜单里，而是模块之间能否形成从数据产生到数据消费的流程。 上述对应关系是选型视角下的能力示意，并非标准能力域与产品模块的严格一一对应。企业仍应结合自身数据基础、组织形态和预算节奏确定优先级。 十、FAQ Q1：中小企业是否需要五个模块一次性全上？ 不需要。中小企业通常更适合从一个最痛的数据域开始，先跑通“理+管+用”的最小闭环，再逐步补强采集、建模和自动化能力。 Q2：功能清单看起来都差不多，怎么判断差异？ 用真实数据做 POC。不要只听“支持”，而要看厂商能否跑完标准定义、数据接入、质量扫描、问题闭环、资产发布和业务申请的一条完整链路。 Q3：开源工具能不能替代数据治理平台？ 部分环节可以，例如采集、调度、数据开发。但主数据、质量闭环、权限、资产目录和组织流程通常需要额外集成，长期维护成本要算清楚。 Q4：理采存管用是不是只适合康桥？ 不是。它可以作为通用选型框架，用来检查任何数据治理平台是否覆盖完整的数据管理闭环。康桥数据中台只是较明确地按这一路径组织产品模块的一个例子。 参考来源 DAMA International，《DAMA数据管理知识体系指南（DAMA-DMBOK，第2版）》 国家市场监督管理总局、国家标准化管理委员会，《数据管理能力成熟度评估模型》（GB/T 36073-2025） 全国人民代表大会常务委员会，《中华人民共和国数据安全法》
一、贯标之后，真正难的是“能力怎么建” 很多企业第一次接触 DCMM 时，关注点都放在“怎么评”“能评几级”“材料怎么准备”。但真正做过一次差距评估后，数据团队往往会遇到另一个更实际的问题：报告列出了很多短板，可这些短板怎么排成建设计划？ 评估报告里可能写着：数据标准体系不完善，数据质量闭环不足，元数据覆盖不完整，资产目录尚未形成业务化使用，治理组织职责不清晰。这些判断都对，但如果不能转化为行动，评估就会停留在诊断层面。 DCMM 2.0（GB/T 36073-2025）给企业提供的是能力目标。它帮助企业看清数据战略、数据治理、数据架构、数据资产、数据标准、数据质量、数据安全、数据生存周期、数据应用流通等方面的成熟度。但从目标到落地，中间还需要一套工程路径。 “理采存管用”可以理解为这样的路径：先理清目标、组织和家底，再采集数据、建设模型、治理质量和标准，最后让数据被共享、被应用、被持续运营。DCMM 说明要达到什么水平，理采存管用则帮助企业回答从哪里开始、按什么顺序做、每一步交付什么。 二、先把 DCMM 评估结果翻译成三类差距 企业拿到评估结果后，不宜马上把每个问题都变成一个项目。较为稳妥的做法，是先把问题归成三类。 差距类型 常见表现 后续建设重点 组织差距 有制度无责任人，有委员会无运行机制 治理组织、数据管家、考核机制 管理差距 有标准文档，无标准执行记录 标准落标、质量规则、元数据责任 平台差距 有系统菜单，无流程闭环 资产目录、质量工单、血缘追溯、API 服务 组织差距决定事情有没有人负责。数据治理首先是组织治理，其次才是技术治理。如果企业没有数据责任人、数据管家、治理委员会或跨部门协调机制，平台再完整也容易变成少数技术人员维护的系统。 管理差距决定规则能不能执行。标准、制度、流程写出来并不难，难的是让它进入数据接入、建模、质量检查、资产发布和业务使用的日常过程。 平台差距决定执行能不能被记录。没有平台承载，很多治理动作只能靠会议纪要、Excel 和人工催办，难以形成可复验的能力。 三、用“理”把评估问题变成治理目标 “理”是很多企业最容易低估的一步。它不是写一份规划方案，而是把治理目标、组织职责和数据家底理清楚。 在 DCMM 贯标背景下，“理”阶段至少要产出四类内容：数据治理目标、核心数据资产清单、数据标准框架、责任矩阵。没有这些内容，后面的采集、建模和质量规则都容易失去边界。 福建某交投集团的资产入表实践可以作为参考。项目启动时，企业拥有充电系统、调度系统、安防系统等多类业务数据，上千张业务表分散在不同系统中。表面上看数据不少，但企业并不清楚哪些数据真正有价值、质量如何、是否具备入表条件。项目首先做的不是写应用，而是全量数据资产盘点，形成标准化的数据资产目录，再进入质量评价和合规审核。 这个顺序对 DCMM 贯标同样重要。企业只有先知道自己有什么数据、哪些数据重要、责任人是谁，才能进一步讨论标准、质量、共享和应用。 四、用“采”和“存”把分散数据变成可治理对象 “采”解决的是数据从哪里来、如何进入统一平台的问题。“存”解决的是数据进入平台后如何组织、如何建模、如何形成稳定的数据底座。 很多企业在评估中暴露的问题，并不是没有数据，而是数据散落在不同系统中。业务系统各自建设，接口方式不同，字段口径不同，更新频率不同。这样的数据即使能被导出，也很难被持续治理。 采集阶段要明确数据源、采集方式、采集频率和责任边界。常见数据源包括数据库、API、文件、消息等。对于设备或物联网相关数据，通常应先由物联网平台完成接入，数据中台再对接该平台获取结构化数据，不宜把数据治理平台定位为直接处理物联网协议的系统。 存储和建模阶段，则要把分散数据纳入统一的数据仓库分层和主题域模型中。常见做法是 ODS、DW、ADS 分层：ODS 保留贴源数据，DW 形成治理后的主题数据，ADS 面向应用和服务。 江西某国控集团在建设数据中台时，对接了协同办公、财务、投资、产权、人力、党建等 10 余套业务系统，并围绕办公、人力资源、财务管理、法律风控、股权管理等主题建立数据仓库。这一步的价值在于，把原本分散的监管数据变成可统一管理、可共享、可分析的数据对象。 五、用“管”把标准、质量、元数据做成闭环 “管”是 DCMM 能力建设中最能体现成熟度的环节。很多企业的数据治理项目之所以效果不稳定，原因不是没有规则，而是规则没有形成闭环。 标准管理要解决“同一个数据是否有同一个说法”。字段命名、数据元、代码集、指标口径，都应从文档进入平台，并与真实表字段和资产目录关联。 质量管理要解决“数据是否可信”。质量规则不能只是跑出报表，还要形成发现、定位、修复、复验的流程。较为稳妥的技术模式是旁路监测：数据正常入仓，质量模块并行扫描，发现问题后打标记、发告警、生成整改工单，不阻断业务链路。 元数据管理要解决“数据是否可理解、可追溯”。基础元数据可以自动采集，平台内链路可以自动记录血缘关系；对于平台外脚本、历史任务等未覆盖环节，则需要支持手动维护补全。 华东某大型化工企业在数据中台建设过程中，同步建立数据标准和质量管理机制，并成立数据管理部、设立数据管家岗位，将数据治理纳入绩效考核体系。项目完成后，库存周转率提升 28%，订单交付及时率提升至 91%，报表出具周期提前 4 天。这个案例说明，“管”不是后台配置项，而是组织机制和平台流程共同运行的结果。 六、用“用”证明治理能力真的产生价值 贯标不是终点。数据治理能力是否成熟，最终还要看业务是否能使用可信数据。 “用”阶段包括资产目录、数据服务、API 共享、报表分析、AI 用数等能力。企业应当让业务人员能够用业务语言找到数据，看到数据来源、质量状态和申请条件，并在授权范围内获取数据服务。 江西某国控集团建设数据资产目录和 API 共享服务后，监管数据可以更快支撑财务监管、风险预警和穿透式查询。项目完成后，业务人员工作量减少 60% 以上。这个结果并不是单个应用带来的，而是前面的标准、采集、建模、质量和资产目录共同支撑的。 部分产品如康桥数据中台，会将数据标准、元数据、质量规则、资产目录、API 服务和 AI 用数组织在同一套平台中。但工具只是载体，企业仍需要治理组织和运营机制，让“用”中发现的问题反向推动“管”和“理”的持续改进。 七、三阶段路线：从差距评估到长效运营 把 DCMM 评估结果转成建设计划时，不建议一次性铺开所有能力域。更可行的方式是三阶段推进。 阶段 参考周期 核心任务 产出 第一阶段：理清基线 4-6 周 资产盘点、标准梳理、质量基线 资产清单、标准清单、质量报告 第二阶段：跑通闭环 6-8 周 选 1-2 个核心数据域跑通采存管用 可复用流程、样板数据域 第三阶段：扩展运营 持续 横向扩业务域，纵向提高质量与应用 常态化运营机制 第一阶段不要追求“大而全”，重点是摸清家底、识别最有价值的数据域。第二阶段要打样，选择一个业务方愿意参与、数据基础相对清晰、价值容易看见的场景，跑通从标准到应用的闭环。第三阶段再扩展到更多业务域，同时把规则、工单、报告、资产目录和培训机制固化下来。 八、对应关系示意：DCMM 2.0 × 理采存管用 × 平台能力 理采存管用 侧重能力 平台支撑 理 数据战略、治理、资产盘点 资产目录初稿、组织和标准框架 采 数据架构、生存周期 数据集成、全量/增量同步 存 数据架构、数据标准 分层模型、主题库 管 标准、质量、安全、主数据 元数据、主数据、质量规则、分类分级 用 数据资产、应用流通 数据服务、API、BI、AI 用数 上表是工程落地视角下的对应关系示意，并非 DCMM 能力域与理采存管用阶段的严格一一对应。比如“理”侧重战略、组织、制度和家底盘点，不只是运营保障；“存”侧重数据模型和数仓分层，也不等同于资产管理。 真正有价值的，是把评估语言转换为建设语言。评估说“数据标准能力不足”，建设语言就应转成“核心数据元标准未发布、字段未落标、标准执行缺少记录”。评估说“数据质量闭环不足”，建设语言就应转成“质量规则未覆盖核心表、问题无工单、修复后无复验”。这样，评估才会真正推动能力提升。 九、FAQ Q1：DCMM 贯标应该先补制度还是先建平台？ 通常应先通过“理”阶段明确目标、家底和责任基线，再选择核心数据域跑平台闭环。制度和平台不宜割裂，制度要在平台流程中被执行，平台也要反映制度要求。 Q2：评估报告问题很多，先做哪一项？ 建议优先选择业务价值高、数据基础相对清晰的数据域，从标准、质量、元数据、资产目录四件事跑通闭环。一个样板域跑通，比多个领域同时浅尝更容易形成共识。 Q3：理采存管用能替代 DCMM 吗？ 不能。DCMM 是能力评估标准，理采存管用是工程实施路径。前者回答“应该达到什么水平”，后者回答“怎么把能力建起来”。 Q4：企业已有数据平台，还需要重新建设吗？ 不一定。可先评估现有平台是否支撑标准执行、质量闭环、血缘追溯和资产服务。如果已有平台能补齐关键能力，不必推倒重来；如果核心流程无法闭环，再考虑模块补强或平台升级。 参考来源 1. 国家市场监督管理总局、国家标准化管理委员会，《数据管理能力成熟度评估模型》（GB/T 36073-2025） 2.DAMA International，《DAMA数据管理知识体系指南（DAMA-DMBOK，第2版）》 3.财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号）
一、为什么 DCMM 三级不是“有平台就够了” 一家准备做 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》 GB/T 36344-2018《信息技术 数据质量评价指标》
一、选型误区：为什么看了十几家厂商还是选不对？ 一位制造企业的CDO在选型三个月后，在一次内部复盘会上说了这样一段话： "每家厂商的PPT都差不多——功能列表两百多项，DAMA、DCMM这些词都在封面上挂着。但我想知道的是：你们的元数据采集是自动的还是手动的？数据质量规则怎么配？标准落标是怎么做的？一问这三个问题，三家厂商的回答几乎一样——'这个我们支持，具体要看实施配置'。" 他停顿了一下，补了一句更让人难受的话："后来我才意识到，我问的问题，和厂商回答的'支持'，根本不在一个频道上。" 这个场景折射出数据中台选型中一个普遍困境：功能列表高度同质化，每家都写着"支持数据治理""支持数据质量""支持元数据管理"，但"支持"这个词覆盖的范围可以从"系统里有个菜单"到"全自动采集+闭环追溯"——差距大到足以决定项目成败。 根据我们在实际选型咨询中观察到的案例，以下三个陷阱最具代表性： 陷阱一：功能列表越长越好。 某中型汽车零部件企业投入200余万元采购了一套"一站式AI数据平台"，功能清单超过230项。上线三个月后，数据质量模块仅配置了不到20%的规则，元数据采集仍需手工录入。功能列表的长度不等于功能落地的深度——买了一套百科全书，不等于学会了里面的知识。 陷阱二：POC跑通等于项目能落地。 厂商演示环境的数据干净、规范、标准化——这是精心准备过的。但真实的IT环境里，异构系统、脏数据、编码混乱才是常态。POC跑通只能证明"理想条件下产品功能可用"，不能证明"你的环境里产品能持续运转"。选型时如果把POC当终审，上线后面临的第一个问题往往是"为什么演示时跑得通，我的数据一进去就报错"。 陷阱三：选型只看功能不看组织匹配。 DAMA数据管理知识体系开篇就强调了一条原则——"数据治理首先是组织治理"。数据中台选型不只是选一个技术平台，更是选择一个未来几年支撑数据管理组织运转的基础设施。选型时不评估厂商能否帮你建立数据治理的组织能力，等于买了一把好刀但没人会用——工具再锋利，还是切不动。 这三个陷阱指向同一个根因：缺少一套标准化的评估语言。 功能列表是厂商写的，POC环境是厂商搭的，组织匹配的判断标准是模糊的。选型者需要的不是一个更长的检查清单，而是一把第三方标尺。 二、评估框架：DAMA凭什么能做选型标尺？ 2.1 DAMA是什么 DAMA（国际数据管理协会）发布的《DAMA-DMBOK数据管理知识体系指南》被广泛视为数据管理领域的"百科全书"。它不隶属于任何厂商，而是一个由全球数据管理从业者共同维护的开放知识体系。其官方定义清晰界定了数据管理的范畴： "Data Management is the development, execution, and supervision of plans, policies, programs, and practices that deliver, control, protect, and enhance the value of data and information assets throughout their lifecycles." 简言之：数据管理是围绕数据全生命周期，开展规划、执行和监督的制度、流程与实践活动。这个定义本身就隐含了选型的关键视角——你不是在选一个软件，而是在评估一个产品能否支撑完整的制度、流程与实践活动。 DAMA-DMBOK将数据管理能力划分为11个知识领域：数据治理、数据架构、数据建模与设计、数据存储与操作、数据安全、数据集成与互操作、文档与内容管理、参考数据与主数据、数据仓库与商业智能、元数据管理、数据质量。这11个领域覆盖了数据管理从组织到技术、从规划到运营的完整拼图。 2.2 为什么用DAMA做选型标尺 在数据中台选型中，常见的三种"标尺"各有缺陷： 选型方式 典型做法 核心缺陷 看功能列表 对比各厂商功能清单，按"有/无"打分 "支持"的深度差异巨大——菜单里有不等于真能用 看案例数量 数厂商PPT里的客户Logo数量 "做过"不等于"做成了"，更不等于"适合你" 看技术栈 评估数据库、计算引擎、中间件 技术是必要条件，不是充分条件——技术强≠治理能力强 DAMA作为标尺的优势在于三个"不"：不是厂商标准——没有哪个厂商能说自己"定义了DAMA"；不是功能列表——每个知识领域对应的是一个能力体系而非一个菜单项；不是静态框架——11个领域之间有内在联系，能帮你看到产品的系统性而非单点功能。 用DAMA做选型评估，本质上是把"这个产品有什么功能"的问题转化为"这个产品在DAMA的每个知识领域下，能力深度到了什么程度"。前者是厂商视角，后者是用户视角。 2.3 DCMM 2.0：国内标准的补充 DAMA是国际标准，告诉你"该建什么能力"。作为补充，中国国家标准DCMM 2.0（GB/T 36073-2025）即将于2026年7月1日正式实施，告诉你"建到了什么水平"。DCMM 2.0相比1.0版本（GB/T 36073-2018）有一个关键变化：能力域从8个扩展为9个，新增了"数据资产"能力域，将数据资产目录、数据资产化等要求提到了与数据质量、数据安全同等的高度。 DAMA和DCMM的关系可以这样理解：DAMA是能力地图，DCMM是水平刻度。 选型时先用DAMA的11个知识领域做能力覆盖评估，看产品是否具备应有的能力模块；选型后可以用DCMM 2.0的九大能力域做成熟度自评，规划后续的能力提升路径。两者结合，构成了从能力定义到成熟度评价的完整选型框架。 2.4 DAMA 11个知识领域全景速览 以下将DAMA 11个知识领域与数据中台选型要检查的核心问题逐一对应： DAMA领域 核心问题 选型要检查什么 数据治理 谁决策、谁负责、怎么考核？ 权限体系是否覆盖"管/建/用"全链路、治理流程能否数字化闭环 数据架构 数据怎么组织、怎么流动？ 是否支持分层建模、模型即执行、多数据域独立管理 数据建模与设计 概念模型→逻辑模型→物理模型能否贯通？ 数仓分层是否可灵活配置、模型定义和执行是否一体 数据存储与操作 数据存在哪、怎么管？ 存储引擎兼容性、私有化部署、信创适配 数据安全 谁能看、谁能改、谁能导出？ 分类分级、脱敏策略、权限粒度 数据集成与互操作 不同系统怎么通？ 多源异构接入、流批一体、标准化接口 参考数据与主数据 核心实体能不能统一编码？ 编码规则定义、多系统映射合并、变更同步 元数据管理 数据从哪来、什么意思？ 自动采集能力、血缘分析跨系统追踪 数据质量 数据准不准、全不全？ 规则配置方式、闭环追溯机制、是否非侵入 数据仓库与商业智能 分析和报表怎么支撑？ 自助分析、可视化、业务人员学习成本 文档与内容管理 非结构化数据怎么管？ 知识库、文档管理、非结构化数据处理能力（选型次优先级） 上述11个领域中，"文档与内容管理"在数据中台选型中优先级较低（通常由独立的ECM/知识管理系统承载），其余10个领域均是选型评估的核心维度。下文将10个领域进一步合并为7个可操作的评估维度，从基础能力到治理能力到应用能力逐层展开。 三、关键维度（上）：基础能力四维检查 本章覆盖DAMA框架中与"数据如何进来、存在哪里、怎么组织"相关的四个基础维度。这四个维度决定了数据中台的"底盘"稳不稳。 维度一：数据治理——组织能力，不是"权限管理"菜单 DAMA将"数据治理"列在11个知识领域的第一位，定义为"对数据资产行使权力与实施管控的权威体系，涵盖问责机制与决策权的分配"。翻译成选型语言就是：产品能不能支撑一个数据治理组织的运转。 很多数据中台产品在"治理"这个维度上的交付物是"用户管理"+"角色管理"两个菜单。这是技术权限，不是治理组织。DAMA意义上的数据治理，需要回答的是：谁对数据质量负责？谁审批数据标准变更？谁管理数据资产目录？这些问题不是靠RBAC权限模型能解决的。 DAMA要求 选型检查项 实操验证方法 治理组织和制度建设 产品是否支持多角色分权？角色体系是否覆盖"管/建/用"全链路？ 要求在系统里创建一个"数据质量管理员"角色，指定其管辖范围（如仅负责某数据域），看是否能实现 治理流程数字化 质量问题从发现→分配→修复→验证，能否在平台内形成完整闭环？ 要求演示一个完整的数据质量工单流程——发现问题→指派责任人→修复→自动复验→关闭 核心判断标准：如果一个中台的治理能力只能用"用户管理"+"角色管理"两个功能来描述，那它做的是技术权限而非治理组织。DAMA意义上的治理能力应当具备三个基本特征：角色可定义、流程可闭环、责任可追溯。 维度二：数据架构——模型在系统里跑，不在PPT里 DAMA对数据架构的定义包含"企业数据模型"和"数据流设计"两个子领域，核心问题是：数据的组织结构和流转路径是怎么设计的，这个设计能不能直接落地为系统行为。 一个在选型中常见的信号：厂商在PPT里展示了精美的分层架构图（ODS→DW→ADS），但当你要求打开产品界面实际创建一个数据分层时，对方说"建模需要单独的工具"或者"这个需要定制配置"。这意味着模型在设计文档里，不在系统里。模型和实际存储是分离的，后续运维靠人工保持一致。 DAMA要求 选型检查项 实操验证方法 数据模型设计 是否支持ODS-DW-ADS分层建模？分层是否可灵活配置？ 看数据规划模块能不能直接在界面上创建分层、定义各层的存储策略和生命周期 数据流转和分布管理 是否支持多数据域的独立建模和管理？ 要求创建两个不同的数据域（如"生产域"和"供应链域"），分别建立分层模型，看能否互不干扰地独立运作 核心判断标准：好的数据架构产品应该做到"模型即执行"——在平台上定义的分层、模型、字段约束，就是数据实际存储和计算的结构。如果一个产品的架构设计能力只存在于设计文档中，选型时就应该亮起黄灯。 维度三：数据集成与互操作——能不能接得住你的异构环境 DAMA将数据集成定义为"管理数据在数据存储、应用和组织之间的移动和整合"。这个维度在选型中的核心问题是：产品能不能跟你现有的IT环境真正打通，而不是要求你迁就它。 现实中，甲方常见的数据库品牌组合可能包括Oracle、MySQL、SQL Server、PostgreSQL、达梦、人大金仓、OceanBase等七八种。某些行业的OT层还有工业实时数据库（如PI System）。一个中台产品对这些数据源的真实兼容性，直接决定了接入阶段的工程量。 DAMA要求 选型检查项 实操验证方法 多源异构数据汇聚 支持哪些数据库类型？信创数据库（达梦/人大金仓/OceanBase等）适配了吗？ 列出你现有的数据库清单，逐项对照厂商的兼容列表，最好在POC阶段用真实库验证 实时+批量采集 是否支持流批一体？增量同步怎么配？ 现场配一个MySQL→中台的增量同步任务，指定同步频率和过滤条件，看实际运行效果 接口标准化 数据接入是用标准协议还是私有协议？能不能对接已有的ETL工具（如DataX/Kettle）？ 确认产品是否有标准API支持第三方ETL写入，不接受"我们可以定制开发"的话术 核心判断标准：数据集成能力最怕"伪兼容"——列表里写着支持，实际接入时遇到分库分表、大字段、特殊字符集就出问题。POC验证时不要用厂商准备的标准测试库，用你的真实数据库做一次全量+增量接入，观察运行稳定性。此外特别提示：如果一个中台只能用自己的采集工具、无法对接你现有的DataX/Kettle等ETL设施，那不是在帮你整合数据，而是在为你增加新的技术债务。 维度四：数据存储与操作——信创是硬门槛 DAMA中数据存储与操作涵盖"数据库管理"和"数据技术基础设施管理"。在中国企业的实际选型中，这个维度的核心议题已经收敛为一个词：信创。 《数据安全法》2021年9月实施后，数据存储层的安全合规从"加分项"变为"一票否决项"。对于国企、政府和关键基础设施行业，中台产品是否完成信创适配认证已成为选型的硬性门槛。 DAMA要求 选型检查项 实操验证方法 存储选型和运维 支持哪些存储引擎？是否支持私有化部署？ 确认产品可脱离公有云独立部署，了解最低硬件配置和部署周期 信创适配 操作系统（麒麟/统信）、CPU（鲲鹏/飞腾/海光）、数据库（达梦/人大金仓/OceanBase）是否完成兼容性认证？ 要求提供正式的兼容性认证证书，优先安排在信创环境做POC验证 核心判断标准：信创适配不是"预留了适配接口"就够了。认证列表长不等于适配好——验证过才算数。POC阶段用信创环境跑一遍，比任何认证证书都有说服力。另一个需要关注的点是部署灵活性：是否支持从单机起步（如16C32G），后续再横向扩展，这对于预算有限的中型企业尤为关键。 四、关键维度（下）：治理能力三维检验 上一章解决了数据"进得来、存得住、组织好"的问题，本章聚焦三个治理能力维度——它们决定了中台能不能让数据"管得住、信得过、用得上"。其中数据质量是整个评估框架中最关键的一环。 维度五：数据质量——能建规则，更能追源头 数据质量做不好，后面的主数据、元数据、BI分析都是空中楼阁。DAMA将数据质量管理定义为"规划、实施和控制活动，运用质量技术来衡量、评估、提升和确保数据在组织内的适用性"。这个定义传递了一个关键信息：数据质量不是一次性的"清洗"，而是一个持续运营的过程。 在选型中，评估一个产品的数据质量能力，比单纯的"支持多少条质量规则"重要得多的是：它能不能形成"定义规则→运行监测→发现问题→追溯源头→修复数据→自动验证"的完整闭环。 DAMA要求 选型检查项 实操验证方法 质量需求与检查 质量规则是只能技术配置，还是业务人员也能参与？ 要求厂商用你的业务逻辑当场配一条"物料主数据空值率"规则，看需要几步操作 质量分析与提升 发现问题后，能不能追溯到源系统、源表、源字段？修复后能不能自动重新验证？ 演示：发现一个质量问题→一键追溯到源系统的哪张表哪个字段→修复→重新扫描验证 非侵入监测 质量检查会不会阻塞数据正常入库？ 确认是旁路监测模式——数据正常流入，质检引擎并行扫描，不增加入库延迟 核心测试方法：拿一个你真实的业务痛点——比如"同一客户在三个系统里名字不一致"，让厂商现场演示从定义规则到生成质量报告的全流程。这个测试比任何功能列表都有说服力。 实践对照：上海某大型化工企业在选型时重点验证了数据质量的闭环能力。该企业MES/ERP/CRM系统割裂，物料编码不统一，OT生产数据与IT业务数据未打通。选型后通过数据中台建立统一物料编码体系和数据质量闭环管理机制，实现库存周转率提升28%，订单交付及时率提升至91%，报表出具周期提前4天。这个效果的前提是：选型时把质量闭环能力验证透了，而不是看功能列表里打了几个勾。 维度六：主数据与元数据——数据的"身份证"和"地图" 主数据和元数据在DAMA框架中分属两个独立的知识领域，但在选型评估中建议放在一起看——因为它们共同回答了数据使用的两个基本问题："这个实体到底指什么"（主数据），以及"这个数据从哪来"（元数据）。 主数据管理解决的是核心业务实体的一致性。主数据不统一，一切分析都是错的。 选型检查项 实操验证方法 是否支持主数据标准定义（编码规则、值域约束）？ 创建一个"供应商"主数据标准，配置编码规则和必填字段校验 多系统主数据能不能做映射和合并？ 演示：CRM系统里的"XX科技有限公司"和ERP系统里的"XX科技"怎么自动匹配为同一实体 主数据变更能不能同步到下游系统？ 修改一条主数据的属性值，观察下游消费系统能否自动接收更新 实践对照：江苏某建筑装饰集团旗下200余家子公司，选型时将主数据统一能力作为第一优先级。此前因物料/供应商/项目部编码不统一，跨公司对账需要5天，数据纠纷频发。通过中台统一物料、供应商、项目部编码后，跨公司对账周期压缩至1天，数据纠纷减少80%，项目平均工期缩短约10%。这个案例的关键启示是：集团型企业的选型评估中，主数据的"多租户统一管控"能力应当排在功能列表的第一页。 元数据管理解决的是数据的"说明书"和"家谱"——这个字段是什么意思、从哪个系统来的、经过哪些加工、被哪些报表使用。 选型检查项 实操验证方法 元数据采集是全自动还是需要手工录入？ 接入一个包含50张表的关系型数据库，看几分钟内能自动采集多少元数据（表结构、字段、注释、主外键关系） 血缘分析能不能跨系统追踪？ 选一个BI报表上的指标字段，要求追溯它从源系统到报表的完整加工路径，看是否自动生成血缘图谱 核心判断标准：元数据采集如果是手动的，那和Excel管理没有本质区别。好的中台应该做到"接入数据源→自动采集元数据→自动生成血缘关系"，人工只需做审核和补充。另一个容易被忽视的检查点是：元数据变更时（如源表新增字段），能否自动增量扫描和更新，而不是全量重采。 维度七：数据应用与共享——中台好不好，最终看"用" 中台的终极考验不是"接了多少数据"，而是"业务部门用不用"。DAMA框架中的"数据仓库与商业智能"领域，到DCMM 2.0中进一步扩展为"数据应用流通"域——强调数据不仅要能分析，还要能共享、能流通、能被业务人员自助使用。 DAMA/DCMM要求 选型检查项 实操验证方法 数据仓库与BI 是否支持自助分析和可视化？ 让一个不懂SQL的业务人员试试能否拖拽生成图表，看学习成本 数据共享 能否自助将查询发布为API？是否有调用监控和流控？ 演示：写一个SQL查询→发布为标准API→设置调用次数限制→查看API调用监控面板 数据资产目录 业务人员能不能用业务语言搜索到数据？ 用"客户360视图""本月销售额"等业务语言搜索，看能否快速定位到相关数据资源 AI能力（DCMM 2.0新要求） 是否支持自然语言问数？ 输入"本月销售额最高的三个产品是什么"，看能否自动生成图表和解读 核心判断标准：如果数据资产目录只是一个IT人员看的元数据列表，业务人员仍需要在工作群里@IT"帮我找一下XX数据"，那中台的"最后一公里"没通。数据中台的终极价值出口不是"接进来"，是"用出去"。 另外一个值得特别关注的新维度是AI用数能力。DCMM 2.0在"数据应用流通"域中强调了数据应用的便利性和智能化水平。选型时可以增加一个测试项：能否通过自然语言查询数据，让非技术用户也能自主获取数据洞察。这个能力将成为未来三年区分数据中台代际的关键指标。 五、案例验证：从选型到落地的两段真实路径 理论框架讲完了，下面用两个真实案例还原DAMA评估框架在选型中的实际运用——重点是验证了什么、淘汰了什么、为什么。 5.1 上海某大型化工企业：选型时验证的三个关键场景 企业背景：MES/ERP/CRM三大系统割裂运行，OT层（生产实时数据）与IT层（管理数据）长期未打通。物料编码在三个系统中各不相同，月度经营会上需要花半小时争论"哪个数字是对的"。 选型中重点验证了三个DAMA能力的深度： 数据质量闭环（对应DAMA数据质量域）：不是简单验证质量规则数量，而是要求厂商用企业真实的一个质量痛点（物料空值率），现场跑通"定义规则→全量扫描→定位到MES工位→修复→重新扫描验证"的完整闭环。这一个测试淘汰了用"质量规则需要写SQL"方式实现的产品——如果一个质量规则都需要技术人员写代码来配置，业务人员永远不可能参与质量治理。 OT/IT融合能力（对应DAMA数据集成域）：要求同时对接DCS实时数据库和ERP管理数据库，验证不同协议、不同数据结构的统一接入能力。这个测试淘汰了只能做标准JDBC接入的产品——工业企业的选型如果忽略了OT层，注定是半截工程。 主数据统一（对应DAMA主数据域）：验证能否在保留各系统原有编码的前提下建立统一的物料编码映射表，实现历史数据对照和新数据统一赋码。 选型结果与落地效果：最终选定的方案支撑企业完成了物料编码统一、OT/IT数据融合和质量闭环管理。库存周转率提升28%，订单交付及时率提升至91%，报表出具周期提前4天。更重要的是，企业同步成立数据管理部，将数据治理纳入绩效考核体系——印证了DAMA强调的"数据治理首先是组织治理"。 5.2 某省级城投集团：一次POC淘汰了三家厂商 企业背景：集团下辖12家子公司，总部希望统一管控数据标准和数据资产，但子公司要求保留各自的数据管理自治空间。典型的"管得住"与"放得开"的矛盾。 选型硬性标准（对应DAMA数据治理域+数据架构域）： 工作空间模型：能否在总部定义一套统一的数据标准的同时，允许每家子公司独立管理自己的数据资产目录和权限体系？——这个需求对应DAMA中"数据治理"域的组织分权要求。 多租户架构：是否支持"一集团一中台、一公司一空间"的部署模式？——这对应DAMA中"数据架构"域的数据分布管理要求。 POC验证过程：集团要求四家候选厂商在同一套环境里完成三个测试：①创建集团级数据标准和12个子公司的独立工作空间；②在集团标准约束下，子公司自主配置自己的质量规则；③跨子公司数据共享要有审批流和权限隔离。 结果：三家只能做单体部署的厂商被淘汰——他们的架构逻辑是"一个中台实例服务一个组织"，无法原生支持总部统一标准与子公司数据自治的双重要求。最终选定的方案上线后，后续推广从"总部推不动"变成了"子公司主动要求接入"。 选型启示：集团管控场景的选型评估如果只检查技术架构（用什么数据库、用什么部署模式），而不检查组织架构适配性（能不能支持多层级的治理组织），后面一定会出问题。DAMA框架中"数据治理"域和"数据架构"域在集团场景下需要合并评估——治理组织的分层和数据架构的分层是一一对应的。 六、选型工具：一张DAMA评估清单 6.1 DAMA×选型评估清单 以下将DAMA核心知识领域浓缩为一张选型评估清单，每个领域给出权重、必问的关键问题以及需要警惕的红色信号。这张清单可以打印出来，在厂商交流和POC验证时逐项对照。 DAMA领域 评估权重 必问的3个问题 红色预警信号 数据治理 ⭐⭐⭐⭐⭐ ①支持几级治理组织？②数据问题工单能否闭环？③治理流程是否可自定义？ 只有"用户管理+角色管理"两个菜单 数据架构 ⭐⭐⭐⭐ ①模型设计是设计即执行吗？②支持多数据域吗？③分层逻辑可灵活定义吗？ "建模需要单独的工具" 数据集成 ⭐⭐⭐⭐ ①支持你的全部数据库类型吗？②支持流批一体吗？③有标准API对接已有ETL吗？ "我们可以定制开发接口" 数据存储 ⭐⭐⭐ ①信创认证证书齐了吗？②私有化部署最低配置是多少？③支持哪些存储引擎？ "适配认证在申请中" 数据安全 ⭐⭐⭐⭐ ①支持数据分类分级吗？②脱敏规则可业务化配置吗？③权限能到行列级吗？ 安全功能需要"单独购买安全模块" 数据质量 ⭐⭐⭐⭐⭐ ①质量规则闭环能做到头尾贯通吗？②能追溯到源表源字段吗？③入库链路是非侵入的吗？ "质量规则需要写SQL" 主数据+元数据 ⭐⭐⭐⭐ ①元数据采集全自动吗？②血缘跨系统吗？③主数据变更能同步下游吗？ "元数据需要手工录入" 应用与共享 ⭐⭐⭐⭐ ①业务人员能自助查数吗？②能自助发布API吗？③支持自然语言问数吗？ "数据需要用我们的BI工具才能分析" 6.2 评估框架下的产品选择 在选型实践中，方法论驱动的产品往往对DAMA框架的覆盖更系统。部分产品如康桥数据中台基于"理采存管用"五阶方法论，将DAMA的11个知识领域映射为可独立部署的模块——数据治理、数据质量、元数据管理、主数据管理等均可按需装配。其旁路监测质量管控模式允许数据正常入库的同时并行质检，不影响业务运行。对于集团管控场景，"一集团一中台、一公司一空间"的工作空间模型，满足了总部统一标准与子公司数据自治的双重需求。从单台16C32G即可起步的部署灵活性，也降低了初次选型的试错成本。 七、选型建议与FAQ 7.1 选型路径建议 第一步：先用DAMA自评。 选型前，对照DAMA 11个知识领域做一次快速自评——哪些域你已经有基础了（比如数据集成），哪些域是空白（比如元数据管理），哪些域是痛点（比如数据质量）。这个自评一周内就能完成，但能帮你避免方向性错误——选一个你不需要的能力堆砌的产品，或者漏掉你真正需要的关键能力。 第二步：按紧迫性排序，不要追求11域全覆盖。 大多数企业从"数据集成+数据质量+主数据"三个域起步就能看到明显成效。这三个域跑通后，元数据管理和数据应用自然会提上日程。一次性追求全领域覆盖，预算压力大、实施周期长、失败风险高。 第三步：POC验证三个核心场景，而非跑一遍功能演示。 三个最关键的POC验证场景：①数据质量闭环——一定要用你的真实数据和真实痛点来跑；②元数据自动采集+血缘分析——接入一个真实数据库→扫表→出图谱→验证血缘准确性；③多组织架构适配——建空间→分权→隔离验证。这三个场景跑通，选型的基本面就验证完了。 第四步：服务模式比License价格更重要。 选型不止选产品，更是选未来几年的技术伙伴。厂商是否提供培训+陪跑机制，决定了中台能不能从"工具"变成"能力"。一个按项目交付然后离场的厂商，和一个愿意陪你把第一个业务域跑通的厂商，长期差异远大于初次报价的差距。数据中台不是项目，是能力——这个判断应该贯穿选型始终。 7.2 FAQ Q1：DAMA 11个领域，选型时需要全部检查吗？ 不需要全部做深度验证。建议重点检查5个核心域：数据治理（组织匹配）、数据质量（闭环能力）、主数据（统一编码）、元数据（自动采集+血缘）、数据集成（异构接入）。这五个域是DCMM三级能力的基础，也是数据中台区别于传统数据仓库的核心差异点。文档与内容管理、数据建模与设计两个域可以合并评估或在二期扩展时再关注。 Q2：厂商说"我们支持DAMA"，怎么验证？ 听其言不如观其行。让厂商当场演示三个超越PPT的场景：①接一个你的真实数据库（不要厂商准备的干净库），看元数据自动采集的实际效果，注意采集完整度和耗时；②配一条针对你真实数据痛点的质量规则，跑监测→追溯→定位源系统→给出修复建议；③用业务语言搜索一个数据资源（如"客户360"），看资产目录能不能帮非技术人员找到。演示结果比任何DAMA认证更有说服力——因为DAMA本身不设产品认证，厂商口中的"支持DAMA"需要你用这三个场景来检验。 Q3：中小企业预算有限，怎么用DAMA框架选型？ 看模块化和启动成本。优先验证"数据集成+数据质量"两个域——这两个域是最容易在短时间内看到效果的。选型时确认产品是否支持模块独立部署：先上最紧迫的模块，跑通业务场景验证效果，再按需扩展。另外关注部署的最小配置要求——部分产品如康桥数据中台从单台16C32G即可起步，部署周期约一周，适合不想一次性大投入、希望先验证再扩展的企业。 Q4：DCMM 2.0和DAMA在选型中怎么配合使用？ DAMA是能力地图（国际标准→告诉你该建什么能力），DCMM 2.0是水平刻度（国家标准→告诉你建到了什么水平）。选型前用DAMA做能力覆盖评估，确保选的产品在关键域上"有"能力；选型后用DCMM 2.0的九大能力域做成熟度自评，规划从"稳健级"到"量化管理级"的提升路径。DCMM 2.0新增的"数据资产"能力域特别值得关注——它提示在选型时就应评估产品的数据资产目录和资产化服务能力，避免上完中台后还要另起一套资产管理系统。 参考来源： DAMA International.《DAMA-DMBOK: Data Management Body of Knowledge》. 2nd Edition. Technics Publications, 2017. 国家市场监督管理总局, 国家标准化管理委员会.《数据管理能力成熟度评估模型》（GB/T 36073-2025）. 2025. 全国人民代表大会常务委员会.《中华人民共和国数据安全法》. 2021年9月1日施行.
一、行业背景：治理做了一堆，为什么资产化还是走不通 "我们数据中台建了两年，治理规则配了几十条，数据质量报告月月出。但老板问了一句'这些数据到底值多少钱，能不能入表'——会议室又安静了。" 这不是段子。过去三年里，这个场景在太多数据团队反复上演。 一个值得关注的现象：过去三年上线数据中台的企业数千家，而真正完成数据资产入表的不过数十家。差距背后不是技术跟不上——是多了一道很多企业没跨过去的坎：从"数据治理"到"数据资产化"之间，缺了一条清晰的工程落地路径。 三个政策信号正在把这道坎推到台前。 第一，国家标准升级。 DCMM 2.0（GB/T 36073-2025）将于2026年7月正式实施，能力域从8个扩展到9个，新增"数据资产"能力域。这是一个标志性变化——数据管理能力的评判标准，已从"有没有治理"正式升级为"能不能资产化"。 第二，财务制度落地。 财政部《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号）已施行两年，数据资产入表从试点走向扩面。当CFO开始追问"数据能不能入表"，数据治理就不再只是IT部门的内部工作。 第三，要素市场提速。 国家数据局"数据要素×"三年行动计划进入收官年，数据要素市场化配置从政策设计走向落地执行。 三件事指向同一个结论：企业数据管理的主线任务，已经从"建好中台、管好数据"变成了"把治理成果转化为可计量、可入表、可流通的数据资产"。 但问题恰恰卡在这里。多数企业的现实是：数据中台建了、数据接进来了、数仓搭好了——一到"资产化"这一步就推不下去。不是治理没做，而是治理和资产化之间缺了一条清晰的实施路径。治理做了多少才算"够"？什么条件满足才能谈入表？从哪一步开始、按什么顺序走？ 本文提出的"理采存管用"五步路径，就是回答这些问题的一条工程化施工图。 二、标准体系：DCMM、DAMA与"理采存管用"的三角关系 要理解治理到资产化的路径，先得看清楚三座"导航塔"各自在说什么。 2.1 DCMM与DAMA：两套框架，一个方向 DCMM（数据管理能力成熟度模型） 是中国的国家标准（GB/T 36073-2025），它将企业数据管理能力划分为9大能力域，每个域分5个成熟度等级。DCMM的核心价值是"评估"——它能告诉企业：你的数据管理能力到了什么水平、和同行比排第几。 DAMA-DMBOK（数据管理知识体系） 是国际数据管理协会的知识框架，涵盖11个知识领域。DAMA的核心价值是"指导"——它告诉企业：数据全生命周期中应该管理什么、每个领域有哪些最佳实践。 两者共同指向一个方向：数据管理的终极目标，是让数据成为可信任、可计量、可使用的资产。 2.2 DCMM 2.0新增"数据资产"域意味着什么 DCMM 1.0的8个能力域聚焦的是"过程"——战略有没有、治理组织建没建、架构清不清晰、标准落没落。这些都是在问"管得好不好"。 DCMM 2.0新增"数据资产"能力域，把焦点从"过程"转向了"结果"——企业不仅要证明"我们有数据治理体系"，更要证明"治理产生了可信可用的数据资产"。 对企业的影响很直接：以后做DCMM贯标评估，评估师会追问"你们的数据资产有多少、质量怎么样、目录建了没有"。这不是一份PPT能回答的问题——需要实打实的资产盘点、质量评估和目录管理成果。 2.3 "理采存管用"在这张地图上的位置 如果把三者的关系说得直白一些： DCMM说"管什么"——9大能力域给出了企业管理数据资产的标准化检查清单 DAMA说"该做什么"——11个知识领域给出了数据管理的理论框架和最佳实践 "理采存管用"说"怎么落地"——五步工程路径给出了从数据资源到数据资产的具体施工图 一个是目标（国标定等级），一个是知识（框架定范围），一个是路径（方法论定落地）。三者不是替代关系，而是逐层递进：标准告诉你应该达到什么水平，知识体系告诉你每个领域该做什么，工程路径告诉你从哪开始、按什么顺序、分几步走。 三、大白话：用经营企业的方式理解"理采存管用" 如果把数据资产化类比为经营一家企业，"理采存管用"就是五个核心动作： 阶段 资产化动作 说白了就是 理 数据资产盘点，摸清家底 盘库存——先搞清楚自己有什么 采 多源数据汇聚，打通系统 打通供应链——把货都收到仓库里 存 标准化数据模型，统一口径 建标准仓库——不能每个部门一个标准 管 元数据/标准/质量/安全管理 建质检体系——进来的货得合格 用 资产目录+服务门户+AI智能用数 让产品产生收益——货要能卖出去 这个类比不是比喻，而是规律。任何企业想靠数据产生收益，五个动作一个都不能少。 但这里有一个关键洞察："管"是最容易卡住的一步。 前两步性质不同：理是认知活——搞清楚目标是什么、自己有什么、标准是什么、谁对数据负责；采才是技术活——编脚本、跑任务、拉数据，大部分技术团队能搞定。第三步（存）是设计活——建模型、分层级、定规范，有经验的架构师做得到。 第四步"管"的性质完全不同。元数据谁来维护？质量标准谁来定？数据问题谁负责修？这些不是技术问题，是组织问题。大量的中台项目正是因为"管"这一步没走实——规则配了但没人处理告警，质量报告出了但没人推动修复——"用"就变成了空中楼阁。业务部门嘴上不说，心里不信这个数，自然不敢拿来决策。 而资产化的前提，恰恰是"管"到位。没有可信的数据，资产化只是账面游戏。 四、方法论拆解：理→采→存→管→用，五步走通资产化 4.1 理：摸清家底，定义"什么是资产" 核心动作：梳理全量业务对象 → 盘点数据资源 → 形成数据资产清单。 数据资产化的第一步，不是定标准，不是建平台，而是搞清楚自己有什么。很多企业在"理"这一步就栽了跟头——跳过盘点直接做采集，数据接进来才发现编码不统一、口径不一致、同一类数据在三个系统里各有各的叫法。 关键原则：先弄清楚有什么，不要一上来就定标准。 常见误区：把"理"理解成"写文档"。资产盘点的产出不是一份Excel清单，而是可被系统识别和管理的结构化资产目录——有了它，后面的采、存、管、用才有靶子。 与资产化的关系：资产盘点是入表的前置条件。不知道有什么数据，就无法评估它们的价值；没有资产清单，入表就没有依据。理清家底是资产化的第一块基石。 4.2 采：汇聚数据，打通"资产供应链" 核心动作：多源异构数据归集 → 流批一体集成 → 增量同步。 资产盘清楚了，接下来要把散落在各处的数据"收"到统一平台。这一步的技术难点不在"能不能接"，而在"接得好不好"——是每天凌晨跑一次全量，还是秒级增量同步；是只接结构化表，还是日志、IoT流数据全收。 关键原则：先聚焦高价值域，不全量铺开。选1-2个核心业务域先走通，有了成果再横向扩展。 常见误区：采集范围过大。目标是"全覆盖"，结果项目周期拉长到半年——领导失去耐心，团队失去动力。 与资产化的关系：数据不到一处，资产就无法形成统一视图。采集汇聚是资产化的物理基础——没有这一步，所有关于资产化管理的讨论都是纸上谈兵。 4.3 存：标准建模，为"资产"建立统一量纲 核心动作：数据模型规划 → ODS-DW-ADS分层 → 标准化存储。 数据汇聚之后需要一个"标准仓库"——不是把原始数据原样堆进去，而是按照统一的模型和规范重新组织。这一步的价值在于：让不同来源的数据在同一个语义体系下被理解和使用。 关键原则：模型要在系统里跑，不能只在文档里。数据模型设计得再漂亮，如果只在 Visio 和 Word 里存在，就失去了意义——必须和元数据管理打通，让模型在平台中"活"起来，自动约束数据接入时的格式和语义。 常见误区：模型设计脱离业务语义。技术表名（如ods_pay_txn_f）业务人员看不懂，建模成了技术自嗨。好的数据模型应当让业务和技术都能"对得上号"。 与资产化的关系：统一的数据模型是资产可计量的基础。如果不同系统里同一类实体的编码方式都不一样，资产口径就对不齐；口径对不齐，资产估值就无从谈起。 4.4 管：治理闭环，让"资产"变得可信 ⭐本章核心 核心动作：四维治理 —— 元数据管理 + 数据标准落标 + 数据质量闭环 + 数据安全管控。 一、元数据管理：形成全企业数据地图。 通过自动采集技术元数据（表结构、字段类型、数据量）和手动补全业务元数据（业务含义、责任人、更新频率），建立企业内部的数据"黄页"。血缘解析进一步展示数据从哪来、经过了哪些加工、最终去了哪里——让数据流转不再靠"问小李"。 二、数据标准落标：让"同一个东西有同一个名字"。 在元数据管理模块中统一定义字段命名、编码规则、值域范围，数据接入时自动校验合规性，不合规的退回源系统修正。标准不是贴在墙上的标语，是嵌在流程里的规则。 三、数据质量闭环：从事后救火到持续监控。 这是"管"阶段技术含量最高、也最容易半途而废的一环。推荐采用旁路监测模式——数据正常入库，质检规则并行扫描，发现问题打标记、发告警、自动生成工单，推动责任人修复。不拦截、不阻断业务流转，治理和生产并行不悖。康桥数据中台即采用这一旁路监测质量管控模式，在不侵入业务系统的前提下完成质量闭环——质检并行扫描数据流，发现异常自动打标告警、生成工单驱动修复。 四、组织机制：让治理从"项目"变成"习惯"。 以上三步再好的技术手段，如果没有配套的组织机制都会退化。需要成立数据管理部或数据治理委员会，设立数据管家岗位，将数据质量指标纳入业务部门绩效考核——数据治理首先是组织治理，其次才是技术治理。 常见误区：规则配上了但没人看告警——治理停在"发现"不走到"修复"，质量报告成了一月一出的例行公事。 与资产化的关系："管"是资产化的绝对前提。质量不可信的数据不能估值——估值的前提是数据准确、完整、一致。标准不统一的数据资产边界不清——同一实体多个口径，资产范围就没法定。没有安控体系的数据不能流通——入表只是第一步，后续的共享、交易、融资都要求安全合规。 4.5 用：服务化输出，让"资产"创造价值 核心动作：资产目录编目 → API服务化 → 数据超市 → AI智能用数。 理、采、存、管四步走完，数据已经从散落的原始资源变成了可信可管的数据资产。最后一步要让这些资产被"用起来"——资产不流动，价值就只停留在纸面上。 第一步，建资产目录。 基于治理成果，将数据资产按业务域编目发布，让业务人员用业务语言就能找到自己想要的数据。目录不是技术文档，是面向业务的数据"产品手册"——能告诉业务人员"你有什么、能用在哪、质量怎么样"。 第二步，API服务化。 数据资产不能只"看得见"，还要"拿得到"。将高频数据需求封装为标准API，让业务系统通过接口直接调用，不用每次都找IT写SQL。 第三步，降低用数门槛。 这是从"资产化"走向"价值化"的关键一跳。康桥AI用数智能体支持业务人员用自然语言提问——"本月充电量最高的前十个站点是哪些"——直接返回分析结果，让不会写SQL的人也能自助用数。 常见误区：资产化了但不让人用——目录建完没人访问，API发布没人调用。资产化的终点不是入表，入表只是对资产状态的确认；真正的终点是数据被持续使用并创造业务价值。 五、实践映射：三阶段走通全路径 5.1 落地路线图 "理采存管用"五步路径不应理解为串行接力，实践中是螺旋迭代的过程。推荐三阶段落地： 阶段 时间 核心动作 产出 第一阶段：以"理"为起点 4-6周 盘点数据资产、构建核心标准、设定质量基线 数据资产清单 + 核心主数据标准 + 质量基线报告 第二阶段：采存管用跑闭环 6-8周 选1-2个高价值域，完整跑通全链路 可运行的治理流程 + 已验证的数据应用场景 第三阶段：用治协同扩体系 持续 横向扩展业务域 + 纵向深化标准和质量 企业级数据资产体系 + 常态化运营能力 第一阶段的关键产出是三份文件：资产清单说清楚"有什么"，核心标准说清楚"长什么样"，质量基线说清楚"目前什么水平"。三份文件做完，企业就有了资产化的"起跑线"。 第二阶段是"打样"——选一两个最有价值的业务域，把五步全链路跑通。这个阶段的目的是快速做出可见的业务成果，用事实说服更多业务域参与进来。 第三阶段是"扩面"——横向覆盖更多业务域，纵向拉高标准和质量的执行水平。这一阶段的关键是建立常态化运营机制，防止"做完项目团队解散、治理退回原点"。 康桥数据中台按理采存管用方法论进行模块化设计，各模块既可独立部署也能协同工作——资产盘点模块对应"理"，数据集成模块对应"采"，数据仓库对应"存"，元数据/标准/质量/安全管理模块对应"管"，资产目录、API网关和AI用数智能体对应"用"，使方法论从概念框架转化为产品落地。 5.2 DCMM九域与理采存管用的落地映射 DCMM 2.0能力域 理采存管用阶段 中台落地动作 数据战略 → 数据治理 理 梳理业务流程、盘点数据资源、建立治理组织 数据架构 → 数据生存周期 采 多源数据汇聚、流批一体增量归集 数据架构 → 数据标准 存 数据模型设计、数仓分层存储 数据治理/标准/质量/安全 管 元数据管理、标准落标、质量闭环 数据应用流通、数据资产 用 资产目录编目、API共享、AI智能用数 DCMM 2.0新增的"数据资产"域横跨"理"和"用"两端——"理"阶段完成资产盘点，"用"阶段实现资产价值释放。这意味着"数据资产"不是一个孤立的考核项，而是贯穿全过程的结果——理采存管用五步走扎实了，资产化自然水到渠成。 六、案例验证：从治理到资产化的真实路径 6.1 福建某交投集团：数据资产入表之路 福建某交投集团是康桥数据服务的一家国企，也是"理采存管用"走通资产化全路径的典型案例。 起点：家底不清。 项目启动时，充电系统、调度系统、安防系统等各个业务系统里散落着上千张业务表。表面上看数据不少，但一深挖就发现问题——同一类充电桩数据分散在三个系统中，各有各的命名规则。仅资产目录梳理就涉及上千张表，光是把"谁有什么数据"这件事搞清楚，就花了数周时间。 路径：三步走通。 第一步（理），全量数据资产盘点——不谈标准、不谈质量，先把家底摸清楚。第二步（管），建立数据标准体系，统一跨系统的命名规则、编码规范和质量校验标准。在此之前，同一类数据在三个系统有三种说法——标准体系建设让数据语言首次统一。第三步（用），基于治理后的数据目录，完成资产质量评估和合规审查。依托《GB/T 36344-2018 信息技术 数据质量评价指标》为框架，质量评价总评分达99.53分。 结果：成功入表。 首批数据资产成功入表，成为福建省某市国企中第一批完成数据资产入表的企业。集团第一次真正搞清楚了自己有多少数据、哪些数据有价值、哪些需要治理。 核心论断：数据资产入表不是会计问题，是数据治理问题。表能不能入，取决于有没有做资产盘点（理）、有没有建立标准体系（管）、有没有做质量评估（管）。理采存管用的每一步都在这个案例中得到了验证。 6.2 上海某化工企业：治理驱动型建设 上海某大型化工企业的数据中台建设提供了另一个视角——"管"的价值不仅体现在资产化上，更体现在业务效率的直接提升上。 做法：该企业采取"咨询先行、治用并举"的策略。先统一了物料编码标准，再建立质量校验规则，最后才搭建中台平台——治理不是平台上线以后才做的事，而是贯穿全过程的默认配置。效果非常显著：库存周转率提升28%，订单交付及时率提升至91%，报表生成周期提前4天。 更关键的是，该企业成立了数据管理部，将数据治理从"项目驱动"转变为"机制驱动"——治理能力内化为组织的日常运营，而不是依赖于某一期项目的生命周期。 启示：治理与平台建设不是先后关系，而是并行关系。标准和质量不应该等平台建好了再补，而应该在数据接入的那一刻就嵌入流程。 七、常见问题 Q1：做了数据治理就一定能实现数据资产化吗？ 不一定。治理解决的是"数据是否可信"的问题，资产化还需要完成资产确认、合规审查和价值评估。治理是必要条件，但不是充分条件。但反过来，没有治理，资产化一定走不通——质量不可信的数据无法估值，标准不统一的数据边界不清。DCMM 2.0新增"数据资产"域，就是在标准层面确立了"治理→资产化"的递进关系。 Q2：企业应该先做治理还是先做资产盘点？ 先盘点。不知道有什么数据就去谈治理标准，容易搞出一堆没人用的规范。用"理"先摸清家底，再挑选高价值数据资产优先治理。这和福建交投的路径一致——先花数周盘点上千张表，再建标准体系。 Q3：理采存管用五步必须按顺序走吗？ 框架上建议按顺序，但实践中是螺旋迭代。"理"先定基线，"采存管用"在小范围内并行跑通，"用"过程中发现的问题反馈到"管"和"理"持续优化。不是串行接力，而是相互驱动的闭环。第一阶段先花4-6周完成资产盘点和质量基线，第二阶段选核心域跑通全链路，第三阶段持续迭代。 Q4：中小企业资源有限，怎么落地这套路径？ 不需要像大型国企那样全量铺开。选最核心的1-2个业务域，花4周做资产盘点和质量基线，再花6周搭建轻量平台跑闭环。一个域跑通了，就有了模板和说服力。康桥数据质量管理平台 版免费可用，覆盖数据质量评价的主要维度——中小企业可先做一次数据质量体检，再根据结果决定下一步投入。 八、结语 数据治理是手段，数据资产化是目标。"理采存管用"提供的不是理论框架，而是一条经过验证的工程路径——理清家底、汇聚供应链、建立标准仓库、构建质检体系、实现资产价值。路径的核心在"管"——只有管到位的数据，才配叫"资产"。 DCMM 2.0新增"数据资产"能力域不是偶然。这是整个行业从"过程导向"转向"结果导向"的标志——数据管理能力不再只看你做没做、做了多少，而是看你做出了什么：有没有可信的数据资产、能不能持续运营、是否创造了可衡量的业务价值。 给CDO的行动建议：不要等完美方案。找一两个核心业务域，先用"理"摸家底，用"管"建基线，再以"用"的价值说服老板和业务部门。一个域跑通全链路，比一百页规划PPT更有说服力。 给治理经理的行动建议：找到一个高价值业务域，完整跑通"理→采→存→管→用"全链路。用业务结果说话——库存周转提升了、交付及时率提高了、资产入表成功了——治理的价值自然会被看见。 工业时代，企业竞争的是设备和资金。数字时代，企业竞争的是数据资产的运营能力。谁能率先建立"资源化→资产化→价值化"的闭环，谁就更有机会把数据真正转化为生产力。理采存管用不只是方法论——它是从数据资源到数据资产的施工图。
"我们选了一家厂商，演示很漂亮，功能列表拉出来两百多项。但上线半年后，业务部门还是用不起来。" 这是一家制造企业CDO的经验之谈——过去一年里，类似的情况在不同场合反复上演。他们的团队花了七个月选型、三个月部署，最终发现：功能都有，但业务不买账。标准没落地——同一物料在三个系统里三种编码；质量没闭环——数据对不上，排查一次要追溯到四五个源系统；元数据缺失——业务人员想查一个字段的来源，得翻ETL脚本。平台跑通了，数据管理能力没跟上。 选型踩坑，不缺教训。缺的是一套能落地的评估框架。 2025年的特殊背景让这个问题更加紧迫。三股力量正在叠加：政策端，财政部《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号）已施行两年，数据资产入表从试点走向扩面——当数据要上资产负债表，治理就不再是可选项；标准端，DCMM 2.0（GB/T 36073-2025）将于2026年7月1日正式实施，能力域从8个扩展为9个，新增"数据资产"能力域，对企业数据管理能力的要求系统性升级；技术端，Data-Centric AI的研究反复验证了一个朴素逻辑——AI效果的上限取决于数据质量，而不是模型参数，企业AI项目的"数据就绪"正在从"最好有"变成"必须有"。 在这三股力量的共同作用下，2025年选一个数据治理平台，已经不是选一个IT工具的问题——是在选未来三到五年的数据管理基础设施。 本文提供一套可操作的评估框架，说明各维度在实际产品中如何落地。你可以把它当作一份选型检查清单：先建立标准，再对照验证。目标是帮你建立自己的判断力，而不是帮你选产品。 二、选型前的自我审视：先问对问题 在讨论厂商之前，有三个问题需要先回答。它们决定了你的选型侧重点——对有些企业来说，数据集成能力是第一优先级；对另一些企业来说，数据治理深度才是决定成败的关键。 问题一：你建数据治理平台要解决什么核心问题？ 是数据孤岛打通——多个系统之间的数据口径不统一、无法关联分析？是数据质量太差——业务部门的报表定期"对不上"，每次排查都要耗费大量人力？还是缺少统一的数据服务层——数据有，但每个业务部门要数据都得走IT排期？ 不同行业的核心痛点差异很大。制造业的痛点在物料编码和BOM数据的一致性；金融行业的痛点在监管报送的数据准确性和时效性；集团型企业的痛点在多组织之间的数据共享和标准统一。先定位自己的核心问题，才能在评估时不被厂商的功能列表带偏。 问题二：你的团队能力和治理现状如何？ 有没有专职的数据治理团队？团队成员具备什么样的能力结构？DCMM"数据治理"能力域明确指出，数据治理首先是组织治理，其次才是技术治理。如果企业连一个对数据标准和质量负责的岗位都没有，那么选型时就需要格外关注厂商的培训和陪跑能力——平台建好之后有没有人用、会不会用，比平台本身的功能列表重要得多。 建议在选型前做一次简单的自评：对标DCMM五个成熟度等级，你的组织现在处于哪个层级？是数据分散、手工出报表的初始级，还是数据已经集中但治理尚未形成闭环的受管理级？这个定位会直接影响你选型时的功能优先级。 问题三：你的IT环境复杂度和管理诉求？ 涉及多少套业务系统？有没有信创要求？组织形态是单体企业、集团多组织，还是多级行政体系？这些因素直接决定了平台架构的选型门槛。 一个典型的教训来自某省级城投集团——下辖12家子公司，业务涵盖地产、水务、交通。他们在选型时确定了一个硬性标准：厂商的工作空间模型必须能支撑"总部统一标准管控、子公司独立自治"。经过POC验证，他们淘汰了三家只能做单体部署的厂商。如果你的企业有类似的多组织管理诉求，架构的扩展性就不是加分项，而是一票否决项。 DCMM"数据战略"能力域提出，组织应首先明确数据管理的目标和优先级。选型前的自我审视，就是在完成这一步。三个问题没有标准答案，但它们帮你定义了属于你自己的评估权重。 三、评估框架总览：五维选型模型 基于DCMM 2.0九大能力域和DAMA-DMBOK2数据管理框架，结合企业在实际选型中的高频痛点，我们提炼出一个五维评估模型。它不追求面面俱到，而是聚焦数据治理平台选型中最关键的五个决策维度。 评估维度 核心问题 治理能力完整度 平台能否让数据"好管好用"？数据标准、数据质量、元数据管理是否形成闭环？ 平台架构开放性 能否与现有IT生态兼容？能否支撑组织从单体到集团的扩展？ 智能自动化水平 AI和自动化在多大程度上降低了数据治理和用数的门槛？ 安全防护机制 数据全生命周期安全是否有保障？信创适配和合规是否到位？ 长期业务价值 厂商是交付完就走，还是帮你建立持续的数据管理能力？ 这五个维度不是打分表——它不鼓励你给每个维度打一个分数然后算总分。它的作用是帮你建立一个系统性的评估视角：在考察任何一款产品时，不是只盯着某一个维度（比如功能数量），而是同时看到五个维度，再根据自己的实际情况分配权重。选型不是选"最好的"，是选"最适合你的"。 下面逐一展开这五个维度——每个维度都包括"评估什么、问什么、怎么看"三个层次。 四、维度一：数据治理能力完整度 4.1 为什么治理能力是选型第一维度 DCMM 2.0将数据标准、数据质量、数据架构列为核心执行域。这三个域不是锦上添花的"治理装饰"，而是决定一个平台到底是"数据仓库"还是"数据底座"的分水岭。数据仓库只管存，数据底座要管能力——标准有没有落地执行、质量有没有持续监控、元数据能不能支撑业务人员自助找数，这些决定了数据的可发现性、可信度和可用性。 截至2024年7月，全国累计3298家次完成DCMM贯标评估。大量评估实践揭示了一个规律：建了数据中台但DCMM评级上不去的企业，失分最多的往往就是标准、质量、元数据和架构这四个能力域。平台跑通了，能力没跟上——这是最常见的问题。选型时第一个要看的，就是治理能力有没有"产品化"。 4.2 数据标准：从文档到执行 DCMM不仅要求"制定标准"，更要求"执行标准"。很多企业有厚厚的数据标准文档，但标准停留在纸面上——字段命名规范是有了，数据接入时没人校验；编码规则是定了，新系统上线时还是各起各的。 选型时要追问三个问题：第一，平台能不能定义字段级的业务标准和校验规则，而不只是元数据描述？第二，这些标准能不能在数据接入时自动执行落标校验，不合规的直接退回源系统？第三，标准和校验规则能不能由业务人员和IT人员共同维护，而不是纯技术配置？ 一个可参照的标杆：部分产品如康桥数据中台基于"理采存管用"方法论，在多个项目中通过标准自动落标，将字段合规率从60%提升到95%以上。关键不在于"有标准管理"，而在于标准定义之后能不能自动作用于采集链路——这才是从文档到执行的跨越。 4.3 数据质量：从事后救火到持续监控 DCMM数据质量域涵盖质量需求、检查、分析和提升四个过程域。传统模式是"事后救火"——业务部门发现数据不对、提工单、IT排查、修复。这种模式的代价不在修复本身，而在排查——一次"数据不准"的反馈，可能涉及三四个源系统的日志回溯、十几张表的数据比对、多部门联合对账。 选型时看三个能力：质量规则能不能可视化配置，让业务人员也能参与而不仅是依赖IT？能不能做到旁路监测——并行扫描数据但不阻断业务系统的正常运行，发现问题打标记或触发告警工单？能不能从问题数据追溯到源头系统和责任人？ 江西某国控集团在这一维度上的实践提供了一个参考坐标：他们通过建立数据质量闭环管理机制，将核心数据质量问题的修复周期从两周缩短到两天。这不是靠增加人手实现的——是把"人工排查"变成了"规则自动扫描+自动定位"。数据质量是数据共享的第一前提：如果数据不可信，再多的共享通道也无人敢用。 4.4 元数据与资产目录：让数据可发现、可理解 当数据出现问题，治理团队需要回答几个基本问题：这个字段来源是哪个系统？经过哪些加工步骤？最近一次变更是什么时候？在没有自动化元数据采集和血缘追踪的情况下，回答这些问题的方式往往是翻阅ETL脚本、查找工单记录、询问相关开发人员——熟悉历史代码的人一旦离开，追溯难度还会进一步上升。 选型时问三个问题：元数据采集是全自动还是大量依赖手工录入？血缘分析能不能跨系统追踪——从源系统字段一路追到BI报表的指标？资产目录是IT人员的"技术台账"，还是业务人员能用业务语言检索、理解和申请使用的"数据地图"？ 学术研究（arXiv:2402.05211）给出了一个清晰结论：好的数据目录不只是技术工具，更是促进跨团队数据共享和复用的组织基础设施。在选型时，资产目录的业务友好度——能不能让非技术人员自助找数——是一个常被低估但实际影响深远的指标。 4.5 治理能力评估小结 子维度 核心检查项 数据标准 字段级标准定义 → 自动落标校验 → 不合规退回 数据质量 可视化配置规则 → 旁路并行监测 → 问题溯源到源头 元数据管理 全自动采集 → 跨系统血缘追踪 → 字段级追溯 资产目录 业务语言检索 → 自助申请 → 质量评分可见 产品对照：部分产品如康桥数据中台基于"理采存管用"方法论，将数据标准管理、质量监测、元数据与血缘、资产目录设计为可独立运行的治理模块，企业可按需选择切入点，先在最痛的数据域建立闭环再逐步扩展。 五、维度二：平台架构开放性 5.1 兼容集成：不是选一个产品，是选一个技术伙伴 数据治理平台不是孤立运行的——它需要和你已有的ERP、MES、CRM、OA等系统协同工作。选型时如果不考察架构开放性，相当于买了一台发动机但没有考虑它能不能装进你的车。 三个层面的兼容性需要逐一验证。数据库层面：支持哪些数据库？信创环境适配了吗？——达梦、人大金仓、海量数据、OceanBase等国产数据库是否在兼容列表中？集成方式层面：多源异构数据接入是通过标准接口（JDBC/API/消息队列）还是私有协议？能不能对接已有的数据集成工具？部署模式层面：是否支持纯私有化部署？能否适配混合云场景？ 中国信通院《数据治理产业图谱3.0》指出，头部厂商正从"单一产品"向"平台化、组件化、可组装"方向演进。这个趋势对选型者的启示很直接：你选的不是一个功能完备的"黑盒"，而是一组可与你现有技术栈组合的能力模块。 5.2 扩展性：从部门级到集团级 很多数据治理平台在部门级场景下表现良好，但一旦扩展到集团多组织场景，架构瓶颈就暴露了。今天是三个业务系统接入，明年可能是十个。今天是单体企业用一个实例，后年可能是集团管控需要分权分域。 选型时的核心检查项是工作空间模型：平台能不能做到"总部统一标准管控、子公司/部门独立自治"？具体来说——总部能不能定义全集团的数据标准和核心质量规则？各子公司能不能在自己的工作空间内独立管理数据资产目录、配置业务级规则？能不能实现跨空间的数据共享和权限隔离？ 江苏某建筑装饰集团（下辖200+家子公司）的实践提供了一个参照：通过多租户架构实现跨公司数据协同后，月底对账时间从5天缩短到1天，数据纠纷减少约80%。某省级城投集团的POC则验证了另一个结论：他们在选型中淘汰了三家只能做单体部署的厂商——不是因为这些厂商的功能不够，而是架构模型无法支撑"集团管控+子公司自治"的双重诉求。 5.3 架构评估小结 评估项 核心检查点 数据库兼容 主流数据库+信创数据库适配认证 集成方式 标准接口（非私有协议）、流批一体 部署模式 私有化部署、混合云支持 工作空间 多租户模型、分权分域、跨空间协同 产品对照：部分产品如康桥数据中台采用"一集团一中台、一公司一空间"的工作空间模型，支持总部统一标准管控与子公司独立自治，已在多个集团型企业中验证了从部门级到集团级的扩展路径。 六、维度三：智能自动化水平 6.1 质量管控的自动化：从手写SQL到可视化配置 传统的数据质量管理大量依赖手工——ETL脚本里写死校验规则，出了问题手动排查，质量报告靠人工统计。这种方式在数据量小、系统少的时候勉强可行，一旦数据源超过10个、数据表超过500张，手工模式就彻底不可持续。 2025年的数据治理平台，自动化水平应该成为硬性评估指标。核心看两点：质量规则的配置门槛和监测的执行方式。 在配置门槛上，选型时要问：质量规则能不能通过可视化界面配置，而不需要写SQL或代码？业务人员能不能参与规则的定义——比如业务部门自己设定"订单金额不能为负""客户名称不能为空"这样的业务规则？如果质量规则只能由IT人员配置，那平台本质上还是技术工具，不是治理平台。 在监测方式上，关键是"旁路监测"能力——质量扫描在数据流转过程中并行执行，不侵入业务系统、不阻断数据流转，发现问题打标记、发告警、生成工单，而不是等到业务投诉再排查。 6.2 AI用数：降低数据使用门槛 大多数企业的数据使用现状是：只有会写SQL的人才能做数据分析，业务部门的用数需求高度依赖IT排期。AI用数能力的出现正在改变这个局面——自然语言查询、智能问答、AI辅助分析，让不会写代码的人也能与数据交互。 选型时看三个层次：第一，平台有没有资产目录作为AI用数的"知识底座"——AI需要知道有哪些数据、数据在哪、数据是什么意思，没有元数据层，AI读不懂数据。第二，自然语言查询的准确率怎么样——能不能在真实业务场景中稳定输出？第三，AI用数能不能做到数据不出域——私有化部署的大模型或检索增强生成（RAG）方案，确保数据安全。 江苏某国企数科的实践具有参考价值。他们运营的数据要素流通平台在部署AI用数智能体后，用户可以通过自然语言完成数据资源的查询和流程引导。更深层的变化在运营机制层面——运营团队从"凭感觉安排数据产品上架"转变为"依据智能体的需求报告召开数据产品决策会"，咨询工单量显著下降。 Data-Centric AI的核心主张在此处尤为重要：AI效果的上限取决于数据质量，而不是模型参数。在数据治理上投入的每一分精力，最终都会在AI效果上体现出来。 6.3 自动化评估小结 评估项 核心检查点 质量规则配置 可视化、业务人员可参与、不需要写SQL 质量监测方式 旁路监测、不阻断业务、自动告警 AI用数 自然语言查询、资产目录驱动、数据不出域 产品对照：部分产品如康桥数据中台内置旁路监测质量管控和AI用数智能体，支持可视化配置质量规则和自然语言分析数据，将治理和用数的自动化贯穿于"管"和"用"两个环节。 七、维度四：安全防护机制 7.1 安全合规已从"加分项"变为"一票否决项" 2021年9月1日起施行的《中华人民共和国数据安全法》，确立了数据分类分级保护制度，要求企业建立全流程数据安全管理制度。在这个法律框架下，数据安全合规已不是"做得好加分"，而是"做不到出局"。 选型时安全维度的评估不需要深入到加密算法或攻防体系的细节——这些是安全产品的评估范畴。对于数据治理平台而言，聚焦三个可验证的合规指标： 第一，是否支持完全的私有化部署——数据不出域，是数据安全合规的底线。第二，是否具备数据分类分级能力——能否按照企业的安全策略对数据进行分级标记、按级管控？第三，脱敏能力如何——在数据共享和对外服务时，能否自动执行脱敏规则？ 这些能力不需要在POC中做安全攻防测试，但需要在产品演示中看到：分类分级的配置流程、脱敏规则的实际效果、权限管控的粒度。 7.2 信创适配不是"认证列表有多长" 信创环境适配是2025年选型中绕不开的话题。但需要提醒的是：认证列表长，不代表适配好。 选型时的正确做法是：第一，确认厂商有完整的信创适配认证——操作系统（麒麟、统信）、数据库（达梦、人大金仓、OceanBase）、芯片（鲲鹏、飞腾）等主流信创产品是否在列。第二，也是最关键的一步——在POC阶段，就在你的实际信创环境上跑一遍。产品在认证实验室里"能跑"和在你的生产环境中"跑得稳"是两回事。 产品对照：部分产品如康桥数据中台已完成麒麟、统信、达梦、人大金仓、OceanBase、华为等主流信创产品的兼容性认证，全系产品只做私有化部署，数据不出域。 八、维度五：长期业务价值 8.1 交付≠完成：看厂商的持续服务能力 数据治理平台不是买个软件装上就完了。它涉及组织变革、流程重构和团队能力建设，是一个持续运营的过程。很多厂商签完合同、部署上线后就转为被动支持模式——有问题你找我，没问题我就等着。但治理平台真正的价值在持续运营中释放。 选型时追问三个问题：部署完成后，厂商会参与运营吗，还是只做远程支持？有没有成熟的培训+陪跑机制——不是一两次集中培训，而是涵盖"为什么做→怎么做→动手做"的梯度赋能？厂商有没有同行业的持续运营案例——不是"做过多少项目"，而是"哪个客户在项目结束一到两年后还在自主运营"？ DCMM在多个能力域中强调，数据管理能力的提升需要组织文化、人员技能和流程机制的综合配套——仅靠工具无法实现成熟度的跃升。DAMA-DMBOK2同样指出，数据管理的成功依赖于"人员、流程和技术的协同"，技术只是三个支柱之一。这给选型者一个明确的信号：选产品，更要选服务能力。 新疆某热力公司的案例提供了一个参照。这家企业承担全市集中供热业务，SCADA、收费、GIS等系统各自独立运行，数据标准不统一，基层人员经常重复录入数据。在建设数据中台的过程中，实施团队没有把工作停留在平台交付层面——围绕理论、实施、实战三个阶段，通过系统化培训帮助信息部门建立对DCMM、DAMA以及方法论的整体认知；结合实际业务场景，指导团队配置数据标准和质量规则；并以真实业务问题为切入点，带领客户完整走通数据治理实践。项目完成后，企业组建起自己的数据管理团队，并将相关机制持续运营至今。 8.2 数据资产化：平台能否支撑长期价值释放 2025年选型，不能只看当下的功能需求，还要看平台能不能支撑未来三到五年的价值演进。这个演进的核心方向是数据资产化——从把数据管好，到把数据变成可计量、可评估、可变现的资产。 选型时看三个能力台阶。第一台阶——资产目录：平台有没有支持业务人员检索和申请的数据资产目录？这不是一个简单的"数据列表"，而是数据的"卡片索引"——包含数据来源、质量评分、更新频率、使用权限等关键信息。第二台阶——DCMM贯标支撑：平台的能力是否能和DCMM 2.0的评估域形成映射？当企业准备申报DCMM贯标评估时，平台能不能提供证据材料——标准执行记录、质量监测报告、元数据资产清单？第三台阶——数据资产入表基础：平台能不能为数据的成本归集、使用量统计、价值评估提供基础数据？当财政部财会〔2023〕11号推动数据资产入表从试点走向扩面，这个能力将从"锦上添花"变成"刚性需求"。 上海某大型化工企业的实践展示了这个演进路径的可能性。他们在数据中台建设过程中，先统一了物料编码等核心数据标准，建立了数据质量规则和管理流程。效果在业务层面直接体现——库存周转率提升28%，订单交付及时率提升至91%。更深远的变化在组织层面：企业成立了数据管理部，实现了从"项目驱动"到"机制驱动"的转变。 8.3 长期价值评估小结 评估项 核心检查点 持续服务能力 培训+陪跑机制、同行业持续运营案例 资产目录 业务友好、质量评分可见、支持自助申请 DCMM贯标支撑 能力域映射、证据材料产出 资产化支撑 成本归集、使用统计、价值评估基础 产品对照：部分产品如康桥数据提供"培训+陪跑"全周期赋能体系——三层培训（理论→实施→实战）和三步陪跑（培训→样板工程→远程支撑），帮助企业实现从"供应商驱动"到"自主运营"的转变。 九、产品映射：五个维度如何落地到产品 五个维度的评估框架回答了"看什么"的问题，接下来需要回答"怎么看"——这些维度在具体的产品中如何体现？DCMM 2.0定目标、"理采存管用"方法论定路径、产品模块定落地，三者之间的关系可以用一张表来呈现。 评估维度 对应DCMM能力域 对应方法论环节 产品能力关键检查项 治理能力完整度 数据标准/质量/架构 理→管 标准自动落标、质量旁路监测、元数据自动采集与血缘 平台架构开放性 数据架构/生存周期 采→存 多源异构接入、多租户工作空间、标准接口（非私有协议） 智能自动化水平 数据应用/流通 管→用 可视化配置质量规则、自然语言用数、AI辅助分析 安全防护机制 数据安全 管 私有化部署、信创适配、分类分级与脱敏 长期业务价值 数据战略/治理/资产 理→用闭环 培训陪跑体系、DCMM贯标支撑、资产化路径 这张映射表的价值在于：当你对一个产品进行五维评估时，每个维度都对应着可验证的产品能力——不是凭感觉打分，而是逐项检查。 更深一层的含义是：五个维度不是独立的功能清单，而是一个问题的五个面。选型时问"这个维度怎么落地"，本质上是在问"方法论有没有产品化"。DCMM 2.0告诉你"要管什么"，方法论告诉你"怎么管"，产品模块告诉你"谁来执行"。选型时如果发现三者之间存在断层——标准写得好但产品落不了、架构设计得漂亮但POC跑不动——那就是需要高度警惕的信号。 十、选型清单与行动建议 10.1 五维评估速查表 把前面五个维度的评估要点浓缩成一张速查表。在选型的每个阶段——需求梳理、厂商初筛、POC验证、最终决策——都可以用它做快速对照。 评估维度 核心问题 怎么验证 治理能力完整度 数据标准/质量/元数据是否形成闭环？ 拿真实业务场景让厂商现场配置一条全流程（建规则→跑监测→出报告→问题追溯） 平台架构开放性 能不能和你现有系统无缝对接？ 查信创兼容性认证、在POC环境实测多源接入 智能自动化水平 自动化降低了多少治理和用数门槛？ 让业务人员（不是IT人员）现场操作质量规则配置和自然语言查询 安全防护机制 安全合规是否到位？ 确认私有化部署能力、数据分类分级和脱敏的配置流程 长期业务价值 厂商是交付完就走还是持续赋能？ 要求厂商提供一个项目结束一年后客户仍在自主运营的真实案例 10.2 给决策者的行动建议 第一步：先理清家底。 在接触任何厂商之前，用DCMM框架做一次自评——你现在处于哪个成熟度等级？最痛的数据域是哪个？是物料编码不统一，还是客户信息混乱，还是报表口径不一致？这份自评报告既是选型需求的输入，也是后续POC验证的基线。如果你的团队对DCMM不熟悉，可以先对标DAMA-DMBOK2的核心领域做一个简化版的数据管理现状梳理。 第二步：POC聚焦核心域。 POC最常见的错误是"全功能演示"——让厂商把系统里所有功能都跑一遍。结果看起来什么都好，但什么都验证不深。正确的做法是：选一个最痛的数据域，用一个真实的业务场景，验证从标准定义、数据接入、质量监测、问题追溯到资产发布的完整闭环。一个域跑通了，评估框架就立住了；所有功能都看了个大概，等于什么都没验证。 第三步：问对问题。 不问"你们有哪些功能"，问"这个功能在实际项目中怎么落地的"。不问"做过多少项目"，问"能不能讲一个项目从启动到验收再到持续运营的全过程"。不问"认证列表有多长"，问"能不能在我们的实际环境上跑一遍"。问题的质地，决定了你能获取的信息的质地。 十一、常见问题 FAQ Q1：功能多少算够？ 不是越多越好。数据治理平台的核心价值在治理深度，不在功能广度。如果你的核心需求是数据集成和共享，可以先上集成+质量模块，跑通之后再扩展。如果你建的是长期数据底座——数据标准、数据质量、元数据管理、资产目录这四个模块一个都不能少，这也是DCMM 2.0重点评估的核心能力域。判断标准不是"有多少功能"，而是"核心域能不能形成闭环"。 Q2：中小团队预算有限怎么选？ 不要看总价，看首年投入和见效速度。选模块化产品，先上最紧迫的模块跑通闭环，再逐步扩展。单台16C32G起步、部署周期约一周的轻量化方案，适合不想一次性大投入的企业。关键不是"买了多少模块"，而是"第一个模块能不能在一个月内让业务部门看到变化"。 Q3：治理平台和AI项目应该先做哪个？ 先治理后AI。Data-Centric AI的研究反复验证：在数据治理上投入的每一分精力，最终都会在AI效果上体现出来。不需要"完美治理"，但至少做到"最小可用治理"——AI需要知道有哪些数据、数据在哪、数据是什么意思。在一个"客户名称"在三个系统里三种写法的数据环境里，再好的AI模型也给不出可靠的分析结论。 Q4：信创环境怎么评估？ 确认厂商有完整的信创适配认证，且在POC阶段就在实际信创环境上实测。认证列表是必要条件，但不是充分条件——实验室里"能跑"和生产环境中"跑得稳"是两回事。建议把信创环境测试纳入POC的硬性环节，而不是作为可选项。 参考来源 [1] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），九大能力域，2026年7月1日起实施 [2] DAMA International, DAMA-DMBOK2: Data Management Body of Knowledge, 2nd Edition [3] 《中华人民共和国数据安全法》，2021年9月1日施行 [4] 中国信通院，《数据治理产业图谱3.0》，2023年12月 [5] 国家数据局等，《"数据要素×"三年行动计划（2024—2026年）》 [6] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号） [7] Andrew Ng et al., Data-Centric AI, https://datacentricai.org/ [8] arXiv:2402.05211, Data Catalog
一、行业背景：为什么现在必须谈DCMM贯标 某企业CDO刚完成数据中台建设，董事长在季度会上问："我们的数据管理水平在行业里排第几？DCMM能过几级？"CDO一时语塞。 中台建好了，但数据管理能力到底怎么样——这个问题越来越多地被问到。三股力量正在把DCMM贯标推向企业议程的核心位置。 第一股力是政策倒逼。 财政部《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号）自2024年正式实施，数据要从"成本项"变成"资产项"。入表的前提是搞清楚数据质量、归属和价值——这恰恰是DCMM评估考察的核心。当CFO开始关心数据管理能力时，DCMM贯标就不再只是IT部门"评个级"的事。 第二股力是标准升级。 DCMM 2.0（GB/T 36073-2025）于2026年7月正式实施，能力域从8个扩展到9个，新增"数据资产"能力域（排第4位），"数据应用"更名为"数据应用流通"。评估标准从"有没有治理"升级为"能不能资产化"——这意味着企业不能再拿旧标准做新评估。 第三股力是竞争压力。 截至2024年7月，全国累计3298家次完成DCMM贯标评估。越来越多的企业将DCMM等级作为数据管理能力的"信用背书"——投标评分加分、合作伙伴准入门槛、集团考核指标。没有DCMM评估等级的企业，在数据能力竞争中正在失去话语权。 二、标准体系：DCMM 2.0九大能力域速览 DCMM 2.0（GB/T 36073-2025）是对企业数据管理能力的全景式评估框架。与1.0（GB/T 36073-2018）相比，有三个关键变化。 1.0→2.0 演进对照表： 维度 DCMM 1.0（GB/T 36073-2018） DCMM 2.0（GB/T 36073-2025） 能力域数量 8个 9个 新增能力域 — 数据资产（排第4位） 命名变更 数据应用 数据应用流通 能力域完整列表 战略/治理/架构/标准/质量/安全/应用/生存周期 战略/治理/架构/资产/标准/质量/安全/生存周期/应用流通 九大能力域速览表： 能力域 类别 核心考察 数据中台承载度 数据战略 战略 是否有规划、有路线图 低（提供支撑，制定靠组织） 数据治理 组织 是否有治理组织、制度、沟通机制 中（提供工具，制度靠人） 数据架构 设计 数据模型、分布、流转是否清晰 高（模型/分布/流转的核心载体） 数据资产 ⭐ 价值 数据是否可盘点、可评估、可入表 高（资产目录/质量评估/价值量化） 数据标准 执行 标准是否制定并执行 高（标准落标、字典管理） 数据质量 执行 是否有质量需求和闭环管理 高（规则/追溯/报告自动化） 数据安全 管控 分类分级、权限、脱敏 中（技术手段，制度靠组织） 数据生存周期 管理 归档、销毁策略 中（配合制度和流程） 数据应用流通 价值 数据是否被使用、共享、产生价值 高（资产门户/API/AI用数） ⭐ = DCMM 2.0 新增能力域，是本次贯标评估的重点增量 九大域中，数据中台直接承载度"高"的有五个域（架构、资产、标准、质量、应用流通），"中"的有三个域（治理、安全、生存周期），"低"的只有一个（战略）。这个分布揭示了一个事实：DCMM评估的大部分能力域，执行层面都依赖数据中台作为技术承载基础。 三、大白话解释：DCMM到底在考察什么 DCMM不是考"平台"，是考"能力"。三个常见误区需要澄清。 误区一："建了数据中台 = DCMM自然高分。" DCMM评估的是"数据管理能力"，不是"有没有平台"。没有中台的企业在数据架构、数据标准、数据质量、数据资产这几个域很难拿高分——因为这些能力需要平台承载和执行。但反过来，有中台不等于能力到位：如果元数据没采、标准没落、质量没监控，平台只是一个空壳。DCMM评估师会直接追问："标准在哪执行的？质量问题怎么追溯？"空壳回答不了。 误区二："DCMM是IT部门的考核。" DCMM第一条能力域就是"数据战略"，第二条是"数据治理"——都是组织层面的事。DAMA将数据治理定义为"围绕数据全生命周期开展的规划、制度、组织、流程与实践活动"。DCMM明确将数据治理组织、制度建设和治理沟通列为核心能力域——数据治理首先是组织治理，其次才是技术治理。没有治理委员会、没有数据管理部、没有制度体系，工具再强也推不动。DCMM 2.0新增的"数据资产"域进一步拉高了组织协同的门槛——资产确认需要财务和业务一起参与，不是IT自己能定的事。 误区三："过了DCMM评估就万事大吉。" DCMM贯标是起点，不是终点。五级成熟度阶梯中，大多数建了中台的企业在2级（受管理级）——数据集中了、基本治理做了，但标准和质量的执行仍靠人工。从2级到3级（稳健级）需要12-24个月，核心是把标准和质量的执行从"人工"变成"自动"。DCMM 2.0的"数据资产"域更是要求持续运营——资产目录不是一次盘点就完事的，数据每天都在变。资产化是持续过程，评估只是阶段性检验。 四、方法论拆解："理采存管用"×DCMM 2.0九域系统映射 DCMM是"检查清单"——告诉你企业应该具备什么数据管理能力。理采存管用是"施工图纸"——告诉你这些能力如何通过工程化手段落地。一个是目标，一个是路径。 DCMM 2.0 × 理采存管用 × 中台动作对照表： 理采存管用 对应 DCMM 2.0 能力域 中台动作 关键产出 理 数据战略 → 数据治理 → 数据架构 梳理业务流程、盘点数据资源、建立治理组织 数据资产目录初稿、战略规划 采 数据架构 → 数据生存周期 打通多源异构系统、流批一体数据归集 统一数据汇聚通道 存 数据架构 → 数据标准 数仓分层建模、统一数据模型 标准化数据底座 管 数据治理 / 数据标准 / 数据质量 / 数据安全 元数据+主数据管理、质量规则配置、分类分级、安全管控 治理闭环、质量报告 用 数据资产 → 数据应用流通 资产目录发布、API共享、可视化报表、AI智能用数 业务自助用数、资产价值释放 关键洞察：DCMM 2.0新增的"数据资产"域，在理采存管用中横跨"理"和"用"两个阶段——"理"阶段摸清资产家底（资产盘点），"用"阶段让资产产生价值（资产目录发布、API共享、AI用数）。这正是数据资产化"资源化→资产化→资本化"三步走在方法论层面的体现——从识别资源、到管理资产、再到释放价值，五个字闭环完整覆盖。 康桥数据中台遵循理采存管用方法论进行模块化设计，如图所示，DCMM 2.0九大能力域→五阶方法论→产品模块形成三层映射：国标定目标、方法论定路径、产品定落地。 五、实践映射：数据中台如何支撑六大核心域 在DCMM 2.0九大域中，数据中台直接承载度最高的六个域，每个域有明确的落地路径。 5.1 数据战略 → 数据治理（组织先行） DCMM前两个域考察的是组织能力。中台能做的是提供支撑工具——资产盘点工具（对应"理"）、治理流程工具（对应"管"）——但战略制定和治理组织建设必须靠企业自己。上海某大型化工企业（案例03）在建设数据中台的同时，成立了数据管理部并设立数据管家岗位，将数据治理纳入绩效考核体系，实现了从"IT项目"到"机制驱动"的转变。这一组织变革本身就是DCMM治理域的加分项。 5.2 数据架构（中台是核心载体） DCMM要求管理数据模型、分布、流转和集成。数据中台通过元数据管理自动建立数据地图，通过血缘分析自动展示数据流转路径。当业务部门想关联分析两个数据域时，立即可见它们的血缘关系——不用再找人问"这数据从哪来的"。架构治理从"靠人记"变成了"系统管"。 5.3 数据资产 ⭐（2.0新增，中台是核心基础设施） DCMM 2.0新增的"数据资产"域考察三项核心能力：数据资产盘点（有什么）、质量评估（值不值钱）、价值管理（怎么用）。数据中台的资产目录模块负责"有什么"，质量管理模块负责"值不值钱"，资产门户和API共享模块负责"怎么用"。没有中台承载，这三件事靠Excel和人工几乎不可持续——上千张表的数据量、持续变化的数据内容，人工方式无法做到实时更新和动态评估。 5.4 数据标准（从文档到执行） DCMM要求的不只是"制定标准"，更是"执行标准"。中台的路径是：在元数据管理模块中定义标准（字段名、类型、值域），数据接入时自动校验合规性，不合规的退回源系统。康桥数据中台在多个项目中通过标准自动落标，将字段合规率从60%提升到95%以上。 5.5 数据质量（从事后救火到持续监控） DCMM数据质量域涵盖质量需求、检查、分析和提升四个过程域。中台的做法是通过旁路监测模式——数据正常入库，质检规则并行扫描，发现问题打标记、发告警、生成工单，不拦截不阻断。江西某国控集团通过建立质量闭环管理机制，半年内将核心数据质量问题的修复周期从两周缩短到两天。 5.6 数据应用流通（让数据产生价值） DCMM的最高要求是"数据驱动决策"。中台支撑这一步的关键是降低用数门槛——资产门户让业务人员用业务语言找数据，AI智能用数让不会写SQL的人也能分析。某市监局通过中台将多个业务条线的数据归集后，统一对外提供数据服务接口，业务部门从"找IT排期"变成了"在线申请、自动审批"。 康桥数据中台严格遵循理采存管用方法论进行模块化设计，各模块既可独立部署也能协同工作。旁路监测模式让质量管控在不侵入源系统的前提下完成闭环——数据正常流转的同时并行扫描，发现异常自动生成工单推动修复。 六、案例验证：从贯标到资产化的真实路径 福建某交投集团 — 数据资产入表 这家负责城市数字化运营的国企，拥有充电系统、调度系统、安防系统等上千张业务表。表面上看数据不少，但一深挖就发现问题——同一类充电桩数据分散在三个系统中，各有各的命名规则。不知道有多少数据、哪些有价值、哪些需要治理。 项目团队采取了"三步走"路径： 第一步：全量数据资产盘点（对应DCMM"数据资产"域—资产盘点）。不谈标准、不谈质量，先把家底摸清楚。通过自动化扫描与业务规则相结合，仅资产目录梳理就涉及上千张表，最终识别出充电订单、支付流水、用户档案、对账记录等核心数据资源，形成了标准化的《企业数据资产目录》。 第二步：建立数据标准体系（对应DCMM"数据标准"域）。统一跨系统的命名规则、编码规范和质量校验标准。在此之前，"同一类数据在三个系统有三种说法"的情况是常态——标准体系建设让数据语言首次统一。 第三步：完成资产质量评估和合规审查（对应DCMM"数据质量"域+"数据资产"域—质量评估）。依托康桥数据质量管理服务，以国家标准《GB/T 36344-2018 信息技术 数据质量评价指标》为框架，对拟入表数据资源进行全量自动化评价，最终质量评价总评分达99.53分。 成果：首批数据资产成功入表，成为福建省某市国有企业中第一批完成数据资产入表的企业。更重要的是——集团第一次真正搞清楚了自己有多少数据、哪些数据有价值。 启示：数据资产入表不是会计问题，是数据治理问题。表能不能入，取决于有没有做资产盘点、有没有做质量评估、有没有建立标准体系。这些恰好是数据中台应该做的事。DCMM 2.0新增"数据资产"域，正是要把这些能力纳入标准化评估——让入表有据可依，让资产化有标可循。 七、FAQ Q1：DCMM 2.0和1.0的核心区别是什么？企业现在按哪个版本准备？ DCMM 2.0（GB/T 36073-2025）于2026年7月1日起正式实施。核心变化是能力域从8个扩展为9个，新增"数据资产"能力域（排第4位），"数据应用"更名为"数据应用流通"。当前过渡期建议按2.0准备——因为新增的"数据资产"域需要较长时间建设（资产盘点+质量评估+目录管理），不是短期内能突击完成的。早准备早受益。 Q2：企业建了数据中台，DCMM评估还需要额外做什么？ 数据中台解决了平台承载问题，但DCMM评估的是综合能力。有三件事中台本身不能替代：一是战略规划和组织建设（数据战略域、数据治理域需要管理层推动）；二是制度体系建设（需要配套管理制度和考核机制）；三是持续运营（标准和质量规则需要根据业务变化持续迭代）。中台+制度+组织，三驾马车缺一不可。 Q3：DCMM贯标评估和最近的数据资产入表是什么关系？ 数据资产入表（财会〔2023〕11号）是财务侧的合规动作，DCMM评估是数据管理能力侧的标准化评定。两者的交集在DCMM 2.0新增的"数据资产"域——这个域考察的资产盘点、质量评估、价值管理，恰好是资产入表的前置条件。DCMM评估为资产入表提供了"数据是否达到资产标准"的能力验证。做DCMM贯标的企业，在资产入表时会有更扎实的数据基础。 Q4：从启动DCMM贯标到拿到三级证书，一般需要多长时间？ 取决于企业数据管理基础。如果已有数据中台底座：从初始级到受管理级（2级），快的6-12个月（补齐基础治理能力）；从受管理级到稳健级（3级），通常需要12-24个月——需要把标准和质量从人工变成自动。DCMM 2.0新增"数据资产"域后，三级对资产盘点和管理的要求更高，建议提前布局资产目录建设。关键是持续投入，不是突击冲刺。 本文基于DCMM 2.0（GB/T 36073-2025）国家标准框架撰写，案例数据来自康桥数据项目实践。
