[SaaS招聘系统架构篇之一] –架构上如何体现对招聘流程运作模式的


在美国,100人以上的企业法律规定必须使用招聘系统,而20-99人的企业60%自主选择了使用招聘系统,招聘系统已经发展近20年,厂商至少200+家,但没有一家厂商市场份额超过5%

       为什么会这样?

其中一个原因就是任何一家厂商的产品难以适应招聘的各种运作模式。它是招聘系统架构设计最大的挑战之一。(当然还有其他的挑战)

你可能会讲,招聘不就是筛筛简历、推荐、评价、面试这一套嘛,哪个公司都差不多。但实际情况,不同公司之间有很大差别。

通常的社会招聘、校园招聘、猎头、RPO等也只是业务或招聘渠道上的分类,在设计系统时还要进一步从中剥离出更内在、更基础的运作模式,并能让系统架构能够支持。

我们先看看提取出来的通常的招聘运作模式有哪些:

     A.      单人直线型:一个职位的招聘流程从头到尾由一位招聘人员负责


      

     B.      分段型:一个职位的招聘在不同阶段由不同的招聘人员负责,每个阶段只有一位招聘人员。例如:有人专门做简历的初筛,有人负责前期部分面试环节的管理,有人负责后半程面试环节的管理。这种情况在“招聘中心+HRBP”团队结构模式时,就会出现。解释一下,“招聘中心”的团队通常会负责招聘渠道的开发、候选人的初选及面试考察,一旦锁定人选范围,将候选人转交给HRBP HRBP是用人部门的HR伙伴,他们会根据所在用人部门的准确用人需求进一步安排面试)。


        

     C.      分段多人型:在分段型的基础上,会出现某个阶段有多人参与的情况,每个人之间有相同身份和权力。例如:在校园招聘时,一个职位收到数千简历,几位招聘人员要一起筛选,并且各负责一部分候选人的面试流程。


      

     D.      主次协作模型:是分段多人型的衍生类型,同样是一个职位有多个招聘人员参与,但不同的是他们身份和权力不相同。例如:其中有人是主导,他负责这个职位的全程管控;辅助人员会参与到其中支持性工作。

      当然还有更多交叉衍生模型,如果把猎头、RPO等不同程度的外包服务方式考虑进来,在架构的支持能力方面就又提出更多要求。

作为企业客户,今天也许你的招聘运作模式是A型,明天需要B型;也可能一部分职位或一部分应聘者是A型流程,而另外一部分有的是B,甚至是C。如果在设计系统之初没有设想到并找到解决方案,那么,客户未来难免要在“定制并付出高昂成本”、“继续忍耐头疼不已的产品”、“不得不放弃”三者之间选择。与其事后痛苦,不如事前多花些时间调研。

你可能问系统不能升级来解决吗?

作为一种SaaS2B软件(也称为企业管理软件),招聘系统对流程、业务功能、权限等均需要考虑,架构非常复杂,一旦设定,不像2C的产品可以随时灵活调整,架构的优势和局限通常也需要较长的时间才能发现,后继修修补补最多只能解决部分功能层面的问题。所以说,架构是招聘系统的核心和基因,将决定软件系统的产品化能力和扩展能力,决定其是否能长期紧随企业的发展和变化。

云招从2008年开始,花了18个月不断尝试、验证,功夫不负有心人,我们做出的产品原型彻底解决了这个架构难题。后继在推出商用OurATS产品的5年中,以上各种情况在我们的客户群中真的都遇到了,而且系统一直是在最初的架构上不断丰富和完善,(相信这是许多云招早期的客户一直陪伴云招成长至今的重要因素)。

 5年后回顾,实践证明早期的18个月投入是非常值得的。


Recruiting is tough.  OurATS makes it easy.


(下一篇: [SaaS招聘系统架构篇之二] –招聘系统中的变形金刚  )