查了一个月“利用率低”，最后发现是统计口径在坑我

先说结论：别急着砍许可。我见过太多团队，报表一看利用率30%，采购直接要回收50个席位，结果下个月研发那边炸锅——不是没人用，是统计压根没算对。

这事得掰开讲。

利用率这个数，天生就容易被算歪。 分母是什么？是采购量还是已分配量？分子又是什么？安装量、活跃登录、还是真并发？这三个东西差得能差出一个数量级。我见过把安装量当活跃量的，CAD装在三百台机器上，常年打开的不到八十人，报表一出来利用率26%，采购当场就要砍。可实际上那两百多台机器里，一半是产线工控机，装着但只在排产那几天用。你砍了试试？

所以第一件事，永远是核对口径。导出源数据，回读原始记录，看看中间有没有丢失、有没有把休眠账号算进去、统计周期覆盖没覆盖完整业务周期。项目型团队尤其注意，淡季平均数会把你带沟里去，峰值才是采购的真实依据。

第二件事，把模块拆开看。 大套件许可最坑人。一套PLM买下来，设计模块用得飞起，仿真模块可能一年没几个人碰。混在一起算利用率，永远是个不上不下的数字，什么都说明不了。按软件、按模块、按部门三层下钻，才知道钱到底花在哪了。

第三，闲置和错配是两回事。 闲置好办，账号三个月没登录，回收，走流程。错配麻烦点——A部门闲置的浮动许可，B部门天天排队等并发，这时候要做的不是回收，是重新划池子。别一刀切。

改进动作落地的时候，几个硬要求：指标定义要留版本号和变更理由，不然明年审计对不上账；回收前先定影响范围和回退方案，别上来就禁用账号；每条整改任务必须有负责人和截止时间，没有这个，人员一变动全白干。

验收别只看汇总数。活跃率要能抽回到具体账号，峰值利用率要能按项目下钻，回收再分配率要留异常样本。汇总值看着漂亮但解释不了原因的，一律打回。

说个真事。 某汽车零部件厂，正版EDA许可60套浮动，报表利用率常年40%出头，管理层嫌贵要砍到40套。IT那边没直接执行，先拉了三个月的并发日志，发现每周二下午并发冲到58，其余时间 utilization 趴在30%以下——原来是仿真组周二固定集中跑版图验证，平时大家用的都是另一组本地授权。最后没砍许可，改了调度：把浮动池拆成两个子池，仿真组专池20套加弹性借用，其余40套开放给全部门。砍预算的事没了，排队投诉也停了，年度续约谈判的时候手里有完整的并发曲线，价格都好谈。这事的关键就一条：他们先回读了源数据，没信报表。

工具层面，gofar 这类资产台账能把安装、授权、使用线索归到一处，闲置席位的证据链好留。但归集归集，回收不回收、怎么跟采购谈判，还是人拍板的事，工具替不了合同和判断。

先查口径，再拆模块，最后谈回收。顺序反了，钱白花，人得罪。