3. CDE建设需求分析与规划
CDE（Common Data Environment，公共数据环境）不是一套买来即用的软件，而是围绕项目信息协同目标搭建起来的管理体系与技术平台的组合。在正式选型、部署之前，必须先完成需求分析与规划，否则极易出现"平台功能齐全但没人用""数据标准与实际交付脱节""上线后反复返工"等问题。本节围绕业务需求调研、数据需求识别、干系人分析、建设目标设定与实施路线图制定五个环节展开，说明如何把模糊的协同诉求转化为可执行的建设方案。
一、业务需求调研：从真实工作场景出发
业务需求调研的目标是弄清"谁在什么环节、因为什么原因、需要交换或使用哪些信息"。调研不能只发问卷，应结合访谈、现场观察和既有流程梳理。典型调研对象包括：业主方项目管理团队、设计各专业负责人、施工总包与分包的信息管理员、监理、造价咨询以及运维接收方。
调研时应重点记录三类信息：一是当前信息流转的实际路径，例如设计变更从提出到施工方收到图纸，中间经过哪些人、用什么工具（邮件、微信群、纸质签认）；二是痛点发生的频次与代价，例如"某项目因版本混乱导致返工，单次损失约X万元"；三是现有系统与数据格式，如BIM模型格式（IFC、RVT）、文档格式（PDF、DWG）、协同平台现状。建议用"业务场景—参与角色—输入信息—输出信息—当前问题"五列记录，形成可追溯的调研台账。
二、数据需求识别：明确"管什么数据、管到什么程度"
数据需求识别是把业务需求翻译成数据对象、数据属性与数据关系。CDE中常见的数据对象包括：模型文件、图纸、文档、表单、审批记录、进度数据、成本数据、质量安全记录等。对每一类数据，需要明确：
- 数据来源：由谁创建、在哪个阶段产生；
- 数据粒度：例如模型是按专业拆分还是按楼层拆分，文档是按单体还是按系统组织；
- 元数据要求：编号规则、版本号、状态（工作中/共享/已发布/归档）、责任人、时间戳；
- 关联关系：模型构件与图纸、变更单、验收记录之间的关联；
- 生命周期：从创建、审批、发布到归档、移交运维的完整状态流转。
以某市政桥梁项目为例，其CDE数据需求可设定为：模型按"专业—单体—构件"三级组织，构件编码采用"项目码+专业码+顺序码"共12位；文档状态分为WIP（工作中）、SHARED（共享）、PUBLISHED（已发布）、ARCHIVED（归档）四态；变更单必须关联受影响构件ID与图纸版本号。这些参数需在调研阶段与各专业确认，避免后期返工。
三、干系人分析：识别影响力与参与度
CDE建设涉及多方利益，干系人分析用于判断谁支持、谁抵触、谁需要重点沟通。可按"影响力—关注度"两个维度分类：高影响力高关注度者（如业主项目经理、设计总负责人）应深度参与需求确认；高影响力低关注度者（如企业IT部门）需定期汇报争取资源；低影响力高关注度者（如一线资料员）应纳入培训与反馈渠道；低影响力低关注度者（如外部审计）保持信息同步即可。
同时要明确每个干系人在CDE中的角色权限：谁可以创建、谁可以审批、谁只能查看、谁负责归档。权限设计应与实际管理职责一致，避免"人人可改、无人负责"。
四、建设目标设定：可衡量、分阶段
建设目标不能停留在"提高协同效率"这类口号，应转化为可衡量的指标。建议从四个维度设定：
- 覆盖度：纳入CDE的项目、专业、参与方比例；
- 及时性：信息从产生到可被授权方获取的平均时长；
- 准确性：版本错误、数据缺失的发生率；
- 合规性：审批流程留痕率、归档完整率。
例如，某项目设定一期目标为：设计阶段模型与图纸100%纳入CDE，共享状态信息平均获取时长不超过4小时，版本错误率低于1%，审批留痕率100%。目标应分阶段设定，避免一次性追求大而全。
五、实施路线图制定：从试点到推广
实施路线图把目标拆解为可执行的任务序列，通常分为四个阶段：准备期（标准制定、平台选型、试点项目确定）、试点期（在1～2个项目上跑通流程、收集问题）、推广期（扩展至更多项目、完善制度）、运营期（持续优化、移交运维）。每个阶段应明确交付物、责任人和时间节点。
下图展示了CDE需求分析与规划的整体关系：从业务调研与数据识别出发，经过干系人分析与目标设定，最终形成分阶段实施路线图，并反馈修正。
路线图不是一次性文件，而应在试点期结束后根据实际使用数据回头修正需求与目标。例如，若试点中发现某专业模型拆分粒度过细导致上传效率低，可调整数据需求中的粒度定义；若某干系人实际参与度远低于预期，需重新评估其权限与培训策略。
综上，CDE建设需求分析与规划的核心逻辑是：从真实业务出发识别数据需求，理清干系人角色与权限，设定可衡量的阶段目标，再以路线图组织落地。五个环节相互关联、迭代修正，而非线性一次性完成。只有把需求做扎实，后续的平台配置、数据迁移和协同流程才能真正服务于项目交付。