2.9 Continual Improvement

Kurz erklärt

Continual Improvement beschreibt die fortlaufende Verbesserung von:

digitalen Produkten,

Services,

Management Practices,

Wertströmen,

Prozessen,

Technologien,

Informationen,

Fähigkeiten,

Zusammenarbeit,

und Erfahrungen der Stakeholder.

Continual Improvement ist:

Bestandteil des ITIL Value Systems,

eine der 34 ITIL Management Practices,

und ein grundlegender Gedanke über den gesamten Product and Service Lifecycle.

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:

veränderte Benutzeranforderungen,
neue Geschäftsziele,
neue Technologien,
technische Schulden,
Sicherheitsrisiken,
neue gesetzliche Anforderungen,
steigende Kosten,
veränderte Lieferantenleistungen,
neue Erkenntnisse aus Incidents,
Rückmeldungen von Benutzern,
und Erfahrungen aus dem laufenden Betrieb.

Auch eine heute wirksame Lösung kann später ungeeignet werden.

Beispiele:

Die Anzahl der Benutzer steigt.
Eine bisher unterstützte Softwareversion erreicht ihr Lebensende.
Ein Lieferant verändert Preise oder Leistungsumfang.
Ein manueller Ablauf verursacht bei wachsender Menge zu viele Fehler.
Eine Sicherheitsanforderung wird verschärft.
Ein Service erreicht technische Zielwerte, wird von Benutzern aber als unzuverlässig wahrgenommen.
Ein Wiederherstellungsverfahren funktioniert unter den aktuellen Bedingungen nicht mehr.
Eine ursprünglich sinnvolle Kontrolle verursacht inzwischen unnötige Wartezeiten.

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:

geplant,
priorisiert,
schrittweise umgesetzt,
unterbrochen,
überprüft,
und später fortgeführt

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:

Guiding Principles,
Governance,
Value Chain Activities,
Management Practices,
und Continual Improvement.

Continual Improvement wirkt dabei nicht nur auf einen einzelnen Bereich.

Verbessert werden können:

das gesamte Value System,
einzelne Management Practices,
Value Streams,
Produkte,
Services,
technische Komponenten,
Organisation und Zusammenarbeit,
Informationen,
Partnerbeziehungen,
und konkrete Arbeitsanweisungen.

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:

klare Verantwortlichkeiten,
geeignete Fähigkeiten,
verfügbare Zeit,
verlässliche Informationen,
Messgrößen,
ein Verbesserungsregister,
Priorisierungskriterien,
Entscheidungsbefugnisse,
Werkzeuge,
Kommunikation,
Wissen,
und regelmäßige Erfolgskontrolle.

Eine Organisation kann mögliche Rollen verwenden wie:

Continual Improvement Manager,
Practice Owner,
Service Owner,
Product Owner,
Improvement Owner,
Improvement Champion,
oder verantwortlicher Teamleiter.

ITIL schreibt nicht für jede Organisation dieselben Rollenbezeichnungen vor.

Entscheidend ist, dass für eine Verbesserungsinitiative geklärt ist:

Wer koordiniert sie?
Wer entscheidet?
Wer setzt Maßnahmen um?
Wer stellt Ressourcen bereit?
Wer misst die Ergebnisse?
Wer verantwortet die nachhaltige Verankerung?

Verbesserung ist Aufgabe aller Beteiligten

Continual Improvement darf nicht ausschließlich einer zentralen Verbesserungsstelle überlassen werden.

Verbesserungsmöglichkeiten können erkannt werden durch:

Benutzer,
Service Desk,
Administratoren,
Entwickler,
Informationssicherheit,
Product Owner,
Service Owner,
Lieferanten,
Führungskräfte,
Fachabteilungen,
und andere Stakeholder.

Beispiele:

Ein Service-Desk-Mitarbeiter erkennt eine häufige Rückfrage.
Ein Administrator erkennt einen fehleranfälligen manuellen Arbeitsschritt.
Ein Benutzer meldet eine unverständliche Servicebeschreibung.
Ein Lieferant weist auf eine neue technische Möglichkeit hin.
Ein Service Owner erkennt eine wiederkehrende Abweichung von einem Serviceziel.
Ein Security-Team erkennt eine unsichere Alttechnologie.
Ein Product Owner erkennt, dass eine Funktion kaum verwendet wird.

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:

verloren gehen,
mehrfach bearbeitet werden,
miteinander konkurrieren,
nur nach persönlicher Vorliebe ausgewählt werden,
ohne ausreichende Daten begonnen werden,
oder nach der Umsetzung nicht überprüft werden.

Eine wirksame Steuerung sorgt dafür, dass Verbesserungsideen:

erfasst,
verstanden,
bewertet,
priorisiert,
verantwortet,
umgesetzt,
gemessen,
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:

die Vision zu präzisieren,
weitere Ausgangsdaten zu erfassen,
den Zielzustand anzupassen,
einen anderen Umsetzungsweg zu wählen,
zusätzliche Maßnahmen aufzunehmen,
oder eine Initiative zu beenden.

Beispiel:

Während der Umsetzung wird festgestellt, dass die angenommene Ursache nicht zutrifft.

Dann kann die Initiative zu folgenden Schritten zurückkehren:

Where are we now?
Where do we want to be?
How do we get there?

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

Pflichtfeld in einem Ticketformular anpassen
veralteten Wissensartikel korrigieren
unnötige Monitoring-Meldung entfernen

Mittlere Verbesserung

Onboarding-Ablauf vereinfachen
Zertifikatsüberwachung einführen
Backup-Tests standardisieren
Incident-Kommunikation verbessern

Größere Verbesserung

neues Ticketsystem einführen
Service Desk neu organisieren
kritischen Service auf eine neue Plattform migrieren
unternehmensweites Identitätsmanagement verbessern

Der Umfang der:

Analyse,
Dokumentation,
Governance,
Messung,
und Kommunikation

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:

Strategie,
Zielen,
Stakeholder-Erwartungen,
Risiken,
Produkten,
Services,
und gewünschten Outcomes.

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:

Anlass der Verbesserung,
betroffene Stakeholder,
gewünschte Outcomes,
strategischen Zusammenhang,
Geltungsbereich,
wichtige Grenzen,
erwarteten Nutzen,
und nicht akzeptierbare Auswirkungen.

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?

Warum ist die Verbesserung notwendig?
Welches Problem oder welche Chance besteht?
Welches Produkt, welcher Service oder welche Practice ist betroffen?
Welche Stakeholder sind relevant?
Welches Outcome wird angestrebt?
Wie unterstützt die Verbesserung die Ziele der Organisation?
Welche Grenzen und Vorgaben gelten?
Welche Risiken dürfen nicht entstehen?
Welche Erwartungen besitzen Führungskräfte und Stakeholder?
Wer muss die Vision unterstützen?
Was gehört ausdrücklich nicht zum Umfang?

Typische Fehler bei der Vision

Verbesserung nur als technische Maßnahme beschreiben
keinen Bezug zu Stakeholdern oder Outcomes herstellen
zu allgemeinen oder unrealistischen Zielzustand formulieren
widersprüchliche Erwartungen nicht klären
Risiken und Grenzen nicht berücksichtigen
mehrere unterschiedliche Probleme in einer Initiative vermischen
Lösung bereits festlegen, bevor der tatsächliche Bedarf verstanden ist

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:

aktuelle Leistung,
bestehende Arbeitsweisen,
vorhandene Fähigkeiten,
Technologien,
Rollen,
Kosten,
Risiken,
Probleme,
Stakeholder-Erfahrung,
und technische Schulden.

Geeignete Informationsquellen

Der Ausgangszustand kann untersucht werden anhand von:

Tickets,
Monitoring-Daten,
Protokollen,
Messwerten,
Benutzerfeedback,
Interviews,
Beobachtungen,
Value Stream Mapping,
Auditergebnissen,
Risikobewertungen,
Lieferantenberichten,
bestehenden Dokumentationen,
Tests,
und Stichproben.

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:

durchschnittliche Durchlaufzeit: fünf Arbeitstage
30 Prozent der Onboardings sind am ersten Arbeitstag unvollständig
monatlich zwölf Incidents wegen abgelaufener Zertifikate
40 Prozent der Tickets benötigen Rückfragen
durchschnittlich vier Teamübergaben pro Incident
Restore-Test war bei zwei von zehn Systemen erfolgreich

Die Baseline sollte:

relevant,
nachvollziehbar,
ausreichend zuverlässig,
und zum gewünschten Outcome passend

sein.

Leitfragen zu Where are we now?

Was geschieht heute tatsächlich?
Welche Daten liegen vor?
Welche Outcomes werden aktuell erreicht?
Was funktioniert bereits gut?
Wo bestehen Probleme?
Welche Risiken und technischen Schulden sind bekannt?
Welche Stakeholder sind betroffen?
Wie wird die heutige Erfahrung wahrgenommen?
Welche Fähigkeiten und Ressourcen stehen zur Verfügung?
Welche Lieferanten und Abhängigkeiten bestehen?
Welche Maßnahmen wurden bereits versucht?
Welche Annahmen müssen überprüft werden?
Welche Baseline kann verwendet werden?

Typische Fehler bei der Ist-Analyse

nur Probleme betrachten und funktionierende Bestandteile ignorieren
ausschließlich leicht verfügbare Kennzahlen verwenden
subjektive Vermutungen als Baseline verwenden
Benutzer- und Kundenerfahrung nicht berücksichtigen
tatsächlichen Ablauf nicht beobachten
Datenqualität nicht prüfen
unterschiedliche Produkt- oder Servicevarianten vermischen
bereits mit der Umsetzung beginnen, bevor die Ausgangslage verstanden ist

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:

verständlich,
realistisch,
relevant,
messbar,
und zeitlich einordenbar

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:

Outcome,
Wert,
Qualität,
Erfahrung,
Risiko,
oder Nachhaltigkeit.

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?

Welches konkrete Outcome soll erreicht werden?
Was soll sich für Stakeholder verändern?
Welche Qualität wird benötigt?
Welche Risiken sollen reduziert werden?
Welche Zielwerte sind sinnvoll?
Welche Fähigkeiten müssen aufgebaut werden?
Welche technischen Schulden sollen reduziert werden?
Welche Grenzen und Vorgaben gelten?
Wann soll der nächste Zielzustand erreicht sein?
Wie wird Erfolg gemessen?
Welche unbeabsichtigten Auswirkungen müssen überwacht werden?
Ist der Zielzustand realistisch und ausreichend unterstützt?

Typische Fehler beim Zielzustand

Ziel nur als Aktivität formulieren
keine Erfolgskriterien definieren
ausschließlich technische Kennzahlen verwenden
unrealistische Zielwerte festlegen
zu viele Ziele gleichzeitig verfolgen
Nebenwirkungen nicht berücksichtigen
nur einen endgültigen Idealzustand statt eines erreichbaren nächsten Zustands beschreiben
Zielwerte festlegen, ohne Baseline zu kennen

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:

Lösungsoptionen,
Maßnahmen,
Prioritäten,
Ressourcen,
Verantwortlichkeiten,
Risiken,
Abhängigkeiten,
Zeitplanung,
Tests,
Kommunikation,
und Messung.

Der Weg kann:

direkt,
schrittweise,
experimentell,
oder explorativ

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:

erwarteter Nutzen
Beitrag zum Outcome
Risiko
Aufwand
Kosten
Dringlichkeit
technische Machbarkeit
organisatorische Machbarkeit
Abhängigkeiten
benötigte Fähigkeiten
Stakeholder-Unterstützung
Nachhaltigkeit
Rückfallmöglichkeit
und Geschwindigkeit des Erkenntnisgewinns

Beispiel:

Problem:

Viele Tickets enthalten unvollständige Informationen.

Mögliche Optionen:

Formular verständlicher gestalten
dynamische Pflichtfelder verwenden
Benutzer mit Beispielen unterstützen
Serviceangebote klarer beschreiben
automatische Plausibilitätsprüfung verwenden
Service-Desk-Mitarbeiter schulen
Eingangskanäle vereinheitlichen

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?

Welche Optionen bestehen?
Welche Maßnahme besitzt den größten erwarteten Nutzen?
Was ist der kleinste sinnvolle nächste Schritt?
Kann ein Pilot oder Experiment verwendet werden?
Welche Ressourcen werden benötigt?
Wer trägt Verantwortung?
Welche Practices sind beteiligt?
Welche Lieferanten werden benötigt?
Welche Risiken und Abhängigkeiten bestehen?
Welche Governance-Entscheidungen sind notwendig?
Wie werden Stakeholder einbezogen?
Wie wird Feedback erhoben?
Wie wird bei Problemen reagiert?
Welche Rückfall- oder Anpassungsmöglichkeit besteht?

Typische Fehler bei der Planung

Maßnahmen auswählen, bevor Ursachen verstanden wurden
ausschließlich eine technische Lösung betrachten
Ressourcen nicht verbindlich bereitstellen
Verantwortlichkeit unklar lassen
zu großen Umfang für eine einzelne Iteration wählen
Kommunikation und Organizational Change Management vergessen
keine Messung einplanen
Abhängigkeiten und Lieferanten nicht berücksichtigen
Verbesserung nebenbei ohne realistische Kapazität erwarten

5. Take action

Zentrale Aufgabe

Die geplanten Maßnahmen kontrolliert und möglichst iterativ umsetzen.

Eine Verbesserung entsteht nicht durch:

Analyse,
Besprechung,
Dokumentation,
oder Aufnahme in ein Register

allein.

Die Maßnahme muss umgesetzt und ihre Wirkung beobachtet werden.

ITIL Version 5 betont bei diesem Schritt ein iteratives Vorgehen mit Möglichkeiten:

Fortschritt zu prüfen,
den Ansatz neu zu bewerten,
und notwendige Anpassungen vorzunehmen.

Iterative Umsetzung

Eine mögliche Vorgehensweise ist:

kleinen sinnvollen Umfang auswählen
Erfolgskriterien festlegen
Maßnahme umsetzen
Ergebnis beobachten
Feedback erfassen
Probleme und Nebenwirkungen untersuchen
Vorgehensweise anpassen
nächste Iteration durchführen

Beispiel: Verbesserung des Monitoring

Iteration 1

einen kritischen Service auswählen
wichtigste Komponenten erfassen
wenige relevante Alarme konfigurieren
Reaktionsweg testen

Auswertung

Werden relevante Störungen erkannt?
Entstehen Fehlalarme?
Erhalten die richtigen Personen die Meldung?
Reichen die Informationen für eine Entscheidung?

Iteration 2

Schwellenwerte verbessern
redundante Events reduzieren
weitere Komponenten einbeziehen
Dokumentation und Eskalation anpassen

Organizational Change Management

Viele Verbesserungen verändern nicht nur Technik.

Sie verändern möglicherweise:

Rollen,
Verantwortlichkeiten,
Gewohnheiten,
Kommunikation,
Arbeitsabläufe,
Werkzeuge,
und Erwartungen.

Deshalb kann Organizational Change Management notwendig sein.

Zu berücksichtigen sind:

verständlicher Zweck,
betroffene Personengruppen,
Kommunikation,
Beteiligung,
Schulung,
Widerstände,
Fähigkeiten,
Unterstützung,
und tatsächliche Anwendung der neuen Arbeitsweise.

Typischer Fehler

Eine neue Arbeitsweise wird technisch bereitgestellt, aber von den Beteiligten nicht verstanden oder verwendet.

Leitfragen zu Take action

Ist der nächste Schritt eindeutig?
Sind Verantwortlichkeiten bekannt?
Sind Ressourcen verfügbar?
Sind Risiken und Rückfallmöglichkeiten berücksichtigt?
Sind Beteiligte informiert?
Ist notwendige Schulung erfolgt?
Kann schrittweise vorgegangen werden?
Wie wird Feedback während der Umsetzung erhoben?
Wie wird der Fortschritt sichtbar gemacht?
Wer entscheidet bei Abweichungen?
Wie werden Erkenntnisse dokumentiert?
Welche Änderungen am Plan sind notwendig?

Typische Fehler bei der Umsetzung

Verbesserung dauerhaft verschieben
zu viele Maßnahmen gleichzeitig beginnen
niemanden eindeutig verantwortlich machen
Beteiligte nicht informieren
Probleme erst am Ende auswerten
am ursprünglichen Plan festhalten, obwohl neue Erkenntnisse vorliegen
nur den technischen Rollout betrachten
keine Zeit für Stabilisierung und Nacharbeit einplanen

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:

der ursprünglichen Baseline,
dem gewünschten Zielzustand,
den Erfolgskriterien,
und der Vision.

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

40 Prozent der Tickets benötigen Rückfragen.
durchschnittliche Bearbeitungsverzögerung: acht Stunden.

Zielzustand

höchstens 15 Prozent benötigen Rückfragen.
durchschnittliche Verzögerung unter zwei Stunden.

Nach der ersten Iteration

25 Prozent benötigen Rückfragen.
durchschnittliche Verzögerung: vier Stunden.

Bewertung:

Die gewünschte Richtung ist erkennbar.
Der Zielzustand ist noch nicht erreicht.
Weitere Untersuchung und Maßnahmen sind notwendig.

Quantitative und qualitative Informationen

Quantitative Informationen:

Zeit,
Anzahl,
Quote,
Kosten,
Ausfallhäufigkeit,
Fehlerquote,
Kapazität,
oder Zielerreichung.

Qualitative Informationen:

Benutzerfeedback,
Mitarbeitererfahrung,
Verständlichkeit,
Vertrauen,
wahrgenommene Einfachheit,
Qualität der Zusammenarbeit,
und beobachtete Hindernisse.

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?

Wurden die geplanten Maßnahmen umgesetzt?
Hat sich der aktuelle Zustand verändert?
Wie verhält er sich zur Baseline?
Werden die gewünschten Outcomes erreicht?
Welche Zielwerte wurden erreicht?
Welche Zielwerte wurden nicht erreicht?
Hat sich die Stakeholder-Erfahrung verändert?
Sind neue Risiken oder Nebenwirkungen entstanden?
Wurde ein Engpass nur verlagert?
Sind Daten ausreichend zuverlässig?
Muss die Initiative angepasst werden?
Sind zusätzliche Maßnahmen notwendig?
Sollte die Initiative beendet oder neu ausgerichtet werden?

Wenn eine Verbesserung nicht wirkt

Mögliche Ursachen:

Problem wurde falsch verstanden.
Baseline war unzuverlässig.
Maßnahme behandelte nur ein Symptom.
Ziel war unrealistisch.
Umsetzung war unvollständig.
Beteiligte verwenden die neue Arbeitsweise nicht.
benötigte Ressourcen fehlen.
technische oder organisatorische Abhängigkeiten wurden übersehen.
externe Bedingungen haben sich verändert.
Messgrößen bilden den tatsächlichen Wert nicht ab.

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:

Mitarbeiter kehren zur alten Arbeitsweise zurück.
Dokumentationen werden nicht aktualisiert.
Verantwortlichkeiten wechseln.
neue Mitarbeiter werden nicht geschult.
Werkzeuge werden anders konfiguriert.
Messung endet unmittelbar nach der Einführung.
andere Veränderungen widersprechen der Verbesserung.
Anforderungen und Risiken verändern sich erneut.

ITIL Version 5 betont deshalb nicht nur das Aufrechterhalten von Dynamik, sondern die fortlaufende Relevanz der Verbesserung.

Verbesserung verankern

Mögliche Maßnahmen:

Verantwortung dauerhaft festlegen
Arbeitsanweisungen aktualisieren
Knowledge-Artikel anpassen
Schulung und Einarbeitung ergänzen
Werkzeuge und Automatisierung aktualisieren
Messgrößen dauerhaft beobachten
Governance-Kontrollen anpassen
Service- und Produktdokumentation aktualisieren
Rollen und Eskalationswege klären
Lieferantenvereinbarungen anpassen
Erkenntnisse in weitere Initiativen übertragen
und regelmäßige Überprüfungstermine festlegen

Knowledge Management

Erkenntnisse sollten so dokumentiert werden, dass andere Beteiligte sie nutzen können.

Dazu können gehören:

Ursachen,
Entscheidungen,
verworfene Optionen,
Testergebnisse,
Messwerte,
bekannte Einschränkungen,
neue Arbeitsweisen,
und gewonnene Erfahrungen.

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:

Ist die manuelle Genehmigung weiterhin notwendig?
Kann sie vereinfacht werden?
Behandelt sie noch ein relevantes Restrisiko?
Erzeugt sie inzwischen unnötige Wartezeit?

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?

Wie wird die neue Arbeitsweise dauerhaft verankert?
Wer trägt langfristig Verantwortung?
Welche Dokumentationen müssen aktualisiert werden?
Welche Fähigkeiten und Schulungen werden benötigt?
Welche Messgrößen werden weiter beobachtet?
Wie wird eine Rückkehr zum alten Zustand erkannt?
Welche Governance-Vorgaben müssen angepasst werden?
Welche Erkenntnisse sollen geteilt werden?
Wann wird die Relevanz erneut geprüft?
Welche Veränderungen könnten die Verbesserung beeinflussen?
Welche weiteren Verbesserungsmöglichkeiten entstehen?
Was wurde aus Fehlern oder Abweichungen gelernt?

Typische Fehler bei der Verankerung

Initiative direkt nach dem technischen Rollout schließen
Messung sofort beenden
Dokumentation nicht aktualisieren
keine dauerhafte Verantwortung festlegen
neue Mitarbeiter nicht berücksichtigen
Lessons Learned erfassen, aber nicht verwenden
Erfolg nicht kommunizieren
Verbesserung unverändert fortführen, obwohl sie nicht mehr relevant ist

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:

Tabelle,
Ticketsystem,
Kanban-Board,
Datenbank,
Projektwerkzeug,
oder spezialisiertes Improvement-Backlog.

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:

erwarteter Wert
Beitrag zu strategischen Zielen
Auswirkung auf Benutzer
Sicherheitsrisiko
regulatorische Notwendigkeit
Dringlichkeit
Kosten
Aufwand
verfügbare Fähigkeiten
Abhängigkeiten
technische Schulden
Lieferantenrisiko
Umsetzbarkeit
und Zeit bis zum erwarteten Nutzen

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:

mit relativ geringem Aufwand,
in kurzer Zeit,
einen erkennbaren Nutzen

erzeugen kann.

Beispiele:

veralteten Wissensartikel korrigieren
eindeutigen Ticketkontakt ergänzen
unnötige Monitoring-Meldung deaktivieren
fehlenden Lieferantenkontakt dokumentieren
häufige Diagnoseabfrage automatisieren

Quick Wins können sinnvoll sein, um:

unmittelbaren Nutzen zu erzeugen,
Akzeptanz aufzubauen,
und Erfahrungen zu sammeln.

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:

zentrale Erfassung,
Verantwortlichkeiten,
Monitoring,
Dokumentation,
und regelmäßige Wirksamkeitsprüfung.

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.

Incident Management koordiniert die Wiederherstellung.
Problem Management untersucht möglicherweise die Ursache.
Continual Improvement verbessert möglicherweise Monitoring, Dokumentation und Wiederherstellungsverfahren.

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:

Monitoring-Plattform konfigurieren
zentrale Datenbank einführen
neue Verantwortlichkeiten technisch abbilden
automatische Erneuerung aktivieren
Alarmierungswege anpassen

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:

Lernen,
Messung,
Feedback,
Anpassung,
und fortlaufende Verbesserung.

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:

Where are we now?
Where do we want to be?
Are we getting there?

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:

Discover,
Design,
Build,
Transition,
Deliver,
und Knowledge Management.

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

Welche Rollen und Fähigkeiten sind betroffen?
Welche Verhaltensänderung wird benötigt?
Bestehen ausreichende Zeit und Kapazität?
Wie wird die neue Arbeitsweise angenommen?

Information and Technology

Welche Daten belegen den Ausgangszustand?
Welche Technologie unterstützt die Verbesserung?
Sind Messung und Automatisierung zuverlässig?
Welche technischen Schulden bestehen?

Partners and Suppliers

Welche externen Anbieter sind betroffen?
Müssen Verträge oder Leistungen angepasst werden?
Welche Abhängigkeiten können die Verbesserung blockieren?
Welche Unterstützung wird benötigt?

Value Streams and Processes

Welcher Arbeitsfluss wird verbessert?
Wo entstehen Wartezeit und Nacharbeit?
Welche Kontrollen und Übergaben sind betroffen?
Wie wird das Outcome gemessen?

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?

Zertifikate werden in verschiedenen Tabellen geführt.
Verantwortlichkeiten sind nicht eindeutig.
Warnungen erfolgen teilweise manuell.
zwölf Zertifikate sind nicht zentral erfasst.
im letzten Jahr entstanden drei Incidents.

3. Where do we want to be?

alle kritischen Zertifikate sind zentral erfasst
verantwortliche Rollen sind zugeordnet
automatische Warnungen erfolgen 60, 30 und 14 Tage vor Ablauf
Erneuerungsverfahren sind dokumentiert
kein vermeidbarer Incident durch unbemerktes Ablaufdatum

4. How do we get there?

vollständigen Bestand erfassen
Verantwortlichkeiten klären
zentrale Datenquelle festlegen
Monitoring konfigurieren
Eskalationsregeln definieren
Erneuerungsverfahren dokumentieren
Pilot mit einem Service durchführen

5. Take action

Pilotservice auswählen
Zertifikat erfassen
Alarmierung testen
Erneuerung simulieren
Verantwortliche schulen
weitere Services iterativ aufnehmen

6. Are we getting there?

Sind alle kritischen Zertifikate erfasst?
Funktionieren Warnungen?
Reagieren die Verantwortlichen?
Wurde die Erneuerung rechtzeitig durchgeführt?
Sind neue Incidents entstanden?

7. How do we keep the improvements relevant?

Erfassung neuer Zertifikate in den Build- und Transition-Ablauf integrieren
Verantwortlichkeiten regelmäßig prüfen
Monitoring überwachen
Wissensartikel pflegen
nach Änderungen und Lieferantenwechseln Bestand kontrollieren
jährliche Wirksamkeitsprüfung durchführen

Praxisbeispiel: Onboarding dauert zu lange

Vision

Neue Mitarbeiter sollen am ersten Arbeitstag sicher und vollständig arbeiten können.

Ausgangszustand

durchschnittliche Durchlaufzeit: zwölf Arbeitstage
viele unvollständige Eintrittsmeldungen
Hardwarebestand ist nicht transparent
mehrere manuelle Freigaben
kein Ende-zu-Ende-Verantwortlicher

Zielzustand

95 Prozent rechtzeitig gemeldeter Eintritte sind am ersten Tag vollständig arbeitsfähig
klare Vorlaufzeit
vollständiges digitales Formular
definierte Standardpakete
sichtbarer Status
geregelte Vertretung

Mögliche Maßnahmen

Value Stream Mapping durchführen
Eintrittsformular verbessern
Rollenpakete definieren
Gerätebestand erfassen
Freigaben vereinfachen
Kontoanlage teilweise automatisieren
Arbeitsfähigkeit bestätigen lassen

Messung

Durchlaufzeit
Anteil vollständiger Meldungen
Anteil arbeitsfähiger Mitarbeiter am ersten Tag
Anzahl Rückfragen
Benutzer- und Führungskräftefeedback

Praxisbeispiel: Zu viele Monitoring-Alarme

Vision

Administratoren sollen relevante Zustandsänderungen rechtzeitig erkennen, ohne durch unnötige Meldungen überlastet zu werden.

Ausgangszustand

täglich mehrere hundert Meldungen
viele Duplikate
unklare Verantwortlichkeit
kritische Meldungen gehen in der Menge unter
Alarmregeln werden selten überprüft

Zielzustand

relevante Alarme besitzen eindeutige Zuständigkeit
Duplikate werden reduziert
kritische Events werden priorisiert
Alarmregeln werden nach Incidents überprüft
Reaktionszeiten werden messbar

Mögliche Maßnahmen

Alarmbestand analysieren
technische und handlungsrelevante Events unterscheiden
redundante Meldungen korrelieren
Verantwortlichkeiten zuordnen
Schwellenwerte testen
automatische Eskalation konfigurieren
monatliche Qualitätsprüfung etablieren

Praxisbeispiel: Knowledge-Base wird kaum genutzt

Vision

Mitarbeiter und Benutzer sollen verlässliches Wissen schnell finden und erfolgreich anwenden können.

Ausgangszustand

viele veraltete Artikel
uneinheitliche Titel
schlechte Suchbegriffe
keine Verantwortlichkeit
Erfolg wird nur anhand der Artikelanzahl gemessen

Zielzustand

häufig benötigte Inhalte sind aktuell
Suche liefert relevante Ergebnisse
Eigentümer und Prüfdatum sind bekannt
Nutzung und Lösungsbeitrag werden gemessen
veraltete Inhalte werden archiviert

Mögliche Maßnahmen

Suchdaten und häufige Tickets auswerten
wichtige Artikel priorisieren
Vorlagen vereinheitlichen
Verantwortliche festlegen
Versionsstände ergänzen
Feedback ermöglichen
regelmäßige Überprüfung einrichten

Continual Improvement bei einem Incident

Nach einem Incident können Verbesserungsmöglichkeiten entstehen bei:

Monitoring,
Eskalation,
Kommunikation,
Dokumentation,
Wiederherstellung,
Lieferantensteuerung,
Konfigurationsinformationen,
Sicherheitskontrollen,
und Benutzerinformation.

Nicht jeder Incident benötigt eine umfangreiche Verbesserungsinitiative.

Eine Initiative ist besonders sinnvoll, wenn:

ein Incident schwerwiegend war,
derselbe Fehler wiederholt auftritt,
die Wiederherstellung unnötig lange dauerte,
wichtige Informationen fehlten,
Risiken nicht erkannt wurden,
oder ähnliche Services ebenfalls gefährdet sind.

Lessons Learned und Post-Incident Review

Eine nachgelagerte Überprüfung kann untersuchen:

Was ist geschehen?
Welche Auswirkungen bestanden?
Was funktionierte gut?
Was erschwerte die Bearbeitung?
Welche Entscheidungen wurden getroffen?
Welche Informationen fehlten?
Welche Maßnahmen waren erfolgreich?
Welche Risiken bestehen weiterhin?
Welche Verbesserungen sind notwendig?
Wer übernimmt diese Verbesserungen?

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:

Probleme offen angesprochen,
Risiken eskaliert,
Fehler untersucht,
und Erkenntnisse geteilt

werden können.

Eine Untersuchung sollte nicht vorschnell nach einer schuldigen Person suchen.

Zu prüfen sind ebenfalls:

unklare Anforderungen,
fehlende Informationen,
ungeeignete Werkzeuge,
widersprüchliche Ziele,
fehlende Fähigkeiten,
unrealistische Arbeitslast,
unzureichende Kontrollen,
und organisatorische Abhängigkeiten.

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:

Hat sich das Outcome verbessert?
Hat sich das Risiko verändert?
Hat sich die Stakeholder-Erfahrung verbessert?
Sind Kosten oder Aufwand gesunken?
Wurden unbeabsichtigte Nebenwirkungen erzeugt?
Bleibt die Verbesserung wirksam?

Mögliche Messgrößen:

Durchlaufzeit
Wiederherstellungszeit
Fehlerquote
Wiederholungsquote
Wartezeit
Anzahl Übergaben
Verfügbarkeit
Serviceerfahrung
Nutzung
Kosten
Sicherheitsvorfälle
Datenverlust
Nacharbeit
Einhaltung von Zielwerten

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:

Werden Tickets häufiger wieder geöffnet?
Werden Vorgänge schneller weitergereicht?
Müssen Benutzer erneut Kontakt aufnehmen?
Ist die Dokumentationsqualität gesunken?
Wurde das tatsächliche Outcome erreicht?

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:

automatische Datenerfassung
Berichte
Trendanalysen
Workflow-Steuerung
Erinnerungen
technische Tests
Überwachung von Zielwerten
und Erkennung wiederkehrender Muster

Automatisierung kann jedoch keine fehlende:

Vision,
Verantwortlichkeit,
Priorisierung,
Datenqualität,
oder fachliche Bewertung

ersetzen.

Grundsatz

Nicht die Verbesserungsidee automatisieren, sondern einen verstandenen und geeigneten Zielzustand.

Künstliche Intelligenz bei Continual Improvement

KI kann beispielsweise unterstützen bei:

Analyse großer Ticketmengen
Erkennung wiederkehrender Themen
Zusammenfassung von Feedback
Vorschlägen für mögliche Verbesserungen
Prognose von Kapazitätsproblemen
Erkennung von Anomalien
und Erstellung erster Berichte

Dabei müssen berücksichtigt werden:

Qualität der Eingangsdaten
Datenschutz
Informationssicherheit
Nachvollziehbarkeit
mögliche Verzerrungen
menschliche Kontrolle
und Ergebnisverantwortung

Beispiel:

Eine KI erkennt, dass viele Tickets den Begriff „Anmeldung“ enthalten.

Das beweist noch nicht:

dass dieselbe Ursache besteht,
dass alle Tickets falsch bearbeitet wurden,
oder welche Verbesserung notwendig ist.

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:

wiederkehrende manuelle Tätigkeiten
fehlende Monitoring-Regeln
veraltete Dokumentationen
unnötige Ticketübergaben
wiederkehrende Fehlkonfigurationen
schlecht nachvollziehbare Abhängigkeiten
ungetestete Wiederherstellungsverfahren
uneinheitliche Serverkonfigurationen
fehlende Automatisierung
und dauerhaft eingesetzte Zwischenlösungen

Eine gute Verbesserungsidee sollte nicht nur lauten:

Das sollten wir automatisieren.

Sie sollte möglichst beantworten:

Welches Problem besteht?
Wie häufig tritt es auf?
Welche Auswirkungen besitzt es?
Welches Outcome soll verbessert werden?
Welche Daten belegen den Bedarf?
Welche Risiken bestehen?
Welche Maßnahme wird vorgeschlagen?
Wie wird der Erfolg gemessen?

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

Vision: Warum ist die Verbesserung wichtig?
Ist-Zustand: Welche Daten und Beobachtungen liegen vor?
Zielzustand: Was soll konkret besser werden?
Weg: Welche Maßnahme ist geeignet?
Aktion: Wer setzt den nächsten Schritt um?
Messung: Woran erkennen wir Fortschritt und Erfolg?
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

2.1 Was ist ITIL und wie ist das Framework aufgebaut?
2.2 Das ITIL Value System
2.3 Die sieben Guiding Principles
2.4 Governance und Verantwortlichkeit
2.5 Die vier Dimensionen des Produkt- und Service-Managements
2.6 Der Product and Service Lifecycle
2.7 Die ITIL Management Practices
2.8 Value Streams und Value Stream Mapping
2.10 ITIL an den eigenen Kontext anpassen
Incident Management
Problem Management
Change Enablement
Knowledge Management
Measurement and Reporting
Organizational Change Management

Quellen und Versionsstand

Offizielle Grundlagen

Ergänzende offizielle Community-Quelle

PeopleCert Community: Continual Improvement, Maturity or Transformation?

Offiziell bestätigter Stand

Die aktuellen offiziellen ITIL-Version-5-Informationen bestätigen:

Continual Improvement ist weiterhin Bestandteil des ITIL Value Systems.
Continual Improvement ist über das gesamte Framework und den Product and Service Lifecycle hinweg relevant.
ITIL Foundation Version 5 behandelt ein verfeinertes Continual Improvement Model.
Das Modell besitzt weiterhin sieben Schritte.
Einzelne Schrittbezeichnungen wurden gegenüber ITIL 4 präzisiert.
Die aktuellen sieben Schritte lauten:
1. What is the vision?
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?
Das Modell kann auf Verbesserungen von Produkten, Services, Practices und anderen Bestandteilen des Value Systems angewendet werden.
Die Schritte werden iterativ verwendet und können auf Grundlage neuer Erkenntnisse erneut durchlaufen werden.

Einordnung

Die ausführlichen:

Leitfragen,
Tabellen,
Checklisten,
Registerfelder,
Priorisierungskriterien,
Praxisbeispiele,
und Umsetzungshinweise

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

Revision #1
Created 1 August 2026 22:35:42 by Admin
Updated 1 August 2026 22:35:57 by Admin