What is ITIL 4 Knowledge Management and how it works

The Problem with Knowledge Management
What is Knowledge Management according to ITIL 4?
The Knowledge Base as a solid foundation
- Why do you need a Knowledge Base?
How to build a functioning Knowledge Base?
Conclusion

knowledge management practice itil 4 base service training value insights switzerland

Oh, what an amazing topic for a rainy Sunday afternoon, where you have nothing better left to do…

Because quite often this is how Knowledge Management is seen in companies. So today, I am going to dig a little deeper into this neglected practice and I will try to explain why it is important and how to start on the right foot with it.

Ladies and gentleman, welcome to my interpretation of the famous and often underestimated practice of Knowledge Management.

The Problem with Knowledge Management

More often than not, Knowledge Management is seen as a secondary or even tertiary discipline within organizations. And honestly, I can somehow understand that if I try to put myself in the shoes of a company who is trying to standardize their Service Management practices.

I invite you to do the same for a moment. So, you are an external ITSM consultant (or even an ITIL 4 trainer like myself) and the company tells you that they want to formalize their ways of working while adopting best practice methodologies like ITIL 4. You have tons of experience, oceans of ideas and the energy to change the world 🙂 and you start telling the company that they should changes this and that and another thing and “How about the Service Desk?” or “What are we going to do about the burning SLAs?”…. so the company (and their internal IT managers) are totally overwhelmed and a bit nervous because you just pointed out a quite long list of things they have done wrong (and let’s be honest, nobody likes that).

So, a better approach is to gain an understanding of the most burning issues the organization has. Thanks to my fortune-telling crystal sphere, I can tell you that most of the times these are going to be Incident Management, Service Request Management and how the Service Desk can reduce customer dissatisfaction.

And let’s face it, Knowledge Management does not really seem to be the best candidate to alleviate these issues. But what if I told you that it could actually have a much larger effect than anticipated at the first look?

What is Knowledge Management according to ITIL 4?

AXELOS has defined the Knowledge Management practice as follows:

The purpose of the Knowledge Management practice is to maintain and improve the effective, efficient and convenient use of information and knowledge across the organization.

As you can see, the definition tells us that this is not only restricted to IT (it is kind of important to note this), but in this article, we will mainly look on the sunny…I mean IT-side of things.

So, Knowledge Management is about sharing knowledge within the organization. To do so we need to find the knowledge holders, the appropriate knowledge recipients and the right channels for distribution. Because simply creating a document, putting it on a shared drive and pointing people there is not gonna be the best solution (speaking out of experience here, and I bet you also have similar experiences).

The Knowledge Base as a solid foundation

Okay, the title here might be a bit misleading, because it suggest that there should be only one Knowledge Base in an organization. This might actually not be bad, but we must ask the question if it makes sense. For a smaller company, this might be totally fine, but for a large corporation it might quickly become a monster and it might make sense to have separate KBs per department or org. unit.

So we can think of the Knowledge Base as a tool helping us to store and categorize information and knowledge, making it available to those who need to access it (so there are some aspects of Access Management as well).

More often than not, modern ITSM Ticketing Tools have this functionality already included in their portfolio. Ideally, it would have integrations to the end user self-service portal, so users can search for how-to articles, and it would have integrations to Incident and Service Request tickets so agents can connect specific knowledge articles to specific tickets. It could be configured to prefill the tickets with predefined text if a knowledge article is assigned to a ticket, saving the agent some documentation time.

Why do you need a Knowledge Base?

Less calls to the Service Desk / less tickets, as the end users can access how-to articles to solve their most common issues
Less workload on expert teams, as the Service Desk can resolve more issues thanks to the articles created by the experts
Higher user satisfaction due to more issues resolved by the Service Desk on first contact
Higher Service Desk staff satisfaction, as they can do more and are less “catch-and-dispatch” only
Lower danger of burning SLAs due to the fact that Service Desks can resolve more and need to rely less on backend teams

How to build a functioning Knowledge Base?

The Knowledge Base is a living and changing place. It is never really finished, as the knowledge to be documented is virtually endless. It evolves over time, so we need to consider feedback from users, statistics on usage and changes in technology and processes. But let’s see the basics you should follow to successfully build a first version of your Knowledge Base.

Step 1 – The Foundation

We should start by gathering actual data from our Incident and Service Request tickets. The categorizations, to be precise. Sure, this only works if we have implemented some common categories before and if we have reporting capabilities. I assume that this should not be an issue because every ticketing system has predefined ticket categories and pre-built reports.

Step 2 – The End User

pareto principle 80 20 effort result value insights agile training coaching knowledge management

Our aim is to find out what the most common issues / service requests are that are raised by our end users. Once we got this, we should apply the Pareto Principle, meaning we should concentrate on the top 20% most common cases instead of creating knowledge articles for everything, because the 20% would cover around 80% of all calls to the Service Desk. You know…less is more in this case.

These user-centered knowledge articles need to be written in a user-friendly language and manner, as otherwise they would not be utilized and all the effort was for nothing. It might even make sense to test the articles with some end users.

Once articles are ready, they should be released into the part of the Knowledge Base, which is available to the end users, ideally through the self-service portal on the company intranet. The publication should happen incrementally, as it usually does not make any sense to wait for a number of articles to be completed before they are release. We are following the ITIL 4 Guiding Principles “Start where you are” and “Progress iteratively with feedback” 🙂

Step 3 – The IT users

Another part of the knowledge base is available to the IT users. This includes mostly the Service Desk but also any other IT function that is depending on the knowledge of others. To increase the resolution rate of individual groups, we should ask the knowledge holders (which are often more senior or expert teams) to create knowledge articles for the most common cases they receive. And again, the Pareto Principle should be applied.

Often senior teams can be very reluctant. “We don’t have time for that” or “What does it bring us?” are common things we might hear. But we can remind them, that the more stuff is resolved by the Service Desk or less senior groups, the more time our experts will have for other activities like development or projects.

The ultimate goal is to increase the First Call Resolution rate on the Service Desk as much as possible in an economical manner.

Step 4 – The Knowledge Centered Support (KCS)

KCS is a methodology, which centers the delivery of services and products around the knowledge needed for it. It tells us that documentation should be a by-product of handling cases and solving issues, but it also makes sure that the knowledge is relevant. That is done by ensuring that documentation is “living”, meaning that it is based on demand and usage. So, in other words, only knowledge articles that are really used should be kept “alive” and updated. The rest shall be removed, as keeping those updated is only overhead work.

During my time on the Service Desk, we used an internally developed knowledge base, which had an integration to our ticketing system. In the tickets we created, we had a specific field for the knowledge article ID. If we entered an ID, it would prefill the ticket with some text. If we did not find any relevant article, we entered “00000” as the ID. Later the knowledge admins would pull a report on the article usage. The least used articles were removed every now-and-then and new articles were created if there have been some issues about the same topic where the tickets were marked with “00000”.

Conclusion

Knowledge Management is a neglected practice that can bring a tremendous value in form of customer satisfaction, green SLAs and happier IT staff when applied right.

Concentrating on the creation of knowledge articles for the most common issues and inquiries helps the users and IT stuff tremendously by reducing unnecessary workload.

Some effort needs to but put into grooming our Knowledge Base, but a good starting point is to analyze usage data and remove or adjust articles that are not used often or are downvoted.