Support & Automatisierung

Change Request (Änderungsantrag)

Allgemeine Infos

Ein Change Request (früher Request for Change, RfC) ist der einzelne, dokumentierte Antrag auf eine Änderung an IT-Systemen, etwa ein Firmware-Update der Firewall, eine neue Conditional-Access-Richtlinie oder die Migration eines Servers. Er ist das Arbeitsobjekt des Change-Management-Prozesses und wird im Ticketsystem als eigener Tickettyp geführt.

ITIL unterscheidet drei Arten: Standard Changes sind risikoarm, wiederkehrend und vorab genehmigt (z. B. Speicher erweitern nach Vorlage). Normal Changes durchlaufen Risikobewertung und Freigabe durch eine Change Authority oder bei hohem Risiko durch das Change Advisory Board (CAB). Emergency Changes werden bei akuten Störungen oder Sicherheitslücken beschleunigt freigegeben und nachträglich dokumentiert.

Abgrenzung: Change Management ist der übergeordnete Prozess (in ITIL 4 Change Enablement). Der Change Request ist der einzelne Antrag darin. Ein Service Request ist eine Standardanfrage ohne Änderungsrisiko, z. B. eine Softwareinstallation aus dem Katalog.

Funktionsweise & Details

Ein vollständiger Change Request enthält:

  1. Beschreibung und Begründung: Was wird geändert, warum, welcher Nutzen.
  2. Betroffene Systeme und Services, Abhängigkeiten aus CMDB oder Asset-Verzeichnis.
  3. Risikobewertung: Auswirkung und Eintrittswahrscheinlichkeit, daraus Change-Typ und Genehmigungsstufe.
  4. Umsetzungsplan mit Zeitpunkt im Wartungsfenster, Verantwortlichen und Testschritten.
  5. Rückfallplan (Backout): Wie wird zurückgerollt, z. B. Snapshot, Konfigurationsexport, alte Richtlinie.
  6. Freigabe durch Change Authority oder CAB, dokumentiert im Ticket.
  7. Abschluss: Ergebnis, Abweichungen, Review bei Fehlschlag.

Vorlagen für Standard Changes beschleunigen häufige Änderungen, weil Risikobewertung und Freigabe einmalig erfolgen.

Vorteile & Nutzen

  • Änderungen werden vor der Umsetzung durchdacht, das verhindert viele selbstverursachte Ausfälle
  • Ein vorbereiteter Rückfallplan verkürzt die Ausfallzeit, wenn doch etwas schiefgeht
  • Bei Störungen ist sofort sichtbar, welche Änderung zuletzt am betroffenen System erfolgte
  • Nachvollziehbare Freigaben erfüllen Anforderungen aus BSI IT-Grundschutz (OPS.1.1.3) und NIS2

Praxisbeispiel

Ein Spezialchemiehersteller mit 400 Mitarbeitenden hatte wiederholt Ausfälle nach ungeplanten Firewall-Änderungen. Die IT führte im Ticketsystem den Tickettyp Change Request mit Pflichtfeldern für Risiko und Rückfallplan ein, Standard Changes wie neue Portfreigaben nach Vorlage gibt der Teamleiter frei, Normal Changes bespricht ein wöchentliches CAB mit IT-Leitung und Produktions-IT. Störungen durch Änderungen gingen spürbar zurück, und bei Problemen war die auslösende Änderung schnell gefunden.

Worauf sollte man achten?

  • Standard Changes konsequent als Vorlagen definieren, sonst wird der Prozess als Bremse empfunden und umgangen
  • Emergency Changes zeitnah nachdokumentieren und im nächsten CAB besprechen
  • Rückfallplan vor der Umsetzung testen oder zumindest Snapshot und Konfigurationssicherung prüfen
  • Change Requests mit Incidents verknüpfen, um Auswirkungen von Änderungen messbar zu machen

Fazit

Der Change Request ist das wichtigste Werkzeug gegen selbstverursachte Ausfälle. Halte das Formular schlank, nutze Standard Changes und bestehe auf einem Rückfallplan.

Weiterführende Links

Verwandte Artikel