(以上图片出自电影《星际穿越》)
如果你看过《星际穿越》,应该对这一幕印象深刻,得物女儿墨菲所处的人事房间,按照时间分为了无数个三维空间实体。系统三维空间加时间组合成四维空间,时间即时空。轴设
时间轴对于人事核心系统,演化就像四维时空中的历程时间,是得物类似生命周期的概念。了解HR工作的同事应该知道,员工在企业的生命周期,从招聘、offer、实习、入职、转正、晋升、调动、离职、重复雇佣,有一套复杂的生命周期,并且组织本身也是在随时间发展的。
员工、部门、职位等组织结构的发展和变化情况,均需要按照时间顺序准确记录,需要追溯到任意历史一天或未来一天展示当时的数据,并在某个时间做对应的调整。这个被人事系统高度依赖的时间维度,就是时间轴。
举一个常见的例子,在人力资源规划工作中,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来说将是非常痛苦的。
业界对时间轴(时间模型)的优秀设计模式,主要以下有2种,代表产品分别是SAP和PeopleSoft。
以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 '部门负责人工号',)
// 查询某一时刻的部门架构(含失效部门)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;
员工经历和入职、转正、变更、离职、重复雇佣等;部门经历了创建、变更、失效、启用等。
将员工和部门数据组合查询,可以得到任意历史时间的组织架构树和员工当时的任职信息。
在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 '部门负责人工号',)
// 查询某一时刻的部门架构(含失效部门)select *from table_department awhere 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 awhere 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;
员工经历和入职、转正、变更、离职、重复雇佣等;部门经历了创建、变更、失效、启用等。
将员工和部门数据组合查询,可以得到任意历史时间的组织架构树和员工当时的任职信息。
以上2种设计模式,都能实现人事系统对时间轴(生命周期)的需求,他们也各有优势和劣势:
// 错误案例, status在子查询中select *from table_department awhere 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 awhere 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的最后一条数据,但因失效,因此会被排除。
时间区间模式和生效日期模式都能够满足人事系统对时间轴的需求,但其各有优劣势,技术实现难度也不同,需企业结合其自身情况,选择适合自己的方式。
另外可以看出,人事系统所需的设计模式和通用系统有很大不同。对于通用系统如电商/支付/社交等,数据都是实时生效的,订单发起->支付->发货->收货,数据通过状态机等机制流转并生效,A用户的订单和B用户的订单之间,并没有联系。
在人事系统中则不同,例如将A员工在1月1日设置为B部门的Leader,虽然1月1日B部门内的员工并没有任何异动和职务调整,但他们的所在部门负责人都会自动关联为A员工。因此,每条数据及其历史数据变化,都有关联影响,这些影响会通过时间轴串联起来。因此,时间轴是人事系统中的必要元素,也是人事系统高度复杂性和专业性的体现。
19年,得物EHR系统从纯自研起步,参考了钉钉和飞书的部分模式,在该阶段,人事主数据没有设计时间轴概念,所有修改即时覆盖生效。组织架构模型对应的基本数据均只有1条最新条目,虽然有变更记录供回查,但技术上并不支持追溯历史某一天的架构和任职数据。
因该阶段仍处于初期建设的阶段,对于历史数据回溯的需求并不强,且上下游系统较少,因此对时间轴的建设暂未高优先级推进。
20年,在这个阶段,得物人事系统建设的模块逐渐增多,主要增加了假勤、绩效等业务板块,这些模块对于时间轴的需求逐渐显现。比如假勤考勤组的分配和回溯依赖历史组织架构、绩效模块。
因此对组织架构做了数据快照备份,相关模块可以通过读取快照查询历史数据,解决了一些燃眉之急。
21年,人事各相关系统对于时间轴的需求愈发强烈,并且无时间轴的设计令人事核心数据质量无法保证,各类数据无序生产,使系统维护难度加大。因此EHR自研开发了生命线模块,使用时间区间模式。所有组织架构变动和任职信息变动,都会生产一条精确到秒的时间线数据。
通过读取生命线中的数据,解决了无法追溯任意历史时间数据的问题。但仍有局限,该生命线仅支持当天异动,自动生产生命线数据。无法对历史数据进行人工编辑和修正。系统中仍存在部分异常数据,因无法人工调整而搁置,影响了整体数据准确性。
22年,公司实施了PeopleSoft系统,该系统作为老牌人力资源软件,带来了专业且规范的数据库、功能和规则。PS系统此后作为核心人事数据库,EHR系统围绕PS系统做功能开发,使人事数据的准确性和完整性上了一个大台阶。
并且,在PS系统的"指导"下,HR和人事系统的产研部门,从中学到了其诸多专业的设计模式。得物的人事系统数据质量和专业性都大幅提高,也通过主数据平台实现了对公司内部各个下游系统的数据分发,基本满足了HR对于人事系统的核心需求。
在其他大型互联网公司中,不乏先将PS或SAP等专业软件作为人事底层系统起步,再逐步自研定制开发的案例。因为PS和SAP等标准系统仍存在很多限制,无法满足企业定制需求,自研替代能使其人事系统在满足规范专业性的同时,更加契合企业自身的需求。未来,得物的人事系统也将逐渐走向这个方向。
人事系统作为专业系统,对产品和研发的专业性有一定的要求。对于未接触过人事系统的研发人员,需要一定的成本来理解时间轴的概念,正确规范地设计时间轴需要丰富的经验。
首先是时间轴的选型,如果是选用业界知名产品如PS,一般已经自带了完整的时间轴设计,选用后基本定型,再更换难度很高。如果是自研系统,从0开始设计,首先需要考虑时间轴的应用范围,比如组织架构和任职记录一定需要时间轴;合同信息、奖惩记录等不需要时间轴;公司配置、数据字典等可选是否添加时间轴,需要根据需求来设计。
另外,带时间轴的系统,在员工的入转调离核心流程、组织架构异动调整等,都需要按时间做准确的记录,需要系统设计时有各种完备的规则校验。如果这些核心内容有漏洞,使用体验可能较差,并且数据质量也将无法保证。
维护时间轴数据的门槛和成本也很高,大型集团企业的组织架构极其复杂,调整及修正数据带来的影响很大。HR手动调整需要花费大量时间,也需要有丰富的系统经验。如果数据出错,排查的难度也极大,研发人员可能将需要开发对应的工具来协助检查,或搭建数据巡检平台来实现。
时间轴对于人事系统是重要且必要的,是因其专业性决定的。但公司内部其他需要人事数据的关联系统没有时间轴的需求,如采购、财务、邮箱和飞书、员工账号系统等。这些系统不需要人事系统的专业数据,也很难和人事系统的时间轴进行数据交换。
因此,通常会将时间轴中的实时人事数据作为对外数据提供给上下游系统。在此类数据交换的过程中,需要注意因为忽略了时间维度,数据需要按照一定的规律和顺序提供,避免出现如先推送了新部门,后推送部门负责人,导致下游在创建部门时判断部门不存在的错误。
时间轴对于人事系统是重要且必要的,其将人事数据从离散变为有序,通过把各模块数据按照时间串联起来,构建成一套既可追溯企业发展历程、也支持预先规划未来发展的人事底层数据库。
对于高速发展奔向超大型组织的集团企业来说,以时间轴作为核心来设计人事系统,可以有效支撑组织发展的速度,极大程度避免企业遇到人力资源发展中的效率瓶颈。
参考:PeopleSoft之生效日期
责任编辑:武晓燕 来源: 得物技术 得物人事系统时间轴(责任编辑:综合)
九兴控股(01836.HK)发布公告:授出1969.5万份购股权
“双11”全国快件量达47.76亿件 11日当天共处理快件6.96亿件