SAP Monitoring: Cloud ALM, Solution Manager, Focused Run & CCMS

Welches SAP Monitoring passt zu Ihrer Landschaft? Wir vergleichen SAP Cloud ALM, Solution Manager, Focused Run und CCMS – inklusive Einsatzszenarien für S/4HANA, Cloud und hybride Umgebungen.

Ein abgebrochener Hintergrundjob, eine überlastete Datenbank oder eine fehlerhafte Schnittstelle wirkt zunächst wie ein technisches Problem. In einer produktiven SAP-Landschaft kann daraus jedoch schnell ein stillstehender Auftrag, eine verzögerte Lieferung oder eine blockierte Buchung werden.

SAP Monitoring soll solche Abweichungen erkennen, bevor sie geschäftskritische Prozesse beeinträchtigen. Dafür stehen heute sehr unterschiedliche Werkzeuge zur Verfügung: vom systemnahen CCMS über SAP Solution Manager und SAP Focused Run bis zum cloud-nativen SAP Cloud ALM.

Die entscheidende Frage lautet deshalb nicht: Welches SAP Monitoring Tool ist das beste? Sondern: Welches Werkzeug passt zu unserer Systemlandschaft, unserem Betriebsmodell und unserer SAP-Roadmap?

Dieser Vergleich zeigt, was die vier Ansätze leisten, wo ihre Grenzen liegen und welches Monitoring-Modell sich für SAP S/4HANA, On-Premise-, Cloud-, RISE- und hybride Landschaften eignet.

Das Wichtigste in Kürze

• SAP Cloud ALM ist die strategische ALM-Plattform von SAP und besonders relevant für neue, cloudorientierte und hybride SAP-Landschaften.
• SAP Focused Run richtet sich an große und komplexe Landschaften mit hohen Anforderungen an technisches Monitoring, Alerting und Analytics.
• SAP Solution Manager 7.2 ist in vielen bestehenden On-Premise- und Hybrid-Landschaften weiterhin im Einsatz. Die Mainstream Maintenance endet jedoch am 31. Dezember 2027.
• CCMS ist die klassische, systemnahe Monitoring-Infrastruktur für ABAP-Systeme und bleibt für lokale technische Checks und Diagnosen relevant, ist aber keine moderne zentrale Observability-Plattform.
• SAP Cloud ALM, Focused Run und Solution Manager sind keine funktional identischen Produkte. Ein Wechsel ist deshalb kein einfacher 1:1-Tooltausch.
• Für sehr große oder anspruchsvolle On-Premise- und Hybrid-Landschaften kann eine Kombination aus SAP Cloud ALM und SAP Focused Run sinnvoll sein.
• Effektives SAP Monitoring umfasst heute nicht nur Server und Datenbanken, sondern auch Geschäftsprozesse, Integrationen, Jobs, Benutzererfahrung, Security und Cloud Services.

SAP Monitoring Tools im Schnellvergleich

Kurz gesagt: Für viele neue SAP-Landschaften ist SAP Cloud ALM heute der Ausgangspunkt. Focused Run kommt ins Spiel, wenn Skalierung und technische Monitoring-Tiefe darüber hinausgehen. Bestehende Solution-Manager-Kunden sollten ihre Transition bereits planen, während CCMS weiterhin als systemnahes Basis-Werkzeug dienen kann.

Was ist SAP Monitoring?

SAP Monitoring bezeichnet die kontinuierliche Überwachung von SAP-Systemen, Anwendungen und Geschäftsprozessen mit dem Ziel, Abweichungen frühzeitig zu erkennen und ihren Einfluss auf den Geschäftsbetrieb zu minimieren.

Ein ausgereiftes Monitoring beantwortet dabei nicht nur die Frage:

„Ist das SAP-System erreichbar?“

Sondern beispielsweise auch:

• Läuft ein kritischer Hintergrundjob wie geplant?
• Werden Bestellungen und Rechnungen korrekt verarbeitet?
• Funktioniert die Verbindung zwischen SAP S/4HANA und einem Cloud-System?
• Steigen Antwortzeiten ungewöhnlich stark an?
• Gibt es abgebrochene Prozesse oder technische Exceptions?
• Ist die SAP-HANA-Datenbank gesund?
• Funktionieren Fiori-Anwendungen aus Sicht der Anwender?
• Gibt es Engpässe bei Work Processes, Speicher oder CPU?
• Ist ein Cloud Service verfügbar?
• Ist ein technischer Fehler bereits relevant für einen Geschäftsprozess?

Modernes SAP Monitoring verbindet damit technische Observability mit Business-Kontext.

Welche Bereiche sollte SAP Monitoring abdecken?

Ein häufiger Fehler besteht darin, SAP Monitoring auf CPU, Speicher und Systemverfügbarkeit zu reduzieren.

In komplexen SAP-Landschaften müssen mehrere Ebenen betrachtet werden.

Technisches System Monitoring

Hier geht es um die technische Gesundheit der SAP-Landschaft.

Typische Kennzahlen sind:

• System- und Instanzverfügbarkeit,
• Work Processes,
• CPU- und Speicherauslastung,
• Dateisysteme,
• Datenbankzustand,
• Antwortzeiten,
• Dumps,
• Systemlogs,
• Queues,
• Locks,
• Spool,
• Zertifikate,
• Backup-Status.

Job Monitoring

Viele geschäftskritische Abläufe hängen von automatisierten Jobs ab.

Monitoring sollte daher erkennen:

• abgebrochene Jobs,
• verspätete Starts,
• ungewöhnlich lange Laufzeiten,
• fehlende Ausführungen,
• Fehler im Job- oder Application Log.

Ein Job kann technisch laufen und trotzdem fachlich fehlschlagen. Deshalb reicht die reine Prüfung des Status häufig nicht aus.

Integration & Exception Monitoring

Moderne SAP-Landschaften bestehen selten aus einem einzigen System.

Schnittstellen verbinden beispielsweise:

• SAP S/4HANA,
• SAP SuccessFactors,
• SAP Ariba,
• SAP BTP,
• SAP Integration Suite,
• E-Commerce-Systeme,
• Banken,
• Logistikprovider,
• MES- oder CRM-Systeme.

Monitoring muss deshalb nicht nur einzelne Endpunkte beobachten, sondern möglichst den gesamten Nachrichtenfluss und die dabei auftretenden Exceptions nachvollziehen können.

Business Process Monitoring

Die wichtigste Frage lautet letztlich nicht, ob eine technische Komponente grün ist, sondern ob der Geschäftsprozess funktioniert.

Typische Beispiele sind:

• Order-to-Cash,
• Source-to-Pay,
• Recruit-to-Retire,
• Design-to-Operate.

Business Process Monitoring verbindet technische und fachliche Kennzahlen und ermöglicht es, Prozessstörungen zu erkennen, bevor sie zu größeren Rückständen führen.

User Experience Monitoring

Ein System kann aus Infrastrukturperspektive verfügbar sein und trotzdem für den Benutzer kaum nutzbar sein.

Deshalb werden zunehmend auch folgende Aspekte überwacht:

• Antwortzeiten,
• SAP Fiori und SAPUI5,
• HTTP Requests,
• RFC-Aufrufe,
• reale Benutzerinteraktionen,
• synthetisch simulierte Benutzerabläufe.

Configuration & Security Monitoring

Auch Konfigurationsänderungen und Security-relevante Abweichungen können Bestandteil eines zentralen Monitoring-Modells sein.

Dazu gehören beispielsweise:

• kritische Konfigurationsabweichungen,
• Security-relevante Einstellungen,
• technische Zertifikate,
• unerwartete Veränderungen im System.

SAP CCMS: das klassische technische Monitoring

Das Computing Center Management System (CCMS) gehört seit vielen Jahren zur technischen Basis von SAP-Systemen.

Ein zentraler Einstieg ist der Alert Monitor über die Transaktion RZ20. Dort können Monitoring-Bäume mit technischen Kennzahlen, Schwellenwerten und Alerts dargestellt werden.

CCMS eignet sich unter anderem zur Überwachung von:

• Applikationsservern,
• Work Processes,
• Datenbanken,
• Betriebssystemressourcen,
• Hintergrundjobs,
• Spool,
• Performance,
• technischen Fehlerzuständen.

Vorteile von CCMS

• direkt mit klassischen SAP-Systemen verbunden,
• für viele grundlegende Basis-Checks verfügbar,
• keine zusätzliche zentrale Monitoring-Plattform erforderlich,
• hilfreich für technische Diagnose auf Systemebene.

Grenzen von CCMS

Mit zunehmender Größe und Heterogenität einer SAP-Landschaft wird ein rein systemzentrierter Monitoring-Ansatz schwieriger.

CCMS ist weniger darauf ausgelegt, komplexe End-to-End-Prozesse über zahlreiche Cloud- und On-Premise-Systeme hinweg zentral zu visualisieren und zu korrelieren.

Deshalb ist CCMS heute vor allem als systemnahes Basis-Werkzeug relevant und weniger als Zielarchitektur für unternehmensweites SAP Monitoring.

SAP Solution Manager: umfassendes ALM für bestehende Landschaften

SAP Solution Manager hat über viele Jahre eine zentrale Rolle im Application Lifecycle Management von SAP-Landschaften gespielt.

Monitoring ist dabei nur ein Teil seines Funktionsumfangs.

Für den technischen Betrieb bietet Solution Manager unter anderem:

• System Monitoring,
• Interface Monitoring,
• Business Process Monitoring,
• Job Monitoring,
• Root Cause Analysis,
• Alerting,
• Reporting.

Beim System Monitoring werden technische Objekte wie Systeme, Instanzen, Datenbanken und Hosts regelmäßig geprüft. Typische Kategorien sind:

• Availability,
• Performance,
• Exceptions,
• Configuration.

Schwellenwerte können definiert und bei Überschreitung Alerts erzeugt werden.

Wo Solution Manager weiterhin stark ist

Unternehmen, die Solution Manager bereits intensiv verwenden, haben häufig über Jahre eigene Prozesse, Templates und Integrationen aufgebaut.

Dazu können neben Monitoring beispielsweise gehören:

• Change Request Management,
• Testmanagement,
• IT Service Management,
• Dokumentation,
• Custom Code Management,
• Prozessmanagement.

Genau deshalb sollte die Ablösung nicht als einfache technische Migration betrachtet werden.

Das entscheidende Datum: Ende 2027

Die Mainstream Maintenance für SAP Solution Manager 7.2 endet am 31. Dezember 2027.

SAP empfiehlt Unternehmen, die Transition zu SAP Cloud ALM vor diesem Zeitpunkt zu planen und durchzuführen.

Für bestehende SolMan-Kunden bedeutet das:

Nicht warten, bis die Plattform ausläuft – sondern heute prüfen, welche Solution-Manager-Funktionen tatsächlich verwendet werden und wie die zukünftige ALM-Architektur aussehen soll.

SAP Focused Run: High-Scale Monitoring für komplexe SAP-Landschaften

SAP Focused Run wurde für Organisationen entwickelt, die deutlich höhere Anforderungen an technisches Monitoring und Skalierbarkeit haben.

Typische Zielgruppen sind:

• große Unternehmen,
• Konzerne mit vielen SAP-Systemen,
• komplexe hybride Landschaften,
• IT-Service-Provider,
• Managed-Service-Anbieter,
• Organisationen mit hohen Anforderungen an Monitoring und Analytics.

Focused Run sammelt kontinuierlich technische Daten zu:

• Systemen,
• Instanzen,
• Hosts,
• Datenbanken,
• Anwendungen.

Zu den zentralen Bereichen gehören:

• System Monitoring,
• Alert & Notification Management,
• Analytics & Intelligence,
• Root Cause Analysis,
• Operations Automation,
• Service Level Management.

Was Focused Run von klassischen Monitoring-Ansätzen unterscheidet

Der Vorteil liegt vor allem in der Skalierung.

Statt eine überschaubare Anzahl einzelner Systeme manuell zu beobachten, ist Focused Run für die Verarbeitung großer Mengen von Monitoring-Daten über komplexe Landschaften hinweg ausgelegt.

Monitoring Templates können regelbasiert zugewiesen und Schwellenwerte zentral verwaltet werden.

Auch dynamische Schwellenwerte und historische Analysen helfen dabei, vom statischen „Grenzwert überschritten“ zu einer differenzierteren Bewertung des Systemverhaltens zu kommen.

Für wen ist SAP Focused Run sinnvoll?

Focused Run ist besonders interessant, wenn:

• sehr viele Systeme zentral überwacht werden,
• detaillierte technische Analysen notwendig sind,
• hohe Datenvolumen verarbeitet werden,
• unterschiedliche Kunden- oder Systemlandschaften betreut werden,
• anspruchsvolle On-Premise- und Hybrid-Szenarien bestehen.

Für eine kleinere Cloud-zentrierte SAP-Landschaft wäre dieser Umfang dagegen häufig überdimensioniert.

SAP Cloud ALM: die strategische Plattform für modernes SAP Operations

SAP Cloud ALM ist die cloud-native Application-Lifecycle-Management-Plattform von SAP.

Sie unterstützt sowohl die Implementierung als auch den laufenden Betrieb von SAP-Lösungen.

Für Operations stellt SAP Cloud ALM heute mehrere spezialisierte Monitoring-Bereiche bereit.

Business Process Monitoring

Business Process Monitoring zeigt die Gesundheit geschäftlicher End-to-End-Prozesse.

Es kann unter anderem Prozessstörungen erkennen und KPIs entlang von Prozessen wie:

• Lead-to-Cash,
• Source-to-Pay,
• Recruit-to-Retire,
• Design-to-Operate

überwachen.

Dadurch wird sichtbar, welche technische Abweichung tatsächlich Auswirkungen auf einen Geschäftsprozess hat.

Integration & Exception Monitoring

Dieser Bereich überwacht Nachrichten und Schnittstellen über mehrere Systeme und Cloud Services hinweg.

Dadurch können:

• fehlgeschlagene Messages,
• Exceptions,
• unterbrochene Integrationsflüsse

zentral erkannt und analysiert werden.

Gerade in Landschaften mit SAP Integration Suite, BTP und SaaS-Lösungen ist dies besonders relevant.

Job & Automation Monitoring

SAP Cloud ALM überwacht unter anderem:

• Ausführungsstatus,
• Laufzeit,
• Startverzögerungen,
• Exceptions

von Jobs und automatisierten Prozessen.

Unterstützt werden neben klassischen ABAP-Jobs auch unterschiedliche Cloud- und Automatisierungsszenarien.

Health Monitoring

Health Monitoring konzentriert sich auf technische Zustände und Metriken unterstützter Services und Systeme.

Real User Monitoring

Real User Monitoring untersucht tatsächliche Benutzerinteraktionen und deren Performance.

Das ermöglicht beispielsweise die Analyse von:

• SAPUI5/Fiori,
• Web Dynpro,
• Web GUI,
• HTTP,
• RFC,
• Dialog Requests.

Synthetic User Monitoring

Während Real User Monitoring echte Benutzerinteraktionen analysiert, simuliert Synthetic User Monitoring definierte Abläufe.

Damit lässt sich beispielsweise regelmäßig prüfen, ob ein kritischer Webprozess auch aus Anwendersicht funktioniert.

Configuration & Security Analysis

Dieser Bereich unterstützt die Analyse von Konfigurations- und Security-relevanten Informationen.

Business Service Management

Business Service Management ergänzt das technische Monitoring um Informationen zu Cloud-Service-Verfügbarkeit, Wartungen und Störungen.

SAP Cloud ALM vs. Solution Manager vs. Focused Run vs. CCMS

Ein sinnvoller Vergleich sollte nicht nur eine Feature-Liste betrachten.

Entscheidend sind Zielgruppe, Betriebsmodell, Landschaft und Zukunftsstrategie.

Diese Tabelle bedeutet ausdrücklich nicht, dass Cloud ALM jede einzelne Funktion der anderen Werkzeuge ersetzt.

SAP selbst weist darauf hin, dass zwischen SAP Cloud ALM, SAP Solution Manager und SAP Focused Run keine vollständige funktionale Parität besteht.

Die Auswahl muss deshalb nach konkreten Use Cases erfolgen.

Welches SAP Monitoring Tool passt zu welcher Landschaft?

Szenario 1: Neues SAP-S/4HANA-Cloud-Projekt

Ausgangspunkt: SAP Cloud ALM

Cloud ALM ist besonders naheliegend, wenn die Landschaft stark cloudorientiert ist und SAP S/4HANA Cloud sowie weitere SAP Cloud Services umfasst.

Relevant sind insbesondere:

• Business Process Monitoring,
• Integration Monitoring,
• Job Monitoring,
• Health Monitoring,
• User Monitoring.

Szenario 2: Bestehende SAP-ECC-/S/4HANA-On-Premise-Landschaft mit Solution Manager

Ausgangspunkt: bestehende Nutzung analysieren und Transition planen

Solution Manager muss nicht kurzfristig abgeschaltet werden.

Unternehmen sollten jedoch heute erfassen:

• welche SolMan-Szenarien tatsächlich genutzt werden,
• welche davon in Cloud ALM abgebildet werden können,
• welche Prozesse angepasst werden müssen,
• ob zusätzliche Anforderungen Focused Run rechtfertigen.

Szenario 3: Sehr große hybride SAP-Landschaft

Ausgangspunkt: Cloud ALM und Focused Run gemeinsam bewerten

Wenn ein Unternehmen eine große Zahl technischer Systeme betreibt und tiefes High-Volume-Monitoring benötigt, kann Focused Run die bessere technische Plattform für bestimmte Operations-Szenarien sein.

Cloud ALM kann parallel andere ALM- und Business-Monitoring-Aufgaben übernehmen.

Szenario 4: Einzelnes klassisches ABAP-System

CCMS und lokale Basis-Tools können weiterhin ausreichend sein

Nicht jede Umgebung benötigt sofort eine zentrale Enterprise-Monitoring-Plattform.

Für grundlegende technische Checks eines einzelnen Systems können RZ20 und weitere lokale SAP-Basis-Werkzeuge weiterhin relevant sein.

Sobald jedoch mehrere Systeme, Clouds und Integrationen zusammenspielen, steigt der Nutzen zentraler Monitoring-Lösungen.

Szenario 5: RISE with SAP

Cloud ALM sollte früh in die Monitoring-Architektur einbezogen werden

RISE with SAP enthält SAP Enterprise Support, Cloud Editions und damit grundsätzlich die Berechtigung für SAP Cloud ALM.

Das heißt jedoch nicht, dass jedes Monitoring-Thema automatisch von SAP übernommen wird.

Auch im RISE-Modell müssen Unternehmen klären:

• wer Business-Prozesse überwacht,
• wer Integrationen überwacht,
• wer auf Alerts reagiert,
• wer Tickets eröffnet,
• wer Probleme mit SAP koordiniert,
• welche SLAs gelten.

SAP Cloud ALM oder SAP Focused Run?

Diese Frage wird häufig als Entweder-oder gestellt.

In vielen Fällen ist das die falsche Perspektive.

SAP Cloud ALM ist besonders geeignet, wenn:

• eine cloudorientierte SAP-Strategie verfolgt wird,
• SAP S/4HANA Cloud eingesetzt wird,
• End-to-End-Prozesse überwacht werden sollen,
• Integrationen und Cloud Services zentral sichtbar sein sollen,
• der Aufwand für den Betrieb der Monitoring-Plattform gering bleiben soll.

SAP Focused Run ist besonders geeignet, wenn:

• sehr viele Systeme überwacht werden,
• tiefe technische Telemetrie erforderlich ist,
• große Datenmengen verarbeitet werden,
• komplexe On-Premise-/Hybrid-Landschaften bestehen,
• ein Service Provider zahlreiche Systeme betreibt,
• Advanced Operations und technische Analytics im Mittelpunkt stehen.

Für große Unternehmen lautet die Antwort deshalb durchaus:

SAP Cloud ALM und SAP Focused Run.

SAP selbst sieht Focused Run als mögliche Ergänzung zu Cloud ALM für umfangreiche On-Premise- oder Advanced-Monitoring-Anforderungen.

Kann SAP Cloud ALM Solution Manager vollständig ersetzen?

Nicht automatisch.

Cloud ALM ist keine technisch identische Cloud-Version von Solution Manager.

Beide Plattformen unterscheiden sich in:

• Architektur,
• Bedienkonzept,
• Datenmodell,
• Integrationen,
• unterstützten Szenarien,
• Betriebsmodell.

Unternehmen sollten deshalb keine „Lift-and-Shift“-Migration erwarten.

Der richtige Ansatz lautet:

Use Case für Use Case prüfen.

Beispiel:

Ein Unternehmen nutzt Solution Manager möglicherweise für:

• System Monitoring,
• Business Process Monitoring,
• ChaRM,
• Testmanagement,
• ITSM,
• Custom Code Management,
• Dokumentation.

Dann muss für jeden dieser Bereiche entschieden werden, welches Zielsystem und welcher zukünftige Prozess sinnvoll sind.

Von SAP Solution Manager zu Cloud ALM: Vorgehen vor 2027

Der Übergang sollte strukturiert erfolgen.

1. Solution-Manager-Nutzung inventarisieren

Zunächst wird erfasst, welche SolMan-Komponenten tatsächlich aktiv genutzt werden.

Nicht konfigurierte Funktionen sind für die Transition irrelevant.

2. Kritische Use Cases priorisieren

Monitoring, Change Management, Testing und ITSM haben unterschiedliche Anforderungen.

Jeder Bereich sollte separat betrachtet werden.

3. SAP Readiness Check für Cloud ALM verwenden

SAP stellt einen Readiness Check bereit, der Unternehmen dabei unterstützt, den bestehenden Solution-Manager-Footprint zu analysieren.

4. Zielarchitektur definieren

Das Ergebnis muss nicht zwingend „alles in Cloud ALM“ lauten.

Je nach Anforderungen kann die Zielarchitektur beispielsweise aus:

Cloud ALM + Focused Run + externem ITSM-System

bestehen.

5. Cloud ALM parallel aufbauen

Ein paralleler Betrieb reduziert das Risiko.

Neue Monitoring-Szenarien können zunächst in Cloud ALM aufgebaut und gegen bestehende SolMan-Mechanismen validiert werden.

6. Alerting und Prozesse neu kalibrieren

Die Migration ist eine gute Gelegenheit, über Jahre gewachsene:

• Schwellenwerte,
• Alerts,
• Eskalationen,
• Empfänger

zu bereinigen.

7. Solution Manager schrittweise außer Betrieb nehmen

Erst wenn kritische Szenarien im Zielmodell zuverlässig funktionieren, sollten die entsprechenden SolMan-Funktionen abgeschaltet werden.

SAP Basis Monitoring: Was muss technisch überwacht werden?

Zentrales Monitoring ersetzt die technische Diagnose durch SAP Basis nicht.

Im Alltag kommen weiterhin systemnahe Tools und Transaktionen zum Einsatz.

Ein zentrales Monitoring-System liefert den Alert.

Die Detailanalyse erfolgt anschließend häufig weiterhin mit den technischen Werkzeugen des jeweiligen Systems.

Das ist ein wichtiger Unterschied:

Monitoring erkennt das Problem. Diagnose erklärt seine Ursache.

SAP S/4HANA Monitoring: Welche Ebenen sind relevant?

Bei SAP S/4HANA sollte Monitoring mindestens sechs Ebenen abdecken.

1. SAP-Applikationsschicht

Beispielsweise:

• Work Processes,
• Dumps,
• Logs,
• Jobs,
• Queues,
• Antwortzeiten.

2. SAP HANA

Relevant sind unter anderem:

• Memory,
• CPU,
• Disk,
• Datenbankwachstum,
• Services,
• Backups,
• Replication,
• Performance.

3. SAP Fiori und User Experience

Ein technisch gesundes Backend bedeutet nicht automatisch eine gute User Experience.

Deshalb sollten auch Fiori- und Web-Szenarien überwacht werden.

4. Integrationen

In S/4HANA-Landschaften gewinnen APIs, Events und Cloud-Integrationen zunehmend an Bedeutung.

Das Monitoring sollte deshalb SAP Integration Suite, BTP und angebundene Anwendungen einbeziehen.

5. Geschäftsprozesse

Technische Metriken müssen mit der Frage verbunden werden, ob Aufträge, Rechnungen, Lieferungen oder Produktionsprozesse wie erwartet verarbeitet werden.

6. Cloud Services

Bei Public Cloud, Private Cloud oder RISE verändern sich die Infrastrukturverantwortlichkeiten.

Monitoring muss deshalb klar zwischen SAP-, Kunden- und Partnerverantwortung unterscheiden.

Monitoring in hybriden SAP-Landschaften

Hybride Umgebungen sind besonders anspruchsvoll.

Beispiel:

SAP S/4HANA On-Premise → SAP Integration Suite → SAP SuccessFactors

Wenn eine Datenübertragung fehlschlägt, kann die Ursache an mehreren Stellen liegen:

1. S/4HANA erzeugt die Nachricht nicht,
2. die Integration schlägt fehl,
3. Authentifizierung funktioniert nicht,
4. das Zielsystem ist nicht verfügbar,
5. die Nachricht wird technisch verarbeitet, fachlich aber abgelehnt.

Ein Monitoring-Ansatz, der nur ein einzelnes System betrachtet, kann diesen Ablauf kaum vollständig beurteilen.

Deshalb gewinnen Integration & Exception Monitoring und End-to-End Monitoring in hybriden Landschaften besonders an Bedeutung.

Alerting: Mehr Alerts bedeuten nicht besseres Monitoring

Technisch ist es einfach, sehr viele Warnungen zu erzeugen.

Schwieriger ist es, nur solche Alerts zu erzeugen, auf die tatsächlich jemand reagieren sollte.

Ein sinnvoller Alert benötigt:

• einen klaren Trigger,
• eine Severity,
• den betroffenen Service oder Prozess,
• technischen Kontext,
• einen verantwortlichen Empfänger,
• eine Eskalationsregel,
• möglichst eine Handlungsempfehlung.

Alert Fatigue vermeiden

Wenn ein Team täglich hunderte Warnungen erhält, von denen die meisten keine Aktion erfordern, verliert Monitoring seinen Nutzen.

Typische Ursachen sind:

• zu enge statische Schwellenwerte,
• doppelte Alerts,
• fehlende Abhängigkeiten,
• nicht berücksichtigte Wartungsfenster,
• veraltete Empfängerlisten.

Die Monitoring-Konfiguration sollte deshalb regelmäßig überprüft und kalibriert werden.

Vom Alert zum Incident

Ein Monitoring-System sollte nicht isoliert neben dem Service Desk existieren.

Ein kritischer Alert kann beispielsweise automatisch:

1. ein Event erzeugen,
2. bewertet werden,
3. einem Verantwortlichen zugewiesen werden,
4. ein Ticket im ITSM-System erstellen,
5. Kontextinformationen anhängen,
6. eine Eskalation auslösen.

SAP Cloud ALM unterstützt beispielsweise die Integration externer Ticket-Systeme sowie Event-basierte Aktionen.

Damit wird aus reinem Monitoring ein operativer Prozess.

Kann SAP Monitoring automatisiert reagieren?

Teilweise ja.

Neben der automatischen Ticket-Erstellung können bestimmte Reaktionen automatisiert werden.

Beispiele:

• Diagnosedaten sammeln,
• Verantwortliche informieren,
• Operation Flows starten,
• geprüfte technische Aktionen auslösen.

Automatisierte Eingriffe in produktive Systeme sollten allerdings nur auf Basis kontrollierter und getesteter Verfahren erfolgen.

Nicht jeder Alert sollte automatisch einen Restart auslösen.

SAP-eigene Tools oder Third-Party Monitoring?

SAP-native Werkzeuge haben einen wichtigen Vorteil: Sie besitzen tiefes Wissen über SAP-spezifische Objekte, Prozesse und Schnittstellen.

Third-Party-Observability-Plattformen können dagegen besonders stark sein, wenn ein Unternehmen SAP gemeinsam mit der gesamten IT-Landschaft überwachen möchte.

Relevant können beispielsweise sein:

• Netzwerk,
• Kubernetes,
• Hyperscaler,
• Non-SAP-Anwendungen,
• Infrastruktur,
• zentrale Enterprise-Observability.

In vielen Unternehmen ist deshalb nicht die Frage SAP oder Third Party, sondern wie beide Ebenen sinnvoll integriert werden.

SAP Monitoring einführen: 7 Schritte

1. Kritische Geschäftsprozesse identifizieren

Nicht mit technischen Metriken beginnen.

Zuerst klären:

Welche Prozesse dürfen nicht ausfallen?

2. Abhängige Systeme und Integrationen erfassen

Für jeden kritischen Prozess sollten die beteiligten:

• SAP-Systeme,
• Cloud Services,
• Schnittstellen,
• Datenbanken,
• Infrastrukturkomponenten

bekannt sein.

3. Monitoring Use Cases definieren

Beispielsweise:

• System Monitoring,
• Job Monitoring,
• Business Process Monitoring,
• Integration Monitoring,
• User Monitoring.

4. Zielplattform auswählen

Cloud ALM, Focused Run, bestehender Solution Manager und Third-Party-Tools sollten anhand der Use Cases bewertet werden.

5. KPIs und Schwellenwerte festlegen

Schwellenwerte sollten zum realen Lastprofil passen.

Ein universeller CPU-Grenzwert sagt beispielsweise wenig darüber aus, ob gerade ein geschäftskritischer Prozess gefährdet ist.

6. Alerting und Eskalation definieren

Für jeden kritischen Alert braucht es einen Owner und eine Reaktionszeit.

7. Kontinuierlich optimieren

Monitoring ist kein einmaliges Implementierungsprojekt.

Neue Systeme, Releases, Integrationen und Geschäftsprozesse verändern die Anforderungen laufend.

Die häufigsten Fehler beim SAP Monitoring

Alles überwachen, was technisch möglich ist

Mehr Metriken erzeugen nicht automatisch mehr Transparenz.

Besser: Business-kritische Services priorisieren.

Nur Infrastruktur überwachen

Ein grüner Server bedeutet nicht, dass Order-to-Cash funktioniert.

Besser: technische und fachliche Monitoring-Ebenen kombinieren.

Alerts ohne Owner konfigurieren

Ein Alert ohne Verantwortlichen ist lediglich eine Nachricht.

Besser: Ownership und Eskalation bereits beim Setup definieren.

Standard-Schwellenwerte unverändert übernehmen

Lastprofile unterscheiden sich erheblich.

Besser: Thresholds auf Grundlage historischer Daten kalibrieren.

Cloud und On-Premise getrennt betrachten

Damit verschwinden genau die Abhängigkeiten aus dem Blick, an denen viele Incidents entstehen.

Besser: End-to-End-Sicht auf hybride Prozesse schaffen.

Solution-Manager-Transition zu spät beginnen

2027 klingt noch weit entfernt. Bei umfangreichen SolMan-Installationen kann die Analyse und Transformation zahlreicher ALM-Prozesse jedoch erheblichen Aufwand verursachen.

Besser: Use-Case-Inventur jetzt starten.

Wie LeverX Unternehmen beim SAP Monitoring unterstützt

LeverX unterstützt Unternehmen bei Aufbau, Optimierung und Betrieb von Monitoring-Landschaften für On-Premise-, Cloud- und hybride SAP-Umgebungen.

Dazu können unter anderem gehören:

• Analyse bestehender Monitoring-Prozesse,
• SAP Basis Monitoring,
• SAP Cloud ALM Setup,
• technische und fachliche Monitoring-Konzepte,
• Alerting und Threshold Design,
• Integration & Exception Monitoring,
• Monitoring von SAP S/4HANA und SAP BTP,
• Integration mit Ticket- und Support-Prozessen,
• laufende Betreuung im Rahmen von SAP Basis und Managed Services.

LeverX verfügt dabei nicht nur über theoretische ALM-Erfahrung. In Kundenprojekten wurden unter anderem SAP Solution Manager und SAP Cloud ALM für System Monitoring und Lifecycle Management eingesetzt sowie hybride SAP-S/4HANA-Landschaften im Rahmen von SAP Basis betreut.

Fazit: Welches SAP Monitoring Tool ist 2026 die richtige Wahl?

Es gibt keine universelle Antwort.

SAP Cloud ALM ist für viele Unternehmen der strategische Ausgangspunkt für zukünftiges Application Lifecycle Management und Operations.

SAP Focused Run bleibt besonders relevant, wenn große, komplexe Landschaften tief und in hoher Skalierung überwacht werden müssen.

SAP Solution Manager kann bestehende Landschaften weiterhin zuverlässig unterstützen, allerdings sollte angesichts des Wartungsendes 2027 bereits heute ein Transition-Plan bestehen.

CCMS und lokale SAP-Basis-Tools bleiben wiederum wertvoll für systemnahe technische Überwachung und Diagnose.

Die langfristig beste Architektur orientiert sich deshalb nicht an einem Produktnamen, sondern an den tatsächlichen Anforderungen:

Welche Geschäftsprozesse müssen geschützt werden? Welche Systeme hängen davon ab? Welche Daten benötigen wir zur Diagnose? Und wer muss auf einen Alert reagieren?

Erst wenn diese Fragen beantwortet sind, sollte die Entscheidung für das Monitoring Tool fallen.

Häufige Fragen zu SAP Monitoring

Was ist SAP Monitoring?

SAP Monitoring ist die kontinuierliche Überwachung von SAP-Systemen, Anwendungen, Integrationen und Geschäftsprozessen. Ziel ist es, technische oder fachliche Abweichungen frühzeitig zu erkennen und zu beheben, bevor sie den Geschäftsbetrieb beeinträchtigen.

Welche SAP Monitoring Tools gibt es?

Zu den wichtigsten SAP-eigenen Werkzeugen gehören CCMS, SAP Solution Manager, SAP Focused Run und SAP Cloud ALM. Zusätzlich existieren lokale Basis-Transaktionen und verschiedene Third-Party-Observability-Lösungen.

Was ist das beste SAP Monitoring Tool?

Es gibt kein universell bestes Tool. SAP Cloud ALM eignet sich besonders für moderne Cloud- und Hybrid-Landschaften, Focused Run für umfangreiches High-Scale Monitoring, Solution Manager für viele bestehende On-Premise-Szenarien und CCMS für klassische systemnahe technische Überwachung.

Was ist der Unterschied zwischen SAP Cloud ALM und Solution Manager?

SAP Cloud ALM ist eine cloud-native ALM-Plattform, während SAP Solution Manager kundenbetrieben und historisch auf umfangreiche On-Premise- und Hybrid-ALM-Prozesse ausgerichtet ist. Die Produkte sind nicht funktional 1:1 identisch.

Wann endet der Support für SAP Solution Manager?

Die Mainstream Maintenance für SAP Solution Manager 7.2 endet nach aktueller SAP-Planung am 31. Dezember 2027. SAP empfiehlt, die Transition zu SAP Cloud ALM vor diesem Zeitpunkt vorzubereiten und abzuschließen.

Was ist der Unterschied zwischen SAP Cloud ALM und Focused Run?

SAP Cloud ALM deckt ein breites Spektrum moderner ALM- und Operations-Szenarien ab und wird als Cloud Service von SAP betrieben. SAP Focused Run konzentriert sich stärker auf hochskalierbares technisches Monitoring, Alerting und Analytics für große und komplexe Landschaften. Beide Lösungen können sich ergänzen.

Kann SAP Cloud ALM On-Premise-Systeme überwachen?

Ja. SAP Cloud ALM unterstützt neben Cloud-Lösungen auch verschiedene On-Premise- und Hybrid-Szenarien. Der konkrete Funktionsumfang hängt vom jeweiligen Produkt und Monitoring Use Case ab.

Ist SAP Cloud ALM in RISE with SAP enthalten?

RISE-with-SAP-Verträge umfassen SAP Enterprise Support, Cloud Editions und damit grundsätzlich die Nutzungsberechtigung für SAP Cloud ALM. Für SAP Focused Run gelten separate Lizenzbedingungen.

Was ist SAP CCMS?

CCMS steht für Computing Center Management System und ist die klassische Monitoring-Infrastruktur innerhalb von SAP-Systemen. Über Werkzeuge wie den Alert Monitor RZ20 können technische Kennzahlen und Alerts überwacht werden.

Was umfasst SAP Basis Monitoring?

SAP Basis Monitoring umfasst unter anderem Systemverfügbarkeit, Work Processes, Hintergrundjobs, Dumps, Logs, Datenbank, Speicher, CPU, Queues, Schnittstellen, Backups und technische Performance.

Wie überwacht man SAP S/4HANA?

SAP S/4HANA Monitoring sollte Applikation, SAP HANA, Fiori/User Experience, Jobs, Integrationen, technische Infrastruktur und geschäftskritische Prozesse abdecken. In Cloud- und Hybrid-Landschaften wird dafür zunehmend SAP Cloud ALM eingesetzt.

Kann SAP Monitoring automatisch Tickets erstellen?

Ja. Moderne Monitoring-Plattformen können Alerts mit externen ITSM-Systemen verbinden und automatisch Tickets oder andere Event-Aktionen auslösen. Entscheidend sind klare Prioritäten, Ownership und Eskalationsregeln.

Braucht man neben SAP Cloud ALM noch Focused Run?

Nicht grundsätzlich. Bei sehr großen Landschaften oder hohen Anforderungen an technisches High-Volume Monitoring kann Focused Run jedoch eine sinnvolle Ergänzung zu SAP Cloud ALM sein.