一个项目结题,CAE那边的30套license空出来,隔壁新立项的电控组却天天denied申请加购。你去问采购能不能"调"一下,采购说合同签的是谁的归谁,得走厂商的transfer流程,一来一回一个多月。等调过来,新项目节点都过了。这种事一年能发生好几回,license在企业内部流转,比跨公司借还费劲。
license是静态绑定的,需求是动态流动的。 这就是矛盾的本质。
调配慢的本质不是技术问题,是调配动作没有标准化、没有留痕、没有系统承接,全靠邮件和工单在各部门之间漂。
坑1:调配走口头和邮件,没有台账。 谁批的、从哪调到哪、什么时候调的,全在聊天记录里。半年后audit或者续约对账,谁也说不清某套license"名义上属于谁",重名、漏记一堆。
坑2:只调 Individual/Named User,不调并发池的优先级。 很多人以为调配就是把激活码换个人,其实Concurrent池里更该调的是option file里的RESERVE和GROUP——哪个组高峰期缺,就把RESERVE配给哪个组,这才是池子里的"调配"。没人动这个,池子永远按三年前的项目结构在排队。
坑3:离职、转岗不回收。 人员走了license还挂在名下。我见过的企业里,离职用户名下挂着的license平均占存量的一到两成,没人回收,新员工就只好买新的。
坑4:把厂商的付费transfer当成唯一路径。 有些许可确实要走厂商流程(比如node-locked迁移硬件、跨法人主体转移),但大量内部调配——同一个license pool内换绑用户、改option file分组——根本不需要动合同,管理员在license server上几分钟就能做完,却习惯性地全部丢给采购走厂商流程。

lmutil lmstat -a,结合option file;MATLAB进License Center导出user list;Altair进ALM的data目录看feature级使用。RESERVE 3 feature_name GROUP cae_core给核心组预留,EXCLUDE把不该用的挡掉,改完lmutil lmreread热加载,不用重启server,整个过程五分钟;规模大了(几十个feature、多server、多部门)就别靠手工台账了:
某做非标设备的制造商,研发90人,SolidWorks 30套(SolidNetWork License Manager,FlexNet体系)+ Abaqus若干token,分机械、电气、仿真三个组。
摸底发现:机械组18套SolidWorks月均签出率只有40%,仿真组常年denied;option file是四年前写的,RESERVE全给了早裁掉的项目组;还有6套挂在已离职员工名下。
整改:option file重写——RESERVE从旧项目组改到仿真组5套,机械组保留12套共享池;6套离职license回收转给新员工;调配台账上线,所有变更登记;续约条款里和厂商确认了pool内部调配免费用。
结果:SolidWorks总采购从30套降到24套,年省维保约11万;仿真组denied从月均40多次降到5次以内;调配周期从原来的一两个星期缩短到当天。