停機追蹤軟體:撬動 OEE 的 8 個停機原因碼
停機追蹤軟體從每月 200 歐元到每月 20,000 歐元不等。從價格上你看不出這樣的事:週一早上產線停下來,班組長只有 30 秒在平板上輸入,下一個零件就要走到傳送帶上了,這時候軟體到底有多大用處。
真正重要的是:軟體能不能幫一線操作員選對停機原因。這就是關鍵。原因碼太模糊,月底 OEE 報告裡只會寫著 "產線停了 14 個小時",沒人知道為什麼。原因碼太細,操作員就放棄了,80% 的時候按 "其它"。最後你花了錢,得到一個什麼都沒記下的系統。
這份指南講實戰。在中小規模工廠裡真正撬動 OEE 的 8 個停機原因碼、可以忽略的 30 多個碼、iPhone 訊號源在班次中長什麼樣、以及怎麼挑選停機追蹤軟體而不被演示帶偏。
為什麼大多數停機追蹤都偏了方向
審計新客戶的停機資料時,同樣三種模式會反覆出現。
第一是 "其它" 專案膨脹。有一家工廠用著 24 個原因碼,頻次前三是 "非計畫停機"、"輕微問題"、"其它",合起來佔記錄停機的 62%。這種資料沒法做根因分析。你知道產線停了,但完全不知道要修什麼。
第二是重複記賬。操作員在 MES 裡記一次停機,在維護系統裡又記一次,為了交班還在紙質日誌上記第三次。數字永遠對不上。廠長就在生產會上挑符合自己想要論點的那個資訊源。
第三是輸入延遲。產線 9:12 停的,操作員 11:47 才回到平板上記。這時記的是 "大約 20 分鐘",不是真實的 8 分 14 秒。即時監控就變成了事後追憶。
解決辦法不是加更多原因碼,而是減少原因碼,並且在產線停下的那一刻,把足夠讓下一個責任人能行動的上下文一起記下來。
重要的 8 個原因碼(以及可以忽略的 30 個)
在過去 18 個月裡,我們和大約 40 家工廠合作,同樣這 8 個原因碼佔了總停機時長的 85% 到 92%。供應商想塞進預設模板裡的其餘 30 多個碼,只佔剩下那一小塊。追蹤這 8 個,其餘的讓自由填寫或者歸到 "其它" 就夠了。
真正撬動 OEE 的 8 個碼如下:
- 物料缺貨。 入料端沒有零件。要麼上游工序比我們這條產線慢,要麼套件沒有按時備好。
- 物料卡住或上游來料質量不良。 入料端有零件,但是錯的零件、損壞的零件、或者卡住了。和缺貨是不同的原因和處理。
- 換刀或換配方。 SKU 之間的計畫切換。單獨追蹤,免得把非計畫停機弄髒。
- 機器故障。 機器的物理部件壞了。軸承、皮帶、氣路這類,需要技術員上手的東西。
- 電氣或控制系統故障。 機器部件沒問題,但是 PLC、感測器、驅動器報錯了。排查路徑不一樣。
- 操作員缺崗或休息。 產線能跑但工位上沒人。交班之間的空檔或非計畫休息都算。
- 質量掛起。 最近幾個零件被檢驗判為不合格,產線停下來等人決定怎麼處理。
- 上游或下游阻塞。 我們這條線沒問題,但是包裝慢了導致傳送帶堆滿,或者倉庫收不下額外的托盤。
就這些。這 8 個碼能抓住絕大部分撬動 OEE 數字的因素。其它的要麼是這些類別下的子項,要麼是一個月一次自由填寫、在 OEE 覆盤裡翻一翻就夠的末端事件。
之所以這套行得通,是因為這 8 個碼每一個都對應不同的行動。物料缺貨要找計畫員,機器故障要找維護,質量掛起要找質量。如果原因碼不能告訴操作員 "該聯絡誰",那就是錯的原因碼。
iPhone 訊號源長什麼樣
如果你讀過OEE 計算指南,就知道停機資料直接掛到可用率,而可用率是 OEE 三大支柱之一。資料只有在產線停下來那一刻被記下來,才有意義。
傳統做法是接到 PLC 的平板。PLC 觸發停機事件後彈窗,提示操作員選原因碼。能用,但硬體加整合每條產線 4,000 到 8,000 歐元,而且會繫結到你最早選的那家 PLC 供應商。
iPhone 訊號源徹底跳過 PLC 整合。在每個工位放一臺翻新 iPhone,跑一個 App。攝影機看著產線,零件流停下來超過設定閾值(通常按節拍 8 到 15 秒),App 就感知到,操作員在螢幕上從 8 個原因碼裡選一個。全程不到 5 秒。
五年前做不到、現在能做到的原因有三個。一是 iPhone 攝影機在沒有專用感測器的情況下,也能在工廠照明下可靠識別節拍停頓。二是端上處理,資料不出廠、不繞雲、沒有往返延遲。三是操作員對這個介面已經熟悉。除了 "點一下原因" 之外,沒有培訓成本。
用這套方法讓一條產線跑起來,硬體每個工位低於 1,000 歐元。一臺翻新 iPhone、一個支架、一盞環燈、一個用來傳資料的乙太網轉接頭。3 條產線的停機訊號源,半個下午就能拉起來。
從記錄到行動:班次級停機工作流
記錄資料只是一半工作。另一半是讓這些資料在班次結束前就觸發動作。
在 OEE 改進真正有進展的工廠裡,穩定有效的工作流是這樣的。最近 1 小時記下的所有原因碼都上到共享班次儀表盤。班組長在 15 分鐘的現場巡線時一眼掃過去。兩個小時裡物料缺貨記了 3 次,午餐前一條 Slack 訊息就發給計畫員了,而不是等到週四下次計畫會。一臺機器上集中出現機器故障,那就立刻呼維護,不等下一個排好的 PM 時段。
儀表盤不需要花哨。8 個原因碼、當前班次的次數和分鐘合計、對比上週的趨勢 sparkline,一頁放下就夠。重要的是班組長真的在看,而看本身就在引發對話。
每個班次結束時,班組長在交班裡寫兩句話。最大的停機源是什麼、對它做了什麼。這就是週五生產會上真正會用到的資料。牆上的 OEE 數字是滯後指標。兩句話交班是先行指標。
這個工作流的攝影機版本可以參考攝影機生產監控這篇,把視覺管線講得更細。配合這份資料的交班模板可以參考製程工程師交班那篇。
如何挑選停機追蹤軟體
評估停機追蹤軟體時,大多數演示會用儀表盤、AI 助手、預測性維護模組來吸引你。演示可以忽略。只問五個問題就夠。
第一,從產線停下來到停機被記下來,要多少秒?如果每個事件佔用操作員超過 10 秒,一個月內資料就會充滿延遲和遺漏。
第二,預設配多少個原因碼,能不能縮到 8 個?如果供應商不肯放棄 40 個碼的分類體系,那他沒理解現場的真實機器停機追蹤。
第三,系統在沒有 PLC 連線的情況下能不能跑?如果記下停機的唯一路徑是控制系統整合,意味著你還沒看到資料,就得先買一個 3 個月的匯入專案。基於攝影機或基於按鈕的記錄應該是基礎功能,不是升級選項。
第四,原始資料長什麼樣?讓供應商把一個現有客戶一週的匿名化停機事件用 CSV 導給你。如果 5 分鐘內做不到,那資料就被鎖在儀表盤裡了,以後你想自己分析時會很難取出來。
第五,頭一年每條產線的總擁有成本是多少,硬體、整合、培訓、訂閱都算進去?很多團隊預算裡只列許可證,其它就忘了。每月 200 歐元的訂閱加上 12,000 歐元整合費,那就不是一年 2,400 歐元的決定。
好的停機追蹤軟體,是班組長不用催就會用的,是維護團隊會信任的資料,是 CFO 在第二年不用做減值的那種軟體。
常見問題
停機追蹤和 OEE 軟體有什麼區別? OEE 軟體用可用率、效能、質量來算出整體 OEE 值。停機追蹤軟體透過記錄產線停下的原因,專門強化可用率這一支柱。許多團隊兩邊都需要,但你可以單獨執行停機追蹤,以後再補上效能和質量的部分。完整計算請參考OEE 計算指南。
原因碼要拆到多細? 8 到 10 個是最優區間。少於 6 個就分不開計畫問題和機器問題。超過 12 個,兩週內操作員就開始按 "其它"。每次會議上有人提議就加一個碼,這種衝動要忍住。
沒有 PLC 也能做停機追蹤嗎? 能。裝好的 iPhone 用攝影機記錄,是沒有現代 PLC 的工廠、或者老線後期補裝的最清爽選擇。在工位放物理按鈕、產線停時讓操作員按一下的按鈕記錄也可以,但每個事件多佔操作員約 2 秒。
停機追蹤軟體多快能跑起來? 用 iPhone 訊號源,一條產線半個下午就能跑起來,8 到 12 條產線規模的工廠全廠一週內能上線。PLC 整合系統通常每條線要 6 到 12 周,含測試。
停機追蹤軟體會替代 CMMS 嗎? 不會。CMMS 管工單、備件庫存、PM 排程。停機追蹤管即時事件記錄和原因碼標註。兩邊應該打通,產線上記下的機器故障應該在 CMMS 裡自動生成工單草稿。但解決的問題不同。
經常會有人問的一個框架問題是,停機追蹤軟體如何接到更寬的整體裝置效率(OEE)報告。停機訊號源就是進入 OEE 的可用率資料。如果非計畫停機和計畫停機兩邊都沒有乾淨的資訊源,週報裡的可用率數字就是猜的,團隊會去爭哪條產線最差,而不是去修。有了乾淨的訊號源,同樣的數字就成為所有根因分析的起點,周覆盤從問責轉向學習。帶原因碼的事件讓班組長可以從最大的損失源開始優先處理,按季度把可用率拉起來。
穩定下來的報告節奏是一份每週停機報告,接到原因碼的帕累託圖上,把平均修復時間(MTTR)和 OEE 分數與每條產線的產量損失放在同一時間軸上。配置的原因碼應分別處理裝置故障、節拍下降、質量問題、計畫維護,這樣周覆盤能看清哪個類別增長最快。用這種資料驅動的持續改進專案,會持續聚焦在最大的損失源上,而不是聲音最大的問題上。靠乾淨訊號源把周覆盤肌肉練起來的團隊,一個季度內就能感受到差距。
本週就讓停機追蹤跑起來
如果你想這週五就讓一條產線的停機訊號源跑起來,最快路徑是一臺翻新 iPhone、一個支架、一個免費 Enao 賬戶。挑出適合你工廠的 8 個原因碼,把攝影機對準產線,一個小時內資料就開始流。沒有 PLC 整合,沒有 12 周專案,沒有五位數賬單。
