The Evolve Loop encompasses the Solve Loop. Structured problem solving as a higher-level process puts some context around the practices of the Solve Loop. The Solve Loop is not intended to be a linear or sequential model. The practices operate as independent entities, and they are used as needed in responding to customer issues. The structured problem solving process provides direction on how to use the Solve loop practices in an effective way.
In some respects, problem solving is an art. However, we have found that a little bit of structure in the problem solving process can help improve the art. The structure of the KCS article also helps reinforce an effective approach to problem solving.
An analogy is helpful in making this point. Consider a crime scene: the first thing the police do when a crime is reported is to preserve and record the situation. The first officers to arrive on the scene are trained to secure the area; they mark the location of the evidence and bodies and take pictures. When the detective shows up to solve the crime, they first seek to understand the situation, then begin to ask clarifying questions, and then eventually go off to do research.
The Structured Problem Solving process involves application of the four practices in the Solve Loop. It helps the Support Analyst collect, organize, and analyze the information used in solving the issue. Note that there are different skills used in different steps in the problem solving process, and, as a result, different Analysts may be involved in each step.
Having explicit techniques in the workflow not only improves the problem solving process, but also creates KCS articles, as a by-product of the problem solving process. The Structured Problem Solving Process in KCS includes two simple, yet powerful, concepts:
Seek to understand before we seek to solve
Search early, search often
First, we seek to understand the situation in the customer's context, and we capture it to preserve it. Then we seek to understand what we collectively know about the issue (search the knowledge base). These concepts are not unique to KCS; Charles Kepner and Benjamin Tregoe outline these same problem-solving methodologies in The Rational Manager, as does Stephen R. Covey in The 7 Habits of Highly Effective People.
Just as in the crime scene, we start by preserving the perspective the customer has of what is happening. This is a very literal process. Next, we search the knowledge base to see if this is a known problem or to see what we collectively know about this type of situation. This idea is the "search early, search often" concept discussed in the Solve Loop. If a KCS article is found in the knowledge base, then we are done. If not, then we refine the search by collecting additional information from the customer.
Searching will sometimes result in finding articles that describe similar situations. While perhaps not perfect for our situation, the content often complements what we know about analyzing this kind of issue. If an existing article is not found after a few searching and refining our search, we start the analysis process. We tap into our problem solving experience and use whatever tools are relevant. We continue to ask clarifying questions. As we build a richer understanding of the issue, we check the knowledge base frequently. If we do not find anything pertinent to the situation already within the knowledge base, and we cannot resolve the problem, we then collaborate with others or escalate the issue for more research.
Many Analysts are too quick to move to the analysis phase of problem solving. If we move too quickly into diagnostics, we are likely to jump to conclusions, stop listening to the customer, miss the fact that there is already a KCS article in the knowledge base, or miss the opportunity to learn from others' experiences in solving similar problems. KCS reinforces the need for the literal step to be the first step in the problem solving process.
Most Support Analysts find that they will need to use multiple applications to get the job done: an incident management system that keeps track of the events, and a knowledge management system that houses the KCS article. It's an important part of the KCS workflow to manage the use of these applications as we resolve each issue. We let the customer know what we are doing during each step along the way and why it is valuable. We call this "managing the conversation."
For instance, when there is a pause in the conversation, we could let the customer know that we are capturing their context and searching the knowledge base for additional information.
If the information is found in the knowledge base and it is accessible, we let the customer know that the knowledge base is available for them to search.
Deal with the administrative elements at the beginning (contact initiation) and end of each contact (wrap up), not in the middle of the conversation. This approach will allow focus on the objective of problem solving.
Problem solving is a collaborative process. Ask any Support Analyst what they do when they realize they are working on something new or unfamiliar and they will tell you they reach out to their peers: they collaborate. And, all too often they do it in spite of the traditional support processes and escalation rules. What if our support process and infrastructure facilitated collaboration instead of inhibited it?
Support Analysts have collaborated for years using tools like email and instant messenger or just asking others nearby; the "prairie dog" support model (over the cubicle wall). These are helpful but limited in their effectiveness. We are seeing some significant infrastructure improvements that facilitate collaboration.
The opportunity to improve the effectiveness of collaboration lies in our ability to know things like availability, who knows what, and who is interested in what. Effective collaboration or what we call "intelligent swarming" is a function of relevance. By relevance we mean, for a given issue, we want to bring together the best resources we have (people and/or content) to solve the issue. To accomplish this we have to know something about the issue and something about our resources, content, and people. Earlier versions of KCS focused on capturing the collective experience of the organization in a KCS article (content). What is emerging is the idea of people profiles that capture both the experiences and interests of the people.
Just as a search gives us access to the past experience of others through the KCS article we could improve the relevance of collaboration by providing access to the people profiles.
The Consortium members have been working for some time to bring the concept of intelligent swarming to operational reality.
We have learned some things from skills based routing. Most organizations that have done it report mediocre results. The issue is if the profiles are detailed enough to be helpful in getting an issue to the right person they are difficult to create. And if they are created the dynamics of the environment make them impossible to maintain. On the other hand if the skills profiles are at the level of detail where they are creatable and maintainable, they are not specific enough to be very accurate in routing.
We have come to the conclusion that the people profiles must be largely programmatic or maintained by the system and tunable by the people in order to reflect interests. The experiences of a Support Analyst change on a week-to-week basis.
Some operational examples of enabling collaboration:
Collaboration capability built into the user interface
Simple version - launch instant messenger (without leaving the problem solving environment - see the prototype user interface)
Sophisticated version - finds relevant people based on the information captured in the incident or WIP article
People finder capabilities
Directed swarm - a team of people triage all incoming issues or a team of people work on any reported severity 1 issues. This takes the KCS concept of collective ownership of knowledge and applies it to incidents. A different view on incident ownership; distinguish ownership of response from ownership to solve. An individual is responsible to respond to the customer but the team owns resolution of the issue. (See the BMC case study at www.serviceinnovation.org/kcs
Enabling visibility to all open incidents and filters that allow Support Analysts to see the incidents they might be able to solve or assist with. This enables an opt-in model; people choose to help.