Jump to: 1. What does FRACAS stand for? | 2. How is FRACAS pronounced? | 3. What is FRACAS? | 4. How do I perform FRACAS? | Step 1: Failure Reporting | Step 2: Analysis | Step 3: Corrective Action | 5. What is CAPA (Corrective and Preventive Action) and how does it relate to FRACAS? | 6. What are the FRACAS and CAPA standards? | 7. When should FRACAS be used? | 8. How is FRACAS used in different industries? | 9. Why should FRACAS be performed? | 10. What are the benefits of using a FRACAS software tool?

1. What does FRACAS stand for?

FRACAS is an acronym for “Failure Reporting, Analysis, and Corrective Action System.”

The term FRACAS has its roots in a Department of Defense standard published in 1985 that defined the FRACAS process, MIL-STD-2155. Therefore, FRACAS is a term widely used and recognized in industries related to military, defense, aerospace, etc. However, due to its long history and wide acceptance, FRACAS is used throughout many commercial industries as well.

2. How is FRACAS pronounced?

Well, clearly no one wants to say “Failure Reporting, Analysis, and Corrective Action System” every time they want to refer to this process! And, actually, the term FRACAS is so well known and accepted in many industry sectors, that its lengthy title may not even be recognized.

In general, FRACAS is pronounced as “frah’-kus.” A second pronunciation also heard is “frey’-kus.” And, lastly, mainly in Europe, “frak’-ah” may be heard.

Confusion does result from the other meaning of the word “fracas.” Fracas is a synonym for the word “argument” or “quarrel,” and, in fact, Googling “FRACAS” often returns results all related to a brawl!

Watch and listen to the video on the various ways to pronounce FRACAS. In the reliability and quality field, the first pronunciation is used.

3. What is FRACAS?

FRACAS is a closed-loop management system to organize, track, and manage your process for handling and resolving problems or issues. The process begins with problem report and identification, progresses through identifying a corrective action, and finally concludes with implementing the corrective action to resolve the issue. Product-centered companies, large to small, engage in some type of closed-loop corrective action (CLCA) process. It may be formal or not, tightly controlled or loosely developed, but it exists in some manner.

4. How do I perform FRACAS?

The steps in a FRACAS, as noted by its acronym, include:

• Failure Reporting: a failure occurrence is logged in some manner.
• Analysis: the failure is analyzed to determine the cause.
• Corrective Action: the steps necessary to correct, prevent, or mitigate the failure in the future are identified, implemented, and verified.

The core of FRACAS is the step-by-step process of problem identification to problem resolution. If any step of the process is not completed – a problem is not recorded, a corrective action is not identified, a corrective action is not implemented – the loop is broken. Far too often, experiences with broken loops lead organizations to implement a controlled, trackable closed-loop system. Over time, most companies realize the necessity of implementing a system to effectively manage the handling of reported issues. While the processes established vary tremendously, most corporations have settled on some type of software system to track and manage issues as they arise.

Delving into the steps of a FRACAS

Step 1: Failure Reporting

Creating the failure report

FRACAS begins with the failure report, or incident report, which essentially is the recording of a failure, issue, or concern that has arisen with your product, process, or system. FRACAS failure reports vary broadly depending on industries, organizational processes, compliance requirements, and company preferences. Issues may involve any number of concerns, from calls to technical support, test results, manufacturing defects, field failures, engineering design request, and even sales related matters.

Some examples of FRACAS incident reports include:

• Failures that occur during product testing
• Non-compliance reports
• Software bugs
• Customer complaints
• Product failure reports
• Manufacturing process improvement requests

Determine the data you want to collect and track

No matter what type of incidents you are tracking in FRACAS, you must determine what data you want to include in your incident reports. Generally, you want to include any information pertinent to helping to resolve the issue and for any future tracking you would like to do.

At the failure reporting stage of FRACAS, you want to define the information that the person initiating the incident report should log. As the incident flows through the FRACAS process, more data will be entered over time. But at this point of initial entry, the data captured should attempt to gather as much information as possible about the failure and how it was found.

Some examples of information you could consider including in your incident report:

• The date and time of the incident report
• The name of the person who found the issue
• The name of the person generating the incident report
• As many details as possible about the incident, such as steps that led to the incident
• What was done to correct the issue when found, if anything
• Potential suggestions for changes that could be made to prevent the issue in the future

As noted, the information gathered for an incident report varies depending on a wide variety of factors: what type of data you are tracking, who is recording the incident, what details are needed for problem resolution, compliance requirements, internal requirements, and more. This is why FRACAS incident reports are typically customized to each organization’s unique requirements. In many cases, software FRACAS tools supply templates that provide a solid starting point for tailoring an incident report to your needs.

Enter information on incidents in real time

As issues occur, you enter them in your FRACAS using the incident report design you have established. The critical aspect of this entry phase of your FRACAS process is ensuring incident capture, i.e. making sure all issues are logged. For this reason, it is important to make sure your FRACAS is available to all team members and is easy to navigate and use.

Failure to fully capture and track incidents is one of the main reasons organizations implement a FRACAS. It forces all information to be centralized and ensures incident reports don’t simply “get lost”.

Step 2: Analysis

Determine the cause of the issue and recommend corrective action

Once an incident has been logged, the next steps involve the analysis. This phase also varies widely and is up to you to determine how to proceed with analyzing the reported issue.

The purpose of the analysis phase is to fully evaluate the cause of the issue and recommend a resolution. The analysis is typically assigned to a team member who is most able to perform this task. This may be an engineer, or a technical support person, or any other team member who can best analyze the incident.

Again, each organization can determine based on their unique requirements what information to capture and track in the analysis stage.

Step 3: Corrective Action

Implement corrective action and close-out the incident

The last step of your FRACAS will be resolution and close-out. At this point, you have determined the cause of the issue and decided how you are planning to correct it. So, it is now time to implement that recommended action. Once implemented, your team should verify the corrective action was successful, and if so, close-out the incident.

Remember that an important element of FRACAS is to make sure issues are tracked through to closure to avoid the broken loop situation. This final step ensures you have closed the loop.

The steps of a FRACAS: The FRACAS workflow

As you can see from the steps outlined above, FRACAS is a closed-loop process with any number of steps from initial incident report through incident resolution. Oftentimes, this series of steps is referred to as the FRACAS workflow.

In general, a workflow is a series of steps where tasks are passed from one team member to another for action. Your particular organization’s workflow is determined by how you handle your own path to resolving issues. Many times, organizations may begin with a process and then adapt it over time based on changing needs and lessons learned.

An example of a workflow process for a FRACAS used for a software company may be:

• Step 1. Entry: A software bug is logged into the FRACAS, whether from an internal source or a customer report.
• Step 2. Assigned: The bug is assigned by the team leader to a member of the development team to investigate and fix.
• Step 3. Fixed: The developer fixes the bug.
• Step 4. Verification: A QA team member reviews the bug fix and approves or rejects it.
• Step 5. Close-out: The bug has been fixed and approved.

This is an example of a custom FRACAS workflow process. Some organizations adopt accepted process methodologies that are commonly used in their industry, or across a range of industries. Some examples include:

• 8D: an eight-step process for process improvement often used by quality professionals, is commonly used in the automotive sector, but also widely accepted across a range of industries including aerospace, medical, healthcare, and manufacturing. The steps of the 8D process are (note that sometimes a step D0: Plan is also included):
  • D1: Establish the team
  • D2: Describe the problem
  • D3: Repair the problem
  • D4: Determine the root cause
  • D5: Define corrective action
  • D6: Implement the corrective action
  • D7: Prevent recurrence
  • D8: Recognize the team
• PDCA (Plan, Do, Check, Act): a four-step process also referred to as the Deming cycle or Deming circle, or the Shewhart cycle.
• DMAIC (Design, Measure, Analyze, Improve, Control): a five-step process improvement methodology used as part of Six Sigma practices.

5. What is CAPA (Corrective and Preventive Action) and how does it relate to FRACAS?

CAPA is also a closed-loop process for the management of failures or nonconformance. A CAPA process identifies actions to be taken to eliminate or mitigate failures or nonconformance issues related to procedures, processes, systems, or services in an organization. CAPA is closely tied to quality management.

In some industries, CAPA is required to meet regulatory standards. For example, industries such as pharmaceutical and medical devices have compliance requirements from the FDA that include having a CAPA in place. CAPAs also are part of many practices in the automotive industry. This is also the case for compliance with ISO standards, GMP and other Good Practices (GxP).

Corrective Action (CA) process management

While there is not a single CAPA standard, there are many process methodologies that are used to support a corrective action system, including 8D, PDCA, and DMAIC.

Many organizations also implement unique CAPA processes best suited to their needs and requirements. Regardless of the specific process employed, the main objective of CAPA is to effectively manage problems or issues.

FRACAS and CAPA relationship

CAPA and FRACAS both fall under the broad umbrella of closed-loop corrective action (CLCA) processes. Both CAPA and FRACAS share the same goal: to ensure your organization is meeting quality, reliability, and continuous improvement objectives through an effective closed-loop process for problem tracking and resolution. The terminology used may depend on the industry, the compliance standard being used, or even organizational preference.

As noted previously, the FRACAS acronym has its roots in the Department of Defense standard MIL-STD-2155. Therefore, FRACAS is a term widely used and recognized the military, defense, and aerospace sectors.

6. What are the FRACAS and CAPA standards?

There is not a single FRACAS or CAPA standard that is applied across the board. There are many standards that are industry-specific, as well as general guidelines for a high-level overview of the implementation of a FRACAS process.

The choice of a standard may be made due to industry requirements, compliance needs, corporate objectives, historical reasons, or simply preference. In general terms, your issue management process is part of your quality management system (QMS), even if it stands alone or is part of an integrated quality platform. Oftentimes, it is helpful to look to technical associations or organizations that serve your industry for guidance and suggestions. Organizations such as ASQ (American Society for Quality) may be a good starting point.

ISO compliance

A FRACAS can help you meet the requirements of ISO-9001 and ISO/TS 16949, as the failure reporting, analysis, and corrective action process aids in compliance with the stages of the ISO standardization process.

• Proposal stage: As a problem or issue is initially diagnosed, the people who first identify it can draft up a proposal detailing the scope and magnitude of the problem at hand.
• Preparatory stage: As steps are taken to halt a problem and develop a solution, immediate actions can be taken in preparation for the steps ahead.
• Committee stage: As tasks are delegated to different departments, select company personnel can be assigned with roles according to skill-sets.
• Enquiry stage: As questions are probed and conclusions are drawn about the issue in the report, further answers are developed as team members close in on the problem that led to the incident or negative trend in question.
• Approval stage: As actions are implemented and solutions materialize, authorized personnel can review and greenlight the final courses of action, bringing matters to a close-out within a proposed timeframe.
• Publication stage: Once completed, the final report of the FRACAS and how it was identified, tracked and ultimately brought to a close-out can be published and archived for subsequent review and study.

FRACAS and CAPA are part of ISO compliance because the steps of both standards align with the stages laid out by the International Organization for Standardization.

MIL-STD-2155 FRACAS Standard

The MIL-STD-2155, entitled Failure Reporting, Analysis and Corrective Action System (FRACAS), establishes the criteria needed to comply with the FRACAS requirement portion of MIL-STD-785. MIL-STD-785, or Reliability Program for Systems and Equipment Development and Production, is a broad standard that offers general guidelines as well as specifics for reliability programs that span the product lifecycle. While these standards are military in origin, they are still used across many industries and offer sound guidelines for a FRACAS process.

Meeting compliance requirements with FRACAS or CAPA

Many regulated industries and ISO certified organizations must have a CAPA process in place to meet compliance requirements. Standards such as ISO-9001, ISO/TS 16949, AS 9100, and policies that are part FDA, GMP, and QMS requirements include the need for defined and established FRACAS/CAPA processes.

The number of terms and acronyms can seem overwhelming at times, especially when first learning about CAPA and FRACAS. In general, CAPA and FRACAS both refer to process control management systems put in place to manage your process. Typically, companies look for a software solution to support their CAPA or FRACAS process. The underlying process control methodology, or workflow steps, used in a CAPA or FRACAS may be based on 8D, PDCA, DMAIC, or a custom-built process control methodology.

7. When should FRACAS be used?

FRACAS can be used any time you want to effectively manage and track issues from initial report through to close-out. Here are some instances when implementing a FRACAS may be advantageous:

• You have any process you feel is not being effectively tracked to closure.
• Reported issues are “getting lost” and not being handled.
• Your corrective actions are not being implemented quickly enough.
• Team members are not aware that they have a task or assignment to complete.
• You have recurring issues that should be analyzed for a root cause so a solution can be found.
• You have a compliance requirement for a trackable corrective management system.
• You want to see how well your deployed product is performing in the field.
• You want to track product repairs.
• You want to consolidate all departments into a single tracking and control system for issue management.
• You want to compare field-based performance metrics to predicted metrics.

8. How is FRACAS used in different industries?

FRACAS is used throughout the defense, aerospace, automotive, medical sectors, and many more to correct and resolve issues, and to ensure quality control. Some specific examples are outlined below, but there are a wide array of additional uses for FRACAS throughout a broad base of industries.

FRACAS in Aerospace

FRACAS is useful for ensuring the reliability of the equipment and systems used in the aerospace industry. Some examples of aerospace applications for FRACAS include:

• FRACAS can be employed in the various trial stages of new aircraft designs. For example, if a dummy-piloted plane fails to launch or pass an expected range of impact and vibration tests, the issue should be chronicled in a failure report and submitted for analysis among qualified professionals, who can then determine the proper course of corrective action.
• FRACAS can help ensure that the avionics software used by airplanes meets all of the applicable safety and reliability requirements.

FRACAS in the Automotive Industry

In the automotive sector, the reliability of vehicle components is crucial for customer safety, and customers demand high quality for all vehicle components. FRACAS can help automotive companies in these areas. Here are a few examples of how the auto industry uses FRACAS:

• FRACAS can be employed if a car model or its parts fail one of the many tests conducted during pre-production.
• Once a car is released to the general public, FRACAS can be utilized in the event of customer complaints.
• Auto repairs can be tracked for monitoring and tracking of recurring issues that should be addressed.
• Before a car goes into mass production, the automaker must test the various parts and components both separately and when they’re fully assembled. If a part fails strength or safety tests, it must be pulled for redesign.

FRACAS in Consumer Products and Commercial Industries

Companies that manufacture goods for consumer use can also benefit from FRACAS. These companies can use FRACAS in many different ways, including the following:

• FRACAS can help to continuously improve the reliability and performance of products by helping to resolve issues that occur during design, testing, manufacturing or usage by the customer.
• Companies can also use FRACAS to improve the reliability of their manufacturing equipment and, through that, the efficiency and productivity of their facilities.

FRACAS in the Defense Sector

The defense sector is where the term FRACAS originated. Today, companies that manufacture equipment and systems used by the military employ FRACAS to ensure the reliability of the weapons, vehicles, software and other equipment they produce, such as:

• If a weapons system is defective or in any way unsafe, a FRACAS could help the manufacturer pinpoint where the problem lies in the design. From there, design modifications could be drawn, reviewed and implemented.
• FRACAS is often employed during the design and deployment of components of military aircraft, such as radar systems, avionics, navigation systems, and weapons systems.
• FRACAS is used for equipment deployed in active military zones to track incidents that arise with military vehicles, and a wide range of equipment used for troop support.

FRACAS in the Healthcare and Medical Fields

FRACAS offers valuable advantages in the medical sector. Some examples include:

• At pharmaceutical laboratories, FRACAS software tools can help doctors develop formulas that are safe and effective at treating symptoms in patients.
• At hospitals, failure report and analysis can help doctors and nurses identify and rectify problems that may arise with certain treatment procedures.
• If patients complain about a particular treatment, an analysis can be performed and the results cross-examined among doctors, who can then take corrective actions based on their findings.

FRACAS in the Oil and Gas Sector

Companies in the energy sector can use FRACAS to solve issues that may arise regarding the supply or quality of oil and gas. Examples include:

• If a supply issue emerges, FRACAS should be conducted to pinpoint the source of the problem and identify the proper corrective option.
• FRACAS reliability analysis software can also help fuel companies determine the cause of quality issues, such as a fuel supply infected with trace elements and other impurities that could prove bad for motors.

FRACAS in the Telecommunications Industry

FRACAS can be used throughout the various branches of the telecommunications industry to analyze and correct failures that may occur with lines, services, and products. Some examples are:

• If customers in a particular area experience service interruption, FRACAS may be used to analyze the root cause of the problem and develop a corrective action that could eliminate or reduce the possibility of such events.
• If a new smartphone design fares poorly during the testing stage, FRACAS could help the manufacturer correct the problem, whether it involves connectivity or the physical durability of the device.

9. Why should FRACAS be performed?

The main reason to implement a FRACAS is to take advantage of its core objective: providing a closed-loop process for effectively tracking and managing issues as they arise and to prevent their reoccurrence. The results of successful FRACAS offer numerous benefits to organizations and all stakeholders, who gain better reputations among industry insiders, and the public at large, by employing these proven reliability improvement techniques.

FRACAS is a win-win all the way around: customers are better served, your organization handles issues efficiently and effectively, and investors remain engaged with a stable, capable company.

10. What are the benefits of using a FRACAS software tool?

Closed-loop processes extend to a wide range of business areas: product testing, non-conformance reporting, compliance requirement tracking, handling product failures in the field, tracking manufacturing defects, and many other examples. In essence, your organization may have various types of processes to track and manage. While the type of issues being managed may vary, the general process remains relatively the same: an issue is reported, and then the problem is corrected in some manner.

The number of steps between initial logging and final closure varies depending on your organization, your needs, the complexity of the process, the number of people involved, and, in some cases, compliance requirements. Additionally, the processes often develop and change over time as needs and requirements evolve.

Many times, organizations struggle to effectively manage and continually update all these processes. When process management spans departments, the management becomes even more difficult. In some cases, companies implement home-grown systems, or maybe even several different home-grown systems, to help control their processes. While the idea of creating and using a home-grown tool seems advantageous initially, it quickly proves daunting for several reasons.

Disadvantages of a home-grown tool

First, someone in your organization needs to manage any internal system you develop. While possible, using your team members for this purpose is not reflective of the core competency of your business. It is better practice to keep your team focused on working on your main business product, process, or service.

Second, software solutions need continual maintenance. This is not only due to technology evolution, but also due to the changing requirements of your internal processes.

Third, while a home-grown solution can be tailored to meet your process requirements, it will be lacking in comparison to all the features available in commercially available tools. For example, a FRACAS process is greatly enhanced when it supports notifications to keep team members informed of pending tasks, overdue tasks, and resolved issues. Also, an approvals process can be beneficial if you have a need for approvals before advancing through your process steps. And though not required, powerful features such as management dashboards and permission-based roles offer huge advantages. Adding these high-level capabilities to a home-grown solution is not easily or quickly accomplished.

Lastly, the vital link between FRACAS and reliability improvement can be most effectively managed with commercially available packages that offer shared data between your FRACAS and your other reliability software tools. The ability to analyze MTBF, MTTR, and other metrics based on your FRACAS data alongside those same metrics obtained from predictive tools can be helpful in determining if your product is functioning in the field as expected.

While it may appear at first that a home-grown system offers the most cost-effective approach for your FRACAS, in the long run, it is likely best to invest in a commercially available tool specifically designed for FRACAS.

Relyence FRACAS Software

Relyence FRACAS fully supports both CAPA and FRACAS processes and offers a robust platform for tracking and managing your corrective and preventive action process.

First, and perhaps most importantly, Relyence FRACAS offers a completely customizable platform. While Relyence FRACAS is an off-the-shelf software tool, the entire process and all supporting features can be tailored to meet your requirements. With out-of-the-box support for the most widely accepted process methodologies, including 8D, DMAIC, and PDCA, you can tailor these, or create your own completely unique process. And, the customization features are available to you, so you can customize on your own if you prefer. Or, our professional services team can be engaged to help in any way needed, whether just for guidance and advice, or complete implementation of your FRACAS.

Beyond customization, Relyence FRACAS offers a wealth of features to support your FRACAS and ensure you are getting the most possible from your system. Notable features include workflow, approvals, notifications, dashboards, reliability and availability metrics, trend score analysis, custom calculations, audit trails, data import and export, API support for integration with other software tools, and integration with the Relyence Studio reliability platform.

For more information, feel free to contact us to schedule your own personal webinar, or you can sign up today for a free trial.