我是 Kota，宇鯨智能的創辦人，從 2021 年開始了一人公司，協助中小企業透過 Data / AI 技術進行數位轉型。

我特別關注想要建立新的服務模式、獲取營收的製造業。這背後需要進行大量的流程再造和數位管理，也需要藉由 AI 技術自動化瓶頸的步驟，這些是我特別擅長的領域。

前一篇談到，一筆訂單從外部通路進來之後，需要先找到目前有效的合作條件，確認商品與其他必要資訊都符合規則，整筆驗證通過後才建立訂單，再把資料送往製造商既有的 ERP。走到這一步，正常情況下的流程已經逐漸清楚，但真正開始往既有系統串接之後，我們還需要處理另一組問題：如果自動化流程中途失敗，接下來應該由誰處理，以及系統能不能自己再試一次。

原本透過人工處理時，這些問題通常不會被拆得這麼細。業務收到訂單後，如果缺資料就回頭問客戶，ERP 輸入失敗就看一下畫面，再決定重新輸入、改資料或找其他人處理。很多判斷跟著操作人員一起完成。改成系統自動送單之後，原本集中在一個人身上的工作被拆開了，系統也開始需要知道不同失敗情況接下來要往哪裡走。

同樣是「送單失敗」，原因可能完全不同

最容易處理的是資料本身有明確問題的情況。例如必要欄位缺少、商品找不到對應規格，或送進來的內容不符合目前允許的合作條件。這類錯誤在驗證階段通常已經可以確認，系統知道哪一筆資料不符合規則，也知道問題需要從資料來源端被修正。

這時候讓系統一直重送沒有太大意義。相同的資料再送十次，結果還是一樣。因此比較合理的做法是 Reject，將可以辨識的原因回給合作通路，讓對方修改後重新提交。技術上這類情況可能對應到 4xx 類型的回應，但在實際流程裡更重要的是，系統已經可以明確指出「這份資料目前無法成立」，而下一個有能力修正問題的人位在通路端。

但 ERP 沒有正常回應時，情況就不一樣。平台可能已經完成前面的資料驗證，也確認這是一張可以成立的訂單，只是在送往 ERP 時遇到 timeout、連線異常或其他系統錯誤。這時候平台知道的是「沒有拿到預期的成功結果」，卻不一定知道 ERP 到底做了什麼。

如果所有錯誤最後都只被寫成「送單失敗」，系統就很難判斷接下來應該 Reject、Retry，還是先停下來交給人確認。

有些錯誤可以重新嘗試，有些狀態不能直接重送

一開始很容易把 Retry 當成最直接的容錯方式。ERP 暫時連不到，就過一段時間再送一次；如果是短暫網路問題，第二次可能就能正常完成。

但這個做法有一個前提：系統必須知道第一次動作確實沒有成功，或至少可以確定同一個動作重新執行不會產生第二份結果。

例如平台把一張訂單送進 ERP，等待一段時間後 timeout。這個 timeout 可能代表 ERP 根本沒有收到，也可能是 ERP 已經成功建立訂單，只是回應沒有順利傳回平台。如果平台看到 timeout 就立即再送一次，而 ERP 又無法辨認這是同一筆交易，最後可能建立兩張相同訂單。

因此我們在討論錯誤處理時，需要把「明確失敗」和「不知道結果」分開。前者如果確認可以安全重做，就比較適合 Retry；後者則需要先保留狀態，讓系統或人有機會確認 ERP 的實際結果，再決定要不要重新送出。

從技術架構繼續往下，這會碰到 Idempotency 等問題，也就是同一個操作被重複執行時，系統能不能辨認它其實代表同一筆交易。不過對當時的產品設計來說，更直接的問題是先不要讓所有失敗都自動進入相同的 Retry 邏輯，因為不同失敗背後的風險並不一樣。

Error handling 其實也在重新分配誰負責處理問題

把錯誤拆開之後，我以 PM 的角度需要確認的也不再只是「錯誤訊息要顯示什麼」，而是下一步由誰處理。

如果訂單資料本身不符合規則，合作通路有能力修改，那就應該讓問題回到來源端；如果資料沒有問題，只是 ERP 暫時無法連線，外部通路其實做不了什麼，這類問題就應該留在平台或製造商內部處理；如果系統無法確認 ERP 到底有沒有成功，則可能需要通知維運人員或 System Admin 進一步確認。

這和原本人工接單時的工作方式很不一樣。以前同一個業務可能同時完成收件、檢查、修正、輸入 ERP 與確認結果，流程中的責任沒有特別被寫出來。當這些步驟開始自動化之後，每一種例外都需要比較明確地知道下一個處理者是誰，否則訂單雖然留在系統裡，實際上沒有人知道自己需要做什麼。

所以錯誤分類最後也會影響通知方式。外部可以修正的問題，適合直接回傳可理解的原因；內部系統異常，不一定需要把技術錯誤完整丟給通路，而是要讓真正能處理系統問題的人收到資訊。

但還有一種情況：系統不讓過，現場卻知道這次需要繼續

當我們把 Reject 和 Retry 分開之後，還是會碰到第三種情況。

系統是根據已知規則執行，因此只要條件不符合，就會把流程擋下來。但企業現場有些例外本來就很難在一開始全部寫成規則。有時候製造商已經確認這筆資料可以處理，只是目前系統裡的條件還沒有完整涵蓋；也可能因為特殊合作情境，負責的人知道這一次應該繼續往後送。

如果系統完全沒有例外處理方式，使用者最後通常還是會想辦法繞過它。例如另外寄 Email、請人直接進 ERP 建單，或用其他方式把工作往下推。這樣系統裡看到的是一張被擋住的訂單，工廠裡卻可能已經用另一條流程處理，後續反而更難追蹤。

因此我們也討論到 Force Send 或 Manual Override 的需要，也就是在某些情況下，允許有權限的人確認例外後，讓原本被系統擋住的流程繼續往下。

不過一旦提供這個能力，問題就從「要不要放一個按鈕」變成「哪些規則可以被人跳過」。

Force Send 不能只是一個繞過檢查的按鈕

如果任何錯誤都能透過 Force Send 繼續處理，前面花時間建立的 Validation 很快就會失去意義。使用者遇到問題時，只要按下強制送出，系統最後還是回到人工判斷，而且很難知道某一筆訂單為什麼沒有按照正常規則執行。

Force Send 如果要存在，必須要有界線。例如資料格式根本無法被 ERP 接受，這類問題即使人工確認也無法靠 Force Send 解決；但某些商業條件或目前系統尚未涵蓋的例外，如果負責人已經完成確認，就可能允許繼續處理。不同類型的錯誤是否允許 Override，需要在實際營運過程中逐步整理。

同時也會碰到權限與紀錄問題。誰有資格做這個判斷、當時為什麼選擇跳過正常規則、後面如果出現問題要怎麼追查，都不能只留在操作人的記憶裡。這也是為什麼 Manual Override 往後通常會牽涉 Permission 與 Audit Log，但在這個階段，我們先需要確認的是哪些例外真的需要讓人介入，以及人工介入後系統應該留下什麼狀態。

人工介入仍然是自動化流程的一部分

這個專案原本希望減少 Email、Excel 與人工轉單，因此在設計流程時，很自然會希望能自動處理的事情盡量自動往下走。但實際把訂單、ERP 與合作條件串在一起之後，可以看到有些判斷很適合交給系統，有些則需要保留人工處理的空間。

正常、規則明確的訂單可以直接自動往下處理；資料有問題而且來源端能修正的，就退回合作通路；暫時性系統問題如果可以安全重新執行，可以進入 Retry；結果不明的情況需要先停下來確認；真正需要例外處理的少數訂單，再交由有權限的人決定是否 Override。

這種做法仍然保留了人工，但人工出現的位置已經和原本不同。以前人需要逐筆搬資料與輸入 ERP，現在人的工作比較集中在系統無法可靠判斷的例外。對製造商來說，這樣的自動化才比較有機會把大量重複工作拿掉，同時保留處理特殊情境的能力。

系統拿掉人工操作後，也要接住原本由人記得的事情

走到這裡後，我們也開始遇到另一個很實際的問題。人工處理訂單時，即使流程沒有明確的狀態欄位，負責的人通常知道自己手上有哪些事情還沒完成。某一張單 ERP 沒送成功、某一份資料還在等補件，這些事情有時候靠工作習慣、Email 或人員記憶維持。

自動化之後，如果 ERP 失敗只是留下一筆 Error Log，但沒有人收到通知，也沒有地方可以看到目前有哪些訂單卡住，那原本人工負責追蹤的工作其實沒有真正被系統接走。系統只是把「人輸入資料」自動化，例外仍然可能悄悄停在流程中間。

因此這個階段需要處理的不只是 Retry、Reject 或 Force Send 本身，也包括誰會知道有問題、誰負責確認，以及問題處理完之後怎麼讓訂單重新回到正常流程。這也是後來會需要 System Admin、例外狀態與人工處理入口的原因。

下一步開始從「訂單成立」走向「真的可以生產」

前一篇我們把一筆訂單什麼時候可以成立逐漸定義清楚，這一篇再把成立之後可能出現的例外拆開。資料問題可以 Reject，可以安全重做的系統問題可以 Retry，狀態不明時需要停下確認，而少數需要人工例外處理的情況，則可能透過有權限、有紀錄的 Override 繼續往後。

但即使訂單成功進入 ERP，還有另一個狀態沒有被解決。

前面幾篇曾經提過，這個製造流程裡，訂單成立的時候最終製作檔可能還不存在。也就是說，一張訂單可以是有效交易，也可以已經成功進入 ERP，但工廠仍然還沒有足夠條件開始生產。

這會把下一個問題從「系統有沒有成功建單」往製造現場再推一步：訂單成立之後，還需要經過哪些事情，才真正變成一張可以進入生產的訂單？

有興趣知道更多的，也歡迎和我聯繫交流( kota@yujing.io )！