Teamcenter 账号不够用？多半不是不够，是没清过账

新来的同事入职，IT 去 Teamcenter 里开账号，系统提示授权数满了。采购那边一问，一套 Named User 授权不便宜，预算还得走流程。于是就卡住了，开发那边等着进系统看图纸，群里天天催。

干了这么多年 PLM 运维，我的第一反应从来不是"赶紧买"，而是先把账查一遍。Teamcenter 用上几年之后，账号里的水分比你想象的大得多。

先搞清楚这是什么问题

Teamcenter 的"账号资源不足"，其实混杂了三件完全不同的事：

• Person 记录：组织里的人员条目，占的是人员规模。
  
• 授权（License）：真正花钱买的东西，Named User 是按人头算的，也有浮动类型。
  
• 会话（Session）：谁在线上、谁占着连接。
  
• 这三个数经常被当成一件事说。领导问"我们还有多少账号"，IT 报的是装了多少、采购报的是买了多少、实际在线的可能只有一半。口径不统一，后面所有动作都是蒙的。
• 再往深了说，同一现象背后可能是容量、配置、流程、合规四种根因。比如共享账号这事，表面看是省了一个授权，实际是合规雷——谁改的数据都查不出来。

几年下来，账号里都攒了些什么

• 离职人员没停用。人走了半年，账号还活得好好的，甚至还在组里、还占着角色。
  
• 一个人多个账号。外包进场开一个，转正再开一个，老的那个没人记得。
  
• 权限给太宽。明明只是看图纸、走审批，却给了完整作者权限。这类占的是高级授权，最贵。
  
• 共享账号。几个人轮着用一个，图省事，后面审计根本说不清。
  
• 服务账号、集成账号、测试账号混在正式人员里，没人管。
  
• 调岗后旧角色没收回。从设计转到工艺了，两边的组都在。
  
• 没有同步机制。HR 那边离职生效了，IT 这边压根不知道，靠人传话，传着传着就漏了。

怎么干：先查清楚，再谈优化，工具放最后

第一步，盘账。这一轮不删任何东西。

1. 核对账号、人员与组织状态。拿 HR 花名册去比对，在职的、离职的、外包、借调，一个个对。对不上的人单独列出来，找业务部门确认。
   
2. 识别长期未登录和重复授权。拉登录审计日志，90天没动静的先标黄，180天没动静的重点查。同名、同手机号、同邮箱前缀的疑似重复也列出来。
   
3. 确认不同角色的最小权限需求。哪些人真需要创建和修改，哪些人只是查看和审批，哪些人只走流程。要能回到具体的人、具体的组、具体的角色，只有一个总数没法动手。
   
4. 导出来的表一定要抽样回读源系统。我见过导出时字段截断、人工合并时粘错行，最后拿一份错的表去跟业务吵架，很尴尬。
5. 还有一句，例外场景和批准人要一起记。总有人是真的半年不登录（比如长期驻厂的），误伤了他，项目就停在那儿了。
6. 第二步，动刀。分四步走，别一次干完。

• 建立入转调离同步机制。这是最治本的一条。跟 HR 对接口，离职、调岗、转外包都要有触发。指定负责人、写清时限，比如离职生效后 3 个工作日内停用。做完要回读验证，看这个月实际执行了几单。
  
• 设不活跃账号复核周期。建议季度一次，先从一个部门试点。通知发到本人和业务负责人，给回复期限，没人认领的才停用。
  
• 回收前必须通知业务负责人。不是通知 HR，是通知用人部门的主管。因为只有他知道这个人是不是在做一个长周期项目。
  
• 按岗位模板重新分配角色和许可。设计工程师一套模板、工艺一套、采购一套、只看图纸的一套。以后新人入职直接套模板，不要再单独配。
  
• 这里有个 Teamcenter 的特殊点要提醒：Person 记录一般不建议直接删。它跟历史数据、工作流任务、对象拥有权绑着，删了容易出 orphan reference。通常的做法是停用账号、收回角色和组、把他签出或拥有的对象转移给继任者。
• 第三步，才轮到工具。
• 在数据层，许可优化这类能力可以把安装、授权、账号分配、会话记录归到一个视图里，也能持续记着重复账号数这类证据。但管理层的事它替不了——哪些人该留、哪些该收，得业务和 IT 一起签字。

拿什么判断干成了

• 活跃账号率：指定谁负责、多久复核一次。
  
• 离职账号关闭时长：公式写死，从离职生效日算到停用日。
  
• 重复账号数：看趋势，口径变了要记一笔。
  
• 账号回收再分配率：回收的授权里有多少真的再分出去了，别回收完堆在那儿。
  
• 指标突然变好或变差，先怀疑采集覆盖和口径，别急着说业务变了。效率、体验、风险三项同时过得去，才算验收。

说个实际干过的例子

一家做工程机械的厂，Teamcenter 跑了六年，人员从三百多涨到快八百，授权数早打满了，业务部门一直在催采购加买。

我们花两周盘了一遍账。HR 在职名单是 812 人，Teamcenter 里活着的 Person 记录有 890 多条。比对下来，离职未停用的 46 个，一个人开两个号的 23 组，外包结束没收回的十几个。

再看权限，更夸张。走审批流程的、只查物料的、供应商那边看图的，全都给了完整的作者角色。真正需要创建修改的岗位，其实只有三百多人。

做法很土。先把离职的 46 个停用、角色收回、拥有的对象转移给组长；重复的 23 组合并；然后按岗位重套模板，把只读需求的人降到查看类角色。没有删一条 Person 记录。

最后一轮下来，腾出六十多个授权。第二年续费不但没加，还往下压了一点。整个过程中只有一位驻厂的老工程师被误停用，他主管当天就反馈了，十分钟恢复。所以先通知业务负责人这条真不是形式主义。