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 Ist das Problem oder die Chance verständlich beschrieben? Ist das betroffene Produkt, der Service oder die Practice bekannt? Sind relevante Stakeholder bestimmt? Ist das gewünschte Outcome erkennbar? Liegen Daten oder konkrete Beobachtungen vor? Sind Auswirkungen und Risiken bekannt? Wurde geprüft, was bereits funktioniert? Ist eine mögliche Maßnahme beschrieben? Sind Nutzen und Aufwand grob einschätzbar? Ist bekannt, wer die Idee weiter bewertet? Checkliste für eine Verbesserungsinitiative Ist die Vision eindeutig? Unterstützt die Initiative strategische oder betriebliche Ziele? Ist der Umfang klar abgegrenzt? Ist der Ausgangszustand dokumentiert? Besteht eine geeignete Baseline? Ist ein überprüfbarer Zielzustand definiert? Sind Erfolgskriterien und Messgrößen festgelegt? Sind Rollen und Verantwortlichkeiten eindeutig? Sind Ressourcen und Fähigkeiten verfügbar? Sind Risiken und Abhängigkeiten berücksichtigt? Sind alle vier Dimensionen betrachtet? Sind relevante Practices und Lieferanten einbezogen? Ist ein iteratives Vorgehen möglich? Sind Kommunikation und Feedback geplant? Ist festgelegt, wie Ergebnisse verankert werden? Checkliste während der Umsetzung Werden geplante Maßnahmen durchgeführt? Ist der Fortschritt sichtbar? Werden Feedback und Messwerte erfasst? Sind neue Risiken oder Nebenwirkungen entstanden? Sind Beteiligte ausreichend informiert? Wird die neue Arbeitsweise tatsächlich verwendet? Müssen Ziel, Plan oder Umfang angepasst werden? Sind Hindernisse eskaliert? Werden Entscheidungen dokumentiert? Ist die nächste Iteration eindeutig? Checkliste zur Erfolgskontrolle Wurde der neue Zustand gemessen? Wurde er mit der Baseline verglichen? Wurden die Zielwerte erreicht? Wurde das gewünschte Outcome erreicht? Hat sich die Stakeholder-Erfahrung verbessert? Wurden Risiken reduziert? Sind neue Risiken entstanden? Wurde ein Engpass nur verlagert? Sind Daten und Messung zuverlässig? Sind weitere Maßnahmen notwendig? Sollte die Initiative fortgeführt, angepasst oder beendet werden? Checkliste zur Verankerung Ist eine dauerhafte Verantwortung festgelegt? Sind Prozesse und Arbeitsanweisungen aktualisiert? Sind Knowledge-Artikel angepasst? Sind betroffene Mitarbeiter geschult? Sind Werkzeuge und Automatisierungen aktualisiert? Werden relevante Messgrößen weiter beobachtet? Wurden Governance-Vorgaben und Kontrollen angepasst? Sind Service-, Produkt- und Konfigurationsinformationen aktuell? Wurden Erkenntnisse und Fehlversuche dokumentiert? Ist ein Termin zur erneuten Relevanzprüfung festgelegt? Wurden weitere Verbesserungsideen erfasst? 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 PeopleCert: ITIL Foundation – Version 5 ITIL: ITIL Foundation – Version 5 ITIL: ITIL Foundation Version 5 – What’s New? ITIL: Where do you start with ITIL? A case for continual improvement PeopleCert: ITIL Transformation – Version 5 PeopleCert: ITIL Service – Version 5 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: What is the vision? Where are we now? Where do we want to be? How do we get there? Take action Are we getting there? 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