去年夏天，财务部小林休完产假回来，发现自己的年假余额比入职五年加起来还多。系统显示她有47天未使用假期——这显然不对。更奇怪的是，隔壁项目组三个同事合计‘富余’了89天假期，而行政却说今年预算根本没批这么多带薪假。

这不是bug，是规则打架的结果。

我们用的是一套老OA系统，人事模块和考勤模块是两个不同年代接入的。员工晋升后年假天数自动增加，但系统不会追溯补发之前的差额。于是，每当有人从5天涨到7天年假，系统就只对未来的假期生效，过去的‘应享未享’就成了死账。可不知道哪个程序员又加了个‘累计结转’逻辑，把这些本不该存在的天数悄悄记进了账户。

最开始没人注意。直到有次季度人力分析，HR想看看‘人均休假时长与离职率的关系’，导出数据一看，差点以为自己看错了。有人一年休了63天？再一查，人家只是断续请了几次病假，被系统误合并成了‘连续假期’。

问题浮上来后，我们决定做一次‘假期清算’。原计划是让IT写个脚本批量修正，但试了两次，不是漏修就是误伤。比如有个员工中途调过部门，年假规则变了两次，光靠字段匹配根本判不准。

这时候，我想到之前在另一个项目里用过的蓝点通用管理系统。它不像传统软件那样把‘请假管理’做成固定功能，而是让你自己搭逻辑。我们导入了原始考勤数据，然后一步步重建规则链：

1. 按员工ID拉出所有职级变动时间点；
2. 对照公司《年假实施细则》建立版本化规则库（比如‘2020年前入职满3年享7天’这种）；
3. 用时间轴对齐每个员工在各阶段应享天数；
4. 最后跑对比报表，标红差异超过3天的异常项。

整个过程像拼图。最麻烦的是处理跨年度结转边界——有些年份政策不允许 rollover，但系统仍自动 carry forward 了。我们加了个‘政策有效性开关’，给每条规则打上生效时段标签，这才理清头绪。

有意思的是，在核对过程中，我们发现了另一种‘软性侵占’：不少主管习惯性拒批下属年中请假，理由是‘项目关键期’，结果年底大家集中休，导致团队节奏被打乱。系统导出的‘请假密度热力图’清楚显示，每年11月到12月请假占比高达68%。这不是制度问题，是管理惯性。

我们没直接改审批权，而是设了个‘预警提示’：当某员工已积压超15天假期，且近6个月未休满应有额度的50%，系统会在其主管提交项目排期时弹出提醒。不强制，但可视化压力往往比制度更有用。三个月后，均衡休假比例上升到了52%。

还有个小插曲。保洁王阿姨有次误触打卡机，把自己‘请’了三天事假。按流程得走人工申诉，但她不熟悉系统。我们在蓝点上加了个‘异常模式识别’：连续两天无打卡记录+无请假申请=自动触发核实任务，派单给行政专员电话确认。这类‘低技术用户友好设计’后来被推广到了其他边缘岗位。

现在回头看，那次假期混乱反而成了一次组织记忆的清洗。我们不再盲目相信系统里的数字，而是学会问：这个值是怎么算出来的？依赖哪些前提？有没有例外路径？

最近新来的实习生问我，为什么我们要花两周时间‘修理’已经发生的错误。我说，不是为了纠正过去，是为了让下一次规则变更时，系统能真正理解‘人’的逻辑，而不是仅仅执行‘程序’的逻辑。