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

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

前一篇提到，我們在把訂單流程往下拆的時候，開始注意到有些資訊會跟著每一筆交易改變，有些條件則會被很多張訂單反覆沿用。當時我們還沒有急著把它整理成一套完整的合約系統，而是先回到實際合作方式，確認商品、通路與訂單之間到底有哪些差異。

這個過程裡，有一個原本很直覺的想法先被打破了。因為專案一開始也會參考一般電商的做法，所以很自然會先從 SKU 去想商品，只要知道某個 SKU 代表哪一種商品，訂單再帶入數量、價格與收件資訊，系統看起來就已經有足夠資料可以往後處理。

但這套想法放進按需製造之後，很快就不夠用了。

原本想用 SKU 定義商品，但實際生產內容每次都可能不同

一般電商裡，SKU 通常可以很穩定地代表一個商品。消費者買同一個 SKU，拿到的會是相同規格、相同內容的商品，系統只需要知道買了哪個品項與多少數量，就可以往庫存、出貨與金流流程繼續處理。

這個專案的情況不太一樣。製造商提供的是依客戶需求生產的服務，即使兩張訂單使用相同的尺寸、材質與加工方式，實際拿去生產的製作檔案仍然可能完全不同。對工廠來說，它們可以使用相同的製造規格，但最後做出來的內容並不相同。

所以 SKU 可以幫助我們理解某一種規格，例如使用哪種材料、什麼尺寸、採用哪一種加工方式，但它無法完整代表這一次真正要生產的東西。系統如果只知道 SKU 和數量，仍然不知道這一張訂單最後應該使用哪一份製作檔。

這個差異也讓商品資料開始被拆成兩個層次。一部分是可以被重複使用的製造規格，另一部分則是每一次訂單才會出現的客製內容。前者比較穩定，後者會隨著不同客戶與不同訂單持續變化。

訂單的客製化很一致，但不同通路的合作條件並不一樣

當我們把商品本身的問題拆開之後，另一個差異也開始變得比較清楚。不同合作通路雖然都會把客製化訂單交給製造商，但彼此的合作條件不一定相同。

例如同一種製造規格，A 通路可能談的是一組價格與交期，B 通路則有另外一組價格與交期。兩邊下單的商品都需要帶入客戶自己的製作檔，也可能使用相同的材料與加工方式，但製造商承諾給不同通路的商務條件並不一定相同。

如果把這些條件全部直接放在商品資料裡，系統就會很難處理。因為同一種商品規格可能同時服務多個合作通路，而不同通路使用的價格、交期與其他合作方式可能不一樣。

反過來，如果每一張訂單都重新帶入價格、交期與所有合作條件，也會開始產生另一種問題。同一個通路明明已經和製造商談好合作方式，卻仍然需要每次下單重新描述一次，而且不同訂單之間還可能出現不一致。

這時候我們開始把原本混在一起的資訊拆得更細。

要先看懂這門生意，才知道哪些資訊應該固定

沿著實際訂單整理之後，系統裡大致開始出現三種不同性質的資訊。

第一種是製造商可以重複提供的製造規格，例如商品尺寸、材料、加工方式或其他比較穩定的生產條件。這些資訊不會因為每一個客戶的圖案不同就全部重新定義。

第二種是製造商和特定合作通路之間的合作條件，例如價格、交期，或其他雙方事先談好的規則。這些資訊會因合作對象不同而改變，但在一段合作期間裡通常會被多張訂單重複使用。

第三種則是每一次交易才會確定的內容，例如這次下單的數量、真正要生產的製作檔、收件資訊，以及當次才出現的特殊要求。這些資料必須跟著訂單走，因為即使是同一個通路、同一種商品規格，每一張訂單仍然可能完全不同。

這個分類不是一開始就在系統設計裡存在，而是從幾種不同情境慢慢整理出來的。SKU 不足以代表完整成品，讓我們把製造規格和客製內容拆開；不同通路使用不同價格與交期，又讓我們看見合作條件也不適合直接綁在商品上。

如果一開始只從資料表或欄位設計往下想，很容易先決定「這個欄位放在哪裡」，但這個專案後來比較重要的判斷，是先理解背後的商業模式：哪些東西會因客戶而改變、哪些會因通路而改變，又有哪些條件其實會被很多張訂單重複使用。這些差異釐清之後，系統該怎麼拆才開始有比較明確的方向。

問題開始從「有哪些欄位」變成「這些資訊在什麼時候確定」

以 PM 的角色來說，我一開始比較容易從欄位去整理需求，例如訂單需要商品、數量、價格、圖檔與交期。工程師在準備實作時，則會繼續確認這些資訊到底從哪裡來，以及什麼時候應該被確定。

價格就是一個很直接的例子。如果某個通路已經談好一組價格，訂單每次進來時是否還需要再帶一次？如果需要帶，系統收到和原本約定不同的價格時應該相信哪一邊？如果不需要帶，系統又要去哪裡找到這個通路目前有效的價格？

交期也有類似問題。不同合作通路可能有不同承諾，如果直接把交期寫在商品本身，同一商品就無法同時對應不同合作方式；但如果每一張訂單都重新輸入，也很難確認這個日期是根據既有合作條件產生，還是這次臨時指定。

這些問題讓需求開始從「一張訂單要有哪些欄位」往資料的生命週期移動。我們需要知道哪些資訊在雙方開始合作時就已經確定，哪些會在合作期間調整，又有哪些資料必須等到真正下單時才會出現。

合作條件需要有一個可以被保存的位置

當這些資訊逐漸被拆開後，系統裡才開始需要一個地方，保存製造商和特定通路之間會反覆使用的合作條件。

我們後來逐漸把這一類資料整理成「合約」的概念。這裡的合約不只是法律文件，也不只是把紙本契約搬進系統，比較接近系統對目前合作條件的一份可執行紀錄。

例如某個合作通路使用哪些商品規格、價格怎麼計算、交期怎麼約定，以及其他會反覆影響後續訂單的條件，都可以從這裡取得。實際下單時，通路就不需要每一次重新描述整套合作方式，只需要帶入這次真正會變動的內容。

這樣拆開之後，訂單的角色也比較清楚。訂單描述這一次實際要生產什麼，包括數量、製作檔與收件資訊；合作條件則描述這個通路目前是在什麼規則下和製造商交易。

這個取捨也讓系統比較能面對不同通路

前一篇提到，我們希望平台可以接不同合作通路，但又不希望每增加一家就把一整套新的邏輯寫進核心流程。把商品規格、合作條件與訂單內容拆開之後，這個問題也比較容易處理。

不同通路可以有自己的價格與交期，但製造商不需要因此建立另一套完全不同的商品；每一張訂單可以帶不同的製作檔，也不需要因此把每一個客製內容都建立成新的固定商品。

系統需要保存的是相對穩定、可以重複使用的資訊，同時讓真正會隨交易改變的內容留在訂單裡。這個方向沒有消除不同通路之間的差異，也沒有把所有商品硬套成相同模式，而是讓不同類型的變化各自留在比較適合的位置。

合作條件被拆出來之後，下一個問題是版本

當合約這個概念開始出現後，新的問題也很快跟著出現。

合作條件不會永遠不變。價格可能重新談過，交期可能調整，商品規格也可能新增。如果今天雙方把某一個商品的價格從 100 元調整成 110 元，明天的新訂單可以使用新價格，但昨天已經成立、還沒有完成生產的訂單要不要一起變成 110 元？

如果系統永遠只讀取目前最新的合作條件，過去已經成立的交易就可能隨著後面的修改一起改變。但如果每次修改都直接複製出另一套資料，系統又需要知道哪一個版本從什麼時間開始有效。

所以當我們把合作條件從訂單裡拆出來之後，下一個需要處理的問題也逐漸變得具體：合作條件改版時，已經成立的訂單應該保留什麼，以及系統要怎麼知道一張訂單當時是依照哪一個版本成立的。

下一篇會接著這個問題，談我們後來怎麼處理合約版本，以及為什麼訂單在成立的那一刻，需要保留當時真正使用的合作條件。

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