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:

Wenn dieses Wissen nicht dokumentiert wird, entstehen typische Probleme:

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:

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:

Implizites Wissen

ist in den Köpfen von Personen vorhanden.

Beispiele:

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:

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:

Das Werkzeug ist nicht entscheidend.

Möglich sind:

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:

Self-Service funktioniert nur, wenn Artikel:

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:

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:

Incident Management liefert auch neues Wissen zurück.

Beispiele:

Knowledge Management und Problem Management

Problem Management erzeugt wichtiges Wissen.

Beispiele:

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:

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:

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:

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:

Eine gute Frage ist:

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

Wissen erfassen

Wissen kann erfasst werden aus:

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

Wissen prüfen

Vor Veröffentlichung sollte geprüft werden:

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

Wissen veröffentlichen

Bei Veröffentlichung ist wichtig:

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

Wissen nutzen

Wissen sollte aktiv in Prozesse eingebunden sein.

Beispiele:

Ungenutztes Wissen veraltet schneller.

Feedback sammeln

Feedback hilft, Knowledge-Artikel zu verbessern.

Mögliche Signale:

Feedback sollte einfach möglich sein.

Wissen aktualisieren

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

Auslöser:

Ein Artikel ohne Pflegeverantwortung veraltet meist schnell.

Wissen archivieren

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

Beispiele:

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:

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:

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:

Benutzerartikel sollten keine unnötigen internen Fachbegriffe enthalten.

Struktur eines Runbooks

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

Mögliche Inhalte:

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:

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:

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:

Ohne Owner veralten Artikel häufig.

Review-Datum

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

Besonders wichtig bei:

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:

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:

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:

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

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:

Nutzen

Die Aufgabe wird sicherer und wiederholbarer.

Checkliste Knowledge-Artikel erstellen

Checkliste Benutzerartikel

Checkliste interner Supportartikel

Checkliste Knowledge-Pflege

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:

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

Quellen und Versionsstand

Offizielle Grundlagen

Ergänzende Praxiseinordnung

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

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:

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:

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:

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:

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:

Ein Benutzerartikel sollte anders geschrieben sein als ein internes Runbook.

Beispiel: Gleiches Thema, verschiedene Zielgruppen

Thema:

VPN verbindet nicht.

Benutzerartikel

Service-Desk-Artikel

Fachteam-Runbook

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:

Beispiel:

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

So wird der Artikel besser gefunden.

Struktur eines Knowledge-Artikels

Ein guter Knowledge-Artikel kann enthalten:

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:

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:

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:

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:

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:

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:

Dann müssen enthalten sein:

Nicht jedes Runbook darf für alle sichtbar sein.

Screenshots verwenden

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

Vorteile:

Risiken:

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:

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:

Beispiel:

Ein VPN-Artikel wird verknüpft mit:

Artikel mit Incidents verknüpfen

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

Nutzen:

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:

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:

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:

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:

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:

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:

Zu prüfen ist:

Falsche Sichtbarkeit kann Sicherheits- oder Datenschutzrisiken erzeugen.

Qualität eines Artikels prüfen

Ein Artikel ist gut, wenn:

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

Tiefendokumentation

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

Nicht enthalten

Beispiel: Service-Desk-Artikel VPN

Titel

VPN verbindet nach Ruhezustand nicht mehr

Zielgruppe

Service Desk

Inhalt

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

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.

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:

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

Quellen und Versionsstand

Offizielle Grundlagen

Ergänzende Praxiseinordnung

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

Diese Grenzen verhindern, dass ein Workaround falsch oder riskant angewendet wird.

Risiken eines Workarounds

Workarounds können Risiken haben.

Beispiele:

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:

Eskalationskriterien verhindern unnötige Verzögerungen.

Ticketdokumentation

Wenn ein Known Error oder Workaround genutzt wurde, sollte das Ticket sauber dokumentiert werden.

Wichtige Angaben:

Gute Ticketdokumentation unterstützt Trendanalyse und Problem Management.

Verknüpfung mit Problem Management

Known Errors entstehen oft aus Problem Management.

Problem Management liefert:

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:

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:

Der Knowledge-Artikel sollte zeigen:

Verknüpfung mit Release Management

Nach einem Release kann sich der Status eines Known Errors ändern.

Beispiele:

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:

Vorteile:

Benutzerkommunikation bei Known Errors

Benutzer sollten verständlich informiert werden.

Gute Kommunikation enthält:

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

Service-Desk-Artikel

Fachteam-Artikel

Nicht jedes Detail gehört in jeden Artikel.

Known Error ohne Workaround

Nicht jeder Known Error besitzt einen sicheren Workaround.

Beispiele:

Dann muss der Artikel klar sagen:

Ein fehlender Workaround sollte ausdrücklich dokumentiert werden.

Known Error mit Risikoakzeptanz

Manche Known Errors bleiben längere Zeit offen.

Gründe:

Dann sollte dokumentiert werden:

Knowledge-Artikel im Ticket vorschlagen

Viele ITSM-Systeme können Artikel im Ticket vorschlagen.

Grundlagen dafür:

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:

Diese Daten helfen, Wissen und Problems gezielt zu verbessern.

Artikelqualität aus Service-Desk-Sicht

Ein Service-Desk-Artikel ist gut, wenn er:

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:

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:

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:

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:

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

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

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

Checkliste Workaround

Checkliste Service Desk Nutzung

Checkliste Wissenspflege

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:

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

Quellen und Versionsstand

Offizielle Grundlagen

Ergänzende Praxiseinordnung

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

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:

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

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:

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:

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:

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:

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:

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

Voraussetzungen für guten Self-Service

Guter Self-Service benötigt:

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:

Ein gutes Serviceportal beantwortet schnell:

Servicekatalog im Self-Service

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

Beispiele:

Ein guter Servicekatalog erklärt:

Gute Request-Formulare

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

Ein gutes Formular:

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:

Dadurch kann der Service Desk schneller arbeiten.

Knowledge-Artikel im Self-Service

Benutzerartikel im Self-Service sollten:

Beispielartikel:

Suchfunktion

Die Suche ist entscheidend.

Benutzer suchen nicht nach internen IT-Begriffen.

Sie suchen nach:

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:

Kategorien sollten aus Benutzersicht benannt werden.

Ungeeignet:

Besser:

Statusinformationen

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

Beispiele:

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:

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:

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

Risiken von Automatisierung im Self-Service

Automatisierung muss kontrolliert werden.

Risiken:

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:

Das Portal sollte klar anzeigen:

Self-Service und Sicherheit

Self-Service muss sicher gestaltet sein.

Zu 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:

Zu prüfen ist:

Formulare sollten keine unnötigen personenbezogenen Daten abfragen.

Self-Service und Barrierearmut

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

Zu beachten:

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

Benutzerfeedback

Benutzer sollten Rückmeldung geben können.

Mögliche Fragen:

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:

Self-Service-Erfolg messen

Self-Service ist erfolgreich, wenn:

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:

Negativ:

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

Self-Service und Service Desk verbinden

Self-Service und Service Desk sollten zusammenarbeiten.

Beispiele:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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

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

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

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:

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

Checkliste Benutzerartikel

Checkliste Serviceportal

Checkliste Self-Service-Formular

Checkliste Self-Service verbessern

Bedeutung für Fachinformatiker für Systemintegration

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

Im Arbeitsalltag bedeutet das:

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

Quellen und Versionsstand

Offizielle Grundlagen

Ergänzende Praxiseinordnung

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

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:

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

Dann entstehen typische Probleme:

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:

Beispiel:

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

Der Service Desk findet einen Knowledge-Artikel mit:

Dadurch muss der Incident nicht neu analysiert werden.

Incident Management liefert Wissen zurück

Incidents zeigen, welches Wissen fehlt oder verbessert werden muss.

Beispiele:

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:

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:

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:

Dadurch kann Incident Management neue Incidents schneller zuordnen.

Knowledge Management unterstützt Problem Management

Knowledge Management hilft Problem Management durch:

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:

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:

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:

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:

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:

Er liefert Knowledge zurück durch:

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:

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:

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:

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:

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:

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:

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:

Falsches Sicherheitswissen kann zu hohen Risiken führen.

Zusammenspiel mit Continual Improvement

Knowledge Management liefert viele Hinweise für Verbesserungen.

Beispiele:

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:

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:

Ohne Knowledge Owner veralten wichtige Artikel schnell.

Service Owner

Der Service Owner hilft zu klären:

Service Owner verbinden technische Informationen mit Service- und Benutzerperspektive.

Fachteams

Fachteams liefern technisches Wissen.

Beispiele:

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

Service-Desk-Artikel

Fachteam-Runbook

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

Wissensqualität im Zusammenspiel

Wissensqualität bedeutet:

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:

Ein Major Incident Review ohne Knowledge-Aktualisierung verschenkt Lernpotenzial.

Wissen aus Failed Changes

Auch fehlgeschlagene Changes liefern wertvolles Wissen.

Zu prüfen ist:

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

Wissen aus Releases

Nach Releases sollte beobachtet werden:

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:

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:

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:

Praxisbeispiel: Major Incident

Situation

Ein zentraler Dienst fällt aus.

Review zeigt

Knowledge-Verbesserungen

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

Checkliste Problem zu Knowledge

Checkliste Change zu Knowledge

Checkliste Release zu Knowledge

Checkliste Knowledge-Qualität im Zusammenspiel

Bedeutung für Fachinformatiker für Systemintegration

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

Im Arbeitsalltag bedeutet das:

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

Quellen und Versionsstand

Offizielle Grundlagen

Ergänzende Praxiseinordnung

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026