软件续费前怎么备数据？让预算申请不再靠拍脑袋的指标清单

每年到续费节点最头疼。采购催你给数字，业务喊不够用，老板问能不能砍，你手里只有去年买了多少套、今年还剩多少套，再就是几个工程师口头反馈“好像不太够”。这种数据交上去，批多了浪费，批少了背锅，怎么都不对。

先说清楚一个事：续费数据不是单纯统计用了多少套license。它是把合同、使用行为、业务排期串起来的一份证据链。缺了哪一环，结论都站不住脚。

很多人一上来就拉日志看并发数，这方向就偏了。并发数只是分子，你还得搞清楚分母是什么——是合同授权总量？还是实际部署的节点数？还是浮动许可池的容量？分母搞错，算出来的利用率就是错的。

需要准备哪些东西，列个清单。

第一，合同层面的底数。合同数量、单价、到期日、授权模式（Named User还是Concurrent）、有没有软限制条款。这些东西要跟采购对，不能只信系统里登记的数，系统里经常有历史遗留的脏数据。

第二，使用层面的实数。活跃用户数、峰值并发数、拒绝次数（denial count）。注意拒绝次数这个指标很关键，光看利用率80%觉得还行，但如果高峰期拒绝率很高，说明容量不够，只是用户被挡在外面没算进分母里。原始日志要留着，统计周期至少覆盖一个完整业务周期，项目型团队还得覆盖关键交付节点，淡季的平均值会骗人。

第三，闲置和关键模块的区分。哪些license长期没人碰，哪些模块虽然用得少但关键时刻必须有。这部分建议打上标签：已确认闲置、待确认、业务关键。别让不同部门反复来问同一件事。

执行上有个框架可以参考。

提前一个业务周期开始准备，别等到合同到期前两周才动手。把常规流程和例外流程分开走，减少临时口头授权带来的混乱。按部门和项目去解释需求变化，执行前通知受影响的人，执行后收集反馈和重新申请。对缩减、维持、增购三种情景分别做测算，保留规则版本和变更理由，下次审计或者换人的时候能说清楚。决策依据和审批记录一定要留，不然数据就只停留在报表里，跟采购决策脱节。

gofar可以把软件发现、许可日志、账号分配和整改记录放到一个视图里，省得你去各个系统里扒数据。但自动化的动作必须有白名单、延迟执行和回退机制，关键项目不能拿来试错。

持续观察几个指标。活跃率要跟具体整改任务挂钩，不能光看一个汇总百分比。峰值利用率要保留分子分母和异常样本，否则说不清为什么是这个数。拒绝率要指定数据负责人和复核频率。续费调整数量要明确计算公式和纳入范围。管理看板要同时展示规模、效率、体验和风险，只优化最容易看的那个数字没有意义。

几个容易踩的坑。

只凭单日报错判断趋势，容易把偶发事件当成长期问题。没做供需分析就直接采购或强制回收，可能多花钱也可能影响业务。把安装量、授权量、登录人数、并发量混为一谈，算出来的利用率根本没法支撑决策。没有责任人、完成时间和回读验证的改进，人员一变动就失效。

小案例。

某汽车零部件企业CATIA续费前，IT只报了"当前50套，建议续50套"。采购问能不能减到40套省点钱，业务说不够用会耽误项目。后来拉了三个月数据：合同授权50套浮动许可，实际峰值并发42套，但拒绝次数在每月底集中爆发。细查发现月底是设计评审节点，有8个Named User同时登录抢资源，另外有12套license绑定了已转岗员工账号长期闲置。最终方案：回收12个闲置账号转为浮动池，峰值并发降到38套，拒绝次数清零，续费数量维持50套但授权模式优化，次年成本降了15%。