Not much. You need just enough field failure data to identify the root cause and determine if and how to resolve the problem.
Field data will accumulate even if your program works diligently to prevent failures.
The actions taken before the reported failure will frame when you need to take action.
Gathering failure data and evaluating the trigger points for action is a reactive approach. This approach means you will only respond to problems.
You will also likely not spot the important emerging issues before they become significant problems.
The meaning of field failures
A failure in your customer’s hands is your product not meeting your customer’s expectations.
Not all field failures result in a call, return, or complaint. Therefore, the failures that you do learn about become critical sources of information about how well your product is or is not meeting expectations.
A field failure is what the customer calls a field failure.
You do not have to reproduce the failure, nor confirm it was due to negligence or abusive use to reclassify the failure to something else.
If a failure costs you time or money, it is a bit of information you cannot ignore.
A failure in your customer’s eyes is not limited to hardware or software elements of the system.
I once received a product return because the box said it was 100 meters in length, and it was closer to 103 meters. The length should match the labeled length, else it is a failure according to this customer.
A failure could be a problem with the advertising, ordering process, or assembly instructions.
A failure that is hardware or software related may be harder to remedy, yet any failure is a symptom of a process failure in your organization.
Every failure contains information
A failure provides an immense amount of information if you look. Each failure may include:
- Symptoms noticed by customer (what they deem a failure)
- Environment and use conditions surrounding the product
- Functional and duration expectations
- Consequences of failure (safety, collateral damage, loss of function, etc.)
- Time of failure (along with manufacture or installation date)
- Root cause of failure
- Condition of elements that have not failed
- And, more
Beyond tracking time on customer service calls or cost of repairs, track the essential information you need to understand the how, why, and when of each failure.
Finally, this information is valuable, so make it easy for your customers and your organization to gather and report.
It is important to remedy the issue quickly with your customer. It is vital you have the information to resolve the current problem and prevent future issues.
Economics of root cause analysis
Not addressing a field failure not only allows ongoing warranty claims, but it also erodes your brand loyalty and market share.
Not addressing the right true cause(s) of a failure wastes design and operations resources that may exacerbate the actual problem.
Using the component switch and check approach may find the damaged component. It may or may not lead to a root cause of the failure. Components can fail as they are the hero or victim of a fault elsewhere in the product.
Sending the identified part to a vendor may lead to a prompt and efficient solution. It also may lead to an extended time of little information and no resolution. Instead, use an internal or a contracted failure analysis laboratory.
Sure it will cost a bit, yet in short order, you will have a clearer root cause understanding, then you can move to effectively solve the problem.
Class defect versus isolated anomaly
When faced with a unique field failure, or even just the first (or only) reported issue, do you spring to action with a full root cause analysis and line stoppage till it is sorted out?
Most of you would not do this for a single reported failure.
If the failure caused a death, you would immediately investigate in detail. Hopefully, this is a very rare event with your product.
If the failure was from an important customer and they demanded an investigation, you would start immediately.
Addressing the problem may be a business decision and not motivated by a desire to improve your product.
Once you have compelling information that a significant portion of fielded products will fail, or you experience an increased rate of returns, you likely will take action. This may be too little information too late to thwart the impact of the class defect.
Starting your response to field failures well before shipping the first product can help.
During the design and development, you identify reliability risks, you find and resolve problems, and you also identify and do not solve problems.
The issues you resolved provides a database of failures that you know fairly well, and if they appear even once in field failure data, that should be a surprise requirement corrective action. Just one failure of a known “solved” issue is a cause for alarm.
Think about it, you identified an issue and chose to spend resources to solve the issue.
The failure provides evidence the issue was not solved. Something went wrong and the risks to product performance, warranty costs, etc. now are all back on the table.
In some cases, we can only mitigate or ameliorate an issue to reduce it’s frequency or time to failure.
Did the failure arrive as expected after the expected duration given the conditions? If it is early — again even just one failure — means something went wrong with the process to solve the problem.
Finally, some problems have not been seen before. Customers are creative that way.
Given the work to understand and solve as many issues during the development phases, a new type of failure will require root causes analysis. Even on just the first one reported.
You may decide not to resolve the issue with a design or process change, as you determine the failure will be an infrequent source of failures.
Do not base your actions on opinion, rather on the root causes analysis and good reliability engineering work.
How much failure data do you need?
Just one field failure is all you need to take action. You should take action given just one field failure.
Waiting to confirm that cracked capacitors due to board bending will cause 5% or more units to failure, may require you to wait till 5% or more fail. Instead, with the first cracked capacitor, you can identify the source of the board bending and stop it.
Immediately reduce the chance for capacitors to crack.
You still need to deal with the existing products that are at risk of failure.
If the root cause is not identified and solved early, you continue to produce systems with some fraction including defects leading to failure. Working to solve the root cause of the initial failure may lead to short and long-term improvements to your process to create reliable products.
Just one field failure is all you need to get started and make a difference.
How do you know when to take action? Add a comment and share your best practices.
Related:
Failure Analysis: The Key to Learning from Failure (article)
Field Data and Reliability (article)
Field Data Analysis First Look (article)
Leave a Reply