Problem solving

Why we have this training course?

TL 9000 requirement
Problem solving is not good status in CFT
Career development / growth for individuals in our org
Before everything else….
Problem solving agenda
Before we start … 10 min
Course Objectives
Why we Need standard & structure Problem Solving Process
Problem Solving R&R’s
When it is a problem?
Notes on problem solving
Problem Solving Step 1&2 15 min
Write Down Your Problem Statement 15 min
Group Activity: Characterize your Problem 20 min
Problem Solving Steps 3-8 45 min
Before we start …
Course objective
Focus on problem-solving principles
Understand how to look at problems and decide which ones are worth
solving
Understand the ownership for the management of the problem-solving
process and leverage people on problem-solving
Establish a common nomenclature, process & report out template for the
company
Provide an understanding of variation & process capability &
common/special cause
Why Do We Need Structured
& Standard Problem Solving Approach?
To develop a consistent methodology by which we approach problem
solving such that we get the most gain for our resource investment
To develop a consistent communication process for which problems are to
be solved and leaders appointed/status provided for each problem
To have a common language for how we approach problem solving
To establish a common process for engaging the workforce in the problem
solving process and eliminating duplication of effort
Problem solving R&R
Problem Type Team R&R
Product Launching NPI/FPM Own the overall problem solving tree
Ensure the right issues are being addressed & prioritize
Product MFR PE issues
Assign the right owners
Ensure the right team is put in place
Ensure right reports are being communicated & right
forums are being held
Ensure timely & meaningful progress is being made
NRF’s MTE Ensure the right issues are being addressed & prioritize
Cost/process capability AO issues
Assign the right owners
Inventory AO Ensure the right team is put in place
Specific issues contained Area Ensure right reports are being communicated & right
within your sphere of Owner forums are being held
influence Ensure timely & meaningful progress is being made
When it is a problem?

•
•
•
Notes on problem solving

• Never lie or mislead during problem solving, or you need bigger lies to cover and
you shall drag the company into dangerous area which you are not able to
handle.
• Each problem means we are in trouble and it may high impact to cost and
reputation. Make sure we learn the lesson and find out how not to repeat again.
Problem solving steps …
 Problem solving steps
D1: Establish a team • Establish a Problem Solving Team

• Create a Problem Statement

• Conduct a Stakeholder Analysis
D2: Problem statement
• Develop Interim Containment Action
(optional)
(Temporary Fix(s))
D3: Containment action • Develop Action Plan(s) to implement
the Interim Containment
• Identify Possible Causes • Verify the Interim Containment
• Conduct a Root Cause Analysis D4: Root cause analysis
• Verify Root Causes
• Identify Possible Corrective Action(s)
(Solutions)
D5: Corrective action
• Conduct a Risk Analysis
• Implement & Validate Corrective
Action(s)
• Prevent recurrence of the problem D6: Preventive action
• Audit Corrective Action(s)
D7: Sustaining control • Classification of Problems
• Remove the Interim Containment
• Recognize Team & Individual Contributions D8: Team congratulation
D1: Establish a team
Establish a Problem Solving Team
 Team leader: Problem owner, agent-in-charge, responsible for acting with a sense of
urgency, competence & accountability
 Team members: Cross functional with right mix of skills, experience & authority
Team member responsibilities
 Focus on the purpose of the team
 Think less about personal goals and more about the success of the team as a whole
 Work to develop an atmosphere of trust and respect among team members
 Communicate clearly & participate fully
 Make realistic commitments & keep them
D1: Establish a team
Team members should focus on the questions
 Be an expert problem solver, not a policeman or blamer
 Focus on the questions, not the people
 Use questions such as: “What should be happening?”, “What is actually happening?”
Solo Investigator (do this when you have a small problem)
 Small problems are often investigated by a solo Problem Solving Investigator
 Should work with Information Collaborator’s (folks that do the work, suppliers,
experts, customers) to gain enough perspectives

Establishing a Team Common Pitfalls: Poor Team Participation, Team member taking on more than
they can do, failure to assign clear tasks, failure to consider outside influences/competing priorities
D1: Establish a team
Do I need Stakeholder Analysis?
This is an optional stage, depends on severity & size of the problem
Perform Stakeholder analysis when the problem: spans departments, affects current org procedures
and/or policies, creates large financial issues, affects people outside of the problem solving team
When not to involve Stakeholders: affects only those tasked with the problem, is not a significant
financial issue
Stakeholder Analysis Questions:
 Who are the stakeholders affected by this problem?
 What is the effect of the problem on each Stakeholder
 What are the positive of addressing the problem for each Stakeholder?
 What are the negative of addressing the problem for each Stakeholder?
 What is the commitment level of the Stakeholder(s) to solve the Problem? (complete, partial, none)
 If not complete commitment, why?

Stakeholder Analysis Pitfalls: Not telling stakeholders why you are investigating a problem, not
explaining why the problem is worth investigating
D2: Problem statement
Characterize the issue: A well formed Problem Statement is a
clear, concise, multi-perspective, in-depth view of the
problem collected from as many information holders as
possible
Example of well formed PS: Example of poor PS:
Cant not read PSN found in Neo and Kesa production line with FR of 20% Found can not read PSN in Neo and Kesa production line
and impact is reducing 30% of line capacity

Neo OBA issue, LCD failed with symptom screen contrast much worse to Neo OBA issue screen abnormal due to not removing protective of
normal phone LCD

Antman S01, Dek machine error connecting to program impact 10% capacity, Antman S01 stop line Dek machine error
line stop.
D2: Problem statement
Create A Well Formed Problem Statement
Questions to Ask Description
What Seems to be the Problem?  Initial Problem Perception: Your first impression of the problem, before any analysis has occurred.

Why it is the problem?  What is the Variation (What is actually happening) vs. the Standard (What should be happening)?
 Variation: A change or deviation in an accepted process, condition, behavior, amount or rate (ie. Rate of production). Use data
What is the Variation vs. the Standard? analysis tools to identify variations
 Standard: An average or normal requirement, level of quality that is acceptable, etc. made permanent and used as a basis for
comparison

Where Does it Happen?  In terms of both location & process

 Look for symptoms and document where they occur
 Where does it not happen? Where it is expected to happen but does not?

When Does it Happen?  Pinpoint when it happens & when it does not

Who is Involved?  Find out who is involved

 Include internal & external customers who are affected

How is the impact?  How big is the problem (ie costs, quality issues, safety issues, org. image issues):
o How much is this costing us?
o How much waste is there?
o Was there anything put on hold?
o How long was the line down?
o Customer facing issue?
o Was anyone injured?
o Was there damage to equipment or facilities?
o Are we exposed to safety issues?

Characterize the Issue Pitfalls: A vaguely described problem; problem described incorrectly; lack of
communication; jumping to permanent solutions too early
D2: Problem statement
Suggested data analysis tools to identify variations

Check Sheets: Collects specific data for a specific process using a flexible format
Concentration/ Heatmap Diagrams: Identifies specific areas of concern within a large target area
Control Charts: Used to document the stability of a particular process over a given period of time
Regression Analysis: Differentiates between causal and symptomatic aspects of a problem
Failure Mode and Effects Analysis (FMEA): Risk assessment process
Fishbone Diagrams: Evaluates various inputs and how those inputs create a specific result
Flowcharts: Identifies specific flows of materials and other aspects of a particular process
Histograms: Represents large pools of data focusing on fluctuations in that data
Process Maps: A visual representation concerning the general organizational wide flows of a process
D2: Problem statement
Team Exercise:
Write down a clear & concise problem statement
Identify the key Stakeholders (orgs) involved
Share the problem statements with your team
Choose one problem statement & refine it
Report Out the problem statement to the rest of the class
D3: Containment action
If you already have or need to put in an interim containment, proceed to D3
If you don’t have any Temporary Fixes, move to D4 and analyze the Root Cause
If resolving the problem won’t save a significant amount of time, money or there isn’t
adequate Stakeholder commitment, stop here

Interim Containment is critical to a good problem solving process. Allows for effective
problem solving without the business pressure to get back going. (Quality or customer
implications).
D3: Containment action
Contain the problem, Interim Containment Action (ICA), Band-Aids, Short-term
corrective actions for limiting damage, Temporary Counter-measures

An interim containment action is put in place to control the situation and isolate
the effects of the problem until Permanent Solutions can be put into place
D3: Containment action
Design a Temporary Fix to control the effects of the problem
First understand & document the flow of a product & the resources needed to produce that
product
Describe the Interim Containment:
 Identify the Containment Action in as specific terms as possible
 Ensure that the Interim Containment does not create other problems
 If re-work and/or re-release are part of it, document it!
Who needs to know about the Interim Containment Action(s)?
 Identify who is affected by the Containment Action and inform them
 Inform the person(s)& location(s) that need to be aware, including those who will contribute to or maintain the
Containment Action
Describe the plan to implement the Containment Action(s):
 First test the fix before implementing, verify that it works again after its in place
 Plan includes: actions to implement the containment, who is responsible for implementing, estimated completion date,
actual completed date
 Collect data that enables you to determine effectiveness of the actions

Containment Pitfalls: Not removing the Interim Containment (can become very costly), Failure to
make sure that Interim Containment does not inadvertently cause other problems
D4: Root cause analysis
Root Cause is a symptom or factor, that if changed or removed, will
permanently eliminate the deviation from the desired standard of the
work process, work activity or work instruction

Why do a Root Cause Analysis?

 Changes the focus from describing symptoms to analyzing possible or potential causes,
finding the Root Cause and verifying it
 Prevents implementing solutions without understanding causes and/or implementing solutions
that only address symptoms
D4: Root cause analysis
Possible Cause to Root Cause Analysis
 Each possible cause should have an identified root cause
 Not all possible causes, if addressed, will prevent recurrence of the problem
 There are many methods that can be used to determine root cause (ie. 5 Why’s)

Identify Possible Causes

 This is the first step in a Root Cause Analysis
 Possible cause is anything that could be a cause or trigger the problem (potential or hypothetical cause)
 First GO and SEE the people and processes near the problem (solve problems at the source)
 Work from facts rather than solely your opinions
 Use process approach to outline process steps involved and identify POO & POD
 Follow by using brainstorming with fishbone chart to cover 4M1E
 Go through all the possible causes from 4M1E and rule out the Possible Causes with evidence (why this is
not the cause)
 Identify Possible Causes based on: General Experience, Knowledge of the process, Past experience in
problem solving, common sense and logic, input from information collaborators
D4: Root cause analysis

• Fishbone chart or Ishikawa chart has benefits in breaking down a complex problem
• into classifiable causes and allow you to deep dive.
• Fishbone chart gives you a systemic approach in problem solving, and allow you to
• plan your failure analysis in optimizing resources, time and etc.
• It is important to note, time is money to us, and to our customer
• Fish bone helps to identify factors, not true root cause yet!
D4: Root cause analysis
Develop the Why Chain
 Select a Possible Cause, and then ask “Why is this Happening?
 Take the answer to that question, and then ask “Why is that Happening?” Until there are no more why’s to ask
 Reaching Root Cause normally requires answering “Why?” a minimum of 3-5 times
 Complete “Why” Chains for all Possible Causes

The Root Cause

 The last “Why” on the chain, also known as the base cause
 Document any supporting data around “dead ends” as well as identified Root Cause
 Use data tools to help identify possible causes and confirm root causes

Will Addressing the Root Cause prevent Recurrence?

 This question validates that you have truly hit a root cause
 If no, explain why you eliminated this Root Cause by answering, “Why did you eliminate this Possible Cause?”
 Then, since it’s a Dead End, either return to you list of Possible Causes and redefine the Possible Cause you are
working on, or pick a different Possible Cause
 If yes, answer the question “How was this verified?” Do you have evidence or data to support?
 Large problems may have several Root Causes that need to be addressed
 Investigate all Possible Causes down to Root Cause since it could be a combo of Root Causes that triggers the problem
D4: Root cause analysis
Why Did you Eliminate the Possible Cause
 Detail why you determined this is not a Root Cause
 Include results of tests or theories you were not able to verify
 Retain dead ends to document what’s been investigated

How was the Root Cause Verified?

 Addressing this Root Cause will prevent recurrence
 Describe how the last “Why?” really is/was the Root Cause
 Include tests & results
 GO and SEE if this theory is true
 Use pareto and heat map to compare the data, do we see the same factor?
 If we need to verify some of the factors, use design of experiment to collect data
 If you can turn the issue on/off by controlling the variable, that is the best indication that you have true root
cause
3 way of Why
 After you verify and conclude the Root Cause, you have answered the question “Why it is happened?”
 The next 2 question needed to be answered are “Why does it escape?” “Why could not we prevent it happen?”

Cause Pitfalls: “Possible” Cause misidentified as a Root Cause, Not deep dive enough to Identify the Root Cause,
Placing Blame specially blame operator, Dealing with the Symptoms, Not specific, very descriptive
D4: Root cause analysis
DoE (Design of Experiment)
D4: Root cause analysis
D4: Root cause analysis
 Possible cause is anything that could be a cause or trigger the problem (potential
or hypothetical cause)
List Possible Causes
 Detail why you determined this is not a Root
Cause
 Include results of tests or theories you were not
able to verify Pick a Possible Cause to
 Retain dead ends to document what’s been Work
investigated
 Select a Possible Cause, and then ask “Why is this Happening?
 Take the answer to that question, and then ask “Why is that Happening?” Until
Why Chain there are no more why’s to ask
Why did you eliminate  Reaching Root Cause normally requires answering “Why?” a minimum of 3-5 times
this Possible Cause?  Complete “Why” Chains for all Possible Causes

 Root Cause is the last “Why” on the chain, also known as the base cause
Is this the Real
 Use data tools (ie. Control charts, fishbone diagrams, process maps, etc. to help
No Root Cause?
identify possible causes and confirm root causes

Yes
 Addressing this Root Cause will prevent recurrence
 Describe how the last “Why?” really is/was the Root Cause
Verify Root Cause  Include tests & results
 GO and SEE if this theory is true

 Large problems may have several Root Causes that need to be addressed
Are there more
Solutions No Possible Causes Yes  Investigate all Possible Causes down to Root Cause since it could be a combo of
to explore? Root Causes that triggers the problem
D5: Corrective action
Once All Possible Causes have “Why Chains”, and you are satisfied that by
addressing one or more Root Causes the problem will be solved…develop,
implement & validate the permanent solution(s)
A Permanent Solution is a permanent revision designed and implemented to
eliminate the Root Cause of a problem.
D5: Corrective action
Solution Description
 May need multiple solutions to address the Root Cause(s)
 Fully document the solution

Brainstorming
 If no solutions are obvious have a brainstorming session
 Make sure that a possible solution does not shift the burden for truly solving the problem to another group that is not
involved
 In Brainstorming: All ideas are valid; Produce as many ideas as you can; One idea may build on another; Everyone should
have a chance to be heard; don’t put any restraints on your ideas; get them out first & then list them in order of
effectiveness, do-ability, etc.

Corrective / Preventative
 Corrective solutions are normally fixing something that formerly worked
 Preventative solutions are those that will prevent the problem from happening again
 Approved indicates if the solution has been approved for implementation
 Responsible indicates the name of the person who will implement the solution
 Date entire solution is due & date it is actually completed
Solution Corrective / Approved Responsible Due Date
Description Preventative Yes/No Done Date
D5: Corrective action
In-Depth Corrective Action Description
 Costly, complex, multi-part, cross-functional, or high-risk solutions
 Answer & document the following questions
Questions to Ask Description
Solution Description Describe the solution
Who Should Be Involved in This Solution? Who needs to be involved in the permanent solution (a.k.a the solution team). It might not be the same as the
problem solving investigation team.
What is the approximate cost of fixing the problem Include a breakdown of all costs associated with implementing this particular solution. Include lost opportunity
for this solution? costs as well as direct costs. Approximated costs should suffice.
What are the earliest & latest estimated completion Consider what is involved & who is involved? What is the realistic timeframe? Consider time for change
dates for this solution? management, testing, design, etc.
What will you have to change to implement this Determine the consequences of each change (ie. Procedure change?). Consider how the change will impact
solution? those directly involved and ancillary: support groups/individuals, existing systems, manpower, facilities, etc.
Where will you implement this Solution Single plant, multi-plant, business process, cross-organizationally? Digital pictures may be needed.

What will be the trade-off(s) from implementing What will be given up if implemented? Will the permanent solution disrupt current ways of operating? Will it
this solution? involve additional work, time, training & resources? Will something that is currently being done suffer an effect?
What do you expect to see/have in place once this For each stakeholder, define the expectations of this specific solution. Create a vision of the future state, when
solution is implemented the solution in in place, clearly and in detail (ie. Describe how solution will look for 1 day, 1 week, 1 month, 1
year, after implementation.
D5: Corrective action
Selecting Corrective Actions to Implement
 When selecting a solution to implement you may want to:
o Compare Costs
o Compare Answers to all Permanent Solution Questions
o Compare level of consensus
o Consider if the Permanent Solution will solve the problem

Risk Analysis
 The following should be considered for each solution when deciding to implement:
o The solution team includes the right people with the right skills
o There is sufficient budget
o There is a detailed plan for the resolution of the problem
o All of the participants in the solution have sufficient time for their parts
o A cost/benefit analysis has been performed
o There is clear accountability for implementation of the solution
o The solution team has the organization support they need

Corrective Action Pitfalls: Unimaginative Ideas; Not enough solution ideas; Focusing on only one solution option; Focusing on
constraints; Selecting a solution without careful evaluation against constraints; considering budget before considering creativity
D5: Corrective action
Once Corrective Action(s) have been Selected
 Actively communicate the progress of your problem solving process to management, stakeholders, those impacted, etc. before the solution is
put in place
 Influencing others to gain their buy-in for implementing the solution involves understanding resistance. Address: 1. What level of support is
needed for the Permanent Solution? 2. How do you recognize a skeptic/non-believer
 Make sure standard work instructions reflect any changes you have made

How did you validate this Corrective Action?

 Consider a pilot program to verify the solution
 Ensure buy-in before and after testing
 Any deficiency identified in the effectiveness of the solutions must be addressed before permanent implementation
 Use Data Tools to collect and monitor your data around the problem
 Look for variation in your data which may indicate that, although the problem is not recurring, the tolerance limits of your solution are
slipping

Solution Implementation
 Construct the Solution Implementation Plan: outline what needs to be done & by whom
 Team leader: make sure all Action Plans get done
 Action Plan: details each element of the Solution Implementation Plan following a chronological sequence
 Responsible: Person who will do the action
 Due Date/Done Date: date the task is due for completion and actual date of completion

Solution: Action Plan Responsible Due Date Done Date

Team Leader:
D5: Corrective action
Corrective Action Team R&R’s
Role Responsibility
Corrective Action • If solution is complex, use a team. If not, just implement the actions.
• Could be a Problem Solving Investigator or someone with operational responsibility in the area of proposed
Implementation Team solution
Leader • Educate team about team’s purpose, limits
• Track team’s goals & achievements
• Anticipate and respond to changes in timing, schedule, workloads and programs
• Communicate with management about the team’s progress and needs
• Communicate with the rest of the organization about team’s actions and achievements
• Remove barriers to team progress
• Help resolve conflict
• Take care of logistics
Corrective Action • Shares responsibility of the success of the team
• Focus on the purpose of the team
Implementation Team • Think less about personal goals and more about the success of the team as a whole
Members • Work to develop an atmosphere of trust and respect
• Communicate clearly and participate fully
• Make realistic commitments and keep them

Other Corrective Action Pitfalls: Failure to get the needed support; team member biting off more than they can chew; Failure to
assign clear tasks; Failure to consider outside influences
D5: Corrective action
Corrective actions are usually
• Corrective the process step
• Improve or enhance a tool/jig/fixture
• Change the method e.g. test method
• Improve and update work instructions
• Improve and update training material/method
• Tighten specification
• Poka-yoke
• Update and standardize document（PFMEA！！）
D6: Preventive action
Best Practices: The best combination of people, machines, raw
materials that utilize minimal space, labor and inventory and work
together to achieve a desired result
Stop it from happening again and establish controls
D6: Preventive action
Prevent Recurrence of the problem
 Monitor or audit your corrective actions to ensure they are effective and don’t cause problems
 Use information gathered and apply it to similar situations
 Identify location, processes, and times when similar problems are likely to occur to take preventative action
 Share best practices across the organization

How will you Prevent Recurrence?

 Consider short and long term
 Document the impacted processes so you can monitor the solution for effectiveness
 Don’t forget human factors: do you still have support for the Permanent Solutions? Are people going back to their
previous mindsets or procedures?
 Communicate learnings to those remote: newsletters, emails, conference calls

Audit & Monitor Effectiveness

 Inspection and review to ensure that a process, activity or solution is implemented and performing according to
prescribed specifications (ie. Weekly visuals, data from systems)
 Audit should take place on implemented solutions before the problem is closed
 Provide and Audit Date and Audit Comments (plan to audit or audit findings)
D6: Preventive action
Common preventive action
• Owner and due date
• Review and revise PFMEA risk list
• Update PFMEA control plan e.g. poka yoke, or detection mechanism
• Apply all the above across all products that are exposed to similar risk.
• Update training standard
• Update DFx
D7: Sustaining control
Classify the Problems
 Open: In-progress, actively being worked
 On-hold: No longer being worked on, but will be when there is more time
 Closed: Solved problems should only be closed once they’ve been audited.
 Unsolved problems are closed when it does not merit investigation, is not in your sphere of influence or is being
addressed by some other group (ie. Problem stopped or went away on its own; the problem is too big or small to
address at this time; the problem sponsor or other management decide not to purse a solution)
 Decision to close should be made by the owner, the sponsor, and/or management

Questions to Ask:
 Is the Temporary fix removed?
 What went well or did not go well:
o Did the team work well together?
o Review the responsibilities of the team members & the team leader
o Review expectations of the Stakeholders
o Were procedures developed that could apply elsewhere?
o Did you find or solve additional problems?
o Were team members recognized for their accomplishments?
o How will you prevent recurrence of this and similar problems?
o Review what did not go well and action to correct these issues for next time
o Did you fix the problem (answer this question with supporting data)

Control Pitfalls: Permanent Solutions not implemented; Permanent solutions not approved
D8: Team congratulation
Recognize Team and Individual Contributions
 Problem solving is not an easy task!
 Problem solving is often an integrated part of continuous improvement,
structured waste elimination & lean transformation programs
 List the team or individual’s name and how they contributed in a positive way
 Recognizing problem closure & and a problem solving effort can build
momentum so that more problems get solved more quickly
Appendix