想少买点许可？先别动采购量

预算被砍，第一反应是少买。但直接砍采购量，是我见过最伤业务的一种省法。

我见过太多次了。采购那边一张纸发过来，说今年软件预算砍 20%，你第一反应是什么？少买几套。CAD 少买五个，PLM 少买三个，数据库那个 NUP 包减一半。数字上去了，报表好看了，然后呢？下个季度项目一铺开，工程师排着队等 license，项目经理天天来找你，最后要么加急买回来，单价更高，要么项目延期，罚的钱比省的那点多得多。

这件事的本质，其实不是采购技巧的问题。是治理。是你手里到底有多少 license 在睡觉、有多少在重复买、有多少被供给了根本不需要那个档位的人，你根本不知道。不知道就开始砍量，等于闭着眼睛做手术。

先说根源。工业企业的软件许可为什么总是“看起来不够、实际上浪费”？

根子上是三件事叠在一起。第一，采购是分散的。研发买 CAD，工艺买 CAM，仿真部门自己搞 ANSYS，IT 只管服务器那边的 Oracle 和 Windows。每个口子都有自己的预算、自己的供应商关系、自己的续费节奏，没人看全貌。第二，许可模式本身在变复杂。以前永久 license 加维护，买断就完了；现在西门子推 SSL 订阅，达索那边 DSLS 管着 CATIA 和 SOLIDWORKS，PTC 有 token 有 named user 也有浮动，同一个 PLM 环境里几种模式混着跑。你连自己“拥有”什么、按什么度量在付费，都未必说得清楚。第三，没人对“用完”负责。license 发下去就完了，员工离职、转岗、项目结束，那套 CAD 还挂在他名下，annual 续费的时候照付。

这三个东西加在一起，结果就是：你付的钱和你真正用掉的东西之间，有一条沟。 Redress 在对 40 到 60 个多供应商软件资产做优化时给过一个数：在回收动作之前，休眠和重复的许可占已付费权利的 10% 到 25%。SaaS 那边更夸张，Zylo 基于四千多万条许可的分析显示 52.7% 买来的 seat 是闲置的。工业软件因为并发 license 和 named user 混用、借出（borrow）机制存在，闲置不一定那么刺眼，但绝对量一点都不小。

踩得最多的四个坑，每一个我都亲眼见过。

坑一：把“预算砍多少”直接翻译成“采购量砍多少”。 这是最常见的。财务说砍 15%，采购就在续费单上把数量乘以 0.85。问题是你砍掉的那 15% 里，可能有一半本来就是闲置的，砍了没感觉；另一半是正在用的，一砍就疼。正确的做法是先知道哪些是闲置的，把闲置的砍掉，可能已经超过 15%，正在用的一个不动。对着你根本不需要的数量打八折，成本还是比零高。

坑二：拿安装量当使用量。 服务器上扫一遍，发现 SolidWorks 装了 60 台，就认为需要 60 个许可。但工业软件尤其是 CAD/CAM 和仿真，大量是浮动/并发模式，同一时间真正 check-out 的可能只有 35 个。安装量和并发峰值之间的 gap，是白花花的钱。更隐蔽的是“借出”——工程师把 license 借到笔记本上出差，回来忘了还，那个 seat 在池子里消失了整整一周，系统显示“不够用”，其实只是被 stranded 了。

坑三：把永久 license 和订阅放在一个筐里管。 永久 license 的省钱逻辑和订阅完全不一样。订阅不续费就没了，所以“少买”等于“到期少续”；永久 license 你已经付过买断费，维护费（annual support）通常是 list price 的 18% 到 22%，不续维护不会立刻丢授权，但会丢掉升级权利和技术支持。很多企业一刀切按订阅的思路去砍永久 license 的维护，省了 20% 的维护费，结果下一轮要上 major release 的时候发现升不了，或者出问题没有厂商支持，代价远超省下来的那点。度量不同，刀法就不能一样。

坑四：被 vendor 的续费单牵着走。 续费窗口就那么短，vendor 发过来的 true-up 数字是基于他们自己的记录，不是你实际的用量。Redress 的数据是：没有用量基线的资产，vendor 报出来的需求比实际高出 8% 到 20%。你手里没有 baseline，谈判桌上 vendor 的数就是唯一的数。你只能在这个数上要折扣，而折扣是对着错误的数量打的。

所以省钱这件事，顺序比力度重要。我的做法是五层，从代价最低、最不伤业务的那一层开始，前面没做完，不要碰后面。

第一层：回收闲置。 这一层几乎零成本，不涉及任何合同变更，不影响任何人正在用的东西。把过去 90 天的 check-out 日志拉出来，把离职、转岗、项目关闭后还挂在名下的 seat 清掉，把借出未归还的收回来。工业软件的 FlexNet、DSLS、Sentinel 这些 license manager 本身就有日志，上监控工具（OpenLM、FlexNet Manager for Engineering Applications 这类）能自动化 harvest，但哪怕手动拉日志，第一轮也能抓出东西来。这一层的空间就是前面说的 10%–25% 那条线，取决于你之前的管理松散程度。代价是：你得花时间读日志，可能还要跟几个部门扯皮“这个 seat 到底还有没有人用”。但不花一分钱新增支出，不改变任何人的工作方式。

第二层：去重。 这一层也基本零成本，但需要跨部门看。同一个功能，A 部门买了 standalone 的，B 部门通过企业协议其实已经有覆盖；或者两个子公司各自跟同一个 vendor 签了合同，单价不同、条款不同。有案例把多部门重复采购率从 35% 压到 8%，省了七位数。工业场景里容易忽略的是同一 vendor 的不同产品线之间的重叠，比如设计端有 CATIA 的某种模块，仿真端又单独买了功能重叠的工具。去重的代价是合同层面的协调，比回收麻烦，但还不涉及重新谈授权模式。能拿多少？Redress 把回收和去重放在一起给区间，10%–25% 的 paid entitlement，其中去重占的比例看你的组织有多“散”。

第三层：降配。 这一层开始碰“供给的档位”了，但还不碰“买多少”。很多用户拿的是高配 license，实际只用低配功能。CAD 里典型：中望的年份授权是向下兼容的，2023 的授权可以跑 2023、2022、2021，反过来不行；但如果你根本不需要 2023 的新功能，为什么要为它付费？PLM 里 named user 的 author 档和 viewer 档差价很大，一个只审阅不编辑的人不需要 author。Oracle 那边更结构化：Processor 按 cores × Core Factor 算，Intel/AMD x86 的 factor 是 0.5，IBM POWER 是 1.0，同一个物理核数在不同平台上许可需求差一倍。降配的区间，按 Redress 的 right-edition 数据，每 seat 20%–40%。代价是你要有功能使用数据，知道谁真的用了哪些模块，而且降配动作可能触发 vendor 的“升级路径”规则，得一个一个看合同。但降配不减少用户手里的工具，只是把供给的规格调到匹配需求。

第四层：重构授权模式。 到这一层，才真正碰“怎么买”的结构。典型动作：把一部分 named user 转成并发，或者反过来；把永久 license 的维护策略按实际升级节奏重新设计；在 Oracle 环境里利用硬分区把 license 需求压下来（注意 Oracle 只认硬分区，VMware 下它按整个集群的物理核算，这是一个巨大的坑）。Oracle 授权重构在专业服务介入的情况下，平均能拿到 38% 的降幅，但前提是你清楚自己在按什么度量付费、分区边界在哪里。工业软件这边，西门子、达索、PTC 都在往订阅和 token 混合模式走，token 的弹性对峰值波动大的仿真场景有价值，但对稳定高频的 CAD 用户未必比 named user 便宜。这一层的空间大，但代价也大：合同重谈、法务介入、可能有迁移成本，而且做错了会锁死好几年。

第五层：替代方案。 换工具。这是最后一层，不是第一层。前面四层做完，你手里会有一个非常干净的数字：我到底需要多少、什么档位、什么模式。拿着这个数字再看替代方案，才知道替代能省的是不是真的省，因为迁移成本、培训成本、数据转换成本、和上下游供应商的格式兼容性，全都要摊进去。很多替代方案在 list price 上好看，在总拥有成本上并不好看。

什么时候确实该少买？ 只有一种情况：需求真的在萎缩。某个产品线下马了，某个研发方向砍掉了，某个车间的产线不做了。这时候少买是结果，不是手段。你先确认了那部分需求不会再回来，对应的人员和项目都在收缩，然后才动采购量。需求萎缩导致的少买，和预算压力导致的少买，是两件完全不同的事。 前者是治理的自然结论，后者是拿业务当缓冲垫。

说一个我经手过的实际盘子，数字做了脱敏，但比例是真实的。一家做非标装备的中型制造企业，CAD 是主力工具，PLM 用着，底层有两套 Oracle 数据库撑 ERP 和 MES。年度软件盘子大概 480 万。预算通知下来，要砍 18%，也就是 86 万左右。采购那边的初版方案很直接：CAD 并发从 55 砍到 45，PLM author 从 30 砍到 24，Oracle 那边 NUP 包不动，因为“数据库不能动”。

我拦了一下。先拉日志，90 天。

CAD 那边，55 个并发里，日均峰值 check-out 其实是 41，另外 14 个是名义上的“备用容量”。其中有 6 个是借出未归还的 stranded seat，已经挂了平均 47 天。回收这 6 个，池子从 55 降到 49 就能覆盖 41 的真实峰值，多出来的 8 个作为正常 buffer 保留。 没砍任何一个工程师正在用的东西。

PLM 那边，30 个 author 里有 7 个过去 90 天没有过任何编辑动作，只有查看。降成 viewer，单价差大约 35%。同时发现两个子公司各自买了一份同类的仿真前处理工具，功能重叠度很高，合并成一份企业协议，砍掉一套。

Oracle 那边没急着动。先看 Core Factor：两台 x86 服务器，物理核一共 48，factor 0.5，Processor 需求是 24。但检查发现 Diagnostics and Tuning Pack 在测试环境里被误启用了，那是一个单独的收费 option，采购单上根本没列，审计来了就是罚单。关掉。然后在生产库上确认了硬分区边界，把一个非核心库约束到更小的资源池，Processor 需求从 24 降到 19。

最后落地的数字：CAD 49 个并发，PLM 23 个 author + 7 个 viewer，仿真工具合并，Oracle Processor 从 24 降到 19。 总盘子从 480 万降到 391 万，降幅 18.5%，刚好踩线。没有一个项目因为 license 被卡住。 采购初版方案里那些被砍掉的 CAD 和 PLM seat，如果真砍了，下个季度至少两个项目要排队等授权。

这事的关键不是省了 89 万。是 89 万里面，没有一分钱是从正在干活的人手里抢走的。 先看你有多少是闲置的。这个数往往比你想象的能省的那部分大。