Effects – alternate usages

In many RCM software applications the Effects has a different usage from that which we describe in many places throughout this website.

For example, in one RCM software application, when you open up the properties of a given Failure Mode from the RCM Hierarchy tree view, an elaborate set of tabs is provided. One of the tabs is called “Effects”. In this dialog you can input any number of entries in the following structure:

1. An Effect code which is an abbreviation such as FIRE or LOWQ
2. Whether the Effect applies to one or more of:
   1. Failures
   2. Planned Maintenance
   3. Inspections
3. A Redundancy Factor – calculated by a wizard into which the user provides:
   1. Number of additional components in parallel
   2. Number required to be operating
   3. Fractional downtime of each component

The above is quite different in style and in meaning from the JA1011 usage for Effects. Information technology tends to shun “free text”. Instead it tries to structure human thought, often too rigidly. The user is required to compartmentalize his observations, that are naturally quite diverse. A user of that RCM application asked the following:

“I have facilitated many RCM reviews using both the JA1011 Effects style as well as the software’s point and click approach. I have found, over the years, that typing in the Effects for each failure mode takes twice the time of answering the specific structured questions posed by the RCM software application.  Is not the more structured approach to Effects, while still providing ample place for free text, if we need it, a better one than that used in the Moubray/JA1011 method?”

This is an interesting question. The test of any FMEA documentation style is whether it “works” in a living RCM context. How well does it succeed in assisting and encouraging continuous day-to-day improvement in the knowledge base? There is no intrinsic “right” or “wrong” software or method. Whatever works.

The reason I am partial to the Moubray style of Effects is that it reads like a story. It treats Question 4 “What happens?” as an open question (although there are guidelines) to be answered in a narrative. A story is more interesting and captivating than a series of checks in an option list. If the organization implements continuous improvement through Living RCM, a story will more likely engage those who have something to add to the knowledge base. Starting with the current narrative they will update it with what they know. Managers and other stakeholders, less familiar with FMECA jargon (e.g. “compensating provisions”) react better to a narrative in plain language. Take, for example this Effects narrative that, in spite of its technical subject, anyone can read and identify with:

“The poles will not open simultaneously which will could create an excessive load interrupting on the last pole, which will cause excessive wear on the contacts. (Under normal switching could cause a protective relay operation due to imbalanced current?) Could increase the risk of customer outage and system instability. The poles does not close simultaneously could cause the first pole in which is the last pole out which will could create an excessive load interrupting on the last pole, which will cause excessive wear on the contacts. Troubleshoot up to 4 hrs and repair up to 5 hrs to adjust the interface linkage. Total up to $1000. Failure frequency has not been documented.”

From the one or two grammatical glitches, the author may not be working in his native language. Yet it doesn’t matter. Anyone can comprehend the description of the sequence of events surrounding the failure mode. Armed with the narrative, determining Consequences and various other parameters related to criticality, redundancy and so on become easier and quicker. The story acts as a validation that confirms and justifies all that you have checked or selected throughout the variety of menus offered by typical RCM types of applications.

© 2011 – 2018, Murray Wiseman. All rights reserved.