View source for Known Error Database (KEDB)

A '''Known Error Database''', then, tracks all of the known errors within the IT’s jurisdiction, which is typically an entire system or even organization. Ideally, the KEDB includes:
*Descriptions of how/when the issue will appear, including a description of the incident from the user’s point of view
*Screenshots of the incident(s) and problem
*Text of error messages
*Workarounds (temporary solutions) that help the user handle the problem and return to productive work with minor to no delay
*Resolutions, if the incident and problem have occurred and previously been solved<ref>[https://www.bmc.com/blogs/known-error-database-an-introduction-to-kedbs/ Definition - What is Known Error Database (KEDB)? -BMC]</ref>


== KEDM Process<ref>[https://www.pluralsight.com/blog/it-ops/known-error-database-example KEDM Process -Pluralsight]</ref> ==
There are three streams where KEDB is leveraged:
*1. When an incident is resolved using temporary means, a known error record is created with the incident summary, description, symptoms and all the steps involved in resolving it. Suppose a user has reported that MS Outlook application crashes when emails start to download. The technical staff, in order to minimize the service outage, advised the customer to access webmail until the issue is resolved. The details of the incident, along with the symptoms and temporary resolution steps, are to be recorded in a new known error record.
*2. When an incident is reported, the support team refers to the KEDB first to check if a [[workaround]] exists in the database. If it does, they will refer to the known error record and follow the resolution steps involved. Suppose the fix provided is inaccurate, the support staff can recommend alternate resolution steps to ensure that KEDB is high on quality. Let's say that at another time and place, MS Outlook application starts to crash. The technical staff can refer to the KEDB to check what was done on previous occasions, and can recommend the workaround to the customer until a permanent solution is in place.
*3. If a permanent solution to a known error is identified and implemented, the incident must not happen anymore. So, the known error record is either taken out of the KEDB or archived with a different status. This is done to ensure that the database is optimized with only the known errors, and accessing records does not become cumbersome due to a high volume of known error records. While the user is accessing email service via webmail, the issue is being investigated to identify that a Bluetooth extension is causing the outlook to crash. The permanent solution is to disable the extension or even uninstall it. This solution is implemented not only on the Outlook that crashed, but on all the systems accessing Outlook, to ensure the same incident doesn't happen again. After implementing and testing the permanent solution, the known error record can either be archived with a pre-defined status or deleted.


[[File:KEDB Process.jpg|400px|KEDB Process]]<br />


== Where the KEDB fits into the Problem Management process<ref>[https://theitsmreview.com/2012/04/7-benefits-of-using-a-kedb/ Where the KEDB fits into the Problem Management process -The ITSM review]</ref> ==
The Known Error Database is a repository of information that describes all of the conditions in your IT systems that might result in an incident for your customers and users. As users report issues support engineers would follow the normal steps in the Incident Management process. Logging, Categorisation, Prioritisation. Soon after that they should be on the hunt for a resolution for the user. This is where the KEDB steps in. The engineer would interact with the KEDB in a very similar fashion to any Search engine or Knowledgebase. They search (using the “Known Error” field) and retrieve information to view the “Workaround” field.


== The KEDB Implementation<ref>[https://www.quickstart.com/blog/everything-you-need-to-know-about-known-error-database-kedb/ The KEDB Implementation -Quickstart]</ref> ==
When we talk about the KEDB, we are truly discussing the Problem Management database instead of a totally discrete store of information. In fact, a good implementation would have it arranged that way. There is balanced planning between Known Error and Problem, so it bodes well that your standard data representation of a Problem (with its number, task information, work notes, and so on) additionally holds the information you require for the KEDB. It isn't erroneous to execute this in an alternate manner—putting away the Problems and Known Errors in separate areas. However, our own inclination is to keep everything together. Known Error and Workaround are the two coins of a Problem.


== Benefits of Known Error Database (KEDB)<ref>[https://www.joetheitguy.com/5-reasons-why-your-organization-needs-a-known-error-database/ Benefits of Known Error Database (KEDB) -Joey the IT Guy]</ref> ==
Below are the reasons why introducing a KEDB will help your organization.
*Quicker Incident Resolution: With a KEDB, your IT service desk agents are able to resolve incidents quicker. Why? Because when a new incident is reported they can consult the KEDB to see if there is already a fix available.
This saves them from having to individually troubleshoot every incident that comes in. And if the incident is part of an already recorded known error, then the agent can immediately apply the fix. They can also advise the affected end user that this is a known issue and people are working to resolve it. This will also give your customers peace of mind, knowing that the problem will (hopefully) soon go away forever (particularly if they’ve experienced it multiple times already).
*Deliver Consistent Support: Having a KEDB for your service desk agents to check means that each one of them will be able to offer the same level of IT support. And because working on the IT service desk is sometimes an entry-level role, you’re highly likely to have agents with various levels of knowledge and skill. Here, a KEDB means that your newer staff members are able to offer the same level of support for such incidents because the fixes are documented for them to follow.
Inconsistent support from the IT service desk can be a big factor in low customer satisfaction (CSAT) scores, so it pays to find ways to tackle this.
*It’s Easier to Monitor and Prioritize Issues: When you have a KEDB you can link up each incident that comes into the desk related to the known error. This means that you’re able to monitor the reach of the problem which, in turn, can help you to prioritize which problems need to be fixed first. For instance, those that have a high number of incidents attached, and therefore impact, can be submitted for fixes sooner than those causing only a couple of calls to the desk.
*Incident Ticket Prevention
Sometimes the workarounds provided for a known error are easy to apply and end users are able to activate them themselves. When this happens, you can let your customers know that your IT teams are working on the issue but in the meantime, should they experience the problem, they can fix it themselves to prevent any disruption.
When your IT teams are already working on the fix you won’t need to worry about tracking the impact of the problem, so it’s better to prevent these calls from coming in in the first place whenever possible.
*Create Happy Customers (and Agents): Because you’re offering consistent support, applying quick fixes to reported incidents, and empowering end users by giving them the opportunity to fix their own issues, you’re likely to see improvements in your CSAT score.
Along with happier customers, your agents will be happier too because a KEDB can make their life so much easier. They don’t have to troubleshoot the same incidents over and over again, and they can provide a level of support that makes them feel good because they know they’re helping to deliver a great IT support service.


== See Also ==




== References ==
<references/>