Below is a full transcript of our recent Root Cause Analysis webinar that offers an overview of ISO Root Cause Analysis and its benefits.
Webinar Topics
- The hidden factors in typical ‘cost of quality’ calculations
- How we miss the massive impact on profit of a non-conformance
- Why ‘operator error’ indicates a weak Root Cause Analysis
- Corrective Actions and why they can be ineffective
- How to make Root Cause Analysis pay dividends – case studies
Full Webinar Transcript
Jim Moran:
So let's see what we can do here today, and hopefully you're all here for the same reason, the root cause analysis chat today on different ways, why it's so important to gross root cause, we'll make some financial business case for why root cause is so...
Jim Moran:
And it's hopefully give us some of your experiences, some things that you've come across, and definitely would love to keep you. Make sure that you have some reason to be here, and by all means, stick your hand up any time you can, any time you like if we haven't answered your question. And we have some polls, and I'll also stop in between the polls, maybe every seven or eight minutes or so, just to double check the panel to see if there are any chats, any comments you've put in that I need to address. And just for those of you who've just joined us recently, normally you'd be hearing Rick Herman talking right now, but Rick's on his way home from Cincinnati, his daughter got married over the weekend and we weren't able to organize a link up for him.
Jim Moran:
So I'm on my own, but I've got lots of friends here, so that's even better. Thanks very much. So, some of you are familiar with the Ishikawa fish bone diagram, and it's been around since 1964, I think was the official launching, but it's actually an extension of the five why's that were put out by another famous systems person of the time, at the end of the 1800s. And Ishikawa had this really well tested, well observed, it's been around for years. It's the simplest tool that I've ever seen that's the most effective, and it's not perfect, but it helps you get the focus off the operator, onto things like you can see up here, working conditions, raw materials, management. There's a scary one, looking in the mirror.
Jim Moran:
Technology, machine, workers, even measurements. Sometimes the actual act of measuring can make either something look off spec that isn't, or the measurements are done in such a way that you don't realize that it's off spec, you don't find out that it's off spec. So all kinds of things that can contribute. So we'll be talking about how root cause can impact your organization, and the importance of it. It takes time, and it's important to take the time to do a good root cause for a number of reasons we'll talk about.
Jim Moran:
The other reason root cause is so important is because some of you might be doing cost of quality calculations so you can justify the time. But there are a lot of things that get missed often in a typical cost of quality calculation. One of them is fielding the phone call. We've got documentation, we've got a back and forth with the customer. This all takes time. Initial investigation, root cause analysis, revisions to the documentation, revisions to processes, revisions to any measurements you're taking. If you have to redo the process, you might have to do a new inspection test plan. Testing can change purchasing, because of something you found you might have to find a new source of something. Design could change because of the problem, repackaging.
Jim Moran:
Then you've got your first attempt at corrective action, your next attempt, next attempt, then, starting the retesting all over again. And then finding repackaging, and then maybe shipping. And depending on whether you're responsible for shipping or not, all these things add up to costs, again, and again, and again. A number of organizations miss all these various areas, I did this in a blog post a couple weeks ago. It's important to remember one other really big thing, is that when people are fixing a problem, you're not creating revenue for the organization.
Jim Moran:
I'm going to show you some pretty interesting, I think interesting anyway, financial facts about how much it costs to replace revenue for a mistake as well. We can miss the massive impact on revenue and performance. If your organization is operating at a 2% net profit, and you have a $1000 error, you have to do $50000 in revenue to get back that $1000. If some of you are having a hard time convincing top management to give you the resources you need to do good root cause analysis so that the corrective action prevents recurrence of issues, show them this.
Jim Moran:
And this isn't a theory, this is an actual, mathematical fact. You put your own percentage of net profit in here, even if you're at 4% net profit, you still have to do $25000 to get back a $1000 error. And this is critical. And the reason why operator error, if you look back to your last 10, 15, 20, 30 non-conforming statements, if your conclusion is that it was operator error, it indicates that you've done a weak root cause analysis because operator error happens, yes, but it's about 6% of the time. So, 94% of the time, there is another cause. It could be in the Ishikawa world, it could be the methods that were used, the processes that were used.
Jim Moran:
It could be the materials the person had to use, it could be the equipment, it could be the work environment. It could be a very distracting environment in a place where the work has to be extremely accurate. So it's quite critical that you explore all the options. The other thing, too, that I can't emphasize enough... just for example, I was just doing some training with an organization a couple of weeks ago. We were doing an internal auditor training course, we did three three hour sessions. And they were telling me about a welder, an experienced welder.
Jim Moran:
15 years, always great work. But for some reason, one or two times out of 20 or 25, he wouldn't get enough weld into the joint. So they called it operator error. And the thing that we have to understand here, is that yes, the welder didn't get enough laid down on the weld, but why not? Was it the drawing, was the drawing not clear? Also, the weld was inspected. How did the inspector miss it? We're in a situation where it was the kind of weld where a third party would come in after the work was done and inspect it, there would be a number of rejections.
Jim Moran:
Similar situation, a construction company does quotes. One of the person preparing a quote left a whole section out of the proposal, and then when it got submitted, obviously it got rejected because the section was missing. And you say, operator error. Well, here's something interesting about that specific situation. Two other executives in the company reviewed the submission before it went in. And of course that's typical, if you have a whole bunch of reviews, people are either thinking, I'm sure it's okay, I'll just put my stamp on it, or it must be okay because so and so approved it.
Jim Moran:
So those are the kind of things where you have to make sure that your inspections and your approval system isn't just becoming a whole rubber stamp. What's that have to do with root cause? Well, when you're looking for reasons why people aren't engaged, sometimes stuff has become automatic and doesn't mean anything anymore. So yes, operator error occurs. It is 6% of the time. But even when it is operator error, there's nothing wrong with looking back, looking a little deeper into what the issues. I'm just going to have a quick look in the chat box and see if there's anything there. Nothing there yet.
Jim Moran:
If you put a question or comment into the chat box and you haven't heard from me, try raising your hand, I'll see what that looks like when it happens. Corrective actions can be ineffective if we don't follow up. That's one reason, if we fix the wrong problem, if we rush the root cause analysis process to get it done quickly, or... I wouldn't say worst of all, but sometimes it happens, the top management only pays lip service to the whole management system section. So, by all means, when your top management isn't on with you, or hasn't joined up with you, or isn't supporting you for whatever reason, maybe if you show him or her some of the data in here, some of the mathematical facts about how much con-conformances cost, and in fact we can even do a complementary lunch and learn [inaudible 00:11:03] if you think it would help.
Jim Moran:
But I see it every year. I used to see it a bit more when I was doing a lot of auditing for Quasar, now the CWB group. And it's been an issue with ISO since 1987. Started working with it in 1992, first system was in CIRNA. It isn't unusual to see top management sometimes, just to be crass, just saying we only need ISO for the certificates so we can get on dead lists. And it's a magnificent standard to use to run any organization, even government. Trevor Shaw with us today has spent a lot of his time in federal government, Ottawa. Others of you know people who are in the government.
Jim Moran:
And it can even be used in a service organization, even a not for profit or a public service organization, to improve processes, to help people stay within their budgets, and of course everybody's trying to stay within their budgets in any situation, that's for sure. So, top management in ISO 9001 section 5.1.1, there are 10 things that top management needs to do, you need to have evidence for. And again, you can do a non-conformance on top management, do a root cause analysis to find out what's going on with top management and why they're not seeing the value in having a management system.
Jim Moran:
And of course a good corrective action can improve profits because of the information we saw earlier. Takes $50000 revenue at 2% net profit to have $1000 left over. So clearly if you can stop having corrective actions, if you can stop having non-conformance, if you can do good corrective actions that actually does prevent recurrence, you're in much better shape profit wise for sure. So let's see if I can get this first poll working. Poll number one. And here's the question. I'll just move this out of the way a little bit. Think of a time when corrective actions were not effective. Tell me why you think they weren't effective. I'm going to launch the poll.
Jim Moran:
Steve, we're not properly trained how to do an effective root cause analysis. Excellent. Well, we can help you with that, Steve, that's for sure. Stacey, solutions were out of our domain. Oh, hard to rely on others to perform their part. Excellent. And that's where some training for them can help too, we're going to use the word communications as well there, too. Management restricted the fix, wow. Thank you, Jeff, you're not alone, and Joseph, just so you know. I wouldn't say it's super common, but it's just more general than you thought. Number five, for most RCAs... Paul, maybe you can tell us a little more about that. Marco's top management did not buy a systematic approach, preferring a correction approach.
Jim Moran:
So those are the ones where you'll try anything and hope it works, throw enough mud at the wall, see what sticks, and definitely very common. Christian, top management didn't give us enough resources, absolutely. Now, again, if you can show those mathematical realities on how much a non-conformance costs, that maybe can wake management up to helping you maybe find a bit more money, or time, or people. Raymond raised his hand, participants need to open participants window. Thank you, Ray. Graham, I'm taught management and I don't have the time for root cause, easy to skip in face of pressure of sales. Absolutely.
Jim Moran:
Again, Graham's pointing out that this is a one off, probably never going to happen, it was just an audit-y, black swan as it were. And employees resisted a fix, we're unionized, employees are used to things being the way they are. Yeah, that's a big challenge. I think that's why I called this webinar Root Cause Analysis: What's In It For Me? Because unless you can demonstrate some value to people, there's really no reason for them to change. And if you're thinking about changing people's opinions, try to remember something Jim Muckle taught me. A gentleman from Auto Auto actually did change management for the Navy. And one thing I learned from him about change is that you can't just simply show people how fantastic it's going to be when everything's better, all these problems will go away, life is good.
Jim Moran:
You actually have to show them how much of what they already have, they'll still have after the change. It just was suggested there they like things the way they are. So make sure that you spend the time showing people that things will be better, and I'll often start with an organization when we build, or if I'm doing a proposal for why should we do, I typically ask them what they like about how things are running now and then what they don't like, so that I'm able to build a system for them where they get to keep the things that they like and we move on.
Jim Moran:
So let's get into the next part. Sometimes resistance to change comes from the wording of the non-conformance, right off the bat. People talk about resisting change in a union environment. The way you word the non-conformance can make all the difference. So often I see things like the operator didn't follow the procedure. So the fact of the matter is, your statement is a stimulus that causes a response. And the response could be in the operator's boss, the operator him or herself, different places. This causes them to respond back to you, so they become a stimulus for you.
Jim Moran:
Now, when that happens, when you're getting a response from the person you gave this statement to, now you are going to react or respond to their stimulus. So they're the stimulus. So here you are. You said, operator didn't follow the procedure, the operator responded. Now, the way the operator responded is the stimulus for you. So when you go to the doctor with a rash, and she prescribes some salve to put on it, and you put on the salve, if it gets worse, we call that a reaction. And then if you go back and get another one, another prescription, put it on, and it works, you call it respond.
Jim Moran:
So what this means is you have control over what you're going to do when the responded becomes the stimulus for you, so you can control whether you're going to react or respond. If you're going to react, it's just like a reaction to any kind of drug, and it's going to get worse. If the R is a response, you're going to get better. You can't control what they're going to do, you can only control what you do with their stimulus. And it's the same with top management. Unless you're Graham and you are top management. You can't control what other people do, and you have to deal with it, you have to create your response.
Jim Moran:
So, if you have good information from doing a good root cause analysis, this helps you turn it into a response instead of a reaction. And that can make all the difference. We need to avoid the phrase, the operator didn't follow the procedure. Why? Obviously, they're going to get defensive, and then you'll have to deal with not only the problem, but you'll have to deal with them being defensive. I've got a few ideas here for you to try. Let me just double check the chat box before I go on. I've got a couple of chats.
Jim Moran:
They are, my audio is weak, same for anyone else? Got it up, yup, it's all the way up. Sorry about that. Maybe I can get in a little bit closer, how's that? Mine's fine, mine's fine too, sometimes it goes in and out. Guess I'll have to stop drinking. Rory says his is fine, Marco, mine's okay. Wow, that's great, thanks everybody. I'll close that up. And we need to avoid the phrase because it makes people defensive, and the other thing that happens is, anybody who gets served with this phrase, you'll find that as soon as they hear this, that you're saying the operator didn't follow the procedure, the next thing that happens is, you end up with a hunt for someone to blame. Or the operator gets defensive. Or they'll have you 8293 reasons why they couldn't follow the procedure.
Jim Moran:
So rather than have it be sort of a battle, if we can get less defensive, that leads to less blame, it leads to more focus on the system. So when we get focused on the system, that's when we can actually make some good improvements to it. Operator error indicates a weak root cause analysis, because as I said before, operator error is based on the data. Demme, Geran... actually, Taichi Ono was even starting to suspect this, and it wasn't until Demme came along and actually did some research, 6% of the time it actually is operator error. So if the operator didn't follow the procedure, what were the circumstances?
Jim Moran:
Was it the working conditions that made it hard to follow the procedure? Was it the equipment? Was it the raw materials? Did they have to add a step or skip a step because of raw materials? Was somebody else involved? was it the aging machinery? Was it the technology? So, assuming that your operators at your locations aren't waking up in the morning and saying to themselves, I wonder how badly I can do my job today? Assuming that's the case, and it is 98% of the time, we have to find out why the organization, why our system wasn't supporting the operator.
Jim Moran:
There's another phrase you can use, the procedure has not been fully implemented. That could be a way to say it. These are things I had to use when I was writing non-conformances as an auditor. The requirement for, fill in the blank, has not been fully met. You can say the requirement for such and such has not been met, if in fact it hasn't been met at all, and then you want to look into why hasn't anybody done this? Could be, the instructions weren't clear, the spot was missing on the form, whatever. And this particular one here, current documentation doesn't match current practice, is good for a situation where the operator has actually found a better way to do it.
Jim Moran:
But your document control system is so complicated that the documentation hasn't caught up with how it's being done. Hopefully that won't be the case too often. The person who mentioned the union shop likely wouldn't be the case there. They would try something new. So make sure that your document control tools make it extremely easy for people to update documentation. That way, they'll be more likely to recommend something change as well. Now, the time this becomes an issue, if the operator has found a better way to do it, are times when it's a legal requirement.
Jim Moran:
Or a specific customer requirement, or it's something you discovered inside your organization that is a huge benefit to you if you do it. So, again, this can be helpful in certain circumstances, documentation doesn't match current practice. And this gets us focused on the process. It also subliminally tells people it's okay to try new stuff as long as it does not [inaudible 00:25:02] legal requirement, or regulatory requirement, it's not a specific customer requirement, and it's not something that we have [inaudible 00:25:09] health and safety environmental. So give people the credit for trying things, and make sure that, again, this is back to using the right language to get the root cause analysis off on the right foot.
Jim Moran:
And this is the question to ask in your organization to get people thinking in terms of, let's not just always blame the operator, let's find out what is weak here and how did our system let the person down. What's the weakness in our system that allowed the error to occur? And even more pointedly, what's the weakness in the system that allowed the operator to make this, or how did we not support the operator? If you decide it was the operator, look into areas of the system that weren't supporting the operator at the time of the issue. Why was the operator allowed to make an error?
Jim Moran:
By focusing on the facts and using evidence, you'll be able to improve the system, not just blame somebody. And you can look all the way through your system. And make sure that when you do the corrective action, like we asked a few questions earlier, if you just throw something out there hoping to hit the boss's time frame for corrective action, you might create a thing called suboptimization, where you fix one thing, but something else breaks. I've had cars like that in my past life, I don't know if Graham remember any of them or not, but you'd fix one whole in the muffler and the extra pressure would cause a pipe to blow somewhere else.
Jim Moran:
Luckily, those days are behind me, but you can all maybe relate to that one way or another. Can happen in a house too. Fix one area, and then another piece of weakness shows up. So when you focus on a workflow and use the flow chart, you'll know if you fix something here, you're not going to cause a breakdown here or here or here. So, by working on a flow, starting on a flow, you might actually start to see where the opportunity for the operator to make the error actually started here, and then it got magnified here, then magnified here. Then by the time it got here, here, and here, of course the operator was so uninformed by that point that it was almost impossible not to make a mistake.
Jim Moran:
You'll notice this organization, they popped these little Rs out here on some of these boxes, that's for risk. And I have another client that puts some trees on various processes to indicate an environmental risk, and another one uses hard hats where there's a specific health and safety risk. Thanks. Non-conformance statements, how helpful are your non-conformance statements? If you'd like to try that, I'll launch the poll. And let's see, I hope you can read that okay. Not very, I can see now, they may cause defensiveness, okay, but I can see we choose operator error too much. Pretty good, very good, that encourage an effective root cause analysis, excellent, most of our corrective actions lead to system improvements. That is great to hear. Oh, [inaudible 00:28:43] in that chat. Here we go. Let's see what we've got here.
Jim Moran:
Oh, [inaudible 00:28:51] and Proto Health Canada, and we do use root cause analysis and we do measure the cost of missing target dates for cost [inaudible 00:29:00] and we lose the trees, and we lose the fees. Ah, good. So even as a public service, you still have... that's great, that's a terrific example. Thanks very much for that. Trevor, no need to answer right away, wondering if you've given thought to what the cost of quality is in a government operation. And the service delivery. And the challenge there of course, Trevor, is measuring serve delivery accurately in a way that really means something to the users, the Canadian public.
Jim Moran:
Root cause analysis can and should be used in government. Again, if you can do a good root cause and prevent recurrence of issues, you'll be able to work within your budget probably more than if you just do a half baked root cause. Management, let's see, from Ray, management can also be a reason operator does not follow procedure. They set the tone. Absolutely, Ray. It starts at the top. I've often said management leads by example, whether they want to or not. Good to know, oh, thanks Trevor. Yeah.
Jim Moran:
Usually, let's see. Stacey. Usually they're very good, but sometimes the real issue is not explained properly. Beautiful. And through analysis and investigation, it's realized that the issue is really something different than originally reported. And that's precisely why, Stacey, that we want to make sure that the statement we make doesn't get everybody off on the wrong track, doesn't get everybody defensive. And the other challenge with those statements is to make them in a way that you're not skewing the root cause analysis. You want to make it in a way that you're keeping the door open to all kinds of exploration things.
Jim Moran:
And some statements have had to be revised at manager request. When he or she presents them, they have to be careful that the employee won't get defensive. Absolutely. That's brilliant, thanks Paul. And then of course, your organizations will have varying levels of bureaucracy, and I think the higher the bureaucratic quotient, the more careful you have to be in terms of stating the issue. And that's why you state the facts, like is the statement true, base it on verifiable evidence, maybe those other phrases will help in the future, the requirement for XYZ hadn't been fully met, or the procedure part 16 of section A hadn't been fully implemented, current documentation doesn't match current practice, any of those.
Jim Moran:
Let's see. As you explained, correctly defined non-conformance can help understand the problem and determine the consequences in appropriate situations, especially for when observation helps others follow up, absolutely. Some root cause analysis are done quickly, resulting in operator error being the most prominent, absolutely. So now, hopefully, those of you who do end up using operator error, I hope we've encouraged you to go a bit further and say okay, it was operator error, but why was the operator allowed to do it in a way that didn't get us the results we wanted?
Jim Moran:
That's another term you can start using, it's in ISO 9001. And in a great article, IRCA article, International Register of Certificated Auditors, called Next Generation Auditing, they're talking about shifting the audit focus from auditing to see if people are following procedures, to auditing to see if a procedure is getting the result you want. So the difference is that now you're literally auditing for results. If you're auditing to see if people are following procedures and ending up with non-conformances, then you're encouraging people to follow perhaps badly written procedures.
Jim Moran:
And Joseph has a comment. I pruned my own bias, last poll I defaulted to the answer that management didn't agree with the fix. It was a better non-conformance statement may have led them, ah, marvelous. So it's worth the price of admission today, Joseph, thank you. [inaudible 00:33:41] conclusion of operator error is very rare for us, fewer than one, but doing good root cause analysis is very time consuming. Yes. What we hope is that, even though it's time consuming, that we have established that it's worth the investment. That's what we're trying to do, make sure that you've convinced yourself that it is worth the investment, and I'm hoping that there's a link. I'm trying to make this link between doing a good root cause analysis and preventing recurrence. A recurrence is expensive enough to begin with, but if recurrence of non-conformances happens continually, and over and over and over, eventually you're going to get to reduction not just in profit but a reduction in morale, and that's pretty bad.
Jim Moran:
Good. So what can you use? Well, as you know, my favorite tool of all time, Ishikawa fish bone. How do you do it? You think of the inputs over here on this side, this can be a poor quality product, well, it's a work with service, it's just as well. But he identified, and it's not politically correct to say these days, but he liked the alliteration of Ms. Man, Method, Machine, and Milieu. Which, the person is clause 712 in ISO 9001, the machine was what we call now the infrastructure, 713, milieu is the work environment. Where's work environment? Machine... there it is, working conditions, work environment, 714. Raw materials would be input, starting at 8.4, I guess. 712. Technology, get back here. Technology. This can be very important. If you're maybe one of the few people here that are related to the federal government, if the computer technology isn't up to speed and you're running behind on submitting reports because the processors aren't good enough, those are issues where you might get dinged for a late report submission, but in fact as the old saying goes, it wasn't my fault.
Jim Moran:
So Ishikawa had these three steps, I'll just show you the steps. Start the process with brainstorming. Get as many ideas as you can, and if you happen to be the one fielding the ideas, simplest method I've ever seen is to put them up on sticky notes, on a whiteboard or a flip chart. Whiteboard's kind of cool. Or tape some flip chart paper horizontally or make a big giant square on the wall, whatever works. Nice thing about stick notes is you don't have to worry about sticking them on a finished wall, like it won't take the paint off the wall.
Jim Moran:
So do a whole bunch of brainstorming, and in order to encourage more ideas, try not to be too judgemental when you're fielding the responses. Then, make sure there are cross functional teams if you can, they work better. This just isn't my observation, you'll see tons and tons of research that show how having a mixed background can certainly help. Now, it is tough in smaller companies. Say you had a company of seven people. You still have different viewpoints, though, and if you're guiding the root cause carefully, or perhaps elicit the services of an external person. That could be helpful, sort of a coach or mentor, something like that.
Jim Moran:
Then, clump them together, and this would be Ishikawa's Man, Method, Machine, and Milieu, and don't forget the inputs, of course. And this will help you get a good start at it. Then you go back here, and dig down inside here. Let's take working conditions, noise, illumination, draft, maybe temperature, season creates the season, changes the temperature, the humidity. There's a foundry here in London that makes the blower covers for Corvette engines, and the aluminum melting furnaces run at 1000 degrees Fahrenheit. The door is always open and they're throwing either the chips that come off or the defective parts.
Jim Moran:
And that kind of work environment can distracts a person, and it's very easy to get distracted and make some kind of error. So then you go down deeper, so you find someone... now, obviously, you can't do anything about the season, but you might be able to do something about the temperature. And drafts, noise, that's another thing too. Less expensive equipment sometimes is noisier. So there's lots of things you can do, management, is management aware of what's going on? Is management communicating well? Let's say operating conditions here, machine wear. Why is the machine worn? So you do the five why down in any one of these.
Jim Moran:
Why was the machine worn? Because we didn't do preventive maintenance. Why didn't we do preventive maintenance? We took it out of the budget. Why did we take it out of the budget? Sales were down. Why were sales down? Because we were having too many on-conformances. Anyway. So the affinity diagram, it works exactly the same way. Start with brainstorming. But instead of using predetermined categories, you make up your own. That's the only difference.
Jim Moran:
Tap root, I came across six or seven years ago when I was doing a workshop out in Regina, Saskatchewan. It was minus 43, was the actual temperature on the third day. They actually stopped the school buses running on minus 40. It was quite, quite chilly. And they wanted me to talk about tap root because it's something that's often used in a health and safety issue. Not my favorite method, but to just kind of summarize it in maybe the simplest terms, instead of starting with the problem and working backwards, you start when the operator got out of bed in the morning and work your way through the day. There's a new version of it, if you have a chance you can hit this guy here. It's the taproot.com, https://taproot.com. And there's about a 15 minute video, and around minute nine or 10 it's pretty good. You can learn a little bit more about their part.
Jim Moran:
So it's evolved, but it still comes down to a lot about the same thing. And when you think of the root cause you might think this way, so tap root kind of gets you thinking in terms of what are the other things, but think back to those Ishikawa diagrams I showed you. A lot of them have these extenders off the edge as well. This one is from this site called thinkreliability.com. So there's lots of good information on tap root if you think you're not happy with Ishikawa, if you're not happy with affinity, you can certainly look into this. Again, the big challenge is, can we do anything about the cause?
Jim Moran:
Now, in order to avoid non-conformances, you can do Failure Mode Effects Analysis, this is PFMEA, is Process Failure Mode and Effects Analysis, and DMFEA is Design, I'll get back to that one. DFMEA, some of you may have... Chris Jim is in the automotive field, they sort of are big fans of FMEA. Some automotive customers require that the suppliers do PPAPs, Production Part Approval Process. They do APQP, Advanced Product Quality Planning. And FMEA fits into that whole package as well.
Jim Moran:
So, not so much as a root cause analysis tool is it useful, but it can be useful in a root cause, when you're doing a root cause analysis, to see where the planning went off the rails. You'll also notice in ISO 9001 clause 10.2, E talks about reviewing your risk analysis to see if you... let's ask the question, if we had done a better risk analysis, could we have avoided this non-conformance? And that's something important to consider. So, another tool, we're in the tools section, show your results on the Pareto chart. The reason this is a tool under the tool section is because it lets you see trends.
Jim Moran:
Another tool... I should ask you to raise your hands. Let's see what happens if you raise your hands. How many of you use Pareto charts? Could I see your hands please? Maybe I can't... I'm not sure where the hand raising is. Oh, transportation safety, thanks Roberto. Tap roots are used by the transportation safety board for accidents and when looking at human performance. That's where I've seen it the most, health and safety. Interesting. From Trevor, it's a quote. There is so much good in most of us, and so much bad in all of us, so keep your words soft and sweet because you never know from day to day the ones you have to eat. Inst that interesting, Kenny McBain. [inaudible 00:44:34] that's a good one. Keep your words sweet because you'll never know which ones you'll have to eat.
Jim Moran:
So I didn't see any hand raising, maybe I haven't got that part figured out yet. Oh, Christian's raising her hand, so they've used... thank you so much, now I can see what that looks like. Pareto charts, excellent. Anything visual really helps. If you think you don't want to take the time to express something visually, you might be interested in some research by the Visual Learning Alliance. The human brain processes visual information, a picture like this, 60000 times faster than text. Yes, ladies and gentlemen, 60000 times faster. Scatter diagrams are good, they can show you trends. Both of these, the Pareto and the scatter diagrams, scatter plots, extremely helpful so you can see trends.
Jim Moran:
You can see correlations pretty quickly too. As long as you've got all the parameters identified correctly, they can be very helpful. This is kind of cool. You've seen this chart, saw this chart a little while ago. If you take the time and plot where non-conformances are happening on the chart, then you can see if trouble spots are repeating themselves, or plot them, see if anything is clumping or see if anything is showing up again and again and again in the same place, that could be an indication of either some safety issues, could be an indication of weakness in thee workflow... handoffs are really, really where many, many, many non-conformances take place. Most people know what they're doing inside these individual boxes, but it's when it goes from step one to step two, that's when things can happen.
Jim Moran:
Next tool, monitor and review your corrective actions. There's no point to spending the time and effort doing something if you're not going to take the time to figure out if it actually worked or not. And that's where you really start to see the payback. When you can take the time to measure, now people who are skeptics are seeing actual evidence. And the other issue is that we want to make sure that results are being measured properly. Interesting. Graham, I don't have an answer to that. But the question was, what percent of quality improvement comes from improvement of processes? I think, philosophically speaking, since your processes are what produces everything... if you can demonstrate, or if you've decided somehow that quality has improved, I have to say 100% of quality improvement comes from improvement of processes. Nothing happens without a process. Nothing happens until somebody sells something, too, but nothing gets produced, service or product, without a process. Good question.
Jim Moran:
Record, report, and communicate for the best effect. If you're making these improvements, that Graham just asked about, to processes, and you're not telling anybody about them, people could imagine that things are actually just getting worse. If all they hear about is that there's been a problem, and they don't hear about what the fix was, and if they weren't involved with the fix, and you weren't showing them like this, in charts, showing how things are getting better, then it's quite likely that it'd be hard to get any momentum going for any kind of project like that.
Jim Moran:
So, what have you found to be the best root cause analysis tools? And I'll watch the poll, and take it away. That's great, Ray, thanks for your help. I'll just remind you too, while you're answering, five why was the precursor to Ishikawa, Ishikawa built on the five why. And you can certainly use five why by itself, and you'll get something... Rakesh... it's a combination of Ishikawa and five why, excellent. Thank you so much. And there we go. I'll just give you a couple more minutes. Ishikawa. Nobody's used the affinity diagram. Tap root, a few, and then we've got Paul, you've used five why, Ishikawa, and timeline analysis, I'd like to learn more about that sometime. Thanks, Paul.
Jim Moran:
Anything else? Yeah, it's pretty hard to go wrong with Ishikawa and five why, especially if you're focused on the system. Keep thinking system. Remember that operators can only perform as well as your system is supporting them. If it is operator error, make sure that you understand what that operator needs, or what the employee needs, the whomever needs, to get the results you want. Make sure that you've got a system in place that really supports them in doing that.
Jim Moran:
So, Ray's used all RCA tools, but five why's is the most often. What do you think about the event cause analysis and barrier analysis? I've heard a little bit, Chris, about barrier analysis. But I couldn't comment on whether it's better or worse. I kind of like the barrier approach because, instead... first, focus on the system and make sure it's working positively and can actually support the results you want, but then if you're kind of hitting some stone walls, try looking for barriers. And again, you can look for barriers on the equipment side, the work environment side, the skill side. Thanks. Got one minute left. Thank you all so much.
Jim Moran:
And I'll get rid of this. We've got a course on root cause analysis, if anybody's interested. We customize this for you, it's not just a standard course. Three three hour days. We've got discounts built in since you've attended these things, let me know if you need one. Virtual audits, we've got a webinar coming up on August 31st, 12 noon. I've done some myself. Most all standards except Christian's, ITF 16949, all the other standards are allowing full virtual audits, and when you start to see the savings that you can gain from not having to pay auditor travel time, auditor hotel expenses, auditor meals, auditors eat a lot of food, we all know that. You'll see that it's the way of the future.
Jim Moran:
So make sure you come by for that if you can. Our platform of course can help you in a virtual audit. We'd be happy to do a demo for you, just head over to simplifyISO.com, and we can also help with documentation and with closeouts. So, if you'd like a complementary lunch and learn, we've got seven spots still left for August, we've had a few in July. Just send me note, jim@simplifyISO.com. Any topic of your choice, if there's anything you like we can certainly look after that for you. So thank you all very much for coming. Thanks for hanging in til one minute after one. And if anybody would like to stay on, I would be happy to have a conversation with you.