Viele Unternehmen steigen gerade in SAP Cloud ALM ein – motiviert durch den SolMan‑Ausstieg oder den Wunsch nach einem modernen, cloudfähigen ALM‑Setup. Die Erwartung: „Einmal einschalten, kurz konfigurieren – und wir sind startklar.“
Die Realität ist differenzierter: Cloud ALM ist stabil und liefert viel „out of the box“ – aber die Einführung scheitert in der Praxis oft an zwei Dingen gleichzeitig:
1) Struktur: Rollen, Verantwortlichkeiten, Betriebsmodell, Governance.
2) Funktionale Kontrollen: Gerade bei Change/Deployment erwarten viele Organisationen 4‑Augen‑Prinzip, harte Freigaben, restriktive Statuswechsel und Auditierbarkeit – und stoßen an Grenzen, wenn sie eine 1:1‑ChaRM‑Logik voraussetzen.
Dieser Artikel zeigt die wiederkehrenden Baustellen, die Projekte verzögern und Teams frustrieren – und warum sie teils organisatorisch, teils funktional entstehen.
Warum die Einführung oft holpert: „ALM‑Tool“ trifft „Betriebsrealität“
Cloud ALM ist nicht einfach ein weiteres Tool, sondern ein Prozess‑Taktgeber: Es macht Zusammenarbeit, Nachweise, Deployment‑Orchestrierung und Monitoring transparenter – fordert dafür aber klare Entscheidungen über Rollen, Freigaben und Verantwortungen.
Gleichzeitig ist Cloud ALM nicht als 1:1‑Replikation von SolMan/ChaRM gedacht – der Schwerpunkt liegt stärker auf Change Enablement als auf maximal restriktiver Change Control.
Konsequenz: Wer Cloud ALM „wie ChaRM“ betreiben will, muss bewusst klären, welche Kontrollen Cloud ALM selbst abdeckt – und wo Ergänzungen (z. B. externe Workflows) nötig sind.
„Wenn ihr Foundation + Governance + Betriebsmodell sauber aufsetzt, dann wird Cloud ALM tatsächlich zum zentralen Baustein für einen schlanken, zukunftsfähigen ALM‑Betrieb.“
– Stephan Grebe, Consultant
Die Baustellen, die wirklich immer wieder kommen
Baustelle 1 – Identität, Rollen & Berechtigungen: Der unsichtbare Projektblocker
Symptome
User sind nicht im IAS gepflegt → Login, Passwort‑Reset, Authentifizierung scheitert.
Rollen/Role Collections sind unklar oder falsch zugeordnet → Personen sehen Apps, aber dürfen keine Aktionen (oder umgekehrt).
Niemand ist klar zuständig für BTP‑Subaccount‑Rollen vs. Cloud‑ALM‑Rollen → Wartezeiten und „Ping‑Pong“ zwischen Security, Basis und BTP‑Admins.
Warum das teuer wird
Setup‑Aktivitäten hängen an wenigen Admin‑Schritten. Wenn die fehlen, steht die gesamte Einführung.
Praxis‑Hinweis
Rollenmodell + Owner + „Wer macht was wo?“ (IAS, BTP, Cloud ALM) muss vor dem ersten Use Case stehen – nicht erst beim Setup‑Hänger.
Baustelle 2 – BTP‑Fundament & Connectivity: Wenn das Fundament wackelt, wackelt alles
Symptome
Destinations (OAuth2ClientCredentials, Service Keys, URLs) sind falsch/unvollständig → Integrationen/Workflow‑Anbindungen funktionieren nicht.
IAS‑Trust und Onboarding sind nicht sauber → Zugriff bleibt instabil.
Externe Tools (Ticketing, Workflow etc.) scheitern an Connectivity, Regeln, Ownership.
Warum das teuer wird
Fehler sind oft nicht „ein Bug“, sondern ein Fundament‑Thema. Debugging kostet Zeit, weil Zuständigkeiten unklar sind.
Praxis‑Hinweis
„BTP‑Hausaufgaben“ als eigenes Arbeitspaket behandeln: IAS, Destinations, Service Keys, Naming/Ownership, Runbook.
Baustelle 3 – Change & Deployment: Erwartung „Kontrolle“ trifft Standard‑Workflow
Hier liegt der größte Erwartungs‑Gap – auch in „normalen“ Unternehmen: 4‑Augen‑Prinzip, SoD und nachvollziehbare Freigaben sind heute Standard‑Governance.
Was Cloud ALM im Standard macht (und was das bedeutet)
Feature‑Statusfluss ist vordefiniert (inkl. erlaubter Aktionen je Status und Rollen) → klare Leitplanke, aber begrenzt frei modellierbare Workflows.
Bestimmte Checks sind eingebaut (z. B. Transport‑Readiness Richtung „Ready for Production“) – ersetzt aber nicht automatisch euer Governance‑Modell.
Viele erwarten ChaRM‑Mechaniken (konfigurierbare Genehmigungsstrecken, Schutzmechanismen) – Cloud ALM ist jedoch anders positioniert (Enablement statt vollständige ChaRM‑Abbildung).
Zentraler Pain
„Wir brauchen restriktive Statuswechsel und Aktionen (nur bestimmte Rollen dürfen X), plus harte Approval‑Gates – aber im Standard ist das nicht überall so granular wie aus ChaRM bekannt.“
Wichtig (Brücke über Ergänzungen)
Zusätzliche Freigabe-/Bestätigungsschritte lassen sich über externe Workflows realisieren (z. B. SAP Build Process Automation), wenn mehr Kontrolle als im Standard benötigt wird.
Praxis‑Hinweis
Change/Deploy ist kein „Tool‑Setup“, sondern Governance‑Design: Rollen, Freigaben, Verantwortlichkeiten, Kriterien für „Ready“.
Baustelle 4 – Deployment‑Enablement in den Managed Systems: Prereqs sind kein „Nebenbei“
Gerade bei ABAP‑Landschaften ist Deployment‑Orchestrierung nicht „Plug & Play“.
Symptome
Managed‑System‑Voraussetzungen (z. B. ST‑PI‑Stände, Notes, SSL/Zertifikate/Parameter) sind nicht erfüllt.
Setup‑Schritte (Push Data Provider, Setup‑Transaktionen/Jobs) sind nicht sauber eingerichtet → Daten/Deployment‑Funktionen fehlen.
Warum das strukturell wird
Hängt an Basis‑Kapazität, Wartungsfenstern, Ownership und Priorisierung – also Organisation, nicht Tool.
Praxis‑Hinweis
Prereqs und Notes als „Enablement‑Stream“ planen: Timeline, Verantwortliche, Wartungsfenster, Eskalation.
Baustelle 5 – Test Management: „Wir landen wieder bei Excel“
Viele Teams erwarten Testplanung und Teststeuerung wie in klassischen Test‑Suites. Cloud ALM kann Tests – aber das Modell ist bewusst „lean“ und Komfortfunktionen sind nicht immer dort, wo man sie erwartet.
Typische Reibungspunkte
Testpläne bündeln Testfälle und erlauben Tester‑Zuweisung, sind aber bewusst schlank (z. B. ohne verschachtelte Testpakete). Paradigmenwechsel: gut für Agilität, ungewohnt für formalisierte Teststrukturen.
Sequenzen / Ausführungsreihenfolge waren lange ein Schmerzpunkt – mittlerweile gibt es eine Möglichkeit, Testfälle im Testplan in eine definierte Reihenfolge zu bringen (statt nur alphabetisch).
„Verlinkung“ ist möglich – aber die Library‑Logik ist noch nicht überall „rund“. Libraries sind grundsätzlich projektunabhängige, wiederverwendbare Objekte; in der Praxis ist die Integration/Guidance aber teils noch im Ausbau. Dadurch kommt „Application/Interface‑Wissen aus Libraries“ nicht immer reibungslos im Testalltag an.
Benachrichtigungen sind nicht durchgängig „test‑zentriert“ gedacht. Häufig bleibt die Testkoordination bei Mail/Teams/Jira – außerhalb des Tools.
Typische Folge
Testkoordination läuft wieder über Excel/Jira/Testtool, während Traceability in Cloud ALM eigentlich gewünscht wäre – organisatorisch (und teils durch Komfortlücken) zerfällt das Bild.
Praxis‑Hinweis
Testmanagement als Betriebsmodell designen (siehe Best Practices): klare Testplan‑Schnitte, Sequenzen, Kommunikationsbrücke, Referenz‑Regeln.
Baustelle 6 – Monitoring & Jobs: Technik liefert Daten – Betrieb braucht ein Modell
Monitoring ist mächtig – aber nur, wenn Datenversorgung und Betriebsorganisation zusammenpassen.
Symptome
Daten müssen je nach Service/System aktiv bereitgestellt/konfiguriert werden – sonst bleibt Monitoring unvollständig.
Cloud ALM ergänzt lokale Tools; zentrale Remediation (Stop/Restart direkt im zentralen Monitor) ist nicht überall durchgängig umgesetzt.
Warum das teuer wird
Alerts laufen ein – aber ohne klare Verantwortlichkeiten und Reaktionsketten entsteht „Alarm‑Rauschen“.
Praxis‑Hinweis
Monitoring ist ein Betriebsmodell: Owner pro Alert‑Typ, Reaktionszeiten, Eskalation, Bereitschaft, Runbooks.
Baustelle 7 – Fehlende Standardisierung & inkonsistente UX: „Warum geht das hier – und dort nicht?“
Eine unterschätzte Baustelle ist die fehlende Standardisierung innerhalb von Cloud ALM selbst – nicht als „Bug“, sondern als inkonsistente Bedien‑ und Funktionslogik zwischen Apps.
Symptome
Gleiche Konzepte werden je nach App unterschiedlich umgesetzt (z. B. Event Variants je nach Job‑ vs. Health‑Monitoring).
Mass Edit / Bulk‑Funktionen existieren in einer App, in einer anderen nicht – ohne ersichtlichen Grund für Anwender.
UX‑Muster (Navigation, Pflichtfelder, Filter/Views, Bearbeitungslogik) sind nicht durchgängig konsistent.
Warum das teuer wird
Mehr Trainingsaufwand, höhere Fehlerquote, schwierigere Governance („jeder macht’s anders“).
Praxis‑Hinweis
Standardisierung muss heute teilweise im Projekt hergestellt werden: Playbooks, Konventionen, DoD‑Kriterien, Review‑Mechaniken.
Baustelle 8 – Validierung & Nachweisführung (allgemein): Wenn Kontrollen „beweisbar“ sein müssen
Auch ohne GxP haben Unternehmen Anforderungen an Nachvollziehbarkeit: 4‑Augen‑Prinzip, Audit Trails, saubere Freigaben, dokumentierte Abnahmen. In regulierten Umgebungen wird das lediglich konsequenter eingefordert.
Praktische Baustelle
Wenn Kontrollanforderungen in einer Granularität gefordert sind, die Cloud ALM standardmäßig nicht „erzwingt“, braucht es Ergänzungen (Workflows, Prozessregeln, ggf. Partnerlösungen).
Was erfolgreiche Einführungen anders machen (Best Practices)
„Foundation Sprint“ vor dem ersten Use Case
IAS/Identity sauber, Nutzer im IAS vorhanden.
Rollenmodell (BTP Role Collections + Cloud‑ALM‑Rollen) festgelegt und dokumentiert.
Destinations/Service Keys/Connectivity geprüft.
Change & Deployment als Governance‑Design behandeln – nicht als Tool‑Konfiguration
Statusfluss & Rollen bewusst einsetzen (Change Manager / Deployment Manager / Developer etc.).
Für 4‑Augen‑Prinzip und „harte Gates“: externe Workflows einplanen (z. B. BPA‑Integration).
Erwartungsmanagement: Cloud ALM ist nicht „ChaRM in der Cloud“ – Prozesse müssen ggf. angepasst oder ergänzt werden.
Managed‑System‑Enablement als eigenes Arbeitspaket
Prereqs/Notes/Setup‑Schritte früh terminieren und ownern (Basis!).
Teststrategie früh entscheiden (und als Betriebsmodell designen)
Was läuft in Cloud ALM, was in externen Tools? Wie bleibt Traceability konsistent?
Pragmatischer Tipp aus der Praxis:
Testplan‑Schnitte klar definieren (z. B. nach Release/Wave/Org/Scope) – nicht „ein Plan für alles“.
Sequenzen konsequent nutzen, damit E2E‑Tests nicht in Excel‑Reihenfolgen landen.
Kommunikationsbrücke definieren (Teams/Jira/Mail): Wer wird wann informiert (Start UAT, Blocker, Retest), weil Test‑Benachrichtigungen oft außerhalb des Tools passieren.
Regeln festlegen, wie Applications/Interfaces referenziert werden (Links, Namenskonventionen oder Library‑Elemente), damit Tester nicht suchen müssen und die Dokumentation konsistent bleibt.
Monitoring als Betriebsmodell definieren
Datenversorgung + Rollen + Reaktionsketten + Eskalation definieren – sonst bleibt Monitoring „schön, aber wirkungslos“.
„Standardisierung by Design“ – internes Playbook statt Tool‑Zufall
Einheitliche Muster für wiederkehrende Konfigurationen definieren (Naming, Tagging, Event‑Variant‑Logik, Threshold‑Konventionen).
Pro App kurze How‑tos/1‑Pager erstellen, wenn sich Bedienlogik unterscheidet.
Definition of Done festlegen: Wann ist ein Setup „fertig“ (inkl. Review durch Betrieb/QA)?
Quality Gates nicht nur für Deployments, sondern auch für Monitoring‑/Alert‑Konfigurationen einführen.
Fazit: Cloud ALM ist nicht „zu schlecht“ – aber auch nicht „einfach nur einschalten“
Cloud ALM ist ein starker Baustein für modernes ALM. Die größten Kosten entstehen dort, wo Unternehmen…
BTP/Identity/Rollen nicht als Fundament behandeln,
bei Change & Deployment ChaRM‑Level‑Kontrollen erwarten, ohne Governance‑Design oder Workflow‑Ergänzungen einzuplanen,
und Monitoring/Test als reines Tool‑Feature sehen statt als Betriebs‑ und Qualitätsmodell.
Wenn ihr Foundation + Governance + Betriebsmodell sauber aufsetzt, dann wird Cloud ALM tatsächlich zum zentralen Baustein für einen schlanken, zukunftsfähigen ALM‑Betrieb.
Ausblick:
Viele der Praxishinweise und „Wunsch‑Funktionen“ sind im SAP Roadmap Explorer bzw. in Roadmap‑Updates bereits sichtbar – aber in der jeweiligen Tenant‑Realität oft noch nicht umgesetzt.
Spannend wird daher, welche Lücken SAP kurzfristig schließt – und wo Partnerlösungen bzw. kundeneigene Erweiterungen über APIs/Integrationen sinnvoll andocken können (z. B. externe Ticket‑Systeme oder Workflow‑Engines als Governance‑Brücke).
Titelbild: ©onlyyouqj/freepik.com
