In the last post, we discussed looking at a process through the lens of desired outcomes. Every step in a process, every action has (or should have) one or more results that indicate the step was successful. For this reason, I have developed what I call the Purpose Map (with apologies to Pastor Rick Warren, though note it’s not a “Purpose-Driven Map”). I apologize to those who have requested the Purpose Map guide to development; it will be released within a week (if you did not yet request it, now’s your chance).
The reason for the Purpose Map is this: I can create a very nice process map, that lays out the current state of the activity. Remembering that every process can be defined by one current-state best way it is done, I can document that “way” and go back and teach everyone the “way.” Ideally, the result will be everyone performing the activity the same (best way we know how).
But as long as I have the procedure broken apart in pieces on my workbench (actually, it is broken into lots of statements on Post-It notes on a wall), would it make sense to look closely at it and determine if there is a better way? Even if I have no measurable defect issues, there may be other wastes that I can remove from the performance of the activity and continuously improve.
This is where analyzing the actions in relation to their intended outcomes becomes so valuable. Because every action (the elements that make up my process) will fall into one of the following categories:
1. Accomplishes nothing in relation to a desired outcome (there is no connection between the action and the process output at the end of the step or process)
2. Is aimed at achieving a specific desired outcome, and achieves its objective (the vast majority of the time)
3. Is aimed at achieving a specific desired outcome, but fails to achieve its objective the majority of the time (or at least an inadequate number of times)
4. No one is sure if the activity is connected to a desired outcome or not
If I analyze the task, actions or activities that fall into each category feed specific process improvement activities:
1. If the action accomplishes nothing in relation to a desired outcome, move it out of the process (every resource applied to the action is, by definition, waste)
2. If the action is aimed at a desired outcome and meets it sufficiently, then don’t touch it–make sure it is properly documented and that performance of the action is enforced
3. If the action is aimed at a desired outcome and does not meet it sufficiently, then go to work on that step. Work on all inadequate actions in the order they occur in a process. It may be that if I fix the flaws of step 6, the flaws in step 7 may iron themselves out
4. If I am not sure about the intent or efficacy of an action, I need to study the process more deeply…until I can move the action into one of the three categories above.
WARNING: process analysis is hard work. If you spend a day working on describing (mapping) a process, and you are not completely worn out, you have not worked hard enough to define and describe the process.
A very smart person (who chose to remain anonymous) once said, “A problem well defined is already half solved.” This is critical to the success of any improvement effort. The more thoroughly you define and drill into the details of a process, the greater your chances of making major improvements happen.