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
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"
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
- 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
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?
- 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