The way we think and act concerning creating a reliable product or system defines the reliability culture of an origination. I trust your organization doesn’t complete the design then ask the reliability folks to ‘add the reliability element’ or ‘test to prove it’s reliable enough’.
Another ineffective approach is to perform many reliability-related tasks, like a design FMEA, HALT, ALT, derating, margin and environmental testing, life testing, demonstration testing, etc More is not better. If the focus is just doing the list of tasks, with little information acted upon, then this approach is little more than a waste of resources.
So, what is it that makes a wonderful design for reliability program? It’s not expecting the reliability team to do it on their own, nor is it checking off a long list of tasks. It is the focus across the organization, inside and outside the design and development team, that each decision made has an impact on reliability performance. As such, the work of the DfR program is to enable each decision to be well informed concerning the potential impact to reliability involved with the pending decision.
DfR is Not Doing Reliability During Design & Development
Creating a reliable product is part of the process of creating a product. These are not two different processes that are independent of one another. A team that focuses on creating a design without considering reliability for three days, then shifts to doing reliability the other two days, is missing the point of DfR.
The eventual reliability performance of a system is a direct function of the decisions made during the concept, design, development, supply chain origination, maintenance plans, etc. This includes decisions made by the marketing, sales, finance, and other teams across the organization.
If the marketing team sets the expectation that the new product will work without failure for 10 years, and the technology is fundamentally not capable of serving that long, then you will not meet your customer expectations concerning reliability.
The finance team may over or underestimate the costs associated with warranty accruals unless well informed concerning the expected field reliability performance.
Selecting a vendor for a key element of a product based on cost alone may have money due to a lower bill of material cost. Yet, the costs due to increase field failures may quickly erase the supply chain based savings.
The ability to design a reliable product involves decisions across the organization, and, yes primarily the decisions within the design and development teams.
DfR is More Akin to Reliability Thinking
If deciding on which vendor to supply a component, cost and ability to supply the expected quantities is common, yet does the person also consider the differences in reliability performance of the components within your system?
Before any analysis or testing, the team that considers reliability as an input to each decision is well ahead of a team that does not do so. Considering reliability, how your product performs over time in the hands of your customers is just the start of a great DfR program.
Increasing awareness of the range of decisions that have an impact on reliability is a good place to start. Include tools and information that enable the wide range of decisions to be well informed. Build an infrastructure that provides the necessary information (cost per failure, cost of failure per unit shipped, for example) to allow each decision to balance the many factors involved with each decision.
Traits of a Great DfR program
I once worked for a general manager that typically responded to any proposal or decision with ‘show me the data’. He wanted to know what we knew and how we knew it, when considering how to frame a decision.
This is a key trait of a great DfR program, detailed and supported reliability work is both expected and done as part of nearly all decisions across the organization. We need to know how will this decision impact reliability performance and how do we know has to become common practice
The second trait is the lack of a fixed list of tasks or tests. Instead, the team understands, not just the reliability team, which tasks or tests are best suited to gain the necessary insights and information to inform an important decision. (not a reliability decision, that doesn’t exist on it’s own).
Other traits include the lack of a separate reliability plan, it’s just part of the product development plan. The pull for reliability information to inform upcoming major decisions. The balance of short-term cost reductions and long-term impacts. The coordination across teams to insure targets, metrics, and goals do not ignore the desire to create a reliable product.
A great DfR program is a culture across the organization that simply incorporates reliability thinking naturally, as it’s important and beneficial to do so.
Leave a Reply