The document describes a systematic 6-step approach to problem solving: 1) define the problem, 2) analyze the problem, 3) generate possible solutions, 4) select the best solution, 5) plan implementation, and 6) evaluate the solution. Key aspects of analysis include identifying root causes, collecting data, and using techniques like flow diagrams, cause-and-effect diagrams, Pareto charts, and check sheets. Alternative solutions are generated through brainstorming and selecting the optimal solution considers factors like safety, cost, and quality. Planning implementation and evaluating outcomes are also important steps in the process.
Root Cause Analysis - Tools, Tips and Tricks to Get to the Bottom of Root CauseCraig Thornton
This webinar discusses and investigates how to conduct root cause analysis. Root cause analysis is something that companies really struggle with. There will be plenty of practical advice in the webinar to help with you understand the concepts and the tools.
If you would like to watch the recording of this webinar then copy and paste the below link into your web browser:
http://www.mangolive.com/blog-mango/root-cause-analysis-tools-webinar
Root Cause Analysis - Tools, Tips and Tricks to Get to the Bottom of Root CauseCraig Thornton
This webinar discusses and investigates how to conduct root cause analysis. Root cause analysis is something that companies really struggle with. There will be plenty of practical advice in the webinar to help with you understand the concepts and the tools.
If you would like to watch the recording of this webinar then copy and paste the below link into your web browser:
http://www.mangolive.com/blog-mango/root-cause-analysis-tools-webinar
I consider whether we as testers can be too closed-minded in our attitudes, whether there are schools of thought or approaches that, even if we care deeply about context, we are very unlikely even to consider and perhaps that we sometimes favour our reputation over giving ourselves the chance to do the best job that we can.
From CEWT#2, http://cewtblog.blogspot.co.uk/2016/02/cewt-2-abstracts.html
Surviving as a Software Tester, Even in Difficult Circumstancesrrice2000
Most test professionals have worked at some time or other in difficult organizations, dysfunctional cultures, and for unreasonable managers and stakeholders. This causes much internal stress and creates fear instead of creativity.
While some fortunate testers work in fantastic and supportive organizations, Rice’s research with many testers indicate most of the problems in testing are “people problems.”
In this presentation, Randy will describe the most common organizational issues that affect testers and will give some tips and strategies on how to survive through them. He will also discuss the difficult issue of knowing when to move on to a new organization, as well as how to map your own career growth.
Elisabeth Hendrickson’s book, Explore It!, contains this definition: “Tested = Checked + Explored”. When I read it, I was fascinated. “What does that mean?”, I asked myself, “what does it /really/ mean?”
This talk described the journey I undertook to understand it, and other definitions of testing that I found along the way, and then to come up with a new definition that filled the gaps I saw in the others, without losing the aspects of them that I felt were valid and useful.
Essentially, I formalised what testing is for me. And, now that I have my definition, I can ask myself in any given situation whether my actions are consistent with the way I believe I want to behave.
The Art of Questioning to improve Software Testing, Agile and AutomatingAlan Richardson
The presentation was delivered at the National Software Testing Conference on 17th May. It draws on lessons learned from various forms of fast, brief and systemic psychotherapy. With a few simple points:
* Why? is a question that targets beliefs
* How, What, Where, When, Who - all target structure and process
* We all have models of the world and our questions reflect that model
* Answers we give, reflect our model
* Responses to answers give information on how well the models of the question asker, and answering person, match up
* Testing can be modeled as a questioning process
* Improving our ability to ask questions improves our ability to test, manage, and change behaviour.
About Joseph Ours' Presentation – “Bad Metric – Bad!”
Metrics have always been used in corporate sectors, primarily as a way to gain insight into what is an otherwise invisible world. Organizations blindly adopt a set of metrics as a way of satisfying some process transparency requirement, rarely applying any statistical or scientific thought behind the measures and metrics they establish and interpret. Many metrics do not represent what people believe they do and as a result can lead to erroneous decisions. Joseph looks at some of the common and some of the humorous testing metrics and determines why they are failures. He further discusses the real purpose of metrics, metrics programs and finishes with pitfalls into which you fall.
Information Technology - Discover the Root Cause and Develop a solution throu...John Hudson
The presentation was compiled by Thinking Dimensions Global in November 2012 for the ITSMF conference held in London. The content relates to the KEPNERandFOURIE process for dealing with incidents and problems in IT and in particular a means of determining the Root Cause and providing the best solution.
The presentation was co-presented by Dr Mat-thys Fourie and John Hudson of Thinking Dimensions Global
Workshop on Root Cause Analysis tools: Ask Why five times and fishbone (Ishikawa) diagram. I use this to teach basic concepts and give people an experience of using the tools.
A Rapid Introduction to Rapid Software TestingTechWell
You're under tight time pressure and have barely enough information to proceed with testing. How do you test quickly and inexpensively, yet still produce informative, credible, and accountable results? Rapid Software Testing, adopted by context-driven testers worldwide, offers a field-proven answer to this all-too-common dilemma. In this one-day sampler of the approach, Paul Holland introduces you to the skills and practice of Rapid Software Testing through stories, discussions, and "minds-on" exercises that simulate important aspects of real testing problems. The rapid approach isn't just testing with speed or a sense of urgency; it's mission-focused testing that eliminates unnecessary work, assures that the most important things get done, and constantly asks how testers can help speed up the successful completion of the project. Join Paul to learn how rapid testing focuses on both the mind set and skill set of the individual tester who uses tight loops of exploration and critical thinking skills to help continuously re-optimize testing to match clients' needs and expectations.
Presented at https://www.onlinetestconf.com/program-spring-otc-2020/
Sometimes you’re asked to start testing in a context that is not ideal: you’ve only just joined the project, the test environment is broken, the product is migrating to a new stack, the developer has left, no-one seems quite sure what’s being done or why, and there is not much time.
Knowing where to begin and what to focus on can be difficult and so in this talk I’ll describe how I try to meet that challenge.
I’ll share a definition of testing which helps me to navigate uncertainty across contexts and decide on a starting point. I’ll catalogue tools that I use regularly such as conversation, modelling, and drawing; the rule of three, heuristics, and background knowledge; mission-setting, hypothesis generation, and comparison. I’ll show how they’ve helped me in my testing, and how I iterate over different approaches regularly to focus my testing.
The takeaways from this talk will be a distillation of hard-won, hands-on experience that has given me
* an expansive, iterative view of testing
* a comprehensive catalogue of testing tools
* the confidence to start testing anything from anywhere
I consider whether we as testers can be too closed-minded in our attitudes, whether there are schools of thought or approaches that, even if we care deeply about context, we are very unlikely even to consider and perhaps that we sometimes favour our reputation over giving ourselves the chance to do the best job that we can.
From CEWT#2, http://cewtblog.blogspot.co.uk/2016/02/cewt-2-abstracts.html
Surviving as a Software Tester, Even in Difficult Circumstancesrrice2000
Most test professionals have worked at some time or other in difficult organizations, dysfunctional cultures, and for unreasonable managers and stakeholders. This causes much internal stress and creates fear instead of creativity.
While some fortunate testers work in fantastic and supportive organizations, Rice’s research with many testers indicate most of the problems in testing are “people problems.”
In this presentation, Randy will describe the most common organizational issues that affect testers and will give some tips and strategies on how to survive through them. He will also discuss the difficult issue of knowing when to move on to a new organization, as well as how to map your own career growth.
Elisabeth Hendrickson’s book, Explore It!, contains this definition: “Tested = Checked + Explored”. When I read it, I was fascinated. “What does that mean?”, I asked myself, “what does it /really/ mean?”
This talk described the journey I undertook to understand it, and other definitions of testing that I found along the way, and then to come up with a new definition that filled the gaps I saw in the others, without losing the aspects of them that I felt were valid and useful.
Essentially, I formalised what testing is for me. And, now that I have my definition, I can ask myself in any given situation whether my actions are consistent with the way I believe I want to behave.
The Art of Questioning to improve Software Testing, Agile and AutomatingAlan Richardson
The presentation was delivered at the National Software Testing Conference on 17th May. It draws on lessons learned from various forms of fast, brief and systemic psychotherapy. With a few simple points:
* Why? is a question that targets beliefs
* How, What, Where, When, Who - all target structure and process
* We all have models of the world and our questions reflect that model
* Answers we give, reflect our model
* Responses to answers give information on how well the models of the question asker, and answering person, match up
* Testing can be modeled as a questioning process
* Improving our ability to ask questions improves our ability to test, manage, and change behaviour.
About Joseph Ours' Presentation – “Bad Metric – Bad!”
Metrics have always been used in corporate sectors, primarily as a way to gain insight into what is an otherwise invisible world. Organizations blindly adopt a set of metrics as a way of satisfying some process transparency requirement, rarely applying any statistical or scientific thought behind the measures and metrics they establish and interpret. Many metrics do not represent what people believe they do and as a result can lead to erroneous decisions. Joseph looks at some of the common and some of the humorous testing metrics and determines why they are failures. He further discusses the real purpose of metrics, metrics programs and finishes with pitfalls into which you fall.
Information Technology - Discover the Root Cause and Develop a solution throu...John Hudson
The presentation was compiled by Thinking Dimensions Global in November 2012 for the ITSMF conference held in London. The content relates to the KEPNERandFOURIE process for dealing with incidents and problems in IT and in particular a means of determining the Root Cause and providing the best solution.
The presentation was co-presented by Dr Mat-thys Fourie and John Hudson of Thinking Dimensions Global
Workshop on Root Cause Analysis tools: Ask Why five times and fishbone (Ishikawa) diagram. I use this to teach basic concepts and give people an experience of using the tools.
A Rapid Introduction to Rapid Software TestingTechWell
You're under tight time pressure and have barely enough information to proceed with testing. How do you test quickly and inexpensively, yet still produce informative, credible, and accountable results? Rapid Software Testing, adopted by context-driven testers worldwide, offers a field-proven answer to this all-too-common dilemma. In this one-day sampler of the approach, Paul Holland introduces you to the skills and practice of Rapid Software Testing through stories, discussions, and "minds-on" exercises that simulate important aspects of real testing problems. The rapid approach isn't just testing with speed or a sense of urgency; it's mission-focused testing that eliminates unnecessary work, assures that the most important things get done, and constantly asks how testers can help speed up the successful completion of the project. Join Paul to learn how rapid testing focuses on both the mind set and skill set of the individual tester who uses tight loops of exploration and critical thinking skills to help continuously re-optimize testing to match clients' needs and expectations.
Presented at https://www.onlinetestconf.com/program-spring-otc-2020/
Sometimes you’re asked to start testing in a context that is not ideal: you’ve only just joined the project, the test environment is broken, the product is migrating to a new stack, the developer has left, no-one seems quite sure what’s being done or why, and there is not much time.
Knowing where to begin and what to focus on can be difficult and so in this talk I’ll describe how I try to meet that challenge.
I’ll share a definition of testing which helps me to navigate uncertainty across contexts and decide on a starting point. I’ll catalogue tools that I use regularly such as conversation, modelling, and drawing; the rule of three, heuristics, and background knowledge; mission-setting, hypothesis generation, and comparison. I’ll show how they’ve helped me in my testing, and how I iterate over different approaches regularly to focus my testing.
The takeaways from this talk will be a distillation of hard-won, hands-on experience that has given me
* an expansive, iterative view of testing
* a comprehensive catalogue of testing tools
* the confidence to start testing anything from anywhere
La misión de NHT Global es mejorar la manera en que usted se siente acerca de sí mismo y acerca del trabajo. Al ofrecer Productos Eficaces y de calidad de vida a nuestros clientes, y posiblemente el plan de compensación más lucrativo que hayan tenido nuestros miembros, estamos comprometidos con el bienestar de las personas en todo el mundo.
Cause and Effect Analysis is a technique for identifying all the possible causes (inputs) associated with a particular problem / effect (output) before narrowing down to the small number of main, root causes which need to be addressed.
تتحدث هذه المحاضرة عن تحليل أسباب جذور المشكلة أو
Root Cause Analysis (RCA)
وهي أداة يتم استخدامها بغرض معرفة جذر أو جذور أسباب مشكلة ما ومن ثم وضع الحل المناسب لعدم تكرار حدوث المشكلة
قمت في هذه المحاضرة بتعريف تحليل أسباب جذور المشكلة او ال
Root Cause Analysis (RCA)
والمبادئ التي يقوم عليها وأنه يركز على تقديم حلول جذرية تمنع عودة المشكلة مرة أخرى بدلا عن التركيز على وضع حلول وقتية لأعراض المشاكل
قمت بعد ذلك بتوضيح خطوات تحليل أسباب جذور المشكلة او ال
Root Cause Analysis (RCA)
متطرقا لعدة أدوات تستخدم في تحليل أسباب جذور المشكلة او ال
Root Cause Analysis (RCA).
Problem Solving Tools and Techniques by TQMIAndrew Leong
This handy guide is for anyone involved in problem solving and improvement activities. It contains guidelines on the use of many of the tools and techniques which can be used as part of a Continuous Improvement process.
This handy guide is for anyone involved in problem solving and improvement activities. It contains guidelines on the use of many of the tools and techniques which can be used as part of a Continuous Improvement process.
This presentation, created by Syed Faiz ul Hassan, explores the profound influence of media on public perception and behavior. It delves into the evolution of media from oral traditions to modern digital and social media platforms. Key topics include the role of media in information propagation, socialization, crisis awareness, globalization, and education. The presentation also examines media influence through agenda setting, propaganda, and manipulative techniques used by advertisers and marketers. Furthermore, it highlights the impact of surveillance enabled by media technologies on personal behavior and preferences. Through this comprehensive overview, the presentation aims to shed light on how media shapes collective consciousness and public opinion.
0x01 - Newton's Third Law: Static vs. Dynamic AbusersOWASP Beja
f you offer a service on the web, odds are that someone will abuse it. Be it an API, a SaaS, a PaaS, or even a static website, someone somewhere will try to figure out a way to use it to their own needs. In this talk we'll compare measures that are effective against static attackers and how to battle a dynamic attacker who adapts to your counter-measures.
About the Speaker
===============
Diogo Sousa, Engineering Manager @ Canonical
An opinionated individual with an interest in cryptography and its intersection with secure software development.
Sharpen existing tools or get a new toolbox? Contemporary cluster initiatives...Orkestra
UIIN Conference, Madrid, 27-29 May 2024
James Wilson, Orkestra and Deusto Business School
Emily Wise, Lund University
Madeline Smith, The Glasgow School of Art
Acorn Recovery: Restore IT infra within minutesIP ServerOne
Introducing Acorn Recovery as a Service, a simple, fast, and secure managed disaster recovery (DRaaS) by IP ServerOne. A DR solution that helps restore your IT infra within minutes.
Have you ever wondered how search works while visiting an e-commerce site, internal website, or searching through other types of online resources? Look no further than this informative session on the ways that taxonomies help end-users navigate the internet! Hear from taxonomists and other information professionals who have first-hand experience creating and working with taxonomies that aid in navigation, search, and discovery across a range of disciplines.
This presentation by Morris Kleiner (University of Minnesota), was made during the discussion “Competition and Regulation in Professions and Occupations” held at the Working Party No. 2 on Competition and Regulation on 10 June 2024. More papers and presentations on the topic can be found out at oe.cd/crps.
This presentation was uploaded with the author’s consent.
2. A. Problem Solving StepsA. Problem Solving Steps
Systematic Approach
Six Steps
• Define The Problem
• Analyze The Problem
• Generate Possible Solutions
• Select The Best Solution
• Plan For Implementation
• Implement And Evaluate The Solution
3. A. Problem Solving StepsA. Problem Solving Steps
1. Step One : Define The Problem
• Identify the problem
• Develop an accurate problem statement:
Too general or misleading:
- - Too broad. . . “Reduce the quality problems in our area”.
- - Implies a cause or suggests a solution . . . “There are not
enough
forklifts to service the assembly line”.
Accurate and Appropriate:
“Reduce the downtime of the assembly line due to
parts problems caused by inadequate restocking”.
4. A. Problem Solving StepsA. Problem Solving Steps
2. Step Two : Analyze The Problem
• Don’t rush to a wrong solution.
• Highly critical step.
• Common mistake to immediately
begin generating solutions.
• Must identify and eliminate root
causes of problem.
5. A. Problem Solving StepsA. Problem Solving Steps
2. Step Two : Analyze The Problem
Examples: Symptoms and Root Causes
Example 1
Symptom: The chicken on the grill is still frozen solid.
Brute Force/Quick Fix: Apply a blow torch to the chicken.
Root Cause: No allowance for time to defrost the chicken.
Real Solution: Plan ahead. Allow defrost time or but fresh chicken.
Example 2
Symptom: High error rate from Word Processing Center.
Brute Force/Quick Fix: Add proofreaders. Hire high-level operator.
Root Cause: Handwritten input drafts illegible.
Real Solution: Do not accept illegible drafts. Encourage use of dictating
equipment.
6. A. Problem Solving StepsA. Problem Solving Steps
2. Step Two : Analyze The Problem
Examples: Symptoms and Root Causes
Example 3
Symptom: Pile-up of rework.
Brute Force/Quick Fix: Add more rework operators.
Root Cause: Incorrect assembly operators.
Real Solution: Train assembly workers.
Example 4
Symptom: High reject rate from plating area.
Brute Force/Quick Fix: Add 100% inspection.
Root Cause: Parts damaged in stockroom.
Real Solution: Change handling methods in stockroom.
7. A. Problem Solving StepsA. Problem Solving Steps
2. Step Two : Analyze The Problem
Getting to the Root Cause of the Problem
Five “Whys” equal one “How-To” (5W=1H)
• Why did the machine stop?
An overload caused the fuse to blow.
• Why did the overload occur?
The bearing was not sufficiently lubricated.
• Why was it not lubricated sufficiently?
The lubrication pump was not pumping sufficiently.
• Why was it not pumping?
The shaft of the pump was worn and rattling.
• Why was the shaft worn?
Metal scraps got to the pump because no strainer was attached.
This helps uncover the root problem and correct it.
8. A. Problem Solving StepsA. Problem Solving Steps
2. Step Two : Analyze The Problem
Preventing Problem Recurrence
• One of four bolts keeps breaking.
The bolt is replaced with a larger bolt.
• A second bolt starts breaking.
All four bolts replaced with larger bolts..
• Iron plate holding the bolts breaks in two.
Plate replaced with thicker plate.
Is recurrence prevented? NO!
• Further study revealed vibration caused the problem.
Vibration was eliminated.
Is the cause prevented? NO!
• Why was the vibration not detected?
Reevaluate test procedures to prevent recurrence.
9. A. Problem Solving StepsA. Problem Solving Steps
2. Step Two : Analyze The Problem
Diagnostic Tools (Described later in Techniques section)
• Brainstorming
• Flow Diagrams
• Cause and Effect Diagrams
• Pareto Charts
• Check Sheets
10. A. Problem Solving StepsA. Problem Solving Steps
2. Step Two : Analyze The Problem
Data Collection
1. Identify what information to collect.
• When a cause/effect is occurring.
• How frequently it is occurring.
• Where it is occurring.
• What is the magnitude of the occurrence?
Ask yourself, “Once I collect this data, what am IAsk yourself, “Once I collect this data, what am I
going to do with the information?going to do with the information?
Steps to Data Collection:
11. A. Problem Solving StepsA. Problem Solving Steps
2. Step Two : Analyze The Problem
2. Decide how to collect the information.
• Interviews and questionnaires (Technical Specialists,
Supervisors and Managers, other Employees)
• Look at records (Past/ recent information, quality,
productivity, safety, inventory, maintenance records).
• Direct observation (Make your own records, use those involved in
the problem).
Steps to Data Collection:
12. A. Problem Solving StepsA. Problem Solving Steps
2. Step Two : Analyze The Problem
3. Decide when to collect the information.
• Decide what is a reasonable time.
• Consider when you are most likely to get the
information.
Steps to Data Collection:
13. A. Problem Solving StepsA. Problem Solving Steps
2. Step Two : Analyze The Problem
4. Design which tools you will use to collect the
information.
• Interviews or questionnaires
• Decide from whom you need information.
• Determine what questions to ask.
• Use checklists to collect two kinds of information
at the same time.
• Think of combinations that show when and where
the cause is happening.
- - Number of times and places occurring
- - Length of time and type of thing
- - Cost and type
- - Machine and/or type of system
Steps to Data Collection:
5. Collect the data.
14. A. Problem Solving StepsA. Problem Solving Steps
3. Step Three : Generate Alternative Solutions
• Use all idea sources available.
- - The worker involved.
- - In-house experts.
- - Written material
- - Outside experts
How to Develop Alternatives:
• Look at the data. What does it tell you?
- - Data will lead to some ideas
- - Data may not lead to best idea
• Question each aspect of situation.
- - What is the job to be done?
- - Why is the job to be done?
- - Who should do the job?
- - Where should the job be done?
- - When should the job be done?
- - How should the job be done?
15. A. Problem Solving StepsA. Problem Solving Steps
3. Step Three : Generate Alternative Solutions
• Brainstorm for alternative solutions.
How to Develop Alternatives: (con’t)
• Apply some appropriate action
- - Eliminate (part, reason, job, activity)
- - Combine (parts, forms, jobs, functions)
- - Rearrange (sequence, location)
- - Simplify (foolproof, make obvious, provide
interlocks, remove steps, reduce physical effort)
• Apply creativity to the situation.
- - Making new ways
- - Rearranging old ways
- - Form novel and useful ideas
16. A. Problem Solving StepsA. Problem Solving Steps
3. Step Three : Generate Alternative Solutions
• Pursue new ideas.
- - Thoroughly discuss ideas before moving on
- - Request input and participation from others
- - Remove obstacles
Personal Skills for Working Together:
• Keep an open mind
- - Avoid prejudging ideas
- - Avoid statements like:
... “That won’t work here”.
... “We already tried that”.
... “That will cost too much”.
- - If other team members criticize:
... Ask for suggestions and ideas
... Ask for data
17. A. Problem Solving StepsA. Problem Solving Steps
3. Step Three : Generate Alternative Solutions
• Ask “good” questions.
- - Ask often for new ideas
- - Clarify – “What do you mean when you say...?”
- - Use “open” questions. Avoid “Yes” or “no” answers
- - Ask “What..., How..., Why...”?
Personal Skills for Working Together:
• Treat ideas equally.
- - Follow brainstorming rules
- - Better alternatives may emerge
- - At first, consider all alternatives
- - Look for most interesting aspect
- - Good ideas come from unexpected sources
- - Say ”What I like most about this idea is...”
18. A. Problem Solving StepsA. Problem Solving Steps
3. Step Three : Generate Alternative Solutions
• Listen with interest and respect
- - Restate ideas to show interest and understanding
- - Don’t interrupt
- - Use positive body language... Nod, smile, eye contact
- - Insist on truthful details... Ask
HOW DO YOU KNOW?
Personal Skills for Working Together:
19. A. Problem Solving StepsA. Problem Solving Steps
4. Step Four : Select A Solution
• Refer back to original problem statement. Consider:
- - Safety
- - Cost
- - Product performance
- - Better management information
- - Improved Technology
- - Time
- - Quality
- - Appearance
20. A. Problem Solving StepsA. Problem Solving Steps
4. Step Four : Select A Solution
• Some questions to ask:
- - Will this completely resolve the problem?
- - Will this only satisfy part of the problem?
- - Will this prevent future occurrences?
- - Will this have little or no impact on the problem?
- - Do we have the authority to implement?
- - Do we have the necessary resources?
- - How long will it take to implement?
21. A. Problem Solving StepsA. Problem Solving Steps
5. Step Five : Plan and Implement Solution
• Steps to ensure successful implementation:
- - Work the most powerful forces
- - Prepare an action plan:
... What will be done?
... How will it be done?
... Where will it be done?
... Who will do it?
... When will it be done?
- - Develop a tracking system:
... Identify milestones or events
... Assign completion dates
... Identify reporting systems
- - Design evaluation procedures
- - Implement the procedures
22. A. Problem Solving StepsA. Problem Solving Steps
6. Step Six : Evaluate The Solution
• Measure results using procedures established
during implementation
• Use data gathering:
- - check sheets
- - control charts
- - time studies
- - Pareto analysis
23. B. Problem Solving TechniquesB. Problem Solving Techniques
1. Flow Diagrams
• What is a “Flow Diagram”?
- - A graphic representation of a process: May be...
- a physical product
- a service
- information
- or combination of the three.
• A Flow Diagram examines the logic or lack
of logic in a sequence of steps.
• A Flow Diagram gives team members a better
understanding of the process.
24. B. Problem Solving TechniquesB. Problem Solving Techniques
1. Flow Diagrams
• Symbols Used in Flow Diagramming:
Terminal Symbol – Identifies “Start” or “End” of process.
Activity Symbol – Indicates a single step in the process.
Holding Step Symbol – Places in process where activity is
temporarily halted.
Decision Symbol – Indicates a decision or branch in process –
Usually contain a Yes/No question.
Connector Symbol – Indicates a continuation of the flow–
Usually contain a letter or number.
Flow Line Symbol – Indicates direction of flow of the process.
25. B. Problem Solving TechniquesB. Problem Solving Techniques
1. Flow Diagrams
• When to Use Flow Diagrams
- - Defining Projects
- - Identifying Root Causes
- - Designing Solutions
- - Implementing Solutions
- - Holding the gains (improvements)
26. B. Problem Solving TechniquesB. Problem Solving Techniques
1. Flow Diagrams
• Summary: How to Construct Flow Diagrams
- - Describe process as it really is.
- - Conduct group discussion and information exchange.
- - Consider intended use.
- - Be flexible
- - Decide on desired outcomes.
- - Define boundaries of process.
- - Document each step in process.
27. B. Problem Solving TechniquesB. Problem Solving Techniques
1. Flow Diagrams
• Summary: How to Construct Flow Diagrams (con’t)
- - Use appropriate symbols.
- - Draw process accurately (top to bottom or left to right)
- - Choose a branch and continue diagramming.
- - Repeat steps until entire process is diagrammed.
- - Review complete chart.
- - Discuss unfamiliar steps.
- - When diagram is complete – analyze it.
28. B. Problem Solving TechniquesB. Problem Solving Techniques
1. Flow Diagram – Scrambled Eggs
29. B. Problem Solving TechniquesB. Problem Solving Techniques
1. Flow Diagram – Team Formation/Operation
30. C. BrainstormingC. Brainstorming
1. Voting and Ranking Techniques
Brainstorming and Cause/Effect analysis generate a large
number of problem, ideas and alternatives.
Techniques are needed to rank them in order of priority.
2. 5-3-1 Ranking Method
• Each item assigned a value of 5, 3, 1, or 0 by each
team member.
• Sum of values assigned by team members
represents team ranking of that item.
31. C. BrainstormingC. Brainstorming
3. 10 - 4 Ranking Method
Helpful in eliminating items to reduce list.
Reduced list can be prioritized using 5-3-1 method.
• Each member allotted 10 points to assign in first round.
• All ten may be assigned to one item if desired.
• Members can assign only 4 points per item in following
rounds.
32. C. BrainstormingC. Brainstorming
4. Multi-voting
Another way to reduce long list.
• Members write down several items to address.
• Tally votes from all members.
• Eliminate items with fewest votes.
• Repeat rounds until desired number reached.
33. D. Cause and Effect DiagramsD. Cause and Effect Diagrams
Fishbone Diagram
Wood Blocks
34. Simple method to identify vital elements among many
trivial elements.
Follow four steps:
• Identify feature or attribute
(rejects, accidents, scrap, etc.)
• List categories that
contribute to the feature.
• Tabulate frequency of each
category. (List in descending
order)
• Construct chart with
frequencies plotted in
descending order.
E. Pareto Charts
36. 1. Defect Location Check Sheets:
Indicate on sketch or picture
where defects are concentrated.
Concentration of certain defects
can help identify process errors.
E. Pareto Charts
Rubber Glove Defects
37. “Lost at Sea”
Problem Solving Exercise
Work together as a team.
Use the ranking methods discussed.
Discuss your choices among the team.
Do not look at the Answer/Rationale sheet.
