SAP Support, SAP AMS oder Managed Services: Was ist der Unterschied?

Was unterscheidet SAP Support, Application Management Services und Managed Services? Der Leitfaden vergleicht Leistungen, Verantwortlichkeiten, SLAs und passende Einsatzbereiche.

SAP Support konzentriert sich in der Regel auf Anwenderanfragen, Incidents und konkrete technische oder funktionale Probleme. SAP Application Management Services (AMS) umfassen zusätzlich die kontinuierliche Betreuung, Optimierung und Weiterentwicklung von SAP-Anwendungen. SAP Managed Services gehen häufig noch weiter und übertragen einem externen Anbieter die laufende Verantwortung für definierte Betriebsbereiche wie Monitoring, SAP Basis, Infrastruktur, Verfügbarkeit oder Security.

Die Grenzen sind jedoch nicht vollständig standardisiert. Je nach Anbieter können sich SAP Support, AMS und Managed Services teilweise überschneiden. Entscheidend ist deshalb nicht allein die Bezeichnung des Angebots, sondern der im Vertrag und im Service Level Agreement definierte Leistungsumfang.

In diesem Leitfaden erfahren Sie:

• wie sich SAP Support, SAP AMS und Managed Services unterscheiden,
• welche Leistungen typischerweise zu den drei Modellen gehören,
• wo Überschneidungen entstehen,
• welches Modell zu welchem Unternehmen passt,
• welche Verantwortlichkeiten intern bleiben sollten,
• wie sich die Modelle miteinander kombinieren lassen.

Warum werden SAP Support, AMS und Managed Services häufig verwechselt?

Die drei Begriffe beschreiben keine vollständig voneinander getrennten Produktkategorien. Sie bezeichnen vielmehr unterschiedliche Formen der laufenden Betreuung von SAP-Systemen und -Anwendungen.

Alle drei Modelle können beispielsweise folgende Leistungen enthalten:

• Bearbeitung von Incidents,
• technische Fehleranalyse,
• Unterstützung von Anwendern,
• Service Level Agreements,
• Monitoring,
• Reporting,
• Bereitschaft für kritische Störungen,
• Zusammenarbeit mit SAP und weiteren Anbietern.

Der Unterschied liegt vor allem im Umfang der übernommenen Verantwortung.

Beim klassischen SAP Support steht meist die Lösung konkreter Anfragen und Störungen im Vordergrund. AMS ergänzt diese reaktive Unterstützung um kontinuierliche Aufgaben wie Problem Management, kleinere Changes, Release-Begleitung und Anwendungsoptimierung. Managed Services übertragen dem Dienstleister häufig zusätzlich die Verantwortung für den stabilen technischen Betrieb eines klar definierten Servicebereichs.

Die Bezeichnung allein reicht nicht aus

Ein Anbieter kann sein Angebot als „SAP Support“ bezeichnen und trotzdem Monitoring, Changes und Release Management einschließen. Ein anderer verwendet dafür den Begriff „SAP AMS“. Wieder andere fassen Anwendungsbetreuung und technischen Betrieb unter „SAP Managed Services“ zusammen.

Unternehmen sollten deshalb nicht nur fragen:

Wie heißt das Service-Modell?

Wichtiger sind konkrete Fragen wie:

• Welche Systeme, Anwendungen und Module sind enthalten?
• Werden nur Tickets bearbeitet oder auch Ursachen und Backlogs?
• Sind Changes, Releases und Optimierungen Bestandteil des Services?
• Wer übernimmt Monitoring und technischen Betrieb?
• Welche Support-Level werden abgedeckt?
• Welche Servicezeiten und Reaktionszeiten gelten?
• Wer trägt die Verantwortung für SAP Basis, Infrastruktur und Security?
• Welche Aufgaben verbleiben beim internen IT-Team?
• Wie werden Leistungen gemessen und berichtet?

Der zentrale Unterschied auf einen Blick

Die drei Modelle lassen sich zunächst folgendermaßen einordnen:

• SAP Support: Hilfe bei konkreten Anfragen, Incidents und Service Requests.
• SAP AMS: Kontinuierliche Betreuung und Weiterentwicklung von SAP-Anwendungen.
• SAP Managed Services: Laufende Verantwortung für definierte technische oder operative Services.

Diese Einordnung dient als Orientierung. Der tatsächliche Leistungsumfang muss immer anhand von Vertrag, SLA, Rollenmodell und Servicekatalog geprüft werden.

Entlasten Sie Ihr internes IT-Team mit klar definiertem SAP Support und verlässlichen SLAs.
SAP Support besprechen

SAP Support, AMS und Managed Services im direkten Vergleich

SAP Support, Application Management Services und Managed Services unterscheiden sich vor allem darin, welche Verantwortung ein externer Dienstleister übernimmt.

SAP Support ist in der Regel auf konkrete Anfragen, Störungen und Service Requests ausgerichtet. SAP AMS erweitert diese Leistungen um die kontinuierliche Betreuung und Optimierung von Anwendungen. Bei SAP Managed Services übernimmt der Anbieter häufig zusätzlich die operative Verantwortung für klar definierte technische Services und deren Verfügbarkeit.

SAP Support: Fokus auf Tickets und konkrete Probleme

Beim SAP Support steht die Bearbeitung einzelner Anfragen im Vordergrund. Dazu gehören beispielsweise:

• Anwenderfragen,
• Incidents,
• Fehlermeldungen,
• Berechtigungsprobleme,
• funktionale Prozessfehler,
• technische Störungen,
• kleinere Service Requests,
• Eskalationen an spezialisierte Experten.

Die Leistung wird häufig nach Support-Leveln organisiert. Der L1 Support nimmt Tickets auf und löst standardisierte Probleme. Der L2 Support übernimmt funktionale und technische Analysen. Der L3 Support bearbeitet komplexe Entwicklungen, Integrationen und technische Ursachen.

SAP Support ist besonders geeignet, wenn ein Unternehmen seine interne IT gezielt entlasten, fehlende SAP-Kompetenzen ergänzen oder klar abgrenzbare Ticketarten auslagern möchte.

Der Schwerpunkt liegt jedoch normalerweise nicht auf einer umfassenden, langfristigen Verantwortung für die gesamte Anwendung.

SAP AMS: Fokus auf Anwendungen und kontinuierliche Verbesserung

SAP Application Management Services umfassen mehr als die reine Bearbeitung von Incidents. Der Dienstleister betreut definierte SAP-Anwendungen über einen längeren Zeitraum und unterstützt sowohl deren Stabilität als auch ihre Weiterentwicklung.

Typische AMS-Leistungen sind:

• Incident- und Problem-Management,
• L2- und L3-Support,
• Service Requests,
• kleinere und mittlere Changes,
• Release- und Upgrade-Begleitung,
• Backlog-Management,
• Anwendungsmonitoring,
• Prozessoptimierung,
• technische Weiterentwicklung,
• Dokumentation und Wissenstransfer,
• regelmäßige Service Reviews.

Ein zentraler Unterschied zum klassischen Support ist der stärkere proaktive Ansatz. Das AMS-Team löst nicht nur einzelne Tickets, sondern analysiert auch wiederkehrende Probleme, technische Schulden und Optimierungsmöglichkeiten.

SAP AMS ist deshalb besonders für Unternehmen geeignet, die ihre SAP-Anwendungen kontinuierlich betreuen und verbessern möchten, ohne alle benötigten Rollen dauerhaft intern aufzubauen.

SAP Managed Services: Fokus auf Betrieb und Serviceverantwortung

Bei SAP Managed Services übernimmt der Anbieter häufig die laufende Verantwortung für klar definierte technische oder operative Services.

Dazu können gehören:

• SAP-Basis-Betrieb,
• SAP-HANA-Administration,
• Infrastruktur und Cloud-Plattformen,
• Systemmonitoring,
• Verfügbarkeitsmanagement,
• Backup und Recovery,
• Patch Management,
• technische Wartung,
• Kapazitätsplanung,
• Security Monitoring,
• Job- und Schnittstellenüberwachung,
• technische Unterstützung bei Releases.

Der Dienstleister arbeitet nicht nur einzelne Aufgaben ab, sondern verantwortet vereinbarte Service-Ergebnisse, beispielsweise Systemverfügbarkeit, technische Stabilität oder definierte Betriebsprozesse.

Managed Services sind besonders relevant, wenn ein Unternehmen den technischen SAP-Betrieb teilweise oder weitgehend an einen spezialisierten Anbieter übertragen möchte.

Wie wird der Erfolg der drei Service-Modelle gemessen?

Die drei Modelle unterscheiden sich nicht nur im Leistungsumfang, sondern auch darin, wie ihre Qualität und ihr Erfolg gemessen werden.

Beim SAP Support stehen häufig Ticket-Kennzahlen im Vordergrund:

• Reaktionszeit,
• Lösungszeit,
• Anzahl bearbeiteter Tickets,
• First Contact Resolution,
• SLA-Erfüllung.

Bei SAP AMS kommen zusätzliche Qualitäts- und Entwicklungsziele hinzu:

• Reduzierung wiederkehrender Incidents,
• Entwicklung des Backlogs,
• erfolgreiche Umsetzung von Changes,
• Anwendungsqualität,
• kontinuierliche Verbesserung.

Managed Services werden stärker an Betriebskennzahlen gemessen:

• Systemverfügbarkeit,
• Performance,
• Anzahl technischer Ausfälle,
• erfolgreiche Backups,
• Kapazitätsauslastung,
• Einhaltung von Wartungs- und Security-Vorgaben.

Praxisbeispiel: So lassen sich die drei Modelle kombinieren

Ein Unternehmen kann für dieselbe SAP-Landschaft alle drei Modelle nutzen:

• Der SAP Support bearbeitet Anwenderanfragen und Incidents in Finance, Einkauf und Logistik.
• Das AMS-Team übernimmt Changes, Release-Begleitung und die kontinuierliche Optimierung dieser Anwendungen.
• Der Managed-Services-Anbieter verantwortet SAP Basis, Monitoring, Backups und den technischen Betrieb.

Die Modelle schließen sich somit nicht gegenseitig aus. Sie können als unterschiedliche Ebenen eines gemeinsamen Service-Modells kombiniert werden.

Entscheidend ist, dass Systeme, Leistungen, Rollen und Schnittstellen eindeutig abgegrenzt sind. Andernfalls entstehen doppelte Zuständigkeiten, verzögerte Eskalationen und Unklarheiten darüber, welcher Anbieter für ein Problem verantwortlich ist.

Welche Leistungen umfasst SAP Support?

SAP Support umfasst die strukturierte Bearbeitung von Anwenderanfragen, Incidents, technischen Störungen und klar definierten Service Requests. Ziel ist es, Probleme möglichst schnell zu lösen, betroffene Geschäftsprozesse wiederherzustellen und Anwender sowie interne IT-Teams im laufenden SAP-Betrieb zu entlasten.

Der konkrete Leistungsumfang hängt vom vereinbarten Support-Modell ab. Unternehmen können einzelne SAP-Module, bestimmte Ticketarten oder den vollständigen L1-, L2- und L3-Support an einen externen Dienstleister übertragen.

Typische Aufgaben im L1-, L2- und L3-Support

SAP Support wird häufig in drei Support-Level gegliedert:

• Der L1 Support nimmt Anfragen entgegen, dokumentiert und priorisiert Tickets und löst bekannte Standardprobleme.
• Der L2 Support analysiert funktionale und technische Störungen, die vertiefte Kenntnisse von SAP-Modulen, Geschäftsprozessen, Stammdaten oder Customizing erfordern.
• Der L3 Support bearbeitet komplexe Fehler in kundenspezifischen Entwicklungen, Integrationen und technischen Architekturen.

Typische Leistungen im SAP Support sind:

• Annahme und Klassifizierung von Tickets,
• Unterstützung von Anwendern und Key Usern,
• Incident Management,
• funktionale und technische Fehleranalyse,
• Berechtigungs- und Rollenprobleme,
• Unterstützung bei Stammdatenfehlern,
• Prüfung von Customizing und Systemeinstellungen,
• Analyse von Schnittstellen und Datenflüssen,
• Fehlerbehebung in kundenspezifischem ABAP-Code,
• Unterstützung für SAP Fiori und SAPUI5,
• Eskalation an SAP oder weitere Technologieanbieter,
• Dokumentation von Lösungen und Workarounds.

Die detaillierten Aufgaben und Eskalationswege erklären wir im Leitfaden zu den SAP Support Leveln 1, 2 und 3.

Welche Tickets gehören zum SAP Support?

Zum klassischen SAP Support gehören vor allem Anfragen, die sich auf ein konkretes Problem oder einen klar definierten Bedarf beziehen.

Typische Beispiele sind:

• Ein Anwender kann einen Geschäftsprozess nicht abschließen.
• Eine Bestellung wird nicht freigegeben.
• Eine Rechnung kann nicht gebucht werden.
• Ein Benutzer verfügt nicht über die benötigte Berechtigung.
• Eine Schnittstelle verarbeitet einzelne Datensätze nicht korrekt.
• Ein Hintergrundjob wird nicht erfolgreich ausgeführt.
• Eine SAP-Fiori-Anwendung zeigt fehlerhafte Informationen.
• Ein kundenspezifisches Programm verursacht einen Prozessabbruch.
• Eine bekannte Funktion muss für einen Anwender erklärt werden.
• Ein kleiner Service Request soll geprüft und umgesetzt werden.

Entscheidend ist, dass das Ticket einem definierten System, Prozess oder Fehlerbild zugeordnet werden kann.

Je nach SLA kann der SAP Support auch kleinere Konfigurationsänderungen, technische Korrekturen und begrenzte Changes umfassen. Größere Weiterentwicklungen, Releases oder Prozessoptimierungen gehören dagegen häufig zu SAP AMS oder zu einem separaten Projekt.

Wie wird SAP Support gesteuert?

Professioneller SAP Support basiert auf klar definierten Prozessen und Service Level Agreements.

Im SLA sollte unter anderem festgelegt werden:

• welche SAP-Systeme und Module unterstützt werden,
• welche Support-Level enthalten sind,
• zu welchen Zeiten der Support verfügbar ist,
• wie Tickets priorisiert werden,
• welche Reaktionszeiten gelten,
• wann eine Eskalation erfolgen muss,
• welche Kommunikationswege genutzt werden,
• welche Änderungen im Support-Umfang enthalten sind,
• welche Leistungen zusätzlich beauftragt werden müssen.

Die Qualität des SAP Supports wird häufig anhand folgender Kennzahlen bewertet:

• Reaktionszeit,
• Wiederherstellungszeit,
• Lösungszeit,
• SLA-Erfüllung,
• First Contact Resolution Rate,
• Anzahl offener Tickets,
• Eskalationsquote,
• Wiedereröffnungsrate,
• Anwenderzufriedenheit.

Eine hohe Anzahl geschlossener Tickets ist allein jedoch kein ausreichendes Qualitätsmerkmal. Ebenso wichtig ist, ob Probleme dauerhaft gelöst, korrekt dokumentiert und bei Wiederholungen systematisch analysiert werden.

Wo liegen die Grenzen des klassischen SAP Supports?

SAP Support ist vor allem auf die Bearbeitung konkreter Anfragen und Störungen ausgerichtet. Er umfasst normalerweise nicht automatisch die langfristige Verantwortung für die Weiterentwicklung der gesamten Anwendung oder den vollständigen technischen Betrieb der SAP-Landschaft.

Typische Leistungen, die nicht immer Bestandteil des klassischen Supports sind:

• kontinuierliche Prozessoptimierung,
• regelmäßiges Release Management,
• strategisches Backlog Management,
• umfangreiche Entwicklungsprojekte,
• grundlegende Prozess-Redesigns,
• vollständiger SAP-Basis-Betrieb,
• Infrastruktur- und Cloud-Management,
• proaktives Kapazitätsmanagement,
• umfassendes Security Monitoring,
• Verantwortung für Systemverfügbarkeit.

Werden solche Aufgaben dauerhaft benötigt, sollte geprüft werden, ob SAP Application Management Services, SAP Managed Services oder eine Kombination der Modelle besser geeignet ist.

Wann ist klassischer SAP Support die passende Wahl?

SAP Support eignet sich besonders für Unternehmen, die:

• ein bestehendes internes SAP-Team gezielt entlasten möchten,
• zusätzliche L2- oder L3-Kompetenzen benötigen,
• klar definierte Ticketarten auslagern wollen,
• schwankenden Support-Bedarf abdecken müssen,
• Unterstützung für einzelne SAP-Module suchen,
• geregelte Eskalationswege und Reaktionszeiten benötigen.

Benötigt ein Unternehmen dagegen neben der Ticketbearbeitung auch regelmäßige Changes, Release-Begleitung und kontinuierliche Optimierung, reicht klassischer SAP Support häufig nicht aus. In diesem Fall ist SAP AMS meist das umfassendere Service-Modell.

Finden Sie heraus, welches Service-Modell am besten zu Ihrer SAP-Landschaft passt.
Service-Modell prüfen

Welche Leistungen umfassen SAP Application Management Services?

SAP Application Management Services, kurz SAP AMS, umfassen die langfristige Betreuung, Stabilisierung und Weiterentwicklung definierter SAP-Anwendungen. Im Unterschied zum klassischen SAP Support beschränkt sich AMS nicht auf die Bearbeitung einzelner Tickets. Das AMS-Team übernimmt zusätzlich kontinuierliche Aufgaben wie Problem Management, Changes, Release-Begleitung, Backlog Management und Anwendungsoptimierung.

Der genaue Umfang wird in einem Servicekatalog festgelegt. Dieser definiert, welche Systeme, Module, Prozesse und Leistungen enthalten sind und welche Aufgaben beim internen IT-Team verbleiben.

Incident, Problem und Request Management

Die Bearbeitung von Incidents bleibt auch bei SAP AMS ein zentraler Bestandteil.

Das AMS-Team unterstützt beispielsweise bei:

• funktionalen und technischen Störungen,
• Fehlern in Geschäftsprozessen,
• Problemen mit Stammdaten und Customizing,
• Berechtigungsfragen,
• Schnittstellenfehlern,
• Problemen in kundenspezifischen Entwicklungen,
• Störungen in SAP-Fiori-Anwendungen,
• wiederkehrenden Fehlermeldungen.

Der Unterschied zum klassischen Support liegt vor allem darin, dass AMS nicht nur einzelne Incidents löst. Wiederkehrende Störungen werden im Rahmen des Problem Managements systematisch untersucht.

Dabei analysiert das AMS-Team unter anderem:

• welche Incidents besonders häufig auftreten,
• ob mehrere Tickets dieselbe Ursache haben,
• welche Systeme oder Prozesse wiederholt betroffen sind,
• ob ein Workaround oder eine dauerhafte Lösung erforderlich ist,
• ob Dokumentation, Monitoring oder Anwenderschulungen verbessert werden sollten.

Ziel ist es, die Anzahl wiederkehrender Tickets dauerhaft zu reduzieren.

Auch Service Requests können Bestandteil von SAP AMS sein. Dazu gehören beispielsweise:

• kleinere Konfigurationsänderungen,
• Anpassungen von Reports,
• Änderungen an Workflows,
• Unterstützung bei Rollen und Berechtigungen,
• Pflege von Schnittstellen,
• kleinere technische Erweiterungen.

Welche Service Requests im vereinbarten Umfang enthalten sind, sollte im Servicekatalog eindeutig beschrieben werden.

Changes, Releases und kontinuierliche Optimierung

SAP AMS verbindet den laufenden Support mit der kontrollierten Weiterentwicklung der Anwendungen.

Typische Change-Leistungen sind:

• kleinere und mittlere Prozessanpassungen,
• Customizing-Änderungen,
• Erweiterungen bestehender Funktionen,
• Anpassungen kundenspezifischer Entwicklungen,
• Änderungen an Reports und Formularen,
• Optimierung von Schnittstellen,
• Anpassung von SAP-Fiori-Anwendungen,
• technische Verbesserungen nach einer Root Cause Analysis.

Changes sollten nicht direkt im Produktivsystem umgesetzt werden. Ein strukturierter Prozess umfasst normalerweise:

1. Aufnahme und Bewertung der Anforderung,
2. fachliche und technische Analyse,
3. Aufwandsschätzung und Priorisierung,
4. Umsetzung in einer Entwicklungsumgebung,
5. technische und funktionale Tests,
6. fachliche Freigabe,
7. kontrollierten Transport,
8. Dokumentation und Nachverfolgung.

Auch die Begleitung von Releases, Updates und Upgrades kann zum AMS-Umfang gehören.

Das AMS-Team kann dabei unterstützen bei:

• Bewertung geplanter Änderungen,
• Prüfung möglicher Auswirkungen,
• Analyse kundenspezifischer Entwicklungen,
• Vorbereitung von Testfällen,
• Durchführung von Regressionstests,
• Fehlerbehebung nach dem Release,
• Hypercare nach der Produktivsetzung,
• Aktualisierung technischer Dokumentation.

Ein weiterer Bestandteil ist die kontinuierliche Optimierung. Dabei werden nicht nur akute Probleme betrachtet, sondern auch Möglichkeiten zur Verbesserung von Stabilität, Performance, Benutzerfreundlichkeit und Prozessqualität.

Backlog Management, Monitoring und Wissenstransfer

Viele Unternehmen verfügen über einen wachsenden Backlog aus Incidents, Service Requests, Changes und technischen Verbesserungen.

Ein AMS-Team kann diesen Backlog strukturiert analysieren und priorisieren.

Typische Schritte sind:

• veraltete oder doppelte Einträge identifizieren,
• Tickets nach Geschäftswert und Risiko kategorisieren,
• Abhängigkeiten zwischen Anforderungen prüfen,
• Aufwand und benötigte Kompetenzen bewerten,
• kurzfristige Korrekturen von größeren Changes trennen,
• einen realistischen Bearbeitungsplan erstellen,
• Fortschritt regelmäßig berichten.

Dadurch wird verhindert, dass der Backlog ausschließlich nach Alter oder nach der Lautstärke einzelner Stakeholder bearbeitet wird.

Abhängig vom Service-Modell kann SAP AMS auch anwendungsbezogenes Monitoring umfassen. Dazu gehören beispielsweise:

• Überwachung kritischer Geschäftsprozesse,
• Prüfung von Schnittstellen und Datenflüssen,
• Überwachung von Hintergrundjobs,
• Kontrolle wiederkehrender Fehler,
• Identifikation von Performance-Problemen,
• Erkennung wachsender Ticketmuster.

Monitoring hilft dabei, Probleme zu erkennen, bevor sie zu kritischen Incidents führen.

Ebenso wichtig ist der Wissenstransfer. Lösungen, Prozesswissen und technische Entscheidungen sollten nicht ausschließlich bei einzelnen Experten verbleiben.

Zu einem strukturierten Wissenstransfer gehören:

• aktuelle System- und Prozessdokumentation,
• Pflege einer Knowledge Base,
• dokumentierte Lösungen und Workarounds,
• Übergabe neuer Entwicklungen an Support-Teams,
• Schulungen für Key User und interne IT,
• regelmäßiger Austausch zwischen L1, L2 und L3,
• dokumentierte Rollen und Eskalationswege.

So bleibt Wissen auch bei personellen Veränderungen oder einem späteren Anbieterwechsel verfügbar.

Wo liegen die Grenzen von SAP AMS?

SAP AMS umfasst normalerweise nicht automatisch den vollständigen technischen Betrieb der SAP-Landschaft.

Leistungen wie folgende können zwar ergänzt werden, gehören aber häufig eher zu SAP Managed Services:

• vollständiger SAP-Basis-Betrieb,
• Infrastruktur- und Cloud-Management,
• Verantwortung für Systemverfügbarkeit,
• Backup und Recovery,
• Betriebssystem- und Datenbankadministration,
• umfassendes Security Monitoring,
• Kapazitätsmanagement,
• technische Rund-um-die-Uhr-Überwachung.

Auch größere Transformationsprojekte gehören normalerweise nicht zum regulären AMS-Umfang.

Dazu zählen beispielsweise:

• vollständige SAP-S/4HANA-Transformationen,
• Einführung neuer SAP-Lösungen,
• grundlegende Prozessneugestaltung,
• umfangreiche Datenmigrationen,
• globale Rollouts,
• größere Architekturänderungen.

Solche Vorhaben sollten als eigenständige Projekte mit klar definiertem Scope, Budget und Governance umgesetzt werden.

SAP AMS ist besonders geeignet, wenn ein Unternehmen nicht nur auf Incidents reagieren, sondern seine SAP-Anwendungen langfristig stabilisieren und kontinuierlich verbessern möchte. Wird zusätzlich die Verantwortung für Infrastruktur, technischen Betrieb und Verfügbarkeit übertragen, sollte das Modell um SAP Managed Services ergänzt werden.

Stabilisieren und optimieren Sie Ihre SAP-Anwendungen mit einem langfristigen AMS-Modell.
SAP AMS anfragen 

Welche Leistungen umfassen SAP Managed Services?

SAP Managed Services umfassen die laufende Verantwortung für klar definierte technische oder operative SAP-Services. Der externe Anbieter bearbeitet dabei nicht nur einzelne Aufgaben, sondern stellt vereinbarte Service-Ergebnisse sicher – beispielsweise Systemverfügbarkeit, stabilen Betrieb, Monitoring, Backup oder technische Wartung.

Der Leistungsumfang wird in einem Servicekatalog und in Service Level Agreements festgelegt. Darin sollte eindeutig geregelt sein, welche Systeme, Betriebsbereiche und Verantwortlichkeiten der Managed-Services-Anbieter übernimmt.

SAP Basis, Systembetrieb und technische Administration

Der SAP-Basis-Betrieb bildet häufig einen zentralen Bestandteil von SAP Managed Services.

Typische Leistungen sind:

• Administration von SAP-Systemen,
• Systemstarts und kontrollierte Neustarts,
• Benutzer- und Mandantenverwaltung,
• Überwachung technischer Systemkomponenten,
• Verwaltung von Hintergrundjobs,
• Drucker- und Spool-Management,
• Transportmanagement,
• Pflege technischer Verbindungen,
• SAP-HANA-Administration,
• Unterstützung bei Patches und Kernel-Updates,
• technische Begleitung von Releases und Upgrades.

Der Managed-Services-Anbieter sorgt dafür, dass definierte Betriebsaufgaben regelmäßig, dokumentiert und nach vereinbarten Standards durchgeführt werden.

Dabei arbeitet das technische Team häufig eng mit dem SAP Support oder AMS-Team zusammen. Meldet ein Anwender beispielsweise eine langsame Transaktion, kann die funktionale Analyse durch AMS erfolgen, während Managed Services Datenbank, Systemressourcen und technische Performance prüfen.

Monitoring und Verfügbarkeitsmanagement

Ein wesentlicher Unterschied zu klassischem SAP Support besteht im proaktiven Monitoring.

Während SAP Support meist auf ein bereits gemeldetes Problem reagiert, überwacht ein Managed-Services-Team kontinuierlich den technischen Zustand der vereinbarten Systeme.

Monitoring kann unter anderem umfassen:

• Systemverfügbarkeit,
• Server- und Datenbankauslastung,
• Speichernutzung,
• Hintergrundjobs,
• Schnittstellen,
• Dumps und Systemprotokolle,
• technische Warteschlangen,
• Zertifikate und Verbindungen,
• Backup-Status,
• Antwort- und Verarbeitungszeiten.

Werden definierte Schwellenwerte überschritten, kann das Team automatisch informiert werden und Maßnahmen einleiten, bevor Anwender oder Geschäftsprozesse erheblich beeinträchtigt werden.

Das Verfügbarkeitsmanagement umfasst zusätzlich:

• Messung der tatsächlichen Systemverfügbarkeit,
• Analyse technischer Ausfälle,
• Planung von Wartungsfenstern,
• Koordination geplanter Downtimes,
• Reporting über Verfügbarkeitsziele,
• Maßnahmen zur Reduzierung ungeplanter Ausfälle.

Welche Verfügbarkeit zugesichert werden kann, hängt von der gesamten Architektur ab. Auch Cloud-Anbieter, Netzwerkdienste, Rechenzentren und Drittanbieter können Einfluss auf die erreichbaren Service Levels haben.

Infrastruktur, Cloud und Kapazitätsmanagement

SAP Managed Services können sich nicht nur auf die SAP-Anwendungsschicht, sondern auch auf die zugrunde liegende Infrastruktur erstrecken.

Je nach Betriebsmodell gehören dazu:

• Server und virtuelle Maschinen,
• Betriebssysteme,
• Datenbanken,
• Storage,
• Netzwerkverbindungen,
• Cloud-Infrastruktur,
• Hochverfügbarkeit,
• Disaster-Recovery-Umgebungen,
• technische Entwicklungs-, Test- und Produktivsysteme.

Der Anbieter kann Infrastruktur selbst betreiben oder die technische Koordination mit einem Hyperscaler, Hosting-Partner oder internen Infrastrukturteam übernehmen.

Zum Kapazitätsmanagement gehören beispielsweise:

• Überwachung von CPU, Arbeitsspeicher und Storage,
• Analyse des Systemwachstums,
• Erkennung von Kapazitätsengpässen,
• Planung zusätzlicher Ressourcen,
• Bewertung saisonaler Lastspitzen,
• Vorbereitung auf Releases oder neue Benutzergruppen.

Dadurch sollen Performance-Probleme und technische Engpässe möglichst frühzeitig erkannt werden.

Backup, Recovery und technische Kontinuität

Managed Services können Verantwortung für die Sicherung und Wiederherstellbarkeit von SAP-Systemen übernehmen.

Typische Leistungen sind:

• Planung und Überwachung von Backups,
• Kontrolle erfolgreicher Sicherungsläufe,
• Definition von Aufbewahrungszeiträumen,
• regelmäßige Wiederherstellungstests,
• Dokumentation von Recovery-Prozessen,
• Unterstützung bei Datenbank- oder Systemwiederherstellungen,
• Abstimmung von Recovery Point Objectives,
• Abstimmung von Recovery Time Objectives.

Ein erfolgreich gemeldetes Backup allein garantiert noch keine sichere Wiederherstellung. Deshalb sollten Unternehmen regelmäßig prüfen, ob Daten und Systeme innerhalb der vereinbarten Ziele tatsächlich wiederhergestellt werden können.

Für geschäftskritische Systeme können zusätzlich Disaster-Recovery- und Business-Continuity-Szenarien definiert werden.

Security, Patches und technische Wartung

Auch technische Sicherheits- und Wartungsaufgaben können Bestandteil von SAP Managed Services sein.

Dazu gehören beispielsweise:

• Überwachung sicherheitsrelevanter Systemmeldungen,
• Bewertung technischer Security-Hinweise,
• Planung und Installation von Patches,
• Zertifikatsmanagement,
• Kontrolle technischer Benutzer,
• Überwachung kritischer Schnittstellen,
• Unterstützung bei Schwachstellenanalysen,
• Dokumentation technischer Sicherheitsmaßnahmen.

Die Verantwortung für Security sollte jedoch genau abgegrenzt werden. Der Managed-Services-Anbieter kann technische Maßnahmen umsetzen, während Governance, Risikobewertung, Compliance und Freigaben häufig beim Unternehmen verbleiben.

Incident Management im technischen Betrieb

Auch Managed Services bearbeiten Incidents. Der Fokus liegt jedoch stärker auf technischen Betriebsstörungen als auf einzelnen Anwender- oder Prozessfragen.

Typische Beispiele sind:

• ein SAP-System ist nicht erreichbar,
• eine Datenbank reagiert nicht,
• Hintergrundjobs brechen systematisch ab,
• eine technische Schnittstelle fällt aus,
• Storage-Kapazitäten werden knapp,
• ein Zertifikat läuft ab,
• ein Backup wurde nicht erfolgreich durchgeführt,
• die Systemperformance verschlechtert sich deutlich.

Bei einem geschäftskritischen Incident koordiniert das Managed-Services-Team die technische Wiederherstellung und bindet bei Bedarf SAP, Cloud-Anbieter, Infrastrukturpartner oder das AMS-Team ein.

Deshalb müssen Eskalationswege zwischen Support, AMS, Managed Services und weiteren Anbietern eindeutig definiert sein.

Wie werden SAP Managed Services gemessen?

Die Qualität von Managed Services wird vor allem anhand technischer und betrieblicher Kennzahlen bewertet.

Dazu können gehören:

• Systemverfügbarkeit,
• Anzahl ungeplanter Ausfälle,
• Reaktionszeit bei technischen Incidents,
• Zeit bis zur Wiederherstellung,
• erfolgreiche Backup-Quote,
• Patch-Compliance,
• Performance und Antwortzeiten,
• Anzahl kritischer Monitoring-Alarme,
• Kapazitätsauslastung,
• Einhaltung geplanter Wartungsfenster,
• SLA-Erfüllung.

Zusätzlich sollten regelmäßige Service Reviews stattfinden. Dabei werden Incidents, Risiken, Kapazitäten, technische Schulden und geplante Verbesserungsmaßnahmen besprochen.

Wo liegen die Grenzen von SAP Managed Services?

SAP Managed Services konzentrieren sich hauptsächlich auf den technischen Betrieb und die Stabilität definierter Services. Sie umfassen nicht automatisch die funktionale Weiterentwicklung von Geschäftsprozessen.

Folgende Aufgaben gehören häufig eher zu SAP Support, AMS oder separaten Projekten:

• Anwenderschulungen,
• funktionale Prozessberatung,
• umfangreiche Customizing-Änderungen,
• Entwicklung neuer Geschäftsprozesse,
• größere ABAP- oder Fiori-Entwicklungen,
• strategisches Anwendungs-Backlog,
• Einführung neuer SAP-Lösungen,
• SAP-S/4HANA-Transformationen,
• globale Rollouts und Datenmigrationen.

Managed Services sind besonders geeignet, wenn ein Unternehmen Verantwortung für SAP Basis, Infrastruktur, Monitoring und technische Verfügbarkeit an einen spezialisierten Anbieter übertragen möchte.

Soll der Anbieter zusätzlich Anwendungen funktional betreuen, Changes umsetzen und Prozesse kontinuierlich optimieren, empfiehlt sich eine Kombination aus SAP Managed Services und SAP Application Management Services.

Übertragen Sie Monitoring, SAP Basis und technische Betriebsaufgaben an erfahrene Spezialisten.
Managed Services prüfen

Wo überschneiden sich SAP Support, AMS und Managed Services?

SAP Support, Application Management Services und Managed Services können dieselben SAP-Systeme betreffen, verfolgen aber unterschiedliche Ziele. Überschneidungen entstehen vor allem bei Incidents, Monitoring, Releases, Schnittstellen und technischen Änderungen.

Entscheidend ist deshalb nicht, Überschneidungen vollständig zu vermeiden. Unternehmen müssen vielmehr eindeutig festlegen, wer eine Störung annimmt, wer sie analysiert, wer Änderungen umsetzt und wer die Gesamtverantwortung für den Service trägt.

Typische Überschneidungen zwischen den Service-Modellen

Die Tabelle zeigt, dass eine Aufgabe von mehreren Teams berührt werden kann. Die Verantwortung sollte dennoch für jeden Prozessschritt eindeutig sein.

Wer ist bei einem SAP Incident verantwortlich?

Die Verantwortung hängt von der Ursache des Incidents ab.

Ein Beispiel: Anwender können in SAP keine Bestellungen mehr anlegen.

Der SAP Support übernimmt zunächst:

• Aufnahme und Priorisierung des Tickets,
• Erfassung der betroffenen Benutzer und Prozesse,
• Prüfung bekannter Lösungen,
• Kommunikation mit dem Fachbereich.

Das AMS-Team prüft anschließend:

• Geschäftsprozess und Customizing,
• Stammdaten,
• Berechtigungen,
• kundenspezifische Erweiterungen,
• funktionale Auswirkungen eines kürzlich eingespielten Changes.

Das Managed-Services-Team analysiert parallel:

• Systemverfügbarkeit,
• Datenbank und technische Performance,
• Hintergrundjobs,
• Infrastruktur,
• technische Verbindungen und Systemprotokolle.

Liegt die Ursache in einer fehlerhaften Konfiguration, übernimmt normalerweise AMS die Lösung. Ist ein technischer Systemausfall verantwortlich, liegt die Wiederherstellung eher bei Managed Services. Der SAP Support koordiniert weiterhin das Ticket und die Kommunikation mit den Anwendern.

Wie lassen sich doppelte Zuständigkeiten vermeiden?

Die Abgrenzung sollte nicht nur auf Ebene der Service-Namen erfolgen. Sie muss für konkrete Systeme, Aufgaben und Prozesse dokumentiert werden.

Dazu sind insbesondere folgende Elemente erforderlich:

• ein gemeinsamer Servicekatalog,
• eine Liste aller unterstützten Systeme und Anwendungen,
• klar definierte Rollen pro Ticket- und Incident-Typ,
• eine Zuständigkeitsmatrix,
• dokumentierte Übergaben zwischen den Teams,
• gemeinsame Prioritäts- und Eskalationsregeln,
• ein zentrales Ticket-System,
• ein verantwortlicher Service oder Incident Manager,
• abgestimmte SLAs und Betriebszeiten,
• gemeinsame Service Reviews.

Eine Zuständigkeitsmatrix kann beispielsweise festlegen, welches Team für Aufnahme, Analyse, Lösung, Freigabe und Kommunikation verantwortlich ist.

Beispiel einer einfachen Verantwortungsmatrix

Die genaue Aufteilung kann je nach Unternehmen abweichen. Wichtig ist, dass für jeden Schritt genau ein Team die Hauptverantwortung trägt.

Ein Anbieter oder mehrere Dienstleister?

SAP Support, AMS und Managed Services können von einem einzigen Anbieter oder von mehreren spezialisierten Dienstleistern übernommen werden.

Ein gemeinsamer Anbieter kann Vorteile bieten:

• weniger Schnittstellen,
• einheitliche Prozesse,
• gemeinsames Reporting,
• schnellere Eskalationen,
• leichterer Wissenstransfer.

Mehrere Anbieter können sinnvoll sein, wenn:

• besondere Spezialkompetenzen benötigt werden,
• Infrastruktur und Anwendungen getrennt betrieben werden,
• unterschiedliche regionale Anforderungen bestehen,
• das Unternehmen Abhängigkeiten von einem einzelnen Anbieter reduzieren möchte.

Bei mehreren Dienstleistern wird ein übergreifendes Service Integration and Management besonders wichtig. Das Unternehmen muss festlegen, wer die Zusammenarbeit koordiniert und bei serviceübergreifenden Incidents die Führung übernimmt.

Wer sollte die Gesamtverantwortung behalten?

Auch bei umfassender Auslagerung sollte das Unternehmen die Governance über seine SAP-Landschaft behalten.

Intern verantwortet werden sollten insbesondere:

• geschäftliche Prioritäten,
• Risiko- und Compliance-Entscheidungen,
• Freigabe kritischer Änderungen,
• Auswahl und Steuerung der Anbieter,
• Kontrolle von SLAs und Servicequalität,
• strategische Architekturentscheidungen.

Externe Dienstleister können Anwendungen und technische Services betreiben. Die Verantwortung für Geschäftsziele, Risiken und die langfristige SAP-Strategie bleibt jedoch beim Unternehmen.

Welches SAP Service-Modell passt zu welchem Unternehmen?

Das passende Service-Modell hängt davon ab, welche Aufgaben ausgelagert werden sollen und wie viel Verantwortung ein externer Anbieter übernehmen soll.

Klassischer SAP Support reicht häufig aus, wenn ein Unternehmen hauptsächlich Unterstützung bei Incidents, Anwenderfragen und klar definierten Service Requests benötigt. SAP AMS eignet sich besser, wenn Anwendungen zusätzlich kontinuierlich optimiert und weiterentwickelt werden sollen. SAP Managed Services sind sinnvoll, wenn ein Dienstleister auch Verantwortung für den technischen Betrieb, das Monitoring und die Verfügbarkeit übernehmen soll.

Entscheidungsmatrix: SAP Support, AMS oder Managed Services?

Wann reicht klassischer SAP Support aus?

SAP Support ist häufig die passende Wahl, wenn das Unternehmen grundsätzlich über ein funktionierendes internes SAP- und IT-Team verfügt, aber zusätzliche Kompetenzen oder Kapazitäten benötigt.

Typische Situationen sind:

• Das Ticketvolumen schwankt stark.
• Einzelne SAP-Module können intern nicht vollständig abgedeckt werden.
• L2- oder L3-Spezialisten werden nur gelegentlich benötigt.
• Anwenderanfragen sollen über einen strukturierten Service Desk bearbeitet werden.
• Es werden definierte Reaktionszeiten und Eskalationswege benötigt.
• Kritische Incidents sollen durch zusätzliche Experten unterstützt werden.
• Einzelne Support-Level oder Ticketarten sollen ausgelagert werden.

Klassischer SAP Support ist besonders geeignet, wenn der Leistungsumfang klar abgegrenzt werden kann. Das Unternehmen behält dabei normalerweise die Verantwortung für Anwendungsstrategie, Releases, größere Changes und den technischen Betrieb.

SAP Support allein reicht häufig nicht aus, wenn das externe Team Anwendungen regelmäßig weiterentwickeln oder technische Betriebsverantwortung übernehmen soll.

Wann ist SAP AMS die bessere Wahl?

SAP Application Management Services eignen sich für Unternehmen, die ihre Anwendungen nicht nur stabil betreiben, sondern kontinuierlich verbessern möchten.

SAP AMS ist besonders relevant, wenn:

• viele wiederkehrende Incidents auftreten,
• das Change- und Request-Backlog wächst,
• regelmäßige Releases begleitet werden müssen,
• Anwendungen technisch oder funktional veraltet sind,
• interne Teams wenig Zeit für Optimierungsaufgaben haben,
• Prozess- und Systemwissen langfristig gesichert werden soll,
• mehrere SAP-Module und Integrationen koordiniert betreut werden,
• kontinuierliche Service Reviews und Verbesserungsmaßnahmen gewünscht sind.

Ein AMS-Team arbeitet langfristiger und stärker proaktiv als ein klassisches Support-Team. Es analysiert nicht nur einzelne Tickets, sondern betrachtet auch Muster, technische Schulden, Prozessqualität und zukünftige Anforderungen.

SAP AMS ist deshalb häufig die passende Wahl für Unternehmen mit einer etablierten SAP-Landschaft, die dauerhaft betreut und schrittweise weiterentwickelt werden soll.

Wann eignen sich SAP Managed Services?

SAP Managed Services sind sinnvoll, wenn ein Unternehmen technische Betriebsaufgaben und definierte Service-Verantwortung an einen externen Anbieter übertragen möchte.

Typische Gründe sind:

• fehlende interne SAP-Basis-Kompetenzen,
• hohe Anforderungen an Systemverfügbarkeit,
• internationale oder rund um die Uhr laufende Prozesse,
• komplexe Infrastruktur- und Cloud-Landschaften,
• Bedarf an proaktivem Monitoring,
• Anforderungen an Backup, Recovery und technische Kontinuität,
• zunehmender Aufwand für Patches und Wartung,
• Bedarf an transparentem Betriebs- und Kapazitätsreporting.

Managed Services sind besonders relevant, wenn technische Stabilität nicht nur durch einzelne Aufgaben, sondern durch messbare Service-Ergebnisse abgesichert werden soll.

Das Unternehmen kann beispielsweise vereinbaren, dass der Dienstleister Verantwortung für Monitoring, SAP Basis, Systemverfügbarkeit und Backup übernimmt. Governance, Risikobewertung und strategische Architekturentscheidungen sollten jedoch weiterhin intern gesteuert werden.

Wann ist eine Kombination der Modelle sinnvoll?

Viele Unternehmen benötigen nicht ausschließlich SAP Support, AMS oder Managed Services. Sie kombinieren die Modelle entsprechend ihrer Landschaft und internen Organisation.

Ein mögliches Modell ist:

• SAP Support für Anwenderanfragen, Incidents und Service Requests,
• SAP AMS für Problem Management, Changes, Releases und Anwendungsoptimierung,
• SAP Managed Services für SAP Basis, Infrastruktur, Monitoring und technische Verfügbarkeit.

Eine Kombination ist besonders sinnvoll, wenn:

• mehrere SAP-Systeme und Geschäftsbereiche unterstützt werden,
• funktionale und technische Aufgaben eng miteinander verbunden sind,
• das interne Team strategische Verantwortung behalten soll,
• unterschiedliche Kompetenzen flexibel benötigt werden,
• Anwendungen und Infrastruktur getrennte Verantwortlichkeiten haben.

Entscheidend ist, dass alle Teams mit einem gemeinsamen Ticket-System, abgestimmten SLAs und eindeutigen Eskalationswegen arbeiten.

Fünf Fragen zur Auswahl des passenden Modells

Unternehmen sollten vor der Entscheidung folgende Fragen beantworten:

1. Benötigen wir hauptsächlich Hilfe bei Tickets oder eine langfristige Anwendungsbetreuung?
2. Soll der Anbieter auch Changes, Releases und Optimierungen übernehmen?
3. Wer verantwortet SAP Basis, Infrastruktur, Monitoring und Verfügbarkeit?
4. Welche Kompetenzen und Verantwortlichkeiten sollen intern bleiben?
5. Welche Ergebnisse sollen durch SLAs und KPIs messbar gemacht werden?

Die Antworten zeigen häufig bereits, welches Modell benötigt wird:

• Tickets und konkrete Probleme: SAP Support
• Anwendungen betreuen und verbessern: SAP AMS
• Technischen Betrieb verantworten: SAP Managed Services
• Alle Bereiche abdecken: kombiniertes Service-Modell

Die Entscheidung sollte nicht anhand des Namens eines Angebots getroffen werden. Maßgeblich sind der tatsächliche Servicekatalog, die Verantwortungsverteilung und die vereinbarten Service-Ergebnisse.

Können SAP Support, AMS und Managed Services kombiniert werden?

Ja. SAP Support, Application Management Services und Managed Services können innerhalb eines gemeinsamen Betriebsmodells kombiniert werden.

In vielen Unternehmen ist diese Kombination sinnvoller als die Auswahl eines einzigen Modells. SAP Support übernimmt die Bearbeitung konkreter Anfragen und Incidents, SAP AMS betreut und verbessert die Anwendungen, und Managed Services sichern den technischen Betrieb der zugrunde liegenden Systeme.

Voraussetzung ist eine klare Aufteilung der Verantwortlichkeiten. Ohne eindeutige Rollen können Tickets zwischen Teams weitergeleitet werden, Eskalationen verzögert erfolgen und Probleme an den Schnittstellen zwischen Anwendung und Infrastruktur ungelöst bleiben.

Beispiel eines hybriden SAP Service-Modells

Ein hybrides Modell kann folgendermaßen aufgebaut sein:

In diesem Modell arbeiten die Teams nicht isoliert voneinander. Ein Incident kann mehrere Bereiche gleichzeitig betreffen und erfordert dann eine koordinierte Analyse.

Praxisbeispiel: Eine SAP-Anwendung reagiert ungewöhnlich langsam

Mehrere Anwender melden, dass die Verarbeitung von Kundenaufträgen deutlich länger dauert als gewöhnlich.

Der SAP Support übernimmt zunächst:

• Aufnahme und Priorisierung der Tickets,
• Erfassung der betroffenen Anwender und Prozesse,
• Prüfung, ob das Problem reproduzierbar ist,
• Kommunikation mit den Fachbereichen.

Das AMS-Team analysiert anschließend:

• betroffene Geschäftsprozesse,
• kundenspezifische Entwicklungen,
• kürzlich umgesetzte Changes,
• Schnittstellen und Datenvolumen,
• funktionale Ursachen.

Das Managed-Services-Team prüft parallel:

• Systemauslastung,
• Datenbank-Performance,
• Hintergrundjobs,
• Speicher- und Infrastrukturkapazität,
• technische Logs und Monitoring-Daten.

Zeigt die Analyse, dass ein kundenspezifischer Report ineffizient programmiert ist, übernimmt das AMS- oder L3-Team die Optimierung. Liegt die Ursache dagegen in fehlender Datenbankkapazität, ist das Managed-Services-Team für die technische Lösung verantwortlich.

Der SAP Support bleibt währenddessen die zentrale Schnittstelle für Ticketstatus und Anwenderkommunikation.

Welche Aufgaben sollten intern bleiben?

Auch wenn große Teile des SAP-Betriebs ausgelagert werden, sollte das Unternehmen bestimmte Verantwortlichkeiten intern behalten.

Dazu gehören insbesondere:

• Festlegung geschäftlicher Prioritäten,
• Benennung von Process und Application Ownern,
• Freigabe produktiver Änderungen,
• Verantwortung für Governance und Compliance,
• Bewertung von Geschäfts- und Sicherheitsrisiken,
• Kontrolle von Budgets und Servicequalität,
• strategische Architekturentscheidungen,
• Steuerung der Dienstleister,
• fachliche Abnahme von Changes,
• Entscheidung über größere Projekte und Transformationen.

Ein externer Anbieter kann technische und funktionale Aufgaben übernehmen. Er kann jedoch nicht allein entscheiden, welche Prozesse für das Unternehmen besonders kritisch sind oder welche Risiken akzeptiert werden dürfen.

Welche Rollen benötigt ein kombiniertes Service-Modell?

Ein gemeinsames Modell funktioniert nur, wenn zentrale Rollen klar definiert sind.

Service Manager

Der Service Manager überwacht die vereinbarten Leistungen, SLAs und KPIs. Er koordiniert Service Reviews und stellt sicher, dass Probleme nicht zwischen verschiedenen Teams verloren gehen.

Incident Manager

Bei kritischen Störungen koordiniert der Incident Manager alle beteiligten Support-, AMS- und Betriebsteams. Er steuert Eskalationen, Statuskommunikation und die Wiederherstellung des Service.

Application Owner

Der Application Owner verantwortet eine bestimmte SAP-Anwendung oder einen funktionalen Bereich. Er bewertet Anforderungen, priorisiert Changes und stimmt sich mit Fachbereichen und Dienstleistern ab.

Process Owner

Der Process Owner verantwortet den geschäftlichen Prozess. Er entscheidet, welche Auswirkungen ein Incident hat und ob eine vorgeschlagene Lösung den fachlichen Anforderungen entspricht.

Technical Service Owner

Der Technical Service Owner trägt Verantwortung für technische Betriebsbereiche wie SAP Basis, Infrastruktur, Datenbanken oder Cloud-Plattformen.

Jede zentrale Leistung sollte genau einer Rolle zugeordnet sein, die für Entscheidungen und Eskalationen verantwortlich ist.

Wie sollte die Zusammenarbeit gesteuert werden?

Für eine effektive Zusammenarbeit sollten alle Beteiligten möglichst mit gemeinsamen Prozessen und transparenten Informationen arbeiten.

Wichtige Voraussetzungen sind:

• ein zentrales Ticket-System,
• ein gemeinsamer Servicekatalog,
• einheitliche Prioritätsstufen,
• abgestimmte SLA-Regeln,
• dokumentierte Eskalationswege,
• gemeinsame Wartungs- und Release-Kalender,
• aktuelle System- und Prozessdokumentation,
• regelmäßige operative Meetings,
• monatliche oder quartalsweise Service Reviews,
• ein gemeinsamer Verbesserungsplan.

Besonders wichtig ist eine eindeutige Regelung für Tickets, deren Ursache zunächst nicht bekannt ist.

Der Anwender sollte nicht selbst entscheiden müssen, ob ein Problem zu SAP Support, AMS oder Managed Services gehört. Das Ticket sollte über einen zentralen Eingang erfasst und anschließend intern an das zuständige Team weitergeleitet werden.

Ein Anbieter oder mehrere Anbieter?

Alle drei Service-Bereiche können von einem integrierten Anbieter übernommen werden. Alternativ kann das Unternehmen mehrere spezialisierte Dienstleister einsetzen.

Vorteile eines integrierten Anbieters

• weniger organisatorische Schnittstellen,
• einheitliches Ticket- und SLA-Modell,
• schnellere Eskalationen,
• gemeinsames Reporting,
• einfacherer Wissenstransfer,
• zentrale Verantwortung für die Servicekoordination.

Vorteile mehrerer spezialisierter Anbieter

• Zugang zu besonderer Fachkompetenz,
• größere Unabhängigkeit von einem einzelnen Dienstleister,
• flexible Auswahl je Technologie oder Region,
• klare Trennung zwischen Anwendung und Infrastruktur.

Bei mehreren Anbietern muss jedoch festgelegt werden, wer die übergreifende Service Integration übernimmt. Andernfalls besteht das Risiko, dass Anbieter die Verantwortung für Incidents gegenseitig weiterreichen.

Wann ist ein kombiniertes Modell besonders sinnvoll?

Ein kombiniertes Modell eignet sich insbesondere für Unternehmen, die:

• eine komplexe SAP-Landschaft betreiben,
• mehrere SAP-Module und Integrationen nutzen,
• geschäftskritische Prozesse rund um die Uhr unterstützen müssen,
• Anwendungen regelmäßig weiterentwickeln,
• technische Betriebsverantwortung auslagern möchten,
• interne SAP-Kompetenzen gezielt ergänzen wollen,
• einen zentralen Ansprechpartner für alle Service-Bereiche benötigen.

Das Ziel sollte nicht sein, möglichst viele Aufgaben auszulagern. Entscheidend ist eine Aufteilung, die internes Prozesswissen, externe SAP-Kompetenz und einen stabilen technischen Betrieb sinnvoll miteinander verbindet.

Lassen Sie Ihre aktuelle Support-Struktur analysieren und das passende Modell definieren.
Service Assessment starten

Worauf sollten Unternehmen bei der Auswahl eines SAP Service Providers achten?

Bei der Auswahl eines Anbieters sollten Unternehmen nicht nur Preise, Tagessätze oder die Anzahl verfügbarer SAP-Berater vergleichen. Entscheidend ist, ob der Dienstleister die benötigte Verantwortung übernehmen, die vorhandene SAP-Landschaft verstehen und seine Leistungen transparent messen kann.

Besonders wichtig sind ein klarer Servicekatalog, passende SAP-Kompetenzen, realistische SLAs und ein strukturierter Transition-Prozess.

Servicekatalog und klare Leistungsabgrenzung

Der Anbieter sollte konkret beschreiben, welche Leistungen zu SAP Support, AMS und Managed Services gehören.

Der Servicekatalog sollte mindestens festlegen:

• unterstützte SAP-Systeme und Module,
• enthaltene Support-Level,
• Servicezeiten und Bereitschaftsmodelle,
• abgedeckte Ticketarten,
• enthaltene Changes und Service Requests,
• Monitoring- und Betriebsleistungen,
• Release- und Upgrade-Unterstützung,
• Verantwortlichkeiten für Integrationen,
• Zuständigkeit für SAP Basis und Infrastruktur,
• ausgeschlossene Leistungen.

Unklare Formulierungen wie „vollständige SAP-Betreuung“ oder „End-to-End-Support“ reichen nicht aus. Unternehmen sollten prüfen, welche konkreten Aufgaben, Systeme und Service-Ergebnisse tatsächlich vertraglich abgedeckt werden.

Fachliche und technische SAP-Kompetenzen

Der Anbieter muss nicht nur allgemeine SAP-Erfahrung nachweisen. Er benötigt Kompetenzen, die zur tatsächlichen Systemlandschaft des Unternehmens passen.

Je nach Bedarf können dazu gehören:

• SAP S/4HANA und SAP ECC,
• Finance und Controlling,
• Einkauf, Vertrieb und Logistik,
• SAP EWM und SAP TM,
• SAP Ariba und SAP SuccessFactors,
• SAP Fiori und SAPUI5,
• SAP BTP und Integrationen,
• ABAP und kundenspezifische Entwicklungen,
• SAP Basis und SAP HANA,
• Cloud- und Infrastrukturkompetenzen.

Unternehmen sollten außerdem prüfen, ob der Anbieter bei Bedarf zusätzliche Experten kurzfristig bereitstellen kann. Dies ist besonders bei kritischen Incidents, Releases und komplexen L3-Problemen wichtig.

SLAs, KPIs und Reporting

Service Level Agreements sollten messbare Ziele enthalten und zu den tatsächlichen Geschäftsrisiken passen.

Wichtige SLA-Bestandteile sind:

• Reaktionszeiten nach Priorität,
• Service- und Bereitschaftszeiten,
• Eskalationswege,
• Kommunikationsintervalle bei kritischen Incidents,
• Ziele für Wiederherstellung und Lösung,
• Zuständigkeiten des Kunden und Anbieters,
• Regeln für Abhängigkeiten von SAP oder Drittanbietern.

Die KPIs sollten zum jeweiligen Service-Modell passen:

Das Reporting sollte nicht nur zeigen, wie viele Tickets geschlossen wurden. Es sollte auch Risiken, wiederkehrende Ursachen, veraltete Anforderungen und konkrete Verbesserungsmaßnahmen sichtbar machen.

Transition und Wissenstransfer

Der Wechsel zu einem neuen Anbieter sollte als eigenes Übergabeprojekt geplant werden.

Eine strukturierte Transition umfasst typischerweise:

1. Analyse der bestehenden SAP-Landschaft,
2. Prüfung von Verträgen und Verantwortlichkeiten,
3. Bewertung offener Tickets und des Backlogs,
4. Übernahme vorhandener Dokumentation,
5. Wissenstransfer mit internen und externen Experten,
6. Shadow- und Reverse-Shadow-Phasen,
7. kontrollierte Übernahme der Services,
8. Stabilisierungsphase mit engerem Reporting.

Vor dem Start sollte geklärt werden, ob folgende Informationen verfügbar sind:

• System- und Integrationsübersichten,
• technische Dokumentation,
• Prozessbeschreibungen,
• kundenspezifische Entwicklungen,
• Zugänge und Berechtigungen,
• offene Incidents und Changes,
• bekannte Risiken und Workarounds,
• Ansprechpartner und Eskalationswege.

Fehlende Dokumentation sollte nicht ignoriert, sondern als konkretes Risiko in den Transition-Plan aufgenommen werden.

Governance und Zusammenarbeit

Ein geeigneter Anbieter sollte nicht nur Tickets bearbeiten, sondern transparent mit internen Teams, Fachbereichen und weiteren Dienstleistern zusammenarbeiten.

Wichtige Voraussetzungen sind:

• benannte Service Manager,
• klare Rollen und Verantwortlichkeiten,
• gemeinsame Prioritätsregeln,
• regelmäßige operative Meetings,
• strukturierte Service Reviews,
• transparente Eskalationen,
• dokumentierte Entscheidungen,
• ein kontinuierlicher Verbesserungsplan.

Bei mehreren Anbietern muss außerdem festgelegt werden, wer serviceübergreifende Incidents koordiniert.

Skalierbarkeit und Servicezeiten

Der Bedarf an SAP-Kompetenzen kann sich durch Releases, Rollouts, Akquisitionen oder saisonale Geschäftsperioden deutlich verändern.

Unternehmen sollten deshalb prüfen:

• Können zusätzliche Spezialisten bereitgestellt werden?
• Lassen sich neue Module oder Standorte aufnehmen?
• Sind erweiterte Servicezeiten oder 24/7-Bereitschaft möglich?
• Wie schnell kann der Leistungsumfang angepasst werden?
• Können Support, AMS und Managed Services später kombiniert werden?

Ein Modell sollte den aktuellen Bedarf abdecken, aber auch auf zukünftige Veränderungen vorbereitet sein.

Checkliste für die Anbieterauswahl

Vor einer Entscheidung sollten Unternehmen folgende Fragen beantworten:

• Ist der Leistungsumfang eindeutig dokumentiert?
• Verfügt der Anbieter über passende SAP-Kompetenzen?
• Sind Verantwortlichkeiten und Schnittstellen klar?
• Passen SLAs und Servicezeiten zu den Geschäftsprozessen?
• Werden Support, AMS und Managed Services sauber abgegrenzt?
• Gibt es einen strukturierten Transition-Plan?
• Wie werden Wissen und Dokumentation gesichert?
• Welche KPIs und Reports werden bereitgestellt?
• Wie werden kritische Incidents eskaliert?
• Kann der Service bei Bedarf skaliert werden?

Der beste Anbieter ist nicht automatisch der mit dem größten Team oder dem niedrigsten Preis. Entscheidend ist, ob Serviceumfang, Kompetenzen, Governance und Verantwortungsmodell zur SAP-Landschaft des Unternehmens passen.

Häufig gestellte Fragen zu SAP Support, AMS und Managed Services

Was ist der wichtigste Unterschied zwischen SAP Support und SAP AMS?

SAP Support konzentriert sich hauptsächlich auf konkrete Anwenderanfragen, Incidents und Service Requests. SAP AMS umfasst zusätzlich die langfristige Betreuung, kontinuierliche Optimierung und Weiterentwicklung definierter SAP-Anwendungen.

Die genaue Abgrenzung hängt vom vereinbarten Servicekatalog ab.

Ist SAP AMS dasselbe wie SAP Managed Services?

Nein. SAP AMS richtet sich vor allem auf Anwendungen, Geschäftsprozesse, Changes und Releases. SAP Managed Services konzentrieren sich häufiger auf technischen Betrieb, Monitoring, SAP Basis, Infrastruktur, Verfügbarkeit, Backup und Wartung.

Einige Anbieter verwenden die Begriffe jedoch unterschiedlich oder fassen beide Bereiche in einem gemeinsamen Angebot zusammen.

Umfasst SAP AMS auch L1-, L2- und L3-Support?

SAP AMS kann L1-, L2- und L3-Support enthalten, häufig liegt der Schwerpunkt jedoch auf L2 und L3. Dazu gehören funktionale Analysen, Problem Management, Changes, kundenspezifische Entwicklungen und die kontinuierliche Verbesserung von Anwendungen.

Der enthaltene Support-Umfang sollte im Servicekatalog eindeutig definiert werden.

Gehören SAP Basis und Infrastruktur zu SAP AMS?

SAP-Basis-Leistungen können Teil eines AMS-Vertrags sein, gehören aber häufig eher zu SAP Managed Services. Das gilt insbesondere für Systembetrieb, Infrastruktur, Datenbankadministration, Monitoring, Backup und technische Verfügbarkeit.

Unternehmen sollten genau prüfen, ob diese Leistungen enthalten oder separat beauftragt werden müssen.

Können SAP Support, AMS und Managed Services kombiniert werden?

Ja. Ein Unternehmen kann SAP Support für Anwenderanfragen und Incidents, AMS für Changes und Anwendungsoptimierung sowie Managed Services für SAP Basis und technischen Betrieb einsetzen.

Wichtig sind ein gemeinsames Ticket-System, klare Zuständigkeiten und abgestimmte Eskalationswege.

Können mehrere SAP-Dienstleister gleichzeitig eingesetzt werden?

Ja. Beispielsweise kann ein Anbieter Anwendungen betreuen, während ein anderer für Infrastruktur und technischen Betrieb verantwortlich ist.

Bei mehreren Dienstleistern muss jedoch festgelegt werden, wer serviceübergreifende Incidents koordiniert und die Gesamtverantwortung für Eskalationen übernimmt.

Welches Modell eignet sich für mittelständische Unternehmen?

Für viele mittelständische Unternehmen eignet sich ein hybrides Modell. Interne Key User und Process Owner behalten Geschäfts- und Prozesswissen, während ein externer Partner L2- und L3-Support, AMS oder technische Managed Services übernimmt.

Der passende Umfang hängt von der SAP-Landschaft, den internen Kompetenzen und der Kritikalität der Prozesse ab.

Wann reicht klassischer SAP Support nicht mehr aus?

Klassischer SAP Support reicht häufig nicht mehr aus, wenn neben der Ticketbearbeitung regelmäßige Changes, Release-Begleitung, Backlog Management und kontinuierliche Optimierung erforderlich sind.

In diesem Fall ist SAP AMS meist das umfassendere Modell. Soll zusätzlich der technische Betrieb ausgelagert werden, können Managed Services ergänzt werden.

Was kosten SAP Support, AMS und Managed Services?

Die Kosten hängen unter anderem von den unterstützten Systemen, SAP-Modulen, Servicezeiten, SLAs, Ticketvolumen und übernommenen Verantwortlichkeiten ab.

SAP Support kann über Stundenkontingente oder SLA-basierte Modelle abgerechnet werden. AMS wird häufig als langfristiger Service mit definierten Kapazitäten vereinbart. Managed Services orientieren sich stärker am technischen Umfang und an den vereinbarten Service-Ergebnissen.

Welches Modell bietet 24/7-Support?

Grundsätzlich können alle drei Modelle erweiterte Servicezeiten oder 24/7-Bereitschaft enthalten. Rund-um-die-Uhr-Abdeckung ist jedoch besonders häufig bei Managed Services und geschäftskritischen technischen Betriebsleistungen relevant.

Im SLA sollte festgelegt werden, welche Systeme, Prioritäten und Ticketarten tatsächlich rund um die Uhr abgedeckt sind.

Fazit: Entscheidend ist der Umfang der übernommenen Verantwortung

SAP Support, SAP Application Management Services und Managed Services unterscheiden sich weniger durch ihre Bezeichnung als durch den Umfang der Verantwortung, die ein externer Dienstleister übernimmt.

SAP Support ist die passende Wahl, wenn Unternehmen Unterstützung bei Anwenderanfragen, Incidents und klar definierten Service Requests benötigen.

SAP AMS eignet sich, wenn SAP-Anwendungen zusätzlich kontinuierlich betreut, optimiert und weiterentwickelt werden sollen.

SAP Managed Services sind relevant, wenn ein Anbieter Verantwortung für technische Betriebsbereiche wie SAP Basis, Monitoring, Infrastruktur, Backup oder Systemverfügbarkeit übernehmen soll.

Viele Unternehmen benötigen keine Entscheidung für nur eines dieser Modelle. Ein kombiniertes Service-Modell kann SAP Support, AMS und Managed Services miteinander verbinden:

• Support für Tickets und Anwender,
• AMS für Anwendungen, Changes und Optimierung,
• Managed Services für technischen Betrieb und Verfügbarkeit.

Damit dieses Modell funktioniert, müssen Servicekatalog, SLAs, Rollen und Eskalationswege eindeutig definiert sein. Für jede Aufgabe sollte klar sein, welches Team die Hauptverantwortung trägt und welche Entscheidungen beim Unternehmen verbleiben.

Die Auswahl sollte deshalb nicht allein anhand von Angebotstiteln oder Preisen erfolgen. Entscheidend sind:

• die vorhandene SAP-Landschaft,
• interne Kompetenzen und Kapazitäten,
• geschäftskritische Prozesse,
• benötigte Servicezeiten,
• gewünschte Verantwortungsübertragung,
• langfristige Ziele für Betrieb und Weiterentwicklung.

SAP Service-Modell passend zu Ihrer Landschaft entwickeln

LeverX unterstützt Unternehmen bei SAP Support, Application Management Services und technischen Managed Services. Gemeinsam analysieren wir Ihre Systeme, Prozesse, internen Kompetenzen und aktuellen Herausforderungen und entwickeln daraus ein klar abgegrenztes Service-Modell.

Finden Sie heraus, welche Kombination aus SAP Support, AMS und Managed Services zu Ihrer SAP-Landschaft passt.
Service-Modell besprechen