Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
c o m
White Paper
Page 1 of 7
White Paper
Page 2 of 7
1. What is a FRACAS?
A FRACAS, or Failure Reporting, Analysis, and Corrective Action
System, is a closed loop system used to improve the reliability of a
product, service, process, or software application. The closed loop
in a FRACAS refers to the systematic manner in which every issue
that is reported is addressed, ensuring that no failure or incident is
missed. The need for a FRACAS spans all industries and classifications,
including hardware, software, process management, and services in
both government and commercial sectors. Software-based FRACAS
processes offer the added benefit of built-in analytical capabilities,
allowing organizations to track key system metrics that include Failure
Rate, MTBF, MTTR, Availability, Cost, and user-defined calculations,
among many others. Built-in reporting and graphing features mean
these metrics to can be trended with regards to time, severity, and
many other factors. In addition, the effectiveness of the FRACAS itself
can be monitored by tracking the overall improvement of the system
as a result of the FRACAS.
FRACAS is used extensively in the following industries: Aerospace,
Automotive, Defense, Electronics, Manufacturing, Telecommunications,
Medical Devices, and others. While a corrective action system is commonly referred to as a FRACAS in many government-related initiatives,
it may be referred to by other names in other industries, including
a CAPA (Corrective and Preventive Action) System, Corrective Action
System, Quality System, and others where the first letter of the FRACAS
acronym is replaced by a P for Problem (PRACAS), an I for Incident
(IRACAS), or a D for Data or Defect (DRACAS). In addition, FRACAS
can be applied for RMA (Return Materials Authorization or Return
Merchandise Authorization) processes and various other quality assurance processes, like bug tracking, call centers, and the like.
How is a FRACAS Performed?
An effective FRACAS ensures that all failures or incidents proceed through these
four major steps: closing the loop to ensure that no failure or incident is missed.
White Paper
Page 3 of 7
A survey conducted by the Reliability Information Analysis Center (RiAC) cited that companies view a
FRACAS to be among their top two most important reliability tasks.
The most successful FRACAS processes are easy to use, employ userfriendly software tools to automate the workflow, and require modest investments in resources and training. By keeping things simple, it
is more likely that those outside the quality/reliability functions will
participate as required. Ultimately, it is important that the FRACAS be
simple enough to work well for both the expert and novice. Of course,
it is also important that the process is designed to allow for a thorough
and effective FRACAS.
Quality Assurance
Operations
Customer Service
Reliability
Field Services
Suppliers
Testing
Maintenance
Utilizing available software tools is one key way to help automate the
FRACAS and make it easier to use. Software tools can help automate
data entry, data analysis, and data output, while providing a central
storage area for critical FRACAS data and results.
Management
Engineering
Others
The collection and analysis of FRACAS data can be two of the most
time-consuming tasks for a FRACAS. Easy to use Web-based forms are
often a great way to provide for efficient data entry. Automated calculations, graphs, and reports, along with the ability to filter data, can
increase the efficiency and effectiveness of data analysis.
Supply Training
Even when a simple FRACAS process is implemented, providing comprehensive training early in the implementation process can alleviate
the concerns of those involved and help make them active participants
in the FRACAS. As feedback is accepted and the FRACAS evolves, it is a
good idea to provide additional training in the more advanced technical and software-related aspects of the process.
Encourage and Offer Feedback
Encouraging feedback from the users of the FRACAS can help those
in leadership roles adjust the FRACAS to become more efficient and
effective. Likewise, providing feedback to all participants, including
feedback in the form of outputs from the system, can be encouraging,
as it can demonstrate the positive, tangible results of the efforts of all
who have adapted to and successfully implemented the FRACAS.
With all of these different groups involved in the process, the interaction across and between various groups can become quite complex.
Some groups may need to be included at multiple points throughout
the workflow. This increases and complicates the steps required to close
out an incident. Consider the following scenario: A simple process is
defined such that a field service representative reports or logs an incident. Quality Assurance reviews this incident and then assigns it to
the Reliability group to perform a root cause analysis. The Reliability
group then recommends a corrective action that the Engineering group
implements. Finally, the Failure Review Board approves the corrective
action and closes out the incident.
Over time, additional groups may request to be involved. For example,
Customer Service believes that they too need to be involved at the corrective action step in the process. Because they directly interface with
the customer, they want to understand and possibly shape the corrective action response that may occur. Sales and Marketing may also
need to be involved to properly manage a customers account. And, a
Supplier may wish to be involved in the analysis and corrective actions
that have occurred with its parts. Very quickly, the number of groups
involved increases, and the process becomes more complex. This may
result in a long cycle time between the opening of an incident and its
eventual closing. If the process is too complex, incidents can become
forgotten and never worked through to completion.
White Paper
Page 4 of 7
White Paper
Page 5 of 7
Streamlining Data Entry and Data Tracking: By entering a single identifier, such as the serial number of a
returned product, as shown above, Relex FRACAS uses lookup table functionality to autopopulate the remaining fields.
The key to ensuring a FRACAS is effective is to gather and report meaningful data. This seems to suggest that the more data an organization
can gather regarding an incident or failure, the better its FRACAS will be.
But this is not necessarily the case. Too much data may prevent companies from discovering meaningful trends.
For example, many legacy FRACAS systems collect 80 or more fields of
information when recording a failure. Although much of this data is
valuable, gathering too much data can result in several problems. For
example, suppose it takes customer support personnel five seconds to
enter data into each field. They will spend 400 seconds or 6.6 minutes
filling in all 80 fields, not including research time, resulting in a general
feeling that it is just too time consuming to fully log a problem. Fields
are routinely skipped and some issues are not even reported because it is
too much trouble. To prevent this, designers develop input screens that
will easily accept incident information.
However, as is often done, designers utilize free flowing text fields to
allow customer support personnel to type any information that they
think is useful. The personnel can then become confused, and do not
always know what to enter. Consequently, they begin to include extraneous or irrelevant data and sometimes just leave the field blank. Not
only is it difficult to perform any meaningful analysis with the resulting
data, but it also becomes a tedious manual process to review each individual incident in search of trends.
Solution 3: Effectively Managing Data
To avoid the problems of inefficient and ineffective data tracking, organizations should establish functional procedures before data collection
begins. Using simple, streamlined forms which store data in a central
database is often the best approach. Training the FRACAS users responsible for data entry helps ensure that all important data is entered correctly and efficiently. It is also helpful to remind those responsible for
entering failure data of the importance of capturing the data at the time
of failure, and the long term benefits to the organization that can result
from timely data capture. Whenever possible, employ automation when
capturing the failure data.
Defining the goals of all intended users and stakeholders is the foundation for a successful FRACAS. Every step in the process of implementing a FRACAS will be based upon these goals. Ensuring these goals are
understood and agreed upon by all is key before implementing the
FRACAS. A mistake or misunderstanding at this step can have negative consequences later. Because issues may not become known until
months later, it is important to commit to a thorough job of researching
and documenting everyones goals and the rationale behind them.
To begin this process, hold a series of short team meetings with each
of the groups and stakeholders with a role in the FRACAS. Map out
each groups specific goals and expectations for the FRACAS. Typical
goals include lowering maintenance costs, improving overall reliability,
and improving next generation product design. Be careful to avoid the
common pitfall of moving off of goal establishment and into detailed
requirements. The purpose of this exercise is for each group to come to
a consensus on the priority of its primary goals.
Step 2: Define the Output
With goals and success factors in place, it is time to define the results
or outputs that each group is expecting from the FRACAS system to
achieve the success factors that were outlined in the groups agreedupon goals. Typically, the results are stated in terms of calculations,
charts, graphs, and reports. For example, the Reliability group may need
a Pareto chart indicating the number of failures by part number. The
Field Service group may require a report indicating the cost of warranty repairs by part number. The Quality group may require a reliability
growth chart.
White Paper
Page 6 of 7
Determine a workflow for the FRACAS: Ensure that roles of all stakeholders involved in
the process are properly represented, as in this RMA (Return Materials Authorization) workflow.
Using the process diagram and the output requirements, determine the
minimum data fields required to support the workflow process at each
step. Investing time in this step helps eliminate the problem of collecting data with no direct purpose, and can help focus users' efforts.
After the data fields have been established, determine how the data will
be viewed by the user. It may make sense to show one large form with
all of the data fields. Or, it may be better for each group to have specific
forms with specific fields displayed so that their view of the data is limited for ease of understanding. Involve the stakeholders to understand
what they are expecting and why.
Additionally, specify how the input data will be gathered. Recall, from
Challenge 3 above, that it is important to collect valid, meaningful
data in an efficient manner. Popular methods include lookup tables to
populate fields based on previous input, drop-down menu choices for
standardized data entry, and bar code scanning.
Step 5: Implement a Prototype FRACAS
Now that the goals, success factors, expected output, workflow process,
and entry forms are defined, you are ready to choose an implementation approach. General purpose tools, such as spreadsheets and personal database programs like Microsoft Excel or Microsoft Access, are
limited in their capacity to handle large amounts of data and may not
support the sharing of data between multiple users. FRACAS calculations and graphing are not intrinsically supported by general purpose
software, and no functionality is included to generate workflow noti-
White Paper
Page 7 of 7
5. Conclusion
Yielding more reliable products, better collaboration throughout teams
in the organization, and valuable system metrics to track product performance over many different factors, an effective FRACAS is a valuable
tool for any company seeking to improve its quality and reputation. By
examining the best practice approaches to implementing a FRACAS
process, companies can help ensure successful adoption, streamlined
implementation, and effective results from the system.
7. Bibliography
1. Failure Reporting, Analysis and Corrective Action System
(FRACAS) Application Guidelines, Product Code FRACAS, Reliability
Analysis Center, 1999 Sep., p 5.
2. M. Villacourt, P. Govil, Failure Reporting, Analysis and
Corrective Action System (FRACAS), Doc ID #: 94042332A-GEN,
SEMATECH, 1994 Jun., Available at
http://www.sematech.org/docubase/document/2332agen.pdf
3. NASA, Preferred Reliability Practices Problem Reporting and
Corrective Action System, Practice No. PD-ED-1255, available at
http://klabs.org/DEI/References/design_guidelines/design_
series/1255ksc.pdf
4. MIL-HDBK-2155 Department of Defense Handbook: Failure
Reporting, Analysis and Corrective Actions Taken
5. RiAC: Reliability Problem Solving, Failure Reporting and
Corrective Action System (FRACAS) and Reverse Engineering,
http://src.alionscience.com/pdf/fracas.pdf
6. E.J. Hallquist, T. Schick, Best Practices for a FRACAS
Implementation, pp 663-667, RAMS 2004.
7. J.S. Magnus, Standardized FRACAS for non-standardized products, pp 447-451, RAMS 1989.
8. A. Mukherjee, Integrated FRACAS systems for F117 infrared
acquisition designation system (IRADS) support yield higher
MTBMA, pp 26 - 29, RAMS 2005.
9. MIL-STD-721C: Definitions of Terms for Reliability and
Maintainability, 1981.
8. Learn More
For more information about Relex FRACAS, please visit:
www.relex.com/products/fracas.asp
Copyright 2009, Parametric Technology Corporation (PTC). All rights reserved. Information described
herein is furnished for informational use only, is subject to change without notice, and should not be
construed as a guarantee, commitment, condition or offer by PTC. PTC, the PTC logotype, Relex, and all
PTC product names and logos are trademarks or registered trademarks of PTC and/or its subsidiaries in
the United States and in other countries. All other product or company names are the property of their
respective owners.
4915-Relex-WP-1009