西门子商务一封邮件过来:“贵司用户数已超出合同上限,请尽快补购。”你一查——采购清单上写着 80 个 named user,结果一统计,90 天没登录的 23 个,离职员工还挂着的 7 个,一个人俩账号的 5 个。真在干活的人排队等账号,离职三年的还在占坑。
这种事几乎每个上 Teamcenter 的厂子都会遇到,年年发生。不是系统坏了,是账号治理没人管。
跟浮动许可那种“用完即还”不一样,named user 是跟着人走的,签了约就是占坑不还。一个用户在 Organization 里建出来、挂上 Person、绑定 Group/Role,License 就算吃上了,管他登不登录。
账号背后连着三样东西:许可证席位、Workflow 任务、权限模板。要么清,要么废,不会自己跑。所以“资源不足”在这个场景下,八成不是 license server 爆满,而是 named user 池被占满了——买家买的不是并发数,是人头数。
别上来就批量禁用,先出一份“事实清单”——这玩意是给采购、业务、法务看的,不是给你自己看的。
搞不清楚的,标“待补证据”,别瞎猜。盘点完抽样回读源系统,人工导出合并过程丢过数据的案例我见得太多了。

以上这些动作,Excel + HR 流程 + 定期人力盯梢,百人规模以内能顶。人一多、账号一杂,靠手工就会漏,这时候再上许可优化类工具做集中监控、任务留痕,把发现、回收、验证串起来。工具是把流程跑顺的,不是替你做决定的——谁该删、谁该留、业务优先级,还是得人拍板。
指标异常先查采集口径变没变,再判断业务是不是真变了。
去年一家做注塑装备的,Teamcenter 12.x,合同 150 个 named user,全员喊不够用要加到 200。运维经理先按上面路数跑了三周摸底:30 天没登录的 41 个,90 天没登录的 63 个,离职未注销的 18 个,一人多号的 9 个。对完账,真缺口算出来其实不到 10 个。
处理也是按流程来的:先跟业务主管逐个确认回收名单,走例外登记的 14 个(长期外派、待产假这类)保留;离职账号按入转调离流程逐个禁用、对象所有权转移;再按岗位模板重新配 Role 和 license 等级。整个动作分了三轮,每轮回收完都回读验证。
结果:回收出 52 个账号,重新分配 40 个,剩余 12 个备用,加购计划直接冻结,一年省下的用户数扩容费用接近 30 万。最实在的是——HR 离职单现在自动带出 IT 账号处置工单,离职账号关闭时长从原来平均 40 多天压到 3 天以内,审计那边也没再挑过毛病。
这事没什么高深的,就是先对账、再清理、最后才谈加购。顺序反了,钱花了,人还是没号用。