入转离账号管理的核心，是把人员状态变化转化为可核对的账号状态结果。做法上以HR人员事件为唯一触发源，入职前生成账号与初始角色，转岗时同步组织与权限归属，离职时按生效时间停用并回收凭证，最后用对账清单核对人员名单与各系统账号是否一致。本文按入职、转岗、离职三类场景拆解字段、动作、交付物与完成标准，并说明HR、IT、业务负责人和审计角色各自承担什么。
要点总览（TL;DR）
- 入转离账号管理以HR人员事件为唯一触发源，入职、转岗、离职分别对应开通、变更、停用三类处理单，最终以账号状态与人员状态一致为完成标准。
- 入职开通前需备齐姓名、工号、部门、岗位、入职日期等字段，按命名规则建号、安全渠道发放初始凭证、按岗位模板授予默认角色，四项核对通过才算完成。
- 转岗坚持先回收原岗位角色、再授予新岗位角色，随后调整组织与群组归属，由新部门负责人确认生效。
- 离职停用时间不晚于离职生效时间，按停用账号、回收凭证、会话失效、工作交接的顺序执行，例外保留须列明范围与期限。
- 用HR人员名单与各系统账号名单定期对账，识别入职未开通、离职未停用、转岗未调整三类异常，按发现—整改—复核—关闭闭环处理。
一条闭环流程：从人员事件到账号状态
入转离账号管理要跑通，先要确定一条主线：人员事件发生，账号系统据此处理，最终账号状态与人员状态保持一致。这条主线包含三个环节，每个环节都有明确的输入和输出。
触发环节。以HR系统或HR台账中的人员事件作为唯一触发源。入职、转岗、离职三类事件分别对应不同的处理单。触发源唯一，是为了避免业务部门口头通知、邮件申请等多头来源造成账号状态与人员状态脱节。触发时至少要带出人员标识、事件类型、生效日期三项信息。
处理环节。三类事件的账号处理顺序不同：
- 入职：先建人员记录，再开通账号，最后授予默认角色。顺序颠倒会出现无主账号或角色挂空。
- 转岗：先确认变更单，再回收原岗位角色，然后授予新岗位角色，最后调整组织归属。回收在前、授予在后，可以避免新旧权限叠加。
- 离职：先确定停用时间点，再停用账号，然后回收凭证与令牌，最后处理工作交接。停用与交接可以并行，但停用时间不得晚于离职生效时间。
结果环节。账号状态要与人员状态一致：在职人员有可用账号且角色与岗位匹配；离职人员账号处于停用状态且凭证失效；转岗人员账号归属已切换到新组织。一致性不是一次性达成的，需要定期对账来验证，这部分在最后一节展开。
审批与留痕位置。审批放在事件确认环节，而不是放在账号执行环节。入职由HR提交人员事件并经用人部门确认岗位；转岗由HR提交变更单并经原、新部门负责人确认；离职由HR提交离职单并经直属上级确认交接安排。账号开通、停用等执行动作本身以工单或任务形式留痕，记录执行人、执行时间和结果，便于后续追溯。审批解决“该不该变”，留痕解决“变了没有”。
入职账号：开通前要准备哪些字段和动作
入职账号开通的质量，取决于开通前拿到的字段是否完整。字段不全就开通，后续往往要反复补录，还会出现账号命名混乱、角色授错的情况。
必备字段清单
| 字段 | 用途 | 缺失时的处理 |
|---|---|---|
| 姓名 | 账号显示名、通讯录 | 阻断开通 |
| 工号 | 账号唯一标识、命名依据 | 阻断开通 |
| 部门 | 组织归属、群组加入 | 阻断开通 |
| 岗位 | 匹配默认角色模板 | 阻断开通 |
| 入职日期 | 确定账号生效时间 | 阻断开通 |
| 直属上级 | 审批链、交接责任人 | 可先开通，限期内补录 |
动作步骤
- 接收人员事件。HR在入职前若干工作日提交人员事件，输入为上述字段，输出为待开通账号清单。
- 生成账号名。按企业命名规则生成，常见规则为“工号”或“姓名拼音加序号”。命名规则要事先定好并写入制度，避免同一人出现多个账号名。
- 创建账号并设置初始凭证。初始凭证通过安全渠道单独发送给本人或直属上级，不放在群聊、邮件正文等公开位置。首次登录强制修改密码。
- 授予默认角色。按岗位模板授予，例如研发岗默认加入研发项目组、获得代码库只读权限；行政岗默认获得办公系统基础权限。岗位模板由业务负责人确认后维护。
- 加入组织与群组。按部门字段加入对应组织节点和必要的工作群组。
完成判定标准
入职开通完成的标志是：账号可正常登录；默认角色与岗位模板一致；组织归属正确；初始凭证已由本人签收并完成首次修改。四项都满足才算完成，任何一项缺失都记为“入职未开通”异常，进入对账清单跟踪。
转岗变更：组织与账号归属怎么同步
转岗是三类事件中最容易被漏掉的一类，因为人员仍在职，账号仍可用，问题往往在权限叠加或归属错乱之后才暴露。处理转岗的关键是把变更单作为唯一依据，并坚持先回收后授予。
变更单的输入信息
转岗变更单至少包含：人员标识、原部门与原岗位、新部门与新岗位、生效日期、原岗位角色清单、新岗位角色清单、原、新部门负责人确认记录。原岗位角色清单可以由账号管理员根据当前账号实际权限导出后附在变更单上，避免凭记忆回收。
处理顺序
- 确认变更单。核对生效日期与审批记录，输出为已批准的变更任务。
- 回收原岗位角色。按变更单附带的原角色清单逐项移除，输出为回收记录。回收完成前不授予新角色。
- 授予新岗位角色。按新岗位模板授予，输出为授予记录。若新岗位需要临时保留部分原权限，要在变更单中单独列明并设定到期时间。
- 调整组织与群组归属。将账号从原部门节点移入新部门节点，退出不再相关的项目组和群组，加入新岗位对应的项目组。
- 确认生效。由新部门负责人确认账号权限满足岗位需要，账号管理员记录生效时间。
跨部门转岗的项目与群组处理
跨部门转岗时，原部门项目中的历史工作项和文档不随人迁移，但访问权限要随组织归属调整。处理原则是：本人名下未完成的工作项由原部门负责人在变更生效前完成交接或转派；已归档文档保留在原项目空间，按项目权限规则决定是否保留本人访问；工作群组按新岗位重新加入，原群组退出。这一环节容易与文档权限管理交叉，本文只说明归属调整动作，细粒度访问策略不在讨论范围。
离职停用：时间点、回收范围与交接
离职账号处理的核心是时间点。停用时间晚于离职生效时间，账号就处于“人已离开、权限仍在”的状态，这是账号管理中最需要避免的情况。
时间点对应关系
停用时间应与离职生效时间对齐：一般设置在离职生效当日或之前，具体时点由企业制度确定。若离职人员需要办理交接，可在停用账号的同时为其开通受限的交接通道，而不是保留完整账号。停用时间一旦确定，写入离职单并作为执行依据。
处理顺序与回收范围
- 停用账号。将账号状态置为停用，禁止登录。输出为停用记录，含执行人和执行时间。
- 回收凭证。包括密码、访问令牌、API密钥、门禁卡、硬件令牌等。凭证清单应在入职时登记，离职时逐项核销。
- 使会话失效。停用账号后，已登录的会话要强制失效，避免已登录终端继续操作。
- 处理工作交接。离职人员名下的工作项、文档、审批中的流程，由直属上级在停用前完成转派或归档。转派记录作为交接凭证留存。
停用后的复核与例外
停用执行后，账号管理员在约定时间内复核：账号确已无法登录、凭证已核销、会话已失效、工作项已完成转派。若因交接需要临时保留部分访问，要在离职单中列明范围、期限和审批人，到期后再次复核关闭。例外处理必须有记录，不能以口头约定长期保留账号。
角色与交付物：谁在哪个环节交付什么
流程能否稳定运行，取决于每个环节是否有人对交付物负责。下表按常见分工列出，企业规模较小时可以合并角色，但交付物不能省略。
| 角色 | 负责环节 | 交付物 | 完成标志 |
|---|---|---|---|
| HR | 人员事件发起与主数据维护 | 入职人员事件、转岗变更单、离职单，字段完整 | 事件单据审批通过并进入账号处理队列 |
| IT或账号管理员 | 账号开通、变更、停用执行 | 开通记录、角色回收与授予记录、停用记录、凭证核销记录 | 执行记录完整，账号状态与事件一致 |
| 业务负责人 | 岗位角色确认与工作交接 | 岗位模板确认、转岗角色清单确认、离职工作项转派记录 | 确认签字或系统确认记录留存 |
| 审计或安全角色 | 定期对账与异常跟踪 | 对账报告、异常清单、整改闭环记录 | 异常项全部关闭或有明确处理结论 |
在人员事件与账号状态衔接、离职工作项转派的环节，ONES可以作为承载平台：成员加入组织后，其名下的工作项、文档和审批流程可以在同一处完成转派与归档，账号停用与工作交接的记录也能对应到具体人员和任务上，便于后续对账时追溯。具体配置方式需结合企业实际的身份源与系统环境确定。
一个完整示例：某研发人员入职到离职的账号轨迹
以下为演示情景，用于说明三类事件在同一人员身上的处理过程，企业可按自身系统替换具体名称。
| 节点 | 事件 | 账号动作 | 记录与核对结果 |
|---|---|---|---|
| 入职前3个工作日 | HR提交入职事件，岗位为后端开发，部门为平台研发部 | 生成账号名，创建账号，授予研发岗默认角色，加入平台研发部组织节点 | 开通记录完整，字段无缺失，核对通过 |
| 入职当天 | 本人签收初始凭证并首次登录 | 强制修改密码，账号状态置为正常 | 登录记录存在，完成标志达成 |
| 入职第8个月 | 转岗至数据平台部，岗位为数据开发 | 回收后端开发角色，授予数据开发角色，组织归属切换，退出原项目组、加入新项目组 | 变更单附原角色清单，回收与授予记录齐全，新部门负责人确认 |
| 转岗后第1个月对账 | 定期对账 | 核对账号归属与岗位模板 | 归属正确，无权限叠加，核对通过 |
| 离职生效前5个工作日 | HR提交离职单，生效日期确定 | 直属上级完成名下工作项转派与文档归档 | 转派记录留存，交接完成 |
| 离职生效当日 | 停用执行 | 账号停用，凭证核销，会话失效 | 停用记录含执行时间，复核确认无法登录 |
| 离职后首次对账 | 人员名单与账号名单比对 | 确认该人员账号处于停用状态 | 无“离职未停用”异常，闭环 |
这个示例说明，每个节点都要留下可核对的记录。记录的价值在于对账时能快速判断账号状态是否与人员状态一致，而不是事后回忆当时做了什么。
完成检查：用对账清单验证流程是否跑通
流程设计得再完整，也需要用对账来验证。对账的基本方法是以HR人员名单为基准，逐人比对各系统账号状态，找出三类异常。
对账方法与异常识别
- 导出人员名单。从HR系统导出在职人员名单和近期离职人员名单，含工号、部门、状态、生效日期。
- 导出账号名单。从各目标系统导出账号清单，含账号名、状态、所属组织、角色。
- 逐人比对。按工号匹配，识别三类异常：在职人员无账号或账号停用，记为“入职未开通”；离职人员账号仍为正常状态，记为“离职未停用”；转岗人员账号组织归属或角色与当前岗位不符，记为“转岗未调整”。
- 登记异常清单。每条异常记录人员、系统、异常类型、发现时间、责任人。
检查频率与责任人
检查频率由企业根据人员流动规模确定，常见做法是每月一次全量对账，人员流动频繁时对入职和离职事件做每周增量核对。责任人建议由审计或安全角色牵头，账号管理员提供账号数据，HR提供人员数据，业务负责人确认转岗角色是否合理。
阻断项与整改闭环
以下情况应作为阻断项处理，在整改完成前不关闭对账周期：离职人员账号仍可登录；离职人员凭证未核销；在职人员长期无账号影响工作。其他异常可按优先级排期整改。每条异常要有整改责任人和完成时间，整改后重新核对并记录关闭结果，形成“发现—整改—复核—关闭”的闭环。对账报告留存备查，作为账号管理有效性的证据。
常见问题
公司规模较小，HR、IT、业务负责人由同一人兼任，流程还能跑通吗？
可以跑通，前提是保留每个环节的交付物，即使执行人是同一人。具体做法是把入职人员事件、转岗变更单、离职单作为触发凭证，把开通记录、角色回收与授予记录、停用记录作为执行凭证，两类记录分开留存。角色合并后，审批与执行由同一人完成时，建议在单据上注明自查确认，并保留审计或安全角色的定期对账作为独立校验。这样流程的控制点仍在，只是承担者减少。
员工离职后仍有未完成的项目工作，账号能不能先不停用？
不建议保留完整账号。更稳妥的做法是按离职生效时间停用账号，同时为交接开通受限通道，例如由直属上级代为处理，或临时授予仅限特定工作项的访问并设定到期时间。临时访问要在离职单中列明范围、期限和审批人，到期后复核关闭。保留完整账号会让账号状态与人员状态脱节，也会增加凭证泄露风险，对账时会被记为“离职未停用”异常。
转岗时新岗位需要沿用部分原岗位权限，怎么处理才不混乱？
在转岗变更单中单独列明需要保留的原权限项，并设定到期时间，其余原岗位角色按清单逐项回收后再授予新岗位角色。保留项到期后由账号管理员复核关闭，复核结果记入变更记录。这样既满足过渡期工作需要，也避免新旧权限长期叠加，后续对账时能清楚判断哪些权限属于临时保留。
对账发现异常后，多久必须整改完成？
整改时限由企业按异常类型确定。离职人员账号仍可登录、离职凭证未核销这类涉及安全的风险项，应作为阻断项立即处理，整改完成前不关闭对账周期；在职人员长期无账号影响工作、转岗角色与岗位不符等异常，可按优先级排期整改。每条异常登记责任人和完成时间，整改后重新核对并记录关闭结果，形成发现—整改—复核—关闭的闭环。
账号开通和停用能否做到自动触发，减少人工操作？
是否自动化取决于企业身份源与目标系统之间的集成方式，常见做法是通过标准协议或接口把HR人员事件同步到账号系统。实施前需要确认身份源支持的事件类型、目标系统的接入方式以及异常回退机制。自动化程度提高后，人工环节的重点转向字段完整性校验、岗位模板维护和对账复核。具体集成方案需结合企业实际系统环境评估。
