ITSM and ITIL

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

ITIL 2011 Changes (Compared to ITIL V3)

Abhinav Kaiser

Video: Understanding Value through Examples

Abhinav Kaiser

Understanding ITIL Value through Utility and Warranty

Abhinav Kaiser

What is Process?

Abhinav Kaiser

The Spectacular History of ITIL

Abhinav Kaiser

KPIs for an Incident Manager

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

Reply

Leave a Comment

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