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

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

第一個通路能用 API，不代表後面的通路都會一樣

上一篇提到，這個專案一開始收到的需求是串接 API，但隨著我們往下理解，才逐漸發現製造商真正希望發展的是按需製造。未來可能有不同品牌、商家與通路，把少量、多樣的訂單交給製造商生產，因此接單系統也開始被當成一個可以持續承接外部合作夥伴的平台來思考。當這個方向確定之後，下一個問題就變得很具體：如果未來真的有很多合作通路，每一家要用什麼方式進來？

第一個合作通路有自己的開發資源，所以希望直接透過 API 發送訂單。從合作效率來看，這是很合理的做法。雙方把資料格式定義好，對方的系統可以直接把訂單送進來，製造商也不用再靠人員收 Email、整理 Excel，再把相同資料輸入一次。不過，製造商在討論後續合作對象時也提出一個現場觀察：這個產業裡即使規模不小的公司，也不一定有自己的開發團隊。有些公司習慣使用既有 ERP 或電商平台，IT 能力主要用來維持日常營運，很難為了新的製造合作另外安排一組工程師做 API 串接。

這個條件讓我們保留了原本規劃的 Web App。對沒有開發能力的通路，他們仍然可以依照平台提供的格式整理資料，再透過 Web App 或檔案上傳訂單；有開發能力的合作夥伴，則可以進一步談 API 整合。從商業端來看，這樣可以降低新的合作對象進入門檻，不需要每一家公司在合作之前都先完成一個 IT 專案。

入口可以不同，但後面的系統成本仍然存在

當時我比較關心的是合作夥伴能不能順利進來，工程師則會繼續往後看這些入口會留下什麼成本。如果今天一家公司用 API，下一家公司上傳 Excel，第三家公司又希望串自己的 ERP，每一家的欄位名稱、商品編碼與資料結構都可能不同。只要這些差異一路延伸到後面的訂單、價格、權限與 ERP 邏輯，系統就會逐漸累積只服務單一合作夥伴的規則。

第一家合作夥伴要求的特殊處理，可能只需要增加一個欄位或一個判斷；第二家再加入新的資料格式，也不一定會立刻造成問題。但隨著合作對象增加，開發端可能需要先判斷這張訂單來自哪個通路，才能知道接下來應該套用哪一組欄位對應、價格規則與流程。這些邏輯如果散落在系統不同位置，後續修改任何一項共用功能時，也需要一起確認各個通路的例外是否受到影響。

對一個剛開始驗證的新商業模式而言，早期為合作夥伴保留一些客製空間並不奇怪。當時真正需要逐步釐清的是，哪些差異來自合作方式本身，確實需要被保留下來；哪些只是不同公司使用不同格式表達相近的資料，可以在進入平台時先完成轉換。

另一個電商通路，讓商品對應問題浮現

這個差異在另一個電商通路的整合上變得很明顯。原本我們也規劃把這個通路的訂單自動接進來，技術上已經能取得訂單，也能取得商品與客戶資料，因此從 API 串接的角度來看，前面的流程並沒有太大的問題。真正開始準備建立 ERP 訂單時，我們才發現外部商品和製造商 ERP 裡的料件之間沒有一套穩定的對應方式。

電商平台有自己的 SKU，製造商 ERP 也有自己的料號，但部分商品的命名與建立方式並不一致。系統可以知道外部訂單買了哪一個商品、數量多少、價格多少，工廠真正開始處理時還需要知道對應的材料、尺寸、加工方式，以及最後應該建立哪一個 ERP 料號。只要中間缺少穩定的轉換規則，系統就無法可靠地決定後續應該怎麼建單。

最後我們選擇暫停這個通路的自動建單。已經開發的程式先保留，但在商品對應方式沒有整理清楚之前，繼續把訂單往 ERP 後面送，只會把不確定性一起自動化。這次暫停也讓我們把 API 串接和製造條件分得更清楚：系統成功收到商品名稱、數量與價格，只代表資料已經從外部平台進來；製造商能不能開始工作，還需要另一組足以轉成內部料件與製程的資訊。

平台開始需要固定「哪些資訊一定要有」

有了這個案例之後，我們再回頭看第一個通路時，問題就比較容易拆開。合作夥伴可以從不同入口送單，也可以保留自己的商品編碼與訂單格式，但系統仍然需要知道，一筆資料進入製造流程之前，至少要具備哪些條件。

例如外部通路可以繼續使用自己的 SKU，但系統必須有辦法找到它對應的製造品項；外部可以保留自己的訂單編號，製造商仍然需要一個可以追蹤單據的識別方式；圖片可以從不同來源傳入，但後續人員必須能夠找到與這筆商品相符的檔案。這些資訊原本散落在 Email、Excel、ERP 與人員經驗裡，開始自動接單之後，就需要逐項確認來源、對應方式，以及資料缺少時是否還能繼續往下處理。

這些條件並不是一開始就先整理成完整規格。第一個通路能正常送單時，有些規則看起來理所當然；等到另一個通路的 SKU 無法對應 ERP，才看見「商品可以被系統收到」和「商品可以被工廠辨識」之間還缺了一段轉換。這些實際出現的差異，逐漸幫助我們確認哪些資訊需要固定成接單時的必要條件，哪些仍然可以留在不同通路自己的格式裡。

有些差異留在入口，有些差異會影響合作規則

隨著整合案例增加，我們也開始能區分不同類型的差異。欄位名稱、檔案格式或外部 SKU 的表示方式，可以盡量在入口或 Mapping 層處理，避免它們直接影響後面的核心流程。另一類差異則和合作條件本身有關，例如不同數量級距的價格、包裝方式、交付條件，這些內容會直接影響實際履約，系統仍然需要有地方保留。

這個區分對按需製造很重要，因為前端的變化本來就會很多。設計內容可以頻繁更換，不同通路有自己的商品管理方式，訂單來源也不會完全一致。如果每一個外部差異最後都轉成工廠內部的新流程，少量多樣帶來的彈性很容易被行政與系統維護成本抵消。平台需要吸收一部分格式差異，同時留下真正會影響製造與交付的合作條件，後面的流程才有機會保持穩定。

這也讓標準化開始有比較具體的範圍。我們當時沒有要求所有合作夥伴使用完全相同的系統，也沒有要求所有人一定透過 API。比較實際的方向，是讓 API、Web App 與檔案上傳都可以成為入口，再逐步確認哪些資訊是後面的製造流程一定需要的。只要這些必要資訊能夠被可靠取得與轉換，前端就可以保留一定程度的差異。

降低合作門檻，也要一起看 Integration Cost

從商業發展的角度，新的通路愈容易加入，對這個模式愈有幫助。如果合作夥伴已經有自己的系統，就直接串接；如果沒有工程資源，就提供檔案上傳或 Web App，盡量減少合作前必須完成的 IT 改造。這些設計可以降低合作夥伴的 Adoption Cost，但每多支援一種格式或特殊流程，平台端也會增加轉換、測試與維護工作。

工程師在這些討論裡持續把這一部分拉回來。當一個特殊需求只影響單一合作夥伴時，如果直接修改核心流程，未來其他功能調整也會一起受到牽連；如果能留在 Mapping、設定或外部轉換層，影響範圍就比較容易控制。這些技術上的考量，最後也和商業上的擴張成本連在一起，因為每增加一個通路需要多少開發與維護工作，會直接影響按需製造模式能不能持續增加合作對象。

新商業模式剛開始時，我們很難先拿出一套完整標準要求市場配合，因為很多規則本身也還在驗證。當時的做法比較接近先讓真實合作發生，再從一次次整合裡辨識哪些內容開始重複出現。重複出現，而且對後面的製造流程有共同意義的部分，逐漸收斂成平台規則；只有特定合作夥伴才存在的差異，則盡量留在外圍處理。

第二個使用情境開始檢驗第一個設計

只有第一個通路時，它的資料格式很容易被當成平台應有的格式，它的作業方式也很容易直接進入系統流程。另一個電商通路出現之後，原本看不出來的一些假設才開始變得明顯。商品資料無法穩定對應 ERP，讓我們先停下自動建單；不同公司的開發能力不一樣，也讓 API 不能成為唯一入口。這些差異提供了新的條件，讓平台原本的設計可以再被檢查一次。

走到這裡，我們比較確定了一個方向：平台可以保留不同接單方式，但進入後續製造流程之前，需要逐漸確認一組必要資訊；合作夥伴自己的格式可以透過轉換處理，會影響實際履約的差異則需要被明確保留下來。這樣的取捨沒有消除客製化，但讓我們開始知道客製化適合留在哪一層，以及哪些內容值得逐漸形成平台標準。

當這個方向確定後，下一個問題會再往訂單裡面走。即使系統已經能辨識外部商品並轉成製造項目，商品規格、價格、包裝與圖檔之間仍然有一些資訊每次下單都會改，有些則應該沿用合作雙方原本的約定。接下來需要釐清的，就是哪些資訊要跟著每一筆訂單進來，哪些條件應該在合作開始前先被固定下來。

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