ITIL in der Praxis

Praxisorientiertes Lern-, Arbeits- und Nachschlagewerk für professionelles IT-Service-Management. Das Buch verbindet ITIL-Grundlagen mit konkreten Arbeitsabläufen, Entscheidungshilfen, Checklisten und Erfahrungswissen für Fachinformatiker Systemintegration.

0. ITIL - Über dieses Buch

0. ITIL - Über dieses Buch

0.1 Über dieses Buch – Ziel, Arbeitsweise und Qualitätsmaßstab

Kurz erklärt

Dieses Buch vermittelt Grundlagen und Zusammenhänge des professionellen IT-Service-Managements.

Es zeigt außerdem, wie Fachinformatiker für Systemintegration dieses Wissen im täglichen IT-Betrieb anwenden können.

Das Buch ist damit gleichzeitig:

Ziel dieses Buches

Dieses Buch verbindet fachliches ITIL-Wissen mit konkreten Situationen aus dem Arbeitsalltag eines Fachinformatikers für Systemintegration.

Es soll dabei helfen:

Das notwendige Fachwissen bildet dafür die Grundlage.

Der praktische Nutzen entscheidet darüber, wie dieses Wissen erklärt und aufbereitet wird.

Leitsatz

Wissen hilft dabei, Zusammenhänge zu verstehen.

Struktur hilft dabei, dieses Wissen im richtigen Moment richtig anzuwenden.

Für wen ist dieses Buch gedacht?

Das Buch richtet sich insbesondere an:

Die Inhalte berücksichtigen unterschiedliche Wissensstände.

Wissensstand Schwerpunkt
Einsteiger verständliche Grundlagen, Fachbegriffe und erste Praxisbeispiele
Fortgeschrittene Abläufe, Zusammenhänge, Entscheidungshilfen und technische Einordnung
Erfahrene Fachkräfte Schnellreferenzen, Risiken, Sonderfälle, Checklisten und Verbesserungsmöglichkeiten

Das Buch soll sowohl beim Lernen als auch später im beruflichen Alltag verwendet werden können.

Was dieses Buch vermitteln soll

Das Buch soll nicht nur Definitionen bereitstellen.

Es soll drei miteinander verbundene Fähigkeiten entwickeln:

  1. Verstehen
  2. Anwenden
  3. Erfahrung aufbauen

Diese Ebenen greifen ineinander.

Fachwissen ohne Anwendung bleibt theoretisch.

Anwendung ohne ausreichendes Verständnis kann zu Fehlern führen.

Erfahrung hilft dabei, Risiken, Zusammenhänge und Sonderfälle früher zu erkennen.

Die drei Wissensebenen

Ebene Leitfrage Inhalt
Verstehen Was ist das und warum ist es wichtig? Begriffe, Grundlagen, Ziele und Zusammenhänge
Anwenden Wie gehe ich konkret vor? Abläufe, Checklisten, Werkzeuge und Entscheidungshilfen
Erfahrung Was muss ich in der Praxis zusätzlich beachten? Risiken, typische Fehler, Sonderfälle und bewährte Vorgehensweisen

Nicht jede Seite muss alle drei Ebenen gleich ausführlich behandeln.

Es soll jedoch erkennbar sein, ob ein Abschnitt:

So arbeitet dieses Buch

Die Inhalte verbinden die drei Wissensebenen miteinander:

  1. Verstehen – Begriffe, Ziele und Zusammenhänge erfassen.
  2. Anwenden – Wissen in konkrete Handlungen und Entscheidungen übertragen.
  3. Erfahrung – Risiken, typische Fehler und Sonderfälle berücksichtigen.

Dadurch soll aus theoretischem Wissen eine sichere und nachvollziehbare Arbeitsweise entstehen.

Vom Wissen zur professionellen Arbeitsweise

Fachwissen → ITIL-Einordnung → Handlung → Dokumentation → Verbesserung

Interaktive Darstellung öffnen

Hinweis

Die statische Grafik enthält die Kernaussage vollständig.

Die interaktive Darstellung ergänzt weitere Erklärungen und Praxisbeispiele, ist für das Verständnis der Seite aber nicht zwingend erforderlich.

Warum ITIL für Systemintegratoren wichtig ist

Fachinformatiker für Systemintegration arbeiten nicht ausschließlich mit:

Zum Berufsalltag gehören ebenfalls:

Technisches Wissen beantwortet beispielsweise die Frage:

Wie untersuche und behebe ich einen ausgefallenen Dienst?

Service Management hilft zusätzlich bei folgenden Fragen:

Professionelle IT-Arbeit verbindet technische Kompetenz mit einer strukturierten und serviceorientierten Arbeitsweise.

Technische und organisatorische Perspektive

Viele Aufgaben eines Systemintegrators besitzen zwei unterschiedliche Perspektiven.

Perspektive Zentrale Frage
Technische Perspektive Wie untersuche, konfiguriere oder repariere ich das System?
Service-Management-Perspektive Wie ordne, priorisiere, koordiniere und dokumentiere ich die Arbeit?

Beispiel:

Ein Webserver ist nicht erreichbar.

Die technische Perspektive kann folgende Prüfungen umfassen:

Die Service-Management-Perspektive ergänzt:

Merke

Technische Fehleranalyse und Service Management ersetzen sich nicht.

Sie ergänzen sich.

Was ITIL leistet

ITIL ist ein anpassbares Best-Practice-Framework für das Management digitaler Produkte und Services.

Es unterstützt Organisationen unter anderem dabei:

ITIL ist kein starres Regelwerk.

Es schreibt nicht für jedes Unternehmen dieselben:

vor.

Die Inhalte müssen an den jeweiligen Kontext angepasst werden.

Grundsatz

ITIL soll die Wertschöpfung unterstützen.

Es soll keine unnötige Bürokratie erzeugen.

Was ITIL nicht leistet

ITIL ersetzt nicht:

ITIL erklärt beispielsweise nicht im Detail:

Das Framework hilft stattdessen dabei, technische Tätigkeiten sinnvoll zu:

Aktueller ITIL-Stand dieses Buches

Dieses Buch trägt absichtlich keine Versionsnummer im Titel.

ITIL wird weiterentwickelt, während ältere Versionen in Unternehmen weiterhin verbreitet sein können.

Für dieses Buch gelten deshalb folgende Regeln:

Beispiel:

ITIL Version 5 ITIL 4
Change Management Change Enablement

Beide Begriffe können in bestehenden Organisationen und Unterlagen vorkommen.

Innerhalb dieses Buches wird bei relevanten Unterschieden angegeben, auf welche Version sich eine Aussage bezieht.

Offizielle Inhalte und Praxiswissen unterscheiden

Das Buch unterscheidet verschiedene Informationsarten.

Informationsart Bedeutung
ITIL-Grundlage Begriff, Modell, Prinzip oder Practice aus dem offiziellen Framework
Offizielle Quelle Aussage aus einer offiziellen Veröffentlichung oder Herstellerdokumentation
Best Practice allgemein bewährte Vorgehensweise
Praxisempfehlung zusätzliche Empfehlung für den Arbeitsalltag
Praxisbeispiel vereinfachte Situation zur Erklärung
Community-Hinweis Erfahrungsbericht ohne gleichwertige offizielle Bestätigung
Eigener Test Ergebnis aus einer dokumentierten eigenen Testumgebung
Versionsabhängig Aussage kann sich durch eine neue Version verändern
Umgebungsabhängig Aussage gilt nur unter bestimmten Bedingungen
Sicherheitsrelevant Handlung kann Vertraulichkeit, Integrität oder Verfügbarkeit beeinflussen

Eine Praxisempfehlung wird nicht als offizielle ITIL-Vorgabe dargestellt.

Eine Community-Erfahrung wird nicht ohne Prüfung als allgemein gültige Lösung übernommen.

Eine technisch mögliche Handlung wird nicht automatisch als sicher oder betrieblich zulässig betrachtet.

Die 30-Sekunden-Regel

Eine Seite soll so aufgebaut sein, dass innerhalb von etwa 30 Sekunden erkennbar ist:

Dafür verwendet das Buch bevorzugt:

Die schnelle Orientierung darf nicht dazu führen, dass notwendiges Grundlagenwissen oder wichtige Einschränkungen fehlen.

Qualitätsmaßstab

Vor der Veröffentlichung oder einer größeren Überarbeitung wird insbesondere geprüft:

Wichtigste Kontrollfrage

Hilft diese Seite einem Fachinformatiker dabei, seinen Arbeitsalltag besser, sicherer oder effizienter zu bewältigen?

Eigenständigkeit und rechtlicher Hinweis

Dieses Buch ist eine unabhängige, öffentlich zugängliche Wissenssammlung.

Es ist:

Offizielle Inhalte werden in eigenen Worten zusammengefasst und durch selbst erstellte:

ergänzt.

ITIL® und PeopleCert® sind eingetragene Marken von PeopleCert International Limited.

Alle Rechte an den Marken und offiziellen Veröffentlichungen verbleiben bei den jeweiligen Rechteinhabern.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die praktischen Beispiele, Qualitätsregeln und Hinweise zur Nutzung dieses Buches sind redaktionelle Festlegungen dieses unabhängigen Nachschlagewerks.

Sie sind keine vorgeschriebenen ITIL-Prozesse.

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

0. ITIL - Über dieses Buch

0.2 So nutzt du dieses Buch

Kurz erklärt

Dieses Buch kann vollständig von Anfang bis Ende gelesen oder gezielt als Nachschlagewerk und praktische Arbeitshilfe verwendet werden.

Du musst nicht jedes Kapitel gelesen haben, bevor du mit einer konkreten Aufgabe arbeitest. Die Seiten sind so aufgebaut, dass zentrale Informationen auch einzeln verständlich und schnell auffindbar sind.

Drei Möglichkeiten, dieses Buch zu verwenden

Nutzung Wann ist sie sinnvoll? Vorgehensweise
Lernen Du möchtest ITIL und professionelles Service Management systematisch verstehen. Kapitel in der vorgesehenen Reihenfolge durcharbeiten.
Nachschlagen Du suchst eine Definition, Abgrenzung oder Entscheidungshilfe. Über Inhaltsverzeichnis, Suche oder Querverweise direkt zur passenden Seite wechseln.
Arbeiten Du befindest dich in einer konkreten Arbeitssituation. Schnellübersicht, Vorgehensweise und Checkliste der passenden Seite verwenden.

Die drei Nutzungsarten schließen sich nicht gegenseitig aus.

Eine Seite kann zunächst zum Lernen gelesen und später als kompakte Arbeitshilfe verwendet werden.

Wenn du das Thema vollständig lernen möchtest

Für ein systematisches Verständnis empfiehlt sich folgende Reihenfolge:

  1. Grundlagen des professionellen Service Managements
  2. zentrale Begriffe wie Produkt, Service, Wert, Outcome, Kosten und Risiken
  3. Aufbau und Denkweise von ITIL
  4. Produkte, Services, Wertströme und Lebenszyklus
  5. Zusammenarbeit mit Benutzern, Kunden und weiteren Stakeholdern
  6. professionelle Ticketbearbeitung
  7. wichtige ITIL Practices
  8. typische Situationen aus dem IT-Betrieb
  9. Praxisfälle, Checklisten und Entscheidungshilfen

Die Grundlagenkapitel vermitteln das notwendige Verständnis für spätere Themen.

Es ist beispielsweise hilfreich, zunächst die Begriffe Service, Wert, Output, Outcome, Kosten, Risiko und Stakeholder zu verstehen, bevor einzelne Practices und deren Zusammenwirken vertieft werden.

Merke

Die praktische Anwendung wird leichter verständlich, wenn die zugrunde liegenden Begriffe, Ziele und Zusammenhänge bekannt sind.

Wenn du schnell etwas nachschlagen möchtest

Beim Nachschlagen musst du nicht jede Seite vollständig von oben bis unten lesen.

Orientiere dich zunächst an den folgenden Bereichen:

Gesuchte Information Geeigneter Abschnitt
schnelle Einordnung des Themas Kurz erklärt
Bedeutung eines Begriffs Grundlagen oder Schnellzusammenfassung
konkrete Arbeitsschritte Vorgehensweise
schnelle Kontrolle Checkliste
Auswahl zwischen mehreren Möglichkeiten Entscheidungshilfe
häufige Fehlentscheidungen Typische Fehler
mögliche Gefahren und Auswirkungen Risiken und Sicherheitsaspekte
zusätzliche Erfahrung aus der Praxis Praxistipp
wichtigste Kernaussage Merke
technische Vertiefung Verwandte Seiten
Herkunft einer Aussage Quellen und Versionsstand

Die wichtigsten Informationen stehen nach Möglichkeit weit oben auf der Seite.

Vertiefungen, Sonderfälle, Beispiele und Quellen folgen anschließend.

Wenn du dich in einer konkreten Arbeitssituation befindest

Angenommen, ein Benutzer meldet:

„Ich kann mich seit heute Morgen nicht mehr anmelden.“

Dann musst du nicht sofort das gesamte Kapitel über Incident Management lesen.

Gehe stattdessen schrittweise vor:

  1. konkrete Situation erfassen
  2. betroffenen Service bestimmen
  3. betroffene Benutzer und Auswirkungen ermitteln
  4. nach Service, Fehlermeldung oder beobachtetem Verhalten suchen
  5. passende Praxis- oder Schnellreferenzseite öffnen
  6. Voraussetzungen und wichtigste Rückfragen prüfen
  7. geeignete Vorgehensweise auswählen
  8. Sicherheits-, Eskalations- und Freigabekriterien beachten
  9. durchgeführte Schritte und Ergebnisse dokumentieren
  10. bei Bedarf technische Querverweise verwenden
  11. prüfen, ob eine weitere Untersuchung oder Verbesserung notwendig ist

Wichtig

Eine Checkliste unterstützt die Arbeit.

Sie ersetzt nicht die fachliche Bewertung der konkreten Situation.

Schnellzugriff nach Arbeitssituation

Situation Passender Themenbereich
Ein Benutzer meldet eine Störung. Incident Management
Ein Benutzer benötigt einen vorgesehenen Standardservice. Service Request Management
Derselbe oder ein ähnlicher Fehler tritt wiederholt auf. Problem Management
Eine technische oder organisatorische Änderung soll durchgeführt werden. Change Management
Ein kritischer Incident beeinträchtigt einen wichtigen Service. Incident Management und betrieblicher Major-Incident-Ablauf
Eine Lösung soll dauerhaft für Kollegen verfügbar sein. Knowledge Management
Hardware, Software oder Lizenzen sollen verwaltet werden. IT Asset Management
Abhängigkeiten zwischen Services und Komponenten sollen erfasst werden. Service Configuration Management
Ein Monitoring-System erzeugt eine Meldung. Monitoring and Event Management
Ein externer Dienstleister muss eingebunden werden. Supplier Management
Vereinbarte Serviceziele werden nicht erreicht. Service Level Management
Eine Arbeitsweise oder ein Service soll verbessert werden. Continual Improvement
Ein sicherheitsrelevantes Ereignis wurde erkannt. Information Security Management und betriebliche Sicherheitsverfahren

Diese Zuordnung dient als erste Orientierung.

Eine Arbeitssituation kann mehrere Practices, technische Fachbereiche und betriebliche Verfahren gleichzeitig betreffen.

Hinweis

Ein Major Incident ist ein besonders schwerwiegender Incident.

Die Kriterien, Rollen, Kommunikationswege und Eskalationsverfahren dafür werden von der jeweiligen Organisation festgelegt.

Technische und serviceorientierte Perspektive verbinden

Viele Aufgaben eines Fachinformatikers für Systemintegration besitzen mindestens zwei Perspektiven.

Perspektive Zentrale Frage
Technische Perspektive Wie untersuche, konfiguriere oder repariere ich das System?
Serviceorientierte Perspektive Welche Auswirkungen bestehen und wie wird die Arbeit koordiniert, dokumentiert und bewertet?

Beispiel:

Ein Webserver ist nicht erreichbar.

Die technische Perspektive kann folgende Prüfungen umfassen:

Die serviceorientierte Perspektive ergänzt:

Merke

Technische Fehleranalyse und Service Management ersetzen sich nicht.

Sie ergänzen sich.

Die Seitenarten dieses Buches

Nicht jede Seite verfolgt denselben Zweck.

Seitenart Zweck
Grundlagenseite erklärt Begriffe, Modelle und Zusammenhänge
Practice-Seite beschreibt Zweck, Nutzen und Anwendung einer Management Practice
Praxisfall zeigt eine realistische Arbeitssituation
Vorgehensweise führt schrittweise durch eine Aufgabe
Entscheidungshilfe unterstützt bei Auswahl, Priorisierung oder Eskalation
Checkliste ermöglicht eine schnelle Kontrolle wichtiger Punkte
Vorlage liefert eine wiederverwendbare Dokumentationsstruktur
Schnellreferenz fasst wichtige Informationen kompakt zusammen
Vergleichsseite grenzt ähnliche Begriffe oder Vorgehensweisen voneinander ab
Glossarseite erklärt Fachbegriffe und Abkürzungen

Die Seitenart soll möglichst bereits durch Titel und Aufbau erkennbar sein.

So erkennst du wichtige Hinweise

Im Buch werden wiederkehrende Kennzeichnungen verwendet.

Kennzeichnung Bedeutung
Kurz erklärt kompakte Einordnung des Themas
ITIL-Grundlage Begriff, Modell oder Inhalt aus dem offiziellen Framework
Offizielle Quelle Aussage aus einer offiziellen Veröffentlichung oder Dokumentation
Praxisbeispiel realistische oder vereinfachte Arbeitssituation
Vorgehensweise empfohlene Reihenfolge von Arbeitsschritten
Entscheidungshilfe Unterstützung bei einer konkreten Auswahl
Typischer Fehler häufige oder besonders relevante Fehlentscheidung
Risiko mögliche technische, organisatorische oder sicherheitsrelevante Folge
Praxistipp zusätzliche bewährte Empfehlung für den Arbeitsalltag
Merke zentrale Aussage zum schnellen Wiederholen
Checkliste Punkte zur direkten Kontrolle
Versionsabhängig Information kann sich durch neue Versionen verändern
Umgebungsabhängig Information gilt nur unter bestimmten Voraussetzungen
Verwandte Seiten passende Grundlagen oder Vertiefungen

Nicht jede Kennzeichnung wird auf jeder Seite verwendet.

Es werden nur Elemente eingesetzt, die für das jeweilige Thema einen tatsächlichen Nutzen bieten.

Querverweise richtig verwenden

IT-Aufgaben lassen sich selten vollständig einem einzigen Thema zuordnen.

Ein fehlgeschlagener Anmeldevorgang kann beispielsweise folgende Bereiche betreffen:

Querverweise helfen dabei:

Grundsatz

Ein Querverweis soll eine konkrete Frage beantworten oder die nächste sinnvolle Vertiefung ermöglichen.

So verwendest du die Suche

Beginne mit dem wichtigsten Begriff der Situation.

Geeignete Suchbegriffe können sein:

Falls ein Begriff keine passenden Ergebnisse liefert, suche zusätzlich:

Beispiel:

Statt ausschließlich nach Outlook zu suchen, können folgende Suchbegriffe hilfreicher sein:

So verwendest du Checklisten

Checklisten helfen dabei, wichtige Punkte nicht zu vergessen.

Sie eignen sich besonders:

Eine Checkliste ist jedoch keine automatische Handlungsanweisung.

Prüfe immer:

So verwendest du Vorlagen

Vorlagen stellen eine Ausgangsbasis dar.

Sie können beispielsweise verwendet werden für:

Vorlagen müssen an die tatsächliche Situation angepasst werden.

Nicht relevante Abschnitte können entfernt werden.

Fehlende Informationen müssen ergänzt werden.

Typischer Fehler

Eine vollständig ausgefüllte Vorlage ist nicht automatisch eine gute Dokumentation.

Entscheidend ist, ob ein anderer Mitarbeiter die Situation, die durchgeführten Schritte und die getroffenen Entscheidungen nachvollziehen kann.

Arbeiten unter Zeitdruck

Bei einem kritischen Incident solltest du dich zunächst auf folgende Punkte konzentrieren:

  1. unmittelbare Gefahren und Sicherheitsrisiken erkennen
  2. betroffenen Service bestimmen
  3. Auswirkungen und Dringlichkeit feststellen
  4. Zuständigkeit und Eskalation klären
  5. Service stabilisieren oder wiederherstellen
  6. Beteiligte angemessen informieren
  7. wesentliche Beobachtungen und Maßnahmen dokumentieren
  8. Erfolg der Wiederherstellung kontrollieren
  9. Ursachenanalyse und Verbesserungen anschließend durchführen

Unter Zeitdruck kann die Dokumentation zunächst kompakt gehalten werden.

Wichtige Beobachtungen, Entscheidungen und Änderungen müssen trotzdem erfasst werden.

Praxistipp

Notiere während eines Incidents mindestens:

Beispiel:

Uhrzeit Beobachtung Maßnahme Ergebnis
09:12 Uhr Webservice nicht erreichbar Dienststatus geprüft Dienst gestoppt
09:15 Uhr Ursache noch unbekannt Dienst kontrolliert gestartet Service wieder erreichbar
09:20 Uhr Störung trat nach einer Änderung auf weiterer Untersuchungsbedarf dokumentiert Ursachenanalyse folgt

Das Buch ersetzt keine betrieblichen Vorgaben

Die Inhalte dieses Buches bieten Orientierung, Hintergrundwissen und praktische Unterstützung.

Im tatsächlichen Unternehmen gelten zusätzlich:

Bei einem Widerspruch haben verbindliche rechtliche, sicherheitsrelevante und betriebliche Vorgaben Vorrang.

Empfohlener Schnellablauf

  1. Situation erfassen
  2. betroffenen Service bestimmen
  3. Auswirkungen und Dringlichkeit bewerten
  4. passende Seite finden
  5. Voraussetzungen und Risiken prüfen
  6. geeignete Vorgehensweise anwenden
  7. Ergebnis kontrollieren
  8. Arbeit dokumentieren
  9. notwendige Folgeaktivitäten einleiten
  10. Verbesserungspotenzial prüfen

Checkliste für die Nutzung des Buches

Nutzungsweg durch das Buch

Situation erfassen
↓
passende Seite finden
↓
Grundlagen und Voraussetzungen prüfen
↓
Vorgehensweise anwenden
↓
Ergebnis kontrollieren
↓
Arbeit dokumentieren
↓
Verbesserung ableiten

Eine spätere interaktive Darstellung kann typische Arbeitssituationen anbieten und direkt zu den passenden Themenbereichen führen.

Verwandte Seiten

Quellen und Versionsstand

Diese Seite beschreibt die Nutzung und den redaktionellen Aufbau dieses unabhängigen Nachschlagewerks.

Die dargestellten Nutzungswege, Seitenarten, Checklisten und Suchstrategien sind Festlegungen dieses Buchprojekts und keine vorgeschriebenen ITIL-Prozesse.

Offizielle ITIL-Begriffe und Practices werden auf den jeweiligen Fachseiten anhand aktueller offizieller Quellen erläutert.

Fachlicher Stand: August 2026

0. ITIL - Über dieses Buch

0.3 Kennzeichnungen, Quellen und Versionsstände

Kurz erklärt

Dieses Buch unterscheidet klar zwischen:

Dadurch soll erkennbar bleiben:

Warum diese Unterscheidung wichtig ist

Nicht jede hilfreiche Aussage besitzt dieselbe Herkunft, Verbindlichkeit oder Beweiskraft.

Ein offizieller ITIL-Begriff ist anders zu bewerten als:

Werden diese Informationsarten miteinander vermischt, kann der falsche Eindruck entstehen, dass:

Dieses Buch trennt deshalb möglichst klar zwischen Herkunft, Gültigkeit und praktischer Einordnung einer Information.

Grundsatz

Eine hilfreiche Empfehlung muss nicht unmittelbar aus ITIL stammen.

Sie muss jedoch als Empfehlung erkennbar sein und darf nicht als offizielle Framework-Vorgabe dargestellt werden.

Die verwendeten Kennzeichnungen

Kennzeichnung Bedeutung
ITIL-Grundlage Begriff, Modell, Prinzip, Practice oder andere Aussage aus dem offiziellen ITIL-Framework
Verbindliche Vorgabe gesetzliche, vertragliche, sicherheitsrelevante oder betriebliche Regel, die eingehalten werden muss
Offizielle Quelle Aussage aus einer offiziellen Veröffentlichung, Norm, Hersteller- oder Projektdokumentation
Best Practice allgemein bewährte Vorgehensweise, die an den jeweiligen Kontext angepasst werden muss
Praxisempfehlung zusätzliche Empfehlung dieses Buches für den Arbeitsalltag
Praxisbeispiel realistische oder vereinfachte Situation zur Erklärung eines Zusammenhangs
Community-Hinweis Erfahrungsbericht oder Lösungsansatz ohne gleichwertige offizielle Bestätigung
Eigener Test Erkenntnis aus einer dokumentierten eigenen Testumgebung
Versionsabhängig Aussage kann sich durch eine andere oder neuere Version verändern
Umgebungsabhängig Aussage gilt nur unter bestimmten technischen oder organisatorischen Bedingungen
Sicherheitsrelevant Information oder Handlung kann Vertraulichkeit, Integrität oder Verfügbarkeit beeinflussen
Betriebliche Vorgabe beachten interne Rollen, Berechtigungen, Prozesse oder Freigaben können Vorrang haben
Noch zu prüfen Aussage oder Sonderfall ist noch nicht ausreichend belegt
Veraltet Inhalt bezieht sich ausdrücklich auf einen älteren Stand
Archiviert Inhalt wird vorwiegend aus historischen Gründen aufbewahrt

Nicht jede Seite benötigt alle Kennzeichnungen.

Sie werden nur verwendet, wenn sie das Verständnis, die Bewertung oder die sichere Anwendung eines Inhalts verbessern.

ITIL-Grundlage

Die Kennzeichnung ITIL-Grundlage wird verwendet, wenn ein Inhalt unmittelbar aus dem offiziellen ITIL-Framework stammt oder einen offiziellen ITIL-Begriff sinngemäß erklärt.

Beispiele:

Beispiel:

ITIL-Grundlage

Incident Management dient dazu, die negativen Auswirkungen von Incidents zu verringern, indem der normale Servicebetrieb so schnell wie unter den jeweiligen Bedingungen sinnvoll wiederhergestellt wird.

Eine solche Aussage wird nicht ohne Kennzeichnung mit zusätzlichen technischen oder persönlichen Empfehlungen vermischt.

Wichtig

Eine sinngemäße Erklärung in eigenen Worten ist keine wörtliche offizielle Definition.

Wörtliche Definitionen müssen eindeutig als Zitat gekennzeichnet und urheberrechtlich zulässig verwendet werden.

Verbindliche Vorgabe

Verbindliche Vorgaben besitzen Vorrang vor allgemeinen Empfehlungen dieses Buches.

Dazu können gehören:

Beispiel:

Betriebliche Vorgabe beachten

Auch wenn eine technische Änderung einfach rückgängig gemacht werden könnte, darf sie nicht ohne die im Unternehmen vorgeschriebene Freigabe durchgeführt werden.

Merke

Technisch möglich bedeutet nicht automatisch:

Offizielle Quelle

Die Kennzeichnung Offizielle Quelle wird verwendet, wenn eine Aussage aus einer maßgeblichen Primärquelle stammt.

Dazu gehören beispielsweise:

Beispiele:

Thema Bevorzugte offizielle Quelle
ITIL-Begriff oder ITIL-Modell offizielle ITIL- oder PeopleCert-Veröffentlichung
Microsoft-Produkt Microsoft Learn oder offizielle Produktdokumentation
Linux-Befehl Manpage oder offizielle Projektdokumentation
Docker-Funktion offizielle Docker-Dokumentation
Netzwerkprotokoll maßgeblicher RFC oder veröffentlichter Standard
Sicherheitswarnung Hersteller, BSI, CERT oder zuständige Sicherheitsorganisation
Softwarekonfiguration offizielle Dokumentation der verwendeten Version
Hardwarefunktion offizielles Handbuch, Datenblatt oder Supportdokument des Herstellers

Wichtig

Eine offizielle Quelle ist grundsätzlich zu bevorzugen.

Sie muss jedoch die konkrete Aussage tatsächlich belegen.

Eine allgemeine Produktseite bestätigt beispielsweise nicht automatisch:

Primärquelle und Sekundärquelle

Eine Primärquelle stammt direkt von der für den Inhalt verantwortlichen Stelle.

Beispiele:

Eine Sekundärquelle erklärt, bewertet oder fasst Primärquellen zusammen.

Beispiele:

Sekundärquellen können beim Verständnis sehr hilfreich sein.

Bei konkreten, versionsabhängigen oder sicherheitsrelevanten Aussagen sollten sie nach Möglichkeit durch eine geeignete Primärquelle ergänzt werden.

Grundsatz

Zum Lernen kann eine gute Sekundärquelle besonders verständlich sein.

Zum Belegen einer konkreten Herstellerfunktion ist normalerweise die Primärquelle stärker.

Best Practice

Eine Best Practice ist eine bewährte Vorgehensweise, die sich in vielen vergleichbaren Situationen als sinnvoll erwiesen hat.

Sie ist nicht automatisch:

Beispiele:

Best Practice

Eine bewährte Vorgehensweise muss an Größe, Risiken, Anforderungen und technische Umgebung der jeweiligen Organisation angepasst werden.

Praxisempfehlung

Eine Praxisempfehlung ergänzt offizielle Framework- oder Herstellerinformationen um konkrete Hinweise für den Arbeitsalltag.

Beispiel:

Praxisempfehlung

Notiere während eines laufenden Incidents mindestens:

Dadurch lässt sich der Ablauf später wesentlich leichter rekonstruieren.

Diese Empfehlung ist sinnvoll, aber nicht automatisch eine wörtliche ITIL-Vorgabe.

Praxisempfehlungen werden verwendet, wenn sie:

Praxisbeispiel

Praxisbeispiele übertragen theoretische Inhalte auf realistische Arbeitssituationen.

Beispiel:

Praxisbeispiel

Nach einem nächtlichen Update können sich mehrere Benutzer nicht mehr anmelden.

Technisch muss die Ursache untersucht werden. Aus Sicht des Service Managements müssen zusätzlich Auswirkungen, Priorität, Kommunikation, Eskalation und Dokumentation berücksichtigt werden.

Praxisbeispiele sind keine vollständig vorgeschriebenen Musterlösungen.

Die tatsächliche Vorgehensweise hängt unter anderem ab von:

Community-Hinweis

Community-Beiträge können besonders bei seltenen Fehlern, undokumentierten Besonderheiten oder neuen Softwareproblemen hilfreich sein.

Mögliche Quellen sind:

Ein Community-Beitrag belegt jedoch nicht automatisch, dass:

Community-Hinweis

Ein Community-Beitrag kann einen wertvollen Lösungsansatz liefern.

Vor der Anwendung müssen Version, Umgebung, Risiken und mögliche Nebenwirkungen geprüft werden.

Community-Aussagen werden nach Möglichkeit mit:

abgeglichen.

Eigener Test

Die Kennzeichnung Eigener Test wird verwendet, wenn eine Aussage in einer kontrollierten Umgebung praktisch geprüft wurde.

Eine solche Angabe sollte möglichst enthalten:

Beispiel:

Eigener Test

Die beschriebene Funktion wurde unter der angegebenen Softwareversion in einer dokumentierten Testumgebung erfolgreich geprüft.

Das Ergebnis bestätigt nicht automatisch dasselbe Verhalten unter älteren Versionen, anderen Plattformen oder abweichenden Konfigurationen.

Merke

Ein erfolgreicher eigener Test belegt das beobachtete Verhalten der getesteten Umgebung.

Er beweist nicht automatisch eine allgemeine oder offiziell unterstützte Kompatibilität.

Offiziell unterstützt und technisch funktionsfähig unterscheiden

Eine Funktion kann technisch funktionieren, obwohl sie vom Hersteller nicht ausdrücklich als unterstützt dokumentiert ist.

Umgekehrt kann eine Funktion offiziell unterstützt werden, aber aufgrund einer fehlerhaften Konfiguration in einer bestimmten Umgebung nicht funktionieren.

Deshalb müssen folgende Aussagen getrennt werden:

Aussage Bedeutung
Offiziell dokumentiert Die Funktion wird in einer offiziellen Quelle beschrieben.
Offiziell unterstützt Der Hersteller nennt die betreffende Verwendung ausdrücklich als unterstützte Konfiguration.
Technisch getestet Die Funktion wurde in einer bestimmten Umgebung praktisch geprüft.
Von Benutzern berichtet Community-Mitglieder berichten über entsprechende Erfahrungen.
Vermutet Es besteht eine Annahme, aber noch kein ausreichender Beleg.

Typischer Fehler

Aus der Aussage „Es hat bei einem Benutzer funktioniert“ wird die Aussage „Der Hersteller unterstützt diese Konfiguration“.

Versionsabhängige Informationen

Technische und organisatorische Inhalte können sich durch neue Versionen verändern.

Dies betrifft beispielsweise:

Versionsabhängige Angaben werden deshalb nach Möglichkeit mit folgenden Informationen versehen:

Angabe Beispiel
Framework oder Produkt ITIL
behandelte Version Version 5
zusätzlich berücksichtigt ITIL 4
fachlich geprüft am August 2026
Quelle offizielle PeopleCert-Veröffentlichung
mögliche Abweichung ältere Begriffe können weiterhin verwendet werden

Aktueller ITIL-Versionsstand dieses Buches

Stand August 2026 ist ITIL Version 5 die aktuelle Generation des Frameworks.

ITIL 4 ist weiterhin relevant, da:

Dieses Buch verwendet deshalb folgende Regeln:

Versionsabhängig

Eine Organisation kann weiterhin Prozesse, Begriffe und Werkzeuge verwenden, die an ITIL 4 oder einer älteren ITIL-Ausgabe ausgerichtet sind.

Für die tägliche Arbeit ist deshalb neben dem aktuellen Framework-Stand auch die tatsächlich eingeführte Arbeitsweise der Organisation entscheidend.

ITIL Practices in Version 5

ITIL Version 5 verwendet weiterhin 34 Management Practices.

Diese werden in zwei Gruppen eingeordnet:

  1. Product and Service Management Practices
  2. General Management Practices

Die Practices wurden gegenüber ITIL 4 nicht vollständig ersetzt, sondern für die neue Version angepasst und neu eingeordnet.

Wichtig

Die Einordnung einer Practice in ITIL Version 5 darf nicht allein aus älteren ITIL-4-Übersichten übernommen werden.

Bei einer versionsabhängigen Aussage muss die aktuelle offizielle Quelle geprüft werden.

Framework-Version und betriebliche Umsetzung unterscheiden

Die verwendete ITIL-Version bestimmt nicht automatisch, wie eine Organisation arbeitet.

Organisationen können:

Beispiel:

Eine Organisation kann einen Vorgang intern als „Störungsticket“ bezeichnen, obwohl im ITIL-Kontext der Begriff Incident verwendet wird.

Eine andere Organisation kann für besonders schwerwiegende Incidents einen eigenen Major-Incident-Ablauf einsetzen.

Praxistipp

Prüfe beim Einstieg in eine Organisation:

Umgebungsabhängige Informationen

Eine technische Anleitung kann fachlich korrekt sein und trotzdem nicht zur eigenen Umgebung passen.

Mögliche Unterschiede sind:

Beispiel:

Umgebungsabhängig

Der Neustart eines einzelnen Dienstes kann in einer Testumgebung unkritisch sein.

In einem Cluster, einer Hochverfügbarkeitsumgebung oder einem Produktivsystem kann derselbe Schritt zusätzliche Auswirkungen verursachen.

Vor technischen Eingriffen muss deshalb geprüft werden:

Sicherheitsrelevante Inhalte

Sicherheitsrelevante Hinweise werden besonders gekennzeichnet.

Sie betreffen beispielsweise:

Sicherheitsrelevant

Eine technisch mögliche Handlung ist nicht automatisch zulässig oder sicher.

Vor der Durchführung müssen Berechtigung, Auswirkungen, Datenschutz, betriebliche Vorgaben und Wiederherstellungsmöglichkeiten geprüft werden.

Sicherheitsrelevante Anleitungen sollen nach Möglichkeit Informationen enthalten zu:

Bewertung von Quellen

Quellen werden nicht ausschließlich nach ihrer Bekanntheit bewertet.

Entscheidend ist, ob eine Quelle:

Als Orientierung gilt:

Rang Quellen- oder Vorgabenart
1 geltendes Recht, verbindliche Verträge und betriebliche Vorgaben
2 offizielle Normen, Standards und behördliche Anforderungen
3 offizielle ITIL- und PeopleCert-Veröffentlichungen
4 offizielle Hersteller- oder Projektdokumentation
5 dokumentierte Hersteller-Supportaussage
6 anerkannte Fachliteratur
7 dokumentierte und nachvollziehbare Best Practice
8 reproduzierbarer eigener Test
9 nachvollziehbarer Community-Bericht
10 unbestätigte Einzelmeinung oder Vermutung

Diese Reihenfolge ist keine starre Hierarchie für jeden Einzelfall.

Die geeignete Quelle hängt von der jeweiligen Aussage ab.

Beispiele:

Aktualität einer Quelle prüfen

Das Veröffentlichungs- oder Änderungsdatum einer Quelle ist wichtig, aber nicht allein entscheidend.

Eine neue Webseite kann ältere Informationen enthalten.

Eine ältere Quelle kann weiterhin gültige Grundlagen beschreiben.

Geprüft werden sollte:

Merke

Neu veröffentlicht bedeutet nicht automatisch fachlich aktueller.

Alt bedeutet nicht automatisch ungültig.

Wenn Quellen einander widersprechen

Widersprechen sich mehrere Quellen, wird nicht automatisch die zuerst gefundene Aussage übernommen.

Stattdessen wird geprüft:

  1. Welche Quelle ist primär oder offiziell?
  2. Auf welche Version bezieht sich die jeweilige Aussage?
  3. Wann wurde die Quelle veröffentlicht oder aktualisiert?
  4. Behandeln die Quellen wirklich dieselbe Funktion und Umgebung?
  5. Wurde eine ältere Empfehlung später ersetzt?
  6. Ist nur eine bestimmte Konfiguration betroffen?
  7. Kann die Abweichung reproduziert werden?
  8. Gibt es eine offizielle Stellungnahme?

Kann der Widerspruch nicht eindeutig geklärt werden, wird er sichtbar gekennzeichnet.

Noch zu prüfen

Die verfügbaren Quellen beschreiben unterschiedliche Ergebnisse.

Die Abweichung kann mit Version, Plattform oder Konfiguration zusammenhängen. Vor einer produktiven Anwendung ist eine zusätzliche Prüfung erforderlich.

Mindestangaben für Quellen

Eine Quelle sollte so angegeben werden, dass sie eindeutig wiedergefunden und bewertet werden kann.

Geeignete Angaben sind:

Beispiel:

Herausgeber: PeopleCert
Dokument: ITIL Foundation – Version 5
Behandelter Stand: ITIL Version 5
Fachlich geprüft: August 2026

Bei technischer Dokumentation zusätzlich:

Hersteller: Beispielhersteller
Produkt: Beispielsoftware
Version: 5.2
Dokument: Administrator Guide
Abschnitt: Backup and Restore
Fachlich geprüft: August 2026

Empfohlener Quellenblock am Seitenende

Je nach Inhalt kann am Ende einer Seite folgender Aufbau verwendet werden:

Quellen und Versionsstand

Offizielle Grundlagen

Ergänzende Quellen

Eigene Prüfung

Fachlicher Stand: …

Nicht benötigte Bereiche werden weggelassen.

Leere Felder oder nicht überprüfte Platzhalter dürfen nicht veröffentlicht werden.

Quellenlinks sollen möglichst:

Bei umfangreichen Dokumenten sollte zusätzlich der relevante Abschnitt angegeben werden.

Typischer Fehler

Als Quelle wird lediglich die Startseite eines Herstellers angegeben, obwohl die konkrete Aussage dort nicht auffindbar ist.

Umgang mit nicht mehr erreichbaren Quellen

Eine nicht mehr erreichbare Quelle macht eine Aussage nicht automatisch falsch.

Die Aussage muss jedoch erneut geprüft werden.

Mögliche Maßnahmen:

Ist keine ausreichende Quelle mehr verfügbar, wird dies kenntlich gemacht.

Noch zu prüfen

Die bisher verwendete Quelle ist nicht mehr erreichbar. Die Aussage muss anhand einer aktuellen Primärquelle erneut bewertet werden.

Änderungen und Korrekturen

Fehler, unklare Formulierungen und veraltete Informationen können trotz sorgfältiger Prüfung auftreten.

Werden sie erkannt, sollen sie nachvollziehbar korrigiert werden.

Bei wichtigen Änderungen können folgende Angaben ergänzt werden:

Datum Änderung Grund
01.08.2026 Seite erstmals erstellt Aufbau des Nachschlagewerks
späteres Datum Begriff an neue ITIL-Version angepasst offizielle Framework-Aktualisierung
späteres Datum technische Anleitung korrigiert geänderte Herstellerdokumentation
späteres Datum Praxisbeispiel präzisiert missverständliche Formulierung

Nicht jede kleine Rechtschreibkorrektur benötigt einen eigenen Eintrag.

Dokumentiert werden sollten vor allem Änderungen, die:

Grundsatz

Eine fachlich begründete Korrektur erhöht die Qualität des Buches.

Fehler sollen nachvollziehbar verbessert und nicht verborgen werden.

Kennzeichnung offener Inhalte

Noch nicht ausreichend geprüfte Inhalte werden nicht als gesicherte Aussagen dargestellt.

Beispiele:

Noch zu prüfen

Für diesen Punkt fehlt derzeit eine ausreichend eindeutige offizielle Quelle.

Versionsabhängig

Die beschriebene Funktion wurde bisher nur unter der angegebenen Version geprüft.

Community-Hinweis

Die beschriebene Lösung wird von mehreren Benutzern berichtet, ist jedoch nicht offiziell bestätigt.

Dadurch bleibt erkennbar, welche Aussagen ausreichend belegt sind und wo noch Unsicherheit besteht.

Keine Vermutung als Tatsache darstellen

Kann eine Aussage nicht ausreichend belegt werden, muss sie als Annahme oder offene Frage formuliert werden.

Ungeeignet:

Die Funktion wurde wahrscheinlich aus Sicherheitsgründen entfernt.

Geeignet:

Die Funktion ist in der aktuellen Dokumentation nicht mehr beschrieben.

Ob sie aus Sicherheitsgründen entfernt wurde, konnte anhand der verfügbaren offiziellen Quellen nicht bestätigt werden.

Merke

Eine plausible Erklärung ist noch kein belegter Sachverhalt.

Rechtlicher und markenbezogener Hinweis

Dieses Buch ist eine unabhängige Wissenssammlung.

Es ist:

Offizielle Begriffe und Konzepte werden in eigenen Worten erklärt und durch selbst erstellte Beispiele, Checklisten und Praxisempfehlungen ergänzt.

ITIL® ist eine eingetragene Marke der PeopleCert-Gruppe.

Die Nennung dient der sachlichen Beschreibung des behandelten Frameworks.

Dieses Buch ist nicht mit PeopleCert verbunden und wird nicht von PeopleCert geprüft, unterstützt oder herausgegeben.

Hinweis

Die Verwendung geschützter Logos, umfangreicher Originaltexte, offizieller Grafiken oder anderer urheberrechtlich geschützter Materialien kann zusätzlichen Bedingungen unterliegen.

Dieses Buch verwendet deshalb bevorzugt eigene Formulierungen, Tabellen, Beispiele und Darstellungen.

Checkliste für die fachliche Prüfung einer Seite

Schnellübersicht zur Quellenbewertung

Frage Bedeutung
Wer ist für die Aussage zuständig? passende Quelle bestimmen
Welche Version wird behandelt? Übertragbarkeit prüfen
Ist die Aussage direkt belegt? Fehlinterpretationen vermeiden
Wie aktuell ist der Inhalt? mögliche Änderungen erkennen
Gilt die Aussage für meine Umgebung? Fehlanwendung vermeiden
Ist die Funktion offiziell unterstützt? Supportstatus klären
Wurde die Aussage praktisch getestet? beobachtetes Verhalten nachvollziehen
Gibt es Risiken oder Einschränkungen? sichere Anwendung ermöglichen
Widersprechen sich Quellen? zusätzliche Prüfung durchführen

Quellen- und Verlässlichkeitsmodell

Verbindliche Vorgabe
↓
geeignete offizielle Primärquelle
↓
Hersteller- oder Projektdokumentation
↓
anerkannte Fachquelle oder Best Practice
↓
reproduzierbarer eigener Test
↓
nachvollziehbarer Community-Bericht
↓
unbestätigte Vermutung

Dieses Modell ist eine Orientierung und keine für jeden Fall starre Rangfolge.

Die benötigte Quellenart muss immer zur konkreten Aussage passen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die Regeln zur Quellenbewertung, Dokumentation eigener Tests, Kennzeichnung von Community-Inhalten und Pflege dieses Buches sind redaktionelle Qualitätsregeln dieses unabhängigen Nachschlagewerks.

Sie sind keine vorgeschriebenen ITIL-Prozesse.

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

0. ITIL - Über dieses Buch

0.4 Aktualisierungen, Versionspflege und Korrekturen

Kurz erklärt

Dieses Buch wird als langfristiges Lern-, Arbeits- und Nachschlagewerk aufgebaut.

Inhalte werden deshalb nicht nur einmal erstellt, sondern regelmäßig geprüft, aktualisiert und bei Bedarf korrigiert.

Dabei soll nachvollziehbar bleiben:

Warum eine kontinuierliche Pflege notwendig ist

IT-Wissen verändert sich.

Neue Versionen können:

Auch digitales Produkt- und Service-Management entwickelt sich weiter.

Zusätzlich können sich betriebliche Anforderungen verändern, beispielsweise durch:

Ein dauerhaft hilfreiches Nachschlagewerk muss solche Veränderungen berücksichtigen.

Grundsatz

Eine Wissensseite ist nicht endgültig abgeschlossen.

Sie beschreibt den fachlich geprüften Stand zu einem bestimmten Zeitpunkt.

Erstellung, Bearbeitung, Prüfung und Test unterscheiden

Die folgenden Angaben beschreiben unterschiedliche Zustände einer Seite.

Angabe Bedeutung
Erstellt am Datum, an dem die Seite erstmals angelegt wurde
Zuletzt bearbeitet Datum der letzten inhaltlichen oder redaktionellen Änderung
Fachlich geprüft am Datum der letzten vollständigen fachlichen Kontrolle
Technisch getestet am Datum eines dokumentierten praktischen Tests
Behandelte Version Version des Frameworks, Produkts oder Systems
Nächste Prüfung empfohlen Zeitpunkt oder Anlass für eine erneute Kontrolle
Bekannte Einschränkungen Bedingungen, unter denen eine Aussage möglicherweise nicht gilt
Offene Punkte noch nicht abschließend geklärte Fragen

Eine reine Textkorrektur ist nicht automatisch eine vollständige fachliche Prüfung.

Beispiel

Am 10. August wurde ein Rechtschreibfehler behoben.

Die letzte vollständige fachliche Prüfung kann trotzdem weiterhin vom 1. August stammen.

Ebenso ist eine fachlich geprüfte Anleitung nicht automatisch technisch getestet.

Eine technische Durchführung kann außerdem nur das Verhalten der tatsächlich verwendeten Testumgebung bestätigen.

Fachlicher Stand einer Seite

Am Ende einer Fachseite wird nach Möglichkeit ein fachlicher Stand angegeben.

Beispiel:

Fachlicher Stand: August 2026
Behandelte Hauptversion: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4

Bei technischen Seiten können weitere Angaben notwendig sein.

Beispiel:

Getestetes Betriebssystem: Ubuntu Server 24.04 LTS
Getestete Softwareversion: Beispielsoftware 5.2
Bereitstellungsart: Docker
Architektur: ARM64
Technisch getestet am: 01.08.2026

Die Angaben sollen dem Leser helfen einzuschätzen:

Merke

Das Bearbeitungsdatum einer Seite sagt allein noch nichts über ihre fachliche Aktualität aus.

Welche Inhalte besonders häufig geprüft werden müssen

Nicht jede Information verändert sich gleich schnell.

Informationsart Typischer Prüfungsanlass
grundlegende ITIL-Konzepte neue offizielle Framework-Veröffentlichung
offizielle Begriffe und Modelle Versionswechsel oder geänderte Definition
Practice-Beschreibungen neue oder überarbeitete offizielle Practice Guidance
technische Menüpfade neue Software- oder Firmwareversion
Befehle und Optionen Versions-, Betriebssystem- oder Plattformwechsel
Herstellerempfehlungen geänderte offizielle Dokumentation
Sicherheitsmaßnahmen neue Schwachstelle, Warnung oder Empfehlung
gesetzliche Anforderungen Änderung der Rechtslage
vertragliche Anforderungen neuer oder geänderter Vertrag
Community-Lösungen vor jeder produktiven Wiederverwendung
eigene Testergebnisse neue Version oder abweichende Umgebung
allgemeine technische Grundlagen fachlicher Anlass oder erkannter Fehler

Grundsatz

Je stärker eine Aussage von einer bestimmten Version, einem Hersteller oder einer aktuellen Sicherheitslage abhängt, desto häufiger muss sie geprüft werden.

Anlässe für eine Aktualisierung

Eine Seite sollte überprüft werden, wenn mindestens einer der folgenden Fälle eintritt:

Eine vollständige Überarbeitung ist nicht bei jeder kleinen Änderung notwendig.

Entscheidend ist, ob die Änderung:

beeinflusst.

Arten von Änderungen

Änderungen werden nach ihrer Bedeutung unterschieden.

Änderungsart Beispiel Änderungsvermerk
Redaktionelle Änderung Rechtschreibung, Formatierung oder bessere Lesbarkeit normalerweise nicht erforderlich
Kleine fachliche Präzisierung missverständliche Formulierung genauer erklärt kurzer Hinweis sinnvoll
Fachliche Korrektur falsche Definition oder Zuordnung berichtigt erforderlich
Technische Aktualisierung neuer Befehl, Menüpfad oder Versionshinweis erforderlich
Sicherheitsrelevante Korrektur riskante Empfehlung entfernt oder abgesichert deutlich dokumentieren
Strukturelle Überarbeitung Seite aufgeteilt, zusammengeführt oder neu eingeordnet Querverweise aktualisieren
Framework-Aktualisierung neue ITIL-Version berücksichtigt Versionshinweis erforderlich
Archivierung Inhalt gilt nur noch für ältere Systeme deutlich kennzeichnen

Redaktionelle Änderungen

Redaktionelle Änderungen verändern nicht die fachliche Bedeutung.

Dazu gehören beispielsweise:

Solche Änderungen benötigen normalerweise keinen ausführlichen Änderungsvermerk.

Das Datum der letzten Bearbeitung kann sich dennoch ändern.

Fachliche Präzisierungen

Eine fachliche Präzisierung ist notwendig, wenn eine Aussage grundsätzlich richtig, aber zu allgemein oder missverständlich formuliert ist.

Beispiel:

Unpräzise:

Die Priorität eines Incidents ergibt sich aus Auswirkung und Dringlichkeit.

Präziser:

Viele Organisationen verwenden Auswirkung und Dringlichkeit als Kriterien für die Priorisierung von Incidents. Die konkrete Bewertungsmethode und Prioritätsmatrix werden von der jeweiligen Organisation festgelegt.

Die Präzisierung verhindert den falschen Eindruck, dass jede Organisation zwingend dieselbe Berechnung oder Matrix verwenden müsse.

Fachliche Korrekturen

Wird eine fachlich falsche Aussage erkannt, wird nicht nur der einzelne Satz ersetzt.

Zusätzlich muss geprüft werden:

Wichtig

Bei sicherheitsrelevanten oder potenziell schädlichen Fehlern hat die Korrektur Vorrang vor redaktionellen Verbesserungen.

Wesentliche Fehler nicht stillschweigend verbergen

Kleine sprachliche Fehler können ohne gesonderten Hinweis korrigiert werden.

Wesentliche fachliche Änderungen sollen nachvollziehbar bleiben.

Ein Änderungsvermerk ist insbesondere sinnvoll, wenn:

Beispiel:

Änderung vom 12.08.2026

Die bisherige Aussage zur Priorisierung wurde präzisiert.

Prioritäten werden nicht allein anhand der technischen Schwere eines Fehlers bestimmt. Die jeweilige Organisation legt fest, welche Kriterien verwendet und wie diese bewertet werden.

Grundsatz

Eine nachvollziehbare Korrektur erhöht die Qualität und Glaubwürdigkeit eines Nachschlagewerks.

Änderungsprotokoll

Bei umfangreichen, häufig verwendeten oder besonders wichtigen Seiten kann ein kompaktes Änderungsprotokoll geführt werden.

Datum Art Änderung Grund
01.08.2026 Ersterstellung Seite angelegt Aufbau des Nachschlagewerks
12.08.2026 Präzisierung Begriff genauer abgegrenzt missverständliche Formulierung
20.09.2026 Aktualisierung neue Framework-Version berücksichtigt offizielle Veröffentlichung
05.10.2026 Korrektur Handlungsempfehlung ersetzt Abgleich mit einer Primärquelle

Nicht jede Rechtschreib- oder Formatierungsänderung benötigt einen Eintrag.

Dokumentiert werden vor allem Änderungen, die:

Empfohlener Änderungsvermerk

Für wichtige Änderungen kann folgende Struktur verwendet werden:

Änderungsvermerk

Datum:
Art der Änderung:
Betroffener Abschnitt:
Bisherige Aussage:
Korrigierte Aussage:
Grund der Änderung:
Verwendete Quelle:
Auswirkung auf andere Seiten:

Nicht benötigte Felder können weggelassen werden.

Umgang mit unterschiedlichen ITIL-Versionen

Bei einer neuen ITIL-Version wird nicht automatisch der gesamte ältere Inhalt gelöscht.

Stattdessen wird geprüft:

  1. Ist die bisherige Aussage weiterhin fachlich gültig?
  2. Wurde nur die Bezeichnung geändert?
  3. Hat sich die Definition verändert?
  4. Wurde ein Modell ersetzt, erweitert oder neu eingeordnet?
  5. Wird die ältere Version weiterhin in Organisationen verwendet?
  6. Ist die Unterscheidung für Praxis oder Prüfung relevant?
  7. Muss eine Vergleichstabelle ergänzt werden?
  8. Sind Querverweise oder Seitentitel betroffen?

Beispiel:

Versionshinweis

In ITIL Version 5 heißt die Practice Change Management.

In ITIL 4 wurde sie Change Enablement genannt.

Älteres Wissen kann erhalten bleiben, wenn es weiterhin relevant ist und eindeutig einer Version zugeordnet wird.

Typischer Fehler

Ein gleich oder ähnlich klingender Begriff wird ohne Prüfung als vollständig identisch mit dem Begriff einer anderen Version behandelt.

Umgang mit technischen Versionen

Technische Anleitungen werden nach Möglichkeit auf eine konkrete Umgebung bezogen.

Beispiel:

Getestete Umgebung

Bei einer neuen Version ist unter anderem zu prüfen:

Eine Anleitung ist nicht allein deshalb aktuell, weil die Seite kürzlich bearbeitet wurde.

Fachlich geprüft und technisch getestet

Diese beiden Angaben dürfen nicht gleichgesetzt werden.

Status Aussage
Fachlich geprüft Die Aussagen wurden mit geeigneten Quellen und Fachwissen kontrolliert.
Technisch getestet Die beschriebene Durchführung wurde in einer dokumentierten Umgebung praktisch geprüft.

Eine Anleitung kann fachlich korrekt sein, ohne in der eigenen Umgebung getestet worden zu sein.

Ein erfolgreicher Test kann wiederum nur das Verhalten der getesteten Umgebung bestätigen.

Er beweist nicht automatisch:

Merke

Ein Test beantwortet die Frage: „Was ist in dieser Umgebung passiert?“

Eine offizielle Herstellerangabe beantwortet die Frage: „Was wird offiziell beschrieben oder unterstützt?“

Umgebungsabhängige Inhalte

Eine Anleitung kann fachlich richtig sein und trotzdem nicht zur eigenen Umgebung passen.

Mögliche Unterschiede bestehen bei:

Vor der Übernahme einer technischen Anleitung muss deshalb geprüft werden:

Veraltete Inhalte

Veraltete Inhalte werden nicht immer sofort gelöscht.

Sie können weiterhin hilfreich sein, wenn:

Solche Inhalte müssen eindeutig gekennzeichnet werden.

Veraltet

Die folgende Vorgehensweise bezieht sich auf eine ältere Produktversion.

Sie darf nicht ungeprüft auf aktuelle Systeme übertragen werden.

Situation Maßnahme
Inhalt ist weiterhin nützlich ältere Version deutlich angeben
Inhalt ist nur historisch relevant archivieren
Inhalt ist fachlich falsch korrigieren oder entfernen
Inhalt ist sicherheitsgefährdend sofort entfernen und Korrekturhinweis ergänzen
aktuelle Alternative vorhanden direkt auf die neue Vorgehensweise verweisen
mehrere Versionen werden verwendet Inhalte eindeutig voneinander trennen

Archivieren statt unkontrolliert löschen

Eine ältere Seite kann weiterhin Informationen enthalten, die für folgende Aufgaben wichtig sind:

Vor dem Löschen sollte deshalb geprüft werden:

Praxistipp

Veraltete Inhalte dürfen nicht unauffällig zwischen aktuellen Anleitungen stehen.

Eine eindeutige Archiv- oder Versionskennzeichnung verhindert Fehlanwendungen.

Offene und noch nicht abschließend geprüfte Punkte

Nicht jeder Sachverhalt kann sofort vollständig geklärt werden.

Offene Punkte dürfen dokumentiert werden, müssen aber eindeutig erkennbar sein.

Noch zu prüfen

Für diesen Sonderfall liegt derzeit keine ausreichend eindeutige offizielle Quelle vor.

Vor einer produktiven Anwendung ist eine zusätzliche Prüfung erforderlich.

Ein offener Punkt sollte möglichst enthalten:

Ungeeignet ist eine unklare Notiz wie:

Später noch einmal prüfen.

Besser ist:

Zu prüfen ist, ob die Funktion ab Version 5.2 auch auf ARM64 offiziell unterstützt wird. Bisher liegt nur ein Community-Bericht vor.

Prüfstatus einer Seite

Für umfangreiche oder kritische Inhalte können folgende Statusangaben verwendet werden:

Status Bedeutung
Entwurf Inhalt befindet sich noch im Aufbau
In Prüfung fachliche Kontrolle ist noch nicht abgeschlossen
Fachlich geprüft Inhalt wurde gegen geeignete Quellen geprüft
Technisch getestet praktische Durchführung wurde dokumentiert getestet
Aktualisierung erforderlich Inhalt könnte nicht mehr aktuell sein
Veraltet Inhalt bezieht sich ausdrücklich auf einen älteren Stand
Archiviert Inhalt wird hauptsächlich aus historischen Gründen aufbewahrt

Ein Status darf nur verwendet werden, wenn seine Voraussetzungen erfüllt sind.

Eine automatisch erzeugte oder oberflächlich gelesene Seite gilt nicht als vollständig fachlich geprüft.

Wann eine erneute Prüfung erforderlich ist

Eine Seite sollte erneut geprüft werden, wenn:

Zusätzlich kann eine anlassbezogene Prüfung sinnvoll sein:

Seitenart Geeigneter Prüfungsanlass
ITIL-Grundlagen neue offizielle Framework-Version
Practice-Seiten neue oder überarbeitete Practice Guidance
Sicherheitsrelevante Anleitung neue Schwachstelle oder Sicherheitsempfehlung
Softwareanleitung relevante neue Hauptversion
Herstellerabhängige Konfiguration neue Firmware oder geänderte Dokumentation
Community-basierte Lösung vor jeder produktiven Verwendung
Checkliste nach realer Anwendung und festgestellten Lücken
Vorlage bei geänderten betrieblichen Anforderungen

Risikobasierte Priorisierung von Aktualisierungen

Nicht alle veralteten Seiten sind gleich dringend.

Die Aktualisierung sollte zuerst dort erfolgen, wo ein Fehler große Auswirkungen verursachen kann.

Priorität Typische Inhalte
Sehr hoch Sicherheitsmaßnahmen, Wiederherstellung, Berechtigungen und produktive Änderungen
Hoch Incident-Bearbeitung, Eskalation, Backup, Change und Notfallverfahren
Mittel Produktkonfigurationen, technische Anleitungen und Menüpfade
Niedrig allgemeine Beispiele, stilistische Verbesserungen und historische Informationen

Ein veralteter Screenshot besitzt normalerweise eine geringere Priorität als eine fehlerhafte Anleitung zur Wiederherstellung eines Backups.

Grundsatz

Aktualisierungen werden nicht nur nach Alter, sondern vor allem nach Risiko und möglicher Auswirkung priorisiert.

Meldung eines möglichen Fehlers

Eine Fehlermeldung sollte möglichst konkrete Informationen enthalten.

Hilfreich sind:

Beispiel:

Möglicher Fehler

Seite: Change Management
Abschnitt: Standard Change
Problem: Die Formulierung kann so verstanden werden, dass jeder Standard Change vor jeder Durchführung erneut genehmigt werden muss.
Vorgeschlagene Prüfung: Definition und Freigabemodell anhand der aktuellen offiziellen Practice Guidance vergleichen.

Eine Fehlermeldung führt nicht automatisch zu einer Änderung.

Sie löst zunächst eine fachliche Prüfung aus.

Ablauf einer fachlichen Korrektur

Vorgehensweise

  1. möglichen Fehler dokumentieren
  2. betroffene Aussage eingrenzen
  3. bisherige Quelle prüfen
  4. geeignete Primärquellen vergleichen
  5. Version und Umgebung berücksichtigen
  6. Auswirkungen auf andere Inhalte prüfen
  7. Korrektur formulieren
  8. Änderungsvermerk ergänzen
  9. Querverweise, Tabellen und Checklisten aktualisieren
  10. fachlichen Stand anpassen

Ablauf einer Versionsaktualisierung

Vorgehensweise

  1. neue Version und offizielle Änderungen erfassen
  2. betroffene Seiten identifizieren
  3. Begriffe, Definitionen und Modelle vergleichen
  4. technische oder organisatorische Auswirkungen bewerten
  5. weiterhin gültige Inhalte bestimmen
  6. veraltete Inhalte aktualisieren oder archivieren
  7. Praxisbeispiele und Entscheidungshilfen prüfen
  8. Checklisten und Vorlagen anpassen
  9. Quellen und Querverweise aktualisieren
  10. Versions- und Änderungsvermerk ergänzen

Checkliste vor einer Aktualisierung

Checkliste nach einer Aktualisierung

Empfohlener Abschluss einer Fachseite

Je nach Inhalt kann eine Seite mit folgenden Angaben enden:

Quellen und Versionsstand

Behandelte Hauptversion:
Zusätzlich berücksichtigt:
Fachlich geprüft am:
Technisch getestet am:
Bekannte Einschränkungen:
Offene Punkte:
Nächste Prüfung empfohlen:

Nur tatsächlich benötigte und korrekt ausgefüllte Angaben werden übernommen.

Leere Felder sollen nicht veröffentlicht werden.

Lebenszyklus einer Wissensseite

Erstellen
↓
fachlich prüfen
↓
veröffentlichen
↓
anwenden und Rückmeldungen sammeln
↓
erneut prüfen
↓
aktualisieren, korrigieren oder archivieren

Die praktische Nutzung einer Seite kann neue Erkenntnisse liefern.

Diese Erkenntnisse fließen anschließend wieder in die Prüfung und Verbesserung des Inhalts ein.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Diese Seite beschreibt die redaktionelle und fachliche Pflege dieses unabhängigen Nachschlagewerks.

Die dargestellten Prüf-, Änderungs-, Dokumentations- und Archivierungsabläufe sind Regeln dieses Buchprojekts und keine vorgeschriebenen ITIL-Prozesse.

Sie orientieren sich an bewährten Grundsätzen wie:

ITIL Version 5 behandelt Continual Improvement weiterhin als grundlegenden Bestandteil des Frameworks und verwendet ein weiterentwickeltes Continual Improvement Model.

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

1. Grundlagen des professionellen Service Managements

1. Grundlagen des professionellen Service Managements

1.1 Warum professionelles Service Management notwendig ist

Kurz erklärt

Unternehmen und öffentliche Einrichtungen sind in hohem Maß von digitalen Produkten und Services abhängig.

Ein funktionierender Server allein erzeugt jedoch noch keinen verlässlichen Service. Erst das abgestimmte Zusammenspiel von Technik, Menschen, Arbeitsweisen, Informationen und externen Partnern ermöglicht stabile und nutzbare IT-Services.

Professionelles Service Management hilft dabei, dieses Zusammenspiel planbar, nachvollziehbar und kontinuierlich verbesserbar zu gestalten.

Vom technischen System zum nutzbaren Service

Fachinformatiker für Systemintegration arbeiten täglich mit technischen Komponenten wie:

Für Benutzer und Organisationen ist jedoch normalerweise nicht die einzelne technische Komponente entscheidend.

Sie benötigen einen funktionierenden Service.

Technische Komponenten Unterstützter Service
Domain Controller, DNS, Netzwerk und Benutzerkonto Anmeldung am Arbeitsplatz
Mailplattform, Identitätsdienst, DNS und Internetzugang E-Mail-Kommunikation
Fileserver, Berechtigungen, Netzwerk und Backup zentrale Dateiablage
VPN-Gateway, Firewall, MFA und Benutzerkonto sicherer Fernzugriff
Webserver, Datenbank, Zertifikat und DNS Unternehmensanwendung
Druckserver, Treiber, Netzwerk und Drucker zentraler Druckservice

Ein Service kann aus vielen technischen und organisatorischen Bestandteilen bestehen.

Fällt eine wichtige Abhängigkeit aus, kann der gesamte Service für den Benutzer nicht mehr nutzbar sein.

Merke

Benutzer nehmen normalerweise keinen einzelnen Server oder Netzwerkdienst wahr.

Sie nehmen wahr, ob sie ihre Arbeit ausführen können.

Warum technische Kompetenz allein nicht ausreicht

Technisches Fachwissen ist unverzichtbar.

Es hilft unter anderem dabei:

Im laufenden IT-Betrieb müssen zusätzlich organisatorische und servicebezogene Fragen beantwortet werden:

Diese Fragen können nicht allein durch einen technischen Befehl oder ein Administrationswerkzeug beantwortet werden.

Dafür wird eine abgestimmte Arbeitsweise benötigt.

Was professionelles Service Management leistet

Professionelles Service Management schafft einen gemeinsamen Rahmen für die Planung, Bereitstellung, Unterstützung, Steuerung und Verbesserung von Services.

Es unterstützt insbesondere dabei:

ITIL stellt hierfür ein anpassbares Best-Practice-Framework bereit.

ITIL Version 5 betrachtet digitales Produkt- und Service-Management stärker als zusammenhängende Aufgabe. Dadurch sollen Produkt-, Entwicklungs-, Betriebs-, Support- und Serviceteams besser zusammenarbeiten und Entscheidungen stärker an Outcomes und Wert ausrichten.

ITIL-Grundlage

ITIL ist kein starres Regelwerk.

Die Inhalte müssen an Ziele, Größe, Risiken, Fähigkeiten und Arbeitsweise der jeweiligen Organisation angepasst werden.

Service Management ist mehr als ein Ticketsystem

Ein Ticketsystem kann Service Management unterstützen.

Es kann beispielsweise:

Das Ticketsystem allein sorgt jedoch nicht automatisch für professionelles Service Management.

Zusätzlich muss geklärt sein:

Typischer Fehler

Die Einführung eines Ticketsystems wird mit der Einführung von Service Management gleichgesetzt.

Ein Werkzeug kann eine Arbeitsweise unterstützen, aber keine fehlenden Verantwortlichkeiten, Regeln oder Entscheidungen ersetzen.

Service Management ist keine einzelne Practice

Professionelles Service Management besteht nicht nur aus Incident Management oder Ticketbearbeitung.

Es verbindet verschiedene Management Practices und Arbeitsbereiche, beispielsweise:

Diese Practices können innerhalb eines Vorgangs zusammenwirken.

Beispiel:

  1. Das Monitoring erkennt den Ausfall eines Webdienstes.
  2. Ein Incident wird erfasst.
  3. Betroffene Benutzer werden informiert.
  4. Die technische Analyse stellt eine fehlerhafte Konfiguration fest.
  5. Eine Zwischenlösung stellt den Service wieder her.
  6. Ein Problem Record wird für die weitere Ursachenanalyse angelegt.
  7. Eine dauerhafte Korrektur wird als Change geplant und umgesetzt.
  8. Die Lösung wird im Wissensmanagement dokumentiert.
  9. Monitoring und Arbeitsanweisungen werden verbessert.

Keiner dieser Schritte ersetzt die technische Fehleranalyse.

Die beteiligten Practices helfen jedoch dabei, die technische Arbeit koordiniert, nachvollziehbar und nachhaltig durchzuführen.

Was ohne gemeinsame Arbeitsweise häufig passiert

Fehlt eine abgestimmte Service-Management-Arbeitsweise, können typische Schwierigkeiten entstehen.

Situation Mögliche Folge
Meldungen erfolgen nur telefonisch oder per Zuruf. Vorgänge gehen verloren oder werden nicht nachvollziehbar dokumentiert.
Jeder Mitarbeiter priorisiert nach eigenem Gefühl. Lautstärke oder persönliche Nähe bestimmen die Reihenfolge.
Verantwortlichkeiten sind unklar. Vorgänge werden weitergereicht oder bleiben unbearbeitet.
Änderungen werden nicht dokumentiert. Spätere Störungen lassen sich nur schwer mit früheren Eingriffen verbinden.
Lösungen bleiben im Wissen einzelner Mitarbeiter. Kollegen führen dieselbe Analyse wiederholt durch.
Teams betrachten nur ihre eigene Komponente. Die tatsächliche Serviceauswirkung wird übersehen.
Benutzer erhalten keine Statusinformationen. Unsicherheit und zusätzliche Rückfragen erhöhen den Arbeitsaufwand.
Wiederkehrende Incidents werden nur einzeln behoben. Die zugrunde liegende Ursache bleibt bestehen.
Kennzahlen betrachten nur Ticketmengen. Ergebnisse, Nutzen und Servicequalität bleiben unklar.
Externe Dienstleister werden zu spät eingebunden. Eskalation und Wiederherstellung verzögern sich.

Praxistipp

Wenn mehrere Mitarbeiter denselben Vorgang grundlegend unterschiedlich bearbeiten würden, fehlt möglicherweise eine gemeinsame oder ausreichend dokumentierte Arbeitsweise.

Praxisbeispiel: Der E-Mail-Service ist gestört

Mehrere Benutzer melden, dass sie keine E-Mails senden können.

Eine technische Betrachtung könnte mit folgenden Prüfungen beginnen:

Diese Prüfungen sind notwendig.

Professionelles Service Management ergänzt weitere Fragen.

Servicebezogene Einordnung

Kommunikation

Technische Bearbeitung

Nach der Wiederherstellung

Hinweis

Ein Major Incident ist ein besonders schwerwiegender Incident.

Die Kriterien, Rollen, Kommunikationswege und Eskalationsverfahren werden von der jeweiligen Organisation festgelegt. Major Incident Management wird hier nicht als eigenständige ITIL Practice behandelt.

Merke

Die technische Wiederherstellung ist ein zentraler Teil der Arbeit.

Professionelles Service Management sorgt dafür, dass Auswirkungen, Kommunikation, Verantwortung, Dokumentation und Verbesserung ebenfalls berücksichtigt werden.

Lokale Optimierung kann dem gesamten Service schaden

Ein einzelnes Team kann seine technische Aufgabe korrekt erfüllen und trotzdem den gesamten Service beeinträchtigen.

Beispiel:

Ein Netzwerkadministrator verschärft eine Firewall-Regel.

Die Änderung kann die Sicherheit einer einzelnen Komponente verbessern.

Wurde jedoch nicht geprüft, welche Anwendungen und Services von der bisherigen Verbindung abhängen, können wichtige Geschäftsprozesse ausfallen.

Eine ganzheitliche Betrachtung berücksichtigt deshalb:

Die vier Dimensionen

ITIL verwendet vier Dimensionen, um digitales Produkt- und Service-Management ganzheitlich zu betrachten.

Dimension Typische Inhalte
Organisationen und Menschen Rollen, Fähigkeiten, Kommunikation, Kultur und Verantwortlichkeiten
Informationen und Technologie Daten, Anwendungen, Infrastruktur, Wissen und Werkzeuge
Partner und Lieferanten Hersteller, Provider, Verträge und externe Abhängigkeiten
Wertströme und Prozesse Abläufe, Aktivitäten, Übergaben, Kontrollen und Zusammenarbeit

Keine Dimension sollte dauerhaft isoliert betrachtet werden.

Beispiel:

Eine technisch leistungsfähige Anwendung kann trotzdem scheitern, wenn:

Merke

Ein Serviceproblem ist nicht automatisch ausschließlich ein Technikproblem.

Gemeinsame Sprache statt Missverständnisse

Unterschiedliche Teams verwenden häufig unterschiedliche Begriffe.

Beispiele:

Werden diese Begriffe nicht einheitlich verwendet, können Missverständnisse entstehen.

Ein Benutzer meldet beispielsweise ein „Problem“.

Im allgemeinen Sprachgebrauch ist das verständlich.

Im Service-Management-Kontext muss jedoch zunächst geprüft werden, ob es sich um:

handelt.

Eine gemeinsame Sprache erleichtert:

Wichtig

Benutzer müssen nicht zwingend die offiziellen ITIL-Begriffe kennen.

Die korrekte fachliche Einordnung ist Aufgabe der zuständigen Service- und Supportorganisation.

Verantwortung muss über einzelne Komponenten hinausgehen

In technischen Umgebungen werden Verantwortlichkeiten häufig nach Komponenten verteilt.

Beispiele:

Ein Service kann von allen diesen Bereichen gleichzeitig abhängen.

Folgende Situation ist möglich:

Netzwerk funktioniert.
Server funktioniert.
Datenbank funktioniert.
Anwendung läuft laut Monitoring.
Der Benutzer kann trotzdem nicht arbeiten.

Service Management ergänzt die technische Komponentenverantwortung um eine Ende-zu-Ende-Sicht:

Wert entsteht nicht allein durch Bereitstellung

Ein Service erzeugt nicht automatisch Wert, nur weil er technisch bereitgestellt wurde.

Eine VPN-Lösung kann:

sein.

Wenn Benutzer jedoch:

wird das erwartete Outcome möglicherweise nicht erreicht.

ITIL Version 5 betrachtet Wertschöpfung als Zusammenarbeit zwischen Service Provider, Service Consumer und weiteren Stakeholdern.

Bei der Bewertung können unter anderem berücksichtigt werden:

Merke

Ein technisch verfügbarer Service ist nicht automatisch ein brauchbarer oder wertvoller Service.

Service Management bedeutet nicht maximale Bürokratie

ITIL schreibt Organisationen nicht vor, jeden Ablauf möglichst umfangreich zu dokumentieren.

Eine Arbeitsweise muss zum jeweiligen Kontext passen.

Ein kleines Unternehmen benötigt möglicherweise:

Eine große oder stark regulierte Organisation benötigt möglicherweise:

Grundsatz

So viel Struktur wie nötig, aber nicht mehr Komplexität als sinnvoll.

Eine übermäßig komplizierte Arbeitsweise kann:

Eine zu schwache Arbeitsweise kann dagegen:

Was professionelles Service Management nicht bedeutet

Professionelles Service Management bedeutet nicht:

Es bedeutet vielmehr:

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker für Systemintegration sind häufig an mehreren Stellen eines Service beteiligt.

Zu ihren Aufgaben können gehören:

Service Management hilft dabei, diese technischen Tätigkeiten in einen größeren Zusammenhang einzuordnen.

Technische Tätigkeit Zusätzliche Service-Management-Frage
Dienst neu starten Wurde die Wiederherstellung geprüft und ist eine weitere Ursachenanalyse notwendig?
Firewall-Regel ändern Wer ist betroffen, welches Risiko besteht und wie sieht der Rückfallplan aus?
Benutzerkonto entsperren Handelt es sich um einen Incident oder einen Service Request?
Server patchen Wie werden Test, Freigabe, Wartungsfenster und Kommunikation organisiert?
Monitoring-Alarm bearbeiten Ist das Event relevant und muss ein Incident erfasst werden?
neue Hardware einbauen Müssen Asset- und Konfigurationsinformationen aktualisiert werden?
Fehler dauerhaft beheben Müssen Problem Management und Change Management einbezogen werden?
Lösung dokumentieren Wer benötigt dieses Wissen und wie wird es auffindbar gemacht?
Backup kontrollieren Wurde nur der Sicherungslauf oder auch die Wiederherstellbarkeit geprüft?

Wie ein serviceorientierter Systemintegrator denkt

Ein serviceorientierter Systemintegrator fragt nicht nur:

Welche Komponente ist defekt?

Er fragt zusätzlich:

Diese Denkweise verhindert nicht jede Störung.

Sie hilft jedoch dabei, Störungen kontrollierter, nachvollziehbarer und nachhaltiger zu behandeln.

Erste Orientierung in einer neuen Organisation

Wenn du in einer neuen IT-Abteilung beginnst, solltest du frühzeitig herausfinden:

Praxistipp

Lerne nicht nur die technische Infrastruktur kennen.

Lerne auch, welche Services davon abhängen und wer bei Störungen oder Änderungen beteiligt werden muss.

Anzeichen für unzureichendes Service Management

Folgende Beobachtungen können darauf hinweisen, dass Arbeitsweisen verbessert werden sollten:

Ein einzelnes Anzeichen beweist noch kein grundsätzliches Organisationsproblem.

Wiederholen sich mehrere dieser Muster, sollte die zugrunde liegende Arbeitsweise untersucht werden.

Entscheidungshilfe: Wird mehr Struktur benötigt?

Prüfe folgende Fragen:

Werden mehrere Fragen mit Ja beantwortet, besteht wahrscheinlich Verbesserungsbedarf.

Die Lösung ist jedoch nicht automatisch ein möglichst umfangreicher Prozess.

Zuerst sollte festgestellt werden:

  1. Welches konkrete Problem besteht?
  2. Welche Auswirkungen verursacht es?
  3. Welche bestehende Arbeitsweise funktioniert bereits?
  4. Welche kleinste sinnvolle Verbesserung ist möglich?
  5. Wie lässt sich ihre Wirkung überprüfen?

Checkliste für den Arbeitsalltag

Wenn du eine technische Aufgabe erhältst, prüfe zusätzlich:

Schnellzusammenfassung

Technik

stellt Komponenten und Funktionen bereit.

Service Management

verbindet Technik mit Menschen, Arbeitsweisen, Informationen, Partnern und den Zielen der Organisation.

Professionelle IT-Arbeit

entsteht, wenn technische Kompetenz und serviceorientierte Arbeitsweise zusammenwirken.

Vom technischen Baustein zum geschäftlichen Ergebnis

Technische Komponenten
↓
digitales Produkt
↓
nutzbarer Service
↓
Outcome für Benutzer und Organisation
↓
wahrgenommener Wert

Technische Komponenten bilden die Grundlage.

Der eigentliche Nutzen entsteht jedoch erst, wenn daraus ein funktionierender Service entsteht, der ein benötigtes Outcome unterstützt.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die Aussagen zur gemeinsamen Wertschöpfung, zu den vier Dimensionen, zur Integration von Produkten und Services sowie zur Ausrichtung auf Outcomes, Kosten, Risiken, Erfahrung und Nachhaltigkeit wurden anhand der genannten offiziellen ITIL- und PeopleCert-Quellen geprüft.

Die Praxisbeispiele, Checklisten, Entscheidungshilfen und betrieblichen Hinweise sind zusätzliche, herstellerneutrale Praxisempfehlungen dieses Nachschlagewerks.

Sie stellen keine wörtlichen ITIL-Definitionen und keine vorgeschriebenen ITIL-Prozesse dar.

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

1. Grundlagen des professionellen Service Managements

1.2 Technik, Produkt, Service und Geschäftsergebnis

Kurz erklärt

Technische Komponenten sind die Bausteine einer IT-Lösung.

Ein digitales Produkt bündelt technische und organisatorische Fähigkeiten.

Ein Service macht diese Fähigkeiten für Benutzer oder Kunden nutzbar.

Entscheidend ist am Ende nicht nur, ob einzelne Systeme funktionieren, sondern ob Benutzer und Organisationen mit ihrer Hilfe das gewünschte Ergebnis erreichen.

Warum diese Unterscheidung wichtig ist

Im IT-Arbeitsalltag werden Begriffe wie System, Produkt, Service, Leistung und Ergebnis häufig miteinander vermischt.

Der Begriff „E-Mail-System“ kann beispielsweise Folgendes bezeichnen:

Diese Bedeutungen hängen zusammen, sind aber nicht identisch.

Für professionelles Produkt- und Service-Management muss erkennbar sein:

Merke

Ein technisch funktionierendes System ist eine notwendige Grundlage.

Entscheidend ist jedoch, ob der damit unterstützte Service für die Benutzer zuverlässig nutzbar ist und das erwartete Ergebnis ermöglicht.

Die Betrachtungsebenen

Für die praktische Einordnung unterscheiden wir folgende Ebenen:

Ebene Zentrale Frage Beispiel
Technische Komponente Aus welchen einzelnen Bausteinen besteht die Lösung? Server, Switch, Datenbank, Zertifikat
Technisches System Wie arbeiten mehrere Komponenten zusammen? E-Mail-Plattform
Digitales Produkt Welche gebündelte digitale Fähigkeit wird verwaltet und weiterentwickelt? Kommunikations- und Kollaborationsplattform
Service Wie wird diese Fähigkeit für Benutzer oder Kunden nutzbar gemacht? E-Mail- und Kalender-Service
Output Was wurde technisch erstellt oder bereitgestellt? Benutzerpostfach wurde angelegt
Outcome Welche Wirkung oder welches Ergebnis wurde erreicht? Mitarbeiter kann kommunizieren
Wert Welchen Nutzen nehmen die beteiligten Stakeholder wahr? zuverlässige Zusammenarbeit und Zeitersparnis

Diese Ebenen bilden keine starre lineare Kette.

Ein digitales Produkt kann mehrere Services ermöglichen.

Ein Service kann wiederum mehrere Produkte, Plattformen, Systeme und externe Leistungen verwenden.

Technische Komponenten

Technische Komponenten sind einzelne Bausteine, aus denen Systeme, Produkte und Services aufgebaut werden.

Dazu gehören beispielsweise:

In einem Konfigurationsmanagement können relevante Bestandteile als Configuration Items erfasst werden.

Ob ein Bestandteil als Configuration Item verwaltet wird, hängt davon ab, ob seine Informationen für die Bereitstellung, Steuerung, Unterstützung oder Wiederherstellung eines Service benötigt werden.

Praxisbeispiel

Für einen VPN-Service können unter anderem folgende Komponenten notwendig sein:

Jede einzelne Komponente kann technisch funktionieren.

Trotzdem kann der gesamte VPN-Service unbrauchbar sein, wenn die Komponenten nicht korrekt zusammenarbeiten.

Technisches System

Ein technisches System entsteht durch das koordinierte Zusammenwirken mehrerer Komponenten.

Beispiele:

Technisches System Mögliche Komponenten
Verzeichnisdienst Domain Controller, DNS, Datenbank, Replikation und Zeitquelle
E-Mail-System Mailplattform, Identitätsdienst, DNS, Zertifikate und Spamfilter
Webplattform Webserver, Datenbank, Load Balancer, DNS und Speicher
Virtualisierungsplattform Hosts, Hypervisor, Netzwerk, Storage und Managementsystem
Backup-System Backupserver, Agenten, Speicherziele, Zugangsdaten und Zeitpläne

Ein technisches System wird häufig aus Sicht der Architektur und Administration betrachtet.

Dabei stehen Fragen im Mittelpunkt wie:

Diese Sicht ist für Fachinformatiker für Systemintegration unverzichtbar.

Für die vollständige Bewertung eines Service reicht sie allein jedoch nicht aus.

Was ist ein digitales Produkt?

Ein digitales Produkt bündelt Fähigkeiten, mit denen für Benutzer, Kunden oder die eigene Organisation nutzbare Ergebnisse ermöglicht werden.

Ein digitales Produkt kann unter anderem bestehen aus:

Beispiele für digitale Produkte:

Ein digitales Produkt wird über seinen gesamten Lebenszyklus betrachtet.

Dazu gehören unter anderem:

Wichtig

Ein digitales Produkt ist nicht zwingend nur eine einzelne Anwendung.

Es kann aus vielen technischen und organisatorischen Bestandteilen bestehen.

Produkt und Service gehören zusammen

ITIL Version 5 betrachtet digitale Produkte und Services als eng miteinander verbundene Bestandteile einer digital unterstützten Lösung.

Ein Produkt stellt Fähigkeiten bereit.

Ein Service ermöglicht es Benutzern oder Kunden, diese Fähigkeiten sinnvoll zu verwenden.

Beispiel:

Betrachtung Kommunikationsplattform
Produkt technisch und organisatorisch verwaltete Kommunikations- und Kollaborationsplattform
Services E-Mail, Kalender, Kontakte, Chat, Videokonferenzen und Dateifreigabe

Produkt und Service sind dabei keine voneinander unabhängigen Welten.

Probleme entstehen häufig, wenn Produktentwicklung, Betrieb und Support getrennt arbeiten und wichtige Anforderungen zu spät berücksichtigen.

Mögliche Folgen sind:

Merke

Ein Produkt stellt Fähigkeiten bereit.

Ein Service macht diese Fähigkeiten für bestimmte Stakeholder nutzbar.

Was ist ein Service?

Ein Service unterstützt Benutzer, Kunden oder andere Stakeholder dabei, gewünschte Ergebnisse zu erreichen.

Die Benutzer müssen dabei nicht alle zugrunde liegenden technischen und organisatorischen Einzelheiten selbst verwalten.

Ein Benutzer eines E-Mail-Service muss beispielsweise nicht selbst:

Der Benutzer erwartet stattdessen, dass er:

kann.

Der Service Provider übernimmt oder koordiniert die dafür notwendigen Fähigkeiten, Ressourcen, Arbeitsweisen und Beziehungen.

Interne und externe Services

Ein Service muss nicht an einen extern zahlenden Kunden verkauft werden.

Auch interne IT-Abteilungen erbringen Services.

Service Mögliche Service Consumer
Benutzerverwaltung Mitarbeiter und Fachabteilungen
zentraler Dateiservice interne Teams und Projekte
E-Mail- und Kalender-Service gesamte Organisation
ERP-Service Einkauf, Lager, Vertrieb und Buchhaltung
Entwicklungsplattform Softwareentwicklung
Monitoring-Service Betriebsteams und Service-Verantwortliche
Backup- und Restore-Service Fachabteilungen und Systemverantwortliche
Netzwerkzugang Mitarbeiter, Gäste und technische Systeme

Der Service Provider kann sein:

Ein Produkt kann mehrere Services ermöglichen

Eine zentrale Identitätsplattform kann beispielsweise folgende Services unterstützen:

Ein einzelner Service kann umgekehrt mehrere Produkte benötigen.

Ein digitaler Arbeitsplatzservice kann beispielsweise verwenden:

Praxistipp

Frage bei einer Störung nicht nur:

„Welches System ist ausgefallen?“

Frage zusätzlich:

„Welche Services verwenden dieses System und welche Benutzer sind dadurch betroffen?“

Output und Outcome unterscheiden

Für die Bewertung einer Aufgabe ist die Unterscheidung zwischen Output und Outcome wichtig.

Begriff Praktische Bedeutung
Output etwas wurde erstellt, verändert oder bereitgestellt
Outcome für einen Stakeholder wurde eine Wirkung oder ein nutzbares Ergebnis erreicht

Beispiele:

Output Outcome
VPN-Client wurde installiert. Mitarbeiter kann sicher von außerhalb arbeiten.
Benutzerkonto wurde angelegt. Neuer Mitarbeiter kann seine Arbeit aufnehmen.
Server wurde bereitgestellt. Fachanwendung kann produktiv verwendet werden.
Backup wurde erfolgreich ausgeführt. Daten können nach einem Ausfall wiederhergestellt werden.
Patch wurde installiert. Ein bekanntes Sicherheitsrisiko wurde reduziert.
Access Point wurde montiert. Benutzer erhalten zuverlässigen WLAN-Zugang.
Wissensartikel wurde erstellt. Supportmitarbeiter können eine Störung schneller lösen.

Typischer Fehler

Die technische Durchführung wird mit dem erfolgreichen Ergebnis gleichgesetzt.

Eine installierte Anwendung ist beispielsweise noch kein erfolgreicher Service, wenn der Benutzer sie nicht starten, verwenden oder für seine Aufgabe einsetzen kann.

Technische Fertigstellung ist nicht gleich Serviceerfolg

Ein neues Benutzerkonto wurde technisch angelegt.

Folgende Schritte wurden durchgeführt:

Der neue Mitarbeiter kann trotzdem nicht arbeiten, wenn:

Der technische Output lautet:

Benutzerkonto wurde erstellt.

Das erwartete Outcome lautet:

Der Mitarbeiter besitzt zum vorgesehenen Zeitpunkt einen funktionierenden und angemessenen Zugriff auf die für seine Tätigkeit benötigten Services.

Geschäftsergebnis und Benutzerergebnis

Ein Service kann unterschiedliche Ergebnisse für verschiedene Stakeholder ermöglichen.

Beispiel: Backup- und Restore-Service

Stakeholder Erwartetes Ergebnis
Benutzer versehentlich gelöschte Datei kann wiederhergestellt werden
Fachabteilung geschäftskritische Daten bleiben verfügbar
IT-Betrieb Systeme können kontrolliert wiederhergestellt werden
Informationssicherheit Schutz- und Aufbewahrungsanforderungen werden unterstützt
Unternehmensleitung Betriebsunterbrechungen und Verluste werden begrenzt
Auditor Kontrollen und Wiederherstellbarkeit sind nachvollziehbar dokumentiert

Nicht jeder Stakeholder bewertet denselben Service nach denselben Kriterien.

Deshalb müssen Anforderungen, Erwartungen, Kosten und Risiken aus mehreren Perspektiven betrachtet werden.

Vom technischen Baustein zum Ergebnis

Ein vereinfachtes Beispiel für einen E-Mail-Service:

Ebene Beispiel
Komponenten DNS, Identitätsdienst, Mailplattform, Zertifikate und Netzwerk
System technische Kommunikationsplattform
Produkt digitale Kommunikations- und Kollaborationslösung
Service E-Mail-, Kalender- und Kontaktservice
Output Postfach und Clientzugang wurden bereitgestellt
Outcome Mitarbeiter können zuverlässig kommunizieren
Geschäftsergebnis Zusammenarbeit und Geschäftsprozesse werden unterstützt
Wert zuverlässige Kommunikation bei angemessenen Kosten und Risiken

Diese Darstellung ist keine starre ITIL-Prozesskette.

Sie dient als praktische Orientierung, um technische Arbeit mit den erwarteten Ergebnissen zu verbinden.

Was bedeutet Wert?

Wert entsteht, wenn ein Produkt oder Service für einen Stakeholder einen erkennbaren Nutzen besitzt.

Wert kann sich beispielsweise zeigen durch:

Wert ist nicht für jeden Stakeholder identisch.

Beispiel:

Eine strengere Multi-Faktor-Authentifizierung kann:

Eine gute Lösung berücksichtigt diese unterschiedlichen Perspektiven.

Merke

Wert ist nicht nur eine technische Eigenschaft.

Er wird von Stakeholdern anhand ihrer Ergebnisse, Kosten, Risiken, Erfahrungen und Erwartungen wahrgenommen.

Wert wird gemeinsam ermöglicht

Der Service Provider erzeugt Wert nicht vollständig allein.

Auch Service Consumer und weitere Stakeholder tragen zur erfolgreichen Nutzung bei.

Beispiel: sicherer Fernzugriff

Der Service Provider muss unter anderem:

Der Benutzer muss unter anderem:

Die Fachabteilung oder Führungskraft muss möglicherweise:

Das gewünschte Ergebnis entsteht erst durch das Zusammenwirken der Beteiligten.

Verfügbarkeit allein reicht nicht aus

Ein Service kann technisch erreichbar und trotzdem praktisch unbrauchbar sein.

Beispiele:

Bei der Beurteilung eines Service können deshalb unter anderem folgende Eigenschaften wichtig sein:

Praxisbeispiel: zentraler Dateiservice

Ein Unternehmen betreibt einen zentralen Dateiservice.

Technische Komponenten

Digitales Produkt

Eine verwaltete Plattform zur Speicherung und gemeinsamen Nutzung von Unternehmensdateien.

Service

Benutzer können entsprechend ihrer Berechtigungen:

Erwartete Outcomes

Möglicher Wert

Praxisbeispiel: Störung des Dateiservice

Ein Benutzer meldet:

„Das Netzlaufwerk ist verschwunden.“

Eine rein komponentenorientierte Analyse könnte sofort mit dem Fileserver beginnen.

Die serviceorientierte Analyse prüft zusätzlich:

Dadurch wird verhindert, dass eine einzelne technische Vermutung zu früh als Ursache angenommen wird.

Bedeutung für das Monitoring

Monitoring sollte nicht ausschließlich einzelne Komponenten überwachen.

Ein Server kann erreichbar sein, obwohl der Service für Benutzer nicht funktioniert.

Deshalb können unterschiedliche Überwachungsebenen notwendig sein:

Ebene Beispiel
Komponentenüberwachung CPU, Arbeitsspeicher, Datenträger und Netzwerkinterface
Systemüberwachung Datenbankverbindung und Dienststatus
Anwendungsüberwachung Anmeldung und wichtige Transaktionen
Serviceüberwachung vollständiger Benutzerweg funktioniert
Ergebnisorientierte Messung Benutzer kann die vorgesehene Aufgabe erfolgreich ausführen

Praxistipp

Überwache bei kritischen Services möglichst auch eine Funktion, die der tatsächlichen Benutzernutzung nahekommt.

Ein erfolgreicher Ping bestätigt nur die Erreichbarkeit eines Hosts, nicht die Nutzbarkeit des gesamten Service.

Bedeutung für Änderungen

Vor einer technischen Änderung muss nicht nur die betroffene Komponente betrachtet werden.

Zusätzlich sollte geprüft werden:

Beispiel:

Eine Änderung an DNS kann Auswirkungen besitzen auf:

Die technische Änderung kann klein erscheinen, während die mögliche Serviceauswirkung sehr groß ist.

Bedeutung für die Priorisierung

Die Priorität einer Störung sollte nicht nur anhand der ausgefallenen Komponente bewertet werden.

Störung Technische Betrachtung Servicebezogene Betrachtung
einzelner Testserver ausgefallen vollständiger Serverausfall möglicherweise geringe geschäftliche Auswirkung
zentraler DNS-Dienst gestört einzelner technischer Dienst möglicherweise viele Services betroffen
einzelner Arbeitsplatzdrucker defekt einzelnes Gerät ausgefallen Auswirkung hängt von Alternativen und Bedarf ab
zentrale Datenbank reagiert langsam System ist noch erreichbar möglicherweise erhebliche Beeinträchtigung eines Geschäftsprozesses

Merke

Die technische Größe eines Fehlers bestimmt nicht automatisch seine geschäftliche Priorität.

Bedeutung für die Dokumentation

Eine gute Dokumentation sollte nicht nur Komponenten beschreiben.

Sie sollte nach Möglichkeit auch folgende Fragen beantworten:

Dadurch wird aus einer reinen Inventarliste eine nutzbare Wissensgrundlage für Betrieb, Support und Wiederherstellung.

Typische Denkfehler

Denkfehler 1: Der Server ist der Service

Ein Server ist normalerweise nur eine Komponente oder Plattform.

Der Service umfasst zusätzlich beispielsweise:

Denkfehler 2: Wenn das Monitoring grün ist, funktioniert der Service

Ein grüner Hoststatus bestätigt nicht automatisch:

Denkfehler 3: Installation bedeutet Abschluss

Eine Softwareinstallation ist zunächst ein Output.

Der gewünschte Zustand ist erst erreicht, wenn:

Denkfehler 4: Produkt und Service sind dasselbe

Produkte und Services sind eng miteinander verbunden, besitzen aber unterschiedliche Betrachtungsschwerpunkte.

Das Produkt bündelt und entwickelt Fähigkeiten.

Der Service macht diese Fähigkeiten für bestimmte Stakeholder nutzbar.

Denkfehler 5: Wert bedeutet nur finanziellen Gewinn

Wert kann auch entstehen durch:

Wie ein Systemintegrator die Zusammenhänge ermittelt

Vorgehensweise

  1. technische Komponenten erfassen
  2. Verbindungen und Abhängigkeiten bestimmen
  3. übergeordnetes System oder Produkt identifizieren
  4. unterstützte Services ermitteln
  5. Benutzer und weitere Stakeholder bestimmen
  6. erwartete Outputs und Outcomes erfassen
  7. kritische Geschäftsprozesse zuordnen
  8. Verantwortlichkeiten klären
  9. Monitoring und Wiederherstellung prüfen
  10. Informationen nachvollziehbar dokumentieren

Fragen für eine neue Umgebung

Wenn du einen neuen Service kennenlernst, solltest du mindestens folgende Fragen stellen:

Checkliste für technische Aufgaben

Bevor du eine technische Maßnahme durchführst:

Schnellzusammenfassung

Begriff Kurzbeschreibung
Komponente einzelner technischer oder organisatorischer Baustein
System zusammenwirkende Gruppe von Komponenten
Digitales Produkt gebündelte digitale Fähigkeit, die über ihren Lebenszyklus verwaltet wird
Service nutzbarer Zugang zu Fähigkeiten, der gewünschte Ergebnisse unterstützt
Output erzeugtes Arbeitsergebnis oder bereitgestellter Bestandteil
Outcome erreichte Wirkung oder Veränderung für einen Stakeholder
Geschäftsergebnis Outcome, das ein Ziel oder einen Prozess der Organisation unterstützt
Wert wahrgenommener Nutzen unter Berücksichtigung von Ergebnissen, Kosten, Risiken und Erfahrung

Grafik vorgesehen

Zusammenhang zwischen Technik, Produkt, Service und Ergebnis

Technische Komponenten
↓
Systeme und Plattformen
↓
digitales Produkt und unterstützende Fähigkeiten
↓
nutzbare Services
↓
Ergebnisse für Benutzer und Organisation
↓
wahrgenommener Wert

Die Grafik sollte zusätzlich verdeutlichen, dass Rückmeldungen aus Nutzung, Betrieb und Support wieder in die Weiterentwicklung des Produkts und der Services einfließen.

Eine spätere interaktive Version kann einen beispielhaften Service auswählen lassen, etwa:

Anschließend werden die dazugehörigen:

angezeigt.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die Aussagen zur integrierten Betrachtung digitaler Produkte und Services, zum gemeinsamen Produkt- und Service-Lebenszyklus sowie zur Ausrichtung auf Outcomes und Wert wurden anhand der genannten offiziellen ITIL- und PeopleCert-Veröffentlichungen geprüft.

Die Beispiele, Checklisten, Betrachtungsebenen und technischen Zuordnungen sind zusätzliche herstellerneutrale Praxisempfehlungen dieses Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen dar.

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

1. Grundlagen des professionellen Service Managements

1.3 Wert, Nutzen, Kosten und Risiken

Kurz erklärt

Ein IT-Service ist nicht bereits deshalb wertvoll, weil er technisch funktioniert. Wert entsteht erst, wenn der Service einen Servicekonsumenten dabei unterstützt, gewünschte Ergebnisse zu erreichen und dabei ein angemessenes Verhältnis zwischen Nutzen, Kosten und Risiken bietet.

Der Wert eines Services wird daher nicht allein durch den Service Provider bestimmt. Er entsteht durch das Zusammenwirken von Provider, Kunde, Benutzer und weiteren beteiligten Stakeholdern.

Entscheidend ist nicht, welche Technik bereitgestellt wurde, sondern welchen wahrgenommenen Nutzen sie für die Beteiligten erzeugt.

1. Wert im Service Management

ITIL beschreibt Wert als den wahrgenommenen Nutzen, die Nützlichkeit und die Bedeutung von etwas.

Dabei sind drei Punkte besonders wichtig:

Ein technisch identischer Service kann daher für zwei Organisationen einen völlig unterschiedlichen Wert besitzen.

Beispiel

Ein Cloudspeicher mit 2 TB Speicherplatz kann für ein kleines Unternehmen sehr wertvoll sein, wenn dadurch:

Für ein anderes Unternehmen kann derselbe Service ungeeignet sein, wenn:

Wert ist keine rein technische Eigenschaft eines Services, sondern hängt vom jeweiligen Kontext und von der Wahrnehmung der Stakeholder ab.

2. Wertschöpfung statt einseitiger Wertlieferung

In einem klassischen Liefermodell könnte der Eindruck entstehen, dass ein Anbieter einen fertigen Wert produziert und anschließend an den Kunden übergibt.

Im Service Management entsteht Wert jedoch normalerweise erst durch die gemeinsame Nutzung und Ausgestaltung des Services. ITIL spricht deshalb von Wertschöpfung durch Zusammenarbeit beziehungsweise Value Co-Creation.

Daran können beteiligt sein:

Beispiel: Einführung eines Ticketsystems

Der Service Provider kann:

Die Kundenorganisation muss unter anderem:

Erst durch das Zusammenwirken beider Seiten kann das gewünschte Ergebnis entstehen.

Ein Service Provider kann die Voraussetzungen für Wert schaffen. Ob tatsächlich Wert entsteht, hängt auch davon ab, wie der Service ausgewählt, eingerichtet, genutzt und weiterentwickelt wird.

3. Ergebnisse statt bloßer Ausgaben

Für die Bewertung eines Services müssen Outputs und Outcomes unterschieden werden.

Begriff Bedeutung Beispiel
Output unmittelbares Arbeitsergebnis einer Aktivität ein eingerichteter VPN-Zugang
Outcome durch einen oder mehrere Outputs ermöglichtes Ergebnis Beschäftigte können sicher von außerhalb arbeiten
Wert wahrgenommener Nutzen und Bedeutung des Ergebnisses produktives und flexibles Arbeiten bei vertretbarem Risiko

Ein Output kann technisch vollständig erbracht worden sein, ohne dass das gewünschte Outcome erreicht wird.

Beispiel

Ein Monitoring-System wurde installiert und erfasst alle Server. Das ist zunächst ein Output.

Das gewünschte Outcome könnte sein:

Werden zwar Messwerte gesammelt, aber keine sinnvollen Warnungen erzeugt und keine Reaktionen festgelegt, ist der technische Output vorhanden, das angestrebte Outcome jedoch nicht erreicht.

4. Nutzen beziehungsweise Utility

Die Utility beschreibt, ob ein Service für einen bestimmten Zweck geeignet ist und die benötigte Funktionalität bereitstellt.

Sie beantwortet vereinfacht die Frage:

Tut der Service das, was benötigt wird?

Utility kann entstehen, wenn ein Service:

Utility wird häufig als „fit for purpose“ bezeichnet: für den vorgesehenen Zweck geeignet.

Beispiele

Service mögliche Utility
E-Mail-Service Nachrichten senden und empfangen
Backup-Service wiederherstellbare Kopien von Daten erzeugen
VPN-Service sicheren Fernzugriff ermöglichen
Ticketsystem Anfragen und Störungen strukturiert erfassen
Identitätsdienst Benutzer authentifizieren und Zugriffe steuern
Monitoring Zustände erfassen und relevante Abweichungen melden

Eine hohe Utility allein reicht nicht aus. Ein Service kann alle benötigten Funktionen besitzen und trotzdem unbrauchbar sein, wenn er beispielsweise zu häufig ausfällt oder nicht ausreichend geschützt ist.

5. Zusicherung beziehungsweise Warranty

Die Warranty beschreibt, unter welchen Bedingungen und mit welcher zugesicherten Qualität ein Service genutzt werden kann.

Sie beantwortet vereinfacht die Frage:

Funktioniert der Service zuverlässig genug und unter den benötigten Bedingungen?

Warranty kann sich insbesondere auf folgende Eigenschaften beziehen:

Warranty wird häufig als „fit for use“ bezeichnet: für die tatsächliche Nutzung geeignet.

Beispiel

Ein Videokonferenzdienst besitzt die benötigten Funktionen. Er bietet damit grundsätzlich Utility.

Für eine Organisation ist er jedoch nur dann tatsächlich nutzbar, wenn beispielsweise:

6. Utility und Warranty gehören zusammen

Utility Warranty
Was leistet der Service? Wie zuverlässig und unter welchen Bedingungen leistet er es?
für den Zweck geeignet für die Nutzung geeignet
benötigte Funktionen benötigtes Qualitätsniveau
unterstützt gewünschte Ergebnisse stellt die erforderlichen Nutzungsbedingungen sicher

Beispiel: Backup-Service

Utility

Warranty

Utility ohne ausreichende Warranty bedeutet: Der Service kann grundsätzlich das Richtige, ist aber nicht zuverlässig genug. Warranty ohne passende Utility bedeutet: Der Service funktioniert zuverlässig, löst jedoch nicht das benötigte Problem.

7. Kosten aus Sicht des Servicekonsumenten

Kosten sind nicht nur der Kaufpreis oder die monatliche Rechnung. Bei der Bewertung eines Services müssen alle relevanten Aufwände betrachtet werden.

Mögliche Kosten sind:

ITIL unterscheidet aus Sicht des Servicekonsumenten zwei grundlegende Wirkungen:

Beispiel: Managed Backup

Durch den Service entstehen unter anderem:

Gleichzeitig können andere Kosten reduziert oder vermieden werden:

Für eine sachgerechte Bewertung müssen zusätzliche Kosten und vermiedene Kosten gemeinsam betrachtet werden.

8. Risiken aus Sicht des Servicekonsumenten

Ein Risiko ist ein mögliches Ereignis, das Schaden verursachen, die Zielerreichung beeinträchtigen oder Unsicherheit erzeugen kann.

Bei Services können Risiken beispielsweise entstehen durch:

Auch bei Risiken müssen zwei Wirkungen unterschieden werden:

Beispiel: Cloudbasierter E-Mail-Service

Möglicherweise reduzierte Risiken:

Möglicherweise neu entstehende oder verbleibende Risiken:

Die Auslagerung eines Services beseitigt nicht automatisch die Verantwortung der Kundenorganisation. Risiken können übertragen, geteilt, reduziert oder akzeptiert werden, müssen aber weiterhin gesteuert werden.

9. Erfahrung und wahrgenommene Servicequalität

Die technische Leistung eines Services ist nicht der einzige Faktor für seinen Wert. Auch die Erfahrung der beteiligten Personen beeinflusst, wie der Service wahrgenommen wird.

Dazu gehören beispielsweise:

Beispiel

Zwei Provider können technisch eine Verfügbarkeit von 99,9 Prozent erreichen. Der eine informiert bei Störungen frühzeitig, nennt regelmäßig den Bearbeitungsstand und dokumentiert anschließend die Ursache. Der andere reagiert verspätet und kommuniziert widersprüchlich.

Obwohl die gemessene Verfügbarkeit gleich ist, kann der wahrgenommene Wert deutlich unterschiedlich sein.

Technische Kennzahlen müssen durch die Perspektive von Kunden und Benutzern ergänzt werden.

10. Nachhaltigkeit als Teil langfristiger Wertbetrachtung

In der aktuellen ITIL-Weiterentwicklung wird Nachhaltigkeit ausdrücklich in die Betrachtung von Wert, Outcomes, Kosten, Risiken und Erfahrung einbezogen.

Nachhaltigkeit kann verschiedene Perspektiven umfassen:

Beispiel

Eine technisch leistungsfähige Lösung kann kurzfristig einen hohen Nutzen erzeugen. Wenn sie jedoch:

kann ihr langfristiger Wert gering sein.

11. Unterschiedliche Stakeholder bewerten Wert unterschiedlich

Stakeholder mögliche Wertkriterien
Benutzer einfache und störungsarme Nutzung
Kunde Unterstützung der Geschäftsziele
Sponsor vertretbare Finanzierung und messbarer Nutzen
Service Provider zuverlässige und wirtschaftliche Leistungserbringung
Management Zielerreichung, Steuerbarkeit und Risikokontrolle
Informationssicherheit Vertraulichkeit, Integrität und Verfügbarkeit
Datenschutz rechtmäßige und zweckgebundene Verarbeitung
Fachabteilung passende Funktionen und kurze Bearbeitungszeiten
Support diagnostizierbare und wartbare Lösung
Lieferant klarer Leistungsumfang und erfüllbare Vereinbarungen

Konflikte sind möglich.

Beispiel

Eine besonders strenge Authentifizierung kann die Sicherheit erhöhen, gleichzeitig aber die Benutzung erschweren. Die Aufgabe des Service Managements besteht nicht darin, nur eine Perspektive zu maximieren, sondern gemeinsam eine angemessene Lösung zu finden.

12. Wertannahme und tatsächlich erreichter Wert

Vor Einführung eines Services existiert zunächst eine Annahme darüber, welchen Wert er erzeugen soll.

Diese Annahme muss später anhand tatsächlicher Ergebnisse überprüft werden.

Vor der Einführung

Nach der Einführung

Ein erfolgreich abgeschlossenes Einführungsprojekt beweist noch nicht, dass der Service dauerhaft Wert erzeugt.

13. Wertorientierte Kennzahlen

Kennzahlen sollten nicht nur technische Aktivität messen, sondern einen Bezug zu den gewünschten Ergebnissen besitzen.

schwache oder unvollständige Kennzahl stärker wertorientierte Ergänzung
Anzahl bearbeiteter Tickets Wiederherstellungszeit und Benutzerzufriedenheit
Anzahl durchgeführter Changes Anteil erfolgreicher Changes und Auswirkungen auf den Service
Serververfügbarkeit Verfügbarkeit des vollständigen Geschäftsservices
Anzahl erstellter Benutzerkonten Zeit bis zur vollständigen Arbeitsfähigkeit neuer Beschäftigter
Anzahl erzeugter Backups erfolgreiche und getestete Wiederherstellungen
Anzahl geschlossener Incidents nachhaltig behobene Störungen und Wiederholungsrate
Anzahl automatisierter Schritte eingesparte Bearbeitungszeit und reduzierte Fehlerquote

Kennzahlen dürfen nicht isoliert betrachtet werden. Eine verkürzte Ticketbearbeitungszeit wäre beispielsweise kein positiver Wertbeitrag, wenn Tickets lediglich vorschnell geschlossen werden und Benutzer anschließend neue Tickets eröffnen müssen.

14. Praxisbeispiel: neuer Remote-Work-Service

Eine Organisation führt einen Service für mobiles Arbeiten ein.

Erwartete Outcomes

Utility

Warranty

Zusätzliche Kosten

Möglicherweise vermiedene Kosten

Möglicherweise reduzierte Risiken

Möglicherweise neu entstehende Risiken

Mögliche Messgrößen

15. Typische Fehlinterpretationen

Aussage fachliche Einordnung
„Der Server läuft, also liefert der Service Wert.“ Ein laufender Server bestätigt weder die Funktion des vollständigen Services noch das gewünschte Outcome.
„Der Kunde hat bezahlt, also ist der Service wertvoll.“ Preis und wahrgenommener Wert sind nicht identisch.
„Alle vereinbarten Funktionen sind vorhanden.“ Utility kann vorhanden sein, während Warranty oder Benutzererfahrung unzureichend sind.
„Der Provider übernimmt den Betrieb, daher bestehen keine Risiken mehr.“ Risiken können reduziert oder übertragen werden, verschwinden aber nicht automatisch.
„Die Einführung wurde termingerecht abgeschlossen.“ Projekterfolg beweist noch keinen dauerhaften Servicewert.
„Die SLA-Werte wurden eingehalten.“ Einhaltung einzelner Messwerte beweist nicht, dass die geschäftlichen Outcomes erreicht wurden.
„Viele bearbeitete Tickets zeigen einen guten Support.“ Eine hohe Ticketzahl kann auch auf schlechte Servicequalität oder wiederkehrende Fehler hinweisen.
„Automatisierung erzeugt immer Wert.“ Automatisierung kann ungeeignete Abläufe beschleunigen und Fehler vervielfachen.
„Wert ist vollständig objektiv messbar.“ Messdaten sind wichtig, der Wert enthält jedoch auch wahrnehmungs- und kontextabhängige Aspekte.

16. Checkliste zur Bewertung eines Services

17. Versionshinweis: ITIL 4 und ITIL (Version 5)

Die grundlegende Wertorientierung bleibt auch in ITIL (Version 5) erhalten. Dazu gehören insbesondere:

ITIL (Version 5) hebt zusätzlich die Erfahrung der Stakeholder, Nachhaltigkeit und den gemeinsamen Lebenszyklus digitaler Produkte und Services deutlicher hervor.

Die in ITIL 4 verwendeten Konzepte Utility und Warranty bleiben für die praktische Bewertung von Serviceanforderungen relevant. Bei aktuellen Unterlagen muss jedoch immer geprüft werden, auf welche ITIL-Version und welchen offiziellen Lehrplan sie sich beziehen.

Merksatz

Wert entsteht, wenn ein Service gewünschte Ergebnisse ermöglicht, einen wahrgenommenen Nutzen bietet und Kosten sowie Risiken für die beteiligten Stakeholder in einem angemessenen Verhältnis stehen. Utility beschreibt, ob der Service das Richtige leistet; Warranty beschreibt, ob er unter den benötigten Bedingungen zuverlässig genutzt werden kann.

Quellen und weiterführende Dokumentation

1. Grundlagen des professionellen Service Managements

1.4 Servicebeziehungen, Rollen und Serviceangebote

Kurz erklärt

Ein Service entsteht nicht isoliert innerhalb einer IT-Abteilung. Er wird in einer Beziehung zwischen einem Service Provider und einem Service Consumer bereitgestellt, genutzt und fortlaufend weiterentwickelt.

Damit diese Beziehung funktioniert, muss eindeutig geklärt sein:

Eine Servicebeziehung besteht nicht nur aus der technischen Bereitstellung. Sie umfasst auch Zusammenarbeit, Vereinbarungen, Nutzung, Kommunikation und gemeinsame Verantwortung für die Wertschöpfung.

1. Service Provider

Ein Service Provider ist eine Organisation, die Services bereitstellt.

Der Provider kann:

Typische Aufgaben eines Service Providers sind:

Beispiele

Service Provider bereitgestellter Service
interne IT-Abteilung Arbeitsplatz- und Supportservice
externer Cloudanbieter Rechen-, Speicher- oder Plattformservice
Managed Service Provider Betrieb und Überwachung der IT-Infrastruktur
Telekommunikationsunternehmen Internet- und Standortverbindungen
internes Personalteam digital unterstützter Personalservice
Softwareanbieter cloudbasierte Fachanwendung
Rechenzentrum Hosting, Stromversorgung, Kühlung und Konnektivität

Der Begriff „Provider“ bezeichnet eine Rolle innerhalb einer bestimmten Servicebeziehung. Dieselbe Organisation kann gegenüber ihren Benutzern Provider und gegenüber einem Cloudanbieter Consumer sein.

2. Service Consumer

Ein Service Consumer ist eine Organisation, die Services eines Service Providers nutzt.

Der Begriff bezeichnet nicht nur einzelne Benutzer. Er umfasst die konsumierende Organisation und die unterschiedlichen Rollen, die an Auswahl, Finanzierung, Anforderungen und Nutzung eines Services beteiligt sind.

Zu den Aufgaben eines Service Consumers können gehören:

Beispiel

Ein Unternehmen nutzt einen externen E-Mail-Service.

Der Provider stellt unter anderem bereit:

Die Kundenorganisation muss unter anderem:

Der Provider trägt nicht automatisch die alleinige Verantwortung für alle Ergebnisse. Auch der Consumer muss die vereinbarten Beiträge leisten.

3. Customer, User und Sponsor

Innerhalb des Service Consumers unterscheidet ITIL drei wichtige Rollen:

Rolle Bedeutung zentrale Fragestellung
Customer definiert die Anforderungen an einen Service und übernimmt Verantwortung für die Outcomes des Servicekonsums Was benötigen wir und welche Ergebnisse sollen erreicht werden?
User verwendet den Service Kann ich den Service wirksam, sicher und verständlich nutzen?
Sponsor genehmigt beziehungsweise autorisiert das Budget für den Servicekonsum Ist die Finanzierung gerechtfertigt und tragfähig?

Diese Rollen müssen nicht von verschiedenen Personen ausgeübt werden. Eine Person kann mehrere Rollen übernehmen. In größeren Organisationen sind die Rollen jedoch häufig getrennt.

Beispiel: neues Ticketsystem

Sponsor

Customer

User

Ein Service kann die Erwartungen des Sponsors erfüllen und trotzdem für Benutzer ungeeignet sein. Deshalb müssen alle drei Perspektiven berücksichtigt werden.

4. Rollen sind kontextabhängig

ITIL-Rollen sind keine festen Berufsbezeichnungen. Sie beschreiben die Funktion einer Person oder Organisation in einer bestimmten Beziehung.

Beispiel: Software-as-a-Service

Ein Unternehmen verwendet eine cloudbasierte Personalverwaltungssoftware.

Beteiligter Rolle in diesem Zusammenhang
SaaS-Anbieter Service Provider gegenüber dem Unternehmen
Personalabteilung Customer und teilweise User
Geschäftsführung Sponsor
Beschäftigte User einzelner Funktionen
interne IT-Abteilung unterstützt die Nutzung und koordiniert die Integration
Cloud-Infrastruktur-Anbieter Provider gegenüber dem SaaS-Anbieter
SaaS-Anbieter Consumer gegenüber dem Cloud-Infrastruktur-Anbieter

Daraus folgt:

5. Produkte und Services unterscheiden

Ein Produkt ist eine Konfiguration von Ressourcen einer Organisation, die dazu entwickelt wurde, einem Consumer Wert anzubieten.

Zu solchen Ressourcen können gehören:

Ein Produkt kann die Grundlage für einen oder mehrere Services bilden.

Beispiel

Ein Provider betreibt eine Plattform für Zusammenarbeit.

Das Produkt kann unter anderem umfassen:

Auf dieser Grundlage können verschiedene Services angeboten werden:

Das Produkt ist die organisierte Ressourcenkonfiguration des Providers. Der Service ermöglicht dem Consumer daraus gewünschte Outcomes.

6. Service und Serviceangebot unterscheiden

Ein Service ermöglicht die gemeinsame Wertschöpfung, indem er gewünschte Outcomes unterstützt, ohne dass der Consumer bestimmte Kosten und Risiken vollständig selbst verwalten muss.

Ein Serviceangebot beschreibt dagegen eine konkrete Zusammenstellung von Leistungen, die sich an die Bedürfnisse einer bestimmten Consumer-Gruppe richtet.

Ein Serviceangebot kann enthalten:

  1. Waren
  2. Zugriff auf Ressourcen
  3. Service Actions

Diese Bestandteile können einzeln oder kombiniert auftreten.

7. Waren als Bestandteil eines Serviceangebots

Waren sind materielle oder übertragbare Bestandteile, deren Eigentum auf den Consumer übergehen kann.

Beispiele:

Typische Eigenschaften:

Beispiel

Ein Workplace-Service enthält:

Notebook, Dockingstation und Monitor können Waren sein. Einrichtung und Support sind dagegen Service Actions.

8. Zugriff auf Ressourcen

Ein Serviceangebot kann dem Consumer Zugriff auf Ressourcen ermöglichen, ohne dass deren Eigentum übertragen wird.

Beispiele:

Typische Eigenschaften:

Beispiel

Bei einem Cloudspeicher erhält der Consumer normalerweise nicht das Eigentum an bestimmten physischen Festplatten. Er erhält Zugriff auf eine vereinbarte Speicherkapazität und die dazugehörigen Funktionen.

9. Service Actions

Service Actions sind Tätigkeiten, die der Provider zur Unterstützung des Consumers ausführt.

Beispiele:

Service Actions können:

ausgeführt werden.

Beispiel

Ein Backup-Service kann enthalten:

10. Beispiel für ein vollständiges Serviceangebot

Service: verwalteter digitaler Arbeitsplatz

Bestandteil konkrete Leistung
Ware Notebook, Netzteil und gegebenenfalls Zubehör
Zugriff auf Ressourcen E-Mail, Dateispeicher, Fachanwendungen, VPN und Kollaborationsplattform
Service Actions Einrichtung, Softwareverteilung, Support, Wartung und Austausch
Utility Beschäftigte können ihre betrieblichen Aufgaben digital ausführen
Warranty vereinbarte Verfügbarkeit, Performance, Sicherheit, Kapazität und Kontinuität
Consumer-Beitrag sorgfältige Nutzung, Einhaltung der Sicherheitsregeln und Meldung von Problemen
erwartetes Outcome Beschäftigte sind innerhalb der vorgesehenen Zeit vollständig arbeitsfähig

Verschiedene Consumer-Gruppen können unterschiedliche Serviceangebote erhalten:

Ein Serviceangebot muss so konkret sein, dass Consumer verstehen, was enthalten ist, unter welchen Bedingungen es genutzt werden kann und welche eigenen Beiträge erforderlich sind.

11. Servicebeziehung

Eine Servicebeziehung ist die Zusammenarbeit zwischen einem Service Provider und einem Service Consumer.

Sie umfasst drei miteinander verbundene Bestandteile:

Bestandteil Bedeutung
Service Provision Tätigkeiten und Ressourcen des Providers zur Bereitstellung des Services
Service Consumption Tätigkeiten und Ressourcen des Consumers zur Nutzung des Services
Service Relationship Management gemeinsame Aktivitäten zur Pflege und Weiterentwicklung der Beziehung

12. Service Provision

Zur Service Provision können gehören:

Beispiel: VPN-Service

Der Provider:

13. Service Consumption

Zur Service Consumption können gehören:

Beispiel: VPN-Service

Der Consumer:

Auch die Nutzung eines Services benötigt Ressourcen, Kompetenzen, Verantwortlichkeiten und kontrollierte Abläufe.

14. Service Relationship Management

Service Relationship Management umfasst die gemeinsamen Aktivitäten von Provider und Consumer, mit denen die Servicebeziehung aufgebaut, gepflegt und verbessert wird.

Dazu gehören beispielsweise:

Typische Fragen eines Service Reviews

Eine Servicebeziehung muss aktiv gepflegt werden. Ein unterschriebener Vertrag ersetzt keine laufende Zusammenarbeit.

15. Interne und externe Servicebeziehungen

Servicebeziehungen können intern oder extern bestehen.

Merkmal interner Provider externer Provider
organisatorische Zugehörigkeit Teil derselben Organisation rechtlich selbstständige Organisation
Grundlage interne Vereinbarungen, Richtlinien und Service Levels Vertrag, Leistungsbeschreibung und Service Levels
Finanzierung interne Kostenstelle, Budget oder Leistungsverrechnung Rechnung, Abonnement oder nutzungsabhängige Zahlung
Steuerung interne Governance Vertrags- und Lieferantenmanagement
Eskalation interne Führungs- und Fachstrukturen vertragliche und organisatorische Eskalationswege
Verantwortung innerhalb der Organisation verteilt zwischen den Organisationen vereinbart

Auch interne Services benötigen:

„Intern“ bedeutet nicht automatisch kostenlos, unkritisch oder frei von Vereinbarungen.

16. Lieferanten und Partner

Ein Provider muss nicht alle Ressourcen und Tätigkeiten selbst bereitstellen. Häufig wirken weitere Organisationen mit.

Beispiele:

Der Consumer erlebt möglicherweise einen einzigen Service, obwohl im Hintergrund mehrere Provider und Lieferanten beteiligt sind.

Beispiel

Ein Software-as-a-Service-Angebot kann abhängig sein von:

Der direkte Provider bleibt gegenüber seinem Consumer für die vereinbarte Servicebeziehung verantwortlich, auch wenn Teile der Leistung von Lieferanten stammen.

Zu prüfen sind deshalb:

17. Beiträge des Providers und des Consumers

Für gemeinsame Wertschöpfung müssen die Beiträge beider Seiten bekannt sein.

Provider-Beitrag Consumer-Beitrag
geeignete Servicefunktionen klare Anforderungen
qualifiziertes Personal geeignete Ansprechpartner
technische Infrastruktur notwendige Endgeräte und lokale Voraussetzungen
Support und Dokumentation korrekte Nutzung und Mitarbeit
Sicherheitsmaßnahmen Einhaltung von Sicherheitsregeln
Monitoring und Berichte Rückmeldung über Erfahrung und Ergebnisse
Behandlung von Störungen vollständige und rechtzeitige Fehlermeldungen
geplante Verbesserungen Beteiligung an Tests und Abnahmen
transparente Kommunikation Mitteilung veränderter Anforderungen
vereinbarte Servicequalität Einhaltung eigener Verpflichtungen

Beispiel

Bei einer Datenmigration kann der Provider:

Der Consumer muss möglicherweise:

Fehlt einer dieser Beiträge, kann das gewünschte Outcome trotz technisch korrekter Provider-Leistung ausbleiben.

18. Vereinbarungen in Servicebeziehungen

Eine Vereinbarung kann formell oder informell sein. Sie muss jedoch für die beteiligten Parteien ausreichend eindeutig sein.

Mögliche Inhalte sind:

Mögliche Vereinbarungsformen:

Eine Vereinbarung ist nur wirksam, wenn die Beteiligten sie verstehen, praktisch erfüllen können und regelmäßig überprüfen.

19. Abgrenzung wichtiger Begriffe

Begriff Bedeutung
Produkt konfigurierte Ressourcen eines Providers zur Ermöglichung von Wertangeboten
Service Mittel zur gemeinsamen Wertschöpfung durch Unterstützung gewünschter Outcomes
Serviceangebot konkrete Beschreibung einer oder mehrerer Leistungen für eine Consumer-Gruppe
Service Provider Organisation, die Services bereitstellt
Service Consumer Organisation, die Services konsumiert
Customer definiert Anforderungen und verantwortet Outcomes des Servicekonsums
User verwendet den Service
Sponsor autorisiert das Budget für den Servicekonsum
Service Provision Bereitstellungstätigkeiten und Ressourcen des Providers
Service Consumption Nutzungstätigkeiten und Ressourcen des Consumers
Service Relationship Management gemeinsame Pflege und Weiterentwicklung der Beziehung
Output unmittelbares Arbeitsergebnis
Outcome durch Outputs ermöglichtes Ergebnis
Value wahrgenommener Nutzen und Bedeutung
Utility Eignung für den benötigten Zweck
Warranty Zusicherung der Eignung für die tatsächliche Nutzung

20. Praxisbeispiel: Managed Backup Service

Service Provider

Ein externes IT-Unternehmen betreibt den Backup-Service.

Service Consumer

Ein mittelständisches Unternehmen verwendet den Service zur Sicherung seiner Systeme.

Sponsor

Die Geschäftsführung genehmigt das Budget.

Customer

Die IT-Leitung definiert:

User

Administratoren verwenden:

Indirekte Benutzer sind alle Beschäftigten, deren Daten und Anwendungen durch den Service geschützt werden.

Serviceangebot

Provider-Beiträge

Consumer-Beiträge

Erwartete Outcomes

Erst getestete und fachlich bestätigte Wiederherstellungen zeigen, ob die Servicebeziehung das erwartete Outcome tatsächlich unterstützt.

21. Praxisbeispiel: interner Onboarding-Service

Ein neuer Beschäftigter soll am ersten Arbeitstag vollständig arbeitsfähig sein.

Beteiligte Provider

Consumer-Rollen

Rolle mögliches Beispiel
Sponsor Leitung der einstellenden Organisationseinheit
Customer verantwortliche Führungskraft
User neuer Beschäftigter

Benötigte Leistungen

Mögliches Outcome

Der neue Beschäftigte kann die vorgesehenen Aufgaben sicher und ohne unnötige Verzögerung ausführen.

Einzelne technische Outputs reichen dafür nicht aus. Ein eingerichtetes Notebook erzeugt noch keinen vollständigen Wert, wenn:

22. Typische Konflikte in Servicebeziehungen

Konflikt mögliche Ursache
Anforderungen werden nicht erfüllt Anforderungen waren unklar, widersprüchlich oder nicht abgestimmt
Benutzer lehnen den Service ab Benutzerperspektive wurde nicht ausreichend berücksichtigt
Sponsor zweifelt am Nutzen Outcomes und Wirtschaftlichkeit wurden nicht belegt
Provider erwartet mehr Mitwirkung Consumer-Beiträge wurden nicht vereinbart
Consumer erwartet nicht enthaltene Leistungen Serviceangebot und Ausschlüsse sind unklar
Service Levels werden erfüllt, trotzdem besteht Unzufriedenheit Kennzahlen bilden die tatsächliche Erfahrung oder Outcomes nicht ab
Änderungen führen zu Problemen Kommunikation, Tests oder Verantwortlichkeiten fehlen
Störungen eskalieren zu spät Eskalationswege sind unbekannt oder ungeeignet
Lieferant verursacht wiederholt Ausfälle unterstützende Verträge passen nicht zu den Consumer-Anforderungen
Kosten steigen unerwartet Nutzung, Abrechnung und Kapazitätsentwicklung werden nicht ausreichend überwacht

Konflikte sollten nicht nur als Kommunikationsproblem behandelt werden. Sie können auf strukturelle Mängel hinweisen, beispielsweise:

23. Typische Fehlinterpretationen

Aussage fachliche Einordnung
„Der Benutzer ist automatisch der Kunde.“ User und Customer sind unterschiedliche Rollen, auch wenn eine Person beide Rollen besitzen kann.
„Wer bezahlt, definiert automatisch alle Anforderungen.“ Der Sponsor autorisiert das Budget; die Anforderungen werden durch die Customer-Rolle bestimmt.
„Der Provider erzeugt den Wert allein.“ Wert entsteht durch das Zusammenwirken von Provider, Consumer und weiteren Stakeholdern.
„Ein Produkt und ein Service sind dasselbe.“ Ein Produkt ist eine Ressourcenkonfiguration; ein Service unterstützt die gemeinsame Wertschöpfung.
„Ein Serviceangebot ist nur eine Preisliste.“ Es beschreibt konkrete Leistungen, Zielgruppen, Bedingungen und Bestandteile des Angebots.
„Bei einem Cloudservice besitzt der Consumer die Infrastruktur.“ Normalerweise erhält er Zugriff auf Ressourcen, ohne deren Eigentum zu übernehmen.
„Ein externer Provider übernimmt alle Risiken.“ Risiken und Verantwortlichkeiten werden verteilt, aber nicht automatisch vollständig übertragen.
„Interne Services benötigen keine Vereinbarungen.“ Auch interne Servicebeziehungen benötigen klare Erwartungen und Verantwortlichkeiten.
„Ein Vertrag reicht zur Steuerung der Beziehung aus.“ Die Beziehung muss fortlaufend kommuniziert, überprüft und verbessert werden.
„Der direkte Provider ist für Fehler seiner Lieferanten nicht zuständig.“ Gegenüber dem Consumer gelten weiterhin die vereinbarten Verantwortlichkeiten des direkten Providers.
„Ein Service ist erfolgreich, wenn er bereitgestellt wurde.“ Entscheidend sind Nutzung, Outcomes, Erfahrung und tatsächlich erzeugter Wert.

24. Checkliste für eine klare Servicebeziehung

25. Versionshinweis: ITIL 4 und ITIL (Version 5)

Die grundlegenden Rollen und Beziehungen bleiben auch in ITIL (Version 5) wichtig. Dazu gehören insbesondere:

ITIL (Version 5) verwendet für die finanzierende Consumer-Rolle teilweise die präzisere Bezeichnung Consumer Sponsor, um sie deutlicher von anderen Sponsorrollen abzugrenzen.

Zusätzlich betrachtet ITIL (Version 5) die Perspektiven und Erfahrungen von Benutzern, Kunden, Consumer Sponsors und Provider-Rollen stärker entlang einer durchgängigen Product and Service Lifecycle Journey.

Für Prüfungen und Zertifizierungen muss immer die Terminologie der jeweils zugrunde liegenden ITIL-Version und des offiziellen Lehrplans verwendet werden.

Merksatz

Ein Service Provider stellt nicht einfach Technik bereit. Provider und Consumer bilden eine Servicebeziehung, in der Customer, User und Sponsor unterschiedliche Perspektiven vertreten. Ein klares Serviceangebot beschreibt, welche Waren, Ressourcenzugriffe und Service Actions enthalten sind und welche Beiträge beide Seiten leisten müssen, damit die gewünschten Outcomes und gemeinsamer Wert entstehen.

Quellen und weiterführende Dokumentation

2. ITIL verstehen – Aufbau, Prinzipien und Modelle

2. ITIL verstehen – Aufbau, Prinzipien und Modelle

2.1 Was ist ITIL und wie ist das Framework aufgebaut?

Kurz erklärt

ITIL ist ein anpassbares Best-Practice-Framework für das Management digitaler Produkte und Services.

Es unterstützt Organisationen dabei, technische und organisatorische Fähigkeiten so miteinander zu verbinden, dass für Benutzer, Kunden und weitere Stakeholder verlässliche Outcomes und nachhaltiger Wert entstehen.

ITIL ist kein fertiger Unternehmensprozess, kein Ticketsystem und keine technische Anleitung. Das Framework stellt Begriffe, Prinzipien, Modelle und Management Practices bereit, die an die jeweilige Organisation angepasst werden müssen.

Was bedeutet ITIL?

Die Bezeichnung ITIL entstand ursprünglich aus dem Namen Information Technology Infrastructure Library.

Heute wird ITIL als eigenständiger Name des Frameworks verwendet.

Die aktuelle Generation ist ITIL Version 5.

Sie betrachtet nicht mehr ausschließlich den Betrieb von IT-Services, sondern das integrierte Management digitaler Produkte und Services über ihren gesamten Lebenszyklus.

Dazu gehören unter anderem:

Merke

ITIL beschreibt nicht nur, wie bestehende IT-Services unterstützt werden.

Es betrachtet auch, wie digitale Produkte und Services entstehen, zusammenwirken und über ihren gesamten Lebenszyklus Wert ermöglichen.

Was ist ein Framework?

Ein Framework ist ein strukturierter Orientierungsrahmen.

Es stellt unter anderem bereit:

Ein Framework schreibt jedoch nicht jeden Arbeitsschritt verbindlich vor.

ITIL legt beispielsweise nicht grundsätzlich fest:

Diese Entscheidungen hängen vom jeweiligen Kontext ab.

Dazu gehören beispielsweise:

Grundsatz

ITIL wird nicht unverändert „installiert“.

Die Organisation verwendet geeignete Bestandteile des Frameworks und passt sie an ihren tatsächlichen Bedarf an.

ITIL ist Best-Practice-Guidance

ITIL stellt bewährte Orientierung für das Management digitaler Produkte und Services bereit.

Best Practice bedeutet in diesem Zusammenhang:

ITIL ist deshalb weder:

Typischer Fehler

Eine Organisation übernimmt Begriffe, Formulare und Genehmigungsstufen, ohne zu prüfen, welches konkrete Problem damit gelöst werden soll.

Dadurch kann unnötige Bürokratie entstehen, ohne dass sich Produkte, Services oder Outcomes verbessern.

Wofür ITIL eingesetzt wird

ITIL kann Organisationen dabei unterstützen:

ITIL kann in unterschiedlichen Organisationen eingesetzt werden.

Beispiele:

Die Grundgedanken sind nicht auf eine bestimmte Branche oder Organisationsgröße beschränkt.

ITIL richtet sich nicht nur an IT-Service-Manager

ITIL ist für unterschiedliche Rollen relevant.

Dazu gehören beispielsweise:

Nicht jede Rolle benötigt dasselbe Detailwissen.

Ein Fachinformatiker für Systemintegration muss beispielsweise nicht jede strategische Entscheidung selbst treffen.

Er sollte jedoch verstehen:

Der zentrale Gedanke: Wert ermöglichen

ITIL richtet das Management digitaler Produkte und Services auf Wert aus.

Wert entsteht nicht allein dadurch, dass eine technische Komponente vorhanden ist.

Ein Service ist beispielsweise nicht automatisch wertvoll, nur weil:

Entscheidend ist, ob die beteiligten Stakeholder die benötigten Outcomes erreichen.

Beispiele:

Technischer Output Erwartetes Outcome
Benutzerkonto wurde angelegt. Neuer Mitarbeiter kann seine Aufgaben ausführen.
VPN-Client wurde installiert. Mitarbeiter kann sicher von außerhalb arbeiten.
Backup wurde erstellt. Daten können nach einem Verlust wiederhergestellt werden.
Anwendung wurde bereitgestellt. Fachabteilung kann ihren Geschäftsprozess durchführen.
Monitoring wurde eingerichtet. Relevante Störungen werden rechtzeitig erkannt und behandelt.

Bei der Bewertung von Wert berücksichtigt ITIL Version 5 insbesondere das Zusammenspiel von:

Wert wird gemeinsam ermöglicht

Wert wird nicht ausschließlich vom Service Provider erzeugt und anschließend an einen passiven Kunden übergeben.

Service Provider, Service Consumer und weitere Stakeholder wirken gemeinsam daran mit, dass ein gewünschtes Outcome erreicht wird.

Beispiel: sicherer Fernzugriff

Der Service Provider stellt unter anderem bereit:

Der Benutzer trägt unter anderem bei durch:

Die Fachabteilung oder Führungskraft trägt möglicherweise bei durch:

Merke

Ein Service kann technisch bereitgestellt werden.

Das gewünschte Outcome entsteht jedoch erst durch das Zusammenwirken der beteiligten Personen, Teams, Technologien und Arbeitsweisen.

Der Aufbau von ITIL Version 5

ITIL Version 5 besteht aus mehreren miteinander verbundenen Bestandteilen.

Bestandteil Zweck
Grundbegriffe des Produkt- und Service-Managements schaffen eine gemeinsame fachliche Sprache
Wertschöpfung und Servicebeziehungen erklären, wie Stakeholder gemeinsam Outcomes und Wert ermöglichen
vier Dimensionen unterstützen eine ganzheitliche Betrachtung
ITIL Value System verbindet die zentralen Elemente des Frameworks
Guiding Principles unterstützen Entscheidungen in unterschiedlichen Situationen
Governance sorgt für Steuerung, Überwachung und Verantwortlichkeit
Value Chain Activities beschreiben zentrale Aktivitäten zur Wertschöpfung
Management Practices stellen organisatorische Fähigkeiten und Ressourcen für bestimmte Aufgaben bereit
Continual Improvement unterstützt die fortlaufende Verbesserung
Product and Service Lifecycle verbindet Produkt- und Servicearbeit über einen gemeinsamen Lebenszyklus
Value Stream Mapping and Management macht den Arbeitsfluss zur Erzeugung von Wert sichtbar und verbesserbar

Diese Bestandteile dürfen nicht dauerhaft isoliert betrachtet werden.

Sie ergänzen sich und werden abhängig von der jeweiligen Situation miteinander kombiniert.

Das ITIL Value System

Das ITIL Value System beschreibt, wie unterschiedliche Bestandteile und Aktivitäten einer Organisation zusammenwirken, um Wert zu ermöglichen.

Es verbindet:

Das Value System dient als übergeordneter Orientierungsrahmen.

Es hilft bei Fragen wie:

Wichtig

Das ITIL Value System ist kein einzelner Prozess.

Es beschreibt das Zusammenwirken verschiedener Elemente des Produkt- und Service-Managements.

Die einzelnen Bestandteile werden auf späteren Seiten dieses Kapitels ausführlich behandelt.

Die Guiding Principles

Die Guiding Principles sind allgemeine Empfehlungen, die Entscheidungen und Handlungen in unterschiedlichen Situationen unterstützen.

Sie sollen dabei helfen:

Die Guiding Principles sind keine starren Arbeitsschritte.

Sie dienen als Denk- und Entscheidungshilfe.

Ein einzelner Grundsatz sollte nicht isoliert angewendet werden, wenn dadurch andere wichtige Perspektiven übersehen werden.

Praxisbeispiel

Die Automatisierung einer Benutzeranlage kann Zeit sparen.

Vor der Automatisierung muss jedoch verstanden werden:

Governance

Governance sorgt dafür, dass die Organisation:

Governance ist nicht mit täglichem Management gleichzusetzen.

Vereinfacht betrachtet:

Governance Management
legt Richtung und Rahmenbedingungen fest plant und koordiniert die praktische Umsetzung
bewertet Bedürfnisse und Erwartungen organisiert Ressourcen und Aktivitäten
überwacht Leistung und Regelkonformität führt Arbeit innerhalb der Vorgaben durch
stellt Verantwortlichkeit sicher bearbeitet konkrete Aufgaben und Entscheidungen

Beispiel:

Die Unternehmensleitung kann vorgeben, dass administrative Zugriffe grundsätzlich durch Multi-Faktor-Authentifizierung geschützt werden müssen.

Das zuständige IT-Team plant und implementiert anschließend die konkrete technische Lösung.

Die vier Dimensionen

ITIL verwendet vier Dimensionen, damit Produkte und Services nicht ausschließlich aus einer technischen Perspektive betrachtet werden.

Dimension Typische Inhalte
Organisationen und Menschen Rollen, Verantwortlichkeiten, Kompetenzen, Kommunikation und Kultur
Informationen und Technologie Daten, Anwendungen, Infrastruktur, Automatisierung und Wissen
Partner und Lieferanten Hersteller, Provider, Verträge und externe Abhängigkeiten
Wertströme und Prozesse Aktivitäten, Abläufe, Übergaben, Kontrollen und Arbeitsfluss

Die Dimensionen beeinflussen sich gegenseitig.

Beispiel:

Eine neue Monitoring-Plattform kann technisch leistungsfähig sein.

Sie liefert trotzdem keinen ausreichenden Nutzen, wenn:

Merke

Ein technisches Problem kann organisatorische Ursachen besitzen.

Ein organisatorisches Problem kann technische Folgen verursachen.

Der Product and Service Lifecycle

ITIL Version 5 verwendet ein gemeinsames Lebenszyklusmodell für digitale Produkte und Services.

Das Modell umfasst acht miteinander verbundene Aktivitäten:

  1. Discover – Bedarf, Chancen, Erwartungen und Ausgangslage verstehen
  2. Design – geeignete Produkte, Services und Lösungen gestalten
  3. Acquire – benötigte Ressourcen, Produkte oder Leistungen beschaffen
  4. Build – Lösungen erstellen, konfigurieren, integrieren und testen
  5. Transition – neue oder geänderte Lösungen kontrolliert in die vorgesehene Umgebung überführen
  6. Operate – Produkte, Systeme und technische Fähigkeiten betreiben
  7. Deliver – Services und vereinbarte Leistungen für Stakeholder bereitstellen
  8. Support – Benutzer, Kunden, Produkte und Services unterstützen

Die Aktivitäten bilden keinen starren linearen Ablauf.

Je nach Situation können sie:

Beispiel:

Während des Betriebs kann erkannt werden, dass eine Anwendung die Anforderungen der Benutzer nicht ausreichend erfüllt.

Diese Erkenntnis kann erneut zu Discovery und Design führen, obwohl das Produkt bereits produktiv verwendet wird.

Wichtig

Ein Produkt oder Service befindet sich nicht dauerhaft nur in einer einzigen Lebenszyklusaktivität.

Unterschiedliche Versionen, Komponenten oder Verbesserungen können gleichzeitig verschiedene Aktivitäten durchlaufen.

Management Practices

Eine Management Practice ist mehr als ein einzelner Prozess.

Sie umfasst organisatorische Ressourcen und Fähigkeiten, die zur Erreichung eines bestimmten Zwecks eingesetzt werden.

Dazu können gehören:

Beispiele für Management Practices:

ITIL Version 5 verwendet weiterhin 34 Management Practices.

Diese sind in zwei Gruppen eingeordnet:

  1. Product and Service Management Practices
  2. General Management Practices

Typischer Fehler

Eine Practice wird ausschließlich als Ablaufdiagramm betrachtet.

Für eine wirksame Practice werden jedoch auch Rollen, Informationen, Fähigkeiten, Werkzeuge, Beziehungen und kontinuierliche Verbesserungen benötigt.

Continual Improvement

Continual Improvement ist im gesamten ITIL-Framework verankert.

Verbesserungen können sich beziehen auf:

Eine Verbesserung sollte nicht nur aus einer spontanen Idee bestehen.

Sie sollte möglichst beantworten:

Beispiel:

Nach mehreren Störungen wird erkannt, dass ein ablaufendes Zertifikat nicht rechtzeitig bemerkt wurde.

Eine nachhaltige Verbesserung könnte umfassen:

Value Streams

Ein Value Stream beschreibt die Abfolge von Schritten, durch die für einen Stakeholder Wert ermöglicht wird.

Ein Value Stream kann mehrere:

miteinander verbinden.

Beispiel: neuer Mitarbeiter benötigt einen arbeitsfähigen IT-Arbeitsplatz

Mögliche Schritte:

  1. Personalabteilung meldet den Eintritt.
  2. Führungskraft benennt Aufgaben und Berechtigungen.
  3. Benutzerkonto wird erstellt.
  4. Lizenzen werden zugewiesen.
  5. Endgerät wird vorbereitet.
  6. Sicherheitsmaßnahmen werden eingerichtet.
  7. Zugriffe werden getestet.
  8. Gerät und Zugangsdaten werden übergeben.
  9. Benutzer bestätigt die Arbeitsfähigkeit.
  10. Dokumentation und Asset-Daten werden aktualisiert.

An diesem Value Stream können unter anderem beteiligt sein:

Merke

Ein Value Stream folgt dem Weg zum gewünschten Outcome.

Er endet nicht automatisch an der Grenze eines einzelnen Teams.

ITIL verbindet Produkt- und Serviceperspektive

Digitale Produkte und Services sind zwei eng miteinander verbundene Perspektiven auf eine technologiebasierte Lösung.

Die Produktperspektive betrachtet beispielsweise:

Die Serviceperspektive betrachtet beispielsweise:

Beide Perspektiven benötigen einander.

Ohne ausreichende Produktperspektive Ohne ausreichende Serviceperspektive
technische Schulden werden übersehen Benutzeranforderungen werden übersehen
Produktentwicklung erfolgt ohne langfristige Planung Support und Betrieb werden zu spät berücksichtigt
Funktionen werden unkoordiniert erweitert technisch erfolgreiche Produkte liefern keine brauchbaren Services
Lebenszyklus und Ablösung bleiben ungeklärt Erfahrung und Servicequalität werden nicht ausreichend bewertet

ITIL Version 5 verbindet diese Perspektiven durch einen gemeinsamen Produkt- und Service-Lebenszyklus.

Was ITIL nicht vorgibt

ITIL gibt keinen universellen Musterprozess für jede Organisation vor.

Das Framework bestimmt nicht automatisch:

Diese Elemente müssen von der Organisation selbst gestaltet werden.

ITIL unterstützt dabei mit:

ITIL ist keine Zertifizierung einer Organisation

Personen können ITIL-Zertifizierungen erwerben.

Das bedeutet jedoch nicht automatisch, dass:

Auch ein Werkzeug kann bestimmte ITIL-Practices unterstützen oder dafür bewertet worden sein.

Das Werkzeug allein führt jedoch kein wirksames Service Management ein.

Merke

Zertifikate, Werkzeuge und Prozessdokumente können professionelles Service Management unterstützen.

Entscheidend ist, wie wirksam die Organisation tatsächlich arbeitet und welche Outcomes sie erreicht.

ITIL und andere Methoden oder Frameworks

ITIL kann gemeinsam mit anderen Ansätzen verwendet werden.

Beispiele:

Ansatz Mögliche Ergänzung zu ITIL
Agile Arbeitsweisen iterative Entwicklung und schnelles Feedback
Scrum strukturierte Produktentwicklung in Teams
Kanban Visualisierung und Steuerung des Arbeitsflusses
DevOps Zusammenarbeit zwischen Entwicklung, Betrieb und weiteren Beteiligten
Lean Reduzierung von Verschwendung und Verbesserung des Flusses
COBIT Governance und Steuerung von Information und Technologie
ISO/IEC 20000 Anforderungen an ein Service-Management-System
ISO/IEC 27001 Anforderungen an ein Informationssicherheitsmanagementsystem
Projektmanagement zeitlich begrenzte Vorhaben mit definierten Zielen

ITIL verlangt nicht, diese Ansätze zu ersetzen.

Sie können sich ergänzen, wenn:

Praxisbeispiel: Eine neue Monitoring-Lösung

Eine Organisation möchte eine neue Monitoring-Lösung einführen.

Eine rein technische Betrachtung könnte sich konzentrieren auf:

Die ITIL-Perspektive ergänzt weitere Fragen.

Wert und Outcomes

Vier Dimensionen

Lebenszyklus

Practices

Verbesserung

Dieses Beispiel zeigt, dass ITIL die technische Umsetzung nicht ersetzt.

Es erweitert die Betrachtung um Ziele, Stakeholder, Lebenszyklus, Zusammenarbeit, Risiken und Verbesserung.

Typische Missverständnisse

Missverständnis 1: ITIL schreibt jeden Prozess genau vor

ITIL stellt anpassbare Best-Practice-Guidance bereit.

Die konkrete Umsetzung wird von der Organisation gestaltet.

Missverständnis 2: ITIL ist nur für große Unternehmen geeignet

Auch kleine Organisationen können geeignete Grundsätze, Practices und einfache Arbeitsweisen verwenden.

Der Umfang muss zum tatsächlichen Bedarf passen.

Missverständnis 3: ITIL bedeutet viele Formulare und Genehmigungen

Unnötige Bürokratie widerspricht einer sinnvollen Anpassung des Frameworks.

Kontrollen sollen einen erkennbaren Zweck erfüllen.

Missverständnis 4: ITIL ersetzt technisches Fachwissen

ITIL unterstützt die Organisation technischer Arbeit.

Es erklärt nicht die konkrete Konfiguration jedes Produkts.

Missverständnis 5: ITIL betrifft nur den Service Desk

Produktentwicklung, Betrieb, Support, Informationssicherheit, Lieferantensteuerung, Governance und Führung können ebenfalls beteiligt sein.

Missverständnis 6: Ein ITIL-Begriff muss intern zwingend genauso heißen

Organisationen können eigene Bezeichnungen verwenden.

Wichtig ist, dass Bedeutung, Verantwortung und Arbeitsweise eindeutig sind.

Missverständnis 7: ITIL Version 5 macht alles aus ITIL 4 ungültig

ITIL Version 5 entwickelt viele bestehende Konzepte weiter.

ITIL-4-Wissen bleibt in zahlreichen Bereichen relevant, muss bei versionsabhängigen Aussagen jedoch richtig eingeordnet werden.

Wie ein Systemintegrator ITIL praktisch verwendet

Ein Fachinformatiker für Systemintegration muss nicht vor jeder Handlung das gesamte Framework analysieren.

Für den Arbeitsalltag können bereits folgende Fragen hilfreich sein:

  1. Welcher Service oder welches Produkt ist betroffen?
  2. Welches Outcome wird benötigt?
  3. Welche Stakeholder sind beteiligt?
  4. Welche der vier Dimensionen müssen berücksichtigt werden?
  5. Welche technischen und organisatorischen Abhängigkeiten bestehen?
  6. Welche Practice unterstützt die Aufgabe?
  7. Welche Risiken und Vorgaben müssen beachtet werden?
  8. Wie wird der Erfolg überprüft?
  9. Was muss dokumentiert werden?
  10. Was kann anschließend verbessert werden?

Checkliste zur Einordnung einer neuen Aufgabe

Schnellzusammenfassung

Begriff Kurzbeschreibung
ITIL anpassbares Best-Practice-Framework für digitales Produkt- und Service-Management
Framework strukturierter Orientierungsrahmen, kein starrer Musterprozess
Wert wahrgenommener Nutzen für Stakeholder
Value System verbindet zentrale Bestandteile des Frameworks zur Wertschöpfung
Guiding Principles allgemeine Empfehlungen für Entscheidungen und Handlungen
Governance Richtung, Überwachung und Verantwortlichkeit
vier Dimensionen ganzheitliche Betrachtung von Produkten und Services
Lifecycle gemeinsame Lebenszyklusbetrachtung digitaler Produkte und Services
Practice organisatorische Ressourcen und Fähigkeiten für einen bestimmten Zweck
Value Stream Abfolge von Schritten zur Ermöglichung von Wert
Continual Improvement fortlaufende Verbesserung von Produkten, Services und Arbeitsweisen

Aufbau dieses Kapitels

Die folgenden Seiten vertiefen die einzelnen Bestandteile des Frameworks:

Übersicht des Frameworks

Bedürfnisse, Chancen und Erwartungen
↓
ITIL Value System
↓
Guiding Principles · Governance · Value Chain Activities · Management Practices · Continual Improvement
↓
gemeinsamer Product and Service Lifecycle
↓
digitale Produkte und Services
↓
Outcomes und gemeinsam ermöglichter Wert

Die Darstellung ist eine vereinfachte Orientierung.

Die Elemente wirken nicht ausschließlich in einer linearen Reihenfolge, sondern beeinflussen sich gegenseitig.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die Aussagen zum Aufbau von ITIL Version 5, zum ITIL Value System, zu den vier Dimensionen, den Guiding Principles, Management Practices, Continual Improvement und dem gemeinsamen Produkt- und Service-Lebenszyklus wurden anhand der genannten offiziellen Quellen geprüft.

Die Praxisbeispiele, Tabellen, Checklisten und vereinfachten Darstellungen sind zusätzliche Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine vorgeschriebenen ITIL-Prozesse dar.

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

2. ITIL verstehen – Aufbau, Prinzipien und Modelle

2.2 Das ITIL Value System

Kurz erklärt

Das ITIL Value System beschreibt, wie die verschiedenen Bestandteile und Aktivitäten einer Organisation als zusammenhängendes System wirken, um Wert zu ermöglichen.

Es verbindet:

Ausgangspunkte sind Chancen, Anforderungen und Nachfrage. Das angestrebte Ergebnis ist gemeinsam ermöglichter Wert für Kunden, Benutzer, die Organisation und weitere Stakeholder.

Warum ein Value System notwendig ist

Digitale Produkte und Services entstehen nicht durch einen einzelnen Prozess oder ein einzelnes Team.

An ihrer Planung, Bereitstellung, Nutzung und Verbesserung können unter anderem beteiligt sein:

Jeder dieser Beteiligten kann eigene:

besitzen.

Werden diese Bereiche voneinander isoliert gesteuert, können lokale Verbesserungen entstehen, die dem gesamten Produkt oder Service schaden.

Beispiele:

Das Value System unterstützt deshalb eine ganzheitliche Betrachtung.

Merke

Professionelles Produkt- und Service-Management entsteht nicht durch einzelne optimierte Bestandteile.

Entscheidend ist, wie alle Bestandteile zusammenwirken.

Vom Bedarf zum Wert

Das ITIL Value System kann vereinfacht folgendermaßen dargestellt werden:

Chance oder Nachfrage
↓
ITIL Value System
↓
digitale Produkte und Services
↓
Outcomes, Erfahrungen und gemeinsam ermöglichter Wert

Nachfrage kann beispielsweise entstehen durch:

Eine Chance kann beispielsweise entstehen durch:

Das Value System soll dabei helfen, Nachfrage und Chancen nicht isoliert zu bearbeiten, sondern kontrolliert in wertschöpfende Ergebnisse zu überführen.

Wichtig

Nicht jede Nachfrage muss unverändert erfüllt werden.

Nicht jede technische Möglichkeit besitzt automatisch einen ausreichenden Nutzen.

Anforderungen und Chancen müssen hinsichtlich Outcomes, Wert, Kosten, Risiken, Erfahrung und Nachhaltigkeit bewertet werden.

Die fünf Bestandteile des ITIL Value Systems

Bestandteil Zentrale Aufgabe
Guiding Principles unterstützen Entscheidungen und Handlungen in unterschiedlichen Situationen
Governance gibt Richtung, überwacht die Organisation und stellt Verantwortlichkeit sicher
Value Chain Activities bilden ein flexibles Betriebsmodell für wertschöpfende Arbeit
Management Practices stellen benötigte organisatorische Ressourcen und Fähigkeiten bereit
Continual Improvement verbessert Produkte, Services, Practices und Arbeitsweisen fortlaufend

Diese Bestandteile sind keine voneinander getrennten Ebenen.

Sie wirken gleichzeitig und beeinflussen sich gegenseitig.

Das Value System ist kein einzelner Prozess

Ein Prozess beschreibt normalerweise eine strukturierte Abfolge von Aktivitäten, durch die bestimmte Eingaben in Ergebnisse überführt werden.

Das Value System ist umfassender.

Es verbindet:

Typischer Fehler

Das ITIL Value System wird als festes Ablaufdiagramm verstanden, das bei jedem Vorgang Schritt für Schritt durchlaufen werden muss.

Tatsächlich ist es ein übergeordneter Orientierungsrahmen, innerhalb dessen unterschiedliche Wertströme und Arbeitsabläufe gestaltet werden.

Ein Incident wird beispielsweise anders bearbeitet als:

Alle diese Situationen können jedoch innerhalb desselben Value Systems gesteuert werden.

Guiding Principles

Die Guiding Principles sind allgemeine Empfehlungen für Entscheidungen und Handlungen.

Sie gelten unabhängig davon:

Die sieben Guiding Principles sind:

  1. Focus on value
  2. Start where you are
  3. Progress iteratively with feedback
  4. Collaborate and promote visibility
  5. Think and work holistically
  6. Keep it simple and practical
  7. Optimize and automate

Praxisnahe Bedeutung:

Guiding Principle Leitfrage
Focus on value Welchen Nutzen und welches Outcome soll die Tätigkeit ermöglichen?
Start where you are Was funktioniert bereits und welche Informationen sind vorhanden?
Progress iteratively with feedback Kann die Verbesserung in kontrollierten Schritten erfolgen?
Collaborate and promote visibility Wer muss beteiligt werden und welche Informationen müssen sichtbar sein?
Think and work holistically Welche Produkte, Services, Menschen und Abhängigkeiten sind betroffen?
Keep it simple and practical Welche Schritte sind wirklich notwendig?
Optimize and automate Was sollte zuerst verbessert und anschließend sinnvoll automatisiert werden?

Die Guiding Principles ersetzen keine technische Analyse und keine betriebliche Vorgabe.

Sie helfen dabei, Entscheidungen aus mehreren Perspektiven zu prüfen.

Praxisbeispiel

Ein Administrator möchte die Anlage neuer Benutzerkonten automatisieren.

Die Guiding Principles führen unter anderem zu folgenden Fragen:

Die Guiding Principles werden auf der Seite 2.3 Die sieben Guiding Principles ausführlich behandelt.

Governance

Governance stellt sicher, dass die Organisation angemessen geführt und kontrolliert wird.

Dazu gehören insbesondere:

Governance wird häufig mit drei grundlegenden Tätigkeiten beschrieben:

Tätigkeit Bedeutung
Evaluate Situation, Bedürfnisse, Optionen, Leistung und Risiken bewerten
Direct Richtung, Prioritäten und Rahmenbedingungen vorgeben
Monitor Ergebnisse, Leistung, Risiken und Einhaltung überwachen

Beispiel:

Eine Organisation beschließt, dass administrative Zugriffe durch Multi-Faktor-Authentifizierung geschützt werden müssen.

Governance bestimmt unter anderem:

Das Management organisiert anschließend:

Merke

Governance gibt Richtung und Rahmenbedingungen vor.

Management plant, koordiniert und kontrolliert die praktische Umsetzung innerhalb dieses Rahmens.

Governance ist nicht nur Aufgabe einer einzelnen Führungskraft.

Je nach Organisation können verschiedene Gremien und Rollen beteiligt sein, beispielsweise:

Value Chain Activities

Die Value Chain Activities bilden das operative Kernmodell des Value Systems.

Sie beschreiben miteinander verbundene Tätigkeitsbereiche, die abhängig von der jeweiligen Situation zu Wertströmen kombiniert werden.

Ein Wertstrom kann beispielsweise zeigen, wie eine Organisation:

Die Value Chain Activities sind dabei keine starren Abteilungen.

Eine einzelne Aktivität kann Beiträge mehrerer Teams und Practices enthalten.

Beispiel:

Bei der Bereitstellung eines neuen Arbeitsplatzes können beteiligt sein:

Wichtig

Ein Wertstrom wird durch das benötigte Outcome bestimmt.

Er sollte nicht ausschließlich entlang bestehender Abteilungsgrenzen aufgebaut werden.

ITIL Version 5 verwendet eine gegenüber ITIL 4 vereinfachte und praxisnähere Darstellung der Value Chain. Sie bleibt Bestandteil des ITIL Value Systems und ist vom neuen Product and Service Lifecycle zu unterscheiden.

Management Practices

Management Practices stellen organisatorische Ressourcen und Fähigkeiten bereit, die zur Durchführung bestimmter Aufgaben oder zur Erreichung bestimmter Ziele benötigt werden.

Eine Practice besteht nicht nur aus einem Ablaufdiagramm.

Sie kann umfassen:

Beispiele:

Practice Typischer Beitrag
Incident Management negative Auswirkungen von Incidents verringern und Servicebetrieb wiederherstellen
Service Request Management vereinbarte Benutzeranfragen wirksam bearbeiten
Problem Management Ursachen und Wahrscheinlichkeiten von Incidents reduzieren
Change Management Änderungen bewerten und kontrolliert ermöglichen
Knowledge Management benötigtes Wissen verfügbar und nutzbar machen
Service Configuration Management verlässliche Informationen über Services und Configuration Items bereitstellen
IT Asset Management IT-Assets über ihren Lebenszyklus verwalten
Monitoring and Event Management relevante Zustandsänderungen erkennen und bewerten
Information Security Management Sicherheitsanforderungen und Risiken angemessen behandeln
Supplier Management Lieferanten und deren Leistungen steuern
Continual Improvement Verbesserungen identifizieren, priorisieren und umsetzen

Mehrere Practices können gemeinsam einen Wertstrom unterstützen.

Beispiel: Ein wiederkehrender Ausfall

  1. Monitoring and Event Management erkennt eine Abweichung.
  2. Incident Management koordiniert die Wiederherstellung.
  3. Problem Management untersucht die zugrunde liegende Ursache.
  4. Change Management unterstützt die kontrollierte dauerhafte Korrektur.
  5. Knowledge Management stellt die Lösung bereit.
  6. Service Configuration Management aktualisiert relevante Beziehungsinformationen.
  7. Continual Improvement bewertet weitere Verbesserungsmöglichkeiten.

Typischer Fehler

Eine Practice wird mit einem einzelnen Team gleichgesetzt.

In der Praxis können mehrere Teams zu einer Practice beitragen und ein Team kann an mehreren Practices beteiligt sein.

Continual Improvement

Continual Improvement ist im gesamten Value System verankert.

Verbessert werden können unter anderem:

Verbesserung ist nicht nur nach einem Fehler notwendig.

Sie kann entstehen durch:

Praxisbeispiel

Ein Zertifikat läuft unerwartet ab und verursacht einen Serviceausfall.

Die unmittelbare Wiederherstellung behebt den Incident.

Continual Improvement fragt zusätzlich:

Continual Improvement unterstützt jede Value Chain Activity und alle anderen Bestandteile des Value Systems.

Es wird auf der Seite 2.9 Continual Improvement ausführlich behandelt.

Wie die Bestandteile zusammenwirken

Die Bestandteile des Value Systems dürfen nicht isoliert betrachtet werden.

Beispiel: Einführung einer neuen Backup-Lösung

Guiding Principles

Governance

Value Chain Activities

Management Practices

Möglicherweise beteiligt:

Continual Improvement

Angestrebter Wert

Value System, Lifecycle, Value Stream und Practice unterscheiden

Diese Begriffe beschreiben unterschiedliche Betrachtungsebenen.

Begriff Bedeutung
ITIL Value System übergeordneter Rahmen, der die Bestandteile der Organisation zur Wertschöpfung verbindet
Product and Service Lifecycle beschreibt die gemeinsamen Lebenszyklusaktivitäten digitaler Produkte und Services
Value Chain flexibles operatives Modell innerhalb des Value Systems
Value Stream konkrete Abfolge von Schritten für ein bestimmtes Outcome
Management Practice Ressourcen und Fähigkeiten für einen bestimmten Zweck
Prozess strukturierte Aktivitäten, die Eingaben in Ergebnisse überführen
Arbeitsanweisung konkrete Beschreibung, wie eine bestimmte Tätigkeit ausgeführt wird

Beispiel:

Ziel: Ein neuer Mitarbeiter soll am ersten Arbeitstag arbeitsfähig sein.

Betrachtung Beispiel
Value System verbindet Steuerung, Prinzipien, Practices und Verbesserung
Lifecycle berücksichtigt Gestaltung, Aufbau, Betrieb, Bereitstellung und Unterstützung der verwendeten Produkte und Services
Value Stream führt von der Eintrittsmeldung bis zum geprüften Arbeitsplatz
Practices unter anderem Service Request Management, IT Asset Management und Information Security Management
Prozess Ablauf zur Anlage eines Benutzerkontos
Arbeitsanweisung konkrete Schritte zur Kontoanlage im verwendeten Verzeichnisdienst

Merke

Das Value System beschreibt das große Ganze.

Der Value Stream beschreibt den Weg zu einem konkreten Outcome.

Eine Practice stellt Fähigkeiten bereit.

Eine Arbeitsanweisung beschreibt die konkrete Durchführung.

Praxisbeispiel: Ein neuer Mitarbeiter beginnt

Die Personalabteilung meldet einen neuen Mitarbeiter.

Nachfrage

Der Mitarbeiter benötigt zum Eintrittsdatum einen arbeitsfähigen IT-Arbeitsplatz.

Angestrebtes Outcome

Der Mitarbeiter kann sich anmelden und alle für seine Tätigkeit freigegebenen Services verwenden.

Guiding Principles

Governance

Value Stream

  1. Eintritt wird gemeldet.
  2. Aufgaben und benötigte Zugriffe werden bestimmt.
  3. Genehmigungen werden eingeholt.
  4. Benutzerkonto und Lizenzen werden bereitgestellt.
  5. Endgerät wird vorbereitet.
  6. Sicherheitsmaßnahmen werden eingerichtet.
  7. Zugriffe werden getestet.
  8. Gerät und Informationen werden übergeben.
  9. Arbeitsfähigkeit wird bestätigt.
  10. Asset- und Konfigurationsdaten werden aktualisiert.

Beteiligte Practices

Verbesserung

Nach jedem Onboarding kann geprüft werden:

Bedeutung für Fachinformatiker für Systemintegration

Ein Fachinformatiker arbeitet häufig innerhalb mehrerer Bestandteile des Value Systems.

Beispiele:

Tätigkeit Bezug zum Value System
Incident analysieren Value Stream und Incident Management
Firewall-Regel ändern Governance, Change Management und Information Security Management
Server dokumentieren Knowledge Management und Service Configuration Management
Monitoring-Alarm bearbeiten Monitoring and Event Management sowie Incident Management
neuen Arbeitsplatz bereitstellen Service Request Management, IT Asset Management und Value Stream
Backup testen Governance, Risikobehandlung und Continual Improvement
wiederkehrenden Fehler automatisieren Guiding Principles, Problem Management und Continual Improvement

Der einzelne Mitarbeiter steuert normalerweise nicht das gesamte Value System.

Er trägt jedoch durch seine:

zu dessen Wirksamkeit bei.

Wie du das Value System im Alltag verwendest

Bei einer neuen Aufgabe kannst du folgende Fragen stellen:

  1. Welche Nachfrage oder Chance liegt vor?
  2. Welches Outcome und welcher Wert werden erwartet?
  3. Welche Stakeholder sind beteiligt?
  4. Welche Guiding Principles helfen bei der Entscheidung?
  5. Welche Governance-Vorgaben gelten?
  6. Welcher Wertstrom wird durchlaufen?
  7. Welche Practices und Fähigkeiten werden benötigt?
  8. Welche Informationen und Technologien werden benötigt?
  9. Welche Risiken und Abhängigkeiten bestehen?
  10. Wie wird das Ergebnis überprüft?
  11. Was kann anschließend verbessert werden?

Diese Fragen müssen nicht in jedem kleinen Vorgang schriftlich beantwortet werden.

Sie unterstützen jedoch eine strukturierte und ganzheitliche Denkweise.

Anzeichen für ein schlecht abgestimmtes Value System

Mögliche Warnzeichen sind:

Ein einzelnes Warnzeichen beweist noch kein grundsätzlich unwirksames Value System.

Wiederholen sich mehrere dieser Muster, sollten Zusammenhänge und Schnittstellen untersucht werden.

Typische Fehler

Fehler 1: Nur einzelne Practices einführen

Eine Organisation führt Incident Management ein, ohne:

ausreichend einzubeziehen.

Das Ergebnis kann ein Ticketsystem mit vielen erfassten Incidents sein, ohne dass wiederkehrende Ursachen reduziert werden.

Fehler 2: Governance mit Bürokratie verwechseln

Governance soll Richtung, Verantwortlichkeit und Kontrolle sicherstellen.

Sie bedeutet nicht automatisch:

Kontrollen müssen zum Risiko und zum Kontext passen.

Fehler 3: Value Streams entlang von Abteilungen gestalten

Ein Wertstrom sollte dem Weg zum Outcome folgen.

Er sollte nicht künstlich an jeder Teamgrenze enden.

Fehler 4: Automatisieren, bevor der Ablauf verstanden wurde

Ein fehlerhafter oder unnötig komplexer Ablauf wird durch Automatisierung häufig nur schneller wiederholt.

Zuerst verstehen und optimieren, danach automatisieren.

Fehler 5: Verbesserung als einmaliges Projekt behandeln

Continual Improvement ist keine einmalige Aufräumaktion.

Es muss in die tägliche Arbeit und in alle Bestandteile des Value Systems integriert werden.

Fehler 6: Technische Outputs mit Wert gleichsetzen

Ein Server, Benutzerkonto oder Dashboard ist zunächst ein Output.

Wert entsteht erst, wenn Stakeholder damit benötigte Outcomes erreichen.

Checkliste zur Bewertung eines Value Systems

Schnellzusammenfassung

Bestandteil Kernfrage
Guiding Principles Wie sollten wir denken und entscheiden?
Governance Wer gibt Richtung vor und überwacht die Ergebnisse?
Value Chain Activities Welche operativen Tätigkeiten werden miteinander verbunden?
Management Practices Welche Fähigkeiten und Ressourcen werden benötigt?
Continual Improvement Wie werden Produkte, Services und Arbeitsweisen fortlaufend verbessert?

Gesamtfrage des Value Systems

Wie müssen alle Bestandteile der Organisation zusammenwirken, damit aus Chancen und Nachfrage nachhaltiger Wert entstehen kann?

Vereinfachte Darstellung

Chancen und Nachfrage
↓
Guiding Principles
Governance
Value Chain Activities
Management Practices
Continual Improvement
↓
digitale Produkte und Services
↓
Outcomes, Erfahrungen und gemeinsam ermöglichter Wert

Die Bestandteile wirken nicht ausschließlich nacheinander.

Sie bilden ein zusammenhängendes System mit Rückmeldungen, Abhängigkeiten und fortlaufenden Verbesserungen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die Aussagen zu den fünf Bestandteilen des ITIL Value Systems, zur Überführung von Chancen und Nachfrage in Wert sowie zur fortlaufenden Bedeutung von Continual Improvement wurden anhand der genannten offiziellen ITIL- und PeopleCert-Quellen geprüft.

Die konkreten Praxisbeispiele, Checklisten, Tabellen und vereinfachten Darstellungen sind zusätzliche Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine vorgeschriebenen ITIL-Prozesse dar.

Die öffentlich zugänglichen offiziellen Übersichtsseiten bestätigen für ITIL Version 5 eine vereinfachte Value Chain, veröffentlichen dort jedoch nicht alle Detaildarstellungen und Workflowdiagramme der offiziellen Foundation-Publikation. Deshalb werden an dieser Stelle keine nicht eindeutig öffentlich belegten Bezeichnungen einzelner neuer Value Chain Activities ergänzt.

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

2. ITIL verstehen – Aufbau, Prinzipien und Modelle

2.3 Die sieben Guiding Principles

Kurz erklärt

Die sieben Guiding Principles sind allgemeine Empfehlungen, die Entscheidungen und Handlungen im digitalen Produkt- und Service-Management unterstützen.

Sie können unabhängig davon angewendet werden:

Die Guiding Principles geben keine festen Arbeitsschritte vor. Sie helfen dabei, Situationen aus mehreren Perspektiven zu beurteilen und angemessene Entscheidungen zu treffen.

Die sieben Guiding Principles im Überblick

Nr. Guiding Principle Praktische Bedeutung
1 Focus on value Arbeit am tatsächlich benötigten Wert und Outcome ausrichten
2 Start where you are vorhandene Fähigkeiten, Informationen und funktionierende Bestandteile berücksichtigen
3 Progress iteratively with feedback in überschaubaren Schritten vorgehen und Rückmeldungen auswerten
4 Collaborate and promote visibility geeignete Beteiligte einbeziehen und relevante Informationen sichtbar machen
5 Think and work holistically Produkte, Services, Menschen, Technologien und Abhängigkeiten gemeinsam betrachten
6 Keep it simple and practical nur Schritte und Kontrollen verwenden, die einen erkennbaren Nutzen besitzen
7 Optimize and automate Arbeitsweisen zuerst verstehen und verbessern, anschließend sinnvoll automatisieren

Die englischen Bezeichnungen werden beibehalten, da sie in offiziellen ITIL-Unterlagen und in der internationalen Praxis verwendet werden.

Die deutschen Erläuterungen in diesem Buch sind sinngemäße Erklärungen und keine wörtlichen offiziellen Übersetzungen.

Fortführung in ITIL Version 5

ITIL Version 5 führt die Guiding Principles als Kernelement des ITIL Value Systems fort.

Sie stammen bereits aus ITIL 4 und bleiben relevant, weil sie keine produktspezifischen oder kurzlebigen technischen Anweisungen darstellen.

Die Prinzipien unterstützen vielmehr eine grundlegende Denkweise für:

ITIL Version 5 ergänzt den Anwendungskontext insbesondere um:

Merke

Die Guiding Principles geben Orientierung, wenn ein detaillierter Ablauf allein nicht ausreicht oder eine Situation mehrere mögliche Vorgehensweisen zulässt.

Die Guiding Principles sind keine Prozessschritte

Die sieben Prinzipien bilden keine Reihenfolge, die von Nummer 1 bis Nummer 7 abgearbeitet werden muss.

Sie können:

Beispiel:

Eine Organisation möchte die Bereitstellung neuer Benutzerkonten automatisieren.

Dabei können gleichzeitig folgende Prinzipien relevant sein:

Typischer Fehler

Nur das Prinzip auszuwählen, das die bereits bevorzugte Entscheidung unterstützt.

Eine gute Entscheidung berücksichtigt alle relevanten Guiding Principles und mögliche Zielkonflikte.

1. Focus on value

Sinngemäße Bedeutung

Jede Tätigkeit sollte einen nachvollziehbaren Beitrag zum Wert für relevante Stakeholder leisten.

Wert entsteht nicht allein dadurch, dass eine technische Aufgabe abgeschlossen wurde.

Entscheidend ist, ob das benötigte Outcome erreicht und von den beteiligten Stakeholdern als nützlich wahrgenommen wird.

Mögliche Stakeholder sind beispielsweise:

Wert kann sich unter anderem zeigen durch:

Leitfragen zu Focus on value

Praxisbeispiel: Backup

Ein Backup-System meldet jeden Tag einen erfolgreichen Sicherungslauf.

Der technische Output lautet:

Die Sicherungsdaten wurden erzeugt.

Der angestrebte Wert besteht jedoch darin, dass:

Um den tatsächlichen Wert zu beurteilen, müssen deshalb zusätzlich geprüft werden:

Merke

Ein erfolgreich ausgeführter Sicherungslauf ist ein Output.

Wiederherstellbare und ausreichend geschützte Daten ermöglichen das benötigte Outcome.

Typische Fehler bei Focus on value

Bedeutung für Systemintegratoren

Vor einer technischen Maßnahme sollte nicht nur gefragt werden:

Wie führe ich diese Aufgabe aus?

Zusätzlich sollte gefragt werden:

Warum wird diese Aufgabe durchgeführt und welches Ergebnis soll sie ermöglichen?

Beispiele:

Technische Aufgabe Wertorientierte Frage
Server neu starten Welcher Service soll dadurch wiederhergestellt werden?
neue Firewall-Regel einrichten Welcher notwendige Zugriff wird ermöglicht und welches Risiko entsteht?
Monitoring-Alarm anlegen Welche relevante Störung soll dadurch früher erkannt werden?
Benutzerkonto erstellen Welche Arbeitsfähigkeit muss zum vorgesehenen Zeitpunkt bestehen?
Anwendung aktualisieren Welcher Nutzen entsteht und welche Risiken werden reduziert?

2. Start where you are

Sinngemäße Bedeutung

Bevor etwas vollständig neu aufgebaut wird, sollen der aktuelle Zustand, vorhandene Fähigkeiten und bereits funktionierende Bestandteile untersucht werden.

Ein bestehender Zustand ist selten vollständig schlecht oder vollständig gut.

Auch in einer unzureichenden Arbeitsweise können bereits wertvolle Bestandteile vorhanden sein, beispielsweise:

Diese Bestandteile sollten erkannt und sinnvoll weiterverwendet werden.

Wichtig

Start where you are bedeutet nicht, dass der vorhandene Zustand unverändert bleiben muss.

Es bedeutet, dass Entscheidungen auf einer realistischen Bewertung des aktuellen Zustands beruhen sollen.

Leitfragen zu Start where you are

Praxisbeispiel: neues Ticketsystem

Eine Organisation möchte ein neues Ticketsystem einführen.

Eine ungeprüfte Vorgehensweise wäre:

  1. neues Produkt auswählen
  2. bestehende Daten vollständig verwerfen
  3. neue Kategorien entwerfen
  4. alle Abläufe gleichzeitig umstellen

Die Anwendung von Start where you are führt zunächst zu einer Bestandsaufnahme:

Dadurch wird verhindert, dass funktionierende Bestandteile unnötig ersetzt oder bekannte Fehler in das neue System übernommen werden.

Beobachten statt nur vermuten

Eine Bestandsaufnahme sollte nach Möglichkeit auf überprüfbaren Informationen beruhen.

Geeignete Informationsquellen können sein:

Typischer Fehler

Eine Arbeitsweise wird allein anhand ihrer Dokumentation bewertet.

Der tatsächlich gelebte Ablauf kann deutlich von der beschriebenen Vorgehensweise abweichen.

Bedeutung für Systemintegratoren

Bei einer Störung sollte nicht sofort davon ausgegangen werden, dass:

Zuerst sollte geprüft werden:

3. Progress iteratively with feedback

Sinngemäße Bedeutung

Große Vorhaben sollen nach Möglichkeit in überschaubare Schritte unterteilt werden. Nach jedem geeigneten Schritt werden Ergebnisse und Rückmeldungen ausgewertet.

Kleine, kontrollierbare Schritte können dazu beitragen:

Iteration bedeutet nicht, ohne Ziel immer wieder dasselbe zu versuchen.

Eine Iteration benötigt:

Leitfragen zu Progress iteratively with feedback

Praxisbeispiel: Einführung einer Monitoring-Plattform

Statt sofort alle Systeme zu überwachen, kann eine Organisation schrittweise vorgehen.

Erste Iteration

Feedback auswerten

Nächste Iteration

Merke

Eine kleine Iteration sollte nicht nur Arbeit erzeugen.

Sie sollte ein verwertbares Ergebnis oder neues Wissen liefern.

Feedback richtig verwenden

Feedback kann aus unterschiedlichen Quellen stammen:

Feedback ist nicht automatisch eine Anweisung.

Es muss bewertet werden hinsichtlich:

Typischer Fehler

Feedback wird erst am Ende eines umfangreichen Vorhabens eingeholt.

Dann können grundlegende Fehlentscheidungen bereits hohe Kosten verursacht haben.

Bedeutung für Änderungen

Bei einer größeren technischen Änderung kann ein iteratives Vorgehen beispielsweise bedeuten:

  1. Testumgebung verwenden
  2. begrenzte Pilotgruppe auswählen
  3. technische und servicebezogene Ergebnisse prüfen
  4. Rückmeldungen auswerten
  5. Konfiguration anpassen
  6. kontrolliert auf weitere Systeme ausweiten
  7. nach jeder Stufe überwachen

Ein iteratives Vorgehen ist nicht immer möglich.

Bei akuten Sicherheitsrisiken, gesetzlichen Fristen oder kritischen Störungen kann schnelles umfassendes Handeln notwendig sein.

Auch dann sollten Ergebnisse und Rückmeldungen so früh wie möglich ausgewertet werden.

4. Collaborate and promote visibility

Sinngemäße Bedeutung

Geeignete Personen und Teams sollen zusammenarbeiten. Relevante Informationen, Entscheidungen, Risiken und Fortschritte müssen für die zuständigen Beteiligten sichtbar sein.

Zusammenarbeit bedeutet nicht, jede Person an jeder Entscheidung zu beteiligen.

Zu viele Beteiligte können:

Entscheidend ist, die richtigen Beteiligten zum richtigen Zeitpunkt mit den richtigen Informationen einzubeziehen.

Leitfragen zu Collaborate and promote visibility

Praxisbeispiel: Änderung einer Firewall-Regel

Eine Fachabteilung benötigt eine neue Verbindung zu einem externen Dienst.

Mögliche Beteiligte sind:

Sichtbar sein sollten unter anderem:

Merke

Sichtbarkeit bedeutet nicht, dass jede Information öffentlich sein muss.

Relevante Informationen müssen für die berechtigten und verantwortlichen Beteiligten zugänglich sein.

Warum Sichtbarkeit wichtig ist

Fehlende Sichtbarkeit kann dazu führen, dass:

Geeignete Formen der Sichtbarkeit können sein:

Zusammenarbeit und Verantwortung

Zusammenarbeit ersetzt keine eindeutige Verantwortung.

Auch bei gemeinsamer Bearbeitung muss erkennbar bleiben:

Typischer Fehler

Viele Personen werden informiert, aber niemand besitzt eine eindeutige Verantwortung für den nächsten Schritt.

5. Think and work holistically

Sinngemäße Bedeutung

Produkte, Services, Organisationen und ihre Bestandteile sollen als zusammenhängendes System betrachtet werden.

Ein Service hängt selten nur von einer einzelnen technischen Komponente ab.

Zu berücksichtigen sind unter anderem:

Die vier Dimensionen des Produkt- und Service-Managements unterstützen diese ganzheitliche Betrachtung.

Leitfragen zu Think and work holistically

Praxisbeispiel: Benutzeranmeldung funktioniert nicht

Mögliche technische Abhängigkeiten:

Mögliche organisatorische Abhängigkeiten:

Eine ausschließlich auf das Benutzerkennwort beschränkte Betrachtung kann deshalb zu kurz greifen.

Lokale Optimierung vermeiden

Ein einzelnes Team kann seine eigene Kennzahl verbessern und gleichzeitig den gesamten Wertstrom verschlechtern.

Beispiel:

Der Service Desk verkürzt seine durchschnittliche Bearbeitungszeit, indem komplexe Tickets möglichst schnell an andere Teams weitergegeben werden.

Die lokale Kennzahl verbessert sich.

Für den Benutzer können jedoch entstehen:

Merke

Eine lokale Verbesserung ist nur dann hilfreich, wenn sie den gesamten Wertstrom und das benötigte Outcome unterstützt.

Bedeutung für technische Änderungen

Vor dem Austausch einer technischen Komponente sollte geprüft werden:

6. Keep it simple and practical

Sinngemäße Bedeutung

Arbeitsweisen, Kontrollen und Lösungen sollen so einfach wie möglich und so umfangreich wie tatsächlich notwendig gestaltet werden.

Einfach bedeutet nicht:

Einfach bedeutet:

Jeder zusätzliche Schritt, jedes Pflichtfeld und jede Genehmigung sollte einen nachvollziehbaren Zweck besitzen.

Leitfragen zu Keep it simple and practical

Praxisbeispiel: Change-Dokumentation

Für einen Change werden 35 Pflichtfelder verlangt.

In der Praxis werden viele Felder:

gefüllt.

Die umfangreiche Dokumentation erzeugt dadurch keine zusätzliche Sicherheit.

Eine zweckmäßige Struktur könnte sich stattdessen auf tatsächlich notwendige Informationen konzentrieren:

Typischer Fehler

Umfang wird mit Qualität verwechselt.

Eine längere Arbeitsanweisung ist nicht automatisch verständlicher oder sicherer.

Angemessene Kontrolle statt identischer Kontrolle

Nicht jede Änderung besitzt dasselbe Risiko.

Beispiele:

Änderung Möglicher Kontrollumfang
dokumentierte, häufig ausgeführte Standardänderung vereinfachter und vorab autorisierter Ablauf
normale Änderung mit überschaubarem Risiko angemessene Bewertung und Freigabe
kritische Änderung an zentraler Infrastruktur umfangreichere Prüfung, Abstimmung und Rückfallplanung
dringende Änderung zur Behebung einer akuten Gefahr beschleunigtes Verfahren mit nachträglicher Kontrolle

Die konkrete Organisation legt die Change-Modelle, Freigaben und Risikokriterien fest.

Merke

Einfachheit entsteht nicht dadurch, notwendige Kontrollen wegzulassen.

Sie entsteht durch passende Kontrollen ohne unnötige Schritte.

7. Optimize and automate

Sinngemäße Bedeutung

Arbeit soll zunächst verstanden und verbessert werden. Anschließend können geeignete Bestandteile automatisiert werden.

Automatisierung kann unter anderem:

Automatisierung kann jedoch auch:

Grundsatz

Nicht alles, was technisch automatisierbar ist, sollte automatisiert werden.

Leitfragen zu Optimize and automate

Optimierung vor Automatisierung

Eine geeignete Reihenfolge ist:

  1. Outcome und Zweck verstehen
  2. aktuellen Ablauf erfassen
  3. unnötige Schritte entfernen
  4. Übergaben und Abhängigkeiten verbessern
  5. Ablauf vereinheitlichen
  6. geeignete Tätigkeiten automatisieren
  7. Ergebnisse überwachen
  8. Automatisierung fortlaufend verbessern

Typischer Fehler

Ein fehlerhafter oder unnötig komplexer Ablauf wird unverändert automatisiert.

Das Ergebnis ist ein schnellerer fehlerhafter Ablauf.

Praxisbeispiel: automatische Benutzeranlage

Geeignete Automatisierungen können sein:

Nicht vollständig automatisiert werden sollten möglicherweise:

Die Automatisierung muss zusätzlich kontrollieren:

Automatisierung und künstliche Intelligenz

ITIL Version 5 berücksichtigt digitale und KI-gestützte Arbeitsumgebungen stärker.

Auch beim Einsatz von KI bleiben die Guiding Principles relevant.

Vor einer KI-gestützten Automatisierung sollte unter anderem geprüft werden:

Sicherheitsrelevant

Eine automatisierte oder KI-generierte Entscheidung entbindet die Organisation nicht von Verantwortung, Kontrolle und Risikobewertung.

Zusammenspiel der sieben Guiding Principles

Die Prinzipien entfalten ihren größten Nutzen, wenn sie gemeinsam betrachtet werden.

Beispiel: Ablösung eines alten Fileservers

Focus on value

Start where you are

Progress iteratively with feedback

Collaborate and promote visibility

Think and work holistically

Keep it simple and practical

Optimize and automate

Mögliche Spannungen zwischen den Prinzipien

Die Guiding Principles liefern nicht immer automatisch dieselbe Handlungsrichtung.

Beispiele:

Mögliche Spannung Notwendige Abwägung
schnell iterieren oder ganzheitlich analysieren ausreichend prüfen, ohne jede denkbare Frage vor dem ersten Schritt lösen zu wollen
einfach halten oder zusätzliche Kontrollen einführen Kontrollaufwand am tatsächlichen Risiko ausrichten
Zusammenarbeit fördern oder schnell entscheiden notwendige Beteiligte einbeziehen, aber Verantwortung eindeutig lassen
automatisieren oder flexibel bleiben nur stabile und ausreichend verstandene Teile automatisieren
Bestehendes nutzen oder neu aufbauen Nutzen, technische Schulden, Risiken und Migrationsaufwand vergleichen
kurzfristigen Wert oder langfristige Nachhaltigkeit priorisieren unmittelbare Outcomes und langfristige Folgen gemeinsam bewerten

Merke

Die Guiding Principles ersetzen keine fachliche Abwägung.

Sie verbessern die Qualität der Fragen, auf deren Grundlage entschieden wird.

Guiding Principles bei einem Incident

Auch bei einer laufenden Störung können die Prinzipien helfen.

Guiding Principle Anwendung im Incident
Focus on value zuerst die für Benutzer wichtigste Servicefunktion wiederherstellen
Start where you are vorhandene Monitoring-Daten, bekannte Fehler und letzte Changes prüfen
Progress iteratively with feedback Maßnahmen kontrolliert durchführen und Ergebnis nach jedem Schritt prüfen
Collaborate and promote visibility zuständige Teams einbinden und aktuellen Status sichtbar halten
Think and work holistically Serviceabhängigkeiten und mögliche Folgeauswirkungen berücksichtigen
Keep it simple and practical zunächst die sicherste geeignete Wiederherstellung wählen
Optimize and automate nach dem Incident wiederkehrende Diagnose- oder Wiederherstellungsschritte verbessern

Während eines kritischen Incidents steht zunächst die sichere und angemessene Wiederherstellung im Vordergrund.

Die umfassende Ursachenanalyse und nachhaltige Verbesserung können anschließend folgen.

Guiding Principles bei einem Change

Guiding Principle Anwendung beim Change
Focus on value Zweck, Outcome und Nutzen des Changes klären
Start where you are aktuellen Zustand und vorhandene Konfiguration erfassen
Progress iteratively with feedback Test, Pilot oder schrittweise Einführung verwenden
Collaborate and promote visibility Betroffene, Verantwortliche und Abhängigkeiten sichtbar machen
Think and work holistically Auswirkungen auf Produkte, Services, Sicherheit und Lieferanten betrachten
Keep it simple and practical angemessenen Kontrollumfang wählen
Optimize and automate standardisierbare Prüfung und Umsetzung verbessern

Bedeutung für Fachinformatiker für Systemintegration

Die Guiding Principles helfen bei technischen und organisatorischen Entscheidungen.

Beispiele:

Ein Fachinformatiker muss die englischen Bezeichnungen nicht in jedem Ticket dokumentieren.

Die zugrunde liegenden Fragen sollten jedoch Teil der professionellen Arbeitsweise werden.

Entscheidungshilfe für neue Aufgaben

Bei einer neuen Aufgabe kannst du die sieben Prinzipien als Kurzprüfung verwenden:

  1. Wert: Welches Outcome soll erreicht werden?
  2. Ausgangslage: Was ist bereits vorhanden und funktionsfähig?
  3. Schritte: Kann kontrolliert und iterativ vorgegangen werden?
  4. Zusammenarbeit: Wer muss beteiligt und informiert werden?
  5. Gesamtsicht: Welche Abhängigkeiten und Auswirkungen bestehen?
  6. Einfachheit: Welche Schritte sind tatsächlich erforderlich?
  7. Optimierung: Was kann verbessert und anschließend automatisiert werden?

Checkliste zur Anwendung der Guiding Principles

Typische Fehlanwendungen

Nur ein Prinzip verwenden

Ein Team beruft sich ausschließlich auf Keep it simple and practical, um notwendige Sicherheitskontrollen wegzulassen.

Richtig wäre, zusätzlich:

zu berücksichtigen.

Start where you are mit Stillstand verwechseln

Der aktuelle Zustand wird nicht verbessert, weil er bereits lange besteht.

Das Prinzip verlangt jedoch eine Bestandsaufnahme, keine unveränderte Fortführung.

Iterationen ohne klares Ziel durchführen

Es werden regelmäßig kleine Änderungen vorgenommen, aber weder Outcome noch Erfolgskriterien sind definiert.

Iteration benötigt Ziel, Feedback und Auswertung.

Sichtbarkeit mit Informationsüberlastung verwechseln

Alle Beteiligten erhalten jede technische Einzelmeldung.

Dadurch gehen relevante Informationen in der Menge unter.

Sichtbarkeit muss zielgruppengerecht und handlungsorientiert sein.

Ganzheitliche Betrachtung als endlose Analyse verwenden

Eine Organisation untersucht jede denkbare Auswirkung und beginnt deshalb nie mit der Umsetzung.

Ganzheitlich denken schließt ein iteratives und pragmatisches Vorgehen nicht aus.

Einfachheit mit fehlender Sorgfalt verwechseln

Dokumentation, Tests oder Rückfallplanung werden weggelassen.

Einfachheit darf notwendige Sicherheit und Nachvollziehbarkeit nicht beseitigen.

Automatisierung als Selbstzweck betrachten

Eine Tätigkeit wird automatisiert, weil die technische Möglichkeit besteht.

Der tatsächliche Nutzen, die Wartung und mögliche Risiken werden nicht bewertet.

Schnellreferenz

Principle Kurzfrage
Focus on value Welchen Wert und welches Outcome ermöglicht die Tätigkeit?
Start where you are Was ist bereits vorhanden und funktioniert?
Progress iteratively with feedback Was ist der nächste kontrollierbare Schritt?
Collaborate and promote visibility Wer muss beteiligt sein und was muss sichtbar werden?
Think and work holistically Welche Zusammenhänge und Abhängigkeiten bestehen?
Keep it simple and practical Was ist tatsächlich notwendig?
Optimize and automate Was kann zuerst verbessert und danach automatisiert werden?

Zusammenfassende Darstellung

Focus on value
Ziel und Outcome verstehen
↓
Start where you are
tatsächlichen Ausgangszustand prüfen
↓
Progress iteratively with feedback
kontrolliert vorgehen und lernen
↓
Collaborate and promote visibility
geeignete Beteiligte und Informationen verbinden
↓
Think and work holistically
das gesamte System berücksichtigen
↓
Keep it simple and practical
unnötige Komplexität vermeiden
↓
Optimize and automate
verbessern, automatisieren und überwachen

Diese Darstellung dient nur als Lernhilfe.

Die Guiding Principles bilden keine verbindliche Reihenfolge und können gleichzeitig angewendet werden.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die offiziellen ITIL-Version-5-Übersichten bestätigen, dass die Guiding Principles weiterhin ein Kernelement des ITIL Value Systems und der praktischen Entscheidungsfindung sind.

Die sieben Guiding Principles werden aus ITIL 4 fortgeführt:

Die deutschen Erklärungen, Leitfragen, Praxisbeispiele, Tabellen und Checklisten auf dieser Seite sind eigene sinngemäße Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine vorgeschriebenen ITIL-Prozesse dar.

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

2. ITIL verstehen – Aufbau, Prinzipien und Modelle

2.4 Governance und Verantwortlichkeit

Kurz erklärt

Governance beschreibt, wie eine Organisation gelenkt und kontrolliert wird.

Sie sorgt dafür, dass:

Im ITIL Value System wird Governance durch drei grundlegende Aktivitäten verwirklicht:

  1. Evaluate – bewerten
  2. Direct – Richtung vorgeben
  3. Monitor – überwachen

Warum Governance notwendig ist

Digitale Produkte und Services beeinflussen heute häufig:

Technische Entscheidungen können deshalb weitreichende organisatorische Folgen besitzen.

Beispiele:

Ohne klare Governance können unter anderem folgende Probleme entstehen:

Merke

Governance soll nicht jede technische Einzelentscheidung zentralisieren.

Sie schafft den Rahmen, innerhalb dessen angemessene Entscheidungen getroffen und kontrolliert werden können.

Governance im ITIL Value System

Governance ist einer der fünf Bestandteile des ITIL Value Systems.

Das Value System verbindet:

Governance stellt dabei sicher, dass die Tätigkeiten der Organisation:

Governance wirkt damit auf:

Wichtig

Governance ist kein einzelner Prozess und keine einzelne Management Practice.

Sie ist ein übergreifender Bestandteil des gesamten ITIL Value Systems.

Die drei Governance-Aktivitäten

Governance wird durch drei grundlegende Aktivitäten verwirklicht:

Aktivität Bedeutung Zentrale Frage
Evaluate Bedürfnisse, Optionen, Leistung, Risiken und Rahmenbedingungen bewerten Was ist notwendig und welche Entscheidung ist angemessen?
Direct Richtung, Prioritäten, Grundsätze und Entscheidungsrahmen vorgeben Was soll erreicht werden und innerhalb welcher Grenzen?
Monitor Leistung, Ergebnisse, Risiken und Einhaltung überwachen Erreichen wir die Ziele und werden die Vorgaben eingehalten?

Diese Aktivitäten sind miteinander verbunden.

Die Ergebnisse des Monitorings können eine erneute Bewertung auslösen.

Aus einer neuen Bewertung können wiederum geänderte Vorgaben oder Prioritäten entstehen.

Vereinfachter Kreislauf

Evaluate
↓
Direct
↓
Monitor
↓
neue Erkenntnisse
↓
erneut Evaluate

Evaluate – bewerten

Bei Evaluate werden die aktuelle Situation, Bedürfnisse, Möglichkeiten und Risiken untersucht.

Mögliche Bewertungsgegenstände sind:

Beispiel:

Eine Organisation prüft, ob eine zentrale Cloud-Plattform eingeführt werden soll.

Bei der Bewertung können unter anderem folgende Fragen relevant sein:

Typischer Fehler

Eine Entscheidung wird ausschließlich anhand des Anschaffungspreises oder einzelner technischer Funktionen bewertet.

Betrieb, Support, Integration, Sicherheit, Abhängigkeiten und spätere Ablösung werden nicht berücksichtigt.

Evaluate bedeutet nicht nur einmalig prüfen

Bewertung findet nicht ausschließlich vor einer Einführung statt.

Eine erneute Bewertung kann notwendig sein, wenn:

Beispiel:

Eine Anwendung wurde ursprünglich nur für eine kleine interne Abteilung eingeführt.

Später wird sie für einen unternehmenskritischen Prozess eingesetzt.

Dadurch können sich ändern:

Die ursprüngliche Bewertung reicht dann möglicherweise nicht mehr aus.

Direct – Richtung vorgeben

Bei Direct werden Richtung, Prioritäten und Rahmenbedingungen vorgegeben.

Dies kann beispielsweise erfolgen durch:

Beispiele:

Governance gibt dabei normalerweise nicht jeden technischen Einzelschritt vor.

Beispiel:

Governance kann festlegen:

Administrative Zugriffe müssen mit einer starken Mehrfaktor-Authentifizierung geschützt werden.

Das zuständige Management und die Fachteams bestimmen anschließend:

Richtung und Grenzen

Eine gute Governance-Vorgabe beantwortet möglichst:

Unklare Vorgabe:

Systeme müssen sicher sein.

Präzisere Vorgabe:

Kritische Systeme müssen entsprechend der festgelegten Schutzbedarfs- und Risikobewertung abgesichert, überwacht und regelmäßig auf die Wirksamkeit ihrer Kontrollen geprüft werden.

Die konkrete technische Umsetzung wird anschließend durch zuständige Fachkräfte und Management Practices gestaltet.

Monitor – überwachen

Bei Monitor wird geprüft, ob:

Monitoring im Governance-Kontext bedeutet mehr als technische Überwachung.

Es kann unter anderem umfassen:

Beispiel:

Eine Organisation verlangt regelmäßige Wiederherstellungstests.

Governance-Monitoring prüft nicht nur, ob ein Testtermin im Kalender stand.

Es prüft beispielsweise:

Merke

Aktivität ist nicht automatisch Wirksamkeit.

Ein ausgefülltes Kontrollformular beweist noch nicht, dass das gewünschte Ergebnis erreicht wurde.

Governance und Management unterscheiden

Governance und Management sind eng miteinander verbunden, aber nicht identisch.

Governance Management
bewertet Bedürfnisse, Erwartungen und Rahmenbedingungen plant und organisiert die praktische Umsetzung
gibt Richtung und Grenzen vor weist Ressourcen und Aufgaben zu
legt Verantwortlichkeit und Entscheidungsbefugnisse fest koordiniert Teams, Practices und Arbeitsabläufe
überwacht Outcomes, Risiken und Regelkonformität überwacht die laufende Ausführung
entscheidet über grundlegende Prioritäten trifft operative und taktische Entscheidungen innerhalb des Rahmens
stellt Rechenschaftspflicht sicher liefert Ergebnisse und berichtet darüber

Vereinfacht:

Governance

Bestimmt, was erreicht und kontrolliert werden muss.

Management

Organisiert, wie dies innerhalb des vorgegebenen Rahmens umgesetzt wird.

Diese Trennung bedeutet nicht, dass Governance nur die Unternehmensleitung betrifft.

Auch nachgelagerte Gremien oder Rollen können delegierte Governance-Aufgaben wahrnehmen.

Die grundlegende Rechenschaftspflicht muss jedoch eindeutig bleiben.

Beispiel: Einführung von Multi-Faktor-Authentifizierung

Governance

Management

Technische Umsetzung

Alle drei Ebenen sind notwendig.

Eine technisch erfolgreiche Konfiguration allein beweist noch nicht, dass:

Verantwortung und Verantwortlichkeit

Im Deutschen wird der Begriff Verantwortung häufig für unterschiedliche Sachverhalte verwendet.

Für eine klare Rollenverteilung ist die Unterscheidung hilfreich zwischen:

Begriff Bedeutung
Ausführungsverantwortung eine Person oder Rolle führt eine Aufgabe aus
Entscheidungsverantwortung eine Person oder Rolle besitzt die Befugnis, eine Entscheidung zu treffen
Ergebnisverantwortung eine Person oder Rolle steht für das erreichte Ergebnis ein
Rechenschaftspflicht eine Person oder ein Gremium muss Entscheidungen und Ergebnisse erklären und vertreten
Beratung Fachwissen wird eingebracht, ohne selbst die endgültige Entscheidung zu treffen
Informationsbedarf eine Person oder Rolle muss über Entscheidung oder Ergebnis informiert werden

Eine Person kann eine Aufgabe ausführen, ohne die endgültige Entscheidungs- oder Ergebnisverantwortung zu besitzen.

Beispiel:

Ein Systemadministrator setzt eine freigegebene Firewall-Regel um.

Typischer Fehler

Die Person, die eine technische Änderung ausführt, wird automatisch für sämtliche geschäftlichen, rechtlichen und organisatorischen Entscheidungen verantwortlich gemacht.

Verantwortung muss eindeutig sein

Bei wichtigen Produkten, Services und Entscheidungen sollte erkennbar sein:

Unklare Verantwortung kann zu folgenden Situationen führen:

Praxistipp

Kann bei einer kritischen Aufgabe niemand eindeutig benennen, wer entscheidet und wer für das Ergebnis einsteht, besteht ein Governance- und Verantwortlichkeitsproblem.

Delegation und Rechenschaftspflicht

Aufgaben und Entscheidungsbefugnisse können delegiert werden.

Eine sinnvolle Delegation benötigt:

Beispiel:

Ein Betriebsteam darf bestimmte dokumentierte Standardänderungen selbstständig durchführen.

Die Delegation kann festlegen:

Wichtig

Delegation bedeutet nicht, dass keine Kontrolle mehr erforderlich ist.

Sie soll Entscheidungen dort ermöglichen, wo ausreichendes Wissen vorhanden ist und das Risiko angemessen beherrscht werden kann.

Entscheidungsbefugnisse

Entscheidungsbefugnisse sollten zum Risiko und zur Bedeutung einer Entscheidung passen.

Mögliche Entscheidungsbereiche sind:

Eine Entscheidungsbefugnis sollte möglichst beantworten:

Beispiel:

Ein Administrator darf einen abgestürzten Dienst nach einer dokumentierten Arbeitsanweisung neu starten.

Er darf möglicherweise nicht ohne zusätzliche Autorisierung:

Autorisierung nach Risiko und Kontext

Nicht jede Entscheidung benötigt denselben Freigabeumfang.

Situation Mögliche Behandlung
häufige, dokumentierte und risikoarme Standardtätigkeit delegierte oder vorab autorisierte Ausführung
normale Änderung mit überschaubarem Risiko Bewertung und Autorisierung durch zuständige Rolle
komplexe Änderung an kritischem Service erweiterte fachliche, technische und geschäftliche Bewertung
dringende Sicherheitsmaßnahme beschleunigtes Verfahren mit klarer Befugnis und nachträglicher Kontrolle
grundlegende strategische Änderung Entscheidung durch entsprechend befugtes Governance-Gremium

Die konkrete Organisation legt fest:

Typischer Fehler

Jede Änderung muss dieselben umfangreichen Genehmigungsstufen durchlaufen.

Dadurch werden risikoarme Tätigkeiten unnötig verzögert, während kritische Entscheidungen möglicherweise trotzdem nicht ausreichend fachlich bewertet werden.

Governance ist mehr als Genehmigung

Governance wird häufig fälschlich auf Freigaben reduziert.

Eine Freigabe beantwortet lediglich eine begrenzte Frage:

Darf diese konkrete Handlung innerhalb des festgelegten Rahmens durchgeführt werden?

Governance umfasst zusätzlich:

Ein Change kann formal genehmigt sein und dennoch schlecht gesteuert werden, wenn:

Richtlinien, Standards und Arbeitsanweisungen unterscheiden

Governance-Vorgaben können auf unterschiedlichen Ebenen konkretisiert werden.

Dokumentenart Zweck Beispiel
Grundsatz oder Policy legt Ziel, Richtung und verbindliche Erwartungen fest administrative Zugriffe müssen angemessen geschützt werden
Standard legt verbindliche einheitliche Anforderungen fest zugelassene MFA-Verfahren und Mindestanforderungen
Prozess oder Ablauf beschreibt zusammenhängende Aktivitäten und Verantwortlichkeiten Beantragung und Freigabe eines administrativen Zugriffs
Verfahren beschreibt eine festgelegte Vorgehensweise Registrierung eines neuen MFA-Geräts
Arbeitsanweisung beschreibt konkrete Ausführungsschritte Menü- und Konfigurationsschritte im Identitätssystem
Checkliste unterstützt die Kontrolle wichtiger Punkte Prüfung eines neuen administrativen Kontos

Nicht jede Organisation verwendet exakt diese Bezeichnungen.

Entscheidend ist, dass:

eindeutig sind.

Beispiel: Backup-Governance

Governance-Vorgabe

Geschäftskritische Daten und Systeme müssen entsprechend ihrer Kritikalität gesichert und innerhalb definierter Ziele wiederhergestellt werden können.

Mögliche Standards

Management

Technische Umsetzung

Governance-Monitoring

Risikobereitschaft und Risikotoleranz

Governance legt fest, welche Risiken:

werden.

Die Organisation kann dafür Risikogrenzen definieren.

Beispiele:

Ein technisches Team sollte verbleibende erhebliche Risiken nicht ohne entsprechende Befugnis selbst akzeptieren.

Beispiel:

Ein Administrator stellt fest, dass ein veraltetes System keine Sicherheitsupdates mehr erhält.

Er kann:

Die Entscheidung, ein erhebliches Restrisiko langfristig zu akzeptieren, benötigt eine entsprechend befugte Rolle.

Merke

Risikoanalyse kann durch Fachkräfte erfolgen.

Risikoakzeptanz muss durch eine dafür autorisierte Stelle erfolgen.

Kontrollen

Eine Kontrolle soll ein Risiko reduzieren, eine Vorgabe sicherstellen oder eine Abweichung erkennbar machen.

Kontrollen können sein:

Kontrollart Beispiel
Vorbeugend MFA verhindert Anmeldung nur mit Kennwort
Erkennend Monitoring erkennt abgelaufenes Zertifikat
Korrigierend dokumentiertes Wiederherstellungsverfahren
Manuell Vier-Augen-Prüfung einer kritischen Änderung
Automatisiert Richtlinie blockiert unsichere Konfiguration
Organisatorisch Funktionstrennung zwischen Beantragung und Genehmigung

Eine Kontrolle sollte hinsichtlich ihrer Wirksamkeit bewertet werden.

Fragen dazu:

Messgrößen und Governance

Governance benötigt Informationen, um Leistung und Risiken bewerten zu können.

Kennzahlen sollten jedoch nicht isoliert betrachtet werden.

Beispiel:

98 Prozent aller Tickets wurden innerhalb der Zielzeit geschlossen.

Diese Zahl beantwortet nicht automatisch:

Geeignete Governance-Informationen können umfassen:

Typischer Fehler

Eine einzelne leicht messbare Kennzahl wird zum alleinigen Steuerungsziel.

Mitarbeiter optimieren anschließend die Kennzahl, ohne den tatsächlichen Wert zu verbessern.

Verantwortlichkeit für Produkte und Services

Für wichtige Produkte und Services sollten Verantwortlichkeiten geklärt sein.

Mögliche Rollen können sein:

ITIL schreibt nicht für jede Organisation dieselben Rollenbezeichnungen oder Organisationsstrukturen vor.

Entscheidend ist, dass folgende Fragen beantwortet werden:

Wichtig

Eine Rollenbezeichnung allein schafft noch keine wirksame Verantwortung.

Die Rolle benötigt Befugnisse, Informationen, Fähigkeiten und Ressourcen.

Service Owner und technische Verantwortung unterscheiden

Ein Service Owner betrachtet den Service normalerweise aus einer Ende-zu-Ende-Perspektive.

Technische Verantwortliche betreuen dagegen möglicherweise einzelne Bestandteile.

Beispiel: E-Mail-Service

Verantwortungsbereich Mögliche Zuständigkeit
gesamter E-Mail-Service Service Owner
Identitätsplattform Identity-Team
DNS Netzwerk- oder Infrastrukturteam
Mailplattform Messaging-Team oder Cloud-Provider
Endgeräte und Client Workplace-Team
Sicherheitsanforderungen Informationssicherheit
Lieferantenvertrag Supplier Management oder Einkauf
Benutzerunterstützung Service Desk

Der Service Owner muss nicht jede technische Tätigkeit selbst ausführen.

Er benötigt jedoch ausreichende Informationen, um:

RACI als mögliches Hilfsmittel

Eine RACI-Matrix kann helfen, Rollen bei einer Tätigkeit zu klären.

Kürzel Bedeutung
R – Responsible führt die Aufgabe aus
A – Accountable steht für das Ergebnis ein und besitzt die übergeordnete Verantwortlichkeit
C – Consulted wird vor oder während der Entscheidung fachlich einbezogen
I – Informed wird über Entscheidung oder Ergebnis informiert

Beispiel: produktive Firewall-Änderung

Rolle Zuordnung
Netzwerkadministrator Responsible
autorisierte Change- oder Service-Rolle Accountable
Informationssicherheit und Anwendungsverantwortlicher Consulted
Service Desk und betroffene Benutzergruppen Informed

Eine RACI-Matrix ist ein mögliches Organisationswerkzeug und keine zwingend vorgeschriebene ITIL-Darstellung.

Bei der Verwendung sollte vermieden werden:

Eskalation

Eskalation ist notwendig, wenn:

Eskalation bedeutet nicht automatisch persönliches Versagen.

Sie ist ein vorgesehener Mechanismus, um Entscheidungen an die geeignete Verantwortungs- und Befugnisebene zu übergeben.

Praxistipp

Eine gute Eskalation enthält:

Ungeeignete Eskalation:

Das System funktioniert nicht. Bitte entscheiden.

Besser:

Der zentrale Dateiservice ist seit 09:10 Uhr für zwei Standorte nicht erreichbar. Die lokale Wiederherstellung war erfolglos. Eine Umschaltung auf das Ersatzsystem ist möglich, kann aber Datenänderungen der letzten 15 Minuten verlieren. Benötigt wird die Entscheidung, ob die Umschaltung durchgeführt und der mögliche Datenverlust akzeptiert wird.

Governance bei Incidents

Governance bestimmt unter anderem den Rahmen für:

Bei einem kritischen Incident sollte geklärt sein:

Governance soll die Wiederherstellung nicht unnötig verzögern.

Entscheidungsrechte und Notfallverfahren sollten deshalb vor einem Incident vorbereitet werden.

Governance bei Changes

Governance legt den Rahmen fest, innerhalb dessen Changes bewertet und autorisiert werden.

Dazu können gehören:

Nicht jeder Change benötigt dieselben Beteiligten oder dasselbe Gremium.

Die Autorisierung sollte sich richten nach:

Typischer Fehler

Ein Change Advisory Board wird als zentrale Freigabestelle für jede kleine Änderung verwendet.

Dadurch können unnötige Verzögerungen entstehen, ohne dass kritische Changes automatisch besser bewertet werden.

Governance bei Lieferanten

Externe Lieferanten können einen wesentlichen Teil eines Produkts oder Service bereitstellen.

Governance sollte unter anderem klären:

Merke

Die Auslagerung einer Tätigkeit überträgt nicht automatisch die gesamte Verantwortung für das Ergebnis oder die Risiken an den Lieferanten.

Governance bei künstlicher Intelligenz

ITIL Version 5 berücksichtigt ausdrücklich AI-gestützte Produkte, Services und Arbeitsweisen.

Governance für KI kann unter anderem behandeln:

Vor dem Einsatz einer KI-Lösung sollte unter anderem geprüft werden:

Sicherheitsrelevant

Die Verwendung einer KI-Lösung überträgt die Verantwortung für Entscheidungen und Folgen nicht automatisch auf das technische System oder den Anbieter.

Governance und Continual Improvement

Governance und Continual Improvement unterstützen sich gegenseitig.

Governance gibt unter anderem vor:

Continual Improvement nutzt unter anderem:

um Verbesserungen zu identifizieren und umzusetzen.

Beispiel:

Das Monitoring zeigt wiederholt, dass kritische Zertifikate erst kurz vor Ablauf erneuert werden.

Governance kann festlegen:

Continual Improvement entwickelt und verbessert anschließend:

Praxisbeispiel: Ausfall eines zentralen Speichersystems

Ein zentrales Speichersystem zeigt kritische Fehler.

Technische Situation

Evaluate

Direct

Monitor

Mögliche Verantwortlichkeiten

Dieses Beispiel zeigt, dass technische Kompetenz, Management und Governance zusammenwirken müssen.

Typische Governance-Fehler

Fehler 1: Verantwortung ohne Befugnis

Eine Person soll für ein Ergebnis einstehen, besitzt aber keine Möglichkeit:

Fehler 2: Befugnis ohne Kontrolle

Eine Rolle darf weitreichende Entscheidungen treffen, ohne:

zu müssen.

Fehler 3: Governance nur als Genehmigung verstehen

Viele Freigaben werden eingeführt, aber Ziele, Verantwortlichkeiten und Erfolgskriterien bleiben unklar.

Fehler 4: Jede Entscheidung zentralisieren

Auch risikoarme Tätigkeiten benötigen hochrangige Genehmigungen.

Dadurch entstehen:

Fehler 5: Risiken ohne Befugnis akzeptieren

Ein technisches Team dokumentiert ein erhebliches Risiko, entscheidet aber eigenständig, es dauerhaft zu akzeptieren.

Fehler 6: Nur technische Leistung überwachen

Server und Anwendungen sind verfügbar, aber:

Fehler 7: Dokumentation mit Wirksamkeit verwechseln

Eine Richtlinie existiert, wird aber:

Fehler 8: Verantwortung bleibt an Teamgrenzen hängen

Jedes Team erfüllt seine Komponentenaufgabe, aber niemand verantwortet das Ende-zu-Ende-Ergebnis des Service.

Fehler 9: Governance nicht an Veränderungen anpassen

Entscheidungsmodelle und Kontrollen bleiben unverändert, obwohl sich:

verändert haben.

Fragen für eine neue Organisation

Beim Einstieg in eine neue IT-Organisation solltest du klären:

Entscheidungshilfe: Ist eine Governance-Entscheidung notwendig?

Eine Governance- oder übergeordnete Entscheidung kann erforderlich sein, wenn:

Eine operative Entscheidung kann dagegen innerhalb delegierter Befugnisse getroffen werden, wenn:

Checkliste für klare Verantwortlichkeiten

Checkliste für wirksame Governance

Schnellreferenz

Frage Governance-Bezug
Was wird benötigt? Evaluate
Welche Optionen und Risiken bestehen? Evaluate
Welches Ziel und welche Grenzen gelten? Direct
Wer darf entscheiden? Direct
Wer trägt die Ergebnisverantwortung? Direct
Werden Vorgaben eingehalten? Monitor
Werden Outcomes erreicht? Monitor
Bleiben Risiken innerhalb akzeptierter Grenzen? Monitor
Müssen Richtung oder Vorgaben angepasst werden? erneutes Evaluate und Direct

Zusammenfassende Darstellung

Bedürfnisse, Ziele, Risiken und Rahmenbedingungen
↓
Evaluate
Situation und Optionen bewerten
↓
Direct
Richtung, Verantwortung und Grenzen vorgeben
↓
Management und technische Umsetzung
↓
Monitor
Ergebnisse, Risiken und Einhaltung überwachen
↓
Feedback, Abweichungen und neue Anforderungen
↓
erneute Bewertung und Anpassung

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die Aussagen zur Einbindung von Governance in das ITIL Value System sowie zu den Governance-Aktivitäten Evaluate, Direct und Monitor wurden anhand offizieller PeopleCert- und ITIL-Unterlagen geprüft.

Die Ausführungen zu:

sind zusätzliche herstellerneutrale Erläuterungen und Praxisempfehlungen dieses unabhängigen Nachschlagewerks.

Eine RACI-Matrix ist ein mögliches Hilfsmittel zur Rollenklärung, aber keine zwingend vorgeschriebene ITIL-Struktur.

Konkrete Governance-Gremien, Rollenbezeichnungen, Freigabestufen und Risikogrenzen müssen von der jeweiligen Organisation festgelegt werden.

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

2. ITIL verstehen – Aufbau, Prinzipien und Modelle

2.5 Die vier Dimensionen des Produkt- und Service-Managements

Kurz erklärt

Die vier Dimensionen unterstützen eine ganzheitliche Betrachtung digitaler Produkte und Services.

Sie helfen dabei, nicht ausschließlich auf Technik, Prozesse oder einzelne Teams zu schauen.

Die vier Dimensionen sind:

  1. Organizations and People – Organisationen und Menschen
  2. Information and Technology – Informationen und Technologie
  3. Partners and Suppliers – Partner und Lieferanten
  4. Value Streams and Processes – Wertströme und Prozesse

Bei Entscheidungen, Änderungen, Störungen und Verbesserungen sollten alle vier Dimensionen berücksichtigt werden.

Warum die vier Dimensionen notwendig sind

Digitale Produkte und Services entstehen durch das Zusammenwirken unterschiedlicher Bestandteile.

Dazu gehören beispielsweise:

Eine technische Lösung kann leistungsfähig sein und trotzdem keinen ausreichenden Wert ermöglichen.

Beispiele:

Die vier Dimensionen helfen dabei, solche Lücken frühzeitig zu erkennen.

Merke

Ein Produkt oder Service ist nur so wirksam wie das Zusammenspiel seiner organisatorischen, technischen, menschlichen und externen Bestandteile.

Die vier Dimensionen im Überblick

Dimension Zentrale Betrachtung
Organizations and People Rollen, Fähigkeiten, Kapazitäten, Kommunikation, Kultur und Organisationsstruktur
Information and Technology Informationen, Wissen, Daten, Anwendungen, Infrastruktur, Integration und Automatisierung
Partners and Suppliers externe Leistungen, Lieferantenbeziehungen, Verträge, Abhängigkeiten und Zusammenarbeit
Value Streams and Processes Ende-zu-Ende-Arbeitsfluss, Aktivitäten, Übergaben, Kontrollen und Ergebnisse

Die Dimensionen sind keine voneinander getrennten Bereiche.

Eine Entscheidung in einer Dimension beeinflusst häufig auch die anderen drei Dimensionen.

Die Dimensionen sind Betrachtungsperspektiven

Die vier Dimensionen sind:

Sie dienen als Perspektiven, mit denen ein Produkt, Service, Wertstrom, Problem oder Vorhaben untersucht werden kann.

Beispiel:

Eine Organisation führt eine neue Plattform für die zentrale Dateiablage ein.

Organizations and People

Information and Technology

Partners and Suppliers

Value Streams and Processes

Erst die gemeinsame Betrachtung ergibt ein vollständigeres Bild.

Nicht jede Dimension benötigt immer denselben Aufwand

Alle vier Dimensionen sollten berücksichtigt werden.

Das bedeutet jedoch nicht, dass sie bei jeder Aufgabe gleich ausführlich dokumentiert werden müssen.

Beispiel:

Bei einer einfachen, dokumentierten Standardtätigkeit kann eine kurze Prüfung ausreichen.

Bei der Einführung einer geschäftskritischen Cloud-Plattform kann dagegen eine umfangreiche Betrachtung notwendig sein.

Der erforderliche Umfang hängt unter anderem ab von:

Grundsatz

Alle vier Dimensionen berücksichtigen, aber den Prüf- und Dokumentationsaufwand an Risiko und Kontext anpassen.

1. Organizations and People

Die Dimension Organizations and People betrachtet die organisatorischen und menschlichen Voraussetzungen für wirksames Produkt- und Service-Management.

Dazu gehören unter anderem:

Technische Systeme werden von Menschen:

Eine technisch geeignete Lösung kann deshalb scheitern, wenn die menschlichen und organisatorischen Voraussetzungen fehlen.

Organisationen sind mehr als Organigramme

Ein Organigramm zeigt formale Strukturen.

Es beantwortet jedoch nicht automatisch:

Für die Bewertung dieser Dimension müssen deshalb sowohl formale als auch tatsächlich gelebte Arbeitsweisen betrachtet werden.

Typischer Fehler

Eine Rolle ist im Organigramm eingetragen, besitzt aber weder ausreichende Befugnisse noch Zeit, Informationen oder Ressourcen, um ihre Verantwortung wahrzunehmen.

Rollen und Verantwortlichkeiten

Für wichtige Produkte, Services und Tätigkeiten sollte geklärt sein:

Mögliche Rollen sind beispielsweise:

ITIL schreibt nicht vor, dass jede Organisation genau diese Rollenbezeichnungen verwenden muss.

Entscheidend ist, dass Verantwortung, Befugnis und erwartetes Ergebnis eindeutig sind.

Fähigkeiten und Kompetenzen

Eine Organisation benötigt nicht nur ausreichend Personal, sondern auch geeignete Fähigkeiten.

Dazu können gehören:

Bei einer neuen Technologie sollte deshalb nicht nur geprüft werden:

Kann das Produkt beschafft oder installiert werden?

Zusätzlich ist zu prüfen:

Merke

Eine Organisation besitzt eine Fähigkeit nicht allein deshalb, weil sie ein Werkzeug gekauft hat.

Kapazität und Arbeitsbelastung

Auch fachlich geeignete Mitarbeiter können ihre Aufgaben nicht wirksam erfüllen, wenn ausreichende Kapazität fehlt.

Anzeichen für Kapazitätsprobleme können sein:

Kapazität sollte deshalb nicht nur anhand der Anzahl von Mitarbeitern bewertet werden.

Zu berücksichtigen sind außerdem:

Kommunikation und Zusammenarbeit

Digitale Produkte und Services überschreiten häufig Team- und Organisationsgrenzen.

Eine wirksame Zusammenarbeit benötigt:

Mögliche Kommunikationsprobleme sind:

Praxistipp

Die Qualität der Zusammenarbeit zeigt sich besonders an Übergaben, Störungen und Änderungen.

Organisationskultur

Kultur beeinflusst, wie Menschen tatsächlich handeln.

Sie zeigt sich beispielsweise darin:

Eine Organisation kann offiziell Zusammenarbeit fördern und gleichzeitig durch ihre tatsächliche Arbeitsweise Konkurrenz zwischen Teams erzeugen.

Beispiel:

Teams werden ausschließlich nach ihrer eigenen Bearbeitungszeit bewertet.

Dadurch kann jedes Team versuchen, Vorgänge möglichst schnell weiterzugeben.

Die lokale Kennzahl verbessert sich, während sich die gesamte Bearbeitungsdauer für den Benutzer verlängert.

Leitfragen zu Organizations and People

2. Information and Technology

Die Dimension Information and Technology betrachtet die Informationen, das Wissen und die Technologien, die für Produkte und Services benötigt werden.

Dazu gehören beispielsweise:

Informationen und Technologie unterstützen nahezu jede Tätigkeit im digitalen Produkt- und Service-Management.

Sie müssen jedoch zu den tatsächlichen Anforderungen und Fähigkeiten der Organisation passen.

Informationen als Arbeitsgrundlage

Geeignete Entscheidungen benötigen geeignete Informationen.

Beispiele:

Informationen sollten möglichst:

sein.

Wichtig

Mehr Daten bedeuten nicht automatisch bessere Informationen.

Entscheidend ist, ob die Daten verständlich, zuverlässig und für eine konkrete Entscheidung nutzbar sind.

Datenqualität

Fehlerhafte oder veraltete Daten können zu falschen Entscheidungen führen.

Beispiele:

Datenqualität sollte deshalb nicht nur bei der Erfassung, sondern über den gesamten Lebenszyklus betrachtet werden.

Zu klären ist:

Information und Wissen unterscheiden

Informationen werden erst durch Einordnung und Erfahrung zu anwendbarem Wissen.

Beispiel:

Information

Der Dienst wurde innerhalb von drei Monaten zwölfmal neu gestartet.

Wissen

Die Neustarts treten regelmäßig nach einem bestimmten Speicheranstieg auf und stellen nur eine vorübergehende Wiederherstellung dar.

Anwendbare Erkenntnis

Die Ursache muss untersucht und eine dauerhafte Korrektur geplant werden.

Knowledge Management soll dabei helfen, relevante Informationen:

Technologieauswahl

Eine Technologie sollte nicht nur anhand ihrer Funktionen bewertet werden.

Zu berücksichtigen sind beispielsweise:

Typischer Fehler

Eine neue Technologie wird eingeführt, weil sie viele Funktionen besitzt.

Erst später wird festgestellt, dass sie nicht zu vorhandenen Arbeitsweisen, Fähigkeiten oder Schnittstellen passt.

Architektur und Integration

Digitale Produkte und Services bestehen häufig aus mehreren integrierten Systemen.

Zu berücksichtigen sind:

Beispiel:

Eine Anwendung kann technisch verfügbar sein, aber nicht nutzbar, wenn:

Eine ganzheitliche Betrachtung erfordert deshalb Informationen über Ende-zu-Ende-Abhängigkeiten.

Informationssicherheit

Informationen und Technologien müssen angemessen geschützt werden.

Zu den grundlegenden Schutzzielen gehören insbesondere:

Je nach Kontext können außerdem relevant sein:

Bei technischen Entscheidungen sollte geprüft werden:

Automatisierung

Automatisierung kann:

Sie benötigt jedoch:

Beispiel:

Eine automatisierte Benutzeranlage kann Konten, Lizenzen und Standardgruppen bereitstellen.

Die Automatisierung muss trotzdem klären:

Künstliche Intelligenz

KI kann bei digitalen Produkten und Services unter anderem eingesetzt werden für:

Dabei müssen unter anderem betrachtet werden:

Sicherheitsrelevant

Eine KI-generierte Antwort oder Entscheidung muss abhängig von ihrer möglichen Auswirkung angemessen geprüft werden.

Die Verantwortung verbleibt bei der Organisation und den zuständigen Rollen.

Technische Schulden

Technische Schulden entstehen, wenn kurzfristige Lösungen später zusätzlichen Aufwand oder Risiken verursachen.

Beispiele:

Technische Schulden sind nicht automatisch vollständig vermeidbar.

Sie sollten jedoch:

werden.

Leitfragen zu Information and Technology

3. Partners and Suppliers

Die Dimension Partners and Suppliers betrachtet externe Organisationen und Personen, die an Produkten, Services oder Wertströmen beteiligt sind.

Dazu können gehören:

Viele Organisationen können digitale Produkte und Services nicht vollständig allein bereitstellen.

Externe Partner können:

bereitstellen.

Partner und Lieferant unterscheiden

Die Begriffe können in Organisationen unterschiedlich verwendet werden.

Vereinfacht kann unterschieden werden:

Begriff Mögliche Bedeutung
Lieferant stellt vertraglich vereinbarte Produkte oder Leistungen bereit
Partner arbeitet enger und möglicherweise längerfristig an gemeinsamen Outcomes mit

Ein Lieferant kann gleichzeitig ein strategischer Partner sein.

Entscheidend ist nicht nur die Bezeichnung, sondern:

Sourcing-Entscheidungen

Organisationen müssen entscheiden, welche Fähigkeiten und Leistungen sie:

Mögliche Kriterien sind:

Typischer Fehler

Eine Tätigkeit wird ausschließlich wegen kurzfristig geringerer Kosten ausgelagert.

Langfristige Abhängigkeiten, Datenportabilität, interne Fähigkeiten und Ausstiegskosten werden nicht berücksichtigt.

Verträge und Vereinbarungen

Verträge und Vereinbarungen sollten die benötigten Outcomes unterstützen.

Mögliche Inhalte sind:

Eine vertraglich zugesicherte technische Verfügbarkeit beantwortet nicht automatisch:

Lieferantenabhängigkeiten

Externe Abhängigkeiten sollten sichtbar und bewertet sein.

Mögliche Risiken sind:

Besonders kritisch kann eine Konzentration entstehen, wenn viele Produkte und Services von demselben Anbieter abhängen.

Beispiel:

Ein einziger Cloud-Anbieter stellt bereit:

Ein Ausfall oder Vertragsproblem kann dann mehrere zentrale Services gleichzeitig beeinflussen.

Geteilte Verantwortung

Bei extern bereitgestellten Services bleiben Verantwortlichkeiten häufig zwischen Anbieter und Kunde aufgeteilt.

Beispiel: Cloud-Service

Der Anbieter kann verantwortlich sein für:

Die nutzende Organisation kann weiterhin verantwortlich sein für:

Die genaue Aufteilung hängt vom jeweiligen Produkt, Vertrag und Bereitstellungsmodell ab.

Merke

Eine ausgelagerte Tätigkeit bedeutet nicht automatisch, dass alle Risiken und Verantwortlichkeiten auf den Anbieter übergehen.

Lieferanten in Incidents

Bei einem Incident sollte geklärt sein:

Eine Supportanfrage an einen Lieferanten ersetzt nicht die interne Verantwortung für:

Ausstiegs- und Übergangsplanung

Bereits bei der Auswahl eines Lieferanten sollte betrachtet werden, wie die Beziehung später verändert oder beendet werden kann.

Zu prüfen sind:

Praxistipp

Eine Exit-Strategie sollte nicht erst entwickelt werden, wenn der Vertrag bereits beendet werden muss.

Leitfragen zu Partners and Suppliers

4. Value Streams and Processes

Die Dimension Value Streams and Processes betrachtet, wie Arbeit durch die Organisation fließt und wie Aktivitäten zu Ergebnissen und Wert beitragen.

Dazu gehören:

Einzelne Teams können ihre Aufgaben gut erfüllen und trotzdem einen schlechten Ende-zu-Ende-Arbeitsfluss erzeugen.

Die Dimension richtet den Blick deshalb nicht nur auf einzelne Prozessschritte, sondern auf den gesamten Weg zum benötigten Outcome.

Value Stream

Ein Value Stream beschreibt eine Abfolge von Schritten, durch die Wert für einen Stakeholder ermöglicht wird.

Beispiele:

Ein Value Stream kann mehrere:

verbinden.

Merke

Ein Wertstrom folgt dem Weg zum Outcome und nicht automatisch der Struktur des Organigramms.

Prozess

Ein Prozess ist eine strukturierte Folge miteinander verbundener Aktivitäten.

Er überführt bestimmte Eingaben in Ergebnisse.

Ein Prozess kann beispielsweise festlegen:

Ein Value Stream kann mehrere Prozesse enthalten.

Ein Prozess kann wiederum in mehreren Value Streams verwendet werden.

Beispiel:

Der Prozess zur Benutzerkontoanlage kann Bestandteil sein von:

Ende-zu-Ende-Sicht

Eine Ende-zu-Ende-Betrachtung prüft den gesamten Weg vom Bedarf bis zum erreichten Outcome.

Beispiel: neuer Mitarbeiter

  1. Eintritt wird gemeldet.
  2. Aufgaben und benötigte Zugriffe werden bestimmt.
  3. Freigaben werden eingeholt.
  4. Benutzerkonto wird erstellt.
  5. Lizenzen werden zugewiesen.
  6. Endgerät wird bereitgestellt.
  7. Sicherheitsmaßnahmen werden eingerichtet.
  8. Zugriffe werden getestet.
  9. Arbeitsplatz wird übergeben.
  10. Arbeitsfähigkeit wird bestätigt.

Wird nur die Kontoanlage betrachtet, können andere notwendige Schritte übersehen werden.

Der technische Output:

Das Benutzerkonto wurde erstellt.

bedeutet noch nicht automatisch das Outcome:

Der neue Mitarbeiter kann seine Aufgaben ausführen.

Übergaben

An Übergaben entstehen häufig:

Beispiele:

Übergaben sollten deshalb geprüft werden auf:

Engpässe und Wartezeiten

Ein Value Stream kann durch Engpässe verlangsamt werden.

Mögliche Ursachen sind:

Nicht jede lange Gesamtdauer entsteht durch langsame Ausführung.

Häufig besteht ein großer Teil aus Wartezeit.

Beispiel:

Schritt Bearbeitungszeit Wartezeit
Anforderung prüfen 15 Minuten 1 Tag
Freigabe erteilen 5 Minuten 2 Tage
Konto erstellen 10 Minuten 4 Stunden
Zugriff testen 15 Minuten 1 Tag

Die tatsächliche Bearbeitungszeit beträgt weniger als eine Stunde.

Der gesamte Durchlauf dauert trotzdem mehrere Tage.

Kontrollen im Arbeitsfluss

Kontrollen können notwendig sein für:

Sie sollten jedoch einen klaren Zweck besitzen.

Zu prüfen ist:

Typischer Fehler

Zusätzliche Freigaben werden eingeführt, nachdem ein Fehler aufgetreten ist.

Später wird nicht mehr geprüft, ob sie das Risiko tatsächlich reduzieren oder nur den Arbeitsfluss verlangsamen.

Prozesse dürfen nicht zum Selbstzweck werden

Ein Prozess ist kein Wert an sich.

Er soll ein benötigtes Outcome unterstützen.

Anzeichen für einen ungeeigneten Prozess können sein:

Messung von Wertströmen und Prozessen

Mögliche Messgrößen sind:

Eine einzelne Kennzahl reicht häufig nicht aus.

Beispiel:

Eine kurze Ticketbearbeitungszeit kann positiv sein.

Sie kann aber auch entstehen, weil Tickets:

werden.

Messgrößen sollten deshalb gemeinsam und im Kontext betrachtet werden.

Leitfragen zu Value Streams and Processes

Zusammenwirken der vier Dimensionen

Die vier Dimensionen beeinflussen sich gegenseitig.

Veränderung Mögliche Auswirkungen auf andere Dimensionen
neues Ticketsystem Schulungsbedarf, Rollen, Datenmigration, Lieferantenvertrag und angepasste Prozesse
Outsourcing des Service Desk neue Schnittstellen, Verantwortlichkeiten, technische Zugänge und Eskalationswege
Automatisierung der Benutzeranlage Datenqualität, Freigaben, Rollen, Sicherheitskontrollen und Prozessänderungen
Einführung einer Cloud-Plattform neue Fähigkeiten, Verträge, Integrationen, Datenflüsse und Supportprozesse
Änderung eines Incident-Prozesses Werkzeugkonfiguration, Schulung, Lieferanteneinbindung und neue Messgrößen
Einsatz von KI Datenanforderungen, Governance, Kompetenzen, Lieferantenrisiken und Kontrollabläufe

Merke

Eine Änderung in nur einer Dimension ist in der Praxis selten auf diese eine Dimension begrenzt.

Praxisbeispiel: Einführung eines neuen Ticketsystems

Eine Organisation möchte ihr bisheriges Ticketsystem ersetzen.

Organizations and People

Information and Technology

Partners and Suppliers

Value Streams and Processes

Wird nur die Technologie ausgewählt, können die anderen drei Dimensionen später zu erheblichen Problemen führen.

Praxisbeispiel: wiederkehrender VPN-Ausfall

Mehrere Benutzer verlieren regelmäßig ihre VPN-Verbindung.

Organizations and People

Information and Technology

Partners and Suppliers

Value Streams and Processes

Eine rein technische Einzelbehandlung kann den Service kurzfristig wiederherstellen.

Die ganzheitliche Betrachtung unterstützt zusätzlich eine nachhaltige Verbesserung.

Praxisbeispiel: Backup und Wiederherstellung

Organizations and People

Information and Technology

Partners and Suppliers

Value Streams and Processes

Merke

Backup ist nicht nur eine Technologie.

Wiederherstellbarkeit entsteht durch das Zusammenspiel aller vier Dimensionen.

Die vier Dimensionen bei einem Incident

Dimension Beispielhafte Fragen
Organizations and People Wer koordiniert, entscheidet, analysiert und kommuniziert?
Information and Technology Welche Systeme, Daten, Protokolle und Abhängigkeiten sind betroffen?
Partners and Suppliers Welche Anbieter müssen beteiligt oder eskaliert werden?
Value Streams and Processes Wie erfolgt Erfassung, Priorisierung, Wiederherstellung, Kommunikation und Abschluss?

Die vier Dimensionen bei einem Change

Dimension Beispielhafte Fragen
Organizations and People Wer beantragt, bewertet, autorisiert, implementiert und prüft?
Information and Technology Welche Komponenten, Daten, Schnittstellen und Sicherheitsmaßnahmen sind betroffen?
Partners and Suppliers Werden Hersteller, Provider oder Wartungspartner benötigt?
Value Streams and Processes Wie erfolgen Bewertung, Test, Autorisierung, Umsetzung, Rückfall und Erfolgskontrolle?

Die vier Dimensionen bei einer Verbesserung

Dimension Beispielhafte Fragen
Organizations and People Welche Fähigkeiten, Rollen oder kulturellen Veränderungen werden benötigt?
Information and Technology Welche Daten belegen das Problem und welche Technologie unterstützt die Verbesserung?
Partners and Suppliers Welche externen Beiträge oder Vertragsänderungen sind notwendig?
Value Streams and Processes Welcher Arbeitsfluss wird verbessert und wie wird die Wirkung gemessen?

Typische Fehler

Fehler 1: Nur Technik betrachten

Eine Organisation kauft eine neue Plattform, ohne Rollen, Fähigkeiten, Support und Arbeitsabläufe vorzubereiten.

Fehler 2: Nur Prozesse dokumentieren

Abläufe werden beschrieben, aber notwendige Informationen, Technologien und Kompetenzen fehlen.

Fehler 3: Lieferanten nicht als Teil des Service betrachten

Externe Abhängigkeiten werden erst berücksichtigt, wenn ein Incident eskaliert.

Fehler 4: Menschen als austauschbare Ressourcen behandeln

Benötigte Fähigkeiten, Erfahrungen, Motivation und Zusammenarbeit werden nicht berücksichtigt.

Fehler 5: Jede Dimension getrennt optimieren

Ein Team verbessert seine eigene Kennzahl, verschlechtert aber den gesamten Wertstrom.

Fehler 6: Alle Situationen gleich ausführlich prüfen

Kleine Standardtätigkeiten werden unnötig kompliziert, während kritische Vorhaben nicht risikogerecht vertieft werden.

Fehler 7: Werkzeuge mit Fähigkeiten verwechseln

Eine Organisation besitzt eine Funktion im Ticketsystem, hat aber keine wirksame Arbeitsweise und keine eindeutigen Verantwortlichkeiten dafür.

Fehler 8: Verträge nur beim Einkauf betrachten

Betrieb, Support, Sicherheit, Eskalation und Ausstieg werden nicht ausreichend einbezogen.

Fehler 9: Datenmenge mit Informationsqualität verwechseln

Viele Kennzahlen werden gesammelt, liefern aber keine Grundlage für Entscheidungen oder Verbesserungen.

Fehler 10: Prozesse an Teamgrenzen enden lassen

Jedes Team bearbeitet nur seinen Teil, während niemand das Ende-zu-Ende-Outcome verantwortet.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten häufig hauptsächlich in der technischen Dimension.

Ihre Aufgaben beeinflussen jedoch immer wieder alle vier Dimensionen.

Beispiel: neuer Server

Tätigkeit Betroffene Dimension
Server installieren und konfigurieren Information and Technology
Zuständigkeit und Betrieb klären Organizations and People
Hardware-, Software- oder Cloud-Anbieter einbinden Partners and Suppliers
Bereitstellung, Change, Monitoring und Support einordnen Value Streams and Processes

Vor einer technischen Maßnahme sind deshalb zusätzliche Fragen sinnvoll:

30-Sekunden-Prüfung

Bei einer neuen Aufgabe kannst du alle vier Dimensionen mit vier Kurzfragen prüfen:

  1. Menschen: Wer ist beteiligt, verantwortlich und ausreichend befähigt?
  2. Technologie: Welche Informationen, Systeme und technischen Abhängigkeiten werden benötigt?
  3. Partner: Welche externen Anbieter und vertraglichen Abhängigkeiten bestehen?
  4. Arbeitsfluss: Wie gelangt die Aufgabe vom Bedarf zum überprüften Outcome?

Diese Kurzprüfung ersetzt keine notwendige Detailanalyse.

Sie hilft jedoch dabei, eine Dimension nicht vollständig zu übersehen.

Checkliste zu Organizations and People

Checkliste zu Information and Technology

Checkliste zu Partners and Suppliers

Checkliste zu Value Streams and Processes

Gesamtcheck für ein Produkt oder einen Service

Schnellreferenz

Dimension Kurzfrage
Organizations and People Wer wird benötigt und wie arbeiten die Beteiligten zusammen?
Information and Technology Welche Informationen und Technologien ermöglichen das Outcome?
Partners and Suppliers Welche externen Leistungen und Abhängigkeiten bestehen?
Value Streams and Processes Wie fließt die Arbeit vom Bedarf zum Ergebnis?

Zusammenfassende Darstellung

Organizations and People
Rollen · Fähigkeiten · Kapazität · Kommunikation · Kultur

Information and Technology
Daten · Wissen · Anwendungen · Infrastruktur · Integration · Automatisierung

Partners and Suppliers
Leistungen · Verträge · Zusammenarbeit · Abhängigkeiten · Ausstieg

Value Streams and Processes
Aktivitäten · Übergaben · Kontrollen · Arbeitsfluss · Outcomes

↓

ganzheitliches digitales Produkt- und Service-Management

↓

bessere Outcomes und gemeinsam ermöglichter Wert

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

ITIL Version 5 verwendet die folgenden vier Dimensionen des Produkt- und Service-Managements:

Die offiziellen ITIL-Version-5-Grundlagen beschreiben die vier Dimensionen als Grundlage einer ganzheitlichen Betrachtung digitaler Produkte und Services.

Die ausführlichen Leitfragen, Beispiele, Checklisten und technischen Einordnungen auf dieser Seite sind zusätzliche herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine für jede Organisation verbindlichen Arbeitsabläufe dar.

Konkrete Rollen, Technologien, Lieferantenmodelle, Prozesse und Kontrollen müssen an den jeweiligen Kontext angepasst werden.

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

2. ITIL verstehen – Aufbau, Prinzipien und Modelle

2.6 Der Product and Service Lifecycle

Kurz erklärt

Der ITIL Product and Service Lifecycle beschreibt den gemeinsamen Lebenszyklus digitaler Produkte und Services.

Er verbindet Produktentwicklung, Beschaffung, technische Umsetzung, Betrieb, Bereitstellung und Unterstützung in einem gemeinsamen Modell.

Die acht Lifecycle-Aktivitäten sind:

  1. Discover
  2. Design
  3. Acquire
  4. Build
  5. Transition
  6. Operate
  7. Deliver
  8. Support

Die Aktivitäten bilden keinen starren linearen Ablauf. Sie können sich überschneiden, wiederholt werden und sich gegenseitig beeinflussen.

Warum ein gemeinsamer Lebenszyklus notwendig ist

Digitale Produkte und Services wurden in Organisationen häufig getrennt betrachtet.

Produktteams konzentrierten sich beispielsweise auf:

Serviceteams konzentrierten sich dagegen auf:

Diese Trennung kann zu Problemen führen.

Beispiele:

ITIL Version 5 verbindet beide Perspektiven deshalb in einem gemeinsamen Product and Service Lifecycle.

Merke

Produkt und Service sind keine voneinander unabhängigen Alternativen.

Sie sind zwei miteinander verbundene Perspektiven auf eine technologiebasierte Lösung.

Produkt- und Serviceperspektive

Die Produktperspektive betrachtet unter anderem:

Die Serviceperspektive betrachtet unter anderem:

Beispiel: VPN-Lösung

Produktperspektive Serviceperspektive
VPN-Gateway und Clientsoftware sicherer Fernzugriff für Benutzer
Authentifizierungsfunktionen verständlicher und zuverlässiger Anmeldevorgang
unterstützte Betriebssysteme Nutzbarkeit auf den benötigten Endgeräten
technische Kapazität ausreichende Leistung für die Benutzer
Softwareversionen kontrollierte und möglichst störungsarme Aktualisierung
Protokollierung Unterstützung bei Störungen und Sicherheitsanalysen
Hersteller-Roadmap langfristige Nutzbarkeit des Fernzugriffs

Beide Perspektiven müssen gemeinsam betrachtet werden.

Eine technisch leistungsfähige VPN-Plattform ermöglicht noch keinen verlässlichen Fernzugriffsservice, wenn:

Die acht Lifecycle-Aktivitäten im Überblick

Aktivität Zentrale Aufgabe
Discover Bedürfnisse, Chancen, Ausgangslage und Umfeld verstehen
Design geeignete Produkte, Services und Lösungen gestalten
Acquire benötigte Ressourcen, Produkte, Leistungen und Fähigkeiten beschaffen oder zuordnen
Build Lösungen erstellen, konfigurieren, integrieren und testen
Transition neue oder geänderte Bestandteile kontrolliert in die vorgesehene Nutzung überführen
Operate Produkte, Plattformen und technische Fähigkeiten zuverlässig betreiben
Deliver Services und Serviceangebote für Stakeholder bereitstellen und steuern
Support Benutzer, Kunden, Produkte und Services bei Fragen, Anfragen und Störungen unterstützen

Die Beschreibungen in dieser Tabelle sind praxisnahe Zusammenfassungen.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen dar.

Lifecycle-Aktivitäten statt starrer Phasen

Die Begriffe können zunächst den Eindruck einer festen Reihenfolge vermitteln:

Discover → Design → Acquire → Build → Transition → Operate → Deliver → Support

Das Modell ist jedoch nicht als starres Wasserfallmodell gedacht.

Jede Aktivität kann:

Beispiel:

Während Version 1 einer Anwendung betrieben, bereitgestellt und unterstützt wird, kann gleichzeitig:

Produkt- oder Serviceversion Mögliche aktuelle Aktivität
Version 1.0 Operate, Deliver und Support
Version 1.1 Build und Test
Version 1.2 Design
zukünftige Hauptversion Discover
abzulösende Altversion Transition und Operate

Merke

Ein Produkt oder Service befindet sich nicht dauerhaft nur in einer einzigen Lifecycle-Aktivität.

Transitions können zwischen verschiedenen Aktivitäten stattfinden

Transition ist nicht ausschließlich ein einmaliger Schritt zwischen Build und Operate.

Eine kontrollierte Überführung kann an unterschiedlichen Stellen notwendig sein.

Beispiele:

Die konkrete Form einer Transition hängt vom jeweiligen Produkt, Service, Risiko und Wertstrom ab.

Wichtig

Transition bedeutet nicht, dass ein Team seine Arbeit beendet und die Verantwortung vollständig an ein anderes Team abgibt.

Produkt-, Service-, Betriebs- und Supportverantwortung müssen über den Übergang hinweg zusammenwirken.

Lifecycle, Value System und Value Stream unterscheiden

Begriff Bedeutung
ITIL Value System verbindet die übergeordneten Bestandteile der Organisation zur Wertschöpfung
Product and Service Lifecycle beschreibt acht gemeinsame Aktivitäten über den Lebenszyklus digitaler Produkte und Services
Value Chain flexibles operatives Modell innerhalb des ITIL Value Systems
Value Stream konkrete Abfolge von Schritten zur Erreichung eines bestimmten Outcomes
Management Practice organisatorische Ressourcen und Fähigkeiten für einen bestimmten Zweck
Prozess strukturierte Aktivitäten, die Eingaben in Ergebnisse überführen
Projekt zeitlich begrenztes Vorhaben zur Erreichung definierter Ziele

Beispiel: Einführung einer neuen Monitoring-Plattform

Lifecycle und Projektlebenszyklus unterscheiden

Ein Projekt besitzt normalerweise:

Ein digitales Produkt oder ein Service besteht häufig über das Projekt hinaus.

Beispiel:

Ein Projekt führt eine neue E-Mail-Plattform ein.

Nach Projektende müssen weiterhin durchgeführt werden:

Typischer Fehler

Die Produkt- und Serviceverantwortung endet mit dem Projektabschluss.

Dadurch bleiben Betrieb, Support, technische Schulden und langfristige Weiterentwicklung ungeklärt.

1. Discover

Zentrale Frage

Was wird benötigt, warum wird es benötigt und welche Ausgangslage besteht?

Discover dient dazu, Bedürfnisse, Chancen, Probleme und Rahmenbedingungen zu verstehen.

Mögliche Auslöser sind:

Discover sollte nicht nur bestätigen, was ein einzelner Anforderer bereits als Lösung vorgeschlagen hat.

Zuerst sollte das zugrunde liegende Bedürfnis verstanden werden.

Beispiel:

Anforderung:

Wir benötigen einen neuen Server.

Mögliche zugrunde liegende Bedürfnisse:

Erst nach dieser Klärung kann bewertet werden, ob ein neuer Server tatsächlich die geeignete Lösung darstellt.

Typische Inhalte von Discover

Leitfragen zu Discover

Mögliche Ergebnisse von Discover

Merke

Ein sinnvolles Ergebnis von Discover kann auch die Entscheidung sein, keine neue Lösung einzuführen.

Praxisbeispiel: wiederkehrende Anmeldeprobleme

Mehrere Benutzer können sich regelmäßig nicht anmelden.

Eine vorschnelle Lösung wäre:

Der Verzeichnisdienst muss ersetzt werden.

Discover untersucht zunächst:

Erst danach kann eine geeignete Designentscheidung getroffen werden.

Typische Fehler bei Discover

2. Design

Zentrale Frage

Wie müssen Produkt und Service gestaltet werden, damit das gewünschte Outcome sicher und nachhaltig unterstützt wird?

Design übersetzt Bedürfnisse und Erkenntnisse in eine geeignete Gesamtlösung.

Dabei werden nicht nur technische Funktionen gestaltet.

Zu berücksichtigen sind ebenfalls:

Funktionale und nichtfunktionale Anforderungen

Funktionale Anforderungen beschreiben, was eine Lösung leisten soll.

Beispiele:

Nichtfunktionale Anforderungen beschreiben Eigenschaften und Qualitätsanforderungen.

Beispiele:

Typischer Fehler

Die Funktionen werden gestaltet, während Betrieb, Support, Sicherheit und Wiederherstellung erst kurz vor der Einführung betrachtet werden.

Design betrachtet alle vier Dimensionen

Organizations and People

Information and Technology

Partners and Suppliers

Value Streams and Processes

Leitfragen zu Design

Betrieb und Support bereits im Design berücksichtigen

Ein Produkt sollte nicht erst nach seiner Entwicklung „betriebsfähig gemacht“ werden.

Bereits im Design sollten unter anderem berücksichtigt werden:

Merke

Operability und Supportability sind keine nachträglichen Zusatzfunktionen.

Sie gehören zur Gestaltung eines nutzbaren und nachhaltigen digitalen Produkts und Service.

Mögliche Ergebnisse von Design

Typische Fehler bei Design

3. Acquire

Zentrale Frage

Welche Produkte, Leistungen, Ressourcen und Fähigkeiten werden benötigt und wie werden sie beschafft oder bereitgestellt?

Acquire umfasst die Beschaffung oder Zuordnung benötigter Bestandteile.

Dazu können gehören:

Acquire bedeutet nicht automatisch, dass etwas von einem externen Anbieter gekauft werden muss.

Mögliche Entscheidungen sind:

Make, Buy, Reuse oder Partner

Möglichkeit Beispiel
Make eigene Anwendung oder Automatisierung entwickeln
Buy Standardsoftware oder Hardware beschaffen
Reuse vorhandene Plattform oder Komponente weiterverwenden
Subscribe Cloud- oder SaaS-Service abonnieren
Partner Lösung gemeinsam mit einem externen Partner entwickeln
Outsource Tätigkeit oder Servicebestandteil extern erbringen lassen

Die Entscheidung sollte nicht nur anhand des Anschaffungspreises erfolgen.

Zu berücksichtigen sind beispielsweise:

Leitfragen zu Acquire

Beschaffung ist mehr als Bestellung

Eine technische Bestellung allein stellt noch keine nutzbare Ressource bereit.

Beispiel: neue Firewall

Zusätzlich zur Hardware können benötigt werden:

Typischer Fehler

Der Kaufpreis wird geplant, während Betriebskosten, Lizenzen, Support und notwendige Fähigkeiten nicht berücksichtigt werden.

Lieferanten und Exit-Planung

Bei externen Leistungen sollte bereits während Acquire geprüft werden:

Mögliche Ergebnisse von Acquire

Typische Fehler bei Acquire

4. Build

Zentrale Frage

Wie wird die entworfene Lösung erstellt, konfiguriert, integriert und überprüft?

Build umfasst die praktische Erstellung und technische Umsetzung.

Dazu können gehören:

Build bedeutet nicht ausschließlich Programmierung.

Auch die Konfiguration einer Standardsoftware oder der Aufbau einer Infrastruktur kann Teil dieser Aktivität sein.

Build und Test gehören zusammen

Eine erstellte Lösung muss überprüft werden.

Mögliche Testarten sind:

Tests sollten sich an Anforderungen und Risiken orientieren.

Merke

Ein erfolgreicher Funktionstest beweist nicht automatisch, dass eine Lösung sicher, betreibbar, wiederherstellbar und für Benutzer geeignet ist.

Leitfragen zu Build

Reproduzierbarkeit

Technische Lösungen sollten möglichst reproduzierbar aufgebaut werden.

Geeignete Maßnahmen können sein:

Reproduzierbarkeit unterstützt:

Build umfasst Betriebsbereitschaft

Während Build sollten nicht nur Produktfunktionen erstellt werden.

Ebenfalls vorzubereiten sind:

Mögliche Ergebnisse von Build

Typische Fehler bei Build

5. Transition

Zentrale Frage

Wie wird eine neue oder geänderte Lösung kontrolliert in die vorgesehene Nutzung und Verantwortung überführt?

Transition verbindet Entwicklung, Beschaffung und Aufbau mit der tatsächlichen Verwendung, dem Betrieb, der Bereitstellung und dem Support.

Mögliche Bestandteile sind:

Transition ist mehr als Deployment

Deployment beschreibt die technische Übertragung von Komponenten in eine Zielumgebung.

Transition umfasst zusätzlich die organisatorische und servicebezogene Einsatzbereitschaft.

Deployment Transition
Software wird installiert. Produkt und Service werden kontrolliert in die Nutzung überführt.
Konfiguration wird verteilt. Betrieb, Support und Stakeholder sind vorbereitet.
technische Komponente wird aktiviert. Funktion, Erfahrung, Risiken und Outcomes werden überprüft.
Daten werden migriert. Datenqualität, Benutzerzugriff und Geschäftsabläufe werden validiert.

Merke

Technisch bereitgestellt bedeutet nicht automatisch betriebsbereit, supportfähig oder für Benutzer nutzbar.

Operational Readiness

Vor einer produktiven Nutzung sollte geprüft werden:

Leitfragen zu Transition

Rückfall und Wiederherstellung

Ein Rückfallplan sollte möglichst klären:

Ein Rückfall ist nicht immer die beste oder technisch mögliche Option.

Bei Datenmigrationen oder unumkehrbaren Änderungen kann stattdessen ein alternativer Wiederherstellungsplan notwendig sein.

Mögliche Ergebnisse von Transition

Typische Fehler bei Transition

6. Operate

Zentrale Frage

Wie werden Produkte, Plattformen und technische Fähigkeiten zuverlässig, sicher und wirtschaftlich betrieben?

Operate betrachtet den laufenden technischen Betrieb.

Dazu gehören beispielsweise:

Operate sorgt dafür, dass die technischen Fähigkeiten vorhanden bleiben, auf denen Services aufbauen.

Operate und Deliver unterscheiden

Operate konzentriert sich stärker auf den laufenden Betrieb der technischen Produkt- und Plattformbestandteile.

Deliver konzentriert sich stärker darauf, Services und Serviceangebote für Stakeholder nutzbar bereitzustellen.

Beispiel: E-Mail

Operate

Deliver

Beide Aktivitäten überschneiden und beeinflussen sich.

Leitfragen zu Operate

Stabilität und Veränderung

Operate bedeutet nicht, technische Systeme möglichst unverändert zu lassen.

Ein stabiler Betrieb benötigt regelmäßig:

Diese Änderungen müssen kontrolliert erfolgen.

Merke

Stabilität entsteht nicht durch Stillstand.

Sie entsteht durch kontrollierte Veränderung, Überwachung und angemessene Wiederherstellungsfähigkeit.

Technische Schulden im Betrieb

Technische Schulden können sich zeigen durch:

Sie sollten:

werden.

Mögliche Ergebnisse von Operate

Typische Fehler bei Operate

7. Deliver

Zentrale Frage

Wie werden Services und Serviceangebote so bereitgestellt, dass Stakeholder die vorgesehenen Outcomes erreichen können?

Deliver betrachtet die tatsächliche Bereitstellung und Steuerung des Service gegenüber Benutzern, Kunden und weiteren Stakeholdern.

Dazu können gehören:

Technische Verfügbarkeit und Servicebereitstellung

Ein technisches System kann verfügbar sein, während der Service für den Benutzer nicht nutzbar ist.

Beispiele:

Deliver betrachtet deshalb nicht nur technische Funktion, sondern auch die tatsächliche Nutzbarkeit und Leistung des Service.

Leitfragen zu Deliver

Serviceangebot

Ein Serviceangebot kann unterschiedliche Bestandteile verbinden:

Praxisbeispiel: Arbeitsplatzservice

Mögliche Bestandteile:

Der Benutzer benötigt normalerweise nicht jeden technischen Bestandteil einzeln.

Er benötigt einen arbeitsfähigen Arbeitsplatz als nutzbares Gesamtergebnis.

Servicequalität und Erfahrung

Servicequalität kann sowohl objektive als auch subjektive Aspekte besitzen.

Mögliche objektive Informationen:

Mögliche Erfahrungsaspekte:

Merke

Ein Service kann technische Zielwerte erfüllen und trotzdem eine schlechte Benutzererfahrung erzeugen.

Mögliche Ergebnisse von Deliver

Typische Fehler bei Deliver

8. Support

Zentrale Frage

Wie werden Benutzer, Kunden, Produkte und Services bei Fragen, Anfragen, Problemen und Störungen wirksam unterstützt?

Support umfasst die Unterstützung während der Nutzung eines Produkts oder Service.

Dazu können gehören:

Support beschränkt sich nicht darauf, Tickets möglichst schnell zu schließen.

Das Ziel besteht darin, negative Auswirkungen zu begrenzen, Nutzung zu ermöglichen und wertvolle Erkenntnisse zurück in den Lebenszyklus zu führen.

Support als Informationsquelle

Support erhält häufig direkte Informationen über:

Diese Erkenntnisse sollten nicht ausschließlich im einzelnen Ticket bleiben.

Sie können zurückfließen in:

Merke

Support ist nicht nur die letzte Aktivität des Modells.

Support liefert Erkenntnisse für den gesamten Product and Service Lifecycle.

Leitfragen zu Support

Supportfähigkeit bereits vorher aufbauen

Wirksamer Support benötigt unter anderem:

Diese Voraussetzungen müssen bereits in Design, Build und Transition berücksichtigt werden.

Mögliche Ergebnisse von Support

Typische Fehler bei Support

Zusammenwirken der acht Aktivitäten

Praxisbeispiel: Einführung eines neuen sicheren Fernzugriffs

Discover

Design

Acquire

Build

Transition

Operate

Deliver

Support

Continual Improvement über den gesamten Lifecycle

Continual Improvement ist nicht auf das Ende des Lebenszyklus beschränkt.

Jede Aktivität kann verbessert werden.

Lifecycle-Aktivität Beispiel für eine Verbesserung
Discover Benutzerfeedback früher und systematischer erfassen
Design Betriebs- und Sicherheitsanforderungen früher berücksichtigen
Acquire Exit-Anforderungen in Lieferantenbewertungen aufnehmen
Build Tests und Bereitstellung stärker automatisieren
Transition Pilot- und Rückfallverfahren verbessern
Operate wiederkehrende Wartung automatisieren
Deliver Serviceangebote verständlicher gestalten
Support bekannte Lösungen schneller auffindbar machen

Erkenntnisse aus späteren Aktivitäten können frühere Aktivitäten erneut auslösen.

Beispiel:

Support erkennt viele Anfragen zu einer unverständlichen Funktion.

Dies kann führen zu:

Governance über den gesamten Lifecycle

Governance wirkt auf alle acht Aktivitäten.

Zu klären sind unter anderem:

Governance sollte nicht erst bei der produktiven Einführung beginnen.

Ungeeignete Grundentscheidungen in Discover, Design oder Acquire können später nur mit hohem Aufwand korrigiert werden.

Die Guiding Principles im Lifecycle

Guiding Principle Anwendung im Lifecycle
Focus on value jede Aktivität am benötigten Outcome ausrichten
Start where you are bestehende Produkte, Fähigkeiten und Daten berücksichtigen
Progress iteratively with feedback Versionen, Piloten und kontrollierte Schritte verwenden
Collaborate and promote visibility Produkt-, Service-, Betriebs- und Supportteams verbinden
Think and work holistically alle acht Aktivitäten und vier Dimensionen berücksichtigen
Keep it simple and practical unnötige Übergaben und Komplexität vermeiden
Optimize and automate Arbeitsweisen verbessern und geeignete Teile automatisieren

Künstliche Intelligenz im Lifecycle

KI kann in allen Lifecycle-Aktivitäten verwendet werden.

Beispiele:

Aktivität Mögliche KI-Unterstützung
Discover Muster in Feedback und Nutzungsdaten erkennen
Design Varianten analysieren oder Prototypen unterstützen
Acquire Angebote und Anforderungen vergleichen
Build Code-, Konfigurations- oder Testunterstützung
Transition Risiken und Migrationsdaten analysieren
Operate Anomalien und mögliche Ausfälle erkennen
Deliver Services personalisieren oder Interaktionen unterstützen
Support Tickets klassifizieren und Lösungsvorschläge bereitstellen

Dabei bleiben notwendig:

Sicherheitsrelevant

KI-Unterstützung ersetzt nicht die Verantwortung der zuständigen Personen und Organisation.

Wo befindet sich die Außerbetriebnahme?

Das offizielle ITIL-Version-5-Modell nennt acht Aktivitäten und enthält keine separate neunte Aktivität mit der Bezeichnung Retire.

Die Ablösung oder Außerbetriebnahme eines Produkts oder Service muss trotzdem kontrolliert gestaltet werden.

Dazu können Beiträge aus mehreren Aktivitäten gehören:

Discover

Design

Acquire und Build

Transition

Operate

Deliver und Support

Zusätzlich können Practices wie folgende beteiligt sein:

Wichtig

Außerbetriebnahme bedeutet nicht nur, ein System auszuschalten.

Daten, Zugänge, Verträge, Assets, Dokumentationen, Abhängigkeiten und Sicherheitsanforderungen müssen ebenfalls behandelt werden.

Anwendung bei einem Incident

Ein Incident findet hauptsächlich während Operate, Deliver oder Support statt.

Seine Erkenntnisse können jedoch den gesamten Lifecycle beeinflussen.

Beispiel:

Ein Zertifikat läuft ab und verursacht einen Serviceausfall.

Support

Operate

Discover

Design

Acquire

Build

Transition

Deliver

Anwendung bei einem Change

Ein Change kann mehrere Lifecycle-Aktivitäten betreffen.

Beispiel: Datenbank-Upgrade

Merke

Change Management unterstützt die kontrollierte Veränderung.

Der Product and Service Lifecycle zeigt den größeren Zusammenhang, in dem die Veränderung stattfindet.

Anwendung bei einem kleinen Standardservice

Nicht jede Servicebereitstellung benötigt ein umfangreiches Projekt.

Beispiel: Standardsoftware für einen Mitarbeiter bereitstellen

Discover

Design

Acquire

Build

Transition

Operate

Deliver

Support

Bei einem standardisierten und risikoarmen Fall können viele Schritte automatisiert und sehr kompakt ausgeführt werden.

Typische Missverständnisse

Missverständnis 1: Die Aktivitäten werden immer einmal nacheinander durchgeführt

Tatsächlich können sie wiederholt, übersprungen, kombiniert oder gleichzeitig durchgeführt werden.

Missverständnis 2: Nach Transition beginnt ausschließlich der Betrieb

Auch während Operate, Deliver und Support können neue Discovery-, Design- und Build-Aktivitäten stattfinden.

Missverständnis 3: Build bedeutet nur Softwareentwicklung

Build kann auch Installation, Konfiguration, Integration, Automatisierung und technische Tests umfassen.

Missverständnis 4: Acquire bedeutet nur Einkauf

Acquire kann auch interne Ressourcen, Fähigkeiten, Daten, Lizenzen und wiederverwendete Komponenten umfassen.

Missverständnis 5: Operate und Deliver bedeuten dasselbe

Operate konzentriert sich stärker auf den technischen Betrieb. Deliver betrachtet stärker die tatsächliche Servicebereitstellung und das Stakeholder-Outcome.

Missverständnis 6: Support beginnt erst nach der Einführung

Supportfähigkeit muss bereits während Design, Build und Transition vorbereitet werden.

Missverständnis 7: Lifecycle und Value Stream sind identisch

Der Lifecycle stellt allgemeine Aktivitäten bereit. Ein Value Stream verbindet konkrete Schritte für ein bestimmtes Outcome.

Missverständnis 8: Ein Produkt ist nach dem ersten Release fertig

Digitale Produkte und Services werden weiter betrieben, unterstützt, verändert und verbessert.

Missverständnis 9: Eine erfolgreiche Transition beendet die Verantwortung des Produktteams

Produkt-, Service-, Betriebs- und Supportverantwortung müssen weiterhin zusammenarbeiten.

Missverständnis 10: Das Modell besitzt automatisch für jede Organisation dieselben Rollen

Die konkrete Rollenverteilung wird von der jeweiligen Organisation gestaltet.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker sind nicht nur in Operate und Support beteiligt.

Sie können Beiträge über den gesamten Lifecycle leisten.

Aktivität Möglicher Beitrag
Discover technische Ausgangslage und bestehende Probleme erklären
Design Architektur, Betrieb, Sicherheit und Wiederherstellung mitgestalten
Acquire technische Anforderungen an Produkte und Lieferanten bewerten
Build Systeme installieren, konfigurieren, integrieren und testen
Transition Migration, Deployment und Betriebsübernahme unterstützen
Operate Infrastruktur und Plattformen betreiben
Deliver Servicebereitstellung und Nutzbarkeit sicherstellen
Support Incidents, Anfragen und technische Probleme bearbeiten

Praxistipp

Bringe Betriebs- und Supportwissen möglichst früh ein.

Viele spätere Probleme können bereits während Discover, Design und Build verhindert werden.

30-Sekunden-Prüfung

Bei einem Produkt, Service oder Change kannst du acht Kurzfragen stellen:

  1. Discover: Verstehen wir den tatsächlichen Bedarf?
  2. Design: Ist die Gesamtlösung einschließlich Betrieb und Support gestaltet?
  3. Acquire: Sind alle notwendigen Ressourcen und Fähigkeiten verfügbar?
  4. Build: Wurde die Lösung erstellt, integriert und ausreichend getestet?
  5. Transition: Kann sie kontrolliert und mit Rückfallmöglichkeit eingeführt werden?
  6. Operate: Kann sie zuverlässig und sicher betrieben werden?
  7. Deliver: Ist der Service für Stakeholder tatsächlich nutzbar?
  8. Support: Können Benutzer und Service wirksam unterstützt werden?

Checkliste zu Discover

Checkliste zu Design

Checkliste zu Acquire

Checkliste zu Build

Checkliste zu Transition

Checkliste zu Operate

Checkliste zu Deliver

Checkliste zu Support

Gesamtcheck für den Product and Service Lifecycle

Schnellreferenz

Aktivität Kurzfrage
Discover Was wird benötigt und warum?
Design Wie muss die Gesamtlösung gestaltet sein?
Acquire Welche Ressourcen und Fähigkeiten werden benötigt?
Build Wie wird die Lösung erstellt und getestet?
Transition Wie wird sie kontrolliert in die Nutzung überführt?
Operate Wie wird sie zuverlässig und sicher betrieben?
Deliver Wie wird der Service für Stakeholder nutzbar bereitgestellt?
Support Wie werden Benutzer, Produkt und Service unterstützt?

Zusammenfassende Darstellung

Discover
Bedarf, Chancen und Ausgangslage verstehen
↓
Design
Produkt, Service und Gesamtlösung gestalten
↓
Acquire
Ressourcen, Produkte und Fähigkeiten beschaffen
↓
Build
erstellen, konfigurieren, integrieren und testen
↓
Transition
kontrolliert in die vorgesehene Nutzung überführen
↓
Operate
technische Fähigkeiten zuverlässig betreiben
↓
Deliver
Services für Stakeholder bereitstellen
↓
Support
Benutzer, Produkte und Services unterstützen
↓
Feedback und Continual Improvement
↓
erneutes Discover, Design oder eine andere benötigte Aktivität

Die Darstellung dient als Lernhilfe.

Das offizielle Modell ist nicht starr oder ausschließlich linear. Jede Aktivität kann Erkenntnisse für jede andere Aktivität liefern.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

ITIL Version 5 verwendet einen gemeinsamen Product and Service Lifecycle mit acht Aktivitäten:

Die offiziellen Veröffentlichungen beschreiben das Modell als ganzheitlich, flexibel und nicht starr linear.

Aktivitäten können sich gegenseitig beeinflussen, wiederholt werden und für unterschiedliche Versionen eines Produkts oder Service gleichzeitig stattfinden.

Die detaillierten Leitfragen, Beispiele, Checklisten und praktischen Einordnungen auf dieser Seite sind eigene herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine für jede Organisation vorgeschriebenen Arbeitsabläufe dar.

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

2. ITIL verstehen – Aufbau, Prinzipien und Modelle

2.7 Die ITIL Management Practices

Kurz erklärt

ITIL Management Practices bündeln organisatorische Ressourcen und Fähigkeiten, die für einen bestimmten Zweck eingesetzt werden.

Eine Practice umfasst deshalb nicht nur einen Prozess.

Si:contentReference[oaicite:0]{index=0}chen und Rollen,

ITIL Version 5 führt weiterhin 34 Management Practices. Sie wurden gegenüber ITIL 4 nicht vollständig ersetzt, sondern weitgehend fortgeführt und an den neuen Produkt- und Servicekontext angepasst.

Warum Management Practices notwendig sind

Digitale Produkte und Services benötigen unterschiedliche organisatorische Fähigkeiten.

Beispiele:

Eine einzelne Abteilung oder ein einzelner Prozess kann diese Aufgaben normalerweise nicht vollständig erfüllen.

Management Practices stellen deshalb strukturierte Fähigkeiten bereit, die in unterschiedlichen Wertströmen miteinander kombiniert werden können.

Merke

Eine Practice beschreibt eine organisatorische Fähigkeit.

Ein konkreter Wertstrom verwendet die benötigten Practices, um ein bestimmtes Outcome zu erreichen.

Practice, Prozess, Team und Werkzeug unterscheiden

Diese Begriffe dürfen nicht gleichgesetzt werden.

Begriff Bedeutung
Management Practice organisatorische Ressourcen und Fähigkeiten für einen bestimmten Zweck
Prozess strukturierte Folge von Aktivitäten, die Eingaben in Ergebnisse überführt
Value Stream Ende-zu-Ende-Abfolge von Schritten zur Ermöglichung eines bestimmten Outcomes
Team Gruppe von Personen, die bestimmte Aufgaben oder Verantwortlichkeiten übernimmt
Rolle definierte Verantwortung, Befugnis oder Tätigkeit
Werkzeug technische Unterstützung für Informationen, Kommunikation, Automatisierung oder Kontrolle
Arbeitsanweisung konkrete Beschreibung, wie eine bestimmte Tätigkeit ausgeführt wird

Beispiel: Incident Management

Die Practice kann enthalten:

Ein Prozess kann beschreiben:

  1. Incident erfassen
  2. Auswirkungen und Dringlichkeit bewerten
  3. kategorisieren
  4. zuständige Bearbeitung zuweisen
  5. untersuchen und diagnostizieren
  6. Service wiederherstellen
  7. Ergebnis prüfen
  8. dokumentieren und abschließen

Ein Team kann sein:

Ein Werkzeug kann sein:

Typischer Fehler

Eine Practice wird eingeführt, indem lediglich ein entsprechendes Modul im Ticketsystem aktiviert wird.

Ein Werkzeug kann eine Practice unterstützen, aber fehlende Verantwortung, Fähigkeiten, Informationen und Zusammenarbeit nicht ersetzen.

Die vier Dimensionen innerhalb einer Practice

Jede Practice sollte ganzheitlich über die vier Dimensionen betrachtet werden.

Dimension Beispielhafte Inhalte einer Practice
Organizations and People Rollen, Fähigkeiten, Kapazität, Kommunikation und Verantwortung
Information and Technology Daten, Wissen, Ticketsysteme, Monitoring und Automatisierung
Partners and Suppliers externe Supportpartner, Hersteller, Provider und Verträge
Value Streams and Processes Aktivitäten, Übergaben, Kontrollen und Arbeitsergebnisse

Beispiel: Monitoring and Event Management

Organizations and People

Information and Technology

Partners and Suppliers

Value Streams and Processes

Management Practices sind keine isolierten Silos

Eine Practice arbeitet normalerweise nicht allein.

Bei einer realen Situation können mehrere Practices zusammenwirken.

Beispiel: Eine Unternehmensanwendung fällt nach einem Update aus.

  1. Monitoring and Event Management erkennt eine Zustandsänderung.
  2. Incident Management koordiniert die Wiederherstellung.
  3. Service Desk dient als Kontakt- und Kommunikationspunkt.
  4. Service Configuration Management liefert Informationen über Abhängigkeiten.
  5. Knowledge Management stellt bekannte Diagnose- und Wiederherstellungsschritte bereit.
  6. Supplier Management bindet gegebenenfalls den Hersteller ein.
  7. Problem Management untersucht die zugrunde liegende Ursache.
  8. Change Enablement unterstützt die kontrollierte dauerhafte Korrektur.
  9. Release Management plant die Bereitstellung einer korrigierten Version.
  10. Deployment Management überträgt die korrigierten Komponenten in die Zielumgebung.
  11. Service Validation and Testing prüft die neue oder geänderte Lösung.
  12. Continual Improvement leitet Verbesserungen für Tests, Monitoring und Arbeitsweisen ab.

Merke

Ein Vorgang gehört nicht immer nur zu einer Practice.

Die benötigten Practices werden entsprechend dem tatsächlichen Wertstrom miteinander verbunden.

Änderungen gegenüber ITIL 4

ITIL Version 5 führt die 34 Management Practices weitgehend fort.

Sie werden im aktuellen Framework in zwei übergeordneten Gruppen organisiert:

  1. Product and Service Management Practices
  2. General Management Practices

Die frühere ITIL-4-Einteilung in:

soll deshalb nicht ungeprüft als aktuelle ITIL-Version-5-Struktur übernommen werden.

Die öffentlich zugänglichen offiziellen Übersichtsseiten bestätigen die neue Einteilung in zwei Gruppen, veröffentlichen dort jedoch keine vollständige frei zugängliche Zuordnung aller 34 Practices zu diesen beiden Gruppen.

Die detaillierten aktuellen Practice Guides werden über PeopleCert Plus bereitgestellt.

Wichtig

Diese Seite führt die 34 Practices deshalb alphabetisch auf.

Sie behauptet keine nicht ausreichend öffentlich belegte Einzelzuordnung zu den beiden neuen Gruppen.

Hinweis zur Bezeichnung Change Enablement

Die aktuelle offizielle ITIL-Version-5-Übersicht zum Practice-Manager-Pfad verwendet weiterhin die Bezeichnung Change Enablement.

In anderen offiziellen Überblickstexten wird teilweise allgemein von change management gesprochen.

Solange die konkrete aktuelle Practice Guidance keine eindeutig abweichende offizielle Practice-Bezeichnung vorgibt, verwendet dieses Buch deshalb:

Change Enablement

Change Management kann weiterhin als allgemeiner organisatorischer Oberbegriff oder als betriebliche Bezeichnung vorkommen.

Versionsabhängig

Eine betriebliche Organisation kann weiterhin eigene Begriffe wie Change Management, Änderungsmanagement oder Change-Prozess verwenden.

Entscheidend ist, dass Zweck, Verantwortlichkeiten und Arbeitsweise eindeutig sind.

Die 34 ITIL Management Practices im Überblick

Die folgenden Kurzbeschreibungen sind praxisnahe Zusammenfassungen in eigenen Worten.

Sie ersetzen nicht die vollständigen offiziellen Practice Guides.

Nr. Management Practice Praxisnahe Kurzbeschreibung
1 Architecture Management aktuelle und zukünftige Strukturen, Beziehungen und Architekturentscheidungen nachvollziehbar gestalten
2 Availability Management sicherstellen, dass Produkte und Services die benötigte und vereinbarte Verfügbarkeit unterstützen
3 Business Analysis Bedürfnisse, Probleme und Anforderungen untersuchen und geeignete Lösungsoptionen unterstützen
4 Capacity and Performance Management ausreichende Kapazität und Leistung für aktuelle und zukünftige Anforderungen sicherstellen
5 Change Enablement erfolgreiche Änderungen durch angemessene Bewertung, Autorisierung und Steuerung unterstützen
6 Continual Improvement Produkte, Services, Practices und Arbeitsweisen fortlaufend an veränderte Bedürfnisse anpassen
7 Deployment Management neue oder geänderte Komponenten kontrolliert in Zielumgebungen übertragen
8 Incident Management negative Auswirkungen von Incidents verringern und den normalen Servicebetrieb angemessen schnell wiederherstellen
9 Information Security Management Informationen und unterstützende Systeme entsprechend den Sicherheitsanforderungen schützen
10 Infrastructure and Platform Management Infrastruktur- und Plattformressourcen über ihren Lebenszyklus planen, betreiben und verbessern
11 IT Asset Management IT-Assets über ihren Lebenszyklus steuern, um Wert, Kosten, Risiken und Entscheidungen zu unterstützen
12 Knowledge Management benötigtes Wissen und Informationen wirksam erfassen, pflegen, teilen und verwenden
13 Measurement and Reporting verlässliche Messungen und Berichte für Entscheidungen, Steuerung und Verbesserung bereitstellen
14 Monitoring and Event Management Produkte, Services und Komponenten systematisch beobachten und relevante Zustandsänderungen behandeln
15 Organizational Change Management menschliche und organisatorische Veränderungen so unterstützen, dass neue Arbeitsweisen angenommen und dauerhaft genutzt werden
16 Portfolio Management Investitionen, Produkte, Services, Programme und Projekte auf Strategie, Wert und verfügbare Ressourcen ausrichten
17 Problem Management Ursachen und Wahrscheinlichkeiten von Incidents reduzieren sowie bekannte Fehler und Workarounds verwalten
18 Project Management zeitlich begrenzte Vorhaben strukturiert planen, steuern und abschließen
19 Relationship Management Beziehungen zu Stakeholdern aufbauen, pflegen und für gemeinsame Outcomes nutzen
20 Release Management neue oder geänderte Produkte, Services und Funktionen für die vorgesehene Nutzung verfügbar machen
21 Risk Management Risiken identifizieren, bewerten, behandeln, überwachen und angemessen kommunizieren
22 Service Catalogue Management verlässliche und verständliche Informationen über Services und Serviceangebote bereitstellen
23 Service Configuration Management zuverlässige Informationen über Services, Configuration Items und deren Beziehungen verfügbar machen
24 Service Continuity Management ausreichende Servicefähigkeit nach schwerwiegenden Störungen oder Katastrophen vorbereiten und erhalten
25 Service Design Produkte und Services ganzheitlich so gestalten, dass sie zweckmäßig, nutzbar und nachhaltig betreibbar sind
26 Service Desk zentralen Kontakt, Kommunikation sowie Unterstützung für Benutzer und Kunden ermöglichen
27 Service Financial Management finanzielle Informationen, Planung und Kontrolle für Produkte, Services und Entscheidungen unterstützen
28 Service Level Management verständliche, geschäftsbezogene Serviceziele vereinbaren und deren Erfüllung steuern
29 Service Request Management vereinbarte und häufig standardisierte Benutzeranfragen wirksam bearbeiten
30 Service Validation and Testing prüfen, ob neue oder geänderte Produkte und Services definierte Anforderungen und Nutzungsbedürfnisse erfüllen
31 Software Development and Management Software so entwickeln und verwalten, dass sie Anforderungen, Qualität, Wartbarkeit und Compliance unterstützt
32 Strategy Management Ziele, Ausrichtung und geeignete Handlungsoptionen für die Organisation entwickeln
33 Supplier Management Lieferanten, Verträge, Leistungen und Beziehungen angemessen steuern
34 Workforce and Talent Management sicherstellen, dass ausreichend geeignete Menschen, Fähigkeiten und Entwicklungsmöglichkeiten vorhanden sind

Nicht jede Practice muss gleich stark ausgeprägt sein

Eine Organisation muss nicht jede Practice:

aufbauen.

Der benötigte Umfang hängt unter anderem ab von:

Beispiel:

Ein kleines Unternehmen kann Supplier Management durch:

umsetzen.

Eine große Organisation benötigt möglicherweise zusätzlich:

Grundsatz

Eine Practice muss wirksam und angemessen sein.

Sie muss nicht möglichst groß oder kompliziert sein.

Foundation-Wissen und vollständige Practice Guidance unterscheiden

Die ITIL Foundation vermittelt:

Die vollständige Practice Guidance kann darüber hinaus behandeln:

Wichtig

Eine kurze Foundation-Definition reicht nicht aus, um eine vollständige betriebliche Practice zu gestalten.

Für eine praktische Einführung werden zusätzlich benötigt:

Zertifizierungsbezogene Practice-Bündel

Die aktuelle offizielle Practice-Manager-Struktur verwendet drei Bündel mit jeweils fünf Practices.

Diese Bündel sind für die Zertifizierungsstruktur relevant.

Sie sind nicht mit den zwei übergeordneten Practice-Gruppen von ITIL Version 5 gleichzusetzen.

Monitor, Support and Fulfil

Enthaltene Practices:

Gemeinsamer praktischer Schwerpunkt:

Plan, Implement and Control

Enthaltene Practices:

Gemeinsamer praktischer Schwerpunkt:

Collaborate, Assure and Improve

Enthaltene Practices:

Gemeinsamer praktischer Schwerpunkt:

Hinweis

Die übrigen Practices bleiben weiterhin Bestandteil der insgesamt 34 ITIL Management Practices, auch wenn sie nicht in diesen drei Practice-Manager-Bündeln enthalten sind.

Wichtige Practices für Fachinformatiker für Systemintegration

Für Fachinformatiker für Systemintegration sind abhängig vom Arbeitsplatz besonders häufig folgende Practices relevant:

Practice Typischer Bezug zum Arbeitsalltag
Service Desk Benutzerkontakt, Erfassung, Kommunikation und Weiterleitung
Incident Management Störungen analysieren und Servicebetrieb wiederherstellen
Service Request Management Benutzerkonten, Zugriffe, Software und Standardleistungen bereitstellen
Problem Management wiederkehrende Fehler und zugrunde liegende Ursachen untersuchen
Change Enablement technische Änderungen bewerten und kontrolliert durchführen
Deployment Management Software, Konfigurationen oder Infrastrukturkomponenten bereitstellen
Release Management neue oder geänderte Funktionen für die Nutzung verfügbar machen
Monitoring and Event Management technische Zustände und relevante Abweichungen erkennen
Service Configuration Management Abhängigkeiten und Configuration Items nachvollziehen
IT Asset Management Hardware, Software, Lizenzen und Cloud-Ressourcen verwalten
Knowledge Management Lösungen, Arbeitsanweisungen und Erkenntnisse verfügbar machen
Information Security Management Schutzanforderungen bei Betrieb und Änderungen berücksichtigen
Supplier Management Hersteller, Provider und Supportpartner einbinden
Service Continuity Management Wiederherstellung und Fortführung kritischer Services unterstützen
Capacity and Performance Management Leistung, Kapazität und zukünftigen Bedarf bewerten
Availability Management benötigte Verfügbarkeit technischer und servicebezogener Fähigkeiten unterstützen
Continual Improvement wiederkehrende Probleme und Arbeitsweisen nachhaltig verbessern

Nicht jeder Fachinformatiker ist für die vollständige Steuerung dieser Practices verantwortlich.

Er kann jedoch durch technische Arbeit, Dokumentation, Eskalation und Rückmeldungen zu ihrer Wirksamkeit beitragen.

Service Desk und Incident Management unterscheiden

Diese beiden Practices werden häufig gleichgesetzt.

Service Desk Incident Management
stellt einen zentralen Kontakt- und Kommunikationspunkt bereit koordiniert die Behandlung von Incidents
bearbeitet Kontakte, Fragen, Anfragen und Meldungen konzentriert sich auf negative Serviceauswirkungen und Wiederherstellung
unterstützt Benutzerkommunikation organisiert Priorisierung, Diagnose, Eskalation und Wiederherstellung
kann Incidents und Service Requests erfassen kann mehrere Teams und Lieferanten einbeziehen
ist eine Practice und kann organisatorisch als Team umgesetzt sein ist eine Practice, die nicht auf ein einzelnes Team begrenzt ist

Ein Service Desk kann Incident Management wesentlich unterstützen.

Er ist jedoch nicht mit der gesamten Incident-Management-Practice identisch.

Incident Management und Problem Management unterscheiden

Incident Management Problem Management
konzentriert sich auf die aktuelle negative Auswirkung konzentriert sich auf Ursachen und zukünftige Auswirkungen
priorisiert Wiederherstellung priorisiert Untersuchung und nachhaltige Risikoreduzierung
kann eine Zwischenlösung verwenden verwaltet Ursachen, bekannte Fehler und Workarounds
arbeitet häufig unter höherem Zeitdruck kann nach der Wiederherstellung vertieft arbeiten
Erfolg: Service ist wieder nutzbar Erfolg: Wahrscheinlichkeit oder Auswirkung weiterer Incidents wird reduziert

Beispiel:

Ein Dienst wird nach einem Speicherfehler neu gestartet.

Merke

Ein Incident muss nicht vollständig ursächlich verstanden sein, bevor der Service wiederhergestellt wird.

Eine Wiederherstellung beseitigt jedoch nicht automatisch die zugrunde liegende Ursache.

Event, Incident und Problem unterscheiden

Begriff Bedeutung
Event erkannte Zustandsänderung, die für das Management eines Produkts oder Service relevant sein kann
Incident ungeplante Unterbrechung, Qualitätsminderung oder andere negative Serviceauswirkung
Problem Ursache oder mögliche Ursache eines oder mehrerer Incidents

Beispiel:

Nicht jedes Event wird zu einem Incident.

Nicht jeder Incident benötigt einen eigenen Problem Record.

Die konkrete Einordnung hängt von Auswirkungen, Wiederholung, Risiko und betrieblicher Arbeitsweise ab.

Service Request und Incident unterscheiden

Service Request Incident
vorgesehene Benutzeranfrage ungeplante negative Serviceauswirkung
häufig standardisierbar benötigt Untersuchung oder Wiederherstellung
Beispiel: neue Software anfordern Beispiel: vorhandene Software startet nicht
Beispiel: Zugriff beantragen Beispiel: genehmigter Zugriff funktioniert nicht
Beispiel: Auskunft anfordern Beispiel: Service ist nicht erreichbar

Die Formulierung eines Benutzers entscheidet nicht automatisch über die Einordnung.

Ein Benutzer kann beispielsweise sagen:

Ich brauche ein neues Kennwort.

Dahinter können unterschiedliche Situationen stehen:

Change Enablement, Release und Deployment unterscheiden

Practice Zentrale Betrachtung
Change Enablement Nutzen, Risiko, Bewertung, Autorisierung und Steuerung einer Änderung
Release Management neue oder geänderte Funktionen und Servicebestandteile für die Nutzung verfügbar machen
Deployment Management Komponenten in eine Zielumgebung übertragen

Beispiel: neue Anwendungsversion

Change Enablement

Release Management

Deployment Management

Diese Tätigkeiten können miteinander verbunden sein, besitzen aber unterschiedliche Zwecke.

IT Asset und Configuration Item unterscheiden

Ein IT Asset wird hinsichtlich seines finanziellen, vertraglichen, risikobezogenen und lebenszyklusbezogenen Werts verwaltet.

Ein Configuration Item wird verwaltet, weil Informationen über seinen Zustand und seine Beziehungen für das Management eines Produktes oder Service benötigt werden.

Ein Gegenstand kann:

sein.

Beispiele:

Gegenstand Mögliche Einordnung
physischer Server IT Asset und Configuration Item
Softwarelizenz IT Asset, möglicherweise auch Configuration Item
virtueller Cluster Configuration Item, abhängig vom Modell möglicherweise Asset-Bezug
Netzwerkkabel je nach Bedeutung weder einzeln verwaltetes Asset noch CI
Cloud-Abonnement IT Asset und möglicherweise Configuration Item
Service-Dokumentation möglicherweise Configuration Item, aber normalerweise kein IT Asset

Wichtig

Nicht jede technische Komponente muss automatisch als einzelnes Configuration Item erfasst werden.

Der benötigte Detaillierungsgrad muss einen erkennbaren Nutzen besitzen.

Practice Owner, Process Owner und ausführende Rolle

Organisationen können unterschiedliche Verantwortlichkeiten verwenden.

Rolle Möglicher Schwerpunkt
Practice Owner Wirksamkeit und Weiterentwicklung der gesamten Practice
Process Owner Gestaltung und Pflege eines konkreten Prozesses
Process Manager laufende Steuerung eines Prozesses
Service Owner Ende-zu-Ende-Verantwortung für einen Service
Product Owner oder Product Manager Prioritäten und Entwicklung eines Produkts
ausführende Rolle konkrete Bearbeitung einer Aufgabe
Tool Owner Betrieb und Weiterentwicklung des unterstützenden Werkzeugs

ITIL schreibt nicht vor, dass jede Organisation genau diese Rollen einsetzen muss.

Entscheidend ist, dass geklärt ist:

Eine Practice einführen oder verbessern

Eine Practice sollte nicht mit der Auswahl eines Werkzeugs beginnen.

Eine sinnvolle Vorgehensweise ist:

  1. Problem oder Bedarf verstehen
  2. gewünschte Outcomes bestimmen
  3. aktuellen Zustand untersuchen
  4. relevante Stakeholder einbeziehen
  5. betroffene Wertströme bestimmen
  6. vorhandene Fähigkeiten und Daten bewerten
  7. Rollen und Verantwortung klären
  8. angemessene Prozesse und Kontrollen gestalten
  9. benötigte Informationen und Werkzeuge festlegen
  10. Lieferanten und Abhängigkeiten berücksichtigen
  11. Messgrößen und Erfolgskriterien definieren
  12. schrittweise einführen
  13. Feedback auswerten
  14. fortlaufend verbessern

Typischer Fehler

Eine vollständige theoretische Practice wird auf einmal entworfen und anschließend der Organisation aufgezwungen.

Dadurch entstehen umfangreiche Dokumentationen, die nicht zur tatsächlichen Arbeitsweise passen.

Eine Practice an Wertströmen ausrichten

Practices sollten nicht ausschließlich intern optimiert werden.

Beispiel:

Incident Management erreicht eine kurze interne Bearbeitungszeit, indem Tickets schnell an andere Teams weitergegeben werden.

Dadurch können jedoch entstehen:

Deshalb sollte geprüft werden:

Merke

Eine leistungsfähige Practice unterstützt den gesamten Wertstrom und nicht nur ihre eigene interne Kennzahl.

Messung einer Practice

Messgrößen sollten den Zweck und die Outcomes einer Practice unterstützen.

Nicht ausreichend ist es, nur leicht verfügbare Aktivitäten zu zählen.

Beispiel: Incident Management

Mögliche Aktivitätszahlen:

Zusätzliche Ergebnisinformationen:

Beispiel: Knowledge Management

Unzureichende Einzelkennzahl:

Anzahl veröffentlichter Wissensartikel

Ergänzende Fragen:

Kennzahlen dürfen nicht das Verhalten verschlechtern

Eine ungeeignete Kennzahl kann unerwünschtes Verhalten fördern.

Kennzahl Mögliche Fehlwirkung
möglichst viele geschlossene Tickets Vorgänge werden voreilig abgeschlossen
möglichst kurze Gesprächsdauer Benutzerproblem wird nicht vollständig verstanden
möglichst wenige Changes notwendige Verbesserungen und Sicherheitsupdates werden vermieden
möglichst wenige Incidents Incidents werden nicht erfasst oder falsch eingeordnet
möglichst viele Wissensartikel Qualität und Aktualität sinken
möglichst hohe technische Verfügbarkeit tatsächliche Nutzbarkeit und Erfahrung werden übersehen

Messgrößen sollten deshalb gemeinsam betrachtet und regelmäßig überprüft werden.

Practice Capability und Maturity

Eine Practice kann unterschiedlich stark entwickelt sein.

Zu bewerten sind beispielsweise:

Eine umfangreiche Dokumentation bedeutet nicht automatisch hohe Fähigkeit oder Reife.

Eine Practice kann formal beschrieben sein und trotzdem unwirksam bleiben, wenn:

Merke

Practice Capability zeigt sich in der wirksamen Erreichung des Zwecks und nicht in der Menge der Dokumente.

Automatisierung innerhalb von Practices

Automatisierung kann Practices unterstützen.

Beispiele:

Practice Mögliche Automatisierung
Incident Management automatische Erfassung aus relevantem Monitoring-Event
Service Request Management standardisierte Bereitstellung genehmigter Software
Change Enablement risikobasierte Weiterleitung und Terminprüfung
IT Asset Management automatische Inventarisierung
Service Configuration Management technische Discovery und Beziehungsaktualisierung
Knowledge Management Vorschläge passender Wissensartikel
Monitoring and Event Management Korrelation und Unterdrückung redundanter Events
Measurement and Reporting automatische Datensammlung und Berichtserstellung
Deployment Management automatisierte Bereitstellung und technische Prüfung
Information Security Management automatische Richtlinien- und Konfigurationskontrolle

Vor der Automatisierung muss geprüft werden:

Grundsatz

Erst verstehen und optimieren, dann automatisieren.

Künstliche Intelligenz innerhalb von Practices

KI kann unter anderem unterstützen bei:

Dabei müssen berücksichtigt werden:

Beispiel:

Eine KI schlägt eine hohe Incident-Priorität vor.

Die zuständige Arbeitsweise muss weiterhin klären:

Sicherheitsrelevant

Eine KI-Empfehlung überträgt die Entscheidungs- und Ergebnisverantwortung nicht auf das technische System.

Practice und betriebliche Organisation

Organisationen können Practices unterschiedlich benennen oder zusammenfassen.

Beispiele:

Die interne Bezeichnung ist weniger wichtig als eine eindeutige Arbeitsweise.

Zu klären ist:

Praxisbeispiel: wiederkehrender VPN-Ausfall

Mehrere Benutzer verlieren regelmäßig die VPN-Verbindung.

Monitoring and Event Management

Service Desk

Incident Management

Service Configuration Management

Supplier Management

Knowledge Management

Problem Management

Change Enablement

Deployment Management

Service Validation and Testing

Continual Improvement

Praxisbeispiel: neuer Mitarbeiter

Das gewünschte Outcome lautet:

Der neue Mitarbeiter kann am ersten Arbeitstag sicher und vollständig arbeiten.

Mögliche beteiligte Practices:

Practice Beitrag
Service Request Management Onboarding-Anfrage erfassen und koordinieren
Service Catalogue Management verfügbare Arbeitsplatz- und Zugangsangebote beschreiben
IT Asset Management Endgerät und Lizenzen bereitstellen und verwalten
Service Configuration Management relevante Beziehungen und Konfigurationen dokumentieren
Information Security Management Zugriff und Sicherheitsanforderungen berücksichtigen
Supplier Management externe Lieferung oder Lizenzbereitstellung steuern
Knowledge Management Anleitungen und Übergabeinformationen bereitstellen
Service Desk Fragen und Probleme beim Einstieg unterstützen
Continual Improvement Verzögerungen und wiederkehrende Fehler im Onboarding reduzieren

Der Value Stream endet nicht bereits mit der Erstellung des Benutzerkontos.

Er endet mit dem überprüften Outcome der Arbeitsfähigkeit.

Praxisbeispiel: abgelaufenes Zertifikat

Ein Zertifikat läuft ab und verursacht einen Serviceausfall.

Incident Management

Monitoring and Event Management

Service Configuration Management

Problem Management

Knowledge Management

Change Enablement

Information Security Management

Continual Improvement

Merke

Die unmittelbare technische Reparatur kann einen Incident lösen.

Mehrere weitere Practices können notwendig sein, um eine Wiederholung zu verhindern.

Typische Fehler bei der Anwendung von Practices

Fehler 1: Practice mit Prozess gleichsetzen

Die Organisation dokumentiert einen Ablauf, berücksichtigt aber Rollen, Wissen, Werkzeuge und Partner nicht ausreichend.

Fehler 2: Practice mit Team gleichsetzen

Incident Management wird ausschließlich als Aufgabe des Service Desk betrachtet, obwohl technische Teams, Service Owner und Lieferanten beteiligt sein können.

Fehler 3: Tool als Ausgangspunkt verwenden

Das Ticketsystem bestimmt Kategorien und Arbeitsweisen, obwohl der tatsächliche Bedarf nicht untersucht wurde.

Fehler 4: Practices isoliert optimieren

Jede Practice verbessert ihre eigenen Kennzahlen, während Übergaben und Gesamtdauer schlechter werden.

Fehler 5: jede Practice maximal formalisieren

Auch einfache und risikoarme Tätigkeiten erhalten unnötig umfangreiche Prozesse und Freigaben.

Fehler 6: nur den Normalfall gestalten

Ausnahmen, Eskalationen, Sicherheitsvorfälle und Lieferantenausfälle werden nicht berücksichtigt.

Fehler 7: Verantwortung nicht eindeutig festlegen

Viele Teams sind beteiligt, aber niemand koordiniert das Ende-zu-Ende-Ergebnis.

Fehler 8: Messung nur auf Aktivität ausrichten

Gezählt werden Tickets, Changes oder Wissensartikel, aber nicht deren Nutzen und Qualität.

Fehler 9: Practice nach Einführung nicht weiterentwickeln

Arbeitsweisen, Werkzeuge und Anforderungen verändern sich, während die Practice unverändert bleibt.

Fehler 10: ältere Begriffe ungeprüft übernehmen

ITIL-4-Kategorien oder betriebliche Begriffe werden ohne Versionshinweis als aktuelle ITIL-Version-5-Struktur dargestellt.

30-Sekunden-Prüfung einer Practice

Bei der Bewertung einer Practice kannst du folgende Fragen stellen:

  1. Welchen Zweck erfüllt die Practice?
  2. Welches Outcome soll sie unterstützen?
  3. In welchen Wertströmen wird sie verwendet?
  4. Wer trägt Verantwortung?
  5. Welche Fähigkeiten werden benötigt?
  6. Welche Informationen und Werkzeuge sind notwendig?
  7. Welche anderen Practices sind beteiligt?
  8. Welche Partner oder Lieferanten werden benötigt?
  9. Wie wird die Wirksamkeit gemessen?
  10. Wie wird die Practice verbessert?

Checkliste für den Aufbau einer Practice

Checkliste für die Bewertung einer bestehenden Practice

Schnellreferenz für häufige Arbeitssituationen

Situation Häufig beteiligte Practices
Service ist ausgefallen Incident Management, Service Desk, Monitoring and Event Management
Fehler tritt wiederholt auf Problem Management, Knowledge Management, Continual Improvement
Benutzer benötigt Standardsoftware Service Request Management, IT Asset Management, Service Desk
System soll aktualisiert werden Change Enablement, Release Management, Deployment Management
Abhängigkeiten sind unklar Service Configuration Management, Architecture Management
Hardware oder Lizenz muss verwaltet werden IT Asset Management, Supplier Management, Service Financial Management
Sicherheitsrisiko wurde erkannt Information Security Management, Risk Management, Change Enablement
Anbieterleistung ist unzureichend Supplier Management, Service Level Management, Relationship Management
neue Anwendung wird eingeführt Service Design, Business Analysis, Architecture Management, Project Management
Service muss nach Katastrophe wiederhergestellt werden Service Continuity Management, Incident Management, Availability Management
Leistung reicht nicht aus Capacity and Performance Management, Availability Management
Benutzer verstehen den Service nicht Service Catalogue Management, Knowledge Management, Relationship Management
Arbeitsweise soll verbessert werden Continual Improvement, Measurement and Reporting
neues Team oder neue Arbeitsweise wird eingeführt Organizational Change Management, Workforce and Talent Management

Zusammenfassende Darstellung

Bedarf oder Chance
↓
gewünschtes Outcome und Value Stream bestimmen
↓
benötigte Management Practices auswählen
↓
Menschen · Informationen · Prozesse · Technologie · Partner verbinden
↓
Arbeit durchführen und Ergebnisse messen
↓
Feedback und Erkenntnisse auswerten
↓
Practices und Wertströme kontinuierlich verbessern

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Offiziell bestätigter Stand

Die offiziellen aktuellen ITIL-Version-5-Informationen bestätigen:

Hinweis zur Practice-Bezeichnung

Die aktuelle offizielle Beschreibung des Practice-Manager-Moduls Plan, Implement and Control verwendet weiterhin die Bezeichnung Change Enablement.

Deshalb wird diese Practice auf dieser Seite nicht ohne eindeutigen offiziellen Nachweis in Change Management umbenannt.

Einordnung

Die alphabetische Übersicht, deutschen Kurzbeschreibungen, Vergleiche, Praxisbeispiele, Checklisten und Arbeitssituationen sind eigene herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine für jede Organisation vorgeschriebenen Prozesse dar.

Die konkrete Gestaltung, Priorisierung und Ausprägung einer Practice muss an Ziele, Risiken, Fähigkeiten und Wertströme der jeweiligen Organisation angepasst werden.

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

2. ITIL verstehen – Aufbau, Prinzipien und Modelle

2.8 Value Streams und Value Stream Mapping

Kurz erklärt

Ein Value Stream beschreibt den Ende-zu-Ende-Weg, durch den aus einem Bedarf, einer Nachfrage oder einer Chance ein nutzbares Ergebnis und Wert für Stakeholder entstehen.

Value Stream Mapping macht diesen Weg sichtbar.

Dabei werden nicht nur einzelne Prozessschritte betrachtet, sondern auch:

Ziel ist nicht, ein besonders umfangreiches Ablaufdiagramm zu erstellen.

Ziel ist, den tatsächlichen Arbeitsfluss zu verstehen und gezielt zu verbessern.

Warum Value Streams wichtig sind

Digitale Produkte und Services entstehen normalerweise nicht innerhalb eines einzigen Teams.

Ein benötigtes Outcome kann Beiträge erfordern von:

Jeder Beteiligte kann seinen eigenen Arbeitsschritt korrekt ausführen.

Der gesamte Ablauf kann trotzdem:

sein.

Beispiel:

Ein neuer Mitarbeiter benötigt einen arbeitsfähigen IT-Arbeitsplatz.

Alle beteiligten Teams können ihre jeweilige Aufgabe korrekt ausführen:

Der Mitarbeiter kann am ersten Arbeitstag trotzdem nicht arbeiten, wenn:

Merke

Die Qualität einzelner Arbeitsschritte garantiert noch kein gutes Ende-zu-Ende-Ergebnis.

Was ist ein Value Stream?

Ein Value Stream ist eine zusammenhängende Abfolge von Schritten, durch die ein bestimmtes Outcome und Wert für einen Stakeholder ermöglicht werden.

Ein Value Stream besitzt normalerweise:

Beispiele für Value Streams:

Wichtig

Ein Value Stream sollte anhand des benötigten Outcomes benannt werden.

Ein Name wie „Ticket bearbeiten“ ist häufig zu eng.

Ein geeigneterer Name kann beispielsweise lauten:

„Benutzer nach einer Störung wieder arbeitsfähig machen.“

Auslöser, Output, Outcome und Wert

Diese Begriffe müssen unterschieden werden.

Begriff Bedeutung Beispiel
Auslöser Ereignis, Nachfrage oder Chance, die den Wertstrom startet neuer Mitarbeiter tritt ein
Input benötigte Informationen oder Ressourcen Eintrittsdatum, Rolle und genehmigte Zugriffe
Aktivität durchgeführter Arbeitsschritt Benutzerkonto erstellen
Output direkt erzeugtes Ergebnis einer Aktivität Benutzerkonto wurde angelegt
Outcome durch Stakeholder ermöglichtes Ergebnis Mitarbeiter kann seine Aufgaben ausführen
Wert wahrgenommener Nutzen unter Berücksichtigung von Outcomes, Kosten und Risiken produktiver und sicherer Arbeitsbeginn

Ein Output ist nicht automatisch das gewünschte Outcome.

Beispiel:

Output: Das VPN wurde installiert.

Outcome: Der Benutzer kann sicher auf die benötigten Anwendungen zugreifen.

Merke

Value Streams werden vom benötigten Outcome aus betrachtet und nicht nur anhand erledigter technischer Tätigkeiten.

Value Stream und Value Stream Mapping

Begriff Bedeutung
Value Stream tatsächlicher oder geplanter Ende-zu-Ende-Weg zum Outcome
Value Stream Mapping strukturierte Darstellung und Untersuchung dieses Weges
Value Stream Management fortlaufende Steuerung, Messung und Verbesserung des Wertstroms

Value Stream Mapping ist damit keine einmalige Zeichenübung.

Die Abbildung soll dabei helfen:

Value Stream, Value Chain und Lifecycle unterscheiden

Begriff Bedeutung
ITIL Value System übergeordneter Rahmen für Wertschöpfung innerhalb der Organisation
Value Chain flexibles operatives Modell innerhalb des ITIL Value Systems
Product and Service Lifecycle acht allgemeine Aktivitäten über den Lebenszyklus digitaler Produkte und Services
Value Stream konkrete Ende-zu-Ende-Abfolge für ein bestimmtes Outcome
Prozess strukturierte Aktivitäten, die Eingaben in Ergebnisse überführen
Management Practice organisatorische Ressourcen und Fähigkeiten für einen bestimmten Zweck
Customer oder User Journey Erfahrung eines Kunden oder Benutzers über mehrere Interaktionen hinweg

Beispiel: neue Anwendung für eine Fachabteilung

Lifecycle

Value Stream

Bedarf der Fachabteilung erfassen
→ Lösung auswählen und bereitstellen
→ Benutzer befähigen
→ produktive Nutzung bestätigen

Beteiligte Practices

Prozesse

User Journey

Merke

Der Lifecycle stellt allgemeine Aktivitäten bereit.

Der Value Stream zeigt den konkreten Weg zum Outcome.

Practices liefern die dafür benötigten Fähigkeiten.

Value Streams überschreiten Organisationsgrenzen

Ein Value Stream endet nicht automatisch an einer Team-, Abteilungs- oder Unternehmensgrenze.

Beispiel: Internetzugang eines Standorts wiederherstellen

Mögliche Beteiligte:

Der Wertstrom endet nicht bereits dann, wenn das interne Netzwerkteam ein Ticket an den Provider übermittelt hat.

Er endet erst, wenn das gewünschte Outcome erreicht oder eine andere vereinbarte Entscheidung getroffen wurde.

Mögliches Outcome:

Der Standort besitzt wieder einen stabilen und ausreichend leistungsfähigen Internetzugang.

Typischer Fehler

Ein Team betrachtet seinen eigenen Arbeitsschritt als abgeschlossen, obwohl das Ende-zu-Ende-Outcome noch nicht erreicht wurde.

Die Grenzen eines Value Streams festlegen

Vor der Abbildung muss geklärt werden:

Unklare Abgrenzung:

Wir bilden den gesamten IT-Support ab.

Bessere Abgrenzung:

Wir bilden den Wertstrom ab, durch den ein Benutzer nach einer gemeldeten Arbeitsplatzstörung wieder arbeitsfähig wird.

Eine klare Grenze verhindert, dass die Darstellung:

wird.

Aktueller und zukünftiger Zustand

Beim Value Stream Mapping werden häufig zwei Zustände unterschieden.

Zustand Zweck
Ist-Zustand zeigt, wie die Arbeit tatsächlich heute erfolgt
Zielzustand zeigt, wie der verbesserte Wertstrom künftig funktionieren soll

Der Ist-Zustand darf nicht ausschließlich aus vorhandenen Prozessdokumentationen übernommen werden.

Er sollte anhand tatsächlicher Informationen untersucht werden.

Geeignete Quellen können sein:

Wichtig

Dokumentierter Prozess und tatsächlich gelebter Ablauf können deutlich voneinander abweichen.

Was in einer Value-Stream-Darstellung enthalten sein kann

Eine praktische Darstellung kann folgende Elemente enthalten:

Element Beispiel
Auslöser Benutzer meldet einen Incident
Stakeholder Benutzer, Service Desk und technisches Team
gewünschtes Outcome Benutzer kann wieder arbeiten
Schritt Incident erfassen
verantwortliche Rolle Service-Desk-Mitarbeiter
benötigte Information Symptome und betroffener Service
verwendetes Werkzeug Ticketsystem
beteiligte Practice Incident Management
Bearbeitungszeit 10 Minuten
Wartezeit 45 Minuten
Übergabe Service Desk an Netzwerkteam
Entscheidung Eskalation erforderlich?
Kontrolle Benutzer bestätigt Wiederherstellung
Nacharbeit Ticket wegen fehlender Informationen zurückgegeben
Lieferant Internetprovider
Risiko falsche Priorisierung
Messgröße gesamte Wiederherstellungszeit
Verbesserungsmöglichkeit Pflichtinformationen bei Erfassung verbessern

Nicht jede Darstellung muss alle Elemente enthalten.

Der Detaillierungsgrad richtet sich nach:

Eine einfache Darstellungsform

Für kleinere Wertströme kann eine Tabelle ausreichen.

Nr. Schritt Verantwortlich Ergebnis Bearbeitungszeit Wartezeit Problem
1 Anfrage erfassen Service Desk vollständiges Ticket 10 Min. 0 Min. Pflichtangaben fehlen häufig
2 Zugriff prüfen Fachverantwortlicher fachliche Freigabe 5 Min. 2 Tage keine Vertretung
3 Zugriff einrichten Administration technische Berechtigung 15 Min. 4 Std. manuelle Gruppensuche
4 Funktion testen Administration technischer Test 10 Min. 0 Min. Benutzer nicht beteiligt
5 Nutzung bestätigen Benutzer bestätigtes Outcome 5 Min. 1 Tag Rückmeldung wird nicht nachverfolgt

Gesamte Bearbeitungszeit:

45 Minuten

Gesamte Wartezeit:

mehr als 3 Tage

Das Beispiel zeigt:

Die lange Durchlaufzeit entsteht nicht hauptsächlich durch langsame technische Ausführung.

Sie entsteht überwiegend durch:

Bearbeitungszeit und Durchlaufzeit unterscheiden

Begriff Bedeutung
Bearbeitungszeit Zeit, in der aktiv an einem Vorgang gearbeitet wird
Wartezeit Zeit, in der keine wertstromrelevante Bearbeitung erfolgt
Durchlaufzeit gesamte Zeit vom Auslöser bis zum abgeschlossenen Outcome
Übergabezeit Zeit und Aufwand beim Wechsel zwischen Rollen, Teams oder Systemen
Nacharbeitszeit zusätzlicher Aufwand aufgrund unvollständiger oder fehlerhafter Arbeit

Beispiel:

Merke

Eine lange Durchlaufzeit bedeutet nicht automatisch, dass Mitarbeiter langsam arbeiten.

Häufig entstehen Verzögerungen zwischen den aktiven Arbeitsschritten.

Weitere mögliche Messgrößen

Je nach Wertstrom können unter anderem betrachtet werden:

Eine einzelne Kennzahl sollte nicht isoliert optimiert werden.

Beispiel:

Eine geringere Bearbeitungszeit kann erreicht werden, indem Tickets schneller an andere Teams weitergegeben werden.

Dadurch können jedoch:

entstehen.

Übergaben sichtbar machen

Übergaben sind Stellen, an denen Arbeit, Verantwortung oder Informationen von einer Rolle, einem Team oder einem System zu einem anderen wechseln.

Beispiele:

An Übergaben können entstehen:

Bei jeder Übergabe sollte geprüft werden:

Warteschlangen und Engpässe

Ein Engpass begrenzt den Fluss des gesamten Wertstroms.

Mögliche Engpässe sind:

Anzeichen für einen Engpass:

Wichtig

Wird nur ein Schritt vor dem eigentlichen Engpass beschleunigt, kann sich die Warteschlange am Engpass weiter vergrößern.

Nacharbeit und Rückschleifen

Nacharbeit entsteht, wenn ein Schritt erneut durchgeführt oder korrigiert werden muss.

Mögliche Ursachen:

Beispiel:

  1. Benutzer beantragt Zugriff.
  2. Administration richtet den Zugriff ein.
  3. Fachverantwortlicher stellt fest, dass der falsche Berechtigungsumfang gewählt wurde.
  4. Zugriff muss entfernt und erneut eingerichtet werden.

Die Nacharbeit erhöht:

Sie kann außerdem das Vertrauen der Stakeholder beeinträchtigen.

Kontrollen und Freigaben untersuchen

Kontrollen können notwendig sein für:

Beim Mapping sollte nicht automatisch jede Kontrolle entfernt werden.

Stattdessen wird geprüft:

Typischer Fehler

Eine Genehmigung wird entfernt, nur weil sie Zeit kostet.

Zuerst muss verstanden werden, welches Risiko oder welche Verpflichtung sie behandelt.

Arbeit mit und ohne direkten Wertbeitrag

Nicht jeder notwendige Schritt erzeugt unmittelbar einen für den Benutzer sichtbaren Wert.

Eine praktische Unterscheidung kann sein:

Kategorie Bedeutung Beispiel
direkter Wertbeitrag unterstützt unmittelbar das gewünschte Outcome benötigten Zugriff bereitstellen
notwendige unterstützende Arbeit ist für Sicherheit, Steuerung oder Zuverlässigkeit erforderlich Berechtigung prüfen
vermeidbare Arbeit besitzt keinen ausreichenden Nutzen oder entsteht durch Fehler dieselben Daten erneut erfassen
Nacharbeit korrigiert unvollständige oder fehlerhafte Ergebnisse falsche Berechtigung entfernen

Nicht sichtbare Arbeit ist nicht automatisch unnötig.

Beispiele für notwendige unterstützende Tätigkeiten:

Diese Tätigkeiten sollten jedoch:

werden.

Value Stream Mapping und die vier Dimensionen

Eine vollständige Untersuchung berücksichtigt alle vier Dimensionen.

Organizations and People

Information and Technology

Partners and Suppliers

Value Streams and Processes

Value Streams und der Product and Service Lifecycle

Die acht Lifecycle-Aktivitäten können in einem Value Stream unterschiedlich kombiniert werden.

Beispiel: neue Monitoring-Lösung einführen

Lifecycle-Aktivität Möglicher Beitrag zum Value Stream
Discover Bedarf, Ausfälle und heutige Überwachung verstehen
Design Zielarchitektur, Alarmierung und Betriebsmodell gestalten
Acquire Plattform, Lizenzen oder externe Leistungen beschaffen
Build Lösung konfigurieren, integrieren und testen
Transition Pilot und kontrollierte Einführung durchführen
Operate Plattform zuverlässig betreiben
Deliver relevante Monitoring-Leistungen für Teams bereitstellen
Support Benutzer und Administratoren bei Problemen unterstützen

Ein anderer Value Stream verwendet möglicherweise nur einen Teil dieser Aktivitäten oder wiederholt einzelne Aktivitäten mehrfach.

Merke

Der Lifecycle liefert allgemeine Aktivitätsbereiche.

Der Value Stream verbindet die konkret benötigten Schritte für ein bestimmtes Outcome.

Value Streams und Management Practices

Ein Value Stream verwendet normalerweise mehrere Practices.

Beispiel: Incident eines extern betriebenen Cloud-Service

Schritt Mögliche beteiligte Practice
Störung erkennen Monitoring and Event Management
Benutzerkontakt erfassen Service Desk
Auswirkungen und Priorität bewerten Incident Management
Abhängigkeiten ermitteln Service Configuration Management
bekannte Lösung suchen Knowledge Management
Anbieter einbinden Supplier Management
Service wiederherstellen Incident Management und technische Practices
Ursache untersuchen Problem Management
dauerhafte Korrektur steuern Change Enablement
Erfahrung auswerten Continual Improvement

Practices dürfen dabei nicht als getrennte Teilprozesse betrachtet werden, zwischen denen ein Vorgang nur weitergereicht wird.

Sie sollen gemeinsam das Ende-zu-Ende-Outcome unterstützen.

Praxisnahe Vorgehensweise zum Value Stream Mapping

Die folgende Vorgehensweise ist eine redaktionelle Praxisempfehlung dieses Buches.

Sie ist keine vorgeschriebene offizielle ITIL-Schrittfolge.

1. Zweck und Outcome festlegen

Zuerst wird geklärt:

Beispiel:

Ziel ist, neue Mitarbeiter spätestens zum vereinbarten Eintrittszeitpunkt mit einem vollständig nutzbaren und sicheren IT-Arbeitsplatz auszustatten.

2. Auslöser und Abschluss bestimmen

Auslöser:

Die Personalabteilung übermittelt eine vollständige und bestätigte Eintrittsmeldung.

Abschluss:

Der Mitarbeiter bestätigt, dass Anmeldung, Endgerät und benötigte Services funktionieren.

Dadurch wird vermieden, dass der Wertstrom zu früh endet.

3. Beteiligte Stakeholder bestimmen

Mögliche Beteiligte:

Zusätzlich sollte geklärt werden:

4. Tatsächliche Schritte erfassen

Die Beteiligten beschreiben, wie ein realer Vorgang heute abläuft.

Nicht nur:

Wie sollte der Prozess funktionieren?

Sondern:

Was geschieht tatsächlich?

Dabei können reale Tickets oder Fälle verfolgt werden.

Mögliche Schritte:

  1. Eintritt melden
  2. Rolle und Zugriffe bestimmen
  3. Freigaben einholen
  4. Endgerät bestellen
  5. Benutzerkonto erstellen
  6. Lizenzen zuweisen
  7. Endgerät konfigurieren
  8. Sicherheitsmaßnahmen aktivieren
  9. Zugriffe testen
  10. Gerät übergeben
  11. Arbeitsfähigkeit bestätigen

5. Informationen, Werkzeuge und Practices ergänzen

Für jeden Schritt wird geprüft:

Beispiel:

Schritt Information Werkzeug Practice
Endgerät bereitstellen Rolle und Hardwarestandard Asset- und Ticketsystem IT Asset Management
Konto erstellen Name, Eintrittsdatum und Organisationseinheit Verzeichnisdienst Service Request Management
Zugriffe einrichten genehmigter Berechtigungsumfang IAM-System Information Security Management
Nutzung bestätigen Benutzerfeedback Ticket oder Portal Service Desk

6. Zeiten und Übergaben erfassen

Für jeden Schritt können erfasst werden:

Nicht jede Zeit muss auf die Minute genau bekannt sein.

Auch eine erste Einteilung kann hilfreich sein:

7. Probleme und Risiken kennzeichnen

Mögliche Beobachtungen:

Probleme sollten möglichst mit Fakten oder Beispielen belegt werden.

8. Ursachen untersuchen

Nicht jedes sichtbare Problem ist die eigentliche Ursache.

Beispiel:

Symptom: Endgerät ist am ersten Arbeitstag nicht verfügbar.

Mögliche Ursachen:

Eine Verbesserung sollte möglichst die relevante Ursache behandeln und nicht nur das Symptom verschieben.

9. Zielzustand gestalten

Der Zielzustand beschreibt, wie der Wertstrom künftig funktionieren soll.

Mögliche Verbesserungen:

Der Zielzustand sollte:

sein.

10. Verbesserungen priorisieren und umsetzen

Verbesserungen können bewertet werden nach:

Nicht alle Verbesserungen müssen gleichzeitig umgesetzt werden.

Ein iteratives Vorgehen kann beispielsweise beginnen mit:

  1. vollständige Eintrittsmeldung sicherstellen
  2. klare Verantwortlichkeit festlegen
  3. Status sichtbar machen
  4. Standardpakete definieren
  5. geeignete Schritte automatisieren
  6. Wirkung messen
  7. weitere Engpässe bearbeiten

Value Stream Management nach dem Mapping

Nach der ersten Abbildung muss der Wertstrom fortlaufend gesteuert werden.

Dazu gehören:

Mögliche Fragen:

Governance von Value Streams

Für wichtige Value Streams sollte geklärt sein:

Ein Value Stream kann mehrere organisatorische Verantwortungsbereiche überschreiten.

Trotzdem muss eine geeignete Koordination des Gesamtergebnisses bestehen.

Typischer Fehler

Jeder Schritt besitzt einen Verantwortlichen, aber niemand verantwortet das gesamte Ende-zu-Ende-Outcome.

Value Stream Mapping bei einem Incident

Beispielwertstrom:

Benutzer nach einem Serviceausfall wieder arbeitsfähig machen

Mögliche Schritte:

  1. Störung erkennen oder melden
  2. Incident erfassen
  3. Auswirkungen und Dringlichkeit bewerten
  4. betroffenen Service bestimmen
  5. erste Diagnose durchführen
  6. zuständiges Fachwissen einbinden
  7. Service wiederherstellen
  8. Funktion technisch prüfen
  9. Nutzbarkeit mit dem Benutzer bestätigen
  10. Kommunikation abschließen
  11. notwendige Folgeaktivitäten einleiten

Mögliche Probleme:

Mögliche Messgrößen:

Value Stream Mapping bei einem Service Request

Beispielwertstrom:

genehmigte Standardsoftware für einen Benutzer nutzbar bereitstellen

Mögliche Schritte:

  1. Software anfordern
  2. Berechtigung und Bedarf prüfen
  3. Lizenzverfügbarkeit kontrollieren
  4. erforderliche Freigabe einholen
  5. Software bereitstellen
  6. Installation oder Zuweisung prüfen
  7. Benutzer informieren
  8. Nutzbarkeit bestätigen
  9. Asset- und Lizenzinformationen aktualisieren

Mögliche Verbesserungen:

Value Stream Mapping bei einem Change

Beispielwertstrom:

Sicherheitsupdate kontrolliert und ohne vermeidbare Serviceunterbrechung bereitstellen

Mögliche Schritte:

  1. Handlungsbedarf erkennen
  2. betroffene Produkte und Services bestimmen
  3. Risiko und Dringlichkeit bewerten
  4. Update testen
  5. Umsetzungs- und Rückfallplan erstellen
  6. Autorisierung einholen
  7. Beteiligte informieren
  8. Update bereitstellen
  9. technische Funktion prüfen
  10. Service-Nutzbarkeit prüfen
  11. Monitoring fortführen
  12. Dokumentation und Konfigurationsinformationen aktualisieren

Mögliche Probleme:

Value Streams und Automatisierung

Automatisierung kann den Fluss verbessern, wenn:

Geeignete Beispiele:

Ungeeignet ist Automatisierung, wenn:

Grundsatz

Einen schlechten Wertstrom zu automatisieren kann dazu führen, dass Fehler und Verschwendung nur schneller ausgeführt werden.

Künstliche Intelligenz in Value Streams

KI kann innerhalb von Value Streams beispielsweise unterstützen bei:

Dabei müssen unter anderem berücksichtigt werden:

Beispiel:

Eine KI schlägt die automatische Genehmigung eines Zugriffs vor.

Vor einer solchen Automatisierung muss geklärt sein:

Sicherheitsrelevant

Die Verwendung von KI verändert nicht automatisch bestehende Verantwortlichkeiten und Governance-Anforderungen.

Value Streams und Continual Improvement

Value Stream Mapping liefert eine Grundlage für Continual Improvement.

Möglicher Verbesserungszyklus:

  1. benötigtes Outcome bestimmen
  2. aktuellen Wertstrom erfassen
  3. Daten und Feedback sammeln
  4. Engpässe und Risiken erkennen
  5. Ursachen untersuchen
  6. Zielzustand gestalten
  7. Verbesserungen priorisieren
  8. schrittweise umsetzen
  9. Wirkung messen
  10. Wertstrom erneut bewerten

Verbesserungen können betreffen:

Merke

Value Stream Mapping zeigt nicht nur, wo Arbeit stattfindet.

Es zeigt, wo Wertfluss behindert wird und wo Verbesserungen ansetzen können.

Typische Fehler beim Value Stream Mapping

Fehler 1: Nur den dokumentierten Soll-Prozess abbilden

Der tatsächlich gelebte Arbeitsablauf bleibt unbekannt.

Fehler 2: An Abteilungsgrenzen aufhören

Der gesamte Weg zum Stakeholder-Outcome wird nicht betrachtet.

Fehler 3: Zu großen Umfang wählen

Der Wertstrom wird so umfangreich, dass keine konkreten Verbesserungen mehr erkennbar sind.

Fehler 4: Nur technische Schritte betrachten

Menschen, Informationen, Lieferanten, Kontrollen und Benutzererfahrung fehlen.

Fehler 5: Nur Bearbeitungszeiten messen

Wartezeit, Übergaben, Nacharbeit und Verzögerungen bleiben unsichtbar.

Fehler 6: Jede nicht sichtbare Tätigkeit als Verschwendung betrachten

Notwendige Sicherheits-, Qualitäts- oder Compliance-Kontrollen werden ungeprüft infrage gestellt.

Fehler 7: Das Diagramm als Endergebnis betrachten

Probleme werden sichtbar gemacht, aber Verbesserungen werden nicht priorisiert oder umgesetzt.

Fehler 8: Mitarbeiter für Probleme im Wertstrom verantwortlich machen

Systemische Ursachen wie fehlende Informationen, ungeeignete Werkzeuge und widersprüchliche Ziele werden übersehen.

Fehler 9: Nur einen idealen Einzelfall betrachten

Ausnahmen, Fehler, Eskalationen und Lieferantenabhängigkeiten bleiben unbekannt.

Fehler 10: Lokale Kennzahlen optimieren

Einzelne Teams verbessern ihre Werte, während sich das Ende-zu-Ende-Outcome verschlechtert.

Fehler 11: Zielzustand ohne Messgrößen gestalten

Später kann nicht festgestellt werden, ob die Verbesserung tatsächlich wirksam war.

Fehler 12: Zu früh automatisieren

Ein ungeeigneter oder instabiler Ablauf wird technisch festgeschrieben.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker sehen häufig nur einen Teil des gesamten Wertstroms.

Beispiele:

Value-Stream-Denken ergänzt folgende Fragen:

Praxistipp

Dokumentiere nicht nur, was du getan hast.

Dokumentiere auch das Ergebnis, relevante Abhängigkeiten und den nächsten notwendigen Schritt.

30-Sekunden-Prüfung eines Value Streams

  1. Auslöser: Was startet den Wertstrom?
  2. Stakeholder: Für wen wird das Outcome benötigt?
  3. Outcome: Wann ist das tatsächliche Ziel erreicht?
  4. Schritte: Welche Tätigkeiten sind notwendig?
  5. Verantwortung: Wer entscheidet und wer führt aus?
  6. Informationen: Welche Daten werden benötigt?
  7. Übergaben: Wo wechselt die Arbeit zwischen Beteiligten?
  8. Fluss: Wo entstehen Wartezeit, Nacharbeit oder Engpässe?
  9. Kontrollen: Welche Prüfungen sind wirklich erforderlich?
  10. Messung: Wie wird Erfolg festgestellt?
  11. Verbesserung: Welcher nächste Schritt verbessert den Wertstrom?

Checkliste vor dem Mapping

Checkliste für die Ist-Aufnahme

Checkliste für den Zielzustand

Checkliste nach der Verbesserung

Schnellreferenz

Frage Bedeutung
Was startet den Wertstrom? Auslöser bestimmen
Für wen wird gearbeitet? Stakeholder bestimmen
Was soll erreicht werden? Outcome definieren
Welche Schritte finden statt? tatsächlichen Arbeitsfluss erfassen
Wer ist beteiligt? Rollen, Teams und Lieferanten bestimmen
Welche Informationen werden benötigt? Informationsfluss untersuchen
Wo wartet die Arbeit? Warteschlangen erkennen
Wo wird Arbeit wiederholt? Nacharbeit erkennen
Wo wechselt Verantwortung? Übergaben untersuchen
Welche Kontrollen sind notwendig? Risiken und Vorgaben berücksichtigen
Wie wird Erfolg gemessen? geeignete Messgrößen bestimmen
Was sollte zuerst verbessert werden? Verbesserungen priorisieren

Zusammenfassende Darstellung

Bedarf, Nachfrage oder Chance
↓
Auslöser des Value Streams
↓
miteinander verbundene Schritte
↓
Menschen · Practices · Informationen · Technologien · Lieferanten
↓
Übergaben · Entscheidungen · Kontrollen · Rückmeldungen
↓
Output
↓
überprüftes Outcome
↓
gemeinsam ermöglichter Wert
↓
Feedback und Continual Improvement

Aufbau einer einfachen Value-Stream-Karte

Auslöser

Was startet den Wertstrom?

↓

Schritt 1

Verantwortliche Rolle · benötigte Information · Ergebnis

↓ Übergabe oder Wartezeit

Schritt 2

Verantwortliche Rolle · verwendete Practice · Werkzeug

↓ Entscheidung oder Kontrolle

Schritt 3

technische oder organisatorische Umsetzung

↓

Ergebnisprüfung

Funktioniert das Produkt oder der Service technisch?

↓

Outcome-Prüfung

Kann der Stakeholder das benötigte Ergebnis erreichen?

↓

Feedback und Verbesserung

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Offiziell bestätigter Stand

Die offiziellen ITIL-Version-5-Informationen bestätigen:

Einordnung

Die auf dieser Seite dargestellte Vorgehensweise zur:

ist eine praxisnahe redaktionelle Methode dieses unabhängigen Nachschlagewerks.

Sie ist keine wörtliche offizielle ITIL-Methode und keine für jede Organisation vorgeschriebene Notation.

Die konkrete Darstellungsform und der benötigte Detaillierungsgrad müssen an Ziel, Risiko, Komplexität und verfügbare Informationen angepasst werden.

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

2. ITIL verstehen – Aufbau, Prinzipien und Modelle

2.9 Continual Improvement

Kurz erklärt

Continual Improvement beschreibt die fortlaufende Verbesserung von:

Continual Improvement ist:

ITIL Version 5 verwendet ein überarbeitet formuliertes Continual Improvement Model mit sieben Schritten.

Warum Continual Improvement notwendig ist

Produkte, Services und Arbeitsweisen bleiben nicht dauerhaft optimal.

Sie werden beeinflusst durch:

Auch eine heute wirksame Lösung kann später ungeeignet werden.

Beispiele:

Merke

Verbesserung ist nicht nur notwendig, wenn etwas vollständig fehlschlägt.

Sie ist auch notwendig, damit weiterhin wirksame Produkte und Services mit veränderten Anforderungen Schritt halten.

Continual und Continuous unterscheiden

Die Begriffe werden im allgemeinen Sprachgebrauch häufig miteinander vermischt.

Begriff Vereinfachte Bedeutung
Continual Improvement wiederkehrende Verbesserungsaktivitäten in angemessenen Abständen
Continuous Improvement Verbesserung als weitgehend ununterbrochene Aktivität

ITIL verwendet den Begriff:

Continual Improvement

Das bedeutet nicht, dass jederzeit ohne Unterbrechung an jeder Sache gearbeitet werden muss.

Verbesserungen können:

werden.

Entscheidend ist, dass Verbesserung dauerhaft in der Arbeitsweise verankert bleibt.

Continual Improvement im ITIL Value System

Continual Improvement ist einer der fünf Bestandteile des ITIL Value Systems.

Das Value System verbindet:

Continual Improvement wirkt dabei nicht nur auf einen einzelnen Bereich.

Verbessert werden können:

Wichtig

Continual Improvement ist nicht nur eine nachgelagerte Tätigkeit.

Es wirkt auf alle Bestandteile des Value Systems und auf den gesamten Product and Service Lifecycle.

Continual Improvement als Management Practice

Als Management Practice benötigt Continual Improvement mehr als einzelne Verbesserungsideen.

Zu einer wirksamen Practice können gehören:

Eine Organisation kann mögliche Rollen verwenden wie:

ITIL schreibt nicht für jede Organisation dieselben Rollenbezeichnungen vor.

Entscheidend ist, dass für eine Verbesserungsinitiative geklärt ist:

Verbesserung ist Aufgabe aller Beteiligten

Continual Improvement darf nicht ausschließlich einer zentralen Verbesserungsstelle überlassen werden.

Verbesserungsmöglichkeiten können erkannt werden durch:

Beispiele:

Grundsatz

Jeder kann Verbesserungen vorschlagen.

Nicht jeder kann allein über Priorität, Ressourcen und Umsetzung entscheiden.

Verbesserung muss gesteuert werden

Ohne eine gemeinsame Arbeitsweise können Verbesserungen:

Eine wirksame Steuerung sorgt dafür, dass Verbesserungsideen:

  1. erfasst,
  2. verstanden,
  3. bewertet,
  4. priorisiert,
  5. verantwortet,
  6. umgesetzt,
  7. gemessen,
  8. und nachhaltig verankert

werden.

Das ITIL Continual Improvement Model

ITIL Version 5 verwendet ein Continual Improvement Model mit sieben Schritten.

Nr. Offizielle englische Leitfrage Praxisnahe deutsche Bedeutung
1 What is the vision? Welche Richtung, Ziele und Grenzen gelten?
2 Where are we now? Wie sieht der tatsächliche Ausgangszustand aus?
3 Where do we want to be? Welcher konkrete Zielzustand soll erreicht werden?
4 How do we get there? Welcher Weg führt vom Ausgangs- zum Zielzustand?
5 Take action Die geplanten Maßnahmen iterativ umsetzen
6 Are we getting there? Prüfen, ob die Initiative den Zielzustand tatsächlich erreicht
7 How do we keep the improvements relevant? Ergebnisse verankern und ihre weitere Relevanz sicherstellen

Versionsabhängig

Die Anzahl der Schritte wurde gegenüber ITIL 4 nicht verändert.

In ITIL Version 5 wurden einzelne Schrittbezeichnungen präzisiert.

Dieses Buch verwendet deshalb die aktuellen Bezeichnungen aus ITIL Version 5.

Das Modell ist iterativ

Die sieben Schritte bilden keine einmalig zu durchlaufende starre Abfolge.

Während einer Initiative kann es notwendig sein:

Beispiel:

Während der Umsetzung wird festgestellt, dass die angenommene Ursache nicht zutrifft.

Dann kann die Initiative zu folgenden Schritten zurückkehren:

Merke

Ein Rücksprung im Modell ist nicht automatisch ein Fehler.

Er kann zeigen, dass Feedback und neue Erkenntnisse tatsächlich berücksichtigt werden.

Das Model ist skalierbar

Das Continual Improvement Model kann für unterschiedlich große Initiativen verwendet werden.

Beispiele:

Kleine Verbesserung

Mittlere Verbesserung

Größere Verbesserung

Der Umfang der:

muss an Größe, Risiko und Komplexität angepasst werden.

1. What is the vision?

Zentrale Frage

Welche Richtung, Ziele, Rahmenbedingungen und Grenzen gelten für die Verbesserung?

Eine Verbesserung benötigt einen verständlichen Bezug zu:

Ohne eine klare Vision können zwar einzelne Maßnahmen umgesetzt werden, ihr Beitrag zum tatsächlichen Wert bleibt jedoch unklar.

Beispiel:

Unzureichende Vision:

Wir wollen das Ticketsystem verbessern.

Präzisere Vision:

Benutzer sollen Störungen und Anfragen einfach melden können. Die zuständigen Teams sollen vollständige Informationen erhalten, damit Vorgänge schneller und mit weniger Rückfragen bearbeitet werden.

Bestandteile einer Vision

Eine Vision kann unter anderem beschreiben:

Beispiel:

Der Onboarding-Wertstrom soll neue Mitarbeiter spätestens zum vereinbarten Eintrittsdatum mit einem sicheren und vollständig nutzbaren IT-Arbeitsplatz versorgen. Sicherheitsfreigaben dürfen dadurch nicht umgangen werden.

Leitfragen zu What is the vision?

Typische Fehler bei der Vision

2. Where are we now?

Zentrale Frage

Wie sieht der tatsächliche gegenwärtige Zustand aus?

Der aktuelle Zustand bildet die Ausgangsbasis für die Verbesserung.

Ohne eine nachvollziehbare Baseline kann später nicht zuverlässig festgestellt werden, ob sich etwas verbessert hat.

Zu untersuchen sind beispielsweise:

Geeignete Informationsquellen

Der Ausgangszustand kann untersucht werden anhand von:

Wichtig

Die bestehende Dokumentation zeigt möglicherweise den vorgesehenen Ablauf.

Sie beweist nicht automatisch, wie tatsächlich gearbeitet wird.

Baseline

Eine Baseline ist ein dokumentierter Ausgangswert oder Ausgangszustand, mit dem spätere Ergebnisse verglichen werden können.

Beispiele:

Die Baseline sollte:

sein.

Leitfragen zu Where are we now?

Typische Fehler bei der Ist-Analyse

3. Where do we want to be?

Zentrale Frage

Welcher konkrete und überprüfbare Zielzustand soll als Nächstes erreicht werden?

Der Zielzustand übersetzt die Vision in konkrete Outcomes und Erfolgskriterien.

Er sollte ausreichend:

sein.

Beispiel:

Vision:

Der Onboarding-Prozess soll neue Mitarbeiter rechtzeitig arbeitsfähig machen.

Konkreter Zielzustand:

Innerhalb von drei Monaten sollen mindestens 95 Prozent der vollständig und fristgerecht gemeldeten Mitarbeiter am ersten Arbeitstag über Endgerät, Benutzerkonto und genehmigte Standardzugriffe verfügen.

Critical Success Factors und Key Performance Indicators

Ein Critical Success Factor beschreibt eine Voraussetzung oder ein Ergebnis, das für den Erfolg wesentlich ist.

Beispiel:

Vollständige Eintrittsinformationen liegen rechtzeitig vor.

Ein Key Performance Indicator unterstützt die Messung.

Beispiel:

Anteil vollständiger Eintrittsmeldungen mindestens zehn Arbeitstage vor dem Eintritt.

Kennzahlen sollten nicht nur leicht messbare Aktivität abbilden.

Sie sollten einen erkennbaren Bezug besitzen zu:

Leading und Lagging Indicators

Art Bedeutung Beispiel
Leading Indicator früher Hinweis auf die wahrscheinliche Entwicklung Anteil rechtzeitig eingegangener Eintrittsmeldungen
Lagging Indicator zeigt das bereits eingetretene Ergebnis Anteil am ersten Tag vollständig arbeitsfähiger Mitarbeiter

Beide Perspektiven können gemeinsam hilfreich sein.

Nur das Endergebnis zu messen kann zu spät sein.

Nur vorbereitende Aktivität zu messen beweist noch nicht, dass das Outcome erreicht wurde.

Leitfragen zu Where do we want to be?

Typische Fehler beim Zielzustand

4. How do we get there?

Zentrale Frage

Welcher realistische Weg führt vom aktuellen zum gewünschten Zustand?

In diesem Schritt wird der Verbesserungsweg gestaltet.

Dazu können gehören:

Der Weg kann:

sein.

In komplexen Situationen ist der vollständige Weg möglicherweise nicht von Anfang an bekannt.

Dann können kleine Experimente und Feedback notwendig sein.

Verbesserungsoptionen bewerten

Mögliche Kriterien:

Beispiel:

Problem:

Viele Tickets enthalten unvollständige Informationen.

Mögliche Optionen:

Nicht jede Option muss gleichzeitig umgesetzt werden.

Verbesserungsplan

Ein Verbesserungsplan kann enthalten:

Feld Inhalt
Maßnahme Was wird verändert?
Verantwortlich Wer koordiniert die Umsetzung?
Ziel Welches Outcome wird unterstützt?
Priorität Wie wichtig und dringend ist die Maßnahme?
Ressourcen Welche Zeit, Fähigkeiten und Mittel werden benötigt?
Abhängigkeiten Was muss vorher oder gleichzeitig geschehen?
Risiken Welche negativen Folgen sind möglich?
Messung Wie wird die Wirkung festgestellt?
Termin Wann beginnt und endet die nächste Iteration?
Status geplant, aktiv, blockiert, abgeschlossen oder verworfen

Leitfragen zu How do we get there?

Typische Fehler bei der Planung

5. Take action

Zentrale Aufgabe

Die geplanten Maßnahmen kontrolliert und möglichst iterativ umsetzen.

Eine Verbesserung entsteht nicht durch:

allein.

Die Maßnahme muss umgesetzt und ihre Wirkung beobachtet werden.

ITIL Version 5 betont bei diesem Schritt ein iteratives Vorgehen mit Möglichkeiten:

Iterative Umsetzung

Eine mögliche Vorgehensweise ist:

  1. kleinen sinnvollen Umfang auswählen
  2. Erfolgskriterien festlegen
  3. Maßnahme umsetzen
  4. Ergebnis beobachten
  5. Feedback erfassen
  6. Probleme und Nebenwirkungen untersuchen
  7. Vorgehensweise anpassen
  8. nächste Iteration durchführen

Beispiel: Verbesserung des Monitoring

Iteration 1

Auswertung

Iteration 2

Organizational Change Management

Viele Verbesserungen verändern nicht nur Technik.

Sie verändern möglicherweise:

Deshalb kann Organizational Change Management notwendig sein.

Zu berücksichtigen sind:

Typischer Fehler

Eine neue Arbeitsweise wird technisch bereitgestellt, aber von den Beteiligten nicht verstanden oder verwendet.

Leitfragen zu Take action

Typische Fehler bei der Umsetzung

6. Are we getting there?

Zentrale Frage

Führt die Initiative tatsächlich zum gewünschten Zielzustand?

In diesem Schritt wird der neue aktuelle Zustand mit folgenden Bezugspunkten verglichen:

Es wird nicht nur geprüft, ob Maßnahmen ausgeführt wurden.

Es wird geprüft, ob sie die erwartete Wirkung erzeugen.

Aktivität und Wirkung unterscheiden

Aktivität Wirkung
neues Monitoring installiert relevante Störungen werden früher erkannt
Schulung durchgeführt Mitarbeiter wenden die neue Arbeitsweise korrekt an
Wissensartikel veröffentlicht Lösungen werden schneller gefunden und erfolgreich verwendet
Pflichtfeld ergänzt Tickets enthalten vollständigere Informationen
Backup-System aktualisiert Wiederherstellungen funktionieren innerhalb der benötigten Ziele
Automatisierung eingerichtet Durchlaufzeit und Fehlerquote sinken

Merke

Eine umgesetzte Maßnahme beweist noch keine erfolgreiche Verbesserung.

Ergebnisse vergleichen

Beispiel:

Baseline

Zielzustand

Nach der ersten Iteration

Bewertung:

Quantitative und qualitative Informationen

Quantitative Informationen:

Qualitative Informationen:

Beide Informationsarten können notwendig sein.

Beispiel:

Die Bearbeitungszeit sinkt.

Mitarbeiter berichten jedoch, dass sie zur Zielerreichung notwendige Dokumentation überspringen.

Die Verbesserung kann dadurch neue Risiken erzeugen.

Leitfragen zu Are we getting there?

Wenn eine Verbesserung nicht wirkt

Mögliche Ursachen:

Eine nicht erfolgreiche Initiative sollte nicht automatisch verborgen werden.

Sie kann wichtige Erkenntnisse liefern.

Grundsatz

Ein kontrolliertes Experiment ohne erwarteten Erfolg kann wertvoll sein, wenn die Erkenntnisse dokumentiert und verwendet werden.

7. How do we keep the improvements relevant?

Zentrale Frage

Wie werden die Ergebnisse verankert und unter veränderten Bedingungen weiterhin relevant gehalten?

Eine Verbesserung kann kurzfristig erfolgreich sein und später wieder verloren gehen.

Mögliche Ursachen:

ITIL Version 5 betont deshalb nicht nur das Aufrechterhalten von Dynamik, sondern die fortlaufende Relevanz der Verbesserung.

Verbesserung verankern

Mögliche Maßnahmen:

Knowledge Management

Erkenntnisse sollten so dokumentiert werden, dass andere Beteiligte sie nutzen können.

Dazu können gehören:

Praxistipp

Dokumentiere nicht nur, was erfolgreich war.

Dokumentiere auch, welche Ansätze nicht funktioniert haben und warum.

Relevanz regelmäßig überprüfen

Eine Verbesserung kann später angepasst oder aufgehoben werden müssen.

Beispiel:

Eine zusätzliche Genehmigungsstufe wurde nach einem Sicherheitsvorfall eingeführt.

Später wird eine technische Kontrolle implementiert, die das Risiko automatisch behandelt.

Dann sollte geprüft werden:

Merke

Eine Verbesserung ist nicht dauerhaft richtig, nur weil sie zum Zeitpunkt ihrer Einführung sinnvoll war.

Leitfragen zu How do we keep the improvements relevant?

Typische Fehler bei der Verankerung

Continual Improvement Register

Ein Continual Improvement Register ist ein mögliches Hilfsmittel zur Erfassung und Steuerung von Verbesserungen.

Es kann enthalten:

Feld Inhalt
ID eindeutige Kennung
Titel kurze Beschreibung
Auslöser Problem, Feedback, Risiko oder Chance
betroffenes Produkt oder Service fachlicher Bezug
gewünschtes Outcome erwartetes Ergebnis
Ausgangszustand bekannte Baseline
Vorschlag mögliche Maßnahme
Nutzen erwarteter Wertbeitrag
Risiko mögliche negative Auswirkungen
Aufwand erwarteter Ressourceneinsatz
Priorität Reihenfolge der Bearbeitung
Verantwortlich Improvement Owner
Status neu, bewertet, geplant, aktiv, blockiert, abgeschlossen oder verworfen
Messgrößen Kriterien zur Erfolgskontrolle
Erkenntnisse Ergebnisse und Lessons Learned

Das Register kann umgesetzt werden als:

Wichtig

ITIL schreibt kein bestimmtes Werkzeug und kein universelles Registerformat vor.

Möglicher Status einer Verbesserung

Status Bedeutung
Neu Idee oder Problem wurde erfasst
Zu prüfen weitere Informationen werden benötigt
Bewertet Nutzen, Risiko und Aufwand wurden untersucht
Priorisiert Reihenfolge wurde festgelegt
Geplant Maßnahmen und Ressourcen sind vorgesehen
Aktiv Umsetzung läuft
Blockiert Abhängigkeit oder Hindernis verhindert Fortschritt
In Auswertung Wirkung wird gemessen
Abgeschlossen Zielzustand wurde ausreichend erreicht und verankert
Zurückgestellt derzeit keine ausreichende Priorität oder Ressource
Verworfen Initiative wird begründet nicht weitergeführt

Verbesserungen priorisieren

Nicht jede gute Idee kann sofort umgesetzt werden.

Mögliche Bewertungskriterien:

Eine einfache Priorisierung kann beispielsweise betrachten:

Kriterium Frage
Wirkung Wie stark verbessert sich das Outcome?
Dringlichkeit Welche Folgen besitzt eine Verzögerung?
Risiko Welches Risiko wird reduziert oder neu erzeugt?
Aufwand Welche Ressourcen werden benötigt?
Abhängigkeit Was muss vorher geschehen?
Sicherheit Besteht unmittelbarer Handlungsbedarf?
Machbarkeit Kann die Initiative erfolgreich umgesetzt werden?

Typischer Fehler

Die lauteste Forderung oder die technisch interessanteste Idee erhält automatisch die höchste Priorität.

Quick Wins

Ein Quick Win ist eine Verbesserung, die:

erzeugen kann.

Beispiele:

Quick Wins können sinnvoll sein, um:

Sie dürfen jedoch nicht dauerhaft wichtigere strukturelle Verbesserungen verdrängen.

Merke

Schnell umsetzbar bedeutet nicht automatisch besonders wertvoll.

Hoher Wert bedeutet nicht automatisch schnell umsetzbar.

Verbesserung und Problem Management unterscheiden

Continual Improvement Problem Management
verbessert Produkte, Services, Practices und Arbeitsweisen reduziert Wahrscheinlichkeit und Auswirkungen von Incidents
kann durch Chancen oder Feedback ausgelöst werden wird häufig durch Incidents, Muster oder Risiken ausgelöst
betrachtet unterschiedliche Verbesserungsgegenstände konzentriert sich auf Ursachen und mögliche Ursachen von Incidents
verwendet Verbesserungsinitiativen verwendet Problems, Known Errors und Workarounds

Beide Practices können zusammenwirken.

Beispiel:

Problem Management erkennt, dass Zertifikate nicht zentral verwaltet werden.

Continual Improvement kann anschließend koordinieren:

Verbesserung und Incident Management unterscheiden

Incident Management Continual Improvement
begrenzt aktuelle negative Serviceauswirkungen verbessert zukünftige Produkte, Services oder Arbeitsweisen
priorisiert Wiederherstellung priorisiert nachhaltige Veränderung
arbeitet häufig unter Zeitdruck kann strukturiert und iterativ umgesetzt werden
kann eine Zwischenlösung verwenden bewertet, wie Ursachen und Arbeitsweisen verbessert werden

Beispiel:

Ein Dienst wird neu gestartet und funktioniert wieder.

Verbesserung und Change Enablement unterscheiden

Continual Improvement Change Enablement
bestimmt und steuert Verbesserungsbedarf unterstützt erfolgreiche Änderungen
richtet Maßnahmen an Outcomes und Wert aus bewertet unter anderem Nutzen, Risiko und Autorisierung konkreter Changes
kann mehrere Changes enthalten behandelt eine konkrete Änderung oder ein Change-Modell

Eine Verbesserungsinitiative kann mehrere Changes benötigen.

Beispiel:

Verbesserungsinitiative:

Zertifikatsmanagement zuverlässiger gestalten.

Mögliche Changes:

Verbesserung und Transformation unterscheiden

Continual Improvement und Transformation überschneiden sich, besitzen aber unterschiedliche typische Anwendungsbereiche.

Continual Improvement Transformation
kann lokal oder schrittweise angewendet werden betrifft häufig umfangreiche organisatorische Veränderungen
eignet sich für konkrete Produkte, Services und Practices kann das gesamte Value System oder große Organisationsbereiche verändern
kann mit begrenztem Umfang und kurzer Laufzeit erfolgen umfasst häufig viele Stakeholder, Abhängigkeiten und längere Zeiträume
verwendet das Continual Improvement Model ITIL Version 5 besitzt zusätzlich ein eigenes Transformation Model

Eine Transformation benötigt ebenfalls:

Wichtig

Nicht jede Verbesserung ist eine Transformation.

Eine Transformation ohne Continual Improvement kann ihre Wirkung jedoch später wieder verlieren.

Verbesserung und Maturity Assessment unterscheiden

Ein Maturity Assessment bewertet Fähigkeiten oder Reife im Vergleich zu einem festgelegten Modell.

Es kann Informationen liefern für:

Das Assessment selbst verbessert jedoch noch nichts.

Es liefert Erkenntnisse, auf deren Grundlage Verbesserungen geplant werden können.

Typischer Fehler

Ein höherer Reifegrad wird als Selbstzweck verfolgt, ohne zu prüfen, ob dadurch relevante Outcomes verbessert werden.

Continual Improvement im Product and Service Lifecycle

Continual Improvement wirkt auf alle acht Lifecycle-Aktivitäten.

Lifecycle-Aktivität Beispielhafte Verbesserung
Discover Bedürfnisse und Feedback systematischer erfassen
Design Sicherheit, Betrieb und Erfahrung früher einbeziehen
Acquire Lieferanten- und Exit-Risiken besser bewerten
Build Tests und Konfiguration stärker automatisieren
Transition Pilotierung, Kommunikation und Rückfallplanung verbessern
Operate technische Schulden reduzieren und Überwachung optimieren
Deliver Serviceangebote und Stakeholder-Outcomes verbessern
Support Wissen, Kommunikation und Wiederherstellung beschleunigen

Erkenntnisse aus einer späteren Aktivität können Verbesserungen in früheren Aktivitäten auslösen.

Beispiel:

Support erkennt wiederkehrende Bedienprobleme.

Daraus können Verbesserungen entstehen in:

Die sieben Guiding Principles bei Verbesserungen

Guiding Principle Anwendung bei Continual Improvement
Focus on value Verbesserung am benötigten Outcome ausrichten
Start where you are Baseline und funktionierende Bestandteile berücksichtigen
Progress iteratively with feedback kontrollierte Schritte und regelmäßige Auswertung verwenden
Collaborate and promote visibility Stakeholder beteiligen und Fortschritt sichtbar machen
Think and work holistically alle vier Dimensionen und Abhängigkeiten betrachten
Keep it simple and practical angemessenen Umfang und verständliche Maßnahmen wählen
Optimize and automate Arbeitsweise zuerst verbessern und danach sinnvoll automatisieren

Die vier Dimensionen bei Verbesserungen

Organizations and People

Information and Technology

Partners and Suppliers

Value Streams and Processes

Praxisbeispiel: Zertifikate laufen wiederholt ab

Ausgangssituation

Mehrere Services waren innerhalb eines Jahres durch abgelaufene Zertifikate beeinträchtigt.

1. What is the vision?

Zertifikate kritischer Services sollen rechtzeitig erneuert werden, damit vermeidbare Ausfälle verhindert werden.

2. Where are we now?

3. Where do we want to be?

4. How do we get there?

5. Take action

6. Are we getting there?

7. How do we keep the improvements relevant?

Praxisbeispiel: Onboarding dauert zu lange

Vision

Neue Mitarbeiter sollen am ersten Arbeitstag sicher und vollständig arbeiten können.

Ausgangszustand

Zielzustand

Mögliche Maßnahmen

Messung

Praxisbeispiel: Zu viele Monitoring-Alarme

Vision

Administratoren sollen relevante Zustandsänderungen rechtzeitig erkennen, ohne durch unnötige Meldungen überlastet zu werden.

Ausgangszustand

Zielzustand

Mögliche Maßnahmen

Praxisbeispiel: Knowledge-Base wird kaum genutzt

Vision

Mitarbeiter und Benutzer sollen verlässliches Wissen schnell finden und erfolgreich anwenden können.

Ausgangszustand

Zielzustand

Mögliche Maßnahmen

Continual Improvement bei einem Incident

Nach einem Incident können Verbesserungsmöglichkeiten entstehen bei:

Nicht jeder Incident benötigt eine umfangreiche Verbesserungsinitiative.

Eine Initiative ist besonders sinnvoll, wenn:

Lessons Learned und Post-Incident Review

Eine nachgelagerte Überprüfung kann untersuchen:

Wichtig

Ein Lessons-Learned-Dokument allein erzeugt keine Verbesserung.

Erkenntnisse müssen in verantwortete und priorisierte Maßnahmen überführt werden.

Fehlerkultur

Continual Improvement benötigt eine Umgebung, in der:

werden können.

Eine Untersuchung sollte nicht vorschnell nach einer schuldigen Person suchen.

Zu prüfen sind ebenfalls:

Grundsatz

Individuelles Fehlverhalten darf nicht ignoriert werden.

Eine ausschließliche Schuldzuweisung kann jedoch systemische Ursachen verdecken.

Messung und Reporting

Eine Verbesserung benötigt passende Informationen.

Messgrößen sollten beantworten:

Mögliche Messgrößen:

Kennzahlen gemeinsam betrachten

Einzelne Kennzahlen können irreführend sein.

Beispiel:

Die durchschnittliche Ticketbearbeitungszeit wurde um 30 Prozent reduziert.

Zusätzlich sollte geprüft werden:

Typischer Fehler

Eine Kennzahl verbessert sich, während sich der gesamte Wertstrom oder die Benutzererfahrung verschlechtert.

Automatisierung bei Continual Improvement

Automatisierung kann Verbesserungen unterstützen durch:

Automatisierung kann jedoch keine fehlende:

ersetzen.

Grundsatz

Nicht die Verbesserungsidee automatisieren, sondern einen verstandenen und geeigneten Zielzustand.

Künstliche Intelligenz bei Continual Improvement

KI kann beispielsweise unterstützen bei:

Dabei müssen berücksichtigt werden:

Beispiel:

Eine KI erkennt, dass viele Tickets den Begriff „Anmeldung“ enthalten.

Das beweist noch nicht:

Die Muster müssen fachlich untersucht und eingeordnet werden.

Typische Fehler bei Continual Improvement

Fehler 1: Verbesserung nur nach Störungen

Chancen, Feedback und technische Schulden werden nicht berücksichtigt.

Fehler 2: Keine klare Vision

Maßnahmen werden umgesetzt, ohne ihren Beitrag zu Outcomes und Wert zu verstehen.

Fehler 3: Keine Baseline

Später kann nicht festgestellt werden, ob sich der Zustand tatsächlich verbessert hat.

Fehler 4: Aktivität mit Wirkung verwechseln

Ein Werkzeug wurde eingeführt oder eine Schulung durchgeführt, aber das Outcome bleibt unverändert.

Fehler 5: Zu viele Initiativen beginnen

Ressourcen werden auf viele Vorhaben verteilt, während kaum eine Initiative abgeschlossen wird.

Fehler 6: Nur Quick Wins umsetzen

Größere strukturelle Risiken und Engpässe bleiben dauerhaft bestehen.

Fehler 7: Verbesserung als Zusatzarbeit behandeln

Es werden keine realistischen Ressourcen, Befugnisse oder Zeitfenster bereitgestellt.

Fehler 8: Mitarbeiter nicht einbeziehen

Die neue Arbeitsweise passt nicht zur tatsächlichen Situation oder wird nicht angenommen.

Fehler 9: Nach der Umsetzung nicht messen

Ob die Verbesserung wirkt oder neue Probleme erzeugt, bleibt unbekannt.

Fehler 10: Ergebnisse nicht verankern

Die Organisation kehrt nach kurzer Zeit zur bisherigen Arbeitsweise zurück.

Fehler 11: Lessons Learned nicht weiterverfolgen

Erkenntnisse werden dokumentiert, aber nicht priorisiert und umgesetzt.

Fehler 12: Kennzahlen isoliert optimieren

Lokale Zielwerte verbessern sich, während Wertstrom und Stakeholder-Erfahrung schlechter werden.

Fehler 13: Improvement Register als Ablage verwenden

Viele Ideen werden erfasst, aber nicht bewertet, priorisiert oder abgeschlossen.

Fehler 14: Verbesserung mit Transformation verwechseln

Eine kleine lokale Anpassung wird unnötig als umfangreiches Veränderungsprogramm organisiert.

Fehler 15: Frühere Verbesserung nie erneut prüfen

Eine einst sinnvolle Kontrolle oder Arbeitsweise bleibt bestehen, obwohl sie inzwischen unnötig oder ungeeignet ist.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker erkennen häufig Verbesserungsmöglichkeiten direkt im technischen Betrieb.

Beispiele:

Eine gute Verbesserungsidee sollte nicht nur lauten:

Das sollten wir automatisieren.

Sie sollte möglichst beantworten:

Beispiel für einen Verbesserungsvorschlag

Unpräzise:

Wir brauchen besseres Monitoring.

Präziser:

Bei drei Incidents innerhalb der letzten sechs Monate wurde der Ausfall des internen DNS-Dienstes erst durch Benutzermeldungen erkannt. Vorgeschlagen wird eine aktive Funktionsprüfung der DNS-Auflösung mit Alarmierung des Bereitschaftsteams. Erfolgskriterium ist, dass ein Ausfall innerhalb von fünf Minuten erkannt und eindeutig dem DNS-Service zugeordnet wird.

30-Sekunden-Prüfung einer Verbesserung

  1. Vision: Warum ist die Verbesserung wichtig?
  2. Ist-Zustand: Welche Daten und Beobachtungen liegen vor?
  3. Zielzustand: Was soll konkret besser werden?
  4. Weg: Welche Maßnahme ist geeignet?
  5. Aktion: Wer setzt den nächsten Schritt um?
  6. Messung: Woran erkennen wir Fortschritt und Erfolg?
  7. Verankerung: Wie bleibt die Verbesserung wirksam und relevant?

Checkliste für eine neue Verbesserungsidee

Checkliste für eine Verbesserungsinitiative

Checkliste während der Umsetzung

Checkliste zur Erfolgskontrolle

Checkliste zur Verankerung

Schnellreferenz des Continual Improvement Models

Schritt Kurzfrage Typisches Ergebnis
1 What is the vision? Richtung, Zweck und Grenzen
2 Where are we now? Ausgangszustand und Baseline
3 Where do we want to be? Zielzustand und Erfolgskriterien
4 How do we get there? Verbesserungsplan und nächste Schritte
5 Take action umgesetzte Maßnahmen und Feedback
6 Are we getting there? Wirkungsprüfung und Anpassungsentscheidung
7 How do we keep the improvements relevant? verankerte und weiterhin überprüfte Verbesserung

Zusammenfassende Darstellung

What is the vision?
Richtung und Zweck klären
↓
Where are we now?
aktuellen Zustand und Baseline erfassen
↓
Where do we want to be?
Zielzustand und Erfolgskriterien bestimmen
↓
How do we get there?
geeigneten Verbesserungsweg planen
↓
Take action
Maßnahmen iterativ umsetzen
↓
Are we getting there?
Fortschritt, Wirkung und Nebenwirkungen prüfen
↓
How do we keep the improvements relevant?
Ergebnisse verankern und regelmäßig neu bewerten
↓
neue Erkenntnisse und weitere Verbesserungsmöglichkeiten
↓
erneute Anwendung des Modells

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Ergänzende offizielle Community-Quelle

Offiziell bestätigter Stand

Die aktuellen offiziellen ITIL-Version-5-Informationen bestätigen:

Einordnung

Die ausführlichen:

sind zusätzliche herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen und keine für jede Organisation vorgeschriebene Verbesserungsmethode dar.

Rollen, Messgrößen, Werkzeuge, Priorisierungsverfahren und Dokumentationsumfang müssen an Ziel, Risiko, Größe und Arbeitsweise der jeweiligen Organisation angepasst werden.

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

2. ITIL verstehen – Aufbau, Prinzipien und Modelle

2.10 ITIL an den eigenen Kontext anpassen

Kurz erklärt

ITIL ist kein fertiger Musterprozess, der unverändert in jede Organisation übernommen werden kann.

Das Framework stellt:

bereit.

Die konkrete Organisation muss daraus eine Arbeitsweise gestalten, die zu ihren:

passt.

ITIL soll deshalb übernommen und angepasst werden.

Eine sinnvolle Anpassung bewahrt Zweck und Nutzen der Guidance, ohne unnötige Komplexität zu erzeugen.

Warum ITIL angepasst werden muss

Organisationen unterscheiden sich erheblich.

Beispiele:

Für alle diese Organisationen können ITIL-Konzepte hilfreich sein.

Sie benötigen jedoch nicht:

Merke

Gleiche ITIL-Grundgedanken können in unterschiedlichen Organisationen zu unterschiedlichen praktischen Umsetzungen führen.

Anpassen bedeutet nicht beliebig auswählen

ITIL an den Kontext anzupassen bedeutet nicht:

Eine Anpassung sollte nachvollziehbar beantworten:

Grundsatz

Anpassung verändert die konkrete Umsetzung.

Sie darf nicht dazu führen, dass der eigentliche Zweck einer Practice, Kontrolle oder Verantwortung verloren geht.

ITIL wird nicht installiert

Ein ITSM-Werkzeug kann installiert werden.

Ein Framework kann dagegen nicht wie eine Software vollständig „installiert“ werden.

ITIL stellt einen Orientierungsrahmen bereit.

Die Organisation muss selbst gestalten:

Typischer Fehler

Eine Organisation kauft ein ITSM-Werkzeug mit vorkonfigurierten ITIL-Modulen und betrachtet die Einführung damit als abgeschlossen.

Das Werkzeug kann die Arbeitsweise unterstützen. Es ersetzt jedoch keine geklärten Ziele, Verantwortlichkeiten, Fähigkeiten und Wertströme.

Die wichtigsten Kontextfaktoren

Vor der Gestaltung einer ITIL-basierten Arbeitsweise sollten mindestens folgende Kontextfaktoren betrachtet werden:

Kontextfaktor Beispielhafte Fragen
Ziele und Strategie Welche geschäftlichen und organisatorischen Ergebnisse sollen unterstützt werden?
Produkte und Services Welche Leistungen werden angeboten und wie kritisch sind sie?
Stakeholder Wer nutzt, finanziert, unterstützt oder beeinflusst die Produkte und Services?
Größe und Struktur Wie viele Benutzer, Teams, Standorte und Organisationseinheiten existieren?
Risiken Welche Ausfälle, Sicherheitsvorfälle oder Fehlentscheidungen wären besonders schwerwiegend?
Gesetze und Verträge Welche rechtlichen, regulatorischen und vertraglichen Verpflichtungen gelten?
Betriebsmodell Wird intern, extern, hybrid, agil, produktorientiert oder projektorientiert gearbeitet?
Fähigkeiten Welche Kenntnisse, Erfahrungen und Kapazitäten sind vorhanden?
Technologie Welche Infrastruktur, Anwendungen, Cloud-Dienste und Automatisierungen werden eingesetzt?
Lieferanten Welche Produkte und Services hängen von externen Anbietern ab?
Kultur Wie werden Entscheidungen, Fehler, Zusammenarbeit und Verantwortung tatsächlich behandelt?
Reife und Ausgangslage Welche Arbeitsweisen funktionieren bereits und wo bestehen erkennbare Schwächen?
Kosten und Ressourcen Welcher Aufwand ist vertretbar und welche Ressourcen stehen zur Verfügung?
Veränderungsgeschwindigkeit Wie häufig ändern sich Produkte, Anforderungen und Technologien?
Erfahrung der Stakeholder Wie erleben Benutzer, Kunden und Mitarbeiter die vorhandenen Services?

Die Ziele der Organisation zuerst verstehen

Die Einführung einer Practice sollte nicht mit einem Prozessdiagramm beginnen.

Zuerst muss geklärt werden, welches Ergebnis verbessert werden soll.

Unzureichendes Ziel:

Wir möchten Incident Management einführen.

Besser:

Benutzer sollen nach ungeplanten Serviceunterbrechungen schneller wieder arbeitsfähig werden. Auswirkungen, Verantwortung und Kommunikation müssen dabei nachvollziehbar sein.

Unzureichendes Ziel:

Wir benötigen eine CMDB.

Besser:

Bei Incidents und Changes fehlen verlässliche Informationen über kritische Serviceabhängigkeiten. Dadurch dauern Analysen länger und Änderungen verursachen unerwartete Auswirkungen.

Unzureichendes Ziel:

Wir wollen ITIL-konform arbeiten.

Besser:

Wir wollen unsere wichtigsten Services nachvollziehbar steuern, Störungen verlässlich bearbeiten, Änderungen kontrollieren und wiederkehrende Fehler systematisch reduzieren.

Merke

ITIL ist ein Hilfsmittel zur Verbesserung von Produkten, Services und Outcomes.

Die Einführung von ITIL-Begriffen ist kein eigenständiges geschäftliches Outcome.

Nicht mit allen 34 Practices gleichzeitig beginnen

ITIL Version 5 enthält 34 Management Practices.

Eine Organisation muss nicht alle Practices gleichzeitig vollständig ausgestalten.

Eine sinnvollere Vorgehensweise ist:

  1. wichtige Produkte und Services bestimmen
  2. konkrete Probleme und Chancen erfassen
  3. relevante Wertströme untersuchen
  4. benötigte Practices identifizieren
  5. vorhandene Fähigkeiten bewerten
  6. wichtigste Lücken priorisieren
  7. kleine wirksame Verbesserungen umsetzen
  8. Ergebnisse messen
  9. weitere Practices oder Fähigkeiten schrittweise entwickeln

Beispiel:

Eine Organisation besitzt folgende Probleme:

Zunächst besonders relevant können sein:

Andere Practices bleiben ebenfalls wichtig, müssen aber möglicherweise nicht mit derselben Priorität entwickelt werden.

Vom Problem zur benötigten Practice

Beobachtetes Problem Möglicherweise relevante Practices
Benutzer wissen nicht, wohin sie sich wenden sollen. Service Desk, Service Catalogue Management
Incidents werden uneinheitlich bearbeitet. Incident Management, Knowledge Management
dieselben Störungen treten regelmäßig erneut auf Problem Management, Continual Improvement
Changes verursachen unerwartete Ausfälle Change Enablement, Service Configuration Management, Service Validation and Testing
technische Abhängigkeiten sind unbekannt Service Configuration Management, Architecture Management
Hardware und Lizenzen sind nicht nachvollziehbar IT Asset Management, Supplier Management
Monitoring erzeugt zu viele unbrauchbare Meldungen Monitoring and Event Management, Continual Improvement
Lieferanten werden bei Incidents zu spät eingebunden Supplier Management, Incident Management
Benutzer erhalten unverständliche Serviceinformationen Service Catalogue Management, Relationship Management
Kapazitätsprobleme werden erst nach Ausfällen erkannt Capacity and Performance Management, Monitoring and Event Management
Wiederherstellungen sind nicht ausreichend vorbereitet Service Continuity Management, Availability Management
Wissen befindet sich nur bei einzelnen Personen Knowledge Management, Workforce and Talent Management

Diese Zuordnung ist eine erste Orientierung.

Die tatsächliche Situation kann Beiträge mehrerer Practices und Kontextfaktoren erfordern.

Die sieben Guiding Principles zur Anpassung verwenden

Die Guiding Principles unterstützen die Entscheidung, wie ITIL angemessen übernommen wird.

Focus on value

Fragen:

Beispiel:

Ein neues Pflichtfeld im Ticketsystem ist nur sinnvoll, wenn die Information tatsächlich:

ermöglicht.

Start where you are

Fragen:

Eine Organisation sollte vorhandene Fähigkeiten nicht allein deshalb verwerfen, weil sie nicht mit offiziellen ITIL-Begriffen bezeichnet wurden.

Beispiel:

Ein kleines Team besitzt bereits:

Diese Bestandteile können weiterentwickelt werden, statt ein vollständig neues und komplexes Modell einzuführen.

Progress iteratively with feedback

Fragen:

Beispiel:

Statt sofort sämtliche Serviceprozesse neu zu gestalten, kann zunächst der Incident-Wertstrom eines besonders wichtigen Service verbessert werden.

Collaborate and promote visibility

Fragen:

Eine ITIL-Einführung, die ausschließlich innerhalb eines kleinen Prozess- oder Toolteams gestaltet wird, kann den tatsächlichen Arbeitsalltag verfehlen.

Think and work holistically

Fragen:

Beispiel:

Die Einführung eines Change-Prozesses beeinflusst möglicherweise:

Keep it simple and practical

Fragen:

Merke

Einfach bedeutet nicht unkontrolliert.

Einfach bedeutet zweckmäßig, verständlich und frei von unnötiger Komplexität.

Optimize and automate

Fragen:

Ein ungeeigneter Ablauf sollte nicht unverändert automatisiert werden.

Alle vier Dimensionen berücksichtigen

Die Anpassung einer Practice muss alle vier Dimensionen einbeziehen.

Organizations and People

Zu klären sind beispielsweise:

Beispiel:

Ein neuer Incident-Prozess kann fachlich gut beschrieben sein.

Er bleibt dennoch unwirksam, wenn:

Information and Technology

Zu klären sind beispielsweise:

Beispiel:

Eine Prioritätsmatrix funktioniert nur, wenn ausreichende Informationen über:

vorliegen.

Partners and Suppliers

Zu klären sind beispielsweise:

Beispiel:

Ein Incident-Prozess ist unvollständig, wenn ein kritischer Cloud-Provider beteiligt ist, aber:

festgelegt wurden.

Value Streams and Processes

Zu klären sind beispielsweise:

Die Anpassung sollte nicht nur einen isolierten Prozessschritt optimieren.

Sie sollte den gesamten Wertstrom berücksichtigen.

Practices an Wertströmen ausrichten

Practices besitzen einen bestimmten Zweck.

Wert entsteht jedoch durch das Zusammenwirken mehrerer Practices in konkreten Wertströmen.

Beispielwertstrom:

Benutzer nach einer Störung wieder arbeitsfähig machen

Möglicherweise beteiligt:

Die Organisation sollte deshalb nicht nur fragen:

Wie sieht unser Incident-Management-Prozess aus?

Zusätzlich sollte sie fragen:

Angemessene Rollen festlegen

ITIL nennt verschiedene mögliche Rollen.

Eine Organisation muss jedoch nicht für jede Rolle eine eigene Vollzeitstelle schaffen.

Kleine Organisation:

Eine Person kann mehrere Rollen übernehmen, beispielsweise:

Große Organisation:

Diese Verantwortlichkeiten können auf mehrere spezialisierte Rollen verteilt werden.

Entscheidend ist nicht die Anzahl der Rollennamen.

Entscheidend ist, dass geklärt ist:

Wichtig

Eine Person kann mehrere Rollen besitzen.

Kritische Funktionstrennungen sowie gesetzliche und sicherheitsrelevante Anforderungen müssen trotzdem berücksichtigt werden.

Rollenbezeichnungen dürfen angepasst werden

Eine Organisation kann eigene Begriffe verwenden.

Beispiele:

ITIL-Begriff Mögliche interne Bezeichnung
Service Desk Helpdesk, IT-Support oder Benutzerbetreuung
Incident Störung
Service Request Standardanfrage oder Leistungsanforderung
Change Enablement Change Management oder Änderungssteuerung
Service Owner Serviceverantwortlicher
Supplier Management Lieferantensteuerung
Continual Improvement kontinuierliche Verbesserung oder Verbesserungsmanagement

Die interne Bezeichnung ist weniger wichtig als eine eindeutige Bedeutung.

Problematisch ist es, wenn derselbe Begriff in verschiedenen Teams unterschiedliche Bedeutungen besitzt.

Beispiel:

Das Wort „Problem“ kann im allgemeinen Sprachgebrauch jede Schwierigkeit bezeichnen.

Im ITIL-Kontext besitzt Problem Management einen bestimmten Zweck im Zusammenhang mit Ursachen oder möglichen Ursachen von Incidents.

Praxistipp

Erstelle ein kurzes internes Glossar für wichtige Begriffe.

Es muss verständlich erklären, wie die Organisation die Begriffe praktisch verwendet.

Dokumentationsumfang anpassen

Nicht jeder Vorgang benötigt dieselbe Dokumentation.

Der Umfang sollte sich richten nach:

Beispiel:

Einfache Standardanfrage

Kritischer Change

Grundsatz

Dokumentation muss eine Entscheidung, Ausführung, Kontrolle oder spätere Nutzung unterstützen.

Daten ohne erkennbaren Zweck sollten nicht nur aus Gewohnheit erhoben werden.

Kontrollen nach Risiko gestalten

Nicht jeder Vorgang benötigt dieselbe Kontrolle.

Beispielhafte Einteilung:

Situation Mögliche Behandlung
häufige, dokumentierte und risikoarme Standardtätigkeit vorab autorisierter und möglichst automatisierter Ablauf
normale Änderung mit überschaubarem Risiko angemessene Bewertung und Autorisierung
komplexe Änderung an kritischem Service vertiefte Risiko-, Abhängigkeits- und Rückfallprüfung
dringende Sicherheitsmaßnahme beschleunigtes Verfahren mit klarer Befugnis und nachgelagerter Kontrolle
strategische Veränderung Entscheidung durch entsprechend befugte Governance-Rollen

Die konkreten Kategorien und Entscheidungsbefugnisse werden von der Organisation festgelegt.

Typischer Fehler

Jede kleine Änderung durchläuft dieselben umfangreichen Freigaben wie eine hochriskante Änderung.

Dadurch entstehen unnötige Wartezeiten, ohne dass kritische Änderungen automatisch besser bewertet werden.

Priorisierung anpassen

ITIL schreibt keine universelle Prioritätsmatrix vor.

Eine Organisation kann Auswirkungen und Dringlichkeit als wichtige Kriterien verwenden.

Sie muss jedoch selbst festlegen:

Beispielhafte Faktoren:

Wichtig

Die lauteste Beschwerde darf nicht automatisch die höchste Priorität bestimmen.

Prioritäten sollten anhand nachvollziehbarer organisatorischer Kriterien festgelegt werden.

Servicekatalog angemessen gestalten

Ein Servicekatalog muss nicht jedes technische Detail enthalten.

Er sollte Informationen bereitstellen, die für die jeweilige Zielgruppe hilfreich sind.

Für Benutzer können relevant sein:

Für interne Teams können zusätzlich relevant sein:

Ein kleiner Betrieb kann mit einer übersichtlichen Serviceliste beginnen.

Ein großes Unternehmen benötigt möglicherweise mehrere Katalogansichten und umfangreichere Serviceinformationen.

Configuration Management angemessen gestalten

Service Configuration Management bedeutet nicht, jede Schraube und jedes Kabel als einzelnes Configuration Item zu erfassen.

Der benötigte Detaillierungsgrad sollte sich richten nach:

Geeignete Fragen:

Typischer Fehler

Eine sehr detaillierte CMDB wird aufgebaut, ohne zu klären, welche Entscheidungen sie unterstützen soll.

Die Daten veralten und verlieren dadurch ihren Nutzen.

Knowledge Management anpassen

Eine Wissensdatenbank muss nicht möglichst viele Artikel enthalten.

Sie sollte benötigtes Wissen:

bereitstellen.

Mögliche Wissensarten:

Eine kleine Organisation kann mit wenigen hochwertigen Artikeln für häufige und kritische Situationen beginnen.

Kennzahlen an Outcomes ausrichten

ITIL schreibt keine universellen Kennzahlen für jede Organisation vor.

Kennzahlen sollten zum Zweck der jeweiligen Practice und zum benötigten Outcome passen.

Beispiel Incident Management:

Mögliche Kennzahlen:

Nicht ausreichend ist häufig die alleinige Betrachtung von:

Beispiel Knowledge Management:

Nicht nur:

Wie viele Artikel wurden erstellt?

Sondern zusätzlich:

Merke

Eine leicht messbare Zahl ist nicht automatisch eine hilfreiche Steuerungsinformation.

Werkzeuge nach der Arbeitsweise auswählen

Ein Werkzeug sollte die benötigten Wertströme und Practices unterstützen.

Vor der Auswahl sollte geklärt sein:

Typischer Fehler

Die Organisation passt ihre gesamte Arbeitsweise an die Standardkonfiguration eines Werkzeugs an, obwohl diese nicht zu ihren Wertströmen und Risiken passt.

Gleichzeitig sollte eine unnötige Sonderkonfiguration vermieden werden.

Zu viele individuelle Anpassungen können:

Automatisierung angemessen einsetzen

Geeignete Automatisierungen können sein:

Vor der Automatisierung sollte geklärt sein:

Grundsatz

Standardisieren und optimieren, bevor automatisiert wird.

Notwendige menschliche Entscheidungen dürfen nicht unbemerkt durch ungeprüfte technische Regeln ersetzt werden.

Künstliche Intelligenz kontextgerecht einsetzen

KI kann ITIL-basierte Arbeitsweisen unterstützen, beispielsweise durch:

Der Umfang menschlicher Kontrolle muss sich nach dem möglichen Risiko richten.

Zu prüfen sind:

Beispiel:

Eine KI kann eine Ticketkategorie vorschlagen.

Die Organisation muss trotzdem regeln:

ITIL mit anderen Ansätzen kombinieren

ITIL muss nicht isoliert verwendet werden.

Es kann mit anderen Frameworks, Normen und Arbeitsweisen kombiniert werden.

Ansatz Möglicher Beitrag
Agile iterative Entwicklung, Feedback und Anpassungsfähigkeit
Scrum strukturierte Arbeit in Produktentwicklungsteams
Kanban Visualisierung und Verbesserung des Arbeitsflusses
DevOps Zusammenarbeit, Automatisierung und schnelle zuverlässige Bereitstellung
Lean Fluss verbessern und vermeidbare Arbeit reduzieren
COBIT Governance und Steuerung von Information und Technologie
ISO/IEC 20000 Anforderungen an ein Service-Management-System
ISO/IEC 27001 Anforderungen an ein Informationssicherheitsmanagementsystem
Projektmanagement zeitlich begrenzte Vorhaben planen und steuern
Enterprise Architecture Strukturen, Abhängigkeiten und Zielarchitekturen gestalten
Site Reliability Engineering Zuverlässigkeit, Automatisierung und messbare Betriebsziele
Business Continuity Management Fortführung kritischer Geschäftsaktivitäten vorbereiten

Die kombinierte Arbeitsweise sollte keine unnötigen parallelen Strukturen erzeugen.

Zu klären ist:

ITIL und agile Arbeitsweisen

ITIL und agile Arbeitsweisen schließen sich nicht aus.

Gemeinsame Grundgedanken können sein:

Mögliche Verbindung:

Typischer Fehler

Jeder agile Sprint wird durch zusätzliche schwerfällige Freigabeverfahren verzögert, obwohl automatisierte Tests, klare Entscheidungsrechte und risikoarme Standardänderungen vorhanden sind.

Ebenso problematisch ist:

Mit dem Hinweis auf Agilität werden notwendige Sicherheits-, Qualitäts- oder Governance-Kontrollen vollständig umgangen.

ITIL und DevOps

DevOps fördert die Zusammenarbeit von:

ITIL kann dazu beitragen:

Mögliche gemeinsame Umsetzung:

ITIL und ISO/IEC 20000

ITIL stellt anpassbare Best-Practice-Guidance bereit.

ISO/IEC 20000 enthält Anforderungen an ein Service-Management-System.

Vereinfacht:

ITIL ISO/IEC 20000
Best-Practice-Framework internationale Norm
anpassbare Guidance prüfbare Anforderungen
beschreibt Konzepte und Practices fordert ein wirksames Managementsystem
keine allgemeine Organisationszertifizierung durch ITIL Organisationen können sich im festgelegten Geltungsbereich zertifizieren lassen

Eine Organisation kann ITIL-Guidance verwenden, um ihr Service-Management-System zu gestalten.

Die Erfüllung einzelner ITIL-Empfehlungen beweist jedoch nicht automatisch die Konformität mit ISO/IEC 20000.

Nicht „ITIL-konform“ als allgemeines Ziel verwenden

ITIL ist ein anpassbares Framework und keine Norm mit einem universellen Organisationszertifikat.

Die Aussage:

Unsere Organisation ist vollständig ITIL-konform.

ist deshalb häufig unpräzise.

Besser ist eine konkrete Beschreibung:

Wichtig

Zertifizierte Personen, akkreditierte Schulungen oder bewertete Werkzeuge beweisen nicht automatisch die Wirksamkeit des gesamten Service Managements einer Organisation.

Kleine Organisationen

Eine kleine Organisation benötigt möglicherweise:

Nicht zwingend erforderlich sind:

Merke

Klein bedeutet nicht unprofessionell.

Auch einfache Arbeitsweisen können verlässlich, kontrolliert und nachvollziehbar sein.

Große oder regulierte Organisationen

Eine große oder regulierte Organisation benötigt möglicherweise:

Trotzdem sollte auch hier unnötige Komplexität vermieden werden.

Ein umfangreicher Ablauf ist nur dann gerechtfertigt, wenn er:

Managed Service Provider

Ein Managed Service Provider muss zusätzlich berücksichtigen:

Ein standardisierter interner Ablauf kann sinnvoll sein.

Er muss jedoch unterschiedliche Kundenanforderungen und Vertragsbedingungen berücksichtigen.

Beispiel:

Ein Incident derselben technischen Plattform kann für zwei Kunden unterschiedliche:

besitzen.

Cloud- und SaaS-Umgebungen

Bei Cloud-Services sollte die Anpassung unter anderem berücksichtigen:

Traditionelle Aufgaben können sich verändern.

Beispiel:

Die Organisation tauscht möglicherweise keine defekten physischen Server mehr selbst aus.

Sie bleibt jedoch verantwortlich für:

Öffentliche Verwaltung und regulierte Bereiche

Zusätzlich relevant können sein:

Diese Anforderungen dürfen nicht als unnötige Bürokratie entfernt werden.

Sie sollten jedoch so gestaltet werden, dass:

Praktische Vorgehensweise zur Anpassung

Die folgende Vorgehensweise ist eine redaktionelle Praxisempfehlung dieses Buches.

Sie ist keine verbindlich vorgeschriebene offizielle ITIL-Schrittfolge.

1. Ziele und Probleme bestimmen

Erfasse:

Ergebnis:

verständliche Beschreibung, warum eine Veränderung notwendig ist

2. Kritische Produkte und Services bestimmen

Fragen:

Ergebnis:

priorisierter Ausgangspunkt statt unkontrollierter Bearbeitung aller Bereiche

3. Tatsächliche Wertströme untersuchen

Beispiele:

Untersuche:

4. Benötigte Practices bestimmen

Fragen:

5. Aktuellen Zustand bewerten

Bewerte unter anderem:

Ergebnis:

realistische Baseline statt rein theoretischer Sollbeschreibung

6. Zielzustand bestimmen

Der Zielzustand sollte beschreiben:

Er muss nicht sofort den endgültigen Idealzustand darstellen.

Ein sinnvoller nächster Zustand kann ausreichend sein.

7. Kleinste wirksame Verbesserung auswählen

Beispiele:

8. Verantwortlichkeit und Governance klären

Bestimme:

9. Iterativ umsetzen

Verwende nach Möglichkeit:

10. Wirkung messen

Prüfe:

11. Ergebnisse verankern

Aktualisiere bei Bedarf:

12. Fortlaufend verbessern

Erfasse neue:

Anpassung ist keine einmalige Einführungsphase.

Sie bleibt Teil von Continual Improvement.

Minimum Viable Practice

Eine Organisation kann zunächst eine bewusst begrenzte, aber funktionsfähige Ausprägung einer Practice gestalten.

Eine solche erste Ausprägung sollte mindestens klären:

Beispiel: erste Incident-Management-Ausprägung

Später können ergänzt werden:

Wichtig

Eine minimale Practice darf nicht so stark reduziert sein, dass ihr grundlegender Zweck nicht mehr erfüllt wird.

Pilotierung

Ein Pilot kann helfen, eine angepasste Arbeitsweise zu prüfen.

Geeigneter Pilotumfang:

Vor dem Pilot sollten festgelegt werden:

Nach dem Pilot wird entschieden:

Organizational Change Management

Die Anpassung von ITIL verändert möglicherweise:

Technische Bereitstellung allein reicht deshalb nicht aus.

Zu berücksichtigen sind:

Typischer Fehler

Ein neuer Prozess wird veröffentlicht und die Organisation erwartet, dass alle Beteiligten ihn ab dem nächsten Tag korrekt anwenden.

Zwischen lokaler Verbesserung und Transformation unterscheiden

Nicht jede Anpassung benötigt ein großes Transformationsprogramm.

Lokale Verbesserung

Beispiele:

Practice-Verbesserung

Beispiele:

Wertstromverbesserung

Beispiele:

Transformation

Beispiele:

Der Umfang der Steuerung muss zur tatsächlichen Veränderung passen.

Reife nicht als Selbstzweck betrachten

Eine Organisation kann Practices und Fähigkeiten bewerten, um ihren aktuellen Zustand besser zu verstehen.

Ein höherer Reife- oder Fähigkeitsgrad ist jedoch nicht automatisch für jede Practice notwendig.

Fragen:

Beispiel:

Ein hochentwickeltes Service Configuration Management kann für eine komplexe, stark integrierte Umgebung wichtig sein.

Für eine sehr kleine und überschaubare Umgebung kann eine einfachere, aber zuverlässige Dokumentation ausreichend sein.

Typische Fehlanpassungen

Fehler 1: ITIL vollständig kopieren

Vorlagen und Prozesse werden unverändert übernommen, obwohl sie nicht zur Organisation passen.

Fehler 2: Nur Begriffe ändern

Alte Probleme bleiben bestehen, werden aber mit neuen ITIL-Bezeichnungen versehen.

Fehler 3: Mit dem Werkzeug beginnen

Das Tool bestimmt die Arbeitsweise, bevor Ziele und Wertströme verstanden wurden.

Fehler 4: Alle Practices gleichzeitig einführen

Ressourcen werden überlastet und keine Practice wird wirksam aufgebaut.

Fehler 5: Jede Practice als eigene Abteilung aufbauen

Unnötige Silos und Übergaben entstehen.

Fehler 6: Rollen ohne Befugnisse vergeben

Personen tragen Verantwortung, können aber nicht entscheiden oder Ressourcen erhalten.

Fehler 7: Jeden Vorgang gleich behandeln

Risikoarme und kritische Tätigkeiten durchlaufen identische Kontrollen.

Fehler 8: Dokumentationsmenge mit Qualität verwechseln

Viele Felder und Dokumente erzeugen keine bessere Entscheidung oder Nachvollziehbarkeit.

Fehler 9: Bestehende funktionierende Arbeitsweisen verwerfen

Wertvolles Wissen und bewährte Fähigkeiten gehen verloren.

Fehler 10: Nur interne Sicht verwenden

Benutzer, Kunden, Fachabteilungen und Lieferanten werden nicht ausreichend einbezogen.

Fehler 11: Prozessgrenzen mit Wertstromgrenzen verwechseln

Jedes Team optimiert seinen Abschnitt, aber niemand betrachtet das gesamte Outcome.

Fehler 12: Kontrollen ohne Zweck einführen

Jeder frühere Fehler führt zu einer zusätzlichen dauerhaften Genehmigung.

Fehler 13: Notwendige Kontrollen als Bürokratie entfernen

Sicherheits-, Datenschutz- oder Compliance-Anforderungen werden unzureichend behandelt.

Fehler 14: Kennzahlen ungeprüft übernehmen

Gemessen wird, was das Werkzeug standardmäßig anbietet, nicht was für Outcomes und Entscheidungen wichtig ist.

Fehler 15: Automatisierung als erstes Ziel verwenden

Ein ungeeigneter Ablauf wird schneller und schwerer veränderbar gemacht.

Fehler 16: Anpassung als einmalige Einführung betrachten

Nach dem Projekt werden Arbeitsweisen nicht mehr überprüft oder verbessert.

Fehler 17: „ITIL-konform“ statt wirksam arbeiten

Die Organisation konzentriert sich auf Begriffe und Formalitäten statt auf Outcomes, Risiken und Erfahrung.

Praxisbeispiel: Kleiner interner IT-Support

Ausgangslage

Angemessener erster Zielzustand

Noch nicht zwingend notwendig

Praxisbeispiel: Kritischer Produktionsservice

Ausgangslage

Möglicher Zielzustand

Hier ist ein höherer Kontroll- und Dokumentationsumfang angemessen.

Praxisbeispiel: Agile Softwareorganisation

Ausgangslage

Mögliche Anpassung

Merke

Häufige Änderungen benötigen nicht automatisch weniger Kontrolle.

Sie benötigen häufig stärker automatisierte, risikogerechte und schneller wirksame Kontrollen.

Praxisbeispiel: Cloud-Service

Ausgangslage

Angepasste Practices

Die Verantwortung verschiebt sich.

Sie verschwindet nicht.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten häufig an der konkreten Umsetzung angepasster Practices.

Mögliche Beiträge:

Hilfreiche Fragen im Arbeitsalltag:

30-Sekunden-Prüfung einer ITIL-Anpassung

  1. Ziel: Welches Problem oder Outcome steht im Mittelpunkt?
  2. Ausgangslage: Was funktioniert bereits?
  3. Kontext: Welche Risiken, Vorgaben und Fähigkeiten bestehen?
  4. Wertstrom: Wie gelangt die Arbeit vom Bedarf zum Ergebnis?
  5. Practices: Welche Fähigkeiten werden tatsächlich benötigt?
  6. Dimensionen: Wurden Menschen, Technologie, Partner und Arbeitsfluss betrachtet?
  7. Einfachheit: Ist jeder Schritt notwendig?
  8. Governance: Sind Verantwortung und Befugnisse eindeutig?
  9. Messung: Woran erkennen wir Wirksamkeit?
  10. Verbesserung: Wie wird Feedback genutzt?

Checkliste vor der Anpassung

Checkliste zur Gestaltung

Checkliste zur Einführung

Checkliste zur Wirksamkeitsprüfung

Checkliste gegen unnötige Bürokratie

Schnellreferenz

Frage Bedeutung für die Anpassung
Was soll verbessert werden? Ziel und Outcome bestimmen
Was funktioniert bereits? vorhandene Fähigkeiten erhalten
Welcher Kontext gilt? Risiken, Vorgaben und Ressourcen berücksichtigen
Welcher Wertstrom ist betroffen? Ende-zu-Ende-Arbeit untersuchen
Welche Practices werden benötigt? passende organisatorische Fähigkeiten auswählen
Wie umfangreich muss die Lösung sein? Aufwand an Risiko und Nutzen ausrichten
Wer entscheidet und verantwortet? Governance und Rollen klären
Welche Informationen werden benötigt? Daten und Dokumentation zweckmäßig gestalten
Welche Werkzeuge unterstützen? Technik nach der Arbeitsweise auswählen
Wie wird Erfolg geprüft? Outcomes und geeignete Messgrößen verwenden
Was lernen wir daraus? Continual Improvement verankern

Zusammenfassende Darstellung

Ziele, Bedürfnisse, Risiken und Vorgaben verstehen
↓
aktuelle Produkte, Services und Wertströme untersuchen
↓
vorhandene Fähigkeiten und funktionierende Arbeitsweisen berücksichtigen
↓
benötigte Management Practices auswählen
↓
Rollen · Informationen · Prozesse · Technologie · Lieferanten anpassen
↓
klein und risikogerecht beginnen
↓
Ergebnisse und Stakeholder-Erfahrung messen
↓
Arbeitsweise verankern und kontinuierlich verbessern

Abschluss des Kapitels

Die wichtigsten Bestandteile des ITIL-Frameworks wurden in diesem Kapitel behandelt:

Diese Bestandteile sollten nicht isoliert verwendet werden.

Sie bilden gemeinsam einen Orientierungsrahmen für professionelles digitales Produkt- und Service-Management.

Kernaussage des Kapitels

ITIL liefert keine fertige Organisation.

ITIL hilft einer Organisation, ihre eigenen Produkte, Services, Wertströme, Practices und Entscheidungen wirksamer zu gestalten.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Offiziell bestätigter Stand

Die offiziellen ITIL-Version-5-Informationen bestätigen:

Einordnung

Die auf dieser Seite dargestellte praktische Vorgehensweise mit zwölf Schritten, die Checklisten, Beispiele, Tabellen und die Bezeichnung Minimum Viable Practice sind redaktionelle Praxisempfehlungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtliche offizielle ITIL-Implementierungsmethode und keine vorgeschriebene Reihenfolge dar.

Konkrete:

müssen von der jeweiligen Organisation anhand ihrer Ziele, Risiken, Fähigkeiten und verbindlichen Vorgaben festgelegt werden.

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

3. Service Desk, Support und operative Servicearbeit

3. Service Desk, Support und operative Servicearbeit

3.1 Der Service Desk als zentraler Kontaktpunkt

Kurz erklärt

Der Service Desk stellt einen zentralen Kontakt- und Kommunikationspunkt zwischen dem Service Provider und seinen Benutzern bereit.

Er nimmt unter anderem:

entgegen.

Der Service Desk muss nicht jedes technische Problem selbst lösen.

Er sorgt jedoch dafür, dass Kontakte:

werden.

Damit verbindet der Service Desk Benutzer, technische Teams, Management Practices, Lieferanten und Wertströme.

Warum ein zentraler Kontaktpunkt notwendig ist

Benutzer benötigen einen verständlichen und verlässlichen Weg, um:

Ohne einen klaren Kontaktpunkt entstehen häufig mehrere parallele Meldewege.

Beispiele:

Dadurch können folgende Probleme entstehen:

Merke

Ein zentraler Kontaktpunkt bedeutet nicht zwingend nur einen technischen Kommunikationskanal.

Es bedeutet, dass Benutzerkontakte kontrolliert zusammengeführt und nachvollziehbar bearbeitet werden.

Der Service Desk als Verbindung zwischen Benutzern und Service Provider

Benutzer kennen häufig nicht:

Sie sollten deshalb nicht selbst entscheiden müssen, ob ein Problem zum:

gehört.

Der Service Desk unterstützt bei dieser Einordnung.

Beispiel:

Ein Benutzer meldet:

Ich kann mich nicht mehr anmelden.

Mögliche Ursachen sind unter anderem:

Der Benutzer muss diese Ursache nicht vor der Meldung bestimmen.

Der Service Desk erfasst zunächst:

Grundsatz

Benutzer beschreiben ihre Beobachtung und ihre Beeinträchtigung.

Die fachliche Einordnung ist Aufgabe der Serviceorganisation.

Der Service Desk ist mehr als eine Telefonzentrale

Ein Service Desk darf nicht auf das reine:

von Tickets reduziert werden.

Eine wirksame Service-Desk-Practice kann unter anderem beitragen zu:

Typischer Fehler

Der Service Desk wird nur danach bewertet, wie schnell ein Kontakt beendet oder ein Ticket weitergeleitet wird.

Dadurch kann die lokale Bearbeitungszeit sinken, während Übergaben, Rückfragen und die gesamte Lösungsdauer steigen.

Service Desk als Practice, Team und Kontaktpunkt unterscheiden

Der Begriff Service Desk kann in der Praxis unterschiedliche Ebenen beschreiben.

Betrachtung Bedeutung
Service-Desk-Practice organisatorische Fähigkeiten und Ressourcen für Kontakt, Kommunikation und Benutzerunterstützung
Service-Desk-Team Mitarbeiter, die einen wesentlichen Teil dieser Aufgaben ausführen
Service-Desk-Funktion organisatorische Einheit mit festgelegten Aufgaben und Verantwortlichkeiten
Kontaktpunkt Zugangsmöglichkeit für Benutzer zum Service Provider
Service-Desk-Werkzeug technische Unterstützung für Kontakte, Tickets, Wissen und Kommunikation
Supportkanal Telefon, Portal, E-Mail, Chat, persönlicher Kontakt oder anderer Zugangsweg

Diese Ebenen sind miteinander verbunden, aber nicht identisch.

Ein Ticketsystem ist nicht der Service Desk.

Ein Service-Desk-Team ist nicht automatisch für jede technische Lösung verantwortlich.

Ein Portal ist nur einer von mehreren möglichen Kontaktkanälen.

Zweck des Service Desk

Der Service Desk unterstützt insbesondere dabei:

Der Service Desk kann zusätzlich:

Wichtig

Der konkrete Umfang wird von der jeweiligen Organisation festgelegt.

ITIL schreibt nicht vor, dass jeder Service Desk dieselben Aufgaben, Kanäle, Servicezeiten oder technischen Befugnisse besitzen muss.

Der Service Desk als Teil mehrerer Wertströme

Der Service Desk ist nicht ausschließlich Teil des Incident-Management-Wertstroms.

Er kann an verschiedenen Wertströmen beteiligt sein.

Wertstrom Möglicher Beitrag des Service Desk
Benutzer nach einer Störung wieder arbeitsfähig machen Meldung aufnehmen, erste Diagnose durchführen, informieren und koordinieren
genehmigte Standardsoftware bereitstellen Service Request erfassen, Status kommunizieren und Ergebnis bestätigen
neuen Mitarbeiter arbeitsfähig machen Fragen beantworten, Übergabe unterstützen und Probleme behandeln
Zugriff bereitstellen Anfrage erfassen, notwendige Angaben prüfen und Status kommunizieren
Benutzer über geplante Wartung informieren zielgruppengerechte Kommunikation bereitstellen
wiederkehrendes Problem reduzieren Muster erkennen und an Problem Management weitergeben
Service verbessern Benutzerfeedback und Kontaktdaten auswerten
Sicherheitsvorfall behandeln Meldung erkennen, sicher eskalieren und vorgegebene Kommunikation verwenden

Der Service Desk ist damit häufig ein Knotenpunkt zwischen:

Service Desk und Incident Management unterscheiden

Service Desk Incident Management
stellt Kontakt und Kommunikation mit Benutzern bereit behandelt negative Auswirkungen von Incidents
nimmt unterschiedliche Kontaktarten entgegen konzentriert sich auf Wiederherstellung des Service
kann Incidents erfassen und erste Diagnose durchführen koordiniert Diagnose, Eskalation und Wiederherstellung
kann Service Requests, Fragen und Feedback bearbeiten behandelt nicht automatisch jede Benutzeranfrage
kann als Team oder organisatorische Funktion umgesetzt sein ist eine organisationsweite Management Practice
unterstützt mehrere Wertströme unterstützt insbesondere Incident-bezogene Wertströme

Ein Service-Desk-Mitarbeiter kann Tätigkeiten des Incident Managements ausführen.

Der Service Desk ist jedoch nicht mit der vollständigen Incident-Management-Practice identisch.

Bei einem komplexen Incident können zusätzlich beteiligt sein:

Service Desk und Service Request Management unterscheiden

Service Desk Service Request Management
stellt Kontakt und Kommunikation bereit steuert die Erfüllung vereinbarter Benutzeranfragen
nimmt einen Request möglicherweise entgegen ordnet den Request einem geeigneten Request-Modell zu
unterstützt bei Rückfragen und Statusinformationen koordiniert Genehmigung, Erfüllung und Abschluss
kann einfache Requests direkt erfüllen kann weitere Teams und Automatisierungen einbeziehen
bearbeitet auch Incidents, Fragen und Feedback konzentriert sich auf vorgesehene Service Requests

Beispiel:

Ein Benutzer benötigt eine freigegebene Standardsoftware.

Der Service Desk kann:

Service Request Management kann anschließend:

Service Desk und Helpdesk unterscheiden

Die Begriffe werden in Organisationen unterschiedlich verwendet.

Häufig wird vereinfacht unterschieden:

Helpdesk Service Desk
stärker auf technische Hilfe und Störungsbehebung ausgerichtet breiter auf Servicebeziehungen, Kommunikation und Unterstützung ausgerichtet
häufig reaktiver Fokus kann reaktive und proaktive Aufgaben umfassen
möglicherweise stärker komponentenorientiert möglichst service- und benutzerorientiert
häufig enger Aufgabenbereich kann mehrere Practices und Wertströme verbinden

Diese Unterscheidung ist nicht in jeder Organisation identisch.

Ein intern als Helpdesk bezeichnetes Team kann praktisch alle Aufgaben eines modernen Service Desk erfüllen.

Merke

Die Bezeichnung allein entscheidet nicht über die Qualität oder den tatsächlichen Aufgabenbereich.

Service Desk und technische Supportgruppen unterscheiden

Technische Supportgruppen besitzen häufig vertieftes Fachwissen.

Beispiele:

Der Service Desk besitzt dagegen häufig eine breitere Sicht auf:

Ein Anliegen kann an eine technische Supportgruppe übergeben werden.

Trotzdem sollte geklärt bleiben:

Typischer Fehler

Nach der technischen Weiterleitung fühlt sich niemand mehr für die Ende-zu-Ende-Kommunikation und das Benutzerergebnis verantwortlich.

Support-Level sind keine zwingende ITIL-Struktur

Viele Organisationen verwenden Bezeichnungen wie:

Eine mögliche Einteilung ist:

Ebene Möglicher Schwerpunkt
First Level Kontakt, Erfassung, erste Diagnose und bekannte Lösungen
Second Level vertieftes technisches oder fachliches Wissen
Third Level hochspezialisierte interne Experten, Entwicklung oder Hersteller

Diese Struktur kann hilfreich sein.

Sie ist jedoch keine zwingend vorgeschriebene ITIL-Organisationsform.

Mögliche Nachteile einer starren Level-Struktur:

Alternative oder ergänzende Modelle sind beispielsweise:

Swarming als mögliche Arbeitsweise

Beim Swarming wird ein komplexer Vorgang nicht nur linear von Supportstufe zu Supportstufe weitergereicht.

Stattdessen werden geeignete Fachkräfte frühzeitig zur gemeinsamen Bearbeitung einbezogen.

Mögliche Vorteile:

Mögliche Voraussetzungen:

Swarming ist eine mögliche Praxisempfehlung und keine für jede Organisation vorgeschriebene ITIL-Struktur.

Mögliche Organisationsmodelle

Ein Service Desk kann unterschiedlich organisiert werden.

Zentraler Service Desk

Ein gemeinsames Team unterstützt mehrere Standorte oder Bereiche.

Mögliche Vorteile:

Mögliche Herausforderungen:

Lokaler Service Desk

Support befindet sich nahe bei Benutzern oder Standorten.

Mögliche Vorteile:

Mögliche Herausforderungen:

Virtueller Service Desk

Mitarbeiter arbeiten verteilt, erscheinen für Benutzer aber als gemeinsamer Service Desk.

Mögliche Vorteile:

Mögliche Herausforderungen:

Follow-the-Sun-Modell

Mehrere Service-Desk-Standorte in verschiedenen Zeitzonen übernehmen nacheinander die Bearbeitung.

Mögliche Vorteile:

Mögliche Herausforderungen:

Spezialisierter Service Desk

Ein Service Desk ist auf bestimmte:

ausgerichtet.

Möglicher Vorteil:

Mögliche Herausforderung:

Kontaktkanäle

Ein Service Desk kann über mehrere Kanäle erreichbar sein.

Kanal Geeignet für Mögliche Herausforderung
Self-Service-Portal strukturierte Incidents und Requests Benutzer müssen das passende Angebot finden
Telefon dringende oder erklärungsbedürftige Situationen Dokumentation muss während oder nach dem Gespräch erfolgen
E-Mail weniger dringende und schriftlich beschreibbare Anliegen häufig unvollständige oder unstrukturierte Angaben
Chat schnelle Rückfragen und direkte Kommunikation Gesprächskontext muss im Vorgang gesichert werden
virtueller Agent häufige Fragen und standardisierte Anliegen Fehlinterpretation und unzureichende Eskalation möglich
persönlicher Kontakt Vor-Ort-Unterstützung und komplexe Kommunikation Meldungen dürfen nicht außerhalb der Nachverfolgung bleiben
Mobile App Meldungen und Status unterwegs Sicherheit und Bedienbarkeit müssen berücksichtigt werden
technische Integration automatische Erfassung aus anderen Systemen nicht jede technische Meldung ist ein Benutzerkontakt oder Incident

Die Organisation sollte für jeden Kanal klären:

Mehrere Kanäle, aber ein gemeinsamer Überblick

Ein Benutzer kann möglicherweise:

Trotzdem sollten relevante Informationen möglichst in einer gemeinsamen Vorgangs- und Kommunikationssicht zusammengeführt werden.

Andernfalls entstehen:

Praxistipp

Die Anzahl der Kontaktkanäle sollte nicht größer sein als die Fähigkeit der Organisation, diese zuverlässig zu überwachen, zusammenzuführen und zu bearbeiten.

Der geeignete Kanal hängt von der Situation ab

Nicht jedes Anliegen eignet sich für jeden Kanal.

Beispiele:

Situation Möglicherweise geeigneter Kanal
allgemeine Standardsoftware bestellen Self-Service-Portal
kritischer Ausfall eines wichtigen Service Telefon oder definierter Major-Incident-Meldeweg
einfache Statusabfrage Portal, Chatbot oder automatische Nachricht
möglicher Sicherheitsvorfall besonders geschützter und bekannter Meldeweg
komplexes Problem mit vielen Rückfragen Telefon, Chat oder gemeinsamer Termin
Feedback zu einem Service Portal, Umfrage oder persönlicher Kontakt
Kennwort vergessen sicherer Self-Service oder verifizierter Supportkontakt

Die Organisation legt die tatsächlichen Kanäle und Regeln fest.

Erreichbarkeit und Servicezeiten

Der Service Desk muss nicht automatisch rund um die Uhr besetzt sein.

Mögliche Modelle:

Zu klären ist:

Wichtig

Servicezeiten des Service Desk, Supportzeiten eines Service und technische Betriebszeiten können unterschiedlich sein.

Service Desk als Kommunikationszentrum

Der Service Desk besitzt häufig eine wichtige Rolle bei der Kommunikation.

Dazu gehören:

Gute Kommunikation sollte möglichst sein:

Ungeeignete Statusmeldung:

Der Incident befindet sich beim Second Level.

Bessere Statusmeldung:

Das Netzwerkteam untersucht derzeit die Verbindung zum zentralen Dateiservice. Eine nächste Statusmeldung erfolgt spätestens um 14:30 Uhr. Sie müssen aktuell nichts weiter unternehmen.

Keine unbelegten Zusagen machen

Ein Service-Desk-Mitarbeiter sollte keine Wiederherstellungszeit versprechen, wenn diese nicht ausreichend belegt ist.

Ungeeignet:

Das funktioniert in zehn Minuten wieder.

Besser:

Das zuständige Team untersucht die Störung. Eine verlässliche Wiederherstellungszeit liegt noch nicht vor. Die nächste Aktualisierung erfolgt um 11:00 Uhr.

Merke

Ein angekündigter Zeitpunkt für die nächste Information ist häufig zuverlässiger als eine unbelegte Schätzung der vollständigen Lösung.

Empathie und professioneller Umgang

Benutzer melden nicht nur einen technischen Fehler.

Sie erleben möglicherweise:

Professioneller Umgang bedeutet:

Empathie bedeutet nicht:

Beispiel:

Ich verstehe, dass Sie die Datei für den heutigen Kundentermin benötigen. Ich prüfe jetzt, ob nur diese Datei oder der gesamte Dateiservice betroffen ist, und informiere Sie über den nächsten Schritt.

Geschäfts- und Benutzerkontext verstehen

Technisches Wissen allein reicht für guten Service-Desk-Support nicht aus.

Hilfreich ist auch das Verständnis:

Beispiel:

Der Ausfall eines Etikettendruckers kann technisch wie ein einzelnes Geräteproblem wirken.

In einem Lager kann er jedoch:

Praxistipp

Service-Desk-Mitarbeiter sollten wichtige Arbeitsbereiche und deren Abhängigkeit von digitalen Services kennenlernen.

Erste Diagnose

Der Service Desk kann eine erste strukturierte Diagnose durchführen.

Mögliche Ziele:

Mögliche Fragen:

Die Diagnose darf nicht zu einer unstrukturierten Liste beliebiger Versuche werden.

Jede Maßnahme sollte:

First Contact Resolution

First Contact Resolution beschreibt, dass ein Anliegen während des ersten Kontakts ausreichend gelöst oder erfüllt wird.

Mögliche Vorteile:

First Contact Resolution darf jedoch nicht durch ungeeignete Maßnahmen künstlich erhöht werden.

Ungeeignet sind beispielsweise:

Merke

Eine Lösung beim ersten Kontakt ist nur dann wertvoll, wenn sie korrekt, sicher und aus Benutzersicht wirksam ist.

Shift Left

Shift Left beschreibt die Verlagerung geeigneten Wissens und geeigneter Fähigkeiten näher zum Benutzer oder zu früheren Supportstufen.

Beispiele:

Mögliche Vorteile:

Shift Left darf nicht bedeuten:

Funktionale Eskalation

Eine funktionale Eskalation erfolgt, wenn zusätzliche:

benötigt werden.

Beispiele:

Eine gute funktionale Eskalation enthält:

Ungeeignet:

Geht nicht. Bitte prüfen.

Besser:

Seit 09:20 Uhr können zwölf Benutzer am Standort Nord keine Verbindung zum zentralen Dateiservice herstellen. Lokale Netzwerkverbindung und DNS-Auflösung funktionieren. Der Verbindungsversuch zum TCP-Port des Dateiservice schlägt fehl. Andere Standorte sind nicht betroffen. Benötigt wird die Prüfung der Standortverbindung und der Firewall-Regeln.

Hierarchische Eskalation

Eine hierarchische Eskalation kann notwendig sein, wenn:

Sie bedeutet nicht automatisch, dass ein technischer Vorgang an eine Führungskraft zur Lösung weitergegeben wird.

Die Führungskraft oder autorisierte Rolle kann beispielsweise:

Ownership eines Vorgangs

Die Organisation sollte festlegen, wer einen Vorgang über seinen gesamten Verlauf besitzt.

Mögliche Modelle:

Unabhängig vom Modell muss geklärt sein:

Typischer Fehler

Ein Ticket besitzt eine zugewiesene Gruppe, aber keine Person oder Rolle fühlt sich für das Gesamtergebnis verantwortlich.

Warme und kalte Übergabe

Kalte Übergabe

Der Vorgang wird ohne direkte Abstimmung einer anderen Gruppe zugewiesen.

Mögliche Folge:

Warme Übergabe

Die übergebende und übernehmende Rolle stimmen sich ab.

Mögliche Bestandteile:

Eine warme Übergabe ist besonders hilfreich bei:

Sie ist nicht für jeden einfachen Vorgang notwendig.

Ticketqualität

Ein gutes Ticket unterstützt:

Mögliche Mindestinformationen:

Abhängig vom Vorgang können zusätzlich notwendig sein:

Wichtig

Es sollen nur Informationen erfasst werden, die einen erkennbaren Zweck besitzen und rechtmäßig verarbeitet werden dürfen.

Objektiv und verständlich dokumentieren

Ungeeignete Dokumentation:

Benutzer hat wieder alles falsch gemacht.

Besser:

Der Benutzer verwendete den bisherigen Anmeldeweg. Seit der Änderung vom 1. August ist eine zusätzliche MFA-Bestätigung erforderlich. Die neue Anleitung war ihm nicht bekannt.

Ungeeignete Dokumentation:

Server kaputt.

Besser:

Der Anwendungsserver ist seit 10:15 Uhr nicht über HTTPS erreichbar. ICMP und SSH funktionieren. Der Webdienst ist beendet und startet mit Fehlercode 1.

Dokumentation sollte:

sein.

Kategorisierung

Kategorien können dabei helfen:

Eine Kategorie sollte nicht ausschließlich die vermutete technische Ursache abbilden.

Zu Beginn ist die Ursache häufig unbekannt.

Mögliche Kategorisierungsdimensionen:

Typischer Fehler

Benutzer müssen in einem Portal aus einer umfangreichen technischen Komponentenliste auswählen, obwohl sie den betroffenen Service und die Ursache nicht kennen.

Priorisierung

Die Priorität sollte nach den Regeln der Organisation bestimmt werden.

Häufig verwendete Kriterien sind:

ITIL schreibt keine universelle Prioritätsmatrix vor.

Beispiel:

Ein einzelner ausgefallener Arbeitsplatz kann eine geringe Auswirkung besitzen.

Ist es jedoch der einzige Arbeitsplatz zur Steuerung einer kritischen Anlage, kann die tatsächliche Auswirkung sehr hoch sein.

Merke

Die Anzahl betroffener Benutzer ist wichtig, aber nicht das einzige Kriterium.

Der Service Desk entscheidet nicht allein nach Lautstärke

Benutzer können ihre Situation subjektiv als sehr dringend wahrnehmen.

Der Service Desk sollte:

Ungeeignet:

Das ist nicht dringend.

Besser:

Ich verstehe, dass Sie die Anwendung heute benötigen. Nach unseren Prioritätskriterien ist aktuell nur Ihr Arbeitsplatz betroffen und es steht ein Ersatzarbeitsplatz zur Verfügung. Der Vorgang wird deshalb als Priorität 3 bearbeitet. Sollte auch der Ersatz nicht funktionieren oder weitere Benutzer betroffen sein, wird die Priorität erneut bewertet.

Major Incidents erkennen und eskalieren

Ein Major Incident ist ein besonders schwerwiegender Incident.

Die Organisation muss eigene Kriterien festlegen.

Mögliche Hinweise:

Der Service Desk kann eine wichtige Rolle übernehmen bei:

Major Incident Management wird nicht als eigenständige der 34 ITIL Management Practices behandelt.

Organisationen können jedoch ein eigenes Major-Incident-Verfahren innerhalb ihrer Incident-Management-Arbeitsweise verwenden.

Knowledge Management

Der Service Desk benötigt gut nutzbares Wissen.

Beispiele:

Ein Wissensartikel sollte möglichst:

enthalten.

Der Service Desk ist gleichzeitig eine wichtige Quelle neuen Wissens.

Wiederkehrende Fragen können zeigen:

Self-Service

Self-Service kann Benutzern ermöglichen:

Erfolgreicher Self-Service benötigt:

Typischer Fehler

Ein Portal wird eingeführt und Benutzer werden gezwungen, es zu verwenden, obwohl Inhalte, Suche und Formulare unverständlich sind.

Self-Service sollte Benutzeraufwand reduzieren und nicht nur Arbeit vom Service Desk auf Benutzer verlagern.

Automatisierung

Mögliche Automatisierungen im Service Desk:

Vor der Automatisierung muss geklärt sein:

Künstliche Intelligenz im Service Desk

KI kann unter anderem unterstützen bei:

KI kann jedoch Fehler erzeugen.

Mögliche Risiken:

Notwendig sind unter anderem:

Sicherheitsrelevant

KI-generierte technische Anweisungen dürfen abhängig vom möglichen Risiko nicht ungeprüft an Benutzer weitergegeben oder auf produktiven Systemen ausgeführt werden.

Der menschliche Kontakt bleibt wichtig

Automatisierung und Self-Service können standardisierte Anliegen effizient bearbeiten.

Menschliche Unterstützung bleibt besonders wichtig bei:

Ein guter Service Desk verbindet deshalb:

Informationssicherheit am Service Desk

Der Service Desk verarbeitet häufig sensible Informationen und kann ein Ziel für Social Engineering sein.

Wichtige Grundsätze:

Beispiel:

Eine Person ruft an und verlangt dringend die Zurücksetzung des Kennworts eines Geschäftsführers.

Zeitdruck, Autoritätsbezug und angebliche Dringlichkeit dürfen die vorgesehene Identitätsprüfung nicht ersetzen.

Remote-Unterstützung

Bei Remote-Support sollte geklärt sein:

Der Mitarbeiter sollte:

Datenschutz und Vertraulichkeit

Tickets können enthalten:

Deshalb sollte die Organisation festlegen:

Typischer Fehler

Benutzer senden vollständige vertrauliche Dokumente, obwohl für die Diagnose nur eine Fehlermeldung oder ein technisch begrenzter Ausschnitt erforderlich wäre.

Zusammenarbeit mit Lieferanten

Ein Service Desk kann externe Lieferanten einbinden.

Dafür sollten verfügbar sein:

Eine Lieferantenmeldung sollte möglichst enthalten:

Die Weitergabe an einen Lieferanten beendet nicht die interne Verantwortung für:

Service-Desk-Kompetenzen

Mögliche benötigte Kompetenzen:

Nicht jeder Mitarbeiter benötigt dieselbe technische Tiefe.

Der Service Desk benötigt jedoch ausreichend gemeinsames Wissen über:

Einarbeitung neuer Service-Desk-Mitarbeiter

Eine sinnvolle Einarbeitung kann umfassen:

Zusätzlich hilfreich:

Qualität statt reiner Geschwindigkeit

Ein Service Desk sollte nicht ausschließlich nach Geschwindigkeit beurteilt werden.

Mögliche Qualitätsaspekte:

Mögliche Kennzahlen

Kennzahlen werden von der jeweiligen Organisation festgelegt.

Mögliche Beispiele:

Kennzahl Mögliche Aussage
First Contact Resolution Anteil geeigneter Anliegen, die beim ersten Kontakt gelöst werden
durchschnittliche Antwortzeit Zeit bis zur ersten qualifizierten Reaktion
gesamte Lösungs- oder Erfüllungszeit Ende-zu-Ende-Dauer bis zum Ergebnis
Abbruchquote Anteil abgebrochener Telefon- oder Chatkontakte
Wiedereröffnungsquote mögliche Hinweise auf unvollständige Lösungen
Anzahl der Übergaben möglicher Hinweis auf unnötige Weiterleitungen
Benutzerzufriedenheit subjektive Erfahrung nach dem Kontakt
erneute Kontaktaufnahme mögliche Hinweise auf fehlende Lösung oder Kommunikation
Ticketqualität Vollständigkeit und Nutzbarkeit der Dokumentation
Backlog-Alter Alter unbearbeiteter oder nicht abgeschlossener Vorgänge
Nutzung von Wissen Verwendung und Wirksamkeit von Wissensartikeln
Self-Service-Erfolgsquote Anteil erfolgreich selbst erledigter geeigneter Anliegen

Keine einzelne Kennzahl beschreibt die gesamte Leistung.

Problematische Kennzahlen

Möglichst kurze Gesprächsdauer

Mögliche Fehlwirkung:

Möglichst viele geschlossene Tickets

Mögliche Fehlwirkung:

Möglichst hohe First Contact Resolution

Mögliche Fehlwirkung:

Möglichst wenige Eskalationen

Mögliche Fehlwirkung:

Möglichst geringe Kosten pro Kontakt

Mögliche Fehlwirkung:

Merke

Kennzahlen beeinflussen Verhalten.

Sie sollten deshalb gemeinsam und im Zusammenhang mit Outcomes, Qualität und Risiken betrachtet werden.

Benutzerfeedback

Benutzerfeedback kann erhoben werden durch:

Feedback sollte:

sein.

Eine sehr niedrige Rücklaufquote kann die Aussagekraft begrenzen.

Negative Einzelbewertungen sollten nicht automatisch als persönliches Versagen eines Mitarbeiters behandelt werden.

Zu untersuchen sind auch:

Der Service Desk als Quelle für Continual Improvement

Der Service Desk erkennt häufig früh:

Diese Erkenntnisse sollten nicht nur in einzelnen Tickets verbleiben.

Mögliche Verbesserungen:

Praxisbeispiel: Anmeldung funktioniert nicht

Ein Benutzer meldet telefonisch:

Ich kann mich nicht anmelden.

Ungeeignete Bearbeitung

  1. Ticket mit Titel „Login geht nicht“ erstellen.
  2. Vorgang ohne weitere Informationen an das Serverteam senden.
  3. Benutzer erhält keine Statusinformation.
  4. Serverteam stellt fest, dass MFA betroffen ist.
  5. Ticket wird an ein anderes Team weitergegeben.
  6. Benutzer ruft erneut an.

Bessere Bearbeitung

  1. betroffenen Benutzer und Service bestimmen
  2. genaue Fehlermeldung erfassen
  3. feststellen, ob weitere Benutzer betroffen sind
  4. Netzwerkverbindung und allgemeine Serviceinformation prüfen
  5. bekannte Störungen und letzte Änderungen prüfen
  6. sichere bekannte Lösung anwenden oder geeignete Fachgruppe einbinden
  7. bisherigen Diagnoseweg dokumentieren
  8. Benutzer über nächsten Schritt informieren
  9. Wiederherstellung bestätigen
  10. wiederkehrendes Muster an Problem Management oder Continual Improvement weitergeben

Praxisbeispiel: Drucker funktioniert nicht

Meldung:

Der Drucker ist kaputt.

Mögliche Klärung:

Mögliche Einordnung:

Das Beispiel zeigt, warum die Formulierung des Benutzers allein nicht die fachliche Kategorie bestimmt.

Praxisbeispiel: Verdächtige E-Mail

Ein Benutzer meldet eine verdächtige Nachricht.

Der Service Desk sollte nach dem Sicherheitsverfahren handeln.

Mögliche Schritte:

Der Vorgang darf nicht allein als normale E-Mail-Störung behandelt werden.

Praxisbeispiel: Mehrfachmeldungen bei einem Ausfall

Viele Benutzer melden gleichzeitig, dass die zentrale Dateiablage nicht erreichbar ist.

Der Service Desk kann:

  1. Meldungen zu einem gemeinsamen Incident zusammenführen
  2. Auswirkung und betroffene Bereiche erfassen
  3. Major-Incident-Kriterien prüfen
  4. technische Teams und Lieferanten einbinden
  5. bekannte Statusinformationen veröffentlichen
  6. Benutzer von unnötigen Einzelrückfragen entlasten
  7. Zwischenlösungen kommunizieren
  8. Wiederherstellung bestätigen
  9. Folgeaktivitäten dokumentieren

Praxistipp

Bei einer bekannten größeren Störung kann eine gut sichtbare Statusmeldung mehr Benutzeraufwand reduzieren als die wiederholte Einzelbearbeitung identischer Kontakte.

Typische Fehler im Service Desk

Fehler 1: Ticketweiterleitung als Hauptziel

Kontakte werden möglichst schnell weitergereicht, ohne ausreichende Informationen zu erfassen.

Fehler 2: Benutzer müssen die technische Zuständigkeit kennen

Portale oder Mitarbeiter verlangen, dass Benutzer selbst das richtige Fachteam auswählen.

Fehler 3: Priorisierung nach Lautstärke

Persönliche Kontakte, Hierarchie oder häufige Nachfragen bestimmen die Reihenfolge.

Fehler 4: Keine Ende-zu-Ende-Verantwortung

Nach einer Weiterleitung überwacht niemand Fortschritt und Benutzerkommunikation.

Fehler 5: Technische Wiederherstellung nicht bestätigen

Das Fachteam meldet Erfolg, aber der Benutzer kann weiterhin nicht arbeiten.

Fehler 6: Gesprächszeit über Qualität stellen

Mitarbeiter beenden Kontakte schnell, erzeugen dadurch aber Rückfragen und Nacharbeit.

Fehler 7: Service Desk als reine Einstiegsposition behandeln

Fähigkeiten, Entwicklungsmöglichkeiten und strategische Bedeutung werden unterschätzt.

Fehler 8: Wissen nur bei einzelnen Personen

Lösungen bleiben in privaten Notizen oder persönlichen Chatverläufen.

Fehler 9: Self-Service als Zwang verwenden

Benutzer erhalten keinen geeigneten menschlichen Kontaktweg für komplexe Situationen.

Fehler 10: KI-Antworten ungeprüft übernehmen

Falsche oder unsichere Lösungsvorschläge werden an Benutzer weitergegeben.

Fehler 11: Sicherheitskontrollen unter Zeitdruck umgehen

Identitäten werden nicht ausreichend geprüft oder sensible Informationen ungeschützt verarbeitet.

Fehler 12: Jede Meldung als Incident behandeln

Service Requests, Fragen, Feedback und Sicherheitsmeldungen werden falsch eingeordnet.

Fehler 13: Jeden Kontakt einzeln betrachten

Mehrfachmeldungen und wiederkehrende Muster werden nicht erkannt.

Fehler 14: Keine Rückmeldung bei Verzögerungen

Benutzer müssen wiederholt nach dem Status fragen.

Fehler 15: Ticket schließen, weil der Benutzer nicht sofort antwortet

Es wird nicht geprüft, ob angemessene Kontaktversuche, Fristen und alternative Wege verwendet wurden.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker können im Service Desk oder in nachgelagerten Fachteams arbeiten.

Wichtige Beiträge sind:

Wenn du ein Ticket aus dem Service Desk erhältst, prüfe:

30-Sekunden-Prüfung eines Benutzerkontakts

  1. Person: Wer meldet und wer ist betroffen?
  2. Service: Welche Arbeitsfähigkeit oder welcher Service wird benötigt?
  3. Symptom: Was wurde beobachtet?
  4. Zeit: Seit wann besteht die Situation?
  5. Auswirkung: Was kann nicht durchgeführt werden?
  6. Umfang: Sind weitere Benutzer oder Standorte betroffen?
  7. Kontext: Was wurde verändert oder bereits versucht?
  8. Einordnung: Incident, Service Request, Frage, Feedback oder Sicherheitsmeldung?
  9. Nächster Schritt: Wer übernimmt welche Aufgabe?
  10. Kommunikation: Wann erhält der Benutzer die nächste Information?
  11. Ergebnis: Wie wird die Wiederherstellung oder Erfüllung bestätigt?
  12. Lernen: Muss Wissen oder eine Verbesserung ergänzt werden?

Checkliste für die Kontaktaufnahme

Checkliste für die Weiterleitung

Checkliste für die Kommunikation

Checkliste vor dem Abschluss

Checkliste für einen wirksamen Service Desk

Schnellreferenz

Frage Bedeutung
Wer meldet? Kontakt und betroffene Person bestimmen
Was wird benötigt? Service oder gewünschtes Outcome verstehen
Was ist geschehen? Symptom und Situation erfassen
Wer ist betroffen? Auswirkungen und Umfang bestimmen
Wie dringend ist es? organisatorische Prioritätskriterien anwenden
Was wurde bereits geprüft? doppelte Arbeit vermeiden
Wer kann helfen? geeignete Fähigkeiten und Practices einbinden
Wer besitzt den Vorgang? Ende-zu-Ende-Verantwortung klären
Wann gibt es Neuigkeiten? verlässliche Kommunikation sicherstellen
Funktioniert es wieder? technisches und benutzerbezogenes Ergebnis bestätigen
Was lernen wir? Wissen und Verbesserung ableiten

Aufbau dieses Kapitels

Die folgenden Seiten vertiefen die operative Arbeit rund um den Service Desk:

Zusammenfassende Darstellung

Benutzer besitzt eine Frage, Anfrage oder Beeinträchtigung
↓
verständlicher Kontaktkanal
↓
Service Desk nimmt Kontakt auf
↓
Identität · Service · Symptom · Auswirkung · Dringlichkeit erfassen
↓
Anliegen fachlich einordnen
↓
bekannte Lösung anwenden oder geeignete Fähigkeiten einbinden
↓
Verantwortung und Kommunikation aufrechterhalten
↓
Ergebnis technisch und aus Benutzersicht prüfen
↓
Vorgang nachvollziehbar abschließen
↓
Wissen, Muster und Verbesserungsmöglichkeiten weiterverwenden

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Offiziell bestätigter Stand

Die offiziellen ITIL-Quellen bestätigen:

Versionshinweis

Die öffentlich zugängliche spezialisierte Zertifizierungs- und Practice-Seite trägt derzeit weiterhin die Bezeichnung ITIL 4 Practitioner: Service Desk.

ITIL Version 5 führt die Management Practices grundsätzlich fort und entwickelt sie weiter. Vollständige aktuelle Practice Guidance wird über die offiziellen ITIL Practice Guides bereitgestellt.

Diese Seite stellt deshalb keine nicht öffentlich belegten Detailänderungen einer zukünftigen oder nur zugangsbeschränkt verfügbaren Service-Desk-Practice-Guidance als gesichert dar.

Einordnung

Die ausführlichen:

sind herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine für jede Organisation verbindlichen ITIL-Prozesse, Support-Level, Prioritätsmatrizen oder Organisationsstrukturen dar.

Die konkrete Gestaltung des Service Desk muss an:

angepasst werden.

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

3. Service Desk, Support und operative Servicearbeit

3.2 Kontaktkanäle und Erreichbarkeit

Kurz erklärt

Kontaktkanäle bestimmen, wie Benutzer den Service Desk erreichen können.

Typische Kanäle sind:

Erreichbarkeit beschreibt mehr als die technische Verfügbarkeit eines Kanals.

Ein Kanal ist erst dann wirksam, wenn:

ITIL schreibt keine universelle Anzahl von Kanälen und keinen grundsätzlich rund um die Uhr besetzten Service Desk vor.

Die Organisation gestaltet Kanäle, Servicezeiten und Eskalationswege entsprechend ihren Benutzern, Services, Risiken und verfügbaren Fähigkeiten.

Warum die Gestaltung der Kontaktkanäle wichtig ist

Ein Service Desk kann fachlich gut organisiert sein und trotzdem schlecht erreichbar wirken.

Beispiele:

Die Wahl und Gestaltung der Kontaktkanäle beeinflusst damit:

Merke

Viele Kontaktkanäle bedeuten nicht automatisch gute Erreichbarkeit.

Jeder angebotene Kanal muss zuverlässig betrieben, überwacht und in die gemeinsamen Wertströme eingebunden werden.

Kontaktkanal, Servicezeit und Reaktionszeit unterscheiden

Begriff Bedeutung
Kontaktkanal Weg, über den ein Benutzer mit dem Service Provider in Verbindung tritt
technische Verfügbarkeit Zeitraum, in dem der Kanal technisch erreichbar ist
Servicezeit Zeitraum, in dem eine vereinbarte menschliche oder automatisierte Leistung angeboten wird
Supportzeit Zeitraum, in dem Unterstützung für einen bestimmten Service bereitsteht
Betriebszeit Zeitraum, in dem ein Produkt oder Service regulär genutzt werden soll
Bereitschaftszeit Zeitraum, in dem zuständige Personen außerhalb regulärer Zeiten bei bestimmten Ereignissen reagieren
erste Reaktionszeit Zeit bis zu einer ersten qualifizierten Rückmeldung
Bearbeitungszeit Zeit, in der aktiv an einem Anliegen gearbeitet wird
Lösungs- oder Erfüllungszeit Zeit bis zur ausreichenden Wiederherstellung oder Erfüllung
Statusintervall vereinbarter Abstand zwischen Statusinformationen

Diese Zeiten können unterschiedlich sein.

Beispiel:

Wichtig

Ein technisch rund um die Uhr erreichbares Formular bedeutet nicht automatisch einen rund um die Uhr verfügbaren menschlichen Support.

Die Kanalstrategie am Benutzerbedarf ausrichten

Vor der Einführung oder Änderung von Kontaktkanälen sollte die Organisation untersuchen:

Unterschiedliche Benutzergruppen können unterschiedliche Anforderungen besitzen.

Beispiele:

Benutzergruppe Mögliche Anforderungen
Büroarbeitsplätze Portal, E-Mail, Chat und Telefon
Produktionsmitarbeiter leicht erreichbare Telefonnummer oder lokaler Kontakt
Außendienst mobile Erreichbarkeit und Self-Service
Schichtbetrieb erweiterte Support- oder Bereitschaftszeiten
externe Kunden klar getrenntes Kundenportal und vertraglich definierte Kanäle
Führungskräfte dieselben Prioritätsregeln, aber möglicherweise besondere Kommunikationsanforderungen
Benutzer mit Einschränkungen barrierearme Kanäle und alternative Kontaktmöglichkeiten
internationale Benutzer unterschiedliche Zeitzonen und Sprachen
Administratoren technischer Eskalations- und Sicherheitskanal

Grundsatz

Der bevorzugte Kanal der IT ist nicht automatisch der geeignete Kanal für alle Benutzer.

Single Point of Contact und mehrere Kanäle

Der Service Desk wird häufig als zentraler oder einzelner Kontaktpunkt beschrieben.

Das bedeutet nicht zwingend, dass nur ein einziger Kanal erlaubt ist.

Mehrere Kanäle können gemeinsam einen zentralen Kontaktpunkt bilden, wenn sie:

Beispiel:

Ein Benutzer kann den Service Desk erreichen über:

Alle Kontakte werden jedoch:

Problematisch wäre dagegen:

Merke

Ein zentraler Kontaktpunkt ist eine organisatorische Fähigkeit und nicht nur eine einzelne Telefonnummer oder E-Mail-Adresse.

Mehrkanal und kanalübergreifende Bearbeitung

Eine Organisation kann mehrere Kanäle anbieten.

Dabei sollte unterschieden werden zwischen:

Ansatz Bedeutung
Mehrkanalbetrieb mehrere Kanäle existieren nebeneinander
kanalübergreifende Bearbeitung Informationen und Bearbeitungsstand bleiben beim Kanalwechsel erhalten
einheitliche Serviceerfahrung Regeln, Sprache und Statusinformationen sind über die Kanäle hinweg abgestimmt

Beispiel einer schlechten kanalübergreifenden Erfahrung:

  1. Benutzer meldet eine Störung per Chat.
  2. Der Chat verweist auf eine Telefonnummer.
  3. Am Telefon muss der Benutzer alles erneut erklären.
  4. Später erhält er eine E-Mail mit einer neuen Ticketnummer.
  5. Im Portal ist keiner der bisherigen Schritte sichtbar.

Bessere Gestaltung:

  1. Chat erfasst die ersten Informationen.
  2. Ein Vorgang wird erstellt.
  3. Beim Wechsel zum Telefon sieht der Mitarbeiter den bisherigen Verlauf.
  4. Der Benutzer nennt nur noch die Vorgangsnummer oder wird sicher identifiziert.
  5. Status und Ergebnis bleiben im Portal sichtbar.

Die konkrete technische Umsetzung hängt von den verwendeten Werkzeugen ab.

Kanalwahl nach Art des Anliegens

Nicht jeder Kanal ist für jedes Anliegen gleich geeignet.

Anliegen Häufig geeignete Kanäle
standardisierte Softwareanforderung Self-Service-Portal
planbarer Berechtigungsantrag Portal mit strukturiertem Formular
allgemeine Frage Portal, Knowledge-Base, Chat oder E-Mail
komplexe Störung mit Rückfragen Telefon, Chat oder persönlicher Kontakt
kritischer Serviceausfall definierter dringender Meldeweg
möglicher Sicherheitsvorfall besonderer Sicherheitsmeldeweg
Kennwort vergessen sicherer Self-Service oder verifizierter Supportkontakt
Statusabfrage Portal oder automatische Benachrichtigung
Feedback oder Beschwerde Portal, Umfrage, E-Mail oder persönlicher Kontakt
Ausfall des normalen Portals alternativer Kontaktweg

Die Organisation sollte deutlich kommunizieren:

Das Self-Service-Portal

Ein Self-Service-Portal kann Benutzer dabei unterstützen:

Mögliche Vorteile:

Mögliche Nachteile bei schlechter Gestaltung:

Merke

Ein Portal ist kein Selbstzweck.

Es muss den Benutzeraufwand reduzieren und die Bearbeitung verbessern.

Ein verständliches Portal gestalten

Ein Benutzer sollte möglichst nicht wissen müssen:

Ungeeignete Auswahl:

Verständlichere Auswahl:

Die technische Zuordnung kann anschließend:

erfolgen.

Formulare zweckmäßig gestalten

Ein Portalformular sollte nur Informationen verlangen, die für:

benötigt werden.

Mögliche Gestaltungsmittel:

Ungeeignete Pflichtfelder:

Besser:

Portal und Barrierefreiheit

Ein Portal sollte von möglichst vielen Benutzern selbstständig verwendet werden können.

Zu berücksichtigen sind beispielsweise:

Die konkreten verbindlichen Anforderungen hängen von Organisation, Land, Branche und Zielgruppe ab.

Wichtig

Wenn ein Portal für einen Benutzer nicht nutzbar ist, muss ein angemessener alternativer Kontaktweg bestehen.

Telefonischer Kontakt

Telefon eignet sich besonders für:

Mögliche Vorteile:

Mögliche Herausforderungen:

Der Service Desk sollte deshalb sicherstellen:

Telefonmenü und Warteschlange

Ein Telefonmenü kann Kontakte vorsortieren.

Es sollte jedoch:

sein.

Ungeeignet:

Drücken Sie 1 für Incident Management, 2 für Service Request Management, 3 für Configuration Management.

Benutzer kennen diese internen Begriffe möglicherweise nicht.

Verständlicher:

Drücken Sie 1 bei einer aktuellen technischen Störung.
Drücken Sie 2 für eine Bestellung oder Zugriffsanfrage.
Drücken Sie 3 bei einer verdächtigen E-Mail oder einem möglichen Sicherheitsvorfall.

Bei Warteschlangen können hilfreich sein:

E-Mail als Kontaktkanal

E-Mail ist leicht zugänglich und eignet sich unter anderem für:

Mögliche Nachteile:

Eine Support-E-Mail-Adresse sollte möglichst:

Sicherheitsrelevant

E-Mail ist nicht für jede vertrauliche Information oder jeden Sicherheitsvorfall geeignet.

Die Organisation muss zulässige Inhalte und alternative sichere Übertragungswege festlegen.

Gute Betreffzeilen und E-Mail-Inhalte

Ungeeigneter Betreff:

Hilfe!!!

Besser:

Anmeldung am Zeiterfassungssystem nicht möglich – Standort Mitte

Hilfreiche Angaben:

Der Service Desk sollte Benutzer nicht mit langen technischen Vorlagen überfordern.

Kurze Hinweise oder automatische Fragen können die Qualität verbessern.

Chat und Instant Messaging

Chat eignet sich für:

Mögliche Vorteile:

Mögliche Risiken:

Geeignete Regeln:

Privatnachrichten an Administratoren

Direkte Nachrichten an bekannte Administratoren wirken für Benutzer häufig schnell.

Sie erzeugen jedoch mögliche Probleme:

Eine professionelle Reaktion kann lauten:

Ich unterstütze gern. Bitte sende die Meldung über den Service-Desk-Kanal oder erlaube mir, daraus einen Vorgang zu erstellen. Dadurch bleibt die Bearbeitung auch bei meiner Abwesenheit nachvollziehbar.

Bei kritischen Situationen sollte die Meldung nicht nur zurückgewiesen werden.

Der Mitarbeiter sollte sicherstellen, dass:

wird.

Virtuelle Agenten und Chatbots

Ein virtueller Agent kann Benutzer unterstützen bei:

Mögliche Vorteile:

Mögliche Risiken:

Grundsatz

Ein virtueller Agent sollte nicht vorgeben, ein Mensch zu sein.

Benutzer sollten erkennen können, dass sie mit einem automatisierten System interagieren.

Menschliche Übergabe bei virtuellen Agenten

Ein Übergang zu einem Mitarbeiter sollte insbesondere möglich sein, wenn:

Bei der Übergabe sollten bereits erfasste Informationen erhalten bleiben.

Ungeeignet:

  1. Benutzer beantwortet zehn Fragen im Chatbot.
  2. Der Chatbot bietet eine Telefonnummer an.
  3. Der Mitarbeiter sieht keine bisherigen Angaben.
  4. Der Benutzer beginnt erneut.

Besser:

  1. Virtueller Agent erfasst grundlegende Angaben.
  2. Ein Vorgang wird erzeugt.
  3. Der Mitarbeiter erhält Verlauf und bisherige Ergebnisse.
  4. Der Benutzer wird über die Übergabe informiert.

Mobile Anwendungen

Eine mobile Supportanwendung kann hilfreich sein für:

Zu berücksichtigen sind:

Fotos und Anhänge sollten nur erfasst werden, wenn sie notwendig sind.

Dabei können versehentlich sichtbar werden:

Persönlicher Vor-Ort-Kontakt

Ein persönlicher Kontakt kann sinnvoll sein bei:

Mögliche Modelle:

Auch ein persönlicher Kontakt sollte nachvollziehbar dokumentiert werden, wenn:

entsteht.

Typischer Fehler

Vor-Ort-Hilfe wird vollständig außerhalb des Service-Management-Systems durchgeführt.

Dadurch bleiben Aufwand, wiederkehrende Probleme und wichtige Änderungen unsichtbar.

Walk-up Desk

Ein Walk-up Desk ist ein physischer Kontaktpunkt, an dem Benutzer persönlich Unterstützung erhalten.

Mögliche Vorteile:

Mögliche Herausforderungen:

Zu klären sind:

Automatisch erzeugte Kontakte

Nicht jeder Kontakt wird durch einen Menschen ausgelöst.

Mögliche technische Quellen:

Solche Meldungen können automatisch:

erzeugen.

Dabei muss geklärt sein:

Merke

Eine automatische Meldung ist nicht automatisch ein Incident.

Sie muss entsprechend ihrer Bedeutung und Auswirkung eingeordnet werden.

Besondere Meldewege für Sicherheitsereignisse

Mögliche Sicherheitsereignisse benötigen häufig einen besonders definierten Meldeweg.

Beispiele:

Der Meldeweg sollte:

sein.

Zusätzlich ist festzulegen:

Ungeeignet wäre ein verstecktes Formular mit vielen technischen Pflichtfeldern.

Notfall- und Major-Incident-Kanäle

Für besonders kritische Incidents kann ein eigener dringender Meldeweg sinnvoll sein.

Dieser darf nicht zur allgemeinen Beschleunigung normaler Anliegen missbraucht werden.

Mögliche Regeln:

Beispiel:

Ein Portalhinweis kann lauten:

Bei vollständigem Ausfall eines kritischen Produktionsservice außerhalb der Service-Desk-Zeit verwenden Sie die Bereitschaftsnummer. Normale Bestellungen und Einzelplatzprobleme werden am nächsten Arbeitstag bearbeitet.

Alternative Kanäle bei Ausfall des Service Desk

Der normale Kontaktweg kann selbst ausfallen.

Beispiele:

Deshalb sollte ein alternativer Meldeweg vorbereitet sein.

Mögliche Alternativen:

Der alternative Kanal sollte nicht von derselben ausgefallenen Komponente abhängen.

Praxistipp

Die Notfallkontaktinformationen sollten auch verfügbar sein, wenn das interne Netzwerk, das Portal oder das Identitätssystem nicht funktioniert.

Statusseite

Eine Statusseite kann Benutzer über bekannte Störungen, Wartungen und Wiederherstellungen informieren.

Mögliche Inhalte:

Vorteile:

Zu berücksichtigen sind:

Eine externe Statusseite darf keine sicherheitskritischen internen Details offenlegen.

Servicezeiten bestimmen

Servicezeiten sollten sich an den benötigten Outcomes und Risiken orientieren.

Zu untersuchen sind:

Mögliche Modelle:

Wichtig

Eine längere Servicezeit benötigt nicht nur einen zusätzlichen Telefonanschluss.

Sie benötigt Personal, Wissen, Befugnisse, Werkzeuge, Eskalationswege und erreichbare Lieferanten.

Erreichbarkeit außerhalb der Servicezeit

Außerhalb der regulären Servicezeit sollte klar sein:

Mögliche Ansage:

Der reguläre Service Desk ist derzeit geschlossen. Kritische Ausfälle der Produktionsservices können über die Bereitschaftsnummer gemeldet werden. Alle anderen Anliegen können im Portal erfasst werden und werden ab 08:00 Uhr bearbeitet.

Bereitschaft und Rufbereitschaft

Eine Bereitschaftsregelung sollte mindestens klären:

Problematisch sind informelle Regelungen wie:

Rufen Sie einfach jemanden aus der IT an.

Dies führt zu:

Follow-the-Sun

Bei internationalem Betrieb können Teams in verschiedenen Zeitzonen nacheinander übernehmen.

Voraussetzungen:

Eine Übergabe sollte enthalten:

Typischer Fehler

Der Vorgang wird am Schichtende nur einer anderen Gruppe zugewiesen, ohne dass Kontext und Verantwortung geklärt sind.

Sprachliche Erreichbarkeit

Bei mehrsprachigen Benutzergruppen ist zu klären:

Automatische Übersetzung kann unterstützen.

Kritische Informationen sollten jedoch überprüft werden, insbesondere bei:

Erreichbarkeit für externe Benutzer

Externe Kunden, Partner oder Lieferanten benötigen möglicherweise andere Kanäle als interne Mitarbeiter.

Zu berücksichtigen sind:

Ein externer Benutzer sollte nicht auf interne Portale oder Kommunikationskanäle zugreifen müssen, für die er keine Berechtigung besitzt.

Identitätsprüfung je Kanal

Nicht jede Anfrage benötigt dieselbe Identitätsprüfung.

Der Umfang sollte sich nach Risiko und verlangter Handlung richten.

Beispiele:

Handlung Mögliche Anforderung
allgemeine Serviceinformation möglicherweise keine besondere Prüfung
Status eines eigenen Tickets sichere Anmeldung oder Vorgangsprüfung
Kennwort zurücksetzen festgelegtes starkes Identitätsverfahren
Berechtigung ändern Identitäts- und Genehmigungsprüfung
vertrauliche Daten übermitteln geschützter Kanal
administrativen Zugriff aktivieren besonders starke Prüfung und Autorisierung

Sicherheitsrelevant

Telefonnummer, Absenderadresse oder angezeigter Name allein beweisen nicht zuverlässig die Identität einer Person.

Social Engineering berücksichtigen

Kontaktkanäle können durch Angreifer ausgenutzt werden.

Typische Warnzeichen:

Mitarbeiter benötigen:

Grundsatz

Gute Erreichbarkeit darf nicht auf Kosten von Identitätsprüfung und Informationssicherheit entstehen.

Kapazitätsplanung für Kontaktkanäle

Ein Kanal ist nur dann zuverlässig, wenn ausreichende Kapazität vorhanden ist.

Zu berücksichtigen sind:

Beispiele für Spitzen:

Mögliche Maßnahmen:

Warteschlangen steuern

Eine Warteschlange sollte nicht nur die Reihenfolge nach Eingangszeit berücksichtigen.

Abhängig vom Kanal können relevant sein:

Benutzer sollten möglichst erkennen können:

Überlauf und Ausweichregelungen

Bei ungewöhnlich hoher Nachfrage können Ausweichregeln notwendig sein.

Beispiele:

Zu vermeiden ist:

Kontaktkanäle und Service Levels

Serviceziele können je Kanal und Anliegen unterschiedlich sein.

Beispiele:

Die Ziele sollten:

sein.

Eine sehr kurze Reaktionszeit besitzt wenig Wert, wenn die erste Antwort nur lautet:

Ihr Ticket wurde erhalten.

Zusätzlich sollte geprüft werden, wann:

erfolgt.

Erreichbarkeit messen

Mögliche Kennzahlen:

Kennzahl Mögliche Aussage
Erreichbarkeitsquote Telefon Anteil angenommener Anrufe
durchschnittliche Wartezeit Zeit bis zur Annahme
Abbruchquote Anteil beendeter Kontakte vor Annahme
Rückrufzeit Zeit bis zum zugesagten Rückruf
erste qualifizierte Reaktionszeit Zeit bis zu einer verwertbaren Antwort
Portal-Abbruchquote Anteil nicht abgeschlossener Formulare
Chat-Übertragungsquote Anteil der Kontakte mit menschlicher Übergabe
Kanalwechselquote Anteil der Fälle, die einen weiteren Kanal benötigen
Wiederholungskontakte erneute Meldung zum selben Anliegen
Self-Service-Erfolgsquote erfolgreich ohne Service-Desk-Kontakt erledigte geeignete Anliegen
Kontakte außerhalb Servicezeit Hinweise auf unpassende Servicezeiten
falsch gewählter Kanal Hinweise auf unklare Kommunikation
Benutzeraufwand Anzahl notwendiger Kontakte oder Wiederholungen

Keine einzelne Kennzahl beschreibt die tatsächliche Erreichbarkeit vollständig.

Abbruchquote richtig einordnen

Eine hohe Abbruchquote kann entstehen durch:

Eine niedrige Abbruchquote beweist nicht automatisch gute Erreichbarkeit.

Möglicherweise:

Kennzahlen müssen deshalb gemeinsam mit:

betrachtet werden.

First Contact Resolution nach Kanal

First Contact Resolution kann je Kanal unterschiedlich bewertet werden.

Beispiele:

Dabei muss geprüft werden:

Self-Service-Erfolg richtig messen

Unzureichende Kennzahl:

Anzahl der Portalaufrufe

Hilfreichere Fragen:

Merke

Ein Benutzer, der nach mehreren erfolglosen Self-Service-Versuchen anruft, hat mehr und nicht weniger Aufwand erlebt.

Kanalqualität regelmäßig überprüfen

Kontaktkanäle verändern sich durch:

Regelmäßig zu prüfen sind:

Kanäle nicht nur hinzufügen, sondern auch entfernen

Neue Kanäle werden häufig schnell ergänzt.

Alte Kanäle bleiben jedoch bestehen.

Dadurch können entstehen:

Vor der Abschaltung eines Kanals sollte geprüft werden:

Einführung eines neuen Kanals

Eine mögliche Vorgehensweise:

  1. Benutzerbedarf und Problem beschreiben
  2. geeignete Anwendungsfälle festlegen
  3. Sicherheits- und Datenschutzanforderungen prüfen
  4. Verantwortlichkeit bestimmen
  5. technische Integration planen
  6. Servicezeiten und Kapazität festlegen
  7. Pilotgruppe auswählen
  8. Erfolgskriterien definieren
  9. Mitarbeiter und Benutzer informieren
  10. Ergebnisse messen
  11. Kanal anpassen oder ausweiten
  12. bestehende Kanäle erneut bewerten

Beispiel:

Ein Chatkanal sollte nicht nur deshalb eingeführt werden, weil die verwendete Plattform diese Funktion anbietet.

Zu prüfen ist:

Kontaktkanäle bei einem Major Incident

Während eines Major Incidents kann das Kontaktvolumen stark steigen.

Geeignete Maßnahmen:

Benutzerkanal und technischer Koordinationskanal sollten unterschieden werden.

Benutzerkanal

Technischer Koordinationskanal

Technische interne Diskussionen sollten nicht ungefiltert in öffentliche Statusmeldungen übernommen werden.

Kontaktkanäle bei Sicherheitsvorfällen

Bei einem möglichen Sicherheitsvorfall können zusätzliche Anforderungen gelten.

Beispiele:

Der normale Service Desk kann den ersten Kontakt aufnehmen.

Er muss jedoch wissen:

Kontaktkanäle bei Service Requests

Standardisierte Service Requests eignen sich häufig gut für Portale und Automatisierung.

Beispiele:

Ein gutes Request-Formular kann:

Der Benutzer sollte erkennen können:

Kontaktkanäle beim Onboarding

Beim Onboarding entstehen häufig mehrere Kontakte:

Ein zentraler digitaler Einstieg kann helfen, Informationen einmalig und strukturiert zu erfassen.

Dabei muss geklärt sein:

Der letzte Punkt ist besonders wichtig.

Ein ausschließlich internes Portal ist möglicherweise nicht nutzbar, wenn der Benutzer noch keinen funktionierenden Zugang besitzt.

Praxisbeispiel: Portal wird kaum verwendet

Beobachtung

Ungeeignete Reaktion

Ab nächster Woche werden telefonische Anfragen nicht mehr angenommen.

Bessere Untersuchung

Mögliche Verbesserungen

Praxisbeispiel: Zu viele E-Mail-Tickets

Beobachtung

Mögliche Verbesserungen

E-Mail muss nicht zwingend abgeschafft werden.

Sie kann für bestimmte Benutzergruppen weiterhin ein sinnvoller Kanal sein.

Praxisbeispiel: Support außerhalb der Geschäftszeit

Ausgangslage

Möglicher Zielzustand

Zusätzlich zu klären

Praxisbeispiel: Virtueller Agent blockiert Benutzer

Ausgangslage

Mögliche Verbesserungen

Merke

Automatisierung soll einen Kontakt vereinfachen und nicht als Barriere vor menschlicher Unterstützung dienen.

Praxisbeispiel: Ticketsystem fällt aus

Situation

Vorbereitete Lösung

Zu vermeiden:

Typische Fehler bei Kontaktkanälen

Fehler 1: Möglichst viele Kanäle anbieten

Die Organisation kann sie nicht zuverlässig überwachen und zusammenführen.

Fehler 2: Portalzwang ohne geeignete Alternative

Komplexe, dringende oder barrierebedingte Situationen werden nicht berücksichtigt.

Fehler 3: Technische Verfügbarkeit mit Supportzeit verwechseln

Benutzer erwarten sofortige Bearbeitung, obwohl nur eine automatische Erfassung erfolgt.

Fehler 4: Private Supportkanäle dulden

Meldungen verschwinden in persönlichen Chats, Postfächern oder Telefonlisten.

Fehler 5: Benutzer müssen das technische Team auswählen

Falsche Zuordnungen und unnötige Weiterleitungen entstehen.

Fehler 6: Kritische und normale Anliegen verwenden denselben unpriorisierten Kanal

Dringende Meldungen werden möglicherweise zu spät erkannt.

Fehler 7: Kein alternativer Kanal

Beim Ausfall von Portal, E-Mail oder Identitätsdienst ist der Service Desk nicht erreichbar.

Fehler 8: Virtueller Agent ohne menschlichen Ausweg

Benutzer bleiben in automatisierten Antwortschleifen.

Fehler 9: Kanäle werden nicht sicher gestaltet

Identitätsprüfung, Datenschutz und vertrauliche Kommunikation fehlen.

Fehler 10: Servicezeiten sind nicht sichtbar

Benutzer wissen nicht, wann mit einer Reaktion zu rechnen ist.

Fehler 11: Kanalwechsel verliert den Kontext

Benutzer müssen ihre Situation mehrfach erklären.

Fehler 12: Self-Service nur zur Kostensenkung

Benutzeraufwand und Abbruchquote steigen.

Fehler 13: Statusseite wird nicht aktualisiert

Veraltete Informationen beschädigen das Vertrauen.

Fehler 14: Bereitschaft ist nur informell geregelt

Einzelne Mitarbeiter werden unkoordiniert und ohne Vertretung kontaktiert.

Fehler 15: Kennzahlen werden isoliert optimiert

Kurze Wartezeiten werden erreicht, während Lösungsqualität und Benutzererfahrung sinken.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten häufig in Service Desk, Betrieb oder nachgelagerten Supportgruppen.

Sie sollten die vorgesehenen Kontaktwege kennen und unterstützen.

Wichtige Verhaltensweisen:

Beispiel:

Ein Benutzer schreibt einem Administrator direkt:

Der Fileserver geht nicht.

Ungeeignet:

Dafür bin ich nicht zuständig. Eröffnen Sie ein Ticket.

Besser:

Ich erfasse die Meldung im Service Desk, damit sie nachvollziehbar bearbeitet wird. Können Sie mir kurz sagen, ob nur Sie oder weitere Benutzer betroffen sind?

Anschließend:

30-Sekunden-Prüfung eines Kontaktkanals

  1. Zielgruppe: Wer soll den Kanal verwenden?
  2. Anliegen: Für welche Kontakte ist er geeignet?
  3. Servicezeit: Wann wird er tatsächlich bearbeitet?
  4. Verantwortung: Wer überwacht den Kanal?
  5. Integration: Werden Kontakte zentral dokumentiert?
  6. Sicherheit: Wie werden Identität und Informationen geschützt?
  7. Barrierefreiheit: Können die vorgesehenen Benutzer den Kanal verwenden?
  8. Eskalation: Wie gelangen kritische Anliegen schnell zur richtigen Stelle?
  9. Alternative: Was geschieht bei Ausfall des Kanals?
  10. Übergabe: Bleiben Informationen bei einem Kanalwechsel erhalten?
  11. Messung: Wie wird die Wirksamkeit überprüft?
  12. Verbesserung: Wie wird Benutzerfeedback verwendet?

Checkliste für ein Self-Service-Portal

Checkliste für telefonischen Support

Checkliste für E-Mail-Support

Checkliste für Chat und virtuelle Agenten

Checkliste für Erreichbarkeit außerhalb der Servicezeit

Checkliste für die gesamte Kanalstrategie

Schnellreferenz

Kanal Besonders geeignet für Besonders zu beachten
Portal strukturierte Incidents und Requests Verständlichkeit, Suche und Alternativkanal
Telefon dringende und komplexe Situationen Wartezeit, Dokumentation und Identitätsprüfung
E-Mail schriftliche, weniger dringende Anliegen Vollständigkeit, Anhänge und Sicherheit
Chat schnelle Rückfragen und begleitete Diagnose Dokumentation und Übergabe
virtueller Agent häufige standardisierte Anliegen Transparenz, Qualität und menschlicher Ausweg
mobile App mobile Benutzer und Statusinformationen Gerätesicherheit und Datenschutz
Vor-Ort-Kontakt Geräteprobleme und komplexe Unterstützung Dokumentation und Priorisierung
Notfallkanal klar definierte kritische Situationen Missbrauchsschutz und schnelle Eskalation
Statusseite bekannte Störungen und Wartungen Aktualität und Schutz vertraulicher Informationen

Zusammenfassende Darstellung

Benutzer benötigt Unterstützung
↓
geeigneten und bekannten Kontaktkanal auswählen
↓
Kanal ist technisch verfügbar und organisatorisch besetzt
↓
Identität und Anliegen angemessen erfassen
↓
Kontakt zentral dokumentieren und fachlich einordnen
↓
geeigneten Wertstrom und zuständige Fähigkeiten einbinden
↓
Status über den passenden Kanal kommunizieren
↓
bei Bedarf Kanal wechseln, ohne Informationen zu verlieren
↓
Outcome bestätigen
↓
Kanalqualität und Benutzererfahrung auswerten
↓
Kontaktstrategie fortlaufend verbessern

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Offiziell bestätigter Stand

Die offiziellen ITIL- und PeopleCert-Quellen bestätigen:

Einordnung

Die auf dieser Seite beschriebenen:

sind herstellerneutrale redaktionelle Empfehlungen dieses unabhängigen Nachschlagewerks.

ITIL schreibt keine universelle:

vor.

Die konkrete Kanalstrategie muss an:

angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle öffentlich zugängliche ITIL-4-Service-Desk-Guidance
Fachlicher Stand: August 2026

3. Service Desk, Support und operative Servicearbeit

3.3 Benutzerkommunikation und professioneller Umgang

Kurz erklärt

Benutzerkommunikation ist ein wesentlicher Bestandteil der Serviceerfahrung.

Ein technisches Problem wird aus Sicht eines Benutzers nicht nur danach bewertet:

Professionelle Kommunikation bedeutet:

Empathie ist dabei kein Ersatz für technische Kompetenz.

Sie hilft, technische Kompetenz so einzusetzen und zu vermitteln, dass Benutzer Vertrauen gewinnen und handlungsfähig bleiben.

Warum Kommunikation Teil der Serviceleistung ist

Benutzer erleben einen Service nicht ausschließlich über:

Sie erleben ihn auch über die Interaktionen mit der Serviceorganisation.

Dazu gehören:

Ein Service kann technisch wiederhergestellt sein und trotzdem eine schlechte Erfahrung hinterlassen.

Beispiele:

Merke

Kommunikation ist kein Zusatz zur technischen Bearbeitung.

Sie ist ein sichtbarer Bestandteil der gesamten Serviceerfahrung.

Technische Qualität und Kommunikation wirken zusammen

Technische Bearbeitung Kommunikation Mögliche Wahrnehmung
schnell und wirksam verständlich und zuverlässig sehr positive Erfahrung
schnell und wirksam unfreundlich oder unklar technisch erfolgreich, aber negatives Vertrauen
langsam oder komplex transparent und regelmäßig Situation bleibt belastend, aber nachvollziehbar
langsam oder komplex keine verlässlichen Informationen starke Unsicherheit und negative Erfahrung
technisch nicht lösbar Alternativen und Grenzen werden verständlich erklärt realistische und professionelle Behandlung
technisch scheinbar gelöst Benutzer kann weiterhin nicht arbeiten tatsächliches Outcome nicht erreicht

Eine freundliche Kommunikation kann eine schlechte technische Leistung nicht dauerhaft ausgleichen.

Eine gute technische Leistung kann jedoch ebenfalls an Wert verlieren, wenn die Kommunikation:

ist.

Ziel professioneller Benutzerkommunikation

Professionelle Kommunikation soll dazu beitragen, dass:

Sie soll nicht nur möglichst freundlich klingen.

Sie muss außerdem:

sein.

Kommunikation an Wissen und Kontext anpassen

Service-Desk-Mitarbeiter sprechen mit Personen mit unterschiedlichen:

Eine identische Erklärung ist deshalb nicht für jede Person geeignet.

Beispiel für einen technisch erfahrenen Ansprechpartner:

Die Namensauflösung funktioniert, aber die TCP-Verbindung zum Dienst wird am Standort blockiert. Das Netzwerkteam prüft aktuell Firewall und Routing.

Beispiel für einen Benutzer ohne technischen Schwerpunkt:

Ihr Computer erreicht den zentralen Dienst derzeit nicht. Das zuständige Netzwerkteam prüft die Verbindung. Sie müssen im Moment keine weiteren Einstellungen verändern.

Beide Aussagen können dieselbe Situation beschreiben.

Die Formulierung wird an die jeweilige Zielgruppe angepasst.

Merke

Verständliche Kommunikation bedeutet nicht, Informationen ungenau oder falsch darzustellen.

Sie bedeutet, die benötigte Information in einer geeigneten Sprache und Detailtiefe zu vermitteln.

Fachsprache bewusst verwenden

Technische Fachbegriffe sind sinnvoll, wenn:

Sie sind ungeeignet, wenn sie:

Ungeeignet:

Der SAML-Assertion-Consumer-Service liefert aufgrund eines fehlerhaften IdP-Mappings einen Authentifizierungsfehler.

Verständlicher:

Die Anmeldung zwischen dem Identitätsdienst und der Anwendung funktioniert derzeit nicht korrekt. Das zuständige Team prüft die Zuordnung. Ihr Kennwort müssen Sie nicht erneut ändern.

Für ein technisches Fachteam kann die detaillierte Beschreibung weiterhin notwendig sein.

Benutzerkommunikation und technische Dokumentation dürfen deshalb unterschiedliche Detailstufen besitzen.

Aktives Zuhören

Aktives Zuhören bedeutet, den Benutzer nicht nur sprechen zu lassen, sondern seine Informationen bewusst aufzunehmen und zu überprüfen.

Dazu gehören:

Beispiel:

Benutzer:

Seit heute Morgen geht bei mir gar nichts mehr.

Ungeeignete Reaktion:

Haben Sie den Computer schon neu gestartet?

Bessere Reaktion:

Ich kläre kurz, was genau betroffen ist. Können Sie sich nicht am Computer anmelden oder funktionieren nach der Anmeldung bestimmte Anwendungen nicht?

Die zweite Reaktion verhindert, dass sofort eine Lösung versucht wird, bevor das Problem ausreichend verstanden ist.

Offene und geschlossene Fragen

Beide Fragearten können sinnvoll sein.

Offene Fragen

Sie ermöglichen eine freie Beschreibung.

Beispiele:

Geschlossene Fragen

Sie klären konkrete Punkte.

Beispiele:

Eine sinnvolle Gesprächsführung beginnt häufig mit einer offenen Frage und wird anschließend durch konkrete Fragen präzisiert.

Das Verstandene zusammenfassen

Eine kurze Zusammenfassung hilft, Missverständnisse früh zu erkennen.

Beispiel:

Ich fasse kurz zusammen: Sie können sich seit ungefähr 09:15 Uhr am Zeiterfassungssystem anmelden, aber beim Speichern erscheint die Meldung „Zugriff verweigert“. Zwei Kollegen in derselben Abteilung sind ebenfalls betroffen. Andere Anwendungen funktionieren. Ist das korrekt?

Vorteile:

Empathie

Empathie bedeutet, die Situation und Perspektive einer anderen Person wahrzunehmen und angemessen darauf zu reagieren.

Sie bedeutet nicht:

Geeignete empathische Aussagen:

Ungeeignete Aussagen:

Wichtig

Empathie erkennt die Auswirkung an.

Sie verspricht nicht automatisch eine sofortige Lösung.

Empathie und Priorisierung unterscheiden

Ein Benutzer kann stark belastet sein, während die organisatorisch bestimmte Priorität trotzdem nicht die höchste Stufe erreicht.

Beispiel:

Ich verstehe, dass Sie die Anwendung für Ihre aktuelle Aufgabe benötigen. Nach unseren Kriterien ist derzeit nur Ihr Arbeitsplatz betroffen und ein Ersatzarbeitsplatz steht zur Verfügung. Der Vorgang wird deshalb mit Priorität 3 bearbeitet. Sollte auch die Alternative ausfallen oder weitere Benutzer betroffen sein, bewerten wir die Priorität erneut.

Diese Aussage:

Ungeeignet:

Dafür bekommen Sie keine höhere Priorität.

Eine professionelle Gesprächsstruktur

Eine mögliche Struktur für einen Benutzerkontakt ist:

  1. Kontakt eröffnen
  2. Identität und Zuständigkeit klären
  3. Anliegen frei beschreiben lassen
  4. Situation und Auswirkungen präzisieren
  5. das Verstandene zusammenfassen
  6. Einordnung und nächsten Schritt erklären
  7. Erwartungen und Zeitpunkte klären
  8. Maßnahme durchführen oder weiterleiten
  9. Ergebnis prüfen
  10. Kontakt professionell abschließen

Diese Struktur ist eine Praxisempfehlung und kein für jede Situation vorgeschriebener ITIL-Prozess.

1. Kontakt eröffnen

Eine geeignete Eröffnung sollte:

sein.

Telefon:

Guten Morgen, IT-Service-Desk, Max Mustermann. Wie kann ich Sie unterstützen?

Chat:

Hallo, Sie sind beim IT-Service-Desk. Ich schaue mir Ihr Anliegen gern an. Wobei benötigen Sie Unterstützung?

E-Mail:

Guten Tag, vielen Dank für Ihre Meldung. Ich prüfe zunächst die betroffene Anwendung und die bisher bekannten Auswirkungen.

Bei bereits bekannten Vorgängen:

Guten Tag, ich melde mich zu Ihrem Vorgang 4711 bezüglich des Dateizugriffs.

2. Identität und Zuständigkeit klären

Abhängig vom Anliegen kann geprüft werden:

Eine starke Identitätsprüfung darf nicht durch freundliches Auftreten oder angeblichen Zeitdruck ersetzt werden.

Ungeeignet:

Sie klingen glaubwürdig. Ich setze das Kennwort direkt zurück.

Besser:

Für die Kennwortzurücksetzung muss ich Ihre Identität nach unserem festgelegten Verfahren prüfen. Ich führe Sie kurz durch die erforderlichen Schritte.

3. Anliegen beschreiben lassen

Der Benutzer sollte zunächst ausreichend Gelegenheit erhalten, seine Beobachtung zu schildern.

Hilfreiche Einstiegsfragen:

Zu frühe technische Vermutungen können die Beschreibung verfälschen.

Beispiel:

Ungeeignet:

Dann ist bestimmt Ihr VPN kaputt.

Besser:

Ich prüfe zunächst, ob die Verbindung oder die Anwendung selbst betroffen ist.

4. Auswirkungen präzisieren

Wichtige Fragen:

Die Kommunikation sollte nicht nur das technische Symptom erfassen.

Beispiel:

Der Drucker funktioniert nicht.

Die tatsächliche Auswirkung kann reichen von:

bis zu:

5. Zusammenfassen und bestätigen

Beispiel:

Sie können seit etwa 13:00 Uhr keine Versandetiketten drucken. Betroffen sind alle vier Arbeitsplätze im Warenausgang. Andere Drucker funktionieren, aber es gibt dort keine zulässige Alternative für die Etiketten. Der Versand steht deshalb momentan still. Ist diese Zusammenfassung korrekt?

Diese Informationen unterstützen:

6. Nächsten Schritt erklären

Der Benutzer sollte wissen:

Beispiel:

Ich prüfe zunächst, ob bereits eine allgemeine Störung bekannt ist. Danach teste ich die Verbindung zum Druckservice. Falls die Ursache dort nicht erkennbar ist, binde ich das zuständige Druck- und Netzwerkteam ein.

Ungeeignet:

Ich gebe das weiter.

Besser:

Ich gebe den Vorgang mit den bisherigen Prüfergebnissen an das Netzwerkteam. Der Service Desk behält die Kommunikation. Sie erhalten spätestens um 14:30 Uhr eine Statusmeldung, auch wenn die Ursache dann noch nicht vollständig behoben ist.

7. Erwartungen realistisch steuern

Zu klären sind:

Eine realistische Aussage ist besser als eine beruhigend gemeinte, aber unbelegte Zusage.

Ungeeignet:

Das ist gleich erledigt.

Besser:

Die Ursache ist noch nicht bestätigt. Das zuständige Team beginnt jetzt mit der Analyse. Eine verlässliche Lösungszeit kann ich noch nicht nennen. Die nächste Rückmeldung erfolgt spätestens um 16:00 Uhr.

8. Maßnahme durchführen oder weiterleiten

Während einer Maßnahme sollte erklärt werden:

Beispiel:

Ich starte nicht den gesamten Computer neu. Zuerst beende ich nur den betroffenen Druckdienst, weil die anderen Anwendungen ordnungsgemäß funktionieren.

Bei einer Remote-Sitzung:

Ich öffne jetzt die Netzwerkeinstellungen und prüfe die bestehende Verbindung. Ich ändere noch keine Konfiguration. Sollte eine Änderung erforderlich sein, erkläre ich sie vorher.

9. Ergebnis prüfen

Nach einer technischen Maßnahme sollte nicht nur gefragt werden:

Geht es jetzt?

Präzisere Prüfung:

Das Ergebnis sollte sich am ursprünglichen Outcome orientieren.

10. Kontakt abschließen

Ein professioneller Abschluss kann enthalten:

Beispiel:

Die Anmeldung funktioniert wieder und Sie konnten den Auftrag erfolgreich speichern. Die Ursache war eine fehlerhafte Gruppenmitgliedschaft. Der Vorgang bleibt noch bis morgen zur Kontrolle geöffnet. Sollte der Fehler erneut auftreten, antworten Sie bitte unter Angabe der Vorgangsnummer 4711.

Bei ungelöster Situation:

Die Störung ist noch nicht behoben. Das Anwendungsteam untersucht aktuell die fehlerhafte Berechtigung. Als Zwischenlösung können Sie den Auftrag über Arbeitsplatz 12 bearbeiten. Die nächste Statusmeldung erfolgt spätestens um 11:30 Uhr.

Klare Sprache verwenden

Klare Sprache zeichnet sich aus durch:

Ungeeignet:

Bitte führen Sie das übliche Prozedere durch und melden Sie sich gegebenenfalls erneut.

Besser:

Starten Sie die Anwendung einmal neu. Melden Sie sich anschließend erneut an. Falls wieder die Meldung „Zugriff verweigert“ erscheint, antworten Sie bitte direkt auf diese Nachricht.

Nur eine Handlung pro Schritt

Besonders bei Telefon, Chat oder E-Mail sollten technische Anweisungen klar gegliedert sein.

Ungeeignet:

Öffnen Sie die Einstellungen, prüfen Sie die Verbindung, löschen Sie den Cache, starten Sie neu und probieren Sie es noch einmal.

Besser:

  1. Öffnen Sie die Anwendung noch nicht erneut.
  2. Prüfen Sie unten rechts, ob das Netzwerksymbol eine Verbindung anzeigt.
  3. Teilen Sie mir bitte mit, welches Symbol angezeigt wird.
  4. Danach bestimmen wir den nächsten Schritt.

Dadurch kann das Ergebnis jedes einzelnen Schritts bewertet werden.

Richtung und Ort eindeutig beschreiben

Ungeeignet:

Besser:

Öffnen Sie oben rechts das Benutzermenü und wählen Sie anschließend „Abmelden“.

Bei mehreren Betriebssystemen oder Versionen sollte vorher geklärt werden:

verwendet wird.

Keine unnötigen Vermutungen als Tatsache darstellen

Ungeeignet:

Das liegt sicher an Ihrem WLAN.

Besser:

Eine instabile Verbindung ist eine mögliche Ursache. Ich prüfe zunächst, ob auch andere Benutzer oder Netzwerkverbindungen betroffen sind.

Ungeeignet:

Der Hersteller hat gerade eine Störung.

Besser:

Beim Hersteller ist derzeit eine mögliche Störung gemeldet. Wir prüfen noch, ob sie mit Ihrem Problem zusammenhängt.

Transparenz über Unsicherheit

Professionelle Kommunikation darf Unsicherheit enthalten.

Geeignete Aussagen:

Ungeeignet ist, Unsicherheit durch scheinbare Gewissheit zu verdecken.

Merke

Ehrliche Unsicherheit kann Vertrauen erhalten.

Falsche Sicherheit beschädigt Vertrauen, sobald eine Zusage nicht eingehalten wird.

Zusagen einhalten

Zusagen können sein:

Kann eine Zusage nicht eingehalten werden, sollte die Information vor Ablauf des zugesagten Zeitpunkts erfolgen.

Beispiel:

Die angekündigte Rückmeldung um 14:00 Uhr kann ich noch nicht mit einer Lösung verbinden. Das Netzwerkteam prüft weiterhin die Standortverbindung. Der Provider wurde inzwischen einbezogen. Die nächste Aktualisierung erfolgt spätestens um 15:00 Uhr.

Ungeeignet:

Statuskommunikation

Eine hilfreiche Statusmeldung beantwortet möglichst:

Beispiel:

Seit 10:20 Uhr ist die zentrale Dateiablage für die Standorte Nord und West nicht erreichbar. Das Netzwerkteam untersucht die Verbindung zum Rechenzentrum. Lokal gespeicherte Dateien sind nicht betroffen. Bitte führen Sie keine wiederholten Neustarts durch. Eine nächste Statusmeldung erfolgt spätestens um 11:00 Uhr.

Statusmeldung ohne neue technische Erkenntnis

Auch wenn noch keine Lösung vorliegt, kann eine Statusmeldung sinnvoll sein.

Beispiel:

Die Analyse läuft weiter. Eine eindeutige Ursache wurde noch nicht bestätigt. Der Hersteller prüft derzeit die Protokolldaten. Die bisher genannte Zwischenlösung bleibt gültig. Die nächste Aktualisierung erfolgt um 16:30 Uhr.

Dadurch weiß der Benutzer:

Kommunikationshäufigkeit an die Situation anpassen

Ein kritischer Incident benötigt häufigere Statusinformationen als eine normale Serviceanfrage.

Mögliche Einflussfaktoren:

Zu häufige Meldungen ohne Inhalt können:

Zu seltene Meldungen erzeugen:

Zielgruppengerechte Statusinformationen

Unterschiedliche Stakeholder benötigen unterschiedliche Informationen.

Zielgruppe Häufig benötigte Information
Benutzer Auswirkung, Zwischenlösung, nächstes Update
Service Desk bekannte Symptome, betroffene Gruppen, freigegebene Formulierung
technisches Team Diagnose, Protokolle, Hypothesen, nächste Maßnahmen
Service Owner Serviceauswirkung, Risiken, Fortschritt und Entscheidungen
Führungskräfte Geschäftsfolgen, erwartete Dauer, Risiken und benötigte Entscheidungen
Lieferant technische Nachweise, Vertragsbezug, Priorität und gewünschte Unterstützung
Informationssicherheit mögliche Daten- oder Sicherheitsauswirkung und gesicherte Beweise

Eine technische Arbeitsnotiz sollte nicht unverändert an alle Benutzer gesendet werden.

Kommunikation bei geplanten Wartungen

Eine Wartungsankündigung sollte möglichst enthalten:

Beispiel:

Am Sonntag, 9. August 2026, wird der zentrale Dateiservice zwischen 08:00 und 10:00 Uhr aktualisiert. In diesem Zeitraum können Dateien vorübergehend nicht geöffnet oder gespeichert werden. Bitte schließen Sie geöffnete Dateien bis 07:45 Uhr. Eine Statusmeldung erfolgt nach Abschluss der Arbeiten.

Ungeeignet:

Am Wochenende finden Wartungsarbeiten statt.

Unterschied zwischen Information und Handlungsaufforderung

Benutzer sollten erkennen können, ob sie:

müssen.

Beispiel:

Keine Handlung erforderlich: Die Aktualisierung wird automatisch installiert.

Beispiel:

Handlung erforderlich: Speichern Sie Ihre Arbeit und starten Sie das Gerät spätestens am Freitag neu.

Eine klare Kennzeichnung reduziert Missverständnisse.

Schriftliche Kommunikation

Schriftliche Kommunikation sollte:

enthalten.

Ungeeigneter Betreff:

Update

Besser:

Status zum Ausfall der Dateiablage – nächstes Update um 15:00 Uhr

Ungeeignete Nachricht:

Wir arbeiten daran.

Besser:

Die Dateiablage ist weiterhin für die Standorte Nord und West nicht erreichbar. Der Provider untersucht aktuell die externe Verbindung. Lokal gespeicherte Dateien können weiterverwendet werden. Die nächste Statusmeldung erfolgt spätestens um 15:00 Uhr.

E-Mail-Kommunikation strukturieren

Eine praktische Struktur:

Beispiel:

Guten Tag,

der Zugriff auf das Abrechnungssystem ist seit 09:40 Uhr für mehrere Benutzer eingeschränkt.

Das Anwendungsteam untersucht aktuell die Anmeldung. Bitte ändern Sie Ihr Kennwort nicht erneut, da das Problem nicht durch ein falsches Kennwort verursacht wird.

Eine nächste Statusmeldung erfolgt spätestens um 11:00 Uhr.

Vorgangsnummer: 4711

Chat-Kommunikation

Im Chat sollten Nachrichten:

geschrieben werden.

Ungeeignet:

ok warte

Besser:

Ich prüfe jetzt, ob bereits eine allgemeine Störung bekannt ist. Das dauert voraussichtlich wenige Minuten. Bitte lassen Sie das Chatfenster geöffnet.

Bei längerer Unterbrechung:

Die Prüfung dauert länger als erwartet. Ich erstelle einen Vorgang und informiere Sie per E-Mail weiter. Ihre Vorgangsnummer lautet 4711.

Telefonische Kommunikation

Beim Telefonkontakt sind besonders wichtig:

Beispielabschluss:

Wir haben die Anwendung neu angemeldet und der Zugriff funktioniert wieder. Ich dokumentiere die Lösung unter Vorgang 4711. Sollte die Meldung erneut erscheinen, rufen Sie bitte nicht alle Schritte erneut durch, sondern nennen Sie direkt diese Vorgangsnummer.

Persönlicher Kontakt

Beim Vor-Ort-Support sollte der Mitarbeiter:

Ungeeignet:

Kommunikation bei Remote-Support

Vor einer Remote-Sitzung sollte geklärt werden:

Geeignete Formulierung:

Mit Ihrer Zustimmung starte ich eine Remote-Sitzung. Sie können alle Schritte sehen und die Sitzung jederzeit beenden. Ich prüfe nur die Einstellungen der betroffenen Anwendung. Bitte schließen Sie vorher vertrauliche Dokumente.

Während der Sitzung:

Ich öffne jetzt die Anwendungsprotokolle. Dabei werden keine persönlichen Dateien verändert.

Nach der Sitzung:

Die Remote-Verbindung ist beendet. Wir haben nur die Anwendungseinstellungen angepasst. Bitte testen Sie jetzt den vollständigen Arbeitsschritt.

Fehler nicht vorschnell dem Benutzer zuschreiben

Ungeeignet:

Besser:

Auch wenn ein Bedienfehler vorliegt, sollte die Organisation prüfen:

Keine Schuldzuweisung zwischen Teams

Ungeeignet gegenüber Benutzern:

Besser:

Interne Ursachen können später sachlich untersucht werden.

Die Benutzerkommunikation sollte nicht zur öffentlichen Schuldzuweisung verwendet werden.

Umgang mit verärgerten Benutzern

Ein verärgerter Benutzer kann:

Eine mögliche Vorgehensweise:

  1. nicht sofort in die Verteidigung gehen
  2. ausreden lassen, soweit möglich
  3. Auswirkung anerkennen
  4. Sachverhalt zusammenfassen
  5. konkrete nächste Schritte nennen
  6. realistische Grenzen erklären
  7. vereinbaren, wann die nächste Information erfolgt

Beispiel:

Ich verstehe, dass der wiederholte Ausfall Ihren Monatsabschluss erheblich behindert. Der Service ist noch nicht stabil. Das Anwendungsteam und der Hersteller arbeiten gemeinsam an der Ursache. Als Zwischenlösung können Sie die Buchungen derzeit über Arbeitsplatz 4 durchführen. Ich informiere Sie spätestens um 13:00 Uhr erneut.

Nicht jede Beschwerde persönlich nehmen

Benutzerfrust richtet sich häufig gegen:

Mitarbeiter sollten Beschwerden ernst nehmen, ohne jede Aussage als persönliche Bewertung zu übernehmen.

Gleichzeitig muss respektloses Verhalten nicht unbegrenzt akzeptiert werden.

Grenzen bei aggressivem oder beleidigendem Verhalten

Professioneller Umgang gilt für alle Beteiligten.

Mitarbeiter müssen:

nicht akzeptieren.

Eine mögliche Reaktion:

Ich möchte Ihr Anliegen gern weiter bearbeiten. Dafür benötige ich ein respektvolles Gespräch. Wenn die Beleidigungen fortgesetzt werden, muss ich den Kontakt beenden und nach unserem Eskalationsverfahren weitergeben.

Bei konkreten Drohungen oder Sicherheitsrisiken sind die internen Sicherheits- und Eskalationsverfahren anzuwenden.

Wichtig

Empathie bedeutet nicht, missbräuchliches Verhalten hinzunehmen.

Deeskalation

Hilfreiche Maßnahmen:

Ungeeignet:

Wenn Sie mich nicht ausreden lassen, kann ich auch nichts machen.

Besser:

Ich möchte die Situation lösen. Dafür fasse ich kurz zusammen, was bereits bekannt ist, und erkläre anschließend die zwei möglichen nächsten Schritte.

Umgang mit Beschwerden

Eine Beschwerde kann Hinweise liefern auf:

Eine Beschwerde sollte:

werden.

Geeignete Antwort:

Vielen Dank für die konkrete Rückmeldung. Sie haben an drei aufeinanderfolgenden Tagen keine angekündigte Statusmeldung erhalten. Ich dokumentiere das als Abweichung und lasse zusätzlich prüfen, warum die Kommunikationsintervalle nicht eingehalten wurden.

Ungeeignet:

Dafür müssen Sie sich an jemand anderen wenden.

Umgang mit Führungskräften und wichtigen Stakeholdern

Hierarchische Positionen können besondere Informationsbedürfnisse erzeugen.

Sie dürfen jedoch nicht automatisch:

Professionelle Kommunikation:

Ich verstehe die geschäftliche Bedeutung Ihres Termins. Für eine höhere Priorität benötige ich noch die Information, ob weitere Benutzer oder ein zentraler Geschäftsprozess betroffen sind. Die Identitätsprüfung für den Zugriff muss trotzdem vollständig durchgeführt werden.

Bei Bedarf kann eine hierarchische Eskalation erfolgen.

Umgang mit wiederholten Nachfragen

Wiederholte Nachfragen können ein Hinweis sein auf:

Die Antwort sollte nicht nur lauten:

Wir arbeiten noch daran.

Besser:

Seit der letzten Meldung wurde der Fehler auf die Verbindung zwischen Anwendung und Datenbank eingegrenzt. Das Datenbankteam prüft aktuell die fehlgeschlagenen Verbindungen. Eine Wiederherstellungszeit liegt noch nicht vor. Die nächste Statusmeldung erfolgt um 16:00 Uhr.

Umgang mit nicht erfüllbaren Forderungen

Manche Forderungen können nicht erfüllt werden, weil sie:

sind.

Eine professionelle Ablehnung enthält möglichst:

  1. klare Aussage
  2. verständliche Begründung
  3. mögliche Alternative
  4. gegebenenfalls Eskalations- oder Antragsweg

Beispiel:

Ich kann die Mehrfaktor-Authentifizierung nicht dauerhaft deaktivieren, da sie für administrative Konten verbindlich ist. Ich kann jedoch prüfen, ob ein zugelassenes alternatives Authentifizierungsverfahren für Ihr Gerät eingerichtet werden kann.

„Nein“ verständlich erklären

Ungeeignet:

Das geht nicht. Prozess ist Prozess.

Besser:

Der direkte Zugriff kann nicht eingerichtet werden, weil dadurch personenbezogene Daten ohne die erforderliche Berechtigung sichtbar wären. Möglich ist stattdessen ein Antrag auf die freigegebene Leseberechtigung. Ich sende Ihnen das passende Serviceangebot.

Kommunikation bei Fehlern der Serviceorganisation

Hat die Serviceorganisation einen Fehler verursacht, sollte sie:

Beispiel:

Bei der gestrigen Änderung wurde eine benötigte Berechtigungsgruppe nicht übernommen. Dadurch konnten zwölf Benutzer die Anwendung heute Morgen nicht öffnen. Die Gruppe wurde wiederhergestellt. Wir prüfen zusätzlich, warum der Test die fehlende Berechtigung nicht erkannt hat.

Ungeeignet:

Es gab ein kleines technisches Problem.

wenn die tatsächliche Auswirkung erheblich war.

Entschuldigung professionell verwenden

Eine Entschuldigung sollte konkret und angemessen sein.

Geeignet:

Es tut uns leid, dass Sie trotz der zugesagten Rückmeldung keine Statusinformation erhalten haben.

Weniger hilfreich:

Entschuldigung für die Unannehmlichkeiten.

ohne zu benennen, was geschehen ist.

Eine Entschuldigung ersetzt nicht:

Kommunikation bei Major Incidents

Bei einem Major Incident müssen Informationen:

bereitgestellt werden.

Zu klären sind:

Inhalt einer Major-Incident-Meldung

Eine erste Meldung kann enthalten:

Beispiel:

Seit 08:45 Uhr ist die zentrale Anmeldung für mehrere interne Anwendungen gestört. Benutzer können sich teilweise nicht neu anmelden. Bereits aktive Sitzungen sind nach aktuellem Stand nicht betroffen. Die zuständigen Identitäts- und Anwendungsteams untersuchen die Ursache. Bitte ändern Sie Ihr Kennwort nicht. Die nächste Statusmeldung erfolgt spätestens um 09:30 Uhr.

Keine unbestätigten Ursachen veröffentlichen

Ungeeignet:

Der Ausfall wurde durch einen Cyberangriff verursacht.

wenn dies noch nicht bestätigt ist.

Besser:

Die Ursache wird untersucht. Das Informationssicherheitsteam ist vorsorglich einbezogen. Eine bestätigte Sicherheitsauswirkung liegt derzeit noch nicht vor.

Abschlusskommunikation nach einem Major Incident

Eine Abschlussmeldung kann enthalten:

Beispiel:

Der Anmeldeservice ist seit 12:20 Uhr wieder verfügbar. Neue Anmeldungen funktionieren nach aktueller Prüfung. Benutzer mit einer weiterhin angezeigten Fehlermeldung sollen die Anwendung einmal vollständig schließen und erneut öffnen. Die zugrunde liegende Ursache wird noch untersucht. Weitere Erkenntnisse fließen in die nachgelagerte Incident-Überprüfung ein.

Kommunikation bei Sicherheitsvorfällen

Bei möglichen Sicherheitsvorfällen gelten häufig besondere Regeln.

Der Service Desk sollte:

Ungeeignet:

Ihr Konto wurde gehackt.

Besser:

Es gibt Hinweise auf eine möglicherweise unberechtigte Anmeldung. Das Sicherheitsteam prüft den Vorgang. Bitte verwenden Sie das betroffene Konto bis zur weiteren Rückmeldung nicht.

Die genaue Kommunikation richtet sich nach dem Sicherheitsverfahren der Organisation.

Datenschutz in der Kommunikation

Kommunikation kann personenbezogene oder vertrauliche Informationen enthalten.

Zu vermeiden sind:

Vor dem Versand sollte geprüft werden:

Adressaten und Verteiler prüfen

Besonders bei größeren Störungen kann eine falsche Empfängerliste:

Vor dem Versand:

Barrierearme Kommunikation

Professionelle Kommunikation berücksichtigt unterschiedliche Fähigkeiten und Voraussetzungen.

Mögliche Maßnahmen:

Ein Benutzer darf nicht als schwierig bewertet werden, weil er:

Mehrsprachige Kommunikation

Bei mehrsprachigen Benutzern sollte geklärt sein:

Automatische Übersetzung kann unterstützen, muss aber bei wichtigen Inhalten kontrolliert werden.

Besonders kritisch sind:

Kulturelle Unterschiede

Kommunikationsstile können sich unterscheiden hinsichtlich:

Professioneller Umgang bedeutet:

Es dürfen keine Annahmen über Fähigkeiten oder Verhalten allein aufgrund von:

getroffen werden.

Interne Kommunikation zwischen Supportgruppen

Benutzerkommunikation kann nur zuverlässig sein, wenn auch die interne Kommunikation funktioniert.

Eine interne Übergabe sollte enthalten:

Ungeeignet:

Bitte übernehmen.

Besser:

Seit 10:05 Uhr können alle zwölf Benutzer am Standort Süd keine Verbindung zum Warenwirtschaftssystem herstellen. DNS und allgemeine Internetverbindung funktionieren. Der Zugriff auf TCP-Port 443 der Zieladresse schlägt nur vom Standort Süd fehl. Der Standort-Router wurde nicht neu gestartet. Benötigt wird die Prüfung von Standorttunnel und Firewall. Nächste Benutzerinformation ist für 11:00 Uhr angekündigt.

Kommunikation bei Schicht- oder Teamübergaben

Eine Übergabe sollte nicht nur den Ticketstatus nennen.

Hilfreich sind:

Beispiel:

Der Service ist teilweise wiederhergestellt. Neue Benutzer können sich anmelden, bestehende Sitzungen zeigen vereinzelt Fehler. Der Hersteller prüft noch die Protokolle. Keine weitere Konfigurationsänderung ohne Abstimmung mit der Incident-Koordination. Nächstes Benutzerupdate um 18:00 Uhr.

Kommunikationsverantwortung klären

Bei mehreren beteiligten Teams sollte festgelegt sein:

Andernfalls entstehen möglicherweise:

Vorlagen und Textbausteine

Vorlagen können Kommunikation:

Sie dürfen jedoch nicht unreflektiert verwendet werden.

Eine Vorlage sollte angepasst werden an:

Ungeeigneter Textbaustein:

Ihr Anliegen wurde erfolgreich gelöst.

wenn der Benutzer die Funktion noch nicht bestätigt hat.

Besser:

Die technische Funktion wurde wiederhergestellt. Bitte prüfen Sie, ob Sie den zuvor fehlgeschlagenen Arbeitsschritt jetzt vollständig durchführen können.

Beispiel: Eingangsbestätigung

Ihre Meldung wurde unter der Vorgangsnummer 4711 erfasst.

Betroffener Service: zentrale Dateiablage
Gemeldete Auswirkung: Dateien lassen sich nicht öffnen

Der Service Desk prüft zunächst, ob eine allgemeine Störung vorliegt. Die nächste Rückmeldung erfolgt innerhalb der vereinbarten Servicezeit.

Beispiel: Rückfrage

Für die weitere Analyse benötigen wir noch folgende Information:

Bitte senden Sie keine Kennwörter oder vollständigen vertraulichen Dokumente.

Beispiel: Weiterleitung

Die erste Prüfung zeigt, dass zusätzliche Analyse durch das Netzwerkteam erforderlich ist.

Der Vorgang wurde mit den bisherigen Prüfergebnissen weitergegeben. Der Service Desk bleibt Ihr Kontaktpunkt. Die nächste Statusmeldung erfolgt spätestens um 14:00 Uhr.

Beispiel: Verzögerung

Die Bearbeitung dauert länger als zunächst erwartet, weil zusätzliche Protokolldaten des Herstellers benötigt werden.

Die Störung wird weiterhin aktiv untersucht. Die bisherige Zwischenlösung bleibt gültig. Die nächste Aktualisierung erfolgt spätestens um 16:30 Uhr.

Beispiel: Wiederherstellung

Der Zugriff auf die Anwendung ist wiederhergestellt.

Bitte melden Sie sich erneut an und führen Sie den zuvor fehlgeschlagenen Arbeitsschritt vollständig durch. Teilen Sie uns anschließend kurz mit, ob die Funktion wieder wie erwartet arbeitet.

Beispiel: Abschluss

Sie haben bestätigt, dass die Anwendung wieder vollständig nutzbar ist.

Ursache war eine fehlerhafte Berechtigungszuordnung. Diese wurde korrigiert. Der Vorgang 4711 wird abgeschlossen.

Die wiederkehrende Ursache wird zusätzlich durch Problem Management untersucht.

Beispiel: Ablehnung mit Alternative

Die gewünschte lokale Administratorberechtigung kann nicht dauerhaft freigegeben werden, da sie nicht dem Sicherheitsstandard für Arbeitsplatzgeräte entspricht.

Für die Installation der benötigten Anwendung steht ein genehmigtes Serviceangebot zur Verfügung. Ich habe Ihnen den entsprechenden Antrag verlinkt.

KI-gestützte Kommunikation

KI kann unterstützen bei:

Mögliche Vorteile:

Mögliche Risiken:

KI-Ausgaben prüfen

Vor dem Versand einer KI-gestützten Antwort sollte geprüft werden:

Sicherheitsrelevant

KI darf keine unbekannten technischen Schritte oder produktiven Änderungen allein aufgrund plausibel klingender Formulierungen veranlassen.

Automatisierte Nachrichten menschlich und präzise gestalten

Ungeeignet:

Ihr Ticket wurde aktualisiert.

Besser:

Das Anwendungsteam hat die Analyse übernommen. Für die weitere Prüfung werden derzeit die Anmeldeprotokolle ausgewertet. Sie müssen aktuell nichts weiter tun. Die nächste Statusmeldung erfolgt spätestens um 12:00 Uhr.

Automatisierung darf nicht nur interne Statuscodes an Benutzer weitergeben.

Kommunikationsqualität messen

Mögliche Informationen:

Messgröße Mögliche Aussage
Benutzerzufriedenheit allgemeine Wahrnehmung des Kontakts
wahrgenommener Aufwand wie aufwendig der Kontakt für den Benutzer war
Verständlichkeit ob Informationen und Anweisungen verstanden wurden
Vertrauen ob Benutzer Aussagen und Zusagen als verlässlich erleben
Wiederholungskontakte mögliche Hinweise auf fehlende Information oder Lösung
eingehaltene Statuszusagen Zuverlässigkeit der Kommunikation
Anzahl notwendiger Rückfragen mögliche Hinweise auf unvollständige Erfassung
Beschwerden Hinweise auf wiederkehrende Kommunikationsprobleme
Kanalwechsel möglicher Hinweis auf ungeeigneten Erstkanal
Wiedereröffnungsquote möglicher Hinweis auf voreiligen Abschluss
Benutzerbestätigung ob das gewünschte Ergebnis tatsächlich erreicht wurde

Eine einzelne Zufriedenheitszahl reicht nicht aus.

Feedback richtig einordnen

Eine negative Bewertung kann sich beziehen auf:

Vor Schlussfolgerungen sollte geprüft werden:

Mitarbeiter sollten nicht allein anhand einzelner emotionaler Bewertungen beurteilt werden.

Kommunikationsreviews

Eine Organisation kann ausgewählte Kontakte prüfen auf:

Die Prüfung sollte der:

dienen.

Sie sollte nicht ausschließlich als Überwachung oder Fehlersuche wahrgenommen werden.

Gesundheit und emotionale Belastung der Mitarbeiter

Service-Desk-Mitarbeiter bearbeiten möglicherweise:

Organisationen sollten berücksichtigen:

Merke

Empathische Kommunikation ist qualifizierte Arbeit.

Sie benötigt Fähigkeiten, Unterstützung und ausreichende Arbeitsbedingungen.

Continual Improvement der Kommunikation

Verbesserungsmöglichkeiten können entstehen durch:

Mögliche Verbesserungen:

Praxisbeispiel: keine Anmeldung möglich

Benutzer:

Ich kann mich nicht anmelden und brauche die Anwendung sofort.

Ungeeignete Antwort:

Haben Sie Ihr Kennwort falsch eingegeben?

Bessere Antwort:

Ich verstehe, dass Sie die Anwendung gerade benötigen. Ich kläre zunächst, ob Ihr Konto oder der gesamte Anmeldedienst betroffen ist. Welche Meldung wird angezeigt und können sich Kollegen in derselben Anwendung anmelden?

Nach der Prüfung:

Weitere Benutzer sind ebenfalls betroffen. Ihr Kennwort ist deshalb wahrscheinlich nicht die Ursache. Der Identitätsdienst wird bereits untersucht. Bitte ändern Sie Ihr Kennwort nicht erneut. Die nächste Statusmeldung erfolgt um 10:30 Uhr.

Praxisbeispiel: verlorene Datei

Benutzer:

Meine Datei ist weg. Da waren zwei Tage Arbeit drin.

Ungeeignet:

Sie hätten regelmäßig speichern müssen.

Bessere Antwort:

Ich verstehe, dass der mögliche Verlust sehr belastend ist. Bitte speichern oder überschreiben Sie an diesem Speicherort zunächst nichts weiter. Ich prüfe, ob eine frühere Version oder Sicherung verfügbar ist. Wann und unter welchem Namen wurde die Datei zuletzt gespeichert?

Wichtig:

Praxisbeispiel: angekündigter Rückruf wurde vergessen

Benutzer:

Mir wurde gestern ein Rückruf versprochen. Es hat sich niemand gemeldet.

Geeignete Antwort:

Das hätte nicht passieren dürfen. Der zugesagte Rückruf wurde nicht durchgeführt. Ich prüfe jetzt den aktuellen Bearbeitungsstand und übernehme die Koordination. Sie erhalten spätestens um 11:00 Uhr eine Rückmeldung von mir, auch wenn die technische Analyse dann noch läuft.

Zusätzlich sollte intern geprüft werden:

Praxisbeispiel: Sicherheitskontrolle wird unter Zeitdruck abgelehnt

Benutzer:

Ich bin in fünf Minuten im Termin. Setzen Sie das Kennwort einfach zurück.

Geeignete Antwort:

Ich verstehe den Zeitdruck. Die Identitätsprüfung kann ich trotzdem nicht überspringen, weil dadurch ein fremdes Konto übernommen werden könnte. Wir führen jetzt das vorgesehene schnelle Prüfverfahren durch. Danach kann ich die Zurücksetzung sofort veranlassen.

Praxisbeispiel: technisches Team benötigt mehr Zeit

Statusmeldung:

Die Anwendung ist weiterhin nicht verfügbar. Das Team hat die Datenbankverbindung als Fehlerbereich eingegrenzt, aber die genaue Ursache ist noch nicht bestätigt. Eine Wiederherstellungsschätzung liegt deshalb noch nicht vor. Die alternative Anwendung kann weiterhin verwendet werden. Nächste Statusmeldung: 15:30 Uhr.

Diese Meldung:

Praxisbeispiel: Ticket wurde voreilig geschlossen

Benutzer:

Das Ticket ist geschlossen, aber der Fehler ist noch da.

Geeignete Antwort:

Danke für den Hinweis. Der Vorgang wurde zu früh geschlossen. Ich öffne ihn erneut und dokumentiere, dass die technische Maßnahme das Benutzerproblem nicht gelöst hat. Wir prüfen jetzt den vollständigen Arbeitsschritt noch einmal.

Anschließend sollte untersucht werden:

Typische Kommunikationsfehler

Fehler 1: Zu früh eine Lösung vermuten

Der Benutzer wird in eine falsche Diagnoserichtung gelenkt.

Fehler 2: Fachbegriffe ohne Erklärung verwenden

Der Benutzer versteht weder Situation noch nächsten Schritt.

Fehler 3: Auswirkungen verharmlosen

Die technische Störung wirkt klein, blockiert aber einen wichtigen Arbeitsprozess.

Fehler 4: Unbelegte Zeitversprechen geben

Vertrauen sinkt, sobald die Zusage nicht eingehalten wird.

Fehler 5: Nur bei neuen Erkenntnissen informieren

Benutzer bleiben lange ohne Status.

Fehler 6: „Ich gebe es weiter“ ohne Verantwortung

Nächster Schritt, Kommunikationsweg und Zuständigkeit bleiben unklar.

Fehler 7: Benutzer oder andere Teams beschuldigen

Zusammenarbeit und Vertrauen werden beschädigt.

Fehler 8: Empathie mit Zustimmung verwechseln

Prioritäts-, Sicherheits- oder Genehmigungsregeln werden unnötig aufgegeben.

Fehler 9: Standardtexte unverändert senden

Die Nachricht passt nicht zur tatsächlichen Situation.

Fehler 10: Technische Wiederherstellung mit Benutzer-Outcome verwechseln

Ticket wird geschlossen, obwohl die Tätigkeit weiterhin nicht möglich ist.

Fehler 11: Verärgerte Benutzer persönlich angreifen

Die Situation eskaliert weiter.

Fehler 12: Beleidigungen unbegrenzt akzeptieren

Mitarbeiterschutz und professionelle Grenzen fehlen.

Fehler 13: Sensible Informationen im falschen Kanal teilen

Datenschutz- oder Sicherheitsrisiken entstehen.

Fehler 14: Widersprüchliche Meldungen mehrerer Teams

Es fehlt eine geklärte Kommunikationsverantwortung.

Fehler 15: KI-Entwürfe ungeprüft versenden

Falsche Aussagen oder unangemessene Formulierungen erreichen Benutzer.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker kommunizieren nicht nur innerhalb des Service Desk.

Sie kommunizieren ebenfalls bei:

Eine gute technische Rückmeldung sollte beantworten:

Ungeeignete technische Rückmeldung:

Server läuft wieder.

Besser:

Der Anwendungsdienst wurde um 14:20 Uhr wiederhergestellt. Technische Funktionsprüfungen sind erfolgreich. Zwei Testbenutzer konnten sich anmelden und Datensätze speichern. Der Service wird bis 16:00 Uhr verstärkt überwacht. Die Ursache wird noch durch Problem Management untersucht.

30-Sekunden-Prüfung einer Benutzerkommunikation

  1. Zielgruppe: Mit wem kommuniziere ich?
  2. Anliegen: Was benötigt die Person tatsächlich?
  3. Auswirkung: Welche Arbeit oder welches Outcome ist betroffen?
  4. Verständlichkeit: Ist die Sprache für die Zielgruppe geeignet?
  5. Fakten: Welche Aussagen sind bestätigt?
  6. Unsicherheit: Was ist noch nicht bekannt?
  7. Handlung: Was geschieht als Nächstes?
  8. Verantwortung: Wer übernimmt die nächste Aufgabe?
  9. Zeit: Wann folgt die nächste Information?
  10. Sicherheit: Darf der Inhalt über diesen Kanal geteilt werden?
  11. Ergebnis: Wie wird das Outcome bestätigt?
  12. Respekt: Ist die Formulierung sachlich und professionell?

Checkliste für ein professionelles Gespräch

Checkliste für schriftliche Nachrichten

Checkliste für Statusmeldungen

Checkliste für schwierige Gespräche

Checkliste vor dem Abschluss eines Vorgangs

Checkliste für KI-gestützte Kommunikation

Schnellreferenz für Formulierungen

Situation Geeignete Formulierung
Auswirkung anerkennen Ich verstehe, dass die Störung Ihren Arbeitsablauf gerade vollständig blockiert.
Verständnis prüfen Ich fasse kurz zusammen, damit ich nichts übersehen habe.
Ursache unbekannt Die genaue Ursache ist noch nicht bestätigt.
keine Lösungszeit bekannt Eine verlässliche Wiederherstellungszeit liegt noch nicht vor.
nächste Rückmeldung Sie erhalten spätestens um 14:00 Uhr eine weitere Statusmeldung.
Weiterleitung Ich binde das Netzwerkteam mit den bisherigen Prüfergebnissen ein.
Verantwortung behalten Der Service Desk bleibt Ihr Kontaktpunkt und informiert Sie weiter.
Sicherheitsregel erklären Die Identitätsprüfung kann ich aus Sicherheitsgründen nicht überspringen.
Alternative anbieten Als Zwischenlösung können Sie derzeit Arbeitsplatz 4 verwenden.
Ergebnis prüfen Können Sie den zuvor fehlgeschlagenen Arbeitsschritt jetzt vollständig durchführen?
Fehler eingestehen Der zugesagte Rückruf ist nicht erfolgt. Ich übernehme jetzt die weitere Koordination.
respektvolle Grenze Ich bearbeite Ihr Anliegen gern weiter, benötige dafür aber ein Gespräch ohne Beleidigungen.

Zusammenfassende Darstellung

Benutzer schildert ein Anliegen
↓
aufmerksam zuhören und Auswirkung verstehen
↓
gezielt nachfragen
↓
das Verstandene zusammenfassen
↓
Situation fachlich und verständlich einordnen
↓
nächsten Schritt und Verantwortung erklären
↓
realistische Erwartungen und Statuszeitpunkt vereinbaren
↓
regelmäßig, ehrlich und zielgruppengerecht informieren
↓
technisches Ergebnis und Benutzer-Outcome prüfen
↓
Kontakt professionell abschließen
↓
Feedback, Beschwerden und Kommunikationsprobleme verbessern

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Offiziell bestätigter Stand

Die offiziellen ITIL- und PeopleCert-Quellen bestätigen:

Einordnung

Die auf dieser Seite dargestellten:

sind herstellerneutrale redaktionelle Empfehlungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Skripte und keine für jede Organisation verbindlichen Kommunikationsabläufe dar.

Die konkrete Kommunikation muss angepasst werden an:

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle öffentlich zugängliche ITIL-4-Service-Desk-Guidance
Fachlicher Stand: August 2026

3. Service Desk, Support und operative Servicearbeit

3.4 Tickets vollständig erfassen und kategorisieren

Kurz erklärt

Ein Ticket dokumentiert einen Kontakt, eine Störung, eine Anfrage oder eine andere zu bearbeitende Arbeitseinheit.

Ein gutes Ticket macht nachvollziehbar:

Die Kategorisierung ordnet den Vorgang so ein, dass:

werden können.

ITIL schreibt kein universelles Ticketformular, kein verpflichtendes Kategoriemodell und keinen für alle Organisationen identischen Ticketstatus vor.

Felder, Kategorien und Arbeitsabläufe müssen zu den Services, Wertströmen, Risiken und Informationsbedürfnissen der jeweiligen Organisation passen.

Warum eine gute Ticketqualität wichtig ist

Ein Ticket ist nicht nur eine technische Notiz.

Es unterstützt unter anderem:

Unvollständige oder unklare Tickets führen häufig zu:

Beispiel für ein unzureichendes Ticket:

Drucker geht nicht.

Daraus ist nicht erkennbar:

Eine bessere Erfassung könnte lauten:

Seit etwa 08:20 Uhr können alle vier Arbeitsplätze im Warenausgang keine Versandetiketten über Drucker WD-ET-01 ausgeben. Normale Bürodrucker funktionieren. Am Etikettendrucker wird „Druckauftrag nicht verfügbar“ angezeigt. Der Drucker ist eingeschaltet und im Netzwerk erreichbar. Die Druckwarteschlange enthält zwölf offene Aufträge. Der Versandprozess ist derzeit unterbrochen und es besteht kein zugelassener Ersatzdrucker.

Merke

Je besser ein Ticket den tatsächlichen Arbeits- und Servicekontext beschreibt, desto weniger muss die nächste bearbeitende Person erneut erfragen.

Ticket ist ein praktischer Sammelbegriff

Der Begriff Ticket wird in vielen ITSM-Werkzeugen als allgemeine Bezeichnung für einen dokumentierten Vorgang verwendet.

Je nach Inhalt kann ein Ticket beispielsweise repräsentieren:

Diese Vorgangsarten besitzen unterschiedliche Zwecke.

Vorgangsart Typischer Zweck
Kontakt Interaktion mit einem Benutzer oder Stakeholder dokumentieren
Incident negative Serviceauswirkung behandeln und Service wiederherstellen
Service Request vorgesehene Benutzeranfrage erfüllen
Problem Ursache oder mögliche Ursache von Incidents untersuchen
Change eine Änderung bewerten, autorisieren und kontrolliert steuern
Security Incident mögliches oder bestätigtes Sicherheitsereignis behandeln
Aufgabe abgegrenzte Tätigkeit innerhalb eines größeren Vorgangs durchführen
Lieferantenfall externe Unterstützung oder vertragliche Leistung anfordern

Wichtig

Nicht jedes Ticket ist ein Incident.

Nicht jede Benutzerfrage ist ein Service Request.

Die richtige Vorgangsart beeinflusst Bearbeitung, Verantwortung, Messung und Abschlusskriterien.

Kontakt, Ticket und zugrunde liegender Vorgang unterscheiden

Ein Benutzerkontakt und ein Ticket sind nicht immer identisch.

Beispiel:

  1. Ein Benutzer meldet telefonisch einen Ausfall.
  2. Der Service Desk erstellt ein Incident-Ticket.
  3. Drei weitere Benutzer melden dasselbe Problem per Chat.
  4. Diese Kontakte werden mit dem bereits bestehenden Incident verknüpft.
  5. Ein technisches Team erhält eine zugehörige Diagnoseaufgabe.
  6. Ein Provider erhält einen verknüpften Lieferantenfall.
  7. Nach der Wiederherstellung wird ein Problem Record für die Ursachenanalyse eröffnet.

Es bestehen damit:

Merke

Nicht jede neue Meldung benötigt einen vollständig unabhängigen Incident.

Mehrere Kontakte können dieselbe zugrunde liegende Störung betreffen.

Ziel der Ticket-Erfassung

Die Erfassung soll ausreichende Informationen bereitstellen, damit die Organisation:

Das Ziel ist nicht:

Grundsatz

Es sollen so viele Informationen wie notwendig und so wenige wie möglich erfasst werden.

Ein mögliches Mindestset an Ticketinformationen

Abhängig von Vorgangsart und Organisation können folgende Informationen sinnvoll sein:

Information Zweck
Vorgangsnummer eindeutige Referenz
Erstellungszeitpunkt zeitliche Nachvollziehbarkeit
Meldekanal Herkunft und Kommunikationskontext
meldende Person Kontakt und Rückfragen
betroffene Person oder Gruppe tatsächliche Auswirkung bestimmen
betroffener Service serviceorientierte Einordnung
kurzer Titel schnelle verständliche Übersicht
Beschreibung Situation und Beobachtung dokumentieren
Beginn zeitliche Einordnung der Beeinträchtigung
Auswirkung Umfang und Geschäftsbezug
Dringlichkeit zeitliche Bedeutung
Priorität organisatorisch bestimmte Bearbeitungsreihenfolge
Kategorie Zuordnung und Auswertung
aktueller Status Bearbeitungsstand
verantwortliche Rolle oder Gruppe aktuelles Ownership
bisherige Maßnahmen doppelte Arbeit vermeiden
Ergebnisse der Maßnahmen Diagnose nachvollziehen
nächster Schritt Bearbeitung fortsetzen
Kommunikationszeitpunkt Benutzerinformation sicherstellen
Lösung oder Erfüllung Ergebnis dokumentieren
Abschlussbestätigung tatsächliches Outcome prüfen
verknüpfte Vorgänge Zusammenhänge sichtbar machen

Nicht jede Vorgangsart benötigt alle Felder.

Ein einfacher Informationskontakt benötigt möglicherweise deutlich weniger Daten als ein kritischer Incident.

Meldende Person und betroffener Benutzer unterscheiden

Die Person, die ein Ticket meldet, ist nicht immer selbst betroffen.

Beispiele:

Deshalb können getrennte Felder sinnvoll sein für:

Typischer Fehler

Das Ticket wird automatisch der meldenden Person zugeordnet, obwohl eine andere Person oder ein ganzer Bereich betroffen ist.

Der betroffene Service gehört in den Mittelpunkt

Eine serviceorientierte Erfassung fragt nicht nur:

Welche technische Komponente ist defekt?

Sondern zuerst:

Welcher Service oder welche Arbeitsfähigkeit ist beeinträchtigt?

Beispiel:

Technische Komponente:

Datenbankserver DB-02

Betroffener Service:

Warenwirtschaftssystem

Geschäftliche Auswirkung:

Lager kann keine Warenausgänge buchen.

Die Komponente kann für Diagnose und technische Zuordnung wichtig sein.

Der Service ist jedoch entscheidend für:

Service und Configuration Item unterscheiden

Information Beispiel
betroffener Service zentraler Dateiservice
betroffene Anwendung Dokumentenmanagement
Configuration Item Fileserver FS-03
Asset physischer Server mit Inventarnummer
Standort Berlin-Nord
Benutzergruppe Buchhaltung

Ein Incident kann mehrere Configuration Items betreffen.

Ein einzelnes Configuration Item kann mehrere Services unterstützen.

Deshalb sollte das Ticket nicht ausschließlich anhand der vermuteten Komponente eingeordnet werden.

Einen guten Tickettitel formulieren

Der Titel sollte die Situation kurz und eindeutig zusammenfassen.

Ungeeignete Titel:

Bessere Titel:

Ein guter Titel enthält häufig:

Praxistipp

Der Titel sollte auch für eine Person verständlich sein, die das Ticket nicht selbst erfasst hat.

Symptom statt vermuteter Ursache dokumentieren

Zu Beginn eines Incidents ist die tatsächliche Ursache häufig unbekannt.

Ungeeignet:

Firewall blockiert Anwendung.

wenn dies nur vermutet wird.

Besser:

Anwendung ist vom Standort Süd nicht über HTTPS erreichbar. Andere Standorte sind nach aktueller Prüfung nicht betroffen. Eine Firewall-Regel ist eine mögliche, aber noch nicht bestätigte Ursache.

Die Dokumentation sollte unterscheiden zwischen:

Art Beispiel
Beobachtung Benutzer erhält „Verbindung nicht möglich“
Messergebnis TCP-Verbindung zu Port 443 schlägt fehl
Vermutung mögliche Blockierung durch Firewall
bestätigte Ursache Regel FW-182 wurde beim letzten Change nicht übernommen

Merke

Eine früh eingetragene Vermutung darf nicht unbemerkt zur scheinbar bestätigten Tatsache werden.

Fakten und Bewertungen trennen

Ungeeignet:

Benutzer hat wieder die falsche Anwendung benutzt.

Besser:

Der Benutzer öffnete die bisher verwendete Anwendungsversion 4.2. Seit dem Change vom 1. August ist Version 5.0 erforderlich. Die bisherige Verknüpfung auf dem Desktop wurde nicht aktualisiert.

Ungeeignet:

Netzwerk ist instabil.

Besser:

Zwischen 09:10 Uhr und 09:25 Uhr gingen 18 von 100 ICMP-Paketen verloren. Zwei VoIP-Gespräche wurden in diesem Zeitraum unterbrochen.

Sachliche Dokumentation verbessert:

Die ursprünglichen Benutzerangaben erhalten

Die Beschreibung des Benutzers kann wichtige Hinweise enthalten.

Beispiel:

„Beim Speichern erscheint immer die Meldung, dass der Datensatz bereits bearbeitet wird.“

Diese ursprüngliche Beobachtung sollte nicht vollständig durch eine technische Interpretation ersetzt werden.

Eine gute Dokumentation kann enthalten:

Dadurch bleibt nachvollziehbar:

Zeitangaben vollständig erfassen

Zeitinformationen können für Analyse und Korrelation entscheidend sein.

Hilfreiche Angaben:

Beispiel:

Letzter erfolgreicher Zugriff: 08:47 Uhr
Erste Fehlermeldung: 08:52 Uhr
Meldung beim Service Desk: 09:03 Uhr
letzter relevanter Change: 07:30 Uhr

Diese Informationen können mit:

verglichen werden.

Typischer Fehler

Im Ticket steht nur das Erstellungsdatum. Der tatsächliche Beginn der Beeinträchtigung bleibt unbekannt.

Auswirkungen vollständig beschreiben

Die Auswirkungen bestimmen, was der Incident für Benutzer und Organisation bedeutet.

Zu erfassen sind möglicherweise:

Unzureichend:

Ein Benutzer betroffen.

Besser:

Betroffen ist der einzige Arbeitsplatz, über den die Produktionsfreigabe durchgeführt werden kann. Ohne Freigabe steht die Fertigungslinie ab 10:00 Uhr still. Ein Ersatzarbeitsplatz ist nicht verfügbar.

Das Beispiel zeigt:

Die reine Benutzeranzahl beschreibt nicht immer die tatsächliche Auswirkung.

Dringlichkeit nicht nur vom Benutzer übernehmen

Benutzer können ihre gewünschte Dringlichkeit mitteilen.

Die Organisation muss sie jedoch anhand festgelegter Kriterien bewerten.

Ein Benutzer kann beispielsweise „sehr dringend“ auswählen, weil:

Das Ticket sollte deshalb unterscheiden zwischen:

Die genaue Bewertung wird auf der Seite 3.5 Auswirkungen, Dringlichkeit und Priorität vertieft.

Die Beschreibung sollte den Normalzustand enthalten

Für die Diagnose ist hilfreich zu wissen:

Beispiel:

Normalerweise wird nach Auswahl von „Auftrag abschließen“ innerhalb weniger Sekunden eine PDF-Rechnung erzeugt. Seit heute 08:30 Uhr bleibt der Ladebildschirm dauerhaft sichtbar. Der Auftrag wird nicht abgeschlossen und es wird keine Fehlermeldung angezeigt.

Diese Beschreibung ist aussagekräftiger als:

Rechnung funktioniert nicht.

Reproduzierbarkeit dokumentieren

Hilfreiche Angaben:

Beispiel:

  1. Anwendung öffnen
  2. Auftrag 4711 auswählen
  3. „PDF exportieren“ anklicken
  4. Anwendung schließt sich ohne Fehlermeldung

Zusätzlich:

Wichtig

Reproduktionsschritte dürfen keine vertraulichen Daten oder unsicheren Handlungen unnötig offenlegen.

Bereits durchgeführte Maßnahmen dokumentieren

Das Ticket sollte zeigen:

Unzureichend:

Neustart gemacht.

Besser:

10:12 Uhr – Anwendungsdienst APP-SVC auf Server APP-02 kontrolliert neu gestartet, nachdem der Prozess nicht mehr auf Health Checks reagierte. Dienst startete erfolgreich. Technischer Health Check ist wieder grün. Benutzeranmeldung schlägt jedoch weiterhin fehl.

Dadurch wird deutlich:

Maßnahme und Ergebnis getrennt dokumentieren

Maßnahme Ergebnis
DNS-Cache geleert Fehler besteht unverändert
Anwendung neu gestartet Anmeldung funktioniert einmalig
anderes Benutzerkonto getestet ebenfalls betroffen
Zugriff über Mobilfunk getestet funktioniert
Firewall-Regel geprüft Regel vorhanden und aktiv
Provider kontaktiert externe Störung bestätigt

Diese Trennung verhindert unklare Notizen wie:

Alles geprüft.

Chronologische Arbeitsnotizen

Eine chronologische Dokumentation unterstützt:

Beispiel:

09:05 Uhr: Incident durch Service Desk erfasst. Fünf Benutzer betroffen.
09:12 Uhr: Allgemeine Statusseite geprüft, keine bekannte Herstellerstörung.
09:18 Uhr: Anwendung von Standort Nord und Süd getestet. Nur Nord betroffen.
09:25 Uhr: Netzwerkteam eingebunden.
09:40 Uhr: Standorttunnel zeigt Paketverlust. Providerfall P-8821 eröffnet.
10:00 Uhr: Benutzerstatus aktualisiert. Nächstes Update 10:30 Uhr.

Arbeitsnotizen sollten nicht nachträglich so verändert werden, dass wesentliche Entscheidungen oder frühere Zustände nicht mehr nachvollziehbar sind.

Korrekturen sollten transparent erfolgen.

Interne und externe Notizen unterscheiden

Viele Ticketsysteme bieten:

Interne Arbeitsnotizen

Können enthalten:

Benutzersichtbare Kommentare

Sollten enthalten:

Sicherheitsrelevant

Interne Notizen sind nicht automatisch für jede vertrauliche Information geeignet.

Zugriffsrechte, Aufbewahrung und Datenklassifizierung müssen berücksichtigt werden.

Kategorisierung

Kategorisierung ordnet einen Vorgang nach festgelegten Merkmalen ein.

Sie kann unterstützen bei:

Eine Kategorie sollte einen konkreten Nutzen besitzen.

Typischer Fehler

Kategorien werden nur deshalb angelegt, weil das Werkzeug beliebig viele Ebenen ermöglicht.

Ein einfaches Kategoriemodell

Eine mögliche Struktur lautet:

Service → Anliegenart → Symptom

Beispiel:

Dateiablage → Incident → Zugriff nicht möglich

Weitere Beispiele:

Die konkrete Struktur wird von der Organisation festgelegt.

Serviceorientierte und technische Kategorien

Serviceorientierte Kategorien

Beispiele:

Vorteile:

Technische Kategorien

Beispiele:

Vorteile:

Beide Perspektiven können kombiniert werden.

Praxistipp

Der Benutzer wählt möglichst den betroffenen Service oder sein Anliegen.

Die technische Einordnung kann während der Bearbeitung ergänzt werden.

Benutzerkategorie und interne Kategorie unterscheiden

Ein Portal sollte nicht zwingend dieselben Kategorien anzeigen wie das interne Ticketsystem.

Benutzerfreundliche Auswahl:

Interne Zuordnung:

Dadurch muss der Benutzer keine interne IT-Struktur kennen.

Mehrere Kategorisierungsdimensionen verwenden

Eine einzige hierarchische Kategorie kann schnell zu groß und unübersichtlich werden.

Alternativ können mehrere getrennte Merkmale verwendet werden.

Dimension Beispiel
Service E-Mail
Vorgangsart Incident
Symptom Versand nicht möglich
technische Domäne Mail Gateway
Standort Berlin
Benutzergruppe Vertrieb
Sicherheitsbezug nein
Ursachencode Zertifikat abgelaufen
Lösungscode Zertifikat erneuert

Vorteile:

Nachteile:

Deshalb sollten nur tatsächlich benötigte Dimensionen verwendet werden.

Symptom-, Ursachen- und Lösungskategorien unterscheiden

Diese Kategorien entstehen zu unterschiedlichen Zeitpunkten.

Kategorie Zeitpunkt Beispiel
Symptomkategorie bei Erfassung Anmeldung nicht möglich
technische Kategorie während Diagnose Identitätsdienst
Ursachenkategorie nach Bestätigung Zertifikat abgelaufen
Lösungskategorie nach Wiederherstellung Zertifikat erneuert

Zu Beginn darf nicht so kategorisiert werden, als wäre die Ursache bereits bekannt.

Typischer Fehler

Das Ticket wird bei der ersten Meldung als „Netzwerkfehler“ kategorisiert und bleibt dort, obwohl später ein abgelaufenes Anwendungstoken als Ursache bestätigt wird.

Kategorien dürfen geändert werden

Eine erste Kategorisierung ist häufig vorläufig.

Während der Bearbeitung können neue Erkenntnisse entstehen.

Eine Kategorie sollte geändert werden, wenn:

Die Änderung sollte:

erfolgen.

Kategorie „Sonstiges“ kontrolliert verwenden

Eine Kategorie wie:

kann notwendig sein.

Sie darf jedoch nicht zur dauerhaften Standardkategorie werden.

Eine hohe Nutzung kann anzeigen:

Praxistipp

Vorgänge in „Sonstiges“ sollten regelmäßig ausgewertet und bei Bedarf neu kategorisiert werden.

Nicht zu viele Kategorieebenen verwenden

Ungeeignetes Beispiel:

IT → Infrastruktur → Netzwerk → Standortnetz → LAN → Switch → Cisco → Modell → Port → Fehler

Eine solche Struktur kann:

sein.

Eine einfachere Kombination kann ausreichen:

Grundsatz

Die Kategorie sollte die Arbeit unterstützen und nicht selbst zu einer zusätzlichen komplizierten Arbeit werden.

Kategorien nicht nach Teams aufbauen

Eine Kategorie wie:

beschreibt organisatorische Zuständigkeit, aber nicht unbedingt den Service oder das Anliegen.

Teams können sich verändern.

Services und Benutzerbedürfnisse bleiben häufig stabiler.

Besser ist:

Vorgangsart richtig bestimmen

Eine wichtige erste Einordnung ist die Unterscheidung zwischen verschiedenen Vorgangsarten.

Incident

Ein Incident liegt vor, wenn eine ungeplante negative Auswirkung auf einen Service behandelt werden muss.

Beispiele:

Service Request

Ein Service Request ist eine vorgesehene Benutzeranfrage.

Beispiele:

Frage oder Informationskontakt

Beispiele:

Eine Frage kann möglicherweise direkt beantwortet werden, ohne einen umfangreichen Request-Wertstrom zu starten.

Sicherheitsmeldung

Beispiele:

Eine Sicherheitsmeldung benötigt möglicherweise:

Beschwerde oder Feedback

Beispiele:

Feedback kann mit einem Incident oder Request verbunden sein, besitzt aber möglicherweise einen eigenen Bearbeitungs- und Verbesserungsweg.

Fehleinordnungen korrigieren

Beispiel:

Ein Benutzer wählt:

Service Request – Kennwort ändern

Während der Erfassung wird erkannt:

Der Vorgang sollte dann möglicherweise als Incident behandelt werden.

Ein anderes Beispiel:

Der Benutzer meldet:

VPN funktioniert nicht.

Die Analyse zeigt:

Dies kann ein Service Request statt eines Incidents sein.

Merke

Die Formulierung oder Portalwahl des Benutzers bestimmt nicht allein die endgültige Vorgangsart.

Duplikate erkennen

Bei größeren Störungen entstehen häufig mehrere Tickets zum selben Incident.

Duplikaterkennung verhindert:

Vor dem Erstellen eines neuen Incidents kann geprüft werden:

Duplikate nicht einfach löschen

Ein Duplikat kann wichtige Informationen enthalten:

Eine sinnvolle Behandlung kann sein:

  1. Kontaktinformationen erhalten
  2. Ticket mit dem Haupt-Incident verknüpfen
  3. betroffene Person oder Gruppe ergänzen
  4. Benutzerkommunikation mit dem Haupt-Incident abstimmen
  5. Duplikat nachvollziehbar schließen oder unterordnen

Parent-, Child- und Sammel-Incidents

Bei einem größeren Incident kann ein Hauptvorgang verwendet werden.

Haupt-Incident

Enthält:

Verknüpfte Meldungen

Enthalten:

Das konkrete Modell hängt vom Ticketsystem und der Organisation ab.

Verknüpfungen zwischen Vorgängen

Tickets können miteinander verbunden werden.

Beispiele:

Mögliche Beziehungstypen:

Wichtig

Verknüpfungen sollten eine erkennbare Bedeutung besitzen.

Eine große Menge unklarer Beziehungen verbessert die Nachvollziehbarkeit nicht.

Status eines Tickets

Ein Status zeigt den aktuellen Bearbeitungszustand.

Mögliche Status sind beispielsweise:

ITIL schreibt kein universelles Statusmodell vor.

Die Organisation muss festlegen:

„Warten“ benötigt einen Grund und nächsten Schritt

Unzureichend:

Status: Warten

Besser:

Warten auf Benutzer – benötigt wird ein Screenshot der genauen Fehlermeldung. Rückmeldung bis 5. August erbeten. Falls keine Antwort erfolgt, wird am 6. August ein weiterer Kontaktversuch durchgeführt.

Oder:

Warten auf Lieferant – Providerfall P-8821 wurde um 10:40 Uhr eröffnet. Nächste vertragliche Rückmeldung wird bis 12:40 Uhr erwartet. Interner Ansprechpartner bleibt Network Operations.

Typischer Fehler

Ein Ticket wird auf „Warten“ gesetzt, ohne dass erkennbar ist, worauf gewartet wird und wer den Vorgang wieder aufnimmt.

Gelöst und abgeschlossen unterscheiden

Eine Organisation kann zwischen:

unterscheiden.

Gelöst

Abgeschlossen

Dieses Modell ist möglich, aber nicht verpflichtend.

Automatischer Abschluss

Ein Ticket kann nach einer festgelegten Frist automatisch geschlossen werden.

Dabei sollte berücksichtigt werden:

Automatischer Abschluss darf nicht nur dazu dienen, Kennzahlen zu verbessern.

Ownership und Zuweisung

Ein Ticket sollte jederzeit eine erkennbare Verantwortung besitzen.

Mögliche Felder:

Eine Gruppe allein reicht möglicherweise nicht aus, wenn:

Merke

„Zugewiesen“ bedeutet nicht automatisch „wird bearbeitet“.

Weiterleitung benötigt vollständige Informationen

Vor einer Weiterleitung sollte geprüft werden:

Ungeeignete Weiterleitung:

Bitte prüfen.

Besser:

Alle Benutzer am Standort Nord können seit 09:15 Uhr den zentralen Dateiservice nicht erreichen. DNS-Auflösung und lokale Netzwerkverbindung funktionieren. Der Zugriff auf TCP-Port 445 schlägt fehl. Standort Süd ist nicht betroffen. Benötigt wird die Prüfung des Standorttunnels und der Firewall. Nächste Benutzerstatusmeldung wurde für 10:30 Uhr angekündigt.

Ticket-Pingpong erkennen

Ticket-Pingpong entsteht, wenn ein Vorgang mehrfach zwischen Gruppen weitergeleitet wird.

Mögliche Ursachen:

Geeignete Maßnahmen:

Anhänge, Screenshots und Protokolle

Anhänge können die Diagnose unterstützen.

Beispiele:

Vor der Speicherung sollte geprüft werden:

Screenshots richtig verwenden

Ein Screenshot sollte möglichst zeigen:

Er sollte möglichst nicht zeigen:

Praxistipp

Fordere möglichst nur den benötigten Bildausschnitt an und erkläre, welche sensiblen Inhalte vorher geschlossen oder entfernt werden sollen.

Protokolldaten sicher behandeln

Logs können enthalten:

Sie sollten:

werden.

Kennwörter und Zugangsdaten gehören nicht ins Ticket

Nicht gespeichert werden sollten insbesondere:

Erhält der Service Desk solche Informationen, müssen die Sicherheitsverfahren der Organisation angewendet werden.

Mögliche Maßnahmen:

Datenschutz und Datenminimierung

Ein Ticket darf nur Informationen enthalten, die für einen legitimen Zweck benötigt werden.

Zu prüfen sind:

Ungeeignet:

Vollständige Krankheitsdiagnose eines Mitarbeiters im allgemeinen IT-Ticket.

Ausreichend kann je nach Situation sein:

Benutzer benötigt aufgrund einer genehmigten Arbeitsplatzanpassung eine alternative Eingabemöglichkeit.

Die verbindlichen Regeln ergeben sich aus den Datenschutz- und Sicherheitsvorgaben der Organisation.

Besondere Behandlung von Sicherheitsmeldungen

Sicherheitsbezogene Tickets können besondere Anforderungen besitzen.

Beispiele:

Ein allgemeiner Service-Desk-Mitarbeiter sollte wissen:

Ticket-Erfassung bei einem möglichen Major Incident

Bei einem möglichen Major Incident sind besonders wichtig:

Ein kurzer Erstbericht darf zunächst unvollständig sein, wenn schnelles Handeln notwendig ist.

Die Informationen müssen anschließend kontrolliert ergänzt werden.

Grundsatz

Schnelle Erfassung und ausreichende Qualität müssen ausbalanciert werden.

Ein kritischer Incident darf nicht wegen eines umfangreichen Pflichtformulars unnötig verzögert werden.

Pflichtfelder

Pflichtfelder können Informationsqualität verbessern.

Sie können jedoch auch:

Ein Feld sollte verpflichtend sein, wenn die Information:

Ungeeignetes Pflichtfeld bei der Ersterfassung:

bestätigte technische Ursache

Die Ursache ist zu diesem Zeitpunkt häufig noch unbekannt.

Besser:

beobachtetes Symptom

Dynamische Formulare

Dynamische Formulare zeigen nur Felder an, die zur gewählten Situation passen.

Beispiel:

Auswahl:

Verdächtige E-Mail

Zusätzliche Felder:

Auswahl:

Software anfordern

Zusätzliche Felder:

Dadurch können Formulare kürzer und verständlicher werden.

Vorlagen und Ticketmodelle

Für häufige Situationen können Vorlagen verwendet werden.

Beispiele:

Eine Vorlage kann enthalten:

Vorlagen müssen regelmäßig geprüft werden.

Eine veraltete Vorlage kann falsche Diagnose oder unnötige Schritte fördern.

Automatisierte Erfassung

Tickets können automatisch entstehen durch:

Bei automatischer Erfassung sollte geklärt sein:

Merke

Automatisch erzeugt bedeutet nicht automatisch richtig kategorisiert oder priorisiert.

KI-gestützte Kategorisierung

KI kann Vorschläge erzeugen für:

Mögliche Vorteile:

Mögliche Risiken:

KI-Ausgaben müssen überprüfbar bleiben

Zu klären ist:

Bei kritischen oder sicherheitsrelevanten Vorgängen sollte eine ungeprüfte vollautomatische Einordnung vermieden werden.

Kategorien regelmäßig pflegen

Ein Kategoriemodell ist nicht dauerhaft unverändert geeignet.

Änderungen entstehen durch:

Regelmäßig zu prüfen sind:

Kategorisierung und Reporting

Kategorien ermöglichen Auswertungen wie:

Die Aussagekraft hängt von der Datenqualität ab.

Unzuverlässige Kategorien erzeugen unzuverlässige Berichte.

Grundsatz

Schlechte Eingangsdaten werden durch ein modernes Dashboard nicht automatisch zu guten Entscheidungsinformationen.

Keine falschen Anreize durch Kategorien

Mitarbeiter können Kategorien so wählen, dass:

Beispiele:

Governance und Qualitätskontrollen müssen solche Fehlanreize berücksichtigen.

Ticketqualität messen

Mögliche Qualitätsmerkmale:

Eine reine Vollständigkeitsquote reicht nicht aus.

Ein ausgefülltes Feld kann trotzdem:

sein.

Qualitätsprüfung ohne unnötige Bürokratie

Mögliche Verfahren:

Die Qualitätsprüfung sollte vor allem:

unterstützen.

Sie sollte nicht ausschließlich zur persönlichen Fehlerbewertung verwendet werden.

Praxisbeispiel: unvollständiges Incident-Ticket

Ursprüngliches Ticket

Titel: Outlook geht nicht
Kategorie: Sonstiges
Priorität: Hoch
Beschreibung: Bitte schnell lösen.

Fehlende Informationen

Verbesserte Erfassung

Titel: E-Mail-Versand über Outlook am Standort Süd nicht möglich
Service: E-Mail und Kalender
Vorgangsart: Incident
Symptom: Nachrichten bleiben im Postausgang
Beginn: etwa 09:10 Uhr
Betroffene: aktuell sieben Benutzer am Standort Süd
Auswirkung: externe Nachrichten können nicht versendet werden; Empfang funktioniert
Fehlermeldung: „Verbindung zum Ausgangsserver nicht möglich“
Prüfung: Webmail-Versand funktioniert; Outlook und Geräte wurden nicht verändert
Zwischenlösung: Versand über Webmail möglich
Nächster Schritt: lokale Outlook- und Netzwerkverbindung prüfen

Praxisbeispiel: Incident oder Service Request

Benutzermeldung:

Ich komme nicht auf das Projektlaufwerk.

Möglicher Incident

Möglicher Service Request

Mögliche Sicherheitssituation

Dieselbe Formulierung kann zu unterschiedlichen Vorgangsarten führen.

Praxisbeispiel: Duplikate bei einer Störung

Innerhalb von zehn Minuten melden 35 Benutzer:

Dateiablage nicht erreichbar.

Geeignete Behandlung:

  1. gemeinsamen Incident erkennen
  2. betroffene Benutzer und Standorte ergänzen
  3. Duplikate mit Haupt-Incident verknüpfen
  4. technische Bearbeitung zentral koordinieren
  5. allgemeine Statusmeldung veröffentlichen
  6. individuelle Sonderauswirkungen gesondert dokumentieren
  7. Wiederherstellung für betroffene Gruppen prüfen

Ungeeignet:

Praxisbeispiel: falsche Kategorisierung

Ticket wurde erfasst als:

Netzwerk → WLAN → Verbindungsfehler

Die Analyse zeigt:

Korrektur:

Die ursprüngliche Benutzerbeschreibung und bisherige Diagnose bleiben erhalten.

Praxisbeispiel: sicherheitskritischer Anhang

Ein Benutzer hängt einen Screenshot an.

Darauf sichtbar:

Geeignete Reaktion:

Das Ticket darf nicht unverändert an große Verteiler oder externe Lieferanten weitergeleitet werden.

Typische Fehler bei Ticket-Erfassung und Kategorisierung

Fehler 1: Titel ohne Aussage

„Problem“, „Hilfe“ oder „Dringend“ ermöglichen keine schnelle Einordnung.

Fehler 2: vermutete Ursache als Tatsache

Die Diagnose wird früh auf eine möglicherweise falsche Richtung festgelegt.

Fehler 3: nur technische Komponente erfassen

Betroffener Service und Geschäftsbezug bleiben unbekannt.

Fehler 4: meldende und betroffene Person verwechseln

Kommunikation und Auswirkung werden falsch zugeordnet.

Fehler 5: Kategorie nach Supportteam auswählen

Organisatorische Änderungen machen das Modell unbrauchbar.

Fehler 6: zu viele Kategorieebenen

Erfassung wird langsam und fehleranfällig.

Fehler 7: „Sonstiges“ als Standard verwenden

Fehler 8: Kategorie nach neuen Erkenntnissen nicht korrigieren

Berichte und Wissenszuordnung bleiben falsch.

Fehler 9: Maßnahmen ohne Ergebnis dokumentieren

Es ist nicht erkennbar, ob ein Test erfolgreich war.

Fehler 10: interne Abkürzungen ohne Erklärung

Andere Teams und spätere Bearbeiter verstehen die Notizen nicht.

Fehler 11: Ticketweiterleitung ohne Kontext

Nächste Gruppe muss die gesamte Situation erneut untersuchen.

Fehler 12: Status „Warten“ ohne nächsten Schritt

Der Vorgang bleibt unbegrenzt liegen.

Fehler 13: Ticket schließen, sobald eine technische Aktion durchgeführt wurde

Das Benutzer-Outcome wurde noch nicht bestätigt.

Fehler 14: Duplikate einfach löschen

Zusätzliche Auswirkungen und Kontaktinformationen gehen verloren.

Fehler 15: sensible Daten unkontrolliert speichern

Datenschutz- und Sicherheitsrisiken entstehen.

Fehler 16: alle Felder verpflichtend machen

Benutzer und Mitarbeiter tragen Platzhalter oder falsche Werte ein.

Fehler 17: KI-Kategorie ungeprüft übernehmen

Kritische oder sicherheitsbezogene Meldungen können falsch eingeordnet werden.

Fehler 18: Kategorien nie überarbeiten

Neue Services und veränderte Arbeitsweisen werden nicht berücksichtigt.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker erhalten häufig Tickets aus dem Service Desk oder erstellen selbst technische Vorgänge.

Vor Beginn der Bearbeitung sollte geprüft werden:

Während der Bearbeitung sollten dokumentiert werden:

Nach der Bearbeitung sollten dokumentiert werden:

30-Sekunden-Prüfung eines Tickets

  1. Person: Wer meldet und wer ist betroffen?
  2. Service: Welcher Service oder Arbeitsprozess ist betroffen?
  3. Symptom: Was wurde tatsächlich beobachtet?
  4. Zeit: Seit wann besteht die Situation?
  5. Auswirkung: Was kann nicht durchgeführt werden?
  6. Umfang: Wer oder was ist zusätzlich betroffen?
  7. Einordnung: Incident, Request, Frage, Feedback oder Sicherheitsmeldung?
  8. Kategorie: Unterstützt die Kategorie Bearbeitung und Auswertung?
  9. Maßnahmen: Was wurde bereits durchgeführt?
  10. Ergebnisse: Was haben die Maßnahmen gezeigt?
  11. Ownership: Wer ist aktuell verantwortlich?
  12. Nächster Schritt: Was geschieht als Nächstes?
  13. Kommunikation: Wann erhält der Benutzer eine Rückmeldung?
  14. Sicherheit: Enthält das Ticket nur zulässige Informationen?
  15. Abschluss: Wie wird das tatsächliche Outcome bestätigt?

Checkliste für die Ersterfassung

Checkliste für technische Arbeitsnotizen

Checkliste vor einer Weiterleitung

Checkliste für die Kategorisierung

Checkliste für Anhänge und sensible Informationen

Checkliste vor dem Abschluss

Checkliste für das Kategoriemodell der Organisation

Schnellreferenz

Bereich Zentrale Frage
Titel Ist die Situation auf einen Blick verständlich?
Person Wer meldet und wer ist betroffen?
Service Welche Arbeitsfähigkeit oder Leistung ist beeinträchtigt?
Symptom Was wurde tatsächlich beobachtet?
Zeit Wann begann die Situation?
Auswirkung Was kann nicht durchgeführt werden?
Vorgangsart Incident, Request, Frage, Feedback oder Sicherheitsmeldung?
Kategorie Unterstützt sie Bearbeitung, Wissen und Auswertung?
Maßnahmen Was wurde bereits getan?
Ergebnisse Was wurde dadurch festgestellt?
Ownership Wer besitzt den nächsten Schritt?
Kommunikation Wann erhält der Benutzer die nächste Information?
Sicherheit Sind Daten und Anhänge angemessen geschützt?
Abschluss Wurde das tatsächliche Outcome bestätigt?

Zusammenfassende Darstellung

Benutzerkontakt oder technische Meldung
↓
meldende und betroffene Personen bestimmen
↓
betroffenen Service und tatsächliches Symptom erfassen
↓
Auswirkungen, Umfang und Zeitangaben dokumentieren
↓
Vorgangsart und vorläufige Kategorie bestimmen
↓
Ownership und nächsten Schritt festlegen
↓
Maßnahmen und Ergebnisse chronologisch dokumentieren
↓
Kategorie bei neuen Erkenntnissen korrigieren
↓
verknüpfte Incidents, Requests, Problems, Changes und Lieferantenfälle sichtbar machen
↓
Lösung oder Erfüllung dokumentieren
↓
Benutzer-Outcome bestätigen
↓
Wissen, Muster und Verbesserungsmöglichkeiten weiterverwenden

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Offiziell bestätigter Stand

Die offiziellen ITIL- und PeopleCert-Quellen bestätigen:

Einordnung

Die auf dieser Seite dargestellten:

sind herstellerneutrale redaktionelle Praxisempfehlungen dieses unabhängigen Nachschlagewerks.

ITIL schreibt kein universelles:

für alle Organisationen vor.

Die konkrete Gestaltung muss angepasst werden an:

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

3. Service Desk, Support und operative Servicearbeit

3.5 Auswirkungen, Dringlichkeit und Priorität

Kurz erklärt

Die Priorität bestimmt, in welcher Reihenfolge und mit welcher Aufmerksamkeit ein Vorgang bearbeitet werden soll.

Sie sollte nicht allein davon abhängen:

Eine verbreitete betriebliche Vorgehensweise ist, die Priorität anhand von:

zu bestimmen.

Auswirkung beschreibt, wie stark Benutzer, Services, Geschäftsprozesse oder andere Stakeholder beeinträchtigt sind.

Dringlichkeit beschreibt, wie schnell gehandelt werden muss, bevor sich die Folgen verschlimmern oder ein wichtiges Zeitfenster verloren geht.

Die Organisation muss selbst festlegen:

ITIL schreibt keine universelle Prioritätsmatrix vor, die unverändert für jede Organisation übernommen werden kann.

Warum eine nachvollziehbare Priorisierung notwendig ist

Eine Serviceorganisation besitzt normalerweise mehr offene Arbeit, als gleichzeitig bearbeitet werden kann.

Beispiele:

Ohne nachvollziehbare Priorisierung kann die Reihenfolge bestimmt werden durch:

Dadurch können schwerwiegende Situationen übersehen werden, während weniger bedeutsame Vorgänge bevorzugt bearbeitet werden.

Beispiel:

Vorgang A

Ein Vorstandsmitglied kann einen zweiten, selten verwendeten Bildschirm nicht nutzen.

Vorgang B

Ein einzelner Produktionsarbeitsplatz kann keine Sicherheitsfreigaben mehr durchführen. Dadurch steht in 20 Minuten eine gesamte Fertigungslinie still.

Obwohl bei beiden Vorgängen zunächst nur eine Person betroffen ist, besitzt Vorgang B wahrscheinlich die deutlich größere Auswirkung und Dringlichkeit.

Merke

Priorisierung bewertet nicht die persönliche Wichtigkeit eines Benutzers.

Sie bewertet die Bedeutung und zeitliche Kritikalität des betroffenen Outcomes.

Auswirkung, Dringlichkeit und Priorität unterscheiden

Begriff Zentrale Frage
Auswirkung Wie schwerwiegend sind die Folgen für Benutzer, Services oder Organisation?
Dringlichkeit Wie schnell muss gehandelt werden, bevor die Folgen unvertretbar werden?
Priorität In welcher Reihenfolge und mit welcher Aufmerksamkeit wird der Vorgang bearbeitet?

Beispiel:

Ein Archivsystem ist ausgefallen.

Mögliche geringe Dringlichkeit

Mögliche hohe Auswirkung

Die Auswirkung kann damit hoch sein, während die unmittelbare Dringlichkeit zunächst geringer ist.

Ein anderes Beispiel:

Ein einzelner Benutzer kann eine Präsentation für einen in zehn Minuten beginnenden Kundentermin nicht öffnen.

Wichtig

Auswirkung und Dringlichkeit beschreiben unterschiedliche Perspektiven.

Eine hohe Auswirkung bedeutet nicht automatisch höchste Dringlichkeit.

Priorität ist keine technische Fehlerklasse

Ein technisch kleiner Fehler kann eine hohe geschäftliche Priorität besitzen.

Beispiel:

Ein abgelaufenes Zertifikat ist möglicherweise schnell erneuerbar.

Wenn dadurch jedoch:

kann der Incident höchste Priorität erhalten.

Umgekehrt kann ein technisch komplexes Problem eine geringere Priorität besitzen.

Beispiel:

Ein selten verwendeter Bericht erzeugt unter einer bestimmten Kombination von Filtern einen Darstellungsfehler.

Die Analyse kann technisch aufwendig sein.

Wenn jedoch:

kann eine niedrigere Priorität angemessen sein.

Merke

Technische Schwierigkeit und betriebliche Priorität sind nicht dasselbe.

Mögliche Einflussfaktoren auf die Auswirkung

Die Organisation kann mehrere Kriterien berücksichtigen.

Anzahl betroffener Benutzer

Mögliche Abstufung:

Die Anzahl allein reicht jedoch nicht aus.

Ein einzelner betroffener Benutzer kann eine kritische Aufgabe ausführen.

Kritikalität des betroffenen Service

Beispiele:

Die Organisation sollte wichtige Services und deren Abhängigkeiten kennen.

Bedeutung des betroffenen Geschäftsprozesses

Mögliche Auswirkungen:

Art der Beeinträchtigung

Beeinträchtigung Beispiel
vollständiger Ausfall Service ist nicht nutzbar
teilweiser Ausfall bestimmte Funktionen fehlen
Leistungsminderung Service reagiert stark verzögert
Qualitätsminderung Ergebnisse sind unvollständig oder fehlerhaft
Sicherheitsbeeinträchtigung Schutzbedarf könnte verletzt sein
Datenbeeinträchtigung Daten sind verloren, beschädigt oder inkonsistent
Erfahrungsbeeinträchtigung Service ist technisch verfügbar, aber praktisch kaum nutzbar

Verfügbarkeit einer Zwischenlösung

Eine geeignete Zwischenlösung kann die Auswirkung oder Dringlichkeit reduzieren.

Beispiele:

Die Zwischenlösung muss jedoch:

sein.

Ungeeignet wäre beispielsweise:

Benutzer können ihre Dokumente an private E-Mail-Adressen senden.

Auch wenn dadurch kurzfristig weitergearbeitet werden könnte, wäre dies möglicherweise aus Sicherheits- und Datenschutzgründen unzulässig.

Dauer und Reichweite

Die tatsächliche Auswirkung kann mit der Zeit wachsen.

Beispiel:

Ein Bestellsystem fällt am frühen Morgen aus.

Zu Beginn bestehen nur wenige offene Bestellungen.

Nach mehreren Stunden können entstehen:

Die Priorität muss deshalb möglicherweise während der Bearbeitung erhöht werden.

Finanzielle Auswirkungen

Mögliche Kriterien:

Nicht jede Organisation kann exakte Beträge während der Ersterfassung bestimmen.

Eine qualitative Bewertung kann zunächst ausreichen.

Sicherheits- und Datenschutzfolgen

Mögliche Auswirkungen:

Ein möglicher Sicherheitsvorfall benötigt möglicherweise:

Er darf nicht ausschließlich anhand der Zahl aktuell betroffener Benutzer bewertet werden.

Gesetzliche und regulatorische Auswirkungen

Mögliche Beispiele:

Die Organisation muss ihre verbindlichen Anforderungen kennen und in die Bewertung einbeziehen.

Auswirkungen auf Kunden, Öffentlichkeit und Reputation

Mögliche Folgen:

Reputationsauswirkung sollte nicht nur nach subjektivem Eindruck bewertet werden.

Geeignete Eskalations- und Kommunikationsrollen müssen beteiligt werden.

Auswirkungen auf Gesundheit und Sicherheit

In bestimmten Umgebungen können IT-Störungen Auswirkungen besitzen auf:

Solche Situationen benötigen möglicherweise:

Mögliche Einflussfaktoren auf die Dringlichkeit

Dringlichkeit beschreibt die verfügbare Zeit bis zu einer wesentlichen Verschlechterung oder bis zum Verlust eines wichtigen Outcomes.

Unmittelbarer Zeitdruck

Beispiele:

Zeit bis zur erwarteten Verschlechterung

Beispiel:

Ein Speicherbereich ist zu 95 Prozent belegt.

Der Service funktioniert noch.

Monitoring zeigt jedoch, dass der Speicher voraussichtlich innerhalb einer Stunde vollständig belegt sein wird.

Obwohl noch kein vollständiger Ausfall besteht, kann hohe Dringlichkeit vorliegen.

Verbleibendes Zeitfenster

Beispiele:

Verfügbarkeit einer Zwischenlösung

Eine sichere und praktikable Zwischenlösung kann die Dringlichkeit reduzieren.

Beispiel:

Die Desktop-Anwendung ist ausgefallen.

Die Webversion ermöglicht alle wichtigen Tätigkeiten.

Die Bearbeitung kann dadurch möglicherweise kontrollierter erfolgen.

Die Zwischenlösung muss allerdings hinsichtlich folgender Punkte bewertet werden:

Drohender Datenverlust

Dringlichkeit kann besonders hoch sein, wenn:

In solchen Situationen kann die erste Maßnahme darin bestehen:

Eine vorschnelle normale Fehlerbehebung kann Wiederherstellungsmöglichkeiten verschlechtern.

Sicherheitsbedrohung

Hohe Dringlichkeit kann vorliegen bei:

Die Bearbeitung richtet sich dann nicht nur nach Incident Management, sondern auch nach dem Sicherheitsverfahren der Organisation.

Kommender geschäftskritischer Zeitpunkt

Beispiel:

Die Gehaltsabrechnung funktioniert am Montag nicht.

Der endgültige Abrechnungslauf beginnt erst am Mittwoch.

Die Auswirkung ist bereits erheblich.

Die verfügbare Zeit bis Mittwoch beeinflusst jedoch die Dringlichkeit und den möglichen Eskalationsweg.

Eine mögliche Auswirkungsskala

Die folgende Skala ist ein redaktionelles Beispiel.

Sie ist keine verbindliche ITIL-Vorgabe.

Stufe Beispielhafte Bedeutung
Hoch kritischer Service, großer Benutzerkreis, erheblicher Geschäfts-, Sicherheits- oder Kundenbezug
Mittel mehrere Benutzer oder wichtiger Teil eines Service betroffen, begrenzte Zwischenlösung vorhanden
Niedrig einzelne oder wenige Benutzer, begrenzte Folgen, geeignete Alternative vorhanden

Eine Organisation kann stattdessen verwenden:

Beispielkriterien für hohe Auswirkung

Eine hohe Auswirkung kann beispielsweise vorliegen, wenn mindestens eines der folgenden Kriterien erfüllt ist:

Die Organisation muss festlegen, ob:

Eine mögliche Dringlichkeitsskala

Auch diese Skala ist ein redaktionelles Beispiel.

Stufe Beispielhafte Bedeutung
Hoch sofortiges Handeln erforderlich; Folgen treten bereits ein oder verschlimmern sich sehr schnell
Mittel zeitnahe Bearbeitung erforderlich; begrenztes Zeitfenster oder zunehmende Folgen
Niedrig Bearbeitung planbar; Auswirkungen verschlechtern sich voraussichtlich nicht kurzfristig

Beispielkriterien für hohe Dringlichkeit

Eine mögliche Prioritätsmatrix

Die folgende Matrix ist eine Praxisvorlage und keine verbindliche ITIL-Matrix.

Auswirkung Dringlichkeit hoch Dringlichkeit mittel Dringlichkeit niedrig
hoch P1 P2 P3
mittel P2 P3 P4
niedrig P3 P4 P4

Eine Organisation kann auch andere Ergebnisse festlegen.

Beispielsweise könnte:

Wichtig

Eine Matrix unterstützt Entscheidungen.

Sie ersetzt nicht die fachliche Bewertung besonderer Situationen.

Mögliche Prioritätsstufen

Priorität Praxisnahe Bedeutung
P1 – kritisch sofortige koordinierte Bearbeitung; sehr hohe Auswirkung und Dringlichkeit
P2 – hoch schnelle priorisierte Bearbeitung; erhebliche Beeinträchtigung
P3 – mittel normale priorisierte Bearbeitung innerhalb vereinbarter Ziele
P4 – niedrig planbare Bearbeitung bei begrenzter Auswirkung und Dringlichkeit

Manche Organisationen verwenden:

Die Bedeutung muss eindeutig dokumentiert sein.

Priorität und Severity unterscheiden

Der Begriff Severity wird in Organisationen unterschiedlich verwendet.

Mögliche Bedeutungen:

Priorität beschreibt dagegen die Bearbeitungsreihenfolge und Aufmerksamkeit.

Beispiel:

Ein Softwarefehler kann hohe Severity besitzen, weil er bei bestimmten Bedingungen Daten beschädigt.

Wenn diese Funktion derzeit deaktiviert ist und kein unmittelbarer Schaden droht, kann die operative Bearbeitungspriorität zunächst anders eingeordnet werden.

Praxistipp

Die Organisation sollte in einem Glossar eindeutig festlegen, wie Severity und Priorität verwendet werden.

Priorität und Servicekritikalität unterscheiden

Servicekritikalität ist eine grundsätzlichere Eigenschaft eines Service.

Beispiele:

Die Priorität bewertet dagegen einen konkreten Vorgang.

Ein Incident an einem kritischen Service besitzt nicht automatisch immer P1.

Beispiel:

In einer geschäftskritischen Anwendung ist nur eine selten verwendete Berichtsfunktion betroffen.

Der Kernservice funktioniert.

Eine geeignete Zwischenlösung besteht.

Der konkrete Incident kann deshalb eine niedrigere Priorität erhalten.

Umgekehrt kann ein normalerweise weniger kritischer Service zu einem bestimmten Zeitpunkt besonders wichtig sein.

Beispiel:

Eine Schulungsplattform wird während einer verbindlichen Abschlussprüfung benötigt.

Priorität und Major Incident unterscheiden

Ein Major Incident ist ein Incident mit besonders erheblicher Bedeutung, der eine besondere Koordination und Kommunikation erfordern kann.

Eine Organisation legt eigene Kriterien fest.

Ein P1-Incident kann ein Major Incident sein.

Dies muss jedoch nicht in jeder Organisation automatisch identisch sein.

Priorität Major Incident
bestimmt Bearbeitungsreihenfolge und Zielzeiten aktiviert besondere Koordination und Kommunikation
kann für unterschiedliche Vorgangsarten gelten bezieht sich auf besonders schwerwiegende Incidents
wird häufig aus Auswirkung und Dringlichkeit bestimmt kann zusätzliche definierte Kriterien besitzen
kann durch normale Supportstruktur bearbeitet werden benötigt möglicherweise Incident-Koordination, Krisenkommunikation und Managementbeteiligung

Major-Incident-Kriterien werden auf Seite 3.7 Ownership, hierarchische Eskalation und Major Incidents vertieft.

Priorität und Eskalation unterscheiden

Hohe Priorität kann eine Eskalation auslösen.

Eine Eskalation kann jedoch auch notwendig sein, wenn die Priorität nicht besonders hoch ist.

Beispiele:

Die Priorität beschreibt nicht vollständig, welcher Eskalationstyp benötigt wird.

Priorität und Zielzeiten unterscheiden

Prioritätsstufen können mit unterschiedlichen Zielen verbunden sein.

Mögliche Ziele:

Beispielhafte interne Ziele:

Priorität Qualifizierte Reaktion Statusintervall
P1 unverzüglich alle 30 Minuten
P2 innerhalb einer Stunde alle 2 Stunden
P3 innerhalb eines Arbeitstags nach wesentlichen Änderungen
P4 nach Planung nach Vereinbarung

Diese Werte sind nur Beispiele.

Die tatsächlichen Ziele müssen zu:

passen.

Reaktionsziel ist kein Lösungsversprechen

Eine Zielzeit für die erste Reaktion bedeutet nicht automatisch, dass der Incident innerhalb dieses Zeitraums gelöst sein muss.

Beispiel:

Qualifizierte Reaktion innerhalb von 30 Minuten

kann bedeuten:

Eine Wiederherstellungszeit hängt unter anderem ab von:

Merke

Serviceziele müssen verständlich benannt werden.

„Antwort innerhalb einer Stunde“ darf nicht als „Lösung innerhalb einer Stunde“ missverstanden werden.

Statusintervalle nach Priorität

Bei hoher Priorität benötigen Stakeholder häufigere Informationen.

Ein Statusintervall sollte festlegen:

Auch wenn keine neue Lösung vorliegt, kann eine Statusmeldung enthalten:

Priorität bei der Ersterfassung

Bei der ersten Meldung liegen häufig noch nicht alle Informationen vor.

Eine vorläufige Priorität kann anhand der verfügbaren Angaben gesetzt werden.

Danach sollte sie überprüft werden, sobald bekannt ist:

Wichtig

Eine erste Priorität ist keine unveränderliche Entscheidung.

Priorität dynamisch neu bewerten

Eine Neubewertung ist sinnvoll, wenn:

Die Priorität kann auch gesenkt werden, wenn:

Jede wesentliche Änderung sollte dokumentiert werden.

Prioritätsänderungen dokumentieren

Eine nachvollziehbare Dokumentation kann enthalten:

Beispiel:

10:25 Uhr – Priorität von P3 auf P1 erhöht. Ursprünglich war ein einzelner Arbeitsplatz betroffen. Inzwischen können sämtliche Benutzer des Standorts keine Produktionsfreigabe durchführen. Fertigung steht seit 10:20 Uhr. Incident-Koordination und Standortleitung wurden informiert.

Wer darf die Priorität ändern?

Die Organisation sollte festlegen:

Mögliche Rollen:

Eine Priorität darf nicht allein deshalb geändert werden, weil eine Person eine schnellere Bearbeitung verlangt.

Benutzerwunsch und organisatorische Priorität

Benutzer sollen die Auswirkungen und zeitlichen Anforderungen beschreiben können.

Sie müssen jedoch nicht zwingend die endgültige Priorität auswählen.

Eine geeignete Kommunikation kann lauten:

Sie haben angegeben, dass die Angelegenheit sehr dringend ist. Ich prüfe jetzt zusätzlich, wie viele Benutzer und welcher Geschäftsprozess betroffen sind. Daraus wird die Priorität nach unseren Kriterien bestimmt.

Bei abweichender Bewertung:

Ich verstehe, dass Sie die Anwendung heute benötigen. Da aktuell nur eine Person betroffen ist, eine sichere Alternative besteht und keine Frist innerhalb der nächsten Stunden gefährdet ist, wird der Vorgang als P3 bearbeitet. Sollte die Alternative ausfallen oder der Monatsabschluss gefährdet sein, bewerten wir die Priorität erneut.

Hierarchie ist kein automatisches Prioritätskriterium

Ein Vorgang einer Führungskraft kann hohe Auswirkung besitzen.

Beispiel:

Die Person muss eine zeitkritische strategische Entscheidung freigeben.

Die hierarchische Position allein genügt jedoch nicht als Begründung.

Ungeeignet:

Tickets der Geschäftsführung sind immer P1.

Besser:

Grundsatz

Eine besondere Kommunikationsbehandlung ist nicht automatisch eine höhere technische Bearbeitungspriorität.

VIP-Regelungen kritisch gestalten

Organisationen verwenden teilweise VIP-Kennzeichnungen.

Diese können unterstützen bei:

Sie sollten nicht dazu führen, dass:

Zwischenlösungen richtig bewerten

Ein Workaround reduziert möglicherweise die Dringlichkeit.

Er löst jedoch nicht automatisch den Incident dauerhaft.

Beispiel:

Die Desktop-Anwendung ist ausgefallen.

Benutzer können vorübergehend die Webversion verwenden.

Zu prüfen ist:

Ein Workaround kann damit:

Er darf aber nicht unkritisch als vollständige Lösung behandelt werden.

Priorisierung bei mehreren gleichzeitig kritischen Incidents

Mehrere P1-Incidents können gleichzeitig auftreten.

Dann reicht die Prioritätsnummer allein möglicherweise nicht aus.

Zusätzlich zu bewerten sind:

Governance oder Incident-Koordination muss möglicherweise Ressourcen zwischen den Vorgängen verteilen.

Abhängige Services berücksichtigen

Ein Incident kann zunächst nur eine technische Komponente betreffen.

Diese kann jedoch mehrere Services unterstützen.

Beispiel:

Ein zentraler Identitätsdienst zeigt erste Fehler.

Aktuell ist nur eine interne Anwendung betroffen.

Möglicherweise werden kurz darauf ebenfalls beeinträchtigt:

Die Priorität sollte potenzielle und bekannte Abhängigkeiten berücksichtigen, ohne unbelegte Worst-Case-Annahmen als Tatsache zu behandeln.

Verknüpfte Incidents gemeinsam betrachten

Mehrere scheinbar unabhängige Meldungen können einen gemeinsamen Auslöser besitzen.

Beispiele:

Wenn alle Services vom gleichen Identitätsdienst abhängen, kann ein gemeinsamer Incident mit höherer Auswirkung vorliegen.

Service Requests priorisieren

Nicht nur Incidents benötigen eine Bearbeitungsreihenfolge.

Auch Service Requests können unterschiedliche Dringlichkeit und Bedeutung besitzen.

Beispiele:

Service Requests sollten trotzdem nicht wie Incidents behandelt werden.

Bei Requests können zusätzlich relevant sein:

Eine verspätet eingereichte Anfrage wird nicht automatisch zum Incident.

Beispiel:

Eine Führungskraft beantragt erst am Freitagnachmittag einen vollständigen Arbeitsplatz für Montag.

Die Anfrage ist dringend.

Es liegt jedoch nicht zwingend eine ungeplante Serviceunterbrechung vor.

Notfall durch schlechte Planung

Eine intern verspätete Anfrage sollte nicht automatisch höchste technische Priorität erhalten.

Trotzdem muss die Organisation die tatsächlichen Auswirkungen berücksichtigen.

Geeignete Vorgehensweise:

Backlog und Priorität

Innerhalb derselben Priorität kann die Reihenfolge zusätzlich bestimmt werden durch:

Ein älteres P3-Ticket sollte nicht dauerhaft durch neue P3-Tickets verdrängt werden.

Backlog-Steuerung sollte deshalb auch berücksichtigen:

Priorität darf nicht jede Planung zerstören

Hohe Prioritäten sollten tatsächlich besonderen Situationen vorbehalten bleiben.

Wenn sehr viele Vorgänge als P1 oder P2 eingestuft werden:

Eine hohe Quote kritischer Prioritäten kann hinweisen auf:

Prioritätsinflation

Prioritätsinflation entsteht, wenn immer mehr Vorgänge hoch priorisiert werden, um schneller bearbeitet zu werden.

Mögliche Anzeichen:

Mögliche Maßnahmen:

Falsche Herabstufung

Prioritäten können ebenfalls zu niedrig angesetzt werden.

Mögliche Ursachen:

Beispiel:

Nur ein Benutzer meldet einen Fehler.

Dieser Benutzer ist jedoch für die gesetzlich fristgebundene Meldung verantwortlich.

Ohne Kontext könnte der Vorgang fälschlich als geringe Auswirkung bewertet werden.

Automatisierte Priorisierung

Werkzeuge können eine Priorität vorschlagen anhand von:

Vorteile:

Risiken:

Merke

Automatisierung kann Priorisierung unterstützen.

Sie ersetzt nicht die fachliche Bewertung ungewöhnlicher Situationen.

KI-gestützte Priorisierung

KI kann Muster erkennen in:

Sie kann beispielsweise vorschlagen:

Mögliche Risiken:

Notwendig sind:

Emotionale Sprache und KI

Eine KI darf nicht automatisch eine hohe Priorität setzen, nur weil ein Ticket Wörter enthält wie:

Sie muss organisatorisch relevante Auswirkungen erkennen oder zur weiteren Klärung auffordern.

Beispiel:

„Extrem dringend: Mauszeiger ist zu langsam.“

Die Formulierung allein beweist keine hohe Auswirkung oder Dringlichkeit.

Priorisierung bei Sicherheitsmeldungen

Eine Sicherheitsmeldung benötigt möglicherweise ein separates Bewertungsmodell.

Zusätzliche Kriterien können sein:

Ein scheinbar kleiner Vorfall kann hohe Kritikalität besitzen.

Beispiel:

Nur ein Administratorkonto zeigt eine verdächtige Anmeldung.

Die Benutzerzahl ist gering.

Der mögliche Berechtigungsumfang ist jedoch sehr hoch.

Priorisierung bei Datenverlust

Zu klären sind:

Die erste Priorität kann darin bestehen, weiteren Schaden zu verhindern.

Priorisierung bei Performance-Problemen

Ein Service kann technisch verfügbar sein, aber praktisch nicht ausreichend nutzbar.

Zu bewerten sind:

Beispiel:

Eine Anwendung benötigt statt zwei Sekunden nun 30 Sekunden pro Vorgang.

Bei wenigen Vorgängen ist dies möglicherweise begrenzt.

Während eines Massenabrechnungslaufs kann dieselbe Verzögerung den gesamten Prozess blockieren.

Priorisierung bei geplanten Changes

Ein Incident nach einem Change kann besondere Aufmerksamkeit benötigen.

Zu prüfen sind:

Die Priorität wird weiterhin anhand der tatsächlichen Auswirkung und Dringlichkeit bestimmt.

Ein Zusammenhang mit einem Change bedeutet nicht automatisch P1.

Priorisierung und Lieferanten

Bei Lieferantenfällen müssen möglicherweise zusätzlich berücksichtigt werden:

Die interne Priorität und die Lieferantenpriorität können unterschiedliche Bezeichnungen besitzen.

Beispiel:

Intern:

P1

Beim Provider:

Severity 1

Die Organisation muss die Zuordnung kennen und prüfen, ob die Kriterien tatsächlich übereinstimmen.

Kommunikation einer Priorität

Benutzer müssen nicht zwingend jedes interne Prioritätsdetail verstehen.

Sie sollten jedoch nachvollziehen können:

Geeignete Formulierung:

Der Vorgang wurde als hohe Priorität eingestuft, weil der gesamte Standort betroffen ist und keine Zwischenlösung besteht. Das Netzwerkteam und der Provider arbeiten bereits an der Wiederherstellung. Die nächste Statusmeldung erfolgt spätestens um 10:30 Uhr.

Bei niedrigerer Priorität:

Der Vorgang wird innerhalb der normalen Servicezeit bearbeitet. Aktuell ist ein Benutzer betroffen und ein alternativer Arbeitsplatz steht zur Verfügung. Sollte diese Alternative ausfallen, melden Sie sich bitte unter Angabe der Vorgangsnummer, damit die Priorität neu bewertet werden kann.

Keine Prioritätsdiskussion ohne Kontext

Ungeeignet:

Das ist nur P3.

Besser:

Nach den aktuellen Informationen ist eine Person betroffen und eine funktionsfähige Alternative vorhanden. Deshalb wird der Vorgang derzeit als P3 bearbeitet. Wenn weitere Benutzer betroffen sind oder die Alternative ausfällt, erhöhen wir die Priorität.

Governance der Priorisierung

Eine wirksame Priorisierung benötigt:

Zu klären ist:

Prioritätsmodell regelmäßig überprüfen

Das Modell kann ungeeignet werden durch:

Regelmäßig zu prüfen sind:

Kennzahlen zur Priorisierung

Mögliche Kennzahlen:

Kennzahlen sollten nicht isoliert betrachtet werden.

Problematische Kennzahlen

Möglichst wenige P1-Incidents

Mögliche Fehlwirkung:

Möglichst hohe Zielerreichung

Mögliche Fehlwirkung:

Möglichst kurze Lösungszeit

Mögliche Fehlwirkung:

Merke

Kennzahlen dürfen nicht dazu führen, dass die Prioritätsbewertung manipuliert wird.

Praxisbeispiel: Ein Benutzer, hohe Auswirkung

Meldung

Ein einzelner Mitarbeiter kann eine Produktionsfreigabe nicht durchführen.

Zusätzlicher Kontext

Bewertung

Das Beispiel zeigt, warum Benutzerzahl nicht allein ausreicht.

Praxisbeispiel: Viele Benutzer, niedrige Dringlichkeit

Meldung

Das interne Archivsystem ist für alle Benutzer nicht erreichbar.

Zusätzlicher Kontext

Bewertung

Praxisbeispiel: Führungskraft mit geringerer Auswirkung

Meldung

Eine Führungskraft kann einen zweiten Bildschirm nicht verwenden.

Zusätzlicher Kontext

Bewertung

Die Position der meldenden Person verändert die technische Auswirkung nicht automatisch.

Praxisbeispiel: Aktive Sicherheitsbedrohung

Meldung

Ein einzelnes Administratorkonto zeigt mehrere ungewöhnliche Anmeldungen aus einem unbekannten Land.

Zusätzlicher Kontext

Bewertung

Praxisbeispiel: Workaround reduziert Dringlichkeit

Meldung

Die Desktop-Version einer Fachanwendung startet nicht.

Zusätzlicher Kontext

Bewertung vor Workaround

Bewertung nach bestätigtem Workaround

Praxisbeispiel: Priorität wird erhöht

Ursprüngliche Situation

Ein Benutzer kann keine Dateien speichern.

Neue Erkenntnis

Innerhalb von 20 Minuten melden weitere Benutzer dasselbe Problem.

Monitoring zeigt:

Neue Bewertung

Praxisbeispiel: Request wird nicht zum Incident

Eine Führungskraft meldet am Freitagnachmittag:

Neuer Mitarbeiter beginnt Montag. Notebook, Konto und alle Anwendungen werden dringend benötigt.

Die Situation ist zeitkritisch.

Es handelt sich jedoch um eine verspätet eingereichte Onboarding-Anfrage und nicht automatisch um einen Incident.

Mögliche Behandlung:

Typische Fehler bei der Priorisierung

Fehler 1: Priorität nur nach Benutzerzahl bestimmen

Ein einzelner kritischer Arbeitsplatz wird unterschätzt.

Fehler 2: Priorität nach Hierarchie bestimmen

Führungskräfte erhalten automatisch P1.

Fehler 3: Benutzer bestimmt endgültige Priorität

Subjektive Dringlichkeit ersetzt organisatorische Kriterien.

Fehler 4: Jede Störung eines kritischen Service ist P1

Teilfunktionen und geeignete Workarounds werden nicht berücksichtigt.

Fehler 5: Technische Komplexität mit Priorität verwechseln

Schwierige Fehler werden bevorzugt, obwohl andere Vorgänge größere Auswirkungen besitzen.

Fehler 6: Priorität nach der Ersterfassung nie ändern

Ausbreitung und neue Risiken bleiben unberücksichtigt.

Fehler 7: Workaround automatisch als vollständige Lösung behandeln

Ursache und verbleibende Einschränkungen werden übersehen.

Fehler 8: Sicherheit nur nach Benutzerzahl bewerten

Ein kompromittiertes Administratorkonto wird unterschätzt.

Fehler 9: Zu viele P1- und P2-Tickets

Das Prioritätsmodell verliert seine Steuerungswirkung.

Fehler 10: Hohe Priorität zur Beschleunigung missbrauchen

Normale Requests verdrängen tatsächliche Incidents.

Fehler 11: Priorität senken, um Zielverletzung zu vermeiden

Kennzahlen werden manipuliert.

Fehler 12: Priorität und Major Incident gleichsetzen

Besondere Koordination wird entweder unnötig oder zu spät aktiviert.

Fehler 13: Zielzeit als Lösungsversprechen kommunizieren

Benutzer erhalten falsche Erwartungen.

Fehler 14: Zwischenlösung nicht fachlich prüfen

Unsichere oder unvollständige Alternativen führen zu falscher Herabstufung.

Fehler 15: Prioritätsänderung nicht dokumentieren

Spätere Entscheidungen sind nicht nachvollziehbar.

Fehler 16: Servicekritikalität ist veraltet

Neue geschäftliche Abhängigkeiten werden nicht erkannt.

Fehler 17: KI-Vorschlag ungeprüft übernehmen

Emotionale Sprache oder falsche Kategorien bestimmen die Priorität.

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker liefern wichtige Informationen für die Prioritätsbewertung.

Sie können beurteilen:

Technische Rückmeldungen sollten nicht nur lauten:

Server ist ausgefallen.

Besser:

Der Server unterstützt die zentrale Anmeldung für VPN und drei Cloud-Anwendungen. Aktuell können sich neue Benutzer nicht anmelden. Bestehende Sitzungen funktionieren noch. Ohne Wiederherstellung werden bei Ablauf der Sitzungen zunehmend weitere Benutzer betroffen sein. Ein sicherer Workaround besteht derzeit nicht.

Diese Informationen helfen bei der Bewertung von:

30-Sekunden-Prüfung der Auswirkung

  1. Welcher Service ist betroffen?
  2. Welche Benutzer oder Kunden sind betroffen?
  3. Welcher Geschäftsprozess ist beeinträchtigt?
  4. Besteht vollständiger oder teilweiser Ausfall?
  5. Gibt es Datenverlust oder Sicherheitsbezug?
  6. Besteht eine geeignete Zwischenlösung?
  7. Sind weitere Services abhängig?
  8. Welche finanziellen, vertraglichen oder rechtlichen Folgen bestehen?
  9. Besteht Gesundheits- oder Sicherheitsbezug?
  10. Wie stark kann sich die Auswirkung noch vergrößern?

30-Sekunden-Prüfung der Dringlichkeit

  1. Tritt der Schaden bereits ein?
  2. Verschlimmert sich die Situation?
  3. Wann wird ein kritischer Zeitpunkt erreicht?
  4. Besteht eine zeitliche Frist?
  5. Droht weiterer Datenverlust?
  6. Besteht eine aktive Sicherheitsbedrohung?
  7. Wie lange ist der Workaround nutzbar?
  8. Kann die Bearbeitung sicher geplant werden?
  9. Welche Wiederherstellungsfenster bestehen?
  10. Wann müssen weitere Rollen oder Lieferanten eingebunden werden?

Checkliste für die Ersterfassung

Checkliste für hohe Priorität

Checkliste für eine Prioritätsänderung

Checkliste für das Prioritätsmodell der Organisation

Schnellreferenz

Frage Zu bewertender Bereich
Wie viele Benutzer sind betroffen? Auswirkung
Welcher Service ist betroffen? Auswirkung
Welcher Geschäftsprozess steht still? Auswirkung
Besteht Daten- oder Sicherheitsrisiko? Auswirkung und Dringlichkeit
Gibt es einen geeigneten Workaround? Auswirkung und Dringlichkeit
Wann verschlimmert sich die Situation? Dringlichkeit
Welche Frist läuft ab? Dringlichkeit
Wie schnell muss gehandelt werden? Dringlichkeit
In welcher Reihenfolge wird bearbeitet? Priorität
Welche Zielzeiten gelten? Priorität und Service Level
Ist besondere Koordination notwendig? Eskalation oder Major Incident
Muss die Bewertung geändert werden? dynamische Neubewertung

Zusammenfassende Darstellung

Incident oder Request wird erfasst
↓
betroffenen Service und Geschäftsprozess bestimmen
↓
Anzahl und Bedeutung der betroffenen Stakeholder bewerten
↓
Daten-, Sicherheits-, Finanz- und Kundenfolgen berücksichtigen
↓
Auswirkung bestimmen
↓
Zeitdruck, Verschlechterung, Fristen und Workaround bewerten
↓
Dringlichkeit bestimmen
↓
organisatorische Matrix oder Entscheidungsregel anwenden
↓
Priorität festlegen und begründen
↓
Zielzeiten, Ownership, Eskalation und Kommunikation auslösen
↓
Situation fortlaufend beobachten
↓
Priorität bei neuen Erkenntnissen erhöhen oder senken
↓
Entscheidung und Auswirkungen nachvollziehbar dokumentieren

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Offiziell bestätigter Stand

Die offiziellen ITIL- und PeopleCert-Quellen bestätigen:

Einordnung

Die auf dieser Seite dargestellten:

sind herstellerneutrale redaktionelle Praxisempfehlungen dieses unabhängigen Nachschlagewerks.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Gestaltung muss angepasst werden an:

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

3. Service Desk, Support und operative Servicearbeit

3.6 Erstdiagnose, Lösung und funktionale Eskalation (Teil 1/2)

Kurz erklärt

Ziel der Erstdiagnose ist nicht, sofort die eigentliche Ursache zu kennen, sondern möglichst schnell die Situation zu verstehen, Auswirkungen zu begrenzen und den Service wiederherzustellen.

Gute Diagnosen beruhen auf:

ITIL empfiehlt, vorhandenes Wissen systematisch zu nutzen und Incidents möglichst früh dort zu lösen, wo die erforderlichen Fähigkeiten vorhanden sind.

Ziele der Erstdiagnose

Nach der Ticketaufnahme beginnt die eigentliche Analyse.

Dabei sollten zunächst folgende Fragen beantwortet werden:

Die Erstdiagnose soll möglichst schnell klären,

Erstdiagnose ist keine Ursachenanalyse

Ein häufiger Fehler besteht darin, bereits in den ersten Minuten die eigentliche Ursache finden zu wollen.

Die Erstdiagnose verfolgt jedoch ein anderes Ziel.

Erstdiagnose Ursachenanalyse
Service möglichst schnell wiederherstellen eigentliche Ursache dauerhaft finden
Minuten bis Stunden Stunden bis Tage
Incident Management Problem Management
Fokus auf Wiederherstellung Fokus auf Prävention

Beispiel:

Ein Webserver antwortet nicht.

Während der Erstdiagnose genügt möglicherweise:

Warum der Dienst abgestürzt ist, wird später im Problem Management untersucht.

Merke

Ein gelöster Incident bedeutet nicht automatisch, dass die Ursache beseitigt wurde.

Beobachtung vor Interpretation

Techniker neigen häufig dazu, sehr früh Vermutungen aufzustellen.

Besser ist folgende Reihenfolge:

  1. Beobachten
  2. Informationen sammeln
  3. Hypothesen bilden
  4. Hypothesen testen
  5. Ursache bestätigen

Beispiel:

❌ "Die Firewall blockiert den Zugriff."

Besser:

✅ "HTTPS-Verbindungen schlagen fehl. Andere Protokolle funktionieren. Firewall ist eine mögliche Ursache."

Symptome richtig erfassen

Ein Symptom beschreibt das beobachtete Verhalten.

Beispiele:

Ein Symptom ist noch keine Ursache.

Mögliche Ursachen

Für dasselbe Symptom können völlig unterschiedliche Ursachen verantwortlich sein.

Symptom

Anmeldung nicht möglich

Mögliche Ursachen:

Deshalb sollten Vermutungen immer überprüft werden.

Strukturierte Diagnose

Eine bewährte Reihenfolge lautet:

  1. Problem verstehen
  2. Umfang bestimmen
  3. Änderungen prüfen
  4. Logs prüfen
  5. Monitoring prüfen
  6. Verbindung testen
  7. Komponenten eingrenzen
  8. Hypothese testen
  9. Ergebnis dokumentieren

Umfang bestimmen

Nicht jede Störung betrifft alle Benutzer.

Zu klären ist:

Je genauer der Umfang bekannt ist, desto einfacher lässt sich die Ursache eingrenzen.

Änderungen berücksichtigen

Viele Incidents entstehen kurz nach Änderungen.

Zu prüfen sind beispielsweise:

Frage:

Was hat sich kurz vor dem Fehler geändert?

Diese Frage spart häufig sehr viel Diagnosezeit.

Reproduzierbarkeit prüfen

Ein Fehler sollte möglichst reproduziert werden.

Beispiel:

  1. Anwendung starten
  2. Benutzer anmelden
  3. Auftrag öffnen
  4. Speichern

Tritt der Fehler jedes Mal auf?

Oder nur gelegentlich?

Auch diese Information grenzt Ursachen erheblich ein.

Bekannte Fehler nutzen

Vor aufwendigen Analysen sollte geprüft werden:

Viele Incidents lassen sich dadurch deutlich schneller lösen.

Monitoring verwenden

Monitoring liefert häufig frühere Hinweise als Benutzer.

Beispiele:

Monitoring ersetzt jedoch keine Diagnose.

Es zeigt häufig nur Symptome.

Logs richtig einsetzen

Logs beantworten häufig Fragen wie:

Dabei gilt:

Nicht jede Warnung ist automatisch relevant.

Logs müssen immer im Zusammenhang betrachtet werden.

Ausschlussverfahren

Eine sehr effektive Methode ist das Ausschlussprinzip.

Beispiel:

VPN funktioniert nicht.

Prüfung:

Die Ursache lässt sich dadurch systematisch eingrenzen.

Von einfach nach komplex

ITIL empfiehlt keine feste Reihenfolge.

In der Praxis hat sich jedoch bewährt:

  1. Offensichtliches prüfen
  2. Bekannte Fehler prüfen
  3. Änderungen prüfen
  4. Monitoring prüfen
  5. Logs prüfen
  6. Detailanalyse

Nicht sofort mit der kompliziertesten Hypothese beginnen.

Keine unnötigen Änderungen

Während der Diagnose sollte möglichst nicht gleichzeitig an mehreren Komponenten gearbeitet werden.

Schlecht:

Danach ist kaum nachvollziehbar, welche Maßnahme tatsächlich geholfen hat.

Besser:

Eine Änderung durchführen.

Ergebnis prüfen.

Dokumentieren.

Erst danach die nächste Maßnahme.

Hypothesen dokumentieren

Eine gute Arbeitsnotiz enthält:

Hypothese

DNS-Auflösung fehlerhaft.

Test

Namensauflösung gegen internen DNS geprüft.

Ergebnis

DNS funktioniert.

Schlussfolgerung

Hypothese verworfen.

Dadurch vermeiden andere Bearbeiter dieselben Tests.

Wissen systematisch nutzen

Erfahrungen sollten nicht ausschließlich im Kopf einzelner Administratoren bleiben.

Hilfreich sind:

Dadurch steigt die First Contact Resolution deutlich.

First Contact Resolution (FCR)

FCR beschreibt den Anteil der Incidents,

die bereits beim ersten Kontakt vollständig gelöst werden.

Vorteile:

FCR darf jedoch nicht künstlich erhöht werden, indem Tickets vorschnell geschlossen werden.

Shift Left

Shift Left bedeutet,

Wissen möglichst früh im Support bereitzustellen.

Beispiele:

Dadurch können mehr Incidents bereits im Service Desk gelöst werden.

Dokumentation während der Diagnose

Nicht erst am Ende dokumentieren.

Nach jeder wichtigen Maßnahme sollte festgehalten werden:

Dadurch bleiben Übergaben nachvollziehbar.

Merksätze

Symptome sind keine Ursachen.

Beobachtungen sind wichtiger als Vermutungen.

Erst den Service wiederherstellen, anschließend die eigentliche Ursache untersuchen.

Jede Diagnose sollte nachvollziehbar dokumentiert werden.

Bekannte Lösungen sind schneller als neue Vermutungen.

3. Service Desk, Support und operative Servicearbeit

3.6 Erstdiagnose, Lösung und funktionale Eskalation (Teil 2/2)

Kurz erklärt

Die Erstdiagnose soll einen Incident schnell verstehen, eingrenzen und möglichst früh beheben.

Dabei geht es zunächst nicht darum, die endgültige Ursache vollständig zu ermitteln. Das wichtigste Ziel des Incident Managements ist die schnelle Wiederherstellung des vereinbarten Servicebetriebs.

Kann der Incident mit den vorhandenen Kenntnissen, Werkzeugen oder Berechtigungen nicht gelöst werden, erfolgt eine funktionale Eskalation an eine geeignete Fachgruppe.

Ziele der Erstdiagnose

Die Erstdiagnose soll möglichst schnell klären:

Eine gute Erstdiagnose reduziert:

Erstdiagnose und Ursachenanalyse unterscheiden

Die Erstdiagnose gehört in erster Linie zum Incident Management.

Die tiefergehende Ursachenanalyse gehört häufig zum Problem Management.

Erstdiagnose Ursachenanalyse
Service möglichst schnell wiederherstellen zugrunde liegende Ursache untersuchen
kurzfristiger Fokus langfristiger Fokus
Workaround oder schnelle Lösung möglich dauerhafte Lösung vorbereiten
Incident Management Problem Management
Minuten bis Stunden abhängig von Komplexität auch deutlich länger

Beispiel:

Ein Anwendungsdienst reagiert nicht mehr.

Incident Management

Problem Management

Merke

Ein Incident kann gelöst sein, obwohl die eigentliche Ursache noch nicht bekannt oder beseitigt ist.

Symptom, Ursache und Auswirkung unterscheiden

Begriff Bedeutung Beispiel
Symptom beobachtetes Fehlverhalten Anmeldung schlägt fehl
unmittelbare Ursache direkter technischer Auslöser Zertifikat abgelaufen
Grundursache tiefer liegende Ursache Zertifikatsüberwachung fehlte
Auswirkung Folge für Benutzer oder Geschäftsprozess Benutzer können nicht arbeiten

Zu Beginn eines Incidents ist häufig nur das Symptom bekannt.

Die Ursache darf deshalb nicht vorschnell als bestätigt dokumentiert werden.

Ungeeignet:

Die Firewall blockiert die Anwendung.

Besser:

HTTPS-Verbindungen zur Anwendung schlagen fehl. Eine Blockierung durch die Firewall ist eine mögliche, noch nicht bestätigte Ursache.

Beobachtung und Vermutung trennen

Eine strukturierte Diagnose folgt möglichst dieser Reihenfolge:

  1. beobachten
  2. Informationen sammeln
  3. Umfang bestimmen
  4. Hypothesen bilden
  5. Hypothesen testen
  6. Ergebnisse bewerten
  7. Service wiederherstellen
  8. Maßnahmen dokumentieren

Beobachtungen sollten möglichst messbar sein.

Ungeeignet:

Das Netzwerk ist langsam.

Besser:

Die Antwortzeit zum Gateway liegt normalerweise unter 5 ms. Aktuell werden zwischen 80 und 150 ms sowie Paketverluste von etwa 12 Prozent gemessen.

Den Umfang bestimmen

Der Umfang hilft bei der Eingrenzung.

Zu prüfen ist beispielsweise:

Beispiel:

Eine Anwendung startet bei einem Benutzer nicht.

Prüfung:

Damit liegt die Ursache wahrscheinlich eher im Benutzerkonto oder Benutzerprofil als im Gerät.

Den Normalzustand kennen

Für die Diagnose muss bekannt sein, was normalerweise geschehen sollte.

Beispiel:

Nach Eingabe der Zugangsdaten sollte innerhalb weniger Sekunden die Startseite erscheinen. Stattdessen bleibt der Ladebildschirm dauerhaft sichtbar.

Diese Beschreibung ist aussagekräftiger als:

Anmeldung funktioniert nicht.

Hilfreiche Fragen:

Änderungen berücksichtigen

Viele Incidents treten nach Änderungen auf.

Zu prüfen sind beispielsweise:

Eine wichtige Diagnosefrage lautet:

Was hat sich kurz vor Beginn des Fehlers verändert?

Ein zeitlicher Zusammenhang beweist jedoch noch keine Ursache.

Der Change muss fachlich überprüft werden.

Bekannte Incidents und Fehler prüfen

Vor einer aufwendigen Analyse sollte geprüft werden:

Dadurch lassen sich doppelte Analysen vermeiden.

Monitoring verwenden

Monitoring kann wichtige Hinweise liefern.

Typische Messwerte:

Monitoring zeigt jedoch häufig nur ein Symptom.

Beispiel:

CPU-Auslastung 100 Prozent

Dies beweist noch nicht, welcher Prozess oder welche Ursache verantwortlich ist.

Logs gezielt auswerten

Logs können zeigen:

Bei der Auswertung sollte geprüft werden:

Nicht jede rote Fehlermeldung ist für den aktuellen Incident relevant.

Reproduzierbarkeit prüfen

Ein reproduzierbarer Fehler lässt sich leichter eingrenzen.

Zu dokumentieren sind:

Beispiel:

  1. Anwendung öffnen
  2. Auftrag auswählen
  3. „PDF exportieren“ anklicken
  4. Anwendung beendet sich ohne Meldung

Zusatz:

Vom Einfachen zum Komplexen

Eine sinnvolle Praxisreihenfolge kann sein:

  1. Meldung und Auswirkungen verstehen
  2. bekannte Störungen prüfen
  3. offensichtliche Voraussetzungen prüfen
  4. Änderungen vergleichen
  5. Monitoring und Logs auswerten
  6. Fehlerbereich eingrenzen
  7. Hypothesen testen
  8. Spezialisten einbinden

Dies ist keine feste ITIL-Vorgabe.

Es verhindert jedoch, dass sofort mit besonders aufwendigen oder riskanten Maßnahmen begonnen wird.

Ausschlussverfahren

Beim Ausschlussverfahren werden mögliche Fehlerbereiche systematisch geprüft.

Beispiel:

VPN-Verbindung funktioniert nicht.

Prüfung Ergebnis
Internetverbindung vorhanden ja
DNS-Auflösung funktioniert ja
VPN-Gateway erreichbar ja
Benutzerkonto aktiv ja
MFA erfolgreich ja
Client-Zertifikat gültig nein

Damit wurde der Fehler auf das Zertifikat eingegrenzt.

Merke

Jeder Test sollte eine konkrete Hypothese bestätigen oder verwerfen.

Hypothesen dokumentieren

Eine gute Arbeitsnotiz kann folgendermaßen aufgebaut sein:

Hypothese

DNS-Auflösung ist fehlerhaft.

Test

Interne und externe Namensauflösung mit dem vorgesehenen DNS-Server geprüft.

Ergebnis

Name wird korrekt aufgelöst.

Schlussfolgerung

Hypothese verworfen.

Dadurch muss die nächste bearbeitende Person denselben Test nicht wiederholen.

Nur kontrollierte Maßnahmen durchführen

Während der Diagnose sollten nicht mehrere Änderungen gleichzeitig vorgenommen werden.

Ungeeignet:

Wenn der Service anschließend funktioniert, ist nicht erkennbar, welche Maßnahme wirksam war.

Besser:

  1. Maßnahme planen
  2. Risiko bewerten
  3. Maßnahme durchführen
  4. Ergebnis prüfen
  5. dokumentieren
  6. erst danach nächsten Schritt festlegen

Produktive Änderungen müssen entsprechend den Regeln des Change Enablement durchgeführt werden.

Neustarts bewusst einsetzen

Ein Neustart kann ein sinnvoller Workaround sein.

Er darf jedoch nicht reflexartig verwendet werden.

Vorher sollte geprüft werden:

... (Fortsetzung wegen Nachrichtenlängenlimit erforderlich)

3. Service Desk, Support und operative Servicearbeit

3.7 Ownership, hierarchische Eskalation und Major Incidents (Teil 1/2)

Kurz erklärt

Jeder Incident muss jederzeit einen eindeutig verantwortlichen Bearbeiter oder eine verantwortliche Gruppe besitzen.

ITIL bezeichnet dies als Ownership.

Ownership bedeutet nicht zwingend, dass diese Person den Fehler selbst behebt. Sie trägt jedoch die Verantwortung dafür, dass der Incident aktiv verfolgt, koordiniert und bis zum Abschluss begleitet wird.

Was bedeutet Ownership?

Ownership beantwortet die Frage:

Wer kümmert sich aktuell um diesen Incident?

Der Owner sorgt dafür, dass:

Ownership bleibt bestehen – auch wenn andere Teams beteiligt werden.

Ownership ist nicht gleich Bearbeitung

Ein häufiger Irrtum:

Wer gerade technisch arbeitet, ist automatisch für den gesamten Incident verantwortlich.

Das stimmt nicht.

Beispiel:

Der Service Desk erstellt ein Ticket und eskaliert es an das Netzwerkteam.

Während das Netzwerkteam analysiert, kann der Service Desk weiterhin Owner bleiben und:

Der technische Bearbeiter führt also eine konkrete Aufgabe aus.

Der Owner sorgt dafür, dass der Incident insgesamt gesteuert wird.

Zuständigkeit, Bearbeitung und Ownership unterscheiden

Begriff Bedeutung
Ownership Verantwortung für den gesamten Incident bis zum Abschluss
Bearbeitung Durchführung aktueller technischer oder organisatorischer Maßnahmen
Zuständigkeit fachliche Verantwortung für einen bestimmten Service, Bereich oder eine Komponente
Kommunikationsverantwortung Verantwortung für Statusmeldungen an Benutzer und Stakeholder
Entscheidungsverantwortung Befugnis, Prioritäten, Ressourcen oder Vorgehen festzulegen

Mehrere Personen oder Teams können gleichzeitig an einem Incident arbeiten.

Der Owner sollte jedoch eindeutig festgelegt sein.

Warum Ownership wichtig ist

Ohne klaren Owner entstehen häufig:

Typische Aussage:

Ich dachte, das andere Team kümmert sich darum.

Genau solche Situationen soll Ownership verhindern.

Aufgaben des Owners

Der Owner überwacht den gesamten Incident.

Typische Aufgaben:

Der Owner muss nicht jede technische Aufgabe selbst durchführen.

Er muss aber sicherstellen, dass der Incident nicht stehen bleibt.

Ownership während einer funktionalen Eskalation

Auch nach einer funktionalen Eskalation bleibt Ownership bestehen.

Beispiel:

Benutzer
    ↓
Service Desk (Owner)
    ↓
Netzwerkteam
    ↓
Hersteller

Das Netzwerkteam untersucht den Fehler.

Der Service Desk sorgt weiterhin dafür, dass:

Eine Eskalation bedeutet also nicht automatisch, dass die Gesamtverantwortung verschwindet.

Ownership übertragen

In manchen Organisationen kann Ownership wechseln.

Beispiele:

Dabei sollte immer dokumentiert werden:

Eine Übergabe ist nur dann sinnvoll, wenn die neue Verantwortung eindeutig akzeptiert wurde.

Ein Ticket darf niemals besitzerlos sein

Ein Incident ohne Owner ist eines der größten Risiken im Support.

Jeder Incident sollte jederzeit erkennen lassen:

Merke

Ein zugewiesenes Ticket ist nicht automatisch ein aktiv gesteuerter Incident.

Funktionale und hierarchische Eskalation unterscheiden

Diese beiden Begriffe werden häufig verwechselt.

Funktionale Eskalation Hierarchische Eskalation
fehlendes Fachwissen oder fehlende Berechtigung Management-Unterstützung oder Entscheidung erforderlich
Spezialisten notwendig Priorisierung, Ressourcen oder Risikoentscheidung notwendig
technischer Fokus organisatorischer oder geschäftlicher Fokus
Beispiel: Netzwerkteam einbinden Beispiel: Service Owner oder Management informieren
Ziel: richtige Fähigkeit einbinden Ziel: Hindernisse, Risiken oder Entscheidungen klären

Funktionale Eskalation

Die funktionale Eskalation wurde bereits in 3.6 Erstdiagnose, Lösung und funktionale Eskalation behandelt.

Beispiele:

Ziel:

Die richtigen Spezialisten bearbeiten den Incident.

Eine funktionale Eskalation ist keine Schuldzuweisung.

Sie bedeutet nur, dass zusätzliche Fähigkeiten, Werkzeuge oder Berechtigungen benötigt werden.

Hierarchische Eskalation

Bei einer hierarchischen Eskalation wird nicht primär weiteres Fachwissen benötigt.

Benötigt werden beispielsweise:

Beispiele:

Wann sollte eskaliert werden?

Nicht erst, wenn:

Sondern bereits dann, wenn erkennbar wird:

Merke

Gute Eskalation ist rechtzeitig, begründet und handlungsorientiert.

Eskalation bedeutet keine Schuld

Eine Eskalation ist keine Kritik an einzelnen Mitarbeitern.

Sie dient dazu:

Ungeeignet:

Wir eskalieren, weil das Team es nicht schafft.

Besser:

Wir eskalieren, weil die Zielzeit gefährdet ist und zusätzliche Entscheidungskompetenz benötigt wird.

Kommunikationseskalation

Manchmal funktioniert die technische Bearbeitung, aber die Kommunikation reicht nicht aus.

Beispiele:

Auch hierfür kann eine Eskalation notwendig sein.

Die technische Lösung und die Kommunikation müssen beide gesteuert werden.

Major Incident

Ein Major Incident ist ein besonders schwerwiegender Incident.

Er besitzt normalerweise:

ITIL schreibt keine universelle feste Definition vor.

Jede Organisation muss eigene Kriterien festlegen.

Mögliche Kriterien für einen Major Incident

Beispiele:

Die Kriterien sollten dokumentiert und regelmäßig überprüft werden.

Major Incident ist nicht automatisch P1

Viele Organisationen setzen:

P1 = Major Incident

Dies ist jedoch keine allgemeine ITIL-Vorgabe.

Ein P1-Incident kann ein Major Incident sein.

Er muss es aber nicht in jeder Organisation automatisch sein.

P1 Major Incident
beschreibt häufig die höchste operative Priorität beschreibt einen besonders schwerwiegenden Incident mit besonderer Koordination
steuert Zielzeiten und Bearbeitungsreihenfolge aktiviert zusätzliche Rollen, Kommunikation und Steuerung
kann durch normale Supportstruktur bearbeitet werden benötigt häufig besondere Koordination
wird meist aus Auswirkung und Dringlichkeit bestimmt kann zusätzliche Kriterien enthalten

Merke

Priorität und Major-Incident-Status sollten bewusst unterschieden oder eindeutig gemeinsam definiert werden.

Ziele eines Major-Incident-Verfahrens

Bei normalen Incidents liegt der Fokus häufig auf der technischen Wiederherstellung.

Bei Major Incidents kommen zusätzliche Aufgaben hinzu:

Das Ziel bleibt die Wiederherstellung des Services.

Der Weg dorthin benötigt jedoch mehr Steuerung.

Major Incident Manager

Viele Organisationen benennen für Major Incidents einen eigenen Major Incident Manager.

Diese Person repariert normalerweise nichts selbst.

Typische Aufgaben:

Der Major Incident Manager sorgt dafür, dass Spezialisten arbeiten können, ohne die Gesamtkoordination nebenbei leisten zu müssen.

Typischer Ablauf eines Major Incidents

Incident erkannt
        ↓
erste Bewertung
        ↓
Major-Incident-Kriterien prüfen
        ↓
Major Incident bestätigen oder ablehnen
        ↓
Owner und Major Incident Manager festlegen
        ↓
Fachteams und Lieferanten einbinden
        ↓
Kommunikation starten
        ↓
Workaround oder Wiederherstellung umsetzen
        ↓
Service stabilisieren
        ↓
Abschluss und Nachbereitung

Nicht jede Organisation verwendet exakt diesen Ablauf.

Entscheidend ist eine klare Koordination.

Sofortmaßnahmen bei Major Incidents

Zu Beginn sollte schnell geklärt werden:

Erst danach beginnt die tiefere technische Analyse.

Rollen bei Major Incidents

Typische Rollen können sein:

Nicht jede Organisation benötigt alle Rollen.

Wichtig ist, dass Zuständigkeiten und Entscheidungswege bekannt sind.

War Room

Bei kritischen Incidents wird häufig ein gemeinsamer Kommunikationskanal eingerichtet.

Beispiele:

Vorteile:

Ein War Room benötigt klare Regeln.

Sonst entsteht schnell Unübersichtlichkeit.

Regeln im War Room

Sinnvolle Regeln:

Ungeeignet:

Alle diskutieren gleichzeitig technische Vermutungen ohne Dokumentation.

Besser:

Hypothesen werden gesammelt, priorisiert, getestet und mit Ergebnis dokumentiert.

Kommunikation wird wichtiger

Je größer der Incident, desto wichtiger wird regelmäßige Kommunikation.

Stakeholder möchten wissen:

Auch wenn noch keine Lösung vorliegt, ist eine Statusmeldung sinnvoll.

Beispiel:

Die Ursache ist noch nicht bestätigt. Netzwerk- und Identitätsdienste werden geprüft. Ein sicherer Workaround ist derzeit nicht verfügbar. Die nächste Statusmeldung erfolgt um 11:30 Uhr.

Statusintervalle

Für kritische Incidents sollten Statusintervalle festgelegt werden.

Beispiel:

Die konkreten Zeiten legt die Organisation selbst fest.

Nicht geeignet:

Wir melden uns, wenn alles wieder funktioniert.

Besser:

Die nächste Statusmeldung erfolgt spätestens um 10:30 Uhr, auch wenn bis dahin noch keine vollständige Lösung vorliegt.

Single Point of Communication

Bei großen Incidents sollte möglichst eine abgestimmte Kommunikationsquelle verwendet werden.

Beispiele:

Dadurch werden widersprüchliche Aussagen vermieden.

Technische Detaildiskussionen gehören nicht ungefiltert in Benutzerkommunikation.

Stakeholder zielgruppengerecht informieren

Zielgruppe Benötigte Informationen
Benutzer Auswirkungen, Workaround, nächste Statusmeldung
Service Desk freigegebene Formulierung, bekannte Symptome, Ticketverknüpfung
technische Teams Logs, Hypothesen, Messergebnisse, Maßnahmen
Management geschäftliche Auswirkungen, Risiken, erwartete Entscheidungen
Kunden Serviceverfügbarkeit, Einschränkungen, nächstes Update
Lieferanten technische Nachweise, Versionen, Priorität, gewünschte Unterstützung
Informationssicherheit Sicherheitsbezug, Beweise, Risiko, Schutzmaßnahmen

Nicht jeder Empfänger benötigt dieselbe Detailtiefe.

Ressourcen koordinieren

Bei Major Incidents arbeiten oft mehrere Teams gleichzeitig.

Der Major Incident Manager oder Incident Coordinator achtet darauf, dass:

Dokumentation während eines Major Incidents

Auch unter Zeitdruck muss dokumentiert werden.

Mindestens festhalten:

Diese Informationen werden später benötigt für:

Nach der Wiederherstellung

Mit der technischen Wiederherstellung endet die Arbeit häufig noch nicht.

Es folgen möglicherweise:

Major Incident Review

Nach Abschluss sollte geprüft werden:

Ziel ist Lernen, nicht Schuldzuweisung.

Lessons Learned

Typische Ergebnisse können sein:

Lessons Learned haben nur dann Wert, wenn daraus konkrete Maßnahmen entstehen.

Problem Management einbeziehen

Ein Major Incident führt häufig zu einem Problem Record.

Dadurch kann später untersucht werden:

Incident Management stellt den Service wieder her.

Problem Management sorgt dafür, dass die Ursache verstanden und zukünftige Wiederholungen möglichst vermieden werden.

Typische Fehler

Fehler 1: Kein eindeutiger Owner

Niemand verfolgt den Incident Ende zu Ende.

Fehler 2: Ownership geht bei Eskalation verloren

Das Ticket wird weitergegeben, aber niemand koordiniert mehr.

Fehler 3: Zu späte Eskalation

Erst nach SLA-Verletzung oder Managementbeschwerde wird reagiert.

Fehler 4: Funktionale und hierarchische Eskalation werden verwechselt

Es wird ein Spezialist benötigt, aber Management informiert – oder umgekehrt.

Fehler 5: Major Incident wird nicht aktiviert

Kriterien sind unklar oder niemand entscheidet.

Fehler 6: Jeder kommuniziert etwas anderes

Es fehlt ein Single Point of Communication.

Fehler 7: Technische Vermutungen werden als Fakten veröffentlicht

Vertrauen geht verloren, wenn Aussagen später korrigiert werden müssen.

Fehler 8: Keine Dokumentation während der Störung

Nachbereitung und Ursachenanalyse werden erschwert.

Fehler 9: War Room ohne Koordination

Viele Personen diskutieren, aber wenige Maßnahmen werden entschieden.

Fehler 10: Nach Wiederherstellung keine Nachbereitung

Die Organisation lernt nicht aus dem Incident.

Fehler 11: Lessons Learned bleiben unverbindlich

Verbesserungen werden beschlossen, aber nicht umgesetzt.

Fehler 12: Problem Management wird nicht gestartet

Die eigentliche Ursache bleibt unbekannt oder unbehandelt.

Praxisbeispiel

08:15 Uhr

Mehrere Standorte melden Ausfälle der zentralen Anmeldung.

08:20 Uhr

Incident wird als Major Incident bewertet.

08:25 Uhr

Major Incident Manager übernimmt die Koordination.

08:30 Uhr

Erste Statusmeldung wird veröffentlicht.

08:40 Uhr

Identity-, Netzwerk- und Cloud-Team arbeiten gemeinsam im War Room.

09:05 Uhr

Ein sicherer Workaround ist verfügbar.

09:40 Uhr

Service ist technisch wiederhergestellt.

10:00 Uhr

Abschlussmeldung wird veröffentlicht.

10:30 Uhr

Review-Termin und Problem Record werden erstellt.

Checkliste Ownership

Checkliste Eskalation

Checkliste Major Incident

Bedeutung für Fachinformatiker für Systemintegration

Auch wenn Fachinformatiker nicht immer selbst Incident Manager sind, sind sie häufig maßgeblich an der technischen Analyse und Wiederherstellung beteiligt.

Im Arbeitsalltag bedeutet das:

Gerade bei größeren Störungen entscheidet oft nicht nur technisches Wissen, sondern auch Zusammenarbeit, Ownership und Koordination über die Dauer des Ausfalls.

Zusammenfassung

Incident übernehmen
↓
Owner eindeutig festlegen
↓
Bearbeitung koordinieren
↓
falls notwendig funktional oder hierarchisch eskalieren
↓
Major Incident aktivieren, wenn Kriterien erfüllt sind
↓
Rollen, Kommunikation und Statusintervalle festlegen
↓
Teams und Lieferanten koordinieren
↓
Service wiederherstellen
↓
Ergebnis stabilisieren und kommunizieren
↓
Review durchführen
↓
Erkenntnisse in Problem Management, Knowledge Management und Continual Improvement übernehmen

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Ausgestaltung muss an:

angepasst werden.

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

3. Service Desk, Support und operative Servicearbeit

3.7 Ownership, hierarchische Eskalation und Major Incidents (Teil 2/2)

Major-Incident-Prozess

Nach der Einstufung als Major Incident beginnt eine koordinierte Bearbeitung.

Ein möglicher Ablauf:

Major Incident erkannt
        │
        ▼
Owner bestätigen
        │
        ▼
Major Incident Manager benennen
        │
        ▼
Fachteams koordinieren
        │
        ▼
Stakeholder informieren
        │
        ▼
Workaround oder Wiederherstellung
        │
        ▼
Service stabilisieren
        │
        ▼
Incident schließen
        │
        ▼
Problem Management starten

Nicht jede Organisation verwendet exakt diesen Ablauf. Entscheidend ist eine klare Koordination.

War Room

Bei kritischen Incidents wird häufig ein gemeinsamer Kommunikationskanal eingerichtet.

Beispiele:

Alle beteiligten Teams arbeiten dort gemeinsam.

Vorteile:

Kommunikationsregeln

Während eines Major Incidents sollte Kommunikation:

Ungeeignet:

Wir glauben, dass wahrscheinlich vielleicht die Firewall schuld ist.

Besser:

Die Ursache wird aktuell untersucht. Firewall und Netzwerk werden geprüft. Nächste Statusmeldung um 11:30 Uhr.

Stakeholder

Nicht jeder benötigt dieselben Informationen.

Stakeholder Benötigte Informationen
Benutzer Auswirkungen und Workaround
Service Desk aktueller Status
Management Geschäftsrisiken
Kunden Serviceverfügbarkeit
Technik Diagnoseinformationen
Lieferanten technische Details

Informationen sollten zielgruppengerecht formuliert werden.

Single Point of Communication

Bei großen Incidents sollte möglichst nur eine abgestimmte Kommunikationsquelle verwendet werden.

Dadurch werden widersprüchliche Aussagen vermieden.

Beispiele:

Ressourcen koordinieren

Nicht jedes Team sollte unabhängig arbeiten.

Der Major Incident Manager achtet darauf, dass:

Dokumentation

Auch unter Zeitdruck muss dokumentiert werden.

Mindestens festhalten:

Diese Informationen werden später benötigt für:

Nach der Wiederherstellung

Mit der Wiederherstellung endet der Major Incident nicht vollständig.

Es folgen häufig:

Major Incident Review

Nach Abschluss sollte überprüft werden:

Ziel ist Lernen – nicht Schuldzuweisung.

Lessons Learned

Typische Ergebnisse:

Problem Management einbeziehen

Ein Major Incident endet häufig mit einem neuen Problem Record.

Dadurch kann später untersucht werden:

Häufige Fehler

Fehler 1

Kein eindeutiger Owner.

Fehler 2

Mehrere Teams arbeiten ohne Koordination.

Fehler 3

Benutzer erhalten keine Statusinformationen.

Fehler 4

Zu späte Eskalation.

Fehler 5

Jeder kommuniziert etwas anderes.

Fehler 6

Techniker diskutieren Vermutungen als Fakten.

Fehler 7

Keine Dokumentation während des Incidents.

Fehler 8

Nach Wiederherstellung erfolgt keine Nachbereitung.

Fehler 9

Lessons Learned werden nicht umgesetzt.

Fehler 10

Problem Management wird nicht gestartet.

Praxisbeispiel

08:15 Uhr

Mehrere Standorte melden Ausfälle.

08:20 Uhr

Major Incident aktiviert.

08:25 Uhr

Incident Manager übernimmt Koordination.

08:30 Uhr

Statusmeldung veröffentlicht.

08:40 Uhr

Netzwerk-, Server- und Cloud-Team arbeiten gemeinsam.

09:05 Uhr

Workaround verfügbar.

09:40 Uhr

Service vollständig wiederhergestellt.

10:30 Uhr

Review-Termin geplant.

Checkliste Ownership

Checkliste Eskalation

Checkliste Major Incident

Bedeutung für Fachinformatiker für Systemintegration

Auch wenn Fachinformatiker nicht die Rolle des Incident Managers übernehmen, sind sie häufig maßgeblich an der technischen Analyse beteiligt.

Im Arbeitsalltag bedeutet das:

Gerade bei größeren Störungen entscheidet oft die Zusammenarbeit über die Dauer des Ausfalls.

Zusammenfassung

Incident übernehmen
↓
Owner festlegen
↓
Bearbeitung koordinieren
↓
falls notwendig funktional oder hierarchisch eskalieren
↓
Major Incident aktivieren, wenn Kriterien erfüllt
↓
Kommunikation sicherstellen
↓
Service wiederherstellen
↓
Review durchführen
↓
Erkenntnisse in Problem Management und Continual Improvement übernehmen

Verwandte Seiten

Quellen

Framework-Stand: ITIL Version 5
Fachlicher Stand: August 2026

3. Service Desk, Support und operative Servicearbeit

3.8 Self-Service, Wissensnutzung und Automatisierung (Teil 1/2)

Kurz erklärt

Ziel moderner Serviceorganisationen ist es nicht, möglichst viele Tickets zu bearbeiten, sondern Benutzern schnell und effizient zu helfen.

ITIL fördert deshalb:

Dadurch können viele Anfragen ohne direkten Kontakt zum Service Desk gelöst werden.

Was bedeutet Self-Service?

Self-Service ermöglicht Benutzern, bestimmte Aufgaben selbstständig durchzuführen.

Beispiele:

Dadurch werden Wartezeiten reduziert und der Service Desk entlastet.

Ziele des Self-Service

Ein gutes Self-Service-Portal soll:

Der Benutzer soll möglichst keine internen IT-Strukturen kennen müssen.

Vorteile

Für Benutzer:

Für die IT:

Grenzen des Self-Service

Nicht jede Anfrage eignet sich für Self-Service.

Beispiele:

In solchen Fällen bleibt der persönliche Support notwendig.

Serviceportal

Das Self-Service-Portal bildet häufig den zentralen Einstiegspunkt.

Typische Inhalte:

Servicekatalog

Ein Servicekatalog beschreibt, welche Leistungen die IT anbietet.

Beispiele:

Dadurch erkennen Benutzer schneller, welcher Service betroffen ist.

Standard Requests

Viele Service Requests lassen sich standardisieren.

Beispiele:

Diese Requests besitzen häufig:

Wissensmanagement

Wissen sollte dauerhaft verfügbar sein.

Nicht nur erfahrene Administratoren sollen Lösungen kennen.

Typische Wissensquellen:

Knowledge Base

Eine Knowledge Base enthält wiederverwendbare Lösungen.

Beispiele:

Gut gepflegte Knowledge-Artikel erhöhen die Lösungsquote erheblich.

Eigenschaften guter Artikel

Ein Artikel sollte:

Zielgruppen unterscheiden

Nicht jeder Artikel richtet sich an dieselben Leser.

Mögliche Zielgruppen:

Ein Benutzerartikel sollte keine internen Diagnoseschritte enthalten.

KCS (Knowledge-Centered Service)

Viele Organisationen orientieren sich an den Prinzipien von Knowledge-Centered Service (KCS).

Grundidee:

Wissen entsteht während der täglichen Bearbeitung.

Nicht erst Wochen später.

Typischer Ablauf:

Incident lösen
      │
      ▼
Lösung dokumentieren
      │
      ▼
Knowledge Base erweitern
      │
      ▼
Nächster Incident schneller lösbar

Wissen aktuell halten

Veraltete Artikel verursachen:

Knowledge-Artikel sollten regelmäßig überprüft werden.

Suche verbessern

Ein gutes Wissenssystem benötigt:

Benutzer suchen häufig nicht mit Fachbegriffen.

Beispiel:

Nicht:

SMTP Authentication Error

Sondern:

Outlook kann keine E-Mails senden.

Automatisierung

Automatisierung übernimmt wiederkehrende Aufgaben.

Beispiele:

Dadurch werden Fehler reduziert und Abläufe beschleunigt.

Vorteile der Automatisierung

Risiken

Automatisierung ersetzt keine Kontrolle.

Fehlerhafte Automatisierungen können:

Automatisierungen benötigen daher:

Runbooks

Runbooks beschreiben standardisierte Arbeitsabläufe.

Beispiele:

Sie sorgen für einheitliche Arbeitsweisen.

Merksätze

Self-Service ersetzt nicht den Service Desk.

Wissen ist nur dann wertvoll, wenn es aktuell bleibt.

Gute Dokumentation spart zukünftige Bearbeitungszeit.

Automatisierung unterstützt Menschen – sie ersetzt keine Verantwortung.

Jede gelöste Störung kann neues Wissen erzeugen.

3. Service Desk, Support und operative Servicearbeit

3.8 Self-Service, Wissensnutzung und Automatisierung (Teil 2/2)

Runbooks und Standardabläufe

Runbooks beschreiben wiederholbare Arbeitsabläufe.

Sie helfen dabei, Aufgaben einheitlich, sicher und nachvollziehbar durchzuführen.

Beispiele:

Ein gutes Runbook enthält:

Runbook und Knowledge-Artikel unterscheiden

Runbook Knowledge-Artikel
richtet sich häufig an IT-Mitarbeiter richtet sich je nach Inhalt an Benutzer oder IT
beschreibt interne Arbeitsabläufe beschreibt Lösungen, Erklärungen oder Anleitungen
enthält technische Prüfschritte kann auch einfache Benutzerhilfe enthalten
benötigt oft Berechtigungen kann öffentlich im Serviceportal stehen
dient der Standardisierung dient der Wiederverwendung von Wissen

Beide Formen unterstützen eine schnellere und einheitlichere Bearbeitung.

Standardisierung

Standardisierung bedeutet, wiederkehrende Aufgaben nach einem einheitlichen Muster auszuführen.

Beispiele:

Standardisierung reduziert:

Standardisierung ist keine Starrheit

Standardisierung bedeutet nicht, dass jede Situation gleich behandelt werden muss.

Sie schafft einen sicheren Normalweg.

Abweichungen bleiben möglich, sollten aber bewusst entschieden und dokumentiert werden.

Beispiel:

Ein Standard-Request für Softwareinstallation kann automatisch laufen.

Eine sicherheitskritische Spezialsoftware benötigt dagegen zusätzliche Prüfung und Freigabe.

Automatisierung sinnvoll einsetzen

Automatisierung sollte dort eingesetzt werden, wo Aufgaben:

Gute Kandidaten:

Weniger geeignet sind Aufgaben mit:

Automatisierung braucht Kontrolle

Eine Automatisierung ist nur dann hilfreich, wenn sie zuverlässig gesteuert wird.

Zu klären ist:

Merke

Automatisierung entfernt Arbeit nicht vollständig. Sie verlagert Arbeit in Design, Prüfung, Betrieb und Überwachung.

Risiken fehlerhafter Automatisierung

Fehlerhafte Automatisierungen können große Auswirkungen haben.

Beispiele:

Deshalb benötigen Automatisierungen:

Self-Service und Automatisierung kombinieren

Self-Service wird besonders wirksam, wenn Benutzeranfragen im Hintergrund automatisiert bearbeitet werden.

Beispiel:

Ein Benutzer beantragt Standardsoftware im Serviceportal.

Möglicher Ablauf:

Benutzer wählt Software im Portal
        ↓
Berechtigung und Genehmigung werden geprüft
        ↓
Softwarepaket wird automatisch zugewiesen
        ↓
Installation startet auf dem Gerät
        ↓
Benutzer erhält Statusmeldung
        ↓
Ticket wird automatisch dokumentiert

Dadurch muss der Service Desk nicht jeden Standardschritt manuell durchführen.

Genehmigungen einbauen

Nicht jede Anfrage darf sofort automatisiert erfüllt werden.

Beispiele für genehmigungspflichtige Requests:

Ein guter Workflow unterscheidet zwischen:

Self-Service muss benutzerfreundlich sein

Ein Self-Service-Portal bringt wenig, wenn Benutzer es nicht verstehen oder nicht finden.

Wichtig sind:

Benutzer sollten nicht wissen müssen, welches interne Team zuständig ist.

Ungeeignet:

Antrag für AD-Gruppenmitgliedschaft CN=APP-FIN-PRD-RW.

Besser:

Zugriff auf Finanzanwendung beantragen.

Gute Formulare

Ein Formular sollte genau die Informationen erfassen, die für die Bearbeitung notwendig sind.

Beispiele:

Zu viele Pflichtfelder führen dazu, dass Benutzer falsche Angaben machen oder den Service Desk direkt kontaktieren.

Zu wenige Pflichtfelder führen zu Rückfragen und Verzögerungen.

Status transparent machen

Benutzer sollten erkennen können:

Transparenz reduziert Rückfragen.

Beispiel:

Ihre Softwareanfrage wartet aktuell auf Genehmigung durch den Fachbereich. Nach Genehmigung startet die automatische Bereitstellung.

Wissensartikel aus Tickets erzeugen

Viele gute Knowledge-Artikel entstehen direkt aus realen Tickets.

Nach einer Lösung sollte geprüft werden:

Nicht jeder Incident benötigt einen neuen Artikel.

Aber häufige oder lehrreiche Fälle sollten nicht verloren gehen.

Qualität von Knowledge-Artikeln sichern

Knowledge-Artikel sollten regelmäßig geprüft werden.

Zu prüfen ist:

Veraltetes Wissen kann schädlicher sein als kein Wissen.

Feedback nutzen

Benutzer und Service-Desk-Mitarbeiter sollten Feedback geben können.

Beispiele:

Dieses Feedback sollte regelmäßig ausgewertet werden.

Kennzahlen

Mögliche Kennzahlen für Self-Service, Wissensnutzung und Automatisierung:

Bereich Mögliche Kennzahl
Self-Service Anteil der Anfragen über Portal
Knowledge Base Artikelaufrufe
Knowledge Base hilfreiche Bewertungen
Service Desk First Contact Resolution
Automatisierung automatisch erfüllte Requests
Automatisierung Fehlerquote automatisierter Abläufe
Service Requests durchschnittliche Erfüllungszeit
Benutzererfahrung Zufriedenheit nach Nutzung
Qualität Anzahl veralteter Artikel
Verbesserung reduzierte Wiederholungstickets

Kennzahlen sollten nicht nur Menge messen, sondern auch Qualität.

Problematische Kennzahlen

Nicht jede Kennzahl führt automatisch zu gutem Verhalten.

Beispiel:

Viele Knowledge-Artikel

Kann problematisch sein, wenn viele Artikel veraltet, doppelt oder unverständlich sind.

Besser:

Beispiel:

Viele automatisierte Tickets

Kann problematisch sein, wenn Automatisierungen Fehler erzeugen oder Benutzer nicht verstehen, was passiert.

Besser:

Zusammenspiel mit Incident Management

Self-Service und Knowledge Management unterstützen Incident Management.

Beispiele:

Dadurch kann der Service schneller wiederhergestellt werden.

Zusammenspiel mit Service Request Management

Viele Service Requests eignen sich besonders gut für Self-Service und Automatisierung.

Beispiele:

Wichtig ist, dass:

Zusammenspiel mit Change Enablement

Automatisierung und Self-Service können Changes auslösen.

Beispiele:

Solche Änderungen müssen entsprechend ihrem Risiko behandelt werden.

Nicht jede Automatisierung ist automatisch ein Standard-Change.

Die Organisation muss festlegen, welche Abläufe vorab geprüft und freigegeben sind.

Zusammenspiel mit Information Security Management

Self-Service und Automatisierung betreffen häufig Berechtigungen und Daten.

Deshalb müssen Sicherheitsanforderungen berücksichtigt werden.

Beispiele:

Benutzerfreundlichkeit darf nicht dazu führen, dass Sicherheitsregeln umgangen werden.

Typische Fehler

Fehler 1

Self-Service wird nur als Ticketformular verstanden.

Fehler 2

Benutzer müssen interne IT-Strukturen kennen.

Fehler 3

Knowledge-Artikel sind veraltet.

Fehler 4

Artikel sind zu technisch für Endbenutzer.

Fehler 5

Automatisierungen werden ohne ausreichende Tests produktiv genutzt.

Fehler 6

Automatisierungen besitzen zu viele Berechtigungen.

Fehler 7

Fehler in automatisierten Abläufen werden nicht überwacht.

Fehler 8

Runbooks existieren, werden aber nicht gepflegt.

Fehler 9

Self-Service ersetzt persönliche Hilfe auch dort, wo sie notwendig wäre.

Fehler 10

Benutzerfeedback wird nicht ausgewertet.

Fehler 11

Genehmigungen sind unklar oder zu langsam.

Fehler 12

Wissen bleibt bei Einzelpersonen statt in dokumentierten Systemen.

Praxisbeispiel: Passwort-Reset

Ausgangslage

Viele Benutzer rufen den Service Desk an, weil sie ihr Passwort vergessen haben.

Verbesserung

Ein Self-Service-Passwort-Reset wird eingeführt.

Wichtige Anforderungen

Nutzen

Praxisbeispiel: Softwareanforderung

Ausgangslage

Software wird per E-Mail angefordert.

Informationen fehlen häufig.

Genehmigungen sind unklar.

Verbesserung

Ein Serviceportal bietet standardisierte Softwareanfragen.

Ablauf

Software auswählen
        ↓
Kosten und Lizenz prüfen
        ↓
Genehmigung einholen
        ↓
Paket automatisch bereitstellen
        ↓
Benutzer informieren
        ↓
Ticket dokumentieren

Nutzen

Praxisbeispiel: Knowledge-Artikel aus Incident

Incident

Mehrere Benutzer melden, dass VPN nach einem Client-Update nicht startet.

Lösung

Der Service Desk findet eine sichere Reparaturmaßnahme.

Folgeaktivität

Ein interner Knowledge-Artikel wird erstellt.

Inhalt:

Nutzen

Der nächste gleichartige Incident kann schneller gelöst werden.

Checkliste Self-Service

Checkliste Knowledge Management

Checkliste Automatisierung

Bedeutung für Fachinformatiker für Systemintegration

Für Fachinformatiker ist dieses Thema besonders wichtig, weil viele praktische Verbesserungen direkt aus dem technischen Alltag entstehen.

Beispiele:

Gute technische Arbeit zeigt sich nicht nur darin, ein einzelnes Problem zu lösen.

Sie zeigt sich auch darin, dass derselbe Fehler künftig schneller, sicherer oder automatisch bearbeitet werden kann.

Zusammenfassung

Wiederkehrende Anfragen erkennen
↓
geeignete Self-Service-Möglichkeiten schaffen
↓
Wissen verständlich dokumentieren
↓
Standardabläufe definieren
↓
geeignete Schritte automatisieren
↓
Risiken, Berechtigungen und Monitoring berücksichtigen
↓
Benutzerfeedback auswerten
↓
Inhalte und Abläufe kontinuierlich verbessern

Merksätze

Self-Service ersetzt nicht den Service Desk, sondern erweitert die Servicefähigkeit.

Wissen muss auffindbar, verständlich und aktuell sein.

Automatisierung braucht klare Verantwortung.

Ein automatisierter Fehler bleibt ein Fehler.

Jede gelöste Störung kann zukünftiges Wissen erzeugen.

Gute Standardisierung schafft Freiraum für komplexe Aufgaben.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Ausgestaltung muss an:

angepasst werden.

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

3. Service Desk, Support und operative Servicearbeit

3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk

Kurz erklärt

Kennzahlen helfen dabei, die Arbeit des Service Desks sichtbar, bewertbar und verbesserbar zu machen.

Sie zeigen jedoch nicht automatisch, ob ein Service wirklich gut ist.

Entscheidend ist, Kennzahlen richtig zu interpretieren und mit Qualität, Benutzererfahrung und kontinuierlicher Verbesserung zu verbinden.

Warum Kennzahlen wichtig sind

Ohne Kennzahlen bleibt die Leistung eines Service Desks schwer bewertbar.

Kennzahlen helfen zu erkennen:

Kennzahlen sollen nicht nur kontrollieren.

Sie sollen helfen, bessere Entscheidungen zu treffen.

Kennzahlen sind kein Selbstzweck

Eine Kennzahl ist nur dann sinnvoll, wenn klar ist:

Beispiel:

Eine sehr kurze Bearbeitungszeit klingt gut.

Sie kann aber problematisch sein, wenn Tickets vorschnell geschlossen werden und Benutzer später erneut Kontakt aufnehmen müssen.

Merke

Eine gute Kennzahl unterstützt bessere Servicequalität.

Eine schlechte Kennzahl erzeugt falsches Verhalten.

Qualität im Service Desk

Qualität bedeutet nicht nur, dass Tickets schnell geschlossen werden.

Qualität bedeutet auch:

Ein Service Desk kann viele Tickets bearbeiten und trotzdem schlechte Qualität liefern.

Quantität und Qualität unterscheiden

Quantität Qualität
Anzahl der Tickets Vollständigkeit der Erfassung
Anzahl geschlossener Vorgänge tatsächliche Lösung aus Benutzersicht
durchschnittliche Bearbeitungszeit Verständlichkeit der Kommunikation
Anzahl Anrufe richtige Klassifizierung
Anzahl Eskalationen sinnvolle Eskalation mit ausreichendem Kontext

Beide Perspektiven sind wichtig.

Nur Mengenkennzahlen reichen nicht aus.

Typische Kennzahlen im Service Desk

Bereich Mögliche Kennzahl
Kontaktvolumen Anzahl der Kontakte pro Zeitraum
Kanäle Anteil Portal, Telefon, E-Mail, Chat
Reaktion Zeit bis zur ersten qualifizierten Rückmeldung
Lösung durchschnittliche Lösungszeit
Wiederherstellung Zeit bis zur Wiederherstellung des Service
First Contact Resolution Anteil beim ersten Kontakt gelöster Anliegen
Eskalation Anteil funktional eskalierter Tickets
Qualität Anteil vollständig dokumentierter Tickets
Benutzererfahrung Zufriedenheit nach Kontakt
Backlog Anzahl offener Tickets
Wiedereröffnung Anteil wiedergeöffneter Tickets
Self-Service Anteil selbst gelöster oder automatisierter Anfragen
Knowledge Nutzung und Bewertung von Wissensartikeln

Die konkrete Auswahl hängt von Organisation, Services und Zielsetzung ab.

Kontaktvolumen

Das Kontaktvolumen zeigt, wie viele Anfragen, Störungen oder Rückfragen eingehen.

Zu betrachten sind:

Ein hohes Kontaktvolumen bedeutet nicht automatisch schlechte Leistung.

Es kann auch bedeuten:

Kanäle auswerten

Kontaktkanäle können unterschiedliche Qualität und Kosten verursachen.

Beispiele:

Kanal Typische Stärke Typisches Risiko
Portal strukturierte Erfassung Benutzer finden Service nicht
Telefon schnelle Klärung schlechte Dokumentation möglich
E-Mail einfach zugänglich unstrukturierte Angaben
Chat schnelle Kurzklärung komplexe Fälle schwer dokumentierbar
Self-Service sofortige Hilfe ungeeignet bei komplexen Incidents

Die Organisation sollte prüfen, welche Kanäle für welche Anliegen geeignet sind.

Zeit bis zur ersten qualifizierten Rückmeldung

Diese Kennzahl misst, wie schnell der Benutzer eine verwertbare Rückmeldung erhält.

Eine qualifizierte Rückmeldung ist mehr als:

Ticket wurde erstellt.

Besser:

Wir haben den Incident aufgenommen. Betroffen ist der VPN-Zugriff. Erste Prüfungen laufen. Die nächste Rückmeldung erfolgt spätestens um 14:00 Uhr.

Diese Kennzahl hilft, gefühlte Untätigkeit zu vermeiden.

Lösungszeit und Wiederherstellungszeit unterscheiden

Kennzahl Bedeutung
Lösungszeit Zeit bis zur Bearbeitung oder zum Abschluss eines Vorgangs
Wiederherstellungszeit Zeit bis der betroffene Service wieder nutzbar ist
Bearbeitungszeit aktive Arbeitszeit am Vorgang
Wartezeit Zeit, in der auf Benutzer, Lieferanten, Genehmigung oder andere Abhängigkeiten gewartet wird

Diese Werte sollten nicht verwechselt werden.

Ein Incident kann technisch wiederhergestellt sein, obwohl die endgültige Ursache noch im Problem Management untersucht wird.

First Contact Resolution

Die First Contact Resolution (FCR) beschreibt den Anteil der Anliegen, die beim ersten Kontakt ausreichend gelöst werden.

Eine hohe FCR kann entstehen durch:

Aber Vorsicht:

Eine hohe FCR ist nicht automatisch gut, wenn Tickets voreilig geschlossen werden.

Zu prüfen ist deshalb auch:

SLA-Erfüllung

SLA-Erfüllung zeigt, ob vereinbarte Serviceziele eingehalten wurden.

Mögliche SLA-Ziele:

Wichtig:

SLA-Erfüllung sollte nicht nur formal betrachtet werden.

Beispiel:

Ein Ticket wurde innerhalb der Zielzeit geschlossen.

Wenn der Benutzer danach erneut melden muss, war die Serviceerfahrung trotzdem schlecht.

Backlog

Der Backlog zeigt offene Arbeit.

Zu betrachten sind:

Ein Backlog ist nicht automatisch schlecht.

Problematisch wird er, wenn:

Wiedereröffnungsquote

Die Wiedereröffnungsquote zeigt, wie oft geschlossene Tickets erneut geöffnet werden.

Mögliche Ursachen:

Eine hohe Wiedereröffnungsquote kann auf Qualitätsprobleme hinweisen.

Eskalationsquote

Die Eskalationsquote zeigt, wie häufig Tickets an andere Teams weitergegeben werden.

Eine hohe Eskalationsquote kann bedeuten:

Eine niedrige Eskalationsquote ist nicht automatisch gut.

Sie kann auch bedeuten, dass notwendige Eskalationen zu spät erfolgen.

Ticketqualität messen

Ticketqualität ist wichtig für Bearbeitung, Übergabe und spätere Auswertung.

Zu prüfen ist:

Eine gute Ticketdokumentation spart spätere Arbeitszeit.

Benutzerzufriedenheit

Benutzerzufriedenheit kann gemessen werden durch:

Wichtig ist, nicht nur eine Zahl zu betrachten.

Eine Bewertung sollte ergänzt werden durch:

Customer Satisfaction und Experience

Customer Satisfaction (CSAT) misst häufig die Zufriedenheit mit einem konkreten Kontakt.

Experience betrachtet breiter, wie Benutzer den Service insgesamt erleben.

Beispiel:

Ein einzelner Service-Desk-Kontakt war freundlich und schnell.

Trotzdem kann die Gesamterfahrung schlecht sein, wenn:

Self-Service-Kennzahlen

Mögliche Kennzahlen:

Nicht nur Nutzung zählt.

Wichtig ist auch, ob Benutzer tatsächlich zum Ziel kommen.

Knowledge-Management-Kennzahlen

Mögliche Kennzahlen:

Problematisch wäre, nur die Anzahl der Artikel zu messen.

Viele schlechte Artikel helfen weniger als wenige gute.

Automatisierungskennzahlen

Mögliche Kennzahlen:

Automatisierung muss nicht nur schnell sein.

Sie muss sicher, nachvollziehbar und zuverlässig sein.

Trendanalyse

Kennzahlen werden besonders wertvoll, wenn sie über längere Zeit betrachtet werden.

Beispiele:

Qualitätssicherung im Service Desk

Qualität kann geprüft werden durch:

Ziel ist nicht Bestrafung.

Ziel ist Lernen und Verbesserung.

Service Reviews

In Service Reviews werden Ergebnisse regelmäßig betrachtet.

Mögliche Inhalte:

Service Reviews verbinden operative Daten mit geschäftlicher Bewertung.

Dashboards

Dashboards helfen, wichtige Informationen schnell sichtbar zu machen.

Ein gutes Dashboard zeigt:

Ein Dashboard sollte nicht mit Kennzahlen überladen werden.

Besser wenige relevante Kennzahlen als viele unklare Zahlen.

Ampellogik vorsichtig verwenden

Ampeln sind einfach verständlich.

Beispiel:

Farbe Bedeutung
Grün Ziel erreicht
Gelb Ziel gefährdet
Rot Ziel verletzt oder Risiko hoch

Risiko:

Eine Ampel kann komplexe Situationen zu stark vereinfachen.

Deshalb sollten kritische Kennzahlen immer mit Kontext erklärt werden.

Fehlanreize vermeiden

Kennzahlen können unerwünschtes Verhalten erzeugen.

Beispiele:

Kennzahl Möglicher Fehlanreiz
viele geschlossene Tickets Tickets werden zu früh geschlossen
kurze Lösungszeit komplexe Fälle werden gemieden
niedrige Eskalationsquote Eskalation erfolgt zu spät
hohe FCR Fälle werden oberflächlich gelöst
hohe SLA-Erfüllung Prioritäten werden manipuliert
viele Knowledge-Artikel Qualität wird durch Menge ersetzt
viele Automatisierungen Risiken werden unterschätzt

Kennzahlen müssen deshalb regelmäßig kritisch überprüft werden.

Kennzahlen gemeinsam interpretieren

Einzelne Kennzahlen können täuschen.

Beispiel:

Dann ist die scheinbare Verbesserung wahrscheinlich keine echte Qualitätsverbesserung.

Besser ist eine kombinierte Betrachtung.

Beispiel:

Continual Improvement im Service Desk

Continual Improvement bedeutet, aus Daten, Feedback und Erfahrungen konkrete Verbesserungen abzuleiten.

Möglicher Ablauf:

Kennzahl oder Feedback erkennen
        ↓
Ursache oder Muster untersuchen
        ↓
Verbesserungsidee erfassen
        ↓
Nutzen und Aufwand bewerten
        ↓
Maßnahme umsetzen
        ↓
Wirkung messen
        ↓
Standard oder Wissen aktualisieren

Verbesserung ist damit ein dauerhafter Bestandteil des Service Desk.

Improvement Register

Verbesserungsideen sollten nicht verloren gehen.

Ein Improvement Register kann enthalten:

Das Werkzeug ist nicht entscheidend.

Wichtig ist, dass Verbesserungen nachvollziehbar erfasst und verfolgt werden.

Beispiele für Verbesserungen

Beobachtung mögliche Verbesserung
viele Passwort-Tickets Self-Service-Passwort-Reset einführen
häufige VPN-Probleme Knowledge-Artikel und Clientprüfung verbessern
viele Rückfragen bei Requests Formulare überarbeiten
hohe Wiedereröffnungsquote Abschlussprüfung verbessern
viele Eskalationen an Netzwerkteam Service Desk mit Runbook unterstützen
lange Wartezeiten auf Genehmigungen Genehmigungsworkflow vereinfachen
wiederkehrende Drucker-Incidents Problem Management einbinden
schlechte Suchtreffer Knowledge Base neu strukturieren

Qualitative Informationen berücksichtigen

Nicht alles Wichtige ist direkt messbar.

Wertvoll sind auch:

Zahlen zeigen oft, wo man suchen sollte.

Die Ursachen versteht man häufig erst durch qualitative Informationen.

Typische Fehler

Fehler 1

Es werden viele Kennzahlen gesammelt, aber keine Entscheidungen daraus abgeleitet.

Fehler 2

Nur Geschwindigkeit wird gemessen, nicht Qualität.

Fehler 3

Tickets werden schnell geschlossen, obwohl der Benutzer nicht arbeitsfähig ist.

Fehler 4

SLA-Erfüllung wird wichtiger genommen als tatsächliche Serviceerfahrung.

Fehler 5

Wiedereröffnungen werden ignoriert.

Fehler 6

Kennzahlen werden ohne Kontext verglichen.

Fehler 7

Teams werden für Zahlen verantwortlich gemacht, die sie nicht beeinflussen können.

Fehler 8

Benutzerfeedback wird gesammelt, aber nicht ausgewertet.

Fehler 9

Dashboards zeigen zu viele Werte ohne klare Aussage.

Fehler 10

Verbesserungsideen werden nicht verfolgt.

Fehler 11

Automatisierungserfolg wird nur an Geschwindigkeit gemessen.

Fehler 12

Knowledge Management wird nur nach Anzahl der Artikel bewertet.

Praxisbeispiel: Wiedereröffnete Tickets

Beobachtung

Die Lösungszeit im Service Desk ist gesunken.

Gleichzeitig steigt die Wiedereröffnungsquote.

Analyse

Viele Tickets werden geschlossen, nachdem eine Standardantwort versendet wurde.

Benutzer bestätigen jedoch nicht, dass das Problem gelöst ist.

Verbesserung

Erfolgskontrolle

Nach zwei Monaten sinkt die Wiedereröffnungsquote.

Die Benutzerzufriedenheit steigt.

Praxisbeispiel: Viele VPN-Incidents

Beobachtung

VPN-Incidents steigen nach einem Client-Update stark an.

Analyse

Mehrere Tickets enthalten ähnliche Symptome.

Ein Teil der Benutzer nutzt eine veraltete Konfiguration.

Verbesserung

Erfolgskontrolle

VPN-Tickets gehen deutlich zurück.

Der Service Desk kann verbleibende Fälle schneller lösen.

Praxisbeispiel: Serviceportal wird kaum genutzt

Beobachtung

Die meisten Anfragen kommen weiterhin per E-Mail.

Analyse

Benutzer finden die richtigen Services im Portal nicht.

Formulare enthalten unklare technische Begriffe.

Verbesserung

Erfolgskontrolle

Portalnutzung steigt.

Rückfragen pro Request sinken.

Checkliste Kennzahlen

Checkliste Ticketqualität

Checkliste Continual Improvement

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker liefern wichtige Daten für Kennzahlen und Verbesserungen.

Sie dokumentieren:

Dadurch können spätere Auswertungen überhaupt erst sinnvoll durchgeführt werden.

Gute technische Arbeit endet nicht mit der Reparatur.

Sie schafft auch verwertbares Wissen für bessere Services.

Zusammenfassung

Service-Desk-Arbeit erfassen
↓
sinnvolle Kennzahlen auswählen
↓
Qualität und Benutzererfahrung berücksichtigen
↓
Trends und Muster erkennen
↓
Verbesserungen ableiten
↓
Maßnahmen umsetzen
↓
Wirkung messen
↓
Wissen, Prozesse und Automatisierung verbessern

Merksätze

Nicht alles, was messbar ist, ist automatisch wichtig.

Geschwindigkeit ohne Qualität ist keine gute Serviceleistung.

Eine Kennzahl braucht immer Kontext.

Benutzerzufriedenheit und Serviceergebnis zählen genauso wie Ticketzahlen.

Gute Dokumentation macht Verbesserung erst möglich.

Continual Improvement beginnt oft mit sauber erfassten Tickets.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Ausgestaltung muss an:

angepasst werden.

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

4. Problem Management

4. Problem Management

4.1 Problem Management – Ziele, Begriffe und Abgrenzung

Kurz erklärt

Problem Management beschäftigt sich mit den Ursachen von Incidents.

Während Incident Management vor allem den Service schnell wiederherstellen soll, untersucht Problem Management, warum Incidents entstehen und wie Wiederholungen vermieden werden können.

Ziel ist nicht nur die schnelle Reparatur, sondern eine nachhaltige Verbesserung der Servicequalität.

Warum Problem Management wichtig ist

Viele Störungen treten nicht nur einmal auf.

Beispiele:

Wenn solche Fälle nur einzeln gelöst werden, bleibt die eigentliche Ursache bestehen.

Problem Management hilft dabei:

Incident und Problem unterscheiden

Incident Problem
ungeplante Unterbrechung oder Qualitätsminderung eines Service Ursache oder mögliche Ursache eines oder mehrerer Incidents
Fokus auf schnelle Wiederherstellung Fokus auf Ursachenverständnis und Vermeidung
kurzfristige Bearbeitung häufig längerfristige Analyse
Workaround kann ausreichen dauerhafte Lösung wird angestrebt
Ziel: Service wieder nutzbar machen Ziel: Wiederholung verhindern oder Auswirkungen reduzieren

Beispiel:

Incident

Benutzer können sich nicht am VPN anmelden.

Problem

Die Ursache liegt in einer fehlerhaften Zertifikatsverteilung, die regelmäßig zu abgelaufenen Client-Zertifikaten führt.

Problem Management ist nicht nur Fehlerbehebung

Problem Management bedeutet nicht nur:

Jemand sucht den technischen Fehler.

Es umfasst auch:

Ein Problem kann auch dann angelegt werden, wenn noch keine endgültige Ursache bekannt ist.

Problem, Known Error und Workaround unterscheiden

Begriff Bedeutung
Problem Ursache oder mögliche Ursache eines oder mehrerer Incidents
Known Error Problem mit bekannter Ursache oder bekanntem Fehlerzustand
Workaround vorübergehende Möglichkeit, Auswirkungen zu umgehen oder zu reduzieren
dauerhafte Lösung Maßnahme, die die Ursache beseitigt oder das Risiko nachhaltig reduziert

Beispiel:

Problem

Mehrere Clients verlieren nach dem Ruhezustand die VPN-Verbindung.

Known Error

Bestimmte Client-Version verursacht nach dem Ruhezustand fehlerhafte Tunnelzustände.

Workaround

VPN-Client vollständig beenden und neu starten.

Dauerhafte Lösung

Client-Version aktualisieren oder Konfiguration ändern.

Problem Management und Incident Management arbeiten zusammen

Incident Management liefert wichtige Informationen für Problem Management.

Dazu gehören:

Problem Management liefert zurück:

Dadurch werden zukünftige Incidents schneller lösbar oder vollständig vermieden.

Reaktives Problem Management

Reaktives Problem Management beginnt nach Incidents.

Auslöser können sein:

Beispiel:

Nach einem Major Incident wird untersucht, warum ein zentraler Dienst ausgefallen ist und warum Monitoring nicht früher gewarnt hat.

Proaktives Problem Management

Proaktives Problem Management sucht nach Problemen, bevor größere Incidents entstehen.

Informationsquellen können sein:

Beispiel:

Monitoring zeigt, dass Speicherplatz auf mehreren Servern regelmäßig kritisch wird.

Noch ist kein Ausfall eingetreten.

Problem Management kann trotzdem prüfen, warum Kapazitätsplanung, Alarmierung oder Bereinigung nicht ausreichen.

Typische Auslöser für einen Problem Record

Ein Problem Record kann sinnvoll sein, wenn:

Nicht jeder einzelne Incident benötigt automatisch einen Problem Record.

Problem Record

Ein Problem Record dokumentiert die Bearbeitung eines Problems.

Typische Inhalte:

Das konkrete Format hängt vom verwendeten ITSM-System und der Organisation ab.

Priorisierung von Problems

Problems sollten priorisiert werden.

Kriterien können sein:

Ein Problem mit wenigen Incidents kann trotzdem hohe Priorität besitzen, wenn es einen kritischen Service oder ein hohes Sicherheitsrisiko betrifft.

Problem Management und Change Enablement

Dauerhafte Lösungen erfordern häufig Änderungen.

Beispiele:

Solche Maßnahmen sollten nicht unkontrolliert umgesetzt werden.

Sie müssen entsprechend Risiko, Auswirkung und Organisationsregeln über Change Enablement gesteuert werden.

Problem Management und Knowledge Management

Problem Management erzeugt wertvolles Wissen.

Dieses Wissen sollte nutzbar gemacht werden für:

Beispiele:

Wissen darf nicht nur im Kopf einzelner Spezialisten bleiben.

Problem Management und Service Configuration Management

Für Ursachenanalysen sind Service- und CI-Informationen wichtig.

Hilfreich sind:

Ohne diese Informationen wird Ursachenanalyse oft langsam und ungenau.

Beispiel:

Mehrere Anwendungen fallen aus.

Erst durch die CI-Beziehungen wird erkennbar, dass alle vom gleichen Datenbankcluster abhängig sind.

Problem Management und Continual Improvement

Problem Management ist eng mit kontinuierlicher Verbesserung verbunden.

Aus Problems können entstehen:

Ein gelöstes Problem sollte deshalb nicht nur abgeschlossen werden.

Es sollte geprüft werden, welche Erkenntnisse für zukünftige Arbeit nutzbar sind.

Problem Management und Risiko

Nicht jede Ursache kann sofort beseitigt werden.

Manchmal ist eine dauerhafte Lösung:

Dann muss das verbleibende Risiko bewusst bewertet und dokumentiert werden.

Mögliche Maßnahmen:

Workaround als wichtiger Zwischenschritt

Ein Workaround ist keine endgültige Lösung, kann aber sehr wertvoll sein.

Er hilft dabei:

Ein Workaround sollte dokumentiert werden mit:

Dauerhafte Lösung

Eine dauerhafte Lösung soll die Ursache beseitigen oder das Risiko wesentlich reduzieren.

Beispiele:

Nicht jede dauerhafte Lösung ist rein technisch.

Auch Prozesse, Kommunikation und Verantwortlichkeiten können Ursachen sein.

Technische Ursache und organisatorische Ursache

Ein Problem kann mehrere Ursachenebenen besitzen.

Beispiel:

Ein Zertifikat läuft ab.

Technische Ursache

Zertifikat ist nicht mehr gültig.

Organisatorische Ursache

Es gab keinen verantwortlichen Owner für Zertifikatsüberwachung.

Prozessursache

Es gab keinen geregelten Ablauf für rechtzeitige Erneuerung.

Verbesserung

Monitoring, Verantwortlichkeit und Erneuerungsprozess werden eingeführt.

Merke

Die technische Ursache ist oft nur ein Teil der Gesamtursache.

Problem Management ist keine Schuldsuche

Problem Management soll nicht klären, wer schuld ist.

Ziel ist:

Eine Schuldzuweisung führt häufig dazu, dass Informationen zurückgehalten werden.

Eine lernorientierte Analyse führt zu besseren Ergebnissen.

Praxisbeispiel: Wiederkehrende VPN-Störungen

Ausgangslage

Mehrere Benutzer melden regelmäßig VPN-Abbrüche.

Incident Management stellt den Zugang jeweils durch Neustart des Clients wieder her.

Problem Management

Die Incidents werden gemeinsam ausgewertet.

Auffällig ist:

Ergebnis

Ein Known Error wird dokumentiert.

Ein Workaround wird für den Service Desk bereitgestellt.

Ein Change zur Aktualisierung des VPN-Clients wird geplant.

Praxisbeispiel: Druckerwarteschlange blockiert

Ausgangslage

Ein Etikettendrucker im Versand blockiert mehrfach pro Woche.

Incident Management entfernt jeweils den fehlerhaften Druckauftrag.

Problem Management

Die Analyse zeigt:

Dauerhafte Lösung

Treiber wird getestet und über Change Enablement aktualisiert.

Zusätzlich wird ein Knowledge-Artikel für den Service Desk erstellt.

Praxisbeispiel: Speicher läuft voll

Ausgangslage

Ein Server erzeugt regelmäßig Incidents wegen vollem Speicher.

Incident Management löscht temporäre Dateien.

Problem Management

Die Untersuchung zeigt:

Verbesserung

Typische Fehler

Fehler 1

Jeder Incident wird einzeln bearbeitet, ohne Muster zu erkennen.

Fehler 2

Problem Management wird erst nach sehr großen Störungen genutzt.

Fehler 3

Workarounds werden nicht dokumentiert.

Fehler 4

Known Errors bleiben nur einzelnen Spezialisten bekannt.

Fehler 5

Die technische Ursache wird gefunden, aber organisatorische Ursachen werden ignoriert.

Fehler 6

Dauerhafte Lösungen werden ohne Change-Bewertung umgesetzt.

Fehler 7

Problems werden eröffnet, aber nicht aktiv verfolgt.

Fehler 8

Priorisierung fehlt.

Fehler 9

Problem Management wird als Schuldsuche verstanden.

Fehler 10

Lessons Learned werden nicht in Knowledge, Monitoring oder Prozesse übernommen.

Checkliste Problem erfassen

Checkliste Problem bearbeiten

Checkliste Problem abschließen

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker für Systemintegration liefern häufig die wichtigsten technischen Informationen für Problem Management.

Dazu gehören:

Wichtig ist nicht nur, einen Incident schnell zu beheben.

Wichtig ist auch, wiederkehrende Ursachen zu erkennen und die Umgebung dauerhaft stabiler zu machen.

Zusammenfassung

Incidents treten auf
↓
Muster oder schwere Auswirkungen werden erkannt
↓
Problem Record wird erstellt
↓
Ursache oder mögliche Ursache wird untersucht
↓
Workaround wird dokumentiert
↓
Known Error wird bei Bedarf erfasst
↓
dauerhafte Lösung wird geplant
↓
Change, Knowledge und Improvement werden eingebunden
↓
zukünftige Incidents werden reduziert oder schneller lösbar

Merksätze

Incident Management stellt den Service wieder her.

Problem Management versteht und reduziert Ursachen.

Ein Workaround ist hilfreich, aber keine dauerhafte Lösung.

Ein Known Error muss nutzbar dokumentiert sein.

Problem Management ist Lernen, nicht Schuldsuche.

Gute Problem Records machen Services langfristig stabiler.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

4. Problem Management

4.2 Ursachenanalyse (Root Cause Analysis – RCA)

Kurz erklärt

Ursachenanalyse bedeutet, systematisch zu untersuchen, warum ein Incident oder Problem entstanden ist.

Ziel ist nicht, möglichst schnell einen Schuldigen zu finden.

Ziel ist, die tatsächlichen technischen, organisatorischen oder prozessualen Ursachen zu verstehen, damit Wiederholungen verhindert oder Auswirkungen reduziert werden können.

Warum Ursachenanalyse wichtig ist

Ohne Ursachenanalyse werden Incidents häufig nur kurzfristig behoben.

Beispiele:

Solche Maßnahmen können kurzfristig helfen.

Sie beantworten aber nicht die Frage:

Warum tritt der Fehler immer wieder auf?

Ursachenanalyse hilft dabei:

Incident-Lösung und Ursachenanalyse unterscheiden

Incident Management Problem Management / RCA
Service schnell wiederherstellen Ursache verstehen
kurzfristiger Fokus nachhaltiger Fokus
Workaround kann genügen dauerhafte Lösung wird vorbereitet
Ziel: Benutzer wieder arbeitsfähig machen Ziel: Wiederholung verhindern oder Risiko senken
Zeitdruck häufig hoch Analyse kann länger dauern

Beispiel:

Ein Webservice ist nicht erreichbar.

Incident Management

Ursachenanalyse

Merke

Eine schnelle Wiederherstellung ist wichtig.

Sie ersetzt aber keine Ursachenanalyse, wenn der Fehler wiederkehren kann.

Symptom, Ursache und Grundursache unterscheiden

Begriff Bedeutung Beispiel
Symptom sichtbares Fehlverhalten Benutzer kann sich nicht anmelden
direkte Ursache unmittelbarer technischer Auslöser Zertifikat ist abgelaufen
Grundursache tiefer liegende Ursache kein Prozess zur Zertifikatsüberwachung
beitragender Faktor Umstand, der den Fehler begünstigt Warnung wurde nicht an das richtige Team gesendet
Auswirkung Folge für Benutzer oder Geschäft Fachanwendung nicht nutzbar

Ein Problem besitzt häufig nicht nur eine Ursache.

Oft wirken mehrere Faktoren zusammen.

Beispiel:

Ein Server fällt aus, weil der Speicher voll ist.

Mögliche Ursachenebenen:

Nur die Aussage „Speicher voll“ beschreibt noch nicht die vollständige Ursache.

Ursachenanalyse ist keine Schuldzuweisung

Ursachenanalyse soll nicht klären:

Wer hat den Fehler gemacht?

Sondern:

Welche Bedingungen haben dazu geführt, dass dieser Fehler entstehen oder unentdeckt bleiben konnte?

Eine schuldorientierte Kultur führt häufig dazu, dass:

Eine lernorientierte Analyse fragt stattdessen:

Grundprinzip einer guten Ursachenanalyse

Eine gute Ursachenanalyse ist:

Sie trennt:

Beobachtung und Hypothese trennen

Ungeeignet:

Die Firewall war schuld.

Besser:

Verbindungen zur Anwendung auf Port 443 schlugen vom Standort Süd fehl. Eine Firewall-Regel ist eine mögliche Ursache und wird geprüft.

Ungeeignet:

Der Benutzer hat etwas falsch gemacht.

Besser:

Der Fehler trat nach einer Änderung der Berechtigungsgruppe auf. Die Auswirkungen der Gruppenänderung werden geprüft.

Ungeeignet:

Das Update hat alles kaputt gemacht.

Besser:

Der Incident begann 20 Minuten nach dem Update. Ein Zusammenhang ist möglich, aber noch nicht bestätigt.

Merke

Zeitlicher Zusammenhang ist ein Hinweis.

Er ist noch kein Beweis.

Typischer Ablauf einer Ursachenanalyse

Ein möglicher Ablauf:

Problem beschreiben
        ↓
Fakten sammeln
        ↓
Zeitlinie erstellen
        ↓
Umfang und Auswirkungen bestimmen
        ↓
Hypothesen bilden
        ↓
Hypothesen prüfen
        ↓
Ursache und beitragende Faktoren bestimmen
        ↓
Workaround dokumentieren
        ↓
dauerhafte Lösung oder Verbesserungen ableiten
        ↓
Maßnahmen priorisieren und verfolgen

Nicht jede Organisation nutzt exakt diesen Ablauf.

Wichtig ist, dass die Analyse nachvollziehbar bleibt.

Problem klar beschreiben

Am Anfang sollte das Problem eindeutig beschrieben werden.

Eine gute Problembeschreibung enthält:

Ungeeignet:

VPN macht Probleme.

Besser:

Seit dem Client-Update vom 12.08.2026 verlieren mehrere Benutzer nach dem Ruhezustand die VPN-Verbindung. Betroffen sind Windows-Notebooks mit Client-Version 5.8. Der Workaround ist ein vollständiger Neustart des VPN-Clients.

Fakten sammeln

Geeignete Informationsquellen:

Wichtig ist, die Daten nicht nur zu sammeln, sondern sie fachlich einzuordnen.

Nicht jede Logmeldung ist relevant.

Nicht jeder Benutzerbericht beschreibt die technische Ursache.

Zeitlinie erstellen

Eine Zeitlinie hilft, Ereignisse in die richtige Reihenfolge zu bringen.

Beispiel:

Zeitpunkt Ereignis
08:00 Uhr Deployment abgeschlossen
08:20 Uhr erste Fehlermeldung im Monitoring
08:25 Uhr erste Benutzermeldung
08:35 Uhr Incident als P1 bewertet
08:45 Uhr Rollback vorbereitet
09:05 Uhr Workaround aktiv
09:30 Uhr Service stabil

Eine Zeitlinie hilft bei Fragen wie:

Umfang bestimmen

Zu prüfen ist:

Der Umfang hilft, mögliche Ursachen einzugrenzen.

Beispiel:

Wenn nur ein Standort betroffen ist, sind zentrale Anwendung und Benutzerkonto möglicherweise weniger wahrscheinlich als Standortnetz, Routing, DNS oder lokale Firewall.

Änderungen prüfen

Viele Probleme stehen im Zusammenhang mit Änderungen.

Zu prüfen sind:

Wichtig:

Ein Change ist nicht automatisch die Ursache.

Er ist zunächst ein relevanter Untersuchungsgegenstand.

5-Why-Methode

Die 5-Why-Methode fragt mehrfach „Warum?“, um von einem Symptom zu tiefer liegenden Ursachen zu gelangen.

Beispiel:

Problem

Ein Webservice war nicht erreichbar.

Warum 1

Warum war der Webservice nicht erreichbar?

Der Dienst war abgestürzt.

Warum 2

Warum ist der Dienst abgestürzt?

Der Speicher war vollständig belegt.

Warum 3

Warum war der Speicher vollständig belegt?

Logdateien sind stark angewachsen.

Warum 4

Warum wurden Logdateien nicht bereinigt?

Die Logrotation war fehlerhaft konfiguriert.

Warum 5

Warum wurde die fehlerhafte Logrotation nicht erkannt?

Es gab kein Monitoring für Logwachstum und keine regelmäßige Prüfung.

Mögliche Maßnahmen:

Grenzen der 5-Why-Methode

Die 5-Why-Methode ist einfach und nützlich.

Sie hat aber Grenzen.

Risiken:

Deshalb sollte sie bei komplexen Incidents mit anderen Methoden kombiniert werden.

Ishikawa-Diagramm

Das Ishikawa-Diagramm wird auch Ursache-Wirkungs-Diagramm oder Fischgräten-Diagramm genannt.

Es hilft, mögliche Ursachen nach Kategorien zu sortieren.

Mögliche Kategorien in der IT:

Beispiel:

Problem:

Wiederkehrende VPN-Abbrüche.

Mögliche Ursachen:

Kategorie Beispiele
Mensch Benutzer versetzen Notebook in Ruhezustand
Prozess Clientupdates werden nicht getestet
Technik fehlerhafte VPN-Client-Version
Umgebung instabile WLAN-Verbindung
Organisation kein Owner für Clientstandard
Lieferant bekannter Fehler in Version
Dokumentation Workaround fehlt in Knowledge Base
Sicherheit Zertifikatsprüfung schlägt fehl

Das Diagramm zwingt dazu, nicht nur eine technische Ursache zu betrachten.

Pareto-Analyse

Die Pareto-Analyse hilft, die wichtigsten Ursachen oder Kategorien zu erkennen.

Grundidee:

Ein kleiner Teil der Ursachen erzeugt häufig einen großen Teil der Auswirkungen.

Beispiel:

Kategorie Anzahl Incidents pro Monat
Passwort und MFA 120
VPN 75
Drucker 40
Softwareinstallation 25
Sonstiges 20

Wenn Passwort/MFA und VPN den größten Anteil ausmachen, können Verbesserungen dort besonders viel Wirkung entfalten.

Die Pareto-Analyse ersetzt keine Ursachenanalyse.

Sie hilft bei der Priorisierung.

Kepner-Tregoe-Ansatz

Ein strukturierter Ansatz kann sein, zu unterscheiden:

Beispiel:

Frage Antwort
Was ist betroffen? VPN-Verbindung nach Ruhezustand
Was ist nicht betroffen? VPN nach Neustart
Wo tritt es auf? Windows-Notebooks
Wo nicht? macOS-Geräte
Seit wann? seit Client-Version 5.8
Veränderung Clientupdate am Vortag

Diese Gegenüberstellung hilft, Hypothesen gezielt einzugrenzen.

Fehlerbaum und Abhängigkeiten

Bei komplexen Services kann eine Abhängigkeitsanalyse helfen.

Zu prüfen sind:

Beispiel:

Eine Anwendung ist nicht erreichbar.

Mögliche Abhängigkeiten:

Benutzer
    ↓
Netzwerk
    ↓
DNS
    ↓
Load Balancer
    ↓
Webserver
    ↓
Anwendung
    ↓
Datenbank
    ↓
Storage

Wenn mehrere Anwendungen betroffen sind, kann eine gemeinsame Abhängigkeit wahrscheinlicher sein.

Datenqualität beachten

Ursachenanalyse ist nur so gut wie die verfügbaren Daten.

Probleme entstehen durch:

Eine wichtige Verbesserung kann daher sein:

Die Datenbasis für zukünftige Analysen verbessern.

Korrelation und Kausalität unterscheiden

Nur weil zwei Ereignisse zeitlich zusammen auftreten, bedeutet das nicht, dass eines das andere verursacht hat.

Beispiel:

Ein Incident beginnt kurz nach einem Windows-Update.

Mögliche Schlussfolgerungen:

Deshalb müssen Hypothesen geprüft werden.

Hypothesen testen

Eine Hypothese sollte überprüfbar sein.

Beispiel:

Hypothese

VPN-Abbrüche entstehen durch Client-Version 5.8.

Test

Ergebnis

Wenn nur Version 5.8 betroffen ist und ein Downgrade den Fehler beseitigt, wird die Hypothese stärker.

Trotzdem muss geprüft werden, ob weitere Faktoren beteiligt sind.

Kontrollierte Tests

Tests sollten möglichst kontrolliert durchgeführt werden.

Wichtig:

Ungeeignet:

Wir ändern DNS, Firewall, Zertifikat und Clientversion gleichzeitig.

Besser:

Wir testen zuerst die Clientversion auf einem betroffenen Gerät und dokumentieren das Ergebnis.

RCA bei Major Incidents

Nach Major Incidents ist eine Ursachenanalyse besonders wichtig.

Zu betrachten sind nicht nur technische Ursachen.

Auch zu prüfen:

Ein Major Incident Review sollte nicht nur fragen:

Warum ist das System ausgefallen?

Sondern auch:

Warum waren die Auswirkungen so groß?

Technische Ursachen

Mögliche technische Ursachen:

Technische Ursachen sind oft sichtbar.

Sie sind aber nicht immer die tiefste Ursache.

Prozessuale Ursachen

Mögliche prozessuale Ursachen:

Prozessuale Ursachen erklären häufig, warum ein technischer Fehler nicht verhindert oder früher erkannt wurde.

Organisatorische Ursachen

Mögliche organisatorische Ursachen:

Diese Ursachen sind oft unangenehm, aber wichtig.

Wenn sie ignoriert werden, treten ähnliche Probleme wieder auf.

Menschliche Faktoren

Menschen machen Fehler.

Gute Ursachenanalyse fragt deshalb nicht nur:

Warum hat jemand falsch gehandelt?

Sondern:

Warum war dieser Fehler möglich oder wahrscheinlich?

Zu prüfen sind:

Ziel ist, Systeme und Prozesse robuster zu machen.

Beitragende Faktoren dokumentieren

Nicht jede Ursache ist allein verantwortlich.

Beispiel:

Ein Datenbankserver fällt aus.

Beitragende Faktoren:

Die Kombination führte zur Störung.

Deshalb sollten mehrere Faktoren dokumentiert werden.

Maßnahmen ableiten

Aus der Ursachenanalyse sollten konkrete Maßnahmen entstehen.

Gute Maßnahmen sind:

Beispiele:

Ursache Maßnahme
Zertifikatsablauf wurde nicht überwacht Monitoring für Zertifikatsgültigkeit einführen
Logrotation war fehlerhaft Konfiguration korrigieren und Test ergänzen
Workaround war unbekannt Knowledge-Artikel erstellen
Eskalation erfolgte zu spät Eskalationskriterien überarbeiten
Serviceabhängigkeit war unbekannt CMDB-Beziehung ergänzen
Lieferant reagierte zu langsam Lieferanteneskalationsweg prüfen

Maßnahmen priorisieren

Nicht jede Maßnahme kann sofort umgesetzt werden.

Zu bewerten sind:

Eine Maßnahme mit hoher Risikoreduktion kann wichtiger sein als eine einfache technische Optimierung.

Wirksamkeit prüfen

Nach Umsetzung einer Maßnahme sollte geprüft werden:

Ursachenanalyse ist erst dann wirklich abgeschlossen, wenn die Verbesserung überprüft wurde oder ein verbleibendes Risiko bewusst akzeptiert ist.

RCA-Ergebnis dokumentieren

Eine Abschlussdokumentation kann enthalten:

Die Dokumentation muss nicht übermäßig lang sein.

Sie muss nachvollziehbar und nützlich sein.

Praxisbeispiel: Zertifikat abgelaufen

Incident

Benutzer können sich nicht an einer Anwendung anmelden.

Direkte Ursache

Das Zertifikat des Anmeldedienstes ist abgelaufen.

Grundursache

Es gab keinen Prozess zur rechtzeitigen Zertifikatserneuerung.

Beitragende Faktoren

Maßnahmen

Praxisbeispiel: Speicher läuft voll

Incident

Ein Dateiserver ist nicht mehr beschreibbar.

Workaround

Temporäre Dateien werden kontrolliert entfernt.

Ursachenanalyse

Maßnahmen

Praxisbeispiel: Wiederkehrende VPN-Abbrüche

Problem

Mehrere Benutzer verlieren nach dem Ruhezustand die VPN-Verbindung.

Fakten

Known Error

Client-Version 5.8 verursacht nach Ruhezustand fehlerhafte Tunnelzustände.

Workaround

VPN-Client vollständig beenden und neu starten.

Dauerhafte Lösung

Test und Ausrollen einer korrigierten Client-Version über Change Enablement.

Typische Fehler

Fehler 1

Symptom wird als Grundursache dokumentiert.

Fehler 2

Die erste Vermutung wird nicht mehr überprüft.

Fehler 3

Nur technische Ursachen werden betrachtet.

Fehler 4

Organisatorische und prozessuale Faktoren werden ignoriert.

Fehler 5

Zeitlicher Zusammenhang wird als Beweis behandelt.

Fehler 6

Mehrere Änderungen werden gleichzeitig getestet.

Fehler 7

RCA wird zur Schuldzuweisung verwendet.

Fehler 8

Workaround wird nicht dokumentiert.

Fehler 9

Maßnahmen werden beschlossen, aber nicht verfolgt.

Fehler 10

Lessons Learned werden nicht in Knowledge, Monitoring oder Prozesse übernommen.

Fehler 11

CMDB- und Serviceabhängigkeiten werden nicht genutzt.

Fehler 12

Wirksamkeit der Maßnahmen wird nicht geprüft.

Checkliste Ursachenanalyse starten

Checkliste Ursachen untersuchen

Checkliste Maßnahmen ableiten

Bedeutung für Fachinformatiker für Systemintegration

Für Fachinformatiker ist Ursachenanalyse eine zentrale Fähigkeit.

Im Arbeitsalltag bedeutet das:

Gute Ursachenanalyse macht Systeme nicht nur wieder lauffähig.

Sie macht sie langfristig stabiler.

Zusammenfassung

Symptom erkennen
↓
Problem beschreiben
↓
Fakten sammeln
↓
Zeitlinie und Umfang prüfen
↓
Hypothesen bilden
↓
Hypothesen testen
↓
technische, prozessuale und organisatorische Ursachen betrachten
↓
Workaround und Known Error dokumentieren
↓
dauerhafte Maßnahmen ableiten
↓
Wirksamkeit prüfen
↓
Wissen und Verbesserungen übernehmen

Merksätze

Die erste Erklärung ist nicht immer die richtige Ursache.

Ein Symptom ist noch keine Grundursache.

Ursachenanalyse ist Lernen, nicht Schuldzuweisung.

Viele IT-Probleme haben technische und organisatorische Ursachen.

Workarounds helfen kurzfristig, ersetzen aber keine dauerhafte Lösung.

Eine RCA ist nur wertvoll, wenn daraus konkrete Verbesserungen entstehen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

4. Problem Management

4.3 Workarounds und Known Errors

Kurz erklärt

Ein Workaround ist eine vorübergehende Möglichkeit, die Auswirkungen eines Incidents oder Problems zu umgehen oder zu reduzieren.

Ein Known Error ist ein bekanntes Problem oder ein bekannter Fehlerzustand, bei dem Ursache, Zusammenhang oder Fehlerbild ausreichend verstanden sind.

Workarounds und Known Errors helfen dabei, Incidents schneller zu bearbeiten, Benutzer arbeitsfähig zu halten und Wissen für den Service Desk nutzbar zu machen.

Warum Workarounds wichtig sind

Nicht jede Ursache kann sofort dauerhaft beseitigt werden.

Gründe können sein:

Ein Workaround kann in solchen Situationen helfen, die Auswirkungen zu begrenzen.

Beispiele:

Ein Workaround ist nicht automatisch schlecht.

Er wird problematisch, wenn er dauerhaft genutzt wird und die eigentliche Ursache nie bearbeitet wird.

Workaround und dauerhafte Lösung unterscheiden

Workaround Dauerhafte Lösung
reduziert oder umgeht Auswirkungen beseitigt Ursache oder Risiko nachhaltig
oft kurzfristig verfügbar benötigt häufig Analyse, Planung oder Change
kann Service schnell wieder nutzbar machen verhindert Wiederholung besser
Ursache kann bestehen bleiben Ursache wird behoben oder kontrolliert
muss dokumentiert und überwacht werden muss getestet und dauerhaft übernommen werden

Beispiel:

Ein VPN-Client verliert nach dem Ruhezustand die Verbindung.

Workaround

VPN-Client vollständig beenden und neu starten.

Dauerhafte Lösung

Fehlerhafte Client-Version aktualisieren oder Konfiguration korrigieren.

Was ist ein Known Error?

Ein Known Error ist ein Problem oder Fehlerzustand, der bekannt und ausreichend beschrieben ist.

Typische Merkmale:

Ein Known Error muss nicht bedeuten, dass bereits eine endgültige Lösung vorhanden ist.

Gerade deshalb ist die Dokumentation wichtig.

Problem, Known Error, Workaround und Lösung unterscheiden

Begriff Bedeutung
Problem Ursache oder mögliche Ursache eines oder mehrerer Incidents
Known Error bekanntes Problem oder bekannter Fehlerzustand mit dokumentiertem Wissen
Workaround vorübergehende Maßnahme zur Umgehung oder Reduzierung der Auswirkungen
dauerhafte Lösung Maßnahme zur Beseitigung der Ursache oder dauerhaften Risikoreduzierung

Beispiel:

Problem

Mehrere Benutzer verlieren regelmäßig die VPN-Verbindung.

Known Error

VPN-Client-Version 5.8 verursacht nach dem Ruhezustand fehlerhafte Tunnelzustände.

Workaround

VPN-Client vollständig beenden und neu starten.

Dauerhafte Lösung

Getestete Client-Version 5.9 über Change Enablement ausrollen.

Ein Workaround ist keine endgültige Lösung

Ein häufiger Fehler besteht darin, einen erfolgreichen Workaround als vollständige Lösung zu behandeln.

Beispiel:

Ein Dienst stürzt regelmäßig ab.

Der Service Desk startet den Dienst jedes Mal neu.

Dadurch ist der Service kurzfristig wieder verfügbar.

Die Ursache bleibt jedoch bestehen.

Mögliche offene Fragen:

Merke

Ein Workaround kann einen Incident lösen.

Er löst aber nicht automatisch das zugrunde liegende Problem.

Anforderungen an einen guten Workaround

Ein guter Workaround sollte:

Zu prüfen ist außerdem:

Ungeeignete Workarounds

Ein Workaround ist ungeeignet, wenn er:

Beispiel:

Benutzer sollen vertrauliche Dokumente über private E-Mail-Konten austauschen, weil der Dateiserver nicht erreichbar ist.

Das wäre technisch vielleicht möglich, aber organisatorisch und sicherheitlich ungeeignet.

Workaround dokumentieren

Ein Workaround sollte so dokumentiert sein, dass er wiederverwendbar ist.

Typische Inhalte:

Eine ungenaue Notiz reicht nicht aus.

Ungeeignet:

Client neu starten.

Besser:

VPN-Client vollständig beenden, prüfen ob der Prozess beendet ist, Client neu starten und erneut verbinden. Gilt nur für Windows-Notebooks mit Client-Version 5.8 nach Ruhezustand. Wenn Verbindung weiterhin fehlschlägt, an Netzwerkteam eskalieren.

Known Error dokumentieren

Ein Known Error sollte mindestens enthalten:

Ziel ist, dass Service Desk und Fachgruppen schneller erkennen:

Known Error Database

Organisationen können bekannte Fehler in einer Known Error Database oder in einem vergleichbaren Wissenssystem dokumentieren.

Das Werkzeug ist nicht entscheidend.

Möglich sind beispielsweise:

Wichtig ist:

Lebenszyklus eines Known Errors

Ein möglicher Ablauf:

wiederkehrender Incident erkannt
        ↓
Problem Record erstellt
        ↓
Ursache oder Fehlerzustand analysiert
        ↓
Known Error dokumentiert
        ↓
Workaround bereitgestellt
        ↓
dauerhafte Lösung geplant
        ↓
Change umgesetzt
        ↓
Wirksamkeit geprüft
        ↓
Known Error aktualisiert oder geschlossen

Nicht jeder Known Error folgt exakt diesem Ablauf.

Entscheidend ist, dass der Status nachvollziehbar bleibt.

Known Error offen lassen oder schließen

Ein Known Error sollte nicht einfach vergessen werden.

Mögliche Status:

Ein Known Error kann offen bleiben, wenn:

Dann müssen Workaround und Risiko weiterhin bekannt bleiben.

Workaround im Incident Management

Incident Management nutzt Workarounds, um den Service schnell wiederherzustellen.

Beispiele:

Wichtig:

Der Incident kann abgeschlossen werden, wenn der Benutzer wieder arbeitsfähig ist und die Organisation dies so definiert.

Das Problem kann trotzdem offen bleiben.

Workaround im Problem Management

Problem Management verwendet Workarounds, um Auswirkungen zu reduzieren, während die Ursache weiter untersucht wird.

Aufgaben:

Ein Workaround ist oft ein wichtiger Zwischenschritt zwischen Analyse und dauerhafter Lösung.

Workaround und Change Enablement

Ein Workaround kann selbst eine Änderung enthalten.

Beispiele:

Solche Maßnahmen müssen nach Risiko bewertet werden.

Nicht jeder Workaround darf ohne Change-Steuerung durchgeführt werden.

Die Organisation muss festlegen, welche Workarounds:

Workaround und Knowledge Management

Workarounds sind nur dann wertvoll, wenn sie gefunden und verstanden werden.

Deshalb sollten sie in Knowledge Management eingebunden werden.

Zu klären ist:

Ein Workaround, der nur in einem alten Ticket steht, hilft beim nächsten Incident kaum.

Workaround und Service Desk

Der Service Desk benötigt klare Informationen:

Beispiel:

Wenn Benutzer nach Ruhezustand keine VPN-Verbindung herstellen können und Client-Version 5.8 verwendet wird, Workaround aus Artikel KB-023 anwenden. Bei anderer Version oder Fehlermeldung an Netzwerkteam eskalieren.

Workaround und Benutzerkommunikation

Benutzer sollten verständlich informiert werden.

Wichtig ist:

Beispiel:

Für diesen Fehler gibt es aktuell eine sichere Zwischenlösung. Bitte starten Sie den VPN-Client vollständig neu und verbinden Sie sich anschließend erneut. Die Ursache wird weiter untersucht. Eine dauerhafte Korrektur ist in Vorbereitung.

Ungeeignet:

Das ist ein bekannter Bug, machen Sie einfach Neustart.

Risiken dauerhaft genutzter Workarounds

Wenn Workarounds dauerhaft genutzt werden, entstehen Risiken:

Ein Workaround sollte deshalb regelmäßig überprüft werden.

Fragen:

Known Error und Risikoakzeptanz

Nicht jeder Known Error wird sofort beseitigt.

Beispiel:

Ein selten auftretender Fehler betrifft eine alte Anwendung.

Der Workaround funktioniert zuverlässig.

Eine dauerhafte Lösung wäre sehr teuer und riskant.

Die Organisation kann entscheiden, das Risiko vorerst zu akzeptieren.

Dann sollte dokumentiert werden:

Known Error bei Lieferantenfehlern

Ein Known Error kann auch durch einen Hersteller oder Lieferanten bestätigt werden.

Beispiele:

Zu dokumentieren ist:

Auch wenn ein Lieferant verantwortlich ist, bleibt die interne Serviceverantwortung bestehen.

Known Error und Major Incident

Nach einem Major Incident kann ein Known Error entstehen.

Beispiel:

Ein zentraler Dienst fällt wegen einer bestimmten Datenbankversion aus.

Der Service wurde wiederhergestellt.

Die dauerhafte Korrektur benötigt aber ein geplantes Upgrade.

Bis dahin wird ein Known Error dokumentiert mit:

Dadurch kann bei Wiederholung schneller reagiert werden.

Beispiel: VPN-Client

Symptom

Benutzer verlieren nach dem Ruhezustand die VPN-Verbindung.

Problem

Mehrere Incidents mit gleichem Muster.

Known Error

VPN-Client-Version 5.8 verursacht nach Ruhezustand fehlerhafte Tunnelzustände.

Workaround

Client vollständig beenden und neu starten.

Dauerhafte Lösung

Version 5.9 testen und ausrollen.

Knowledge

Service Desk erhält einen Artikel mit Prüfschritten, Workaround und Eskalationskriterien.

Beispiel: Druckerwarteschlange

Symptom

Etiketten werden nicht gedruckt.

Problem

Druckwarteschlange blockiert regelmäßig durch bestimmte PDF-Dateien.

Known Error

Der aktuell installierte Druckertreiber verarbeitet bestimmte PDF-Formate fehlerhaft.

Workaround

Fehlerhaften Auftrag entfernen und Datei über alternative Druckoption ausgeben.

Dauerhafte Lösung

Treiberupdate testen und über Change Enablement ausrollen.

Beispiel: Zertifikat

Symptom

Anmeldung an Fachanwendung schlägt fehl.

Problem

Zertifikat des Anmeldedienstes ist abgelaufen.

Known Error

Zertifikatsablauf wird nicht überwacht und kann zu Anmeldeausfällen führen.

Workaround

Kein vollwertiger Workaround verfügbar.

Dauerhafte Lösung

Zertifikat erneuern, Monitoring einführen, Owner festlegen und Runbook erstellen.

Merke

Nicht jeder Known Error besitzt einen geeigneten Workaround.

Beispiel: Speicher läuft voll

Symptom

Server kann keine neuen Daten schreiben.

Problem

Logdateien wachsen unkontrolliert.

Known Error

Logrotation ist fehlerhaft konfiguriert.

Workaround

Temporäre Bereinigung nach Runbook durchführen.

Dauerhafte Lösung

Logrotation korrigieren, Monitoring-Grenzen anpassen und Verantwortlichkeit festlegen.

Typische Fehler

Fehler 1

Workaround wird als dauerhafte Lösung behandelt.

Fehler 2

Known Error wird nicht dokumentiert.

Fehler 3

Workaround steht nur in einem einzelnen Ticket.

Fehler 4

Service Desk kennt den Workaround nicht.

Fehler 5

Benutzer erhalten unsichere oder unklare Anweisungen.

Fehler 6

Workaround umgeht Sicherheitsregeln.

Fehler 7

Risiken und Einschränkungen werden nicht genannt.

Fehler 8

Known Errors bleiben dauerhaft offen, ohne Neubewertung.

Fehler 9

Dauerhafte Lösung wird nicht geplant oder verfolgt.

Fehler 10

Lieferantenfehler werden nicht intern dokumentiert.

Fehler 11

Workaround wird nicht getestet.

Fehler 12

Nach Umsetzung der dauerhaften Lösung wird der Knowledge-Artikel nicht aktualisiert.

Checkliste Workaround erstellen

Checkliste Known Error dokumentieren

Checkliste Workaround im Betrieb nutzen

Checkliste Known Error schließen

Bedeutung für Fachinformatiker für Systemintegration

Für Fachinformatiker ist der saubere Umgang mit Workarounds und Known Errors besonders wichtig.

Im Arbeitsalltag bedeutet das:

Ein guter Workaround spart Zeit.

Ein gut dokumentierter Known Error verhindert doppelte Analyse.

Eine dauerhafte Lösung verbessert den Service nachhaltig.

Zusammenfassung

Incident oder wiederkehrendes Fehlerbild erkennen
↓
Problem oder mögliche Ursache untersuchen
↓
Known Error dokumentieren
↓
sicheren Workaround bereitstellen
↓
Service Desk und Benutzer angemessen informieren
↓
dauerhafte Lösung planen
↓
Change bei Bedarf durchführen
↓
Wirksamkeit prüfen
↓
Known Error und Knowledge aktualisieren oder schließen

Merksätze

Ein Workaround ist hilfreich, aber nicht automatisch eine Lösung.

Ein Known Error muss auffindbar und verständlich dokumentiert sein.

Nicht jeder Known Error besitzt einen sicheren Workaround.

Workarounds dürfen Sicherheitsregeln nicht aushebeln.

Dauerhaft genutzte Workarounds sind ein Hinweis auf ungelöste Probleme.

Gute Known-Error-Dokumentation macht zukünftige Incidents schneller lösbar.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

4. Problem Management

4.4 Trendanalyse und proaktives Problem Management

Kurz erklärt

Trendanalyse und proaktives Problem Management helfen dabei, wiederkehrende Muster frühzeitig zu erkennen.

Ziel ist es, Problems nicht erst nach großen Störungen zu bearbeiten, sondern mögliche Ursachen und Risiken bereits vorher sichtbar zu machen.

Dadurch können Incidents reduziert, Auswirkungen begrenzt und Services langfristig stabiler betrieben werden.

Warum Trendanalyse wichtig ist

Ein einzelner Incident wirkt oft wie ein isolierter Fehler.

Erst durch die Betrachtung vieler Vorgänge wird sichtbar, ob ein Muster besteht.

Beispiele:

Trendanalyse hilft dabei, solche Muster zu erkennen und daraus Verbesserungen abzuleiten.

Reaktives und proaktives Problem Management unterscheiden

Reaktives Problem Management Proaktives Problem Management
beginnt nach Incidents sucht nach Risiken und Mustern vor größeren Incidents
reagiert auf Störungen verhindert oder reduziert zukünftige Störungen
nutzt Incident-Daten nach einem Ereignis nutzt Trends, Monitoring, Reviews und Erfahrungswerte
häufig nach Major Incidents häufig durch regelmäßige Analyse
Ziel: Ursache verstehen Ziel: Risiken frühzeitig erkennen

Beide Formen sind wichtig.

Reaktives Problem Management lernt aus bereits eingetretenen Incidents.

Proaktives Problem Management versucht, zukünftige Incidents zu vermeiden.

Was ist eine Trendanalyse?

Trendanalyse bedeutet, Daten über einen Zeitraum zu betrachten und Muster zu erkennen.

Mögliche Fragen:

Eine Trendanalyse betrachtet nicht nur einzelne Tickets, sondern Zusammenhänge.

Mögliche Datenquellen

Geeignete Quellen für Trendanalysen:

Je besser die Datenqualität, desto aussagekräftiger die Analyse.

Typische Muster

Muster Mögliche Bedeutung
viele gleiche Incidents wiederkehrendes Problem
steigende Ticketzahlen wachsendes Risiko oder schlechter Service
gleiche Symptome nach Changes mögliche Change-Ursache
hohe Wiedereröffnungsquote unvollständige Lösung
viele Eskalationen an ein Team fehlendes Wissen im Service Desk
häufige Workarounds dauerhafte Ursache nicht beseitigt
viele Suchanfragen ohne Treffer fehlende Knowledge-Artikel
häufige Störung an einem Standort lokales Infrastrukturproblem
wiederkehrende Speicherwarnungen Kapazitäts- oder Monitoringproblem

Trendanalyse im Service Desk

Der Service Desk ist eine besonders wichtige Quelle für Trends.

Dort entstehen täglich Informationen über:

Wenn diese Informationen nur in einzelnen Tickets bleiben, gehen wichtige Verbesserungsmöglichkeiten verloren.

Zeitliche Muster erkennen

Incidents können sich zeitlich häufen.

Beispiele:

Solche Muster helfen bei der Ursachenfindung.

Beispiel:

Wenn ein Speicherbereich jeden Montagmorgen voll ist, kann ein Wochenendjob oder eine fehlende Bereinigung beteiligt sein.

Servicebezogene Muster erkennen

Zu prüfen ist:

Ein Service mit wenigen, aber sehr kritischen Incidents kann wichtiger sein als ein Service mit vielen kleinen Standardanfragen.

Standortbezogene Muster erkennen

Standortbezogene Trends können Hinweise liefern auf:

Beispiel:

Wenn nur ein Standort häufig VPN-Abbrüche meldet, muss nicht der VPN-Service selbst die Hauptursache sein.

Möglicherweise liegt das Problem bei lokaler Internetanbindung, Firewall, WLAN oder Routing.

Benutzergruppen und Rollen betrachten

Manchmal treten Incidents vor allem bei bestimmten Benutzergruppen auf.

Beispiele:

Solche Muster können auf fehlende Schulung, unklare Prozesse oder technische Sonderanforderungen hinweisen.

Change-bezogene Muster erkennen

Viele Problems entstehen im Zusammenhang mit Änderungen.

Zu prüfen ist:

Trenddaten können zeigen, ob Change Enablement verbessert werden muss.

Monitoringdaten proaktiv nutzen

Monitoring zeigt nicht nur akute Störungen.

Es kann auch zukünftige Risiken sichtbar machen.

Beispiele:

Solche Signale können ein Problem anzeigen, bevor Benutzer betroffen sind.

Kapazitätstrends

Kapazitätstrends helfen zu erkennen, ob Ressourcen bald nicht mehr ausreichen.

Zu betrachten sind:

Beispiel:

Wenn ein Dateiserver jeden Monat um 12 Prozent wächst, kann bereits vor einem Ausfall geplant werden, wie Kapazität erweitert oder Daten bereinigt werden.

Known Errors auswerten

Known Errors sollten regelmäßig überprüft werden.

Fragen:

Ein Known Error darf nicht dauerhaft unbeachtet bleiben.

Workaround-Nutzung als Warnsignal

Wenn ein Workaround sehr häufig genutzt wird, ist das ein Hinweis auf ein ungelöstes Problem.

Beispiel:

Der Service Desk startet jede Woche denselben Dienst neu.

Der Workaround funktioniert kurzfristig.

Trotzdem zeigt die Häufigkeit, dass eine dauerhafte Lösung notwendig ist.

Zu prüfen ist:

Knowledge-Base-Daten nutzen

Die Knowledge Base liefert Hinweise auf wiederkehrende Themen.

Mögliche Signale:

Daraus können Verbesserungen entstehen:

Benutzerfeedback auswerten

Benutzerfeedback kann Trends sichtbar machen, die in technischen Daten nicht sofort erkennbar sind.

Beispiele:

Qualitative Rückmeldungen ergänzen Kennzahlen.

Lieferanteninformationen einbeziehen

Auch Lieferanten können wichtige Hinweise liefern.

Beispiele:

Ein wiederkehrender interner Incident kann mit einem bekannten Herstellerfehler zusammenhängen.

Sicherheitsmeldungen als Problem-Auslöser

Nicht jede Sicherheitsmeldung ist ein Incident.

Manche Sicherheitsmeldungen weisen auf ein Problem oder Risiko hin.

Beispiele:

Proaktives Problem Management kann helfen, solche Risiken strukturiert zu bearbeiten.

Trend, Problem und Verbesserung verbinden

Ein Trend allein ist noch keine Lösung.

Ein sinnvoller Ablauf:

Daten sammeln
        ↓
Muster erkennen
        ↓
Trend bewerten
        ↓
Problem Record erstellen
        ↓
Ursache oder Risiko untersuchen
        ↓
Workaround oder Schutzmaßnahme bereitstellen
        ↓
dauerhafte Verbesserung planen
        ↓
Wirkung messen

Dadurch wird aus Beobachtung eine steuerbare Verbesserung.

Wann aus einem Trend ein Problem Record entsteht

Ein Problem Record kann sinnvoll sein, wenn:

Nicht jede Auffälligkeit benötigt sofort einen Problem Record.

Priorisierung proaktiver Problems

Proaktive Problems konkurrieren mit anderen Aufgaben.

Kriterien zur Priorisierung:

Ein Problem ohne aktuellen Ausfall kann trotzdem hohe Priorität besitzen, wenn ein schwerer Ausfall absehbar ist.

Beispiel: Speichertrend

Beobachtung

Monitoring zeigt, dass ein Dateiserver jeden Monat stark wächst.

Trend

Bei gleicher Entwicklung ist der Speicher in sechs Wochen voll.

Proaktives Problem Management

Nutzen

Ein zukünftiger Ausfall wird verhindert.

Beispiel: Häufige Passwort- und MFA-Tickets

Beobachtung

Ein großer Anteil der Service-Desk-Kontakte betrifft Passwort und MFA.

Analyse

Viele Benutzer kennen den Self-Service-Passwort-Reset nicht.

MFA-Anleitungen sind veraltet.

Verbesserung

Nutzen

Weniger Standardkontakte und schnellere Hilfe für Benutzer.

Beispiel: VPN-Incidents nach Clientupdate

Beobachtung

Nach einem Clientupdate steigen VPN-Incidents deutlich an.

Analyse

Betroffen sind nur Windows-Notebooks mit einer bestimmten Version.

Problem Record

Ein Problem wird eröffnet, um Ursache, Workaround und dauerhafte Lösung zu verfolgen.

Maßnahmen

Beispiel: Eskalationen an Netzwerkteam steigen

Beobachtung

Immer mehr Tickets werden vom Service Desk an das Netzwerkteam eskaliert.

Analyse

Viele Eskalationen betreffen einfache DNS- und VPN-Prüfungen.

Verbesserung

Nutzen

Weniger unnötige Eskalationen und schnellere Bearbeitung.

Typische Fehler

Fehler 1

Trends werden nicht ausgewertet, obwohl Daten vorhanden sind.

Fehler 2

Einzelne Incidents werden gelöst, aber Muster bleiben unbeachtet.

Fehler 3

Nur technische Kennzahlen werden betrachtet.

Fehler 4

Benutzerfeedback wird ignoriert.

Fehler 5

Monitoring wird nur für Alarmierung genutzt, nicht für proaktive Analyse.

Fehler 6

Known Errors bleiben offen, ohne Häufigkeit und Risiko neu zu bewerten.

Fehler 7

Fehler 8

Proaktive Problems werden immer niedriger priorisiert als akute Tickets.

Fehler 9

Datenqualität ist schlecht, wird aber nicht verbessert.

Fehler 10

Verbesserungsmaßnahmen werden nicht auf Wirksamkeit geprüft.

Fehler 11

Lieferantenhinweise und bekannte Herstellerfehler werden nicht berücksichtigt.

Fehler 12

Trendanalysen werden nur einmalig durchgeführt statt regelmäßig.

Checkliste Trendanalyse

Checkliste proaktives Problem Management

Checkliste Datenqualität

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker erkennen Trends häufig direkt im technischen Alltag.

Beispiele:

Wichtig ist, solche Beobachtungen nicht nur mündlich weiterzugeben, sondern nachvollziehbar zu dokumentieren.

So können daraus Problems, Known Errors, Changes oder Verbesserungen entstehen.

Zusammenfassung

Incidents, Monitoring und Feedback auswerten
↓
Muster und Trends erkennen
↓
Risiko und Auswirkung bewerten
↓
Problem Record bei Bedarf erstellen
↓
Ursache oder mögliche Ursache untersuchen
↓
Workaround oder Schutzmaßnahme bereitstellen
↓
dauerhafte Verbesserung planen
↓
Change, Knowledge oder Continual Improvement einbinden
↓
Wirkung messen und Datenqualität verbessern

Merksätze

Proaktives Problem Management beginnt, bevor der große Ausfall eintritt.

Monitoring ist nicht nur Alarmierung, sondern auch Frühwarnsystem.

Häufig genutzte Workarounds sind ein Hinweis auf ungelöste Problems.

Gute Datenqualität ist die Grundlage guter Trendanalyse.

Ein erkannter Trend ist erst wertvoll, wenn daraus eine konkrete Verbesserung entsteht.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

4. Problem Management

4.5 Problem Management im Zusammenspiel mit Incident, Change und Knowledge Management

Kurz erklärt

Problem Management arbeitet nicht isoliert.

Es ist eng verbunden mit Incident Management, Change Enablement, Knowledge Management, Service Configuration Management und Continual Improvement.

Nur wenn diese Practices zusammenarbeiten, können Incidents schnell bearbeitet, Ursachen verstanden, dauerhafte Lösungen umgesetzt und Wissen für zukünftige Fälle nutzbar gemacht werden.

Warum das Zusammenspiel wichtig ist

Ein Problem entsteht häufig aus wiederkehrenden oder schwerwiegenden Incidents.

Die dauerhafte Lösung benötigt oft einen Change.

Der Service Desk benötigt Workarounds und Known Errors aus dem Knowledge Management.

Service Configuration Management liefert Informationen über betroffene Systeme und Abhängigkeiten.

Continual Improvement sorgt dafür, dass Erkenntnisse nicht verloren gehen.

Ohne dieses Zusammenspiel entstehen typische Schwächen:

Überblick über das Zusammenspiel

Incident tritt auf
        ↓
Incident Management stellt Service wieder her
        ↓
wiederkehrendes Muster oder schwere Auswirkung wird erkannt
        ↓
Problem Management untersucht Ursache
        ↓
Workaround oder Known Error wird dokumentiert
        ↓
Knowledge Management stellt Wissen bereit
        ↓
dauerhafte Lösung wird vorbereitet
        ↓
Change Enablement steuert Umsetzung
        ↓
Service wird stabilisiert
        ↓
Continual Improvement übernimmt Erkenntnisse

Problem Management und Incident Management

Incident Management und Problem Management haben unterschiedliche Schwerpunkte.

Incident Management Problem Management
schnelle Wiederherstellung des Service Ursache verstehen und Wiederholung vermeiden
kurzfristiger Fokus nachhaltiger Fokus
einzelne Störung bearbeiten Muster und Ursachen untersuchen
Workaround kann genügen dauerhafte Lösung wird angestrebt
Benutzer schnell arbeitsfähig machen Service langfristig stabiler machen

Beide Practices ergänzen sich.

Incident Management liefert Daten und Erfahrungen.

Problem Management liefert Workarounds, Known Errors und dauerhafte Verbesserungen zurück.

Was Incident Management an Problem Management liefert

Wichtige Informationen aus Incidents:

Je besser Incidents dokumentiert sind, desto leichter kann Problem Management Muster erkennen.

Was Problem Management an Incident Management zurückliefert

Problem Management unterstützt Incident Management durch:

Dadurch kann der Service Desk zukünftige Incidents schneller erkennen und bearbeiten.

Beispiel:

Wenn ein VPN-Fehler als Known Error dokumentiert ist, muss der Service Desk nicht bei jedem neuen Ticket von vorn analysieren.

Wann ein Incident zu einem Problem führen kann

Ein Problem Record kann sinnvoll sein, wenn:

Nicht jeder Incident benötigt automatisch ein Problem.

Die Organisation sollte Kriterien festlegen.

Beispiel: Incident zu Problem

Incident

Mehrere Benutzer melden, dass VPN nach dem Ruhezustand nicht mehr funktioniert.

Incident Management

Der Service Desk stellt die Verbindung durch Neustart des VPN-Clients wieder her.

Problem Management

Mehrere gleichartige Incidents werden verglichen.

Es wird erkannt:

Ergebnis

Ein Problem Record wird erstellt.

Ein Known Error und ein Workaround werden dokumentiert.

Ein Change für eine neue Client-Version wird vorbereitet.

Problem Management und Change Enablement

Dauerhafte Lösungen erfordern häufig Änderungen an produktiven Systemen.

Beispiele:

Solche Maßnahmen dürfen nicht unkontrolliert durchgeführt werden.

Change Enablement sorgt dafür, dass Änderungen bewertet, geplant, genehmigt, umgesetzt und überprüft werden.

Warum dauerhafte Lösungen oft Changes sind

Eine dauerhafte Lösung verändert häufig den Zustand einer Umgebung.

Beispiele:

Problem mögliche dauerhafte Lösung Bezug zu Change Enablement
VPN-Client fehlerhaft neue Version ausrollen Software-Change
Zertifikat läuft ab Zertifikat erneuern und Monitoring ergänzen technischer Change
Speicher läuft voll Logrotation ändern Konfigurations-Change
Druckertreiber fehlerhaft Treiber aktualisieren Standard- oder Normal-Change
Dienst stürzt regelmäßig ab Anwendungspatch einspielen Release oder Change
Berechtigungen falsch modelliert Rollenkonzept anpassen organisatorischer und technischer Change

Die Art des Changes hängt von Risiko, Auswirkung und Organisationsregeln ab.

Problem Management liefert Input für Changes

Ein guter Change zur Problemlösung sollte auf nachvollziehbaren Informationen beruhen.

Problem Management liefert dafür:

Dadurch kann Change Enablement besser bewerten, ob und wie die Änderung umgesetzt werden soll.

Change Enablement liefert Informationen zurück

Nach einem Change sollte geprüft werden:

Ein Problem sollte nicht automatisch geschlossen werden, nur weil ein Change umgesetzt wurde.

Die Wirksamkeit muss überprüft werden.

Emergency Change und Problem Management

Bei sehr kritischen Situationen kann eine schnelle Änderung notwendig sein.

Beispiele:

Auch dann sollten Entscheidungen dokumentiert werden.

Nach der Wiederherstellung sollten Problem Management und Review klären:

Problem Management und Knowledge Management

Problem Management erzeugt Wissen.

Dieses Wissen muss auffindbar, verständlich und aktuell sein.

Geeignete Inhalte für Knowledge Management:

Wenn Wissen nicht dokumentiert wird, müssen Teams dieselben Fälle immer wieder neu analysieren.

Unterschiedliche Zielgruppen für Wissen

Nicht jedes Wissen gehört in denselben Artikel.

Zielgruppe Inhalt
Benutzer einfache Anleitung, Workaround, Statushinweise
Service Desk Prüfschritte, bekannte Symptome, Eskalationsregeln
Fachteam technische Details, Logs, Konfigurationen, Ursachen
Management Risiko, Auswirkungen, Verbesserungsstatus
Lieferant Produktversion, Fehlerbild, technische Nachweise

Ein Benutzerartikel sollte keine internen Diagnoseschritte oder vertraulichen technischen Details enthalten.

Known Error als Wissensbaustein

Ein Known Error ist besonders wichtig für Knowledge Management.

Er beschreibt:

Dadurch kann der Service Desk schneller entscheiden, ob ein neuer Incident zu einem bekannten Fehler passt.

Knowledge-Artikel aktuell halten

Nach Problem- und Change-Bearbeitung müssen Wissensartikel geprüft werden.

Zu aktualisieren sind möglicherweise:

Ein gelöster Known Error mit veraltetem Workaround kann später neue Verwirrung erzeugen.

Problem Management und Service Configuration Management

Für Problem Management sind Informationen über Configuration Items und Serviceabhängigkeiten sehr wichtig.

Hilfreich sind:

Ohne diese Informationen ist schwer erkennbar, welche Komponenten gemeinsam betroffen sind.

Beispiel: Abhängigkeiten erkennen

Mehrere Anwendungen melden Verbindungsfehler.

Einzelne Teams prüfen zunächst ihre Anwendungen getrennt.

Durch Service- und CI-Beziehungen wird sichtbar:

Problem Management kann dadurch gezielter analysieren.

Problem Management und Service Level Management

Service Level Management hilft zu bewerten, welche Problems besonders wichtig sind.

Zu berücksichtigen sind:

Ein Problem mit wenigen Incidents kann hohe Priorität besitzen, wenn ein kritischer Service oder ein wichtiges Service Level gefährdet ist.

Problem Management und Supplier Management

Viele Problems betreffen Lieferanten oder Hersteller.

Beispiele:

Problem Management sollte dokumentieren:

Auch wenn ein Lieferant technisch verantwortlich ist, bleibt die interne Serviceverantwortung bestehen.

Problem Management und Continual Improvement

Problem Management liefert viele Verbesserungsideen.

Beispiele:

Diese Verbesserungen sollten nicht nur mündlich besprochen werden.

Sie sollten in einem Improvement Register oder vergleichbaren System verfolgt werden.

Problem Management und Information Security Management

Manche Problems haben Sicherheitsbezug.

Beispiele:

Sicherheitsbezogene Problems benötigen möglicherweise:

Problem Management und Monitoring

Monitoring unterstützt Problem Management durch:

Problem Management kann umgekehrt Monitoring verbessern.

Beispiele:

Zusammenspiel als Kreislauf

Incident-Daten
      ↓
Problem-Analyse
      ↓
Known Error und Workaround
      ↓
Knowledge-Artikel
      ↓
dauerhafte Lösung
      ↓
Change
      ↓
Wirksamkeitsprüfung
      ↓
Verbesserung von Monitoring, Wissen und Prozessen
      ↓
weniger oder schneller lösbare Incidents

Typische Fehler im Zusammenspiel

Fehler 1

Incidents werden gelöst, aber nicht mit Problems verknüpft.

Fehler 2

Problem Management erhält zu wenig Informationen aus Tickets.

Fehler 3

Workarounds werden gefunden, aber nicht in Knowledge Management übernommen.

Fehler 4

Known Errors sind nur Spezialisten bekannt.

Fehler 5

Dauerhafte Lösungen werden ohne Change-Bewertung umgesetzt.

Fehler 6

Nach einem Change wird nicht geprüft, ob das Problem wirklich gelöst ist.

Fehler 7

Knowledge-Artikel bleiben nach einer dauerhaften Lösung unverändert.

Fehler 8

CMDB- und Serviceabhängigkeiten werden nicht genutzt.

Fehler 9

Lieferantenfehler werden intern nicht nachvollziehbar dokumentiert.

Fehler 10

Lessons Learned werden nicht in Continual Improvement übernommen.

Fehler 11

Sicherheitsbezug wird zu spät erkannt.

Fehler 12

Problem Records bleiben offen, ohne Verantwortlichen oder nächsten Schritt.

Praxisbeispiel: VPN-Problem

Incident Management

Mehrere Benutzer melden VPN-Abbrüche.

Der Service Desk stellt die Verbindung durch Neustart des Clients wieder her.

Problem Management

Incidents werden verglichen.

Die Analyse zeigt:

Knowledge Management

Ein Known Error und ein Workaround werden dokumentiert.

Der Service Desk erhält Prüfschritte.

Change Enablement

Eine neue Client-Version wird getestet und kontrolliert ausgerollt.

Continual Improvement

Der Updateprozess wird angepasst, damit Clientupdates künftig besser getestet werden.

Praxisbeispiel: Zertifikatsausfall

Incident Management

Benutzer können sich nicht an einer Anwendung anmelden.

Das abgelaufene Zertifikat wird erneuert.

Problem Management

Die Ursache wird untersucht.

Ergebnis:

Knowledge Management

Symptome und Prüfschritte werden dokumentiert.

Change Enablement

Monitoring und Erneuerungsprozess werden eingeführt.

Continual Improvement

Zertifikatsübersicht und Wartungskalender werden als Standard etabliert.

Praxisbeispiel: Druckerfehler

Incident Management

Etikettendrucker blockiert regelmäßig.

Der Service Desk leert die Warteschlange.

Problem Management

Bestimmte PDF-Dateien und ein alter Treiber werden als Ursache erkannt.

Knowledge Management

Workaround wird dokumentiert.

Change Enablement

Treiberupdate wird getestet und ausgerollt.

Service Desk

Künftige Incidents können schneller erkannt werden.

Continual Improvement

Druckertreiber werden in einen regelmäßigen Prüfprozess aufgenommen.

Checkliste Zusammenspiel mit Incident Management

Checkliste Zusammenspiel mit Change Enablement

Checkliste Zusammenspiel mit Knowledge Management

Checkliste Zusammenspiel mit Configuration Management

Checkliste Abschluss eines Problems

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker für Systemintegration stehen oft genau an der Schnittstelle zwischen Incident, Problem, Change und Knowledge.

Im Arbeitsalltag bedeutet das:

Gute technische Arbeit endet nicht mit der Wiederherstellung eines Services.

Sie hilft auch, zukünftige Incidents zu vermeiden oder schneller zu lösen.

Zusammenfassung

Incident wird bearbeitet
↓
Muster oder Ursache wird erkannt
↓
Problem Record wird erstellt
↓
Ursache, Risiko und Workaround werden untersucht
↓
Known Error und Knowledge werden dokumentiert
↓
dauerhafte Lösung wird vorbereitet
↓
Change Enablement steuert Umsetzung
↓
Wirksamkeit wird geprüft
↓
Monitoring, Knowledge, Prozesse und Standards werden verbessert
↓
zukünftige Incidents werden reduziert oder schneller lösbar

Merksätze

Incident Management stellt den Service wieder her.

Problem Management versteht Ursachen und reduziert Wiederholungen.

Change Enablement sorgt für kontrollierte dauerhafte Lösungen.

Knowledge Management macht Workarounds und Known Errors nutzbar.

Configuration Management zeigt Abhängigkeiten und betroffene Komponenten.

Continual Improvement sorgt dafür, dass Erkenntnisse nicht verloren gehen.

Gute Zusammenarbeit verhindert, dass dieselben Fehler immer wieder neu analysiert werden.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

5. Change Enablement

5. Change Enablement

5.1 Change Enablement – Ziele, Begriffe und Abgrenzung

Kurz erklärt

Change Enablement beschäftigt sich damit, Änderungen an Services, Systemen, Prozessen oder Infrastruktur kontrolliert, nachvollziehbar und risikobewusst umzusetzen.

Ziel ist nicht, Änderungen zu verhindern.

Ziel ist, nützliche Änderungen zu ermöglichen, ohne unnötige Risiken für laufende Services, Benutzer oder Geschäftsprozesse zu erzeugen.

Warum Change Enablement wichtig ist

IT-Umgebungen verändern sich ständig.

Beispiele:

Jede Änderung kann Nutzen bringen.

Jede Änderung kann aber auch Störungen verursachen.

Change Enablement sorgt dafür, dass Änderungen:

werden.

Change Enablement ist kein Änderungsverbot

Ein häufiger Irrtum:

Change Enablement bedeutet, dass jede Änderung möglichst schwer gemacht wird.

Das ist falsch.

Change Enablement soll Änderungen ermöglichen.

Aber Änderungen sollen so durchgeführt werden, dass:

Merke

Gute Change-Steuerung schützt nicht vor Veränderung.

Sie schützt vor unkontrollierter Veränderung.

Was ist ein Change?

Ein Change ist eine Änderung an einem Service oder an einem unterstützenden Bestandteil eines Service.

Betroffen sein können beispielsweise:

Nicht jede Tätigkeit ist automatisch ein Change im engeren Sinn.

Die Organisation muss festlegen, welche Arten von Änderungen über Change Enablement gesteuert werden.

Beispiele für Changes

Change Beispiel
Software-Change Update einer Fachanwendung
Infrastruktur-Change Austausch eines Servers
Netzwerk-Change Anpassung einer Firewall-Regel
Cloud-Change Erstellen einer neuen Ressourcengruppe
Security-Change Aktivierung von MFA
Konfigurations-Change Änderung eines Dienstparameters
Datenbank-Change Schemaänderung
Prozess-Change neuer Genehmigungsworkflow
Monitoring-Change neue Alarmregel
Dokumentations-Change Aktualisierung eines Runbooks

Ziele von Change Enablement

Change Enablement verfolgt mehrere Ziele:

Change Enablement verbindet Stabilität und Veränderungsfähigkeit.

Risiken unkontrollierter Änderungen

Unkontrollierte Änderungen können zu schweren Problemen führen.

Beispiele:

Viele Incidents entstehen nicht durch völlig unbekannte Fehler, sondern durch schlecht geplante oder schlecht dokumentierte Änderungen.

Change Enablement und Incident Management

Change Enablement steht eng mit Incident Management in Verbindung.

Ein Change kann:

Beispiel:

Nach einem Update funktioniert eine Anwendung nicht mehr.

Incident Management stellt den Service schnell wieder her.

Change Enablement hilft anschließend zu klären:

Change Enablement und Problem Management

Problem Management liefert häufig den Anlass für Changes.

Beispiele:

Die dauerhafte Lösung eines Problems erfordert oft einen Change.

Problem Management beschreibt Ursache, Risiko und Lösungsvorschlag.

Change Enablement sorgt für kontrollierte Umsetzung.

Change Enablement und Knowledge Management

Änderungen erzeugen neues Wissen.

Nach einem Change müssen möglicherweise aktualisiert werden:

Ein Change ist nicht vollständig abgeschlossen, wenn die Technik funktioniert, aber das Wissen veraltet bleibt.

Change Enablement und Service Configuration Management

Service Configuration Management liefert Informationen über Configuration Items und Abhängigkeiten.

Für Changes ist wichtig zu wissen:

Ohne diese Informationen kann die Auswirkungsbewertung unvollständig sein.

Change Enablement und Information Security Management

Viele Changes haben Sicherheitsbezug.

Beispiele:

Solche Changes benötigen möglicherweise besondere Prüfung durch Informationssicherheit.

Dabei geht es nicht darum, jede Änderung zu blockieren.

Es geht darum, Risiken bewusst zu bewerten.

Change Enablement und Continual Improvement

Change Enablement unterstützt kontinuierliche Verbesserung.

Verbesserungen werden oft durch Changes umgesetzt.

Beispiele:

Continual Improvement erkennt Verbesserungsbedarf.

Change Enablement sorgt dafür, dass die Änderung kontrolliert umgesetzt wird.

Change Request

Ein Change Request beschreibt eine gewünschte Änderung.

Typische Inhalte:

Das konkrete Format hängt vom ITSM-Werkzeug und der Organisation ab.

Warum ein Change Request wichtig ist

Ein Change Request macht eine Änderung nachvollziehbar.

Er beantwortet zentrale Fragen:

Ohne diese Informationen kann eine Änderung schwer bewertet werden.

Auswirkung und Risiko bewerten

Vor einem Change sollte geprüft werden:

Die Bewertung muss zum Umfang der Änderung passen.

Eine kleine Standardänderung benötigt weniger Aufwand als eine kritische Produktionsumstellung.

Nutzen bewerten

Neben Risiken muss auch der Nutzen betrachtet werden.

Möglicher Nutzen:

Ein Change kann trotz Risiko sinnvoll sein, wenn der Nutzen wichtig genug ist und die Risiken kontrolliert werden.

Change Enablement und Geschwindigkeit

Nicht alle Changes dürfen gleich langsam oder gleich schnell behandelt werden.

Eine Organisation muss unterscheiden zwischen:

Zu viel Kontrolle verlangsamt notwendige Verbesserungen.

Zu wenig Kontrolle erzeugt Störungen.

Gutes Change Enablement findet ein passendes Gleichgewicht.

Typische Change-Arten

Viele Organisationen unterscheiden mindestens:

Die genaue Bezeichnung und Ausgestaltung kann je nach Organisation unterschiedlich sein.

ITIL gibt Konzepte vor, aber keine für alle Organisationen identische Prozessform.

Standard Change

Ein Standard Change ist eine vorab bewertete, wiederholbare und risikoarme Änderung.

Typische Merkmale:

Beispiele:

Ein Standard Change benötigt nicht jedes Mal eine vollständige Einzelgenehmigung.

Er muss aber sauber definiert und kontrolliert sein.

Normal Change

Ein Normal Change ist eine Änderung, die bewertet, geplant und je nach Risiko genehmigt werden muss.

Beispiele:

Normal Changes benötigen typischerweise:

Emergency Change

Ein Emergency Change ist eine dringende Änderung, die notwendig ist, um einen akuten Schaden zu vermeiden oder einen Service schnell wiederherzustellen.

Beispiele:

Emergency Changes dürfen nicht als Abkürzung für schlecht geplante Arbeit missbraucht werden.

Auch bei hoher Dringlichkeit sollten Entscheidungen und Maßnahmen dokumentiert werden.

Nachträgliche Prüfung ist besonders wichtig.

Change Authority

Eine Change Authority ist eine Person oder Gruppe, die Changes bewertet oder genehmigt.

Je nach Organisation und Change-Art können das sein:

Die Change Authority sollte zur Größe, zum Risiko und zur Auswirkung des Changes passen.

Nicht jede Änderung benötigt ein großes Gremium.

Change Advisory Board

Ein Change Advisory Board kann bei komplexeren oder risikoreicheren Changes beraten.

Mögliche Aufgaben:

Ein Change Advisory Board sollte nicht jede kleine Änderung ausbremsen.

Es sollte dort unterstützen, wo mehrere Perspektiven notwendig sind.

Kommunikation bei Changes

Betroffene Benutzer und Stakeholder sollten rechtzeitig informiert werden.

Zu kommunizieren sind je nach Situation:

Gute Kommunikation reduziert Unsicherheit und unnötige Tickets.

Wartungsfenster

Ein Wartungsfenster ist ein geplanter Zeitraum für Änderungen.

Es hilft, Risiken zu begrenzen.

Zu beachten:

Ein Wartungsfenster sollte nicht nur technisch bequem sein.

Es muss auch zur Nutzung des Services passen.

Rollback und Backout

Vor riskanten Changes sollte klar sein, wie die Änderung zurückgenommen werden kann.

Zu prüfen ist:

Nicht jeder Change kann einfach zurückgerollt werden.

Dann muss das Risiko besonders sorgfältig bewertet werden.

Testen vor Umsetzung

Tests reduzieren Risiken.

Mögliche Tests:

Der Testumfang muss zum Risiko passen.

Ein kritischer Change benötigt mehr Prüfung als ein kleiner Standard Change.

Erfolg eines Changes prüfen

Nach der Umsetzung sollte geprüft werden:

Ein Change ist nicht nur deshalb erfolgreich, weil die technische Änderung durchgeführt wurde.

Er ist erfolgreich, wenn der gewünschte Nutzen ohne unvertretbare Nebenwirkungen erreicht wurde.

Failed Change

Ein Failed Change ist eine Änderung, die nicht wie geplant erfolgreich war oder negative Auswirkungen verursacht hat.

Mögliche Ursachen:

Failed Changes sollten analysiert werden.

Ziel ist Lernen, nicht Schuldzuweisung.

Typische Fehler

Fehler 1

Änderungen werden ohne Bewertung direkt in Produktion durchgeführt.

Fehler 2

Change Enablement wird als reine Bürokratie verstanden.

Fehler 3

Risiken werden nur technisch, nicht geschäftlich bewertet.

Fehler 4

Abhängigkeiten zwischen Services werden nicht geprüft.

Fehler 5

Benutzer werden nicht informiert.

Fehler 6

Rollback fehlt oder ist unrealistisch.

Fehler 7

Tests sind unzureichend.

Fehler 8

Emergency Changes werden als Abkürzung genutzt.

Fehler 9

Nach dem Change wird der Erfolg nicht geprüft.

Fehler 10

Dokumentation und Knowledge Base werden nicht aktualisiert.

Fehler 11

Changes werden nicht mit Incidents oder Problems verknüpft.

Fehler 12

Failed Changes werden nicht ausgewertet.

Praxisbeispiel: Firewall-Regel

Ausgangslage

Eine neue Schnittstelle zwischen zwei Anwendungen soll freigeschaltet werden.

Change Request

Risiko

Falsche Regel kann Zugriff verhindern oder ungewollten Zugriff erlauben.

Erfolgskriterium

Die Schnittstelle funktioniert und es gibt keine unerwarteten Verbindungsfreigaben.

Praxisbeispiel: Zertifikat erneuern

Ausgangslage

Ein Zertifikat läuft bald ab.

Change

Zertifikat wird vor Ablauf erneuert.

Prüfung

Nutzen

Ausfall durch abgelaufenes Zertifikat wird verhindert.

Praxisbeispiel: Emergency Change

Ausgangslage

Eine kritische Sicherheitslücke wird aktiv ausgenutzt.

Maßnahme

Ein Sicherheitsupdate muss kurzfristig eingespielt werden.

Wichtig

Checkliste Change Request

Checkliste Umsetzung

Checkliste Nachbereitung

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker für Systemintegration führen im Alltag viele Changes durch oder bereiten sie vor.

Beispiele:

Wichtig ist dabei nicht nur die technische Umsetzung.

Wichtig ist auch:

Zusammenfassung

Änderungsbedarf erkennen
↓
Change Request erstellen
↓
Nutzen, Risiko und Auswirkungen bewerten
↓
Change-Art bestimmen
↓
Freigabe oder Vorabgenehmigung prüfen
↓
Umsetzung planen
↓
Benutzer und Stakeholder informieren
↓
Change kontrolliert durchführen
↓
Ergebnis testen
↓
Dokumentation, Knowledge und CMDB aktualisieren
↓
Lessons Learned übernehmen

Merksätze

Change Enablement verhindert nicht Veränderung, sondern ermöglicht sichere Veränderung.

Jede Änderung kann Nutzen und Risiko erzeugen.

Ein kleiner technischer Change kann große geschäftliche Auswirkungen haben.

Rollback muss vor der Umsetzung bedacht werden.

Emergency Changes sind kein Ersatz für schlechte Planung.

Ein Change ist erst erfolgreich, wenn der gewünschte Nutzen erreicht wurde.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

5. Change Enablement

5.2 Change-Typen und Risikobewertung

Kurz erklärt

Nicht jede Änderung besitzt dasselbe Risiko.

Change Enablement unterscheidet deshalb verschiedene Change-Typen und bewertet Änderungen nach Risiko, Auswirkung, Dringlichkeit und Standardisierbarkeit.

Ziel ist, einfache und risikoarme Änderungen schnell durchführen zu können, während kritische Änderungen sorgfältig geplant und kontrolliert werden.

Warum Change-Typen wichtig sind

Eine kleine Standardänderung sollte nicht denselben Aufwand verursachen wie eine kritische Produktionsumstellung.

Beispiele:

Diese Änderungen unterscheiden sich stark in:

Change-Typen helfen dabei, den passenden Umgang mit einer Änderung festzulegen.

Grundidee der Change-Klassifizierung

Eine Organisation sollte festlegen:

ITIL schreibt keine für alle Organisationen identische Change-Matrix vor.

Die Einteilung muss zur Organisation, zu den Services und zu den Risiken passen.

Typische Change-Typen

Viele Organisationen unterscheiden mindestens:

Change-Typ Kurzbeschreibung
Standard Change vorab bewertete, wiederholbare und risikoarme Änderung
Normal Change Änderung mit individueller Bewertung, Planung und Genehmigung
Emergency Change dringende Änderung zur Abwehr akuter Schäden oder zur schnellen Wiederherstellung
Major Change besonders umfangreiche, geschäftskritische oder risikoreiche Änderung
Minor Change kleine Änderung mit begrenzter Auswirkung
Routine Change regelmäßig vorkommende Änderung nach definiertem Ablauf

Nicht jede Organisation verwendet alle Begriffe.

Wichtig ist, dass die Begriffe intern eindeutig definiert sind.

Standard Change

Ein Standard Change ist eine Änderung, die bereits vorab geprüft und genehmigt wurde.

Typische Merkmale:

Beispiele:

Ein Standard Change ist nicht ungeprüft.

Er wurde nur bereits vorab bewertet.

Normal Change

Ein Normal Change wird individuell bewertet, geplant und genehmigt.

Typische Merkmale:

Beispiele:

Normal Changes benötigen je nach Risiko unterschiedlich viel Prüfung.

Emergency Change

Ein Emergency Change ist eine dringende Änderung, die wegen eines akuten Risikos oder Schadens schnell durchgeführt werden muss.

Typische Auslöser:

Beispiele:

Emergency Changes dürfen nicht als Abkürzung für schlechte Planung genutzt werden.

Auch unter Zeitdruck müssen Maßnahmen nachvollziehbar dokumentiert und nachträglich überprüft werden.

Major Change

Ein Major Change ist eine Änderung mit besonders hoher Auswirkung oder hohem Risiko.

Beispiele:

Typische Merkmale:

Ein Major Change ist nicht automatisch ein Emergency Change.

Er kann lange geplant sein und trotzdem sehr risikoreich sein.

Minor Change

Ein Minor Change ist eine kleinere Änderung mit begrenzter Auswirkung.

Beispiele:

Auch kleine Changes können Risiken besitzen.

Beispiel:

Eine scheinbar kleine Firewall-Regel kann große Auswirkungen haben, wenn sie einen kritischen Service betrifft.

Change-Typen im Vergleich

Kriterium Standard Change Normal Change Emergency Change
Risiko gering und vorab bewertet individuell zu bewerten häufig hoch oder zeitkritisch
Dringlichkeit planbar planbar akut
Genehmigung vorab genehmigt je nach Risiko erforderlich beschleunigt oder nachträglich ergänzt
Ablauf standardisiert individuell geplant schnell, aber kontrolliert
Dokumentation standardisiert vollständig nach Bedarf mindestens entscheidungsrelevant
Beispiele Standardsoftware produktives Update kritischer Sicherheitspatch

Risikobewertung

Risikobewertung bedeutet, mögliche negative Folgen eines Changes vor der Umsetzung zu betrachten.

Typische Fragen:

Risiko entsteht aus Wahrscheinlichkeit und Auswirkung.

Auswirkung bewerten

Die Auswirkung beschreibt, wie stark Benutzer, Services oder Geschäftsprozesse betroffen wären.

Zu prüfen ist:

Je größer die mögliche Auswirkung, desto sorgfältiger muss der Change gesteuert werden.

Wahrscheinlichkeit bewerten

Die Wahrscheinlichkeit beschreibt, wie wahrscheinlich ein Fehler bei der Änderung ist.

Einflussfaktoren:

Eine Änderung mit geringer Auswirkung, aber hoher Fehlerwahrscheinlichkeit kann trotzdem relevant sein.

Dringlichkeit bewerten

Nicht jede dringende Änderung ist automatisch ein Emergency Change.

Zu prüfen ist:

Dringlichkeit darf nicht dazu führen, dass grundlegende Sicherheits- und Dokumentationspflichten ignoriert werden.

Nutzen bewerten

Neben Risiko und Dringlichkeit muss der Nutzen betrachtet werden.

Möglicher Nutzen:

Ein Change kann sinnvoll sein, obwohl er Risiko besitzt.

Entscheidend ist, ob Nutzen und Risiko bewusst bewertet wurden.

Typische Risikokriterien

Kriterium Beispiele
Servicekritikalität produktiv, geschäftskritisch, Testsystem
Benutzerimpact einzelne Person, Team, Standort, Kunden
Technische Komplexität einfache Konfiguration, Migration, Architekturänderung
Rollback-Fähigkeit einfach, schwierig, nicht möglich
Testabdeckung vollständig getestet, teilweise getestet, nicht getestet
Sicherheitsbezug Berechtigungen, Firewall, Daten, Logging
Zeitpunkt Geschäftszeit, Wartungsfenster, Monatsabschluss
Abhängigkeiten Datenbank, Netzwerk, Identität, Lieferant
Erfahrung häufig durchgeführt, neu, einmalig
Kommunikationsbedarf keine Benutzerinfo, interne Info, Kundenkommunikation

Einfache Risikomatrix

Eine einfache Matrix kann helfen.

Auswirkung Wahrscheinlichkeit niedrig Wahrscheinlichkeit mittel Wahrscheinlichkeit hoch
hoch mittel hoch sehr hoch
mittel niedrig mittel hoch
niedrig niedrig niedrig mittel

Diese Matrix ist nur ein Beispiel.

Die Organisation muss eigene Bewertungsstufen festlegen.

Beispiel für Change-Risikostufen

Risikostufe Bedeutung
Niedrig begrenzte Auswirkung, gut getestet, einfacher Rollback
Mittel mehrere Benutzer oder wichtiger Service betroffen, Rollback möglich
Hoch kritischer Service, viele Benutzer, komplexe Änderung
Sehr hoch geschäftskritisch, schwieriger Rollback, erhebliche Sicherheits- oder Datenrisiken

Die Risikostufe beeinflusst:

Change Authority passend wählen

Die Genehmigungsinstanz sollte zum Risiko passen.

Beispiele:

Change mögliche Change Authority
Standardsoftware installieren vorab genehmigter Standardprozess
kleine Konfigurationsänderung Team Lead oder Service Owner
produktives Anwendungsupdate Change Manager oder Change Advisory Board
sicherheitskritische Firewall-Regel Informationssicherheit und Service Owner
Emergency Security Patch Emergency Change Authority
große Plattformmigration Management, Service Owner, Change Board

Nicht jede Änderung benötigt ein großes Gremium.

Aber risikoreiche Änderungen brauchen ausreichend Perspektiven.

Wann ein Change Advisory Board sinnvoll ist

Ein Change Advisory Board kann sinnvoll sein, wenn:

Ein CAB sollte beraten und Risiken sichtbar machen.

Es sollte nicht jede Routineänderung unnötig verzögern.

Emergency Change Authority

Für Emergency Changes kann eine kleinere, schnell erreichbare Entscheidungsgruppe sinnvoll sein.

Mögliche Beteiligte:

Wichtig ist:

Standard Change richtig definieren

Ein Standard Change sollte nicht leichtfertig als Standard eingestuft werden.

Vorab zu klären:

Wenn ein Standard Change häufig fehlschlägt, muss er neu bewertet werden.

Emergency Change Missbrauch vermeiden

Emergency Changes sollten nicht genutzt werden, nur weil:

Ungeeignet:

Wir machen daraus einen Emergency Change, damit wir keine Freigabe brauchen.

Besser:

Es liegt kein akuter Schaden vor. Der Change wird als Normal Change mit beschleunigter Planung behandelt.

Risiko durch Nicht-Handeln

Nicht nur Durchführung kann riskant sein.

Auch Nicht-Handeln kann Risiko erzeugen.

Beispiele:

Eine gute Bewertung betrachtet deshalb:

Rollback und Backout in der Risikobewertung

Ein Change ist weniger riskant, wenn ein zuverlässiger Rollback möglich ist.

Zu prüfen ist:

Wenn kein Rollback möglich ist, muss besonders sorgfältig getestet und kommuniziert werden.

Testumfang nach Risiko

Der Testumfang sollte zur Risikostufe passen.

Risiko möglicher Testumfang
niedrig Standardprüfung, kurzer Funktionstest
mittel Testsystem, Review, definierter Smoke Test
hoch ausführlicher Testplan, Abhängigkeitstest, Rollback-Test
sehr hoch Pilot, Lasttest, Sicherheitsprüfung, Managementfreigabe

Tests sollten nicht nur prüfen, ob die Änderung technisch durchgeführt wurde.

Sie sollten prüfen, ob der Service danach wie erwartet nutzbar ist.

Kommunikationsbedarf nach Risiko

Je höher Risiko und Auswirkung, desto wichtiger wird Kommunikation.

Zu informieren sind je nach Change:

Inhalt der Kommunikation:

Wartungsfenster bewerten

Ein Wartungsfenster sollte passend gewählt werden.

Zu berücksichtigen sind:

Ein technisch bequemes Wartungsfenster ist nicht automatisch geschäftlich sinnvoll.

Abhängigkeiten und Change-Kollisionen

Mehrere Changes können sich gegenseitig beeinflussen.

Beispiele:

Change Enablement sollte prüfen:

Change Freeze

Ein Change Freeze ist ein Zeitraum, in dem Änderungen eingeschränkt werden.

Beispiele:

Ein Change Freeze verhindert nicht zwingend jede Änderung.

Emergency Changes oder wichtige Sicherheitsmaßnahmen können trotzdem notwendig sein.

Dann muss besonders bewusst entschieden werden.

Sicherheitsrisiken bewerten

Besonders sorgfältig zu bewerten sind Changes an:

Fragen:

Datenschutz und Compliance

Manche Changes betreffen Datenschutz oder Compliance.

Beispiele:

Dann können zusätzliche Prüfungen erforderlich sein.

Beispielsweise durch Datenschutz, Informationssicherheit, Compliance oder Rechtsabteilung.

Lieferantenrisiken

Bei Changes mit Lieferantenbezug zu prüfen:

Auch externe Changes müssen intern nachvollziehbar gesteuert werden.

Change-Erfolgskriterien

Vor der Umsetzung sollte klar sein, wann ein Change erfolgreich ist.

Beispiele:

Ohne Erfolgskriterien ist die Nachprüfung unklar.

Failed Change und Lessons Learned

Ein Change kann fehlschlagen.

Wichtig ist dann:

Ziel ist Lernen, nicht Schuldzuweisung.

Praxisbeispiel: Standard Change

Änderung

Standardsoftware aus genehmigtem Katalog wird installiert.

Bewertung

Umgang

Der Change kann als Standard Change über das Serviceportal ausgeführt werden.

Praxisbeispiel: Normal Change

Änderung

Eine produktive Fachanwendung erhält ein Versionsupdate.

Bewertung

Umgang

Der Change wird geplant, getestet, genehmigt und nach Umsetzung geprüft.

Praxisbeispiel: Emergency Change

Änderung

Eine aktiv ausgenutzte Sicherheitslücke muss kurzfristig geschlossen werden.

Bewertung

Umgang

Emergency Change wird kontrolliert durchgeführt, dokumentiert und nachträglich reviewed.

Praxisbeispiel: Falsch eingestufter Change

Situation

Eine Firewall-Regel wird als kleine Routineänderung behandelt.

Problem

Die Regel betrifft eine zentrale Schnittstelle zur Warenwirtschaft.

Nach Umsetzung kann der Versand keine Aufträge mehr übertragen.

Lerneffekt

Der Change war technisch klein, aber geschäftlich kritisch.

Künftig werden Firewall-Changes nach betroffenen Services und Geschäftsprozessen bewertet, nicht nur nach technischem Aufwand.

Typische Fehler

Fehler 1

Jede Änderung wird gleich behandelt.

Fehler 2

Ein riskanter Change wird fälschlich als Standard Change eingestuft.

Fehler 3

Emergency Change wird als Abkürzung genutzt.

Fehler 4

Nur technische Risiken werden bewertet.

Fehler 5

Risiko des Nicht-Handelns wird ignoriert.

Fehler 6

Rollback wird erst während der Störung überlegt.

Fehler 7

Tests passen nicht zum Risiko.

Fehler 8

Benutzer und Service Desk werden nicht informiert.

Fehler 9

Abhängigkeiten und parallele Changes werden nicht geprüft.

Fehler 10

Sicherheits- und Datenschutzrisiken werden zu spät erkannt.

Fehler 11

Change-Erfolgskriterien fehlen.

Fehler 12

Failed Changes werden nicht ausgewertet.

Checkliste Change-Typ bestimmen

Checkliste Risikobewertung

Checkliste Emergency Change

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker müssen Change-Typen und Risiken praktisch einschätzen können.

Im Arbeitsalltag bedeutet das:

Gerade kleine technische Änderungen können große Auswirkungen haben, wenn sie einen kritischen Service betreffen.

Zusammenfassung

Änderung erkennen
↓
Change-Typ bestimmen
↓
Auswirkung und Wahrscheinlichkeit bewerten
↓
Risiko des Changes und Risiko des Nicht-Handelns vergleichen
↓
Test, Rollback und Kommunikation planen
↓
passende Change Authority einbinden
↓
Änderung kontrolliert durchführen
↓
Erfolg prüfen
↓
Lessons Learned übernehmen

Merksätze

Nicht jede Änderung benötigt denselben Prozessaufwand.

Ein Standard Change ist vorab bewertet, nicht ungeprüft.

Ein Emergency Change ist kein Ersatz für schlechte Planung.

Technisch klein bedeutet nicht automatisch risikoarm.

Risiko entsteht aus Auswirkung, Wahrscheinlichkeit und Kontext.

Auch Nicht-Handeln kann riskant sein.

Der Change-Typ muss zur tatsächlichen Auswirkung passen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

5. Change Enablement

5.3 Genehmigung, Planung und Umsetzung von Changes

Kurz erklärt

Ein Change sollte nicht nur technisch durchgeführt werden.

Vor der Umsetzung müssen Ziel, Risiko, Auswirkungen, Verantwortlichkeiten, Freigaben, Kommunikation, Tests und Rückfallmöglichkeiten geklärt sein.

Gute Change-Planung sorgt dafür, dass Änderungen kontrolliert, nachvollziehbar und mit möglichst geringem Risiko für laufende Services umgesetzt werden.

Warum Genehmigung und Planung wichtig sind

Viele Störungen entstehen nicht durch die Änderung selbst, sondern durch unklare Vorbereitung.

Typische Ursachen:

Change Enablement soll solche Risiken reduzieren.

Grundprinzip

Ein Change sollte nur dann umgesetzt werden, wenn mindestens klar ist:

Je höher Risiko und Auswirkung, desto gründlicher müssen Planung und Genehmigung sein.

Typischer Ablauf

Änderungsbedarf erkennen
        ↓
Change Request erstellen
        ↓
Risiko und Auswirkung bewerten
        ↓
Change-Typ bestimmen
        ↓
Genehmigung oder Vorabgenehmigung prüfen
        ↓
Umsetzung planen
        ↓
Kommunikation vorbereiten
        ↓
Change durchführen
        ↓
Ergebnis testen
        ↓
Dokumentation aktualisieren
        ↓
Change abschließen oder nachbereiten

Dieser Ablauf ist ein Praxisbeispiel.

Die konkrete Umsetzung hängt von Organisation, Risiko und Change-Modell ab.

Change Request erstellen

Ein Change Request beschreibt die gewünschte Änderung.

Typische Inhalte:

Ein Change Request sollte so formuliert sein, dass eine andere Person die Änderung bewerten kann.

Gute und schlechte Change-Beschreibung

Ungeeignet:

Update Server.

Besser:

Update des produktiven Webservers APP-WEB-01 von Version 2.4.57 auf 2.4.60, um bekannte Sicherheitslücken zu schließen. Betroffen ist der interne Service „Mitarbeiterportal“. Umsetzung im Wartungsfenster am 14.08.2026 von 20:00 bis 21:00 Uhr. Rollback durch Wiederherstellung der vorherigen Paketversion und Konfiguration möglich.

Eine gute Beschreibung macht Ziel, Umfang und Risiko sichtbar.

Genehmigung

Genehmigung bedeutet, dass eine berechtigte Person oder Gruppe der Umsetzung zustimmt.

Dabei wird geprüft:

Genehmigung ist keine reine Formalität.

Sie soll eine bewusste Entscheidung ermöglichen.

Change Authority

Die Change Authority ist die Person oder Gruppe, die eine Änderung bewertet oder genehmigt.

Mögliche Change Authorities:

Die passende Change Authority hängt ab von:

Nicht jeder Change benötigt dieselbe Genehmigungsstufe.

Genehmigung nach Risiko

Risiko mögliche Genehmigung
niedrig vorab genehmigter Standardprozess
mittel Team Lead oder Service Owner
hoch Change Manager, Service Owner oder CAB
sehr hoch Management, Informationssicherheit, CAB oder spezielle Change Authority
akut kritisch Emergency Change Authority

Diese Tabelle ist ein Beispiel.

Die Organisation muss ihre Genehmigungswege selbst festlegen.

Change Advisory Board

Ein Change Advisory Board kann bei umfangreichen oder risikoreichen Changes unterstützen.

Mögliche Aufgaben:

Ein CAB sollte nicht jede kleine Änderung ausbremsen.

Es ist besonders dann sinnvoll, wenn mehrere Perspektiven benötigt werden.

Emergency-Genehmigung

Bei Emergency Changes muss oft schneller entschieden werden.

Trotzdem sollten mindestens geklärt werden:

Auch ein Emergency Change braucht Kontrolle.

Nur der Genehmigungsweg ist beschleunigt.

Planung der Umsetzung

Ein Umsetzungsplan beschreibt, wie der Change praktisch durchgeführt wird.

Er sollte enthalten:

Je kritischer der Change, desto genauer sollte der Plan sein.

Schrittfolge definieren

Eine gute Schrittfolge vermeidet Unsicherheit während der Umsetzung.

Beispiel:

  1. aktuelles Backup prüfen
  2. Konfiguration exportieren
  3. Benutzerinformation bestätigen
  4. Dienst in Wartungsmodus setzen
  5. Update installieren
  6. Dienst starten
  7. Funktionstest durchführen
  8. Monitoring prüfen
  9. Fachbereichstest bestätigen
  10. Wartungsmodus beenden
  11. Abschlussmeldung senden
  12. Dokumentation aktualisieren

Wichtig ist, dass jeder Schritt ein klares Ergebnis besitzt.

Vorbereitung

Vor der Umsetzung sollte geprüft werden:

Eine gute Vorbereitung verhindert Hektik während des Change-Fensters.

Wartungsfenster

Ein Wartungsfenster ist ein geplanter Zeitraum für Änderungen.

Zu berücksichtigen sind:

Ein Wartungsfenster sollte nicht nur technisch bequem sein.

Es muss zur Nutzung des Services passen.

Kommunikation vor dem Change

Betroffene Personen sollten rechtzeitig informiert werden.

Je nach Change können beteiligt sein:

Eine Vorabinformation kann enthalten:

Beispiel einer Benutzerinformation

Am 14.08.2026 zwischen 20:00 und 21:00 Uhr wird das Mitarbeiterportal aktualisiert. In diesem Zeitraum kann der Zugriff kurzzeitig unterbrochen sein. Bitte speichern Sie offene Eingaben vorher. Nach Abschluss informieren wir über die erfolgreiche Umsetzung.

Die Kommunikation sollte verständlich und nicht unnötig technisch sein.

Service Desk informieren

Der Service Desk muss vor wichtigen Changes wissen:

Sonst entstehen unnötige Incidents und Rückfragen.

Tests planen

Ein Testplan beschreibt, wie geprüft wird, ob der Change erfolgreich war.

Mögliche Tests:

Der Test muss zum Risiko des Changes passen.

Bei kritischen Services reicht ein oberflächlicher Test oft nicht aus.

Smoke Test

Ein Smoke Test ist eine kurze Grundprüfung nach der Umsetzung.

Beispiele:

Ein Smoke Test ersetzt keine vollständige Abnahme.

Er hilft aber, grobe Fehler sofort zu erkennen.

Rollback und Backout planen

Rollback oder Backout bedeutet, den Change zurückzunehmen oder in einen sicheren Zustand zu bringen.

Zu klären ist:

Ein Rollback muss vor der Umsetzung geplant werden, nicht erst während der Störung.

Rollback ist nicht immer möglich

Manche Changes lassen sich nicht einfach zurückrollen.

Beispiele:

Wenn kein einfacher Rollback möglich ist, müssen Risiko, Testtiefe und Kommunikationsplanung besonders sorgfältig sein.

Abbruchkriterien

Abbruchkriterien legen fest, wann ein Change gestoppt oder zurückgerollt wird.

Beispiele:

Abbruchkriterien verhindern, dass ein Change trotz deutlicher Warnzeichen weitergeführt wird.

Durchführung

Während der Durchführung sollte konzentriert und nachvollziehbar gearbeitet werden.

Wichtig:

Ungeeignet:

Während des Updates ändern wir zusätzlich noch ein paar andere Einstellungen.

Besser:

Nur der freigegebene Change wird umgesetzt. Zusätzliche Auffälligkeiten werden dokumentiert und separat bewertet.

Umgang mit Abweichungen

Während eines Changes können unerwartete Situationen auftreten.

Dann sollte geklärt werden:

Nicht jede Abweichung darf spontan gelöst werden.

Sonst entsteht ein ungeplanter Change im Change.

Monitoring während des Changes

Monitoring sollte aktiv beobachtet werden.

Zu prüfen sind:

Monitoring zeigt nicht alles.

Es ergänzt technische und fachliche Tests.

Kommunikation während des Changes

Bei längeren oder kritischen Changes sollten Zwischenstände kommuniziert werden.

Beispiele:

Kommunikation verhindert Unsicherheit.

Sie muss aber sachlich und abgestimmt bleiben.

Erfolg prüfen

Nach der Umsetzung sollte geprüft werden:

Ein Change ist nicht automatisch erfolgreich, nur weil die technische Tätigkeit abgeschlossen ist.

Fachliche Abnahme

Bei wichtigen Services kann eine fachliche Abnahme erforderlich sein.

Beispiele:

Technische Erreichbarkeit allein genügt nicht immer.

Wichtig ist, ob der Service aus Sicht der Benutzer funktioniert.

Abschlussmeldung

Nach erfolgreicher Umsetzung sollte eine Abschlussmeldung erfolgen.

Sie kann enthalten:

Beispiel:

Das Update des Mitarbeiterportals wurde erfolgreich abgeschlossen. Der Service ist wieder verfügbar. Bitte melden Sie Auffälligkeiten über das Serviceportal unter Angabe des Services „Mitarbeiterportal“.

Dokumentation aktualisieren

Nach dem Change müssen relevante Informationen aktualisiert werden.

Mögliche Inhalte:

Ein Change ist unvollständig, wenn die technische Umgebung geändert wurde, die Dokumentation aber den alten Zustand zeigt.

CMDB aktualisieren

Wenn Configuration Items betroffen sind, sollte die CMDB aktualisiert werden.

Beispiele:

Fehlende CMDB-Aktualisierung kann spätere Incidents, Problems und Changes erschweren.

Knowledge Base aktualisieren

Nach einem Change können Knowledge-Artikel falsch oder veraltet sein.

Zu prüfen ist:

Wissen muss zum aktuellen Servicezustand passen.

Problem Record aktualisieren

Wenn ein Change eine dauerhafte Lösung für ein Problem war, muss der Problem Record aktualisiert werden.

Zu prüfen ist:

Ein Problem sollte nicht automatisch geschlossen werden, nur weil ein Change umgesetzt wurde.

Failed Change

Ein Change gilt als fehlgeschlagen, wenn:

Ein Failed Change sollte nachvollziehbar ausgewertet werden.

Ziel ist Verbesserung, nicht Schuldzuweisung.

Post Implementation Review

Ein Post Implementation Review prüft nach der Umsetzung, wie der Change verlaufen ist.

Mögliche Fragen:

Nicht jeder kleine Standard Change benötigt ein ausführliches Review.

Bei risikoreichen oder fehlgeschlagenen Changes ist es besonders wichtig.

Praxisbeispiel: Anwendungsupdate

Change

Produktive Fachanwendung wird aktualisiert.

Planung

Umsetzung

Update wird im Wartungsfenster durchgeführt.

Prüfung

Abschluss

Dokumentation und Knowledge-Artikel werden aktualisiert.

Praxisbeispiel: Firewall-Regel

Change

Neue Verbindung zwischen Anwendung und Partner-API wird freigeschaltet.

Planung

Umsetzung

Firewall-Regel wird im genehmigten Zeitfenster gesetzt.

Prüfung

Schnittstelle überträgt Testdaten korrekt.

Logs zeigen keine unerwarteten Verbindungen.

Praxisbeispiel: Rollback notwendig

Change

Datenbanktreiber einer Anwendung wird aktualisiert.

Problem

Nach dem Update schlägt der Export von Berichten fehl.

Entscheidung

Abbruchkriterium ist erfüllt.

Rollback wird eingeleitet.

Nachbereitung

Typische Fehler

Fehler 1

Change wird ohne klaren Plan umgesetzt.

Fehler 2

Genehmigung wird als reine Formalität behandelt.

Fehler 3

Service Desk wird nicht informiert.

Fehler 4

Benutzer erfahren erst durch eine Störung vom Change.

Fehler 5

Rollback ist nicht vorbereitet.

Fehler 6

Tests prüfen nur Technik, nicht Benutzer-Outcome.

Fehler 7

Abweichungen werden spontan und undokumentiert behoben.

Fehler 8

Mehrere zusätzliche Änderungen werden nebenbei durchgeführt.

Fehler 9

Change wird abgeschlossen, obwohl Erfolgskriterien nicht geprüft wurden.

Fehler 10

Dokumentation, CMDB und Knowledge Base bleiben veraltet.

Fehler 11

Problem Record wird nach dauerhafter Lösung nicht aktualisiert.

Fehler 12

Failed Change wird nicht ausgewertet.

Checkliste Genehmigung

Checkliste Planung

Checkliste Umsetzung

Checkliste Abschluss

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker setzen Changes häufig technisch um.

Dabei reicht es nicht, nur den Befehl oder die Konfiguration zu kennen.

Wichtig ist auch:

Gute Change-Umsetzung verbindet technisches Können mit sauberer Planung.

Zusammenfassung

Change Request prüfen
↓
Genehmigung und Change Authority klären
↓
Umsetzungsschritte planen
↓
Tests, Kommunikation und Rollback vorbereiten
↓
Change im vorgesehenen Zeitfenster durchführen
↓
Ergebnis technisch und fachlich prüfen
↓
Abschluss kommunizieren
↓
Dokumentation, CMDB und Knowledge aktualisieren
↓
Failed Changes oder Abweichungen auswerten

Merksätze

Ein Change ist mehr als die technische Änderung.

Genehmigung bedeutet bewusste Risikoentscheidung.

Gute Planung reduziert Incidents nach Changes.

Rollback wird vor der Umsetzung geplant, nicht während der Störung.

Der Service Desk muss wichtige Changes kennen.

Ein Change ist erst abgeschlossen, wenn Ergebnis und Dokumentation geprüft sind.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

5. Change Enablement

5.4 Release Management und Deployment Management

Kurz erklärt

Release Management und Deployment Management sorgen dafür, dass neue oder geänderte Services, Anwendungen, Funktionen oder Infrastrukturkomponenten kontrolliert bereitgestellt werden.

Release Management betrachtet vor allem, wann und in welcher Form eine Änderung für Benutzer oder Kunden verfügbar gemacht wird.

Deployment Management betrachtet vor allem, wie technische Komponenten in eine Zielumgebung gebracht werden.

Beide Bereiche hängen eng mit Change Enablement zusammen.

Warum Release und Deployment wichtig sind

Viele Änderungen werden nicht einzeln sichtbar.

Oft werden mehrere technische Änderungen gemeinsam bereitgestellt.

Beispiele:

Wenn solche Änderungen unkoordiniert ausgerollt werden, können entstehen:

Release und Deployment sorgen für geordnete Bereitstellung.

Release und Deployment unterscheiden

Begriff Bedeutung
Release Bündel neuer oder geänderter Funktionen, Services oder Komponenten, das bereitgestellt und für Nutzung freigegeben wird
Deployment technische Überführung von Komponenten in eine Zielumgebung
Change kontrollierte Änderung an einem Service oder unterstützenden Bestandteil
Rollout Verteilung oder Einführung eines Releases bei Benutzern, Standorten oder Systemen
Rollback Rücknahme einer Änderung auf einen vorherigen Zustand
Backout geplanter Ausstieg aus einer Änderung, wenn Abbruchkriterien erfüllt sind

Ein Deployment kann technisch erfolgreich sein, obwohl das Release aus Benutzersicht noch nicht erfolgreich ist.

Beispiel:

Die neue Version wurde auf dem Server installiert.

Benutzer können aber eine wichtige Funktion nicht nutzen.

Technisch wurde deployed.

Das Release ist fachlich noch nicht erfolgreich.

Release Management

Release Management plant, koordiniert und steuert die Bereitstellung neuer oder geänderter Services und Funktionen.

Typische Fragen:

Release Management verbindet technische Bereitstellung mit Benutzer- und Serviceperspektive.

Deployment Management

Deployment Management sorgt dafür, dass technische Komponenten kontrolliert in eine Zielumgebung gebracht werden.

Typische Fragen:

Deployment Management besitzt damit einen stärker technischen Fokus.

Release, Deployment und Change Enablement im Zusammenspiel

Ein möglicher Zusammenhang:

Änderungsbedarf entsteht
        ↓
Change Request wird erstellt
        ↓
Risiko und Auswirkung werden bewertet
        ↓
Release wird geplant
        ↓
Deployment wird vorbereitet
        ↓
Change wird genehmigt
        ↓
Deployment wird durchgeführt
        ↓
Release wird für Benutzer verfügbar
        ↓
Erfolg wird geprüft
        ↓
Dokumentation und Knowledge werden aktualisiert

Nicht jede Organisation trennt diese Schritte gleich stark.

Wichtig ist, dass technische Umsetzung, Freigabe und Kommunikation zusammenpassen.

Beispiel: Anwendungsversion

Eine Fachanwendung erhält eine neue Version.

Change Enablement

Release Management

Deployment Management

Alle drei Bereiche müssen zusammenarbeiten.

Release-Paket

Ein Release-Paket kann alle Bestandteile enthalten, die für eine Bereitstellung notwendig sind.

Mögliche Inhalte:

Nicht jedes Release-Paket ist gleich umfangreich.

Der Umfang muss zum Risiko und zur Bedeutung des Releases passen.

Release-Plan

Ein Release-Plan beschreibt, wann und wie ein Release bereitgestellt wird.

Typische Inhalte:

Ein Release-Plan muss nicht kompliziert sein.

Er muss aber ausreichend klar sein, damit alle Beteiligten wissen, was passiert.

Release Notes

Release Notes beschreiben, was sich mit einem Release ändert.

Sie können enthalten:

Release Notes sollten zielgruppengerecht sein.

Technische Teams benötigen andere Informationen als Endbenutzer.

Benutzerorientierte Release Notes

Ungeeignet:

Backend-Komponente API-GW-PRD wurde auf Build 2026.08.14-rc3 aktualisiert.

Besser:

Die Suche im Mitarbeiterportal wurde verbessert. Ergebnisse werden nun schneller angezeigt. Während des Updates kann das Portal am 14.08.2026 zwischen 20:00 und 20:30 Uhr kurzzeitig nicht verfügbar sein.

Benutzer müssen verstehen:

Deployment-Plan

Ein Deployment-Plan beschreibt die technische Umsetzung.

Mögliche Inhalte:

Bei einfachen Deployments kann der Plan kurz sein.

Bei kritischen Deployments muss er detaillierter sein.

Umgebungen

Viele Organisationen nutzen mehrere Umgebungen.

Beispiele:

Ziel ist, Änderungen vor der Produktion zu prüfen.

Typische Fragen:

Ein Test in einer völlig abweichenden Umgebung gibt nur begrenzte Sicherheit.

Test und Abnahme

Vor einem Release sollten geeignete Tests durchgeführt werden.

Mögliche Tests:

Der Testumfang hängt vom Risiko ab.

Ein kritisches Release benötigt mehr Prüfung als eine kleine, risikoarme Änderung.

Regressionstest

Ein Regressionstest prüft, ob bestehende Funktionen nach einer Änderung weiterhin funktionieren.

Beispiel:

Eine neue Exportfunktion wird eingebaut.

Der Regressionstest prüft zusätzlich:

Dadurch wird verhindert, dass eine neue Funktion alte Funktionen unbeabsichtigt beschädigt.

Smoke Test nach Deployment

Ein Smoke Test ist eine kurze Grundprüfung direkt nach dem Deployment.

Beispiele:

Ein Smoke Test ersetzt keine vollständige Abnahme.

Er hilft aber, grobe Fehler sofort zu erkennen.

Deployment-Methoden

Organisationen können verschiedene Deployment-Methoden nutzen.

Beispiele:

Methode Kurzbeschreibung
Big Bang Bereitstellung für alle Benutzer gleichzeitig
phasenweise Bereitstellung Einführung in mehreren Gruppen oder Standorten
Pilot begrenzte Einführung bei kleiner Benutzergruppe
Rolling Deployment schrittweise Aktualisierung einzelner Systeme
Blue-Green Deployment Wechsel zwischen zwei vorbereiteten Umgebungen
Canary Deployment neue Version zunächst für kleinen Teil der Benutzer
Feature Toggle Funktion wird technisch bereitgestellt, aber gezielt aktiviert oder deaktiviert

Diese Methoden sind Praxisbeispiele.

ITIL schreibt keine bestimmte technische Deployment-Methode für alle Organisationen vor.

Big-Bang-Deployment

Beim Big-Bang-Deployment wird eine Änderung für alle betroffenen Benutzer oder Systeme gleichzeitig bereitgestellt.

Vorteile:

Risiken:

Geeignet eher dann, wenn:

Phasenweise Bereitstellung

Bei einer phasenweisen Bereitstellung erfolgt der Rollout schrittweise.

Beispiele:

Vorteile:

Risiken:

Pilot

Ein Pilot testet ein Release mit einer begrenzten Benutzergruppe.

Geeignet für:

Ein Pilot sollte klare Kriterien besitzen:

Ein Pilot ohne Auswertung bringt wenig Nutzen.

Blue-Green Deployment

Beim Blue-Green Deployment existieren zwei Umgebungen.

Beispiel:

Nach Tests wird der Verkehr auf die neue Umgebung umgeschaltet.

Vorteile:

Risiken:

Canary Deployment

Beim Canary Deployment erhält zuerst nur ein kleiner Teil der Benutzer die neue Version.

Wenn keine Probleme auftreten, wird der Anteil erhöht.

Vorteile:

Risiken:

Feature Toggles

Feature Toggles ermöglichen, Funktionen unabhängig vom technischen Deployment zu aktivieren oder zu deaktivieren.

Beispiel:

Die neue Funktion ist bereits deployed, aber nur für eine Pilotgruppe aktiviert.

Vorteile:

Risiken:

Feature Toggles benötigen klare Verwaltung und Dokumentation.

Deployment-Automatisierung

Deployments werden häufig automatisiert.

Beispiele:

Vorteile:

Risiken:

Manuelles Deployment

Manuelle Deployments können notwendig sein, wenn:

Risiken manueller Deployments:

Runbooks und Checklisten reduzieren diese Risiken.

Release-Kalender

Ein Release-Kalender zeigt geplante Releases und wichtige Change-Zeitpunkte.

Er hilft bei:

Ein Release-Kalender sollte für relevante Teams sichtbar sein.

Change Freeze und Release Freeze

Ein Freeze ist ein Zeitraum, in dem Releases oder Changes eingeschränkt werden.

Beispiele:

Ein Freeze bedeutet nicht zwingend, dass gar nichts geändert werden darf.

Sicherheitsupdates oder Emergency Changes können trotzdem notwendig sein.

Dann muss besonders bewusst entschieden und dokumentiert werden.

Kommunikation vor einem Release

Vor einem Release sollten betroffene Gruppen informiert werden.

Mögliche Inhalte:

Der Service Desk muss besonders gut vorbereitet sein.

Service Desk vorbereiten

Der Service Desk benötigt vor einem Release:

Ohne Vorbereitung steigen nach einem Release unnötige Tickets und Rückfragen.

Monitoring während und nach Deployment

Während und nach einem Deployment sollte Monitoring aktiv beobachtet werden.

Zu prüfen sind:

Nach kritischen Releases kann eine verstärkte Beobachtungsphase sinnvoll sein.

Rollback und Roll Forward

Bei Problemen nach einem Deployment gibt es zwei grundsätzliche Richtungen.

Ansatz Bedeutung
Rollback Rückkehr zum vorherigen Zustand
Roll Forward Vorwärtskorrektur durch neue Änderung oder Hotfix

Rollback ist nicht immer möglich.

Roll Forward kann sinnvoll sein, wenn:

Beide Wege benötigen Entscheidung, Dokumentation und Risikobewertung.

Release-Erfolg prüfen

Nach einem Release sollte geprüft werden:

Ein Release ist nicht erfolgreich, nur weil Dateien deployed wurden.

Es muss aus Service- und Benutzersicht funktionieren.

Post-Deployment Review

Ein Post-Deployment Review kann nach wichtigen Deployments sinnvoll sein.

Fragen:

Nicht jedes kleine Deployment benötigt ein ausführliches Review.

Bei kritischen oder fehlgeschlagenen Deployments ist es wichtig.

Release Management und Knowledge Management

Nach einem Release müssen Wissensbestände aktualisiert werden.

Mögliche Inhalte:

Veraltete Knowledge-Artikel erzeugen nach Releases häufig neue Tickets.

Release Management und Configuration Management

Nach Releases und Deployments müssen Configuration Items aktuell bleiben.

Mögliche Änderungen:

Wenn die CMDB veraltet bleibt, werden spätere Incidents, Problems und Changes schwieriger.

Release Management und Incident Management

Nach Releases können Incidents entstehen.

Deshalb sollte Incident Management vorbereitet sein.

Wichtig:

Ein Anstieg von Incidents nach einem Release kann auf Probleme in Test, Kommunikation oder Deployment hinweisen.

Release Management und Problem Management

Wenn nach einem Release wiederkehrende oder schwere Incidents entstehen, kann ein Problem Record notwendig sein.

Problem Management prüft dann:

Release Management und Change Enablement

Change Enablement sorgt dafür, dass Releases und Deployments kontrolliert umgesetzt werden.

Zu klären ist:

Release und Deployment sollten nicht an Change Enablement vorbei erfolgen.

Praxisbeispiel: VPN-Client-Rollout

Ausgangslage

Eine alte VPN-Client-Version verursacht wiederkehrende Incidents.

Release

Neue VPN-Client-Version wird bereitgestellt.

Deployment

Erfolgskontrolle

VPN-Incidents gehen zurück.

Known Error wird aktualisiert.

Knowledge-Artikel wird angepasst.

Praxisbeispiel: Mitarbeiterportal

Ausgangslage

Das Mitarbeiterportal erhält neue Funktionen.

Release Management

Deployment Management

Nachbereitung

Incidents nach Release beobachten und Knowledge-Artikel aktualisieren.

Praxisbeispiel: Fehlgeschlagenes Deployment

Situation

Eine neue Anwendungsversion wird erfolgreich installiert.

Problem

Nach dem Deployment funktioniert der PDF-Export nicht mehr.

Maßnahmen

Lerneffekt

Der Testplan muss künftig auch Exportfunktionen abdecken.

Typische Fehler

Fehler 1

Release und Deployment werden gleichgesetzt.

Fehler 2

Technisches Deployment gelingt, aber Benutzer sind nicht vorbereitet.

Fehler 3

Service Desk erhält keine Release-Informationen.

Fehler 4

Release Notes fehlen oder sind zu technisch.

Fehler 5

Tests decken wichtige Geschäftsprozesse nicht ab.

Fehler 6

Rollback wird nicht realistisch geplant.

Fehler 7

Mehrere Releases kollidieren zeitlich.

Fehler 8

Monitoring wird nach Deployment nicht beobachtet.

Fehler 9

Known Errors und Workarounds werden nicht dokumentiert.

Fehler 10

CMDB und Knowledge Base bleiben nach Release veraltet.

Fehler 11

Fehlgeschlagene Deployments werden nicht ausgewertet.

Fehler 12

Automatisierung wird genutzt, aber nicht überwacht.

Checkliste Release Management

Checkliste Deployment Management

Checkliste Kommunikation

Checkliste Nachbereitung

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker sind häufig direkt an Deployments beteiligt.

Im Alltag bedeutet das:

Gute technische Bereitstellung bedeutet nicht nur:

Installation erfolgreich.

Sondern:

Service funktioniert, Benutzer sind arbeitsfähig, Support ist vorbereitet und Dokumentation stimmt.

Zusammenfassung

Release-Inhalt festlegen
↓
Changes, Risiken und Abhängigkeiten prüfen
↓
Deployment vorbereiten
↓
Service Desk und Benutzer informieren
↓
technische Bereitstellung durchführen
↓
Smoke Test und Monitoring prüfen
↓
Release aus Benutzersicht bewerten
↓
Incidents und Feedback beobachten
↓
Knowledge, CMDB und Runbooks aktualisieren
↓
Lessons Learned übernehmen

Merksätze

Release Management betrachtet die Bereitstellung aus Service- und Benutzersicht.

Deployment Management betrachtet die technische Überführung in eine Zielumgebung.

Ein erfolgreiches Deployment ist nicht automatisch ein erfolgreiches Release.

Service Desk und Benutzer müssen auf wichtige Releases vorbereitet sein.

Rollback und Kommunikation gehören vor dem Deployment geplant.

Nach einem Release müssen Knowledge, CMDB und Monitoring geprüft werden.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

5. Change Enablement

5.5 Change-Erfolg messen und Continual Improvement

Kurz erklärt

Ein Change ist nicht automatisch erfolgreich, nur weil er technisch durchgeführt wurde.

Erfolgreich ist ein Change erst dann, wenn der gewünschte Nutzen erreicht wurde, der Service stabil bleibt, Benutzer arbeitsfähig sind und keine unvertretbaren Nebenwirkungen entstehen.

Deshalb müssen Changes nach der Umsetzung bewertet, dokumentiert und für zukünftige Verbesserungen genutzt werden.

Warum Change-Erfolg gemessen werden muss

Ohne Erfolgsmessung bleibt unklar, ob ein Change wirklich sinnvoll war.

Mögliche Fragen:

Change-Erfolg bedeutet mehr als:

Umsetzung abgeschlossen.

Entscheidend ist das Ergebnis aus Service-, Benutzer- und Betriebssicht.

Technische Umsetzung und Service-Erfolg unterscheiden

Technische Umsetzung Service-Erfolg
Paket wurde installiert Benutzer können wieder arbeiten
Konfiguration wurde geändert Service funktioniert stabil
Server wurde aktualisiert abhängige Systeme funktionieren weiterhin
Firewall-Regel wurde gesetzt Schnittstelle funktioniert sicher und erwartungsgemäß
Zertifikat wurde erneuert Anmeldung funktioniert ohne neue Störungen
Deployment ist abgeschlossen Release erzeugt den gewünschten Nutzen

Ein Change kann technisch erfolgreich sein und trotzdem aus Service-Sicht Probleme verursachen.

Beispiel:

Eine neue Anwendungsversion wurde korrekt installiert.

Nach dem Update funktioniert jedoch der Export für die Buchhaltung nicht mehr.

Technisch war das Deployment erfolgreich.

Aus Sicht des Services ist der Change nur teilweise erfolgreich oder fehlgeschlagen.

Erfolgskriterien vorab festlegen

Erfolg sollte vor der Umsetzung definiert werden.

Gute Erfolgskriterien sind:

Beispiele:

Change mögliches Erfolgskriterium
VPN-Client aktualisieren VPN-Incidents sinken innerhalb von vier Wochen deutlich
Zertifikat erneuern Anmeldung funktioniert und Monitoring erkennt zukünftige Abläufe
Firewall-Regel setzen gewünschte Verbindung funktioniert, keine unerwarteten Freigaben
Anwendung aktualisieren Kernfunktionen funktionieren nach Smoke Test und Fachbereichstest
Monitoring erweitern relevante Warnung wird korrekt ausgelöst und an richtiges Team gesendet
Druckertreiber aktualisieren Etikettendruck funktioniert und Incidents treten nicht erneut auf

Ohne Erfolgskriterien wird die Nachprüfung ungenau.

Mögliche Kennzahlen für Change-Erfolg

Bereich mögliche Kennzahl
Umsetzung Anteil erfolgreich abgeschlossener Changes
Qualität Anzahl fehlgeschlagener Changes
Stabilität Incidents nach Changes
Risiko Anzahl Emergency Changes
Planung Anteil Changes mit Rollback-Plan
Kommunikation Beschwerden oder Rückfragen nach Change
Geschwindigkeit Durchlaufzeit von Change Request bis Umsetzung
Wirkung Rückgang wiederkehrender Incidents
Wissen aktualisierte Knowledge-Artikel nach Change
Verbesserung Lessons Learned umgesetzt

Nicht jede Organisation benötigt alle Kennzahlen.

Wichtig ist, dass die Kennzahlen Entscheidungen und Verbesserungen unterstützen.

Change Success Rate

Die Change Success Rate beschreibt den Anteil der Changes, die erfolgreich umgesetzt wurden.

Vorsicht:

Eine hohe Erfolgsquote ist nur sinnvoll, wenn klar definiert ist, was „erfolgreich“ bedeutet.

Ungeeignet:

Change wurde durchgeführt, also erfolgreich.

Besser:

Change wurde wie geplant durchgeführt, Erfolgskriterien wurden erreicht, keine relevanten Incidents entstanden, Dokumentation wurde aktualisiert.

Eine zu einfache Erfolgsdefinition verfälscht die Kennzahl.

Failed Changes

Ein Failed Change ist eine Änderung, die nicht wie geplant erfolgreich war oder unerwünschte Auswirkungen verursacht hat.

Mögliche Beispiele:

Failed Changes sind wichtige Lernquellen.

Sie sollten nicht versteckt oder beschönigt werden.

Incidents nach Changes

Eine wichtige Kennzahl ist die Anzahl der Incidents, die nach Changes entstehen.

Zu prüfen ist:

Nicht jeder Incident nach einem Change wurde durch den Change verursacht.

Der zeitliche Zusammenhang ist ein Hinweis, aber kein Beweis.

Emergency-Change-Quote

Eine hohe Anzahl von Emergency Changes kann auf Probleme hinweisen.

Mögliche Ursachen:

Emergency Changes sind manchmal notwendig.

Wenn sie aber zur Regel werden, sollte das Change-Modell überprüft werden.

Rollback-Quote

Die Rollback-Quote zeigt, wie oft Changes zurückgenommen werden mussten.

Eine hohe Quote kann hinweisen auf:

Eine niedrige Rollback-Quote ist nicht automatisch gut.

Sie kann auch bedeuten, dass bei Problemen kein funktionierender Rollback vorhanden war.

Durchlaufzeit von Changes

Die Durchlaufzeit beschreibt, wie lange ein Change von der Anforderung bis zur Umsetzung benötigt.

Zu betrachten sind:

Lange Durchlaufzeiten können auf Engpässe hinweisen.

Beispiele:

Qualität der Change Requests

Die Qualität eines Change Requests beeinflusst die gesamte Bearbeitung.

Zu prüfen ist:

Unvollständige Change Requests führen zu Rückfragen, Verzögerungen und höheren Risiken.

Change-Kalender auswerten

Ein Change-Kalender zeigt nicht nur geplante Änderungen.

Er kann auch zur Verbesserung genutzt werden.

Zu prüfen ist:

Ein gut gepflegter Change-Kalender reduziert Konflikte und Überraschungen.

Post Implementation Review

Ein Post Implementation Review prüft nach der Umsetzung, ob der Change erfolgreich war.

Mögliche Fragen:

Nicht jeder kleine Standard Change benötigt ein ausführliches Review.

Bei risikoreichen, fehlgeschlagenen oder besonders wichtigen Changes ist es sehr sinnvoll.

Review nach Emergency Changes

Emergency Changes sollten besonders sorgfältig nachbereitet werden.

Zu prüfen ist:

Ziel ist nicht, die schnelle Entscheidung nachträglich zu bestrafen.

Ziel ist, zukünftige Notfälle zu vermeiden.

Review nach Failed Changes

Ein Failed Change sollte analysiert werden.

Mögliche Fragen:

Failed Changes sind wichtige Daten für Continual Improvement.

Lessons Learned

Lessons Learned sind Erkenntnisse aus erfolgreichen und fehlgeschlagenen Changes.

Mögliche Ergebnisse:

Lessons Learned sind nur wertvoll, wenn daraus konkrete Maßnahmen entstehen.

Continual Improvement im Change Enablement

Change Enablement sollte selbst kontinuierlich verbessert werden.

Möglicher Ablauf:

Change-Daten sammeln
        ↓
Trends und Schwachstellen erkennen
        ↓
Verbesserungsidee erfassen
        ↓
Nutzen und Aufwand bewerten
        ↓
Maßnahme umsetzen
        ↓
Wirkung messen
        ↓
Change-Modell anpassen

Verbesserung kann sich auf Prozesse, Werkzeuge, Kommunikation, Vorlagen, Automatisierung oder Rollen beziehen.

Improvement Register

Verbesserungsideen aus Change Reviews sollten nicht verloren gehen.

Ein Improvement Register kann enthalten:

Beispiele:

Standard Changes regelmäßig überprüfen

Standard Changes sind vorab genehmigt.

Trotzdem müssen sie regelmäßig geprüft werden.

Fragen:

Ein Standard Change darf nicht dauerhaft ungeprüft bleiben.

Change-Modell anpassen

Ein Change-Modell beschreibt, wie bestimmte Change-Arten bearbeitet werden.

Es sollte angepasst werden, wenn:

Ein gutes Change-Modell ist stabil, aber nicht starr.

Automatisierung im Change Enablement

Automatisierung kann Change Enablement verbessern.

Beispiele:

Automatisierung muss aber kontrolliert werden.

Ein falsch automatisierter Change-Prozess kann Fehler schneller verbreiten.

Change-Datenqualität verbessern

Gute Auswertung benötigt gute Daten.

Probleme entstehen durch:

Eine wichtige Verbesserung kann darin bestehen, die Pflichtinformationen im Change-Prozess zu verbessern.

Zusammenhang mit Problem Management

Problem Management ist besonders wichtig für Change-Erfolg.

Ein Change kann:

Nach einem Change zur Problemlösung sollte geprüft werden:

Zusammenhang mit Knowledge Management

Nach Changes muss Wissen aktuell bleiben.

Zu prüfen ist:

Ein Change kann technisch erfolgreich sein und trotzdem Supportprobleme verursachen, wenn Knowledge veraltet bleibt.

Zusammenhang mit Service Configuration Management

Nach Changes müssen Configuration Items und Beziehungen aktuell bleiben.

Zu prüfen ist:

Eine veraltete CMDB erschwert zukünftige Incidents, Problems und Changes.

Zusammenhang mit Measurement and Reporting

Measurement and Reporting unterstützt Change Enablement durch:

Wichtig ist, nicht nur Zahlen zu zeigen.

Berichte sollten erklären:

Beispiel: Failed Change

Situation

Ein Anwendungspatch wurde eingespielt.

Problem

Nach dem Patch funktioniert der PDF-Export nicht mehr.

Analyse

Verbesserungen

Beispiel: Zu viele Emergency Changes

Beobachtung

Emergency Changes nehmen über mehrere Monate zu.

Analyse

Viele Emergency Changes betreffen ablaufende Zertifikate und Speicherplatzprobleme.

Ursachen

Verbesserungen

Beispiel: Standard Change verbessern

Situation

Standardsoftware wird über ein Portal bereitgestellt.

Problem

Viele Requests schlagen fehl, weil Geräte nicht erreichbar sind.

Analyse

Verbesserungen

Typische Fehler

Fehler 1

Change gilt als erfolgreich, nur weil er technisch durchgeführt wurde.

Fehler 2

Erfolgskriterien werden nicht vorab definiert.

Fehler 3

Incidents nach Changes werden nicht ausgewertet.

Fehler 4

Failed Changes werden beschönigt oder nicht dokumentiert.

Fehler 5

Emergency Changes werden nicht nachbereitet.

Fehler 6

Lessons Learned werden gesammelt, aber nicht umgesetzt.

Fehler 7

Standard Changes werden nie überprüft.

Fehler 8

Kennzahlen erzeugen falsche Anreize.

Fehler 9

Change-Datenqualität ist schlecht.

Fehler 10

Knowledge Base und CMDB werden nach Changes nicht aktualisiert.

Fehler 11

Review-Fragen konzentrieren sich nur auf Technik, nicht auf Servicewirkung.

Fehler 12

Verbesserungen bleiben ohne Verantwortlichen und Termin.

Problematische Kennzahlen

Kennzahl möglicher Fehlanreiz
möglichst viele Changes unnötige oder schlecht geplante Änderungen
sehr kurze Durchlaufzeit unzureichende Prüfung
hohe Erfolgsquote Fehler werden nicht ehrlich dokumentiert
wenige Emergency Changes dringende Fälle werden falsch klassifiziert
wenige Failed Changes Teams melden Fehlschläge nicht transparent
niedrige Rollback-Quote Rollback fehlt oder wird vermieden

Kennzahlen müssen deshalb immer mit Kontext betrachtet werden.

Gute Kennzahlenkombinationen

Sinnvoll ist eine kombinierte Betrachtung.

Beispiele:

Einzelne Kennzahlen können täuschen.

Kombinationen zeigen bessere Zusammenhänge.

Checkliste Change-Erfolg prüfen

Checkliste Post Implementation Review

Checkliste Failed Change

Checkliste Continual Improvement im Change Enablement

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker tragen wesentlich dazu bei, ob Change-Erfolg messbar und nachvollziehbar ist.

Im Arbeitsalltag bedeutet das:

Gute technische Arbeit endet nicht beim erfolgreichen Befehl.

Sie endet erst, wenn der Service stabil funktioniert und die Änderung nachvollziehbar abgeschlossen ist.

Zusammenfassung

Change-Ziel und Erfolgskriterien festlegen
↓
Change durchführen
↓
technisches Ergebnis prüfen
↓
Benutzer-Outcome und Servicewirkung prüfen
↓
Incidents, Monitoring und Feedback auswerten
↓
Failed Changes und Emergency Changes reviewen
↓
Knowledge, CMDB und Dokumentation aktualisieren
↓
Lessons Learned erfassen
↓
Verbesserungen verfolgen
↓
Change-Modell kontinuierlich verbessern

Merksätze

Ein Change ist nicht erfolgreich, nur weil er durchgeführt wurde.

Erfolg muss aus Service- und Benutzersicht geprüft werden.

Failed Changes sind Lernquellen.

Emergency Changes benötigen Nachbereitung.

Kennzahlen ohne Kontext erzeugen falsche Schlüsse.

Lessons Learned sind nur wertvoll, wenn sie umgesetzt werden.

Change Enablement selbst muss kontinuierlich verbessert werden.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

6. Service Configuration Management

6. Service Configuration Management

6.1 Service Configuration Management – Ziele, Begriffe und Grundlagen

Kurz erklärt

Service Configuration Management sorgt dafür, dass wichtige Informationen über Services, Systeme, Komponenten und deren Beziehungen nachvollziehbar gepflegt werden.

Ziel ist, zu wissen:

Dadurch können Incidents, Problems, Changes und Releases besser bewertet und gesteuert werden.

Warum Service Configuration Management wichtig ist

IT-Services bestehen selten aus nur einer einzelnen Komponente.

Ein scheinbar einfacher Service kann abhängig sein von:

Wenn diese Zusammenhänge unbekannt sind, entstehen Risiken:

Service Configuration Management schafft dafür eine nachvollziehbare Informationsbasis.

Was ist eine Configuration?

Eine Configuration beschreibt, wie ein Service oder System aufgebaut ist.

Dazu gehören beispielsweise:

Beispiel:

Der Service „VPN-Zugang“ besteht nicht nur aus dem VPN-Gateway.

Er kann abhängig sein von:

Configuration Item

Ein Configuration Item (CI) ist ein Bestandteil, der für die Bereitstellung oder Verwaltung eines Service relevant ist.

Beispiele:

Nicht jedes technische Objekt muss automatisch ein CI sein.

Die Organisation muss festlegen, welche Elemente wichtig genug sind, um verwaltet zu werden.

Beispiele für Configuration Items

CI-Typ Beispiel
Service Mitarbeiterportal
Anwendung Warenwirtschaft
Server APP-WEB-01
Datenbank SQL-Cluster Produktion
Netzwerk Standort-Firewall
Cloud Azure App Service
Sicherheit TLS-Zertifikat
Identität Entra-ID-Gruppe
Dokumentation Betriebsrunbook
Lieferant Supportvertrag Provider
Arbeitsplatz Notebook
Peripherie Etikettendrucker

Welche CI-Typen sinnvoll sind, hängt von Organisation, Services und Steuerungsbedarf ab.

Ziel von Service Configuration Management

Service Configuration Management soll sicherstellen, dass verlässliche Informationen verfügbar sind über:

Diese Informationen unterstützen andere ITIL Practices.

Beispiele:

Service Configuration Management ist mehr als Inventarisierung

Inventarisierung beantwortet oft nur:

Was ist vorhanden?

Service Configuration Management beantwortet zusätzlich:

Wie hängt es zusammen und warum ist es für den Service wichtig?

Beispiel:

Eine Inventarliste zeigt:

Service Configuration Management zeigt zusätzlich:

Diese Beziehungen machen die Informationen im Betrieb wertvoll.

CI-Beziehungen

Beziehungen zwischen CIs sind besonders wichtig.

Typische Beziehungen:

Beziehungen helfen zu verstehen, welche Auswirkungen ein Ausfall oder Change haben kann.

Beispiel: Serviceabhängigkeiten

Benutzer
    ↓
Mitarbeiterportal
    ↓
Webserver
    ↓
Anwendungsdienst
    ↓
Datenbank
    ↓
Storage

Zusätzlich abhängig von:

Wenn die Datenbank ausfällt, ist das Mitarbeiterportal betroffen.

Wenn das Zertifikat abläuft, kann die Anmeldung scheitern.

Wenn DNS fehlerhaft ist, erscheint der Service möglicherweise komplett unerreichbar.

CMDB

Eine Configuration Management Database (CMDB) ist ein System oder Datenbestand, in dem Configuration Items und ihre Beziehungen verwaltet werden.

Eine CMDB kann enthalten:

Eine CMDB muss nicht zwingend ein einzelnes großes Werkzeug sein.

Wichtig ist, dass die benötigten Informationen zuverlässig verfügbar und gepflegt sind.

CMDB und CMS unterscheiden

Der Begriff Configuration Management System (CMS) kann breiter verstanden werden als eine einzelne CMDB.

Ein CMS kann mehrere Datenquellen verbinden.

Beispiele:

Die CMDB kann ein Teil dieses größeren Systems sein.

Configuration Management und Asset Management unterscheiden

Configuration Management Asset Management
Fokus auf Servicebeziehungen und Betriebsrelevanz Fokus auf Besitz, Kosten, Lebenszyklus und Vertragsdaten
betrachtet CIs und Abhängigkeiten betrachtet Assets als wirtschaftliche oder verwaltete Objekte
wichtig für Incident, Problem und Change wichtig für Einkauf, Lizenzierung und Lifecycle
Beispiel: Datenbank ist abhängig von Storage Beispiel: Server wurde am 12.03.2025 gekauft

Ein Objekt kann gleichzeitig Asset und CI sein.

Beispiel:

Ein produktiver Server ist wirtschaftlich ein Asset und betrieblich ein CI.

Welche Informationen sind sinnvoll?

Nicht jedes Detail muss erfasst werden.

Sinnvolle CI-Informationen können sein:

Zu viele ungenutzte Felder machen Pflege schwer.

Zu wenige Informationen machen die Daten im Betrieb wertlos.

CI-Status

Ein CI kann unterschiedliche Status besitzen.

Beispiele:

Der Status hilft zu erkennen, ob ein CI produktiv genutzt wird oder nicht.

Beispiel:

Ein alter Server darf nicht mehr als aktive Abhängigkeit eines produktiven Services erscheinen, wenn er bereits außer Betrieb genommen wurde.

Umgebungen kennzeichnen

CIs sollten ihrer Umgebung zugeordnet werden.

Beispiele:

Das ist wichtig, weil ein Change an einem Testsystem anders bewertet wird als ein Change an einem produktiven System.

Unklare Umgebungskennzeichnung kann zu gefährlichen Verwechslungen führen.

Kritikalität erfassen

Die Kritikalität beschreibt, wie wichtig ein CI oder Service für die Organisation ist.

Beispiele:

Die Kritikalität hilft bei:

Wichtig:

Die Kritikalität eines CIs sollte aus der Servicebedeutung abgeleitet werden.

Owner und Verantwortlichkeiten

Für wichtige CIs sollte klar sein:

Ohne Owner veralten Informationen schnell.

Ungeeignet:

Niemand fühlt sich für das System verantwortlich.

Besser:

Service Owner, technischer Owner und Supportgruppe sind dokumentiert.

Service Owner und CI Owner unterscheiden

Rolle Bedeutung
Service Owner Verantwortung für den gesamten Service und dessen Wertbeitrag
CI Owner Verantwortung für ein bestimmtes Configuration Item
Supportgruppe bearbeitet Incidents, Changes oder Betriebsaufgaben
Lieferant unterstützt oder betreibt bestimmte Komponenten

Ein Service kann viele CIs besitzen.

Ein CI kann mehrere Services unterstützen.

Deshalb sind Beziehungen und Verantwortlichkeiten wichtig.

Datenqualität

Service Configuration Management ist nur hilfreich, wenn die Datenqualität ausreichend ist.

Typische Probleme:

Schlechte Datenqualität kann gefährlicher sein als keine Daten, weil sie falsche Sicherheit erzeugt.

Datenqualität prüfen

Mögliche Prüffragen:

Regelmäßige Prüfung ist notwendig, besonders bei kritischen Services.

Discovery

Discovery bezeichnet das automatische Erkennen von Systemen, Komponenten oder technischen Eigenschaften.

Beispiele:

Discovery kann helfen, Daten aktuell zu halten.

Es ersetzt aber nicht jede fachliche Bewertung.

Ein Tool kann erkennen, dass ein Server existiert.

Es weiß nicht automatisch, welcher Geschäftsprozess davon abhängig ist.

Manuelle Pflege

Manche Informationen müssen manuell oder organisatorisch gepflegt werden.

Beispiele:

Automatische Erkennung und manuelle Pflege müssen zusammenarbeiten.

Namenskonventionen

Klare Namenskonventionen helfen, CIs eindeutig zu identifizieren.

Beispiele:

Ungeeignet:

Besser:

Die konkrete Namenskonvention muss zur Organisation passen.

Configuration Baseline

Eine Configuration Baseline beschreibt einen bekannten, freigegebenen Zustand.

Beispiele:

Baselines helfen bei:

Wenn ein System von der Baseline abweicht, sollte bekannt sein, warum.

Abweichungen erkennen

Abweichungen können entstehen durch:

Abweichungen sind nicht automatisch falsch.

Sie müssen aber nachvollziehbar und bewertet sein.

Service Configuration Management und Incident Management

Bei Incidents helfen Configuration-Daten zu verstehen:

Beispiel:

Eine Anwendung ist nicht erreichbar.

Durch CI-Beziehungen wird sichtbar, dass Anwendung, Datenbank und Identity Provider relevant sind.

Die Diagnose wird schneller und gezielter.

Service Configuration Management und Problem Management

Problem Management nutzt Configuration-Daten, um Ursachen zu erkennen.

Beispiele:

Ohne Beziehungen bleiben solche Muster oft verborgen.

Service Configuration Management und Change Enablement

Bei Changes helfen Configuration-Daten bei der Auswirkungsbewertung.

Zu prüfen ist:

Ein Change ohne Kenntnis der Abhängigkeiten kann unerwartete Incidents erzeugen.

Service Configuration Management und Release Management

Release und Deployment benötigen verlässliche Informationen über:

Nach einem Release müssen CI-Daten aktualisiert werden.

Sonst stimmen spätere Analysen nicht mehr.

Service Configuration Management und Information Security Management

Configuration-Daten unterstützen Sicherheitsarbeit.

Beispiele:

Sicherheitsmaßnahmen hängen stark davon ab, zu wissen, welche Systeme und Abhängigkeiten existieren.

Praxisbeispiel: Abgelaufenes Zertifikat

Incident

Benutzer können sich nicht am Mitarbeiterportal anmelden.

Analyse

Das TLS-Zertifikat ist abgelaufen.

Configuration Management hilft durch:

Verbesserung

Zertifikate werden künftig als CIs mit Ablaufdatum, Owner und Monitoring erfasst.

Praxisbeispiel: Datenbankcluster

Situation

Mehrere Anwendungen melden Fehler.

Ohne CI-Beziehungen

Jedes Anwendungsteam sucht getrennt.

Mit CI-Beziehungen

Es wird sichtbar:

Nutzen

Die Ursache wird schneller eingegrenzt.

Praxisbeispiel: Change-Auswirkung

Change

Firewall-Regel soll angepasst werden.

Configuration Management zeigt:

Nutzen

Der Change wird besser bewertet und sicherer umgesetzt.

Typische Fehler

Fehler 1

CMDB wird als reine Inventarliste verstanden.

Fehler 2

CIs werden erfasst, aber Beziehungen fehlen.

Fehler 3

Daten werden einmal erstellt und danach nicht gepflegt.

Fehler 4

Owner sind unbekannt oder veraltet.

Fehler 5

Changes aktualisieren die CMDB nicht.

Fehler 6

Discovery-Daten werden ungeprüft übernommen.

Fehler 7

Zu viele unwichtige Details werden gepflegt, aber wichtige Servicebeziehungen fehlen.

Fehler 8

Cloud-Ressourcen und externe Services werden nicht berücksichtigt.

Fehler 9

CMDB-Daten werden in Incident, Problem und Change nicht genutzt.

Fehler 10

Dubletten und uneinheitliche Namen erschweren die Nutzung.

Fehler 11

Kritikalität wird technisch statt geschäftlich bewertet.

Fehler 12

Dokumentation und CMDB widersprechen sich.

Checkliste CI erfassen

Checkliste Beziehungen prüfen

Checkliste Datenqualität

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten täglich mit Configuration Items.

Beispiele:

Wichtig ist nicht nur, diese Komponenten technisch zu betreiben.

Wichtig ist auch zu dokumentieren:

Gute Configuration-Daten machen Fehleranalyse, Changes und Servicebetrieb deutlich sicherer.

Zusammenfassung

Service und Komponenten identifizieren
↓
wichtige Configuration Items festlegen
↓
Eigenschaften und Owner dokumentieren
↓
Beziehungen zwischen CIs erfassen
↓
Datenqualität prüfen
↓
Changes und Releases einbeziehen
↓
Informationen in Incident, Problem und Change nutzen
↓
CMDB oder CMS kontinuierlich pflegen und verbessern

Merksätze

Service Configuration Management ist mehr als Inventarisierung.

Beziehungen zwischen CIs sind oft wichtiger als einzelne technische Details.

Eine CMDB ist nur so wertvoll wie ihre Datenqualität.

Discovery hilft, ersetzt aber keine fachliche Verantwortung.

Ohne aktuelle Configuration-Daten werden Incidents, Problems und Changes riskanter.

Jede wichtige Änderung sollte auch die Configuration-Daten aktualisieren.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

6. Service Configuration Management

6.2 Configuration Items und Beziehungen

Kurz erklärt

Ein Configuration Item (CI) ist ein Bestandteil, der für einen IT-Service wichtig ist und deshalb verwaltet werden soll.

Beziehungen zwischen CIs zeigen, wie Services, Anwendungen, Systeme, Netzwerke, Datenbanken, Zertifikate, Lieferanten und andere Bestandteile zusammenhängen.

Der eigentliche Wert entsteht nicht nur durch die Liste einzelner CIs, sondern durch das Verständnis ihrer Abhängigkeiten.

Warum Configuration Items wichtig sind

IT-Services bestehen meistens aus mehreren technischen und organisatorischen Bestandteilen.

Beispiel:

Ein Mitarbeiterportal kann abhängig sein von:

Wenn diese Bestandteile nicht bekannt sind, werden Incidents, Problems und Changes schwieriger.

Configuration Items helfen dabei, diese Bestandteile strukturiert zu erfassen.

Was ist ein Configuration Item?

Ein Configuration Item ist ein Element, das für die Bereitstellung, den Betrieb, die Steuerung oder die Unterstützung eines Service relevant ist.

Ein CI kann technisch oder nicht-technisch sein.

Beispiele:

Nicht jedes vorhandene Objekt muss automatisch ein CI sein.

Entscheidend ist, ob das Objekt für Servicebetrieb, Risiko, Support, Change oder Steuerung relevant ist.

CI ist nicht gleich Asset

Ein Asset ist häufig ein wirtschaftlich oder vertraglich relevantes Objekt.

Ein CI ist ein für den Servicebetrieb relevantes Objekt.

Asset Configuration Item
Fokus auf Besitz, Kosten, Vertrag oder Lebenszyklus Fokus auf Servicebeziehung, Abhängigkeit und Betrieb
wichtig für Einkauf und Lizenzierung wichtig für Incident, Problem, Change und Release
Beispiel: Notebook mit Kaufdatum Beispiel: Notebook als Teil eines verwalteten Arbeitsplatzservices
Beispiel: Server als Anlagegut Beispiel: Server als Bestandteil einer produktiven Anwendung

Ein Objekt kann gleichzeitig Asset und CI sein.

Beispiel:

Ein produktiver Datenbankserver ist ein Asset und gleichzeitig ein CI.

Welche Objekte sollten als CI erfasst werden?

Ein Objekt sollte eher als CI erfasst werden, wenn:

Ein Objekt muss nicht erfasst werden, nur weil es technisch existiert.

Die Pflege muss einen praktischen Nutzen haben.

Beispiele für CI-Typen

CI-Typ Beispiel
Business Service Mitarbeiterportal
Technical Service Datenbankplattform
Anwendung Warenwirtschaft
Server PRD-APP-PORTAL-01
Datenbank SQL-Cluster Produktion
Netzwerkgerät Standort-Firewall
Cloud-Ressource App Service, Storage Account
Sicherheit TLS-Zertifikat, MFA-Richtlinie
Identität Entra-ID-Gruppe
Schnittstelle REST-API zum ERP-System
Monitoring Alarmregel für Zertifikatsablauf
Backup Backupjob für Datenbank
Dokumentation Betriebsrunbook
Lieferant Supportvertrag Provider

Die CI-Typen sollten zur Organisation passen.

Zu viele CI-Typen können die Pflege unnötig erschweren.

Zu wenige CI-Typen können wichtige Unterschiede verdecken.

Service-CI und technische CIs unterscheiden

Ein Service selbst kann als CI betrachtet werden.

Beispiel:

Der Service ist das, was Benutzer wahrnehmen.

Die technischen CIs sind Bestandteile, die den Service ermöglichen.

Diese Unterscheidung hilft, technische Informationen mit Benutzer- und Geschäftsbezug zu verbinden.

Attribute eines Configuration Items

Ein CI sollte nur so viele Attribute besitzen, wie sinnvoll gepflegt und genutzt werden können.

Mögliche Attribute:

Wichtig ist nicht maximale Datenmenge.

Wichtig ist nutzbare Datenqualität.

CI-Name

Der CI-Name sollte eindeutig und verständlich sein.

Ungeeignet:

Besser:

Eine Namenskonvention kann enthalten:

Die konkrete Namenskonvention muss zur Organisation passen.

CI-Status

Der Status zeigt, in welchem Zustand sich ein CI befindet.

Mögliche Status:

Der Status ist wichtig für:

Ein CI, das außer Betrieb ist, sollte nicht mehr als aktive Abhängigkeit eines produktiven Services erscheinen.

Umgebung

Die Umgebung zeigt, wo ein CI genutzt wird.

Beispiele:

Ein Change an einem Testsystem ist anders zu bewerten als ein Change an einem produktiven System.

Fehlende Umgebungskennzeichnung kann gefährlich sein.

Beispiel:

Ein Administrator führt eine Änderung auf einem System aus, das für Test gehalten wird, tatsächlich aber produktiv ist.

Version und Konfiguration

Für viele CIs ist die Version wichtig.

Beispiele:

Versionen helfen bei:

Beispiel:

Wenn nur VPN-Client-Version 5.8 betroffen ist, muss diese Information auffindbar sein.

Owner und Supportgruppe

Für wichtige CIs sollte klar sein:

Unklare Verantwortlichkeiten führen zu Verzögerungen.

Ungeeignet:

Niemand weiß, wem dieser Server gehört.

Besser:

Service Owner, technischer Owner, Supportgruppe und Lieferant sind dokumentiert.

Kritikalität

Die Kritikalität beschreibt, wie wichtig ein CI oder der zugehörige Service ist.

Mögliche Stufen:

Die Kritikalität beeinflusst:

Wichtig:

Die Kritikalität sollte nicht nur technisch bewertet werden.

Ein unscheinbarer Server kann geschäftskritisch sein, wenn ein zentraler Prozess davon abhängt.

Sicherheitsklassifizierung

Manche CIs benötigen zusätzliche Sicherheitsinformationen.

Beispiele:

Solche Informationen helfen bei:

Was sind CI-Beziehungen?

CI-Beziehungen beschreiben, wie Configuration Items miteinander verbunden sind.

Beispiele:

Beziehungen machen sichtbar, welche Auswirkungen ein Ausfall oder Change haben kann.

Warum Beziehungen wichtiger sind als Einzelinformationen

Eine Liste einzelner CIs beantwortet nur:

Was gibt es?

Beziehungen beantworten:

Was hängt wovon ab?

Beispiel:

CI-Liste:

Beziehungen:

Erst durch Beziehungen wird klar, welche Komponenten gemeinsam einen Service ermöglichen.

Typische Beziehungstypen

Beziehung Bedeutung
nutzt Ein CI verwendet ein anderes CI
läuft auf Anwendung läuft auf Server oder Plattform
ist abhängig von Service funktioniert nur mit anderem CI
verbindet zu Netzwerk- oder Schnittstellenbeziehung
wird überwacht von Monitoringbeziehung
wird gesichert durch Backupbeziehung
wird unterstützt von Lieferanten- oder Supportbeziehung
ist Teil von Komponente gehört zu größerem Service
ersetzt neues CI ersetzt altes CI
kommuniziert mit technische Schnittstelle zwischen Systemen

Die Beziehungsarten sollten verständlich und einheitlich genutzt werden.

Beispiel: Mitarbeiterportal

Mitarbeiterportal
    ↓ nutzt
Portal-Anwendung
    ↓ läuft auf
Webserver PRD-APP-PORTAL-01
    ↓ nutzt
Datenbank PRD-DB-PORTAL-01
    ↓ nutzt
Storage PRD-STO-01

Weitere Beziehungen:

Beispiel: VPN-Service

VPN-Service
    ↓ nutzt
VPN-Gateway
    ↓ nutzt
Firewall
    ↓ nutzt
Internetanbindung

Zusätzliche Abhängigkeiten:

Wenn MFA ausfällt, kann der VPN-Service betroffen sein, obwohl das VPN-Gateway technisch läuft.

Beispiel: Druckservice

Druckservice
    ↓ nutzt
Druckserver
    ↓ verwaltet
Netzwerkdrucker
    ↓ nutzt
Netzwerksegment

Weitere Abhängigkeiten:

Ein Druckproblem kann also viele Ursachen haben.

Ohne Beziehungen wird oft nur der Drucker selbst betrachtet.

Beispiel: Schnittstelle zwischen Anwendungen

Anwendung A
    ↓ sendet Daten an
API-Gateway
    ↓ leitet weiter an
Anwendung B
    ↓ schreibt in
Datenbank B

Zusätzliche Abhängigkeiten:

Eine kleine Änderung am API-Token kann den gesamten Datenaustausch stoppen.

Beziehungen und Incident Management

Bei Incidents helfen Beziehungen, die Auswirkung zu verstehen.

Beispiele:

Beispiel:

Mehrere Anwendungen melden Fehler.

CI-Beziehungen zeigen, dass alle denselben Datenbankcluster nutzen.

Die Diagnose wird schneller eingegrenzt.

Beziehungen und Problem Management

Problem Management nutzt CI-Beziehungen, um Muster zu erkennen.

Beispiele:

Ohne Beziehungen bleiben solche Muster oft unsichtbar.

Beziehungen und Change Enablement

Bei Changes sind Beziehungen besonders wichtig.

Zu prüfen ist:

Ein Change an einem kleinen CI kann große Auswirkungen haben, wenn viele Services davon abhängen.

Beispiel: Change-Auswirkung durch Beziehung

Change

Ein Zertifikat soll erneuert werden.

Ohne Beziehung

Es wird nur der Webserver betrachtet.

Mit Beziehung

Es wird sichtbar:

Dadurch wird der Change besser geplant.

Beziehungen und Release Management

Release Management benötigt Beziehungen, um zu verstehen:

Ein Release kann fehlschlagen, wenn eine abhängige Komponente vergessen wird.

Beziehungen und Information Security Management

Sicherheitsarbeit benötigt CI-Beziehungen.

Beispiele:

Ohne Beziehungen ist Sicherheitsbewertung unvollständig.

Beziehungen und Notfallplanung

Für Notfallplanung sind Abhängigkeiten entscheidend.

Zu klären ist:

Ein Wiederanlaufplan ohne Abhängigkeiten ist häufig unvollständig.

Tiefe der Beziehungspflege

Nicht jede Beziehung muss bis ins kleinste Detail gepflegt werden.

Zu klären ist:

Zu wenig Beziehungspflege macht die CMDB nutzlos.

Zu viel Detailtiefe macht sie schwer wartbar.

Beispiel für sinnvolle Detailtiefe

Für einen geschäftskritischen Service sinnvoll:

Für einen einfachen Testservice kann weniger Detail genügen.

Die Pflege muss zum Risiko passen.

Horizontale und vertikale Beziehungen

Vertikale Beziehungen

zeigen den Aufbau eines Service von oben nach unten.

Beispiel:

Service
    ↓
Anwendung
    ↓
Server
    ↓
Plattform
    ↓
Storage

Horizontale Beziehungen

zeigen Verbindungen zwischen gleichartigen oder verbundenen Komponenten.

Beispiel:

Anwendung A  ↔  API  ↔  Anwendung B

Beide Beziehungstypen sind wichtig.

Vertikale Beziehungen helfen bei Auswirkungsanalyse.

Horizontale Beziehungen helfen bei Schnittstellen- und Kommunikationsproblemen.

Upstream und Downstream

Bei Schnittstellen wird oft zwischen Upstream und Downstream unterschieden.

Begriff Bedeutung
Upstream vorgelagertes System, von dem Daten oder Dienste kommen
Downstream nachgelagertes System, das Daten oder Dienste erhält

Beispiel:

CRM-System
    ↓ sendet Kundendaten an
ERP-System
    ↓ sendet Rechnungsdaten an
Buchhaltungssystem

Wenn das CRM-System fehlerhafte Daten liefert, können downstream weitere Probleme entstehen.

Single Point of Failure erkennen

CI-Beziehungen können Single Points of Failure sichtbar machen.

Beispiel:

Mehrere Services nutzen denselben Datenbankserver.

Wenn dieser Server ausfällt, sind alle Services betroffen.

Mögliche Maßnahmen:

Beziehungen helfen also nicht nur bei Dokumentation, sondern auch bei Risikobewertung.

Dubletten und Namensprobleme

CI-Beziehungen werden unbrauchbar, wenn CIs mehrfach oder uneinheitlich erfasst sind.

Beispiele:

beschreiben möglicherweise dasselbe System.

Folgen:

Namenskonventionen und Dublettenprüfung sind deshalb wichtig.

Veraltete Beziehungen

Beziehungen können veralten durch:

Veraltete Beziehungen sind riskant.

Beispiel:

Ein Change wird als unkritisch bewertet, weil eine alte Beziehung fehlt.

Nach Umsetzung fällt ein abhängiger Service aus.

Beziehungen durch Changes aktualisieren

Jeder relevante Change sollte prüfen:

Configuration Management darf nicht getrennt von Change Enablement betrachtet werden.

Beziehungen durch Discovery erkennen

Technische Beziehungen können teilweise automatisch erkannt werden.

Beispiele:

Aber:

Discovery erkennt nicht immer fachliche Bedeutung.

Ein Tool kann eine Verbindung sehen.

Es weiß nicht automatisch, ob diese Verbindung geschäftskritisch ist.

Manuell gepflegte Beziehungen

Manuell gepflegt werden oft:

Diese Informationen brauchen Verantwortliche und regelmäßige Prüfung.

Beziehungen visualisieren

CI-Beziehungen können als Diagramm, Tabelle oder Abhängigkeitsansicht dargestellt werden.

Mögliche Formen:

Wichtig ist, dass die Darstellung für den Zweck geeignet ist.

Ein Management-Review benötigt andere Details als eine technische Fehleranalyse.

Service Map

Eine Service Map zeigt die wichtigsten Bestandteile eines Services.

Beispiel:

Service: Mitarbeiterportal

Benutzer
    ↓
DNS
    ↓
Load Balancer
    ↓
Webserver
    ↓
Anwendung
    ↓
Datenbank
    ↓
Storage

Zusätzlich:
Identity Provider, Zertifikat, Monitoring, Backup, Supportgruppe

Eine Service Map muss nicht jedes Detail enthalten.

Sie soll die wichtigsten Abhängigkeiten verständlich machen.

Tabellarische Beziehungspflege

Eine einfache Tabelle kann für kleinere Umgebungen ausreichend sein.

Service CI Beziehung Abhängig von Owner
Mitarbeiterportal Portal-App läuft auf PRD-APP-PORTAL-01 App-Team
Mitarbeiterportal Portal-App nutzt PRD-DB-PORTAL-01 DB-Team
Mitarbeiterportal Portal-App nutzt Identity Provider IAM-Team
Mitarbeiterportal Webservice nutzt TLS-Zertifikat Plattform-Team

Wichtig ist, dass die Tabelle gepflegt und genutzt wird.

CI-Beziehungen in Tickets nutzen

Tickets sollten relevante CIs enthalten.

Das hilft bei:

Beispiel:

Ein Incident wird nicht nur als „Anwendung gestört“ erfasst.

Er wird mit Service, Anwendungsversion, Datenbank und betroffener Schnittstelle verknüpft.

Dadurch können spätere Muster erkannt werden.

CI-Beziehungen in Changes nutzen

Ein Change Request sollte betroffene CIs enthalten.

Beispiele:

Zusätzlich sollten abhängige Services geprüft werden.

Ein Change an einer zentralen Komponente muss anders bewertet werden als ein Change an einem isolierten Testsystem.

CI-Beziehungen in Problems nutzen

Ein Problem Record sollte relevante CIs und Beziehungen enthalten.

Beispiel:

Mehrere Incidents betreffen verschiedene Anwendungen.

Problem Management erkennt:

Die CI-Beziehung hilft, eine gemeinsame Ursache zu finden.

Praxisbeispiel: Datenbank als gemeinsame Abhängigkeit

Situation

Drei Anwendungen melden Performance-Probleme.

Einzelbetrachtung

Jedes Team sucht zunächst in seiner Anwendung.

CI-Beziehungen zeigen

Nutzen

Die Analyse wird schneller auf die gemeinsame Abhängigkeit gelenkt.

Praxisbeispiel: Zertifikat als CI

Situation

Anmeldung am Service schlägt fehl.

CI-Beziehungen zeigen

Verbesserung

Zertifikate werden künftig als eigene CIs mit Ablaufdatum, Owner und Monitoringbeziehung gepflegt.

Praxisbeispiel: Standort-Firewall

Situation

Ein Standort meldet Zugriffsstörungen.

CI-Beziehungen zeigen

Nutzen

Die Fehlersuche wird auf Standortnetz, Firewall und VPN eingegrenzt.

Praxisbeispiel: Veraltete Beziehung

Situation

Eine alte Datenbank wird abgeschaltet.

Problem

In der CMDB ist nicht dokumentiert, dass ein Reporting-Service noch darauf zugreift.

Folge

Nach Abschaltung fällt das Reporting aus.

Lerneffekt

Vor Außerbetriebnahme müssen Abhängigkeiten geprüft und alte Beziehungen bereinigt werden.

Typische Fehler

Fehler 1

Nur technische Geräte werden als CIs betrachtet.

Fehler 2

Services selbst werden nicht als CIs erfasst.

Fehler 3

Beziehungen zwischen CIs fehlen.

Fehler 4

Beziehungen werden einmal erstellt und danach nicht gepflegt.

Fehler 5

Zu viele unwichtige Details werden gepflegt, aber wichtige Abhängigkeiten fehlen.

Fehler 6

CIs haben keinen Owner.

Fehler 7

CI-Namen sind uneinheitlich oder doppelt.

Fehler 8

Discovery-Daten werden ohne fachliche Prüfung übernommen.

Fehler 9

Changes aktualisieren CI-Beziehungen nicht.

Fehler 10

Tickets werden nicht mit betroffenen CIs verknüpft.

Fehler 11

Kritikalität wird ohne Servicebezug bewertet.

Fehler 12

Schnittstellen, Zertifikate und Cloud-Ressourcen werden vergessen.

Checkliste: Ist ein Objekt ein sinnvolles CI?

Checkliste CI-Attribute

Checkliste CI-Beziehungen

Checkliste Beziehungspflege nach Changes

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten praktisch mit vielen Configuration Items.

Beispiele:

Wichtig ist nicht nur, diese Komponenten technisch zu kennen.

Wichtig ist auch zu verstehen:

Gute CI-Beziehungen machen technische Arbeit schneller, sicherer und nachvollziehbarer.

Zusammenfassung

wichtige Services identifizieren
↓
relevante Configuration Items bestimmen
↓
sinnvolle Attribute erfassen
↓
Owner und Kritikalität festlegen
↓
Beziehungen zwischen CIs dokumentieren
↓
Serviceabhängigkeiten sichtbar machen
↓
CIs in Incidents, Problems und Changes nutzen
↓
Beziehungen nach Changes aktualisieren
↓
Datenqualität regelmäßig prüfen

Merksätze

Ein CI ist nur dann wertvoll, wenn es für den Servicebetrieb relevant ist.

Beziehungen zeigen, welche Auswirkungen ein Ausfall oder Change haben kann.

Eine CI-Liste ohne Beziehungen ist nur begrenzt hilfreich.

Technisch kleine Komponenten können geschäftlich sehr wichtig sein.

Discovery erkennt Technik, aber nicht automatisch fachliche Bedeutung.

CI-Beziehungen müssen nach Changes gepflegt werden.

Gute Configuration-Daten verbessern Incident, Problem, Change und Security Management.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

6. Service Configuration Management

6.3 Configuration Management Database

Kurz erklärt

Eine Configuration Management Database (CMDB) ist ein Datenbestand oder Werkzeug, in dem Configuration Items und ihre Beziehungen verwaltet werden.

Sie hilft dabei, Services, Systeme, Komponenten, Versionen, Verantwortlichkeiten und Abhängigkeiten nachvollziehbar zu dokumentieren.

Der Wert einer CMDB entsteht nicht durch möglichst viele Einträge, sondern durch aktuelle, verlässliche und nutzbare Informationen für Incident, Problem, Change, Release und Security Management.

Warum eine CMDB wichtig ist

IT-Services bestehen aus vielen abhängigen Bestandteilen.

Ohne zentrale oder verlässliche Configuration-Daten entstehen typische Probleme:

Eine CMDB soll diese Informationen strukturiert nutzbar machen.

Was eine CMDB leisten soll

Eine CMDB soll helfen zu beantworten:

Damit unterstützt die CMDB nicht nur Dokumentation, sondern tägliche Betriebsentscheidungen.

CMDB ist kein Selbstzweck

Eine CMDB ist nur sinnvoll, wenn sie genutzt wird.

Ungeeignet:

Wir erfassen alles, weil eine CMDB vollständig sein muss.

Besser:

Wir erfassen die Informationen, die für Servicebetrieb, Support, Changes, Risiken und Entscheidungen wirklich benötigt werden.

Eine zu große, ungepflegte CMDB wird schnell unübersichtlich und unzuverlässig.

Eine kleine, gut gepflegte CMDB kann deutlich nützlicher sein.

CMDB und Configuration Management System

Eine CMDB ist ein Datenbestand für Configuration Items und Beziehungen.

Ein Configuration Management System (CMS) kann breiter sein.

Ein CMS kann mehrere Quellen verbinden, zum Beispiel:

Die CMDB kann also Teil eines größeren Configuration Management Systems sein.

CMDB und Inventarliste unterscheiden

Inventarliste CMDB
zeigt häufig nur vorhandene Geräte oder Assets zeigt Configuration Items und Servicebeziehungen
Fokus auf Bestand Fokus auf Betrieb, Abhängigkeiten und Wirkung
Beispiel: Server existiert Beispiel: Server betreibt Service X und nutzt Datenbank Y
wichtig für Übersicht wichtig für Incident, Problem, Change und Risiko
oft objektbezogen service- und beziehungsbezogen

Eine Inventarliste beantwortet:

Was haben wir?

Eine CMDB beantwortet zusätzlich:

Wofür wird es genutzt und wovon hängt es ab?

Typische Inhalte einer CMDB

Eine CMDB kann enthalten:

Nicht jede CMDB benötigt alle Felder.

Die Felder müssen zum Zweck und Pflegeaufwand passen.

Beispiel für einen CMDB-Eintrag

Feld Beispiel
CI-Name PRD-APP-PORTAL-01
CI-Typ Server
Status aktiv
Umgebung Produktion
Service Mitarbeiterportal
Owner Plattform-Team
Supportgruppe Application Support
Version Linux Server Version X
Standort Rechenzentrum Berlin
Kritikalität hoch
Lieferant interner Betrieb
Dokumentation Betriebsrunbook Mitarbeiterportal
Beziehungen läuft Portal-App, nutzt Datenbank PRD-DB-PORTAL-01
letzte Prüfung 02.08.2026

Dieses Beispiel ist bewusst einfach gehalten.

Die tatsächlichen Felder hängen von Organisation und Werkzeug ab.

Wichtige CI-Typen in einer CMDB

Mögliche CI-Typen:

Wichtig ist eine klare interne Definition.

Wenn Teams CI-Typen unterschiedlich verwenden, werden Auswertungen ungenau.

Service als zentrales Element

Eine CMDB sollte nicht nur technische Komponenten sammeln.

Wichtig ist die Verbindung zum Service.

Beispiel:

Mitarbeiterportal
    ↓ nutzt
Portal-Anwendung
    ↓ läuft auf
PRD-APP-PORTAL-01
    ↓ nutzt
PRD-DB-PORTAL-01
    ↓ nutzt
PRD-STO-01

Zusätzlich:

Erst diese Serviceperspektive macht die CMDB im Betrieb wertvoll.

Beziehungen in der CMDB

Beziehungen sind einer der wichtigsten Bestandteile einer CMDB.

Typische Beziehungen:

Ohne Beziehungen ist eine CMDB oft nur eine Inventarliste.

Beispiel: Beziehungskette

Benutzer
    ↓
Mitarbeiterportal
    ↓
Webserver
    ↓
Anwendung
    ↓
Datenbank
    ↓
Storage

Weitere Abhängigkeiten:

Wenn eine Komponente ausfällt, hilft die CMDB zu erkennen, welche Services betroffen sein können.

CMDB und Incident Management

Bei Incidents hilft eine CMDB durch:

Beispiel:

Ein Benutzer meldet, dass das Mitarbeiterportal nicht erreichbar ist.

Die CMDB zeigt:

Dadurch kann die Diagnose gezielter beginnen.

CMDB und Problem Management

Problem Management nutzt CMDB-Daten, um gemeinsame Ursachen zu erkennen.

Beispiele:

Ohne CMDB-Beziehungen werden solche Muster oft erst spät sichtbar.

CMDB und Change Enablement

Change Enablement benötigt CMDB-Daten für die Auswirkungsbewertung.

Zu prüfen ist:

Ein Change ohne CMDB-Prüfung kann unerwartete Auswirkungen verursachen.

CMDB und Release Management

Release und Deployment benötigen verlässliche Informationen über:

Nach einem Release müssen CMDB-Daten aktualisiert werden.

Sonst zeigt die CMDB einen veralteten Zustand.

CMDB und Information Security Management

Eine CMDB unterstützt Sicherheitsarbeit durch Informationen über:

Beispiel:

Eine Sicherheitslücke betrifft eine bestimmte Softwareversion.

Mit CMDB-Daten kann schneller erkannt werden, welche Systeme und Services betroffen sind.

CMDB und Service Level Management

Service Level Management kann CMDB-Daten nutzen, um zu verstehen:

Ein Service Level ist schwer zu steuern, wenn die technischen Abhängigkeiten unbekannt sind.

CMDB-Datenquellen

Mögliche Datenquellen für eine CMDB:

Keine einzelne Datenquelle ist automatisch vollständig.

Die CMDB muss aus passenden Quellen aufgebaut und geprüft werden.

Automatische Discovery

Discovery kann technische Informationen automatisch erfassen.

Beispiele:

Discovery ist hilfreich für Aktualität.

Aber Discovery erkennt nicht immer:

Manuelle Pflege

Manuelle Pflege bleibt wichtig für Informationen wie:

Diese Informationen benötigen Verantwortliche.

Ohne klare Pflegeverantwortung veralten sie schnell.

Datenqualität in der CMDB

Eine CMDB ist nur so gut wie ihre Datenqualität.

Wichtige Qualitätskriterien:

Schlechte Daten können gefährlich sein.

Sie führen zu falschen Entscheidungen, weil Teams der CMDB vertrauen, obwohl sie veraltet ist.

Typische Datenqualitätsprobleme

Problem Folge
doppelte CIs Incidents und Changes werden falsch verknüpft
veraltete Owner Eskalation dauert länger
fehlende Beziehungen Auswirkung wird unterschätzt
falscher Status außer Betrieb genommene Systeme erscheinen aktiv
fehlende Versionen Sicherheitsbewertung wird ungenau
fehlende Servicezuordnung Priorisierung wird schwieriger
falsche Umgebung Test und Produktion werden verwechselt
fehlende Dokumentationslinks Betrieb dauert länger

Dubletten vermeiden

Dubletten entstehen, wenn dasselbe CI mehrfach erfasst wird.

Beispiele:

Folgen:

Gegenmaßnahmen:

Namenskonventionen

Eine gute Namenskonvention unterstützt Eindeutigkeit.

Mögliche Bestandteile:

Beispiele:

Die Namenskonvention sollte einfach genug sein, damit sie konsequent genutzt wird.

Pflichtfelder und optionale Felder

Nicht jedes Feld sollte verpflichtend sein.

Zu viele Pflichtfelder führen dazu, dass Benutzer falsche Werte eintragen, nur um den Datensatz speichern zu können.

Sinnvolle Pflichtfelder können sein:

Optionale Felder können abhängig vom CI-Typ sein.

Beispiel:

Ein Zertifikat benötigt Ablaufdatum.

Ein Drucker benötigt Standort.

Eine Anwendung benötigt Version und Service Owner.

CMDB-Modell

Das CMDB-Modell beschreibt, welche CI-Typen, Attribute und Beziehungen verwendet werden.

Zu klären ist:

Ein einfaches, verstandenes Modell ist besser als ein komplexes Modell, das niemand pflegt.

Granularität

Granularität beschreibt, wie detailliert CIs erfasst werden.

Beispiel:

Sehr grob:

Mittel:

Sehr fein:

Die richtige Granularität hängt vom Nutzen ab.

Zu grob hilft bei technischer Analyse wenig.

Zu fein ist schwer pflegbar.

Beispiel für passende Granularität

Für einen kritischen Webservice sinnvoll:

Nicht immer sinnvoll:

Die CMDB soll Entscheidungen unterstützen, nicht jede technische Kleinigkeit abbilden.

CMDB-Lebenszyklus

Ein CI durchläuft einen Lebenszyklus.

geplant
    ↓
erstellt oder beschafft
    ↓
in Betrieb genommen
    ↓
geändert
    ↓
regelmäßig geprüft
    ↓
außer Betrieb genommen
    ↓
archiviert oder gelöscht

Die CMDB sollte diesen Lebenszyklus abbilden.

Besonders wichtig ist die saubere Außerbetriebnahme.

Außerbetriebnahme von CIs

Vor dem Entfernen eines CIs sollte geprüft werden:

Ein CI einfach zu löschen kann spätere Nachvollziehbarkeit zerstören.

Oft ist Archivierung sinnvoller.

CMDB und Change-Prozess

Changes sollten CMDB-Daten aktualisieren.

Beispiele:

Wenn Changes die CMDB nicht aktualisieren, veraltet sie automatisch.

CMDB und Dokumentation

Die CMDB ersetzt nicht jede Dokumentation.

Sie kann aber auf Dokumentation verweisen.

Beispiele:

Die CMDB zeigt, welche Dokumentation zu welchem CI oder Service gehört.

CMDB und Monitoring

Monitoring und CMDB sollten sich ergänzen.

Monitoring zeigt:

CMDB zeigt:

Beispiel:

Monitoring meldet Ausfall eines Servers.

Die CMDB zeigt, welche Services davon abhängen und wer informiert werden muss.

CMDB und Cloud

Cloud-Umgebungen verändern sich oft schnell.

Herausforderungen:

Für Cloud-Ressourcen sind klare Tags, automatisierte Erkennung und regelmäßige Prüfung besonders wichtig.

CMDB und Tags

Tags oder Labels können helfen, Cloud- und Plattformressourcen zuzuordnen.

Mögliche Tags:

Beispiel:

Tag Wert
Service Mitarbeiterportal
Umgebung Produktion
Owner Plattform-Team
Kritikalität hoch
Datenklasse intern

Tags ersetzen keine vollständige CMDB, können aber wichtige Daten liefern.

CMDB und Container

Auch Container-Umgebungen können CMDB-relevant sein.

Mögliche CIs:

Wichtig ist, nicht jeden kurzlebigen Container einzeln dauerhaft zu pflegen.

Oft sind Service, Anwendung, Plattform, Version und Abhängigkeiten wichtiger als einzelne temporäre Instanzen.

CMDB und Schnittstellen

Schnittstellen werden oft vergessen.

Dabei sind sie für Services kritisch.

Zu erfassen sind:

Ein Schnittstellenfehler kann mehrere Services gleichzeitig betreffen.

CMDB und Zertifikate

Zertifikate sollten bei wichtigen Services als relevante CIs betrachtet werden.

Sinnvolle Informationen:

Viele vermeidbare Incidents entstehen durch abgelaufene oder falsch erneuerte Zertifikate.

Berechtigungen und Gruppen als CIs

Auch Benutzergruppen oder Berechtigungskonzepte können CI-relevant sein.

Beispiele:

Solche CIs sind besonders wichtig für:

CMDB-Reports

Nützliche Reports können sein:

Reports sollen nicht nur Zahlen liefern.

Sie sollen konkrete Verbesserungen ermöglichen.

CMDB-Einführung schrittweise beginnen

Eine CMDB sollte nicht zwingend sofort alles abbilden.

Sinnvoller Start:

  1. kritische Services auswählen
  2. wichtigste CIs erfassen
  3. zentrale Beziehungen dokumentieren
  4. Owner festlegen
  5. Change-Prozess anbinden
  6. Datenqualität prüfen
  7. Nutzung in Incident und Change etablieren
  8. schrittweise erweitern

Eine CMDB scheitert häufig, wenn zu Beginn zu viel auf einmal erfasst werden soll.

Minimal sinnvolle CMDB für kleine Umgebungen

Für kleine Umgebungen kann auch eine einfache Struktur ausreichen.

Mögliche Mindestinformationen:

Das kann auch in einem einfachen ITSM-Tool, Wiki oder einer strukturierten Tabelle beginnen.

Wichtig ist Pflege und Nutzung.

Governance der CMDB

CMDB-Governance legt Regeln fest.

Zu klären ist:

Ohne Governance wird eine CMDB schnell unzuverlässig.

Rollen im CMDB-Betrieb

Mögliche Rollen:

Rolle Aufgabe
Configuration Manager steuert Modell, Qualität und Regeln
Service Owner verantwortet Serviceinformationen
CI Owner verantwortet einzelne CIs
Supportgruppe nutzt und ergänzt Betriebsinformationen
Change Manager sorgt für Aktualisierung nach Changes
Security Team nutzt Daten für Sicherheitsbewertung
Asset Manager liefert Asset- und Vertragsdaten

Die Rollen müssen nicht überall als eigene Stellen existieren.

Die Verantwortlichkeiten müssen aber klar sein.

Praxisbeispiel: Incident mit CMDB-Nutzen

Situation

Mehrere Benutzer melden, dass das Mitarbeiterportal nicht erreichbar ist.

CMDB hilft durch:

Ergebnis

Die Analyse konzentriert sich schneller auf Datenbank, Zertifikat und letzten Change.

Praxisbeispiel: Change mit CMDB-Nutzen

Situation

Ein Datenbankserver soll aktualisiert werden.

CMDB zeigt:

Ergebnis

Der Change wird nicht als isoliertes Serverupdate behandelt, sondern als Serviceänderung mit Abhängigkeiten.

Praxisbeispiel: Sicherheitslücke

Situation

Eine kritische Schwachstelle betrifft eine bestimmte Softwareversion.

CMDB hilft durch:

Ergebnis

Patchpriorisierung wird schneller und nachvollziehbarer.

Praxisbeispiel: Abgelaufenes Zertifikat verhindern

Situation

Mehrere Zertifikate wurden bisher nur in einzelnen Runbooks erwähnt.

Problem

Ablaufdaten wurden nicht zentral überwacht.

Verbesserung

Zertifikate werden als CIs erfasst mit:

Nutzen

Ausfälle durch abgelaufene Zertifikate werden besser vermeidbar.

Typische Fehler

Fehler 1

CMDB wird als reine Inventarliste aufgebaut.

Fehler 2

Zu viele CIs werden erfasst, aber nicht gepflegt.

Fehler 3

Services und Beziehungen fehlen.

Fehler 4

Owner sind nicht definiert.

Fehler 5

Daten werden nicht durch Changes aktualisiert.

Fehler 6

Discovery-Daten werden ungeprüft übernommen.

Fehler 7

Dubletten und uneinheitliche Namen werden nicht bereinigt.

Fehler 8

CMDB wird im Incident- und Change-Prozess nicht genutzt.

Fehler 9

Kritikalität wird technisch statt servicebezogen bewertet.

Fehler 10

Cloud-Ressourcen, Zertifikate und Schnittstellen fehlen.

Fehler 11

Reports zeigen Probleme, aber niemand verfolgt Verbesserungen.

Fehler 12

CMDB-Ziel und Pflegeaufwand passen nicht zusammen.

Checkliste CMDB-Modell

Checkliste CMDB-Eintrag

Checkliste Datenqualität

Checkliste CMDB im Change nutzen

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker nutzen und pflegen CMDB-Daten im praktischen Betrieb.

Wichtig ist:

Eine gute CMDB macht technische Arbeit nicht bürokratischer.

Sie macht sie nachvollziehbarer, sicherer und schneller.

Zusammenfassung

Ziel der CMDB festlegen
↓
relevante Services und CI-Typen bestimmen
↓
Attribute und Beziehungen definieren
↓
Datenquellen anbinden
↓
Owner und Pflegeverantwortung klären
↓
CIs und Beziehungen erfassen
↓
CMDB in Incident, Problem und Change nutzen
↓
Datenqualität regelmäßig prüfen
↓
CMDB schrittweise verbessern

Merksätze

Eine CMDB ist nur wertvoll, wenn ihre Daten genutzt und gepflegt werden.

Beziehungen sind wichtiger als eine lange Liste einzelner Systeme.

Eine CMDB ersetzt keine Betriebsdokumentation, sie verknüpft relevante Informationen.

Discovery hilft bei Technik, ersetzt aber keine fachliche Verantwortung.

Jede relevante Änderung sollte auch die CMDB aktualisieren.

Schlechte CMDB-Daten können zu falschen Entscheidungen führen.

Klein anfangen und konsequent pflegen ist besser als groß planen und nicht aktuell halten.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

6. Service Configuration Management

6.4 Discovery, Pflege und Datenqualität

Kurz erklärt

Discovery, Pflege und Datenqualität sorgen dafür, dass Configuration-Daten nicht nur einmal erfasst, sondern dauerhaft aktuell, korrekt und nutzbar bleiben.

Discovery hilft, technische Informationen automatisch zu erkennen.

Pflege sorgt dafür, dass fachliche, organisatorische und servicebezogene Informationen ergänzt und aktuell gehalten werden.

Datenqualität entscheidet, ob Configuration-Daten im Betrieb wirklich verlässlich sind.

Warum dieses Thema wichtig ist

Eine CMDB oder ein Configuration Management System ist nur dann hilfreich, wenn die Daten stimmen.

Veraltete oder falsche Configuration-Daten führen zu Problemen:

Datenqualität ist deshalb kein Nebenthema.

Sie ist die Grundlage dafür, dass Service Configuration Management im Alltag funktioniert.

Discovery

Discovery bedeutet, technische Informationen automatisch oder halbautomatisch zu erkennen.

Mögliche Discovery-Ergebnisse:

Discovery kann Daten schneller und regelmäßiger erfassen als rein manuelle Pflege.

Was Discovery leisten kann

Discovery kann helfen bei:

Beispiel:

Ein Discovery-Werkzeug erkennt, dass ein Server noch eine alte Softwareversion verwendet.

Diese Information kann für Security, Change Enablement und Problem Management wichtig sein.

Was Discovery nicht automatisch leisten kann

Discovery erkennt Technik.

Discovery versteht aber nicht automatisch den fachlichen Zusammenhang.

Ein Discovery-Werkzeug erkennt vielleicht:

Es weiß aber nicht automatisch:

Deshalb muss Discovery durch fachliche Pflege ergänzt werden.

Discovery und manuelle Pflege ergänzen sich

Discovery Manuelle oder organisatorische Pflege
erkennt technische Objekte ergänzt fachliche Bedeutung
erkennt Versionen und Eigenschaften ergänzt Owner und Verantwortlichkeiten
erkennt Verbindungen bewertet Serviceabhängigkeiten
erkennt neue Ressourcen prüft, ob sie relevant sind
erkennt Abweichungen klärt, ob sie erlaubt sind
liefert Ist-Daten ergänzt Soll-Zustand und Kontext

Gute Configuration-Daten entstehen durch Kombination aus Automatisierung, Prozessen und Verantwortung.

Typische Discovery-Quellen

Mögliche Quellen für technische Erkennung:

Keine Quelle ist vollständig.

Mehrere Quellen müssen oft abgeglichen werden.

Discovery in Cloud-Umgebungen

Cloud-Umgebungen verändern sich häufig schneller als klassische Rechenzentrumsumgebungen.

Typische Herausforderungen:

Wichtige Maßnahmen:

Discovery in Container-Umgebungen

In Container-Umgebungen entstehen und verschwinden technische Instanzen oft sehr schnell.

Nicht jeder kurzlebige Container sollte dauerhaft als einzelnes CI gepflegt werden.

Sinnvoller können sein:

Wichtig ist, servicebezogene Informationen zu erfassen, nicht jede temporäre Laufzeitinstanz dauerhaft zu dokumentieren.

Discovery und Sicherheitsbewertung

Discovery ist für Sicherheit besonders wichtig.

Beispiele:

Aber auch hier gilt:

Discovery zeigt technische Tatsachen.

Die Risikobewertung benötigt zusätzlich Kritikalität, Datenklasse, Servicebezug und Owner.

Discovery-Ergebnisse prüfen

Discovery-Daten sollten nicht ungeprüft übernommen werden.

Zu prüfen ist:

Automatisierung ohne Prüfung kann die CMDB mit unbrauchbaren Daten füllen.

Datenpflege

Datenpflege bedeutet, Configuration-Daten aktuell und nutzbar zu halten.

Dazu gehören:

Pflege ist keine einmalige Projektarbeit.

Sie ist eine laufende Betriebsaufgabe.

Pflege durch Change Enablement

Changes sind eine der wichtigsten Quellen für CMDB-Aktualisierungen.

Nach einem Change kann sich ändern:

Deshalb sollte jeder relevante Change prüfen:

Müssen Configuration-Daten aktualisiert werden?

Wenn Changes die CMDB nicht pflegen, veraltet sie automatisch.

Pflege durch Release und Deployment

Nach Releases und Deployments ändern sich häufig:

Release- und Deployment-Prozesse sollten deshalb CMDB-Aktualisierung als Abschlussaufgabe enthalten.

Pflege durch Incident und Problem Management

Incident und Problem Management können Datenfehler sichtbar machen.

Beispiele:

Solche Erkenntnisse sollten nicht im Ticket verschwinden.

Sie sollten zur Verbesserung der Configuration-Daten genutzt werden.

Pflege durch Service Owner

Service Owner sind wichtig für fachliche Informationen.

Sie können prüfen:

Technische Teams kennen oft die Komponenten.

Service Owner kennen den fachlichen Wert und die Auswirkung.

Pflege durch technische Teams

Technische Teams pflegen vor allem technische Informationen.

Beispiele:

Wichtig ist, dass technische Änderungen nicht nur umgesetzt, sondern auch nachvollziehbar dokumentiert werden.

Pflegeintervalle

Nicht alle Configuration-Daten müssen gleich häufig geprüft werden.

Mögliche Prüfintervalle:

CI oder Information mögliches Prüfintervall
geschäftskritischer Service regelmäßig und nach jedem relevanten Change
Zertifikate automatisch überwachen und regelmäßig prüfen
produktive Server nach Changes und in festen Reviews
Cloud-Ressourcen häufig oder automatisiert
Dokumentationslinks regelmäßig oder nach Releases
Testsysteme nach Bedarf
archivierte CIs selten, aber nachvollziehbar

Die Häufigkeit sollte sich nach Risiko, Kritikalität und Änderungsdynamik richten.

Datenqualität

Datenqualität beschreibt, ob Configuration-Daten für den vorgesehenen Zweck geeignet sind.

Wichtige Qualitätsmerkmale:

Perfekte Vollständigkeit ist selten realistisch.

Entscheidend ist, dass die Daten für Incident, Problem, Change, Release und Security Management ausreichend zuverlässig sind.

Korrektheit

Korrektheit bedeutet:

Die Information stimmt mit der Realität überein.

Beispiele:

Falsche Daten sind gefährlich.

Beispiel:

Die CMDB zeigt einen Server als Testsystem, obwohl er produktiv genutzt wird.

Ein Change wird dadurch zu niedrig bewertet.

Aktualität

Aktualität bedeutet:

Die Information ist nicht veraltet.

Beispiele für veraltete Daten:

Aktualität entsteht durch Anbindung an Changes, Releases, Reviews und Discovery.

Vollständigkeit

Vollständigkeit bedeutet nicht, jedes Detail zu erfassen.

Sie bedeutet:

Die für den Zweck notwendigen Informationen sind vorhanden.

Beispiel:

Für einen kritischen Service sollten mindestens vorhanden sein:

Ein unwichtiger Testdienst benötigt weniger Detailtiefe.

Eindeutigkeit

Eindeutigkeit bedeutet:

Jedes CI ist klar identifizierbar.

Probleme entstehen durch:

Beispiel:

könnten dasselbe CI beschreiben.

Solche Dubletten erschweren Reports, Changes und Incidents.

Konsistenz

Konsistenz bedeutet:

Daten folgen einheitlichen Regeln.

Beispiele:

Ungeeignet:

werden ohne Regel gemischt.

Besser:

Eine definierte Schreibweise wird verbindlich genutzt.

Nachvollziehbarkeit

Nachvollziehbarkeit bedeutet:

Es ist erkennbar, woher eine Information kommt und warum sie geändert wurde.

Hilfreich sind:

Nachvollziehbarkeit ist besonders wichtig bei Sicherheitsfragen, Audits und Major Incidents.

Nutzbarkeit

Daten sind nur wertvoll, wenn sie genutzt werden können.

Nutzbarkeit bedeutet:

Eine CMDB mit vielen Feldern, die niemand versteht oder nutzt, erzeugt keinen Mehrwert.

Datenqualitätsregeln

Eine Organisation sollte Datenqualitätsregeln definieren.

Beispiele:

Solche Regeln müssen kontrollierbar sein.

Datenqualitätskennzahlen

Mögliche Kennzahlen:

Kennzahl Aussage
CIs ohne Owner Verantwortlichkeit fehlt
CIs ohne Servicezuordnung Servicebezug unklar
kritische Services ohne Abhängigkeiten Auswirkungsanalyse unvollständig
CIs ohne letzte Prüfung Aktualität unsicher
ablaufende Zertifikate ohne Owner hohes Betriebsrisiko
Dublettenquote Eindeutigkeit schlecht
Changes ohne CI-Verknüpfung CMDB wird im Change-Prozess nicht genutzt
Incidents ohne CI-Verknüpfung Trendanalyse erschwert

Kennzahlen sollten nicht nur gemessen werden.

Sie müssen zu Verbesserungen führen.

Datenqualitätsberichte

Datenqualitätsberichte können regelmäßig zeigen:

Solche Berichte sollten Verantwortliche und nächste Schritte enthalten.

Nur eine Fehlerliste reicht nicht aus.

Dubletten bereinigen

Dubletten entstehen leicht durch manuelle Pflege, Discovery oder unterschiedliche Datenquellen.

Vorgehen:

  1. mögliche Dubletten erkennen
  2. prüfen, ob es wirklich dasselbe CI ist
  3. führenden Datensatz festlegen
  4. Beziehungen zusammenführen
  5. verknüpfte Incidents, Problems und Changes prüfen
  6. Dublette archivieren oder löschen
  7. Ursache der Dublette beheben

Wichtig ist, nicht versehentlich unterschiedliche CIs zusammenzuführen.

Veraltete CIs archivieren

Nicht mehr aktive CIs sollten nicht einfach unkontrolliert gelöscht werden.

Besser ist oft:

So bleibt Nachvollziehbarkeit erhalten.

Das ist besonders wichtig bei Audits, Sicherheitsvorfällen oder späteren Analysen.

Abweichungen erkennen

Abweichungen zwischen CMDB und Realität können entstehen durch:

Abweichungen sollten nicht nur korrigiert werden.

Es sollte geprüft werden, warum sie entstanden sind.

Soll-Zustand und Ist-Zustand unterscheiden

Zustand Bedeutung
Soll-Zustand freigegebener oder erwarteter Zustand
Ist-Zustand tatsächlich erkannter Zustand
Abweichung Unterschied zwischen Soll und Ist

Beispiel:

Soll-Zustand:

Server nutzt Version 5.9.

Ist-Zustand:

Discovery erkennt Version 5.8.

Mögliche Ursachen:

Configuration Drift

Configuration Drift bedeutet, dass Systeme im Laufe der Zeit vom gewünschten Zustand abweichen.

Ursachen:

Folgen:

Baselines und regelmäßige Prüfungen helfen gegen Configuration Drift.

Baselines nutzen

Eine Configuration Baseline beschreibt einen bekannten, freigegebenen Zustand.

Beispiele:

Baselines helfen bei:

Wenn ein System von der Baseline abweicht, sollte dokumentiert sein, warum.

Pflegeverantwortung

Ohne Verantwortung veraltet Configuration Management.

Zu klären ist:

Verantwortung kann auf mehrere Rollen verteilt sein.

Sie muss aber eindeutig sein.

Rollen bei der Datenpflege

Rolle mögliche Aufgabe
Configuration Manager Regeln, Modell und Datenqualität steuern
Service Owner Servicebezug, Kritikalität und fachliche Daten prüfen
CI Owner einzelne CIs verantworten
Supportgruppe technische Informationen ergänzen
Change Manager CMDB-Aktualisierung nach Changes sicherstellen
Security Team sicherheitsrelevante Daten nutzen und prüfen
Asset Manager Asset-, Vertrags- und Lebenszyklusdaten liefern

Die Rollen müssen nicht immer eigene Stellen sein.

Wichtig sind klare Zuständigkeiten.

Pflege durch Prozesse erzwingen

Datenpflege funktioniert besser, wenn sie in Prozesse eingebaut ist.

Beispiele:

Datenpflege sollte nicht nur auf freiwilliger Erinnerung beruhen.

Pflegeaufwand realistisch halten

Zu viel Detailtiefe führt zu Pflegeproblemen.

Fragen zur Begrenzung:

Daten, die niemand nutzt und niemand pflegt, sollten kritisch hinterfragt werden.

Toolunterstützung

Tools können unterstützen durch:

Ein Tool löst aber kein organisatorisches Problem.

Ohne klare Regeln und Verantwortung wird auch ein gutes Tool schlechte Daten enthalten.

Integration mit ITSM-Prozessen

Configuration-Daten sollten nicht isoliert gepflegt werden.

Sie sollten aktiv genutzt werden in:

Je häufiger die Daten im Alltag genutzt werden, desto eher fallen Fehler auf.

Ungenutzte Daten veralten schneller.

Datenqualität durch Nutzung verbessern

Wenn Service Desk und Fachteams CMDB-Daten aktiv nutzen, werden Fehler sichtbar.

Beispiele:

Wichtig ist, dass solche Fehler einfach gemeldet und korrigiert werden können.

Praxisbeispiel: Discovery findet unbekannten Server

Situation

Discovery erkennt einen Server, der nicht in der CMDB steht.

Prüfung

Ergebnis

Der Server wird entweder als CI aufgenommen oder kontrolliert außer Betrieb genommen.

Praxisbeispiel: Falscher Owner

Situation

Ein Incident betrifft eine Anwendung.

Die CMDB nennt ein Team, das seit Monaten nicht mehr zuständig ist.

Folge

Eskalation verzögert sich.

Verbesserung

Praxisbeispiel: Veraltete Version

Situation

Die CMDB zeigt Version 5.9.

Discovery erkennt Version 5.8.

Mögliche Ursachen

Verbesserung

Abweichung wird geprüft, korrigiert und mit Change Record verknüpft.

Praxisbeispiel: Fehlende Zertifikatsdaten

Situation

Ein produktives Zertifikat läuft ab.

In der CMDB ist kein Ablaufdatum gepflegt.

Folge

Anmeldedienst fällt aus.

Verbesserung

Praxisbeispiel: Cloud-Ressource ohne Tags

Situation

Cloud-Report zeigt mehrere Ressourcen ohne Service-Tag.

Risiko

Verbesserung

Typische Fehler

Fehler 1

Discovery-Daten werden ungeprüft in die CMDB übernommen.

Fehler 2

Manuelle Pflege wird niemandem eindeutig zugeordnet.

Fehler 3

CMDB wird einmal aufgebaut und danach nicht gepflegt.

Fehler 4

Changes aktualisieren Configuration-Daten nicht.

Fehler 5

Dubletten werden ignoriert.

Fehler 6

Datenqualitätsberichte werden erstellt, aber nicht bearbeitet.

Fehler 7

Zu viele Felder werden gepflegt, obwohl sie niemand nutzt.

Fehler 8

Wichtige Beziehungen fehlen trotz vieler technischer Details.

Fehler 9

Cloud- und Container-Ressourcen werden nicht berücksichtigt.

Fehler 10

Zertifikate, Schnittstellen und Benutzergruppen werden vergessen.

Fehler 11

Owner und Kritikalität werden nicht regelmäßig geprüft.

Fehler 12

Teams vertrauen der CMDB nicht mehr, weil Fehler nicht korrigiert werden.

Checkliste Discovery

Checkliste Datenpflege

Checkliste Datenqualität

Checkliste nach Changes

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker tragen stark zur Datenqualität bei.

Im Alltag bedeutet das:

Eine gute CMDB entsteht nicht allein durch ein Tool.

Sie entsteht durch saubere technische Arbeit, klare Prozesse und konsequente Pflege.

Zusammenfassung

technische Daten durch Discovery erkennen
↓
Ergebnisse prüfen und Dubletten vermeiden
↓
fachliche Informationen ergänzen
↓
Owner, Servicebezug und Kritikalität pflegen
↓
Changes und Releases zur Aktualisierung nutzen
↓
Datenqualität regelmäßig messen
↓
Abweichungen korrigieren
↓
Pflegeaufwand realistisch halten
↓
Configuration-Daten aktiv in ITSM-Prozessen nutzen

Merksätze

Discovery erkennt Technik, aber nicht automatisch fachliche Bedeutung.

Datenpflege ist eine laufende Betriebsaufgabe, kein einmaliges Projekt.

Eine CMDB veraltet automatisch, wenn Changes sie nicht aktualisieren.

Datenqualität ist wichtiger als Datenmenge.

Schlechte Configuration-Daten können zu falschen Entscheidungen führen.

Je häufiger Daten im Alltag genutzt werden, desto schneller fallen Fehler auf.

Gute Datenqualität braucht Toolunterstützung, Prozesse und Verantwortung.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

6. Service Configuration Management

6.5 Service Configuration Management im Zusammenspiel mit Incident-, Problem- und Change-Management

Kurz erklärt

Service Configuration Management liefert wichtige Informationen über Services, Configuration Items, Versionen, Verantwortlichkeiten und Abhängigkeiten.

Diese Informationen werden besonders in Incident Management, Problem Management und Change Enablement benötigt.

Ohne aktuelle Configuration-Daten werden Störungen langsamer analysiert, Ursachen schwerer erkannt und Changes riskanter bewertet.

Warum das Zusammenspiel wichtig ist

Configuration-Daten sind keine reine Dokumentation.

Sie unterstützen tägliche Entscheidungen im IT-Betrieb.

Beispiele:

Service Configuration Management liefert die Informationsbasis.

Incident, Problem und Change Management nutzen diese Informationen für Analyse, Bewertung und Steuerung.

Grundidee des Zusammenspiels

Service Configuration Management
        ↓
liefert Services, CIs, Beziehungen, Owner und Versionen
        ↓
Incident Management nutzt diese Daten für schnelle Diagnose
        ↓
Problem Management nutzt diese Daten für Ursachenanalyse
        ↓
Change Enablement nutzt diese Daten für Auswirkungs- und Risikobewertung
        ↓
Changes, Incidents und Problems liefern neue Erkenntnisse zurück
        ↓
Configuration-Daten werden aktualisiert und verbessert

Der Kreislauf funktioniert nur, wenn Configuration-Daten gepflegt und aktiv genutzt werden.

Zusammenspiel mit Incident Management

Incident Management benötigt Configuration-Daten, um Störungen schneller einzuordnen.

Wichtige Fragen:

Je besser diese Informationen verfügbar sind, desto schneller kann der Incident bearbeitet werden.

Incident Management liefert Informationen zurück

Incidents können zeigen, dass Configuration-Daten falsch oder unvollständig sind.

Beispiele:

Diese Erkenntnisse sollten nicht im Incident verschwinden.

Sie sollten genutzt werden, um die CMDB oder das Configuration Management System zu verbessern.

Beispiel: Incident mit fehlender Beziehung

Situation

Benutzer melden, dass das Mitarbeiterportal nicht erreichbar ist.

Analyse

Der Webserver ist erreichbar.

Die Anwendung kann sich aber nicht mit der Datenbank verbinden.

Problem

In der CMDB war die Datenbankbeziehung nicht gepflegt.

Folge

Die Diagnose dauert länger.

Verbesserung

Die Beziehung zwischen Mitarbeiterportal, Anwendung, Datenbank, Storage und Backup wird nachgetragen.

Zusammenspiel mit Problem Management

Problem Management nutzt Configuration-Daten, um Ursachen und Muster zu erkennen.

Wichtige Fragen:

Configuration-Daten helfen, einzelne Incidents in einen größeren Zusammenhang einzuordnen.

Problem Management liefert Informationen zurück

Problem Management kann Configuration-Daten verbessern.

Beispiele:

Eine Ursachenanalyse sollte deshalb auch prüfen, ob Configuration-Daten angepasst werden müssen.

Beispiel: Problem durch gemeinsame Abhängigkeit

Situation

Drei Anwendungen erzeugen ähnliche Fehlermeldungen.

Einzelbetrachtung

Jedes Team untersucht zunächst seine eigene Anwendung.

Configuration-Daten zeigen

Ergebnis

Problem Management erkennt eine gemeinsame Ursache schneller.

Verbesserung

Die Serviceabhängigkeiten werden in der CMDB klarer gepflegt.

Zusammenspiel mit Change Enablement

Change Enablement benötigt Configuration-Daten für die Auswirkungs- und Risikobewertung.

Wichtige Fragen:

Ohne Configuration-Daten wird ein Change schnell zu niedrig bewertet.

Change Enablement liefert Informationen zurück

Changes verändern Configuration-Daten.

Beispiele:

Nach einem Change muss geprüft werden:

Welche Configuration-Daten müssen aktualisiert werden?

Wenn Changes die CMDB nicht aktualisieren, veraltet sie automatisch.

Beispiel: Change mit unvollständiger Auswirkungsbewertung

Situation

Eine Firewall-Regel wird geändert.

Annahme

Nur eine kleine technische Anpassung.

Tatsächliche Auswirkung

Die Regel betrifft eine Schnittstelle zwischen Warenwirtschaft und Versand.

Nach dem Change können Aufträge nicht mehr übertragen werden.

Ursache

Die Beziehung zwischen Firewall-Regel, Schnittstelle und Geschäftsprozess war nicht dokumentiert.

Verbesserung

Schnittstellen und Firewall-Abhängigkeiten werden als relevante CIs und Beziehungen gepflegt.

Configuration-Daten im Change Request

Ein Change Request sollte relevante Configuration-Daten enthalten.

Dazu gehören:

So wird aus einer technischen Änderung eine bewertbare Serviceänderung.

Zusammenspiel mit Release und Deployment Management

Release und Deployment Management benötigen Configuration-Daten für kontrollierte Bereitstellung.

Wichtige Fragen:

Nach einem Release müssen Versionen, Beziehungen und Dokumentation aktualisiert werden.

Beispiel: Release mit Versionsänderung

Situation

Eine neue Anwendungsversion wird ausgerollt.

Configuration Management muss aktualisieren

Nutzen

Bei späteren Incidents ist sofort sichtbar, welche Version produktiv läuft.

Zusammenspiel mit Knowledge Management

Configuration-Daten und Knowledge Management ergänzen sich.

Die CMDB zeigt:

Knowledge Management liefert:

Beide müssen verknüpft sein.

Eine CMDB ohne Dokumentationslinks ist weniger nützlich.

Eine Knowledge Base ohne Service- und CI-Bezug ist schwerer auffindbar.

Beispiel: Knowledge und CMDB

Situation

Ein VPN-Problem tritt wiederholt auf.

CMDB zeigt

Knowledge Base zeigt

Nutzen

Der Service Desk kann neue Incidents schneller erkennen und bearbeiten.

Zusammenspiel mit Information Security Management

Information Security Management benötigt Configuration-Daten für Risikobewertung und Schutzmaßnahmen.

Wichtige Fragen:

Ohne Configuration-Daten ist Sicherheitsarbeit unvollständig.

Beispiel: Sicherheitslücke

Situation

Eine kritische Schwachstelle betrifft eine bestimmte Softwareversion.

Mit guter CMDB

Es ist erkennbar:

Nutzen

Patchpriorisierung wird schneller und nachvollziehbarer.

Zusammenspiel mit IT Asset Management

IT Asset Management und Service Configuration Management überschneiden sich.

IT Asset Management liefert Informationen über:

Service Configuration Management ergänzt:

Ein Server kann gleichzeitig Asset und CI sein.

Beide Sichten sollten zusammenpassen.

Zusammenspiel mit Service Level Management

Service Level Management benötigt Configuration-Daten, um Service Levels realistisch zu bewerten.

Wichtige Fragen:

Service Levels sind schwer steuerbar, wenn die Serviceabhängigkeiten unbekannt sind.

Zusammenspiel mit Monitoring

Monitoring und Configuration Management ergänzen sich.

Monitoring zeigt:

Configuration Management zeigt:

Beispiel:

Monitoring meldet einen Serverausfall.

Die CMDB zeigt, dass daran ein geschäftskritischer Service hängt.

Dadurch kann der Incident korrekt priorisiert und kommuniziert werden.

Zusammenspiel mit Continual Improvement

Configuration Management liefert viele Verbesserungsansätze.

Beispiele:

Diese Erkenntnisse sollten in Continual Improvement einfließen.

Typischer Informationsfluss

Incident erkennt Datenfehler
        ↓
Datenfehler wird dokumentiert
        ↓
Configuration Management prüft und korrigiert
        ↓
Change aktualisiert CI oder Beziehung
        ↓
Problem Management erkennt Muster
        ↓
Knowledge Management ergänzt Workaround
        ↓
Reporting zeigt Datenqualität
        ↓
Continual Improvement verbessert Prozess und Pflege

Configuration Management ist dadurch Teil eines Lernkreislaufs.

Wichtige Schnittstelleninformationen

Für das Zusammenspiel mit anderen Practices sind besonders wichtig:

Diese Informationen sollten nicht nur vorhanden sein, sondern auch aktiv genutzt werden.

Praxisbeispiel: Major Incident

Situation

Ein zentraler Service fällt aus.

Incident Management benötigt

Configuration Management liefert

Nachbereitung

Praxisbeispiel: Wiederkehrende Druckerprobleme

Situation

Ein Standort meldet regelmäßig Druckprobleme.

Incident-Daten zeigen

Configuration-Daten zeigen

Problem Management erkennt

Der Fehler hängt mit einem alten Treiber und einer bestimmten Anwendung zusammen.

Verbesserung

Treiber wird über Change Enablement aktualisiert.

Knowledge-Artikel und CMDB werden angepasst.

Praxisbeispiel: Zertifikatsmanagement

Situation

Ein Zertifikat läuft ab und verursacht einen Incident.

Problem Management erkennt

Change Enablement setzt um

Configuration Management aktualisiert

Praxisbeispiel: Cloud-Ressource ohne Owner

Situation

Eine Cloud-Ressource erzeugt Kosten und ist sicherheitsrelevant.

Problem

Kein Owner, kein Service-Tag, keine Dokumentation.

Risiko

Verbesserung

Typische Fehler im Zusammenspiel

Fehler 1

CMDB wird gepflegt, aber im Incident Management nicht genutzt.

Fehler 2

Incidents zeigen Datenfehler, aber niemand korrigiert sie.

Fehler 3

Problem Management erkennt neue Abhängigkeiten, aber sie werden nicht dokumentiert.

Fehler 4

Changes ändern CIs, ohne die CMDB zu aktualisieren.

Fehler 5

Release und Deployment aktualisieren Versionen nicht.

Fehler 6

Knowledge-Artikel sind nicht mit Services oder CIs verknüpft.

Fehler 7

Security bewertet Risiken ohne aktuelle Configuration-Daten.

Fehler 8

Monitoring-Alarme enthalten keine Serviceinformationen.

Fehler 9

Asset-Daten und CI-Daten widersprechen sich.

Fehler 10

Owner und Supportgruppen sind veraltet.

Fehler 11

Configuration-Daten werden nur für Audits gepflegt, nicht für den Betrieb.

Fehler 12

Datenqualitätsprobleme werden gemessen, aber nicht verbessert.

Checkliste Zusammenspiel mit Incident Management

Checkliste Zusammenspiel mit Problem Management

Checkliste Zusammenspiel mit Change Enablement

Checkliste Zusammenspiel mit Release und Deployment

Checkliste Zusammenspiel mit Security

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten täglich an der Schnittstelle zwischen Technik, Support und Betrieb.

Für sie bedeutet das:

Gute Configuration-Daten entstehen nicht nur durch ein Tool.

Sie entstehen durch konsequente Nutzung im Alltag.

Zusammenfassung

Configuration-Daten bereitstellen
↓
Incident Management nutzt sie für Diagnose und Priorisierung
↓
Problem Management nutzt sie für Muster und Ursachen
↓
Change Enablement nutzt sie für Risiko- und Auswirkungsbewertung
↓
Release und Deployment aktualisieren Versionen und Beziehungen
↓
Knowledge Management verknüpft Workarounds und Runbooks
↓
Security nutzt Daten für Risiko- und Schwachstellenbewertung
↓
Datenfehler und neue Erkenntnisse fließen zurück
↓
CMDB, Service Maps und Dokumentation werden verbessert

Merksätze

Configuration-Daten sind nur wertvoll, wenn sie im Betrieb genutzt werden.

Incident Management braucht Service- und CI-Bezug für schnelle Diagnose.

Problem Management braucht Beziehungen, um gemeinsame Ursachen zu erkennen.

Change Enablement braucht Abhängigkeiten für realistische Risikobewertung.

Jeder relevante Change sollte Configuration-Daten aktualisieren.

Knowledge ohne CI-Bezug ist schwerer auffindbar.

Monitoring ohne Servicebezug erschwert Priorisierung.

Gute Configuration-Daten verbessern Support, Stabilität, Sicherheit und Veränderungsfähigkeit.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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. Knowledge Management

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. Knowledge Management

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. Knowledge Management

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. Knowledge Management

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. Knowledge Management

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

8. Service Level Management

8. Service Level Management

8.1 Service Level Management – Ziele, Begriffe und Grundlagen

Kurz erklärt

Service Level Management sorgt dafür, dass Erwartungen an IT-Services klar beschrieben, messbar gemacht, vereinbart, überwacht und regelmäßig überprüft werden.

Ziel ist nicht, möglichst viele Kennzahlen zu sammeln.

Ziel ist, gemeinsam zu verstehen:

Warum Service Level Management wichtig ist

Ohne klare Service Levels entstehen häufig Missverständnisse.

Beispiele:

Service Level Management macht Erwartungen sichtbar und steuerbar.

Was ist ein Service Level?

Ein Service Level beschreibt ein vereinbartes oder erwartetes Qualitätsniveau eines Service.

Beispiele:

Ein Service Level sollte verständlich, messbar und für den Service relevant sein.

Service Level Management ist mehr als SLA-Verwaltung

Ein häufiger Irrtum:

Service Level Management bedeutet nur, SLAs zu schreiben.

Das ist zu kurz gedacht.

Service Level Management umfasst auch:

Ein SLA allein verbessert noch keinen Service.

Ziele von Service Level Management

Service Level Management soll:

Wichtig ist, nicht nur technische Messwerte zu betrachten.

Entscheidend ist, ob der Service den benötigten Nutzen liefert.

Kunde, Benutzer und Service Provider unterscheiden

Rolle Bedeutung Beispiel
Kunde entscheidet oder verantwortet den Bedarf an einem Service Fachbereichsleitung
Benutzer nutzt den Service im Alltag Mitarbeitende im Mitarbeiterportal
Service Provider stellt den Service bereit oder betreibt ihn interne IT oder externer Anbieter
Service Owner verantwortet den Service innerhalb der Organisation Owner für VPN-Service
Stakeholder ist vom Service betroffen oder beteiligt Datenschutz, Security, Management

Kunden und Benutzer haben nicht immer dieselbe Perspektive.

Ein Kunde achtet oft auf Nutzen, Kosten und Risiko.

Ein Benutzer achtet stärker auf Alltagstauglichkeit, Geschwindigkeit und Verständlichkeit.

Service Level Agreement

Ein Service Level Agreement (SLA) ist eine Vereinbarung über Serviceziele zwischen Service Provider und Kunde.

Ein SLA kann enthalten:

Ein SLA sollte verständlich und realistisch sein.

Ein SLA, das niemand liest oder versteht, hilft im Betrieb wenig.

Service Level Requirement

Ein Service Level Requirement (SLR) beschreibt eine Anforderung an die Servicequalität.

Beispiele:

SLRs helfen, Erwartungen zu erfassen, bevor sie als Serviceziele vereinbart werden.

Service Level Target

Ein Service Level Target ist ein konkretes Ziel innerhalb eines Service Levels.

Beispiele:

Bereich mögliches Ziel
Verfügbarkeit Service ist während vereinbarter Servicezeit zu 99,5 Prozent verfügbar
Reaktion P1-Incidents werden innerhalb von 15 Minuten bearbeitet
Wiederherstellung P1-Incidents werden innerhalb von 4 Stunden gelöst oder umgangen
Bearbeitung Standardsoftware wird innerhalb von 2 Arbeitstagen bereitgestellt
Performance Startseite lädt im Normalbetrieb unter 3 Sekunden
Kommunikation Statusupdates bei Major Incidents alle 30 Minuten

Ein Ziel muss messbar und fachlich sinnvoll sein.

Operational Level Agreement

Ein Operational Level Agreement (OLA) beschreibt interne Vereinbarungen zwischen unterstützenden Teams.

Beispiel:

Das SLA verspricht dem Fachbereich eine Wiederherstellung innerhalb von 4 Stunden.

Dafür braucht die IT interne Beiträge:

Ein OLA unterstützt also die Einhaltung des SLA.

Underpinning Contract

Ein Underpinning Contract ist ein unterstützender Vertrag mit einem externen Lieferanten.

Beispiele:

Wenn ein SLA von externen Leistungen abhängt, müssen Lieferantenverträge dazu passen.

Beispiel:

Ein interner Service kann keine Wiederherstellung innerhalb von 2 Stunden garantieren, wenn der externe Lieferant nur Reaktion am nächsten Arbeitstag zusagt.

SLA, OLA und Lieferantenvertrag im Zusammenhang

Kundenanforderung
    ↓
Service Level Requirement
    ↓
Service Level Agreement
    ↓
interne Operational Level Agreements
    ↓
externe Underpinning Contracts
    ↓
technische Umsetzung, Monitoring und Reporting

Die Ziele müssen zusammenpassen.

Sonst werden Versprechen gemacht, die technisch oder organisatorisch nicht erfüllbar sind.

Servicebeschreibung als Grundlage

Vor Service Levels muss klar sein, welcher Service gemeint ist.

Eine Servicebeschreibung kann enthalten:

Ohne klare Servicebeschreibung ist ein SLA schwer verständlich.

Beispiel: Servicebeschreibung VPN-Zugang

Feld Beispiel
Service VPN-Zugang
Zweck sicherer Zugriff auf interne Ressourcen von außerhalb
Benutzer berechtigte Mitarbeitende
Supportzeit Montag bis Freitag, 08:00 bis 18:00 Uhr
Abhängigkeiten VPN-Gateway, MFA, Identity Provider, Internet
Service Owner IT-Infrastruktur
Einschränkung private Geräte nur nach Freigabe
Knowledge Benutzeranleitung VPN, Known Error VPN-Client

Solche Informationen helfen, Erwartungen und Ziele sauber zu formulieren.

Messbarkeit

Ein Service Level sollte messbar sein.

Ungeeignet:

Der Service soll schnell sein.

Besser:

Die Startseite soll während normaler Last innerhalb von drei Sekunden laden.

Ungeeignet:

Der Support soll zeitnah reagieren.

Besser:

Kritische Incidents werden innerhalb von 15 Minuten aufgenommen und priorisiert.

Messbarkeit verhindert Diskussionen über unklare Begriffe.

Messmethode festlegen

Zu jedem Ziel sollte klar sein:

Beispiel:

Verfügbarkeit kann unterschiedlich gemessen werden:

Ohne Messmethode ist eine Kennzahl schwer vergleichbar.

Technische Kennzahl und Benutzererfahrung unterscheiden

Ein Service kann technisch verfügbar sein und trotzdem schlecht nutzbar sein.

Beispiele:

Service Level Management sollte deshalb technische Messwerte und Benutzererfahrung zusammen betrachten.

Geeignete Kennzahlen

Geeignete Kennzahlen sind:

Beispiele:

Eine Kennzahl sollte eine Entscheidung oder Verbesserung unterstützen.

Problematische Kennzahlen

Kennzahlen können falsche Anreize erzeugen.

Kennzahl möglicher Fehlanreiz
viele geschlossene Tickets schnelle Schließung statt guter Lösung
sehr kurze Bearbeitungszeit komplexe Fälle werden oberflächlich behandelt
hohe SLA-Erfüllung Ziele sind zu niedrig gesetzt
wenige Eskalationen notwendige Eskalationen werden vermieden
hohe Verfügbarkeit Benutzerprobleme werden übersehen
viele Knowledge-Artikel Menge statt Qualität

Kennzahlen müssen deshalb immer mit Kontext bewertet werden.

Service Level und Priorität

Service Levels hängen oft mit Prioritäten zusammen.

Beispiel:

Priorität typische Bedeutung
P1 kritischer Serviceausfall mit hoher Auswirkung
P2 wichtige Funktion stark eingeschränkt
P3 einzelner Benutzer oder begrenzte Auswirkung
P4 niedrige Auswirkung oder Standardanfrage

Wichtig:

Priorität sollte nicht nur aus Dringlichkeit entstehen.

Sie sollte Auswirkung und Dringlichkeit gemeinsam betrachten.

Ein einzelner Benutzer kann eine hohe Priorität haben, wenn eine geschäftskritische Rolle betroffen ist.

Reaktionszeit und Lösungszeit unterscheiden

Begriff Bedeutung
Reaktionszeit Zeit bis zur ersten qualifizierten Bearbeitung oder Rückmeldung
Lösungszeit Zeit bis zur vollständigen Lösung oder vereinbarten Wiederherstellung
Wiederherstellungszeit Zeit bis der Service wieder nutzbar ist, ggf. mit Workaround
Bearbeitungszeit Zeit, in der aktiv am Vorgang gearbeitet wird
Wartezeit Zeit, in der auf Benutzer, Lieferant oder Genehmigung gewartet wird

Diese Begriffe sollten nicht vermischt werden.

Ein Ticket kann schnell beantwortet, aber noch lange nicht gelöst sein.

Verfügbarkeit

Verfügbarkeit beschreibt, ob ein Service im vereinbarten Zeitraum nutzbar ist.

Wichtige Fragen:

Beispiel:

99,5 Prozent Verfügbarkeit während Servicezeit bedeutet etwas anderes als 99,5 Prozent rund um die Uhr.

Servicezeit und Supportzeit unterscheiden

Begriff Bedeutung
Servicezeit Zeitraum, in dem der Service vereinbarungsgemäß nutzbar sein soll
Supportzeit Zeitraum, in dem Unterstützung verfügbar ist
Wartungsfenster geplanter Zeitraum für Änderungen oder Wartung
Bereitschaft Unterstützung außerhalb normaler Zeiten bei definierten Fällen

Ein Service kann rund um die Uhr verfügbar sein, aber nur zu bestimmten Zeiten vollen Support haben.

Diese Unterschiede müssen klar kommuniziert werden.

Wartungsfenster

Wartungsfenster sollten in Service Leveln berücksichtigt werden.

Zu klären ist:

Ein Wartungsfenster muss zur Nutzung des Services passen.

Ein technisch bequemes Wartungsfenster kann fachlich ungeeignet sein.

Service Level und Benutzerkommunikation

Benutzer sollten wissen:

Unklare Kommunikation führt zu falschen Erwartungen.

Service Level Management unterstützt deshalb auch verständliche Kommunikation.

Service Review

Ein Service Review ist eine regelmäßige Besprechung zur Servicequalität.

Mögliche Inhalte:

Ein Service Review sollte nicht nur Zahlen vorlesen.

Es sollte helfen, Servicequalität zu verstehen und zu verbessern.

Reporting

Service Level Reporting stellt Informationen zur Serviceleistung bereit.

Gute Reports sind:

Ein guter Report beantwortet:

SLA-Abweichungen

Eine SLA-Abweichung bedeutet, dass ein vereinbartes Ziel nicht erreicht wurde.

Zu prüfen ist:

Eine SLA-Abweichung sollte nicht nur berichtet, sondern analysiert werden.

Service Level und Continual Improvement

Service Level Management liefert wichtige Hinweise für Verbesserungen.

Beispiele:

Diese Hinweise sollten in Continual Improvement einfließen.

Service Level und Kosten

Höhere Service Levels verursachen oft höhere Kosten.

Beispiele:

Deshalb müssen Service Levels realistisch und wirtschaftlich sinnvoll sein.

Nicht jeder Service benötigt maximale Verfügbarkeit.

Service Level und Risiko

Service Levels sollten zum Risiko passen.

Fragen:

Ein Service mit hohem Risiko benötigt strengere Ziele als ein unkritischer interner Testservice.

Service Level und Lieferanten

Viele Services hängen von Lieferanten ab.

Beispiele:

Service Level Management muss prüfen:

Interne Zusagen dürfen externe Abhängigkeiten nicht ignorieren.

Service Level und Monitoring

Monitoring liefert Daten für Service Level Management.

Beispiele:

Wichtig ist, dass Monitoring den Service aus relevanter Sicht misst.

Ein Server-Ping allein reicht oft nicht aus, um Servicequalität zu bewerten.

Service Level und Service Configuration Management

Service Configuration Management hilft zu verstehen:

Ohne Configuration-Daten sind Service Levels schwer realistisch zu bewerten.

Service Level und Incident Management

Incident Management liefert Daten über Servicequalität.

Beispiele:

Diese Daten helfen, SLA-Erfüllung und Verbesserungspotenzial zu bewerten.

Service Level und Problem Management

Problem Management unterstützt Service Level Management, wenn Ziele wiederholt verfehlt werden.

Beispiele:

Dann reicht Reporting allein nicht aus.

Die Ursache muss untersucht und dauerhaft verbessert werden.

Service Level und Change Enablement

Changes können Service Levels beeinflussen.

Zu prüfen ist:

Change Enablement und Service Level Management sollten deshalb zusammenarbeiten.

Praxisbeispiel: Mitarbeiterportal

Serviceziel

Das Mitarbeiterportal soll montags bis freitags von 08:00 bis 18:00 Uhr verfügbar sein.

Messung

Review

Im Monatsbericht wird sichtbar:

Erkenntnis

Technische Verfügbarkeit allein reicht nicht.

Performance und Benutzerfeedback müssen zusätzlich betrachtet werden.

Praxisbeispiel: Service Desk

Serviceziel

Kritische Incidents werden innerhalb von 15 Minuten aufgenommen und priorisiert.

Messung

Risiko

Wenn nur „erste Antwort“ gemessen wird, kann eine automatische Antwort die Kennzahl erfüllen, ohne echte Bearbeitung zu leisten.

Verbesserung

Gemessen wird qualifizierte Reaktion, nicht nur automatische Eingangsbestätigung.

Praxisbeispiel: Lieferantenabhängigkeit

Serviceziel

Interner Service soll innerhalb von 4 Stunden wiederhergestellt werden.

Problem

Ein externer Lieferant garantiert nur Reaktion innerhalb von 8 Stunden.

Folge

Das interne Ziel ist nicht realistisch, wenn der Lieferant kritisch beteiligt ist.

Verbesserung

Typische Fehler

Fehler 1

SLA wird geschrieben, aber nicht aktiv genutzt.

Fehler 2

Service Levels sind technisch korrekt, aber für Benutzer nicht verständlich.

Fehler 3

Kennzahlen messen Systeme, aber nicht Servicequalität.

Fehler 4

Messmethode ist unklar.

Fehler 5

Servicezeit, Supportzeit und Wartungsfenster werden vermischt.

Fehler 6

Interne SLAs ignorieren Lieferantenabhängigkeiten.

Fehler 7

Zu hohe Ziele werden vereinbart, obwohl Ressourcen fehlen.

Fehler 8

SLA-Abweichungen werden nur berichtet, aber nicht analysiert.

Fehler 9

Benutzerfeedback wird ignoriert.

Fehler 10

Service Reviews bestehen nur aus Zahlen ohne Maßnahmen.

Fehler 11

Prioritäten werden nur nach Lautstärke des Benutzers gesetzt.

Fehler 12

Service Level Management wird als reine Kontrollfunktion verstanden.

Checkliste Service Level definieren

Checkliste SLA-Inhalte

Checkliste Messung

Checkliste Service Review

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker unterstützen Service Level Management durch technische Daten und praktische Betriebserfahrung.

Im Arbeitsalltag bedeutet das:

Service Level Management hilft dabei, technische Arbeit mit Servicequalität und Benutzererwartung zu verbinden.

Zusammenfassung

Service verstehen
↓
Erwartungen und Anforderungen erfassen
↓
Service Level Requirements formulieren
↓
realistische Ziele vereinbaren
↓
Messmethoden festlegen
↓
SLA, OLA und Lieferantenabhängigkeiten abstimmen
↓
Serviceleistung überwachen
↓
verständlich berichten
↓
Service Reviews durchführen
↓
Abweichungen analysieren
↓
Verbesserungen anstoßen

Merksätze

Service Level Management klärt Erwartungen und macht Servicequalität steuerbar.

Ein SLA verbessert nichts, wenn es nicht verstanden, gemessen und genutzt wird.

Technische Verfügbarkeit ist nicht automatisch gute Benutzererfahrung.

Servicezeit, Supportzeit und Wartungsfenster müssen klar getrennt werden.

Interne Ziele müssen zu internen Fähigkeiten und Lieferantenverträgen passen.

Kennzahlen brauchen Kontext, sonst erzeugen sie falsche Schlüsse.

Service Reviews sollen Verbesserungen auslösen, nicht nur Zahlen präsentieren.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

8. Service Level Management

8.2 SLA, SLR, OLA und Underpinning Contracts

Kurz erklärt

Service Level Management arbeitet mit mehreren Arten von Vereinbarungen und Anforderungen.

SLR beschreibt, welche Servicequalität benötigt wird.

SLA beschreibt, welche Servicequalität zwischen Kunde und Service Provider vereinbart ist.

OLA beschreibt interne Unterstützungsvereinbarungen zwischen Teams.

Underpinning Contracts beschreiben unterstützende Verträge mit externen Lieferanten.

Diese Ebenen müssen zusammenpassen, sonst werden Serviceziele vereinbart, die praktisch nicht erfüllbar sind.

Warum diese Begriffe wichtig sind

Ein IT-Service wird selten von nur einer Stelle erbracht.

Beispiel:

Der Service „Mitarbeiterportal“ kann abhängig sein von:

Wenn ein SLA dem Fachbereich eine schnelle Wiederherstellung verspricht, müssen alle unterstützenden Teams und Lieferanten dazu beitragen können.

Deshalb reicht es nicht, nur ein SLA zu schreiben.

Die Vereinbarungen im Hintergrund müssen ebenfalls passen.

Grundmodell

Service Level Requirement
    ↓
beschreibt benötigte Servicequalität
    ↓
Service Level Agreement
    ↓
vereinbart Servicequalität mit dem Kunden
    ↓
Operational Level Agreements
    ↓
regeln interne Unterstützungsleistungen
    ↓
Underpinning Contracts
    ↓
sichern externe Lieferantenleistungen ab
    ↓
Monitoring, Reporting und Service Reviews
    ↓
prüfen, ob Ziele erreicht werden

Alle Ebenen müssen aufeinander abgestimmt sein.

Service Level Requirement

Ein Service Level Requirement (SLR) beschreibt eine Anforderung an die Servicequalität.

SLRs entstehen häufig aus:

Ein SLR ist noch nicht automatisch eine verbindliche Vereinbarung.

Es ist zunächst eine Anforderung, die geprüft, bewertet und verhandelt werden muss.

Beispiele für Service Level Requirements

Bereich Beispiel für SLR
Verfügbarkeit Mitarbeiterportal soll während Geschäftszeiten verfügbar sein
Support Benutzer benötigen Support montags bis freitags von 08:00 bis 18:00 Uhr
Reaktion kritische Störungen sollen sehr schnell aufgenommen werden
Wiederherstellung zentrale Störungen sollen innerhalb weniger Stunden umgangen oder behoben werden
Performance häufig genutzte Seiten sollen zügig laden
Requests Standardsoftware soll innerhalb weniger Arbeitstage bereitgestellt werden
Kommunikation bei größeren Störungen sollen regelmäßige Statusupdates erfolgen
Sicherheit Sicherheitsvorfälle sollen sofort eskaliert werden

SLRs sollten so formuliert sein, dass sie später in messbare Ziele überführt werden können.

SLR prüfen

Nicht jede Anforderung kann unverändert übernommen werden.

Zu prüfen ist:

Service Level Management hilft, Anforderungen realistisch zu machen.

Beispiel: unrealistisches SLR

Anforderung

Das System soll immer verfügbar sein.

Problem

„Immer“ ist unklar und praktisch kaum erreichbar.

Besser prüfen:

Daraus kann ein realistisches SLA-Ziel entstehen.

Service Level Agreement

Ein Service Level Agreement (SLA) ist eine Vereinbarung zwischen Service Provider und Kunde über die erwartete und vereinbarte Servicequalität.

Ein SLA beschreibt nicht nur technische Werte.

Es beschreibt, was der Service leisten soll und wie die Leistung bewertet wird.

Typische Inhalte:

Ein SLA sollte verständlich, realistisch und überprüfbar sein.

SLA ist eine Vereinbarung, kein Wunschzettel

Ein SLA darf keine Ziele enthalten, die nicht erbracht werden können.

Ungeeignet:

Fachbereich wünscht 24/7-Verfügbarkeit, obwohl kein 24/7-Betrieb, keine Bereitschaft und kein passender Lieferantenvertrag existieren.

Besser:

Verfügbarkeitsziel, Supportzeiten, Bereitschaft und Lieferantenleistungen werden gemeinsam geprüft und realistisch vereinbart.

Ein SLA muss zu Fähigkeiten, Budget, Risiko und Organisation passen.

Arten von SLAs

Mögliche SLA-Formen:

SLA-Art Beschreibung Beispiel
Servicebezogenes SLA gilt für einen bestimmten Service SLA für VPN-Zugang
Kundenbezogenes SLA gilt für einen bestimmten Kunden oder Fachbereich SLA für Personalabteilung
Mehrstufiges SLA kombiniert allgemeine und spezifische Vereinbarungen allgemeine IT-Supportregeln plus spezielle Ziele für kritischen Service
Interner Service Level wird intern vereinbart und berichtet interner Service Desk Support
Externer SLA-Bezug hängt von Lieferantenvertrag ab Cloud-Service mit Provider-SLA

Die passende Form hängt von Organisation und Servicekatalog ab.

SLA-Inhalte verständlich formulieren

Ein SLA sollte nicht nur juristisch oder technisch formuliert sein.

Ungeeignet:

HTTP-Endpunkt antwortet in 99,7 Prozent der Messintervalle mit Statuscode 200.

Besser ergänzt:

Der Service gilt als verfügbar, wenn Benutzer die Startseite öffnen und sich anmelden können. Technisches Monitoring prüft zusätzlich den HTTP-Status und die Login-Funktion.

Technische Definitionen sind wichtig.

Aber der Servicebezug muss verständlich bleiben.

Geltungsbereich

Der Geltungsbereich beschreibt, wofür das SLA gilt und wofür nicht.

Zu klären ist:

Ein unklarer Geltungsbereich führt später zu Streit über Erwartungen.

Beispiel Geltungsbereich

Service

VPN-Zugang für berechtigte Mitarbeitende.

Eingeschlossen

Nicht eingeschlossen

Diese Abgrenzung macht Erwartungen klarer.

Servicezeit

Die Servicezeit beschreibt, wann ein Service vereinbarungsgemäß nutzbar sein soll.

Beispiele:

Servicezeit ist wichtig für Verfügbarkeitsmessung und Wartungsplanung.

Supportzeit

Die Supportzeit beschreibt, wann Unterstützung verfügbar ist.

Beispiele:

Ein Service kann auch außerhalb der Supportzeit verfügbar sein.

Aber bei Störungen gelten dann möglicherweise andere Reaktionszeiten.

Servicezeit und Supportzeit unterscheiden

Begriff Bedeutung Beispiel
Servicezeit Service soll nutzbar sein Mitarbeiterportal 24/7 erreichbar
Supportzeit Hilfe ist verfügbar Service Desk 08:00 bis 18:00 Uhr
Wartungsfenster geplante Änderungen erlaubt Sonntag 22:00 bis 23:00 Uhr
Bereitschaft definierte Unterstützung außerhalb normaler Zeiten P1-Rufbereitschaft nachts

Diese Begriffe dürfen nicht vermischt werden.

Wartungsfenster

Wartungsfenster regeln, wann geplante Arbeiten stattfinden dürfen.

Zu klären ist:

Ein Wartungsfenster sollte zur Nutzung des Services passen.

Ein technisch bequemes Zeitfenster kann fachlich ungeeignet sein.

Verfügbarkeit im SLA

Verfügbarkeit beschreibt, ob ein Service im vereinbarten Zeitraum nutzbar ist.

Wichtig ist die genaue Definition.

Zu klären ist:

Ohne klare Definition ist eine Verfügbarkeitszahl schwer interpretierbar.

Beispiel Verfügbarkeitsziel

Ungeeignet:

Service ist zu 99,9 Prozent verfügbar.

Besser:

Der Service gilt während der vereinbarten Servicezeit als verfügbar, wenn Benutzer die Startseite öffnen, sich anmelden und die Hauptfunktion nutzen können. Geplante Wartungsfenster werden separat ausgewiesen.

Diese Definition ist für Technik und Benutzer klarer.

Reaktionszeit

Reaktionszeit beschreibt die Zeit bis zur ersten qualifizierten Bearbeitung oder Rückmeldung.

Wichtig:

Eine automatische Eingangsbestätigung ist nicht automatisch eine qualifizierte Reaktion.

Beispiele:

Reaktionszeit sollte mit Priorität und Supportzeit verknüpft sein.

Wiederherstellungszeit

Wiederherstellungszeit beschreibt, bis wann ein Service wieder nutzbar sein soll.

Das kann bedeuten:

Wichtig ist, genau zu definieren, was als wiederhergestellt gilt.

Beispiel:

Ein Workaround kann den Benutzer wieder arbeitsfähig machen, obwohl die Ursache noch nicht dauerhaft behoben ist.

Lösungszeit

Lösungszeit beschreibt die Zeit bis zur endgültigen Lösung.

Sie ist nicht immer identisch mit Wiederherstellungszeit.

Beispiel:

Ein bekannter Fehler kann durch Workaround kurzfristig umgangen werden.

Die dauerhafte Lösung erfolgt erst durch einen späteren Change.

Dann ist der Service wiederhergestellt, aber das Problem noch nicht endgültig gelöst.

Prioritäten im SLA

SLAs enthalten häufig Prioritätsklassen.

Eine Priorität sollte aus Auswirkung und Dringlichkeit entstehen.

Auswirkung Dringlichkeit mögliche Priorität
viele Benutzer betroffen sofortige Arbeit blockiert P1
wichtiger Fachbereich betroffen kurzfristige Bearbeitung nötig P2
einzelner Benutzer betroffen Arbeit teilweise möglich P3
geringe Auswirkung kein Zeitdruck P4

Die konkrete Matrix muss zur Organisation passen.

Wichtig ist, Priorität nicht nur nach Lautstärke oder subjektivem Druck zu vergeben.

Auswirkung

Auswirkung beschreibt, wie stark ein Incident, Request oder Problem den Service oder die Organisation betrifft.

Kriterien:

Ein einzelner Benutzer kann hohe Auswirkung haben, wenn eine kritische Rolle betroffen ist.

Dringlichkeit

Dringlichkeit beschreibt, wie schnell gehandelt werden muss.

Kriterien:

Hohe Dringlichkeit ohne hohe Auswirkung führt nicht automatisch zu höchster Priorität.

Beides muss gemeinsam bewertet werden.

Messmethoden im SLA

Ein SLA-Ziel braucht eine klare Messmethode.

Zu definieren ist:

Beispiel:

Bei Reaktionszeit muss klar sein, ob die Zeit ab Ticketeingang, ab Kategorisierung oder ab Supportzeitbeginn zählt.

Ausnahmen

SLAs sollten Ausnahmen definieren.

Beispiele:

Ausnahmen dürfen nicht genutzt werden, um Verantwortung zu vermeiden.

Sie müssen nachvollziehbar sein.

OLA

Ein Operational Level Agreement (OLA) ist eine interne Vereinbarung zwischen Teams oder Organisationseinheiten.

Ziel:

Interne Teams stellen gemeinsam sicher, dass ein SLA erfüllt werden kann.

Beispiele:

OLAs sind interne Zusagen, keine Kundenzusagen.

Warum OLAs wichtig sind

Ein SLA kann nur eingehalten werden, wenn interne Abläufe funktionieren.

Ohne OLA entstehen Probleme:

OLAs machen interne Beiträge transparent.

Beispiel OLA-Kette

SLA:

P1-Incident wird innerhalb von 4 Stunden wiederhergestellt.

Dafür notwendige OLA-Beiträge:

Team interner Beitrag
Service Desk Ticket aufnehmen, priorisieren, Kommunikation starten
Monitoring Alarm korrekt auslösen
Plattformteam Serverzustand prüfen
Datenbankteam Datenbankverfügbarkeit prüfen
Netzwerkteam Netz- und Firewallpfade prüfen
Service Owner fachliche Auswirkung bewerten
Kommunikation Statusupdates unterstützen

Nur zusammen kann das SLA erreicht werden.

OLA-Inhalte

Ein OLA kann enthalten:

Ein OLA muss praktikabel sein.

Zu komplizierte interne Vereinbarungen werden im Alltag nicht genutzt.

OLA und Ticketübergabe

OLAs helfen besonders bei Übergaben.

Zu klären ist:

Klare Übergaben verhindern Verzögerungen und Doppelarbeit.

Underpinning Contract

Ein Underpinning Contract ist ein unterstützender Vertrag mit einem externen Lieferanten.

Er kann Leistungen regeln wie:

Underpinning Contracts müssen zu den internen SLAs passen.

Warum Underpinning Contracts wichtig sind

Viele IT-Services hängen von externen Leistungen ab.

Beispiele:

Wenn ein externer Vertrag schwächer ist als das interne SLA, entsteht ein Risiko.

Die Organisation verspricht dann möglicherweise mehr, als sie liefern kann.

Beispiel Lieferantenabhängigkeit

Interner SLA-Wunsch:

Fachanwendung bei kritischer Störung innerhalb von 4 Stunden wiederherstellen.

Externer Softwarevertrag:

Hersteller reagiert innerhalb von 1 Arbeitstag.

Risiko:

Wenn die Ursache beim Hersteller liegt, kann das interne Ziel nicht sicher eingehalten werden.

Mögliche Maßnahmen:

SLA, OLA und Underpinning Contract abstimmen

Zu prüfen ist:

Eine SLA-Zusage darf nicht isoliert betrachtet werden.

Typische Lücke zwischen SLA und OLA

SLA:

P2-Incidents werden innerhalb von 8 Stunden gelöst.

Interne Realität:

Folge:

Das SLA wird regelmäßig verfehlt.

Verbesserung:

Typische Lücke zwischen SLA und Lieferantenvertrag

SLA:

Service ist Montag bis Freitag von 08:00 bis 18:00 Uhr unterstützt.

Lieferantenvertrag:

Hersteller-Support nur von 09:00 bis 17:00 Uhr.

Folge:

Bei Störung um 17:30 Uhr kann interne IT das SLA möglicherweise nicht erfüllen.

Verbesserung:

Mehrere Lieferanten

Ein Service kann von mehreren Lieferanten abhängen.

Beispiel:

Dann muss klar sein:

Der Benutzer interessiert sich nicht für Lieferantengrenzen.

Für ihn zählt, ob der Service funktioniert.

SLA und Supplier Management

Supplier Management stellt sicher, dass Lieferantenleistungen die Serviceziele unterstützen.

Wichtige Fragen:

Service Level Management und Supplier Management müssen eng zusammenarbeiten.

SLA und Service Configuration Management

Service Configuration Management zeigt, welche CIs und Lieferanten einen Service unterstützen.

Das hilft bei SLA-Planung.

Beispiele:

Ohne diese Abhängigkeiten können SLAs falsch bewertet werden.

SLA und Monitoring

SLA-Ziele müssen messbar sein.

Monitoring liefert Daten für:

Wichtig ist:

Monitoring muss die vereinbarte Servicequalität abbilden.

Ein Server-Ping reicht nicht aus, wenn Benutzer sich trotzdem nicht anmelden können.

SLA und Reporting

SLA-Reports sollten zeigen:

Ein guter Report erklärt nicht nur, ob ein Ziel rot oder grün ist.

Er erklärt, warum es relevant ist und was daraus folgt.

SLA und Service Review

Im Service Review werden SLA, OLA und Lieferantenleistung gemeinsam betrachtet.

Mögliche Fragen:

Service Reviews verbinden Messung mit Entscheidung.

SLA-Änderungen

SLAs sollten angepasst werden, wenn sich Rahmenbedingungen ändern.

Auslöser:

Ein SLA ist kein dauerhaft unveränderliches Dokument.

Es muss regelmäßig überprüft werden.

SLA-Verhandlung

Bei SLA-Verhandlungen sollten folgende Punkte offen besprochen werden:

Wichtig:

Nicht jede hohe Anforderung ist automatisch sinnvoll.

Manchmal ist ein realistischer Service Level mit gutem Workaround besser als ein teures Maximalziel.

Service Level und Kosten

Höhere Service Levels können höhere Kosten verursachen.

Beispiele:

Service Level Management macht sichtbar, welche Qualität benötigt wird und was sie kostet.

Service Level und Risikoakzeptanz

Nicht alle Risiken lassen sich vollständig vermeiden.

Wenn ein niedrigeres Service Level vereinbart wird, sollte klar sein:

Beispiel:

Ein nicht kritischer Testservice erhält kein 24/7-SLA.

Das ist akzeptabel, wenn die Auswirkung gering und bekannt ist.

Service Level und Kommunikation

SLA-Inhalte müssen für Benutzer und Stakeholder verständlich kommuniziert werden.

Benutzer sollten wissen:

Unklare Kommunikation erzeugt falsche Erwartungen.

Praxisbeispiel: VPN-Service

SLR

Benutzer im Homeoffice benötigen werktags zuverlässigen Zugriff auf interne Systeme.

SLA

VPN-Service soll Montag bis Freitag von 08:00 bis 18:00 Uhr verfügbar sein.

P1-Incidents werden innerhalb von 15 Minuten qualifiziert bearbeitet.

OLA

Netzwerkteam übernimmt P1-Eskalationen innerhalb von 30 Minuten.

Identity-Team unterstützt bei MFA-Störungen innerhalb definierter Zeit.

Underpinning Contract

Internetprovider und VPN-Hersteller bieten Support innerhalb vereinbarter Zeiten.

Prüfung

Wenn Hersteller-Support nur am nächsten Arbeitstag reagiert, muss das SLA entsprechend bewertet werden.

Praxisbeispiel: Mitarbeiterportal

SLR

Fachbereich benötigt das Portal während der Kernarbeitszeit.

SLA

Servicezeit Montag bis Freitag von 07:00 bis 19:00 Uhr.

Geplante Wartung nur außerhalb dieser Zeit.

OLA

Anwendungsteam und Datenbankteam stellen interne Unterstützung während Servicezeit sicher.

Underpinning Contract

Cloud-Datenbank besitzt Provider-Support für kritische Fälle.

Review

Nach mehreren Performancebeschwerden wird ein zusätzliches Performance-Ziel ergänzt.

Praxisbeispiel: Standardsoftware bereitstellen

SLR

Benutzer sollen freigegebene Standardsoftware schnell erhalten.

SLA

Standardsoftware wird innerhalb von 2 Arbeitstagen bereitgestellt.

OLA

Service Desk prüft Anfrage innerhalb eines Arbeitstages.

Endpoint-Team stellt Paketierung und Softwareverteilung bereit.

Underpinning Contract

Softwarelieferant stellt Lizenzportal und Support bereit.

Risiko

Wenn Lizenzfreigabe extern länger dauert, muss dies im SLA berücksichtigt werden.

Praxisbeispiel: Lieferant passt nicht zum SLA

Situation

Interner SLA verspricht Wiederherstellung innerhalb von 4 Stunden.

Problem

Der externe Wartungsvertrag garantiert Ersatzteilversand erst am nächsten Arbeitstag.

Folge

Das SLA ist bei Hardwaredefekt nicht erfüllbar.

Mögliche Maßnahmen

Typische Fehler

Fehler 1

SLR wird ungeprüft direkt als SLA übernommen.

Fehler 2

SLA-Ziele sind nicht messbar.

Fehler 3

SLA, OLA und Lieferantenverträge passen nicht zusammen.

Fehler 4

Supportzeit und Servicezeit werden vermischt.

Fehler 5

Wartungsfenster sind nicht geregelt.

Fehler 6

Prioritäten sind unklar oder subjektiv.

Fehler 7

Messmethode wird nicht definiert.

Fehler 8

Ausnahmen werden nicht dokumentiert.

Fehler 9

Interne Teams kennen ihre OLA-Beiträge nicht.

Fehler 10

Lieferantenabhängigkeiten werden nicht berücksichtigt.

Fehler 11

SLA wird nicht regelmäßig überprüft.

Fehler 12

SLA wird als Kontrollinstrument genutzt, aber nicht als Grundlage für Verbesserung.

Checkliste SLR

Checkliste SLA

Checkliste OLA

Checkliste Underpinning Contract

Checkliste Abstimmung SLA, OLA und Lieferantenvertrag

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker müssen SLA, OLA und Lieferantenabhängigkeiten praktisch verstehen.

Im Arbeitsalltag bedeutet das:

Service Level Management verbindet technische Realität mit vereinbarter Servicequalität.

Zusammenfassung

Service Level Requirement erfassen
↓
fachlichen Bedarf, Risiko und Machbarkeit prüfen
↓
realistische SLA-Ziele vereinbaren
↓
interne OLAs zur Unterstützung festlegen
↓
externe Underpinning Contracts abstimmen
↓
Messmethoden und Ausnahmen definieren
↓
Monitoring und Reporting einrichten
↓
Service Reviews durchführen
↓
Abweichungen analysieren
↓
SLA, OLA oder Lieferantenvertrag verbessern

Merksätze

Ein SLR beschreibt Bedarf, ein SLA beschreibt eine Vereinbarung.

Ein SLA ist nur erfüllbar, wenn OLAs und Lieferantenverträge dazu passen.

Servicezeit und Supportzeit sind nicht dasselbe.

Reaktionszeit ist nicht automatisch Lösungszeit.

Ein Ziel ohne Messmethode ist später kaum bewertbar.

Lieferantenabhängigkeiten müssen vor der SLA-Zusage geprüft werden.

Gute Service Level sind realistisch, messbar und verständlich.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

8. Service Level Management

8.3 Kennzahlen, Messmethoden und Reporting

Kurz erklärt

Kennzahlen, Messmethoden und Reporting machen Servicequalität sichtbar.

Entscheidend ist nicht, möglichst viele Zahlen zu sammeln.

Entscheidend ist, die richtigen Fragen zu beantworten:

Gute Messung unterstützt Entscheidungen. Schlechte Messung erzeugt falsche Sicherheit.

Warum Kennzahlen wichtig sind

Ohne Messung bleibt Servicequalität oft subjektiv.

Typische Aussagen ohne klare Daten:

Kennzahlen helfen, solche Aussagen zu prüfen.

Sie zeigen:

Kennzahlen sind kein Selbstzweck

Eine Kennzahl ist nur sinnvoll, wenn sie genutzt wird.

Ungeeignet:

Wir messen alles, weil es technisch möglich ist.

Besser:

Wir messen das, was für Servicequalität, Steuerung, Risiko und Verbesserung wichtig ist.

Zu viele Kennzahlen führen zu unübersichtlichen Reports.

Zu wenige Kennzahlen können wichtige Probleme verdecken.

Die richtige Auswahl hängt vom Service, den Zielen und den Entscheidungen ab, die unterstützt werden sollen.

Gute Kennzahlen

Gute Kennzahlen sind:

Eine Kennzahl sollte immer eine Frage beantworten.

Beispiel:

Nicht nur:

Wie viele Tickets wurden geschlossen?

Sondern:

Werden Benutzer schneller wieder arbeitsfähig und verbessert sich die Servicequalität?

Kennzahl und Ziel unterscheiden

Eine Kennzahl ist ein Messwert.

Ein Ziel beschreibt, welcher Wert erreicht werden soll.

Begriff Bedeutung Beispiel
Kennzahl gemessener Wert Verfügbarkeit des Service
Zielwert gewünschter oder vereinbarter Wert mindestens 99,5 Prozent während Servicezeit
Messmethode Art der Ermittlung synthetischer Login-Test alle 5 Minuten
Report Darstellung und Bewertung Monatsbericht Servicequalität
Maßnahme Reaktion auf Ergebnis Problem Record für wiederholte Ausfälle

Ohne Zielwert ist eine Kennzahl schwer zu bewerten.

Ohne Messmethode ist ein Ziel schwer überprüfbar.

Messmethode

Die Messmethode beschreibt, wie eine Kennzahl ermittelt wird.

Zu klären ist:

Eine unklare Messmethode führt zu Diskussionen über Zahlen statt zu Verbesserungen.

Beispiel: Verfügbarkeit messen

Unklar:

Der Service war zu 99,9 Prozent verfügbar.

Klärende Fragen:

Erst mit diesen Angaben ist die Zahl aussagekräftig.

Technische Messung und Benutzerperspektive

Technische Messungen sind wichtig, aber nicht ausreichend.

Beispiele:

Technische Sicht Benutzerperspektive
Server antwortet auf Ping Benutzer kann Anwendung nutzen
HTTP-Status ist 200 Anmeldung funktioniert wirklich
Datenbank läuft Anwendung verarbeitet Daten korrekt
CPU-Auslastung ist normal Oberfläche reagiert schnell genug
Service Desk Ticket ist geschlossen Benutzer ist tatsächlich arbeitsfähig

Ein Service kann technisch verfügbar sein und trotzdem für Benutzer schlecht nutzbar sein.

Servicebezogene Kennzahlen

Service Level Management sollte möglichst servicebezogen messen.

Beispiele:

Servicebezogene Kennzahlen sind hilfreicher als reine Technikzahlen ohne Kontext.

Verfügbarkeit

Verfügbarkeit beschreibt, ob ein Service im vereinbarten Zeitraum nutzbar ist.

Zu definieren ist:

Beispiel:

Der Service gilt als verfügbar, wenn Benutzer während der Servicezeit die Startseite öffnen, sich anmelden und die Hauptfunktion nutzen können.

Diese Definition ist aussagekräftiger als nur:

Server ist erreichbar.

Berechnung von Verfügbarkeit

Eine einfache Formel:

Verfügbarkeit = verfügbare Zeit / vereinbarte Servicezeit × 100

Beispiel:

vereinbarte Servicezeit im Monat: 10.000 Minuten
Ausfallzeit: 50 Minuten

Verfügbarkeit = 9.950 / 10.000 × 100
Verfügbarkeit = 99,5 Prozent

Wichtig:

Die Berechnung muss definieren, welche Ausfallzeit zählt und welche nicht.

Geplante Wartung

Geplante Wartung sollte getrennt betrachtet werden.

Zu klären ist:

Geplante Wartung ist nicht automatisch unproblematisch.

Auch geplante Arbeiten können die Benutzererfahrung verschlechtern, wenn sie schlecht kommuniziert oder schlecht geplant sind.

Teilausfälle

Nicht jeder Ausfall betrifft den gesamten Service.

Beispiele:

Für Teilausfälle muss festgelegt werden, wie sie bewertet werden.

Sonst wird Servicequalität zu positiv oder zu negativ dargestellt.

Reaktionszeit

Reaktionszeit beschreibt die Zeit bis zur ersten qualifizierten Bearbeitung oder Rückmeldung.

Zu klären ist:

Eine automatische Antwort sollte nicht als echte Reaktion gewertet werden, wenn keine Bearbeitung beginnt.

Wiederherstellungszeit

Wiederherstellungszeit beschreibt, wann ein Service wieder nutzbar ist.

Das kann bedeuten:

Wichtig ist, den Begriff vorher zu definieren.

Ein Benutzer kann wieder arbeitsfähig sein, obwohl die Ursache noch nicht dauerhaft behoben ist.

Lösungszeit

Lösungszeit beschreibt die Zeit bis zur endgültigen Lösung.

Sie unterscheidet sich von Wiederherstellungszeit.

Beispiel:

Ein Incident wird durch Workaround schnell behoben.

Das zugrunde liegende Problem wird erst später durch einen Change dauerhaft gelöst.

Dann sind Wiederherstellung und endgültige Lösung unterschiedliche Zeitpunkte.

MTTA, MTTR und ähnliche Kennzahlen

Häufig genutzte Kennzahlen:

Kennzahl Bedeutung
MTTA durchschnittliche Zeit bis zur Annahme oder Reaktion
MTTR durchschnittliche Zeit bis Wiederherstellung oder Lösung
MTBF durchschnittliche Zeit zwischen Ausfällen
MTRS durchschnittliche Zeit bis Service-Wiederherstellung
FCR First Contact Resolution, Lösung beim ersten Kontakt

Wichtig:

Abkürzungen müssen in der Organisation einheitlich definiert werden.

MTTR kann je nach Organisation „Mean Time to Repair“, „Mean Time to Restore“ oder anders verstanden werden.

Incident-Kennzahlen

Mögliche Incident-Kennzahlen:

Wichtig ist die Kombination.

Eine einzelne Incident-Kennzahl erklärt selten die ganze Situation.

Problem-Kennzahlen

Mögliche Problem-Kennzahlen:

Problem-Kennzahlen helfen, strukturelle Ursachen sichtbar zu machen.

Sie sollten nicht dazu führen, Problems vorschnell zu schließen.

Change-Kennzahlen

Mögliche Change-Kennzahlen:

Change-Kennzahlen helfen, Stabilität und Veränderungsfähigkeit zu bewerten.

Request-Kennzahlen

Mögliche Request-Kennzahlen:

Diese Kennzahlen helfen, Serviceportale, Formulare und Automatisierung zu verbessern.

Knowledge-Kennzahlen

Mögliche Knowledge-Kennzahlen:

Knowledge-Kennzahlen zeigen, ob Wissen im Alltag hilft oder nur abgelegt wird.

Benutzerzufriedenheit

Benutzerzufriedenheit ergänzt technische Kennzahlen.

Mögliche Methoden:

Wichtig:

Zufriedenheit ist subjektiv, aber trotzdem wertvoll.

Sie zeigt, ob gemessene Servicequalität auch so erlebt wird.

Experience Level

Neben klassischen Service Levels kann auch die Benutzererfahrung betrachtet werden.

Beispiele:

Technische Ziele allein zeigen nicht immer die tatsächliche Nutzungserfahrung.

Reporting

Reporting stellt Kennzahlen und Bewertungen verständlich dar.

Ein Report sollte nicht nur Zahlen zeigen.

Er sollte erklären:

Ein guter Report führt zu Handlung, nicht nur zu Ablage.

Zielgruppen für Reporting

Verschiedene Zielgruppen benötigen unterschiedliche Reports.

Zielgruppe benötigt typischerweise
Management Risiken, Trends, Zielerreichung, Entscheidungen
Service Owner Servicequalität, Abweichungen, Maßnahmen
Service Desk Tickettrends, Knowledge-Lücken, Eskalationen
Fachteam technische Ursachen, Changes, Problems
Security Team Schwachstellen, kritische CIs, Vorfälle
Benutzer Status, einfache Verfügbarkeit, bekannte Störungen

Nicht jeder Report muss alle Details enthalten.

Management-Reporting

Management benötigt meist verdichtete Informationen.

Geeignete Inhalte:

Management-Reports sollten nicht mit technischen Details überladen werden.

Sie müssen entscheidungsfähig machen.

Operatives Reporting

Operative Teams benötigen mehr Detail.

Geeignete Inhalte:

Operatives Reporting hilft bei Analyse und Verbesserung der täglichen Arbeit.

Benutzerorientiertes Reporting

Benutzer benötigen klare und einfache Informationen.

Beispiele:

Benutzer brauchen keine internen Detailberichte.

Sie brauchen verständliche Orientierung.

Dashboards

Dashboards zeigen aktuelle oder regelmäßige Informationen auf einen Blick.

Mögliche Inhalte:

Ein Dashboard muss gepflegt und richtig interpretiert werden.

Ein grünes Dashboard bedeutet nicht automatisch, dass Benutzer zufrieden sind.

Ampelstatus

Viele Reports nutzen Ampelfarben.

Beispiel:

Status Bedeutung
grün Ziel erreicht
gelb Risiko oder leichte Abweichung
rot Ziel verfehlt oder kritisches Risiko

Wichtig:

Ampeln brauchen klare Regeln.

Ungeeignet:

Gelb nach Bauchgefühl.

Besser:

Gelb, wenn Zielwert um bis zu 10 Prozent verfehlt wird oder ein Risiko für den nächsten Zeitraum besteht.

Ein einzelner Monatswert reicht oft nicht aus.

Wichtiger sind Trends.

Beispiele:

Durchschnittswerte vorsichtig nutzen

Durchschnittswerte können täuschen.

Beispiel:

Die durchschnittliche Lösungszeit beträgt 4 Stunden.

Mögliche Realität:

Deshalb sollten Durchschnittswerte ergänzt werden durch:

Median und Perzentile

Der Median zeigt den mittleren Wert einer Verteilung.

Perzentile zeigen, wie viele Fälle unter einem bestimmten Wert liegen.

Beispiel:

Das ist oft aussagekräftiger als nur ein Durchschnittswert.

Kontext zu Kennzahlen

Kennzahlen brauchen Kontext.

Beispiel:

Ticketvolumen steigt.

Mögliche Ursachen:

Ohne Kontext kann eine Kennzahl falsch interpretiert werden.

Datenqualität im Reporting

Reports sind nur so gut wie ihre Daten.

Typische Datenprobleme:

Datenqualität muss regelmäßig geprüft werden.

Messung kann Verhalten beeinflussen

Kennzahlen beeinflussen, wie Menschen arbeiten.

Beispiele:

Kennzahlen müssen so gewählt werden, dass sie gutes Verhalten fördern.

Falsche Anreize vermeiden

Besser ist eine Kombination von Kennzahlen.

Beispiele:

Kombination besser als
Lösungszeit und Wiedereröffnungsquote nur schnelle Lösung
Ticketanzahl und Benutzerzufriedenheit nur Produktivität
SLA-Erfüllung und Major-Incident-Analyse nur grüne Ampel
Change-Erfolg und Incidents nach Changes nur Anzahl Changes
Knowledge-Nutzung und Artikelbewertung nur Anzahl Artikel

Gute Kennzahlensets betrachten Qualität, Wirkung und Stabilität gemeinsam.

Reporting-Frequenz

Die Frequenz hängt vom Zweck ab.

Report mögliche Frequenz
Live-Dashboard für Betrieb laufend
Major-Incident-Status während Ereignis regelmäßig
Service-Level-Report monatlich
Service Review monatlich oder quartalsweise
Lieferantenreport monatlich oder quartalsweise
Managementreport monatlich oder quartalsweise
Datenqualitätsreport regelmäßig nach Bedarf

Zu häufige Reports ohne Handlung erzeugen Aufwand.

Zu seltene Reports erkennen Probleme zu spät.

Reporting und Service Review

Reports sollten Service Reviews vorbereiten.

Ein Service Review nutzt Reports, um zu besprechen:

Reporting liefert Daten.

Service Review macht daraus Bewertung und Handlung.

SLA-Abweichungen berichten

Bei SLA-Abweichungen sollte ein Report enthalten:

Nur „SLA nicht erreicht“ reicht nicht aus.

Beispiel: SLA-Abweichung

Ziel

P1-Incidents innerhalb von 4 Stunden wiederherstellen.

Ergebnis

Ziel wurde in einem Fall verfehlt.

Ursache

Datenbankproblem wurde zu spät an das zuständige Team eskaliert.

Auswirkung

Mitarbeiterportal war für mehrere Standorte nicht nutzbar.

Maßnahme

OLA-Eskalation wird angepasst.

Service Desk erhält neuen Knowledge-Artikel.

Monitoringalarm wird geändert.

Serviceverbesserung aus Kennzahlen ableiten

Kennzahlen sollen Verbesserungen auslösen.

Beispiele:

Die wichtigste Frage lautet:

Welche konkrete Handlung folgt aus dem Report?

Kennzahlen für Continual Improvement

Continual Improvement nutzt Kennzahlen zur Priorisierung.

Hilfreich sind:

Nicht jede schlechte Kennzahl ist sofort höchste Priorität.

Die Bedeutung hängt von Servicekritikalität und Auswirkung ab.

Praxisbeispiel: Grüne SLA, unzufriedene Benutzer

Situation

SLA-Verfügbarkeit wurde erreicht.

Trotzdem sind Benutzer unzufrieden.

Analyse

Erkenntnis

Verfügbarkeit allein misst nicht die Benutzererfahrung.

Verbesserung

Performance-Ziel und Benutzerfeedback werden ergänzt.

Praxisbeispiel: Ticketzahlen steigen

Situation

Ticketanzahl im Service Desk steigt stark.

Mögliche Ursachen

Vorgehen

Tickets nach Service, Kategorie, Priorität und Ursache auswerten.

Nicht vorschnell annehmen, dass der Service Desk schlechter arbeitet.

Praxisbeispiel: Lieferant erfüllt Ziel nicht

Situation

SLA-Abweichungen entstehen durch langsame Lieferantenreaktion.

Reporting zeigt

Verbesserung

Supplier Review durchführen.

Underpinning Contract prüfen.

Internes SLA realistisch bewerten.

Praxisbeispiel: Knowledge-Lücke

Situation

Viele Benutzer suchen im Portal nach „neues Handy MFA“.

Es gibt keinen passenden Treffer.

Folge

Viele Tickets entstehen.

Verbesserung

Benutzerartikel „MFA auf neuem Smartphone einrichten“ erstellen.

Suchbegriffe ergänzen.

Ticketformular verlinken.

Messung

Suchtreffer, Artikelbewertung und Ticketvolumen nach Verbesserung prüfen.

Typische Fehler

Fehler 1

Es werden zu viele Kennzahlen ohne klare Entscheidung gemessen.

Fehler 2

Kennzahlen sind technisch korrekt, aber für den Service nicht relevant.

Fehler 3

Messmethoden sind nicht definiert.

Fehler 4

Reports enthalten Zahlen ohne Bewertung.

Fehler 5

Durchschnittswerte verdecken kritische Einzelfälle.

Fehler 6

Benutzerzufriedenheit wird ignoriert.

Fehler 7

Datenqualität in Tickets und CMDB ist schlecht.

Fehler 8

Automatische Antworten werden als echte Reaktion gezählt.

Fehler 9

SLA-Abweichungen werden nur gemeldet, aber nicht analysiert.

Fehler 10

Kennzahlen erzeugen falsche Anreize.

Fehler 11

Reports sind nicht auf Zielgruppen angepasst.

Fehler 12

Aus Reports entstehen keine Verbesserungsmaßnahmen.

Checkliste Kennzahl auswählen

Checkliste Messmethode

Checkliste Reporting

Checkliste SLA-Abweichung analysieren

Checkliste Datenqualität für Reports

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker liefern viele Daten, die für Service Level Management wichtig sind.

Im Arbeitsalltag bedeutet das:

Gute Messung hilft, technische Arbeit sichtbar und steuerbar zu machen.

Zusammenfassung

Serviceziele verstehen
↓
passende Kennzahlen auswählen
↓
Messmethode eindeutig definieren
↓
Datenquellen und Datenqualität sichern
↓
technische und Benutzerperspektive kombinieren
↓
Ergebnisse verständlich berichten
↓
Abweichungen analysieren
↓
Trends erkennen
↓
Verbesserungsmaßnahmen ableiten
↓
Wirkung erneut messen

Merksätze

Eine Kennzahl ist nur sinnvoll, wenn daraus eine Entscheidung oder Verbesserung entstehen kann.

Messmethode und Datenquelle müssen klar sein.

Technische Verfügbarkeit ist nicht automatisch gute Servicequalität.

Durchschnittswerte können kritische Probleme verdecken.

Reports brauchen Kontext, Bewertung und Maßnahmen.

Kennzahlen können Verhalten beeinflussen und falsche Anreize erzeugen.

Reporting ist die Grundlage für Service Reviews und Continual Improvement.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

8. Service Level Management

8.4 Service Reviews und Continual Improvement

Kurz erklärt

Service Reviews bewerten regelmäßig, wie gut ein IT-Service seine vereinbarten Ziele erfüllt und ob er den erwarteten Nutzen liefert.

Dabei werden nicht nur SLA-Werte betrachtet.

Auch Incidents, Problems, Changes, Benutzerfeedback, Risiken, Lieferantenleistungen und Verbesserungspotenziale gehören dazu.

Continual Improvement sorgt anschließend dafür, dass aus Erkenntnissen konkrete und überprüfbare Verbesserungen entstehen.

Warum Service Reviews wichtig sind

Ein Report allein verbessert keinen Service.

Kennzahlen zeigen beispielsweise:

Ein Service Review bewertet zusätzlich:

Ein Service Review verbindet Daten mit Bewertung, Verantwortung und Handlung.

Was ist ein Service Review?

Ein Service Review ist eine regelmäßige strukturierte Betrachtung eines Service.

Dabei wird gemeinsam geprüft:

Service Reviews können je nach Kritikalität und Organisation:

stattfinden.

Ziele eines Service Reviews

Ein Service Review soll:

Das Review sollte nicht nur rückwärts schauen.

Es sollte auch kommende Risiken und Veränderungen betrachten.

Service Review ist keine reine Zahlenbesprechung

Ein häufiger Fehler:

Im Service Review werden nur Diagramme und SLA-Werte vorgelesen.

Das reicht nicht aus.

Ein gutes Service Review beantwortet:

Merke

Reporting liefert Informationen.

Das Service Review bewertet diese Informationen und löst Entscheidungen aus.

Teilnehmer eines Service Reviews

Mögliche Teilnehmer:

Nicht jedes Review benötigt alle Rollen.

Die Teilnehmer sollten zum Service und zu den aktuellen Themen passen.

Rolle des Service Owners

Der Service Owner trägt eine zentrale Verantwortung.

Typische Aufgaben:

Der Service Owner muss nicht jede technische Einzelheit kennen.

Er muss aber verstehen, welche Auswirkungen technische Themen auf den Service haben.

Rolle des Service Level Managers

Der Service Level Manager unterstützt durch:

Die Rolle kann je nach Organisation anders benannt oder verteilt sein.

Rolle des Service Desk

Der Service Desk liefert wichtige Praxiserkenntnisse.

Beispiele:

Der Service Desk kennt oft die tatsächliche Benutzerwahrnehmung besser als rein technische Reports.

Rolle der technischen Teams

Technische Teams liefern Informationen zu:

Technische Informationen sollten so erklärt werden, dass ihre Servicewirkung verständlich ist.

Rolle des Fachbereichs oder Kunden

Fachbereiche und Kunden liefern die Geschäftsperspektive.

Wichtige Fragen:

Servicequalität darf nicht nur aus IT-Sicht bewertet werden.

Vorbereitung eines Service Reviews

Vor dem Review sollten relevante Informationen gesammelt werden.

Mögliche Inhalte:

Die Vorbereitung sollte sich auf wichtige Themen konzentrieren.

Ein unübersichtlicher Datenberg erschwert Entscheidungen.

Mögliche Agenda

Eine kompakte Agenda kann so aussehen:

  1. Servicezustand und wichtige Entwicklungen
  2. Zielerreichung und SLA-Abweichungen
  3. Benutzer- und Kundenfeedback
  4. wichtige Incidents und Major Incidents
  5. offene Problems und Known Errors
  6. Changes und Releases
  7. Lieferantenleistung
  8. Risiken und kommende Anforderungen
  9. Verbesserungsmaßnahmen
  10. Entscheidungen, Owner und Termine

Die Agenda sollte an den Service angepasst werden.

Servicezustand bewerten

Zu Beginn sollte ein Gesamtbild entstehen.

Mögliche Fragen:

Ein Gesamtbild hilft, einzelne Kennzahlen richtig einzuordnen.

SLA-Erfüllung bewerten

Zu prüfen ist:

Eine Zielverfehlung muss nicht automatisch bedeuten, dass das Ziel falsch ist.

Aber sie muss verstanden werden.

Erreichte Ziele kritisch betrachten

Auch grüne Kennzahlen sollten hinterfragt werden.

Beispiele:

Ein grünes Dashboard ist kein Beweis für einen guten Service.

Benutzerfeedback einbeziehen

Benutzerfeedback kann stammen aus:

Zu prüfen ist:

Qualitatives Feedback ergänzt Kennzahlen.

Incidents betrachten

Im Service Review sollten nicht alle Incidents einzeln besprochen werden.

Wichtig sind:

Ziel ist, Muster und Verbesserungsmöglichkeiten zu erkennen.

Major Incidents betrachten

Bei Major Incidents sollte geprüft werden:

Ein Major-Incident-Review kann Teil eines Service Reviews sein oder separat stattfinden.

Problems und Known Errors betrachten

Wichtige Fragen:

Häufig genutzte Workarounds sind ein Warnsignal.

Changes betrachten

Zu prüfen ist:

Changes beeinflussen Servicequalität direkt.

Releases betrachten

Bei Releases sind wichtig:

Ein technisch erfolgreiches Deployment kann aus Benutzersicht trotzdem unzureichend sein.

Lieferantenleistung betrachten

Bei externen Abhängigkeiten sollte geprüft werden:

Lieferantenprobleme dürfen nicht einfach als unveränderlich hingenommen werden.

Risiken betrachten

Mögliche Servicerisiken:

Risiken sollten mit Auswirkung, Wahrscheinlichkeit, Owner und Maßnahme dokumentiert werden.

Kommende Anforderungen betrachten

Ein Service Review sollte auch nach vorne schauen.

Beispiele:

So können notwendige Changes und Kapazitäten frühzeitig geplant werden.

Continual Improvement

Continual Improvement bedeutet, Services, Practices, Prozesse, Werkzeuge und Arbeitsweisen fortlaufend zu verbessern.

Verbesserungen können klein oder groß sein.

Beispiele:

Nicht jede Verbesserung benötigt ein großes Projekt.

Continual Improvement ist keine einmalige Maßnahme

Ein häufiger Irrtum:

Nach einem Verbesserungsprojekt ist der Service dauerhaft optimiert.

Services verändern sich ständig.

Gründe:

Deshalb ist Continual Improvement ein fortlaufender Kreislauf.

Verbesserungskreislauf

Ein möglicher Ablauf:

aktuelle Situation verstehen
        ↓
Zielzustand festlegen
        ↓
Verbesserungspotenzial erkennen
        ↓
Maßnahme priorisieren
        ↓
Umsetzung planen
        ↓
Verbesserung durchführen
        ↓
Wirkung messen
        ↓
Ergebnis bewerten
        ↓
nächste Verbesserung auswählen

Wichtig ist, nach der Umsetzung zu prüfen, ob die gewünschte Wirkung tatsächlich erreicht wurde.

Improvement Register

Ein Improvement Register sammelt Verbesserungsideen und Maßnahmen.

Mögliche Felder:

Das Improvement Register kann in einem ITSM-System, Projekttool, Wiki oder einer strukturierten Liste geführt werden.

Warum ein Improvement Register wichtig ist

Ohne zentrale Nachverfolgung entstehen typische Probleme:

Das Register schafft Transparenz und Verantwortung.

Verbesserungsideen erfassen

Verbesserungsideen können entstehen aus:

Jede Idee sollte kurz beschreiben:

Verbesserungen priorisieren

Nicht alle Verbesserungen können gleichzeitig umgesetzt werden.

Mögliche Kriterien:

Eine einfache Maßnahme mit hohem Nutzen kann vor einem großen Projekt sinnvoll sein.

Nutzen und Aufwand vergleichen

Eine einfache Bewertung kann helfen:

Nutzen Aufwand mögliche Priorität
hoch niedrig sehr hoch
hoch hoch strategisch bewerten
niedrig niedrig bei Gelegenheit
niedrig hoch meist geringe Priorität

Diese Matrix ist nur ein Beispiel.

Sicherheits- oder Compliance-Themen können unabhängig vom Aufwand hohe Priorität besitzen.

Erfolgskriterien für Verbesserungen

Vor Umsetzung sollte klar sein, woran Erfolg erkannt wird.

Beispiele:

Verbesserung Erfolgskriterium
Knowledge-Artikel verbessern weniger Tickets und bessere Bewertungen
Monitoring erweitern Fehler wird vor Benutzerbeschwerden erkannt
OLA anpassen Eskalationszeit sinkt
Self-Service einführen Standardrequests werden schneller erfüllt
Zertifikatsmonitoring einführen keine ungeplanten Ausfälle durch Ablauf
Change-Checkliste ergänzen weniger Incidents nach Changes

Ohne Erfolgskriterien bleibt unklar, ob die Verbesserung wirksam war.

Kleine Verbesserungen

Kleine Verbesserungen können schnell Wirkung zeigen.

Beispiele:

Solche Verbesserungen sollten nicht unnötig durch große Prozesse verzögert werden.

Größere Verbesserungen

Größere Maßnahmen können sein:

Solche Maßnahmen benötigen oft:

Verbesserung und Change Enablement

Viele Verbesserungen werden durch Changes umgesetzt.

Beispiele:

Continual Improvement erkennt und priorisiert den Verbesserungsbedarf.

Change Enablement sorgt für kontrollierte Umsetzung.

Verbesserung und Problem Management

Problem Management liefert Ursachen und dauerhafte Lösungsvorschläge.

Beispiele:

Diese Erkenntnisse können als Improvement erfasst und priorisiert werden.

Verbesserung und Knowledge Management

Knowledge Management kann verbessert werden durch:

Wissen ist häufig eine schnelle und kostengünstige Verbesserungsmöglichkeit.

Verbesserung und Service Configuration Management

Configuration-Daten können verbessert werden durch:

Gute Configuration-Daten verbessern Incident, Problem, Change und Security Management.

Verbesserung und Supplier Management

Lieferantenverbesserungen können sein:

Lieferantenleistung ist Teil der gesamten Servicequalität.

Verbesserungen verfolgen

Jede wichtige Maßnahme sollte mindestens besitzen:

Ungeeignet:

Monitoring verbessern.

Besser:

Bis zum 30.09.2026 Zertifikatsmonitoring für alle produktiven Webservices einführen. Erfolg: Warnung mindestens 30 Tage vor Ablauf, Owner je Zertifikat dokumentiert.

Status von Verbesserungen

Mögliche Status:

Ein klarer Status erleichtert Nachverfolgung.

Blockierte Verbesserungen

Verbesserungen können blockiert sein durch:

Blockierungen sollten sichtbar sein.

Zu dokumentieren ist:

Wirkung messen

Nach Umsetzung muss geprüft werden:

Eine umgesetzte Maßnahme ist nicht automatisch eine erfolgreiche Verbesserung.

Verbesserung schließen

Eine Verbesserung sollte erst geschlossen werden, wenn:

Wenn die Wirkung noch nicht messbar ist, kann der Status „Wirkung wird geprüft“ sinnvoll sein.

Service Review dokumentieren

Ein Service Review sollte dokumentieren:

Die Dokumentation sollte kompakt und handlungsorientiert sein.

Entscheidungen dokumentieren

Wichtige Entscheidungen können sein:

Zu jeder Entscheidung sollte nachvollziehbar sein:

Maßnahmenprotokoll

Ein einfaches Maßnahmenprotokoll:

Maßnahme Owner Termin Status Erfolgskriterium
VPN-Known-Error aktualisieren Netzwerkteam 15.08.2026 offen Service Desk findet Artikel
Zertifikatsmonitoring einführen Plattformteam 30.09.2026 geplant Warnung 30 Tage vor Ablauf
OLA-Eskalation anpassen Service Level Manager 31.08.2026 in Arbeit kürzere P1-Eskalationszeit

Ein Maßnahmenprotokoll verhindert, dass Entscheidungen nach dem Review verloren gehen.

Folgereview

Im nächsten Service Review sollte geprüft werden:

Ohne Folgereview verlieren Maßnahmen schnell an Verbindlichkeit.

Praxisbeispiel: Wiederkehrende VPN-Incidents

Beobachtung

VPN-Incidents steigen über drei Monate.

Service Review

Verbesserung

Erfolgskriterium

VPN-Incidents sinken innerhalb von vier Wochen deutlich.

Praxisbeispiel: SLA erfüllt, Benutzer unzufrieden

Beobachtung

Verfügbarkeitsziel wurde erreicht.

Benutzer melden trotzdem schlechte Performance.

Service Review

Verbesserung

Praxisbeispiel: Lieferantenproblem

Beobachtung

Mehrere SLA-Abweichungen entstehen durch langsame Herstellerreaktion.

Service Review

Verbesserung

Praxisbeispiel: Major Incident

Review-Erkenntnisse

Verbesserungen

Praxisbeispiel: Self-Service verbessern

Beobachtung

Viele Tickets entstehen zur MFA-Einrichtung.

Analyse

Verbesserungen

Erfolgskriterium

Weniger MFA-Standardtickets und bessere Artikelbewertung.

Typische Fehler

Fehler 1

Service Reviews bestehen nur aus dem Vorlesen von Kennzahlen.

Fehler 2

Es nehmen zu viele Personen ohne klare Rolle teil.

Fehler 3

Benutzer- und Fachbereichsfeedback fehlt.

Fehler 4

Grüne Kennzahlen werden nicht kritisch hinterfragt.

Fehler 5

SLA-Abweichungen werden erklärt, aber keine Maßnahmen beschlossen.

Fehler 6

Maßnahmen besitzen keinen Owner.

Fehler 7

Verbesserungen besitzen kein Erfolgskriterium.

Fehler 8

Lessons Learned werden nicht verfolgt.

Fehler 9

Lieferantenleistung wird getrennt vom Service betrachtet.

Fehler 10

Reviews schauen nur zurück und nicht auf kommende Risiken.

Fehler 11

Umgesetzte Maßnahmen werden nicht auf Wirkung geprüft.

Fehler 12

Verbesserungsideen gehen außerhalb eines Registers verloren.

Checkliste Service Review vorbereiten

Checkliste Service Review durchführen

Checkliste Improvement Register

Checkliste Wirkung prüfen

Checkliste Maßnahmenverfolgung

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker liefern wichtige technische Erkenntnisse für Service Reviews und Continual Improvement.

Im Arbeitsalltag bedeutet das:

Technische Verbesserung ist besonders wertvoll, wenn sie messbar zu stabileren Services und besserer Benutzerunterstützung führt.

Zusammenfassung

Serviceleistung und Benutzerfeedback sammeln
↓
Service Review vorbereiten
↓
Ziele, Abweichungen und Risiken bewerten
↓
Incidents, Problems, Changes und Lieferanten betrachten
↓
Verbesserungen identifizieren
↓
Nutzen, Risiko und Aufwand bewerten
↓
Maßnahmen priorisieren
↓
Owner, Termin und Erfolgskriterien festlegen
↓
Verbesserung kontrolliert umsetzen
↓
Wirkung messen
↓
Ergebnis im nächsten Service Review prüfen

Merksätze

Ein Service Review macht aus Reporting konkrete Entscheidungen.

Grüne Kennzahlen bedeuten nicht automatisch gute Servicequalität.

Benutzerfeedback gehört genauso zum Review wie technische Messwerte.

Jede wichtige Verbesserung braucht Owner, Termin und Erfolgskriterium.

Eine umgesetzte Maßnahme ist erst erfolgreich, wenn ihre Wirkung geprüft wurde.

Continual Improvement besteht aus vielen kleinen und großen Verbesserungen.

Reviews müssen auch kommende Risiken und Anforderungen betrachten.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

8. Service Level Management

8.5 Service Level Management im Zusammenspiel mit Incident, Problem, Change und Configuration Management

Kurz erklärt

Service Level Management kann Servicequalität nicht allein steuern.

Es benötigt Informationen aus Incident Management, Problem Management, Change Enablement, Service Configuration Management, Knowledge Management, Supplier Management sowie Measurement and Reporting.

Gleichzeitig liefert Service Level Management Ziele, Prioritäten und Anforderungen zurück, an denen diese Practices ihre Arbeit ausrichten können.

Erst durch dieses Zusammenspiel werden Servicequalität, Risiken und Verbesserungsbedarf aus Sicht der Benutzer und des Geschäfts sichtbar.

Warum das Zusammenspiel wichtig ist

Ein Service Level beschreibt, welche Qualität ein Service erreichen soll.

Ob diese Qualität tatsächlich erreicht wird, hängt jedoch von vielen Bereichen ab.

Beispiele:

Service Level Management verbindet diese Informationen mit den vereinbarten Servicezielen.

Grundidee des Zusammenspiels

Serviceziele und Erwartungen festlegen
        ↓
Service Level Management definiert messbare Ziele
        ↓
Incident Management liefert Störungs- und Wiederherstellungsdaten
        ↓
Problem Management untersucht wiederkehrende Ursachen
        ↓
Change Enablement setzt Verbesserungen kontrolliert um
        ↓
Service Configuration Management zeigt Abhängigkeiten
        ↓
Knowledge Management stellt nutzbares Wissen bereit
        ↓
Supplier Management bewertet externe Beiträge
        ↓
Measurement and Reporting zeigt Ergebnisse und Trends
        ↓
Service Review bewertet Abweichungen und Risiken
        ↓
Continual Improvement verfolgt Verbesserungen

Die Practices arbeiten nicht nacheinander in einer festen Reihenfolge.

Sie tauschen fortlaufend Informationen aus.

Service Level Management und Incident Management

Incident Management liefert wichtige Informationen darüber, wie stabil und zuverlässig ein Service im Alltag funktioniert.

Relevante Informationen:

Diese Daten helfen zu prüfen, ob vereinbarte Serviceziele erreicht werden.

Was Service Level Management an Incident Management liefert

Service Level Management unterstützt Incident Management durch:

Dadurch weiß Incident Management, welche Incidents besonders schnell und intensiv bearbeitet werden müssen.

Service Level und Incident-Priorität

Die Priorität eines Incidents sollte nicht allein von der Lautstärke eines Benutzers oder der technischen Komplexität abhängen.

Zu berücksichtigen sind:

Beispiel:

Ein technisch kleiner Fehler kann hohe Priorität besitzen, wenn ein geschäftskritischer Prozess vollständig blockiert wird.

Reaktionszeit im Incident Management

Service Level Management definiert möglicherweise ein Reaktionsziel.

Incident Management muss dafür nachvollziehbar erfassen:

Eine automatische Eingangsbestätigung sollte nicht mit einer qualifizierten Bearbeitung verwechselt werden.

Wiederherstellung und dauerhafte Lösung unterscheiden

Incident Management konzentriert sich auf die schnelle Wiederherstellung des Service.

Service Level Management kann deshalb ein Ziel für die Wiederherstellungszeit besitzen.

Beispiel:

Ein Workaround macht Benutzer nach zwei Stunden wieder arbeitsfähig.

Die dauerhafte Lösung erfolgt erst eine Woche später durch einen Change.

Dann gilt:

Diese Zeitpunkte sollten getrennt gemessen werden.

SLA-Verletzung durch Incident

Wenn ein Incident zu einer SLA-Verletzung führt, sollte geprüft werden:

Eine SLA-Verletzung ist häufig nicht nur ein technisches Ereignis.

Sie kann auch organisatorische Ursachen besitzen.

Beispiel: verspätete Eskalation

Situation

Ein geschäftskritischer Service fällt aus.

SLA-Ziel

Wiederherstellung innerhalb von vier Stunden.

Problem

Der Service Desk eskaliert erst nach zwei Stunden an das zuständige Fachteam.

Folge

Das Wiederherstellungsziel wird verfehlt.

Analyse

Verbesserungen

Service Level Management und Problem Management

Problem Management untersucht Ursachen wiederkehrender oder schwerwiegender Incidents.

Service Level Management hilft dabei, Problems zu priorisieren.

Relevante Kriterien:

Ein Problem kann hohe Priorität besitzen, auch wenn aktuell kein Incident offen ist.

Was Problem Management an Service Level Management liefert

Problem Management liefert:

Diese Informationen helfen, Servicequalität und zukünftige Risiken realistisch zu bewerten.

Häufige Workarounds als Service-Level-Risiko

Ein Workaround kann die Wiederherstellung beschleunigen.

Wenn er jedoch ständig genutzt wird, kann dies auf ein ungelöstes Problem hinweisen.

Zu prüfen ist:

Ein erreichtes SLA bedeutet nicht automatisch, dass der Service gesund ist.

Beispiel: Dienstneustart als Workaround

Situation

Ein Anwendungsdienst fällt regelmäßig aus.

Workaround

Der Service Desk veranlasst einen Neustart.

Kennzahl

Die Wiederherstellungszeit bleibt innerhalb des SLA.

Tatsächliches Problem

Verbesserung

Problem Record priorisieren und dauerhafte Lösung über Change Enablement umsetzen.

Problem-Priorisierung nach Servicewirkung

Problem Management sollte nicht nur technische Schwere betrachten.

Wichtige Fragen:

Service Level Management liefert dafür die geschäftliche und servicebezogene Perspektive.

Service Level Management und Change Enablement

Changes können Servicequalität verbessern oder verschlechtern.

Beispiele:

Service Level Management hilft zu bewerten, welche Serviceziele durch einen Change beeinflusst werden.

Was Service Level Management an Change Enablement liefert

Für die Change-Bewertung sind wichtig:

Dadurch kann ein Change nicht nur technisch, sondern auch servicebezogen bewertet werden.

Was Change Enablement an Service Level Management liefert

Change Enablement liefert:

Diese Informationen gehören in Service Reviews und Service-Level-Berichte.

Geplante Wartung und Service Levels

Geplante Wartung muss klar geregelt sein.

Zu prüfen ist:

Nicht jede angekündigte Unterbrechung darf automatisch aus der Messung ausgeschlossen werden.

Die Regeln müssen vorher vereinbart sein.

Change Freeze und kritische Geschäftszeiten

Service Level Management hilft zu erkennen, wann Changes besonders riskant sind.

Beispiele:

In solchen Zeiträumen kann ein Change Freeze oder eine besonders strenge Bewertung sinnvoll sein.

Emergency Changes können trotzdem notwendig sein.

Sie benötigen dann eine bewusste Risikoentscheidung.

Changes zur Verbesserung von Service Levels

Wenn Serviceziele regelmäßig verfehlt werden, können Changes notwendig sein.

Beispiele:

Service Level Management beschreibt den Verbesserungsbedarf.

Change Enablement steuert die kontrollierte Umsetzung.

Beispiel: Performance-Ziel wird verfehlt

Beobachtung

Das Mitarbeiterportal ist verfügbar, reagiert aber zu langsam.

Service Review

Das vereinbarte Performance-Ziel wird regelmäßig verfehlt.

Analyse

Changes

Erfolgskriterium

Die wichtigsten Benutzeraktionen liegen wieder innerhalb des vereinbarten Zielwerts.

Service Level Management und Service Configuration Management

Service Configuration Management zeigt, wie ein Service technisch und organisatorisch aufgebaut ist.

Wichtige Informationen:

Diese Informationen sind notwendig, um Service Levels realistisch festzulegen und Risiken zu verstehen.

Warum Serviceabhängigkeiten für SLAs wichtig sind

Ein Service kann nur so zuverlässig sein wie seine kritischen Abhängigkeiten.

Beispiel:

Das Mitarbeiterportal hängt ab von:

Ein hohes Verfügbarkeitsziel ist unrealistisch, wenn eine kritische Abhängigkeit deutlich schwächere Ziele oder keine Redundanz besitzt.

Configuration-Daten für SLA-Planung

Zu prüfen ist:

Diese Informationen helfen, Serviceziele realistisch zu gestalten.

Service Level Management verbessert Configuration Management

Service Reviews können Datenqualitätsprobleme sichtbar machen.

Beispiele:

Solche Erkenntnisse sollten in die Pflege der Configuration-Daten einfließen.

Beispiel: unbekannte Abhängigkeit

Situation

Ein interner Service verfehlt sein Verfügbarkeitsziel.

Analyse

Der Service hängt von einer externen API ab.

Diese Beziehung war in der CMDB nicht dokumentiert.

Folgen

Verbesserungen

Service Level Management und Knowledge Management

Knowledge Management beeinflusst Reaktions- und Wiederherstellungszeiten.

Gutes Wissen kann:

Knowledge Management trägt damit direkt zur Servicequalität bei.

Was Service Level Management an Knowledge Management liefert

Service Level Management zeigt, bei welchen Services und Themen Wissen besonders wichtig ist.

Beispiele:

Daraus können neue oder verbesserte Knowledge-Artikel entstehen.

Was Knowledge Management an Service Level Management liefert

Knowledge Management liefert:

Diese Informationen helfen zu verstehen, warum bestimmte Serviceziele erreicht oder verfehlt werden.

Beispiel: lange Wiederherstellungszeit

Beobachtung

DNS-Incidents werden regelmäßig zu spät gelöst.

Analyse

Verbesserungen

Erwartete Wirkung

Kürzere Erstdiagnose und schnellere Wiederherstellung.

Service Level Management und Supplier Management

Viele Services hängen von externen Lieferanten ab.

Beispiele:

Supplier Management sorgt dafür, dass Lieferantenleistungen die vereinbarten Serviceziele unterstützen.

Was Service Level Management an Supplier Management liefert

Supplier Management benötigt:

Daraus können geeignete Lieferantenverträge und Leistungsziele abgeleitet werden.

Was Supplier Management an Service Level Management liefert

Supplier Management liefert:

Diese Informationen gehören in Service Reviews.

Lieferantenvertrag und internes SLA abstimmen

Ein internes SLA darf nicht stärker sein als die tatsächlich verfügbare Unterstützung, sofern keine eigenen Schutzmaßnahmen bestehen.

Beispiel:

Internes Ziel

Wiederherstellung innerhalb von vier Stunden.

Lieferantenvertrag

Hersteller reagiert innerhalb eines Arbeitstages.

Mögliche Lösungen:

Service Level Management und Monitoring and Event Management

Monitoring liefert technische und servicebezogene Messdaten.

Beispiele:

Service Level Management definiert, welche Serviceeigenschaften gemessen werden müssen.

Monitoring aus Serviceperspektive

Unzureichend:

Webserver antwortet auf Ping.

Besser:

Ein Service kann technisch „grün“ erscheinen, obwohl Benutzer nicht arbeiten können.

Monitoring und Messmethode abstimmen

Zu klären ist:

Monitoring muss zu den vereinbarten Zielen passen.

Service Level Management und Measurement and Reporting

Measurement and Reporting bereitet Daten so auf, dass Servicequalität bewertet werden kann.

Service Level Management liefert dafür:

Measurement and Reporting liefert:

Reporting braucht Kontext aus anderen Practices

Eine Zahl allein erklärt nicht, warum ein Ziel verfehlt wurde.

Beispiel:

Verfügbarkeit beträgt 98,9 Prozent statt 99,5 Prozent.

Für eine sinnvolle Bewertung werden zusätzliche Informationen benötigt:

Reporting verbindet diese Informationen.

Service Level Management und Continual Improvement

Service Level Management erkennt Abweichungen und Verbesserungspotenziale.

Continual Improvement sorgt dafür, dass daraus konkrete Maßnahmen entstehen.

Mögliche Verbesserungen:

Verbesserungen aus Service Reviews

Ein möglicher Ablauf:

Serviceziel wird verfehlt
        ↓
Abweichung wird im Report sichtbar
        ↓
Service Review bewertet Ursache und Auswirkung
        ↓
Improvement wird erfasst
        ↓
Owner, Termin und Erfolgskriterium werden festgelegt
        ↓
Problem, Change, Knowledge oder Supplier Management wird eingebunden
        ↓
Maßnahme wird umgesetzt
        ↓
Wirkung wird gemessen
        ↓
Ergebnis wird im nächsten Service Review geprüft

So wird aus einer Kennzahl eine konkrete Verbesserung.

Service-Level-Ziele überprüfen

Nicht jede wiederholte Zielverfehlung bedeutet, dass das Ziel gesenkt werden sollte.

Zu prüfen ist:

Ziele sollten realistisch, aber nicht bequem sein.

Neue Service-Level-Ziele aus Verbesserungen

Neue Erkenntnisse können zusätzliche Ziele erforderlich machen.

Beispiele:

Service Levels sollten sich mit dem Service weiterentwickeln.

Rollen und Verantwortlichkeiten im Zusammenspiel

Rolle oder Practice Beitrag
Service Owner verantwortet Servicequalität und Prioritäten
Service Level Management definiert, misst und überprüft Serviceziele
Service Desk liefert Benutzerfeedback und Incident-Daten
Incident Management stellt Services wieder her
Problem Management untersucht Ursachen und Wiederholungen
Change Enablement setzt Änderungen kontrolliert um
Configuration Management liefert Services, CIs und Abhängigkeiten
Knowledge Management stellt Lösungen und Workarounds bereit
Supplier Management steuert externe Leistungen
Measurement and Reporting bereitet Daten und Trends auf
Continual Improvement verfolgt Verbesserungen

Die Verantwortlichkeiten müssen klar sein.

Servicequalität ist jedoch eine gemeinsame Aufgabe.

Informationsfluss zwischen den Practices

Service Level Management
    ↓ definiert Ziele
Incident Management
    ↓ liefert Störungsdaten
Problem Management
    ↓ liefert Ursachen und Known Errors
Change Enablement
    ↓ liefert Änderungen und Ergebnisse
Configuration Management
    ↓ liefert Abhängigkeiten und Kritikalität
Knowledge Management
    ↓ liefert Workarounds und Nutzungswissen
Supplier Management
    ↓ liefert externe Leistungsdaten
Measurement and Reporting
    ↓ erstellt Berichte und Trends
Service Review
    ↓ beschließt Verbesserungen
Continual Improvement
    ↓ verfolgt Umsetzung und Wirkung

Dieser Informationsfluss muss nicht in einem einzigen Werkzeug stattfinden.

Wichtig sind verlässliche Verknüpfungen und Verantwortlichkeiten.

Praxisbeispiel: VPN-Service

Service Level Management

Definiert Verfügbarkeit, Supportzeit und Wiederherstellungsziel.

Incident Management

Liefert Daten zu VPN-Abbrüchen und Wiederherstellungszeiten.

Problem Management

Erkennt fehlerhafte Client-Version als gemeinsame Ursache.

Knowledge Management

Stellt Workaround und Prüfschritte bereit.

Change Enablement

Steuert Pilot und Rollout einer neuen Client-Version.

Service Configuration Management

Zeigt betroffene Clientversionen, Gateway und MFA-Abhängigkeit.

Supplier Management

Prüft Herstellerunterstützung.

Continual Improvement

Misst, ob die VPN-Incidents nach dem Rollout sinken.

Praxisbeispiel: Zertifikatsausfall

Incident

Anmeldung am Mitarbeiterportal fällt aus.

Problem

Zertifikat war abgelaufen.

Configuration Management

Zertifikat war nicht als CI mit Owner und Ablaufdatum erfasst.

Service Level Management

Verfügbarkeitsziel wurde verfehlt.

Change Enablement

Zertifikat wird erneuert und Monitoring eingeführt.

Knowledge Management

Runbook und Prüfschritte werden erstellt.

Continual Improvement

Alle produktiven Zertifikate werden erfasst und mindestens 30 Tage vor Ablauf überwacht.

Praxisbeispiel: Lieferantenabhängige Störung

Situation

Ein SaaS-Service ist nicht erreichbar.

Incident Management

Koordiniert Benutzerkommunikation und Eskalation.

Supplier Management

Eskaliert an den Anbieter.

Service Level Management

Prüft Auswirkung auf SLA und Benutzer.

Configuration Management

Zeigt betroffene Geschäftsprozesse und Schnittstellen.

Problem Management

Prüft wiederkehrende Providerstörungen.

Continual Improvement

Bewertet zusätzlichen Workaround, Redundanz oder Vertragsänderung.

Praxisbeispiel: Service verfügbar, aber langsam

Monitoring

Server und Anwendung erscheinen verfügbar.

Benutzerfeedback

Benutzer melden lange Ladezeiten.

Service Level Management

Erkennt, dass nur Verfügbarkeit, aber keine Benutzerperformance gemessen wird.

Configuration Management

Zeigt Datenbank und externe Schnittstelle als Abhängigkeiten.

Problem Management

Untersucht Performanceursache.

Change Enablement

Steuert Kapazitäts- und Konfigurationsänderung.

Measurement and Reporting

Ergänzt Antwortzeit und synthetische Benutzertransaktion.

Praxisbeispiel: viele Standardtickets

Beobachtung

Viele Tickets betreffen Passwort und MFA.

Service Level Management

Erkennt hohe Bearbeitungsmenge und schlechte Benutzererfahrung.

Knowledge Management

Überarbeitet Benutzerartikel und Suchbegriffe.

Service Request Management

Vereinfacht Formulare und Automatisierung.

Service Desk

Liefert häufige Fragen und Rückmeldungen.

Continual Improvement

Misst Ticketentwicklung, Self-Service-Nutzung und Artikelbewertung.

Typische Fehler im Zusammenspiel

Fehler 1

Service Levels werden festgelegt, ohne technische Abhängigkeiten zu prüfen.

Fehler 2

Incident-Daten werden gemessen, aber nicht servicebezogen ausgewertet.

Fehler 3

Wiederholte SLA-Verletzungen führen nicht zu Problem Management.

Fehler 4

Changes werden durchgeführt, ohne Service-Level-Auswirkungen zu prüfen.

Fehler 5

Geplante Wartung wird pauschal aus allen Messungen ausgeschlossen.

Fehler 6

CMDB-Daten sind veraltet und führen zu falscher Risikobewertung.

Fehler 7

Lieferantenverträge unterstützen interne Serviceziele nicht.

Fehler 8

Monitoring misst einzelne Server, aber keine nutzbare Servicefunktion.

Fehler 9

Workarounds halten SLA-Ziele formal ein, obwohl der Service dauerhaft instabil ist.

Fehler 10

Knowledge-Lücken verlängern Wiederherstellungszeiten.

Fehler 11

Reports zeigen Abweichungen, aber keine Verantwortlichen oder Maßnahmen.

Fehler 12

Verbesserungen werden umgesetzt, aber ihre Wirkung wird nicht gemessen.

Checkliste Zusammenspiel mit Incident Management

Checkliste Zusammenspiel mit Problem Management

Checkliste Zusammenspiel mit Change Enablement

Checkliste Zusammenspiel mit Service Configuration Management

Checkliste Zusammenspiel mit Knowledge Management

Checkliste Zusammenspiel mit Supplier Management

Checkliste Service Review über alle Practices

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker liefern wichtige technische Informationen für das Zusammenspiel der Practices.

Im Arbeitsalltag bedeutet das:

Technische Arbeit wird dadurch nicht nur als einzelne Tätigkeit betrachtet.

Sie wird mit Servicequalität, Benutzerwirkung und geschäftlichem Nutzen verbunden.

Zusammenfassung

Serviceziele und Erwartungen festlegen
↓
Incident Management liefert Störungs- und Wiederherstellungsdaten
↓
Problem Management untersucht wiederkehrende Ursachen
↓
Change Enablement setzt Verbesserungen kontrolliert um
↓
Service Configuration Management zeigt Abhängigkeiten und Risiken
↓
Knowledge Management beschleunigt Diagnose und Wiederherstellung
↓
Supplier Management steuert externe Beiträge
↓
Monitoring und Reporting messen Servicequalität
↓
Service Review bewertet Abweichungen und Risiken
↓
Continual Improvement verfolgt Maßnahmen und Wirkung

Merksätze

Service Level Management kann Servicequalität nicht allein erzeugen.

Incident Management zeigt, wie sich Störungen auf Serviceziele auswirken.

Problem Management verhindert, dass dieselben SLA-Verletzungen ständig wiederkehren.

Change Enablement setzt Serviceverbesserungen kontrolliert um.

Configuration Management zeigt, wovon ein Service tatsächlich abhängig ist.

Knowledge Management verkürzt Diagnose- und Wiederherstellungszeiten.

Interne Serviceziele müssen durch Teams und Lieferanten unterstützt werden.

Monitoring muss nutzbare Servicefunktionen und nicht nur einzelne Systeme messen.

Ein erreichtes SLA bedeutet nicht automatisch, dass ein Service dauerhaft gesund ist.

Verbesserungen sind erst abgeschlossen, wenn ihre Wirkung gemessen wurde.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

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

9. Service Request Management

9. Service Request Management

9.1 Ziele und Grundlagen des Service Request Management

Kurz erklärt

Service Request Management beschäftigt sich mit der strukturierten Bearbeitung von Service Requests.

Ein Service Request ist keine Störung.

Stattdessen handelt es sich um eine geplante, standardisierte und vom Benutzer angeforderte Serviceleistung.

Ziel ist es, Anfragen schnell, nachvollziehbar, möglichst automatisiert und mit gleichbleibender Qualität bereitzustellen.

Was ist Service Request Management?

Service Request Management ist eine ITIL Practice zur Bearbeitung von standardisierten Benutzeranfragen.

Dabei geht es nicht um die Behebung eines Fehlers, sondern um die Bereitstellung einer gewünschten Leistung.

Typische Beispiele:

Alle diese Vorgänge können geplant und standardisiert abgewickelt werden.

Was ist ein Service Request?

Ein Service Request ist eine formelle Anfrage eines Benutzers oder einer autorisierten Person nach einer definierten Serviceleistung.

Ein Service Request kann sich beispielsweise beziehen auf:

Wichtig:

Ein Service Request ist keine Störung.

Es funktioniert nichts falsch.

Der Benutzer benötigt lediglich eine Leistung der IT.

Ziele des Service Request Management

Die wichtigsten Ziele sind:

Je standardisierter ein Request ist, desto einfacher kann er automatisiert werden.

Warum Service Requests wichtig sind

In vielen Unternehmen bestehen die meisten Tickets nicht aus Incidents.

Stattdessen entstehen täglich zahlreiche Standardanfragen.

Beispiele:

Würde jede Anfrage individuell bearbeitet, entstünde unnötiger Aufwand.

Standardisierte Abläufe sorgen für:

Incident oder Service Request?

Diese beiden Begriffe werden häufig verwechselt.

Incident Service Request
ungeplante Störung geplante Anfrage
Service funktioniert nicht wie erwartet Benutzer wünscht eine Leistung
Ziel ist Wiederherstellung Ziel ist Bereitstellung
häufig hoher Zeitdruck meist planbare Bearbeitung
kann Major Incident werden wird normalerweise nicht eskaliert

Beispiele für Incidents

Alle diese Fälle beschreiben eine Störung.

Beispiele für Service Requests

Hier funktioniert nichts falsch.

Der Benutzer benötigt lediglich eine zusätzliche Leistung.

Typische Kategorien von Service Requests

Service Requests lassen sich beispielsweise einteilen in:

Eine sinnvolle Kategorisierung erleichtert Automatisierung und Auswertung.

Warum Standardisierung wichtig ist

Je ähnlicher Requests bearbeitet werden,

desto einfacher lassen sie sich:

Standardisierung sorgt außerdem dafür,

dass verschiedene Mitarbeiter zum gleichen Ergebnis gelangen.

Service Request oder Change?

Nicht jeder Service Request ist gleichzeitig ein Change.

Beispiel:

Ein Benutzer beantragt Microsoft Office.

Die Installation erfolgt nach einem freigegebenen Standardverfahren.

Für den Benutzer handelt es sich um einen Service Request.

Im Hintergrund kann die Bereitstellung über einen bereits genehmigten Standard Change erfolgen.

Service Request oder Incident?

Ein Benutzer meldet:

"Ich kann Outlook nicht öffnen."

→ Incident

Ein Benutzer meldet:

"Bitte installieren Sie Outlook auf meinem neuen Notebook."

→ Service Request

Der Unterschied liegt nicht im Programm,

sondern im Ziel der Anfrage.

Wer darf Service Requests stellen?

Je nach Organisation können Requests gestellt werden von:

Häufig gelten dabei Berechtigungen.

Nicht jeder Benutzer darf jede Leistung anfordern.

Serviceportal als Einstieg

Viele Unternehmen verwenden ein zentrales Serviceportal.

Dort können Benutzer:

Dadurch sinkt die Anzahl telefonischer Anfragen erheblich.

Self-Service und Service Requests

Viele Requests eignen sich hervorragend für Self-Service.

Beispiele:

Dadurch können Benutzer viele Aufgaben selbst durchführen.

Typischer Ablauf eines Service Requests

Benutzer
      │
      ▼
Request stellen
      │
      ▼
Prüfung
      │
      ▼
Genehmigung (falls notwendig)
      │
      ▼
Bearbeitung
      │
      ▼
Bereitstellung
      │
      ▼
Benutzer informiert
      │
      ▼
Request schließen

Nicht jeder Request benötigt eine Genehmigung.

Request oder Information?

Auch reine Informationsanfragen können Service Requests sein.

Beispiele:

Oft genügt hierbei bereits ein passender Knowledge-Artikel.

Priorität bei Service Requests

Service Requests besitzen ebenfalls Prioritäten.

Diese unterscheiden sich jedoch häufig von Incident-Prioritäten.

Beispiel:

Ein neues Notebook kann durchaus wichtig sein,

stellt aber normalerweise keinen Incident dar.

Prioritäten orientieren sich häufig an:

Servicequalität

Auch für Service Requests können Ziele definiert werden.

Beispiele:

Diese Ziele können Bestandteil eines SLA oder Servicekatalogs sein.

Dokumentation

Jeder Request sollte nachvollziehbar dokumentiert werden.

Mindestens:

Eine gute Dokumentation erleichtert spätere Auswertungen.

Automatisierung

Viele Service Requests lassen sich vollständig automatisieren.

Beispiele:

Automatisierung reduziert:

Vorteile des Service Request Management

Für Benutzer:

Für die IT:

Praxisbeispiel

Ein Mitarbeiter beginnt nächste Woche im Unternehmen.

Benötigt werden:

Anstatt sechs einzelne Tickets manuell zu bearbeiten,

existiert ein standardisierter Onboarding-Request.

Alle notwendigen Aufgaben werden automatisch angestoßen.

Dadurch sinkt der Bearbeitungsaufwand erheblich.

Typische Fehler

Fehler 1

Incidents werden als Service Requests erfasst.

Fehler 2

Service Requests werden unnötig individuell bearbeitet.

Fehler 3

Es existieren keine Standardabläufe.

Fehler 4

Genehmigungen fehlen oder erfolgen zu spät.

Fehler 5

Benutzer kennen das Serviceportal nicht.

Fehler 6

Statusinformationen fehlen.

Fehler 7

Standardleistungen werden nicht automatisiert.

Fehler 8

Dokumentation ist unvollständig.

Checkliste Service Request

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker bearbeiten im Arbeitsalltag häufig mehr Service Requests als Incidents.

Typische Aufgaben sind:

Je besser Service Requests standardisiert sind,

desto mehr Zeit bleibt für komplexe technische Aufgaben.

Zusammenfassung

Benutzer benötigt eine definierte Leistung

↓

Service Request erfassen

↓

Kategorie bestimmen

↓

Genehmigung prüfen

↓

Standardverfahren anwenden

↓

Leistung bereitstellen

↓

Benutzer informieren

↓

Request dokumentieren und schließen

Merksätze

Ein Service Request ist keine Störung.

Service Requests beschreiben standardisierte Leistungen.

Standardisierung ist die Grundlage für Automatisierung.

Gute Serviceportale entlasten den Service Desk.

Service Request Management erhöht Servicequalität und Benutzerzufriedenheit.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Beispiele, Kategorien, Abläufe und Empfehlungen sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine einheitlichen Request-Kategorien oder Genehmigungsabläufe vor. Die konkrete Umsetzung richtet sich nach den angebotenen Services, der Organisationsstruktur und den Geschäftsanforderungen.

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

9. Service Request Management

9.2 Request Model und Standard Requests

Kurz erklärt

Wiederkehrende Service Requests sollten nicht jedes Mal neu geplant werden.

Stattdessen werden sie mithilfe von Request Models standardisiert.

Ein Request Model beschreibt den vollständigen Ablauf eines bestimmten Service Requests – von der Anforderung über Genehmigungen bis zur Bereitstellung und Dokumentation.

Dadurch werden Bearbeitungszeiten verkürzt, Fehler reduziert und Automatisierungen ermöglicht.

Was ist ein Request Model?

Ein Request Model ist eine dokumentierte Vorlage für einen wiederkehrenden Service Request.

Es beschreibt:

Jeder gleichartige Request wird möglichst nach demselben Modell bearbeitet.

Ziele eines Request Models

Ein Request Model soll:

Warum Request Models wichtig sind

Ohne festgelegte Abläufe entscheidet jeder Bearbeiter unterschiedlich.

Dadurch entstehen häufig:

Ein Request Model sorgt dafür, dass alle Beteiligten nach denselben Regeln arbeiten.

Bestandteile eines Request Models

Ein vollständiges Request Model enthält typischerweise:

Je komplexer ein Request ist, desto ausführlicher sollte das Modell sein.

Beispiel: Softwareinstallation

Ein mögliches Request Model:

Software beantragen
        │
        ▼
Lizenz prüfen
        │
        ▼
Genehmigung Vorgesetzter
        │
        ▼
Software automatisch verteilen
        │
        ▼
Installation prüfen
        │
        ▼
Benutzer informieren
        │
        ▼
Request schließen

Der Ablauf bleibt für alle gleich.

Was sind Standard Requests?

Ein Standard Request ist ein häufig wiederkehrender Service Request mit einem definierten Ablauf.

Typische Beispiele:

Für Standard Requests existiert normalerweise bereits ein Request Model.

Eigenschaften eines Standard Requests

Ein Standard Request ist:

Dadurch kann die Bearbeitung weitgehend unabhängig vom Bearbeiter erfolgen.

Nicht jeder Request ist ein Standard Request

Einige Anforderungen sind individuell.

Beispiele:

Solche Anforderungen benötigen häufig eine individuelle Planung.

Request Models und Servicekatalog

Ein Servicekatalog beschreibt,

welche Leistungen angeboten werden.

Ein Request Model beschreibt,

wie eine bestimmte Leistung erbracht wird.

Beispiel:

Servicekatalog:

Microsoft 365

Request Model:

Microsoft-365-Lizenz für neuen Mitarbeiter bereitstellen.

Informationen des Benutzers

Ein gutes Request Model legt fest,

welche Informationen der Benutzer angeben muss.

Beispiele:

Fehlende Informationen führen häufig zu Verzögerungen.

Pflicht- und optionale Angaben

Nicht alle Informationen sind immer erforderlich.

Beispiel:

Pflichtfelder:

Optionale Angaben:

Dadurch bleiben Formulare übersichtlich.

Genehmigungen im Request Model

Viele Standard Requests benötigen Genehmigungen.

Beispiele:

Das Request Model definiert eindeutig,

wann welche Genehmigung erforderlich ist.

Genehmigungsfreie Requests

Nicht jeder Request benötigt eine Freigabe.

Beispiele:

Dadurch sinkt der Bearbeitungsaufwand erheblich.

Bearbeitungsschritte definieren

Ein Request Model beschreibt jeden Bearbeitungsschritt.

Beispiel:

Jeder Bearbeiter kennt dadurch den vollständigen Ablauf.

Verantwortlichkeiten

Für jeden Schritt sollte klar sein,

wer verantwortlich ist.

Beispiele:

Aufgabe Verantwortlich
Request prüfen Service Desk
Genehmigung Vorgesetzter
Lizenzverwaltung Lizenzmanagement
Softwareverteilung Client Management
Abschluss Service Desk

Dadurch entstehen keine unklaren Zuständigkeiten.

Automatisierung

Viele Schritte können automatisiert werden.

Beispiele:

Automatisierung reduziert manuelle Tätigkeiten erheblich.

Kommunikation

Auch die Kommunikation sollte standardisiert werden.

Beispiele:

Benutzer kennen dadurch jederzeit den aktuellen Stand.

Bearbeitungszeiten

Für Standard Requests können Zielzeiten definiert werden.

Beispiele:

Request Zielzeit
Passwort zurücksetzen 15 Minuten
Softwareinstallation 1 Arbeitstag
Benutzerkonto 4 Stunden
Monitor bestellen 3 Arbeitstage
VPN-Zugang 1 Arbeitstag

Diese Zeiten dienen als Orientierung für Servicequalität und Planung.

Request Models regelmäßig überprüfen

Ein Request Model sollte regelmäßig überprüft werden.

Mögliche Fragen:

Ein veraltetes Request Model führt schnell zu Fehlern.

Versionierung

Änderungen an Request Models sollten nachvollziehbar sein.

Dokumentiert werden können:

Dadurch bleibt nachvollziehbar,

welcher Ablauf aktuell gültig ist.

Praxisbeispiel

Ein neuer Mitarbeiter beginnt am Montag.

Der Service Request:

"Neuer Mitarbeiter"

startet automatisch:

Jede Aufgabe wird automatisch an das zuständige Team weitergeleitet.

Der gesamte Ablauf basiert auf einem einzigen Request Model.

Typische Fehler

Fehler 1

Für häufige Requests existiert kein Request Model.

Fehler 2

Bearbeiter arbeiten nach unterschiedlichen Abläufen.

Fehler 3

Genehmigungen sind nicht eindeutig geregelt.

Fehler 4

Zu viele unnötige Pflichtfelder.

Fehler 5

Bearbeitungsschritte sind unvollständig dokumentiert.

Fehler 6

Automatisierungen werden nicht genutzt.

Fehler 7

Verantwortlichkeiten sind unklar.

Fehler 8

Veraltete Request Models werden weiterhin verwendet.

Checkliste Request Model

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten täglich mit Request Models.

Typische Aufgaben:

Gut gepflegte Request Models sparen im Arbeitsalltag erhebliche Zeit und sorgen für eine gleichbleibend hohe Servicequalität.

Zusammenfassung

Wiederkehrenden Request identifizieren

↓

Request Model erstellen

↓

Informationen und Genehmigungen festlegen

↓

Bearbeitung standardisieren

↓

Automatisierung nutzen

↓

Leistung bereitstellen

↓

Benutzer informieren

↓

Request dokumentieren und abschließen

Merksätze

Standard Requests sollten immer nach einem Request Model bearbeitet werden.

Ein Request Model beschreibt den gesamten Bearbeitungsablauf.

Standardisierung ermöglicht Automatisierung.

Gute Request Models reduzieren Fehler und Bearbeitungszeit.

Klare Verantwortlichkeiten verbessern die Servicequalität.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Request Models, Bearbeitungsschritte, Zielzeiten und Beispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine festen Request Models oder Standardabläufe vor. Organisationen entwickeln diese entsprechend ihrer Services, Sicherheitsanforderungen und Geschäftsprozesse.

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

9. Service Request Management

9.3 Genehmigungen und Freigabeverfahren

Kurz erklärt

Nicht jeder Service Request darf sofort ausgeführt werden.

Viele Leistungen verursachen Kosten, verändern Berechtigungen oder beeinflussen Sicherheit und Compliance.

Deshalb benötigen bestimmte Requests vor der Bearbeitung eine oder mehrere Genehmigungen.

Ziel ist es, Risiken zu reduzieren, Verantwortlichkeiten eindeutig festzulegen und gleichzeitig unnötige Wartezeiten zu vermeiden.

Warum Genehmigungen notwendig sind

Genehmigungen stellen sicher, dass eine angeforderte Leistung berechtigt, sinnvoll und zulässig ist.

Sie helfen dabei:

Eine Genehmigung bedeutet dabei nicht automatisch eine lange Bearbeitungszeit.

Gut definierte Standardprozesse können Genehmigungen weitgehend automatisieren.

Was ist eine Genehmigung?

Eine Genehmigung ist die formelle Zustimmung einer berechtigten Person oder Stelle zur Durchführung eines Service Requests.

Die Genehmigung bestätigt beispielsweise:

Erst danach beginnt – sofern erforderlich – die eigentliche Bearbeitung.

Nicht jeder Request benötigt eine Genehmigung

Viele Standardleistungen können ohne zusätzliche Freigabe bereitgestellt werden.

Beispiele:

Hier würde eine zusätzliche Genehmigung lediglich den Prozess unnötig verzögern.

Wann Genehmigungen sinnvoll sind

Eine Genehmigung ist häufig erforderlich bei:

Je höher Risiko oder Kosten, desto wichtiger wird eine Freigabe.

Typische Genehmigungsstellen

Je nach Organisation können unterschiedliche Stellen beteiligt sein.

Beispiele:

Anfrage Genehmigung
Notebook Vorgesetzter
Softwarelizenz Lizenzmanagement
Administratorrechte Informationssicherheit
SAP-Berechtigung Fachbereich
Cloud-Ressourcen Kostenstellenverantwortlicher
VPN-Zugang Vorgesetzter oder IT-Sicherheit
Mobiltelefon Einkauf oder Kostenstelle

Die zuständige Stelle sollte im Request Model eindeutig definiert sein.

Einfacher Genehmigungsprozess

Ein typischer Ablauf:

Benutzer stellt Request
          │
          ▼
Genehmigung erforderlich?
          │
     ┌────┴────┐
     │         │
    Nein      Ja
     │         │
     ▼         ▼
Bearbeitung   Genehmigung
     │         │
     └────┬────┘
          ▼
Bereitstellung
          │
          ▼
Request schließen

Nicht jeder Request durchläuft denselben Ablauf.

Mehrstufige Genehmigungen

Komplexere Requests können mehrere Freigaben benötigen.

Beispiel:

Ein Administratorzugang wird beantragt.

Mögliche Reihenfolge:

  1. Vorgesetzter
  2. Informationssicherheit
  3. Systemverantwortlicher

Erst nach allen Genehmigungen beginnt die technische Umsetzung.

Parallele Genehmigungen

Nicht alle Freigaben müssen nacheinander erfolgen.

Sind Genehmigungen unabhängig voneinander, können sie parallel eingeholt werden.

Vorteile:

Dies wird von vielen ITSM-Systemen unterstützt.

Genehmigungsregeln

Ein Request Model sollte eindeutig festlegen:

Klare Regeln vermeiden Rückfragen und Verzögerungen.

Genehmigung ist keine technische Prüfung

Die Genehmigung beantwortet in erster Linie organisatorische Fragen.

Beispiele:

Die technische Umsetzung erfolgt anschließend durch die zuständigen IT-Teams.

Ablehnung eines Requests

Nicht jeder Request wird genehmigt.

Mögliche Gründe:

Eine Ablehnung sollte dokumentiert und nachvollziehbar begründet werden.

Vertretungsregelungen

Genehmigungen dürfen nicht von einzelnen Personen abhängig sein.

Deshalb sollten Vertretungen definiert werden.

Beispiele:

Fehlende Vertretungen führen häufig zu langen Bearbeitungszeiten.

Fristen für Genehmigungen

Viele Organisationen definieren Zielzeiten.

Beispiele:

Genehmigung Zielzeit
Vorgesetzter 1 Arbeitstag
Lizenzmanagement 4 Stunden
Informationssicherheit 2 Arbeitstage
Einkauf 3 Arbeitstage

Werden Fristen überschritten, kann eine Erinnerung oder Eskalation erfolgen.

Automatische Genehmigungen

Einige Requests können automatisch genehmigt werden.

Beispiele:

Voraussetzung ist, dass alle Regeln bereits definiert wurden.

Bedingte Genehmigungen

Manche Genehmigungen hängen von Bedingungen ab.

Beispiele:

Sind die Bedingungen nicht erfüllt, entfällt die zusätzliche Freigabe.

Genehmigungen dokumentieren

Jede Genehmigung sollte nachvollziehbar gespeichert werden.

Typische Informationen:

Dadurch bleibt später nachvollziehbar, warum eine Leistung bereitgestellt wurde.

Genehmigungen und Compliance

Viele gesetzliche oder interne Vorgaben verlangen dokumentierte Genehmigungen.

Beispiele:

Eine fehlende Dokumentation kann später zu Problemen bei Audits führen.

Genehmigungen und Least Privilege

Das Prinzip der minimalen Berechtigung spielt eine wichtige Rolle.

Benutzer sollen nur die Rechte erhalten,

die sie tatsächlich benötigen.

Deshalb benötigen insbesondere folgende Requests häufig zusätzliche Genehmigungen:

Temporäre Berechtigungen

Nicht jede Berechtigung muss dauerhaft vergeben werden.

Beispiele:

Nach Ablauf sollte die Berechtigung automatisch entzogen werden.

Genehmigungen regelmäßig überprüfen

Genehmigungsprozesse sollten regelmäßig bewertet werden.

Fragen dabei:

Ein effizienter Prozess schützt die Organisation, ohne die Benutzer unnötig auszubremsen.

Praxisbeispiel

Ein Entwickler benötigt Administratorrechte auf seinem Notebook.

Der Ablauf:

  1. Entwickler stellt Request.
  2. Vorgesetzter bestätigt die Notwendigkeit.
  3. Informationssicherheit prüft das Risiko.
  4. IT vergibt die Berechtigung.
  5. Die Rechte gelten nur für zwei Wochen.
  6. Nach Ablauf werden sie automatisch entfernt.

So bleiben Sicherheit und Nachvollziehbarkeit gewährleistet.

Typische Fehler

Fehler 1

Jeder Request benötigt dieselben Genehmigungen.

Fehler 2

Genehmigungen sind nicht dokumentiert.

Fehler 3

Vertretungen fehlen.

Fehler 4

Genehmigungen verzögern Standardleistungen unnötig.

Fehler 5

Ablehnungen werden nicht begründet.

Fehler 6

Administratorrechte werden dauerhaft vergeben.

Fehler 7

Genehmigungsregeln sind unklar.

Fehler 8

Abgelaufene Berechtigungen werden nicht entfernt.

Fehler 9

Genehmigungen erfolgen außerhalb des ITSM-Systems und sind später nicht nachvollziehbar.

Fehler 10

Genehmigungsprozesse werden nie überprüft oder verbessert.

Checkliste Genehmigungen

Checkliste Berechtigungs-Requests

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker setzen viele genehmigte Service Requests technisch um.

Typische Aufgaben:

Dabei müssen technische Umsetzung und dokumentierte Genehmigung immer zusammenpassen.

Zusammenfassung

Benutzer stellt Request

↓

Genehmigung erforderlich?

↓

Genehmiger prüfen Anfrage

↓

Freigabe oder Ablehnung

↓

Bereitstellung der Leistung

↓

Dokumentation

↓

Benutzer informieren

↓

Request abschließen

Merksätze

Nicht jeder Service Request benötigt eine Genehmigung.

Genehmigungen schützen Sicherheit, Budget und Compliance.

Standardleistungen sollten möglichst automatisiert freigegeben werden.

Administratorrechte sollten zeitlich begrenzt vergeben werden.

Genehmigungen müssen nachvollziehbar dokumentiert sein.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Genehmigungsprozesse, Beispiele und Rollen sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine festen Genehmigungsstufen oder Freigabeworkflows vor. Organisationen definieren diese anhand ihrer Sicherheitsrichtlinien, Compliance-Anforderungen und Geschäftsprozesse.

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

9. Service Request Management

9.4 Erfüllung, Automatisierung und Self-Service

Kurz erklärt

Ein zentrales Ziel des Service Request Management ist es, Service Requests möglichst schnell, zuverlässig und mit gleichbleibender Qualität zu erfüllen.

Dies wird durch standardisierte Abläufe, Self-Service-Portale und Automatisierungen erreicht.

Je weniger manuelle Tätigkeiten notwendig sind, desto schneller erhalten Benutzer die gewünschte Leistung und desto mehr Zeit bleibt der IT für komplexe Aufgaben.

Was bedeutet Request Fulfilment?

Request Fulfilment beschreibt die eigentliche Bearbeitung und Bereitstellung einer angeforderten Serviceleistung.

Nachdem alle notwendigen Informationen vorliegen und erforderliche Genehmigungen erfolgt sind, beginnt die Umsetzung.

Typische Tätigkeiten sind:

Ziel ist eine schnelle und fehlerfreie Bereitstellung.

Ziele der Request-Erfüllung

Eine gute Request-Erfüllung soll:

Die eigentliche Bearbeitung sollte möglichst keine improvisierten Einzelschritte enthalten.

Standardisierte Abläufe

Standardisierte Prozesse sorgen dafür, dass identische Requests immer gleich bearbeitet werden.

Beispiele:

Dadurch sinken:

Automatisierung im Service Request Management

Viele wiederkehrende Aufgaben eignen sich hervorragend zur Automatisierung.

Beispiele:

Automatisierungen werden häufig über ITSM-Systeme, Identity-Management-Lösungen oder Workflow-Plattformen umgesetzt.

Vorteile der Automatisierung

Automatisierung bietet zahlreiche Vorteile:

Automatisierung ersetzt dabei nicht die Verantwortung für den Prozess.

Grenzen der Automatisierung

Nicht jeder Request kann vollständig automatisiert werden.

Beispiele:

Hier bleibt eine manuelle Prüfung erforderlich.

Self-Service

Beim Self-Service führt der Benutzer bestimmte Aufgaben selbst durch.

Die IT stellt dafür geeignete Werkzeuge bereit.

Beispiele:

Dadurch werden Service Desk und Fachabteilungen entlastet.

Self-Service ist mehr als ein Formular

Ein modernes Self-Service-Portal bietet häufig:

Der Benutzer soll möglichst viele Aufgaben selbst erledigen können.

Der Servicekatalog

Der Servicekatalog bildet die Grundlage vieler Self-Service-Portale.

Er beschreibt:

Benutzer sollen ohne technisches Detailwissen erkennen können, welche Leistung sie benötigen.

Benutzerfreundliche Formulare

Ein gutes Formular ist:

Nur notwendige Informationen sollten abgefragt werden.

Zu viele Pflichtfelder führen häufig zu Abbrüchen.

Dynamische Formulare

Viele ITSM-Systeme unterstützen dynamische Formulare.

Beispiel:

Wählt der Benutzer:

"Notebook"

erscheinen automatisch weitere Felder:

Wählt der Benutzer:

"Software"

erscheinen stattdessen:

Dadurch bleiben Formulare übersichtlich.

Workflow-Automatisierung

Ein Workflow steuert den gesamten Ablauf eines Requests.

Beispiel:

Request
    │
    ▼
Genehmigung
    │
    ▼
Benutzerkonto
    │
    ▼
Gruppenmitgliedschaft
    │
    ▼
Softwareinstallation
    │
    ▼
Benutzer informieren
    │
    ▼
Request schließen

Jeder Schritt wird automatisch an die nächste zuständige Stelle übergeben.

Automatische Benachrichtigungen

Während der Bearbeitung können automatisch Nachrichten versendet werden.

Beispiele:

Dadurch muss der Benutzer nicht ständig nachfragen.

Identity Management

Viele Benutzer-Requests betreffen Identitäten und Berechtigungen.

Identity-Management-Systeme können beispielsweise:

Dadurch lassen sich viele Standard-Requests vollständig automatisieren.

Zero-Touch Provisioning

Bei standardisierten Arbeitsplätzen kann die Bereitstellung nahezu vollständig automatisiert erfolgen.

Beispiel:

Ein neuer Mitarbeiter wird im HR-System angelegt.

Automatisch entstehen:

Die IT muss nur noch kontrollieren oder ausliefern.

Automatisierung mit Workflows

Workflow-Systeme können verschiedene Werkzeuge miteinander verbinden.

Beispiele:

Ein einziger Request kann dadurch zahlreiche Systeme automatisch steuern.

Fehlerbehandlung

Auch automatisierte Prozesse benötigen Fehlerbehandlung.

Mögliche Situationen:

In solchen Fällen sollte der Workflow kontrolliert anhalten und den zuständigen Bearbeiter informieren.

Rollback

Automatisierungen sollten möglichst rückgängig gemacht werden können.

Beispiele:

Dadurch lassen sich Fehler einfacher korrigieren.

Protokollierung

Jede automatische Bearbeitung sollte nachvollziehbar sein.

Typische Informationen:

Eine vollständige Protokollierung erleichtert Fehleranalyse und Audits.

Überwachung automatisierter Prozesse

Automatisierungen müssen überwacht werden.

Beispiele:

Nicht erkannte Fehler können dazu führen, dass Requests unvollständig bearbeitet werden.

Self-Service und Knowledge Base

Viele Requests lassen sich bereits durch passende Informationen lösen.

Beispiele:

Findet der Benutzer die Lösung selbst, muss kein Ticket erstellt werden.

Chatbots und virtuelle Assistenten

Viele Serviceportale integrieren Chatbots.

Sie können:

Komplexe Anfragen werden bei Bedarf an den Service Desk weitergeleitet.

Messung der Servicequalität

Auch Self-Service und Automatisierung sollten gemessen werden.

Beispiele:

Diese Kennzahlen helfen, den Service kontinuierlich zu verbessern.

Praxisbeispiel

Ein neuer Mitarbeiter wird eingestellt.

Der Vorgesetzte startet im Self-Service-Portal den Request:

Neuer Mitarbeiter

Automatisch werden:

Der Service Desk muss den Ablauf lediglich überwachen.

Typische Fehler

Fehler 1

Standard-Requests werden weiterhin vollständig manuell bearbeitet.

Fehler 2

Self-Service-Portale sind unübersichtlich.

Fehler 3

Automatisierungen besitzen keine Fehlerbehandlung.

Fehler 4

Genehmigungen werden nicht automatisch berücksichtigt.

Fehler 5

Benutzer erhalten keine Statusinformationen.

Fehler 6

Workflows werden nicht überwacht.

Fehler 7

Rollback-Möglichkeiten fehlen.

Fehler 8

Knowledge-Artikel sind veraltet.

Fehler 9

Zu viele unnötige Formularfelder erschweren die Nutzung.

Fehler 10

Automatisierungen werden nach Änderungen nicht getestet.

Checkliste Self-Service

Checkliste Automatisierung

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker entwickeln, betreiben und überwachen häufig automatisierte Serviceprozesse.

Typische Aufgaben:

Gut geplante Automatisierungen reduzieren Routinearbeiten erheblich und erhöhen gleichzeitig die Servicequalität.

Zusammenfassung

Benutzer stellt Service Request

↓

Self-Service oder Service Desk

↓

Genehmigungen prüfen

↓

Workflow starten

↓

Automatisierte Bereitstellung

↓

Benutzer informieren

↓

Protokollieren

↓

Request abschließen

Merksätze

Standardisierte Requests eignen sich besonders für Automatisierung.

Self-Service entlastet den Service Desk.

Automatisierung benötigt Monitoring und Fehlerbehandlung.

Gute Workflows verkürzen Bearbeitungszeiten erheblich.

Jede Automatisierung muss nachvollziehbar dokumentiert werden.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Beispiele, Workflows, Self-Service-Funktionen und Automatisierungen sind herstellerneutrale Praxisempfehlungen. ITIL schreibt weder bestimmte Portale noch konkrete Automatisierungsplattformen vor. Die technische Umsetzung hängt von den eingesetzten ITSM-, Identity-Management- und Workflow-Systemen der jeweiligen Organisation ab.

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

9. Service Request Management

9.5 Zusammenspiel mit Incident, Change, Knowledge und Service Level Management

Kurz erklärt

Service Request Management arbeitet nicht isoliert.

Es steht in engem Zusammenhang mit anderen ITIL Practices.

Erst das Zusammenspiel mit Incident Management, Change Enablement, Knowledge Management, Service Level Management, Information Security Management und Continual Improvement ermöglicht eine schnelle, sichere und qualitativ hochwertige Bearbeitung von Service Requests.

Jede Practice liefert Informationen oder Leistungen, die den gesamten Request-Prozess unterstützen.

Warum das Zusammenspiel wichtig ist

Ein Service Request besteht selten nur aus einer einzelnen Tätigkeit.

Beispiel:

Ein neuer Mitarbeiter benötigt:

Für die Bereitstellung arbeiten häufig mehrere Teams und Practices zusammen.

Das Service Request Management koordiniert dabei den gesamten Ablauf.

Zusammenspiel der Practices

Service Request
        │
        ▼
Genehmigungen
        │
        ▼
Knowledge nutzen
        │
        ▼
Incident vermeiden
        │
        ▼
Changes ausführen
        │
        ▼
Service bereitstellen
        │
        ▼
Servicequalität messen
        │
        ▼
Verbesserungen umsetzen

Die Practices arbeiten parallel und ergänzen sich gegenseitig.

Service Request Management und Incident Management

Diese beiden Practices werden häufig verwechselt.

Der wichtigste Unterschied:

Incident Management Service Request Management
Störung beheben Service bereitstellen
ungeplantes Ereignis geplante Anfrage
Ziel: Wiederherstellung Ziel: Erfüllung einer Anforderung
häufig hoher Zeitdruck planbare Bearbeitung

Trotzdem arbeiten beide eng zusammen.

Wenn ein Incident zum Request wird

Manchmal stellt sich während der Bearbeitung heraus,

dass gar keine Störung vorliegt.

Beispiel:

Benutzer meldet:

"Ich kann Photoshop nicht benutzen."

Analyse:

Photoshop wurde nie installiert.

Es liegt keine Störung vor.

Der Incident wird geschlossen.

Anschließend wird ein Service Request für die Softwareinstallation erstellt.

Wenn ein Request zum Incident wird

Auch das Gegenteil ist möglich.

Beispiel:

Ein Benutzer beantragt VPN.

Während der Bereitstellung fällt auf:

Der VPN-Gateway ist ausgefallen.

Jetzt liegt zusätzlich ein Incident vor.

Der Service Request bleibt bestehen,

die technische Störung wird jedoch separat als Incident bearbeitet.

Parallele Bearbeitung

Ein Service Request und ein Incident können gleichzeitig existieren.

Beispiel:

Beide Vorgänge besitzen unterschiedliche Ziele,

können sich jedoch gegenseitig beeinflussen.

Verknüpfung von Tickets

Viele ITSM-Systeme ermöglichen Verknüpfungen.

Beispiel:

Service Request
       │
       ├──────── Incident
       │
       ├──────── Change
       │
       ├──────── Knowledge Article
       │
       └──────── Configuration Item

Dadurch bleiben Zusammenhänge nachvollziehbar.

Service Request Management und Change Enablement

Viele Requests führen zu Änderungen an der IT-Umgebung.

Beispiele:

Nicht jede dieser Änderungen benötigt jedoch einen eigenen Change.

Standard Changes

Viele Service Requests werden über bereits genehmigte Standard Changes umgesetzt.

Beispiele:

Der Benutzer bemerkt davon häufig nichts.

Für ihn bleibt es ein Service Request.

Normale Changes

Größere Anforderungen können zusätzlich einen normalen Change benötigen.

Beispiel:

Ein Fachbereich benötigt eine neue Unternehmenssoftware.

Der Service Request startet den Prozess.

Die technische Einführung erfolgt anschließend kontrolliert über Change Enablement.

Service Request Management und Knowledge Management

Knowledge Management unterstützt Service Requests in nahezu jeder Phase.

Beispiele:

Je besser die Wissensbasis,

desto schneller erfolgt die Bearbeitung.

Knowledge vor Ticket

Idealerweise prüft der Benutzer bereits vor der Ticketerstellung,

ob ein passender Knowledge-Artikel existiert.

Beispiele:

Dadurch werden viele Requests vollständig vermieden.

Neue Knowledge-Artikel

Auch Service Requests können neue Dokumentationen erzeugen.

Beispiele:

Wissen sollte kontinuierlich erweitert werden.

Runbooks

Viele Standard Requests besitzen ein Runbook.

Ein Runbook beschreibt:

Dadurch arbeiten alle Bearbeiter nach demselben Verfahren.

Service Request Management und Service Level Management

Auch Service Requests besitzen häufig Serviceziele.

Beispiele:

Service Level Management überwacht,

ob diese Ziele erreicht werden.

Kennzahlen

Typische Kennzahlen:

Diese Kennzahlen helfen bei Verbesserungen.

Service Request Management und Information Security Management

Viele Requests betreffen Sicherheitsaspekte.

Beispiele:

Information Security Management definiert häufig die notwendigen Anforderungen.

Least Privilege

Service Requests sollten möglichst nach dem Prinzip der geringsten Berechtigung umgesetzt werden.

Benutzer erhalten nur die Rechte,

die sie tatsächlich benötigen.

Dadurch sinkt das Sicherheitsrisiko.

Rezertifizierung

Manche Berechtigungen werden regelmäßig überprüft.

Beispiele:

Nicht mehr benötigte Berechtigungen werden entfernt.

Service Request Management und Service Configuration Management

Viele Requests verändern Configuration Items.

Beispiele:

Nach der Bereitstellung sollten die entsprechenden Configuration-Daten aktualisiert werden.

Warum Configuration-Daten wichtig sind

Nur aktuelle Daten ermöglichen:

Service Requests verändern häufig genau diese Informationen.

Service Request Management und Supplier Management

Externe Lieferanten können an der Bearbeitung beteiligt sein.

Beispiele:

Lieferzeiten externer Partner beeinflussen häufig die gesamte Bearbeitungsdauer.

Service Request Management und Continual Improvement

Jeder Request liefert Verbesserungspotenzial.

Beispiele:

Diese Erkenntnisse fließen in Continual Improvement ein.

Verbesserungsmöglichkeiten

Typische Maßnahmen:

Kleine Verbesserungen können große Wirkung entfalten.

Zusammenspiel im Onboarding

Ein Beispiel:

Neuer Mitarbeiter
        │
        ▼
Service Request
        │
        ▼
Genehmigungen
        │
        ▼
Benutzerkonto
        │
        ▼
Microsoft 365
        │
        ▼
VPN
        │
        ▼
Notebook
        │
        ▼
CMDB aktualisieren
        │
        ▼
Benutzer informieren

Mehrere Practices arbeiten dabei gleichzeitig zusammen.

Praxisbeispiel

Ein neuer Mitarbeiter beginnt nächste Woche.

Der Request löst automatisch aus:

Währenddessen:

Der Benutzer erlebt einen einzigen zusammenhängenden Service.

Typische Fehler

Fehler 1

Incidents und Requests werden verwechselt.

Fehler 2

Service Requests aktualisieren keine Configuration-Daten.

Fehler 3

Knowledge wird nicht genutzt.

Fehler 4

Genehmigungen verzögern Standardleistungen.

Fehler 5

Automatisierungen fehlen.

Fehler 6

Serviceziele werden nicht gemessen.

Fehler 7

Information Security wird zu spät eingebunden.

Fehler 8

Bearbeitung erfolgt außerhalb des ITSM-Systems.

Fehler 9

Self-Service wird kaum genutzt.

Fehler 10

Verbesserungspotenziale werden nicht ausgewertet.

Checkliste Zusammenspiel

Checkliste Automatisierung

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten täglich an den Schnittstellen verschiedener ITIL Practices.

Im Arbeitsalltag bedeutet dies:

Erst das Zusammenspiel aller Practices ermöglicht einen professionellen und effizienten IT-Service.

Zusammenfassung

Benutzer stellt Service Request

↓

Knowledge und Self-Service unterstützen

↓

Genehmigungen prüfen

↓

Standard Change nutzen (falls erforderlich)

↓

Service bereitstellen

↓

Configuration aktualisieren

↓

Servicequalität messen

↓

Verbesserungen umsetzen

Merksätze

Service Request Management arbeitet niemals isoliert.

Incidents beheben Störungen – Service Requests stellen Leistungen bereit.

Knowledge und Automatisierung beschleunigen die Bearbeitung.

Configuration-Daten müssen nach der Bereitstellung aktuell sein.

Continual Improvement verbessert auch Service Requests kontinuierlich.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Zusammenhänge, Beispiele und Praxisempfehlungen orientieren sich an den ITIL-Practices. Die konkrete technische Umsetzung hängt von den eingesetzten ITSM-Systemen, Automatisierungsplattformen, Identity-Management-Lösungen und organisatorischen Prozessen der jeweiligen Organisation ab.

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

10. Monitoring and Event Management

10. Monitoring and Event Management

10.1 Ziele und Grundlagen des Monitoring and Event Management

Kurz erklärt

Monitoring and Event Management sorgt dafür, dass der Zustand von IT-Services und IT-Systemen kontinuierlich überwacht wird.

Ziel ist es, Abweichungen möglichst früh zu erkennen, bevor daraus Incidents oder Serviceunterbrechungen entstehen.

Ereignisse (Events) werden gesammelt, bewertet und – je nach Bedeutung – automatisch verarbeitet oder an die zuständigen Teams weitergeleitet.

Was ist Monitoring and Event Management?

Monitoring and Event Management ist eine ITIL Practice zur kontinuierlichen Überwachung von Services, Systemen und Infrastruktur.

Dabei werden Informationen über den aktuellen Zustand gesammelt und ausgewertet.

Beispiele:

Das Ziel besteht darin, Probleme möglichst frühzeitig zu erkennen.

Warum Monitoring wichtig ist

Ohne Monitoring werden viele Probleme erst bemerkt,

wenn Benutzer sie melden.

Dadurch entstehen:

Ein gutes Monitoring erkennt viele Probleme bereits,

bevor Benutzer betroffen sind.

Ziele des Monitoring and Event Management

Die wichtigsten Ziele sind:

Monitoring ersetzt dabei keine Fehlerbehebung.

Es liefert die notwendigen Informationen.

Monitoring und Event Management unterscheiden

Diese beiden Begriffe werden häufig gemeinsam verwendet,

beschreiben jedoch unterschiedliche Aufgaben.

Monitoring Event Management
sammelt Messwerte bewertet Ereignisse
überwacht Systeme entscheidet über Reaktionen
erkennt Veränderungen verarbeitet Events
liefert Daten löst Aktionen aus

Monitoring erzeugt Events.

Event Management verarbeitet diese.

Was ist ein Event?

Ein Event ist jede erkennbare Veränderung des Zustands eines Services oder Configuration Items.

Ein Event kann beispielsweise entstehen durch:

Nicht jedes Event bedeutet automatisch ein Problem.

Event ist nicht gleich Incident

Ein häufiger Irrtum:

Jedes Event ist ein Incident.

Das stimmt nicht.

Beispiel:

Ein Server startet nach einer geplanten Wartung neu.

Das Monitoring erzeugt ein Event.

Da die Änderung geplant war,

liegt kein Incident vor.

Beispiel eines echten Incidents

Das Monitoring erkennt:

Es existiert:

Jetzt entsteht aus dem Event möglicherweise ein Incident.

Informationsfluss

Monitoring
      │
      ▼
Event entsteht
      │
      ▼
Bewertung
      │
 ┌────┴────┐
 │         │
Normal   Reaktion
 │         │
 ▼         ▼
Protokoll Alarm oder Automation

Nicht jedes Event benötigt menschliches Eingreifen.

Arten von Monitoring

Typische Bereiche:

Je nach Service kommen unterschiedliche Überwachungen zum Einsatz.

Technisches Monitoring

Technisches Monitoring überwacht einzelne Komponenten.

Beispiele:

Es beantwortet die Frage:

Funktioniert das System technisch?

Service Monitoring

Service Monitoring betrachtet den Service aus Benutzersicht.

Beispiele:

Ein Server kann technisch erreichbar sein,

während der eigentliche Service bereits gestört ist.

Aktives Monitoring

Beim aktiven Monitoring werden Systeme regelmäßig geprüft.

Beispiele:

Die Prüfungen erfolgen automatisch in festgelegten Intervallen.

Passives Monitoring

Beim passiven Monitoring senden Systeme selbst Informationen.

Beispiele:

Hier wartet das Monitoring auf eintreffende Ereignisse.

Synthetisches Monitoring

Synthetisches Monitoring simuliert typische Benutzeraktionen.

Beispiele:

Dadurch wird geprüft,

ob ein Service tatsächlich nutzbar ist.

Real User Monitoring (RUM)

Beim Real User Monitoring werden echte Benutzeraktionen ausgewertet.

Beispiele:

Dadurch erhält die IT Informationen über die tatsächliche Benutzererfahrung.

Überwachungsobjekte

Monitoring kann sich beziehen auf:

Nicht jedes Objekt benötigt dieselbe Überwachung.

Grenzwerte (Thresholds)

Viele Überwachungen arbeiten mit Grenzwerten.

Beispiele:

Messwert Grenzwert
CPU über 90 %
RAM über 95 %
Festplatte über 85 % belegt
Zertifikat läuft in 30 Tagen ab
Backup fehlgeschlagen
Antwortzeit über 2 Sekunden

Grenzwerte sollten regelmäßig überprüft werden.

Frühwarnungen

Nicht jeder Alarm muss sofort kritisch sein.

Beispiel:

Festplatte:

Dadurch bleibt genügend Zeit,

Probleme zu beheben.

Alarmmüdigkeit (Alert Fatigue)

Zu viele unnötige Alarme führen dazu,

dass wichtige Warnungen übersehen werden.

Typische Ursachen:

Ein gutes Monitoring erzeugt möglichst wenige,

aber relevante Alarme.

Praxisbeispiel

Das Monitoring erkennt:

Es entsteht:

Das Zertifikat wird rechtzeitig erneuert.

Ein späterer Incident wird vermieden.

Typische Fehler

Fehler 1

Monitoring existiert nur für Server,

nicht für Services.

Fehler 2

Grenzwerte sind ungeeignet.

Fehler 3

Zu viele unnötige Alarme.

Fehler 4

Alarme werden nicht bearbeitet.

Fehler 5

Backups werden nicht überwacht.

Fehler 6

Zertifikate werden nicht überwacht.

Fehler 7

Monitoring erkennt Fehler erst nach Benutzerbeschwerden.

Fehler 8

Monitoring wird nach Änderungen nicht angepasst.

Checkliste Monitoring

Bedeutung für Fachinformatiker für Systemintegration

Monitoring gehört zu den täglichen Aufgaben vieler Fachinformatiker.

Typische Tätigkeiten:

Ein gut aufgebautes Monitoring verhindert viele Störungen, bevor Benutzer sie überhaupt bemerken.

Zusammenfassung

Systeme und Services überwachen

↓

Messwerte sammeln

↓

Event erzeugen

↓

Event bewerten

↓

Alarm oder Automatisierung

↓

Incident vermeiden oder bearbeiten

↓

Service stabil halten

Merksätze

Monitoring sammelt Informationen – Event Management bewertet sie.

Nicht jedes Event ist ein Incident.

Gutes Monitoring erkennt Probleme vor den Benutzern.

Service Monitoring ist wichtiger als reine Serverüberwachung.

Wenige aussagekräftige Alarme sind besser als viele unnötige Warnungen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Monitoring-Arten, Beispiele und Grenzwerte sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine konkreten Monitoring-Werkzeuge oder festen Schwellenwerte vor. Diese richten sich nach den überwachten Services, den Geschäftsanforderungen und der technischen Umgebung.

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

10. Monitoring and Event Management

10.2 Event-Typen, Filter und Priorisierung

Kurz erklärt

Ein Monitoring-System erzeugt täglich oft tausende oder sogar Millionen von Events.

Die Aufgabe des Event Managements besteht darin, diese Ereignisse zu bewerten, unwichtige Meldungen herauszufiltern und relevante Events an die richtigen Prozesse oder Personen weiterzuleiten.

Nur so können Störungen früh erkannt werden, ohne Administratoren mit unnötigen Meldungen zu überlasten.

Warum Event Management notwendig ist

Ein modernes Rechenzentrum erzeugt ständig Ereignisse.

Beispiele:

Ohne Bewertung wären diese Informationen kaum nutzbar.

Event Management entscheidet, welche Ereignisse wichtig sind.

Lebenszyklus eines Events

Ein typischer Ablauf:

Ereignis entsteht
        │
        ▼
Monitoring erkennt Event
        │
        ▼
Event klassifizieren
        │
        ▼
Filtern
        │
        ▼
Priorisieren
        │
        ▼
Aktion auslösen
        │
        ▼
Event protokollieren

Nicht jedes Event führt zu einer Aktion.

Kategorien von Events

ITIL unterscheidet grundsätzlich drei Event-Typen:

Event-Typ Bedeutung
Informational normale Information
Warning mögliche zukünftige Störung
Exception Fehler oder kritischer Zustand

Diese Einteilung hilft bei der automatischen Verarbeitung.

Informational Events

Informational Events dokumentieren normale Vorgänge.

Beispiele:

Diese Events dienen hauptsächlich der Dokumentation.

Normalerweise ist keine Reaktion erforderlich.

Warning Events

Warning Events weisen auf mögliche zukünftige Probleme hin.

Beispiele:

Noch besteht kein Incident.

Es sollte jedoch geprüft werden, ob Maßnahmen erforderlich sind.

Exception Events

Exception Events zeigen einen Fehler oder kritischen Zustand an.

Beispiele:

Diese Events führen häufig zu:

Warum nicht jedes Event gleich wichtig ist

Ein Drucker im Lager fällt aus.

Ein Domänencontroller fällt aus.

Beides sind Exception Events.

Die Auswirkungen unterscheiden sich jedoch erheblich.

Deshalb erfolgt zusätzlich eine Priorisierung.

Priorisierung von Events

Bei der Priorisierung werden unter anderem berücksichtigt:

Dadurch entstehen sinnvolle Reaktionen.

Beispiel

Zertifikat läuft in 30 Tagen ab.

→ Warning

Zertifikat heute abgelaufen.

→ Exception

Der Event-Typ ändert sich automatisch,

obwohl derselbe Sachverhalt überwacht wird.

Event-Filter

Nicht alle Events sollen angezeigt werden.

Filter unterdrücken beispielsweise:

Dadurch sinkt die Anzahl unnötiger Alarme.

Warum Filter wichtig sind

Ohne Filter entstehen häufig:

Ein gutes Monitoring meldet möglichst nur relevante Ereignisse.

Event-Korrelation

Mehrere Events können dieselbe Ursache besitzen.

Beispiel:

Ein Switch fällt aus.

Dadurch entstehen gleichzeitig:

Eine Event-Korrelation erkennt,

dass alle Meldungen wahrscheinlich dieselbe Ursache besitzen.

Dadurch entsteht nicht für jedes Event ein separates Incident-Ticket.

Deduplizierung

Viele Systeme melden denselben Fehler mehrfach.

Beispiel:

Alle 30 Sekunden:

Datenbank nicht erreichbar

Die Deduplizierung fasst identische Events zusammen.

Dadurch entsteht nur ein Alarm.

Unterdrückung (Suppression)

Bei geplanten Wartungen können bestimmte Events unterdrückt werden.

Beispiel:

Während eines genehmigten Changes:

Das Monitoring erkennt den Ausfall,

erzeugt jedoch keinen Incident,

da die Wartung bekannt ist.

Zeitliche Bewertung

Auch der Zeitpunkt spielt eine Rolle.

Beispiel:

CPU:

Nicht jede kurzfristige Spitze stellt ein Problem dar.

Abhängigkeiten berücksichtigen

Ein Service kann aus vielen Komponenten bestehen.

Fällt der Router aus,

melden gleichzeitig:

Fehler.

Die eigentliche Ursache bleibt jedoch der Router.

Deshalb sollten Abhängigkeiten im Monitoring berücksichtigt werden.

Business Impact

Nicht jedes technische Problem besitzt dieselbe geschäftliche Bedeutung.

Beispiele:

Testsystem nicht erreichbar.

→ geringer Business Impact.

Produktionssystem ausgefallen.

→ hoher Business Impact.

Event Management sollte diese Unterschiede berücksichtigen.

Automatische Reaktionen

Je nach Event können unterschiedliche Aktionen erfolgen.

Beispiele:

Informational:

Warning:

Exception:

Praxisbeispiel

Monitoring erkennt:

Festplatte:

84 %

→ Information.

85 %

→ Warning.

95 %

→ Exception.

98 %

→ automatischer Incident.

100 %

→ Notfallmaßnahmen.

Die Reaktion wird schrittweise intensiver.

Typische Fehler

Fehler 1

Alle Events besitzen dieselbe Priorität.

Fehler 2

Keine Event-Korrelation.

Fehler 3

Keine Filter vorhanden.

Fehler 4

Doppelte Events erzeugen mehrere Tickets.

Fehler 5

Warnungen werden ignoriert.

Fehler 6

Business Impact wird nicht berücksichtigt.

Fehler 7

Wartungen erzeugen unnötige Alarme.

Fehler 8

Grenzwerte werden nie überprüft.

Checkliste Event Management

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker konfigurieren häufig Monitoring- und Event-Management-Systeme.

Typische Aufgaben:

Ein gutes Event Management reduziert unnötige Arbeit und sorgt dafür, dass kritische Ereignisse schnell erkannt werden.

Zusammenfassung

Event entsteht

↓

Event klassifizieren

↓

Filter anwenden

↓

Priorität bestimmen

↓

Event korrelieren

↓

Reaktion auslösen

↓

Dokumentieren

Merksätze

Nicht jedes Event ist wichtig.

Informational Events dokumentieren normale Zustände.

Warning Events weisen auf mögliche zukünftige Probleme hin.

Exception Events erfordern häufig eine Reaktion.

Gute Filter und Event-Korrelation verhindern Alarmfluten.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Event-Kategorien (Informational, Warning und Exception) entsprechen der ITIL-Praxis. Die konkreten Prioritäten, Filterregeln, Schwellenwerte und Automatisierungen werden organisationsspezifisch definiert und hängen von den überwachten Services sowie den eingesetzten Monitoring-Werkzeugen ab.

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

10. Monitoring and Event Management

10.3 Alarme, Eskalationen und Automatisierung

Kurz erklärt

Nicht jedes Event erfordert menschliches Eingreifen.

Erst wenn ein Ereignis eine definierte Bedeutung besitzt, wird daraus ein Alarm.

Je nach Schwere können anschließend automatische Aktionen, Eskalationen oder die Erstellung eines Incident-Tickets erfolgen.

Ziel ist es, Probleme möglichst schnell und möglichst automatisch zu erkennen und zu behandeln.

Vom Event zum Alarm

Ein Monitoring-System erzeugt kontinuierlich Events.

Nur ein Teil dieser Events wird zu Alarmen.

Ein typischer Ablauf:

Monitoring
      │
      ▼
Event
      │
      ▼
Bewertung
      │
 ┌────┴────┐
 │         │
keine      Alarm
Aktion      │
            ▼
Reaktion

Die Bewertung erfolgt anhand definierter Regeln.

Was ist ein Alarm?

Ein Alarm ist eine Benachrichtigung über ein relevantes Ereignis.

Er informiert darüber, dass eine Reaktion erforderlich oder zumindest sinnvoll sein kann.

Ein Alarm bedeutet jedoch nicht automatisch, dass bereits ein Incident vorliegt.

Beispiele für Alarme

Typische Alarme:

Je nach Kritikalität unterscheiden sich die weiteren Maßnahmen.

Alarme priorisieren

Nicht jeder Alarm besitzt dieselbe Bedeutung.

Mögliche Kriterien:

Dadurch kann dieselbe technische Meldung unterschiedlich behandelt werden.

Alarmstufen

Viele Organisationen verwenden mehrere Alarmstufen.

Beispiel:

Stufe Bedeutung
Information nur protokollieren
Warnung beobachten
Hoch Administrator informieren
Kritisch sofort reagieren
Notfall Eskalation und Incident

Die genaue Anzahl der Stufen ist organisationsabhängig.

Alarmkanäle

Alarme können über verschiedene Wege zugestellt werden.

Beispiele:

Der Kanal richtet sich nach der Kritikalität.

Alarmrouting

Nicht jeder Alarm geht an dieselbe Person.

Beispiele:

Alarm Empfänger
Netzwerk Netzwerkteam
Backup Backup-Team
Datenbank Datenbankadministration
Cloud Cloud-Team
Active Directory Windows-Team
Linux Linux-Team
Container Plattform-Team

Dadurch gelangen Informationen direkt an die zuständigen Personen.

Automatische Reaktionen

Viele Alarme können automatisiert verarbeitet werden.

Beispiele:

Nicht jede Situation erfordert sofort einen Administrator.

Selbstheilung (Self-Healing)

Self-Healing beschreibt automatische Korrekturmaßnahmen.

Beispiele:

Dadurch entstehen viele Incidents gar nicht erst.

Beispiel

Container beendet sich
        │
        ▼
Monitoring erkennt Fehler
        │
        ▼
Container automatisch neu starten
        │
        ▼
Container läuft wieder
        │
        ▼
Event dokumentieren

Der Benutzer bemerkt den Fehler möglicherweise überhaupt nicht.

Automatisierte Incident-Erstellung

Nicht jeder Alarm erzeugt automatisch einen Incident.

Sinnvoll ist dies beispielsweise bei:

Das ITSM-System erstellt automatisch ein Incident-Ticket.

Eskalationen

Kann ein Alarm nicht automatisch gelöst werden,

beginnt häufig eine Eskalation.

Beispiele:

Welche Eskalation erfolgt,

hängt von Schwere und Auswirkungen ab.

Zeitabhängige Eskalationen

Nicht jeder Alarm wird sofort eskaliert.

Beispiel:

CPU-Auslastung:

Zeitfilter verhindern unnötige Reaktionen.

Mehrstufige Eskalationen

Ein möglicher Ablauf:

Alarm
   │
   ▼
Administrator
   │
   ▼
Bereitschaft
   │
   ▼
Teamleiter
   │
   ▼
Incident Manager
   │
   ▼
Major Incident

Nicht jeder Alarm erreicht automatisch die höchste Eskalationsstufe.

Alarmunterdrückung

Während geplanter Wartungen können Alarme unterdrückt werden.

Beispiel:

Ein Server wird bewusst neu gestartet.

Das Monitoring erkennt:

Server nicht erreichbar.

Da ein genehmigter Change aktiv ist,

wird kein Incident erzeugt.

Abhängigkeiten berücksichtigen

Ein ausgefallener Router verursacht häufig viele weitere Alarme.

Beispiele:

Durch Abhängigkeitsregeln wird möglichst nur der eigentliche Fehler hervorgehoben.

Alarmkorrelation

Mehrere Alarme können zusammengehören.

Beispiel:

Die eigentliche Ursache:

Storage reagiert verzögert.

Alarmkorrelation unterstützt Administratoren bei der Ursachenanalyse.

Alarmfluten vermeiden

Zu viele Warnungen führen häufig dazu,

dass wichtige Alarme übersehen werden.

Typische Maßnahmen:

Dadurch steigt die Qualität der Alarmierung.

Dashboards

Dashboards stellen Alarme übersichtlich dar.

Typische Informationen:

Sie ermöglichen einen schnellen Überblick.

Benachrichtigung außerhalb der Arbeitszeit

Kritische Systeme werden häufig rund um die Uhr überwacht.

Außerhalb der Geschäftszeiten können Alarme beispielsweise an:

gesendet werden.

Dadurch bleibt die Reaktionsfähigkeit erhalten.

Praxisbeispiel

Ein RAID-Verbund meldet:

Eine Festplatte ausgefallen.

Automatisch geschieht:

Die eigentliche Reparatur erfolgt anschließend durch den zuständigen Administrator.

Typische Fehler

Fehler 1

Jeder Alarm erzeugt sofort einen Incident.

Fehler 2

Keine automatische Fehlerbehandlung.

Fehler 3

Keine Alarmkorrelation.

Fehler 4

Zu viele Benachrichtigungen.

Fehler 5

Keine Wartungsfenster berücksichtigt.

Fehler 6

Falsche Empfänger erhalten Alarme.

Fehler 7

Self-Healing wird nicht genutzt.

Fehler 8

Bereitschaft wird wegen unwichtiger Warnungen gestört.

Fehler 9

Alarmregeln werden nach Änderungen nicht angepasst.

Fehler 10

Fehlgeschlagene Automatisierungen bleiben unbemerkt.

Checkliste Alarmmanagement

Checkliste Automatisierung

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker richten häufig Alarmierungen und automatische Reaktionen ein.

Typische Aufgaben:

Ein gut abgestimmtes Alarmmanagement sorgt dafür, dass kritische Ereignisse schnell erkannt und möglichst automatisch behandelt werden.

Zusammenfassung

Monitoring erkennt Event

↓

Event bewerten

↓

Alarm erzeugen

↓

Priorisieren

↓

Automatische Reaktion oder Eskalation

↓

Incident (falls erforderlich)

↓

Dokumentation

Merksätze

Nicht jeder Alarm führt zu einem Incident.

Gute Alarmregeln vermeiden unnötige Benachrichtigungen.

Self-Healing kann viele Incidents vollständig verhindern.

Alarmkorrelation unterstützt die Ursachenanalyse.

Die richtige Information muss zur richtigen Zeit die richtige Person erreichen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Alarmierungsstrategien, Eskalationsmodelle, Self-Healing-Beispiele und Automatisierungen sind herstellerneutrale Praxisempfehlungen. ITIL definiert die Grundprinzipien des Monitoring and Event Management, schreibt jedoch keine konkreten Alarmstufen, Eskalationswege oder Automatisierungsmechanismen vor. Diese werden organisationsabhängig anhand der Servicekritikalität und der eingesetzten Monitoring- und ITSM-Werkzeuge umgesetzt.

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

10. Monitoring and Event Management

10.4 Monitoring-Werkzeuge, Dashboards und Kennzahlen

Kurz erklärt

Monitoring-Werkzeuge sammeln kontinuierlich Informationen über IT-Services, Anwendungen und Infrastruktur.

Dashboards bereiten diese Informationen übersichtlich auf, während Kennzahlen (Metrics) helfen, Trends, Risiken und Verbesserungsmöglichkeiten zu erkennen.

Ziel ist es, aus einer großen Menge technischer Daten verwertbare Informationen für den Betrieb und die Entscheidungsfindung zu gewinnen.

Warum Monitoring-Werkzeuge notwendig sind

Moderne IT-Umgebungen bestehen häufig aus:

Eine manuelle Überwachung wäre praktisch unmöglich.

Monitoring-Werkzeuge sammeln und bewerten diese Informationen automatisch.

Aufgaben eines Monitoring-Werkzeugs

Ein Monitoring-System kann beispielsweise:

Das Werkzeug ersetzt dabei nicht die Analyse durch Fachpersonal.

Es liefert die notwendigen Informationen.

Was ist ein Dashboard?

Ein Dashboard fasst wichtige Informationen übersichtlich zusammen.

Es beantwortet Fragen wie:

Dadurch entsteht ein schneller Überblick über den aktuellen Zustand der IT.

Ziele eines Dashboards

Ein gutes Dashboard soll:

Nicht jede Person benötigt dieselben Informationen.

Verschiedene Dashboards

Je nach Rolle unterscheiden sich Dashboards erheblich.

Beispiele:

Jede Zielgruppe benötigt andere Informationen.

Service-Desk-Dashboard

Typische Inhalte:

Das Dashboard unterstützt die tägliche Bearbeitung.

Netzwerk-Dashboard

Mögliche Informationen:

Dadurch lassen sich Netzwerkprobleme schnell erkennen.

Server-Dashboard

Typische Kennzahlen:

Cloud-Dashboard

Beispiele:

Cloud-Dashboards berücksichtigen häufig zusätzlich wirtschaftliche Kennzahlen.

Management-Dashboard

Das Management benötigt meist keine technischen Details.

Interessant sind beispielsweise:

Dashboards sollten immer an die Zielgruppe angepasst werden.

Was sind Kennzahlen (Metrics)?

Kennzahlen beschreiben messbare Eigenschaften eines Systems oder Services.

Beispiele:

Kennzahlen bilden die Grundlage für Berichte und Entscheidungen.

Technische Kennzahlen

Typische technische Kennzahlen:

Sie beschreiben den technischen Zustand.

Servicebezogene Kennzahlen

Beispiele:

Sie beschreiben die Sicht des Benutzers.

Geschäftsbezogene Kennzahlen

Beispiele:

Diese Kennzahlen verbinden IT und Geschäftsprozesse.

Wichtige Monitoring-Kennzahlen

Beispiele:

Kennzahl Aussage
Verfügbarkeit läuft der Service?
Antwortzeit wie schnell reagiert der Service?
CPU Prozessorauslastung
RAM Speicherverbrauch
Festplatte freier Speicher
Netzwerk Datenverkehr
Fehlerrate Anzahl Fehler
Backup erfolgreich oder fehlgeschlagen
Zertifikate verbleibende Laufzeit
Alarme Anzahl kritischer Ereignisse

Nicht jede Kennzahl ist für jeden Service relevant.

KPIs (Key Performance Indicators)

KPIs sind besonders wichtige Kennzahlen.

Beispiele:

KPIs dienen häufig als Grundlage für Service Reviews.

MTTD

Mean Time to Detect beschreibt,

wie schnell eine Störung erkannt wird.

Je kleiner der Wert,

desto früher erkennt das Monitoring Probleme.

MTTR

Mean Time to Restore beschreibt,

wie lange die Wiederherstellung eines Services dauert.

Monitoring kann MTTR verkürzen,

weil Fehler früher erkannt werden.

Trendanalysen

Einzelne Messwerte sind oft wenig aussagekräftig.

Beispiele:

Trends unterstützen Kapazitätsplanung und Verbesserungen.

Historische Daten

Monitoring speichert häufig Messwerte über längere Zeit.

Dadurch lassen sich:

durchführen.

Historische Daten sind für Continual Improvement besonders wertvoll.

Visualisierung

Kennzahlen lassen sich unterschiedlich darstellen.

Beispiele:

Die Darstellung sollte zur jeweiligen Fragestellung passen.

Ampelsysteme

Viele Dashboards verwenden Farben.

Beispiel:

🟢 Normal

🟡 Warnung

🔴 Kritisch

Farben ermöglichen eine schnelle Orientierung.

Sie sollten jedoch nicht die einzige Informationsquelle sein.

Service Maps

Service Maps zeigen,

welche Systeme zu einem Service gehören.

Beispiel:

Online-Shop
      │
      ├── Webserver
      ├── Datenbank
      ├── Storage
      ├── DNS
      ├── Load Balancer
      └── Payment API

Dadurch werden Abhängigkeiten sichtbar.

Kapazitätsplanung

Monitoring unterstützt Capacity Management.

Beispiele:

Kapazitätsprobleme können früh erkannt werden.

Monitoring und Reports

Aus Kennzahlen entstehen Reports.

Typische Inhalte:

Reports richten sich häufig an:

Praxisbeispiel

Das Dashboard zeigt:

Administratoren erkennen sofort,

dass aktuell kein unmittelbarer Handlungsbedarf besteht.

Typische Fehler

Fehler 1

Zu viele Kennzahlen.

Fehler 2

Falsche Zielgruppe.

Fehler 3

Veraltete Dashboards.

Fehler 4

Nur technische Kennzahlen.

Fehler 5

Keine Trendanalyse.

Fehler 6

KPIs sind unklar definiert.

Fehler 7

Service Maps fehlen.

Fehler 8

Historische Daten werden nicht ausgewertet.

Fehler 9

Dashboards enthalten zu viele Details.

Fehler 10

Kennzahlen werden gemessen,

aber nicht genutzt.

Checkliste Monitoring-Dashboard

Checkliste Kennzahlen

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten regelmäßig mit Monitoring-Dashboards und Kennzahlen.

Typische Aufgaben:

Die Fähigkeit, Messwerte richtig zu interpretieren, ist im IT-Betrieb oft wichtiger als das reine Sammeln der Daten.

Zusammenfassung

Monitoring sammelt Messwerte

↓

Kennzahlen berechnen

↓

Dashboard darstellen

↓

Trends erkennen

↓

Reports erstellen

↓

Entscheidungen treffen

↓

Services verbessern

Merksätze

Ein Dashboard soll Entscheidungen unterstützen – nicht möglichst viele Daten anzeigen.

KPIs konzentrieren sich auf die wichtigsten Kennzahlen.

Servicebezogene Kennzahlen sind für Benutzer wichtiger als reine Hardwarewerte.

Historische Daten ermöglichen Ursachenanalysen und Kapazitätsplanung.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Dashboards, Kennzahlen, KPIs und Visualisierungen sind herstellerneutrale Praxisempfehlungen. ITIL definiert Grundprinzipien für Monitoring und Reporting, schreibt jedoch keine konkreten Werkzeuge, Dashboards oder Kennzahlen vor. Die Auswahl richtet sich nach den überwachten Services, den Geschäftsanforderungen und den Informationsbedürfnissen der jeweiligen Zielgruppen.

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

10. Monitoring and Event Management

10.5 Zusammenspiel mit Incident, Problem, Change und Service Configuration Management

Kurz erklärt

Monitoring and Event Management arbeitet eng mit anderen ITIL Practices zusammen.

Monitoring erkennt Ereignisse, bewertet deren Bedeutung und stellt Informationen für andere Prozesse bereit.

Erst durch das Zusammenspiel mit Incident Management, Problem Management, Change Enablement und Service Configuration Management entsteht ein vollständiger und effizienter IT-Servicebetrieb.

Warum das Zusammenspiel wichtig ist

Monitoring allein behebt keine Fehler.

Es beantwortet zunächst nur die Frage:

"Was ist passiert?"

Andere ITIL Practices beantworten anschließend beispielsweise:

Erst gemeinsam entsteht ein vollständiger Ablauf.

Zusammenspiel der Practices

Monitoring
      │
      ▼
Event
      │
      ▼
Bewertung
      │
      ▼
Incident?
      │
 ┌────┴────┐
 │         │
Nein      Ja
 │         │
 ▼         ▼
Protokoll Incident
            │
            ▼
Problem?
            │
            ▼
Change?
            │
            ▼
Service wiederhergestellt

Nicht jedes Event durchläuft alle Schritte.

Monitoring und Incident Management

Diese beiden Practices arbeiten besonders eng zusammen.

Monitoring erkennt Ereignisse.

Incident Management stellt den normalen Servicebetrieb wieder her.

Beispiel:

Monitoring erkennt:

Webserver antwortet nicht.

Anschließend:

Monitoring erkennt den Fehler.

Incident Management behebt ihn.

Monitoring erkennt häufig Incidents vor dem Benutzer

Ein großer Vorteil moderner Monitoring-Systeme:

Probleme werden oft erkannt,

bevor Benutzer sie melden.

Beispiele:

Viele Incidents können dadurch vollständig vermieden werden.

Monitoring und Problem Management

Ein einzelner Alarm ist häufig kein Problem.

Wiederholen sich jedoch dieselben Events regelmäßig,

kann daraus ein Problem Record entstehen.

Beispiel:

Jeden Dienstag:

Incident wird jedes Mal behoben.

Monitoring zeigt jedoch,

dass dieselbe Ursache regelmäßig auftritt.

Jetzt beginnt Problem Management mit der Ursachenanalyse.

Trendanalysen unterstützen Problem Management

Monitoring speichert historische Daten.

Dadurch lassen sich erkennen:

Diese Informationen helfen bei der Suche nach der eigentlichen Ursache.

Monitoring und Change Enablement

Viele Changes beeinflussen Monitoring.

Beispiele:

Nach einem Change muss häufig auch das Monitoring angepasst werden.

Monitoring vor einem Change

Vor Änderungen liefern Monitoring-Daten wichtige Informationen.

Beispiele:

Dadurch kann später geprüft werden,

ob der Change erfolgreich war.

Monitoring nach einem Change

Nach der Umsetzung wird kontrolliert:

Monitoring bestätigt,

ob die Änderung erfolgreich war.

Geplante Wartungen

Während eines genehmigten Changes sollten Monitoring-Systeme dies berücksichtigen.

Beispiel:

Server wird bewusst neu gestartet.

Ohne Wartungsfenster:

Mit Wartungsfenster:

Monitoring und Service Configuration Management

Monitoring überwacht Configuration Items.

Configuration Management beschreibt diese.

Beispiele:

Monitoring liefert aktuelle Zustandsinformationen.

Configuration Management liefert Struktur und Beziehungen.

Warum Configuration Items wichtig sind

Ohne Configuration Management weiß Monitoring häufig nicht,

welche Bedeutung ein System besitzt.

Beispiel:

Server 01 fällt aus.

Monitoring erkennt den Ausfall.

Erst Configuration Management zeigt:

Dieser Server gehört zum:

Dadurch lässt sich die Auswirkung deutlich besser bewerten.

Service Maps

Service Maps verbinden Monitoring und Configuration Management.

Beispiel:

Online-Shop
      │
      ├── Webserver
      ├── Load Balancer
      ├── Datenbank
      ├── Storage
      ├── DNS
      └── Payment API

Fällt eine Komponente aus,

werden die betroffenen Services sofort sichtbar.

Abhängigkeiten erkennen

Configuration Management zeigt,

welche Systeme voneinander abhängig sind.

Dadurch kann Monitoring:

Monitoring und Availability Management

Monitoring liefert die Grundlage zur Messung der Verfügbarkeit.

Beispiele:

Availability Management nutzt diese Daten,

um Verfügbarkeitsziele zu bewerten.

Monitoring und Capacity Management

Monitoring misst kontinuierlich:

Capacity Management nutzt diese Informationen,

um zukünftige Ressourcen zu planen.

Monitoring und Information Security Management

Monitoring erkennt auch sicherheitsrelevante Ereignisse.

Beispiele:

Diese Events können an Security-Prozesse weitergeleitet werden.

Monitoring und Continual Improvement

Monitoring liefert kontinuierlich Kennzahlen.

Dadurch lassen sich Verbesserungen erkennen.

Beispiele:

Continual Improvement nutzt diese Daten,

um Prozesse weiterzuentwickeln.

Monitoring und Service Level Management

Viele SLA-Kennzahlen basieren direkt auf Monitoring-Daten.

Beispiele:

Ohne zuverlässiges Monitoring können SLA-Ziele kaum objektiv gemessen werden.

Praxisbeispiel

Das Monitoring erkennt:

Die Antwortzeit einer Datenbank steigt seit mehreren Wochen kontinuierlich an.

Zunächst entstehen einzelne Warning Events.

Später treten wiederholt Incidents auf.

Problem Management untersucht die Ursache und stellt fest,

dass der verfügbare Speicher nicht mehr ausreicht.

Ein genehmigter Change erweitert den Speicher.

Nach der Umsetzung zeigt das Monitoring wieder normale Antwortzeiten.

Die gewonnenen Erkenntnisse fließen anschließend in Continual Improvement ein.

Typische Fehler

Fehler 1

Monitoring arbeitet unabhängig von Incident Management.

Fehler 2

Configuration Items sind nicht aktuell.

Fehler 3

Changes berücksichtigen das Monitoring nicht.

Fehler 4

Monitoring-Daten werden nicht ausgewertet.

Fehler 5

Wiederkehrende Events führen nicht zu Problem Records.

Fehler 6

Service Maps fehlen.

Fehler 7

Abhängigkeiten werden nicht berücksichtigt.

Fehler 8

Monitoring misst keine SLA-Kennzahlen.

Fehler 9

Kapazitätsdaten werden nicht ausgewertet.

Fehler 10

Verbesserungen basieren nicht auf Messdaten.

Checkliste Zusammenspiel

Checkliste Monitoring-Prozess

Bedeutung für Fachinformatiker für Systemintegration

Monitoring gehört zu den wichtigsten Werkzeugen im Arbeitsalltag eines Fachinformatikers.

Typische Aufgaben:

Ein gut integriertes Monitoring unterstützt nahezu alle Bereiche des IT-Service-Managements.

Zusammenfassung

Monitoring erkennt Events

↓

Event bewerten

↓

Incident auslösen (falls erforderlich)

↓

Problem analysieren

↓

Change umsetzen

↓

Monitoring überprüft Ergebnis

↓

Erkenntnisse für Continual Improvement nutzen

Merksätze

Monitoring erkennt Ereignisse – andere Practices reagieren darauf.

Monitoring liefert die Grundlage für Incident, Problem und Change Management.

Configuration Management erklärt die Beziehungen zwischen den überwachten Systemen.

Gute Service Maps beschleunigen die Ursachenanalyse.

Monitoring-Daten bilden die Grundlage für kontinuierliche Verbesserungen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Zusammenhänge orientieren sich an den offiziellen ITIL-Practices. Monitoring and Event Management stellt Informationen für zahlreiche weitere Practices bereit, übernimmt jedoch selbst weder die Fehlerbehebung noch die Ursachenanalyse oder die Planung von Änderungen. Die konkrete technische Umsetzung hängt von den eingesetzten Monitoring-, ITSM- und CMDB-Systemen der jeweiligen Organisation ab.

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

11. Service Configuration Management

11. Service Configuration Management

11.1 Ziele und Grundlagen des Service Configuration Management

Kurz erklärt

Service Configuration Management sorgt dafür, dass Informationen über IT-Services und deren Bestandteile vollständig, aktuell und nachvollziehbar verwaltet werden.

Dazu gehören unter anderem Server, Clients, Netzwerkgeräte, Anwendungen, Cloud-Ressourcen, Dokumentationen und ihre gegenseitigen Beziehungen.

Ziel ist es, jederzeit zu wissen, welche Komponenten existieren, wie sie zusammenhängen und welche Auswirkungen Änderungen oder Störungen haben.

Was ist Service Configuration Management?

Service Configuration Management ist eine ITIL Practice zur Verwaltung von Informationen über Services und deren Bestandteile.

Dabei werden nicht die Geräte selbst verwaltet,

sondern die Informationen über diese Objekte.

Beispiele:

Alle diese Objekte können Bestandteil eines IT-Services sein.

Warum Service Configuration Management wichtig ist

In modernen IT-Umgebungen existieren oft tausende oder sogar zehntausende Komponenten.

Ohne eine strukturierte Verwaltung entstehen schnell Fragen wie:

Service Configuration Management beantwortet genau diese Fragen.

Ziele des Service Configuration Management

Die wichtigsten Ziele sind:

Was ist ein Configuration Item (CI)?

Ein Configuration Item (CI) ist jedes Objekt,

das für die Bereitstellung oder Verwaltung eines IT-Services relevant ist.

Ein CI kann beispielsweise sein:

Nicht jedes Inventarobjekt muss automatisch ein CI sein.

Entscheidend ist die Bedeutung für den Service.

Beispiele für Configuration Items

Kategorie Beispiele
Hardware Server, Notebook, Switch
Software Betriebssystem, ERP, Datenbank
Netzwerk Router, Firewall, VLAN
Cloud virtuelle Maschine, Storage, Load Balancer
Dokumentation Runbook, Architekturdiagramm
Service E-Mail, VPN, Fileserver
Verträge SLA, Wartungsvertrag

Nicht jedes Objekt ist ein CI

Ein einzelnes Netzwerkkabel oder eine Computermaus wird häufig inventarisiert,

aber nicht unbedingt als Configuration Item verwaltet.

Dagegen besitzen folgende Objekte meist einen direkten Einfluss auf Services:

Diese werden häufig als CIs geführt.

Was wird über ein CI gespeichert?

Je nach Organisation können unterschiedliche Informationen gespeichert werden.

Typische Angaben:

Je kritischer das CI,

desto umfangreicher sind häufig die gespeicherten Informationen.

Der Lebenszyklus eines Configuration Items

Ein CI durchläuft mehrere Phasen.

Beispiel:

Geplant
    │
    ▼
Beschafft
    │
    ▼
Installiert
    │
    ▼
In Betrieb
    │
    ▼
Geändert
    │
    ▼
Außer Betrieb
    │
    ▼
Entsorgt

Alle relevanten Änderungen sollten dokumentiert werden.

Status eines Configuration Items

Typische Status:

Der aktuelle Status erleichtert den Überblick.

Beziehungen zwischen Configuration Items

Ein großer Vorteil des Service Configuration Managements besteht darin,

dass Beziehungen dokumentiert werden.

Beispiel:

Online-Shop
      │
      ├── Webserver
      │      │
      │      └── Betriebssystem
      │
      ├── Datenbank
      │
      ├── Storage
      │
      └── Firewall

Dadurch wird sichtbar,

welche Komponenten voneinander abhängig sind.

Warum Beziehungen wichtig sind

Fällt eine Datenbank aus,

kann dies Auswirkungen haben auf:

Durch dokumentierte Beziehungen lassen sich Auswirkungen deutlich schneller erkennen.

Service statt Einzelgerät

ITIL betrachtet nicht einzelne Geräte,

sondern den gesamten Service.

Ein Benutzer interessiert sich beispielsweise nicht dafür,

welcher Server ausgefallen ist.

Wichtig ist für ihn,

ob der E-Mail-Service funktioniert.

Service Configuration Management verbindet technische Komponenten mit den bereitgestellten Services.

Service Maps

Service Maps zeigen grafisch,

welche Configuration Items zu einem Service gehören.

Beispiel:

VPN-Service
      │
      ├── Firewall
      ├── VPN-Gateway
      ├── Active Directory
      ├── DNS
      └── Zertifikate

Dadurch lassen sich Störungen und Änderungen schneller bewerten.

Warum aktuelle Daten wichtig sind

Veraltete Informationen führen häufig zu:

Deshalb müssen Configuration-Daten regelmäßig gepflegt werden.

Praxisbeispiel

Ein Webserver fällt aus.

Durch Service Configuration Management erkennt die IT sofort,

dass betroffen sind:

Dadurch kann die Priorität schneller bestimmt und der Incident gezielt bearbeitet werden.

Typische Fehler

Fehler 1

Configuration Items sind nicht aktuell.

Fehler 2

Beziehungen fehlen.

Fehler 3

Services sind nicht dokumentiert.

Fehler 4

Änderungen werden nicht nachgetragen.

Fehler 5

Verantwortlichkeiten sind unklar.

Fehler 6

Zu viele unwichtige Objekte werden als CIs verwaltet.

Fehler 7

Service Maps fehlen.

Fehler 8

Configuration Management wird nur als Inventarliste genutzt.

Checkliste Configuration Items

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten regelmäßig mit Configuration Items.

Typische Aufgaben:

Eine gepflegte Configuration-Datenbasis erleichtert nahezu alle Bereiche des IT-Service-Managements.

Zusammenfassung

Service identifizieren

↓

Configuration Items erfassen

↓

Beziehungen dokumentieren

↓

Status aktuell halten

↓

Änderungen nachführen

↓

Informationen für Incident, Problem und Change Management bereitstellen

Merksätze

Service Configuration Management verwaltet Informationen – nicht die Hardware selbst.

Ein Configuration Item ist jedes für einen Service relevante Objekt.

Beziehungen zwischen Configuration Items sind oft wichtiger als die einzelnen Komponenten.

Aktuelle Configuration-Daten beschleunigen Incident- und Change-Prozesse.

Gute Service Maps erhöhen die Transparenz komplexer IT-Umgebungen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Beispiele und Vorgehensweisen orientieren sich an der ITIL Practice „Service Configuration Management“. Welche Objekte als Configuration Items geführt werden und welche Informationen gespeichert werden, richtet sich nach Größe, Komplexität und Anforderungen der jeweiligen Organisation.

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

11. Service Configuration Management

11.2 Configuration Items, Attribute und Beziehungen

Kurz erklärt

Ein Configuration Item (CI) besteht nicht nur aus einem Namen.

Erst durch seine Eigenschaften (Attribute) und seine Beziehungen zu anderen Configuration Items entsteht ein vollständiges Bild eines IT-Services.

Ziel ist es, jederzeit nachvollziehen zu können, welche Komponenten existieren, welche Informationen darüber bekannt sind und wie sie miteinander verbunden sind.

Aufbau eines Configuration Items

Jedes Configuration Item besitzt eine Reihe von Informationen, die seinen aktuellen Zustand beschreiben.

Typische Bestandteile:

Je kritischer ein CI ist, desto umfangreicher sind häufig die gespeicherten Informationen.

Was sind Attribute?

Attribute sind Eigenschaften eines Configuration Items.

Sie beschreiben das CI genauer.

Beispiele:

Nicht jedes CI benötigt dieselben Attribute.

Beispiel: Server als Configuration Item

Attribut Beispiel
CI-ID SRV-00125
Name APP-SRV-01
Typ Virtueller Server
Betriebssystem Windows Server 2025
IP-Adresse 10.20.5.15
Standort Rechenzentrum Berlin
Status Produktiv
Verantwortlich Windows-Team
Service ERP-System

Diese Informationen erleichtern die Verwaltung erheblich.

Beispiel: Netzwerk-Switch

Ein Switch kann unter anderem folgende Attribute besitzen:

Dadurch lassen sich Wartung und Fehleranalyse vereinfachen.

Pflicht- und optionale Attribute

Nicht alle Informationen sind immer erforderlich.

Beispiel:

Pflichtattribute:

Optionale Attribute:

Die Organisation legt selbst fest, welche Angaben verpflichtend sind.

Eindeutige Identifikation

Jedes Configuration Item sollte eindeutig identifizierbar sein.

Geeignet sind beispielsweise:

Mehrdeutige Bezeichnungen erschweren den Betrieb.

Beziehungen zwischen Configuration Items

Einzelne Configuration Items bilden selten einen vollständigen Service.

Erst ihre Beziehungen machen Zusammenhänge sichtbar.

Beispiele:

Diese Beziehungen ermöglichen eine deutlich bessere Auswirkungsanalyse.

Beispiel einer Beziehung

Online-Shop
      │
      ▼
Webserver
      │
      ▼
Datenbank
      │
      ▼
Storage

Fällt das Storage-System aus,

kann die gesamte Anwendung betroffen sein.

Arten von Beziehungen

Typische Beziehungstypen:

Beziehung Beispiel
läuft auf Anwendung → Server
verwendet Anwendung → Datenbank
verbindet Switch → Server
schützt Firewall → Netzwerk
repliziert Datenbank → Datenbank
enthält Service → Anwendung
sichert Backup → Server

Je genauer Beziehungen dokumentiert sind,

desto einfacher lassen sich Auswirkungen erkennen.

Service und Configuration Items

Ein Service besteht meist aus mehreren Configuration Items.

Beispiel:

E-Mail-Service
      │
      ├── Mailserver
      ├── Datenbank
      ├── Storage
      ├── DNS
      ├── Firewall
      ├── Active Directory
      └── Zertifikate

Der Service ist mehr als die Summe seiner technischen Komponenten.

Auswirkungsanalyse (Impact Analysis)

Beziehungen ermöglichen eine schnelle Bewertung von Auswirkungen.

Beispiel:

Vor einem geplanten Change soll ein Server neu gestartet werden.

Durch die dokumentierten Beziehungen erkennt die IT sofort:

Betroffen sind:

Dadurch kann das Wartungsfenster besser geplant werden.

Root Cause Analysis unterstützen

Auch bei Störungen helfen Beziehungen.

Beispiel:

Monitoring meldet:

Die Beziehungen zeigen,

dass alle Systeme dieselbe Datenbank verwenden.

Die eigentliche Ursache liegt vermutlich dort.

Versionen dokumentieren

Viele Configuration Items besitzen unterschiedliche Versionen.

Beispiele:

Versionen erleichtern:

Eigentümer und Verantwortliche

Ein Configuration Item sollte einen fachlichen oder technischen Verantwortlichen besitzen.

Beispiele:

Dadurch ist klar,

wer Änderungen oder Entscheidungen verantwortet.

Status eines Configuration Items

Typische Statuswerte:

Der Status sollte jederzeit aktuell sein.

Dokumentationen verknüpfen

Zu einem CI können verschiedene Dokumente gehören.

Beispiele:

Diese Informationen sollten möglichst direkt mit dem CI verknüpft sein.

Automatische Aktualisierung

Viele Attribute können automatisch gepflegt werden.

Beispiele:

Dadurch steigt die Datenqualität.

Praxisbeispiel

Ein Administrator plant,

die Firmware einer Firewall zu aktualisieren.

Durch die Beziehungen erkennt er,

dass betroffen sind:

Das Wartungsfenster wird entsprechend geplant.

Typische Fehler

Fehler 1

Configuration Items besitzen keine eindeutige ID.

Fehler 2

Attribute sind unvollständig.

Fehler 3

Beziehungen fehlen.

Fehler 4

Verantwortliche sind nicht dokumentiert.

Fehler 5

Versionen werden nicht aktualisiert.

Fehler 6

Dokumentationen sind nicht verknüpft.

Fehler 7

Status stimmt nicht mit der Realität überein.

Fehler 8

Zu viele irrelevante Attribute werden gepflegt.

Checkliste Configuration Items

Checkliste Beziehungen

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker pflegen Configuration Items häufig direkt im Arbeitsalltag.

Typische Aufgaben:

Je vollständiger die Configuration-Daten sind, desto einfacher werden Incident-, Problem- und Change-Prozesse.

Zusammenfassung

Configuration Item erfassen

↓

Attribute ergänzen

↓

Beziehungen dokumentieren

↓

Verantwortlichkeiten festlegen

↓

Status aktuell halten

↓

Informationen für andere ITIL Practices bereitstellen

Merksätze

Ein Configuration Item besteht aus mehr als seinem Namen.

Attribute beschreiben ein CI – Beziehungen verbinden mehrere CIs.

Beziehungen sind entscheidend für Impact- und Ursachenanalysen.

Aktuelle Attribute erhöhen die Qualität der CMDB.

Gute Configuration-Daten erleichtern nahezu alle ITIL Practices.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Attribute, Beziehungstypen und Beispiele orientieren sich an der ITIL Practice „Service Configuration Management“. Welche Attribute gespeichert und welche Beziehungstypen verwendet werden, hängt von den Anforderungen und dem Datenmodell der jeweiligen Organisation ab.

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

11. Service Configuration Management

11.3 CMDB und Configuration Management System (CMS)

Kurz erklärt

Damit Configuration Items und ihre Beziehungen verwaltet werden können, benötigen Organisationen geeignete Werkzeuge.

Die bekannteste Datenbank hierfür ist die Configuration Management Database (CMDB).

ITIL betrachtet jedoch nicht nur eine einzelne Datenbank, sondern ein Configuration Management System (CMS), das Informationen aus verschiedenen Quellen zusammenführt.

Ziel ist es, jederzeit aktuelle und verlässliche Informationen über Services und deren Bestandteile bereitzustellen.

Was ist eine CMDB?

Die Configuration Management Database (CMDB) ist eine Datenbank zur Speicherung von Informationen über Configuration Items und deren Beziehungen.

Eine CMDB enthält beispielsweise Informationen über:

Die CMDB bildet die Grundlage vieler ITSM-Prozesse.

Aufgaben einer CMDB

Eine CMDB soll:

Sie dient als zentrale Informationsquelle für viele ITIL Practices.

Was ist ein Configuration Management System (CMS)?

Ein CMS ist mehr als eine einzelne Datenbank.

Es verbindet verschiedene Informationsquellen miteinander.

Ein CMS kann beispielsweise Informationen aus folgenden Systemen zusammenführen:

Dadurch entsteht ein umfassender Überblick über die IT-Landschaft.

CMDB und CMS unterscheiden

Diese Begriffe werden häufig verwechselt.

CMDB CMS
einzelne Datenbank Gesamtsystem
speichert CI-Daten verbindet mehrere Datenquellen
Bestandteil des CMS umfasst zahlreiche Systeme
enthält Configuration Items stellt Informationen bereit

Die CMDB ist also ein Bestandteil des CMS.

Aufbau eines CMS

Ein mögliches Beispiel:

Monitoring
      │
Inventarisierung
      │
Cloud
      │
Active Directory
      │
Ticket-System
      │
Dokumentation
      │
      ▼
Configuration Management System
      │
      ▼
CMDB

Das CMS stellt Informationen aus verschiedenen Quellen zusammen.

Welche Informationen stammen aus welchen Quellen?

Beispiele:

Informationsquelle Beispiele
Monitoring Status, Alarme
Active Directory Benutzer, Computer
Virtualisierung virtuelle Maschinen
Cloud Instanzen, Storage
Inventarisierung Hardware
Ticket-System Incidents, Changes
Dokumentation Runbooks, Architektur

Das CMS verbindet diese Informationen logisch miteinander.

Warum nicht alles in der CMDB speichern?

Nicht jede Information gehört dauerhaft in die CMDB.

Beispiel:

CPU-Auslastung verändert sich ständig.

Diese Information stammt besser direkt aus dem Monitoring.

Die CMDB speichert stattdessen beispielsweise:

Aktuelle Zustandsinformationen liefert das Monitoring.

Zentrale Datenhaltung

Eine zentrale Datenbasis bietet zahlreiche Vorteile.

Beispiele:

Dadurch arbeiten alle ITIL Practices mit denselben Informationen.

Beziehungen visualisieren

Viele CMDB-Systeme können Beziehungen grafisch darstellen.

Beispiel:

CRM-Service
      │
      ├── Webserver
      ├── Datenbank
      ├── Storage
      ├── Firewall
      └── DNS

Solche Darstellungen erleichtern die Fehlersuche erheblich.

Serviceorientierte Sicht

ITIL betrachtet bevorzugt Services statt Einzelgeräte.

Ein Benutzer interessiert sich beispielsweise dafür,

ob der VPN-Service verfügbar ist,

nicht dafür,

welcher einzelne Server betroffen ist.

Das CMS verbindet beide Sichtweisen.

Abfragen im CMS

Ein CMS beantwortet beispielsweise Fragen wie:

Dadurch lassen sich Entscheidungen schneller treffen.

Integration mit Monitoring

Viele CMS-Systeme übernehmen Statusinformationen aus dem Monitoring.

Beispiele:

Dadurch stehen aktuelle Informationen direkt zur Verfügung.

Integration mit Change Enablement

Nach einem erfolgreichen Change sollte die CMDB aktualisiert werden.

Beispiele:

Nur so bleibt die Datenqualität erhalten.

Integration mit Incident Management

Bei einem Incident können Administratoren sofort erkennen:

Dadurch verkürzt sich die Analyse erheblich.

Integration mit Problem Management

Problem Management nutzt historische Informationen aus dem CMS.

Beispiele:

Diese Informationen unterstützen die Ursachenanalyse.

Discovery-Werkzeuge

Viele Informationen müssen nicht manuell gepflegt werden.

Discovery-Werkzeuge erkennen automatisch:

Dadurch sinkt der Pflegeaufwand.

Manuelle Pflege bleibt notwendig

Nicht alle Informationen können automatisch erkannt werden.

Beispiele:

Diese Angaben müssen häufig manuell gepflegt werden.

Datenqualität

Eine CMDB ist nur dann hilfreich,

wenn die gespeicherten Informationen korrekt sind.

Wichtige Kriterien:

Schlechte Daten führen zu falschen Entscheidungen.

Praxisbeispiel

Ein Administrator plant einen Neustart eines Datenbankservers.

Über die CMDB erkennt er sofort:

Der Server gehört zu:

Dadurch wird der Change besser geplant und betroffene Fachbereiche können rechtzeitig informiert werden.

Typische Fehler

Fehler 1

CMDB und CMS werden gleichgesetzt.

Fehler 2

Configuration Items werden nicht aktualisiert.

Fehler 3

Discovery wird nicht genutzt.

Fehler 4

Monitoring ist nicht integriert.

Fehler 5

Beziehungen fehlen.

Fehler 6

Mehrere Datenquellen liefern widersprüchliche Informationen.

Fehler 7

Zu viele Informationen werden manuell gepflegt.

Fehler 8

Niemand ist für die Datenqualität verantwortlich.

Checkliste CMDB

Checkliste CMS

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten regelmäßig mit CMDBs und CMS-Systemen.

Typische Aufgaben:

Ein gepflegtes CMS erleichtert nahezu alle administrativen Tätigkeiten im IT-Betrieb.

Zusammenfassung

Configuration Items erfassen

↓

In der CMDB speichern

↓

Weitere Datenquellen anbinden

↓

Informationen im CMS zusammenführen

↓

Beziehungen darstellen

↓

Informationen für alle ITIL Practices bereitstellen

Merksätze

Die CMDB ist ein Bestandteil des CMS.

Ein CMS verbindet Informationen aus mehreren Quellen.

Monitoring liefert Zustandsdaten – die CMDB liefert Strukturinformationen.

Discovery verbessert die Datenqualität.

Eine CMDB ist nur so gut wie die Qualität ihrer Daten.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

ITIL unterscheidet klar zwischen einer Configuration Management Database (CMDB) als Datenbank und einem Configuration Management System (CMS) als übergeordnetem Informationssystem. Welche Datenquellen integriert werden und wie die technische Umsetzung erfolgt, hängt von den eingesetzten ITSM-, Discovery- und Monitoring-Lösungen der jeweiligen Organisation ab.

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

11. Service Configuration Management

11.4 Pflege, Discovery und Datenqualität

Kurz erklärt

Eine Configuration Management Database (CMDB) ist nur dann hilfreich, wenn ihre Informationen aktuell und korrekt sind.

Deshalb gehören die kontinuierliche Pflege, automatische Discovery-Verfahren und die regelmäßige Überprüfung der Datenqualität zu den wichtigsten Aufgaben des Service Configuration Management.

Ziel ist es, jederzeit eine zuverlässige Informationsbasis für Incident Management, Problem Management, Change Enablement und andere ITIL Practices bereitzustellen.

Warum Datenqualität entscheidend ist

Eine unvollständige oder veraltete CMDB kann mehr Schaden anrichten als gar keine CMDB.

Falsche Informationen führen beispielsweise zu:

Eine hohe Datenqualität ist daher wichtiger als eine möglichst große Anzahl gespeicherter Configuration Items.

Was bedeutet Datenqualität?

Datenqualität beschreibt,

wie zuverlässig und nutzbar Informationen sind.

Wichtige Qualitätsmerkmale:

Nur wenn diese Eigenschaften erfüllt sind,

können andere ITIL Practices auf die Daten vertrauen.

Vollständigkeit

Alle erforderlichen Informationen sollten vorhanden sein.

Beispiele:

Fehlende Informationen erschweren spätere Entscheidungen.

Aktualität

Configuration-Daten müssen Änderungen zeitnah widerspiegeln.

Beispiele:

Veraltete Informationen führen schnell zu Fehlentscheidungen.

Korrektheit

Die gespeicherten Informationen müssen der Realität entsprechen.

Beispiel:

Die CMDB enthält:

Windows Server 2022

Tatsächlich läuft:

Windows Server 2025

Solche Abweichungen können Fehleranalysen und Sicherheitsmaßnahmen erheblich erschweren.

Konsistenz

Informationen dürfen sich nicht widersprechen.

Beispiel:

Die CMDB nennt als Verantwortlichen das Linux-Team,

während die Dokumentation das Windows-Team aufführt.

Solche Widersprüche sollten vermieden werden.

Was ist Discovery?

Discovery bezeichnet die automatische Erkennung von Configuration Items und ihren Eigenschaften.

Discovery-Werkzeuge können beispielsweise erkennen:

Dadurch sinkt der manuelle Pflegeaufwand erheblich.

Wie funktioniert Discovery?

Je nach Werkzeug kommen unterschiedliche Verfahren zum Einsatz.

Beispiele:

Welche Methode verwendet wird,

hängt von der jeweiligen Infrastruktur ab.

Agentenbasierte Discovery

Ein Agent wird direkt auf dem System installiert.

Vorteile:

Nachteile:

Agentenlose Discovery

Hier erfolgt die Erkennung über Netzwerkprotokolle oder Programmierschnittstellen.

Vorteile:

Nachteile:

Automatisch erkannte Informationen

Discovery kann beispielsweise erfassen:

Nicht alle Informationen lassen sich automatisch erkennen.

Was Discovery nicht erkennt

Geschäftsbezogene Informationen müssen häufig manuell ergänzt werden.

Beispiele:

Diese Informationen entstehen meist außerhalb der technischen Infrastruktur.

Regelmäßige Discovery

Discovery sollte regelmäßig ausgeführt werden.

Beispiele:

Dadurch bleiben Änderungen möglichst aktuell.

Abgleich mit der CMDB

Nach einer Discovery werden erkannte Änderungen mit der CMDB verglichen.

Mögliche Ergebnisse:

Nicht jede Änderung wird automatisch übernommen.

Je nach Organisation erfolgt zunächst eine Prüfung.

Manuelle Pflege

Auch bei umfangreicher Discovery bleibt manuelle Pflege notwendig.

Typische Aufgaben:

Automatische Verfahren ersetzen diese Arbeiten nicht vollständig.

Qualitätssicherung

Configuration-Daten sollten regelmäßig überprüft werden.

Mögliche Maßnahmen:

Dadurch lassen sich Fehler früh erkennen.

Configuration Audits

Ein Configuration Audit überprüft,

ob die dokumentierten Informationen der tatsächlichen Umgebung entsprechen.

Beispielsweise wird geprüft:

Audits erhöhen die Zuverlässigkeit der CMDB.

Data Owner

Für wichtige Configuration Items sollte klar geregelt sein,

wer für die Daten verantwortlich ist.

Typische Verantwortliche:

Dadurch bleibt die Pflege dauerhaft sichergestellt.

Kennzahlen zur Datenqualität

Auch Datenqualität kann gemessen werden.

Beispiele:

Diese Kennzahlen unterstützen Continual Improvement.

Praxisbeispiel

Ein Discovery-Werkzeug erkennt,

dass auf einem Server eine neue Version des Betriebssystems installiert wurde.

Die Änderung wird erkannt,

aber zunächst nicht automatisch übernommen.

Nach erfolgreicher Prüfung aktualisiert der Administrator die CMDB.

Dadurch bleiben Dokumentation und tatsächlicher Zustand identisch.

Typische Fehler

Fehler 1

Configuration Items werden nie überprüft.

Fehler 2

Discovery wird nicht genutzt.

Fehler 3

Discovery überschreibt ungeprüft manuelle Angaben.

Fehler 4

Verantwortlichkeiten fehlen.

Fehler 5

Veraltete Beziehungen bleiben bestehen.

Fehler 6

Audits finden nicht statt.

Fehler 7

Zu viele irrelevante Informationen werden gespeichert.

Fehler 8

Monitoring und CMDB liefern widersprüchliche Daten.

Fehler 9

Changes werden nicht in die CMDB übernommen.

Fehler 10

Niemand misst die Datenqualität.

Checkliste Datenqualität

Checkliste Discovery

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker sorgen häufig dafür,

dass Configuration-Daten korrekt und aktuell bleiben.

Typische Aufgaben:

Eine zuverlässige CMDB entsteht nicht einmalig, sondern durch kontinuierliche Pflege.

Zusammenfassung

Configuration Items erfassen

↓

Discovery durchführen

↓

Änderungen erkennen

↓

Daten prüfen

↓

CMDB aktualisieren

↓

Datenqualität überwachen

↓

Regelmäßig auditieren

Merksätze

Eine CMDB ist nur so gut wie ihre Daten.

Discovery reduziert manuellen Pflegeaufwand, ersetzt ihn aber nicht vollständig.

Geschäftsbezogene Informationen müssen häufig manuell ergänzt werden.

Regelmäßige Audits verbessern die Datenqualität.

Aktuelle Configuration-Daten unterstützen nahezu alle ITIL Practices.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die beschriebenen Discovery-Verfahren, Qualitätskriterien und Auditmaßnahmen orientieren sich an den Empfehlungen der ITIL Practice „Service Configuration Management“. Welche Discovery-Werkzeuge, Schnittstellen und Prüfmechanismen eingesetzt werden, hängt von der jeweiligen IT-Landschaft und den organisatorischen Anforderungen ab.

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

11. Service Configuration Management

11.5 Zusammenspiel mit Incident, Problem, Change und Monitoring

Kurz erklärt

Service Configuration Management arbeitet eng mit vielen anderen ITIL Practices zusammen.

Die gespeicherten Informationen über Configuration Items (CIs), Services und deren Beziehungen bilden die Grundlage für fundierte Entscheidungen im IT-Betrieb.

Erst durch das Zusammenspiel mit Incident Management, Problem Management, Change Enablement und Monitoring and Event Management entfaltet Service Configuration Management seinen vollen Nutzen.

Warum das Zusammenspiel wichtig ist

Eine CMDB allein behebt keine Störungen und führt keine Änderungen durch.

Sie beantwortet jedoch entscheidende Fragen wie:

Diese Informationen werden anschließend von anderen ITIL Practices genutzt.

Zusammenspiel der Practices

Configuration Items
          │
          ▼
CMDB / CMS
          │
          ▼
Incident
Problem
Change
Monitoring
          │
          ▼
Bessere Entscheidungen

Die CMDB dient als gemeinsame Informationsbasis.

Service Configuration Management und Incident Management

Bei einem Incident muss häufig schnell geklärt werden:

Diese Informationen stammen aus der CMDB.

Beispiel

Das Monitoring meldet:

Webserver nicht erreichbar.

Die CMDB zeigt:

Dadurch kann der Incident schneller bewertet werden.

Impact Analysis

Die Auswirkungen einer Störung lassen sich mithilfe der Beziehungen zwischen Configuration Items bestimmen.

Beispiel:

Storage
    │
    ▼
Datenbank
    │
    ▼
ERP-System
    │
    ▼
Produktion

Fällt das Storage-System aus,

sind mehrere Services betroffen.

Dadurch steigt die Priorität des Incidents.

Root Cause Analysis

Auch Problem Management nutzt die Beziehungen der CMDB.

Beispiel:

Mehrere Incidents betreffen:

Die CMDB zeigt,

dass alle dieselbe Datenbank verwenden.

Dadurch lässt sich die eigentliche Ursache schneller identifizieren.

Service Configuration Management und Problem Management

Problem Management untersucht wiederkehrende Ursachen.

Configuration-Daten helfen beispielsweise dabei,

Je vollständiger die CMDB,

desto effizienter wird die Ursachenanalyse.

Known Errors

Wird eine Ursache dauerhaft dokumentiert,

kann sie mit betroffenen Configuration Items verknüpft werden.

Beispiel:

Known Error
      │
      ▼
Firmware-Version 4.2.1
      │
      ▼
Switch-Serie XY

Dadurch lassen sich ähnliche Vorfälle schneller erkennen.

Service Configuration Management und Change Enablement

Changes verändern häufig Configuration Items.

Beispiele:

Nach jedem erfolgreichen Change sollte die CMDB aktualisiert werden.

Vor einem Change

Vor einer Änderung beantwortet die CMDB beispielsweise:

Dadurch sinkt das Risiko von Fehlentscheidungen.

Nach einem Change

Nach erfolgreicher Umsetzung werden beispielsweise aktualisiert:

Dadurch bleibt die CMDB aktuell.

Service Configuration Management und Monitoring

Monitoring überwacht Configuration Items.

Die CMDB beschreibt sie.

Beispiel:

Monitoring erkennt:

Server ausgefallen.

Die CMDB ergänzt:

Erst beide Informationen zusammen ermöglichen eine vollständige Bewertung.

Service Maps

Monitoring und CMDB können gemeinsam Service Maps erzeugen.

Beispiel:

CRM-Service
      │
      ├── Webserver
      ├── API
      ├── Datenbank
      ├── Storage
      └── Firewall

Fällt eine Komponente aus,

werden betroffene Services sofort sichtbar.

Monitoring nach Changes

Nach einem Change überprüft Monitoring beispielsweise:

Configuration Management dokumentiert,

welche Version jetzt produktiv eingesetzt wird.

Monitoring unterstützt Discovery

Discovery-Werkzeuge erkennen:

Die Ergebnisse können anschließend in die CMDB übernommen werden.

Service Configuration Management und Service Level Management

SLA-Ziele beziehen sich häufig auf Services.

Die CMDB beschreibt,

welche Configuration Items zu einem Service gehören.

Dadurch können Verfügbarkeiten und Ausfälle korrekt bewertet werden.

Service Configuration Management und Availability Management

Availability Management benötigt Informationen darüber,

welche Komponenten für einen Service notwendig sind.

Beispiele:

Die CMDB liefert diese Informationen.

Service Configuration Management und Capacity Management

Kapazitätsplanung nutzt unter anderem:

Die CMDB zeigt,

welche Ressourcen vorhanden sind und welchen Services sie zugeordnet sind.

Service Configuration Management und Information Security Management

Viele sicherheitsrelevante Informationen werden mit Configuration Items verknüpft.

Beispiele:

Dadurch lassen sich Risiken gezielter bewerten.

Service Configuration Management und Continual Improvement

Eine gepflegte CMDB unterstützt Verbesserungen.

Beispiele:

Dadurch steigt der Nutzen der gesamten Configuration-Datenbasis.

Praxisbeispiel

Ein Switch wird ersetzt.

Vor dem Change zeigt die CMDB:

Betroffen sind:

Nach erfolgreicher Umsetzung werden:

aktualisiert.

Monitoring bestätigt anschließend,

dass alle Services wieder ordnungsgemäß funktionieren.

Typische Fehler

Fehler 1

Changes werden nicht in der CMDB dokumentiert.

Fehler 2

Incident Management nutzt die CMDB nicht.

Fehler 3

Monitoring kennt keine Servicebeziehungen.

Fehler 4

Discovery-Ergebnisse werden ignoriert.

Fehler 5

Service Maps fehlen.

Fehler 6

Configuration Items besitzen keine Verantwortlichen.

Fehler 7

Problem Management nutzt historische Configuration-Daten nicht.

Fehler 8

Mehrere Systeme besitzen widersprüchliche Informationen.

Fehler 9

SLA-Bewertungen berücksichtigen keine Serviceabhängigkeiten.

Fehler 10

Configuration-Daten werden nur nach größeren Projekten aktualisiert.

Checkliste Zusammenspiel

Checkliste Service Configuration Management

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker pflegen und nutzen Configuration-Daten nahezu täglich.

Typische Aufgaben:

Eine gepflegte CMDB reduziert Suchaufwand, verbessert Entscheidungen und unterstützt nahezu alle ITIL Practices.

Zusammenfassung

Configuration Items verwalten

↓

Beziehungen dokumentieren

↓

Informationen in der CMDB bereitstellen

↓

Incident, Problem und Change unterstützen

↓

Monitoring integrieren

↓

Datenqualität verbessern

↓

Services sicher betreiben

Merksätze

Service Configuration Management liefert Informationen – andere Practices nutzen sie.

Eine aktuelle CMDB beschleunigt Incident-, Problem- und Change-Prozesse.

Monitoring beschreibt den Zustand – die CMDB beschreibt die Struktur.

Service Maps erleichtern Impact- und Ursachenanalysen.

Gute Configuration-Daten sind eine wichtige Grundlage für professionelles IT-Service-Management.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Zusammenhänge entsprechen den Empfehlungen der ITIL-Practices. Service Configuration Management stellt strukturierte Informationen über Services und Configuration Items bereit, die von Incident Management, Problem Management, Change Enablement, Monitoring und weiteren Practices genutzt werden. Die konkrete technische Umsetzung erfolgt organisationsabhängig mithilfe von CMDB-, CMS-, Monitoring- und ITSM-Systemen.

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

12. Service Level Management

12. Service Level Management

12.1 Ziele und Grundlagen des Service Level Management

Kurz erklärt

Service Level Management stellt sicher, dass IT-Services mit den vereinbarten Anforderungen der Kunden und des Unternehmens übereinstimmen.

Dazu werden Serviceziele definiert, überwacht und regelmäßig überprüft.

Ziel ist es, realistische Erwartungen zu vereinbaren, die Servicequalität messbar zu machen und die kontinuierliche Verbesserung der Services zu unterstützen.

Was ist Service Level Management?

Service Level Management ist eine ITIL Practice zur Vereinbarung, Überwachung und Verbesserung der Qualität von IT-Services.

Dabei geht es nicht nur darum,

möglichst kurze Reaktionszeiten einzuhalten.

Viel wichtiger ist,

dass Serviceanbieter und Kunden ein gemeinsames Verständnis darüber entwickeln,

welche Leistungen erbracht werden und welche Erwartungen realistisch sind.

Warum Service Level Management wichtig ist

Ohne klare Vereinbarungen entstehen häufig Missverständnisse.

Typische Fragen:

Service Level Management beantwortet diese Fragen.

Ziele des Service Level Management

Die wichtigsten Ziele sind:

Servicequalität

Servicequalität beschreibt,

wie gut ein Service die Anforderungen der Benutzer erfüllt.

Dabei spielen verschiedene Faktoren eine Rolle.

Beispiele:

Servicequalität umfasst also deutlich mehr als reine Technik.

Was ist ein Service Level?

Ein Service Level beschreibt das vereinbarte Qualitätsniveau eines Services.

Beispiele:

Service Levels werden gemeinsam vereinbart,

nicht einseitig festgelegt.

Service Level Agreement (SLA)

Ein Service Level Agreement (SLA) dokumentiert die vereinbarten Serviceziele.

Ein SLA beschreibt beispielsweise:

Ein SLA ist keine technische Anleitung,

sondern eine Vereinbarung zwischen Serviceanbieter und Kunde.

Bestandteile eines SLA

Ein typisches SLA enthält:

Je nach Organisation können weitere Inhalte ergänzt werden.

Servicezeiten

Nicht jeder Service muss rund um die Uhr verfügbar sein.

Beispiele:

Service Servicezeit
Büroarbeitsplätze Mo–Fr 08:00–18:00 Uhr
Produktionssystem 24 × 7
Intranet Mo–So 06:00–22:00 Uhr
Testsystem nach Bedarf

Die Servicezeit beeinflusst die Bewertung der Servicequalität.

Verfügbarkeit

Verfügbarkeit beschreibt,

wie lange ein Service innerhalb der vereinbarten Servicezeit nutzbar ist.

Beispiele:

Eine höhere Verfügbarkeit erfordert in der Regel mehr technische und organisatorische Maßnahmen.

Erwartungen abstimmen

Ein häufiges Ziel des Service Level Managements besteht darin,

realistische Erwartungen zu schaffen.

Beispiel:

Ein Fachbereich wünscht:

100 % Verfügbarkeit.

Die IT erläutert,

dass Wartungsfenster, Hardwarefehler oder externe Einflüsse dies praktisch unmöglich machen.

Gemeinsam wird ein realistisches Serviceziel vereinbart.

Messbarkeit

Serviceziele sollten eindeutig messbar sein.

Geeignete Formulierungen:

Ungeeignet sind Formulierungen wie:

Kundenzufriedenheit

Ein Service kann alle technischen Kennzahlen erfüllen

und trotzdem als unzureichend wahrgenommen werden.

Deshalb berücksichtigt Service Level Management auch:

Regelmäßige Reviews

Service Levels werden regelmäßig überprüft.

Dabei wird unter anderem betrachtet:

Service Level Management ist deshalb ein kontinuierlicher Prozess.

Praxisbeispiel

Ein Unternehmen betreibt einen VPN-Service.

Vereinbart wurde:

Monitoring misst die Verfügbarkeit,

Incident Management liefert die Wiederherstellungszeiten

und Service Level Management bewertet,

ob die vereinbarten Ziele eingehalten wurden.

Typische Fehler

Fehler 1

Serviceziele sind nicht messbar.

Fehler 2

Unrealistische Erwartungen.

Fehler 3

Kennzahlen werden nicht überwacht.

Fehler 4

SLA wird nie überprüft.

Fehler 5

Benutzeranforderungen werden nicht berücksichtigt.

Fehler 6

Nur technische Kennzahlen werden betrachtet.

Fehler 7

Verantwortlichkeiten sind unklar.

Fehler 8

Es gibt keine regelmäßigen Service Reviews.

Checkliste Service Level Management

Bedeutung für Fachinformatiker für Systemintegration

Auch wenn Service Level Agreements häufig vom Service Management erstellt werden,

arbeiten Fachinformatiker täglich an deren Einhaltung.

Typische Aufgaben:

Damit leisten sie einen wichtigen Beitrag zur Erfüllung der vereinbarten Serviceziele.

Zusammenfassung

Service definieren

↓

Erwartungen abstimmen

↓

Serviceziele vereinbaren

↓

SLA dokumentieren

↓

Serviceleistung messen

↓

Ergebnisse bewerten

↓

Services kontinuierlich verbessern

Merksätze

Service Level Management schafft gemeinsame Erwartungen.

Ein SLA beschreibt vereinbarte Leistungen – keine technischen Lösungen.

Servicequalität muss messbar sein.

Monitoring liefert die Daten, Service Level Management bewertet sie.

Regelmäßige Reviews sind Grundlage für kontinuierliche Verbesserungen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Ziele und Vorgehensweisen orientieren sich an der ITIL Practice „Service Level Management“. Die konkrete Ausgestaltung von Service Levels und Service Level Agreements hängt von den Anforderungen der jeweiligen Organisation und ihrer Kunden ab.

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

12. Service Level Management

12.2 Service Level Agreements (SLA), Operational Level Agreements (OLA) und Underpinning Agreements (UC)

Kurz erklärt

Damit ein IT-Service zuverlässig erbracht werden kann, reichen Service Level Agreements (SLAs) allein nicht aus.

Zusätzlich werden interne Vereinbarungen zwischen IT-Teams sowie Verträge mit externen Dienstleistern benötigt.

ITIL unterscheidet hierfür drei Ebenen:

Gemeinsam sorgen sie dafür, dass vereinbarte Serviceziele tatsächlich eingehalten werden können.

Warum mehrere Vereinbarungen notwendig sind

Ein Kunde vereinbart beispielsweise:

Der VPN-Service soll innerhalb von vier Stunden wiederhergestellt werden.

Damit dieses Ziel erreicht werden kann,

müssen häufig mehrere interne und externe Stellen zusammenarbeiten.

Beispiele:

Deshalb existieren unterschiedliche Vereinbarungen.

Service Level Agreement (SLA)

Ein SLA ist eine Vereinbarung zwischen dem Serviceanbieter und dem Kunden.

Es beschreibt,

welche Leistungen erbracht werden.

Typische Inhalte:

Das SLA beschreibt die Erwartungen des Kunden.

Operational Level Agreement (OLA)

Ein OLA ist eine interne Vereinbarung innerhalb der Organisation.

Beispiele:

Ein OLA legt fest,

welche Leistungen ein internes Team für andere Teams erbringt.

Der Kunde sieht diese Vereinbarung normalerweise nicht.

Underpinning Agreement (UC)

Ein Underpinning Agreement (UC) ist eine Vereinbarung mit einem externen Dienstleister oder Lieferanten.

Beispiele:

Diese Vereinbarungen unterstützen die Einhaltung des SLA.

Die drei Ebenen

Kunde
   │
   ▼
SLA
   │
   ▼
Interne Teams
   │
   ▼
OLA
   │
   ▼
Externe Lieferanten
   │
   ▼
UC

Alle drei Ebenen müssen zusammenpassen.

Zusammenhang zwischen SLA, OLA und UC

Beispiel:

Das SLA fordert:

Wiederherstellung innerhalb von vier Stunden.

Damit dies möglich ist,

vereinbart das Netzwerk-Team intern:

Analyse innerhalb von einer Stunde.

Der Hardwarelieferant garantiert:

Ersatzhardware innerhalb von zwei Stunden.

Nur wenn alle Vereinbarungen zusammenpassen,

kann das SLA eingehalten werden.

Vergleich

Merkmal SLA OLA UC
Vertragspartner Kunde und Serviceanbieter interne Teams externer Dienstleister
Sichtbar für Kunden Ja Nein normalerweise nein
Ziel Servicequalität vereinbaren interne Zusammenarbeit regeln externe Leistungen absichern

Beispiel: E-Mail-Service

Ein Unternehmen betreibt einen E-Mail-Service.

Das SLA enthält:

Intern existieren OLAs:

Zusätzlich bestehen UCs mit:

Alle Beteiligten tragen gemeinsam zur Servicequalität bei.

Servicezeiten abstimmen

Ein häufiger Fehler:

SLA:

24 × 7

OLA:

Montag bis Freitag

Dadurch kann das SLA praktisch nicht eingehalten werden.

Interne und externe Vereinbarungen müssen deshalb zueinander passen.

Mehrere SLAs

Eine Organisation kann unterschiedliche SLAs besitzen.

Beispiele:

Nicht jeder Service benötigt dieselben Serviceziele.

Serviceklassen

Viele Organisationen definieren verschiedene Serviceklassen.

Beispiel:

Klasse Verfügbarkeit
Bronze 99 %
Silber 99,5 %
Gold 99,9 %
Platin 99,99 %

Je höher die Anforderungen,

desto größer sind meist Aufwand und Kosten.

Verantwortlichkeiten

Ein SLA beschreibt auch,

wer welche Aufgaben übernimmt.

Beispiele:

Serviceanbieter:

Kunde:

Klare Verantwortlichkeiten vermeiden Missverständnisse.

Messverfahren

Ein SLA sollte festlegen,

wie Kennzahlen gemessen werden.

Beispiele:

Nur eindeutig definierte Messverfahren ermöglichen objektive Bewertungen.

Ausnahmen

Nicht jede Unterbrechung zählt automatisch als SLA-Verletzung.

Typische Ausnahmen:

Diese Ausnahmen sollten im SLA eindeutig beschrieben werden.

Review von Vereinbarungen

SLAs, OLAs und UCs sollten regelmäßig überprüft werden.

Fragen dabei sind beispielsweise:

Dadurch bleiben Vereinbarungen aktuell.

Praxisbeispiel

Ein Unternehmen garantiert:

VPN-Service:

Intern besteht ein OLA:

Netzwerk-Team:

Mit dem Internetprovider besteht zusätzlich ein UC:

Alle Vereinbarungen unterstützen gemeinsam die Einhaltung des SLA.

Typische Fehler

Fehler 1

SLA und OLA widersprechen sich.

Fehler 2

Externe Lieferanten erfüllen die Anforderungen nicht.

Fehler 3

Servicezeiten sind unrealistisch.

Fehler 4

Kennzahlen sind nicht messbar.

Fehler 5

Verantwortlichkeiten fehlen.

Fehler 6

Vereinbarungen werden nie überprüft.

Fehler 7

SLA enthält technische Details statt Serviceziele.

Fehler 8

Unterschiedliche Teams kennen die Vereinbarungen nicht.

Checkliste SLA

Checkliste OLA und UC

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker erstellen SLAs meist nicht selbst,

arbeiten jedoch täglich daran,

dass deren Ziele erreicht werden.

Typische Aufgaben:

Dadurch tragen sie direkt zur Einhaltung der Servicequalität bei.

Zusammenfassung

Serviceziele vereinbaren

↓

SLA mit dem Kunden festlegen

↓

OLA zwischen internen Teams abstimmen

↓

UC mit externen Dienstleistern vereinbaren

↓

Servicequalität messen

↓

Regelmäßig überprüfen und verbessern

Merksätze

Das SLA beschreibt die Vereinbarung mit dem Kunden.

Das OLA regelt die Zusammenarbeit innerhalb der Organisation.

Das UC beschreibt Vereinbarungen mit externen Dienstleistern.

Alle drei Ebenen müssen zusammenpassen.

Ein SLA ist nur realistisch, wenn OLA und UC seine Einhaltung unterstützen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

ITIL unterscheidet zwischen Service Level Agreements (SLA), Operational Level Agreements (OLA) und Underpinning Agreements (UC). Gemeinsam stellen sie sicher, dass vereinbarte Serviceziele sowohl intern als auch mit externen Dienstleistern unterstützt werden. Die konkrete Ausgestaltung dieser Vereinbarungen richtet sich nach den Anforderungen der jeweiligen Organisation.

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

12. Service Level Management

12.3 Kennzahlen, Berichte und Service Reviews

Kurz erklärt

Vereinbarte Serviceziele sind nur dann sinnvoll, wenn ihre Einhaltung regelmäßig gemessen und bewertet wird.

Service Level Management nutzt hierfür Kennzahlen (Metrics), Key Performance Indicators (KPIs), Berichte (Reports) und Service Reviews.

Ziel ist es, die tatsächliche Servicequalität objektiv zu bewerten, Verbesserungspotenziale zu erkennen und gemeinsam mit den Kunden geeignete Maßnahmen abzuleiten.

Warum Kennzahlen wichtig sind

Ein Service kann nur verbessert werden,

wenn seine Leistung messbar ist.

Ohne Kennzahlen bleiben viele Aussagen subjektiv.

Beispiele:

Nicht messbar:

Der Support arbeitet schnell.

Messbar:

95 % aller Incidents wurden innerhalb von 30 Minuten angenommen.

Nur messbare Informationen ermöglichen objektive Bewertungen.

Was sind Kennzahlen (Metrics)?

Kennzahlen sind messbare Werte,

die Informationen über einen Service liefern.

Beispiele:

Nicht jede Kennzahl eignet sich automatisch als KPI.

Key Performance Indicators (KPIs)

KPIs sind besonders wichtige Kennzahlen,

mit denen die Zielerreichung bewertet wird.

Beispiele:

KPIs konzentrieren sich auf die wichtigsten Erfolgsfaktoren.

Typische Service-Level-Kennzahlen

Kennzahl Aussage
Verfügbarkeit Wie lange war der Service nutzbar?
Reaktionszeit Wann begann die Bearbeitung?
Wiederherstellungszeit Wann war der Service wieder verfügbar?
SLA-Erfüllung Wurden die vereinbarten Ziele erreicht?
Erstlösungsquote Wie viele Anfragen wurden direkt gelöst?
Kundenzufriedenheit Wie bewerten Benutzer den Service?

Verfügbarkeit messen

Die Verfügbarkeit wird häufig in Prozent angegeben.

Beispiele:

Je höher die gewünschte Verfügbarkeit,

desto größer werden meist Aufwand und Kosten.

Reaktionszeit und Wiederherstellungszeit

Diese beiden Begriffe werden häufig verwechselt.

Reaktionszeit

Zeit zwischen Eingang einer Meldung und Beginn der Bearbeitung.

Wiederherstellungszeit

Zeit bis der Service wieder ordnungsgemäß funktioniert.

Ein Incident kann sehr schnell angenommen,

aber erst deutlich später vollständig behoben werden.

Erstlösungsquote (First Contact Resolution)

Die Erstlösungsquote beschreibt,

wie viele Anfragen bereits beim ersten Kontakt vollständig gelöst werden.

Eine hohe Erstlösungsquote bedeutet häufig:

Sie ist daher eine wichtige Kennzahl für Service Desks.

Kundenzufriedenheit

Technisch erfolgreiche Services führen nicht automatisch zu zufriedenen Benutzern.

Typische Bewertungsmöglichkeiten:

Subjektive Bewertungen ergänzen technische Kennzahlen.

Berichte (Reports)

Kennzahlen werden regelmäßig in Berichten zusammengefasst.

Typische Inhalte:

Berichte richten sich an unterschiedliche Zielgruppen.

Zielgruppen für Berichte

Je nach Rolle unterscheiden sich die Inhalte.

Beispiele:

Zielgruppe Typische Inhalte
Management KPIs, Trends, Risiken
Service Owner SLA-Erfüllung, Verbesserungen
Service Desk Incidents, Service Requests
Kunden Servicequalität, Verfügbarkeit
Administratoren technische Kennzahlen

Jede Zielgruppe benötigt andere Informationen.

Service Reviews

Ein Service Review ist ein regelmäßiges Treffen,

bei dem die Servicequalität bewertet wird.

Typische Fragen:

Service Reviews fördern die Zusammenarbeit zwischen IT und Kunden.

Typischer Ablauf eines Service Reviews

Kennzahlen sammeln
        │
        ▼
Berichte erstellen
        │
        ▼
Service Review durchführen
        │
        ▼
Abweichungen bewerten
        │
        ▼
Verbesserungen beschließen
        │
        ▼
Maßnahmen umsetzen

Service Reviews finden häufig monatlich oder quartalsweise statt.

Abweichungen analysieren

Nicht jede Zielabweichung bedeutet automatisch schlechte Servicequalität.

Beispiele:

Wichtig ist,

die Ursachen zu verstehen,

statt ausschließlich Kennzahlen zu betrachten.

Einzelne Messwerte liefern oft nur eine Momentaufnahme.

Trendanalysen zeigen Entwicklungen.

Beispiele:

Dadurch werden Verbesserungen sichtbar.

Visualisierung

Kennzahlen lassen sich unterschiedlich darstellen.

Beispiele:

Die Darstellung sollte übersichtlich und leicht verständlich sein.

Benchmarking

Organisationen vergleichen ihre Kennzahlen häufig:

Benchmarking hilft,

Verbesserungspotenziale zu erkennen.

Serviceverbesserungen ableiten

Service Reviews sollen konkrete Maßnahmen hervorbringen.

Beispiele:

Kennzahlen dienen also nicht nur der Kontrolle,

sondern vor allem der Verbesserung.

Praxisbeispiel

Ein Unternehmen bewertet seinen VPN-Service.

Ergebnisse:

Im Service Review wird beschlossen,

den Self-Service weiter auszubauen,

um die Anzahl einfacher Supportanfragen zusätzlich zu reduzieren.

Typische Fehler

Fehler 1

Zu viele Kennzahlen.

Fehler 2

KPIs sind nicht eindeutig definiert.

Fehler 3

Kennzahlen werden gemessen,

aber nicht ausgewertet.

Fehler 4

Berichte sind zu technisch.

Fehler 5

Service Reviews finden nicht regelmäßig statt.

Fehler 6

Nur negative Ergebnisse werden betrachtet.

Fehler 7

Kundenzufriedenheit wird nicht gemessen.

Fehler 8

Verbesserungsmaßnahmen werden nicht nachverfolgt.

Checkliste Kennzahlen

Checkliste Service Reviews

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker liefern viele der technischen Informationen,

auf denen Service Reviews basieren.

Typische Aufgaben:

Damit tragen sie direkt zur kontinuierlichen Verbesserung der IT-Services bei.

Zusammenfassung

Serviceleistung messen

↓

Kennzahlen berechnen

↓

Berichte erstellen

↓

Service Review durchführen

↓

Verbesserungen beschließen

↓

Maßnahmen umsetzen

Merksätze

Kennzahlen machen Servicequalität messbar.

KPIs konzentrieren sich auf die wichtigsten Ziele.

Service Reviews dienen der Verbesserung – nicht der Schuldzuweisung.

Gute Berichte unterstützen fundierte Entscheidungen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Kennzahlen, KPIs, Berichte und Service Reviews orientieren sich an den Empfehlungen der ITIL Practice „Service Level Management“. Welche Kennzahlen tatsächlich erhoben werden, richtet sich nach den vereinbarten Servicezielen und den Anforderungen der jeweiligen Organisation.

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

12. Service Level Management

12.4 Kundenzufriedenheit und Continual Improvement

Kurz erklärt

Die Einhaltung von Service Level Agreements allein garantiert noch keinen guten IT-Service.

Service Level Management betrachtet deshalb neben technischen Kennzahlen auch die Zufriedenheit der Benutzer und Kunden.

Die gewonnenen Erkenntnisse fließen anschließend in das Continual Improvement ein, um Services langfristig weiterzuentwickeln.

Warum Kundenzufriedenheit wichtig ist

Ein Service kann alle vereinbarten Kennzahlen erfüllen,

und trotzdem als schlecht wahrgenommen werden.

Beispiel:

Ein Incident wird innerhalb der vereinbarten vier Stunden behoben.

Der Benutzer erhält jedoch während dieser Zeit keinerlei Rückmeldung.

Technisch wurde das SLA erfüllt.

Die wahrgenommene Servicequalität ist dennoch gering.

Servicequalität aus Sicht des Kunden

Kunden bewerten Services häufig nach anderen Kriterien als Administratoren.

Typische Fragen sind:

Diese Aspekte ergänzen technische Kennzahlen.

Objektive und subjektive Bewertung

Servicequalität setzt sich aus beiden Bereichen zusammen.

Objektive Bewertung Subjektive Bewertung
Verfügbarkeit Freundlichkeit
Reaktionszeit Kommunikation
Wiederherstellungszeit Verständlichkeit
SLA-Erfüllung Gesamteindruck
Fehlerrate Zufriedenheit

Beide Sichtweisen sind wichtig.

Kundenzufriedenheit messen

Typische Verfahren:

Die Methode richtet sich nach Service und Organisation.

Customer Satisfaction Score (CSAT)

Der CSAT misst,

wie zufrieden Benutzer unmittelbar nach einer Serviceleistung sind.

Beispiel:

"Wie zufrieden waren Sie mit der Bearbeitung Ihres Incidents?"

Antwortmöglichkeiten:

Der CSAT eignet sich besonders für einzelne Supportfälle.

Net Promoter Score (NPS)

Der NPS bewertet,

wie wahrscheinlich Kunden den Service weiterempfehlen würden.

Typische Frage:

"Wie wahrscheinlich ist es, dass Sie unseren IT-Service weiterempfehlen?"

Bewertung:

0 bis 10 Punkte.

Der NPS betrachtet eher die langfristige Gesamtzufriedenheit.

Feedback ernst nehmen

Nicht jedes negative Feedback bedeutet,

dass Prozesse schlecht funktionieren.

Es kann beispielsweise aufzeigen:

Feedback liefert wichtige Hinweise für Verbesserungen.

Beschwerden analysieren

Beschwerden sollten systematisch ausgewertet werden.

Beispiele:

Dadurch lassen sich wiederkehrende Schwachstellen erkennen.

Verbesserungen priorisieren

Nicht jede Verbesserung besitzt dieselbe Bedeutung.

Typische Kriterien:

Priorisierung hilft,

Ressourcen gezielt einzusetzen.

Continual Improvement

Continual Improvement ist eine eigenständige ITIL Practice.

Ihr Ziel besteht darin,

Services, Prozesse und Arbeitsweisen kontinuierlich weiterzuentwickeln.

Service Level Management liefert dafür wichtige Informationen.

Zusammenspiel

Kennzahlen
      │
      ▼
Feedback
      │
      ▼
Service Review
      │
      ▼
Verbesserungen planen
      │
      ▼
Maßnahmen umsetzen
      │
      ▼
Erneut messen

Verbesserung ist ein fortlaufender Kreislauf.

Typische Verbesserungsmaßnahmen

Beispiele:

Auch kleine Änderungen können die Servicequalität deutlich erhöhen.

Kommunikation verbessern

Benutzer bewerten häufig nicht nur die Lösung,

sondern auch den Umgang während der Bearbeitung.

Wichtige Punkte:

Gute Kommunikation erhöht die Zufriedenheit oft stärker als technische Optimierungen.

Erfolge sichtbar machen

Verbesserungen sollten dokumentiert und kommuniziert werden.

Beispiele:

Dadurch wird der Nutzen des Continual Improvement sichtbar.

Langfristige Entwicklung beobachten

Einzelne Umfragen liefern nur Momentaufnahmen.

Erst langfristige Entwicklungen zeigen,

ob Verbesserungen tatsächlich wirken.

Beispiele:

Trendanalysen sind deshalb besonders wertvoll.

Praxisbeispiel

Eine Umfrage zeigt,

dass Benutzer zwar mit der technischen Lösung zufrieden sind,

aber häufig fehlende Statusinformationen bemängeln.

Daraufhin führt die IT automatische Statusmeldungen im Ticketsystem ein.

Bei der nächsten Befragung steigt die Kundenzufriedenheit deutlich,

obwohl sich die technischen Kennzahlen kaum verändert haben.

Typische Fehler

Fehler 1

Nur SLA-Kennzahlen werden betrachtet.

Fehler 2

Benutzerfeedback wird ignoriert.

Fehler 3

Umfragen finden nur selten statt.

Fehler 4

Verbesserungsmaßnahmen werden nicht umgesetzt.

Fehler 5

Kommunikation wird unterschätzt.

Fehler 6

Nur negatives Feedback wird ausgewertet.

Fehler 7

Verbesserungen werden nicht gemessen.

Fehler 8

Es gibt keine Verantwortlichen für Verbesserungsmaßnahmen.

Checkliste Kundenzufriedenheit

Checkliste Continual Improvement

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker tragen wesentlich zur Verbesserung der Servicequalität bei.

Typische Aufgaben:

Viele Verbesserungen entstehen direkt aus den Erfahrungen des täglichen IT-Betriebs.

Zusammenfassung

Serviceleistung messen

↓

Benutzerfeedback einholen

↓

Ergebnisse auswerten

↓

Verbesserungen planen

↓

Maßnahmen umsetzen

↓

Erfolg erneut messen

Merksätze

SLA-Erfüllung bedeutet nicht automatisch zufriedene Benutzer.

Kommunikation beeinflusst die wahrgenommene Servicequalität erheblich.

Feedback ist eine wichtige Grundlage für Verbesserungen.

Continual Improvement ist ein fortlaufender Prozess.

Jede Verbesserung sollte anschließend erneut bewertet werden.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Verfahren zur Messung der Kundenzufriedenheit und zur kontinuierlichen Verbesserung orientieren sich an den Empfehlungen der ITIL Practices „Service Level Management“ und „Continual Improvement“. Die Auswahl geeigneter Kennzahlen, Umfragen und Verbesserungsmaßnahmen richtet sich nach den Anforderungen der jeweiligen Organisation und ihrer Kunden.

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

12. Service Level Management

12.5 Zusammenspiel mit Incident, Problem, Change und Monitoring

Kurz erklärt

Service Level Management arbeitet nicht isoliert.

Die Einhaltung vereinbarter Serviceziele ist nur möglich, wenn verschiedene ITIL Practices eng zusammenarbeiten.

Incident Management, Problem Management, Change Enablement, Monitoring and Event Management sowie Continual Improvement liefern die Informationen und Maßnahmen, die zur Erfüllung der Service Levels notwendig sind.

Service Level Management bewertet diese Ergebnisse und entwickelt die Services gemeinsam mit Kunden und Fachbereichen kontinuierlich weiter.

Warum das Zusammenspiel wichtig ist

Ein Service Level Agreement beschreibt,

welche Leistungen vereinbart wurden.

Es sorgt jedoch nicht selbst dafür,

dass diese Leistungen erbracht werden.

Dafür arbeiten mehrere ITIL Practices zusammen.

Zusammenspiel der Practices

Monitoring
      │
      ▼
Incident Management
      │
      ▼
Problem Management
      │
      ▼
Change Enablement
      │
      ▼
Service Level Management
      │
      ▼
Continual Improvement

Jede Practice erfüllt dabei eine eigene Aufgabe.

Service Level Management und Incident Management

Incident Management stellt den normalen Betrieb möglichst schnell wieder her.

Service Level Management bewertet anschließend,

ob dabei die vereinbarten Ziele eingehalten wurden.

Beispiele:

Incident Management arbeitet operativ.

Service Level Management bewertet die Ergebnisse.

Beispiel

SLA:

Ein Incident wird

nach 20 Minuten angenommen

und nach drei Stunden behoben.

Service Level Management bewertet:

SLA erfüllt.

Service Level Management und Problem Management

Wiederkehrende SLA-Verletzungen können auf tieferliegende Probleme hinweisen.

Beispiele:

Problem Management untersucht anschließend die eigentliche Ursache.

Service Level Management und Change Enablement

Viele Verbesserungen der Servicequalität erfolgen über Changes.

Beispiele:

Service Level Management zeigt,

welche Verbesserungen notwendig sind.

Change Enablement setzt sie kontrolliert um.

Monitoring and Event Management

Monitoring liefert die Messwerte,

auf denen viele SLA-Kennzahlen basieren.

Beispiele:

Ohne Monitoring wären objektive Bewertungen kaum möglich.

Beispiel

Monitoring misst:

SLA fordert:

99,90 %

Service Level Management bewertet:

SLA erfüllt.

Service Configuration Management

Service Configuration Management beschreibt,

welche Configuration Items zu einem Service gehören.

Dadurch lässt sich feststellen,

welche Ausfälle tatsächlich den vereinbarten Service beeinflussen.

Außerdem unterstützt die CMDB:

Availability Management

Availability Management entwickelt Maßnahmen,

um die Verfügbarkeit eines Services zu erhöhen.

Beispiele:

Service Level Management bewertet anschließend,

ob die vereinbarten Verfügbarkeitsziele erreicht wurden.

Capacity and Performance Management

Kapazitätsengpässe können SLA-Verletzungen verursachen.

Capacity and Performance Management überwacht beispielsweise:

Service Level Management erkennt anhand der Kennzahlen,

wann zusätzliche Ressourcen notwendig werden.

Information Security Management

Auch Sicherheitsmaßnahmen beeinflussen Service Levels.

Beispiele:

Ein ausgewogenes Verhältnis zwischen Sicherheit und Benutzerfreundlichkeit ist wichtig.

Supplier Management

Externe Dienstleister beeinflussen häufig direkt die Servicequalität.

Beispiele:

Service Level Management überprüft,

ob externe Leistungen die vereinbarten Serviceziele unterstützen.

Continual Improvement

Service Reviews liefern Verbesserungspotenziale.

Diese fließen anschließend in Continual Improvement ein.

Beispiele:

Servicequalität wird dadurch kontinuierlich verbessert.

Informationsfluss

Monitoring
      │
      ▼
Kennzahlen
      │
      ▼
Service Review
      │
      ▼
Verbesserungsmaßnahmen
      │
      ▼
Change Enablement
      │
      ▼
Monitoring überprüft Ergebnis

Dadurch entsteht ein geschlossener Verbesserungszyklus.

Praxisbeispiel

Ein Unternehmen stellt fest,

dass die Wiederherstellungszeit des VPN-Services regelmäßig das SLA überschreitet.

Monitoring liefert die Messdaten.

Incident Management dokumentiert die Bearbeitungszeiten.

Problem Management erkennt,

dass ein einzelner VPN-Gateway überlastet ist.

Change Enablement führt einen zweiten Gateway ein.

Monitoring bestätigt anschließend,

dass die Wiederherstellungszeit deutlich sinkt.

Im nächsten Service Review wird festgestellt,

dass das SLA nun wieder zuverlässig eingehalten wird.

Typische Fehler

Fehler 1

Service Level Management betrachtet nur SLA-Kennzahlen.

Fehler 2

Monitoring liefert unvollständige Daten.

Fehler 3

Problem Management wird nicht einbezogen.

Fehler 4

Verbesserungen werden nicht umgesetzt.

Fehler 5

Changes berücksichtigen Serviceziele nicht.

Fehler 6

Supplier erfüllen vereinbarte Leistungen nicht.

Fehler 7

Service Reviews führen zu keinen Maßnahmen.

Fehler 8

Service Levels werden nach Änderungen nicht angepasst.

Fehler 9

Configuration-Daten sind veraltet.

Fehler 10

Kennzahlen werden gemessen,

aber nicht zur Verbesserung genutzt.

Checkliste Zusammenspiel

Checkliste Service Level Management

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker tragen täglich zur Einhaltung der Service Levels bei.

Typische Aufgaben:

Damit unterstützen sie direkt die vereinbarte Servicequalität.

Zusammenfassung

Monitoring liefert Kennzahlen

↓

Incident Management stellt Services wieder her

↓

Problem Management beseitigt Ursachen

↓

Change Enablement setzt Verbesserungen um

↓

Service Level Management bewertet die Ergebnisse

↓

Continual Improvement entwickelt den Service weiter

Merksätze

Service Level Management bewertet Leistungen – andere Practices erbringen sie.

Monitoring liefert die Messwerte für SLA-Bewertungen.

Problem Management reduziert zukünftige SLA-Verletzungen.

Service Reviews bilden die Grundlage für kontinuierliche Verbesserungen.

Gute Servicequalität entsteht nur durch das Zusammenspiel mehrerer ITIL Practices.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Zusammenhänge entsprechen den Empfehlungen der ITIL-Practices. Service Level Management bewertet die Einhaltung vereinbarter Serviceziele, während andere Practices die technischen und organisatorischen Voraussetzungen schaffen. Erst ihr Zusammenspiel ermöglicht eine dauerhaft hohe Servicequalität.

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

13. Change Enablement

13. Change Enablement

13.1 Ziele und Grundlagen des Change Enablement

Kurz erklärt

Änderungen an IT-Systemen gehören zum Alltag jeder Organisation.

Neue Software wird installiert, Server aktualisiert, Sicherheitslücken geschlossen oder Cloud-Dienste erweitert.

Ziel des Change Enablement ist es, diese Änderungen kontrolliert, nachvollziehbar und mit möglichst geringem Risiko umzusetzen.

Dabei sollen notwendige Veränderungen ermöglicht werden, ohne die Stabilität der IT-Services unnötig zu gefährden.

Was ist Change Enablement?

Change Enablement ist eine ITIL Practice zur Steuerung und Unterstützung von Änderungen an Services und Configuration Items.

Sie sorgt dafür,

dass Änderungen:

und dokumentiert werden.

Warum heißt es nicht mehr Change Management?

Frühere ITIL-Versionen verwendeten den Begriff:

Change Management

Seit ITIL 4 lautet die offizielle Bezeichnung:

Change Enablement

Der neue Name verdeutlicht,

dass Änderungen nicht verhindert,

sondern sicher und effizient ermöglicht werden sollen.

Warum Änderungen notwendig sind

Ohne Änderungen wäre eine moderne IT nicht dauerhaft funktionsfähig.

Typische Gründe:

Veränderungen gehören zum normalen IT-Betrieb.

Ziele des Change Enablement

Die wichtigsten Ziele sind:

Was ist ein Change?

Ein Change ist jede geplante Änderung,

die Auswirkungen auf Services oder Configuration Items haben kann.

Beispiele:

Nicht jede technische Tätigkeit ist automatisch ein Change.

Change ist nicht gleich Incident

Diese Begriffe werden häufig verwechselt.

Incident Change
ungeplante Störung geplante Änderung
Ziel: Service wiederherstellen Ziel: Service verbessern oder anpassen
häufig Zeitdruck normalerweise geplant
reaktive Tätigkeit proaktive Tätigkeit

Ein Incident kann später einen Change erforderlich machen.

Beispiel

Ein Server fällt regelmäßig aus.

Incident Management stellt den Betrieb mehrfach wieder her.

Problem Management findet die Ursache.

Zur dauerhaften Lösung wird:

Diese geplante Änderung ist ein Change.

Grundprinzip des Change Enablement

Jede Änderung sollte beantwortete Fragen besitzen:

Typischer Ablauf

Änderungsbedarf
       │
       ▼
Bewertung
       │
       ▼
Risikoanalyse
       │
       ▼
Genehmigung
       │
       ▼
Umsetzung
       │
       ▼
Überprüfung
       │
       ▼
Abschluss

Nicht jeder Change durchläuft alle Schritte mit demselben Aufwand.

Warum Risiken bewertet werden

Jede Änderung kann unbeabsichtigte Auswirkungen haben.

Beispiele:

Deshalb bewertet Change Enablement Risiken bereits vor der Umsetzung.

Nutzen strukturierter Changes

Ein geregelter Change-Prozess sorgt unter anderem für:

Dadurch steigt die Stabilität der IT.

Nicht jede Änderung ist gleich kritisch

Beispiele:

Geringes Risiko:

Hohes Risiko:

Je größer die Auswirkungen,

desto sorgfältiger erfolgt Planung und Bewertung.

Verantwortlichkeiten

An einem Change können verschiedene Rollen beteiligt sein.

Beispiele:

Nicht jede Organisation verwendet alle Rollen.

Dokumentation

Jeder Change sollte nachvollziehbar dokumentiert werden.

Typische Inhalte:

Eine gute Dokumentation erleichtert spätere Analysen.

Praxisbeispiel

Ein Unternehmen möchte den VPN-Server aktualisieren.

Vor der Umsetzung werden:

Nach erfolgreicher Aktualisierung bestätigt das Monitoring,

dass der Service wieder ordnungsgemäß funktioniert.

Typische Fehler

Fehler 1

Änderungen erfolgen ohne Planung.

Fehler 2

Risiken werden nicht bewertet.

Fehler 3

Es existiert kein Rollback.

Fehler 4

Benutzer werden nicht informiert.

Fehler 5

Änderungen werden nicht dokumentiert.

Fehler 6

Monitoring prüft das Ergebnis nicht.

Fehler 7

Configuration-Daten werden nicht aktualisiert.

Fehler 8

Changes werden direkt in der Produktion getestet.

Checkliste Change Enablement

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker setzen täglich Changes um.

Typische Aufgaben:

Ein strukturierter Change-Prozess reduziert Ausfälle und erhöht die Stabilität der IT.

Zusammenfassung

Änderungsbedarf erkennen

↓

Risiken bewerten

↓

Genehmigung einholen

↓

Änderung umsetzen

↓

Ergebnis überprüfen

↓

Dokumentieren und abschließen

Merksätze

Change Enablement ermöglicht Veränderungen – es verhindert sie nicht.

Jede Änderung sollte geplant und bewertet werden.

Je höher das Risiko, desto sorgfältiger die Vorbereitung.

Ein Rollback gehört zu jeder kritischen Änderung.

Gute Dokumentation unterstützt zukünftige Changes.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Grundlagen orientieren sich an der ITIL Practice „Change Enablement“. ITIL definiert Grundprinzipien für die kontrollierte Durchführung von Änderungen, schreibt jedoch keinen starren Prozess vor. Die konkrete Umsetzung richtet sich nach Größe, Risiken und Anforderungen der jeweiligen Organisation.

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

13. Change Enablement

13.2 Change-Typen und Risikobewertung

Kurz erklärt

Nicht jede Änderung besitzt dasselbe Risiko oder denselben Aufwand.

Deshalb unterscheidet ITIL verschiedene Change-Typen.

Je nach Risiko, Auswirkungen und Dringlichkeit unterscheiden sich Planung, Genehmigung und Durchführung.

Ziel ist es, einfache Änderungen möglichst effizient und risikoreiche Änderungen besonders sorgfältig umzusetzen.

Warum verschiedene Change-Typen?

Eine kleine Änderung,

wie das Aktualisieren einer Druckersoftware,

benötigt deutlich weniger Planung als die Migration eines Active Directory.

Würden beide Änderungen denselben Prozess durchlaufen,

wäre der Aufwand unnötig hoch.

Deshalb unterscheidet ITIL verschiedene Change-Typen.

Die drei Change-Typen nach ITIL

ITIL Version 5 unterscheidet grundsätzlich:

Change-Typ Beschreibung
Standard Change geringes Risiko, vorab genehmigt
Normal Change individuelle Bewertung und Genehmigung erforderlich
Emergency Change schnelle Umsetzung wegen dringender Situation

Diese Einteilung richtet sich nach Risiko und Auswirkungen,

nicht nach der technischen Komplexität.

Standard Change

Ein Standard Change ist:

Für jede Durchführung ist normalerweise keine neue Genehmigung erforderlich.

Beispiele für Standard Changes

Mögliche Standard Changes:

Diese Änderungen folgen meist einem festen Ablauf.

Eigenschaften eines Standard Change

Ein Standard Change besitzt:

Dadurch kann er effizient umgesetzt werden.

Normal Change

Ein Normal Change ist die häufigste Form einer Änderung.

Er wird individuell bewertet.

Dabei werden unter anderem betrachtet:

Beispiele für Normal Changes

Typische Beispiele:

Diese Änderungen benötigen meist eine individuelle Planung.

Emergency Change

Ein Emergency Change dient dazu,

eine akute Gefahr oder Störung schnell zu beseitigen.

Dabei wird der normale Genehmigungsprozess verkürzt,

nicht jedoch vollständig ausgelassen.

Beispiele für Emergency Changes

Typische Situationen:

Hier steht die schnelle Wiederherstellung des Betriebs im Vordergrund.

Emergency bedeutet nicht ungeplant

Auch Emergency Changes sollten soweit möglich:

werden.

Lediglich der Zeitdruck ist deutlich höher.

Vergleich der Change-Typen

Merkmal Standard Normal Emergency
Risiko gering unterschiedlich häufig hoch
Genehmigung vorab individuell beschleunigt
Planung standardisiert individuell verkürzt
Dokumentation erforderlich erforderlich ebenfalls erforderlich

Risikobewertung

Vor jeder Änderung sollte bewertet werden,

welche Risiken bestehen.

Typische Fragen:

Die Risikobewertung unterstützt fundierte Entscheidungen.

Risikofaktoren

Beispiele für Risikofaktoren:

Je mehr Risikofaktoren vorliegen,

desto sorgfältiger sollte geplant werden.

Business Impact

Neben technischen Risiken wird auch der geschäftliche Einfluss bewertet.

Beispiele:

Gering:

Mittel:

Hoch:

Business Impact und technisches Risiko sind nicht immer identisch.

Wahrscheinlichkeit und Auswirkung

Risiken werden häufig anhand zweier Kriterien bewertet:

Beispiel:

Wahrscheinlichkeit Auswirkung Risiko
gering gering niedrig
hoch gering mittel
gering hoch mittel
hoch hoch hoch

Diese Bewertung unterstützt die Entscheidung über notwendige Maßnahmen.

Risikomatrix

Eine vereinfachte Risikomatrix:

                Auswirkung
            Niedrig  Mittel  Hoch
Niedrig       🟢       🟢      🟡
Mittel        🟢       🟡      🟠
Hoch          🟡       🟠      🔴

Je höher das Risiko,

desto umfangreicher sollten Planung und Genehmigung sein.

Risikominimierung

Risiken lassen sich häufig reduzieren.

Beispiele:

Ziel ist nicht,

jedes Risiko vollständig auszuschließen,

sondern es auf ein akzeptables Maß zu reduzieren.

Rest-Risiko

Auch nach sorgfältiger Planung bleibt häufig ein Restrisiko bestehen.

Beispiel:

Ein Betriebssystem-Update wurde erfolgreich getestet.

Trotzdem kann es in der Produktivumgebung zu unerwarteten Problemen kommen.

Deshalb gehören Rollback und Monitoring zu jeder kritischen Änderung.

Praxisbeispiel

Ein Unternehmen plant ein Firmware-Update für zentrale Switches.

Die Bewertung ergibt:

Der Change wird als Normal Change durchgeführt.

Das Wartungsfenster wird nachts geplant,

Monitoring überwacht die Umsetzung

und bei Problemen steht ein Rollback bereit.

Typische Fehler

Fehler 1

Alle Änderungen werden gleich behandelt.

Fehler 2

Risiken werden nicht dokumentiert.

Fehler 3

Business Impact wird unterschätzt.

Fehler 4

Emergency Changes werden nicht nachbereitet.

Fehler 5

Standard Changes werden nie überprüft.

Fehler 6

Es existiert kein Rollback.

Fehler 7

Tests fehlen.

Fehler 8

Benutzer werden nicht informiert.

Fehler 9

Monitoring überwacht den Change nicht.

Fehler 10

Risikobewertung erfolgt nur technisch,

nicht geschäftlich.

Checkliste Risikobewertung

Checkliste Change-Typen

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker bewerten und begleiten regelmäßig Änderungen.

Typische Aufgaben:

Eine realistische Risikobewertung gehört zu den wichtigsten Voraussetzungen erfolgreicher Changes.

Zusammenfassung

Änderungsbedarf erkennen

↓

Change-Typ bestimmen

↓

Risiken bewerten

↓

Business Impact analysieren

↓

Maßnahmen planen

↓

Genehmigung vorbereiten

Merksätze

Nicht jede Änderung benötigt denselben Aufwand.

Standard Changes sind vorab genehmigt und risikoarm.

Normal Changes werden individuell bewertet.

Emergency Changes beschleunigen den Prozess – sie ersetzen ihn nicht.

Jede Risikobewertung sollte technische und geschäftliche Auswirkungen berücksichtigen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Change-Typen und Verfahren zur Risikobewertung entsprechen den Empfehlungen der ITIL Practice „Change Enablement“. ITIL schreibt keine feste Risikomatrix oder konkrete Bewertungsmethode vor. Organisationen definieren diese entsprechend ihrer Geschäftsanforderungen und ihrer Risikobereitschaft.

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

13. Change Enablement

13.3 Genehmigungen, Change Authority, CAB und Change-Kalender

Kurz erklärt

Nicht jede Änderung darf sofort umgesetzt werden.

Abhängig vom Risiko, den Auswirkungen und der Bedeutung eines Changes müssen geeignete Personen oder Gremien über dessen Durchführung entscheiden.

ITIL verwendet hierfür den Begriff Change Authority.

Zusätzlich unterstützen ein Change Advisory Board (CAB) sowie ein Change-Kalender die koordinierte Planung und Durchführung von Änderungen.

Warum Genehmigungen notwendig sind

Änderungen können erhebliche Auswirkungen auf IT-Services haben.

Beispiele:

Deshalb sollte vor der Umsetzung geprüft werden,

ob der erwartete Nutzen die möglichen Risiken rechtfertigt.

Was ist eine Change Authority?

Die Change Authority ist die Person oder Gruppe,

die über einen Change entscheidet.

ITIL schreibt keine feste Rolle vor.

Je nach Organisation kann dies beispielsweise sein:

Die Entscheidung richtet sich nach Risiko und Auswirkungen des Changes.

Nicht jeder Change benötigt dieselbe Genehmigung

Ein Standard Change ist bereits vorab genehmigt.

Ein Normal Change benötigt häufig eine individuelle Freigabe.

Ein Emergency Change nutzt meist ein beschleunigtes Genehmigungsverfahren.

Die Genehmigung sollte immer zum Risiko passen.

Genehmigungen nach Risiko

Ein mögliches Beispiel:

Risiko Mögliche Change Authority
gering Teamleitung
mittel Change Manager
hoch Change Authority oder CAB
sehr hoch Management oder Geschäftsleitung

Die konkrete Zuordnung legt jede Organisation selbst fest.

Was ist ein Change Advisory Board (CAB)?

Ein Change Advisory Board (CAB) ist ein beratendes Gremium.

Es unterstützt die Change Authority,

indem es Änderungen bewertet und Empfehlungen ausspricht.

Das CAB entscheidet nicht automatisch selbst über jeden Change.

Die endgültige Entscheidung trifft die zuständige Change Authority.

Aufgaben des CAB

Das CAB unterstützt beispielsweise bei:

Dadurch verbessert sich die Qualität von Entscheidungen.

Mögliche Teilnehmer eines CAB

Je nach Change können unterschiedliche Personen beteiligt sein.

Beispiele:

Nicht jeder Teilnehmer ist bei jedem Change erforderlich.

Emergency CAB (ECAB)

Für besonders dringende Änderungen kann ein Emergency Change Advisory Board (ECAB) eingesetzt werden.

Es besteht meist aus wenigen entscheidungsbefugten Personen.

Dadurch können dringende Entscheidungen schneller getroffen werden.

Typische Situationen:

Der Change-Kalender

Ein Change-Kalender dokumentiert,

wann geplante Änderungen stattfinden.

Typische Informationen:

Dadurch lassen sich Überschneidungen vermeiden.

Vorteile eines Change-Kalenders

Ein Change-Kalender hilft dabei,

Er verbessert die Übersicht über geplante Änderungen.

Beispiel eines Change-Kalenders

Datum Service Art des Changes
12.09. VPN Softwareupdate
13.09. ERP Datenbankupdate
14.09. Firewall Firmwareupdate
15.09. WLAN Controller-Aktualisierung

So erkennen Administratoren frühzeitig mögliche Konflikte.

Warum Terminüberschneidungen problematisch sind

Werden mehrere kritische Änderungen gleichzeitig durchgeführt,

kann dies zu Problemen führen.

Beispiel:

am selben Abend.

Bei einer Störung wird die Ursachenanalyse deutlich erschwert.

Der Change-Kalender hilft,

solche Situationen zu vermeiden.

Wartungsfenster

Viele Changes werden innerhalb geplanter Wartungsfenster durchgeführt.

Typische Vorteile:

Wartungsfenster sollten frühzeitig angekündigt werden.

Kommunikation vor einem Change

Vor größeren Änderungen sollten relevante Personen informiert werden.

Beispiele:

Die Information sollte unter anderem enthalten:

Dokumentation der Genehmigung

Jede Genehmigung sollte nachvollziehbar dokumentiert werden.

Beispiele:

Dadurch bleiben Entscheidungen transparent.

Praxisbeispiel

Ein Unternehmen plant,

die Firmware aller Core-Switches zu aktualisieren.

Die Risikobewertung ergibt:

Der Change wird:

Alle betroffenen Fachbereiche werden vorab informiert.

Typische Fehler

Fehler 1

Änderungen werden ohne Genehmigung durchgeführt.

Fehler 2

Der Change-Kalender wird nicht gepflegt.

Fehler 3

Mehrere kritische Changes finden gleichzeitig statt.

Fehler 4

Das falsche Entscheidungsgremium wird beteiligt.

Fehler 5

Emergency Changes werden nicht dokumentiert.

Fehler 6

Benutzer werden nicht informiert.

Fehler 7

Genehmigungen sind nicht nachvollziehbar.

Fehler 8

Wartungsfenster werden nicht eingehalten.

Fehler 9

Externe Dienstleister werden zu spät eingebunden.

Fehler 10

CAB-Sitzungen beschäftigen sich mit Standard Changes,

die bereits vorab genehmigt sind.

Checkliste Genehmigung

Checkliste Change-Kalender

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker sind häufig an der Vorbereitung und Umsetzung von Changes beteiligt.

Typische Aufgaben:

Sie liefern wichtige Entscheidungsgrundlagen für die Change Authority.

Zusammenfassung

Change planen

↓

Risiko bewerten

↓

Change Authority bestimmen

↓

Genehmigung einholen

↓

Change-Kalender aktualisieren

↓

Beteiligte informieren

↓

Umsetzung vorbereiten

Merksätze

Die Change Authority entscheidet über einen Change.

Das CAB unterstützt die Entscheidung – es ersetzt sie nicht.

Standard Changes benötigen normalerweise keine erneute Genehmigung.

Ein gepflegter Change-Kalender verhindert Konflikte zwischen Änderungen.

Gute Kommunikation reduziert Risiken und Überraschungen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

ITIL verwendet den Begriff Change Authority für die Person oder Gruppe, die einen Change genehmigt. Ein Change Advisory Board (CAB) besitzt in ITIL eine beratende Funktion und unterstützt die Entscheidungsfindung. Der Einsatz eines CAB, eines Emergency CAB (ECAB) und eines Change-Kalenders richtet sich nach Größe, Komplexität und Risiko der jeweiligen Organisation.

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

13. Change Enablement

13.4 Umsetzung, Tests und Rollback

Kurz erklärt

Nach der Genehmigung beginnt die eigentliche Umsetzung eines Changes.

Ziel ist es, Änderungen kontrolliert, nachvollziehbar und mit möglichst geringem Risiko einzuführen.

Dazu gehören insbesondere sorgfältige Tests, eine geplante Durchführung, eine Überprüfung des Ergebnisses sowie ein vorbereiteter Rollback für den Fall unerwarteter Probleme.

Warum Tests wichtig sind

Auch sorgfältig geplante Änderungen können unerwartete Auswirkungen haben.

Beispiele:

Tests helfen, solche Probleme möglichst früh zu erkennen.

Testumgebungen

Änderungen sollten nach Möglichkeit zuerst in einer Testumgebung geprüft werden.

Typische Umgebungen:

Je ähnlicher die Testumgebung der Produktivumgebung ist,

desto aussagekräftiger sind die Testergebnisse.

Warum nicht direkt in der Produktion testen?

Tests im Produktivsystem können zu:

führen.

Deshalb sollten Änderungen möglichst vorab getestet werden.

Arten von Tests

Je nach Change können unterschiedliche Tests erforderlich sein.

Beispiele:

Nicht jeder Change benötigt alle Testarten.

Funktionstest

Beim Funktionstest wird geprüft,

ob die neue oder geänderte Funktion wie vorgesehen arbeitet.

Beispiel:

Nach einer VPN-Aktualisierung wird getestet,

ob sich Benutzer erfolgreich verbinden können.

Regressionstest

Ein Regressionstest überprüft,

ob bestehende Funktionen nach einer Änderung weiterhin ordnungsgemäß arbeiten.

Beispiel:

Nach einem Datenbankupdate funktionieren weiterhin:

Regressionstests verhindern unbeabsichtigte Nebenwirkungen.

Pilotbetrieb

Bei größeren Änderungen erfolgt häufig zunächst ein Pilotbetrieb.

Dabei wird die Änderung nur für einen kleinen Benutzerkreis eingeführt.

Vorteile:

Nach erfolgreichem Pilotbetrieb erfolgt die Einführung für alle Benutzer.

Wartungsfenster

Produktive Änderungen werden häufig innerhalb geplanter Wartungsfenster umgesetzt.

Vorteile:

Größere Änderungen erfolgen häufig außerhalb der Hauptarbeitszeiten.

Durchführung des Changes

Während der Umsetzung sollten alle Schritte dokumentiert werden.

Typische Inhalte:

Eine vollständige Dokumentation erleichtert spätere Analysen.

Monitoring nach der Umsetzung

Nach Abschluss überwacht das Monitoring,

ob der Service ordnungsgemäß arbeitet.

Beispiele:

Monitoring bestätigt den Erfolg des Changes.

Was ist ein Rollback?

Ein Rollback stellt den vorherigen Zustand wieder her,

wenn der Change nicht erfolgreich war.

Das Ziel besteht darin,

die Auswirkungen eines fehlgeschlagenen Changes möglichst gering zu halten.

Wann wird ein Rollback durchgeführt?

Beispiele:

Nicht jeder Fehler führt sofort zu einem Rollback.

Die Entscheidung richtet sich nach Risiko und Auswirkungen.

Rollback-Plan

Ein Rollback sollte bereits vor Beginn des Changes vorbereitet werden.

Typische Inhalte:

Ein Rollback darf nicht erst während einer Störung geplant werden.

Beispiel eines Rollbacks

Neues Update installieren
          │
          ▼
Tests erfolgreich?
      │
 ┌────┴────┐
 │         │
Ja        Nein
 │         │
 ▼         ▼
Produktiv  Rollback
weiter     durchführen

Ein klar definierter Ablauf verkürzt die Wiederherstellungszeit.

Backups vor einem Change

Vor vielen Änderungen wird ein Backup erstellt.

Beispiele:

Backups erleichtern den Rollback erheblich.

Verifizierung

Nach erfolgreicher Umsetzung wird geprüft,

ob der Change tatsächlich erfolgreich war.

Typische Fragen:

Erst danach gilt der Change als abgeschlossen.

Post Implementation Review (PIR)

Nach größeren Änderungen wird häufig ein Post Implementation Review (PIR) durchgeführt.

Dabei wird bewertet:

Der PIR dient der kontinuierlichen Verbesserung zukünftiger Changes.

Dokumentation aktualisieren

Nach erfolgreichem Change sollten unter anderem aktualisiert werden:

Dadurch bleiben Informationen aktuell.

Praxisbeispiel

Ein Unternehmen aktualisiert seine zentrale Firewall.

Vorher:

Nach der Aktualisierung:

Der Change wird anschließend erfolgreich abgeschlossen.

Typische Fehler

Fehler 1

Änderungen werden direkt produktiv getestet.

Fehler 2

Es existiert kein Rollback.

Fehler 3

Backups fehlen.

Fehler 4

Monitoring überprüft den Change nicht.

Fehler 5

Regressionstests werden ausgelassen.

Fehler 6

Dokumentationen werden nicht aktualisiert.

Fehler 7

Benutzer werden nicht informiert.

Fehler 8

Der Change wird zu früh abgeschlossen.

Fehler 9

Erfahrungen werden nicht ausgewertet.

Fehler 10

Testumgebung unterscheidet sich stark von der Produktivumgebung.

Checkliste Umsetzung

Checkliste Rollback

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker setzen die meisten Changes praktisch um.

Typische Aufgaben:

Eine sorgfältige Umsetzung entscheidet häufig über den Erfolg eines Changes.

Zusammenfassung

Genehmigung erhalten

↓

Tests durchführen

↓

Backup erstellen

↓

Change umsetzen

↓

Monitoring überprüfen

↓

Bei Bedarf Rollback durchführen

↓

Dokumentation aktualisieren

↓

Post Implementation Review durchführen

Merksätze

Änderungen sollten möglichst nicht direkt in der Produktivumgebung getestet werden.

Ein Rollback muss vor Beginn des Changes geplant sein.

Monitoring bestätigt den Erfolg einer Änderung.

Dokumentationen gehören zum Abschluss jedes Changes.

Erfahrungen aus abgeschlossenen Changes verbessern zukünftige Änderungen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die beschriebenen Vorgehensweisen zu Tests, Rollback, Monitoring und Post Implementation Review orientieren sich an den Empfehlungen der ITIL Practice „Change Enablement“. ITIL schreibt keine festen Testverfahren vor, empfiehlt jedoch ausdrücklich eine risikoorientierte Planung, geeignete Testmaßnahmen und eine nachvollziehbare Nachbereitung von Änderungen.

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

13. Change Enablement

13.5 Zusammenspiel mit Incident, Problem, Service Configuration Management und Monitoring

Kurz erklärt

Change Enablement arbeitet eng mit vielen anderen ITIL Practices zusammen.

Änderungen entstehen häufig aus Incidents oder Problems, beeinflussen Configuration Items und werden durch Monitoring überwacht.

Erst das Zusammenspiel dieser Practices ermöglicht sichere Änderungen, stabile IT-Services und eine kontinuierliche Verbesserung der gesamten IT-Landschaft.

Warum das Zusammenspiel wichtig ist

Ein Change wird selten isoliert durchgeführt.

Vor einer Änderung müssen beispielsweise folgende Fragen beantwortet werden:

Diese Informationen stammen aus verschiedenen ITIL Practices.

Zusammenspiel der Practices

Incident
      │
      ▼
Problem
      │
      ▼
Change Enablement
      │
      ▼
Service Configuration Management
      │
      ▼
Monitoring
      │
      ▼
Continual Improvement

Jede Practice liefert wichtige Informationen für die nächste.

Change Enablement und Incident Management

Viele Changes entstehen als Folge eines Incidents.

Beispiel:

Ein Server fällt regelmäßig aus.

Incident Management stellt den Betrieb zunächst wieder her.

Die eigentliche Ursache bleibt jedoch bestehen.

Zur dauerhaften Lösung wird ein Change geplant.

Incident Management arbeitet also häufig kurzfristig,

während Change Enablement eine nachhaltige Verbesserung ermöglicht.

Beispiel

Serverausfall
      │
      ▼
Incident Management
      │
      ▼
Service wiederhergestellt
      │
      ▼
Hardware ersetzen
      │
      ▼
Change Enablement

Der Incident endet mit der Wiederherstellung,

der Change beseitigt anschließend die eigentliche Ursache.

Change Enablement und Problem Management

Problem Management untersucht,

warum Incidents wiederholt auftreten.

Wird eine dauerhafte Lösung gefunden,

führt diese häufig zu einem Change.

Beispiele:

Problem Management liefert also häufig den Anlass für einen Change.

Known Errors

Ein Known Error kann eine empfohlene Änderung enthalten.

Beispiel:

Bekannter Fehler:

Firmware-Version 5.2 verursacht Abstürze.

Empfohlene Lösung:

Firmware-Version 5.3 installieren.

Die eigentliche Umsetzung erfolgt anschließend über Change Enablement.

Change Enablement und Service Configuration Management

Vor jeder Änderung muss bekannt sein,

welche Configuration Items betroffen sind.

Die CMDB liefert beispielsweise:

Dadurch können Auswirkungen besser bewertet werden.

Impact Analysis

Vor einem Change wird häufig geprüft,

welche Services betroffen sind.

Beispiel:

Firewall
     │
     ├── VPN
     ├── Internet
     ├── VoIP
     └── E-Mail

Ein Firmware-Update betrifft somit mehrere Services.

Diese Information stammt aus der CMDB.

CMDB aktualisieren

Nach erfolgreicher Umsetzung werden unter anderem aktualisiert:

Dadurch bleibt die Configuration-Datenbasis aktuell.

Change Enablement und Monitoring

Monitoring überwacht,

ob Änderungen erfolgreich umgesetzt wurden.

Beispiele:

Monitoring bestätigt somit den Erfolg eines Changes.

Monitoring vor einem Change

Auch vor einer Änderung liefert Monitoring wichtige Informationen.

Beispiele:

Diese Informationen unterstützen die Risikobewertung.

Monitoring nach einem Change

Nach der Umsetzung werden häufig überprüft:

Erst wenn diese Prüfungen erfolgreich sind,

gilt der Change als abgeschlossen.

Change Enablement und Release Management

Ein Release kann mehrere Changes enthalten.

Beispiel:

Ein Software-Release umfasst:

Change Enablement bewertet und genehmigt die Änderungen,

Release Management plant und verteilt das Gesamtpaket.

Change Enablement und Deployment Management

Nach der Genehmigung erfolgt häufig die technische Bereitstellung.

Deployment Management übernimmt beispielsweise:

Change Enablement steuert den organisatorischen Rahmen,

Deployment Management die technische Umsetzung.

Change Enablement und Information Security Management

Viele Changes dienen der Verbesserung der Sicherheit.

Beispiele:

Dabei müssen Sicherheitsanforderungen und Serviceverfügbarkeit gleichermaßen berücksichtigt werden.

Change Enablement und Continual Improvement

Erfahrungen aus abgeschlossenen Changes fließen in Continual Improvement ein.

Beispiele:

Dadurch entwickelt sich der Change-Prozess kontinuierlich weiter.

Praxisbeispiel

Ein Unternehmen stellt fest,

dass nach jedem Betriebssystemupdate ähnliche Probleme auftreten.

Problem Management analysiert die Ursache.

Es zeigt sich,

dass wichtige Regressionstests fehlen.

Change Enablement ergänzt daraufhin den Testplan.

Monitoring bestätigt,

dass zukünftige Updates deutlich störungsärmer verlaufen.

Die neue Vorgehensweise wird anschließend als Standardprozess dokumentiert.

Typische Fehler

Fehler 1

Changes werden unabhängig von Incidents geplant.

Fehler 2

Configuration Items werden nicht aktualisiert.

Fehler 3

Monitoring überprüft Änderungen nicht.

Fehler 4

Problem Management wird nicht einbezogen.

Fehler 5

Release und Change werden verwechselt.

Fehler 6

Deployment erfolgt ohne Genehmigung.

Fehler 7

Auswirkungen auf andere Services werden unterschätzt.

Fehler 8

Erfahrungen aus früheren Changes werden nicht genutzt.

Fehler 9

CMDB und Monitoring liefern widersprüchliche Informationen.

Fehler 10

Verbesserungsmaßnahmen werden nicht dokumentiert.

Checkliste Zusammenspiel

Checkliste erfolgreicher Change

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker begleiten nahezu den gesamten Lebenszyklus eines Changes.

Typische Aufgaben:

Dadurch leisten sie einen wesentlichen Beitrag zu einem sicheren und stabilen IT-Betrieb.

Zusammenfassung

Incident erkennen

↓

Ursache analysieren

↓

Change planen

↓

Auswirkungen bewerten

↓

Änderung umsetzen

↓

Monitoring prüfen

↓

CMDB aktualisieren

↓

Verbesserungen übernehmen

Merksätze

Viele Changes entstehen aus Incidents oder Problems.

Die CMDB liefert die Grundlage für Impact-Analysen.

Monitoring bestätigt den Erfolg eines Changes.

Deployment setzt Änderungen technisch um – Change Enablement steuert sie organisatorisch.

Erfahrungen aus abgeschlossenen Changes verbessern zukünftige Änderungen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Zusammenhänge entsprechen den Empfehlungen der ITIL-Practices. Change Enablement koordiniert Änderungen organisatorisch und arbeitet dabei eng mit Incident Management, Problem Management, Service Configuration Management, Monitoring sowie weiteren Practices wie Release und Deployment Management zusammen.

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