My post today is all about Knowledge base content, and how you can make a start creating your own.
First of all, I’ll offer a definition in my own words. What is a Knowledge base?
It’s a special kind of database for storing a workgroup's or organisation’s knowledge and expertise. Typically a Knowledge base contains articles that relate to fault fixing, how-to documents, user guides, white papers and so on. There is also usually a retrieval system (often a search engine) and way of classifying and grading content.
Knowledge bases offer all sorts of possibilities. In Incident Management, they offer the possibility of a genuine lift in first time fix rate. They offer new staff a chance to make a bigger contribution more quickly, whilst reducing dependence on a few key engineers.
A knowledge base is bit like motherhood and apple pie – it’s almost impossible not to be in favour of it. So why is it then that so few companies seem to have effective Knowledgebase content in place? I was at a social networking event recently (a breakfast event, more lively and interesting than I expected it to be) and ‘reducing dependence on key technical staff’ was one of the things that came up for discussion.
Knowledge base content was one of the solutions proposed, but only a couple of us there had knowledge base content we were trying to develop. One guy claimed ‘we’ve got a really effective Knowledge base’ to which I asked ‘How do you know it’s effective?’.
I will go on to answer my own question – most likely in a future post. In the meantime, I’ll stick with why it seems so few companies have Knowledge base content of their own.
The answer lies in the content word. Where does the content come from? Who writes it? How can we make sure it is accurate? How can we ensure that, as technology changes and moves on, so does our content? Where does quality come into things? How can I create content when we are all so busy? How can I get any kind of objective measure of the usefulness (or otherwise) of the content?
The bottom line is it’s all about content.
In preparing this article, it became clear that there was almost a ‘hierarchy’ of content. I’ll try to define each (as I’ve seen it used in IT Service Management) and describe some of it’s relative strengths and weaknesses.
In ITSM, this might be the most commonly-found – because we create it as part of the task of resolving customer Incidents. An Incident might consist of a fault description and (eventually) a resolution, which offers us a knowledge base article as a 'free' by-product.
- It’s free! (Well, almost).
- Tends to be focus on problem resolution, but that isn’t the only thing we do – or the only thing we want. We want to things correctly in the first place.
- Requires engineers to really take the time to explain what they did. The more time-consuming the write-up of resolution, the more likely the engineer is to gloss over something important.
I'll continue this thread in future posts.