# 5.5 Change-Erfolg messen und Continual Improvement > **Kurz erklärt** > > Ein Change ist nicht automatisch erfolgreich, nur weil er technisch durchgeführt wurde. > > Erfolgreich ist ein Change erst dann, wenn der gewünschte Nutzen erreicht wurde, der Service stabil bleibt, Benutzer arbeitsfähig sind und keine unvertretbaren Nebenwirkungen entstehen. > > Deshalb müssen Changes nach der Umsetzung bewertet, dokumentiert und für zukünftige Verbesserungen genutzt werden. --- **Warum Change-Erfolg gemessen werden muss** Ohne Erfolgsmessung bleibt unklar, ob ein Change wirklich sinnvoll war. Mögliche Fragen: - Hat der Change das Ziel erreicht? - Funktioniert der betroffene Service stabil? - Gab es neue Incidents nach dem Change? - Wurde der erwartete Nutzen erreicht? - Waren Benutzer ausreichend informiert? - War der Rollback realistisch? - Waren Tests ausreichend? - Gab es ungeplante Auswirkungen? - Muss Wissen oder Dokumentation angepasst werden? - Was sollte beim nächsten Change besser laufen? Change-Erfolg bedeutet mehr als: > Umsetzung abgeschlossen. Entscheidend ist das Ergebnis aus Service-, Benutzer- und Betriebssicht. --- **Technische Umsetzung und Service-Erfolg unterscheiden** | Technische Umsetzung | Service-Erfolg | |---|---| | Paket wurde installiert | Benutzer können wieder arbeiten | | Konfiguration wurde geändert | Service funktioniert stabil | | Server wurde aktualisiert | abhängige Systeme funktionieren weiterhin | | Firewall-Regel wurde gesetzt | Schnittstelle funktioniert sicher und erwartungsgemäß | | Zertifikat wurde erneuert | Anmeldung funktioniert ohne neue Störungen | | Deployment ist abgeschlossen | Release erzeugt den gewünschten Nutzen | Ein Change kann technisch erfolgreich sein und trotzdem aus Service-Sicht Probleme verursachen. Beispiel: Eine neue Anwendungsversion wurde korrekt installiert. Nach dem Update funktioniert jedoch der Export für die Buchhaltung nicht mehr. Technisch war das Deployment erfolgreich. Aus Sicht des Services ist der Change nur teilweise erfolgreich oder fehlgeschlagen. --- **Erfolgskriterien vorab festlegen** Erfolg sollte vor der Umsetzung definiert werden. Gute Erfolgskriterien sind: - eindeutig, - messbar, - überprüfbar, - realistisch, - mit dem Ziel des Changes verbunden, - und für Technik sowie Benutzer verständlich. Beispiele: | Change | mögliches Erfolgskriterium | |---|---| | VPN-Client aktualisieren | VPN-Incidents sinken innerhalb von vier Wochen deutlich | | Zertifikat erneuern | Anmeldung funktioniert und Monitoring erkennt zukünftige Abläufe | | Firewall-Regel setzen | gewünschte Verbindung funktioniert, keine unerwarteten Freigaben | | Anwendung aktualisieren | Kernfunktionen funktionieren nach Smoke Test und Fachbereichstest | | Monitoring erweitern | relevante Warnung wird korrekt ausgelöst und an richtiges Team gesendet | | Druckertreiber aktualisieren | Etikettendruck funktioniert und Incidents treten nicht erneut auf | Ohne Erfolgskriterien wird die Nachprüfung ungenau. --- **Mögliche Kennzahlen für Change-Erfolg** | Bereich | mögliche Kennzahl | |---|---| | Umsetzung | Anteil erfolgreich abgeschlossener Changes | | Qualität | Anzahl fehlgeschlagener Changes | | Stabilität | Incidents nach Changes | | Risiko | Anzahl Emergency Changes | | Planung | Anteil Changes mit Rollback-Plan | | Kommunikation | Beschwerden oder Rückfragen nach Change | | Geschwindigkeit | Durchlaufzeit von Change Request bis Umsetzung | | Wirkung | Rückgang wiederkehrender Incidents | | Wissen | aktualisierte Knowledge-Artikel nach Change | | Verbesserung | Lessons Learned umgesetzt | Nicht jede Organisation benötigt alle Kennzahlen. Wichtig ist, dass die Kennzahlen Entscheidungen und Verbesserungen unterstützen. --- **Change Success Rate** Die Change Success Rate beschreibt den Anteil der Changes, die erfolgreich umgesetzt wurden. Vorsicht: Eine hohe Erfolgsquote ist nur sinnvoll, wenn klar definiert ist, was „erfolgreich“ bedeutet. Ungeeignet: > Change wurde durchgeführt, also erfolgreich. Besser: > Change wurde wie geplant durchgeführt, Erfolgskriterien wurden erreicht, keine relevanten Incidents entstanden, Dokumentation wurde aktualisiert. Eine zu einfache Erfolgsdefinition verfälscht die Kennzahl. --- **Failed Changes** Ein Failed Change ist eine Änderung, die nicht wie geplant erfolgreich war oder unerwünschte Auswirkungen verursacht hat. Mögliche Beispiele: - Change musste abgebrochen werden, - Rollback war notwendig, - Service fiel aus, - Benutzer konnten nicht arbeiten, - neue Incidents entstanden, - Erfolgskriterien wurden nicht erreicht, - Daten wurden beschädigt, - Sicherheitsrisiko entstand, - Kommunikation war unzureichend, - Dokumentation blieb falsch. Failed Changes sind wichtige Lernquellen. Sie sollten nicht versteckt oder beschönigt werden. --- **Incidents nach Changes** Eine wichtige Kennzahl ist die Anzahl der Incidents, die nach Changes entstehen. Zu prüfen ist: - Trat der Incident direkt nach dem Change auf? - Ist ein Zusammenhang wahrscheinlich? - Welche Services sind betroffen? - Wurde der Change korrekt getestet? - Wurden Abhängigkeiten übersehen? - War die Kommunikation ausreichend? - War der Service Desk vorbereitet? - Gab es ähnliche Incidents bei früheren Changes? Nicht jeder Incident nach einem Change wurde durch den Change verursacht. Der zeitliche Zusammenhang ist ein Hinweis, aber kein Beweis. --- **Emergency-Change-Quote** Eine hohe Anzahl von Emergency Changes kann auf Probleme hinweisen. Mögliche Ursachen: - schlechte Planung, - zu spätes Erkennen von Risiken, - fehlendes Monitoring, - unzureichendes Patchmanagement, - instabile Services, - fehlende Wartungsfenster, - langsame Genehmigungswege, - zu viele ungeplante Arbeiten, - oder schlechte Priorisierung. Emergency Changes sind manchmal notwendig. Wenn sie aber zur Regel werden, sollte das Change-Modell überprüft werden. --- **Rollback-Quote** Die Rollback-Quote zeigt, wie oft Changes zurückgenommen werden mussten. Eine hohe Quote kann hinweisen auf: - unzureichende Tests, - schlechte Auswirkungsbewertung, - falsche Annahmen, - fehlende Abhängigkeiten, - ungeeignete Wartungsfenster, - unvollständige Kommunikation, - oder mangelhafte technische Vorbereitung. Eine niedrige Rollback-Quote ist nicht automatisch gut. Sie kann auch bedeuten, dass bei Problemen kein funktionierender Rollback vorhanden war. --- **Durchlaufzeit von Changes** Die Durchlaufzeit beschreibt, wie lange ein Change von der Anforderung bis zur Umsetzung benötigt. Zu betrachten sind: - Zeit bis zur Bewertung, - Zeit bis zur Genehmigung, - Wartezeit auf Informationen, - Wartezeit auf Wartungsfenster, - Zeit für Tests, - Zeit für Umsetzung, - Zeit bis Abschluss. Lange Durchlaufzeiten können auf Engpässe hinweisen. Beispiele: - Change Requests sind unvollständig. - Genehmigungen dauern zu lange. - Tests sind nicht verfügbar. - Fachbereiche reagieren langsam. - Lieferanten blockieren. - CAB-Termine sind zu selten. --- **Qualität der Change Requests** Die Qualität eines Change Requests beeinflusst die gesamte Bearbeitung. Zu prüfen ist: - Ist die Änderung verständlich beschrieben? - Ist der betroffene Service genannt? - Sind CIs dokumentiert? - Ist der Nutzen klar? - Sind Risiken bewertet? - Ist ein Testplan vorhanden? - Ist ein Rollback beschrieben? - Ist Kommunikation berücksichtigt? - Sind Abhängigkeiten genannt? - Sind Erfolgskriterien definiert? Unvollständige Change Requests führen zu Rückfragen, Verzögerungen und höheren Risiken. --- **Change-Kalender auswerten** Ein Change-Kalender zeigt nicht nur geplante Änderungen. Er kann auch zur Verbesserung genutzt werden. Zu prüfen ist: - Häufen sich Changes in bestimmten Zeiträumen? - Gibt es Kollisionen zwischen Changes? - Werden kritische Services zu häufig geändert? - Finden Changes außerhalb geeigneter Wartungsfenster statt? - Gibt es wiederholt Verschiebungen? - Werden Changes während Change Freeze beantragt? - Sind Lieferanten und Bereitschaften richtig eingeplant? Ein gut gepflegter Change-Kalender reduziert Konflikte und Überraschungen. --- **Post Implementation Review** Ein Post Implementation Review prüft nach der Umsetzung, ob der Change erfolgreich war. Mögliche Fragen: - Wurde der Change wie geplant durchgeführt? - Wurden Erfolgskriterien erreicht? - Waren Tests ausreichend? - Waren Risiko und Auswirkung korrekt bewertet? - War die Kommunikation verständlich? - War der Service Desk vorbereitet? - Gab es Incidents nach dem Change? - War Rollback möglich oder notwendig? - Wurde Dokumentation aktualisiert? - Welche Verbesserungen sind notwendig? Nicht jeder kleine Standard Change benötigt ein ausführliches Review. Bei risikoreichen, fehlgeschlagenen oder besonders wichtigen Changes ist es sehr sinnvoll. --- **Review nach Emergency Changes** Emergency Changes sollten besonders sorgfältig nachbereitet werden. Zu prüfen ist: - Warum war die Änderung dringend? - Hätte die Situation früher erkannt werden können? - War der Emergency-Prozess angemessen? - Wer hat entschieden? - Welche Risiken wurden akzeptiert? - War die Dokumentation ausreichend? - Wurde der Service stabil wiederhergestellt? - Sind weitere dauerhafte Maßnahmen notwendig? - Muss ein Problem Record erstellt werden? - Muss Monitoring verbessert werden? Ziel ist nicht, die schnelle Entscheidung nachträglich zu bestrafen. Ziel ist, zukünftige Notfälle zu vermeiden. --- **Review nach Failed Changes** Ein Failed Change sollte analysiert werden. Mögliche Fragen: - Welche Annahme war falsch? - Welche Abhängigkeit wurde übersehen? - Welcher Test fehlte? - War das Wartungsfenster ausreichend? - War der Rollback realistisch? - Waren Rollen klar? - Wurde zu spät abgebrochen? - War die Kommunikation ausreichend? - Welche Dokumentation war fehlerhaft? - Welche Maßnahme verhindert Wiederholung? Failed Changes sind wichtige Daten für Continual Improvement. --- **Lessons Learned** Lessons Learned sind Erkenntnisse aus erfolgreichen und fehlgeschlagenen Changes. Mögliche Ergebnisse: - Change-Vorlage verbessern, - Testplan erweitern, - Rollback-Vorgaben präzisieren, - Service Desk früher informieren, - CAB-Beteiligung anpassen, - Standard Change neu definieren, - Emergency-Kriterien überarbeiten, - CMDB aktualisieren, - Monitoring erweitern, - Knowledge-Artikel aktualisieren, - Automatisierung verbessern, - Schulung durchführen. Lessons Learned sind nur wertvoll, wenn daraus konkrete Maßnahmen entstehen. --- **Continual Improvement im Change Enablement** Change Enablement sollte selbst kontinuierlich verbessert werden. Möglicher Ablauf: Change-Daten sammeln ↓ Trends und Schwachstellen erkennen ↓ Verbesserungsidee erfassen ↓ Nutzen und Aufwand bewerten ↓ Maßnahme umsetzen ↓ Wirkung messen ↓ Change-Modell anpassen Verbesserung kann sich auf Prozesse, Werkzeuge, Kommunikation, Vorlagen, Automatisierung oder Rollen beziehen. --- **Improvement Register** Verbesserungsideen aus Change Reviews sollten nicht verloren gehen. Ein Improvement Register kann enthalten: - Verbesserungsidee, - Auslöser, - betroffener Prozess, - erwarteter Nutzen, - Risiko, - Aufwand, - Priorität, - Verantwortlicher, - Status, - Zieltermin, - Ergebnis. Beispiele: - Checkliste für Firewall-Changes ergänzen, - Service Desk bei Releases früher informieren, - Standard-Change-Katalog überarbeiten, - Emergency-Change-Review verbindlich machen, - Rollback-Vorlage verbessern, - Change-Kalender sichtbarer machen. --- **Standard Changes regelmäßig überprüfen** Standard Changes sind vorab genehmigt. Trotzdem müssen sie regelmäßig geprüft werden. Fragen: - Wird der Ablauf noch korrekt genutzt? - Ist das Risiko weiterhin niedrig? - Gab es Incidents nach Standard Changes? - Sind Runbooks aktuell? - Sind Berechtigungen angemessen? - Sind Erfolgskriterien noch gültig? - Wird der Standard Change missbraucht? - Muss der Ablauf angepasst werden? - Muss der Standard Change entfernt werden? Ein Standard Change darf nicht dauerhaft ungeprüft bleiben. --- **Change-Modell anpassen** Ein Change-Modell beschreibt, wie bestimmte Change-Arten bearbeitet werden. Es sollte angepasst werden, wenn: - Changes regelmäßig zu langsam sind, - Standard Changes zu viele Rückfragen erzeugen, - Emergency Changes zu häufig auftreten, - Failed Changes zunehmen, - Genehmigungen unnötig blockieren, - Risiken nicht erkannt werden, - Service Desk nicht ausreichend informiert wird, - oder Dokumentation häufig fehlt. Ein gutes Change-Modell ist stabil, aber nicht starr. --- **Automatisierung im Change Enablement** Automatisierung kann Change Enablement verbessern. Beispiele: - automatische Pflichtfeldprüfung, - Risikoeinstufung anhand betroffener Services, - automatische Benachrichtigung des Service Desks, - Change-Kollisionen erkennen, - Standard-Change-Workflows, - automatische Deployment-Protokolle, - automatische CMDB-Aktualisierung, - Monitoring nach Change aktivieren, - Erinnerungen an Reviews. Automatisierung muss aber kontrolliert werden. Ein falsch automatisierter Change-Prozess kann Fehler schneller verbreiten. --- **Change-Datenqualität verbessern** Gute Auswertung benötigt gute Daten. Probleme entstehen durch: - unvollständige Change Requests, - falsche Servicezuordnung, - fehlende CI-Verknüpfung, - unklare Abschlussnotizen, - nicht dokumentierte Rollbacks, - fehlende Erfolgskriterien, - nicht verknüpfte Incidents, - fehlende Problem-Verknüpfung, - veraltete CMDB. Eine wichtige Verbesserung kann darin bestehen, die Pflichtinformationen im Change-Prozess zu verbessern. --- **Zusammenhang mit Problem Management** Problem Management ist besonders wichtig für Change-Erfolg. Ein Change kann: - eine dauerhafte Lösung für ein Problem umsetzen, - einen Known Error schließen, - einen Workaround ersetzen, - neue Incidents verursachen, - oder selbst ein neues Problem auslösen. Nach einem Change zur Problemlösung sollte geprüft werden: - Ist das Problem wirklich behoben? - Treten zugehörige Incidents weiter auf? - Ist der Workaround noch nötig? - Kann der Known Error geschlossen werden? - Muss ein neues Problem erstellt werden? --- **Zusammenhang mit Knowledge Management** Nach Changes muss Wissen aktuell bleiben. Zu prüfen ist: - Müssen Knowledge-Artikel angepasst werden? - Sind Screenshots oder Menüpfade veraltet? - Gibt es neue Workarounds? - Ist ein Known Error geschlossen? - Muss der Service Desk neue Prüfschritte kennen? - Müssen Benutzeranleitungen angepasst werden? - Muss ein Runbook aktualisiert werden? Ein Change kann technisch erfolgreich sein und trotzdem Supportprobleme verursachen, wenn Knowledge veraltet bleibt. --- **Zusammenhang mit Service Configuration Management** Nach Changes müssen Configuration Items und Beziehungen aktuell bleiben. Zu prüfen ist: - Wurde eine Version geändert? - Wurde Hardware ersetzt? - Wurde ein neuer Server erstellt? - Wurde eine Schnittstelle geändert? - Wurde eine neue Abhängigkeit erzeugt? - Hat sich der Owner geändert? - Wurde ein Zertifikat erneuert? - Hat sich ein Lieferant geändert? Eine veraltete CMDB erschwert zukünftige Incidents, Problems und Changes. --- **Zusammenhang mit Measurement and Reporting** Measurement and Reporting unterstützt Change Enablement durch: - Kennzahlen, - Trendberichte, - Dashboards, - Erfolgsanalysen, - Service Reviews, - Managementberichte, - und Verbesserungsnachweise. Wichtig ist, nicht nur Zahlen zu zeigen. Berichte sollten erklären: - was passiert ist, - warum es relevant ist, - welche Risiken bestehen, - welche Maßnahmen geplant sind, - und welche Entscheidung benötigt wird. --- **Beispiel: Failed Change** **Situation** Ein Anwendungspatch wurde eingespielt. **Problem** Nach dem Patch funktioniert der PDF-Export nicht mehr. **Analyse** - Testplan enthielt keinen Exporttest. - Fachbereich wurde nicht in die Abnahme einbezogen. - Rollback war möglich und wurde durchgeführt. - Service Desk wurde erst nach Benutzeranrufen informiert. **Verbesserungen** - Testplan um Exportfunktion erweitern, - Fachbereichstest für kritische Funktionen einführen, - Service Desk vor jedem produktiven Patch informieren, - Release Notes ergänzen. --- **Beispiel: Zu viele Emergency Changes** **Beobachtung** Emergency Changes nehmen über mehrere Monate zu. **Analyse** Viele Emergency Changes betreffen ablaufende Zertifikate und Speicherplatzprobleme. **Ursachen** - kein Zertifikatsmonitoring, - keine rechtzeitige Kapazitätsplanung, - fehlende Owner, - veraltete Wartungskalender. **Verbesserungen** - Zertifikatsüberwachung einführen, - Speichertrends monatlich prüfen, - Owner je Service festlegen, - proaktive Problem Records erstellen. --- **Beispiel: Standard Change verbessern** **Situation** Standardsoftware wird über ein Portal bereitgestellt. **Problem** Viele Requests schlagen fehl, weil Geräte nicht erreichbar sind. **Analyse** - Portal prüft den Gerätestatus nicht vorab. - Benutzer erhalten unklare Fehlermeldungen. - Service Desk muss manuell nacharbeiten. **Verbesserungen** - Vorabprüfung des Gerätestatus automatisieren, - Benutzerhinweis verbessern, - Fehler automatisch an Service Desk weiterleiten, - Knowledge-Artikel aktualisieren. --- **Typische Fehler** **Fehler 1** Change gilt als erfolgreich, nur weil er technisch durchgeführt wurde. --- **Fehler 2** Erfolgskriterien werden nicht vorab definiert. --- **Fehler 3** Incidents nach Changes werden nicht ausgewertet. --- **Fehler 4** Failed Changes werden beschönigt oder nicht dokumentiert. --- **Fehler 5** Emergency Changes werden nicht nachbereitet. --- **Fehler 6** Lessons Learned werden gesammelt, aber nicht umgesetzt. --- **Fehler 7** Standard Changes werden nie überprüft. --- **Fehler 8** Kennzahlen erzeugen falsche Anreize. --- **Fehler 9** Change-Datenqualität ist schlecht. --- **Fehler 10** Knowledge Base und CMDB werden nach Changes nicht aktualisiert. --- **Fehler 11** Review-Fragen konzentrieren sich nur auf Technik, nicht auf Servicewirkung. --- **Fehler 12** Verbesserungen bleiben ohne Verantwortlichen und Termin. --- **Problematische Kennzahlen** | Kennzahl | möglicher Fehlanreiz | |---|---| | möglichst viele Changes | unnötige oder schlecht geplante Änderungen | | sehr kurze Durchlaufzeit | unzureichende Prüfung | | hohe Erfolgsquote | Fehler werden nicht ehrlich dokumentiert | | wenige Emergency Changes | dringende Fälle werden falsch klassifiziert | | wenige Failed Changes | Teams melden Fehlschläge nicht transparent | | niedrige Rollback-Quote | Rollback fehlt oder wird vermieden | Kennzahlen müssen deshalb immer mit Kontext betrachtet werden. --- **Gute Kennzahlenkombinationen** Sinnvoll ist eine kombinierte Betrachtung. Beispiele: - Change Success Rate und Incidents nach Changes, - Durchlaufzeit und Qualität der Change Requests, - Emergency-Change-Quote und proaktive Problem Records, - Failed Changes und Lessons Learned, - Standard-Change-Nutzung und Fehlerquote, - Knowledge-Aktualisierungen und Supportanfragen nach Release, - CMDB-Aktualisierungen und spätere Incident-Diagnosequalität. Einzelne Kennzahlen können täuschen. Kombinationen zeigen bessere Zusammenhänge. --- **Checkliste Change-Erfolg prüfen** - [ ] Erfolgskriterien vorab definiert - [ ] Change wie geplant umgesetzt - [ ] Service technisch verfügbar - [ ] Benutzer-Outcome geprüft - [ ] abhängige Services geprüft - [ ] Monitoring geprüft - [ ] Logs geprüft - [ ] Incidents nach Change geprüft - [ ] Service Desk informiert - [ ] Abschluss kommuniziert - [ ] Dokumentation aktualisiert - [ ] Knowledge Base aktualisiert - [ ] CMDB aktualisiert --- **Checkliste Post Implementation Review** - [ ] Ziel des Changes erreicht? - [ ] Risiko korrekt bewertet? - [ ] Auswirkungen korrekt eingeschätzt? - [ ] Tests ausreichend? - [ ] Kommunikation ausreichend? - [ ] Wartungsfenster passend? - [ ] Rollback realistisch? - [ ] Abweichungen dokumentiert? - [ ] neue Incidents entstanden? - [ ] Lessons Learned erfasst? - [ ] Verbesserungen zugewiesen? - [ ] Review-Ergebnis dokumentiert? --- **Checkliste Failed Change** - [ ] Auswirkungen begrenzt - [ ] Incident verknüpft - [ ] Rollback oder Roll Forward bewertet - [ ] Benutzer informiert - [ ] Service Desk informiert - [ ] Ursache des Fehlschlags untersucht - [ ] Problem Record erstellt, falls erforderlich - [ ] Testplan angepasst - [ ] Change-Modell geprüft - [ ] Knowledge aktualisiert - [ ] Lessons Learned dokumentiert - [ ] Verbesserungsmaßnahmen verfolgt --- **Checkliste Continual Improvement im Change Enablement** - [ ] Change-Kennzahlen regelmäßig ausgewertet - [ ] Emergency Changes analysiert - [ ] Failed Changes analysiert - [ ] Standard Changes überprüft - [ ] Change Requests auf Qualität geprüft - [ ] CAB oder Genehmigungswege bewertet - [ ] Service Desk Feedback einbezogen - [ ] Benutzerfeedback berücksichtigt - [ ] CMDB- und Knowledge-Aktualisierung geprüft - [ ] Verbesserungen im Improvement Register erfasst - [ ] Verantwortliche benannt - [ ] Wirksamkeit der Verbesserungen geprüft --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker tragen wesentlich dazu bei, ob Change-Erfolg messbar und nachvollziehbar ist. Im Arbeitsalltag bedeutet das: - Umsetzungsschritte dokumentieren, - Tests sauber durchführen, - technische und fachliche Ergebnisse prüfen, - Monitoring und Logs auswerten, - Abweichungen ehrlich dokumentieren, - Rollbacks nachvollziehbar beschreiben, - Knowledge und Runbooks aktualisieren, - CMDB-Änderungen melden, - Incidents nach Changes erkennen, - und Verbesserungen aus Fehlern ableiten. Gute technische Arbeit endet nicht beim erfolgreichen Befehl. Sie endet erst, wenn der Service stabil funktioniert und die Änderung nachvollziehbar abgeschlossen ist. --- **Zusammenfassung** > Change-Ziel und Erfolgskriterien festlegen > ↓ > Change durchführen > ↓ > technisches Ergebnis prüfen > ↓ > Benutzer-Outcome und Servicewirkung prüfen > ↓ > Incidents, Monitoring und Feedback auswerten > ↓ > Failed Changes und Emergency Changes reviewen > ↓ > Knowledge, CMDB und Dokumentation aktualisieren > ↓ > Lessons Learned erfassen > ↓ > Verbesserungen verfolgen > ↓ > Change-Modell kontinuierlich verbessern --- **Merksätze** > Ein Change ist nicht erfolgreich, nur weil er durchgeführt wurde. > Erfolg muss aus Service- und Benutzersicht geprüft werden. > Failed Changes sind Lernquellen. > Emergency Changes benötigen Nachbereitung. > Kennzahlen ohne Kontext erzeugen falsche Schlüsse. > Lessons Learned sind nur wertvoll, wenn sie umgesetzt werden. > Change Enablement selbst muss kontinuierlich verbessert werden. --- **Verwandte Seiten** - 5.1 Change Enablement – Ziele, Begriffe und Abgrenzung - 5.2 Change-Typen und Risikobewertung - 5.3 Genehmigung, Planung und Umsetzung von Changes - 5.4 Release Management und Deployment Management - 4.5 Problem Management im Zusammenspiel mit Incident, Change und Knowledge Management - Knowledge Management - Service Configuration Management - Continual Improvement - Measurement and Reporting --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Change Enablement - PeopleCert – ITIL Practice Guide: Release Management - PeopleCert – ITIL Practice Guide: Deployment Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Measurement and Reporting - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Kennzahlen, - Review-Fragen, - Checklisten, - Beispiele, - Lessons-Learned-Hinweise, - und Improvement-Ansätze sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Change-Erfolgsquote, - Review-Pflicht für alle Changes, - KPI-Liste, - PIR-Vorlage, - Lessons-Learned-Struktur, - oder Reporting-Form für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Risiken, - Service Levels, - Organisation, - Change-Modell, - Release-Modell, - Datenqualität, - Werkzeuge, - Sicherheitsanforderungen, - und verfügbare Fähigkeiten angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026