標籤誤貼未清潔鋼瓶遭維修人員攔截｜Near Miss 與 Good Catch 案例

06-06｜標籤誤貼未清潔鋼瓶遭維修人員攔截未遂案例

在鋼瓶維修流程中，Status Label（狀態標籤）是辨識鋼瓶目前作業狀態的重要資訊之一。

但是：

Label
（標籤）

只能代表一項 Status Information（狀態資訊），不能單獨取代鋼瓶實際狀態與相關作業紀錄的確認。

本案例中，一支鋼瓶被貼上表示前端作業已完成的狀態標籤，並送往 Maintenance Area（維修區域）。

維修人員在後續作業前進行資料確認時，發現：

Status Label
（狀態標籤）

與：

Work Record
（作業紀錄）

無法相互對應。

進一步確認後發現，該鋼瓶實際並未完成標籤所表示的前端清潔／處理程序。

維修人員因此立即停止後續作業。

異常是在：

Valve Opening
（開閥）

以及：

Pressure Panel Connection
（壓力盤連接）

之前被發現。

因此沒有進一步進入拆閥相關作業。

這起案例屬於：

Near Miss
（未遂事件）

同時也是：

Good Catch
（成功攔截）

的重要案例。

一、案例概要

事件類型：

Status Label / Record Mismatch
（狀態標籤／紀錄不一致）

主要異常：

鋼瓶上的 Status Label（狀態標籤）顯示前端作業已完成，

但維修人員查核相關 Work Record（作業紀錄）時，沒有找到可以支持該狀態的對應紀錄。

進一步確認後發現：

Actual Cylinder Status
（鋼瓶實際狀態）

與：

Label Status
（標籤所表示的狀態）

不一致。

發現時機：

・Valve Opening（開閥）之前
・Pressure Panel Connection（壓力盤連接）之前
・Valve Removal（拆閥）之前

事件結果：

・維修人員停止後續作業
・異常鋼瓶未繼續進入維修程序
・沒有進一步發展成設備或人員事件

因此本案例可以分類為：

Near Miss / Good Catch
（未遂事件／成功攔截）

【照片 06-06-01｜鋼瓶 Status Label 示意】

二、Label Says Complete 不等於 Process Actually Complete

這是本案例最重要的第一個觀念。

如果鋼瓶貼有：

Cleaning Completed
（清潔完成）

或其他表示前端處理已完成的狀態標籤，

後端人員很容易產生：

「既然已經貼標籤，就代表前面的作業已經完成。」

這種預期。

但是：

Label Says Complete
（標籤顯示完成）
≠
Process Actually Complete
（實際作業已完成）

同樣：

Label Present
（標籤存在）
≠
Record Exists
（作業紀錄存在）

因此 Status Label（狀態標籤）與 Work Record（作業紀錄）最好能夠相互支持。

三、本案例為什麼沒有進入 Pressure Panel？

06-05 的案例中：

鋼瓶已經進入 Pressure Confirmation（壓力確認）階段，

才發現實際狀態與預期不符。

但 06-06 不同。

本案例中，維修人員在進一步操作之前就發現：

Label
（標籤）

與：

Record
（紀錄）

存在不一致。

因此：

Status Mismatch Detected
（發現狀態不一致）
↓
STOP
（停止）
↓
No Valve Opening
（未開閥）
↓
No Pressure Panel Connection
（未連接壓力盤）
↓
No Valve Removal
（未拆閥）

異常被攔截在更前端的位置。

這也是為什麼本案例可以被視為：

Good Catch
（成功攔截）。

四、這個案例不能直接寫成「滿瓶誤送」

這一點需要特別區分。

06-05 已知的事實是：

Full / Pressurized Cylinder
（滿瓶／仍具有高壓內容物的鋼瓶）

實際進入維修流程。

因此 06-05 可以明確記錄：

Unexpected High Pressure
（非預期高壓）。

但是 06-06 目前已知的是：

・標籤顯示前端處理已完成
・沒有相符的完成紀錄
・進一步確認實際沒有完成標籤所表示的清潔／處理程序
・維修人員在開閥及接壓力盤前停止作業

因此不能從這些資料直接推論：

Full Cylinder
（滿瓶）

或：

High Pressure Cylinder
（高壓鋼瓶）。

比較正確的描述是：

Cylinder Status Not Verified / Process Not Completed
（鋼瓶狀態未獲確認／前端程序未完成）

這是技術案例紀錄非常重要的原則：

Unknown
（未知）

不要自行補成：

Known Fact
（已知事實）。

五、Status Label 是 Information Barrier，不是 Physical Barrier

Status Label（狀態標籤）的主要功能是：

Communication
（資訊傳遞）

與：

Status Identification
（狀態識別）。

因此它可以被視為：

Information Barrier
（資訊型防護層）。

但標籤本身不能：

・確認鋼瓶實際壓力
・證明前端作業確實完成
・證明鋼瓶內容物狀態
・防止錯誤鋼瓶進入流程
・取代 Physical Verification（實際確認）

所以：

Information Barrier
（資訊防護）
＋
Record Verification
（紀錄確認）
＋
Physical Verification
（實際狀態確認）

應該是不同層次的防護。

六、為什麼 Work Record 很重要？

Work Record（作業紀錄）的價值，不只是留下：

「有人做過。」

而是建立：

Traceability
（追溯性）。

例如當 Status Label 顯示：

Process Complete
（作業完成）

時，相關紀錄應能協助確認：

・是哪一支鋼瓶？
・進行了什麼程序？
・程序是否完成？
・相關狀態是否可以追溯？
・標籤與紀錄是否指向同一支鋼瓶？

本案例正是因為：

Label Status
（標籤狀態）

與：

Available Record
（現有紀錄）

無法相互支持，

才讓維修人員察覺：

Something Is Wrong
（狀態可能有問題）。

因此紀錄本身也形成了一道：

Detection Barrier
（偵測防護層）。

七、不要因為標籤存在就跳過確認

在重複性的維修工作中，很容易形成：

「以前送來的都是處理完成的。」

或：

「有這張標籤就代表沒問題。」

這類 Assumption（假設）。

但事故往往發生在：

Expected Condition
（預期狀態）

與：

Actual Condition
（實際狀態）

不同的時候。

因此：

Routine Work
（例行工作）
≠
No Verification Needed
（不需要確認）

Label Present
（有標籤）
≠
Verification Complete
（確認已完成）

越是每天重複的工作，越需要避免：

Assumption-based Work
（依賴假設進行作業）。

八、Good Catch 的價值不是「剛好被看到」

Good Catch（成功攔截）不應被簡化成：

「還好有人發現。」

如果維修人員是透過：

・Status Check（狀態確認）
・Record Check（紀錄確認）
・Information Cross-check（資訊交叉確認）

發現異常，

代表原本流程中仍存在有效的 Detection Barrier（偵測防護層）。

因此 Good Catch 應該被記錄：

What Was Found?
（發現什麼？）

How Was It Found?
（怎麼發現？）

At What Stage?
（在哪個階段發現？）

What Was Prevented?
（避免了什麼後續操作？）

Which Barrier Worked?
（哪一道防護層發揮作用？）

這些資訊可以用來改善其他流程。

九、Near Miss 不代表可以不用調查

因為本案例沒有造成：

・人員受傷
・設備損壞
・大量氣體洩漏

很容易被當成：

「沒有發生事故。」

但 Near Miss（未遂事件）的價值就在於：

Failure Path
（失效路徑）

已經開始形成，

只是被其中一道 Safety Barrier（安全防護層）成功阻止。

因此應該問：

「如果維修人員沒有發現 Label / Record Mismatch，下一步會發生什麼？」

可能的下一步原本會是：

Pressure Panel Connection
（壓力盤連接）

甚至：

Valve-related Work
（瓶閥相關作業）。

因此 Near Miss 是非常重要的 Learning Opportunity（學習機會）。

十、不要急著把 Root Cause 寫成「貼錯標籤」

本案例已知：

Status Label
（狀態標籤）

與實際流程狀態不一致。

但：

Wrong Label
（錯誤標籤）

可能只是：

Direct Condition
（直接異常）

而不一定是：

Root Cause
（根本原因）。

後續仍應調查：

・為什麼錯誤標籤會出現在這支鋼瓶？
・標籤如何產生？
・標籤由誰、在什麼條件下使用？
・是否需要對應 Work Record 才能建立完成狀態？
・Cylinder Identification（鋼瓶識別）是否可能混淆？
・Process Routing（流程路由）是否存在漏洞？
・Handover（交接）是否完整？
・是否有 Independent Verification（獨立確認）？

因此：

Wrong Label
（錯誤標籤）
≠
Root Cause Confirmed
（根本原因已確認）

十一、不要只靠「提醒人員注意」作為改善

如果事故改善最後只有：

「提醒作業人員不要貼錯。」

這種措施通常仍高度依賴 Human Memory（人員記憶）。

更值得檢查的是：

是否能讓：

Label
（標籤）

Record
（紀錄）

Cylinder Identification
（鋼瓶識別）

Process Status
（流程狀態）

彼此產生更強的關聯。

例如改善方向可以從：

Traceability
（追溯性）

Status Verification
（狀態確認）

Independent Check
（獨立確認）

Error Proofing / Poka-Yoke
（防錯設計）

等角度評估。

但實際採用何種方法，仍應依公司流程與核准制度決定。

十二、本案例中的 Safety Barrier

本案例可以整理出多層防護：

Barrier 1：

Correct Process Completion
（正確完成前端程序）

目的：

只有真正完成必要前端程序的鋼瓶，才能進入下一階段。

Barrier 2：

Correct Status Label
（正確狀態標示）

目的：

讓後續人員辨識鋼瓶目前狀態。

Barrier 3：

Work Record
（作業紀錄）

目的：

提供可追溯的完成證據。

Barrier 4：

Label / Record Cross-check
（標籤／紀錄交叉確認）

目的：

發現資訊不一致。

Barrier 5：

Pressure Confirmation Before Valve Removal
（拆閥前壓力確認）

目的：

即使前面的 Information Barrier（資訊防護層）全部失效，仍透過實際狀態確認建立最後一道重要防線。

在本案例中：

Barrier 1 / 2
存在異常

但：

Barrier 3 / 4
協助維修人員成功發現問題。

因此事件在進入 Pressure Panel 之前被停止。

十三、與 06-05 案例比較

06-05：

Unexpected / Residual Cylinder Pressure
（非預期／殘留鋼瓶壓力）

異常發現階段：

Pressure Panel
（壓力盤）

事件結果：

・Protective Device Activation
（保護裝置作動）

・Pressure Gauge Damage
（壓力錶損壞）

・Valve Removal 被阻止

06-06：

Status Label / Record Mismatch
（狀態標籤／紀錄不一致）

異常發現階段：

Before Valve Opening
（開閥之前）

Before Pressure Panel Connection
（連接壓力盤之前）

事件結果：

・後續作業停止
・沒有進入壓力盤確認階段
・沒有進一步發展成設備事件

因此可以看到：

Earlier Detection
（越早發現）
↓
Lower Event Progression
（事件發展程度越低）

這就是 Prevention Barrier（預防防護層）與 Detection Barrier（偵測防護層）往前移的重要性。

十四、Failure Mode Database（故障模式資料庫）建議紀錄

Failure Mode ID：

FM-012

Failure Mode：

Status Label / Record Mismatch
（狀態標籤／紀錄不一致）

Process：

Cylinder Maintenance Receiving
（鋼瓶維修接收）

Observed Condition：

Status Label indicated process completion, but corresponding completion record could not be confirmed.
（狀態標籤顯示程序完成，但無法確認相符的完成紀錄。）

Actual Condition：

Required upstream process had not been completed as indicated by the label.
（實際未完成標籤所表示的前端程序。）

Detection Method：

Label / Record Cross-check
（標籤／紀錄交叉確認）

Detection Stage：

Before Valve Opening
（開閥之前）

Before Pressure Panel Connection
（壓力盤連接之前）

Event Classification：

Near Miss / Good Catch
（未遂事件／成功攔截）

Safety Barrier：

Status Verification
（狀態確認）

Record Verification
（紀錄確認）

Information Cross-check
（資訊交叉確認）

Possible Contributing Factors：

・Label Control
（標籤管理）

・Process Routing
（流程路由）

・Cylinder Identification
（鋼瓶識別）

・Handover
（交接）

・Record Control
（紀錄管理）

・Other Factors
（其他因素）

Confirmed Root Cause：

依原始事故調查結果填寫。

Cause Status：

CONFIRMED（已確認）
PROBABLE（高度可能）
POSSIBLE（可能）
UNCONFIRMED（尚未確認）

十五、本案例的重要判斷觀念

本案例可以整理成：

Label Says Complete
（標籤顯示完成）
≠
Process Actually Complete
（實際程序已完成）

Label Present
（標籤存在）
≠
Record Verified
（紀錄已確認）

Wrong Label
（錯誤標籤）
≠
Root Cause Confirmed
（根本原因已確認）

Process Not Completed
（程序未完成）
≠
Full Cylinder Confirmed
（已確認為滿瓶）

Near Miss
（未遂事件）
≠
No Investigation Needed
（不需要調查）

Good Catch
（成功攔截）
＝
Valuable Safety Information
（有價值的安全資訊）

因此本案例最重要的經驗是：

Do Not Trust a Single Indicator
（不要只依賴單一狀態指標）

而應：

Cross-check Label, Record and Actual Condition
（交叉確認標籤、紀錄與實際狀態）。

十六、相關文章

・04-05｜鋼瓶維修前接收與狀態確認
・06-05｜未清潔滿瓶誤送維修廠造成壓力盤洩壓事故案例
・07-04｜鋼瓶壓力測試盤與拆閥前壓力確認
・09-01｜Stop Work 與 Good Catch
・09-02｜多層安全防護
・09-04｜異常現象、直接原因與根本原因的判斷方法
・09-05｜鋼瓶維修經驗如何轉化為 Failure Mode Database
・09-06｜新進維修人員的鋼瓶異常判斷與經驗傳承

注意事項

本文為 Status Label / Record Mismatch（狀態標籤／紀錄不一致）的 Near Miss / Good Catch（未遂事件／成功攔截）案例整理。

本案例已知的是：

鋼瓶實際未完成標籤所表示的前端清潔／處理程序，且維修人員在 Valve Opening（開閥）與 Pressure Panel Connection（壓力盤連接）之前發現異常並停止後續作業。

本文不將該鋼瓶進一步推定為 Full Cylinder（滿瓶）或具有特定壓力，除非原始事故紀錄能提供相關證據。

Status Label（狀態標籤）、Work Record（作業紀錄）與 Physical Condition（實際狀態）應視為不同層次的資訊與安全防護，不應以單一標籤取代必要的實際確認。

最後更新：2026-09-28