SAP AMS in der Schweiz: Application Management Services und SAP Support

Learn about how AI operates inside SAP S/4HANA, from clean core and data quality to embedded use cases, real-time decisions, and secure, transparent execution.

Mit dem Go-live eines SAP-Systems beginnt der laufende Betrieb. Geschäftsprozesse müssen stabil funktionieren, Anwender benötigen Unterstützung, Schnittstellen müssen überwacht und Änderungen kontrolliert umgesetzt werden. Gleichzeitig soll sich die interne IT nicht dauerhaft mit jedem Incident oder jedem technischen Detail beschäftigen müssen.

SAP Application Management Services (SAP AMS) unterstützen Unternehmen dabei, ihre SAP-Landschaft nach der Einführung strukturiert zu betreiben und weiterzuentwickeln. Je nach Serviceumfang können dazu unter anderem Incident- und Problem Management, funktionaler SAP Support, Monitoring, Changes, Release-Unterstützung und Optimierung gehören.

Für Schweizer Unternehmen stellt sich deshalb weniger die Frage, ob SAP Support notwendig ist, sondern wie der SAP-Betrieb organisiert werden soll: intern, vollständig extern oder als Hybridmodell. Entscheidend sind dabei unter anderem die Komplexität der SAP-Landschaft, verfügbare interne Ressourcen, gewünschte Servicezeiten, Integrationen und die strategische Bedeutung von SAP für das Unternehmen.

Dieser Leitfaden zeigt, worin sich SAP Support, SAP AMS und Managed Services unterscheiden, wann sich ein externes Betriebsmodell lohnt und welche Punkte Schweizer Unternehmen bei der Auswahl eines SAP-AMS-Partners berücksichtigen sollten.

Was sind SAP Application Management Services? 

SAP Application Management Services (SAP AMS) umfassen Dienstleistungen für den laufenden Betrieb, Support und die Weiterentwicklung von SAP-Anwendungen. Ziel ist es, die SAP-Landschaft nach der Einführung stabil zu betreiben und gleichzeitig notwendige Anpassungen und Verbesserungen strukturiert umzusetzen.

Je nach Betriebsmodell übernimmt ein SAP-AMS-Partner beispielsweise die Bearbeitung von Incidents und Service Requests, die Analyse wiederkehrender Fehler, funktionalen Support für SAP-Module, Unterstützung bei Changes und Releases sowie die Überwachung von Schnittstellen und relevanten Anwendungen.

Damit geht SAP AMS über die reine Fehlerbehebung hinaus. Ein professionell aufgebauter Service betrachtet den SAP-Betrieb als kontinuierlichen Prozess: Störungen werden behoben, Ursachen analysiert, Änderungen kontrolliert umgesetzt und Verbesserungspotenziale identifiziert.

Was gehört typischerweise zu SAP AMS?

Der konkrete Leistungsumfang wird vertraglich festgelegt und an die SAP-Landschaft des Unternehmens angepasst. Typische Bausteine sind:

• Incident Management: Aufnahme, Priorisierung und Bearbeitung von Störungen
• Problem Management: Analyse von wiederkehrenden Fehlern und Root Causes
• Request Management: Bearbeitung definierter Benutzer- und Serviceanfragen
• Functional Support: Unterstützung bei fachlichen Fragen und SAP-Prozessen
• Technical Support: Unterstützung bei technischen Komponenten, Schnittstellen und Systemabhängigkeiten
• Change Management: Planung und Umsetzung kontrollierter Änderungen
• Release Management: Unterstützung bei Releases, Updates und geplanten Wartungsaktivitäten
• Monitoring: Überwachung relevanter Systeme, Prozesse, Schnittstellen und Jobs
• Continuous Improvement: Identifikation und Umsetzung von Optimierungen

Bei modernen SAP-Landschaften können zusätzlich Lösungen wie SAP S/4HANA, SAP BTP, Integrationskomponenten oder SAP Cloud ALM Teil des Betriebsmodells sein. Welche Leistungen sinnvoll sind, hängt dabei von Architektur, Verantwortlichkeiten und den vereinbarten Service Levels ab.

Was SAP AMS nicht automatisch bedeutet

SAP AMS ist nicht gleichbedeutend mit einer vollständigen Auslagerung der IT. Unternehmen können einzelne SAP-Module oder Services extern betreiben lassen und gleichzeitig strategische Architektur, Governance, Prozessverantwortung oder bestimmte Fachthemen intern behalten.

Auch SAP-Support und SAP AMS sind nicht dasselbe. SAP bietet selbst Support- und Serviceleistungen für seine Produkte an. Ein AMS-Modell bezieht sich dagegen auf die konkrete SAP-Anwendungslandschaft eines Unternehmens und kann – abhängig vom Vertrag – deren laufenden Support, Betrieb und Weiterentwicklung abdecken.

Für Schweizer Unternehmen ist deshalb weniger die Bezeichnung des Services entscheidend als die genaue Definition der Verantwortlichkeiten: Wer bearbeitet welchen Incident? Wer verantwortet Changes? Welche Servicezeiten gelten? Wer übernimmt Eskalationen? Und welche Aufgaben bleiben bei der internen IT?

Ein klar definierter Serviceumfang bildet damit die Grundlage für ein belastbares SAP-Betriebsmodell.

SAP Support, AMS oder Managed Services: Wo liegt der Unterschied?

Die Begriffe SAP Support, SAP Application Management Services (SAP AMS) und SAP Managed Services werden im Markt teilweise synonym verwendet. Inhaltlich beschreiben sie jedoch unterschiedliche Leistungs- und Verantwortungsmodelle.

Für Unternehmen in der Schweiz ist diese Unterscheidung relevant, weil sich daraus unterschiedliche Anforderungen an Vertrag, Serviceorganisation, SLAs und interne Ressourcen ergeben.

SAP Support

SAP Support bezeichnet zunächst die Unterstützung bei Fragen, Störungen und Problemen rund um SAP-Systeme. Der Begriff kann dabei unterschiedliche Leistungen umfassen – vom Hersteller-Support bis zum Support durch einen externen SAP-Dienstleister.

Beim externen SAP Support steht häufig die Bearbeitung konkreter Anfragen und Störungen im Vordergrund. Der Umfang kann beispielsweise auf bestimmte SAP-Module, Geschäftsprozesse oder definierte Supportzeiten begrenzt sein.

Geeignet ist dieses Modell insbesondere dann, wenn ein Unternehmen seine SAP-Verantwortung weitgehend intern behält, aber bei Bedarf auf zusätzliche Expertise oder Kapazitäten zurückgreifen möchte.

SAP Application Management Services

SAP AMS geht in der Regel einen Schritt weiter. Neben der Bearbeitung von Incidents und Requests umfasst Application Management auch die strukturierte Betreuung und Weiterentwicklung der SAP-Anwendungen.

Typische Bestandteile sind Incident und Problem Management, funktionaler Support, Change Management, Monitoring, Release-Unterstützung und kontinuierliche Optimierung. Der konkrete Umfang wird über das vereinbarte Service-Modell definiert.

Geeignet ist SAP AMS insbesondere dann, wenn der laufende SAP-Betrieb dauerhaft unterstützt werden soll und ein Unternehmen definierte Verantwortlichkeiten, Prozesse und Service Levels mit einem externen Partner etablieren möchte.

SAP Managed Services

Bei Managed Services übernimmt ein externer Dienstleister einen noch umfassender definierten Teil der Betriebsverantwortung. Dabei können neben den Anwendungen auch technische Betriebsleistungen, Infrastruktur, Monitoring oder weitere IT-Services Bestandteil des Modells sein.

Die Grenzen zwischen AMS und Managed Services sind in der Praxis nicht immer eindeutig. Entscheidend ist deshalb nicht die Bezeichnung des Vertrags, sondern welche Leistungen, Systeme und Verantwortlichkeiten tatsächlich übertragen werden.

SAP Support, AMS und Managed Services im Vergleich

Die Tabelle zeigt zugleich: Es gibt kein grundsätzlich besseres Modell. Die passende Variante hängt davon ab, wie kritisch SAP für das Unternehmen ist, welche Kompetenzen intern vorhanden sind und wie viel Betriebsverantwortung extern übernommen werden soll.

Für viele Unternehmen kann ein hybrides Modell sinnvoll sein: Die interne IT behält Architektur, Governance und geschäftskritische Entscheidungen, während ein externer Partner den operativen Support und definierte Application-Management-Leistungen übernimmt.

Die konkrete Ausgestaltung sollte deshalb vor Vertragsabschluss anhand von Serviceumfang, Verantwortungsmatrix, SLAs, Eskalationswegen und Schnittstellen zur internen IT festgelegt werden.

Wie organisiert man den SAP-Betrieb nach dem Go-live?

Der Go-live ist nicht das Ende eines SAP-Projekts, sondern der Übergang in eine neue Betriebsphase. In den ersten Wochen steht die Stabilisierung im Vordergrund. Danach müssen Support, Changes, Releases und Weiterentwicklung in einen verlässlichen Regelbetrieb überführt werden.

Ein strukturiertes Betriebsmodell hilft dabei, Verantwortlichkeiten früh zu klären und zu vermeiden, dass Wissen aus dem Implementierungsprojekt verloren geht.

Hypercare: Stabilität nach dem Go-live

Direkt nach dem Go-live ist der Supportbedarf meist höher als im späteren Regelbetrieb. Anwenderfragen, Prozessabweichungen, technische Probleme und unerwartete Wechselwirkungen zwischen Systemen müssen schnell bewertet und behoben werden.

In dieser Hypercare-Phase arbeiten Projektteam, interne IT, Fachbereiche und gegebenenfalls der externe SAP-Partner eng zusammen. Wichtig sind insbesondere:

• klare Eskalationswege für kritische Incidents
• erhöhte Transparenz über offene Tickets und deren Priorität
• Monitoring kritischer Geschäftsprozesse und Schnittstellen
• schnelle Ursachenanalyse bei wiederkehrenden Fehlern
• dokumentierte Workarounds und Lösungen
• regelmässige Bewertung, wann ein Thema in den normalen Support überführt werden kann

Hypercare sollte dabei zeitlich und organisatorisch klar vom späteren Regelbetrieb abgegrenzt werden. Andernfalls besteht das Risiko, dass temporäre Projektstrukturen dauerhaft bestehen bleiben.

Übergabe in den Regelbetrieb

Nach der Stabilisierung werden Aufgaben und Verantwortlichkeiten in den definierten SAP-Betrieb überführt. Dazu gehört zunächst eine klare Service Transition.

Dabei sollten unter anderem folgende Fragen beantwortet sein:

1. Welche SAP-Systeme, Module und Schnittstellen sind Bestandteil des Services?
2. Welche Incidents bearbeitet der externe Partner und welche die interne IT?
3. Wer entscheidet über Changes und Releases?
4. Welche Servicezeiten und Eskalationsstufen gelten?
5. Welche Dokumentation und welches technische Wissen müssen verfügbar sein?
6. Wie werden externe Partner, SAP und andere IT-Dienstleister eingebunden?

Eine Verantwortungsmatrix, beispielsweise nach dem RACI-Prinzip, kann dabei helfen, Überschneidungen und Lücken zwischen interner IT, Fachbereichen und Dienstleistern zu vermeiden.

Vom Betrieb zur kontinuierlichen Verbesserung

Ein moderner SAP-Betrieb sollte nicht ausschliesslich darauf ausgerichtet sein, Störungen möglichst schnell zu beheben. Auch wiederkehrende Ursachen, ineffiziente Prozesse und technische Schulden sollten systematisch betrachtet werden.

Daraus entsteht ein kontinuierlicher Zyklus:

Go-live → Hypercare → Regelbetrieb / AMS → Continuous Improvement

Im Regelbetrieb können beispielsweise wiederkehrende Incidents analysiert, Schnittstellen optimiert, Prozesse angepasst oder neue SAP-Funktionen geprüft werden. Bei einer SAP-Landschaft mit S/4HANA, Cloud-Komponenten oder SAP BTP gewinnt diese kontinuierliche Weiterentwicklung zusätzlich an Bedeutung.

Der entscheidende Punkt ist die Trennung von Betriebsstabilität und Weiterentwicklung bei gleichzeitiger enger Abstimmung. Der Support muss das Tagesgeschäft zuverlässig absichern, während Verbesserungen kontrolliert geplant und umgesetzt werden.

Für Schweizer Unternehmen bedeutet ein belastbares SAP-Betriebsmodell deshalb nicht zwingend eine vollständige Auslagerung. Entscheidend ist, dass nach dem Go-live klar geregelt ist, wer den Betrieb verantwortet, wer Veränderungen steuert und wie aus Support-Erkenntnissen konkrete Verbesserungen entstehen.

Wann lohnt sich SAP AMS?

SAP AMS lohnt sich insbesondere dann, wenn der laufende Betrieb einer SAP-Landschaft mehr Ressourcen, Spezialwissen oder Verfügbarkeit erfordert, als ein Unternehmen dauerhaft intern bereitstellen möchte.

Dabei sollte nicht allein die Unternehmensgrösse ausschlaggebend sein. Entscheidend sind vielmehr die Komplexität und Kritikalität der SAP-Landschaft, das verfügbare Know-how, das Supportaufkommen und die gewünschte Betriebsorganisation.

Typische Anzeichen für den Bedarf an SAP AMS

Ein externes Application-Management-Modell kann sinnvoll sein, wenn mehrere der folgenden Faktoren zutreffen:

• Die SAP-Landschaft unterstützt geschäftskritische Prozesse und muss zuverlässig verfügbar sein.
• Intern fehlen ausreichend SAP-Spezialisten für bestimmte Module oder Technologien.
• Einzelne Experten tragen zu viel kritisches Systemwissen.
• Supportanfragen und Incidents binden regelmässig Kapazitäten der internen IT.
• SAP-Systeme, Schnittstellen und Eigenentwicklungen werden zunehmend komplex.
• Das Unternehmen benötigt definierte Servicezeiten und Eskalationsprozesse.
• Nach einer S/4HANA-Transformation soll der Betrieb professionell skaliert werden.
• Die SAP-Landschaft umfasst Cloud-, On-Premise- oder hybride Komponenten.
• Neben dem Tagesgeschäft besteht Bedarf an kontinuierlicher Optimierung.
• Die interne IT soll sich stärker auf Architektur, Governance und digitale Transformation konzentrieren.

Besonders relevant ist die Verfügbarkeit von Know-how. Ein Unternehmen kann über ein leistungsfähiges internes SAP-Team verfügen und trotzdem für bestimmte Themen einen externen Partner benötigen – beispielsweise für selten benötigte Spezialkenntnisse, zusätzliche Kapazitäten bei Releases oder die Abdeckung definierter Servicezeiten.

Wann SAP AMS möglicherweise nicht notwendig ist

Ein umfassendes AMS-Modell ist nicht automatisch die richtige Lösung für jedes Unternehmen.

Bei einer überschaubaren SAP-Landschaft mit wenigen Modulen, geringem Supportaufkommen und einem ausreichend grossen internen Team kann ein internes Betriebsmodell wirtschaftlich und organisatorisch sinnvoller sein.

Auch ein selektiver Support kann ausreichen. Dabei werden beispielsweise nur bestimmte SAP-Module, technische Spezialthemen oder Spitzen bei der Supportkapazität extern abgedeckt.

Die Entscheidung sollte daher nicht mit der Frage beginnen: „Sollen wir SAP auslagern?“ Sinnvoller ist zunächst:

„Welche Betriebsleistungen benötigen wir dauerhaft, welche Kompetenzen wollen wir intern behalten und wo schafft externe Unterstützung einen messbaren organisatorischen Nutzen?“

Ein einfaches Entscheidungsmodell

Für die Bewertung können Unternehmen sechs Dimensionen betrachten:

Diese Kriterien liefern keine automatische Entscheidung. Sie helfen jedoch dabei, die Diskussion von einer reinen Kostenfrage auf Risiko, Kapazität, Servicequalität und strategische Prioritäten zu erweitern.

Für viele Schweizer Unternehmen ist deshalb ein hybrides SAP-AMS-Modell interessant: Strategische Entscheidungen, Architektur und Business-Verantwortung bleiben intern, während ein externer Partner definierte Support-, Betriebs- und Weiterentwicklungsleistungen übernimmt.

SAP Support auslagern oder intern aufbauen?

Ob Unternehmen ihren SAP Support intern organisieren, vollständig extern vergeben oder als Hybridmodell aufbauen sollten, lässt sich nicht pauschal beantworten. Jede Variante hat unterschiedliche Auswirkungen auf Know-how, Verfügbarkeit, Kosten, Steuerung und Abhängigkeit von externen Partnern.

Entscheidend ist deshalb, welche Verantwortung im Unternehmen bleiben soll und für welche Leistungen externe Kapazitäten oder Spezialkenntnisse benötigt werden.

SAP Support intern organisieren

Beim internen Modell liegen Betrieb, Support und Weiterentwicklung weitgehend bei der eigenen IT-Organisation.

Vorteile:

• direkter Zugriff auf internes Prozess- und Unternehmenswissen
• kurze Kommunikationswege zu Fachbereichen
• hohe Kontrolle über Prioritäten und Änderungen
• Know-how bleibt im Unternehmen

Herausforderungen:

• Aufbau und Erhalt von SAP-Spezialwissen
• Abdeckung von Ferien, Krankheit und personellen Engpässen
• Abhängigkeit von einzelnen Experten
• zusätzlicher Aufwand für Serviceorganisation und Bereitschaften
• schwierige Skalierung bei stark schwankendem Supportbedarf

Das interne Modell kann besonders gut funktionieren, wenn die SAP-Landschaft überschaubar ist und ausreichend qualifizierte Ressourcen dauerhaft verfügbar sind.

SAP Support extern vergeben

Beim externen Modell übernimmt ein SAP-Partner definierte Support- und Application-Management-Leistungen. Umfang und Verantwortlichkeiten werden vertraglich festgelegt.

Vorteile:

• Zugriff auf zusätzliches SAP- und Branchenwissen
• besser skalierbare Supportkapazitäten
• definierte Prozesse für Incidents, Changes und Eskalationen
• Entlastung der internen IT bei operativen Aufgaben
• Möglichkeit, Spezialwissen gezielt einzukaufen

Herausforderungen:

• Abhängigkeit von Servicequalität und Verfügbarkeit des Partners
• zusätzlicher Aufwand für Steuerung und Governance
• Übergabe von Wissen und Verantwortlichkeiten
• Anforderungen an Datenschutz, Sicherheit und Zugriffsrechte
• potenzielle Schnittstellen zwischen internem Team und Dienstleister

Outsourcing bedeutet daher nicht, dass die Verantwortung vollständig verschwindet. Auch bei einem externen SAP-Partner müssen auf Kundenseite beispielsweise Governance, Priorisierung, Architekturentscheidungen und geschäftliche Verantwortung klar verankert bleiben.

Hybrides SAP-AMS-Modell

Ein hybrides Modell kombiniert interne und externe Ressourcen. Dabei übernimmt die interne IT beispielsweise Architektur, Governance, Business Alignment und strategische Entscheidungen, während ein externer Partner definierte Support-, Betriebs- oder Weiterentwicklungsaufgaben übernimmt.

Das kann besonders sinnvoll sein, wenn ein Unternehmen sein SAP-Know-how intern behalten, gleichzeitig aber Kapazitätsengpässe oder Spezialthemen abdecken möchte.

Was sollte intern bleiben?

Auch bei einem weitreichenden SAP-AMS-Modell sollten Unternehmen bewusst festlegen, welche Kompetenzen und Entscheidungen sie selbst kontrollieren möchten.

Dazu können beispielsweise gehören:

• Business- und Prozessverantwortung
• SAP-Strategie und Zielarchitektur
• Priorisierung von Veränderungen
• Governance und Risikomanagement
• Steuerung kritischer Dienstleister
• Freigabe geschäftskritischer Changes

Operative Supportleistungen lassen sich dagegen je nach Situation gezielt extern vergeben.

Die beste Lösung ist deshalb häufig nicht „alles intern“ oder „alles extern“, sondern eine klare Aufteilung der Verantwortlichkeiten. Ein gut definiertes Hybridmodell kann interne Kontrolle mit externer Skalierbarkeit verbinden – vorausgesetzt, Schnittstellen, Eskalationen und Entscheidungsrechte sind eindeutig geregelt.

Welche Leistungen sollte ein SAP-AMS-Vertrag abdecken?

Ein SAP-AMS-Vertrag sollte nicht nur festlegen, dass ein Dienstleister „SAP Support“ leistet. Entscheidend ist eine möglichst klare Beschreibung von Leistungsumfang, Verantwortlichkeiten, Servicezeiten, Eskalationswegen und Schnittstellen.

Je genauer der Scope definiert ist, desto leichter lässt sich später beurteilen, ob eine Anfrage zum vereinbarten Service gehört, wie sie priorisiert wird und wer für die Umsetzung verantwortlich ist.

Incident Management

Beim Incident Management geht es um die Bearbeitung ungeplanter Störungen. Dazu gehören beispielsweise Fehler in SAP-Prozessen, Probleme mit Schnittstellen oder Einschränkungen für bestimmte Benutzergruppen.

Ein sinnvoller Service beschreibt unter anderem:

• welche Systeme und Module abgedeckt sind
• wie Incidents erfasst und priorisiert werden
• welche Informationen für die Analyse benötigt werden
• wie Eskalationen erfolgen
• wie Status und Lösungen dokumentiert werden

Problem Management

Nicht jeder Fehler sollte dauerhaft als einzelner Incident behandelt werden. Treten bestimmte Probleme wiederholt auf, sollte ihre Ursache systematisch untersucht werden.

Problem Management zielt deshalb auf die Root Cause Analysis und die nachhaltige Beseitigung wiederkehrender Fehler. Dazu können beispielsweise technische Analysen, Prozessanpassungen oder gezielte Changes gehören.

Change und Release Management

SAP-Landschaften verändern sich laufend. Neue Anforderungen, gesetzliche Änderungen, Systemupdates oder Integrationen können Anpassungen erforderlich machen.

Der AMS-Service sollte deshalb definieren, wie Changes angefordert, bewertet, getestet, genehmigt und produktiv gesetzt werden. Gleiches gilt für die Planung und Begleitung von Releases.

Wichtig ist dabei die Abgrenzung zwischen operativen Changes und grösseren Transformations- oder Implementierungsprojekten. Nicht jede umfangreiche Weiterentwicklung sollte automatisch Bestandteil des laufenden AMS sein.

Technischer und funktionaler Support

Ein vollständiges Application-Management kann sowohl fachliche als auch technische Leistungen umfassen.

Funktionaler Support kann beispielsweise Fragen zu Geschäftsprozessen und SAP-Modulen abdecken. Technischer Support kann sich dagegen auf Systemabhängigkeiten, Schnittstellen, Jobs, Berechtigungen oder andere technische Komponenten beziehen.

Welche Leistungen tatsächlich erforderlich sind, hängt von der individuellen SAP-Architektur ab.

Weiterentwicklung und Continuous Improvement

Ein SAP-AMS-Modell kann über die reine Störungsbearbeitung hinausgehen. Unternehmen können mit dem Partner auch regelmässige Optimierungen vereinbaren.

Dazu gehören beispielsweise:

• Optimierung bestehender SAP-Prozesse
• Anpassung von Funktionen und Konfigurationen
• Verbesserung von Schnittstellen
• Automatisierung wiederkehrender Aufgaben
• Analyse von Supportdaten
• Vorbereitung neuer Funktionen oder Releases

Hier sollte der Vertrag klar zwischen inkludierten Leistungen und separat zu beauftragenden Projekten unterscheiden.

Was sollte zusätzlich im Vertrag definiert werden?

Neben den einzelnen Services sollten mindestens folgende Punkte eindeutig geregelt sein:

Ein guter SAP-AMS-Vertrag schafft damit vor allem Transparenz über Verantwortung und Erwartungen. Er sollte detailliert genug sein, um den täglichen Betrieb zu steuern, gleichzeitig aber flexibel genug bleiben, um Veränderungen der SAP-Landschaft abzubilden.

Gerade bei S/4HANA-, Cloud- und hybriden Landschaften empfiehlt sich deshalb eine regelmässige Überprüfung des Serviceumfangs. Das Betriebsmodell sollte sich gemeinsam mit der Technologie und den Geschäftsanforderungen weiterentwickeln.

Welche Leistungen sollte ein SAP-AMS-Vertrag abdecken?

Ein SAP-AMS-Vertrag sollte nicht nur festlegen, dass ein Dienstleister „SAP Support“ leistet. Entscheidend ist eine möglichst klare Beschreibung von Leistungsumfang, Verantwortlichkeiten, Servicezeiten, Eskalationswegen und Schnittstellen.

Je genauer der Scope definiert ist, desto leichter lässt sich später beurteilen, ob eine Anfrage zum vereinbarten Service gehört, wie sie priorisiert wird und wer für die Umsetzung verantwortlich ist.

Incident Management

Beim Incident Management geht es um die Bearbeitung ungeplanter Störungen. Dazu gehören beispielsweise Fehler in SAP-Prozessen, Probleme mit Schnittstellen oder Einschränkungen für bestimmte Benutzergruppen.

Ein sinnvoller Service beschreibt unter anderem:

• welche Systeme und Module abgedeckt sind
• wie Incidents erfasst und priorisiert werden
• welche Informationen für die Analyse benötigt werden
• wie Eskalationen erfolgen
• wie Status und Lösungen dokumentiert werden

Problem Management

Nicht jeder Fehler sollte dauerhaft als einzelner Incident behandelt werden. Treten bestimmte Probleme wiederholt auf, sollte ihre Ursache systematisch untersucht werden.

Problem Management zielt deshalb auf die Root Cause Analysis und die nachhaltige Beseitigung wiederkehrender Fehler. Dazu können beispielsweise technische Analysen, Prozessanpassungen oder gezielte Changes gehören.

Change und Release Management

SAP-Landschaften verändern sich laufend. Neue Anforderungen, gesetzliche Änderungen, Systemupdates oder Integrationen können Anpassungen erforderlich machen.

Der AMS-Service sollte deshalb definieren, wie Changes angefordert, bewertet, getestet, genehmigt und produktiv gesetzt werden. Gleiches gilt für die Planung und Begleitung von Releases.

Wichtig ist dabei die Abgrenzung zwischen operativen Changes und grösseren Transformations- oder Implementierungsprojekten. Nicht jede umfangreiche Weiterentwicklung sollte automatisch Bestandteil des laufenden AMS sein.

Technischer und funktionaler Support

Ein vollständiges Application-Management kann sowohl fachliche als auch technische Leistungen umfassen.

Funktionaler Support kann beispielsweise Fragen zu Geschäftsprozessen und SAP-Modulen abdecken. Technischer Support kann sich dagegen auf Systemabhängigkeiten, Schnittstellen, Jobs, Berechtigungen oder andere technische Komponenten beziehen.

Welche Leistungen tatsächlich erforderlich sind, hängt von der individuellen SAP-Architektur ab.

Weiterentwicklung und Continuous Improvement

Ein SAP-AMS-Modell kann über die reine Störungsbearbeitung hinausgehen. Unternehmen können mit dem Partner auch regelmässige Optimierungen vereinbaren.

Dazu gehören beispielsweise:

• Optimierung bestehender SAP-Prozesse
• Anpassung von Funktionen und Konfigurationen
• Verbesserung von Schnittstellen
• Automatisierung wiederkehrender Aufgaben
• Analyse von Supportdaten
• Vorbereitung neuer Funktionen oder Releases

Hier sollte der Vertrag klar zwischen inkludierten Leistungen und separat zu beauftragenden Projekten unterscheiden.

Was sollte zusätzlich im Vertrag definiert werden?

Neben den einzelnen Services sollten mindestens folgende Punkte eindeutig geregelt sein:

Ein guter SAP-AMS-Vertrag schafft damit vor allem Transparenz über Verantwortung und Erwartungen. Er sollte detailliert genug sein, um den täglichen Betrieb zu steuern, gleichzeitig aber flexibel genug bleiben, um Veränderungen der SAP-Landschaft abzubilden.

Gerade bei S/4HANA-, Cloud- und hybriden Landschaften empfiehlt sich deshalb eine regelmässige Überprüfung des Serviceumfangs. Das Betriebsmodell sollte sich gemeinsam mit der Technologie und den Geschäftsanforderungen weiterentwickeln.

SLAs, KPIs und Service Governance

Ein SAP-AMS-Modell funktioniert im Alltag nur dann zuverlässig, wenn nicht nur Leistungen, sondern auch Servicequalität und Verantwortlichkeiten messbar definiert sind. SLAs, KPIs und regelmässige Service Reviews schaffen dafür einen gemeinsamen Rahmen zwischen Unternehmen und AMS-Partner.

Was sollte ein SLA für SAP Support definieren?

Ein Service Level Agreement sollte festlegen, welche Servicequalität bei unterschiedlichen Situationen erwartet wird. Dazu gehören beispielsweise:

• Servicezeiten: Wann ist der Support erreichbar?
• Prioritäten: Wie werden kritische und weniger dringende Incidents unterschieden?
• Reaktionsziele: Wie schnell wird eine Anfrage aufgenommen und bearbeitet?
• Eskalationen: Wann und an wen wird ein Problem weitergeleitet?
• Kommunikation: Wie werden Status, Zwischenstände und Lösungen dokumentiert?
• Reporting: Welche Kennzahlen werden regelmässig ausgewertet?

Reaktions- und Lösungszeiten sollten nicht pauschal für jede SAP-Landschaft übernommen werden. Ein geschäftskritischer Produktionsprozess kann andere Anforderungen haben als eine selten genutzte Anwendung. Die SLA-Struktur sollte deshalb an Geschäftskritikalität, Betriebszeiten und technische Abhängigkeiten angepasst werden.

Beispiel für eine SLA-Struktur

Die konkreten Zeitwerte sollten vertraglich festgelegt werden. Entscheidend ist nicht ein möglichst aggressives SLA, sondern ein realistisches Verhältnis zwischen geschäftlicher Auswirkung, Serviceverfügbarkeit und erforderlichen Ressourcen.

Welche KPIs sind sinnvoll?

SLAs definieren Erwartungen. KPIs zeigen anschliessend, wie der Service tatsächlich funktioniert.

Für SAP AMS können unter anderem folgende Kennzahlen relevant sein:

• Anzahl und Entwicklung der Incidents
• Incidents nach Priorität und SAP-Modul
• Einhaltung vereinbarter Reaktionsziele
• Lösungszeiten
• Anzahl wiederkehrender Incidents
• Backlog und Alter offener Tickets
• Change-Erfolgsquote
• Anzahl produktionsbezogener Fehler nach Changes
• Entwicklung des Supportvolumens
• Nutzer- oder Fachbereichszufriedenheit

Dabei sollte nicht versucht werden, möglichst viele Kennzahlen zu sammeln. Wenige steuerungsrelevante KPIs sind in der Regel hilfreicher als ein umfangreiches Reporting ohne klare Konsequenzen.

Service Governance: Wer entscheidet was?

Neben SLAs und KPIs braucht ein AMS-Modell klare Governance-Strukturen. Regelmässige Service Reviews können beispielsweise dazu dienen, Ticketentwicklungen, SLA-Erfüllung, wiederkehrende Probleme, geplante Changes und Verbesserungsmassnahmen zu besprechen.

Besonders wichtig ist die Abgrenzung zwischen:

• operativen Supportentscheidungen
• geschäftlichen Prioritäten
• technischen Architekturentscheidungen
• Changes und Releases
• strategischen Weiterentwicklungen

Eine klare Verantwortungsmatrix verhindert, dass Entscheidungen zwischen interner IT, Fachbereich und Dienstleister liegen bleiben.

SLAs sollten mit dem Geschäftsmodell verbunden sein

Ein SAP-AMS-Service sollte nicht isoliert nach technischen Kennzahlen gesteuert werden. Entscheidend ist die Auswirkung eines Problems auf das Unternehmen.

Wenn beispielsweise ein Fehler einen zentralen Beschaffungs-, Produktions-, Logistik- oder Finanzprozess beeinträchtigt, kann eine andere Priorisierung erforderlich sein als bei einem rein administrativen Problem.

Gute Service Governance verbindet deshalb SAP-Betrieb mit Business Impact. Sie schafft Transparenz darüber, welche Services kritisch sind, welche Risiken akzeptiert werden können und wo Verbesserungen den grössten geschäftlichen Nutzen bringen.

SAP AMS für S/4HANA, SAP Cloud ERP und hybride Landschaften

Moderne SAP-Landschaften bestehen zunehmend aus einer Kombination verschiedener Systeme und Cloud-Services. Neben SAP S/4HANA oder SAP Cloud ERP können beispielsweise SAP BTP, Integrationslösungen und weitere spezialisierte Anwendungen Teil der Architektur sein. Dadurch wird auch das Application Management komplexer.

SAP S/4HANA

Bei SAP S/4HANA umfasst Application Management nicht nur die klassische Fehlerbehebung. Supportteams müssen Geschäftsprozesse, Integrationen, Eigenentwicklungen und Abhängigkeiten zwischen verschiedenen Systemkomponenten verstehen.

Nach einer S/4HANA-Migration ist deshalb eine strukturierte Übergabe in den Regelbetrieb besonders wichtig. Erfahrungen aus der Implementierung sollten in Supportdokumentation, Monitoring und definierte Betriebsprozesse einfliessen.

SAP Cloud ERP

Bei Cloud-basierten SAP-Modellen verändern sich die Verantwortlichkeiten zwischen Unternehmen, SAP und weiteren Dienstleistern. Nicht jede technische Betriebsaufgabe liegt beim Kunden oder beim AMS-Partner.

Ein SAP-AMS-Modell sollte deshalb klar definieren, wer für welche Anwendung, Schnittstelle und Supportstufe verantwortlich ist. Gerade bei standardisierten Cloud-Services ist diese Abgrenzung wichtiger als die Frage, wer „das System betreibt“.

Hybride SAP-Landschaften

In hybriden Landschaften müssen häufig On-Premise-Systeme, Cloud-Anwendungen und Integrationen gemeinsam betrachtet werden. Ein Incident kann beispielsweise an einer Schnittstelle entstehen, obwohl die betroffene Anwendung selbst technisch verfügbar ist.

Ein geeigneter AMS-Ansatz sollte deshalb auch Abhängigkeiten und Eskalationswege zwischen SAP, interner IT, Cloud-Providern und weiteren Dienstleistern berücksichtigen.

SAP BTP und SAP Cloud ALM

SAP BTP kann Erweiterungen, Integrationen und weitere Services ausserhalb des klassischen S/4HANA-Kerns bereitstellen. Diese Komponenten sollten bei der Definition des Application Managements nicht isoliert betrachtet werden.

Auch SAP Cloud ALM kann im laufenden Betrieb eine Rolle spielen. SAP beschreibt unter anderem Monitoring- und Alerting-Funktionen für Anwendungen, Integrationen, Geschäftsprozesse, Benutzer- und Performance-Aspekte sowie weitere Betriebsbereiche.

Damit verschiebt sich der Fokus von einem rein reaktiven Supportmodell hin zu einem stärker überwachten und datenbasierten SAP-Betrieb.

Für Unternehmen bedeutet das: Je heterogener die SAP-Landschaft, desto wichtiger werden eine klare Verantwortungsmatrix, integriertes Monitoring und definierte Eskalationsprozesse. Ein SAP-AMS-Partner sollte deshalb nicht nur einzelne SAP-Module unterstützen, sondern die relevanten Abhängigkeiten der gesamten Anwendungslandschaft verstehen.

SAP AMS als langfristiges Betriebsmodell

Ein stabiler SAP-Betrieb endet nicht mit dem Go-live. Unternehmen müssen Support, Betrieb, Changes und Weiterentwicklung so organisieren, dass ihre SAP-Landschaft zuverlässig funktioniert und sich gleichzeitig an neue Geschäftsanforderungen anpassen lässt. SAP AMS kann dabei eine flexible Lösung sein – intern, extern oder als Hybridmodell.

LeverX unterstützt Unternehmen entlang des gesamten SAP-Lebenszyklus – von Beratung und Implementierung über Integration und Migration bis hin zu Application Management und laufendem Support. Damit lässt sich die Verbindung zwischen SAP-Transformation und stabilem Betrieb aus einer Hand betrachten.

Für Schweizer Unternehmen ist dabei entscheidend, ein Betriebsmodell zu wählen, das zur eigenen SAP-Landschaft, Organisation und strategischen Ausrichtung passt. LeverX kann dabei als verlässlicher SAP-Partner unterstützen, Anforderungen zu strukturieren, Verantwortlichkeiten zu definieren und ein passendes SAP-AMS-Modell aufzubauen.