人事部门的考勤与排班管理

考勤与排班为什么该待在一起

在多数公司里，这是两套在不同时间因不同理由买回来的系统。排班进来，是因为有人需要一张班表。考勤进来，是因为工资需要工时。两者持有互相重叠的数据，在边缘处彼此打架，于是人事里总有一个人，把每月最后一周花在判断哪一边才是对的。

这种对账不是小活儿，而且它什么也生产不出来。它是纯粹的摩擦，来自一次本来就不必存在的数据切分。

一条记录，三种读法

把排班和考勤记录挂在同一名员工身上，等于删掉了第二份副本，也就顺手删掉了对账。主管把它读成班表。员工把它读成自己这一周。工资把它读成工时。没有人需要重新誊一遍。

顺带地，最值钱的那个数字也白白到手了。计划工时与实际工时之间的差额，落到每个人、每个部门头上，是人事手里最有用的一个数：它能在排班问题变成人手问题之前把它挑出来，而它只有在两个数字并排存放时才存在。

和现实对得上的部门与地点

报表的上限，就是它底下那套结构的上限。按组织真实运转的样子去建部门和地点，而不是按某个系统期待的样子，才能让一个关于缺勤的问题，在别人真正会问的那个层级上答得出来。

一条记录。三个读者。不用重敲。

对着真实补位批出去的休假

休假审批是两套系统分家时损害最显眼的地方。申请在这一边被一个看不见那一边排班的人批掉，等到第三周，部门才发现五个人里有三个同时不在。

当申请与班次住在同一份日历里，这件事就从事故变成了决定。批的人看得见还有谁休假，看得见班次有没有人顶，也可以把申请压着，直到补位落实。剩余天数留在员工记录上，算术就不必另开一张表格。

让工时不经改动地走到工资

从时间记录到工资核算之间，每一个手工步骤都是一次把错误放进去的机会，而工资出错要付两次代价：一次是改正，一次是信任。把记录下来的数字直接导出，休息已经分开、加班已经标好，重敲这一步就没有了。

想把核算放在同一套系统里的公司，可以按每位员工每月0,50美元加上薪资模块。已经有稳定薪资服务商的公司通常用不上它，导出就够了。

它不做的事

边界值得明说。这不是一套完整的人力资源信息系统。招聘、入职材料、绩效周期和人事档案属于人力资源系统，也留在那里。落在这里的是运营层：谁在什么时候上班，他实际做了多少，以及这要花多少钱。

工资出错要付两次代价：一次改正，一次信任。

人事总会被问到的三个问题

缺勤、加班和产能。每个人事部门都会收到这三者的各种版本，多半来自一位周四之前就想要数字的财务负责人。当三个答案都出自同一批记录下来的工时时，它们彼此对得上；而当它们来自三堆不同的数据时，这一点根本没有保障。

一个季度里按部门看缺勤，能看出压力在哪。按部门看加班，看出的是人员配置模型哪里不对，而不是哪里的人更卖力。把编制和实际工时并排放，就知道定员是否配得上这些活。

不当成项目来推

碰到工资的系统，通常以项目的形态到来：一个指导小组，一次数据迁移，一份培训计划，以及一个推迟过两次的上线日期。这种分量配得上人力资源信息系统，用在一张班表和一台打卡机上就过头了。

真正管用的路子要窄得多。一个部门，一个月，和今天在用的东西并排跑。如果排班更容易发布，工时不用重敲就到了工资那边，理由自己就立住了，推广也就是把一件已经跑通的事复制一遍，而不是幻灯片上的一份计划。

主管需要学什么

如果工具的形状对，几乎不用学。发布一周排班、批一个申请、读一张报表，是一线主管要做的三件事，每一件都该经得起只讲一遍。凡是需要培训才能发布班表的东西，一个季度之内就会被人绕开。

不用立项就能开始

Shifton对10人以内免费且没有时间限制，这足够让一个部门在有人写采购理由之前先规规矩矩跑起来。排班、基础打卡、手机应用和报表都在这一档里，模块可以从每位员工每月0,50美元起一个一个加，每个都带最长60天的试用期。