# 7. Knowledge Management



# 7.1 Knowledge Management – Ziele, Begriffe und Grundlagen

> **Kurz erklärt**
>
> Knowledge Management sorgt dafür, dass wichtiges Wissen im IT-Betrieb gesammelt, geprüft, strukturiert, auffindbar und nutzbar gemacht wird.
>
> Ziel ist, dass Mitarbeitende, Service Desk, Fachgruppen und Benutzer nicht jedes Problem immer wieder neu lösen müssen.
>
> Gute Wissensnutzung verbessert Supportqualität, verkürzt Bearbeitungszeiten, reduziert Wiederholungsfehler und macht IT-Services stabiler.

---

**Warum Knowledge Management wichtig ist**

Im IT-Betrieb entsteht täglich Wissen.

Beispiele:

- bekannte Fehlermeldungen,
- Workarounds,
- Standardlösungen,
- Installationsanleitungen,
- Betriebsrunbooks,
- Eskalationswege,
- bekannte Fehler,
- Anleitungen für Benutzer,
- technische Prüfschritte,
- Lessons Learned aus Incidents,
- Ergebnisse aus Problem Management,
- Änderungen nach Releases,
- Sicherheits- und Betriebshinweise.

Wenn dieses Wissen nicht dokumentiert wird, entstehen typische Probleme:

- dieselben Fragen werden immer wieder gestellt,
- Service Desk analysiert bekannte Fehler jedes Mal neu,
- Lösungen hängen von einzelnen Personen ab,
- neue Mitarbeitende brauchen länger,
- Workarounds werden uneinheitlich angewendet,
- Benutzer erhalten widersprüchliche Antworten,
- Wissen geht bei Krankheit, Urlaub oder Wechsel verloren,
- und Incidents dauern länger als nötig.

Knowledge Management macht Wissen wiederverwendbar.

---

**Ziel von Knowledge Management**

Knowledge Management soll sicherstellen, dass richtiges Wissen zur richtigen Zeit für die richtige Zielgruppe verfügbar ist.

Ziele sind:

- Wissen auffindbar machen,
- Lösungen wiederverwendbar machen,
- Bearbeitungszeiten reduzieren,
- Fehler bei Standardfällen vermeiden,
- Self-Service ermöglichen,
- Service Desk entlasten,
- Qualität von Antworten verbessern,
- neue Mitarbeitende schneller einarbeiten,
- Lessons Learned sichern,
- und kontinuierliche Verbesserung unterstützen.

Knowledge Management ist kein reines Dokumentationsarchiv.

Es ist ein aktiver Bestandteil des Servicebetriebs.

---

**Wissen ist nicht gleich Dokumentation**

Dokumentation kann Wissen enthalten.

Aber nicht jede Dokumentation ist automatisch nützliches Wissen.

| Dokumentation | Nutzbares Wissen |
|---|---|
| irgendwo abgelegt | auffindbar |
| sehr technisch oder unklar | zielgruppengerecht |
| veraltet | geprüft und aktuell |
| ohne Zusammenhang | mit Service, CI oder Prozess verknüpft |
| nur für Spezialisten verständlich | für passende Zielgruppe verständlich |
| nicht gepflegt | mit Owner und Review versehen |

Beispiel:

Ein 80-seitiges Betriebshandbuch kann wichtig sein.

Für den Service Desk ist aber oft ein kurzer Artikel mit Symptomen, Prüfschritten, Workaround und Eskalationsweg hilfreicher.

---

**Arten von Wissen**

Im IT-Betrieb gibt es unterschiedliche Wissensarten.

| Wissensart | Beispiel |
|---|---|
| **Benutzerwissen** | Anleitung zum Zurücksetzen des Passworts |
| **Service-Desk-Wissen** | Prüfschritte bei VPN-Problemen |
| **Fachwissen** | technische Analyse einer Datenbankstörung |
| **Betriebswissen** | Runbook für Neustart eines Dienstes |
| **Known-Error-Wissen** | bekannter Fehler mit Workaround |
| **Change-Wissen** | Hinweise nach einem Update |
| **Sicherheitswissen** | Umgang mit verdächtigen Mails |
| **Servicewissen** | Zuständigkeiten, Supportzeiten und Abhängigkeiten |

Diese Wissensarten benötigen unterschiedliche Form, Sprache und Zugriffsbeschränkung.

---

**Explizites und implizites Wissen**

**Explizites Wissen**

ist dokumentiert und kann weitergegeben werden.

Beispiele:

- Knowledge-Artikel,
- Runbook,
- Checkliste,
- FAQ,
- Servicebeschreibung,
- Known Error,
- Installationsanleitung.

**Implizites Wissen**

ist in den Köpfen von Personen vorhanden.

Beispiele:

- Erfahrung mit einem instabilen System,
- bekannte Eigenheiten eines Lieferanten,
- typische Fehler nach Updates,
- inoffizielle Abhängigkeiten,
- bewährte Diagnosewege.

Knowledge Management versucht, wichtiges implizites Wissen in nutzbares explizites Wissen zu überführen.

---

**Wissen muss zielgruppengerecht sein**

Nicht jede Zielgruppe benötigt dieselben Informationen.

| Zielgruppe | braucht typischerweise |
|---|---|
| **Benutzer** | einfache Anleitung, klare Schritte, keine internen Details |
| **Service Desk** | Symptome, Prüfschritte, Workaround, Eskalationsweg |
| **Fachteam** | technische Details, Logs, Konfigurationen, Ursachen |
| **Management** | Risiko, Auswirkungen, Status, Entscheidungspunkte |
| **Security Team** | Schutzmaßnahmen, Meldewege, Klassifizierung |
| **Lieferant** | technische Nachweise, Versionen, Fehlerbild |

Ein Benutzerartikel sollte keine internen Admin-Schritte enthalten.

Ein interner Runbook-Artikel darf technischer und detaillierter sein.

---

**Beispiele für Knowledge-Artikel**

Mögliche Artikeltypen:

- „VPN verbindet nicht nach Ruhezustand“
- „Passwort über Self-Service zurücksetzen“
- „Druckwarteschlange sicher neu starten“
- „TLS-Zertifikat erneuern“
- „Known Error: Client-Version 5.8 verliert Tunnelzustand“
- „Runbook: Datenbankdienst kontrolliert neu starten“
- „Checkliste: Server nach Update prüfen“
- „FAQ: MFA bei neuem Smartphone einrichten“
- „Service Desk: Erstdiagnose bei DNS-Problemen“
- „Benutzerinformation: Wartungsfenster Mitarbeiterportal“

Wichtig ist, dass Titel und Inhalt Suchbegriffe aus der Praxis berücksichtigen.

---

**Knowledge Base**

Eine Knowledge Base ist ein strukturierter Ort für Wissen.

Sie kann enthalten:

- Benutzeranleitungen,
- interne Supportartikel,
- technische Runbooks,
- FAQ,
- Known Errors,
- Workarounds,
- Checklisten,
- Troubleshooting-Guides,
- Servicebeschreibungen,
- Release-Hinweise,
- Sicherheitsanweisungen.

Das Werkzeug ist nicht entscheidend.

Möglich sind:

- ITSM-System,
- Wiki,
- Self-Service-Portal,
- Dokumentationsplattform,
- Knowledge-Modul,
- internes Handbuch.

Wichtig sind Auffindbarkeit, Aktualität, Qualität und Pflegeverantwortung.

---

**Knowledge Management und Self-Service**

Knowledge Management unterstützt Self-Service.

Benutzer können einfache Anliegen selbst lösen, wenn Informationen verständlich bereitstehen.

Beispiele:

- Passwort zurücksetzen,
- MFA neu einrichten,
- WLAN verbinden,
- Standardsoftware beantragen,
- Drucker hinzufügen,
- Status einer Störung prüfen,
- häufige Fehlermeldung verstehen.

Self-Service funktioniert nur, wenn Artikel:

- leicht auffindbar,
- verständlich formuliert,
- aktuell,
- kurz genug,
- und praktisch getestet sind.

Ein schlechter Self-Service erzeugt zusätzliche Rückfragen.

---

**Knowledge Management und Service Desk**

Der Service Desk profitiert besonders von guter Wissensbasis.

Nützlich sind:

- Standardantworten,
- Diagnosefragen,
- Prüfschritte,
- bekannte Symptome,
- Workarounds,
- Eskalationskriterien,
- Priorisierungshinweise,
- Kommunikationsvorlagen,
- Links zu Runbooks,
- Known Errors,
- Serviceinformationen.

Dadurch kann der Service Desk schneller und einheitlicher arbeiten.

Gleichzeitig liefert der Service Desk viele Hinweise, welche Artikel fehlen oder verbessert werden müssen.

---

**Knowledge Management und Incident Management**

Incident Management nutzt Wissen zur schnellen Wiederherstellung.

Beispiele:

- bekannter Workaround wird angewendet,
- Service Desk findet passenden Artikel,
- Incident wird mit Knowledge-Artikel verknüpft,
- Benutzer erhält geprüfte Anleitung,
- wiederkehrender Fehler wird schneller erkannt.

Incident Management liefert auch neues Wissen zurück.

Beispiele:

- neue Fehlermeldung,
- neuer Workaround,
- unklare Anleitung,
- falscher Artikel,
- fehlender Eskalationsweg,
- wiederkehrende Benutzerfrage.

---

**Knowledge Management und Problem Management**

Problem Management erzeugt wichtiges Wissen.

Beispiele:

- bekannte Ursachen,
- Known Errors,
- Workarounds,
- dauerhafte Lösungen,
- beitragende Faktoren,
- Lessons Learned,
- technische Prüfschritte,
- Risikohinweise.

Dieses Wissen sollte nicht nur im Problem Record bleiben.

Es muss so aufbereitet werden, dass Service Desk, Fachgruppen oder Benutzer es nutzen können.

---

**Knowledge Management und Change Enablement**

Changes verändern Services und damit auch Wissen.

Nach einem Change müssen möglicherweise aktualisiert werden:

- Benutzeranleitungen,
- Screenshots,
- Menüpfade,
- Runbooks,
- Known Errors,
- Workarounds,
- Servicebeschreibungen,
- Supportwege,
- Monitoringhinweise,
- Eskalationsregeln.

Ein Change ist nicht vollständig abgeschlossen, wenn die Technik geändert wurde, aber das Wissen noch den alten Stand zeigt.

---

**Knowledge Management und Release Management**

Releases bringen neue oder geänderte Funktionen.

Knowledge Management unterstützt durch:

- Release Notes,
- Benutzerinformationen,
- Service-Desk-Briefings,
- bekannte Einschränkungen,
- neue Workarounds,
- aktualisierte FAQ,
- Schulungsunterlagen,
- Hinweise auf geänderte Prozesse.

Nach einem Release steigen oft Rückfragen, wenn Wissen nicht rechtzeitig vorbereitet wurde.

---

**Knowledge Management und Service Configuration Management**

Configuration-Daten helfen, Wissen besser zuzuordnen.

Beispiele:

- Artikel gehört zu einem Service,
- Workaround gehört zu einem Known Error,
- Runbook gehört zu einem CI,
- Anleitung gehört zu einer Anwendungsversion,
- Sicherheitsartikel gehört zu einer bestimmten Benutzergruppe.

Ohne Service- oder CI-Bezug sind Knowledge-Artikel schwerer auffindbar und schwerer aktuell zu halten.

---

**Lebenszyklus von Wissen**

Wissen sollte einen Lebenszyklus besitzen.

    Bedarf erkennen
        ↓
    Wissen erfassen
        ↓
    Inhalt prüfen
        ↓
    Artikel veröffentlichen
        ↓
    Artikel nutzen
        ↓
    Feedback sammeln
        ↓
    Artikel aktualisieren
        ↓
    Artikel archivieren oder entfernen

Wissen darf nicht dauerhaft ungeprüft online bleiben.

Veraltetes Wissen kann falsche Handlungen verursachen.

---

**Wissensbedarf erkennen**

Wissensbedarf entsteht zum Beispiel durch:

- häufige Incidents,
- wiederkehrende Benutzerfragen,
- neue Services,
- neue Releases,
- Major Incidents,
- bekannte Fehler,
- fehlende Runbooks,
- neue Mitarbeitende,
- Sicherheitsvorfälle,
- unklare Eskalationen,
- wiederholte Fehlbedienung,
- Service-Desk-Rückfragen.

Eine gute Frage ist:

> Welche Information hätte den letzten Incident schneller lösbar gemacht?

---

**Wissen erfassen**

Wissen kann erfasst werden aus:

- gelösten Incidents,
- Problem Records,
- Known Errors,
- Change Records,
- Release Notes,
- Betriebsdokumentation,
- Expertenwissen,
- Benutzerfeedback,
- Schulungen,
- Lieferanteninformationen,
- Monitoring-Analysen,
- Major-Incident-Reviews,
- Lessons Learned.

Wichtig ist, Wissen nicht nur zu sammeln, sondern zu strukturieren und nutzbar zu machen.

---

**Wissen prüfen**

Vor Veröffentlichung sollte geprüft werden:

- Ist der Inhalt fachlich korrekt?
- Ist die Zielgruppe klar?
- Ist der Artikel verständlich?
- Sind Schritte vollständig?
- Sind Risiken genannt?
- Sind Screenshots aktuell?
- Gibt es Sicherheits- oder Datenschutzprobleme?
- Ist der Artikel mit Service oder CI verknüpft?
- Ist ein Owner eingetragen?
- Gibt es ein Review-Datum?

Ungeprüfte Artikel können mehr Schaden als Nutzen verursachen.

---

**Wissen veröffentlichen**

Bei Veröffentlichung ist wichtig:

- passender Titel,
- klare Suchbegriffe,
- sinnvolle Kategorie,
- Zielgruppe,
- Zugriffsschutz,
- Version oder Gültigkeit,
- Owner,
- Veröffentlichungsdatum,
- Review-Datum,
- Verknüpfung zu Service, CI, Known Error oder Change.

Ein Artikel muss so veröffentlicht werden, dass er im richtigen Moment gefunden wird.

---

**Wissen nutzen**

Wissen sollte aktiv in Prozesse eingebunden sein.

Beispiele:

- Service Desk sucht beim Ticketstart nach Artikeln,
- Ticketformular schlägt passende Artikel vor,
- Benutzer erhalten Self-Service-Vorschläge,
- Known Errors sind mit Incidents verknüpft,
- Change-Abschluss verlangt Knowledge-Prüfung,
- Problem-Abschluss verlangt Workaround- oder Known-Error-Dokumentation.

Ungenutztes Wissen veraltet schneller.

---

**Feedback sammeln**

Feedback hilft, Knowledge-Artikel zu verbessern.

Mögliche Signale:

- Artikel wird häufig genutzt,
- Artikel wird selten gefunden,
- Benutzer bewerten Artikel schlecht,
- Service Desk ergänzt immer wieder dieselbe Erklärung,
- Artikel löst das Problem nicht,
- Suchbegriffe führen zu keinem Treffer,
- Artikel ist nach Release veraltet,
- Schrittfolge ist unklar.

Feedback sollte einfach möglich sein.

---

**Wissen aktualisieren**

Artikel müssen aktualisiert werden, wenn sich etwas ändert.

Auslöser:

- Change,
- Release,
- neuer Known Error,
- gelöster Known Error,
- neue Version,
- neuer Menüpfad,
- geänderte Zuständigkeit,
- geänderter Workaround,
- Sicherheitswarnung,
- Benutzerfeedback,
- neue Screenshots,
- geänderter Service.

Ein Artikel ohne Pflegeverantwortung veraltet meist schnell.

---

**Wissen archivieren**

Nicht mehr gültige Artikel sollten archiviert oder entfernt werden.

Beispiele:

- alter Workaround gilt nicht mehr,
- Service wurde abgeschaltet,
- Version ist nicht mehr im Einsatz,
- Known Error wurde behoben,
- Anleitung bezieht sich auf alte Oberfläche,
- Sicherheitsanweisung wurde ersetzt.

Archivierung kann sinnvoll sein, wenn spätere Nachvollziehbarkeit wichtig ist.

Veraltete Artikel sollten aber nicht mehr als aktuelle Lösung erscheinen.

---

**Qualitätsmerkmale guter Knowledge-Artikel**

Ein guter Artikel ist:

- fachlich korrekt,
- aktuell,
- klar strukturiert,
- verständlich,
- zielgruppengerecht,
- auffindbar,
- mit Service oder CI verknüpft,
- mit Owner versehen,
- risikoarm anwendbar,
- getestet,
- und regelmäßig überprüft.

Ein guter Artikel beantwortet nicht alles.

Er beantwortet genau das, was die Zielgruppe in dieser Situation braucht.

---

**Struktur eines Supportartikels**

Ein Service-Desk-Artikel kann enthalten:

- Titel,
- Kurzbeschreibung,
- Symptome,
- betroffener Service,
- Zielgruppe,
- Voraussetzungen,
- Prüfschritte,
- Lösung oder Workaround,
- Abbruchkriterien,
- Eskalationsweg,
- Risiken,
- verwandte Artikel,
- Owner,
- Review-Datum.

Nicht jeder Artikel benötigt alle Felder.

Die Struktur muss zum Zweck passen.

---

**Struktur eines Benutzerartikels**

Ein Benutzerartikel sollte besonders verständlich sein.

Mögliche Struktur:

- Was ist das Problem?
- Wen betrifft es?
- Was kann ich selbst tun?
- Schritt-für-Schritt-Anleitung,
- erwartetes Ergebnis,
- wann muss ich ein Ticket erstellen?
- welche Informationen soll ich im Ticket angeben?
- Link zu weiterem Support.

Benutzerartikel sollten keine unnötigen internen Fachbegriffe enthalten.

---

**Struktur eines Runbooks**

Ein Runbook ist eine betriebliche Schritt-für-Schritt-Anleitung.

Mögliche Inhalte:

- Zweck,
- betroffener Service,
- Voraussetzungen,
- benötigte Berechtigungen,
- Sicherheits- oder Risiko-Hinweise,
- genaue Schritte,
- Prüfpunkte,
- erwartete Ergebnisse,
- Abbruchkriterien,
- Rollback,
- Eskalation,
- Dokumentation nach Durchführung.

Runbooks sind besonders wichtig für wiederkehrende technische Betriebsaufgaben.

---

**Titel und Suchbegriffe**

Der Titel sollte so gewählt werden, dass Benutzer oder Service Desk den Artikel finden.

Ungeeignet:

> Fehler 0x80231-A Spezialfall

Besser:

> VPN verbindet nach Ruhezustand nicht mehr

Ungeeignet:

> Authentifizierungsproblem Anwendung X

Besser:

> Anmeldung im Mitarbeiterportal schlägt fehl

Ein Artikel kann zusätzlich Synonyme oder typische Fehlermeldungen enthalten.

---

**Artikel kurz und praktisch halten**

Zu lange Artikel werden oft nicht gelesen.

Besser sind:

- klare Überschriften,
- kurze Schritte,
- konkrete Beispiele,
- Tabellen bei Varianten,
- Hinweise auf Risiken,
- Links zu tieferer Dokumentation.

Ein Artikel sollte nicht versuchen, ein ganzes Handbuch zu ersetzen.

Für tiefe technische Details kann auf Runbooks oder Fachteamdokumentation verwiesen werden.

---

**Wissensfreigabe**

Nicht jeder Artikel darf ohne Prüfung veröffentlicht werden.

Freigabe kann erforderlich sein bei:

- Sicherheitsanweisungen,
- Workarounds mit Risiko,
- Benutzerkommunikation,
- Anleitungen mit Administratorrechten,
- Datenschutzbezug,
- Änderungen an kritischen Services,
- rechtlichen oder vertraglichen Aussagen.

Die Freigabe muss aber zum Risiko passen.

Zu viel Freigabeaufwand verhindert schnelle Wissensnutzung.

---

**Zugriffsschutz**

Knowledge-Artikel können unterschiedliche Sichtbarkeit haben.

Beispiele:

| Sichtbarkeit | Beispiel |
|---|---|
| öffentlich für Benutzer | MFA einrichten |
| intern für Service Desk | Prüfschritte bei VPN-Störung |
| nur Fachteam | Datenbank-Restart-Runbook |
| vertraulich | Sicherheitsvorfall-Prozess |
| Management | Risiko- und Statusübersicht |

Zu viele Einschränkungen verhindern Nutzen.

Zu wenig Einschränkung kann Sicherheitsrisiken erzeugen.

---

**Knowledge Owner**

Ein Knowledge Owner ist verantwortlich für Inhalt und Aktualität eines Artikels.

Aufgaben:

- fachliche Korrektheit prüfen,
- Review durchführen,
- Änderungen einarbeiten,
- veraltete Inhalte entfernen,
- Feedback bewerten,
- Gültigkeit bestätigen,
- verwandte Artikel prüfen.

Ohne Owner veralten Artikel häufig.

---

**Review-Datum**

Ein Review-Datum zeigt, wann ein Artikel überprüft werden muss.

Besonders wichtig bei:

- sicherheitsrelevanten Artikeln,
- Workarounds,
- Known Errors,
- Benutzeranleitungen mit Screenshots,
- Runbooks,
- Artikeln zu kritischen Services,
- Lieferantenabhängigkeiten.

Ein Artikel kann auch vor dem Review-Datum aktualisiert werden, wenn ein Change oder Release den Inhalt verändert.

---

**Wissensqualität messen**

Mögliche Kennzahlen:

| Kennzahl | mögliche Aussage |
|---|---|
| häufig genutzte Artikel | wichtiges Wissen |
| schlechte Bewertungen | Artikel unklar oder falsch |
| Suchanfragen ohne Treffer | Wissenslücke |
| Artikel ohne Owner | Pflegeproblem |
| Artikel ohne Review | Aktualität unsicher |
| Tickets trotz Artikel | Artikel nicht auffindbar oder nicht hilfreich |
| Workarounds ohne Artikel | Wissen nicht verfügbar |
| alte Artikel mit hoher Nutzung | Risiko veralteter Informationen |

Kennzahlen müssen mit Feedback und Kontext bewertet werden.

---

**Knowledge Management und KCS**

Viele Organisationen orientieren sich an Ansätzen wie **Knowledge-Centered Service (KCS)**.

Grundidee:

- Wissen entsteht während der Arbeit,
- Lösungen werden beim Bearbeiten von Tickets erfasst,
- Artikel werden durch Nutzung verbessert,
- Wissen wird nicht erst nachträglich als Zusatzaufgabe gepflegt.

Wichtig:

KCS ist ein Praxisansatz und nicht identisch mit ITIL.

Er kann Knowledge Management sinnvoll ergänzen.

---

**Wissen während der Arbeit erfassen**

Gute Praxis ist:

- Wenn ein Incident gelöst wird, prüfe, ob Wissen dokumentiert werden sollte.
- Wenn ein Artikel fehlt, erstelle einen Entwurf.
- Wenn ein Artikel falsch ist, markiere oder korrigiere ihn.
- Wenn ein Workaround genutzt wird, verknüpfe ihn.
- Wenn ein Known Error entsteht, veröffentliche passende Informationen.
- Wenn ein Release kommt, aktualisiere relevante Artikel.

Wissen sollte dort entstehen, wo die Arbeit stattfindet.

---

**Typische Fehler**

**Fehler 1**

Knowledge Base wird als Ablage für alte Dokumente genutzt.

---

**Fehler 2**

Artikel haben keinen Owner.

---

**Fehler 3**

Artikel werden veröffentlicht, aber nie überprüft.

---

**Fehler 4**

Benutzerartikel sind zu technisch.

---

**Fehler 5**

Interne Runbooks sind für Benutzer sichtbar.

---

**Fehler 6**

Workarounds stehen nur in Tickets.

---

**Fehler 7**

Known Errors werden nicht mit Artikeln verknüpft.

---

**Fehler 8**

Service Desk nutzt vorhandenes Wissen nicht.

---

**Fehler 9**

Suchbegriffe passen nicht zur Sprache der Benutzer.

---

**Fehler 10**

Nach Changes und Releases werden Artikel nicht aktualisiert.

---

**Fehler 11**

Feedback wird gesammelt, aber nicht bearbeitet.

---

**Fehler 12**

Veraltete Artikel bleiben als aktuelle Lösung sichtbar.

---

**Praxisbeispiel: VPN-Fehler**

**Situation**

Benutzer verlieren nach dem Ruhezustand die VPN-Verbindung.

**Problem**

Der Service Desk erklärt den Workaround jedes Mal neu.

**Knowledge Management**

Ein Artikel wird erstellt mit:

- Symptomen,
- betroffener Clientversion,
- Prüfschritten,
- Workaround,
- Eskalationsweg,
- Known-Error-Verknüpfung.

**Nutzen**

Neue Incidents werden schneller gelöst.

Der Service Desk arbeitet einheitlicher.

---

**Praxisbeispiel: MFA-Einrichtung**

**Situation**

Viele Benutzer erstellen Tickets zur MFA-Einrichtung.

**Analyse**

Der Self-Service-Artikel ist schwer auffindbar und zu technisch.

**Verbesserung**

- neuer Titel mit Benutzerbegriffen,
- klare Schritt-für-Schritt-Anleitung,
- Screenshots,
- Abschnitt „Wann muss ich ein Ticket erstellen?“,
- Link direkt im Serviceportal.

**Nutzen**

Weniger Tickets und bessere Benutzererfahrung.

---

**Praxisbeispiel: Change macht Artikel veraltet**

**Situation**

Nach einem Release ändern sich Menüpfade im Mitarbeiterportal.

**Problem**

Der alte Knowledge-Artikel zeigt falsche Schritte.

**Folge**

Benutzer erstellen Tickets, obwohl die Funktion vorhanden ist.

**Verbesserung**

Change-Abschluss enthält künftig die Prüfung betroffener Knowledge-Artikel.

---

**Praxisbeispiel: Runbook fehlt**

**Situation**

Ein Dienst muss regelmäßig kontrolliert neu gestartet werden.

**Problem**

Nur ein erfahrener Administrator kennt die genaue Reihenfolge.

**Risiko**

Bei Abwesenheit wird der Dienst falsch neu gestartet.

**Knowledge Management**

Ein Runbook wird erstellt mit:

- Voraussetzungen,
- Schritten,
- Prüfungen,
- Abbruchkriterien,
- Rollback,
- Eskalationsweg.

**Nutzen**

Die Aufgabe wird sicherer und wiederholbarer.

---

**Checkliste Knowledge-Artikel erstellen**

- [ ] Zielgruppe festgelegt
- [ ] Problem oder Thema klar beschrieben
- [ ] betroffener Service genannt
- [ ] Symptome oder Anlass beschrieben
- [ ] Voraussetzungen genannt
- [ ] Schritte verständlich formuliert
- [ ] erwartetes Ergebnis genannt
- [ ] Risiken oder Einschränkungen beschrieben
- [ ] Eskalationsweg angegeben
- [ ] verwandte Artikel verknüpft
- [ ] Owner eingetragen
- [ ] Review-Datum gesetzt

---

**Checkliste Benutzerartikel**

- [ ] einfache Sprache
- [ ] keine unnötigen internen Begriffe
- [ ] klare Schrittfolge
- [ ] Screenshots aktuell, falls verwendet
- [ ] Suchbegriffe der Benutzer berücksichtigt
- [ ] Voraussetzungen genannt
- [ ] erwartetes Ergebnis beschrieben
- [ ] Ticketweg erklärt
- [ ] keine vertraulichen internen Informationen enthalten

---

**Checkliste interner Supportartikel**

- [ ] bekannte Symptome beschrieben
- [ ] betroffene Services oder CIs verknüpft
- [ ] Prüfschritte enthalten
- [ ] Workaround beschrieben
- [ ] Abbruchkriterien genannt
- [ ] Eskalationskriterien definiert
- [ ] Known Error verknüpft, falls vorhanden
- [ ] Risiken beschrieben
- [ ] Owner und Review-Datum vorhanden

---

**Checkliste Knowledge-Pflege**

- [ ] Artikel mit hohem Nutzungsgrad geprüft
- [ ] schlecht bewertete Artikel überprüft
- [ ] Suchanfragen ohne Treffer ausgewertet
- [ ] Artikel ohne Owner bereinigt
- [ ] Artikel ohne Review-Datum geprüft
- [ ] veraltete Artikel archiviert
- [ ] Artikel nach Changes aktualisiert
- [ ] Artikel nach Releases aktualisiert
- [ ] Feedback bearbeitet
- [ ] doppelte Artikel zusammengeführt

---

**Bedeutung für Fachinformatiker für Systemintegration**

Fachinformatiker besitzen viel praktisches Betriebswissen.

Dieses Wissen ist besonders wertvoll, wenn es dokumentiert und nutzbar gemacht wird.

Im Arbeitsalltag bedeutet das:

- Lösungen aus Incidents als Wissen sichern,
- wiederkehrende Fehler als Artikel dokumentieren,
- technische Runbooks schreiben,
- Workarounds sauber beschreiben,
- bekannte Risiken nennen,
- Service Desk mit Prüfschritten unterstützen,
- nach Changes Dokumentation aktualisieren,
- und veraltete Artikel melden oder korrigieren.

Gute Wissensarbeit spart nicht nur Zeit.

Sie macht IT-Betrieb zuverlässiger und weniger abhängig von Einzelpersonen.

---

**Zusammenfassung**

> Wissensbedarf erkennen  
> ↓  
> Wissen während der Arbeit erfassen  
> ↓  
> Zielgruppe und Zweck festlegen  
> ↓  
> Artikel strukturiert erstellen  
> ↓  
> fachlich prüfen  
> ↓  
> veröffentlichen und auffindbar machen  
> ↓  
> in Incident, Problem, Change und Service Desk nutzen  
> ↓  
> Feedback auswerten  
> ↓  
> Artikel aktualisieren oder archivieren  
> ↓  
> Wissensqualität kontinuierlich verbessern

---

**Merksätze**

> Wissen ist nur wertvoll, wenn es gefunden, verstanden und genutzt wird.

> Eine Knowledge Base ist kein Ablageort für beliebige Dokumente.

> Benutzer, Service Desk und Fachteam benötigen unterschiedliche Detailtiefe.

> Workarounds gehören nicht nur ins Ticket, sondern in nutzbare Knowledge-Artikel.

> Nach Changes und Releases muss Wissen aktualisiert werden.

> Veraltetes Wissen kann neue Incidents verursachen.

> Gute Wissensarbeit reduziert Abhängigkeit von Einzelpersonen.

---

**Verwandte Seiten**

- 7.2 Knowledge-Artikel, Runbooks und FAQ
- 7.3 Known Errors, Workarounds und Wissensnutzung im Service Desk
- 7.4 Self-Service und Benutzerwissen
- 7.5 Knowledge Management im Zusammenspiel mit Incident, Problem und Change
- Incident Management
- Problem Management
- Change Enablement
- Release Management
- Service Configuration Management
- Continual Improvement

---

**Quellen und Versionsstand**

**Offizielle Grundlagen**

- PeopleCert – ITIL Practice Guide: Knowledge Management
- PeopleCert – ITIL Practice Guide: Incident Management
- PeopleCert – ITIL Practice Guide: Problem Management
- PeopleCert – ITIL Practice Guide: Change Enablement
- PeopleCert – ITIL Practice Guide: Release Management
- ITIL Foundation – Version 5

**Ergänzende Praxiseinordnung**

- Knowledge-Centered Service als verbreiteter Praxisansatz für Wissensarbeit im Support

**Einordnung**

Die dargestellten:

- Artikeltypen,
- Checklisten,
- Rollenhinweise,
- Lebenszyklusmodelle,
- Qualitätskriterien,
- und Praxisbeispiele

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

- Knowledge-Artikel-Vorlage,
- Review-Frequenz,
- Knowledge-Base-Struktur,
- Rollenverteilung,
- KCS-Nutzung,
- oder Toolauswahl

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

- Services,
- Zielgruppen,
- Supportmodell,
- Sicherheitsanforderungen,
- Knowledge-Werkzeuge,
- Datenqualität,
- Organisation,
- Change-Modell,
- 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

# 7.2 Knowledge-Artikel, Runbooks und FAQ

> **Kurz erklärt**
>
> Knowledge-Artikel, Runbooks und FAQ sind unterschiedliche Formen von dokumentiertem Wissen.
>
> **Knowledge-Artikel** helfen bei wiederkehrenden Fragen, Fehlerbildern, Workarounds oder Standardlösungen.
>
> **Runbooks** beschreiben konkrete betriebliche Abläufe Schritt für Schritt.
>
> **FAQ** beantworten häufige Fragen kurz und verständlich.
>
> Entscheidend ist, dass die Wissensform zur Zielgruppe, zum Risiko und zum Anwendungsfall passt.

---

**Warum verschiedene Wissensformen wichtig sind**

Nicht jedes Wissen sollte gleich dokumentiert werden.

Ein Benutzer benötigt eine andere Anleitung als ein Administrator.

Der Service Desk benötigt andere Informationen als ein Fachteam.

Beispiele:

- Benutzer braucht: „Wie richte ich MFA neu ein?“
- Service Desk braucht: „Welche Prüfschritte bei MFA-Problemen?“
- Fachteam braucht: „Wie wird der Identity-Dienst kontrolliert neu gestartet?“
- Management braucht: „Welche Auswirkungen hat der bekannte Fehler?“
- Security Team braucht: „Welche Meldewege gelten bei verdächtigen Anmeldungen?“

Wenn alle Informationen in einem einzigen langen Dokument stehen, wird Wissen schwer nutzbar.

Besser ist eine passende Struktur nach Zweck und Zielgruppe.

---

**Knowledge-Artikel**

Ein Knowledge-Artikel beschreibt nutzbares Wissen zu einem konkreten Thema.

Typische Inhalte:

- Fehlerbild,
- Ursache oder bekannte Ursache,
- Lösung,
- Workaround,
- Prüfschritte,
- Eskalationsweg,
- Benutzeranleitung,
- technische Hinweise,
- bekannte Einschränkungen,
- verwandte Artikel.

Knowledge-Artikel können intern oder für Benutzer sichtbar sein.

Wichtig ist, dass sie auffindbar, aktuell und verständlich sind.

---

**Typische Knowledge-Artikel**

| Artikeltyp | Beispiel |
|---|---|
| **Lösungsartikel** | VPN verbindet nach Ruhezustand nicht mehr |
| **Workaround-Artikel** | PDF-Export schlägt fehl – alternative Ausgabe nutzen |
| **Known-Error-Artikel** | Client-Version 5.8 verliert VPN-Tunnelzustand |
| **Benutzerartikel** | Passwort über Self-Service zurücksetzen |
| **Supportartikel** | Erstdiagnose bei DNS-Problemen |
| **Technischer Artikel** | Zertifikat für Webservice prüfen |
| **Sicherheitsartikel** | Verdächtige E-Mail melden |
| **Serviceartikel** | Supportzeiten und Kontaktweg für Mitarbeiterportal |

Der Artikeltyp sollte klar sein, damit Inhalt und Detailtiefe passen.

---

**Runbooks**

Ein Runbook ist eine konkrete Schritt-für-Schritt-Anleitung für wiederkehrende Betriebsaufgaben.

Typische Runbooks:

- Dienst kontrolliert neu starten,
- Zertifikat erneuern,
- Backup prüfen,
- Restore testen,
- Server nach Update prüfen,
- Druckwarteschlange bereinigen,
- Monitoringalarm bearbeiten,
- Benutzergruppe nach Standardprozess anpassen,
- Anwendung nach Deployment testen,
- Notfallumschaltung durchführen.

Runbooks sind besonders wichtig bei Aufgaben, die korrekt, sicher und wiederholbar ausgeführt werden müssen.

---

**FAQ**

FAQ bedeutet „Frequently Asked Questions“.

Eine FAQ beantwortet häufige Fragen kurz und verständlich.

Beispiele:

- Wie ändere ich mein Passwort?
- Warum muss ich MFA verwenden?
- Wo finde ich das Serviceportal?
- Wann ist der Service Desk erreichbar?
- Was mache ich bei verlorenem Smartphone?
- Wie beantrage ich Standardsoftware?
- Warum ist ein Wartungsfenster notwendig?

FAQ eignen sich besonders für Benutzerwissen.

Sie ersetzen aber keine vollständigen Runbooks oder technischen Supportartikel.

---

**Knowledge-Artikel, Runbook und FAQ unterscheiden**

| Form | Zweck | Zielgruppe | Beispiel |
|---|---|---|---|
| **Knowledge-Artikel** | Wissen zu Fehler, Lösung oder Workaround bereitstellen | Benutzer, Service Desk, Fachteam | VPN-Fehler erkennen und lösen |
| **Runbook** | betriebliche Aufgabe sicher ausführen | IT-Betrieb, Fachteam, Service Desk | Dienst kontrolliert neu starten |
| **FAQ** | häufige Fragen kurz beantworten | Benutzer, Service Desk | Wie setze ich mein Passwort zurück? |

Die Grenzen können sich überschneiden.

Wichtig ist, dass der Inhalt im Alltag gut nutzbar ist.

---

**Zielgruppe zuerst klären**

Vor dem Schreiben muss klar sein:

- Wer liest den Artikel?
- Was möchte die Person erreichen?
- Wie viel Vorwissen hat sie?
- Welche Berechtigungen besitzt sie?
- Darf sie die Schritte selbst ausführen?
- Welche Risiken bestehen?
- Wann muss eskaliert werden?
- Welche Begriffe nutzt die Zielgruppe bei der Suche?

Ein Benutzerartikel sollte anders geschrieben sein als ein internes Runbook.

---

**Beispiel: Gleiches Thema, verschiedene Zielgruppen**

Thema:

> VPN verbindet nicht.

**Benutzerartikel**

- einfache Sprache,
- wenige Schritte,
- keine internen Details,
- Hinweis, wann ein Ticket erstellt werden soll.

**Service-Desk-Artikel**

- Symptome,
- Diagnosefragen,
- Clientversion prüfen,
- Workaround,
- Eskalationskriterien.

**Fachteam-Runbook**

- technische Logs,
- Gatewayprüfung,
- Zertifikatsprüfung,
- Konfigurationsprüfung,
- Herstellerhinweise,
- dauerhafte Maßnahmen.

Ein Thema kann also mehrere Artikel benötigen.

---

**Gute Titel**

Der Titel entscheidet oft, ob ein Artikel gefunden wird.

Ungeeignet:

> Fehler 0x23A bei Authentifizierung

Besser:

> Anmeldung im Mitarbeiterportal schlägt fehl

Ungeeignet:

> Netzwerkproblem nach Standby

Besser:

> VPN verbindet nach Ruhezustand nicht mehr

Ungeeignet:

> Client Workaround

Besser:

> VPN-Client vollständig neu starten

Ein guter Titel nutzt Begriffe, nach denen Zielgruppen tatsächlich suchen.

---

**Suchbegriffe berücksichtigen**

Artikel sollten typische Begriffe enthalten.

Beispiele:

- Fehlermeldung,
- Symptom,
- Service-Name,
- Anwendung,
- Benutzerbegriff,
- technische Bezeichnung,
- Abkürzung,
- alternative Schreibweise.

Beispiel:

Ein Artikel zu Mehrfaktor-Authentifizierung sollte auch Begriffe enthalten wie:

- MFA,
- 2FA,
- Authenticator-App,
- neues Smartphone,
- Anmeldung bestätigen.

So wird der Artikel besser gefunden.

---

**Struktur eines Knowledge-Artikels**

Ein guter Knowledge-Artikel kann enthalten:

- Titel,
- Kurzbeschreibung,
- Zielgruppe,
- betroffener Service,
- Symptome oder Anlass,
- Voraussetzungen,
- Lösung oder Workaround,
- Schritt-für-Schritt-Anleitung,
- erwartetes Ergebnis,
- Risiken oder Einschränkungen,
- Eskalationsweg,
- verwandte Artikel,
- Owner,
- Review-Datum.

Nicht jeder Artikel benötigt alle Punkte.

Die Struktur sollte zum Zweck passen.

---

**Beispielstruktur für Service-Desk-Artikel**

| Abschnitt | Inhalt |
|---|---|
| **Titel** | VPN verbindet nach Ruhezustand nicht mehr |
| **Kurzbeschreibung** | bekannter Fehler bei bestimmter Clientversion |
| **Symptome** | Verbindung bricht nach Standby ab |
| **Betroffen** | Windows-Notebooks mit Client-Version 5.8 |
| **Prüfschritte** | Version prüfen, Fehlerbild abgleichen |
| **Workaround** | Client vollständig beenden und neu starten |
| **Eskalation** | bei anderer Version an Netzwerkteam |
| **Verknüpfung** | Known Error, Problem Record, Change |
| **Review** | nach Rollout neuer Clientversion prüfen |

Diese Struktur hilft, Fälle schnell und einheitlich zu bearbeiten.

---

**Struktur eines Runbooks**

Ein Runbook sollte besonders genau sein.

Mögliche Struktur:

- Zweck,
- betroffener Service,
- Zielgruppe,
- Voraussetzungen,
- benötigte Berechtigungen,
- benötigte Werkzeuge,
- Risiken,
- Vorbereitung,
- genaue Schritte,
- Prüfpunkte,
- erwartetes Ergebnis,
- Abbruchkriterien,
- Rollback oder Rückweg,
- Eskalationsweg,
- Dokumentation nach Durchführung,
- Owner,
- Review-Datum.

Bei kritischen Aufgaben sind Abbruchkriterien und Rollback besonders wichtig.

---

**Beispielstruktur für Runbook**

| Abschnitt | Inhalt |
|---|---|
| **Zweck** | Dienst kontrolliert neu starten |
| **Voraussetzungen** | Wartungsfenster oder Freigabe vorhanden |
| **Risiko** | Benutzer können kurzzeitig nicht arbeiten |
| **Vorbereitung** | Monitoring prüfen, aktuelle Sessions prüfen |
| **Schritte** | Dienst stoppen, Status prüfen, Dienst starten |
| **Prüfung** | Anmeldung, Logs, Monitoring |
| **Abbruchkriterium** | Dienst startet nicht innerhalb definierter Zeit |
| **Rollback** | vorherige Konfiguration wiederherstellen |
| **Eskalation** | Fachteam oder Bereitschaft informieren |

Runbooks sollten so geschrieben sein, dass sie auch unter Zeitdruck verständlich bleiben.

---

**Struktur einer FAQ**

Eine FAQ sollte kurz und direkt sein.

Mögliche Struktur:

- Frage,
- kurze Antwort,
- einfache Schritte,
- Link zu ausführlicher Anleitung,
- Hinweis auf Supportweg.

Beispiel:

**Frage**

> Wie setze ich mein Passwort zurück?

**Antwort**

> Nutzen Sie den Self-Service-Passwort-Reset im Serviceportal. Halten Sie Ihre zweite Anmeldemethode bereit. Wenn Sie keinen Zugriff mehr auf MFA haben, erstellen Sie ein Ticket an den Service Desk.

FAQ sollten nicht zu langen Handbüchern werden.

---

**Benutzerartikel schreiben**

Benutzerartikel sollten:

- einfache Sprache nutzen,
- kurze Schritte enthalten,
- Fachbegriffe vermeiden oder erklären,
- keine internen Systeme unnötig nennen,
- keine vertraulichen Informationen enthalten,
- klare Screenshots nutzen, falls sinnvoll,
- erwartetes Ergebnis beschreiben,
- Supportweg nennen.

Ungeeignet:

> Prüfen Sie, ob Ihr Identity Provider den Token korrekt verarbeitet.

Besser:

> Öffnen Sie die Authenticator-App und bestätigen Sie die Anmeldung erneut.

---

**Interne Supportartikel schreiben**

Interne Supportartikel dürfen technischer sein.

Sie sollten enthalten:

- Fehlerbild,
- betroffene Services,
- betroffene Versionen,
- typische Ursachen,
- Prüfschritte,
- Workaround,
- Risiken,
- Eskalationskriterien,
- Verknüpfung zu CI, Problem oder Known Error,
- Hinweise zur Dokumentation im Ticket.

Service-Desk-Artikel sollten schnell nutzbar sein.

Sie sollten keine unnötig langen Hintergrundtexte enthalten.

---

**Technische Fachartikel schreiben**

Technische Fachartikel können detaillierter sein.

Geeignet sind:

- Logpfade,
- Konfigurationsparameter,
- Architekturhinweise,
- Schnittstellen,
- Abhängigkeiten,
- Datenbankdetails,
- Versionshinweise,
- Fehleranalysen,
- Herstellerinformationen,
- Risiken und Nebenwirkungen.

Wichtig:

Technische Fachartikel sollten trotzdem strukturiert und überprüfbar sein.

Ein unstrukturierter Expertennotizzettel hilft nur begrenzt.

---

**Runbooks und Sicherheit**

Runbooks können sicherheitskritische Schritte enthalten.

Beispiele:

- Administratorrechte verwenden,
- Firewall-Regel ändern,
- Zertifikat austauschen,
- Datenbank wiederherstellen,
- Benutzerrechte ändern,
- Dienst mit erhöhten Rechten starten,
- Sicherheitsalarm bearbeiten.

Dann müssen enthalten sein:

- Berechtigungsanforderungen,
- Freigabeanforderungen,
- Risiken,
- Abbruchkriterien,
- Protokollierung,
- Eskalation,
- und Zugriffsschutz des Artikels.

Nicht jedes Runbook darf für alle sichtbar sein.

---

**Screenshots verwenden**

Screenshots können helfen, wenn Benutzer eine Oberfläche bedienen müssen.

Vorteile:

- Schritte werden verständlicher,
- Menüpfade sind leichter erkennbar,
- Benutzer machen weniger Fehler.

Risiken:

- Screenshots veralten schnell,
- sensible Daten können sichtbar sein,
- Oberfläche kann je nach Version abweichen,
- Artikel wird schwerer zu pflegen.

Screenshots sollten regelmäßig geprüft und bei Changes aktualisiert werden.

---

**Tabellen verwenden**

Tabellen eignen sich gut für Varianten.

Beispiel:

| Situation | Vorgehen |
|---|---|
| Benutzer kennt Passwort | Passwort über Portal ändern |
| Benutzer kennt Passwort nicht | Self-Service-Reset nutzen |
| Benutzer hat neues Smartphone | MFA-Methode neu registrieren |
| Benutzer hat keinen MFA-Zugriff | Ticket an Service Desk erstellen |

Tabellen helfen, Entscheidungen schnell sichtbar zu machen.

---

**Checklisten verwenden**

Checklisten sind sinnvoll für wiederkehrende Prüfungen.

Beispiele:

- Server nach Update prüfen,
- Backupjob kontrollieren,
- Change vorbereiten,
- Zertifikat erneuern,
- neuen Arbeitsplatz bereitstellen,
- Incident eskalieren.

Eine gute Checkliste ist kurz, eindeutig und vollständig genug.

Sie sollte keine wichtigen Entscheidungen verstecken.

---

**Entscheidungsbäume verwenden**

Entscheidungsbäume helfen bei Diagnose.

Beispiel:

    Benutzer kann sich nicht anmelden
        ↓
    Passwort bekannt?
        ↓
    ja → MFA prüfen
        ↓
    nein → Self-Service-Reset prüfen
        ↓
    kein MFA-Zugriff → Service Desk Ticket
        ↓
    Konto gesperrt → Entsperrprozess prüfen

Entscheidungsbäume sollten nicht zu komplex werden.

Bei zu vielen Verzweigungen ist eine Tabelle oft besser.

---

**Artikel mit Services und CIs verknüpfen**

Knowledge-Artikel sollten mit relevanten Services oder Configuration Items verknüpft werden.

Vorteile:

- Artikel werden im Incident schneller vorgeschlagen,
- betroffene Versionen sind erkennbar,
- Known Errors werden leichter gefunden,
- Service Desk sieht passende Runbooks,
- Changes können betroffene Artikel prüfen,
- veraltete Artikel fallen eher auf.

Beispiel:

Ein VPN-Artikel wird verknüpft mit:

- VPN-Service,
- VPN-Client-Version,
- VPN-Gateway,
- Identity Provider,
- Known Error,
- Problem Record.

---

**Artikel mit Incidents verknüpfen**

Wenn ein Artikel zur Lösung eines Incidents genutzt wurde, sollte er im Ticket verknüpft werden.

Nutzen:

- häufig genutzte Artikel werden sichtbar,
- Artikelqualität kann bewertet werden,
- wiederkehrende Fehler werden erkennbar,
- Service Desk arbeitet einheitlicher,
- Problem Management erkennt Muster.

Wenn viele Tickets trotz Artikel entstehen, sollte geprüft werden, ob der Artikel unklar, nicht auffindbar oder technisch unzureichend ist.

---

**Artikel mit Problems und Known Errors verknüpfen**

Bei bekannten Fehlern ist die Verknüpfung besonders wichtig.

Ein Known-Error-Artikel sollte enthalten:

- Fehlerbild,
- betroffene Versionen,
- Ursache oder wahrscheinliche Ursache,
- Workaround,
- dauerhafte Lösung,
- Status,
- Eskalationskriterien,
- Problem Record,
- geplanter Change.

Dadurch können zukünftige Incidents schneller bearbeitet werden.

---

**Artikel mit Changes und Releases verknüpfen**

Changes und Releases können Knowledge-Artikel verändern.

Beispiele:

- Menüpfad ändert sich,
- neue Version hat anderes Fehlerbild,
- Workaround ist nicht mehr gültig,
- Known Error wird behoben,
- neuer Service wird eingeführt,
- Supportweg ändert sich,
- Screenshots werden veraltet.

Deshalb sollte bei Change- und Release-Abschluss geprüft werden:

> Welche Knowledge-Artikel müssen aktualisiert werden?

---

**Versionierung von Artikeln**

Bei wichtigen Artikeln kann Versionierung sinnvoll sein.

Zu dokumentieren ist:

- Erstellungsdatum,
- letzte Änderung,
- Autor oder Owner,
- fachliche Prüfung,
- gültige Serviceversion,
- Änderungsgrund,
- Review-Datum.

Versionierung hilft bei Nachvollziehbarkeit.

Besonders wichtig ist sie bei sicherheitskritischen Runbooks, Workarounds und Betriebsanleitungen.

---

**Review und Ablaufdatum**

Artikel sollten regelmäßig geprüft werden.

Besonders wichtig bei:

- Workarounds,
- Known Errors,
- Runbooks,
- Sicherheitsartikeln,
- Benutzerartikeln mit Screenshots,
- Artikeln zu kritischen Services,
- Artikeln zu Lieferantenprodukten.

Ein Ablaufdatum oder Review-Datum verhindert, dass veraltetes Wissen dauerhaft als aktuelle Lösung erscheint.

---

**Owner für Artikel**

Jeder wichtige Artikel sollte einen Owner besitzen.

Der Owner ist verantwortlich für:

- fachliche Korrektheit,
- Aktualität,
- Review,
- Feedbackbewertung,
- Freigabe von Änderungen,
- Archivierung,
- und Verknüpfung mit Services oder CIs.

Ohne Owner bleibt unklar, wer einen Artikel korrigieren darf oder muss.

---

**Freigabe von Artikeln**

Nicht jeder Artikel benötigt dieselbe Freigabe.

Beispiele:

| Artikel | mögliche Freigabe |
|---|---|
| einfache FAQ | Service Desk oder Knowledge Owner |
| Benutzeranleitung | Service Owner oder Kommunikation |
| technisches Runbook | Fachteam |
| Sicherheitsartikel | Information Security |
| Workaround mit Risiko | Fachteam und Service Owner |
| Known Error | Problem Management oder Fachteam |

Die Freigabe sollte zum Risiko passen.

Zu viel Freigabeaufwand verhindert schnelle Wissensnutzung.

---

**Zugriffsschutz**

Artikel können unterschiedliche Sichtbarkeit haben.

Beispiele:

- öffentlich für alle Benutzer,
- intern für Service Desk,
- nur Fachteam,
- nur Management,
- nur Security,
- vertraulich wegen Sicherheitsdetails.

Zu prüfen ist:

- enthält der Artikel interne Systeme?
- enthält er Sicherheitsinformationen?
- enthält er Administratorbefehle?
- enthält er personenbezogene Daten?
- enthält er Lieferanteninformationen?
- darf ein Benutzer diese Schritte selbst ausführen?

Falsche Sichtbarkeit kann Sicherheits- oder Datenschutzrisiken erzeugen.

---

**Qualität eines Artikels prüfen**

Ein Artikel ist gut, wenn:

- Zielgruppe klar ist,
- Zweck klar ist,
- Titel suchbar ist,
- Schritte verständlich sind,
- Inhalt fachlich stimmt,
- Risiken genannt werden,
- Eskalation klar ist,
- Ergebnis prüfbar ist,
- Owner vorhanden ist,
- Review-Datum vorhanden ist,
- Artikel mit Service oder CI verknüpft ist.

Ein Artikel ist nicht gut, nur weil er lang ist.

---

**Häufige Qualitätsprobleme**

| Problem | Folge |
|---|---|
| Titel unklar | Artikel wird nicht gefunden |
| zu technisch | Benutzer verstehen ihn nicht |
| zu allgemein | Service Desk kann ihn nicht anwenden |
| kein Owner | Artikel veraltet |
| kein Review | Aktualität unklar |
| keine Eskalation | falsche Bearbeitung |
| keine Risiken | unsichere Anwendung |
| keine Servicezuordnung | Artikel wird nicht im richtigen Kontext gefunden |
| veraltete Screenshots | Benutzer folgen falschen Schritten |

---

**Kurzartikel und Tiefendokumentation kombinieren**

Manche Themen brauchen zwei Ebenen.

**Kurzartikel**

- Symptome,
- schnelle Lösung,
- Workaround,
- Eskalationsweg.

**Tiefendokumentation**

- technische Ursache,
- Architektur,
- Konfiguration,
- Logs,
- Hintergrund,
- dauerhafte Lösung.

Der Kurzartikel verweist auf die Tiefendokumentation.

So bleibt der Artikel im Support schnell nutzbar, ohne Fachdetails zu verlieren.

---

**Beispiel: Benutzerartikel MFA**

**Titel**

MFA auf einem neuen Smartphone einrichten

**Zielgruppe**

Benutzer

**Inhalt**

- wann der Artikel gilt,
- was vorbereitet werden muss,
- Schritt-für-Schritt-Anleitung,
- erwartetes Ergebnis,
- was bei fehlendem Zugriff zu tun ist,
- Link zum Service Desk.

**Nicht enthalten**

- interne Administrationsschritte,
- Sicherheitskonfiguration,
- technische Token-Details.

---

**Beispiel: Service-Desk-Artikel VPN**

**Titel**

VPN verbindet nach Ruhezustand nicht mehr

**Zielgruppe**

Service Desk

**Inhalt**

- Fehlerbild,
- betroffene Clientversion,
- Prüfschritte,
- Workaround,
- Ticketdokumentation,
- Eskalation an Netzwerkteam,
- Link zum Known Error.

**Nutzen**

Der Service Desk erkennt den bekannten Fall schneller und handelt einheitlich.

---

**Beispiel: Runbook Zertifikat erneuern**

**Titel**

Runbook: TLS-Zertifikat für Mitarbeiterportal erneuern

**Zielgruppe**

Plattform-Team

**Inhalt**

- Voraussetzungen,
- Freigabe,
- Backup der alten Konfiguration,
- Zertifikatsanforderung,
- Installation,
- Dienstneustart,
- Funktionstest,
- Monitoringprüfung,
- Rollback,
- Dokumentation,
- CMDB-Aktualisierung.

**Besonderheit**

Dieses Runbook ist sicherheits- und servicekritisch und benötigt fachliche Prüfung.

---

**Beispiel: FAQ Passwort**

**Frage**

Wie setze ich mein Passwort zurück?

**Antwort**

Nutzen Sie den Self-Service-Passwort-Reset im Serviceportal.

Wenn Sie keinen Zugriff auf Ihre zweite Anmeldemethode haben, erstellen Sie ein Ticket an den Service Desk.

**Link**

Ausführliche Anleitung: Passwort und MFA verwalten

---

**Typische Fehler**

**Fehler 1**

Alle Informationen werden in einen einzigen langen Artikel geschrieben.

---

**Fehler 2**

Zielgruppe ist nicht klar.

---

**Fehler 3**

Benutzerartikel enthalten interne technische Details.

---

**Fehler 4**

Runbooks enthalten keine Abbruchkriterien.

---

**Fehler 5**

Workarounds enthalten keine Risiken.

---

**Fehler 6**

Titel orientieren sich an Technik statt an Suchbegriffen der Zielgruppe.

---

**Fehler 7**

Artikel haben keinen Owner.

---

**Fehler 8**

Review-Datum fehlt.

---

**Fehler 9**

Screenshots werden nach Releases nicht aktualisiert.

---

**Fehler 10**

Knowledge-Artikel sind nicht mit Services, CIs, Incidents oder Problems verknüpft.

---

**Fehler 11**

Veraltete Artikel bleiben sichtbar.

---

**Fehler 12**

FAQ wird als Ersatz für vollständige Supportartikel verwendet.

---

**Checkliste Knowledge-Artikel**

- [ ] Zielgruppe festgelegt
- [ ] Titel ist suchbar
- [ ] betroffener Service genannt
- [ ] Symptome oder Anlass beschrieben
- [ ] Voraussetzungen genannt
- [ ] Lösung oder Workaround beschrieben
- [ ] Schritte verständlich formuliert
- [ ] erwartetes Ergebnis genannt
- [ ] Risiken oder Einschränkungen genannt
- [ ] Eskalationsweg beschrieben
- [ ] verwandte Artikel verknüpft
- [ ] Owner eingetragen
- [ ] Review-Datum gesetzt

---

**Checkliste Runbook**

- [ ] Zweck beschrieben
- [ ] Zielgruppe festgelegt
- [ ] betroffener Service genannt
- [ ] Voraussetzungen geprüft
- [ ] benötigte Berechtigungen genannt
- [ ] Risiken beschrieben
- [ ] Vorbereitungsschritte genannt
- [ ] Durchführungsschritte eindeutig
- [ ] Prüfpunkte enthalten
- [ ] erwartetes Ergebnis beschrieben
- [ ] Abbruchkriterien definiert
- [ ] Rollback oder Rückweg beschrieben
- [ ] Eskalationsweg genannt
- [ ] Dokumentation nach Durchführung beschrieben
- [ ] Owner und Review-Datum vorhanden

---

**Checkliste FAQ**

- [ ] häufige Frage klar formuliert
- [ ] kurze Antwort vorhanden
- [ ] einfache Sprache verwendet
- [ ] keine unnötigen internen Begriffe
- [ ] Link zu ausführlicher Anleitung vorhanden, falls nötig
- [ ] Supportweg genannt
- [ ] Zielgruppe eindeutig
- [ ] Artikel aktuell
- [ ] Owner vorhanden
- [ ] Review-Datum gesetzt

---

**Checkliste Artikelqualität**

- [ ] fachlich korrekt
- [ ] aktuell
- [ ] verständlich
- [ ] nicht unnötig lang
- [ ] für Zielgruppe geeignet
- [ ] über Suche auffindbar
- [ ] mit Service oder CI verknüpft
- [ ] Zugriffsschutz passend
- [ ] keine sensiblen Informationen falsch sichtbar
- [ ] Feedbackmöglichkeit vorhanden
- [ ] Nutzung wird ausgewertet
- [ ] veraltete Inhalte werden archiviert

---

**Bedeutung für Fachinformatiker für Systemintegration**

Fachinformatiker erstellen und nutzen viele Wissensformen.

Im Alltag bedeutet das:

- technische Lösungen als Knowledge-Artikel dokumentieren,
- wiederkehrende Betriebsaufgaben als Runbook beschreiben,
- Service Desk mit klaren Prüfschritten unterstützen,
- Benutzeranleitungen verständlich halten,
- Workarounds mit Risiken und Eskalation dokumentieren,
- Artikel nach Changes aktualisieren,
- veraltete Inhalte melden,
- und Wissen mit Services, CIs und Problems verknüpfen.

Gute Wissensdokumentation macht Betrieb weniger abhängig von Einzelpersonen und verbessert die Qualität im Support.

---

**Zusammenfassung**

> Wissensbedarf erkennen  
> ↓  
> Zielgruppe bestimmen  
> ↓  
> passende Wissensform wählen  
> ↓  
> Knowledge-Artikel, Runbook oder FAQ erstellen  
> ↓  
> Inhalt fachlich prüfen  
> ↓  
> Service, CI oder Problem verknüpfen  
> ↓  
> Artikel veröffentlichen  
> ↓  
> Nutzung und Feedback auswerten  
> ↓  
> Artikel aktualisieren oder archivieren

---

**Merksätze**

> Die Form des Wissens muss zum Zweck passen.

> Benutzerartikel, Supportartikel und Runbooks brauchen unterschiedliche Detailtiefe.

> Ein guter Titel entscheidet oft, ob Wissen gefunden wird.

> Runbooks benötigen klare Schritte, Prüfpunkte und Abbruchkriterien.

> FAQ beantworten häufige Fragen, ersetzen aber keine vollständige Betriebsdokumentation.

> Jeder wichtige Artikel braucht Owner, Review und passende Sichtbarkeit.

> Wissen ist nur nützlich, wenn es gefunden, verstanden und gepflegt wird.

---

**Verwandte Seiten**

- 7.1 Knowledge Management – Ziele, Begriffe und Grundlagen
- 7.3 Known Errors, Workarounds und Wissensnutzung im Service Desk
- 7.4 Self-Service und Benutzerwissen
- 7.5 Knowledge Management im Zusammenspiel mit Incident, Problem und Change
- Incident Management
- Problem Management
- Change Enablement
- Release Management
- Service Configuration Management

---

**Quellen und Versionsstand**

**Offizielle Grundlagen**

- PeopleCert – ITIL Practice Guide: Knowledge Management
- PeopleCert – ITIL Practice Guide: Incident Management
- PeopleCert – ITIL Practice Guide: Problem Management
- PeopleCert – ITIL Practice Guide: Change Enablement
- PeopleCert – ITIL Practice Guide: Service Desk
- ITIL Foundation – Version 5

**Ergänzende Praxiseinordnung**

- Knowledge-Centered Service als verbreiteter Praxisansatz für Wissensarbeit im Support

**Einordnung**

Die dargestellten:

- Artikelstrukturen,
- Runbook-Strukturen,
- FAQ-Beispiele,
- Checklisten,
- Qualitätskriterien,
- Freigabehinweise,
- und Praxisbeispiele

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

- Knowledge-Artikel-Vorlage,
- Runbook-Vorlage,
- FAQ-Struktur,
- Freigabematrix,
- Review-Frequenz,
- oder Toolauswahl

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

- Services,
- Zielgruppen,
- Supportmodell,
- Risiken,
- Sicherheitsanforderungen,
- Knowledge-Werkzeuge,
- Service Configuration Management,
- Change-Modell,
- 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

# 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

# 7.4 Self-Service und Benutzerwissen

> **Kurz erklärt**
>
> Self-Service bedeutet, dass Benutzer einfache Informationen, Anleitungen, Lösungen oder Anfragen selbstständig nutzen können, ohne direkt den Service Desk kontaktieren zu müssen.
>
> Benutzerwissen ist dafür die Grundlage.
>
> Gute Self-Service-Angebote helfen Benutzern schnell weiter, reduzieren Standardtickets und entlasten den Service Desk.
>
> Self-Service funktioniert aber nur, wenn Inhalte verständlich, aktuell, auffindbar und sicher nutzbar sind.

---

**Warum Self-Service wichtig ist**

Viele Anfragen im IT-Alltag wiederholen sich.

Beispiele:

- Passwort zurücksetzen,
- MFA neu einrichten,
- Drucker verbinden,
- WLAN einrichten,
- Standardsoftware beantragen,
- VPN-Anleitung finden,
- Status einer Störung prüfen,
- häufige Fehlermeldung verstehen,
- neues Gerät vorbereiten,
- Zugriff beantragen,
- Servicezeiten nachlesen.

Wenn Benutzer solche Themen selbst lösen können, entstehen Vorteile:

- schnellere Hilfe,
- weniger Wartezeit,
- weniger Standardtickets,
- entlasteter Service Desk,
- bessere Benutzererfahrung,
- einheitliche Antworten,
- weniger Rückfragen,
- und mehr Zeit für komplexe Störungen.

Self-Service ersetzt den Service Desk nicht.

Er ergänzt ihn für geeignete Themen.

---

**Self-Service ist mehr als eine Knowledge Base**

Eine Knowledge Base ist ein wichtiger Bestandteil.

Self-Service kann aber mehr umfassen.

Beispiele:

- Benutzeranleitungen,
- FAQ,
- Serviceportal,
- Statusseite,
- Request-Formulare,
- Passwort-Reset,
- Softwarekatalog,
- Chatbot,
- automatisierte Standardprozesse,
- Benutzerinformationen,
- interaktive Hilfen,
- geführte Fehlerdiagnose.

Self-Service bedeutet:

> Benutzer können passende Hilfe oder passende Services eigenständig finden und nutzen.

---

**Geeignete Self-Service-Themen**

Self-Service eignet sich besonders für:

- häufige Fragen,
- risikoarme Standardaufgaben,
- klare Schritt-für-Schritt-Anleitungen,
- wiederkehrende Requests,
- einfache Fehlerbilder,
- Statusinformationen,
- Standardsoftware,
- Passwort- und MFA-Themen,
- Drucker- und WLAN-Anleitungen,
- Onboarding-Informationen,
- bekannte Workarounds für Benutzer.

Nicht jedes Thema eignet sich für Self-Service.

Komplexe, sicherheitskritische oder riskante Tätigkeiten gehören weiterhin in kontrollierte Supportprozesse.

---

**Ungeeignete Self-Service-Themen**

Self-Service ist ungeeignet, wenn:

- Administratorrechte notwendig sind,
- Datenverlust möglich ist,
- Sicherheitsrisiken entstehen,
- Benutzer vertrauliche Informationen sehen würden,
- Ursache unklar ist,
- mehrere Systeme betroffen sein können,
- eine Freigabe erforderlich ist,
- gesetzliche oder Compliance-Vorgaben betroffen sind,
- falsche Anwendung großen Schaden verursachen kann.

Beispiel:

Ein Benutzer sollte nicht selbst Firewall-Regeln ändern können.

Ein Benutzer kann aber eine verständliche Anleitung erhalten, wie er eine Firewall-Freigabe korrekt beantragt.

---

**Benutzerwissen**

Benutzerwissen ist Wissen, das für Endbenutzer verständlich und nutzbar aufbereitet ist.

Typische Inhalte:

- einfache Anleitungen,
- kurze FAQ,
- Hinweise zu bekannten Störungen,
- Schritt-für-Schritt-Hilfen,
- Screenshots,
- Servicebeschreibungen,
- Voraussetzungen,
- Antragswege,
- Supportkontakte,
- Statusinformationen,
- Sicherheitsverhalten,
- Hinweise zur Ticket-Erstellung.

Benutzerwissen sollte nicht wie interne IT-Dokumentation geschrieben sein.

Es muss zur Sprache und Situation der Benutzer passen.

---

**Interne Sprache und Benutzersprache unterscheiden**

Ungeeignet:

> Prüfen Sie, ob Ihr Token im Identity Provider korrekt registriert ist.

Besser:

> Öffnen Sie Ihre Authenticator-App und prüfen Sie, ob Sie die Anmeldung bestätigen können.

Ungeeignet:

> Der Client verliert nach Sleep den Tunnel State.

Besser:

> Wenn Ihr VPN nach dem Ruhezustand nicht mehr verbindet, starten Sie den VPN-Client vollständig neu.

Ungeeignet:

> Erstellen Sie einen Incident mit Kategorie IAM/MFA/Auth.

Besser:

> Erstellen Sie ein Ticket mit dem Betreff „MFA funktioniert nicht“ und nennen Sie Ihr Gerät und die Fehlermeldung.

Benutzerwissen muss verständlich sein, nicht intern perfekt formuliert.

---

**Ziele von Self-Service**

Self-Service soll:

- Benutzer schneller unterstützen,
- Standardfragen reduzieren,
- einfache Lösungen direkt bereitstellen,
- Ticketqualität verbessern,
- Anfragen richtig kanalisieren,
- Service Desk entlasten,
- Wissen einheitlich bereitstellen,
- Wartezeiten verringern,
- Benutzerzufriedenheit erhöhen,
- und Supportprozesse effizienter machen.

Self-Service ist nur erfolgreich, wenn Benutzer ihn akzeptieren und nutzen.

---

**Voraussetzungen für guten Self-Service**

Guter Self-Service benötigt:

- verständliche Inhalte,
- gute Suche,
- klare Kategorien,
- aktuelle Artikel,
- einfache Formulare,
- passende Sprache,
- mobile Nutzbarkeit,
- Barrierearmut,
- klare Supportwege,
- gepflegte Serviceinformationen,
- regelmäßige Auswertung,
- und Rückmeldemöglichkeiten.

Ein Portal allein verbessert noch nichts.

Die Inhalte und Prozesse müssen funktionieren.

---

**Serviceportal**

Ein Serviceportal ist ein zentraler Einstiegspunkt für Benutzer.

Es kann enthalten:

- Knowledge Base,
- FAQ,
- Servicekatalog,
- Request-Formulare,
- Ticketstatus,
- Störungsmeldungen,
- Statusinformationen,
- Benutzeranleitungen,
- Softwarekatalog,
- Passwort-Reset,
- Kontaktmöglichkeiten.

Ein gutes Serviceportal beantwortet schnell:

- Was suche ich?
- Was kann ich selbst tun?
- Was kann ich beantragen?
- Wo sehe ich den Status?
- Wann muss ich ein Ticket erstellen?
- Welche Informationen werden benötigt?

---

**Servicekatalog im Self-Service**

Der Servicekatalog beschreibt verfügbare IT-Services aus Benutzersicht.

Beispiele:

- Standardsoftware beantragen,
- neues Benutzerkonto,
- Zugriff auf Anwendung,
- Hardware bestellen,
- Drucker einrichten,
- VPN-Zugang beantragen,
- Gruppenpostfach beantragen,
- Mobilgerät registrieren.

Ein guter Servicekatalog erklärt:

- wofür der Service ist,
- wer ihn nutzen darf,
- welche Voraussetzungen bestehen,
- welche Genehmigungen nötig sind,
- wie lange es ungefähr dauert,
- welche Informationen benötigt werden,
- und wo Hilfe verfügbar ist.

---

**Gute Request-Formulare**

Self-Service-Formulare sollten so gestaltet sein, dass Benutzer richtige Informationen liefern können.

Ein gutes Formular:

- fragt nur notwendige Informationen ab,
- nutzt verständliche Feldnamen,
- vermeidet interne Kategorien,
- bietet passende Auswahlfelder,
- erklärt Pflichtfelder,
- prüft Eingaben,
- zeigt erwartete Bearbeitungszeit,
- nennt Genehmigungsschritte,
- bietet Hilfetexte,
- und erzeugt ein gut bearbeitbares Ticket.

Schlechte Formulare erzeugen Rückfragen und falsche Tickets.

---

**Beispiel: schlechtes und gutes Formular**

Schlecht:

| Feld | Problem |
|---|---|
| Kategorie | Benutzer kennt interne Kategorien nicht |
| CI | Benutzer weiß nicht, welches CI betroffen ist |
| Priorität | Benutzer bewertet oft zu hoch oder unsicher |
| Beschreibung | ohne Hilfe zu ungenau |

Besser:

| Feld | Vorteil |
|---|---|
| Welcher Service ist betroffen? | benutzerverständlich |
| Was möchten Sie tun? | Ziel wird klar |
| Welche Fehlermeldung sehen Sie? | Diagnose wird möglich |
| Seit wann tritt das Problem auf? | zeitliche Einordnung |
| Sind weitere Personen betroffen? | Auswirkung erkennbar |

---

**Ticketqualität durch Self-Service verbessern**

Self-Service kann Tickets verbessern, wenn Benutzer geführt werden.

Beispiele:

- richtige Kategorie wird automatisch gesetzt,
- betroffener Service wird abgefragt,
- Fehlermeldung wird erfasst,
- Screenshots können angehängt werden,
- Standort oder Gerät wird abgefragt,
- Dringlichkeit wird durch Fragen eingeordnet,
- passende Knowledge-Artikel werden vorgeschlagen.

Dadurch kann der Service Desk schneller arbeiten.

---

**Knowledge-Artikel im Self-Service**

Benutzerartikel im Self-Service sollten:

- kurze Titel haben,
- verständlich formuliert sein,
- klare Schritte enthalten,
- Screenshots nur bei Nutzen verwenden,
- erwartetes Ergebnis beschreiben,
- typische Fehler nennen,
- Supportweg erklären,
- und regelmäßig geprüft werden.

Beispielartikel:

- Passwort zurücksetzen
- MFA auf neuem Smartphone einrichten
- VPN auf dem Notebook verbinden
- Drucker hinzufügen
- Software über das Portal installieren
- Verdächtige E-Mail melden

---

**Suchfunktion**

Die Suche ist entscheidend.

Benutzer suchen nicht nach internen IT-Begriffen.

Sie suchen nach:

- „Passwort vergessen“
- „VPN geht nicht“
- „Drucker offline“
- „neues Handy“
- „MFA funktioniert nicht“
- „Software installieren“
- „E-Mail verdächtig“
- „Portal geht nicht“

Artikel sollten diese Begriffe enthalten.

Eine gute Suche berücksichtigt Synonyme, Fehlermeldungen und häufige Formulierungen.

---

**Kategorien und Navigation**

Neben Suche hilft eine einfache Navigation.

Mögliche Kategorien:

- Konto und Anmeldung,
- Passwort und MFA,
- Netzwerk und VPN,
- E-Mail und Kalender,
- Software,
- Hardware,
- Drucken,
- Dateien und Zugriff,
- Sicherheit,
- Störungen und Status,
- Anträge und Berechtigungen.

Kategorien sollten aus Benutzersicht benannt werden.

Ungeeignet:

- IAM,
- Endpoint,
- Collaboration,
- Network Services,
- Infrastructure.

Besser:

- Anmeldung,
- Geräte,
- E-Mail,
- Netzwerk,
- Software,
- Zugriff.

---

**Statusinformationen**

Self-Service kann Benutzer über Störungen informieren.

Beispiele:

- aktueller Ausfall,
- geplantes Wartungsfenster,
- bekannte Einschränkung,
- Zwischenlösung,
- betroffene Services,
- nächste Aktualisierung,
- Abschlussmeldung.

Statusinformationen reduzieren doppelte Tickets.

Wenn Benutzer sehen, dass eine Störung bekannt ist, müssen sie nicht erneut nachfragen.

---

**Beispiel: Statusmeldung**

> Der Service „Mitarbeiterportal“ ist aktuell für einige Benutzer nicht erreichbar.
>
> Die Ursache wird untersucht.
>
> Bitte erstellen Sie nur dann ein Ticket, wenn Sie zusätzlich ein anderes Fehlerbild sehen oder dringend individuelle Unterstützung benötigen.
>
> Nächste Aktualisierung erfolgt um 14:30 Uhr.

Statusmeldungen sollten klar, ruhig und verständlich sein.

---

**Self-Service bei bekannten Störungen**

Bei bekannten Störungen kann Self-Service helfen durch:

- sichtbare Statusmeldung,
- einfache Erklärung,
- Workaround,
- Hinweis auf betroffene Benutzer,
- Angabe, ob ein Ticket nötig ist,
- nächste Aktualisierung,
- Link zu weiteren Informationen.

Wichtig ist:

Benutzer dürfen nicht mit unsicheren Workarounds allein gelassen werden.

Bei kritischen Fällen muss der Supportweg klar bleiben.

---

**Self-Service und Automatisierung**

Self-Service kann mit Automatisierung verbunden sein.

Beispiele:

- Passwort zurücksetzen,
- Standardsoftware bereitstellen,
- Benutzer zu genehmigter Gruppe hinzufügen,
- Standardgerät bestellen,
- Ticket automatisch richtig kategorisieren,
- Genehmigungsworkflow starten,
- Status automatisch anzeigen,
- Knowledge-Artikel automatisch vorschlagen.

Automatisierung eignet sich besonders für wiederholbare, risikoarme und klar definierte Aufgaben.

---

**Risiken von Automatisierung im Self-Service**

Automatisierung muss kontrolliert werden.

Risiken:

- falsche Berechtigungen,
- fehlende Genehmigung,
- Missbrauch,
- Sicherheitslücken,
- falsche Zuordnung,
- automatische Fehlerverbreitung,
- fehlende Protokollierung,
- unklare Verantwortlichkeit.

Deshalb müssen automatisierte Self-Service-Prozesse geprüft, überwacht und dokumentiert werden.

---

**Genehmigungen im Self-Service**

Nicht jeder Self-Service-Request darf sofort ausgeführt werden.

Genehmigungen können notwendig sein bei:

- Zugriff auf Fachanwendungen,
- Berechtigungsänderungen,
- kostenpflichtiger Software,
- Hardwarebestellung,
- externem Zugriff,
- Datenfreigabe,
- Administratorrechten,
- Cloud-Ressourcen,
- Sicherheitsausnahmen.

Das Portal sollte klar anzeigen:

- wer genehmigt,
- warum Genehmigung nötig ist,
- was der aktuelle Status ist,
- und welche Informationen fehlen.

---

**Self-Service und Sicherheit**

Self-Service muss sicher gestaltet sein.

Zu beachten:

- Identität des Benutzers prüfen,
- Berechtigungen kontrollieren,
- sensible Informationen schützen,
- keine internen Sicherheitsdetails offenlegen,
- Anleitungen mit Risiko einschränken,
- Protokollierung sicherstellen,
- Missbrauch verhindern,
- Datenschutz beachten.

Beispiel:

Ein Benutzerartikel darf erklären, wie eine verdächtige E-Mail gemeldet wird.

Er sollte aber keine internen Erkennungsregeln oder Sicherheitswerkzeuge offenlegen.

---

**Self-Service und Datenschutz**

Self-Service kann personenbezogene Daten betreffen.

Beispiele:

- Benutzerkonto,
- Gerätedaten,
- Standort,
- Telefonnummer,
- Screenshots,
- Ticketbeschreibung,
- Zugriffsrechte,
- Protokolldaten.

Zu prüfen ist:

- Welche Daten werden abgefragt?
- Sind sie notwendig?
- Wer kann sie sehen?
- Wie lange werden sie gespeichert?
- Wird der Benutzer verständlich informiert?
- Gibt es sensible Anhänge?

Formulare sollten keine unnötigen personenbezogenen Daten abfragen.

---

**Self-Service und Barrierearmut**

Self-Service sollte möglichst einfach zugänglich sein.

Zu beachten:

- klare Sprache,
- gut lesbare Struktur,
- mobile Nutzbarkeit,
- verständliche Links,
- sinnvolle Überschriften,
- Alternativen zu Bildern,
- keine unnötig komplexen Formulare,
- ausreichende Kontraste,
- verständliche Fehlermeldungen.

Ein Self-Service, der schwer zu bedienen ist, erzeugt neue Supportanfragen.

---

**Benutzerfeedback**

Benutzer sollten Rückmeldung geben können.

Mögliche Fragen:

- War der Artikel hilfreich?
- Haben die Schritte funktioniert?
- War etwas unverständlich?
- Wurde das Problem gelöst?
- Welche Information hat gefehlt?

Feedback hilft, Inhalte zu verbessern.

Es muss aber regelmäßig ausgewertet werden.

Sonst verliert die Feedbackfunktion ihren Wert.

---

**Nutzung messen**

Mögliche Kennzahlen für Self-Service:

| Kennzahl | mögliche Aussage |
|---|---|
| Artikelaufrufe | welche Themen wichtig sind |
| Suchanfragen ohne Treffer | Wissenslücken |
| Ticketvermeidung | Self-Service löst Anliegen |
| Formularabbrüche | Formular zu kompliziert |
| schlechte Bewertungen | Artikel unverständlich oder falsch |
| häufige Rückfragen | Inhalt unvollständig |
| häufige Requests | Automatisierungspotenzial |
| Self-Service-Anteil | Nutzung des Portals |

Kennzahlen sollten immer mit Kontext betrachtet werden.

Hohe Artikelaufrufe können bedeuten:

- Artikel ist wichtig,
- Problem tritt häufig auf,
- Artikel ist schwer verständlich,
- oder Service verursacht viele Fragen.

---

**Self-Service-Erfolg messen**

Self-Service ist erfolgreich, wenn:

- Benutzer passende Hilfe finden,
- einfache Anliegen schneller gelöst werden,
- Ticketqualität steigt,
- Standardtickets sinken,
- Service Desk entlastet wird,
- Benutzerzufriedenheit steigt,
- Inhalte aktuell bleiben,
- und keine Sicherheitsrisiken entstehen.

Nicht erfolgreich ist Self-Service, wenn Benutzer nur vom Support ferngehalten werden.

Self-Service muss Hilfe verbessern, nicht Hilfe erschweren.

---

**Ticketvermeidung richtig verstehen**

Ticketvermeidung ist nicht immer automatisch positiv.

Positiv:

- Benutzer löst Passwortproblem selbst.
- Benutzer findet passende Anleitung.
- Benutzer sieht Statusmeldung und erstellt kein doppeltes Ticket.

Negativ:

- Benutzer findet keinen Supportweg.
- Benutzer gibt frustriert auf.
- Benutzer nutzt unsicheren Umweg.
- Benutzer meldet echten Incident nicht.

Deshalb muss Self-Service immer Benutzererfahrung und Risiko berücksichtigen.

---

**Self-Service und Service Desk verbinden**

Self-Service und Service Desk sollten zusammenarbeiten.

Beispiele:

- Service Desk nutzt dieselben Artikel,
- Service Desk meldet fehlende Artikel,
- Service Desk sieht, welche Artikel Benutzer vorher gelesen haben,
- Benutzer können aus einem Artikel direkt ein Ticket erstellen,
- Ticketformular übernimmt relevante Informationen,
- Artikel werden aus gelösten Tickets verbessert.

Self-Service darf nicht getrennt vom Support betrieben werden.

---

**Übergang vom Self-Service zum Ticket**

Wenn Self-Service nicht hilft, muss der nächste Schritt klar sein.

Ein guter Artikel sagt:

- Wann soll ein Ticket erstellt werden?
- Welche Informationen sollen angegeben werden?
- Welche Screenshots sind hilfreich?
- Welche Fehlermeldung ist wichtig?
- Welche Dringlichkeit ist angemessen?
- Gibt es einen alternativen Kontaktweg bei kritischen Störungen?

Beispiel:

> Erstellen Sie ein Ticket, wenn die Anmeldung nach diesen Schritten weiterhin nicht funktioniert. Geben Sie bitte die Fehlermeldung, Uhrzeit, Gerätetyp und betroffenen Service an.

---

**Self-Service bei Onboarding**

Beim Onboarding ist Self-Service besonders hilfreich.

Mögliche Inhalte:

- erstes Login,
- Passwort ändern,
- MFA einrichten,
- E-Mail nutzen,
- Kalender nutzen,
- WLAN verbinden,
- VPN einrichten,
- Software installieren,
- Drucker hinzufügen,
- Serviceportal nutzen,
- Sicherheitsregeln,
- Supportkontakt.

Gutes Onboarding-Wissen reduziert viele Anfangsfragen und verbessert den Start neuer Mitarbeitender.

---

**Self-Service bei Offboarding**

Auch beim Offboarding kann Self-Service unterstützen.

Beispiele:

- Checkliste für Führungskräfte,
- Rückgabe von Geräten,
- Umgang mit Daten,
- Weiterleitung oder Deaktivierung von Postfächern,
- Entzug von Berechtigungen,
- Archivierung,
- Software- und Lizenzrückgabe.

Diese Themen sind oft sicherheits- und compliance-relevant.

Deshalb müssen klare Prozesse und Genehmigungen berücksichtigt werden.

---

**Self-Service bei Sicherheitsfragen**

Benutzerwissen ist für Informationssicherheit wichtig.

Beispiele:

- Phishing melden,
- verdächtige E-Mail erkennen,
- verlorenes Gerät melden,
- Passwort sicher ändern,
- MFA-Probleme melden,
- keine Zugangsdaten weitergeben,
- sichere Dateiablage nutzen,
- Sicherheitsvorfall melden.

Sicherheitsartikel müssen besonders verständlich sein.

Benutzer müssen schnell erkennen, was sie tun sollen.

---

**Benutzer nicht überfordern**

Self-Service sollte Benutzer unterstützen, nicht mit IT-Arbeit belasten.

Warnzeichen:

- zu viele Pflichtfelder,
- unklare Kategorien,
- lange technische Texte,
- keine Suche,
- veraltete Artikel,
- komplizierte Genehmigungswege,
- keine Rückmeldung,
- kein klarer Supportweg.

Self-Service darf nicht bedeuten:

> Benutzer sollen sich selbst durch schlechte Prozesse kämpfen.

---

**Benutzerperspektive testen**

Self-Service-Inhalte sollten aus Benutzersicht getestet werden.

Fragen:

- Findet ein Benutzer den Artikel über typische Begriffe?
- Versteht er die Schritte ohne IT-Vorwissen?
- Weiß er, wann er stoppen muss?
- Weiß er, wann ein Ticket nötig ist?
- Funktionieren Links und Screenshots?
- Ist der Artikel auf mobilen Geräten nutzbar?
- Wird klar, was als nächstes passiert?

Ein technisch korrekter Artikel kann trotzdem schlecht sein, wenn Benutzer ihn nicht verstehen.

---

**Service Desk als Qualitätsquelle**

Der Service Desk erkennt häufig, wo Self-Service scheitert.

Beispiele:

- Benutzer finden Artikel nicht,
- Formulare erzeugen falsche Tickets,
- Anleitungen sind unklar,
- Artikel sind veraltet,
- Kategorien passen nicht,
- Suchbegriffe fehlen,
- Standardfrage tritt trotz Artikel weiter häufig auf.

Deshalb sollte Service-Desk-Feedback regelmäßig in Self-Service-Verbesserungen einfließen.

---

**Self-Service-Inhalte nach Changes aktualisieren**

Changes können Self-Service-Inhalte veralten lassen.

Beispiele:

- neue Oberfläche,
- anderer Menüpfad,
- neue MFA-Methode,
- neue VPN-Version,
- geänderter Softwarekatalog,
- geänderte Genehmigung,
- neues Serviceportal,
- anderer Supportweg.

Change-Abschluss sollte deshalb prüfen:

> Welche Benutzerartikel, FAQ oder Formulare müssen aktualisiert werden?

---

**Self-Service-Inhalte nach Releases aktualisieren**

Releases können Benutzerfragen auslösen.

Vor einem Release sollten vorbereitet werden:

- Release Notes,
- Benutzeranleitung,
- FAQ,
- bekannte Einschränkungen,
- Supportartikel,
- Statusinformationen,
- Self-Service-Formulare,
- Service-Desk-Briefing.

Nach dem Release sollten Suchanfragen, Tickets und Feedback beobachtet werden.

---

**Self-Service und Continual Improvement**

Self-Service sollte kontinuierlich verbessert werden.

Möglicher Ablauf:

    Nutzung analysieren
        ↓
    Suchanfragen ohne Treffer prüfen
        ↓
    häufige Tickets auswerten
        ↓
    Artikel verbessern
        ↓
    Formulare vereinfachen
        ↓
    Automatisierung prüfen
        ↓
    Feedback auswerten
        ↓
    Wirkung messen

Guter Self-Service entsteht durch regelmäßige Pflege, nicht durch einmalige Erstellung.

---

**Praxisbeispiel: MFA neues Smartphone**

**Situation**

Viele Benutzer erstellen Tickets, weil sie ein neues Smartphone haben.

**Problem**

Der alte Artikel ist schwer auffindbar und nutzt interne Begriffe.

**Verbesserung**

- Titel: „MFA auf neuem Smartphone einrichten“
- Suchbegriffe: MFA, Authenticator, neues Handy, Anmeldung
- einfache Schritte,
- Screenshots,
- Hinweis bei fehlendem Zugriff,
- direkter Ticketlink.

**Nutzen**

Benutzer lösen einfache Fälle selbst.

Komplexe Fälle landen mit besseren Informationen beim Service Desk.

---

**Praxisbeispiel: VPN-Anleitung**

**Situation**

Viele Benutzer melden VPN-Probleme im Homeoffice.

**Self-Service-Inhalt**

- Voraussetzungen prüfen,
- Internetverbindung testen,
- VPN-Client öffnen,
- bekannte Fehlermeldungen erklären,
- Workaround bei Ruhezustand,
- Ticketweg bei weiterhin bestehendem Fehler.

**Wichtig**

Sicherheitsrelevante interne Details bleiben im Service-Desk-Artikel.

Benutzer erhalten nur sichere, verständliche Schritte.

---

**Praxisbeispiel: Software beantragen**

**Situation**

Benutzer fragen per E-Mail nach Standardsoftware.

**Self-Service-Lösung**

- Softwarekatalog im Portal,
- klare Beschreibung der Software,
- automatische Genehmigung bei freigegebener Standardsoftware,
- Lizenzhinweis,
- Statusanzeige,
- automatische Installation, falls möglich.

**Nutzen**

Weniger manuelle Rückfragen und schnellere Bereitstellung.

---

**Praxisbeispiel: Statusseite bei Störung**

**Situation**

E-Mail-Service ist gestört.

**Ohne Statusseite**

Viele Benutzer erstellen identische Tickets.

**Mit Statusseite**

Benutzer sehen:

- Störung ist bekannt,
- betroffener Service,
- aktueller Status,
- nächste Aktualisierung,
- ob ein Ticket notwendig ist.

**Nutzen**

Service Desk kann sich stärker auf Behebung und Kommunikation konzentrieren.

---

**Typische Fehler**

**Fehler 1**

Self-Service wird als Ersatz für Support verstanden.

---

**Fehler 2**

Benutzerartikel sind zu technisch.

---

**Fehler 3**

Artikel sind nicht auffindbar.

---

**Fehler 4**

Suchbegriffe der Benutzer fehlen.

---

**Fehler 5**

Formulare fragen interne IT-Kategorien ab.

---

**Fehler 6**

Self-Service enthält unsichere Workarounds.

---

**Fehler 7**

Benutzer wissen nicht, wann sie ein Ticket erstellen sollen.

---

**Fehler 8**

Statusinformationen fehlen bei bekannten Störungen.

---

**Fehler 9**

Feedback wird gesammelt, aber nicht ausgewertet.

---

**Fehler 10**

Artikel werden nach Changes und Releases nicht aktualisiert.

---

**Fehler 11**

Automatisierung wird ohne ausreichende Kontrolle eingeführt.

---

**Fehler 12**

Ticketvermeidung wird wichtiger genommen als echte Hilfe.

---

**Checkliste Self-Service-Thema auswählen**

- [ ] Thema tritt häufig auf
- [ ] Lösung ist klar beschreibbar
- [ ] Risiko ist niedrig oder kontrollierbar
- [ ] Benutzer dürfen die Schritte selbst ausführen
- [ ] keine vertraulichen internen Informationen nötig
- [ ] Supportweg kann klar beschrieben werden
- [ ] Artikel kann aktuell gehalten werden
- [ ] Nutzen für Benutzer ist erkennbar
- [ ] Service Desk wird entlastet
- [ ] Sicherheits- und Datenschutzfragen sind geprüft

---

**Checkliste Benutzerartikel**

- [ ] Titel nutzt Benutzersprache
- [ ] Zielgruppe ist klar
- [ ] Problem oder Aufgabe ist verständlich beschrieben
- [ ] Voraussetzungen sind genannt
- [ ] Schritte sind einfach und kurz
- [ ] erwartetes Ergebnis ist beschrieben
- [ ] typische Fehler sind genannt
- [ ] Supportweg ist klar
- [ ] keine internen vertraulichen Informationen enthalten
- [ ] Screenshots sind aktuell, falls verwendet
- [ ] Owner ist eingetragen
- [ ] Review-Datum ist gesetzt

---

**Checkliste Serviceportal**

- [ ] Suche funktioniert mit Benutzerbegriffen
- [ ] Kategorien sind verständlich
- [ ] häufige Anliegen sind leicht auffindbar
- [ ] Servicekatalog ist aktuell
- [ ] Formulare sind einfach
- [ ] Ticketstatus ist sichtbar
- [ ] Statusmeldungen sind vorhanden
- [ ] Feedback ist möglich
- [ ] Inhalte sind mobil nutzbar
- [ ] Zugriffsschutz ist passend
- [ ] Service Desk kann Inhalte pflegen oder Feedback geben

---

**Checkliste Self-Service-Formular**

- [ ] fragt nur notwendige Informationen ab
- [ ] nutzt verständliche Feldnamen
- [ ] erklärt Pflichtfelder
- [ ] vermeidet interne Kategorien
- [ ] bietet passende Auswahlfelder
- [ ] schlägt Knowledge-Artikel vor
- [ ] prüft Eingaben, soweit möglich
- [ ] zeigt Genehmigungen und Status
- [ ] nennt erwartete Bearbeitung
- [ ] erzeugt ein gut bearbeitbares Ticket

---

**Checkliste Self-Service verbessern**

- [ ] häufige Tickets ausgewertet
- [ ] Suchanfragen ohne Treffer geprüft
- [ ] Artikelbewertungen ausgewertet
- [ ] Formularabbrüche analysiert
- [ ] Service-Desk-Feedback eingeholt
- [ ] Benutzerfeedback berücksichtigt
- [ ] veraltete Artikel aktualisiert
- [ ] neue Artikel für häufige Themen erstellt
- [ ] Automatisierungspotenzial geprüft
- [ ] Sicherheitsrisiken bewertet
- [ ] Wirkung nach Verbesserung gemessen

---

**Bedeutung für Fachinformatiker für Systemintegration**

Fachinformatiker unterstützen Self-Service durch praxisnahes technisches Wissen.

Im Arbeitsalltag bedeutet das:

- häufige technische Fragen erkennen,
- verständliche Benutzerartikel mit vorbereiten,
- sichere Workarounds von riskanten Maßnahmen unterscheiden,
- Service Desk mit klaren Informationen versorgen,
- Formulare aus technischer Sicht verbessern,
- Automatisierung für Standardaufgaben unterstützen,
- Inhalte nach Changes aktualisieren,
- und technische Begriffe in benutzerverständliche Sprache übersetzen.

Guter Self-Service entsteht durch Zusammenarbeit von Service Desk, Fachgruppen, Service Ownern und Benutzern.

---

**Zusammenfassung**

> häufige Benutzeranliegen erkennen  
> ↓  
> prüfen, ob Self-Service geeignet und sicher ist  
> ↓  
> Benutzerwissen verständlich aufbereiten  
> ↓  
> Artikel, FAQ, Formular oder Automatisierung bereitstellen  
> ↓  
> Serviceportal und Suche benutzerfreundlich gestalten  
> ↓  
> Übergang zum Ticket klar beschreiben  
> ↓  
> Nutzung und Feedback auswerten  
> ↓  
> Inhalte nach Changes und Releases aktualisieren  
> ↓  
> Self-Service kontinuierlich verbessern

---

**Merksätze**

> Self-Service ersetzt den Service Desk nicht, sondern ergänzt ihn.

> Benutzerwissen muss in Benutzersprache geschrieben sein.

> Ein Artikel hilft nur, wenn er gefunden und verstanden wird.

> Gute Formulare verbessern Ticketqualität.

> Ticketvermeidung ist nur positiv, wenn Benutzer wirklich Hilfe erhalten.

> Self-Service muss sicher, aktuell und gepflegt sein.

> Der Service Desk ist eine wichtige Quelle für Self-Service-Verbesserungen.

---

**Verwandte Seiten**

- 7.1 Knowledge Management – Ziele, Begriffe und Grundlagen
- 7.2 Knowledge-Artikel, Runbooks und FAQ
- 7.3 Known Errors, Workarounds und Wissensnutzung im Service Desk
- 7.5 Knowledge Management im Zusammenspiel mit Incident, Problem und Change
- Service Desk
- Incident Management
- Request Fulfilment
- Change Enablement
- Release Management
- Continual Improvement

---

**Quellen und Versionsstand**

**Offizielle Grundlagen**

- PeopleCert – ITIL Practice Guide: Knowledge Management
- PeopleCert – ITIL Practice Guide: Service Desk
- PeopleCert – ITIL Practice Guide: Service Request Management
- PeopleCert – ITIL Practice Guide: Incident Management
- PeopleCert – ITIL Practice Guide: Change Enablement
- PeopleCert – ITIL Practice Guide: Continual Improvement
- ITIL Foundation – Version 5

**Ergänzende Praxiseinordnung**

- Knowledge-Centered Service als verbreiteter Praxisansatz für Wissensarbeit im Support
- Allgemeine UX- und Support-Praxis für Self-Service-Portale, Formularqualität und Benutzerkommunikation

**Einordnung**

Die dargestellten:

- Self-Service-Beispiele,
- Benutzerartikel-Strukturen,
- Formularhinweise,
- Checklisten,
- Kennzahlen,
- und Praxisbeispiele

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

- Self-Service-Portal-Struktur,
- Artikelvorlage,
- Formularstruktur,
- Suchlogik,
- Automatisierungspflicht,
- Kennzahlenliste,
- oder Toolauswahl

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

- Benutzergruppen,
- Services,
- Supportmodell,
- Sicherheitsanforderungen,
- Datenschutz,
- Knowledge-Werkzeuge,
- Servicekatalog,
- Automatisierungsgrad,
- 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

# 7.5 Knowledge Management im Zusammenspiel mit Incident, Problem und Change

> **Kurz erklärt**
>
> Knowledge Management wirkt nicht isoliert.
>
> Es verbindet Wissen aus Incident Management, Problem Management, Change Enablement, Release Management, Service Desk und Service Configuration Management.
>
> Ziel ist, dass Erfahrungen, Lösungen, Workarounds, Known Errors, Runbooks und Benutzerinformationen im richtigen Moment verfügbar sind.

---

**Warum das Zusammenspiel wichtig ist**

Im IT-Betrieb entsteht Wissen ständig während der Arbeit.

Beispiele:

- ein Incident wird gelöst,
- ein Workaround wird gefunden,
- ein Problem wird analysiert,
- ein Known Error wird dokumentiert,
- ein Change verändert einen Service,
- ein Release bringt neue Funktionen,
- ein Benutzerartikel wird nach Rückfragen verbessert,
- ein Major Incident erzeugt Lessons Learned.

Wenn dieses Wissen nicht in Knowledge Management einfließt, geht es verloren.

Dann entstehen typische Probleme:

- gleiche Incidents werden immer wieder neu analysiert,
- Service Desk nutzt veraltete Informationen,
- Workarounds stehen nur in einzelnen Tickets,
- Benutzer erhalten widersprüchliche Antworten,
- Knowledge-Artikel passen nicht mehr zur aktuellen Version,
- Known Errors sind nicht auffindbar,
- Changes verändern Services, aber Artikel bleiben alt,
- und Verbesserungen werden nicht dauerhaft übernommen.

---

**Grundidee des Zusammenspiels**

    Incident tritt auf
            ↓
    Service Desk nutzt vorhandenes Wissen
            ↓
    fehlendes oder falsches Wissen wird erkannt
            ↓
    Problem Management analysiert wiederkehrende Ursachen
            ↓
    Known Error oder Workaround entsteht
            ↓
    Knowledge Management macht dieses Wissen nutzbar
            ↓
    Change oder Release setzt dauerhafte Lösung um
            ↓
    Knowledge-Artikel, Runbooks und FAQ werden aktualisiert
            ↓
    zukünftige Incidents werden schneller gelöst oder vermieden

Knowledge Management ist damit ein Lernkreislauf im IT-Betrieb.

---

**Zusammenspiel mit Incident Management**

Incident Management nutzt Knowledge, um Services schneller wiederherzustellen.

Nützlich sind:

- bekannte Symptome,
- Standardlösungen,
- Workarounds,
- Known Errors,
- Prüfschritte,
- Eskalationsregeln,
- Benutzerinformationen,
- Runbooks,
- Service-Desk-Artikel.

Beispiel:

Ein Benutzer meldet, dass VPN nach dem Ruhezustand nicht mehr verbindet.

Der Service Desk findet einen Knowledge-Artikel mit:

- betroffenem VPN-Client,
- Prüfschritten,
- Workaround,
- Eskalationskriterien,
- Verknüpfung zum Known Error.

Dadurch muss der Incident nicht neu analysiert werden.

---

**Incident Management liefert Wissen zurück**

Incidents zeigen, welches Wissen fehlt oder verbessert werden muss.

Beispiele:

- neuer Fehler tritt auf,
- bekannter Workaround funktioniert nicht mehr,
- Artikel ist unverständlich,
- Suchbegriff fehlt,
- Eskalationsweg ist falsch,
- Benutzer stellen immer dieselbe Frage,
- Service Desk ergänzt immer wieder dieselbe Erklärung,
- Artikel passt nicht zur aktuellen Version.

Diese Erkenntnisse sollten in Knowledge Management zurückfließen.

Ein gelöster Incident kann also Auslöser für einen neuen oder verbesserten Knowledge-Artikel sein.

---

**Wann aus einem Incident ein Knowledge-Artikel entstehen sollte**

Ein Knowledge-Artikel ist sinnvoll, wenn:

- der Incident wahrscheinlich wieder auftreten wird,
- die Lösung wiederverwendbar ist,
- ein Workaround gefunden wurde,
- Service Desk künftig schneller reagieren kann,
- Benutzer eine Anleitung benötigen,
- eine Fehlermeldung häufig vorkommt,
- eine Eskalation klar geregelt werden muss,
- oder der Fall für neue Mitarbeitende hilfreich ist.

Nicht jeder einzelne Incident benötigt einen eigenen Artikel.

Aber wiederkehrende oder typische Fälle sollten dokumentiert werden.

---

**Zusammenspiel mit Problem Management**

Problem Management erzeugt besonders wertvolles Wissen.

Beispiele:

- Ursachenanalyse,
- bekannte Ursachen,
- beitragende Faktoren,
- Known Errors,
- Workarounds,
- dauerhafte Lösungen,
- Risiken,
- Lessons Learned,
- wiederkehrende Muster.

Dieses Wissen darf nicht nur im Problem Record bleiben.

Es muss so aufbereitet werden, dass es im Service Desk, in Fachgruppen oder im Self-Service genutzt werden kann.

---

**Problem Management liefert Known Errors**

Ein Known Error sollte in Knowledge Management nutzbar gemacht werden.

Ein guter Known-Error-Artikel enthält:

- Fehlerbild,
- betroffener Service,
- betroffene Version,
- Ursache oder wahrscheinliche Ursache,
- Workaround,
- Risiken,
- Einschränkungen,
- Eskalationskriterien,
- dauerhafte Lösung,
- Status,
- Problem-Verknüpfung,
- Review-Datum.

Dadurch kann Incident Management neue Incidents schneller zuordnen.

---

**Knowledge Management unterstützt Problem Management**

Knowledge Management hilft Problem Management durch:

- historische Artikel,
- bekannte Workarounds,
- häufig genutzte Lösungen,
- Suchanfragen ohne Treffer,
- wiederkehrende Service-Desk-Fragen,
- schlecht bewertete Artikel,
- Hinweise auf Knowledge-Lücken,
- Nutzungsauswertungen,
- Verknüpfungen zu Incidents.

Beispiel:

Ein Workaround-Artikel wird sehr häufig genutzt.

Das kann ein Hinweis sein, dass ein Problem weiterhin offen ist und eine dauerhafte Lösung benötigt.

---

**Zusammenspiel mit Change Enablement**

Changes verändern Services, Systeme, Prozesse und Benutzeroberflächen.

Dadurch kann Wissen veralten.

Nach einem Change müssen möglicherweise aktualisiert werden:

- Benutzerartikel,
- FAQ,
- Service-Desk-Artikel,
- Runbooks,
- Known Errors,
- Workarounds,
- Screenshots,
- Menüpfade,
- Eskalationswege,
- Servicebeschreibungen,
- Monitoringhinweise,
- CMDB-Verknüpfungen.

Ein Change ist nicht vollständig abgeschlossen, wenn die technische Änderung umgesetzt wurde, aber das Wissen noch den alten Zustand beschreibt.

---

**Knowledge-Prüfung im Change-Abschluss**

Beim Abschluss eines Changes sollte geprüft werden:

- Welche Artikel sind betroffen?
- Haben sich Schritte, Screenshots oder Menüpfade geändert?
- Gibt es neue Fehlermeldungen?
- Wurde ein Known Error behoben?
- Ist ein Workaround noch gültig?
- Muss ein Benutzerartikel erstellt werden?
- Muss der Service Desk informiert werden?
- Muss ein Runbook angepasst werden?
- Muss ein Artikel archiviert werden?

Diese Prüfung sollte Teil der Change-Nachbereitung sein.

---

**Beispiel: Change macht Wissen veraltet**

**Situation**

Eine Anwendung erhält eine neue Oberfläche.

**Problem**

Der Self-Service-Artikel beschreibt noch die alte Menüführung.

**Folge**

Benutzer finden die Funktion nicht und erstellen Tickets.

**Verbesserung**

Change Enablement ergänzt eine Pflichtprüfung:

> Welche Knowledge-Artikel, FAQ und Screenshots müssen vor oder nach dem Change aktualisiert werden?

---

**Zusammenspiel mit Release Management**

Releases bringen neue oder geänderte Funktionen.

Knowledge Management unterstützt Releases durch:

- Release Notes,
- Benutzerinformationen,
- FAQ,
- Service-Desk-Briefings,
- Known Errors,
- bekannte Einschränkungen,
- neue Workarounds,
- aktualisierte Runbooks,
- Schulungsunterlagen.

Ein Release ohne Knowledge-Vorbereitung führt häufig zu unnötigen Rückfragen.

---

**Release-Wissen vor Veröffentlichung vorbereiten**

Vor einem Release sollte geklärt werden:

- Was ändert sich für Benutzer?
- Welche Funktionen sind neu?
- Welche Funktionen ändern sich?
- Welche bekannten Einschränkungen bestehen?
- Welche Artikel müssen aktualisiert werden?
- Welche Fragen werden Benutzer wahrscheinlich stellen?
- Welche Informationen benötigt der Service Desk?
- Welche Known Errors sind relevant?
- Welche Workarounds sind freigegeben?

Gute Release-Kommunikation reduziert Incidents nach der Einführung.

---

**Zusammenspiel mit Service Desk**

Der Service Desk ist gleichzeitig Nutzer und Lieferant von Wissen.

Er nutzt Knowledge für:

- schnelle Antworten,
- Standardlösungen,
- Workarounds,
- Eskalation,
- Benutzerkommunikation,
- Ticketdokumentation.

Er liefert Knowledge zurück durch:

- Feedback zu Artikeln,
- Hinweise auf fehlende Inhalte,
- wiederkehrende Fragen,
- neue Fehlerbilder,
- Suchbegriffe aus der Praxis,
- Rückmeldungen von Benutzern.

Der Service Desk sollte deshalb aktiv in Knowledge Management eingebunden sein.

---

**Service Desk als Qualitätsfilter**

Der Service Desk erkennt schnell, ob Wissen im Alltag funktioniert.

Typische Rückmeldungen:

- Artikel wird nicht gefunden,
- Titel passt nicht zur Benutzersprache,
- Schritte sind unklar,
- Screenshot ist veraltet,
- Workaround funktioniert nicht,
- Eskalationsweg stimmt nicht,
- Artikel ist zu lang,
- Artikel enthält zu viele interne Details,
- Benutzer verstehen die Anleitung nicht.

Diese Rückmeldungen sollten regelmäßig ausgewertet werden.

---

**Zusammenspiel mit Self-Service**

Self-Service nutzt Knowledge, damit Benutzer einfache Anliegen selbst lösen können.

Geeignet sind:

- FAQ,
- Benutzeranleitungen,
- Statusinformationen,
- bekannte sichere Workarounds,
- Servicebeschreibungen,
- Request-Formulare,
- Passwort- und MFA-Hilfen,
- Softwarekatalog,
- Onboarding-Anleitungen.

Self-Service braucht besonders klare Sprache.

Interne Diagnoseschritte oder sicherheitskritische Informationen gehören nicht ungeprüft in Benutzerartikel.

---

**Self-Service liefert Wissen zurück**

Self-Service-Daten zeigen, was Benutzer wirklich suchen.

Wichtige Signale:

- häufige Suchanfragen,
- Suchanfragen ohne Treffer,
- häufig geöffnete Artikel,
- schlechte Bewertungen,
- hohe Formularabbrüche,
- viele Tickets nach Artikelaufruf,
- wiederkehrende Begriffe aus Benutzertexten.

Diese Daten helfen, Knowledge-Artikel, FAQ und Formulare zu verbessern.

---

**Zusammenspiel mit Service Configuration Management**

Service Configuration Management liefert Kontext zu Wissen.

Wichtige Verknüpfungen:

- Artikel zu Service,
- Artikel zu Configuration Item,
- Known Error zu betroffener Version,
- Runbook zu Anwendung oder Server,
- Workaround zu Problem Record,
- Benutzerartikel zu Servicekatalogeintrag,
- Release Notes zu Anwendungsversion.

Ohne Service- oder CI-Bezug sind Knowledge-Artikel schwerer auffindbar und schwerer aktuell zu halten.

---

**Beispiel: Knowledge und CI-Verknüpfung**

Ein Artikel beschreibt einen VPN-Fehler.

Sinnvolle Verknüpfungen:

- Service: VPN-Zugang,
- CI: VPN-Client-Version,
- CI: VPN-Gateway,
- CI: Identity Provider,
- Problem Record,
- Known Error,
- geplanter Change.

Dadurch kann der Artikel bei passenden Incidents automatisch vorgeschlagen oder schneller gefunden werden.

---

**Zusammenspiel mit Information Security Management**

Sicherheitswissen muss besonders sorgfältig gepflegt werden.

Beispiele:

- Phishing melden,
- verlorenes Gerät melden,
- MFA-Probleme,
- Passwortregeln,
- verdächtige Anmeldung,
- Sicherheitsvorfall-Prozess,
- Umgang mit sensiblen Daten,
- sichere Dateiablage,
- Meldewege,
- Verhalten bei Verdacht auf Kompromittierung.

Sicherheitsartikel müssen verständlich sein.

Sie dürfen aber keine internen Schutzmechanismen unnötig offenlegen.

---

**Sicherheitsrelevante Knowledge-Artikel**

Bei sicherheitsrelevanten Artikeln ist zu prüfen:

- Wer darf den Artikel sehen?
- Sind interne Details geschützt?
- Ist die Anleitung missbrauchssicher?
- Gibt es klare Meldewege?
- Ist der Inhalt fachlich freigegeben?
- Ist der Artikel aktuell?
- Ist ein Review-Datum gesetzt?
- Sind Datenschutzanforderungen berücksichtigt?

Falsches Sicherheitswissen kann zu hohen Risiken führen.

---

**Zusammenspiel mit Continual Improvement**

Knowledge Management liefert viele Hinweise für Verbesserungen.

Beispiele:

- häufige Suchanfragen ohne Treffer,
- viele Tickets trotz Self-Service-Artikel,
- häufig genutzte Workarounds,
- schlecht bewertete Artikel,
- veraltete Runbooks,
- fehlende Knowledge-Verknüpfungen,
- wiederkehrende Benutzerfragen,
- viele Eskalationen wegen fehlender Prüfschritte.

Diese Erkenntnisse sollten in Continual Improvement einfließen.

---

**Knowledge als Verbesserungsquelle**

Ein sinnvoller Verbesserungsablauf:

    Knowledge-Daten auswerten
            ↓
    Lücken und Qualitätsprobleme erkennen
            ↓
    Verbesserungsmaßnahme definieren
            ↓
    Owner und Termin festlegen
            ↓
    Artikel, Formular oder Prozess verbessern
            ↓
    Wirkung messen
            ↓
    Ergebnis in Continual Improvement übernehmen

Knowledge Management ist damit nicht nur Dokumentation, sondern auch Verbesserungsarbeit.

---

**Wissen im Lebenszyklus eines Incidents**

    Benutzer meldet Störung
            ↓
    Service Desk sucht passenden Artikel
            ↓
    Artikel liefert Prüfschritte oder Workaround
            ↓
    Incident wird gelöst oder eskaliert
            ↓
    Ticket wird mit Artikel verknüpft
            ↓
    Feedback zum Artikel wird dokumentiert
            ↓
    Knowledge-Artikel wird bei Bedarf verbessert

So wird jeder Incident zu einer möglichen Quelle für besseres Wissen.

---

**Wissen im Lebenszyklus eines Problems**

    Wiederkehrende Incidents werden erkannt
            ↓
    Problem Record wird erstellt
            ↓
    Ursache oder wahrscheinliche Ursache wird analysiert
            ↓
    Known Error wird dokumentiert
            ↓
    Workaround wird erstellt
            ↓
    Service Desk erhält Knowledge-Artikel
            ↓
    dauerhafte Lösung wird verfolgt
            ↓
    Artikel wird nach Lösung aktualisiert oder archiviert

Problem Management und Knowledge Management arbeiten hier besonders eng zusammen.

---

**Wissen im Lebenszyklus eines Changes**

    Change wird geplant
            ↓
    betroffene Artikel und Runbooks werden identifiziert
            ↓
    Service Desk und Benutzerinformationen werden vorbereitet
            ↓
    Change wird umgesetzt
            ↓
    Wissen wird aktualisiert
            ↓
    alte Artikel werden angepasst oder archiviert
            ↓
    Feedback nach Change wird ausgewertet

So verhindert Change Enablement, dass veraltetes Wissen im Betrieb bleibt.

---

**Wissensverknüpfungen**

Gute Knowledge-Arbeit nutzt Verknüpfungen.

Mögliche Verknüpfungen:

- Knowledge-Artikel zu Incident,
- Knowledge-Artikel zu Problem,
- Known Error zu Workaround,
- Workaround zu Service,
- Runbook zu CI,
- Benutzerartikel zu Servicekatalog,
- Artikel zu Change,
- Artikel zu Release,
- Artikel zu Sicherheitsmeldung.

Verknüpfungen verbessern Auffindbarkeit, Auswertung und Pflege.

---

**Rollen im Zusammenspiel**

| Rolle | Beitrag zu Knowledge Management |
|---|---|
| **Service Desk** | nutzt Artikel, gibt Feedback, erkennt Wissenslücken |
| **Fachteam** | liefert technische Inhalte und prüft Richtigkeit |
| **Problem Management** | liefert Known Errors, Ursachen und Workarounds |
| **Change Management** | sorgt für Aktualisierung nach Changes |
| **Release Management** | liefert Release Notes und neue Informationen |
| **Service Owner** | prüft fachliche Richtigkeit und Benutzerwirkung |
| **Security Team** | prüft sicherheitsrelevante Inhalte |
| **Knowledge Owner** | verantwortet Pflege, Review und Qualität |

Rollen können je nach Organisation unterschiedlich benannt sein.

Wichtig sind klare Verantwortlichkeiten.

---

**Knowledge Owner**

Ein Knowledge Owner sorgt dafür, dass ein Artikel aktuell und korrekt bleibt.

Aufgaben:

- fachliche Prüfung,
- Review,
- Feedback bewerten,
- Änderungen einarbeiten,
- veraltete Inhalte archivieren,
- Zielgruppe prüfen,
- Zugriffsschutz prüfen,
- Verknüpfungen pflegen.

Ohne Knowledge Owner veralten wichtige Artikel schnell.

---

**Service Owner**

Der Service Owner hilft zu klären:

- welche Benutzerinformationen nötig sind,
- welche Servicebeschreibung korrekt ist,
- welche Auswirkungen ein Known Error hat,
- welche Kommunikation freigegeben ist,
- welche Artikel für den Service wichtig sind,
- welche Inhalte nach Changes angepasst werden müssen.

Service Owner verbinden technische Informationen mit Service- und Benutzerperspektive.

---

**Fachteams**

Fachteams liefern technisches Wissen.

Beispiele:

- Logauswertung,
- Ursache,
- Konfigurationsdetails,
- technische Risiken,
- sichere Workarounds,
- Runbooks,
- Abbruchkriterien,
- Rollback-Hinweise,
- technische Prüfungen nach Changes.

Fachteams sollten Wissen so aufbereiten, dass Service Desk oder Benutzer es passend nutzen können.

---

**Wissen für verschiedene Zielgruppen aufbereiten**

Ein technischer Sachverhalt kann mehrere Wissensformen benötigen.

Beispiel: Zertifikatsproblem

**Benutzerartikel**

- aktuelle Einschränkung,
- was Benutzer tun können,
- wo Statusinformationen stehen.

**Service-Desk-Artikel**

- Symptome,
- betroffener Service,
- Eskalationsweg,
- freigegebene Kommunikation.

**Fachteam-Runbook**

- Zertifikat prüfen,
- Zertifikat erneuern,
- Dienst testen,
- Monitoring prüfen,
- CMDB aktualisieren.

Ein Artikel für alle Zielgruppen ist oft nicht sinnvoll.

---

**Wissensqualität im Zusammenspiel**

Wissensqualität bedeutet:

- richtige Information,
- richtige Zielgruppe,
- richtige Detailtiefe,
- richtige Sichtbarkeit,
- richtige Verknüpfung,
- aktueller Stand,
- klarer Owner,
- regelmäßiger Review.

Ein fachlich richtiger Artikel kann trotzdem schlecht sein, wenn er für die Zielgruppe unverständlich ist.

Ein gut geschriebener Artikel kann gefährlich sein, wenn er veraltet ist.

---

**Kennzahlen für das Zusammenspiel**

Mögliche Kennzahlen:

| Kennzahl | mögliche Aussage |
|---|---|
| Incidents mit verknüpftem Knowledge-Artikel | Nutzung im Service Desk |
| häufig genutzte Artikel | wichtige Supportthemen |
| Suchanfragen ohne Treffer | Wissenslücken |
| Artikel ohne Owner | Pflegeproblem |
| Artikel ohne Review-Datum | Aktualitätsrisiko |
| Tickets trotz Self-Service-Artikel | Artikel nicht hilfreich oder Problem weiterhin häufig |
| Known Errors ohne Artikel | Wissen fehlt im Support |
| Changes ohne Knowledge-Prüfung | Risiko veralteter Artikel |
| schlechte Artikelbewertungen | Qualitätsproblem |

Kennzahlen müssen mit Feedback und fachlicher Bewertung kombiniert werden.

---

**Wissen aus Major Incidents**

Major Incidents liefern besonders wichtige Erkenntnisse.

Nach einem Major Incident sollte geprüft werden:

- Welche Informationen haben gefehlt?
- Welche Runbooks waren hilfreich?
- Welche Artikel waren veraltet?
- Welche Kommunikation war unklar?
- Welche Workarounds wurden genutzt?
- Welche Known Errors entstanden?
- Welche Benutzerinformationen müssen verbessert werden?
- Welche Lessons Learned gehören in Knowledge Management?

Ein Major Incident Review ohne Knowledge-Aktualisierung verschenkt Lernpotenzial.

---

**Wissen aus Failed Changes**

Auch fehlgeschlagene Changes liefern wertvolles Wissen.

Zu prüfen ist:

- War das Runbook ausreichend?
- War der Rollback beschrieben?
- Waren Tests vollständig?
- Gab es fehlende Abhängigkeiten?
- War Service Desk informiert?
- Müssen Change-Vorlagen verbessert werden?
- Muss ein neuer Knowledge-Artikel entstehen?
- Muss ein Known Error dokumentiert werden?

Failed Changes sollten nicht nur technisch korrigiert, sondern auch wissensseitig ausgewertet werden.

---

**Wissen aus Releases**

Nach Releases sollte beobachtet werden:

- Welche Fragen stellen Benutzer?
- Welche Incidents entstehen?
- Welche Artikel werden häufig aufgerufen?
- Welche Suchbegriffe führen zu keinem Treffer?
- Welche Screenshots sind veraltet?
- Welche Known Errors sind neu?
- Welche FAQ fehlt?

So kann Knowledge Management schnell auf reale Benutzerfragen reagieren.

---

**Praxisbeispiel: VPN-Problem**

**Incident Management**

Benutzer melden VPN-Abbrüche.

**Problem Management**

Mehrere Incidents zeigen dasselbe Muster.

Ursache ist eine fehlerhafte Client-Version.

**Knowledge Management**

Ein Known-Error-Artikel wird erstellt.

Er enthält:

- Fehlerbild,
- betroffene Version,
- Prüfschritte,
- Workaround,
- Eskalationskriterien,
- geplanten Change.

**Change Enablement**

Neue Client-Version wird ausgerollt.

**Nachbereitung**

Knowledge-Artikel wird aktualisiert oder archiviert.

---

**Praxisbeispiel: MFA-Self-Service**

**Beobachtung**

Viele Tickets entstehen wegen neuem Smartphone.

**Knowledge Management**

Benutzerartikel wird erstellt:

- MFA auf neuem Smartphone einrichten,
- Screenshots,
- Hinweis bei fehlendem Zugriff,
- Ticketlink.

**Service Desk**

Tickets enthalten bessere Informationen.

**Continual Improvement**

Suchbegriffe und Formular werden verbessert.

**Nutzen**

Weniger Standardtickets und bessere Benutzererfahrung.

---

**Praxisbeispiel: Change veraltet Runbook**

**Situation**

Nach einem Update ändert sich der Neustartprozess eines Dienstes.

**Problem**

Das alte Runbook beschreibt noch die frühere Reihenfolge.

**Risiko**

Administratoren führen im Störungsfall falsche Schritte aus.

**Verbesserung**

Change-Abschluss enthält künftig:

- betroffene Runbooks prüfen,
- Knowledge Owner informieren,
- Review-Datum setzen,
- alte Version archivieren.

---

**Praxisbeispiel: Major Incident**

**Situation**

Ein zentraler Dienst fällt aus.

**Review zeigt**

- Service Desk hatte keinen passenden Artikel,
- Eskalationsweg war unklar,
- Statusmeldung musste improvisiert werden,
- Runbook für Wiederherstellung war veraltet.

**Knowledge-Verbesserungen**

- Service-Desk-Artikel erstellen,
- Major-Incident-Kommunikationsvorlage ergänzen,
- Runbook aktualisieren,
- Known Error dokumentieren,
- Service Map verlinken.

---

**Typische Fehler**

**Fehler 1**

Knowledge Management wird getrennt von Incident, Problem und Change betrieben.

---

**Fehler 2**

Gelöste Incidents erzeugen kein wiederverwendbares Wissen.

---

**Fehler 3**

Problem Management dokumentiert Known Errors, aber der Service Desk findet sie nicht.

---

**Fehler 4**

Workarounds bleiben nur in Tickets.

---

**Fehler 5**

Changes aktualisieren Knowledge-Artikel nicht.

---

**Fehler 6**

Releases erzeugen neue Benutzerfragen, aber keine FAQ.

---

**Fehler 7**

Service Desk Feedback wird nicht bearbeitet.

---

**Fehler 8**

Knowledge-Artikel sind nicht mit Services oder CIs verknüpft.

---

**Fehler 9**

Sicherheitsartikel sind entweder zu offen oder zu stark eingeschränkt.

---

**Fehler 10**

Major-Incident-Lessons-Learned werden nicht in Knowledge übernommen.

---

**Fehler 11**

Artikel werden an Kennzahlen gemessen, aber nicht fachlich geprüft.

---

**Fehler 12**

Niemand ist verantwortlich für Pflege und Review.

---

**Checkliste Incident zu Knowledge**

- [ ] wiederkehrendes Fehlerbild erkannt
- [ ] Lösung oder Workaround dokumentiert
- [ ] passende Suchbegriffe ergänzt
- [ ] Zielgruppe festgelegt
- [ ] Service oder CI verknüpft
- [ ] Eskalationsweg beschrieben
- [ ] Risiken genannt
- [ ] Knowledge-Artikel im Ticket verknüpft
- [ ] Feedback aus Ticket berücksichtigt
- [ ] Problem Management informiert, falls Muster erkennbar

---

**Checkliste Problem zu Knowledge**

- [ ] Known Error dokumentiert
- [ ] Ursache oder wahrscheinliche Ursache beschrieben
- [ ] Workaround beschrieben oder als nicht verfügbar gekennzeichnet
- [ ] betroffene Versionen genannt
- [ ] betroffene Services und CIs verknüpft
- [ ] Service Desk Artikel erstellt
- [ ] Benutzerinformation geprüft
- [ ] dauerhafte Lösung oder Change vermerkt
- [ ] Review-Datum gesetzt
- [ ] Artikel nach Lösung aktualisiert oder archiviert

---

**Checkliste Change zu Knowledge**

- [ ] betroffene Artikel identifiziert
- [ ] Benutzerartikel geprüft
- [ ] Service-Desk-Artikel geprüft
- [ ] Runbooks geprüft
- [ ] Screenshots geprüft
- [ ] Menüpfade geprüft
- [ ] Known Errors geprüft
- [ ] Workarounds geprüft
- [ ] Service Desk informiert
- [ ] Artikel nach Umsetzung aktualisiert
- [ ] veraltete Artikel archiviert
- [ ] Knowledge-Prüfung im Change Record dokumentiert

---

**Checkliste Release zu Knowledge**

- [ ] Release Notes erstellt
- [ ] neue Funktionen beschrieben
- [ ] geänderte Funktionen beschrieben
- [ ] bekannte Einschränkungen dokumentiert
- [ ] FAQ vorbereitet
- [ ] Service Desk gebrieft
- [ ] Benutzerkommunikation vorbereitet
- [ ] neue Known Errors dokumentiert
- [ ] alte Workarounds geprüft
- [ ] Suchanfragen nach Release ausgewertet
- [ ] Artikel nach Feedback verbessert

---

**Checkliste Knowledge-Qualität im Zusammenspiel**

- [ ] Artikel besitzt Owner
- [ ] Review-Datum vorhanden
- [ ] Zielgruppe klar
- [ ] Service oder CI verknüpft
- [ ] Problem oder Known Error verknüpft, falls relevant
- [ ] Change oder Release verknüpft, falls relevant
- [ ] Risiken und Grenzen beschrieben
- [ ] Eskalationsweg klar
- [ ] Zugriffsschutz passend
- [ ] Feedbackmöglichkeit vorhanden
- [ ] Nutzung wird ausgewertet
- [ ] veraltete Inhalte werden archiviert

---

**Bedeutung für Fachinformatiker für Systemintegration**

Fachinformatiker stehen häufig genau dort, wo wichtiges Wissen entsteht.

Im Arbeitsalltag bedeutet das:

- Lösungen aus Incidents dokumentieren,
- wiederkehrende Fehler an Problem Management melden,
- Workarounds sicher beschreiben,
- Known Errors technisch prüfen,
- Runbooks für Betriebsaufgaben erstellen,
- nach Changes Artikel aktualisieren,
- Service Desk mit Prüfschritten unterstützen,
- Configuration Items verknüpfen,
- Benutzerwissen technisch korrekt vorbereiten,
- und Lessons Learned in nutzbare Dokumentation übertragen.

Gute Wissensarbeit macht technischen Betrieb stabiler, schneller und weniger abhängig von Einzelpersonen.

---

**Zusammenfassung**

> Incident liefert Erfahrung  
> ↓  
> Problem Management erkennt Ursachen und Known Errors  
> ↓  
> Knowledge Management macht Wissen nutzbar  
> ↓  
> Service Desk verwendet Artikel im Alltag  
> ↓  
> Change und Release verändern Services  
> ↓  
> Knowledge wird aktualisiert  
> ↓  
> Self-Service stellt Benutzerwissen bereit  
> ↓  
> Feedback und Kennzahlen zeigen Lücken  
> ↓  
> Continual Improvement verbessert Inhalte und Prozesse

---

**Merksätze**

> Knowledge Management verbindet Lernen mit täglichem IT-Betrieb.

> Incidents liefern Hinweise auf fehlendes oder falsches Wissen.

> Problem Management liefert Known Errors, Ursachen und Workarounds.

> Changes und Releases müssen Knowledge aktualisieren.

> Service Desk Feedback ist eine der wichtigsten Quellen für Wissensqualität.

> Knowledge ohne Service- oder CI-Bezug ist schwerer nutzbar.

> Lessons Learned sind nur wertvoll, wenn sie in nutzbares Wissen überführt werden.

---

**Verwandte Seiten**

- 7.1 Knowledge Management – Ziele, Begriffe und Grundlagen
- 7.2 Knowledge-Artikel, Runbooks und FAQ
- 7.3 Known Errors, Workarounds und Wissensnutzung im Service Desk
- 7.4 Self-Service und Benutzerwissen
- Incident Management
- Problem Management
- Change Enablement
- Release Management
- Service Configuration Management
- Continual Improvement

---

**Quellen und Versionsstand**

**Offizielle Grundlagen**

- PeopleCert – ITIL Practice Guide: Knowledge Management
- PeopleCert – ITIL Practice Guide: Incident Management
- PeopleCert – ITIL Practice Guide: Problem Management
- PeopleCert – ITIL Practice Guide: Change Enablement
- PeopleCert – ITIL Practice Guide: Release Management
- PeopleCert – ITIL Practice Guide: Service Configuration Management
- PeopleCert – ITIL Practice Guide: Continual Improvement
- ITIL Foundation – Version 5

**Ergänzende Praxiseinordnung**

- Knowledge-Centered Service als verbreiteter Praxisansatz für Wissensarbeit im Support

**Einordnung**

Die dargestellten:

- Schnittstellen,
- Informationsflüsse,
- Rollenhinweise,
- Checklisten,
- Praxisbeispiele,
- und Qualitätskriterien

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

- Knowledge-Prozessschnittstelle,
- Artikelpflicht nach jedem Incident,
- Review-Frequenz,
- Verknüpfungsregel,
- Rollenmatrix,
- oder Toolintegration

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

- Services,
- Zielgruppen,
- Supportmodell,
- Knowledge-Werkzeuge,
- Sicherheitsanforderungen,
- Problem Management,
- Change-Modell,
- Release-Modell,
- 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