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

Checkliste Post Implementation Review

Checkliste Failed Change

Checkliste Continual Improvement im Change Enablement

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker tragen wesentlich dazu bei, ob Change-Erfolg messbar und nachvollziehbar ist.

Im Arbeitsalltag bedeutet das:

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

Revision #1
Created 2 August 2026 15:41:14 by Admin
Updated 2 August 2026 15:41:25 by Admin