Tutorial

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