自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
引言：Gartner的镜与灯 Gartner魔力象限是全球企业软件选型中最具影响力的参考工具之一。它以"执行能力"和"愿景完整性"两个轴将厂商分为领导者、挑战者、远见者和利基者四类，为采购决策提供了一套标准化的比较框架。在数据管理、商业智能等领域，这份象限图几乎成为企业选型的"第一站"。 但它也是一面有视角限制的镜子。Gartner以全球市场为分析单元，其评估维度天然倾向那些在多国市场有布局、产品标准化程度高、能够支撑跨国部署的厂商。对于一家长三角的中型制造企业、一个中西部城市的政务数据平台、或者一个旗下有两百余家分子公司的建筑集团——这些在中国本土语境下大量存在的选型场景，Gartner的镜子里未必照得清楚。 Gartner自身也承认这一点。其调研显示，超过三分之一的企业机构对数据中台的可行性和适用性仍感困惑。问题不在于工具本身，而在于视角：选型不是选"全球最好"的产品，是选"最适合你的"产品。 本文尝试在Gartner魔力象限之外，从中国本土企业的实际需求出发，梳理一套更贴近本土语境的数据治理平台评估维度。 一、三个选型误区——为什么照着Gartner选可能水土不服 在讨论"该怎么选"之前，有必要先看看"容易怎么选偏"。根据我们在多个行业数据治理项目中的观察，本土企业在数据治理平台选型中，有三个反复出现的误区——而这些误区恰好与Gartner框架的不完全覆盖有关。 误区一：只看功能列表长度，不看治理深度。 很多选型团队会拉一张Excel，把候选厂商的功能模块逐一打勾。功能数量多的胜出。但数据治理平台的核心不是"有没有某个功能"，而是这个功能在多深的层面上与应用系统、业务流程、数据架构咬合在一起。数据标准落标只是"写了文档"还是"可在模块中配置质量规则进行稽核"？质量规则是"事后补救式跑个脚本"还是"数据入库时旁路持续监测"？同样的"数据质量管理"模块，落地深度可以相差一个数量级。Gartner象限评估的是厂商功能和市场覆盖，不会深入到某家本土企业的实际IT环境中验证治理闭环。 误区二：只看市场地位，不看架构能不能支撑你的多组织形态。 Gartner领导者象限的厂商，通常面向的是扁平化管理结构——一个企业一个租户。但中国本土企业大量存在"集团管控+分子公司自治"的多层组织形态。一个建筑集团旗下两百余家子公司，每家有自己的业务系统、财务口径和编码习惯。这类场景下，选型的关键不是厂商的全球市场份额，而是平台能不能提供"总部统一标准管控、子公司独立工作空间"的架构能力，以及平滑地从点到面扩展的组织扩展路径。 误区三：把选型当一次性采购，忘了后续的运营和团队能力建设。 Gartner象限主要评估产品本身，但数据治理平台的特殊性在于——交付上线只是起点，平台能否真正用起来，取决于团队有没有持续运营的能力。如果一个平台的功能很强大，但厂商在交付后只能提供工单式支持，企业内部没有建立起独立运维和质量持续提升的机制，那么平台大概率会在上线两三年后沦为"数据仓库2.0"——存了很多数据，但治理仍然靠人工。 识别这些误区本身，就是在建立一套更务实的选型视角。 二、一个本土化的五维评估框架 中国本土企业的数据治理平台选型，需要的不是再建一套与Gartner对标的全球性评估体系，而是一套能够在具体选型场景中"落地"的实用框架。这套框架的参照系有三个来源： DCMM 2.0（GB/T 36073-2025）：中国数据管理能力成熟度评估的国家标准，九大能力域覆盖了数据治理从战略到应用流通的完整链条。它是企业自评数据管理现状的标尺，也是选型时验证厂商能否补齐自身短板的依据。 DAMA-DMBOK：国际数据管理知识体系，提供了数据治理的完整知识地图，帮助选型团队理解"数据治理平台应该管什么"。 "理采存管用"方法论：龙石数据在多个行业项目中提炼的五阶段工程化方法论，将DCMM和DAMA的框架性指导转化为可执行的建设路径。 基于这三个参照系，结合本土企业的典型需求特征，我们提炼出五个评估维度： 维度 核心问题 选型追问 治理能力完整度 平台能否覆盖数据标准、质量、元数据和资产目录的闭环管理？ 标准落标是不是仅在文档层面？质量监测是旁路的还是侵入式的？ 架构开放性 平台能否兼容现有IT环境，能否支撑集团型多组织扩展？ 私有化部署是否灵活？接口开放到什么程度？工作空间隔离怎么实现？ 安全合规 平台是否满足数据安全法和信创环境的要求？ 分类分级是内置能力还是需要二次开发？信创适配覆盖多少环节？ 智能自动化 平台能否降低数据治理的人工依赖和维护成本？ 质量规则是手工配置还是自动推荐？AI能否辅助元数据识别和血缘解析？ 长期业务价值 平台能否帮助企业从"项目驱动"走向"能力自驱"？ 厂商是否提供培训和陪跑？是否有数据资产化的演进路径？ 这五个维度之间并非彼此独立。治理完整度是"管得住"，架构开放性是"接得上"，安全合规是"不出事"，智能自动化是"降成本"，长期价值是"走得远"——对任何一个维度的忽视，都可能在平台上线后的某个阶段暴露为系统性瓶颈。 市场上已有部分数据治理平台在实践这一思路。例如龙石数据中台以"理采存管用"方法论为骨架，将数据标准管理、质量稽核、元数据管理和资产目录打包为可按需装配的独立模块，每个维度对应的能力可以在具体选型中逐一验证。 下面，我们逐维展开。 三、维度一：数据治理能力完整度——不是"有没有"，是"落到多深" 数据治理能力完整度是五个维度中最基础、也最容易被"功能列表"掩盖的一个。评估这个维度，需要穿透功能模块的表层，追问三个核心能力：标准落地、质量闭环和资产可发现性。 数据标准：从文档到执行。 很多企业的数据标准是以Word文档或Excel表格的形式存在的——定义得很清楚，但在数据开发、集成和使用过程中无人参考。标准的价值在于"落标"，即标准的定义能够自动作用于数据流转的每个环节。选型时需要追问：平台是否支持字段级的落标稽核？标准变更后，下游链路能否自动感知？还是需要人工逐个修改？ 数据质量：从救火到持续监测。 传统的质量管控模式是"出问题→排查→修复→手工补一条规则"，是一种事后补救式的治理。更为可持续的做法是旁路监测——数据正常入库，质量检查在旁路并行扫描，发现问题后打标记、发告警、生成整改工单，不阻断正常的业务流转。这种模式既保证了业务的连续性，又让质量问题能够被持续发现和跟踪。选型时需要验证：质量规则的配置门槛有多高？支持多少种规则类型？规则是仅能手动编写SQL，还是支持可视化配置？ 元数据与资产目录：让数据可发现、可理解。 数据治理平台区别于传统数据仓库的关键能力之一，是它能够让业务人员自己找到数据、理解数据的含义。这需要元数据自动采集和血缘解析能力作为基础，再通过资产目录的门户形态，将技术元数据翻译为业务人员可理解的数据资产。选型时需要确认：元数据采集的覆盖范围（是否包含存储过程、ETL任务、报表等）？血缘解析的自动化程度？资产目录是否支持业务标签、自定义分类和权限管控？ 产品层面，治理四模块的闭环程度是评估的关键。数据标准、质量稽核、元数据血缘、资产目录四个模块之间的联动——标准定义驱动落标稽核，落标稽核的异常触发质量问题，质量问题关联元数据血缘定位根因，最终在资产目录中标记数据资产的可信度——这种咬合深度决定了平台能否走出"各模块各自为战"的局面。模块化设计让企业可以按自身业务节奏逐步装配，无需一次性为"全栈功能"支付溢价。 四、维度二：平台架构开放性——不是选一个产品，是选一个技术伙伴 数据治理平台不是一个孤立的系统。它需要对接企业现有的ERP、MES、CRM、SRM等几十套业务系统，需要在未来三到五年内承载业务规模和组织的增长，需要在信创环境下稳定运行。这三个需求归结为架构开放性这一个维度。 兼容集成：不应要求企业"削足适履"。 选型时需要考察平台的数据源接入能力——支持哪些数据库类型、文件格式和消息队列？对非标准接口的数据源，是否提供灵活的扩展机制？一个底线要求是：数据治理平台的引入，不应迫使企业对现有的业务系统架构做出大面积改造。 扩展性：从部门试点到集团推广。 本土企业的典型情况是：先在某个业务域做试点，见效后再逐步推广到全公司，最终覆盖所有分子公司。这就要求平台具备"从小做到大"的架构扩展能力，而非一开始就需要全量部署。 这里有一个典型案例。 案例：江苏某建筑装饰集团 旗下两百余家分子公司，每家使用独立的业务系统和财务口径，跨公司数据对账原来靠人工逐表比对，一轮全集团对账需要五天。引入数据治理平台后，通过"一集团一中台、一公司一空间"的架构模型，总部统一管理数据标准和质量规则，子公司各自在独立工作空间内管理本地数据和业务流程。跨公司对账时间从五天缩至一天，因数据口径不一致引发的业务纠纷减少了约80%。 这个案例验证的核心选型原则是：平台架构的开性，最终体现为"能否支撑你的组织形态"，而非"技术白皮书里列了多少个接口协议"。 五、维度三：安全合规与信创适配——从加分项到一票否决项 数据安全法和信创工程的推进，正在将安全合规从选型中的"加分项"变为"一票否决项"。评估这个维度时，需要关注的不是厂商的安全资质列表有多长，而是平台在三个层面上的安全能力是否内建而非外挂。 数据分类分级：是否在平台内置了分类分级标准模板？是否支持基于分类结果自动匹配脱敏策略和访问控制？如果分类分级需要二次开发或依赖外部系统，安全管控的时效性和完整性就会打折扣。 数据脱敏与访问控制：平台是否支持静态脱敏和动态脱敏两种模式？是否提供字段级、行级的细粒度权限控制？在多组织场景下，数据权限是否能够做到"同一张表对不同工作空间呈现不同视图"？ 信创适配的深度：不是看认证列表——国产操作系统、国产数据库、国产中间件的适配证书，几乎每家厂商都能拿得出来。真正的区别在于适配的深度：是全功能模块都完成了信创环境测试，还是仅核心模块通过了适配？在信创环境下，平台的性能损耗在可接受范围内吗？这些问题的答案，需要POC实测，而不是看一份资质清单。 六、维度四：智能自动化水平——降低持续治理的人工成本 数据治理如果长期依赖人工——手工梳理元数据、手工编写质量规则、手工排查数据问题——瓶颈不在平台功能，在人力规模。因此在选型阶段，平台的智能自动化水平，直接影响平台上线后三到五年的总拥有成本。 质量管控自动化：平台是否支持可视化配置质量规则？是否能够根据历史数据特征自动推荐质量规则？规则配置之后，监控、告警、工单、整改确认是否形成自动化闭环，还是每个环节都需要人工干预？旁路监测机制让质检与业务流转互不干扰，是自动化落地的关键能力。 AI辅助数据治理：随着大模型技术的发展，AI在数据治理领域的应用正在从概念走向落地。元数据自动发现和血缘解析不再完全依赖人工梳理；质量规则可以基于数据特征自动推荐；业务语义的自动识别让"一物多名"的识别不再依赖手工字典。选型时可以追问：平台是否集成了AI能力辅助元数据管理、质量规则推荐和业务语义映射？这些能力是装点门面的Demo还是可在生产环境稳定运行？ AI用数智能体是另一个值得关注的演进方向——当数据治理达到一定成熟度后，业务人员能否通过自然语言直接查询数据、自动生成分析图表，是衡量平台能否真正"降低用数门槛"的重要标志。 七、维度五：长期业务价值——从"项目交付"到"能力自驱" 数据治理平台的选型决策，影响的不是未来一年的IT预算，而是未来三到五年企业的数据资产积累方向。因此最后一个维度评估的是：平台能否帮助企业从"项目交付"走向"能力自驱"。 能力转移，不是功能交付。 很多数据治理项目在上线初期运行良好，但一旦厂商撤场、核心实施人员离职，平台的活力就开始衰减——新数据源无人接入，质量规则长期不更新，资产目录逐渐过时。根本原因在于：交付的是"产品功能"，而不是"治理能力"。 解决这个问题，需要厂商在交付产品的同时，提供能力转移的服务。市场上的一些实践——如龙石数据中台"产品+培训+陪跑"的模式——为企业提供了一个参考方向：培训建立认知（DCMM/DAMA理论→工具操作→样板工程实战），陪跑完成能力转移（厂商专家进入客户现场，指导客户团队在自己真实的业务场景中动手操作），最终目标是让企业团队具备独立运维和持续治理的能力。 这里有一个相关的案例。 华东某化工企业在引入数据治理平台后，从顶层成立了数据管理部，推动OT/IT数据融合。通过统一物料编码和标准管理，库存周转率提升了28%，订单交付及时率达到91%。但比这两个数字更重要的变化是：在项目交付一年后，该企业的数据管理部已经能够独立承接新的业务域数据治理需求，不再依赖厂商驻场。从"项目驱动"到"机制驱动"，这才是长期业务价值的真正体现。 数据资产化的演进路径。 数据治理平台的价值实现路径通常是递进的：第一步是让数据"可管理"（标准统一、质量可控），第二步是让数据"可发现"（资产目录、自助检索），第三步是让数据"可运营"（数据资产入表、数据服务化）。选型时，企业应着眼于平台是否具备支撑这个三阶段演进的产品架构和服务能力，而非仅仅关注当前阶段的功能匹配。 八、案例验证——两个真实项目看五维落地 上述五个维度如果停留在理论层面，选型时仍然难以把握轻重。以下两个真实项目（均来自龙石数据中台的实施案例）演示了不同行业、不同规模的企业在选型和落地过程中，五个维度分别起到了什么作用。 案例一：江苏某建筑装饰集团——架构开放性与治理完整度的协同 这家企业的核心痛点是集团管控与子公司自治之间的矛盾。两百余家子公司独立运营，总部缺乏统一的数据视图。在选型阶段，企业最关注的是架构开放性——平台能否在统一标准的同时，保障各公司的操作自主权？ "一集团一中台、一公司一空间"的工作空间模型，让总部层面的数据标准和质量规则能够自动下发，子公司的工作空间内数据自治、互不干扰。治理完整度维度上，先从主数据编码和跨公司对账切入，再逐步扩展到质量稽核和资产目录。这个案例说明，对于集团型企业，架构开放性是治理完整度的前提——如果架构不能支撑多组织形态，治理能力本身无从落地。 案例二：华东某化工企业——治理深度与长期价值的闭环 化工行业的特点是业务系统高度异构（DCS、PLC、MES、ERP等多个系统层级），且对数据实时性和可靠性要求极高。该企业在选型时非常明确：不追求功能数量，只关注"质量稽核能不能落到位"和"供应商走了之后自己能不能独立运转"。 项目从物料编码统一和库存数据质量切入，逐步扩展到全业务域的数据治理。库存周转率提升28%、订单交付及时率达到91%——这些业务层面的改善，验证的是治理完整度的落地深度。而数据管理部在项目交付一年后的独立运营能力，验证的是长期业务价值的兑现。 两个案例放在一起看，揭示了一个选型规律：五个维度不是同等重要的——企业应根据自身的数据管理成熟度和组织特点，确定当前阶段的核心维度和辅助维度。 九、选型清单与行动建议 将上述五个维度的评估要点浓缩为一套可操作的选型清单： 评估维度 关键追问 POC验证建议 治理能力完整度 标准落标到字段级了吗？质量是旁路监测还是事后补救？元数据采集覆盖多少环节？ 选一个核心业务域，从标准定义→落标稽核→质量规则→问题工单→整改确认走完一个完整闭环 架构开放性 能否支撑多组织形态？接口开放程度如何？从部门试点到集团推广的扩展路径是什么？ 在POC环境中部署多工作空间，验证权限隔离和数据视图隔离 安全合规 分类分级是否内置？脱敏策略是否自动化？信创适配覆盖所有模块还是仅核心模块？ 在信创环境中运行质量规则和脱敏任务的完整流程 智能自动化 质量规则可否视化配置？AI是否辅助元数据识别和血缘解析？ 拿一个真实数据源，现场演示自动采集元数据和AI推荐质量规则 长期业务价值 厂商是否提供培训和陪跑？数据资产化的演进路径是否清晰？ 要求厂商展示一个交付一年以上的客户案例，了解该客户的独立运营现状 三步行动建议： 先自评，再看产品。 在接触厂商之前，先用DCMM 2.0九大能力域做一次内部自评，识别数据管理的核心短板。带着"我们需要补充什么"的问题去选型，而不是带着"厂商能提供什么"的心态去听演示。 POC聚焦核心域，不求大而全。 选一个最紧迫的业务域做POC，走通"标准→质量→资产"的完整链路。不要在POC阶段试图覆盖所有功能模块——那会让评估失焦。 问对问题。 除了功能演示，追问厂商三个问题：① 交付一年以上的客户，独立运营率是多少？② 信创环境下的性能测试报告可以提供吗？③ 培训课程的结构和陪跑的时间节奏是怎样的？厂商对这些问题的回答质量，往往比产品Demo更能说明问题。 十、常见问题 FAQ Q1：Gartner魔力象限还有参考价值吗？ 有，但它更适合作为"全球市场格局的概览"，而非"本土企业选型的决策依据"。比较合理的做法是：用Gartner了解赛道全貌和头部厂商的全球布局，用本文的五维度框架做本土化适配性评估。两者不是替代关系，是视角互补。 Q2：功能多是不是说明平台更成熟？ 不一定。功能数量反映的是厂商的产品化投入，但不是选型的首要判断标准。一个覆盖了二十个功能模块但治理闭环走不通的平台，对企业的实际价值不如一个只做四个核心模块但每个环节都能落到底的平台。从实际经验看，选型时应先看"治理深度"，再看"功能广度"。 Q3：中小企业预算有限，五个维度都要严格评估吗？ 不需要。中小企业通常架构相对简单、组织层级扁平、安全合规压力与大企业不同，架构开放性和安全合规两个维度的权重可以适当调低。重点放在治理能力完整度（能否用有限的预算拿到"真正好用的核心治理能力"）和智能自动化（能否减少长期人工投入）上。如果团队规模小、数据治理经验不足，也可以优先考虑带有培训陪跑服务的模式。 Q4：信创环境怎么评估？不看认证列表看什么？ 三个验证点：① 要求厂商在信创环境中演示——不是点亮一个页面，而是跑完一个"数据源接入→质量规则配置→稽核任务执行→结果输出"的完整流程；② 询问信创环境下与标准环境下的性能对比数据；③ 了解厂商的信创适配是"全模块覆盖"还是"核心模块先行"，以及后续模块的适配时间表。 结语 Gartner魔力象限是一面镜子，照出的是全球市场的厂商格局。但对于一家具体的企业来说，选型不是看谁在全球排名最高，而是看谁能在你的IT环境中、你的组织形态下、你的数据管理成熟度阶段，真正让数据治理落地。 五个维度——治理完整度、架构开放性、安全合规、智能自动化和长期业务价值——提供的不是另一个版本的"最佳厂商排行榜"，而是一套你可以根据自身情况调整权重的评估语言。从这个意义上说，最终的选型决策不在任何魔力象限里，而在你对自身需求的理解深度中。 参考来源 [1] DAMA International, DAMA-DMBOK: Data Management Body of Knowledge（第二版） [2] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0） [3] 中国信通院，《数据治理产业图谱3.0》 [4] Gartner, Market Guide for Data and Analytics Service Providers [5] 《中华人民共和国数据安全法》（2021年9月1日施行） [6] GB/T 36344-2018《信息技术 数据质量评价指标》
如果你是一家国企的技术负责人，正在推进数据中台选型，供应商的演示很漂亮，功能列表很长，但你心里清楚——信创替代的时间表就在那里，数据安全合规的审查不会因为你"还在选型"而暂停。一次选型失误不只是项目失败，更可能意味着合规风险和一个三到五年内无法推倒重来的技术路线。 国企数据中台的选型逻辑，和一般企业有本质区别。民营企业的选型重点可能是性价比、生态兼容性、业务部门的满意度；而国企面前，有两道绕不过去的门槛：信创兼容性，与全链路数据安全。 一、国企数据中台选型的特殊性 国企是信创推进的主阵地。按照信创替代时间表，关键领域的信息系统需要在2027年前完成国产化适配[1]。数据中台作为企业级数据基础设施，连接着几十甚至上百套业务系统，其信创兼容性决定了整个数据链路能不能跑在国产化底座上。 与此同时，《数据安全法》[2]自2021年施行以来，数据分类分级保护制度已从"指导意见"进入实质执行阶段。对国企而言，安全合规已从"加分项"变为"一票否决项"——数据中台如果不能提供分类分级、全链路脱敏、安全审计等能力，在采购评审阶段就会被直接淘汰。 在数据制度建设层面，"数据二十条"[3]首次从顶层设计上明确了数据产权、流通交易、收益分配、安全治理四方面的基础制度框架，为国企数据治理提供了从"管好数据"到"用好数据"的政策路径。 还有一个容易被忽略的结构性因素：国企的组织形态。典型的国控集团旗下可能有数十家甚至上百家下属企业，管理层级多、业务板块杂，"穿透式监管"是硬性要求。这就要求数据中台具备集团级多组织适配能力——总部统一管控标准、子公司保有操作自治权，二者必须兼顾。 面对这些特殊约束，选型应该从哪些维度着手？以下六个维度，可以作为国企数据中台选型的评估框架。 二、信创兼容性：不只是"能跑"，而是全栈适配 很多厂商在信创适配上的表述是"支持国产化部署"。但"支持"和"适配"是两回事——前者意味着代码能在某个国产OS上跑起来，后者意味着在全栈信创环境下经过了完整的兼容性验证。 全栈信创适配需要覆盖四个层面：操作系统（麒麟、统信）、数据库（达梦、人大金仓、OceanBase等）、中间件（东方通、宝兰德等）、芯片架构（华为鲲鹏等）。任何一个环节存在兼容性缺陷，都可能在后续运维中成为性能瓶颈或故障点。 更重要的是，认证列表长不等于适配质量好。选型时应在POC阶段要求厂商在真实信创环境中完成全链路数据集成验证——从数据源接入到ETL转换再到数据服务输出，全流程跑在信创底座上，而不是仅在某个环节做一次简单的连通性测试。 市场上已有部分数据中台产品完成了全栈信创适配。例如龙石数据中台已通过麒麟、统信、达梦、人大金仓、OceanBase、华为鲲鹏等主流信创组件的兼容互认认证，累计获得9项兼容互认证明。但归根结底，认证是入场券，POC验证才是选型的真正依据。 三、数据安全：全链路而非单点 数据安全不是装一个防火墙模块就能解决的问题。在数据中台的语境下，安全能力需要贯穿数据采集、传输、存储、计算、输出全链路，任何一个环节出现盲区，就给了数据泄露可乘之机。 评估数据中台的安全能力，建议重点关注三个层次： 第一层：数据分类分级。 这是数据安全管理的起点。数据中台需要具备敏感数据自动识别能力，能够按照《数据安全法》[2]及行业标准对数据资产进行分级标记，让不同安全等级的数据走不同的处理路径。 第二层：全链路脱敏。 脱敏不能只发生在输出端。数据从采集入库的那一刻起，就应在存储层完成脱敏；在计算和分析环节，脱敏后的数据仍可参与运算；输出时再根据使用者的权限决定是否进一步脱敏。很多平台能做到"输出端脱敏"，但采集和存储环节的脱敏覆盖是薄弱环节。 第三层：分权分域。 国企的集团多级管控天然要求"总部统一标准、子公司独立自治"的数据治理架构。数据中台需要提供工作空间级别的隔离能力，让总部能够统一定义数据标准和安全策略，同时各下属企业在自己的空间内自主管理和使用数据，互不干扰。 龙石数据中台在这方面提供了参考实践：其内置的数据分类分级与全链路脱敏能力覆盖了从采集到输出的完整链路，工作空间模型支持"一集团一中台、一公司一空间"的架构，搭配八类精细化角色体系，覆盖数据从生产、治理到使用的全部人员的权限管控。 四、治理深度：区分"数据通道"和"数据底座" 很多数据中台把核心能力放在"汇聚"上——接得多、跑得快、可视化好看。但国企真正的痛点不在接入本身，而在于接进来以后：能不能统一标准、能不能管住质量、能不能追溯来源。 这里需要区分两个概念："数据通道"和"数据底座"。前者解决的是数据流动问题，把各系统的数据搬到一起；后者解决的是数据可信问题——标准统一、质量可控、血缘可追溯。国企的穿透式监管和数据驱动决策，依赖的是后者，而不是前者。 国际数据管理协会（DAMA）在《数据管理知识体系指南》（DAMA-DMBOK 2.0）[4]中，将数据治理定义为数据管理的核心职能领域之一，强调数据治理不是技术部门的"内务"，而是需要跨部门协同的企业级职能。这一理念对国企尤为适用——数据治理部门如果定位为IT下属团队，几乎不可能推动跨业务域的标准统一和质量稽核。 评估治理深度，可以从三个关键能力入手： 数据标准能不能自动落标。 很多企业建立了数据标准规范，但标准停留在文档里——实际上线后发现各系统该不统一的还是不统一。真正有效的标准管理，是系统能够在数据接入时自动校验是否符合已定义的标准，并将不达标的数据标出、阻断或告警。 数据质量能不能形成闭环。 "检测→告警→定位→整改→验证"五个环节缺一个就会漏掉。一些平台只做到检测和告警，但没有问题定位和整改跟踪能力，最终质量问题只是从一个"没人知道"变成了"知道了但没人改"。 元数据能不能跨系统追踪血缘。 当一份财务报告的数据对不上时，能不能从最终指标一路追溯到原始数据源，找到哪个环节出了问题？这要求元数据管理不只是采集表结构，而是能建立跨系统的字段级血缘关系。 根据DCMM国家标准（GB/T 36073-2025）[5]的数据管理能力成熟度评估框架，数据治理能力的关键衡量维度包括数据战略、数据治理组织、数据制度、数据架构等九大能力域。国企在选型时应评估数据中台对DCMM各能力域的覆盖度——不是追求"满分"，而是确保中台架构能支撑企业向更高成熟度等级演进。 以华东某国控集团的数据中台建设为例，其旗下有协同办公、财务、投资、产权管理、"三重一大"、人力、党建等10余套业务系统，数据标准缺失、指标口径不一。通过数据中台建设，建立了统一数据标准体系和自动化质量稽核系统，实现了财务数据填报错误实时检测、异常自动预警——业务人员工作量减少60%以上，同时实现了全级次穿透式监管。 五、平台架构与扩展性：从"单点可用"到"集团可管" 国企选型通常要考虑到三到五年的扩展需求。今天可能只是集团总部的一个部门在用，一两年后可能扩展到全集团几十家下属企业。如果平台架构先天不支持多组织扩展，后续要么重新选型，要么忍受高昂的改造代价。 建议关注两个架构层面的评估点： 工作空间/多租户模型。 这是集团级部署的刚需。总部需要能在统一平台上为不同子公司创建独立的工作空间，每个空间有自己的数据、用户和权限边界。总部的角色是制定标准、监控质量、统筹安全，而不是替子公司操作每一个数据任务。 模块化可装配。 国企的预算节奏和建设节奏通常分阶段。一期可能只做数据集成和标准管理，二期再加质量治理和资产目录，三期上智能分析。平台需要支持功能模块独立部署、按需装配，不强制全套上线，这样才能匹配分阶段的资金安排和业务节奏。 市场上已有数据中台产品在设计上考虑了这种需求。龙石数据中台的功能模块支持独立部署，从单台服务器起步到集团级多节点扩展均可平滑过渡；工作空间模型支撑"一集团一中台、一公司一空间"的架构，总部管控标准、空间内自治运营。 六、数据资产与共享服务：建好之后能不能用起来 数据中台建设的终极检验标准不是"能不能跑起来"，而是"业务部门用没用起来"。如果中台上线后，业务人员查一个指标还是得找IT部门提需求、等技术排期，那这个中台本质上只是换了一个地方存数据。 衡量数据中台"建好之后用不用得起来"，可以看两个指标： 数据资产目录是否真正"能用"。 不是做一个静态的资产登记页面，而是让业务人员能够像逛电商一样检索数据资产——按业务主题浏览、按关键词搜索、看清每个数据资产的来源、口径、质量评分、负责人，自助申请使用。 数据共享是否从"定制开发"转向"自助获取"。 传统模式下，新上一个监管应用需要IT团队为每个数据接口写几十行定制代码。有了数据中台后，标准化的API共享和目录共享应该成为默认方式——业务方在资产目录中申请，审批通过后通过标准API获取数据，无需额外的定制开发。 前述华东某国控集团在数据中台上线后，建立了可视化资产目录和API共享服务体系，监管应用无需定制开发接口即可直接调用标准化数据服务，让数据从"存着"变成了"用着"。 七、容易被忽视的第六个维度：服务模式 选型时大家习惯逐项比较产品功能，但国企数据中台的交付模式同样不可忽视。数据中台不是买软件——装完服务器、配好环境、跑通演示流程，项目就结束了。它是一个持续运营的过程，需要平台能力和组织能力的同步成长。 值得关注的是，项目结束一年后，客户的团队能不能独立运营。如果一两年后客户仍然高度依赖厂商的驻场支持，说明能力转移没有发生。对国企来说，数据治理的终局不是供应商持续驻场，而是企业自身具备了持续治理的能力。 好的服务模式应当包含两个环节：培训与陪跑。培训解决"知不知道怎么做"的问题——覆盖理论方法论（如DCMM[5]、DAMA[4]等标准认知）、工具操作（平台功能使用）和实战演练（真实业务场景模拟）。陪跑解决"能不能自己动手做"的问题——厂商专家进入客户现场，选择一个真实业务域，指导客户团队逐步完成数据归集、标准制定、质量治理、资产化运营的全流程，每一步都是客户团队动手操作，厂商在旁指导纠偏。 龙石数据的"产品+培训+陪跑"模式提供了一个参考：培训在龙石公司集中进行（理论→模拟→实操），陪跑则转入客户现场（龙石指导、客户操作），目标是让客户从"被服务"转向"自己能治"。 八、常见问题（FAQ） Q1：国企数据中台选型周期通常多长？ 从需求调研到最终签约，国企数据中台的选型周期通常需要3-6个月，大型集团可能需要6-12个月。这是因为国企采购流程需要经历需求论证、技术方案评审、POC验证、招标采购等多个环节。建议在正式选型启动前预留1-2个月做内部需求梳理和数据资产盘点，避免"边选边想需求"。按照国资委对央企国企数字化转型的部署要求[1]，选型应立足于3-5年的技术路线规划，而非仅仅解决当前痛点。 Q2：信创适配证书数量多就代表适配质量好吗？ 不一定。认证证书证明产品在实验室环境中通过了兼容性测试，但不能等同于生产环境的适配质量。选型时应关注三个实际指标：一是证书覆盖的组件是否包含你实际使用的技术栈（有些厂商的证书集中在少数几个组件上）；二是POC阶段是否能在真实信创环境下完成全链路数据集成验证，而不是单点连通性测试；三是已有客户中是否有同规模国企的长期稳定运行案例。中国信通院在《数据治理产业图谱》[6]中指出，信创适配正从"能用"向"好用"演进，适配质量而非适配数量才是选型的关键。 Q3：中小企业国企是否也需要全栈信创适配？ 这取决于企业的信创替代时间表和业务系统规模。按照信创替代的总体部署[1]，并非所有国企都需要一步到位完成全栈适配，但核心业务系统（涉及人财物、关键生产经营的系统）需要优先完成。对于系统数量较少的中小国企，可以先从数据库和操作系统的国产化适配入手，中间件和芯片架构的适配可以根据业务增长节奏逐步推进。关键是数据中台平台本身要具备信创兼容能力——即使当前不全部使用国产组件，平台架构也应预留信创迁移的技术路径，避免未来面临"推倒重来"的困境。 Q4：数据中台采购招标时，如何评估安全能力的真实水平？ 建议从三个角度交叉验证：一是审查厂商是否具备等保认证、密码应用安全性评估等合规资质；二是在POC阶段要求厂商演示完整的分类分级→脱敏→审计闭环，而非仅展示安全模块的界面截图；三是要求厂商提供不少于两个同行业国企客户的案例，并允许技术团队与客户方技术人员直接交流（而非仅通过销售转述）。《数据安全法》[2]已将数据安全责任明确到数据处理者，选型阶段的安全评估不到位，实施后出现安全事件的合规风险将由企业自身承担。 九、结语 国企数据中台的选型不能走"先看功能再对价格"的常规路径。信创兼容性决定了能不能建，数据安全决定了建了合不合规，治理深度决定了建了有没有用，平台架构决定了建了能管多久，资产共享决定了建了用不用得起来，服务模式决定了建完能不能自己走下去。 这六个维度中，信创与安全是底线——过不了这两关，其余都是空谈。治理深度和服务能力是上限——决定了数据中台在组织里到底是"又一个IT系统"，还是真正支撑决策和监管的数据底座。两种结果之间的差距，往往就在选型时的这六个评估维度上。 参考来源 [1] 国务院国有资产监督管理委员会，《关于加快推进国有企业数字化转型工作的通知》（2020年9月）及信创替代工作部署（2022年国资委79号文） [2] 全国人民代表大会常务委员会，《中华人民共和国数据安全法》，2021年6月10日通过，2021年9月1日施行 — npc.gov.cn/... [3] 中共中央、国务院，《关于构建数据基础制度更好发挥数据要素作用的意见》（"数据二十条"），2022年12月 — gov.cn/... [4] DAMA International，《数据管理知识体系指南》（DAMA-DMBOK 2.0），2017年（中文版：机械工业出版社，2020年） [5] 国家市场监督管理总局、国家标准化管理委员会，GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），2026年7月1日实施 — openstd.samr.gov.cn/... [6] 中国信息通信研究院，《数据治理产业图谱》，2023年发布
早上八点，化工企业的安全环保部值班室里，值班工程师面前摆着三块屏幕——DCS控制系统实时跳动着反应釜的温度与压力数据，CEMS在线监测系统显示着废气排放浓度曲线，MES生产执行系统里排列着当天的生产批次和工艺参数。三块屏幕都是正常状态，但工程师心里清楚：三套系统的数据彼此不互通。如果反应釜的温度出现异常波动，废气排放浓度是否同步变化？生产负荷调整后，能耗曲线和排放曲线之间是否存在规律性关联？这些问题，他需要手动从三个系统分别导出 Excel，拼在一起才能看出端倪——而这个过程通常要花掉一个上午。 这不是某一家化工企业的特殊困境。在化工行业中，安全、环保、生产三域数据的长期割裂，正成为企业从"被动应对"转向"主动防控"的最大障碍。 一、化工行业的"三座数据孤岛" 化工行业的信息化程度并不低。大多数化工企业已经部署了 DCS（分布式控制系统）和 SIS（安全仪表系统）来监控生产过程安全，部署了 CEMS（烟气连续排放监测系统）和 VOCs（挥发性有机物）在线监测来满足环保合规要求，部署了 MES、ERP、LIMS（实验室信息管理系统）来管理生产执行与企业资源。问题在于——这些系统是分批、分部门、分目标建设的，彼此之间没有设计数据互通机制。 具体来说，化工企业普遍面临"三座数据孤岛"： 安全域数据主要来自 DCS 和 SIS 系统，以秒级时序数据为主，涵盖温度、压力、液位、流量等工艺参数，以及可燃气体浓度、有毒气体浓度等安全监测指标。这些数据当前的主要用途是实时报警——当某个参数越过阈值时触发声光报警和连锁动作。但报警之后呢？工程师需要手动回溯相关工艺参数的变化趋势，判断是传感器误报、操作失误还是设备异常。跨系统追溯全靠人工经验。 环保域数据主要来自 CEMS、VOCs 在线监测和废水排放在线监测系统，以分钟级或小时级数据为主，涵盖二氧化硫、氮氧化物、颗粒物、COD（化学需氧量）、氨氮等排放指标。这些数据的主要用途是上报——定期上传至环保监管部门以满足合规要求。但很少有企业将这些数据用于内部分析：排放异常之前，工艺参数是否有前兆？不同产品、不同负荷下的排放特征是否有规律可循？数据的潜在价值被"上报即结束"的工作流程锁死了。 生产域数据主要来自 MES、ERP 和 LIMS 系统，涵盖生产批次、投料记录、质检结果、设备运行状态、能耗统计等信息。这些数据是企业经营管理的核心，但通常与安全和环保数据不在同一个分析平面上。当产品质量波动时，技术人员在 MES 里翻批记录，在 LIMS 里查质检数据，再去 DCS 里拉工艺参数曲线——三个系统、三种查询方式、三份手工对表结果。一个异常追溯通常耗时数小时，甚至因为数据关联链条中断而不了了之。 行业内有一个典型的场景：同一个反应釜，在 DCS 系统里的编号是"R101"，在 MES 系统里叫"REACTOR-01"，在环保监测系统里可能只是一个点位编号"P-023"。三种命名对应同一个物理装置，但系统之间不做映射。当安全报警指向"R101"时，环保系统不知道这是"P-023"，生产系统不知道这是"REACTOR-01"——三套系统各行其是，跨域联动的第一步就卡在了数据"认不出彼此"上。 许多制造企业的管理者以为，自己缺的是更多的监测点、更快的报警响应，但实际上面临的核心问题不是感知能力不足，而是感知到的大量数据没有被组织成可以有效分析的信息。 二、传统做法为什么拉不通三域数据？ 面对安全、环保、生产三域数据的割裂，企业并非没有尝试过整合。比较常见的做法包括：上报表工具做跨系统数据展示、建中间表做数据汇集、找 MES 厂商做系统间接口。但这些尝试大多止步于局部打通，很难形成三域联动的数据能力。根因有三层。 第一层：数据标准不统一。 这是最表层但也最难绕开的问题。化工企业内的装置、物料、工艺参数、排放指标，在不同系统中有着不同的编码规则和命名习惯。以某流程制造企业为例，一种名为"钛白粉 R996"的原料物料，在 ERP 系统里叫"R996-TB"，在 LIMS 系统里叫"TiO₂-R996"，在采购系统里是另一套编码——三种叫法对应同一种实物。物料编码尚且如此，设备编码、工艺参数编码、排放指标编码的混乱程度更高。 编码不统一带来的直接后果是：跨系统的数据关联无法自动化。每条关联路径都需要人工建立对照表，而化工企业少则几十套装置、多则数百套，手工维护对照表的工作量无法持续。 第二层：数据质量参差不齐。 化工生产环境下的传感器数据有其天然的不确定性——高温、高压、腐蚀性介质、电磁干扰，都会导致传感器出现断连、跳变或漂移。DCS 系统的历史数据中，温度测点突然从 180°C 跳到 2999°C（量程上限），或者连续 30 分钟停留在同一数值（传感器卡死），这些现象并不罕见。 如果不对原始传感数据进行质量稽核就直接用于分析，分析结果的可信度就大打折扣。而传统做法中，数据清洗通常是"用一次、洗一次"——每个分析任务都需要分析师自己写规则剔除异常值，不同人对"异常"的判断标准又各不相同。同一个测点的数据，安全部门用的是"剔除跳变后的五分钟均值"，生产部门用的是"剔除跳变后的瞬时值"——口径都不一致，分析结果自然无法对齐。 第三层：缺乏以"装置/批次"为核心的数据关联模型。 这是最深层的问题。化工生产具有明显的批次特征——一个批次的原料投入、工艺参数曲线、质检结果、排放数据、能耗数据，在物理世界是天然关联的。但在数据世界，这些信息分散在 DCS、MES、LIMS、CEMS、EMS（能源管理系统）五套甚至更多系统中，没有一套统一的数据模型将它们串联起来。 缺少这个关联模型，导致的后果是：当企业想知道"某批次产品的废气排放为什么高于平均水平"时，需要分别从不同系统提取原料信息、工艺参数曲线、设备运行记录、排放监测数据，再手工拼凑出可能的关联关系。这不是分析，是考古。 三、让安全、环保、生产在一个平台上对话 上述三个障碍，靠传统的点对点接口或报表工具无法根治。标准不统一、质量不可控、关联模型缺失，三个问题交织在一起，需要的不是更强的接入能力，而是一套系统性的数据治理路径。 某大型化工集团的实践提供了一个参照。该集团年产值超百亿，业务覆盖基础化工、精细化工及新材料，工厂内部部署了 DCS、SIS、MES、LIMS、ERP、CEMS 等多套系统，OT（操作技术）层与 IT 层长期割裂。2024年初，龙石顾问团队在项目启动初期进场调研后发现，该集团的海量传感器数据绝大多数仅用于实时报警——测点值越过阈值后触发声光报警和连锁动作，但报警之后的数据并没有用于趋势分析和风险预判。用项目负责人的话说："我们有一堆传感器的数据，但除了报警，没有别的用途。" 项目团队做的第一件事不是上平台，而是摸清数据家底。团队花了近三周时间，逐一梳理了集团核心工厂内安全、环保、生产三域涉及的全部数据源——DCS 测点数、SIS 联锁点、CEMS 监测因子、MES 批次记录、LIMS 质检项、ERP 物料主数据。梳理的结果之一是发现同一套装置在 DCS、MES、环保监测系统中存在三种不同的编码体系。这也是整个项目遇到的第一个意外挑战——出人意料地，最大的障碍不在技术对接上，而在主数据标准的统一上。 接下来是数据接入。团队建立了统一的工业数据底座，将 DCS 的秒级实时测点、CEMS 和 VOCs 在线监测的分钟级数据、MES 的批次级生产记录、LIMS 的质检结果、ERP 的物料与能耗数据，按各自的时效性要求和完整度要求分别接入。对于安全和环保数据，时效性是第一位的——温度测点延迟 10 秒可能就错过了异常捕捉的窗口；对于生产和能耗数据，完整性则更为关键——批次记录的缺失会直接导致追溯链条断裂。 数据治理环节是整个方案的中枢。团队以"装置 → 工艺参数 → 排放 → 能耗"为数据主线，统一了全厂的设备编码、物料编码和指标编码标准，解决了同一装置多个编码的问题。在此基础上，配置了数据质量的旁路监测规则——当 DCS 温度数据出现跳变（如瞬间从正常区间跳至量程上限）或 CEMS 排放数据出现断点缺失时，系统自动标记这些异常数据点，生成质量告警，但不阻断数据的正常入库和流转。这种"数据照进、质量并行"的方式，既保障了实时监控的连续性，也建立了质量问题的可追溯机制。 在数据底座和治理体系就绪之后，应用场景的构建就水到渠成了。团队构建了"反应釜温度/压力 → 废气排放浓度 → 能耗曲线"的三域联动分析看板。当 DCS 触发安全报警时，系统自动拉取该时段对应的 CEMS 排放数据和 MES 工艺参数曲线，在同一时间轴上叠加展示——工程师不再需要从三个系统分别导出数据手工对齐。此外，基于设备运行数据和历史故障记录构建了关键装置的异常预警模型，当工艺参数出现偏离正常运行区间的趋势时，系统提前发出预警，将干预窗口从事后拉回到事中和事前。 在整个落地过程中，团队发现，真正推动项目走下去的不仅是技术平台的上线，更关键的是企业自身数据管理能力的同步成长。该集团在项目期间成立了数据管理部，在各业务部门设置了数据管家岗位，并将数据质量的改善纳入了相关岗位的绩效考核。项目团队以"先培训、再陪跑"的方式——在公司集中进行理论与实操培训，再到客户现场由顾问指导、客户团队动手操作，目标是让企业逐步具备自主运维和扩展应用的能力。 四、基线变化：从被动应对到主动防控 数据三域融合带来的变化，在三个维度上都有清晰的 before/after 对比。 安全维度：从"报警后排查"到"异常前识别"。 项目前，DCS 报警触发后，工程师需要依次登录 DCS、MES、CEMS 三个系统，分别提取报警时段的数据，再在 Excel 中手工对表判断影响范围和可能原因。这个过程通常耗时两到四个小时，而报警后的黄金响应窗口往往只有几十分钟。 项目后，报警触发时系统自动关联该时段的环境排放数据和工艺参数曲线，在同一界面上呈现完整的异常画像。工程师可以在分钟级定位到报警的根本原因——是传感器故障、操作偏差还是设备异常。更关键的是，基于工艺参数的趋势偏离分析，系统能提前识别出那些尚未触发报警阈值但已在缓慢劣化的异常趋势，把应对的动作前置到事故形成之前。项目统计显示，从报警发生到完成影响范围判断的平均时间，从项目前的近三小时缩短到项目后的二十分钟以内。 环保维度：从"超标后上报"到"趋势中预警"。 项目前，环保数据的用途几乎仅限于合规上报。排放浓度超标后才发现问题，然后被动启动超标报告流程。排放异常与工艺参数之间的关系，靠有经验的工程师凭记忆和感觉判断，没有系统化积累。 项目后，排放数据与工艺参数在同一数据底座上打通。当排放浓度呈现持续上升趋势但尚未超标时，系统自动关联该时段的原料投料类型、反应温度和停留时间等工艺参数，提示操作人员可能的原因方向。例如，系统曾发现某产品的废气中氮氧化物浓度在正常范围上限持续运行，关联分析显示对应时段的反应温度偏高约 5°C——调整后排放浓度即回落至正常区间中位。这种"还没有超标，但趋势已经偏了"的洞察，在没有三域融合之前几乎不可能做到。 生产维度：从"经验调参"到"数据驱动优化"。 项目前，同一产品同一配方、不同批次之间的质量波动明显，但找不到系统性的原因。工艺参数调整主要依赖老员工的个人经验，配方优化周期长、试错成本高。库存周转率和订单交付及时率也因产销信息不同步而长期在较低水平徘徊。 项目后，基于六层数据模型（原料批次 → 工单 → 工序 → 参数 → 质检 → 成品）的全链路批次追溯成为可能。当某批次产品质量出现偏差时，可一键追溯到该批次的原料供应批次、各工序工艺参数曲线和质检节点数据。库存周转率提升了近三成，订单交付及时率从项目前的约七成提升至九成以上。更值得关注的是，工艺知识从"依赖老师傅的个人判断"逐步转化为"可查询、可复用的数据资产"——新员工不再需要从头摸索，而是可以在数据底座上对比历史最优批次的工艺参数组合。 五、启示：化工数据治理的三个"先于" 从这个案例中，可以提炼出几条对化工行业具有普遍参考价值的经验。 标准先于集成。 在尝试打通多系统数据之前，先统一装置编码、物料编码和指标名称的标准。编码不统一意味着每接入一个新系统就制造一批新的对照表，接入越多、混乱越多。统一主数据标准是跨域数据融合的第一步，也是工作量最大、最容易被跳过的一步。这一点与 DCMM 国标（GB/T 36073-2025）[1]中将数据标准作为数据治理基础能力的理念高度一致。较为稳妥的做法是，从安全环保这个"高价值、高紧迫"的场景切入，先拉通场景内涉及的核心系统和核心指标的标准，跑通后再逐步扩展覆盖范围。 质量先于分析。 传感器数据的完整性、准确性和一致性不解决，再先进的分析模型也是空中楼阁。国标 GB/T 36344-2018（数据质量评价指标）[2]从完整性、一致性、准确性等维度定义了数据质量的评价框架，化工场景下传感器数据常见的跳变、漂移、断连等问题，恰恰对应了这些质量维度的核心关切。旁路监测的方式——数据正常入库、质量规则并行扫描、发现问题打标记而非拦截——在化工这类对实时性要求高的场景中尤其适用。它既建立了质量问题的可见性，也不打断业务系统的正常运行节奏。市场上已有部分数据中台产品（如龙石数据中台）将这种旁路监测能力作为标准配置，企业可在平台选型时将其作为评估项之一。 场景先于平台。 从多数成功案例来看，化工行业的数据治理通常不宜追求一步到位的"全业务域、全系统覆盖"。从一个具体的、价值明确的小切口切入——比如安全环保联动——跑通之后再复制到能耗优化、设备预测性维护、产销协同等更多场景，是更务实的路径。一个场景的成功落地带来的组织信心和团队经验，比一份宏大的整体规划更有推动力。 该集团在项目过程中逐步意识到，数据治理不是一次性的平台上线，而是一项需要持续运营的组织能力。产品提供工具底座，而真正让数据持续产生价值的，是企业自身的数据管理机制和人员能力的同步成长。从"数据二十条"[3]对数据要素市场化配置的顶层设计，到 DCMM[1]对数据管理能力成熟度的体系化指引，政策与标准的双轮驱动正在为化工行业的数据治理提供前所未有的外部推力。 常见问答（FAQ） Q1：化工行业数据中台建设一般需要多长时间？ 以本案例中百亿级化工集团为参照，从前期调研、主数据标准统一、数据接入与治理，到首批场景（安全环保联动）上线，周期约 6 至 9 个月。其中主数据标准统一阶段耗费时间最长，通常占整体周期 30% 以上。规模较小的化工企业可适度压缩，但数据标准的拉通工作不应跳过。 Q2：中小型化工企业是否也有必要做三域数据融合？ 有必要，但不应照搬大型集团的"全量接入"模式。中小企业可以从一个最高频的痛点场景切入——例如仅打通关键装置的 DCS 安全数据与 CEMS 环保数据，先解决"报警后跨系统追溯"这一个问题。数据标准不用一步到位覆盖全厂，先统一场景内涉及的核心设备编码和关键指标即可。跑通一个小闭环的效果，远比一份大而全的规划更有说服力。 Q3：化工数据治理如何确保不影响正常生产？ 这是化工行业数据治理最敏感的问题。本案例中的做法提供了参考：数据接入采用"旁路采集"方式——通过标准工业协议（OPC UA、Modbus 等）从 DCS/SIS 系统的接口机读取数据，不直接触碰控制层网络。数据质量稽核也采用"旁路监测"模式——数据正常入库，质量规则并行扫描，发现问题打标记而非阻断流转。这种"数据照进、质量并行"的方式，确保了生产系统的连续性和安全性不受影响。 参考来源 [1] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0） — openstd.samr.gov.cn [2] GB/T 36344-2018《信息技术 数据质量评价指标》 — openstd.samr.gov.cn [3] 中共中央、国务院，《关于构建数据基础制度更好发挥数据要素作用的意见》（"数据二十条"），2022年12月 — gov.cn [4] 龙石数据，数据中台产品，https://www.longshidata.com/products/government.html
作者：小陆 说明：本文系基于Palantir官方技术文档、行业研究报告及公开媒体报道等公开资料，所做的综合性梳理与推演、探讨。 序章：历史性失败 2001年9月11日，美国梦破碎了，属于美国的20世纪画上了句号。 早晨，19名隶属于基地组织的恐怖袭击者劫持了4架民航客机，分别撞上了世贸中心双子塔、五角大楼，还有一架坠毁在宾夕法尼亚的田野。 这是一个屈辱的日子，文明灯塔骤然摇摇欲坠。然而主谋本·拉登未曾料到，他原以为联邦会在袭击后如苏联般支离破碎。9月14日，小布什总统站在废墟之上，喊出那句“那些推倒这些建筑的人，很快就会听到我们所有人的声音”，美国竟意外达成了前所未有的团结，总统支持率飙升至历史峰值。 历史的进程仿佛就此改写，美国正式开启了反恐战争。然而，这场战争并未如预期般速战速决。阿富汗战事绵延二十年，而那个名为奥萨马·本·拉登的元凶，却如同人间蒸发。 在美国情报系统的视野里，除了拉登偶尔发布的挑衅录像，他的名字变成了一堆散落的、难以追踪的碎片。这些碎片，如同双子塔倒塌时的尘埃，毫无意义，却日夜刺痛着美利坚最脆弱痛苦的神经。 2003年至2004年的911委员会听证会上，主席基恩与副主席汉密尔顿公开坦言：这或许本是一场可以避免的袭击。 一份迟来的报告——《911委员会报告》 *信息来源于《9/11commission report》 报告揭示了残酷的真相：由于情报处理系统的落后，美国多次错失良机。数据并非匮乏，而是无法拼接。911的预警信号如同写在白纸上的字迹，静静地躺在美国多个互不相通的数据库里，却无人能将它们拼凑成完整的情报。 致命的失误（五个场景） 场景一：明尼苏达的电脑 2001年8月，明尼苏达州潘姆飞行学院，教官们对一个名叫扎卡利亚·穆萨维的中东学员感到不安与怀疑——他几乎没有大型客机驾驶基础，却希望直接接受波音747模拟机训练。8月16日，穆萨维因签证违规被捕。当地FBI分局嗅到了危险，申请搜查其笔记本电脑，却两次被华盛顿总部驳回，理由是无法证实其与境外势力的联系。那台电脑，直至911之后才被解锁。 场景二：凤凰城的备忘录 一个月前的7月10日，FBI凤凰城分局探员肯尼斯·威廉姆斯写下内部通报，警告基地组织可能正批量派遣人员赴美学开客机，并附上了排查方案。然而总部大笔一挥，标为“不用跟进”。直到双子塔倒塌，那两位主管也未曾翻阅过这份文件。系统无法自动识别“大批中东人扎堆学开飞机”的危险可能，更无法在穆萨维落网时，将其与一个月前的预警自动匹配。 场景三：汉堡与圣地亚哥的割裂 2000年，阿塔、谢希、贾拉——三位未来的劫机者，属于同一密谋组织——汉堡细胞，持真名与旅行签证从容入境。美国的移民数据库与反恐名单完全割裂，三人甚至未触发任何警报。直到911后，SEVIS（学生与交流访问学者信息系统）这类联动机制才被迫催生。监控者与行动者，被隔在两个互不通话的房间里。 场景四：吉隆坡—曼谷—加州的断线 2000年1月，CIA在吉隆坡拍下了两名劫机者与“科尔”号爆炸案主谋哈拉德同时出现的照片。然而照片既未录入观察名单，也未通报FBI。1月15日，哈兹米飞抵洛杉矶，CIA知情却未声张。两人随后住进了圣地亚哥一名FBI线人的家中，而当地FBI对此毫不知情。直到2001年8月24日，两人才被列入观察名单，而搜查指令竟拖延至8月28日才发出，距灾难仅剩两周。系统缺乏“本体论”思维，无法将“吉隆坡参会者”、“外国入境旅客”、“线人的房客”归为同一实体。 场景五：亚丁港的爆炸事件 2000年10月，哈拉德策划了“科尔”号驱逐舰爆炸案，致17名美军丧生。他的名字早已在案，却未被关联到吉隆坡合影中的那两人。由于缺乏“本体”概念，系统无法将“参会者”与“炸舰者”合二为一，警报从2000年推迟至永远。 灾难当日 911当天，数据治理的缺失再次产生恶果。8:19，华裔空乘邓月薇报警，信息却未能高效同步。8:46，第一架飞机撞塔，白宫尚不知飞机被劫。布什总统在佛罗里达的小学里，听到的只是“小型飞机事故”。副总统切尼在办公室看着电视，眼睁睁目睹第二架飞机撞向南塔。FAA内部混乱不堪，局长甚至在电视画面之前对劫机一无所知。 结论 导致911的，不是情报收集的匮乏，而是数据治理的失败，是连接的失败。报告中美国认为的药方是“去中心化网络”，设立国家情报总监（DNI）与国家反恐中心（NCTC），打破部门壁垒。 在2004年12月17日，布什总统签署了《2004年情报改革与防恐法》。这是1947年以来情报界的最大变革：设立DNI统管各情报机构，成立NCTC作为跨机构中枢，并强制要求从“需要知道”转向“需要分享”。这套法律体系，正是治理层面的“本体化”雏形。 国家背后的帮手：Palantir *信息来源于 BBC 科技专题报道、行业大数据研究报告、《纽约杂志》2020 年深度调查，以及Palantir官方网站文章 Palantir 诞生于 2003 年，它的精神胚胎也就是 9·11事件，2003 年，蒂尔投入第一笔启动资金，联合亚历克斯·卡普、乔·朗斯代尔、斯蒂芬·科恩等人共同创立 Palantir。公司之名源自指环王的真知晶石，公司里有哲学和PayPal的复合血脉。 外界常将Palantir误解为一台输入“本拉登”即输出“阿伯塔巴德大院”的GPS定位仪。事实并非如此。Palantir的Gotham平台，做的是将散落在多系统的碎片，融合成“关系网+时间轴+地理空间”的复合画像。 根据 Palantir 官方文档定义，其核心技术被称为“本体论”（Ontology），即“对世界的分类”。官方将其定位为组织的数字孪生，这是一个位于集成数据集与模型之上的语义层（semantic layer）。该架构通过将数据映射为对象类型（object types）、属性（properties）、链接类型（link types）和动作类型（action types），构建出组织运营的完整图景。Palantir官方明确指出，Ontology 的设计初衷是表达企业复杂且相互关联的决策，而不仅仅是数据。值得注意的是，卡普拥有法兰克福大学新古典社会理论博士学位，福布斯等外界媒体亦指出产品名称“Ontology”与哲学术语存在关联，但 Palantir 官方从未公开声明其技术架构直接源于哲学理论。 2005年，CIA旗下投资机构向Palantir注资200万美元，使其成为CIA此后三年的唯一客户。随后，NSA与FBI也相继成为其客户。尽管CEO卡普对本·拉登行动细节避而不谈，但《纽约杂志》2020年的调查指出，Palantir被广泛认为在长达十年的追捕中提供了关键辅助。 本体论与数据：从哲学到实践 本体论源于哲学，研究存在及其范畴关系。互联网时代，计算机科学家借用了这一概念，用以描述如何将现实世界映射到数字空间。简而言之，它是构建结构化模型，让分散的数据能被理解、连接和使用，而非仅是孤立的堆积。而皮特和卡普都是哲学训练出身，Palantir 从一开始就不是一家普通的硅谷大数据公司，而是带着强烈的哲学气质 。他们从哲学本体论出发，建立出了自己的一套数据治理的本体理论——ontology，也就是我们常说的palantir的本体论。 Palantir的工程化落地 *信息来源：Palantir官方文档 Palantir所希望达成的，简单来讲是让按真实世界建模的虚拟世界模型反过来改变现实。其系统架构核心分为三层： 第一层：语义元素（Semantic Layer）——定义“是什么” 这是系统的地基。通过对象（Object）、属性（Property）和链接（Link）统一描述业务实体。 对象：人、组织、地点、设备等。 属性：姓名、国籍、经纬度等特征。 链接：隶属、发生于、驾驶等关系。 在情报工作中，这意味着“吉隆坡参会者”、“入境旅客”、“线人房客”不再是四条孤立记录，而是同一“Person”对象的不同面。 第二层：动力元素（Kinetic Layer）——定义“怎么做” 语义层定义了静态世界，动力层则赋予系统执行力，包含动作（Actions）和函数（Functions）。 如果说语义层是名词，动力层就是动词。它规定条件触发时的操作逻辑： 检测到可疑通话，自动发出追踪指令。 识别特定区域异常人员聚集，自动触发“潜在袭击”警报。 发现“吉隆坡参会者”入境，自动推送情报至分析师。 这使得系统从静态档案库变为实时作战图。 第三层：动态决策与四重集成 系统通过数据（Data）、逻辑（Logic）、行动（Action）、安全（Security）的四重集成实现动态决策： 数据：汇聚多源信息。 逻辑：运行业务规则与算法。 行动：执行工作流并回写系统。 安全：全程细粒度权限控制。 这构成了“组织的数字孪生”，将法律层面的“需要分享”转化为技术层面的“实时协同”。 关于“海神之矛”的推测 *基于公开能力的推演，非已证实事实 注：以下内容是基于Palantir公开技术架构的合理推演，非官方确认的事实。 本拉登在阿富汗躲过追捕以后，完全隐蔽了起来，反侦察能力强，使用信使物理传话，抓捕行动也因此一直推迟。 2010年，一个名为“科威特人”的信使犯下了致命失误——使用了电子设备通信，使其从抽象名字变为可追踪节点。这正是本体论发挥效用的时刻： Object（实体归一）：系统将CIA的吉隆坡记录、FBI的签证信息、NSA的加密通话记录、卫星影像中的白色铃木SUV，归并为同一“科威特”对象。 Property（刻画特征）：系统标记其静态属性（身份：核心信使）与动态属性（仅接听不呼出、活动半径超500公里、车辆夜间出行占比高）。每新增一条异常，系统自动上调其风险置信度。 Link（连点成网）：系统建立语义链接：科威特─接听─加密通话；科威特─驾驶─白色SUV；SUV─停靠─阿伯塔巴德大院；大院─焚烧─垃圾（异常）。通过贝叶斯逻辑持续修正，多条证据叠加，系统判定大院藏匿高价值目标的概率趋近于确定。 Action（从研判到行动）：当置信度达标，系统自动标记目标，同步至CIA与军方系统，生成侦察工单与突袭预案。经审批链核准后，指令下达，行动结果回传系统，沉淀为新研判规则。 *AI生成的模拟概念图（置信度都为虚构） 如图所示，从完整复杂网络里可以筛选出一个完整的事件，该事件是现实世界的映射，该事件的置信度可以通过统计学工具计算。 一个假设：假如十年前美国情报部门就用了本体论 假如2001年就有Palantir的本体论，改变的绝非仅是多抓几个恐怖分子，而是整个情报链路的重塑。回顾那些致命失误： 7月10日：凤凰城备忘录提交瞬间，语义层自动提取“飞行学校+极端分子属性”，关联全国注册记录，而非沉睡两月。 8月16日：穆萨维被捕瞬间，动力层函数识别”高风险+飞行学校+关联凤凰城“模式，自动触发紧急搜查申请，而非驳回申请。 8月23日：CIA通报嫌疑人入境瞬间，地理空间函数自动匹配圣地亚哥电话簿，快速派遣核查，而非任其在眼皮底下潜伏19天。 8月底：嫌疑人列入监视名单瞬间，动作类型自动生成禁飞名单条目提交到相关部门，而非遗漏登机。 911委员会认为事件并非不可避免。本体论的推演表明，至少5至6次错失的机会可被挽回。这并非魔法，而是“连接”的胜利。当吉隆坡的“Khalid”、FBI未知的“Khalid al-Mihdhar”、FAA空白的观察名单，在本体论的语义空间中相遇时，9·11报告中“连接的失败”才有了真正的工程化解药。IRTPA在法律层面要求连接，Palantir在技术层面实现连接，这便是本体论给予后世最深刻的教训。
三份重量级政策文件在两年内相继出台，从制度、财务、流通三个维度，一步步将数据中台的角色从"数据管道"推向了"资产管理基础设施"。 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
去年年底，一家中型制造企业部署了企业内部大模型，试点阶段的效果让团队兴奋不已——业务总监对着对话框输入"本月华东区销售情况"，系统自动拉取数据、生成图表，几秒钟就给出了分析结果。正式上线后第一周，财务总监找到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
CFO在季度会上问了一句："咱们的数据能不能入表？"数据团队负责人看了看手头那几十个数据质量告警——沉默了。 这不是虚构场景。同一周，另一家制造企业的数据团队也遭遇了类似的尴尬：审计师要求提供拟入表数据的质量评价报告，团队翻遍了系统，只找到一份两年前的手工Excel质量记录——字段缺失率没有统计、跨系统一致性从未对比、数据血缘完全空白。CFO最后拍了板："入表先搁置。" 这两幕正在越来越多的企业中上演。财会〔2023〕11号[2]施行已近两年，数据资产入表从概念讨论走向实际操作，越来越多的CFO和审计师开始把同样的问题摆上台面。而大多数企业的数据治理状态，距离回答"能不能入表"还有三道明显的坎。 一、三道政策令：入表不再是选择题 三大政策正在将数据资产入表从"加分项"推向"必答题"。 DCMM 2.0（GB/T 36073-2025）[1]新增"数据资产"能力域。 这是标准层面的关键信号——评判企业数据管理水平的标准，从"有没有治理"升级为"能不能资产化"。数据不再只是 IT 团队维护的"后台资源"，而是需要被识别、被评估、被量化的企业资产。 财会〔2023〕11号[2]明确了数据资源的会计处理路径。 这份暂行规定施行以来，数据可入表的制度障碍已被扫除，CFO 开始真正关注数据治理——因为数据能不能入表、入多少，直接关系到财务报表。 "数据要素×"三年行动计划进入收官之年。 数据要素市场化配置加速，公共数据授权运营、企业数据资产入表、数据交易定价——这一整套政策组合拳正在推动一个根本变化：企业数据管理的主线任务，已经从"把数据管好"扩展为"让数据成为资产"。 三道政策拧成一股绳，方向已经清楚。问题是：大多数企业的数据治理，还卡在入表的前一道关口上。 二、入表前的三道坎 从我们观察到的企业实践来看，数据资产入表之前，有三道坎几乎家家都会遇到。 第一道坎：资产底数不清。 企业运行多年，数据散落在数十套业务系统中，有多少张表、哪些字段、数据量多大——往往没人能说清楚。而数据资产入表的起点恰恰是"先知道你有什么"。底数不清，入表就无从谈起。 第二道坎：质量参差不齐。 数据入表需要审计依据，但大量企业的数据从未经过系统性的质量评价。同一客户的名称在 CRM 里是"XX有限公司"，在 ERP 里是"XX公司"，在 MES 里又是一个缩写——当数据本身都不可信时，资产估值就失去了基础。数据资产化有一个朴素的前提：数据必须可信。入表只是把这个前提变成了硬性约束。 第三道坎：标准没有统一。 跨系统的数据口径不一致，导致资产边界无法清晰界定。一条"合同金额"数据，财务系统和业务系统各有一套算法，以哪个为准？入表之前，这类问题必须被回答。 这三道坎背后指向同一个事实：数据资产入表的真正难点不是会计处理，而是数据治理。入表倒逼的，本质上是一次治理能力的系统性升级。 三、从被动应对到主动推进：分三步走 面对入表压力，从多数企业的实践来看，一个较为稳妥的做法是将治理任务拆解为三步推进——不是在入表前突击搞一次"大扫除"，而是让治理本身走向体系化。 第一步：先把家底盘清楚。 不谈标准、不谈质量，第一步就是搞清楚自己有什么数据。全量数据资产盘点，涵盖各业务系统的表、字段、数据量、更新频率，最终产出一份可追踪的资产清单。这一步的价值不止于入表——很多企业在盘点过程中才发现，同一个业务域的数据在三个系统里有三种叫法，连业务部门自己都说不清哪个是最新的。入表给了盘点的正当性：不是 IT 部门"又在搞治理"，而是 CFO 和审计师需要这份清单。 第二步：让数据质量可量化。 家底盘清之后，紧跟着的问题是：这些数据可信吗？以 GB/T 36344-2018[3]定义的六个质量维度为框架——规范性、完整性、准确性、一致性、时效性、可访问性——对企业数据做一次系统性的质量扫描和量化评分。除可访问性外，其余五个维度直接影响数据的可用性和可信度。查出来的问题，打标、归类、生成工单、推动修复，让质量管控从"人工经验判断"变成"可追踪的闭环"。跨系统的数据标准统一也应当在这一步完成——统一命名规则、编码规范、核心业务主数据定义。 第三步：把资产管起来。 前两步扎实之后，数据资产化管理的基础就具备了。这一步的核心是建立资产目录，让业务人员用业务语言就能找到数据资产、理解其含义、评估其价值。资产编目、合规审核、价值评估、会计确认——这一系列动作需要 IT、财务、法务、业务多个部门协同完成。入表不是终点：数据被持续使用、产生可计量的业务回报，才是资产化的完整闭环。 需要指出的是，三步走不是一条直线。企业在第一步盘点之后，往往会发现某些数据域的质量问题比预想的严重，需要回到第二步深入治理，才能推进第三步。但从整体方向来看，这三步的顺序相对清晰——跳过盘点直接定标准，容易做出一堆没人用的规范；跳过质量直接入表，写进报表的数据经不起审计。 四、案例验证：一家国企的入表实战 华东某交投集团（企业名称已脱敏，下同）的经历，为上述路径提供了一个完整的注脚。 启动入表工作之初，该集团面临的是一个典型困境：上千张业务表散落在各系统中，无人能说清全貌；同一类数据在不同系统里有不同的命名和口径；数据质量从未被系统性地评估过，无法量化可信度。 整个入表工作的起点，是一次历时数周的全量数据资产盘点（对应第一步"理清家底"）。盘点产出了集团首份完整的数据资产清单，为后续所有工作提供了基础坐标系。 在此基础上，项目团队着手建立跨系统的数据标准体系——统一命名规则、核心实体编码规范、质量评价框架（对应第二步"建标准、管质量"）。标准确立之后，数据质量评分得以量化：最终达到 99.53 分。 第三步进入资产化管理：编目、合规审核、价值评估、会计确认——多部门协同完成首批数据资产入表。 复盘整个过程，一个清晰的结论浮现：入表成功的根本原因，不是评估方法有多精妙，而是前两步——家底盘清了、质量标准统一了——走扎实了。入表不是治理的目的，而是治理扎实之后自然产出的结果。 五、常见问题 Q1：做了数据治理就一定能实现数据资产化吗？ 不一定。数据治理是资产化的必要条件，不是充分条件——但没有治理，资产化一定走不通。质量不可信的数据无法估值，标准不统一的资产边界不清。 Q2：应该先做治理还是先做资产盘点？ 先盘点。不知道有什么数据就去谈治理标准，容易搞出一堆没人用的规范。用"理"先摸清家底，再从中挑选高价值的数据资产优先投入治理资源，产出比更高。 Q3：中小企业资源有限，怎么落地？ 从最核心的一到两个业务域切入，花几周时间完成资产盘点和质量基线，搭建轻量平台跑通闭环。如果需要工具支撑，可以关注一些免费可用的数据质量检测工具——例如龙石数据质量管理平台社区版，覆盖 GB/T 36344[3]标准框架下的质量检测，可先做一次数据质量体检，再根据结果决定下一步投入方向。关键是先动起来，不必追求一步到位。 六、结语 数据资产入表倒逼治理升级——这未必是坏事。 过去，技术团队推着业务走，往往感觉推不动。现在情况反过来了：CFO 和审计师在推着技术团队走，入表的硬性要求反而让治理获得了来自业务端的驱动力。方向比从前更清晰。 从多数企业的实践来看，较为稳妥的做法是先理家底、再建标准、再管质量——三件事做扎实了，入表是水到渠成的事。数据资产入表不应被视为一次性的会计操作，而应被看作企业数据治理能力走向体系化的一个起点。 参考来源 [1] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），2026年7月1日实施 — openstd.samr.gov.cn/bzgk/gb/std?tid=72458 [2] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号），2023年8月 — gov.cn/zhengce/zhengceku/202308/content_6899395.htm [3] GB/T 36344-2018《信息技术 数据质量评价指标》 — openstd.samr.gov.cn/bzgk/gb/std?tid=72297 龙石数据，《数据治理实战指南》，— https://www.longshidata.com/lsdmaterial/dg-guide.html
一家中型制造企业在部署大模型后，内部测试阶段效果不错，问"本月华东区销售情况"能给出清晰的数据和趋势判断。正式上线第一天就出了问题——系统告诉业务副总"华东区上月销售额3200万"，但财务系统里是2800万，差了整整400万。 排查结果指向了一个简单的事实：ERP、CRM和财务系统对"华东区"的定义不同，对"销售额"的计算口径也不一样。模型本身没有出错——它忠实汇总了它能看到的全部数据。问题出在它"看到"的数据本来就不一致。 这个场景折射出一个正在加速的趋势：当大模型从技术验证走向业务一线，最关键的瓶颈往往不是模型能力，而是数据供给质量。Data-Centric AI的研究反复验证了一个判断——AI效果的上限由数据质量决定，而非模型参数。DCMM 2.0（GB/T 36073-2025）[1]更从国家标准层面确认了这一方向：L4量化管理级明确要求企业具备AI支撑能力，数据治理在AI时代已从"最好有"变成了战略级要求。 大模型时代，数据质量的容错率被大幅压缩 传统BI场景下，数据质量问题的后果相对可控。报表上一个数字偏差，使用者在业务层面往往能察觉——"上个月华东没做过这么大单子"——然后人工核查修正。数据错了，人的经验还能兜底。 大模型把这个容错空间压到了几乎不存在。原因是三个机制同时起作用。 第一，大模型输出的是完整分析结论，而非单个数字。当它在回答"今年哪个产品线增长最快"时，会调用多张表、关联多次查询、形成综合判断。链条中某一个环节的数据有问题，可能让整段结论偏离事实。业务人员面对一段逻辑完整的分析文本，很难逐环节拆解验证——这不是看一个数字对不对，而是判断一整套推理是否站得住脚。 第二，大模型天然倾向于信任输入数据。它不会主动质疑"这个字段的值从上下文推断可能不对"，也不会在发现多个数据源对同一指标给出不同数值时提示"请确认口径"。它会根据它能读取到的全部信息，给一个它认为最合理的回答。而如果它读到的信息本身就相互矛盾，这个"最合理的回答"可能恰好是最危险的——看起来有理有据，实际上建立在不一致的数据基础之上。 第三，修复成本呈非线性放大。传统BI场景下排查一个数字偏差，通常追溯到一两张源表就能定位。而大模型关联了多系统、多口径的数据，一次质量问题可能需要回溯多个数据源、对比多套业务口径、跨部门确认数据定义。排查周期从小时级拉长到天级，远超传统场景的量级。 换句话说，大模型不会判断数据对错，但它会让数据中的问题变得比以往任何时候都更难发现、更难追溯、影响更大。Data-Centric AI提出者吴恩达的判断在这里找到了最具体的注脚："与其花80%精力调模型参数，不如花80%精力提升数据质量。"当企业发现花了几百万调优的大模型，在实际业务场景中的表现还不如一个治理到位的中小模型时，数据治理在AI战略中的优先级自然被重新排列。 国家标准已在推动数据供给升级 DCMM 2.0（GB/T 36073-2025）[1]于2026年7月1日正式实施，带来的变化不止是能力域从8个扩展为9个。更值得关注的是成熟度评估体系中对AI能力的明确要求。 新标准将数据管理能力划分为五个成熟度等级：初始级→受管理级→稳健级→量化管理级→优化级。到了L4量化管理级，标准要求企业在数据管理全过程中具备量化评估能力，并引入人工智能等先进技术支撑数据管理决策。这意味着AI应用在DCMM体系中不再是一个可选项——企业若想在评估中达到L4及以上，必须在数据架构、数据质量、数据标准等关键能力域中储备AI用数能力。 九大能力域的重新划定也释放了明确信号。新增的"数据资产"域排在第四位，包含权属管理、价值评估和资产运营三个能力项，与"数据二十条"[3]确立的数据要素市场化政策方向直接呼应。"数据应用"更名为"数据应用流通"，将数据服务、外部数据管理和数据开放纳入统一框架。从标准结构来看，DCMM 2.0正在从"管好数据"向"用好数据"倾斜——而这一转变恰好与AI时代企业对高质量数据供给的需求同频。 与DCMM 2.0互补的是GB/T 36344-2018[2]《信息技术 数据质量评价指标》。该标准定义了六个数据质量评价维度：规范性、完整性、准确性、一致性、时效性和可访问性。除可访问性侧重数据获取的技术条件外，前五个维度直接影响AI应用效果——规范性决定了数据是否按统一格式组织、可被模型稳定解析；完整性和准确性决定了模型赖以推理的信息基础是否可靠；一致性和时效性决定了跨系统关联分析的结论是否可信。 政策层面，高质量数据集建设也在加速从概念走向落地。江苏省2026年率先推动高质量数据集先行先试，147个项目入选省级试点，覆盖制造、医疗、交通等多个领域。龙石数据联合省市场监督管理局数据中心和苏州大学共同申报的"高质量数据集智能底座"项目同期获批，探索数据治理成果向AI训练数据的高效转化路径。 这些标准和政策的交汇，指向同一个方向：高质量数据供给正从一个技术课题上升为制度性要求。以江苏某大数据中心为例，该中心对300余个高频共享数据资源、超过10亿条数据进行了系统性质量评测，累计定位近1000万个数据质量问题，经过持续修复后修复率达到95%，200个高频应用资源的准确率达到100%。公共数据供给从"能用"提升到"好用"——这个跃迁的逻辑，同样适用于企业AI场景下的数据供给。 从"数据可用"到"数据可训"：高质量供给需要三层基础 传统数据治理以满足业务报表和运营分析为主要目标，关注的是数据"能用"——能从不同系统中取到数据、能跑通报表、能支撑日常决策。但大模型对数据的要求不止于此。它需要数据"可训"——能被模型稳定解析、跨系统关联时不产生口径冲突、输出结论可以被追溯和验证。从"可用"到"可训"，需要补上三层基础。 元数据：让AI理解数据含义 元数据是数据的"使用说明书"——它记录了数据从哪里来、经过了哪些加工、每个字段代表什么业务含义。对传统BI来说，元数据的作用更多是辅助性的：分析师查一下表结构、确认一下字段含义。但对大模型而言，元数据层几乎是不可或缺的前提。 原因很简单：大模型在处理数据时，看到的是字段名和数值，但读不懂字段背后的业务语境。一个标注为customer_name的字段，在ERP系统里指签约主体，在CRM系统里指联系人。如果模型在关联这两个系统的数据时不做区分，"客户"的统计口径就直接出错了。元数据的作用，就是在这类场景下提供关键的业务语义——让AI能在理解数据含义的前提下使用数据，而不仅仅是拿到一个可查询的字段。 当监管或审计要求企业说明"训练数据来源和加工过程"时，元数据是唯一可以提供完整追溯链条的依据。没有元数据，训练数据就是一堆脱了上下文的值，数据的可解释性归零。 数据标准：让AI跨系统理解业务 大模型的一大优势是跨数据源关联分析。但这个优势的前提，是不同系统对同一业务概念的定义是一致的，或者至少是可映射的。 现实中的情况往往是反过来的。同一家制造企业，ERP系统按事业部划分"产品线"，MES系统按生产工艺划分"产品线"，CRM系统则按销售目录划分。三套"产品线"对应三种分类逻辑和编码体系，每一套在自己的系统内都自洽，但放到一起就互相冲突。当大模型尝试关联这三个系统的数据做综合分析，它面对的是一堆同名字段指向不同实体——口径不统一导致的结论偏差，比数据缺失更难排查。 数据标准层的作用，就是为不同系统之间建立一套"翻译机制"：ERP编码怎么映射到MES分类、CRM的中文描述对应哪个ERP料号。这不只是技术层面的字段映射——标准层实际上是AI跨系统理解的"业务词典"。有了这层翻译，模型才可能做到"问的是全公司的产品线趋势，回答时自动匹配所有系统的口径"。 数据质量：让AI输出可信 这是最直接的一层，也最容易被低估。GIGO原则（Garbage In, Garbage Out）在传统IT时代是一条经验法则，在大模型时代变成了一个被放大数倍的现实风险。 传统场景下，一条脏数据最多污染一张报表的某个格子。但在大模型场景中，一条脏数据可能被模型在多轮推理中反复调用——它生成第一个分析结果时引用了这个错误值，下一步做趋势对比时继续基于这个结果推导，再下一步做优先级排序时又把这个推导作为权重依据。一条脏数据的"污染半径"在模型推理链中被大幅扩张。 社区的实践经验表明，在正式启动大模型应用之前，至少要对核心数据域做一轮系统性质量评估。市面上也有部分免费的数据质量工具，例如龙石数据质量管理平台·社区版，部署后可对核心数据源进行GB/T 36344标准框架下的质量检测，旁路监测模式不阻断业务流转，适合作为质量基线的快速摸底工具。 三层基础之间的关系不是串行的——不需要等元数据"做完"再建标准、等标准"完美"再做质量。它们之间互相增强：元数据缺失时数据标准难以落地，质量检测的结果反过来可以暴露标准不一致的问题。从多数成功案例来看，选取一个核心业务域，三层并行启动、快速迭代，比逐层推进更高效。 CDO和CIO现在可以着手做的几件事 大模型还在快速迭代，但对数据供给的要求方向已经足够明确。不需要等到"治理100分"再启动AI应用，但启动之前有几件事可以先做。 先做一次数据质量体检。 选取AI应用瞄准的核心业务域，用GB/T 36344[2]的六个维度（除可访问性外重点看前五个）做一次系统性评测。摸清现状后再定优先级：如果多个系统对同一指标口径不一致，先把数据标准做起来；如果核心表的缺失率或异常值比例偏高，先建质量基线。体检的目的不是追求完美，而是知道问题在哪儿、先解决哪个。 建立"数据就绪"的最小体系。 不需要一开始就覆盖全部数据资产——从AI应用会用到的核心表和字段切入。元数据层至少记录这些表和字段的来源、加工过程和业务含义。数据标准层统一核心业务实体（客户、产品、供应商）的编码规则和分类口径。数据质量层在数据接入环节建立完整性、准确性、一致性的自动校验。这个最小体系跑通后，再向更多数据域扩展。 AI用数与数据治理并行推进。 不必等治理做完再上AI。实践中的一个有效策略是：AI用数的需求反向暴露治理短板。当业务人员用自然语言问数据时得到的答案不准，自然会暴露出标准不一致、元数据缺失、质量问题。这比自上而下推动治理更容易取得业务部门的理解和配合。选取一个业务价值最高的用数场景，先跑通再扩展。 关注DCMM 2.0的AI能力要求。 DCMM[1] L4以上要求企业储备AI用数能力，这涉及的是评估时间表而非远期规划。已有企业在进行DCMM 2.0评估准备时，将AI用数能力列为重点建设项。评估现有数据中台是否具备AI用数入口——如自然语言查询、数据资产目录驱动等——是一个务实的起点。市场上已有部分产品（如龙石AI用数智能体）支持自然语言问数、数据不出域的私有化部署，作为数据治理成果的消费层，可以让治理投入更快见到业务价值。 常见问题 问：大模型项目要不要等数据治理做完再启动？ 不需要。选取核心业务域先做质量评估和标准统一，治理工作与AI用数可以并行推进。内测阶段用受控数据集验证效果，是比较稳妥的做法。 问：怎么判断是模型能力问题还是数据质量问题？ 选取一个已知数据质量情况的业务域做测试。如果在该域中模型输出准确度明显高于其他域，说明问题更可能出在数据侧。借助数据质量评估工具对输入数据做系统检测，将检测结果与模型输出效果做对照分析，通常能快速定位根因。 问：中小企业没有专职数据治理团队，怎么起步？ 从数据质量体检开始。目前市面上已有免费可用的数据质量工具（如龙石数据质量管理平台社区版），覆盖GB/T 36344[2]主要维度，部署后可快速摸清数据质量现状，再根据结果确定治理优先级。不需要一开始就铺开全量——先盯住AI应用会用到的那几套核心系统和几张核心表即可。 问：DCMM 2.0 L4要求AI能力，大部分企业L3都不到，怎么办？ DCMM是能力建设的方向标，不是紧急合规线。企业可以根据自身所处阶段，先锚定与AI效果最直接相关的2-3个能力域重点建设——尤其是"数据质量"和"数据标准"两个域。先做到L3稳健级的核心能力，再向L4量化管理级演进。标准提供的是一条可参照的路径，不是一张时间表。 大模型代表了企业AI应用的前沿方向，但它的上限取决于数据供给质量而非模型参数规模。Data-Centric AI的核心理念在DCMM 2.0[1]标准中得到了制度性确认——数据治理已成为AI基础设施的组成部分，而非应用上线前的一项准备工序。 对企业CDO和CIO而言，眼下最务实的做法是从三层基础中最薄弱的环节切入，在AI用数中暴露问题、迭代优化。当模型能力不再是稀缺资源，高质量的数据供给就是AI应用效果的分水岭。这一能力，正在从技术课题转变为企业AI战略的核心竞争力。 参考来源 [1] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），2026年7月1日实施 — openstd.samr.gov.cn/bzgk/gb/std?tid=72458 [2] GB/T 36344-2018《信息技术 数据质量评价指标》 — openstd.samr.gov.cn/bzgk/gb/std?tid=72297 [3] 中共中央、国务院，《关于构建数据基础制度更好发挥数据要素作用的意见》（"数据二十条"），2022年12月 — gov.cn/zhengce/2022-12/19/content_5732695.htm [4] 龙石数据成功入选2026年江苏省高质量数据集建设先行先试项目试点 — https://www.longshidata.com/blog/c/c2026061101.html
当CFO下一次推门进来说"我们也要做数据资产入表"时，你的平台能不能答出这五个问题？ 第一问：企业有哪些数据资源？ 上百个业务系统、上千张表，能不能用一份结构化的资产目录把它们说清楚——而不用IT团队加班翻Excel？ 第二问：数据质量有多高？ 会计师事务所要的是系统性、可重复、可追溯的质量评价结果，不是一句"我们一直在用、应该还行"。 第三问：跨系统的数据口径统一了吗？ 同一个客户在CRM里叫"客户名称"，在ERP里叫"往来单位"——资产边界划不清，估值从何谈起？ 第四问：资产目录建好了吗？ 入表范围的划定，依赖的是一份面向审计和业务方的正式资产清单，而不是技术文档里的表结构说明。 第五问：这些能力是建在平台上，还是寄托在人的经验上？ 如果答案全是后者，那入表的准备还远没有完成。 数据资产入表正在从少数先行企业的"试点"走向制度化的"扩面"。对于此前还在观望的CDO、CIO来说，"入不入表"已经不是一个远期话题——以上五个问题，接下来的两年内大概率会被CFO和审计机构逐一追问。 入表不是会计问题，是数据治理问题 不少企业高管的直觉反应是："入表是财务部的事，跟我们信息部门关系不大。" 这个判断可能恰好弄反了。拆开数据资产入表的五个核心环节来看——资产盘点、合规审核、质量评价、价值评估、会计确认——前三个环节的本质都是数据治理工作，而不是财务操作。 资产盘点考验的是元数据管理能力：你能不能系统性地说清楚企业有多少数据、存在哪里、归属哪个业务域？合规审核考验的是分类分级和安全策略是否落地。质量评价更是纯数据治理范畴——按 GB/T 36344-2018[3]定义的六个维度（规范性、完整性、准确性、一致性、时效性、可访问性），除可访问性外其余五个维度直接影响数据是否"可信到可以入表"。 所以当CFO追问"这批数据能不能入表"时，答案不在财务部的账本里，而在数据治理平台的扎实程度里。一个基础公式是：元数据管理 + 数据标准 + 质量闭环 + 资产编目 = 入表就绪。 四个必检项：你的平台能过几关？ 如果把入表看作一次"数据审计"，那么数据治理平台就是这场审计的主要被查对象。以下四个维度，分别对应入表流程中的关键堵点。 元数据管理：你能说清楚自己有什么数据吗？ 资产盘点是入表的起点——入表范围取决于你对自身数据资源的掌控程度。如果元数据管理还停留在人工整理Excel的阶段，面对上百个业务系统、上千张表，盘清家底本身就是一项浩大工程。更关键的是，没有血缘分析能力，你很难追溯一张报表的上游来源——讲不清楚数据"从哪来"，入表范围就是一笔糊涂账。 从行业实践来看，具备自动采集元数据和血缘分析能力的治理平台，在这个环节能将盘点周期从数周压缩到数天。 数据标准：跨系统的"数据语言"统一了吗？ 同一个客户实体，CRM 里叫"客户名称"，ERP 里叫"往来单位"，数据仓库里又变成了"签约方"——三个名字可能指向同一个对象，但系统不认。数据口径不统一，资产边界就无法清晰界定，估值就更无从谈起。 DCMM 2.0[2]将数据标准列为独立能力域，考察的是企业是否建立了统一的业务术语、参考数据和主数据标准。入表场景下，这不再是一个"锦上添花"的技术规范，而是直接影响资产范围的底线条件。 数据质量：你的数据经得起审计吗？ 入表需要可审计的质量依据——不是技术团队一句"这批数据我们一直在用，应该还行"能够替代的。会计师事务所要求的是系统化、可重复、可追溯的质量评价结果。 GB/T 36344[3]的六个维度中，规范性（字段格式是否统一）、完整性（关键字段有无缺失）、准确性（数值是否与业务实际一致）、一致性（跨系统数据是否吻合）、时效性（数据更新是否及时）这五个维度构成了入表质量评价的基本框架。平台需要具备全量自动化质量扫描能力，能够输出结构化的质量报告，而不是对数据质量做一次性的手工排查。 资产编目：入表的"资产清单"建好了吗？ 即使前三项都达标，如果缺少一份结构化的数据资产目录，入表范围仍然无法被清晰界定。DCMM 2.0[2]新增的数据资产域，考察的正是企业是否建立了资产目录、是否具备资产分类与标签管理能力。 资产目录不是一份技术文档——它是面向审计和业务方的"数据产品手册"，需要说清楚每项数据资产的业务含义、覆盖范围、更新频率和质量状态。没有这份目录，入表范围的划定就带有较大的主观判断成分，经不起审计追问。 案例：一张上千张表的答卷 福建某交投集团（企业名称已脱敏，下同）是负责城市数字化运营的国有企业，拥有充电系统等多个业务系统，上千张业务表散落在不同数据库中。当数据资产入表被提上日程时，他们面临的问题和大多数企业一样：家底不清、质量未知、流程不熟。 整个项目按六个阶段推进：资产盘点→资产登记→质量评价→合规审核→价值评估→会计入表。其中，龙石数据承担了质量评价环节，并协同律所、会计师事务所和资产评估机构完成全链条服务。 关键节点有两个。一是资产盘点阶段，通过自动化扫描与业务规则相结合，从上千张表中梳理出充电订单、支付流水等核心数据资源，形成标准化的《企业数据资产目录》——这是后续所有工作的基础。二是质量评价阶段，以 GB/T 36344[3]为框架对拟入表数据进行全量自动化扫描，最终质量评价总评分达到 99.53 分（满分 100），会计师事务所据此确认质量符合入表要求。 该集团最终成为福建省某市首批完成数据资产入表的国有企业。回头看，入表的瓶颈并不在会计师事务所的专业能力，而在数据治理平台的基础有多扎实——资产目录决定了入表范围，质量评价决定了入表可信度。以龙石数据中台为例，其从资产盘点、标准管理、质量评价到资产编目的端到端支撑能力，正是在这类全链条服务中积累和验证的。 FAQ Q1：数据治理做到位了，就一定能入表吗？ 不一定。治理是必要条件但不是充分条件。数据质量不过关，估值无从谈起；标准不统一，资产边界就划不清——这些确实取决于治理的扎实程度。但入表本身还需要完成资产确认、合规审核和价值评估三个专业环节，这些超出了数据治理平台的范畴。比较准确的理解是：治理到位是入表的前提，入表是治理成果在财务层面的确认。 Q2：企业应该先做治理还是先做资产盘点？ 从多数案例的实际操作路径来看，比较合理的顺序是先盘点。福建交投花了数周时间先把上千张表的家底摸清楚，再在此基础上建立标准体系。如果反过来——还不知自己有什么数据就去定标准，容易搞出一套没人用的规范。当然，如果企业的数据标准基础已经比较好，两条线也可以并行推进。 Q3：中小企业有必要为入表铺这么大盘子吗？ 不需要像大型国企那样全量铺开。比较务实的做法是选一两个核心业务域，花几周时间做资产盘点加质量基线，再搭建轻量平台跑通从盘点到编目的闭环。第一步始终是搞清楚自己有什么——这和企业规模无关。如果不确定从哪里入手，也可以先用免费的数据质量评估工具对核心业务数据做一次扫描，了解当前数据质量的基线水平再做规划。例如龙石数据质量管理平台·社区版，部署后即可对核心数据源进行 GB/T 36344[3]标准框架下的质量检测，以较低的成本完成入表前的第一步质量摸底。 结语 DCMM 2.0[2]已于 2026 年 7 月正式实施，在贯标评估中，"你们的数据资产情况如何"正在从一个加分项变成基准问题。对于尚未启动入表准备的企业来说，当前比较紧迫的三个动作是：先把家底摸清楚，再把资产化的能力建在平台上而不是Excel里，最后选一个高价值域跑通从盘点到编目的全流程。 工业时代的企业竞争围绕设备和资金展开，数字时代的竞争天平正在向数据资产的运营能力倾斜。这个转变不是一夜之间发生的，但它确实在加速。 参考来源 [1] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号），2023年8月 — gov.cn/zhengce/zhengceku/202308/content_6899395.htm [2] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），2026年7月1日实施 — openstd.samr.gov.cn/bzgk/gb/std?tid=72458 [3] GB/T 36344-2018《信息技术 数据质量评价指标》 — openstd.samr.gov.cn/bzgk/gb/std?tid=72297
