# 7.3 Known Errors, Workarounds und Wissensnutzung im Service Desk > **Kurz erklärt** > > Known Errors und Workarounds sind besonders wichtig für den Service Desk. > > Sie helfen dabei, bekannte Fehlerbilder schneller zu erkennen, Benutzer schneller wieder arbeitsfähig zu machen und wiederkehrende Incidents einheitlich zu bearbeiten. > > Entscheidend ist, dass dieses Wissen verständlich dokumentiert, leicht auffindbar, aktuell und mit Incident-, Problem- und Knowledge Management verknüpft ist. --- **Warum Known Errors und Workarounds im Service Desk wichtig sind** Der Service Desk ist häufig die erste Stelle, die wiederkehrende Fehler bemerkt. Beispiele: - mehrere Benutzer melden denselben VPN-Fehler, - eine Anwendung zeigt nach einem Update immer dieselbe Fehlermeldung, - ein Druckertreiber verursacht wiederkehrende Probleme, - ein Zertifikat läuft ab, - ein Workaround wird regelmäßig angewendet, - ein bekannter Fehler tritt nach bestimmten Bedingungen auf. Ohne dokumentiertes Wissen muss der Service Desk jeden Fall neu analysieren. Mit gut gepflegten Known Errors und Workarounds kann er schneller reagieren. --- **Known Error** Ein **Known Error** ist ein bekannter Fehlerzustand oder ein bekanntes Problem, bei dem Ursache, wahrscheinliche Ursache oder Fehlerbild ausreichend verstanden sind. Ein Known Error kann enthalten: - bekanntes Symptom, - betroffener Service, - betroffene Version, - Ursache oder wahrscheinliche Ursache, - Workaround, - dauerhafte Lösung, - Status, - Risiko, - Eskalationsweg, - Verknüpfung zu Problem Record, - Verknüpfung zu Knowledge-Artikel. Ein Known Error muss nicht bedeuten, dass die endgültige Lösung bereits umgesetzt wurde. --- **Workaround** Ein **Workaround** ist eine vorübergehende Möglichkeit, die Auswirkungen eines Incidents oder Problems zu umgehen oder zu reduzieren. Beispiele: - VPN-Client vollständig neu starten, - alternative Webversion nutzen, - Druckauftrag über anderen Drucker ausgeben, - Dienst kontrolliert neu starten, - temporäre Bereinigung nach Runbook durchführen, - anderes Anmeldeverfahren verwenden, - bekannte fehlerhafte Funktion vorübergehend vermeiden. Ein Workaround ist hilfreich, aber nicht automatisch eine dauerhafte Lösung. --- **Known Error und Workaround unterscheiden** | Begriff | Bedeutung | Beispiel | |---|---|---| | **Known Error** | bekannter Fehlerzustand oder bekanntes Problem | VPN-Client-Version 5.8 verliert nach Ruhezustand Verbindung | | **Workaround** | vorübergehende Maßnahme zur Umgehung | VPN-Client vollständig beenden und neu starten | | **dauerhafte Lösung** | beseitigt Ursache oder reduziert Risiko dauerhaft | neue VPN-Client-Version ausrollen | | **Knowledge-Artikel** | nutzbare Dokumentation für Zielgruppe | Service-Desk-Artikel mit Symptomen und Prüfschritten | --- **Warum Workarounds dokumentiert werden müssen** Ein Workaround, der nur einzelnen Personen bekannt ist, hilft nicht zuverlässig. Typische Folgen fehlender Dokumentation: - Service Desk arbeitet uneinheitlich, - Benutzer erhalten unterschiedliche Antworten, - Incidents dauern länger, - gleiche Analyse wird mehrfach durchgeführt, - Risiken werden übersehen, - Eskalationen erfolgen zu spät, - Problem Management erkennt Muster schlechter, - neue Mitarbeitende müssen Wissen mündlich erfragen. Ein guter Workaround muss für die richtige Zielgruppe auffindbar und verständlich sein. --- **Ein Workaround ist keine endgültige Lösung** Ein häufiger Fehler ist, einen Workaround als Lösung zu behandeln. Beispiel: Ein Dienst stürzt regelmäßig ab. Der Service Desk startet den Dienst jedes Mal neu. Dadurch funktioniert der Service kurzfristig wieder. Die eigentliche Ursache bleibt aber bestehen. Offene Fragen: - Warum stürzt der Dienst ab? - Warum erkennt Monitoring den Fehler nicht früher? - Warum ist kein automatischer Neustart vorgesehen? - Warum tritt der Fehler regelmäßig auf? - Gibt es ein Problem Record? - Gibt es eine geplante dauerhafte Lösung? > **Merke** > > Ein Workaround kann einen Incident abschließen. > > Das zugrunde liegende Problem kann trotzdem offen bleiben. --- **Wissensnutzung im Service Desk** Der Service Desk sollte Knowledge aktiv nutzen. Beispiele: - bei Ticketerstellung nach passenden Artikeln suchen, - bekannte Symptome mit Known Errors vergleichen, - Workaround nach geprüfter Anleitung anwenden, - Ticket mit Knowledge-Artikel verknüpfen, - fehlende oder falsche Artikel melden, - wiederkehrende Incidents an Problem Management geben, - Benutzer mit freigegebenen Informationen versorgen. Knowledge Management ist nur wirksam, wenn das Wissen im Alltag verwendet wird. --- **Service-Desk-Artikel zu Known Errors** Ein guter Service-Desk-Artikel zu einem Known Error enthält: - eindeutigen Titel, - betroffenen Service, - bekannte Symptome, - betroffene Versionen oder Komponenten, - Prüfschritte, - Workaround, - Risiken und Einschränkungen, - wann der Artikel nicht gilt, - Eskalationskriterien, - Verknüpfung zum Problem Record, - geplante dauerhafte Lösung, - Review-Datum, - Owner. Der Artikel muss so geschrieben sein, dass der Service Desk ihn unter Zeitdruck nutzen kann. --- **Beispielstruktur für einen Known-Error-Artikel** | Abschnitt | Inhalt | |---|---| | **Titel** | VPN verbindet nach Ruhezustand nicht mehr | | **Betroffener Service** | VPN-Zugang | | **Symptom** | Verbindung bricht nach Standby ab | | **Betroffen** | Windows-Notebooks mit Client-Version 5.8 | | **Prüfung** | Clientversion und Fehlerbild abgleichen | | **Workaround** | VPN-Client vollständig beenden und neu starten | | **Eskalation** | bei anderer Version an Netzwerkteam | | **Problem Record** | verknüpft | | **Dauerhafte Lösung** | Rollout Version 5.9 geplant | | **Review** | nach Rollout prüfen | --- **Titel und Suchbegriffe** Known-Error-Artikel müssen über typische Suchbegriffe gefunden werden. Ungeeignet: > Fehlercode 0x802-VPN-Tunnelstate Besser: > VPN verbindet nach Ruhezustand nicht mehr Ungeeignet: > Problem mit Auth-Komponente Besser: > Anmeldung im Mitarbeiterportal schlägt fehl Ein guter Titel nutzt die Sprache, die im Ticket oder im Benutzerkontakt tatsächlich vorkommt. --- **Symptome klar beschreiben** Der Service Desk muss schnell erkennen können, ob ein neuer Incident zum Known Error passt. Gute Symptombeschreibungen enthalten: - sichtbare Fehlermeldung, - Zeitpunkt oder Auslöser, - betroffene Anwendung, - betroffene Version, - betroffene Benutzergruppe, - betroffene Umgebung, - typische Begleitumstände, - bekannte Ausschlusskriterien. Beispiel: > Fehler tritt nur nach Ruhezustand auf Windows-Notebooks mit VPN-Client-Version 5.8 auf. Wenn der Fehler direkt nach Neustart oder bei anderer Version auftritt, gilt dieser Known Error nicht automatisch. --- **Prüfschritte** Prüfschritte helfen, den Known Error sicher zu erkennen. Beispiele: - Service prüfen, - Version prüfen, - Benutzergruppe prüfen, - Fehlermeldung vergleichen, - Zeitpunkt prüfen, - letzte Changes prüfen, - Known-Error-Status prüfen, - Monitoring prüfen, - Ticketverlauf prüfen. Prüfschritte sollten kurz, eindeutig und reproduzierbar sein. Ungeeignet: > Prüfen, ob es das bekannte Problem ist. Besser: > VPN-Client-Version prüfen. Gilt nur für Version 5.8. Fehler tritt nach Ruhezustand auf. Wenn Version abweicht, an Netzwerkteam eskalieren. --- **Workaround-Schritte** Ein Workaround muss so beschrieben sein, dass er sicher ausgeführt werden kann. Er sollte enthalten: - genaue Schritte, - Voraussetzungen, - erwartetes Ergebnis, - Risiken, - Einschränkungen, - Abbruchkriterien, - Eskalation bei Fehlschlag, - Hinweis zur Dokumentation im Ticket. Ungeeignet: > Client neu starten. Besser: > VPN-Client vollständig beenden, prüfen ob kein VPN-Prozess mehr läuft, Client erneut starten und Verbindung testen. Wenn Verbindung weiterhin fehlschlägt, Ticket an Netzwerkteam eskalieren. --- **Wann der Workaround nicht angewendet werden darf** Ein guter Artikel beschreibt auch Grenzen. Beispiele: - gilt nur für bestimmte Version, - gilt nicht bei Sicherheitsvorfall, - gilt nicht bei Datenverlust, - gilt nicht bei produktivem Datenbankfehler, - gilt nicht außerhalb eines genehmigten Wartungsfensters, - gilt nicht ohne Freigabe, - gilt nicht bei kritischen Services ohne Eskalation. Diese Grenzen verhindern, dass ein Workaround falsch oder riskant angewendet wird. --- **Risiken eines Workarounds** Workarounds können Risiken haben. Beispiele: - Datenverlust, - Sicherheitsrisiko, - Unterbrechung für andere Benutzer, - falsche Berechtigungen, - Folgefehler, - manuelle Fehler, - unvollständige Wiederherstellung, - Verstoß gegen Vorgaben, - verdeckte Ursache bleibt bestehen. Deshalb sollten Risiken im Artikel genannt werden. Ein Workaround ohne Risikohinweis kann zu falscher Anwendung führen. --- **Eskalationskriterien** Ein Service-Desk-Artikel sollte klar sagen, wann eskaliert werden muss. Beispiele: - Workaround schlägt fehl, - Fehlerbild passt nicht vollständig, - anderer Service ist betroffen, - mehrere Benutzer oder Standort betroffen, - Sicherheitsbezug möglich, - kritischer Service betroffen, - Datenverlust möglich, - gleiche Störung wiederholt sich häufig, - Benutzer hat Sonderrolle, - bekannte Version stimmt nicht. Eskalationskriterien verhindern unnötige Verzögerungen. --- **Ticketdokumentation** Wenn ein Known Error oder Workaround genutzt wurde, sollte das Ticket sauber dokumentiert werden. Wichtige Angaben: - welcher Knowledge-Artikel genutzt wurde, - welcher Known Error vermutet oder bestätigt wurde, - welche Prüfschritte durchgeführt wurden, - ob der Workaround funktioniert hat, - welche Version betroffen war, - ob eskaliert wurde, - ob Benutzer informiert wurde, - ob Folgeproblem erkennbar ist. Gute Ticketdokumentation unterstützt Trendanalyse und Problem Management. --- **Verknüpfung mit Problem Management** Known Errors entstehen oft aus Problem Management. Problem Management liefert: - Ursache oder wahrscheinliche Ursache, - beitragende Faktoren, - bekannte Symptome, - Workaround, - dauerhafte Lösung, - Risiko, - Status, - geplante Changes. Der Service Desk nutzt dieses Wissen im Incident Management. Neue Incidents liefern wiederum Informationen zurück an Problem Management. --- **Wann der Service Desk Problem Management informieren sollte** Problem Management sollte informiert werden, wenn: - ein Workaround sehr häufig genutzt wird, - ein Known Error häufiger auftritt als erwartet, - neue Symptome auftreten, - ein bekannter Workaround nicht mehr funktioniert, - ein neuer wiederkehrender Fehler sichtbar wird, - ein Major Incident droht, - viele Benutzer betroffen sind, - Service Desk auffällige Trends erkennt. Der Service Desk ist eine wichtige Frühwarnquelle. --- **Verknüpfung mit Change Enablement** Eine dauerhafte Lösung für einen Known Error benötigt häufig einen Change. Beispiele: - Softwareupdate, - Konfigurationsänderung, - Treiberupdate, - Zertifikatserneuerung, - Firewall-Anpassung, - Monitoring-Erweiterung, - Berechtigungsänderung, - Austausch einer Komponente. Der Knowledge-Artikel sollte zeigen: - ob ein Change geplant ist, - wann eine dauerhafte Lösung erwartet wird, - ob der Workaround bis dahin gilt, - wann der Artikel überprüft werden muss. --- **Verknüpfung mit Release Management** Nach einem Release kann sich der Status eines Known Errors ändern. Beispiele: - Known Error wurde behoben, - Workaround ist nicht mehr gültig, - neue Version hat anderes Fehlerbild, - Artikel benötigt neue Screenshots, - Service Desk braucht neue Prüfschritte, - Benutzerinformation muss angepasst werden. Nach Releases sollten relevante Knowledge-Artikel geprüft werden. --- **Verknüpfung mit Service Configuration Management** Known Errors und Workarounds sollten mit Services und CIs verknüpft werden. Beispiele: - Service: VPN-Zugang, - CI: VPN-Client-Version 5.8, - CI: VPN-Gateway, - CI: Identity Provider, - CI: Zertifikat, - Problem Record, - Change Record. Vorteile: - Artikel werden im Ticket besser vorgeschlagen, - betroffene Versionen sind erkennbar, - Trendanalyse wird besser, - Changes können Artikel gezielt aktualisieren, - Service Desk findet schneller passende Informationen. --- **Benutzerkommunikation bei Known Errors** Benutzer sollten verständlich informiert werden. Gute Kommunikation enthält: - was betroffen ist, - welche Zwischenlösung verfügbar ist, - was Benutzer tun sollen, - welche Einschränkung besteht, - ob an einer dauerhaften Lösung gearbeitet wird, - wo weitere Informationen stehen. Ungeeignet: > Das ist ein bekannter Bug, einfach neu starten. Besser: > Für dieses VPN-Problem gibt es aktuell eine sichere Zwischenlösung. Bitte schließen Sie den VPN-Client vollständig und starten Sie ihn erneut. Die Ursache ist bekannt, eine dauerhafte Korrektur wird vorbereitet. --- **Interne und externe Artikel trennen** Ein Known Error kann verschiedene Artikel benötigen. **Benutzerartikel** - einfache Erklärung, - sichere Handlung, - Supportweg, - keine internen Details. **Service-Desk-Artikel** - Symptome, - Prüfschritte, - Workaround, - Eskalation, - Ticketdokumentation. **Fachteam-Artikel** - technische Ursache, - Logs, - Konfiguration, - dauerhafte Lösung, - Change-Planung. Nicht jedes Detail gehört in jeden Artikel. --- **Known Error ohne Workaround** Nicht jeder Known Error besitzt einen sicheren Workaround. Beispiele: - Zertifikat ist abgelaufen, - Datenbank ist beschädigt, - Sicherheitslücke wird aktiv ausgenutzt, - zentraler Dienst ist ausgefallen, - Datenverlust droht. Dann muss der Artikel klar sagen: - kein Workaround verfügbar, - sofort eskalieren, - Benutzer nicht zu unsicheren Ersatzwegen anleiten, - Statuskommunikation nutzen, - Problem oder Major Incident prüfen. Ein fehlender Workaround sollte ausdrücklich dokumentiert werden. --- **Known Error mit Risikoakzeptanz** Manche Known Errors bleiben längere Zeit offen. Gründe: - dauerhafte Lösung ist teuer, - Herstellerkorrektur steht aus, - Änderung ist riskant, - Workaround funktioniert ausreichend, - Service wird bald abgelöst, - Risiko wurde bewusst akzeptiert. Dann sollte dokumentiert werden: - wer das Risiko akzeptiert hat, - wie lange die Akzeptanz gilt, - welcher Workaround erlaubt ist, - wann neu bewertet wird, - welche Einschränkungen bestehen. --- **Knowledge-Artikel im Ticket vorschlagen** Viele ITSM-Systeme können Artikel im Ticket vorschlagen. Grundlagen dafür: - guter Titel, - passende Suchbegriffe, - Servicebezug, - Kategorie, - CI-Verknüpfung, - Known-Error-Verknüpfung, - klare Symptome, - aktuelle Inhalte. Automatische Vorschläge helfen nur, wenn die Artikelqualität gut ist. Schlechte Vorschläge führen dazu, dass Mitarbeitende die Funktion ignorieren. --- **Nutzung messen** Die Nutzung von Known-Error- und Workaround-Artikeln sollte ausgewertet werden. Mögliche Fragen: - Welche Artikel werden häufig genutzt? - Welche Workarounds werden besonders oft angewendet? - Welche Artikel lösen Incidents erfolgreich? - Wo brechen Mitarbeitende ab? - Welche Artikel werden schlecht bewertet? - Welche Suchanfragen führen zu keinem Treffer? - Welche Known Errors erzeugen weiterhin viele Tickets? Diese Daten helfen, Wissen und Problems gezielt zu verbessern. --- **Artikelqualität aus Service-Desk-Sicht** Ein Service-Desk-Artikel ist gut, wenn er: - schnell auffindbar ist, - klare Symptome nennt, - Prüfschritte enthält, - Workaround sicher beschreibt, - Eskalationsregeln nennt, - keine unnötige Fachsprache nutzt, - Risiken sichtbar macht, - mit Service oder CI verknüpft ist, - aktuell ist, - und im Ticket nutzbar dokumentiert werden kann. Der Artikel muss im Arbeitsfluss helfen, nicht nur formal existieren. --- **Feedback aus dem Service Desk** Der Service Desk sollte Feedback zu Artikeln geben können. Beispiele: - Artikel nicht gefunden, - Titel unklar, - Schritt fehlt, - Workaround funktioniert nicht mehr, - Fehlerbild hat sich geändert, - Screenshot veraltet, - Eskalationsweg falsch, - Benutzer verstehen Anleitung nicht, - Artikel ist doppelt vorhanden. Feedback muss bearbeitet werden. Sonst verliert der Service Desk Vertrauen in die Knowledge Base. --- **Wissenspflege nach gelösten Incidents** Nach gelösten Incidents sollte geprüft werden: - Gibt es bereits einen passenden Artikel? - Muss der Artikel ergänzt werden? - War der Artikel korrekt? - Sollte ein neuer Artikel entstehen? - Ist ein Known Error erkennbar? - Gibt es einen neuen Workaround? - Sollte Problem Management informiert werden? Diese Prüfung muss nicht bei jedem kleinen Ticket ausführlich sein. Bei wiederkehrenden oder auffälligen Fällen ist sie sehr wertvoll. --- **Wissenspflege nach Problem-Abschluss** Nach Problem Management sollten relevante Artikel aktualisiert werden. Zu prüfen ist: - wurde ein Known Error erstellt, - wurde ein Workaround dokumentiert, - wurde eine dauerhafte Lösung umgesetzt, - ist der Workaround noch gültig, - muss der Service Desk neue Prüfschritte kennen, - muss ein Benutzerartikel erstellt werden, - müssen alte Artikel archiviert werden. Problem-Abschluss ohne Knowledge-Prüfung führt dazu, dass Wissen im Betrieb nicht ankommt. --- **Wissenspflege nach Change oder Release** Nach Changes und Releases muss geprüft werden: - ist der Known Error behoben, - ist der Workaround noch gültig, - haben sich Versionen geändert, - haben sich Menüpfade geändert, - haben sich Symptome geändert, - muss der Artikel archiviert werden, - muss der Service Desk informiert werden, - müssen Benutzerinformationen angepasst werden. Ein veralteter Workaround kann nach einem Release neue Probleme verursachen. --- **Praxisbeispiel: VPN Known Error** **Situation** Nach dem Ruhezustand verlieren Windows-Notebooks die VPN-Verbindung. **Known Error** VPN-Client-Version 5.8 verliert nach Ruhezustand den Tunnelzustand. **Service-Desk-Artikel** - Fehlerbild, - betroffene Version, - Prüfschritte, - Workaround, - Eskalation bei anderer Version, - Problem Record, - geplanter Change auf Version 5.9. **Nutzen** Der Service Desk erkennt den Fall schneller und dokumentiert ihn einheitlich. --- **Praxisbeispiel: Druckertreiber** **Situation** Etikettendruck funktioniert bei bestimmten PDF-Dateien nicht. **Known Error** Der installierte Treiber verarbeitet bestimmte PDF-Formate fehlerhaft. **Workaround** Fehlerhaften Druckauftrag entfernen und alternative Druckoption nutzen. **Dauerhafte Lösung** Treiberupdate testen und ausrollen. **Knowledge-Nutzen** Service Desk kann betroffene Fälle schneller erkennen und vermeidet unnötige Hardwaretauschversuche. --- **Praxisbeispiel: Kein Workaround verfügbar** **Situation** Anmeldung an einer Fachanwendung schlägt wegen abgelaufenem Zertifikat fehl. **Known Error** Zertifikat des Anmeldedienstes ist abgelaufen. **Workaround** Kein sicherer Workaround verfügbar. **Service-Desk-Anweisung** - Incident priorisieren, - an Plattform-Team eskalieren, - Statusmeldung verwenden, - Benutzer nicht auf unsichere Ersatzwege verweisen. **Nutzen** Der Service Desk reagiert klar und sicher. --- **Praxisbeispiel: Artikel veraltet nach Release** **Situation** Nach einem Release ändert sich der Menüpfad für eine Funktion. **Problem** Der alte Benutzerartikel beschreibt den früheren Menüpfad. **Folge** Benutzer erstellen Tickets, obwohl die Funktion verfügbar ist. **Verbesserung** Change- und Release-Abschluss enthalten künftig eine Prüfung betroffener Knowledge-Artikel. --- **Typische Fehler** **Fehler 1** Known Error ist bekannt, aber nicht dokumentiert. --- **Fehler 2** Workaround steht nur in einem alten Ticket. --- **Fehler 3** Service Desk kennt den Workaround nicht. --- **Fehler 4** Artikel beschreibt nicht, wann der Workaround nicht gilt. --- **Fehler 5** Risiken werden nicht genannt. --- **Fehler 6** Known Error wird nicht mit Problem Record verknüpft. --- **Fehler 7** Artikel wird nach Change oder Release nicht aktualisiert. --- **Fehler 8** Benutzer erhalten interne technische Details. --- **Fehler 9** Kein Workaround verfügbar, aber der Artikel sagt das nicht ausdrücklich. --- **Fehler 10** Service Desk dokumentiert nicht, welcher Artikel genutzt wurde. --- **Fehler 11** Häufig genutzte Workarounds werden nicht an Problem Management gemeldet. --- **Fehler 12** Feedback aus dem Service Desk wird nicht bearbeitet. --- **Checkliste Known-Error-Artikel** - [ ] Fehlerbild klar beschrieben - [ ] betroffener Service genannt - [ ] betroffene Version oder Komponente genannt - [ ] Ursache oder wahrscheinliche Ursache beschrieben - [ ] Workaround vorhanden oder ausdrücklich nicht verfügbar - [ ] Risiken genannt - [ ] Einschränkungen genannt - [ ] Prüfschritte enthalten - [ ] Eskalationskriterien beschrieben - [ ] Problem Record verknüpft - [ ] geplanter Change oder dauerhafte Lösung genannt - [ ] Owner und Review-Datum vorhanden --- **Checkliste Workaround** - [ ] genaue Schritte beschrieben - [ ] Voraussetzungen genannt - [ ] Zielgruppe klar - [ ] erwartetes Ergebnis beschrieben - [ ] Risiken bewertet - [ ] Abbruchkriterien definiert - [ ] Eskalationsweg genannt - [ ] Dokumentation im Ticket beschrieben - [ ] Gültigkeitsbereich klar - [ ] Review nach Change oder Release vorgesehen --- **Checkliste Service Desk Nutzung** - [ ] bei bekannten Symptomen Knowledge Base prüfen - [ ] passenden Artikel im Ticket verknüpfen - [ ] Prüfschritte dokumentieren - [ ] Workaround korrekt anwenden - [ ] Ergebnis dokumentieren - [ ] bei Abweichung eskalieren - [ ] bei falschem Artikel Feedback geben - [ ] wiederkehrende Fälle an Problem Management melden - [ ] Benutzer mit freigegebenem Text informieren - [ ] Artikel nicht blind anwenden, wenn Fehlerbild nicht passt --- **Checkliste Wissenspflege** - [ ] häufig genutzte Workarounds auswerten - [ ] Known Errors regelmäßig prüfen - [ ] Artikel nach Changes aktualisieren - [ ] Artikel nach Releases aktualisieren - [ ] gelöste Known Errors archivieren oder anpassen - [ ] Feedback des Service Desk bearbeiten - [ ] Suchbegriffe verbessern - [ ] doppelte Artikel zusammenführen - [ ] veraltete Workarounds entfernen - [ ] Problem Management über neue Muster informieren --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker unterstützen Known Errors und Workarounds durch technisches Verständnis und saubere Dokumentation. Im Arbeitsalltag bedeutet das: - wiederkehrende Fehlerbilder erkennen, - technische Prüfschritte verständlich beschreiben, - Workarounds sicher dokumentieren, - Risiken und Grenzen nennen, - Known Errors mit CIs und Problems verknüpfen, - Service Desk mit klaren Artikeln unterstützen, - nach Changes Artikel aktualisieren, - und häufig genutzte Workarounds als Hinweis auf ungelöste Problems verstehen. Gute Workaround- und Known-Error-Dokumentation spart Zeit und erhöht die Qualität im Support. --- **Zusammenfassung** > Wiederkehrendes Fehlerbild erkennen > ↓ > Problem oder Known Error dokumentieren > ↓ > Symptome und betroffene Versionen beschreiben > ↓ > sicheren Workaround bereitstellen oder Nichtverfügbarkeit kennzeichnen > ↓ > Service-Desk-Artikel erstellen > ↓ > Artikel mit Service, CI, Problem und Change verknüpfen > ↓ > Service Desk nutzt Artikel im Incident > ↓ > Nutzung und Feedback auswerten > ↓ > dauerhafte Lösung verfolgen > ↓ > Artikel nach Change oder Release aktualisieren --- **Merksätze** > Ein Known Error muss auffindbar sein, sonst hilft er dem Service Desk nicht. > Ein Workaround ist hilfreich, aber keine automatische Dauerlösung. > Jeder Workaround braucht Grenzen, Risiken und Eskalationskriterien. > Kein Workaround verfügbar ist ebenfalls eine wichtige Information. > Service Desk Feedback verbessert die Knowledge Base. > Häufig genutzte Workarounds sind ein Hinweis auf ungelöste Problems. > Nach Changes und Releases müssen Known Errors und Workarounds überprüft werden. --- **Verwandte Seiten** - 7.1 Knowledge Management – Ziele, Begriffe und Grundlagen - 7.2 Knowledge-Artikel, Runbooks und FAQ - 7.4 Self-Service und Benutzerwissen - 7.5 Knowledge Management im Zusammenspiel mit Incident, Problem und Change - 4.3 Workarounds und Known Errors - Incident Management - Problem Management - Change Enablement - Service Configuration Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Service Desk - PeopleCert – ITIL Practice Guide: Change Enablement - ITIL Foundation – Version 5 **Ergänzende Praxiseinordnung** - Knowledge-Centered Service als verbreiteter Praxisansatz für Wissensarbeit im Support **Einordnung** Die dargestellten: - Known-Error-Strukturen, - Workaround-Hinweise, - Service-Desk-Checklisten, - Ticketdokumentation, - Pflegehinweise, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Known-Error-Vorlage, - Workaround-Struktur, - Service-Desk-Artikelpflicht, - Eskalationsmatrix, - Review-Frequenz, - oder Toolintegration für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Supportmodell, - Knowledge-Werkzeuge, - Problem Management, - Change-Modell, - Sicherheitsanforderungen, - Service Configuration Management, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026