Known Error Database (KEDB)
Die Known Error Database (KEDB) ist die durchsuchbare Sammlung aller bekannten Probleme mit dokumentierten Workarounds. Sie ist das wichtigste Werkzeug, mit dem das 1st Level schnell auf wiederkehrende Vorfälle reagieren kann – und das wichtigste Ergebnis von Problem Management. Stell dir vor: ein Anwender ruft an, beschreibt ein Symptom. Der Agent tippt die wichtigsten Schlagworte in die KEDB-Suche und bekommt sofort den passenden Eintrag mit Workaround. Bearbeitungszeit: 30 Sekunden statt 30 Minuten. Wissen, das sonst nur in den Köpfen einzelner steckt, wird zur Resource des ganzen Teams. Diese Lektion zeigt, was in einen KEDB-Eintrag gehört, wie er sich vom Knowledge-Base-Artikel unterscheidet, wie der Lifecycle aussieht und welche Pflegeregeln entscheidend sind.
1) Was ist ein Known Error?
Ein Known Error ist ein Problem, dessen Ursache bekannt ist, aber für das es noch keine endgültige Lösung gibt – nur einen Workaround. Die KEDB sammelt diese Einträge.
| Begriff | Bedeutung |
|---|---|
| Incident | Konkrete Service-Störung – „Drucker druckt nicht" |
| Problem | Die zugrundeliegende Ursache, untersucht durch Problem Management |
| Known Error | Problem mit bekannter Ursache + dokumentiertem Workaround – aber ohne endgültige Lösung |
| Fixed | Known Error, dessen Ursache mittlerweile beseitigt wurde – Eintrag wird archiviert |
2) Anatomie eines KEDB-Eintrags
Ein guter KEDB-Eintrag ist für 1st-Level-Agents geschrieben – nicht für Spezialisten. Schlagwortreich, lösungsorientiert, ohne Vorwissen verständlich. So sieht ein typischer Eintrag aus:
Outlook.ost im %APPDATA%-Pfad.3) Suche in der KEDB – live
Tipp ein paar Schlagworte ein und sieh, wie sich die Treffer ändern. Klick auf einen Vorschlag, um es zu probieren:
4) KEDB-Lifecycle
Klick die Stati an, um den Lebenslauf eines Eintrags zu sehen:
5) KEDB vs. Knowledge Base – wichtige Abgrenzung
Häufige Verwechslung, die in Prüfungen unterscheidbar sein muss:
| KEDB | Knowledge Base | |
|---|---|---|
| Inhalt | Bekannte Fehler mit Workarounds | Allgemeines Wissen, Anleitungen, FAQ |
| Zielgruppe | Service-Desk-Agents (intern) | Agents + Endanwender (oft öffentlich) |
| Trigger | Ein konkreter Fehler/Bug ist aufgetreten | Wiederkehrende Frage oder Aufgabe |
| Typische Beispiele | „Bug in Treiber X – Workaround Y" | „So legen Sie Mailregeln in Outlook an" |
| Lebensdauer | Bis Bug behoben ist | Bis Verfahren sich ändert |
| Owner | Problem Manager | Knowledge Manager |
Faustregel: KEDB beantwortet „Warum funktioniert das nicht?", Knowledge Base beantwortet „Wie mache ich X?".
6) Pflege-Regeln für eine lebende KEDB
- Pflicht-Review alle 3-6 Monate. Jeder Eintrag muss regelmäßig auf Aktualität geprüft werden. Veraltete Workarounds sind schlimmer als keine.
- Verbundene Incidents zählen. Wenn ein Eintrag seit 12 Monaten keine neuen verbundenen Incidents hat, ist die Ursache vermutlich weg – Eintrag prüfen und ggf. archivieren.
- Schlagworte aus Anwender-Sprache. Was würde der User am Telefon sagen? „Outlook startet nicht" – nicht „Mail-Client zeigt Profile-Corruption-Fehler". Endnutzer-Begriffe verwenden.
- Workaround validiert. Vor Veröffentlichung muss der Workaround auf einem zweiten System getestet sein – nicht nur „hat beim Originalsystem funktioniert".
- Klare Verantwortlichkeit. Jeder Eintrag hat einen Owner. Wenn der Owner geht, wird die Zuständigkeit übergeben.
- Suche oft trainieren. 1st-Level-Agents sollen die KEDB als erstes öffnen, nicht zuletzt. Das geht nur, wenn sie das Werkzeug kennen und vertrauen.
7) Antipatterns
- „Wir haben eine KEDB, aber niemand schaut rein." Klassischer Fall. Lösung: in Schulungen einbauen, Suchhäufigkeit messen, schlechte Sucherlebnisse aufdecken.
- Einträge nur für Spezialisten verständlich. Eintrag voller Fachjargon → 1st Level versteht ihn nicht → unbenutzbar. Lösung: Verständlichkeitsprüfung durch echte 1st-Level-Agents.
- Workarounds, die längst nicht mehr funktionieren. Patch behoben, aber KEDB-Eintrag noch aktiv. Agent versucht Workaround, der mehr Schaden anrichtet. Lösung: Lifecycle-Disziplin.
- Doppelte Einträge. Drei Einträge zum gleichen Problem, jeder etwas anders. Lösung: Pflegevorschriften, Suche vor Anlegen.
- Geheim-KEDB pro Team. Netzwerk-Team hat seine Notizen, DB-Team seine, niemand sieht die anderen. Lösung: ein zentrales System.
Zusammenfassung
Die KEDB sammelt Known Errors – Probleme mit bekannter Ursache und dokumentiertem Workaround. Sie ist das Werkzeug, mit dem 1st Level wiederkehrende Vorfälle in Sekunden statt Minuten löst. Pflichtfelder eines Eintrags: ID, Titel, Status, Schlagworte, betroffene CIs, Symptome, Ursache, Workaround, endgültige Lösung (geplant). Lifecycle: Draft → Active KE → RFC offen → Fixed → Archiv. Abgrenzung: KEDB = bekannte Fehler mit Workaround (für Agents), Knowledge Base = allgemeines Wissen (oft auch für Endanwender). Pflegeregeln: regelmäßiges Review (3-6 Mon.), Anwender-Sprache in Schlagworten, validierte Workarounds, klare Owner. Antipatterns: KEDB existiert aber wird nicht genutzt, zu fachlich geschriebene Einträge, veraltete Workarounds, doppelte Einträge, Insel-KEDBs pro Team. Direktes Bindeglied zwischen Incident und Problem Management.
Verwandte Lektionen: Problem Management · Knowledge Base · Incident Management · und mehrWeitere relevante LektionenLevel SupportChange ManagementService DeskTicketsystemeCMDBContinual ImprovementPatch-Management