5.2 Change-Typen und Risikobewertung Kurz erklärt Nicht jede Änderung besitzt dasselbe Risiko. Change Enablement unterscheidet deshalb verschiedene Change-Typen und bewertet Änderungen nach Risiko, Auswirkung, Dringlichkeit und Standardisierbarkeit. Ziel ist, einfache und risikoarme Änderungen schnell durchführen zu können, während kritische Änderungen sorgfältig geplant und kontrolliert werden. Warum Change-Typen wichtig sind Eine kleine Standardänderung sollte nicht denselben Aufwand verursachen wie eine kritische Produktionsumstellung. Beispiele: Passwort eines Testkontos zurücksetzen, Standardsoftware installieren, Firewall-Regel in Produktion ändern, Datenbankmigration durchführen, Sicherheitsupdate wegen aktiver Schwachstelle einspielen, zentrale Authentifizierung umstellen. Diese Änderungen unterscheiden sich stark in: Risiko, Auswirkung, Dringlichkeit, Wiederholbarkeit, Genehmigungsbedarf, Testaufwand, Kommunikationsbedarf, Rollback-Möglichkeit. Change-Typen helfen dabei, den passenden Umgang mit einer Änderung festzulegen. Grundidee der Change-Klassifizierung Eine Organisation sollte festlegen: welche Change-Typen verwendet werden, welche Kriterien dafür gelten, wer entscheiden darf, welche Genehmigung notwendig ist, welche Dokumentation erwartet wird, welche Tests erforderlich sind, wann Kommunikation notwendig ist, und wie der Erfolg geprüft wird. ITIL schreibt keine für alle Organisationen identische Change-Matrix vor. Die Einteilung muss zur Organisation, zu den Services und zu den Risiken passen. Typische Change-Typen Viele Organisationen unterscheiden mindestens: Change-Typ Kurzbeschreibung Standard Change vorab bewertete, wiederholbare und risikoarme Änderung Normal Change Änderung mit individueller Bewertung, Planung und Genehmigung Emergency Change dringende Änderung zur Abwehr akuter Schäden oder zur schnellen Wiederherstellung Major Change besonders umfangreiche, geschäftskritische oder risikoreiche Änderung Minor Change kleine Änderung mit begrenzter Auswirkung Routine Change regelmäßig vorkommende Änderung nach definiertem Ablauf Nicht jede Organisation verwendet alle Begriffe. Wichtig ist, dass die Begriffe intern eindeutig definiert sind. Standard Change Ein Standard Change ist eine Änderung, die bereits vorab geprüft und genehmigt wurde. Typische Merkmale: wiederholt sich häufig, besitzt geringes Risiko, Ablauf ist dokumentiert, Auswirkungen sind bekannt, Umsetzung ist standardisiert, Genehmigung ist bereits grundsätzlich erteilt, Rollen und Schritte sind klar, Erfolg ist leicht prüfbar. Beispiele: Standardsoftware aus genehmigtem Katalog installieren, Benutzer in eine genehmigte Standardgruppe aufnehmen, Standardarbeitsplatz bereitstellen, neues Standard-Monitoring für einen Server aktivieren, Zertifikat nach geprüftem Runbook erneuern, Standarddrucker einrichten. Ein Standard Change ist nicht ungeprüft. Er wurde nur bereits vorab bewertet. Normal Change Ein Normal Change wird individuell bewertet, geplant und genehmigt. Typische Merkmale: nicht vollständig standardisiert, Risiko muss bewertet werden, Auswirkungen müssen geprüft werden, Genehmigung ist erforderlich, Umsetzung muss geplant werden, Tests und Rollback müssen betrachtet werden. Beispiele: Update einer produktiven Anwendung, Änderung einer Firewall-Regel, Datenbankänderung, Umstellung eines Servers, Anpassung einer Schnittstelle, Änderung an einem produktiven Netzwerksegment, Einführung eines neuen Tools. Normal Changes benötigen je nach Risiko unterschiedlich viel Prüfung. Emergency Change Ein Emergency Change ist eine dringende Änderung, die wegen eines akuten Risikos oder Schadens schnell durchgeführt werden muss. Typische Auslöser: kritischer Service ist ausgefallen, Sicherheitslücke wird aktiv ausgenutzt, Datenverlust droht, Major Incident benötigt sofortige technische Maßnahme, kein sicherer Workaround ist verfügbar, dringende Wiederherstellung ist notwendig. Beispiele: kritischen Patch kurzfristig einspielen, fehlerhafte Konfiguration sofort zurückrollen, abgelaufenes Zertifikat bei Produktionsausfall erneuern, kompromittierten Zugang sperren, DNS oder Routing kurzfristig korrigieren. Emergency Changes dürfen nicht als Abkürzung für schlechte Planung genutzt werden. Auch unter Zeitdruck müssen Maßnahmen nachvollziehbar dokumentiert und nachträglich überprüft werden. Major Change Ein Major Change ist eine Änderung mit besonders hoher Auswirkung oder hohem Risiko. Beispiele: neues Rechenzentrum anbinden, zentrales Identity-System migrieren, ERP-System aktualisieren, Netzwerkarchitektur grundlegend ändern, neue Cloud-Plattform einführen, mehrere Standorte gleichzeitig umstellen, kritische Datenbank migrieren. Typische Merkmale: viele Stakeholder betroffen, hoher Planungsaufwand, mehrere Teams beteiligt, umfangreiche Tests notwendig, Kommunikationsplan erforderlich, Rollback komplex oder nur eingeschränkt möglich, Management-Entscheidung notwendig. Ein Major Change ist nicht automatisch ein Emergency Change. Er kann lange geplant sein und trotzdem sehr risikoreich sein. Minor Change Ein Minor Change ist eine kleinere Änderung mit begrenzter Auswirkung. Beispiele: kleine Konfigurationsanpassung an einem nicht kritischen System, Ergänzung einer Monitoringbeschreibung, Anpassung eines Formularfelds, Änderung eines nicht produktiven Testsystems, kleinere Dokumentationsänderung. Auch kleine Changes können Risiken besitzen. Beispiel: Eine scheinbar kleine Firewall-Regel kann große Auswirkungen haben, wenn sie einen kritischen Service betrifft. Change-Typen im Vergleich Kriterium Standard Change Normal Change Emergency Change Risiko gering und vorab bewertet individuell zu bewerten häufig hoch oder zeitkritisch Dringlichkeit planbar planbar akut Genehmigung vorab genehmigt je nach Risiko erforderlich beschleunigt oder nachträglich ergänzt Ablauf standardisiert individuell geplant schnell, aber kontrolliert Dokumentation standardisiert vollständig nach Bedarf mindestens entscheidungsrelevant Beispiele Standardsoftware produktives Update kritischer Sicherheitspatch Risikobewertung Risikobewertung bedeutet, mögliche negative Folgen eines Changes vor der Umsetzung zu betrachten. Typische Fragen: Was kann schiefgehen? Welche Services wären betroffen? Welche Benutzer oder Kunden wären betroffen? Wie wahrscheinlich ist ein Fehler? Wie schwer wären die Auswirkungen? Wie gut ist der Change getestet? Gibt es einen Rollback? Gibt es ein Wartungsfenster? Gibt es Abhängigkeiten? Gibt es Sicherheits- oder Datenschutzrisiken? Wer muss informiert werden? Risiko entsteht aus Wahrscheinlichkeit und Auswirkung. Auswirkung bewerten Die Auswirkung beschreibt, wie stark Benutzer, Services oder Geschäftsprozesse betroffen wären. Zu prüfen ist: Ist ein geschäftskritischer Service betroffen? Sind interne Benutzer betroffen? Sind externe Kunden betroffen? Sind mehrere Standorte betroffen? Gibt es Auswirkungen auf Produktion, Verkauf, Abrechnung oder Support? Können Daten verloren gehen? Können Sicherheitsanforderungen verletzt werden? Sind gesetzliche oder vertragliche Anforderungen betroffen? Gibt es Abhängigkeiten zu anderen Services? Je größer die mögliche Auswirkung, desto sorgfältiger muss der Change gesteuert werden. Wahrscheinlichkeit bewerten Die Wahrscheinlichkeit beschreibt, wie wahrscheinlich ein Fehler bei der Änderung ist. Einflussfaktoren: Komplexität der Änderung, Erfahrung des Teams, Qualität der Tests, Reife des Runbooks, Anzahl beteiligter Systeme, Anzahl manueller Schritte, bekannte Fehler, Stabilität der Umgebung, Lieferantenabhängigkeit, Neuartigkeit der Änderung. Eine Änderung mit geringer Auswirkung, aber hoher Fehlerwahrscheinlichkeit kann trotzdem relevant sein. Dringlichkeit bewerten Nicht jede dringende Änderung ist automatisch ein Emergency Change. Zu prüfen ist: Warum ist die Änderung dringend? Gibt es einen akuten Schaden? Droht ein Sicherheitsvorfall? Läuft eine Frist ab? Gibt es einen Workaround? Kann die Änderung bis zum nächsten Wartungsfenster warten? Wird die Dringlichkeit durch schlechte Planung verursacht? Welche Risiken entstehen durch sofortige Umsetzung? Dringlichkeit darf nicht dazu führen, dass grundlegende Sicherheits- und Dokumentationspflichten ignoriert werden. Nutzen bewerten Neben Risiko und Dringlichkeit muss der Nutzen betrachtet werden. Möglicher Nutzen: Incident dauerhaft beheben, Sicherheitsrisiko reduzieren, Performance verbessern, Kosten senken, Benutzererfahrung verbessern, gesetzliche Anforderungen erfüllen, technische Schulden reduzieren, Stabilität erhöhen, Automatisierung ermöglichen, Betrieb vereinfachen. Ein Change kann sinnvoll sein, obwohl er Risiko besitzt. Entscheidend ist, ob Nutzen und Risiko bewusst bewertet wurden. Typische Risikokriterien Kriterium Beispiele Servicekritikalität produktiv, geschäftskritisch, Testsystem Benutzerimpact einzelne Person, Team, Standort, Kunden Technische Komplexität einfache Konfiguration, Migration, Architekturänderung Rollback-Fähigkeit einfach, schwierig, nicht möglich Testabdeckung vollständig getestet, teilweise getestet, nicht getestet Sicherheitsbezug Berechtigungen, Firewall, Daten, Logging Zeitpunkt Geschäftszeit, Wartungsfenster, Monatsabschluss Abhängigkeiten Datenbank, Netzwerk, Identität, Lieferant Erfahrung häufig durchgeführt, neu, einmalig Kommunikationsbedarf keine Benutzerinfo, interne Info, Kundenkommunikation Einfache Risikomatrix Eine einfache Matrix kann helfen. Auswirkung Wahrscheinlichkeit niedrig Wahrscheinlichkeit mittel Wahrscheinlichkeit hoch hoch mittel hoch sehr hoch mittel niedrig mittel hoch niedrig niedrig niedrig mittel Diese Matrix ist nur ein Beispiel. Die Organisation muss eigene Bewertungsstufen festlegen. Beispiel für Change-Risikostufen Risikostufe Bedeutung Niedrig begrenzte Auswirkung, gut getestet, einfacher Rollback Mittel mehrere Benutzer oder wichtiger Service betroffen, Rollback möglich Hoch kritischer Service, viele Benutzer, komplexe Änderung Sehr hoch geschäftskritisch, schwieriger Rollback, erhebliche Sicherheits- oder Datenrisiken Die Risikostufe beeinflusst: Genehmigung, Testtiefe, Kommunikationsbedarf, Wartungsfenster, Dokumentationsumfang, Beteiligung von Spezialisten, Nachprüfung. Change Authority passend wählen Die Genehmigungsinstanz sollte zum Risiko passen. Beispiele: Change mögliche Change Authority Standardsoftware installieren vorab genehmigter Standardprozess kleine Konfigurationsänderung Team Lead oder Service Owner produktives Anwendungsupdate Change Manager oder Change Advisory Board sicherheitskritische Firewall-Regel Informationssicherheit und Service Owner Emergency Security Patch Emergency Change Authority große Plattformmigration Management, Service Owner, Change Board Nicht jede Änderung benötigt ein großes Gremium. Aber risikoreiche Änderungen brauchen ausreichend Perspektiven. Wann ein Change Advisory Board sinnvoll ist Ein Change Advisory Board kann sinnvoll sein, wenn: mehrere Services betroffen sind, mehrere Teams beteiligt sind, hohes Risiko besteht, der Rollback schwierig ist, Benutzer oder Kunden informiert werden müssen, Sicherheitsfragen bestehen, Lieferanten beteiligt sind, mehrere Changes zeitlich kollidieren, oder Managemententscheidungen notwendig sind. Ein CAB sollte beraten und Risiken sichtbar machen. Es sollte nicht jede Routineänderung unnötig verzögern. Emergency Change Authority Für Emergency Changes kann eine kleinere, schnell erreichbare Entscheidungsgruppe sinnvoll sein. Mögliche Beteiligte: Incident Manager, Change Manager, Service Owner, Informationssicherheit, verantwortliches Fachteam, Management bei hohem Geschäftsrisiko. Wichtig ist: Entscheidung dokumentieren, Risiko akzeptieren oder begründen, Umsetzung kontrollieren, Ergebnis prüfen, nachträgliches Review durchführen. Standard Change richtig definieren Ein Standard Change sollte nicht leichtfertig als Standard eingestuft werden. Vorab zu klären: Ist der Ablauf wiederholbar? Ist das Risiko niedrig? Sind Auswirkungen bekannt? Gibt es ein geprüftes Runbook? Sind Berechtigungen klar? Gibt es definierte Erfolgskriterien? Gibt es Abbruchkriterien? Wird die Ausführung protokolliert? Wird der Standard regelmäßig überprüft? Wenn ein Standard Change häufig fehlschlägt, muss er neu bewertet werden. Emergency Change Missbrauch vermeiden Emergency Changes sollten nicht genutzt werden, nur weil: ein Request zu spät gestellt wurde, Planung vergessen wurde, Genehmigung umgangen werden soll, ein Team schneller arbeiten möchte, normale Change-Zeiten als störend empfunden werden. Ungeeignet: Wir machen daraus einen Emergency Change, damit wir keine Freigabe brauchen. Besser: Es liegt kein akuter Schaden vor. Der Change wird als Normal Change mit beschleunigter Planung behandelt. Risiko durch Nicht-Handeln Nicht nur Durchführung kann riskant sein. Auch Nicht-Handeln kann Risiko erzeugen. Beispiele: Sicherheitslücke bleibt offen, Zertifikat läuft bald ab, Speicher läuft voll, instabile Version bleibt produktiv, gesetzliche Frist wird verpasst, Workaround belastet Betrieb dauerhaft, bekannte Fehler erzeugen weitere Incidents. Eine gute Bewertung betrachtet deshalb: Risiko des Changes, Risiko des Nicht-Handelns, Risiko einer Verzögerung, Risiko des Workarounds. Rollback und Backout in der Risikobewertung Ein Change ist weniger riskant, wenn ein zuverlässiger Rollback möglich ist. Zu prüfen ist: Kann die Änderung vollständig zurückgenommen werden? Wie lange dauert der Rollback? Sind Backups vorhanden? Wurden Konfigurationen gesichert? Werden Daten verändert? Gibt es Abhängigkeiten? Wer entscheidet über Abbruch? Wann ist der späteste sichere Abbruchzeitpunkt? Wenn kein Rollback möglich ist, muss besonders sorgfältig getestet und kommuniziert werden. Testumfang nach Risiko Der Testumfang sollte zur Risikostufe passen. Risiko möglicher Testumfang niedrig Standardprüfung, kurzer Funktionstest mittel Testsystem, Review, definierter Smoke Test hoch ausführlicher Testplan, Abhängigkeitstest, Rollback-Test sehr hoch Pilot, Lasttest, Sicherheitsprüfung, Managementfreigabe Tests sollten nicht nur prüfen, ob die Änderung technisch durchgeführt wurde. Sie sollten prüfen, ob der Service danach wie erwartet nutzbar ist. Kommunikationsbedarf nach Risiko Je höher Risiko und Auswirkung, desto wichtiger wird Kommunikation. Zu informieren sind je nach Change: betroffene Benutzer, Service Desk, Fachbereiche, Management, Lieferanten, Informationssicherheit, Kunden, Bereitschaftsdienst. Inhalt der Kommunikation: Was wird geändert? Wann wird geändert? Welche Auswirkungen sind möglich? Gibt es eine Unterbrechung? Was müssen Benutzer tun? Wo gibt es Statusinformationen? Wann gilt der Change als abgeschlossen? Wartungsfenster bewerten Ein Wartungsfenster sollte passend gewählt werden. Zu berücksichtigen sind: Servicezeiten, Geschäftsprozesse, internationale Zeitzonen, Monats- oder Jahresabschluss, Produktionszeiten, Kundenverkehr, Backupfenster, Lieferantenverfügbarkeit, Bereitschaft, Rollbackdauer. Ein technisch bequemes Wartungsfenster ist nicht automatisch geschäftlich sinnvoll. Abhängigkeiten und Change-Kollisionen Mehrere Changes können sich gegenseitig beeinflussen. Beispiele: Netzwerkteam ändert Routing, während Anwendungsteam ein Deployment durchführt. Datenbankwartung fällt mit Reporting-Lauf zusammen. Cloud-Team ändert Identitätsdienst, während VPN-Client aktualisiert wird. Backupfenster überschneidet sich mit Datenbankmigration. Change Enablement sollte prüfen: Welche Changes laufen gleichzeitig? Betreffen sie gleiche Services oder CIs? Können sie sich gegenseitig beeinflussen? Gibt es ein Change Freeze? Muss eine Reihenfolge festgelegt werden? Change Freeze Ein Change Freeze ist ein Zeitraum, in dem Änderungen eingeschränkt werden. Beispiele: Jahresabschluss, kritische Verkaufsphase, Produktionshochlauf, Prüfung oder Audit, große Migration, Feiertagsgeschäft. Ein Change Freeze verhindert nicht zwingend jede Änderung. Emergency Changes oder wichtige Sicherheitsmaßnahmen können trotzdem notwendig sein. Dann muss besonders bewusst entschieden werden. Sicherheitsrisiken bewerten Besonders sorgfältig zu bewerten sind Changes an: Firewall-Regeln, Identitätsdiensten, Administratorrechten, MFA, Logging, Verschlüsselung, Zertifikaten, externen Schnittstellen, Cloud-Berechtigungen, Datenfreigaben, Sicherheitssoftware. Fragen: Werden neue Zugriffe eröffnet? Werden Rechte erweitert? Werden Schutzmaßnahmen deaktiviert? Werden Logs reduziert? Werden sensible Daten berührt? Gibt es ein Prüf- oder Rezertifizierungsverfahren? Datenschutz und Compliance Manche Changes betreffen Datenschutz oder Compliance. Beispiele: neue Datenverarbeitung, neue Schnittstelle, neue Cloud-Ablage, geänderte Aufbewahrung, geänderte Protokollierung, Zugriff auf personenbezogene Daten, Standortwechsel von Daten, Einführung eines neuen Tools. Dann können zusätzliche Prüfungen erforderlich sein. Beispielsweise durch Datenschutz, Informationssicherheit, Compliance oder Rechtsabteilung. Lieferantenrisiken Bei Changes mit Lieferantenbezug zu prüfen: Ist der Lieferant verfügbar? Gibt es Support während des Wartungsfensters? Gibt es Herstellerhinweise? Ist die Version unterstützt? Gibt es bekannte Fehler? Wer führt welche Aufgabe aus? Welche Eskalationswege gelten? Welche SLA oder Verträge sind betroffen? Wie wird das Ergebnis abgenommen? Auch externe Changes müssen intern nachvollziehbar gesteuert werden. Change-Erfolgskriterien Vor der Umsetzung sollte klar sein, wann ein Change erfolgreich ist. Beispiele: Anwendung startet ohne Fehler, Benutzer können sich anmelden, Schnittstelle überträgt Daten korrekt, Monitoring ist grün, keine neuen Fehler in Logs, Performance bleibt im Zielbereich, Sicherheitsprüfung erfolgreich, Service Desk erhält keine Störungswelle, Fachbereich bestätigt Funktion. Ohne Erfolgskriterien ist die Nachprüfung unklar. Failed Change und Lessons Learned Ein Change kann fehlschlagen. Wichtig ist dann: Auswirkungen begrenzen, Rollback durchführen, falls erforderlich, Benutzer informieren, Incident oder Problem verknüpfen, Ursache des Fehlschlags untersuchen, Change-Modell verbessern, Tests anpassen, Dokumentation korrigieren. Ziel ist Lernen, nicht Schuldzuweisung. Praxisbeispiel: Standard Change Änderung Standardsoftware aus genehmigtem Katalog wird installiert. Bewertung Ablauf ist bekannt, Software ist geprüft, Zielgruppe ist definiert, Risiko ist niedrig, Installation ist automatisiert, Rollback ist möglich. Umgang Der Change kann als Standard Change über das Serviceportal ausgeführt werden. Praxisbeispiel: Normal Change Änderung Eine produktive Fachanwendung erhält ein Versionsupdate. Bewertung mehrere Fachbereiche betroffen, Testsystem vorhanden, Wartungsfenster notwendig, Rollback möglich, aber zeitaufwendig, Benutzerkommunikation erforderlich. Umgang Der Change wird geplant, getestet, genehmigt und nach Umsetzung geprüft. Praxisbeispiel: Emergency Change Änderung Eine aktiv ausgenutzte Sicherheitslücke muss kurzfristig geschlossen werden. Bewertung Risiko des Nicht-Handelns sehr hoch, Testzeit begrenzt, Produktionssystem betroffen, Management und Informationssicherheit müssen eingebunden werden. Umgang Emergency Change wird kontrolliert durchgeführt, dokumentiert und nachträglich reviewed. Praxisbeispiel: Falsch eingestufter Change Situation Eine Firewall-Regel wird als kleine Routineänderung behandelt. Problem Die Regel betrifft eine zentrale Schnittstelle zur Warenwirtschaft. Nach Umsetzung kann der Versand keine Aufträge mehr übertragen. Lerneffekt Der Change war technisch klein, aber geschäftlich kritisch. Künftig werden Firewall-Changes nach betroffenen Services und Geschäftsprozessen bewertet, nicht nur nach technischem Aufwand. Typische Fehler Fehler 1 Jede Änderung wird gleich behandelt. Fehler 2 Ein riskanter Change wird fälschlich als Standard Change eingestuft. Fehler 3 Emergency Change wird als Abkürzung genutzt. Fehler 4 Nur technische Risiken werden bewertet. Fehler 5 Risiko des Nicht-Handelns wird ignoriert. Fehler 6 Rollback wird erst während der Störung überlegt. Fehler 7 Tests passen nicht zum Risiko. Fehler 8 Benutzer und Service Desk werden nicht informiert. Fehler 9 Abhängigkeiten und parallele Changes werden nicht geprüft. Fehler 10 Sicherheits- und Datenschutzrisiken werden zu spät erkannt. Fehler 11 Change-Erfolgskriterien fehlen. Fehler 12 Failed Changes werden nicht ausgewertet. Checkliste Change-Typ bestimmen Ist die Änderung wiederholbar? Ist der Ablauf dokumentiert? Ist das Risiko vorab bewertet? Ist die Änderung bereits vorab genehmigt? Gibt es akuten Zeitdruck? Droht Schaden bei Verzögerung? Ist ein produktiver Service betroffen? Sind mehrere Teams beteiligt? Ist ein Rollback möglich? Gibt es Sicherheits- oder Datenschutzbezug? Muss ein Service Owner entscheiden? Passt Standard, Normal oder Emergency Change? Checkliste Risikobewertung betroffener Service bekannt betroffene CIs bekannt Benutzer- oder Kundenimpact bewertet geschäftliche Auswirkungen bewertet technische Komplexität bewertet Sicherheitsrisiken geprüft Datenschutz oder Compliance geprüft Abhängigkeiten geprüft parallele Changes geprüft Testumfang festgelegt Rollback oder Backout geprüft Kommunikationsbedarf bewertet Risiko des Nicht-Handelns bewertet Checkliste Emergency Change akuter Schaden oder hohes Risiko liegt vor Grund für Dringlichkeit dokumentiert Entscheidungsträger eingebunden Risiko bewertet Mindesttest durchgeführt, soweit möglich Rollback geprüft Umsetzung dokumentiert Service Desk informiert Benutzer oder Stakeholder informiert, falls notwendig Ergebnis geprüft nachträgliches Review geplant Folgeproblem oder Improvement erstellt, falls nötig Bedeutung für Fachinformatiker für Systemintegration Fachinformatiker müssen Change-Typen und Risiken praktisch einschätzen können. Im Arbeitsalltag bedeutet das: nicht jede Änderung sofort produktiv durchführen, technische und geschäftliche Auswirkungen bedenken, betroffene Services und Abhängigkeiten prüfen, Rollback vor der Umsetzung planen, Tests passend zum Risiko durchführen, Service Desk und Benutzer informieren, Changes sauber dokumentieren, und aus fehlgeschlagenen Changes lernen. Gerade kleine technische Änderungen können große Auswirkungen haben, wenn sie einen kritischen Service betreffen. Zusammenfassung Änderung erkennen ↓ Change-Typ bestimmen ↓ Auswirkung und Wahrscheinlichkeit bewerten ↓ Risiko des Changes und Risiko des Nicht-Handelns vergleichen ↓ Test, Rollback und Kommunikation planen ↓ passende Change Authority einbinden ↓ Änderung kontrolliert durchführen ↓ Erfolg prüfen ↓ Lessons Learned übernehmen Merksätze Nicht jede Änderung benötigt denselben Prozessaufwand. Ein Standard Change ist vorab bewertet, nicht ungeprüft. Ein Emergency Change ist kein Ersatz für schlechte Planung. Technisch klein bedeutet nicht automatisch risikoarm. Risiko entsteht aus Auswirkung, Wahrscheinlichkeit und Kontext. Auch Nicht-Handeln kann riskant sein. Der Change-Typ muss zur tatsächlichen Auswirkung passen. Verwandte Seiten 5.1 Change Enablement – Ziele, Begriffe und Abgrenzung 5.3 Genehmigung, Planung und Umsetzung von Changes 5.4 Release Management und Deployment Management 5.5 Change-Erfolg messen und Continual Improvement Incident Management Problem Management Service Configuration Management Information Security Management Quellen und Versionsstand Offizielle Grundlagen PeopleCert – ITIL Practice Guide: Change Enablement PeopleCert – ITIL Practice Guide: Incident Management PeopleCert – ITIL Practice Guide: Problem Management PeopleCert – ITIL Practice Guide: Information Security Management PeopleCert – ITIL Practice Guide: Service Configuration Management ITIL Foundation – Version 5 Einordnung Die dargestellten: Change-Typen, Risikokriterien, Matrizen, Checklisten, Praxisbeispiele, und Bewertungsfragen sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: Change-Typen-Matrix, Risikoskala, Genehmigungsmatrix, CAB-Pflicht, Testvorgabe, oder Emergency-Change-Struktur für alle Organisationen vor. Die konkrete Umsetzung muss an: Services, Risiken, Organisation, Service Levels, Sicherheitsanforderungen, Change-Modell, Lieferanten, Datenqualität, 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