Neven Zitek When I read Branimir’s article about Knowledge Management within ITIL (which I strongly recommend that you read if you haven’t already), Building a world of knowledge – ITIL Knowledge Management, one thing immediately came to my attention: “Technicians keep everything local, either on their laptops, in their mail inboxes or in their heads.” That statement couldn’t be truer. And it’s not just technicians – everyone has their own place where they keep important information, structured for their personal needs, and available only to themselves. I’ve highlighted keywords for you, and in case you missed them, here they are: structured and available. Please remember them.
It’s a riddle wrapped in a mystery
When implementing a Service Management System (SMS), it’s fairly easy to justify Incident Management implementation. Or Change Management, and/or Problem Management. They all represent cornerstones of service transition and operation and have measurable properties, which can be directly related to service status, internal workload, and customer satisfaction. It’s the general opinion that with the Knowledge Management module you can’t do that.
While Knowledge Management is extremely important in running a successful service organization, it gets neglected for many reasons, and its importance is obscured by its complexity and entanglement with every single piece of service management framework. Within this article, I’ll try to give you pointers on how to implement a successful Service Knowledge Management System (SKMS).
Start small, think big
As in implementing Service Management practices, such as ITIL, the vast majority of organizations start with implementing Incident Management first. It’s the perfect place to start implementing Knowledge Management as well. Operational staff gathers and produces an enormous amount of data every day.
Figure 1 – DIKW model
But, the data they gather is not useful in and of itself, and operational staff usually don’t understand the importance of the data they handle, or in rare cases they do – they record it in their own, personal notebooks.
In order to make use of that data, you should understand the DIKW model shown in Figure 1; data is just a set of facts, information is data within context, knowledge is information processed by human experience and understanding, and wisdom is when you can make informed decisions.
Based on this information, now we know that Incident Management is a great place for data and even information gathering. This information has to be collected in an organized and structured manner, processed before it can be processed. This is where Problem Management kicks in (you may want to read some of our great articles about it: ITIL Problem Management: getting rid of problems, ITIL and ISO 20000 Problem Management – Organizing for problem resolution, and ITIL Reactive and Proactive Problem Management: two sides of the same coin).
Problem Management takes information about past incidents and events, vendor information, industry best practices and other information, and uses it in order to find and eliminate incident root causes, or to implement workarounds. This process transforms data into information, and then into knowledge, which is only the first step. Now we need to pass back that knowledge to the ones who need it, in order to make use of it. We need to make it available.
While this is just an example, please understand that the Known Error Database (KEDB) produced by Problem Management is not the Service Knowledge Management System (SKMS) itself, but only a part of it.
Tips, tricks and benefits
Knowledge Management implementation justification and benefits. Just as Incident Management is a great place for data/information gathering, they are the ones who will reap great benefits from stored knowledge. For example, if the above-mentioned Problem Management discovers a new and improved workaround to common issues, Incident Management will be aware and use that knowledge to improve incident resolution times, which is a measurable property – directly related with Knowledge Management.
If Change Management information regarding new releases is available to the incident resolution team (Service Desk), they will be able to identify and escalate incoming incidents to the proper support levels much faster than usual, again improving resolution times, and customer satisfaction.
With SKMS in place, organizations will not lose knowledge if employees are unavailable because of vacation, sick leave, or even when they leave the company. The risk of “rediscovering knowledge” is reduced to a minimum, if not eliminated completely.
Where to store it? Almost every Service Management System has some form of Knowledge Management module or Service Knowledge Management System (SKMS) implemented, so that could be a great place for storing Customer Information, Known Error Database (KEDB), Service Level Agreements (SLA), documented policies, processes, instructions, manuals, and other useful information that affects daily operations.
You could also use web-based portals (such as a wiki) to store and manage information that Incident Management (or anyone else) can use, as they are easy to set up and maintain. I’d always suggest having a “hard copy” of information stored in web pages, in the form of office documents, for several reasons: documents can be stored locally in case the web front-end is unavailable, they can be archived, and they can be printed for use in off-the-grid situations (such as emergency situations).
Wherever and whatever you store in your KMDB, it’s important that it is searchable, well structured, and available to those who need it.
“Knowledge is power, ignorance is bliss.”
When you don’t preserve knowledge within your organization, you are at risk of falling into an endless loop of rediscovering the same thing, losing time on finding basic stuff, or even being unable to find it. It’s important that you get out of that loop to avoid the risk of going insane.
The definition of insanity is doing the same thing over and over and expecting different results. – Albert Einstein
