Knowledge Management is a hot IT service management (ITSM) topic again.
Spurred on by the interest in social-enablement and self-help/service, many organizations are looking at how best to manage knowledge or, more specifically, how to make pertinent information available to people as and when they need it.
“Failing to plan is planning to fail” applies here
Organisations and their practitioners who are considering buying and implementing Knowledge Management technology should consider the following: What is the process trying to achieve?
The actual implementation of knowledge technology usually requires detailed and specific tasks and use of highly tailored and focussed content. Therefore it’s essential to be absolutely clear on what result is expected from this – e.g.
- Increased first level resolution for Service desk staff
- Fast induction/training of IT support staff
- Consistent/auditable use of policies and procedures across all IT support staff
- Faster resolution/turnaround time (across teams) using crowdsourcing/increasing visibility of issues
- Development of specific technical skills for specific staff and teams
- Development of broad skills and product knowledge for all staff and teams
- Reduction in incidents and problems being escalated to 2nd/3rd level teams
- Reduced cost of operating a service desk or IT support service
- Development of shared understanding and awareness of technical issues across a department
- Greater use of self-help or self-healing technology for IT staff and IT customers
- Improvement across various service management processes – e.g. request, incident, problem, change, asset and configuration, SLM
“Managing knowledge” is not a suitable end result to have in mind.
Turning tacit knowledge into explicit knowledge can be perilous
It can be easy to start writing knowledge articles (KAs) without a clear and consistent view of these goals – this can result in KAs that are useless, inappropriate, pitched at the wrong level, over or under engineered etc. Clarity on purpose is essential.
It’s essential to understand and clarify the format of how an article is written and by whom – so define some simple guidelines for completing the KA, as well as the basic format of the article. As an example this could include the need for some context (i.e. a map), some indication of testing errors, known errors as well as other (service catalog type) information about the service and users.
All of this will help the service desk analyst or support analyst to be able to quickly use the information as needed. The other side of this is simply that, if the analyst cannot quickly identify (1) if this is a useful piece of information, then (2) read and use it, then the whole process is wasted.
Think about who will consume the knowledge and how
Another key point is to use relevant and appropriate language – be clear on who it’s for, as well as when and how it will be consumed and used. It may be that more or less technical language can be used, depending on the consumer of the KA. Some contact centres use different text formats for different levels of staff, so that trainees are given scripts, whereas supervisors see bullet points only – this can be transferred to IT support with the same criteria. Also for some IT technical areas, it can be useful if access to records is controlled by level of training or qualification – i.e. so that only those with the right skills are able to use the content.
Knowledge, like bananas, has a finite shelf life
Ownership of articles and their approval, maintenance and removal is also important. The role of Knowledge administrator or even Problem Manager does not imply that that person will provide all the input to articles, so a clear and effective approval and maintenance process is vital. Ideally this can be driven via a tool where alerts are sent to relevant approvers/owners regarding the need to approve or review an article based on set time periods etc.
The value of knowledge is not in its creation but in its consumption
Finally, and most importantly, any knowledge system is only of value if it’s used and used effectively. It’s not good enough to simply set up a series of records and expect them to be used. The only way to understand what is and isn’t useful is to track this constantly. Measuring the use and success of articles is a key element of this process and should help to drive improvement, effectiveness and relevance.
Sometimes the most basic records (such as lists) can be the most used and useful documents, whereas elegantly crafted pieces may lie unused and unread – the success of your knowledge system will rely heavily on being able to see what is working and to then work on improving the KAs that are not.
Overall it should be accepted that Knowledge Management is a permanent ‘work in progress’ which will never be completed. The success of this depends on clearly understanding the outcomes the systems is expected to achieve, in addition to knowing the audience that the articles are aimed at. In addition, this requires a culture of constant review and improvement. Also remember that Knowledge Management doesn’t always put people in touch with information, sometimes it puts people in touch with people who have knowledge.
Finally, while tools can help to automate and deliver very specific content to specific situations – in fact Knowledge Management is difficult without them –the success of Knowledge Management in your organization will still depend more on cultural acceptance and shared goals than anything else.
Does this match with your experience of Knowledge Management? What would you advice be?