那天 CPK 報告出來，全場沉默了三秒
還記得好幾年前，我們廠裡有支機台的良率一直卡關，怎麼調就是上不去。那時候，產線每天抱怨，PM 追著你問進度，壓力大到爆。好不容易組了一個專案，大家信心滿滿地說要用 DMAIC 搞定它。結果呢？搞了兩個月，CPK 從 1.08 變成 1.05，DPMO 甚至還多了一點，從 6210 變成 6300。報告出來那天，會議室裡真的沉默了三秒，空氣凝結到我都能聽到自己心跳聲。到底哪裡出了問題？DMAIC 明明是個好工具，為什麼很多專案最後都像無頭蒼蠅，收不了尾？
問題出在哪？
說穿了，很多時候我們把 DMAIC 當成一個「流程」在跑，而不是把它當成一個「解決問題的思維」。你 Define 完目標，Measure 完數據，Analyze 完原因，Improve 完對策，最後 Control 住成果，聽起來很合理，對吧？但實際上，這五個步驟環環相扣，如果其中一步沒搞清楚，後面就很容易走偏。最常見的問題就是，大家 Define 了「目標」，卻沒 Define 清楚「問題」。
所以重點是：你必須非常清楚，你到底要解決什麼「具體」的問題。
實際上怎麼做？
要釐清「問題」，我通常會拉一個魚骨圖，但不是亂拉一通，而是專注在「結果」上。舉個例子，如果你的良率低，不要只寫「良率低」，這太模糊了。你要寫：「某製程的良率，近三個月平均比目標值低 5%，其中 Wafer 邊緣的 Defect 數量佔總 Defect 的 70%。」這樣才夠具體。
接著，在 Measure 階段，你要量化這些「問題」。例如，我們前面提到的那個案例，當時大家只知道「良率不好」，但沒有真正去量化 Defect 的分佈、位置、種類。我們後來重新量測，發現雖然總 Defect 數量沒變，但原本以為的「隨機 Defect」其實有高達 85% 都集中在 Wafer 的特定象限。
換句話說：你必須用數據把問題描繪得清清楚楚，而且這個數據要能指向問題的「根源」。
最常見的坑
坦白講，我踩過最大的坑，就是 Define 階段沒有花足夠的時間，或是被老闆的「目標」牽著鼻子走。老闆說：「把良率拉到 99%！」你就 Define 說要「提升良率到 99%」。結果呢？你很努力地 Measure、Analyze，發現一大堆可能的原因，但因為目標太泛，你不知道該從何下手。
另一個常見的坑，是在 Analyze 階段，大家習慣性地把所有想得到的變數都拿來分析一遍。結果就是資料量大到嚇死人，跑出來的結果一堆 P 值不顯著，然後你就開始懷疑人生。說穿了，這是因為你沒有根據 Measure 階段的「問題」數據，去縮小分析的範圍。
所以重點是：Define 階段要花時間把問題「挖深」，Measure 階段要用數據「定位」，Analyze 階段要「聚焦」在真正有關係的變數上。
今天能做的一件事
下一個專案，Define 階段多花 30 分鐘，把問題描述得更具體！