4.1 Retroactive RCM Approaches

However, despite this rapid payback, some individuals and
organisations have expended a great deal of energy on attempts

to reduce the time and resources needed to apply the RCM
process. The results of these attempts are generally known as
‘streamlined' RCM techniques.
This section of this paper outlines the main features of some of
the most widely touted ‘streamlined' approaches to RCM. In all
cases, the proponents of these techniques claim that their
principal advantage is that they achieve similar results to
something which they call ‘classical' RCM, but that they do so in
much less time and at much lower cost. However, not only is this
claim questionable, but all of the streamlined techniques have
other drawbacks, some quite serious. These drawbacks are also
highlighted in the following paragraphs.
4.1 Retroactive RCM approaches
The most popular method of ‘streamlining' the RCM process

starts not by defining the functions of the asset (as specified in
the SAE Standard), but starts with the existing maintenance tasks.
Users of this approach try to identify the failure mode that each
task is supposed to be preventing, and then work forward again
through the last three steps of the RCM decision process to re-
examine the consequences of each failure and (hope-fully) to
identify a more cost-effective failure management policy. This
approach is what is most often meant when the term ‘streamlined
RCM'10 is used. It is also known as "backfit" RCM11 or "RCM in
reverse".
Retroactive approaches are superficially very appealing, so much

so that the author tried them himself on numerous occasions
when he was new to RCM. However, in reality they are also
among the most dangerous of the streamlined methodologies,
for the following reasons:
- they assume that existing maintenance programs cover just

about all the failure modes that are reasonably likely to require
some sort of preventive maintenance. In the case of every
maintenance program that I have encountered to date, this
assumption is simply not valid. If RCM is applied correctly, it
transpires that nowhere near all of the failure modes that actually
require PM are covered by existing maintenance tasks. As a
result, a considerable number of tasks have to be added. Most of
the tasks that are added apply to protective devices, as
discussed below. (Other tasks are eliminated because they are
found to be unnecessary, or the type of task is changed, or the
frequency is changed. The nett effect is usually a reduction in
perceived overall PM workloads, typically by between 40% and
70%.)
- when applying retroactive RCM, it is often very difficult to

identify exactly what failure cause motivated the selection of a
particular task, so much so that either inordinate amounts of time
are wasted trying to establish the real connection, or sweeping
assumptions are made that very often prove to be wrong. These
assumptions are made that very often prove to be wrong. These
two problems alone make this approach an extremely shaky
foundation upon which to build a maintenance program.
- in re-assessing the consequences of each failure mode, it is still

necessary to ask whether "the loss of function caused by the
failure mode will become evident to the operating crew under
normal circum-stances". This question can only be answered by
establishing what function is actually lost when the fail-ure
occurs. This in turn means that the people doing the analysis
have to start identifying functions anyway, but they are now
trying to do so on an ad hoc basis halfway through the analysis
(and they are not usually trained in how to identify functions
correctly in the first place because this approach considers the
function identification step to be unnecessary). If they do not,
they start making even more sweeping - and hence often
incorrect - assumptions that add to the shakiness of the results.
- retroactive approaches are especially weak on specifying

appropriate maintenance for protective devices. As stated by the
author in his book12: "at the time of writing, many existing
maintenance programs provide for fewer than one third of
protective devices to receive any attention at all (and then
usually at inappropriate intervals). The people who operate and
maintain the plant covered by these programs are aware that
another third of these devices exist but pay them no attention,
while it is not unusual to find that no-one even knows that the
final third exist. This lack of awareness and attention means that
most of the protective devices in industry - our last line of
protection when things go wrong - are maintained poorly or not
at all." So if one uses a retroactive approach to RCM, in most
cases a great many protective devices will continue to receive no
attention in the future because no tasks were specified for them
in the past. Given the enormity of the risks associated with
unmaintained protective devices, this weakness of retroactive
RCM alone makes it completely indefensible. (Some variants of
this approach try to get around this problem by specifying that
protective systems should be analysed separately, often outside
the RCM framework. This gives rise to the absurd situation that
two analytical processes have to be applied in order to
compensate for the deficiencies created by attempts to
streamline one of them.)
- more so than any of the other streamlined versions of RCM,

retroactive approaches focus on maintenance workload
reduction rather than plant performance improvement (which is
the primary goal of function-oriented true RCM). Since the returns
generated by using RCM purely as a tool to reduce maintenance
costs are usually lower - sometimes one or two orders of
magnitude lower - than the returns generated by using it to
improve reliability, the use of the ostensibly cheaper retroactive
approach becomes self defeating on economic grounds, in that it
virtually guarantees much lower returns than true RCM.
4.2 Use of generic RCM analyses

4.2 Use of generic RCM analyses
A fairly widely-used shortcut in the application of RCM entails

applying an analysis performed on one system to technically
identical systems. In fact, one or two organizations even sell such
generic analyses, on the grounds that it is cheaper to buy an
analysis that has already been performed by someone else than
it is to perform your own. The following paragraphs explain why
generic analyses should be treated with great caution:
• operating context: In reality, technically identical systems often

require completely different maintenance pro-grams if the
operating context is different. For example, consider three
pumps A, B and C that are technically identical (same make,
model, drives, pipework, valvegear, switchgear, and pumping the
same liquid against the same head). The generic mindset
suggests that a maintenance program developed for one pump
should apply to the other two.
However, Pump A stands alone, so if it fails, operations will be

affected sooner or later. As a result the users and/or maintainers
of Pump A are likely to make some effort to anticipate or prevent
its failure. (How hard they try will be governed both by the effect
on operations and by the severity and frequency of the failures of
the pump.)
However, if pump B fails, the operators simply switch to pump C,

so the only consequence of the failure of pump B is that it must
be repaired. As a result, it is likely that the operators of B would
at least consider letting it run to failure (especially if the failure of
B does not cause significant secondary damage.) On the other
hand, if pump C fails while pump B is still working (for instance if
someone cannibalizes a part from C), it is likely that the operators
will not even know that C has failed unless or until B also fails. To
guard against this possibility, a sensible maintenance strategy
might be to run C from time to time to find out whether it has
failed. This example shows how three identical assets can have
three totally different maintenance policies because the
operating context is different in each case. In the case of the
pumps, a generic program would only have specified one policy
for all three pumps.
Apart from redundancy, many other factors affect the operating

context and hence affect the maintenance programs that could
be applied to technically identical assets. These include whether
the asset is part of a peak load or base load operation, cyclic
fluctuations in market demand and/or raw material supplies, the
availability of spares, quality and other performance standards
that apply to the asset, the skills of the operators and
maintainers, and so on.
• maintenance tasks: different organizations - or even different

parts of the same organization - seldom employ people with
identical skillsets. This means that people working on one asset
may prefer to use one type of proactive technology (say high-

4.1 Retroactive RCM Approaches

Uploaded by

Copyright:

Available Formats

4.1 Retroactive RCM Approaches

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

4.1 Retroactive RCM Approaches

Uploaded by

Copyright:

Available Formats

However, despite this rapid payback, some individuals and

organisations have expended a great deal of energy on attempts

4.1 Retroactive RCM approaches

The most popular method of ‘streamlining' the RCM process

Retroactive approaches are superficially very appealing, so much

- they assume that existing maintenance programs cover just

- when applying retroactive RCM, it is often very diﬃcult to

- in re-assessing the consequences of each failure mode, it is still

- retroactive approaches are especially weak on specifying

- more so than any of the other streamlined versions of RCM,

4.2 Use of generic RCM analyses

A fairly widely-used shortcut in the application of RCM entails

• operating context: In reality, technically identical systems often

However, Pump A stands alone, so if it fails, operations will be

However, if pump B fails, the operators simply switch to pump C,

Apart from redundancy, many other factors aﬀect the operating

• maintenance tasks: diﬀerent organizations - or even diﬀerent

You might also like