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