Improve My Business

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.

Technorati Tags: Business, eliminating defects, improvement, process improvement, process mapping, quality, Streamlining

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!

Technorati Tags: corrective action, defect, eliminating defects, preventive action

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!

Technorati Tags: eliminating defects, problem solving, root cause

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!

Technorati Tags: Affinity diagram, Business, eliminating defects, Fault Tree Analysis, fishbone diagram, FMEA, Kepner Tregoe, problem solving, process, process mapping, process monitoring, processes, root cause, Streamlining, systems thinking

In Part One, we talked about defining the defect or error we are trying to eliminate. We know that the definition may not be correct due to our lack of knowledge of all the aspects of the problem; so we want to develop a list of data that we want to gather.

The data may be available already – as part of regular process monitoring or other sources (maybe the daily high and low temperatures for a series of days, for example). If so, ensure that someone is gathering the data and making it available to all who need it. If the data is not readily available, determine the best way to gather it. Please note that ‘best’ does not necessarily mean ‘easiest’ – we will be making future decisions based on the integrity of this data, and we need it to be accurate enough to meet present and future needs.

Once we have all the data that we think we need, we are ready to assess our next step – containment.

Containment is defined as as interim action that prevents the defect or error from getting worse, and minimizes or eliminates it on a temporary basis. The containment action is discontinued when the permanent action is put in place. Here’s an example that may explain the difference:

I’m in the kitchen cutting up vegetables, and the knife slips, cutting my hand in the process. The cut is pretty bad, so I’ll need stitches. Containment is to rinse the cut, bandage it, and get to a clinic or hospital. Permanent action is to get the stitches put in; and remember that since the containment action is discarded after the permanent action is in place, the doctor is not going to replace the same bloody bandage I arrived in; (s)he’s going to use a new bandage if she needs to.

In the real world, containment usually doesn’t require any special skills (like the ability to suture skin); and many actions including the following are considered containment:

* monitoring
* inspecting
* sorting
* testing

So, our steps:

* determine what data we need to make current and future decisions;
* implement temporary containment while we figure out what to do next.

In part three we’ll talk about identifying the root cause.

Technorati Tags: eliminating defects, problem solving, process monitoring