Everybody Uses MTBF, Really?
I don’t.
When you say ‘… uses MTBF’? What is it you’re implying? Do they make important business decisions, or assess product designs, or order spares based on using MTBF?
Probably not.
When you use MTBF, what do you use it to accomplish?
- Do you write a report and send it to the requesting team?
- Do you run a calculation and provide the resulting MTBF to customers or vendors?
- Do you or anyone in your organization use MTBF in a useful manner.
And, if so, does it work for you? Does MTBF actually provide a useful metric related to your product’s reliability performance?
In my experience, MTBF and related metrics are great for meeting requirements or fulfilling requests, not much else. They are not useful for decision making. MTBF is next to useless when ordering spares. And, it is so commonly misunderstood that the report values are often simply misleading.
Do you receive request for MTBF from customers or internal teams? What do they use MTBF to accomplish? Check of as done?
Some may claim they use MTBF as a comparison to previous products. Some claim it provides an insights to the expected reliability performance. Some really do not know what do with MTBF so just ignore the value.
When gathering data for a part count prediction (aka Mil Hdbk 217 or similar) do you request MTBF values? Is so, do you also ask about failure mechanisms, derating parameters, or how/what will most likely fail?
Simply taking the MTBF value provided reinforces that notion that ‘everybody uses MTBF’ and does not provide you or your team useful information.
Data sheets, vendor websites, reliability reports, etc. all contain MTBF (sometimes called life, or reliability, yet the most common reported metric is MTBF or something similar).
MTBF is around us, built into tools, and expected. My contention is that even though it is not useful, it is so common, that it is assumed everybody uses MTBF.
Don’t be Everybody.
You will do a better job reporting reliability as couplets of probability of success and duration, rather than MTBF.
Do something that is useful and easy to use. Do not use MTBF. Be better than everybody. Add value to your organization, to your team, to your customers. Help others by your example, to be like you and not like everybody else.
useful insight in reliability
thanks!
“Right is right even if no one is doing it; wrong is wrong even if everyone is doing it.” This has been attributed to St. Augustine and William Penn but is appropriate in the No MTBF discussion too. Just because a lot of people are using and mostly misusing and misunderstanding MTBF doesn’t make it the right thing to be using/doing.
thanks Dan, great quote. cheers, Fred
I understand that mtbf is a rubbery figure that can be manipulated to any value you wish to see or that values furnished by COTS suppliers are mostly without any insight as to how the value was generated. However, how can relaibility be determined/calculated without a failure rate/mtbf figure? How can a spares optimisation analysis be conducted (say using OPUS) without the key input parameter in failure rate/mtbf? What does Systecom (OPUS developers) have to say?
Hi Eddy,
Keep in mind that failure rate is only one of four elements for a reliability goal or statement. If I say the failure rate is 50,000 MTBF or as FR 1/50000 per hour of use – then if I’m interested in operating only an hour, that is pretty good. If not he other hand I want to operate with out failure for 20 years, it’s pretty terrible.
What temperature or related stress? What use conditions and loads? What function or set of functions?
I use probability of success and often select three couplets of time and probability. Early life goal, warranty or mission goal, expected operating life goal.
The key parameter is the chance of failure (or probability of success) and duration – they always have to be asked for and provided together.
I agree, MTTF & MTBF are good for scorecards but decision making shall be made based on more accurate data.
MTTF and MTBF are also not very useful for scorecards, as that is a prime location to base decisions.
cheers,
Fred