Branimir Valentic “Reinventing the wheel.” – We often use this saying in everyday life, but did you know that it’s valid in IT Service Management, i.e. ITIL, as well? Let me recall a common situation: your users open an incident; you find a workaround or solution to the incident and resolve it. A few days (or months) later, the same situation happens again. And you (or some other technician) work hard to rediscover that (same) workaround again. Sometime later – it’s the same thing all over again. Waste of time, isn’t it? That’s why ITIL installed Known Error (KE).
Known Error – a definition
According to ITIL (Service Operation), a Known Error is “a problem that has a documented root cause and a workaround.” Documented means recorded. Records are common in ITIL. Just like, e.g., incident records, a Known Error exists in the form of a record and it is stored in the Known Error Database (KEDB). Such record exists throughout the lifecycle of a Known Error, which means that the Known Error is recorded from its creation until “retirement” (if the KE record will be ever deleted at all).
A Known Error record contains (these are general parameters common to all tools. I saw different tools with various additional content):
- status (e.g. “Archived” or “Recorded Problem” when Known Error is created, but root cause and workaround are not known yet)
- error description – content of this field is used for searching through Known Errors (e.g. by Service Desk staff or users) while searching for incident/problem resolution (e.g. “Printer does not print after sending a document to the printer. However, when printing a status page locally on the printer, everything works fine.”)
- root cause – entered by Incident/Problem Management staff (e.g. “Since printer does not accept documents to be printed from user computers, but prints out status report – a faulty network card is the cause of the problem.”)
- workaround – e.g. “Closest printer to the user should be set as default printer or user should be instructed which device to use until new printer is provided.”
Where does it belong?
Officially, Known Errors belong to Problem Management, but it’s not unusual for Service Desk to resolve an incident with a permanent solution, or find a workaround and create a Known Error record. The aim of the Problem Management is to find a root cause of one or more incidents. Problems are created because the root cause (the real cause of the incident) and its resolution need to be identified. The result of the problem investigation and diagnosis is identification of the root cause of the problem, and a workaround (temporary fix) or (final) resolution. These are valuable pieces of information and need to be recorded – so, a Known Error is created.
Timing – when to raise a Known Error record?
Certainly, this should be done when you identify the root cause and workaround. But, it can be recorded earlier, e.g. when the problem is recorded. This is done for informational purposes or to record every step of workaround creation. Also, if a Known Error is recorded and it takes a long time to find a workaround or resolve the problem, someone who faces the same problem has the information that someone is working on the problem resolution and which temporary workarounds are available. I saw some situations when an IT organization used the KEDB to provide users with a self-help tool (i.e. as a Knowledge Base) while creating a Known Error record tool, which Service Desk used to allow them to choose whether the Known Error record would be published publicly (honestly, not all information is useful to everyone, so sometimes some workarounds are not applicable for users). In such a way, IT provided users with knowledge where they could search for a solution before opening an incident (or, since the tool supported such functionality, to search through the KEDB while typing incidents’ subject or description).
ISO 20000 view
The Problem Management process is one of the processes required by ISO 20000 (remember, everything written down in ISO 20000-1 must be implemented). ISO 20000 requires that Known Errors shall be recorded and that up-to-date information on Known Errors (and problem resolution) is provided to the Incident and Service Request Management process (as opposed to ITIL, this is a single process in ISO 20000). So, if you are thinking about ISO 20000 implementation, it’s better to seriously considering building a KEDB.
Let’s make life easier.
It’s not necessary to have mighty tools for IT Service Management to provide KEDB functionality and gain the advantage of Known Errors. For some organizations (I noticed that some small organizations are doing it this way), a spreadsheet will be enough. It may not be a perfect solution, but it will do.
The bottom line is that everyone gains the advantage of the KEDB:
- Users – they have a tool to help themselves. Or, they can speed up incident resolution, e.g. they don’t have to wait until Service Desk staff resolves the incident, because Service Desk will most probably use the same database, i.e. KEDB.
- Service Desk, people involved in Incident Management or Problem Management – they have a body of knowledge, which saves a complete history of their work. They can do reporting, incident and problem resolution is much faster (no re-work and no unnecessary transfer of incidents to problem management)…
It’s a fact that Known Errors and the KEDB are usually forgotten. IT has a IT Service Management tool and uses recorded incidents and problems to look for workarounds or solutions. This is the hard way. The pace at which everything moves is looking for a simple, yet powerful solution. Known Errors and the KEDB are exactly that.
Click here to see a free preview of the Known Error Record template.
