Home > KCS v6 Practices Guide > Section 2 The KCS Practices > The Solve Loop > Practice 4: Improve > Technique 4.2: Flag It or Fix It

Technique 4.2: Flag It or Fix It

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.

 

As we use the knowledge base, we are responsible for the quality and accuracy of the articles we interact with. If we see something we think is wrong or doesn't make sense, we need to take one of two actions: flag it or fix it.  The flag it or fix it concept applies to both content standard violations and technical accuracy or completeness. 

  • Fix it: if we are confident and we have a license level to make the update we fix it.
  • Flag it: if we are not confident or we don't have the license level to make the update we flag it. 

 

Fix It vs Create a New Article?

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 does not exist in the knowledge base or in another searchable, maintained repository (see Technique 3.3: Linking). While the content standard should provide some guiding criteria, as with many things in the KCS methodology, this decision requires judgment.

 

Generally, there should be one KCS article per resolution and cause.  Multiple resolutions for different environments and the same issue or symptom should not be in the same article. 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 is gained. Decisions should be based on what is best or clearest for the intended audience of the article: what will make the most sense to them. 

 

A single KCS article may include different approaches to resolving an issue with a single cause. For example, the fix or resolution may include a number of options for resolution, such as offering a temporary, manual work-around to the issue or a formal fix or code update. The options offered should include a description of the effort and implications for the user of each option. 

 

As we will see later, we augment Solve Loop "in the workflow" articles with Evolve Loop articles. Evolve Loop articles are high-value articles (based on reuse) or articles that describe diagnostic processes that can guide users through a number steps to get them to the best answer in an optimum way.  Each step in the process is an article and the outcome of each step directs the user to the next step.  These procedural articles are linked together to 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.  (See Content Health Technique 5.4: Creating Evolve Loop Articles.)

 

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 responders unknowingly solving the same problem in parallel.  Awareness also enables collaboration.

 

Responders should not be expected or try to assess the future value of a KCS article. If the issue is worth solving, it is worth saving. Our goal is to create a knowledge base that reflects the collective experience of everyone interacting with the knowledge. The completeness of that experience then more accurately reflects, through patterns and trends, the requestor's and responder's experiences.  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 requestor. Then, if the article is reused, it should be modified or expanded based on demand. Over time, the problem statements in the article will describe the issue in as many ways as requestors 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

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 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 the issue is one that people encounter often, others will search with a variety of symptoms and may find article A. They should update the symptoms to include the requestors experience if it is not already in the article. Other responders 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 responder who first sees them both should merge articles A and B.  If we are following the Reuse is Review technique 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:

  • 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" and/or the "search before you save" techniques 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.

Dealing with Duplicates: The Merge

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 Consortium 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

     

Viewing 2 of 2 comments: view all
We encourage people to be very circumspect in this use of "not confident" as a reason for flagging an article. We have too often seen organizations where flagging was perceived as easier than fixing, so people frequently used the "not confident" clause. If a licensed knowledge worker takes the request all the way to the response, he or she should be confident enough in the response to fix the article. If they request help, swarm, or collaborate, at the end they should have the knowledge to fix the article. It's only if they escalate a request with an attached article to someone with more expertise that they should flag the article...and then the eventual responder should make the appropriate fix.

As we like to say, "fixing should be a corner case:" not the normal way of doing business. Edited 16:11, 26 May 2016
Posted 16:11, 26 May 2016
From a discussion from the team meeting on 21 September 2016, we're proposing eliminating flagging from Candidates. (Readers still can flag.) Assuming versioning is available in the KB tool, we want Candidates to actually make the change but not publish the change.
Posted 15:33, 21 Sep 2016
Viewing 2 of 2 comments: view all
You must to post a comment.
Last modified
11:19, 27 Jan 2017

Tags

This page has no custom tags.

Classifications

This page has no classifications.