软件台账、合同、安装量、许可日志——四本账对不上，License优化就是空转

一个NX，采购台账里叫“Siemens NX”，安装扫描记录里是“UG NX 12.0”，FlexNet日志里feature名字写着“nx12000”，法务手里的合同附件又是另一套产品描述。四本账，四个名字，四个负责人，四个更新频率。你拿什么去对账？这不是段子，这是大部分工业企业的真实状态。软件资产管理的性质说到底就一句话：让“你买了什么”（entitlement）和“你实际在消耗什么”（consumption）之间有一个可复核、可解释的对应关系。台账是采购视角的拥有量，合同是法务视角的权利边界，安装数据是IT视角的部署事实，许可日志是运行时视角的消耗事实。四者不归一化，任何“优化”动作都是拿假数据做真决策。归一化（normalization）不是IT的洁癖，是后面所有对账成立的前提——把不同的安装字符串映射到同一个publisher-product-edition-version的层级上，映射不上，匹配就是空的。

核查重点别贪多，先把三件事钉死。

第一，软件目录有没有主数据。 不是一张Excel，是一个每个部门都认的“这东西叫什么”的基准。同一个软件在不同部门的台账里名字不一样，后面的资产覆盖率和数据匹配率全是废的。

第二，安装、授权、使用三账能不能按同一个键串起来。 至少用户、设备、feature、时间这四个维度里有两个能对上。对不上，你就不知道一条安装记录到底对应的是哪个合同条款、哪次签出、哪个项目。

第三，例外场景有没有标出来。 离线机器的节点锁许可、某个项目组的reserve保留、厂商送的临时eval授权，这些东西不标，回收策略第一个误杀的就是它们。例外不是漏洞，例外是必须被记录在案的事实。

实施顺序其实没什么优雅的走法，最脏的活先干。先把软件主数据建起来，把安装字符串灌进归一化引擎跑一遍覆盖率，看看哪些publisher或者product漏了——这个覆盖率不跑到85%以上，后面别急着做reconciliation。然后把entitlement挂到合同上，metric type、生效日期、到期日、数量，缺一个字段就是一个盲区。到期日空着是续费提醒永远不触发的头号原因。接下来才是对账。对账结果只有三种：装多了、买多了、对得上。买多了走reclamation，装多了走remediation，两种任务的逻辑完全不一样，混在一起就是灾难。最后才是续费窗口。续费的数量应该是过去一个完整周期里denial日志和reclamation记录共同支撑出来的数，不是你去年买了多少、今年涨个百分比。

指标别搞太复杂，但每一个都要能下钻。资产覆盖率——不是全公司一个百分比，是按部门和软件拆开，哪块没覆盖到要能点进去看见具体设备。数据匹配率——安装记录里有多少条成功关联到了合同条目，匹配不上的那部分是哪些、为什么。闲置许可量——分子是闲置签出数，分母是总签出数，分子怎么判定的、阈值多少、误杀率多少，都要有记录。合规差异数——安装量减去有效entitlement，差异是正的还是负的，对应的是补采购还是回收，责任人是谁。单个指标好看没有任何意义，效率、体验、风险三个东西同时在一个可接受的区间里，才算数。把安装量当授权量、把登录人数当并发峰值、把lmstat的瞬时输出当利用率，这三件事只要干了一件，后面的报告就可以直接扔了。还有，没有denial数据就设回收阈值，等于蒙着眼睛调参数——FlexNet的lmstat只告诉你池子里剩几个，不告诉你谁被拒绝过、哪个模块在峰值时段崩了。

说一个具体的。去年一家做非标自动化的公司，三十人出头的机械设计团队，CAD浮动许可买了80个，研发总监天天喊不够，要再加30个。IT没急着买，先挂了两周只读监控，不动任何策略。数据出来之后两件事很扎眼：有效并发只占购买量的58%到63%，也就是说八十个许可里真正在操作的不到六十个；午休时段接近四成的会话根本没断，早上开了软件去开晨会、去抽烟、去刷邮件，许可就那么签出着挂在那儿。厂商的FlexNet日志里这些“人走机开”的情况是看不出来的，lmstat只知道feature被拿走了，不关心拿走的人是不是在干活。IT做的第一件事是开静默闲置回收，阈值设了15分钟，后台悄悄把许可收回池子，用户回来操作时系统无声无息重新申请，界面不弹窗、不中断。第二件事是把监控按模块拆开，发现高级曲面模块被一小撮人长期占着，其中有些人根本只用基础功能，高级模块的回收阈值单独压短。三个月后许可从80降到68，又过了三个月落到63，原本要加的30个一个没买。这家公司没什么神奇的工具，就是把四本账里的两本——安装签出和实际使用——先对上了，然后才动的手。