很多人做 SAP 权限管理做到删除用户这一步就默认收工了SU01 里选中用户点删除屏幕提示用户已删除完事。但在 S/4HANA 这个时代尤其是从审计合规的角度看删掉只是一个开始。业务用户被删了不代表它的用户主数据从系统里消失了它只是被打上了删除标记继续躺在 USR02 里占用着用户号甚至还会出现在某些报表、后台同步任务和身份管理接口的返回值里。真正要把这些已删除用户收拾干净、合规安顿好靠的是 SAP 里一个专门的功能Maintain Deleted Business Users。我第一次接触到这个功能是被一个审计问题逼着去查的。当时客户刚做完一轮人员清理权限顾问删了几十个离职账号结果外部审计问这些删除操作有没有记录被删除的用户数据保留多久有没有办法物理删除一查才发现SAP 根本没把用户真正物理删掉而是软删除。后来在 Fiori Launchpad 里找到 Maintain Deleted Business Users 这个 App又结合 SU01、SUIM、AL08 把这些已删除用户从标记到清理走了一遍才算是把这块彻底打通。这篇文章我就按自己的实际经验把已删除业务用户从原理到实操再到踩坑排错完整写一遍。适合 SAP Basis、权限顾问、IAM 项目上负责用户生命周期的朋友参考也适合刚接手用户管理、想把离职账号这件事做规范的新手。1. 为什么删除用户不等于删干净先搞懂业务用户的生命周期1.1 你删掉的只是一个标记SAP 用户主数据的真实存在形式很多非 SAP 背景的同事会有一个习惯性认知删除用户就是把这个人的所有账号信息从系统里彻底抹掉像回收站清空一样。SAP 不是这个逻辑。SAP 里执行用户删除操作时系统做的是标记删除——把用户主记录标记为已删除状态但这个主记录本身仍然存在于底表中USR02、USR03、USR21 这些表里的数据都不会真的消失。这么做并不是 SAP 设计偷懒而是有实际考量。用户主数据关联的不仅仅是登录名和密码还关联权限角色分配、业务伙伴信息、工作流任务、采购单或审批单的创建人字段。如果真把物理记录删了老的单据会因为找不到对应的用户主数据而出现各种异常——比如审批历史里的创建人显示不出来、ALV 报表里责任人一栏变空白、工作日志里用户号悬空。为了不影响历史业务数据完整性SAP 选择了软删除这个折中方案用户从可见的用户列表里消失但底表数据保留历史记录还能关联上。这就像你把通讯录里的联系人归档了而不是把手机里的联系人文件删掉。归档之后日常列表里看不到他但搜索旧聊天记录时那个头像和名字依然能对得上。理解了这个底层机制你才能理解后面所有问题——为什么已删除用户还占用户数为什么同名用户创建不了为什么审计报告里还能看到这个人根源都在软删除。1.2 审计与合规为什么已删除用户反而要专门管理如果说软删除是 SAP 为了业务连续性所做的妥协那已删除用户管理就是应对审计和合规要求的补丁。这里有个核心矛盾一方面系统需要保留历史关联另一方面外部审计和数据保护法规又要求企业不能无限期保留个人信息——尤其是离职员工的账号数据。我经历过的几个项目里外部审计对用户删除这块的检查点非常固定是否有用户删除的审批记录删除后的数据保留了多久是否还有未清理的僵尸用户残留是否定期执行过物理清理如果这些问题的答案都是没有那审计发现项基本就跑不掉了。特别是现在个人信息保护相关的法规越来越严GDPR 这类数据保护条例很多企业都明确规定个人数据保留期限到期必须彻底清除。SAP 的 Maintain Deleted Business Users 就是专门为满足这类需求设计的让你能看到所有处于删除状态的业务用户并按权限和保留策略做最终清理。这里要特别提醒一句审计看的不只是有没有删更看重删得有依据、留得有痕迹。哪怕你批量删了 100 个账号如果没留存一份删除前的权限快照、没记录删除审批单号、没按保留期规划清理节奏审计照样可以给你开一项。所以我后面会一直强调删除前导出、删除后留档这个习惯。1.3 这项功能到底能解决什么核心问题清单把 Maintain Deleted Business Users 的价值拆开看它主要解决四个问题。第一可视化系统里到底有多少已删除用户都在什么状态第二可检索按条件筛选出特定范围的已删除用户比如某个部门上个月删除的所有账号。第三可追溯查看这些用户的删除时间和删除方式为审计提供证据。第四可清理对超过保留期的用户执行真正的物理删除让数据生命周期完整闭环。实操过程中这四个能力缺一不可。你只清不查就少了一份审计依据你只查不清保留数据无限增长合规上迟早暴雷你查了清了但没留底等于白干。这也是我在做 IAM 项目时反复跟客户强调的Maintain Deleted Business Users 不是删除按钮的另一个入口它是用户生命周期管理的最后一环承担着生态收尾的作用。2. 删除用户之前的检查事项准备工作比下删除命令更重要2.1 先盘点清楚状态用 SU01 和 SUIM 摸清底细真正动手删除用户之前我建议你先花几分钟做一次状态盘点。不是打开列表直接删而是先明确三个问题这个用户现在处于什么状态他名下还挂了多少权限这些权限有没有被其他用户复用这三个问题清楚了后面不管是用 SU01 删除还是再到 Maintain Deleted Business Users 里清理都会顺很多。第一个问题看用户状态。最直接的就是事务码 SU01在用户维护界面可以看到当前用户是否存在锁定标记、是否被标记删除。不过 SU01 一次只能看一个用户要批量盘点建议用 SUIM用户信息系统它相当于用户和授权的报表中心可以在里面按用户、角色、授权对象、参数文件等维度组合查询。第二个问题看角色分配。在 SUIM 里跑一个用户分配的角色报表把用户名输进去就能看到这位用户挂了哪些角色包括直接分配的和通过复合角色间接拿到的权限。这一步尤其重要。很多权限顾问删用户时只删了用户本身结果这个用户对应的 PFCG 角色分配记录还挂在那边过段时间一看用户没了但权限残留。有残留意味着什么意味着如果后面有人重新创建同名用户可能会继承一组你想不到的旧权限这是非常大的安全漏洞。第三个问题看会话与后台任务。这个放到 2.2 单独说因为它最容易被忽略也最容易在删除时给你迎面一击。2.2 活跃会话和后台任务那些删不掉的用户我删过最棘手的一个用户是财务部一个离职的主管。当时种种检查都过了角色没复用、流程单也批了、数据也导出来了。结果 SU01 里点删除系统直接弹错说用户当前有会话存在。我一开始还以为是偶发情况后来才意识到那位主管的账号被配置在一个周期性的后台作业里每天定时跑相当于每天都自动登录一次所以删除操作一直被阻塞。所以我的建议是删除用户前一定先看活跃会话和后台作业。会话层面用 AL08也可以用 SM04查看当前登录系统的用户列表确认目标用户有没有在线会话。如果显示在线需要先与用户或管理员确认是否可以强制注销或者用 SM04 里的终止会话来清理。后台作业层面用 SM37 查一下作业列表看目标用户是否作为提交用户挂在某个周期作业里。如果有需要先处理作业通常是把作业移交到另一个服务账号或者直接停用相关作业。还有一种情况比较隐蔽就是工作流任务。如果该用户还有未处理的工作流项、审批任务挂在名下删除时也容易遇到依赖冲突。SAP 的工作流运行时SWU3 相关配置会引用用户 ID如果用户已删而任务存在轻则任务无法正常显示重则工作流运行时直接报错。稳妥的做法是删除前把该用户的待办工作流转发给接替者或者通过任务管理功能将其待处理项转向。这一步在离职交接流程中应当与业务部门协同完成权限团队不要自己拍脑袋处理。2.3 删除前的权限快照与审计留档别删得不明不白如果前面两步是安全层面和执行层面的检查那这一步就是审计层面的检查。我的习惯是在每个用户删除前做一次完整的权限导出存档。导出内容至少包括用户名、全名、部门、直接和间接角色、关键授权对象尤其是 S_TCODE、S_ADMI、S_USER_PRO 这类高风险权限、用户类型Dialog/Service/System、最近登录日期、创建日期。导出路径一般用 SUIM 相关报表也可以直接从 PFCG 的角色用户列表里拉更彻底点可以用 SE16 查 USR02、USR21、USR05 等关键表的数据导出后存档。这些导出文件在审计访谈时直接拿出来就能回答你怎么证明删除前这个用户只有这些权限这个问题。还有一个细节容易被忽略用户删除后尤其是软删除状态下的用户其名字会继续出现在很多历史记录里。如果你在删除前没有留存用户名 ↔ 员工信息的对应关系几个月后再回去查时哪怕看到用户名也不一定能对上真人。所以删除前最好连 HR 系统里的人员编号、部门、离职日期一起归档到一个统一记录表里权当是给系统留下一本用户墓志铭。我记得有次客户做年度权限复审需要确认某个已删除用户的售后审批历史就是因为当时没留映射关系折腾了快两天才对上人这个教训到现在我都记得。3. Maintain Deleted Business Users 实操从界面进入到批量清理3.1 两条进入路径Fiori App 与经典 GUI 的处理差异Maintain Deleted Business Users 这个功能在标准交付里是以 Fiori App 的形式提供的一般在 Fiori Launchpad 上搜索对应名称就能找到入口。它面向的典型使用场景是安全管理员或用户管理员需要集中查看所有软删除状态的业务用户并决定哪些可以清、哪些要继续归档。如果你所在的企业还在用经典 GUISAP GUI不要慌这个功能背后的用户主数据逻辑和事务码 SU01 是打通的。你可以进入 SU01在初始界面的用户字段里输入用户名或者直接在菜单里切换已删除用户视图查看用户当前的标记删除状态。事实上这两个入口查看的数据源是同一条链路USR02 表里的删除标记状态。差异主要体现在操作效率上——Fiori App 擅长拿条件筛选、批量处理和导出而 SU01 更适合单用户的查看和微调。需要提醒一点很多项目上线时 Fiori 并没有全量激活尤其是一些传统 ECC 客户可能还在用 NetWeaver Business Client 或者纯 GUI。这时候如果找不到 Maintain Deleted Business Users 这个 App不要硬等 IT 给你开 Fiori直接回归最底层的处理逻辑通过 SU01 标记删除用户再通过底层表数据和报表来管理这些已删除用户。工具缺了可以补但流程得跑起来别把没有 App当借口让清理工作停摆。3.2 界面里的核心维度和批量筛选实操要点拆解进入 Fiori App 后首页呈现的通常是已删除用户的列表界面。这个界面看起来简单但操作上有几个关键按钮和字段需要理解透彻否则容易误操作。首先是筛选区。你一般可以按用户名、姓名、部门、删除日期范围等维度组合检索。这里我强烈建议你每次操作都习惯性地把删除日期范围选上哪怕只是做临时查看。因为已删除用户列表默认是按某种固定排序展示的不设置日期范围你面对的就是一个所有历史删除用户的堆积列表。一旦企业跑了两三年这个列表可能有上万条记录直接加载会非常卡也容易看漏。用日期范围先把本次要处理的批次圈出来是高效操作的第一步。其次是导出功能。这个 App 支持把筛选结果导出为本地文件常见格式包括电子表格和文本文件这个导出不是给领导看报告的而是给你做审计留档用的。我建议每个批次清理前都导出一次清理前清单清理后如有需要再导一次清理后清单两份对上整个数据生命周期就闭环了。再往细节走列表里每一行用户一般会显示用户的删除状态、用户名、创建日期、删除日期等字段。重点要看的是创建日期和删除日期这两个时间点的差值——它是判断这个人是否属于长期野生账号的关键线索。创建时间久、删除时间晚、又在删除后长期未清理的用户往往对应着离职流程拖沓或者权限管理员漏处理的情况。这类用户在审计时最容易成为发现项所以清理优先级要拉高。3.3 最终清理的正确姿势保留期、确认机制与批量执行前面说的都是查看和导出真正让这个功能发挥安全管理价值的是最终清理物理删除这一步。在 Maintain Deleted Business Users 中执行最终清理和 SU01 里的删除用户不是一回事。前者是删除那些已经处于删除状态且确认无再使用需求的记录让它们从审计性保留的软删除状态变成真正的物理清除后者则是把正常用户标记为删除。在执行最终清理前你的脑子里要有一个保留期的概念。什么叫保留期就是用户被标记删除后你至少要保留它多久才能满足审计和业务追溯需求。这个周期没有统一的法定数字通常由企业自己的信息安全策略和数据保护要求决定常见的是 1-3 年。我参与的项目里有的客户定的是 2 年有的定的是 1 年加一个财季的缓冲但无一例外都在数据保护和个人信息治理的框架范围内做权衡。实操上你可以在 App 里通过筛选条件圈定一批已超过保留期的用户然后执行最终删除操作。执行前系统通常会有确认弹窗或表单要求再次确认有的版本还会要求填写删除原因备注。这一步的确认机制不是形式主义就是逼着你停下来想一想这批用户删下去是否会影响正在进行的审计是否有接替者还在依赖同名用户做历史查询我的建议是每次批量清理前都做一次二次检查至少让另一位同事复核一下筛选条件别自己一人拍板。3.4 把例行清理做成可重复流程不打无准备的仗一次性清理是急救能跑起来的例行清理才是真正的合规。这里给你一个可以直接抄作业的流程参考。第一步每月固定时间导出全部已删除用户清单。第二步按保留期规则筛选出到期用户优先处理删除时间超过保留期上限的。第三步对照上月的审计留档确认这些用户没有被任何进行中的流程引用。第四步在 Maintain Deleted Business Users 中执行最终清理并导出清理后清单。第五步把两份清单和操作日志一起归档到权限管理共享目录。这里面还有一个小技巧就是给这个任务设置一个后台作业或日历提醒。因为人总是会忘尤其在一个月有几十个用户变更的忙碌月份里例行清理很容易被排到后面。你可以用 SM36 定义一个周期性的后台作业只做数据导出和记录汇总不直接执行删除——删除还是让人来点但先拉数据这件事可以由系统自动完成。人负责判断机器负责提醒和准备这个配合用下来最稳。4. 常见问题与排查实录实战中踩过的坑4.1 用户删了之后还能不能重新创建同名冲突怎么办这是一个几乎每个项目都会遇到的问题。场景一般是某个员工离职后账号被删过了一两年另一位同名同姓或者同拼音的员工入职HR 系统里再生成一个一样的用户号结果权限管理员在 SU01 创建时系统报错用户已存在但你在正常用户列表里又找不到这个用户。原因其实就是软删除机制用户记录还在底表里只是被标记删除了。若用户号唯一性校验是照常执行的系统当然不允许你新建一个同号用户。碰到这种情况有两条处理路线。第一条如果原用户数据已经过了保留期可以走最终清理路径把这个软删除记录物理清掉再重新创建同名用户——这个操作在 Maintain Deleted Business Users 里很好用专门处理这种旧碍事数据。第二条如果原用户还没到保留期或者历史数据还需要保留关联那就不能急着清最好换一个用户号创建新用户避免旧数据被切断关联。这里我踩过一个坑当时图省事直接把旧用户从底部表里强行删了结果这个错删导致旧年度报表里审批记录的用户显示全乱。后来我学乖了凡是遇到同名重建第一反应永远是查保留期第二反应是查历史业务关联两个都确认无碍才敢清理。这不是技术难度的问题是想事周全与否的问题。4.2 已删除用户还占许可证报表里怎么还在另一个高频问题用户明明已经删除了为什么 LICENSE 相关的报表里还统计着这个用户为什么组织架构或用户清单报表里还能看到它答案还是绕不开软删除。许可证License统计的基础数据来自用户主记录表只要记录还在就很可能被计数。这时候的处理逻辑要看你的诉求如果是为了让许可证报表好看一点重点其实不在这一个已删除用户而在于整个用户基础里有多少这种僵尸记录——把它们全部清理掉许可证水位自然就下来了。这种情况更要依赖 Maintain Deleted Business Users 的筛选和导出功能先把列表拉全再逐一核对用途能清则清。如果是在某些自定义报表里还能看到已删除用户那就需要检查报表的取数逻辑了。很多开发在写查询时只设置了用户名 输入值没有额外过滤删除标记USR02 中删除标志相关的字段状态所以已删除用户还是会被捞出来。这不是功能本身的问题是你需要在报表里补过滤条件的问题。权限团队最好和开发沟通在报表层统一把删除标记作为标准过滤项从源头堵住数据看着不对的困扰。4.3 清理报错、数据不同步排查思路分享执行最终清理时遇到报错是最容易让人心慌的环节。常见报错之一是用户仍被引用系统拒绝物理删除。这种报错通常出现在用户与某些业务主数据、业务伙伴编号有关联的场景里。排查时先别急着怀疑功能坏了反而要感谢这个报错——它意味着系统在保护业务完整性。你需要做的是找到引用源解除关联后再尝试清理。引用源可能是业务伙伴关系、用户参数文件、工作流启动器甚至可能是自定义表里存了这个用户 ID。另一种情况是数据不同步。比如在 Maintain Deleted Business Users 里看到一个用户已经被清理了但在某些报表查询里还能查到它的用户名但点进 SU01 又提示不存在。这种残留索引类问题多与同步延迟或存储读取相关处理方法通常是做一次全量数据比对。如果经常出现就要检查后台是否有什么接口或程序在定期把删除用户重新同步回主表。我见过一次很有意思的“复现”案例已清理用户隔了两周又出现在已删除列表里查了一圈才发现是 HR 同步接口在定期把旧人员数据重新推送成业务用户等于自动复活了已删除账号。后来在接口配置里加了删除状态回写逻辑才算根治。4.4 常见问题速查表场景现象排查路径常用处理删除用户后列表仍可见用户状态为已删除未物理清理查 USR02 删除标志确认保留期Maintain Deleted Business Users 中执行最终清理创建同名用户报已存在底表记录未真正删除查原用户删除时间、历史关联过保留期则清理重建否则换新用户号删除时提示会话存在用户仍有在线会话或后台作业AL08/SM04 查会话SM37 查作业终止会话或移交作业后重试清理时提示用户被引用有其他表或主数据引用用户查看报错引用详情解除引用必要时基于业务判断保留用户许可证统计偏高大量已删除用户仍在计数导出全部已删除用户按保留期分批物理清理报表仍能看到已删用户报表未过滤删除标志检查报表取数逻辑增加删除状态过滤条件提示只要是清理操作一定要先在生产环境之外做一次预演至少在测试系统上跑一遍同样的筛选和清理逻辑确认不误伤再上生产。5. 把用户删除管理做成制度的落地心得Maintain Deleted Business Users 说到底是一个工具真正决定安全效果的还是背后那一套操作制度。我参与过几个 IAM 相关项目后最大的体会是用户删除这件事必须和离职流程、HR 系统、审计节奏深度绑定不能由权限管理员一个人凭感觉发挥。要将用户删除管理做成例行制度有几个维度一定不能省略。第一定义清晰的保留期。建议在信息安全制度里就写明软删除用户保留多久最终清理要遵循什么频率由谁审批所有已删除用户的操作记录统一归档。这部分内容看起来是文档工作但审计时最有说服力的恰恰是这份文档。第二把权限快照作为删除动作的前置条件。只要标准流程里把导出权限快照和提交删除申请绑定后面就不会出现删了又不知道删了什么。从技术上可以在 SUIM 里跑完导出再把导出文件附到变更工单上。整个过程不复杂复杂的是让大家都习惯这么干。第三定期核对用户生命周期中的异常信号。比如删除日期和最后登录日期之间间隔很短说明用户在删除前还在活跃用系统创建多年但一直没登录过的用户往往是重复账号删除时间超过保留期但又没清理的记录就是流程断点。这些信号靠人盯不现实建议每季度从系统里拉一次异常报告逐条核销。第四测试环境和生产环境保持一致的操作策略。我见过不少团队在生产环境清理得很勤快测试环境里却堆积了几年的已删除用户结果在做数据迁移或系统刷新时这些垃圾数据跟着进生产造成重复用户和权限冲突。所以在测试环境里同样要跑 Maintain Deleted Business Users 的例行清理别让测试系统沦为数据垃圾场。第五不要忽视操作日志的留存。不管是 SU01 的删除还是 Fiori App 里的最终清理操作记录都是审计的硬通货。很多企业用的是绑定审计日志的方式我建议在关键用户变更操作上再额外留一份独立记录包含操作人、操作时间、目标用户、操作类型和备注。这份记录在企业内部权限复审、外部审计访谈、甚至安全事件溯源时都能派上大用场。最后再说一个实际体会。很多人一上来就问Maintain Deleted Business Users 这个事务码是什么其实它更多是基于 Fiori 的功能 App理念上代表的是用户删除后的治理视角。你不需要把这个功能神话但也不能只把它当成一个清理按钮。它真正的价值在于逼着你去面对那些被你删了但还阴魂不散的业务用户逼着你去回答审计提出的你到底把数据怎么样了这个问题。把这块流程理顺了你的用户管理才算真正闭环。
SAP已删除业务用户治理：从软删除到合规清理实操指南
很多人做 SAP 权限管理做到删除用户这一步就默认收工了SU01 里选中用户点删除屏幕提示用户已删除完事。但在 S/4HANA 这个时代尤其是从审计合规的角度看删掉只是一个开始。业务用户被删了不代表它的用户主数据从系统里消失了它只是被打上了删除标记继续躺在 USR02 里占用着用户号甚至还会出现在某些报表、后台同步任务和身份管理接口的返回值里。真正要把这些已删除用户收拾干净、合规安顿好靠的是 SAP 里一个专门的功能Maintain Deleted Business Users。我第一次接触到这个功能是被一个审计问题逼着去查的。当时客户刚做完一轮人员清理权限顾问删了几十个离职账号结果外部审计问这些删除操作有没有记录被删除的用户数据保留多久有没有办法物理删除一查才发现SAP 根本没把用户真正物理删掉而是软删除。后来在 Fiori Launchpad 里找到 Maintain Deleted Business Users 这个 App又结合 SU01、SUIM、AL08 把这些已删除用户从标记到清理走了一遍才算是把这块彻底打通。这篇文章我就按自己的实际经验把已删除业务用户从原理到实操再到踩坑排错完整写一遍。适合 SAP Basis、权限顾问、IAM 项目上负责用户生命周期的朋友参考也适合刚接手用户管理、想把离职账号这件事做规范的新手。1. 为什么删除用户不等于删干净先搞懂业务用户的生命周期1.1 你删掉的只是一个标记SAP 用户主数据的真实存在形式很多非 SAP 背景的同事会有一个习惯性认知删除用户就是把这个人的所有账号信息从系统里彻底抹掉像回收站清空一样。SAP 不是这个逻辑。SAP 里执行用户删除操作时系统做的是标记删除——把用户主记录标记为已删除状态但这个主记录本身仍然存在于底表中USR02、USR03、USR21 这些表里的数据都不会真的消失。这么做并不是 SAP 设计偷懒而是有实际考量。用户主数据关联的不仅仅是登录名和密码还关联权限角色分配、业务伙伴信息、工作流任务、采购单或审批单的创建人字段。如果真把物理记录删了老的单据会因为找不到对应的用户主数据而出现各种异常——比如审批历史里的创建人显示不出来、ALV 报表里责任人一栏变空白、工作日志里用户号悬空。为了不影响历史业务数据完整性SAP 选择了软删除这个折中方案用户从可见的用户列表里消失但底表数据保留历史记录还能关联上。这就像你把通讯录里的联系人归档了而不是把手机里的联系人文件删掉。归档之后日常列表里看不到他但搜索旧聊天记录时那个头像和名字依然能对得上。理解了这个底层机制你才能理解后面所有问题——为什么已删除用户还占用户数为什么同名用户创建不了为什么审计报告里还能看到这个人根源都在软删除。1.2 审计与合规为什么已删除用户反而要专门管理如果说软删除是 SAP 为了业务连续性所做的妥协那已删除用户管理就是应对审计和合规要求的补丁。这里有个核心矛盾一方面系统需要保留历史关联另一方面外部审计和数据保护法规又要求企业不能无限期保留个人信息——尤其是离职员工的账号数据。我经历过的几个项目里外部审计对用户删除这块的检查点非常固定是否有用户删除的审批记录删除后的数据保留了多久是否还有未清理的僵尸用户残留是否定期执行过物理清理如果这些问题的答案都是没有那审计发现项基本就跑不掉了。特别是现在个人信息保护相关的法规越来越严GDPR 这类数据保护条例很多企业都明确规定个人数据保留期限到期必须彻底清除。SAP 的 Maintain Deleted Business Users 就是专门为满足这类需求设计的让你能看到所有处于删除状态的业务用户并按权限和保留策略做最终清理。这里要特别提醒一句审计看的不只是有没有删更看重删得有依据、留得有痕迹。哪怕你批量删了 100 个账号如果没留存一份删除前的权限快照、没记录删除审批单号、没按保留期规划清理节奏审计照样可以给你开一项。所以我后面会一直强调删除前导出、删除后留档这个习惯。1.3 这项功能到底能解决什么核心问题清单把 Maintain Deleted Business Users 的价值拆开看它主要解决四个问题。第一可视化系统里到底有多少已删除用户都在什么状态第二可检索按条件筛选出特定范围的已删除用户比如某个部门上个月删除的所有账号。第三可追溯查看这些用户的删除时间和删除方式为审计提供证据。第四可清理对超过保留期的用户执行真正的物理删除让数据生命周期完整闭环。实操过程中这四个能力缺一不可。你只清不查就少了一份审计依据你只查不清保留数据无限增长合规上迟早暴雷你查了清了但没留底等于白干。这也是我在做 IAM 项目时反复跟客户强调的Maintain Deleted Business Users 不是删除按钮的另一个入口它是用户生命周期管理的最后一环承担着生态收尾的作用。2. 删除用户之前的检查事项准备工作比下删除命令更重要2.1 先盘点清楚状态用 SU01 和 SUIM 摸清底细真正动手删除用户之前我建议你先花几分钟做一次状态盘点。不是打开列表直接删而是先明确三个问题这个用户现在处于什么状态他名下还挂了多少权限这些权限有没有被其他用户复用这三个问题清楚了后面不管是用 SU01 删除还是再到 Maintain Deleted Business Users 里清理都会顺很多。第一个问题看用户状态。最直接的就是事务码 SU01在用户维护界面可以看到当前用户是否存在锁定标记、是否被标记删除。不过 SU01 一次只能看一个用户要批量盘点建议用 SUIM用户信息系统它相当于用户和授权的报表中心可以在里面按用户、角色、授权对象、参数文件等维度组合查询。第二个问题看角色分配。在 SUIM 里跑一个用户分配的角色报表把用户名输进去就能看到这位用户挂了哪些角色包括直接分配的和通过复合角色间接拿到的权限。这一步尤其重要。很多权限顾问删用户时只删了用户本身结果这个用户对应的 PFCG 角色分配记录还挂在那边过段时间一看用户没了但权限残留。有残留意味着什么意味着如果后面有人重新创建同名用户可能会继承一组你想不到的旧权限这是非常大的安全漏洞。第三个问题看会话与后台任务。这个放到 2.2 单独说因为它最容易被忽略也最容易在删除时给你迎面一击。2.2 活跃会话和后台任务那些删不掉的用户我删过最棘手的一个用户是财务部一个离职的主管。当时种种检查都过了角色没复用、流程单也批了、数据也导出来了。结果 SU01 里点删除系统直接弹错说用户当前有会话存在。我一开始还以为是偶发情况后来才意识到那位主管的账号被配置在一个周期性的后台作业里每天定时跑相当于每天都自动登录一次所以删除操作一直被阻塞。所以我的建议是删除用户前一定先看活跃会话和后台作业。会话层面用 AL08也可以用 SM04查看当前登录系统的用户列表确认目标用户有没有在线会话。如果显示在线需要先与用户或管理员确认是否可以强制注销或者用 SM04 里的终止会话来清理。后台作业层面用 SM37 查一下作业列表看目标用户是否作为提交用户挂在某个周期作业里。如果有需要先处理作业通常是把作业移交到另一个服务账号或者直接停用相关作业。还有一种情况比较隐蔽就是工作流任务。如果该用户还有未处理的工作流项、审批任务挂在名下删除时也容易遇到依赖冲突。SAP 的工作流运行时SWU3 相关配置会引用用户 ID如果用户已删而任务存在轻则任务无法正常显示重则工作流运行时直接报错。稳妥的做法是删除前把该用户的待办工作流转发给接替者或者通过任务管理功能将其待处理项转向。这一步在离职交接流程中应当与业务部门协同完成权限团队不要自己拍脑袋处理。2.3 删除前的权限快照与审计留档别删得不明不白如果前面两步是安全层面和执行层面的检查那这一步就是审计层面的检查。我的习惯是在每个用户删除前做一次完整的权限导出存档。导出内容至少包括用户名、全名、部门、直接和间接角色、关键授权对象尤其是 S_TCODE、S_ADMI、S_USER_PRO 这类高风险权限、用户类型Dialog/Service/System、最近登录日期、创建日期。导出路径一般用 SUIM 相关报表也可以直接从 PFCG 的角色用户列表里拉更彻底点可以用 SE16 查 USR02、USR21、USR05 等关键表的数据导出后存档。这些导出文件在审计访谈时直接拿出来就能回答你怎么证明删除前这个用户只有这些权限这个问题。还有一个细节容易被忽略用户删除后尤其是软删除状态下的用户其名字会继续出现在很多历史记录里。如果你在删除前没有留存用户名 ↔ 员工信息的对应关系几个月后再回去查时哪怕看到用户名也不一定能对上真人。所以删除前最好连 HR 系统里的人员编号、部门、离职日期一起归档到一个统一记录表里权当是给系统留下一本用户墓志铭。我记得有次客户做年度权限复审需要确认某个已删除用户的售后审批历史就是因为当时没留映射关系折腾了快两天才对上人这个教训到现在我都记得。3. Maintain Deleted Business Users 实操从界面进入到批量清理3.1 两条进入路径Fiori App 与经典 GUI 的处理差异Maintain Deleted Business Users 这个功能在标准交付里是以 Fiori App 的形式提供的一般在 Fiori Launchpad 上搜索对应名称就能找到入口。它面向的典型使用场景是安全管理员或用户管理员需要集中查看所有软删除状态的业务用户并决定哪些可以清、哪些要继续归档。如果你所在的企业还在用经典 GUISAP GUI不要慌这个功能背后的用户主数据逻辑和事务码 SU01 是打通的。你可以进入 SU01在初始界面的用户字段里输入用户名或者直接在菜单里切换已删除用户视图查看用户当前的标记删除状态。事实上这两个入口查看的数据源是同一条链路USR02 表里的删除标记状态。差异主要体现在操作效率上——Fiori App 擅长拿条件筛选、批量处理和导出而 SU01 更适合单用户的查看和微调。需要提醒一点很多项目上线时 Fiori 并没有全量激活尤其是一些传统 ECC 客户可能还在用 NetWeaver Business Client 或者纯 GUI。这时候如果找不到 Maintain Deleted Business Users 这个 App不要硬等 IT 给你开 Fiori直接回归最底层的处理逻辑通过 SU01 标记删除用户再通过底层表数据和报表来管理这些已删除用户。工具缺了可以补但流程得跑起来别把没有 App当借口让清理工作停摆。3.2 界面里的核心维度和批量筛选实操要点拆解进入 Fiori App 后首页呈现的通常是已删除用户的列表界面。这个界面看起来简单但操作上有几个关键按钮和字段需要理解透彻否则容易误操作。首先是筛选区。你一般可以按用户名、姓名、部门、删除日期范围等维度组合检索。这里我强烈建议你每次操作都习惯性地把删除日期范围选上哪怕只是做临时查看。因为已删除用户列表默认是按某种固定排序展示的不设置日期范围你面对的就是一个所有历史删除用户的堆积列表。一旦企业跑了两三年这个列表可能有上万条记录直接加载会非常卡也容易看漏。用日期范围先把本次要处理的批次圈出来是高效操作的第一步。其次是导出功能。这个 App 支持把筛选结果导出为本地文件常见格式包括电子表格和文本文件这个导出不是给领导看报告的而是给你做审计留档用的。我建议每个批次清理前都导出一次清理前清单清理后如有需要再导一次清理后清单两份对上整个数据生命周期就闭环了。再往细节走列表里每一行用户一般会显示用户的删除状态、用户名、创建日期、删除日期等字段。重点要看的是创建日期和删除日期这两个时间点的差值——它是判断这个人是否属于长期野生账号的关键线索。创建时间久、删除时间晚、又在删除后长期未清理的用户往往对应着离职流程拖沓或者权限管理员漏处理的情况。这类用户在审计时最容易成为发现项所以清理优先级要拉高。3.3 最终清理的正确姿势保留期、确认机制与批量执行前面说的都是查看和导出真正让这个功能发挥安全管理价值的是最终清理物理删除这一步。在 Maintain Deleted Business Users 中执行最终清理和 SU01 里的删除用户不是一回事。前者是删除那些已经处于删除状态且确认无再使用需求的记录让它们从审计性保留的软删除状态变成真正的物理清除后者则是把正常用户标记为删除。在执行最终清理前你的脑子里要有一个保留期的概念。什么叫保留期就是用户被标记删除后你至少要保留它多久才能满足审计和业务追溯需求。这个周期没有统一的法定数字通常由企业自己的信息安全策略和数据保护要求决定常见的是 1-3 年。我参与的项目里有的客户定的是 2 年有的定的是 1 年加一个财季的缓冲但无一例外都在数据保护和个人信息治理的框架范围内做权衡。实操上你可以在 App 里通过筛选条件圈定一批已超过保留期的用户然后执行最终删除操作。执行前系统通常会有确认弹窗或表单要求再次确认有的版本还会要求填写删除原因备注。这一步的确认机制不是形式主义就是逼着你停下来想一想这批用户删下去是否会影响正在进行的审计是否有接替者还在依赖同名用户做历史查询我的建议是每次批量清理前都做一次二次检查至少让另一位同事复核一下筛选条件别自己一人拍板。3.4 把例行清理做成可重复流程不打无准备的仗一次性清理是急救能跑起来的例行清理才是真正的合规。这里给你一个可以直接抄作业的流程参考。第一步每月固定时间导出全部已删除用户清单。第二步按保留期规则筛选出到期用户优先处理删除时间超过保留期上限的。第三步对照上月的审计留档确认这些用户没有被任何进行中的流程引用。第四步在 Maintain Deleted Business Users 中执行最终清理并导出清理后清单。第五步把两份清单和操作日志一起归档到权限管理共享目录。这里面还有一个小技巧就是给这个任务设置一个后台作业或日历提醒。因为人总是会忘尤其在一个月有几十个用户变更的忙碌月份里例行清理很容易被排到后面。你可以用 SM36 定义一个周期性的后台作业只做数据导出和记录汇总不直接执行删除——删除还是让人来点但先拉数据这件事可以由系统自动完成。人负责判断机器负责提醒和准备这个配合用下来最稳。4. 常见问题与排查实录实战中踩过的坑4.1 用户删了之后还能不能重新创建同名冲突怎么办这是一个几乎每个项目都会遇到的问题。场景一般是某个员工离职后账号被删过了一两年另一位同名同姓或者同拼音的员工入职HR 系统里再生成一个一样的用户号结果权限管理员在 SU01 创建时系统报错用户已存在但你在正常用户列表里又找不到这个用户。原因其实就是软删除机制用户记录还在底表里只是被标记删除了。若用户号唯一性校验是照常执行的系统当然不允许你新建一个同号用户。碰到这种情况有两条处理路线。第一条如果原用户数据已经过了保留期可以走最终清理路径把这个软删除记录物理清掉再重新创建同名用户——这个操作在 Maintain Deleted Business Users 里很好用专门处理这种旧碍事数据。第二条如果原用户还没到保留期或者历史数据还需要保留关联那就不能急着清最好换一个用户号创建新用户避免旧数据被切断关联。这里我踩过一个坑当时图省事直接把旧用户从底部表里强行删了结果这个错删导致旧年度报表里审批记录的用户显示全乱。后来我学乖了凡是遇到同名重建第一反应永远是查保留期第二反应是查历史业务关联两个都确认无碍才敢清理。这不是技术难度的问题是想事周全与否的问题。4.2 已删除用户还占许可证报表里怎么还在另一个高频问题用户明明已经删除了为什么 LICENSE 相关的报表里还统计着这个用户为什么组织架构或用户清单报表里还能看到它答案还是绕不开软删除。许可证License统计的基础数据来自用户主记录表只要记录还在就很可能被计数。这时候的处理逻辑要看你的诉求如果是为了让许可证报表好看一点重点其实不在这一个已删除用户而在于整个用户基础里有多少这种僵尸记录——把它们全部清理掉许可证水位自然就下来了。这种情况更要依赖 Maintain Deleted Business Users 的筛选和导出功能先把列表拉全再逐一核对用途能清则清。如果是在某些自定义报表里还能看到已删除用户那就需要检查报表的取数逻辑了。很多开发在写查询时只设置了用户名 输入值没有额外过滤删除标记USR02 中删除标志相关的字段状态所以已删除用户还是会被捞出来。这不是功能本身的问题是你需要在报表里补过滤条件的问题。权限团队最好和开发沟通在报表层统一把删除标记作为标准过滤项从源头堵住数据看着不对的困扰。4.3 清理报错、数据不同步排查思路分享执行最终清理时遇到报错是最容易让人心慌的环节。常见报错之一是用户仍被引用系统拒绝物理删除。这种报错通常出现在用户与某些业务主数据、业务伙伴编号有关联的场景里。排查时先别急着怀疑功能坏了反而要感谢这个报错——它意味着系统在保护业务完整性。你需要做的是找到引用源解除关联后再尝试清理。引用源可能是业务伙伴关系、用户参数文件、工作流启动器甚至可能是自定义表里存了这个用户 ID。另一种情况是数据不同步。比如在 Maintain Deleted Business Users 里看到一个用户已经被清理了但在某些报表查询里还能查到它的用户名但点进 SU01 又提示不存在。这种残留索引类问题多与同步延迟或存储读取相关处理方法通常是做一次全量数据比对。如果经常出现就要检查后台是否有什么接口或程序在定期把删除用户重新同步回主表。我见过一次很有意思的“复现”案例已清理用户隔了两周又出现在已删除列表里查了一圈才发现是 HR 同步接口在定期把旧人员数据重新推送成业务用户等于自动复活了已删除账号。后来在接口配置里加了删除状态回写逻辑才算根治。4.4 常见问题速查表场景现象排查路径常用处理删除用户后列表仍可见用户状态为已删除未物理清理查 USR02 删除标志确认保留期Maintain Deleted Business Users 中执行最终清理创建同名用户报已存在底表记录未真正删除查原用户删除时间、历史关联过保留期则清理重建否则换新用户号删除时提示会话存在用户仍有在线会话或后台作业AL08/SM04 查会话SM37 查作业终止会话或移交作业后重试清理时提示用户被引用有其他表或主数据引用用户查看报错引用详情解除引用必要时基于业务判断保留用户许可证统计偏高大量已删除用户仍在计数导出全部已删除用户按保留期分批物理清理报表仍能看到已删用户报表未过滤删除标志检查报表取数逻辑增加删除状态过滤条件提示只要是清理操作一定要先在生产环境之外做一次预演至少在测试系统上跑一遍同样的筛选和清理逻辑确认不误伤再上生产。5. 把用户删除管理做成制度的落地心得Maintain Deleted Business Users 说到底是一个工具真正决定安全效果的还是背后那一套操作制度。我参与过几个 IAM 相关项目后最大的体会是用户删除这件事必须和离职流程、HR 系统、审计节奏深度绑定不能由权限管理员一个人凭感觉发挥。要将用户删除管理做成例行制度有几个维度一定不能省略。第一定义清晰的保留期。建议在信息安全制度里就写明软删除用户保留多久最终清理要遵循什么频率由谁审批所有已删除用户的操作记录统一归档。这部分内容看起来是文档工作但审计时最有说服力的恰恰是这份文档。第二把权限快照作为删除动作的前置条件。只要标准流程里把导出权限快照和提交删除申请绑定后面就不会出现删了又不知道删了什么。从技术上可以在 SUIM 里跑完导出再把导出文件附到变更工单上。整个过程不复杂复杂的是让大家都习惯这么干。第三定期核对用户生命周期中的异常信号。比如删除日期和最后登录日期之间间隔很短说明用户在删除前还在活跃用系统创建多年但一直没登录过的用户往往是重复账号删除时间超过保留期但又没清理的记录就是流程断点。这些信号靠人盯不现实建议每季度从系统里拉一次异常报告逐条核销。第四测试环境和生产环境保持一致的操作策略。我见过不少团队在生产环境清理得很勤快测试环境里却堆积了几年的已删除用户结果在做数据迁移或系统刷新时这些垃圾数据跟着进生产造成重复用户和权限冲突。所以在测试环境里同样要跑 Maintain Deleted Business Users 的例行清理别让测试系统沦为数据垃圾场。第五不要忽视操作日志的留存。不管是 SU01 的删除还是 Fiori App 里的最终清理操作记录都是审计的硬通货。很多企业用的是绑定审计日志的方式我建议在关键用户变更操作上再额外留一份独立记录包含操作人、操作时间、目标用户、操作类型和备注。这份记录在企业内部权限复审、外部审计访谈、甚至安全事件溯源时都能派上大用场。最后再说一个实际体会。很多人一上来就问Maintain Deleted Business Users 这个事务码是什么其实它更多是基于 Fiori 的功能 App理念上代表的是用户删除后的治理视角。你不需要把这个功能神话但也不能只把它当成一个清理按钮。它真正的价值在于逼着你去面对那些被你删了但还阴魂不散的业务用户逼着你去回答审计提出的你到底把数据怎么样了这个问题。把这块流程理顺了你的用户管理才算真正闭环。
