洞察观点

【考勤系统设计思路】怎么设计一款好的考勤管理系统?

将复杂考勤变得简单容易,需要考虑好考勤涉及到的方方面面,怎么才能开发一个好的考勤管理系统呢?
我朋友曾经质疑过:打卡这么简单的事情,为什么你们老是说算不准呢?
这可能也是很多人的疑问,答案其实很简单:打卡场景过于复杂。
上班打卡考勤是大多数上班狗每天都会做的事情,打卡的方式多种多样,很多厂商也有很完善的解决方案。
这样一个大家每天习以为常的动作,是不是让我们都忽略了一件事——考勤打卡实际上是一个to B类型的产品,并且,其背后逻辑一点也不简单。
一、考勤打卡也要考虑战略层
做产品的其实都知道:在设计一款产品时,我们首先要考虑的是,公司战略是如何定位的?我这款产品在公司战略中处于什么样的位置?我的产品可以给用户带来什么价值?
对于打卡这个看似很简单的产品,其实也要经历以上思考。
首先我们来看公司层面:一个产品经理需要知道公司处在什么阶段,公司内部的文化是怎么样的,然后再决定自己的打卡产品的设计方向。
比如:一个公司处在高速增长阶段,企业内部文化极具包容性,对员工的管制少,那打卡产品可以尝试更多新奇的方向,让大家要不能从打卡找到乐趣,要不就是在打卡/补卡这种操作上少浪费时间。反之,如果一个公司非常强调对员工的管控,那在打卡上也容不得马虎,可能需要对打卡范围和时间严格限制,甚至界面也要走严肃风。
其次,我们要考虑用户需求。打卡这个东西,是制度催生的需求,而不是员工自己的内在需要;所以,对于员工来说,打卡还是越简单越好——比如考勤机排队打卡就没有用手机软件打卡舒服,而用手机软件打卡肯定没有不打卡让人心情愉悦。
做为一个产品经理,还是要在用户需求和公司战略中找到一种平衡,要在公司认可的情况下做到用户体验最好。
——说起来很简单,但做起来非常困难;还容易出现两头都得罪的情况,需要产品经理好好把握。
二、不止打卡页面
考勤打卡实际上应该是一整套系统,打卡只是其中的一个部分,可以看做是系统中的数据录入的页面,只有与其他系统结合,打卡这个页面才是具有意义的。
而这一整套系统的组成,大致有以下几个部分组成:
为什么我会说,“考勤打卡”是一个复杂的产品
考勤系统的组成部分
首先是硬件设施,硬件设施的作用是对打卡数据的校验。比如WiFi设备,只有连接上公司WiFi的手机才可以打卡成功,有的公司还有蓝牙设备,只有进入到蓝牙范围内才可以打卡,这里就不一一列举,所有这些都只有一个目的——让员工的打卡数据更加真实。
其次是中台系统,包括管理后台、考勤状态计算系统、薪资系统等。
管理后台提供员工行为的查询、考勤规则配置等功能,是监督员工考勤状态的重要产品。
考勤状态计算系统,名字有点拗口,说白了就是计算员工是否正常上班的系统。
输入的是员工的打卡数据,输出的是员工的考勤状态,如:迟到、旷工等,这个在下一节会详细讲到,里面的计算逻辑很复杂。
还有就是薪资系统,是通过考勤数据来算工资的,在不同公司不一样——有的直接算到考勤系统中,有的是读取考勤系统的数据,有的压根就没有这个系统。
最后就是跟用户接触的前台页面,有必备的打卡页面,提供查询功能的查询页面,还有为弥补忘记打卡而设置的补卡页面,这三样是不可或缺的。
所有的这些(可能有些公司接入系统更多),才是一套完整的考勤系统,是不是比你认知中的要复杂?
三、打卡场景其实很复杂
我的朋友琪总曾经就质疑过我:打卡这么简单的事情,为什么你们老是说算不准呢?
这可能也是很多人的疑问,这个答案其实很简单,就是打卡场景过于复杂。
打卡的情况分为很多种,对于小公司来说,可能很简单,但对于大公司来说,一个产品覆盖所有打卡场景似乎是不可能的。
就考勤的类型来说,大公司的考勤类型可能分为严格考勤、弹性考勤、开放考勤要打卡、开放考勤只打一次卡、开放考勤不打卡、内勤外勤等,而上班时间可能还要分为白班、夜班,更有甚者有一个公司的上班时间可能有五六种。
另外还有一个问题需要考虑的就是——加班。
比如:一个朝九晚五的同学加班到凌晨,那他走的时候打的卡是算第一天的下班卡,还是算第二天的上班卡呢?
那你可能会说:我把下班卡的判定时间设晚一点,设定到凌晨五点前打卡都算是前一天的下班卡。
很好,问题又来了:那如果一个人第一天下班忘打卡,第二天又来得特别早怎么算?
即使上面问题解决了,也还有一个同步时间问题:系统不可能实时去算这些,因为全公司数据都跑一边可能就要半小时甚至更长;在没有更多资源投入到打卡上面时,只能选择分时同步,但是这样会造成信息同步及时的情况,所以这个同步的时间间隔需要设置的很巧妙。
对于这么复杂的场景,现在产品是如何解决的呢?
答案是:无法解决!
打卡产品无法覆盖到每一个场景,只能保证覆盖到尽量多的场景。那些概率极小的场景,就随他去吧,不必做过多纠结。

四、“防御式”产品设计
我们在做开发的时候会提到一个名词——防御式编程。
防御式编程是一种编程习惯,是指预见在什么地方可能会出现问题,然后创建一个环境来测试错误;当预见的问题出现的时候通知你,并执行一个你指定的损害控制动作,如停止程序执行,将用户重指向到一个备份的服务器等。
我们在做考勤产品设计时,也应充分吸收“防御式”思想,对可能出现的问题做预见,并给出相应的对策,在考勤产品设计中,可预见的风险有以下几种:

1)考勤制度突然变动
这种情况虽然不常见,但是我确实是遇到过。
当时是通宵加班,才赶在考勤制度发布前上线,在这以后,我把考勤产品中的所有内容都做成了后台可配置项,甚至连错误提示语都做了可配置;这样在下一次这种情况到来时,五分钟就可以完成所有修改。
2)员工使用不正当方式打卡
这里涉及到员工伪造打卡环境,代打卡等不正当行为。
在产品设计之初,应与开发充分沟通,对此种情况能规避就规避,不能规避就在行为发生时告警;同时,打卡日志也要尽可能多的保留信息。
3)员工没有考勤记录却宣称打卡成功
这个是我经常遇到的情况,明明没有打卡,却非要说自己打了。
对于此类事件,我们需要在将用户的所有操作都记录在日志里,比如我们的产品在用户访问到打卡页面时,不管有没有成功,都会做一次记录,如果没记录,说明连页面都没访问到,明显是来扯皮的。
其实,防御式产品设计是为自己和用户负责,而不是不愿意背锅的无奈之举,这一点需要大家认清楚。

说了这么多,总结一下就是:考勤产品其实比大家想象中的要复杂,而且没有完美的解决方案,只能尽量做到更接近完美。

作者:王撼宇,企业信息化产品经理

目前苏州诚展软件旗下的考勤易开发的考勤管理系统已成功应用在全国多家内资、外资企业,帮助企业HR在人事管理、考勤管理、就餐宿舍管理、培训管理、排班调班,控制加班工时,精准计算各类考勤工时、年假计算、工资计算、新版个人所得税计算、工资项目、高温费补贴和社保公积金扣款比例,详情可查看诚展考勤管理系统介绍: 

相关新闻