Tutorial

2012 Annual RELIABILITY and MAINTAINABILITY Symposium
Closed-Loop Corrective Action Basics,
Best Practices and Application
Brad Cline
PTC
Services Manager
Windchill Quality Solutions
41 W. Otterman Street
Suite 310
Greensburg, PA 15601 USA
Internet (e-mail): bcline@ptc.com
Brad Cline & Ken Stillwell
Tutorial Notes © 2012 AR&MS
Ken Stillwell
PTC
Vice President, Strategy & Operations
Windchill Quality Solutions
41 W. Otterman Street
Suite 310
Greensburg, PA 15601 USA
Internet (e-mail): kstillwell@ptc.com

SUMMARY & PURPOSE
This tutorial introduces basic information about closed loop corrective action processes. There are many names for the
closed loop corrective action process, including FRACAS (Failure Reporting, Analysis, and Corrective Action System), CAPA
(Corrective and Preventive Action), PRACA (Problem Reporting, Analysis, and Corrective Action), and others. These processes
bring together a wide range of information, from test results to field data to repair records. Outputs can include both qualitative
and quantitative results that are inherently customizable to the specific needs of the organization. This tutorial also addresses
several of the key obstacles to deriving a successful closed loop corrective action process as well as best practice suggestions
and a proven methodology for realizing the full benefits of a lucrative closed loop corrective action process, including
improvements in quality, reliability, and productivity along with reduced costs. To conclude the tutorial, several case studies are
presented that highlight success stories from a wide range of groups who have implemented effective closed loop corrective
action processes.
Brad Cline
Brad Cline (Services Manager - PTC’s Windchill Quality Solutions) manages enterprise-level implementations, from
requirements definition and design to system installation, with over 50 large-scale FRACAS implementations globally. Brad
also manages consulting services, which functions as a full-service reliability engineering support center. With a BS - Applied
Mathematics - Carnegie Mellon University and MBA - University of Pittsburgh, Brad has experience managing data
warehousing implementations, data analysis activities, and web-based enterprise reporting tools.
Ken Stillwell
Ken Stillwell (Vice President – Strategy and Operations) is responsible for driving efficiency in operations and overall
growth strategies for PTC’s Windchill Quality Solutions, and leads customer support, global education, and global services. Ken
oversees enterprise-level FRACAS implementations, with more than 150 FRACAS deployments completed by the
implementation team. With a BS - Business/Economics - University of Pittsburgh and MBA - University of South Carolina, Ken
has held executive positions in software/IT, biotech and aerospace.
Table of Contents
1. Introduction .......................................................................................................................................................................... 1
2. FRACAS Fundmentals ......................................................................................................................................................... 1
3. FRACAS Best Practices ....................................................................................................................................................... 2
4. Challenges to Effective FRACAS ........................................................................................................................................ 3
5. Steps t Successful FRACAS Implementation ...................................................................................................................... 4
6. Practical Application ............................................................................................................................................................ 6
7. Conclusions .......................................................................................................................................................................... 8
8. References ............................................................................................................................................................................ 8
9. Tutorial Visuals…………………………………………………………………………………….. ................................... 9
ii – Cline & Stillwell 2012 AR&MS Tutorial Notes

1. INTRODUCTION
To produce high-quality products in an ever more
competitive marketplace, the ability to efficiently discover,
track, and correct incidents or failures found during product
development, testing, and operation is crucial. This need spans
all industries and classifications, including hardware,
software, process management, and services in both
government and commercial sectors. Notably, a survey
conducted by the former Reliability Analysis Center (RAC),
now the Reliability Information Analysis Center (RIAC),
indicated that companies view this subject, most commonly
referred to as FRACAS (Failure Reporting, Analysis and
Corrective Action System), to be among their top two most
important reliability tasks (1). Additionally, as of mid-March
2011, as per Directive-Type Memorandum (DTM) 11-003 –
Reliability Analysis, Planning, Tracking, and Reporting, as
part of a comprehensive reliability and maintainability (R&M)
program, a failure reporting and corrective action system is
required to be maintained through design, development,
production, and sustainment.
Manufacturers and service providers have employed a
variety of methods for tracking product failures and managing
corrective actions. These systems include paper-based
approaches, electronic spreadsheets and personal databases, or
even large enterprise systems that affect hundreds or
thousands of customers, suppliers, and engineers worldwide.
Conceptually, the benefits of a failure tracking and corrective
action process are clear. However, implementing such a
system that yields more reliable products and improved
designs in an efficient and effective manner is complex.
Different groups have attempted to define structured
approaches and guidelines for the implementation of failure
reporting and corrective action systems. Organizations such as
the RIAC, in accordance with the U.S. Department of Defense
(DoD), have studied the requirements of both large and small
companies to develop general guidelines for FRACAS. In
addition to the RIAC guidelines, other similar efforts have
been published for public use, including SEMATECH’s
“Failure Reporting, Analysis and Corrective Action System”
Planning and Implementation Guide (2) and NASA’s
“Preferred Reliability Practices, Problem Reporting and
Corrective Action System” documents (3). While most
government-related initiatives commonly refer to corrective
action systems to as FRACAS, other names, including
PRACA, Quality System, Corrective Action System, and
others abound. Regardless of what the systems are called,
these published guidelines present process-based approaches
to solving the fundamental problem of product improvement
through failure recording, corrective action, and lessons
learned.
Even with existing guidelines and advancements in
computer and communications technologies, the
implementation of a cost-effective FRACAS that produces
more reliable products remains a challenging task. Having
examined the deployment of FRACAS in a variety of
industries, the authors have determined that the publicly-
available guidelines fail to address many of the practical
complications that exist. These intricacies are neither processrelated
nor technical in nature but instead stem from each
company’s unique organizational structure, goals, and
expectations. With this tutorial, the authors seek to provide
additional practical guidance for implementation of a
FRACAS, considering best practices and a step-by-step
process for a successful FRACAS.
2. FRACAS FUNDAMENTALS
2.1 What is FRACAS?
As defined earlier, FRACAS stands for Failure Reporting,
Analysis, and Corrective Action System. The FRACAS
process allows efficient tracking, analysis, and correction of
problems found during product development, testing, and
operation. Though most commonly used with fielded
products, FRACAS can be applied to products, services,
processes, and software applications thanks to its flexibility. A
FRACAS is ultimately a closed loop system that improves the
reliability of the product, service, process, or software
application by focusing on failure reporting and resolution.
Naming conventions vary widely. Variations include 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), “I” for Incident (IRACAS), and “D” for Data or
Defect (DRACAS).
2.2 Why is FRACAS important?
FRACAS implementations track, analyze, and correct
problems found during development, testing, and operation,
with the goal of improving the reliability and quality of its
target product. In many instances, FRACAS also identifies
trends related to failures and prioritizes the top issues to be
addressed. In any specific implementation, the reason for
employing the FRACAS process should be identified clearly
as the process is defined. In some cases, specific customers
may require using FRACAS explicitly.
2.3 Who uses FRACAS?
The need for FRACAS spans all industries and
classifications, including hardware, software, process
management, and services, in both government and
commercial sectors. Many industries use it extensively,
including:
• Aerospace
• Automotive
• Defense
• Electronics
2.4 What are the results of a FRACAS?
• Manufacturing
• Telecommunications
• Medical Devices
• Others
Depending on the data collected in a FRACAS process,
users can often generate quantitative results such as failure
rate, mean time between failures (MTBF), mean time between
critical failures (MTBCF), reliability, availability, and other
results. FRACAS outputs also regularly include graphs and
2012 Annual RELIABILITY and MAINTAINABILITY Symposium Cline & Stillwell – 1

eports to identify important summary details visually based
on the data collected.
2.5 How is FRACAS performed?
While specifics will vary, FRACAS processes generally
include these steps:
1. Record the failures or incidents. Critical data associated
with each failure or incident is recorded and stored under
defined procedures, often in a database management
system.
2. Analyze the reported failures or incidents. The root cause
of the failure or incident is identified and stored in the
database management system alongside the original data.
3. Identify necessary corrective action. A corrective action
plan for mitigating the failure or incident is developed,
implemented, and stored in the database management
system.
4. Verify the corrective action. Finally, the effectiveness of
the corrective action is reviewed and recorded in the
database management system and the incident or problem
is closed out per established procedures.
2.6 What are the limitations of FRACAS?
As much as FRACAS can substantially improve products,
services, processes, or computer applications, the difficulty of
efficient application is its inherent limitation. Smart planning
and execution during implementation is paramount, otherwise
the system may fail to manage data efficiently, effectively
identify root causes of problems, or close the FRACAS
process loop correctly.
2.7 Where can I learn more about FRACAS?
As noted in the introduction, many FRACAS resources
are available, including some that define structured
approaches and guidelines for implementation. You can find
several key FRACAS resources listed in the REFERENCES
section.
3. FRACAS BEST PRACTICES
While the general closed loop corrective action process
seems to follow a common sense approach, many factors can
impede its application. Because of the potential challenges, the
following best practices are strongly recommended for use
during FRACAS implementation.
3.1 Set expectations and goals
Prior to deploying the FRACAS corrective action system,
well-defined expectations and goals are essential. These
include the roles and responsibilities of all stakeholders in the
process as well as the objectives of the FRACAS system itself.
All key stakeholders in the process must agree upon the
explicitly defined set of clear expectations and goals. With
these in place, the FRACAS implementation can progress with
clarity of purpose and the system can deploy efficiently and
effectively in line with the defined objectives.
3.2 Involve the stakeholders
The support and involvement of all FRACAS
stakeholders is critical. Many of these stakeholders will
originate within the organization, but customers and/or
suppliers may be involved as well. Involving all appropriate
parties leads to support for gathering sufficient failure data
and unification of a common process across the whole
organization.
3.3 Gain active management involvement
Management involvement and support has a strong
impact on the success of the FRACAS. Active management
participation often results in obtaining and maintaining
necessary funding and resources, and may also provide the
leadership needed to implement and maintain a successful
FRACAS.
3.4 Keep the process simple
The most successful FRACAS solutions are easy to use,
employ user-friendly software tools for automation, and
overall require modest investments in resources and training.
By keeping things simple, active participation from those
outside the quality/reliability is more likely. Ultimately, the
FRACAS must be simple enough for both the expert and
novice to use. Of course, the process design must also allow
for a thorough and effective FRACAS.
3.5 Leverage software tools
Software, either a custom in-house tool or customizable
off-the-shelf solution, is one key way to help to automate the
FRACAS and make it easier to use. Software tools help to
automate data entry, analysis, and output, and provide a
central storage area for FRACAS data and results.
3.6 Provide for efficient data entry and analysis
Entering and analyzing data can be two of the most time
consuming tasks for FRACAS users. Simple web-based forms
can provide for efficient data entry, while automated
calculations, graphs, and reports, along with the ability to
filter the data, can increase the efficiency and effectiveness of
data analysis.
3.7 Supply training
Even when the simplest FRACAS process is
implemented, early training can alleviate the stakeholders’
concerns and foster active participation. As users generate
feedback and the FRACAS evolves, providing additional
training is beneficial for the same reasons.
3.8 Encourage and supply feedback
There are two types of desirable feedback. Feedback from
the users of the FRACAS can help those in leadership roles
focus and streamline the system, while feedback from those in
leadership roles to all participants showcases the results of
their hard work and provides encouragement.
2 – Cline & Stillwell 2012 AR&MS Tutorial Notes

4. CHALLENGES TO EFFECTIVE FRACAS
4.1 Challenge 1: Complex organization interaction
A proper FRACAS process can span many different
functional groups within an organization. Data is contributed
by and/or needs to be made available to the following groups:
• Manufacturing • Engineering
• Operations
• Quality Assurance
• Reliability
• Customer Service
• Sales and Marketing • Field Services
• Testing
• Suppliers
• Failure Review • Maintenance
Board (FRB)
• Others
With all these different departments involved in the
process, their interaction can become complex. Some groups
may want to be included at multiple points. This increases and
complicates the steps required to close an incident.
Consider the following scenario of how this may occur. In
this simple process, a field service representative reports or
logs an incident. Quality Assurance then reviews this incident
and assigns it to the Reliability group to perform a root cause
analysis. The Reliability group 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 request to be involved. For
example, Customer Service believes that they too need to be
part of the corrective action step. Because they directly
interface with the customer, they want to understand and
possibly shape the corrective action response that may occur.
In addition, Sales and Marketing may also be needed to
properly manage a customer’s account, and a Supplier may
desire to be connected with the analysis and corrective actions
that have occurred with its parts. In this situation, the number
of entities involved increases rapidly and the process quickly
becomes convoluted.
This results in a long cycle time between the opening of
an incident and its eventual closing. If the process is too
complex, incidents can even become “forgotten” and never
worked through to completion. Ultimately, the timely
reporting of trends is compromised and, in the worst case, the
entire process breaks down. A typical warning sign of a
breakdown in the process is the phrase, “We just need to
communicate better.” Although this may be true, the process
may simply be too tangled to allow effective communication.
While all parties have the best intentions, the results in such
situations can be disappointing.
4.2 Solution 1: How to overcome the challenge of complex
organization interaction
While working with the stakeholders in the planning
phases of the FRACAS, identify the simplest process or
workflow possible while still keeping key stakeholders
involved at various steps in the process. Whenever possible,
automate the communication. This way, all groups that need
to be aware of an incident’s status can be notified easily.
Assigning a key contact person for each functional group
to attend FRACAS planning meetings and communicate
important information to the group further streamlines
communication.
Regular FRACAS process review meetings involving all
key stakeholders from the various functional groups can be
helpful as well. These meetings can decrease in frequency
over time.
Lastly, make sure that all stakeholders sign off on the
proposed communication plans before the final FRACAS is
deployed to ensure organizational complexity has been
adequately addressed.
4.3 Challenge 2: Lack of prioritized goals
Based on a recent survey conducted by PTC, the top three
reasons for implementing a closed-loop analysis and
corrective action system are:
1. Compliance with customer requirements
2. Gaining insights into the reliability of products
3. Improving the next generation of product design
Depending on the functional groups involved, the relative
importance of these reasons may vary. Consider an example
organization without clearly prioritized goals. A customer
contract specifies that a FRACAS be utilized for a particular
project. The project manager focuses on implementing what
the customer has specifically required, but financial
constraints mean the resources needed to complete a fullfeatured
FRACAS implementation are unavailable.
Project/program managers implement a temporary spreadsheet
or database solution with full intentions of replacing this
solution in the future with a more substantial system, but a
full-featured FRACAS never materializes. Consequently, a
minimal FRACAS becomes the standard resulting in poor
efficiency and a lack of cohesiveness.
Here’s another example: a company believes that a
FRACAS is important to the success of a product, but they see
it as something they will get to in the future. As the product
lifecycle progresses, the company starts to appreciate the
necessity of a FRACAS. By this time, the company is far past
the point of the budgeting and planning processes. Therefore,
a proper implementation does not occur and teams are left
scrambling late in the project to find resources to implement a
FRACAS. Once again, a minimal FRACAS develops.
In a third example, a program manager struggles to
provide a FRACAS implementation while her executive
management has much higher expectations for this system.
They envision that the FRACAS will save the company
money on warranty costs. In addition, the reliability group is
expecting to gather significant data to explore trends and
improve their product’s design over time. Consequently, these
groups expect a full-featured implementation with significant
data gathering, analysis, and reporting capabilities.
Unfortunately, because the program manager has minimal
financial resources, she can only implement a basic FRACAS.
The deployed system is not set up early enough to sufficiently
track information, which limits the data available to executive
management and the reliability group. The system needs more
2012 Annual RELIABILITY and MAINTAINABILITY Symposium Cline & Stillwell – 3

time to gather enough data to perform meaningful analysis.
The resulting implementation falls short of everyone’s
expectations.
What caused the problems in these examples? First, the
groups involved did not discuss and prioritize the list of goals
and expectations. Second, there was not objective FRACAS
leadership across the departments. Finally, effective executive
sponsorship verifying and tracking the goals did not exist.
4.4 Solution 2: How to identify and prioritize goals
To overcome the problems caused by a lack of prioritized
goals, several points must be considered while planning the
FRACAS. First, make sure all stakeholders, including
management, discuss and agree on the goals and expectations
of the FRACAS. Objective FRACAS leadership ensures that
all stakeholders’ goals are considered in the planning. Lastly,
determine which goals can be thoroughly accomplished in the
planned FRACAS, and make sure all stakeholders sign off on
the goal prioritization.
4.5 Challenge 3: Ineffective and inefficient data tracking
As mentioned previously, the key to an effective
FRACAS solution is the gathering and reporting of
meaningful data. This seems to suggest that the more data
gathered on an incident or failure, the better the FRACAS will
be. However, this is not necessarily the case. Too much data
may even prevent users from discovering meaningful trends
because they can’t “see the forest through the trees”.
For example, many legacy FRACAS solutions collect 80
or more fields of information when recording a failure.
Although much of this data is valuable, the ramifications of
gathering that much data can result in several problems.
If it takes customer support personnel recording an
incident five seconds to enter data in each field, they will
spend 400 seconds or 6.7 minutes filling out the form for all
80 fields of data, not including any research time. Soon, many
begin to feel that fully logging a problem is just too timeconsuming.
They start routinely skipping fields and not even
reporting some issues at all.
To prevent this, designers develop input screens that will
easily accept incident information. However, they often use
free-flowing text fields to allow customer support personnel to
type any information that they think is useful. The support
users, though, become confused and do not always know what
to enter. Consequently, they begin to include extraneous or
irrelevant data, sometimes just leaving the field blank. The
resulting “data” becomes unable to support any meaningful
analysis and manually scanning incidents for trends becomes a
tedious chore.
4.6 Solution 3: How to effectively manage data
To avoid the problems of inefficient and ineffective data
tracking, organizations will want to establish functional
procedures before data collection begins. Use of simple,
streamlined forms that store data in a central database is often
the best approach. Taking the time to train the FRACAS users
responsible for data entry helps to ensure that all important
data is entered correctly and efficiently. Reminding those
responsible for the failure data entry of the importance of
capturing the data at the time of failure and the long term
benefits to the organization that result from that timely data
capture is critical. Whenever possible, data capture should be
automated as well.
5. STEPS TO SUCCESSFUL FRACAS IMPLEMENTATION
While this tutorial has discussed three of the most
common challenges during FRACAS implementations, the
issues presented are not all-encompassing. Instead, they
outline typical problems that prevent a company, regardless of
industry, from realizing the dramatic results that can be
achieved with a FRACAS.
Few documented tools and techniques exist to aid the
successful implementation of a closed-loop analysis and
corrective action system. This set of steps for successful
FRACAS implementation is intended to help companies
overcome the obstacles outlined above. The eight step
approach is meant as a framework that can be modified as
needed to fit a specific situation.
5.1 Step 1: Define the goals and success factors
Defining the goals of all intended users and stakeholders
is the foundation for a successful FRACAS implementation.
Every step in the process of establishing a FRACAS will be
based upon this definition. A mistake or misunderstanding at
this step can have negative consequences later. Therefore,
implementations require a commitment to thorough research
and documentation is required as otherwise issues may not
come to light until months later.
To begin this process, hold a series of short team
meetings with each of the groups (as identified in Issue 1) and
the representative stakeholders within the FRACAS process.
Using general facilitation techniques, map out specific goals
or expectations of the FRACAS. Typical goals include
lowering maintenance costs, improving overall reliability, and
improving next generation product design. Be careful of the
common pitfall of moving off of goal establishment and into
detailed requirements. The purpose of this exercise is for each
group to reach a consensus on the priority of its main goals.
Once each group has set its primary goals, call a crossfunctional
meeting. One representative from each group and
an executive and/or management representative should attend
to review, consolidate, and prioritize the goals. During this
same meeting, attach what success realistically means for each
of these goals in concrete terms. For example, if a goal is to
lower maintenance costs, a quantifiable success factor may be
to reduce these costs by ten percent over the next 12 months.
At the conclusion of this meeting, each attendee signs a
document that lists the consolidated and prioritized goals
along with their success factors. This single technique will
immediately highlight the level of agreement between the
groups.
Finally, gain executive approval and support and have one
executive take overall ownership and support of the
implementation. Encourage that person to communicate the
4 – Cline & Stillwell 2012 AR&MS Tutorial Notes

goals and success factors back to the teams.
5.2 Step 2: Define the output
With goals and success factors in place, define the results
or output that each group expects from the FRACAS next.
Based on the goals, each group will decide the outputs they
need from the FRACAS to achieve the previously established
success factors. 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.
A common pitfall is that each group will want as much
output as possible, resulting in a bloated “wish list” that is
difficult to reasonably implement. The purpose of this
exercise, though, is to focus only on the basic necessities for
success based on the goals determined earlier. To make this
clear, map each output requirement back to a goal and success
factor.
5.3 Step 3: Map the Process/Workflow
Through a series of meetings and interviews with
stakeholders, next discuss what process or workflow they
expect to follow. Most of the groups will focus on their own
internal process but may not understand the overall process to
be followed. Based on each group’s individual input and
through additional investigation, develop a draft of a single
consolidated process diagram. Use this to search out
inefficiencies and actively find ways to simplify the process.
Involve the stakeholders in simplifying and coordinating
the process steps between the groups. Question any step that
does not assist with producing the output requirements
established previously. Also, ensure that the overall process
does not grow too complex. Remember that many steps can
slow the working of incidents or decrease the ability to report
trends in a timely manner. Change to the overall process is
inevitable, but this step establishes a workable starting point.
5.4 Step 4: Map data required and input method
Using the process diagram and the output requirements,
determine the minimum data fields required to support the
workflow process at each step. The investment of time in this
step helps avoid collecting data that has no direct purpose and
focuses efforts in the most important areas.
Once the data fields are established, determine how the
user will view the data. One large form with all data fields or
specific forms with tailored fields to simplify understanding
for each group may be preferable. Involve the stakeholders to
understand what they are expecting and why.
Additionally, specify how the input data will be gathered.
Recall from Issue 3 that efficient collection of valid,
meaningful data is paramount. Popular methods include prepopulating
fields based on previous input, drop-down menu
choices, and even bar code entry.
5.5 Step 5: Implement a prototype FRACAS
Now that the goals, success factors, expected output,
workflow process, and entry forms are defined, choose an
implementation approach. A variety of automation tools that
can be used to support a FRACAS exist, though they fall into
three major levels of capability and sophistication.
The first level of software products that support FRACAS
are off-the-shelf, general purpose tools such as spreadsheet
and personal database programs. Microsoft Excel and
Microsoft Access are two popular options in this category.
They are relatively inexpensive and can be used for a variety
of purposes outside the FRACAS realm. In addition, many
companies already have these tools available. However,
general purpose tools have limited capacity to handle large
amounts of data and may not support data sharing between
multiple users. Also, these tools do not intrinsically support
FRACAS calculations and graphing. Furthermore, this
approach may require internal support to create and maintain
the custom application.
The second level of FRACAS tools includes Workgroup
applications that specifically provide FRACAS support for a
small group of users and moderate amounts of data. FRACAS
Workgroup tools can typically support multiple users,
workflow capabilities, and FRACAS calculations. They also
may connect with other Reliability and Maintainability tools
for more detailed analysis.
The third level of FRACAS tools includes Enterprise
applications that provide intrinsic FRACAS support, including
workflow, calculations, graphs, as well as additional
capabilities for handling large amounts of data and many
users. Enterprise FRACAS tools typically support multiple
means of data entry and reporting, including internet browser
support that allows them to support a large, distributed user
base. Enterprise FRACAS tools also often integrate with other
Enterprise systems, including ERP/PDM, Mail, Workflow,
and Directory Services.
For both Workgroup and Enterprise FRACAS tools, a
continuum of product offerings is available. Customdeveloped
solutions, integrated custom tools, complete
commercial off the shelf (COTS) options all exist on the
market. With today’s technologies and FRACAS product
offerings, custom FRACAS solutions cannot easily be
justified. Custom development is usually the most expensive
option because of the time and resources required to design,
implement, support, and grow a single FRACAS
implementation. Given that FRACAS implementations
typically have common functional and data requirements, a
configurable COTS solution, which allows changes without
programming skills, is a more cost effective approach to
deploying a FRACAS.
To select the appropriate level of a FRACAS tool, users
must examine their immediate needs in relation to future
plans. Factors in the selection criteria must include a firm
understanding of the functionality or capabilities required, the
number of potential users, and the data storage necessities
over time. These decisions may seem daunting, but careful
2012 Annual RELIABILITY and MAINTAINABILITY Symposium Cline & Stillwell – 5

selection of the approach is imperative. To validate the
decision, implement a prototype FRACAS based on the
selected approach.
5.6 Step 6: Accept feedback and modify FRACAS
At this stage, reconvene the stakeholders and start testing
the prototype system. Does the previously defined workflow
process work in this environment? Can the data be efficiently
entered into the system? Can the expected outputs be
generated? Is the system easy to use and understand?
Most importantly, revisit the goals and success factors.
Does the system meet these goals? Will the success factors be
met? Particular areas will likely need additional tweaking or
reworking. This is the time to accept constructive feedback
and make the necessary modifications.
Before proceeding, gain signoff and approval from all
stakeholders. With their continued involvement, the chances
of gaining their support is high, and they can be the best
advocates for the project when proceeding to the next step —
general rollout.
5.7 Step 7: Rollout and train
Companies can take several different approaches for
general rollout, and each method has its own set of advantages
and disadvantages.
The “Big Bang” approach allows all users on the system
at once. This approach is typically used where time is short.
When all the users begin to use the system at the same time,
many problems are likely. With so many users involved,
seemingly minor issues can become major obstacles.
Although this approach can work, it requires significant
planning and coordination. It should only be considered when
absolutely necessary.
Alternatively, most companies prefer a phased approach
in which several groups at a time are trained and brought
online. In this case, unforeseen issues can be addressed
without involving the entire user base. Additionally, the
implementation and training teams can adapt to provide better
support for later groups. Typically, the more individualized
attention ultimately gains more support and acceptance from
the general user base.
Training is extremely important, especially when typical
FRACAS processes involve users of many different areas of
interest and levels of expertise. When users understand what is
expected of them and are empowered by training to use the
tools given to them, the system has a much greater chance for
acceptance and success.
5.8 Step 8: Continue to change
Continual change should be expected for the FRACAS
system based on user feedback regarding what works and
what needs improvement. As business objectives and
processes evolve, the FRACAS needs to adapt and support
these developments. As a result, active management needs to
accept and validate changes to the FRACAS in relation to the
original high-level goals. Through this oversight, a highperformance,
functional system will remain viable for many
years.
6. PRACTICAL APPLICATION
This section presents several case studies to address the
practical application of FRACAS. In some instances the
FRACAS was implemented as a result of a customer
requirement and in others as an internal decision by the
organization. They represent a range of successful FRACAS
implementations based on systematic steps and the FRACAS
best practices described above.
6.1 Case Study #1: Traditional FRACAS
A manufacturer in the aerospace industry instituted and
continues to use a traditional FRACAS. A desire for reliable
products as well as a customer requirement drove the
implementation. Management established various goals,
especially:
• Capture of incident or failure information in a closed loop
system.
• Provide periodic reports to the customer with the closedloop
resolution for each incident.
The required outputs include metrics like MTBF. Reports
are generated as well including Failure Summary, Failure
Analysis, and Reliability reports.
For workflow, the process follows a series of defined
steps: Incident Entry, Quality Review, Failure Investigation,
Root Cause Analysis, Corrective Action, Failure Review
Board, and Closeout.
Data inputs to the FRACAS include data from the
previously implemented database system as a starting point.
Subsequent data is entered manually using customized tables
and forms for each workflow step.
Two programs initially deployed the prototype FRACAS.
During prototype review, necessary additional reports,
calculations and alerts were identified and the FRACAS was
updated to support the added requirements.
The solution provider supplied training to key users for
the FRACAS on both programs.
Since the initial implementation, the FRACAS has
changed slightly to better suit the organization’s needs.
Modifications are ongoing as new needs arise.
This FRACAS has proven to be a success thanks to the
systematic planning approach used during deployment.
6.2 Case Study #2: RMA System
A supplier to the aerospace and defense industry
implemented and continues to use a FRACAS to manage and
track their return material authorization (RMA) process.
The goals and success factors for the FRACAS are as
follows:
• Efficiently track and manage the RMA process.
• Provide procedures and tools to gather reliability data
from various groups, including customer service, repair
and overhaul, original equipment, and other service
centers.
• Attain reliability data to help with quoting expected
maintenance costs.
6 – Cline & Stillwell 2012 AR&MS Tutorial Notes

• Identify reliability and maintainability metrics as possible
inputs to other reliability analyses.
Numerous outputs were identified as required, including a
range of reports. Example reports include:
• Incident Report by Serial Number
• Failure Modes by Part Number
• RMA Status Report
The organization defined its workflow steps for the RMA
process as: Field Service Entry, RMA Creation, Return Item
Review, Preliminary Inspection Evaluation, Test Evaluation,
Disassembly Evaluation, Engineering Evaluation, Final
Inspection, and Closeout.
Legacy data from the existing RMA database was
imported to the new FRACAS with plans to input new data
manually going forward.
Based on the goals, available inputs, and desired outputs,
a prototype FRACAS was created and initially deployed to
power users. During the prototype review, users were satisfied
with the FRACAS as implemented.
Initial key users of the FRACAS received training from
the software vendor in a “train-the-trainer” program. These
users then provided training to all other personnel before
rolling the new FRACAS for RMA across the organization.
A systematic step-by-step process allowed for the creation
of a FRACAS process and system that met all requirements
for the RMA.
6.3 Case Study #3: Business Intelligence System
A global information technology corporation instituted
and continues to use FRACAS as a business intelligence
system to support better data mining and ultimately improved
business decision-making. The FRACAS provides one means
of gathering historical, current, and predictive views of
business operations related to testing and fielded product
performance. Prior to reorganization of the testing and fielded
product data capturing and analysis procedure, users entered
data into a customer support system. Then, for critical cases,
users streamlined the data for consistency and readied it for
analysis by design engineers. These data mining processes
were difficult and time-consuming and the company required
a new solution.
The goals and success factors for the FRACAS are as
follows:
• Integrate previously disjoint data sets across the product
lifecycle to create single source of truth for failure
analysis.
• Use actual reliability and availability data to refine targets
from generation to generation and effectively track
reliability growth.
• Track failures during testing to identify potential failure
modes, easily recognize trends, and determine metrics,
including MTBF.
• Perform fielded product performance analysis to manage
outing information and reporting.
The organization identified many outputs, including
numerous graphs and reports. The graphs and reports provided
a view of data trends over multiple years with comparisons to
previous generations of products in an instant dashboard view.
Disparate requirements for testing and tracking field
failures required multiple workflows. For example, for fielded
product failures, the workflow steps include Problem
Definition, Root Cause Analysis, Corrective Action, and
Closeout.
The new tool imported legacy data from the previous
customer support system to streamline the data mining
processes. Going forward, the customer support team will
input their data directly to the FRACAS via the carefully
designed forms.
Based on the goals, available inputs, and desired outputs,
a prototype FRACAS was created and initially deployed to
power users. After gathering user feedback, necessary changes
were implemented, including additional graphs and reports to
let both engineers and management quickly acquire up-to-date
information from the FRACAS.
The software vendor team who implemented the
FRACAS trained power users. These power users, in turn,
trained the remaining user base on the role-specific features
and functions. Following training, all customer support
personnel, design engineers, and management began using the
new tool.
A systematic step-by-step process facilitated the creation
of a FRACAS system to improve the efficiency of data mining
and other analysis, which provides critical information driving
advantageous business decisions for the firm.
6.4 Case Study #4: Non-Traditional FRACAS
A manufacturer of highly specialized, leading edge
industrial components implemented and continues to use a
FRACAS to track details related to raw materials inspection.
The primary goal and success factor for the FRACAS is
to provide the process and system to track data pertaining to
incoming product, work-in-progress, and final inspection. The
required system allows inspectors to enter the results of their
material reviews and track progress of lots. The firm also
anticipated that the FRACAS would help to determine metrics
such as the first pass yield and percent scrapped.
The implementation team identified many outputs
including various reports. Example reports include:
• First Pass Yield Report
• Scrap Report
• Action Report
The workflow for the process was identified and includes
three key inspection steps: Incoming, Work-in-Progress, and
Final.
As no legacy data was easily available for the new
FRACAS for raw materials inspection, all data is entered
manually to the FRACAS using custom forms and tables.
With the goals, inputs, and outputs in place, the software
vendor built the prototype FRACAS for initial deployment to
power users. After gathering feedback, the vendor
implemented certain changes, including the addition of alerts
to automate notifications based on other entered data and
better control for dates associated with acceptance or rejection
of the materials inspected.
2012 Annual RELIABILITY and MAINTAINABILITY Symposium Cline & Stillwell – 7

The vendor also trained the initial key users of the
FRACAS, who then provided subsequent training to all
personnel. The new FRACAS for raw materials inspection
was then rolled out corporate wide.
A systematic step-by-step process allowed for the creation
of a FRACAS process and system to meet requirements for
the raw materials inspection system.
6.5 Case Study #5: CAPA
A manufacturer of highly specialized, leading edge
industrial components implemented and continues to use a
FRACAS to accommodate their Corrective Action Request
(CAR)/Preventative Action Request (PAR) process.
Key goals and success factors for the FRACAS are as
follows:
• Efficiently track and manage the CAR/PAR process.
• Track metrics like time to close each CAR/PAR.
• Incorporate alerts to notify of overdue actions.
Various outputs were identified, including reports and
graphs. Example reports and graphs include:
• Average Time to Close CAR/PAR
• Issues by Source
The FRACAS team defined the workflow steps for the
CAR/PAR process as: CAR/PAR Entry, Review, Root Cause,
Action Taken, Effectiveness, and Closeout.
The new tool imported legacy data from the existing
CAR/PAR system, and new data will be input manually going
forward.
Based on the goals, available inputs, and desired outputs,
a prototype FRACAS was created and initially deployed to a
small group of users familiar with the process. Updates to
further streamline the forms for more efficient data entry,
among other changes, were implemented based on user
feedback.
The vendor trained users of the CAR/PAR FRACAS
before the company rolled out the new tool to replace the
previous system.
Again, a systematic step-by-step process was critical for
the creation of a FRACAS to meet requirements for the
CAR/PAR process.
7. CONCLUSIONS
Closed loop corrective action systems like FRACAS
provide an effective process for controlling, tracking, and
analyzing failures. They can lead to improvements in quality,
reliability, and productivity while simultaneously reducing
costs. When working to implement FRACAS, be aware of the
challenges that may arise. Keep best practices in mind and,
like the organizations described in the case studies, follow the
recommended eight step procedure for successful FRACAS
implementations.
8. REFERENCES
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.p
df
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. RAC: 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 nonstandardized
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.
10. Directive-Type Memorandum (DTM) 11-003 –
Reliability Analysis, Planning, Tracking, and Reporting,
March 2011, US DoD.
8 – Cline & Stillwell 2012 AR&MS Tutorial Notes