our friends at Crucial Skills offer the following advice if you are plagued by one of these
1. Unreliability
2. ”It’s not my job”
3. Procrastination
4. Resistance to change
5. Negative attitude
Luckily, they also provide some tips on how to overcome them… 
|
|
|
|
|
 |
Process Mapping should be the foundation for any initiative to increase the performance of your company. Whether you are trying to achieve cost reductions, increased quality, higher employee satisfaction, increased efficiency, decreased wastes, or improvements in any other company performance metric, you should start your initiative with process mapping. To show the importance of process mapping let’s start with an example we can all relate to, writing a paper.
If you were asked to write a report drawing conclusions about the value of a particular niche in a subject that you weren’t familiar with you wouldn’t start your research with a laser focus on the niche. If you did you would inevitably wind up writing a sub par paper. You wouldn’t have an understanding of the greater context of the subject and your paper would be lacking the depth of understanding that a well written report requires. Sure you may learn everything there is to know about that niche, but how could you draw an accurate conclusion about its value without first understanding how it fits into the overall subject. Most of us, if asked to write this kind of report, would begin by looking at the overall subject and seeing how it fits into everything else around it, then exploring the interactions between the different parts of the subject, then exploring our particular niche. This way, when we draw a conclusion about the value of the niche we have been exploring, we know that the conclusion takes into account how this niche interacts with the broader picture.
Trying to take on an initiative to improve the performance of you company without first going through a process mapping exercise is like trying to write the paper by taking a laser focus on the niche. Before you can try to improve the performance of any one particular area of your company, you first have to understand how each area of your company operates internally and how the different areas interact with one another. This is why process mapping is invaluable for company performance improvement projects. With a good process map you will understand the ins and outs of each part of your company and how the work that makes your company run gets done. With this understanding you can then focus on improving particular metrics with an understanding of everything that affects that metric and is affected by it.
Targeting a performance metric and taking steps to improve it without having the context of a good process map will inevitably have negative consequences for your business. While you may be able to achieve increased performance in that area you won’t see or understand the organizational cost of those achievements. The goal of improving a performance metric is always to make the company as a whole better, and to do this you have to start from an understanding of how the company as a whole operates, which is precisely what a good process map gives you. Staring with good process mapping gives you the foundation you need to insure that your efforts to improve the performance of you company are achieved and sustained.
|
|
|
|
|
|
|
OK, quick recap: In part one we talked about definition; in part two we discussed data identification and collection, and interim containment; part three discussed identifying the root cause. Part four discussed fixing the true causes of the problem.
Now that we’ve implemented our chosen fix, we want to focus on how to ensure that we don’t have the problem recur. This is often a misunderstood step in the process. If the prior step was “fix xyz”, I often see folks who document the step on prevent recurrence as “continue with xyz”. Well geez, that’s brilliant! I’m guessing that it’s a bit more complicated than that, tho…
So, what does ‘prevent recurrence’ really mean? Let’s start by expanding our thinking - we want to prevent recurrence not only for this defect, but for additional potential causes as well.
Additional potential causes??!? Where am I supposed to get THAT info? Ahh, that’s where the beauty of the tools we used in step three come in — we can go to our pareto diagram, our cause-and-effect (fishbone/Ishikawa) diagram, or other investigative tools. Although we were able to eliminate the problem by focusing in on the root causes we identified, we can go back now and figure out what are probable causes of future defects - and prevent them before they occur. For all you folks who have implemented ISO 9001 and have trouble identifying preventive actions, here’s a great place for it.
Now let’s be clear — if you find a defect on line 2 of a manufacturing plant that has three identical manufacturing lines, and you implement the fix on lines 1, 2, and 3, this is not corrective for line 2 and preventive for lines 1 and 3 - this is simply complete/comprehensive corrective action. But, if you also implement a ‘fix’ on something that hasn’t ‘broken’ yet [since you're implementing and training anyway, you might as well do it for multiple as for one], you are doing true preventive action. Woot!
|
|
|
|
|
|
|
OK, quick recap: In part one we talked about definition; in part two we discussed data identification and collection, and interim containment; part three discussed identifying the root cause. Now we’ll discuss what to do once we know the true causes of the problem. It sounds pretty simple and straightforward, really - eliminate the root causes. But we find out that it’s not as straightforward as it may seem….
When eliminating the true root cause, you want to ensure that you will follow the advice given to doctors — “First, do no harm”. Implementing an effective corrective action means fixing the problem, without causing new problems. This may involve ensuring that the fix can be implemented fully; that the fix corrects the problem; and that (here’s the tricky part) if you remove the fix, the problem comes back. Why is this the tricky part? Imagine this: “Ummm, boss, I think I’ve found the cause, and so I ran a test and the defect disappeared. Now, I’m going to remove the fix and produce bad parts again, just to be sure…” Yah, that conversation will really happen…
So, you take your data, analysis, pilot studies, etc. and select and implement the best fix for the situation. The ‘best fix’ may involve some other analysis, like down time, training, costs, resources, etc. to get the best fix for your organization, so remember to be aware of other factors that can impact implementation.
Once this fix is in place, monitor results to ensure that the fix worked, and that there were no adverse results. If so, congratulations!
|
|
|
|
|
|
|
In part one we talked about definition; in part two we discussed data identification and collection, and interim containment; now we’ll discuss identifying the root cause.
Identifying root cause isn’t as easy as it sounds, since sometimes we confuse symptoms with cause. Here’s an example:
When you go to the doctor, you tell him/her your symptoms, and the doctor may diagnose you right there, or may run additional tests before diagnosing the problem, and recommending the solution.
The additional tests, in our case, are to narrow down the possible causes, or to validate the chosen causes, before taking action to eliminate the cause. We don’t want the doctor to treat the sore throat and fever, we want the doctor to diagnose WHY we have the sore throat/fever, and help us eliminate the cause - permanently.
So for identifying the root causes, we want to make a list of possible root causes, and then determine which causes are the reason we have the problem this time.
There are several tools to help us make this differential diagnosis – some of them include the Ishikawa or Fishbone Diagram (because of its structure) or Cause-and-Effect Diagram (because of its results); Affinity Diagram; Fault Tree Analysis; Kepner-Tregoe Problem Analysis; Process Mapping; and Failure Mode and Effects Analysis.
Each of these tools strives to take data from different sources and place them all in one place. Both the Affinity Diagram and Fishbone Diagram then ‘cluster’ the data into larger similar groups. For Affinity Diagram, the data is clustered by the team, with major topics selected based on available data. For example, if the group is trying to save time in morning routines, they may cluster events around location (bathroom, kitchen, etc.), around who does tasks (myself, myself plus family/pets, etc.) or around events (get ready, eat breakfast, exercise, etc.) based on what will give the team the best chance of identifying root cause of long morning prep time.
For Fishbone Diagram, the data is clustered around known fields. In Fishbone, for a production process we typically use the “5 M’s” – manpower, materials, methods, machinery, and measurements (and a newer, sixth, M is “mother nature”, or environment); for administration in service either the 8 P’s (Price, Promotion, People, Processes, Place / Plant, Policies, Procedures, and Product (or Service) or the 4 S’s (Surroundings, Suppliers, Systems, Skills). Each of these is structured to a) make it easy to remember the categories when a fishbone needs to be derived, and b) allow additional brainstorming of possible causes when filling in.
The benefits to each of these methods is in the details. Too often, I find that an Ishikawa diagram has been done, but the team didn’t save it for future use. Or, the diagram was done, but didn’t go into enough detail to make the tool worthwhile. For example, a major cause may be manpower… so we look at all the ways that we can have the incorrect person in the job. This would be the major cause, or first ‘bone’ on the skeleton. The minor causes might include lack of training, lack of expertise, lack of knowledge (although they all sound related, there are different sub-causes, so we list them separately)… and from there we list sub-causes, and sub-sub-causes, until we get down to the true root cause for that particular area.
Other techniques and tools may analyze each step in a process or service to determine where errors can be made (Failure Mode and Effects Analysis) or follow a process to identify areas of error (mapping, Fault Tree, etc.) The important point here is to do the root cause analysis correctly, and fully; don’t stop before you get the to true root cause.
In part four we’ll discuss what to do once you’ve determined true root causes… stay tuned!
|
|
|
|
|
|
|
Bad Behavior has blocked 283 access attempts in the last 7 days.
