FRACAS: An Overview

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.

 

What Is FRACAS?

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:

1. Failure reporting (FR): All failures and faults related to a system, piece of equipment or process are formally reported using a standard form known as a failure report or defect report. The failure report should clearly identify the failed asset, symptoms of the failure, testing conditions, operating conditions and failure time.
2. Analysis (A): Perform a root cause analysis to identify what caused the failure. Perform a root cause analysis to identify what caused the failure.
3. Corrective actions (CA): Once the cause of the failure is determined, implement and verify corrective (or preventive) actions to prevent future occurrences of the failure. Any changes should be formally documented to ensure standardization.

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.

FRACAS are now widely digital and, in addition to failure reporting, analysis and correction, can work in tandem with multiple processes and tools such as DMAIC, MTBF and MTTR.

 

How to Implement FRACAS

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:

• Date and time of the incident
• Who found the issue or failure
• Who is conducting the incident report
• All details about the incident, including the steps that led to the incident
• Any corrective action that was done to fix the issue
• Suggestions for changes that could be implemented to prevent recurrence

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

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.

• Step 1 – Entry: A failure is detected and entered into the FRACAS. In this case, a bearing has seized.
• Step 2 – Assign: The team lead assigns the issue to a member of the maintenance team to investigate. The maintenance department determines the bearing is fatigued due to misalignment.
• Step 3 – Fix: The maintenance team looks into the work history of the machine and discovers previous instances of improper assembly, which resulted in soft foot, misalignment and loose connections. Through root cause analysis, the maintenance team determines the current bearing defect was the result of shaft misalignment, which was caused by deficiencies in the maintenance team's skills due to improper training.

  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.

• Step 4 – Verify: The maintenance supervisor restarts the machine to check for any alignment issues through vibration analysis.
• Step 5 – Closeout: If the machine is running properly, the failure is closed out in the FRACAS.

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.

 

The Phases of Implementing FRACAS

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.

• Discovery Phase: The first step in the discovery phase is defining each task and identifying who will take ownership of the task. Next, process flows should be determined. This means setting procedures, the approval process and the decision-making processes. Then, other information should be defined, including failure modes, failure mechanisms, product specifications, reliability information and historical data.

  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.

  Task	Ownership	Information
  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

• Design Phase: The design phase is where you standardize your process. In modern organizations, this is done using software to make the FRACAS process easy for a large number of employees to use across the organization. Activities in this phase are broken into two types of activities: human work and document-based tasks. Tasks that deal with things like failure observation, verification and failure analysis are types of document-based tasks. Essentially, these are the reports used for analysis. Human work includes things like incorporating corrective action.

  Human Work	Document-based Tasks
  Isolation	Failure observation
  Retest	Documentation
  Item verification	Failure verification
  Corrective action determination	Failure analysis
  Corrective action incorporation	Data search
  Effectiveness verification	Root cause analysis
  Performance testing

• Enactment Phase: As the name suggests, the enactment phase is where the FRACAS process is actually implemented and executed. Participants in the FRACAS process are given their own tasks via email, mobile device, etc. Once they complete their tasks, they report to the system via the same method.

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.

 

FRACAS Compliance

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:

• Proposal stage: Once a problem is diagnosed, the team members who identify the problem should draft a proposal detailing the magnitude of the issue.
• Preparatory stage: Immediate actions are taken to prepare for the steps that will allow you to stop the issue.
• Committee stage: Employees should be assigned roles according to their skillsets, and tasks should be delegated accordingly.
• Inquiry stage: By looking into questions raised and drawing conclusions about the reported issue(s), team members work together to determine the root cause of the problem and figure out a solution.
• Approval stage: Authorized employees should green-light solutions and appropriate actions as they see fit and close out the issue.
• Publication stage: The final FRACAS report can be closed out and archived for future review and consideration.

 

Benefits of Implementing FRACAS

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:

• Through proper investigation of failures and appropriate corrective action, a FRACAS also directly reduces immediate costs like factory rework and parts/materials scrap, as well as indirect costs like customer dissatisfaction.
• A FRACAS tends to be a contributing factor to reliability growth, continuous process improvement and an efficient maintenance program. This is done via continuous monitoring and data tracking through the FRACAS, which provides a summarized assessment of whether previous failure trends have been eliminated by corrective action.
• FRACAS offers visibility of reliability performance issues and initiates continuous improvement processes.
• Through root cause analysis, FRACAS helps expedite engineering efforts to fix issues, which in turn leads to effective corrective actions.
• FRACAS provides an organization with a knowledge base of a history of problems, giving you a precedent for numerous issues to help you avoid them in the future.

 

Bottom Line

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.