每年做预算的时候,老板拿着去年的软件支出表问一句:这个数怎么又涨了。
你说研发人数涨了,项目多了,单价也涨了。老板说,那你告诉我,去年多买的那批,用上了没有。
你答不上来。采购台账上只有"买了多少、花了多少",没有"用上了多少"。这两件事之间隔着一层东西,而这层东西就是钱漏出去的地方。
软件预算的涨法,跟别的费用不太一样。别的花完就完了,软件这块有个特点——它是滚的。
第一层滚法:维护费按基数滚。买的时候一笔,之后每年按采购额的一定比例交维护,整包续,自动续。那个基数一旦上去,就很难下来,因为从来没人拿数据质疑过它。
第二层滚法:许可是动态池子,采购是静态快照。采购一年动一次,使用每天在变。人进人出、项目开了结了、外包来了走了。你拿一张季度更新的表去对一个每小时都在变的池子,误差只会越积越大。
第三层滚法:没人拥有全局数据。采购手里是合同和金额,IT 手里是终端安装,许可服务器里有并发日志,业务手里是账号。每家都掌握一部分事实,没有一家掌握全部,所以每次讨论都变成吵架。
还有个基础问题得先说清楚:不同的许可模式不能混着算总数。浮动许可(concurrent/floating)是抢池子的,命名用户(named user)是绑人的,节点锁定(node-locked)是绑机器的,订阅是按月按账号的。这四种垒在一起加出来的数,是假的。很多企业台账上那个"总共多少套",就是这么加出来的。
排队 ≠ 不够用。
研发喊卡,你就去加采购,这是最冤的一种。多数情况是占着不用——上午开个模型去开会,中午回来接着干,中间两三个小时 license 就那么挂着。看许可服务器日志里的 DENIED 和排队记录,对时间点,再去查那个时段谁持有,基本能抓出来。
后果:几十万花了,排队照旧,明年还得再花。
闲置席位年年交维护。
一年没打开过的席位,你照样给它交维护费。这钱没人认领,也不会在任何一张报表上单独出现,但它年年发生。
套件里默认勾上的模块。
装的时候一路下一步,附加模块全勾了。主程序你有授权,模块没有,或者数量少得多。这块往往比主程序还贵,而且你自己都不知道装了。
回收动作没有规则。
知道有人占着,知道有账号闲置,但处理一次要打招呼、要协调、要说服人,成本太高,于是就没人动。拖着拖着就变成常态。
离职、外包、项目结束,许可没跟着走。
这块是最好量化的浪费,也是最好改的。人走了机器堆在角落,账号还在,订阅按月还在扣。

先记三个数:峰值并发、零使用席位/套数、订阅月活。
然后建底账,回答三个问题:
Excel 加日志,两三个人跑两三个月能通一遍。通完你才知道自己的数据长什么样、阈值该定多少。这时候再看工具。
盯四点:能不能接现有终端数据、能不能解析你那几个许可服务器的日志、关键厂商的授权规则认不认、能不能自动回收闲置。最后一条是核心,不能自动释放的工具,本质还是一张漂亮的表。
gofar 在这块能帮企业把软件资产集中管起来、看许可实际用了多少、给成本控制和审计留数据基础。上之前把自己的合同和流程理一遍,实施范围自己定,关键结论人工过一遍再往外拿。别信"一键合规",最后一步一定是人拿合同一条条对。
一家做电机的厂,研发 + 仿真 + 工艺,两百来人。
摸底前:CAE 浮动 70 套,日志峰值 42,日均排队 15 次,最长一次等了四十多分钟。CAD 席位 190 个,零使用超 12 个月的 35 个。订阅席位 150 个,月活 103。外包账号 40 个,其中 24 个对应项目已经结束大半年。
干的事也不复杂:idle 超时设 30 分钟;回收 35 个 CAD、8 套零使用 CAE、24 个外包账号;订阅从 150 降到 108;续费基数砍掉这 35 个和 8 套;当年计划增购的 15 套主模块,取消。
结果:日均排队从 15 次降到 2 次以内,一套没多买。那年软件支出从 540 万左右掉到 445 万出头,其中能拿合同和付款凭证对上的硬节省 95 万。