Within the culture of KCS, people take responsibility for what they see in the knowledge base; they follow the simple rule of "flag it or fix it." Licensed users can clean up minor problems in the moment, or add information that enriches and evolves the KCS article. KCS articles that are flagged need to trigger a workflow that will get the attention of a subject matter expert. These modifications, based on real usage (demand), lead to continuous, ongoing knowledge base improvement.
In the act of searching, we should:
Use It—leverage and link an existing KCS article to resolve an incident.
Flag It— if we are not licensed or confident, we should add comments to the article (Rework or Technical Review states are one way to flag an article) so that an authorized person can fix it.
Fix It— modify an existing KCS article if we are licensed and confident.
Add It— create a new KCS article if one does not already exist.
The ability to associate incidents with the KCS article that resolves the issue is a critical element of the KCS methodology. The data generated by the association is necessary for many of the Evolve Loop analysis activities. For example, calculating the participation rate for individuals and teams or calculating reuse and enabling the new vs. known analysis are all based on the association between incidents and articles. The association of articles to incidents is most often done by creating a link from the incident and the article and from the article to the incident. Hence the term linking has become part of the KCS vocabulary. Organizations that cannot associate incidents with articles or link them are at a severe disadvantage.
As search engine technology has improved over the past few years many organizations are now able to index and search multiple repositories with a variety of different types of content. In this environment linking an incident to the content that resolves the issue is legitimate if the following criteria is met:
The specific resolution or answer (a sentence or a paragraph) is findable by the search engine
The information is captured in a maintained repository or database
It is accessible by the audience being served (could be internal or external users)
The content is in the context of the audience that is looking for it (they can find it, using their words and phrases, and they can use it or understand it)
When these criteria are met the links to other types of content are satisfying the fundamental goal of KCS; create findable, usable knowledge for a specific audience. So, in this situation creating a KCS article adds little or no value. Links to other types of content that satisfy the above criteria should be counted in reuse counts, participation rates and the new vs. known analysis.
When is a new KCS article justified? KCS article creation should occur when a unique resolution is required to address an issue within a specific environment and such an article has not yet been documented in the knowledge base or in another searchable, maintained repository of questions and answers in the customers context (see "Linking"). While the content standard should provide some guiding criteria, as with many things in the KCS model this decision requires judgment.
Generally, there should be one KCS article per problem (unique resolution and cause). However, this is not an absolute rule, and the criteria should be developed based on experience in the environment. KCS articles will evolve through use and sometimes merge or split as additional experience emerges. A single KCS article may include different ways to solve a problem. For example, the fix or resolution may include a number of ways to deal with the issue such as temporary work-around to the problem as well as a formal fix or code update.
As we will see later, we augment Solve Loop "in the workflow" articles with Evolve Loop articles that describe the diagnostic processes that can guide users through a number of procedural KCS articles that will get them to the correct article to solve the issue. This is very helpful in dealing with issues that have very generic symptoms and multiple possible causes.
Even though a newly created KCS article, or Work-in-Progress (WIP), may not contain a resolution, it represents valuable knowledge. Work-in-Progress articles in the knowledge base enable others in the organization to discover that a problem is being worked. This process helps eliminate duplicate effort—two Analysts unknowingly solving the same problem in parallel. Awareness enables collaboration.
Support Analysts should not be expected or try to assess the future value of a KCS article. If the problem or question is worth solving, it is worth saving. Our goal is to create a knowledge base that reflects the collective experience of the organization. The completeness of that experience then more accurately reflects, through patterns and trends, the customer experience. If we selectively ignore issues by not capturing them, the patterns over time are less valuable.
When creating new articles we should not attempt to extend the article to cover all possible situations that might occur. Instead, the article should resolve the issue raised by the customer. Then, if the article is reused, it should be modified or expanded based on customer demand. Over time, the problem statements in the article will describe the issue in as many ways as customers have experienced them.
A certain level of redundancy and diversity in a knowledge practice is healthy. Redundancy becomes a problem only when it adversely affects the findability and usability of the content. Some examples of acceptable redundancy include:
KCS articles for the same issue but for different target audiences. This can avoid confusion. Target audiences can be defined as an environment variable, thus requiring a separate issue with a different resolution.
KCS articles that capture wholly different experiences but have the same resolution and cause. Initially these articles will not show in a single search. But if these KCS articles are being used and modified over time, their problem statements will eventually have them show up in a single search, at which point they should be merged (updating and keeping the oldest). Having two articles with different issues with the same resolution does not necessarily mean there is redundancy. You must also consider the cause. It is possible to have the same resolution for two complete different issues. If the cause is different, then the issues are most likely unique and therefore no redundancy exists. When you find two articles that have different issues and the same resolution, the advice is to evaluate the articles to see if they are two different descriptions of the same problem. Both may just have different symptoms. In this case there is redundancy and the article should be merged. You may also find two articles with similar descriptions and different resolutions. Upon evaluation the issues and environment are the same, the cause is the same, however the resolutions provided are different. This is also redundancy. In this case the duplicate articles should be merged.
Duplicate articles are inevitable if the organization is truly practicing KCS. To some extent, duplicate articles are a necessary ingredient in a successful knowledge management practice. Duplicate articles become a problem when multiple articles with similar symptoms and the same resolution are showing up in response to a search.
There are two causes of duplicate articles. One is necessary and productive; the second is not.
The first is naturally dealt with in the KCS methodology. A customer 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 Support Analyst is not likely to find the existing article and will create a new one reflecting the customer's described experience (article B). If the issue is one that customers encounter often, others will search with a variety of symptoms and may find article A. They should update the symptoms to include the customer experience if it is not already in the article. Other Analysts handling this issue may find article B and should update the problem description appropriately. If these articles are being used often, over time they will eventually both show up in a search. The Support Analyst who first sees them both should merge articles A and B. If we are following the reuse is review practice and constantly updating the articles based on the customer experience, duplicates will evolve over time to the point where they are close enough to both be found in a search. That is the point at which we should merge them.
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. Lots of duplicate articles are typically a symptom of one or a combination of the following common violations:
Support Analysts are given a goal for article creation; this drives the behavior of creating rather than re-using
Support Analysts are not following the "search early, search often" and/or the "search before you save" practices 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 Analysts 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.
When duplicate articles are discovered they should be merged. Different KM tools have different ways of dealing with this but the best practice, based on the members' experience, proposes that the newer article (or articles) content and links be merged into the older article, and the newer articles are archived or deleted. Here are some of the key reasons to preserve the oldest article:
It is important to keep the metadata: information like the date this issue first occurred, its revision history and other important article attributes and history
We don't want to lose the links to the original incident and subsequent incidents
We want the reuse count to be based on the complete history of this article
It is typically less work; the older article is more likely to have a richer set of symptoms and environment statements