What is FRACAS?
FRACAS, or Failure Reporting, Analysis, and Corrective Action System, is a closed-loop management system to organize, track, and manage your process for handling and resolving problems or issues. The process is initiated with a problem report, progresses through identifying a corrective action, and finally concludes with implementing the recommended resolution. Product-centered companies, large to small, engage in some type of closed-loop corrective action (CLCA) process, some more formal and controlled than others. The core objective of FRACAS is to ensure that the process for problem handling is well-managed, controlled, trackable, and consistent.
The FRACAS acronym has its roots in the MIL-STD-2155 Department of Defense standard published in 1985. Therefore, FRACAS is a term widely used and recognized in industries related to military, defense, aerospace, etc. However, the usage of the term is now broadly accepted across all industry sectors. Additionally, there are various terms used to denote the same type of closed-loop process, such as CAPA (Corrective and Preventive Action), CA (Corrective Action), APQP (Advanced Product Quality Planning), and QMS (Quality Management System). FRACAS and CAPA specifically have long histories and wide acceptance. No matter what terminology is used, a closed-loop corrective action process offers a solid framework for improving reliability, quality, operation, and safety by systematically managing issues as they occur.
The FRACAS Process Explained
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 Steps of a FRACAS Process
Step 1: Failure Reporting
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.
No matter what type of items you are tracking in FRACAS, you must determine what information to capture and log. Generally, you want to include any data pertinent to helping resolve the issue and for any future tracking you would like to do.
At the initial entry stage of FRACAS, you want to define the information that the person logging the incident report should collect. The data captured at this early stage should include as much information as possible about the failure and how it was found.
Some examples of data you could consider including in an 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
- Any causes investigated that proved to not be relevant in order to rule them out for future analysis
- What was done to correct the issue when found
- 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. Therefore, FRACAS incident reports are typically customized to each organization’s unique requirements.
Step 2: Analysis
Once an incident has been logged, the next steps involve analyzing the problem to determine the cause. The purpose of the analysis phase is to determine and verify the root cause of the issue and recommend a resolution. The analysis phase is critical in order to perform successful corrective action. Oftentimes, there may be multiple team members across different organizational departments involved in the analysis phase.
Step 3: Corrective Action
The last step is resolution and close-out. At this point, you have determined the root cause of the issue, so you can develop a corrective action plan. Implementation of the plan is key as well and includes determining the action to take, who is responsible, and deciding the timeline for implementation. Lastly, there should be a verification plan in place as well to ensure the corrective action was successful. Once verified, the incident can be closed out.
Methodologies for Implementing a FRACAS Process
While there is not a specific standard that your FRACAS process must follow, there are many techniques and methodologies that provide guidance for how to proceed.
Many regulated industries and ISO certified organizations must have a corrective action process in place to meet compliance requirements. Standards such as ISO-9001, ISO/TS 16949, AS 9100, and policies that are part of FDA, GMP, and QMS requirements include the need for defined and established FRACAS/CAPA processes. ISO standards do not impose a methodology that must be followed but allow you to define and implement a system that meets your needs. However, ISO compliancy does require that your process is controlled and followed to your specifications.
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, entitled 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.
To comply with the needs of ISO, MIL-STD-2155, and other corrective action industry requirements, oftentimes businesses turn to well-defined and well-known process methodologies when implementing FRACAS. There are three commonly adopted techniques used across a broad range of industries: 8D, PDCA, and DMAIC.
It is important to note that is it very common for organizations to start with one of these known process types and modify it to align with their unique needs. By adopting one of these methodologies or a process based on one of these methodologies, you are assured that your FRACAS will meet compliance requirements.
For details on FRACAS methodologies, refer to our descriptive blog post.
When Should I Use FRACAS?
All organizations must handle problem reports of some kind. These issues may be items such as product failures, customer complaints, testing failures, non-conformance reports (NCRs), safety issues, audit findings, QA (quality assurance) reports, client reported failures, manufacturing defects, software bugs, inspection findings, defect reports, repair logs, and so on. The goal of FRACAS is to ensure that whatever issues you need to handle are captured and then tracked until they have been properly addressed.
Therefore, FRACAS is used any time you want to effectively manage and track issues from initial report through to close-out. A few example instances when implementing a FRACAS may be advantageous include:
- Reported issues are “getting lost” and not being handled.
- Customers are reporting defects and you want to ensure they are appropriately addressed.
- 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 track failures in testing.
- You want to improve customer response times.
- Safety or compliance issues have been reported.
- You want to implement defect tracking.
- You want to see how well your product is performing in the field.
- You need to ensure issues noted during an audit such as NCRs are corrected.
- You want to track product repairs.
- You want to consolidate all departments into a single tracking and control system for issue management.
- Warranty claims are higher than expected.
- You want to compare field-based performance metrics to predicted metrics.
What Are the Benefits of FRACAS?
There are many advantages of implementing a FRACAS process. At its most basic level, FRACAS provides the ability to track issues, so nothing is overlooked or forgotten. So, the central advantage of a FRACAS is that it ensures that as incidents arise, they are captured and recorded, and tracked until they have been properly addressed.
Beyond this key advantage, there are several additional key advantages of FRACAS.
- Track and control preventive action tasks, or the implementation of recommended action plans to make sure issues do not reoccur.
- Ensure your issues are tracked in one central data repository, meaning that all data is encapsulated in one place and not scattered throughout the organization.
- Provide centralized issue handling so anyone in your company, group, or team can view this critical information and always be aware of the status and their tasks.
- Retain lessons learned for future problem resolution as the FRACAS data bank of information continually grows over time.
- Analyze your process, track metrics, and monitor your system for continual process improvement.
- Improve quality, reduce risk, increase reliability, and enhance safety.
FRACAS Case Study: An Example FRACAS Process
Design of a FRACAS process is specific to each organization depending on needs and requirements. While the 8D, PDCA, and DMAIC methodologies are often used, in many situations, businesses choose to build a custom FRACAS process based on what works best for them.
A good example of a custom FRACAS solution is a software firm that employs Relyence FRACAS to track software defects. Their customized FRACAS process was designed internally. Due to the flexibility of the Relyence platform, they were able to customize the user interface to their requirements and utilize some of the built-in features of Relyence to optimize their process. The FRACAS software defect tracking system is used for managing customer reported defects as well as defects uncovered during QA testing.
A 3 Step FRACAS Process
There are three steps in the Defect Tracker:
- Defect Report
- Analysis and Fix
Step 1: Defect Report
The process begins with a software defect entered into the Defect Tracker. Defects can be logged by any team member. Defects are typically recorded by QA team members during internal testing or by Technical Support team members from customer reported issues.
Upon initial entry, several fields are automatically filled in by Relyence FRACAS: the Defect ID, the date, and the person recording the defect. The Defect ID is autogenerated based on criteria you can set. The date is set to the current date and the person recording the defect is set to the name of the logged in user. This data can be modified if needed. Taking advantage of the Relyence FRACAS features that allow you to designate default values upon entry makes data entry easier and less error prone.
When a defect is reported, it is important to capture as much information as possible to aid in problem resolution. First, a short description is entered which is useful to get a quick idea of the nature of the defect. This short description can also be helpful for higher level managers or team leaders who do not need to get into the finer details of the problem. Then, a more detailed explanation of the defect is entered. Also included is information about who found the defect. In this case, if the defect was found by a customer, the Customer ID is entered in order to aid in follow up once the defect is resolved.
A priority is then assigned to the defect. The priority assignment is an internally defined list to help designate task priority. This is a dropdown list selection of:
- High – Fix as soon as possible
- Medium – Fix within one month
- Low – Fix within the current release cycle
Included in the new defect entry are several data fields to define the problem in greater detail to aid analysis and resolution:
- Steps to Reproduce: if known, a list of the steps which can reproduce the defect
- Screenshots of Defect: this can be any number of images which show the defect occurring, or the aftereffects of the defect
- Attachments: if any additional documents or images can be useful for analysts, they can be attached
Lastly, and importantly, using Relyence FRACAS, you can optionally include a Workflow, Approvals and Notifications element to your FRACAS process. This capability enables you to set up a Workflow process that is automatically engaged for your defect tracking. This allows you to move the defect through the Workflow process, set due dates for resolution, and assign responsibility along each step. A significant advantage of enabling the Workflow, Approvals, and Notifications feature in Relyence is that team members can receive notification emails to inform them of a variety of statuses, such as when a new defect is entered that they need to fix, defects that are past their due dates, and due dates that are upcoming.
In this case, upon entry of a new defect, a team leader is notified. The team leader reviews the information, assigns the team member responsible for fixing the defect, sets a due date, and then advances the Workflow to the next step of the process – Analysis and Fix.
Step 2: Analysis and Fix
The second step in the Defect Tracker is the analysis and subsequent remedy. In the Workflow Data section, you can see the engineer assigned to analyze and fix the defect along with the due date for resolution.
Upon analysis, there may be two outcomes: the defect is fixed, or the analyst is unable to duplicate the problem, and therefore, cannot determine a fix. In the latter case, the analyst will check the CND (Could Not Duplicate) checkbox. Otherwise, if resolved, the analyst completes the following information:
- Date Fixed: the date the fix was made
- Fix Description: a description of what was done to fix the defect so there is a record of problem resolution
- Notes for Verification: this is an optional field that can be used to provide helpful notes for the analyst assigned to verify the defect is fixed
Once the fix has been completed, the analyst assigns responsibility for defect verification, sets a due date, and progresses the Workflow to the next step – Verification.
Step 3: Verification
The final stage of the Defect Tracker is to verify that the defect has been properly addressed and fixed. The team member responsible for verifying the fix can be seen in the Workflow section along with the assigned due date. Again, all pertinent information about the defect is available, such as Steps to Reproduce and Notes for Verification, which can aid in the verification process.
If verification is successful, the team member enters the date the verification was completed.
Lastly, the defect is Closed by checking the Closed box on the form. Notably, if using the Relyence built-in Workflow feature, you can set the Closed indication to be automatically set upon the final Workflow Step being completed. Once Closed, the defect data is automatically set to read-only so no further updates can be mistakenly made to the defect report. In this case, a notification is sent to the team leader that the defect has been fixed, so, if necessary, the customer can be notified.
If verification is not successful, the Workflow process enables the team member to reject the fix and set the Workflow back to the prior Analysis and Fix stage. Information about why the rejection occurred is included. At this point, the analyst must go back to review and properly resolve the issue. Once completed, the defect is again progressed to the verification stage for reassessment.
As you can see from the example case study, this FRACAS implementation does not follow an 8D, PDCA, or DMAIC process, but is a very capable and controlled issue management system. It includes the three key parts of FRACAS: failure reporting, analysis, and corrective action tracking. It is a good example of how a FRACAS process can be custom tailored to meet any organization’s needs.
How Do I Implement FRACAS?
Implementing a FRACAS starts by evaluating your current process. How do you track and handle issues that arise in your organization? Do different departments use different processes? What are the advantages of your current process? What are the disadvantages? Discuss which elements are working and which elements could be improved.
Talk to team members across your organization using a cross-functional approach to gain all insights needed to implement a system that will work for everyone. Once you have this foundation, you can begin to build a specification for your FRACAS process. It may take several iterations to come to agreement on the best process for your organization.
At this point, you can explore the various choices you have to implement your FRACAS. You can choose to build an in-house system using off-the-shelf software tools, hire a software development firm to create a custom solution for your needs, or turn to a commercially available FRACAS software tool. For a detailed look into these options, read our informational blog post.
If you do not have a cohesive approach in place for handing issues, or you want to implement a process based on a known and proven methodology, or simply want to start fresh using a solid framework to build on, it is best to turn to a commercially available FRACAS software tool. They provide a proven foundation and offer numerous features for quick start up and ease of use.
What Should I Look for in a FRACAS Software Tool?
When evaluating FRACAS software, there are many factors to consider. One major feature to look for is the ability to easily customize all aspects of the process. As mentioned, there is rarely a one-size-fits-all approach to a FRACAS process, and it is quite common for FRACAS processes to grow and change over time. For this reason, a product that is easily customized is key.
It may be helpful to find a tool that supports the most commonly used process for problem resolution: 8D, PDCA, and DMAIC. Providing this support out-of-the-box can get you up and running in minimal time. Also, allowing the customization of these formats is critical as well.
There are several features beyond the core process management aspect that are important to consider. These are not necessarily as obvious until you begin to use the tool on a daily basis, but will be important considerations as you move forward in establishing your FRACAS. Some of these important items to evaluate include:
- Ease of use of the software
- Browser-based accessibility with mobile device support
- Workflow, approvals, and notifications for process control
- Audit tracking, especially for compliance concerns
- Metrics for measurable performance tracking
- Dashboards for high level overviews of your process
- Customer service and support
Relyence FRACAS 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. Also, 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 for 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.