软件续费别再只报采购数：License 底稿、拒绝率和许可回收怎么进预算附件

最怕那种会。合同往桌上一摊，就两个数，买了多少套、去年花了多少，然后采购问一句"明年留不留"，一屋子人开始凭印象说话。研发说不够用，IT 说日志看着挺闲，财务只想知道能砍几成。我一般不先开口，这种会开完，要么砍出事，要么糊里糊涂又续三年。烦的真不是算数，是每回都得替上一轮没留底稿的人擦屁股。

得先把这东西的性质掰一下，不然后面全白搭。续费要交的根本不是一张"利用率报表"，是一条能回读的证据链，软件发现、许可日志、账号分配，一路到整改记录和审批单，中间哪节断了，那个数就别拿去开会。它还得盖住发现、判断、执行、复盘四头，不是续费前一周临时导个 Excel 就完事。把清单当一次性文档的我见多了，人一换、项目一交，下回又从零开始。这东西本来就该长在月度运营和变更管理里，谁负责、哪天完、交什么验证材料，三样写不上，等于没写。

还有个特别容易糊过去的，分母、周期、例外、缺失值，少一个，指标一变你都说不清是业务真变了还是脚本改了。技术日志不能自己拍板，得跟合同、跟业务排期交叉对。这话我说得绝对，但吃过亏的人都懂。

底稿我本子上是乱的，照抄吧，别嫌跳：

① 合同数量、单价、到期时间，拉原合同附件，别用采购系统里那个被改过三回的摘要。跟业务排期对一遍，哪天验收、哪天结项，标出来。

③ 活跃用户、峰值并发、denial（就是 license server 回的那条拿不到许可），原始日志整段存，周期写死，数据负责人签个字。转述不算证据，微信里那句"好像挺稳的"更不算。

补一条，夹在中间才想起来的：长期闲置跟业务关键模块分开标，已确认 / 待确认 / 不适用，三态，省得 IT 和工艺各查一遍还查重了。底稿留版本、留时间戳，后面合同一改或者项目插队，结论对不上，至少翻得回去看是哪版口径。

（顺手答了老被问的那几句。从哪起手？就上面三项核验，先拿活跃率和峰值并发把现状描出来，别急着定缩减。数据至少盖一个完整业务周期，项目组还得盖到关键节点，淡季一平均，峰值全抹平了。谁负责？IT 管数据和技术策略，采购管合同续费，业务定优先级，沾合规争议让法务或专业的人把关，别自己硬扛。）

提前一个业务周期动手，没得商量。普通流程跟例外流程分开写，最怕临时口头一句"先给他开个"，到续费时谁都记不得。按部门、按项目解释需求，动账号之前通知到人，动完收一轮重新申请和异常反馈，别嫌啰嗦。缩减、维持、增购三版情景测算都摆上桌，规则版本和为啥改留痕；决策依据、审批记录直接挂到采购单或整改任务上，别让数据烂在报表里。

gofar 这层我倒觉得省心，软件发现、许可日志、账号分配、整改记录能归到一个视图，分散证据才算能追。但自动化别撒手全跑，白名单、延迟、回退都得有，关键项目不能拿来试错，这话我偏激点说，谁在验收周上自动回收谁自己收场。它记拒绝率这类运营证据可以，替代不了企业审批，也替代不了专业判断。

看板我只看四样，说法各不一样。活跃率得跟整改任务或业务事件挂上，光一个汇总数解释不了啥；峰值利用率分子分母异常样本都得留着；拒绝率指定谁复核、多久复核一次；续费调整数量把计算公式和纳入范围写明白，不然财务一问就卡壳。规模、效率、体验、风险得同时摆着，人天然只盯最好看那个数，我最不信这种。

几个坑，火气收不住也得说。单日一次报错就下结论，偶发当趋势，太常见。供需没分析完先采购或者硬回收，钱多花还可能把关键业务卡住。安装量、授权量、登录人数、并发量混着算，那数压根不配进预算附件。至于没责任人、没完成时间、没回读验证的改进，基本活不过下一次人员调整。

华北一家做风电齿轮箱的，NX 加 Teamcenter，另挂一套仿真求解器，合同 180 个并发 token，续费前六周采购报的是"够用，维持"。IT 拉了整季 license server 日志，denial 四百多次，按 feature 分组一看，八成挤在非线性接触那个模块，峰值并发其实冲到 168，可活跃账号才 90 出头，三十多个是外包撤场和调岗没解绑的 named-user，另有一批现场 borrow 离线借用的记录被旧导出脚本漏了。三版测算摆上桌：维持 180、缩到 140、不缩总盘但回收那 30 个死绑定做池化再给关键 feature 加 20。~~140 那版当时差点签了~~ 后来选了第三版，回退窗口放月底非生产时段，执行前给仿真组逐个发通知，规则版本和变更理由附在审批单后面。下季度回读，denial 掉到十几次，峰值 171，回收再分配率能逐条回到账号和主机。预算附件第 7 页贴的就是那张按 feature 分组的 denial 表，后面附了规则版本号。