Confusion between Knowledge Management Database and Known Error Database

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.

Related posts

A Very Brief Introduction of ITIL V3 Lifecycle Phases

Abhinav Kaiser

Survey : SMBs don’t Believe ITIL is Beneficial in Support

Abhinav Kaiser

ITIL V2 to be Withdrawn Starting from June 2010

Abhinav Kaiser

List of ITIL 4 Practices

Abhinav Kaiser

Why must Organizations Implement ITIL? (Benefits of ITIL) – Part 1

Abhinav Kaiser

Mother of all IT Sins: Not Proofreading

Abhinav Kaiser

1 comment

Robert Russell March 11, 2021 at 3:21 AM

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.)


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.