那天 CPK 報告出來，全場沉默了三秒
還記得好幾年前，我們產線有個新產品導入，大家都說會爆賣。結果咧？剛開始生產，良率就掉漆。開會時，主管臉色鐵青地盯著那份 CPK 報告，上面赫然寫著 1.08。你知道 CPK 1.08 是什麼概念嗎？說穿了，就是你生產一百萬片晶圓，大概會有 6210 片是報廢的！我永遠記得那三秒鐘的沉默，比半夜停電還恐怖。後來主管直接點名：「XX，你 IE 部的，給我想辦法！」幹，我心裡 OS：IE 哪是萬靈丹啊？但嘴上還是得說：「是，我來處理。」
問題出在哪？
很多時候，我們看到良率不好、產能卡住，第一個反應就是「快點修機台」或是「換個參數試試看」。這其實就像你車子發不動，卻只會一直轉鑰匙一樣。坦白講，這不是解決問題，只是在試運氣。說穿了，你需要一個有系統的方法來找出真正的病因。這個方法，其實就是 IE 工具箱的核心精神：從現象追溯到根本原因，然後針對性地改善。 很多工程師只會看結果，但不會分析過程。這也是為什麼 IE 這麼重要。
實際上怎麼做？
要怎麼從 CPK 1.08 這種慘況，一步步爬出來？我通常會這樣做：
- 定義問題 (Define)： 首先，你要清楚「問題」到底是什麼？是良率太低？產能不夠？還是成本太高？以上面的例子來說，就是 CPK 1.08，導致 DPMO 6210。數字越具體越好，千萬別說「良率有點差」。
- 量測現況 (Measure)： 接下來，你需要收集數據。這個步驟最容易踩雷，很多新人只會撈半天的機台 Log，卻不知道該看什麼。我會建議你畫流程圖，然後在每個關鍵站點量測時間、數量、不良率。例如，我們可以去看哪一個製程步驟的不良率最高？是蝕刻？還是薄膜？或者，是不是某個機台的停機時間特別長？
- 分析原因 (Analyze)： 拿到數據後，不是堆在那裡發呆。你可以用魚骨圖（Ishikawa Diagram）或 5 Whys 法，來系統性地找出潛在原因。舉個例子，如果發現 A 機台的停機時間特別長，那就要問：為什麼停機長？是不是頻繁當機？為什麼頻繁當機？是程式問題？還是硬體老化？一步步追問，直到找到那個「你覺得可以改變」的根源。
- 改善方案 (Improve)： 找到原因之後，就可以設計改善方案了。這時候，不是拍腦袋想，而是根據數據和分析結果。例如，如果是程式問題，就請寫程式的來優化；如果是硬體老化，就考慮維修或更換。記住，改善方案要有「可量測的目標」。
- 管制成果 (Control)： 最後，實施改善後，你必須持續監控，確保問題沒有復發。這就像你開刀後還需要復健一樣。可以設定一個週期性的報表，或者建立一個自動監控系統。
所以重點是，這五個步驟是環環相扣的，缺一不可。
最常見的坑
說實話，IE 工具箱聽起來很棒，但實際操作起來，最常遇到的就是「數據不全」和「抗拒改變」。有一次，我要求一個新人去拉某個機台的數據，結果他只拉了前一天的。我問他：「前一個月甚至前一年的數據呢？」他一臉茫然。沒有足夠的歷史數據，你根本無法判斷現在的狀況是「常態」還是「異常」。另一個坑就是，當你提出改善方案時，常常會遇到「我們以前都是這樣做的」這種阻力。這時候，數據就是你最強大的武器。
今天能做的一件事
找出你現在最頭痛的一個問題，然後用「數字」定義它。