Field Data and Reliability

Customers experience product failures.

Understanding these failures that occur in the hands of customers is an essential undertaking. We need this information to identify increasing failure rates, component batch or assembly errors, or design mistakes.

Our work to design for reliability includes assumptions about customer expectations and use stresses.

The field performance either validates our work or illuminates the errors. Our work to select suppliers and build a stable assembly processes attempts to identify the highest risk elements for reliability (and quality) with plenty of assumptions. The field performance again validates our work or illuminates the errors.

The field reliability performance impacts the business directly. Customer satisfaction, brand loyalty, and warranty expenses. The business objectives hinge of reliability performance.

Customers may expect product improvements even if they did not experience the failures personally. The internet provides many venues for customers to compare notes and discuss failures.

Customers increasingly do not simply want a replacement they may demand an improved design instead.

The Nature of Field Data

This data is never perfect.

It is better than anything we create in the lab though.

Field data is actual data.

It is a record of how the product performs for those using the product. All the expectations, stresses, and component variation are present. No sample sizes or confidence bounds necessary.

Part of the issue is we the data from customers is noisy. We do not know exactly when the first turn on or use occurs after purchase. Nor do we know exactly and under what circumstances failure occurs. Often, we do not know the exact failure. Just that a customer reports a failure. Not all customers even provide a complaint or report.

Yet it is the best data we have available.

Find the Field Data

Your organization most likely gathers information about customer experienced field failures. Call centers, return authorizations, replacements, repairs, warranty claims, all provide information on field failures.

Ideally, you will have date installed, date of failure, use conditions, symptoms or failure mode, plus a root causes analysis of each failure to the specific mechanism. Right. More likely we have the date the customer reported the failure, which may not be the same as when it actually failed.

When first looking for the field data, it is often gathered for other purposes.

The databases and records are to help serve the customer and track costs, not to reveal reliability performance. As you and the organization realize the value of the field data analysis, you’ll be able to establish better data capture processes.

Another element of data you require for an analysis is the number of units placed in service, both those that have failed and those that have not failed. The shipments data is often a good source. Better would be records of initialization or turn on.

This may be complicated by delays in shipping and warehousing. Or with the use of units as spares.

Likewise, not all units installed and operated continue to operate indefinitely. This may take some work and investigation to determine the nominal and range of operating durations.

Most simply assume every unit shipped is still operating unless reported as failed.

Gather the Field Data

A common mistake is to simply count the number of returns each month and report the count on a month by month bar chart.

This is easy and generally non-informative. Trends are likely to be caused by variation in shipments as any other reason.

Trends are likely to be caused by variation in shipments as any other reason.

Beyond how many failures occurring do you need to gather the time to failure information as a minimum?

When was it shipped, installed, failed and reported would be great, yet knowing the month of shipment and month of failure is often the best we can do.

The time to failure data allows Weibull analysis or similar to estimate the overall failure rate trend versus the age of the product. Time zero is when installing (or shipped) for each unit. Do they show signs of wear out (increasing failure rate) after 3 months?

The conditions of use and reported failure mode provide a way to Pareto the issues.

Adding the cost to the customer or the manufacturer may provide a way to refine the priorities for improvement work.

Plot the various failure modes or better failure mechanisms with the Weibull analysis as each one is likely to be on a different failure rate trend. Some will indicate early life failures and other may show wear out behavior.

At different points in the age of the product, the Pareto of issues is likely to be different.

 

What happened?

The last but often most useful element of the field data is finding out what happened.

Do the root cause analysis on as many units as possible. Determine the sequence of events or stresses that lead to the product failure. If it’s not possible to redesign or improve the current product, you can on the next design cycle.

We’ll explore how to analyze the data in another article, yet gathering the data is often the difficult part of the exercise.

Do you have good data? Where do you find is the best source of field data?

---

Related:

>Field Data and Reliability (article)

Field Data Analysis First Look (article)

The Next Step in Your Data Analysis (article)