Change Management

Viele Störungen entstehen nicht von selbst, sondern durch Änderungen: ein Update, eine neue Firewall-Regel, ein umgestellter Server. Das Change Management sorgt dafür, dass solche Änderungen bewusst und mit abgeschätztem Risiko passieren. In ITIL 4 heißt die Praxis Change Enablement; der ältere Begriff Change Management ist aber weiterhin verbreitet.

Was ein Change ist

Nach ITIL ist ein Change das Hinzufügen, Ändern oder Entfernen von allem, was direkt oder indirekt Auswirkungen auf Services haben kann. Dazu gehören Hardware, Software, Konfigurationen, Dokumentation und Abläufe.

Wichtig: „Change Management“ bezeichnet im allgemeinen Sprachgebrauch auch die Begleitung von organisatorischem Wandel in Unternehmen. In diesem Eintrag geht es um die Bedeutung im IT-Service-Management.

Drei Arten von Changes

Typischer Ablauf eines normalen Changes

1. Antrag (Change Request): Was soll geändert werden, warum, wann?
2. Bewertung: Risiko, Auswirkungen, betroffene Nutzer*innen, Rückfallplan.
3. Freigabe: durch eine festgelegte Stelle (Change Authority), je nach Risiko eine Person oder ein Gremium.
4. Planung und Ankündigung: Zeitfenster wählen, Betroffene informieren.
5. Umsetzung: mit Test und, wenn nötig, Rückfall auf den alten Stand.
6. Überprüfung: Hat der Change das Ziel erreicht? Gab es Nebenwirkungen?

Bezug zum Support

Für den Support ist Change Management aus zwei Gründen wichtig:

• Störungen einordnen: Häufen sich nach einem Update die Incidents, ist der Change die naheliegende Spur. Wer weiß, was wann geändert wurde, findet Ursachen schneller.
• Probleme dauerhaft lösen: Die Ursache eines Problems wird meist über einen Change beseitigt.
• Vorbereitet sein: Wird der Servicedesk vorab über geplante Änderungen informiert, kann er Anfragen gleich richtig beantworten und mit Textbausteinen vorbereiten.

Beispiel

Ein IT-Dienstleister plant, am Samstag die Warenwirtschaft eines Kunden zu aktualisieren. Der Change wird am Mittwoch bewertet, am Donnerstag freigegeben und den Anwender*innen angekündigt. Der Servicedesk bekommt eine kurze Notiz: Was ändert sich, welche Fragen sind zu erwarten, wer ist am Montag Ansprechperson? Gehen am Montag Anfragen ein, ist die Antwort schon da.

Wie viel Formalität nötig ist

Ein kleines Team braucht kein Change-Gremium. Sinnvoll ist aber auch dort: geplante Änderungen kurz ankündigen, einen Rückfallplan haben und festhalten, was wann geändert wurde. Mehr Hintergrund zum IT-Support im Ratgeber IT-Ticketsystem.

Häufige Fehler

• Kein Rückfallplan: Geht das Update schief, wird improvisiert.
• Servicedesk nicht informiert: Der erste Hinweis auf die Änderung kommt vom verärgerten Kunden.
• Jeder Kleinkram als normaler Change: Wer auch Routineänderungen einzeln genehmigen lässt, erzeugt Stau und Umgehungen. Dafür gibt es Standard-Changes.

Für kleine Teams reicht oft eine einfache Änderungsliste: Datum, was geändert wurde, wer es gemacht hat, wie man es rückgängig macht.

So hilft rapidFOX

rapidFOX hat kein eigenes Change-Management-Modul mit Freigabeprozess. Was es bietet: Ein geplanter Change lässt sich als Ticket mit Mini-Projekt-Checkliste abbilden, Absprachen laufen über den internen Team-Chat, und die Wissensdatenbank hält fest, was geändert wurde. Mehr unter Servicedesk-Software.