SAP Support nach Go-live: Guide für Schweizer Unternehmen

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.

Der SAP Go-live markiert den Übergang vom Projekt- in den operativen Betrieb. Ab diesem Zeitpunkt steht nicht mehr die Einführung des Systems im Mittelpunkt, sondern die Frage, ob die Geschäftsprozesse im Alltag stabil, performant und zuverlässig funktionieren.

Unmittelbar nach dem Produktivstart treten häufig Themen auf, die sich erst unter realen Bedingungen vollständig beurteilen lassen: Benutzerfragen, Prozessabweichungen, Datenprobleme, fehlerhafte Schnittstellen oder unerwartete Systemlast. Deshalb folgt auf den Go-live in der Regel eine Phase mit erhöhter Unterstützung – die sogenannte SAP Hypercare.

Vom Projektteam zum Betriebsteam

Während der Einführung liegt die Verantwortung typischerweise bei einem Projektteam. Nach dem Go-live müssen dagegen klare operative Verantwortlichkeiten etabliert sein. Dazu gehören unter anderem:

• Annahme und Priorisierung von Incidents und Service Requests
• Überwachung von Systemen, Schnittstellen und Hintergrundjobs
• Analyse und Behebung wiederkehrender Fehler
• Steuerung von Changes und Releases
• Pflege der technischen und funktionalen Dokumentation
• Eskalation kritischer Störungen
• Übergabe von Projektwissen an die zuständigen Supportteams

Dabei sollte bereits vor dem Go-live feststehen, wer welche Aufgabe übernimmt. Ein Supportmodell, das erst nach dem Produktivstart definiert wird, erschwert die schnelle Bearbeitung kritischer Probleme.

Was passiert mit offenen Problemen aus dem Go-live?

Nicht jedes offene Ticket ist automatisch ein Zeichen für einen instabilen SAP-Betrieb. Entscheidend ist die Priorisierung.

Kritische Störungen, die einen zentralen Geschäftsprozess beeinträchtigen, benötigen eine andere Behandlung als kleinere Benutzerfragen oder Optimierungswünsche. Deshalb sollten offene Themen spätestens während der Hypercare systematisch klassifiziert und anschliessend in den regulären Support-, Problem- oder Change-Prozess überführt werden.

Kurzantwort: Nach dem SAP Go-live folgt zunächst eine Phase der Stabilisierung und intensiven Betreuung. Danach werden die verbleibenden Aufgaben in einen definierten Regelbetrieb überführt. Dazu gehören Incident- und Problem Management, Monitoring, Changes, Releases und kontinuierliche Weiterentwicklung.

Der eigentliche Übergabepunkt

Der Übergang von Hypercare zum normalen SAP Support sollte nicht allein anhand eines Datums erfolgen. Sinnvoller sind messbare Kriterien: Kritische Incidents müssen beherrscht werden, Supportprozesse funktionieren, Verantwortlichkeiten sind geklärt und das Betriebsteam verfügt über die notwendige Dokumentation und das erforderliche Know-how.

Für Schweizer Unternehmen mit internationalen SAP-Landschaften kommt eine weitere Ebene hinzu. Eine Schweizer Gesellschaft kann beispielsweise in ein globales SAP-Template, zentrale IT-Services und internationale Supportprozesse eingebunden sein. Dann muss nicht nur die lokale Supportorganisation funktionieren; auch die Schnittstellen zwischen lokalem Business, globalem SAP-Team und externen Partnern müssen eindeutig geregelt sein.

Der SAP Support nach dem Go-live ist damit weniger eine einzelne Serviceleistung als ein Betriebsmodell mit klaren Verantwortlichkeiten, Prozessen und Eskalationswegen.

SAP Hypercare: Was passiert in den ersten Wochen?

SAP Hypercare bezeichnet die zeitlich begrenzte Phase erhöhter Unterstützung direkt nach dem Go-live. Ziel ist es, kritische Geschäftsprozesse zu stabilisieren, auftretende Störungen schnell zu beheben und die Organisation sicher in den Regelbetrieb zu überführen.

In dieser Phase arbeitet das Supportteam meist enger und reaktionsschneller als im späteren Normalbetrieb. Fachliche Experten, Key User, IT, Projektteam und gegebenenfalls externe SAP-Partner greifen schneller ineinander. Gleichzeitig werden erste Erfahrungen aus dem Produktivbetrieb genutzt, um Prozesse, Berechtigungen, Schnittstellen und Systemkonfiguration gezielt nachzujustieren.

Wie lange dauert SAP Hypercare?

Eine allgemeingültige Dauer gibt es nicht. Wie lange die Hypercare-Phase sinnvoll ist, hängt unter anderem von der Komplexität der Einführung, der Anzahl der betroffenen Geschäftsprozesse und Standorte, der Integrationslandschaft, der Datenqualität sowie der Zahl der Benutzer ab.

SAP sieht für bestimmte Services und Szenarien beispielsweise definierte Hypercare-Pakete von vier oder acht Wochen vor. Das ist jedoch kein allgemeiner Standard für jedes SAP-Projekt.

Entscheidend ist deshalb weniger die Anzahl der Kalenderwochen als die Frage, ob der SAP-Betrieb bereits kontrolliert und reproduzierbar funktioniert.

Welche Aufgaben gehören zur Hypercare?

Während der Hypercare sollten insbesondere die Themen eng überwacht werden, die für die Stabilität des Geschäftsbetriebs entscheidend sind:

• Priorisierung und schnelle Bearbeitung kritischer Incidents
• Überwachung von Schnittstellen, Hintergrundjobs und Systemverfügbarkeit
• Analyse wiederkehrender Fehler und deren Ursachen
• Unterstützung von Key Usern und Fachbereichen
• Prüfung von Daten- und Prozessproblemen
• Koordination zwischen Fachbereich, IT, Projektteam und externen Partnern
• Dokumentation von Lösungen und bekannten Fehlern
• Übergabe relevanter Erkenntnisse an das spätere Supportteam

Dabei sollte Hypercare nicht zu einer verlängerten Projektphase werden. Offene Themen müssen deshalb laufend bewertet werden: Was ist ein Incident? Was erfordert eine dauerhafte Problemlösung? Was gehört in einen Change? Und welche Anforderungen sind eigentlich Weiterentwicklungen?

Hypercare oder Regelbetrieb?

SAP beschreibt Hypercare im Kontext des Übergangs nach dem Cutover als Teil der Post-Go-live-Unterstützung, bevor die Organisation in einen regulären Betriebsmodus übergeht.

Wann kann Hypercare beendet werden?

Das Ende der Hypercare sollte anhand definierter Kriterien entschieden werden – nicht nur anhand eines im Projektplan eingetragenen Datums. Typische Kriterien sind:

1. Kritische Geschäftsprozesse laufen stabil.
2. Kritische Incidents sind unter Kontrolle.
3. Supportprozesse und Eskalationswege funktionieren.
4. Verantwortlichkeiten für L1-, L2- und L3-Support sind geklärt.
5. Monitoring und relevante Betriebsprozesse sind etabliert.
6. Dokumentation und Known Issues sind an das Betriebsteam übergeben.
7. Das verbleibende Ticketvolumen kann mit dem vorgesehenen Supportmodell bewältigt werden.

Kurz gesagt: Hypercare ist die Brücke zwischen Go-live und Regelbetrieb. Eine gute Hypercare-Phase löst nicht jedes denkbare Problem, sondern schafft die Voraussetzungen dafür, dass offene Themen kontrolliert in Incident-, Problem-, Change- und Supportprozesse übergehen können.

Was sollte ein SAP Support Modell nach dem Go-live abdecken?

Nach der Hypercare-Phase braucht ein Unternehmen mehr als eine zentrale E-Mail-Adresse für Supportanfragen. Ein belastbares SAP Support Modell definiert, welche Leistungen erbracht werden, wer verantwortlich ist, wie Störungen priorisiert werden und wie Änderungen kontrolliert in die SAP-Landschaft gelangen.

Dabei sollte der Support nicht nur auf die Behebung einzelner Incidents ausgerichtet sein. Ziel ist ein Betriebsmodell, das Stabilität, Transparenz und kontinuierliche Verbesserung miteinander verbindet.

Incident Management: Störungen schnell einordnen und beheben

Das Incident Management bildet die Grundlage des laufenden SAP Supports. Eingehende Störungen werden erfasst, priorisiert, bearbeitet und bis zur Lösung nachverfolgt.

Wichtig ist dabei eine klare Unterscheidung zwischen beispielsweise:

• kritischen Störungen eines zentralen Geschäftsprozesses
• Einschränkungen einzelner Funktionen oder Benutzergruppen
• normalen Service Requests
• bekannten Fehlern
• Anforderungen für Changes oder Weiterentwicklungen

Für kritische Incidents sollte ausserdem festgelegt sein, wer eskaliert, wer entscheidet und wer mit dem betroffenen Fachbereich kommuniziert.

Problem Management: Wiederkehrende Fehler dauerhaft lösen

Wenn derselbe Fehler wiederholt auftritt, reicht die Bearbeitung einzelner Tickets nicht aus. Das Problem Management untersucht die zugrunde liegende Ursache und verhindert, dass sich Störungen dauerhaft wiederholen.

Dazu können beispielsweise Root-Cause-Analysen, Known-Error-Dokumentation oder gezielte technische und fachliche Verbesserungen gehören.

Gerade nach einer SAP-Einführung ist dieser Schritt wichtig: Häufen sich ähnliche Tickets, kann dies auf eine Prozessschwäche, fehlerhafte Stammdaten, eine Integrationsproblematik oder eine unzureichende Systemkonfiguration hinweisen.

Change und Release Management: SAP kontrolliert weiterentwickeln

Nach dem Go-live endet die Veränderung der SAP-Landschaft nicht. Neue Anforderungen aus dem Business, gesetzliche Anpassungen, SAP-Releases oder technische Abhängigkeiten führen weiterhin zu Changes.

Ein gutes Support Modell trennt deshalb klar zwischen:

Incident → etwas funktioniert nicht wie erwartet.
Problem → die Ursache wiederkehrender Störungen muss analysiert werden.
Change → eine kontrollierte Änderung am System ist erforderlich.
Weiterentwicklung → eine neue oder erweiterte Funktion wird benötigt.

Diese Unterscheidung verhindert, dass Supporttickets unkontrolliert zu Entwicklungsaufträgen werden und sorgt für eine nachvollziehbare Priorisierung.

Monitoring und technischer SAP Betrieb

Ein stabiler SAP Betrieb beginnt nicht erst mit einem Ticket. Systeme, Schnittstellen, Hintergrundjobs und relevante technische Prozesse sollten möglichst proaktiv überwacht werden.

Dazu gehören je nach SAP-Landschaft beispielsweise:

• Systemverfügbarkeit und technische Performance
• Schnittstellen und Integrationen
• Hintergrundjobs
• relevante System- und Anwendungsfehler
• technische Ereignisse und Alerts
• Verfügbarkeit kritischer Geschäftsprozesse

SAP Cloud ALM unterstützt unter anderem Monitoring, Alerting und die Analyse von Betriebsereignissen und kann damit ein Bestandteil eines strukturierten Betriebsmodells sein.

Knowledge Management: Wissen darf nicht mit dem Projekt verschwinden

Ein häufig unterschätzter Bestandteil des SAP Supports ist die Sicherung des Projektwissens. Nach einer komplexen Einführung kennen einzelne Projektmitarbeitende oder Key User oft noch zahlreiche Zusammenhänge, die nicht vollständig dokumentiert wurden.

Vor dem Übergang in den Regelbetrieb sollten deshalb mindestens folgende Informationen verfügbar sein:

• System- und Prozessdokumentation
• Support- und Eskalationswege
• relevante Schnittstellen und Abhängigkeiten
• bekannte Fehler und Workarounds
• Betriebs- und Monitoringkonzept
• Verantwortlichkeiten
• Dokumentation wichtiger Changes
• Zugriffs- und Berechtigungskonzept für Supportaufgaben

Damit wird aus projektbezogenem Wissen eine belastbare Grundlage für den langfristigen SAP Support.

Ein Support Modell sollte den gesamten Lebenszyklus abdecken

Die einzelnen Disziplinen sollten nicht isoliert betrachtet werden. In der Praxis greifen sie ineinander:

Incident → Analyse → Problem Management → Change → Test → Release → Monitoring → kontinuierliche Verbesserung

Ein solches Modell schafft einen kontrollierten Kreislauf: Störungen werden behoben, wiederkehrende Ursachen analysiert und notwendige Änderungen kontrolliert umgesetzt.

Für Unternehmen mit komplexen oder internationalen SAP-Landschaften ist zusätzlich entscheidend, wo die jeweiligen Verantwortlichkeiten liegen – beispielsweise beim lokalen IT-Team, einem globalen SAP Competence Center, SAP selbst oder einem externen Supportpartner.

Kurzantwort: Ein SAP Support Modell nach dem Go-live sollte mindestens Incident Management, Problem Management, Change- und Release Management, Monitoring, Wissensmanagement sowie klare Verantwortlichkeiten und Eskalationswege abdecken. Die konkrete Ausgestaltung hängt von der SAP-Landschaft, den Geschäftsprozessen und dem gewünschten Service Level ab.

SAP Support, AMS oder Managed Services – welches Modell passt?

Nach dem Go-live stehen Unternehmen häufig vor einer grundlegenden Entscheidung: Reicht ein klassisches SAP Support Modell, wird SAP AMS (Application Management Services) benötigt oder soll ein externer Partner grössere Teile des SAP Betriebs übernehmen?

Die Begriffe werden in der Praxis teilweise unterschiedlich verwendet. Für die Auswahl eines passenden Modells ist deshalb weniger die Bezeichnung entscheidend als der tatsächliche Leistungsumfang, die Verantwortungsverteilung und die vereinbarten Service Levels.

SAP Support: gezielte Unterstützung bei Problemen

Ein klassisches SAP Support Modell konzentriert sich häufig auf die Bearbeitung konkreter Anfragen und Störungen. Je nach Vereinbarung kann dies funktionalen Support, technischen Support oder die Unterstützung bei definierten SAP-Komponenten umfassen.

Das Modell eignet sich beispielsweise, wenn:

• ein internes SAP-Team den Betrieb weitgehend selbst übernimmt,
• nur bestimmte Expertise extern benötigt wird,
• der Support auf einzelne Module oder Themen begrenzt werden soll,
• interne Ressourcen für die Koordination und Steuerung vorhanden sind.

SAP AMS: laufendes Application Management

SAP AMS geht typischerweise über die reine Ticketbearbeitung hinaus. Ein AMS-Modell kann laufenden funktionalen und technischen Support, Problem Management, Changes, Releases und kontinuierliche Optimierung miteinander verbinden.

Damit übernimmt ein AMS-Partner einen definierten Teil des Application Managements – mit klaren Zuständigkeiten und vereinbarten Service Levels.

Besonders sinnvoll kann AMS sein, wenn das Unternehmen langfristig externe Kapazität oder spezialisiertes SAP-Know-how benötigt, ohne den gesamten IT-Betrieb auszulagern.

Managed Services: stärker ausgelagerte Verantwortung

Bei Managed Services wird die Verantwortung für einen vereinbarten Leistungsbereich noch umfassender übertragen. Der externe Partner übernimmt dabei nicht nur einzelne Supportaktivitäten, sondern kann definierte Betriebs- und Serviceaufgaben end-to-end verantworten.

Welche Leistungen tatsächlich enthalten sind, sollte immer vertraglich und organisatorisch konkret definiert werden. Der Begriff allein sagt noch nicht aus, welche Verantwortung beim Dienstleister liegt.

Support, AMS und Managed Services im Vergleich

Die Grenzen zwischen den Modellen sind dabei fliessend. Entscheidend ist daher, die Leistungen nicht nur nach Servicebezeichnung, sondern anhand eines konkreten Servicekatalogs und einer Verantwortungsmatrix zu definieren.

Welches Modell passt zu welchem Unternehmen?

Eine einfache Orientierung:

Internes SAP-Team stark aufgestellt → gezielter externer Support kann ausreichen.

Interne Ressourcen begrenzt oder schwankend → SAP AMS kann laufende Unterstützung und spezialisiertes Know-how ergänzen.

Betriebsverantwortung soll für definierte Services weitgehend extern liegen → Managed Services können sinnvoll sein.

Auch ein hybrides Modell ist möglich: Das interne Team behält beispielsweise Architektur, Governance und Business Ownership, während ein externer Partner L2/L3 Support, Monitoring oder definierte Application-Management-Aufgaben übernimmt.

Für die Entscheidung sollten Unternehmen deshalb zuerst klären: Welche Aufgaben sollen intern bleiben, welche Kompetenzen fehlen und für welche Services wird eine verbindliche externe Leistung benötigt?

Für eine ausführlichere Gegenüberstellung von SAP Support, AMS und Managed Services lohnt sich eine separate Betrachtung der Modelle und Auswahlkriterien.

Welche SLAs braucht ein SAP Support Modell?

Ein SAP Support Modell wird erst dann belastbar, wenn die erwartete Servicequalität messbar definiert ist. Dafür dienen Service Level Agreements (SLAs). Sie legen fest, welche Leistungen ein Supportteam erbringt, innerhalb welcher Zeiten es reagiert und wie Eskalationen gesteuert werden.

Dabei sollte ein SLA nicht nur eine möglichst kurze Reaktionszeit versprechen. Entscheidend ist, dass die vereinbarten Service Levels zu den tatsächlichen Geschäftsanforderungen passen.

Reaktionszeit ist nicht Lösungszeit

Ein häufiger Fehler bei der Gestaltung von SAP Support SLAs ist die Gleichsetzung von Reaktions- und Lösungszeit.

Reaktionszeit bezeichnet den Zeitraum bis zur qualifizierten Bearbeitung eines Incidents.

Lösungszeit beschreibt dagegen den Zeitraum bis zur Wiederherstellung des vereinbarten Services oder bis eine definierte Lösung beziehungsweise ein Workaround vorliegt.

Bei einer kritischen Störung kann beispielsweise eine sehr kurze Reaktionszeit erforderlich sein, während die endgültige Ursachenbehebung mehr Zeit benötigt. Deshalb sollten beide Werte separat vereinbart werden.

Prioritäten nach Geschäftsauswirkung definieren

Nicht jedes SAP-Ticket benötigt dieselbe Servicequalität. Sinnvoll ist eine Priorisierung anhand von Geschäftsauswirkung und Dringlichkeit.

Die konkrete Definition sollte zur Organisation passen. Ein Produktionsstillstand, ein Fehler in der Finanzbuchhaltung und eine einzelne Benutzerfrage haben beispielsweise unterschiedliche geschäftliche Auswirkungen.

Welche SLA-Bausteine sollte ein SAP Support Vertrag enthalten?

Ein vollständiges Support-Modell sollte mindestens folgende Punkte klären:

• Servicezeiten: Wann ist der Support verfügbar?
• Reaktionszeiten: Wie schnell wird ein Incident aufgenommen?
• Lösungs- oder Wiederherstellungszeiten: Welche Zielwerte gelten für unterschiedliche Prioritäten?
• Priorisierung: Nach welchen Kriterien wird P1, P2, P3 oder P4 vergeben?
• Eskalation: Was passiert, wenn ein SLA gefährdet oder überschritten wird?
• Bereitschaft: Gibt es ausserhalb der regulären Servicezeiten eine Rufbereitschaft?
• Supportumfang: Welche SAP-Systeme, Module, Schnittstellen und Services sind abgedeckt?
• Verantwortlichkeiten: Welche Aufgaben übernimmt der Kunde, welche der Supportpartner?
• Reporting: Welche KPIs werden regelmässig ausgewertet?
• Service Reviews: Wie werden Leistung und Verbesserungsmassnahmen gemeinsam überprüft?

Gerade bei hybriden SAP-Landschaften sollte zusätzlich eindeutig geregelt sein, wo die Verantwortung zwischen Unternehmen, SAP, Cloud-Anbietern, Infrastrukturpartnern und SAP Supportpartnern liegt.

SLA ist nicht gleich SLA

Ein zu ambitioniertes SLA kann genauso problematisch sein wie ein zu schwaches. Wenn beispielsweise eine sehr kurze Lösungszeit vereinbart wird, obwohl die Ursache nur durch einen Change, einen Drittanbieter oder eine komplexe Schnittstelle behoben werden kann, entstehen unrealistische Erwartungen.

Besser ist ein Modell, das zwischen Service Level, Geschäftsrelevanz und tatsächlicher Beeinflussbarkeit unterscheidet.

Dazu gehört auch eine klare Definition dessen, was als „Lösung“ gilt. Bei komplexen Incidents kann die temporäre Wiederherstellung des Geschäftsbetriebs durch einen Workaround sinnvoller sein als die sofortige dauerhafte Ursachenbehebung.

SLAs sollten regelmässig überprüft werden

Ein SAP Support Modell bleibt nicht über Jahre unverändert. Nach einigen Monaten im Regelbetrieb zeigen Ticketvolumen, Incident-Muster und tatsächliche Geschäftsanforderungen, ob die vereinbarten Service Levels noch passen.

Regelmässige Service Reviews können deshalb beispielsweise folgende Fragen beantworten:

• Welche Incidents treten besonders häufig auf?
• Werden vereinbarte Reaktionszeiten eingehalten?
• Wo entstehen wiederkehrende Eskalationen?
• Welche Probleme sollten dauerhaft behoben werden?
• Entsprechen Servicezeiten und Bereitschaft noch dem Geschäftsbedarf?
• Welche Changes oder Verbesserungen lassen sich aus den Supportdaten ableiten?

Kurzantwort: Ein gutes SAP Support SLA definiert nicht nur Reaktionszeiten. Es regelt Prioritäten, Lösungs- beziehungsweise Wiederherstellungszeiten, Servicezeiten, Eskalationen, Verantwortlichkeiten und Reporting. Die Zielwerte sollten sich an der geschäftlichen Kritikalität der unterstützten Prozesse orientieren.

Wie organisiert man SAP Support in der Praxis?

Ein definiertes Supportmodell braucht eine ebenso klare Organisation. Nach dem Go-live sollte deshalb feststehen, wer Tickets entgegennimmt, wer fachliche und technische Probleme löst und wer bei kritischen Störungen entscheidet.

Für viele Unternehmen bietet sich ein mehrstufiges Modell an. Die genaue Aufteilung hängt von der Grösse der Organisation, der SAP-Landschaft und dem verfügbaren internen Know-how ab.

L1, L2 und L3: Wer übernimmt welche Aufgabe?

Eine typische Supportstruktur unterscheidet drei Ebenen:

• L1: Erste Anlaufstelle für Benutzer, Ticketaufnahme, Klassifizierung, Priorisierung und einfache Standardlösungen.
• L2: Fachliche und technische Analyse komplexerer Incidents innerhalb definierter SAP-Module oder Services.
• L3: Tiefgehende technische Analyse, Fehlerbehebung im System, Entwicklung oder Unterstützung bei komplexen Problemen.

Diese Ebenen müssen nicht zwingend auf drei verschiedene Organisationen verteilt sein. Ein internes SAP-Team kann beispielsweise L1 und Teile von L2 übernehmen, während ein externer SAP-Partner L2/L3 unterstützt.

Eine RACI-Matrix schafft Klarheit

Besonders bei internationalen SAP-Landschaften entstehen Probleme häufig nicht durch fehlendes Know-how, sondern durch unklare Zuständigkeiten.

Eine einfache RACI-Matrix kann beispielsweise festhalten:

R = Responsible, A = Accountable, C = Consulted.

Die konkrete Matrix sollte an die jeweilige Organisation angepasst werden. Entscheidend ist, dass für jede kritische Aufgabe genau nachvollziehbar ist, wer verantwortlich ist und wer die Entscheidung trifft.

Intern oder extern?

Die Entscheidung zwischen internem und externem SAP Support ist selten ein reines Entweder-oder. Ein hybrides Modell kann sinnvoll sein, wenn das Unternehmen strategische Verantwortung und Business-Know-how intern behalten, gleichzeitig aber externe Kapazität oder Spezialwissen nutzen möchte.

Interner Support bietet insbesondere Vorteile bei Geschäftsprozesswissen, direktem Kontakt zu Fachbereichen und langfristigem Aufbau eigener SAP-Kompetenz.

Externer Support kann dagegen zusätzliche Kapazität, spezialisierte Kenntnisse und definierte Service Levels bereitstellen. Das kann besonders relevant sein, wenn interne Ressourcen schwanken oder mehrere SAP-Technologien und Integrationen gleichzeitig betreut werden müssen.

Governance gehört zum Supportmodell

Auch ein operativ gut funktionierender Support benötigt Steuerung. Dazu gehören regelmässige Service Reviews, KPI-Auswertungen, Eskalationsmanagement und die gemeinsame Priorisierung von Verbesserungen.

Typische Kennzahlen können beispielsweise sein:

• Anzahl und Entwicklung der Incidents
• Incidents nach Priorität
• Einhaltung der vereinbarten SLAs
• Wiederkehrende Incidents und offene Problems
• Ticketvolumen nach SAP-Modul oder Service
• Alter offener Tickets
• Anzahl und Status von Changes
• Eskalationen und deren Ursachen

Damit wird SAP Support von einer reaktiven Ticketfunktion zu einem steuerbaren Bestandteil des SAP Betriebs.

Was sollte vor der Übergabe geklärt sein?

Vor dem Ende der Hypercare sollte das Unternehmen deshalb nicht nur technische Dokumentation übergeben, sondern auch die operative Organisation testen. Dazu gehören beispielsweise Eskalationsszenarien für einen kritischen Incident, die Erreichbarkeit der zuständigen Teams und die Übergabe eines realistischen Ticketbestands.

Kurzantwort: Ein praxistaugliches SAP Support Modell kombiniert klare L1/L2/L3-Verantwortlichkeiten, eine RACI-Matrix, definierte Eskalationswege und regelmässige Service Governance. Ob die Leistungen intern, extern oder hybrid erbracht werden, sollte anhand von Know-how, Ressourcen, Geschäftsrelevanz und gewünschtem Service Level entschieden werden.

SAP Support in Cloud- und hybriden SAP-Landschaften

Mit SAP S/4HANA Cloud, SAP BTP und integrierten Cloud-Services verändert sich auch die Organisation des SAP Supports. Nicht mehr alle technischen Komponenten liegen unter der direkten Kontrolle des Unternehmens. Gleichzeitig bleiben fachliche Prozesse, Daten, Konfigurationen und ein Teil der Betriebsverantwortung beim Kunden.

Deshalb sollte ein Support Modell für eine Cloud- oder hybride SAP-Landschaft zunächst klären: Wer ist für welchen Service verantwortlich?

Verantwortung über mehrere Ebenen verteilen

In einer typischen Cloud-Landschaft können mehrere Parteien beteiligt sein:

• Unternehmen: Business-Prozesse, fachliche Anforderungen, interne Governance und definierte Kundenaufgaben
• SAP: Leistungen und Verantwortlichkeiten entsprechend dem jeweiligen SAP Cloud Service und Vertrag
• SAP Support- oder AMS-Partner: vereinbarte funktionale, technische oder operative Supportleistungen
• Drittanbieter: beispielsweise für Schnittstellen, Add-ons oder angebundene Systeme

Diese Aufteilung sollte nicht implizit bleiben. Gerade bei Incidents, die mehrere Systeme betreffen, muss klar sein, wer die Koordination übernimmt und bis zu welchem Punkt die jeweilige Partei verantwortlich ist.

SAP S/4HANA Cloud erfordert ein angepasstes Supportmodell

Bei SAP S/4HANA Cloud verschiebt sich ein Teil der technischen Betriebsverantwortung in Richtung Cloud-Anbieter. Das bedeutet jedoch nicht, dass das Unternehmen keinen eigenen SAP Support mehr benötigt.

Fachliche Prozessfragen, Konfiguration, Berechtigungen, Integrationen, Stammdaten, Benutzerunterstützung und die Koordination von Changes können weiterhin Bestandteil des kundenseitigen Supportmodells sein.

Die genaue Verantwortungsverteilung hängt vom eingesetzten Cloud-Modell und den vertraglich definierten Leistungen ab.

SAP BTP und Integrationen mitdenken

In modernen SAP-Landschaften endet der Support zudem nicht an der Grenze des ERP-Systems. SAP BTP, Integrationslösungen, Drittanwendungen und bestehende On-Premise-Systeme können miteinander verbunden sein.

Bei einer Störung sollte deshalb nicht nur gefragt werden, welches SAP-System betroffen ist, sondern auch, welcher Geschäftsprozess über mehrere Systeme hinweg beeinträchtigt wird.

Ein Supportmodell sollte beispielsweise definieren:

1. Wer überwacht relevante Integrationen?
2. Wer analysiert Fehler zwischen SAP und Drittsystemen?
3. Wer koordiniert externe Anbieter?
4. Wer entscheidet über notwendige Changes?
5. Wer übernimmt die Kommunikation gegenüber dem Business?

SAP Success Plans und ergänzende Services

Auch das SAP-eigene Support- und Serviceportfolio entwickelt sich weiter. SAP hat 2026 ein Portfolio aus Foundational, Advanced und Max Success Plan eingeführt, die je nach SAP Cloud Solution unterschiedliche Unterstützungsleistungen und Betreuungsintensitäten abdecken. Ergänzende Services können weitere operative oder fachliche Aufgaben adressieren.

Für Unternehmen bedeutet das: Der SAP-eigene Service sollte nicht isoliert betrachtet werden. Entscheidend ist, welche Leistungen bereits durch SAP abgedeckt sind und welche Lücken im eigenen Supportmodell verbleiben.

Kurzantwort: In Cloud- und hybriden SAP-Landschaften muss Support über Systemgrenzen hinweg organisiert werden. Unternehmen sollten Verantwortlichkeiten zwischen SAP, internem IT-Team, AMS-Partnern und Drittanbietern eindeutig dokumentieren und für kritische Geschäftsprozesse einen klaren Eskalationsweg definieren.

Was Schweizer Unternehmen beim SAP Support beachten sollten

Für Schweizer Unternehmen gelten beim SAP Support grundsätzlich dieselben Anforderungen an Stabilität, Servicequalität und klare Verantwortlichkeiten wie in anderen Märkten. Gleichzeitig können Datenschutz, internationale Organisationsstrukturen und lokale Geschäftsanforderungen die Gestaltung des Supportmodells beeinflussen.

Datenschutz und externer Supportzugriff

Wird SAP Support an einen externen Dienstleister ausgelagert, sollte geprüft werden, welche Daten verarbeitet werden, auf welche Systeme zugegriffen werden kann und wo die beteiligten Parteien ihren Sitz haben.

Der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte (EDÖB) weist darauf hin, dass Unternehmen auch bei ausgelagerter Bearbeitung personenbezogener Daten grundsätzlich verantwortlich bleiben. Bei einer Bekanntgabe von Daten ins Ausland müssen zudem die entsprechenden Voraussetzungen und Schutzmechanismen geprüft werden.

Für das Supportmodell bedeutet das: Zugriffsrechte, Datenflüsse und Verantwortlichkeiten sollten bereits bei der Vertrags- und Prozessgestaltung berücksichtigt werden. Daraus folgt nicht automatisch, dass Supportdaten oder Systeme in der Schweiz betrieben werden müssen. Entscheidend sind die konkrete Datenverarbeitung und die anwendbaren rechtlichen Anforderungen.

Schweizer Tochtergesellschaften in globalen SAP-Landschaften

Viele Schweizer Unternehmen oder Schweizer Tochtergesellschaften sind in internationale SAP-Organisationen eingebunden. Ein globales Template, ein zentraler SAP Betrieb oder ein internationaler Service Desk kann dabei sinnvoll sein.

Trotzdem können lokale Anforderungen bestehen – etwa bei Geschäftsprozessen, Organisation, Sprache oder der Zusammenarbeit mit Schweizer Fachbereichen.

Ein funktionierendes Modell sollte deshalb eindeutig beantworten:

• Welche Supportleistungen werden lokal erbracht?
• Welche Aufgaben liegen bei einem globalen SAP Competence Center?
• Wer entscheidet bei lokalen Prozessanforderungen?
• Wie werden internationale Eskalationen gesteuert?
• Welche Servicezeiten gelten für Schweizer Benutzer?
• In welcher Sprache erfolgt die Kommunikation mit Fachbereichen und Key Usern?

Lokale Anforderungen mit globaler Governance verbinden

Eine Schweizer SAP-Organisation muss nicht zwangsläufig ein vollständig separates Supportmodell aufbauen. Häufig ist eine Kombination sinnvoll: globale Standards und Governance werden mit lokal definierten Verantwortlichkeiten ergänzt.

Beispielsweise können Incident Management, Monitoring und L3 Support zentral organisiert sein, während lokale Key User und Business Owner fachliche Anforderungen priorisieren und mit dem globalen Team abstimmen.

Damit lässt sich vermeiden, dass lokale Anforderungen entweder unkontrolliert vom globalen Standard abweichen oder im zentralen Supportprozess nicht ausreichend berücksichtigt werden.

Was sollte im Schweizer Kontext geprüft werden?

Vor der Übergabe in den Regelbetrieb lohnt sich eine gezielte Prüfung von:

1. Datenschutz: Welche personenbezogenen Daten können im Support verarbeitet werden?
2. Zugriffe: Wer kann aus welchen Ländern auf SAP-Systeme oder Supportdaten zugreifen?
3. Datenübermittlungen: Werden Daten oder Supportinformationen ins Ausland übermittelt?
4. Verantwortlichkeiten: Welche Aufgaben liegen lokal, welche global?
5. Servicezeiten: Decken die vereinbarten Zeiten die tatsächlichen Geschäftsanforderungen ab?
6. Kommunikation: Sind Sprache und Eskalationswege für lokale Fachbereiche klar definiert?
7. Vertragliche Regelungen: Sind Supportumfang, Zugriffsrechte und Verantwortlichkeiten mit externen Partnern eindeutig geregelt?

Schweizer Unternehmen sollten beim SAP Support insbesondere Datenverarbeitung, externe Zugriffe und internationale Verantwortlichkeiten frühzeitig klären. Bei globalen SAP-Landschaften geht es dabei weniger um ein vollständig separates Schweizer Modell als um eine klare Verbindung zwischen lokalen Geschäftsanforderungen und globaler SAP Governance.

Post-Go-live-Checkliste: Ist Ihr SAP Support bereit für den Regelbetrieb?

Der Übergang von Hypercare in den Regelbetrieb sollte anhand konkreter Kriterien erfolgen. Die folgende Post-Go-live-Checkliste hilft dabei, die wichtigsten organisatorischen, technischen und vertraglichen Voraussetzungen zu prüfen.

15 Punkte für den SAP Support Readiness Check

• Organisation und Verantwortlichkeiten

1. L1-, L2- und L3-Verantwortlichkeiten sind definiert.
2. Für kritische Incidents sind Eskalationswege und Ansprechpartner bekannt.
3. Interne und externe Verantwortlichkeiten sind dokumentiert.
4. Business Owner und Key User kennen ihre Rolle im Supportprozess.

• Prozesse und SLAs

1. Incident-, Problem-, Change- und Release-Prozesse sind etabliert.
2. Prioritäten und Kriterien für P1–P4 sind definiert.
3. Reaktions- und gegebenenfalls Lösungs- oder Wiederherstellungszeiten sind vereinbart.
4. Servicezeiten und Bereitschaft sind passend zu den Geschäftsanforderungen festgelegt.

5. Reporting und regelmässige Service Reviews sind vorgesehen.

• Technik und Wissen

1. Monitoring für relevante SAP-Systeme, Schnittstellen und Hintergrundjobs ist eingerichtet.
2. Kritische Abhängigkeiten zu Drittsystemen sind dokumentiert.
3. Known Issues und Workarounds sind verfügbar.

4. System-, Prozess- und Supportdokumentation wurde an das Betriebsteam übergeben.

5. Relevantes Projektwissen ist nicht nur bei einzelnen Mitarbeitenden vorhanden.

• Governance und Weiterentwicklung

1. Offene Hypercare-Tickets sind einem klaren Folgeprozess zugeordnet.
2. Es gibt einen definierten Prozess für Changes und kontinuierliche Verbesserungen.

Ein „Ja“ bei allen Punkten ist nicht zwingend erforderlich

Die Checkliste sollte nicht als formale Abnahme verstanden werden. Entscheidend ist, ob die verbleibenden Lücken bekannt, priorisiert und verantwortet sind.

Ein Unternehmen kann beispielsweise in den Regelbetrieb wechseln, obwohl einzelne Optimierungen noch offen sind. Kritischer wäre dagegen eine Situation, in der niemand für bestimmte Incidents zuständig ist, Eskalationswege fehlen oder das notwendige Betriebswissen nur beim ursprünglichen Projektteam liegt.

Der wichtigste Prüfpunkt lautet deshalb:

Kann das zuständige Betriebsteam einen kritischen SAP Incident ohne das ursprüngliche Projektteam kontrolliert bearbeiten oder zumindest gezielt eskalieren?

Wenn die Antwort nein lautet, ist der Übergang aus der Hypercare wahrscheinlich noch nicht ausreichend vorbereitet.

Von der Checkliste zum kontinuierlichen Verbesserungsprozess

Support Readiness endet zudem nicht mit dem Übergang in den Regelbetrieb. Ticketdaten, SLA-Reports, wiederkehrende Incidents und Change-Anforderungen liefern wichtige Hinweise darauf, wo Prozesse oder die SAP-Landschaft weiter optimiert werden sollten.

Damit wird aus dem Post-Go-live-Check kein einmaliger Abschluss, sondern der Ausgangspunkt für einen kontinuierlichen SAP Betrieb und eine strukturierte Weiterentwicklung.

Wie LeverX unterstützen kann

LeverX unterstützt Unternehmen dabei, SAP-Landschaften nach dem Go-live strukturiert in den stabilen Betrieb zu überführen und langfristig weiterzuentwickeln. Dazu können je nach Bedarf SAP AMS, Application Support, technische und funktionale Betreuung sowie kontinuierliche Optimierung gehören.

Der Ansatz lässt sich an die bestehende Organisation anpassen: Unternehmen können ausgewählte Supportleistungen auslagern oder ein hybrides Modell etablieren, bei dem interne Teams die Governance und Business-Verantwortung behalten und LeverX definierte operative oder fachliche Aufgaben übernimmt.

Für Schweizer Unternehmen mit komplexen oder internationalen SAP-Landschaften kann dabei insbesondere die klare Abgrenzung von Verantwortlichkeiten, Supportprozessen und Eskalationswegen helfen.