search.noResults

search.searching

dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
JUST PLANE CULTURE


PROBLEM SOLVING (PART 2) – ANALYSIS BY PATRICK KINANE


In part one, I delved into identifying the problem and the difference between a problem and symptom. Here we will look into the analysis portion. There are several analyses involved in the problem-solving taxonomy. We analyze the problem, we analyze the potential solutions, we analyze the implementation of the solutions, we analyze if the implemented solutions met or exceeded our original plan, we analyze when improvements are noticed and no solution has been applied, and we analyze what we can do better (including the problem- solving approach itself). Problem solving involves a lot of analysis but here we are only going to look at analyzing the problem. We know we have a problem, so


why do we need to analyze it? The first reason is to determine how deep you need to go into problem solving. Every problem needs root-cause analysis, but you don’t want to do a full-blown problem-solving process for every problem event. If someone spills a cup of coffee, you don’t make an organizational announcement of “cleanup, aisle five,” call out the hazmat crew, quarantine the area and foam the runway. That’s overly reactive. Conversely, if someone spills acid on their person, you don’t just tell them, “go get cleaned up” and leave it at that. That’s underly reactive. I am sure you can recognize when you need a deeper root-cause analysis and when a cursory root cause would suffice in those scenarios, but there is a lot of gray inbetween.


WHAT DO WE DO? Can you leave it up to management to determine how extensively


48 DOMmagazine.com | mar 2018


to investigate? Definitely maybe. Problem solving and the accompanying root-cause analysis requires valuable resources, so you want to be conservative (but not to the extent of jeopardizing an equally- valuable improvement activity). Improvement is the primary reason for going through this process. It’s not to find the bad guy and it’s not to check a box and move on — it’s to actually change things for the better. The goal is to make your work environment safer, more efficient and more effective. You are more cost effective when you are safer, and you are more productive when you are more effective and efficient. The benefit is that the employees are more satisfied in their jobs and the customer is more satisfied in the product or service provided. Employees are more engaged when they are more satisfied in their jobs. When they are more engaged, they are more apt to contribute to improvement which leads back into the continuous improvement cycle.


THE RISK MATRIX There has to be some mechanism to give management leeway to direct them when a thorough root-cause analysis is mandatory, optional but advisable, optional but discretionary, or not obligatory. One method that I have found useful is the risk matrix. For the reasons stated above, a problem can be a safety issue, quality issue, production issue, etc. What is your organization’s pain tolerance? Is a technician jamming his or her finger on a machine acceptable? What about if the technician jams two fingers? How about two technicians jamming their fingers? How about


two in one month? What about two in one day? What if it’s the same technician, same machine, or same shift? What if it’s different technicians, different machines, or different shifts? In order to construct a risk matrix,


your organization will have to establish criteria for determining what level of response should be taken. You cannot possibly determine all the different situations that might occur in an organization, so there has to be some universally-generic description. Every organization’s concern or reason for being in business is to be productive and to generate a profit. It impacts the organization when an incident affects the production/ service process. The extent of that impact should be your guiding light in determining depth of analysis. Are we more concerned over a technician who has jammed his or her finger or cut it off on a piece of machinery? Obviously, the finger loss. Are we more concerned when one or two technicians jammed their fingers in a piece of machinery? Two technicians. Are we more concerned if the technicians jammed their finger in the past five years or past five hours? The past five hours, of course. Are we more concerned if five technicians jammed their fingers on one piece of machinery or five different pieces of machinery? The organizational impact is the five technicians jamming their fingers, so we are equally concerned with both scenarios. The information on one piece of machinery or five different machines is incidental to assist you in your path towards a solution. We have identified three criteria: the severity of the occurrence, the frequency of occurrences and the duration of occurrences.


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58  |  Page 59  |  Page 60  |  Page 61  |  Page 62  |  Page 63  |  Page 64  |  Page 65  |  Page 66  |  Page 67  |  Page 68