台账、合同、日志各管各的？先把四本账合到一起再说 License 优化

早上九点研发总监冲进 IT 办公室要 5 个 NX 席位，说项目要开工等不了；下午采购拿着上个月刚签的续约单来说预算冻结；晚上厂商的合规函躺在公共邮箱里没人认领。这三件事其实是同一件事的三个切面，但在绝大多数企业里，IT 看日志、采购看合同、业务看项目表，三本账互相对不上，谁也不知道全貌长什么样。

问题本质，先掰扯清楚

许可治理的本质不是“少花钱买软件”，是把四条数据流串起来：台账（装了什么）、合同（买了什么）、日志（用了什么）、业务（什么岗位什么项目在用）。四条流断了任何一条，剩下三条都只能做局部判断，得不出全局结论。台账没更新、合同翻不出来、日志看不懂、业务没人配合——四个问题里任何一个单独拿出来都能拖死治理。

从现象倒推数据，别看截图下判断

同一个“许可不够用”的现象，可能来自四种根因：容量真不够、配置错（比如 GROUP 规则把人挡在外面）、流程断（离职没回收）、合规边界模糊（外包用没算进授权范围）。这四种根因对应的动作完全相反，前一种要采购，后三种要治理，方向搞反了花钱买罪受。所以别只看 lmstat 拉出来的占用数，得把日志时间线和业务排期放在一起看，找出持续性问题和偶发噪声的区别。

诊断清单，三件事

有没有统一的软件目录？装了什么、装在哪、谁在用，这三个问题能不能在一个地方答出来？目录里该标“已确认、待确认、不适用”，不同部门别重复核查同一份东西。安装、授权、使用三账能不能关联？能关联到具体设备、账号、模块的才有解释力，只看汇总数等于没看。数据更新频率和责任边界有没有定？台账谁维护、多久更一次、日志谁拉、异常谁处理，这些没定，治理就是空中楼阁。

实施顺序，别倒着来

先建标准软件主数据——一个软件一个唯一编号，版本、模块、授权类型、合同号全挂上去，这是所有后续分析的骨架。然后连数据：发现工具装上，SCCM 或 EDR 拉安装清单，FlexLM 或 DSLS 的日志接入，采购合同录入系统而不是躺在 Excel 里。第三步按风险和成本排优先级，别上来就想覆盖全部软件，先抓贵的和合规风险高的。最后形成月度运营加季度决策的机制，数据更新到动作、动作反馈到数据，转起来才算治理。

盯四个数

资产覆盖率（实际盘点到的安装数 ÷ 应纳管终端数）、数据匹配率（三账能关联的比例）、闲置许可量（零使用许可的年化费用）、合规差异数（有凭证支撑的安装数和总安装数的差）。每个都留分子分母和下钻明细，汇总数没法解释原因就没意义。

一个真事

西南一家做工业机器人的，600 人规模，原来 NX、SolidWorks、AutoCAD 各一套账：IT 的 Excel 台账三个月没更新、采购的合同文件夹在共享盘里、许可服务器日志从没人在意。审计前两周，老板问“我们到底买了多少套 SolidWorks”，三个人给出三个数：IT 说装了 80 台、采购说买了 60 套、日志显示峰值并发只有 35。后来花了一个半月把主数据建起来，接上 FlexLM 日志和采购合同库，跑出真实数据：SolidWorks 装机 82、有凭证 58、真实峰值并发 39，缺口比想象小但浪费比想象大。最后动作分两步：按真实峰值砍了 15 套续费量，省了将近 12 万年费；把装 130 套国产 CAD 的历史缺口报给法务，以采代赔补了差额授权，审计一次过。老板最意外的是，第一次知道公司一年光维护费就 80 多万。

涉及合同解释和对外承诺的部分让法务把关，技术和采购把事实和证据做扎实，两条线别搅一起干就行。