FRACAS

出自 MBA智库百科(https://wiki.mbalib.com/)

FRACAS（Failure Report Analysis and Corrective Action System，故障報告、分析和糾正措施系統）—— FRACAS通常也稱為“故障信息閉環管理系統”，FRACAS還有稱為，如“歸零管理”、“PRACAS”、“DRACAS”等。

　　由世界著名的可靠性公司一一美國RELEX公司推出的FRACAS(故障報告、分析和糾正措施，Failure Report Analysis and Corrective Action System，縮寫為FRACAS)專業系統軟體，通過報告產品的故障，分析故障原因，制定和實施有效的糾正措施，以防止故障的再現，同時把故障根本原因和糾正措施信息反饋到設計過程中，改善和促進產品的可靠性增長。

　　1980年頒佈的美軍標MIL-STD-785B (《系統和設備研製生產的可靠性大綱 要求軍用系統承包商建立FRACAS，以有效地開展、監督和控制研製過程中的故障報告、分析和糾正活動。為使這一工作更加規範化，1985年美國國防部又頒發了軍用標準MIL—STD．2155(AS)《失效報告、分析和糾正措施系統》，對故障報告、分析和糾正活動規定了統一的要求和準則。我國早在1986年由原國防科工委頒佈的《軍工產品質量管理條例》中，就提出了承製單位應當制定質量、可靠性信息的收集、傳遞、處理、貯存和使用的管理辦法，並同使用單位建立質量信息反饋網路、故障報告制度和採取糾正措施制度。之後，為滿足在我國軍工領域推行可靠性工程的需要，參照美軍標先後於1988年頒佈了國軍標GJB450．88《裝備研製和生產的可靠性通用大綱 ，1990年頒佈了GJB841-90《故障報告、分析和糾正措施系統》，明確要求承製單位在軍工產品的研製和生產階段建立FRACAS，並規定了該系統建立及運行的程式、方法和要求。

　　按GJB450要求,研製、生產單位要建立一個閉環故障報告系統。該系統包括:

　　(1)對故障進行報告和分析的程式;

　　(2)將糾正措施反饋到設計、生產、試驗過程中去的程式;

　　(3)跟蹤、評審故障分析及糾正措施狀況的制度;

　　(4)有關故障的文件記錄的規定。

　　GJB841為如何實現GJB450上述要求提供了指導。

　　由於產品研製涉及許多外購、外協產品,因此,對於協作配套產品的故障信息應納入主承製單位的信息收集系統,以利於跟蹤故障。同時要把有關故障信息納入相應的故障文件內。對於產品使用過程中的故障信息,也應疏通渠道,及時加以收集,以利於改進產品。

　　對於像航天系統這樣複雜、昂貴、重要的產品,為使故障報告、分析和糾正措施的各項活動得到控制,設立一個故障審查組織是非常必要的。其目的在於控制FRACAS的運行並增加管理的透明度。圖1表示了故障報告閉環系統工作流程及其與故障審查組織的關係。

　　目前一些單位建立了信息系統,應當把FRACAS作為本單位信息系統的組成部分,並根據FRACAS要求來完善現有的信息系統。

　　對所有故障、故障原因的調查和分析、採取的糾正措施及效果以及故障評審活動等均應記錄並保存,將這些記錄編製成為有統一編號的故障文件,以便於檢索、查閱。它也為信息交換提供了基礎。

　　FRACAS應在研製階段的早期就建立並運行。這是由於在研製的初期,允許設計作較大的更改來解決故障問題。而等到研製後期,雖然仍可提出糾正措施,但受到很大的約束,付諸實現就很困難。

　　GJB450-88和GJB841—90中規定，“建立FRACAS的目的是要及時報告產品的故障，分析故障原因，制定和實施有效的糾正措施，以防止故障再現，改善其可靠性和維修性”。

　　“FRACAS應由承製方(包括轉承製方)儘早建立，併在訂購(使用)方的協同下加以實現。該系統應保證對合同規定層次的產品在研製階段和生產階段所發生的故障及時報告、分析和糾正”。從上述要求可以看出建立FRACAS的目的，是為了對產品在研製和生產階段所發生的故障進行嚴格的“歸零”管理，做到及時報告、查清原因、正確糾正，防止再現，從而實現產品可靠性增長，以保證達到對產品可靠性和維修性的要求。可見，FRACAS的建立與運行是開展可靠性工程活動的重要組成部分。可靠性工程的主要任務就在於糾正己發生的故障，防止故障的發生，控制和減少故障發生的概率。而FRACAS正是利用“信息反饋、閉環控制”的原理，並通過一套規範化的管理程式，使分散髮生的產品故障，得到及時的解決，並防止故障的重覆發生。建立FRACAS是實現產品可靠性增長、提高產品質量的重要手段。它既有糾正己有故障的現實意義，又能對未來新品發生類似的故障起到積極預防的作用。通過FRACAS的運行， 可以積累大量處理故障的實踐經驗，對類似產品的改進與設計提供可供參考的信息，起到舉一反三，防止其他產品出現類似問題的作用。FRACAS的建立與運行主要適用於產品的研製階段和產品的早期使用階段，因為在研製階段採取糾正措施方案的選擇靈活性最大，最易於實施，效果也最為明顯。

　　Relex FRACAS系統不僅是一個強大的可靠性軟體，還是一個質量追蹤和管理系統，實施和應用FRACAS技術將能為企業成功實現6σ、ISO9000、AS9000、QS9000和TL9000等質量目標提供保障。同時，FRACAS系統也能幫助企業提升ERP、PDM、SCM和CRM 的投資價值。

　　FRACAS與流行的8D管理思想相同， 主要針對實際發生的故障信息進行閉環管理，FRACAS是構建可靠性工程平臺的基礎。Relex FRACAS系統基於區域網和Web技術，將產品的可靠性數據積存到資料庫中，通過完整的閉環管理流程對各種信息進行過濾、統計、分析和計算，同時對可靠度、可用度、失效率、MTBF等進行計算，進行可靠性增長和費用的分析。系統可為不同規模的企業進行定製，為每一位使用者量身定做各種界面、流程、計算、圖形、報表、報警等內容。

　　故障信息傳遞和故障件處理的流程圖見圖：

　　圖：故障信息傳遞和故障件處理流程

　　一、故障報告

　　(1)故障報告的範圍

　　軍工產品在研製過程中發生的所有故障和重大質量問題等(以下簡稱為故障)都應及時記錄，並填寫故障報告表。

　　(2)故障報告的內容

　　故障報告的內容應能完整、真實地反映故障發生時的一切情況，一般包括：

　　a．產品發生故障的時間、地點及何種試驗；

　　b．發生故障時產品所處的工作狀態及環境條件等；

　　c．故障產品的詳細描述；

　　d．故障現象和特征的詳細描述；

　　e．故障的觀測者及觀測故障時的環境條件

　　(3)故障報告的要求

　　故障報告一般應滿足如下要求：

　　a．各產品研製單位應根據實際情況，制定統一的故障報告的表格，以便對故障報告進行傳遞、統計處理和儲存(推薦使用G．IB841—90所列各表)；

　　b．產品的故障報告應按不同的層次(如總體、系統、設備、部組件等)和故障的嚴重等級規定故障報告應報告到哪一級；

　　c．故障報告應規定報告的時限，如重大故障應在多少小時內報到最高管理級，一般故障應在多少小時內報告到規定的管理級等；

　　d．供方在產品研製過程中出現的一般故障由各單位自行處理，但應經常與總體單位保持聯繫，通報故障的處理情況。

　　(4)故障的核實

　　有關職能部門接到故障報告後，應根據故障等級和故障報告的詳細程度，對故障情況進行調查，對故障報告的準確性進行核實。一般應做以下工作：

　　a．重新證實初次觀測故障的真實性，進一步錄取故障信息；

　　b．查找故障的部位，一直到最低一級可更換的故障件；

　　c．用相同合格件更換、代替故障件後，重新進行測試和試驗，以確定故障是否被糾正；

　　d．對更換下來的故障件進行測試，以核實該可疑故障件是否確有故障，初步確定故障的範圍；

　　e．對於不可重覆試驗的故障件，可以通過對故障影響和後果(如泄露、斷裂、損壞等)的詳細觀察來證實。

　　二、故障分析

　　故障分析是由故障現象、後果去查明故障的原因和故障機理的過程，追查故障原因，應一直查出根本原因，並能構造出反映故障因果邏輯關係的故障鏈，確定造成故障的責任方。對於特別重大故障應成立故障分析工作組，負責故障的調查、分析工作，給出分析結論，完成故障分析報告，提出改進措施的建議。故障分析工作組組長一般由與該故障無直接責任關係的專家擔任；故障分析工作組成員應由各方面、各專業的代表組成。

　　(1)故障分析的步驟

　　對故障進行分析的一般步驟為：

　　a．分析有關產品及其故障的資料(如產品的設計資料、試驗程式、FMEA報告、故障報告等)；

　　b．分析故障產品的全部工作歷史和故障歷史；

　　c．分析可能導致產品發生故障的外部因素(如試驗測試設備、測試方法、操作環境及人為因素等)；

　　d．對故障件進行檢查或測試；

　　e．提出故障原因和故障機理的假設，並用試驗或理論分析的方法進行驗證；

　　f.根據試驗或理論分析的結果，給出故障分析結論，完成故障分析報告；

　　g．提出糾正措施建議；

　　h．整理各種資料、工作記錄、試驗數據，編成檔案及時歸檔。

　　(2)故障分析的方法

　　對報告的故障進行徹底的分析，以確定故障的根本原因。故障分析的方法一般分為以下3種：

　　a．工程分析

　　根據工程原理和工程經驗，對故障產生的原因和機理進行分析，可以通過理論分析計算、故障模擬試驗或對故障件進行分解等方法。應充分利用FMECA分析結果提供的信息，運用故障樹分析方法來幫助查明故障模式和原因之間的邏輯關係。

　　b．失效機理分析

　　利用觀察、測試、理化分析、解剖、X光檢查、電子掃描顯微鏡觀測等方法，去研究物質結構、工藝過程可能產生的缺陷，分析導致這種缺陷的機理和過程。該方法主要適用於元器件、零部件和材料等硬體。

　　c．統計分析

　　通過對故障產品累計工作時間、次數和出故障次數，對該故障模式在類似產品出現的次數加以系統的整理，以估計該故障模式的性質和出現的概率。

　　(3)對故障分析的要求

　　無論採用上述哪一種故障分析方法，其分析的結果都應能判明以下問題：

　　a．該故障是相關故障，還是非相關故障?以便估計產品在未來使用環境中是否會發生類似的故障；

　　b．該故障是責任故障還是非責任故障?以便在估計產品可靠性時考慮是否記入該故障，同時也利於分清故障產品是故障源還是受害者；

　　c．確定引起故障的責任方面，如是設計、製造的原因，還是元器件、原材料、外購件的缺陷；是設備的問題還是人為操作的錯誤，或是其他未查明的原因等；

　　d．該故障是初次發現，還是類似產品中早已出現過的故障；

　　e．該故障是需要糾正的系統性問題引起的，還是偶然性問題引起的，如果是偶然性故障，它出現的概率是多少?是否需要糾正。

　　(4)故障分析報告

　　一般故障的分析報告可參照故障分析報告表，完成對故障的分析和擬採取糾正措施的建議。

　　重大故障應由相關職能部門或故障分析工作組完成故障分析報告。

　　故障分析報告是對整個故障分析處理過程的總結，是確定和實施糾正措施的依據。重大故障的分析結論應由有關方面組織評審，確認後方可提出糾正措施的建議。

　　故障分析報告一般包括以下內容：

　　a、對產品工作的歷史和對故障件的故障現象、特征的描述；

　　b．故障調查和分析過程；

　　C．故障原因和機理的分析、論證；

　　d．建議的糾正措施和需說明的問題建議等。

　　如故障原因一時難以查清，應在故障分析報告中，說明理由，經故障審查委員會主任或主管技術的領導批准後，可暫時結束故障分析工作；如已查明故障原因，但未採取糾正措施的故障，也應編寫故障分析總結報告。報告中應申述不採取或無法採取糾正措施的理由，經審批後可暫時結束故障分析工作。

　　在產品定型前，對上述暫時結束的故障分析報告工作應重新組織審查，才能最後結案。故障分析報告必須按規定的程式進行會簽和審批。

　　(5)故障件的管理

　　對所有的故障件應做明顯的標識，以便於識別和控制，確保按要求進行處置。為了便於對故障的調查和分析，在完成故障分析之後到糾正措施實施之前，應對現場加以保護，對故障件要妥善保管，不應隨意處理。故障調查和分析完成後，對於典型的、重要的故障產品也應妥善管理。

　　三、故障糾正

　　對於已查明原因的故障，責任單位的有關部門應依據對故障分析的結論制定糾正措施，防止故障的再發生。故障的糾正按以下程式進行：

　　(1)糾正措施的確認

　　糾正措施必須通過試驗來驗證其有效性。同時應分析糾正措施實施的可行性，是否會帶來新的故障模式或附加的不可靠性。所以在對提出的重大故障或質量問題糾正措施正式批准前，應組織有關專家和部門的代表對糾正措施進行評審，經故障審查委員會批准後實施，以確保糾正措施的有效性、可行性，並與其它相關部分介面相協調。

　　(2)故障糾正措施的報告

　　故障單位的有關部門在進行故障分析和制定糾正措施後，應及時按規定的要求準確、規範的填寫糾正措施實施報告表；在特殊情況下，如查不出故障原因或不能採取糾正措施，應在表中說明原因，做為遺留問題備查；對於早期使用中發生的偶然性非重大故障或質量問題可暫不填寫此表。

　　表中故障審查組織意見欄，對於重大故障或質量問題，由該組織的故障審查委員會填寫；一般故障由該故障單位的質量管理部門負責人填寫，做為對故障及其糾正措施的確認，併發給有關部門貫徹實施。

　　(3)糾正措施的實施

　　批准的糾正措施反饋到設計、生產、試驗過程中，要通過技術狀態管理系統完成相應的文件和產品的更改。

　　對於可能出現相同的故障模式的類似產品，應本著“舉一反三” 的原則，研究是否需要採取措施；

　　對於與故障有關聯的其它可疑產品，應進行必要的分析或試驗，證明其可靠性並未降低，壽命未受損。

　　故障審查委員會辦公室負責跟蹤檢查糾正措施的落實情況。

　　(4)糾正措施效果的驗證

　　對於已採取糾正措施的故障產品，有關部門應通過試驗、試用等方法，驗證糾正措施的有效性，如達不到預期的效果，則需進一步分析故障的原因或採取其它的糾正措施，直到故障得到徹底解決。最後將糾正措施納入有關技術文件，並落實到所有產品上。

　　(5)管理改進

　　通過分析產品的故障原因，還應進一步從管理上、質量管理體系上等多方面人手查找需要解決的問題，以進一步完善制度，改善體系，促進產品質量和可靠性的不斷提高。

　　步驟一：制定目標和成功要素

　　制定適當初級目標是成功實施FRACAS的基礎。項目組中的負責不同工作的成員都必須明確自己在FRACAS實施過程中的具體目標。具體目標包括降低維修成本、提高整體可靠性，改進下一代產品設計。目標一旦制定，各小組的代表和執行人應召開專門的會議針對這些目標進行評價、調整，並賦予這些目標一定的優先權。

　　同時在會議期間，應針對上述已經制定的各個目標確定出實際、可量化的成功要素。例如：如果目標是降低維修成本，那麼量化的成功要素就是將隨後12個月的維修成本降低10%。目標和成功要素確認後，必須將具體內容和細則下發到FRACAS小組的所有成員。

　　步驟二：定義輸出

　　依照目標，各小組必須確定FRACAS所需要的輸出，從而評估是否能實現分配給他們的成功要素。通常情況下，輸出可以是計算結果、圖、表，或報告等。為了方便對輸出的管理，每個輸出都應該和目標和成功要素相對應。

　　步驟三：繪製過程/工作流程

　　通過與使用者的一系列走訪和會談，確定各小組的工作流程，繪製統一的流程圖，這個流程圖最好能簡化整個FRACAS過程，以便及時生成所需的輸出。過多的步驟會給實施過程帶來消極影響，因此必須將工作流程減到最簡，從而降低實施過程的複雜度。

　　步驟四：設置數據限制和輸入方法

　　利用輸出要求和統一的流程圖，確定設置數據限制。目的是過濾那些重要數據，減少對無用數據的收集。數據限制確定後，接下來是如何收集這些數據，故障報告人員通過什麼形式來報告。收集方法包括早期的手工填寫、從選擇表中挑選、直接數據輸入或是電腦條碼的錄入。同時必須制定數據輸入規則（例如：故障信息的那些數據必須要求輸入）以及如何保證數據的準確性和一致性。

　　步驟五：實施FRACAS基本原型

　　上述四個步驟即實施FRACAS的前期準備工作，完成之後可以開始實施基本原型。目前實施FRACAS的工具有三個層次：Excel或者Access等通用工具或者自開發的實施工具滿足基本需要，缺點是無法滿足多用戶共同使用，數據處理能力有限，數據安全性差。

　　部門級的應用工具，能包括基本的FRACAS功能，適合用戶較少的部門應用。

　　企業級應用工具（例如後面介紹的RelexFRACAS等專業軟體工具），提供全部FRACAS功能，支持大規模數據和多用戶，採用WEB技術，與企業信息化管理軟體（ERP、PDM等）有介面，便於實現數據的共用與傳遞。

　　項目組根據當前的實際情況採用不同的應用工具來實施FRACAS。

　　步驟六：接受反饋和修改FRACAS

　　FRACAS基本原型建立好之後，讓使用者參與進來，確定其輸出是否能夠達到預定的目標要求，是否滿足成功要素。同時尋找需要改進的工作區域，通過收集建設性的反饋意見，來進行適當的修改。在進行系統演示前,要得到小組代表和執行人或負責人的認同和支持。

　　步驟七：演示和培訓

　　確定是將系統立即展示給所有使用者，還是採用逐步推開的方式。如果時間充裕，那麼逐步推進的方式會更好一些。

　　在培訓過程中，擔當不同角色的使用者可能出現不同的問題，我們可以對這些暴露出來的問題進行有針對性的解決，從中總結經驗。

　　步驟八：持續改進

　　根據使用者的反饋，對FRACAS進行持續的改進。如果商業目標和流程發生了變化，那麼也需要對FRACAS做適當的修改。在這個過程中有一點需要註意，即要保證所有改動並不違背最初制定的整體目標。

　　採用專業的應用工具可幫助實施者建立科學嚴謹的閉環流程，下麵介紹美國RELEX公司推出的Relex FRACAS系統。

• 通過FRACAS的成功運行，能夠建立比較完善的產品零部件的故障信息和可靠性信息資料庫，利用該資料庫，可以為本型產品的可靠性改進和後續產品的可靠性設計提供數據基礎；

• 通過FRACAS的成功運行，能夠得到產品整機及其組成成件的可靠性評價參數值，以此作為制定備件支持和維修保障策略的重要參考；

• 通過FRACAS可以建立以可靠性為中心的故障信息管理和控制系統。