某企业数据治理项目立项，两份方案摆在了决策桌上：数据质量厂商推荐独立部署一套数据质量管理平台，数据中台厂商则说"中台自带质量模块，不需要重复采购"。预算有限，治理团队内部为此讨论了好几轮——质量团队担心模块能力不够深，中台团队担心重复建设。 这个场景在 DCMM 2.0（GB/T 36073-2025）[1] 实施后越来越常见。两类方案不是简单的"谁替代谁"，而是定位不同、能力边界不同、适用场景不同。选错带来的不只是预算浪费，后续治理的深度和运营方式都会受牵连。本文从六个维度给出对照框架，供读者结合自身情况判断。 一、DCMM 2.0 对数据质量的要求，先说清楚"要什么" DCMM 2.0 于 2026 年 7 月 1 日正式实施，在其九大能力域中，数据质量域包含四个能力项：数据质量需求、数据质量检查、数据质量分析、数据质量提升[1]。注意一个容易被忽略的细节——"检查"只是四个环节之一。 这意味着标准要求的质量管理是一个体系，而不是一个检测工具。只看"能不能检测问题"，与标准要求的差距是比较明显的。从企业实践看，很多质量项目恰恰卡在这里：规则配了不少，告警每天在出，但问题认领、根因分析和流程改进长期缺位，质量问题反复出现。 在定义"什么算好数据"时，GB/T 36344-2018《信息技术 数据质量评价指标》[2] 提供了起点：规范性、完整性、准确性、一致性、时效性、可访问性六个维度。六个维度除可访问性外，其余五个直接影响数据应用效果，也是质量需求定义时被引用较多的框架。 先谈标准，是因为选型的前提是明确目标：如果只是要"检测问题"，两类工具都能做到；如果要建的是覆盖需求、检查、分析、提升四环节的体系，评估重点就完全不同。截至 2025 年 11 月，全国已有超过一万家企业完成 DCMM 贯标评估[4]，贯标实践中数据质量域往往是差距较大的能力域之一，原因多半不是没有规则，而是规则与闭环之间存在断裂。另一个常被提及的判断是，数据质量是数据共享的第一前提——脏数据跨部门共享只会放大错误。 二、两类产品的定位差异 2.1 独立数据质量平台：质量为主业的"专精"型 独立数据质量管理平台把数据质量作为核心主业，能力围绕质量闭环展开：标准管理、规则创建、质量评测、问题闭环管理、质量评价。这类产品通常沉淀了可复用的规则资产——以龙石数据质量管理平台为例，内置标准库与规则库开箱即用，质量规则覆盖五大类，支持零代码可视化配置，采用旁路监测模式不侵入原始业务库，可应对百亿级数据量评测[5]。 更关键的是闭环深度：问题数据支持自动派发、源头修复、督办考核与审计追溯，全流程留痕。部分平台还提供 AI 智能评测，覆盖 DCMM 数据质量四个能力项、DAMA 数据管理知识体系与 GB/T 36344 的评价维度[5]。 独立平台的另一个特征是中立性。它以第三方视角开展质量评测，可以出具对外使用的评估报告，这在数据资产入表、数据交易挂牌、监管报送等场景中是硬需求。 2.2 数据中台质量模块：一体化治理中的"嵌入"型 数据中台质量模块是"理采存管用"方法论中"管"环节的子能力，与数据集成、标准管理、元数据管理、数据共享处于同一平台。质量不再是独立系统，而是随数据流转内嵌在治理链路里：数据标准定义了字段口径，质量规则校验数据是否符合标准，元数据记录了数据来源，质量结果又可以反馈给标准迭代。 其核心运行模式是旁路监测——数据正常入仓，质检规则并行扫描，发现问题打标记、发告警、生成整改工单，不拦截不阻断原有的数据链路。这种方式对业务系统无侵入，规则通过可视化界面配置，业务人员也可以参与。落标，即把已发布的数据标准关联到真实表字段上、检查实际数据是否符合标准，在中台里与标准管理模块天然联动。在多数中台产品中，质量规则同样支持完整性、准确性、一致性、时效性等多类检查，规则配置方式与独立平台类似，差异主要体现在规则资产的沉淀深度和问题闭环的组织方式上。 以龙石数据中台为例，质量模块作为"管"环节的一部分，随中台按需装配——可以单独启用，也可以与数据集成、标准、元数据等模块组合使用[5]。 2.3 两类形态的对照 对比项 独立数据质量平台 数据中台质量模块 定位 质量为主业的专精型系统 一体化治理中的嵌入型子模块 核心能力 标准-规则-评测-问题-评价全流程闭环 旁路监测 + 与集成/标准/元数据联动 规则体系 标准库、规则库沉淀与复用 常用质检规则，随标准管理联动 闭环深度 问题派发、源头修复、督办考核、审计追溯 检测、告警、工单、整改跟踪 中立性 第三方视角，可出具对外评估报告 内嵌于治理体系，服务于内部管理 部署成本 独立部署，需单独采购与运维 随中台装配，与现有平台共用底座 适用边界 全域多系统、规则复杂、需对外报告 中台数据域内治理、随中台统一运维 需要说明的是，上表按两类产品的通用形态归纳差异，供对照参考，不构成优劣结论——闭环深浅、规则体系强弱取决于各厂商的具体实现，两类形态均有深浅之分。以龙石为例，其独立数据质量管理平台与数据中台的质量模块在规则配置体验上保持一致，差异主要体现在标准库、规则库、问题派发与考核审计等深度能力是否具备。 三、六个选型维度：不预设答案的对照框架 六个维度只提供对照视角。每个维度先看"判断问题"，再看两类产品在该维度上的形态差异，最终由读者对照自身情况判断。 维度一：治理范围。 质量治理要覆盖哪些数据——仅中台、数仓内的数据，还是包括各业务系统源端、跨部门共享数据、对外交换数据？范围不同，工具的接入边界就不同：全域治理需要对接多个系统源端并统一管理；域内治理跟随数据汇聚位置即可。先画出质量工作的覆盖边界，再对照两类产品的接入能力。 维度二：数据来源复杂度。 数据源的数量、类型与异构程度，以及是否存在跨系统一致性比对需求——例如 CRM 与订单系统的客户信息是否一致、多系统指标口径能否核对。来源越复杂，对工具的接入广度、规则适配与联动能力要求越高；来源集中时，轻量方案即可胜任。政务场景中，华东某市监局的数据治理平台就包含跨系统的数据关联比对能力，用于核对同一主体在不同系统中的登记信息是否一致；华东某国控集团则在数据中台内配置了完整性、准确性、一致性、及时性、唯一性稽核规则，实现自动检测、异常告警、问题定位、整改跟踪的闭环——这两类场景考察的都是对多来源数据的处理能力，只是承载方式不同。 维度三：质量规则复杂度。 需要管理的规则分几个层次——基础完整性、唯一性检查，跨字段校验，时效性规则，以及业务自定义规则？DCMM 2.0 四个能力项意味着规则不止于"检测"；GB/T 36344 的六维度可以作为规则体系设计的起点。DAMA-DMBOK2[3] 将数据质量评估分为初始评估与持续监测两类，规则体系的组织方式同样可以参照这个思路。规则层次多、需要长期沉淀复用时，对规则引擎的独立管理能力要求更高；规则简单直接时，嵌入式方案也能覆盖。行业里一个常见的情形是，制造企业围绕物料、客户等主数据配置编码和校验规则，从几十条逐步积累——华东某电子制造企业的主数据治理就是这样起步的，规则能否沉淀、复用、演进，直接影响后续治理的边际成本。 维度四：组织模式。 质量工作由谁主导、向谁汇报？是否有专职质量团队或岗位，还是依托中台运维团队？组织上是否需要以独立于使用方的身份对外出具质量评估报告，用于数据资产入表、数据交易挂牌或监管报送？组织定位决定工具形态的适配性：需要第三方身份出具报告时，出具主体的独立性与资质是硬约束，需要向候选厂商确认；组织内统一运维时，模块化方式与现有体系衔接更顺。一个参照是，数据交易平台普遍要求上架产品经第三方质量评估并出具报告，江苏某数据交易所的挂牌流程即是如此——这类场景天然指向具备独立评测身份的产品或服务。 维度五：已有技术架构。 当前是否已有数据中台或数仓底座、技术栈是否统一？已有中台、且质量工作在其数据范围内时，模块化扩展的衔接成本较低；没有底座时，从质量平台起步的投入更轻，但需要与后续的数据架构规划一并考虑——如果企业计划建设中台或数仓，先上的质量平台能否与后续底座对接，值得提前确认。 维度六：长期运营方式。 质量工作如何长期运转——专职团队常态化运营，以月报、考核、审计追溯为周期，还是随中台统一运维？运营主体与考核机制一旦确定，工具形态应与之匹配。数据中台不是一次性项目，而是持续运营的能力平台；运营机制先于工具选型，是较为稳妥的做法。 需要强调的一点是：六个维度没有固定权重，关键是识别当前的主要矛盾是范围、规则还是组织机制。对照自查后，两类产品各有适配场景，不存在普适的"更强"。 四、场景画像与组合使用建议 按六个维度自查后，多数企业会落在以下典型情形。画像仅作匹配参考，不作优劣判断。 画像 A：独立质量平台更适配的情形。 治理范围覆盖全域、目前没有现成数据底座、规则体系复杂、需要第三方评估报告、由专职团队常态化运营。华东某数据局的数据质量管理服务是这类场景的典型：各委办局数据标准各异，跨部门协同困难，项目以"标准先行、监测常态化、修复闭环化"为核心，建立质量监测规则，问题纳入"质量监测→发现问题→派发工单→部门修复→复验归档"的闭环，并沉淀规则库与问题修复知识库[5]。华东某大数据中心则在此基础上，形成了"制度+标准+监测"三位一体的治理体系，以月为周期出具质量评估报告，规则库沉淀数千条，问题修复率超过九成[5]。这类制度化、运营化的质量工作，独立平台的组织成本更低。 画像 B：中台质量模块更适配的情形。 已有数据中台、治理范围集中在中台数据、规则以检测加告警为主、随中台统一运维。华东某国控集团是典型：中台内建质量稽核规则，自动检测财务填报错误、投资项目信息缺失等问题，自动预警、精准整改，质量管控与统一标准、主数据、资产目录在同一平台内联动。质量作为"管"环节的一部分嵌入治理链路，不需要单独维护一套系统的账号、权限和运维。 画像 C：组合使用。 两类产品不是非此即彼。常见做法是：中台模块承担日常旁路监测，独立平台或第三方服务承担专项评测与对外报告。例如日常监测发现的高频问题在中台内闭环处理，年度质量评估、入表前的质量核验等专项工作交给独立评测。组合使用的前提是先明确分工，避免两套系统重复配置规则。 起步建议。 如果预算有限、团队规模小，不急于一步到位，可以从一次免费的质量体检起步——市场上已有免费可用的数据质量工具，例如龙石数据质量管理平台·社区版，支持十余类质检规则，一条命令即可部署，先跑通"发现→修复→验证"的闭环，再依据体检结果定选型方向，按六个维度决定升级路径[5]。治理能力的建设是渐进的过程，先摸清家底再决定投入规模，通常比一步到位上重型平台更稳妥。 工具选型只是起点，质量能力的长期运转最终要靠组织与运营。龙石在交付工具的同时提供培训与陪跑服务，帮助客户团队自己掌握规则配置、问题分析和闭环运营的方法，实现从"厂商主导"向"企业自主运营"的能力转移[5]。这一点在评估长期运营方式维度时，值得一并纳入考量。 五、FAQ Q1：企业已经上了数据中台，还需要单独采购数据质量平台吗？ 没有标准答案，回到六个维度对照即可：治理范围是否超出中台数据、质量规则复杂度是否超出"检测+告警"、组织上是否需要独立出具报告——对照结果指向哪类，再决定是否单独采购。判断方法见第三节。 Q2：数据质量平台和数据中台质量模块可以一起用吗？会不会重复建设？ 可以组合使用，且组合是不少企业的实际选择：中台模块做日常监测，独立平台做专项评测和对外报告。关键在分工——日常规则在哪个系统配置、专项评估由谁出具、问题台账以哪边为准，先明确再采购，可以避免两套系统重复配规则。 Q3：预算有限、团队小，从哪一类起步更稳妥？ 可以先做一次免费的质量体检摸家底，以结果定选型方向——第四节起步建议中的社区版路径就是具体做法，部署快、规则覆盖常用场景，先跑通闭环再决定升级方向。 Q4：数据资产入表需要第三方质量评估报告，中台质量模块能出吗？ 关键在组织维度：对外评估报告对出具主体的独立性有要求，数据交易挂牌等场景也普遍要求第三方评估。是否由中台模块出具，取决于厂商的评测身份与资质能否满足要求，建议先与候选厂商确认，再对照第三节维度四判断。 参考来源 [1] 国家市场监督管理总局、国家标准化管理委员会，《GB/T 36073-2025 数据管理能力成熟度评估模型》（DCMM 2.0），2026年7月1日实施 [2] 国家市场监督管理总局、国家标准化管理委员会，《GB/T 36344-2018 信息技术 数据质量评价指标》 [3] DAMA International,《DAMA数据管理知识体系指南（第二版）》(DAMA-DMBOK2) [4] 中国电子信息行业联合会，DCMM 贯标统计数据（2025年11月） [5] 龙石数据，数据质量管理平台产品介绍，https://www.longshidata.com/products/quality.html
AI团队负责人找到数据团队："模型训练跑出来的结果不对，排查发现数据集里的客户姓名有空的、手机号格式乱的、性别字段有六种写法。这些数据你们不做检查吗？" 这位负责人的遭遇并非个例。很多企业在建AI数据集时，把"数据集"等同于"数据汇总"——把各业务系统的数据拉出来堆在一起就交付了。但数据集和原始数据汇总之间有本质区别：未经质量验证的数据投入模型训练，错误会被放大而非消除。GB/T 36344-2018《信息技术 数据质量评价指标》定义了六个数据质量评价维度——规范性、完整性、准确性、一致性、时效性、可访问性，除可访问性侧重技术存取条件外，前五个维度直接影响AI应用效果。五类基础质量检查是高质量数据集建设的前提，但并非全部要求——数据集还需要在标准对齐、元数据标注等方面持续完善。 在这个方向下，市场上已有免费可用的数据质量工具。以龙石数据质量管理平台·社区版为例——作为信通院《数据治理产业图谱3.0》入选厂商和DAMA大中华区实训基地，龙石在这个领域已经有多个项目验证——它采用旁路监测模式：数据正常入库，质检规则在旁路并行扫描，发现问题后打标记、发告警，不阻断业务流程。社区版内置12类可视化配置的质检规则，覆盖五维质量评价，部署后即可对核心数据源进行系统的质量检测。以下操作均基于该平台展开。 一、前置准备：看清数据全貌 在开始配置质量规则之前，需要先让平台"认识"你的数据。这一步的核心是数据源接入和元数据管理——没有元数据，后续的规则配置和问题定位都缺少参照系。 1. 数据源接入 在社区版中接入业务数据库，填写连接信息后保存即可。平台支持MySQL、Oracle、SQLServer、PostgreSQL等关系型数据库，也兼容Doris、Vastbase G100、KingbaseES V8、GBase8a等国产数据库。接入时需确保数据源与平台服务器网络互通，连接池参数使用默认值即可，大数据量场景下可按需调整。 2. 元数据采集 数据源接入后，系统会自动创建元数据采集任务。点击"立即执行"后，平台同步当前数据库的最新表结构——包括表名、字段名、数据类型、长度、精度、主键、注释等信息。需要注意：每次表结构发生变更后，都必须重新执行元数据采集*，否则新增字段或变更的数据类型不会被后续的质检规则感知到。 3. 元数据维护 自动采集得到的是物理表名和字段名（通常为英文），需要为表和字段补充业务名称与业务描述。例如物理表 customer_info 补充为"客户基础信息表"，字段 phone 补充为"手机号码"。后续质量评测的规则配置和问题数据展示，都依赖这些业务元数据来提升可读性。 另外，被评测的表必须存在物理主键*（数据库层面定义的主键字段）或逻辑主键*（如果表没有物理主键，可指定一组字段共同作为唯一标识）。同时设置业务标识字段*——它决定了问题列表里优先展示哪个字段来代表"这是哪条记录出了问题"。 二、完整性保障：数据不能缺胳膊少腿 完整性是数据质量的底线。如果关键字段大量为空，后续所有分析、建模都失去基础。 典型场景*：CRM（客户关系管理系统）中客户姓名、手机号字段大量为空，AI模型训练时连"谁是客户"都搞不清楚；数据从源库归集到目标库后，发现丢了上千条记录——归集过程出了问题但无人察觉。 操作步骤*： 创建评测模型*：在"评测模型管理"中创建模型，命名如"CRM客户信息评测"，选择对应的数据库。 新增评测对象*：选择 customer_info 表作为评测对象，设置评测方式（全量同步）、逻辑主键和业务标识字段。 配置空值检查规则*：新增规则→选择"空值检查"→检查字段选 customer_name 和 phone→检查方式选"每个字段都不能为空"。规则描述可写为"客户姓名和手机号是客户身份的基础标识，不能为空"。 配置数据缺失检查规则*：新增规则→选择"数据缺失检查"→选择参照库和目标表→通过关联字段建立映射→检查归集前后数据条数是否一致。 DAMA-DMBOK将完整性列为数据质量的基础维度，DCMM 2.0（GB/T 36073-2025）数据质量域的"质量检查"能力项也明确覆盖完整性校验。从实践来看，完整性通常是企业数据质量问题中占比最高的一类，也是最适合作为质量治理起点的维度。 三、规范性保障：数据要能"对得上话" 如果说完整性解决的是"有没有"的问题，规范性解决的是"说不说得上话"的问题——不同系统对同一个信息的表达方式必须对齐。 典型场景*：同一个员工的性别字段，CRM写"M/F"，订单系统写"男/女"，BI报表里出现"0/1/未知"。三套系统三种口径，跨系统关联分析时直接翻车。 操作步骤*： 配置格式规范性检查规则*：使用EL表达式（EL是一种简单的表达式语言，平台用它来做轻量级规则配置，不需要写Java代码）校验格式是否合规。 手机号格式：#phone REGEXP '^1[3-9][0-9]{9}$' 身份证号、统一社会信用代码、邮箱等同理 配置引用完整性检查规则*（字典校验）：确保代码字段的取值在标准字典范围内。 性别代码引用标准字典（M=男/F=女） 注册状态、用户等级、合同状态等代码字段同理 需要注意：引用完整性检查引用的是数据标准模块的字典定义，空值不参与引用完整性评测*——这避免了"空值被当成字典外异常"的误报，让规则聚焦于"有值但值不对"的问题。 四、准确性保障：数据要"靠得住" 数据有值、格式合规，不代表它就是对的。准确性关注的是数据是否真实反映了业务现实——这是五个维度中最难检查但也最关键的一环。 典型场景*：销售流水表中出现了超出合理范围的金额记录（正常的退款冲销会产生负数，此处指明显的业务异常，如单笔金额远超合同上限）；财务系统中毛利率与BI报表的计算结果不一致——数据没有空值、格式也合规，但值本身就是错的。 操作步骤*： 配置值域检查规则*：限定字段的取值范围——交易金额必须大于0，库存数量不能为负数，年龄介于0-120之间。空值不参与评测。 配置逻辑检查规则*：用EL表达式或JAVA代码验证多字段间的业务逻辑关系。例如毛利率公式验证： EL表达式：#orderAmount > 0（适合简单规则快速配置） JAVA代码：适合复杂业务逻辑——如验证毛利率字段值是否等于(销售收入-销售成本)/销售收入 配置SQL检查规则*：复杂业务逻辑用自定义SQL深度验证——例如检查所有已发货订单，其实际发货日期是否不晚于承诺日期加3天。 五、一致性保障：数据要"对得上" 不同系统中存储的同一业务对象的信息应当一致。当CRM中的客户等级是"金牌"、订单系统里却是"银牌"时，跨系统分析的结果就失去了可信度。 典型场景*：同一个客户在CRM里客户等级为"金牌"，订单系统里显示为"银牌"；订单状态标记为"已发货"，但仓库无出库记录、物流无运单信息——存在矛盾的数据会让AI模型学到错误的关联模式。 操作步骤*： 配置一致性检查规则*：选择参照对象（如订单系统对应表），通过客户ID关联，检查客户等级、所在区域、联系方式等字段在两个系统中是否一致。空值不参与评测。 配置交叉比对检查规则*：多表联合验证——订单状态 vs 仓库出库记录 vs 物流运单信息，三者一致才算通过。交叉比对需要至少2个比对对象，且只有当评测对象与所有比对对象同时不一致时才标记为问题。 配置关联关系检查规则*：验证表间关系的完整性——每个员工有且仅有一张工卡（1:1关系），每个客户可以有多条订单记录（1:N关系）。 关联关系检查支持三种对应关系：1:1（一对一，如员工-工卡）、1:0-1（一对零或一，如员工-笔记本电脑）、1:N（一对多，如客户-订单）。 六、时效性保障：数据不能"过时" 数据完整、规范、准确、一致，但如果是半年前的快照——模型训练时上个月的新增客户完全没被覆盖，预测效果自然大打折扣。时效性检查的核心不是"有没有做"，而是先定义清楚"什么叫过时"，再通过调度持续执行。 定义时效规则：明确每张核心表的时效要求—— 数据更新时间不得超过N小时/天 同步延迟不得超过M分钟 数据必须在业务有效期内（如合同数据不得超过合同截止日） 不同业务场景对时效的要求差异很大：交易数据可能是分钟级，客户主数据可能是天级，不能一刀切。 配置定时调度：定义时效规则后，通过评测任务调度持续执行。社区版支持四种执行策略： 首次执行建议：先用"手工触发"跑一次，确认规则无误且误报率在可接受范围内，再切换为重复执行——直接上定时调度可能会因为规则参数不合理而产生大量误报。 七、从检测到闭环：让质量问题能被管理起来 配置完规则只是开始——质量管理的目标是让问题能够持续被发现、被跟踪、被修复，形成可运转的闭环。 操作流程： 首次验证：先用"手工触发"跑一次，逐条确认问题数据是真的质量问题还是规则误报。如果误报率高，调整规则参数和过滤条件后再跑。 切换定时运行：规则验证无误后，切换为重复执行（按天），让质量检查成为日常自动化流程。 问题数据查看：在"问题数据查看"中按主题、模型、规则、问题状态（待修复/已关闭）、评测日期筛选问题。业务标识字段帮助快速定位"这是哪条记录出了问题"。 修复与复验：业务侧修改源数据后，下次评测任务运行时会重新检查该条记录——如果问题已修正，系统自动将状态更新为"已关闭"。 进度跟踪*：在"问题数据统计"中按层级查看各主题、模型、规则的问题数据量和修复率，跟踪治理进度。 数据质量管理的目标，并不是一次性清理所有问题，而是在不影响业务运行的前提下，让问题能够持续被发现、被跟踪、被修复。从一个核心业务域的三五条规则起步，跑顺畅了再逐批扩展覆盖范围。规则持续运行，质量持续提升，高质量数据集的建设才能真正成为日常工作的一部分，而不是项目验收时的一次专项行动。 附：五类质量问题 × 12类质检规则映射速查 上文第二至第六节演示了五类质量问题的核心规则配置方法，其余规则的使用方式类似——选定规则类型、指定检查字段、配置参数、补充描述即可。下表为完整映射速查： 12类规则中还包含唯一性检查和自定义扩展两类未在上述五类映射中展开。唯一性检查用于检测重复数据（如同一个学号出现两次），自定义扩展支持通过EL表达式/JAVA代码或对接外部API实现特殊校验需求。从多数使用经验来看，12类内置规则已覆盖绝大多数常见场景。 常见问题 Q1：部署社区版需要什么条件？ 最低4核16G内存、100G磁盘，CentOS 7.9操作系统，一行命令10-20分钟即可完成部署。支持MySQL、Oracle、SQLServer、PostgreSQL及Doris、Vastbase G100、KingbaseES V8、GBase8a等国产数据库。 Q2：五类问题应该先解决哪一类？ 没有适用于所有企业的统一顺序。如果当前最突出的是数据大量为空，就从完整性入手；如果跨系统口径打架最严重，优先做一致性和规范性。建议从一个核心业务域起步，每类问题先配置3-5条高价值规则，跑通闭环后再逐步扩展。 Q3：旁路监测会影响数据库性能吗？ 质量扫描会消耗数据库资源，建议设置过滤条件限定扫描数据范围，并在低峰期（如夜间或周末）执行。首次全量扫描时如果数据量较大（千万级以上），用评测对象的过滤条件限定数据范围尤为重要。 Q4：规则配置后系统会自动修复数据吗？ 不会。质量管理的职责是发现问题和推动治理，不是直接修改业务数据。问题数据进入问题库，标注清楚哪条记录、违反了什么规则、建议怎么修复。业务侧修改源数据后，下次评测任务运行时会重新检查该条记录并更新状态。 Q5：业务表新增了字段，规则需要全部重建吗？ 如果新增字段不影响已有规则（比如只增加了备注列），现有规则不需要修改。如果新增字段需要纳入质量监控，直接在评测模型里新增对应的评测规则即可，不需要重建整个模型。同时不要忘记重新执行元数据采集以同步新字段信息。 Q6：12类规则之外还有特殊校验需求怎么办？ 使用"自定义扩展"规则类型，支持通过EL表达式/JAVA代码或对接外部API服务实现定制化校验。不过从多数使用经验来看，12类内置规则已经覆盖了绝大多数常见数据质量校验场景。 数据集和原始数据的区别，在于前者经过了系统的质量验证。完整性让数据不缺失，规范性让数据可对话，准确性让数据不误导，一致性让数据不矛盾，时效性让数据不过时——这五件事做扎实了，模型训练才有可靠的信息基础。企业AI建设的瓶颈正在从模型能力转向数据能力，而数据质量的体系化治理，正是这个转型中最值得投入的一项基础工作。 参考来源 [1] GB/T 36344-2018《信息技术 数据质量评价指标》，国家标准化管理委员会 [2] DAMA International,《数据管理知识体系指南》（DMBOK2，第二版） [3] GB/T 36073-2025《数据管理能力评估模型》（DCMM 2.0），国家标准化管理委员会 [4] 龙石数据质量管理平台（社区免费版），https://www.longshidata.com/community/products/quality-community.html
一位刚完成DCMM自评的CDO翻着厚厚的制度文件——数据管理办法、数据标准规范、质量管理制度一应俱全——但评估师追问的是："这些制度的实际执行记录在哪里？标准字段覆盖率是多少？质量问题平均闭环周期多长？" 这并不是个别现象。DCMM 2.0（GB/T 36073-2025，2026年7月1日起实施）[1]的核心变化之一，就是将评估方式从以定性判断为主升级为量化度量——486项评估指标分布在一套要求可复验的证据体系中[2]。制度的价值在于定义规则，但规则的执行、监测、追溯和持续改进，越来越需要一个数据治理平台来承载。 制度管"应不应该做"，平台管"有没有在做"——两者不是替代关系，而是互补关系。本文以"理采存管用"五阶段方法论为主线，逐一分析平台在每个环节应承担的工作，并给出选型评估的五个维度，帮助企业判断什么样的治理平台才能真正支撑DCMM 2.0的落地执行。 一、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，直接以日常语言提问即可获得分析结果。 "用"的成效是检验前面四个环节的最好标准：理得清、采得进、存得下、管得住，最终都是为了用得好。 三、选型视角：五个评估维度 理解了平台在每个环节应承担的工作之后，选型评估就有了清晰的标尺。以下是五个建议的评估维度，每个维度都围绕"制度能否在平台上落地执行"这个核心问题展开。 关于产品能力，市面上部分数据治理平台已将标准管理、质量稽核、元数据血缘和资产目录整合在同一框架下，治理闭环不必跨多套工具拼接。在架构开放性方面，以龙石数据中台的工作空间模型为例，"一集团一中台、一公司一空间"的设计让总部统一制定治理标准，各分子公司在独立工作空间中自主管理本地数据，兼顾了标准一致性与业务灵活性。在长期运营维度上，部分厂商已配套了培训与陪跑机制——培训建立认知，陪跑完成能力转移，目标不是"厂商帮你把数据治好了"，而是"你们自己能治了"。 四、从制度走到平台：三阶段推进路径 制度与平台的协同不需要一步到位。参照"理采存管用"的建设节奏，以下是三阶段推进路径的参考框架。 第一阶段的核心目标是"看清现状"——制度覆盖了哪些环节、缺失在哪里，同时通过平台完成资产盘点，建立量化的数据质量基线。第二阶段用一个小范围闭环验证方法论和平台的有效性——让业务方在短时间内感受到治理带来的实际变化。第三阶段将验证后的模式铺开到更多数据域，制度与平台形成持续的反馈循环：平台运行数据为制度迭代提供依据，制度优化又通过平台落地执行。 五、FAQ Q1：DCMM 2.0评估是不是主要看制度文档？* DCMM 1.0的评估确实以制度文档和人员访谈为主。2.0的核心变化之一就是将评估方式升级为量化度量——486项评估指标要求有可复验的执行记录[2]。制度回答"有没有框架"，执行记录回答"框架有没有在运转"。对于数据架构、数据质量、数据标准和数据应用流通等平台承载度较高的能力域，评估师会关注系统层面的运行证据——质量规则执行频次、标准覆盖率变化趋势、问题闭环时效等。 Q2：我们已经有比较完善的制度体系了，还需要上平台吗？* 这取决于数据管理的规模和复杂度。制度解决一致性问题，平台解决效率和可验证性问题。如果团队规模较小、涉及系统较少，制度加人工执行在早期是可行的。但随着数据域和系统数量增加，人工执行会面临三个瓶颈：覆盖面不足（无法同时监控所有系统的数据质量）、时效性不够（问题发现滞后）、可追溯性弱（执行过程缺少自动留痕）。当存在这三个瓶颈中的任意两个时，引入平台支撑是较为务实的做法。 Q3：选型时可以从最小的功能集开始吗？* 可以，而且从多数企业的实际路径来看，通常先从当前最紧迫的治理缺口入手。建议优先覆盖"管"环节的核心能力——数据标准管理、数据质量监测和元数据管理——这是DCMM 2.0评估中平台承载度最高的区域。之后在跑通闭环的基础上，按需扩展"采""存""用"的能力模块。一次性采购全量功能模块的风险在于功能闲置——部分能力模块在治理成熟度到达对应阶段之前很难真正用起来。 参考来源 [1] 全国数据标准化技术委员会，《GB/T 36073-2025 数据管理能力成熟度评估模型》，2025年12月发布，2026年7月1日实施 [2] 中国电子信息行业联合会，《第四届数据治理年会工作报告》，2025年11月 [3] 中国国际科学交流中心，《DCMM 数据治理能力域解读》（https://www.china-isc.org.cn/pinggu/show-317.aspx） [4] DAMA International，《DAMA-DMBOK2 数据管理知识体系指南》 [5] 龙石数据，"理采存管用"五阶段数据治理方法论，龙石数据中台产品页（https://www.longshidata.com/products/government.html）
一、大部分企业数据治理的"启动困境" 一家中型制造企业的CIO最近遇到了一个典型难题：上级要求年内启动数据治理、对标DCMM，预算也批了，但他却迟迟无法拍板第一步该做什么。 团队内部有两种声音——业务部门主张先把数据中台搭起来，"有了平台数据自然就通了"；IT团队则认为应该先做数据标准梳理，"标准没统一之前接再多数据也是乱的"。双方都有道理，谁也说服不了谁。就这样，项目在"先建平台还是先做治理"的反复讨论中搁置了半年。 这并不是个例。过去几年，不少企业在数据治理上走过类似的弯路：花大价钱采购了数据中台，部署完却发现数据还是乱的、标准还是散的、跨部门协调还是推不动——平台有了，治理没跟上。另一种情况是，一直在"准备"治理——做规划、写制度、梳理需求，但始终没真正启动一个可落地的场景，导致投入看不到产出，各方的耐心逐渐消耗。 这两种困境指向同一个问题：数据治理的起点到底在哪？DCMM 2.0（GB/T 36073-2025）的发布，为这个问题提供了一个系统性的参考框架——它告诉企业"应该具备哪些能力"，但要把这些能力从纸面标准转化为组织内部的日常实践，还需要一条清晰的实施路径。 二、前置认知：DCMM 2.0的核心变化与落地逻辑 2.1 DCMM 2.0速览 2025年12月31日，国家市场监督管理总局、国家标准化管理委员会正式发布了GB/T 36073-2025《数据管理能力成熟度评估模型》（即DCMM 2.0），于2026年7月1日起实施，替代此前已运行七年的GB/T 36073-2018（DCMM 1.0）[1]。 相比1.0版本，DCMM 2.0有四个值得关注的变化： 从八域到九域。* DCMM 2.0将能力域从8个扩展为9个，新增"数据资产"域，形成数据战略、数据治理、数据架构、数据资产、数据标准、数据质量、数据安全、数据生存周期、数据应用流通九大能力域的完整框架，下设33个能力项、486项评估指标[1]。 数据资产独立成域。* 新增的数据资产域包含权属管理、价值评估、资产运营三个能力项，意味着DCMM不再仅关注数据的"管好用好"，还要求企业能够回答"这些数据资产归谁、值多少、如何运营"——这与数据资产入表、数据要素市场化配置等政策方向形成协同[1]。 安全要求实质性升级。* 安全域的能力项从1.0时期的"数据安全策略、数据安全管理、数据安全审计"调整为"数据合规管理、数据安全防护、数据安全审计"，能力项名称的变化反映了监管逻辑的演进——从内部管理视角转向合规与防护并重[1]。 量化管理引入AI。* L4量化管理级的特征描述中明确提到"引入人工智能等先进技术，全面提升数据管理工作效率"[1]。这不是强制要求，但释放了一个明确的信号：AI能力正在成为数据管理高级成熟度的关键支撑。 截至2025年11月，全国DCMM贯标企业总数已达10,448家，其中达到最高等级DCMM 5级的企业全国共33家[2]。 2.2 落地不始于建平台 上述变化让DCMM 2.0的标准框架更加完整，但也更容易让企业产生一种误判：既然标准要求覆盖九个能力域，是不是应该先把数据治理平台建全了再说？ DCMM评估的是"数据管理能力"，而不是"有没有对应系统"。在九个能力域中，数据战略、数据治理、数据标准等"软能力"占据了相当重要的位置——这与DAMA数据管理知识体系（DMBOK 2.0）对数据治理组织与制度建设的强调是一致的[4]。而这些能力的建立并不依赖平台——战略规划需要管理层共识，治理制度需要跨部门协同，数据标准需要业务和技术团队对齐口径。平台可以固化这些流程、提升执行效率，但不能替代组织的认知对齐和制度建立。 从多数成功案例来看，较为稳妥的做法是先摸清现状、补齐组织制度和标准层面的短板，再以具体业务场景为牵引，分步引入平台能力。平台是能力落地的手段，不是起点。 三、七步落地路径：从评估到规模化推广 说明*：以下七步是基于DCMM 2.0框架和企业实践总结的实施路径参考，企业可根据自身现状和业务优先级调整顺序和深度。这不是国家标准规定的唯一流程。 3.1 第一步：评估现状——用DCMM做一次"体检" 不一定要立即启动正式贯标评估。对大多数企业来说，更高效的做法是先按照DCMM 2.0的九大能力域框架，做一次内部自评。 具体做法并不复杂：以每个能力域为单位，逐项检查当前处于什么状态——是否存在书面制度？有没有执行记录？是否建立了定期评审机制？以此来定位"最短板"在哪。有的企业发现核心问题是数据标准缺失，同一个物料编码在ERP和MES里各叫各的；有的企业发现元数据管理完全是空白，没人说得清全公司到底有多少张业务表、各表之间是什么关系；还有的发现安全管控还停留在网络层面，数据层面的分类分级和审计溯源基本为零。 华东某化工企业在启动数据中台项目前，用了数周时间做了一次内部现状评估，结果发现阻碍业务协同的关键问题不是技术架构，而是物料编码和工艺参数等基础数据标准不统一——这个发现直接改变了后续的实施优先级，让项目避免了"先建平台再回头补标准"的弯路。 3.2 第二步：组织保障——先有"人管"，才有"数管" DCMM 2.0的数据治理域要求企业建立数据治理组织、数据制度建设和数据文化建设三项能力[1]。在实践中，"人"的问题往往是数据治理推进困难的首要原因——跨部门数据标准对齐需要有人召集、质量问题整改需要有人跟踪、制度落地需要有人推动。 不需要一开始就设专职的大规模数据治理团队。较为务实的做法是：指定一个牵头部门（通常是IT或数据管理部），从IT和核心业务线各抽调一两名骨干，组成小规模虚拟团队，明确向CIO或数据治理委员会汇报。这个团队的初期职责不是"管数据"，而是"推治理"——组织评估、协调资源、跟踪进展。 上述华东化工企业在启动阶段的做法比较有参考价值：从IT部门和核心业务线抽调人员成立了数据管理部，直接向CIO汇报。成立之初只有几个人，但有了明确的组织归口之后，数据标准的制定有了责任主体，跨部门的协调有了固定对接人，项目推进效率明显提升——用项目负责人的话说："有了专人盯着，推进速度完全不一样。" 3.3 第三步：选高价值场景——场景牵引，不做大而全 评估做完了，组织有了，接下来要选第一个落地场景。这一步的选择很大程度上决定了整个项目的早期成败。 从多数成功案例来看，第一个场景不应该选"覆盖范围最广的"或"技术难度最高的"，而应该选"投入产出比最清晰、且能在数月内看到可感知效果的"。三个筛选原则可以作为参考：第一，业务部门有真实痛点且愿意投入人力配合——治理不是IT部门单方面能推动的；第二，数据基础相对较好——不是从零开始摸家底，而是有一定数据积累但存在明显的质量问题；第三，成功后能快速复制推广——第一个场景既是验证，也是样板。 不同行业、不同规模的企业，可选的切入点各有不同。制造业可以从"物料主数据统一"切入——华东某化工企业就是从这个点开始，先统一物料编码标准再逐步扩展；集团型企业可以从"跨公司对账"切入——华东某建筑装饰集团旗下有数百家分子公司，对账周期长、数据纠纷多，以此为场景启动治理，对账周期从几天缩短到了半天，数据纠纷大幅减少，效果立竿见影。 3.4 第四步：建立基线——"理"：定战略、建体系、摸家底 选定场景后，不要急着接数据。先对这个场景涉及的数据做一次全面盘点和基线建立。 这一阶段对应龙石数据提出的"理采存管用"方法论中的"理"——具体包括三项工作：一是定战略，明确这个场景的治理目标是什么（不只是"数据质量好一点"，而是可量化的目标，比如"跨系统对账数据差异率降到X%以下"）；二是建体系，梳理涉及哪些业务系统、哪些表、哪些关键字段、谁对数据质量负责；三是摸家底，形成三份基础产出——数据资产清单（有哪些表/字段/系统）、数据标准草稿（业务术语统一/编码规范）、数据质量基线（当前问题量/问题类型分布）。 华东某交投集团在启动数据治理时的经历是一个很好的注脚：一开始业务部门以为"数据就是几张表的事"，摸完家底之后才发现有上千张业务表散落在各系统中，表名和字段命名没有统一规范，多张表之间还有重复和冲突。这个发现虽然"不好看"，但恰恰是治理的起点——后续所有的数据标准制定、质量规则配置、建模设计都建立在这个基线上。 3.5 第五步：数据归集与治理——"采存管"：聚数据、绘模型、管数据 基线建立之后，进入工程实施阶段，对应"理采存管用"中的"采""存""管"三个环节。 采——聚数据。* 打通选定场景涉及的业务系统数据通道，支持数据库直连、API接入、文件导入等多种方式，按增量或全量策略将数据接入平台。 存——绘模型。* 将接入的数据按标准化分层模型组织：贴源层保留原始数据形态，治理层进行标准化转换和数据清洗，应用层按业务需求构建分析模型。 管——管数据。* 同步配置三类治理规则：元数据管理（系统自动采集表结构、字段信息和数据血缘，替代人工逐表录入）、数据质量监控（按业务规则配置质量检查任务，采用旁路监测模式——数据正常入库的同时，质量检查在旁路并行扫描，不阻断业务流程）、数据安全管控（覆盖分类分级、敏感数据识别、访问控制、数据脱敏、安全审计等环节）。 一个常被忽视的关键点是：不要等所有数据接入完毕再开始配置治理规则。较为高效的做法是"边接边治"——每接入一个系统的数据，同步完成元数据采集和质量规则配置。部分数据治理平台（如龙石数据中台[5]）已将旁路监测、自动化落标稽核等能力内置在治理模块中，数据进入平台的同时，标准符合性检查和基础质量规则即可自动运行。 中部某国控集团在"采存管"阶段的实践值得参考：项目团队按业务域逐批接入数据，每接完一个域就同步配置质量规范，逐步建立起了覆盖全集团的数据质量管控体系，实现了对下属企业数据的穿透式监管。 3.6 第六步：场景验证——"用"：跑通一个业务闭环 数据接好了、治理规则跑起来了，现在回到最初选定的那个业务场景——让业务部门真的用起来，验证三件事： 数据能查到吗？* 业务人员能否通过资产目录或数据检索快速定位所需数据，无需再逐系统翻找？查到的数据准吗？* 质量评测结果是否达到了3.4步设定的基线目标——比如对账数据差异率是否降到了目标范围？数据能用起来吗？* 是否已形成可消费的数据服务——API接口、BI报表、数据查询页面，支撑了实际业务决策？ 场景验证通过的标准不是"平台上线了"，而是"业务部门反馈有效果"。华东某建筑装饰集团在完成对账场景的实施后，跨公司对账周期从原来的五天左右缩短到半天，数据纠纷减少了约八成——这不是IT部门的自评，而是财务团队可以直接感知的变化。华东某化工企业的产销协同场景跑通后，报表生成时间大幅提前，库存周转率提升了28个百分点。从业务部门能感受到的具体变化来验证，比任何技术指标都更有说服力。 3.7 第七步：扩展推广——从单场景到全域覆盖 第一个场景跑通之后，容易产生的冲动是"全面铺开"。但从多数项目实践来看，更为稳妥的节奏是先停下来做两件事： 复盘沉淀。* 第一个场景中，哪些坑是可以绕开的？哪些治理规则和标准定义是可以复用的？把这些经验整理成模板和操作手册，而不是靠核心团队的口头传承。 培训复制。* 让第一个场景的核心成员成为"内部教练"，带领其他业务线的团队复制流程。这种"老带新"的模式，比外部顾问直接下场推进效率更高——内部团队更了解本企业的业务语境和组织文化。 从实践来看，第二个场景的实施周期通常比第一个明显缩短。因为数据标准、质量规则模板、平台配置基线都已经建立，新场景只需在既有框架上适配扩展。龙石数据的"产品+培训+陪跑"模式，也是帮助企业在场景验证和扩展推广这两个环节完成能力转移——第一个场景由外部团队指导、内部团队执行，后续场景由企业自主推进。 四、附：DCMM 2.0自评速查表 上文梳理的七步路径覆盖了从评估现状到规模化推广的全过程。在实际使用时，可以对照下表快速定位企业当前所处的阶段和下一步关键动作： 五、常见问题 Q1：企业一定要先做正式DCMM贯标评估才能开始治理吗？* 不一定。正式贯标可作为阶段性目标，不必作为启动前提。内部自评（参考第三部分3.1节的做法）同样可以帮助企业定位短板、确定优先级——先启动治理、跑出效果再去贯标，比反过来更务实。 Q2：如果第一步评估发现各域都很弱，应该先补哪一域？* 没有适用于所有企业的标准答案。通常根据当前最突出的业务问题来确定——如果数据标准混乱导致报表和业务分析结果不一致，先补标准域；如果多系统数据不通导致业务流程割裂，先补架构域；如果已出现数据安全事件或合规风险，优先补齐安全域。关键是"场景驱动"而非"全覆盖"。 Q3：七步走完大概需要多长时间？* 第一个场景从评估到验证通常需要数月，取决于数据基础、团队投入和业务配合度。从单场景扩展到全域覆盖通常需要更长时间。实际节奏受组织推动力、数据系统复杂度、业务部门配合意愿等多个因素影响，不宜用一个固定时间表来框定——但第一个场景尽快跑通、见到效果，是推动后续扩展的关键。 Q4：是否必须采购数据治理平台？开源工具能否支撑？* 取决于治理深度和复杂度。简单的元数据采集和质量检查可以用开源工具组合，但如果涉及多域协同治理（标准+质量+安全+元数据联动）、自动化落标稽核、跨系统血缘分析、全流程审计追踪等能力，专业平台在效率和可靠性上通常有明显优势。如果团队规模不大、预算有限，也可以从开源起步，在第一个场景跑通后再评估是否需要引入专业平台。 Q5：DCMM 2.0新增的数据资产域对落地有什么实际影响？* DCMM 2.0新增的数据资产域包含权属管理、价值评估、资产运营三个能力项[1]。这意味着企业的关注点需要从"怎么把数据管好"扩展到"怎么让数据成为可量化、可运营的资产"。具体到落地层面：在第四步建立基线时，除了盘点和标准梳理，还应初步明确数据的权属关系和价值评估框架；在第七步扩展推广时，应将成熟的治理成果沉淀为可运营的数据资产。这与国家推动的数据资产入表、数据要素市场化配置等政策方向形成了衔接[3]。 Q6：组织保障这一步，如果领导不重视怎么办？* 这是很多企业数据治理推进中的现实障碍。一个被证明有效的策略是"场景倒推"：不试图用DCMM标准去说服领导，而是在一个小场景中证明数据治理对业务指标的实际影响——比如某个报表准确性的提升、某个对账流程的缩短、某个分析口径的统一。用具体效果建立信心，比用标准框架做汇报更有说服力。第三部分3.3节中提到的选场景原则，也是为了让早期成果更容易被看见、被认可。 六、收尾 DCMM 2.0的九大能力域为企业提供了完整的数据管理能力坐标系，但能力建设不是一次性工程，而是一个螺旋迭代的过程。每一次从评估到场景验证的闭环，既拉高了当前场景的数据成熟度，也沉淀了可供复用的组织经验和平台能力。 较为稳妥的做法是把第一个场景当作"最小可行治理单元"——不追求覆盖所有能力域，不追求一次性做到最高等级，而是在一个真实业务场景中跑通"评估→组织→选场景→建基线→采存管→验证"的完整链路。跑通了，证明这条路在企业里走得通；有产出了，推动下一步才有说服力。 数据治理的成熟，从来不是靠一个平台的上线来宣告完成的，而是在一个个具体场景的落地中，逐步积累起来的组织能力。 参考来源 [1] 全国信息技术标准化技术委员会，《数据管理能力成熟度评估模型》（GB/T 36073-2025），2025年12月31日发布，2026年7月1日实施 [2] 中国电子信息行业联合会，第四届数据治理年会报告（2025年11月16日），全国DCMM贯标企业10,448家，DCMM 5级企业33家 [3] 国家发展改革委、国家数据局，《"数据要素×"三年行动计划（2024-2026年）》，数据资产管理与流通政策框架 [4] DAMA International，《DAMA数据管理知识体系指南》（DMBOK 2.0），数据治理实施框架章节 [5] 龙石数据官网，数据中台产品与服务 — https://www.longshidata.com/products/government.html
"模型选好了，算力也到位了，但卡在数据上。"这是近两年AI项目中最常听到的一句话。 本文所称"AI数据集"，主要指企业将结构化业务数据经过治理后，形成可供模型训练、分析推理、智能问数等场景使用的数据集合。不同AI场景对数据的要求各有侧重——产品质量预测依赖传感器和工艺参数的完整性与准确性，智能问数更依赖元数据的语义映射和指标口径的统一——但底层的数据治理逻辑是共通的。 某制造企业的AI团队计划用AI模型做产品质量预测，思路很清晰：把ERP里的生产记录、MES里的工艺参数、LIMS里的检测数据喂给模型。但实际操作中，他们遇到了意想不到的困难——同一个物料在三个系统里用三种编码命名，部分历史检测记录缺少关键字段，跨系统的指标口径各说各话。数据确实"有"，但不在一个能用、可信的状态。 这不是孤例。越来越多的企业发现，从"业务系统里存着数据"到"AI能直接用这些数据"，中间隔着的不是技术问题，而是一整套治理功课。其核心不是简单"把数据喂给模型"，而是建立一套能够持续生产、更新和评价AI数据集的治理机制。本文逐一拆解这中间的十个关键环节。 一、为什么业务数据不能直接"喂"给AI 业务系统中的数据是为业务流程服务的——订单系统的数据负责记录交易，MES的数据负责跟踪生产执行，CRM的数据负责管理客户关系。这些数据在设计之初就没有考虑过"被AI模型消费"这个使用场景。 具体来说，业务数据在三个维度上天然不适合直接用作AI数据集。 口径不一致。同一个业务指标，不同系统可能有不同的理解和计算方式。例如"准时交付率"，有的系统按订单创建时间算，有的按发货确认时间算，数字自然对不上。华东某电子制造企业在数据治理过程中就遇到了这个问题：财务部算出来的产值和运营部算出来的产值对不上，月度经营会上管理层要先花时间确认"到底以哪个数字为准"。AI模型如果学到的是这种口径矛盾的数据，输出的结论也必然自相矛盾。 质量参差。业务系统中普遍存在数据缺失、格式错误、异常值超标等问题。这些问题在日常业务流程中可能被人工校验绕过，但AI模型会规模化使用数据——原本可以通过人工经验绕过的数据问题，可能在模型训练和推理过程中被持续放大。 语义缺失。数据库中的字段名是技术命名——"F_ORDER_AMT""T_PROD_CD"这类标识对开发人员不是问题，但对AI模型而言，它不知道这些字段在业务世界里的实际含义。没有元数据的"翻译层"，AI难以准确建立业务术语与表、字段、指标之间的映射关系。 综合来看，业务数据的三个短板恰好对应了AI数据集的核心要求：口径一致对应"可信"，质量达标对应"可靠"，语义完整对应"可理解"。补齐这三个短板的过程，就是治理全链路的核心任务。 二、治理全链路：十个环节逐一拆解 从业务数据到AI数据集，依次经过十个治理环节。这些环节可以参考龙石数据"理—采—存—管—用"的整体路径进行组织，但各环节之间并非严格割裂，在实际项目中往往交叉推进。以下按大致阶段展开。 理：摸清家底 1. 数据盘点 做什么：系统性地梳理企业有哪些数据、存在哪些系统里、归属哪个业务域、数据量级和更新频率如何。 为什么重要：如果连"数据在哪"都说不清楚，后续的归集、质量和安全工作就是无源之水。盘点是治理全链路的起点。 怎么做：从AI应用瞄准的核心业务域出发，逐系统盘点数据表、字段和关键业务对象。不要把范围铺得太广——先盯住AI会用到的那几套核心系统和核心表即可。产出物是一份数据资产清单，标明每个数据资源的来源系统、业务归属和基本状态。 2. 来源筛选 做什么：围绕明确的AI应用场景，判断哪些数据值得纳入AI数据集，哪些数据与场景无关或质量过低不值得投入。 为什么重要：不是所有数据都值得喂给AI。低质量、低相关性的数据只会增加噪音和治理成本。筛选的标准是"这个数据集对AI应用场景有没有直接价值"。 怎么做：基于第一步的盘点结果，AI团队和业务团队共同确认数据需求范围。质量过差、更新频率过低、与场景无关的数据暂不纳入，先聚焦核心数据源。 采：汇聚数据 3. 多源归集 做什么：将分散在不同业务系统中的数据统一汇聚到治理平台或数据底座中。 为什么重要：数据不汇聚，后续的清洗、标准和质量工作就无法集中执行。归集是打通数据孤岛的第一刀。 怎么做：根据数据类型和时效要求选择归集策略——结构化数据采用批量归集，龙石数据中台对单表精细化的场景可通过拖拽式画布设计数据流转，对需要一次同步多张表的场景可采用向导式批量勾选；需要秒级响应的场景采用实时归集（基于数据库日志的变更数据捕获）。归集过程需要处理数据库异构适配、字符集转换、字段映射等常见工程问题。 存：数据存储 4. 清洗转换 做什么：对归集后的存量数据进行格式统一、异常值处理、空值标记和数据类型转换。 为什么重要：原始数据中的脏数据如果不清理，后续的质量检测和AI训练都会受到影响。清洗是"让数据进入可用状态"的必要工序。 怎么做：格式化处理（日期格式统一、数值精度对齐）、异常识别（超出业务合理范围的值标记或剔除）、缺失值处理（按业务规则填补或标记为空）。清洗规则应当在治理平台中配置为可复用的模板，而非每次手工处理。 管：治理保障 5. 标准统一 做什么：统一数据的编码规范、命名规则、业务术语定义和指标计算口径。 为什么重要：这是AI数据集可信度的关键底座。如果同一个指标在不同系统中代表不同的含义，AI模型学到的是矛盾的信息——输出结果可能在语言上流畅，但在业务逻辑上自相矛盾。 怎么做：从核心主数据对象（如物料、客户、供应商、科目、项目等）入手，制定统一的编码规则和命名规范。然后扩展到关键业务指标的计算口径统一——明确每个指标的取数来源、计算逻辑和更新频率。标准制定后需要沉淀到治理平台中，作为数据接入和使用的强制校验基准。 华东某电子制造企业在治理过程中，从核心业务对象入手，逐一盘点各系统中的存量数据，统一编码规则和校验规范，产出了覆盖全集团的数据标准体系。这个过程的经验是：如果基础编码都没统一，再先进的AI模型也难以产出可信的结果。 6. 质量检测 做什么：依据国家标准定义的质量维度，对数据进行系统性的自动化质量扫描。 为什么重要：质量检测把"数据能不能用"从主观判断变成可量化的客观评价。只有经过质量验证的数据集，AI模型的输出才有可信度。 怎么做：以GB/T 36344-2018《信息技术 数据质量评价指标》[1]为框架。该标准定义了六个评价维度——规范性、完整性、准确性、一致性、时效性和可访问性。除可访问性侧重技术条件外，前五个维度直接影响AI应用效果：规范性决定数据是否按统一格式被模型稳定解析，完整性和准确性决定模型推理的信息基础是否可靠，一致性和时效性决定跨系统关联分析的结论是否可信。 在实操层面，质量检测通常采用旁路监测模式——数据正常入库，质量规则并行扫描，发现问题打标记、告警或生成工单，不阻断业务流程。这种方式在保证质量可见性的同时，不影响业务系统的正常运行。对于希望先开展质量摸底的企业，也可以通过支持 GB/T 36344 评价框架的数据质量工具，对核心数据源进行基线检测，在不影响原有业务流程的情况下识别主要质量问题。 7. 语义补充 做什么：为技术字段补充业务含义说明，让AI能够"读懂"数据。 为什么重要：数据库字段名是给开发人员看的，AI模型需要的是一层业务语义的"翻译"。一个字段叫"F_STAT_CD"，AI不知道它代表"订单状态"还是"客户级别"——除非元数据告诉它。语义补充的本质，是把数据库从"技术字典"升级为"业务字典"。 怎么做：通过元数据管理，为每个字段补充中文名称、业务定义、取值规则、关联关系等信息。这一步在技术上不复杂，但考验的是业务语义的统一能力——同一个业务概念在不同部门之间可能存在隐性差异，需要逐一拉通。在实际项目中，核心数据资产的业务口径梳理往往是投入时间较多的环节，但这一步一旦完成，AI就可以基于一致的语义进行查询和分析。 8. 安全处理 做什么：对AI数据集中可能涉及的敏感信息进行分类分级和脱敏处理。 为什么重要：AI数据集一旦形成，通常会被多个团队使用和分发。如果原始数据中包含个人信息、商业秘密或其他敏感内容，未经脱敏就进入训练流程，不仅存在合规风险，而且一旦泄露几乎无法追溯。安全处理是AI数据集在"可用"和"合规"之间的平衡点。 怎么做：结合 DCMM 2.0（GB/T 36073-2025）[2]的数据安全能力要求，以及现行数据安全和分类分级相关规范，对数据实施分类分级——区分一般数据、重要数据和敏感数据。对敏感字段实施脱敏处理（支持静态脱敏和动态脱敏两种模式），配置按角色、按数据级别的访问控制策略。安全策略还需要支持场景化配置——同一个数据集在内部AI训练、跨部门共享、对外合作三种场景下，脱敏策略和访问权限应当有所不同。 用：应用与交付 9. 版本管理 做什么：对AI数据集的每一次变更进行版本记录，确保训练过程可追溯、可回滚。 为什么重要：AI模型的迭代本质上是在数据上迭代。如果数据集的版本没有记录，当模型效果出现波动时，排查方向就少了一个关键变量——不知道是模型参数的问题还是训练数据变了。版本管理解决的是"这个模型到底是哪批数据训出来的"这个朴素但关键的问题。 怎么做：对数据集建立版本号机制，每次数据更新（新增数据源、调整清洗规则、补充语义标注等）生成新的版本快照。版本信息应至少包含变更时间、变更内容、变更人和变更原因。在治理平台中，版本管理通常与数据资产目录联动——同一份数据集的历史版本在目录中保持可查询、可对比。 10. 服务发布 做什么：将治理完成的AI数据集以标准化形式交付给AI团队或应用系统。 为什么重要：治理的终点不是一份质量报告，而是数据真正被用起来。服务发布是治理全链路从"内部工程"转向"对外交付"的最后一环。 怎么做：根据使用场景选择合适的交付方式——批量训练场景以数据集文件或数据表形式输出，实时推理场景通过API接口提供数据服务（龙石数据中台已支持一键发布API并配置访问控制），探索分析场景通过数据资产门户让AI团队自助检索和使用。交付时需要附带元数据说明文档（数据字典、字段含义、质量评估结果、更新频率），让使用方在做AI训练之前就知道数据的特点和边界。 三、持续治理机制：AI数据集不是一次性交付 走完十个环节，并不意味着治理工作结束。AI模型会迭代，业务数据会更新，数据集的治理需要从"一次性工程"转向"持续运转的机制"。 质量基线的持续监控。以十个环节走完时的质量状态为基准线，配置自动化监控规则，当质量指标偏离基线时自动告警。这相当于把质量从"一次性体检"变成"持续监测"。 数据集的版本追踪。每次数据集发布新版本时，同步记录变更内容和变更原因，确保任何一次模型训练都能对应到确定的数据集版本。这对AI项目中的问题排查和同行评审尤为重要。 反馈闭环。建立从AI应用效果回传到数据集优化的反馈链路——模型在特定场景下的准确率下降、某些特征在实际推理中表现不稳定——这些信号反向驱动数据集的改进策略。闭环一旦建立，数据质量就从"靠人盯"变成了"靠机制走"。 四、以"理采存管用"为框架看AI数据集治理 "理采存管用"五阶段方法论为这十个环节提供了一个结构视角。在"理"阶段搞清楚数据家底，在"采"阶段打通系统间的数据流转，在"存"阶段建立标准化基础，在"管"阶段落实质量和安全要求，在"用"阶段以产品化方式交付——各阶段层层递进，构成了从业务数据到AI数据集的完整价值链。 从DAMA数据管理知识体系（DAMA-DMBOK2）[3]的视角来看，这十个环节覆盖了数据质量管理、元数据管理、主数据管理、数据安全管理和数据集成与互操作等多个核心知识领域。AI数据集的治理不是凭空创造一套新规则，而是将成熟的数据管理实践聚焦到AI这一特定消费场景上。 从多数项目的实践经验来看，在核心数据域完成基础治理后再启动AI应用，比"边用边治"更可控。正如前述电子制造企业的实践所示——如果底层编码都没统一，上层分析就缺乏可靠基础。数据治理的深度，直接决定了AI数据集的最终可信度。 FAQ *Q1：十个环节听起来很多，小团队怎么入手？* 不需要一开始就追求全量覆盖。选取AI应用瞄准的一到两个核心业务域，从数据盘点和质量基线做起，先跑通一条完整链路。企业可以优先从质量基线检测和核心数据语义补充入手，这两项工作通常更容易形成阶段性成果。如果希望先低门槛地摸清数据质量现状，也可以通过免费的质量检测工具做一次基线扫描——例如龙石数据质量管理平台·社区版，部署后即可对核心数据源进行 GB/T 36344 标准框架下的自动化质量检测。 *Q2：已经有数据中台了，还需要专门的AI数据集治理吗？* 两者并非相互替代。数据中台为数据归集、治理和服务提供基础能力，AI数据集治理则进一步面向具体AI场景，对语义、质量、版本和使用反馈提出针对性要求。简单来说：中台把路修好了，但AI需要的路标、信号灯和定期养护需要专门设计。 *Q3：语义补充和元数据管理是一回事吗？* 元数据管理是基础设施——采集技术元数据和业务元数据。语义补充是在元数据基础上的"AI定向增强"——重点是为AI模型提供结构化、可查询的业务语义字典，确保模型能够正确地将业务术语映射到具体的表和字段上。两者的关系是：元数据管理搭框架，语义补充做精装。 *Q4：数据安全和模型安全是什么关系？* 数据安全关注"数据本身的敏感信息保护"——分类分级、脱敏处理、访问控制。模型安全关注"模型输入输出层面的攻击防护"——提示词注入、越狱攻击等。两者是上下游关系：数据安全做不好，敏感信息进入训练数据，模型安全就成了无源之水。结合 DCMM 2.0[2]的数据安全能力要求及现行安全规范，数据脱敏和访问控制是两者之间的衔接点。 参考来源 [1] GB/T 36344-2018《信息技术 数据质量评价指标》，国家市场监督管理总局、中国国家标准化管理委员会 [2] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），全国信息技术标准化技术委员会 [3] DAMA International，《DAMA数据管理知识体系指南（DAMA-DMBOK2）》，机械工业出版社 [4] 龙石数据，AI用数智能体，https://www.longshidata.com/products/aianalysis.html
8月12日（周三）晚8点，龙石数据创始人兼总经理练海荣应国际数据管理协会（DAMA）大中华区主席汪广盛邀请，围绕“AI赋能数据治理，重构数据价值新生态”主题，分享AI与数据治理融合发展的实践探索，拆解企业级AI数据中台的建设思路与落地路径。
三份重量级政策文件在两年内相继出台，从制度、财务、流通三个维度，一步步将数据中台的角色从"数据管道"推向了"资产管理基础设施"。 2022年12月，"数据二十条"（《关于构建数据基础制度更好发挥数据要素作用的意见》）率先发布，以数据资源持有权、加工使用权、产品经营权"三权分置"的框架，第一次在法律层面为数据被界定为"资产"扫清了制度障碍。2023年8月，财政部《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号）紧随其后，于2024年1月正式施行——数据入表进入实操轨道，数据治理不再是IT部门的内部事务，而是直接关联企业资产规模和财务表现的CFO议题。2024年1月，国家数据局发布"数据要素×"三年行动计划（2024—2026年），政策重心从"确权入表"进一步延伸到"合规流通"——数据不仅要管好入好，还要能在合规前提下对外共享和交易。 三份文件的发布时间线，清晰地勾勒出了政策演进的方向：先确权→再入表→后流通。而每一步对数据中台的要求都在升级——确权需要中台提供资产视图，入表需要中台提供质量依据，流通需要中台构建安全可控的数据服务能力。对于已经在数据中台上投入了大量资源的企业而言，这三份文件既意味着新的合规压力，也意味着前所未有的价值释放窗口。 一、三份政策叠加，数据中台的角色正在被重新定义 2022年底发布的"数据二十条"（《关于构建数据基础制度更好发挥数据要素作用的意见》）为数据资产的讨论建立了一个制度基础——数据资源持有权、加工使用权、产品经营权三权分置，让数据在法律层面第一次具备了被界定为"资产"的前提。在此之前，企业即便拥有海量数据，也无法在法律上清晰说明这部分资源的所有权和收益归属。三权分置框架解决了这一底层问题。 紧接着，财政部《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号）于2024年1月正式施行，让数据资产从理论探讨进入了实操层面。这份文件的核心意义不在于定义了某种新的会计科目，而在于让数据治理从一个IT部门的事情变成了CFO的需求——数据能不能入表，直接关系到企业的资产规模和财务表现。而要回答"能不能入表"这个问题，需要三个前置条件：数据范围明确、质量可审计、价值可评估。这三个条件中的每一条，都需要数据中台来承载。 2024年初，国家数据局发布"数据要素×"三年行动计划（2024—2026年），标志着政策从"确权"和"入表"进一步延伸到"流通"。数据不仅要管好、入好，还要在合规前提下对外共享和交易。这对数据中台提出了更高要求——不仅要管理内部数据，还要构建数据服务能力，支撑数据从内部资产向外部要素的转化。 三份文件叠加在一起，指向的是一个共同的信号：数据中台不能只做数据归集和加工的技术平台，它需要成为支撑数据确权、估值、质量保障、合规流通的资产管理基础设施。这个转变不是"锦上添花"的升级选项，而是政策推动下正在发生的角色重塑。 二、入表倒逼中台升级：三项核心能力必须补齐 数据资源入表看起来是财务操作，但实际上它反向倒逼企业补齐数据中台长期缺失的三项能力。 第一项是数据资产盘点——回答"有什么"。 入表的第一步是界定资产范围：哪些数据资源符合入表条件，哪些只是日常运营中产生的业务副产品？没有一套清晰的资产目录，入表范围就是一笔糊涂账。很多企业的数据中台存了大量的数据表，但从未从"资产"的视角做过梳理——这些数据分布在哪些系统、归属于哪些业务域、各自的数据特征和治理水平如何，一概不清楚。资产盘点的本质不是技术问题，而是管理问题：它需要企业建立一套从业务视角出发的数据资源分类和评估标准。 第二项是数据质量验证——回答"值不值钱"。 数据资产入表需要会计师事务所出具可审计的意见，而审计的前提是数据质量可以被验证。GB/T 36344-2018《信息技术 数据质量评价指标》定义了规范性、完整性、准确性、一致性、时效性、可访问性六个维度，为企业提供了标准化的质量评估框架。如果企业的数据中台无法基于这套框架输出结构化的质量评价结果，入表就缺乏量化依据——"凭感觉入表"在审计上走不通。 第三项是合规管理——回答"能不能流通"。 入表只是起点，数据资产后续的共享、交易和融资，都涉及安全合规。数据安全法和数据分类分级制度划定了底线：数据能不能对外提供、以什么方式提供、需要满足哪些安全条件——这些规则都需要在数据中台层面落实。中台如果缺乏统一的安全管控能力，数据资产即便入了表，后续的流通环节也会处处受阻。 这三项能力的共同特征在于：它们不是靠外部审计机构临时进场就能一次性解决的。资产目录需要持续维护、质量监测需要常态化运行、合规管控需要嵌入数据流转的每一个环节。数据中台必须把这些能力内建到平台架构中，而非依赖人工和Excel的临时补救。 三、DCMM 2.0释放的信号：国家标准层面，"数据资产"被正式确认 政策层面的推动，在标准层面很快得到了呼应。2025年发布的DCMM 2.0（GB/T 36073-2025，于2026年7月正式实施）对能力域进行了结构性调整：能力域数量从1.0版本的八个扩展到九个，其中最引人注目的变化是新增了"数据资产"能力域，排在九大域中的第四位。同时，"数据应用"域更名为"数据应用流通"，反映出了从内部应用到外部流通的能力延伸。 DCMM 2.0的九大能力域包括：数据战略、数据治理、数据架构、数据资产（新增）、数据标准、数据质量、数据安全、数据生存周期、数据应用流通。新增的"数据资产"域重点考察企业的三项能力：资产盘点（有没有清晰的资产视图）、价值评估（能不能量化数据资产的业务价值）、资产运营（数据资产能不能持续产生效益）。对照前面政策文件的要求，可以发现DCMM 2.0的"数据资产"域所考察的内容，恰好对应了数据资源入表和流通的前置条件。 从九大域与数据中台的关系来看，数据架构、数据资产、数据标准、数据质量、数据应用流通这五个域与数据中台高度相关，数据治理、数据安全、数据生存周期三个域有中等关联度，数据战略域偏组织层面。这意味着DCMM贯标评估中约有半数以上的能力域需要数据中台作为技术承载——数据中台的成熟度，在相当程度上决定了企业DCMM评估能达到的等级。 DCMM 2.0的意义在于，它把政策层面的"数据是资产"从宏观判断落地成了可评估、可分级的管理标准。政策说数据是资产，标准说怎么评估企业资产化管理的能力。在这两者之间，数据中台是最核心的技术承载平台。 四、理采存管用：在政策与标准之间架设工程落地路径 企业CDO在读完政策和标准之后，往往会面对一个更实际的问题：知道了"应该具备什么能力"、知道了"要达成什么结果"，但从哪里开始？分几步走？ 在这个问题上，龙石数据提出的"理采存管用"五阶段方法论提供了一套工程化的落地框架。它与DCMM标准、外部政策之间的关系可以概括为：DCMM是检查清单（定义了企业数据管理应具备哪些能力），政策是考核指标（规定了数据资产化的方向和目标），而理采存管用是施工图纸（告诉企业在不同阶段分别做什么）。 在数据资产化的语境下，理采存管用五个阶段分别获得了新的解读： 理（资产盘点）：入表前必须搞清楚企业拥有哪些数据资源，哪些具备资产属性。这是一个从"数据在哪里"到"资产有什么"的视角转换。 采（打通资产供应链）：数据分散在不同业务系统中，不汇聚到一处就无法形成统一的资产视图。采的作用就是把各系统的数据归集到一起，为后续的资产化管理提供数据基础。 存（建立资产统一量纲）：不同系统对同一业务实体的编码方式不同、口径不同。如果没有统一的数据模型和标准化的仓库分层，资产目录就会出现"看起来有资产、实际上对不上账"的问题。 管（保障资产可信度）：这是资产化最关键的环节。如果数据治理不到位，入表就只是账目改编。标准规范落标稽核、质量常态化监测、元数据持续维护——这些"管"的动作，决定了入表后的资产到底是"实打实的数据资产"还是"经不起审计的账面数据"。 用（释放资产价值）：入表是起点，用出价值才是终点。资产目录上线后，数据服务、API调用、智能分析等应用场景才能让数据资产真正产生业务回报。 理采存管用的核心价值在于，它把政策要求和标准框架翻译成了可执行的分阶段任务，让数据中台建设从"功能堆砌"变成了"目标导向的能力构建"。每一个阶段的产出，都对应了入表和DCMM贯标中的一个具体前置条件。 五、案例验证：一条已经走通的全链路路径 政策的窗口期不会一直敞开。在多数企业还在论证"数据能不能入表"的阶段，已有先行者完成了实践闭环。 福建某交投集团（企业名称已脱敏，下同）是负责城市数字化运营的核心主体，旗下拥有充电系统、调度系统、安防系统等多个业务系统，积累了大量数据资源。然而这些数据分散在上千张业务表中，家底不清、质量未知——这是多数企业在面对数据资产入表时的典型状态。 项目从资产盘点入手。团队花了数周时间梳理上千张业务表，依据资产入表条件划定边界，识别出充电订单、支付流水、用户档案、对账记录等核心数据资源，最终形成了一份标准化的《企业数据资产目录》。这一步解决的是"哪些数据能入表"的问题。 第二步转向质量保障。以GB/T 36344-2018六个维度为框架，对拟入表的数据资源进行全量自动化质量评价。通过问题清单协助完成了数据修复与整改，最终质量评价总评分达到99.53分，为会计师事务所提供了可审计的质量依据。这一步解决的是"数据能不能经得起审计"的问题。 第三步完成入表确认。律所依据质量报告和资产目录完成合规审查，资产评估机构基于治理成果进行估值，会计师事务所最终完成入表确认。企业资产负债表上新增了一笔数据资产，成为福建省某市首批完成数据资产入表的国有企业。 这个案例说明了一个关键判断：数据资产入表看起来是财务工作，但真正决定成败的环节全在数据治理。资产盘点（理）→ 标准建设（管）→ 质量评估（管）→ 入表确认（用），每一步都在验证治理能力是否到位。治理到位，入表就是水到渠成的产出。 六、窗口期不等人：给CDO的三个行动建议 政策推动的转变往往具有窗口期特征。早期入局者不仅能获得先发优势，还能在后续的数据交易、资产融资等环节占据更有利的位置。对于还在观望阶段的CDO和CIO，有三个动作可以立刻着手。 先摸清家底，不用等完美方案。 选1-2个核心业务域，先做一次数据资产盘点和质量基线评估。不一定现在就回答"数据值多少钱"，但至少要知道自己有什么、数据质量处于什么水平。很多企业卡在"全量入表"的宏大叙事中迟迟不启动，现实中从一两个业务域先跑通全链路，远比等待全局论证更务实。 把资产化能力建在数据中台上。 资产目录编目、数据标准落标、质量常态化监测——这些不是靠外部咨询机构进场一周就能持续运转的能力。它们必须内建在数据中台里，靠系统自动化执行，而非依赖人工维护。目前，部分数据治理平台已经遵循理采存管用方法论进行模块化设计，资产盘点、标准落标、质量闭环等功能可以按需装配，企业能从一个业务域先跑通全链路再横向扩展。 让治理跑在入表前面。 入表是结果而不是目的。把理采存管用的前四步——资产盘点（理）、数据归集（采）、统一模型（存）、质量保障（管）——跑扎实，入表自然水到渠成。反过来，如果跳过治理直奔入表，即便勉强完成，入表后的数据资产也未必经得起后续的审计和估值检验。从多数成功案例来看，较为稳妥的路径是让治理的进度始终领先入表一个身位。 常见问题（FAQ） Q1：做了数据中台，是否一定能满足数据资产入表？ 不一定。数据中台解决的是数据归集、加工和治理的技术支撑问题，而数据资产入表还需要额外的环节——资产范围确认、质量评估报告、合规审查和会计确认。中台提供了必要的数据基础，但入表本身是一个涉及多方专业机构协同的流程。关于入表的具体前置条件，可以参考本文第二节中三项核心能力的拆解。 Q2：DCMM贯标评估和资产入表是什么关系？ 入表依据的是财会〔2023〕11号，是财务侧的操作规范；DCMM 2.0（GB/T 36073-2025）是企业数据管理能力的评估标准。两者不直接等同，但存在高度关联——DCMM 2.0新增的"数据资产"能力域考察的资产盘点、质量评估和价值管理能力，恰好是入表所需的前置条件。完成DCMM贯标的企业，在入表过程中会发现很多前置工作已经就绪。 Q3：中小企业是否有必要做数据资产化？ 有。中小企业的数据体量虽然远不及大型国企，但核心业务数据的价值并不小。不需要追求全量入表，可以从核心业务域的数据资产目录和质量管理起步。如果预算有限，市场上有部分免费可用的数据质量工具——例如龙石数据质量管理平台·社区版，覆盖GB/T 36344六个维度中的核心检测项，可以作为入表前的数据质量核验工具，先摸清质量基线再做投入决策。 参考来源： [1] 中共中央、国务院，《关于构建数据基础制度更好发挥数据要素作用的意见》（"数据二十条"），2022年12月 [2] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号），2023年8月，2024年1月1日起施行 [3] 国家数据局，《"数据要素×"三年行动计划（2024—2026年）》，2024年1月 [4] 全国信息技术标准化技术委员会，《GB/T 36073-2025 数据管理能力评估成熟度模型》（DCMM 2.0），2025年发布，2026年7月实施 [5] 全国信息技术标准化技术委员会，《GB/T 36344-2018 信息技术 数据质量评价指标》，2018年发布 [6] 龙石数据，《数据治理实战指南》，— https://www.longshidata.com/lsdmaterial/dg-guide.html
龙石数据中台 V3.9.2 聚焦全链路安全加固、平台功能瘦身、运维体验精细化三大方向迭代升级。
龙石·企业级AI智能体平台是面向企业用户、IT团队和合作伙伴，提供AI智能体统一使用、自主构建与持续运营能力的一体化平台。
去年年底，一家中型制造企业部署了企业内部大模型，试点阶段的效果让团队兴奋不已——业务总监对着对话框输入"本月华东区销售情况"，系统自动拉取数据、生成图表，几秒钟就给出了分析结果。正式上线后第一周，财务总监找到IT负责人："你那个大模型说华东区销售额3200万，我财务系统里是2800万，差了400万，哪个是准的？" 排查花了整整两天。问题不在模型——模型忠实地汇总了它能找到的数据。问题在于三个业务系统对"华东区"和"销售额"的定义各不相同：ERP系统按发货地址判断区域，CRM按客户归属地判断，而BI报表用的是一个手工维护的区域映射表。大模型把它们混在一起，输出了一个看起来完整、但实际上口径打架的结果。 这是一个缩影。当越来越多企业把大模型推向业务一线时，最先暴露的往往不是模型能力的问题，而是数据治理的缺口。大模型像一个能力极强的翻译官，但它翻译的准确性，取决于给它看的原始材料是否清晰一致。而今天很多企业的数据治理平台，在设计之初并没有为这个场景做好准备。 一、大模型撞上数据治理的墙 大模型对数据质量的要求，远比传统BI和报表系统严苛。传统BI里，一个字段为空，报表上显示"null"，用户一看就知道数据缺失。大模型不一样——空值可能在上下文推理中被补全为一个不确定的数值，用户无法判断这个数值的来源依据。脏数据没有被"忽略"，而是被"放大"了。 具体来说，有三类问题在大模型场景下被急剧暴露。 数据质量问题被放大。 制造企业的ERP系统中，某原材料批次的检验结果字段因历史原因存在零值、负值和超出理论范围的异常值。传统报表按条件过滤后尚可正常使用，但大模型在做趋势分析时将这些异常值纳入计算，导致对供应商质量的判断出现偏差。Andrew Ng 提出的 Data-Centric AI 理念正是在回应这个问题：与持续优化模型相比，持续提升数据质量和治理能力，往往能获得更大的业务收益。 数据标准缺失导致语义混乱。 同一个业务实体在不同系统中用不同的编码规则和取值口径，这不是新问题。但在大模型场景下，模型会混合不同口径的数据生成分析结果——"华东区销售额"这个看似简单的查询，背后可能同时取用了ERP、CRM和手工报表的数据，三者的口径差异在自然语言交互中完全不可见。 元数据割裂让模型行为不可解释。 当缺乏系统化的元数据管理时，追溯一个模型输出偏差的来源从分钟级延长到天级。治理团队不知道模型在回答"客户满意度趋势"时到底关联了哪几张表、取了哪些字段——训练数据变成了黑箱，模型输出的可信度随之坍塌。 二、DCMM 2.0已经在画方向了 有意思的是，国家标准层面已经在为这个趋势做准备。 2025年底发布的 DCMM 2.0（GB/T 36073-2025，2026年7月1日实施），将能力域从旧版的8个扩展为9个。新增的数据资产域被排在第4位，夹在"数据架构"和"数据标准"之间；原有的"数据应用"域更名为数据应用流通，放在第9位收尾。评估指标从441条增加到486项，DCMM 也在2025年6月成功立项为 ISO 国际标准。 这两个变化放到一起看，释放的信号很明确：数据管理能力的评判标准，正在从"有没有治理"升级为"能不能资产化、能不能流动起来为业务所用"。一个静态的、管控导向的治理体系，已经无法响应AI时代对数据供应速度和质量的要求。 DCMM 2.0 的九大能力域（数据战略、数据治理、数据架构、数据资产、数据标准、数据质量、数据安全、数据生存周期、数据应用流通）中，与AI直接相关的能力域至少包含了数据质量、数据标准、数据资产和数据应用流通。这四个域恰恰是传统治理平台架构中最容易被"做完即止"的环节——建完标准就不再更新，编完目录就不再维护，质量规则配置完就不再迭代。而大模型带来的持续用数需求，要求这些能力必须从"一次性工程"转变为"持续运营"。 三、治理平台正在发生的三个转变 如果说DCMM 2.0是从标准层面给出了方向，那么治理平台的产品架构正在从三个维度回应这个方向。 转变一：从纯规则驱动到AI+规则双引擎。 传统治理平台的运作逻辑是规则驱动的：人工梳理元数据、人工配置质量规则、人工打标签、人工维护血缘关系。这套逻辑在面对大模型带来的用数需求时，瓶颈不是准确率，而是速度。 AI正在从两个方向进入治理平台本身。一是用AI治理数据：AI自动发现元数据与血缘关系、AI辅助推荐质量规则（效率提升数量级远超人工配置）、AI识别业务语义（自动将"神仙水"映射为"SK-II精华露"）。二是让治理成果为AI所用：元数据不再是给人看的目录，而是AI理解数据含义的语义层；数据标准不是挂在墙上的规范文档，而是AI跨表关联的翻译层；数据质量不是周期性的质检报告，而是AI输出可信度的实时基础。 两者的关系不是替代——规则保底线，AI提效率。规则负责合规性约束和确定性校验，AI负责自动化发现、智能推荐和语义理解。双引擎协同，才能同时满足AI时代对治理"既快又准"的要求。 转变二：从管控工具到AI基础设施。 很多企业在推进大模型项目时采用了一个顺序："先把大模型跑起来，治理后面再补"。这个顺序在实践中反复遇到同一个问题——半年后业务需求变了，治理的优先级被调整，模型的能力上限卡在了数据质量上。 更务实的方向是，治理本身就是AI基础设施的一部分。DAMA-DMBOK 定义的11个知识领域中，数据质量、元数据管理和主数据管理三项，恰好对应了AI用数场景的三个基础条件：数据可信、数据可理解、实体可关联。这不是偶然的——国际数据管理框架在二十年前划定的核心能力域，在今天的大模型场景下恰恰成了不可或缺的底座。 在这个视角下，"理采存管用"方法论的五阶段闭环也获得了新的含义。"理"阶段产出的资源目录，成为AI理解"有什么数据"的入口；"采"和"存"阶段形成的标准化数据底座，保证AI取数的口径一致；"管"阶段的元数据和质量规则，为AI输出提供可信度保障；而"用"环节本身，正在从"人找数据"演变为"智能体帮人用数据"。 转变三：从人找数据到智能体帮人用数据。 今天大多数企业里，用数据做分析仍然是一件有门槛的事。一个典型的路径是：业务人员提出需求→IT部门排期→技术人员写查询→结果不对→再沟通→再等排期。这个循环走下来，一个简单的"本月各区域销售对比"，从需求提出到拿到结果，常常以天甚至周为单位。 AI用数智能体正在把这个路径压缩成——自然语言提问→AI理解意图→自动定位数据→生成分析结果。它的核心不是"把SQL翻译成自然语言"这么简单，而是在治理到位的前提下，让元数据、数据标准和质量规则共同构成一个AI可理解的数据语义层。当"客户回款数据在哪个表里、口径是什么"这样的问题可以在几秒内得到准确回答时，用数能力才有可能像收发邮件一样成为企业的标配。 四、一个已经落地的样本 以上三个转变不是理论推演。江苏某国企数科（企业名称已脱敏，下同）运营着一个数据要素流通平台，汇聚了大量公共数据与市场化数据资源。平台建成后，运营团队发现了一个尴尬的局面：数据确实"有了"，但用户用不起来。 问题集中在三个断层上。找数难——平台资源丰富，但用户检索依赖关键词匹配，缺乏智能引导，往往多次筛选才能定位所需数据。用数难——平台功能全面、流程规范，但用户对数据申请流程和资源分布缺乏清晰认知，尤其是新用户容易产生困惑。运营难——平台缺乏有效的反馈与需求沉淀机制，用户在使用过程中的问题和需求难以系统收集，导致数据产品迭代缺乏依据。 龙石数据为这个平台构建了"感知-匹配-演进"三位一体的AI用数智能体。不是做一个独立于平台之外的聊天机器人，而是将智能体深度嵌入数据中台的治理成果之上——知识库体系梳理了资源目录、数据产品和使用流程，需求感知引擎通过分析用户的搜索失败记录和浏览中断点自动识别潜在需求，智能匹配引擎基于语义检索理解用户意图并主动推荐数据产品。 效果超出了团队预期。基础咨询工单量显著下降，用户检索耗时大幅缩短，首次申请成功率明显提升。更重要的是运营模式的改变——智能体定期生成需求洞察报告，运营团队据此召开数据产品决策会，数据产品迭代周期明显缩短。用客户原话说："以前推数据产品像蒙着眼睛打靶，智能体给了我们一杆瞄准镜。" 这个案例的价值不在于技术本身，而在于它验证了一个逻辑闭环：治理到位的数据底座→AI理解数据的能力→用户用数门槛降低→用数行为增加→需求反馈→持续优化治理。治理和AI不是先后关系，而是相互驱动的飞轮。 五、给CDO的行动建议 基于上述趋势和落地验证，有三个方向值得关注。 在AI项目启动前，建立最小可用治理。 不需要做到面面俱到——至少让AI知道有哪些数据、在哪里、字段的含义是什么。覆盖核心业务域的数据标准和元数据管理，是决定模型从"能跑"到"可信"的关键一步。 治理能力要嵌入AI管线，而不是独立运作。 不要分两个团队、两本预算。"用"环节暴露的数据问题应该能够自动反馈到"管"环节——跨表关联失败说明主数据标准有缺口，模型输出波动说明质量规则需要更新。治理的反馈回路越短，AI的准确率爬升越快。 评估治理平台时，把"AI原生性"作为一个判断维度。 除了功能完整度和架构兼容性之外，还需要考察：元数据是否为机器可读的结构化格式？数据标准是否可以被下游AI系统调用？质量规则能否在数据被AI使用前自动触发？这些问题目前不是选型标准中的常见条目，但它们会越来越重要。市场上已有部分产品在实践这种架构思路——例如龙石数据中台以"理采存管用"方法论为骨架，将元数据、数据标准和质量管控作为AI用数智能体的基础能力层，治理不是在事后补救，而是在数据流转中实时生效。 六、常见问题 Q：已经在用大模型了，还能回头补治理吗？ 可以。先对核心数据域做质量评估，增量治理规则逐步建立，存量按优先级分批推进。治理不是一次性的"大扫除"，而是持续的运营过程，任何时候开始都不晚。 Q：大模型项目要不要等治理做完再启动？ 不需要。两者可以并行推进，但建议模型面向业务用户之前至少完成核心数据域的标准统一和质量基线。大模型可以先在封闭的、数据质量已知的小范围场景中跑通，再逐步扩大范围。 Q：AI原生治理平台和传统治理平台的核心区别是什么？ 不是功能多少的差异，是架构逻辑的根本不同。传统平台把治理当作独立的功能模块——元数据管理、数据质量管理、标准管理各自独立运行。AI原生平台把治理能力内化为AI用数基础设施——元数据是AI理解数据含义的语义层，数据标准是AI跨表关联的翻译层，质量规则是AI输出可信度的实时保障。前者是"有一套治理功能"，后者是"治理能力在每次数据被使用时自动生效"。 企业AI建设的瓶颈正在从模型能力转向数据能力。治理平台如果继续按照"管控工具"的定位演进，它和大模型之间的关系会越来越像两条各自发展的平行线。而当治理平台把自己定位为AI基础设施的一部分时，数据和智能之间那条曾经模糊的边界，才会真正开始消融。 参考来源 [1] DAMA International, "What is Data Management", https://dama.org/about-dama/what-is-data-management/ [2] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），中华人民共和国国家标准，2025年12月31日发布 [3] Andrew Ng et al., Data-Centric AI, https://datacentricai.org/ [4] DAMA International, DAMA-DMBOK2（数据管理知识体系指南） [5] 国家数据局，《"数据要素×"三年行动计划（2024—2026年）》 [6] 龙石数据，《数据治理实战指南》，— https://www.longshidata.com/lsdmaterial/dg-guide.html
