Solution Manager läuft aus: Umstieg auf Cloud ALM ist kein Großprojekt

Der Tenant ist in Minuten provisioniert, berechtigte Kunden zahlen keine zusätzlichen Lizenzkosten und der Operations-Teil ist mit rund zwei Personentagen eingerichtet. Wer jetzt startet, entscheidet in Ruhe, welche Solution-Manager-Funktionen er überhaupt noch braucht.

Die Uhr läuft anders als gedacht

Die Mainstream-Wartung für SAP Solution Manager 7.2 endet am 31. Dezember 2027. SAP empfiehlt allen Kunden, den Übergang zu SAP Cloud ALM vor diesem Datum abzuschließen. So weit ist die Lage bekannt. Verbreitet ist allerdings ein Merksatz, der nicht trägt: Wir haben bis 2030 Zeit. Die Extended Maintenance bis Ende 2030 ist an die Extended Maintenance für SAP Business Suite 7 gekoppelt und steht damit nicht jedem Kunden offen. Unternehmen, die keine Extended Maintenance für SAP Business Suite 7 beziehen, wechseln nach 2027 für nicht abgedeckte SolMan-Funktionen in die Customer-Specific Maintenance. Die Frist hängt damit am jeweiligen ECC-Status des Unternehmens, nicht an einer allgemeinen Roadmap-Angabe.

Für CIO und IT-Leitung ist das eine Governance-Frage, keine Basis-Frage. Sie sollte beantwortet sein, bevor der Betrieb sie beantwortet bekommt. Ein Nebeneffekt wird dabei selten mitgedacht. Bei vielen Mittelständlern ist der Solution Manager das letzte System mit AS-Java-Stack. Die Teams sind froh, diese Komponente loszuwerden, weil das Know-how dafür ohnehin fehlt.

Drei Irrtümer, die Start verzögern

Der eigentliche Grund für das Zögern liegt nicht in der Technik. Es sind drei Annahmen, die sich in Projekten regelmäßig als falsch erweisen.

Erstens: die Kosten. SAP Cloud ALM steht berechtigten SAP-Kunden ohne zusätzliche Lizenzkosten zur Verfügung. Die Berechtigung lässt sich in SAP for Me in wenigen Klicks prüfen. Ein erheblicher Teil der Kunden weiß das nicht und kalkuliert im Kopf mit einem Budget, das gar nicht anfällt.

Zweitens: die Speichergrenze. SAP hat die Base Memory im Rahmen der Fair-Use-Regelung auf 24 GB angehoben. In der Praxis wird dieser Rahmen kaum ausgereizt. Ein Kunde mit rund 18 angebundenen Landschaften und breitem Cloud-Service-Portfolio bewegt sich dabei bei etwa 6 GB Hana-Memory, ohne am Housekeeping gedreht zu haben. Das ist ein Viertel der Fair-Use-Grenze.

Drittens: der Aufwand. Der Tenant ist in Minuten provisioniert, das Anbinden einzelner Systeme dauert Stunden. Eine Agenten-Ausrollung wie beim Solution Manager entfällt vollständig. Der bestehende Betrieb läuft parallel weiter, SAP Cloud ALM greift nicht in laufende Prozesse ein. Wie niedrig die Hürde tatsächlich liegt, zeigt ein wiederkehrendes Muster: Es gibt Kunden, die den Tenant provisioniert und ein erstes Sandbox-System angebunden haben, dann aber stehen blieben, weil sie massiven Wissensaufbau befürchteten. Die Entscheidung fällt deshalb meist auf Teamleitungsebene, nicht im Investitionsausschuss.

Was der SolMan nie konnte

Wer den Wechsel nur als Pflichtübung betrachtet, übersieht den größeren Teil. SAP Cloud ALM überwacht Cloud-Services und On-prem-Systeme in einer Oberfläche, einschließlich Zertifikaten und API-Keys, etwa für den SAP Cloud Connector und die Integration Suite. Diese Cloud-Seite deckte der Solution Manager nicht ab, und genau dort wachsen die Landschaften. Abgelaufene API-Keys eines Subaccounts sind ein klassischer stiller Ausfall. Nichts stürzt ab, nichts alarmiert, die Schnittstelle liefert einfach nicht mehr. Auffällig wird das, wenn die Fachabteilung anruft. SAP Cloud ALM warnt konfigurierbar vor, beispielsweise 90 Tage vor Ablauf, mit einer kritischen Erinnerung 30 Tage davor. Die Alarmierung geht dorthin, wo gearbeitet wird: in den Teams-Kanal, nach Jira oder ServiceNow, statt in ein Postfach, das ohnehin überläuft. Das ist kein Komfortthema. Es gibt Bestandskunden, die genau wegen dieser Funktion den Wechsel vollzogen, weil abgelaufene Keys ihnen im Betrieb regelmäßig die Beine gebrochen haben.

Der zweite Bereich ist das zentrale Transportmanagement für On-prem- und Cloud-Entwicklung, mit Fiori-Oberfläche und ohne manuelle Export- und Import-Schritte. Der Einstieg erfolgt in der Praxis fast immer über Operations, der Implementation-Bereich bleibt liegen. Das liegt meist am Wording der Dokumentation, nicht an der Sache: Die Techniker haben dort weniger Prozessarbeit, als sie annehmen.

Der Weg dorthin, ohne Big Bang

Der Umstieg auf SAP Cloud ALM läuft schrittweise: Readiness Check im Solution Manager, dann Entwicklungs- und Testsysteme, dann Produktion. Beide Werkzeuge lassen sich parallel betreiben und im Monitoring miteinander vergleichen. Zwei Fallstricke lohnen die Vorarbeit. Die Identitätsverwaltung sollte von Anfang an am produktiven IAS-Tenant hängen, sonst entstehen parallele Tenants ohne Synchronisation. Und einzelne Metriken, etwa das Filesystem-Monitoring, erzeugen ohne Vorkonfiguration vor allem Fehlalarme. Beides ist nachträglich korrigierbar, aber unnötig teuer. Wichtig für die Risikobewertung: SAP Cloud ALM ist eine Orchestrierungsschicht, kein Single Point of Failure. Fällt der Service aus, bleiben Transporte über das TMS manuell möglich, anders als bei ChaRM oder Focus Build. Der Umstieg ist damit steuerbar und jederzeit reversibel. Bislang gibt es kaum SAP-Bestandskunden, die den Einstieg bereut hätten. Das reicht von einer Enablement-Session, in der die Mannschaft selbst deployt und dabei lernt, bis zum vollständigen Aufbau von Tenant, Systemanbindung und Cloud-Services durch Entplexit.

Fazit

Die Frist läuft, aber der Aufwand ist kalkulierbar. Wer wartet, verliert keine Technik, sondern Handlungsspielraum. Der teuerste Fehler beim Wechsel auf SAP Cloud ALM ist das Warten. Wer früh beginnt, entscheidet selbst, welche Solution-Manager-Funktionen er überhaupt noch braucht, statt sie unter Zeitdruck nachzubauen. (Quelle: Entplexit)