Up Your KEDB Game

8 Tips for Using a KEDB to Up Your Problem Management Game

Whether your organization uses ITIL or not, a known error database, or KEDB, is a surefire way to both improve your problem management practice and empower your IT support teams and customers alike. To help, this blog contains eight tips for using a KEDB that will up your IT service management (ITSM) game. But first a little explanation on what a KEDB is.

What’s a KEDB?

A KEDB is a database that contains all known issues affecting your customers and IT environment. It describes the conditions in which these issues occur, how the issue manifests itself, and how to resolve the issue in the short term via a workaround. Where a workaround is anything that can reduce or remove the impact of an incident or problem for which a permanent resolution is not yet available.

This blog by @Joe_the_IT_Guy contains eight tips for using a Known Error Database (KEDB) that will up your #ITSM game. Share on X

Tip #1: Use the ITIL 4 “start where you are” guiding principle

Have you got your problems logged already? If you have a problem management practice in place already, then have a look at your active problem list. Do any of them already have workarounds or temporary fixes? Then have a look at related incident records, has anything been successfully tried to get the end user up and running again? This can all be shared with those in IT support roles via a KEDB.

Key details to include when capturing known errors and workarounds for the first time include:

  • The service affected
  • What the issue looks like from an end-user perspective
  • The steps needed to carry out the workaround.

Tip #2: Get a handle on recurring issues

Talk to your IT service desk personnel to find out which issues they see day-in-day-out. These are likely some of your biggest pain points, so look at what workarounds can be applied to save time, effort, and everyone’s sanity.

Examples of workarounds that can be applied at the first line of support include:

Tip #3: Aim to minimize, if not eliminate, duplication of effort and rework

Sometimes in IT, we spend so much time and effort trying to fix something that we hunker down and forget to talk to people. For example, how many times have you seen different technicians or teams trying to fix the same issue?

So, build a step into your resolution process whereby the person who fixed the issue pops a couple of lines summarizing what they did to restore service into the incident record. If it’s considered a known error too, then add it to the KEDB as a workaround. That way if the issue reoccurs the service desk analyst isn’t scrambling through pages of ticket updates trying to figure out what’s happened, or starting again from scratch, and can instead go straight to the workaround.

Tip #4: Work with the change control/management team

The change control (or change management) team is an important source of support for known errors. Think about it, how many times have we deployed some software into the live environment only for the IT service desk to be flooded with calls reporting bugs and defects?

So, get ahead of the game by being involved in your change and deployment practices. If you don’t attend the change advisory board (CAB), then get invited so you can understand the impact of planned changes and raise any concerns.

Sometimes a business decision will be made to deploy a release with known issues on the understanding that they’re fixed later. If this happens, get a list of the defects and how they behave from an end-user perspective and raise them as known errors. Send the list of known error defects to the IT service desk with details of any workarounds and the date of the next release. This way the service desk can get people up and running again and be able to give them a rough timeline for when their issue will be resolved permanently.

Tip #5: Promote the KEDB as a key way to restore service faster

Make sure that everyone on the IT service desk knows about and has access to your KEDB because speed is the name of the game when it comes to first and second-line support.

If an end user is calling the service desk either something’s broken or isn’t working as it should do, or they might need something covered by a service request to be able to do their job. In the case of an incident, the end user is trying to use a broken service. Having a related workaround in a KEDB with clear instructions on what the issue is and how to fix it will definitely get the end user working again quickly.

Make sure that everyone on the IT #servicedesk knows about and has access to your KEDB because speed is the name of the game when it comes to first and second-line support – @Joe_the_IT_Guy Share on X

Tip #6: Ensure that you make workarounds easily repeatable

When you create, or are provided with, a new workaround, ask another team member to peer review it to ensure that it makes sense and is easily usable. We all explain things slightly differently, but for a workaround to be effective (and valuable) it needs to be easy to understand and use, and maybe even easy to explain to the end user.

Here @Joe_the_IT_Guy shares eight tips for using your Known Error Database (KEDB) effectively. #ITSM #servicedesk Share on X

Tip #7: Look for continuous integration opportunities

Continuous integration is a development practice that requires all code to be created as a small unit of work that’s merged into a central repository at the end of each day. This ensures that the code is always in a deployable state and that the quality of the code improves from “does this work?” to “does this meet requirements in a user-friendly way?”

Continuous integration means that support documentation needs to be kept updated to make sure the technical notes match the service out in the live environment, that’s being used by customers. This doesn’t mean writing War and Peace though – one of the key facets of modern development is efficiency in all things. So, aim for short, concise notes detailing what’s changed. This way, if an error is found in the code, it’s easier to document in the KEDB and easier to put right.

Tip #8: Measure success

Measure the effectiveness of your KEDB by reporting on some basic outcomes. This will enable you to showcase the value added as well as ensuring that the KEDB is being used. Things to consider measuring include:

  • Increase in first-time fix rates
  • A decrease in overall resolution times
  • Increase in customer satisfaction
  • Percentage of problems with a documented workaround
  • Percentage of incidents resolved with a workaround.

So, that’s my eight tips for using your KEDB effectively. What would you add? Please let me know in the comments.


Posted by Joe the IT Guy

Joe the IT Guy

Native New Yorker. Loves everything IT-related (and hugs). Passionate blogger and Twitter addict. Oh...and resident IT Guy at SysAid Technologies (almost forgot the day job!).