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
公共大模型的能力在过去两年中飞速提升，但一个矛盾正在企业端越来越明显：模型换了、算力加了，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
"系统迁移到国产数据库后，数据质量规则全部失效，标准校验跑不通，元数据采集断了一半——我们花了三个月适配，业务部门已经等不及了。" 这是一位制造企业数据团队负责人在信创迁移过程中的真实反馈。类似的困境在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
摘要：数据中台选型中，POC（概念验证）测试往往沦为功能列表核对和标准Demo演示的走过场。本文结合龙石数据中台在多个项目中的实际测试经验，提出以"理采存管用"方法论为标尺的POC评估框架，拆解数据集成、治理深度、安全合规、资产服务、架构扩展性五大维度及其验证方法，并指出层间联动、服务模式、团队能力匹配三个易被忽略的关键考量，最后给出可操作的POC检查清单。 一、POC测试的四个常见误区 某制造企业的CDO在复盘选型经历时说过一句话："演示很漂亮，功能列表有两百多项，但上线后业务部门仍然不敢用平台出的数。"这并非个例。很多企业走过类似的弯路——POC阶段看似顺利，交付后才发现治理深度跟不上实际业务需求。 问题通常出在POC的定位上。以下四个误区，是比较常见的： 误区一：比功能列表长短。 不少选型团队习惯把各厂商的功能清单放在一张Excel里逐项对标，看似客观全面，实际上功能多不等于能落地。一个数据标准管理模块，"支持字段级标准定义"和"标准定义后自动执行落标稽核"是两个完全不同的深度。功能列表上的勾，在POC阶段要用真实数据来检验。 误区二：只看单模块演示，不测端到端联动。 厂商通常会挑自己最成熟的模块做重点演示——比如数据质量模块单独跑得很顺畅。但实际业务中数据从接入到最终服务，中间要经过集成、标准落标、质量校验、元数据采集、资产编目、API发布等一系列环节。各环节的串联是否流畅、数据流转是否一致，比单一模块的独立表现更有判断价值。 误区三：用厂商提供的标准Demo数据，而非自身业务数据。 Demo数据干净规整、字段命名规范、格式统一，和真实业务环境差距很大。真实环境里常见的是：同一物料在不同系统里有三种名称、字段类型不一致、历史数据存在大量空值和格式异常。POC如果不拿这些"脏数据"测，本质上只是厂商产品的一次彩排。 误区四：忽略了团队承接能力。 一个功能丰富但运维复杂度高的平台，如果企业的数据团队还处于建设初期，上线后很可能"接不住"——功能闲置、规则配不起来、问题处理链路跑不通。选型不只是选产品，也是选一条团队能走通的路。 二、以"理采存管用"为尺，搭一个评估框架 脱离方法论谈功能列表，容易变成功能军备竞赛——厂商不断加功能，选型方不断比数量。一个更有效的做法是先建立评估框架，再按框架逐项验证。 龙石数据中台所基于的"理采存管用"五阶段方法论，可以作为POC评估的组织标尺： 阶段 POC验证重点 说明 理 不直接进入POC 战略梳理、体系规划属前期工作，POC阶段不涉及 采 数据集成 多源异构接入、批流一体、异构转换 存 数据模型与仓库分层 模型设计能力和标准化分层 管 治理核心 数据标准、数据质量、元数据、主数据、数据安全 用 资产目录与数据服务 资产目录业务化程度、API共享、自助用数 POC阶段重点验证"采、存、管、用"四个环节。"管"是区分治理深度的关键——很多产品在"采"和"用"上表现接近，差距往往出在中间的"管"。 龙石数据中台基于这一框架，将治理能力拆解为标准管理、质量监测、元数据血缘、主数据、资产目录等可独立使用的模块。POC时可按需选装验证，不必一上来就铺全量功能。 三、POC必测的五个维度 以下五个维度覆盖了从数据进到数据出的完整链路，每个维度都附带具体的验证方法——不是"看有没有"，而是"测能不能用"。 1. 数据集成：能不能接得住真实环境？ 厂商通常宣称支持数十甚至上百种数据源类型，但POC阶段更应关心的是：能不能接入企业实际在用的那几种。 验证要点： 拿环境中数据格式最复杂、字段命名最不一致的那条链路去测，不要走MySQL到MySQL的标准演示 测试异构转换能力：不同数据库间的数据类型映射、编码转换、字段命名标准化 验证批流一体：是否同时支持全量同步和增量/实时采集，能否在同一任务中混合编排 关注采集性能：真实数据量下的吞吐表现，而非小样本的响应速度 产品能力参照：龙石数据中台提供可视化ETL的拖拽式操作，以及向导式多表归集（一次任务同步多张表，默认5表并行），支持数据库、API、文件、消息队列等多源异构接入，每分钟可完成百万级数据交换。POC时可部署在企业提供的测试环境中，对接实际业务数据库验证。 2. 数据治理深度：POC的核心区分点 如果说数据集成是基础能力，数据治理深度就是不同产品之间差异最大的区域。以下四个子维度建议逐一验证： 数据标准落标：不少产品都宣称"支持数据标准管理"，但关键在于标准的定义和执行之间有没有打通。验证方法是：选一个业务字段（如物料编码），定义其命名规则和值域范围，然后接入一批包含不符合该标准的真实数据，观察系统是否能自动识别违规记录并生成稽核报告。落标稽核的本质不是"配了一条规则"，而是"规则自动执行了"。 数据质量闭环：质量检测怎么跑、跑完之后怎么办——这是选型评估中容易被略过但上线后最耗人力的环节。重要的验证方法是让厂商30分钟内完成一条完整的质量闭环：配置质量规则（如空值检查、值域校验、一致性检查）→ 接入测试数据 → 执行质量扫描 → 输出问题报告 → 从问题追溯到原始记录 → 生成整改工单。注意确认质检是旁路模式——数据正常入库，质检在旁路并行扫描，发现问题打标记、发告警，不阻断数据流转。 元数据与血缘：元数据能否自动采集（而不是需要手动逐表录入），血缘追踪能不能跨系统追溯从源表到指标的完整链路。需注意血缘关系有两种维护方式：平台内自动解析数据流转环节的输入输出关系；平台外操作（如外部脚本直写）则需在元数据界面手动补全。不存在"一键全自动"的血缘方案，但自动解析的覆盖深度差异很大。 主数据管理：选一个多源系统中编码不一致的业务对象（如物料、客户、供应商），验证归并冲突处理机制和变更后的自动分发能力。这是验证"管"环节能否真正落地的典型场景。 产品能力参照：龙石数据中台的治理模块中，落标稽核为标准定义后的自动执行机制；质量监测为旁路模式，数据照常入库，质检并行扫描，问题打标记并自动生成告警和整改工单；元数据自动采集无需逐表手工录入；血缘支持从源系统表到中台指标的跨系统追溯。 3. 数据安全与合规 数据安全不能仅看"支持分类分级"的文档描述，建议在POC阶段就做实际验证： 分类分级与敏感识别：导入一批包含敏感字段（身份证号、手机号、银行卡号等）的数据，验证系统能否自动识别并标记 信创适配：如果企业有信创要求，POC阶段就在实际信创环境（操作系统、数据库、中间件全栈）跑一遍，不只看兼容性列表。全栈信创环境（如麒麟/统信 + 达梦/人大金仓 + 东方通）下的安装部署和功能验证，本身就是一个有效的筛选测试 分权分域：在多租户场景下验证组织权限的精细化管控——不同角色的用户看到的资产范围、可执行的操作是否严格隔离 4. 资产目录与数据服务 "用"环节关注的是数据真正交付到业务手中的通路： 资产目录的业务化程度：打开资产目录，业务人员能不能用自然语言理解"这张表是做什么的"？还是只有技术表名和字段类型列表？ 自助用数：从搜索数据资产 → 在线申请 → 审批 → 获取数据，全流程是否在线化？业务人员是否可以不经过IT就能完成？ API 服务能力：发布一个数据API后，在高并发场景下的响应性能、鉴权与限流机制是否完善 5. 架构扩展性 数据中台不是一次性项目，选型时就要考虑三年后的扩展需求： 工作空间模型：是否支持"一集团一中台、一公司一空间"的多租户架构？总部统一管控标准和安全策略，子公司独立运营数据资产 模块化程度：各模块是否可以独立部署、按需组合？还是必须全量安装？从项目统计来看，多数企业的数据中台建设是分阶段推进的——先解决数据集成和基础质量，半年到一年后再扩展主数据和资产服务。模块化架构可以显著降低起步门槛 部署门槛：最低配置要求（CPU/内存/磁盘/操作系统）和实际部署周期（从环境准备到功能验证） 四、POC中容易被忽略的三件事 1. 层间联动才是真正的试金石 单层功能都及格不等于连起来能跑通。一个实用的验证场景是：从数据接入 → 自动触发质量校验 → 血缘关系自动生成 → 资产目录同步可见 → 发布为API → 在监控面板查看调用量，从头到尾一口气跑通。如果在某个环节需要手动干预或变通处理，说明各层之间是靠外部拼接而非内部协同的。 这不是性能测试，而是架构一致性测试——各模块之间的数据格式、状态传递、事件触发是否在底层就设计为一致。 2. 服务模式：厂商是交付完就走还是持续陪跑？ 数据中台不是买个软件装上就能用的标准化产品。从项目交付到团队自主运营，中间有一段相当长的过渡期。选型时值得考察厂商在交付后的支持模式：有没有系统化的培训体系（不仅仅是产品操作手册）？有没有实战陪跑机制（厂商专家进入项目现场，和客户团队一同在真实业务场景中推进）？ 衡量标准可以很朴素：项目结束一年后，企业的数据团队能不能脱离厂商独立运营数据中台？ 龙石数据的"产品+培训+陪跑"模式可作参照：培训分三层——理论层（DCMM、DAMA和理采存管用方法论）、实施层（怎么启动、怎么推进）、实战层（在培训环境中动手完成数据归集、标准配置、质量规则开发等）；陪跑则是龙石专家进入客户现场，选一个真实业务域，由客户团队操作、龙石指导，目标不是"帮你把数据治好了"而是"你们自己能治了"。 3. 团队能力匹配：不要选一个接不住的产品 某中型汽车零部件企业的选择值得参考：初期选了一款功能覆盖很广的平台，但数据团队只有三个人，结果上线半年后大部分模块仍处于闲置状态——不是产品不好，是团队暂时接不住。后来调整策略，从单一模块起步逐步扩展。 选型时对团队能力的自我评估至少包括：专职数据人员数量、已有技术栈（熟悉哪些数据库/开发框架）、过往数据项目经验。如果团队尚在建设期，从模块化产品起步、先跑通数据集成和质量监测两个最紧迫的模块，是一种较为稳妥的做法。 五、三个真实场景的POC对照 以下三个案例来自龙石数据中台实际项目经验，可作为不同侧重点的POC验证参考： 场景一：主数据管理深度 华东某建筑装饰集团旗下两百余家子公司使用不同的ERP系统，同一物料在三个系统中分别叫"镀锌钢板""热镀锌板""DX51D+Z"，采购、库存、财务各执一词。POC阶段的验证用例设计为：选取一批跨系统的物料数据，要求厂商在测试环境中完成编码映射、冲突归并、统一编码、变更自动分发到下游系统的完整流程。这个场景同时验证了标准落标、主数据归并和分发机制三个关键能力。 场景二：异构数据集成 + 标准先行 某化工企业的MES、ERP、CRM系统长期各自独立运行，数据字段命名和编码体系各成一套。POC测试聚焦两个验证点：一是在不修改源系统的情况下完成多源异构接入（包括Oracle、SQL Server和一套遗留的工控系统导出文件），二是接入后自动执行字段级标准校验，输出的稽核报告能否准确定位到不合规的具体记录和字段。这个案例中，厂商是否在接入数据之前就引导客户先建标准体系，也是一个值得观察的信号——标准先行的厂商通常对治理的落地路径有更清晰的认知。 场景三：集团架构扩展性 某国控集团要求数据中台支持"总部统一管控+子公司数据自治"的多层架构。POC验证重点放在工作空间模型上：创建总部和各子公司的独立空间，验证总部能否统一设定安全策略和数据标准，子公司能否在自有空间内独立管理数据资产、配置质量规则，同时关键数据按策略自动归集到总部空间。这种"可分可合"的架构能力，对集团型企业而言比单一实例的性能指标更有参考价值。 六、POC检查清单 POC阶段 必验项目 验证方法 判断标准 数据集成 多源异构接入 用实际业务环境中最复杂的异构链路测试 数据接入完整，字段类型映射正确 数据集成 批流一体 全量同步+增量采集混合编排 延迟和吞吐量满足业务时效要求 数据标准 落标自动稽核 定义字段标准 → 接入不合标数据 → 验证稽核报告 自动执行，非手动触发 数据质量 旁路监测闭环 30分钟内完成建规则→跑监测→出报告→追溯→工单 全流程无阻塞，数据照常入库 元数据血缘 自动采集与追溯 接入业务表 → 检查血缘自动生成和跨系统追溯 覆盖主要数据库类型，追溯深度≥3层 主数据 冲突归并+分发 同一对象多名称→合并→变更分发到下游 分发机制可靠，支持审批流程 数据安全 分类分级+信创 导入含敏感字段数据 + 信创环境全链路验证 自动识别敏感数据，信创环境无兼容问题 资产服务 资产目录+自助用数 业务语言搜索→在线申请→审批→获取 业务人员可独立完成，不需IT介入 架构扩展 工作空间+模块化 多租户分权分域+模块独立部署验证 权限隔离严格，模块可按需组合 服务模式 培训+陪跑 考察厂商交付后的能力转移机制 有系统化培训和实战陪跑方案 七、FAQ Q1：POC阶段应该投入多长时间？ 通常以一到两周为宜。其中数据集成和三个核心治理模块（数据标准、数据质量、元数据）建议各安排不少于一天的深度验证。不必在厂商"半天演示+半天答疑"的快节奏里匆忙决策——POC的目的是让选型团队有足够时间用自己的数据去验证，而不是看厂商安排好的流程。 Q2：开源方案能否纳入POC对比？ 可以，但需在同一评估维度下对齐。开源方案在功能灵活性和无许可成本方面有优势，但对团队技术能力的要求较高——通常需要五人以上的专职数据工程团队才能有效维护。如果企业数据团队以业务人员为主，商用产品的易用性和厂商支持的时间成本优势会更明显。具体选择取决于团队构成，而非产品本身的好坏。 Q3：厂商如果不配合真实场景测试怎么办？ 这本身就是一个有效的筛选信号。愿意配合企业用真实业务数据做端到端验证的厂商，通常对产品的工程化成熟度有足够信心（旁路监测是否真的不阻断、血缘是否真的能跨系统追溯——这些不用真实数据跑一遍是看不出来的）。只愿意走标准Demo流程的厂商，交付后可能面临类似的问题：标准功能都可用，但一遇到企业的实际数据环境就需要"等版本升级"。 Q4：中小企业预算有限，POC重点看什么？ 建议优先验证最紧迫的两个模块，通常是数据集成和质量监测。从项目统计来看，多数中小企业数据治理的首要痛点是"数据在哪不清楚、数据质量没把握"，先解决这两个问题再逐步扩展到主数据和资产服务，是较为务实的路径。市面上已有部分产品（如龙石数据中台）支持模块独立部署、单台服务器即可起步，部署周期约一周，可以降低初期投入。不必为暂时用不到的功能买单。 参考来源 [1] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0） [2] 中国信通院，《数据治理产业图谱3.0》 [3] DAMA International,《DAMA数据管理知识体系指南》（DAMA-DMBOK 2.0） [4] GB/T 36344-2018《信息技术 数据质量评价指标》 [5] 龙石数据，数据中台产品，https://www.longshidata.com/products/government.html
华东某建筑装饰集团总部的月度经营分析会上，财务总监翻开各子公司报送的 Excel 报表，眉头越皱越紧——同一个"石材采购成本"，三个子公司的口径完全不一样。有人按合同价算，有人按实际结算价算，还有人把运费一并摊了进去。"我们每个月花一周时间收报表、对数字，最后发现连项目到底赚不赚钱都说不清楚。" 这不是个案。200 余家子公司、近百个在建项目部，年产值超过 200 亿元——规模越大，成本数据的"散"和"乱"就越致命。 建筑装饰行业天然是项目制运作，材料采购、劳务分包、施工结算分属不同系统，数据源头多、口径杂。很多企业把问题归结为"ERP 不够好"，但实际情况更底层：当同一个物料在三个子公司有三种叫法时，任何分析系统都只能得到混乱的输入。 一、项目成本透明化的三道坎 坎一：主数据"各说各话" 同一装饰材料，华东子公司叫"大理石A级"，南京子公司叫"A类石材"，总部采购系统叫"石材_01"。供应商名称也是各自编码——甲公司的"供应商A"，在乙公司的系统里是另一个编号。连"谁花了多少钱"都算不清，跨公司调拨、结算频繁出错，每月对账需要大量人工干预。 这不是孤例。一批脱敏行业案例显示，集团型企业的主数据混乱几乎是"标配"——物料编码不统一、供应商信息不一致、项目部命名不规范。表面上是编码问题，实质是缺乏集团级数据标准体系和统一的认责机制。从行业实践来看，多数企业的主数据治理项目并非输在技术选型上，而是输在跨部门、跨子公司的组织协同上——编码谁定、标准谁维护、冲突谁裁决，这些看似基础的问题长期没有明确答案。 坎二：业财数据"两张皮" 预算在总部成本系统，实际费用在子公司财务系统和项目台账中，两者脱节。项目完工后才发现超支，却无法追溯到超在哪里、因谁而起。集团整体毛利率逐年下滑，但总部说不清是哪个环节出了问题。 业财"两张皮"的根源不是系统没打通，而是数据口径不一致。同一个"项目成本"，预算部门用含税价、财务部门用不含税价、项目部按实际支出记账——三套口径，对不上一张表。 坎三：集团管控"看不透" 总部无法实时获取各公司的收入、成本、回款、毛利率等核心指标。每月经营分析会前，财务部门要花一周时间从各子公司收 Excel，口径不一、真假难辨。集团在做重大决策时，依据的是"手工汇总、层层上报"的滞后数据。管理层对此的感受是：规模越大，对一线的感知反而越弱。 二、诊断：为什么上了 ERP 成本还是不透明？ 上述三道坎指向一个共同根因：缺乏统一的集团级数据标准。 很多建筑装饰企业认为自己缺的是更贵的 ERP 或更强的 BI 工具。但实际上，问题不在工具数量——该集团旗下已上线 OA、ERP、项目管理、供应链、财务等多个系统。核心瓶颈在于，供应商与物料编码在 200 余家子公司间互不通用，集采优势无法发挥；项目成本数据滞后，集团无法穿透式洞察底层经营风险。 一个直观的判断标准：如果财务部门每月的核心工作之一是"给各子公司发 Excel 模板、催收、汇总、核对"，那问题大概率不在系统上，而在数据标准上。 业界公认的数据治理方法论——理采存管用——将数据治理分为五个阶段，"管"正是其中承上启下的核心环节，这一方法论与 DCMM（GB/T 36073-2025）[1]对数据战略、数据治理、数据标准等能力域的定义高度对应。主数据管理、数据标准管理、数据质量管理，解决的都是"数据不一致、读不懂、信不过"的问题。而在管环节中，主数据管理通常被视为第一优先级：先让"谁是谁"有唯一答案，后续的质量稽核和经营分析才有根基。 三、过程故事：最难的不是技术，是拉通三个部门 回到华东这家建筑装饰集团的真实过程。 2024年项目启动后，龙石顾问团队对集团的核心系统进行了全面调研。调研结论很快形成：数据底座的技术选型和平台搭建不是难点，真正的挑战在于主数据标准的统一。而这个挑战，"出人意料地不在技术上"。 以装饰工程中常用的石材为例：在 ERP 系统里用的是采购编码，在项目管理系统中用的是设计图号，在施工子公司的材料台账上用的是仓库自编号。三个部门——采购、设计、施工——各说各话，谁也不愿意改自己的编码体系。 项目组联合三个部门，在会议室里逐一拉通核心物料编码。过程比预想的困难得多：采购部门认为自己的编码最完整，设计部门强调图号是行业标准，施工部门则说"我们在工地跑了十年，就认这个编号"。最终花了近三周，才将第一批核心物料的编码规则定下来。 这个过程的教训很明确：不是技术问题，是组织问题。 编码谁定、标准谁维护、冲突谁裁决——这些看似基础的事，在长期的组织惯性中一直没有被解决。当企业习惯了"各部门各管各的数据"，再先进的平台也只是在混乱的数据上盖了一层漂亮的界面。 四、解决方案：主数据先行 + 分级底座 + 穿透式管控 基于诊断结论，团队为该集团设计了三层递进的治理方案。 统一核心实体编码。 针对物料、供应商、项目部三大核心主数据实体，制定集团统一的编码规范与认责机制。清洗历史数据，整合为唯一的"黄金记录"。建立主数据分发服务，确保 200 余家子公司、近百个项目部共用同一套数据语言。需要说明的是，清洗存量数据是一个无法跳过的阶段——这项工作看似耗时、见效慢，但如果跳过它直接在旧数据上建看板，相当于在不同口径的数据上强行做汇总，结果只会放大误差。正如行业中另一个脱敏案例所揭示的，"物料主数据是集团型企业数据治理的第一关"，集中采购、供应商评价、成本分析，全部依赖于这一步的质量。 搭建多租户数据底座。 采用"物理集中、逻辑隔离、分层授权"的架构：在集团层面部署统一的数据中台，为每家子公司创建独立的数据空间，项目部则配置轻量级场景空间。总部负责基础设施和数据标准，子公司在本空间内自主开发和管理，项目部按需使用。这一架构同时满足了两个看似矛盾的需求——总部的合规管控和子公司的业务敏捷。 上线穿透式成本看板。 基于治理后的高质量数据，构建经营驾驶舱和项目成本看板。管理层可从集团全局视角一键钻取至任一具体项目，实时查看预算执行、实际成本与毛利偏差。当成本超支达到预设阈值时，系统自动触发红线预警并推送至相关负责人——成本管控从"事后审计"转向"事中预警"。 五、赋能体系：让自己会治 方案落地不仅是技术部署。团队为该集团设计了"培训+陪跑"的赋能模式。 培训集中在公司进行，而非客户现场——让关键用户脱离日常工作环境，系统性地掌握方法论和平台操作。陪跑阶段，顾问进入客户现场，选择一个真实业务域，与客户团队一起推进——但角色有明确分工：顾问指导，客户操作。每一步都是客户团队动手完成，目标是"你们自己能治了"，而不是"我们帮你把数据治好了"。 这种模式的底层逻辑是：集团型企业的数据治理不是一次性项目，而是一项需要长期运营的能力。平台可以部署，标准可以制定，但如果团队不具备持续维护的能力，三年后的数据质量会回到原点。 六、效果：四个可量化的改变 以下数据来自该项目上线后的实际运营统计。 从花一周对账到一天自动结算。 项目前，每月跨公司对账需各子公司财务人员手工核对，耗时约五天。项目后，全集团实现物料、供应商、项目部"一物一码"，跨公司调拨材料时系统自动匹配编码，结算对账时间缩短至一天，数据纠纷减少约八成。 从事后核算到事中预警。 项目前，成本分析依赖月度报表，完工后才能判断盈亏。项目后，成本看板实时对比预算与实际，超支项自动预警。项目经理在施工过程中即可调整用工和采购计划，而非等到结算时才发现问题。 从总部"盲人摸象"到一屏全览。 项目前，总部管理层对各子公司经营状况的感知依赖层层上报的 Excel。项目后，经营驾驶舱上线，管理层可随时查看各子公司的收入、成本、毛利率、回款率等核心指标，并下钻到具体项目。 从要数据层层审批到子公司自主创新。 子公司利用独立数据空间，快速开发了"项目经理绩效考核看板"等应用，项目平均工期明显缩短。用子公司一线人员的话说："以前要数据得层层审批，现在自己就能搞定。" 该集团管理层在项目总结时评价："以前开经营分析会，数据全靠各分公司人工报送，真假难辨且滞后严重。现在通过数据中台，我们坐在总部就能看清全国上百个项目的实时成本与合规情况，实现了靠数据说话、靠数据管理。" 七、启示 这个案例的价值，超出了建筑装饰这一个行业。 第一，集团型企业数据治理的第一关是主数据。 物料编码不统一，成本分析就是沙上建塔。当"同一物料三种叫法"成为常态，任何 BI 工具、任何分析模型都无法给出可信的结论。从行业实践看，先解决"谁是谁"的问题，再谈"谁怎么样"，是比较稳妥的推进顺序。 第二，穿透不是替下级做决策。 集团管控的目标不是把子公司的每一笔支出都管死，而是让总部和子公司站在同一套数据上对话。当双方看到的是同一个数字、同一套口径，争论的就不再是"你的数对不对"，而是"我们该怎么改善"。这种转变本身，比任何技术指标都更有价值。 第三，存量数据的清洗不可跳过。 在多个脱敏案例中都能看到类似的规律：企业倾向于先把平台搭起来、看板做出来，历史数据"后面再说"。但实际情况是，看板一旦上线，业务部门的第一反应往往是"这个数不对"——因为底层的旧数据口径根本没拉齐。清洗存量数据看似慢，实则是唯一的快。这一点与 GB/T 36344-2018（数据质量评价指标）[2]的核心理念一致——数据质量是分析结论可信度的前提，跳过质量治理直接上分析，本质上是在不可靠数据上做决策。 成本透明化的本质，不是装一套新系统，而是建立一套全集团可信、统一、可穿透的数据基础。《"数据要素×"三年行动计划（2024-2026年）》[3]明确提出"推动数据要素在工业制造、建筑等重点行业领域的深度应用"，建筑装饰行业的成本数据治理恰恰是这一方向的典型落地场景。市场上已有部分数据治理平台（如龙石数据中台）围绕主数据管理、数据标准管理和质量稽核构建了完整的治理能力体系。但工具终究是工具——决定成败的，始终是组织有没有决心把"各说各话"变成"同一种语言"。 常见问答（FAQ） Q1：集团型建筑装饰企业的主数据治理一般需要多长时间？ 主数据治理的周期取决于两个变量：实体范围和跨组织协同效率。以本案例为参照，涉及物料、供应商、项目部三大核心实体的主数据标准制定与存量清洗，在 200 余家子公司规模下耗时约 3 至 4 个月。其中编码规则的制定和跨部门拉通占整体时间的一半以上——纯技术工作（清洗脚本、数据映射工具）往往只需几周，但组织共识的达成需要反复沟通。建议企业将主数据治理纳入集团级专项，由分管副总裁牵头，避免将其降级为信息化部门的单部门任务。 Q2：中小型建筑装饰企业是否也需要做集团级主数据管理？ 没有"200 家子公司"不等于不需要主数据管理。只要存在以下任一情况，主数据治理就是刚需：① 同一物料在不同系统中编码不一致；② 项目部与总部之间的成本数据口径不一；③ 跨项目采购比价时无法确认"买的是不是同一种材料"。中小企业可以从核心物料（如大宗装饰材料：石材、木饰面、涂料）和核心供应商两类实体切入，编码规则不必一步到位覆盖全品类——先统一采购量前 20% 的物料编码，通常就能覆盖 80% 以上的采购金额。 Q3：数据治理平台上线后，如何确保长期有效运营而不是"用两年就荒"？ 这是集团型企业数据治理最常见的"折旧"问题。本案例中的做法提供了两点关键经验：一是"培训+陪跑"的赋能模式——项目期间系统性地培养关键用户的平台操作和标准维护能力，确保顾问撤离后企业能自主运转；二是将数据质量纳入了相关岗位的绩效考核——数据标准不是"一次性建设成果"，而是需要持续维护的运营能力。当主数据的新增、变更、停用有明确的责任人和流程，并且这些责任人的绩效考核与之挂钩时，数据质量的持续改善就有了制度保障。 参考来源 [1] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0） — openstd.samr.gov.cn [2] GB/T 36344-2018《信息技术 数据质量评价指标》 — openstd.samr.gov.cn [3] 国家数据局等，《"数据要素×"三年行动计划（2024-2026年）》，2024年1月 — gov.cn
CFO在企业微信上@了数据团队负责人："财务部在推进数据资产入表，需要一份集团现有数据资产的清单——下周五之前能给出来吗？" 数据团队负责人打开手头的系统看了看：充电、支付、调度……几十个系统上散落着上千张表，同一类充电桩数据在三个系统里有三种命名规则。他回了一句："我尽量。" 这不是虚构场景。华东某交投集团启动数据资产入表时，面临的第一个问题就是这个——"家底"到底是什么。 一、入表的第一个关口：不是会计处理，是资产盘点 很多企业把"数据资产入表"理解成一个会计问题——财务部牵头，审计师确认，年底前走完流程就行。但从实际执行来看，入表的全流程六个环节中，前三个——资产盘点、资产登记、质量评价——本质上都是数据治理工作，和会计分录几乎无关。 一个基础判断逻辑是：元数据能不能自动采集、数据标准有没有统一、质量问题能不能量化、资产目录编不编得出来——这四个条件加起来，基本决定了企业距离"入表就绪"还有多远。四个条件少一个，到了审计环节就可能被退回。 这个判断逻辑也和政策走向一致。DCMM 2.0（GB/T 36073-2025）[1]将"数据资产"新增为独立能力域——从"有没有治理"到"能不能资产化"，标准本身也在跟进企业的实际需求。配合财政部财会〔2023〕11号《企业数据资源相关会计处理暂行规定》[2]的落地，入表已不再是政策空转，而是国企财务合规的实质要求。 但在讨论"怎么入表"之前，需要先回答一个更基础的问题：企业的数据家底到底是什么样的。 二、家底一团乱：入表之前的三道坎 华东某交投集团的IT基础设施并不差——充电系统、支付系统、调度系统、用户服务平台，几十个业务系统常年运行，积累了海量数据。但启动入表时，项目组发现要迈过的坎不在会计技术上。 坎一：资产底数不清。 上千张业务表分散在不同数据库中，没有一份完整的资产清单。充电桩数据分散在三个系统里，各自有不同的命名规则——有的叫"桩状态"，有的叫"充电设备信息"，有的沿用开发文档里的内部代号。没人能对着CFO说清楚：集团到底有哪些数据、分布在哪里、哪些具备资产属性。 坎二：质量参差不齐，无从量化。 这批数据一直在支撑业务运转——支付系统跑着、充电桩运营着，表面上没什么问题。但从来没有做过系统性质量评估。哪部分"干净"、哪部分存在缺陷，只能靠经验判断。会计师事务所提出的要求是明确的：入表数据需要有可审计的质量依据。企业拿不出来。 坎三：流程复杂，缺乏统筹经验。 资产盘点、合规审核、质量评价、价值评估、会计确认——这五个专业领域横跨IT、法务、财务、评估多个部门。此前集团从未完整跑通过一次全流程，各部门之间的衔接标准和工作语言都不统一。 顾问团队进场后的第一个判断是："先不谈入表，先把家底盘清楚。" 三、从翻Excel到自动扫描：资产盘点的完整过程 "家底盘清楚"这句话听起来简单，但落到操作层面，是从上千张表中梳理出"一本清账"的系统工程。 全量扫描：不是从零开始手工整理。 如果靠人手工打开每个数据库，逐一登记表名、字段、数据量，上千张表的盘点周期可能要以月计。项目组借助数据中台的元数据自动采集能力，对各业务系统做全量扫描——上千张表、数万个字段，系统自动识别表结构、字段类型、数据量、更新频率。很多企业在这个过程中第一次发现：同一个充电桩的数据，在三张表里以三种结构共存。 业务规则筛选：划定入表边界。 自动化扫描解决了"有什么"的问题，但入表需要的不是一张全量清单，而是"哪些具备资产属性"。项目组和业务部门逐一确认：充电订单数据——直接产生收入，纳入入表候选；系统运行日志——运维辅助，暂不入表；用户支付流水——可量化、可估值，纳入入表。最终从上千张表中识别出充电订单、支付流水、用户档案、对账记录等核心数据资源。 形成资产目录：给出"一本清账"。 筛选完成后，项目组将每一项数据资产标准化——业务含义、覆盖范围、更新频率、质量状态逐一明确。最终产出一份《企业数据资产目录》，让业务人员用业务语言就能理解数据资产，也让CFO和审计师有了一份可以审阅的正式资产清单。从"IT部门自己维护的Excel"变成了"管理层可以讨论的资产台账"。 四、有了目录还不够：质量评价为入表"上保险" 资产目录给企业提供了一个清晰的盘点结果，但入表还需要一个更严格的步骤——让数据质量变得可以量化、可以被第三方审计。 项目组以GB/T 36344-2018《信息技术 数据质量评价指标》[3]为框架，对拟入表数据进行全量自动化质量扫描。标准定义了六个评价维度：规范性、完整性、准确性、一致性、时效性、可访问性——直接影响入表数据的可信度。 扫描结果并不意外：订单状态字段存在不规范填写，部分时间字段与实际业务操作存在偏差，不同系统的支付渠道代码不一致……这些问题在日常业务中可能不影响使用——订单照付、充电桩照常运营——但在审计师眼里，任何质量缺陷都可能成为"数据不可信"的依据。 借助自动化质量评价工具，项目组对发现的问题分类打标、推动修复。修复后的数据再次扫描，最终质量评价总评分达到99.53分（满分100分），会计师事务所据此确认质量符合入表要求。从"从来没评估过"到"99.53分"，这一步为后续估值和会计确认提供了量化底线。 五、生态协同：入表不是一家能做完的事 数据质量评价只是入表链条中的一个环节。完整的入表需要六个专业角色协同作业：资产盘点→资产登记→质量评价→合规审核→价值评估→会计入表，各环节成果相互印证。 在这个项目中，龙石数据承担了质量评价环节，同时联合律所和会计师事务所、资产评估机构，以生态协同的方式提供全链条服务——律所依据质量报告完成合规审查，资产评估机构基于质量和合规结果进行价值评估，会计师事务所最终完成入表确认。 这种模式回应了一个行业现实：企业推进入表时，最头疼的问题之一就是"找不到能一站式完成的单一服务商"。数据质量评价、法律合规审查、资产评估、会计确认分属四个专业领域，任何一个环节缺失或脱节，链条就断了。生态联合的意义不在于"一家公司什么都做"，而在于"各环节有人兜底、成果互认"。 六、首批入表之后：资产化管理才刚开始 经过全流程推进，华东某交投集团成功将符合条件的支付类数据资源纳入企业资产负债表，数据资产首次获得了合法的会计身份。这也是该省某市首批完成数据资产入表的国有企业实践。 比"入进去了"更重要的，是"能持续"——形成《企业数据资产目录》和筛选标准之后，这套方法和工具可以直接复用到其他业务线，大幅降低未来的重复投入。入表不是一次性的突击任务，而是资产管理能力的一次检验。 从更长的周期看，入表后的数据资产具备了可量化价值，为质押融资、资产证券化等金融创新提供了基础。企业的角色，从"数据持有者"向"数据资产经营者"演进。 复盘整个项目，有一个结论值得留意：入表最终能顺利通过，不是因为评估方法有多精妙，也不是因为会计处理有多复杂——而是前面的资产盘点和标准统一走扎实了。这一步没人能代劳，也没人能跳过。 结语 入表不是会计部门的独角戏，但也不意味着每个企业都需要像案例中的交投集团那样一步到位全量铺开。对于还在观望的企业，有三个思路可以参考。 先盘点，再谈标准。 如果还不知道自己有什么数据，定标准容易做出一堆没人用的规范。用资产盘点先把范围画出来，后续的标准建设、质量治理才有明确的靶子。 选一个高价值域先跑通。 不需要像上千张表的规模——从一到两个核心业务域起步，产出一份小范围的资产目录和质量基线。跑通一个闭环，比在全量维度上反复论证更有说服力。 把能力建在平台上，不是Excel里。 资产盘点、质量评价、目录管理——这些工作如果每次入表都靠手工从头做一遍，入表的常态化就无从谈起。市场上已有部分数据中台产品（如龙石数据中台）将这些能力沉淀为平台级的核心功能，元数据自动采集、质量自动化扫描、资产目录管理不再是"入表项目专属"，而是可以持续运作的治理基座。 FAQ Q1：数据治理做到位了，就一定能入表吗？ 不一定。治理是必要条件但不是充分条件。数据质量不过关，估值无从谈起；标准不统一，资产边界就划不清——这些取决于治理扎实程度。但入表本身还需完成资产确认、合规审核和价值评估。准确的理解是：治理到位是入表的前提，入表是治理成果在财务层面的确认。 Q2：中小企业资源有限，怎么启动数据资产盘点？ 不需要全量铺开。选一到两个核心业务域，花几周时间做资产盘点加质量基线。关键是先把家底摸清楚——这和企业规模无关。如果缺少工具，可以先用免费的数据质量评估工具做一次全量扫描，了解数据的质量基线再做规划。 Q3：资产盘点和数据治理应该先做哪个？ 先盘点。用盘点先摸清家底，再判断哪些数据值得投入治理资源。如果反过来——还不知道自己有什么数据就开始定标准、建模型——容易做出一堆没人用的规范。从多数成功案例来看，较为稳妥的做法是盘点先行、治理跟进、入表自然接续。 参考来源 [1] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0） — openstd.samr.gov.cn [2] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号），2023年8月 — gov.cn [3] GB/T 36344-2018《信息技术 数据质量评价指标》 — openstd.samr.gov.cn [4] 龙石数据，数据中台产品，https://www.longshidata.com/products/government.html
一所211大学的老师想做一个简单的跨部门数据分析——比如学生成绩与图书馆借阅记录的关联——需要走纸质申请、找多个处室盖章审批，周期按天计算。这不是个例。在相当多的高校，数据不是"资产"而是"孤岛"——它们被锁在各个业务系统里，彼此隔绝，取之不易。 很多高校以为自己缺的是新系统，实际上缺的是一个能让数据流动起来的中台底座。 一、高校信息化的"繁荣"与"割裂" 经过多年信息化建设，一所普通高校通常积累了数十个业务系统：教务、科研、人事、学工、资产、一卡通……每个系统都有自己的数据库，建的时候各管各，跑起来互不相通。表面上看系统齐全，但跨部门的数据协作往往退回到最原始的方式——手工导出Excel，邮件传来传去，一个口径能对出三四个版本。 这种"繁荣"下的"割裂"，集中体现在三个层面。 不通。 各系统数据独立存储，跨部门的分析需求靠人工拼接。教务想知道各学院经费使用效率，科研处想评估实验室设备利用率，都需要找人、等审批、对口径——周期动辄数天甚至数周。 不准。 同一个学生在教务系统、一卡通系统、学工系统中的学号、姓名、院系字段可能不一致。缺乏统一的数据标准，跨系统数据关联时"对不上号"是常态。 不全。 大量线下行为数据——实验室使用情况、校园能耗、图书馆入馆记录——没有被系统化采集和沉淀，游离在数据资产之外。 更棘手的是老旧平台的困境。不少高校的早期数据平台已超出原厂维保期，核心组件超期服役。系统偶发的同步异常可能直接影响一卡通充值、财务结算、教务选课等核心业务。运维高度依赖原厂，学校信息化部门面对新需求响应迟缓，智慧校园的蓝图卡在了数据底座的"老化"上。 二、从"功能上线"到"数据运营"：一个211大学的破局之路 江苏一所211大学面临的就是这样的局面。该校原有的公共数据平台建成多年后，逐渐从"支撑者"变成了"绊脚石"——核心组件超出原厂维保期，系统稳定性下降，同步异常直接影响一卡通、财务、教务等核心业务的顺畅运行；架构封闭导致运维高度依赖原厂，故障处置滞后；数据资源分散、缺乏统一的资源地图，师生申请和使用数据的流程繁琐、体验割裂。 2023年，项目启动后，龙石顾问团队进场做了全面诊断。核心判断并不复杂：学校不是缺业务系统，而是缺一个架构开放、运维自主、服务敏捷的新一代数据基座。旧平台的"黑盒式"交付模式，让信息化部门既管不住数据、也接不住需求。 围绕"平滑迁移、能力升级、体验革新"三个目标，项目团队制定了四步方案。 架构重构与平滑迁移。 方案采用分层解耦的五层架构——基础设施层、业务来源层、贴源汇聚层、数据治理层、数据应用层——确保系统高内聚、低耦合，易于扩展维护。经充分评估，保留了承载海量核心业务且运行稳定的 GaussDB 200 数据库，规避大规模数据迁移风险；同步替换升级了原有的数据集成与治理平台，新建数据探查编目、数据超市等核心能力模块。迁移不走"一步到位"——数据、流程、接口按优先级分批推进，每批次迁移后设置一至两周监控观察期，确保核心业务零感知、无中断。 全域数据探查与标准化治理。 通过数据探查与编目系统，自动盘点各院处的业务数据，形成全校统一的数据资源清单，彻底摸清家底。利用多表归集和批量归集流程开发，将教务、科研、人事、学工、资产、一卡通等分散异构数据规范高效地汇聚到统一数据资源中心。再借助可视化数据开发套件——涵盖清洗、加工、流程编排——对入仓数据进行标准化治理，沉淀为高质量、可复用的核心数据资产。这一过程对标 DCMM（GB/T 36073-2025）[1]数据标准与数据质量域的能力要求，确保治理成果可评估、可复现。 数据服务化与自助消费。 建设面向全校的数据超市与数据网关：数据超市以"商品货架"形式清晰陈列可共享的数据资源、API服务与产品，师生通过菜单点选或API调用即可自助申请标准化数据；数据网关提供API的自动化配置、生成与全生命周期管理，支撑跨部门服务高效流通与安全管控。数据从"找人审批"变成"即取即用"。 智能化运维保障。 监控中心实现从主机、数据库到数据归集与开发任务的全景一体化监控，支持自定义CPU、内存、任务耗时、记录数等关键阈值。异常发生时，系统通过微信、短信、邮件等多渠道自动告警并附带详细原因，运维模式从被动应对转向主动保障。 实施分三个阶段推进：底座搭建与平稳迁移→能力建设与体验提升→深化运营与持续赋能。每一阶段验收通过后才进入下一阶段，不求快，求稳。 项目中一段插曲值得记录。龙石顾问进场后发现，最大的阻力出人意料地不在技术上——各部门对"数据共享"的顾虑才是第一道坎。教务处担心数据被"拿去考核"，后勤处疑虑"数据出去了还能不能管得住"。项目组没有硬推，而是先以校领导最关心的几个跨部门指标为牵引——各学院经费使用效率、跨部门审批平均耗时——用数据超市的第一个试点让各部门看到共享的价值。数据摆出来、效果看见了，阻力自然消解。 三、从"数据中台"到"一表通"：让数据服务师生 数据底座建好之后，变化是具体且可量化的。 跨部门数据申请从"天/周级"协调缩短为"分钟级"在线自助获取。过去老师申请一个跨域数据集，平均需要跑 3 至 5 个处室、填若干张表、等各级审批——周期按天算，短则 3 个工作日，长则超过两周。现在登录数据超市，搜索、申请、审批、获取，全程在线，平均 10 分钟内即可完成。 更深层的变化体现在"一表通"场景的落地。项目上线运行一年后，"一表通"已覆盖学生奖助学金申请、教师职称评审、新生入学信息核验、毕业生离校手续等 12 个高频业务场景。过去学生申请一项奖学金需先后跑学工处、财务处、后勤处开具 5 份证明，现在系统自动调取成绩、消费、宿舍等数据，一键生成申请表。教师职称评审时，科研成果、教学课时、社会服务数据自动汇聚，填报从平均 3 天的重复劳动变成半小时的核对确认。据学校信息化部门统计，"一表通"上线后，师生对信息化服务的满意度较之前提升了超过 40 个百分点。 信息化部门的角色也发生了根本转变。用该校项目负责人的话说："过去老师申请个数据，得跑断腿、磨破嘴、盖遍章；现在数据底座升级成了'超市'，动动鼠标就像逛淘宝，几分钟搞定。这不光是系统的焕新，更是我们这帮人从数据存储仓库升级为数据资产运营平台。" 四、启示：高校数据治理的三条经验 回看这个211大学的建设历程，有三条经验对面临类似问题的高校具有普遍参考意义。 不贪多求全。 一所高校几十个业务系统，不可能一口气全部打通。较为务实的做法是先挑教务和学生两个核心域——与教学和人才培养直接相关的数据，覆盖面最广、业务价值最高。把核心域的数据跑通、用起来、见到效果之后，再逐步扩展至科研、人事、资产等其他域。一上来就铺大盘子，容易在漫长的建设周期中消耗掉各方的耐心。 数据服务化是关键。 建数据中台不是为了"存数据"，而是为了让数据流动起来、被师生用起来。数据超市和API网关的价值不只在技术上统一了出口，更在于降低了用数门槛——从"找人审批"到"自助获取"，这个体验上的跨越，是数据中台被学校各部门真正接纳的分水岭。这一理念与教育部《教育信息化2.0行动计划》[2]中"推动从教育专用资源向教育大资源转变、从提升师生信息技术应用能力向全面提升信息素养转变"的方向一脉相承。 组织协同比技术更硬。 高校的组织架构是典型的条块分割，每个处室、每个学院都有自己的数据主权意识。技术平台搭得再好，如果各部门不愿意把数据拿出来共享，中台就是空壳。从这个211大学的经验看，以校领导关注的跨部门指标为牵引，让各部门在共享中先看到收益，比用行政命令"硬推"有效得多。IT部门搭台、业务部门唱戏，数据治理才能真正从项目变成常态。 高校智慧校园建设的下半场，比拼的不是上了多少系统，而是数据能不能真正"跑起来"。当数据从孤岛走向融合、从成本中心走向数字资产、从IT部门走向每一位师生，智慧校园的承诺才算落了地。"数据二十条"[3]明确的数据产权结构性分置和数据要素市场化配置方向，为高校数据资产的激活与流通提供了制度性指引——数据不仅需要被治理，更需要被作为资产进行管理和运营。 常见问答（FAQ） Q1：高校数据中台与传统的共享数据中心有何本质区别？ 传统共享数据中心的核心逻辑是"把数据搬到一个库里"，解决的是存储集中问题。数据中台的核心逻辑是"让数据可治理、可复用、可服务"，解决的不只是"存"的问题，更是"治"和"用"的问题。具体差异体现在三个层面：一是中台自带数据治理能力（标准管理、质量稽核、资产编目），传统中心库通常不具备；二是中台通过数据超市和API网关实现"数据服务化"，师生可自助获取而非依赖IT部门手工导出；三是中台采用分层解耦架构，可在不中断业务的前提下完成平台升级和组件替换——这正是本案例中江苏某211大学能够平滑迁移旧平台的关键。 Q2：一表通服务的建设需要哪些前提条件？周期通常多久？ 一表通不是孤立的应用功能，而是数据治理成果的自然产物。其前提条件包括：① 核心业务域数据已完成标准统一和入仓（教务、学工、人事、科研等）；② 跨系统数据已建立关联映射（学号/工号作为主键打通各系统）；③ 数据质量已达到可自动汇聚的水平。在本案例中，以上前提条件的建设耗时约 6 个月（含平台迁移），一表通首批场景（学生奖助学金申请）在底座上线后 2 个月内投入使用。整体从项目启动到一表通覆盖 12 个场景，周期约 12 至 14 个月。 Q3：高校数据治理如何平衡数据共享与隐私保护？ 这是高校数据治理中最敏感的议题，也是本案例中项目推进的最大阻力来源。该校的做法提供了三层防护：一是明确数据分级分类——涉及师生个人身份、成绩、消费等敏感数据的共享须经脱敏处理，仅限特定角色在审批后访问；二是数据网关的权限管控——每条数据服务的调用都需经过认证、授权和审计，可追溯到每一次访问记录；三是"最小必要"原则——一表通场景中仅调取与该业务直接相关的数据字段，不过度汇聚。这三层机制让各部门在"看得到管控"的前提下愿意共享数据，是在高校体制内推进数据融合的现实路径。 Q4：老旧高校数据平台迁移有哪些关键风险？如何规避？ 老旧平台迁移的最大风险不是技术兼容性，而是核心业务中断。本案例的应对策略是"分批迁移+监控观察期"：数据按业务域分批迁移，每批次上线后设置一至两周监控观察期，确认一卡通、教务选课、财务结算等核心业务无异常后再推进下一批次。此外，保留运行稳定的底层数据库（本例中为 GaussDB 200）作为过渡，避免一次性大规模数据搬迁引发不可逆风险。对于承载核心业务的老旧组件，建议保留至少一个完整学期的并行观察期后再执行下线。 参考来源 [1] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0） — openstd.samr.gov.cn [2] 教育部，《教育信息化2.0行动计划》，2018年4月 — moe.gov.cn [3] 中共中央、国务院，《关于构建数据基础制度更好发挥数据要素作用的意见》（"数据二十条"），2022年12月 — gov.cn [4] 龙石数据，数据中台产品，https://www.longshidata.com/products/government.html
采购计划员拿到两份报价单：供应商报的是"钛白粉R996"，仓库的领料单上写的是"R-996"，到了配方系统里，它又变成了"996"。同一个东西，三个名字。为了确认这三份单据指向同一种原料，他花了半小时打电话、翻台账——而这半小时，只是制造企业每天无数个"对名字"动作里的一个。 一物多码不是编码问题，是治理问题。物料编码是制造业数据的"身份证"，编码不统一，采购、库存、成本、质量、供应链分析全部对不上。对正在建设高质量数据集、推进AI应用的企业来说，这个问题更紧迫：实体标识不统一，数据集就无法构建，AI模型也无法稳定解析——把各系统数据"拉出来堆在一起"只是数据集建设的第一步。一物多码的背后，涉及物料分类、编码规则、数据责任、历史清洗、跨系统分发五个层面，任何一个层面缺位，治理都会落空。 一、一物多码：制造业数据治理的第一道坎 制造业是系统密度最高的行业之一。ERP管采购和财务，MES管生产执行，WMS管仓储，PLM管研发设计，配方系统管工艺……每个系统都有一份自己的物料档案，编码规则却各自为政。同一种物料，采购系统按供应商名称编，设计系统按图纸号编，车间按自己的习惯编。久而久之，"一物多码"与"多物一码"并存——前者是同一个物料对应多个编码，后者是不同物料共用一个编码，两条线都在污染数据。 三个场景能说明一物多码的代价。 集中采购推不动。 某大型综合制造集团的采购中心曾长期面临一个尴尬：各子公司报上来的采购需求用的是各自的物料编码，采购中心要先花大量时间"翻译"——哪些是不同的物料，哪些是同一个物料叫了不同的名字。等翻译完，采购窗口也过了。集中采购的规模优势，就这样被编码差异一点点吃掉。 成本核算对不上。 同一类原材料，A子公司记在"原材料-化工类"，B子公司记在"辅料-生产用"，C子公司干脆没分类。集团想做全集团的物料成本分析，第一步是"认谁是谁"，而这个工作量几乎是天文数字。 批次追溯难。 跨系统的物料批次无法自动关联，追溯靠人工映射。一家精细化工企业曾有类似的经历：一批产品出现质量波动，质量部门要把原料批次、工艺参数、检验记录手工串起来找原因，一次批次数据整理要花半天。 很多制造企业以为自己缺的是系统，实际最大瓶颈往往是数据无法形成统一链路。再先进的MES、再漂亮的看板，底层物料编码对不上，跨系统的数据就关联不起来。在数据管理能力成熟度评估（DCMM 2.0，GB/T 36073-2025）[1]中，数据标准域的能力项——业务术语、主数据、参考数据、数据元、指标数据——指向的正是这套基础工作；DAMA-DMBOK 2.0[3]也把参考数据与主数据管理列为数据管理的基础能力领域。行业里普遍把主数据管理归入治理体系的"管"阶段：物料、客户、供应商等核心实体统一了，数据才谈得上管得住、用得好。需要说明的是，制造业场景中数据管理能力看DCMM，智能制造能力看CMMM（GB/T 39116-2020），两者各有侧重，主数据治理属于前者。 对AI应用而言，这一关更关键。智能采购、供应链预测等场景的第一步，是跨系统关联数据——历史采购量、库存、价格、供应商、质量表现——而关联的前提，是所有系统对同一物料使用同一标识。一物多码不解决，AI读到的"同一个物料"是几个不同的名字，预测和推荐都会失真。GB/T 36344-2018[2]定义的六个数据质量评价维度中，规范性、一致性等维度直接决定模型能否稳定解析、跨系统能否准确关联，一物多码恰恰破坏了这些维度，使数据集达不到"可训"的标准。主数据与数据标准，是AI应用的数据底座。 二、一个典型场景：钛白粉的三个名字 具体到一家企业，一物多码长什么样？华东某精细化工企业（流程制造，年产能超20万吨，生产环保涂料、树脂及助剂）的经历很有代表性。 这家企业的同一原材料"钛白粉"，在采购系统里叫"钛白粉R996"，在配方系统里写成"R-996"，到了质检系统又被简化为"996"。三个系统，三个名字，数据源头各不相同。设备编号同样混乱：DCS里的反应釜编号，与MES工单里的设备字段对不上。主数据不统一，批次追溯时无法自动关联物料批次和设备参数，大量工作靠人工映射。前面提到的那次"半天整理一次批次数据"，就发生在这家企业。 龙石顾问进场后的第一判断很直接：流程制造的数据治理，必须从主数据开始。物料编码不统一、设备编号不一致，后续的批次追溯、工艺分析都会遇到严重障碍。企业需要先为每一类原材料、每一台设备、每一道工序建立统一的数字身份，才能谈批次关联、参数分析和智能优化。 这并非孤例。某大型综合制造集团的情况如出一辙：ERP物料主数据重复率高，"一物多码"与"多物一码"并存，采购、库存、生产、财务模块的数据因编码不一致无法关联。集中采购"翻译"各子公司清单、成本核算"认谁是谁"，问题比精细化工企业更大——几十套编码体系并存，物料数据总量达到数十万级。 三、怎么治：从标准、清洗到分发 治理路径说起来不复杂：统一标准、唯一标识、持续运营。做起来，每一步都有讲究。 先是梳理核心主数据实体。这家企业从原材料、中间体、成品、设备、工序、计量单位入手，制定统一的业务术语与编码规则，并明确每种主数据的归属部门——物料编码谁维护、改了通知谁、历史记录谁认，这些问题在项目一开始就要有答案。出乎意料的是，项目最大的障碍不在技术，而在"理"：跨部门认责。编码规则的技术实现很快，但让采购、生产、质检各自让渡一部分"命名权"，需要一轮轮沟通。 然后是清洗历史数据。采购、生产、质检系统中的记录被逐条比对，合并为唯一的"黄金记录"，并建立编码映射表，让新旧编码在过渡期内共存。这一步漫长且不可跳过。某大型综合制造集团在治理时专门走过四段：摸清家底、建标准定规则（覆盖数十个大类、数百个小类）、清洗数据（数十万条物料逐条比对、去重、重新编码）、系统固化。参与项目的负责人说过一句话："这一步不完成，后续所有工作都是空中楼阁。"同样走完这条路的华东某电子制造企业，其物料数据量已达百万级，清洗去重后采购、生产和财务才真正用上了"同一本账"。 再往后是跨系统分发。当技术部新增一种原材料时，编码自动同步至ERP、MES、LIMS，所有系统使用同一标识。数据在源头一次录入，向各系统分发，而不是每个系统各自维护一份——这正是"唯一数据源"原则的落地。 在统一主数据的基础上，企业建立了"原料批次—生产工单—反应工序—工艺参数—质量检验—成品批次"的六层数据模型，为每个中间体、每道工序、每个质量指标定义统一编码与计量单位。某批次产品出现质量异常时，通过批次ID即可一键关联所用原材料批次、各工序、操作人员和检验数据。 治理成果在这一步开始转化为AI可用的数据底座：统一编码加上标准代码集、六层模型，使每批产品的原料、工艺、质检数据可以跨系统一键关联。质量波动分析、配方优化、采购预测等AI应用，从此有了干净的训练与推理数据。 这个过程里，平台工具承担的是固化工作。主数据管理模块完成编码统一、数据清洗与映射、跨系统同步；数据标准管理维护代码集与属性模板；数据质量管理负责唯一性校验——新增物料时自动校验是否已存在类似物料，避免重复编码继续累积——并以旁路监测方式并行扫描存量数据，不影响业务系统正常运行。集团型企业还可以借助"一集团一中台、一公司一空间"的工作空间模型，在统一标准管控与子公司自治之间取得平衡。 配套的还有能力转移。项目采用"培训+陪跑"的方式：培训阶段在龙石公司集中进行，理论、模拟、实操三层递进；进入现场的陪跑阶段，顾问团队选定一个真实业务域，与客户团队一起跑——指导归指导，每一步都由客户团队自己动手完成。目标不是"帮你把数据治好了"，而是"你们自己能治了"。 四、效果：从"对名字"到"一物一码" 治理完成后的变化，可以用几组前后对比来说明： 批次数据整理：从半天到几秒。* 批次追溯不再需要人工映射，系统自动关联原材料批次、设备参数、检验记录。 批次间质量波动（粘度、固含量）：降低40%。* 工艺参数标准化后，同一配方不同批次的指标趋于稳定。 客户质量投诉率：下降60%。* 批次一致性提升，质量不稳定引发的投诉大幅减少。 新配方研发周期：从6个月到3个月以内。* 基于历史批次的工艺参数与质量结果建立相关性分析模型，工程师能快速找到最优工艺区间。 外部案例验证了同样的逻辑。某大型矿业集团完成主数据治理后，"一物多码"问题基本消除，建立起覆盖数万条物料、上万条客户供应商的标准化代码库，集团层面的经营统计与财务合并有了统一的基础数据支撑。前述综合制造集团的集中采购物料匹配效率明显提升，跨子公司的成本核算口径实现了统一。 客户原声最有说服力："过去我们的生产更多依赖经验，配方调优靠试错，质量波动难以解释。现在通过这套体系，把每一批产品的原料、工艺参数和质量结果都串联起来，很多问题可以用数据说清楚。" 治理成果还直接转化为AI场景的落地条件。智能采购：统一物料编码后，各系统、各子公司的采购需求按同一标识自动汇总，采购中心无需再"翻译"清单；基于统一的历史采购数据，价格比对、供应商评估、采购量预测有了可靠依据。供应链预测：六层模型打通原料批次—工单—质检链路后，历史消耗、库存、质量波动数据可跨系统关联，需求预测与排产预测不再是无源之水。此时再看高质量数据集建设：2024年初，《"数据要素×"三年行动计划（2024—2026年）》[4]把工业制造列为重点领域，高质量数据集正是该行动落地的基础工程——统一标识的物料主数据已成为智能采购、供应链预测等应用的可信底座，数据集建设从"拉数"进入"可信"阶段；数据治理成果（标准、质量、主数据）将原始业务数据转化为模型可直接使用的训练集，能节省70%以上的数据准备工作量。 五、三点启示 回顾这些案例，有三点启示值得同行参考。 先治主数据，再谈数据应用与AI。 物料编码不统一，上层分析是沙上建塔，智能采购、供应链预测更是无从谈起。主数据与数据标准是数据治理的第一道关口，也是AI应用的数据底座。很多企业急于建大屏、上AI，而底层编码尚未统一——先把基础打牢，后面的路会顺很多。 主数据管理的本质不是管控，而是服务。 它的核心价值是"唯一数据源"——让每个业务系统都能从一个可信源头获取标准数据。这个原则一旦确立，后续的系统集成和数据分析就能少走很多弯路。 一物多码的治理是持续运营，不是一次项目。 标准要有人维护，质量要持续校验，分发要形成闭环。组织与机制缺一不可：专责岗位、审批流程、校验规则，缺了任何一环，编码会重新乱回去。这也是为什么越来越多的企业把主数据治理纳入常态化运营，而不是当一次性项目做完就散。从实践看，"产品+培训+陪跑"的组合——平台负责固化规则，培训与陪跑负责让企业自己接得住——是让治理成果持续下去的一种稳妥方式。 治理之后，同一物料在所有系统中只有一个名字——这个"唯一名字"正是高质量数据集的最小单元。数据集建设从"数据汇总"走向"可信、可训"，AI应用才能从演示走向业务一线。对大多数制造企业来说，这一步从统一物料编码开始，是最稳妥的起点。 六、常见问题 Q1：一物多码和多物一码有什么区别？哪个危害更大？ 一物多码是同一个物料对应多个编码，表现为数据重复、对账困难；多物一码是不同物料共用一个编码，表现为数据混淆、统计失真。两者的危害侧重点不同：一物多码抬高对账和协同成本，多物一码直接扭曲成本与库存统计。都需要靠唯一性校验从源头控制——新增物料时自动比对是否已存在类似物料，把重复编码挡在入口之外。 Q2：治理应该从哪类物料切入？所有物料类型一起治吗？ 从业务影响最大的切入。原材料和关键物料通常最复杂，也最能见到效果，先跑通，再扩展到半成品、成品、备品备件。综合制造集团的经验是先治物料、再扩展客户、供应商、组织等其他主数据对象；矿业集团则选择优先做透对经营分析影响最大的几类主数据。小步快跑优于一步到位，用阶段性成果推动更大范围的覆盖。 Q3：存量数据清洗周期长，能不能先上系统再清洗？ 不建议绕开。清洗存量数据是系统上线的前提——很多企业绕开清洗直接上系统，结果系统上线后数据照样乱。把存量数据理清楚，看似慢，实则是唯一的快；配合编码映射表让新旧编码过渡期共存，可以降低清洗阶段对业务的影响。 Q4：主数据统一后，各业务系统要跟着改造吗？ 分阶段过渡。先建编码映射表，让新旧编码共存，再逐步推动各系统切换使用统一编码；分发机制确保新增数据源头唯一——源头一次录入，各系统同步获取，不需要每个系统各自维护一份编码档案。 Q5：单工厂、中小企业也需要做物料主数据治理吗？ 需要，只是颗粒度不同。只要有多个业务系统、有跨部门对账，就存在一物多码的风险。可以从一个核心物料大类、几条校验规则起步，不必一上来就搭全套体系；随着业务系统增多再逐步扩充。 Q6：一物多码治理和智能采购、供应链预测这些AI应用有什么关系？ 直接关系。AI场景的第一步是跨系统关联数据——历史采购量、库存、质量、供应商——而关联的前提是所有系统对同一物料使用同一标识。一物多码不解决，AI读到的"同一个物料"是几个不同的名字，预测和推荐都会失真，这正是GB/T 36344[2]一致性维度要解决的问题。主数据与数据标准治理的成果，就是AI应用的训练与推理底座。如果希望用工具把标准、清洗、分发、校验串成一条链路，部分数据治理平台已具备主数据管理能力（如龙石数据中台），可以从一个物料大类试点起步。 参考来源 [1] 国家市场监督管理总局、国家标准化管理委员会，《数据管理能力成熟度评估模型》（GB/T 36073-2025，DCMM 2.0），2025年发布，2026年7月1日实施 — openstd.samr.gov.cn [2] 国家市场监督管理总局、国家标准化管理委员会，《信息技术 数据质量评价指标》（GB/T 36344-2018）— openstd.samr.gov.cn [3] DAMA International. DAMA-DMBOK: Data Management Body of Knowledge (2nd Edition). Technics Publications, 2017. [4] 国家数据局等十七部门，《"数据要素×"三年行动计划（2024—2026年）》，2024年1月 — gov.cn
一位刚完成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）
