Building a knowledge base
ITIL defines a “knowledge management” process in Service Transition. That said, the concepts they describe are very high-level: the Data/Information/Knowledge/Wisdom (DIKW) model and the Service Knowledge Management System (SKMS) which is the idea of a system that can query and link across all all IT service management systems.
It can be hard to move from ITIL’s guidance into action for knowledge management. But in fact it’s quite easy to begin building a “knowledge base.” There are typically two types of knowledge base:
- Internal knowledge base (internal to the IT provider)
- External knowledge base (primarily targeting IT’s users)
The internal knowledge base may have more sensitive information, such as network topology diagrams, and the content may not be very good: “I think this system keeps time cards running” might be a statement in your internal knowledge base. There are two goals for your internal knowledge base: document things so people remember later what they did, and help IT people struggling with a complex issue get a lead on how to address the issue.
The external knowledge base will usually be edited, and of higher quality. It may be publicly available. The primary goal of the external knowledge base is to prevent users from having to wait for things: rather than submitting an incident, they may find a workaround themselves through the knowledge base.
In either case, knowledge bases need to be two things: searchable and accurate.
For searching, searches should be able to go through attachments and generally be “Google-like.” You may have to help search along by adding keywords to knowledge base entries.
For accuracy, if you have one inaccurate knowledge base entry it will tarnish the entire knowledge base. Good knowledge base products will help with periodic reviews of articles to ensure they are accurate. My favorite approach is to require an expiration date when the knowledge base entry is created; the author usually has a good guess about when someone would need to check and ensure the knowledge base entry is still good.
The simplest knowledge bases are wikis, Sharepoint or Google sites, or even a shared network drive. I recommend you identify a knowledge base owner, who can decide on the tool and how it’s configured, how articles are organized, and the permissions required for IT staff and end users.
Better knowledge bases will be integrated into your ITSM tool, and will let you create or associate incidents, problems, changes, and other records with knowledge base entries. The challenge with these more advanced tools is to continue to allow the flexibility of simpler tools such as Google sites, where you can upload vendor documentation as attachments and know they’ll turn up later.