It’s Friday afternoon and the phone rings. It is another customer complaining about your product not working. This is the fifth call this afternoon. Something is wrong and you’re responsible for making it right.
The natural failure analysis process starts across your team. Gather information, determine the scope of the issue, work to understand the root causes, and implement an appropriate solution. This may involve stopping production, halting shipments, or even a product recall.
Initially, you just have more irate customer calls than a typical Friday afternoon.
Sample of issues
Products fail. And most products are a collection of components supplied from other organizations. We trust our vendors to provide reliable parts. Sure we may do a range of tasks to ensure the suitability of the components for use in our product, yet things do not always work out as expected.
The supplier may have changed their process and thinking it would not impact performance not alerted you to the nature of the change. The transportation process to your factory may damage some of the parts. Without incoming inspection, which is generally not cost effective, it may be our customers that first find the problem.
Missing ingredient, faulty plating, excessive vibration, all are examples that may cause a component to fail for your customer by having a latent defect that passes your assembly and testing process.
Component vendors create components that for many customers. A resistor or flange company knows that basic use of their products, not your use specifically. They may work with you to evaluate the use of their component in your application, yet you probably do not do this for every component.
If you overly constrain your supplier and basically ask for and receive highly customized parts, you also take on the liability for failures. It’s basically your design.
Component suppliers also rarely receive sufficient information about field failures. They find out their component has caused a failure, yet may not receive sufficient information about the environment, use, and root cause details. The component that fails may just be a victim of some other part’s abnormal behavior.
I’m not suggesting that suppliers and you conduct 100% inspection in every case. When looking for part per million defect rates, this is not cost effective and may cause more damage and result in higher failure rates. Yet, do we need to accept the field failure rates we experience and the occasional batch of bad parts?
One other issue that is common is not every vendor is an expert with the technology they produce.
They may not have the deep technical knowledge to assist you in determining if the product will work in your application. They may not have the ability to truly determine the root cause of component failures. They have been responding to cost reduction requirements for so many years, they no longer have the resources to assist you as needed.
Trust and Verify
To solve the problem of customer complaints on Friday afternoon, you really need to start very early in the development process. The hardest thing to do is stop making the assumption that the vendor will always provide highly reliable parts for your product.
You are already doing risks assessment tasks such as FMEA and HALT, now extend that to your components. If they exhibit weakness, either ask the vendor to improve the component design or assembly process or find a new solution. If testing just 10 prototypes and one failure due to a faulty component, that may represent a 10% defect rate from that supplier that is probably not acceptable. Do not assume the problem will go away.
In some cases, you will have to become the expert with the component technology and assembly process to identify where and what to monitor. Moving the quality control to as early in the process as possible does take intimate knowledge of the technology and process, yet provides the most cost effective means to receive good parts.
One other option is to conduct a random and detailed analysis of the component, then share the results with your supplier. I call this trust and verify.
For example, for electrolytic capacitors, the formulation of the electrolytic solution is critical to the reliable performance of the component. Therefore, take a component or two and conduct a detailed chemical analysis of the solution. If it changes, ask why (and hold the batches from that vendor till you get a satisfactory answer).
The trust and verify requires the knowledge to know what to look for in the component. This could be compositions, assembly defects, or the tensile strength. The testing in not lot acceptance testing nor statistically based. It is a check for major or minor shifts in the supplied component.
The value is mostly in letting your suppliers know that you are watching and have the capability to detect unannounced changes. It also helps you build and maintain the technical knowledge.
Years ago I heard about an interesting program. Built into the supplier purchase contract is the clause that if the component leads to a system failure, the cost of the system, not the component is payable by the supplier. If a $10 power supply cases a $5,000 workstation to fail. The power supply vendor pays the $5,000 replacement cost.
This may or may not work for your situation, yet working to include more accountability back to your suppliers is one route to improving the attention they pay to sending you reliable components.
The final note is on change management. Change happens. We look for and implement cost reductions, we respond to part obsolesce, or work to improve or add new features to an existing product. We and our vendors make changes to assembly, packaging, transpiration, and designs.
Does your change management process explore the possible ramifications of the change as is commonly done during development? Do you have the resources and knowledge to fully judge the impact of the change?
Most teams have a change management process, yet lack the appropriate knowledge to effectively judge the impact of the change. Yes, it may take time and experimentation. It should be part of your plan.
We build a product based on assembly components into our design. We rely on vendors to provide reliable parts. Building a system based on fundamental material and process knowledge and open discussions with your suppliers will not solve all component related failures. It sure will reduce them though.
Letting your customer find component failures is expensive. You have alternatives to just taking customer calls on Friday afternoon. Think through the entire process and focus on the areas of significant risk first, then work through to every component. Even a simple capacitor can cause a system failure. In short, avoid too many assumptions.