1、什么是時間軸

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

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

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

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

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

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

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

1. 我們需要在歷史的組織架構(gòu)上進(jìn)行調(diào)整，并且該調(diào)整行為需要按照制定的執(zhí)行日期來追溯，執(zhí)行日期前后，需要展示當(dāng)時對應(yīng)的架構(gòu)、職務(wù)數(shù)據(jù)。

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

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

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

例如某個員工在3月1日發(fā)生了異動：部門調(diào)動、職級晉升并有工作城市調(diào)動，且從2月開始漲薪。那么4月設(shè)定Q1績效時，因Q1中間有部門調(diào)動，應(yīng)由調(diào)動前后的上級聯(lián)合評定績效等級。在4月發(fā)放3月工資和Q1獎金時，不能按照4月當(dāng)時的薪酬水平來發(fā)放，而是需要考慮從2月1日開始調(diào)薪，重新計算3月工資、Q1獎金、補(bǔ)發(fā)工資、補(bǔ)繳社保和個稅。并且因?yàn)楣ぷ鞒鞘凶兓绫Ｐ枰謩e在2個城市繳納。

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

3、如何設(shè)計時間軸

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

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

3.1.1 設(shè)計原則

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

3.1.2 使用方法

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

3.1.3 維護(hù)方法

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

3.1.4 案例

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

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

3.2 生效日期模式（PeopleSoft）

3.2.1 設(shè)計原則

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

每個標(biāo)準(zhǔn)數(shù)據(jù)（工號或部門Code）的歷史數(shù)據(jù)按其生效日期順序記錄，如果一天內(nèi)有多條數(shù)據(jù)，再按生效序號依次記錄，員工離職和部門失效的數(shù)據(jù)，生效狀態(tài)為0。N條數(shù)據(jù)分割出了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 '部門負(fù)責(zé)人工號',
)

3.2.2 使用方法

// 查詢某一時刻的部門架構(gòu)(含失效部門)
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);
// 查詢某一時刻的部門架構(gòu)(不含失效部門)
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 維護(hù)方法

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

3.2.4 案例

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

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

3.3 優(yōu)劣勢對比

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

3.3.1 可維護(hù)性

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

3.3.2 易使用性

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

• 在查詢某一時刻所有啟用的組織架構(gòu)時，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的生效組織架構(gòu)，部門表中有如下數(shù)據(jù)

錯誤案例的結(jié)果：會錯誤地查到2018-12-01的生效數(shù)據(jù)，因?yàn)槠涫切∮?022-01-01的最后一條生效數(shù)據(jù)。

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

3.4 設(shè)計模式總結(jié)

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

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

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

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

4.1 階段一：無時間軸，實(shí)時生效

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

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

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

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

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

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

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

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

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

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

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

4.5 未來展望：自研替代PeopleSoft

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

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

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

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

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

5.2 建設(shè)難度、擴(kuò)展性難度

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

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

5.3 數(shù)據(jù)維護(hù)成本

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

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

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

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

6、總結(jié)

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

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

參考：PeopleSoft之生效日期