Featured Video
This Week in Quality Digest Live
Metrology Features
Ryan E. Day
Simplified workflows and improved features are key to managing growth
James Rawstron
Jet wing surface scan reduced to under four minutes
Michael Huda
How do you control a color that absorbs so much light, spectrophotometers can’t measure it?
Matthew Martin
Traditional CMMs are being challenged by fast-emerging, highly advanced blue-light scanning
Dirk Dusharme @ Quality Digest
Christmas is creeping, should a four-year degree really be the minimum requirement, and what we learn from Disneyland

More Features

Metrology News
Four times faster data acquisition, enabling precise measurement at the submicron level
Caters to the growing need for sophisticated scanning in an entry-level solution that is budget friendly
Topics for the Go Forth and Measure project are virtually unlimited
Ask questions, exchange ideas and best practices, share product tips, discuss challenges in quality improvement initiatives

More News

Fred Schenkelberg

Metrology

Three Ways to Provide Field Reliability Feedback to the Design Team

Applicable to any program at any time

Published: Monday, August 1, 2016 - 23: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.

Discuss

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.