项目范围、工期或预算已经发生变化，却找不到对应的变更申请和批准记录，这类情况在项目执行中并不少见。处理时先不要急着补一张单子，而应冻结相关基线、盘点已经发生的改动，再按影响程度选择补走审批、回退或重新评估。本文围绕单项目的范围、计划和预算约束，说明如何识别、排查原因、分级处置并验证恢复。
要点总览（TL;DR）
- 未经批准的项目变更指范围、计划或预算已被实际改动，但缺少申请、影响评估和批准记录；仅有变更想法尚未执行的不属于此类。
- 排查原因按“流程是否清晰—评估是否可行—执行是否绕过”的顺序进行，用制度文件、待批积压和基线差异三类证据分别验证，避免直接归因为执行层不守规矩。
- 处置先冻结基线并盘点已发生的改动，再按影响分级：影响可控的补记录、补评估、补审批并纳入新基线；影响较大的暂停交付、回退或重新评估；涉及预算与合同的在进一步投入前停止并升级。
- 恢复以基线、交付物与审批记录三者一致为准，并通过变更准入检查和定期基线比对防止复发；复盘时区分流程缺陷与个人执行问题。
未经批准的项目变更通常表现为什么
未经批准的项目变更，指项目的范围、计划或预算已经被实际改动，但没有走完申请、影响评估和批准流程。判断的关键在于“改动是否已经发生”和“审批记录是否存在”，两者同时成立，才属于本文讨论的情形。仅仅有人提出变更想法、尚未执行，属于待审批事项，不在处置范围内。
实际工作中可以从以下信号入手排查：
- 交付物内容与已批准的基线不一致，例如多出未列入范围的功能、少做了已承诺的模块。
- 里程碑日期、关键路径或资源投入发生偏移，但项目计划中没有对应的变更记录。
- 成本支出超出批准预算，或采购、外包合同金额调整，却没有变更单支撑。
- 审批以口头同意、即时消息确认、会议纪要一句话带过的方式完成，缺少正式记录和影响评估。
- 团队成员按新要求执行了一段时间，相关方却仍按旧版本理解项目内容。
需要区分几类相邻情形。需求对象本身的修改如何管理，属于需求变更的范畴；跨研发资产的变更治理涉及多个配置项之间的联动，范围更大；多项目组合层面的变更治理关注资源与优先级在项目间的调配。本文聚焦单个项目内范围、计划、预算三类约束被改动却缺少审批的情况，其他情形只在处置时作为升级出口提及。
先分清原因：是流程缺失、评估缺位还是执行绕过
发现未批准变更后，容易直接归因为“执行层不守规矩”。原因判断需要证据支撑，不同成因对应不同的修复重点。建议按“制度是否清晰—评估是否可行—执行是否绕过”的顺序排查，先排除流程设计问题，再判断个体行为。
| 原因假设 | 典型表现 | 验证证据 | 排查方式 |
|---|---|---|---|
| 变更流程本身缺失或不清晰 | 团队说不清向谁提变更、用什么表单、多久批复 | 制度文件、流程说明、历史变更记录的数量与完整度 | 抽查近几个月的变更记录，看是否存在统一入口和固定模板；访谈两三名执行人员，确认其是否知道提交流程 |
| 影响评估能力不足，变更被搁置 | 变更申请提交后长期无人评估，执行层等不及先行改动 | 待批变更的积压数量、平均评估耗时、评估人是否明确 | 统计待批清单的停留时长，查看评估环节是否缺少明确责任人或评估方法 |
| 执行层绕过审批 | 流程存在且评估及时，仍有改动未提交 | 基线差异记录、沟通记录、变更台账与实际改动的比对 | 将当前交付物与基线逐项比对，结合沟通记录确认改动由谁在何时决定 |
排查时先采集证据再下结论。制度文件和历史记录可以说明流程是否存在；待批清单和评估耗时可以说明流程是否运转；基线差异和沟通记录可以说明改动是否绕过了已有流程。三类证据指向不同原因，也可能同时成立，例如流程存在但评估环节长期积压，执行层在等待中自行推进。证据采集应尽量保留原始记录，包括版本历史、审批痕迹和关键沟通内容，避免事后凭记忆还原。
按影响分级处置：补批、回退还是重做评估
处置的第一步是冻结。暂停相关基线的新一轮修改，把当前计划、范围说明和预算版本固定下来作为比对基准，同时备份现有交付物和记录。冻结期间向相关方说明正在核查，避免在盘点过程中又产生新的未记录改动。
随后盘点已经发生的改动，逐项列出改了什么、由谁决定、影响哪些交付物、已经投入多少工时和成本。盘点结果决定后续路径：
| 影响程度 | 判断参考 | 处置路径 |
|---|---|---|
| 影响可控 | 改动局限在局部交付物，工期和成本偏移在可接受范围内，未触发合同条款 | 补齐变更记录和影响评估，按原审批层级补批，批准后纳入新基线，并同步更新相关计划 |
| 影响较大 | 关键里程碑偏移、成本明显超支、交付物质量或合规性受影响 | 暂停相关交付，评估回退到原基线的可行性；回退成本过高时，重新编制方案并走完整审批 |
| 涉及预算与合同 | 改动触及合同金额、付款节点、供应商承诺或对外交付义务 | 立即停止进一步改动，升级至预算负责人和合同管理方，由有权层级决定是否追认或调整合同 |
补批不是简单补一张单子。补记录时要如实写明改动发生的时间、原因和已产生的影响，影响评估要覆盖范围、工期、成本和质量四个方面，审批人应基于真实信息作出判断。回退前要确认回退本身不会造成更大损失，例如已经对外交付的部分、已经发生的采购支出，往往无法通过回退消除。涉及预算和合同的变更，停止点应设在“进一步投入资源之前”，在有权层级给出结论前，相关执行动作保持暂停。
操作前的备份与沟通同样重要。备份当前版本的计划、交付物和审批记录，确保回退或重新评估时有据可依；沟通对象至少包括变更发起人、受影响交付物的负责人、审批人和预算或合同管理方，沟通内容应说明冻结范围、预计处置时间和当前暂停的执行动作。
在处置流程中，变更申请、影响评估和审批记录需要有统一的承载位置，基线也需要可对比。ONES 瀑布项目管理解决方案支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并可通过对比版本细节追溯变更细节；这些能力可用于盘点阶段确认改动范围和发生时间。对于需求、基线、版本与变更的管理对象，ONES ALM 方案提供统一管理支撑，适用于研发场景下的变更影响分析与结果回溯。工具承载的是记录与比对，处置路径和审批权限仍由项目自身的治理规则决定。
处置后如何验证恢复并防止复发
处置完成的标志是基线、交付物与审批记录三者一致：当前基线反映的是经过批准的版本，实际交付物与基线内容相符，每一项改动都能在审批记录中找到对应条目。验证时可以抽取若干关键交付物逐项核对，而不是只看变更单是否齐全。
恢复验证可按以下清单执行：
- 新基线已发布，且发布动作有记录、有批准人。
- 交付物与基线逐项比对无差异，或差异项均有对应审批。
- 变更台账中的每条记录都包含申请、影响评估和批准结果。
- 相关方已收到基线更新通知，并按新版本理解项目内容。
- 暂停的执行动作已明确恢复条件，未获批准的部分仍处于停止状态。
防止复发依靠机制而非提醒。变更准入检查应嵌入执行环节：没有审批记录的改动不进入执行，计划调整、范围追加和预算支出在系统中以审批通过为前提。定期开展基线比对和变更台账回顾，例如按固定周期检查基线差异和待批积压，可以及早发现绕过审批的苗头。ONES 支持通过项目列表查看项目状态、资源投入和当前进展，便于在回顾时快速定位偏差项目。
复盘时区分流程问题与个人执行问题。若证据显示流程入口不清、评估长期积压，修复重点应放在简化申请路径、明确评估责任人和时限上；若流程运转正常而个别人员反复绕过，则通过准入检查和责任约定处理。两类问题混在一起谈，容易把机制缺陷归为态度问题，也容易让真正的违规行为被流程讨论掩盖。
常见问题
改动已经执行了一段时间，还能补走审批吗？
可以补，但补批的前提是如实还原事实。补记录时应写明改动发生的时间、由谁决定、原因是什么、已经投入多少工时和成本；影响评估要覆盖范围、工期、成本和质量四个方面。审批人基于真实信息判断是否追认，而不是对一张事后填写的单子走形式。如果改动已经触及合同金额、付款节点或对外交付义务，补批权限应上移到预算负责人和合同管理方，由有权层级决定追认还是调整合同。
回退到原基线是不是最稳妥的处理方式？
回退适用于改动尚未对外交付、回退成本可控的情形。已经交付给客户的部分、已经发生的采购支出和已签署的合同承诺，通常无法通过回退消除，强行回退可能造成更大损失。这类情况更适合暂停相关交付、重新编制方案并走完整审批。判断时先盘点改动的可逆性，再决定回退还是重新评估，两者都需要在冻结基线、完成盘点之后进行。
流程和审批都齐全，为什么还是会出现未批准的变更？
常见原因是评估环节积压。变更申请提交后长期无人评估，执行层等不及便先行改动，表面上流程存在，实际运转已经失效。排查时可以统计待批清单的停留时长和评估耗时，确认评估责任人是否明确、评估方法是否可操作。修复重点应放在明确评估责任人和时限、简化申请路径上，而不是继续加严审批层级。
处置完成后，怎么确认项目真的恢复受控？
看三者是否一致：当前基线是经过批准的版本，实际交付物与基线内容相符，每一项改动都能在审批记录中找到对应条目。验证时抽取若干关键交付物逐项核对，比只看变更单是否齐全更可靠。同时确认相关方已收到基线更新通知，暂停的执行动作有明确的恢复条件，未获批准的部分仍处于停止状态。
用工具承载变更流程，能解决未批准变更的问题吗？
工具解决的是记录与比对问题，审批权限和处置规则仍由项目自身的治理规则决定。以 ONES 为例，瀑布项目管理解决方案支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并可通过对比版本细节追溯变更细节，便于在盘点阶段确认改动范围和发生时间；ALM 方案围绕需求、基线、版本和变更建立统一管理对象。这些能力让变更申请、评估和审批有统一的承载位置，但准入检查是否执行、审批层级如何设置，取决于团队是否把规则落到日常执行中。
