License 优化：先别急着砍闲置

老板看到报表上"利用率 60%"，第一反应是"砍掉 40% 的许可省钱"。IT 照做，三个月后项目节点前集体报错，紧急补买，花的钱比省的多一倍。

这就是不做分析直接动手的下场。

优化到底在干什么

License 优化不是"少买几套"，是让每份许可服务真实业务需求。

一个许可池里通常混着三类东西：

• 真在用的：关键用户、关键时段、关键模块。
• 占着不用的：离职员工绑定、长期登录不签出、调试完忘记释放。
• 该用但不够的：项目节点峰值超出容量，但平时看起来"够用"。
• 优化要动的是第二类，保护的是第一类和第三类。一刀切，必出事。

为什么总搞砸

表象和根因没分清。 许可拒绝率高，可能是容量不够，也可能是配置问题（模块拆分不合理、浮动池没建对），还可能是流程问题（有人长期占用不释放），甚至是合规问题（装了没买）。四类根因的解法完全相反——容量不够要买，配置问题要调，流程问题要管，合规问题要补。不分类就动手，方向全错。

口径不统一。 安装量、授权量、登录人数、并发量，四个数字放一起比，得出的"利用率"没有任何决策价值。安装量里包含卸载残留，登录人数包含只开界面不做仿真的，授权量里可能混着不同模块。必须先统一软件、模块、用户、时间范围，再谈供给和需求。

只看汇总不看明细。 汇总数说"平均利用率 70%"，但明细里可能是"平时 30%、节点 100%"。平均值把峰值抹平了，按平均值决策，节点必崩。

先摸底，三件事

第一件：识别高成本、高拒绝、高闲置的软件。 从 FlexNet / DSLS 日志里拉数据，按软件、模块、用户、时间段拆开看。同时记录例外场景——谁批准的、为什么例外，后面策略才不会误伤关键任务。

第二件：确认业务关键时段和用户群。 找项目经理要排期表，知道什么时候是节点前高峰。完成后抽样回读源系统，确认导出和汇总过程没丢信息。

第三件：核对合同允许的优化方式。 有些许可合同明确禁止某些调度方式，或者对并发用户数、地域范围有限制。要能回到具体设备、账号、模块，光有汇总数定位不了原因。

跨部门评审只用同一份底稿，IT、采购、法务、业务对着同一张表说话。

执行顺序，别乱

先建基线。 当前许可满足率多少、闲置量多少、拒绝率多少，先定下来。每个动作指定负责人和截止时间，做完回读验证。

选优先场景试点。 从可控的部门或软件开始，比如先拿一个仿真组的 ABAQUS 池子试，稳了再推广。别一上来全公司推。

上线策略。 提醒、回收、调度，分步来。闲置超过 4 小时自动提醒，24 小时未响应再回收。把普通流程和例外流程分开，减少临时口头授权。执行前通知受影响用户，执行后收集反馈。

用结果数据复盘。 看趋势，不看单点。连续观察两个周期以上，再决定是否扩大范围。

怎么算做对了

• 许可满足率：指定数据负责人和复核频率。
• 闲置回收量：明确计算公式和纳入范围。
• 拒绝下降趋势：记录口径变化，看趋势。
• 用户体验反馈：抽样回读源记录验证。
• 指标异常时先查采集覆盖和口径有没有变，再判断业务是不是真变了。效率、体验、风险三个都在可接受范围，才算过验收。

几个坑

• 凭单日报错当长期趋势。
• 没做供需分析就先采购或强制回收。
• 安装量、授权量、登录人数、并发量混为一谈。
• 改进没责任人、没时间、没验证，人一换就失效。

一个小案例

某家电企业，SolidWorks 买了 50 套浮动许可，报表显示平均利用率 55%，老板要求砍到 35 套。IT 拉了三个月日志做明细分析：平时工作日确实只有 20-25 套在用，但每月最后一周是项目评审节点，峰值冲到 47 套；有 6 套被两个离职员工的账号长期绑定没释放；还有 8 套是"登录不签出"——工程师开了软件挂着，实际在做别的事。

整改没砍总量，做了三件事：回收了离职账号的 6 套绑定，配了 2 小时空闲自动释放策略，把 50 套拆成 40 套主池 + 10 套高峰备用池。平均利用率从 55% 升到 78%，节点峰值也没再报错。第二年续费时，采购拿着数据跟达索谈，把备用池换成了更便宜的按需许可，反而省了钱。

问题从来不是"买多买少"，是"怎么在跑"。