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

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

前兩篇談到，這個專案一開始看起來只是 API 串接，後來逐漸確認製造商真正想發展的是按需製造。當不同通路開始進來之後，我們也需要處理另一個問題：入口可以不同，但進入工廠之前，仍然需要逐漸確認一組足以讓製造流程往下走的必要資訊。

到這個階段，方向其實已經比一開始清楚很多。我們知道系統要承接外部通路的訂單，要處理不同商品與工廠 ERP 之間的對應，也知道未來可能同時存在 API、Web App 與檔案上傳幾種接單方式。不過，真正開始把這些方向轉成產品之後，還是有很多細節無法只靠前面的需求訪談決定。很多原本聽起來很合理的需求，都要等到我們實際拿一筆訂單、一個商品或一次操作往下拆，才看得出原本的規則能不能成立。

一筆訂單裡，混著不同時間才會確定的資訊

當時我以 PM 的角色開始整理通路實際會提供的資料。我們拿著合作過程中的訂單內容、附件與既有 Email 往來，一項一項確認製造商需要哪些資訊，才能把外部訂單轉成可以執行的製造工作。表面上看，一張訂單最基本的內容很直覺，包括商品、數量、設計與收件資訊，但繼續往下整理之後，還會碰到包裝方式、標籤、出貨方式、價格條件、商品規格與製作圖檔。

這些內容原本放在同一封 Email 或同一份資料裡，很容易全部被當成「訂單資料」，但它們其實不是在同一個時間點決定。有些資訊幾乎每一次都會改，例如這次的數量、設計圖與收件地址；有些條件則可能在雙方開始合作時就已經談好，之後很多張訂單都會沿用，例如商品規格、價格方式或包裝要求。如果每張訂單都重新傳送所有資訊，後續很容易出現前後版本不一致，也會開始分不清楚某個欄位代表的是這次訂單的特殊要求，還是雙方原本就已經確認的合作條件。

這個問題後來會延伸到合約與訂單之間的關係，不過當時我們沒有直接先設計一套合約系統，而是繼續沿著實際流程整理，先確認這些資訊分別在什麼時候產生、由誰確認，以及後面的製造流程會怎麼使用。

「第一次收到商品」和「需要打樣」原本被放在一起

打樣流程是另一個讓需求逐漸改變的例子。一開始我們曾經考慮，如果系統第一次收到某個商品或 SKU，就把它當成需要打樣的新商品。這個規則在最初的討論裡很合理，因為新的商品第一次進入工廠，確實可能需要先確認成品，因此也很容易直接把「第一次出現」當成系統可以使用的判斷條件。

工程師準備把這個規則往產品裡放時，開始用不同情境測試它。例如相同商品規格只換了一張新的設計圖，系統是否應該把它當成新的商品；如果外部通路使用了一組新的 SKU，但工廠其實早就做過完全相同的產品，系統第一次看到這個編號也不代表工廠第一次生產。另一種情況是商品資料早就存在，但客戶這一次仍然希望重新打樣，單純依照資料是否出現過，也無法判斷客戶這次的要求。

幾個情境放在一起之後，我們才把原本的一個規則拆成不同事情：系統有沒有看過這筆商品資料、工廠這次是否需要建立新的製作條件，以及客戶有沒有提出打樣需求。前者可以從資料判斷，後面兩件事則仍然包含製造現場與客戶需求的判斷。

因此最後沒有把「第一次收到」直接做成打樣規則，也沒有在這個階段另外建立完整的打樣流程。當時的取捨是先讓這部分維持人工處理，等實際案例累積到可以形成穩定條件之後，再決定哪些判斷適合交給系統。這也讓需求文件裡原本很簡單的一句「第一次的商品需要打樣」，在準備實作時被重新拆成幾個不同狀態。

訂單成立時，製作檔可能還不存在

圖檔則讓我們碰到另一種流程上的假設。工程師一開始從系統處理的角度思考，會希望訂單進來時，相關的製作檔案也已經準備完成，這樣系統可以一次把訂單資料與檔案收齊，再交給後面的流程處理。但我們回到製造商目前的工作方式確認後，實際順序和這個假設不同。

現場通常要先有一筆正式交易或 ERP 訂單，後面的美編或製作人員才會開始處理相關檔案。因此在訂單成立的那個時間點，最終可以拿去生產的製作檔本來就可能還不存在。這個差異表面上只是檔案上傳時間不同，放進系統之後卻會影響訂單可以在什麼條件下成立，以及後續流程由誰承接。

如果把最終製作檔設定成建立訂單的必要條件，現場原本可以先往下走的交易反而會被系統擋住；如果允許訂單先成立，後面就要繼續處理誰負責補檔、在哪一個時間點補，以及檔案還沒準備好時，流程應該停在哪一個階段。原本透過 Email 與人工處理時，業務可能知道哪一張圖還沒到，美編也知道哪些訂單正在等待資料，這些狀態很多都存在人員的工作習慣裡。當自動接單開始取代部分人工轉單之後，原本跟著人一起完成的追蹤工作也需要重新被看見。

所以後來在整理需求時，我們不只確認「一筆訂單有哪些欄位」，也會繼續確認某一項資料在流程的哪個時間點才會出現。在資料還不存在的期間，訂單是否可以成立、下一個人能不能先開始工作，會直接影響系統最後要怎麼設計。

使用者原本說要加欄位，後來調整的是操作方式

另一個例子發生在訂單畫面。當時我希望畫面上能多顯示一些資訊，原因是通路可能一次上傳很多筆訂單，上傳完成之後需要確認這次送進來的資料是不是完整、筆數是否正確，以及有沒有哪一筆資料出現問題。從功能需求來看，最直接的描述就是在訂單列表增加幾個欄位。

工程師在討論畫面時繼續確認使用者看到這些欄位之後要做什麼。我們重新回到實際操作情境，發現使用者關心的範圍主要是「剛剛這一次上傳的資料」，他需要先知道這一批資料有多少訂單、哪些成功、哪些有問題，再往下查看特定訂單的內容。如果直接在完整訂單列表增加欄位，雖然資訊變多了，使用者還是需要自己從大量歷史訂單裡找出剛才上傳的那些資料。

因此後來的方向從單純增加欄位，逐漸調整成先看到一次上傳的 Batch，再從 Batch 往下查看裡面的訂單與明細。這樣的資訊結構比較接近使用者實際檢查資料的方式，發生問題時也比較容易回到某一次上傳追查。原本是一個很小的 UI 需求，繼續確認使用情境之後，最後調整的其實是資訊怎麼被組織，以及使用者完成確認工作的順序。

工程師提出的反例，會把模糊的規則放大

這幾次討論的過程其實很相似。我會先從客戶的商業需求與現場流程整理出目前理解的做法，工程師在準備產品與實作時，再用不同情境確認這個規則能不能涵蓋實際狀況。如果出現規則無法解釋的案例，我們就回頭確認當初描述的是一個長期會成立的條件，還是目前流程裡剛好形成的做法。

第一次收到商品就打樣，後來被拆成資料是否存在、製作條件是否需要重新建立，以及這次是否有打樣需求；訂單需要製作檔，往下確認之後才知道製作檔可能在訂單成立之後才出現；訂單列表需要更多欄位，則因為重新確認使用者的工作內容，最後改成以 Batch 作為檢查資料的入口。

這些變化沒有改變按需製造的整體方向，卻會影響系統進到現場後能不能順著原本的工作方式運作。如果前期先把所有訪談內容整理成固定功能，之後直接按照功能表開發，很多還沒有被驗證的假設也會一起進入產品。這個案子的需求反而是在一次次準備實作、出現反例、再回到現場確認的過程裡逐漸變得具體。

PM 整理需求，工程師也會反過來影響需求

這也是我在這個案子裡比較明確感受到的 PM 分工。我的工作主要是把客戶想發展的方向、現場流程、合作方式與目前的限制整理出來，再確認下一個階段需要解決哪些問題。這些資訊到了工程師端之後，還會再經過產品與實作角度的檢查，因為一段在會議裡可以理解的描述，不一定已經足以變成系統規則。

工程師在設計資料、流程或操作方式時，如果遇到規則無法涵蓋的情境，或發現一個功能背後仍然缺少判斷條件，這些問題就會再回到我這邊。有時候需要找製造商確認實際流程，有時候需要重新整理我們原本的假設，也有些需求最後會決定先保留人工處理。

所以在這個專案裡，PM 和工程師之間的關係比較像持續來回修正。PM 把商業目標與現場條件帶進產品，工程師透過產品設計與實作把其中模糊的地方放大，再由 PM 回到使用情境確認。需求不是在第一次訪談結束時就完整定義，而是在這個過程裡逐漸收斂。

有些條件開始顯得不適合放在每一筆訂單裡

隨著前面的細節逐漸被拆開，我們也開始看到另一類問題。有些資訊每一筆訂單都會改，但價格、商品規格、包裝方式與部分交付條件，可能會被同一個合作關係下的很多張訂單反覆使用。如果每一次下單都重新傳入這些條件，除了增加資料量，也可能出現這一張訂單使用舊價格、下一張訂單又帶入另一個版本的情況。

但把這些內容直接固定在系統裡也會遇到問題，因為合作條件本身還是會調整。價格可能改版，商品規格可能新增，包裝與交付方式也可能重新談過。系統接下來需要處理的，是這些條件應該放在哪裡，以及條件更新之後，已經成立的訂單要不要跟著變動。

前面的訂單拆解讓這個問題逐漸變得具體：每一次交易才決定的內容，可以跟著訂單進來；會被一段合作期間反覆使用的條件，則需要另外找到適合的位置保存。下一篇會接著這個方向，談我們怎麼從實際下單流程開始把「合作條件」和「訂單內容」分開，以及合約的概念為什麼會逐漸出現在系統裡。

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