Featured Video
This Week in Quality Digest Live
Metrology Features
Amanda Hunt
CNC milling machines are considered the ideal solution for preparing tensile specimens
Ryan E. Day
FARO’s Cobalt Array Imager helps Hubbell speed up FAI and time-to-market
Scanner runoff event pushes new standard toward the finish line
Dirk Dusharme @ Quality Digest
I'll believe it when I see it in my AR goggles
Mike Richman
The framework of the smart factory takes shape

More Features

Metrology News
Robot-served vision, new force-testing products, and electronic gauges at booth No. 135532
Machine demos, technology previews, and a daily happy hour at booth No. 338319
Other exhibits will feature machine tools to demonstrate tool setting, probing, machine monitoring, and robotic gauging
Marposs Mida Laser 75P Hybrid combines a noncontact laser and touch probe in one system
LEXT OLS5000 3D laser confocal scanning microscope received a Silver award

More News

Fred Schenkelberg


Three Ways to Provide Field Reliability Feedback to the Design Team

Applicable to any program at any time

Published: Tuesday, August 2, 2016 - 00:00

Spending too much on reliability and not getting the results you expect? Just getting started and not sure where to focus your reliability program? Or, just looking for ways to improve your program?

There’s not one way to build an effective reliability program. The variations in industries, expectations, technology, and the many constraints shape each program. Here are three suggestions you can apply to any program at any time. These are not quick-fix solutions, and neither will you see immediate results, yet each will significantly improve your reliability program and help you achieve the results you and your customers expect.

1. Stop using MTBF

I recommend not using mean time between failures (MTBF). The same applies to mean time  to failure (MTTF), mean time between unscheduled removal (MTBUR), and the many variations of MTXXX that exist. The primary reason is MTBF is not useful. It doesn’t help you and your team make decisions that lead to improving reliability.

The focus should be on balancing what you know about the performance and your other priorities. Although you may have fantastic cost-of-goods data, reliability data are often vague. Don’t cloud that scant information by obscuring what it means using MTBF.

Instead, use reliability directly. The function performs within a defined environment with a probability of success over specified duration. For example, my phone has a goal of making and receiving calls in my home office with a 99-percent probability of success over five years.

Use reliability:
• To set goals
• Do apportionment
• To set vendor requirements
• For comparisons
• To define and report reliability tests
• Anywhere you talk about reliability

The clarity alone will improve your reliability program.

2. Do your failure analysis

When something fails in a prototype or fielded product, you need to understand what failed. Not only that, you must know the root cause of the failure. To implement a design, process, or assembly fix to address the failure, you need to understand what happened.

Isolating the failed part and sending it off to the vendor for analysis rarely works. Vendors rarely have the capability to determine the root cause of a failure when looking at an isolated part or two. The failed component may be a victim of poor design or another element that has failed.

The element that fails may have design or assembly problems. It may be that the part downstream for another item of the product isn’t functioning properly. We don’t send blown fuses to the vendor for analysis. Instead, we look for the cause of the excessive current.

Instead, work with a third-party failure analysis laboratory directly. You’ll likely get answers faster; you’ll also likely learn more about the potential root causes, especially if the root cause is part of the vendor’s design or assembly process. It’s your failure analysis, so you need unbiased information to allow you to determine the appropriate corrective action.

3. Identify reliability risks early

Product testing, reliability testing, or demonstration tests are too little too late in most cases. You can’t afford to test in reliability, especially when it’s done late in the development process.

Also, simply testing a product may or may not reveal novel or rare failure mechanisms. Sample sizes alone prevent finding significant issues; not being able to detect precursors to serious problems is another thing.

Testing is not a great means to identify reliability risks. Instead, use tools like FMEA and highly accelerated life testing (HALT) early and often in the development process to help you focus on failure mechanisms that present the most risk to the reliable performance of your product. Give your development team time to focus on solving or mitigating the reliability risks facing your product.

These are just three suggestions. I’ve seen each of them make significant improvements to reliability programs in diverse industries.


About The Author

Fred Schenkelberg’s picture

Fred Schenkelberg

Fred Schenkelberg is an experienced reliability engineering and management consultant with his firm FMS Reliability. His passion is working with teams to create cost-effective reliability programs that solve problems, create durable and reliable products, increase customer satisfaction, and reduce warranty costs. Schenkelberg is developing the site Accendo Reliability, which provides you access to materials that focus on improving your ability to be an effective and influential reliability professional.