故障分析：壞了要壞得有價值

某泰國食品包裝廠的封口機，某個早班突然停機，整條線卡住四十分鐘。操作員在交接本上只寫了一句「機器壞了，已叫修」。維修班長趕到現場，換了一個感應器，機器恢復運轉，這件事就算「處理完畢」。兩週後，同一台機器、幾乎同一個位置，又停機了——這次卡了將近一小時，因為沒人記得上次換的是哪個零件、也沒人問過「為什麼這個感應器會壞」。

這種場景在中小型工廠裡並不少見：故障被當成「意外事件」處理，修好就結案，沒有人往下追問。結果就是同樣的故障一修再修，維修人力耗在同一個坑裡，卻沒有人把這些「壞掉的經驗」變成組織的資產。

為什麼

故障記錄的目的，從來不是為了「證明我修好了」，而是為了讓下一次故障不再發生，或至少能更快被抓到。一台設備第一次故障時，通常會釋放出一些「劣化訊號」——聲音變了、溫度升高、震動變大、味道不對——只是這些訊號在正式停機之前，很少被人當一回事。等到真正停機，才有人開始追查原因，但這時候線索往往已經被「換掉的零件」一起丟進垃圾桶了。

換句話說，故障分析要解決的核心問題是：把「事後補救」變成「事前有跡可循」，把「壞了就修」變成「壞得有價值」——每一次故障都留下足夠的線索，讓組織下次能更早發現、更快處理，甚至根本不會再發生。

怎麼做

1. 先把「壞了」寫清楚：一張像樣的故障記錄表

最基本也最容易被忽略的一步，是把故障發生的來龍去脈寫下來，而不是只寫「機器壞了」。一張堪用的故障記錄表至少要包含：發生時間與停機時長、故障部位（用設備圖或零件編號指出來，不要只寫「那台機器」）、故障當下的現象描述（異音、異味、警示燈、異常數值）、當下的處置方式，以及後續是否需要根本原因分析。這張表不需要複雜的系統，一張紙本表單貼在設備旁，讓操作員和維修人員都能隨手填，就已經比什麼都沒有好很多。