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
To be supportive of the PDSA APQP approach and the process-based quality system
model, APQP software needs to support a long term strategy of using the information
(knowledge) being collected to manage process variation, support knowledge management
activities, and produce the needed documentation to support internal as well as
external customer expectations.
From a functional standpoint, the APQP software must provide the quick and simple
creation of all APQP documentation and a means of approval and revision control
and access of such information to those in need of it with minimal effort. This
must include the ability to (re)format the documentation so that it satisfies the
needs of the user. Since different users (aka customers) have different knowledge
needs, the APQP software must be able to create different formats "on the fly".
But such a system must also link information together so that a change in an attribute
of a product or process is automatically provided to all associated documents (e.g.
see linkage table). Without this dissemination of information (knowledge) throughout
key linkages, the consistency of related product and process documents and actions
will always be questionable. Consider the impact of a change to the measurement
evaluation technique on the Control Plan without the corresponding updating of the
shop floor documentation. This could not only effect product quality for a specific
operation and impede any improvement efforts implemented by the process team, but
it could also 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 that are made to specific design or process information
need to shared and studied by the team. Comments and results of changes to documentation
can build a lessons learned 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 will lack reliability and effectiveness. The APQP software should provide
the means to assure the use of consistent terms to describe potential failure modes,
effects of failure, causes of failure and control methods, etc. across all products
and processes. When implemented correctly, this feature enables the process knowledge
and documents to become the source material for continual improvement and problem
Documentation development for new products that share the same process elements
is typically redundant and time consuming. If standard processes are used in multiple
locations, it is advantageous to create core process components that can be re-used
for building the documentation. This approach will significantly reduce the time
needed to create the documentation and eliminate errors due to incongruous data.
The team may also want access to information (e.g. DVPR results by the design engineer)
for similar products/product families. When this information is linked and controlled,
the product/ process design activities are readily accessible by all professionals
using the system. The information should be selectable 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 be able to "share" common information
among product families and manufacturing process operations to minimize the product/process
development effort as well as assure 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, (DFMEA, DVPR, PF, PFMEA, CP, etc.) will be consistent, up to
date and communicated to all who need this information for all design and process
Ultimately the system should include a project/program management capability so
customer project timelines and deliverables are integrated with the product and
process knowledge management.
Sidebar Are you getting your moneys worth?
How good are your Design and Process Documents?If they satisfy the intent of APQP
then they will contain your key product and process knowledge.
The first question you should ask if a production or field problem occurs is: Did
we know it could have occurred? The answer is either yes or no. And the only way
to determine this objectively is to review the FMEAs and related documents.
If the answer is "yes" then you should ask, "What did we say we were going to do
to prevent or monitor this failure mode"? The answer is in the Control Plan and
process records. Either the controls are insufficient or not being followed.
If the answer is "no", then you need to review the development process to verify
it is sufficient and being followed. If it is okay then you have just gained some
new knowledge (a new failure mode), which should be used to update the product and
process documents. If not, then you (management) need to determine why and improve
APQP software should enable you to answer these questions quickly and efficiently.
Cost of Defects during the production/development process
Source: "A Smart Way to Manufacture," Business Week, April 30, 1990
Page 1 2