Dealing with Field Data
Abstract
Carl and Fred discussing use of field data in reliability programs.
Key Points
Join Carl and Fred as they discuss when and how to use field data in reliability programs.
Topics include:
- When to use field data on new projects
- What portion of field data is applicable (similarity, functionality, conditions of use, etc.)
- Field warranty noise
- Field warranty cost vs frequency
- FRACAS and field data analysis
- Three dimensions to field data anaysis: how similar is field data, what are the field data metrics (cost, frequency, etc.), how much noise is in the field data.
- Use field data analysis to avoid repetition of past problems
- Design guides
Enjoy an episode of Speaking of Reliability. Where you can join friends as they discuss reliability topics. Join us as we discuss topics ranging from design for reliability techniques, to field data analysis approaches.
/
RSS Feed
Show Notes
Please login with your site registration to download the 1 page PDF previous survey results.
Login
If you haven’t registered, it’s free and takes only a moment.
Hi Frank,
Love the topic and conversation. Thanks to both you and Carl for sharing your knowledge.
You discussed how Design notes or Design guidelines can help with design-for-reliability at early stages of the development process. My question is, how did those notes get in front of the right person at the right time to help them make a good design decision? Were there application or part specific libraries that engineers were required to check before moving forward with a design decision? Were they documented in specifications or prints? How were those “golden nuggets” saved and presented so that the critical wisdom was guaranteed to be passed along?
You gave the example of Phil who made sure cracked capacitor issues were addressed in his project, but this was really an example of a single person with a passion to make sure a specific problem was solved. I’m wondering if there are PROGRAMMATIC best practices here that you have seen used before?
Thanks!
Hi Joel,
Thanks for the note and questions –
First, the lessons learned process called ‘Golden Nuggets’ is a process of finding suitable lessons that would benefit with routine reminders – and the interaction of a person with ‘veto’ power related to product launches – to meet with the person setting the project resouces and provding the tasks/schedule for the team. Here’s a bit more on it in an article https://lucas-accendo-site-speed.sprod01.rmkr.net/lessons-learned-via-golden-nuggets/
On design notes/guidelines – this one is trickery as it often requires a culture that wants to use the notes/guidelines as the members acrsoss the team understand the value of getting reliability right, right from the start.
In the best situations, I’ve seen routine training of all engineers and managers on DFR techniques, including guideline use. Along with wide spread distribution of notes/guideliens, along with meaningful technical support for any questions concerning the use of those guidelines, plus, and this one may be the most important, a local to the design team, a reliability champion (may or may not be a reliablility engineer) that encourages using guidelines and helps discuss applications and exceptions. The champion may be part of the design review team and encourage the use, etc.
Another approach, depending on the culture, that sometimes works is if the project manager and/or director of engineering encourage, expect, and reinforce the required use of the DFR guidelines.
When I was at HP we had electrical derating, thermal design, and environmental considerations/testing guidelines. In the best reliability performance teams these were dogged eared and routinely used by the development and design engineers. It was what they did, it was how they went about creating a design. In other organizations, the use of guidelines was still a work in progress with pockets that used them.
The trick, I think, is to be sure to document the use and related benefits – find examples with your teams were this happens and make sure they get credit for their DFR work. The product will just work, and that doesn’t typically happen unless there is a widespread and routine use of DFR guidelines, IMHO. By just working, it may not be noticed what caused that to occur.
cheers,
Fred