連鎖餐飲導入 AI 排班系統失敗案例：店長為什麼又改回人工

一間擁有十幾家分店的連鎖餐飲品牌，總部人資部門每個月要處理將近兩百位工讀生與正職人員的排班，光是彙整各店回報的請假單、調班需求、時薪計算，就要花掉兩個人快一週的時間。老闆看到市面上有 AI 排班系統，號稱能根據歷史來客量、員工可上班時段、勞基法工時上限自動生成最佳班表，還能預測尖峰時段該加派多少人力，覺得這正是解決缺工與人力成本問題的答案。系統報價一年落在十幾萬到二十幾萬之間，比起兩個人資的人事成本，怎麼算都划算，於是總部拍板，十幾家分店一起導入。

原本的期待很清楚：系統上線後，店長不用再花時間手動排班，總部也能即時看到每家店的人力配置是否合理，甚至能抓出哪些分店長期人力過剩或不足。前兩週的示範也確實漂亮，系統跑出來的班表工時分配均勻，尖峰時段人力也比之前更充足，大家一度以為這次數位轉型會很順利。

為什麼系統跑出來的班表，店長看了直接搖頭

問題是從第三週開始浮現的。系統排出來的班表在紙面上很合理，但完全沒考慮到現場的人情因素：哪個工讀生和哪個工讀生處不來、誰週五晚上要去補習沒辦法排班、哪個資深員工其實默默扛下了大部分的教育訓練工作。這些資訊從來沒有被系統化記錄過，自然也沒辦法餵給 AI 學習，系統只能根據員工登記的「可上班時段」硬排，結果排出一堆班表要臨時對調，店長光是處理調班訊息就比以前更累。

更麻煩的是尖峰預測。系統的來客量預測是根據過去半年的 POS 資料訓練出來的，但沒有把在地活動、天氣、周邊商圈的臨時變化算進去。有一家開在夜市旁的分店，系統完全沒抓到夜市擺攤時段暴增的人潮，連續三個週末都排太少人，外場忙到出餐延遲、客訴變多；隔壁一家開在辦公商圈的分店則相反，系統照過去資料排了平常的人力，卻沒注意到附近有棟大樓在裝修，午餐人潮少了三成，結果排太多人力，人事成本反而超支。

代價不只是多繳的系統費用

這些狀況拖了將近兩個月，總部才意識到問題不是「系統不夠聰明」，而是從一開始資料就沒準備好。員工的個人狀況、店周邊的商圈變化，這些原本仰賴店長經驗判斷的「軟資訊」，沒有人想過要怎麼轉成系統看得懂的輸入條件。結果是店長們陸續回報班表狀況不對，總部人資又要花時間手動調整系統排出來的結果，等於多做了一層工作，原本想省下來的時間不但沒省到，有一段時間反而比純手動排班還花時間，幾乎多花了將近一倍的工時在「修正 AI 排出來的班表」。加上系統的月費持續在燒，幾家分店店長乾脆私下又改回自己用 Excel 排班，只把系統當成打卡與工時統計工具，原本想要的「總部統一管理」目標也就落空了。

對總部來說，更難處理的其實是信任成本。第一批被系統搞得焦頭爛額的店長，後來對任何新系統都會直覺抗拒，即使半年後總部把資料補齊、重新調整參數，想再推第二輪導入，現場的配合度已經大不如前。

後來怎麼調整，才把系統救回來

總部後來做的第一件事，是先讓兩三家分店當試點，而不是十幾家店一次上線。試點期間，店長被要求把「員工不能排班的隱性原因」「店周邊會影響來客量的固定事件」都建成一份簡單的備註清單，同步更新進系統，讓 AI 排班至少有這些額外變數可以參考。第二件事，是把系統定位從「自動生成最終班表」改成「先生成草案，店長再做最後確認與微調」，而不是要求現場照單全收。第三件事，則是把來客量預測拆成「基礎模型」加「店長自行標註的特殊日期」，遇到夜市擺攤、商圈活動這類系統學不到的變數，由人工事先提醒系統要調整。這三個調整下來，大概又過了一季，班表的接受度才慢慢回升，總部也才敢把導入範圍擴大回其他分店。

給連鎖餐飲業者的避雷提醒

回頭看這個案例，真正的問題從來不是排班演算法不夠準，而是總部低估了「店現場的隱性資訊量」有多大，也高估了半年的 POS 資料能代表所有情境。導入前可以先做幾個檢查：排班系統的訓練資料是否只有來客量與工時，還是也涵蓋了員工個別狀況與商圈事件這類軟資訊；上線範圍是先從一兩家店試點，還是打算一次全面鋪開；系統產出的班表定位是「最終結果」還是「給店長確認的草案」；以及萬一系統判斷失準，現場有沒有明確的人工覆核與調整機制。

如果這幾個問題在簽約前都答不出來，通常就是後續會卡關的前兆，值得先放慢腳步，而不是急著把十幾家店一次綁進同一套系統裡。