I recently wrote a piece for Plural Sight on Known Error Database (KEDB). A KEDB is a repository that holds information about problems for which the root cause is known but a permanent solution doesn’t. Either the permanent solution does not exist or not implemented (yet).
It is common in the IT world to confuse the KEDB with the Knowledge Management database (KMDB). In fact, during one of my ITIL Lifecycle Service Operations training sessions, when I was on the topic of KEDB, one of my students claimed that her organization maintained a KEDB. I invited her onto the podium to explain how it worked in her organization and what it contained. She said – “The database contains policy documents, process documents, work instructions, technical manuals…” I clarified if this database had incident and resolution records which were not the case.
The database which she was referring to is the KMDB generally but ITIL has a different term for it – service knowledge management system (SKMS).
SKMS and KEDB are two different entities entirely. One cannot substitute the other although KEDB is a subset of SKMS. A KEDB strictly holds information about incidents and the incident resolution details.
I would argue that a Known Error does NOT require that a Root Cause has been found. With many IT organizations, vendors provide IT services to which the owning organization does not have visibility into the ‘black box’ that is the vendor system. To not document a Known Error record (which should include any valuable workaround instructions to support staff to restore production services) is withholding potentially invaluable information from the rest of the IT organization. I.e., “we’re not going to publish a means to recover because we don’t know why it’s happening” increases MTTRS and decreases MTBF.
As soon as a viable workaround has been developed, it should be published, via a KE, to the appropriate internal audiences (and/or external customers if they are a participant in the recovery process.)