自2024年起，"数据要素×"三年行动计划在全国范围推进[1]，以"以赛促用、场景牵引"为主线，覆盖工业制造、现代农业、商贸流通、交通运输、金融服务、科技创新、文化旅游、医疗健康、应急管理、气象服务、城市治理、绿色低碳等12大行业方向。这项行动的价值标尺始终是同一个问题：具体业务场景放大了多少价值，而不是建了多大的数据平台。 对照这一标尺，会发现一个耐人寻味的反差：不少企业的数据治理平台建得完整——标准体系、质量规则、资产目录一应俱全，却很难在业务结果上找到对应的改善。治理投入在"空转"。问题出在哪里？ 一个被普遍忽视的答案是：顺序反了。多数企业先建了治理能力，再去找场景；而"数据要素×"传递的信号恰恰相反——场景定义在前，数据、标准、质量能力按需倒推。治理的起点不是数据，而是业务场景。 一、"数据要素×"在牵引什么：不看平台，看场景价值 "数据要素×"行动的逻辑，落点是业务价值：先定义场景，再明确这个场景需要什么数据，最后用效果说话。这与国家层面推动数据要素价值释放的方向一脉相承——财政部财会〔2023〕11号让企业数据资源可以计入财务报表[2]；2026年实施的国家标准GB/T 36073-2025（DCMM 2.0）新增"数据资产"能力域，下设价值评估、资产运营等能力项[4]。政策与标准都在回答同一个问题：数据怎么产生价值、怎么衡量价值。 对企业而言，这个信号同样清晰。数据治理领域常讨论"业务驱动，不技术自嗨"：不是"有什么技术就上什么"，而是"业务要什么就建什么"，先锚定业务价值，再倒推数据架构。放在治理语境下，就是先回答"要解决哪个业务问题"，再决定"需要哪些数据、立哪些标准、设哪些质量规则"。治理的投入产出，从规划那一刻就应该能算得出来。 二、治理投入"空转"的三种典型模式 先看治理的定义。DAMA-DMBOK将数据管理界定为围绕数据全生命周期开展的规划、制度、组织与流程活动，其目标是交付、控制、保护和提升数据资产的价值[3]。价值由此成为治理的出发点和检验标准。但现实中，治理投入与业务价值脱节的情况并不少见，通常表现为三种模式。 第一种是"为治而治"的大而全建设。 规划阶段按标准框架铺开——数据标准、数据质量、元数据、主数据、资产目录逐项立项，平台功能越建越全，却始终没有一个具体的业务问题作为锚点。成果不可见，治理部门在每轮预算汇报时都难以说明投入回报。一些数据治理服务商在方案中直言：治理不能"为治而治"，须从领导看板、跨部门报表等高频痛点切入，用成果换信任。这句话的潜台词是，脱离场景的治理建设，很容易沦为成本中心。 第二种是事后补救式治理。 业务部门用数据出了问题——报表对不上、口径不一致、数据缺失——才发起排查和修复。治理动作跟着故障走，修完一个再等下一个，投入分散在无休止的救急中，与场景价值的关联是断裂的。 第三种，也是被验证更有效的路径，是场景驱动的反向治理：从业务问题出发的最小可用治理。 一家中大型化工企业提供了典型样本。化工行业产销协同是公认的难题：生产是连续的、大批量的，销售是波动的、多品种的，产销不协同直接表现为库存要么积压、要么断货。这家企业的做法不是先建覆盖全业务域的数据治理体系，而是"以产销协同为突破口"，先把销售、生产、库存、物流的数据打通，再逐步扩展到采购、质量、财务等其他业务域。用企业自己的话说：不要一上来就做全业务域数据治理，选一条最痛的业务链路先跑通。结果是库存异常从"月底才发现"变为"实时预警"，车等货、货等车的情况大幅减少，销售预测与生产排产的数据基础从"各自为政"变为"共享一套数据"。 对比之下，三种模式的差别不在技术投入多少，而在起点不同：一个从体系出发，一个从故障出发，一个从业务问题出发。 三、反向倒推：从业务场景到数据能力的四步链 场景驱动的反向治理，可以落地为一条四步链：业务场景 → 关键数据 → 标准口径 → 质量基线。 第一步，选场景。 高价值场景通常有三个判别特征：直接关联经营指标——库存周转、交付及时率、对账周期、监管效率，管理层能直观感知价值；需要跨系统数据融合，单一系统内解决不了；结果可量化，改善能用数字衡量。满足这三条的，就是值得优先投入的场景。 第二步，定数据。 明确场景依赖哪些关键数据对象——物料、客户、订单、设备、工序——以及它们分布在哪些系统。这一步回答"数据从哪来、缺什么"，是后续治理动作的输入清单。 第三步，立标准。 先统一"打架最凶"的核心主数据与口径。两个部门对同一物料有两种叫法、同一指标有两套算法，是一切分析冲突的源头。标准建设不必求全，从场景涉及的核心实体入手，见效更直接。 第四步，建质量基线。 围绕场景关键字段配置质量规则并持续监测。较为稳妥的做法是采用旁路监测：数据照常入库，质量检查在旁路并行扫描，不拦截、不阻断，发现问题打标记、告警；也可以作为增强手段，在入库前先做一次质量体检。质量基线不是一次性动作，而是随业务运行持续迭代。 这套链条与数据治理的方法论框架是同构的：先"理"清场景对应的数据家底，再通过标准与质量把数据"管"起来，最终让数据在场景中"用"起来，形成价值闭环。差别只在于，入口是业务场景，而不是治理体系本身。 四、案例验证：两条已经走通的路 这条路径不是理论推演。华东某大型化工企业（国有，年产值超百亿元）在行业存量竞争与"双碳"政策双重压力下推进精细化运营，面临的正是典型场景问题：销售预测与生产排产脱节、库存积压与缺货并存。项目采用"咨询先行、治用并举"的方式，没有从平台功能清单出发，而是围绕"采购-生产-库存-销售"全链路梳理物料、产品、装置、工序、批次等核心业务对象，先统一分歧最大的物料编码与业务口径；再打通DCS、MES、LIMS、ERP等系统数据，建设工业数据湖；最后才落到产销协同驾驶舱、工序级能耗分析、业财一体全景屏等具体应用上。一年后，库存周转率提升28%，订单交付及时率提升至91%，报表出具周期提前4天。更关键的是，企业成立了数据管理部、设立数据管家岗位，把数据治理纳入绩效考核，从"项目驱动"转向"机制驱动"。企业负责人的评价是："这不是一次IT项目，而是一场管理革命。" 同一逻辑在集团场景同样成立。江苏某建筑装饰集团旗下200余家子公司、近百个在建项目部，同一装饰材料在苏州子公司叫"大理石A级"、南京子公司叫"A类石材"、总部采购系统叫"石材_01"。集团从"跨公司对账"这个具体痛点切入，倒推主数据治理——统一物料、供应商、项目部编码，实现"一物一码"——再建设多租户数据底座和穿透式经营驾驶舱。结果是跨公司对账从5天缩短至1天，数据纠纷减少80%。 场景驱动的反向治理需要工具支撑。市场上已有部分数据中台产品（如龙石数据中台）把数据标准管理、数据质量管理、主数据管理、数据资产目录作为可按需装配的模块[5]，从单个场景起步即可，不必一次上全套——这与"先跑通一条链路"的路径是匹配的。 五、给CIO和数据负责人的三个动作 把上述逻辑落到行动层面，可以对应三个动作。 用场景清单替代功能清单做治理规划。 规划治理工作时，先列业务问题，再排治理动作。每个治理项目立项时都回答一个问题：它服务哪个业务场景、改善哪个经营指标。答不上来的立项，优先级自然靠后。 建立"场景→数据需求"映射表。 把每个高价值场景对应的数据对象、涉及系统、标准缺口、质量风险列成一张表，治理投入按场景价值排序。这张表不必追求与任何标准框架严格对应，它的作用是让投入与价值的对应关系可见、可讨论。 让成果可看可感。 资产地图、质量报告、分析看板是争取持续支持的关键。数据治理不是一次性项目，而是持续运营的能力建设——认知建立、体系建设、平台建设、运营落地、组织自驱五个环节相互衔接，任何一个缺失都可能让能力建设中断。成果看得见，机制才留得住。 六、FAQ Q：治理规划应该先建平台还是先找场景？ 从多数成功案例来看，先找场景更为稳妥。第三节的反向倒推四步链就是具体做法：先明确业务问题，再按需配置数据、标准和质量能力，平台建设跟着场景走，而不是反过来。 Q：场景很多，先做哪个？ 用三个判别特征筛选：是否直接关联经营指标、是否需要跨系统数据融合、结果是否可量化。通常从最痛的一条业务链路切入——比如产销协同、跨公司对账——先跑通，再复制到其他场景。 Q：只做场景相关的治理，会不会以后扩展困难？ 不会。场景驱动的治理按需装配能力，先跑通一条链路，再横向扩展到其他业务域，标准、质量、主数据这些能力本身是复用的。数据治理是持续运营的过程，扩展是常态，不是一次性规划的结果。 Q：怎么衡量治理投入与场景价值直接关联？ 用经营指标说话——交付及时率、库存周转、对账周期、监管效率，而不是治理活动指标（建了多少标准、配了多少规则）。成果可量化，是"用成果换信任"的前提。 结语 数据要素价值释放的前提，是治理能力服务具体场景。当治理投入能直接对应到某个业务结果的改善，数据才真正从"资源"走向"价值"。 参考来源 [1] 国家数据局.《"数据要素×"三年行动计划（2024—2026年）》. [2] 财政部. 财会〔2023〕11号《企业数据资源相关会计处理暂行规定》. [3] DAMA International. DAMA-DMBOK 2.0《DAMA数据管理知识体系指南》. [4] 国家市场监督管理总局、国家标准化管理委员会. GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0）. [5] 龙石数据. 部门级数据治理与数据要素价值解决方案. https://www.longshidata.com/solution/departmentdatagov.html
"公司到底有哪些数据？分布在哪些系统？各有多少张表？"这个问题，在数据产权登记工作推进的背景下，正成为越来越多企业绕不开的考题。不少数据团队的答案并不完整：上千张业务表散落在几十个系统中，同一类数据在业务侧有三种命名，既没有统一的资产目录，也没有一份完整台账。等到登记服务机构追问细节——这批数据来自哪个系统、归哪个部门持有、加工过程有没有记录、用到了哪些场景、质量有没有第三方依据——回答往往停在半途。 登记机构受理的并不是"数据本身"，而是说得清来龙去脉的资产材料。这些材料从哪来？恰恰来自资产盘点。本文从产权登记（确权）的视角出发，讨论企业为什么要把数据资产盘点放在前面，以及盘点具体盘什么、怎么盘。 一、确权、入表、流通：政策节奏在加快，卡点却在数据家底 从政策脉络看，方向已经清晰。2022年12月，《关于构建数据基础制度更好发挥数据要素作用的意见》（"数据二十条"）提出数据资源持有权、加工使用权、产品经营权"三权分置"，从制度层面为数据资产界定权属奠定了基础[1]；随后财政部发布《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号），自2024年起施行，数据资源开始具备进入财务报表的通道[2]；"数据要素×"三年行动计划则将政策重心从确权、入表延伸到合规流通[3]。三份文件的时间线勾勒出"先确权、再入表、后流通"的推进次序。 与此同时，与数据产权、确权登记相关的制度探索在多地陆续落地推进，一些地区已开展数据产品挂牌、确权登记等实践。对多数企业来说，真正卡住进度的往往不是政策本身，而是数据家底：登记要交的材料，企业拿不出来。确权环节在加速推进，但家底不具备，确权就无从谈起——登记之前，先把数据家底备齐，这四项能力缺一不可：盘点、目录、权属界定、来源追溯。 二、登记要交的"数据家底"：五项属性一个都不能少 产权登记不是给数据贴一个"所有权"标签，而是要提交一份说得清来龙去脉的资产材料。综合各地登记实践与入表流程要求，这份材料通常要回答五个方面的问题，每一项背后都对应一项基础能力： 登记要素 要回答的问题 对应的基础能力 数据来源 数据从哪个系统、哪个业务环节产生 来源追溯（元数据采集） 责任主体 数据归谁持有、谁加工、谁运营 权属界定 加工过程 经过哪些加工转换、血缘是否清晰 血缘追溯 使用范围 用在哪里、共享给谁、边界在哪 目录与共享边界管理 质量状况 数据是否可信、有无量化依据 质量评价 五个问题环环相扣。来源说不清，无法证明数据从哪里来；归属说不清，无法确认登记主体；加工过程无记录，血缘链条断在中间；质量没有量化依据，资产可信度缺乏支撑。以责任主体为例，2026年7月1日起实施的 DCMM 2.0（GB/T 36073-2025）新增"数据资产"能力域，其中就包含权属管理、价值评估、资产运营三项能力项，从标准层面把"数据是谁的"纳入了成熟度评估[4]。 这五项属性，恰恰是资产盘点过程的产出物。数据家底就是"盘得清、查得到、说得清归属、追得到来源"，而盘点先行，是登记受理的隐含前提——登记机构受理的正是这份家底材料。 三、资产盘点不是简单建目录 不少企业把资产盘点理解为"建一个数据资产目录"，这个认知值得修正。目录只是盘点结果的呈现形式，盘点的本质是以登记、入表、流通为目标的数据摸底与属性界定。权属归属、来源血缘这些属性不会自己出现在目录里，需要通过盘点过程逐项厘清。 具体来说，三个误区比较常见： 把盘点当 IT 台账。 盘点不是统计表数量、字段数量，而是要回答"这些数据归谁、从哪来、能不能用"。 把盘点当一次性项目。 盘点结果会随业务变化而失效，需要持续更新，不是交完目录就结束。 把盘点当纯技术工作。 数据归谁持有、能否对外共享，本质是管理问题，技术工具只是手段。 盘点要回答的问题可以归纳为四类：元数据能不能自动采集、标准是否统一、质量是否可量化、目录能否编出来。这四类问题的答案，决定了登记、入表、流通是否具备共同基础——同一份盘点成果，登记时回答归属（权属），入表时回答价值，流通时回答可信。其中权属与来源追溯是难度较高、也直接决定登记成败的两项：它们不像表结构那样可以自动采集，需要业务部门、数据部门和管理层坐下来逐项确认。 四、盘点怎么盘：把"家底"盘出来的完整路径 在"理采存管用"方法论中，"理"是第一步：定战略、建体系、摸家底。放到数据资产化的语境下，"理"对应的正是资产盘点——入表前要搞清楚企业拥有哪些数据资源、哪些具备资产属性，这是一个从"数据在哪里"到"资产有什么"的视角转换。 把"摸家底"落到操作层面，可以拆成四步： 第一步，全量扫描。 借助元数据自动采集能力，系统自动抓取各业务系统的表结构、字段类型、数据量、更新频率，先回答"有什么数据、在哪里"。这是来源追溯的起点——扫描结果就是后续归属界定的底稿。 第二步，业务规则筛选。 不是所有数据都具备资产属性。用业务规则划定资产边界，剔除日志类、临时性、重复备份等非资产数据，识别出真正具备登记条件的核心数据资源。 第三步，权属与血缘厘清。 逐项确认每类数据由谁持有、谁加工、谁运营，梳理加工链与血缘关系，形成权属清单与来源追溯记录。这一步回答"数据是谁的、从哪来的"，是产权登记直接对应的部分。 第四步，形成资产目录与质量评价。 将前三步成果沉淀为《数据资产目录》，并按 GB/T 36344-2018《信息技术 数据质量评价指标》的框架开展质量评价——该标准定义了规范性、完整性、准确性、一致性、时效性、可访问性六个维度，其中前五个维度直接影响数据应用效果[5]。目录加质量报告，构成登记时可提交的"一本清账"。 盘点之后并非终点，还要接续"管"的环节：质量评价、标准统一、元数据维护，让家底持续更新。放在入表全景中看，从资产盘点、资产登记、质量评价、合规审核、价值评估到会计入表，六个环节环环相扣、成果相互印证，其中前三个环节本质上都是数据治理工作，与会计分录关系不大。 在工具层面，市场上已有部分数据中台产品（如龙石数据中台）将元数据自动采集、资产盘点与标签管理、权属维护、血缘追踪、质量评价沉淀为平台能力[6]，盘点过程可以不再依赖人工逐个系统翻阅，AI 辅助盘点也在减少人工梳理的工作量。对尚未建立这类能力的企业，从核心业务域的人工台账起步，同样可以启动家底梳理。 五、案例验证：一家国企的盘点先行实践 华东某交投集团是一家负责城市数字化运营的主体企业，汇聚了城市交通、支付、用户服务等大量数据资源。随着数据资源入表政策落地，集团希望将符合条件的自有数据集纳入企业资产负债表，但面临的挑战很典型：上千张业务表散落在多个数据库，缺乏统一资产目录，无法界定入表范围；数据从未做过系统性质量评估，会计师事务所要求的可审计质量依据拿不出来；资产盘点、合规审核、质量评价、价值评估、会计确认等多个专业领域，单一团队难以统筹。 集团的推进路径是盘点先行。先借助自动化扫描与业务规则筛选，识别充电订单、支付流水、用户档案、对账记录等核心数据资源，划定入表边界，形成《企业数据资产目录》；随后对接数据登记服务机构，完成数据产品挂牌或确权登记，获取《数据资产登记证书》；再以 GB/T 36344 为框架开展全量自动化质量评价，发现并修复订单状态不规范、时间字段偏差、支付渠道不一致等问题，最终质量评价总评分达 99.53 分（满分 100）；此后依次完成合规审核、价值评估与会计入表，成为当地首批完成数据资产入表的国有企业。 这个案例有两个细节值得注意。其一，登记和入表能走通，不是因为会计处理精妙，而是资产盘点和标准统一先走扎实了，这一步没人能代劳，也没人能跳过。其二，入表之后还有流通环节——在数据交易市场，数据产品挂牌交易通常需要第三方《数据质量评估报告》作为入场凭证，江苏某数据交易所的数据产品正是从预估 85 分修复至 99 分以上后才完成挂牌。盘点与质量评价的成果，在确权、入表、流通三个阶段都会反复用到。 六、FAQ Q1：产权登记和数据资产入表是什么关系？先做哪个？ 政策层面的次序是先确权、再入表、后流通，登记是入表的前置确权环节。从多数企业实践看，行动次序则是先盘点、再登记、入表自然接续——第二节的家底五要素和第四节的盘点路径，就是具体做法。 Q2：数据资产盘点一定要全量铺开吗？中小企业怎么启动？ 不需要。从一到两个核心业务域先跑通"盘点—目录—登记—入表"的闭环，比全量铺开更稳妥；盘点与企业规模关系不大，关键是先把家底摸清。如果缺乏工具支撑，可以关注数据中台或数据质量管理平台自带的盘点与评测能力。 Q3：资产盘点和数据治理应该先做哪个？ 从多数实践来看，盘点先行、治理跟进。还不知道自己有什么数据就开始定标准、建模型，容易做出一堆没人用的规范；先把家底盘出来，治理工作才有对象和优先级。 结语 登记、入表、流通，每一步都以清晰的数据家底为前提：盘得清、查得到、说得清归属、追得到来源。盘点不是为政策做的一次性准备，而是企业把数据当资产经营的第一项基本功。 参考来源 [1] 中共中央、国务院，《关于构建数据基础制度更好发挥数据要素作用的意见》（"数据二十条"），2022年12月。https://www.gov.cn/zhengce/2022-12/19/content_5732695.htm [2] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号），2023年8月。 [3] 国家数据局，《"数据要素×"三年行动计划（2024—2026年）》，2023年12月。 [4] 国家市场监督管理总局、国家标准化管理委员会，GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），2026年7月1日实施。 [5] 国家市场监督管理总局、国家标准化管理委员会，GB/T 36344-2018《信息技术 数据质量评价指标》。 [6] 龙石数据官网，数据中台产品页。https://www.longshidata.com/products/government.html
某制造企业的数据治理团队花了近三个月时间，梳理了核心业务系统的数据字段，配置了上百条质量校验规则。规则上线后，系统每天自动扫描出数千条告警——空值、重复、格式不规范，各种问题被逐一标记。 半年后，团队负责人复盘时发现了一个尴尬的局面：告警数量在涨，但真正被修复的问题并没有同步增加。治理团队大量时间花在了"判断哪些告警值得处理"上，业务部门觉得这些告警和实际业务问题关系不大。一位业务主管的反馈很直白："我们知道数据有问题，但你们发的那个报表我们看不懂，也不知道这些问题对我们的业务到底有什么影响。" 这个场景引出了一个数据治理领域容易被忽视的问题：配了规则就等于做好了数据质量管理吗？ 国家标准 DCMM 2.0（GB/T 36073-2025）[1] 给出了不同的视角。在其九大能力域中，数据质量域包含四个能力项：数据质量需求、数据质量检查、数据质量分析和数据质量提升。注意，"检查"只是四个环节之一。这意味着标准在意的不仅仅是"能否检测到问题"，更是"发现问题之后有没有一套持续改进的机制"。 一、当"发现问题"本身成了新的问题 在许多企业的数据治理实践中，质量管理的推进路径高度相似：选一个核心业务域 → 梳理数据资产 → 配置质检规则 → 产出问题报告。到这里为止，逻辑是通的。但问题的分岔出现在下一步——报告产出了，然后呢？ 较为常见的情况是，规则越配越多，但闭环始终没建起来。具体表现为三种典型症状： 规则数量在涨，但实际被修复的问题没有同步增加。 规则从几十条扩展到几百条，每天产出的告警从几百条升到几千条，但真正被修复、被验证、被归档的问题占比很低。治理团队在"发现"这个环节投入了大量资源，但在"解决"这个环节上缺乏对等的投入。 治理团队变成了"告警分类员"。 当告警量超过一定规模，治理团队大量时间消耗在判断哪些告警值得处理上——优先级排序、影响范围评估、与业务部门反复沟通确认。这些工作有价值，但它们本质上是在弥补"问题管理流程缺失"带来的手动成本。 业务部门对质量告警逐渐麻木。 同类告警反复出现，每次处理后过一段时间又冒出来。业务部门最初的配合意愿在一次次的"反复"中被消耗——"反正都是那些问题，修了还会再出现"。 从 DCMM 2.0 的视角审视这种状态，实质上是把"数据质量检查"从数据质量域四个环节中孤立了出来——做了检查，没做需求定义、根因分析和流程提升。行业观察显示，大量企业数据质量项目因缺乏闭环管理机制而难以达到预期效果。这个判断的指向很明确：单点检测和闭环管理之间的差距，才是数据质量能力真正的分水岭。 二、DCMM 2.0 数据质量域到底在要求什么 DCMM 2.0（GB/T 36073-2025）在第 11 章专门定义了数据质量管理能力域，包含四个能力项。这四个能力项之间的顺序关系和逻辑关联，恰恰是理解"为什么不能只做检测"的关键。 能力项 核心问题 如果缺失会怎样 数据质量需求 什么算"好数据"？质量标准在哪？ 没有统一的判断依据，每个系统各自定义，跨部门口径不一致 数据质量检查 数据是否符合既定标准？ — 数据质量分析 问题的根因是什么？影响范围多大？ 同类问题反复出现，无法从源头根治 数据质量提升 怎么防止问题复现？流程怎么改进？ 治理停留在发现-修复-再发现-再修复的循环中 DCMM 2.0 将这四个能力项放在同一个能力域中，不是偶然。它们构成了一条逻辑链：先定义标准，再检查合规性，然后分析问题根因，最后推动流程改进。 这是一条完整的质量管理链路，缺少任何一个环节，整个链条都会断裂。 从实践中观察，最容易出问题的两个断裂点分别位于"检查之后"和"分析之后"。检查之后——很多企业的质量工作到"出了报告"就停止了，缺少问题认领、责任指派和修复跟踪机制。分析之后——即使做了根因分析，也缺少将分析结论转化为流程改进动作的推力，导致同类问题在下一次业务操作中再次出现。 这可以类比为医疗场景：量体温只是诊断的起点，真正的治疗需要结合化验分析、开处方、用药、复查，以及根据疗效调整方案。量了体温但不开药，或者开了药但不复查——这个医疗过程是不完整的。 作为补充参照，GB/T 36344-2018《信息技术 数据质量评价指标》[2] 从数据本身的特性出发，定义了六个质量评价维度：规范性、完整性、准确性、一致性、时效性和可访问性。在制定数据质量需求（首个能力项）时，这个六维框架可以作为定义"好数据"标准的起点。 三、从检测到闭环：八个关键环节 DCMM 2.0 数据质量域的四个能力项提供了顶层框架，但落地到日常运营中，还需要更细颗粒度的操作步骤。从企业实践来看，较为有效的做法是将四环节展开为八个可操作的关键步骤： 标准定义 → 规则配置 → 评测 → 发现 → 认领 → 整改 → 复核 → 改进 这八个步骤环环相扣，以"改进"节点反馈到"标准定义"，形成持续优化的闭环。逐一来看每个步骤的定位： 标准定义是整个闭环的起点。它回答的是"什么是好数据"——哪个字段不能为空、哪个取值范围是合理的、哪些跨表数据需要保持一致。标准不是凭空制定的，需要基于业务规则、行业规范和监管要求来确立。行业实践中，业务规则的显式化定义也普遍被视为质量管理的首要步骤。 规则配置将标准转化为可自动执行的质检规则。这一步的关键在于让业务人员能够参与配置而非全部依赖 IT——业务部门对"什么是异常数据"有最直接的经验，但如果没有低门槛的配置工具，这个经验就无法转化为规则。 评测是运行质量扫描、生成问题报告的环节。采用旁路监测模式（数据正常入库，质量检查在旁路并行扫描）可以确保不阻断业务流程。DAMA-DMBOK2[3] 将数据质量评估分为初始评估和持续监测两类，评测环节承担的正是在不中断业务运行前提下的常态化监测职能。 发现将扫描结果提炼为可操作的问题项——不仅要标出"哪张表有异常"，还要精确到"哪个字段的哪些记录有问题"，标记字段级根因，为后续的认领和整改提供明确目标。 认领将问题推送到责任部门或责任人，明确整改期限。这一步在整个闭环中看似简单，却是最容易断裂的环节。如果问题没有明确的责任归属，前面的检测工作就全部悬空。 整改是对问题数据的实际修复。这一步经常是整个闭环中最脆弱的环节——涉及跨部门协同、业务系统操作权限和生产环境影响评估。如果整改动作长期未被跟踪和督促，闭环就是名义上的闭环。 复核在整改完成后自动复扫，确认问题确实被修复，而非被临时遮盖。这是对整改质量的验证，也是闭环"闭"起来的标志。 改进将高频问题归类，追溯系统性根因，反向优化质量规则和业务规范。例如，如果某类格式错误在三个月内出现了二十余次，不仅需要修复当前数据，还需要检查录入界面的校验逻辑是否缺失。 观察这八个步骤可以明显看到：检测（评测 + 发现）只是八步中的两步。后面的认领 → 整改 → 复核 → 改进才是质量闭环的核心价值所在。 单纯追求检测规则的覆盖率，而忽视闭环的完整性，从长期来看是投入产出比不高的做法。 市场上已有部分数据治理平台将这八个环节整合为可在线流转的闭环体系。以龙石数据质量管理平台为例，它将标准管理、规则配置、质量评测、问题分析和整改闭环串联在同一系统中——从标准到规则、从规则到扫描、从扫描到工单、从工单到复验归档，每一步都在同一平台上完成，避免了"系统A发现问题→线下沟通→系统B处理"的信息断裂。 四、以华东某电子制造企业为例 闭环的价值，在实际业务场景中看得更清楚。 华东一家中大型电子制造企业，日常运转依赖 ERP、MES、WMS 等多个业务系统。随着业务规模扩大，三个环节的数据问题逐步暴露：一是跨部门协同——同一个物料在研发、采购、仓库三个部门的系统中有不同的编码和名称，每次跨部门对账都是一场"翻译"；二是经营指标口径——财务和运营部门对"产值"的计算逻辑不同，月度经营会上管理层经常要先确认"以哪个数字为准"；三是报表周期——经营分析报表依赖人工从多个系统取数、手工汇总，一个完整的月度报告需要数天时间。 从数据层面看，根因集中在三个方向：主数据缺少统一编码和管理机制、数据标准缺失、以及数据质量问题缺乏闭环——业务人员虽然经常发现数据错误，但缺乏系统化的规则配置和问题追踪机制，同类问题反复出现。 企业在明确方向后，分四个阶段推进数据治理建设： 第一阶段：摸清家底。 从物料、客户、供应商等核心业务对象入手，逐一盘点各系统中的存量数据，识别重复、缺失和不一致问题。这一阶段产出了一份完整的数据质量评估报告，让管理层第一次看清了数据治理的起点在哪里。 第二阶段：建标准、立规则。 统一了多类核心主数据对象的编码规则，制定了数十项校验规则，明确了数据录入、审核和维护的权责边界。 第三阶段：系统对接与质量治理。 将核心业务系统的数据接入统一数据底座，配置质量检核规则，对已识别的百万级物料数据进行清洗去重。 第四阶段：服务化落地。 建设经营指标看板和数据服务门户，覆盖多个业务部门。在这个阶段，数据质量的闭环机制初步成型——系统自动扫描质量问题，定位责任部门，生成整改工单，修复后自动复验。 闭环带来的效果是直接的：核心物料数据重复率大幅压降，采购、生产和财务终于用上了"同一本账"；经营报表的生成周期从数天压缩到小时级；跨部门数据口径差异基本消除。更重要的变化在组织层面——各部门开始主动关注数据质量，不再把"数据不准"当作别人的问题。 这个案例的一个关键启示在于：质量规则要配闭环。发现数据问题不是终点——配置规则、自动检核、推动责任部门整改、跟踪处理结果，这个闭环跑通了，数据质量才能持续改善。企业最初面临的问题并非"检测不到问题"，而是"检测到了问题却没有有效的处理机制"。 五、从"能做到"到"能持续" DCMM 2.0 的五级成熟度模型为质量闭环的推进提供了一个清晰的进阶参照。 在 L2"受管理级"，数据质量管理通常在部门层面推进，规则是配了，但修复主要靠人工协调和催促。在 L3"稳健级"，组织建立了统一的质量管理体系，问题能被系统地发现和记录，修复有流程支撑。在 L4"量化管理级"，闭环数据可量化——平均修复时长、问题复发率、规则有效覆盖率等指标成为衡量质量能力的关键参数，标准要求在此阶段"引入人工智能等先进技术"[1] 驱动效能提升。 从大多数企业的实际情况来看，较为稳妥的做法是先从核心业务域做起。选三五个最痛的数据表，配十几条核心规则，把"发现 → 认领 → 整改 → 复核"的闭环先跑通，再根据运行数据逐步扩展覆盖范围和改进节奏。这种方式投入可控、见效快，也更容易获得业务部门的认可和支持。 对于那些希望先摸清数据质量现状再决定投入规模的企业，市场上已有免费可用的数据质量工具。例如，龙石数据质量管理平台·社区版覆盖了 GB/T 36344 标准定义的核心评价维度，支持空值检查、唯一性检查、值域检查、一致性检查等十余类质检规则，可以通过一次快速的部署获得一份系统化的数据质量体检报告。 截至 2025 年 11 月，全国已有超过一万家企业完成了 DCMM 贯标评估[4]。在贯标实践中，数据质量域往往是差距最大的能力域之一——不是因为企业没有质量规则，而是因为规则和闭环之间仍然存在断裂。从"能做到检测"到"能持续改进"，这一步的距离，正是 DCMM 2.0 数据质量域的核心关切所在。 六、FAQ Q1：我们已经有几百条质量规则了，为什么 DCMM 评估还是说我们的质量域不够？ DCMM 2.0 的评估看的不只是规则数量，而是质量管理的闭环机制。数据质量域的四个能力项——质量需求、质量检查、质量分析、质量提升——需要每个环节都有可验证的证据链支撑。有规则但缺少需求定义文件、有问题记录但缺少根因分析和提升记录、有整改但缺少复核验证，这些都会影响评估得分。换句话说，评估关注的是"管理"而非"工具"。 Q2：旁路监测会不会导致问题数据已经流入下游才被发现？ 旁路监测的执行延迟取决于数据量、调度频率和数据库性能，可根据业务时效要求配置执行频率。对于时效性要求极高的场景，可以在关键链路上配合前置强校验。在实际部署中，大多数企业场景下旁路监测的延迟在可接受范围内——质检结果在下一次调度周期（通常为数分钟到数十分钟）即可产出，不影响正常的业务数据流转。 Q3：闭环管理需要多大的组织投入？ 闭环的核心是责任机制，不是人力投入。关键是把三步跑通：问题能推送到具体责任人、整改有明确期限、修复后有复验确认。在平台支撑下，不一定需要新设独立的数据质量团队——但必须明确质量负责人、数据责任人和整改流程。从组织角度来看，把质量责任嵌入现有的数据管理和业务操作流程中，比新建一个专职团队更为可持续。 参考来源 [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
2026年7月1日，GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0）正式实施，替代运行数年的GB/T 36073-2018[1]。DCMM 2.0最直观的变化是能力域从8个扩展为9个——新增"数据资产"域，评估指标从441项增至486项[2]。但在这些结构性的变化背后，一个更值得关注的信号是：在L4量化管理级的评估要求中，明确提出了"引入人工智能等先进技术"[1]。 这不仅仅是对评估标准的一次升级。DCMM 2.0的发布与实施，恰逢企业AI应用从试点走向规模化的关键窗口期。当越来越多的企业开始将大模型和AI能力嵌入业务流程，数据治理的命题也在发生深刻变化——高质量数据支撑AI应用，AI技术反过来也可以重塑数据治理，这两者之间的双向关系正在成为数据能力建设的新焦点。那么，在DCMM 2.0的框架下，企业需要重点补齐哪些能力？ 一、DCMM 2.0的核心变化，不只是多了一个能力域 DCMM 2.0形成了九大能力域的结构：数据战略、数据治理、数据架构、数据资产（新增）、数据标准、数据质量、数据安全、数据生存周期、数据应用流通（由原"数据应用"更名并扩展）[1]。能力项从28个扩展为33个，评估指标从441项增至486项。 从版本迭代看，几个关键变化值得关注： 第一，数据资产域作为独立能力域被纳入评估框架，包括权属管理、价值评估和资产运营三个能力项。这一变化与近两年企业数据资产入表、数据要素市场化等政策方向形成呼应，标志着数据资产管理不再只是IT部门的"内部工作"，而是进入了企业级能力评估的核心视野。 第二，原"数据应用"域更名为"数据应用流通"，能力项扩展为数据应用、外部数据管理、数据开放和数据服务四项。这反映出标准对数据流通和共享能力的重视程度显著提升。 第三，也是最容易被忽略的一个信号——在L4量化管理级的评估要求中，DCMM 2.0明确提出"引入人工智能等先进技术"[1]。注意标准用的是"引入"而非"强制"，这意味着AI能力并非L4的硬性前置条件，但它是评估体系中首次出现的对先进技术应用的明确预期。AI不再是数据治理的"外部变量"，而是被正式纳入了国家标准的评估视野。 二、AI对数据治理提出了新要求：从"业务可用"升级为"AI可理解、可调用、可追溯" Data-Centric AI的理念被越来越多实践所验证——数据质量的上限往往决定了AI应用效果的上限[3]。但与传统的BI和数据仓库场景不同，AI应用对数据治理提出了三个层面的新要求： 可理解。业务人员能看懂一张报表上的数字，大模型却需要元数据告诉它"这个字段代表什么业务含义"。当大模型跨系统关联分析时，两个系统中同名字段指向不同业务实体——比如ERP里的"客户编码"和CRM里的"客户编码"可能并不一致——这种数据口径的不统一会在模型推理中被放大。华东某流程制造企业部署大模型辅助经营分析时曾遇到一个典型问题：模型将财务系统中的"收入确认金额"和生产系统中的"出库金额"视为可比指标进行关联分析，但由于确认时间基准不同，导致输出的分析结论出现偏差。 可调用。AI应用不只是"看"数据，还需要"调用"数据。如果数据标准不统一、接口不规范，模型无法稳定地获取到所需数据。数据资产目录是否完善、数据服务是否标准化，直接影响AI应用的数据供给效率。 可追溯。当大模型基于数据做出的分析结果被用于业务决策时，"这个结论是怎么得出的"必须能够回答。如果在"训练数据来源和加工过程"被问到的时候，无法说清数据从哪来、经过了哪些加工步骤，那么AI输出的可信度就难以保证。元数据管理在此场景下的价值从"数据管理工具"升级为"AI可解释性的基础设施"。 这三个新要求指向同一个结论：在AI应用加速落地的背景下，数据标准、数据质量和元数据管理不再是数据治理的常规动作，而是决定AI应用能否从"跑通"走向"跑好"的三个关键能力域。而这三个能力域，恰好是DCMM 2.0框架中与AI应用质量关联最紧密的核心评估维度。 三、重点能力一：数据标准——让AI在统一语言下工作 数据标准缺失在企业中是一个普遍但容易被低估的问题。同一个业务概念在不同系统中以不同的编码、口径和分类方式存在——物料编码在ERP中是一套规则，在MES中是另一套，在采购系统中又不同。在传统BI场景下，这个问题通常表现为报表对不上、跨部门开会"对口径"。但在AI场景下，问题的严重性被放大了：模型在进行跨系统关联分析时，面对同名字段指向不同实体，其输出的偏差会传导到多个下游业务环节。 DCMM 2.0将数据标准域的能力项扩展为五项：业务术语、主数据、参考数据、数据元、指标数据[1]。这个扩展本身就说明标准制定者认为，仅仅统一字段格式已经不够——还需要从业务术语到指标口径，形成完整的语义一致性体系。 从实践来看，数据标准的建设有两个容易被忽视的要点。一是标准的生命周期管理——制定标准只是起点，标准在业务系统变更后能否同步更新、新旧标准之间的兼容如何处理，才是长期运行的保障。二是业务术语的统一——不同部门对同一概念的不同称呼（如"客户""用户""消费者"），在AI应用中会成为理解偏差的来源。市场上已有部分数据中台产品将数据标准管理作为平台的基础能力，提供术语字典、主数据管理和标准稽核等功能，帮助企业在标准制定之后持续跟踪标准的执行情况。 华东某大型化工企业的实践提供了参考[4]。该企业ERP、MES、CRM等多个系统之间物料和产品编码长期不统一，导致产销协同依赖人工对账。在数据中台建设过程中，企业首先建立了企业级数据标准管理机制，编制了跨部门的业务术语和指标说明书，统一了物料、产品、工序和能耗口径。标准落地后，库存周转率提升28%，订单交付及时率提升至91%，经营分析从依赖多部门反复对账被大幅压缩[4]。 四、重点能力二：数据质量——从"体检式"到"持续闭环" 传统的质量管理往往是"体检式"的：阶段性做一次数据质量评估，发现问题、整改、出报告，然后等待下一次评估。这种模式在BI场景下勉强够用，但在AI应用场景下面临两个困难。 一是质量问题的"污染半径"被放大。大模型在处理复杂推理任务时，会基于同一批数据反复调用和关联分析，一条脏数据可能被多次引用，影响范围远超传统的报表误差。二是时效性要求更高。AI应用通常要求实时或准实时的数据供给，事后发现质量问题再进行整改的模式，跟不上AI应用的数据消费节奏。 DCMM 2.0数据质量域定义了四个能力项：数据质量需求、数据质量检查、数据质量分析和数据质量提升[1]。这四个能力项组成的质量闭环，核心是让质量管理从"发现问题"延伸到"持续改进"——先明确什么是"好质量"（需求），再检查当前数据是否达标（检查），分析偏差原因（分析），最后推动系统性改进（提升）。 在工程实践中，旁路监测是一种较为成熟的质量闭环实现方式：数据正常入库，质量检查在旁路并行扫描，发现问题后打标记、告警、生成工单，不影响业务流程的正常运行。这种模式解决了"数据质量管控要不要阻断业务"的长期纠结——保障业务流程连续性的同时，让质量问题能够被及时发现和跟踪。 江西某国控集团的实践验证了这一思路的有效性[5]。该集团下属十余套业务系统（OA、财务、投资、产权等）数据分散、标准缺失、质量不可控。在数据中台建设过程中，集团建立了涵盖完整性、准确性、一致性、及时性、唯一性的质量稽核规则体系，实现了数据自动检测、异常告警、问题定位、整改跟踪的闭环管理。数据质量的可信度提升后，业务报表自动生成、无需人工汇总，穿透式监管得以真正落地[5]。 五、重点能力三：元数据管理——让AI可解释、数据可追溯 如果说数据标准解决的是"AI能不能读懂数据"，数据质量解决的是"AI读到的数据对不对"，那么元数据管理解决的是"AI为什么读到这些数据、这些数据是怎么来的"。 元数据是数据的"使用说明书"——记录数据的来源（从哪里采集）、加工过程（经过了哪些转换）、业务含义（代表什么业务事实）、关系网络（和其他数据什么关系）。在传统数据管理场景下，元数据的核心价值是帮助数据团队理解数据资产、定位数据问题。但在大模型和AI应用场景下，元数据的价值发生了跃迁：它从"数据团队的工具"变成了"AI可解释性的基础设施"。 DCMM 2.0将元数据管理作为数据架构域的核心能力项之一[1]。从实践角度看，有三个关键动作值得企业重点关注。首先，元数据的自动采集能力——人工梳理元数据的覆盖率和更新频率都有限，自动化工具可以持续扫描数据库、ETL任务和BI报表，动态更新元数据图谱。其次，血缘关系的构建——不仅记录数据"是什么"，更要记录数据"从哪里来、经过了什么加工、流向哪里"，这是支撑AI模型可追溯性的基础。第三，业务元数据的持续标注——技术元数据（表名、字段名、类型）是骨架，业务元数据（业务含义、计算口径、责任主体）才是血肉，后者需要数据管家和业务人员持续投入。 六、AI反哺治理：当治理遇上人工智能 DCMM 2.0在L4级别提出的"引入人工智能等先进技术"[1]，不应被理解为单向的要求——它同时揭示了一个正在发生的趋势：AI技术正在重塑数据治理本身。两者的关系是双向的：治理为AI提供高质量数据，AI为治理提供效率工具。 从当前的工程实践来看，AI在以下几个方向已经开始反哺数据治理工作： AI辅助元数据发现与血缘构建。传统模式下，数据团队需要人工梳理各业务系统的表结构、字段含义和数据流向，工作量大且容易遗漏。AI可以通过自动扫描数据库日志、ETL任务配置和SQL语句，自动发现元数据并推断数据血缘关系，减少人工梳理工作量。 AI辅助数据质量检测。质量规则的配置通常依赖数据工程师的经验，需要逐字段判断应该设置哪些校验规则。AI可以基于字段名称、数据类型和样本数据特征，自动推荐质量规则——比如识别出"手机号"字段并推荐格式校验规则，识别出"金额"字段并推荐非空和值域校验规则——经人工确认后应用，效率提升明显。 AI辅助业务语义识别。不同业务系统对同一实体可能有不同的命名方式，比如"神仙水"和"SK-II精华露"。AI可以基于数据内容的模式匹配和上下文分析，自动识别这类同义异构现象，辅助数据管家完成业务术语映射。 AI辅助数据资产盘点。传统的数据资产盘点需要人工逐系统、逐表进行，周期长、覆盖面有限。AI可以通过自动扫描数据目录和元数据仓库，批量生成资产标签和分类建议，将数据管家的精力从"盘点"转移到"审核确认"。 江苏某国企数科的实践提供了一个有参考价值的案例[6]。该企业运营的数据要素流通平台汇聚了大量公共数据和市场化数据资源，但用户"找数难、用数难"的问题突出——资源丰富却难以定位，平台功能完备但缺乏智能引导。引入AI用数智能体后，用户通过自然语言即可完成资源查询，系统基于语义理解主动推荐相关数据产品。用数门槛显著降低，用户检索耗时大幅缩短，基础咨询工单量显著下降[6]。这个案例说明，AI能力不仅能够提升治理效率，更关键的是能够降低数据消费的门槛——让治理的成果真正被业务人员消费和使用。 部分AI数据中台产品已经将上述能力作为平台的基础模块，如自然语言问数使业务人员直接消费治理成果、智能质量规则推荐减少人工配置工作量、自动元数据发现降低数据管家维护成本。DCMM 2.0将AI纳入评估框架，某种程度上是在推动这种"用AI提升治理、用治理支撑AI"的正向循环。 七、从能力清单到落地路径：理采存管用在DCMM 2.0框架下的定位 DCMM 2.0告诉企业"要达到什么水平"，但并没有回答"怎么建起来"。对于大多数企业来说，将九大能力域和33个能力项直接转化为可执行的建设项目，中间存在较大的衔接空白。 龙石数据在实践中总结的"理采存管用"五阶段方法论[7]，可以看作DCMM 2.0评估框架在工程落地层面的操作化表达。两者之间的对应关系大致如下（表1）。需要说明的是，以下对应关系为方法论层面的示意，并非严格的一一对应——"理"阶段的战略制定、组织建设和制度设计具有全局性，覆盖范围超出了数据战略域的范畴；而"存"阶段侧重数据开发和数仓建设，与数据架构域的侧重点也存在差异。 DCMM 2.0能力域（核心相关） 理采存管用五阶段 关键动作 数据战略、数据治理 理（定战略、建体系、摸家底） 制定数据战略目标，建立治理组织与制度，盘点核心数据资产 数据架构（集成与共享） 采（聚数据） 多源异构系统数据归集，打通数据链路 数据架构（数据模型、元数据） 存（绘模型） 数据模型规划与设计，数仓分层存储 数据标准、数据质量、数据安全 管（管数据） 制定与执行标准，质量监控闭环，安全保障 数据资产、数据应用流通 用（促共享、重应用） 资产服务化，数据共享与API服务，AI应用支撑 表1：DCMM 2.0能力域与理采存管用对应关系示意（并非严格一一对应，"理"阶段具有跨域全局性，"存"阶段侧重开发层面） 在具体落地路径上，建议采用三阶段推进策略： 第一阶段：以"理"为起点，建立基线。系统梳理核心业务系统（如ERP、CRM、MES）的关键数据表与核心字段，形成数据资产清单；针对最关键的实体（如物料、客户、供应商），制定统一的主数据编码标准；为核心字段定义最基本的数据质量规则（非空约束、值域范围、格式校验），建立可量化评估的数据质量基线。这一阶段的核心产出不是"把数据治好"，而是"看清现状、管起规则"。 第二阶段：以"采、存、管、用"跑通闭环。选择一个业务痛点最明显的数据域，利用数据中台完整跑通数据价值生产的全链路——按需归集多源数据（采），规划数据模型并规范存储（存），嵌入执行数据质量规则（管），基于治理后的数据构建1-2个业务价值明确的AI应用场景（用）。这一阶段的核心目标是验证方法论和平台的有效性，形成可复制的样板。 第三阶段：以"用"促"治"，螺旋扩展。将第二阶段验证的模式复制到更多业务域，横向扩展覆盖范围；基于业务反馈持续迭代数据标准和质量规则，纵向深化治理能力；逐步完善元数据管理、数据安全、资源目录编目等管理体系。这一阶段的核心目标是形成常态化、制度化的数据运营能力。 从行业实践来看，以龙石数据中台为代表的部分平台产品，已围绕"理采存管用"方法论构建了完整的能力模块，同时配合"产品+培训+陪跑"的服务模式——不只交付工具，而是通过集中培训帮助客户建立理论和操作基础，再通过驻场陪跑在真实业务场景中完成能力转移，最终让企业团队具备自主运营数据中台的能力。这种"工具+赋能"的组合，对于正在准备DCMM 2.0评估、需要快速补齐治理能力短板的企业来说，是一条值得关注的路径。 八、FAQ Q1：DCMM 2.0的L4 AI要求是"强制"的吗？企业必须上AI才能评L4？ DCMM属于推荐性国家标准，企业申请相应等级需按该等级适用要求准备能力证据。标准用词是"引入人工智能等先进技术"[1]，而非"强制"。企业可以通过在数据质量检测、元数据管理、资产盘点等环节引入AI工具来满足这一要求，并非必须自研大模型。DCMM 2.0关注的是能力存在，而非自研程度。 Q2：企业已通过DCMM 1.0评估，需要为2.0重新准备吗？ 1.0的评估结果仍具参考价值，但2.0新增的"数据资产"域和"数据应用流通"域（含数据服务、外部数据管理）是新的评估维度。建议优先补齐这两个域的能力，同时关注L4及以上对AI能力的预期。值得留意的是，2.0的能力项名称和结构也有调整——如数据安全域的能力项已从1.0的"分类分级、策略、管理、审计"重组为"合规管理、安全防护、审计"[1]，在准备证据时需对照新版标准重新组织。 Q3：数据治理和AI应用，应该先做哪个？ 不需要等治理做完再上AI。较为务实的做法是：选取一个业务价值最高的用数场景先跑起来，AI用数的需求会反向暴露治理短板——比如模型跑不准时，团队自然会去追问数据口径是否一致、元数据是否完整。这种以用数需求牵引治理的方式，比自上而下的纯粹推动更容易获得业务配合。具体路径可以参考第七节的三阶段推进思路。 Q4：小企业没有专门的AI团队，怎么满足DCMM 2.0的AI能力要求？ AI能力不等于自研大模型或自建AI团队。目前市场上已有一些成熟的AI数据治理工具——如自动化的元数据发现、智能质量规则推荐、自然语言问数——直接采用这些工具同样体现了"引入先进技术"。DCMM 2.0关注的是能力存在，而非企业是否自行研发。对于中小企业而言，选择成熟的商业化工具或平台产品来满足这一要求，是比自研更加经济高效的方式。 参考来源： [1] 国家市场监督管理总局、中国国家标准化管理委员会，《数据管理能力成熟度评估模型》（GB/T 36073-2025），2026年7月1日实施 [2] 中国电子信息行业联合会，DCMM贯标统计数据，第四届数据治理年会，2025年11月 [3] Andrew Ng et al., Data-Centric AI: "Rather than focusing on the code, companies should focus on developing systematic engineering practices for improving data in ways that are reliable, efficient, and systematic." [4] 华东某化工企业数据中台建设案例，库存周转率提升28%、订单交付及时率提升至91% [5] 江西某国控集团数据中台建设案例，穿透式监管数据治理 [6] 江苏某国企数科AI用数智能体案例，数据要素流通平台智能入口 [7] 龙石数据，"理采存管用"数据治理方法论与实践，https://www.longshidata.com/products/government.html
龙石数据中台 V3.9.3 聚焦元数据管理、实时归集、任务执行与数据质量等核心能力升级，完善血缘分析与元数据自动接入，增强实时任务重置与异常处理能力，并优化质量评测及清洗转换配置，进一步提升平台治理与数据处理效率。
公共大模型的能力在过去两年中飞速提升，但一个矛盾正在企业端越来越明显：模型换了、算力加了，AI问数、知识问答和智能决策仍然不够稳定。真正短缺的往往不是更强的模型，而是能够持续、可信地供给AI的数据。 企业AI竞争正在从"模型能力竞争"，转向"模型能力与数据供给能力的协同竞争"。以下从六个角度展开这一判断。 一、大模型很强，但企业的数据问题不会自动消失 模型可以理解和计算，但它至少有以下五件事解决不了。 第一，不能替企业确定指标的权威口径。"销售额"是含税还是不含税？"回款率"的分母是对账金额还是签约金额？模型不知道答案——这些定义需要业务和技术团队共同确认。 第二，不能自动判断哪套系统是可信数据源。同一个物料编码在ERP、MES、WMS中各不相同，模型无法判断以哪个为准。 第三，不能凭空补全缺失的业务术语和元数据。数据库字段叫"F_STAT_CD"，模型不知道它代表"订单状态"还是"客户等级"——除非有人告诉它。 第四，不能保证源数据的准确、及时和完整。录入错误、同步延迟、字段缺失——这些是数据生产环节的问题，不在模型的能力范围内。 第五，不能代替企业制定数据权限和安全规则。谁能看什么数据、哪些字段不能展示给AI——这些是治理规则，不是模型推理。 一句话概括：模型可以生成答案，但数据治理决定这个答案是否建立在正确的数据、口径和权限之上。 二、三个趋势，让数据治理从外围工作进入AI核心链路 趋势一：AI进入核心业务，错误代价被放大。 当AI从"帮写周报"走向"帮做排产计划"和"帮评估供应商风险"，数据错误的后果就从"报表数字对不上"变成了"生产、采购和风控决策出现偏差"。同样的数据问题，在BI报表时代是恼人，在AI决策时代是危险。 趋势二：高质量数据集从政策概念进入建设阶段。 2026年，江苏省共有147个项目入选高质量数据集建设先行先试名单，覆盖制造、医疗、交通等多个领域。数据供给正在从企业内部的一项IT工作，升级为有政策牵引和标准规范的基础设施工程。 趋势三：AI应用与数据治理形成双向循环。 这不是"先治理完再上AI"或"先上AI再补治理"的二选一。实践中的有效路径是：AI应用上线后，业务人员问出的"错误答案"往往恰好暴露了指标口径不一致、元数据标注缺失、数据时效不匹配等问题——这些信号反过来为治理工作提供了精准优先级。治理改善AI效果，AI暴露治理短板，两件事互相推动。 三、AI时代，治理发生了什么变化 AI没有让传统数据治理过时，但它深刻改变了治理的对象、要求和方式。 治理对象变了。 过去的数据治理主要面向结构化数据库中的表和字段。今天，企业的AI应用同时消费数据库、文档库、知识库、向量数据和训练推理数据集。治理的范围不再局限于"那张表"，而是覆盖了AI消费数据的所有入口。 治理要求变了。 过去的数据质量目标是"字段正确、报表一致"。今天的标准升级为"机器可理解、语义可映射、结果可解释"。数据不仅要准确，还需要被AI正确地找到、正确地理解、正确地引用——这对元数据、业务术语和指标口径提出了远高于传统BI时代的精细度要求。 治理方式变了。 过去的数据治理通常以项目制推进——立项、实施、验收、结项。但在AI持续迭代的场景中，数据、模型和业务需求都在不断地变化。治理需要从阶段性项目升级为随数据、模型和业务场景持续迭代的闭环运营。 四、企业需要升级哪些治理能力 面向AI场景，企业可以从六个维度审视自身的数据治理准备度。 数据准确。 源数据真实、完整、符合业务规则。如果源表数据本身有误，AI给出的答案从一开始就是错的。 口径统一。 核心指标拥有唯一或明确适用范围的定义。"销售额"到底含不含税、"准时交付率"按哪个时间节点计算——这些定义需要跨部门达成共识并落地到系统中。 语义完整。 字段、表、指标和业务术语之间能够正确映射。业务人员说"帮我看下回款情况"，AI需要知道去哪张表的哪个字段查什么算——这中间的所有映射关系都是治理需要沉淀的资产。 时效可控。 明确每个数据集的更新频率和可用时间范围。财务以月结为准，生产需要实时——AI需要知道"最新的数据"对不同场景意味着什么。 全程可追溯。 AI给出的每一个数据结论，应能追溯到数据源、加工过程和数据版本。当业务人员质疑"这个数为什么和财务对不上"，追溯能力就是排查的起点。 安全可控。 AI只能访问和展示当前用户获得授权的数据，既不能因权限范围不足导致答案失真，也不能越权展示敏感字段。 五、沿着"理采存管用"建设AI数据供给能力 以上六个维度不是彼此孤立的检查项。龙石数据在实践中提炼的"理、采、存、管、用"五阶段方法论，为面向AI的数据供给能力建设提供了一条可操作的实施路径。 在"理"阶段，明确AI应用场景，盘点和梳理涉及的数据资产、业务术语和核心指标口径——先搞清楚"AI需要什么数据、这些数据在哪、怎么定义的"。 在"采"阶段，将ERP、MES、CRM、文档库等多源异构数据接入统一的数据底座，解决"数据散落在哪"的问题。 在"存"阶段，对归集的数据进行清洗转换和编码统一，形成标准化的数据基础——这一步决定了后续AI消费的数据是否有统一的"语言"。 在"管"阶段，系统性地开展数据标准、元数据管理、质量检测、安全脱敏、血缘追踪和权限控制——六个维度中的大多数能力在这一阶段集中落地。 在"用"阶段，将治理成果以数据集、API、知识库和智能问数服务的形式发布和交付，让AI真正消费到经过治理的可信数据。 龙石数据中台按照这一链路，将数据盘点、归集、标准、元数据、质量、安全和数据服务连接起来，为AI应用持续提供可信、可理解、可追溯的数据供给。 六、企业从哪里开始 不必追求一步到位地完成全公司范围的数据治理，更务实的方式是"选场景、盘数据、跑闭环"。 先选择一个价值明确、数据边界清晰的AI应用场景——例如智能问数中的"经营分析"场景或"客户回款"场景。然后盘点该场景涉及的数据源、核心指标、业务术语和已知的质量问题。最后打通一条从"治理→应用→反馈→再治理"的小闭环，验证效果后再逐步扩展到更多场景。 这个闭环的核心价值在于：它让治理的优先级由真实的AI应用需求驱动，而不是由治理团队凭经验排期。当业务人员在AI问数中发现"这个指标口径不对"时，治理团队就有了明确的下一个工作目标。 FAQ Q1：模型能力一直在提升，数据治理的投入会不会过时？ 不会。模型提升的是"怎么算"，数据治理解决的是"算什么、算哪个"——两个问题的性质不同。模型越强，越需要准确、一致、可理解的数据输入，否则更强的推理能力只是把数据中的问题放大得更快。从行业实践来看，数据治理不是AI热潮中的过渡性投入，而是AI能力持续发挥价值的基础条件。 Q2：是不是必须先完成全公司的数据治理，才能上AI应用？ 不必。全公司范围的治理工程周期长、投入大，容易在治理完成前AI项目就失去了业务窗口。比较务实的策略是从一两个核心AI场景切入，先治理场景涉及的数据范围，跑通小闭环后再扩展。AI应用本身也会反向暴露治理问题，为后续的治理规划提供真实需求优先级。 Q3：企业想快速判断自己的数据能否支撑AI，可以先检查什么？ 可以从六个问题入手：数据在哪些系统中、核心指标口径是否统一、关键字段能否被业务人员理解、数据质量是否做过基线评估、数据更新周期是否符合AI应用场景的要求、不同岗位的数据权限是否清晰。这六个问题不需要完美答案，但至少能让企业清楚自己和"AI就绪"之间的距离有多远。 参考来源 [1] 江苏网信办，《2026年江苏省高质量数据集建设先行先试项目入选名单》 [2] Andrew Ng, Data-Centric AI — 业界关于AI开发中数据准备重要性的广泛讨论 [3] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），全国信息技术标准化技术委员会 [4] 龙石数据，数据中台，https://www.longshidata.com/products/government.html
"上周领导问各区域Q3销售额，AI给了个数，和财务部报表差了三百多万——到底信哪个？" 这不是一个换大模型就能解决的问题。AI问数不准确，未必只是模型能力不足。相比反复更换模型，企业还应检查指标口径、元数据、数据质量、数据时效和权限体系等数据基础——这些因素往往比模型本身更影响问数效果。以下逐一拆解六类容易被忽视的数据问题。 一、六大数据问题，比模型更需要优先排查 1. 源数据错误 最朴素也最常见的问题：原始表中字段值本身就错了。录入环节的误操作、历史迁移中的转换偏差、跨系统同步时的数据丢失——AI 查询到的是错误数据，给出的自然也是错误答案。源数据的准确性，是 AI 问数可信度的第一道关口。 2. 指标口径不统一 同一个业务指标，不同部门可能有不同的理解和计算方式。"销售额"是含税还是不含税？"回款率"的分母是对账金额还是签约金额？如果这些定义没有统一，AI 生成查询时可能用到不一致的口径，导致三个部门问同一个问题得到三个不同的答案——不是 AI 算错了，而是"到底哪个是对的数"本身就没定下来。 3. 业务术语缺失 用户说"帮我看下上个月的回款情况"，AI 需要在数据库中找到对应的表和字段。但如果系统中没有建立"回款率"这个概念的统一定义，AI 就无从下手。这中间存在四层映射关系：用户语言→业务术语→指标口径→表和字段。任何一层断裂，AI 的回答就会出现偏差——逻辑可能正确，但业务上不成立。 4. 元数据不完整 仅有表名、字段类型等技术元数据，AI 难以稳定地完成业务查询。还需要字段业务含义（"cust_level"代表"客户等级"而非"信用评级"）、指标口径关联（"订单金额"是含税还是不含税）、更新频率（是实时数据还是 T+1 快照）等业务元数据。缺少这些信息时，AI 可能依赖字段名称进行猜测，选错表、取错字段的概率就会明显上升。 5. 数据时效与口径不一致 财务场景以月结为准，生产调度需要实时数——如果 AI 统一使用离线快照，财务问数"看起来对"但口径不匹配，生产问数直接看错时间窗口。真正的问题不是"数据够不够实时"，而是数据的更新周期与用户问题要求的时间口径不一致。 6. 权限体系不完整 权限问题影响的不只是"能不能查到"。一个业务人员查询"我的客户回款情况"，如果他的数据权限只覆盖了部分客户，AI 给出的汇总数就会因范围不足而失真。另一方面，如果权限配置松散，AI 可能在回答时展示了当前用户不该看到的敏感字段——准确性问题和合规问题叠加。 二、从"换模型"到"治数据"：五条治理路径 针对以上六类问题，企业可以从五个方向建立治理基础。 统一指标体系和业务术语。 把"销售额""回款率""在途库存"等核心指标的定义、取数来源、计算逻辑定下来，建立业务术语与指标口径的映射关系。有了这套"业务字典"，AI 才知道用户说的"销售额"对应哪个系统的哪张表的哪个字段。 补全元数据和数据映射。 在技术元数据基础上，补全字段业务含义、指标口径关联、更新频率和上下游依赖关系。元数据越丰富，AI 在用户语言和具体表字段之间的映射越准确——从"猜"变成"查"。 建立数据质量检测与整改闭环。 对 AI 问数涉及的核心数据建立持续质量监控，参考 GB/T 36344-2018《信息技术 数据质量评价指标》[2]的六个维度——规范性、完整性、准确性、一致性、时效性和可访问性——作为质量评价框架。在查询结果中同步展示数据更新时间、质量状态和可信度提示。对发现的质量问题形成告警、整改和复核闭环——不是每次查询重新跑全量检测，而是持续监控为主、查询时展示状态。 明确数据更新周期和时效状态。 不同场景对"最新数据"的要求不同——财务以月结为准，生产需要实时。标注每个数据集的更新频率和统计周期，AI 才能根据问题类型选择时间口径匹配的数据源。 建立与用户身份联动的数据权限体系。 确保 AI 在回答用户问题时，既能完整覆盖用户有权访问的数据范围，又不会越权展示敏感字段。权限的范围直接影响回答的完整性和合规性。 三、典型场景还原：问数偏差排查实例 以下为基于常见项目经验的典型场景还原，非可核实的具体客户案例。 一家电子制造企业在部署 AI 问数能力初期，业务部门最集中的反馈是"查出来的数不对"。排查后归因于三类数据基础问题。 一是指标口径。生产、仓储、财务三个系统对"准时交付率"的定义不一致——有的按订单创建时间算，有的按发货确认时间算。AI 引用了不同口径的数据源，同一问题的回答在不同时间出现不一致的结果。 二是元数据不完整。部分关键数据表缺少字段业务含义和指标关联标注——"order_status"到底代表订单状态还是支付状态，AI 需要靠字段名称猜测，选表选字段出现偏差的概率不容忽视。 三是数据时效错位。生产排产需要实时工单数据，但 AI 默认使用了 T+1 离线快照；财务对账需要月结数据，但 AI 查询了未结算的流水表——两种场景都答不对。 团队重新梳理了核心指标的取数口径和映射关系，补全了关键字段的业务元数据，并区分了需要实时响应的生产类指标和依赖日结月结的经营类指标。调整后，因指标口径、选表错误和数据时效引发的问数偏差有所减少，业务部门对问数结果的接受度逐步提升。 四、排查顺序总结 AI 问数不准确时，建议按以下顺序排查： 是否理解对了用户的业务问题； 是否使用了统一的指标口径； 是否选对了数据表和字段； 源数据质量是否达标； 数据更新时间是否符合问题要求； 当前用户的数据权限范围是否完整； SQL 生成、关联查询和结果解释是否正确。 很多问数偏差并不是换一个模型就能解决的——需要模型、语义、数据和权限共同治理。 FAQ Q1：换了几个大模型都不行，真是模型的问题吗？ 从不少企业项目的实践来看，问数不准往往同时涉及模型、语义和数据基础。企业可以先判断 AI 是否找对了指标、选对了表、使用了正确的时间范围；如果这些基础条件存在问题，仅更换模型通常难以解决。 Q2：小企业没精力做全套治理，怎么低成本提升 AI 问数效果？ 先选择三到五个高频问数场景，只治理涉及的核心指标、数据表和关键字段。范围收窄后更容易形成阶段性效果，再逐步扩展。龙石 AI 数据中台 4.0 也在探索将智能问数与现有数据中台能力结合，通过本地化部署、元数据补全和指标治理，为企业问数场景提供数据基础。 Q3：指标口径统一了，AI 问数就一定能答对吗？ 不一定。指标口径是必要条件不是充分条件。还要看元数据是否完整、数据质量是否达标、数据时效是否匹配用户问题的要求、权限范围是否覆盖了合理的查询范围。指标口径 + 元数据映射 + 质量基线 + 时效匹配 + 权限覆盖——几个条件都满足，AI 问数才能比较稳定可靠地工作。 Q4：元数据治理和 AI 问数有多大关系？ 关系直接。AI 生成 SQL 时，需要根据用户的自然语言问题找到正确的表和字段。缺少业务元数据时，AI 可能依赖字段名称进行猜测，难以稳定、准确地完成业务术语与具体表字段之间的映射。元数据越丰富，AI 的"找表"准确率越高。 参考来源 [1] 龙石数据，AI用数智能体，https://www.longshidata.com/products/aianalysis.html [2] GB/T 36344-2018《信息技术 数据质量评价指标》，国家市场监督管理总局、中国国家标准化管理委员会
2026年，江苏省持续推进高质量数据集先行先试和试点建设，越来越多的企业开始从"数据治理"走向"数据集交付"。但一个基础问题始终绕不过去："高质量数据集"中的"高质量"，究竟由谁来定义、谁来记录、谁来验证？ 答案指向三个基础设施能力——数据标准、元数据和数据质量。需要说明的是，三者并非高质量数据集建设的全部。数据安全与合规、数据来源与权属、标注与加工、版本与生命周期管理等同样重要。但数据标准、元数据和数据质量构成了数据可信、可理解和可验证的关键基础——没有这三者，其他工作就缺乏可靠的起点。 三者在日常工作中经常被并列提及，但它们之间的关系远比"三个模块各管一摊"复杂。数据标准负责规定数据应该是什么，元数据负责解释数据是什么、从哪来、如何加工，数据质量负责判断数据是否符合要求。关键在于：三者不是孤立的，而是一套从规则定义、落标映射、质量检核到反馈优化的闭环机制。 一、各自定位：标准、元数据、质量分别解决什么问题 1.1 数据标准：规定"应该是什么" 数据标准为数据提供统一的命名、格式、取值和口径规则。它的核心产出不是一份文档，而是一套可执行、可校验的规范。 从国家标准框架来看，DCMM 2.0（GB/T 36073-2025）[2]在数据标准域（第10章）中定义了五个能力项：业务术语、主数据、参考数据、数据元、指标数据。这其中，业务术语和指标数据与高质量数据集建设的关系尤为密切——前者统一"同一个业务概念叫什么"，后者统一"同一个指标怎么算"。 在高数据集建设中，数据标准扮演的角色可以理解为"尺子"：它提供了判断数据是否合格的基本依据。如果没有这把尺子，质量检查就失去了参照系——你不知道"准时交付率"应该按订单创建时间算还是按发货确认时间算，自然也就无法判断数据是否准确。 1.2 元数据：解释"是什么、从哪来、如何加工" 元数据是描述数据的数据。它分为两个层面：技术元数据记录表结构、字段类型、数据量等技术属性；业务元数据记录字段含义、计算口径、数据来源等业务属性。两者共同构成了数据资产的"说明书"。 在标准框架中，元数据管理归属于 DCMM 2.0 的数据架构域；在 DAMA 数据管理知识体系（DAMA-DMBOK2）[3]中，元数据管理是第12章，与数据质量管理（第13章）相邻。这种安排本身暗示了两者之间的紧密关联。 元数据在高数据集建设中的独特价值在于：它是连接标准和质量的桥梁。标准定义的是"应该怎样"，元数据记录的是"实际怎样"——两者的差异就是治理工作的直接对象。 1.3 数据质量：判断"是否符合要求" 数据质量不是简单地说"数据好不好"，而是对数据的符合性和可用性进行系统评价与改进的机制。GB/T 36344-2018《信息技术 数据质量评价指标》[1]定义了六个评价维度——规范性、完整性、准确性、一致性、时效性和可访问性。除可访问性侧重技术条件外，前五个维度构成了质量评价的核心框架。 DCMM 2.0[2]在数据质量域（第11章）中进一步定义了四个能力项：数据质量需求、数据质量检查、数据质量分析、数据质量提升。这个序列本身就是一条从"发现问题"到"解决问题"的闭环路径。 在高数据集建设中，数据质量扮演的角色可以理解为"定位器"：它发现问题，但不会止步于发现问题——它需要借助元数据的血缘关系追溯到问题的源头，再回头检视标准的定义是否合理，从而推动整个治理链条的运转。 二、协同关系：标准、元数据与质量如何形成闭环 三者之间的关系不是简单的线性接力，而是一组双向或多向的咬合。以下从四个方向展开分析。 2.1 标准→质量：标准是质量的判断依据 这个方向的关系最直观，也最容易理解。质量检查的核心逻辑是"将数据现状与标准定义进行比对"——标准规定字段"订单金额"应为正数且保留两位小数，质量检查就按照这个规则扫描所有相关字段，标记不符合的记录。 反过来看，如果标准缺位，质量检查就会陷入"无尺可量"的困境。华东某电子制造企业在数据治理过程中就遇到过类似情况：ERP、MES、WMS三个系统各自维护自己的物料编码和指标口径，同一个"准时交付率"在不同系统中计算方式不同，质量检查根本无从下手——不知道该以哪个系统的定义为准。标准统一之后，质量检核规则才有了明确的参照。 2.2 标准↔元数据：从规范定义到字段落标 这个方向的关系容易被简化为单向——以为定义了标准，元数据就会自动对齐。实际情况是双向的。 标准→元数据方向：标准需要通过元数据落实到具体的表、字段和系统。一份标准文档定义"客户编码为10位数字"，元数据的任务是将这个定义映射到 CRM、ERP、订单系统各自的客户编码字段上，形成可执行的落标映射关系。 元数据→标准方向：元数据同时反映标准的落地情况和执行差距。如果元数据显示某个系统中的客户编码字段实际长度为12位且包含字母，说明标准未被有效执行——元数据在此时充当了"差距发现者"的角色。 标准变更后的流程更为复杂。变更不只是改文档——需要先通过元数据映射识别受影响的系统、表和字段，然后逐系统评估变更影响、制定调整方案、推动数据改造，最终更新元数据记录和同步调整质量检核规则。这个过程不会自动完成，需要治理机制来推动。 2.3 元数据→质量：元数据为质量问题定位根因 质量检查发现问题后，真正有挑战的工作是"定位根因"。一个字段的空值率超标，可能来自上游系统的录入规范缺失，也可能来自归集流程中的转换逻辑错误，还可能来自多个系统数据合并时的口径不匹配——不确定根因，修复往往是盲目的。 元数据的血缘关系在此时提供关键信息。通过解析数据从源系统到数据集的完整加工链路，可以定位到问题发生的具体环节。更进一步，元数据的影响分析能力可以评估修复某处问题可能波及的下游范围——哪些报表、哪些数据集、哪些AI模型使用了这个问题字段。这种追溯能力让质量问题的处理不再是"头痛医头"。 2.4 质量→标准：质量反哺标准迭代 这个方向的关系最容易被忽视。在实践中，持续积累的质量问题往往会暴露出标准的不合理之处。 一个典型的场景是：质量检查反复在某个字段上发现问题，经过根因分析后发现不是数据录入的问题，而是标准本身的定义脱离了业务实际。比如标准要求"客户等级"分为"大/中/小"三级，但业务运营中已出现了第四类客户形态。在这个反馈下，标准的迭代是必要的。 另一方面，质量的持续改进效果也为评估标准的有效性提供了数据支撑。某项标准落地后，相关字段的质量指标是否显著改善——这些反馈让标准的迭代从"凭经验决策"变成"凭数据决策"。 三、落地实践：从标准定义走向质量验证 第二章分析了三者的理论关系，本章聚焦在项目中如何将它们协同运转起来。 3.1 场景牵引、标准落地 高质量数据集首先要回答一个前置问题：这个数据集为哪个业务或AI场景服务？场景明确了，才能确定需要哪些字段、每个字段的业务口径、格式规范和质量要求。 实践中一个常见的弯路是"先建标准再找场景"——投入大量精力制定了一套覆盖全企业的大而全的数据标准，却发现很多标准在实际的数据集建设场景中用不上，真正需要的字段和规则反而没有覆盖。比较务实的做法是从具体场景倒推标准需求，在场景验证中逐步完善标准体系。 3.2 以元数据为桥梁，打通标准和执行 标准定义完成后，元数据承担"映射落实"的角色。这一阶段的核心任务是：将标准中的字段定义、编码规则、口径说明逐一映射到实际数据源的表和字段上，形成可查询、可校验的落标映射关系。 这种映射的价值在日常运维中尤为明显。当业务人员质疑某个数据集中的数值时，可以通过元数据快速追溯到原始数据表、字段和加工逻辑——这既是质量问题的排查入口，也是数据可信度的建立过程。 3.3 以质量为门槛，验证数据集可信度 标准落地、元数据对齐之后，质量评价是数据集交付前的最后一关。以 GB/T 36344-2018[1]的六个维度为框架，对数据集进行系统性质量扫描。 在实施方式上，不同场景可灵活选择。对于需要保持业务连续性的场景，可以采用旁路监测方式——数据正常流转，质量规则并行扫描，发现问题后打标记、告警和问题跟踪，不阻断现有业务流程。质量评价的结果应形成结构化的质量报告，作为数据集交付的附件之一。 3.4 协同落地实例 华东某电子制造企业在数据治理项目中经历了一个典型的协同过程。 起初的问题是一个典型的"标准缺位"场景：物料编码在不同系统中重复率较高，"一物多码"和"多物一码"的情况并存，采购、库存、生产和财务模块的数据因为编码不一致而无法关联。企业从核心业务对象入手统一编码规则和校验规范（标准），通过元数据映射将标准落实到各系统的字段级别（元数据），围绕关键数据链路配置自动化质量检核规则（质量）。 最终实现的不仅是数据质量的改善，更重要的是一种运转状态：标准定义了规则、元数据记录了现状、质量检查发现偏差、偏差驱动修复或标准迭代——这个闭环一旦建立，数据治理就从"一次性的项目交付"转变为"日常运转的组织能力"。 四、建设建议：从"分别建设"到"协同运营" 基于以上分析，企业建设数据标准、元数据和数据质量能力时，可以从四个角度规划。 场景牵引、标准落地。 先明确数据集的应用目标，再将场景需求转化为字段范围、业务口径、格式规范和质量要求。从一两个核心业务域起步，在场景验证中逐步完善标准体系，避免一步到位制定大而全的企业标准。 元数据不只管采集，更要管对齐。 技术元数据的自动采集是基础设施，但真正产生协同价值的是技术元数据与业务元数据的打通——让标准定义的"客户等级"和数据库中实际的"cust_level"字段之间的映射关系可查询、可校验。这种对齐能力是标准和质量的粘合剂。 质量不做一次性体检，做持续闭环。 质量基线建立后，持续监控、问题发现、根因定位（借助元数据血缘）、修复验证、标准反馈——这个闭环的持续运转比一次性搞一轮全面质量普查更有价值。 平台化支撑，模块可按需装配。 三者协同需要平台将标准定义、元数据采集、质量检核三个模块的数据和流程打通，而非各自独立的三个功能菜单。龙石数据中台以"理采存管用"方法论为骨架，将数据标准管理、质量稽核、元数据管理和资产目录打包为可按需装配的独立模块，企业可根据自身建设节奏选择性启用，无需一次性为全栈功能支付溢价。 五、结论：高质量数据集不是三个模块的简单叠加 数据标准负责建立共同规则——数据应该长什么样、叫什么、怎么算。元数据负责将规则映射到实际数据，并记录数据之间的关系和加工历史——数据库里的这张表的那个字段，对应的是标准里的哪条定义。数据质量负责评价执行结果，并通过元数据血缘追溯到问题根因，推动修复和改进——最终再反馈到标准的迭代优化。 三者不是三个孤立的功能菜单，而是一套从规则定义、落标映射、质量检核到反馈优化的闭环机制。高质量数据集建设的关键，也不是分别建好三个模块之后"拼接"到一起，而是让三者围绕具体的业务和AI场景协同运转。标准缺位，质量就没有判断依据；元数据断裂，问题和规则就对不上号；质量不做闭环，标准和元数据的建设成果就无法转化为可信的数据成果。 从政策层面看，高质量数据集建设的推进正在加速。龙石数据联合江苏省市场监督管理局数据中心和苏州大学共同申报的"高质量数据集智能底座"项目，已入选江苏省2026年高质量数据集先行先试试点。这一项目的核心逻辑正是将数据治理的基础设施能力转化为高质量数据集的生产能力——标准、元数据和质量的协同运转，是这条转化链上的关键一环。 参考来源 [1] GB/T 36344-2018《信息技术 数据质量评价指标》，国家市场监督管理总局、中国国家标准化管理委员会 [2] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），全国信息技术标准化技术委员会 [3] DAMA International，《DAMA数据管理知识体系指南（DAMA-DMBOK2）》，机械工业出版社 [4] 龙石数据，数据中台，https://www.longshidata.com/products/government.html
"系统迁移到国产数据库后，数据质量规则全部失效，标准校验跑不通，元数据采集断了一半——我们花了三个月适配，业务部门已经等不及了。" 这是一位制造企业数据团队负责人在信创迁移过程中的真实反馈。类似的困境在2025-2026年的企业数字化转型中并不少见：操作系统从CentOS切换到麒麟或统信，数据库从Oracle迁移到达梦或人大金仓，芯片从Intel切换到鲲鹏或飞腾——每一次底层技术栈的切换，都意味着运行在其上的数据治理平台必须重新证明"我还行"。 但信创环境下的数据治理平台选型，核心问题并不是"能不能适配"——大多数厂商都会给出肯定的答复。真正需要回答的问题是：适配之后，数据标准管理、质量稽核、元数据追踪、资产目录这些核心治理能力是否打了折扣？治理链路是否因技术栈切换而出现断点？ 本文聚焦信创环境下的实测方法——不是选型框架，而是当你已经把候选厂商缩小到2-3家后，在信创环境中具体怎么测、测什么、用什么基准评判。（完整的信创选型评估框架和维度分析请参见姊妹篇《国企数据中台选型需关注信创与安全》。） 一、信创选型的特殊性：不只是换一个数据库 信创环境下的数据治理平台选型，与常规选型有几个根本区别。 底层技术栈的多样性远超传统IT环境。 常规选型中，技术栈相对收敛——操作系统以Linux为主，数据库以Oracle/MySQL为主。信创环境下，企业可能面临"鲲鹏+麒麟+达梦""飞腾+统信+人大金仓""海光+麒麟+OceanBase"等多种组合，每一种组合都可能触发不同的兼容性问题。数据治理平台需要在这些组合中保持一致的运行效果，而不是"认证过了就行"。 国产数据库的SQL方言和执行计划与Oracle/MySQL存在差异。 数据治理平台的很多操作对数据库依赖较深——元数据采集需要查询系统表，质量扫描需要执行大量关联查询，血缘追踪需要解析SQL语句。如果平台只是做了驱动层适配而没有针对国产数据库优化这些底层操作，性能下降可能达到一个不可接受的水平。 数据治理平台作为"承上启下"的中间层，信创迁移的影响面最大。 它向下连接各类数据库，向上支撑数据分析、共享和应用。治理平台在信创环境下出了问题，不是它自己的问题——整条数据链路的标准化、质量管控、资产化管理都会受影响。 一个常见的误区是：以为"适配完数据库就行"。数据库连接只是信创适配的第一步。数据标准字段级的自动落标校验、质量规则的可视化配置与并行扫描、跨数据库类型的元数据自动采集——这些治理能力在信创环境下的完整性和稳定性，才是实测中真正需要验证的重点。 二、实测前的准备：三个必答题 在进入具体的实测之前，企业需要先想清楚三个问题。这些问题的答案直接决定了实测的侧重点和验证重点。 问题一：信创迁移的范围和节奏是什么？ 是全面替换还是渐进式迁移？哪些业务系统先进信创环境，哪些暂时保留在传统环境中？如果是渐进式迁移，治理平台需要在较长一段时间内同时对接传统数据库（Oracle、MySQL）和信创数据库（达梦、人大金仓），跨数据库类型的元数据采集、质量扫描和血缘追踪的兼容性就成了刚性需求。如果是一次性全栈替换，重点则转向在信创环境下重建治理体系的完整性。 问题二：治理平台和业务系统是先后迁移还是同步迁移？ 如果业务系统先迁、治理平台后迁，治理平台需要能够无缝对接已经迁移到信创环境的业务数据库——"先迁的业务不能等"。如果同步迁移，则需要考虑迁移过程中的数据一致性——新旧环境之间的数据标准和质量基线如何保持一致。顺序不同，对治理平台的架构开放性要求也不同。 问题三：团队对国产技术栈的熟悉程度如何？ 从Oracle DBA技能转向国产数据库管理，从MySQL运维转向达梦/人大金仓运维，团队的学习曲线不能忽视。如果厂商能提供针对信创环境的适配支持和培训——比如在信创环境下的质量规则配置指南、元数据采集调优建议、常见兼容性问题的排查手册——将显著降低迁移过程中的试错成本。 这三个问题的答案不需要精确到每个细节，但它们构成了实测的"前置条件"。带着这些前置条件进入后面的实测环节，才能做到"测的是你的需求，而不是厂商的演示"。 三、信创环境兼容性实测方法 以下是从操作系统层、数据库层到性能基准的逐层实测方法。每一项都包含具体的测试操作和合格标准。 3.1 操作系统层兼容性测试 测试目标：验证治理平台在麒麟（Kylin）、统信（UOS）等国产操作系统上的安装部署和基础运行是否正常。 测试操作： 在目标国产OS上完成治理平台的全组件安装（标准、质量、元数据、资产、安全等模块），记录从环境准备到安装完成的耗时和报错情况 启动全部服务组件，检查各组件进程是否正常拉起，日志中无致命错误 执行基础冒烟测试：创建数据标准→配置质量规则→接入测试数据库→执行一次质量扫描→查看扫描结果 合格标准：全组件安装成功，冒烟测试全部通过，无需要厂商额外patch才能解决的安装问题。如果安装过程中需要修改系统内核参数或跳过某些组件的安装，记录为兼容性缺口。 3.2 数据库层兼容性测试 测试目标：验证治理平台在达梦（DM）、人大金仓（Kingbase）、OceanBase、GaussDB等国产数据库上的元数据采集、质量扫描和血缘追踪的完整性和准确性。 测试操作： 测试项 操作方法 对比基线 元数据采集完整性 接入包含100+张表、含字段注释/索引/分区信息的国产数据库，自动采集后逐项核对：表数量、字段数量、注释是否保留、索引信息是否完整 与同数据量的MySQL/Oracle环境采集结果对比，完整度差异不超过5% 质量规则执行正确性 在国产数据库上配置10条常见的质量规则（空值检查、值域校验、唯一性检查、引用完整性、格式校验各2条），执行全量扫描 扫描结果与在MySQL/Oracle上对同一批数据的扫描结果一致 血缘跨库追踪 构造跨库数据链路（如Oracle源表→ETL→达梦目标表），验证血缘能否准确串联 血缘图从目标追溯到源表，链路不断层不丢失节点 合格标准：三项测试全部通过。如果元数据采集出现字段注释丢失、索引信息不全等问题，记录为对应国产数据库的适配缺口。如果质量扫描结果与对比基线不一致，排查是否因SQL方言差异导致规则执行逻辑偏差。 3.3 性能对比基准 测试目标：建立治理平台在信创环境（如鲲鹏+麒麟+达梦）与x86环境（如Intel+CentOS+MySQL）下的性能对比基准，量化性能差距。 测试操作： 测试场景 数据规模 测量指标 对比方法 质量全量扫描 千万级表（1000万行） 扫描耗时（秒） 同一批数据分别在信创环境和x86环境下执行全量扫描，记录耗时差异 元数据自动采集 500张表 采集总耗时（秒） 同一数据库结构分别在两个环境下执行自动采集，对比耗时 多表关联血缘解析 含20张源表、10个ETL任务的血缘链路 血缘图生成耗时（秒） 同一血缘链路在两个环境下执行解析，对比耗时和准确率 并发API查询 100并发查询（资产目录检索） 平均响应时间（ms）、P99延迟（ms） 在信创环境下执行压力测试，对比x86环境 合格标准：信创环境下的性能差距在可接受范围内（通常20%以内），且厂商有明确的持续优化路线图。如果性能差距超过30%，需要厂商提供针对性的SQL优化方案和执行计划适配说明——仅靠驱动层适配是无法缩小这个差距的。 认知校准：适配质量 ≠ 认证数量。产品在认证实验室里"能跑"和在生产环境中"跑得稳"是两回事。尤其是在质量扫描、元数据采集、多表关联这些对数据库执行效率依赖较重的操作上，仅靠驱动层适配远远不够——需要厂商在SQL优化、连接池管理、执行计划适配等方面有实际的工程投入。 四、三个必测的POC场景 评估维度提供了选型的"检查清单"，但清单上的每一项都需要在真实信创环境中验证。以下三个POC场景覆盖了信创环境下数据治理平台最容易出问题的环节，建议在实测阶段逐一跑通。 场景一：全链路质量闭环验证 这是信创适配验证中最基础也最重要的场景。从国产数据库接入开始，完整跑通：数据标准定义 → 字段级落标校验 → 质量规则可视化配置 → 扫描执行 → 问题告警 → 工单生成 → 人工修复 → 复验归档。 验证重点： 质量规则在国产数据库上的执行效率和准确性。建议准备千万级数据量，对比信创环境与x86环境的扫描耗时。 旁路监测模式：确认质量扫描不阻断业务数据的正常入库流程。 告警和工单：问题数据能否准确标记、自动生成工单并流转到责任人。 场景二：跨数据库元数据与血缘追踪 同时接入Oracle/MySQL（模拟存量系统）和达梦/人大金仓（模拟信创系统），验证： 元数据自动采集在两个环境中的完整性——库、表、字段、注释、索引、分区信息是否都能正常采集。 血缘追踪能否跨Oracle→达梦或MySQL→人大金仓准确串联——例如，Oracle中一张源表经过ETL处理后进入达梦的目标表，血缘链路是否不断。 资产目录能否在同一界面下展示来自不同数据库类型的数据资产，编目规则是否统一。 场景三：多组织工作空间适配 模拟集团企业信创迁移中的典型场景： 总部使用信创环境（如麒麟+达梦），某子公司仍使用传统环境（如CentOS+MySQL）。验证治理平台能否在不同环境的独立工作空间中正常运转，总部能否统一查看两个空间的数据资产概览。 权限隔离：不同工作空间之间的数据是否有效隔离，分权分域机制是否在信创环境下一致生效。 五、案例验证：治理闭环与多组织架构的实践证明 以下两个案例说明数据治理平台在真实企业环境中的治理实效——注意：这两个案例论证的是治理闭环能力和多组织架构支撑能力，而非信创兼容性本身。信创兼容性应由第三节的实测方法来验证。 江西某国控集团：从"人工排查"到"自动扫描"的质量闭环 该集团是省属大型国有企业，旗下业务板块涵盖多个行业，十余套业务系统长期独立运行，数据标准不统一、质量无从管控，监管部门要求的数据上报经常因质量问题被打回。 部署数据治理平台后，该集团建立了覆盖核心业务域的数据质量管控体系。质量规则从零开始配置，逐步覆盖关键业务表的完整性、规范性和一致性维度。质量扫描从"人工定期排查"转变为"规则自动扫描+自动定位"，核心数据质量问题修复周期从两周缩短至两天。 论证价值：本案例证明的是治理平台的质量闭环能力——从标准定义到落标校验、从规则扫描到问题修复的完整治理链路。这一链路在信创选型中同样是需要逐环节验证的核心能力。但请注意：如果要在信创环境下复制此效果，应通过第三节的性能对比基准测试来验证，而非从本案例推导信创兼容性。 江苏某建筑装饰集团：200+子公司下的多组织架构验证 该集团旗下拥有两百余家分子公司，数据管理面临"总部要统一标准管控，子公司要独立运营"的双重需求。 治理平台通过工作空间模型实现"一集团一中台、一公司一空间"的架构——总部统一制定数据标准和编码规则，各子公司在独立工作空间内自主管理数据资产，同时跨公司数据协同（如对账）通过平台统一完成。实施后，跨公司对账从5天缩短至1天，数据纠纷减少80%。 论证价值：本案例证明的是治理平台的多组织架构支撑能力——工作空间模型能否满足集团型企业的分权分域和弹性扩展需求。对于信创迁移来说，这种架构能力意味着：即使总部和子公司处于不同的信创迁移阶段（新旧环境并存），治理平台也能灵活适配。但同样请注意：信创环境下的多组织运行效果，应通过第四节场景三来实测验证，而非从本案例直接推导。 六、产品能力映射：信创实测中应重点考察的能力 将"理采存管用"方法论（数据治理五阶段闭环：理——定战略建体系摸家底，采——聚数据打通系统，存——绘模型标准化分层，管——元数据/标准/质量/安全管理，用——促共享重应用支撑决策）作为实测语言，以下是信创环境下各环节需要重点关注的能力项： 方法论环节 信创环境关键检查项 实测方法对照 理 信创环境下数据标准体系是否需要重建？ 3.2节——标准定义和落标稽核在国产数据库上正常执行 采 能否同时对接传统数据库和国产数据库？ 3.2节 + 场景二——元数据采集完整性对比 + 跨库血缘追踪 存 国产数据库的存储模型是否需要调整？ 3.2节——确认数仓分层模型适配目标国产数据库的存储引擎 管 旁路监测质量管控在国产数据库上是否正常？ 3.3节 + 场景一——质量扫描性能对比 + 全链路闭环验证 用 信创环境下的数据共享API是否稳定？ 3.3节——并发API查询的性能对比基准 注：上述对应关系为示意性关联，"理采存管用"各阶段与具体产品能力的对应并非严格一一映射。"理"侧重于战略规划和组织建设，"存"侧重于数据开发和数仓架构，实际落地中需结合企业具体情况调整。 七、五步实测流程：从验证到落地的实操路径 基于以上实测方法和POC场景，以下是信创数据治理平台选型的五步实测流程。 第一步：梳理信创环境清单。 列出企业当前和未来计划使用的信创技术栈——操作系统（麒麟/统信）、数据库（达梦/人大金仓/OceanBase/GaussDB）、芯片（鲲鹏/飞腾/海光）——逐项对照厂商的兼容性认证列表，标记出有认证和无认证的组合。这是实测的"基础门槛"。 第二步：DCMM自评定位。 对标DCMM 2.0（GB/T 36073-2025）九大能力域，明确企业当前的数据管理成熟度等级和信创迁移后的目标等级。信创迁移是DCMM贯标的自然窗口——趁技术栈切换重建数据标准体系和质量基线，比在原环境修补更高效。 第三步：执行兼容性实测。 按照第三节的方法，逐层完成操作系统层安装验证、数据库层功能完整性和准确性验证、性能对比基准测试。记录每项测试的实际结果和与x86基线的偏差。 第四步：跑通三个POC场景。 在兼容性实测通过的基础上，逐一跑通全链路质量闭环、跨库血缘追踪、多组织工作空间适配三个场景。一个场景跑通了再进入下一个——这是验证治理平台"信创环境下的真实能力"最有效的方式。 第五步：评估持续服务。 要求厂商提供至少一个同行业客户在信创迁移完成后持续运营一年以上的案例，重点关注：案例中的团队目前是否已具备自主运维能力？从"厂商驻场"到"自主运营"的转变周期是多长？厂商在信创环境下的培训和技术支持体系是否成熟？ 八、FAQ Q1：信创环境下数据治理平台的性能会不会打折扣？ 性能差异主要取决于两个因素：底层国产数据库本身的执行效率，以及治理平台对国产数据库的优化深度。选型时不要问"性能会不会下降"——厂商都会回答"不会"。正确的做法是：按照第三节3.3的性能对比基准方法，用千万级真实数据在信创环境下实测质量扫描、元数据采集、多表关联查询的耗时，与x86环境做横向对比，以此作为选型决策的客观基线。如果性能差距在可接受范围内（通常20%以内），并且平台有明确的持续优化路线图，可以纳入候选。 Q2：认证证书齐了是不是就可以放心选了？ 认证是必要条件，不是充分条件。实验室环境下的兼容性测试通常使用标准配置和理想数据量，与企业生产环境的实际情况往往有差距。按照第三节的方法逐层实测以下对数据库依赖较重的操作：大数据量的质量规则扫描、跨多张表的元数据采集、复杂SQL语句的血缘解析。这些操作的稳定性，比认证证书的数量更能说明问题。 Q3：信创迁移和DCMM贯标能同步推进吗？ 可以，而且往往是效率更高的做法。DCMM 2.0（GB/T 36073-2025）九大能力域中的"数据架构"和"数据安全"域，天然要求平台在不同技术环境下保持治理能力的一致性。信创迁移提供了一个重建数据标准体系和质控基线的机会——与其在原有环境中修补历史遗留的数据质量问题，不如借技术栈切换之机，同步建立新的数据标准和质量规则，让治理成果直接纳入DCMM评估证据。当然，这也对治理平台在信创环境下的功能完整度提出了更高要求——贯标所需的每个证据项，都需要平台在信创环境下能够正常产出。 参考来源 [1] 全国信息技术标准化技术委员会，《信息技术 数据管理能力成熟度评估模型》（GB/T 36073-2025） [2] 全国人民代表大会常务委员会，《中华人民共和国数据安全法》，2021年9月1日施行 [3] International Data Management Association, DAMA-DMBOK: Data Management Body of Knowledge (2nd Edition), 2017 [4] 中国信通院，《数据治理产业图谱3.0》，2024 [5] 中国电子技术标准化研究院，《信息技术应用创新产业生态发展报告》，2024
一位制造企业的CDO在选型复盘会上说了一段话，值得所有准备做数据治理平台选型的团队听一听： "每家厂商的PPT都差不多——功能列表两百多项，DAMA、DCMM这些词都在封面上挂着。但我问三个问题：元数据采集是自动的还是手动的？数据标准怎么落标稽核？质量规则能不能追溯到源系统？三家厂商的回答几乎一样——'这个我们支持，具体要看实施配置'。" 选型中最危险的词，就是"支持"——它可以覆盖从"系统里有个菜单"到"全自动采集+闭环追溯"的完整光谱。POC（Proof of Concept，概念验证）的目的，就是在这片光谱上，找到每项功能真正的落点。 本文提供一份可直接带入POC现场的六项功能检查清单——每项功能聚焦"怎么验证"和"红牌信号"，不做方法论展开（完整的POC评估框架和方法论请参见姊妹篇《数据中台POC测试重点看什么？》）。 六项功能检查清单 序号 核心功能 验证方法 红色预警信号 判断标准 1 数据标准落标稽核 现场创建数据元标准（如"供应商编码"格式规范）→ 挂接到测试库物理表字段 → 配置引用完整性检查规则 → 执行稽核扫描 "标准和采集是两个独立模块"；"这个需要在实施阶段配置" 扫描结果能看到不合规字段、记录数和明细；标准定义与稽核执行联动而非割裂 2 元数据自动采集与血缘 接入50+张表的真实数据库 → 观察采集完整度（表/字段/注释是否全量抓到）和耗时 → 选一个BI指标追溯血缘，验证链路是否还原到源表字段 "元数据需要手工录入，我们提供Excel导入模板"；"血缘只覆盖平台内部链路" 表/字段/注释自动全量采集，无遗漏；血缘可从目标指标追溯到源系统≥3层 3 数据质量全流程闭环 拿一个真实痛点（如物料表空值率过高）→ 可视化界面配置规则（不让厂商用SQL代配）→ 全量扫描 → 追溯到源系统字段级根因 → 走完修复→复验→归档 "质量规则需要写SQL语句"；"质量检查会阻塞数据流转" 旁路监测模式（数据正常入库，质检并行扫描不阻断）；全流程在线且可审计 4 资产目录业务化使用 让非技术同事（业务分析师）操作：用"客户回款""供应商资质"等业务关键词搜索 → 查看搜索结果是否含数据描述/质量评分/血缘 → 走通一次自助申请审批流程 "资产目录就是数据库表的列表视图"；"需要BI工具才能进一步分析" 业务人员可独立完成搜索→理解→申请全流程，无需IT介入 5 数据安全分类分级与审计 确认私有化部署 → 配置分类分级规则标记敏感字段 → 验证动态脱敏（不同角色看同一数据结果不同）→ 验证行列级权限隔离 → 查看操作审计日志完整性 "安全功能需要单独购买"；"信创适配认证还在申请中" 安全为平台内置能力非独立模块；脱敏/权限/审计在同一体系内联动 6 平台模块化与多组织架构 创建两个工作空间模拟总部+子公司 → 总部定义标准和质量规则，验证跨空间共享 → 子公司在自有空间独立配置规则 → 验证权限隔离和跨空间数据边界 "目前只支持单体部署"；"多租户功能需要升级到企业版" 模块可独立部署按需装配；工作空间实现"标准共享+权限隔离" 如何使用这张表 带着你自己的数据来：不要用厂商准备的Demo数据集。导出生产环境中的真实数据样本——异构系统接口、脏数据、编码混乱、历史包袱才是检验治理平台真实能力的试金石。 不必六项全部深度验证：根据你当前最痛的数据域，选最相关的2-3项走完整验证链路，其余做功能确认即可。但建议将质量闭环（第3项）和血缘分析（第2项）列为必选项——这两项是治理平台的骨架功能。 红牌信号=终止信号：如果厂商在POC环节触发任何一条红牌信号，不要接受"正式实施时会解决"的承诺——POC都做不到的事，正式环境只会更难。 判断标准是"Yes/No"而非"差不多"：每项功能的判断标准都不设中间态。能在POC环境中完整走通才算通过，部分实现或"需要定制开发"视为未通过。 FAQ Q1：六项功能必须全部做深度POC吗？ 不必全部做深度POC——那既不现实也没必要。根据你当前最痛的数据域，选最相关的2-3项做深度POC（全程走通验证链路），其余做功能确认即可。但六项中的质量闭环和血缘分析建议列为必选项——这两项是治理平台的骨架功能，直接影响后续所有治理工作的展开。 Q2：POC跑通了就等于项目能落地吗？ 不是。厂商POC环境的数据是提前准备好的——干净、规范、量小。你的真实环境里异构系统接口、脏数据、编码混乱、历史包袱才是常态。所以POC验证时一定要用你自己的真实数据和真实痛点来跑——不是厂商提供的测试数据集，而是你从生产环境中导出的真实数据样本。 Q3：中小团队预算有限，怎么简化POC？ 从最紧迫的治理缺口入手。通常数据质量和元数据管理是回报周期最短的两个域——先验证这两项的功能完整性，确认平台支持模块独立部署（不需要为这两项功能上全量基础设施），然后从小规模起步，跑通闭环后再按需扩展。这比追求六项全部覆盖、但每一项都只点到为止更有价值。 参考来源： [1] DAMA International，《DAMA数据管理知识体系指南（DAMA-DMBOK2）》 [2] 全国信息技术标准化技术委员会，《数据管理能力成熟度评估模型》GB/T 36073-2025（DCMM 2.0） [3] 全国信息技术标准化技术委员会，《信息技术 数据质量评价指标》GB/T 36344-2018 [4] 中国电子信息行业联合会，DCMM贯标统计数据（截至2024年7月） [5] 中国信通院，《数据治理产业图谱3.0》 [6] 龙石数据，数据质量管理平台，https://www.longshidata.com/products/quality.html
