Historically, quality managers have purchased Advanced Product Quality Planning (APQP) software to reduce time spent creating related documentation. The goal was to get the documents to customers in the format they required and still have a documentation trail that could survive an audit.

In the past 12 months, the marketplace seems to have changed to one more consistent with the original focus of APQP. More engineering directors are seeing the value of Failure Mode and Effects Analysis (FMEAs) and Control Plans. Engineers are using these to manage their design and manufacturing processes by examining and then controlling various failure events in their products and processes before the failures arise, rather than creating products that meet minimum specifications and letting the service and warranty departments handle the quality issues.

APQP is a structured product lifecycle management approach to defining and establishing the steps necessary to ensure that a product or service satisfies the customer. It starts at the concept stage with product development and continues through production implementation and continual improvement. The APQP Reference Manual, published first in 1994 by the Supplier Quality Requirements Task Force, is one of the harmonized reference manuals, procedures, reporting formats and technical nomenclature used by Chrysler (now DCX), Ford and General Motors. This effort led to the development of QS-9000 and eventually to ISO/TS 16949: 2002.

The APQP Reference Manual combines the PLM approaches and requirements of the OEMs and participating suppliers and uses the Plan-Do-Study-Act (PDSA) improvement cycle. The purpose of the cycle, according to the manual, is to emphasize:

• Up-front planning. The first three quarters of the cycle are devoted to up-front product quality planning through product and process validation.

• The act of implementation. In the fourth quarter of the cycle, the importance of evaluating the output serves two functions: to determine if customers are satisfied and to support the pursuit of continual improvement.

Although APQP focuses on continual improvement and process knowledge management, the actual implementation focus, more often than not, has been on compliance. The reasons are varied: QS-9000 was built around ISO 9001: 1994, which was element-based rather than process-based; many QS consultants and training offerings were retreads of the element-based ISO consulting and training; and many suppliers wanted to know the minimal effort needed to continue selling to the automotive industry.

With the publication of ISO/TS 16949: 2002, things changed. ISO/TS 16949: 2002 is based on ISO 9001: 2000, which uses a process-based quality management system model, and is more lined up with the PDSA cycle. Organizations with mature quality management systems are starting to use APQP as a prevention and risk management approach.

APQP software should link information together so that a change in the attribute of a product or process is automatically provided to all associated documents. Source: Omnex Systems

APQP software

Software packages developed in support of APQP activities were influenced by the intent of users. Consequently, early APQP software focused on the creation of individual documents to comply with the basic documentation requirements. Because the purpose of APQP software was not to develop process knowledge but, rather, create process documents, each of the various forms were developed independently, even though there are links among the information. Because of this, many companies still use spreadsheet or word processing programs to generate forms. While this may be the fastest approach for single-document development, the effort to ensure individual documents are current and groups of documents are consistent is time-consuming and prone to error.

The next wave of software used a database to store the document information. These programs can provide the reuse of product and process information across several parts. Some provide simple links among the process documents but often with limiting effects. Many programs require that the links be established during the initial setup of the part and process development. After the documents are initialized, creation or modification of links is not possible. Because the focus of these programs is still compliance, this approach is considered an advance over the spreadsheet approach.

An advantage of the database-

oriented program is that the document format can be separated from the information entry. Although the APQP Reference Manual was developed as part of the harmonization activity of DCX, Ford and General Motors, individual divisions and units began asking for their own specific forms, which differed from the standard forms. This multiplicity of forms worsened as organizations began to develop a world market.

With compliance-oriented systems, after the product and process documents are created, they are modified only when the customer changes the product requirements or problems occur. Consequently, the shortcomings of maintaining the collection of process documents with document-based APQP software often is overlooked.

As organizations began implementing the process-based quality management system model, continual improvement became more than a slogan. Organizations use various approaches to achieve improvement from mistake-proofing and process team activities at the floor level to lean and Six Sigma for breakthrough improvement. These initiatives require that cross-functional teams readily have access to all necessary information, regardless of their location.

With organizations achieving mature implementation of ISO 9001/TS 16949 and expanding into the world market, the shortcomings of compliance- or document-oriented programs became evident:

• Documentation development for new products similar to existing products was consuming the same amount of time as unique products. A company supplying the same design to multiple customers must create multiple copies of product and process documentation from scratch, particularly if the customers wanted different formats. Companies using the copy/paste/change approach to minimize development time find that when the process changes, each piece of the individual product documentation must be changed.

Other companies use a set of generic product and process documentation. This also requires another set of addendum documents to identify the uniqueness of each product.

• Documentation development for new products that shared the same process elements was redundant and time-consuming. In this scenario, the same group of equipment produces different parts. The equipment dictates the control of the process, not by the products produced. Some companies try using the copy/paste/change approach to minimize development time but most must develop the documentation from a blank form.

• Product and process information was not readily available to all team members because of limited computer access. With organizations that have facilities around the world, sharing information is difficult. Most traditional APQP software requires access to a single physical workstation on which information to share resides. Even server-based software has difficulty allowing the design group in the United States to share information with the production facilities in remote locations.

• Documentation maintenance for existing products was redundant and time-consuming. Because most APQP software did not maintain links among a single product's documentation and did not share attributes among families of parts, individuals were forced to make changes in each document of each product individually.

• Documentation errors became evident as shortcuts were taken to minimize redundant effort.

• Organizations began receiving nonconformances during surveillance audits because documentation was not consistent.

• Management began asking questions about the documents and the APQP process, but was not receiving valid answers.

As organizations evolved from a compliance orientation toward quality to a process-based quality system model, management began to realize that quality does have a positive effect on the bottom line and that prevention had a higher return on investment than the traditional detection and correction approach. With this realization, management began to ask engineers and production personnel questions that need answers during the APQP process:

• Will the design satisfy all customer requirements and needs? How can the design be improved?

• With a compliance orientation, effort was focused on validation activities instead of verification. Even if the Design FMEA included verification as a design control, because the APQP software did not link the DFMEA with the Design Verification Plan and Report (DVP&R), it would not reflect this activity. Instead, the DVP&R became the validation testing report.

• Will the shipped product satisfy all customer requirements and needs? Without dynamic links among the various process review documents, information entered in one document was not always included in others.

• If a problem occurs, is it known that the problem could have occurred?

• Is the APQP process on track?

Because APQP software packages were developed as document generation tools, the programs do not include project management capabilities. Software developed to manage projects does not interface with the APQP software without manual intervention that is prone to error.

Long-term strategy

To support the PDSA APQP approach and the process-based quality system model, APQP software needs to support a long-term strategy of using the information being collected to manage process variation, support knowledge management activities and produce the needed documentation to meet internal as well as external customer expectations.

From a functional standpoint, APQP software must provide the quick and simple creation of all APQP documentation and a means of approval and revision control and access to such information with minimal effort. This must include the ability to format or reformat the documentation so that it satisfies the needs of the user. Because different users have different knowledge needs, APQP software must be able to create different formats on the fly.

But such a system also must link information so that a change in an attribute of a product or process automatically is provided to all associated documents. Without this dissemination of information, the consistency of related product and process documents and actions always will be questionable. Consider the impact of a change to the measurement evaluation technique on the Control Plan without updating the corresponding shop-floor documentation. This not only affects product quality for a specific operation and impedes any improvement efforts implemented by the process team, it also could generate non-conformances when reviewed by the internal quality and surveillance audit teams.

Collaboration and accessibility also play a key role in the sustainability and success of the APQP system. Changes made to specific design or process information need to be shared and studied by the team. Comments and results of changes to documentation can build a database that can be used to verify that the system is working. Throughout the APQP process, it is critical that the terminology used by the cross-functional teams is standardized. Without this uniformity, the PDSA approach lacks reliability and effectiveness. APQP software should provide the means to ensure the use of consistent terms to describe potential failure modes, effects of failure, and causes of failure and control methods across all products and processes. When implemented correctly, this feature enables the process knowledge and documents to serve as the source material for continual improvement and problem solving.

Documentation development for new products that share the same process elements is redundant and time-consuming. If standard processes are used in multiple locations, it is advantageous to create core process components that can be reused for building the documentation. This approach reduces the time needed to create the documentation and eliminates errors because of incongruous data.

The team also may want access to information for similar products and product families. When this information is linked and controlled, the product and process design activities are readily accessible by everyone using the system. The information should be selected based on past history and subject matter expertise.

These basic requirements are not currently met by generic products such as spreadsheet programs or commercial software products that support the creation but not the control of the completed documentation. The software should share common information among product families and manufacturing process operations to minimize the product and process development effort as well as ensure consistency among similar products and processes. Further, the integration of design and process knowledge and documentation is required to ensure consistency throughout the design function and the manufacturing process control efforts. When planning the creation of design and process documentation for a new or existing product, the design and process engineers need to know that the APQP documents are consistent, updated and communicated to all who need this information for design and process changes.

Ultimately, the system should include a project and program management capability so that customer project timelines and deliverables are integrated in the product and process knowledge management. Q

sidebar: TECH tIPS

• APQP software packages were developed as document generation tools and therefore, programs did not include project management capabilities.

• From a functional standpoint, APQP software must provide a quick and simple solution for all APQP documentation and a means of approval and revision control, and access to such information.

• Collaboration and accessibility play a key role in the sustainability and success of an APQP system.