那天 CPK 報告出來，全場沉默了三秒
還記得嗎？上個月那批新製程的晶圓，良率一直卡在一個不上不下的尷尬區間。老闆每天早會都問，工程師每個都抓頭。有一天，PM 信心滿滿地把 CPK 報告丟出來，螢幕上大大地秀著一個數字：1.08。會議室裡瞬間安靜，只有冷氣的嗡嗡聲。PM 臉上笑容僵掉，老闆眉頭鎖得更緊。你知道嗎？CPK 1.08 代表什麼？代表我們有高達 6210 DPMO 的機率會做出不良品！換句話說，每十萬個產品，就有六千多個是廢料。那時候我心裡就想，這種狀況，根本就是六標準差 DMAIC 專案的菜啊！
問題出在哪？不是所有問題都適合 DMAIC
說穿了，DMAIC（Define, Measure, Analyze, Improve, Control）這套方法，就是專門拿來解決那種「問題很明確，但原因不明確，而且影響很大」的狀況。你看上面那個 CPK 1.08 的例子，我們知道良率不好，知道哪個產品線有問題，也知道會損失多少錢，但就是不知道根源在哪。這種時候，你不能光憑經驗拍腦袋去改參數，那只會把事情搞得更複雜。
所以重點是，在決定是不是要啟動 DMAIC 專案前，你要先問自己幾個問題：
- 問題夠痛嗎？ 這是最現實的。如果只是偶爾出現的零星客訴，影響不大，那可能不用殺雞用牛刀。但像良率這種直接噴錢的，肯定要痛。
- 問題夠明確嗎？ 你能清楚定義問題是什麼嗎？例如，是「某條機台的產品 A 的厚度超出規格」，而不是「最近良率好像有點差」。
- 問題的原因不明嗎？ 如果你已經知道原因，例如是設備壞了，那直接修設備就好，不用繞一大圈。DMAIC 是用來找「未知原因」的。
- 數據能拿到嗎？ DMAIC 非常仰賴數據，如果你連最基本的量測數據都拿不到，那後面就玩不下去了。
如果這四點你都點頭說「是」，那恭喜你，你的問題很可能就是 DMAIC 的目標！
實際上怎麼做？用數字說話
坦白講，判斷一個問題適不適合 DMAIC，最簡單粗暴的方式就是看數據。
- 看不良率 (Defect Rate) 或 DPMO (Defects Per Million Opportunities)： 如果你的 DPMO 高於 3000 (大概就是 Cpk 1.0 左右)，而且這個不良率已經持續一段時間，甚至有惡化的趨勢，那就是個警訊。我以前看過一個案子，某個製程的 DPMO 一直在 6000 上下徘徊，導致每個月都要報廢一大批晶圓。這種等級的損失，不動 DMAIC 根本說不過去。
- 看 Cpk/Ppk： 當你的 Cpk 或 Ppk 值低於 1.33 (對應大概 6210 DPMO)，甚至像前面提到的 1.08 這種慘狀，表示你的製程能力不足以穩定生產合格產品。這時候，光靠日常巡檢或小修小補是沒用的，需要系統性的分析。
- 看客戶抱怨 (Customer Complaints)： 如果同一個問題的客戶抱怨重複發生，而且數量不低，例如每週都有 3-5 件相同的客訴，即使 DPMO 看起來不高，但因為直接影響客戶滿意度，也應該考慮用 DMAIC 來根除問題。
所以重點是，別只憑感覺，用實際的數字去衡量問題的嚴重性和普遍性。
最常見的坑：一開始就想「跳 Analyze」
說實話，我看到太多工程師，一聽到要啟動 DMAIC，腦子裡就直接跳到「Analyze」階段，馬上猜測原因，然後就想去「Improve」。結果就是花了大量時間去驗證一個錯誤的假設，然後又回到原點。
舉個例，我們有個機台，產品良率一直有波動。Team leader 覺得是新進工程師操作不熟練，一直盯著他們。但實際用 DMAIC 的 Define 和 Measure 階段去收集數據後才發現，問題根本不在人，而是某個供應商提供的耗材批次不穩定。如果一開始就急著把原因歸咎給人，那只會製造更多內部矛盾，根本解決不了問題。
換句話說，不要急著找答案，而是要紮實地定義問題、量測現況。
今天能做的一件事
回去看看你手邊最「痛」的那個問題，能不能用數字明確定義它？