FMEA系列1：編寫FMEA時的錯誤案例分析

FMEA是在產品和製造過程的設計開發中，對可能遇到的技術風險進行管理的一個非常強大的工具。AIAG的FMEA手冊根據其所建議的FMEA模板，說明了如何填寫模板中要求的每一項內容，但這些說明比較簡短，僅僅根據這些說明很難編寫出一份好的FMEA。這篇文章將結合我的工作經歷中遇到的一些案例，來說明一下編寫FMEA時應注意的問題：

1: 在識別要求時，應只包括必須滿足的要求

我曾經碰到過這樣一個案例（案例1）：在開發一個新產品的過程中，銷售團隊對新產品的結構提出了一些要求，想以此作為向客戶推銷的賣點（方案A）。但產品設計團隊根據以往的經驗，認為要實現銷售團隊期望的結構成功的幾率很低，於是在不改變產品主要功能的情況下，向銷售團隊建議了另一種結構（方案B），這個方案也得到了銷售團隊的認可。在之後的過程中，設計團隊將方案A和方案B同時進行，而最終的結果是發現方案A是可行的，所以產品的最終設計採用了方案A。在編寫這個產品開發的DFMEA時，設計團隊認為方案A是有風險的，而方案B是為了應對該風險而制定的措施，所以應將此風險和措施記錄在了DFMEA中。最終完成的DFMEA如下所示，其中，方案A被作為要求識別了出來，對現行控制O的打分為8，因為設計團隊認為有很大的可能性這個要求無法達成，方案B被記錄為建議的措施，而措施結果中，因為方案A被確定是可行的，所以將方案A記錄為採取的措施，O的打分降為了1。其它信息因為與這裡的討論無關，所以此處省略不寫（後續的案例也一樣）。

以上這個DFMEA中存在若干問題，其中最大的問題是編寫DFMEA的團隊將一個優先的方案作為了要求識別在DFMEA中。在編寫FMEA時，「要求」一欄中，只應識別該產品或過程必須滿足的要求。如果一個產品或過程有若干個設計選項，而其中一個優於其它幾個選項時，該最優選項不應識別為對該產品或過程的要求，因為優先選項也只是備選方案之一，雖然優先選項本身的實現可能存在風險，但對於產品的設計來說，任何一個備選方案的實現，都是可以接受的，所以從產品設計來看的話，優先選項無法實現並不是一個風險。所以在這個DFMEA中，方案A無須作為一個要求記錄到DFMEA中。

2. 在提出建議措施之前，應先完成風險的評估

FMEA如下圖所示包括兩個部分：前半部分，截至現行控制RPN的打分，是風險評估，即評估現有的控制措施下，失效模式存在的風險。後半部分，從建議的措施開始，是風險控制，即在現有的控制措施下，如果失效模式的風險超出可以接受的程度，應提出新的措施以控制這個風險：

在進行風險評估時，有時需要一些工作來獲得客觀的數據，以對S，O和D進行評估。這些工作需要在提出建議的措施之前完成，因為風險控制的需要取決於風險評估的結果。

下面來看一個案例2。在這個案例中，DFMEA小組在首次起草DFMEA的時候，對其中的一個失效模式，計劃採用與之前一個類似產品相同的探測措施，但DFMEA小組對於該探測措施是否也能有效識別目前開發的產品的失效模式沒有很強的信心，於是他們決定做某項試驗（一周內可以完成）來驗證這個探測措施的有效性。而試驗的最終結果確認了這個探測措施是可行的。以下是他們最終完成的DFMEA，其中現行控制中的探測措施是之前類似產品xxx的探測措施，現行控制中D的打分是8，因為DFMEA小組對這個探測措施的信心不足,建議的措施是實施試驗，以驗證該探測措施的有效性。最後因為試驗證明該探測措施是有效的，所以採取的措施還是該探測措施，但D的打分根據試驗的結果降到了2分。

以上編寫的DFMEA存在的最大的一個問題是FMEA小組把風險控制和風險評估混淆了。FMEA模板中「建議的措施」這一項是填寫為了控制風險所需要的措施，但實施試驗是為了進行有效風險評估所需要的措施，不是為了風險控制。這項工作是在討論是否需要進一步措施來控制風險之前應該完成的。如果如案例中所述，在首次起草FMEA的時候這項工作尚未完成，則在首次起草時，不應對D進行打分，而是在試驗結果出來後，再召集一次會議對D進行打分。上述的DFMEA，最終編寫後應該是如下的樣子，其中建議的措施和措施結果都應該是空白：

3. 是否需要風險控制以及如何進行風險控制的決定應與風險評估的結果一致

接下去要討論的一個案例3，跟上面提到的案例有幾分相似，在這個案例中，在起草FMEA的時候，FMEA小組同樣對現行的控制措施的有效性不是很有信心。但不同的是，這個案例中如果要對探測措施的有效性進行驗證的話，必須要用該產品製造出來後的樣品，之前無法用其它措施來驗證。另外，FMEA小組也無法在現有的資源條件下，尋找到其它可行的探測措施，於是決定採用現行的控制措施。而幸運的是，在最終樣品出來後，現行的探測措施被證明是有效的。這個完成後的FMEA如下所示，其中現行控制、建議的措施和措施結果填寫的都是相同的措施。但現行控制中D的打分比較高，因為對其沒有信心。而措施的結果中，因為事實證明探測措施是有效的，D的打分為2。

上述的FMEA中存在的一個主要問題是風險評估的結果和如何進行風險控制的決定是存在矛盾的。風險評估的結果是現行控制不夠有效，但建議的措施還是採取現行的控制措施，這有背於FMEA的目的。FMEA的目的是當發現現行控制存在風險時，能夠提出新的措施以應對這個風險。所以在這個案例中，FMEA小組如果評估的結果是現行措施不夠有效，而目前的資源無法提供其它有效的措施，則FMEA小組應向管理層提出更多的資源要求，以便能夠實施更加有效的措施。最終完成的FMEA應類似如下所示，其中建議的措施是有別於現行措施的新措施：

如果比較案例2和案例3，可能有人會問，案例3中對現行措施D的打分是不是應該等樣品出來後有了客觀證據確認探測措施是否有效再進行打分。答案是不應該。在案例2中，確認探測措施有效性的試驗只需一周時間，而案例3中，必須等到樣品出來後才可以確認。這個已經在設計開發非常後面的階段了，如果這個時候得到證據說探測措施不有效，而需要再去考慮新的探測措施時，則可能引起整個項目計劃的改變，例如項目延期或經費增加。所以案例中的風險評估不得不在沒有客觀證據的情況下完成，基於FMEA小組的經驗和知識給出一個最好的猜測。但是即便這個風險評估是基於猜測的，在考慮如何進行風險控制時，還是必須跟風險評估的結果一致。這個案例中，最終現行探測被驗證是有效的，表明FMEA小組進行風險評估的時候存在不準確，但如果基於小組的風險評估卻不要求更多的資源以採取新的探測措施，則表明FMEA小組在使用FMEA這個工具時存在誤解。

4. 潛在失效根源指的是失效模式的產生原因(Cause of Occurence)，而不是流出原因(Cause of Escape)

在接下來要討論的案例4中，整個產品開發的團隊根據不同的責任，分成了若干個小組，其中設計小組負責產品的設計，驗證小組負責對設計小組的設計方案進行驗證，如果發現產品設計中存在不能滿足預期要求的地方則反饋給設計小組以糾正存在的問題。在編寫這個產品的DFMEA的時候，FMEA小組在識別了設計小組可能造成的失效模式的同時，也認為如果驗證小組在產品驗證過程中存在問題（例如驗證方法錯誤）從而不能識別產品設計中的缺陷的話，也將最終導致設計出來的產品可能存在失效模式。因此，在編寫DFMEA的過程中，FMEA小組在潛在失效根源這一項中，既包括了由設計小組造成的原因，也包括由驗證小組造成的原因。其中一個失效模式（產品跌落後開裂）如下所示。針對這個失效模式，跌落試驗是對產品設計進行驗證的手段，作為現行控制的探測措施記錄在其中。同時，跌落試驗中可能存在的問題（未能模擬產品掉落時候的最大衝擊力），又被作為潛在失效根源記錄了下來。

上述這個FMEA中存在的錯誤是FMEA小組將失效模式的流出根源記作了潛在失效根源。在編寫FMEA時，識別潛在失效根源的時候，應只識別失效模式的產生原因，而不應包括流出原因。這一點AIAG的手冊中有提到，其中的內容截圖如下：

5. FMEA應針對技術風險

在設計開發過程中使用FMEA這個工具，雖然在AIAG的FMEA手冊中並未特別明確的提到，但通常都將其局限於技術上的風險，而不是管理上的風險。那麼什麼樣的風險是技術上的風險呢？這個可包括三個方面：

1) FMEA中識別的失效模式是產品規格和性能方面的失效，而不是項目進度、成本控制等方面的問題。

2) 失效模式產生的根源應該是技術上的（物理或化學的）根源，例如材料強度不夠、鍍層緻密性差等等，而不是管理上的根源，例如文件錯誤、溝通不暢、數據丟失、資源不到位等等。

3)應對失效模式的措施（現行控制或建議措施）應該是技術上的（物理或化學的）方案，例如採用強度更高的材料、提高鍍層緻密性等，而不是管理上的根源，例如及時更新文件、定期舉行會議確保溝通、數據備份等等。

在我的工作經歷中看到的FMEA，通常都能滿足上述第一點，但往往在討論產生根源和應對措施時，會把管理上的問題也混淆進來。所以這裡需要強調一下：

-- FMEA中潛在失效根源這一項，應只識別技術上的根源，而不應包括管理上的根源。

-- FMEA中現行控制和建議的措施這兩項，應只是技術上的解決方案，而不是管理上的解決方案