Problem Identification Tool /

Problem Audit
Dr Muhammad Anshari
What is a root cause?
ROOT CAUSE =
• The causal or contributing factors that, if corrected, would prevent recurrence of
the identified problem

• The “factor” that caused a problem or defect and should be permanently

eliminated through process improvement

• The factor that sets in motion the cause and effect chain that creates a problem

• The “true” reason that contributed to the creation of a problem, defect or

nonconformance
2 © 2004 Superfactory™. All Rights Reserved.
What is root cause analysis?
• A standard process of:

 identifying a problem
 containing and analyzing the problem
 defining the root cause
 defining and implementing the actions required to eliminate the root cause
 validating that the corrective action prevented recurrence of problem

Root cause analysis is part of a complete corrective action

process. Getting to root cause is only half the battle.
Preventing the root cause requires many more additional
steps

3 © 2004 Superfactory™. All Rights Reserved.

Benefits
By eliminating the root cause…
You save time and money!
• Problems are not repeated
• Reduce rework, retest, re-inspect, poor quality costs, etc…
• Problems are prevented in other areas
• Communication improves between groups and
• Process cycle times improve (no rework loops)
• Secure long term company performance and profits

$$ Less rework = Increased profits! $$

4 © 2004 Superfactory™. All Rights Reserved.
Importance of the root cause
Not knowing the root cause can lead to costly band aids.

• The Washington Monument was degrading

Why? Use of harsh chemicals
Why? To clean up after pigeons
Why so many pigeons? They eat spiders and there are a lot of spiders
at the monument
Why so many spiders? They eat gnats and lots of gnats at the
monument
Why so many gnats? They are attracted to the light at dusk.
Solution: Turn on the lights at a later time.
5 © 2004 Superfactory™. All Rights Reserved.
When should root cause analysis
be performed?
When PROBLEMS occur !!

6 © 2004 Superfactory™. All Rights Reserved.

 How does it differ from what we do
now?
USUAL APPROACH
Firefighting! Problem
Problem
Immediate Containment reoccurs
Identified
Action Implemented elsewhere!

Find
someone to
blame!

PREFERRED APPROACH
Immediate Defined Solutions are
Solutions
Problem Containment Root Cause applied across
validated
Identified Action Analysis company and
with data
Implemented Process never return!

7 © 2004 Superfactory™. All Rights Reserved.

Root Cause Analysis
Tracing a Problem to its Origins
• In medicine, it's easy to understand the difference between treating
the symptoms and curing the condition. A broken wrist, for example,
really hurts! But painkillers will only take away the symptoms; you'll
need a different treatment to help your bones heal properly.
• But what do you do when you have a problem at work? Do you jump
straight in and treat the symptoms, or do you stop to consider
whether there's actually a deeper problem that needs your attention?
If you only fix the symptoms – what you see on the surface – the
problem will almost certainly return, and need fixing over, and over
again.
RCA
• However, if you look deeper to figure out what's causing the problem, you
can fix the underlying systems and processes so that it goes away for good.
• Root Cause Analysis (RCA) is a popular and often-used technique that helps
people answer the question of why the problem occurred in the first place.
It seeks to identify the origin of a problem using a specific set of steps, with
associated tools, to find the primary cause of the problem, so that you can:
• Determine what happened.
• Determine why it happened.
• Figure out what to do to reduce the likelihood that it will happen again.
A Brief History Behind Root Cause Analysis (RCA)
• Developed by Sakichi Toyoda who later founded Toyota Motor
Company.
• RCA was first used during the development of Toyota’s manufacturing
processes in 1958.
 Process- RCA has five identifiable steps.
• Step One: Define the Problem
• What do you see happening?
• What are the specific symptoms?
• Step Two: Collect Data
• What proof do you have that the problem exists?
• How long has the problem existed?
• What is the impact of the problem?
• You need to analyze a situation fully before you can move on to look at factors
that contributed to the problem. To maximize the effectiveness of your RCA, get
together everyone – experts and front line staff – who understands the situation.
People who are most familiar with the problem can help lead you to a better
understanding of the issues.
• A helpful tool at this stage is CATWOE. With this process, you look at the same
situation from different perspectives: the Customers, the people (Actors) who
implement the solutions, the Transformation process that's affected, the World
view, the process Owner, and Environmental constraints.
 Process
• Step Three: Identify Possible Causal Factors
• What sequence of events leads to the problem?
• What conditions allow the problem to occur?
• What other problems surround the occurrence of the central problem?
• During this stage, identify as many causal factors as possible. Too often, people
identify one or two factors and then stop, but that's not sufficient. With RCA, you
don't want to simply treat the most obvious causes – you want to dig deeper.
• Step Four: Identify the Root Cause(s)
• Why does the causal factor exist?
• What is the real reason the problem occurred?
• Use the same tools you used to identify the causal factors (in Step Three) to look at
the roots of each factor. These tools are designed to encourage you to dig deeper at
each level of cause and effect.
Process
• Step Five: Recommend and Implement Solutions
• What can you do to prevent the problem from happening again?
• How will the solution be implemented?
• Who will be responsible for it?
• What are the risks of implementing the solution?
• Analyze your cause-and-effect process, and identify the changes needed for
various systems. It's also important that you plan ahead to predict the effects
of your solution. This way, you can spot potential failures before they happen.
RCA – 5 Why’s
• RCA may be as simple as asking “five whys”:
• The worker fell. Why?
• Oil on the floor. Why?
• Broken part. Why?
• The parts keep failing. Why?
• Changes in procurement practices. Why?
5 Whys Continued
• By the fifth why, the auditor should have identified or
be close to identifying the root cause. More complex
issues may require a greater investment of resources
and more rigorous analysis.
• Prior to commencing RCA for more complex issues,
auditors should consider:
– Time
– Skill sets
Potential RCA Barriers
• Prior to performing RCA, internal auditors should
anticipate the following potential barriers:
• Management may be reluctant to support internal audit’s
role in RCA.
• Management may resist due to time and resource
commitments.
• RCA may be difficult and subjective
• RCA that leads to specific concrete observations and
recommendations could be perceived to be placing the
auditor in the role of Management.
Environmental Factors
• Most root causes can be traced back to decisions,
actions, or inactions by one or more employees.
• Some of these could be:
• Competence of personnel
• Hiring qualified personnel
• Lack of or insufficient training
• Adequacy of technology or tools
• Appropriateness of organization or departmental culture
• Health of the organization or departmental morale
• Level or number of resources (budget/personnel)
Environmental Factors Continued
• Process circumstances and other influencing items that led
the person or persons to make the decisions
• Decision-making authority of the person or persons
involved.
Techniques
• Five Whys
• Failure mode and effects analysis (FAMEA)
• SIPOC (Suppliers, inputs, processes, outputs,
customers diagram.
• Flowcharting of the process flow, system flow, and
data flow.
• Fishbone diagrams
• Critical to quality metrics
• Pareto chart
• Statistical Correlation
RCA – 5 Why’s

1. Write down the specific problem - The worker fell. Why?

2. Write down answer; Oil on the floor. Ask 2nd Why?
3. Continue until what you consider is the true root cause is
defined.
4. Don’t allow an early believable answer keep you from
continuing to ask why. Broken part. Why?
5. The parts keep failing. Why?
6. Changes in procurement practices. Why?
How does it work?
Defect found at “Customer”…
PROCESS PROCESS PROCESS PROCESS
A B C D

CUSTOMER

“Customer” can be
Internal or External

21 © 2004 Superfactory™. All Rights Reserved.

How does it work?
Contain the problem…
PROCESS PROCESS PROCESS PROCESS
A B C D

CUSTOMER

Nothing is allowed to further

escape to the customer

22 © 2004 Superfactory™. All Rights Reserved.

How does it work?
Contain the root process…
PROCESS PROCESS PROCESS PROCESS
A B C D

CUSTOMER

Nothing is allowed to further

escape to the next process

23 © 2004 Superfactory™. All Rights Reserved.

How does it work?
Prevent the problem…
PROCESS PROCESS PROCESS PROCESS
A B C D

CUSTOMER

Corrective action implemented so

root cause of problem does not
occur again!

24 © 2004 Superfactory™. All Rights Reserved.

But who’s to blame?
• The “no blame” environment is critical
• Most human errors are due to a process error
• A sufficiently robust process can eliminate human errors
• Placing blame does not correct a root cause situation
• Is training appropriate and adequate?
• Is documentation available, correct, and clear?
• Are the right skillsets present?

25 © 2004 Superfactory™. All Rights Reserved.

Corrective Actions
3 types of Corrective Action:

• Immediate action

• The action taken to quickly fix the impact of the problem so the “customer” is
not further impacted

• Permanent root cause corrective action

• The action taken to eliminate the error on the affected process or product

• Preventive (Systemic) root cause corrective action

• The action taken to Prevent the error from recurring on any process or
26
product © 2004 Superfactory™. All Rights Reserved.
Examples of Corrective Actions
Immediate (step #3)
All current batch of paperwork re-inspected by another worker for
same type of problem
Permanent (step #5)
Form changed to mandate completion of certain fields

Preventive (step #5)

Similar forms with same fields used all over in company are
changed to “mandatory”

If preventive not addressed, problem will return!!

27 © 2004 Superfactory™. All Rights Reserved.

Examples of Corrective Actions
Immediate (step #3)
Part removed and replaced in product, retested

Permanent (step #5)

Product redesigned to account for part variability

Preventive (step #5)

Design process changed to require variation analysis testing on
similar supplier parts

If preventive not addressed, problem will return!!

28 © 2004 Superfactory™. All Rights Reserved.

The Difference between Permanent vs. Preventive Corrective Actions
Permanent Preventive
• Trained employee on proper  Made training a requirement to
machine use new employees working in that
area
• Changed product design to make  Changed design guidelines to not
parts easier to assemble manually allow for use of part in full scale
production
• Specific customer document critical
 All documents that are critical to
to project is identified with red
project are identified with red
folder folders
• Update all customers with latest  Check for those software bugs
software revision to fix problem added to checklist and performed
prior to release of software
• Fallen patient given full-time  Process developed to identify “at
assistant to provide help moving risk” patients for falls who require
around hospital assistant
• Employee fired for ethical violation  Ethics training developed and
provided to all employees

29 © 2004 Superfactory™. All Rights Reserved.

Problem Solving Process
1

Identify
8 Problem 2

Validate Identify
Team
7 3
Problem
Follow Up Immediate
Plan Solving Action

Process
Complete Root
Plan Cause

Action
6 Plan
4

5
30 © 2004 Superfactory™. All Rights Reserved.
Step #1
Identify the Problem
Very important!

• Clearly state the problem the team is to solve

• Teams should refer back to problem statement to
avoid getting off track
• Use 5W2H approach
• Who? What? Why? When? Where? How? How
Many?

© 2004 Superfactory™. All Rights Reserved. 31

Step #1
5W2H
• Who? Individuals/customers associated with problem
• What? The problem statement or definition
• When? Date and time problem was identified
• Where? Location of complaints (area, facilities, customers)
• Why? Any previously known explanations
• How? How did the problem happen (root cause) and how will the problem
be corrected (corrective action)?
• How Many? Size and frequency of problem

© 2004 Superfactory™. All Rights Reserved. 32

Step #2
Identify Team
When a problem cannot be solved quickly by an individual, use a team!

• Should consist of domain knowledge experts

• Small group of people (4-10) with process and product knowledge,
available time and authority to correct the problem
• Must be empowered to “change the rules”
• Should have a designated Champion
• Membership in team is always changing!

© 2004 Superfactory™. All Rights Reserved. 33

Step #2
Key Ideas for Team Success

• Define roles and responsibilities

• Identify external customer needs
• Identify internal customer needs
• Appropriate levels of organization present
• Clearly defined objectives and outputs
• Solicit input from everyone!
• Good meeting location
• near work area for easy access to info
• quiet for concentration and avoiding distractions
© 2004 Superfactory™. All Rights Reserved. 34
Step #2
Roles and Responsibilities

• Champion: Mentor, guide and direct teams, advocate to upper

management
• Leader: day-to-day authority, calls meetings, facilitation of
team, reports to Champion
• Record Keeper: Writes and publishes minutes
• Participants: Respect all ideas, keep an open mind, know their
role within team

© 2004 Superfactory™. All Rights Reserved. 35

Step #3
Immediate Action

• Must isolate effects of problem from customer

• Usually “Band-aid” fixes
• 100% sorting of parts
• Re-inspection before shipping
• Rework
• Recall parts/documents from customer or from storage
• Only temporary until corrective action is implemented (very
costly, but necessary)
• Must also verify that immediate action is effective
© 2004 Superfactory™. All Rights Reserved. 36
 Step #3
Verify Immediate Action

• Immediate action = activity implemented to screen, detect

and/or contain the problem
• Must verify that immediate action was effective
• Run Pilot Tests
• Make sure another problem does not arise from the
temporary solutions

• Ensure effective screens and detections are in place to prevent

further impact to customer until permanent solution is
implemented.
© 2004 Superfactory™. All Rights Reserved. 37
Step #4
Root Cause

• Brainstorm possible causes of problem with team

• Organize causes with Cause and Effect Diagram
• “Pareto” the causes to identify those most likely or occurring
most often
• Use 5 Why? method to further define the root cause of
symptoms
• May involve additional research/analysis/investigation to
get to each “Why?”
• Must identify the process that caused the problem
• if root cause is company-wide, elevate these process issues
(outside of team control) to upper management to address
© 2004 Superfactory™. All Rights Reserved. 38
Step #4
Tools
 brainstorming  5 Why
 flowcharting  failure mode, effect
 cause & effect & criticality analysis
diagrams  fault tree analysis
 pareto charts
 barrier analysis
 change analysis

© 2004 Superfactory™. All Rights Reserved. 39

Step #4
5 Why’s

• Ask “Why?” five times

• Stop when the corrective actions do not change
• Stop when the answers become less important
• Stop when the root cause condition is isolated

© 2004 Superfactory™. All Rights Reserved. 40

 What is a Cause-Effect Diagram?

• A Cause-Effect (also called “Ishikawa” or “Fishbone”)

Diagram is a Data Analysis/Process Management Tool
used to:

• Organize and sort ideas about causes contributing to

a particular problem or issue
• Gather and group ideas
• Encourage creativity
• Breakdown communication barriers
• Encourage “ownership” of ideas
• Overcome infighting

41 © 2004 Superfactory™. All Rights Reserved.

 Cause-Effect Diagram

• A Cause-Effect Diagram is typically generated in a

group meeting
• It is a graphical method for presenting and sorting
ideas about the causes of issues or problems

42 © 2004 Superfactory™. All Rights Reserved.

 Cause-Effect Diagram
• Steps used to create a Cause-Effect Diagram:
• Define the issue or problem clearly
• Decide on the root causes of the observed issue or
problem
• Brainstorm each of the cause categories
• Write ideas on the cause-effect diagram. A generic
example is shown below:

Materials Methods

Environment Effect
Equipment People

NOTE: Causes are not limited to the 5 listed categories, but serve as a starting point

43 © 2004 Superfactory™. All Rights Reserved.

 Cause-Effect Diagram
• Allow team members to specify where ideas fit into the diagram
• Clarify the meaning of each idea using the group to refine the
ideas. For example:

Materials Methods

Incorrect Quantity Late Dispatch

Spillage
Incorrect BOL Shipping Delay
Wrong Destination

Traffic Delays

Shipping
Environment
Wrong Equipment
Problems
Weather Driver
Dispatcher Attitude
Breakdown Dirty Equipment Wrong Directions

Equipment People

44 © 2004 Superfactory™. All Rights Reserved.

 Cause-Effect Diagram
• After completing the Cause-Effect Diagram, take the
following actions:
• Rank the ideas from the most likely to the least likely
cause of the problem or issue
• Develop action plans for identifying the essential data,
resources and tools

45 © 2004 Superfactory™. All Rights Reserved.

 Expected Outcome
• Individuals have become part of a problem
solving team
• The sources of problems and other issues have
been identified using a systematic process
• Team members see issues from a similar
perspective
• Ideas and solutions are documented
• Communication is improved
• Team members assume ownership

46 © 2004 Superfactory™. All Rights Reserved.

Step #5
Corrective Action Plan

• Must verify the solution will eliminate the problem

• Verification before implementation whenever possible
• Define exactly…
• What actions will be taken to eliminate the problem?
• Who is responsible?
• When will it be completed?
• Make certain customer is happy with actions
• Define how the effectiveness of the corrective action will
be measured.
© 2004 Superfactory™. All Rights Reserved. 47
Step #5
Verification vs. Validation
(Before) (After)

• Verification
• Assures that at a point in time, the action taken will
actually do what is intended without causing another
problem

• Validation
• Provides measurable evidence over time that the
action taken worked properly, and problem has not
recurred
© 2004 Superfactory™. All Rights Reserved. 48
Step #6
Complete Action Plan

• Make certain all actions that are defined are completed

as planned

• If one task is still open, verification and validation is

pushed back

• If the plan is compromised, most likely the solution will

not be as effective

© 2004 Superfactory™. All Rights Reserved. 49

Step #7
Follow Up Plan

• What actions will be completed in the future to ensure that the root cause
has been eliminated by this corrective action?
• Who will look at what data?
• How long after the action plan will this be done?
• What criteria in the data results will determine that the problem has not
recurred?

© 2004 Superfactory™. All Rights Reserved. 50

Step #8
Validate and Celebrate

• What were the results of the follow up?

• If problem did reoccur, go back to Step #4 and re-evaluate root cause, then
re-evaluate corrective action in Step #5
• If problem did not reoccur, celebrate team success!

• Document savings to publicize team effort, obtain customer satisfaction and

continued management support of teams

© 2004 Superfactory™. All Rights Reserved. 51

What does a good RCA look like?
• The Root Cause is
• Internally Consistent ,
• Thorough, and
• Credible

52 © 2004 Superfactory™. All Rights Reserved.

What does a good RCA look like?
The Complete Root Cause Analysis is
• inter-disciplinary, involving experts from the frontline services
• involving of those who are the most familiar with the situation
• continually digging deeper by asking why, why, why at each level
of cause and effect.
• a process that identifies changes that need to be made to
systems
• a process that is as impartial as possible

53 © 2004 Superfactory™. All Rights Reserved.

What does a good RCA look like?
To be thorough a Root Cause Analysis must
include:
• determination of human & other factors
• determination of related processes and systems
• analysis of underlying cause and effect systems
through a series of why questions
• identification of risks & their potential contributions
• determination of potential improvement in
processes or systems

54 © 2004 Superfactory™. All Rights Reserved.

What does a good RCA look like?
To be Credible a Root Cause Analysis must:
• include participation by the leadership of the
organization & those most closely involved in
the processes & systems
• be internally consistent

55 © 2004 Superfactory™. All Rights Reserved.

Hints about root causes
• One problem may have more than one root cause
• One root cause may be contributing to many problems
• When the root cause is not addressed, expect the problem to reoccur
• Prevention is the key!

56 © 2004 Superfactory™. All Rights Reserved.

Review
• You learned:
• How to identify the root cause
• Why it is important
• The process for proper root cause analysis
• How basic quality tools can be applied to examples

57 © 2004 Superfactory™. All Rights Reserved.

Manufacturing

Root Cause Analysis

Example #1

58 © 2004 Superfactory™. All Rights Reserved.

Example #1
Identify Problem

Part polarity reversed on circuit board

© 2004 Superfactory™. All Rights Reserved. 59

Determine Team
• Team members:
• Team Leader – Terry
• Inspector – Jane
• Worker – Tammy
• Worker - Joe
• Quality Eng – Rob
• Engineer – Sally

60 © 2004 Superfactory™. All Rights Reserved.

Immediate Action
• Additional inspection added after this assembly process step to check
for reversed part defects

• Last 10 lots of printed circuit boards were re-inspected to check for

similar errors

61 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Part reversed

Why?

62 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Part reversed

Worker not sure of correct part orientation

Why?

63 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Part reversed

Worker not sure of correct part orientation

Part is not marked properly

Why?

64 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Part reversed

Worker not sure of correct part orientation

Part is not marked properly

Engineering ordered it that way from vendor

Why?

65 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Part reversed

Worker not sure of correct part orientation

Part is not marked properly

Engineering ordered it that way from vendor

Process didn’t account for possible

manufacturing issues

66 © 2004 Superfactory™. All Rights Reserved.

Corrective Action

• Permanent – Changed part to one that can only be placed in correct

direction (Mistake proofed). Found other products with similar
problem and made same changes.

• Preventive - Required that any new parts selected must have

orientation marks on them.

67 © 2004 Superfactory™. All Rights Reserved.

 Root Cause Analysis
Example #2

68 © 2004 Superfactory™. All Rights Reserved.

Example #2

Identify Problem

A manager walks past the assembly line and notices a puddle of water on the
floor. Knowing that the water is a safety hazard, she asks the supervisor to
have someone get a mop and clean up the puddle. The manager is proud
of herself for “fixing” a potential safety problem.

69 © 2004 Superfactory™. All Rights Reserved.

Example #2

But What is the Root Cause?

The supervisor looks for a root cause by asking 'why?’

70 © 2004 Superfactory™. All Rights Reserved.

Immediate Action
Knowing that the water is a safety hazard, the manager asks the supervisor
to have someone get a mop and clean up the puddle.

71 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Puddle of water on the floor

Why?

72 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Puddle of water on the floor

Leak in overhead pipe

Why?

73 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Puddle of water on the floor

Leak in overhead pipe

Water pressure is set too high

Why?

74 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Puddle of water on the floor

Leak in overhead pipe

Water pressure is set too high

Water pressure valve is faulty

Why?

75 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Puddle of water on the floor

Leak in overhead pipe

Water pressure is set too high

Water pressure valve is faulty

Valve not in preventative maintenance program

76 © 2004 Superfactory™. All Rights Reserved.

Corrective Action
• Permanent – Water pressure valves placed in preventative
maintenance program.

• Preventive - Developed checklist form to ensure new equipment is

reviewed for possible inclusion in preventative maintenance program.

77 © 2004 Superfactory™. All Rights Reserved.

Example #3

Root Cause Analysis

Example #3

78 © 2004 Superfactory™. All Rights Reserved.

Example #3

Identify Problem

Customers are unhappy because they are being shipped products that
don't meet their specifications.

79 © 2004 Superfactory™. All Rights Reserved.

Immediate Action
Inspect all finished and in-process product to ensure it meets customer
specifications.

80 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Product doesn’t meet specifications

Why?

81 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Product doesn’t meet specifications

Manufacturing specification is different from

what customer and sales person agreed to
Why?

82 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Product doesn’t meet specifications

Manufacturing specification is different from

what customer and sales person agreed to

Sales person tries to expedite work by calling

head of manufacturing directly
Why?

83 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Product doesn’t meet specifications

Manufacturing specification is different from

what customer and sales person agreed to

Sales person tries to expedite work by calling

head of manufacturing directly

Manufacturing schedule is not available for

sales person to provide realistic delivery date
Why?

84 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Product doesn’t meet specifications

Manufacturing specification is different from

what customer and sales person agreed to

Sales person tries to expedite work by calling

head of manufacturing directly

Manufacturing schedule is not available for

sales person to provide realistic delivery date

Confidence in manufacturing schedule is not

high enough to release/link with order system

85 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Confidence in manufacturing schedule is not
high enough to release/link with order system

Why?

86 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Confidence in manufacturing schedule is not
high enough to release/link with order system

Parts sometimes not available thereby

creating schedule changes
Why?

87 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Confidence in manufacturing schedule is not
high enough to release/link with order system

Parts sometimes not available thereby

creating schedule changes

Expediting and priority changes consume

parts not planned for
Why?

88 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Confidence in manufacturing schedule is not
high enough to release/link with order system

Parts sometimes not available thereby

creating schedule changes

Expediting and priority changes consume

parts not planned for

Manufacturing schedule does not reflect

realistic assembly and test time
Why?

89 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Confidence in manufacturing schedule is not
high enough to release/link with order system

Parts sometimes not available thereby

creating schedule changes

Expediting and priority changes consume

parts not planned for

Manufacturing schedule does not reflect

realistic assembly and test time

No ongoing review of manufacturing standards

90 © 2004 Superfactory™. All Rights Reserved.

Corrective Action
• Permanent – Manufacturing standards reviewed and updated.

• Preventive - Regular ongoing review of actuals vs standards is

implemented.

91 © 2004 Superfactory™. All Rights Reserved.

 Root Cause Analysis
Example #4

92 © 2004 Superfactory™. All Rights Reserved.

Example #4

Identify Problem

Department didn’t complete their project on time

93 © 2004 Superfactory™. All Rights Reserved.

Determine Team
• Team members:
• Boss – Jim
• Worker – Tom
• Worker - Karen
• Project Mgr – Bob
• Admin – Sally

94 © 2004 Superfactory™. All Rights Reserved.

Immediate Action
• Additional resources applied to help get the project team back on
schedule

• No new projects started until Root Cause Analysis completed

95 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Didn’t complete project on time

Why?

96 © 2004 Superfactory™. All Rights Reserved.

Cause and Effect
Procedures Personnel
Lack of worker
knowledge
Poor project plan
Poor project
mgmt skills Lack of resources

Didn’t complete
project on time

Inadequate Poor Inadequate

computer documentation computer system
programs

Materials Equipment

97 © 2004 Superfactory™. All Rights Reserved.

Cause and Effect
Procedures Personnel
Lack of worker
knowledge
Poor project plan
Poor project
mgmt skills Lack of resources

Didn’t complete
project on time

Inadequate Poor Inadequate

computer documentation computer system
programs

Materials Equipment

98 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Didn’t complete project on time

Resources unavailable when needed

Why?

99 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Didn’t complete project on time

Resources unavailable when needed

Took too long to hire Project Manager

Why?

100 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Didn’t complete project on time

Resources unavailable when needed

Took too long to hire Project Manager

Lack of specifics given to

Human Resources Dept
Why?

101 © 2004 Superfactory™. All Rights Reserved.

Root Cause
Didn’t complete project on time

Resources unavailable when needed

Took too long to hire Project Manager

Lack of specifics given to

Human Resources Dept

No formal process for submitting job opening

102 © 2004 Superfactory™. All Rights Reserved.

Corrective Action
• Permanent – Hired another worker to meet needs of next project
team

• Preventive - Developed checklist form with HR for submitting job

openings in the future

103 © 2004 Superfactory™. All Rights Reserved.