考勤排班文档格式.docx

考勤排班文档格式.docx

《考勤排班文档格式.docx》由会员分享，可在线阅读，更多相关《考勤排班文档格式.docx（5页珍藏版）》请在冰豆网上搜索。

00之间的任一时刻上班，11:

00-13:

00的任一时刻下班，但要保障上满4小时。

这类型的班段可称为自由班段。

3、休息时段在一个班段内部，允许存在多个休息时段。

4、用餐时段同休息时段类似。

用餐时段可分为两类：

固定用餐和自由用餐，举例说：

规定中午用餐11:

30-12:

30，叫固定用餐，允许中午11:

00之间用餐，但规定用餐时间只能是1个小时，叫自由用餐。

如果规定了员工可以自由选择11:

0011:

15-12:

1511:

30之间的一个时段用餐，则可称为浮动用餐。

由上面4个基本元素组合而成的班次，称为基本班次，其中休息时段或用餐时段是从属于某个班段的，这样组成的班次，能够适应大部分的情况。

班次除了规定上下班时间规则外，还要定义该班次中，怎样才算迟到早退，怎样才算缺席旷工，还有其它什么异常等等，如含用餐时段的班次，就有用餐超时的异常。

（每个班次都定义迟到早退缺席旷工等设定，会比较啰嗦，可做个全局默认值，如果班次中没有设定就使用默认值）

二、特殊班次

1、休息：

休息作为一个特殊的班次指明了当天不用上班。

注意指定休息并非指定当天是周日或节假日，这由其它地方定义。

指定休息仅仅是指定当天不用上班。

2、自由上下班：

规定员工当天7:

00-19:

00可自由上下班（多个班段），只要保障上足8小时即可，或者上了多少小时班算多少。

周六周日自由加班就是属于这种情况。

3、互斥班组：

将多个互斥的基本班次组合在一起，构成一个互斥班组。

所谓互斥的，是指各个班次其上下班时间相互不交叉。

计算考勤时由系统自动识别匹配是哪个基本班次。

这对于两班倒或三班倒的情况下可以有效地减少排班的工作量。

不建议使用互斥班组来进行排班，因为在员工多打卡或少打卡的情况下，同时加班，请假会让班次是的刷卡点改变，这都使得智能匹配过程容易产生错误。

明确排班则没有这类错误。

考勤应是非常严肃的，哪怕是0.0001%的错误，都会给你的考勤软件蒙上污点。

4、动态班次这是一种非常特殊的班次。

正常情况下，班次的定义是预先定义的，而动态班次的班次定义是由程序动态生成的。

好像这不好理解，举例说，学校老师按课程表上下班，上课前30分钟要签到，下课后即可下班，没课可以不来。

此时可依据课程表动态生成一个基本班次来参与考勤计算。

如果不使用动态班次，则需要预定义很多个基本班次，而且也加大了排班的难度。

很明显，这种班次需要二次开发定制才能使用。

三、“工作天”在班次中的重要性

班次解决了员工当天该如何上下班，排班指定了员工当天上哪个班次。

这个天并非我们时常说的24小时的一天，而是“工作天”。

一个工作天可能不止24小时。

班次中定义工作天的起止时间点，加班可能会改变该时间点，从而使得一个工作天实际上不止24小时。

“休息”作

为一个特殊的班次，其不用指定工作天起止点。

班次中如果不定义工作天，那么对于跨天加班及连续上班36小时的现象就不好处理。

这里说一下员工连续工作36小时的现象（变态吧），例如：

两班倒时，1号上夜班，一直加班到2号，然后接着上白班，2号下班后又加班。

好像说，这不可能吧!

我说说我知道的比较合理的解析。

一种情况是下班后安排几个员工到医院守护病人，然后第二天继续上班，自然得付给员工加班费了。

其实并不是那名员工强壮得变态，他们可以睡觉的。

另一种情况是，安排员工24小时待命，机器一好就开始生产，自然这也是得给员工加班费的。

所以，面对异常现象时（:

考勤排班），不要盲目下结论，调查分析后更有发言权。

对于该异常，应该将加班时间分配到相应的工作天去，这也需要工作天定义。

定义了工作天，考勤体系更为完整。

四、用面向对象的类来因应企业班次的发展

以上所说的班次，能对应企业中的普遍情况，但就能适应企业中的全部情况了吗？

那肯定是不行的，随着企业的发展与需求的变化，班次也将随着变化，但无论如何变化，总要规定员工是如何上下班的，如何打卡的，怎样才算是异常等等信息，对于考勤计算来说，这个班次又是如何匹配刷卡的，如何匹配工作天的，等等信息总要在班次中定义，排班也一样，无论采用何种排班方法，总得给出当天排的是什么班次。

用写SQL过程来计算考勤过程的方法，因为其对模块化及面向对象均不支持，在需求发生变更时，改动代码或看别人的代码都将变得无比艰难。

用面向对象的软件方法可以在企业有新的班次类型出现时，轻松面对，而无须对软件大动干戈。

用面向对象的方法则需要建立一个正确的考勤模型体系，只要考勤模型不变，变化就尽在掌握中。

四公休作息日

作息是每个人所必需的,

五调休

班次及排班对于考勤有着重要的意义，是计算考勤的基准。

考勤软件是否好用，排班是否好用就占了很大的比重。

1、群组排班与个人排班的关系。

不同的软件其排班实现不大一样，一般分为群组排班及个人排班，排班逻辑是个人排班优先于群组排班。

对于群组的概念，有些软件直接用部门替代有些则有专门的考勤班组概念，无论如何做，都是一个员工集合也就是Group这个概念，个人排班作为特殊情况对待。

其当天排班过程则是这样：

如果当天有做个人排班，则以个人排班为准，否则以群组排班作为当天班次，如果群组排班也没排，那么就依全局设定来处理这个异常，没排班的可以设定一个默认班次，或者设一个部门默认班次或者直接发出异常，总之在考勤计算前要确认当天所上班次，我是反对智能匹配班次这个概念的，因为考勤是个很严肃的话题，就算你做到了99.99%成功匹配，但就是出现一个错误，就需要人工来做全部检查。

2、异动与历史记录对排班的影响。

一个例子就是：

员工从排班组a调入排班组B，那么其班次也会跟着改变，计算时得考虑这些因素。

类似这样的例子有：

员工部门调动对于统计部门每天人数的影响，薪资异动对于每月薪资计算的影响。

3、数据的来拢去脉能够展示出来给用户看，回答为什么员工当天上的是这个班次，打了这些卡后，为什么得到如此计算结果。

4、个人月排班查询：

数据来源是群组排班与、个人排班、加班、请假及异动记录，依据预定的规则计算出员工当天排班然后展示出来给用户看，”加”表示当天有安排加班，”假”表示

当天有请假，”离”表示当天已离职，”未”表示当天尚未入职，并提供快捷的方式查找到相应的记录，以做到有理可依有据可查。

个人排班与群组排班具有类似的界面及批量排班功能，目的是减少排班工作量，让软件更人性化一些。

5、个人考勤明细：

考勤计算结果与相关考勤数据展示出来，让用户明白刷了什么卡，得到什么样的结果，力求做到数据透明化。

解决几个问题：

1）当天该员工是否应上班？

这由排班系统来排定。

2）应该什么时候上下班？

这由班次定义指定。

3）打了什么卡？

这通过自动采集考勤机数据得到。

4）计算结果是什么样的？

为什么是这样?

将计算结果显示出来，并支持相应的分组统计。

能方便地过滤出每一天的异常人员，并提供方便的途径回答员工的考勤疑问。

排班系统与考勤计算的关系

排班系统与考勤计算其实关系不大，也就是考勤计算只需要排班系统告诉员工当天排的是哪个班次就行了，具体如何排班，如何倒班则与考勤计算无关。

理解这一点就可以将排班系统与考勤计算独立开来。

排班系统的目标是更好地真实地反映企业中排班的实际情况，企业中排班的主要对象是：

1、人。

2、班次。

3、倒班规则。

下面分开来说：

1、人，要解决多人同时排班的问题。

最简单方法是手工进行每人每天的排班，加一个批量处理功能来解决多人同时排班的问题。

这里说另一种方法：

将人归入群组，然后对群组进行每天排班，特殊的人员进行个人每天排班。

也就有群组排班与个人排班同时存在，匹配逻辑是个人排班优先于群组排班。

同时群组排班及个人排班都应该有批量处理功能。

对人分群组进行群组排班的方法比较贴近千人以上的企业的实际情况，能清楚地反映当前群组的班次。

其带来的问题是员工归属群组的历史记录问题，这个问题要处理。

2、班次，班次的种类及具体班次的定义请看另一个文章，这里只是提出排班时，要对所排班次的合理性做出检测并警告，主要是相邻天的上下班时间交叉问题，特别是1号上夜班，2号上白班这种情况。

当班次很多时，一般会对班次进行分类，常有以下分类：

1、按部门分。

2、按使用性质分：

常用班次，临时班次，一次性班次等。

分类后能很容易就能找到相应的班次，不用记住班次的名称或编号。

3、倒班规则，如果做好了群组排班与个人排班，就算没做倒班规则，对千人左右的厂也够用了。

但要应付更多的员工时，倒班规则可以帮助HR人员很快地生成当月排班表。

常见的倒班规则有：

两班倒，三班倒，倒班时间则有：

按月倒及按周倒，或者自定义倒班日期。

倒班规则挂在员工考勤群组中，不同的考勤群组指定不同的倒班规则，这样就可以快速生成群组排班表。

快速生成一个群组排班表，再由HR人员手工做少少修改或不用修改就可以完成排班，这可以减轻排班难度。

4、员工排班表的生成。

排班表决定员工最终排定班次，注意：

该表不一定存在于数据库中，至少在我的设计里，该表没有存在于数据库表中。

它是排班系统动态依据“群组排班表”“个人排班表”“个人历史记录”计算而得出的。

目前我设计中“倒班规则”则是用来快速生成群组排班表，减轻排班工作量的，与排班表生成逻辑无关。

如果要做得更复杂一些，也可以在将“倒班规则”考虑到排班表的生成中去，那样的排班表生成逻辑就复杂很多了。

我认为：

将“倒班规则”只用作快速生成群组排班表，不计入排班表生成逻辑中是一个足够好用的方案，系统不需要再复杂化。

5、关于自动侦测员工当天班次。

自动侦测员工当天班次，作为一个功能存在，做成“侦测可能的排班错误”，并提供对应的可能班次。

用以方便检测排班错误。

还是不赞成用自动检测到的班次来替代排班的方案。

因为那不能回答：

当天员工是否应该出勤？

（不用出勤也就没有旷工缺席了。

）

关于考勤有很多很多的话题与规则，因为其复杂与易变，考勤软件走的是螺旋上升的发展道路，程序员的每一次努力都让软件更强壮易用，所以最好用面向对象的方法来开发考勤软件。

至于数据库表设计及具体程序对象接口代码，我没准备这方面的内容，至于用户操作界面如何才易用，那又是另一个话题了。

思想与解决方案说出，代码就是次要的了。

篇二：

排班考勤方案

临沂市人民医院oa排班系统推行方案

一、现行考勤概述

目前我院考勤模式采用的是原始的人工统报，由各科考勤员每月初统计上报员工出勤天数。

由于我院排班复杂且人员流动频繁，错报漏报现象频繁，导致考勤统计工作效率低下。

为满足日益迫切的精细化管理需求，拟推行以oa排班为技术支撑，通过排班信息自动抓取来进行出勤统计的排班考勤模式，以实现及时精确的考勤统计，减少临床一线的考勤负担，提高考勤管理工作的质量和效率，为打造数字化、精细化的管理模式奠定基础。

二、排班考勤初步设想

各考勤单元每周根据规范的操作要求在oa排班系统进行排班和请销假管理，oa系统在月末即可生成当月考勤报表和请销假汇总，并发布在用友员工自助系统。

根据权限设置来实现不同人群的查询需求，即职工个人可在每月1-3号在自助系统查询个人上月出勤和请销假情况，考勤员可查询单元明细，医疗区院领导、财务办、综合办可查询医疗区明细，总院领导班子、人力资源部、财务部可查询全院明细。

如有异议，可在5号前通过排班员向人力资源部提出修正申请，按规定程序核实后可以进行修正，从而实现以员工自我监管、自我负责为主的考勤模式。

人力资源部整理汇总后，于6日报往

财务部门用于绩效等薪资待遇的核算。

三、推行方案

鉴于考勤结果涉及全院职工的切身经济利益，关系到全体职工对医院管理工作的整体满意度，本着科学稳健、方便临床的原则，现提出如下方案。

第一，梳理排班单元，拟定班种目录

在结合目前考勤模式的基础上，理清考勤单元下属的排班单元，考勤单元用于核算，排班单元用来排班，做到医护分开，各负其责。

结合前期班种的梳理情况，通过归纳和简化，建立起标准化的班种类别明细。

第二，抽取典型科室，试行排班系统

前期工作完备后，在各系统选取典型科室进行试点，以测试排版考勤的可行性和数据的可信度。

期间由人力资源部根据考勤管理工作的需要提出具体需求，网络信息部负责根据需求系统功能开发，各主管职能部门负责相关科室的排班审核。