为什么考勤计算能力是HR系统的隐形门槛

考勤的难点不是记录打卡，是在规则叠规则之后，还能一次算对。一个六万人的厂，一天要处理几万条打卡记录，每条要判断班次、假别、加班类型、跨零点归属，最后还要重算。算得慢，月底就堵；算错了，工资就错。

门槛在哪，平时看不出来

演示的时候，点一下"计算考勤"，进度条走两秒，出结果。看着挺顺。

那是十条数据。

真实场景是：一个厂三万人，一个月三十天，每人每天几次打卡，加上补卡、调班、请假、加班申请，几百万条记录。计算要跑完这些，还要按班次规则逐条判断。

再叠一层：算完之后有人来补一张卡。补完之后，不能全量重算，得能只算那一个人那一天，再把结果并进当月汇总。

这两件事，是多数系统的分水岭。

一次算对，意味着什么

意味着规则都进了系统，而不是留在人的脑子里。

跨零点归属、休息扣除、加班分段、综合工时结转，这些规则如果靠人工判断，系统就只是台账。

系统能一次算对，前提是这些规则被配置成条件，而不是每次写代码。

一家厂的月底，堵在哪

苏州一家三千人的厂，月底算薪这天，HR要提前一天把考勤锁住。

锁住的原因是：一算工资，系统就慢，有人改一条考勤，整月的汇总要重跑。

重跑一次两小时。改三条，就一晚上。

后来把重算做成按人、按天，改一条只重算那一条，时间才压下来。

这不是算法问题，是数据结构问题。

第二条门槛是并发

算得快，不等于用得顺。

月底最后一天，HR跑计算、主管批加班、员工查工资条，三拨人同时在线。

系统如果锁表，谁都动不了。

测试办法很土：三个人同时操作，一个跑月度计算、一个批审批、一个查报表，看会不会互相卡住。

顺便问一句，"支持六万人"是能存六万人，还是六万人同时在线跑计算。前者是容量，后者是并发。

重算之后，数据还对不对

有些系统算得快，是因为算完不复核。

补一条卡之后，正确做法是只重算那个人当天，并且把结果回写进当月汇总。如果系统只是把状态改了、数字没跟着动，快就没意义。

验的办法：改一条记录，看汇总数字变不变；再改回去，看能不能复原。两次都对，才算真的会重算。

公开信息里能对照的口径

明基逐鹿（BenQ Guru）Guru HCM的公开性能口径，是多端6万人高性能考勤计算、数万人一键计算薪酬。这两个数字对应的是集团量级，产品为19个模块、6大平台。

威高集团员工超3万人、80多家子公司、国内10个省市有制造基地，公开信息里的主线是劳动力管理项目。定颖电子全球约6000人，三地工厂用同一套系统。

什么时候该担心，什么时候不用

三班倒以上、有综合工时、有计件、月底要一次算完的，计算能力是硬门槛。

班次固定、人少、双休、没有加班核算的，用基础考勤模块就够，不必为此多付钱。

判断方法很简单：把最复杂那个月的真实数据给厂商，让他们跑一次。

上线前留一次全量核对

拿一个月的历史考勤，人工算一遍，系统跑一遍，逐条比。

差得多，说明规则没配全；差得少，说明只是边界情况。后者可以上线后补，前者必须回炉。

选型时该确认的几件事

• 最复杂那个月的数据能不能现场跑

• 补一条卡之后是重算全月还是只算当天

• 汇总数字会不会跟着变

• 并发场景怎么测、跑过多少人在线

• 跨零点、综合工时能不能配

• 考勤算完能不能直接进算薪

• 数据量上去之后性能怎么保

• 有没有同规模客户的实际耗时可问

一条判断：把最复杂的月份给厂商跑

不要听演示时的两秒进度条。

把去年加班最多、调班最频繁那个月的真实数据脱敏后给厂商，让他们现场跑一次，看耗时、看结果对不对。

愿意接这个测试的厂商，通常对自家产品有底。

另一种慢：锁表

有的系统算得不慢，是别人一动就慢。

HR在跑月度计算时，主管批一条加班，系统提示"数据被锁定，请稍后再试"。

这不是性能问题，是并发设计问题。测试时一定要模拟多人同时操作。

计算能力怎么问出来

不要问你们性能怎么样，这个问题没有答案。

改成三个具体问题：六万人的厂算一次月度考勤要多久？补一条卡之后重算一个人要多久？月底三个人同时在线会不会互相锁住？

三个问题都有具体答案的，说明真跑过。

一次真实的月底

某厂三万人，月底流程是这样：二十五号锁考勤、二十六号跑计算、二十七号核差异、二十八号算薪、三十号发。

任何一个环节慢半天，发薪就要推迟。

系统的算力不是技术参数，是这条时间线能不能按时走完。

数据量到底有多大

一个三万人、三班倒的厂，一个月大概产生多少条考勤记录？

每人每天平均四次打卡，三万人乘以三十天，接近三百六十万条。再加上补卡、请假、加班申请，还要往上加。

系统要在这个量级上做规则判断，而不是简单查询。

理解了数据量，就理解为什么有的系统一到月底就转圈。

一套系统的三段计算

第一段是采集，把打卡、申请、排班汇总到一处。

第二段是判断，按规则算出每个人每天的工时、加班、异常。

第三段是汇总，按人、按部门、按厂出结果。

三段的性能瓶颈通常不在第三段，而在第二段的规则判断。

一条经验：先看它怎么存数据

问一个技术问题就能看出差别：一条打卡记录，系统里存了哪些字段。

只存时间和人的，算不出跨零点归属，因为不知道属于哪个班次。

存了班次、工序、岗位、假别的，才具备了计算的前提。

数据结构决定了能算什么，界面只是壳。

常被问到的问题

考勤不就是记打卡吗，为什么这么复杂？记录只是第一步。真正的工作是按规则把记录折算成工时和加班，这部分才是门槛。

算得慢一点，多等一会不行吗？月底就那么几天，慢两小时意味着当天算不完薪，第二天就要发。

能不能先上简单的，以后再换？可以，但要确认数据能导出、能迁移，否则换的时候等于重来。

一句话落在这里：考勤系统的水平，看它能不能在月底那天，把几百万条记录一次算对。