第一阶段：BPM+PS阶段
BPM负责offer以及人事的入离调转，通过中间表的方式写数据，以异步的方式同步到PS系统，在这一阶段，各个系统是断开的，没有所谓的内网，也不存在移动办公。
这一阶段，PS的功能包括了core HR、休假、算薪、绩效。
员工的offer、入职、调动、转正、离职、转正是在BPM中操作，结果数据同步到PS中落地。
国内休假是采用.net开发，结果数据落地到PS，海外休假采用的是PS中的标准功能，绩效也是用的PS功能。
在这个阶段，阿里的信息化只能说是有系统可用，谈不上效率，也没有移动化。同时也面临着数据落地失败、BPM系统不稳定、业务扩展、人数激增等问题。（备注：下文图片缺少的部分是“离职”。）
第二阶段：PS + HR工作台
在BPM阶段遗留了很多问题：
- BPM已经到期，面临是否续费的选择。
- BPM已经满足不了实际业务发展的需要。
- BPM是基于.net开发的，集团开始转向java开发。
- 集团从13年开始推行移动all in。要求移动办公。
- BPM同步PS的数据要到第二天才能生效，数据时效性不好。
基于这些考虑，阿里的研发部门决定抛弃基于.net开发的BPM，转向自主研发适合自己的入离调转系统。在此时，阿里下游的人事、行政等系统其实是割裂的，内部交流通过一个叫”轩辕剑”的软件是用来查公司组织架构和人。数据也不是实时更新的。
在2013年，阿里信息平台内部开始提及主数据的概念，在当时就希望基于此替换掉PS。当时的主数据其实就是一个MySQL的数据库，数据是从ps抓取然后进行加工处理，所包含的信息也非常少，仅仅是人员的基本信息和职务信息。基于主数据，信息平台开始更新轩辕剑并丰富功能，同时更名为阿里内外。这时候阿里内外只是一个简单的在电脑上能查到人的软件。
与此同时，随着BPM的到期，重构属于阿里自己的人事管理系统也逐渐提上日程，在此之前做了哪些工作：
1、实地走访用户，深入一线HR，了解他们的需求。
2、项目交付的过程中，熟悉业务的HR是深度参与的，在交付的过程中针对hr的使用习惯和操作习惯包括常用报表都做了对应的适应。
3、整合系统，打通人事的各个环节，实现移动办公审批。
4、将组织架构变更迁移到外部，实现hr自主变更所属范围的组织架构
5、数据实时更新到ps
在第二阶段的前期，数据的来源是HR工作台—PS—主数据。
这一个阶段的主数据，已经开始接受不止是单一的员工个人信息数据和职务数据，也开始对外提供人事的其他数据服务。而在此之前也暴露了主数据的局限性。在之前主数据的定位是人员当前最新的数据，做到实时同步和更新。到后面发现如果单一的人事数据是无法支持未来业务的发展。很多系统开始要求提供历史性的数据，以及要求常用性以及字典数据也要统一，避免后期带来的数据转换成本。基于此类考虑，PS开始向主数据提供人事基础数据如地点公司，也提供人员职务变更的历史记录和字典类数据。
第二阶段的中后期，随着主数据的日益完善，公司内部的系统开始围绕着主数据开展业务。包括人员账号的开通关闭、绩效、人才盘点、人员的入离调转数据都是基于主数据来获取的。
这一阶段PS功能包括core HR和payroll、休假。绩效已经实现外部自研，数据也不再落地到ps。core HR只是存储结果数据，人员的入离调转晋升等都是在hr工作台实现流程结转。数据最终落地到ps。
人员的组织、权限、hr基础数据都可以在hr工作台得到快速配置。
人员的晋升、年终奖的配发、绩效、人才盘点等都实现了在外部自研。
同时跟其他系统的打通也都是基于主数据来扩展。主数据依托阿里内外的app，来服务员工服务管理者。例如：因为员工休假找不到人，主数据提供员工的休假状态、时间和代理人。
基于主数据为数仓提供源数据，为管理工作台提供分析类数据：包括人员考勤情况分析、人才盘点、人才流失等数据分析。
第三阶段：EHR平台+ PS
经过第二个阶段的夯实基础，人员围绕core HR的数据已经逐步从PS剥离，而此时阿里也迎来上市。国外业务也在扩张，面临的问题是当前基于ps的考勤、休假、员工福利都已经不能满足要求，在这个阶段主要是将除了算薪以外的其他数据都剥离出PS，包括年终奖和绩效。
PS在此阶段就是底层数据库。从休假开始，所有业务数据都是存储在业务系统，PS只接受结果数据，包括休假、考勤、payroll一次性输入、员工福利等，这个阶段生态公司也在逐步加入，生态公司的员工也需要能访问阿里的内部系统和网络，主数据也在逐步接入生态公司，下游的HR系统也能支持生态公司，使用同一套人事、休假、考勤、福利系统。
E表人才是阿里的年终奖分配发放系统，也是人才盘点、员工发展的集合。在年终绩效评分之后，就开始进行E表人才，除了员工参与对自身技术能力的评定、下阶段发展规划，也包含上级主管对员工的发展等级的评定、奖金池的分配。
在此阶段，整个HR系统面临最大的挑战，除了PS薪酬计算慢以外，就是休假余额不准。在2014年，阿里EHR团队开始抽调团队重构休假系统。从系统一开始立项的定位就是：
1、数据准确、结算精准。
2、可配置化，简易化，易于用户操作。
3、适用于国际化，多语言多时区版本
4、移动化，集成化。
5、服务于主数据，综合考勤休假数据，能够及时接入生态化公司。
基于以上考虑，休假系统从一开始就对标PS灵活配置的规则，不仅仅是年假规则，包括通知模板、报表均是灵活选择配置。
第四阶段：EHR平台
在2015年，完成休假系统从PS系统中彻底剥离之后，剩余在PS中的只剩下实习生考勤、员工福利申请和薪酬计算。基于此，阿里开始筹划薪酬自主运算，在自主剥离实习生考勤和员工福利申请之外，阿里也在同步进行薪酬自主核算。薪酬核算涉及到一个非常复杂的过程，除了涉及到员工入离调转的变动，还包括员工薪资变化、社保变化、考勤休假等多种情况，涉及分段、追溯，还需要让薪酬人员能以最简单的方式理解每一个薪资项的来源。这个中间涉及到公式、累加器、数组、分级等，还需要将薪酬规则抽象化，让用户能够方便、简单的后期运维。
同时考虑到薪资的高度保密性，还需要保证数据不会泄露，一个是对数据库层面进行加密，开发看到的数据库都是经过加密的，第二个是对应用层面增加开关，允许隐藏或者展示薪资数据，第三个是硬件加密，防止数据拷贝和遗失造成的数据泄露。
薪酬自主核算的第一步，是将原来PS里批量导入的功能迁移到外部，鉴于此类属于非敏感数据，当时以引进Java外包方式开发薪酬批量导入，原来在PS中有很多收入项是需要通过导入的方式录入到PS，存在操作复杂，文件格式有限制，数量有限制等难度，基于未来考虑，将薪酬批量导入采用Java的方式开发，能够支持Excel导入，数据复审，数据实时同步等功能。
第二步是先易后难：薪酬核算是一个非常复杂的过程，涉及到每个薪资项目的计算以及薪资数据的准确性，为了减少影响范围，将实习生工资第一个纳入薪酬自主核算的试验田，在稳定运行之后，才正式运行正式员工的薪酬核算，为了保证数据的准确性，PS薪酬核算与薪酬自主核算系统并行了半年。
总结
善于学习现有商业系统先进之处，不盲从，善思考
善于利用现有技术和公共组件，避免重复造轮子，比如国际化需要多语言版本，当时就有团队已经有自己的多语言管理系统美杜莎，只需要使用他们提供的服务即可。需要调度类服务，有现成的服务可以提供，也方便集中管理，有问题也会积极响应。
所有人事类的数据主数据都对外提供数据查询服务，通过授权满足下游系统的服务。
系统要灵活配置，包括模板、功能等。
感想
HR系统是一个复杂的系统，看起来是一个简单的人员入离调转发工资，但是中间包含着诸多复杂的业务。阿里能够把去PS以及薪酬核算自主研发，靠的是深厚的技术积累。从2013年到2016年这三年期间，阿里的中台技术、中间件技术、云计算技术以及围绕着淘宝生态化衍生的技术，都能在诸多的项目中得到灵活运用。新功能的建设之前，总会先看看内部是否有类似的功能，避免重复造轮子。HSF、ODPS这些技术是支撑着阿里一步步把PS功能逐步剥离的技术基础，中台战略、主数据是为HR诸多系统打下坚实的基础，在此基础上，才有全球休假系统、HR工作台、管理工作台、薪酬核算系统等这些震惊业内的系统。
我们经常听到有人说人事系统能有多复杂，不就是给人办个入职、算个工资吗，能有多复杂？这不是一个技术人员或者产品应该有的态度，作为一个在HR领域占据半壁江山的系统，任何认为他简单、觉得比金融、ToB交易简单的想法，都是愚蠢和不合格的。对老旧的系统，我们可以挑毛病，但是也要保持敬畏之心，对于自己不懂的业务，也不要觉得自己的业务最牛逼，其他都是菜瓜。阿里投入了10多人全都是P7P8级别的专家，前后花了1年的时间才将薪酬核算系统做好，并行又花了半年，才敢正式宣布去PS。
本文转载自微信公众号“陈果George”，如有侵权，请联系我们删除
原始URL：https://mp.weixin.qq.com/s/demjFP_gHH_ZlHga5i2z_g
