# 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