审批调岗调薪

项目介绍

审批调岗调薪是把「通过之后要发生的事」写进审批流：调岗、转正、转全职这类申请，审批一通过就联动人事异动记录与薪酬数据，不再由 HR 到两个模块里重复录一次。

起因是这类审批本身就不是单一变更：调一个岗位，同时动了组织与岗位、职级与薪资、生效日期三处。过去审批走完只是拿到了一个「同意」，人事和薪酬还要各自补录，漏一处就对不上账。

我的判断只有一条：审批是入口，不是终点。表单灵活度不是重点，通过之后自动发生什么才是。

问题在哪

一次调岗至少牵动三处，且各有各的生效日期：

• 组织与岗位：人事侧要新增一条异动记录
• 职级与薪资：薪酬侧要改档案并按新月薪核算
• 生效日期：考勤、工龄、社保基数都跟着它走

手工补录的三个必然后果：漏同步、两侧日期不一致、改完没有痕迹。

两条设计决定

一、按事拆模板，不做一张大表单

同一类事只有一个入口。转正调薪、调岗调薪、转全职调薪三个模板由人事与智能薪酬共同提供，模板说明直接写清「审批通过后自动同步至智能薪酬」，让审批人知道自己在批什么后果。

二、把数据同步做成模板属性

同步不是写死在代码里的行为，而是模板上的开关：这个模板要不要同步给人事、要不要同步给薪酬，由配置决定。字段层面对齐了同名同义——转全职前信息由系统自动获取，转全职后信息由申请人填，调薪明细里自动求和并生成大写金额，减少手填错误。

结果与边界

• 人事与薪酬两侧共用一套审批模板，减少一次重复录入
• 使用规模与同步成功率按上线数据复核后再补，这里不写未核过的数字

可迁移的判断

• 审批类产品的能力上限不在表单灵活度，在「通过之后自动发生什么」
• 跨系统流程的第一个坑是生效日期不一致：设计时就要把每个日期字段的含义写死
• 模板化的真正收益是减少培训成本：同一类事只有一个入口、一种说法