Application Lifecycle Management (ALM) bezeichnet die durchgängige Steuerung aller Aktivitäten, die eine Unternehmensanwendung von der ersten Anforderung bis zur Abschaltung begleiten. Dazu zählen Anforderungsmanagement, Entwicklung, Test, Release, Betrieb, Monitoring und Wartung. ALM ist kein Tool, sondern eine Disziplin. Tools unterstützen diese Disziplin, ersetzen sie aber nicht.
SAP ALM ist die Ausprägung dieser Disziplin für SAP-Systemlandschaften. Anders als generisches IT-ALM arbeitet SAP ALM mit spezifischen Artefakten: Transport Requests, Mandanten, ABAP-Entwicklungsobjekten, Customizing und Konfigurationsdaten. Diese Artefakte werden über mehrstufige Systemlandschaften bewegt und dort kontrolliert produktiv gesetzt.
SAP-Systeme laufen in den meisten Fällen als geschäftskritische Infrastruktur. Drei Kräfte treiben aktuell die Aufwertung von SAP ALM in Unternehmen:
1. Der Migrationsdruck Richtung S/4HANA. SAP hat die Wartung für SAP ECC auf Ende 2027 befristet. Ohne strukturiertes ALM wird aus jedem Migrationsprojekt ein kontinuierliches Risiko.
2. Das Ende der Mainstream-Wartung für den SAP Solution Manager zum 31.12.2027. Seine Ablösung erzwingt strategische Entscheidungen über die künftige ALM-Architektur.
3. Regulatorik und Audit-Anforderungen. SOX, GxP, DORA und der EU AI Act verlangen nachweisbare Kontrolle über Änderungen in kritischen Systemen.
Ein belastbares SAP ALM stützt sich auf drei Säulen: Prozessdisziplin, Technologie und Governance.
Prozessdisziplin bedeutet, dass es einen definierten und eingehaltenen Weg gibt, wie eine Anforderung zur produktiven Änderung wird. ITIL 4 unterscheidet drei Change-Typen: Standard Changes, Normal Changes und Emergency Changes.
Technologie unterstützt den Prozess durch Automatisierung, Transparenz und Kontrolle: Transport-Orchestrierung, automatisierte Importzyklen, Downgrade Protection, Cross Reference Checks und Impact Analysen.
Governance sorgt dafür, dass Prozess und Technologie auch gelebt werden. Ohne klare Rollen, Eskalationspfade und Entscheidungsgremien verliert jede ALM-Architektur nach wenigen Monaten ihre Wirkung.
Fehlende Transparenz über den Status eines Changes. Teams wissen oft nicht, in welchem System ein Transport gerade steht, wer ihn zuletzt bearbeitet hat und wann er produktiv geht.
Manuelle Arbeit, die Teams bindet. SAP Basis und Release Manager verbringen einen grossen Teil ihrer Zeit mit repetitiven Aufgaben.
Compliance ohne Nachweisbarkeit. SOX-relevante Kontrollen werden prozessual behauptet, aber nicht technisch erzwungen.
Ein durchgängiger End-to-End-Prozess. Requirement, Change, Test, Deployment und Audit Trail gehören in einen Prozessfluss, nicht in vier getrennte Tools mit manuellen Übergaben.
Transport-Orchestrierung statt manueller Importe. Sequenzen werden automatisch geprüft. Downgrade Protection ist aktiv.
Audit Trail als Nebenprodukt des Prozesses. Jede Statusänderung, jede Genehmigung, jede Abweichung wird automatisch protokolliert.
SAP ALM ist mehr als ein Werkzeug. Es ist die Disziplin, mit der ein Unternehmen Änderungen an geschäftskritischen SAP-Systemen sicher, nachvollziehbar und nachweisbar durchführt. Die Grundlage ist ITIL 4 mit den bekannten Change-Typen Standard, Normal und Emergency, ergänzt um die SAP-Spezifika Transport, Mandant und Systemlandschaft.
Drei Kräfte zwingen Unternehmen 2026 zur strategischen Neubewertung: die S/4HANA-Migration, das Ende der SolMan-Mainstream-Wartung am 31.12.2027 und wachsende regulatorische Anforderungen.