Home > KCS v6 Practices Guide > Section 2 The KCS Practices > The Evolve Loop > Practice 5: Content Health > Technique 5.4: Creating Evolve Loop Articles

Technique 5.4: Creating Evolve Loop Articles

Two Types of KCS Articles

Earlier we discussed the interdependent nature of the Solve Loop and Evolve Loop. Each loop generates knowledge by considering articles at different levels. To recap, Solve Loop articles are created and improved by knowledge workers in the role of responder, while they are resolving issues. At the time Solve Loop content is created, it is difficult to judge how important or valuable it may be, but if an issue is worth a response, it is worth capturing in the knowledge base for others to reuse and thereby contribute to the patterns that emerge in the Evolve Loop analysis.

 

Ideally, Solve Loop articles are developed just-in-time based on requestor demand. Solve Loop articles must adhere to the content standard so that the articles have a consistent structure and are findable and usable by the intended audience.

 

Evolve Loop articles are high-value articles. These articles are usually created by Knowledge Domain Experts based on patterns and trends in article reuse or the analysis of self-service activity. Evolve Loop content is high-value because it is derived from the patterns of reuse or the clustering of articles around a common theme or issue, or critical processes and procedures. Evolve Loop content generally represents a very small percentage of the total knowledge base.

 

The pattern analysis performed in the Evolve Loop also identifies opportunities for improvements in product functionality, processes, policies and documentation. By performing root cause analysis and aggregating symptom and reuse data, the Knowledge Domain Expert can assemble compelling data (business justifications) to drive changes based on the organizational experience.

 

Some examples of Evolve Loop content include:

  • Procedural articles: details on multi-step processes

  • Resolution paths—a collection of procedural articles that defines the optimal approach to resolving a generic symptom or executing a complex process (procedural or diagnostic). The design of resolution paths is not trivial; the Knowledge Domain Experts typically facilitate the design process. While this may seem overwhelming, we have never seen more than five of these generic symptoms in a knowledge domain.   

  • High-impact issues (ones that cause outages or pertain to new or strategic products)

  • Articles created to fill knowledge gaps: issues users are seeking resolutions to through self-service but not finding anything helpful. This is using self-service demand to identify the need for knowledge articles.

Article Patterns and Clusters

A primary goal of the Evolve Loop processes is to learn from the collection of activity and articles created and reused in the Solve Loop. This analysis promotes continuous improvement of the KCS system on many levels. In order to make sense of the thousands of articles that are typically created in the Solve Loop, it is helpful to consider the content in subsets or collections of related articles. We call these subsets of the knowledge base "knowledge domains."

 

Knowledge domains are virtual collections (not physical partitions) of the articles that relate to a product family or a technology or group of technologies. Knowledge domains are seldom about one product. They are not precise or absolute in their boundaries; knowledge domains often overlap. A knowledge domain is the collection of articles that makes sense to review for pattern and clustering analysis. Therefore, the purpose or intent of the analysis defines the collection of articles that are relevant.

 

For example, if we use Pareto analysis on reuse to identify opportunities for product improvements, the collection of articles that relate to the product family or technology is the knowledge domain. If we want to provide an account team with a profile of a customer's experience over the past year, the collection of articles that relate to a specific customer is the knowledge domain.

We see some predictable phenomena in looking at knowledge domains for product families or technologies:

  • The frequency distribution for the reuse of articles is always a power curve—the 80-20 rule applies to article reuse. In many organizations, up to 80% of articles will rarely or never be reused. Of the remaining 20%, some will be reused much more often than others.

  • Within a knowledge domain, users frequently experience failures in a limited number of ways, perhaps five to seven high-level generic symptom categories (for example: system is slow, can't connect to the internet, PC won't boot, cannot access my file)

  • Generic or common symptoms often have diverse causes—each of the five to seven common generic failure types has multiple possible causes and therefore different resolutions

  • Some common causes will show up in diverse and seemingly unrelated ways—a single cause will be experienced by users in very different ways

Methods for Prioritizing Root Cause Analysis

One of the goals for the Knowledge Domain Expert is to look for clusters of articles that have the same or similar causes or resolution. Commercially available data mining tools are proving to be quite effective because we can point them at specific fields in a collection of articles (a little bit of structure provides a lot of value) and they will tell us about the patterns and cluster that exist. The pattern clusters that emerge are based on the content of the articles, not a predefined set of categories.   

 

Another way to identify high-value content is to run an algorithm that measures the value of the KCS articles to the organization. A calculated value is based on attributes of both the KCS articles and the related cases. Things like frequency of use, severity, type of problem, impact of the problem, type of customer, and importance of the product can all be considered. The algorithms can become quite complex. For more on this see Assessing the Value of Articles in Technique 5.10. 


The Power of the Curve

Root cause and value analysis are complex and evolving areas where many Consortium members look to experts for assistance. There are great commonalities in content trends when we look across organizations. This is an area of considerable industry activity. Some technology vendors are delivering rich analytics with their KM tools. David Kay and Francoise Tourniaire's book, Collective Wisdom: Transforming Support with Knowledge provides some direction on this topic.

The Search for Common Symptoms

When we examine article reuse, we often find that a single symptom (or a small set of common symptoms) can emerge from multiple, diverse causes, each of which requires different resolutions. For example, "cannot connect to network" could mean anything from a hardware, network, software failure or...  user error. The symptom experienced by the customer is insufficient to identify the correct resolution. Additional information is required, possibly needing diagnostic steps to identify the distinguishing characteristics of the failure and environment in order to provide the correct resolution.

 

A diagnostic step can be captured as an article, and a collection of steps or articles linked together creates a "resolution path."  This approach is very powerful, because resolution paths are made up of articles (diagnostic steps or procedures) that can be reused as appropriate in multiple resolution paths. And, unlike diagnostic trees, where the knowledge worker has to start at the beginning and work through each step independent of what they already know about the situation, the article structure allows the knowledge worker to enter the diagnostic process based on what they know about the issue.

 

A frequency distribution showing reuse of articles is one way to identify common symptoms. The analysis of the heavily reused articles coupled with the Knowledge Domain Expert's knowledge about the domain brings to light the common or generic failure symptoms. The Knowledge Domain Experts then create the Evolve Loop articles that support the knowledge worker in determining the distinguishing characteristics that will point them to the correct resolution. While it is the responsibility of the Knowledge Domain Experts to do the analysis and create the Evolve Loop articles, it should not be done in isolation. The Knowledge Domain Experts should validate their observations and resolution paths with a cross-section of the knowledge workers who work in the domain.

 

First, the Knowledge Domain Expert identifies a cluster of Solve Loop articles that relate to a generic symptom. This identification must be done from the requestor's perspective; how they experience the issue is what counts. As we mentioned, for most domains, there are a limited number (five to seven) of generic symptoms. The Knowledge Domain Expert then looks to understand the process by which the distinguishing characteristics of the situation can be identified, defining the path to the article with the correct resolution for the situation. The Evolve Loop articles will describe the diagnostic steps through a collection of procedural articles that are linked together. The outcome of each step will dictate or point to the next appropriate step.

 

Each step in this diagnostic process is itself an article. The appropriate resolution path is dictated by the outcome of each step.  Computer programmers might think of this process as a series of if/then steps, and the procedural articles as reusable subroutines.


Evolve Loop Content

 

From an article structure view, the issue and environment statements include the distinguishing characteristics needed to take the next step. Resolution information describes how to do the procedure. Each possible outcome or result of the procedure will point the user to the appropriate next step in the process. Eventually, this sequence leads to an article that contains the resolution for the issue in the specific environment. 

 

 

 

The Search for Common Causes

Different users may experience a single problem in very different ways. Despite a common cause, users see diverse symptoms. This situation would be likely in a software environment, where different hardware and software combinations might cause the same application glitch to behave in different ways—poor performance in one case, but system crash in another. Situational variables might disguise the common cause.

Power Curve: Resolution Path

When a cluster is identified, the sum of the reuse counts and the value to the business for the collection of articles should be considered in prioritizing the issue. The Knowledge Domain Expert should also decide if the articles should be merged or linked. The key criteria to consider here is findability for the audience that the article serves. While merging the articles has many advantages for the ongoing evolution of the article and aligns with the "one article, one fix" concept, situations can exist where it makes sense to have multiple articles for the same issues, perhaps linked together.

 

If the issue/symptoms and environment are dramatically different, merging the articles would decrease findability for each respective environment. In this case, the articles should remain for each unique environment, but should be updated to be procedural. They should include ways to validate the situation, and the resolution field for each should point to an article that contains the resolution. As the resolution is used and improved, it only exists in one place.  

Evolve Loop Content

Plugging Content Gaps Identified From the Web

Another type of Evolve Loop content is articles that fill "content gaps" in our self-service model. The use of self-service introduces some interesting dynamics:

  • Users will visit a good web site to solve problems they would not have requested assistance for. Demand for information is far greater than the number of incidents that come into the support center.

  • When customers use self-service, there are issues they will not solve, but they will still not request assistance

  • Unsolved customer issues represent gaps in the knowledge base (an article does not exist) or findability issues (an article exists but the customer could not find it) 

     

Part of the Knowledge Domain Expert's responsibility is to identify content gaps on the web through search and browse analytics that that identify likely failures. If possible, they should create articles that resolve user issues that were pursued through self-service and not resolved. They could also refine existing articles based on how the user was searching for the answer—this improves the findability of existing articles.

 

The Evolve Loop content processes are critical for continuous learning, innovation, and improvement. They leverage the activity and articles used in the Solve Loop and create incremental value for the organization.

Viewing 1 of 1 comments: view all
This page states: "Another way to identify high-value content is to run an algorithm that measures the value of the KCS articles to the organization. A calculated value is based on attributes of both the KCS articles and the related cases. Things like frequency of use, severity, type of problem, impact of the problem, type of customer, and importance of the product can all be considered. The algorithms can become quite complex."

I remember this technique was proposed and (I assume) implemented by a consulting firm in the early days of KCS, but in my journeys recently, in the last 10 years or so, I haven't seen this technique being practiced. Perhaps the extra insight wasn't worth the reporting complexity, and the challenge of understanding the meaning of the calculated index. Are there KCS implementations that are doing this today, and if so, should we promote this more aggressively as a best practice? Or if has fallen off, should we deprecate it?
Posted 10:32, 27 May 2016
Viewing 1 of 1 comments: view all
You must to post a comment.
Last modified
13:28, 6 Jun 2016

Tags

This page has no custom tags.

Classifications

This page has no classifications.