1、什么是時間軸

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

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

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

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

2、為什么人事系統(tǒng)需要時間軸

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

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

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

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

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

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

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

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

3、如何設計時間軸

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

3.1 時間區(qū)間模式（SAP）

3.1.1 設計原則

以SAP為代表的時間區(qū)間設計模式中，每個標準數(shù)據（工號或部門Code）的歷史數(shù)據都標記了其開始時間和結束時間和生效狀態(tài)，相鄰的2條數(shù)據接續(xù)但無交叉，最后一條數(shù)據的結束日期為無窮大(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 '部門狀態(tài)',
    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 維護方法

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

3.1.4 案例

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

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

3.2 生效日期模式（PeopleSoft）

3.2.1 設計原則

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

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

// 部門簡化模型
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 '部門狀態(tài)',
    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 維護方法

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

3.2.4 案例

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

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

3.3 優(yōu)劣勢對比

以上2種設計模式，都能實現(xiàn)人事系統(tǒng)對時間軸（生命周期）的需求，他們也各有優(yōu)勢和劣勢：

3.3.1 可維護性

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

3.3.2 易使用性

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

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

// 錯誤案例, 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的生效組織架構，部門表中有如下數(shù)據

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

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

3.4 設計模式總結

時間區(qū)間模式和生效日期模式都能夠滿足人事系統(tǒng)對時間軸的需求，但其各有優(yōu)劣勢，技術實現(xiàn)難度也不同，需企業(yè)結合其自身情況，選擇適合自己的方式。

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

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

4、得物人事系統(tǒng)時間軸設計的演化

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

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

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

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

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

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

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

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

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

4.4 階段四：引入PeopleSoft系統(tǒng)，規(guī)范專業(yè)的生效日期模式時間軸

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

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

4.5 未來展望：自研替代PeopleSoft

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

5、時間軸帶給研發(fā)人員的挑戰(zhàn)

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

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

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

5.2 建設難度、擴展性難度

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

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

5.3 數(shù)據維護成本

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

5.4 上下游系統(tǒng)的數(shù)據交換成本

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

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

6、總結

時間軸對于人事系統(tǒng)是重要且必要的，其將人事數(shù)據從離散變?yōu)橛行?，通過把各模塊數(shù)據按照時間串聯(lián)起來，構建成一套既可追溯企業(yè)發(fā)展歷程、也支持預先規(guī)劃未來發(fā)展的人事底層數(shù)據庫。

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

參考：PeopleSoft之生效日期