首页 /场景分析 / AI给老板的幻觉：为什么IT不能自研考勤系统？

AI给老板的幻觉：为什么IT不能自研考勤系统？

盖雅工场2026 年 07 月 16 日

随着AI的迅猛发展，一些企业内部的IT同仁，也多了一层新的困扰。

近期跟几位客户聊下来，听到一个挺一致的说法：老板觉得现在AI写代码很厉害，两周就能跑出一个能看的demo，何必花大价钱外采。但就他们实际用AI的情况而言，用AI写出来的系统，demo阶段跑得好好的，怎么一到真实场景就卡住了。

在盖雅的客户里，不乏从自研走到外采这一步的企业，回头聊起这段经历，说法出奇地一致：以为考勤很简单，没想到复杂性那么高。AI确实降低了写代码的门槛，但没降低懂业务的门槛。

AI降低的是写代码的门槛

不是懂业务的门槛

这句话说起来容易，但很多IT团队真正着手落地之前，是不信的。

道理其实很简单。我们让AI写一段计算加班时长的代码，可以说是毫无难度。给定上班时间、下班时间、法定工时，减一下就是加班时长。这种逻辑，AI几分钟的确就能生成一版能跑的函数。

但是在实际场景中，加班时长怎么算，并不是一道简单的算术题。

同一个工厂，可能有正常班、夜班、倒班三种排班模式同时存在；同一个员工，这个月是计时，下个月转岗变成了计件；请假冲抵加班要不要按小时折算，不同工种的加班倍率是不是统一，这些规则会不会因为某个基地在外省，还要再叠一层地方性政策——这些变量摞在一起，每多一个业务场景，规则之间要联动的关系就成倍往上翻。

有时候，规则复不复杂，跟工厂企业规模大小关系不大。即便是管理已经很成熟的小厂，一旦涉及复杂排班，问题往往不知道会从什么地方冒出来。

我们有一家快消行业的客户，工厂自动化程度很高，整个制造部不过三四百人，每条产线十来个人。按常理说，这个规模的排班，靠人脑也能搞定，并不需要什么系统。但他们很早就意识到，一旦引入共享用工，这套靠人脑的逻辑就跑不通了。

原因在于，他们的产线采用三班两倒的模式，三个班组轮早晚班和休息，规律看起来清晰，实际操作里变量很多。

例如，某个岗位人手不够，先从同产线休息班借调，借调不够再跨产线，跨产线就要看员工的岗位技能和熟练等级是不是匹配——有些产线不允许夜间生产，有些特殊岗位对熟练度有明确要求。借调过程中还要同时盯着几条非强制规则，例如员工连续排休要优先保障，上月负工时要在当月对冲等等。

这些约束条件，他们自己整理出来，光是强制项就有四条，非强制项还有很多条，每一条背后都有一套判断逻辑。

就这样一套规则体系下来，仅仅是两条产线的周排班，人工排一次要耗费四到六个小时，还无法完全保证准确。让IT用AI来自研这个排班引擎，代码倒是能写出来，但谁来告诉系统这六条约束规则怎么排优先级？谁来告诉系统在强制规则和非强制规则之间如何取舍？

这些问题，不是AI能回答的，是要有人在工厂里蹲过足够长的时间，见过足够多的排班冲突，才能给出一套站得住脚的方案。

这也是为什么某灯塔工厂级别的客户，自研考勤排班，最后行不通。

这家公司管理层早就拍板说要自研，团队也投入了不少资源，最后实际做到的是：能考勤打卡，收上来打卡数据，但算不出实时工时。卡是打上了，账算不出来。

他们表示："收数据本身不难，难的是收上来之后，怎么把原始数据套进那一整套互相牵扯的规则里，算出一个准确、能立刻拿去用的结果。"

另一家高科技制造企业的经历更是如此。

他们排班自研的项目不是没试过，是试过又没成功，最后才决定放弃。哪怕有AI帮着写代码，排班这件事真正卡住的地方，往往是你根本不知道规则该长什么样。班组长凭经验做的临时调整、员工个人的排班诉求、产线突发的波动，这些东西很难被完整地写成一条条规则。

总之，AI能帮企业实现你想清楚的逻辑，但没法替企业把业务想清楚。

还有一个更根本的问题：很多企业其实并不清楚，考勤排班这件事做得"对"、做得"好"是什么样的。

自研系统，意味着企业要自己定义规则、自己判断标准、自己决定哪些约束条件该有优先级、哪些可以灵活处理。但这个判断本身，往往也是靠着内部的经验和习惯在走，没有经过外部的对照和验证。结果就是，系统按照现有经验搭起来了，运行看起来也没问题，但究竟有没有漏洞、有没有更合理的做法，企业自己其实是没有把握的。

靠自研很难解决这个问题。

成熟的供应商在不同行业、不同规模、不同排班模式下落地过大量项目，见过的异常情况、处理过的边界条件，早就沉淀进了产品逻辑里。企业选择这样的供应商，某种程度上也是在借用这些年积累下来的行业经验，买的不只是一套软件功能。

说到底，AI能加速的，是从想法到代码这一段。但在这之前，还有更长的一段的路要走，从业务场景里把规则一条条摸清楚，这个过程AI帮不上什么忙，得靠人在工厂里真正待过、见过、改过才行。这也恰恰是盖雅这些年在不同行业、不同排班场景里一点点积累下来的东西。

从自研到外采

"以为很简单"到"没想到那么复杂"

"以为考勤很简单，没想到复杂性那么高。"

这句话是某仓储物流企业IT负责人说的，他们当初决定自研考勤系统的时候，内部评估觉得考勤无非就是打卡记录，数据进来，算一算，出去。公司里两百人的IT团队，这点事还搞不定？

结果做着做着才发现，自研的隐性成本，启动那天往往是看不见的，系统上线之后才会一波一波地找上门来。

第一波是业务变了。

新开一个厂，排班规则跟原来不一样，系统要跟着改；某条产线从三班倒改成两班倒，工时计算逻辑要重新梳理；引入外包工，考勤口径跟正式员工不一样，又是一套改动。另外，发生收并购的时，被并入的公司原来有一套自己的考勤规则，怎么跟现有系统对齐，又是一场硬仗。

每一次业务调整，自研系统就要重新开发一次，而这些改动的成本，在立项那天都不会被算进去，因为那个时候谁也不知道后面业务会怎么变。

第二波是合规要求变了。

例如，综合工时制的申请和审批，是今年很多企业都在经历的一道坎。有的企业成功申请到了综合工时，工时计算方式跟标准工时完全不同，系统要跟着重新适配；还有的企业申请没批下来，原本按综合工时设计的排班逻辑要整套推倒重来。

类似这样的合规变化，还有加班工资标准的修订、特殊岗位工时上限的调整，每隔一段时间可能就会有新的口径落下来。每一条都要落进系统里，落不进去，轻则数据对不上，重则面临劳动仲裁的风险。

总之，维护合规性这件事，听起来不起眼，但它是持续发生的。选择自研，就意味着这件事从此落在自己IT团队身上，时刻要盯着变化。

我们一家零售业客户的IT团队后来放弃自研，给出的理由就是：成本太高了。

这里说的成本，开发成本反而是最容易被低估的部分。真正让企业感受到压力的，是持续维护的人力投入、每次需求变更的响应周期，以及系统出了问题找不到人兜底的焦虑。当你把这笔账被拎出来之后，外采的价格突然就没那么贵了。

所以，AI只是让项目启动变得很便宜，demo两周就能跑出来，老板看了觉得靠谱。但AI没有让运维变得便宜。业务还是会变，法规还是会改，数据还是会出错，每一次出问题，还是得有人去查、去改、去测、去重新上线。

有些系统或许适合自研

考勤排班不在其中

说到这里，可能有人会问：那什么系统适合自研，什么不适合？

回答这个问题之前，我们想举一个例子。

我们接触过的一家车辆制造企业，内部在做系统选型的时候形成了一个共识：考勤没有能力自研，学习培训系统可以自研。他们判断背后的逻辑，主要还是和管理的复杂度相关。

不同系统的难度差别很大。学习培训系统，核心逻辑是课程管理和学习记录，规则相对清晰，业务边界也好划定；

考勤排班就不一样了，规则多、合规要求高、跟具体业务场景深度绑定，任何一个环节出了问题，其他地方都会跟着受影响。而且考勤排班的规则不是定一次就能用很久的，它会随着业务扩张、人员结构变化、政策调整一直在变，这才是自研真正难应付的地方。

很多IT团队在判断要不要自研的时候，喜欢拿其他系统做类比：

之前自研过别的系统，跑得挺好，考勤排班应该也差不多。但考勤排班有它的特殊性，不太适合用这种方式类比。其他系统自研成不成功，很大程度上取决于那套系统的业务规则稳不稳定、边界清不清晰；而考勤排班面对的，是每天都在动的人、每月都可能改的规则、每年都要重新核对的合规要求。系统难不难维护，很大程度上取决于它要跟多少个外部变量保持同步，这一点考勤排班几乎是所有系统里最高的。

所以自研过其他系统、技术能力不差的团队，在考勤排班上依然会碰壁，也就不奇怪了。能力够不够不是核心问题，是这件事本身的特点决定了它不太适合用自研来做。

在决策之前，不妨先想清楚几个问题：

这个系统的规则稳不稳定，半年后还是不是现在这套逻辑？
它需要跟多少内外部变量联动？
排班、考勤、薪资、合规，这几张表之间的关系理清楚了吗？
涉及地方性政策的部分，团队有没有人持续跟进？
业务扩张之后，系统能不能跟得上，还是每次开新厂、换新模式都要重新开发一轮？
出了问题，团队有没有能力快速定位原因，还是只能靠排查日志慢慢猜？
系统上线之后，日常维护靠谁，这个人离职了怎么办？

这几个问题里，只要有几个答案是"不确定"，自研的风险就已经不低了。考勤排班在这几个问题上的答案，几乎没有一个是让人放心的。