A部门常年闲置，B部门天天抢不到

总部买了100个，A门店永远抢不到，B门店常年空着一半。

这话是我一个管整车仿真平台的朋友说的。集团统一采购的100个token，按采购单分给三个子公司，A子公司高峰期denied一大把，B子公司平均占用率不到一半，钱是总部出的，矛盾全都堆到IT头上。加买吧，B那边空着不合理；不加吧，A那边天天投诉。卡就卡在——license是按“谁买单归谁用”分的，而需求从来不按采购单长。

一、根源：license是静态分配的，需求是潮汐的

• 采购跟着预算走，预算跟着部门走，分完就锁死。但研发需求是有时段波动的——项目阶段、交付节点、季节性排产，每个部门的峰谷完全不同步；
• 部门A的谷值跟部门B的峰值如果错开，理论上一个池子就能覆盖两个部门的峰值之和，而不是各自买各自的。现实是谁也不搭理谁；
• 技术上license server根本不在乎请求来自哪个部门，FlexNet的浮动许可、DSLS的concurrent池天生就能共享。锁死license的不是技术，是采购合同和管理习惯。

二、四个常见的坑

坑1：只见总账，不看时段。 每个部门的月均占用单看都“还行”，拼在一起看不出错峰潜力。没有按时段画过使用曲线，谁也说不清重叠了多少。

坑2：共享走口头，成本没分摊。 两个部门说好共用一个池子，没写分摊规则。年底A部门用了70%的量却摊一半的钱，B部门闹到老总那里，共享直接散伙，比不共享还糟糕。

坑3：合同里没留共享的口子。 有些许可按部门/主体签，跨法人或跨区域的共享被EULA卡死。等想pooling了才发现要重新谈合同，一谈半年。

坑4：抢锁抢出来的假峰值。 池子开放后没人定优先级，手快的部门每天早上八点半挂脚本抢license，手慢的部门永远denied。数据被抢锁行为污染，采购决策跟着失真。

三、四层解决方案

第一层：先摸底

• 把所有license server过去6-12个月的日志拉出来，按部门、按地域、按时段三个维度拆：每个部门的P95并发、denied时间点、峰谷曲线；
• 画一张“各部门使用时段重叠图”——X轴是时间，Y轴是占用，每个部门一条线。重叠部分就是你家license的浪费洼地；
• 拿到这张图，pooling能省多少、怎么分池，一眼就有数。

第二层：零成本配置优化

• 技术池：同一台license server上把各部门的浮动许可合并成一个总池。FlexNet体系用option file的GROUP+RESERVE做软隔离——RESERVE n feature_name GROUP dept_x，平时共享，谁急了谁多用；
• 时间池：峰谷错开的部门用scheduler错峰——自动化作业调到夜间低谷跑，白天人工高峰留给另一部门；
• 优先级规则写进option file：核心交付组的作业RESERVE保底，剩余部分先到先得，规则公开。

第三层：优化采购策略

• 合同里主动写清共享范围：同一法人主体内部跨部门共享、跨厂区共享是否允许，续约时跟厂商确认并落进条款，省得事后扯皮；
• 按合并后的总峰值采购，不是按各部门峰值之和采购——错峰共享做得好，这一项就能省15-30%；
• 成本分摊机制白纸黑字：按实际使用时长/次数按月分摊，DSLS和FlexNet的log都能出账，OpenLM这类工具能直接按部门出chargeback报表。

第四层：上工具做长期管理

多server、跨地域的集团规模，靠脚本拼日志撑不住。OpenLM支持FlexNet、DSLS、LM-X等多协议，能跨server出按部门、按时段的报表和chargeback；轻量方案就是Python解析log+Grafana画时段曲线。跨时区的场景（比如中国团队和欧洲团队）时差越大错峰越狠，共享收益最高，前提是时区数据也要进报表。

四、一个小案例

某汽车零部件集团，三个子公司共用一套CAE平台，仿真token共120个，按采购单分：A公司60、B公司40、C公司20。年license支出约380万。

摸底发现：A公司日均占用52个、周周denied；B公司日均18个、占用率45%；C公司日均11个。三个公司的峰值时段几乎不重叠——A上午+晚上跑批，B下午，C集中在月底节点冲峰。

整改：token全部合并成一个池，option file按GROUP做软隔离，A公司交付期RESERVE 55个、平时不锁；自动化作业错峰到夜间；成本按实际使用量月度分摊进各部门预算；续约合同里写明集团内共享合法。

结果：token总量从120个降到88个（降27%），年支出降到296万；A公司denied从月均90次降到10次以内；B公司占用率提到71%；三个公司再没人找IT吵架——池子还是那些池子，只是终于流起来了。

先别急着加买。把各部门的使用时段画在一张图上，看看重叠了多少。