I came across this great article at MyCustomer.com on Key Attitudinal Indicators vs Key Performance Indicators, and why KAI’s may be better suited (as a leading indicator) to predict customer loyalty than KPI (a lagging indicator)… give it a read and see if you agree! Please post your thoughts here… I’d love to hear ‘em.
|
|
|
|
|
 |
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!
|
|
|
|
|
|
|
As with many processes, I’ve found that what gets monitored on a regular basis tends to stay at status quo, or improve; what is ignored, tends to deteriorate quickly.
Let me give you a quick example: We just got back from twelve days in Maui (it was fabulous!) Yes, that’s why you haven’t seen a post since then… I just could NOT focus on work while I was there! [And, that's good news, when you think about it...]
However, we left our swimming pool, and directions for maintaining it, with a contractor who would be working on the house. Turns out, the materials we were waiting for were delayed, so the contractor didn’t come for the last 8 of the 12 days we were gone.
Those of you who own swimming pools may be able to write this next part with me: we came home to a green swimming pool. The algae was pretty prevalent, and we had to do something pretty quickly. More worrying, the pressure in the filter was way too high, which can burn out a motor pretty quickly. So, instead of the pool being monitored, it was ignored. And, instead of the pool being swimmable, it wasn’t.
How often does this happen in business? How often do we think that something is going along ’swimmingly’ only to find out that we have a BIG problem - a problem that could have easily been avoided or minimized by a little attention more frequently?
Go review your processes now, and see which of them might benefit from a little more frequent attention.
|
|
|
|
|
|
|
Bad Behavior has blocked 88 access attempts in the last 7 days.
