需求人數和請假申請難以兼顧。
請假申請、時段需求、最低人數常常需要同時人工檢查。
問題
比填表更重的是平衡各種條件的判斷。
排班難點不是把名字填進表格，而是同時保持許多規則、偏好和例外一致。
必須安排合格人員。
負責人、持證人員、設備操作人員等，必須出現在指定時段。
公平性難以靠目視確認。
夜班、週末、總班別數和高負荷工作不能集中在少數人身上。
小變化會導致整體重排。
一次缺勤或需求變化，就可能讓整張表需要重排。
自動化目標不是排班表本身，而是排班負責人在製作表格時反覆進行的判斷。
建模
把現場規則轉成可計算條件。
把“儘量公平”“不要連續工作”“這兩人分開”“尊重請假申請”等現場語言，轉換成資料、硬性規則、偏好和評分。
目標函式範例
人數不足 x 1000 + 資格缺口 x 1000 + 偏好違背 x 20 + 工作量不均 x 5
權重僅用於說明。實際專案會透過訪談確定絕對條件和優先順序，並與真實排班比較後調整。
輸入資料
員工、可出勤時間、請假申請、資格、需求人數和目前排班。
硬性條件
需求人數、資格安排、休息限制等不能違反的條件。
偏好條件
請假申請、偏好班別、公平性等儘量滿足的條件。
複核輸出
排班候選、未滿足條件、理由、指標和變更影響。
可操作示範
調整條件，重新計算排班候選。
可以切換業務場景，並調整需求人數、資格安排、偏好、公平性和連續工作上限。排班候選、指標和檢查日誌會同步更新。
這是用於說明的簡易啟發式示範，不是正式環境用最佳化引擎。
人數滿足率
資格安排率
偏好符合率
排班別數差
| 員工 | 週一 | 週二 | 週三 | 週四 | 週五 | 週六 | 週日 |
|---|
規則庫
把“貴公司預設如此”的條件逐一建模。
以下代表規則會逐步建模。不是一開始就加入全部條件，而是根據運營重要度和資料是否存在來決定第一階段範圍。
COV-01
硬性
各時段需求人數
按星期、時段、地點、部門和角色設定最低人數和建議人數。
COV-02
偏好
按繁忙程度增員
根據銷售預測、預約數、入住人數、產量等調整建議人數。
LAB-01
硬性
連續工作與間隔
處理連續工作上限、夜班後休息、班別間隔等已確認的內部規則。
LAB-02
硬性
合約工時與上限
納入周或月工時、僱傭型別上限、可加班時間等條件。
SKL-01
硬性
資格人員與負責人安排
保證各時段所需的資格、負責人或設備操作技能組合。
SKL-02
偏好
新人和熟練人員組合
避免新人單獨值班，儘量與培訓負責人或熟練人員組合。
PRF-01
偏好
請假申請與可出勤時間
區分不可出勤與請假申請，並按重要度設定優先順序。
PRF-02
偏好
工作負荷公平性
減少夜班、週末、晚班、總班別數和高負荷工作的偏差。
PRF-03
偏好
固定負責人和符合度
將客戶連續性、團隊符合度和擅長領域納入安排評分。
定製規則
貴公司理所當然的條件，正是建模物件。
通用範例中不會出現的條件，往往正是專用建模的價值所在。
閉店後不要立即安排開店避免全是新人值班特定兩人不要同時安排支援其他地點每月最多兩次夜班後第二天休息保持同一客戶負責人
輸出
返回判斷材料，而不僅是排班表。
實用的排班系統不能只輸出一張表，還應說明發生了什麼變化、哪些條件未滿足，以及排班負責人需要檢查什麼。
多個候選方案
不是給出一個不透明答案，而是返回多個取捨不同的候選方案。
未滿足條件
顯示人數缺口、未滿足的請假申請，以及無法滿足的條件。
安排理由
說明為什麼安排某個人，例如資格、偏好、目前負荷較低或覆蓋優先。
變更影響
發生缺勤時，固定需要保留的班別，只重新計算受影響範圍。
行業範例
為每個現場定義“好排班”。
什麼是好排班，在不同現場並不相同。模型應使用業務現場本來使用的語言和優先順序。
零售與餐飲
開店和閉店、繁忙日、賣場技能、週末公平性。
照護與醫療
日班和夜班、持證人員、照護連續性、休息間隔。
製造與物流
設備資格、產量、產線安排、輪班輪換。
現場與支援團隊
現場可用人員、支援覆蓋、緊急回應、移動約束。
自建或選型
標準排班適合既有服務。現場規則會左右結果時，專用模型更合適。
客製開發並不總是正確答案。應根據規則複雜度、資料準備度，以及可說明候選方案帶來的業務價值來判斷。
不會把客製開發當作預設答案。
如果既有服務能很好解決問題，我們會直接說明。只有當客製條件的業務價值可能高於成本時，才建議開發專用系統。
既有服務足夠時
如果班別模式標準、規則較少、團隊規模不大，使用現有排班服務通常能更快開始。
適合客製系統時
資格、現場規則、臨時變更和結果說明較多時，建立專用模型更有價值。
資料
從既有檔案和規則備忘開始。
第一天不需要完整資料庫。既有 Excel、紙本請假申請和員工臺帳，都可以整理成第一版資料格式。
員工與可出勤時間
員工姓名或 ID、技能、合約工時、可出勤時間、請假申請，足以開始第一版模型。
需求人數
按日期、時段、地點、部門、角色拆分的需求人數，定義了覆蓋目標。
硬性規則與偏好
把絕對不能違反的規則，與儘量滿足的偏好分開處理。
目前排班範例
目前排班和人工調整記錄，可用於比較自動候選方案是否符合實際。
流程
正式開發前，先小範圍確認是否可求解。
第一目標不是替換整個業務，而是驗證排班規則能否表達、產生候選方案是否有用。
01
確認目前做法
確認目前 Excel、請假申請收集和人工修正流程。
02
分類條件
分離硬性規則、偏好、評價指標和只能由人判斷的部分。
03
試做計算模組
用代表資料建立小型計算元件。
04
比較候選方案
將產生候選方案與目前排班和負責人意見比較。
05
系統化業務
確認適合後，再連線編輯、權限和業務流程。
下一步驗證
選擇下一項要確認的內容。
從排班問題繼續選擇有助於團隊判斷的材料。
常見問題
排班自動化前的常見問題。
說明示範能展示什麼、原型驗證什麼，以及哪些部分仍應由人判斷。
本頁示範就是正式環境用最佳化器嗎？
不是。本頁示範只是說明思路的簡易啟發式。實際專案會在確認規則、規模和回應時間後選擇求解器或搜尋方法。
可以從 Excel 開始嗎？
可以。通常只要有目前排班、員工表、請假申請和簡短規則備忘，就能開始第一輪確認。
系統會自動決定最終排班嗎？
不會。系統應展示排班候選、未滿足條件和安排理由，由排班負責人確認最終排班。
請假申請如何處理？
除非組織明確把它作為硬性規則，否則會作為偏好處理。輸出會顯示哪些申請未滿足，以及原因。
兩週原型包含什麼？
先限定在一個組織、一類排班和主要規則內，確認是否可計算、與現行方案相比是否有用。編輯、權限和業務整合在後續判斷。