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

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

上一篇整理 ERP 導入過程中的需求訪談時，我提到一個現象：使用者說「我們都是這樣做」，通常還需要繼續確認適用範圍與例外，才能變成系統可以執行的規則。

但實際參與後面的 ERP 討論，還會遇到另外一種情況。有些問題已經和訪談深度沒有直接關係，因為公司目前根本還沒有一個明確答案。新系統提供了幾種可能的做法，大家理解差異之後，才開始討論未來到底要採用哪一種。

系統開始要求選擇，原本沒有答案的問題才會出現

其中一次在討論銷售訂單產生採購需求時，ERP 顧問先問採購需要看到多細的資訊。系統可以按照料號，把多張訂單的需求數量加總之後再轉採購單；也可以保留訂單關係，一張訂單對應一張需求繼續往下走。現場開始討論哪種方式比較符合未來工作，有人傾向一對一，有人的工作則比較接近把備用料集中處理。討論到中間時，導入方直接說了一句：「因為我們也還不確定未來的方式會怎樣。」

其實組織在導入新系統時，很多時候內部的 SOP 依然處於模糊的狀態。顧問提供了系統流程的選項，導入方也聽得懂兩種方式的差異，只是過去沒有把這件事情正式定義成一條規則。舊的工作方式可以靠既有系統、個人習慣與部門之間的協調繼續運作，等到新的 ERP 要設定流程時，才必須回答未來究竟要逐單處理，還是把需求彙總之後再處理。

另外一段採購討論則走向比較明確的結果。系統原本允許銷售訂單直接產生採購單，不需要先建立請購。導入方確認公司採購需要先經過請購，而且請購還需要一層審核，因此最後決定把直接轉採購的路徑鎖掉，要求採購一定從請購流程進來。

因此，提出系統流程的選項其實有一點「強迫決定」的作用。有可能公司很快就能確認正式做法；也有可能，導入方第一次發現 SOP 在這裡有漏洞，過往其實還沒有人真正決定過。

公司可以正常運作，不代表每一個流程都有明確的決策機制

如果沿用既有工作方式，導入方未必需要回答所有問題。例如需求要不要逐張訂單往後追蹤，只要現在的採購、生管與業務有一套大家熟悉的協作方式，就可以繼續工作。遇到不同品項時，也可能由熟悉的人自行調整。

導入 ERP 之後，很多原本可以留在人腦裡的彈性會開始被要求轉成系統設定。系統需要知道一筆需求到底要走哪條流程、哪些單據允許直接產生、哪些需要審核，以及不同角色能不能自行改變路徑。原本沒有必要做成正式制度的事情，因此會在導入過程中一一浮現。

因為套裝系統通常不會按照每一家公司的每一個習慣無限延伸，而是提供幾種已經設計好的流程，導入方需要決定哪些符合自己的管理方式。這些限制讓一些過去可以模糊處理的問題，開始需要有明確答案。

如果這時候第一個反應都是要求系統配合現況，就有可能出現另一個問題。假設公司現在有五種例外，每一種都要求 ERP 客製成不同流程，但這五種差異背後的判斷依據其實沒有人說得清楚，那麼客製化做的事情，只是把原本存在於人員經驗裡的複雜度搬進程式。

有些特殊流程確實有存在的理由，也值得系統配合；有些則可能只是受到舊系統限制、過去工作分工或歷史習慣形成。ERP 導入提供了一個重新確認這些差異是否仍然需要存在的機會。

使用者知道怎麼工作，不一定有權決定公司未來怎麼工作

這裡也讓我注意到另一個問題。導入會議裡坐在現場的人，通常是最熟悉實際操作的人，所以顧問很自然會問他們：「那你們未來要用哪一種？」

有些問題確實可以由現場直接決定，例如某個畫面需要顯示哪些操作資訊，或現行流程裡一個明確的操作方式。但像「需求要逐單處理還是彙總處理」這類問題，可能同時影響採購效率、訂單追溯、生管作業與後續管理報表。實際使用者可以很清楚地說明每種方式會帶來什麼影響，最後選哪一條作為公司正式流程，未必是他有權限承擔的決策。

因此，當導入方說「這個我們還不確定」時，繼續追問有時不會得到更好的答案。需要先區分的是，目前缺的是資訊，還是缺一個有權限做決定的人。

如果是資訊不足，可以再補流程、數據或實際案例；如果牽涉跨部門權責與管理制度，就需要把問題提高到適合的決策者，例如部門主管或是老闆。否則會議很容易出現大量「這個之後再確認」、「這個回去問一下」，下一次顧問再碰到相同設定時，又重新討論一次。

當場沒有結論的議題，需要被留下來

如果 FDE 參與這類導入，我認為一個很重要的工作，是把「還不知道」從會議裡的一句話，轉成一個可以被追蹤的決策點。

例如「訂單需求到底要逐單還是彙總轉採購單」不適合只記錄成「採購流程待確認」，因為幾週之後再看到這句話，很可能已經忘記當時為什麼需要討論。至少需要留下當時正在選什麼、各自會影響哪些流程、目前缺少什麼資訊，以及最後應該由誰決定。

可以先整理成類似這樣的議題追蹤表：

這份紀錄的關鍵，一方面是後續追蹤尚未決定的議題，另一方面是協助把問題定義到可以被決定的程度，包括目前有哪些合理選項、不同選項會改變什麼，以及這個決定需要由誰決定。

當 ERP 告訴我們「這裡可以走 A，也可以走 B」，FDE 可以利用這個系統限制，要求組織確認未來正式採用哪一個作業流程。如果系統的標準做法真的不符合需求，再進一步討論客製化，也會比較清楚為什麼需要付出額外的開發與維護成本。

如果組織尚未完成作業流程的標準化，就直接讓系統同時支援 A、B、C，再加上幾條特殊例外，最後得到的彈性未必對導入方有幫助。使用者依然需要在每一次操作時自己判斷要走哪條路，只是原本的人工作業多了一套更複雜的系統可以選。

Clarify 到 Decide：建立適合決策發生的條件

我目前把 FDE 的工作分成 Observe、Clarify、Decide、Encode、Verify 五層。上一篇主要處理 Observe 與 Clarify，先把使用者描述的流程、適用範圍與例外問清楚；這一篇主要解釋從 Clarify 到 Decide 的過程。

Clarify 在這裡要處理的是，先確認眼前的問題究竟是系統功能不支援、現行流程沒有說清楚，還是公司根本還沒有決定未來的做法。這三種問題後續處理方式差很多，如果沒有先區分，很容易過早進入客製化討論。到了 Decide，FDE 的工作也不等於替公司下決策。比較接近的是協助把 Decision 定義清楚，整理系統允許的選項與實際影響，找到真正有權限決定的人，並確保最後的選擇可以回到系統設定與後續流程。

當然，即使公司已經決定了流程，仍然會留下另一類問題。例如大家可能已經同意「替代料由生管或物控人工判斷」，但「人工判斷」本身還沒有說明這個人到底依照哪些條件決定。這就會進入下一篇要處理的問題：當流程裡仍然存在大量「看情況」、「依經驗」與「由某個人決定」時，FDE 要怎麼判斷哪些經驗可以進一步被整理成明確規則。

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