如何设计编制计算规则?设计思路是什么?

0 评论 6307 浏览 11 收藏 16 分钟

本文重点介绍了编制管理中核心的编制计算规则的说明,其中需要深入业务场景,了解到各单位编制分解的广度和深度的不同,并对编制的占用和释放规则的统一规划,尽量在满足业务整体编制管控的大前提下,进行编制计算规则中数据指标的定义统一化,降低系统开发难度。

笔者作为一名B端产品经理,主要负责人力资源管理系统,这篇文章将向大家简明扼要地说明编制管理中编制计算规则的设计思路,供大家学习参考。

一、编制管理业务说明

通俗地来讲,编制管理就类似于“萝卜占坑”的游戏,企业给每个部门挖了一定数量的坑,员工就相当于萝卜,一个萝卜一个坑,在职的员工就是已经埋在土里的萝卜,离职的员工就是拔走的萝卜,编制管理一方面就是要明确挖多少坑,另一方面就是计算好哪些萝卜已经占着坑、哪些萝卜即将进坑,哪些萝卜即将拔走腾地方。

企业的人力资源管理非常重要的就是对于员工的管理,需要清楚地知道某员工是哪一类员工,这类员工最多可以招多少人,享有什么权利和义务。所以编制管理是企业人力资源规划的重要组成部分,同时也是招聘、入职、调动等核心人力资源业务的前置要素。

编制管理的上游是企业对于预算计划的制定与分解,其中人力成本是企业核心成本之一,企业对于成本与预算的计划制订、规范化管理之于企业的生存和发展尤为重要。

二、编制管理介绍

1. 编制管理系统概述

编制管理横跨组织、招聘、人事三大模块,包含企业年度编制计划制定、编制层级分解下发、编制需求的上报以及编制情况的调整是企业各级单位均涉及的工作内容,且编制类型和编制计划等要素在不同单位存在一定差异,需兼顾整体与个性需求的平衡。

编制管理组织模块主要实现的编制的下发、上报、调配,属于编制数据源头;招聘模块和人事模块主要承载核心业务流程,根据组织或者岗位的编制情况以及相应的管控规则,对于招聘环节、入职环节、调动环节等人事业务的发生进行管控,属于基于编制数据和管控规则赋能业务。

由于编制管理涉及模块及规则众多,管控逻辑也纷繁复杂,本文仅说明编制管理的核心——编制计算规则。编制计算规则分为两个步骤,第一步是对于编制指标的定义,第二步是基于编制指标,计算剩余编制数量的公式。编制计算规则基于业务逻辑进行设计,目的是计算出企业内部某部门或者某岗位剩余的编制数量有多少,用于限定用人部门进行招聘、入职、调动等业务是否可以进行,在相应的业务环节当中通过校验编制剩余数量,对业务流程进行阻断性的管控或者提醒。

2. 数据指标

人力资源管理系统当中,存在多种用工形式的员工,包括合同制员工、实习生、劳务派遣人员、劳派人员、退休人员等等;这些员工又可能处于多种状态,包括处于在职状态、离职状态、退休状态、轮岗状态等,也有可能处于多种业务流程中,包括招聘流程、入职流程、调动流程、离职流程等。纷繁众多的业务流当中,基于编制的管控就尤为重要。

以员工入职为例,如果不对于部门的员工编制数量进行管控,那用人部门可能会面临着大批量的员工入职,极大地抬高了这个部门的人力成本,并且极易造成组织混乱,打破原有的组织管理方式和工作节奏,进而降低生产效率,所以编制管理是十分重要的人力资源管理内容。

编制管理不是因为企业上线HR系统来衍生出的新型业务场景,而是始终贯穿企业生命的重要业务。一切的设计都要沉入到业务场景当中。我们之前知道了人力资源团队为什么要去做编制的管理,那我们就要进一步去思考具体要管理哪些呢?下边将尽量生动形象地说明人力资源业务的场景和相应引发的思考。

首先因为公司业务发展情况,产生了组织的分层拆分,让更细粒度的组织专注于某个业务,那基于每个组织所属业务的差异,又会造成用人的差异化。有的部门需要大量的IT人才来做核心的内部系统,那这个部门就应该设置更多的编制来适应其业务发展需要;有的部门仅需要几名UE设计师来对接各个业务线,那这个部门仅需要设置少量的编制就能满足它的业务需求,所以每个部门基于业务情况会有不同的编制需求,这样我们自然地提出一个问题,某部门/岗位总共要有多少编制?这就需要人力资源部和用人部门进行协商,来制定部门的编制数量。

制定好部门的编制数量之后,就需要看到编制已经被占用的有多少,我们在对外招聘的时候就要减去这一部分已经被占用的,所以这又产生另一个问题:这个部门/岗位有多少员工已经占用了编制。那是不是用编制的总数减去已经占用编制数就是我们能够招聘的人数了呢?

设想有一名候选人,已经给他发放了Offer,约定好了下星期来入职,那这一封Offer就要提前预定好人家的位置,不然候选人来了都不占位置,谁都不愿意。进而引申出另一个问题,哪些员工即将占用编制,这个数量也是十分重要的,假如有3名员工拿了Offer并且即将入职了,那再对外招聘的时候招聘人数就要减去3,给人家占上位置,这个就是在途增员人数。

我们再思考,如果有在途增员人数,是不是也有在途减员人数呢?比如说一名员工要离职了,审批全都同意了,下周直接走人就可以了。我们需要再招聘一个人来接替他的工作,如果这个时候即将离职的员工还占用着编制,那我们是不是招人就会遇到困难呢,所以就应该给离职审批都通过的员工释放掉他的编制,所以这就是在途减员人数。

(1)分配编制数量

部门/岗位总共有多少编制?这个问题其实就是说我们到底最多能招多少人来工作,也就是企业给挖了多少坑能放萝卜。例如一个技术团队招聘程序员,不能无限制招聘,会大幅增大企业的成本,那这个时候就需要人力资源部给这个团队设置一个上限,上限的设置是由用人部门和人力资源部协商,基于部门的业务发展情况进行的统一规划设立的。上限就说明了这个团队最多能有多少人,再多就不能再进人了。那这个技术团队的人数上限也就是人力资源部分配的编制数量,所以这里我们称之为分配编制数量

(2)已占编制数量

哪些员工已经占用编制?这个问题就是企业挖的坑里边,有几个坑已经被萝卜占上了。同样还是那个技术团队,这里边在职的员工肯定是先把编制占下了,所以我们称之为已占编制数量

(3)在途增员数量

哪些员工即将占用编制?这个问题就是有哪个坑被萝卜预定了。例如技术团队里边即将来一个新人,已经给人家发了Offer了,这时候就得给人家预留一个坑。还有可能要从另一个产品团队调一个员工来技术团队,两边的领导都审批通过了,这个时候也得给人家预留一个编制,所以我们称之为在途增员数量

(4)在途减员数量

哪些员工即将释放编制?这个问题就是有个萝卜要被拔走了,这个坑能腾出来放别的萝卜了。例如技术团队有名员工要离职/退休,离职/退休的审批都通过了,定好了再过一周就撤了,所以我们称之为在途减员数量

(5)剩余编制数量

部门/岗位剩余多少编制?这个问题就是假如有个萝卜要来占坑了,那我们得看看有没有坑剩下的能给他用,所以称之为剩余编制数量。

3. 编制计算逻辑

编制管理顾名思义是基于编制进行人员的管理,组织模块基于组织架构树分配好部门/岗位的编制情况,招聘模块和人事模块又会基于员工入职/调入的部门/岗位剩余的编制数量判断是否还能继续招人,所以招聘岗和员工关系岗对于编制的管控核心关注的数据指标就是【剩余编制数量】以【剩余编制数量】为出发点,可以得出以下公式:

【剩余编制数量】=【分配编制数量】-【已占编制数量】-【在途增员数量】+【在途减员数量】

4. 编制数据场景差异化的指标计算规则

我们之前提到过,编制管理是一个横跨组织、招聘、人事三大模块的功能,其中组织模块是编制的数据源头,招聘和人事模块又基于编制数据进行管控,那编制数据的不同场景也就会影响后续编制计算公式中各项数据指标的规则。

组织模块中由组织管理岗进行编制数据的层级下发,编制的颗粒度可以到达岗位级别,也就是编制的数据可以由组织架构树的根节点一直分配到末节点,即充满整个组织架构树的一根树枝。但是需要考虑到实际的业务场景中,不同的单位/组织对于编制的使用情况差异化较大,所以并不强烈要求每个岗位、每个部门都进行编制的分配,那么这些没有被分配编制的部门/岗位怎样衡量【剩余编制数量】这个指标呢?

基于对编制数据场景的调研,有如下三种编制数据场景(红色标识岗位为进行编制检查的岗位)。

场景一 岗位已分配编制

对于“岗位1”已经分解编制的情况下,编制的计算公式如下:

【分配编制数量】=岗位1 的分配编制数量

【已占编制数量】=岗位1 的在职员工数量

【在途增员数量】=岗位1的已发放Offer尚未入职人数+调入审批中人数

【在途减员数量】=岗位1的调出、离职、退休审批结束未生效人数

场景二 岗位未分配编制、但其上级组织已分配编制

【分配编制数量】=组织1 的分配编制数量

【已占编制数量】=岗位1 的分配编制数量+组织2的分配编制数量+岗位2、岗位3、组织3的在职人数

【在途增员数量】=岗位2、岗位3和组织3的已发放Offer尚未入职人数+调入审批中人数

【在途减员数量】=岗位2、岗位3和组织3的调出、离职、退休审批结束未生效人数

场景三 岗位未分配编制、且其上级组织仍未分配编制

【分配编制数量】=子公司的编制数量

【已占编制数量】=岗位1 的分配编制数量+组织2的分配编制数量+岗位2、岗位3、组织3的在职人数

【在途增员数量】=岗位2、岗位3和组织3的已发放Offer尚未入职人数+调入审批中人数

【在途减员数量】=岗位2、岗位3和组织3的调出、离职、退休审批结束未生效人数

(对于该种情况,如果岗位上级组织的上级组织仍未分配编制,则组织架构树爬树最顶端为子公司层级)

以上三种组织编制数据的场景,说明了实际的编制管理业务中,不同的子公司、单位对于编制管控的业务管理方式和深度不同,我们的编制指标也要相应于不同的业务场景进行差异化的调整。

 

本文由 @Crystal爱猫咪 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!