2. 工程数据治理框架

CDE 不是把文件集中到一个平台就结束了。真正决定 CDE 能否长期可用的，是它背后那套治理框架：数据被怎样分类分级、元数据由谁维护、质量规则如何落地、责任如何划分、成熟度如何评估。这五件事构成一个闭环——分类分级决定数据“怎么管”，元数据管理解决“怎么找、怎么理解”，质量规则解决“怎么信”，责任矩阵解决“谁来管”，成熟度评估解决“管得怎么样、下一步往哪走”。

一、数据分类分级：先定“管什么、管多严”

工程数据分类分级不是给文件贴个标签，而是为后续权限、质量、责任提供统一坐标。分类回答“这是什么数据”，分级回答“它有多重要、泄露或错误会造成多大影响”。

分类维度建议按“专业域 + 数据形态”双轴展开。专业域可划分为：建筑、结构、给排水、暖通、电气、总图、工艺等；数据形态可划分为：模型数据（IFC、RVT）、图纸数据（DWG、PDF）、文档数据（方案、计算书、说明）、结构化数据（构件属性表、工程量清单）、过程数据（会议纪要、变更单、审批记录）。

分级建议采用四级：L1 公开级、L2 内部级、L3 受控级、L4 核心级。判断依据可参考三个问题：数据是否涉及知识产权或商业秘密；数据错误是否会导致返工、安全或合规风险；数据是否被多个专业或阶段复用。例如，结构计算书通常为 L3，涉及核心受力体系的关键计算书可定为 L4；一般性会议纪要多为 L2；对外公开的效果图可定为 L1。

二、元数据管理：让数据“可找、可懂、可追溯”

元数据是“关于数据的数据”。在 CDE 中，元数据管理要解决三个问题：这份数据是什么、谁在什么时候为什么创建、它和哪些数据有关。

工程元数据建议分三层：业务元数据（专业、阶段、用途、责任方）、技术元数据（文件格式、版本、坐标系、单位制、软件来源）、管理元数据（创建时间、审批状态、密级、关联变更单号）。以一份 IFC 模型为例，其元数据可包含：专业=结构，阶段=施工图，坐标系=项目基点，单位=米，版本=V2.3，审批状态=已批准，密级=L3，关联变更=BG-2024-017。

元数据不是一次性录入，而是随数据流转持续更新。建议在 CDE 中设置“元数据必填字段”，未填写完整的数据不允许进入共享区。同时建立元数据字典，统一字段名称、取值范围和填写规范，避免同一含义出现多种写法。

三、数据质量规则：把“可信”变成可检查的条件

数据质量规则要具体到可执行、可验证。工程数据常见质量问题包括：模型缺构件、属性缺失、版本混乱、坐标系不一致、图纸与模型不符。对应规则可分为四类：完整性、一致性、准确性、及时性。

以下是一组可直接参考的质量规则示例（参数为教学示例，非实测值）：

质量规则应尽量自动化。可在 CDE 中配置规则引擎，对模型进行批量检查，输出“合格/不合格/待确认”三态结果。规则不是越多越好，初期建议聚焦 5～8 条高频、高影响规则，稳定后再逐步扩展。

四、数据责任矩阵：每份数据都要有明确的人

责任矩阵的核心是回答“谁创建、谁审核、谁批准、谁使用”。推荐采用 RACI 变体：R（负责执行）、A（最终批准）、C（被咨询）、I（被通知）。在 CDE 中，责任矩阵应与角色和权限绑定，而不是停留在文档里。

以“结构专业模型”为例：建模工程师为 R，专业负责人为 A，暖通和电气专业为 C，项目经理和施工方为 I。当模型进入共享区前，系统应自动校验 A 是否完成审批；未审批的数据只能停留在工作区，不能对外发布。

责任矩阵还要覆盖“数据退役”。当某版本被替代后，应明确谁负责归档、谁负责通知下游、旧版本保留多久。建议在 CDE 中设置版本状态字段：工作中、待审批、已批准、已发布、已归档、已作废。

五、治理成熟度评估：知道现在在哪，下一步去哪

成熟度评估不是打分排名，而是找出短板、确定改进优先级。建议从五个维度评估：分类分级覆盖率、元数据完整率、质量规则自动化率、责任矩阵执行率、数据复用率。每个维度按 1～5 级评分，1 级为临时手工，5 级为自动闭环。

评估周期建议每季度一次。评估结果应形成“差距清单”，并转化为下一季度的改进任务。例如，若元数据完整率仅为 2 级，改进任务可设定为“下季度将必填字段完整率提升至 90%以上”。

这五个要素不是并列关系，而是相互支撑的闭环：分类分级为元数据和权限提供依据；元数据为质量规则提供检查对象；质量规则的结果需要责任矩阵来闭环处理；责任矩阵的执行情况又成为成熟度评估的输入；评估发现的差距反过来推动分类分级和元数据的改进。只有这个闭环转起来，CDE 才不是静态的文件仓库，而是持续产生可信数据的工程基础设施。