Der Monitoring Stack ist bei SAP Managed Services nicht einfach ein Kostenfaktor für die Serviceerbringung. Er ist die Risikomanagement-Ebene, die darüber entscheidet, ob ein Vertrag profitabel bleibt.
Jeder P1-Incident, der eine Stunde früher hätte erkannt werden können, verursacht drei bis sechs Stunden ungeplante Engineering-Arbeit unter Notfallbedingungen. Jeder SLA Breach führt zu einer Diskussion über mögliche Vertragsstrafen. Und jeder Kunde, der nach einer Serie schlechter Incidents den Provider wechselt, bedeutet verlorene Onboarding-Kosten und entgangene wiederkehrende Umsätze aus einem Vertrag, dessen Abschluss möglicherweise ein Jahr gedauert hat.
MSPs, die Monitoring als Kostenposition betrachten, die möglichst klein gehalten werden muss, machen einen kommerziellen Fehler.
Der richtige Blickwinkel ist ein anderer: Die Qualität des Monitorings bestimmt direkt die Delivery-Kosten. Und die Delivery-Kosten bestimmen direkt die Marge.
Dieser Artikel zeigt, welche Monitoring-Funktionen für unterschiedliche Preismodelle im SAP Managed Services Bereich erforderlich sind, welche Kosten regelmäßig unterschätzt werden und wie Monitoring-Kompetenz zu einem echten Preisvorteil werden kann.
Wie das Preismodell die Monitoring-Anforderungen bestimmt
Die drei dominierenden Preismodelle für SAP Managed Services verteilen das operative Risiko unterschiedlich zwischen MSP und Kunde. Diese Risikoverteilung bestimmt wiederum, welche Anforderungen der Monitoring Stack erfüllen muss.
Ein pauschales Preismodell pro SID überträgt praktisch das gesamte operative Risiko auf den MSP. Läuft ein System schlecht und benötigt mehr Engineering-Zeit als kalkuliert, trägt der MSP die zusätzlichen Kosten.
In diesem Modell muss der Monitoring Stack ungeplanten Engineering-Aufwand möglichst stark reduzieren. Bedingungen müssen früh genug erkannt werden, damit das Team proaktiv reagieren kann, statt erst nach Eintritt eines Incidents.
Jede Stunde reaktiver Arbeit, die durch einen frühzeitigen Alert hätte verhindert werden können, ist verlorene Marge.
Bei Time-and-Materials-Modellen liegt ein größerer Teil des operativen Risikos beim Kunden. Der MSP wird für die geleisteten Stunden bezahlt, einschließlich Incident Response.
Aus reiner Margensicht sind die Monitoring-Anforderungen in diesem Modell niedriger, weil der Kunde sowohl für die Monitoring-Arbeit als auch für die Folgen unzureichenden Monitorings bezahlt.
Langfristig analysieren T&M-Kunden jedoch, wie viel sie für reaktive Incidents ausgeben. Anschließend wechseln sie entweder den Provider oder strukturieren den Vertrag neu.
Time and Materials in Verbindung mit schlechtem Monitoring ist daher vor allem ein kurzfristig funktionierendes Geschäftsmodell.
Outcome-based Pricing, bei dem der MSP auf Basis der erreichten SLA-Ziele statt der durchgeführten Aktivitäten bezahlt wird, überträgt das größte Risiko auf den MSP und erfordert entsprechend die umfassendste Monitoring-Abdeckung.
Ein MSP kann keine SLAs erfüllen, die er nicht messen kann. Und er kann seine SLA-Performance nicht verteidigen, wenn er sie nicht dokumentieren kann.
Outcome-based Pricing ohne Monitoring Stack, der SLA-relevante Kennzahlen bis auf Business-Prozess-Ebene erfasst, ist ein Vertrag mit hohem Konfliktpotenzial.
Was zum Monitoring Stack jedes gemanagten SAP-Systems gehört
Die Grundabdeckung für alle Systeme
Unabhängig vom Preismodell benötigt jedes gemanagte SAP-Produktivsystem eine kontinuierliche Überwachung derselben zentralen Bereiche.
Die HANA-Speicherauslastung im Verhältnis zum Allocation Limit sollte in kurzen Intervallen gemessen werden, während ausreichend historische Trenddaten für Kapazitätsplanung und Kundenkommunikation erhalten bleiben.
Die Auslastung der Dialog-Workprozesse muss pro Applikationsserver-Instanz überwacht werden. Die Schwellenwerte sollten dabei zeitabhängig sein und die individuellen Batch- und Dialog-Lastprofile der jeweiligen Kundenumgebung berücksichtigen.
Bei Tier-1-Background-Jobs reicht ein einfacher Success/Failure-Status nicht aus. Neben der Erfolgsrate muss auch die Laufzeit gegenüber etablierten Baselines überwacht werden.
Interface-Fehlerraten sollten nach Nachrichtentyp erfasst und durch Volume Anomaly Detection ergänzt werden. Bei bestimmten Interfaces kann ein plötzliches Absinken des Volumens auf null genauso problematisch sein wie ein starker Anstieg der Fehlerzahl.
Auch die HANA-Log-Volume-Auslastung gehört in die Basisüberwachung, mit einem sinnvollen Schwellenwert bei 70 % und nicht erst bei 85 %.
Diese Komponenten sind nicht optional.
Ein MSP, der SAP-Systeme ohne kontinuierliche Abdeckung dieser fünf Bereiche betreibt, arbeitet mit Monitoring-Lücken, die irgendwann zu einem Incident führen werden, den das Monitoring hätte erkennen müssen.
Führt dieser Incident anschließend zu einem SLA Breach, wird die Frage nach der Qualität des Monitoring Stacks zu einer Vertragsfrage und nicht nur zu einer operativen.
Die Reporting-Ebene, die Kunden sehen müssen
SLA Reporting ist das kundenseitige Produkt des Monitoring Stacks.
Ein MSP, dessen monatliche Reports ausschließlich Uptime-Prozentwerte enthalten, präsentiert die Kennzahl, die sich am einfachsten berechnen lässt, aber am wenigsten darüber aussagt, was für den Kunden tatsächlich relevant ist.
Business-relevantes SLA Reporting zeigt die Abschlussquoten von Batch Jobs innerhalb der vereinbarten Zeitfenster, Interface-Erfolgsraten, MTTR nach Incident Severity und Trenddaten, anhand derer erkennbar wird, ob sich die Systemgesundheit über die Vertragslaufzeit verbessert oder verschlechtert.
Ein Kundenportal, in dem Kunden ihre eigenen System-Health-Daten in Echtzeit einsehen können, ohne auf den Monatsreport warten zu müssen, verändert außerdem die Beziehung zwischen MSP und Kunde.
Aus einer klassischen Lieferantenbeziehung wird stärker eine gemeinsame operative Partnerschaft.
Gleichzeitig lässt sich die monatliche Diskussion „das System hat sich letzte Woche langsam angefühlt“ durch eine sachliche Analyse anhand derselben Daten ersetzen, auf die auch der Kunde Zugriff hat.
Diese gemeinsame Datenbasis eliminiert eine wesentliche Quelle von Reibung zwischen Kunde und MSP.
Welche Monitoring-Kosten MSPs regelmäßig unterschätzen
Die Lizenzkosten der Monitoring-Plattform sind der sichtbare Kostenblock.
Die Kosten, die den ROI des Monitorings tatsächlich reduzieren können, sind dagegen häufig menschliche Aufwände, die im Budget nicht explizit berücksichtigt wurden.
Die Pflege der Alert-Qualität ist wahrscheinlich der am stärksten unterschätzte Aufwand.
Eine Monitoring-Konfiguration, die täglich 40 Alerts erzeugt, von denen 35 False Positives sind, spart keine Engineering-Zeit.
Sie führt zu Alert Fatigue. Dadurch werden reale Warnungen übersehen, was wiederum zu genau den Incidents führt, die das Monitoring eigentlich verhindern sollte.
Alert-Schwellenwerte an das konkrete Verhalten der Kundensysteme anzupassen, ist keine einmalige Setup-Aufgabe. Es handelt sich um einen kontinuierlichen Prozess.
Jemand muss regelmäßig die Qualität der Alerts überprüfen und die Schwellenwerte anpassen, wenn sich die SAP-Landschaft des Kunden verändert.
Dieser Aufwand wird im Staffing-Modell eines Managed-Services-Vertrags häufig nicht ausreichend berücksichtigt.
Der zweite regelmäßig unterschätzte Kostenblock ist das Client Onboarding.
Ein neues SAP-Kundensystem mit dem Monitoring Stack zu verbinden, Baselines aufzubauen, kundenspezifische Alert-Schwellenwerte zu konfigurieren und die korrekte Erfassung aller Metriken zu validieren, benötigt in einem strukturierten Onboarding-Prozess etwa 20 bis 40 Stunden pro System.
Bei einem MSP mit einem pauschalen Preis pro SID wird dieser Onboarding-Aufwand zu Beginn des Vertrags vollständig vorfinanziert.
Bei 20 Stunden pro SID und einem Engineer-Satz von 80 € pro Stunde entstehen 1.600 € Onboarding-Kosten, die zunächst wieder verdient werden müssen, bevor der Vertrag profitabel wird.
Bei einem Vertrag mit sechs Monaten Sales Cycle und einer initialen Laufzeit von zwölf Monaten müssen diese Unit Economics von Anfang an in der Kalkulation berücksichtigt werden.
Der dritte unterschätzte Aufwand betrifft die Pflege der Eskalationswege.
On-Call-Kontakte ändern sich, wenn Mitarbeiter ihre Rolle wechseln, das Unternehmen verlassen oder neue Kollegen hinzukommen.
Ein Monitoring-System, das Alerts an Personen sendet, die nicht mehr zuständig sind, oder an Telefonnummern, die inzwischen neu vergeben wurden, wird genau in der Nacht versagen, in der es um 03:00 Uhr funktionieren muss.
Die Eskalationswege sollten deshalb mindestens quartalsweise überprüft werden.
Das entspricht ungefähr einer Stunde pro Kunde und Quartal.
Bei 20 Kunden entstehen daraus 80 Stunden administrativer Aufwand pro Jahr, die in vielen Service-Delivery-Budgets nicht sichtbar sind.
| Achtung: MSPs, die wegen niedrigerer Lizenzkosten auf eine neue Monitoring-Plattform wechseln, unterschätzen manchmal die vollständigen Switching Costs. Alert-Konfigurationen, kundenspezifische Baselines, Reporting Templates und ITSM-Integrationen sind plattformspezifisch. Ein Plattformwechsel für ein Portfolio von 30 Kunden bedeutet, all diese Komponenten für sämtliche Kunden neu aufzubauen. Die Einsparung bei den Lizenzkosten muss deshalb gegen die vollständigen Migrationskosten gerechnet werden und nicht nur gegen die reine Preisdifferenz zwischen den Plattformen. |
|---|
Monitoring-Kompetenz als Preisdifferenzierungsmerkmal
Zwei MSPs können SAP Managed Services zu ähnlichen Preisen anbieten und dennoch völlig unterschiedliche Monitoring-Fähigkeiten besitzen.
Der Unterschied wird im Service Delivery sichtbar.
Der eine MSP ruft den Kunden an und erklärt, dass ein kritischer Zustand erkannt und behoben wurde.
Der andere ruft an und erklärt, dass das System in der vergangenen Nacht einen P1-Incident hatte.
Die kommerzielle Frage lautet, ob Kunden bereit sind, für proaktive Fähigkeiten einen höheren Preis zu zahlen.
Die Antwort ist ja, allerdings nicht für eine abstrakte technische Fähigkeit.
Kunden bezahlen für den nachweisbaren Nutzen.
Ein MSP, der in seinen Quarterly Business Reviews zeigen kann, welche Incidents vor dem User Impact erkannt wurden, welche Capacity Warnings vor einem tatsächlichen Engpass ausgelöst wurden und welche Change-Control-Monitoring-Reports Audit-Anforderungen erfüllt haben, demonstriert den Wert seines proaktiven Monitorings anhand von Ergebnissen, die der Kunde direkt mit seiner eigenen operativen Erfahrung verbinden kann.
Ein MSP, der solche Nachweise nicht liefern kann, weil der Monitoring Stack die dafür notwendigen Daten nicht erfasst, konkurriert hauptsächlich über den Preis.
Preiswettbewerb bei SAP Managed Services führt jedoch schnell zu einem Margenniveau, das die meisten MSPs nicht halten können, ohne die Servicequalität zu reduzieren.
Der Monitoring Stack ermöglicht es einem MSP, über Fähigkeiten statt ausschließlich über den Preis zu konkurrieren.
Bestimmte Monitoring-Funktionen unterstützen Premium-Pricing besonders deutlich: Business Process Completion Monitoring, das die für das Business relevanten SLA-Ziele misst und nicht nur die Infrastruktur; proaktive Kapazitätsplanung mit dokumentierten Empfehlungen; Configuration Drift Monitoring mit auditfähigen Änderungsreports; und kundenorientierte Dashboards, die dem Kunden direkte Transparenz über seine eigene Umgebung geben.
Jede dieser Fähigkeiten ermöglicht eine konkrete Diskussion darüber, warum das Angebot mehr wert ist als das eines Providers, dessen Monitoring bei Server-Uptime beginnt und endet.
Die versteckten Kosten von unzureichendem Monitoring
Der Business Case für Investitionen in Monitoring-Fähigkeiten wird besonders deutlich, wenn man die Kosten betrachtet, die ohne diese Fähigkeiten entstehen.
Ein P1-Incident auf einem SAP-Produktivsystem außerhalb der Geschäftszeiten, der drei Engineers bindet, vier Stunden bis zur Lösung benötigt und anschließend eine Diskussion über SLA-Vertragsstrafen auslöst, kann den MSP allein an direkten Engineering-Kosten zwischen 3.000 € und 6.000 € kosten.
Hinzu kommen die Auswirkungen auf die Kundenbeziehung und gegebenenfalls die vertraglich vereinbarte SLA-Strafe.
Hätte derselbe Incident zwei Stunden früher erkannt und ohne Eskalation behoben werden können, lägen die Kosten einer proaktiven Monitoring-Reaktion möglicherweise näher bei 400 €.
Die Break-even-Rechnung für Monitoring-Investitionen ist daher relativ einfach.
Wie viele verhinderte P1-Incidents pro Jahr sind erforderlich, damit sich die Monitoring-Plattform selbst bezahlt?
Für die meisten MSPs, die zehn oder mehr SAP-Produktivsysteme betreuen, liegt diese Zahl unter der Anzahl der P1-Incidents, die sie aktuell pro Jahr erleben.
Die Monitoring-Investition ist damit kein klassisches Cost Center.
Sie ist ein Programm zur Senkung von Incident-Kosten, das gleichzeitig das Risiko von Kundenabwanderung reduziert. Und Client Churn gehört zu den teuersten Ereignissen in jedem Managed-Services-Geschäftsmodell.
Wenn ein Kunde nach einer Serie vermeidbarer Incidents kündigt, entstehen Kosten, die selten vollständig berücksichtigt werden: die Sales-Kosten für einen Ersatzkunden, die typischerweise sechs bis zwölf Monatsumsätze des Vertrags ausmachen können; der Verlust einer Kundenreferenz, wenn der ehemalige Kunde seine Erfahrungen mit potenziellen Neukunden teilt; und die interne Belastung, die der Verlust eines bedeutenden Kunden im Serviceportfolio verursacht.
Ein MSP, der jedes Jahr einen großen SAP-Managed-Services-Kunden wegen mangelhafter Incident-Qualität verliert, trägt versteckte Kosten, die deutlich höher sein können als die Investition in die Monitoring-Plattform, die diesen Verlust möglicherweise verhindert hätte.
Der Monitoring Stack sollte deshalb bereits in das Preismodell integriert werden, bevor der erste Kundenvertrag unterschrieben wird, und nicht erst dann, wenn die Marge beginnt zu sinken.
Plattformkosten, Onboarding-Aufwand pro System, Pflege der Alert-Qualität und Reporting-Arbeit sind vorhersehbare Kosten.
Ein Pricing-Modell, das diese Faktoren berücksichtigt, erzeugt Verträge, die nachhaltig profitabel bleiben.
Ein Modell, das sie ignoriert, erzeugt Verträge, deren Marge mit jeder nicht eingeplanten Zusatzleistung weiter sinkt.
Die MSPs, die im SAP Managed Services Markt nachhaltig wachsen, behandeln ihre Monitoring-Fähigkeiten als Produkt und nicht als unsichtbaren Infrastrukturkostenblock.
Ihre Preise spiegeln wider, was proaktive Operations tatsächlich kosten. Ihr Reporting zeigt dem Kunden, welchen Mehrwert diese Investition erzeugt. Und ihre Marge verschwindet nicht jedes Mal, wenn ein Incident auftritt, den das Monitoring eigentlich hätte erkennen müssen.
Redpeaks wurde für MSP-Deployments im großen Maßstab entwickelt: Pricing pro SID, Multi-Client-Dashboards, kundenorientierte Portale und ITSM-Integrationen, die Alerts mit dem relevanten SAP-Kontext weiterleiten. Das Onboarding eines neuen Kundensystems dauert Stunden statt Wochen.
