1、什么是時間軸

（以上圖片出自電影《星際穿越》）

如果你看過《星際穿越》，應該對這一幕印象深刻，女兒墨菲所處的房間，按照時間分為了無數個三維空間實體。三維空間加時間組合成四維空間，即時空。

時間軸對于人事核心系統，就像四維時空中的時間，是類似生命周期的概念。了解HR工作的同事應該知道，員工在企業的生命周期，從招聘、offer、實習、入職、轉正、晉升、調動、離職、重復雇傭，有一套復雜的生命周期，并且組織本身也是在隨時間發展的。

員工、部門、職位等組織結構的發展和變化情況，均需要按照時間順序準確記錄，需要追溯到任意歷史一天或未來一天展示當時的數據，并在某個時間做對應的調整。這個被人事系統高度依賴的時間維度，就是時間軸。

2、為什么人事系統需要時間軸

舉一個常見的例子，在人力資源規劃工作中，HR時常需要根據企業發展，及時設置、調整公司內部的組織架構。并且在調整的公告中，往往會注明執行日期，例如“自簽發日期起，開始執行”等。

在實際操作中，調整組織架構是一項復雜的工作，人力資源部發布公告后，相關部門可能需要幾天時間來配合完成調整。公司規模越大，調整的難度越高，有時甚至當天無法完成所有調整設置工作，需要延后幾天。因此產生了這樣2種需求：

1. 我們需要在歷史的組織架構上進行調整，并且該調整行為需要按照制定的執行日期來追溯，執行日期前后，需要展示當時對應的架構、職務數據。

2. 我們需要設置一個未來的執行日期，在這個日期上提前設置和調整組織架構，系統將在該執行日期到來之時，自動使該數據生效。

基于這2種需求，引入時間軸概念是水到渠成的。

另外，對組織架構和任職記錄的歷史追溯是必要的，并且有實際業務場景，主要應用在考勤、績效、薪酬模塊。績效和薪酬模塊都天然存在時間上的錯位，常見于4月設定Q1的績效，4月發放3月工資+Q1的獎金等場景。

例如某個員工在3月1日發生了異動：部門調動、職級晉升并有工作城市調動，且從2月開始漲薪。那么4月設定Q1績效時，因Q1中間有部門調動，應由調動前后的上級聯合評定績效等級。在4月發放3月工資和Q1獎金時，不能按照4月當時的薪酬水平來發放，而是需要考慮從2月1日開始調薪，重新計算3月工資、Q1獎金、補發工資、補繳社保和個稅。并且因為工作城市變化，社保需要分別在2個城市繳納。

如果沒有時間軸，異動變化數據無法準確追溯，以上計算依靠人工，對大型集團企業的HR來說將是非常痛苦的。

3、如何設計時間軸

業界對時間軸（時間模型）的優秀設計模式，主要以下有2種，代表產品分別是SAP和PeopleSoft。

3.1 時間區間模式（SAP）

3.1.1 設計原則

以SAP為代表的時間區間設計模式中，每個標準數據（工號或部門Code）的歷史數據都標記了其開始時間和結束時間和生效狀態，相鄰的2條數據接續但無交叉，最后一條數據的結束日期為無窮大(9999-12-31)。

// 部門簡化模型
create table table_department
(
    code        varchar(20) not null comment '部門編號',
    start_time  datetime     not null comment '開始日期',
    end_time    datetime     not null comment '結束日期',
    status      int          not null comment '部門狀態',
    name        varchar(20) not null comment '部門名稱',
    parent_code varchar(20) not null comment '父部門編號',
    manager_id  varchar(20)  not null comment '部門負責人工號',
)

3.1.2 使用方法

// 查詢某一時刻的部門架構(含失效部門)
select * from table_department where start_time <= '2023-04-01' and end_time > '2023-04-01';
// 查詢某一時刻的部門架構(不含失效部門)
select * from table_department where start_time <= '2023-04-01' and end_time > '2023-04-01' and status = 1;

3.1.3 維護方法

• 添加最新或未來數據時，需將最后一條數據的結束時間改為新數據開始時間，新數據開始時間改為無窮大
• 插入歷史中間數據時，需將有沖突的歷史數據開始結束時間做避讓，空開新數據的時間區間。如果新數據將歷史數據完整包含，歷史數據將會被完全覆蓋

3.1.4 案例

員工經歷和入職、轉正、變更、離職、重復雇傭等；部門經歷了創建、變更、失效、啟用等。

將員工和部門數據組合查詢，可以得到任意歷史時間的組織架構樹和員工當時的任職信息。

3.2 生效日期模式（PeopleSoft）

3.2.1 設計原則

在PS中，生效日期(EFFDT)是最重要的模型元素，另外還有生效狀態(STATUS)、生效序號(EFFSEQ)。

每個標準數據（工號或部門Code）的歷史數據按其生效日期順序記錄，如果一天內有多條數據，再按生效序號依次記錄，員工離職和部門失效的數據，生效狀態為0。N條數據分割出了N+1個區間。

// 部門簡化模型
create table table_department
(
    code        varchar(20) not null comment '部門編號',
    effdt       date        not null comment '生效日期',
    effseq      int         not null comment '生效序號',
    status      int         not null comment '部門狀態',
    name        varchar(20) not null comment '部門名稱',
    parent_code varchar(20) not null comment '父部門編號',
    manager_id  varchar(20) not null comment '部門負責人工號',
)

3.2.2 使用方法

// 查詢某一時刻的部門架構(含失效部門)
select *
from table_department a
where a.effdt =
      (select max(b.effdt) from table_department b where b.code = a.code and b.effdt <= '2023-04-01')
  and a.effseq =
      (select max(c.effseq) from table_department c where c.code = a.code and c.effdt = a.effdt);
// 查詢某一時刻的部門架構(不含失效部門)
select *
from table_department a
where a.effdt =
      (select max(b.effdt) from table_department b where b.code = a.code and b.effdt <= '2023-04-01')
  and a.effseq =
      (select max(c.effseq) from table_department c where c.code = a.code and c.effdt = a.effdt)
  and a.status = 1;

3.2.3 維護方法

• 添加或插入數據時，按期望的生效日期插入，如果當天已存在記錄，則按序號添加，或在老序號中間插入
• 未來數據和歷史數據同理

3.2.4 案例

員工經歷和入職、轉正、變更、離職、重復雇傭等；部門經歷了創建、變更、失效、啟用等。

將員工和部門數據組合查詢，可以得到任意歷史時間的組織架構樹和員工當時的任職信息。

3.3 優劣勢對比

以上2種設計模式，都能實現人事系統對時間軸（生命周期）的需求，他們也各有優勢和劣勢：

3.3.1 可維護性

• 生效日期模式（PeopleSoft）更優：維護時只需要對應按生效日期添加數據、修改數據、刪除數據，可以較方便地對歷史回溯數據進行修改。
• 時間區間模式（SAP）較難：因其對每條數據的開始結束時間都有不可重疊的強校驗，因此編輯任何一條數據，都需要對和其相鄰的數據進行同步修改，對人工維護和系統維護都帶來了更大的挑戰。

3.3.2 易使用性

• 時間區間模式（SAP）更優：因查詢時，只需按所需的日期在開始結束范圍內查詢，即可確定當時唯一的一組數據。
• 生效日期模式（PeopleSoft）較難：查詢時，有effdt和effseq兩個維度需要取max，取值較復雜，且容易出錯。以下是一個常見的錯誤案例：
• 生效日期模式典型錯誤案例

• 在查詢某一時刻所有啟用的組織架構時，status狀態檢查需要放在子查詢的外層。

// 錯誤案例, status在子查詢中
select *
from table_department a
where a.effdt =
      (select max(b.effdt) from table_department b where b.status = 1 and b.code = a.code and b.effdt <= '2023-04-01')
  and a.effseq =
      (select max(c.effseq) from table_department c where c.status = 1 and c.code = a.code and c.effdt = a.effdt);


// 正確案例，status在子查詢的外層
select *
from table_department a
where a.effdt =
      (select max(b.effdt) from table_department b where b.code = a.code and b.effdt <= '2023-04-01')
  and a.effseq =
      (select max(c.effseq) from table_department c where c.code = a.code and c.effdt = a.effdt)
  and a.status = 1;

假如需要查詢2022-01-01的生效組織架構，部門表中有如下數據

錯誤案例的結果：會錯誤地查到2018-12-01的生效數據，因為其是小于2022-01-01的最后一條生效數據。

正確案例的結果：2020-01-01是小于2022-01-01的最后一條數據，但因失效，因此會被排除。

3.4 設計模式總結

時間區間模式和生效日期模式都能夠滿足人事系統對時間軸的需求，但其各有優劣勢，技術實現難度也不同，需企業結合其自身情況，選擇適合自己的方式。

另外可以看出，人事系統所需的設計模式和通用系統有很大不同。對于通用系統如電商/支付/社交等，數據都是實時生效的，訂單發起->支付->發貨->收貨，數據通過狀態機等機制流轉并生效，A用戶的訂單和B用戶的訂單之間，并沒有聯系。

在人事系統中則不同，例如將A員工在1月1日設置為B部門的Leader，雖然1月1日B部門內的員工并沒有任何異動和職務調整，但他們的所在部門負責人都會自動關聯為A員工。因此，每條數據及其歷史數據變化，都有關聯影響，這些影響會通過時間軸串聯起來。因此，時間軸是人事系統中的必要元素，也是人事系統高度復雜性和專業性的體現。

4、得物人事系統時間軸設計的演化

4.1 階段一：無時間軸，實時生效

19年，得物EHR系統從純自研起步，參考了釘釘和飛書的部分模式，在該階段，人事主數據沒有設計時間軸概念，所有修改即時覆蓋生效。組織架構模型對應的基本數據均只有1條最新條目，雖然有變更記錄供回查，但技術上并不支持追溯歷史某一天的架構和任職數據。

因該階段仍處于初期建設的階段，對于歷史數據回溯的需求并不強，且上下游系統較少，因此對時間軸的建設暫未高優先級推進。

4.2 階段二：按天快照，定時刷新

20年，在這個階段，得物人事系統建設的模塊逐漸增多，主要增加了假勤、績效等業務板塊，這些模塊對于時間軸的需求逐漸顯現。比如假勤考勤組的分配和回溯依賴歷史組織架構、績效模塊。

因此對組織架構做了數據快照備份，相關模塊可以通過讀取快照查詢歷史數據，解決了一些燃眉之急。

4.3 階段三：自研組織架構生命線，時間區間模式時間軸

21年，人事各相關系統對于時間軸的需求愈發強烈，并且無時間軸的設計令人事核心數據質量無法保證，各類數據無序生產，使系統維護難度加大。因此EHR自研開發了生命線模塊，使用時間區間模式。所有組織架構變動和任職信息變動，都會生產一條精確到秒的時間線數據。

通過讀取生命線中的數據，解決了無法追溯任意歷史時間數據的問題。但仍有局限，該生命線僅支持當天異動，自動生產生命線數據。無法對歷史數據進行人工編輯和修正。系統中仍存在部分異常數據，因無法人工調整而擱置，影響了整體數據準確性。

4.4 階段四：引入PeopleSoft系統，規范專業的生效日期模式時間軸

22年，公司實施了PeopleSoft系統，該系統作為老牌人力資源軟件，帶來了專業且規范的數據庫、功能和規則。PS系統此后作為核心人事數據庫，EHR系統圍繞PS系統做功能開發，使人事數據的準確性和完整性上了一個大臺階。

并且，在PS系統的"指導"下，HR和人事系統的產研部門，從中學到了其諸多專業的設計模式。得物的人事系統數據質量和專業性都大幅提高，也通過主數據平臺實現了對公司內部各個下游系統的數據分發，基本滿足了HR對于人事系統的核心需求。

4.5 未來展望：自研替代PeopleSoft

在其他大型互聯網公司中，不乏先將PS或SAP等專業軟件作為人事底層系統起步，再逐步自研定制開發的案例。因為PS和SAP等標準系統仍存在很多限制，無法滿足企業定制需求，自研替代能使其人事系統在滿足規范專業性的同時，更加契合企業自身的需求。未來，得物的人事系統也將逐漸走向這個方向。

5、時間軸帶給研發人員的挑戰

• 時間軸是人事系統中最重要的設計之一，其重要性貫穿人事系統的每個模塊。同時，其復雜度和維護難度也是極高的，需要產研人員具有高度專業性，來應對人事系統高復雜度帶來的挑戰。

5.1 理解和使用時間軸的門檻

人事系統作為專業系統，對產品和研發的專業性有一定的要求。對于未接觸過人事系統的研發人員，需要一定的成本來理解時間軸的概念，正確規范地設計時間軸需要豐富的經驗。

5.2 建設難度、擴展性難度

首先是時間軸的選型，如果是選用業界知名產品如PS，一般已經自帶了完整的時間軸設計，選用后基本定型，再更換難度很高。如果是自研系統，從0開始設計，首先需要考慮時間軸的應用范圍，比如組織架構和任職記錄一定需要時間軸；合同信息、獎懲記錄等不需要時間軸；公司配置、數據字典等可選是否添加時間軸，需要根據需求來設計。

另外，帶時間軸的系統，在員工的入轉調離核心流程、組織架構異動調整等，都需要按時間做準確的記錄，需要系統設計時有各種完備的規則校驗。如果這些核心內容有漏洞，使用體驗可能較差，并且數據質量也將無法保證。

5.3 數據維護成本

維護時間軸數據的門檻和成本也很高，大型集團企業的組織架構極其復雜，調整及修正數據帶來的影響很大。HR手動調整需要花費大量時間，也需要有豐富的系統經驗。如果數據出錯，排查的難度也極大，研發人員可能將需要開發對應的工具來協助檢查，或搭建數據巡檢平臺來實現。

5.4 上下游系統的數據交換成本

時間軸對于人事系統是重要且必要的，是因其專業性決定的。但公司內部其他需要人事數據的關聯系統沒有時間軸的需求，如采購、財務、郵箱和飛書、員工賬號系統等。這些系統不需要人事系統的專業數據，也很難和人事系統的時間軸進行數據交換。

因此，通常會將時間軸中的實時人事數據作為對外數據提供給上下游系統。在此類數據交換的過程中，需要注意因為忽略了時間維度，數據需要按照一定的規律和順序提供，避免出現如先推送了新部門，后推送部門負責人，導致下游在創建部門時判斷部門不存在的錯誤。

6、總結

時間軸對于人事系統是重要且必要的，其將人事數據從離散變為有序，通過把各模塊數據按照時間串聯起來，構建成一套既可追溯企業發展歷程、也支持預先規劃未來發展的人事底層數據庫。

對于高速發展奔向超大型組織的集團企業來說，以時間軸作為核心來設計人事系統，可以有效支撐組織發展的速度，極大程度避免企業遇到人力資源發展中的效率瓶頸。

參考：PeopleSoft之生效日期