Die Kalkulation vieler SAP-Managed-Services-Verträge ist linear. Drei Systeme bei Kunde A benötigen rund 0,3 Vollzeitäquivalente, weitere drei bei B erhöhen den Aufwand auf 0,6. Zehn ähnliche Kunden erfordern drei oder vier zusätzliche Engineers. Das Geschäft wächst, die Stückkosten bleiben gleich. So entsteht eine SAP-spezialisierte Personalagentur statt eines skalierbaren Unternehmens.
Ein Wendepunkt entsteht nicht durch schnelleres Einstellen oder selektivere Kundenauswahl, sondern wenn Monitoring und Automatisierung so viel Routine übernehmen, dass zusätzliche Kunden unterproportionalen Aufwand verursachen. Dieser Artikel beschreibt die nötigen Fähigkeiten, die Wirtschaftlichkeit verschiedener Reifegrade und die besten Investitionsfelder.
Welche Tätigkeiten nicht skalieren und warum
Reaktive Incident-Bearbeitung
Sie ist die teuerste Tätigkeit, mit besonders ungünstig schwankenden Kosten. Ein P1 um 03:00 Uhr kostet drei bis fünf Engineer-Stunden zu Notfallkonditionen. Entscheidend sind Zeitpunkt und Komplexität, nicht Portfolio, gestrige Performance oder Kundenpreis.
Mit wachsendem Portfolio sinkt das Incident-Volumen nicht automatisch. Bei durchschnittlich 1,5 P1 pro System und Monat bringen zwanzig neue Systeme dreißig weitere P1. Entweder wächst das Team proportional oder die Reaktionszeit leidet. Eine dritte Möglichkeit entsteht nur durch weniger Incidents infolge besseren Monitorings und früherer Erkennung.
Kunden-Onboarding
Ohne Werkzeuge sind Anbindung, Landschaftsdokumentation, Baselines, kundenspezifische Schwellen, Abdeckungsprüfung, Reporting und Teambriefing aufwendig. Typisch sind 20 bis 40 Stunden pro Produktivsystem.
Fünf Systeme bedeuten 100 bis 200 Stunden vor dem ersten wiederkehrenden Betrieb. Diese Kosten fallen für einen möglicherweise sechs Monate lang verkauften Vertrag an. Komplexes Onboarding verschlechtert die Neugeschäftsmarge. Ohne Industrialisierung zahlen MSPs dafür, Verträge zu gewinnen.
Monatliches Reporting
Erst werden Verfügbarkeit, SLA-Werte, Incidents und Gesundheitstrends gesammelt, dann formatiert, kommentiert und in die Kundenpräsentation übernommen. Manuell dauert das typischerweise zwei bis vier Stunden pro Kunde und Monat.
Bei fünfzehn Kunden sind das 30 bis 60 Stunden, ungefähr eine Engineer-Woche monatlich für rückblickende Dokumente, die einmal gelesen werden. Dieselbe Zeit hätte in proaktiver Incident-Vermeidung einen höheren Nutzen.
Monitoring-Qualität als wichtigster Skalierungshebel
Das Verhältnis reaktiver und proaktiver Arbeit
Ein Team mit 70 % Incident-Bearbeitung und 30 % Verbesserung kann ohne proportional mehr Personal kaum wachsen. Neue Kunden bringen Reaktivarbeit, die den Verbesserungsanteil immer wieder verdrängt.
Teams mit höchstens etwa 40 % reaktivem Aufwand können eher Kunden ohne proportionalen Personalaufbau aufnehmen. Proaktive Kapazität treibt die Schleife: besseres Monitoring, frühere Erkennung, weniger Incidents, mehr Verbesserungskapazität. Von 70 auf 40 % zu kommen verlangt eine aktive Investitionsphase, die viele MSPs endlos verschieben, weil das Tagesgeschäft keinen Raum lässt.
Alert-Qualität und Aufwand pro System
Vierzig Alerts täglich, davon dreißig Fehlalarme, erzwingen manuelle Sichtung. Zwei Minuten pro Fehlalarm ergeben eine Stunde ohne Mehrwert. Bei zwanzig Engineers und 250 Arbeitstagen ist der Jahresaufwand erheblich. Baseline-basierte SAP-Alert-Konfiguration reduziert diese Arbeit und schafft Kapazität für Wertschöpfung.
Wie ein skalierter MSP aussieht
Das Verhältnis verwalteter SID zu Engineers misst die Effizienz. Bei geringer Monitoring-Reife sind 8 bis 15 Produktivsysteme je Engineer mit viel reaktiver Arbeit und wenig Automatisierung üblich. Nach gezielten Investitionen sind 25 bis 40 bei besserer Servicequalität möglich.
Der Fortschritt entsteht nicht durch härteres Arbeiten oder bessere Rekrutierung, sondern durch weniger Arbeit je System: weniger Incidents, schnellere Erkennung, automatisierte Berichte und standardisiertes Onboarding. Die Tätigkeitsarten bleiben, Routine bindet weniger Zeit.
Bei zwölf Systemen pro Engineer erfordert ein Kunde mit sechs Systemen eine halbe zusätzliche Kapazität. Bei dreißig kann derselbe Kunde innerhalb vorhandener Kapazität aufgenommen werden, sofern die Infrastruktur bereitsteht. Grenzkosten sinken und Margen verbessern sich mit dem Wachstum.
Automatisierung für nichtlineares Wachstum
Onboarding automatisieren
20 bis 40 Stunden lassen sich mit standardisierter Anbindung, automatischer Baseline und Alert-Vorlagen auf 3 bis 5 reduzieren. Agentenloses Monitoring ermöglicht dies auf SAP-Anwendungsebene: RFC-Benutzer und Verbindung werden in weniger als einer Stunde eingerichtet. Baselines laufen automatisch zwei bis vier Wochen vor endgültiger Schwellenfestlegung. Individuell bleiben vor allem vertragliche Geschäftsprozess-SLOs.
Fünf statt dreißig Stunden pro System bedeuten bei fünf Systemen 25 statt 150 Stunden. Zu üblichen Sätzen sind das mehrere Tausend Euro je Neukunde, mit erheblichem kumulativem Effekt im wachsenden Vertrieb.
Reporting automatisieren
Automatische Berichte aus Monitoring-Daten beseitigen Sammlung und Formatierung. Engineers prüfen und ergänzen kundenspezifischen Kontext vor Versand: zwanzig Minuten statt drei Stunden. Für fünfzehn Kunden sinkt der Monatsaufwand von 45 auf weniger als fünf Stunden. SLA-Observability liefert Verfügbarkeit, Incident-Zahl, MTTR und Abschlussquoten ohne manuelle Extraktion.
Incident-Reaktion automatisieren
Automatisierung reduziert Beteiligung, beseitigt sie aber nicht. Automatisch werden vorab bekannte Antworten ausgeführt. HANA-Log-Auslastung löst Backup und Mitteilung aus. Deaktivierte Verbuchung alarmiert sofort kritisch. Ein verspäteter Job erzeugt einen Alert samt normaler Laufzeit und Fristkontext.
Ein Alert mit automatischer Kontexterfassung, definierter Erstmaßnahme und diagnostisch vorgefülltem ITSM-Ticket spart gegenüber manueller Rekonstruktion 30 bis 60 Minuten. Bei zwanzig Kunden und durchschnittlich dreißig Alerts monatlich ergeben sich 15 bis 30 Stunden Ersparnis.
In der Praxis: Automatisierung erleichtert auch die Aufnahme von Juniors in die Bereitschaft. Vorgefüllter Kontext und automatisierte Erstmaßnahmen ermöglichen weniger erfahrenen Engineers eine sichere Betreuung größerer Portfolios. Senior-Wissen wird in Monitoring und Konfiguration eingebettet.
Die Plattforminvestition verändert die Wirtschaftlichkeit
Baselines je System, daraus erzeugte Alerts, Onboarding-Vorlagen, Reporting und ITSM bilden eine Skalierungsinfrastruktur. Reine Metrik-Dashboards sind Sichtbarkeitswerkzeuge. Beides hat Wert, aber nur Ersteres verändert das Engineer-SID-Verhältnis. SAP Managed Operations und MSP-Monitoring beschreiben die Anforderungen. Zwei gesparte Stunden je System und Monat decken bei einem relevanten Portfolio die Lizenzkosten; die Einsparung wächst mit.
Erfolgreich skalierende MSPs investierten bewusst vor einer Kapazitätskrise. Sie bauten die Schicht, solange das Portfolio Zeit ließ. Wer erst bei dreißig Kunden unter Betriebsdruck nachrüstet, erkennt, dass dieser Freiraum vorher geschaffen werden muss.
Redpeaks ist für MSP-Skalierung gebaut: Preise je SID, Mandanten-Dashboards, automatische Baselines, Kundenportale und ITSM mit SAP-Kontext in jedem Incident. Entdecken Sie das MSP-Partnerprogramm.
