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

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

前幾篇一路談到，外部通路的訂單進來之後，系統需要先確認合作條件、驗證商品與訂單內容，再把成立的交易送進製造商既有 ERP。遇到資料錯誤、ERP 異常或其他例外時，也開始需要區分 Reject、Retry 與人工介入。

做到這裡，一張訂單從外部通路進到製造商內部的路徑已經逐漸清楚。但如果把視角再往工廠裡面移一步，就會遇到另一套這個接單系統還沒有真正管理的資料：實際拿去生產的製作檔案。

這個案子的製作檔長期放在 NAS 裡，工程與相關人員也已經習慣直接在既有資料夾裡處理檔案。ERP 可以讓工廠知道有哪些訂單，NAS 裡則放著真正要拿去製作的檔案。兩邊在實際工作上有很強的關聯，但中間並沒有一套完整的圖面管理機制負責版本、狀態與關聯。所以即使一張訂單已經進 ERP，也不代表工廠在那個時間點就一定可以開始生產。

訂單成立時，最終製作檔本來就可能還不存在

前面曾經提過，我們一開始也討論過訂單與製作檔應該用什麼順序產生。從系統資料完整性的角度，很容易希望訂單進來時，相關檔案就已經準備好，這樣系統可以一次把訂單與檔案收齊，再交給後面的流程。

但回到製造商原本的工作方式後，實際順序並不是這樣。通常需要先形成交易、建立 ERP 訂單，後面的工程或製作人員才會根據訂單開始整理真正拿去生產的檔案。因此在訂單成立的那一刻，客戶可能已經提供原始圖片或設計素材，但最後可以直接進入製程的檔案仍然需要經過後續處理。

因此，「訂單資料完整」和「製作檔已經可以生產」是兩個不同時間點。如果為了讓系統資料看起來完整，硬性要求最終製作檔一定要在建單以前出現，反而會改變工廠原本的工作順序。因此當時沒有把製作檔設計成訂單成立的必要條件，訂單可以先往下走，製作檔則沿用後面的既有作業產生。

這個做法先讓接單流程可以成立，但也把原本存在於工廠裡的另一個問題留了下來：當製作檔在訂單之後才產生，系統怎麼知道目前哪一份才是最後真正要拿去生產的版本？

NAS 很適合存檔，但版本仍然大量依賴人的工作習慣

製造商原本把大量圖面放在 NAS，這件事情本身並沒有不合理。製作檔通常不小，工程與現場人員都在既有環境裡工作，共享資料夾也已經成為日常操作的一部分。要求所有人因為新增一套接單系統，就立刻放棄原本的檔案環境，反而會帶來很大的使用成本。

真正需要處理的是 NAS 上面的檔案怎麼被管理。同一個案件在處理過程中可能會修改製作檔，原本的內容經過確認後也可能重新調整。如果檔案主要靠資料夾、檔名與人員習慣來區分，使用者通常知道自己目前在處理哪一份，但系統沒有完整紀錄這些變化，也很難單純從一個檔案路徑判斷哪一份是目前有效版本。

訂單系統可以知道某張單已經成立，也可以知道它成功進入 ERP，但如果要繼續回答「目前製作檔做到哪裡」、「哪一份才是最新版本」、「這份檔案是否已經確認可以生產」，就已經超過一般訂單管理的範圍。

再繼續往下做，需求會逐漸變成一套圖面管理系統

如果要從系統上完整處理這件事情，一開始看起來可能只是把訂單和 NAS 裡的檔案連在一起。但繼續拆下去之後，需要管理的內容其實會愈來愈多。

系統需要知道某一份圖面對應哪一張訂單或哪一個製作品項，也需要知道目前使用哪一版。當檔案重新修改時，舊版本是否要保留、誰進行了修改，以及目前這份圖面是不是已經確認可以進入生產，都會開始變成需要被記錄的狀態。

如果外部通路透過雲端平台提供檔案，而工廠內部仍然使用 NAS，還需要再處理檔案如何進入工廠既有環境，以及兩邊如果同時存在檔案時，現場最後應該以哪一份為準。

做到這個程度，原本的需求就已經很接近一套完整的圖面管理系統。工程師需要處理的也不會只是一個檔案欄位，而是圖面的關聯、版本、狀態，以及後續和工廠實際工作方式之間的銜接。

技術上可以做，但真正大的成本在流程改動

如果建立一套完整的圖面管理機制，現有使用者的工作方式也會跟著改變。

原本工程可能直接進 NAS 找資料、處理檔案，再按照既有方式放回資料夾。正式導入版本與狀態管理之後，就需要重新定義什麼時候建立版本、修改之後怎麼提交、哪一份才算正式版，以及生產端應該從哪裡取得已確認的檔案。原本依賴檔名、資料夾與人員經驗維持的工作，也需要逐漸轉成系統裡明確的操作。

當時真正需要配合這些改動的工程團隊，現場條件也不太適合再增加一套新的操作方式。那段時間美編人力不足，又正好碰到旺季，日常工作本身已經很滿。這個角色原本對流程改動的反應也比較負面，過去習慣的工作方式一旦被改動，很容易增加摩擦。即使主管理解圖面管理的方向，也很難在這個時間點直接要求團隊全面改用新的流程。

因此這裡的 Adoption Cost 並不只是「要學一套新系統」。如果真的要推圖面管理，需要有人重新整理工作規則、陪同工程人員改變操作習慣，還要承擔轉換期間可能降低效率的風險。在人力已經不足、旺季訂單又多的情況下，這些改動很容易直接影響正在進行的生產工作。對工程師而言，這代表產品範圍會明顯擴大；對我這個 PM 角色來說，更重要的是確認這些改動是不是目前就必須一起發生。

這個階段最主要的目標，仍然是讓不同合作通路能用較低的成本把訂單送進製造商，減少 Email、Excel、人工整理與 ERP 重複輸入。圖面管理的問題確實存在，但現有 NAS 與人工流程仍然可以讓工廠完成後續製作，只是版本與狀態的管理還不夠完整。

因此最後的取捨，是先保留既有圖面流程，不在這一階段同時重做工程、NAS 與生產端取檔的工作方式。

最後選擇保留 NAS，也保留了一部分人工判斷

原本的 NAS 繼續使用，工程與工廠人員仍然依照既有方式處理製作檔。新的系統先負責已經比較明確的接單與交易流程，包括合作條件、訂單驗證、ERP 介接，以及需要和檔案建立的基本關聯；圖面從產生、修改到最後確認可生產的完整生命週期，暫時沒有全部搬進新的平台。

這個選擇留下的限制也很清楚。系統暫時無法完整掌握每一份製作檔的版本變化，也不能單靠訂單狀態判斷目前 NAS 裡的檔案是不是已經準備完成。有些確認仍然需要依靠現場人員與原本的操作方式。

但這也讓新的接單模式可以先在不大幅改變製作端工作習慣的情況下開始運作。尤其當時工程團隊已經處在人力不足與旺季壓力下，如果同時要求他們改變檔案管理與版本確認方式，很可能讓新系統本身變成額外負擔，而不是先解決接單流程的問題。

等到合作通路與訂單量增加之後，如果原本依靠人員記得檔案狀態、確認版本與追蹤製作進度的方式開始成為新的瓶頸，再重新評估圖面管理會比較有明確的投入理由。

這次沒有做圖面管理，並不是因為問題不存在，而是當時除了技術範圍之外，還有很明確的人力、旺季與使用者接受度限制。既有流程仍然能支撐生產，因此接單與 ERP 整合先往前推進，圖面管理則留到現場有能力承接改動的時候再處理。

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