项目变更影响评估报告用于在审批前把变更事实、影响范围和应对措施写成一份可比较的材料。模板以“变更描述—影响维度评估—结论与审批建议”为主线，覆盖范围、进度、预算、资源、质量、风险与依赖关系七个维度，每个维度记录影响事实、影响程度、依据来源和应对措施，最后汇总净影响并给出审批建议。以下先给出可直接复制填写的空白模板，再说明字段口径、必填规则、完整示例与维护方法。
要点总览（TL;DR）
- 模板以“变更描述—七维度影响评估—结论与审批建议”为主线，覆盖范围、进度、预算、资源、质量、风险与依赖关系，可直接复制填写。
- 每个影响维度记录影响事实、影响程度、依据来源和应对措施四类信息，保证不同填写人产出的报告可以横向比较。
- 审批必需的字段包括基本信息、变更描述、与变更类型直接相关的维度，以及净影响汇总和建议结论；其余维度可按变更规模裁剪。
- 建议结论采用通过、有条件通过、暂缓、否决四档，有条件通过须写明条件内容和复核触发点，暂缓须写明待补充信息。
- 模板可按项目类型增减维度、统一影响程度分级口径，并通过版本记录与变更单、审批记录一并归档，保持历次评估可追溯。
可复制空白模板：项目变更影响评估报告
以下模板可直接复制到文档工具中填写。表格中的“影响程度”建议按组织约定分级，例如高／中／低，并在字段说明中固定分级口径。
一、报告基本信息
| 字段 | 填写内容 |
|---|---|
| 变更编号 | |
| 变更名称 | |
| 提出人／所属部门 | |
| 提出日期 | |
| 所属项目 | |
| 变更类型 | □范围 □进度 □预算 □资源 □质量 □其他：____ |
| 评估人／评估日期 | |
| 关联变更单／需求单 |
二、变更描述
| 项目 | 填写内容 |
|---|---|
| 现状 | |
| 拟变更内容 | |
| 变更原因 | |
| 不变更的后果 |
三、七维度影响评估
| 影响维度 | 影响事实 | 影响程度 | 依据来源 | 应对措施 |
|---|---|---|---|---|
| 范围 | ||||
| 进度 | ||||
| 预算 | ||||
| 资源 | ||||
| 质量 | ||||
| 风险 | ||||
| 依赖关系 |
四、结论与审批建议
| 项目 | 填写内容 |
|---|---|
| 净影响汇总 | |
| 建议结论 | □通过 □有条件通过（条件：____） □暂缓 □否决 |
| 建议理由 | |
| 审批人意见 | |
| 审批人／审批日期 |
五、附件与依据清单
| 序号 | 附件／依据名称 | 说明 |
|---|---|---|
| 1 | ||
| 2 | ||
| 3 |
字段说明：每个评估维度记录什么
字段说明的作用是让不同填写人产出的报告可以横向比较。基本信息与变更描述回答“改什么、为什么改”，七维度评估回答“改了以后影响在哪里、影响多大”，结论区回答“是否建议批准”。
基本信息与变更描述字段
| 字段名 | 含义 | 填写口径 |
|---|---|---|
| 变更编号 | 本次变更的唯一标识 | 沿用变更单编号，保证报告与审批记录可对应 |
| 变更类型 | 变更主要触及的约束类别 | 按主要影响勾选，可多选；与七维度评估中的重点维度保持一致 |
| 现状 | 变更前的计划、范围或资源状态 | 写当前已批准的口径，注明对应的计划版本或基线 |
| 拟变更内容 | 具体要调整的对象和幅度 | 写清调整前后的数值或范围，避免只写“压缩工期”这类方向性描述 |
| 变更原因 | 触发变更的内外部因素 | 写可核实的原因，区分客户要求、内部决策与外部条件变化 |
| 不变更的后果 | 维持现状可能带来的损失 | 写可预见的业务或交付后果，作为审批权衡的另一侧依据 |
七个影响维度的评估对象
| 维度 | 评估对象 | 记录内容 |
|---|---|---|
| 范围 | 交付物、功能边界、验收标准 | 增减了哪些交付物，验收口径是否变化 |
| 进度 | 里程碑、关键路径、交付日期 | 哪些节点移动、移动多少天、是否影响关键路径 |
| 预算 | 人力成本、采购成本、外部费用 | 增减金额及测算依据，区分一次性与持续性支出 |
| 资源 | 人员、设备、外部供应商 | 需要增减或调整的资源配置，以及资源冲突时段 |
| 质量 | 测试覆盖、缺陷风险、验收通过率 | 压缩或调整后哪些质量活动被影响，如何补偿 |
| 风险 | 新增风险与已有风险的变化 | 风险描述、触发条件、可能后果与应对预案 |
| 依赖关系 | 前后置任务、外部团队、系统接口 | 受影响的依赖项、对方配合要求与确认状态 |
影响程度、依据来源与应对措施
每个维度下的三类子字段承担不同作用。影响程度用于快速比较各维度的轻重，建议采用统一分级并在报告中写明分级含义；依据来源说明结论从哪里来，例如计划基线对比、工时记录、报价单或对方团队确认，便于审批人复核；应对措施写清由谁在什么时间做什么，把影响从“已识别”推进到“有安排”。三类子字段缺一，评估就容易停留在描述层面。
结论区的净影响汇总与审批建议
净影响汇总是把七个维度的影响合并成一个判断，写清主要受益与主要代价，以及两者是否可接受。建议结论采用通过、有条件通过、暂缓、否决四档：有条件通过须写明条件内容和复核触发点，暂缓须写明需要补充的信息，否决须写明主要理由。审批人意见栏由审批人填写，与评估人结论分开记录，便于后续追溯决策过程。
必填与选填：哪些字段不能空
审批决策依赖的字段必须填写完整，其余字段按变更类型和规模取舍。判断标准是：缺少该字段，审批人是否无法判断影响是否可接受。
审批必需的必填字段
- 基本信息中的变更编号、变更名称、提出人、提出日期、所属项目、变更类型。
- 变更描述中的现状、拟变更内容、变更原因、不变更的后果。
- 七维度评估中与变更类型直接相关的维度，至少填写影响事实、影响程度和依据来源。
- 结论区的净影响汇总、建议结论与建议理由。
- 附件清单中至少列出一项支撑依据，例如计划对比或测算表。
按变更类型选填的字段
| 变更类型 | 重点必填维度 | 可简化或选填的维度 |
|---|---|---|
| 进度调整 | 进度、资源、依赖关系、风险 | 预算可简写，质量写是否受影响即可 |
| 范围增减 | 范围、进度、预算、质量 | 资源与依赖关系按是否涉及外部配合取舍 |
| 预算调整 | 预算、范围、进度 | 质量与依赖关系可简写 |
| 资源替换 | 资源、进度、质量、风险 | 预算按是否产生额外费用取舍 |
必填字段缺失时的处理方式
必填字段暂时无法取得时，不建议直接留空提交。可在字段中标注“待补充”，写明补充责任人和预计完成时间，并在建议结论中选择暂缓，待信息补齐后再进入审批。这样审批人能看到缺口位置，避免在信息不完整的情况下作出判断。
不同变更规模下的字段裁剪原则
影响小、可逆、不触及关键路径的变更，可保留基本信息、变更描述、重点维度和结论区，其余维度写“经评估无影响”并注明判断依据。影响大、不可逆或涉及外部承诺的变更，七个维度全部填写，并附上计划对比、成本测算和风险预案。裁剪的原则是保留判断依据，不因规模小而省略结论区的净影响汇总。
填写示例：一次工期压缩变更的完整评估
以下为演示情景，用于说明模板的填写方式，数据为示例设定，不代表真实项目。
示例背景
某单项目原计划在第四季度末完成交付，客户要求提前两周上线，项目经理提出工期压缩变更，涉及测试阶段和部分联调工作。
七维度逐项填写
| 维度 | 影响事实 | 影响程度 | 依据来源 | 应对措施 |
|---|---|---|---|---|
| 范围 | 交付范围不变，验收标准不变 | 低 | 需求清单核对 | 无需调整 |
| 进度 | 上线日期提前10个工作日，测试阶段由15天压缩至10天 | 高 | 计划基线对比 | 测试与联调并行，关键路径任务增加每日站会跟踪 |
| 预算 | 增加临时测试人力费用，金额按内部工时单价测算 | 中 | 工时测算表 | 费用列入本期变更预算，由项目负责人审批 |
| 资源 | 测试组需增加2人，持续3周 | 中 | 工时日历与饱和度记录 | 从其他项目临时调配，原项目排期相应顺延 |
| 质量 | 回归测试轮次由3轮减为2轮，缺陷修复窗口缩短 | 高 | 测试计划对比 | 增加自动化回归覆盖，上线后保留一周观察期 |
| 风险 | 联调依赖外部团队，对方排期未确认 | 高 | 外部团队沟通记录 | 本周内取得书面确认，未确认则触发复核 |
| 依赖关系 | 联调任务前置依赖接口文档交付 | 中 | 任务依赖清单 | 接口文档提前交付，联调任务设置前后置依赖 |
净影响汇总与审批建议写法
净影响汇总可写为：交付范围与验收标准不变，上线日期提前10个工作日；主要代价是测试轮次减少、临时人力费用增加，以及对外部联调排期的依赖；主要收益是满足客户上线要求。建议结论为“有条件通过”，条件为外部团队在本周内书面确认联调排期，且自动化回归覆盖达到约定比例；任一条件未满足则转为暂缓并重新评估。审批人意见栏记录同意或调整后的决定，与评估结论分开留存。
示例与字段说明的对应关系
示例中每个维度都填写了影响事实、影响程度、依据来源和应对措施，与字段说明中的四类信息一一对应；结论区先写净影响，再写建议结论和条件，与结论字段的口径一致。填写人可对照此示例检查自己的报告是否在相同位置给出了同类信息。
调整与维护：让模板适配不同项目
模板需要在不同项目类型和变更规模下保持可用，同时保证历次评估材料可追溯。调整集中在维度取舍、分级口径和版本管理三处。
按项目类型增减维度
研发交付类项目通常七个维度全部保留；内部工具或小规模改进项目可合并预算与资源维度，保留范围、进度、质量和风险；涉及外部供应商的项目应强化依赖关系与预算维度，并要求附上对方确认记录。增减维度时在模板中注明适用项目类型，避免同一组织内出现口径不一致的报告。
评估口径与影响程度分级的维护
影响程度分级建议由项目管理办公室或指定负责人统一维护，明确高、中、低各自的判断标准，例如进度影响以关键路径天数为准、预算影响以金额区间为准。阈值调整后同步更新字段说明，并在模板版本记录中注明生效日期，保证新旧报告可比。
模板版本与归档管理
模板每次调整保留版本号和修订说明，旧版本不删除，便于回溯历史报告使用的口径。评估报告按变更编号归档，与变更单、审批记录放在同一位置。使用 ONES Wiki 时，可通过页面模板库一键创建制式化文档模板，让填写格式保持统一；页面组可关联项目，使评估文档与项目任务互相对应，文档中还可嵌入任务进度和报表，方便审批人直接查看计划与执行情况。对于需要对比计划偏差的变更，ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并通过版本细节对比追溯变更内容；工时日历与饱和度报表可用于资源维度的填写依据。具体支持范围以实际环境为准。
评估材料与审批记录的留存衔接
评估报告定稿后与审批结论一并留存，审批中提出的条件、复核触发点和后续补充材料作为附件追加，不覆盖原报告。这样下一次同类变更评估时，可以直接引用历史报告的影响判断和应对措施，减少重复测算，也让审批记录形成完整链条。
常见问题
变更影响评估报告和变更申请单有什么区别，能否合并成一份？
变更申请单回答“要改什么、为什么改”，影响评估报告回答“改了以后影响在哪里、影响多大、是否建议批准”。两者可以放在同一份文档中，但建议保留清晰的分区：申请信息在前，七维度评估和结论在后。合并的好处是审批人一次看到全貌；需要注意的是评估部分仍要由评估人独立填写，避免提出人自己写结论、审批人失去独立判断依据。
影响程度的高、中、低没有统一标准，怎么保证不同项目的报告可比？
分级口径需要由组织层面统一约定，例如进度影响以关键路径移动天数为准、预算影响以金额区间为准、质量影响以受影响的测试活动范围为准。口径确定后写入字段说明，并在模板版本记录中注明生效日期。跨项目比较时，审批人看到的“高”才对应同一含义。若组织暂未统一，至少在单个项目内保持历次变更使用同一口径，并在报告中写明本次采用的分级含义。
变更规模很小，七个维度都要填吗？
可以裁剪，但裁剪的是维度数量，不是判断依据。影响小、可逆、不触及关键路径的变更，可保留基本信息、变更描述、与变更类型相关的重点维度和结论区，其余维度写“经评估无影响”并注明判断依据，例如已核对需求清单或计划基线。结论区的净影响汇总不建议省略，它是审批人快速判断的主要依据。影响大、不可逆或涉及外部承诺的变更，七个维度应全部填写，并附计划对比、成本测算和风险预案。
评估时某些数据暂时拿不到，报告可以先提交审批吗？
不建议在必填字段留空的情况下直接提交。可以在对应字段标注“待补充”，写明补充责任人和预计完成时间，并在建议结论中选择暂缓，待信息补齐后再进入审批。这样审批人能看到缺口位置和补齐安排，避免在信息不完整时作出判断。若缺口只涉及选填维度，可在报告中注明该维度暂未评估及原因，由审批人决定是否要求补充。
评估报告定稿后，审批中提出的条件和后续材料怎么留存？
评估报告定稿后与审批结论一并留存，审批中提出的条件、复核触发点和后续补充材料作为附件追加，不覆盖原报告。这样历史报告保持原貌，审批链条完整可追溯。使用 ONES Wiki 时，可通过页面模板库一键创建制式化文档模板，让填写格式保持统一；页面组可关联项目，使评估文档与项目任务互相对应，文档中还可嵌入任务进度和报表，方便审批人直接查看计划与执行情况。具体支持范围以实际环境为准。
