CPK 報告又綠又紅，你猜主管信哪個？
記得幾年前有次夜班，產線突然連爆好幾批貨，品質報表上，Cpk 值從原本的 1.3 突然掉到 1.08，紅燈狂閃。製造部那邊急得跳腳，因為這代表良率可能要慘了。我跟小李盯著螢幕，看著那些看似沒什麼異常的數據點，心裡也是一堆問號。結果追半天，才發現是上游某個新料批次出了包，數值雖然還在規格內，但已經往邊緣靠了。那晚，我們就開始討論，到底什麼時候該拉警報？那些「還沒出界」但已經怪怪的數據，到底要不要理？
報警器靈敏度過高，其實更麻煩
你可能覺得，數據一有變動就報警不是很好嗎？提早發現問題，提早解決。說實話，這完全是個美麗的誤會。我們半導體廠的機台每天吐幾十萬筆數據，如果每點小波動都報警，你根本沒時間做其他事，每天光是確認是不是「誤報」就飽了。這就是所謂的「誤報率」問題。
想像一下，你家煙霧偵測器，煮個泡麵就狂叫，第一次你衝過去關，第二次你開始懷疑，第三次你可能直接拔電池。產線的 Run Rules 就是這個道理。我們用的那些 Run Rules，像是「連續 N 點在中心線同一側」、「連續 N 點趨勢向上或向下」這種，其實都是基於統計學的假設。例如，我們通常假設資料是常態分佈，而且是獨立隨機的。但現實中，產線的數據哪有那麼乖？常常會有一些微小的、系統性的偏移，但還沒嚴重到突破管制界線。這些時候，如果 Run Rules 設計得太過靈敏，就很容易產生大量的誤報（False Alarm），讓你疲於奔命，最後反而對真正的警報失去警覺。
所以重點是，你必須找到一個平衡點：既能及早發現真正的問題，又不會被一堆雜訊淹沒。
實際上，我們怎麼調整 Run Rules？
通常我們用的 Run Rules 都有幾個經典款，比如：
* Rule 1：單點突破管制界線 (Outside Control Limits)：這是最直接的，一出界就報警，誤報率最低，但通常問題已經很嚴重了。
* Rule 2：連續 N 點落在中心線同一側 (N points on one side of center line)：例如連續 7 點都比平均值高，就算沒出界，也表示可能有點不對勁。
* Rule 3：連續 N 點趨勢向上或向下 (N points trending up or down)：例如連續 6 點一直往上跑，顯然有系統性的漂移。
這些規則的「N」值，就是我們可以調整的地方。例如，Westgard 的 Run Rules 裡面，Rule 2 是「連續 8 點落在中心線同一側」，但有時候我們會調整成「連續 7 點」甚至「連續 6 點」，來提高靈敏度。但是！每一次調整，誤報率就會跟著飆高。
舉例來說，如果資料真的完全隨機，而且是常態分佈，光是「連續 7 點在中心線同一側」這個規則，誤報率大概是千分之七點八。換句話說，你可能每跑 128 批貨，就有一批會因為這個規則被誤判。如果你把 N 縮小，誤報率會更高。試想一下，如果你的 DPMO 只有 6210（6 Sigma 等級），結果誤報率就已經快到千分之八，那到底是真的有問題，還是系統在跟你開玩笑？
所以，在調整 N 值的時候，你真的要很小心。我們會回頭看過去半年，類似這樣「灰色地帶」的數據，最後有沒有真的演變成大問題。如果大部分的「連續 7 點趨勢向上」最後都只是虛驚一場，那可能這個 Rule 的 N 值需要調大一點，或者搭配其他 Rule 一起判斷。
最常見的坑：主管看顏色，工程師看數據
說實話，最大的坑就是主管只看報表顏色，一看到紅字就要求你「馬上處理」，但卻不管這些紅字是不是因為誤報率過高。我遇過最扯的，是某個產線為了「看起來」很穩定，把 Run Rules 調得超級寬鬆，結果真的發生異常，等到數據突破管制界線才發現，那批貨早就報廢好幾天了。相反的，也有產線為了「超前部署」，把 Run Rules 調得超級靈敏，導致每天警報響不停，工程師每天跑現場確認，最後對警報麻痺了，反而錯過了真正需要處理的問題。
坦白講，這就是人性。大家都想數據好看，但好不好看背後的統計意義，卻常常被忽略。我們工程師的工作，不只是把報表弄成綠色，而是要確保報表上的顏色真的能反映產線的真實狀況。
今天能做的一件事
重新檢視你現在用的 Run Rules，問問自己：「這些規則的誤報率，在我的製程上合理嗎？」