Technique 5.3: Knowledge Optimization

Creating Evolve Loop Articles

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.

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 created based on demand identified by patterns in Solve Loop content. 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.

For a thorough look at creating Evolve Loop articles and other Knowledge Domain Analysis activities, please visit the KCS v6 Knowledge Domain Analysis Reference Guide.

A major benefit of KCS is the opportunity to continuously improve the user's productivity and experience. KCS creates a system of persistent learning that is based on experience. Patterns and trends in the knowledge base can be used to drive documentation, product and service improvements. The Evolve Loop, a process of analysis and reflection, generates insight for the whole interaction network. The Knowledge Domain Expert extracts the learning from the patterns of information in the system.

Root Cause Analysis and Evolve Loop Content

Just as the healthcare industry has moved from reactive-only services to more proactive, preventive care over the last decade, many organizations have started to supplement reactive support with preventative actions—eliminating the source of issues in the first place. This has become possible as self-service has off-loaded responders' time, making them available to spend more time identifying issues for elimination. In order to find and diagnose problems, Knowledge Domain Experts perform root cause analysis. The patterns and trends of the articles in the knowledge base are the source of information for the analysis.

Knowledge articles are very transactional in nature. They represent what we have learned from an interaction. Looking at a collection of articles in a domain allows us to identify patterns and trends. We can assess the closeness or distance between articles. Articles that cluster around common themes or have similar causes represent opportunities to improve products or services. Removing the source of a frequent request is the ultimate level of success for an organization as it improves the customer productivity.

80% of the incident volume relates to 20% of the content in the knowledge base.

The Knowledge Domain Expert, product engineering, and product management must be part of the workflow and become engaged as patterns and trends in the Solve Loop content start to emerge. Through understanding the patterns and trends, we can pursue another form of intervention. Perhaps we can improve the documentation or create Evolve Loop articles - ones that merge the experience represented in many related KCS articles into a single KCS article.  (See KCS Roles and the Proficiency Model for a complete description of Knowledge Domain Expert responsibilities.)

Dealing with Duplicates

Duplicate articles are inevitable if the organization is truly practicing KCS.  A certain level of redundancy and diversity in a knowledge practice is healthy. Redundancy becomes a problem only when it adversely affects the discoverability and usability of the content.

Some examples of redundancy include:

• KCS articles for the same issue but for different target audiences or context (for example, novice vs expert). Target audiences can be defined as an environment variable, thus requiring a separate issue with a different resolution.
• Having two articles with different issues and the same resolution does not necessarily mean there is redundancy.  If the cause is different, then the issues are most likely unique and therefore no redundancy exists.
• Occasionally we may find two articles with similar descriptions and different resolutions.  If upon evaluation the issues, environment, and cause is the same, but the resolutions provided are different, this is redundancy, and these articles should be merged.    

There are two causes of duplicate articles. One is necessary and productive; the other is not.

The first is naturally dealt with in the KCS methodology.  A person encountering an issue may describe it in a totally different way or in a different environment than the way in which an existing article in the knowledge base is documented (article A). The responder is not likely to find the existing article and will create a new one reflecting the requestor's described experience (article B).  If we are following the Reuse is Review technique and constantly updating issue fields in the articles based on the requestor's experience, duplicates will evolve over time to the point where they will both show up in a single search. This is the point at which the responder should merge articles A and B.

The second cause of multiple articles with the same symptoms, environment, and resolution showing up in response to a search is a result of not following the KCS Practices. The existence of lots of duplicate articles is typically a symptom of one or a combination of the following common violations:

• Responders are given a goal for article creation; this drives the behavior of creating rather than re-using
• Responders are not following the "search early, search often" technique and as a result they create articles about issues that have already been solved and captured in the knowledge base
• The culture discourages editing articles that are believed to "belong" to others, so responders create duplicate articles instead (individual ownership of articles is death to successful knowledge management practices)

In any case, we need a way to deal with duplicate articles.

Archive Strategy

Priming the Knowledge Base with New Information

KCS is a demand-driven system; this means we should not add content in the absence of demand. Just as we should not try to anticipate the future value of an issue (if it is worth resolving, it's worth capturing), we should not create articles in anticipation of demand. This often causes concern and raises the question...  What if we know a situation will occur with the release of a new application or process?  If we know something will happen it is probably based on past experience, as in, the last time we did this, that happened.  Or, we know from the alpha and beta testing that users will experience these issues. That is demand-driven.

The general rule of "don't add articles until someone asks" raises a problem when introducing new products or processes.  How do we prime the knowledge base for them?

Perhaps the worst thing we can do is have development or engineering write articles about the new product or process: those articles will be in the context of how the product was designed and built, not how customers will use it, and not how it will break.  We can, in fact, capture information about new products in a useful context.  As a new product or process is going through alpha and beta testing or user acceptance testing, we should capture those experiences in the context of use. Creating articles that address the issues users are likely to encounter because of what we learned in the pre-release testing is the best way to seed the knowledge base.

During product beta cycles, we pay special attention to creating content in context of the beta testers experience.  Generally these pre-release articles should be in a Draft or Not Validated state (not visible to customers) until they have been reused to solve a customer issue, and, as a result, updated with the customer context and then made available externally for direct customer access through self-service.

KCS articles can also be pre-populated in the new knowledge base during the KCS training and pilot phase. Students bring their top ten current issues to training and use these issues to practice creating KCS articles. We structure and enter the knowledge according to the KCS content standard. As these KCS articles are reused in the request-resolution process, they should be modified to include the requestor's context.