driving worldwide business excellence

APQP Software - Not Just for Document Creation

Gregory F. Gruska, President, The Third Generation, Inc. and Donald Cherry, Director Marketing, Omnex Systems

Page 1 2 3 4

APQP Software:

Software packages developed in support of APQP activities were influenced by the intent of the users, not the approach (although there are notable exceptions, such as AQuA).Consequently early APQP software focused on the creation of individual documents to comply with the basic documentation requirements. Since the purpose of APQP software was not the development of process knowledge but only (minimal) process documents, each of the various forms were developed independently of each other even though there were linkages among the various information elements. With this focus, many companies used (and still do use) spreadsheet or word processing programs to generate the forms. While this may be the "fastest" approach for single document development, the effort needed to assure that individual documents are current and groups of documents are consistent is time consuming and error-prone.

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

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, the facts are that individual divisions and units began asking for "their" specific forms, which differed from the standard forms. This multiplicity of forms worsened as organizations began to develop a world market. Database-oriented APQP programs can provide various document formats some even allow the user to develop their own interactively.

With compliance-oriented systems, once the product/process documents are created they are modified only when the customer changes the product requirements or a problem occurs. Consequently the shortcomings of maintaining the collection of process documents with document based APQP software is often overlooked.

As organizations began implementing the process-based quality management system model, continual improvement became more than a slogan. Organizations utilized various approaches to achieve improvement from mistake proofing and process team activities at the "floor" level to Lean/Six Sigma for breakthrough improvement. These initiatives require that cross-functional teams are more than just teams in name only and that the members have ready access to all the necessary information regardless of their location within the organization or geographically.

With organizations achieving mature implementation of ISO 9001/ISO/TS 16949:2009 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 taking the same amount of time as for unique products.
    A company supplying essentially the same design to multiple customers has to create multiple copies of product and process documentation from scratch especially if the customers all wanted different formats. Companies using the copy/paste/change approach to minimize development time find that when the process changes (e.g. for continual improvement) each piece of the individual product documentation must be changed. An error-prone approach.
    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 covered. Again, an error-prone approach.
  • 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. That is, the control of the process is dictated by the equipment, not the products produced. Some companies try using the copy/paste/change approach to minimize development time but most have to develop the documentation from a blank form.
  • Product and process information was not readily available to all team members due to computer access availability.
    With organizations that have facilities around the world, sharing information is difficult. Most of the traditional APQP software requires access to a single physical workstation on which it resides to share information. Even server-based software has difficulty allowing the design group in the United States to share information with the production facilities in a remote state, other North American countries, and/or locations overseas.
  • Documentation maintenance for existing products was redundant and time consuming.
    Because the APQP software did not maintain linkages among a single products documentation and did not share attributes among families of parts, individuals were forced to make required changes in each document of each product individually. This is not only time consuming but also error prone.
  • Documentation errors began coming up due to "shortcuts" taken to minimize redundant effort.
  • Organizations began receiving nonconformances during surveillance audits because their documentation was not consistent and up to date. and
  • Management began asking questions about the documents and the APQP Process and were not getting valid answers.
    As organizations evolved from a compliance orientation towards quality to a process-based quality system model, management began to realize that quality does have a positive affect on the bottom line and that prevention had a higher ROI than the traditional detection/correction approach. With this realization, management began to ask engineers and production personnel some questions whose answers should have been identified during the APQP process:
    • Will the design satisfy all customer requirements and needs? How can we improve the design?
      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. The DVP&R became the validation testing report instead.
    • Will the shipped product satisfy all customer requirements and needs?
      Without dynamic linkages among the various process review document (Process Flow, Process FMEA, Control Plan, etc), information entered in one document was not always included in the others.
    • If a problem occurs: Did we know that the problem could have occurred?
      (See sidebar)
    • Is the APQP process on track?
      Since the 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.

Page 1 2 3 4


Quick Contact