Relyence User Guide
Introduction to FRACAS

Establishing a FRACAS

FRACAS, or Corrective and Preventive Action, is a way for you to capture, monitor, track, and evaluate your process for handling incident reports of any kind. FRACAS Incidents are commonly meant to be failures, but Relyence FRACAS is not limited to this, and your Incident reports can be a variety of items - such as customer complaints, maintenance requests, tech support issues, software bugs, etc. 

A FRACAS is typically customized to your needs. Relyence FRACAS offers a few excellent starting points for your FRACAS. You may choose to use these FRACAS templates as is. If you want to modify them, they are completely and easily customizable. See Relyence FRACAS Advanced Features for more information on customizing your FRACAS. Our implementation team can help you in customizing the Relyence FRACAS interface to meet your needs. We can also aid in defining your process, or establishing a new FRACAS. Feel free to contact us for details.

We recommend going through Getting Started with Relyence FRACAS as a starting point for learning Relyence FRACAS. The following process is intended to be a starting point; you can adapt it as required for your needs.

1. Decide what information you want to capture and track

The central element of any FRACAS process is an incident report. This incident can be any type of issue, bug report, customer complaint, failure report, etc. - essentially any issue you want to log and track to resolution.

When an issue is reported, you need to determine what information you want to capture with its report. For example, you may want to know the date it occurred, the customer name, the person who entered the issue, a description of what happened, troubleshooting actions taken, repairs made, who is responsible for resolution, etc. The amount of data and what you choose to capture is completely up to you, you just need to determine what is most critical to you and what may help for tracking and measurement moving forward.

Relyence FRACAS includes a set of supplied templates that you can choose to use as is, or modify to suit your needs. These templates include a set of data fields that are commonly used in FRACAS processes.

2. Decide if you want to use Problems

While an "incident", or single reported issue is central to FRACAS, you also need to consider if you want to implement a standard, or systematic, approach to multiple or single incident resolution.

For example, an 8D process is a well-known and standard methodology for handling a defined Problem. A problem is generally considered to be any issue or group of issues that are in need to further review and analysis. One example would be the case where you notice a sudden spike in product failures, or customer complaints. You can then review all your incident reports and group similar failure reports together and create a Problem for a team to investigate. The investigation may include a root cause analysis (RCA), subsequent recommendations for corrective action, and then implementation of an agreed upon corrective action.

You may decide you want to use your FRACAS for incident tracking only, and not use Problems. Relyence FRACAS enables you to work in either way.

3. Enter your Incidents as they occur

As issues are reported, enter them into your FRACAS. Make sure everyone involved in issue management has access to your FRACAS and can enter information as they receive it. A FRACAS is most helpful when all issues are logged and tracked. This is the most efficient way to ensure that all incidents are handled.

If you have another system that you use for incident capture, you may choose to maintain that process and then import the data into your FRACAS on a scheduled basis. For example, you may have technicians in the field who record incident in a simple way, perhaps even using an application such as Microsoft Excel. At the end of each day, you can transfer those reports (i.e. import) into your FRACAS for full tracking, analysis, and close out. Or, you could choose to use the Relyence API as an alternative mechanism for populating and/or extracting your FRACAS data.

Depending on the amount of data you decide to log and track for your reported issues, you may have different people from different teams or departments responsible for data entry. You do not need to completely fill out your FRACAS forms all at once, but you can go back and augment your incident report as the issue progresses through your process.

4. Create Problems as needed

If you elect to utilize Problems, either through an 8D process, or any other process, make sure you elevate issues of concern to the Problem level as needed. 

Usually, once a Problem is defined, a team approach is taken. You decide who is to be part of the team for Problem resolution and then assign tasks according. There may be people from various departments involved in Problem resolution.

5. Track Incidents and Problems through to resolution and close out

One of the most significant advantages of implementing a FRACAS is to make sure issues are tracked through to resolution and close out. Your objective is to close out all issues logged in your FRACAS to the satisfaction of your customer. An effective FRACAS management process is essential to maintaining your company reputation for quality and customer service.

Tracking Problems through to resolution, corrective action, and close out is also a powerful way to provide for continual product improvement.

6. Monitor your FRACAS

Continually review your FRACAS open items, review output reports, and follow up on actions and corrective actions being implemented. Set dates for resolution, assign responsible parties as needed to ensure actions are completed. Through judicious use of continual monitoring, you can always be aware of issues of concern and address issues early before large problems occur.