問題
重建路線的工作，比輸入行事曆更重。
困難不在輸入預約，而是在訪視、人員、時間、移動與例外之間，持續重建可行組合。
訪視時間窗會重疊。
上午限定、前置作業後、截止時間前等，每個訪視都有不同時間條件。
- 需要包含前後移動
- 也會產生等待時間
不是每個人都能去。
資格、設備、語言、現場經驗與客戶偏好會限制可安排人員。
- 有資格人員成為瓶頸
- 匹配度與連續負責也要考慮
地圖上近也不一定可行。
服務時間、停車、道路時間、據點與直行直歸都會影響計畫是否可行。
- 移動會壓縮日程
- 每位負責人出發地可能不同
一次變更會影響整天。
缺勤、取消或緊急追加會迫使剩餘一天重新組合。
- 儘量維持已確認日程
- 也可能需要通知變更
計畫負責人每次都在腦中做這類計算。
訪視時間窗×負責人條件×移動×連續性×變更= 可執行日程
數理模型
請求解器安排一天路線之前，先把規則分開。
訪視計畫可以視為含時間窗、人員技能、休息、固定預約與變更後修復的路線問題。
01
必守
必須滿足的條件
- 訪視時間窗每次訪視都必須在允許的服務時間窗內開始並完成。
- 必要技能只將具備所需技能、資格、設備或語言能力的人員列為候選。
- 人員可用性缺勤、工作時間、訪視上限與返回據點規則都保持可見。
02
偏好
儘量滿足的偏好
- 連續負責當連續負責具有業務價值時，優先保留同一名負責人。
- 期望時間在允許的時間窗內，盡量靠近期望的訪視時間。
- 負荷均衡避免困難訪視、長距離移動或緊急任務集中到某一個人。
03
指標
需要改善的指標
- 未分配訪視先減少高優先順序的未分配訪視，再改善便利性指標。
- 移動時間在保持時間窗與連續性可說明的前提下，減少總移動時間。
- 延遲與加班當人員與時間不足時，不偽裝成完整計畫，而是顯示原因。
只看最短距離，排不出好日程。
為了少幾分鐘移動時間，是否值得打破連續負責；緊急個案進來時，可以調整幾項已確認安排。這些優先順序會與你一起決定。
外勤業務
適合需要匹配訪視、人員與順序的業務。
共同問題是誰應該在什麼時間、以什麼順序訪視哪個地點。
居家照護與護理
處理訪視時間窗、醫療技能、連續負責、週次頻率與缺勤修復。
時間窗資格連續性
現場檢查與維修
組合設備種類、零件、技術人員技能、緊急度與從據點出發的移動。
技能零件緊急
清潔與維護
表達入場時間窗、必要設備、多人作業與連動任務。
多人設備入場時間窗
業務拜訪與現場調查
反映優先順序、區域、關係負責、訪視頻率與直行移動。
優先順序區域頻率
互動示範
改變條件，確認候選路線為什麼改變。
切換業務案例、缺勤、緊急訪視與規則強度，查看候選路線為什麼改變。
路線圖
概略路線
座標是虛構的相對位置。正式系統會替換為道路時間矩陣與已驗證的地址處理。
確認
確認要點
人員路線
一日時間軸
未分配
需要判斷的訪視
規則範例
為決定路線是否可執行的業務規則建模。
以下是選擇求解器或搜尋方法前，需要先分離的規則範例。
WIN-01必守訪視時間窗
在各訪視允許時間窗內開始並完成，否則標示為不可行。
SKL-01必守必要技能
要求人員持有該訪視所需的所有技能、資格、設備類別或語言能力。
AVL-01必守工作可用性
遵守人員缺勤、工作開始、工作結束、最大訪視數與固定預約。
BRK-01必守休息時間窗
在候選路線中清楚保留用餐休息或休息時間窗。
CON-01偏好連續負責
在不破壞必守條件時，優先保留上次負責人員。
CHG-01偏好減少變更
缺勤或緊急追加後修復計畫時，避免變更已確認訪視。
BAL-01偏好負荷均衡
在人員之間平衡訪視件數、服務時間、移動時間、緊急度與困難現場。
TRV-01指標減少移動
在可行性、優先順序與連續性已納入後，再減少總移動。
UNS-01指標未分配說明
不要強行產生誤導性的完整計畫，而是顯示未分配訪視與原因。
可解釋輸出
不只輸出計畫本身，也輸出計畫的理由。
有用的系統不會隱藏不足，而是顯示候選計畫，以及每個例外需要人工判斷的理由。
訪視順序與時間
按每位人員顯示到達、等待、開始、完成、移動、休息與返回時間。
未分配原因
分類顯示技能、時間窗、訪視上限、工時與固定預約等不足原因。
候選比較
跨候選比較分配數、移動、延遲、連續性、加班與變更量。
人工修正與影響
讓人員鎖定已確認的訪視或人員分配，然後只重算剩餘計畫。
1生成候選根據條件與優先順序計算
→2人工確認例外、關係與現場情況
→3固定一部分保留已確認訪視
→4重新計算重排變更部分
→連線到運營
不只計算，也做到現場團隊真正會使用的系統。
只有最佳化引擎並不能改變營運。我們會圍繞請求、客戶資料、人員日程、地圖、通知與實際結果設計畫面與工作流程。
- 請求受理與個案臺賬管理訪視條件、地址、所需時間與優先順序
- 負責人手機應用確認今日順序、地圖、聯絡、到達與完成
- 變更與通知反映取消、缺勤與緊急追加並通知
- 實績與分析彙整計畫與實際差異、移動、延遲與工作負荷
現場負責人手機日程、地圖、報告
運營管理畫面請求、手動修正、確認
計算核心計算引擎約束、路線、重算
資料客戶、人員、實績資料庫、API、審計日誌
資料
從既有排程檔案與規則說明開始。
第一個原型可以從匿名化的一天或一週資料開始。目標是確認規則能否表達，以及候選計畫是否有用。
輸入
最先確認的資料
訪視清單
地址或區域、可訪視時間、服務時長、必要技能、優先順序與上次負責人。
人員清單
工作時間、據點、資格、訪視上限、缺勤與目前位置。
業務規則
必守規則、偏好、優先順序、休息規則、固定預約與變更限制。
目前計畫與實際結果
目前計畫、實際到達與完成時間、移動、取消與手動修正記錄。
適用判斷
不是所有排程問題都需要客製最佳化。
先判斷資料與規則是否足以支撐可驗證的計算。
+
適合諮詢
- 時間窗、資格、移動等條件很多
- 計畫編排依賴特定負責人經驗
- 缺勤或緊急追加會頻繁重排
- 引入現有工具後仍有大量手工修正
- 日程需要與其他業務系統連線
-
先考慮現有工具
- 訪視件數少，固定路線即可處理
- 時間指定或資格條件很少
- 市售服務已經足夠
- 基礎資料與業務規則尚未整理
- 自動化之前應先整理受理流程
交付流程
先解決一小段，再連接到現場營運。
我們會分開計算驗證與系統實作，讓每個階段都能依據證據繼續、變更或停止。
- 01診斷免費確認
確認課題與資料
確認目前日程、負責人、訪視條件與變更頻率。
- 02建模設計
將條件分成三類
整理必守條件、偏好與改善指標，並確認評價方式。
- 03原型固定範圍
小規模計算驗證
用一天或一週的資料生成候選，並與當前方案比較。
- 04產品化單獨報價
實現業務系統
把受理、地圖、修正、通知、實際結果與權限整體實作。
- 05改善持續改善
從實績繼續改善
使用實際移動時間、延遲與現場修正來打磨規則。
這個頁面示範是正式最佳化引擎嗎？
不是。頁面示範是說明用的簡單確定性啟發式。正式專案會在確認規模、規則與回應時間需求後，選擇求解器、搜尋方法或混合方案。
可以從 Excel 開始嗎？
可以。第一次確認可以從匿名化的訪視清單、人員清單、規則備忘與目前日程開始。
缺勤或緊急訪視後可以修復計畫嗎？
可以。修復模式可以鎖定已完成或已通知的訪視，然後只重算剩餘路線並顯示變更內容。
可以串接地圖服務嗎？
可以。道路時間 API、距離矩陣與地圖顯示可在確認費用、條款、快取與隱私處理後整合。
系統會自動確認最終日程嗎？
不會。確認日程前，人員應先審核未分配訪視、規則放寬與手動修正。