SAP Monitoring Plattform evaluieren: 12 Fragen, die Sie vor der Auswahl stellen sollten

Die meisten Evaluierungen von SAP Monitoring Plattformen laufen schief, bevor die erste Demo überhaupt beginnt. Das Team definiert Anforderungen auf hoher Ebene, plant Präsentationen mit drei Anbietern, sieht sich ähnliche, perfekt aufbereitete Folien über Echtzeit-Transparenz und intelligentes Alerting an und versucht anschließend, Plattformen zu vergleichen, die auf dem Papier alle weitgehend gleich aussehen.

Die Fragen, die tatsächlich Unterschiede sichtbar machen würden, werden oft nicht gestellt, weil niemand sie vorbereitet hat. Wie verhält sich das Tool, wenn ein Job erfolgreich abgeschlossen wurde, aber Anwendungsfehler in die Spool-Ausgabe geschrieben hat? Kann es SAP BTP Erweiterungen in derselben Ansicht überwachen wie den On-Premise ABAP Stack? Was passiert mit dem Alarmrouting, wenn der Bereitschaftsingenieur im Urlaub ist und eine automatische Eskalation nötig wird?

Diese Checkliste basiert genau auf solchen konkreten Fragen. Jede davon ist darauf ausgelegt, reale Lücken sichtbar zu machen, die generische Demo-Skripte häufig umgehen. Gehen Sie diese Fragen in Gesprächen mit Anbietern durch, und Sie erhalten ein deutlich klareres Bild davon, was jede Plattform tatsächlich leistet und was nur im Marketing versprochen wird.

Abdeckung: Was überwacht die Plattform tatsächlich?

Q1 Deckt sie alle SAP-Komponenten ab, die Sie heute betreiben, einschließlich der Systeme, für die offiziell niemand verantwortlich ist?

Jeder Anbieter wird diese Frage mit Ja beantworten. Entscheidend ist die Anschlussfrage: Bitten Sie um eine dokumentierte Liste der unterstützten Technologien und gleichen Sie diese mit Ihrer tatsächlichen Landschaft ab. Nicht mit Ihrer Ziellandschaft nach der S/4HANA Migration. Sondern mit Ihrer aktuellen Landschaft, inklusive aller Legacy-Komponenten, des BusinessObjects Reporting Clusters, älterer NetWeaver Systeme und kundenspezifischer Konnektoren.

Produktive SAP-Landschaften entsprechen selten dem sauberen Architekturdiagramm aus der IT-Strategiepräsentation. Es gibt fast immer Komponenten, die älter sind als die aktuelle IT-Leitung, Systeme, die technisch veraltet sind, aber weiterhin vom Finanzbereich genutzt werden, und Integrationen, die niemand anfassen möchte, weil sie funktionieren und die Person, die sie gebaut hat, das Unternehmen vor drei Jahren verlassen hat. Eine Monitoring Plattform, die S/4HANA und HANA abdeckt, aber nicht SAP BusinessObjects, erzeugt einen blinden Fleck in einer Ebene, von der Fachanwender täglich abhängig sind.

SAP BusinessObjects ist ein guter konkreter Test. Viele Plattformen behaupten, SAP zu unterstützen, decken aber nur den zentralen ABAP Stack ab. Fragen Sie direkt, ob das Tool Report Scheduling, Publikationsstatus, Verfügbarkeit von Serverknoten und Nutzerlast in BOBJ-Umgebungen überwacht. Wenn die Antwort vage ist, behandeln Sie sie wie ein Nein.

Wie eine gute Antwort aussieht: Der Anbieter stellt ohne Zögern eine Matrix zur Komponentenabdeckung bereit. Sie zeigt die konkrete Monitoring-Tiefe pro Technologie, nicht nur eine Checkbox-Tabelle, in der alles als unterstützt markiert ist.

Warnsignal: Der Anbieter sagt, er unterstütze „alle SAP-Technologien“, kann aber nicht genau benennen, welche Metriken für jede Technologie erfasst werden. Allgemeine Aussagen ohne technische Details sind ein zuverlässiges Zeichen dafür, dass die Abdeckung oberflächlicher ist als behauptet.

Q2 Ist das Deployment agentenlos, und was bedeutet das genau für Ihre Umgebung?

Agentenlos ist ein Begriff, der im SAP Monitoring sehr unterschiedlich verwendet wird. Manche Anbieter meinen damit, dass sie SAP-eigene RFC- oder REST-APIs nutzen, um Daten zu erfassen, ohne zusätzliche Software auf dem SAP Application Server zu installieren. Andere meinen, dass ein Agent auf einem separaten Collector Host läuft statt direkt auf dem SAP Server. Aus operativer Sicht sind das deutlich unterschiedliche Architekturen.

Ein wirklich agentenloses Deployment, das über Standard-SAP-RFC-Verbindungen und APIs arbeitet, hat zwei praktische Vorteile, die mit der Zeit immer wichtiger werden. Erstens gibt es keine Transportaufträge zu pflegen. Jeder SAP Transport ist ein Change-Management-Vorgang, der durch Entwicklung, Qualitätssicherung und Produktion laufen muss, und in regulierten Umgebungen kostet dieser Prozess Zeit. Zweitens bricht das Monitoring Tool nicht, wenn SAP einen Patch veröffentlicht oder Sie Ihr System aktualisieren, weil auf SAP-Seite kein Code installiert ist.

Die Frage an den Anbieter lautet: Wenn wir morgen ein größeres SAP Kernel Upgrade durchführen, erfordert Ihr Monitoring Tool eine Aktion von unserer Seite, bevor es weiter funktioniert? Wenn die Antwort Ja lautet, besteht eine Agentenabhängigkeit, unabhängig davon, was das Marketing sagt.

Wie eine gute Antwort aussieht: Das Deployment erfordert das Anlegen eines technischen RFC-Benutzers mit definierten Berechtigungen, das Verbinden des Collectors mit dem System und den Start der Datenerfassung. Keine Transportaufträge, keine SAP-seitige Software, kein Change-Management-Ticket erforderlich.

Warnsignal: Der Anbieter erwähnt Transporte, SAP-seitige Konfiguration oder etwas, das eine Change Request in Ihrem SAP-System für Einrichtung oder Wartung erfordert. Das schafft laufenden Aufwand, der während der Evaluierung leicht unterschätzt wird.

Alerting: Signalqualität und Konfigurationstiefe

Q3 Wie werden Alarmschwellenwerte konfiguriert, und wer legt sie fest?

Vordefinierte Alarmschwellenwerte sind fast immer falsch für Ihre konkrete Umgebung. Das ist keine Kritik an Anbietern. Es ist ein strukturelles Problem: Standardschwellenwerte sind für ein durchschnittliches SAP-System kalibriert, und Ihr System ist nicht durchschnittlich. Es hat ein spezifisches Lastprofil, spezifische Batch-Zyklen und spezifische Nutzungsspitzen, durch die „80 % CPU“ am Dienstag um 14:00 Uhr etwas völlig anderes bedeuten kann als um 02:00 Uhr am ersten Montag des Monats.

Relevant ist hier, ob Schwellenwerte pro System statt global gesetzt werden können, ob das Tool zeitbasierte Schwellenwerte unterstützt, etwa unterschiedliche Limits während der Geschäftszeiten und während nächtlicher Batch-Fenster, und ob es einen Mechanismus gibt, um Baselines aus historischen Daten zu lernen oder vorzuschlagen.

Eine Monitoring Plattform, die für jede Metrik in jedem System manuelle Schwellenwerteingaben erfordert, wird technisch korrekt, aber operativ ignoriert. Der Konfigurationsaufwand führt irgendwann dazu, dass jemand einen globalen Schwellenwert auf alle Systeme anwendet, nur um das Alarmrauschen zu stoppen. Dann ist man wieder beim Standardverhalten, nur mit zusätzlichen Schritten.

Wie eine gute Antwort aussieht: Schwellenwerte können pro System und pro Zeitfenster konfiguriert werden. Das Tool sammelt vor dem Alerting eine Baseline-Periode oder stellt zumindest Baseline-Daten bereit, damit Administratoren Schwellenwerte definieren können, die das tatsächliche Systemverhalten widerspiegeln.

Warnsignal: Die Standardschwellenwerte werden als produktionsbereit präsentiert. Jede Umgebung ist anders. Ein Anbieter, der überzeugt ist, dass seine Defaults sofort funktionieren, hat die Vielfalt der SAP-Landschaften, in die er verkauft, nicht ausreichend berücksichtigt.

Q4 Was macht die Plattform zwischen der Erkennung einer Anomalie und dem Versand einer Benachrichtigung?

Der Abstand zwischen der Erkennung eines Problems und einem wirklich nützlichen Alarm ist der Bereich, in dem viele Plattformen scheitern. Ein roher Alarm mit dem Inhalt „hohe CPU auf PRD“ um 03:00 Uhr teilt dem Bereitschaftsingenieur mit, dass etwas passiert. Er sagt aber nicht, ob es dieselbe Workprozess-Sättigung ist, die jeden Montag während des MRP-Laufs auftritt, oder ob es sich um eine echte Anomalie handelt. Er sagt nicht, welche Background Jobs zu diesem Zeitpunkt aktiv waren, ob auch der HANA-Speicher unter Druck stand oder ob nachgelagerte Jobs wegen des CPU-Spikes bald ihr Zeitfenster verpassen.

Die Frage lautet: Zeigen Sie mir, wie ein Alarm aussieht, wenn er ausgelöst wird. Nicht den Konfigurationsbildschirm. Die tatsächliche Benachrichtigung, die im Posteingang landet oder das Incident Ticket erstellt. Enthält sie korrelierten Kontext oder nur den Metrikwert, der einen Schwellenwert überschritten hat?

Alert-Korrelation, also das Gruppieren zusammenhängender Ereignisse in einer einzigen Incident-Ansicht statt fünf separater Benachrichtigungen für fünf Symptome derselben Ursache, ist die Funktion, die Monitoring Tools, die operatives Rauschen reduzieren, von denen unterscheidet, die es erzeugen.

Wie eine gute Antwort aussieht: Alarme enthalten korrelierten Kontext: aktive Jobs zum Zeitpunkt der Auslösung, aktuelle Systemereignisse, verwandte Metrikabweichungen. Mehrere Symptome desselben zugrunde liegenden Problems werden zu einem einzigen Incident gruppiert, statt separate Benachrichtigungen zu erzeugen.

Warnsignal: Die Demo zeigt schwellenwertbasierte Alarme, die unabhängig pro Metrik ausgelöst werden. Keine Korrelation, keine Gruppierung, kein Kontext über Metrikname und Wert hinaus. Das ist Infrastruktur-Alerting auf SAP angewendet, kein SAP-bewusstes Monitoring.

Q5 Kann die Plattform Anwendungsfehler innerhalb eines abgeschlossenen Jobs erkennen?

Dies ist die spezifischste Frage in dieser Liste und diejenige, die Anbieter am ehesten unvorbereitet trifft. SAP Background Jobs können mit dem Status FINISHED enden und trotzdem Fehlermeldungen in ihrer Spool-Ausgabe enthalten. Das ABAP-Programm wurde bis zum Ende ausgeführt, hat aber unterwegs Meldungen vom Typ E protokolliert, häufig weil das Programm Ausnahmen intern behandelt, statt sie als Fehler auf Job-Ebene sichtbar zu machen.

Für Jobs im Finanzabschluss, in der Gehaltsabrechnung oder in der Fakturierung ist diese Unterscheidung entscheidend. Ein Job, der 9.400 von 9.500 Rechnungen gebucht hat, weil die übrigen 100 Datenprobleme hatten, sieht in SM37 wie ein erfolgreicher Job aus. Die Abweichung fällt erst auf, wenn ein Fachanwender zwei Tage später die Zahlen abstimmt.

Fragen Sie den Anbieter direkt: Wenn ein Job mit dem Status FINISHED abgeschlossen wird, sein Spool-Protokoll aber Meldungen der Klasse E enthält, alarmiert Ihr Tool darauf? Bitten Sie um eine Demonstration. Viele Plattformen haben diese Fähigkeit nicht, weil sie das Parsen von Spool-Inhalten erfordert und nicht nur das Auslesen des Jobstatus-Feldes. Das ist deutlich komplexer umzusetzen.

Wie eine gute Antwort aussieht: Die Plattform liest die Job-Spool-Ausgabe, erkennt Einträge der Meldungsklassen E und A und alarmiert bei Jobs, die mit Anwendungsfehlern abgeschlossen wurden, auch wenn der Jobstatus FINISHED zeigt. Dies kann in einer Live-Demo oder Testumgebung gezeigt werden.

Warnsignal: Der Anbieter erklärt, dass der Status FINISHED bedeutet, dass der Job erfolgreich abgeschlossen wurde. Das zeigt, dass das Tool die Job-Infrastruktur überwacht, nicht den Job-Inhalt. Für geschäftskritische Batch-Prozesse führt diese Lücke zu Incidents.

Background Job Monitoring: über Statuscodes hinaus

Q6 Kann die Plattform Joblaufzeiten gegen eine Baseline überwachen, nicht nur den Abschlussstatus?

Ein Batch Job, der aktuell doppelt so lange läuft wie normal, ist noch nicht zwingend ein Problem. Vielleicht wird er rechtzeitig fertig. Aber es ist ein Signal. Wenn dieses Signal erkannt wird, während der Job noch läuft, kann das Operations-Team prüfen, bevor das Jobfenster schließt und bevor abhängige Jobs in die Warteschlange geraten.

Laufzeitbasiertes Alerting setzt voraus, dass die Plattform weiß, was für jeden Job normal ist. Das bedeutet, sie muss historische Laufzeitdaten speichern und diese Daten nutzen, um Abweichungen zu erkennen. Außerdem muss sie legitime Laufzeitschwankungen berücksichtigen: Derselbe Job, der an einem normalen Tag 40 Minuten läuft, kann am Monatsende 90 Minuten benötigen, weil das Datenvolumen dreimal so hoch ist.

Fragen Sie, wie das Tool Laufzeit-Baselines erstellt. Nutzt es einen rollierenden Durchschnitt? Erlaubt es getrennte Baselines nach Zeitraum, etwa Monatsende gegenüber normalen Tagen? Können Schwellenwerte als Prozentsatz der Baseline statt als feste Zeitgrenze konfiguriert werden? Eine Plattform, die nur auf „Job läuft länger als X Minuten“ alarmieren kann, erfordert ständige manuelle Nachjustierung, wenn Geschäftsvolumina wachsen.

Wie eine gute Antwort aussieht: Das Tool verfolgt historische Joblaufzeiten, erstellt Baselines pro Job und alarmiert, wenn die aktuelle Laufzeit deutlich von dieser Baseline abweicht. Schwellenwerte werden als Prozentsatz der Baseline-Laufzeit ausgedrückt, nicht als absolute Werte.

Warnsignal: Laufzeit-Monitoring ist nur als fester Zeitschwellenwert verfügbar. Der Anbieter fordert Sie auf, eine maximal akzeptable Laufzeit pro Job zu definieren. Das ist operativ korrekt, erzeugt aber Wartungsaufwand, wenn Volumina sich ändern, und passt sich nicht an legitime Schwankungsmuster an.

Integration mit bestehenden Tools

Q7 Wie integriert sich die Plattform in Ihre ITSM-Lösung, und wie sieht das Ticket aus?

Native ITSM-Integration ist ein Standardversprechen. Was sich zwischen Plattformen stark unterscheidet, ist die Qualität des Ticketinhalts, der erzeugt wird. Eine Integration, die ein ServiceNow Incident mit dem Betreff „SAP Alert: High CPU“ eröffnet, ist technisch gesehen eine Integration. Eine Integration, die ein Incident mit dem betroffenen Systemnamen, der spezifischen Metrik und ihrem aktuellen Wert, den korrelierten Ereignissen im selben Zeitfenster, empfohlenen Untersuchungsschritten und einem direkten Link zur relevanten SAP-Transaktion erstellt, ist ein Werkzeug, das tatsächlich hilft.

Bitten Sie um ein Live-Beispiel eines automatisch erzeugten Incident Tickets. Fragen Sie gezielt nach SAP-spezifischem Kontext: Enthält das Ticket die betroffene SID, die Transaktion oder den Jobnamen, den Workprozess-Typ, relevante Logeinträge? Eine generische IT-Alerting-Integration behandelt SAP wie jedes andere überwachte System. Eine SAP-bewusste Integration erzeugt Tickets, mit denen ein SAP-Basis-Ingenieur arbeiten kann, ohne zuerst alles erneut untersuchen zu müssen.

Fragen Sie außerdem nach bidirektionaler Integration. Wenn ein Incident im ITSM gelöst wird, aktualisiert sich der Alarmstatus in der Monitoring Plattform? Wenn ein Wartungsfenster in der Monitoring Plattform geöffnet wird, unterdrückt es die Incident-Erstellung im ITSM für die Dauer dieses Fensters? Diese Zwei-Wege-Verhaltensweisen unterscheiden eine Integration, die Zeit spart, von einer, die doppelte Arbeit erzeugt.

Wie eine gute Antwort aussieht: Die Demo zeigt ein tatsächlich erzeugtes Ticket mit SAP-spezifischen Feldern: SID, Komponente, Metrikkontext, aktuelle Ereignisse und empfohlene Maßnahme. Die Integration ist bidirektional. Wartungsfenster unterdrücken automatisch die Ticketerstellung.

Warnsignal: Die Integration sendet ein generisches Webhook-Payload an das ITSM. Der Anbieter erklärt, dass Ihr Team das Ticket-Template konfigurieren kann. Konfigurierbar bedeutet: noch nicht erledigt. Sie tragen die Verantwortung für die Integrationsqualität, nicht der Anbieter.

Deployment und operativer Aufwand

Q8 Wie lange dauert es von der Installation bis zu sinnvollem Produktionsmonitoring?

Time-to-Value ist die Kennzahl, die Anbieter während Evaluierungen am stärksten dazu verleitet, zu optimistisch zu sein. Die Demo läuft gegen eine vorkonfigurierte Referenzumgebung, in der alles abgestimmt ist und jedes Dashboard perfekt aussieht. Ihr Produktions-Onboarding wird anders aussehen.

Bitten Sie um einen Referenzzeitplan aus einer vergleichbaren Kundeneinführung, idealerweise mit einer ähnlichen Anzahl an Systemen und einer ähnlichen Landschaftskomplexität. Fragen Sie konkret, wie lange die Baseline-Erfassung dauert, bevor Alerting zuverlässig ist. Fragen Sie, wie die Schwellenwertabstimmung in den ersten Wochen erfolgt, wenn das System normales Verhalten noch lernt. Fragen Sie, wer für diese Abstimmungsarbeit verantwortlich ist: der Anbieter, Ihr Team oder beide gemeinsam.

Ein Tool, das sechs Monate Professional Services benötigt, bevor es aufhört, Fehlalarme zu erzeugen, ist keine Monitoring Plattform. Es ist ein Beratungsprojekt mit angehängter Monitoring Software. Der Onboarding-Prozess sollte in Wochen gemessen werden, und Ihr Team sollte ihn mit Dokumentation des Anbieters durchführen können, nicht nur mit dessen ständiger Präsenz.

Wie eine gute Antwort aussieht: Der Anbieter beschreibt einen strukturierten Onboarding-Prozess mit definiertem Zeitplan: Systemanbindung in wenigen Tagen, Baseline-Erfassung über zwei bis vier Wochen, Schwellenwertprüfung und Tuning, dann Go-live-Freigabe. Referenzkunden mit ähnlicher Landschaftskomplexität stehen für Gespräche zur Verfügung.

Warnsignal: Der Anbieter erwähnt eine „maßgeschneiderte Implementierung“ oder ein Professional-Services-Paket als Standard-Onboarding-Pfad. Implementierungskomplexität, die individuelle Beratungsleistungen erfordert, bedeutet meist, dass das Tool nicht für effizientes Deployment in unterschiedlichen SAP-Landschaften konzipiert ist.

Q9 Wie geht die Plattform mit hybriden Umgebungen um, in denen einige Systeme On-Premise und andere in RISE with SAP oder bei einem Hyperscaler laufen?

Diese Frage ist relevanter geworden, da das RISE with SAP Programm die Cloud-Adoption in Unternehmen beschleunigt. Die Monitoring-Herausforderung in einer hybriden Landschaft besteht nicht nur in technischer Abdeckung. Es geht um einheitliche Transparenz: ein On-Premise NetWeaver System und eine in RISE gehostete S/4HANA Instanz in derselben Ansicht sehen zu können, inklusive korrelierter Ereignisse, wenn ein Geschäftsprozess beide umfasst.

RISE with SAP verdient eine eigene Frage, weil das Modell der geteilten Verantwortung eine Unschärfe erzeugt, die viele Kunden noch nicht vollständig abgebildet haben. SAP verwaltet in RISE die Infrastruktur und die Plattform. Der Kunde verantwortet Anwendungskonfiguration, Erweiterungen, Integrationen und, ganz entscheidend, Observability. Die gewählte Monitoring Plattform muss innerhalb des RISE-Konnektivitätsmodells funktionieren, ohne dass SAP Infrastrukturzugriffe öffnen muss, die außerhalb des Standard-Serviceumfangs liegen.

Fragen Sie den Anbieter, ob er produktive Deployments in RISE with SAP Umgebungen hat. Fragen Sie, wie die Verbindung zur S/4HANA Instanz hergestellt wird. Wenn die Antwort eine nicht standardmäßige Konnektivitätsanfrage an SAP beinhaltet, ist das ein Einführungsrisiko. Eine Plattform, die per Standard-RFC mit einem dedizierten Monitoring-Benutzer verbindet, sollte in RISE ohne Sondervereinbarung funktionieren.

Wie eine gute Antwort aussieht: Der Anbieter bestätigt produktive Deployments in RISE with SAP Umgebungen. Die Konnektivität erfolgt über Standard-SAP-RFC mit einem dedizierten Monitoring-Benutzer, ohne speziellen Infrastrukturzugriff. Hybride Landschaften zeigen On-Premise- und Cloud-Systeme in einer konsolidierten Ansicht.

Warnsignal: Der Anbieter bleibt bei RISE-Kompatibilität vage oder beschreibt Cloud Support als geplanten Roadmap-Punkt. Wenn Hybrid Cloud heute oder innerhalb der nächsten 18 Monate Teil Ihrer Landschaft ist, ist das eine ausschließende Lücke.

Reporting, Resilienz und Gesamtkosten

Q10 Wie sieht Reporting für Personen aus, die keine SAP-Basis-Ingenieure sind?

SAP Monitoring wird oft ausschließlich vom technischen Team evaluiert, das es täglich nutzen wird. Die Reporting-Anforderungen anderer Stakeholder, insbesondere des IT-Leiters, der über Service Levels berichten muss, der Business Process Owner, die Bestätigung über den Abschluss ihrer kritischen Prozesse benötigen, und des MSP Account Managers, der kundenorientierte Daten braucht, landen selten auf der Anforderungsliste.

Eine gute Monitoring Plattform unterstützt mehrere Reporting-Modi. Technische Dashboards für das Basis-Team. Service-Level-Ansichten für das Operations Management. Zusammenfassungen zur Gesundheit von Geschäftsprozessen für die Personen, die die Prozesse besitzen, nicht die Infrastruktur. Wenn eine Plattform nur Rohmetriken in einer Oberfläche zeigen kann, die SAP-Wissen zur Interpretation erfordert, ist ihr Reporting-Wert auf die kleinste Zielgruppe der Organisation begrenzt.

Bitten Sie um eine Demo der Reporting-Ebene aus einer nicht technischen Perspektive. Was würde der Finanzleiter sehen, wenn er sich einloggt? Kann ein Bericht erzeugt werden, der zeigt, ob die drei kritischsten Finanzprozesse im letzten Monat innerhalb ihrer SLA-Fenster abgeschlossen wurden? Kann dieser Bericht automatisiert per E-Mail versendet werden? Wenn eine dieser Fragen mit Nein beantwortet wird, ist die Plattform ein Tool für das Basis-Team, nicht für die Organisation.

Wie eine gute Antwort aussieht: Die Plattform verfügt über rollenbasierte Dashboard-Ansichten. Nicht technische Stakeholder können Abschlussstatus von Geschäftsprozessen, SLA-Compliance-Trends und Verfügbarkeitszusammenfassungen sehen, ohne technische Metriken interpretieren zu müssen. Geplante Berichte können automatisch per E-Mail verteilt werden.

Warnsignal: Jede Ansicht in der Demo erfordert SAP-Metrikkenntnisse, um sie zu verstehen. Der Anbieter positioniert das als Vorteil, nämlich technische Tiefe, statt als Einschränkung. Monitoring, das nur dem technischen Team dient, wird bei Budgetverlängerungen begrenzte organisatorische Unterstützung haben.

Q11 Was passiert, wenn das Monitoring Tool selbst ein Problem hat?

Diese Frage macht Anbieter sichtbar unkomfortabel, und genau deshalb lohnt es sich, sie zu stellen. Monitoring-Infrastruktur kann ausfallen. Collector gehen offline. Datenbankverbindungen brechen ab. Die Monitoring-Datenbank läuft voll. In jedem dieser Szenarien lautet die Frage, ob das Monitoring-System seinen eigenen Ausfall erkennt und meldet, oder ob Sie es erst bemerken, wenn ein Dashboard seit sechs Stunden nicht mehr aktualisiert wurde.

Self-Monitoring ist eine grundlegende Anforderung, aber nicht überall selbstverständlich. Das Monitoring-System sollte alarmieren, wenn seine eigenen Komponenten beeinträchtigt sind, wenn die Datenerfassung für ein bestimmtes System gestoppt wurde oder wenn die Alarmzustellung fehlgeschlagen ist. Es sollte einen dokumentierten Wiederherstellungsprozess für Collector-Ausfälle haben. Idealerweise sollte es außerdem eine Form von Redundanz für Hochverfügbarkeitsumgebungen bieten, in denen Monitoring-Kontinuität selbst Teil des SLA ist.

Fragen Sie den Anbieter: Wenn Ihr Collector um 02:00 Uhr die Verbindung zu unserem SAP-System verliert, wie erfahren wir davon? Wenn die Antwort lautet „Sie würden Lücken in den Daten sehen“, bedeutet das in Wahrheit: Sie würden es erst erfahren, wenn Sie manuell nachsehen. Das ist kein Self-Monitoring. Das ist fehlender Nachweis.

Wie eine gute Antwort aussieht: Die Plattform verfügt über Self-Monitoring-Funktionen. Sie erkennt Collector-Ausfälle, Lücken in der Datenerfassung und fehlgeschlagene Alarmzustellung und informiert das Operations-Team, wenn eines dieser Ereignisse eintritt. Collector-Redundanz oder automatisches Failover ist für kritische Umgebungen verfügbar.

Warnsignal: Der Anbieter wurde in Evaluierungen noch nie nach diesem Punkt gefragt oder beantwortet ihn mit Disaster-Recovery-Verfahren für die Monitoring-Datenbank. Datenwiederherstellung und operatives Self-Monitoring sind unterschiedliche Fähigkeiten. Entscheidend für den täglichen Betrieb ist Letzteres.

Q12 Wie skaliert die Preisgestaltung mit dem Wachstum Ihrer Landschaft, und was ist im Basispreis enthalten?

Die Preisgestaltung im SAP Monitoring variiert stärker als in vielen anderen Enterprise-Software-Kategorien, und diese Variation ist im ersten Angebot nicht immer sichtbar. Das häufigste strukturelle Preismodell basiert auf überwachten SIDs, was transparent und planbar ist. Die Fallstricke liegen darin, was im Basispaket enthalten ist und was als separat bepreistes Add-on hinzukommt.

Fragen Sie gezielt nach typischen Zusatzkosten: ITSM-Konnektoren wie ServiceNow, Jira oder BMC Remedy, die pro Integration berechnet werden, historische Datenaufbewahrung über ein Standardfenster hinaus, Monitoring von Nicht-Produktionssystemen zu abweichenden Tarifen und Zugang zu bestimmten Funktionen wie Custom Dashboards, API-Zugriff oder Spool Monitoring, die hinter höheren Preispaketen liegen.

Fragen Sie außerdem, was bei der Verlängerung passiert. Ein SID-basiertes Modell, bei dem Produktionssysteme X kosten und Nicht-Produktionssysteme weniger als X, ist verständlich. Ein Modell, bei dem nach erfasster Metrik abgerechnet wird oder die Preisgestaltung vom Datenvolumen abhängt, erzeugt Unsicherheit, die mit dem Wachstum Ihrer Landschaft zunimmt. Lassen Sie sich das vollständige Preismodell schriftlich geben, bevor Sie mit einem Proof of Concept starten, nicht erst nachdem Sie bereits drei Monate in die Evaluierung investiert haben.

Wie eine gute Antwort aussieht: Die Preisgestaltung erfolgt pro SID mit klarer Unterscheidung zwischen Produktions- und Nicht-Produktionsraten. Der Basispreis enthält die zentralen Monitoring-Funktionen, ohne dass zusätzliche Module für standardmäßige ITSM-Integration oder Datenaufbewahrung erforderlich sind. Verlängerungspreise sind vertraglich definiert.

Warnsignal: Das Preisgespräch wird auf eine separate kommerzielle Diskussion verschoben. Oder das erste Angebot bezieht sich nur auf die Plattform, während Konnektoren und fortgeschrittene Funktionen als separate Positionen erst nach dem ersten Vorschlag auftauchen.

Die 12 Fragen auf einen Blick

Nutzen Sie diese Zusammenfassung als Referenz in Gesprächen mit Anbietern. Die Spalte „Kernprüfung“ zeigt, was jede Frage im Wesentlichen klären soll.

Wie Sie diese Checkliste in der Praxis nutzen

Gehen Sie diese Fragen vor der ersten Anbieter-Demo durch, nicht erst währenddessen. Wenn Sie sie dem Anbieter im Voraus senden, erhalten Sie vorbereitete Antworten auf die Punkte, bei denen er gute Antworten hat, und Ausweichmanöver oder Schweigen bei den Punkten, bei denen er keine hat. Auch das ist aufschlussreich.

Bitten Sie während der Demo um Live-Demonstrationen der konkreten Szenarien, die für Sie relevant sind. Keine allgemeine Feature-Tour. Zeigen Sie mir, was passiert, wenn dieser Job zu lange läuft. Zeigen Sie mir den Alarm, der ausgelöst wird, wenn das HANA Log Volume 70 % überschreitet. Zeigen Sie mir, wie das Ticket in ServiceNow aussieht. Anbieter, die das konkrete Szenario demonstrieren können, das Sie beschreiben, verfügen tatsächlich über diese Fähigkeit. Anbieter, die auf einen zukünftigen Roadmap-Punkt oder eine mögliche kundenspezifische Konfiguration verweisen, zeigen Ihnen die Lücke.

Führen Sie vor der finalen Entscheidung einen Proof of Concept in Ihrer tatsächlichen Umgebung durch. Zwei bis vier Wochen mit Ihren Systemen, Ihren Jobprofilen und Ihren Alarmkonfigurationen sind mehr wert als zwanzig Stunden Demos. Ein PoC zeigt außerdem Deployment-Komplexität, Baseline-Qualität und Fehlalarmraten, die keine Demo-Umgebung sichtbar macht.

Der Evaluierungsprozess für eine Monitoring Plattform fühlt sich wie zusätzlicher Aufwand an. Das ist er nicht. Die Kosten einer falschen Toolauswahl, die Ihre tatsächliche Landschaft nicht abdeckt, Alarme auslöst, die niemand beachtet, oder stille Fehler übersieht, die Ihre teuersten Incidents verursachen, sind deutlich höher als die Zeit, die Sie investieren, um diese Fragen im Vorfeld zu stellen.

Redpeaks deckt SAP NetWeaver, S/4HANA, HANA, BusinessObjects, BTP und Cloud-Umgebungen über einen einzigen agentenlosen Collector ab, mit Laufzeit-Baselines pro Job, Spool-Level-Alerting und nativer ITSM-Integration.
Fordern Sie eine Demo mit Ihrer eigenen Landschaft an.