评估许可证实际采购量,不清楚软件许可证使用数据

年初做预算，老板一句话："软件这块压 15%。"你打开采购台账，满屏都是去年花了多少，但你答不上来三件事：到底装了多少、真正在用的有几个、明年不买行不行。

于是只能砍最"看得见"的那笔——停掉一个新模块的采购。三个月后研发那边炸了，说仿真排队排到第二天早上，产能被你砍没了。

软件降本这事儿，压价是最容易做的，也是最没用的。真正漏钱的口子，从来不在价格单上。

为什么会漏，本质就三句话

第一，你手上没有一个能信的底数。

采购系统里有合同和金额，终端管理工具有安装清单，许可服务器有使用日志，财务有付款记录。四份数据，四个字段体系，同一个软件四个名字。谁也不比谁更权威，所以每次讨论都变成吵架。

第二，"买了"和"用了"之间没人负责。

采购签完合同，事情就结束了。装没装、开没开、人还在不在岗，没人跟踪。一年之后再看，那笔钱花了什么效果，说不清。

第三，续费是自动的，复盘是一次性的。

维护费按原基数每年滚，整包续、自动续。盘子只增不减，因为从来没有人拿数据去质疑过这个基数。

几个最贵的坑，按我见过的赔钱金额排

排队 ≠ 不够用。

研发喊"软件卡"，你就去加采购，这是最常见也最冤的一种。多数情况是占着不用——上午开个模型，去开会，中午回来接着干，中间两三个小时许可就那么挂着。

看许可服务器日志里有没有 DENIED 和排队记录，看时间点，再去对那个时段谁持有 license，基本能抓出来。

后果：你花了几十万扩容，排队照旧。

续费基数从来没人复核。

维护费一般是按采购额的一定比例逐年交。那 40% 一年没打开过的席位，你照样年年给它交维护。

后果：沉默成本，年年发生，没人认领。

模块层级搞错。

套件里默认勾了一堆附加模块，很多人一路下一步就装上了。还有一种是活儿明明低版本就能干，但标准镜像里统一给了高配版。

后果：审计时候最贵的一笔罚款，往往出在这几个你自己都不知道装了的模块上。

命名用户绑死人，人岗不匹配。

命名用户（named user）是绑人的，浮动许可是抢池子的，这俩不能混着算。人调岗、离职、外包撤场，席位没跟着动，新来的人反而没得用。

后果：一边超用一边闲置，同时存在，年年如此。

订阅席位只增不减。

按月买的席位，人走了照扣。这块的浪费是最好量化的，也是最好改的。

授权主体对不上。

集团签的合同，子公司在用；或者反过来。审计的时候这条经常翻车，而且翻车了很难临时补。

怎么弄：先摸底，再优化，工具放最后

摸底：先把三个数记下来，这就是你的基线

没基线就没法证明后来省了钱。先记：峰值并发、零使用席位/套数、订阅月活。

然后建底账，至少能回答三个问题：

• 装了什么：终端侧扫安装清单，别忘了云上、虚拟机里、那些"临时"的机器
  
• 买了什么：合同、订单、授权证明（Proof of Entitlement）。订单不等于授权，钱付了没归档的事儿我见过好几回
  
• 谁在用：别问人，看日志。FlexNet/FlexLM、达索那套 DS License Server 这类，都能导出 usage
  
• 字段必须对齐：软件名、版本、模块、授权单位（浮动/命名用户/单机）、归属主体。这步枯燥，跳过它后面全是猜。

优化：动作就这几个，别想复杂

• 回收：最后使用时间超 90 天的（按你们项目周期定），先停掉再通知。停两周没人找你，就回收。先问的话，答案永远是"我要用"
  
• 治占坑：配 idle 超时，闲置半小时左右自动释放。各家配置方式不一样，有的在服务端有的在客户端，逐个试
  
• 拆池 / 合并池：不同模块的池子要分开看。某个模块 32 套峰值才 6 套，主模块 85 套排队 23 次——这种情况去找厂商谈重配（re-mix），把余量挪到紧的那边
  
• 续费前一定复核：拿使用率报表去谈，降基数、减量续、或者干脆不续。谈不谈得成看关系，不谈肯定没有
  
• 流程就一件事：申请—审批—分配—回收—续费。必须有"回收"，只进不出永远堵

工具

Excel 加许可服务器日志，两三个人跑两三个月，能通一遍。通完你才知道自己的数据长什么样、口径怎么定。这时候再看工具。

看工具盯四点：能不能接现有终端数据、能不能解析你那几个许可服务器的日志、你那几个关键厂商的授权规则它认不认、能不能自动回收闲置。别信"一键合规"，最后一步一定是人拿合同一条条对，工具只能把范围从几千条缩到几十条。

gofar 在这块能帮企业把软件资产集中管起来、看许可实际用了多少、给成本控制和审计提供数据基础。上之前还是把自己的合同、组织流程、数据基础理一遍，实施范围自己定，关键结论人工过一遍再往外拿。别直接拿系统输出当结论。

用四个数验证成效

• 资产覆盖率（纳入底账的 / 实际盘子）
  
• 闲置授权回收量
  
• 峰值并发 与 许可总量 的关系（这个比值才说明该不该扩容）
  
• 整改闭环率（发现的问题里，真正关掉的比例）
  
• 财务节省只认已发生的：取消采购、减少续费、避免重复购买。预估的、测算的，不算。

一个真实点的账

某工业装备厂，研发设计 + 仿真 + 工艺，280 人左右。

摸底前：CAD 类席位台账 240 个，仿真主模块浮动 85 套、某附加模块 32 套。日志显示主模块峰值 51，日均排队 23 次，最长一次等了五十多分钟；附加模块峰值 6。零使用超 12 个月的：CAD 41 个、仿真 11 套。订阅类席位 180 个，月活 121。外包账号 47 个，其中 29 个对应项目已结束超半年。

干的事：idle 超时设 30 分钟；回收 41 个零使用席位和 11 套仿真；附加模块从 32 套降到 8 套，省下的钱谈成挪去买主模块；订阅 180 降到 124；清 29 个外包账号；续费基数砍掉 41 个 CAD 和 11 套仿真；当年计划增购的 20 套主模块，取消。

结果：当年软件支出从 620 万左右降到 505 万出头，其中能拿合同和付款凭证对上的硬节省 114 万。仿真排队日均 23 次降到 3 次以内。第二年再交审计数据，两天。