Change Management (in ITIL 4 als Change Enablement bezeichnet) ist die Praxis, die sicherstellt, dass Änderungen an IT-Services und IT-Infrastruktur so durchgeführt werden, dass Risiken minimiert und Nutzen maximiert werden. Der Kern der Praxis: Jede bedeutende Änderung durchläuft einen definierten Prozess aus Erfassung, Bewertung, Genehmigung, Umsetzung und Nachverfolgung.
In der SAP-Welt bekommt Change Management eine zusätzliche Dimension. Jede SAP-Änderung materialisiert sich als Transport Request, wird durch eine Systemkette (typisch: Development → Quality Assurance → Production) bewegt und dort importiert. Der Change-Management-Prozess verwaltet nicht nur die Entscheidung, ob eine Änderung durchgeführt wird, sondern auch die Orchestrierung des technischen Artefakts über die Landschaft hinweg. Das unterscheidet SAP-Change-Management von generischem IT-Change-Management.
Der formale Startpunkt jeder Änderung ist der Request for Change (RfC). Er enthält Beschreibung, Begründung, Auswirkung, Risikoeinschätzung, betroffene Systeme und den gewünschten Umsetzungszeitraum. Der RfC wird klassifiziert, bewertet, genehmigt und an die Umsetzung übergeben. Am Ende steht nicht der erfolgreiche Import, sondern der Post-Implementation Review.
SAP-Systeme sind in den meisten Unternehmen Kernsysteme. Ein fehlgeschlagener Transport in einem ERP-System kann Finanzabschluss, Lieferkette oder Kundenprozesse stören. Die Kosten einer einzigen Fehlfreigabe liegen schnell im sechsstelligen Bereich, in regulierten Branchen können sie Audit-Feststellungen und Bussgeldverfahren nach sich ziehen.
Die Rahmenbedingungen für Change Management haben sich in den letzten Jahren deutlich verschärft:
Regulatorischer Druck. SOX (Sarbanes-Oxley) verlangt seit 2002 dokumentierte Kontrollen über Änderungen an finanzrelevanten Systemen. GxP (Pharma und Life Sciences) fordert dasselbe für validierte Systeme. DORA (Digital Operational Resilience Act) erweitert die Anforderungen seit 2024 auf Finanzdienstleister in der EU. Der EU AI Act ergänzt seit 2025 Kontrollanforderungen für KI-gestützte Systeme. All diese Regularien erwarten nicht nur einen Change-Prozess, sondern dessen technische Erzwingbarkeit und Nachweisbarkeit.
Hybride Landschaften. Moderne SAP-Kunden betreiben selten nur S/4HANA. Typisch sind Kombinationen aus On-Premise-Installationen, S/4HANA Cloud, BW/4HANA, SAP BTP, SuccessFactors, Ariba, SAP Analytics Cloud und diverse Non-SAP-Systeme. Jedes dieser Systeme hat eigene Änderungs- und Transportmechanismen. Das Change Management muss diese Vielfalt zusammenhalten, ohne sie zu ignorieren.
Geschwindigkeitserwartungen aus dem Business. Fachbereiche erwarten Änderungen in Tagen, nicht in Wochen. Agile Projektmethoden und DevOps-Ansätze drücken in Richtung kürzerer Zyklen. Change Management wird dadurch nicht überflüssig, sondern verschiebt seinen Fokus: Weg von der manuellen CAB-Diskussion über jede Kleinigkeit, hin zu Standardisierung, Vorab-Genehmigung und Automation von risikoarmen Änderungen.
Die Kundenpraxis zeigt: Unternehmen, die ihren Change-Prozess ernsthaft professionalisiert haben, berichten von deutlich kürzeren Durchlaufzeiten und gleichzeitig höherer Produktionsstabilität. Unternehmen, die Change Management als lästige Pflicht führen, erleben die gegenteilige Entwicklung. Zunehmende Zahl an Changes, zunehmende Zahl an Produktionsfehlern, Team-Frustration.
ITIL 4 unterscheidet drei Change-Typen, die auch im SAP-Umfeld als Grundstruktur dienen. In der SAP-Praxis hat sich zusätzlich ein vierter Typ etabliert, der im COI_SAP_Feature_Registry als Documentary Change geführt wird.
Standard Change. Vorab genehmigte, risikoarme, wiederholbare Änderung. Beispiel: Stammdatenpflege nach definiertem Schema, Customizing-Anpassungen aus einer Whitelist, Standard-Systemkopien. Der Standard Change durchläuft keinen CAB, sondern folgt einem automatisierten Prozess. Er ist der stärkste Hebel, um Change-Management-Kapazität freizusetzen.
Normal Change. Der klassische Change mit vollständiger Risikobewertung, Auswirkungsanalyse, Testabdeckung und CAB-Entscheidung. Normal Changes werden nach Risiko klassifiziert (minor, major) und entsprechend durch den Prozess geführt.
Emergency Change. Änderung mit hoher Dringlichkeit, meist zur Behebung eines kritischen Incidents oder einer Sicherheitslücke. Durchläuft ein abgekürztes Genehmigungsverfahren (Emergency CAB oder Einzelgenehmigung). Wird nachträglich dokumentiert und im nächsten regulären CAB nachbesprochen. Emergency Changes sind keine Abkürzung um den Prozess, sondern eine beschleunigte Variante mit nachgelagerter Dokumentation.
Documentary Change. Änderung, die ausserhalb des technischen Transportwesens erfolgt (etwa direkte Customizing-Anpassungen in Produktion), aber trotzdem dokumentiert werden muss. In vielen Landschaften sind Documentary Changes der blinde Fleck. Sie finden statt, werden aber nicht erfasst. Damit fehlt ein Teil des Audit Trails.
Ein belastbarer Change-Prozess folgt einem Statusworkflow mit klaren Übergängen. Ein typischer Ablauf:
Erfasst → Klassifiziert → Bewertet → Genehmigt → In Umsetzung → In Test → Freigegeben zur Produktion → Produktiv → Abgeschlossen.
Jeder Statusübergang ist an eine Rolle gebunden, wird technisch protokolliert und lässt sich nicht ohne Spur überspringen. Rücksprünge (zum Beispiel aus "In Test" zurück in "In Umsetzung") sind möglich, werden aber dokumentiert. Der Statusworkflow ist das technische Rückgrat von Nachvollziehbarkeit und Auditfähigkeit.
Der Change Advisory Board (CAB) ist das Entscheidungsgremium für Normal Changes. Er bewertet Risiko, Auswirkung, Abhängigkeiten zu anderen Changes, Testabdeckung und Timing. Der CAB entscheidet nicht technisch, sondern aus Gesamtsicht. Typische CAB-Teilnehmer: Change Manager, SAP Basis, Release Manager, Fachbereichsvertreter, Security, bei Bedarf Wirtschaftsprüfer.
Ein wirksamer CAB ist nicht der Ort, an dem jeder Change im Detail diskutiert wird. Er ist der Ort, an dem das Change-Portfolio gesteuert wird. Standardentscheidungen werden vorab delegiert, Routine-Changes als Standard Change vorklassifiziert. Der CAB konzentriert sich auf das, was wirklich Abwägung braucht: Grösse, Timing, Risiko, Abhängigkeiten.
Ein zentrales Kontrollprinzip. Niemand genehmigt seinen eigenen Change. Der Entwickler, der die Änderung programmiert, ist nicht derselbe, der sie testet. Der Tester ist nicht derselbe, der sie produktiv freigibt. In regulierten Branchen ist diese Trennung nicht optional, sondern Grundlage des internen Kontrollsystems. Im SAP-Berechtigungskonzept wird sie über Rollen und Transport-Berechtigungen technisch erzwungen.
Standard Changes werden wie Normal Changes behandelt. Das ist der häufigste Fehler in SAP-Change-Prozessen. Wiederkehrende, risikoarme Änderungen durchlaufen den vollen CAB, binden Kapazität und frustrieren die Beteiligten. Der CAB verliert seine Entscheidungsfunktion, weil er mit Trivialitäten überladen ist.
Emergency Changes werden zur Abkürzung missbraucht. Wenn der reguläre Prozess zu langsam ist, erklären Teams ihren Change zum Emergency, um die CAB-Wartezeit zu umgehen. Das Ergebnis: Ein grosser Teil der Changes wird als Emergency klassifiziert, der Audit sieht Missbrauch des Prozesses und der eigentliche Zweck des Emergency Change (schnelle Reaktion auf echte Krisen) verwässert.
Documentary Changes fehlen im Audit Trail. Customizing-Anpassungen, die direkt in Produktion erfolgen, werden oft nicht in das zentrale Change-System eingetragen. Im Audit fehlt damit ein Teil der Historie. Das ist kein technisches, sondern ein Prozessproblem.
CAB-Meetings als Statusmeeting. Der CAB wird zum wöchentlichen Statusbericht, in dem Changes abgenickt werden, die längst eskaliert wurden. Echte Entscheidungen finden informell zwischen den Meetings statt. Die formale Dokumentation bleibt, die Wirksamkeit der Kontrolle ist dahin.
Kein technisch erzwungenes Vier-Augen-Prinzip. Separation of Duties steht im Prozesshandbuch, wird aber nicht im Berechtigungskonzept durchgesetzt. Entwickler können im Zweifel ihre eigenen Changes nach Produktion transportieren. Das fällt im SOX-Audit als Kontrollfeststellung auf.
Unverbundene Tool-Landschaft. Anforderungen werden in Jira erfasst, Changes in SolMan, Test-Defects in einem dritten Tool, Release-Status in Excel. Jede Übergabe produziert Datenverluste. Der Audit Trail ist Stückwerk.
Emergency CAB, der nicht existiert. Viele Unternehmen haben einen Emergency-Change-Prozess im Handbuch, aber keinen benannten Emergency CAB mit Erreichbarkeit und Entscheidungsbefugnis ausserhalb der Geschäftszeiten. Wenn nachts um 23 Uhr ein Emergency Change nötig ist, wird entweder gar nichts entschieden oder die Kontrolle übergangen.
1. Change-Klassifizierung vor Prozessbeginn. Jeder RfC wird zu Beginn klassifiziert: Standard, Normal minor, Normal major, Emergency, Documentary. Die Klassifikation steuert den gesamten weiteren Ablauf. Sie ist kein nachträgliches Label, sondern eine Prozessentscheidung.
2. Eine belastbare Standard-Change-Whitelist. Das sind wiederkehrende, risikoarme Änderungen, die vorab genehmigt sind. Typische Kandidaten: bestimmte Customizing-Änderungen, Stammdatenpflege nach Schema, Rollenzuweisungen aus einem definierten Set, Systemmonitoring-Anpassungen. Die Whitelist wird vom CAB verabschiedet, regelmässig überprüft und technisch durchgesetzt.
3. CAB mit klarer Agenda und klarer Entscheidungsbefugnis. Der CAB trifft sich in fester Frequenz (typisch wöchentlich), mit fester Teilnehmerliste und definierter Tagesordnung. Entscheidungen werden dokumentiert, nicht nur angenickt. Abwesenheiten werden durch Vertretungsregelung kompensiert.
4. Emergency-Prozess mit benanntem Emergency CAB. Ausserhalb der Geschäftszeiten gibt es eine benannte, erreichbare Instanz, die Emergency Changes genehmigen darf. Die Freigabe wird technisch protokolliert. Am nächsten Werktag wird der Emergency im regulären CAB nachbesprochen.
5. Documentary Changes systematisch erfassen. Alles, was technisch ausserhalb des Transports passiert, aber prozessual Change ist, wird zentral erfasst. Das schliesst direkte Customizing-Anpassungen, manuelle Berechtigungsvergaben und externe Systemänderungen ein. Ohne diese Erfassung ist der Audit Trail unvollständig.
6. Technisch erzwungenes Vier-Augen-Prinzip. Das SAP-Berechtigungskonzept wird so aufgesetzt, dass derselbe User nicht entwickeln, testen und produktiv freigeben kann. Die Rollen sind sauber getrennt, die Berechtigungen sind dokumentiert, die Prüfung ist Teil des Audits.
7. Kennzahlen zur Prozesssteuerung. Ein wirksamer Change-Prozess wird gemessen, nicht nur geführt. Typische Kennzahlen: Durchschnittliche Durchlaufzeit nach Change-Typ, Anteil erfolgreich umgesetzter Changes, Anteil Emergency Changes am Gesamtvolumen, Anteil Changes mit Nacharbeit, durchschnittliche CAB-Dauer. Wer nicht misst, kann nicht steuern.
Change Management ist weder optional noch reine Tool-Frage. Prozessdisziplin, technische Erzwingung der Separation of Duties und messbare Metriken sind die drei Hebel für ein belastbares SAP Change Management.