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

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

前一篇談到，我們最後沒有在這個階段一起建立完整的圖面管理系統。製作檔仍然放在 NAS，工程也繼續沿用原本的工作方式。當時很容易把這件事情理解成專案範圍的取捨，但實際往現場再看一步，還有一個更直接的限制：真正需要改變工作方式的人是工程，而當時的工程團隊並沒有太多餘裕可以承接一套全新的流程。

逐字稿裡其實已經看得到，工程除了 POD 訂單，也同時處理大量其他代工類型的訂單，NAS 一直是他們下載與編輯圖單的主要工作區。當時討論 Web App 時，也沒有假設它可以直接全面取代 ERP，而是認為它比較適合先服務特定角色，再根據不同人實際需要的資訊分別調整。

再加上當時正值旺季，工程本身也缺人，工作壓力已經很高。這個角色對流程變動的接受度原本就比較低，即使主管知道圖面管理長期需要改善，也很難在這個時間點直接要求團隊全面換掉原本的操作方式。

第一線「不想改」，背後通常有很具體的工作成本

如果只看系統設計，圖面管理其實很合理。檔案應該有版本、狀態與關聯，哪一份是正式版、誰修改過、什麼時間可以進入生產，都應該有比較明確的紀錄。

但把這些設計放回工程的日常工作後，代表的其實是一連串新的操作。

原本他們可能進 NAS 找到訂單資料夾，處理完圖檔之後再放回原本的位置。如果導入完整圖面管理，就可能需要登入新的系統、找到訂單、上傳或提交檔案、確認版本，再更新目前的處理狀態。每一個步驟單獨看都不複雜，但對一個已經缺人、又正在處理旺季訂單的團隊來說，就是新的工作量。

更麻煩的是，接單自動化帶來的效益和流程改動的成本不一定落在同一群人身上。業務與接單端可以少掉 Email 整理、人工建單與 ERP 重複輸入，工程則可能先增加新的版本與狀態管理工作。從公司的角度來看整體流程變好了，第一線使用者看到的卻可能是自己又多了一套需要操作的東西。

主管認同方向，也不代表當下適合強推

在組織架構上，主管當然可以要求部門改流程。但實際導入時，主管也要承擔流程切換期間的風險。

如果新的操作方式需要學習，短期產能可能下降；如果大家還沒有熟悉系統，旺季訂單又持續進來，最後最常出現的情況就是現場一邊用新流程，一邊又回頭用原本的 NAS、Excel 或其他方式把工作完成。系統看起來上線了，實際作業卻多出兩套並行流程。

所以當時真正需要衡量的是這個團隊有沒有能力在這個時間點承接變動。主管是否支持是一個條件，人力、工作量與第一線的接受程度則是另外幾個同樣重要的條件。

先讓系統適應現場，而不是要求現場一次適應完整系統

當時逐字稿裡已經出現一些降低改動幅度的做法。Web App 先服務特定 team，不要求一次涵蓋所有角色；NAS 仍然保留作為工程主要工作區；檔案流程甚至討論過由系統預先建立資料夾，再透過 NAS 的 Symbolic Link 維持原本按照訂單編號找檔案的習慣。

這些做法背後的方向很接近：能夠先不要求使用者改變的地方，就先不要一次改掉。接單、訂單驗證與 ERP 整合可以先往前推，因為這些地方已經有相對明確的價值與規則；工程既有的 NAS 工作方式則先保留。系統先在背後多做一些事情，讓使用者需要面對的變化盡量少一點。

這種逐步導入的方式對這個案子比較適合，因為每一次只增加有限的變動，使用者比較容易知道新的流程到底影響自己什麼，也比較容易在真的使用之後回饋問題。

測試階段，有些工作我甚至會先自己補起來

逐步導入做到更細的時候，我不一定會要求工程師先把整條流程全部自動化完成。如果某個步驟還沒有被系統處理，但人工完成的成本還可以接受，我有時候會先自己把這段工作補起來。可能是人工整理一份資料、幫忙確認某個欄位、處理還沒有自動化的轉換，或暫時用既有工具把兩個步驟接起來。

因為很多需求在會議裡看起來合理，真正操作之後才會知道使用者到底會在哪裡卡住。有些原本認為很重要的欄位，他可能根本不會看；有些原本預期只是例外的情況，實際上每天都會遇到；也可能在操作之後才發現，前面設計的流程順序和現場習慣完全不同。

如果這些事情還沒有釐清，就直接把完整邏輯交給工程師實作，後面調整的不只是一個按鈕，還可能牽涉資料結構、Validation、權限、例外處理與測試。所以在比較早期的階段，我會容許流程裡暫時存在一些人工工作，先確認使用者能不能順利把事情做完。

人工補位之後，再決定哪些事情值得交給工程師

這種人工方式不適合長期維持。真正有價值的地方，是它可以讓規則先被實際使用過。

如果同一件人工工作開始反覆出現，而且每次處理方式都差不多，就代表這個規則逐漸穩定；如果使用者連續使用幾次之後，操作方式也沒有再發生大的調整，這時再把需求整理給工程師，開發出來的功能通常會比較接近真正需要的樣子。

所以 PM 和工程師之間也會形成一個來回。

PM 先把流程帶到可以實際測試的程度，中間一些缺口可以暫時人工處理；使用者開始操作後，再確認哪些規則真的成立、哪些地方還需要改；等流程比較穩定，再讓工程師把高頻、重複、規則清楚的部分做進系統。

這和一開始就把所有功能列完再一次開發相比，工程師不用太早替還在變動的流程建立完整架構，使用者也不用一次面對大量新的操作。

第一階段的目標可以只是讓使用者順利完成工作

早期更重要的是，使用者能不能在新的流程裡順利完成工作。如果中間還有一兩個步驟需要由我協助，但使用者本身不需要理解那些尚未成熟的系統細節，這個 Pilot 仍然可以繼續往下驗證。所以在驗證時，不用把「全部自動化」當成唯一的完成條件。等流程真的跑過幾次之後，再觀察哪些人工補位一直重複出現。

如果只是偶爾遇到一次的特殊情況，可能暫時保留人工就可以；如果每天都要處理，而且規則已經很明確，就開始有足夠理由投入工程資源把它自動化。這樣每一階段增加的自動化，都來自已經發生過的工作，而不是先假設未來所有流程應該長什麼樣子。

最後沒有要求工程一次換掉整套工作方式

回到工程與圖面管理，我們知道 NAS 的版本管理不完整，也知道長期來看完整的圖面管理會比較容易追蹤，但當時工程正處在人力不足與旺季壓力下。要求他們同時更換圖面管理方式，會讓這個新接單系統帶來的改動超出團隊當下能承受的範圍。

所以接單、合作條件與 ERP 整合繼續往前，工程原本的 NAS 流程先保留；能在系統背後自動處理的部分逐步增加，還沒有成熟的地方則允許先用人工補上。等到使用者真的跑過流程、規則也比較穩定，再決定哪些功能值得交給工程師完成。

在這個案例裡，逐步導入帶來的好處除了降低第一線一次需要承擔的改變，也讓需求可以在真實操作中繼續被驗證。系統每往前多走一步，都建立在上一個階段已經實際跑過的流程上，而不需要先要求整個組織一次接受完整的新做法。

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