SAP Cloud ALM und die Lücken im Change Management: Stand 2026

1. Definition: Was Cloud ALM ist und was nicht

SAP Cloud ALM ist die strategische Cloud-Plattform für Application Lifecycle Management, die SAP seit 2019 schrittweise aufbaut. Sie ist als Nachfolger des SAP Solution Manager (SolMan 7.2) positioniert, dessen Mainstream Maintenance am 31. Dezember 2027 endet. Customer können danach gegen Aufpreis bis 2030 Extended Maintenance buchen, danach läuft SolMan ohne SAP-Support.

Cloud ALM ist eine Multi-Tenant-SaaS-Anwendung, die SAP auf der eigenen BTP betreibt. Customer aktivieren sie als Teil ihres Enterprise Support oder ihrer Cloud-Subscription. Es gibt keine On-Premise-Installation. Patches werden alle zwei Wochen ausgerollt, Major-Features quartalsweise. Diese Cloud-only-Architektur ist die wichtigste Designentscheidung und prägt jede Funktions-Diskussion.

1.1 Die vier Kernbereiche

SAP strukturiert Cloud ALM in vier offizielle Bereiche, die in der Roadmap-Explorer-Anwendung sichtbar sind und unterschiedliche Reifegrade haben.

Implementation: Werkzeuge für die Einführung neuer SAP-Lösungen. Project Management, Solution Documentation (Soldoc), Process Management, Test Management (über Tricentis-Integration), Requirements und Stories. Dieser Bereich ist relativ reif.

Operations: System Monitoring, Health Monitoring, Job Monitoring, Configuration und Security Analysis, Real User Monitoring, Synthetic User Monitoring, Integration Monitoring. Funktional überlappt dieser Bereich mit SAP Focused Run. SAP positioniert Cloud ALM für mittlere und kleine Landschaften, Focused Run für Großunternehmen mit hohem Daten-Volumen.

Change and Deploy Management: Der Bereich, der ChaRM aus dem klassischen SolMan ersetzen soll. Hier sind die deutlichsten Lücken im Frühjahr 2026, das Hauptthema dieses Artikels. Cloud ALM bringt eigene Begriffe wie Features, Releases, Deployment Plans mit, die aus dem agilen Projektmanagement kommen, nicht aus dem klassischen ITIL-Wortschatz.

Business and Data Transformation: Der jüngste Bereich, mit Fokus auf Business Process Mining, Process Intelligence, Data Migration. Hier werden Funktionen aus SAP Signavio und LeanIX integriert. Reifegrad noch im Aufbau.

1.2 Was Cloud ALM nicht ist

Drei wichtige Klarstellungen, die in der Praxis oft missverstanden werden.

Erstens, Cloud ALM ist nicht SolMan in der Cloud. Die beiden Plattformen haben grundlegend unterschiedliche Architekturen, Daten-Modelle und Funktions-Designs. Eine 1-zu-1-Migration ist technisch nicht möglich. Wer von ChaRM nach Cloud ALM migriert, beginnt fachlich neu.

Zweitens, Cloud ALM ist nicht für alle SAP-Customer gedacht. Die offizielle Positionierung adressiert Cloud-zentrische Landschaften (RISE with SAP, GROW with SAP, S/4HANA Cloud Public Edition) und hybride Setups mit Cloud-Anteilen. Für reine On-Premise-S/4HANA-Landschaften ohne BTP-Komponenten ist Cloud ALM funktional eingeschränkt.

Drittens, Cloud ALM ist nicht fit to needs, sondern fit to standard. SAP positioniert die Plattform explizit als standardisierte Lösung ohne Customizing-Möglichkeiten. Wer in SolMan eigene Workflows definiert hat, eigene CRM-Felder, eigene Genehmigungs-Logiken, findet diese Möglichkeiten in Cloud ALM nicht.

1.3 Warum dieser Artikel jetzt nötig ist

Drei parallele Entwicklungen 2026 machen eine ehrliche Lücken-Analyse zum Pflicht-Thema. Erstens, der DSAG-Investitionsreport 2026 zeigt, dass 24 Prozent der Customer die SAP Integrated Toolchain bereits teilweise oder vollständig nutzen, 39 Prozent planen die Nutzung in Teilen. Im Umkehrschluss: 37 Prozent nutzen sie nicht und planen das auch noch nicht. Zweitens, die SolMan-Mainstream-Maintenance endet am 31. Dezember 2027. Customer haben weniger als 20 Monate Zeit für Bestandsaufnahme, Strategie-Entscheidung und Migrations-Umsetzung. Drittens, die Cloud-ALM-Reife wächst quartalsweise, aber sie ist noch nicht vollständig. Mehrere Funktionen aus dem ChaRM-Werkzeugkasten existieren in Cloud ALM noch nicht oder nur in vereinfachter Form.

2. Marktstatus: Wie weit Cloud ALM 2026 wirklich ist

2.1 DSAG-Investitionsreport 2026

Der DSAG-Investitionsreport 2026, veröffentlicht 26. Februar 2026, ist die wichtigste unabhängige Datenquelle. 24 Prozent der Customer nutzen die SAP Integrated Toolchain bereits teilweise oder vollständig. 39 Prozent planen die Nutzung zumindest in Teilen. 37 Prozent bisher keine Nutzung und kein konkreter Plan.

Die DSAG kommentiert, dass die vergleichsweise geringe Investitionsbereitschaft in die Public Cloud zeigt, dass aus Kundensicht noch funktionale Tiefe, Integrationsfähigkeit und verlässliche Rahmenbedingungen entscheidend sind. Viele Unternehmen haben stark individualisierte Landschaften, in denen die standardisierten Cloud-ALM-Werkzeuge nur eingeschränkt nutzbar sind.

2.2 ERP-Landschaft als Kontext

56 Prozent S/4HANA On-Premises, 54 Prozent SAP ECC oder Business Suite, 17 Prozent S/4HANA Private Cloud, 5 Prozent S/4HANA Public Cloud. Die On-Premise-Dominanz ist die wichtigste Markt-Realität. Für diese Landschaften ist Cloud ALM nicht der natürliche ALM-Pfad.

2.3 Reife-Bewertung pro Bereich

Implementation: Reif. Operations: Bedingt reif. Change and Deploy Management: Lückig. Business and Data Transformation: Im Aufbau. Wer sich heute für Cloud ALM entscheidet, kauft eine Plattform mit klar wachsender Reife, aber mit Stand-2026-Lücken, die zur Migration eingeplant werden müssen.

2.4 Cloud ALM Patch-Strategie

SAP rollt Cloud ALM Patches ungefähr alle zwei Wochen aus. Customer können die Update-Zeitpunkte nicht selbst steuern. Major-Releases erfolgen quartalsweise mit dokumentierten Roadmap-Features. Eine umfassende Test-Strategie ist Pflicht-Aufgabe der Customer: Regression-Tests, Smoke-Tests nach jedem Patch und ein klares Eskalations-Prozess für unerwartete Verhaltensänderungen.

3. Die neun dokumentierten Lücken im Change Management

Lücke 1: Cross System Object Lock (CSOL)

Was fehlt: In SolMan ChaRM verhindert das Cross System Object Lock (CSOL), dass dasselbe Objekt in zwei parallelen Transports geändert wird. CSOL existiert in Cloud ALM Stand Mai 2026 nicht. Quelle: blue.works/en/cloud-alm-coffee-party-ix vom 18. Februar 2026: "the Cross System Object Lock (CSOL) checks are still missing".

Praxis-Auswirkung: Konflikte zwischen parallelen Transports werden später erkannt, oft erst beim Import in das Q-System. Workaround: SAP hat als teilweisen Ersatz die Cross-Reference Check Funktion implementiert (Q1 2025). Dieser Check erkennt Konflikte beim Transport-Release, nicht beim Erstellen der Änderung. Vollständiges CSOL-Equivalent ist auf der Roadmap, aber ohne festes Lieferdatum.

Lücke 2: Custom Workflows

Was fehlt: SolMan ChaRM erlaubt umfangreiches Customizing der Genehmigungs-Workflows. Cloud ALM ist explizit fit to standard und bietet keine vergleichbaren Anpassungs-Möglichkeiten. Quelle: realtech.com: "Standardization over maximum flexibility".

Praxis-Auswirkung: Customer mit gewachsenen ChaRM-Konfigurationen müssen ihre Workflows auf SAP-Standard reduzieren. Komplexe Genehmigungs-Logiken (etwa mit verzweigten Pfaden, fachlichen Eskalationen, regulatorischen Pflicht-Schritten) sind nicht eins-zu-eins abbildbar. Workaround: Externe Werkzeuge oder Drittanbieter-Plattformen. SAP empfiehlt explizit die Integration mit Drittanbieter-ALM-Tools für Erweiterungs-Bedarf.

Lücke 3: Vollwertiger Service Desk und ITSM

Was fehlt: SolMan bringt mit dem ITSM-Modul einen vollwertigen Service Desk mit Incident Management, Problem Management, Knowledge Base. Cloud ALM hat dieses Modul nicht im gleichen Umfang. Stattdessen setzt SAP auf Integration mit externen ITSM-Plattformen (ServiceNow, Jira Service Management). Quelle: realtech.com Januar 2025: "Kein vollwertiger Service Desk".

Workaround: ServiceNow oder Jira Service Management als Service Desk, mit Cloud ALM als Change-Management-Layer. Das ist die heute am häufigsten gewählte Konstellation in DACH-Großunternehmen.

Lücke 4: End-to-End-Trackability

Was fehlt: SolMan ChaRM bietet eine vollständige Verfolgung jeder Änderung von der Anforderung über Entwicklung, Testing, Genehmigung bis zum Produktions-Deployment. Cloud ALM erweitert die Trackability quartalsweise, aber Stand Mai 2026 ist die Kette nicht in allen Szenarien lückenlos. ASUG-Analyse Oktober 2025: "trackability of every change from start to finish are capabilities that Cloud ALM doesn't currently offer a like-for-like replacement".

Workaround: Externe Compliance-Logging-Plattform (Splunk, ELK, Microsoft Sentinel), die alle Cloud-ALM-Events plus die zusätzlichen Quellen (Git, Jenkins, ServiceNow, BTP Audit Log) aggregiert.

Lücke 5: Erweiterbarkeit und Extensions

Was fehlt: SolMan erlaubt eigene Implementierungen über BAdIs, eigene Funktionsbausteine, eigene Reports, eigene CRM-Felder. Cloud ALM bietet keine vergleichbare Erweiterungs-Schicht. Customer können Konfigurationen anpassen, aber keinen eigenen Code in die Plattform einbringen.

Lücke 6: Reine On-Premise-Szenarien

Was fehlt: Cloud ALM ist Cloud-only. Für Customer mit strikten On-Premise-Anforderungen ist Cloud ALM nicht im klassischen Sinn nutzbar. realtech.com Januar 2026: "Many businesses assume that SAP Cloud ALM is the default replacement for SolMan, but it lacks key functionalities, especially for on-premise environments".

Lücke 7: Hohe Daten-Volumen

Was fehlt: Die Cloud-ALM-UIs sind primär für mittlere und kleine Customer ausgelegt. Bei sehr hohen Daten-Volumen (vielen Systemen, vielen Alerts, vielen Transports parallel) erreichen die Standard-UIs Performance-Grenzen. saptechnicalguru.com 2026: "Data volumes on Cloud ALM are not to be too high, since the UIs are still designed for small and medium customers". Workaround: Zwei-Werkzeug-Strategie. Cloud ALM für die Standard-Funktionen, Focused Run für High-Volume-Monitoring.

Lücke 8: Daten-Migration aus SolMan

Was fehlt: Eine vollständige automatisierte Migration der Bestandsdaten aus SolMan nach Cloud ALM existiert nicht. SAP bietet einen Selective Data Transfer für ausgewählte Datenkategorien (etwa Document Files seit Q1 2026), aber nicht für alle ChaRM-Bestandsdaten. Xitera Consulting: "Testdaten werden nicht automatisch aus dem SolMan 7.2 übernommen". 8 GB Speicherlimit für Soldoc. Workaround: SolMan parallel zu Cloud ALM weiterbetreiben als Read-Only-Archive bis die Aufbewahrungs-Frist abgelaufen ist.

Lücke 9: Conditional und Consistency Checks

Was fehlt: SolMan ChaRM hat eine breite Palette von Konsistenz-Checks (etwa: erfolgreich in Q importiert vor Produktions-Genehmigung, alle Pflichtfelder vor Status-Übergang gefüllt, Dependencies zwischen Transports korrekt). Cloud ALM hat einen Teil dieser Checks, aber nicht alle. Workaround: Quality-Gates über externe CI/CD-Pipelines oder Drittanbieter-Plattformen mit eigenen Konsistenz-Check-Bibliotheken.

4. Was Cloud ALM 2025 und 2026 ergänzt hat

Damit der Lücken-Befund nicht einseitig wirkt: Cloud ALM hat in den letzten 18 Monaten substanziell neue Funktionen ausgeliefert.

Q1 2025 Erweiterungen: Downgrade Protection (DGP), Cross-Reference Check, Intrinsic Downgrade Check. Q1 2026 Erweiterungen: Block-Check als Teil der Deployment-App, ATC-Check at CTS-managed Transport Release, Retrofit für Upgrade und Conversion in S/4HANA, Soldoc Document Migration, Dashboard for RISE with SAP Methodology Executive view, Konfiguration und Security Analysis Compliance Status.

Setup-Voraussetzungen für ATC-Check at Transport Release: SAP_BASIS 7.40 SP20 oder höher, ST-PI 740 SP 26, SAP Notes 3421256 und 3425282 implementiert. TMS muss client-spezifisch konfiguriert sein mit TMS-Parameter CTC = 1. Diese Voraussetzungen müssen in der Bestandsaufnahme geprüft werden.

Customer, die heute eine Migrations-Entscheidung treffen, sollten die Roadmap-Trajektorie als Annahme einbeziehen, aber nicht als Garantie. Erfahrungsgemäß werden 70 bis 80 Prozent der angekündigten Roadmap-Features im versprochenen Quartal geliefert, der Rest verzögert sich.

5. Tool Landscape: Cloud ALM, ChaRM und Drittanbieter im Vergleich

5.1 Bewertungs-Tabelle

¹ Solutive AG ist Initiator des Change Orchestration Institute. Die Bewertung in der Tabelle ist eine Selbstauskunft des Anbieters und nicht Teil einer redaktionell unabhängigen Validierung.

5.2 Drei Markt-Cluster

Cluster A, Cloud-First: Customer, die Cloud-zentrisch sind, niedrige Custom-Workflow-Anforderungen haben und mit dem fit-to-standard-Ansatz leben können. Für sie ist Cloud ALM die natürliche Wahl. Etwa 24 Prozent im DACH-Markt.

Cluster B, Hybrid: Customer mit On-Premise-S/4HANA-Schwerpunkt und BTP-Erweiterungen. Sie nutzen Cloud ALM für Cloud-Anteile, kombinieren mit Drittanbieter-Plattformen. Größtes Marktsegment, geschätzt 50 bis 56 Prozent.

Cluster C, On-Premise-Strikt: Customer mit reinen On-Premise-S/4HANA-Landschaften, oft regulatorisch gebunden. Für sie ist Cloud ALM keine Option. Geschätzt 20 Prozent des DACH-Markts.

6. Migrations-Strategien für SolMan-zu-Cloud-ALM

Strategie 1: Vollständig zu Cloud ALM

Geeignet für Cluster A. Customer migriert komplett von SolMan ChaRM zu Cloud ALM. Voraussetzungen: Niedriger Custom-Workflow-Anteil, keine On-Premise-Strikt-Anforderungen, Bereitschaft zur Prozess-Anpassung. Gesamtaufwand 6 bis 12 Monate.

Strategie 2: Hybrid mit Brücken-Werkzeug

Geeignet für Cluster B. Cloud ALM für Cloud-Anteile, Drittanbieter-Plattform als Brücke für On-Premise. Gesamtaufwand 9 bis 18 Monate. Phasen-Plan: Q3 2026 Bestandsaufnahme, Q4 2026 Vendor-Auswahl, Q1 2027 Parallel-Setup, Q2-Q3 2027 Cutover.

Strategie 3: Vollständig auf Drittanbieter-Plattform

Geeignet für Cluster C. Gesamtaufwand 12 bis 24 Monate. Bei strikten Compliance- oder Datensouveränitäts-Anforderungen oft die einzige praktikable Option.

Strategie 4: Extended Maintenance bis 2030

Brücken-Strategie für Spät-Entscheider. SAP-Aufpreis 25 bis 50 Prozent. Bis spätestens 2029 muss eine echte Migrations-Entscheidung getroffen werden.

7. Architektur-Konsequenzen aus dem Cloud-only-Modell

Cloud ALM ist Cloud-only, das ist die zentrale Architektur-Entscheidung. Für DACH-Customer mit strikten Datensouveränitäts-Anforderungen kann das Cloud ALM ausschließen. DSAG hat sich am 17. März 2026 zur deutschen Cloud-Souveränität positioniert und Datensouveränität als zentrales Anliegen formuliert.

Die Patch-Zyklus-Realität (alle zwei Wochen) erfordert eine kontinuierliche Test-Strategie: Smoke-Tests nach jedem Patch, Regression-Tests für kritische Workflows, klare Eskalations-Prozesse bei Verhaltensänderungen.

Die End-to-End-Compliance-Architektur erfordert eine zentrale Compliance-Logging-Plattform (Splunk, ELK, Microsoft Sentinel) als Aggregator für alle Cloud-ALM-Events plus die ergänzenden Quellen.

SAP betreibt für Cloud ALM einen Customer-Influence-Prozess. Customer können Verbesserungs-Anforderungen einreichen und über sie abstimmen, was die SAP-Roadmap-Priorisierung beeinflusst. Erreichbar über das SAP Cloud ALM Improvement Request Portal mit S-User-Login. Customer-Influence kann SAP aber nicht zur Aufgabe der fit-to-standard-Philosophie bewegen. Lücken, die strukturell sind (Lücke 2 Custom Workflows, Lücke 5 Erweiterbarkeit), werden nicht durch Customer-Influence-Prozesse aufgelöst.