Search

Loading

Monday, January 14, 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.

Sunday, January 13, 2013

5 myths about RCM

I recently found some old posts relating to regularly regurgitated myths about Reliability-centered Maintenance. 

I thought I would repost them here if anybody is interested. They were first published around 2007 so some of the links no longer work, and some of the old webpages are now out of publication. 

But the links below work fine.
  • Myth 1 is lost in time right now.. I will see if I can dig it up in the next couple of days


So over the next ten days, starting from tomorrow, I will work to publish a detailed post every day on one of the common myths (of maintenance, not of RCM) I regularly come up against when we are facilitating or teaching people about RCM. 


You can subscribe using the link on the tabs at the top of the page, or via the email box on the side page. We don't spam our readers and many people reading this blog have been doing so for over 5 years now. 


Good luck, and let's hope I haven't been too ambitious in the 10 tips in 10 days theme. 


Check out the Reliability Success training schedule for detailed training on the themes mentioned in this blog.

Explaining Run-to-failure

I often read posts and articles railing against run-to-failure as a valid maintenance strategy. or worse, RCM practitioners trying to apologise for run to fail decisions and explain other ways of doing things.

RTF is hard to accept initially because engineers and tradesmen (Journeymen) have an affinity with machinery as Moubrey would say. We like to get them running, tune them to the max, and keep them running smoothly. 

It's in our DNA fortunately... But this doesn't help us to create the minimum safe levels of maintenance for our physical assets. 

Saturday, January 12, 2013

The 8 task types of RCM


About 7 years ago we started to introduce the concept of 8 Maintenance Types to the RCM training we deliver.

This was in response to my involvement in the evolving Whole of Life cost and management models throughout the infrastructure sectors of the UK at that time. (circa. 2003 - 2006 ish)


The results have been so impressive that this has become part of the story of RCM that we tell during the RCM 101 course, and is developed further with additional techniques and applications during the RCM Analyst training course. 


Some of the things to come out of this over the years have amazed even me, and the impact tends to change depending on the application within each sector, company, or even asset. 

One of these has been the total uselessness of commonly used metrics in most companies. Particularly the Planned vs Corrective work order graphs.


Another impact has been on the approach that many companies take to forecasting whole of life costs, change out dates, and for forecasting CAPEX spending way off into the future. 

The Dangers of "Basic Maintenance"

Basic maintenance is the latest variant of the "back to basics" meme that sweeps through maintenance every 5 - 10 years.

It sounds innocuous enough, and who would argue about setting proper lubrication schedules and cleaning regimes right?

Yet in the RCM analyses that we regularly perform this belief in basic maintenance is one of the largest contributors to over-maintenance, inefficient use of resources, and in some cases increases in downtime and risk of failure

Tuesday, January 8, 2013

Its the FUNCTION stupid!

Clearly understanding this concept is one of the key elements of maintenance and reliability, and the key reason why rationalisation methods will never really be able to challenge correct application of Reliability-centered Maintenance. 

Almost every single analysis I do I come across the example of assets being managed based on what they are. 

A pump receives the "basic standard" of maintenance that you would expect for a pump, a centrifuge is overhauled every 18 months as you would expect and no one asks any questions.

Yet costs are far higher, return to service failures are higher, and a preponderance of redundant maintenance tasks.

Another tool in the toolbox...

As a long term proponent of Reliability-centered Maintenance I regularly hear this trope trotted out to try to minimise RCM, or to try to elevate lesser method to the same standing as RCM.

One variant of this is when people compare two disimilar methods; for example Planning and RCM.

Planning is about doing the job right, about logistics, analysis and contributes greatly to the efficiency of the asset team. RCM is about the effectiveness and applicability of the maintenance regimes. 

And never the twain shall meet. 

Both important, even essential, but not directly comparable.

Another example would be to take a method like, say. Weibull and to compare this directly to RCM.

For those with any experience in the field this is obviously a mismatch. Weibull is a targeted approach for investigative analysis of failures, whereas RCM is a holistic approach to developing maintenance regimes.

In fact, RCM can very easily (and should in the hands of master RCM Analysts) contain Weibull analysis.

Reliability-centered Maintenance is not another tool in the toolbox. RCM is the toolbox!

Monday, December 31, 2012

Is it really RCM software?

It is amazing the array of software packages in today's market place that call themselves Reliability-centered Maintenance packages yet they often have little if anything to do with either the RCM standard, or with the original report written by Nowlan and Heap. (32 MB PDF file)

Yet they are positioning themselves as RCM packages, and nobody is calling this into question!

Problem of the Week - Managing statutory compliance

Statutory tasks are the scourge of maintenance, no matter which industry you are in.

The intention behind statutory maintenance is supposedly safety of course. For this reason they exist on cranes, lifting gear, pressure vessels, release valves and so forth. it is also the reason why they are so prevalent within the underground coal industry.

High voltage equipment operating in an environment of highly explosive gases tends to be a little hairy at times, so the statutory tasks are there to help manage these risks safely.

That's all well and good; and on the surface it seems like a great idea. Unfortunately it is the implementation that has gone awry in most cases. In some cases this is merely counter productive, but at times it is actively increasing the risk of the type of incident they are supposed to be protecting against.

Sunday, January 1, 2012

RCM 101 - Origin Stories

Trademark of Reliability Success
RCM 101TM is an internationally acclaimed training event, delivered to over 4,500 professionals globally in industries as diverse as:

  • Oil and Gas (In Qatar, UAE and Australia)
  • Petrochemical (Throughout the Kingdom of Saudi Arabia)
  • Hard Rock Mining (Australia and Latin America)
  • Rail (Australia and the UK)
  • Water and Electricity Utilities (Western Australia, NSW and throughout the UK)
Compliant with SAE JA1011 (The RCM Standard), and tying in many unique elements, RCM 101 is fast becoming recognised as the premier training event for maintenance and reliability professionals. 

You can find a more detailed overview on our website, and the current course outline is available in PDF.  (Oil and Gas)

For the practitioners among us this post is a bit of a discussion over the creation of RCM 101 and the RCM Analyst training methods, and the problems I set out to fix when I started all of this.