Home > KCS v6 Practices Guide > Section 2 The KCS Practices > The Evolve Loop > Practice 6: Process Integration > Technique 6.1: Structured Problem Solving

Technique 6.1: Structured Problem Solving

As we have mentioned, the Evolve Loop defines and encompasses the Solve Loop. The structured problem solving 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 requests. 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 outcome. The structure of the KCS article also helps reinforce an effective approach to problem solving.

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 responders 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 responders or collaborators may be involved in each step.

 

Having explicit techniques in the workflow not only improves the problem solving process, but also creates a KCS article as a by-product of the problem solving process. The structured problem solving process in KCS includes two simple, yet powerful, concepts:

 

First, we seek to understand the situation in the requestor'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.

Structured Problem Solving Model
Just as in the crime scene, we start by preserving the perspective the requestor has of what is happening. This is a very literal process. Next, we search the knowledge base to see if this is a known issue or to see what we collectively know about this type of situation.  The "search early, search often" technique is a key part of the Solve Loop. If a an article is found that provides the resolution, then we are mostly done (we still need to link and modify the existing article). If not, then we refine the search by collecting additional information from the requestor.

 

Searching will sometimes result in finding articles that describe similar situations. While perhaps not perfect for our situation, articles about similar issues can provide additional insight or trigger qualifying questions that we had not thought of. This complements what we know about analyzing this kind of issue. If an existing article is not found after refining our search a few times, we start the diagnostic 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 in the knowledge base, and we cannot resolve the problem, we then collaborate with others or escalate the issue for more additional research.

 

Different Skills at Different PointsMany responders are too quick to move into the diagnosis phase of problem solving. If we move too quickly into diagnostics, we are likely to jump to conclusions, stop listening to the requestor, 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.

 

 

 

 

 

 

Managing the ConversationManaging the Conversation

We are seeing better integration of the various systems the responders use to resolve issues. However, if systems are not integrated and we have to use multiple systems and screens to handle issues, this section is relevant.  In environments where we need to use multiple applications to get the job done; for example, a case or incident management system that keeps track of the events, and a separate knowledge management system that houses the KCS article, it's helpful to design the KCS workflow to manage the conversation in order to minimize the need to jump back and forth between systems. 

 

Deal with the administrative elements at the beginning (contact initiation) and end of each contact (wrap up) - not interspersed thorough the resolution process. This approach will allow focus on the objective of problem solving:

Enabling Collaboration

Problem solving is a collaborative process.  Ask any responder 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.  All too often they do it in spite of the traditional processes and escalation rules. What if our 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 integrated into the responder user interface 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.  Where KCS helps connect people to content or knowledge for known issues, Intelligent Swarming helps connect people to people for new issues.  

 

The Consortium members have been working for some time to bring the concept of Intelligent Swarming to operational reality.  An increasing number of members have moved their organizations from an escalation-based model to a collaboration-based model. They are realizing amazing benefits.  For more information, see the Intelligent Swarming initiative on the Consortium web site. 

 

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. 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, or any responder, 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 on the next page)

    • 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 on the KCS Academy Resources page.)

  • 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. 

You must to post a comment.
Last modified
12:11, 18 Apr 2016

Tags

This page has no custom tags.

Classifications

This page has no classifications.