Monday, 14 January 2013

Common errors of anti-RCM evangelists

Ever notice how the ones opposing RCM seem to do so with a missionary zeal? 

Evangelists shouting at the top of their lungs that "you too can get what RCM offers... but without RCM!"

This particular brand of evangelism had its genesis in the 1990's. 

Back when team-facilitated RCM was seen as the only way to implement RCM, and organisations were shedding human resources to try to keep up with competition as trade barriers dropped all over the world.

The evangelists (those promoting derivative methods like streamlining or rationalisation) turned their gaze on the method, instead of the implementation. 

And the results have been dramatically, and almost universally, terrible.

Don't get me wrong; they are great for my business. I made a career in the mid to late nineties cleaning up after these guys had made a mess. 

Moubray went over some of this ground in his article on the Case Against Streamlined maintenance

One of his better points was that when you streamline something, you remove a part of it.

And herein lies the problem. Instead of addressing issues with implementation, the streamliners went directly for the rigour of the method, often guaranteeing a sub-standard result.

Common Errors of anti-RCM Evangelists

More often than not the anti-RCM thing is a deliberate commercial tactic designed to create difference, appeal to a wider audience, or to support functionality in non-compliant software.

Yet as Moubray pointed out streamlining, or worse rationalizing, is an attack on the rigour of the method and leaves out steps that are often very important.

Functions are often first off the rack. They are either missed out totally as with Rationalization approaches (PMO, Reverse RCM and the like), or they only list the critical functions. (Whatever they might be!)

Missing the Function


Time and time again, in implementation after implementation, I have had to fix this problem. When you do not consider the function, you end up treating the asset based on what it is, not based on what it is required to do.

Within the LNG sector it was Sulphide pumps. Two duty one standby with the two duty pumps .

In this case all pumps were subject to a vibration analysis regime. Why? because they're pumps right? And this is how you maintain that asset.

Yet on further analysis we determined that the function was actually to deliver product at X rate and then found the following to be true.
  • There was a standby pump which, if maintained correctly, could be relied upon to start when required.
  • There was a seamless transfer between the Duty and Standby assets; with no hiccups or even minor interruptions to the process
  • If the Duty pump bearing was noted as having a high vibration signature, indicating an impending failure, it would be planned for replacement which would take 4 days using an onsite workshop.
  • If it failed in an unplanned manner it would take.... 4 days using an onsite workshop!
  • And lastly, if the bearings were allowed to run to failure, to the point where they failed and caused the loss of the function, then there would be absolutely no additional or secondary failures.
So the entire practice of vibration monitoring on these specific assets was able to be eliminated, along with a new strategy for fix on failure that would reduce replacement time from 4 days to 4 hours. 

Not a big deal when you are talking about two pumps but when you are managing an asset base of a hundred or so similar sets then this is a considerable additional cost for no additional benefit. 

If you omit the function you end up treating the asset based on what it is, rather than what it does.

This point runs ever deeper. When you perform rigorous functional analysis the team involved learns a heck of a lot about the assets they are supposed to be managed. It exposes a range of issues...

The true failing of rationalization...

In a recent study on Longwalls from the Coal industry we eliminated over 91% of the existing maintenance regimes. 

Why? Because when we defined the function we found that there were a range of failure modes that were not being managed using the traditional "maintain the asset" approach.

This is impossible when using a Reverse RCM or rationalisation approach. 

Rationalisation starts with the concept that the existing strategies are 80% correct. 

It ends up being an approach to justify what is currently in place, instead of dealing with the failure modes that are actually disrupting the function of the asset.

To be continued...

The issue of anti-RCM evangelists will be dealt with in several posts over the next couple of weeks. A pretty crass tactic from people who actually do know better.