為什麼大家都想要配送路線最佳化，真正導入卻這麼難？
數位轉型喊了很多年，物流業和需要配送的零售、製造業也不例外。當企業開始面對缺工、司機老化、油料成本上升與配送需求碎片化，「Route Optimization（RO，路線最佳化）」幾乎是最直覺的答案：既然電腦可以同時考慮幾十台車、幾百個配送點、容量、時間窗（time window）與距離，理論上當然應該比人工排得更好。
但實際做過RO導入的人大概都有類似經驗：演算法明明算得出來，專案卻不一定上得去。甚至工具愈專業、限制考慮得愈完整，反而愈容易被挑戰。
問題到底出在哪裡？
RO不是把原本的流程搬到電腦裡
一般數位化，主要是把「原本怎麼做」轉換成「現在在系統裡做」。例如紙本表單改成線上簽核、Excel改成ERP。
RO不一樣。
它會直接重新決定「哪位司機送哪幾單、用哪一台車、幾點出發、先送誰、後送誰」。換句話說，它不是把既有決策數位化，而是在挑戰既有決策。
這也是RO特別難的第一個原因。
企業原本的配送方式往往包含大量沒有寫下來的規則：某位司機習慣跑某一區、某個客戶最好下午送、某家店雖然沒有正式時間窗但司機知道不能太早到、業務臨時插單時要怎麼處理。這些知識原本散落在人腦、電話、LINE與工作習慣裡。
RO一進來，這些東西突然都必須被挖出來寫下來。因為不論用數學規劃還是啟發式演算法，系統都必須有明確的目標函數與限制式，每一條規則都得被寫成可以計算的形式。
因此RO很像一台X光機。它沒有製造問題，卻是把企業原本沒有被正式管理的問題一次呈現，即便是頂級的物流公司也必須直接面對這些議題。
更大的問題，是人工與系統根本沒有站在同一個評分標準上
假設人工排了十條路線，其中有一條繞遠了，大家通常會認為「今天比較忙」「司機臨時有狀況」、可能路上塞車了。
但如果RO排出一條看起來反直覺的路線，反應往往變成：「這套系統不行」、「演算法不懂物流現場」。
弔詭的是，企業主在找RO方案時，主要是認為調度或司機難以勝任複雜的任務；但是找了RO方案後，卻又回頭請原本的調度或司機檢視最佳化後的路線是否合理。
我曾遇過一個很典型的案例。某位企業主因為不滿既有調度效率，希望導入RO。導入後，系統很快產生一套從整體指標看來效率更高的配送計畫。老闆看完覺得不錯，但也坦白說，他無法判斷每一條路線是否真的能執行，因此又把RO的結果交回原本的調度檢查。
調度很快從其中一條路線找出一個迴轉點，認為司機最不希望遇到迴轉，因此結論是：演算法沒有考慮司機感受。這個批評很具體，也很有畫面；相較之下，車隊整體效率的改善卻是抽象的。
為了確認問題，我拜託客戶讓我實際跟車。當天司機跑的是調度原本規劃的路線。實際跑完後發現，竟有34%的客戶點必須迴轉才能抵達。這不是說迴轉不重要，而是人工路線原本也存在同樣問題，只是從未被量化。若RO因一個迴轉就被判定失敗，人工卻不必接受同樣檢驗，兩者從一開始就沒有公平比較。
這個案例後來反而比較容易解。與其試圖證明RO可以一次取代調度，我們先讓司機與調度一起面對同一個事實：人工排車的結果如果不是迴轉，往往就是繞更遠的路。
真正要比較的，不是某一條路線有沒有一個不討喜的動作，而是在可接受的現場條件下，整體多跑了多少路、花了多少時間。於是我們改用少量、增量的方式導入，每次只讓RO接手一小部分任務，讓調度能逐步看到差異，也保留修正空間。當改善不是一次性的系統取代人工，取而代之的是一段可以被觀察、被驗證的增量過程，調度自然比較容易接受。
這也是為什麼我常用一句話形容：
人的錯誤是流量，系統的錯誤是存量。
人工昨天排不好，今天重新排就好了；系統曾經出現一條奇怪路線，卻可能半年後還在會議裡被提起。
更麻煩的是，RO預設最佳化的是用上帝視角來看「整個車隊」的總量指標，公平性除非被明確寫進目標函數，否則不會被自動照顧；但司機看到的通常只是自己的一條路線。
假設十台車整體少了80公里，但其中一位司機比以前多跑6公里，他完全可能覺得：「這個系統明明排得比較差」。
我們必須承認，他的觀察不一定錯，只是觀察尺度不同。
於是RO面臨一個很特殊的困境：全局效益是總量性的，反對意見卻往往是局部、具體而且非常有畫面的。
還有一個更弔詭的現象：系統愈精確，愈容易吃虧
人工排車時，企業可能說「VIP一定要先送」「原則上不要跨區」「最好4小時內送完」，但人工實務上未必每天百分之百遵守。
一旦導入RO，這些話卻很容易全部被轉成嚴格限制。
結果是，系統被要求同時滿足所有規則，再跟原本不需要嚴格滿足這些規則的人工結果比較。
於是出現一個很奇怪的局面：
不考慮限制，客戶說你不懂現場；全部嚴格考慮，又被問為什麼效率沒有人工好。
另一個案例，更能說明這種不對稱。我曾輔導一家大型貨運業者。導入初期，我們就和客戶有共識：數學家如果只坐在辦公室，很難做出能落地的排車模型。因此，我們讓數學家駐點一段時間，跟著現場師傅學調度。客戶也認真整理過去口耳相傳的慣性與隱性知識，甚至訂出數條排車「憲法」，作為系統不可跨越的清楚邊界。
但到了驗收階段，RO的成果一開始始終無法比人工更好。起初，大家直覺認為是模型還不夠懂現場；後來我們逐條檢查人工路線，卻發現人工結果本身也會違背自己訂的「憲法」。這才讓問題慢慢浮現：客戶以為已經說清楚的規則，實際上只是調度決策的一部分。
我們沒有因此停下來，而是持續和現場一起修正模型、重新釐清限制與評分方式。經過一段時間後，演算法的成果開始超越人工。這裡要說明一件事：實務規模下的RO並不是真的算到最佳解，而是在可接受的計算時間內找到一個夠好的可行解。模型和限制定義錯了，算出來的「最佳」就是往錯的方向最佳。
照理說，這應該是導入成功最明確的證據，但新的問題反而出現了：當系統真的排得比人好，產生的路線也開始長得和過去不太一樣。績效超越了人類，客戶卻開始擔心，因為他們已經無法只靠過去的經驗快速判斷這些新路線到底能不能執行。
於是出現一個很有意思的矛盾：系統愈接近模型定義下的最佳解，結果可能愈不像人工；但結果愈不像人工，人就愈不敢用。調度因此開始更仔細地逐條檢視RO的成果，而這個檢查過程又揭露了另一件事：即使前期已經讓數學家駐點、讓現場整理規則、甚至訂出排車「憲法」，導入過程中仍然有一些隱性知識沒有被說出來。
不是客戶故意隱瞞，而是很多經驗只有在看到一條違反直覺的具體路線時，人才會突然意識到：「原來這件事我們一直都有在考慮。」
這也讓我們重新理解RO的導入不是一次把需求訪談完整、把規則寫進模型就結束，而是一個不斷逼近現場真實決策邊界的疊代過程。
哪些規則絕對不能違反、哪些只是偏好、什麼情況可以例外，以及例外願意付出多少代價，往往都要在系統真的提出不同答案後才會逐漸被釐清。換句話說，演算法超越人工並不代表導入完成；就我的經驗來說，那反而才是最困難的階段開始。
但不是每一個案例最後都能跨過這一關。有些客戶會在這個階段停下來，甚至因此流失。這也是做RO很難迴避的現實。這些沒有成功落地的案例，後來反而成為我們很重要的學習材料。我們開始反覆整理失敗專案，辨認究竟是模型能力不足、限制定義錯誤、評分方式不公平，還是組織根本還沒有準備好把決策交給系統。
也正是從這些失敗中，我們才逐漸歸納出RO難做的根因，並進一步思考：下一階段若要把AI放進路線決策裡，重點不只是讓模型更聰明，而是讓系統能理解人為什麼拒絕某個答案，以及哪些現場規則其實需要被討論、被學習、被調整。
這不是單純的演算法問題，而是怎麼證明一個新決策系統比較好的問題。
所以企業導入RO，需要的不只是POC
對大型企業來說，一般的POC（概念驗證）通常只驗證到「算得出來」，卻沒有驗證到「被接受」。比較合理的流程應該是：
先驗證是否有改善價值，再找出真正的營運限制；接著先定義怎麼判斷成功，之後才進行小範圍實際試跑，最後再擴大導入。
其中一個重要原則，是司機與現場人員非常重要，但他們最重要的角色應該是幫忙指出「系統不知道的現場事實」，而不是只用一句「這條路線看起來怪」決定整個RO專案成功或失敗。
RO下一階段真正的競爭力，不只是演算法
做了多年RO之後，我認為，真正困難的最後一哩路，並非強調用了什麼先進的演算法，讓企業願意把決策交給系統才是關鍵。
所以成熟的RO產品，除了最佳化核心，還需要另一層能力：讓人工與系統可以公平比較、讓限制被正確分類、讓修改後的代價被看見，也讓使用者不需要先理解一整套數學最佳化理論，就能正確地和系統互動。
知道RO為什麼會被拒絕，然後把那些反覆出現的阻力，一個一個消化進產品裡。
如果這件事做得到，RO才有機會從少數大型企業才能負擔的導入專案，真正變成可以規模化的數位服務。
