Updated: Mar 15
I've built various types of documentation libraries over the years and with every new library project, I've implemented a new organization to make knowledge easier to categorize, save, and retrieve.
If you are familiar with ITIL, a Service Knowledge Database (SKDB) is very similar to the concept of a Service Knowledge Management System (SKMS). The biggest differences are overall knowledge organization, integration touchpoint processes, and a more granular separation of similar topics.
The SKDB is designed to ensure that you always have the information you need when you need it. The need for documented knowledge is becoming more and more critical and knowledge as a service is crucial to all organizations. In addition, a well thought out SKDB saves you time and money when integrated into your service delivery processes.
For example, let's assume that your company has a policy that requires technicians to complete an Incident Resolution Report (IRR) before closing out any tickets. These reports are stored in the Service Delivery Library (each one is categorized based on an incident type but that's for another article). Because its a policy, a process and/or procedure describes how to create an IRR. Now, let's assume that we have another process that requires technicians (or maybe dispatch) to check the SKDB for IRRs that are similar to the current incident being reported before beginning work on the ticket. If an IRR exists that helps you resolve an incident faster, then efficiency and customer satisfaction improves. It may have taken the tech that created the IRR 9 hours to resolve the incident the first time, but the tech using that IRR may have closed the ticket within minutes because of the harvested knowledge.
The previous diagram provides instances where integration touchpoints with your harvested knowledge results in a library maturity level that is sure to show its ROI on a daily basis.