One of the challenges I often face is that of explaining the current state of our processes to leaders at my company. Sometimes my goal is to convince them that the current process is “in statistical control” and the seeming irregularities they saw last week were not anything that they need to worry about. Other times, they do not seem to think that some processes are problematic and my goal is to convince them that the same processes are out of control, or trending in the wrong direction.
The causes of these issues usually occur in sub-processes that the leaders do not regularly monitor. Who can blame them? They have far too many metrics to watch as it is. In truth, many of these processes go unmonitored or are completely misunderstood by most employees.
For example, our technical support group uses a knowledge management tool to help them track and resolve customers’ technical issues. The business has spent tremendous effort attempting to prove that this tool either helps or hurts the satisfaction of our customers. The test is usually constructed as follows:
- Collect data on the extent to which each representative uses the knowledge management tool
- Collect data on the extent to which customers handled by each representative are satisfied
- Run a regression analysis using knowledge management tool usage as a predictor of customer satisfaction
Obviously, there are a number of issues with this simplistic analysis. After watching the business run through several iterations of analyses similar to this, it occurred to me that one of the factors ignored, among many others, was the diagnostic questions that the agents used to decide which search terms to put into the knowledge management tool to find the appropriate content.
The focus of the operations group (who do not particularly like the tool) has generally been on the quality of the content. They essentially point their fingers at the content management group and blame them for the poor performance of the tool. On the other hand, the content management group point thier fingers at the operations group as the problem, noting that because the agents do not provide feedback on content that needs improvement, the content does not improve.
When my teammates and I mapped out the technical support process at a high level, it quickly became evident that a major part of the process has been ignored. It occurred to us that the company does not have any measurement systems that assess the quality of the diagnosis performed by the agents. So now we have ourselves a little project to conduct. This may not necessarily be a full fledged Six Sigma project. At the very least, we have an assignment to create a new measurement system that assesses the quality of diagnosis performed by agents. Interestingly, this may require a new knowledge management tool. It is a daunting task but if we are to make progress, we must assess where we stand.
The bottom line: Process mapping will often quickly help you identify areas where your business does not have information that tells them which parts of a process to improve. Once you have this information, it is often clear where you need to develop or refine measurement systems so that you can improve process outputs.