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

Checkliste Runbook

Checkliste FAQ

Checkliste Artikelqualität

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