Incoming and Outgoing Shipments in 1 STEP Using Odoo 17
Using a Fishbone Diagram: Part 2 - Identify Root Causes of Problems
1. Using a Fishbone Diagram: Part 2 PROG 1026: Logic & Problem Solving
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
Hinweis der Redaktion
Welcome Back – hope you are ready for another interesting session tonight.
Here’s what I hoped we could cover tonight… I’ll be checking with ConEd to see if I can have the certificates available for undeclared students on Wednesday, but may have to be sent out to you.
Last week we looked at Cause and Effect analysis and you may recall that this was seen to be an important opportunity to help you consider problem-solving that may be applied in numerous areas – and in particular to the areas of process engineering, re-engineering and continuos quality improvement or CQI. This workshop is intended to help you understand how to perform C&E for good team efforts for process improvement, but its scope is really limited to getting you familiar with one of the tools – the fishbone diagram. If you are interested there are a number of paths for further training including the CAMC, IIBA, PMI and other associations who articulate professional credentials. We discussed C&E and its tools as being useful in team environments where problems are complex and root causes are unknown and where the team needs to focus on problems and not on people or symptoms. It will help to develop innovative problem solving within functional and especially cross-functional teams.
We looked very briefly at a tool that we will be working with more tonight – the fishbone (or ishakawa) diagram and had a chance to practice two of the necessary skills to completing a fishbone – brainstorming and the five-why’s.
Please note that we will be using a smaller set of cause classes in our exercises – using the 4P’s or 4M’s. 4 P’s: Process, People, Plant/Equipment, Policies 4 M’s Manpower, Methods, Machinery, Materials We’ll also look at a different approach and in fact we’ll use a different classification scheme altogether tonight in the case study – even though the basic process will stay the same.
Briefly – and I believe this is in your guide on page 6 – the process always starts off with a definition of the problem. This may seem pretty straightforward, but it sometimes gets complicated – especially if all the tem doesn’t agree it is the problem! Based on your team situation, the nature of your business and the nature of the problem you next need to make a determination of the best way to categorize the causes. We will look at a couple of these methods shortly. Next you brainstorm all the possible causes you can identify, and assign them to the cause categories. These should then be questions for deeper causes until the desired level of detail is achieved, after which the team is ready to analyse the causes to find root causes or bottlenecks that can be addressed. Finally action is planned to address the problem by fixing the root causes. Keep in mind that the actual implementation of those improvements don’t fall inside of this process, but they do in the overall scheme of CQI. So now we are ready to try some application.
You were asked to read the case study and to begin highlighting some of the issues with an eye to two key questions – what is the central or net problem? And what are some of the causes you can see of this problem? Take a moment to review the case and your notes and we’ll begin the case study shortly…
OK – ready? So here’s what we will do. Teams are… The process will look like this: facilitator – I’d like to have a different facilitator for each of the next three major steps 5 minutes to generate and agree on a problem statement
Don’t overwork this – but try to get it down to a few words that concisely says – here’s the problem, something that si happening or not happening that causes us a problem being successful at what we are trying to do. Five minutes – then we’ll share our problem statements
OK I’d like another member of the team to try to facilitate this next step – brainstorming is an important skills and the ground rules are important – don’t judge suggestions, just get as much down as you can. Facilitators should try to ensure everyone has a chance to participate – many people are reflective or deep thinkers or may be introspective, but they very often have some of the best contributions… Let’s try to get at least 8-10 ideas about problems that lead directly to the problem statement you came up with – remember it should be a direct cause to the problem at this level. If it doesn’t, then hold that thought and instead try to come up with what it affects that leads to the problem.
Major Cause Categories There are two major methods we will discuss tonight, but your team may be able to come up with a better set of cause categories. 4Ps are effective for service type businesses or problems, while 4Ms is better in manufacturing, industrial and construction type situations.
One way that may work even better for many teams – especially if they are all close to the process is to use process classification: This will be unique for every process of course so the design here is just an example of a process classification – in this case for problem involving late pizza deliveries. You can see how the various major process categories are broken out. In the case, it ends with the major categories having been specified by Bob, the manager and that’s where you will begin your work of assigning causes to the major process areas.
In dispersion analysis you might see the same item across numerous categories – less so for process classification. Go Ahead and do your assignment now