生管為什麼一直問工單？訂單 vs 工單差在哪？（皮克敏絨毛娃娃訂單案例）
週一早上，業務 Peter 在 Line 群組丟了一則訊息：「客戶訂單 PO-PKM-8842，皮克敏絨毛娃娃混單 1,000 隻，4 週內要交貨。」
半小時後，生管回覆：「工單號給我。 紅葉款走哪條產線？岩石款能跟黃葉款同一張工單嗎？週一要先出的那 400 隻，是 WO-01 還是 WO-03？」
對於剛接觸生產製造，或正在導入 MES / ERP 系統的朋友，這種狀況應該不陌生：「業務明明說訂單 1,000 隻皮克敏，現場為什麼一直問工單號？」
這不是領班或廠長在刁難，而是兩套語言本來就不該混用。在生產製造裡，訂單（Sales Order） 屬於業務語言；但真正讓生產線動起來的是工單（Work Order / 生產工單）。
目錄
- 訂單與工單：兩套語言，兩種角色
- 訂單 1,000 隻，現場為什麼不是一張工單
- ERP 怎麼翻譯：還要做多少、何時動？
- 什麼時候要拆工單？三種常見的現場實務案例
- 緊急插單：為什麼改工單比改訂單務實
- 三個常見的誤解（製造現場真的會踩這些坑）
- 一句話總結
訂單與工單：兩套語言，兩種角色
| 訂單（Sales Order） | 工單（Work Order / 生產工單） | |
|---|---|---|
| 誰的語言 | 客戶、業務、ERP 系統 | 工廠、生管、MES 系統 |
| 代表含義 | 需求起點、交期與數量的承諾 | 產線的生產通行證 |
| 詳細內容 | 品項、總量、希望交期（範例：皮克敏 1,000 隻） | 品號、品種、款式、做多少、用哪條產線、給哪個客戶、哪個批次 |
以下再詳細解釋一下訂單和工單的差異：
- 訂單從客戶端發起，是生產製造流程的「來源」，但內容是宏觀的：要多少、大概什麼時候要。它無法直接告訴吊飾產線的師傅「現在開始縫這批紅葉款」。
- 工單則是訂單進入工廠後的執行單元。沒有工單，產線不知道具體要做什麼、做多少、做給誰、走哪條產線；MES 系統的追溯也是掛在工單與批號上，而不是掛在「皮克敏 1,000 隻」訂單號上。
訂單很少能與現場一對一對接。實務上會經過 ERP 做翻譯與拆解：結合庫存、交期、產能與物料現況，把業務需求轉成工廠看得懂的工單，再交給排程與 MES 系統。
訂單 1,000 隻，現場為什麼不是一張工單
延續上述案例：PO-PKM-8842｜皮克敏絨毛娃娃混單 1,000 隻｜4 週內交貨（客戶後續確認：週一先出紅葉 + 黃葉 400 隻、週四再出含岩石款在內 600 隻，生管在 ERP 才會看到分批與品號資訊）。
－業務在 CRM / 銷售訂單看到的資訊
- 客戶訂單 PO-PKM-8842
- 品項：皮克敏絨毛娃娃（混單）
- 1,000 隻
- 4 週內交貨
上述這些資訊對業務來說，任務是「跟客戶確認交期、等工廠交貨」。至於紅葉、黃葉、岩石是不是同一條產線、是不是同一種包裝——通常不在訂單這一層展開。
－生管打開 ERP 看到的
這張訂單不能直接投入產線。要先計算：
- 成品倉已有 150 隻 尾單現貨 > 不必全做
- 實際還得生產 850 隻（1,000 − 150）
- 客戶檔期：週一先交 400（紅葉 + 黃葉）、週四再交 600（含岩石皮克敏等）> 交期要切兩段
- 吊飾產線每批最多 200 隻 > 還得再切批次
- 岩石款（PK04） 填充材、標籤、途程與紅 / 黃葉不同 > 不宜與一般款混同一張工單 同一張訂單，兩個畫面。業務談的是承諾；生管算的是怎麼做得到。
也就是說，最後下達現場的，很可能是 多張工單——不同品號、不同產線、不同開工日——而不是「皮克敏絨毛娃娃 1,000 隻」這一行字。
下面分兩段說明：ERP 怎麼算出這些數字，以及為什麼要拆成多張工單。
ERP 怎麼翻譯：還要做多少、何時動？
ERP 在生產製造裡扮演著翻譯官：把業務導向的訂單，「轉成工廠可執行的工單」。依庫存、交期、產能與生產邏輯做核算與拆解。
「轉成工廠可執行的工單」，這個怎麼轉？礙於篇幅太長，詳細轉換流程我會再另外撰寫另一篇文章跟大家分享 （絕對不是地球自轉、頭轉啦）
－第一步：翻譯與核算——還要做多少？
ERP 接收客戶需求（品項、數量、交期），並結合工廠即時資訊運算：
- 庫存與交期：現有庫存能否先滿足一部分？剩餘多少、何時必須開工才來得及？
- 物料需求：聚酯纖維、填充棉、吊牌、珠鍊、彩盒是否齊套？若包材分批到貨，可能先建議開 200 隻 的工單，其餘待料到齊後再開。
以本案為例：
- 訂單 1,000 − 庫存 150 = 淨生產 850 隻
- 若岩石款專用灰布目前只夠 200 隻，可能建議：先開 WO-A（200，黃葉 + 紅葉），待到貨後再開 WO-B（650 或再依品號切批）
這一步回答的是：在承諾交期下，工廠實際要生產多少、大概何時動。
－第二步：拆解——訂單一張為什麼常變成多張工單
即使淨需求量已算出，仍常拆成多張工單。以 PO-PKM-8842 為例，ERP 可能長這樣：
| 拆解原因 | 本案例可能長這樣 |
|---|---|
| 分批交貨 | WO-01（週一 400：紅葉 + 黃葉）、WO-02（週四 600：含岩石）> 對應不同開工與完工。 |
| 單批上限 200 | 淨生產 850 隻、吊飾產線每批最多 200 > 至少 5 張工單；若 WO-01 負責週一批 400，還會再拆成 2 張各 200。 |
| 品號 / 途程不同 | 紅葉、黃葉、岩石填充工序不同 > 分開工單，避免混線掛錯吊牌。 |
| 多線平行 | 紅葉 A 線 340、黃葉 B 線 340、岩石 C 線 170 同時開工，縮短工期。 |
工單核准後，才進入 MES 下達、派工。也就是說，ERP 負責在計畫層把「需求語言」變成「可開工的工單集合」；MES 負責工單到了現場之後的執行與履歷。
什麼時候要拆工單？三種常見的現場實務案例
許多人理解「一張訂單變多張工單」時，只想到分批交貨。實務上還有下面這 3 大面向。拆單的目的很單純：把業務端的需求，變成工廠端可執行、可管理、可追溯的具體行動——每一張工單都是 MES 系統能執行的最小單元。
1. 交付需求與規格差異
分批交貨（最常見）：週一先出紅葉 + 黃葉、週四再出岩石款 > 對應不同開工日與完工日的工單。生管排程看的是「哪張工單何時必須完工」，不是「訂單總量何時交完」。 即便交期同一天，仍可能因規格拆單：
- 分倉 / 目的地：訂單 500 隻，300 隻供台灣電商倉（紅葉線 A）、200 隻供日本代購倉（黃葉線 B）> 兩張工單，物流、標籤與報關規則不同。
- 包裝：同一批皮克敏，一半吊飾背卡 + 珠鍊、一半17 公分大娃娃彩盒 > 兩張工單，後段包裝站與標籤模板不同，避免紅葉款吊飾被裝進岩石大娃娃外箱。
2. 產能與效率
- 單批最大生產限制：吊飾產線每批上限 200 隻，淨生產 850 隻 > 系統拆成多張工單，換產線與填充的節奏才符合設備限制。硬塞成一張工單，雖然排程表很好看、業務看得很爽，但現場卻無法執行。
- 多產線平行：為縮短工期，紅葉 A 線、黃葉 B 線與岩石款 C 線同時開工 > 多張工單，MES 系統追各自產線的產出。
3. 現場管理與品質追溯
- 班別拆分：客戶或廠內品保要求日班、夜班分單 > 品質異常時可以核對到班別，而不是只能說「那天做的」、「禮拜一做的」。
- 模具壽命：岩石款眼片、鼻子共用模具達到某一個模次數後需換模 > 工單範圍切在「同一套模具週期」內，履歷與模具管理、保養計畫一致。
這些規則常寫進 ERP 轉工單邏輯，並在 MES 做防呆——例如跑錯製程站、模具不符、料況不對，系統直接擋下，而不是等到出貨才發現吊牌寫成「紅色皮克敏」卻裝了「黃葉款」。
緊急插單：為什麼改工單比改訂單務實
週三下午，業務 Peter 又丟出一則訊息：「客戶要插單，發光皮克敏吊飾急要 100 隻，本週五前要。」若每次都去改原始訂單，容易牽動業務、財務與已開立的整批生產計畫。
製造現場常見的兩種應對方式：
- 做法 A：回去改原始訂單 PO-PKM-8842 的數量與交期 > 可能牽動業務承諾、財務確認、已開立的整批計畫，連鎖反應大。
- 做法 B：新增或調整特定工單（例如 WO-URGENT-01：發光皮克敏吊飾 100 隻、提高優先序、指定 B 吊飾產線）> MES 與排程立刻反映，訂單主檔仍保留對客戶的總承諾。
實務上較穩的是做法 B。這也是為什麼生管常說「哪張工單先跑」，而不是「哪張訂單先跑」——排程動的是執行層的工單，不是對外的訂單承諾。
三個常見的誤解（製造現場真的會踩這些坑）
- 「訂單上寫皮克敏絨毛娃娃 1,000 隻，現場照做就好」：訂單沒告訴你：紅葉還是黃葉、吊飾還是大娃娃、岩石款走哪條線、用哪套標籤、料夠不夠。這些都在工單與 ERP 的轉換裡才會被算出來。
- 「工單拆太多，是 ERP 設定太複雜」：多數拆單對應真實限制：檔期節奏、品號差異、設備批次、多線平行、物料及包材齊套。問題通常不是「為什麼要拆」，而是有沒有把拆單原因講清楚，讓業務與現場對同一張訂單有相同預期。
- 「有 MES 就不用管工單，掃碼就會自己跑」：MES 以工單與批號為執行依據。若是工單錯、批號錯、途程錯，好的 MES 會防呆卡控；若沒阻擋，系統只會讓混亂的現場更加混亂——出貨了才發現客戶要紅葉吊飾，箱內卻是黃葉款。
一句話總結
訂單是需求起點；工單是執行細節與生產管理。 ERP 把訂單轉換、翻譯成工單，「皮克敏絨毛娃娃 1,000 隻」，到了工廠會變成「紅葉吊飾 WO-xx、岩石 WO-yy」。拆單則把一個業務訂單拆成多個可排程、可進出站、可追溯的執行單元。生管一直問工單號，是在確認現場這一刻縫的是哪個品號——先對齊這層語言，再談系統優化升級，才不會從第一天就對錯資訊。