HR系统和许可系统根本没打通。人走了，账号还在，许可还挂着。

这事我碰过太多次，已经不怎么惊讶了。离职流程走得很顺，HR 在系统里点一下“已离职”，IT 收到工单收电脑、停邮箱、销门禁。但 CAD 的 named user 呢？PLM 的 author 授权呢？Ansys 那个挂在 license server 上的 seat 呢？没人动。离职单上根本没有“软件许可回收”这一行。 人走了半年，他的账号还在许可池里，annual 续费的时候照付。

你说这是采购问题吗？不是。是两个系统之间缺一根线。HR 知道人走了，许可服务器不知道；许可服务器知道 seat 被占着，但不知道占它的人已经不在了。中间那段，靠人拿 Excel 去对，三个月对一次，对完又回去了。

三类僵尸占用，本质是一件事：人的状态变了，许可的状态没跟着变。

• 离职未回收。最干净的一类，也最容易找。人已经不在了，账号还在。gofarlic 那边给过一个数，一家公司光离职员工遗留的许可就占总许可数的 18%。thenegotiationexperts 的口径更宽，说任何时刻 20%–30% 的付费 SaaS seat 属于不活跃或已离职用户。工业软件因为有并发池兜着，不那么刺眼，但 named user 那一块一旦漏，就是一个 seat 一个 seat 地漏。
• 转岗未调整。比离职隐蔽。搞设计的调去做工艺，他名下那套 CATIA 还在，新岗位可能只需要 viewer 权限。不回收不是最贵的，不降配才是。你还在为一个不需要 author 的人付 author 的钱。cnnetsun 那个案例里，两百多个高端工业软件授权，近七十个账号九十天打开不到五次，大多挂在已经转岗或者休长假的员工名下。
• 长期不活跃。最难吵的一类，因为“不活跃”和“暂时不用”之间的线不好画。项目空档期、阶段性支持角色、低频刚需，都可能被误判。但反过来，确实有一批 seat 已经事实上处于“没人会再碰”的状态，只是没有离职单来触发回收。

发现入口，说三个能今天就开始做的。

第一个入口最简单：拿 HR 的在职名单，去对许可系统里的持有名单。 差集就是离职未回收。不用任何工具，导出两张表，VLOOKUP 一下。这一步不涉及阈值，不涉及判断，纯对名单。如果你们连一张干净的“谁名下有什么许可”的表都没有，那先做这个表，别的都往后放。

第二个入口：拉最后活跃时间。 工业软件的 license manager 日志里一般都有，FlexNet、DSLS、Sentinel 这些，check-out 的时间戳就在那儿，只是没人定期去读。把每个 named user 或者每个被分配的 seat 的最后一次实际启动时间拉出来，按天数排个序。排在最后那一截，就是你要看的。

第三个入口容易被忘掉：共享账号和通用账号。车间、实验室、外协场景里常见，一个“design01”账号挂在好几台机器上，人换了几茬，账号一直没销。这类账号没有清晰的“离职”归属，但它占的是实打实的 seat。回收动作不是销号那么简单，得先确认现在谁在用、以什么方式用，然后要么转成真正的个人账号，要么收进并发池。

阈值这件事，坑不在设多少天，在于你不把口径写在表头上。

我见过同一个企业，IT 说闲置率 12%，采购说 25%，财务说 30%。一问，IT 算的是“最后登录超过 180 天”，采购算的是“最后 check-out 超过 90 天”，财务直接拿安装量减并发峰值。三个数都对，但说的不是同一件事。

口径至少要锁三样东西：

• 看的是登录还是启动？ named user 环境下，账号登录了不等于软件在用；浮动许可环境下，check-out 了也不等于人在操作，FlexNet 原生的 TIMEOUT 只看 TCP 心跳，用户开着软件去开会，连接不断，它不回收。你要的是“软件启动且有过实际操作”，不是“账号还活着”。
• 连续多少天？ Flexera 默认 activity threshold 是 60 天，可调到 15/30/60/90/120。Ivanti 的默认回收线是 120 天，理由是很多厂商认为一个季度内至少跑过一次就算“用过”。工业场景下，90 天是个常用起点，但 CAE 那种长周期仿真、或者按项目节点才启动的工具，90 天会误伤。先按 90 天拉名单，但名单出来是给人复核的，不是直接自动回收。
• 离职和转岗走不走同一个阈值？ 不走。离职是确定事件，HR 状态一变就该触发回收，不需要等 90 天。转岗需要看新岗位的权限模型，可能需要降配而不是回收。长期不活跃才需要阈值判断。三件事混在一个“闲置天数”字段里算，结果一定是一笔糊涂账。

表头上写清楚：统计区间、数据来源、分母是什么、离职/转岗/不活跃分别怎么定义。写不清楚，下次换个人算，数字就对不上，会就没法开。

回收动作最怕的是“做了，但三个月后又回去了”。

根子在于回收是一个一次性动作，而人的状态变化是持续发生的。你今天对完名单，清了一批，下个月又有人离职、转岗、项目结束，如果不挂在流程上，三个月后同一个 Excel 又要重做一遍。

做法不复杂，难的是让 HR 那边愿意配合：在离职流程里加一步。 HR 确认离职日期的那一刻，系统自动生成一条待办给 IT 或者许可管理员，内容不是“请回收许可”这种模糊的话，而是直接列出这个人名下有哪些软件、什么授权类型、最后活跃时间、建议动作（回收/降配/转共享池）。IT 点确认，回收动作发生；不点，待办就挂在那里，每三天提醒一次。

转岗也一样。调岗单生效的时候触发一次权限复核，不是默认保留全部旧权限，而是新岗位的权限模型重新走一遍。很多企业的问题不是没有转岗流程，是转岗流程只管 HR 那边的职位变更，不管系统权限的重新对齐。

工具能帮上忙的，是把这个闭环自动化。OpenLM 的 License Harvesting 可以做闲置释放，支持 FlexLM 管理的应用，监控 CPU/IO/进程活跃度来判断是不是真的没人用。但工具解决的是“发现和释放”，离职触发那一步，还是得靠流程集成，HR 系统和许可管理之间那根线，工具替你连不了。

这一块的空间，说实话不算大。离职遗留占许可总数的比例，工业场景下通常不如消费级 SaaS 那么夸张，named user 的管理密度也因企业而异。但它的好处是：最容易拿，最没争议，最不需要跟 vendor 重新谈合同。 你不需要动采购量，不需要碰授权模式，不需要法务介入。你只是把已经付了钱、但人在系统里已经不存在的那部分 seat 拿回来。

有一家做精密零部件的厂，CAD 并发池 48 个，日常峰值跑到 43，一直喊着要加 8 个。拉了一遍名单，发现 5 个并发 seat 被借出到笔记本上出差，平均挂了 40 多天没还；另外 3 个 named user 对应的员工已经离职两到五个月，账号还在。把这 8 个收回来，池子降到 40 个就能覆盖 43 的真实峰值？不，是 43 的峰值本身就虚高，实际 concurrent 峰值只有 38。 最后没有加购，也没有砍采购量，就是把借出的催回来、离职的销掉，池子从 48 调到 42，留了 4 个 buffer。续费少了 6 个 seat 的钱，业务侧没有任何一个人感觉到变化。