在SAP IAM这个行当里泡了八年，对接过的SAP业务用户生命周期项目不下二十个，我最怵的不是项目上线日的通宵，而是半年一次的审计季。审计员翻着离职名单，抬头问我：“这些离职的员工，他们的SAP账号处理到哪一步了？”这时候最怕听到的回答就是——“账号锁了”。锁了不等于删了，锁了的账号还挂在业务角色上、还持有补充访问权限、还在审批流程里占着节点。它像一颗没响的雷，平时看不出问题，一到权限分析就炸。
后来在SAP Identity Management的运维环境里，我陆续接触到Maintain Deleted Business Users这套维护逻辑，才慢慢把“已删除业务用户”这个环节从被动处理变成主动治理。这篇文章不是官方文档的翻译，是多个项目里踩出来的经验总结：它解决什么问题、实际操作里怎么用、哪些坑绝对不能踩，我一次性讲透。无论你用的是SAP Cloud Identity Services、本地部署的SAP IdM，还是S/4HANA自带的IAM模型，这篇都值得存下来对照。
1. 为什么“已删除业务用户”是生命周期管理里最刺手的一环
1.1 删除不等于消失：用户状态的三个真实层级
很多刚接触IAM的同事会把“删除用户”理解成一个动作：在系统里把人去掉，完事。但真实的企业系统里，用户状态从来不是非黑即白，我一般把删除拆成三个层级来看。
第一层是硬删除，也就是记录从系统里物理移除。这个动作最干净，但风险也最高。一旦删除，用户主数据、角色关联、审批历史、工作流待办关联全没了，想恢复只能靠备份，过程极其痛苦。所以成熟团队不会一上来就硬删。
第二层是逻辑锁定，就是用SU01把用户锁掉，或者打上删除标记。这是ECC时代最常见的做法，因为它“看起来无害”。但问题在于，锁定的用户仍然存在于系统中，角色还在，授权还在，它在权限报表里就是一条活生生的记录。审计员不关心你锁没锁，他只知道账号存在。
第三层是软删除，这是现代身份管理场景里的主流做法：身份在身份目录里被标记为“已删除”，但数据带保留期继续存放，系统可以在保留期内随时找回，也可以配置任务在保留期满后彻底清理。Maintain Deleted Business Users处理的就是这一层。
理解这个分层之后，再回头看常见的运营事故就很清楚了。很多项目的问题不是“不知道要删”，而是把三层删除混为一谈：在源系统里做了软删除，却以为目标系统里的账号已经没了；或者直接去S/4HANA里硬删，结果把人家的流程审批单、历史业务数据关联全搞断了。
1.2 审计视角下的“删除证据链”缺失
我参加过不少内外部审计，审计员对用户删除这件事的考察逻辑其实非常固定，就五条：谁提的删除申请、谁审批的、删除前做了哪些权限回收、删除发生在什么时间、怎么证明这个人确实已经无法登录系统。
这五条串起来，就是“删除证据链”。传统做法里，哪一环最容易断？很遗憾，每一环都可能断。离职单走的是HR流程，权限回收单走的是IT流程，账号锁定又可能是管理员自己操作，三个系统里的时间戳对不上，审计员一抓一个准。
更麻烦的是“删除前做了哪些权限回收”这一环。很多团队是先删账号再想起来回收角色，结果角色配置里的分配记录已经随着用户一起没了，你只能拿一张截图证明“曾经有过这个角色”。在严格的外部审计里，这种证据是不够的。
所以我一直建议团队把已删除业务用户纳入统一管理视图。这个视图至少要做到：一条完整的删除记录，能追溯到源系统删除时间、身份目录软删除时间、权限回收执行时间、最终清理时间，每一步都有操作日志。Maintain Deleted Business Users这类功能的价值，首先就是帮你把这条链从零散拼图变成一条时间线。
1.3 被误删的技术账号：业务用户管理的“边界事故”
聊删除，就绕不开“谁是业务用户”这个定义问题。最典型的事故就是清理任务把技术用户当成业务用户删掉了。
在SAP环境里，技术用户包括RFC用户、后台批处理用户、接口用户，甚至还包括一些系统间通信用的服务账号。以我见过的一个项目为例，当时为了清理积压的已删除用户，运维同事写了个批量任务，条件没做用户类型过滤，结果把一个MES/MOM集成场景里用的接口账号也带上了。当天夜里接口作业全部失败，生产线工单同步中断，紧急回滚用了两个小时。
这件事的教训有两个。第一，任何批量删除脚本或者清理任务，必须先把用户类型作为第一过滤器；第二，所谓“业务用户”的边界要在项目初期就白纸黑字定义出来。一个用户算不算业务用户，要看它有没有被身份生命周期管理覆盖，要看它是否对应自然人的登录身份，而不是看它名字里有没有“USER”字样。
Maintain Deleted Business Users本身的目标群体是业务用户，但它不会替你判断哪个该删。你要是把接口账号也纳入了同一套删除流程，出事了只能怪自己没建好过滤规则。
2. Maintain Deleted Business Users 到底管理什么：先看清它的工作边界
2.1 它处在IAM架构的哪一层
很多读者看到“Maintain Deleted Business Users”这个名字，第一反应是：它是不是一个S/4HANA里的新事务代码？答案是否定的。这个名字在不同部署形态下出现过不同的位置，核心逻辑是一致的：它是一个身份目录层的维护功能。
现代SAP IAM的架构通常分三层：源系统（比如SuccessFactors Employee Central、S/4HANA的PA20人员主数据）、身份置备层（Identity Provisioning或者本地SAP IdM）、目标系统（S/4HANA、BTP、Concur这类业务应用）。身份目录就是中间那一层，它是所有身份的集散地。
当一个员工在源系统被终止时，身份置备层会感知到变更，把这个身份在目录里标记为“已删除”。从这一刻起，这个身份就进入了已删除用户的管理范畴。管理员通过Maintain Deleted Business Users可以看到这批人，做审查、恢复、延期、永久清理等操作。它管的是身份目录里的“待删除状态”，而不是直接去删目标系统里的账号。
在SAP Cloud Identity Services里，这个入口一般在管理后台的Users区，里面有专门的“Deleted Users”分类；在本地部署的SAP IdM里，对应的是身份中心里的已删除身份视图和配套清理任务。别看入口名字不同，背后的状态模型基本是同一套。
2.2 软删除、留置期与硬删除：后台的真实处理顺序
再往下拆，这套功能背后的处理顺序是固定的，我建议每个IAM运维人员都把它刻在脑子里。
第一步，源系统标记删除。HR系统在员工离职日触发人员终止，或者管理员在管理后台手动删除某个业务用户，源系统把删除信号释放出来。
第二步，身份置备同步。Identity Provisioning会在下一次同步周期里发现这条删除变更，把身份在目录里的状态改成“已删除”。注意，这个阶段身份并没有真正消失，只是被打上了标记。
第三步，留置期存续。系统按配置好的保留周期（常见的是30天、60天、90天）保留这个身份的完整记录。保留期内，管理员可以审查、恢复、延期，也可以随时执行永久清理。保留期的存在是有道理的：再入职的场景需要找回原身份，审计需要查看历史分配，交接不彻底时业务部门也需要缓冲时间。
第四步，永久清理。保留期满且没有被恢复或延期的身份，会被清理任务从目录中彻底移除，历史分配关系也随之消失。这一步不可逆，操作前必须慎重。
这个顺序里，最被人忽略的是“留置期”。很多运维团队把软删除当成“已经删了”，一看状态是已删除就不管了，结果三个月后清理任务把人家的身份连带所有审计记录一起清掉，再想查历史就什么都查不到了。
2.3 功能边界：它不负责的事
我见过不止一次，客户以为用这个功能就能一步到位把用户从整个SAP生态里抹掉，这是对它的最大误解。它管的是“身份生命周期”，不是“目标系统账号状态”。
它不负责即时回收S/4HANA里的PFCG权限角色。角色回收需要走权限变更流程，去目标系统里做去置备，或者通过IdM的角色分发任务去执行。它也不负责吊销SSO令牌和活动会话，那属于访问管理和会话控制范畴。它更不负责帮你判断一个用户是离职还是转岗，这是业务规则问题。
换句话说，Maintain Deleted Business Users把“该从目录里删掉谁”这件事管理好，但“谁在具体系统里还能访问什么”要依赖周边模块协同。设计流程时，一定要把这几个步骤串成一个闭环：人员终止→身份软删除→权限回收→目标系统去置备→留置期满→目录清理。少了任何一个环节，删除都不算真正完成。
3. 实操全流程：从定位已删除用户到完成清理
3.1 不同环境下的入口：别纠结菜单路径，认准核心视图
每次在项目上教客户使用这套功能，我都会先讲一句：入口路径在不同版本、不同部署方式里会有差异，不要死记菜单，要认准“已删除用户”这个核心视图。
在SAP Cloud Identity Services的管理界面里，进入Users区域后切换到Deleted Users分类，系统会列出所有处于软删除状态的身份。在本地SAP IdM的身份中心里，已经删除的身份会有独立的维护区域，管理员还可以配置周期性的删除清理任务。部分S/4HANA的IAM实施里，业务用户管理相关的内容在Fiori应用里也能看到类似的已删除用户清单。
我自己在各项目里统一的口径是：谁负责查已删除用户，谁就有责任定期在周五下午把这个视图刷一遍，核对留置期，处理到期项。这个习惯比任何工具都重要。
3.2 审查只盯三个问题：她是谁、还能干什么、东西交接了没
拿到已删除用户列表后，不要急着点“永久删除”。我会用三个问题过一遍每一个人，这也是我教给团队成员的标准动作。
第一个问题：她是谁。看用户的身份属性，确认身份类型。是正式员工、外包顾问，还是外部合作伙伴？不同类型对应的审批路径、保留期都不同。同时要核对该用户是否还关联着未完成的工作流。我见过一个极端案例：离职员工的身份已经被标记删除，但他名下还挂着一个待他审批的采购申请，业务部门等了两周没人批，最后检查发现审批流卡在这个已删除的用户身上。
第二个问题：她还能干什么。这一步要到目标系统里查实际状态。我通常用SAP GUI打开SU01看账号锁定状态，通过PFCG查角色分配，再看一下最后登录时间和登录失败记录。如果身份目录里显示已删除，但S/4HANA里的账号还有效，这就是去置备没跟上，得先处理目标系统。
第三个问题：她的东西交接了没。重点看有没有遗留的审批任务、待办任务、传输请求（Transport Request）、别名邮箱转发等资产。有些企业还会做业务单据归属转移，把离职人员名下的单据改到接手人那里。这一步没做完，这个人就算删干净了，业务链路还是断的。
把这三个问题分别口头确认一遍，比直接看系统状态更可靠。系统会告诉你“这个用户被删了”，但不会告诉你“这个用户的审批流还等人处理”。
3.3 批量处理与删除前的数据导出
清理工作不会只有一个用户，往往一次要处理几十上百个。这时要用好用批量功能，但批量操作之前有一件事必须做：导出。
我不建议在界面上挑几个用户然后直接点“永久删除”，尤其是第一次接触这套功能的团队。标准做法是：把待清理的用户列表导出成表格，逐条做审查标记，审查通过后再回到系统里按名单执行批量清理。这样一来，万一之后审计要追溯，你手里还有一份清理前的快照，而不是只靠系统日志。
导出的内容至少包括：用户ID、显示名称、身份类型、删除标记时间、保留期到期时间、源系统中的最后状态、关联的角色和分配记录。以云环境导出的数据为例，一条删除身份记录往往长这样：
{ "id": "498e1f2c-8a3b-4d5e-9f6a-1b2c3d4e5f6a", "userName": "WANG.FANG", "displayName": "Wang Fang", "identityType": "EMPLOYEE", "sourceSystem": "SAP_HR_EC", "deletionState": "SOFT_DELETED", "deletedAt": "2025-06-30T18:00:00Z", "retentionUntil": "2025-08-29T18:00:00Z", "targetAssignments": [ {"system": "S4HANA", "status": "DEPROVISIONED"}, {"system": "BTP_SUB", "status": "PENDING"} ], "processedBy": "IT_IAM_ADMIN" }导出后，用Excel或者你习惯的数据分析工具加一列“处理决策”，填“恢复”“延期”“永久清理”其中之一，再回到系统执行。这样做的好处是，每个已删除用户都有一笔“决策留痕”，在审计面前你拿得出依据，而不只是一句“我删了”。
4. 删错了怎么办：恢复、延期与资产转移的三条退路
4.1 留置期内的恢复：别让再入职的员工变成“新用户”
系统里最容易被误判成“删除”的场景，其实是员工转岗和再入职。同一家公司里，员工从A子公司调到B子公司，或者离职半年后又重新入职，如果身份已经被永久清理，再入职时就只能创建新身份，这就带来了一个大麻烦：身份唯一标识变了，历史分配、审批记录、权限审计数据全部对不上，财务、安全、合规三块都要陪着你善后。
留置期的价值就在这里。很多企业把保留期设为90天，就是因为再入职和转岗的窗口通常在三个月内。恢复一个软删除身份，主数据还在，身份关联还能重新建立，省掉的不只是建账号的十分钟，而是后续一连串数据一致性问题的麻烦。
但要注意，恢复身份不等于恢复权限。我曾经处理过一个案例：员工离职45天后又回来，系统里身份一恢复，她发现自己的SAP角色还是离职前的旧角色，而这段时间公司已经上线了新的职责分离规则。最后还是要靠手动重新按最新角色矩阵配一遍。所以恢复动作要配合权限复审一起做，别指望系统“一键还原成原来那样”。
4.2 延期删除：交接不彻底时的缓冲策略
不是所有已删除用户都能在保留期内完成交接。客户资料还在他手里，报表口径只有他清楚，项目文档没归档干净——这些都是业务部门拖着不让你删的理由。
我不反对延期，但反对无条件的延期。操作上，我会给单个已删除用户单独设置新的保留期到期日，前提是业务负责人要签字确认延期原因和时间。延期功能本质上是个治理工具，不是让你无限期搁置的理由。
这里有一个容易踩的坑：延期操作只对单个身份生效，如果你在列表里选中一大批用户统一点了延期，系统会把所有人的到期日一并后移。如果这批人里有已经交接完毕、随时可以清理的，那你就把本该删除的用户又“养”了一段时间。批量延期这事，业务上慎用。
4.3 永久删除之后：最后一张底牌其实很痛
万一真的永久删错了，有没有补救办法？有，但代价很大。你只能重新创建一个新身份，然后手动把所有目标系统里的账号重新关联起来，再把之前导出的历史数据手工归档。这个做法的问题在于，新身份对身份生命周期管理体系而言就是一个全新对象，下次同步、下次审计、下次权限分析，它都会以“新用户”的身份出现。
我见过一个客户在这个问题上吃了大亏。他们把一名外部顾问的身份永久清理后，才发现该顾问的雇佣合同其实延期了三个月，并且他名下还有一个正在进行中的集成测试账号。最后只能重建身份、重建角色、重建关联，前后折腾了整整一个迭代周期。
所以我在项目里一直强调一个底线动作：点永久删除之前，先确认这不是“状态变更”。员工转外部顾问、子公司之间调动、实习生转正，这些变更如果被误判成人员终止，永久删除下去就是给自己挖坑。
5. 把离职流程自动化：与HR系统和身份置备的联动
5.1 标准链路：从HR终止到身份置备再到目标系统去置备
真正成熟的IAM团队不会用人肉盯着已删除用户列表，而是在前面就把链路打通。理想的自动化流程是这样：HR系统中员工离职事件触发后，Identity Provisioning在同步周期中感知到人员终止，自动把这个身份标记为已删除，同时在目标系统S/4HANA、BTP、其他云服务里执行去置备，把账号停用或删除。
在本地部署的SAP IdM场景里，这个动作通常还会落到一组ABAP对象上，通过BAPI_USER_LOCK、BAPI_USER_DELETE这类接口把变更真正执行到ECC或S/4HANA后台。这也是为什么我一直建议运维团队把身份置备层和ERPM的接口状态纳入同一个监控看板，否则源系统已经“删了”，目标系统却还“活着”，中间这个时间差就是安全窗口。
去置备动作本身也可能失败。失败原因五花八门：目标系统用户正被占用、RFC连接中断、用户被其他流程锁定。这就是Maintain Deleted Business Users存在的意义之一：它把那些去置备失败或者来不及去置备的身份兜住，不让它们变成无人认领的孤儿账号。
5.2 清理作业与回收周期参数配置
留置期多长合适？这个参数没有标准答案，要根据业务和审计要求定。我给客户的默认建议是：内部员工90天，外包顾问30天。这个数不是拍脑袋定的，而是基于两条约束——再入职窗口和审计对数据最小化的要求。
配置在技术实现上不难，通常就是给清理任务设置参数。难的是配套的例外规则。清理任务执行前，至少要排除三种情况：有未完结工作流的用户、有法律保留请求的用户、身份类型是未定义或者是技术用户的记录。否则自动化跑得越欢，事故来得越狠。
我经手的一个项目里，清理作业每周日凌晨三点跑，有段时间不断出现用户“被清理后又被业务投诉”的情况。后来排查发现，规则里漏了一条：用户状态在源系统是“离职”，但在业务系统里还有“未关闭订单”。从那以后，我把所有清理作业都加了一道前置检查，凡是目标系统还有活动业务对象的身份，一律跳过并生成例外报告。
5.3 自动化覆盖不到的角落：外部用户与顾问账号
自动化的最美好想象是“全部不用管”，但现实中总有几个角落覆盖不到。最典型的是外部业务用户。比如供应商门户、客户门户里注册的外部用户，它们没有被HR系统管理，离职信号不会自动产生，你能依赖的只有业务部门通知和维护人员的定期盘点。
顾问账号也类似。外包顾问往往在客户系统和乙方公司系统里各有一份身份，客户侧的身份跟着项目合同走，合同结束不代表HR系统里会有删除事件。这些账号和合同管理流程绑定，得靠项目经理在结项时触发清理流程。
这些覆盖不到的部分，恰恰是安全审计的重点关照对象。我处理过一家企业的年度合规检查，问题清单里一半的异常账号都来自“不受生命周期管理覆盖的外部身份”。后来我们在流程上补了一道季度盘点任务，把外部用户和顾问用户的清单发给对应的业务负责人确认，才算把这道口子堵上。
6. 审计合规视角：怎么用这套流程拿出“铁证”
6.1 审计员最想看的三种记录
审计季来了别慌，如果你把删除流程管理好了，这三类记录随时能拿出来，就已经稳了大半。
第一类是删除申请与审批记录。谁提出删除需求，谁审批通过，审批意见是什么。这套记录在传统做法里往往分散在邮件和工单系统里，在身份管理流程里，它应该跟着身份的生命周期事件归档，随时可查。
第二类是权限回收记录。用户删除前，角色分配是什么时候、由谁回收的。审计员真正关心的不是“删没删”，而是“删之前有没有把钥匙收走”。如果权限回收和身份删除的间隔超过了一个审计周期，你就等着被写进整改项吧。
第三类是无法登录的验证证据。这里包括账号锁定状态、最后成功登录时间、最后失败登录时间。把它和时间线对起来，就能形成一条完整的“此人已无法进入系统”的证据链。我用这套材料应付过不止一次外部审计，最有效的一张表就是“身份删除时间线”，把源系统删除、目录软删除、目标系统锁定、权限回收、目录清理五个时间点拉成一排，审计员看完通常不会再追问。
6.2 权限回收与删除之间的时间差：SoD报告里的隐患
很多人忽略一个问题：身份目录里的用户删了，不代表权限分析报告里就干净了。权限回收是分系统执行的，S/4HANA里的角色去掉了，但Central User Administration（CUA）模板里可能还残留着这个人的补充权限，或者某个测试系统里还有一个克隆账号。
职责分离（SoD）报告扫描的是各目标系统里的权限数据，它在意的不是你身份目录的状态，而是“这个用户ID在这个系统里还有没有权限”。如果去置备不完整，就会出现“身份已删除但SoD报告里冲突仍在”的怪现象。处理这种问题，不能只看身份目录，要以SoD报告为准回溯各系统。
我所在的团队养成了一个习惯：每次批量清理已删除用户之后，下一个周期就跑一轮权限分析，专门核对删除名单里的用户ID是否还在各系统权限报表中出现。这既是验证，也是留证。把两轮对比报告存档，比任何口头解释都有说服力。
6.3 隐私合规与数据留存最小化
再往上一层，是隐私合规视角。业务用户的身份数据、权限数据、登录记录都属于个人信息，企业不能无限期保留。这也是留置期必须被认真对待的原因：它不是业务上随便定的“延后处理窗口”，而是数据留存策略的一部分。
在很多合规框架下，员工离职后，超出法定或业务必要期限的个人数据应当被删除或匿名化。如果你们的管理界面里躺着一堆三年都没处理过的“已删除用户”，审计或监管机构一旦查到，你会多出一项“数据留存超期”的记录。
合规视角下的理想状态是：保留期参数有书面定义，清理作业按期执行，清理记录有日志可查，删除策略和隐私政策一致。做到这四条，你已经能理直气壮地告诉审计员：我们的删除流程是受控的，不是想起来才删一次。
7. 最后，我把这些年自己定下的几条“土规矩”写给你们
文章写到这儿，核心内容已经差不多了。收尾我不讲大道理，只讲几个我用真金白银换来的习惯，你们可以直接抄。
第一，保持期默认内部员工90天、外部人员30天，有特殊需求走例外审批。这套参数我们用了好几年，既覆盖了再入职窗口，又不会让数据留存期长得离谱。
第二，任何批量删除之前必须先做导出。哪怕系统里只有五个用户要清理，也先导出留档。导出文件存到一个单独的安全目录，保留三年。这是成本的保险，也是后悔药。
第三，所有自动化清理作业都加用户类型过滤，只处理明确标记为业务用户（EMPLOYEE、CONSULTANT、GUEST等）的身份。技术用户、接口用户永远不在清理名单里。不要觉得这是小题大做，出一次MES接口账号被删的事故，你就知道这个过滤器有多值钱。
第四，遇到“状态变更”，永远不做永久删除。员工转顾问、子公司间调动、合同延期，这些情况下的身份要恢复或者重建，不要走向清理路径。拿不准的时候，宁可先把用户留着过一夜，第二天业务确认后再处理。
第五，月底固定出一份已删除用户处理报告，发给安全负责人和审计接口人。报告里写清楚当期新增软删除多少、恢复多少、延期多少、永久清理多少、例外跳过多少。这个习惯坚持半年以后，你跟审计之间的关系会明显缓和——因为他知道你有完整的治理节奏。
所谓“安全管理已删除业务用户”，核心不在于你会不会点那几颗按钮，而在于你有没有把删除当作一个流程来治理：有边界、有时间线、有证据链、有兜底方案。把这些想透了，Maintain Deleted Business Users在你手里才真正有了意义。
