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

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

這一系列文章最早從一個很明確的需求開始。製造商希望合作通路可以透過 API 把訂單送進來，再把資料轉進原本使用的 ERP。以系統開發的角度來看，其實就是系統整合，只要確認 API 規格、欄位 Mapping、驗證方式、商品對應與 ERP 寫入，就可以逐步進入開發。

不過後來發現，真正花時間處理的幾乎都不是 API 本身。我們往回確認製造商為什麼需要這個 API，才逐漸看到他們正在嘗試的是一種新的按需製造合作模式；開始開發之後，又陸續碰到不同通路的能力差異、商品與製作檔的關係、合作條件、合約版本、訂單成立的邊界、ERP 失敗後怎麼處理，以及製作檔仍然留在 NAS 裡的現場流程。

再往後，問題甚至已經離開純粹的系統設計，開始碰到第一線人力不足、旺季、流程改動的接受度，以及主管雖然認同方向，現場卻沒有辦法一次承接完整改造的情況。

反思這一整段過程，如果說有個 FDE 的角色，其實混雜了 PM、架構師的梳理與判斷，這些工作很多發生在正式規格形成以前，還有不少發生在功能已經可以使用之後。

一開始收到的是 API 需求，但還需要確認它背後要支撐什麼商業模式

如果直接按照最早收到的需求開始做，第一版很可能就是針對目前這一家合作通路建立 API，再把訂單寫入 ERP。這在當時完全合理，因為眼前確實有一個合作方需要串接，也有很明確的系統目標。

但往前問這個合作未來會怎麼發展，才發現製造商希望承接的不只是眼前這一家通路，而是讓更多品牌、IP 或銷售通路把低量、多樣的訂單交給工廠生產。第一家合作通路有自己的開發團隊，可以直接串 API，但下一家合作方可能沒有任何 IT 能力。如果系統從一開始就完全按照第一家合作方的能力設計，未來每多一種合作模式，就可能再重新做一次整合。

因此後面才逐漸留下 API、Web App、檔案上傳等不同入口，同時開始思考哪些資訊應該成為平台共同要求的製造資訊。

這一段如果只從最早的功能需求出發，其實不一定會自然出現。當時需要先理解製造商想建立什麼樣的合作方式，再回頭看現在這個 API 應該被放在什麼位置。因此，此專案內 FDE 的一部分早期工作，是協助客戶把「現在想做的功能」重新放回商業模式裡確認。

很多規則沒有辦法靠一次需求訪談就整理完整

商業方向比較清楚之後，規格其實還是不完整。例如當時曾經討論過，是不是第一次出現的 SKU 就應該走打樣流程。這個規則一開始聽起來很合理，但工程師開始提出不同情境之後，很快就出現問題。同樣的製造規格換了一張圖算不算第一次、新的外部 SKU 如果工廠以前做過相同產品怎麼處理、客戶明確要求打樣但系統已經看過這個商品又怎麼辦。

製作檔也發生過類似的事情。從資料模型來看，很容易假設一張完整訂單應該同時存在正式製作檔，但現場實際流程是交易成立、ERP 訂單建立之後，工程端才開始製作正式生產檔。如果照原本的系統假設要求製作檔先存在，系統反而會把現場原本能運作的流程卡住。

商品資料也是一路做下去才逐漸拆清楚。原本很自然地從電商 SKU 出發，但這個按需製造模式裡，相同尺寸、材質與加工方式可以搭配完全不同的客製圖面；同一個製造規格，又可能因為不同合作通路有不同價格與交期。最後才慢慢拆出可以重複使用的製造規格、通路合作條件，以及每一筆訂單自己的客製內容。

我覺得不是客戶說不清楚，也不是我問不來，還是得從真實情境中歸納，才看得到當時沒想到的例外情況。當時的工作方式是 PM 從商業模式、訪談與現場流程先形成一個初步理解，工程師再用資料、產品與實作角度提出反例。只要反例足以影響設計，就再回到現場確認。經過幾次來回之後，規則才逐漸穩定到適合被寫進系統。

因此 FDE 在這一段做的事情，也不只是把客戶說的內容整理成 User Story。需求本身還在形成，工程開發的思考也同時參與了需求探索。

系統邊界也是一路做出來的

等到需求開始變清楚之後，下一個挑戰是範疇，哪些功能應該做到這一套系統裡。

如果認真看，超多流程都能找到值得改善的地方。合作條件需要版本管理，所以開始出現 Contract Version 與 Snapshot；訂單有多個品項，需要決定一個品項錯誤時整張單要不要 Reject；ERP 可能 timeout，因此需要區分 Retry、Reject 與 Force Send；製作檔放在 NAS，又缺少完整版本管理，繼續做下去就會變成圖面管理系統。

然而時間與資源有限，不適合全部都在同一階段解決。圖面管理是一個很典型的例子。我們知道 NAS 上的檔案版本與狀態管理不完整，也知道如果建立正式圖面管理，長期追蹤會比較清楚。但真正推動後，工程端原本找檔、修改、存檔與確認版本的工作方式都會一起改變。當時又碰到缺人與旺季，第一線對流程變動的接受度也不高，主管很難在那個時間點要求團隊全面切換。

最後的退而求其次，承認這個問題存在，先保留既有 NAS 流程。這類取捨在專案裡其實很常發生。Backlog 裡可以放進很多合理功能，但真正需要判斷的是哪些事情現在做會讓主要目標更容易達成，哪些事情雖然值得改善，當下的改動成本卻更高。因此 FDE 在這個案例裡也一直參與系統邊界的判斷，包含決定哪些需求暫時不要做。

很多技術問題做到後面，其實是在重新分配營運責任

訂單自動化之後，又產生了權責問題。例如「送 ERP 失敗」從技術上看是一個 Error Handling 問題，但真正深入理解後，很多還沒想清楚的決定。

如果是商品資料錯誤，應該由合作通路修正；如果是 ERP 暫時連線失敗，可能適合 Retry；如果 timeout 之後根本不知道 ERP 有沒有成功建單，就不能直接重新送一次；某些現場例外經過人工確認後仍然需要繼續，則可能需要 Force Send。

接著又會出現下一層問題：誰可以 Force Send、什麼錯誤能跳過、未知錯誤應該通知誰，以及哪些問題屬於 Sales、維運人員或 System Admin 的責任。

原本人工接單時，這些事情通常由同一個人一路處理。資料不完整就回頭問、ERP 錯了就看一下、真的不行再找其他人。流程自動化之後，原本跟著人的判斷被拆散，系統必須開始明確描述每一種狀態接下來由誰處理。

因此，專案中的技術決策必須再被翻譯成營運角度，才能回到企業真正的工作流程。API 回什麼錯誤碼只是其中一層，後面還需要知道誰會收到、誰有能力處理，以及這個問題處理完之後怎麼重新回到正常流程。

系統做出來之後，需求探索其實還沒有結束

功能完成後，當使用者開始實際操作，會出現很多之前不曉得的流程和判斷。原本以為很重要的欄位可能沒有人使用，原本認為很少發生的例外可能每天出現；一個流程在文件上只有三個步驟，實際操作時使用者卻需要來回切換不同系統。甚至系統設計本身沒有錯，第一線當下也可能因為工作量與人力限制而沒有能力承接新的操作方式。

工程端的案例就是如此。完整圖面管理有清楚的價值，但當時人力不足、又正值旺季。如果按照完整設計一次推上去，很可能讓新系統本身成為額外工作。

因此實際採取的是逐步導入。NAS 可以保留就先保留，Web App 先服務適合的角色，需要改變使用者操作的地方盡量降低，讓新的接單與 ERP 流程先進入真實工作環境。

這也讓產品在上線之後仍然持續被現場修正。在這個案子裡，FDE 的工作沒有在功能交付時結束。使用者開始使用之後產生的新資訊，仍然會回到下一輪產品設計。

有些還沒有穩定的工作，我會先自己做

逐步導入的過程中，有些功能如果頻率還不高，又可以仰賴人工完成，我不會讓工程師動工，而是手動先幫使用者把這段缺口補起來。可能是整理資料、補一個欄位、處理還沒有自動化的轉換，或用既有工具把兩個流程暫時接起來。

這麼做的好吃，是使用者可以把完整工作跑過一次。實際操作之後，如果同一件人工工作每次都用相同方式處理，使用者也沒有再出現新的問題，這時規則才比較適合交給工程師。相反地，如果每次處理都有新的例外，代表目前對問題的理解還沒有穩定，太早把邏輯寫進程式，後面修改的不只是一個功能，也可能連資料結構、Validation、權限與例外流程一起受到影響。

所以人工補位在這個階段會有驗證需求的好處。不過人工流程不會永久存在。當某一段工作開始高頻、重複，而且處理規則已經穩定，就應該盡可能自動化做完。PM 在中間做的一部分工作，就是確認什麼時候這個問題已經穩定到值得正式產品化。

回頭看，很多 FDE 的工作發生在開發前和交付後

如果把一般軟體專案簡化來看，常見流程可能是需求、規格、開發、測試、上線。當需求與驗收條件都已經相對穩定時，這種分工可以非常有效率，SI（系統整合商）也可以根據清楚的規格完成大量系統整合與導入工作。

這個按需製造專案的特點，是需求一開始有很多不確定性。新的商業模式還在驗證，下一個合作通路會有什麼能力並不知道；工廠原本有大量人工判斷沒有被寫成規則，製作檔與 ERP 的順序也需要進入現場後才看得清楚；第一線可以接受多少流程改動，也必須真的開始使用才會知道。

因此規格形成之前必須花時間釐清，理解商業目標、走進現場、建立初步假設，再讓工程師用反例測試，之後才逐漸形成可以開發的規則。

另外一部分工作則是系統做完後，當使用者真的開始操作、例外開始出現、人工補位開始重複，這些資訊又會反過來影響下一版產品。

如果用這個案例來看，FDE 和比較典型的 SI 合作方式差異比較明顯的地方，也集中在這兩端。當需求已經相對穩定、系統邊界與驗收標準清楚時，傳統 SI 模式可以有效率地完成交付；當企業仍在探索新的商業模式，連「該做什麼」本身都會隨著現場持續改變時，就需要更多工作發生在正式開發前與上線後。

這個專案裡，FDE 實際多承接了哪些工作

回頭看前面幾篇文章，最早從 API 需求往回確認製造商真正想建立的按需製造模式；接著透過現場流程與工程反例，把原本還不穩定的商品、合約、訂單與製作檔規則逐步拆清楚；系統範圍擴大時，再一起判斷哪些事情現在需要做，哪些像圖面管理可以暫時保留人工。

進入正式流程之後，又需要把 Retry、Reject、Force Send 這些技術狀態重新對應到企業裡真正負責處理問題的人。系統開始交給第一線使用後，則繼續觀察 Adoption Cost，控制每一次需要改變的幅度；遇到尚未穩定的流程，有時先用人工把缺口補起來，等規則穩定後再正式交給工程師。

這些工作很難在專案一開始全部寫進需求規格，因為很多答案當時還不存在。

這個專案如果一開始的流程、商業模式與使用方式都已經非常清楚，可能也不需要這麼多來回。但當企業正在嘗試一種新的合作模式，需求會隨著合作通路、工廠現場與實際使用持續改變時，開發本身只是整個工作的其中一段。

回頭看這幾個月真正反覆發生的事情，是一起確認下一個值得解決的問題，把還模糊的規則放進真實流程測試，再判斷哪些內容已經穩定到值得正式寫進系統。

至少在這個 Manufacture-on-Demand 專案裡，這是 FDE 參與最深的一部分。

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