製造業生產管理系統到底在管理什麼?
重點結論
製造業生產管理系統管理的是生產需求如何被執行,以及執行過程留下哪些物料、進度與成本紀錄。系統是否有價值,取決於這些資料能否互相追溯,而不是畫面或報表的數量。
銷售訂單記錄客戶要什麼,生產作業則要回答材料如何準備、哪些工序必須完成,以及什麼時候能交付。接單生產可能由客戶訂單啟動;備貨生產則可能由預測或庫存補充需求啟動。因此,不應預設所有工廠都採「一張訂單對一張工單」,而要確認拆單、併單或共用批次時,來源需求仍能被追蹤。
以一筆需要加工、表面處理與組裝的生產需求為例,生管先確認產品結構與物料,再安排內製及委外工序;倉庫記錄領退料,現場回報完成量,最後辦理檢驗與入庫。這是流程示意,實際站別會因工廠而異,但每個交接點都應說清楚:誰更新資料、更新什麼,以及下一個部門依哪一筆紀錄作業。
規劃時,可以先讓各部門共同確認一張工單能回答的問題,而不是直接從看板版型開始。
| 管理面向 | 應能回答的問題 |
|---|---|
| 生產需求 | 為哪筆訂單、預測或補庫需求生產?需要多少、何時完成? |
| 產品與物料 | 使用哪一版 BOM?應領、已領、退回與耗用數量如何記錄? |
| 製程與進度 | 現在在哪個工作站或協力廠?哪些工序已完成? |
| 在製與品質 | 待加工、待驗、不良與重工數量各是多少? |
| 完工與成本 | 哪些數量已入庫?材料、工時、加工費如何對應生產紀錄? |
什麼情況代表 Excel、進銷存或既有 ERP 開始不夠用?
重點結論
當跨部門需要共同判斷交期、物料或進度,卻必須反覆詢問、重抄或核對不同版本時,就值得評估流程與系統改善。問題也可能出在使用方式或資料責任,不能直接歸因於軟體不足。
若產品與製程穩定、協作人員少,且資料更新責任清楚,Excel 搭配既有系統仍可能足夠。相反地,即使已購買 ERP,只要現場不回報、主檔無人維護,或委外紀錄沒有回到工單,管理者仍無法取得可靠的答案。選型前應先分辨「系統沒有功能」與「功能存在,但流程沒有落實」。
這類選型問題也出現在使用者討論中。一則海外小批量製造業的求助文,描述現場先用紙本記錄,再輸入 Excel,並詢問可取代現況的 MES/ERP 方案;這可作為真實問題訊號,但不是台灣市場普查,也不是任何產品的成效證明。
企業可以用以下清單整理最近反覆發生的狀況,並為每一項留下實例。
- 交期必須逐站詢問,系統狀態無法反映最新作業。
- 領料、退料與現場實際耗用量對不起來。
- 插單或設變後,部分人員仍依舊版工單作業。
- 委外半成品只能查到「已送出」,無法確認未回貨與異常。
- 相同資料在生管、倉庫與會計之間重複輸入。
- 生產異常已發生,但成本或進度報表直到很久以後才反映。
盤點後,先挑一個對交期或重工影響最大的環節改善。若透過統一品號、確認權責與調整既有功能就能解決,便不必立即增加系統;若問題跨越多個工具且需要持續同步,再評估整合或補建模組。
BOM、製令與工單要如何連動,才不會各有一套版本?
重點結論
BOM 管理要同時處理產品結構、適用版本與生產引用關係。評估系統時,應確認每一筆生產紀錄能否還原當時採用的版本與變更,而不只是顯示最新用料表。
BOM(Bill of Materials,物料清單)用來描述產品所需的組件與數量。實際規劃還要搭配製程途程、工作站及作業條件;只知道要用哪些料,並不足以決定在哪裡加工、如何報工或何時完工。
「製令」與「工單」在不同企業及軟體中的用法可能相同,也可能分成不同層級。本文以製令代表生產指令、工單代表現場執行紀錄的概念分工,並不要求系統一定建立兩種單據。導入時應先對照現有用語,確認哪份紀錄負責需求、派發、耗用與完工,避免為了名稱增加重複作業。
多版本 BOM 本身不代表需要客製。Microsoft Dynamics 365 的官方文件已說明 BOM 版本、核准及有效條件等能力,顯示這些需求可存在於現成產品中;企業仍需驗證所評估的版本與設定是否支援自己的變更方式。
實際展示時,建議請廠商走一個完整設變情境:產品已開工後更換材料,新單採新版本,舊單是否繼續使用原版本?若允許改料,誰核准、已領材料如何處理、變更紀錄如何回查?能回答這些問題,才足以判斷系統是否支援企業的 BOM 管理,而不是只看功能名稱。
委外加工與在製品要怎麼管理,才能知道貨在哪裡?
重點結論
委外加工管理應把外發、分批回貨、檢驗、異常與加工費連回原生產紀錄。只記一個「已送外包」狀態,無法充分支援交期、在製品與費用核對。
以半成品送往協力廠做表面處理為例,企業需要區分已發出、外廠尚未交回、已收回待驗、合格可用及退回重工等狀態。這些數量不宜混在同一欄,也不能把「貨已回廠」直接視為「可以投入下一站」。以下是假設的驗證情境,不是真實企業案例:外發 100 件、先回 60 件,其中 5 件待處理,系統應能說明剩餘 40 件的交期,以及已回貨數量的檢驗去向。
| 委外環節 | 選型時要驗證的紀錄 |
|---|---|
| 外發 | 原工單、工序、品號、批次或識別資訊、數量與加工廠 |
| 交期追蹤 | 承諾交期、分批回貨安排、延誤原因與負責窗口 |
| 收貨與檢驗 | 本次實收、合格、待驗、不良及未回貨數量 |
| 異常處理 | 短少、報廢、退回重工、補料及責任歸屬 |
| 加工費核對 | 計價單位、核准單價、驗收數量與對應工單 |
現成軟體也可能支援這些流程。Microsoft Business Central 搭配 Subcontracting app 的官方範例包含分批收貨情境,因此「有分批回貨」不應直接被當成客製理由;真正要比較的是企業的驗收、轉廠與計價規則,能否在所選方案中完整執行。
若加工費依重量、件數或不同工序計算,建議把一張實際請款單與外發、回貨紀錄一起帶進展示。確認核對方式後,再決定需要調整設定、增加欄位,或開發特殊流程,避免以「有委外模組」代替實際驗證。
現場報工如何連到生產進度與製造成本?
重點結論
現場報工應讓完成量、工序、工時與異常回到對應工單,並與領退料紀錄共同支援成本分析。資料更新及時,不代表費用已全部入帳;作業進度、成本估算與最終結算需要分開呈現。
規劃報工時,先確認管理者真的需要哪個粒度的資訊。若目標是知道工單是否完成某道工序,可以先記錄工單、工序、完成量與時間;若要分析人工作業成本,還需要定義工時如何記錄,尤其一人同時照顧多台設備時,不能把機台經過時間直接當成人工投入時間。
操作方式也要符合現場。平板、共用終端、條碼或 QR Code 都可以列入評估,重點是現場人員能否在正常工作節奏中完成回報。示範時應讓真正操作的人試一次,確認找工單、改數量、回報不良與更正錯誤是否順手,再決定是否需要進一步串接機台。
成本分析則需要另一層設定。Microsoft 的生產工單成本文件區分材料、作業與間接成本,也說明實際成本會使用已回報的耗用資料;這支持「報工與耗料是成本分析的基礎」,不代表只填完成數量就能算出完整成本。
假設同一產出範圍原計畫用料 100 公斤、實際淨領用 112 公斤,系統可以提示差異,但仍應確認是否有尚未退料、在製餘料、替代料或報廢。委外帳單未到、費率尚未更新,或製造費用尚未完成分攤時,畫面宜標示估算或待結算狀態。這樣的設計能讓主管提早追查異常,也避免把尚未完整的資料當成最終結論。
ERP、生產管理系統與 MES 到底怎麼選?
重點結論
先依需要解決的問題分配系統責任,再比較產品名稱。ERP、MES 與生產管理模組的功能可能重疊,企業不一定需要三套系統,也不必因為其中一段不足就全部汰換。
ERP 通常著重企業資源與營運資料,MES 則更靠近現場生產執行。SAP 對 MES 的說明包含製造過程監控、追蹤與紀錄,也指出它與 ERP 的分工;但不能因此認定所有 ERP 都缺乏報工功能,或所有 MES 都具備相同深度的設備與品質功能。
「生產管理系統」也不是固定、互斥的產品類別。有些廠商用它稱呼 ERP 製造模組,有些用來指工單與報工平台。因此,評估時應把自己的問題帶進操作展示,確認功能在哪裡執行、結果存在哪裡,以及例外時誰負責處理。
| 現在最需要解決的問題 | 優先評估方向 | 展示時不能略過的問題 |
|---|---|---|
| 訂單、採購、庫存與財務資料分散 | ERP 或既有 ERP 的流程整理 | 生產資料如何連到物料與帳務? |
| 已有進銷存,缺少 BOM、工單與領退料管理 | 製造模組或生產管理方案 | 能否帶入真實產品結構與工單? |
| 已有 ERP,現場進度與品質紀錄仍不完整 | MES 或報工、品質等適用模組 | 回報粒度與現場操作是否合適? |
| ERP、MES、WMS 各自可用,但重複輸入 | 系統整合、連接器或資料交換 | 主檔、庫存、工單與狀態由誰主責? |
| 僅特定流程經驗證後仍無法支援 | 產品擴充或特定模組客製 | 缺口範圍、驗收與維護責任是否清楚? |
不是所有企業都需要客製化。若現成產品或 SaaS 經設定即可支援主要流程,應把它列為優先方案;評估時一併計入授權、導入、資料整理、設備、串接與後續維護,而非只比較初期報價。若採客製方案,也必須確認誰維護、需求變更如何處理,以及未來如何匯出資料。
已有 ERP 與 MES 時,可以評估保留兩者並交換必要資料。可行性仍須逐一確認廠牌、版本、介面、授權及可讀寫範圍,不能只憑「支援串接」四個字決定。
對企業而言,比「能不能串」更實際的問題是:工單改版後何時同步?重送是否造成重複報工?失敗由誰處理?這些驗收情境應在選型時提出,才能知道整合後是否真的減少人工工作。
什麼情況適合客製化,JoinX 哲煜科技可以從哪一段介入?
重點結論
當關鍵流程已確認無法透過現成產品的合理設定、模組或擴充滿足,且缺口影響交付、資料一致性或現場操作時,才值得評估客製化。JoinX 哲煜科技可以從特定流程、操作介面與跨系統整合切入,不必一開始就重做整套 ERP。
少量多樣、多階 BOM、設變或委外加工,都只是需要驗證的需求特徵,並不是客製化的充分理由。企業應要求候選廠商用真實資料演示,將「原生支援」「設定後可支援」「需要擴充」與「無法支援」分開記錄。只有知道缺口究竟在哪裡,才能比較改流程、換產品或開發功能的代價。
以下情況較適合帶著資料,和 JoinX 哲煜科技討論可行的介入範圍。
| 已確認的缺口 | JoinX 哲煜科技可評估的工作 | 開始前需釐清 |
|---|---|---|
| ERP 的訂單與財務可用,特殊委外流程仍在 Excel | 補建委外追蹤或例外處理模組,連回原工單 | 哪些紀錄保留在 ERP,哪些由新模組負責? |
| MES 已回報,ERP 狀態仍要人工更新 | API、資料交換、錯誤通知與對帳流程 | 原廠介面是否可用,失敗與重送如何處理? |
| 標準畫面不符合現場操作方式 | Web、APP、平板或共用終端介面 | 裝置、網路、權限與操作步驟有哪些限制? |
| Excel、紙本分散,尚無一致的工單與主檔 | 流程盤點、資料結構與分階段系統規劃 | 先解決哪個問題,哪些資料由誰維護? |
客製化評估也應包含「這個流程是否值得保留」。若特殊做法只是歷史習慣,調整流程可能比寫程式更合適;若它涉及既有客戶交付條件、現場限制或無法合理替換的作業方式,才需要進一步設計。
明確的需求可以是:「ERP 不換,先讓委外未回貨與工單進度對得起來。」它比「我要一套自己的 ERP」更容易界定範圍、安排試行與確認成果。JoinX 哲煜科技的角色,是協助企業把這個缺口釐清,再評估適合的開發與整合方式。
找開發公司前,需要先準備什麼?
重點結論
第一次討論不需要完整 PRD、需求規格書,也不需要先決定 ERP 或 MES。帶著正在使用的工單、BOM、Excel 與既有系統資訊,就能開始釐清問題。
建議挑一筆正常完成的生產紀錄,再挑一筆曾經設變、缺料、委外延誤或重工的紀錄。正常流程能說明日常作業,例外紀錄則能顯示哪些地方需要人工補救;兩者一起討論,比只列功能名稱更容易確認系統範圍。
| 可以帶來的資料 | 用來釐清什麼 |
|---|---|
| 現行 BOM、工單與流程圖 | 生產依據、站別與交接方式;沒有流程圖也可口頭說明 |
| Excel、紙本與報表 | 哪些資料被重抄、哪些欄位實際沒人使用 |
| 委外單、回貨與請款紀錄 | 數量、狀態、加工費如何核對 |
| 既有 ERP、MES、WMS 名稱與版本 | 哪些系統需要保留、介面資訊由誰提供 |
| 最常發生的困擾 | 先處理交期、料帳、追溯或成本中的哪個問題 |
| 期待看到的結果 | 如何判斷改善有用,例如可直接查到工單未回貨數量 |
若資料涉及客戶價格或其他不宜外傳的內容,可以先遮蔽,保留欄位結構與代表情境。首次討論的目的,是確認問題、限制與下一步要驗證的事情;企業不必先替開發團隊決定技術方案。
常見問題
可以列為評估方向,但必須先確認交換哪些資料、使用什麼介面,以及誰負責對帳。海外 ERP 求推薦討論中,就有製造業發文者明確希望保留 QuickBooks、補足生產管理;這反映的是使用者需求,不代表任意兩套軟體都能直接連接。評估時應讓既有系統廠商與新方案團隊共同確認資料邊界。
先找出最影響交付的那一段,再決定系統怎麼補
如果目前已有 ERP、MES、進銷存或大量 Excel,可以先確認哪些功能仍適用,再找出影響交期、料帳或成本判斷的缺口。你不需要先決定要重新開發一套系統,才能開始討論。