发布时间:2025-11-05 05:22:59 来源:创站工坊 作者:IT科技


(以上图片出自电影《星际穿越》)
如果你看过《星际穿越》,应该对这一幕印象深刻,系统女儿墨菲所处的时间房间,按照时间分为了无数个三维空间实体。轴设三维空间加时间组合成四维空间,演化即时空。历程
时间轴对于人事核心系统,得物就像四维时空中的人事时间,是系统类似生命周期的概念。了解HR工作的时间同事应该知道,员工在企业的轴设生命周期,从招聘、演化offer、历程实习、得物入职、转正、晋升、调动、离职、重复雇佣,有一套复杂的生命周期,并且组织本身也是在随时间发展的。
员工、服务器托管部门、职位等组织结构的发展和变化情况,均需要按照时间顺序准确记录,需要追溯到任意历史一天或未来一天展示当时的数据,并在某个时间做对应的调整。这个被人事系统高度依赖的时间维度,就是时间轴。
举一个常见的例子,在人力资源规划工作中,HR时常需要根据企业发展,及时设置、调整公司内部的组织架构。并且在调整的公告中,往往会注明执行日期,例如“自签发日期起,开始执行”等。
在实际操作中,调整组织架构是一项复杂的工作,人力资源部发布公告后,相关部门可能需要几天时间来配合完成调整。公司规模越大,调整的云南idc服务商难度越高,有时甚至当天无法完成所有调整设置工作,需要延后几天。因此产生了这样2种需求:
1. 我们需要在历史的组织架构上进行调整,并且该调整行为需要按照制定的执行日期来追溯,执行日期前后,需要展示当时对应的架构、职务数据。
2. 我们需要设置一个未来的执行日期,在这个日期上提前设置和调整组织架构,系统将在该执行日期到来之时,自动使该数据生效。
基于这2种需求,引入时间轴概念是水到渠成的。
另外,对组织架构和任职记录的历史追溯是必要的,并且有实际业务场景,主要应用在考勤、绩效、薪酬模块。绩效和薪酬模块都天然存在时间上的错位,常见于4月设定Q1的绩效,b2b供应网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)。

员工经历和入职、转正、变更、离职、重复雇佣等;部门经历了创建、变更、失效、启用等。
将员工和部门数据组合查询,可以得到任意历史时间的组织架构树和员工当时的任职信息。



在PS中,生效日期(EFFDT)是最重要的模型元素,另外还有生效状态(STATUS)、生效序号(EFFSEQ)。
每个标准数据(工号或部门Code)的历史数据按其生效日期顺序记录,如果一天内有多条数据,再按生效序号依次记录,员工离职和部门失效的数据,生效状态为0。N条数据分割出了N+1个区间。

员工经历和入职、转正、变更、离职、重复雇佣等;部门经历了创建、变更、失效、启用等。
将员工和部门数据组合查询,可以得到任意历史时间的组织架构树和员工当时的任职信息。



以上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;1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.假如需要查询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之生效日期