Zwei typische Ausgangspunkte im Unternehmen — Serie 2/6

Blog vom 22.02.2026

Zwei typische unternehmerische Ausgangssituationen

Bei der Analyse von SAP-ALM-Strategien nach SolMan befinden sich Unternehmen in der Regel in einer von zwei strukturellen Ausgangspositionen. Diese Unterscheidung ist entscheidend, da sich die architektonischen Konsequenzen grundlegend unterscheiden.

Szenario A: SAP Solution Manager als Transportwerkzeug

In vielen Organisationen war SAP Solution Manager nie das unternehmensweite Lifecycle-Backbone. Stattdessen:

  • Anforderungen und Backlog-Management wurden in Jira oder Azure DevOps gesteuert

  • Change-Governance lief über ServiceNow oder vergleichbare ITSM-Plattformen

  • Testmanagement erfolgte in spezialisierten Tools

  • Enterprise-Reporting existierte außerhalb des SAP-Stacks

SolMan blieb häufig primär für die Orchestrierung von Transporten zwischen SAP-Systemen im Einsatz.

In diesem Szenario war SAP-ALM bereits teilweise externalisiert. Die Einführung von SAP Cloud ALM als vollständige Lifecycle-Suite kann daher führen zu: 

  • Überlappenden Governance-Prozessen

  • Doppelter Backlog-Dokumentation

  • Getrennten Reporting-Modellen

  • Erhöhter Integrationskomplexität 

Das architektonische Ziel ist hier nicht Ersatz — sondern Vereinfachung. 

Szenario B: SAP Solution Manager als Governance-Kern

In anderen Umgebungen spielte SolMan eine zentralere Rolle. Er stellte beispielsweise bereit:

  • Integriertes Change Control (ChaRM)

  • SAP-zentrierte Release-Governance

  • Compliance- und Audit-Nachvollziehbarkeit

  • Strukturierte SAP-Testprozesse

In solchen Fällen kann SAP Cloud ALM als natürlicher struktureller Nachfolger dienen.

Doch auch hier koexistieren häufig Enterprise-Tools wie Jira, Azure DevOps oder ServiceNow. Die Fragestellung verschiebt sich daher von der Produktnachfolge hin zur architektonischen Integration:
Wie soll SAP-natives Lifecycle-Management mit der übergeordneten Enterprise-Toolchain zusammenspielen?

Im nächsten Beitrag lösen wir uns vollständig von konkreten Tools und betrachten die funktionalen Ebenen, die eine nachhaltige Enterprise-SAP-ALM-Architektur definieren.