软件续费前攒够硬数据，预算申请不用靠嘴吵

别一收到原厂的续费账单，采购转头就直接按去年的数量走流程，业务部门在旁边喊“不够用”，IT那边拿个利用率报表说“剩好多”，两边各说各的，最后报上去的预算申请到管理层那直接打回来，一句“凭什么续这么多”，谁都答不上来。

光盯着眼前这一次续费的事，你永远攒不出长期能用的能力。续费要准备的这堆数据，得从发现问题、判断需求、动手执行到事后复盘全串起来，不是凑几张截图就能交差的。咱们要的也不是报表上那种看着特别好看的利用率数字，是最后不管是缩减、维持还是增购，IT、采购、业务、法务坐在一起，所有人都能对着同一份材料说得出道理，谁也不用跟谁扯皮。

所有动作别光写在PPT里，必须落到具体的人头上，什么时候做完，做完之后拿什么材料交差，一个都不能少。这清单也不是做完这次续费就扔的一次性废纸，后面每个月做运营、改配置的时候都能用得上，省得明年续费又从头再来一遍。

很多人做续费数据第一步就错了，以为把日志导出来算个平均数就完事。这种分析根本没用，你连这个利用率的分母是什么、统计的是哪段时间、中间有哪些例外情况、哪些数据根本没采集到都没写清楚，下个月数字一变，谁也解释不了到底是需求涨了还是统计口径改了。所有参与方先把事实口径掰成一模一样的，后面不管是扩容、调度还是整改，大家才有共同的讨论基础，不然吵到下班都没结果。

你要攒的硬证据就三样，别整那些花里胡哨的：
第一，先把合同里的授权数量、单价、具体到期时间一条条捋清楚。别光对着技术日志下结论，要和手里的采购合同、接下来半年的业务排期交叉着核对，很多时候你以为的许可缺口，其实是下个月有个大项目要集中启动，日志里的历史数据根本没覆盖到。
第二，把活跃用户数、峰值并发数、许可拒绝次数这几个核心数统计出来。原始日志、你选的统计周期、谁负责整理这份数据，这些全要同步存好，别群里谁转述一句“好像有几个人用不了”，你就直接当成证据往报告里写，真到审批会上根本站不住脚。
第三，把长期闲置的席位、业务部门明确说了绝对不能动的关键模块单独拎出来。每一条都标清楚“已确认”“待确认”“不适用”，省得IT查完采购再查一遍，业务又过来翻一遍，三拨人做重复工。
这份事实底稿一定要留好版本号和导出时间，后面合同改了、业务变了，你才能说清楚当时为什么得出这个结论，不会过了三个月回头看，连自己都解释不了数据差在哪。

动手做的时候也别瞎赶工，按这几步来稳得多：
提前一个完整的业务周期就开始攒数据，别等原厂提前半个月发催费函了你才临时抱佛脚。普通的账号调整、席位回收走常规审批流程，那种涉及关键项目的例外情况单独走绿色通道，别全混在一起乱套。
按部门、按具体项目一条条解释你的需求，别上来就报个总数字。要调整席位之前提前通知所有受影响的用户，动作做完之后立刻收集大家的反馈，有人抢不到许可或者出异常，马上就能回退。
缩减、维持、增购这三种情况各做一套情景测算，别只给管理层一个数让他猜。每一次规则改了、参数调了，都把变更理由写清楚，后面审计或者下一轮续费的时候，不用再重新捋前因后果。
所有决策的依据、对应的审批记录全留好，别辛辛苦苦分析完一堆数据，最后报表往共享文件夹里一扔，采购下单的时候还是按老数量走，白忙活一场。
技术上你可以用gofar把软件发现、许可日志、账号分配和整改记录全归到同一个视图里，省得四个部门各存一份Excel找起来费劲。但所有自动化的调整动作，必须提前设好白名单、延迟执行时间和一键回退的机制，那种正在赶交付的关键项目，绝对不能拿来当新功能的试验品。

后面持续盯着这几个数就行，别做完续费就不管了：
活跃率，每调整一批席位就对应上具体的整改任务或者业务事件，别最后报了个90%的活跃率，点进去全是离职半年没清的账号。
峰值利用率，分子分母和那些明显异常的样本全单独标出来，别光给个汇总数，出了问题根本找不到根因。
拒绝率，指定专门的人负责定期复核，别等到研发天天在群里喊抢不到许可，你才发现许可服务器早就崩了。
续费调整数量，计算公式、哪些情况算进统计范围，明明白白写清楚，别这次统计算上了外协账号，下次统计又把他们排除在外，数字完全没法对比。
你的管理看板不能只放利用率这一个好看的数字，规模、效率、用户体验、合规风险这几样东西得同时摆在台面上，别为了把利用率凑到90%，把所有缓冲席位全砍光，高峰期全公司排队抢许可。效率、体验、风险三个方面同时都能接受，这次续费才算真的做完了。

最后说几个绝对不能踩的坑：
别拿着单日的使用数据就下判断，很可能那天全公司集体出去团建，你把偶发的低使用率当成长期趋势，直接砍了二十个许可，下周项目启动直接全乱套。
供需分析没做完就急着新采购或者强制回收，要么白扔几十万买一堆永远用不上的许可，要么直接把关键岗位的席位给收走了，耽误了项目交付谁都担不起责任。
把安装量、授权量、登录人数、并发量这几个完全不同的数混在一起算出来的利用率，根本没有任何参考价值，拿这个数去做决策纯纯是瞎指挥。
没有明确责任人、没有截止时间、没有事后回读验证的改进动作，等下次负责的人一离职，过不了半年所有老问题全得原样冒出来。

之前接触过一个汽车零部件厂的采购，去年续费的时候差点直接按上年280万的账单直接走流程，后来按这个方法拉了三个多月的完整日志，拆到每个模块每一条记录。最后发现高级仿真模块全年峰值并发才5个，他们却足足买了14个，闲置率高得离谱；反而是基础建模模块，旺季高峰期连续三周出现许可拒绝，业务部门天天喊不够用，之前的采购量根本没覆盖到真实需求。最后他们直接砍掉9个闲置的高级仿真许可，只补了12个基础建模席位，最终续费金额直接降到190万，省下来的钱直接给研发换了一批新的工作站，两边都没人有意见。