Home > Retired: KCS Practices Guide v5.3 > Section 2 KCS Practices and Techniques > The Solve Loop > Practice 3: Reuse > Technique 3: Linking

Technique 3: Linking

Referencing and Linking to Other Information Sources

No single content resource can hold all knowledge needed to solve all issues. A rule of thumb when creating a KCS article is to keep it to one page and insert hyperlinks to other KCS articles, specific sections of online documents (product manuals, diagnostic guides), or bug reports as appropriate. The KCS article can act as a context-sensitive index to the other resources. This approach eliminates redundancy and the need to maintain information in several different places.

 

Use of links to reference documentation in KCS articles allows more experienced users to move quickly through the content and at the same time enables less experienced users to understand and implement a complex resolution.

 

Best practice when we have multiple data sources is to provide a unified search engine. Preferences can be set in most search tools to prioritize data sources, so that the current knowledge base and preferred secondary resources are searched first. It can also be helpful to allow the Support Analyst the option of selecting the sources they wish to search.

Thoughts on Linking

The ability to associate an incident 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 linking 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.

Linking an incident to an existing KCS article

If a KCS article with a relevant resolution is found, it should be reused and linked to the incident. The existing article should be updated (improved) with any additional symptoms or relevant environment information.

 

If a relevant article is not found in the knowledge base, a new article should be created. Ideally we already have a WIP article, which has the words and phrases we first used to search (searching is creating), or if the customer started the process in self-service the words and phrases they initially used to search. The WIP should also contain the notes we took during the problem-solving process.  Now all we have to do is update the resolution (and the cause, if appropriate), review the environment statements for relevance, and put the WIP into an appropriate state based on our confidence in the article and our license level.

Linking an incident to non-KCS content

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 non-knowledge base content that resolves the issue is legitimate if the following criteria are met:

  • The information is captured in a maintained repository or database

  • The specific resolution or answer (a sentence or a paragraph) is findable by the search engine

  • 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 and/or understand it)

     

When these criteria are met, the links to other types of content satisfy the fundamental goal of KCS: create findable, usable knowledge for a specific audience. So in this situation, creating a KCS article would add 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.

Linking Articles

Capture the resolution as provided to the customer as part of the incident

  • The Analyst should be able to establish a link between incidents and articles. Links should be implemented in such a way as to be available to other processes - e.g., reporting, search-ranking algorithms, and search results display. (In other words, a hyperlink embedded in a text field as part of an incident note would not satisfy this requirement.)

  • Analysts should be able to link and unlink articles

Many-to-many relationship between incidents and articles

  • The linking mechanism should allow for multiple articles to be linked to an incident. Optionally, links may be associated with a link type, for example, "resolved" vs. "referenced."

Persistent link and snapshot

  • The linking mechanism should allow an Analyst viewing the incident to see both the current state of any linked knowledge base article(s) and the content of the article at the time it was delivered to the customer.  (For example, by recording a snapshot of the solution at the time of delivery, or by including a link to a specific version of the article if the knowledge base supports version history.)

Slide05

Next up is the improve practice, even though we just gave an example of how capture, search, reuse and improve all play together. We are beginning to see that the Solve Loop practices are tightly related. In talking about one practice or technique we cannot avoid discussing how it is related to the others.

Viewing 3 of 3 comments: view all
"Organizations that cannot associate incidents with articles or link them are at a severe disadvantage."

A more detailed article on how to enable this from a technical standpoint would be a good link at this point.
Posted 10:54, 14 Sep 2014
I agree with the comment above :-)
Posted 06:56, 15 May 2015
So, 2 types of linking discussed here: 1) linking an article to other articles/documents/content (I think of this as "pointing to") and 2) linking articles and incidents together (I think of this as linking). Agree both are important. When wanting to link an incident to a document the analyst can't edit, it's best to create an article and have that article link to (point to) the other document. The reason for this is so that the article can act as a "wrapper" for the document, and be updated with additional customer context for findability purposes, and to act as a pointer to where in the document the useful bit of information is. Cardinal rule: Don't send readers on a wild goose chase. (instead escort them to where they need to go)

In terms of linking an incident to an article, I find that a URL, or article id number placed by the system (not user entered freeform information) in a dedicated field in the incident PLUS placing a URL or incident id number (again not freeform user entered text) in a dedicated field in the article is best. Why the double linking? It's really just a way to take the most advantage of the incident tracking system's and the knowledge base system's reporting capabilities. Sometimes what you can't get out of one system's reports, you can get out of the other's. And it adds a bit of redundancy - if one system is lost, the linking information can be recovered from the other. In any circumstance, from a user perspective they should just have to click a "link" button once, and both systems fields are updated.
Posted 11:48, 18 Feb 2016
Viewing 3 of 3 comments: view all
You must to post a comment.
Last modified
12:44, 15 Oct 2013

Tags

This page has no custom tags.

Classifications

This page has no classifications.