Die operative SolMan-Lücke 2027: was Monitoring, Focused Run und LaMa nach dem Wartungsende ersetzt

1. Was die operative Seite des SAP Solution Manager umfasst

In der Diskussion um das Wartungsende des SAP Solution Manager dreht sich fast alles um Change Request Management. Das ist verständlich, weil ChaRM für viele Organisationen die sichtbarste SolMan-Funktion ist. Es verstellt aber den Blick auf eine zweite, mindestens ebenso kritische Baustelle: den Betrieb. SolMan war nie nur ein Change-Werkzeug, sondern die zentrale Betriebsplattform der SAP-Basis.

Die operative Seite des Solution Manager umfasst eine Reihe von Funktionen, die mit Change und Transport nichts zu tun haben, sondern den laufenden Betrieb der SAP-Landschaft absichern.

1. Technisches Monitoring. Überwachung von Systemverfügbarkeit, Performance, Schnittstellen und Hintergrundverarbeitung, inklusive Alerting an die Betriebsteams.

2. EarlyWatch Alert. Der regelmässige Gesundheitsbericht je System, der Risiken in Performance, Stabilität und Sicherheit früh sichtbar macht. Für viele Basis-Teams das wichtigste einzelne Betriebsartefakt.

3. Business Process Monitoring und End-User-Sicht. Überwachung geschäftskritischer Prozessketten und der Endanwender-Erfahrung, etwa über das frühere End-User Experience Monitoring.

4. Landscape-Automation. System Copy, System Refresh, Mass-Operations und zentrale Start-Stop-Steuerung, traditionell über den eng verbundenen SAP Landscape Manager, kurz LaMa.

5. Landschafts-Verzeichnis und Stammdaten. Das System Landscape Directory als Verzeichnis der technischen Systeme und Komponenten, Grundlage für Monitoring und Wartungsplanung.

6. IT Service Management. Incident, Problem und Service Request, oft eng an die Change-Prozesse gekoppelt.

Diese Funktionen sind kein Beiwerk. Sie sind das Fundament, auf dem der tägliche SAP-Betrieb läuft. Genau dieses Fundament ist vom Wartungsende betroffen, und zwar mit eigenen Fristen und eigenen Nachfolge-Fragen, die sich nicht mit der Change-Diskussion erledigen.

2. Warum das Wartungsende 2027 vor allem die Basis-Teams trifft

1. Das Datum ist dasselbe, die Betroffenheit eine andere. Die Mainstream-Wartung des SAP Solution Manager 7.2 endet am 31. Dezember 2027. Während die Change-Teams über ChaRM-Nachfolge diskutieren, stehen die Basis-Teams vor der Frage, womit sie ab 2028 überhaupt noch überwachen, automatisieren und betreiben. Die Betriebsseite hat in dieser Debatte bisher zu wenig Aufmerksamkeit bekommen.

2. Der Nachfolger zielt auf einen anderen Betrieb. SAP positioniert Cloud ALM als strategische Plattform, aber primär für cloud-zentrische und mittelgrosse Landschaften. Für hochkomplexe, on-premise-dominierte Umgebungen mit hohem Monitoring-Volumen verweist SAP auf Focused Run als ergänzendes Werkzeug. Cloud ALM und Focused Run ersetzen sich nicht, sie ergänzen sich. Wer das nicht trennt, plant falsch.

3. Die Marktrealität verschärft das Problem. Der DSAG-Investitionsreport 2026 dokumentiert, dass 56 Prozent S/4HANA On-Premises betreiben und 54 Prozent noch ECC oder die Business Suite in der Landschaft haben. Rund 78 Prozent fahren hybride oder on-premise-geprägte Setups. Das ist genau die Klientel, für die die rein cloud-native Betriebsausrichtung am wenigsten passt, und die am stärksten auf die Betriebsfunktionen von SolMan angewiesen ist.

4. Mehrere Fristen laufen parallel. Die Betriebsseite hängt an mehreren Produkten mit eigenen End-of-Maintenance-Daten, nicht nur am Solution Manager selbst. Wer nur auf das SolMan-Datum schaut, übersieht, dass auch das Landschafts-Management und das System Landscape Directory eigene Enddaten haben. Die Bestandsaufnahme muss diese Fristen einzeln erfassen.

3. Was die einzelnen Betriebsfunktionen nach 2027 ersetzt

Die Ablösung der Betriebsseite ist kein einzelner Wechsel, sondern eine Reihe funktionsbezogener Entscheidungen. Für jede SolMan-Betriebsfunktion gibt es einen anderen Nachfolgepfad, und nicht jeder Pfad ist SAP-nativ.

1. Technisches Monitoring. Für mittlere und kleinere Landschaften übernimmt Cloud ALM mit seinem Operations-Bereich das technische Monitoring. Für grosse, hochvolumige oder stark on-premise-geprägte Landschaften ist Focused Run der von SAP vorgesehene Weg. Focused Run bleibt über 2027 hinaus in der Mainstream-Wartung und hat eigene, von SolMan unabhängige Wartungsbedingungen. Wichtig: Focused Run ist ein separates, lizenzpflichtiges Produkt, kein Add-on.

2. EarlyWatch Alert. Der EWA-Bericht verschwindet nicht, aber sein Transportweg ändert sich. Statt über SolMan können die Managed-Systeme die Daten über die SDCCN-Komponente direkt an das SAP-Backbone senden, ganz ohne SolMan-Installation, oder die EWA-Funktion über Cloud ALM beziehen. Die Bestandsaufnahme muss klären, über welchen Weg jedes System künftig seine Gesundheitsdaten liefert.

3. End-User- und Prozess-Monitoring. Das frühere End-User Experience Monitoring wird in Cloud ALM durch Synthetic User Monitoring abgelöst. Business Process Monitoring ist in Cloud ALM verfügbar und gilt als einer der reiferen Operations-Bausteine. Hier ist der Nachfolgepfad vergleichsweise klar.

4. Data Volume Management. Das in SolMan integrierte Data Volume Management ist für Cloud ALM nicht geplant. SAP stellt die Funktion stattdessen als eigenständige DVM-App in SAP for Me bereit. Wer DVM heute aktiv nutzt, muss diesen Bruch in der Werkzeuglandschaft bewusst einplanen.

5. Landscape-Automation. Hier liegt die grösste Lücke. Die Mainstream-Wartung für SAP Landscape Management 3.0 endet ebenfalls am 31. Dezember 2027, dokumentiert in SAP-Hinweis 3375877, und SAP plant keine Extended Maintenance. Der vorgesehene Nachfolger SAP Landscape Management Cloud wurde eingestellt. Für System Copy, System Refresh und zentrale Start-Stop-Automation gibt es damit keinen SAP-nativen Nachfolger im eigenen Betrieb. Drittanbieter wie Avantra füllen diese Lücke.

6. System Landscape Directory. Das SLD läuft als Teil von SAP NetWeaver AS Java ebenfalls auf das Wartungsende zu, dokumentiert in der SAP-Knowledge-Base zum Ende der Wartung nach 2027. Die Verzeichnis- und Stammdatenfunktion muss in der Zielarchitektur neu verortet werden, etwa über die Landschaftsdaten in Cloud ALM oder Focused Run.

7. IT Service Management. Den vollwertigen Service Desk aus SolMan bildet Cloud ALM nicht im gleichen Umfang ab. Der etablierte Weg ist die Integration einer dedizierten ITSM-Plattform wie ServiceNow oder Jira Service Management, mit Cloud ALM oder einer Orchestrierungs-Schicht als Change-Anbindung.

4. Wo die Ablösung der Betriebsseite zur Falle wird

1. Die Landscape-Automation hat keinen SAP-nativen Nachfolger. Anders als bei Monitoring, wo Focused Run als Auffanglösung existiert, ist bei der Landschafts-Automation keine Extended Maintenance vorgesehen und der Cloud-Nachfolger eingestellt. Wer heute LaMa für System-Kopien und Mass-Operations nutzt, verliert diese Funktion ersatzlos, wenn nicht aktiv ein Drittanbieter-Pfad aufgebaut wird. Das trifft genau die grossen, hybriden Landschaften am härtesten, die am meisten automatisieren.

2. Cloud ALM liefert keine Full-Stack-Sicht über hybride Landschaften. Cloud ALM ist SAP-zentrisch. Eine durchgängige Beobachtbarkeit über SAP, Infrastruktur, Middleware und Non-SAP-Komponenten hinweg gehört nicht zu seinem Umfang. Organisationen mit heterogenen Landschaften brauchen dafür eine zusätzliche Observability-Schicht, sonst entstehen blinde Flecken im Betrieb.

3. Focused Run ist mächtig, aber nicht voraussetzungslos. Focused Run deckt das hochvolumige Monitoring ab, ist aber ein eigenes Produkt mit eigener Lizenz, eigenem Betrieb und nicht unerheblichem Einrichtungsaufwand. Es ist keine Funktion, die man nebenbei aktiviert. Für kleinere Organisationen kann der Aufwand den Nutzen übersteigen, womit die Entscheidung zwischen Cloud ALM und Focused Run selbst zur Planungsfrage wird.

4. Parallele Fristen erzeugen versteckten Zeitdruck. Weil Solution Manager, Landscape Management und das System Landscape Directory unterschiedliche, aber nahe Enddaten haben, entsteht ein Bündel gleichzeitig fälliger Migrationen. Wer nur das prominente SolMan-Datum plant, läuft Gefahr, die stilleren Fristen zu übersehen und am Ende mehrere Betriebsfunktionen gleichzeitig unter Druck ablösen zu müssen.

5. Der Betrieb fällt zwischen die Zuständigkeiten. Die Change-Diskussion hat einen klaren Eigentümer, die Betriebsseite oft nicht. Monitoring, Automation und Landschaftsdaten verteilen sich über Basis, Infrastruktur und Betrieb. Ohne eine benannte Verantwortung für die operative SolMan-Ablösung bleibt diese Baustelle liegen, bis sie akut wird.

6. Compliance hängt auch am Betrieb. Regelwerke wie NIS2 und DORA verlangen nachweisbare, auditierbare Betriebsprozesse, nicht nur Change-Nachweise. Eine Lücke im Monitoring oder in der Landschafts-Automation ist damit nicht nur ein technisches, sondern auch ein regulatorisches Risiko, weil der lückenlose Betriebsnachweis fehlt.

5. Ein Vorgehensmodell für die operative Ablösung

Die operative SolMan-Ablösung lässt sich strukturieren wie ein eigenes Teilprojekt neben der Change-Migration. Die folgenden Schritte halten die Betriebsseite handhabbar.

1. Funktionsinventar des Betriebs erstellen. Erfassen, welche Betriebsfunktionen tatsächlich genutzt werden: Monitoring-Szenarien, EWA, Business Process Monitoring, DVM, Landscape-Automation, SLD, ITSM. Je Funktion Nutzungsgrad und Kritikalität bestimmen. Dieses Inventar ist die Grundlage für jede weitere Entscheidung.

2. Den offiziellen Readiness-Check nutzen. SAP stellt mit dem Readiness Check und der Datensammlung im Solution Manager ein Verfahren bereit, das einen Nutzungsüberblick erzeugt und zeigt, was migrierbar ist, was manuelle Anpassung braucht und was ausserhalb des Migrationsumfangs liegt. Operations-Daten liegen dabei generell ausserhalb des automatischen Umfangs, was die Bestandsaufnahme umso wichtiger macht.

3. Pro Funktion den Zielpfad festlegen. Für jede Betriebsfunktion den Nachfolger bestimmen: Cloud ALM für mittleres Monitoring und Business Process Monitoring, Focused Run für hochvolumiges und stark on-premise-geprägtes Monitoring, Drittanbieter für Landscape-Automation und Full-Stack-Observability, dedizierte ITSM-Plattform für den Service Desk.

4. Die Werkzeug-Entscheidung Cloud ALM gegen Focused Run bewusst treffen. Die Wahl hängt an Grösse, Volumen und Landschaftstyp, nicht an Cloud-Präferenz. Kleine bis mittlere Landschaften kommen oft mit Cloud ALM aus, grosse hybride Landschaften brauchen Focused Run. Eine Zwei-Werkzeug-Strategie ist legitim und häufig die realistische Antwort.

5. Die stillen Fristen separat terminieren. Landscape Management und System Landscape Directory bekommen einen eigenen Meilenstein, unabhängig von der Change-Migration, damit sie nicht im Schatten von ChaRM untergehen.

6. Betriebsverantwortung benennen. Eine eindeutige Zuständigkeit für die operative Ablösung festlegen, die Basis, Infrastruktur und Betrieb zusammenführt. Ohne benannten Eigentümer bleibt die Betriebsseite unkoordiniert.

6. Tool Landscape

Die folgende Tabelle ordnet ein, welche Werkzeugklasse welche operative SolMan-Funktion nach 2027 abdeckt. Sie zeigt, dass es keine einzelne Eins-zu-eins-Nachfolge gibt, sondern eine Verteilung über Cloud ALM, Focused Run, dedizierte Betriebswerkzeuge und ITSM-Plattformen. Die Change- und Transport-Zeile ist bewusst zum Kontrast mitgeführt, weil sie zeigt, wo eine Orchestrierungs-Schicht ihren Platz hat und wo nicht.

¹ 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. Der Orchestration Layer adressiert Change, Release und Transport, nicht den technischen Betrieb wie Monitoring oder Landscape-Automation. Diese Bereiche liegen bewusst außerhalb seines Funktionsumfangs und werden durch Focused Run und dedizierte Betriebswerkzeuge abgedeckt.

Die Tabelle macht die Arbeitsteilung sichtbar. Der Orchestration Layer ist stark in Change, Release und Transport, aber bewusst nicht im technischen Betrieb. Monitoring, EarlyWatch Alert, Landscape-Automation und das System Landscape Directory liegen ausserhalb seines Funktionsumfangs und werden durch Focused Run und dedizierte Betriebswerkzeuge abgedeckt. Eine vollständige Ablösung der operativen SolMan-Seite kombiniert daher mehrere Werkzeugklassen, statt ein einzelnes Produkt als Gesamtersatz zu erwarten.

7. Operative Konsequenzen für SAP-Organisationen

Aus der Betriebsperspektive ergeben sich konkrete Schritte, die unabhängig von der Change-Migration gelten.

Die erste Konsequenz betrifft die Sichtbarkeit. Die operative SolMan-Ablösung gehört als eigener Strang in die 2027-Planung, nicht als Anhang der ChaRM-Diskussion. Wer den Betrieb nicht separat plant, entdeckt die Lücken erst, wenn sie den laufenden Betrieb treffen.

Die zweite Konsequenz betrifft die Landscape-Automation. Weil es hier keinen SAP-nativen Nachfolger gibt, ist dies der dringlichste Einzelpunkt. Organisationen, die LaMa produktiv für System-Kopien und Mass-Operations nutzen, sollten den Drittanbieter-Pfad früh evaluieren, weil der Aufbau einer Alternative Vorlauf braucht.

Die dritte Konsequenz betrifft die Werkzeug-Strategie. Cloud ALM und Focused Run sind keine Entweder-oder-Entscheidung, sondern eine Frage des Landschaftstyps. Eine bewusste Zwei-Werkzeug-Strategie ist oft die realistische Antwort, und sie muss budgetiert werden, weil Focused Run lizenzpflichtig ist.

Die vierte Konsequenz betrifft die Compliance. Der Betriebsnachweis ist Teil der regulatorischen Anforderungen aus NIS2 und DORA. Eine lückenlose Betriebs-Governance über alle Systeme hinweg ist daher nicht nur eine technische, sondern auch eine Nachweis-Aufgabe, die in die Zielarchitektur gehört.