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

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

Abhinav Kaiser

ITIL 2011 on 29-Jul-2011

Abhinav Kaiser

ITIL Foundation: Types of Services

Abhinav Kaiser

What is PDSA?

Abhinav Kaiser

Comprehensive List of ITIL 2011 Abbreviations

Abhinav Kaiser

Importance of Maintaining Training Attendance Sheets in IT Organizations

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.