Field Failure Tracking System Setup

Field Failure Tracking System Setup

DEFINITION

A Field Failure Tracking System is a method for collecting field data for the purpose of calculating the field reliability of the product and analyzing for trends.

SITUATION

The client wishes to reduce product warranty repair/replacement costs. Alternatively, the client wishes to increase the product warranty period for competitive advantage. The client does not have an understanding of failure percentages or failure modes over time.

OBJECTIVE

Establish a data set that tracks the products failure history over time for the purposes of:

1. Isolating failure modes relative to time in the field for failure mode analysis;
2. Monitoring current health of product or system in field;
3. Predicting warranty cost exposure over the life of the warranty.

VALUE TO YOUR ORGANIZATION

Identifying failure percentages relative to failure modes as a function of time in the field is key to the sustaining engineering effort to increase product reliability for:

1. Customer satisfaction
2. Decrease or control of program ROI
3. Decreased warranty costs.

RELIABILITY INTEGRATION

An example of Reliability Integration during the Field Failure Tracking System Setup is as follows:

During the data collection process, we will compare field results to predicted results to:

• determine if the results are within an acceptable range.
• develop a prediction-to-field factor that may be used on future projects.

METHODOLOGY

Develop method to “mine” client’s Relational Data Base Management System to establish field metrics.

1. Determine “front end” access data from applications (order entry system, RMA tracking system, etc.). What data is currently available? What language does the RDBMS speak (SQL, VBA, C++, Java, etc)?
2. Establish parametric model in conjunction with client’s technical staff.
3. Write system to extract data from the storage mechanism (Oracle, Siebel, etc.).
4. Organize data to present multi-view model.
5. Analyze data in conjunction with client’s technical staff and report results.
6. Provide technical training on how the data is organized, what it means and how to use it.

CASE STUDIES/OPTIONS

The following case studies and options provide example approaches. We shall tailor our approach to meet your specific situation.

1. Extracting from a different data systems to a RDBMS system for analysis

   A large company was in need to figure out why a customer was having a large fall out of products in their application. It was unknown what was happening and the company was uncertain if their fulfillment process, design or their manufacturing was at fault. By using extracts from their ASK system to a SQL RDBMS and then by taking the data that described both shipments and returns by region, manufacture location, manufacture datecode, and calendar date, we were able to track the product issue to a deviation in the manufacturing issue and isolate the problem from a full recall to a small isolated datecode range replacement, saving the company millions of dollars in liability.

2. Oracle to Excel Tool

   A midcap company was trying to understand a seasonality issue in their product line. With their tracking system in Oracle, they were collecting data on shipments and RMA’s that included information on region, datecode, manufacturing location and part mix for the given program. We were able to design a model for gathering their data from the SQL environment to Excel that allow us to view the data by datecode, region and part mix that isolated the failure mode to a component manufacturing process change that was not announced to the parent company until after the product had shipped into the market place. This helped our client to isolate the problem in the field and assign liability on the component manufacture for not specifying the change and giving the company the time to qualify them. This avoided a large scale recall and a replacement campaign was initiated.