入转调离任务自动化
HR外包服务中以「用工任务」为核心实体，通过状态机驱动、子任务联动和权限矩阵三大支柱，实现从入职到离职全链路任务拆解、下达、审核和撤销的系统化管控方案。核心理念是将”人盯人”的服务交付模式升级为”系统驱动、流程管控”模式。
简介
入转调离任务自动化是HR人力资源外包服务中处理人员入职、转正、调岗、离职全流程的系统化方案。在HR外包业务中，每发起一个人员任务都会联动到合同签署、社保增减员、工资发放、商业保险四大子任务。传统人工操作模式下，服务专员需要分别登录不同模块逐个操作，一旦遗漏某个子任务就可能导致员工社保断缴或工资漏发。
首席道歉官在 2026-06-22-woshipm-hr-task-automation-design 中指出，入转调离的真正痛点不是”页面多”而是”联动缺”——子任务的拆解和下达完全依赖人工判断和手动执行，当多任务并发时系统缺少优先级判定机制，审核员需要翻看多个页面才能确认人员的真实状态。更复杂的是，如果离职被撤销，需要追溯性地恢复所有已退任务的状态。
方案的核心思路是将人员管理中的所有操作统一归入四大任务类型，并为每种任务类型建立标准化的全链路状态机，通过 子任务联动机制 实现主管务与子任务的自动拆分和统一管控，通过 状态机驱动按钮显隐 确保任何角色在任何节点看到的操作入口都是正确的。
关键信息
- 类型：方法论 / B端产品设计实践
- 领域：人力资源外包 / B端SaaS / 任务管理
- 核心问题：入转调离任务的子任务拆解和下达依赖人工判断，容易遗漏导致社保断缴或工资漏发
- 解决思路：以「用工任务」为核心实体，状态机驱动 + 子任务联动 + 权限矩阵三大支柱
- 四大任务类型：启动任务（入职/增员）、续变任务（续签/变更）、退出任务（离职/解约）、退任务（撤销处理）
- 关联角色：B端产品经理、业务架构师
- 关联方法：业务设计、流程梳理
核心特性
四大任务类型体系
| 任务类型 | 触发场景 | 子任务联动 |
|---|---|---|
| 启动任务 | 入职/增员 | → 合同签署 + 社保增员 + 工资开户 + 商保投保 |
| 续变任务 | 续签/变更 | → 合同续签 + 社保基数变更 + 工资调整 + 商保续保 |
| 退出任务 | 离职/解约 | → 合同终止 + 社保减员 + 工资结算 + 商保退保 |
| 退任务 | 撤销处理 | → 退社保 + 退合同 + 退工资 + 退商保 |
每种任务类型都有标准化的”发起→导入→拆分→审核→下达→撤销”全链路状态机。
全链路状态机
任务状态节点：待录入→待审核→审核中→已驳回→已通过→已下达→已撤销
每个状态节点定义了可操作动作集合，后端状态枚举驱动前端按钮显隐。这是 状态机驱动按钮显隐 设计模式的具体应用——不是靠前端 if-else 硬编码，而是在后端状态枚举中定义”当前状态+当前角色=可操作按钮列表”。
子任务联动机制
核心设计原则：
- 自动拆分：服务专员只需导入人员信息，系统自动根据人员状态和客户配置将主管务拆分为四个子任务
- 独立流转：子任务各自有独立的状态机和审批流程
- 统一管控：主管务撤销时，所有已下达的子任务同步进入退任务流程
这种”主管务—子任务”的联动机制，彻底解决了”退了合同但忘了退社保”的遗漏问题。详见 子任务联动机制。
权限矩阵设计
五类角色 × 五个维度的精细控制：
| 角色 | 主要职责 | 权限范围 |
|---|---|---|
| 服务主管 | 选择出账客户、选择任务类型 | 客户配置、任务发起 |
| 服务专员 | 录入/导入人员信息、补正资料 | 数据录入、结果查看 |
| 资料审核员 | 审核人员资料和合同信息 | 审核操作、驳回操作 |
| 资料审核主管 | 复核异常或高风险任务 | 高级审核、异常处理 |
| HR客户方 | 查看任务进度和结果 | 只读查看 |
权限按客户、组织、服务组、岗位和页面动作五个维度控制。审核类高危操作（批量导入、批量导出、删除、作废）需要单独授权。敏感个人信息（证件号、手机号、银行卡）按角色脱敏展示。
撤销离职的务实策略
撤销离职后的数据恢复采用”尽力恢复”策略：
- 如果离职期间社保已由新供应商接手 → 生成异常记录，推送审核主管人工确认
- 如果工资结算中已产生不可逆操作（如银行已打款）→ 标记为不可恢复
- 撤销离职时弹窗明确告知用户哪些任务可恢复、哪些不可恢复，增加二次确认
这比”完全回滚”的假设更务实——真实业务中很多操作是不可逆的，系统必须承认这一点并提供人工兜底路径。
业务流程设计（8步闭环）
| 步骤 | 核心动作 | 关键设计点 |
|---|---|---|
| 前置 | 服务主管选择出账客户 | 确认服务协议和办理项目范围 |
| 步骤1 | 选择任务类型 | 系统自动加载该客户下的任务模板和默认配置 |
| 步骤2 | Excel批量导入人员信息 | 文件限Excel、最大5M、仅读第一个Sheet |
| 步骤3 | 系统自动校验 | 必填字段完整性、人员状态合规性、任务冲突检测 |
| 步骤4 | 资料审核员逐一审核 | 人员信息真实性、合同模板匹配度、附件完整性 |
| 步骤5 | 补正资料后重新提交 | 保留每次审核和补正的历史记录 |
| 步骤6 | 系统自动拆分子任务 | 合同→合同系统、社保→社保系统、工资→薪酬系统、商保→商保系统 |
| 步骤7 | 审核主管复核 | 仅针对异常或高风险任务 |
| 步骤8 | 下达任务结果 | 同步更新人员状态；退出类任务同步生成退任务记录 |
不同素材中的观点
- 2026-06-22-woshipm-hr-task-automation-design（首席道歉官）：从HR外包服务的实际业务痛点出发，提出了以「用工任务」为核心实体的入转调离全链路自动化方案。核心洞察是”入转调离的真正痛点不是页面多而是联动缺”——通过状态机驱动、子任务联动和权限矩阵三大支柱，将”人盯人”模式升级为”系统驱动、流程管控”模式。给出了完整的四大任务类型体系、8步业务流程、5个核心功能模块的设计，以及撤销离职的”尽力恢复”务实策略。特别强调了两个实际使用问题：退任务之间的依赖关系（退社保可能需要在退工资之前完成）和撤销离职的数据追溯边界。
实用信息
适用场景
- 人力资源外包服务：入转调离全流程的任务管理和自动化
- B端SaaS任务管理系统：需要多级任务拆分、状态流转、权限控制的复杂任务系统
- 跨模块联动系统：一个主任务需要联动多个下游子任务的业务场景
设计启示
- 以任务而非页面为建模单元：入转调离的核心不是设计”入职页面""离职页面”，而是定义”用工任务”这个核心实体及其状态机。页面只是任务状态的可视化载体
- 子任务联动比单任务流转更复杂也更有价值：主任务撤销时子任务的同步回退、退任务之间的依赖关系、撤销离职的尽力恢复——这些联动逻辑是方案的核心价值
- 状态机驱动比 if-else 驱动更可靠：将”什么状态能做什么操作”编码到后端状态枚举中，比在前端写 if-else 更不容易出错，也更容易维护
- 撤销操作的务实设计：不要假设所有操作都可以回滚，系统必须承认不可逆操作的存在并提供人工兜底路径
注意事项
- 退任务依赖关系需要配置化：退社保、退合同、退工资、退商保四项退任务之间并非完全解耦（如退社保可能需要在退工资之前完成），当前版本退任务为并行处理，需要人工确保执行顺序。建议增加”退任务依赖关系配置”，允许客户按城市/地区模板设置退任务的前置依赖关系
- 撤销离职的二次确认不可省略：撤销离职时必须弹窗明确告知用户哪些任务可以恢复、哪些不可恢复，避免用户误以为”撤销=完全恢复”
- 批量导入的校验颗粒度：导入校验需要逐行提示失败原因，不能只给一个笼统的”导入失败”。社保截止日逾期、人员状态冲突等具体原因需要精确到行和字段
- 合同供应商电子签检测：系统需要自动检测合同供应商的电子签开通状态，未开通的自动切换为线下流程并给出明确提示，避免操作员在电子签和线下流程之间混淆
与其他方法论的关系
- 与 B端产品经理 的关系：入转调离任务自动化是B端PM”业务设计 vs 功能设计”方法论在HR外包入转调离场景的具体实践。以「用工任务」为核心实体的建模方式，正是业务设计四步法中”设计未来（To-Be业务模型）“步骤的落地——不是把线下表格搬到线上，而是重构业务流程本身
- 与 花名册功能设计 的关系：花名册是”数据层”（人员信息管理），入转调离自动化是”任务层”（人员状态变更的流程管理）。花名册的”规则显性化”原则在入转调离中体现为状态机驱动的按钮显隐
- 与 人员转移审批闭环 的关系：转移审批是”单点操作的安全”，入转调离自动化是”全链路的效率”。两者共同构成HR外包服务”人员管理”模块的完整设计
- 与 业务设计 的关系：本文展示了业务设计的”场景识别能力”——区分了主流程（正常入转调离）和异常流程（撤销离职、退任务依赖、社保截止日逾期），并为每种异常场景设计了系统化应对方案
- 与 工作SOP 的关系：8步业务流程是典型的B端系统SOP化设计，步骤3”系统自动校验”和步骤6”自动拆分子任务”是两个最关键的自动化节点