Das Ende des SolMan
Der SAP Solution Manager (kurz „SolMan“) ist seit vielen Jahren die ausgereifte Lösung der Wahl für viele Unternehmen im Rahmen ihrer Application-Lifecycle-Management-Strategie (ALM). Er übernimmt Aufgaben innerhalb einer SAP-Topologie wie Prozess-, Test- und Änderungsmanagement, aber auch die Überwachung von Geschäftsprozessen. Diese Funktionen verhindern, dass es beiSAP-Implementierungen zu schwerwiegende Fehler und infolge zu finanziellen Verlusten kommt. SolMan ist jedoch in erster Linie eine Lösung für lokale Landschaften, da die Cloud zum Zeitpunkt der Einführung noch nicht so allgegenwärtig war wie heute.
Der Solution Manager umfasst eine Vielzahl von Funktionen rund um den IT-Betrieb von SAP: Testfallmanagement, risikobasiertes Testen, Testdatenmanagement, technische Überwachung, Change-/Transportmanagement, Sicherheit, Prozessmanagement, Infrastrukturmanagement, Landschaftsmanagement und oft auch zentrale Anwendungen wie CUA (Central User Administration) oder andere technische Dienste/Gateway-Funktionen.
Und genau hier liegt der Kern der Entscheidung von SAP, die Wartung des Solution Managers nur noch bis 2027 fortzuführen: die Migration von On-Prem-Systemen (SAP ECC) auf die Cloud-basierte ERP-Lösung S/4 Hana, die SAP mit allen Mitteln fördert (und forciert). Kunden können die SolMan-Wartung bis 2030 verlängern, allerdings nur in Form einer kostenpflichtigen erweiterten Wartung. Laut SAP werden dabei nicht alle SolMan-Funktionen abdeckt.
Die von SAP angebotene Lösung SAP Cloud ALM ist, wie der Name schon sagt, auf Cloud-Systeme ausgerichtet und weniger für On-Prem-Landschaften geeignet. Zudem betont SAP ausdrücklich, dass es sich – zumindest zum jetzigen Zeitpunkt – nicht um einen SolMan-Nachfolger handelt. Ob der recht enge Zeitrahmen bis 2027 ausreicht, um das Produkt auf das Funktionsniveau von SolMan weiterzuentwickeln, bleibt fraglich.
Unabhängig davon, wie man zu dieser SAP-Strategie steht, das Ende des SolMan ist beschlossene Sache – ohne Diskussion. Für SAP-Anwender ist diese Abkündigung ebenso einschneidend wie das Supportende von ECC, da sie direkte Auswirkungen auf die Fähigkeit der Kunden hat, ihren IT-Betrieb mit SAP wie gewohnt fortzusetzen.
Anwender und Systemadministratoren müssen sich daher proaktiv mit den daraus resultierenden Herausforderungen auseinandersetzen, anstatt sich mit ihnen herumzuschlagen – oder sie im schlimmsten Fall zu ignorieren. Denn auch wenn das Jahr 2027 heute noch in weiter Ferne zu liegen scheint, ist eine erfolgreiche Ablösung des SolMan nur mit umfangreichen Vorüberlegungen und daraus abgeleiteten, sorgfältig geplanten Maßnahmen möglich.
Zunächst gilt es, sich einige zentrale Fragen zu stellen, wie z. B.: Wofür wird der Solution Manager aktuell eingesetzt? Welche Funktionen kann SAP Cloud ALM übernehmen? Können unsere Systeme in die Cloud verlagert werden? Gibt es eventuell geeignetere externe Drittlösungen?
Wer vermisst den Solution Manager?
Da der Einsatz des Solution Managers von SAP vorgeschrieben ist, ist er weit verbreitet. Kleinere Unternehmen nutzen ihn jedoch nur für diese Pflichtbereiche und werden sein Fehlen kaum bemerken. Anders sieht es bei größeren Unternehmen aus. Größere Unternehmen nutzen das Change Request Management (CHaRM) und das IT Service Management (ITSM), die in SolMan integriert sind, sehr intensiv. Sie werden auch die Funktionen zur Überwachung von Geschäftsprozessen in SolMan schmerzlich vermissen, auf die sie sich beim Betrieb ihrer SAP-Landschaften verlassen.
Ist SAP Cloud ALM die Lösung?
Wie bereits erwähnt, kann Cloud ALM – zumindest derzeit – nicht alle Funktionen von SolMan übernehmen. Für ITSM werden Lösungen von Drittanbietern empfohlen und an einem vollwertigen Ersatz für CHaRM wird noch gearbeitet. Sie sind jedoch für Unternehmen, die sie für ihre Change- und Transportprozesse etc. nutzen, unverzichtbar. Auch das gesamte Monitoring in Cloud ALM ist sehr stark auf SAP-Standards ausgerichtet und kann viel weniger an individuelle Anforderungen angepasst werden.
Auch bei den SAP-Verantwortlichen selbst ist ein Umdenken zu beobachten. Früher hieß es, die im Solution Manager integrierte CHaRM-Funktionalität reiche völlig aus und DevOps-Produkte von Drittanbietern seien unnötig. Mit Cloud ALM verhält es sich jedoch völlig anders: SAP öffnet die Lösung über Open Telemetry und APIs für Partnerunternehmen, um die offensichtlichen Lücken zu schließen. Passend dazu wurde Marc Thiers auf dem letzten ALM Summit in Mannheim im Oktober 2023 auf die Frage nach der CHaRM-Funktionalität mit den Worten zitiert: „Ich bin zu alt, um Feinde zu haben“.
Es sei daran erinnert, dass Cloud ALM nur in und für die Cloud verfügbar ist. Unternehmen aus regulierten Branchen, für die eine Cloud-Migration beispielsweise aus rechtlichen Gründen nicht in Frage kommt, bleiben außen vor.
Frühzeitig handeln und Alternativen prüfen
Unabhängig davon, ob ein Unternehmen den Umstieg auf Cloud-ALM plant oder ob eine Drittanbieterlösung die ideale Lösung ist, bleibt die Situation gleich: Die Zeit drängt! Eine Migration – oder möglicherweise sogar die Einführung einer hybriden (Übergangs-)Lösung aus On-Prem und Cloud – erfordert eine umfassende Vorplanung bis hin zur detaillierten Schulung der an der Umstellung beteiligten Mitarbeiterinnen und Mitarbeiter.
Je früher sich die Verantwortlichen – ohne gleich in Panik zu verfallen – mit dem Thema beschäftigen, desto besser. Der erste Schritt besteht darin, festzustellen, welche Funktionen des Solution Managers tatsächlich genutzt werden. Beziehen Sie möglichst alle Stakeholder mit ein, die in irgendeiner Weise von der Abschaltung des SolMan betroffen sind.
Prüfen Sie dann, ob Cloud ALM die von Ihnen genutzten Funktionen ausreichend abdeckt. Häufig können an dieser Stelle bisher heterogen verteilte oder fehlende Funktionen in einer Drittlösung wie einer AIOps-Plattform konsolidiert werden. Idealerweise bietet eine solche Lösung nicht nur den gewünschten Funktionsumfang, sondern unterstützt auch Ihre individuelle SAP-Topologie – sei es Cloud, On-Prem oder eine hybride Kombination aus beiden Welten. Und selbst Unternehmen, die sich in der Migration zu S/4 in der Cloud befinden (was Jahre dauern kann – ein bekannter bayerischer Automobilhersteller hat sich das Jahr 2030 zum Ziel gesetzt), können (oder müssen) einige Bereiche auf ihren lokalen Rechnern belassen.
Schlussfolgerung
Aus dieser Gemengelage ergibt sich ein gemischtes Bild: Kleinere Unternehmen sind von dem angekündigten Ende des Solution Managers in der Regel wenig bis gar nicht betroffen – es sei denn, sie haben auf dieser Basis eigene spezielle Monitoring-Automatismen entwickelt. Größere Unternehmen stehen dagegen vor großen Herausforderungen beim Betrieb ihrer SAP-Landschaften, die umso größer und kritischer werden, je länger sie untätig bleiben. Und angesichts der in diesem Zusammenhang etwas diffusen SAP-Roadmap ist man versucht, schon heute das Ende von SolMan auszurufen (zumal weitere Funktionen wie Focused Build, Focused Insights, Focused Run und Lama ein ähnliches Schicksal erwarten) und sich anderweitig nach Alternativen umzusehen.
Viele Verantwortliche unterschätzen die disruptiven Auswirkungen dieser Abschaltung sowie den Zeit-, Kosten- und Personalaufwand für eine erfolgreiche Umstellung. Es handelt sich nicht um ein technisches Upgrade mit nahtloser Migration. Vielmehr bedarf es einer sorgfältigen Planung, einer dedizierten Datenzuordnung und oft auch einer individuellen Anpassung. Schließlich ändert sich die Art und Weise, wie Geschäftsprozesse verwaltet und überwacht werden, erheblich.
Dieser Herausforderung steht jedoch eine nicht minder große Chance gegenüber. Angesichts der unvermeidlichen Investition in eine oder mehrere neue Alternativlösungen zu SolMan bietet sich für die meisten Unternehmen die ideale Gelegenheit, über den eigenen Tellerrand hinauszuschauen. Der Markt bietet bereits Lösungen mit langjährig erprobten DevOps-Produkten und AIOps-Plattformen namhafter Anbieter. Diese sind nicht nur in der Lage, den Solution Manager zu ersetzen, sondern bieten in der Regel zusätzliche Funktionalitäten und decken zudem flexibel alle aktuellen und zukünftigen SAP-Topologien ab. Es lohnt sich also, hier proaktiv einen genaueren Blick zu werfen, statt alles einfach laufen zu lassen.