Known Error DataBase – KEDB – a repository that describes all of the conditions in your IT systems that might result in an incident for your customers.
Wondering – do you have a Known Error Database? And are you getting the maximum value out of it?
The concept of a KEDB is interesting because it is easy to see how it benefits end users. Also because it is dynamic and constantly updated. Most of all because it makes the job of the Servicedesk easier. It is true to say that an effective KEDB can both increase the quality and decrease the time for Incident resolution.
Problem Management and the Definition of “The System”
One of the aims of Problem Management is to identify and manage the root causes of Incidents. Once we have identified the causes we could decide to remove these problems to prevent further users being affected.
Obviously this might be a lengthy process – replacing a storage device that has an intermittent fault might take some scheduling. In the meantime Problem Managers should be investigating temporary resolutions or measures to reduce the impact of the Problem for users. This is known as the Workaround.
When talking about Problem Management it helps to have a good definition of “Your System”. There are many possible causes of Incidents that could affect your users including:
- Hardware components
- Software components
- Networks, connectivity, VPN
- Services – in-house and outsourced
- Policies, procedures and governance
- Security controls
- Documentation and Training materials
Any of these components could cause Incidents for a user. Consider the idea that incorrect or misleading documentation would cause an Incident. A user may rely on this documentation and make assumptions on how to use a service, discover they can’t and contact the Servicedesk.
This documentation component has caused an Incident and would be considered the root cause of the Problem
Where the KEDB fits into the Problem Management process
The Known Error Database is a repository of information that describes all of the conditions in your IT systems that might result in an incident for your customers and users.
As users report issues support engineers would follow the normal steps in the Incident Management process. Logging, Categorisation, Prioritisation. Soon after that they should be on the hunt for a resolution for the user.
This is where the KEDB steps in.
The engineer would interact with the KEDB in a very similar fashion to any Search engine or Knowledgebase. They search (using the “Known Error” field) and retrieve information to view the “Workaround” field.
The “Known Error”
The Known Error is a description of the Problem as seen from the users point of view. When users contact the Servicedesk for help they have a limited view of the entire scope of the root cause. We should use screenshot of error messages, as well as the text of the message to aid searching. We should also include accurate descriptions of the conditions that they have experienced. These are the types of things we should be describing in the Known Error field A good example of a Known Error would be:
When accessing the Timesheet application using Internet Explorer 6 users experience an error message when submitting the form.
The error message reads “Javascript exception at line 123”
The Known Error should be written in terms reflecting the customers experience of the Problem.
The “Workaround”
The Workaround is a set of steps that the Servicedesk engineer could take in order to either restore service to the user or provide temporary relief. A good example of a Workaround would be:
To workaround this issue add the timesheet application to the list of Trusted sites
1. Open Internet Explorer 2. Tools > Options > Security Settings [ etc etc ] The Known Error is a search key. A Workaround is what the engineer is hoping to find – a search result. Having a detailed Workaround, a set of technical actions the Servicedesk should take to help the user, has multiple benefits – some more obvious than others.