应用退役处置效果评估要回答的是：这次退役是否按计划完成、遗留风险是否收敛、业务与成本影响能否解释清楚。做法上先把退役拆成可核验的阶段，再为每个阶段设定带分子分母、时间窗和单位的指标，用可追溯证据逐项核对，最后分别给出处置完成度与业务影响两类结论。ONES可在退役任务、变更记录与文档状态流转中承载证据归档，本文围绕评估方法展开。
要点总览（TL;DR）
- 评估应用退役处置效果，先把退役拆成退役决策、数据与集成清理、访问与权限回收、资产与合同处置、下线确认五个阶段，再为每个阶段设定可计算的指标。
- 每个指标写明公式、分母定义、统计时间窗、单位和证据来源五项，口径在评估开始前冻结，中途修改分母会让前后数据不可比。
- 分母为零记为“不适用”，数据缺失记为“数据不足”，两者都不并入完成率，防止完成率被虚高。
- 指标结果要与变更工单、访问日志、资产台账、合同终止文件、监控下线记录交叉核对，不一致时以证据为准并记录差异。
- 处置完成度与业务影响分开下结论，完成度高不能推出业务影响已消除；没有行业统一达标线时，只与计划值或自身基线比较。
退役处置效果评估要回答什么问题
评估对象是单个应用的退役处置过程，从退役决策形成到正式下线这一段。产品自身的商业生命周期阶段划分、退市决策，以及单个业务对象的处置流程，都不在本文讨论范围内。明确这条边界，可以避免把“产品还该不该继续卖”和“这套系统有没有退干净”混成同一个问题。
评估目标可以归为三项。第一，处置是否按计划完成：计划中的清理、回收、终止动作是否在约定时间窗内做完。第二，遗留风险是否收敛：残留的数据副本、未断开的集成、未回收的账号权限是否降到可接受水平。第三，业务与成本影响是否可解释：下线后受影响的业务方是否完成迁移，节省的资源与合同支出能否对应到具体条目。
评估结论有三种用途，需要在评估开始时就说明本次结论服务于哪一种，避免一份报告被当成万能凭证。
- 验收签字：作为退役项目关闭的依据，结论需要覆盖全部计划动作及其证据。
- 遗留风险跟踪：把未完成项转成带责任人和期限的跟踪清单，结论侧重缺口而非总分。
- 同类退役流程改进：比较多个退役项目的指标表现，找出反复出问题的环节，结论侧重模式而非单点。
三种用途对证据完整度的要求不同。验收签字要求每项结论都有对应材料；风险跟踪允许部分指标标注为数据不足；流程改进则要求多个项目使用同一口径，否则比较没有意义。
指标与范围：五个阶段与对应指标
把退役处置拆成五个阶段，每个阶段有明确的产出物，指标才有附着点。阶段之间存在先后依赖：数据与集成清理通常先于访问与权限回收完成，下线确认在最后。评估时可以按阶段分别计算，也可以合并成整体完成度，但合并前要保留分阶段数据。
| 阶段 | 候选指标 | 衡量对象 | 适用条件 |
|---|---|---|---|
| 退役决策 | 决策按期形成率、影响范围识别覆盖率 | 决策文档是否在计划节点前完成，受影响系统与业务方是否被识别 | 通用 |
| 数据与集成清理 | 数据处置完成率、遗留集成清理率 | 数据归档或销毁条目、对外集成接口的断开情况 | 含敏感数据或存在外部集成时重点适用 |
| 访问与权限回收 | 账号权限回收率、共享凭证失效确认率 | 用户账号、服务账号、共享账号的停用与删除 | 通用；存在共享凭证时增加后一项 |
| 资产与合同处置 | 资产核销完成率、合同终止完成率 | 服务器、许可证、云资源的释放，供应商合同的终止 | 涉及采购合同或自持资产时适用 |
| 下线确认 | 按期下线率、下线后异常工单数 | 监控摘除、域名与入口关闭、下线后仍被访问的情况 | 通用 |
通用指标适用于绝大多数退役项目，包括决策按期形成率、账号权限回收率、按期下线率。条件指标只在满足前提时纳入：应用不含敏感数据时，数据处置完成率可以只统计归档条目；没有外部集成时，遗留集成清理率标注为不适用，而不是记为100%。涉及合同的应用才统计合同终止完成率，内部自建且无采购的应用不纳入该项。
指标数量不宜过多。每个阶段保留一到两个能对应证据的指标，比堆叠十几个无法取数的指标更有用。指标清单确定后应冻结口径，评估中途修改分母会让前后数据不可比。
数据口径：公式、分母与证据来源
指标能否复算，取决于口径是否写全。每个指标至少写明公式、分母定义、统计时间窗、单位和证据来源五项。下表给出四个关键指标的口径示例，实际使用时按项目情况调整时间窗，但调整要在评估开始前完成并记录。
| 指标 | 公式 | 分母定义 | 时间窗 | 单位 | 证据来源 |
|---|---|---|---|---|---|
| 处置完成率 | 已完成处置条目数 ÷ 计划处置条目总数 × 100% | 退役计划中列明的全部处置条目 | 决策批准日至计划下线日 | 百分比 | 变更工单、任务记录、处置清单 |
| 遗留集成清理率 | 已确认断开的集成数 ÷ 登记在册的集成总数 × 100% | 退役前集成清单中的接口总数 | 清理开始至下线确认日 | 百分比 | 集成清单、接口下线记录、对端系统确认 |
| 权限回收率 | 已停用或删除的账号数 ÷ 退役前账号清单总数 × 100% | 退役前从身份系统导出的账号总数 | 退役前最后一次导出至下线后30日 | 百分比 | 访问日志、身份系统导出记录 |
| 按期下线率 | 按计划日期完成下线的应用数 ÷ 计划下线应用总数 × 100% | 同一批次计划下线的应用数 | 按批次统计 | 百分比 | 监控下线记录、变更单关闭时间 |
分母为零的处理规则要提前约定。当某类条目在退役前就不存在，例如应用从未接入外部集成，该指标记为“不适用”，不计入整体完成率的分子分母，也不写成100%。当分母存在但数据缺失，例如账号清单未能导出，该指标记为“数据不足”，单独列出缺口，同样不并入完成率。这两种标注方式能防止完成率被虚高。
横向比较需要谨慎。集成数量多、账号规模大的应用，清理工作量天然更大，完成率偏低不代表处置质量差。跨应用比较时应同时给出绝对数量和规模信息，或者只在同类规模的应用之间比较。不同批次使用不同时间窗的数据也不可比，比较前先对齐口径。
评估步骤：从取数到结论
评估按固定顺序执行，每一步都有明确产出，便于他人复核。
- 确定评估范围与时间窗。写明本次评估覆盖哪个应用或哪批应用、起止日期、依据的退役计划版本。范围一旦确定，后续取数不随意扩大。
- 按阶段取数与证据归档。逐阶段收集变更工单、访问日志、资产台账、合同终止文件、监控下线记录，按指标归类存放，文件名或编号与指标对应。
- 逐指标计算并与计划值或基线对比。计划值来自退役计划，基线来自同类项目的历史表现。没有计划值和基线的指标只报告实际值，不设合格判断。
- 交叉核对。把指标结果与证据逐项比对，例如权限回收率显示100%，但访问日志在下线后仍有该应用账号的登录记录，则以证据为准，修正指标并记录差异原因。
- 形成两类结论。处置完成度结论回答“计划动作做完了多少”，遗留风险清单回答“还剩什么没收敛、由谁在什么时间前处理”。
- 复核与签字。由未参与执行的复核人抽查证据与计算过程，确认口径一致后签字。复核记录本身也是留存材料。
交叉核对是最容易被跳过的一步，也是评估可信度的关键。指标是汇总结果，证据是原始材料，两者不一致时以证据为准，并在报告中保留差异说明，而不是直接修改数字让两者吻合。
一个可复算的例子
以下为演示情景，数字为说明计算方法而设定，不代表任何真实项目。
某内部管理系统计划退役，退役前登记情况为：计划处置条目40项；集成清单登记接口12个；身份系统导出账号150个，其中共享账号3个；无采购合同，服务器为自持。计划下线日为6月30日，实际于7月10日完成下线。
处置完成率：截至下线确认日完成38项，38 ÷ 40 × 100% = 95%。未完成的2项为历史报表归档和一台测试服务器释放。
遗留集成清理率：确认断开11个，11 ÷ 12 × 100% ≈ 91.7%。剩余1个接口的对端系统已停用但未出具书面确认，按未完成计。
权限回收率：已停用或删除147个，147 ÷ 150 × 100% = 98%。剩余3个为共享账号，其中1个因关联其他系统暂缓停用，2个待确认责任人。
合同终止完成率：该应用无采购合同，分母为零，记为“不适用”，不并入整体完成率。
按期下线率：计划6月30日，实际7月10日，未按期，本批次该应用计为0，即0 ÷ 1 × 100% = 0%。若按批次统计多个应用，则用批次内按期数除以批次总数。
从结果推导结论：处置完成度较高但未达全部完成，遗留风险集中在1个未获书面确认的集成、3个共享账号和2项未完成处置条目，需转成跟踪清单并指定责任人。按期下线率为0，说明延期原因需要单独说明，例如依赖方确认滞后，这一信息对改进同类流程有价值。
该示例的适用边界：单一应用、规模较小、无合同环节。应用到多应用批次或含敏感数据的场景时，需要补充数据处置条目和合同终止证据，指标口径也要相应扩展。
如何解读结果与常见限制
处置完成度高，说明计划内的动作基本做完，不能据此推出业务影响已消除。用户是否已完成迁移、下游系统是否还有隐性依赖、数据是否真的不可恢复，这些需要单独的验证材料。完成度与业务影响是两类结论，报告中应分开表述。
单个指标不能代表整体绩效。权限回收率100%而集成清理率偏低，整体处置仍存在明显缺口。指标之间存在制约关系：为了尽快提高按期下线率而压缩清理时间，可能推高下线后的异常工单数；为了追求完成率而把难处理的条目移出计划清单，会让分母失真。评估时应同时看几组相关指标，并对清单变更留痕。
评估时点会影响结论。下线后立即评估，异常工单数往往偏低，滞后效应尚未显现；间隔过长，部分日志可能已过保留期。建议在下线后设定固定的观察窗口，并在报告中注明评估时点与观察窗口长度。
结论表述应保留条件与不确定性。使用“在本次评估范围内”“依据现有证据”“该指标数据不足”等限定语，比给出一个笼统的合格判断更可靠。没有行业统一达标线时，不设通用合格阈值，只与计划值或自身基线比较。
把评估落到治理流程中
评估结果要进入三个环节才算完成闭环。第一是退役验收：处置完成度结论和证据包作为验收签字的依据，未完成项不因整体完成率高而被忽略。第二是遗留风险跟踪：把未收敛的集成、账号、资产条目转成带责任人和期限的跟踪项，定期复核直至关闭。第三是流程改进：把多个退役项目的指标表现放在同一口径下比较，找出反复出现的缺口环节，例如集成对端确认总是滞后，据此调整退役计划的检查点设置。
证据与记录需要长期留存。退役项目的复核往往发生在数月甚至数年后，变更工单、访问日志导出、资产台账、合同终止文件、监控下线记录都应归档到可检索的位置，并与对应的退役任务关联。记录分散在个人邮箱或本地目录，会让复核失去依据。
在工具承载上，ONES可围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；退役任务、相关变更记录与评估文档可以在同一链路中流转状态，证据随任务归档，复核时按应用追溯。对于需求链条长、参与角色多的组织，这种关联方式能减少评估时到处找材料的情况。具体模块组合与可用范围以实际采购和部署情况为准。
评估方法本身也需要迭代。每次退役结束后，回看指标口径是否够用、证据是否容易取得、哪些指标反复出现数据不足，据此调整下一批退役的指标清单和取数要求。口径稳定下来之后，跨项目的比较才有基础，流程改进也才有可依据的数据。
常见问题
退役处置评估中，哪些指标可以跨应用横向比较？
横向比较的前提是口径一致、规模可比。集成数量多、账号规模大的应用，清理工作量天然更大，完成率偏低不代表处置质量差。跨应用比较时应同时给出绝对数量和规模信息，或者只在同类规模的应用之间比较。不同批次使用不同时间窗的数据也不可比，比较前先对齐口径。条件指标（如合同终止完成率）在部分应用中记为“不适用”，这类指标不适合直接放进跨应用排名。
退役计划中途新增或删除了处置条目，完成率怎么算才不失真？
处置完成率的分母是退役计划中列明的全部处置条目，计划变更会直接影响分母。建议在评估开始前冻结计划版本，评估期间发生的条目增减单独记录变更原因、时间和批准人，并在报告中同时给出按原计划口径和按变更后口径的两个结果。把难处理的条目移出计划清单会让分母失真，这类调整必须留痕，复核时重点检查。
下线后观察窗口设多长比较合适？
观察窗口没有统一标准，取决于应用的访问频率和日志保留期。窗口太短，异常工单数往往偏低，滞后效应尚未显现；窗口太长，部分日志可能已过保留期，取数困难。可行的做法是在退役计划阶段就约定固定窗口，例如下线后30日，并在报告中注明评估时点与窗口长度。对低频访问的系统，可以适当延长窗口或补充主动探测记录。
评估结论用于验收签字时，证据需要完整到什么程度？
验收签字要求每项结论都有对应材料，未完成项不因整体完成率高而被忽略。具体做法是逐指标归档证据，文件名或编号与指标对应，由未参与执行的复核人抽查证据与计算过程。数据不足的指标单独列出缺口，不作为验收通过的依据。证据包与退役任务关联存放，便于数月甚至数年后复核时按应用追溯。
ONES 能支撑退役处置评估中的哪些环节？
ONES 可围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；退役任务、相关变更记录与评估文档可以在同一链路中流转状态，证据随任务归档，复核时按应用追溯。现有官方资料主要覆盖需求到发布链路，退役处置环节的具体功能与操作方式建议结合试用或与厂商确认。具体模块组合与可用范围以实际采购和部署情况为准。
