那天機台又掛了，良率掉到讓人心驚膽跳
記得有一次，產線的某台關鍵設備又莫名其妙掛了，這次影響超大。當時我們正在趕一批急單，結果機台一停，後面一堆製程全部卡住。良率報告一出來，直接從平常的 99% 掉到 95% 以下，Cpk 也從 1.3 掉到 1.08，全場氣氛瞬間凝結。老闆臉色鐵青地問：「到底為什麼？到底哪個環節出問題？」你說，這時候要怎麼辦？難不成要叫大家土法煉鋼，一個一個零件去拆、一個一個參數去調嗎？當然不是，這時候就是我們這些老工程師，拿出故障樹分析（Fault Tree Analysis, FTA）的時候了。
問題出在哪，說穿了就是「逆向思考」
說實話，故障樹分析聽起來很學術，但其實它就是一種「逆向思考」的邏輯工具。當一個「不好的事件」發生時（例如：機台當機、良率暴跌），我們要做的，就是像偵探一樣，一步一步往回推，找出所有可能導致這個事件發生的原因。它會把這些原因用布林邏輯（AND, OR 閘）連接起來，畫成一棵樹狀圖。
換句話說，你不是在想「我做了什麼會成功」，而是在想「發生了什麼糟糕的事，會導致這個失敗」。它把複雜的問題，拆解成一個個獨立且可分析的元件，讓你一眼看清楚整個系統的「脆弱點」在哪裡。
實際上怎麼做？用邏輯閘把問題攤開來
我們通常會這樣畫故障樹：
- 定義頂部事件 (Top Event)：這是你最不想看到的結果。例如：「機台 A 無預警停機」。
- 找出直接原因 (Direct Causes)：哪些事情發生，會「直接」導致頂部事件？假設機台 A 停機，可能是「電源供應器故障」或「主控板當機」或「軟體程式崩潰」。這裡就是用 OR 閘連接。
- 繼續往下分解 (Decomposition)：針對每個直接原因，再問「是什麼導致這個原因發生？」
* 如果「主控板當機」，可能是「晶片過熱」或「韌體缺陷」。
- 持續分解直到基本事件 (Basic Events)：直到你找到那些不能再往下細分、可以直接量測或更換的「基本事件」為止。例如「保險絲燒斷」本身就是一個基本事件。
我們曾經用 FTA 分析過一個 DPMO 高達 6210 的製程缺陷，發現最後歸結到三個基本事件：供應商提供的某批次原料純度不穩、機台清潔頻率不足、以及操作員未確實執行 SOP。當你把這些根本原因列出來，每個原因發生的機率也估算出來，就能算出頂部事件發生的機率，知道哪個環節最需要優先處理。
最常見的坑：想太多跟想太少
我在用 FTA 的過程中，看過很多人踩坑。
- 坑一：想太少，分解不夠徹底。有時候大家只分解到第二層就停了，覺得「喔，是軟體問題」。但軟體問題底下還有很多可能性，是記憶體溢出？還是邏輯錯誤？不挖到最底層的基本事件，你就無法真正解決問題，只是治標不治本。上次一個新人分析機台掛掉，只寫了「感測器異常」，但沒去追是感測器本身壞、還是線路鬆脫、還是參數設定錯誤，結果花了一天白忙。
- 坑二：想太多，把所有可能性都畫進去。有時候為了求全，把一些機率極低、幾乎不可能發生的事件也畫上去，導致故障樹變得無比巨大、難以閱讀，反而失去分析的效率。坦白講，時間就是金錢，找出高機率的關鍵點才是王道。
所以重點是，要抓好一個平衡點，分解到足以讓你採取實際行動的層次就好。
今天能做的一件事
選一個你最近遇到的問題，試著用 FTA 的思維，畫出它的故障樹雛形。