组织一调整，权限就乱？先让组织主数据成为权限与流程的唯一源头
发一纸调令容易，让考勤、绩效、审批人和数据权限同时生效很难。组织如果不是唯一源头，每个系统都会变成一份过期通讯录。权限混乱是组织主数据分裂的症状。
读这一篇能得到什么
- 组织与任职关系应有唯一主数据源头，考勤、绩效、审批、数据范围都消费同一份
- 任免要有生效日，权限按生效日切换而不是按操作日，避免「人已到岗权还在旧部门」
- 审批人与数据范围跟随职位，而不是跟随个人私聊指定
- 兼岗/借调/代理要显式建模并设期限，避免「好像有权限」
- 预入职可开最小化账号，入职生效日切换正式权限；先打通组织-任职-权限，再扩自助
调令周一生效，报销还找旧经理
周一早上，制造部新经理发现：下属请假仍推给前任，报销审批链断在已离职的邮箱，考勤组还停在旧车间规则。调令上周就发了，IT 说「等各系统手工改」，OA、MES、财务各改各的——有的改了，有的没改。审计抽到的不是黑客入侵，而是组织主数据分裂：每个系统一份过期通讯录。
发一纸调令容易，让考勤组、绩效评价人、审批人、数据范围同一天切换很难。权限混乱是症状，根子是「谁在什么生效日属于哪个职位」没有唯一真相。继续在每个系统里维护一份组织树，等于保证每次调岗都有人漏改。
还有一类更隐蔽：兼岗口头说了，系统里却能看到不该看的薪资；或者「先让他用老账号干着」，人已到新岗，权还在旧部门。方便换来的是安全与效率双损，越拖越难一次收干净。
唯一源头：组织引擎写，EHR 消费
JEDP 的分工建议写死在治理里：组织树与任职主数据由组织引擎主责；EHR 主责 HR 流程、考勤结果、绩效应用与薪酬发放链路；权限与流程办理人消费组织任职与权限引擎规则——人事系统不要另搞一套通讯录。
主数据最小集：组织单元（树 + 类型）、职位、任职（人-职位-生效区间）、汇报关系、兼岗/代理、编制。缺任职区间，所有「继承」都是猜。下游系统只读同步结果，禁止反向改树。谁都可以改组织树的日子，就是权限永久漂移的日子。
| 分裂点 | 现场表现 | 缺什么 |
|---|---|---|
| 多头维护组织树 | OA/HR/业务各一份 | 权威源与同步纪律 |
| 无生效日 | 按操作日改权 | 任职开始-结束区间 |
| 跟人绑审批 | 经理离职审批全断 | 按职位/角色找人 |
| 兼岗口头化 | 「好像能批」 | 显式记录与期限 |
| 法律实体与行政混树 | 薪税与管理扯不清 | 双模型 + 映射 |
| 预入职无边界 | 未入职即高权限 | 最小化权限包 |
编制也挂在同一树上：超编进人、空岗长期不补，都会在招聘预入职与排班里放大。入转调离单据应是任职变更的唯一合法入口；微信通知改权限，等于宣布主数据作废。
生效日不是操作日
调令 3 月 1 日生效，操作却在 3 月 5 日录入时，系统应按 3 月 1 日重算权限与考勤归属，并对 1～4 日单据给出可解释规则（补算或调整单），而不是以操作日覆盖历史。未来生效的组织调整应支持预置：合并日前完成映射与权限包演练，避免「周一早上全员无法审批」。
历史组织版本要保留。考勤、绩效、审批痕迹必须能按当时归属解释，否则劳动争议与审计时你会拿不出一致说法。「组织合并了，历史算新部门」——覆盖历史是最贵的偷懒。
审批矩阵应逐步改为「按职位/角色找人」；例外代理走委托单。指定自然人且无代理的模式，与组织调整天然冲突——请假、调岗、离职都会断流。抽检标准很硬：任取近 30 天一次调岗，核对生效日当天——考勤组、直接经理、审批链、数据权限是否同时切换。有一项落后，主数据就还不是唯一源头。
兼岗、借调、代理：写进系统，带上期限
兼岗应写明兼的职位、数据范围、是否含薪酬敏感字段、结束日期；借调区分「行政仍归属 A、工作指令在 B」时的考勤与绩效归属；代理用于经理休假，到期自动收回。任何「先开着方便干活」的永久额外权限，都应定期审计清零——过期未收回的代理/兼岗数，是权限只增不减的晴雨表。
临时授权全部走代理/委托单，禁止「先开权限再补手续」。到期自动失效并保留审计，才是可回收的临时；没有到期日的「临时」，六个月后就是幽灵账号。
法律实体与行政组织分开后，编制、审批走行政树，合同与个税主体走法律实体映射。多地工厂尤其容易混：员工在 A 厂上班、合同在 B 公司，若只有一棵树，权限与薪税总会有一边错。模型上分开、映射上关联，比硬拧成一棵大树安全得多。
预入职与离职：权限节奏的两端
预入职可以提前：资料填报、合同签署、入职任务；但业务系统权限、薪资查看、敏感名册必须等入职生效日切换——预入职账号是办理通道，不是提前上岗通行证。招聘专题讲的是录用到生效日的权限切换；本专题讲的是任职继承与调岗生效日——二者都依赖生效日，不要各建一套通讯录。
离职端对称：离职日自动收权、代理交接未完成要升级，账号残留与「人走权还在」是审计常客。入职日打开正式权，调岗日切换审批人，离职日收回——同一套时间纪律，审计才讲得通。
变化触发清单建议贴在 HR 与 IT 联席墙上：
| 变化 | 应触发 |
|---|---|
| 调岗 | 数据权限、审批人、考勤组、绩效关系按生效日切换 |
| 离职 | 账号禁用、代理交接、权限回收 |
| 兼岗/借调 | 额外权限包与范围，到期收回 |
| 组织合并/拆分 | 历史归属可追溯，单据按当时组织解释 |
| 预入职→入职 | 最小化账号切换正式权限包 |
| 代理 | 限期委托，到期失效 |
JEDP-EHR 组织人事怎么承权
JEDP-EHR 组织人事覆盖编制、员工档案与入转调离；权限随组织任职继承，调令生效日驱动权限包与审批人切换。招聘预入职覆盖资料审校与入职办理；考勤、绩效、薪酬消费同一任职。自助与经理服务的查询审批范围与组织权限一致——代理与兼岗必须可回收，操作可审计。
一期通常先打组织引擎骨架与 EHR 入转调离、合同、花名册，并做调岗生效日权限抽检；二期再扩考勤组随任职切换；三期再谈更多员工/经理自助。权威源不确定之前，不要扩大自助审批范围——自动化会放大错误的树。
不适用时先停步：多套组织表并存且短期无法定权威，先定权威与同步纪律；历史任职无法追溯，先补关键人员任职再按生效日解释；审批仍大量线下指定人，先改矩阵到职位再上系统；代理与兼岗制度空白，先补期限与审计要求。组织半年不动的极小微企业手工成本低，但一旦多实体或多地，提前提模仍然值得。
近三十天调岗，三问抽检
本周不必采购新模块。列出所有维护「部门」字段的系统，指定唯一写入方，其余只读——这一步比采购任何模块都更接近「权限不乱」。
再抽近三十天调岗样本，三问：
- 生效日当天，考勤组、直接经理、审批链、数据权限是否同时切换？
- 有无无任职却仍持有业务系统权限的账号？
- 过期兼岗/代理是否已收回？预入职超权与离职残留各有多少？
抽检失败先修同步与生效日，再考虑扩自助。记录留档备审计；权威源不确定时，停「邮件通知各系统改权限」的口子，改成只读消费唯一任职。预入职最小化与离职日收权，建议作为每月固定项——两端纪律建起来，中间调岗才不会每月重演。
想把这篇里的做法落到自己的厂里？资源中心有对应场景的在线自测与资料模板，也可以直接约一次真实环境演示。
常见问题
围绕本篇主题的追问，先看这里；仍有疑问可联系我们
子公司法律实体和行政组织如何区分？
法律实体用于合同与薪税，行政组织用于管理与审批，模型上分开、映射上关联；混成一棵树是权限与薪税双乱的开始。
临时授权怎么做？
有期限的代理/委托，到期自动收回，并保留审计；禁止永久「先开着」。
员工没入职完能不能开账号？
可用预入职账号，权限最小化（填资料、看入职任务），转正/入职生效日切换正式权限包。
组织频繁调整怎么办？
用版本与生效日，不要靠覆盖历史；历史单据应按当时组织解释。
审批还大量指定具体人怎么办？
逐步改为「按职位/角色找人」；例外代理走委托单。指定人模式与组织调整天然冲突。