建筑业在数据时代面临的九类结构性挑战

摘要

建筑业数字化已经由单点工具应用逐步进入系统集成、数据治理与人工智能应用阶段，但信息系统数量增长并未自然转化为组织的数据能力。建筑业以项目制为主要生产组织方式，具有参与主体众多、组织关系临时化、专业分工复杂、数据生成过程分散以及建筑实体生命周期显著长于项目组织生命周期等特征。由此，建筑业的数据问题并非一般意义上的系统孤岛或技术落后问题，而是数据战略、权责配置、对象语义、技术架构、质量判断、生命周期、安全边界、智能应用和价值实现之间的结构性失配。

本文以GB/T 36073—2025《数据管理能力成熟度评估模型》所代表的组织数据管理能力框架为参照，采用规范性理论分析、项目生命周期分析、产业链主体分析和对象语义分析方法，将建筑业在数据时代面临的问题归纳为九类结构性挑战：数字化投入与经营目标脱节，项目责任清晰而数据责任模糊，同名不同义与同物不同码，项目系统繁多而企业级连续性不足，交付完整而数据未必可信，建设数据无法自然进入运营，数据开放利用与工程安全边界冲突，大模型接入数据库不等于行业智能，以及数据规模不等于数据资产能力。既有研究稿已对上述九类问题形成初步分类，其核心判断是建筑业需要从局部信息化建设转向数据责任、对象语义、质量证据和全生命周期连续性治理。

本文进一步提出，这九类挑战并非彼此孤立，而是形成一条递进的结构性因果链：战略脱嵌导致治理责任缺位，责任缺位加剧语义分裂，语义分裂造成架构断裂，架构断裂削弱数据质量和生命周期连续性，进而放大安全风险、人工智能误用和数据资产化失败。建筑业的数据时代转型，实质上要求行业建立“双重生产体系”：在生产建筑实体的同时，生产能够持续解释、治理、验证和证明建筑实体的数据事实。

关键词：建筑业；数据治理；DCMM；项目制；对象语义；数据质量；全生命周期；人工智能；数据资产

一、问题提出：建筑业为什么面临“结构性”数据挑战

建筑业数字化通常被描述为由传统生产方式向BIM、物联网、云计算、数字孪生和人工智能驱动的新型生产方式转型。这种技术演进确实提升了工程量计算、设计协同、施工组织、现场感知和运营监测能力，但也容易形成一种技术决定论假设：只要系统足够多、数据足够全、模型足够先进，建筑业的数据问题就会自然得到解决。

现实情况并非如此。

许多建筑企业已经部署项目管理、财务、成本、采购、BIM、智慧工地和物联网系统，却仍然无法稳定回答以下问题：

- 同一设备在不同系统中是否为同一个真实对象；

- 某条状态记录在什么时间和条件下有效；

- 数据错误应由哪个主体负责修正；

- 设计、采购、施工和运营数据如何保持连续；

- 系统回执是否能够证明现实行动发生；

- 模型训练是否包含在原有数据授权中；

- 项目结束后谁继续维护数据；

- 大量项目数据如何转化为企业能力。

因此，建筑业面临的不是简单的“系统不足”，而是数据管理方式与建筑生产组织方式之间的不适配。

DCMM的意义也不应被简化为数据平台建设或形式化等级评估。其核心对象是组织能否持续管理数据战略、责任、标准、架构、质量、安全、生命周期和应用价值。原始研究材料已经明确指出，DCMM真正要求企业证明的不是“有没有平台”，而是数据由谁负责、按照什么标准产生、对应什么业务对象、经过何种质量控制、在什么权限下使用并创造什么业务价值。

本文所谓“结构性挑战”，是指这些问题无法通过增加单一软件、优化局部流程或开展一次数据清洗得到根本解决，而需要调整企业战略、组织权责、对象分类、合同安排、技术架构和产业链协作关系。

二、理论基础与分析框架

2.1 建筑业的项目制与临时组织属性

建筑生产通常以项目为基本组织单元。项目具有明确的时间、预算、合同、范围和交付目标，设计单位、施工单位、专业分包、供应商和咨询机构围绕具体项目临时组合，并在项目结束后解散或转入其他项目。

临时组织具有较高的动员效率，却不天然承担长期知识和数据维护责任[5]。建筑实体可能持续存在数十年，而项目团队、合同关系和业务系统只存在数年。这种“长期实体—短期组织”之间的时间错位，是建筑数据生命周期断裂的根本原因之一。

2.2 建筑数据的跨主体共同生产属性

建筑数据并非由单一企业独立生产。

设计企业定义空间和构件，建设单位提出业务需求，供应商提供产品参数，施工企业记录现场安装，监理和检测机构形成质量结论，运营企业记录状态和维修情况。每项数据都处于多主体协作和责任关系之中。

因此，建筑数据治理不是企业内部数据库管理问题，而是产业链权利、责任和专业判断的协调问题。

2.3 建筑数据的对象指称属性

建筑数据最终需要指向现实中的建筑、空间、构件、系统、设备、任务或责任单元。字段格式正确，不代表数据指向的对象正确；不同系统中的记录名称相同，也不代表它们具有相同业务含义。

可以把建筑数据互操作划分为三个层次：

\[ ext{技术互操作}\rightarrow ext{结构互操作}\rightarrow ext{语义与对象互操作}\]

技术互操作解决系统能否连接，结构互操作解决数据格式能否转换，语义与对象互操作则解决不同系统是否在描述同一真实对象和同一业务含义。

2.4 数据、证据与事实的区分

建筑数字化经常把数据库记录、系统日志、设备回执和业务事实混为一谈。实际上：

\[ ext{Data Record} eq ext{Evidence} eq ext{Verified Fact}\]

数据记录只说明系统保存了一项内容；Evidence是能够支持特定判断的、具有对象、来源、时间和过程信息的证据材料；事实则是依据明确规则对Evidence进行质量核验后形成的判断。

由此，本文提出以下总体分析框架：

text

数据战略

→ 组织责任

→ 对象与语义标准

→ 数据架构

→ 数据质量

→ 生命周期连续

→ 安全与用途治理

→ 智能应用

→ 数据价值实现

前一环节的缺陷往往会向后一环节传导。

三、研究方法与边界

本文是一篇规范性和解释性研究论文，主要采用四种方法。

第一，制度框架分析。以DCMM所体现的数据管理能力要求为参照，分析建筑业数据问题如何由技术问题转化为组织能力问题。

第二，生命周期分解。按照规划、设计、采购、施工、验收、交付、运营、维修、更新和退役等阶段，分析数据连续性及责任转移。

第三，产业链主体分析。考察建设单位、设计企业、总承包企业、专业分包、设备供应商、监理检测机构和运营主体的数据行为及责任边界。

第四，对象语义分析。区分真实对象、模型对象、业务记录、传感器点位、状态、事件、Evidence和事实，分析数字记录与现实对象之间的关系。

本文不以DCMM为九类挑战的唯一原因，也不认为DCMM能够自动解决相关问题。DCMM在本文中主要作为观察和改善组织数据管理能力的制度参照，而不是对建筑行业具体技术方案的替代。

四、建筑业在数据时代面临的九类结构性挑战

4.1 数据战略挑战：数字化投入与经营目标脱节

许多建筑企业已经建设了大量信息系统。项目管理系统负责进度和任务管理，BIM系统负责模型和专业协同，财务系统负责核算，采购系统负责物资与供应商管理，物联网平台负责现场感知。这些系统分别解决局部业务问题，却未必形成统一的数据战略。

企业往往无法清晰回答：

- 哪些数据属于企业核心生产资料；

- 哪些数据需要跨项目持续复用；

- 哪些数据支撑经营分析和管理决策；

- 哪些数据能够形成专业知识库、行业模型或人工智能能力；

- 哪些数据可以转化为外部服务；

- 数据治理投入应如何衡量收益；

- 数据能力如何形成市场竞争优势。

原始研究材料将这一问题概括为：建筑企业系统数量不断增加，但数据工作没有真正进入企业战略，DCMM可能推动数据工作从IT预算事项上升为经营和治理事项。

从战略管理角度看，问题的本质是**数据活动与价值创造机制脱嵌**。企业部署系统时通常能够说明系统解决什么业务问题，却较少说明系统产生的数据在项目结束后如何继续发挥作用。

数据战略至少应回答四类问题：

第一，数据资源定位。哪些数据属于企业必须长期控制和维护的基础数据，哪些只是项目过程记录。

第二，能力形成机制。数据如何进入成本基准、质量知识、供应商评价、风险识别和专业模型。

第三，价值实现路径。数据通过降低成本、减少风险、改善服务还是形成新业务创造价值。

第四，治理投入逻辑。企业需要为数据质量、语义维护、权限管理和长期保存投入多少资源。

如果没有战略层面的回答，数字化容易退化为系统采购和项目成本，而不能形成企业能力。

4.2 组织治理挑战：项目责任清晰，数据责任模糊

建筑项目已经形成较为成熟的工程责任制度。项目经理、设计负责人、专业负责人、质量负责人、监理人员和安全责任人均具有明确职责。

但是，数据责任通常没有获得同等程度的制度化。

一条错误的设备参数可能来自设计输入错误、供应商样本错误、采购替换未更新、施工变更未同步、验收信息录入错误、运营系统重新编码或平台接口转换错误。系统可以记录错误，却不能自动确定：

- 谁应当首先发现问题；

- 谁有权修改；

- 谁负责审核；

- 谁承担错误造成的业务后果；

- 修正后的历史版本如何保留。

已有材料也指出，项目责任虽然明确，但数据错误可能跨越设计、供应、施工、验收和运营多个环节，企业需要建立分层数据责任体系。

这一问题可以被理解为专业责任与数据责任的分离。专业人员对设计、施工和检测结果负责，却未必对这些结果在信息系统中的表达和后续使用负责；信息化人员负责系统运行，却不具备判断专业数据是否正确的能力。

企业需要建立至少八类角色：

1. 数据所有责任人；

2. 业务数据责任人；

3. 数据管理员；

4. 系统责任人；

5. 数据质量复核人；

6. 数据安全责任人；

7. 数据使用审批人；

8. Evidence与审计责任人。

这些角色不一定分别设置为独立岗位，但其职责必须被明确分配。数据治理由此不再只是信息化部门的工作，而成为业务、法务、财务、安全、项目管理和经营管理共同参与的组织机制。

4.3 数据标准挑战：同名不同义与同物不同码

建筑产业链中的数据标准问题，表面上表现为编码不一致，深层上则是不同主体对现实对象的分类方式和管理目的不同。

同一台设备可能同时具有：

- 设计模型中的BIM GUID；

- 采购系统中的物料编码；

- 施工系统中的构件编号或任务编号；

- 资产管理系统中的资产编号；

- BMS中的设备编号；

- IoT系统中的点位编号；

- 运维系统中的工单对象；

- 检测系统中的检测对象。

这些编号不一致不是偶然错误，而是设计、采购、施工、资产、控制和维修等不同业务逻辑分别作用的结果。既有研究稿也将其概括为建筑产业链“同名不同义、同物不同码”的全生命周期语义缺口。

DCMM可以推动企业建立业务术语、主数据、参考数据、数据元、指标口径和编码映射规则，但仅统一字段名称并不能解决全部问题。建筑行业还需要回答：

- 数据究竟指向哪个真实对象；

- 对象边界如何确定；

- 映射关系在什么时间范围内有效；

- 对象拆分、合并或替换后历史如何延续；

- 模型对象是否与现场对象一致；

- 一个传感器点位是否足以代表设备状态；

- 多个系统发生身份冲突时由谁裁决。

因此，建筑数据标准需要经历三个阶段：

text

字段与格式统一

→ 业务术语和编码统一

→ 真实对象与关系语义一致

第三阶段比前两阶段更困难，因为它涉及专业判断、组织权力和长期治理，而不仅是技术转换。

4.4 数据架构挑战：项目系统多，企业级连续性弱

建筑企业的信息系统往往围绕项目建设。项目开始时部署系统、创建组织和账号，项目结束后账号关闭、团队解散、系统停用，数据被导出为文件或归档包。

这种架构能够满足项目交付，却难以持续形成企业级能力。

企业难以把分散项目数据转化为：

- 企业成本基准；

- 供应商履约画像；

- 质量缺陷知识；

- 施工工艺经验；

- 设备运行知识；

- 风险预测模型；

- 企业级高质量数据集。

原始研究材料提出，建筑企业的数据架构需要从“一个项目—一套系统—一批文件—项目结束后归档”转向项目运行系统、企业标准、主数据与元数据服务、跨项目知识事实库以及长期数据责任的组合。

其深层矛盾是：

\[ ext{项目组织的临时性} eq ext{企业知识与建筑资产的持续性}\]

合理的架构应至少区分三层：

第一层是项目运行层，满足项目快速组织、现场协同和合同交付需要。

第二层是企业治理层，维护统一主数据、元数据、指标、权限和数据质量规则。

第三层是长期知识与事实层，保存跨项目可复用的成本、质量、履约、设备和运行知识。

项目系统可以更换，但企业数据语义、对象身份和历史事实不应随系统退出而消失。

4.5 数据质量挑战：交付完整不等于数据可信

建筑项目的数据验收长期以文件数量、字段是否填写、表格是否完整和模型能否打开为主要标准。

这些标准只能证明数据在形式上存在，不能证明数据与现实一致。

典型问题包括：

- BIM模型与施工现场不一致；

- 设备台账与实际安装设备不一致；

- 工单显示完成，但维修结果未达到要求；

- 接口返回成功，但现实设备状态没有改变；

- 人工填报缺少来源、时间和版本；

- 同一指标在不同部门采用不同口径；

- 历史记录被覆盖而未保留变更关系。

既有材料因此提出，建筑数据质量应从格式完整升级为对象正确、来源明确、时间有效、版本一致、关系可信、过程可追溯和结果可复核。

本文在此基础上进一步增加“责任可定位”维度，形成八项质量条件：

\[Q_d=f(O,S,T,V,R,P,E,A)\]

其中：

- \(O\)：对象正确性；

- \(S\)：来源明确性；

- \(T\)：时间有效性；

- \(V\)：版本一致性；

- \(R\)：关系可信性；

- \(P\)：过程可追溯性；

- \(E\)：结果可复核性；

- \(A\)：责任可定位性。

这说明建筑数据质量不能只由数据库规则和IT人员判断，还需要业务规则、专业知识、现场检查、Evidence和质量核验共同参与。

数据质量还应与事实质量区分。数据准确不代表结论成立；只有数据足以支持特定判断，并经过明确规则核验后，才能形成可信事实。

4.6 数据生存周期挑战：建设数据无法自然进入运营

建筑实体可能持续使用数十年，而设计和施工项目组织通常只存在数年。建设阶段形成的数据不会因为交付仪式完成而自然成为运营数据。

交付后常见问题包括：

- 模型与实际设备不一致；

- 供应商资料不完整；

- 施工变更未进入资产台账；

- 设备替换后历史记录断裂；

- 原系统停止维护；

- 运营单位重新测绘和重新编码；

- 数据保存和更新责任不明确。

已有材料强调，数据创建、使用、维护、归档、退役和销毁需要纳入连续管理，数字交付也应从一次性交付文件转向长期维护责任。

这一挑战源于三种生命周期不一致：

text

建筑实体生命周期：数十年

项目合同生命周期：数年

信息系统生命周期：数年或更短

未来的数字交付不应只规定“交付什么”，还应规定：

- 谁维护对象身份；

- 谁更新设备状态；

- 谁处理错误映射；

- 谁保留历史版本；

- 哪些数据需要长期保存；

- 哪些数据可以归档；

- 哪些数据在何种条件下退役或销毁；

- 对象替换后新旧记录如何关联。

交付本质上应被重新定义为数据治理责任和对象维护责任的正式转移，而不是文件复制。

4.7 数据安全挑战：开放利用与工程安全边界冲突

建筑数据既具有经营价值，也可能包含敏感的物理空间和系统控制信息，包括人员信息、空间布局、门禁权限、设备控制、能源系统、基础设施运行、安全隐患和应急信息。

因此，建筑数据安全不能只依赖账号密码、网络隔离和数据库访问权限。

企业还需要明确：

- 哪类数据可以公开；

- 哪类数据只能在项目内部使用；

- 哪些数据可以跨企业共享；

- 哪些数据可以用于模型训练；

- 哪些设备数据不得出域；

- 哪些行动必须经过人工授权；

- 第三方服务商退出后如何迁移或删除数据；

- 数据开放是否可能影响工程和公共安全。

原始研究材料已经指出，建筑数据安全不仅涉及访问控制，还涉及数据开放、训练使用、设备跨域、人工授权以及第三方退出。

由此需要区分三种权力：

\[ ext{Technical Access} eq ext{Authorized Use} eq ext{Authority to Act}\]

技术上能够读取数据，不代表获得特定用途的使用授权；能够使用数据进行分析，也不代表有权控制设备或改变现实空间。

建筑数据治理需要把主体身份、数据分类分级、用途控制、行动授权、安全联锁、审计追踪和人工接管结合起来。

4.8 数据应用挑战：大模型接入数据库不等于行业智能

大模型与数据库连接可以降低查询成本，使业务人员通过自然语言访问数据，但这只解决“如何更方便地查询”，不能自动解决“数据究竟表示什么”。

大模型直接连接数据库无法可靠处理：

- 字段含义不清；

- 对象身份错误；

- 不同系统口径冲突；

- 状态真实性不足；

- 权限和用途不合法；

- 结果缺少证据；

- 日志被误认为事实。

既有材料提出，可靠的建筑行业人工智能应经过行业概念、对象身份、属性关系、时间状态、权限用途、查询推理、Evidence和质量核验等环节。

完整链条应为：

text

行业概念

→ 真实对象身份

→ 属性与关系

→ 时间与状态

→ 权限与用途

→ 数据查询与推理

→ Evidence

→ 质量核验

→ 可验证结论

这意味着大模型可靠性的决定因素不仅是模型能力，还包括语义体系、对象身份、数据来源、权限规则和事实验证机制。

必须保持以下边界：

\[ ext{SQL正确} eq ext{业务含义正确}\]

\[ ext{系统日志} eq ext{现实行动证据}\]

\[ ext{接口成功} eq ext{现实结果成立}\]

因此，DCMM对人工智能应用的深层影响，不是要求企业部署更多模型，而是推动企业首先形成机器可理解、可追溯和可治理的数据基础。

4.9 数据资产挑战：数据规模不等于资产能力

建筑企业通常拥有大量模型、图纸、合同、价格、工单、影像和传感器数据。但数据规模大，不代表数据能够形成资产或经营能力。

数据要成为可管理资源、数据产品或可持续经营能力，至少需要明确：

- 数据合法来源；

- 权利与用途边界；

- 数据质量水平；

- 可使用场景；

- 更新机制；

- 预期收益；

- 维护成本；

- 安全风险；

- 错误责任。

原始研究材料也明确指出，DCMM可以提升数据资源化和产品化能力，但不能替代法律权利判断、会计确认或市场定价。fileciteturn1file0L43-L56

需要严格区分：

text

数据资源

≠

数据产品

≠

数据资产

数据资源是组织合法控制并可以管理的数据集合；数据产品是经过加工、具有明确使用场景和交付形式的数据服务；数据资产则还需要满足组织控制、经济利益、成本计量及相关制度条件。

建筑数据资产化的困难尤其在于：

1. 数据由多主体共同生产；

2. 项目合同未必明确长期使用权；

3. 数据质量和更新责任不清；

4. 使用场景高度专业化；

5. 错误数据可能产生工程和安全责任；

6. 数据收益往往依赖持续服务而非一次交易。

因此，数据资产化不能以“拥有多少数据”为起点，而应以“能否持续合法地控制、维护、使用并创造价值”为判断基础。

五、九类挑战之间的结构性耦合

上述九类问题并不是九个独立问题，而是可以构成一条连续的失效链：

text

数据战略脱嵌

↓

组织责任缺位

↓

对象与语义分裂

↓

数据架构断裂

↓

数据质量不确定

↓

生命周期不连续

↓

安全和用途风险扩大

↓

人工智能形成错误推理或越权行动

↓

数据难以产品化和资产化

5.1 战略问题决定治理投入

如果企业未把数据视为长期生产资料，就不会持续设置数据责任、标准和维护预算。

5.2 治理问题决定标准能否执行

即使制定了数据标准，如果没有明确责任主体、审批机制和变更程序，标准也会随着项目和人员变化而失效。

5.3 标准问题决定架构能否连续

只有统一对象、术语和关系，项目系统中的数据才能进入企业级主数据、知识库和事实库。

5.4 架构问题决定质量和生命周期

如果项目数据在系统退出后只保留为文件，数据质量问题无法持续修正，生命周期关系也会断裂。

5.5 质量和生命周期决定智能应用可靠性

缺少对象身份、来源、时间和版本的数据，即使被大模型读取，也可能形成流畅但错误的解释。

5.6 治理和质量决定资产能力

没有权利边界、持续更新和质量证明的数据，很难稳定形成数据产品，更不能自动形成数据资产。

因此，建筑业不能把九类挑战分别交给九个软件模块解决，而应建立统一的数据治理体系。

六、理论命题

命题一：战略嵌入命题

建筑企业的数据治理能力取决于数据活动是否进入企业经营战略，而不是取决于信息系统数量。

当数据投入与成本、风险、服务、资产运营和知识积累等经营目标建立明确关系时，数据治理才具有持续资源基础。

命题二：责任连续命题

建筑数据质量与生命周期连续性，取决于数据责任能否跨越项目阶段和组织边界。

项目责任结束而数据责任同时消失，是建筑数据断裂的主要制度原因。

命题三：对象语义前置命题

跨系统数据整合和人工智能应用的可靠性，取决于数据是否首先建立真实对象、属性、关系和时间语义，而不是取决于接口数量或模型参数规模。

命题四：架构分层命题

建筑企业只有将项目运行架构与企业长期数据架构分层，才能兼顾项目灵活性和跨项目连续性。

命题五：证据质量命题

建筑数据的可信度不能只由格式和字段完整性判断，还需要对象、来源、时间、版本、过程、Evidence和责任共同成立。

命题六：生命周期价值命题

建筑数据价值随时间持续增长的前提，是对象身份、关系和历史记录在设计、施工、运营和更新阶段保持连续。

命题七：用途治理命题

建筑数据安全的核心不只是控制谁可以访问，还包括控制谁可以基于数据在何种目的、范围和责任条件下采取行动。

命题八：智能可靠性命题

大模型在建筑行业中的可靠性主要受到行业语义、真实对象锚定、权限治理和证据机制的约束，而不仅由模型能力决定。

命题九：资产能力命题

建筑数据只有形成合法来源、持续控制、质量维护、明确场景和可验证收益的完整能力，才可能从数据资源进一步转化为数据产品或资产。

七、DCMM的制度作用及其边界

DCMM可以为建筑企业提供统一的数据管理能力语言，推动数据工作从分散系统建设转向战略、治理、标准、架构、质量、安全、生命周期和应用的整体管理。

其可能产生的作用包括：

- 使企业管理层正式承担数据治理责任；

- 推动数据责任进入岗位和流程；

- 促进业务术语、主数据和指标口径统一；

- 要求数据质量具有审查证据；

- 推动数据生命周期和安全制度建立；

- 促进数据应用与经营价值关联。

但必须明确，DCMM不能直接解决所有行业问题。

它不能替代：

- 建筑专业标准；

- 工程质量判断；

- 数据法律权利确认；

- 会计资产确认；

- 真实对象语义建模；

- 专业系统安全控制；

- 现场Evidence和第三方核验。

DCMM更适合作为组织能力框架，行业语义、对象身份、专业规则和真实场景闭环仍需由建筑产业链主体共同建立。

八、治理与实践建议

8.1 从一个真实闭环开始，而不是先建大型平台

企业应优先选择成本核算、设备维修、质量整改、材料追溯、能源管理或数字交付等场景，验证：

text

真实对象

→ 数据生成

→ 责任确认

→ 权限控制

→ 业务使用

→ Evidence

→ 质量核验

→ 经营结果

只有一个小场景能够稳定闭环，才适合继续扩大范围。

8.2 把数据要求写入项目合同

合同需要明确：

- 数据交付范围；

- 数据标准；

- 对象编码；

- 更新责任；

- 权利与用途；

- 模型训练权限；

- 数据质量；

- 历史记录；

- 项目结束后的迁移和删除要求。

8.3 建立企业级真实对象和主数据体系

各系统可以保留自身编号，但应建立跨系统映射、有效期、版本、来源和复核状态，避免简单用一个新编码替换所有旧编码。

8.4 区分数据质量、Evidence质量和事实质量

企业应分别评价：

- 数据本身是否准确；

- Evidence是否完整；

- 结论是否按照明确规则成立。

8.5 建立长期数据责任

数字交付不应以模型文件移交为终点，而应建立从建设到运营的数据维护、变更、退役和替代机制。

九、研究局限与后续议程

本文主要进行理论和制度分析，尚未基于大规模企业样本对九类结构性挑战进行量化检验。

后续研究可围绕以下问题展开：

第一，不同类型建筑企业在九类挑战上的成熟度是否存在显著差异。

第二，建设单位、设计企业、施工企业和运营主体的数据责任如何通过合同重新配置。

第三，对象身份一致性、Evidence完整性和业务绩效之间是否存在可测量关系。

第四，DCMM成熟度提升是否能够显著改善跨项目数据复用和人工智能应用效果。

第五，真实对象协议、行业语义Profile和小范围闭环能否在不同项目之间复制。

十、结论

建筑业在数据时代面临的根本问题，不是信息系统数量不足，而是传统项目制生产方式尚未形成与之匹配的数据治理制度。

九类结构性挑战共同表明：

- 数据没有充分进入企业战略；

- 数据责任尚未完成组织化；

- 对象和语义仍然分裂；

- 项目架构难以支撑长期知识；

- 数据质量缺乏事实和证据基础；

- 建设数据无法自然延续至运营；

- 安全治理没有覆盖数据用途和现实行动；

- 人工智能应用缺乏可靠语义前提；

- 数据规模尚未转化为资产能力。

建筑业的数据时代转型，最终需要形成双重生产体系。既有研究对此作出的概括具有高度解释力：

一条生产建筑实体，一条生产能够持续解释、治理和证明建筑实体的数据。

这意味着，项目交付不再只以建筑实体完成为终点，还应形成真实对象身份、数据来源、责任关系、生命周期记录、Evidence和可验证结果。

DCMM能够提供组织能力建设的制度度量衡，但真正决定建筑业能否完成转型的，是企业和产业链能否把数据从项目副产品转化为长期生产资料，把系统记录转化为可信Evidence，把分散信息转化为可以跨阶段使用和验证的数据事实。