組織一調整，權限就亂？先讓組織主資料成為權限與流程的唯一源頭
發一紙調令容易，讓考勤、績效、審批人和資料權限同時生效很難。組織如果不是唯一源頭，每個系統都會變成一份過期通訊錄。權限混亂是組織主資料分裂的症狀。
讀這一篇能得到什麼
- 組織與任職關係應有唯一主資料來源頭，考勤、績效、審批、資料範圍都消費同一份
- 任免要有生效日，權限按生效日切換而不是按操作日，避免「人已到崗權還在舊部門」
- 審批人與資料範圍跟隨職位，而不是跟隨個人私聊指定
- 兼崗/借調/代理要顯式建模並設期限，避免「好像有權限」
- 預入職可開最小化賬號，入職生效日切換正式權限；先打通組織-任職-權限，再擴自助
調令週一生效，報銷還找舊經理
週一早上，製造部新經理發現：下屬請假仍推給前任，報銷審批鏈斷在已離職的郵箱，考勤組還停在舊車間規則。調令上週就發了，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 入轉調離、合同、花名冊，並做調崗生效日權限抽檢；二期再擴考勤組隨任職切換；三期再談更多員工/經理自助。權威源不確定之前，不要擴大自助審批範圍——自動化會放大錯誤的樹。
不適用時先停步：多套組織表並存且短期無法定權威，先定權威與同步紀律；歷史任職無法追溯，先補關鍵人員任職再按生效日解釋；審批仍大量線下指定人，先改矩陣到職位再上系統；代理與兼崗制度空白，先補期限與審計要求。組織半年不動的極小微企業手工成本低，但一旦多實體或多地，提前提模仍然值得。
近三十天調崗，三問抽檢
本週不必採購新模組。列出所有維護「部門」欄位的系統，指定唯一寫入方，其餘只讀——這一步比採購任何模組都更接近「權限不亂」。
再抽近三十天調崗樣本，三問：
- 生效日當天，考勤組、直接經理、審批鏈、資料權限是否同時切換？
- 有無無任職卻仍持有業務系統權限的賬號？
- 過期兼崗/代理是否已收回？預入職超權與離職殘留各有多少？
抽檢失敗先修同步與生效日，再考慮擴自助。記錄留檔備審計；權威源不確定時，停「郵件通知各系統改權限」的口子，改成只讀消費唯一任職。預入職最小化與離職日收權，建議作為每月固定項——兩端紀律建起來，中間調崗才不會每月重演。
- EHR 人力方案
- 招聘預入職
- 考勤異常閉環
- 績效閉環
- 薪酬資料可信
想把這篇裡的做法落到自己的廠裡？資源中心有對應場景的線上自測與資料模板，也可以直接約一次真實環境演示。
常見問題
圍繞本篇主題的追問，先看這裡；仍有疑問可聯絡我們
子公司法律實體和行政組織如何區分？
法律實體用於合同與薪稅，行政組織用於管理與審批，模型上分開、對映上關聯；混成一棵樹是權限與薪稅雙亂的開始。
臨時授權怎麼做？
有期限的代理/委託，到期自動收回，並保留審計；禁止永久「先開著」。
員工沒入職完能不能開賬號？
可用預入職賬號，權限最小化（填資料、看入職任務），轉正/入職生效日切換正式權限包。
組織頻繁調整怎麼辦？
用版本與生效日，不要靠覆蓋歷史；歷史單據應按當時組織解釋。
審批還大量指定具體人怎麼辦？
逐步改為「按職位/角色找人」；例外代理走委託單。指定人模式與組織調整天然衝突。