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之收效日期

线下活动引荐

时刻:2023年6月10日(周六) 14:00-18:00

主题:得物技能沙龙总第18期-无线技能第4期

地址:杭州西湖区学院路77号得物杭州研制中心12楼培训教室(地铁10号线&19号线文三路站G口出)

活动亮点:本次无线沙龙聚集于最新的技能趋势和实践,将在杭州/线上为你带来四个令人等待的演讲论题,包含:《抖音创作工具-iOS功耗监控与优化》、《得物隐私合规渠道建造实践》、《网易云音乐-客户端大流量活动的日常化保证方案实践》、《得物Android编译优化》。相信这些论题将对你的作业和学习有所协助,我们等待着与你一起讨论这些令人兴奋的技能内容!

报名方法:点击报名无线技能沙龙

本文属得物技能原创,来源于:得物技能官网

未经得物技能答应禁止转载,否则依法追究法律责任!