第一步：第一类：实际请求的能力和授权结果

先确认受影响任务实际请求了什么能力，服务端是否授予或拒绝。软件名称、安装人数和账号数量都不能替代这条记录。若问题发生在许可文件、版本或部署变更后，还应先核对授权范围；配置问题即使表现为“取不到许可”，也不应直接变成采购数量。

第二步：第二类：高峰窗口和并发变化

采购不能只看全天平均利用率。应把拒绝或等待发生前后的窗口单独拉出，看同一时间有多少请求、多少已经授予、是否连续占满，以及这种情况是否跨项目周期重复。高峰若只来自可预期的短期冲刺，先协调和错峰通常更稳妥；若关键窗口持续重复，才说明有稳定的容量风险。

第三步：第三类：任务结果和业务影响

每条等待都应对应到项目、任务类型和最晚需要结果时间。关键评审、交付和普通探索任务不能混为一个“失败次数”。采购评审应说明哪些结论因等待而延后、影响是否可通过调整计划化解，而不是只记录谁抱怨打不开软件。

最后确认：第四类：已经做过的治理动作

还要确认现有会话是否正常、是否有异常遗留、是否尝试过错峰、优先级协调或释放流程。未做治理就直接加购，容易让可解决的使用问题进入长期成本；但当多个关键节点重复受阻、正常占用已确认、协调后仍无改善时，也不应无限期把问题推回给工程师。

四类证据最好由同一份评审清单承载。研发补充任务和节点，IT 补充请求、授权和会话状态，采购补充合同与到期边界，软件资产管理员记录已实施的治理动作。这样可以明确每一条结论来自谁、缺什么信息、下一步由谁验证，避免会议结束后又回到各自维护的零散表格。

评审通过后仍需设置复核点。若选择错峰或调整规则，应在下一个高峰比较等待与拒绝是否下降；若选择增购，应核对新增授权是否解决了对应的关键窗口，而不是只看总利用率变化。复核结果将成为下一次预算更可靠的基线。

对采购负责人而言，四类证据还可以避免两种相反风险。一种是因单次投诉而买入长期闲置的授权；另一种是只看平均利用率而削减关键低频能力。前者增加不可逆成本，后者会在项目节点造成更高的交付风险。只有把使用窗口和任务后果同时摆出来，才能比较两种风险。

不同软件或模块不应合并成一个采购总数。某个模块出现稳定拒绝，不代表其他授权也需要增加；某个池长期闲置，也不代表可以用来抵消另一项关键能力的需求。采购清单应逐项列出对应证据、建议动作和复核时间，避免用总金额掩盖结构性问题。

在预算尚未确定时，团队可以先建立临时的任务协调规则，同时保留完整记录。这个过渡措施的目的不是长期替代采购，而是让关键任务在评审期间有清晰处理路径，并为最终决策留下可验证的事实。

采购输出应清楚列出：需要继续观察的时间窗口、要先处理的异常会话、可执行的错峰规则，或需要新增授权的具体能力及证据。FloatLic 能将请求、并发、会话与趋势整理为可复查的使用记录，帮助研发、IT 和采购围绕同一事实沟通；它不替代合同审核、厂商授权说明和预算决策。

采购会议结束前，应为每项待验证结论指定负责人和截止时间。例如由研发补全关键任务的业务影响，由 IT 核对请求和会话状态，由采购确认合同边界。没有责任人和复核时间的“需要再看看”，往往会在下一次预算会议中原样出现。

关于 FloatLic

广州浮点信息科技有限公司专注于工业软件许可证管理、监控与优化，帮助企业提升许可证利用率，降低采购与使用成本。
FloatLic 可支持许可证监控、闲置识别、并发分析、使用趋势洞察和优化决策支持。
官网地址：www.floatlic.com