利用Odoo实现HR功能之：从人员需求申请_工作岗位招聘过程的闭环业务

近期为公司进行一项HR方面的业务，即HR功能中的，从人员编制管理–再到HR工作岗位的招聘，这样形成了一个闭环的业务。所以拿起来说说，这个最主要是利用原来工作岗位的Odoo原型机制，再进行一些业务的逻辑调整，招聘完成后再返回需求状态，达到一个完整的闭环业务。这其中也会涉及到员工合同的管理，这个放到下一个话题。

下面的内容包括以下几个部分：

1. 整个招聘管理的业务流程与业务逻辑；
2. 模块介绍；
3. 人员需求表及逻辑（含审批流）;
4. 工作岗位逻辑及调整;
5. 部门人员编制需求表；

一、整个招聘管理的业务流程与业务逻辑；

这里仅从人员需求申请业务、工作岗位进行业务描述，因为在此次需求中，它会形成一个业务上的闭环。员工合同管理是属于Odoo原型的模块，只是从工作岗位转为员工的一些HR业务进行对接，下次有空的话再进行说明。

二、模块介绍；

• 人员需求表：需要开发。主要由需求部门发起，需要进行审批流；
• 审批模块：另外开发的审批流模块，此文不介绍;
• 人员编制管理：需要开发。由HR进行日常维护，主要是实现影响人员需求表中部门的申请名额逻辑。PS：部门由最高一次限定，不对最底架构下的部门限制。
• 招聘：Odoo原型的模块，免费；包括岗位管理、岗位招聘业务。PS：这里会进行业务逻辑调整，招聘的人数等于需求人数时，返回人员需求表“结束招聘”状态。形成闭环结束。
• 工作岗位里的应聘人员：属于招聘管理，会进行字段需求调整；生成员工信息逻辑不变。每个应聘阶段，员工进行归档即保存人才库管理，这个逻辑不就变，为Odoo原型。

三、人员需求表及逻辑（含审批流）

四、工作岗位逻辑及调整;

1.关掉在线发布及 面试表单，如下图：

2.工作岗位表单，我有进行调整

字段的内容与人员需求表一致，主要是由人员需求表复制值过来外，保留原来重要的逻辑与字段。其中的字段与逻辑说明：

1）所有的字段（除以下）外，都从人员需求申请表传过来。且可编辑。
除了以下字段不需传过来且默认为空：工作地点。
2）原字段仍保留：招聘负责人、人力资源主管（经理）；可编辑。
招聘负责人：默认为[人力资源招聘负责人]操作人。
人力资源主管：默认为HR经理。
3）保留原来“部门”字段，值=传输“申请人部门”的值；
4）保留原来“期望新员工数”，值=传输“*拟增补额人”的值；

3.结束的逻辑有稍微调整

五、部门人员编制需求表；

六、其他

此次仅是我的方案，对于其他几支仅提供一个参考思路。毕竟，一来没有去社区查询有无合适的模块，二来由于也因为时间有限，不能仔细测试下评估方案是否最优，只是利用现用的Odoo免费的社区版进行适当的调整，以达到实现自身业务上的需求。

但是也有几点要说明下：

1.本文由上面可见，基本都不进行HR线下的业务进行完整的描述与介绍。基于这样的思路，HR在招聘到员工后，一般会进行最后一道”确认“的流程，即会拿着纸质的资料给各老板签名确认，才敢发出Offer，这个流程目前我没落地线上。或者说没有直接体现出现，其实在最后适当调整流程即可做到。

2.在丰富员工面试资料完善部分，比如员面试的内容，Odoo原型也有对应的[面试表单]进行维护，Web的形式体现（不管发给招聘人员填写或者HR在面试过程进行填写）的信息归档，这块我也在这个阶段没有开放和落地。

3.跟其他人才招聘网或其他应聘方式，我目前是没有关联进公司的员工招聘。采取手动的方式。后续倒可以优化这部分，但是这块总体上不是最主要的核心内容。所以暂忽略。

这三点，主要是因为公司的HR业务是新的流程，公司以前也是没有系统上的深沉，平时仅HR自己线下的业务跟进。所以主要的目标就先实现上线。实现公司HR流程的规范化、面试过程资料存档等业务。

七、后续

1.完成员工招聘后，会有员工基本资料的完善流程、开通账号、正式签订合同等一系列的管理。这块后续合同管理部门会描述。不过总体上也是Odoo的原型，只是我这里进行一些对HR优化和信息通知。

PS：各企业不一样，业务也许会不一样，由自身决定。

2.后续的工资管理。这块涉及的就是”正规“的HR需要的东西，这其中还会涉及到最基本的数据的统计也分析的问题。比如考勤算法与统计等。这块要等所有HR业务规范后才进行的一步动作。

END.