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!
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
Bad Behavior has blocked 283 access attempts in the last 7 days.
