别等审计函到了，才想起来查自己装了多少套NX

干这行久了，你会发现一个挺操蛋的规律：软件资产这事，不出事的时候谁都觉得不是事，出了事谁都觉得早该管。

原厂审计来的时候，最难受的真不是少几份合同。合同找找总能翻出来，法务那边多少有存档。真正要命的是，你根本说不清楚现在到底谁在用、装的是什么版本、哪个模块、什么许可类型，和当初买的到底对不对得上。IT说采购清楚，采购说使用在研发，研发说我只要能干活就行。三方一对，谁都没有一张能直接拿出来的表。

审计函不会给你三个月。它一般给你两周，最多一个月，让你“配合提供软件部署与授权使用情况”。这两周里你要干的事，本质上是在补过去两三年欠的账。

先把许可模式搞清楚，不然你连“超没超”都判断不了

工业企业踩的坑，一大半是因为把不同软件的许可逻辑混在一起想。Floating / Concurrent 看的是同一时刻的并发数，不是总人数。你买了10个并发许可，50个人装过、用过，不一定是违规，只要峰值没破10就行。但反过来，如果峰值破了，哪怕平时只有5个人在用，审计那一下抓的就是峰值那一下。西门子查NX和Teamcenter，读的就是FlexLM服务端日志里重建出来的历史峰值，不是平均值。

Named User 是另一套账。它绑的是人，不是机器，也不是并发数。只要一个不在授权名单里的人登进去用了，那一秒就算不合规，没有任何“峰值没超”的辩解空间。而且Named User的重新分配是有频率限制的，西门子的PLM条款写得很清楚，一个Named User许可每个自然月只能重指派一次。你研发人员流动快，入职离职频繁，如果每次离职没有及时把Named User释放回池子，半年下来账面上就会多出一堆“幽灵用户”。

还有一类更容易被忽略的：Token-based。NX的高端模块、Teamcenter的某些功能、Ansys的部分求解器，是按token池来消耗的。它不看你开了几个人，看的是你同时调用了多少个功能模块，峰值一叠加，池子就可能被穿透。你以为自己只买了“NX基础包”，结果CAM编程的时候调了五轴模块，token早就超了，但界面上不会弹警告。

工业企业最容易撞上的五个坑

坑一：虚拟机克隆。 这是制造企业IT最常干的事，也是最容易在审计里炸的事。一台工作站的软件环境连同离线许可证文件一起做成镜像，新员工入职直接克隆一台，装好就能用。一台授权变成了十几台在用，而且完全不在IT的监控范围里。离线许可文件的绑定信息通常只校验MAC地址或硬盘序列号，镜像克隆之后每一台副本都能正常通过校验，系统自己都分不清哪个是原始、哪个是克隆。原厂审计工具一扫，实例数比购买数多出30%，追缴加罚款就是几十万起步。

坑二：试用到期不锁死。 很多工业软件的试用版到期之后并不会立刻停止运行，只是每隔一阵弹个提醒。研发的人嫌烦，点掉继续用；IT不知道，采购也没跟进。从法律性质上讲，到期之后每一天的使用都是无授权使用，审计的时候原厂不会因为“我们忘了”就放过这一段。

坑三：版本和模块混着用，授权边界糊成一锅粥。 SolidWorks的Standard、Professional、Premium是叠加逻辑，Professional的席位自带一个Standard底座，但这不等于你可以拆开来让两个人分别用Standard和Professional。你买5个Professional，理论上最多是5个人在用，不是“5个Professional + 5个Standard = 10个人”。Catia更狠，它是模块化授权，GSD曲面、装配、运动仿真各算各的，你买了基础包，工程师在工位上把高级模块勾上了，用一次就算一次超出授权范围。审计读的是许可证服务器日志，不是你的采购合同。

坑四：离职账号和闲置席位没人回收。 Named User不回收，账面上这个人永远“在用”。Concurrent许可被一个已经转岗的人长期挂着，真正需要的人排队等。原厂审计的时候，闲置席位不会帮你减分，反而说明你的授权管理没有闭环，每一个“买了但没人合法使用”的席位，在审计口径里都是潜在的追缴依据。

坑五：版本共存引发的许可冲突。 SolidWorks 2022和2023可以装在同一台机器上，但许可证管理器对多版本共存的处理并不是“两个版本各算各的”那么简单。旧的许可证文件可能被新版本调用，或者反过来，导致日志里出现一些你自己都解释不清楚的feature调用记录。审计的人不会管你“技术上怎么发生的”，他只认日志里记的东西。

动手的顺序：先查清楚，再动手砍，最后才谈工具

别一上来就琢磨买什么平台。你连自己有什么都不知道，上什么工具都是白花钱。

第一步，摸底，只读不碰。 把现有的许可服务器日志导出来，至少跑两周。如果是FlexLM/FlexNet管着的，直接把lmgrd的日志拉出来看；如果是DSLS（达索的License Server），去把服务端的日志和当前借出记录对一遍。目标只有一个：搞清楚峰值到底是多少，谁在什么时候占了什么。不要在这一步就开始“优化”，先看清楚。两周的数据能告诉你很多东西：哪些模块的峰值远低于购买量，哪些模块一到下午就排队，哪些人挂着许可但实际没有活跃操作。

第二步，拿使用数据去对采购台账。 采购那边的合同和PO只能告诉你“买了什么”，不能告诉你“用在了哪里”。你需要把许可服务器里的feature名称和合同上的模块名称一一映射起来。这一步最枯燥，但最关键。映射完之后，你会看到三类东西：第一类，买了但峰值从来没接近过的，叫冗余；第二类，峰值反复穿透的，叫缺口；第三类，日志里有feature调用但合同上找不到对应条目的，叫风险敞口。第三类最危险，因为它就是你审计时最可能被追缴的那一块。

第三步，先处理不要花钱就能解决的问题。 把离职超过30天的Named User释放掉，西门子的条款允许每月重指派一次，但前提是你得真的去操作。把Concurrent池里那些“连着服务器但键鼠十分钟没动、求解器也没在跑”的会话做回收，阈值设在12到15分钟是比较常见的做法，不会打断正常的设计节奏，但能把被占着不用的席位挤回公共池。把试用到期还在跑的实例找出来，该停的停，该补的补。这三件事不需要新采购任何东西，做完之后你的有效许可位置至少能改善一截。

第四步，再谈工具。 工具的作用不是替你“管”，是替你“看见”和“留痕”。如果你们家以FlexLM系为主（NX、Teamcenter、Ansys、部分Catia环境都走这个），OpenLM这类专门盯工程软件许可的工具比通用SAM平台更对口，它能读FlexNet和DSLS的底层数据，而且支持对Catia做“Save & Close”式的空闲回收。如果你们是SAP、Oracle、Microsoft混着管，那就走Flexera或Snow那一路。选型的时候只问一个问题：它能不能把“谁、在哪个机器上、什么时间、调了哪个feature、持续了多久”这条链完整拉出来。拉不出来，报表再好看也没用。

一个真实的案例，细节比结论更值得看

某大型装备制造企业，研发人员将近两千人，每年在CAE/CAD上的采购投入过千万。原厂例行审计，审计工具扫出来的实际运行实例数比购买量多了将近30%，追缴过去两年的超额使用费加罚款，八十多万。

问题出在哪儿？不是采购没买够，也不是故意用盗版。研发为了图快，把几台高性能工作站上的软件环境连同许可证一起做了虚拟机镜像，新员工来了直接克隆一台，计算资源不够了再克隆一台。一台授权变成了十几台在用，全部游离在IT的监控之外。IT那边看到的许可服务器记录是“正常的”，因为克隆出来的虚拟机用的就是原始镜像里的离线授权，不需要向服务器请求，也不会在服务器日志里留下新记录。

更麻烦的是，这个企业在此之前一直觉得自己“大体上是合规的”，因为采购合同都在，每年该续的维护也续了。但他们从来没有把“买了多少”和“实际在跑多少”放在同一张桌子上对过一次。审计函来了之后，IT花了将近一周时间才把克隆虚拟机的分布摸清楚，而原厂那边已经用工具把扫描报告和侵权天数计算表做好了。

八十多万的教训是：许可证合规这件事，靠“我们买了”是证明不了的，你得能拿出“谁在用、用了什么、有没有超出”的连续记录。虚拟机克隆只是最典型的一种失控方式，镜像恢复、硬盘复制、离线授权文件被拷来拷去，本质上都是同一个问题——你的授权在技术上是可以被无限复制的，而你在管理上看不见复制发生了没有。