数据资产入表下的企业数据治理架构设计与落地路径

架构师视角：入表不是一个会计问题

CFO 在季度会上问了一句："咱们的数据能不能入表？"数据团队负责人看了看手头那几十个数据质量告警——沉默了。

作为一个数据架构师，你很清楚这句"沉默"背后的问题。它不是一句话能回答的，因为回答这个问题需要一张完整的架构蓝图：数据资产从哪里来、经过哪些系统、质量如何保证、口径如何统一、最终以什么形态进入财务报表——而大多数企业的现状是，这张蓝图还不存在。

财会〔2023〕11 号[2]施行已近两年。另一家制造企业的数据团队被审计师要求提供质量评价报告时，翻遍系统只找到一份两年前的手工 Excel——字段缺失率没统计、跨系统一致性没对比、数据血缘完全空白。CFO 拍板："入表先搁置。"

这不是个案。当数据治理的架构基础缺失时，入表就是把一座没有地基的房子拿去给审计师验收——结果可想而知。

一、政策驱动下的架构需求

三大政策正在将数据资产入表从"加分项"推向"必答题"，同时也对数据治理架构提出了新的要求。

DCMM 2.0（GB/T 36073-2025）[1]新增"数据资产"能力域。 从架构角度看，这意味着数据管理能力评估模型增加了一个全新的维度——"资产化"。传统的"理、采、存、管、用"架构框架需要扩展，增加从"资源化"到"资本化"的跃迁路径。

财会〔2023〕11 号[2]明确了数据资源的会计处理路径。 对于架构设计而言，这意味着需要在现有的数据架构中新增一个"会计确认层"——连接数据治理成果与财务报表的桥梁。数据资产的识别、计量、列报，都需要在架构层面有对应的能力支撑。

"数据要素×"三年行动计划进入收官之年。 数据要素市场化配置要求企业的数据架构具备对外输出的能力——公共数据授权运营、数据交易定价等场景，都要求数据架构从"内部自用"升级为"可估值、可交易、可审计"。

二、入表前的三道架构缺口

从架构设计的维度来审视，大多数企业在入表前存在三个系统性的架构缺口。

缺口一：资产目录层缺失

典型问题：企业有数十套业务系统，但缺乏一个统一的资产注册与发现机制。有多少张表、哪些字段、数据量多大、更新频率如何——这些基础元数据散落在各系统中，没有形成统一视图。

架构影响：没有资产目录层，入表的"资产识别"环节就缺乏基础数据支撑。这本质上是元数据管理架构的缺位。

缺口二：质量评价层缺失

典型问题：数据质量管控停留在"人工巡检"阶段，缺乏自动化的质量扫描、量化评分和问题追踪机制。同一客户名称在 CRM、ERP、MES 三个系统中的一致性从未被系统性地评估过。

架构影响：没有质量评价层，入表的"估值"环节就失去了可信基础。审计师需要的不是口头解释，而是系统生成的质量量化报告。

缺口三：标准统一层缺失

典型问题：跨系统数据口径不一致，核心主数据的编码规则、命名规范没有统一。一条"合同金额"在财务系统和业务系统里有不同的算法逻辑，无从对齐。

架构影响：没有标准统一层，入表的"资产边界界定"就无法完成。口径打架的数据无法形成清晰的资产定义。

三个缺口指向同一个结论：数据资产入表的真正瓶颈不是会计处理能力，而是数据治理架构的完备性。

三、治理架构设计：三层递进模型

基于上述分析，一个面向数据资产入表的企业数据治理架构，可以抽象为三层递进模型。

第一层：资产发现层（Asset Discovery Layer）

定位： 解决"有什么"的问题——全量数据资产的自动发现、注册与编目。

核心能力：

• 多源异构系统的元数据自动采集
• 数据资产统一注册与目录化
• 资产血缘关系的自动梳理
• 资产清单的可视化输出

关键产出： 全量数据资产清单，覆盖各业务系统的表、字段、数据量、更新频率。

实施要点： 这一层是基础中的基础。不谈标准、不谈质量——先搞清楚有什么。很多企业在这一阶段就会发现，同一个业务域的数据在三个系统里有三种叫法，连业务部门自己都说不清哪个是最新的。

第二层：质量量化层（Quality Quantification Layer）

定位： 解决"可信吗"的问题——以量化方式评估数据质量，建立标准统一。

核心能力：

• 基于 GB/T 36344-2018[3] 六维度框架的质量自动扫描
• 质量评分量化（规范性、完整性、准确性、一致性、时效性、可访问性）
• 质量问题打标、归类、工单生成、修复追踪的闭环
• 跨系统命名规则、编码规范、核心主数据的统一

关键产出： 数据质量量化报告，跨系统数据标准体系。

实施要点： 除可访问性外，其余五个维度直接影响数据的可用性和可信度。这一层的核心价值在于，将质量管控从"人工经验判断"变成"可追踪的系统闭环"。审计师要看的，就是这一层产出的量化证据。

第三层：资产运营层（Asset Operation Layer）

定位： 解决"怎么用"的问题——数据资产的持续运营与价值实现。

核心能力：

• 业务语义层：让业务人员用业务语言找到数据资产
• 合规审核层：法务对数据权属和合规性的确认
• 价值评估层：财务对数据资产的估值与会计确认
• 运营监控层：资产使用追踪、价值回报计量

关键产出： 数据资产目录、合规审核报告、会计确认依据。

实施要点： 这一层需要 IT、财务、法务、业务多个部门协同。入表不是终点：数据被持续使用、产生可计量的业务回报，才是资产化的完整闭环。

层级关系

三层之间不是简单的线性推进，而是螺旋迭代的关系：

• 第一层产出（资产清单）→ 为第二层提供扫描范围
• 第二层产出（质量报告 + 标准体系）→ 为第三层提供可信基础
• 第三层运行中发现的资产变更 → 反馈到第一层更新资产清单

跳过第一层直接建标准，容易做出一堆没人用的规范；跳过第二层直接入表，写进报表的数据经不起审计。

四、架构落地案例

华东某交投集团（企业名称已脱敏）的入表过程，完整验证了三层递进模型。

起点架构状态： 上千张业务表散落在各系统中，元数据管理基本空白，质量评价从未系统化——三个架构缺口全部存在。

第一层落地（资产发现）： 历时数周的全量盘点，建立了集团首份完整数据资产清单，补齐资产目录层的空白。

第二层落地（质量量化）： 建立跨系统数据标准体系——统一命名规则、核心编码规范、质量评价框架。标准确立后，数据质量评分量化，最终达到 99.53 分。

第三层落地（资产运营）： 编目、合规审核、价值评估、会计确认——多部门协同完成首批数据资产入表。

复盘结论： 入表成功的根本原因，不是评估方法有多精妙，而是前两层的架构基础——资产发现和质量量化——走扎实了。入表不是治理的目的，而是治理架构完备之后自然产出的结果。

五、架构师 FAQ

Q1：三层递进模型和 DCMM 2.0 的关系是什么？

三层递进模型是面向入表场景的架构设计，DCMM 2.0 是全方位的成熟度评估框架。两者可以配合使用：DCMM 2.0 做成熟度基线评估，三层模型做入表专项架构落地。DCMM 2.0 中新增的"数据资产"能力域，正好对应三层模型中的第三层。

Q2：中小企业架构资源有限，怎么简化落地？

不需要完整搭建三层。建议先从最核心的一到两个业务域出发，用轻量方案跑通迷你闭环：手动盘点 + 开源质量扫描工具做基线 + 一份简版资产目录。跑通之后再考虑平台化。关键是先动起来，不必追求一步到位。

Q3：现有数据架构需要多大改动？

通常不需要推倒重来。大多数企业的数据架构已经有了"存"和"管"的基础，缺失的主要是"资产发现"和"质量量化"这两个环节。在现有架构上补这两个能力层，比新建一套体系成本低得多。具体做法是在现有数据平台或数据中台之上，增加一个资产治理模块，对接元数据采集和质量扫描能力。

Q4：入表完成之后，架构还需要维护吗？

需要。入表只是起点。数据资产会随着业务变化而演进——新增系统、字段变更、数据迁移——这些变化都需要持续反映到资产目录和质量报告中。如果入表之后就停止架构维护，下一次审计时同样会遇到数据可信度问题。建议将数据资产治理视为架构的持续运营能力，而非一次性项目。

六、结语

数据资产入表倒逼治理升级——从架构师的视角来看，这未必是坏事。

过去，技术团队推着业务走，往往感觉推不动。现在情况反过来了：CFO 和审计师在推着技术团队走，入表的硬性要求反而让治理架构的完善获得了来自业务端的驱动力。方向比从前更清晰。

从多数企业的实践来看，较为稳妥的架构建设路径是：先建资产发现层、再建质量量化层、再做资产运营层——三层架构做扎实了，入表是水到渠成的事。数据资产入表不应被视为一次性的会计操作，而应被看作企业数据治理架构走向体系化的一个起点。