APQP Software - Not Just for Document Creation
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:

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 solving.

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 changes.

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 it.

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 3 4

Top

Quick Contact