配置管理计划用于说明研发过程中哪些资产需要受控、由谁负责、何时形成基线、变更如何审批以及状态如何记录。一份可直接评审的计划通常包含目的与范围、角色与职责、配置项识别规则、基线与发布、变更控制、配置状态记录、配置审计、工具与库管理、培训与例外九个章节，并配套配置项清单表、基线清单表、变更申请与审批表、配置状态记录表、配置审计检查表五张关键表格。本文提供可复制的空白文档框架、空白表样、字段说明与填写示例，适用于研发项目在启动或阶段评审前编制配置管理计划。
要点总览（TL;DR）
- 配置管理计划正文建议包含九个章节：目的与范围、角色与职责、配置项识别规则、基线与发布、变更控制、配置状态记录、配置审计、工具与库管理、培训与例外。
- 配套五张关键表格：配置项清单表、基线清单表、变更申请与审批表、配置状态记录表、配置审计检查表，分别对应识别、基线、变更、状态和审计五个管理动作。
- 评审前必须填满目的与范围、角色与职责、配置项识别规则、基线与发布、变更控制，以及配置项清单、基线清单、变更审批表中的关键字段；状态记录频率、审计频次可按项目规模调整。
- 填写时注意区分配置项版本与基线版本：前者是单个配置项的最新受控版本，后者是一组配置项在基线建立时整体固化的标识。
- 计划本身也是受控文档，受控范围、基线类型、审批层级、配置库或工具变更、审计发现系统性问题时应触发修订，并在阶段评审或里程碑节点复核。
可复制空白模板：配置管理计划正文框架
下面给出配置管理计划的正文骨架。使用时保留章节标题，将方括号中的占位内容替换为项目实际信息；表格位置先写“见附表编号”，待正文定稿后再插入对应表格。
封面与版本信息栏
| 项目 | 填写内容 |
|---|---|
| 文档名称 | [项目名称] 配置管理计划 |
| 文档编号 | [如 CMP-PROJ-001] |
| 版本 | [V0.1 / V1.0] |
| 编制人 / 日期 | [姓名] / [YYYY-MM-DD] |
| 评审人 / 日期 | [姓名] / [YYYY-MM-DD] |
| 批准人 / 日期 | [姓名] / [YYYY-MM-DD] |
| 适用范围 | [项目或产品线名称、阶段范围] |
正文章节占位
- 目的与范围：说明本计划适用的项目、阶段、受控资产类型，以及与其他项目计划的关系。
- 角色与职责：列出配置管理员、变更审批人、配置项负责人、审计人等角色及其职责边界。
- 配置项识别规则：定义哪些工作产物纳入配置管理、命名规则、版本编号规则、入库时机。引用附表一配置项清单表。
- 基线与发布：定义基线类型（如需求基线、设计基线、测试基线、发布基线）、建立条件、审批人和发布方式。引用附表二基线清单表。
- 变更控制：说明变更申请入口、影响分析要求、审批层级、实施与验证、关闭条件。引用附表三变更申请与审批表。
- 配置状态记录：规定状态记录频率、记录内容、报告对象。引用附表四配置状态记录表。
- 配置审计：说明功能审计与物理审计的时机、检查项、责任人和问题处理方式。引用附表五配置审计检查表。
- 工具与库管理：说明配置库结构、访问权限、备份策略，以及承载配置项与变更记录的工具。
- 培训与例外：说明相关人员的培训安排，以及偏离本计划时的申请与批准方式。
五张关键表格的空白表样
五张表格分别对应配置项识别、基线建立、变更审批、状态记录和审计检查五个管理动作。表头可直接复制到文档或表格工具中，示例行用于说明填写位置，正式使用时删除。
附表一：配置项清单表
| 配置项编号 | 配置项名称 | 类别 | 负责人 | 当前版本 | 所属基线 | 存放位置 | 状态 |
|---|---|---|---|---|---|---|---|
| [CI-001] | [名称] | [需求/设计/代码/测试/文档] | [姓名] | [V1.0] | [基线编号] | [库路径] | [草稿/受控/已基线] |
附表二：基线清单表
| 基线编号 | 基线名称 | 基线类型 | 包含配置项 | 建立日期 | 审批人 | 基线版本 | 状态 |
|---|---|---|---|---|---|---|---|
| [BL-001] | [名称] | [需求/设计/测试/发布] | [配置项编号列表] | [YYYY-MM-DD] | [姓名] | [V1.0] | [已建立/已变更/已关闭] |
附表三：变更申请与审批表
| 变更编号 | 关联配置项 | 变更内容 | 申请人 | 申请日期 | 影响分析 | 审批人 | 审批结论 | 实施日期 | 关闭日期 |
|---|---|---|---|---|---|---|---|---|---|
| [CR-001] | [CI-001] | [变更描述] | [姓名] | [YYYY-MM-DD] | [影响范围] | [姓名] | [批准/驳回/待定] | [YYYY-MM-DD] | [YYYY-MM-DD] |
附表四：配置状态记录表
| 记录日期 | 配置项编号 | 当前版本 | 状态 | 变更编号 | 记录人 | 备注 |
|---|---|---|---|---|---|---|
| [YYYY-MM-DD] | [CI-001] | [V1.1] | [受控] | [CR-001] | [姓名] | [说明] |
附表五：配置审计检查表
| 审计编号 | 审计类型 | 审计对象 | 检查项 | 检查结果 | 问题描述 | 责任人 | 整改期限 | 关闭状态 |
|---|---|---|---|---|---|---|---|---|
| [AU-001] | [功能/物理] | [基线编号或配置项] | [检查内容] | [符合/不符合] | [问题] | [姓名] | [YYYY-MM-DD] | [已关闭/未关闭] |
字段说明：每个章节和表格字段填什么
字段说明的作用是让不同填写人对同一字段采用相同口径。章节字段说明填写目的与边界，表格字段说明取值来源和判断标准，两者共同保证模板、说明与示例一致。
正文章节字段说明
| 章节 | 填写要点 | 完成标志 |
|---|---|---|
| 目的与范围 | 写明项目名称、阶段、受控资产类型；说明本计划不覆盖的内容 | 读者能判断哪些工作产物受本计划约束 |
| 角色与职责 | 每个角色写清决策权、执行动作和交接对象 | 变更审批人和配置管理员无空缺 |
| 配置项识别规则 | 给出纳入标准、命名规则、版本编号规则、入库时机 | 能据此判断一个新产物是否应进入配置项清单 |
| 基线与发布 | 列出基线类型、建立条件、审批人、发布方式 | 每种基线都有明确的建立时点和审批人 |
| 变更控制 | 说明申请入口、影响分析要求、审批层级、验证与关闭条件 | 一条变更从申请到关闭的路径完整 |
| 配置状态记录 | 规定记录频率、记录人、报告对象 | 状态记录能回答“某配置项当前是什么版本、处于什么状态” |
| 配置审计 | 区分功能审计与物理审计，写明时机、检查项和问题处理 | 审计发现的问题有责任人和整改期限 |
| 工具与库管理 | 说明库结构、权限、备份策略和承载工具 | 配置项存放位置可被定位和访问 |
| 培训与例外 | 写明培训对象、时机，以及例外申请与批准方式 | 偏离计划的情形有明确处理路径 |
表格字段定义与取值口径
- 配置项编号：按项目约定的编码规则生成，一经分配不重复使用；配置项废止后保留编号并标记状态。
- 类别：按组织约定的分类填写，常见为需求、设计、代码、测试、文档；分类用于统计和审计抽样。
- 当前版本：指该配置项自身的最新受控版本，每次经批准的变更产生新版本。
- 基线版本：指一组配置项在基线建立时被整体固化的版本标识，与单个配置项的当前版本不同。基线版本变化意味着基线内容发生整体调整，需要重新审批。
- 所属基线：填写配置项被纳入的基线编号；未纳入任何基线时填“无”。
- 状态：配置项状态可取草稿、受控、已基线、已废止；基线状态可取已建立、已变更、已关闭。
- 影响分析：写明变更波及的配置项、基线、测试范围和交付节点，作为审批依据。
- 审批结论：取值为批准、驳回、待定；待定需注明补充材料要求。
- 审计类型：功能审计检查配置项是否满足规定要求，物理审计检查配置项的实际存在与记录是否一致。
必填与选填：评审前必须填满的部分
评审阻断项是那些缺失后无法判断配置管理是否可执行的内容。建议在评审前先填满必填项，选填项按项目规模和阶段补充。
| 类别 | 字段或章节 | 填写理由 |
|---|---|---|
| 必填 | 目的与范围、角色与职责、配置项识别规则、基线与发布、变更控制 | 缺少任一项，配置管理的责任、对象和变更路径无法确定 |
| 必填 | 配置项清单表的编号、名称、类别、负责人、存放位置 | 配置项是后续基线和变更管理的基础 |
| 必填 | 基线清单表的基线编号、类型、包含配置项、审批人 | 基线建立需要明确审批责任 |
| 必填 | 变更申请与审批表的变更编号、关联配置项、审批人、审批结论 | 保证变更可追溯、可追责 |
| 选填 | 配置状态记录表的记录频率与报告对象 | 小型项目可随变更事件记录，不必固定周期 |
| 选填 | 配置审计检查表的审计频次 | 可按阶段或里程碑安排，早期项目可减少频次 |
| 可裁剪 | 培训与例外章节 | 团队已熟悉流程且无例外情形时，可合并到角色与职责中简述 |
| 可裁剪 | 工具与库管理章节 | 使用组织统一配置库时，可引用组织级规定，不重复展开 |
裁剪的依据是项目规模、阶段和合规要求。涉及外部交付或合规审计的项目，建议保留全部章节和表格；内部迭代型项目可先保留必填项，随阶段推进补充状态记录和审计内容。
填写示例：一份填好的配置管理计划片段
以下为演示情景，用于说明字段如何落到具体内容，不代表真实项目数据。
示例项目背景与受控范围
某研发项目处于需求与设计阶段，受控范围包括需求文档、接口设计文档、核心模块代码和测试用例。配置管理员由项目助理兼任，变更审批人为项目经理和技术负责人。
配置项清单与基线清单样例
| 配置项编号 | 配置项名称 | 类别 | 负责人 | 当前版本 | 所属基线 | 存放位置 | 状态 |
|---|---|---|---|---|---|---|---|
| CI-001 | 产品需求规格说明书 | 需求 | 张工 | V1.2 | BL-001 | 配置库/需求 | 已基线 |
| CI-002 | 接口设计文档 | 设计 | 李工 | V1.0 | BL-002 | 配置库/设计 | 已基线 |
| CI-003 | 订单模块代码 | 代码 | 王工 | V1.1 | 无 | 代码库/order | 受控 |
| 基线编号 | 基线名称 | 基线类型 | 包含配置项 | 建立日期 | 审批人 | 基线版本 | 状态 |
|---|---|---|---|---|---|---|---|
| BL-001 | 需求基线 | 需求 | CI-001 | 2025-03-10 | 项目经理 | V1.0 | 已建立 |
| BL-002 | 设计基线 | 设计 | CI-002 | 2025-04-02 | 技术负责人 | V1.0 | 已建立 |
一条变更从申请到关闭的记录样例
| 变更编号 | 关联配置项 | 变更内容 | 申请人 | 申请日期 | 影响分析 | 审批人 | 审批结论 | 实施日期 | 关闭日期 |
|---|---|---|---|---|---|---|---|---|---|
| CR-001 | CI-001 | 新增订单取消规则 | 张工 | 2025-04-08 | 影响需求基线 BL-001、测试用例 3 条 | 项目经理 | 批准 | 2025-04-10 | 2025-04-15 |
该变更批准后，CI-001 版本由 V1.2 升至 V1.3，需求基线 BL-001 状态标记为已变更并重新审批；配置状态记录表同步记录本次版本变化和变更编号。配置项与变更记录需要在协作平台中保持状态一致，ONES ALM 方案围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯，可作为承载配置项状态与变更流转的工具选择之一。具体表单结构需结合组织流程在工具中配置。
调整与维护：计划随项目演进如何更新
配置管理计划本身也是受控文档，需要版本管理、评审节奏和明确的修订触发条件。维护的重点是让计划与实际执行保持一致，避免计划停留在立项时的状态。
计划本身的版本与审批记录
| 版本 | 修订日期 | 修订内容 | 修订人 | 审批人 |
|---|---|---|---|---|
| V0.1 | [YYYY-MM-DD] | 初稿 | [姓名] | [姓名] |
| V1.0 | [YYYY-MM-DD] | 评审通过 | [姓名] | [姓名] |
触发修订的情形
- 受控范围发生变化，例如新增产品线、新增交付物类型或阶段范围调整。
- 基线类型或审批层级调整，例如合规要求提高后需要增加审批节点。
- 配置库结构、工具或权限策略变更。
- 配置审计发现系统性问题，现有规则无法覆盖。
- 组织级配置管理流程更新，需要项目计划同步对齐。
定期复核与归档方式
建议在阶段评审或里程碑节点复核计划，确认配置项清单、基线清单与实际一致，状态记录和审计问题已关闭。项目结束时，将配置管理计划、各附表记录和审计结果一并归档，归档版本标记为最终版，并保留审批记录以便后续追溯。复核频率可按项目周期确定，周期较长的项目可设置季度复核。
常见问题
小型项目可以只保留部分章节和表格吗？
可以按项目规模和合规要求裁剪。建议先保留目的与范围、角色与职责、配置项识别规则、基线与发布、变更控制五个必填章节，以及配置项清单表、基线清单表、变更申请与审批表的关键字段。配置状态记录频率和审计频次可以随变更事件或里程碑安排，培训与例外、工具与库管理在团队已熟悉流程、使用组织统一配置库时可合并或引用组织级规定。涉及外部交付或合规审计的项目，建议保留全部章节和表格。
配置项清单表和基线清单表是什么关系？
配置项清单表记录单个受控资产的编号、名称、类别、负责人、当前版本和存放位置；基线清单表记录一组配置项在某个时点被整体固化的结果，包括基线编号、类型、包含的配置项、建立日期和审批人。配置项清单表中的“所属基线”字段指向基线编号，未纳入任何基线时填“无”。基线建立后，基线内配置项的版本变化需要经过变更审批并重新建立或更新基线。
配置状态记录需要固定周期填写吗？
不强制固定周期。状态记录的目的是能回答“某配置项当前是什么版本、处于什么状态、由哪次变更引起”。小型项目可以随变更事件记录，在每次变更关闭时更新；周期较长或并行变更较多的项目，可设置固定记录频率并向项目经理或配置控制委员会报告。无论采用哪种方式，记录内容应包含记录日期、配置项编号、当前版本、状态、关联变更编号和记录人。
配置审计检查表应该检查哪些内容？
配置审计分为功能审计和物理审计。功能审计检查配置项是否满足规定的要求，例如需求文档与设计文档、测试用例之间是否一致；物理审计检查配置项的实际存在与记录是否一致，例如配置库中的版本、存放位置与配置项清单表是否吻合。检查表应记录审计编号、审计类型、审计对象、检查项、检查结果、问题描述、责任人和整改期限，审计发现的问题需跟踪到关闭状态。
配置管理计划制定后，什么情况下需要修订？
常见触发情形包括：受控范围变化，如新增产品线、交付物类型或阶段范围调整；基线类型或审批层级调整；配置库结构、承载工具或权限策略变更；配置审计发现系统性问题，现有规则无法覆盖；组织级配置管理流程更新。修订后应更新计划版本和审批记录，并在阶段评审或里程碑节点复核配置项清单、基线清单与实际执行是否一致。
