Sie sind auf Seite 1von 9

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


White Paper

1. What is a FRACAS?
Incident Initiation
A FRACAS, or Failure Reporting, Analysis, and Corrective
Action System, is a closed loop system used to improve the Closed Loop
reliability of a product, service, process, or software applica- Review Corrective Action Analysis
tion. The closed loop in a FRACAS refers to the systematic Process
manner in which every issue that is reported is addressed,
ensuring that no failure or incident is missed. The need for Corrective Action
a FRACAS spans all industries and classifications, including
hardware, software, process management, and services in An effective FRACAS ensures that all failures or incidents proceed through
both government and commercial sectors. Software-based these four major steps: closing the loop to ensure that no failure or incident
FRACAS processes offer the added benefit of built-in ana- is missed.
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- Identify Necessary Corrective Action: Using the same
rics can be trended with regards to time, severity, and many database management system to track its development,
other factors. In addition, the effectiveness of the FRACAS implementation, and result, a corrective action plan must
itself can be monitored by tracking the overall improvement be developed and implemented to reduce or eliminate the
of the system as a result of the FRACAS. recurrence of the failure or incident

FRACAS is used extensively in many industries, including Review and Verify the Corrective Action: The effectiveness
aerospace, automotive, defense, electronics, manufac- of the corrective action must be reviewed and recorded,
turing, telecommunications, medical devices, and others. using the same database management system, and the
While a corrective action system is commonly referred to as incident closed out per established procedures
a FRACAS in many government-related initiatives, it may be
referred to by other names in other industries, including a What are the limitations of a FRACAS?
CAPA (Corrective and Preventive Action) System, Corrective
Although implementing a FRACAS can be an excellent way
Action System, Quality System, and others where the first let-
to improve a product, service, or process, its inherent limita-
ter of the FRACAS acronym is replaced by a P for Problem
tion is that it can be difficult to apply effectively. As with any
(PRACAS), an I for Incident (IRACAS), or a D for Data or
technique, it is critical that a FRACAS process is well planned
Defect (DRACAS). In addition, FRACAS can be applied for
and efficiently executed; otherwise, the system could fail to
RMA (Return Materials Authorization or Return Merchandise
manage data effectively, fail to identify the root causes of
Authorization) processes and various other quality assurance
problems, or fail to close the loop in the FRACAS process.
processes, like bug tracking, call centers, and the like.
For that reason, the Windchill Quality Solutions (formerly
How is a FRACAS performed?
Relex) team, which has deployed numerous FRACAS systems
While the specifics of how each FRACAS process is imple- in organizations throughout a variety of industries, presents
mented will vary, a FRACAS usually includes the following the following practical guidelines for managers and others
steps: responsible for the development and implementation of a
successful FRACAS.
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 As with any technique that is applied across an
same database management system into which the failure organization, it is critical that a FRACAS process
or incident data was entered, established procedures are is well planned and efficiently executed.
used to determine and record the root cause of the failure
or incident

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


White Paper

2. Best practices for a FRACAS implementation.

While the general closed loop corrective action process A survey conducted by the Reliability Information
seems to follow a common-sense approach, many factors
Analysis Center (RiAC) cited that companies view a
can make the application of a FRACAS difficult. Because of
these potential challenges, the following best practices are
FRACAS to be one of their top two most important
strongly recommended for use during FRACAS implementations. reliability tasks.

Set Expectations and Goals

Prior to deploying the FRACAS corrective action system, it Leverage Software Tools
is essential to set the expectations and goals of the system.
Identifying the purpose and goals of the FRACAS, as well as Utilizing available software tools is one key way to help
identifying the roles and responsibilities of all stakeholders in automate the FRACAS and make it easier to use. Software
the process, is essential. It is also critical that all stakeholders tools can help automate data entry, data analysis, and data
in the process understand and agree upon the established output, while providing a central storage area for critical
expectations and goals of the system. FRACAS data and results.

Involve the Stakeholders Provide for Efficient Data Entry and Analysis

It is of the utmost importance that all stakeholders in the The collection and analysis of FRACAS data can be two of
FRACAS are involved in and supportive of the process. The the most time-consuming tasks for a FRACAS. Easy to use
stakeholders will include many within the organization and Web-based forms are often a great way to provide for effi-
may also include customers and/or suppliers. By involving all cient data entry. Automated calculations, graphs, and reports,
stakeholders, support may be gained for acquiring sufficient along with the ability to filter data, can increase the efficiency
failure data, and a common process can be achieved across and effectiveness of data analysis.
the whole organization and outside entities.
Supply Training
Gain Active Management Involvement
Even when a simple FRACAS process is implemented, providing
Management involvement and support can significantly impact comprehensive training early in the implementation process can
the success of the FRACAS. Active management participation alleviate the concerns of those involved and help make them ac-
often results in obtaining and maintaining necessary fund- tive participants in the FRACAS. As feedback is accepted and
ing and resources, and may very well provide the leadership the FRACAS evolves, it is a good idea to provide additional
needed to implement and maintain a successful FRACAS. training in the more advanced technical and software-related
aspects of the process.
Keep the Process Simple
Encourage and Offer Feedback
The most successful FRACAS processes are easy to use, employ
user-friendly software tools to automate the workflow, and re- Encouraging feedback from the users of the FRACAS can
quire modest investments in resources and training. By keeping help those in leadership roles adjust the FRACAS to become
things simple, it is more likely that those outside the quality/ more efficient and effective. Likewise, providing feedback to
reliability functions will participate as required. Ultimately, it is all participants, including feedback in the form of outputs
important that the FRACAS be simple enough to work well for from the system, can be encouraging, as it can demonstrate
both the expert and novice. Of course, it is also important that the positive, tangible results of the efforts of all who have
the process is designed to allow for a thorough and effective adapted to and successfully implemented the FRACAS.
FRACAS.

Page 3 of 9 | Organizational best practices for FR ACAS implementation 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


White Paper

Solution 1: Overcoming the Challenge of Complex Interactions track information, which limits the data available to execu-
tive management and to the reliability group. It will take
While working with the stakeholders in the planning phases some time for the data to be complete enough to perform a
of a FRACAS, identify the simplest workflow possible while meaningful analysis. The result is a system that falls short of
still keeping everyone involved at key steps in the process. everyones expectations.
Whenever possible, automate communication. This way, all
groups that need to be aware of the status of an incident can What caused the problems in these examples? First, goals
be notified easily. It is generally helpful if each functional and expectations from the various groups were not discussed
group has a key contact person who may attend FRACAS and prioritized in relation to each other. Second, there was
planning meetings and communicate important information no objective FRACAS leadership across the groups. And, finally,
to the functional group. effective executive sponsorship verifying and tracking the
goals was nonexistent.
Regular FRACAS process review meetings involving all key
stakeholders from the various functional groups can be help- Solution 2: Overcoming a Lack of Prioritized Goals
ful. These meetings can decrease in frequency over time. And,
of course, before the final FRACAS is deployed, make sure To overcome the problems that result from the lack of priori-
that all stakeholders have signed off on the proposed com- tized goals, use best practice principles. First, the goals and
munication plans to ensure you can overcome the challenge expectations of the FRACAS should be discussed and agreed
of complex organization interaction. upon by all stakeholders, including management. It is also
helpful to obtain objective FRACAS leadership so that all stake-
Challenge 2: A Lack of Prioritized Goals holders goals may be considered in the planning. Also, deter-
mine which goals can be accomplished well by the FRACAS as
Consider the following scenario: a customer contract it has been designed, and make sure all stakeholders have
specifies that a FRACAS system be utilized for a particular signed off on and agreed to these planned and prioritized
project. But due to financial constraints, the resources are goals.
lacking to complete a fully featured FRACAS implementation.
Project managers implement a temporary Microsoft Excel- Challenge 3: Ineffective Data Tracking
based or Microsoft Access-based solution, fully intending
to replace this solution in the future with a more substantial The key to ensuring a FRACAS is effective is to gather and
system. But a fully featured FRACAS never materializes. Con- report meaningful data. This seems to suggest that the more
sequently, a minimal FRACAS system becomes the standard, data an organization can gather regarding an incident or
resulting in poor efficiency and a lack of cohesiveness. failure, the better its FRACAS will be. But this is not neces-
sarily the case. Too much data may prevent companies from
In another example, a company believes that a FRACAS is discovering meaningful trends.
important to the success of a product but sees it as something
they will get to in the future. As the product lifecycle progresses, For example, many legacy FRACAS systems collect 80 or more
the company gains an appreciation for the necessity of a fields of information when recording a failure. Although much
FRACAS. By this time, the company is far past the point of of this data is valuable, gathering too much data can result
the budgeting and planning processes. Therefore, a proper im- in several problems. For example, suppose it takes customer
plementation does not occur and teams are left scrambling support personnel five seconds to enter data into each field.
late in the project to find resources to implement a FRACAS. They will spend 400 seconds or 6.6 minutes filling in all 80
Once again, a minimal FRACAS system is implemented. fields, not including research time, resulting in a general
feeling that it is just too time consuming to fully log a prob-
In a third example, an executive management team has high lem. Fields are routinely skipped and some issues are not
expectations for the system. They envision that the FRACAS even reported because it is too much trouble. To prevent this,
will save the company money on warranty costs; while the designers develop input screens that will easily accept inci-
reliability group expects significant data that can be used to dent information.
discover trends and improve a products design over time.
Unfortunately, because the program manager is provided with However, as is often done, designers utilize free flowing text
minimal financial resources, she can only implement a basic fields to allow customer support personnel to type any in-
FRACAS. The system is not deployed early enough to sufficiently formation that they think is useful. The personnel can then

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


White Paper

become confused, and do not always know what to enter. Step 2: Define the Output
Consequently, they begin to include extraneous or irrelevant
data and sometimes just leave the field blank. Not only is it With goals and success factors in place, it is time to define
difficult to perform any meaningful analysis with the resulting the results or outputs that each group is expecting from the
data, but it also becomes a tedious manual process to review FRACAS system to achieve the success factors that were out-
each individual incident in search of trends. lined in the groups agreed-upon goals. Typically, the results
are stated in terms of calculations, charts, graphs, and re-
Solution 3: Effectively Managing Data ports. For example, the Reliability group may need a Pareto
chart indicating the number of failures by part number. The
To avoid the problems of inefficient and ineffective data track- Field Service group may require a report indicating the cost
ing, organizations should establish functional procedures before of warranty repairs by part number. The Quality group may
data collection begins. Using simple, streamlined forms which require a reliability growth chart.
store data in a central database is often the best approach.
Training the FRACAS users responsible for data entry helps A common pitfall is that each group will want as much output
ensure that all important data is entered correctly and effi- as possible, resulting in a bloated wish list that is difficult to
ciently. It is also helpful to remind those responsible for entering reasonably implement. The purpose of this exercise, however,
failure data of the importance of capturing the data at the is to focus on what is absolutely necessary for success based
time of failure, and the long term benefits to the organization on previously established goals. To help with this, map each
that can result from timely data capture. Whenever possible, output requirement back to a goal and success factor.
employ automation when capturing the failure data.
Step 3: Map the Process Workflow
4 Steps to a successful FRACAS.
Through a series of meetings and interviews with stakeholders,
These three common challenges to FRACAS implementations discuss what process or workflow they expect to follow. Most of
are by no means all-encompassing, but they do outline typical the groups will focus on their own internal processes but may
problems that prevent companies from realizing the dramatic not understand the overall process as it relates to all groups
results that can be achieved with a successful FRACAS. To help with a role in FRACAS. Based on each groups individual input
avoid these common obstacles from the outset of planning a and through additional investigation, develop a consolidated
FRACAS, the following eight steps are recommended: process diagram. Using this diagram, search out inefficiencies
and actively find ways to simplify the process.
Step 1: Define the Goals and Success Factors
Involve stakeholders in simplifying and coordinating the pro-
Defining the goals of all intended users and stakeholders is cess steps between the groups. Question any step that does
the foundation for a successful FRACAS. Every step in the not produce the output requirements established previously.
process of implementing a FRACAS will be based upon these Also, work to ensure that the overall process is not too lengthy
goals. Ensuring these goals are understood and agreed upon or complex. Remember that many steps can slow the resolu-
by all is key before implementing the FRACAS. A mistake or tion of incidents or decrease the ability to report trends in a
misunderstanding at this step can have negative consequenc- timely manner. Changes to the overall process are inevitable,
es later. Because issues may not become known until months but this step establishes a workable starting point.
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 Streamlining Data Entry and Data Tracking: By entering a single identifier,
requirements. The purpose of this exercise is for each group such as the serial number of a returned product, as shown above, Windchill
to come to a consensus on the priority of its primary goals. FRACAS uses lookup table functionality to autopopulate the remaining fields.

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


White Paper

Step 4: Map the Required Data and Input Method steps, making it easy to start from a predefined solution or
configure it in a few easy steps to suit organizational needs.
Using the process diagram and the output requirements, This solution helps companies avoid the expensive, time-
determine the minimum data fields required to support the consuming, and often intractable results of hiring specialized
workflow process at each step. Investing time in this step consultants to create a customized solution. Easily configurable
helps eliminate the problem of collecting data with no direct templates can be continuously adapted as your FRACAS pro-
purpose, and can help focus users efforts. cess changes and develops, without the need for specialized
programming skills.
After the data fields have been established, determine how
the data will be viewed by the user. It may make sense to Whether selecting a small group collaboration tool or a
show one large form with all of the data fields. Or, it may large, Enterprise-wide FRACAS application, examine the or-
be better for each group to have specific forms with specific ganizations immediate needs in relation to its future plans.
fields displayed so that their view of the data is limited for It is important to consider the functionality required by your
ease of understanding. Involve the stakeholders to under- specific FRACAS process, the number of potential users, and
stand what they are expecting and why. the data storage requirements both at the projects inception
and well into the future. To validate the decision, implement a
Additionally, specify how the input data will be gathered.
prototype FRACAS based on the selected approach.
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
Customer
data entry, and bar code scanning. Service
Product Customer
Warranted? NO Paying? NO
Takes Call
Step 5: Implement a Prototype FRACAS 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- Step 6: Accept Feedback and Modify the FRACAS
ity, maintainability, and risk analysis applications to effect a
more detailed analysis. Enterprise applications provide ad- Once the prototype FRACAS has been implemented, with suf-
ditional tools for handling large amounts of data, including ficient time for users to test and get a feel for it, it is important
Web-based tools for streamlined data entry, workflow alerts to bring the stakeholders back together and evaluate the re-
delivered via e-mail, support for Microsoft Active Directory sults of the prototype system. Is this environment effective
Services, and many simultaneous users. for the previously defined workflow process? Is data entry
efficient and streamlined? Can the expected outputs be
Windchill FRACAS also supports commercial-off-the-shelf generated? Is the system easy to use and understand?
(COTS) templates with preconfigured FRACAS workflow

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


White Paper

Most importantly, revisit the goals and success factors. Does 5 Conclusion.
the system fulfill these goals? Will the success factors be
met? It is very likely that you will find areas of the system Yielding more reliable products, better collaboration
that need to be reworked. This is the time to accept con- throughout teams in the organization, and valuable system
structive feedback and make the necessary modifications. metrics to track product performance over many different
Before proceeding, gain signoff and approval from all factors, an effective FRACAS is a valuable tool for any
stakeholders. You will need their continued support to make company seeking to improve its quality and reputation. By
the implementation a success. examining the best practice approaches to implementing
a FRACAS process, companies can help ensure successful
Step 7: Rollout and Training adoption, streamlined implementation, and effective results
from the system.
Although it may be necessary, when time is of the essence,
to allow all users onto the system at once, this approach is 6 About the authors.
likely to have more issues. With so many users starting out
at the same time, seemingly minor issues can become major Daniel Jacob is an ASQ Certified Reliability Engineer with
obstacles. Although this approach can work, it requires sig- an extensive and diverse background in engineering, project
nificant planning and coordination. It should only be con- management, technical sales, and market development. As
sidered when absolutely necessary. Alternately, a phased Business Development Director for Windchill Quality Solutions,
approach whereby several groups at a time are trained Mr. Jacob works with customers to determine the software
and then brought online is the preferred implementation and processes necessary to meet corporate and program
method. By using this approach, any unforeseen issues can objectives.
be addressed without involving the entire user base. Addi-
Jennifer Akers is an ASQ Certified Reliability Engineer
tionally, the implementation and training teams are able to
responsible for all Windchill Quality Solutions training services.
adapt to these issues and provide better support for later
As a Senior Application Engineer and Curriculum Developer,
groups.
Jennifer has developed numerous training courses that focus
Typically, the more individualized attention and training giv- on both the theoretical foundations and practical applications
en to users, the better their acceptance and support of the of Windchill Quality Solutions software tools.
FRACAS will be. Training is extremely important, especially
7 Bibliography.
when typical FRACAS systems involve users of many differ-
ent areas of interest and levels of expertise. When users un- 1. Failure Reporting, Analysis and Corrective Action System
derstand what is expected of them and are empowered by (FRACAS) Application Guidelines, Product Code FRACAS,
training to use the FRACAS, the system has a much greater Reliability Analysis Center, 1999 Sep., p 5.
chance for acceptance and success.
2. M. Villacourt, P. Govil, Failure Reporting, Analysis
Step 8: Continue to Change and Adapt the FRACAS and Corrective Action System (FRACAS), Doc
ID #: 94042332A-GEN, SEMATECH, 1994 Jun.,
One of the most important aspects of a FRACAS is to learn
Available at http://www.sematech.org/docubase/
what works and what can be improved. Based on this feed-
document/2332agen.pdf
back, continual change can and should be expected. As
business objectives and processes change, the FRACAS 3. NASA, Preferred Reliability Practices Problem Reporting
needs to be adapted to support these changes. It is impor- and Corrective Action System, Practice No. PD-ED-1255,
tant, however, that the FRACAS is actively managed to not available at http://klabs.org/DEI/References/design_
only accept these changes but to also validate these changes guidelines/design_series/1255ksc.pdf
in relation to the overall goals that were initially established.
4. MIL-HDBK-2155 Department of Defense Handbook:
Failure Reporting, Analysis and Corrective Actions Taken

Page 8 of 9 | Organizational best practices for FR ACAS implementation 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