1 0

Why Knowledge is the source of our Problems?

Knowledge articles are the source of our problems. As more incident tickets are attached to a knowledge article, the article rises in reuse and is then promoted to problem management for root cause analysis and issue elimination.

Most organizations that perform proactive problem management begin with ticket trend analysis. Support analysts create the incident tickets and categorize the tickets based on some defined taxonomy. This creates smaller collections of tickets. The tickets in a collection can be reviewed by a subject matter expert to identify if there are related incidents. When they discover a trend, they create a problem record and link the related incidents to the problem. While this analysis method has worked for many organizations, is can be labor intensive and prone to errors. The errors begin when the support analyst incorrectly categorizes the tickets.

The Knowledge Centered Service Management (KCSM) strategy creates problems from knowledge articles instead of from incidents. There are three common ways in which problems are created.

  1. High Knowledge Reuse
    The knowledge article includes a description of the issue and related symptoms. The article also includes the current known workaround used to restore service. As knowledge articles are reused in the support process, incident tickets are linked to the knowledge articles.  This increases the evidence that problems exist.
  2. Major Incidents
    Knowledge articles related to major incidents generate a need for problems to be opened for investigation. This action occurs in response to a major incident. The major incident has significant business impact and warrants problem investigation without evidence of reoccurring incidents.
  3. No Workaround Available
    When no known workaround is available and expertise is needed to determine the root cause and develop either a workaround or a fix, then the incident manager may request that a problem be opened from the related in-progress knowledge article. This type of action is known as reactive problem management. An in-progress knowledge article is an articles that has been created that documents the issue, but lacks a resolution.

Ticket trend analysis is replaced with an on-demand report. The problem manager can run a report of the most used knowledge articles to identify problems. This report could include all services or could be specific to a service.

Since knowledge articles are related to problems, we can quickly see in the report if a knowledge article is related to an existing problem and the state of the problem. Knowledge articles with high reuse likely warrant opening a new problem.

Problem Management Linkage to Knowledge Management

When the problem is created, the description of the problem comes from the knowledge article and is linked to the knowledge article. The problem may be linked to one or more knowledge articles, which are linked to incident tickets. Thus, a problem is linked to one or more incidents, through the knowledge articles. The information in the knowledge articles and the incident records is valuable to the problem management professional investigating the root cause.

When the cause is identified, the problem state changes to known error and the description of the cause is updated in the knowledge article. The test to validate the cause can also be added to the knowledge article to aid others in diagnosing future incidents. The creation or improvement of a workaround or fix is added to the knowledge article to aid others in resolving future incidents.

Linking Tickets to Knowledge

The ability to generate knowledge article usage reports is dependent on incident tickets being linked to knowledge articles. Article linking can occur under different circumstances.

  1. Knowledge Reuse
    During the incident management process, support analysts search the knowledge base to determine if incidents are known to the organization. When they find the appropriate article, they link the incident ticket to the article and use the knowledge in the article to resolve the incident.
  2. Resolution Matching
    The objective of resolution matching is to improve the findabilty of existing knowledge, instead of adding duplicate knowledge articles. When no article is found that resolve the incident, support analysts continue to diagnose and investigate the issue. Once they resolve the incident, they need to search the knowledge base again as a part of the ticket closing process. This time they search the knowledge base using the resolution description to see if articles with similar resolutions exists. If they find a match, then they can update the article based on the incident description to improve findability.  At that time, they link the incident ticket to the knowledge article.
  3. Article Creation
    Articles can be created from newly resolved incidents. At which time, the initial incident ticket is linked to the knowledge article.  Articles can also be created from new unresolved incidents.  In this case, the article development is in-progress and it captures the issue while the resolution is unknown. While the new article does not contain a resolution, it can be reused, or linked to, by other support analysts who are investigating related incidents.
  4. Ticket Resolution Analysis
    Achieving 100% compliance with the KCS practices is unlikely. Tickets will be closed without reusing knowledge and tickets will be closed lacking proper resolution documentation.  This is referred to as knowledge loss – someone resolved an issue and did not capture the knowledge for future reuse. While organizations strive for 100% compliance, there will still be some percentage of tickets closed without knowledge.  This is where ticket resolution analysis adds value. Ticket resolution analysis helps to minimize knowledge loss and identify knowledge gaps.

The first three options for linking tickets to knowledge articles are done in the support process by the support analysts. Ticket resolution analysis is done periodically by a subject matter expert, such as a problem management professional. The tickets being reviewed are only those that are not linked to a knowledge article with a resolution. The objective of the analysis is to review each ticket and see if it can be appropriately linked to an existing knowledge articles within that service. This improves the use count that aids in identifying problems. In KCSM, all tickets and knowledge articles are linked to services. This enables ticket resolution analysis by service. Thus, we can review the tickets by service to see if they should have been linked to knowledge articles within that service.

If an article should have been linked, then it is linked post ticket closure else no article was found and a knowledge gap is identified. If the ticket has sufficient information to create an article, then one can be created to fill the gap else knowledge loss has occurred and the ticket cannot be linked to an article. The new articles created to fill the gap are available for future reuse in the support process.

The higher the percentage of tickets linked properly to knowledge articles, the better the organization can identify problems and ultimate eliminate them from the environment. This statement has two dependences. The first measures the activity of linking. This metric focus on process compliance. Are people linking tickets to knowledge articles. The second dependency needs to focus on the quality of the data. Are tickets linked to knowledge articles properly? The link quality metrics is measured through random sampling of tickets to determine if the proper article was linked to the ticket. This is likely a check done during the quality assurance process known as ticket monitoring or incident monitoring.

Identify problems in your environment using the knowledge reuse and not ticket trend analysis.

Related Posts


Leave your comment