Only the online system has the current version. Verify hard copy against online system before use.

CAUSE ANALYSIS AND

PREVENTIVE CORRECTIVE ACTION GUIDE

FOR SUPPLIERS

SQ&TP 0110

Revision Date: 07/18/03

J. Saliture, Director, SQ&TP

Suppliers may view this document via the Internet at https://oasis.northgrum.com.

ii

REVISION RECORD

The latest issue to this guide may be confirmed by viewing the OASIS web site (address is shown on the cover).

REVISION DATE REVISION DATE REVISION DATE

Original Issue 7/18/03

iii

TABLE OF CONTENTS CHAPTER PAGE

Expectations.................................................................................................................................iv

Overview......................................................................................................................................1

Introduction..................................................................................................................................2

Flow Chart ...................................................................................................................................5

Event ............................................................................................................................................6

Collection.....................................................................................................................................7

Analysis........................................................................................................................................13

Solution........................................................................................................................................24

Assessment...................................................................................................................................37

Reference .....................................................................................................................................41

ATTACHMENTS (A) Using 5 WHY Analysis.......................................................................................42

(B) Risk Decision Guide ...............................................................................................43

(C) SCAR Review and Approval Guide .......................................................................51

(D) Supplier Corrective action Request (SCAR) ..........................................................52

iv

EXPECTATIONS OF BUSINESS ASSOCIATES

Continuously evaluate the effectiveness of the corrective action process. Provide a process that effectively handles customer complaints and reports of product or

quality system deficiencies in a timely manner commensurate to the needs of the customer.

When product is affected, take immediate steps to capture, control,and document the status of all work in process, and inventory, including product already delivered or in transit.

Provide customers timely disclosure of nonconforming materiel in transit or delivered post-discovery.

Initiate immediate interim corrective action needed to eliminate the direct cause of an event, and document the actions taken to correct the discrepancy.

Conduct a thorough cause analysis of each event relating to product, process, and quality system that looks beyond the obvious to the degree appropriate, commensurate to the magnitude of the problem with the risk encountered.

Identify and document effective corrective action measures taken to prevent recurrence of contributing and root causes.

Provide the customer a Correction Action Report that documents the investigation and analysis, corrective actions, management approval, and assessment of the effectiveness of the identified corrective action; both immediate and preventive.

Maintain objective evidence that supports the verification of corrective action effectiveness.

Provide sufficient notification and justification to the customer when committed corrective action dates of corrective action cannot be met.

1

OVERVIEW

Cause analysis and preventive corrective action is a process of finding cause and facilitating corrective actions to prevent the potential of recurrence of an event(s) that, if left unchecked, will ultimately lead the customer and suppliers to unrealized costs associated with rework, repair, and replacement at all levels of manufacture.

This process is an integral part of Total Quality and Six Sigma practices. An ISO/AS/EN 9001 quality management system standard requires manufactures to have corrective and preventive action processes that are used throughout the manufacturing facility.

Effective preventative corrective action concepts build on the traditional corrective action process, yielding a more robust process in every aspect of its application to product, process, and quality system. The resulting cost savings benefit both the supplier and customer.

Northrop Grumman Integrated Systems recognizes that an effective Corrective and Preventive Action process will assist in achieving cost reductions in manufacturing, improve the desired level of quality excellence, and promote on time delivery.

This document is based on corrective and preventive action concepts discussed in a cause analysis and mistake proofing document prepared by Allied Signal for the United States Department of Energy. Northrop Grumman Integrated Systems encourages suppliers of manufactured goods and services to aggressively pursue adapting cause analysis, corrective and preventive action, and mistake proofing concepts into all levels and aspects of their business process, product, and quality system.

Suppliers are encouraged to utilize manuals and guidelines posted on the OASIS web site. Assistance and training can be arranged upon request through your assigned process manager.

2

INTRODUCTION

Cause Analysis and Preventive Corrective Action (CA/PCA):

1. Is an effective process for finding the causes of an event, facilitating effective corrective actions, and preventing the recurrence of events

2. Is an excellent tool for streamlining processes, solving problems, and reducing processing time

3. Will increase processing speed as confidence and experience is gained

Goal: Provide an understanding of the concepts of CA/PCA and its application to prevent and/or eliminate errors and defects.

Objectives:

Define the CA/PCA steps for implementation and/or modification to improve existing methods.

Understand the importance of team dynamics and data collection. Illustrate the importance of constructing cause chains and their relevance to the

identification of cause types.

Look at the WHY questioning method and its importance to the analysis of problems. Define corrective action solution types. Discuss the importance of follow-up and effective measurement of corrective action. Define report documentation, data collection, analysis, solution, and assessment.

3

Cause analysis and preventive corrective action can provide you the right path.

Corrective action Process is the feedback system for your business:

SupplierProcesses

In ternal AuditF inding

Prototype andQ ualification

resu lts

Product defectsand SPC

Custom erReturns and

Audits

Businessp lanning and

support

Business Processes

Design

Product Delivery

Custom erSupport

CorrectiveAction Process

All corrective actions should flow through a single corrective action process.

4

Have we learned anything? If the company keeps making the same mistakes, it may be caused by a disconnected feedback system. We must learn from our mistakes; otherwise large amounts of time and effort will be consumed in continuous, repetitive firefighting drills.

Don't messwith it

Does itwork?

Didyou mess

with it?

Willyou be

blamed for itany way ?

You could bein trouble !

OH - OH!

TOO BAD

NO PROBLEM

Canyou transfer

blame to someoneelse ?

Hide it orthrow

away theevidence !

Canit be fixed beforeyour boss finds

out ?

Doesanyone knowyou messed

with it ?

Traditional Problem Solving:

YES

NO

YES

NO

YESNO

YES

YES

NO

NO

YES

NO

5

Its time to break from tradition and put out the fires. Lets get started down the right path. The following diagram illustrates the Cause Analysis and Preventive Corrective Action (CA/PCA) process. The following discussion is broken into 5 parts. They are Event, Collection, Analysis, Solution, and Assessment.

E V E N T

Id e n tify T e a mD o c u m e n t

T e a m

D o c u m e n tC a u s e s

D o c u m e n tC o rre c tiv e

A c tio n

D ire c t C o n tr ib u tin g

Id e n tify P ro b le m

G a th e r D a ta

D e te rm in e C a u s e

R O O T

D e te rm in e C o rre c tiv e A c tio n

P re ve n tiv eS p e c ific

M is ta k e P ro o fin g

Im p le m e n t & F o llo w U p

S o lu tio nA c c e p ta b le

?

Is s u eR e p o rt

D o c u m e n tF o llo w -U p

Y E S

C O L L E C T IO N

A N A L Y S IS

S O L U T IO N

A S S E S S M E N T

N O

6

EVENT

An event is an undetected error from which problems are derived and ultimately drives the need to conduct a corrective action investigation. Cause Analysis and Preventive Corrective Action (CA/PCA) is triggered by such an event.

EVENT All-inclusive term for things like:

Product failure Audit finding Special cause Accident Customer complaint

The solution to the event is the CA/PCA process built around four key elements that are referred to as Collection, Analysis, Solution, and Assessment.

Risk Analysis consideration. Once the CA/PCA process is established and stable, risk assessment should then be considered. When conducted in a scientific manner, risk analysis will help identify the essential few or the most critical problems that need to be pursued through the CA/PCA process, hence, better management of vital resources. Typically, stakeholders would conduct a risk decision analysis and have it approved by single point of contact (SPOC) before starting the collection phase of the CA/PCA process. A Risk Decision Guide is attached at the end of this guide.

PROCEED WITH CAUTION!

It is important that there is a clear understanding of the how-to-do-it concept of CA/PCA as presented in this guide. The concepts, once realized and implemented, must become stable before moving into risk assessment

7

COLLECTION

In order to identify the appropriate cause(s) of a problem associated with an event, you must start with the collection phase. This phase of the CA/PCA process engages fact-finding that is made up of three elements: team identification, problem identification, and data gathering. Documentation of the activity carried out in each of the elements is necessary to support completion of the final report.

Identify Team

Identify Problem

Gather and Verify Data

DocumentTeam

IDENTIFY THE TEAM

A team provides the critical control and feedback that the process must have to achieve optimum results. The team dynamic assures that the outcome of the corrective action will be successful in implementing preventive measures. Management empowers the team members with the responsibility and authority over their process.

There are two groups that make up the teams membership during the data collection phase: the natural work team and the qualified team.

The natural work team members, or stakeholders, must have a vested ownership in resolving situations:

They know their process(es). They have the data and experience. They have to live with the corrective actions. They will make it work if given the chance. They depend on the process.

The qualified team members are consulted, as required by the natural team members, to provide technical support. They include:

Those who can provide additional information Those who have particular technical expertise Those who may be needed to act as advisors Those providing management support. 8

9

The natural team will identify and integrate other team members as the investigation unfolds. Once a natural team begins the data gathering process, they will identify the need to bring in other people as natural or qualified team members. Qualified team members are ad hoc members in that they act as advisors to the natural team members on an as-needed basis. The natural team must know when to bring in a qualified team and identify the resources available for use on the qualified team.

A core team of three to five people works the best; a team that becomes too large may become uncontrollable. Bring qualified members in as you need them, drop them off when they are no longer required, and maintain a running roster of the member participation.

NNoo TTeeaamm?? NNoo PPrroocceessss!! QQuueessttiioonnaabbllee RReessuullttss!!

Assigning CA investigations to someone with no vested interests or expertise to conduct an investigation on their own, or forming a team that doesnt have ownership of the problem, will yield unsatisfactory results. Its important to understand that the natural team provides the critical control and feedback the process must have to succeed but only if they have the responsibility and authority over their process.

A team should never be less than two people; even on simple problems, the synergy that comes from two people sharing ideas adds greatly to the process.

Team members from different backgrounds and responsibilities bring different ideas and experiences to the table; the team process capitalizes on these factors. ESTABLISH A SINGLE POINT OF CONTACT (SPOC)

The SPOC acts as the focal point for management of corrective action system, initiating the corrective action investigation when a SCAR (Supplier Request for Corrective action) is received. The SPOC is responsible for final signoff of all reports and follow-up of CA completion status to the customer. The SPOC is generally an individual trained in and responsible for the management of the corrective action process and has knowledge of the business operations and key personnel.

The SPOC will identify and document the initial teaming structure within the business operation and activate the appropriate team to respond to each SCAR. The SPOC is responsible for ensuring that all team members have been trained in the CA/PCA process before becoming part of a working team. Once teams have been identified, they will most likely work together on other similar investigations.

IDENTIFY THE PROBLEM

The team members must understand and be able to clearly state the problem(s) in simple terms in the form of a WHY question. Many events have more than one problem; identify and work them separately. Ask the following to help formulate the WHY:

What is the problem to be resolved?

Know your Problems! You must understand the problem. Is there more than one problem?

Keep it simple.

What is the customers concern?

When writing an event or WHY question, remember the following rules:

An Event Question Is: An Event Question Does Not:

Short Simple Concise Focused on one problem Is a question starting with why?

Tell what caused the event State what to do next Explain the event

Example: The Event: I didnt get to work on time. Event-Related Question: Why was I late? (simple question)

IIff yyoouu ccaannnnoott ssttaattee iitt ssiimmppllyy,, yyoouu ddoo nnoott uunnddeerrssttaanndd tthhee pprroobblleemm.. 10

GATHER AND VERIFY DATA

DATA GATHERING The goal is to gather and document all the factual information necessary to ensure a thorough

Cause Analysis and data, which may be needed to complete any required reports. Normally, the team may have to collect data several times during the analysis phase. The team will determine when more data is need before they can factual answer the WHY questions and move on in the analysis phase.

Initial data gathering starts at the scene. Data has a shelf life; the longer you wait, the more difficult it becomes to obtain good information. When possible, go to the scene and take note of who was present, what is in place, when the event occurred, and where the event happened. If the event is in the form of an audit finding, try to recover as much of the scene as possible.

Data Collection Tips

Location the site, building, facility, or field location where the event took place. Names of Personnel operations personnel, visitors, contractors Date and Time Specifications what are the requirements? Operational Conditions startup, shutdown, normal operations Environmental Conditions noise levels, visual distractions, lighting, temperature,

humidity, weather, etc.

Communications verbal or written, what orders were being followed? Sequence of Events in what order did things take place? Equipment what was being operated? Physical Evidence damaged equipment or parts, medical reports Recent Changes in personnel, equipment or procedures Training classroom, on-the-job training, none Other Events have there been other similar occurrences?

The team must make sure that gathered data is correct and complete. Let the data tell the story.

DDoonntt jjuummpp ttoo aa ssoolluuttiioonn ccoonncclluussiioonn.. 11

12

DATA VERIFICATION It is vital that the team validates and verifies the data as it is being collected. Incorrect information

will impact decisions the team will make in respect to the corrective action chosen to implement; this will manifest in the recurrence of a contributing cause. Look for the following:

Accuracy:

Was information copied from a document or from memory? Were interviews done immediately after the event, or was there a lapse in time?

Second Source: Whenever possible, get confirmation from another source.

Conflicting Information: Note data that disagrees with other data. This can include data from interviews/statements or documents/procedures. This could also include conflicting interpretations.

Dont Be Afraid to Back Up: Your data may often show you that multiple problems exist. The data may also require you to rewrite your event question.

Tools to Help in Organizing Data:

Create a process map. List the steps in the process and all of the associated variables. Create a time line. Lay out each piece of data in its sequential order.

13

ANALYSIS

In the analysis phase, the collected data is evaluated to establish cause type. Team documentation of this analysis is as important as collecting the data itself.

Determine Causes

Direct Contributing Root

DocumentCauses

DETERMINE CAUSE

DETERMINE CAUSE

WWhhyy DDiidd IItt HHaappppeenn??

The cause analysis process requires complete honesty and no predetermined assumptions!

Eliminating preconceived notions is critical. They cause the team to sidetrack the process. They may lead the team to ignore data that points to the real problems.

Act on fact! Follow the data, dont try to lead it.

This process is a tool to be used to obtain a permanent fix; you will not achieve it if you try to force the analysis into supporting a preconceived corrective action.

Remember: Dont get personal; what we really want to know is:

NNOOTT wwhhoo ddiidd iitt,, BBUUTT WWhhyy ddiidd iitt hhaappppeenn?? 14

15

THE WHY-WHY METHOD Even the most serious or complex problems can be solved by using the WHY-WHY method,

coupled with cause chain diagrams.

Why? Because the process is:

Fast Informal Natural to use Universal Effective.

Everyone, everyday, uses the WHY analysis method. Its a natural, logical progression for thinking through a problem. The WHY approach provides a systematic process in determining all of the contributors to a problem before implementing a corrective action plan. The WHY questioning process is the center of the entire analysis phase. With each application, the user will gain proficiency with where the questioning needs to go. This guide will establish some WHY basics. A presentation of the 5 WHY analysis process has been added as an attachment to this guide to provide the reader with a more in-depth discussion of the execution and application of this powerful tool.

CAUSE CHAINS Cause chains are the product of the WHY questioning. Using a cause chain as a diagram allows

you to handle large or complex problems that are impossible for the human brain to see as a whole. They also keep you honest!

Working from an effect back to a cause, restate the cause as a problem (Why?) and find the next cause. Repeat until you run into success.

Keeping it simple is the secret to the process. Asking complex or poorly focused questions will lead you off the correct path that will ultimately result in wasted time.

TTaakkee ssmmaallll sstteeppss!! IIttss vveerryy eeaassyy ttoo jjuummpp aahheeaadd aanndd lleeaavvee oouutt ccaauusseess..

Simple Questions Simple Answers

16

From the example below, you can begin to see how a chain of answers is derived from the WHY questioning (simple question). The simple answers identify a cause, i.e., the cause chain. Each cause (simple answer) leads to the last cause in a chain that is referred to as a root cause. As you will see, cause chain can lead to multiple root causes.

The Big Secret!

Example of WHY-WHY Method of Questioning Event: I didnt get to work on time. Event-Related Question:

Why was I late? (simple question) - Car wouldnt start (simple answer)

Why didnt the car start? (simple question) - The Battery was dead. (simple answer)

Why was the battery dead? (simple question) - Dome light was on all night. (simple answer)

Why was the light on? (simple question) - The car door was left open. (simple answer)

Why was the door open? (simple question) - Kids played in car. (simple answer)

Why were kids in car? (simple question) - Car not locked. (simple answer)

Why was car unlocked? (simple question) - Remote access failed to activate lock.

(simple answer)

17

WWhhaatt iiff yyoouu ggeett ttwwoo aannsswweerrss??

Cause chains like to branch a lot. Often this happens and you dont realize it right away. Study each answer and if it contains two or more separate pieces of data you have identified a branch. Continue the Why-Why questioning for both the original and new branch.

The car was unlocked, so the kids played in the car. (not a simple answer)

Two pieces of data were given in the answer above: Car unlocked and kids played in car.

Each becomes a branch that must be questioned.

Why was the door open? (simple question)

Why was car not locked? (simple question)

Kids played in car (simple Car unlocked (simple answer)

Why was the door open? (simple question)

Why were kids playing in car? (simple question)

WWhhaatt iiff yyoouu ggeett ttwwoo qquueessttiioonnss??

Youre going to quickly find out that asking the right question isnt always easy. Sometimes there are two ways of looking at data, which leads you to form two different questions. Be sure youre focused on that one cause and youre not jumping ahead. If your WHY questions directly lead from the cause, then ask them. As in the example above, make another branch in the cause chain.

SSoolluuttiioonnss ccoommee llaatteerr!!

Stopping to consider solutions for each cause will mislead and slow the process. Not all causes have solutions, nor do they necessarily need them. Build the cause chain first, then work on the solutions!

18

Test the Chain Prove the chain is correct by working it backwards. Began with the last answer and ask, Does it

follow that the last answer leads to the previous answer?

The Car Door Was Left Open Did this cause?

Dome light was on all night.

Did this cause?

Battery was dead.

Did this cause?

Car wouldnt start

Did this cause?

Event: I didnt get to work on time.

In our example, did the kids leaving the car door open lead to not getting to work in time? Yes, it did. Therefore, that step in the chain held up.

Cause Labels WHY questioning, as seen in the example used, has produced what appears to be a satisfactory

chain. Cause labels need to be applied to the answers in the chain. Cause labels are categorized as direct, contributing, and root. The following defines each of the cause categories and labels.

The first label in the chain direct cause: The cause that directly resulted in an event identified the direct cause (The first cause in

the chain).

Event

Car didnt start Direct Cause

The battery was dead

The direct cause is the answer to the first question (your problem statement). Jump-starting the car will get you to work, but as it relates to this problem, it wont keep you from being late in the future.

The next label is contributing cause: This is the cause(s) that contributed to an event, but by

itself would not have caused the event (the causes after the direct cause).

Contributing Cause(s)

- Dome light was on all night - The car door was left open - Kids played in car

Event Car didnt start

Direct Cause The battery was dead

Note: For a simple problem, there may be no contributing cause; for a complex problem, there could be numerous contributing causes.

The last label is root cause: It is the fundamental reason leading to an event, which, if corrected, may prevent recurrence. Root cause doesnt hold any more or less weight than contributing cause; its merely the last cause in the chain.

The root cause is really that point in a cause chain that is identified as the best place to stop. It will become apparent to the team at some point that continuing the WHY questioning will not bring any added value to the corrective action process in terms of cost savings. The root cause is not always the most significant cause in the chain, and sometimes it cant be corrected easily or well. Focus on the fact that it is just the last cause in the chain.

If we look back at the example of WHY questioning (page 20), the last item (remote failed to activate lock) would be the root cause. Fixing the remote will not prevent recurrence 100 percent. The remote operator or the remote may fail again so addressing one of the other contributing causes may go further toward prevention like not allowing the kids to play in unlocked cars

Cherry picking the data to look for a root cause will lead to failure. Never try to build a cause chain from the root cause backwards to justify your choice; youll end up trying to justify assumptions or to serve an agenda. What you wont do is fix the problem! 19

20

HHooww mmaannyy rroooott ccaauusseess ccaann tthheerree bbee??

As seen in the examples below, when a chain branches or an event drives more than one problem, multiple root causes will result.

Example One When an event question drives an answer that identifies two or more problem statements, each problem drives its own chain to a root cause.

Event

ProblemOne

DirectCause

RootCause

ContributingCause

ProblemTwo

DirectCause

RootCause

Example Two When a WHY question drives more than one answer, multiple contributing causes can result.

ContributingCause

ContributingCause

RootCause

Event

ProblemOne

DirectCause

RootCause

ContributingCause

RootCause

Where a cause chain branches into multiple contributing causes, each contributing cause points to a problem that needs its own solution. Therefore, each branch of a chain must be worked down to a root cause. Each branch needs to be analyzed to determine the significance of contribution to the problem statement. In some cases, problems will be identified that dont directly impact the problem under analysis but may be seen as an action that needs to be corrected and thereby worked separately. The Risk Decision Guide (discussed on page 10) concept could be utilized to help evaluate contributing causes to determine the extent to which to carry out a cause chain and corrective actions.

There may be instances where there is no root cause; this happens if the event chain trail becomes lost or there is no more data. Records may be missing, required personnel are no longer present, or the problem could be very old in nature. In these causes, you may have to call the last known contributing cause as the root cause.

21

Review of Key Points in Process

Start with the event question. (identify the problem) Use the WHY-WHY process. (gather data) Take small steps dont skip causes. (do the analysis build the chain) Write down each cause and the WHY. (simple question and answer) No corrective actions allowed! (determine cause) Test cause chain by working backwards. (validate)

The following is a simple example of cause application:

Direct cause = (D), the contributing cause = (C) and the root cause = (R).

Event: I didnt get to work on time. Event-Related Question: Why was I late? (Simple Question) Car wouldnt start. (Simple answer)

D The battery was dead. (simple answer)

C Dome light was on all night. (simple answer)

C The car door was left open (simple answer)

C Kids played in car. (simple answer)

C Car not locked. (simple answer)

R Remote access failed to activate lock. (simple answer)

Important Note: Some causes may not be directly related to the event but are still contributing to the cause and may point out that there are additional problems to be analyzed (like kids played in car). Some problems may not have any contributing causes between the direct and root cause.

22

Y-Y Curve Normal progression of any analysis is to move from a point of not knowing enough about when

the event occurred (first target) to a point where the problem becomes well understood and workable (bottom of the curve). Past that point, the problem picks up the silliness factor and quickly becomes unworkable. Knowing where to stop takes practice, experience, and some assistance in defining the limits of the root cause.

Ignorance Silly

Unworkable

Workable

Kids played in car The battery was dead

Car wouldnt start

Remote failed to activate lock

The car door was left open Car not locked

Dome light was on all night

SSoo wwhheenn ddooeess tthhee cchhaaiinn eenndd??

Guideline rules for ending the chain:

4. Is the last cause within control of the team?

5. Does the team have ownership?

Utilizing the answers from the example WHY questioning from page 20, we can demonstrate the guideline rules in the illustration above.

You must identify the root cause, even though you may not have the resources in your team to solve it. Do not use these tests as an excuse to take an easy way out and not follow the process to the root cause. Just because you feel a problem is beyond your personal ownership or that of the natural team does not mean its beyond the ownership of someone or another team in the company. Actions involving resources issues or issues outside of the team ownership must be elevated to management. There are rare occasions when the root cause has been properly identified but has no solution. Its still the root cause and needs to be documented.

TThhee ccaauussee cchhaaiinn iiss yyoouurr bbrriiddggee bbeettwweeeenn tthhee eevveenntt aanndd tthhee ssoolluuttiioonn.. TTrruusstt iitt!!

23

Building the bridge between an event and a solution requires finding the correct causes. You may not be totally comfortable with the cause chains you have created; dont worry, the strength of the process is that, as long as you have identified all the major causes, you are on your way to obtaining valuable solutions.

24

SOLUTION

The solution phase is the culmination of all of the effort expended in the collection and analysis of the collected data. It is at this point where corrective action of the identified problem takes place. Dont be distracted with preconceived ideas or emotion-driven solutions like operator error. Let the process point you in the right direction.

DocumentCorrective

ActionDetermine Corrective Action

Specific Preventive

Mistake Proofing

DETERMINE CORRECTIVE ACTION

Corrective action solutions are defined as a set of planned activities (or actions) implemented for the sole purpose of permanently resolving the problem. There are two types of corrective action, specific (also known as immediate) and preventive (also known as sustaining). The following discussion will expand on this concept of corrective actions taken during the CA/PCA process.

Specific or Immediate Corrective Action: Action taken to correct the direct cause and change the effect.

Preventive or Sustaining Corrective Action: Actions taken to prevent recurrence of the event that focuses on

the contributing causes and the root cause.

These two categories (specific and preventive) are quite different in how they are applied and how these actions affect the corrective action process. Not understanding the importance of these elements could lead to serious mistakes in fixing problems. Typically most corrective action stops with the immediate corrective action and never gets to the more important preventive and mistake proofing action steps. In other words we put out the fire but we never seem to get around to making sure that the fire never starts again.

Lets take a look at the corrective actions and how they work.

SPECIFIC CORRECTIVE ACTIONS Are actions taken to correct the effect and/or direct cause of an event. It can also be referred to as

specific corrective action. The action is immediate but does not prevent the event from recurring.

Specific action taken to change effect Specific action taken to change direct cause.

Event = Late to work Direct cause = Specific action =

Effect = Car wont start Dead battery Jump battery

IImmmmeeddiiaattee ccoorrrreeccttiivvee aaccttiioonn ddooeess nnoott pprreevveenntt rreeccuurrrreennccee!! 25

26

Immediate Corrective Action Immediate corrective actions are only used to correct the direct cause and change the effect;

theyre really a form of damage control and cleanup. The purpose is to limit or stop the effects from getting any worse and repairing whatever was affected. Often, immediate corrective action occurs at the scene in response to the event. When this happens, there may be nothing for the natural team to do except document what was done.

Stopping a process until corrective actions can be applied is also a form of immediate corrective action; it temporarily stops the direct cause from operating but does not provide an acceptable long-term solution.

The following is a simple example to illustrate immediate corrective action:

Event: Pilot holes were mislocated in parts.

Direct Cause: Drill fixture not to current configuration Effect: Misallocated pilot holes in parts. Immediate Corrective Action: Reject and rework tool. (direct cause)

Remake parts. (Effect).

The example shows two actions requiring immediate corrective action. One limits the direct cause (reject and rework tool). The other fixes the effect (remake parts). The first action to the direct cause does not prevent tooling configuration change process from allowing recurrence of the event.

It must be understood that correcting direct cause is only temporary. For example, in a manufacturing process it can range from shutting down the process, changing the instructions, putting a tool in bond, etc. Changing the effect can range from repairing damage tooling, fixing defective parts, recalling material, etc., and is only temporary. These actions dont prevent the event from recurring any time in the future.

Look for all of the effects. Often the problem has been occurring for a period of time before it is ultimately discovered. The team needs to look at the history to find out if other like things, like previously produced parts, are also part of the effect. Fixing or recalling delivered product is all immediate corrective action.

27

PREVENTIVE CORRECTIVE ACTIONS These are actions taken to prevent recurrence of the event by focusing on the contributing and

root causes. it is also referred to as sustaining corrective action.

Contributing Cause Preventive

Corrective Actions

Root Cause

Preventive actions are focused on breaking the cause chain. A 100 percent fix at the root cause, more often than not, will not prove to be effective if there are two or more not addressed contributing causes in the chain, leaving it unbroken.

Determining the number of corrective actions to be taken and how effective they will be in breaking the cause chain requires careful analysis by the team.

Contributing causes not directly leading to the root cause should be evaluated for corrections as they may apply to other possible problems. A contributing cause missed or overlooked in the analysis will also result in an unbroken chain and recurrence of the event.

Interim (temporary) corrective action of a contributing cause may also be implemented. This is a special type of action that is effected to prevent an event from reoccurring until such time as preventive corrective actions have been put into place. Interim corrective actions are used when it is important to get a process back on line on a temporary basis. It can take the form of barriers that block off an area or imposing corrective actions that would not be cost effective in the long run. If interim corrective action is used, it must be reported with a deadline for final sustaining corrective actions to be put into place. Remember, this is an exception to the normal corrective action process and is not considered a standard step in the process.

28

PPrreevveennttiinngg rreeccuurrrreennccee mmeeaannss pprreevveennttiinngg rreeccuurrrreennccee eevveerryywwhheerree!!

How does a team handle contributing cause issues out of their area of control in order to break the cause chain?

Expand the team, create a second team, or pass it up to management. The team can handle most global issues merely by bringing in one or two more members that

have the authority to implement the corrective actions over a border scope of the business operation.

Do whatever it takes; just dont ignore the problem. Doing the right thing means making prudent calls based upon facts.

29

Assessing Severity and Frequency of the Problem Not all problems warrant the same level of attention. A typographical error that caused no harm

will not receive as much effort to correct as would a manufacturing error that causes thousands of dollars in defective product. The team must look at the severity and frequency of the problem.

To assist in guiding this effort, ask the following three questions:

What is the cost of the event in terms of: Personnel and environmental safety Lost money Lost time Product loss Customer dissatisfaction?

Schedule impact how likely is the event to recur if not fixed? Can you accept the consequences of a recurrence?

If there are any doubts about the evaluation process outcome, or if the team needs assistance in getting the corrective action approved, bring in a management representative as a qualified team member.

Corrective Action Test 1. Do the corrective actions lower the risk of the

event recurrence to an acceptable level? 2. Are there adverse effects caused by implementing

the corrective actions that would make themundesirable?

3. Do the interim corrective actions adequately lower therisk of the event recurrence to an acceptable level untilpreventive corrective actions can be implemented?

MISTAKE PROOFING

Mistake proofing is a way of thinking about corrective actions that gives you a much better chance of developing fixes that are 100 percent effective. This is where most of your preventive corrective action that prevents root cause from happening or recurring is identified.

Mistake proofing:

A process that provides a structure for designing failure mode out of a product or process?

Mistake proofing devices and techniques are highly effective in breaking cause chains. They tend to be simple, inexpensive devices that prevent errors from occurring or detect errors that have occurred early enough to avoid serious risk. The point of mistake proofing is to keep errors from becoming events that impact cost and/or safety.

To understand mistake proofing, you must understand the difference between errors and events!

Detected error occurrence becomes a cause. Undetected error occurrence becomes an event. 30

31

Murphys Law suggests that defects are never found until after the final inspection. Mistake proofing eliminates that law in that defects can be found before final inspection.

YYoouu hhaavvee ttwwoo ooppttiioonnss::

Option 1: Demand vigilance. There is no mistake, there has been no mistake, and there shall be no mistake.

Option 2: Face reality and admit that Murphy was right. Inspection isnt 100 percent effective. Use that knowledge to look at your processes in a new light to eliminate the error before it becomes an event by mistake proofing. Change the way you look at operator errors. Remember Dr. Demmings study on operator error? He showed that 94 percent of errors are process related and only 6% are people related.

People make mistakes; rarely do they do it on purpose. A process that requires a person to constantly make choices and decisions without much

guidance is primed for error.

32

The human brains default mode of operation is pattern recognition and autopilot execution. If the pattern is familiar, a behavior that has been successful in the past will be launched. Its only when feedback suggests that things are not progressing as planned that a more in-depth thought is brought forth. As operators, we are on autopilot everyday until something happens to break us out of our routine long enough for us to discover things arent functioning properly. A good process alerts the operator when something is not being performed correctly. An operator will keep on making mistakes until something tells them to stop. Thats where mistake proofing comes into play.

KKeeeepp iinn mmiinndd tthhaatt aa rroobbuusstt pprroocceessss wwiillll ttaakkee iinnttoo aaccccoouunntt vvaarryyiinngg ddeeggrreeeess ooff ooppeerraattoorr eexxppeerriieennccee aanndd bbee ddeessiiggnneedd aaccccoorrddiinnggllyy..

Use mistake proofing because:

Errors are more difficult to commit. Its possible to reverse errors to undo them. Its easier to discover errors that have occurred. The process is more forgiving of errors.

So, how is mistake proofing done? Take a look at some everyday examples of mistake proofing that is already in use in our daily lives:

The sneak a cup feature on coffee makers Beepers on automated teller machines (ATMs) so you wont forget your card Being unable to shift the transmission lever from park unless the brake pedal is depressed Car lights that turn on and off automatically Lockout fields and tab controls on electronic forms Car wash that wont start unless car is positioned on the sensor pad 7-day pill dispensers Kill switch on lawn mowers and treadmills One-way-only part fixture setups (Poka-Yoke).

33

The three levels of mistake proofing are: 1. Source Detection A process where features and conditions are verified by

devices and techniques built directly into the work process. The process detects the error, making it impossible to do the task incorrectly. Errors found at this stage have not been passed on and therefore are not defects.

2. Self-Detection The process is structured so that errors are easily detected during the operation. Operators can discover their own errors before passing them on to become defects.

3. Successive Detection Occurring downstream from the error, later processes are designed to be effective at discovering effects. Although this process protects the customer, this level is not as effective or efficient as source detection.

MISTAKE PROOFING THE CAUSE CHAIN Error points are causes where someone failed to do something correctly a point at which a

mistake was made. As youve noticed in cause chains, there are always a few causes where you have to ask if possible operator error caused the mistake and could have been discovered. These are the causes you want to look initially to see if a mistake-proofing device can be used to prevent the event.

The distance between the error and the defect discovery is important to the process. It can have implications regarding costs, missed schedule, or lost man-hours. It will also give clues as to where corrective actions need to be applied to be the most effective.

Not all error points may have applicability for a mistake-proofing device, but the team should continue to look at the rest of the cause chain. MISTAKE PROOFING AND STATISTICAL PROCESS CONTROL (SPC)

Statistical process control relies on process mapping to capture and account for all the common causes that produce process variations. Common causes are routine to the process such things as tool wear, temperature variations, material lots, etc. The common causes are dealt with in a good process design. SPC is then used to provide a measurement of process capability and warns of variations.

Statistical process control is a form of defect detection. It happens after an error has become a defect. The purpose of SPC is to detect special cause variations causes outside the process that

34

results in the process being out of control. Once their existence has been identified, SPC is unable to identify how to prevent the special cause from recurring.

Cause analysis can be done to analyze the event and build a cause chain that leads back to the special cause. The special causes are then eliminated by mistake proofing and are prevented from recurring. MISTAKE PROOFING AND FAILURE MODE AND EFFECTS ANALYSIS (FMEA)

Failure mode and effects analysis is performed to identify the potential failure modes in each step of the process and the effects those failures would have on the product. It then ranks the order of design and process deficiencies based on risk so you can focus on prevention of the highest-risk problems. FMEA is a perfect match for mistake proofing.

FMEA Table

FAILURE MODE EFFECT CAUSE CONTROLS

#1

#2

#3

#4

Expand the causes usingthe 5 WHY process.

One WHY isnt enoughto uncover the causes forhigh-risk effects.

Control the high-riskmodules with MP devices.

35

TThhiinnggss ttoo wwaattcchh oouutt ffoorr iinn tthhee pprroocceessss;; ccoommmmoonn eerrrroorr--ccaauussiinngg ppooiinnttss

There are many types of operations or conditions that go against the human autopilot mode or generally make conditions more stressful and therefore more prone for generation of errors. Think hard about designing them out or using mistake proofing devices to protect the integrity of the process.

Points to consider during the mistake proofing design process: Adjustments Fixtures, tools, or designs that require the operator to tweak parts into alignment

Tooling Undetected tool wear, tool changes required between part runs Points to consider (continued)

Lots of parts Many parts in an assembly process with similar sizes, shapes, or colors. Lots of steps Assembly that requires many small operations where sequence of steps is

critical

No processing standard Where additional procedures, instructions, or training will be needed to support the operation

Symmetry Where the symmetrical design of a part or mirror image layout makes it hard to identify specific features or orientation

Asymmetry Where a part that is not symmetrical can be reversed and still fit Speed and repetition Repeating the same operation continuously, requiring the

operation to be done quickly, or both

High volume Physical volume of product coming out of the process makes processing errors more likely and detection of the errors more difficult

Environment Local conditions that can affect the process lighting, cleanliness, traffic, temperature, etc.

MMiissttaakkee pprrooooffiinngg TThhee eeaarrlliieerr iittss aapppplliieedd,, tthhee bbeetttteerr..

Each stage of bringing a product to production needs to be accomplished with an awareness that mistake-proofing devices should be implemented whenever possible. Product design allows you to change design features to make it easier to build and make the processing less difficult. Process design and development should focus on the operators interaction with the process and how to reduce error points. Product/process validation is one last review in which trouble spots can be spotted during pre-production build. Production may turn up more problems, identifying the cause chain to implement effective mistake-proofing devices and allow for permanent corrections.

36

TThhee ccoosstt ooff NNOOTT mmiissttaakkee pprrooooffiinngg

Mistake proofing is a very effective way to prevent errors from becoming defects. It works early in the process and, as a result, costs less than other detection processes. Cost of nonconformance increases in other defect detection processes the farther away the defect is noted from the point of error. By the time a defect reaches final inspection or the customer, the cost is much greater.

Example: One prime contractor reported that half of their mistake-proofing devices cost less than $100. However, the estimated net saving through their application was $8.4 million, or about $2,545 per device.

37

ASSESSMENT

In the assessment phase, proposed solutions are implemented. Responsible personnel are charged with the oversight and verification follow up activity that determines the acceptability of the implemented solutions. The Solutions and results are documented and issued as a report to the customer.

Implement andFollow Up

DocumentFollow-Up

SolutionAcceptable

?

IssueRepot

LoopBack NO YES

IMPLEMENT AND FOLLOW UP

Proposed solutions do not become preventive corrective actions until they are implemented. To implement, you have to know:

WWhhaatt,, WWhhoo,, aanndd WWhheenn What is the corrective action?

Who is responsible for getting it done? When is it going to be done?

Every corrective action listed should have the what, who, and when phase completed prior to

closing the action.

DDoonntt mmaakkee tthhee bbiigg mmiissttaakkee!!

Never assign a corrective action to someone who isnt on the team. Trying to do so means that you missed one of your natural team members. Add the individual to the team, revisit the cause chain and any proposed corrective actions prior to continuing with the implementation.

DDoo wwhhaatt yyoouu ssaayy!!

Corrective actions must be accomplished as stated.

Its important to take things literally. Did you accomplish everything as you stated in the report? Were the tasks accomplished per the established timeline?

Dont commit to actions that the team cannot deliver.

Be careful in use of terms such as everyone or all; use of such terms implies your certainty to deliver

Remember:

Say what you do. Do what you say/ Be able to prove it.

Dont hang yourself with your report! Write your corrective actions clearly. 38

39

Start with who will follow up on corrective actions. The team isnt done until someone has been chosen to look after the corrective actions. It doesnt have to be just one team member; a problem with several corrective actions affecting different areas will involve different people. Whoever is selected must buy into the process and the corrective actions.

Responsible team member needs to answer the following questions:

Were the corrective actions done as stated? Were they done on time? Have they been effective?

The answer to the effective question may not be obvious. The team should think about how the effectiveness of the corrective actions could be tested or measured. What proof can be shown that the problem has truly been prevented? How are you going to answer the customers concerns?

Did the corrective actions work? If no:

Go back to the process. Re-evaluate the cause chain. Obtain the proper results. Do it again.

If yes:

YYoouuvvee cclloosseedd tthhee lloooopp!!!!

What if questions reinforce the effectiveness of the corrective action:

The corrective action that was implemented is not what was proposed Find out why not.

The proposed corrective action is not functioning. Find out why and redo the cause analysis process.

Better or alternative corrective actions were applied. They need to be reported.

The corrective actions were in response to an audit finding. Not reporting the changes could set the stage for another finding.

The problem was serious, or you dont have complete control over implementing your corrective action

Perform periodic checks to ensure that the corrective actions are still in place and functioning. If possible, add this review phase to an already existing validation process instead of creating a new review process.

ISSUE REPORT

Now that youve been through the entire data collection, analysis, solution, and assessment elements of the CA/PCA process, its time to bring the whole thing together as a final report for final approval. The team is not the only group that will review the documented effort; affected management, organizations, and the customer may all review the teams results.

You may have done an excellent job of analysis and correction, but if the information is not clearly written, no one will understand the results. Net effect: youve wasted your time.

BASICS OF A CORRECTIVE ACTION REPORT Team Members: List the names of the natural and qualified team members. Event Description: Describe the event that led to corrective action activities. If it was a survey/audit finding, repeat the finding. Event Question: This is a WHY question that the team used to define the problem being analyzed and to start the cause chain.

Direct, Contributing, and Root Cause: Text blocks for the cause chain. Make sure to attach the completed cause chain to the report.

Specific Corrective Action: Enter the action(s) taken to correct the direct cause and/or the effect. This should include dates of completion and the names of owners.

Sustaining Corrective Action: Enter the actions taken against the root and contributing causes to prevent the recurrence of the event, dates of completion, and names of the owners. List mistake- proofing devices and types implemented. Team Signoff: Team members signify that the corrective action report is complete and ready for presentation to management/customer.

SPOC Approval: Before the report is circulated to management and the customer, the SPOC reviews the report to verify that the team has a product (reference attachment C). The team and the SPOC should use attachments C and D to ensure that all customer requirements

are met in the report. 40

41

REFERENCES

Max Ammerman, Root Cause Analysis Handbook, New York Resources, 1998, ISBN 0-527-76326-8.

Beauregard, M. R., Mikulak, R.J., and McDermott, R.E., The Basics of Mistake-Proofing, New York Quality Resources, 1997.

Norman, D. A., The Design of Everyday Things, New York Doubleday, 1989. Shingo, Shigeo, Zero Quality Control: Sources of Inspection and the Poka-yoke System, Productivity Press, trans. A.P. Dillion, Portland, Oregon, 1986.

Kepner-Tregoe, Kepner-Tregors Problem Solving and Decision Making, United States Department of Energy, trans., PRI, Warrendale, PA. 1982, DE-ACO4-76-DP00613.

42

ATTACHMENT A USING WHYANALYSIS

Double click the button below to view a 23-page tutorial.

43

ATTACHMENT B RISK DECISION GUIDE

This decision guide will help a team evaluate the extent to which a problem should be pursued through the cause analysis and preventative corrective action process (CA/PCA). It will also help a team to decide the extent to which to carry corrective actions and the amount of resources to be applied to the corrective actions. The guide helps focus a business team on the implications and risk identified from the business model. It provides a scientific way of determining the essential few or most critical problems to be addressed by the CA/PCA process.

The risk factor or R calculation will identify the level of action and justification that should be considered by a team. The R calculation is based on three elements: severity (S), frequency (F), and detectability (D). The following provides a discussion of each of these elements and calculating the risk factor.

SEVERITY RANKING (S) Using Table 1 below, start by estimating how severe the effect of the problem or variation will be

for the next user or customer. This is the factor that represents the seriousness of variation in the eyes of the next user or customer.

Table 1. Severity Ranking and Criteria

Rank Severity Criteria 1 Unreasonable to expect that the minor nature of the failure would cause any noticeable

effect on the next operation. Customer will probably not be able to detect variation. 2 Variation causes only a slight customer annoyance. Customer will probably notice only

minor problems. 3 Customer is made uncomfortable or is annoyed by the problem. For example,

moderate rank would be given to undesirable attributes, such as the need for customer to make revisions or corrections.

4 High degree of customer dissatisfaction due to the nature of the problem, such as an unusable product or service.

5 Problem involves potential safety considerations or loss of customer.

44

FREQUENCY RANKING (F) Next, using Table 2 below, estimate the likelihood that the problem or variation will occur.

Regardless of the risk factor calculated below, this frequency ranking is the best indicator of the preventive capability (robustness) of the process. Corrective actions should be considered to reduce high-frequency rankings even when the risk factor is otherwise within acceptable limits.

Table 2. Frequency Ranking and Criteria

Rank Frequency Criteria

1 Remote probability of occurrence. 2 Low probability of occurrence (process in statistical control). 3 Moderate probability of occurrence. Associated with processes that have experienced

occasional failures, but not in major proportions (process in statistical control but not quite capable).

4 High probability of occurrence. Generally associated with processes that have often failed (process in statistical control but not capable).

5 Very high probability of occurrence, i.e., defect is almost certain to occur.

DETECTABILITY RANKING (D) Finally, using Table 3 below, estimate the probability of passing a problem or variation on to the

next user or customer.

Table 3. Detectability Ranking and Criteria

RANK DETECTABILITY CRITERIA 1 Remote likelihood that the product would be passed on or shipped containing that defect. The

defect is a functionally obvious characteristic that can readily be detected by a subsequent operation. Detection reliability: at least 99.99%.

2 Low likelihood that the product would be passed on or shipped containing the defect. The defect is an obvious characteristic. Detection reliability: at least 99.8%.

3 Moderate likelihood that the product would be passed on or shipped containing the defect. The defect is an easily identified characteristic. Detection reliability: at least 98%.

4 High likelihood that the product would be passed on or shipped containing the defect. The defect is a subtle characteristic. Detection reliability: greater than 90%.

5 Very high likelihood that the product would be passed on or shipped containing the defect. Item is not checked or checkable. Defect is one that affects usefulness of product, is latent and would not appear before shipping. Detection reliability: 90% or less.

45

Calculating the Risk Factor The risk factor or R value is calculated by inserting the applicable ranking numbers (15)

selected from each of the three tables above into the following equation;

R = S2 x F x D The resulting R value, when compared to the Table 4 below, identifies the risk factor and its

associated action level with justification. R= Action Level

(R) Value Action Level Justification Criteria 0 to 24 None Risk is acceptable. Do not have to complete CA/CPA process.

25 to 48 Minimal Risk is acceptable if cost of preventive corrective action is moderate to high (specific corrective action should be taken if possible). Fix if cost is low.

49 to 96 Moderate Risk is acceptable if cost of corrective action is high or preventive barriers are put in place; otherwise fix.

97 to 192 High Risk warrants considerable cost expenditure. Look for lower-cost alternates if cost is prohibitive.

193 + Very High Risk is totally unacceptable. Fix at any cost.

Table 4. A Supplier Corrective Action Request (SCAR) response, regardless of the action level

determined, must be provided to the initiator in accordance with the chapter on assessments. A SCAR response for the action level of none will report the risk calculation, justification for each of the ranking criteria selected, and justification for the action level obtained. Elaborate on the justification criteria selected by stating why the risk is acceptable. Provide objective evidence supporting your justification, including responsible management approval. The initiator reserves the right to require a complete analysis and corrective action investigation if the justification is determined by the customer not to be acceptable.

46

ATTACHMENT C SCAR REVIEW AND APPROVAL GUIDE

The single points of contact (SPOCs) see these steps as the minimum required information and action on a SCAR before he will approve it:

Team Members: Are all vested owners listed on the team? Event Question: Does it starts with WHY? Check to make sure the question is the proper one coming from the event description.

Causes: Are all causes, including sub-tier impact, listed? Causes must make sense when read in order (forms a cause chain!). Test the chain by going backwards.

In Case of Operator Error as a Cause: Document the answers to the four questions. Improper tools? Improper training? Improper instructions? Lost expectation?

Corrective Actions: Provide who (by name), what, and when for each action, even if it is already complete. Include any subtier supplier involvement.

Specific CA: Must address the direct cause and/or effects. Preventive CA: Must addresses contributing or root causes.

Does each CA have a corresponding cause on the chain? Are mistake-proofing devices used and the types listed?

Did the team get buy-in from their management for corrective actions outside the teams authority?

Outstanding CA must have a final due date entered in the follow-up panel. Analysis of given defect against work in process, inventory, and product shipped or in shipping cycle or in the field? If no other product was affected, state why.

Systemic Issues: Did the team identify and address them? Professionally Written: Check for complete sentences, grammar, and punctuation. Readability will it make sense to the customer?

47

ATTACHMENT D SUPPLIER CORRECTIVE ACTION REQUEST (SCAR)

Issue Date:____/_____/____ Response Due Date:____/____/____ Extension Date:____/___/____

To Supplier Contact: Supplier Code #: Title:

Name:

From:

E-mail: Address:

Phone:

FAX:

Subject Part # _____________ Rejection Tag Reference #__________________

Corrective action expectations and requirements: Corrective action is required in accordance with Subsection 2.9 of the Supplier Quality Assurance

Requirements (SQAR) and this notification. Suppliers and their subtiers shall conduct an analysis to establish cause and impact, determine corrective action, implement corrective action and follow-up to validate effectiveness of implemented corrective actions.

Extensions:

Notification in writing (email is acceptable) is required within 48 hours prior to the due date with justification.

As applicable provide revised CA completion dates, status of your investigation, and list of the action taken and actions to be taken.

Guidelines: To assist in clarification of terms and completion of the requirements stated above, cause analysis

and preventive corrective action guideline materials can be viewed on the OASIS Web Site (http://oasis.northgrum.com). Northrop Grumman Integrated Systems encourages suppliers to study and utilize these materials as they communicate the desired result of an effective corrective action process. On-site assistance can be obtained by contacting your assigned Northrop Grumman Integrated Systems Materiel Quality and Technical Services representative.

48

INSTRUCTIONS A report containing the required report information, noted below, approved and signed by the

responsible supplier quality representative, must be submitted to the Northrop Grumman SCAR initiator. Supporting documentation of the analysis and corrective actions must be included with the report. Submit report to the initiator via fax or email on suppliers letterhead attached to the SCAR.

Required Report Information

The capture of all affected product and document status:

Work in process (WIP), include quantities Stock/inventory, include quantities Shipping cycle, include last ship date Indicate conformance status of parts, i.e., suspect, nonconforming, or conforming. Traceable part marking identifier applied to product (in accordance with SQAR 3.2).

Root Cause Analysis

Using a WHY analysis process, identify and document direct causes and contributing causes leading to the root cause. This analysis must consider and document any like parts, product, or processes that may also be affected.

NOTE: If you determine that the nonconformance is not your responsibility, respond to initiator with your analysis and all appropriate supporting documentation.

Provide Immediate CA

Document the actions that will be taken to correct the direct cause. Include dates of completion. Provide assurance that all affected product has been captured and the next shipment has been flagged for 100 percent verification by your Quality Department prior to shipment.

NOTE: Northrop Grumman Integrated Systems Inspection at your site is required to verify the immediate CA of product scheduled for delivery prior to full implementation of corrective action. Platinum suppliers are not exempt.

Provide Preventative CA

Document actions that will be taken against the contributing causes to prevent recurrences of the event. This action ensures that the correction of the event is applied to other parts, product, or processes that are affected.

49

Required Report Information ( continued) Implementation of CA

Document when implementation of immediate and preventative actions, respectively, actually occur and what the results were.

Subtier Impact

When subtier involvement is identified, a subtier corrective action report shall meet all of the aforementioned requirements and is to be included in the final report to Northrop Grumman Integrated Systems.

CA Effectivity

Provide the date that culminates the actions of your Corrective action Plan and signals the point at which the subject product or process will be ready for validation to confirm the effectiveness of the CA.

Verification of Corrective Action (VCA)

Provide objective evidence of corrective action validation and effectiveness of implemented corrective action. Include validation of subtier corrective action plans. Submit records of verification to SCAR initiator.

NOTE: Northrop Grumman Integrated Systems may review objective evidence during a Verification of Corrective action review at your site.

Tutorial: