Navigation
Home
News
Newsletter
Knowledge Bases
Tutorials
Directory
Books
Maintenance-Tips
Conferences
Forums
Photo Albums
Reliability Radio
Benchmark
Calendar
Gadgets
Jobs
Network Links
Archives
en Español
XML/RSS Feeds Advertise

Tricks to Keep things Simple in Maintenance by Steve Turner, OMCS

Introduction

In the realm of maintenance analysis, we engineers seem to take great delight in turning something which is fundamentally simple into something that is very complex. 

By doing this:

• We introduce numbers of assumptions of which many, may be (and often are) flawed.
• We purchase statistical software which takes the onus of analysis away from the very people who understand the plant (the operators and tradesmen) as these people are often not sufficiently computer literate to run the complex software and almost always not statistically competent.
  • The result is that we lose buy-in and therefore the enthusiasm to create a living program that is simple to understand and simple to change. 
  • The PM program ends up being owned by the engineer in the back room with the computer rather than the folk who do the work and know what works and what does not.
• We take far more time to do the analysis than it should.
• We end up with a program that is easily discredited on the basis of the assumptions and the “dodgy” data.

So where does the conclusion that analysis issues need not be complex come from?  How can maintenance strategy development be reduced to simple methods?  Who are the right people to ask and what are the right questions to ask them? What are the secrets?

Asking the Right Questions

In the majority of cases, condition monitoring is chosen as the means of managing failure. It is widely accepted that the intervals of inspection for condition monitoring are primarily driven by the rates of decay of assets. The point is that the rates of decay of an asset at failure mode level are rarely measured or collected with any degree of rigor (if at all) hence there is rarely data available to support anything else, other than a simple approach.

So Point 1 is that if the right people are asked the right questions, the best assessment of the rates of decay will emerge very quickly, whereas a reliance on statistical methods may never get the information in sufficient quantity to make reasonably confident predictions.   A question often used to determine the rate of decay is this” How often should you inspect this component for this failure mechanism such that it will never fail without you knowing?”.

The second approach to preventive maintenance is what we may call "Hard Time" or Scheduled discard / refurbishment tasks. The intervals for these tasks rely on some information regarding the failure patterns and the consequence of failure. Again, in most industrial applications, there are two “in a sense contradictory" situations.

If the component has a dominant failure mode which is age related and has a high frequency, then the maintainers will usually know what that frequency is because they change the component regularly. They do not need a sophisticated database for this. Questions to ask is “How often should you change this component such that it will never fail in service?.  If you have some data, assemble the data on a bar chart with age on the X Axis and Failure Frequency on the Y Axis.

If the failure is age related and low frequency, then it will take a long time to get any statistically significant data unless there are lots of these components in the same service. 

If a failure mode is random and fails suddenly, then there is no amount of preventive maintenance that will stop the failure from happening unexpectedly.  No matter what statistics are available for these failure modes, there will be no benefit whatsoever.  The means to prevent such failure is by modification not by preventive maintenance/

Pitfalls Associated with thinking Data Will Solve the Problems

In collecting the quantities of data so necessary for statistical analysis, one could easily suggest that maintenance has failed, as its primary task is to remove the failures before they occur. So, in order to get the information, that is so desperately needed to succeed, we must first set out to fail.

This makes no sense. So if we were to try and use statistical methods in an industrial application, we are forced either:

• To make sweeping assumptions about means and distributions and stuff the numbers into simulation algorithms, or
• We can take the simple approach which relies on intuition, engineering training and valued judgment of experienced people who have probably dealt with similar failure modes many times before.

Conclusion

No doubt there are instances where statistical applications can work wonderfully well and where computer simulation packages stand out, head and shoulders above the rest. However in the author’s experience, we are almost always short of the data we want. We therefore need to provide simple thought processes that help people to make good educated assessments. If I were to rely on three or four guesses jammed into a software tool (that perhaps only people of your statistical background really understand) then I would be most uncomfortable about turning in a decent result for a client. "Trouble is, a bad result rarely surfaces immediately, but that's another subject"!

Regardless of anything else though, the bottom line is implementation. The more ownership the program has at the "shop floor" then the more successful it will be (in my experience). Doing a bunch of elegant statistical analyses, or any analysis for that matter, is a cost to the business. It is a cost until the time that it is implemented. Since implementation is often the tough bit, we most often focus heavily on implementation rather than trying to clean up data and support assumptions which may result in a solution which is no better than the initial assessment. I love statistics, but I also understand their limitations.

Anyone wanting to read more on this subject can download a paper called "understanding the downsides of statistical maintenance analysis methods" from our website at www.pmoptimisation.com.au. Readers should be aware that this paper discusses only a certain type of approach that is a "cost minimization" approach. Readers may see similarities in some of the points raised in packages that use different algorithms.

Alternatively, readers may be interested to listen to the reliability manager from Bermuda Electric Light Company who very quickly made significant gains to his organization without using any complex statistics.  www.omcsinternational.com/testimonials/default.asp