见过不少这样的场面：加班申请系统已经上线运行，部门群里照样有人发一句“今晚我加个班，明天补单”。管理员很头疼，觉得是推行力度不够。但往下追问往往会发现，问题出在系统本身——要么提交太麻烦，要么审批卡在半路没人知道，要么批完了数据没回到该去的地方。

卡点一：提交端不贴合真实场景

车间员工手里是手机，办公室员工手里是电脑，管理者可能两个都在用。如果系统只有PC端入口，一线员工自然绕开。移动端提交要解决的不只是“能填”，还有几件容易被忽略的事：草稿暂存（填到一半被叫走很常见）、批量提交（连续一周加班逐条填很折磨）、补单标记（事后补录要和事前申请区分开，便于后续稽核）。

多终端之间的数据同步也要经得起考验。微信端提交、PC端审批、后台出报表，这三处读的必须是同一份数据，不能出现微信端显示4小时、后台报表显示3.5小时的错位。

卡点二：审批路由没有覆盖例外情况

标准的一级审批很容易配，难的是例外。加班时长超过某个值要不要往上加一级？项目经理和部门主管同时是审批人时怎么定？审批人出差了能不能设代理人？跨部门借调的员工，走谁的路由？

这些场景如果没有在配置阶段想清楚，系统就会在实际运行中卡住，员工等不及，就回到群里喊一声。另一个常被忽略的是超时提醒：审批单停在某个人那里超过一定时长，系统应主动推送提醒，而不是等申请人自己去催。审批的时效性靠人盯，是撑不了几个月的。

卡点三：审批完成不等于流程结束

这是容易出问题的一环。审批通过的加班单，至少要完成三件事：一是回写考勤，与刷卡记录比对形成核定工时；二是把结果同步到薪资核算口径里；三是通知到申请人本人，让他知道批了多久。

少了第三步，员工不知道自己批下来几个小时，到了发薪日才发现对不上，信任度一下子就掉了。少了步，财务月底还要再核一遍，系统价值就打了折扣。

深圳市英普瑞科技有限公司在实施审批类项目时，通常会把月度封账时点作为一个节点来设计：封账之后数据锁定，后续修改必须走调整流程并留痕，这样既能保证核算口径稳定，也方便回溯是谁、在什么时候改了什么。

还有一层：审计与权限

加班数据直接关联薪酬，改一条记录就是改一笔钱。谁有权限修改已审批的单据、修改后是否留下操作日志、审批人能否看到本部门之外的数据，这些在配置阶段就要定下来。权限设得太松，事后追责没有依据；设得太紧，日常调整全部堆到管理员身上，同样影响效率。

回到开头那个问题。员工绕过系统，往往是因为系统暂时还不如发条消息省事。把提交端做顺手、把路由的例外情况补全、把数据回写的闭环合上，这三件事做到了，群里的“我今天加个班”自然会少下去。这不是推行力度的问题，是产品细节的问题。