Projektmanagement & ITIL

Known Error Database (KEDB)

Overview

Die Known Error Database (KEDB) ist ein Datenbestand aus Known Error Records. Ein Known Error ist nach ITIL ein Problem, dessen Ursache gefunden wurde, für das aber noch keine dauerhafte Lösung umgesetzt ist. Der Datensatz enthält Symptome, Ursache, betroffene Systeme, den Workaround und den Status der endgültigen Behebung. Er bleibt aktiv, bis die Lösung umgesetzt ist oder das betroffene System außer Betrieb geht.

Die KEDB wird im Problem Management gepflegt und vor allem im Incident Management genutzt: Der Service Desk sucht bei einer neuen Störung zuerst nach einem passenden Known Error und wendet den dokumentierten Workaround an, statt neu zu analysieren. Zusätzlich hilft sie bei der Priorisierung von Changes, weil sichtbar wird, welche Fehler wie viele Incidents verursachen.

Abgrenzung: Die Knowledgebase ist das breitere System mit Anleitungen, FAQ und Betriebswissen, Knowledge Management der Prozess dahinter. Die KEDB ist ein eng umrissener Teil davon und enthält nur Fehler mit bekannter Ursache und offenem Fix. In vielen ITSM-Tools ist sie kein eigenes Produkt, sondern ein Datensatztyp oder Artikeltyp im Problem- oder Wissensmodul. Die CMDB beschreibt Configuration Items, Known Errors werden mit ihnen verknüpft.

How it works

Ein Known Error Record entsteht und endet in diesen Schritten:

  1. Problem Identification: Häufungen gleichartiger Incidents oder ein Major Incident führen zu einem Problem-Datensatz.
  2. Problem Control: Das Team analysiert die Ursache und dokumentiert einen Workaround. Sobald die Ursache bekannt ist, wird daraus ein Known Error Record.
  3. Nutzung: Service Desk und Second Level verknüpfen neue Incidents mit dem Known Error und wenden den Workaround an. Die Zahl der verknüpften Incidents zeigt die Dringlichkeit.
  4. Error Control: Die dauerhafte Lösung wird bewertet und meist über einen Change umgesetzt.
  5. Abschluss: Nach umgesetzter und getesteter Lösung wird der Datensatz geschlossen oder archiviert, damit die aktive KEDB übersichtlich bleibt.

Typische Felder: Fehlerbeschreibung und Symptome (in Anwendersprache, damit die Suche trifft), Ursache, Workaround mit Schritten, Auswirkung auf Systeme und Benutzer, betroffene Configuration Items, verknüpftes Problem und Change, Erfassungs- und Lösungsdatum.

Benefits

  • Schnellere Störungsbehebung: Der First Level löst bekannte Fehler direkt mit dem Workaround, statt sie weiterzuleiten, das senkt Bearbeitungszeit und MTTR.
  • Weniger Doppelarbeit: Die Analyse wird einmal gemacht und dokumentiert, statt bei jedem Ticket neu zu beginnen.
  • Bessere Priorisierung: Die Zahl verknüpfter Incidents pro Known Error zeigt, welche dauerhafte Lösung den größten Effekt hat.
  • Transparenz gegenüber Anwendern: Bekannte Fehler mit Workaround lassen sich im Self-Service-Portal veröffentlichen und vermeiden Tickets.

Practical example

Bei einem Ingenieurbüro mit 150 Mitarbeitenden stürzt nach einem Update der CAD-Software regelmäßig der Export ins PDF ab, der Hersteller hat einen Fix erst für das nächste Release angekündigt. Das IT-Team legt ein Problem an, findet als Ursache einen Konflikt mit einem Grafiktreiber und dokumentiert als Workaround einen alternativen Druckertreiber. Der Known Error wird im Ticket-System veröffentlicht und mit den betroffenen Arbeitsplätzen in der CMDB verknüpft. Der Service Desk löst neue Meldungen in wenigen Minuten, und mit dem Hersteller-Release wird der Datensatz über einen Change geschlossen.

Things to keep in mind

  • Formuliere Symptome so, wie Anwender sie melden (Fehlermeldungstext, Programmname), sonst findet der Service Desk den Eintrag nicht.
  • Halte die KEDB auf Fehler mit bekannter Ursache und offenem Fix begrenzt und archiviere gelöste Einträge, eine überfüllte Datenbank wird nicht mehr genutzt.
  • Kontrolliere Workarounds regelmäßig, vor allem nach Updates, denn ein veralteter Workaround kann neue Störungen auslösen.
  • Verknüpfe Incidents konsequent mit dem Known Error, nur so siehst Du, welche dauerhafte Lösung Vorrang hat.
  • Kennzeichne Workarounds mit Sicherheitsauswirkung (z. B. deaktivierte Schutzfunktion) und begrenze ihre Laufzeit.

Conclusion

Die KEDB ist das Bindeglied zwischen Problem und Incident Management und zahlt sich schon mit wenigen gut gepflegten Einträgen aus. Bilde sie in Deinem vorhandenen Ticket-System ab, statt ein separates Werkzeug einzuführen.

Further reading

Related articles