计划基线变更记录表的核心结构是“一次变更一行”：把变更对象、变更前后内容、影响评估、版本号、审批角色与结论、生效时间放在同一行内，便于逐条追溯。版本信息建议用“基线版本号+变更序号”两级标识，审批字段按提出、评估、批准、生效四类角色分列，审批意见单独成列，避免塞进备注。下面给出可直接复制的空白表、字段口径、必填清单、完整示例和维护规则。
要点总览（TL;DR）
- 模板采用“一次变更一行”结构，主表记录变更对象、影响评估、版本信息、审批流转四组字段，版本登记表记录每个基线版本的生效状态。
- 版本信息用“基线版本号+变更序号”两级标识：基线版本号按V主版本.次版本编制，变更序号在同一版本下从01连续编号。
- 审批字段按提出、评估、批准、生效四类角色分列，评估结论与审批结论分开记录，审批意见不写入备注。
- 必填字段保证记录可识别、可追溯、可审批；条件必填字段在对应变更类型或状态触发时转为必填。
- 维护遵循只增不改原则，作废用状态标记，新版本生效当天同步更新旧版本的失效时间和替代版本。
可复制空白模板：计划基线变更记录表
模板由两张表组成：变更记录主表承载每一次变更的完整信息，基线版本登记表记录每个基线版本的生效状态。两张表通过“基线版本号”关联，主表记录过程，登记表记录结果。复制到文档或表格工具时，建议把主表第一列设为变更编号并保持唯一，登记表按版本号升序排列。
变更记录主表（空白）
| 变更编号 | 基线名称 | 受影响工作项 | 变更类型 | 变更前内容 | 变更后内容 | 工期影响 | 成本影响 | 范围影响 | 依赖影响 | 变更原因 | 基线版本号 | 变更序号 | 生效版本 | 提出人 | 提出时间 | 评估人 | 评估结论 | 评估时间 | 审批人 | 审批结论 | 审批时间 | 生效时间 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
基线版本登记表（空白）
| 基线版本号 | 基线名称 | 版本说明 | 包含变更编号 | 批准人 | 批准时间 | 生效时间 | 版本状态 | 失效时间 | 替代版本 |
|---|---|---|---|---|---|---|---|---|---|
字段说明：每个字段记录什么、怎么填
主表字段按四组组织：变更对象、影响评估、版本信息、审批流转。分组的作用是让填写人按顺序推进，先明确改什么，再评估影响，然后确定版本，最后走审批。下表逐字段说明口径，与S1模板列顺序一致。
| 字段 | 所属分组 | 记录内容与填写口径 |
|---|---|---|
| 变更编号 | 变更对象 | 本次变更的唯一标识，建议采用“基线缩写-年份-流水号”，如PLN-2025-003。全表不重复。 |
| 基线名称 | 变更对象 | 被变更的基线全称，与版本登记表保持一致，如“一期交付进度基线”。 |
| 受影响工作项 | 变更对象 | 列出受影响的WBS节点、里程碑或交付物编号，多个用分号分隔。范围要具体到可定位的条目。 |
| 变更类型 | 变更对象 | 从固定选项中选择：范围变更、工期变更、成本变更、依赖变更、里程碑调整。一次变更涉及多类时，填主导类型并在备注说明。 |
| 变更前内容 | 变更对象 | 引用原基线的具体数值或描述，如“里程碑M3计划完成日2025-06-30”。写事实，不写评价。 |
| 变更后内容 | 变更对象 | 变更后的对应数值或描述，与变更前逐项对应，便于直接比对。 |
| 工期影响 | 影响评估 | 对总工期或关键路径的影响天数和方向，如“关键路径延长5个工作日”。无影响填“无”。 |
| 成本影响 | 影响评估 | 增减金额及口径，如“增加人力成本约2人月”。无法量化时写明估算依据。 |
| 范围影响 | 影响评估 | 交付物增减、验收标准变化等，说明是否涉及合同或需求基线联动。 |
| 依赖影响 | 影响评估 | 对外部团队、供应商、前置任务的依赖变化，注明需要同步通知的对象。 |
| 变更原因 | 变更对象 | 触发变更的事实，如“供应商交付延迟两周”。与影响评估分开写，避免混在一起。 |
| 基线版本号 | 版本信息 | 变更所基于的基线版本，如V1.0。表示这次变更从哪个版本出发。 |
| 变更序号 | 版本信息 | 同一基线版本下的变更流水号，从01开始递增。与版本号组合形成唯一标识，如V1.0-02。 |
| 生效版本 | 版本信息 | 本次变更批准后形成的基线版本，如V1.1。未批准时留空。 |
| 提出人 | 审批流转 | 发起变更的人员姓名与角色。 |
| 提出时间 | 审批流转 | 变更申请提交日期，精确到日。 |
| 评估人 | 审批流转 | 负责影响评估的人员，通常是计划负责人或技术负责人。 |
| 评估结论 | 审批流转 | 评估意见与建议，如“影响可控，建议批准”。与审批结论分列，保留评估独立性。 |
| 评估时间 | 审批流转 | 评估完成日期。 |
| 审批人 | 审批流转 | 有权批准该级别变更的人员或角色，如项目经理、项目指导委员会。 |
| 审批结论 | 审批流转 | 批准、驳回、有条件批准。有条件批准需在备注写明条件。 |
| 审批时间 | 审批流转 | 审批决定作出日期。 |
| 生效时间 | 审批流转 | 新基线正式替代旧基线的日期，与版本登记表一致。 |
| 状态 | 审批流转 | 草稿、评估中、待审批、已批准、已生效、已驳回、已作废。状态驱动后续动作。 |
| 备注 | 审批流转 | 补充说明，如审批条件、关联会议纪要编号。审批意见不写在这里。 |
版本登记表字段口径：基线版本号按S5规则编制；版本说明用一句话概括该版本相对上一版的变化；包含变更编号列出构成该版本的全部主表记录；批准人与批准时间对应最终审批；版本状态分为生效、已失效、草稿；失效时间与替代版本用于标记被新版本取代的旧版本，保留历史可查。
必填与选填：哪些字段不能空
必填字段保证每条记录可识别、可追溯、可审批。条件必填字段在特定情形下转为必填，其余为选填。团队治理强度不同，可以把条件必填提升为必填，但不宜把必填降为选填，否则记录失去追溯价值。
必填字段
- 变更编号、基线名称、变更类型、变更原因：缺少任一项，记录无法定位和解释。
- 变更前内容、变更后内容：变更记录的核心事实，必须成对填写。
- 基线版本号、变更序号：版本追溯的起点，未填则无法与登记表关联。
- 提出人、提出时间：责任与时效的起点。
- 状态：驱动流程流转，新建记录至少填“草稿”。
条件必填字段
- 受影响工作项：变更类型为范围、工期、依赖变更时必填，需具体到条目。
- 工期影响、成本影响、范围影响、依赖影响：对应变更类型触发时必填，如工期变更必须填工期影响，其余可填“无”。
- 评估人、评估结论、评估时间：状态进入“待审批”前必填。
- 审批人、审批结论、审批时间：状态为“已批准”或“已驳回”时必填。
- 生效版本、生效时间：状态为“已生效”时必填，且与版本登记表一致。
选填字段
- 备注：用于补充会议纪要编号、审批附加条件等，没有可留空。
- 版本登记表中的失效时间、替代版本：仅在旧版本被取代时填写。
留空与待补的标记约定：尚未取得的信息统一填“待补”，并在备注注明责任人和预计补齐日期；确认无影响的评估项填“无”，与“待补”区分开。这样复核时能一眼看出哪些是真实结论、哪些是缺口。
填写示例：一次工期基线变更的完整记录
以下为演示情景：某交付项目因供应商延迟，需要把里程碑M3的完成日期后移。示例用于说明字段联动，数值为虚构。
主表记录（一行）
| 字段 | 填写内容 |
|---|---|
| 变更编号 | PLN-2025-003 |
| 基线名称 | 一期交付进度基线 |
| 受影响工作项 | M3 集成测试完成；WBS 4.2 接口联调 |
| 变更类型 | 工期变更 |
| 变更前内容 | M3计划完成日2025-06-30 |
| 变更后内容 | M3计划完成日2025-07-11 |
| 工期影响 | 关键路径延长9个工作日，总工期顺延 |
| 成本影响 | 增加约1.5人月 |
| 范围影响 | 无 |
| 依赖影响 | 需同步通知验收团队调整窗口 |
| 变更原因 | 供应商接口交付延迟两周 |
| 基线版本号 | V1.0 |
| 变更序号 | 02 |
| 生效版本 | V1.1 |
| 提出人 | 计划负责人 张某 |
| 提出时间 | 2025-06-10 |
| 评估人 | 技术负责人 李某 |
| 评估结论 | 影响可控，建议批准并同步验收窗口 |
| 评估时间 | 2025-06-12 |
| 审批人 | 项目经理 王某 |
| 审批结论 | 批准 |
| 审批时间 | 2025-06-13 |
| 生效时间 | 2025-06-16 |
| 状态 | 已生效 |
| 备注 | 关联变更评审会纪要2025-06-12 |
版本登记表记录（一行）
| 字段 | 填写内容 |
|---|---|
| 基线版本号 | V1.1 |
| 基线名称 | 一期交付进度基线 |
| 版本说明 | M3完成日后移至2025-07-11，总工期顺延9个工作日 |
| 包含变更编号 | PLN-2025-003 |
| 批准人 | 项目经理 王某 |
| 批准时间 | 2025-06-13 |
| 生效时间 | 2025-06-16 |
| 版本状态 | 生效 |
| 失效时间 | — |
| 替代版本 | — |
编号过程：原基线为V1.0，此前已有一次变更记为V1.0-01，本次为V1.0-02。批准后形成新基线V1.1，登记表新增一行；同时把V1.0行的版本状态改为“已失效”，失效时间填2025-06-16，替代版本填V1.1。审批链路在记录中完整呈现：提出→评估→批准→生效，四个时间点依次递增，状态与时间相互印证。
调整与维护方法：版本编号规则与表格维护
版本编号规则决定记录能否长期对齐。建议采用两级标识：基线版本号用“V主版本.次版本”，主版本在基线范围或里程碑结构发生重大调整时递增，次版本在常规变更批准后递增；变更序号在同一基线版本下从01连续编号，不跳号、不复用。一次变更批准后，生效版本取下一个次版本号，未批准前生效版本留空。
维护操作清单
- 只增不改：已生效的记录不修改原值，需要更正时新增一条更正记录，在备注注明被更正记录编号。
- 作废用状态标记：不再适用的记录把状态改为“已作废”，保留行和原内容，不删除。
- 关联归档：每条记录关联计划文档版本号、评审纪要编号和审批记录，归档时按基线名称和版本号建立目录。
- 定期复核：每月或每个里程碑节点复核一次，检查状态为“待审批”超期的记录、生效版本与登记表不一致的记录。
- 失效版本标记：新版本生效当天，同步更新登记表中旧版本的失效时间和替代版本，避免两个版本同时显示为生效。
当变更记录和审批在文档、表格中分散维护时，版本对齐和状态同步容易出错。ONES 的项目计划支持设置项目计划和里程碑基线，并实时对比计划与执行的偏差；版本细节可对比追溯变更内容，需求、基线、版本和变更也可作为统一管理对象，支撑变更影响分析与交付结果回溯。把变更记录作为工作项、审批结论随流程流转，能让主表状态与登记表版本保持一致；具体模板形态和审批字段配置以团队实际使用为准。
常见问题
变更记录主表和版本登记表之间如何关联？
两张表通过“基线版本号”关联。主表每一行记录一次变更，填写本次变更所基于的基线版本号（如V1.0）和变更序号；版本登记表按版本号记录每个基线版本的生效状态、批准信息和包含的变更编号。当一次变更批准后，主表的“生效版本”填写新版本号（如V1.1），同时在版本登记表新增一行记录该版本，并把旧版本行的状态改为“已失效”，填写失效时间和替代版本。这样主表保留变更过程，登记表反映版本结果，两边通过版本号对齐。
审批结论为“有条件批准”时，条件应该记录在哪里？
审批结论列填写“有条件批准”，具体条件写在备注列，并注明条件对应的验证责任人和验证时间。评估结论列保持评估阶段的独立意见，不把审批条件混入。状态列在条件未满足前可保持“待审批”或单独标记为“有条件批准待验证”，条件满足后再改为“已批准”并填写审批时间。这样审批结论、附加条件和验证状态各自有明确位置，复核时不会遗漏。
基线版本号的主版本和次版本分别在什么情况下递增？
主版本在基线范围或里程碑结构发生重大调整时递增，例如新增一个交付阶段、里程碑数量变化或项目范围整体调整。次版本在常规变更批准后递增，例如单个里程碑日期调整、局部工作项增减。变更序号在同一基线版本下从01连续编号，不跳号、不复用。一次变更批准后，生效版本取下一个次版本号；未批准前生效版本留空。团队可以根据自身治理强度调整“重大调整”的判定标准，但应在模板使用说明中固定下来，避免同一项目内口径不一致。
如果变更记录填错了，是直接修改还是新增记录？
已生效的记录不直接修改原值。需要更正时新增一条更正记录，在备注中注明被更正记录的变更编号和更正原因，状态标记为“已生效”。原记录保持原样，状态可改为“已作废”并注明被哪条记录替代。这样历史链路完整，复核时能看出更正前后的事实。对于尚未进入审批的草稿记录，可以直接修改，因为此时记录还没有形成正式版本。
变更记录和审批在文档、表格中分散维护时，如何保持版本对齐？
分散维护时，建议固定一个版本登记表作为唯一版本清单，所有变更记录主表的“生效版本”必须能在登记表中找到对应行。每次审批完成后，先更新登记表，再回填主表的生效版本和状态，顺序固定可以减少不一致。定期复核时，重点检查状态为“已生效”但登记表无对应版本、或登记表显示生效但主表状态未更新的记录。如果团队使用ONES的项目计划与基线能力，可以把变更记录作为工作项、审批结论随流程流转，让主表状态与登记表版本保持同步；具体模板形态和审批字段配置以团队实际使用为准。
