FRACAS is a process that gives organizations a way to report, classify and analyze failures, as well as plan corrective reactions in response to those failures.
A failure reporting, analysis and corrective action system (FRACAS) is a process that gives organizations a way to report, classify and analyze failures, as well as plan corrective reactions in response to those failures. Software is often used to implement a FRACAS system to help manage multiple failure reports and produce a history of failure with corresponding corrective actions, so recorded information from those past failures can be analyzed.
First developed and used by the United States Department of Defense groups in 1985, a FRACAS is a closed-loop process containing the following steps:
FRACAS can be used in multiple applications like safety/risk reduction, process control and incident reporting systems. The closed-loop process is a disciplined and focused approach that detects and solves issues in the design, development and production stages. It does this through multiple fundamental tasks, including recording and capturing data and information about failures; identifying and prioritizing failures; and determining, implementing and verifying corrective actions to prevent failure recurrence.
A FRACAS also provides important information from failure analysis and corrective actions for reliability data reports. Report summaries for things like incident counts contain valuable reliability and quality data.
Implementing a FRACAS is highly customizable based on your organization's needs. In fact, there is no single FRACAS standard that is applied across the board, with many standards being industry specific. Below are guidelines and a thorough overview of an effective FRACAS and what it takes to gather the necessary information. As mentioned earlier, there are three basic steps for collecting this information:
Step 1 – Creating the failure report
FRACAS starts with the failure report — the recording of an asset's failure, issue or cause for concern with a product or process. The information in failure reports can vary widely depending on your industry, processes and compliance requirements. Creating a report might involve speaking with multiple departments within your organization to discuss things like technical support, test results from the lab, manufacturing defects, issues in the field and engineering or design.
Regardless of the type of information you're tracking within the FRACAS, it's important to remember that you need to narrow down what information you want to include in your report. This means any information deemed necessary to help determine and resolve issues as well as information for future tracking.
During the failure reporting stage of FRACAS, you should clearly define the type of information to record in the incident report. Over time, as failures flow through the closed-loop FRACAS process, more information will be collected; however, initially, as much data as possible should be gathered on the failure and how it was detected. Failure reports should collect information such as:
As noted previously, this information can vary depending on the type of data you're tracking, who is recording the information, what details are needed to resolve the issue, compliance requirements and more. Generally, FRACAS failure reports are customized to each organization's requirements.
The most important aspect of failure reporting is ensuring issues are logged in your FRACAS as they occur in real time. To do this, all team members must have access to the FRACAS and be able to properly navigate the system.
Step 2 – Analysis
After you've logged your failure report(s), it's time to conduct an analysis of the issue at hand. This phase can also be customized to fit your organization's needs and help you determine how to proceed with analyzing the issue. The analysis phase typically is done by a team lead or engineer who fully evaluates what caused the failure and then identifies a solution.
Step 3 – Corrective action
The final step in the FRACAS is resolving the issue and closing it out. At this point, you've determined the root cause of the failure and come up with a solution to correct it. Once you've implemented the corrective action, your team should verify the success of the action and close out the incident in the system. Closing out each failure is critical to ensure the closed-loop system remains intact.
The FRACAS workflow consists of multiple steps that make up the closed-loop process, which takes the initial incident report through the incident resolution. Each organization's FRACAS workflow is different based on how issues are handled internally. Workflows also evolve as needs change and lessons are learned. Below is an example of a FRACAS workflow you might see for a manufacturer.
To fix the problem, the maintenance team assigns a properly trained team member to handle machine alignment and implements a mandatory training session for all team members on how to align the machine in question. Additionally, a single-point lesson with each step in the alignment process is posted near the machine.
This is a basic example of how a FRACAS process might work in a manufacturing setting. Some manufacturers use other methodologies for implementing a FRACAS. For example, the automotive and aerospace industries typically employ what's known as the 8Ds (8 Disciplines) – an eight-step process for process improvement. These eight steps consist of establishing a team, describing the problem, repairing the problem, determining the root cause, defining corrective actions, implementing corrective actions, preventing recurrence and recognizing the team's hard work.
Since modern manufacturing companies amass a large amount of reliability data and information, FRACAS data usually is managed in a structured database to make using the data more convenient. This is known as a data-centered approach. This process-oriented method solves two problems: clearly defining complicated tasks with a lot of people and organizations involved to avoid confusion of relationships and responsibilities, and secondly, defining and regulating mandatory tasks within the management system so workers can be reminded of their obligation to do them. According to research in the Journal of Quality and Reliability Engineering, implementing FRACAS in this way is done using three phases: discovery, design and enactment.
Once you have all the necessary information, it's time to establish the rules by looking at guidelines and regulations. Finally, you need to integrate the components through documentation. After you've completed this phase, you should have the properties of a FRACAS process as shown in the table below.
|Observe failure||User||Item data, time, location, environment|
|Document failure symptoms||Testing division||Failure description and expected root cause|
|Verify failure||Testing division||Checklist|
|Isolate the suspected item||Testing division||Failure mode|
|Retest of suspected item replaced||Testing division||Test report|
|Verify the failure of the isolated item||Testing division||Repair description/verification report|
|Failure analysis||Reliability division||Analysis method and report|
|Check for similar failure history||Reliability division||Historical data|
|Determine root cause||Reliability division||Root cause identification|
|Determine and incorporate corrective action||FRB||Analysis results/action specifications|
|Verify effectiveness of the action||FRB||Effectiveness result|
|Human Work||Document-based Tasks|
|Item verification||Failure verification|
|Corrective action determination||Failure analysis|
|Corrective action incorporation||Data search|
|Effectiveness verification||Root cause analysis|
Delivering tasks to the appropriate people is essential in keeping a FRACAS process flowing. Task responsibility can be defined either in the design phase or the enactment phase. For example, an employee can be determined before the FRACAs process starts, or a supervisor can choose someone and assign them a task during the operation. Tasks should be delivered via email or through the SMS, with their progress updated in real time.
The closed-loop process of FRACAS lets you closely align your failure reporting and analysis with multiple industry standards. The choice of standard depends on industry requirements, compliance needs, company objectives, etc.
The MIL-STD-2155 FRACAS standard is the standard from which FRACAS originated. It is broad, offering general guidelines for reliability programs spanning the product life cycle. Even though this standard is military based, it's used across many industries to guide FRACAS implementation.
A FRACAS can also help you meet multiple ISO requirements, including ISO-9001 and ISO/TS16949, since it complies with the stages of the ISO standardization process:
Implementing a FRACAS gives you valuable information to help identify and correct errors or failures, past problems, defects, or process errors in a timely manner. Additional benefits include the following:
Many organizations think the only solution to preventing failures or fixing issues is adding more preventive maintenance steps. While this may be necessary at times, it's better to implement a redesign of the process. If you do add more preventive maintenance steps, make sure you run them through an FMEA process or RCM analysis so you are not incorporating non-value-added steps into the maintenance program.