When is the last time you thought about APQP/PPAP? Advanced Product Quality Planning and Control Plan (APQP) was originally printed in 1994 with the second edition in 2008. Production Part Approval Process (PPAP) was originally issued in 1993, the second edition in 1995 and the third edition in 1999.

In the past 17 years, from 1993 to the present, computer technology has done amazing things. Basic office software has done wonders to help fill out and standardize documents. There is no excuse for not having professional looking documentation that is organized and easy to produce.

First, assume the following:           

1. You have read and understood the latest document.

2. Your organization has a quality system with documented procedures.

3. You can map your processes to the latest APQP and PPAP documents.

4. You understand the requirements and documents required regarding APQP and PPAP from customers.

5. You have standard tests that are done as part of the product and process development process.

6. You have a good relationship with the customer.

If this is not true, please take the steps to remedy this. Engage the whole organization.

Over the years, PPAP has become more widely known than APQP. However, in auditor talk, PPAP is really the evidence that APQP has been executed. APQP states “Product quality planning is a structured method of defining and establishing the steps necessary to assure that a product satisfies the customer.”

APQP includes sections on the following:

1. Plan and define program

2. Product design and development

3. Process design and development

4. Product and process validation

5. Feedback, assessment and corrective action

6. Control plan methodology

Warranty

Enlarge this picture As this warranty projection chart shows, warranty is a huge line item on annual reports. IPTV stands for incident per thousand vehicles. Quickly addressing and preventing warranty issues puts money right to the bottom line. Source: Lou Ann Lathrop

How does one test that the product satisfies the customer? Start with the things-gone-wrong category first: warranty.

Get the warranty data for the products in question and look at warranty from the paradigm of every warranty issue is an unhappy customer.

When one looks at every data point as one unhappy customer, the data is staggering. Act as if that customer is yourself or a family member. Now act as if you are the owner of the company: how can you react to help prevent the problem from ever happening again?

A lot of data, and relatively recent data, is available. Get all of the data possible. Get every part back and run through a standard and rigorous failure analysis as new model years are started. Do this for the entire model year. Get trend data on a regular, monthly basis and review. Understand the data, and what affects it. Learn what is driving the numbers. Understand the concepts of statistical process control.

Compare the warranty data of all the company’s products against each other, compare and contrast the data, and figure out why some products are better than others. This fulfills the requirement of benchmarking.

Understand and Pareto the causes of warranty issues. Do deep dives to find permanent and irreversible corrective action. Predict the improvement in warranty by understanding current warranty and what is driving it. Look at all upcoming changes that will address warranty concerns to predict a projected warranty. Implement as soon as possible—the sooner the better. Make sure all appropriate change management procedures are followed.

Warranty is a huge line item on annual reports. Preventing warranty issues or quickly addressing them puts money right to the bottom line.

Validation Processes

Enlarge this picture This is an example of a warranty chart comparing model years. Manufacturers would do well to learn what is driving the numbers and understand the concepts of statistical process control. Source: Lou Ann Lathrop

Another area that has had increased visibility and produced good results is having robust and standard validation procedures. The definitions of validation have shifted from a final inspection to a built-in quality—or engineered in—perspective. What is the particular test validating? Is it for quality, reliability and durability and/or performance and function? Analysis, development and validation (ADV) is General Motors Corp. (GM)’s interpretation of APQP.

Setting a rigid time in the program for validation test complete dates can help drive the entire organization to a new level of performance. Just waiting for PPAP deadlines is not enough. Documentation for tests, or the evidence of, also should be completed.

One may hear the terms: validation testing complete (VTC) and validation documentation complete (VDC). All supplier testing, all component testing, all sub system testing completed and all vehicle level testing are rigorously tracked for completion. Every test result from validation testing should be rigorously reviewed and scrutinized. There are very few test properties these days, so every test and test result counts.

The tests are run, so it would be a waste if the results were not studied to every last detail. The test properties should be autopsied in detail.

Over time in every commodity, a specialist should gather criteria, with pictures of what is good, bad and in between. This could be called end of test criteria; years ago in electronics manufacturing it was called workmanship standards. It could include pictures and measurements of what makes a good solder joint, a marginally acceptable solder joint and bad solder joints. Having detailed criteria and adding to this documented criteria helps to capture lessons learned over time.

In 2003, GM hired retired Toyota executive Tatsuhiko Yoshimura, an expert in vehicle durability, to critique GM’s procedures.

Enlarge this picture It is important to understand the concepts of statistical process control (SPC). SPC is a critical, often overlooked and forgotten knowledge. Source: Lou Ann Lathrop

Yoshimura, in his writings to leadership, would say any meeting where there were no parts to look at is a waste of time. He extolled his concept of what he called GD3: good design, good discussion and good dissection.

Good dissection was embodied by the process of DRBTR: design review based on test results. He wanted everyone on the team to see the test properties and have a good discussion around them. Discussion and actions are to be documented in a report. Issues and buds of problems are summarized and documented.

The same type of review can and should be conducted with virtual parts using today’s latest computer-aided design (CAD) and analysis tools. Stack-up analysis of parts also should be part of the standard process. If suppliers do not have these tools, they should find the people at the OEM that have this capability and responsibility. Maybe they can run the analysis and provide the supplier with the detailed information.

Lastly, Yoshimura required a climate of sharing failure information and had a seven-item checklist to assess a company. (See Checklist on pg. 40). The checklist is to assess the climate of sharing failure information. Is the environment a learning environment, or is the system closed down to sharing? This is similar to one of Dr. Deming’s 14 points to “Drive out fear, so that everyone may work effectively for the company.” This type of culture has always been implied and required for both APQP and PPAP; without this, APQP and PPAP processes will be cumbersome rather than the corporate strength that it could be. Q

Tech Tips

• There is no excuse for not having professional looking documentation that is organized and easy to produce.
• A thorough review can and should be conducted with virtual parts using the latest computer-aided design and analysis tools.
• If suppliers do not have the proper tools, they should find the people at the OEM that have this capability.

Tatsuhiko Yoshimura’s Climate of Sharing Failure Information Checklist

1. Does top management feel that a problem caused by his subordinate is his problem?

2. Does top management reprimand the subordinate causing the problem from the standpoint of a customer?

3. Has top management directly talked to the person causing the problem or his superior on the cause of the failure—at the work site, with the actual part in hand?

4. Has top management discussed the cause of failure with the person in charge from the standpoint of an engineer?

5. Does top management praise those responsible when the cause analysis and measures to correct the failure were good?

6. Has top management made it a routine practice to discuss examples of how he learned from the past failures with his subordinates?

7. Does the company have a process to make failure examples a corporate asset?