MES 已經上線，為什麼管理者還是需要打電話問進度？

假設某工單實際生產狀況：

08:00 開始加工。

10:00 完成 5,000 件。

10:30 轉入下一製程。

12:30 作業員才補登報工資料。

在 10:00 至 12:30 之間，MES 可能仍顯示：

工單尚未完成、產量尚未更新、產品仍停留在原製程。

管理者看到的不是現場即時狀態，而是尚未更新的歷史資料。

這種情況即使系統本身沒有故障，仍然會影響 MES 的管理價值。

Production Reporting Latency 是什麼？

Production Reporting Latency 可定義為：

實際生產事件發生後，到該事件資料成功進入 MES 的時間差。

建議公式：

Reporting Latency = Data Received Time − Actual Event Time

例如：

實際完工時間：10:00

MES 收到報工時間：12:30

則：

Reporting Latency = 150 分鐘

這代表該筆完工資訊延遲了 2.5 小時才進入系統。

需要注意，這是建議的企業內部管理指標，並非所有 MES 都採用相同定義。

為什麼資料回報延遲會影響生產管理？

生產進度失真

工單實際已完成，但 MES 仍顯示生產中。

生管可能因此錯誤判斷設備負荷或工單進度。

WIP 數量不準確

產品已轉入下一站，但系統尚未完成轉站報工。

造成不同製程的在製品數量與現場不一致。

生產排程判斷錯誤

當 APS 或 ERP 使用延遲的 MES 資料重新排程，可能高估尚未完成的工作量。

異常處理不及時

設備已經停機，但作業員沒有即時回報。

管理者可能直到班末才發現異常，錯失及早處理的機會。

MES 應該記錄哪兩種時間？

Actual Event Time

實際生產事件發生時間。

例如：

工單開始、工單完成、設備停機、製程轉站。

Data Received Time

MES 伺服器實際收到該筆資料的時間。

例如：

作業員 10:00 完工，但 12:30 才透過報工系統提交。

建議資料表至少保留：

欄位	說明
WORK_ORDER_ID	工單編號
PROCESS_CODE	製程代碼
MACHINE_ID	設備編號
EVENT_TYPE	報工事件類型
EVENT_TIME	實際事件時間
RECEIVED_AT	伺服器接收時間
REPORTING_DELAY	報工延遲分鐘數
REPORT_SOURCE	人工、設備或系統介接

特別需要避免將 CREATED_AT 直接當成實際生產時間。

否則補登報工時，可能造成生產履歷時間錯誤。

如何分析哪些製程最容易延遲報工？

假設 MES 統計一週資料：

製程	平均報工延遲	30 分鐘內回報率
打頭	12 分鐘	92%
輾牙	38 分鐘	71%
熱處理	85 分鐘	45%
電鍍	25 分鐘	83%
包裝	8 分鐘	96%

可以發現：

熱處理製程的報工即時性明顯較差。

但改善前應先確認：

熱處理是否採批次作業？是否需要等待冷卻？是否由單一人員負責多台設備？現場是否缺乏方便的報工終端？

不同製程的合理回報時間可能不同，不宜直接以同一標準評估所有作業。

如何建立 Reporting Timeliness Rate？

建議新增：

報工準時率（Reporting Timeliness Rate）

計算方式：

準時報工筆數 ÷ 應報工總筆數 × 100%

例如企業規定：

實際事件發生後 15 分鐘內完成報工。

某日應報工 1,000 筆，其中 850 筆符合規定。

則：

Reporting Timeliness Rate = 85%

實際導入時，還應區分正常回報、補登報工及離線資料同步，避免將網路中斷誤判為人員未依規定報工。

為什麼不能只看平均報工延遲？

假設 100 筆報工：

90 筆在 5 分鐘內完成。

另外 10 筆延遲 180 分鐘。

平均值可能無法充分反映這些嚴重延遲的事件。

因此建議同時追蹤：

Average Reporting Latency

平均報工延遲。

P95 Reporting Latency

95% 的報工延遲時間不超過的數值。

Maximum Reporting Latency

最大報工延遲。

Overdue Reporting Count

超過規定時間的報工筆數。

如此才能區分一般延遲與少數嚴重異常。

MES 如何降低現場補登報工？

建立報工提醒

當設備已經開始運轉，但 MES 沒有對應的進站紀錄時，主動提醒現場人員。

簡化報工操作

透過條碼、QR Code、觸控設備或預設工單，降低人工輸入時間。

串聯設備資料

具備通訊能力的設備，可透過 PLC、OPC UA 或 API 蒐集運轉狀態。

但設備運轉不一定等於工單正式開工，因此仍需要正確的工單與設備關聯機制。

建立補登原因紀錄

對於超過規定時間的報工，可要求選擇原因：

設備故障、網路中斷、作業繁忙、忘記報工或其他原因。

讓管理者知道延遲真正發生在哪個環節。

Production Reporting Latency Dashboard 應呈現哪些資訊？

建議包含：

• Average Reporting Latency
• P95 Reporting Latency
• Reporting Timeliness Rate
• Overdue Reporting Count
• Backdated Reporting Count
• Unreported Production Events
• Reporting Delay by Process
• Reporting Delay by Machine
• Reporting Delay by Shift
• Reporting Delay by Operator
• Reporting Delay Trend
• Reporting Delay Reason Pareto

其中最值得建立：

Reporting Latency Heatmap（報工延遲熱力圖）

橫軸顯示班別或時段，縱軸顯示製程或設備，利用顏色呈現平均延遲程度。

管理者可以快速辨識：

哪些設備、哪些時段經常沒有即時報工？

如何避免報工時間被任意修改？

如果允許作業員自行輸入實際作業時間，MES 應保留：

原始提交時間、實際事件時間、修改前後內容、修改人員及修改原因。

並建立合理的時間檢核規則。

例如：

工單完成時間不可早於開始時間。

補登時間超過設定門檻時需要填寫原因。

跨班別修改需依權限核准。

這些措施可以提升生產履歷的可信度，同時避免單純追求報工準時率，反而造成資料失真。

如何建立生產報工即時性改善閉環？

建議流程：

現場生產事件 → MES 接收報工 → 計算 Reporting Latency → 判斷是否超時 → 記錄延遲原因 → 分析製程與班別 → 改善報工流程 → 持續追蹤準時率

改善目標不是要求作業員增加更多紀錄工作，而是：

讓正確的生產資訊，在需要的時間進入 MES。

導入 Production Reporting Latency 分析有哪些效益？

透過 MES 建立報工延遲分析，企業可以提高生產進度透明度、改善 WIP 資料準確性、降低人工補登造成的履歷錯誤，並提升 ERP、APS 與現場生產資訊的一致性。

更重要的是，管理者可以從：

「MES 上面有沒有資料？」

進一步確認：

「MES 上面的資料是否足夠即時，可以用來做生產決策？」