说清楚：Teamcenter 的许可，卡的是“人”，不是“并发”

Teamcenter 的账号问题，很多时候不是“买少了”，是名字挂在系统里，人早就不在流程上了。入职先开号，项目换了权限不动，人走了账号还在，外包结束没人提，几次下来账号池顶满，新来的人开不了号，业务那边就开始走“共用账号”或者临时借号的路子。等到你开始查，会发现账面上一堆“活跃用户”，真正每天在 TC 里干活的，可能比想象的少一截。

Teamcenter 的许可结构和 CAD 的浮动许可不是一回事。基础许可以命名用户许可为主，细分为作者许可、消费者许可、临时许可等，模块许可另算，基础许可和模块许可都具备才能完整使用某个模块。命名许可的核心规则是“按人绑定”，一个 Named User 不能同时被多个人使用，同一自然月内可以重新指派给另一个具体的人，但名额本身是固定的。

这就决定了 TC 账号治理的逻辑：不是看高峰时段有多少人同时在线，而是看有多少账号“占着命名许可的位置，但没有对应的有效使用行为”。一个作者许可被一个三个月没登录过的离职员工挂着，就等于这个名额物理上消失了。你再买，买的不是容量，是给历史账号的粗放管理补窟窿。

最容易看走眼的一件事：登录活跃 ≠ 模块活跃

很多企业拉 TC 账号报表，第一眼看日活、月活，觉得“人不少啊”。但 TC 的账号消耗是分层的：登录进入系统、浏览 BOM、查看图纸、提交流程，这些动作证明平台有业务存在，但它们消耗的是基础访问权限，不一定在消耗你真正花钱买的高价值模块许可。

一个工艺工程师每天登录 TC 看三次流程状态，和一个设计工程师连续四小时在 TC 里跑结构管理和变更协同，在“日活”这个口径下是一样的，但对许可资源的实质占用完全两码事。只看活跃账号数，你看到的是“有人在用 TC”，看不到“命名许可被谁有效消耗了”。

所以摸底的第一步，不是统计“谁没登录”，是把登录行为和模块行为拆开。登录记录从 TC 的访问日志里拉，模块消耗要看许可服务器那边的基础许可和模块许可签出记录，两边对起来，才能分清哪些账号是“真在用”，哪些是“挂着名字但只做了浅层访问”。

回收之前，先把“不能动的”和历史包袱分开

命名许可的回收比并发许可麻烦，因为你动的不是一个会话，是一个和人员、岗位、项目、历史数据都挂着的身份。常见的几类账号，处理方式完全不一样：

• 离职账号。 最大的坑不是人走了，是数据所有权还挂在这个账号上。Teamcenter 里离职员工创建的部件、文档、流程对象，如果直接删账号，这些东西的归属会变成悬空。Siemens 官方建议的路径是先 deactivate，再根据情况用 Change Ownership 把对象转给在岗人员，或者永久保留为历史归属，不要一上来就 delete。离职账号的关闭，必须是“停用 + 所有权交接”两个动作，缺一个都会在后续的数据追溯里出问题。
• 转岗账号。 人在，但原来的模块权限已经不匹配现在的岗位。这类账号不要直接回收命名许可，先走角色和模块的重新配置。把作者许可降成消费者许可，或者把某个模块的访问摘掉，许可自然释放出来，账号本身还留着。
• 外包/项目型账号。 项目结束日期是明确的，但系统里往往没有对应的到期动作。这类账号的命名许可回收，前提是项目关闭流程和账号关闭流程挂钩，不能等 IT 去猜哪个外包该走了。
• “先别动”账号。 每个企业都有几个权限复杂、历史长的关键用户账号，谁都不敢碰。这类单独列白名单，但白名单本身要有复核周期，不能变成永久豁免。

回收动作要落到“谁通知、谁确认、谁执行”

命名许可回收最容易激化矛盾的地方，是IT 单方面把号停了，业务那边完全不知道。一个人出差回来发现 TC 进不去，里面还有没提交的流程，电话直接打到 IT 负责人那里。

比较稳的流程是：

第一，回收之前出清单，不直接动系统。 把“连续 N 天无登录且无模块签出记录”的账号拉出来，带上最后登录时间、最后模块使用时间、所属部门和直线负责人，发给业务侧确认。确认的目的是区分“真该收”和“有特殊情况”，不是走过场。

第二，离职账号和业务确认脱钩，走 HR 驱动。 离职账号的停用不需要业务慢慢确认，入转调离的同步机制里，离职事件应该直接触发 TC 账号的 deactivate，同时启动数据所有权转移。这一步慢一天，命名许可就多占一天。很多企业的 JML 流程和 TC 账号管理是两条线，IT 知道人走了，系统不知道，这是最冤的占用。

第三，回收执行后要能回读。 停了哪些号、释放了哪些命名许可、这些许可重新分配给了谁，要有记录。“命令成功”不等于“账号真的不可用了”，抽样登一下，确认状态变了，才算闭环。

指标不要只看“账号总数”

四个东西放在一起看：

• 活跃账号率：分母是当前处于活动状态的命名许可账号数，分子是周期内有模块级操作记录的账号。只用登录记录当分子，这个数会虚高。
• 离职账号关闭时长：从 HR 离职生效日期到 TC 账号 deactivate 的时间差。这个数最能暴露 JML 有没有真正接到账号管理上。
• 重复/冗余账号数：同一自然人对应多个账号、或者同一个岗位存在多个命名许可占用的情况。这个要靠人员主数据和 TC 账号做匹配才能发现。
• 回收后再分配率：收回来的命名许可，有多少在下一个周期内被分配给了真正有需求的新用户。收了不用，只是把浪费从一个人转移到了池子里。

指标异常的时候，先回去看采集口径有没有变。上个月还在统计“登录过就算活跃”，这个月改成了“有模块操作才算”，活跃账号率会掉一截，但那不是业务萎缩，是口径修正。

一个实测，数字不惊人，但每一步都对得上

某装备制造企业，Teamcenter 命名作者许可 68 个，系统里活动账号显示 71 个——已经超了，新账号开不出来，业务在走共用账号。IT 先没申请增购，把 TC 访问日志和许可服务器的基础许可签出记录对了一遍，发现连续 90 天无模块级操作、但账号仍处于 active 状态的命名许可占用有 19 个，其中 11 个对应的是已经离职或转岗超过三个月的人员，剩下 8 个是项目结束后没有再使用的外协账号。

他们没有直接停号。先走 HR 名单核对离职状态，对 11 个离职账号做 deactivate + 数据所有权转移，8 个外协账号通知项目负责人确认结束后停用。收回的 19 个命名作者许可，其中 14 个在两周内分配给了排队的新用户，剩下 5 个留作缓冲。系统里的活动账号从 71 降到 52，新账号开通恢复正常，增购单子撤了。 模块许可那边没有动，因为模块签出记录显示高价值模块的峰值占用并不紧张，问题确实在命名账号这一层。

这件事里没有任何复杂的技术动作。就是把“账号状态”和“人的状态”对上了，然后把停用动作接到了离职流程上，而不是等 IT 季度盘点的时候再翻。命名许可治理真正的起点，是承认账号不是 IT 的资产，是组织变化的投影。 投影不清理，换什么工具都是在给旧影子续费。