那天 CPK 報告出來，全場沉默了三秒
還記得好幾年前，我們廠裡有批新產品，剛導入就出狀況。那天產線的機台警報大作，整個 MES 系統紅通通一片。主管衝過來，臉色鐵青地問：「到底發生什麼事？」結果一查，發現某個關鍵參數的 Cpk 竟然掉到 1.08，從原本的 1.33 一路崩盤。重點是，這個參數一直以來都很穩，根本沒人料到會出事。那次我們光是找出問題根源、釐清影響範圍，就花了快兩天，整個產線停擺，損失不是開玩笑的。
問題出在哪？
說穿了，我們那時候的警報系統根本就是「馬後炮」。等到 Cpk 爛到一個程度才報警，那都已經是慘案發生了。就像你開車，等到引擎都冒煙了才顯示溫度過高，你說這有什麼用？品質警告系統，要的是「早期預警」，而不是「事後公告」。白話一點講，就是要在問題還小的時候，就讓你看到端倪，在 Cpk 還沒掉到 1.08 之前，就先預警。
所以重點是，我們需要設計一些「領先指標」，在品質變壞之前，就能先偵測到訊號。這些指標不會直接告訴你產品壞了，而是告訴你「快要壞了」。
實際上怎麼做？
最簡單也最常用的，就是去觀察製程參數的「趨勢變化」。舉個例子，如果我們某個蝕刻時間的公差是 +/- 5 秒，你可能會設定當值超過公差時才警報。但早期預警不是這樣玩。
- 觀察標準差 (Standard Deviation, StDev) 的變化：
所以重點是，除了監控平均值，也要把標準差的趨勢變化納入早期預警的指標。
- 建立「連續異常點」的判斷準則：
例如，我們發現 DPMO (Defects Per Million Opportunities) 平時大概是 2000 左右，某天突然飆到 6210。這當然是紅燈。但如果 DPMO 連續五批都從 2000 慢慢爬到 2500、3000、3500，雖然還沒到紅燈，這絕對是個潛在風險。
所以重點是，定義「連續幾點」數據落在某個預警區間，才觸發警報，而不是只看單點數據。
最常見的坑
說實話，很多人都會把預警系統做得太靈敏，導致「狼來了」的故事不斷上演。警報一直響，但每次去查都沒事，久了大家就麻痺了。最後真的出事，反而沒人理。我們以前就遇過，工程師把預警區間設得太窄，一點點波動就發警報，搞得大家每天都在跑警報，結果每次都白跑。後來我們重新回顧數據，發現大部分的「預警」根本就是正常波動，只是因為區間設太死。
另一個坑是，預警指標設了一大堆，但根本沒人去看。或者看了也不知道該怎麼辦。你設定了十幾個預警指標，每個指標都有自己的觸發條件，然後每天幾百條預警訊息跑出來，誰有空去消化？說穿了，不是指標越多越好，而是要挑選真正關鍵、有意義的指標。
今天能做的一件事
回去看看你現在的品質警報系統，有沒有把「標準差趨勢」納入監控。