Using a System to Record, Report And Eliminate Defects

Why is that some organization seem to break the reactive cycle and others don’t?  After all most organizations have a PM program and some form of a planning and scheduling program right?   The key difference between those that do is their ability to use their failure data and systematically eliminate defects and issues from the processes and equipment.  This doesn’t mean adding a new PM everytime some fails, which just won’t work.

To eliminate the defects and issues, the organization needs to collect meaningful data to analyze and act on.  This is where FRACAS comes in.

What is FRACAS

So what is FRACAS?  Its standards for Failure Reporting and Corrective Action System.   A FRACAS is a system, often utilizing the CMMS/EAM (but not a requirement) that provides a systematic way for reporting, classifying, analyzing failures and planning preventative or correct actions in response to those failures.    Typically it is to used to build a historical database of failures to drive reliability engineering work and equipment improvements.

A typical FRACAS system consists of the following steps;

    1. Failure Reporting (FR).  The failures related to a piece of equipment are reported through a standard form (such as failure information in a work order).
    2. Analysis (A). Is using the data to identify the cause of failure.  This may be using a Pareto Analysis to identify the most important issue to address and then using other techniques to dive into the issue and determine the cause.
    3. Corrective Actions (CA).  Once the cause has been identified, the corrective (or preventative) actions must be implemented to prevent the recurrence of the failure.  Ideally, these are documented through a formal change management program to ensure the learnings are incorporated into new equipment designs.

Setting Up a Failure Recording System

So at first view, a FRACAS seems simple enough.  So why is it that most organizations struggle with one?   It is generally because it is not well thought out ahead of time and built into the CMMS/EAM.   Also, the system may be overly complex.   So what can you do to ensure it works with your CMMS/EAM and you people?  Start by following the suggestions below;

  • Use a master library so that the number of overall codes is reduced, while only displaying codes relevant to the equipment in question
  • Keep drop downs simple.  Ideally, they fit on a single screen with no scrolling
  • Eliminate free text fields as much as possible for codes.
  • Train your people.  Train them on why the data needs to be collected, how it will be collected, how it will be used and most importantly, the benefits to them,

Aligning Your FRACAS System to ISO 14224

Thankfully there are those who have taken the time to share their knowledge on this exact subject.  There have been books written (FRACAS by Ricky Smith), and there is an ISO standard developed to classify, collect, analyze and share failure and maintenance data.   This ISO standard is ISO 14224, and while it was developed for the Oil & Gas Industry, it can be used and applied in other industries (and there are many examples of it being done successfully).

ISO 14224 requirements.   So according to the standard, what information should be collected to facilitate a FRACAS?   Well, it all starts with the asset hierarchy, which is a whole other topic.  Assuming that the hierarchy is correct, the information that should be collected is as follows;

  • Failure Mode
  • Failure Mechanism
  • Failure Cause
  • Failure Consequence
  • Failed Component
  • How Failure Was Detected
  • Condition of Equipment at Point of Failure
  • Breakdown Time
  • Repair Time

Based on this information, meaningful analysis such a Weibull, Crow-AMSAA and various RCA techniques can be applied to eliminate the failure.

Cautions

There are a few cautions which should be considered when implementing FRACAS;

  • Many consider the only solution to failures is more PMs.  This could not be further from the truth.  It is better to try to redesign out the failure or find a different solution.  If a PM must be added to the system, make sure it is vetted by the use of an FMEA or RCM analysis.  This will prevent nonvalue-added (whether due to the nature of the failure mode or the cost effectiveness of the maintenance routine) PM from being added to the maintenance program.
  • Don’t collect data that will not be used.  Only collect the data that will be used.  The people providing the data will realize that they are supplying data which is not used and as a result of that, they will stop supplying or worse, supplying incorrect data.
  • Make the data collection system easy.  If it is not easy, it will not be used or will be gamed (i.e. selecting the 1st or 7th item down each data field list).
  • Develop the FRACAS with the long-term strategy in mind.   If you plan on recruiting Reliability Engineers in the future, setup the system to start collecting the data now.

Do you have a FRACAS in place?  How effective is it?  What are the issues you (or your staff) encountered when trying to record, analyze or act on the data?  Stay Tuned for next week’s post on building an Asset Hierarchy according to ISO 14224.

Remember, to find success; you must first solve the problem, then achieve the implementation of the solution, and finally sustain winning results.

I’m James Kovacevic
Eruditio, LLC
Where Education Meets Application
Follow @EruditioLLC

References;