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

Revision #1
Created 2 August 2026 16:43:04 by Admin
Updated 2 August 2026 16:43:56 by Admin