项目变更已经实施、审批却没走，事后补批的关键是把既成事实重新放回受控流程：先冻结现状并取证，再评估实际影响与风险，按该变更原本应属的审批层级提交补批申请，由有权审批人作出追认、附条件追认或回退的决定，最后补齐记录、基线与计划。补批补的是影响评估、决策依据和后续纠偏，一张签字单无法替代这些内容。下文按启动准备、申请撰写、审批决策、收尾同步的顺序展开，并给出角色分工、示例与闭环检查清单。
要点总览（TL;DR）
- 补批的本质是把已发生的变更重新纳入受控流程：先冻结现状并取证，再评估影响、按原权限审批，最后补齐记录、基线与整改。
- 补批申请要写清变更前后对比、已产生与潜在影响、未审批原因和处置建议，处置建议在追认、附条件追认、回退三种方案中选择。
- 补批按该变更原本应属的审批层级提交，由原有权审批人或变更控制委员会作出决定，避免降级审批。
- 审批通过后同步更新变更日志、项目基线、进度计划与相关文档；附条件追认要设置整改责任人、期限和验证时点。
- 用闭环检查清单逐项核对事实证据、审批层级、基线同步、相关方确认和防止再发动作，任一项缺失都说明补批尚未闭环。
补批前先做三件事：冻结、取证、定责
发现变更未审批就已实施，第一反应不应是立刻找人签字，而是先控制现场。事实不清时进入审批，审批人无法判断影响范围，补批容易流于形式。启动补批前完成三件事，形成一份补批启动记录。
冻结当前状态
通知变更发起人和实施人暂停继续扩大变更范围，包括暂停新增受影响的交付物、暂停向更多模块或环节扩散。冻结的对象是变更边界，项目其他正常工作可以继续。冻结时记录冻结时点、当前完成程度和仍在进行中的相关动作，作为后续影响评估的基准状态。
收集已实施的证据
证据用于还原“发生了什么”，至少覆盖四类信息：
- 时间线：变更实际开始时间、关键动作完成时间、被发现未审批的时间；
- 范围：涉及的工作项、交付物、文档、系统或流程环节；
- 人员：谁发起、谁实施、谁知情、谁批准过口头或临时安排；
- 痕迹：变更前后的版本、会议记录、沟通记录、已发布的文档或已提交的代码、已调整的计划。
证据清单按“证据名称—所在位置—对应事实”三列登记，便于审批人核对，也避免后续补记录时凭记忆填写。
确定补批申请责任人
补批申请原则上由变更发起人提交，项目经理负责组织影响评估和流程推进。若发起人已离场或职责不清，由项目经理指定责任人并在启动记录中写明。启动记录应包含变更事实描述、证据清单、责任人三项内容，经项目经理确认后作为补批流程的起点。
补批申请怎么写：影响评估与申请材料
补批申请单的质量决定审批能否有效进行。它需要回答四个问题：改了什么、已经造成什么、还可能造成什么、建议怎么处置。以下字段可作为申请单的基本结构。
| 字段 | 填写要求 |
|---|---|
| 变更事项描述 | 一句话说明变更内容，注明涉及的工作项、交付物或项目约束 |
| 变更前后对比 | 按范围、进度、成本、质量、资源五个维度分别列出原计划与变更后状态 |
| 已产生的实际影响 | 写已经发生的结果，附证据编号，区分可量化影响与待观察影响 |
| 潜在风险 | 列出尚未暴露但可能发生的风险，标注发生条件与可能后果 |
| 未审批原因说明 | 如实说明当时为何未走审批，区分流程不清晰、时间紧迫、沟通遗漏等情形 |
| 责任归属 | 写明发起人、实施人及各自应承担的责任，避免笼统写“团队疏忽” |
| 处置建议 | 在追认、附条件追认、回退三种方案中选择并说明理由 |
影响评估怎么做
影响评估按维度逐项对比，避免只写结论。进度维度写明关键路径是否改变、里程碑是否受影响；成本维度写明已发生支出与后续追加预算；质量维度写明测试覆盖、验收标准是否被削弱；资源维度写明人员投入变化和对其他项目的挤占；范围维度写明交付物增减及对相关方的影响。每项结论标注依据，例如“测试周期由10天压缩为6天，依据为调整后的测试计划版本”。
处置建议的三种取向
追认适用于变更本身合理、影响可控、程序缺失可通过整改弥补的情形；附条件追认适用于变更可以保留但需要补充验证、补做评审或限期整改的情形，条件应具体可验证；回退适用于变更带来的风险超出可接受范围，或与项目目标冲突的情形，回退方案需说明回退步骤、成本和二次影响。申请单给出建议，最终由审批人决定。
按原权限提交审批：补批的决策路径
补批最容易出问题的地方是审批层级被悄悄降低：变更原本需要变更控制委员会决定，补批时却由项目经理签个字了事。正确做法是先对照变更管理制度，确认该变更在正常流程下应属哪一级审批，再按同一层级提交。
确定原审批层级
依据变更类型和影响程度判断：涉及项目基线、里程碑、预算或验收标准的变更，通常需要项目管理层或变更控制委员会审批；仅影响局部执行细节的变更，可由项目经理审批。制度中对金额、工期、范围有量化门槛的，按门槛对照。无法判断时，按较高层级提交，并在申请中说明判断依据。
补批的审批形式
补批由原有权审批人作出决定；制度要求多级会签的，补批同样走多级会签，不因事后补办而合并或跳过环节。审批人需要看到完整的影响评估和证据清单，必要时可要求发起人或实施人到场说明。审批过程应留下记录，包括审批人、审批时间、审批意见和决策依据。
三种审批结论及后续动作
| 审批结论 | 含义 | 后续动作 |
|---|---|---|
| 追认 | 认可变更结果，补全审批手续 | 更新变更记录与基线，同步计划与文档 |
| 附条件追认 | 认可变更保留，但须完成指定整改 | 设定整改项、责任人和验证时点，到期复核 |
| 要求回退 | 变更不予认可，需恢复到变更前状态 | 制定回退计划，评估回退成本，回退后重新验证 |
审批结论写入补批审批记录，与申请单、证据清单一并归档。补批涉及的变更记录、审批流转和结论留痕，可以在 ONES 中借助工作项与版本对比来承载：变更前后的版本细节可追溯，项目计划与里程碑基线可对比计划与执行的偏差，便于审批人核对影响范围。具体配置方式需结合团队实际环境确认。
补批通过后要补齐什么：记录、基线与计划
审批结论作出后，变更才真正回到受控状态，收尾动作决定补批是否有效。收尾的核心是让记录、基线、计划三者与项目实际保持一致。
更新变更日志与项目基线
在变更日志中登记本次变更的编号、内容、审批结论和生效时间，与正常审批的变更使用同一套记录格式。项目基线按审批结论调整：范围基线更新交付物清单，进度基线更新里程碑日期，成本基线更新预算额度。基线更新需注明依据的审批记录编号，便于日后追溯。
同步计划与相关文档
进度计划、资源安排、预算表、测试计划、验收标准等受影响的文档逐项核对并更新，更新后在文档中标注版本和更新原因。涉及多个文档时，建立一份同步清单，逐项确认完成，避免只改计划不改配套文档。
通知相关方并确认接收
向受变更影响的团队、上下游相关方和客户接口人发出变更通知，说明变更内容、生效时间和对其工作的影响。通知发出后要求接收方确认，确认记录作为收尾证据留存。对附条件追认，通知中同时说明整改要求和时间节点。
设置整改跟踪项
附条件追认的整改项逐条登记为跟踪项，写明整改内容、责任人、完成期限和验证方式。验证时点到达后由项目经理或指定人员复核，复核结果回填跟踪项。整改未完成的，跟踪项保持开放状态，不因审批已通过而关闭。
角色与交付物分工
补批流程涉及四类角色，职责边界清晰可以减少推诿和重复劳动。下表按角色列出主要职责和对应交付物。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 变更发起人 | 说明变更事实与原因，提供证据，提交补批申请 | 补批申请单、证据清单 |
| 项目经理 | 组织影响评估，推进审批流转，协调收尾同步 | 影响评估结论、同步清单、整改跟踪项 |
| 变更审批人/变更控制委员会 | 审阅材料，作出追认、附条件追认或回退决定 | 补批审批记录与决策结论 |
| 配置或文档管理员 | 更新变更日志、项目基线与受控文档 | 更新后的变更记录、基线版本、文档版本 |
角色可以由同一人兼任，但职责不能省略。例如小团队中项目经理可能同时承担发起人职责，此时申请单中仍需分别写明发起与评估两项工作，审批人保持独立。补批材料与审批记录的查阅权限按项目敏感程度设置，ONES 知识库支持从页面到内容操作的分级权限管控，可用于控制变更文档的可见范围。
示例：一次进度压缩变更的补批过程
以下为演示情景，用于说明补批流程的完整走法，不对应真实项目。
情景与事实记录
某项目为赶在客户节点前交付，项目经理与测试负责人商定将系统测试周期由10天压缩为6天，直接调整了测试计划并通知测试团队执行，未提交变更审批。三天后质量例会上被发现。此时测试已执行两天，部分用例被合并或跳过。启动记录中登记：变更内容为测试周期压缩4天，涉及测试计划与用例执行范围，证据包括调整后的测试计划版本、测试团队通知记录和已执行的测试报告。
影响评估内容
进度维度：交付节点提前4天，关键路径未变；质量维度：原计划执行的120条用例中约30条被合并，回归测试范围缩小；成本维度：测试人力投入减少，但后续缺陷修复可能增加；风险维度：未覆盖模块在客户验收阶段暴露缺陷的概率上升。未审批原因说明为“节点压力下口头商定，未走变更流程”，责任归属写明发起人为项目经理、实施人为测试负责人。处置建议为附条件追认，条件是补做被合并用例中的高风险部分，并在交付前增加一轮冒烟验证。
审批结论与整改
变更控制委员会审阅后作出附条件追认：认可压缩后的测试安排，要求在一周内补做15条高风险用例，交付前完成冒烟验证，由质量负责人验证。审批记录中写明条件、责任人和验证时点。
补齐基线与后续验证
配置管理员更新进度基线中的测试里程碑日期，测试计划更新为6天版本并标注审批记录编号，变更日志登记本次补批。整改跟踪项登记两条：补做高风险用例、交付前冒烟验证。一周后质量负责人复核补做结果，验证通过后关闭跟踪项；冒烟验证在交付前完成并记录结果。项目复盘时将“节点压力下的变更须先提交快速审批”写入团队约定，作为防止再次发生的改进动作。
完成检查：补批是否真正闭环
补批流程走完后，用以下清单逐项核对。任一项未满足，说明补批尚未闭环，需要继续处理。
| 检查项 | 核对标准 | 证据 |
|---|---|---|
| 事实与证据 | 变更时间、范围、涉及人员和痕迹完整，证据可核对 | 补批启动记录、证据清单 |
| 影响评估 | 范围、进度、成本、质量、资源五个维度均有结论和依据 | 补批申请单 |
| 审批层级 | 与该变更原本应属的审批层级一致，无降级审批 | 变更管理制度对照说明、审批记录 |
| 审批结论 | 结论明确为追认、附条件追认或回退，决策依据可查 | 补批审批记录 |
| 基线同步 | 变更日志、项目基线已更新并注明审批记录编号 | 更新后的基线版本 |
| 计划与文档 | 进度计划、预算、资源安排及相关文档已同步更新 | 同步清单、文档版本记录 |
| 相关方确认 | 受影响方已收到通知并确认接收 | 通知与确认记录 |
| 整改闭环 | 附条件追认的整改项有责任人、期限和验证结果 | 整改跟踪项及复核记录 |
| 防止再发 | 针对未审批原因形成具体改进动作并落实到流程或约定 | 复盘记录、流程修订说明 |
检查由项目经理组织，配置或文档管理员配合核对记录与基线，审批人确认审批结论的执行情况。检查结果记录在案，作为项目变更管理过程的组成部分。补批完成不等于问题结束，未审批原因对应的改进动作需要在下一次变更发生时接受检验，才能说明补批真正起到了纠偏作用。
常见问题
变更已经实施很久，证据不全还能补批吗？
可以启动补批，但要把证据缺口如实写进申请材料。先按现有痕迹整理时间线、涉及范围、参与人员和可查到的记录，对无法还原的部分标注“待核实”，并说明核实方式。审批人看到的是完整的事实状态，包括哪些环节证据充分、哪些只能依靠当事人陈述。证据缺口较大时，审批人可能要求补充调查后再作决定，或作出附条件追认，把补齐证据作为整改项之一。
补批申请被要求回退，已经投入的成本怎么处理？
回退决定意味着变更结果不被认可，需要恢复到变更前状态。此时先制定回退计划，列明回退步骤、涉及的工作项与文档、预计工时和二次影响，再评估已投入成本中哪些可以保留、哪些形成沉没成本。回退完成后重新验证变更前状态是否恢复，并把回退过程和成本记录进变更日志。若回退本身会带来新的重大风险，应把这一情况反馈给审批人，由审批人决定是否调整结论。
多个变更同时未审批，可以合并成一次补批吗？
可以合并提交，前提是这些变更的审批层级相同、影响范围相互关联，且合并后仍能逐项看清每个变更的事实与影响。合并申请单中按变更逐条登记内容、证据和影响评估，审批结论也逐条对应，避免一个结论覆盖全部变更。审批层级不同或影响范围彼此独立的变更，分开提交更稳妥，否则容易出现高层级变更被低层级审批顺带通过的情况。
补批通过后，原变更的执行记录需要修改吗？
执行记录保持原样，不做追溯性修改。补批补的是审批手续和影响评估，已经发生的执行痕迹是事实证据，修改会破坏可追溯性。正确做法是在变更日志中登记补批信息，注明审批记录编号和生效时间，让原执行记录与补批审批记录形成对应关系。后续计划、基线和文档按审批结论更新，并标注更新依据。
怎么避免同类未审批变更再次发生？
从补批中暴露的未审批原因入手，形成具体改进动作。若原因是流程不清晰，明确哪类变更必须走审批、由谁审批、紧急情况下用什么快速通道；若原因是时间压力，为节点前的变更设置简化的快速审批路径，缩短等待时间；若原因是沟通遗漏，把变更审批作为计划调整的前置检查项。改进动作写入团队约定或流程文件，并在下一次变更发生时检验是否被执行。
