White Paper

Organizational best practices for FRACAS implementation

MANAGEMENT CONSIDER ATIONS WHEN DEVELOPING AND DEPLOYING A CORRECTIVE ACTION SYSTEM

Introduction

To produce high quality products in an increasingly competitive marketplace,

the ability to efficiently discover, track, and correct incidents or failures
found during product development, testing, and operations is crucial. This
need spans all industries and classifications, including hardware and soft-
ware production, process management, and services in both government
and commercial sectors. A survey conducted by the Reliability Information
Analysis Center (RiAC) cited that companies view this subject, most com-
monly referred to as FRACAS (Failure Reporting, Analysis, and Corrective
Action System) to be one of their top two most important reliability tasks.

Manufacturers and service providers have employed a variety of methods

for tracking product failures and managing corrective actions. These can
range from so-called manual approaches using paper-based intake meth-
ods and handwritten forms, to a combination of electronic spreadsheets
and personal databases, to large enterprise systems that affect hundreds or
thousands of customers, suppliers, and engineers worldwide.

Nevertheless, the implementation of a cost-effective FRACAS that produces

an end result of more reliable products remains a complex and challeng-
ing undertaking. Decades worth of publicly available guidelines from the
United States Department of Defense (DoD) to NASA fail to address many
of the practical complications that exist. These complications are neither
process-related nor technical in nature, but stem from each companys or-
ganizational structure, goals, and expectations.

Page 1 of 9 | Organizational best practices for FR ACAS implementation PTC.com


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 applica-
tion. 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 ana-
lytical capabilities, allowing organizations to track key system
metrics that include Failure Rate, MTBF, MTTR, Availabil-
ity, Cost, and user-defined calculations, among many others.
Built-in reporting and graphing features mean these met-
rics 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 many industries, including
aerospace, automotive, defense, electronics, manufac-
turing, 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 let-
ter 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?
While the specifics of how each FRACAS process is imple-
mented will vary, a FRACAS usually includes the following
steps:
Record the Failures or Incidents: Using a database
management system and an established procedure,
critical data associated with each failure or incident is
recorded, and the process is initiated
Analyze the Reported Failures or Incidents: Using the
same database management system into which the failure
or incident data was entered, established procedures are
used to determine and record the root cause of the failure
or incident
Page 2 of 9 | Organizational best practices for FR ACAS implementation
White Paper
Incident Initiation
Closed Loop
Review Corrective Action Analysis
Process
Corrective Action
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.
Identify Necessary Corrective Action: Using the same
database management system to track its development,
implementation, and result, a corrective action plan must
be developed and implemented to reduce or eliminate the
recurrence of the failure or incident
Review and Verify the Corrective Action: The effectiveness
of the corrective action must be reviewed and recorded,
using the same database management system, and the
incident closed out per established procedures
What are the limitations of a FRACAS?
Although implementing a FRACAS can be an excellent way
to improve a product, service, or process, its inherent limita-
tion is that it can be difficult to apply effectively. As with any
technique, it is critical that a FRACAS process is well planned
and efficiently executed; otherwise, the system could fail to
manage data effectively, fail to identify the root causes of
problems, or fail to close the loop in the FRACAS process.
For that reason, the Windchill Quality Solutions (formerly
Relex) team, which has deployed numerous FRACAS systems
in organizations throughout a variety of industries, presents
the following practical guidelines for managers and others
responsible for the development and implementation of a
successful FRACAS.
As with any technique that is applied across an
organization, it is critical that a FRACAS process
is well planned and efficiently executed.
PTC.com

2. Best practices for a FRACAS implementation.
While the general closed loop corrective action process
seems to follow a common-sense approach, many factors
can make the application of a FRACAS difficult. Because of
these potential challenges, the following best practices are
strongly recommended for use during FRACAS implementations.
Set Expectations and Goals
Prior to deploying the FRACAS corrective action system, it
is essential to set the expectations and goals of the system.
Identifying the purpose and goals of the FRACAS, as well as
identifying the roles and responsibilities of all stakeholders in
the process, is essential. It is also critical that all stakeholders
in the process understand and agree upon the established
expectations and goals of the system.
Involve the Stakeholders
It is of the utmost importance that all stakeholders in the
FRACAS are involved in and supportive of the process. The
stakeholders will include many within the organization and
may also include customers and/or suppliers. By involving all
stakeholders, support may be gained for acquiring sufficient
failure data, and a common process can be achieved across
the whole organization and outside entities.
Gain Active Management Involvement
Management involvement and support can significantly impact
the success of the FRACAS. Active management participation
often results in obtaining and maintaining necessary fund-
ing and resources, and may very well provide the leadership
needed to implement and maintain a successful FRACAS.
Keep the Process Simple
The most successful FRACAS processes are easy to use, employ
user-friendly software tools to automate the workflow, and re-
quire 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.
Page 3 of 9 | Organizational best practices for FR ACAS implementation
White Paper
A survey conducted by the Reliability Information
Analysis Center (RiAC) cited that companies view a
FRACAS to be one of their top two most important
reliability tasks.
Leverage Software Tools
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.
Provide for Efficient Data Entry and Analysis
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 effi-
cient 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 ac-
tive 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.
PTC.com
 White Paper

3. Apply best practices to common challenges. at multiple points throughout the workflow. This increases
and complicates the steps required to close out an incident.
The best way to observe the benefits of these best practice Consider the following scenario: A simple process is defined
approaches is to see the ways in which they help overcome such that a field service representative reports or logs an
the challenges that organizations commonly experience when incident. Quality Assurance reviews this incident and then
implementing a FRACAS. Each of the following Challenge / assigns it to the Reliability group to perform a root cause
Solution scenarios demonstrates the benefits of a best practice analysis. The Reliability group then recommends a correc-
approach to FRACAS implementation: tive action that the Engineering group implements. Finally,
the Failure Review Board approves the corrective action and
Challenge 1: Complex Organizational Interactions
closes out the incident.
A proper FRACAS process can span many different functional
Over time, additional groups may request to be involved. For
groups within an organization. Data is contributed by and /or
example, Customer Service believes that they too need to be
needs to be made available to the following groups:
involved at the corrective action step in the process. Because
Manufacturing Quality Assurance they directly interface with the customer, they want to under-
Operations Customer Service stand and possibly shape the corrective action response that
Reliability Field Services may occur. Sales and Marketing may also need to be involved
Sales and Marketing Suppliers to properly manage a customers account. And, a Supplier
may wish to be involved in the analysis and corrective actions
Testing Maintenance
that have occurred with its parts. Very quickly, the number of
Failure Review Board (FRB) Management
groups involved increases, and the process becomes more
Engineering Others complex. This may result in a long cycle time between the
With all of these different groups involved in the process, opening of an incident and its eventual closing. If the process
the interaction across and between various groups can be- is too complex, incidents can become forgotten and never
come quite complex. Some groups may need to be included worked through to completion.

Operators, Suppliers, Field Services, Returns,

Maintenance, Customer Service

Failure Review Board (FRB),

Quality Assurance, Testing,
QA Management
Reliability Engineering
Discovery Reporting

Initiation
Close-Out Evaluation

Review Web-Based
Verification Analysis Investigation
FRACAS

Corrective Action Analysis

Implementation

Approval Planning

Manufacturing, Operations,
Logistics Engineers, Design Engineers

Involving all stakeholders in the FRACAS workflow: Each group in an organization has different roles in the FRACAS. The goal in designing a FRACAS is to
accurately capture each groups role and to ensure that software processes carry this workflow through to each required member automatically. Web-based
communication technology like that found in Windchill FRACAS can help ensure that every incident is addressed: effectively "closing the loop".

Page 4 of 9 | Organizational best practices for FR ACAS implementation PTC.com


Solution 1: Overcoming the Challenge of Complex Interactions
While working with the stakeholders in the planning phases
of a FRACAS, identify the simplest workflow possible while
still keeping everyone involved at key steps in the process.
Whenever possible, automate communication. This way, all
groups that need to be aware of the status of an incident can
be notified easily. It is generally helpful if each functional
group has a key contact person who may attend FRACAS
planning meetings and communicate important information
to the functional group.
Regular FRACAS process review meetings involving all key
stakeholders from the various functional groups can be help-
ful. These meetings can decrease in frequency over time. And,
of course, before the final FRACAS is deployed, make sure
that all stakeholders have signed off on the proposed com-
munication plans to ensure you can overcome the challenge
of complex organization interaction.
Challenge 2: A Lack of Prioritized Goals
Consider the following scenario: a customer contract
specifies that a FRACAS system be utilized for a particular
project. But due to financial constraints, the resources are
lacking to complete a fully featured FRACAS implementation.
Project managers implement a temporary Microsoft Excel-
based or Microsoft Access-based solution, fully intending
to replace this solution in the future with a more substantial
system. But a fully featured FRACAS never materializes. Con-
sequently, a minimal FRACAS system becomes the standard,
resulting in poor efficiency and a lack of cohesiveness.
In another example, a company believes that a FRACAS is
important to the success of a product but sees it as something
they will get to in the future. As the product lifecycle progresses,
the company gains an appreciation for the necessity of a
FRACAS. By this time, the company is far past the point of
the budgeting and planning processes. Therefore, a proper im-
plementation does not occur and teams are left scrambling
late in the project to find resources to implement a FRACAS.
Once again, a minimal FRACAS system is implemented.
In a third example, an executive management team has high
expectations for the system. They envision that the FRACAS
will save the company money on warranty costs; while the
reliability group expects significant data that can be used to
discover trends and improve a products design over time.
Unfortunately, because the program manager is provided with
minimal financial resources, she can only implement a basic
FRACAS. The system is not deployed early enough to sufficiently
Page 5 of 9 | Organizational best practices for FR ACAS implementation
White Paper
track information, which limits the data available to execu-
tive management and to the reliability group. It will take
some time for the data to be complete enough to perform a
meaningful analysis. The result is a system that falls short of
everyones expectations.
What caused the problems in these examples? First, goals
and expectations from the various groups were not discussed
and prioritized in relation to each other. Second, there was
no objective FRACAS leadership across the groups. And, finally,
effective executive sponsorship verifying and tracking the
goals was nonexistent.
Solution 2: Overcoming a Lack of Prioritized Goals
To overcome the problems that result from the lack of priori-
tized goals, use best practice principles. First, the goals and
expectations of the FRACAS should be discussed and agreed
upon by all stakeholders, including management. It is also
helpful to obtain objective FRACAS leadership so that all stake-
holders goals may be considered in the planning. Also, deter-
mine which goals can be accomplished well by the FRACAS as
it has been designed, and make sure all stakeholders have
signed off on and agreed to these planned and prioritized
goals.
Challenge 3: Ineffective Data Tracking
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 neces-
sarily 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 prob-
lem. 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 inci-
dent information.
However, as is often done, designers utilize free flowing text
fields to allow customer support personnel to type any in-
formation that they think is useful. The personnel can then
PTC.com

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 track-
ing, 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 effi-
ciently. 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.
4 Steps to a successful FRACAS.
These three common challenges to FRACAS implementations
are by no means all-encompassing, but they do outline typical
problems that prevent companies from realizing the dramatic
results that can be achieved with a successful FRACAS. To help
avoid these common obstacles from the outset of planning a
FRACAS, the following eight steps are recommended:
Step 1: Define the Goals and Success Factors
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 consequenc-
es 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 expecta-
tions for the FRACAS. Typical goals include lowering mainte-
nance 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.
Page 6 of 9 | Organizational best practices for FR ACAS implementation
White Paper
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 out-
lined in the groups agreed-upon goals. Typically, the results
are stated in terms of calculations, charts, graphs, and re-
ports. 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, however,
is to focus on what is absolutely necessary for success based
on previously established goals. To help with this, map each
output requirement back to a goal and success factor.
Step 3: Map the Process Workflow
Through a series of meetings and interviews with stakeholders,
discuss what process or workflow they expect to follow. Most of
the groups will focus on their own internal processes but may
not understand the overall process as it relates to all groups
with a role in FRACAS. Based on each groups individual input
and through additional investigation, develop a consolidated
process diagram. Using this diagram, search out inefficiencies
and actively find ways to simplify the process.
Involve stakeholders in simplifying and coordinating the pro-
cess steps between the groups. Question any step that does
not produce the output requirements established previously.
Also, work to ensure that the overall process is not too lengthy
or complex. Remember that many steps can slow the resolu-
tion of incidents or decrease the ability to report trends in a
timely manner. Changes to the overall process are inevitable,
but this step establishes a workable starting point.
Streamlining Data Entry and Data Tracking: By entering a single identifier,
such as the serial number of a returned product, as shown above, Windchill
FRACAS uses lookup table functionality to autopopulate the remaining fields.
PTC.com
 White Paper

Step 4: Map the Required Data 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. 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 under-
stand 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 col-
lect 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
steps, making it easy to start from a predefined solution or
configure it in a few easy steps to suit organizational needs.
This solution helps companies avoid the expensive, time-
consuming, and often intractable results of hiring specialized
consultants to create a customized solution. Easily configurable
templates can be continuously adapted as your FRACAS pro-
cess changes and develops, without the need for specialized
programming skills.
Whether selecting a small group collaboration tool or a
large, Enterprise-wide FRACAS application, examine the or-
ganizations immediate needs in relation to its future plans.
It is important to consider the functionality required by your
specific FRACAS process, the number of potential users, and
the data storage requirements both at the projects inception
and well into the future. To validate the decision, implement a
prototype FRACAS based on the selected approach.
Customer
Service
Product Customer
Warranted? NO Paying? NO
Takes Call
YES YES

Receive Goods/
Assign RMA
Now that the goals, success factors, expected output, work- Initial Inspection
flow process, and entry forms are defined, you are ready to
choose an implementation approach. General purpose tools,
Replacement
such as spreadsheets and personal database programs like to Customer
Microsoft Excel or Microsoft Access, are limited in their ca- End

pacity to handle large amounts of data and may not support Assign
the sharing of data between multiple users. FRACAS calcula- Work
Orders
tions and graphing are not intrinsically supported by general Perform Analysis
- Identify Trends
purpose software, and no functionality is included to gener- - Identify Problems
Repair - Analyze Reliability
ate workflow notifications automatically and ensure a closed Equipment
Identify
Initiate ECO
Root Cause
loop process. In addition, this approach may require internal Process

support to create and maintain a customized application.

Determine a workflow for the FRACAS: Ensure that roles of all stakeholders
Based upon the size of the workgroup, a small group collab- involved in the process are properly represented, as in this RMA (Return
oration tool or a large, Enterprise-wide application may be Materials Authorization) workflow.

required. Windchill FRACAS offers solutions for both sizes of

workgroups, including workflow capabilities, built-in FRACAS
calculations, and seamless integration with other reliabil-
ity, maintainability, and risk analysis applications to effect a
more detailed analysis. Enterprise applications provide ad-
ditional tools for handling large amounts of data, including
Web-based tools for streamlined data entry, workflow alerts
delivered via e-mail, support for Microsoft Active Directory
Services, and many simultaneous users.
Windchill FRACAS also supports commercial-off-the-shelf
(COTS) templates with preconfigured FRACAS workflow
Step 6: Accept Feedback and Modify the FRACAS
Once the prototype FRACAS has been implemented, with suf-
ficient time for users to test and get a feel for it, it is important
to bring the stakeholders back together and evaluate the re-
sults of the prototype system. Is this environment effective
for the previously defined workflow process? Is data entry
efficient and streamlined? Can the expected outputs be
generated? Is the system easy to use and understand?

Page 7 of 9 | Organizational best practices for FR ACAS implementation PTC.com


Most importantly, revisit the goals and success factors. Does
the system fulfill these goals? Will the success factors be
met? It is very likely that you will find areas of the system
that need to be reworked. This is the time to accept con-
structive feedback and make the necessary modifications.
Before proceeding, gain signoff and approval from all
stakeholders. You will need their continued support to make
the implementation a success.
Step 7: Rollout and Training
Although it may be necessary, when time is of the essence,
to allow all users onto the system at once, this approach is
likely to have more issues. With so many users starting out
at the same time, seemingly minor issues can become major
obstacles. Although this approach can work, it requires sig-
nificant planning and coordination. It should only be con-
sidered when absolutely necessary. Alternately, a phased
approach whereby several groups at a time are trained
and then brought online is the preferred implementation
method. By using this approach, any unforeseen issues can
be addressed without involving the entire user base. Addi-
tionally, the implementation and training teams are able to
adapt to these issues and provide better support for later
groups.
Typically, the more individualized attention and training giv-
en to users, the better their acceptance and support of the
FRACAS will be. Training is extremely important, especially
when typical FRACAS systems involve users of many differ-
ent areas of interest and levels of expertise. When users un-
derstand what is expected of them and are empowered by
training to use the FRACAS, the system has a much greater
chance for acceptance and success.
Step 8: Continue to Change and Adapt the FRACAS
One of the most important aspects of a FRACAS is to learn
what works and what can be improved. Based on this feed-
back, continual change can and should be expected. As
business objectives and processes change, the FRACAS
needs to be adapted to support these changes. It is impor-
tant, however, that the FRACAS is actively managed to not
only accept these changes but to also validate these changes
in relation to the overall goals that were initially established.
Page 8 of 9 | Organizational best practices for FR ACAS implementation
White Paper
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.
6 About the authors.
Daniel Jacob is an ASQ Certified Reliability Engineer with
an extensive and diverse background in engineering, project
management, technical sales, and market development. As
Business Development Director for Windchill Quality Solutions,
Mr. Jacob works with customers to determine the software
and processes necessary to meet corporate and program
objectives.
Jennifer Akers is an ASQ Certified Reliability Engineer
responsible for all Windchill Quality Solutions training services.
As a Senior Application Engineer and Curriculum Developer,
Jennifer has developed numerous training courses that focus
on both the theoretical foundations and practical applications
of Windchill Quality Solutions software tools.
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
PTC.com
 White Paper

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 Windchill FRACAS, please visit:

PTC.com/products/windchill/FRACAS.

2011, 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 Logo,
Windchill, 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 property of their respective owners. The timing of any product release,
including any features or functionality, is subject to change at PTCs discretion.

6528FRACASBestPracticesEN0411

Page 9 of 9 | Organizational best practices for FR ACAS implementation PTC.com