What Price Providing MTBF?
What good is your service if your livelihood consists of providing MTBF upon request?
Sure, you earn some money, yet did the customer receive value in the transaction? As you know, or should know, MTBF is so commonly misunderstood that the customer is likely to be confused about what they want, reliability or MTBF. Providing them with MTBF does not answer their question.
Worse, the customer thinks they got something of value and blithely heads off with rather meaningless information.
My contention is to provide MTBF because the customer’s request is wrong. We know better. Those performing predictions, doing data analysis, and other reliability engineering work know that MTBF is a faulty and rather meaningless metric often confused with reliability, R(t). (probability of success over a duration).
Part of providing a service and value to customers is helping them actually solve problems and improve their ability to create a reliable product. Providing MTBF does neither. Asking your customer what they really want and will use the information for allows us to provide R(t). Something that is useful.
The Customer Expects MTBF
One view of business is to offer the custom exactly what they request. Don’t ask questions; don’t question the validity of the customer’s request.
The customer is always right.
Well, if they are asking for MTBF, they are likely not right.
Every time someone asks me for MTBF I ask they want they really want to know. How do they expect to use the MTBF value. Every time they describe something that MTBF cannot provide or help to answer. Every time I describe R(t) and they say that is what they really want. They want to know the chance of their product surviving over some duration.
I often ask how does their product fail – they never describe a random and constant failure pattern. They describe issues with installation, early life failures, wear out, and degradation patterns. MTBF is not able to describe these behaviors in a meaningful manner.
The customer may request MTBF yet they want information to help them make decisions. They want something that describes the reliability performance of their product over time.
In consulting, we often ask questions to fully understand the clients initial request. We know the initial request is likely not the real issue that needs to be solved. A few questions helps the consultant and client determine the underlying issue that should be solved to make a difference.
Ask you customer that is requesting MTBF, what they really want.
The Customer Only Pays for MTBF
A comment on a previous NoMTBF article included the situation that the customer would only pay for MTBF. They expected and only would pay for a report or component that included MTBF.
If the condition of sale is MTBF that does not preclude you also providing a warning that the MTBF value may be of little value, provides limited information, and may not reflect the reliability performance of the item. Then provide the R(t) formula or graph which provide value, information and a description of reliability performance.
I like the idea to add a warning. Hopefully, the customer thinks about the value of asking for MTBF and instead asks for reliability in the future.
We’re Providing What The Customer Requests
Sure, part of business is satisfying the customer. Providing what they request is great. Providing what is of use is better.
When questioned, your customers are probably interested in the reliability and performance of their product or system. They want to know the chance of failure over a duration ( 1 – R(t) ). They may want to understand the probability of mission success, or have an idea of expected failure rates to stock spares. They need accurate and reliable reliability performance information.
If your service can only provide MTBF are you helping your customer to answer the questions they have about their system? No. You are providing a crude and often mis-understood value that oversimplifies, leading to poor decisions.
Instead provide what the customer needs. Provide some education to help them improve their design and reliability performance. Instead really understand what the customer needs, not simply requests, and provide a meaningful and useful solution.
How do you request reliability information? How do you respond to requests for MTBF? Add you comments below and let’s share best practices around requesting and providing reliability information.
There’s always value in giving the customer what they want, even though it’s not exactly what they asked for. You can’t penalize them for their ignorance – they just don’t know how to ask for what they want. One of the most common reasons I hear for requesting MTBF is that it’s what some one else told them to get. Give them a reliability vs. time curve and see how often them smile and nod their head. A picture’s worth a thousand words, and way more valuable than that 4-letter acronym.You can even point to where the MTBF point on that line is to fill in that magical, mystical number request. Telling them their reliability isn’t really going to be constant over time won’t surprise many – we live in a real world where old things break down.
Hi Kevin,
Agree, we should penalize our customer, yet engagement them to overcome ignorance so they benefit by avoiding MTBF altogether.
Cheers,
Fred
Fred, I am a serious convert, but some of us humble folk cannot always change things. I have recently had a couple of clients who have been asked to soppy an MTBF to a VERY VERY big client of their own. They have a fixed deliverable of an MTBF and no discussion. We have debated at length and ultimately, if they want to be paid, this what had to be given. So, my compromise is yo give a number (!) together with a health warning that it is rubbish – but meets the end user demand. I don’t like it, but we all need to live. How else is it possible to address issues like this? I assure you that discussion with the end user is absolutely out of the question.
Hi Gerald, I like the health warning, that is a start.I understand the problem and will be looking for ways to approach this issue for a future article. In the meantime, if anyone has suggestions that would be great. cheers, Fred
MTBF is just another reliability metric. Why beat ourselves over the head to say don’t use it. If we can explain the bathtub curve and then state for some time after early life, failures will be random in nature, is that so bad even if the random period was short?
Att, Google, Facebook, Apple are not just customers but are worth more than $Trillion. Who are we to say to them to stop using MTBF.
If anyone can convince 1 of them to stop using MTBF, please let us know!
Hi Jon,
I will tell them, as you should as well. As a customer, I expect a low failure rate over a duration, not MTBF. As far as I know, and I don’t have perfect knowledge of all that Apple’s reliability team does or doesn’t do, they do not use MTBF or MTTF. HP didn’t when I was there (we used annualized failure rate, which isn’t much better, yet it isn’t MTBF), Folks at Dell sent me internal policy document that stated they would not use nor expect suppliers to use MTBF… and the list is growing.
Sure, we can consider MTBF just another metric. We shouldn’t simply because so many do not know what it is, what is represents, nor how to use it.
The bathtub curve is a myth – there is not ‘flat part of the curve’. You know this. We cannot simply assume it exists and hope it materializes. There are many competing failure mechanisms vying to cause an item to fail. Some may occur early some later. We use the bathtub curve to describe the various ways items typically fail as an aid for troubleshooting and to encourage robust design and process stability/capability.
If we don’t try, it won’t happen. If the desire is to create reliable products than no using MTBF helps in that endeavor. I think we can change industries. With your help, it is possible.
Cheers,
Fred
In the early 1990s, Apple Computer made nonparametric estimates of field reliability and failure rate functions for its computers and their service parts. Apple used actuarial forecast statistical demand distribution to recommend spare parts stock levels for service providers based on local computer sales. Service providers screamed, because earlier, Apple required them to buy and stock many more service parts. Apple bought back $36M obsolescent service parts. Parts were crushed!
Apple was also making “Credible Reliability Predictions” [https://accendoreliability.com/credible-reliability-prediction/#more-431571/]
In year 2000 Dell was using Weibull statistics for computer reliability from test units.
Hello Fred,
Great article, and thanks. I am still learning about all this, and so have a question: if R(t) as I understand it is a function of both duration and MTBF, what then gives R(t) added value beyond MTBF if seemingly the only difference is that we’re including duration as a variable and expressing the result as a probability?
Regards,
Bill
Hi Bill, good question. first off R(t) is the probability of an item surveying over a duration, t. Change the duration, t, and the probability changes. R(t) is not a function of t and MTBF. (that made me wince)
For the exponential distribution R(t) is exp[ – lambda t ] or exp [ – t / MTBF ] we often use the Greek character theta instead of MTBF as it really is just the parameter which defines the exponential function.
For the Weibull distribution R(t) is exp [ – ( t / eta ) ^ beta ] similar to the exponential yet with two parameters, beta and eta. The Weibull function is handy as it can describe decreasing, steady, and increasing hazard rates, unlike the exponential distribution.
R(t) exists for many different probability distributions, as does a cumulative distribution function, hazard function, and probability density function. None rely on or have to use MTBF (and one shouldn’t use MTBF if working on reliability engineering type tasks or at all, of course.)
Depending the shape of the probability distribution the probability of failure for the first 100 hours of an item’s use may be very, very different. Assuming it is described by the exponential distribution is the source of many very poor decisions.
Hope that helps.
Cheers,
Fred
Use of Reliability also makes for a really good comparator when evaluating alternative designs as it tends to get away from the ‘averages’ that clients often like, but don’t understand. Outside of continuous processes, systems very often have use cycles; so that is very helpful to know how likely it is to make it through a cycle. Depending on the length of the cycle and the life of the item, aging starts to be significant so that reliability is now a real player. Understanding this is a big driver for establishing maintenance and support: mean availability based on MTBF and MTTR is not a good way to plan resources!
Well said Gerald, thanks. cheers, Fred
Good day,
In a maintenance environment, is MTBF not the key in ensuring that the equipment stays longer in operation and fails less than R(t) which is the element of product or equipment design?
Hi Bafana,
Just because MTBF is in common use does not mean it is useful or important. MTBF and similar measures are easy to use and just as easy to misunderstand. For example, MTBF is an average – the average of the rate of failure depends on the underlying distribution. Assuming we have a constant failure rate – very often not at all true – the average is the 63rd percentile of the exponential distribution.
If the actual distribution is normally distributed, the average is 50%. And depending on how skewed the pattern the MTBF could be the 10th or 90th percentile. Rather meaningless unless we know the underlying distribution describing the arrival rate of failures.
MTBF does little more than mask what is going on and more often than not, provides misleading information.
Instead focus on understanding the time to failure pattern and if it is increasing, decreasing, osculating, or some other pattern – then take the appropriate actions to make improvements. There are many graphical and statistical tools available that provide a much clearer picture of what your system is doing. Any that use MTBF is not one of them.
cheers,
Fred