SAP Support Level 1, 2 und 3: Aufgaben, SLAs und Eskalation erklärt

Was unterscheidet L1, L2 und L3 im SAP Support? Dieser Leitfaden erklärt Aufgaben, typische Tickets, Eskalationswege, Prioritäten und SLAs anhand praktischer Beispiele.

SAP Support wird in vielen Unternehmen in drei Support-Level gegliedert. Der L1 Support beziehungsweise First-Level-Support nimmt Anfragen auf, klassifiziert Tickets und löst standardisierte Anwenderprobleme. Der L2 Support beziehungsweise Second-Level-Support bearbeitet funktionale und technische Störungen, die vertiefte SAP-Kenntnisse erfordern. Der L3 Support beziehungsweise Third-Level-Support übernimmt komplexe Fehler, kundenspezifische Entwicklungen, Schnittstellenprobleme und Änderungen am System.

Die klare Aufteilung zwischen Level 1, Level 2 und Level 3 sorgt dafür, dass jedes Ticket möglichst schnell den richtigen Ansprechpartner erreicht. Gleichzeitig schafft sie Transparenz über Verantwortlichkeiten, Eskalationswege und die im Service Level Agreement definierten Reaktionszeiten.

Die genaue Aufgabenverteilung ist jedoch nicht in jedem Unternehmen identisch. Sie hängt von der SAP-Landschaft, den internen Kompetenzen, dem Ticketvolumen und dem gewählten Support-Modell ab.

In diesem Leitfaden erfahren Sie, welche Aufgaben die einzelnen SAP Support Level übernehmen, wie Tickets eskaliert werden und welche Rolle Prioritäten, SLAs und externe SAP-Dienstleister dabei spielen.

Warum werden SAP Support Leistungen in L1, L2 und L3 unterteilt?

SAP-Systeme unterstützen häufig geschäftskritische Prozesse in Finance, Einkauf, Vertrieb, Logistik, Produktion oder Personalmanagement. Eine Störung kann deshalb einzelne Anwender betreffen, aber auch ganze Prozessketten oder produktive Systeme beeinträchtigen.

Nicht jedes Problem erfordert jedoch sofort einen Entwickler oder einen spezialisierten SAP-Berater. Viele Anfragen lassen sich bereits durch standardisierte Anleitungen, eine Korrektur von Benutzereinstellungen oder die Prüfung bekannter Fehler lösen. Andere Tickets benötigen dagegen funktionales Prozesswissen, technische Analysen oder Änderungen an kundenspezifischem Code.

Die Aufteilung in drei Support-Level ermöglicht eine strukturierte Bearbeitung:

• L1 Support übernimmt den ersten Kontakt, die Dokumentation und die Erstlösung.
• L2 Support analysiert funktionale und technische Probleme.
• L3 Support löst besonders komplexe Störungen und unterstützt die technische Weiterentwicklung des Systems.

Ein gut organisiertes Support-Modell verhindert, dass hochqualifizierte SAP-Spezialisten dauerhaft mit einfachen Standardanfragen beschäftigt werden. Gleichzeitig stellt es sicher, dass kritische Incidents schnell eskaliert und von Experten mit den passenden Kompetenzen bearbeitet werden.

Rollen, Ticketprioritäten, Zuständigkeiten und Eskalationswege sollten deshalb im SLA und in den operativen Support-Prozessen eindeutig dokumentiert sein.

SAP Support Level 1, 2 und 3 im direkten Vergleich

Die drei SAP Support Level unterscheiden sich vor allem durch die Komplexität der bearbeiteten Anfragen und die erforderliche fachliche oder technische Expertise.

Der L1 Support ist die erste Anlaufstelle für Anwender und löst bekannte, standardisierte Probleme. Der L2 Support analysiert Störungen, die tieferes Prozess-, Modul- oder Konfigurationswissen erfordern. Der L3 Support übernimmt komplexe Fehler, kundenspezifische Entwicklungen und Änderungen, die spezialisierte SAP-Berater, Entwickler oder Architekten benötigen.

Typische SAP-Tickets nach Support-Level

Die Zuordnung eines Tickets hängt nicht nur von der Fehlermeldung ab. Entscheidend sind auch die Ursache, die Auswirkungen auf den Geschäftsbetrieb und die für die Lösung erforderlichen Kompetenzen.

Beispiele für L1-Tickets

• Ein Anwender kann eine bekannte Transaktion nicht finden.
• Eine Standardfunktion wird nicht wie erwartet bedient.
• Ein Benutzer benötigt Informationen zum Status eines bereits gemeldeten Incidents.
• Eine bekannte Fehlermeldung kann anhand einer dokumentierten Lösung behoben werden.
• Ein Ticket muss erfasst, kategorisiert und dem richtigen SAP-Modul zugeordnet werden.
• Ein Anwender benötigt Unterstützung bei einem standardisierten Prozessschritt.

Beispiele für L2-Tickets

• Eine Bestellung kann aufgrund einer fehlerhaften Konfiguration nicht freigegeben werden.
• Ein Buchungsprozess liefert nur für bestimmte Belegarten ein falsches Ergebnis.
• Stammdaten oder Customizing-Einstellungen verursachen einen Prozessfehler.
• Eine Benutzerrolle enthält nicht die erforderlichen Berechtigungen.
• Ein Interface verarbeitet einzelne Datensätze nicht korrekt.
• Ein wiederkehrender Incident erfordert eine funktionale Ursachenanalyse.
• Ein Service Request benötigt eine begrenzte Konfigurationsänderung.

Beispiele für L3-Tickets

• Ein Fehler liegt in einer kundenspezifischen ABAP-Entwicklung.
• Eine Schnittstelle muss technisch angepasst oder neu entwickelt werden.
• Eine komplexe Performance-Störung betrifft mehrere Systeme und Prozessschritte.
• Eine SAP-Fiori-Anwendung benötigt Änderungen am Frontend oder Backend.
• Eine neue Funktion erfordert eine Erweiterung des SAP-Standards.
• Ein Fehler kann nur durch eine tiefgehende Code-, Architektur- oder Datenbankanalyse behoben werden.
• Für die Lösung muss SAP oder ein weiterer Technologieanbieter einbezogen werden.

Die Support-Level sind nicht vollständig standardisiert

Die Begriffe L1, L2 und L3 werden in vielen Unternehmen verwendet, ihre konkrete Ausgestaltung kann jedoch variieren. Manche Organisationen ordnen beispielsweise Berechtigungsprobleme dem L1 Support zu, während diese in anderen Unternehmen von einem spezialisierten L2-Team bearbeitet werden.

Auch die Grenze zwischen Support und Weiterentwicklung ist nicht immer eindeutig. Eine kleine Konfigurationsänderung kann als Service Request im L2 Support bearbeitet werden. Eine umfangreiche Prozessanpassung mit Entwicklungsaufwand gehört dagegen normalerweise in den L3 Support oder in ein separates Change-Projekt.

Deshalb sollten Unternehmen für jeden Support-Level eindeutig festlegen:

• welche Systeme und Module abgedeckt werden,
• welche Ticketarten das jeweilige Team bearbeitet,
• welche Änderungen ohne zusätzliche Freigabe erlaubt sind,
• wann eine Eskalation erfolgen muss,
• welche Rollen für Kommunikation und Entscheidungen verantwortlich sind,
• welche Reaktionszeiten und Servicezeiten gelten.

Eine klare Support-Matrix verhindert unnötige Weiterleitungen und sorgt dafür, dass Tickets von Beginn an dem Team mit den passenden Kompetenzen zugeordnet werden.

Ergänzen Sie Ihr internes Team mit erfahrenen SAP-Beratern, Entwicklern und Integrationsexperten.
SAP-Experten anfragen

Welche Aufgaben übernimmt der SAP L1 Support?

Der SAP L1 Support ist die erste Anlaufstelle für Endanwender und Key User. Seine wichtigste Aufgabe besteht darin, Anfragen strukturiert aufzunehmen, relevante Informationen zu sammeln und möglichst viele standardisierte Probleme direkt zu lösen.

Kann ein Ticket nicht im First-Level-Support bearbeitet werden, sorgt der L1 Support dafür, dass es vollständig dokumentiert, richtig priorisiert und an das zuständige L2- oder L3-Team weitergeleitet wird.

Zentrale Aufgaben des SAP L1 Supports

Zu den typischen Aufgaben gehören:

• Annahme von Anfragen über Service Portal, E-Mail, Telefon oder Chat
• Erfassung und Dokumentation des Tickets
• Zuordnung zum richtigen SAP-System, Modul oder Geschäftsprozess
• Kategorisierung als Incident, Service Request oder Anwenderfrage
• Bewertung der Dringlichkeit und Geschäftsauswirkung
• Bearbeitung bekannter und standardisierter Probleme
• Nutzung vorhandener Anleitungen und Knowledge-Base-Artikel
• Kommunikation mit dem Anwender
• Weiterleitung komplexerer Tickets an L2 oder L3
• Nachverfolgung des Bearbeitungsstatus
• Abschluss und Dokumentation gelöster Tickets

Welche Informationen sollte der L1 Support erfassen?

Eine vollständige Ticketbeschreibung ist entscheidend für eine schnelle Bearbeitung. Fehlen wichtige Angaben, müssen L2- oder L3-Experten zunächst zusätzliche Informationen anfordern, bevor die eigentliche Analyse beginnen kann.

Der L1 Support sollte deshalb möglichst folgende Informationen dokumentieren:

• betroffener Anwender und Standort
• betroffenes SAP-System und Mandant
• SAP-Modul oder Geschäftsprozess
• verwendete Transaktion oder Anwendung
• genaue Fehlermeldung
• Zeitpunkt und Häufigkeit des Problems
• betroffene Benutzer oder Organisationseinheiten
• Geschäftsauswirkung
• bereits getestete Lösungsversuche
• Screenshots, Belege oder relevante Protokolle
• mögliche Fristen oder kritische Geschäftstermine

Bei geschäftskritischen Incidents sollte zusätzlich geklärt werden, ob ein Workaround verfügbar ist und welche Prozesse aktuell stillstehen oder eingeschränkt sind.

Welche Probleme kann der SAP L1 Support direkt lösen?

Der First-Level-Support bearbeitet vor allem wiederkehrende Probleme, für die dokumentierte Lösungen oder standardisierte Vorgehensweisen vorhanden sind.

Typische Beispiele sind:

• Unterstützung bei der Navigation in SAP
• Fragen zu bekannten Prozessschritten
• Zuordnung einer Anfrage zum richtigen Modul
• Prüfung bekannter Fehlermeldungen
• Hinweise zur Nutzung einer Standardtransaktion
• Unterstützung bei einfachen Benutzerproblemen
• Statusauskünfte zu offenen Tickets
• Bereitstellung freigegebener Anleitungen
• erneute Ausführung standardisierter Prozessschritte
• Weiterleitung von Berechtigungsanfragen nach einem definierten Verfahren

Ob Passwort- oder Berechtigungsprobleme tatsächlich durch L1 bearbeitet werden, hängt von den Sicherheitsrichtlinien und der Aufgabenverteilung des jeweiligen Unternehmens ab.

Welche Kompetenzen benötigt ein L1-Support-Mitarbeiter?

Der L1 Support muss nicht jedes SAP-Modul im Detail beherrschen. Er benötigt jedoch ausreichend Wissen, um Anfragen zu verstehen, korrekt einzuordnen und die richtigen Informationen zu erfassen.

Wichtige Kompetenzen sind:

• grundlegendes Verständnis der SAP-Landschaft
• Kenntnis zentraler Geschäftsprozesse
• sicherer Umgang mit dem Ticket-System
• Verständnis der Ticketkategorien und Prioritäten
• Kenntnis der vereinbarten SLAs
• Fähigkeit zur strukturierten Fehleraufnahme
• klare Kommunikation mit Anwendern
• Nutzung von Wissensdatenbanken und Support-Dokumentation
• Verständnis der Eskalationswege
• Sensibilität für Datenschutz und Zugriffsrechte

Besonders wichtig ist die Fähigkeit, zwischen einem Bedienungsproblem, einer technischen Störung und einem potenziell geschäftskritischen Incident zu unterscheiden.

Wann wird ein Ticket vom L1 an den L2 Support eskaliert?

Ein Ticket sollte an den L2 Support weitergeleitet werden, wenn:

• keine dokumentierte Standardlösung verfügbar ist,
• vertiefte Kenntnisse des SAP-Moduls erforderlich sind,
• eine Systemkonfiguration geprüft werden muss,
• das Problem nur bestimmte Prozessvarianten betrifft,
• ein Stammdaten- oder Berechtigungsproblem vermutet wird,
• ein Fehler wiederholt auftritt,
• eine fachliche Ursachenanalyse notwendig ist,
• die Bearbeitung außerhalb des Verantwortungsbereichs von L1 liegt,
• die vereinbarte Bearbeitungszeit überschritten werden könnte.

Die Eskalation sollte nicht nur aus einer Weiterleitung bestehen. Der L1 Support muss sicherstellen, dass das Ticket verständlich beschrieben ist und alle bereits verfügbaren Informationen enthält.

Praxisbeispiel: Eine Bestellung kann nicht freigegeben werden

Ein Anwender meldet, dass eine Bestellung nicht freigegeben werden kann.

Der L1 Support prüft zunächst:

1. Welches SAP-System ist betroffen?
2. Welche Bestellnummer und Einkaufsorganisation sind betroffen?
3. Welche Fehlermeldung wird angezeigt?
4. Tritt das Problem nur bei einem Anwender oder bei mehreren Personen auf?
5. Funktioniert die Freigabe bei anderen Bestellungen?
6. Gibt es eine bekannte Lösung oder einen dokumentierten Workaround?
7. Wie dringend ist die Bestellung für den Geschäftsbetrieb?

Stellt sich heraus, dass lediglich ein bekannter Prozessschritt fehlt, kann L1 den Anwender direkt unterstützen.

Liegt dagegen möglicherweise eine fehlerhafte Freigabestrategie, Konfiguration oder Berechtigung vor, wird das Ticket mit allen gesammelten Informationen an den L2 Support weitergeleitet.

Woran wird ein guter SAP L1 Support gemessen?

Die Qualität des First-Level-Supports sollte nicht nur an der Anzahl geschlossener Tickets gemessen werden.

Geeignete Kennzahlen sind beispielsweise:

• First Contact Resolution Rate
• Anteil korrekt kategorisierter Tickets
• durchschnittliche Reaktionszeit
• Zeit bis zur Weiterleitung an L2 oder L3
• Vollständigkeit der Ticketdokumentation
• Anzahl falsch zugeordneter Tickets
• Kundenzufriedenheit nach Ticketabschluss
• Wiedereröffnungsrate gelöster Tickets
• Nutzung und Erweiterung der Knowledge Base

Eine hohe Erstlösungsquote ist hilfreich, darf jedoch nicht dazu führen, dass komplexe Probleme zu lange im L1 Support verbleiben. Entscheidend ist, dass jedes Ticket schnell und korrekt bearbeitet oder weitergeleitet wird.

Grenzen des SAP L1 Supports

Der L1 Support sollte normalerweise keine umfangreichen Konfigurationsänderungen, Codeanpassungen oder tiefgehenden Systemanalysen durchführen.

Zu seinen Grenzen gehören typischerweise:

• Änderungen an produktivem Customizing
• Anpassungen von ABAP-Code
• Entwicklung neuer Funktionen
• tiefgehende Schnittstellenanalysen
• komplexe Performance-Untersuchungen
• technische Architekturentscheidungen
• Änderungen an kritischen Berechtigungskonzepten
• Fehlerbehebung ohne dokumentiertes und freigegebenes Verfahren

Eine klare Abgrenzung schützt die Stabilität der SAP-Landschaft und verhindert, dass Änderungen ohne ausreichende Analyse, Tests oder Freigaben vorgenommen werden.

Welche Aufgaben übernimmt der SAP L2 Support?

Der SAP L2 Support bearbeitet funktionale und technische Probleme, die nicht durch standardisierte Anleitungen oder bekannte Lösungen im First-Level-Support gelöst werden können. Dafür sind vertiefte Kenntnisse der SAP-Module, Geschäftsprozesse, Systemkonfiguration und technischen Abhängigkeiten erforderlich.

Während der L1 Support vor allem Informationen sammelt und erste Lösungen bereitstellt, analysiert der L2 Support die eigentliche Ursache eines Incidents. Ziel ist es, das Problem nachhaltig zu beheben, einen geeigneten Workaround bereitzustellen oder das Ticket vollständig für eine Eskalation an den L3 Support vorzubereiten.

Zentrale Aufgaben des SAP L2 Supports

Typische Aufgaben im Second-Level-Support sind:

• funktionale und technische Analyse von Incidents
• Prüfung von Customizing und Systemeinstellungen
• Bearbeitung komplexerer Anwender- und Key-User-Anfragen
• Analyse von Stammdaten- und Prozessproblemen
• Untersuchung von Berechtigungsfehlern
• Bearbeitung von Service Requests
• Durchführung freigegebener Konfigurationsänderungen
• Analyse wiederkehrender Störungen
• Prüfung von Schnittstellen und Datenflüssen
• Unterstützung bei Tests und Fehlerreproduktion
• Dokumentation von Ursachen, Lösungen und Workarounds
• Eskalation komplexer Fälle an den L3 Support

Je nach Support-Modell kann der L2 Support zusätzlich kleinere Changes, Prozessanpassungen und die Pflege der Knowledge Base übernehmen.

Welche Probleme löst der SAP L2 Support?

Der L2 Support wird eingeschaltet, wenn eine Anfrage vertieftes Wissen zu einem SAP-Modul oder Geschäftsprozess erfordert.

Typische Beispiele sind:

• eine Bestellung wird aufgrund einer fehlerhaften Freigabestrategie nicht verarbeitet,
• eine Rechnung kann nur bei bestimmten Buchungskreisen nicht gebucht werden,
• ein Materialstamm enthält inkonsistente oder unvollständige Daten,
• eine Benutzerrolle ermöglicht nicht den erforderlichen Prozessschritt,
• ein Prozess funktioniert in einem Werk, aber nicht in einem anderen,
• eine Nachricht wird durch eine fehlerhafte Konfiguration ausgelöst,
• eine Schnittstelle verarbeitet einzelne Datensätze nicht korrekt,
• ein Report liefert abweichende Ergebnisse,
• ein wiederkehrender Incident benötigt eine Ursachenanalyse,
• eine kleinere funktionale Änderung muss umgesetzt und getestet werden.

Der L2 Support unterscheidet dabei zwischen einem einmaligen Fehler, einer fehlerhaften Konfiguration, einem Prozessproblem und einem Hinweis auf eine tieferliegende technische Ursache.

Funktionaler und technischer L2 Support

In vielen SAP-Organisationen ist der Second-Level-Support in funktionale und technische Bereiche unterteilt.

Funktionaler L2 Support

Funktionale SAP-Berater analysieren Probleme innerhalb von Geschäftsprozessen und Modulen.

Dazu gehören beispielsweise:

• SAP FI und CO
• SAP MM
• SAP SD
• SAP EWM
• SAP TM
• SAP PP und PP/DS
• SAP PM und Asset Management
• SAP Ariba
• SAP SuccessFactors

Sie prüfen Prozessabläufe, Stammdaten, Customizing und Abhängigkeiten zwischen Modulen.

Technischer L2 Support

Technische Experten untersuchen Probleme, die stärker mit Systemkomponenten, Berechtigungen, Datenbanken oder Integrationen verbunden sind.

Dazu gehören beispielsweise:

• SAP Basis
• SAP HANA
• Benutzer- und Rollenverwaltung
• technische Schnittstellen
• SAP Fiori und SAP Gateway
• Jobs und Hintergrundverarbeitung
• Dumps und Systemprotokolle
• Transport- und Release-Prozesse

Funktionaler und technischer L2 Support arbeiten häufig gemeinsam, da viele Incidents sowohl Prozess- als auch Systemursachen haben können.

Wie analysiert der L2 Support einen Incident?

Eine strukturierte Analyse umfasst typischerweise mehrere Schritte.

1. Ticket und Geschäftsauswirkung prüfen

Zunächst wird geprüft, ob alle Informationen vollständig sind und welche Geschäftsprozesse betroffen sind.

Dazu gehören:

• betroffene Systeme und Mandanten,
• Benutzer und Organisationseinheiten,
• Prozessschritte,
• Fehlermeldungen,
• Priorität und Dringlichkeit,
• verfügbare Workarounds,
• bereits durchgeführte Prüfungen.

2. Fehler reproduzieren

Wenn möglich, wird der Fehler in einer geeigneten Test- oder Qualitätssicherungsumgebung reproduziert.

Dadurch lässt sich feststellen:

• unter welchen Bedingungen das Problem auftritt,
• ob alle Anwender betroffen sind,
• ob bestimmte Stammdaten oder Prozessvarianten relevant sind,
• ob das Problem durch Konfiguration oder individuellen Code verursacht wird.

3. Systemdaten und Protokolle analysieren

Abhängig von der Art des Incidents prüft der L2 Support beispielsweise:

• Anwendungsprotokolle,
• Job-Logs,
• Dumps,
• Änderungsbelege,
• Schnittstellenmeldungen,
• Berechtigungsprüfungen,
• Customizing-Einstellungen,
• Stammdaten,
• Transporthistorie.

4. Ursache und Lösung bestimmen

Anschließend wird bewertet, ob:

• eine Konfiguration korrigiert werden kann,
• Stammdaten angepasst werden müssen,
• ein dokumentierter Workaround ausreicht,
• ein kleiner Change notwendig ist,
• das Ticket an den L3 Support eskaliert werden muss.

5. Lösung testen und dokumentieren

Vor einer Änderung im Produktivsystem sollte die Lösung entsprechend den internen Prozessen getestet und freigegeben werden.

Die Dokumentation sollte enthalten:

• Fehlerursache,
• durchgeführte Analyse,
• Lösung oder Workaround,
• betroffene Systeme,
• erforderliche Tests,
• mögliche Auswirkungen,
• Empfehlungen zur Vermeidung ähnlicher Probleme.

Praxisbeispiel: Eine Rechnung kann nicht gebucht werden

Ein Anwender meldet, dass eine Lieferantenrechnung nicht gebucht werden kann. Der L1 Support dokumentiert die Fehlermeldung, den Buchungskreis, den Beleg und die betroffenen Benutzer.

Der L2 Support prüft anschließend:

1. Tritt das Problem bei allen Rechnungen oder nur bei bestimmten Belegen auf?
2. Sind Kontierung, Steuerkennzeichen und Buchungsperiode korrekt?
3. Gibt es eine fehlerhafte Konfiguration im betroffenen Buchungskreis?
4. Sind Stammdaten des Lieferanten vollständig?
5. Liegt ein Berechtigungsproblem vor?
6. Wurde kürzlich ein Transport oder eine Konfigurationsänderung eingespielt?
7. Kann der Fehler in einem Testsystem reproduziert werden?

Liegt die Ursache in einer fehlerhaften Konfiguration oder in Stammdaten, kann der L2 Support die Korrektur koordinieren und testen.

Zeigt die Analyse dagegen, dass eine kundenspezifische Erweiterung den Buchungsprozess blockiert, wird das Ticket mit den Analyseergebnissen an den L3 Support eskaliert.

Wann eskaliert der L2 Support an L3?

Eine Eskalation an den Third-Level-Support ist erforderlich, wenn:

• der Fehler in kundenspezifischem Code liegt,
• eine neue technische Lösung entwickelt werden muss,
• eine komplexe Schnittstelle angepasst werden soll,
• eine tiefergehende Performance- oder Datenbankanalyse notwendig ist,
• mehrere Systeme und Integrationen betroffen sind,
• die Ursache trotz funktionaler und technischer Analyse nicht eindeutig ist,
• ein Standardfehler durch SAP geprüft werden muss,
• eine größere Änderung oder Erweiterung erforderlich ist.

Ein gut vorbereitetes L3-Ticket sollte bereits folgende Informationen enthalten:

• vollständige Fehlerbeschreibung,
• betroffene Systeme und Prozesse,
• Reproduktionsschritte,
• relevante Logs und Screenshots,
• Ergebnisse der bisherigen Analyse,
• bereits getestete Lösungsansätze,
• Bewertung der Geschäftsauswirkung,
• erwartetes Ergebnis.

Dadurch kann der L3 Support direkt mit der vertieften Analyse beginnen.

Welche Kompetenzen benötigt der SAP L2 Support?

L2-Mitarbeiter benötigen sowohl fachliche als auch analytische Kompetenzen.

Wichtig sind insbesondere:

• vertiefte Kenntnisse eines oder mehrerer SAP-Module,
• Verständnis durchgängiger Geschäftsprozesse,
• Erfahrung mit SAP Customizing,
• Fähigkeit zur strukturierten Fehleranalyse,
• Grundverständnis technischer Abhängigkeiten,
• Kenntnisse zu Integrationen und Datenflüssen,
• Erfahrung mit Tests und Transportprozessen,
• sichere Dokumentation von Lösungen,
• Verständnis von SLAs, Prioritäten und Eskalationen,
• klare Kommunikation mit Anwendern, Key Usern und technischen Teams.

Je komplexer die SAP-Landschaft ist, desto wichtiger wird die Zusammenarbeit zwischen verschiedenen Fachrichtungen.

Woran wird ein guter SAP L2 Support gemessen?

Geeignete Kennzahlen sind beispielsweise:

• durchschnittliche Bearbeitungs- und Lösungszeit,
• Anteil innerhalb des SLA gelöster Tickets,
• Anzahl wiederkehrender Incidents,
• Eskalationsquote an L3,
• Qualität der Ursachenanalysen,
• Wiedereröffnungsrate,
• Anzahl erfolgreich umgesetzter Service Requests,
• Entwicklung des Ticket-Backlogs,
• Qualität der Dokumentation,
• Zufriedenheit von Key Usern und Fachbereichen.

Eine niedrige Eskalationsquote ist nicht automatisch ein Qualitätsmerkmal. Komplexe Probleme sollten frühzeitig an L3 weitergegeben werden, wenn Entwicklung oder spezialisiertes Expertenwissen erforderlich sind.

Grenzen des SAP L2 Supports

Der L2 Support kann Konfigurationen prüfen und kleinere freigegebene Änderungen umsetzen. Umfangreiche Entwicklungen oder Architekturänderungen gehören jedoch normalerweise nicht zu seinem Verantwortungsbereich.

Typische Grenzen sind:

• größere ABAP-Entwicklungen,
• umfangreiche Fiori- oder BTP-Erweiterungen,
• tiefgehende Datenbank- und Performance-Analysen,
• komplexe Integrationsentwicklungen,
• grundlegende Architekturänderungen,
• größere Prozess-Redesigns,
• Änderungen mit hohem Risiko für produktive Systeme,
• Probleme, die eine Herstelleranalyse durch SAP erfordern.

Eine klare Abgrenzung zwischen L2, L3 und Change-Projekten verhindert, dass komplexe Anforderungen als einfache Support-Tickets behandelt werden.

Besprechen Sie Ihre aktuellen SAP Support Herausforderungen und erhalten Sie ein passendes L1–L3-Modell.
SAP Support besprechen

Welche Aufgaben übernimmt der SAP L3 Support?

Der SAP L3 Support bearbeitet besonders komplexe funktionale und technische Probleme, die weder im First-Level- noch im Second-Level-Support gelöst werden können. Dafür sind tiefgehende Kenntnisse in SAP-Entwicklung, Systemarchitektur, Integrationen und kundenspezifischen Erweiterungen erforderlich.

Der Third-Level-Support wird typischerweise eingebunden, wenn ein Fehler im Programmcode liegt, mehrere Systeme betroffen sind, eine technische Änderung notwendig ist oder die Ursache eines Incidents eine umfassende Analyse erfordert.

Zentrale Aufgaben des SAP L3 Supports

Zu den typischen Aufgaben gehören:

• Analyse komplexer und geschäftskritischer Incidents
• Fehlerbehebung in kundenspezifischem ABAP-Code
• Entwicklung und Anpassung von SAP-Erweiterungen
• Analyse und Weiterentwicklung von SAP-Fiori- und SAPUI5-Anwendungen
• Untersuchung komplexer Schnittstellen- und Integrationsprobleme
• Root Cause Analysis bei wiederkehrenden Störungen
• technische Performance- und Datenbankanalysen
• Unterstützung bei Patches, Releases und Upgrades
• Entwicklung von Workarounds und dauerhaften Lösungen
• Zusammenarbeit mit SAP und weiteren Technologieanbietern
• technische Dokumentation und Wissenstransfer
• Unterstützung bei Tests und kontrollierter Produktivsetzung

Je nach Organisationsmodell kann der L3 Support auch umfangreichere Service Requests, Changes und kleinere Entwicklungsprojekte übernehmen.

Welche Probleme löst der SAP L3 Support?

Der Third-Level-Support wird eingesetzt, wenn die Lösung spezialisiertes Entwicklungs- oder Architekturwissen erfordert.

Typische Beispiele sind:

• ein Fehler in einer kundenspezifischen ABAP-Entwicklung,
• eine Schnittstelle überträgt Daten unvollständig oder in falscher Reihenfolge,
• eine SAP-Fiori-Anwendung zeigt fehlerhafte Daten oder reagiert nicht,
• ein Geschäftsprozess wird durch einen BAdI, User Exit oder Enhancement blockiert,
• ein Performance-Problem betrifft mehrere Anwendungen oder Systeme,
• eine kundenspezifische Erweiterung funktioniert nach einem Update nicht mehr,
• ein Hintergrundjob bricht aufgrund komplexer technischer Abhängigkeiten ab,
• ein Fehler lässt sich nur durch Debugging und Codeanalyse reproduzieren,
• eine bestehende Integration muss technisch angepasst werden,
• ein SAP-Standardproblem muss mit dem Hersteller geklärt werden.

L3-Tickets können sowohl akute Incidents als auch strukturelle Probleme betreffen, die wiederholt auftreten und nicht allein durch Konfigurationsänderungen gelöst werden können.

SAP ABAP und kundenspezifische Entwicklungen

Viele Unternehmen betreiben individuelle SAP-Erweiterungen, die über Jahre hinweg entwickelt und an spezifische Geschäftsprozesse angepasst wurden.

Der L3 Support kann dabei folgende Aufgaben übernehmen:

• Analyse bestehender ABAP-Programme
• Debugging und Fehlerbehebung
• Optimierung von Code und Laufzeiten
• Modernisierung älterer Eigenentwicklungen
• Anpassung von Reports, Formularen und Workflows
• Entwicklung neuer Erweiterungen
• Unterstützung bei BAdIs, User Exits und Enhancement Spots
• Prüfung kundenspezifischer Entwicklungen vor Updates
• Dokumentation und Qualitätssicherung

Vor einer Änderung sollte geprüft werden, ob die Anforderung tatsächlich neuen Code benötigt oder durch SAP-Standardfunktionen, Konfiguration oder eine bestehende Erweiterung gelöst werden kann.

SAP Fiori, SAPUI5 und moderne Erweiterungen

Der L3 Support kann auch moderne SAP-Anwendungen und Benutzeroberflächen betreuen.

Dazu gehören:

• Analyse fehlerhafter SAP-Fiori-Apps
• Unterstützung bei SAPUI5
• Prüfung von OData Services
• Fehleranalyse in Frontend und Backend
• Anpassung von Launchpad-Konfigurationen
• Entwicklung kundenspezifischer Fiori-Anwendungen
• Unterstützung bei Erweiterungen auf SAP BTP
• Analyse von Authentifizierungs- und Berechtigungsproblemen
• Optimierung von Performance und Benutzerfreundlichkeit

Bei neuen Erweiterungen sollte berücksichtigt werden, wie sich die Lösung mit einer Clean-Core-Strategie und zukünftigen SAP-Releases vereinbaren lässt.

Unterstützung bei komplexen Integrationen

SAP-Landschaften sind häufig mit Produktionssystemen, E-Commerce-Plattformen, Banken, Logistikdienstleistern, Cloud-Anwendungen und weiteren Geschäftssystemen verbunden.

Der L3 Support analysiert unter anderem:

• fehlerhafte Nachrichten und Datenübertragungen,
• APIs und Web Services,
• IDocs und RFC-Verbindungen,
• OData-Schnittstellen,
• SAP Integration Suite,
• Middleware und Event-basierte Integrationen,
• Transformationen und Mapping-Logik,
• Authentifizierung und technische Zertifikate,
• Abhängigkeiten zwischen mehreren Systemen.

Dabei wird nicht nur die sichtbare Fehlermeldung untersucht. Ziel ist es, den betroffenen Datenfluss vollständig nachzuvollziehen und die eigentliche Ursache zu identifizieren.

Root Cause Analysis bei wiederkehrenden Incidents

Ein wichtiges Ziel des L3 Supports besteht darin, wiederkehrende Probleme dauerhaft zu reduzieren.

Eine Root Cause Analysis kann folgende Schritte umfassen:

1. relevante Incidents und technische Daten sammeln,
2. gemeinsame Muster und Abhängigkeiten identifizieren,
3. Logs, Code, Konfiguration und Datenflüsse untersuchen,
4. die eigentliche Fehlerursache bestimmen,
5. kurzfristige Workarounds und dauerhafte Lösungen bewerten,
6. die Lösung testen und kontrolliert implementieren,
7. Präventionsmaßnahmen und Monitoring definieren,
8. Ergebnisse in der Knowledge Base dokumentieren.

Dadurch wird verhindert, dass dieselbe Störung immer wieder nur kurzfristig behoben wird.

Praxisbeispiel: Kundenspezifische Preisfindung verursacht Fehler

Ein Unternehmen meldet, dass bestimmte Kundenaufträge mit einem falschen Preis verarbeitet werden. Der Fehler tritt nur bei einzelnen Produkt- und Kundengruppen auf.

Der L1 Support erfasst die betroffenen Aufträge, Kunden, Materialien und Fehlermeldungen.

Der L2 Support prüft:

• Konditionssätze,
• Preisfindungsschema,
• Stammdaten,
• Verkaufsorganisation,
• Customizing,
• Unterschiede zwischen korrekten und fehlerhaften Aufträgen.

Die Analyse zeigt, dass eine kundenspezifische Erweiterung zusätzliche Preisbedingungen verändert.

Der L3 Support übernimmt anschließend:

1. Analyse des betroffenen ABAP-Codes,
2. Reproduktion des Fehlers im Testsystem,
3. Identifikation der fehlerhaften Logik,
4. Entwicklung und Dokumentation der Korrektur,
5. Durchführung technischer Tests,
6. Unterstützung der Fachbereiche bei Integrationstests,
7. kontrollierte Überführung in das Produktivsystem,
8. Monitoring nach der Implementierung.

Nach der Lösung wird die Ursache dokumentiert, damit vergleichbare Probleme künftig schneller erkannt werden können.

Zusammenarbeit mit SAP

Nicht jeder komplexe Fehler liegt in einer kundenspezifischen Entwicklung. In manchen Fällen betrifft das Problem eine SAP-Standardfunktion, ein bekanntes Produktverhalten oder einen technischen Fehler, der durch SAP geprüft werden muss.

Der L3 Support kann dabei:

• technische Informationen und Reproduktionsschritte zusammenstellen,
• Logs, Dumps und Systemdaten vorbereiten,
• relevante SAP Notes recherchieren,
• eine Meldung bei SAP erstellen,
• die Kommunikation mit dem Hersteller koordinieren,
• Rückfragen beantworten,
• vorgeschlagene Korrekturen testen,
• die Implementierung der Lösung begleiten.

Eine vollständige technische Vorbereitung verkürzt häufig die Abstimmung mit SAP, da der Hersteller das Problem schneller nachvollziehen kann.

Welche Kompetenzen benötigt der SAP L3 Support?

L3-Experten benötigen tiefgehendes Spezialwissen in einem oder mehreren technischen oder funktionalen Bereichen.

Dazu können gehören:

• SAP ABAP und objektorientierte Entwicklung
• SAP Fiori und SAPUI5
• SAP BTP und Erweiterungsarchitekturen
• SAP Integration Suite
• SAP Basis und SAP HANA
• Datenbanken und Performance-Analyse
• Schnittstellen und APIs
• Berechtigungen und Security
• SAP-Module und durchgängige Geschäftsprozesse
• Debugging, Testing und Transportmanagement
• Systemarchitektur und Clean-Core-Prinzipien

Neben technischem Wissen ist die Fähigkeit wichtig, komplexe Probleme strukturiert zu erklären und eng mit L2-Teams, Fachbereichen, Entwicklern und externen Anbietern zusammenzuarbeiten.

Woran wird ein guter SAP L3 Support gemessen?

Geeignete Kennzahlen sind beispielsweise:

• Lösungszeit komplexer Incidents
• Anteil dauerhaft behobener Probleme
• Anzahl wiederkehrender Incidents
• Qualität der Root Cause Analysen
• Zeit bis zur Bereitstellung eines Workarounds
• Anzahl erfolgreicher Fehlerkorrekturen
• Fehlerquote nach Produktivsetzungen
• Qualität von Code und Dokumentation
• Einhaltung von Test- und Freigabeprozessen
• Zusammenarbeit mit L1, L2 und SAP
• Beitrag zur Reduzierung technischer Altlasten

Eine schnelle Codeänderung ist nicht automatisch eine gute Lösung. Entscheidend ist, dass die Änderung sicher, wartbar, dokumentiert und mit der zukünftigen SAP-Architektur vereinbar ist.

Grenzen des SAP L3 Supports

Nicht jede größere Anforderung sollte als Support-Ticket behandelt werden.

Ein separates Projekt oder ein formaler Change-Prozess ist häufig sinnvoll, wenn:

• ein vollständiger Geschäftsprozess neu gestaltet werden soll,
• umfangreiche Entwicklungen erforderlich sind,
• mehrere Systeme grundlegend verändert werden,
• eine neue SAP-Lösung eingeführt wird,
• größere Datenmigrationen notwendig sind,
• Architekturentscheidungen langfristige Auswirkungen haben,
• umfangreiche Tests und Schulungen erforderlich sind.

Die klare Trennung zwischen Incident, Service Request, Change und Projekt verhindert, dass strategische Vorhaben ohne ausreichende Planung im laufenden Support umgesetzt werden.

Wie funktioniert die Eskalation zwischen SAP Support Level 1, 2 und 3?

Ein SAP-Ticket wird eskaliert, wenn es innerhalb des aktuellen Support-Levels nicht gelöst werden kann, spezialisiertes Wissen benötigt wird oder die Geschäftsauswirkungen eine schnellere Bearbeitung erfordern.

Dabei gibt es zwei grundlegende Formen der Eskalation:

• funktionale Eskalation: Das Ticket wird an ein Support-Level mit tieferem Fach- oder Technikwissen weitergeleitet.
• hierarchische Eskalation: Verantwortliche Personen oder das Management werden eingebunden, weil ein kritischer Incident, eine SLA-Verletzung oder ein erhebliches Geschäftsrisiko besteht.

Ein klar definierter Eskalationsprozess verhindert, dass Tickets zu lange beim falschen Team verbleiben. Gleichzeitig stellt er sicher, dass kritische SAP-Störungen frühzeitig die notwendige Aufmerksamkeit erhalten.

Wann wird ein SAP-Ticket funktional eskaliert?

Eine funktionale Eskalation erfolgt, wenn die Bearbeitung Kompetenzen erfordert, die im aktuellen Support-Level nicht verfügbar sind.

Typische Eskalationswege sind:

• vom L1 Support an den L2 Support,
• vom L2 Support an den L3 Support,
• vom L3 Support an SAP oder einen weiteren Technologieanbieter.

Die Eskalation sollte nicht allein davon abhängen, wie lange ein Ticket bereits offen ist. Entscheidend sind die Ursache, die Komplexität und die erforderlichen Kompetenzen.

Eskalation vom L1 an den L2 Support

Der L1 Support eskaliert ein Ticket typischerweise an L2, wenn:

• keine bekannte oder dokumentierte Lösung verfügbar ist,
• vertiefte Kenntnisse eines SAP-Moduls benötigt werden,
• Customizing, Stammdaten oder Berechtigungen geprüft werden müssen,
• der Fehler nicht eindeutig als Bedienungsproblem identifiziert werden kann,
• der Incident wiederholt auftritt,
• eine fachliche oder technische Ursachenanalyse erforderlich ist,
• ein Service Request eine Konfigurationsänderung benötigt,
• das Ticket möglicherweise nicht innerhalb der vereinbarten Zeit gelöst werden kann.

Vor der Eskalation sollte der L1 Support alle grundlegenden Informationen erfassen. Dazu gehören die Fehlermeldung, betroffene Benutzer, Systeme, Prozesse, Geschäftsauswirkungen und bereits durchgeführte Lösungsversuche.

Eskalation vom L2 an den L3 Support

Der L2 Support eskaliert ein Ticket an L3, wenn:

• kundenspezifischer Code analysiert oder geändert werden muss,
• eine komplexe Schnittstelle betroffen ist,
• die Ursache mehrere Systeme oder technische Komponenten umfasst,
• eine tiefgehende Performance-Analyse notwendig ist,
• eine Erweiterung entwickelt werden muss,
• der Fehler trotz funktionaler und technischer Analyse nicht gelöst werden kann,
• eine SAP-Standardfunktion möglicherweise fehlerhaft ist,
• die Behebung ein spezialisiertes Entwicklungs- oder Architekturwissen erfordert.

Die bisherigen Analyseergebnisse sollten vollständig dokumentiert werden. Dadurch wird verhindert, dass der L3 Support bereits ausgeführte Prüfungen wiederholen muss.

Eskalation vom L3 Support an SAP

Eine Weiterleitung an SAP kann erforderlich sein, wenn:

• ein Fehler im SAP-Standard vermutet wird,
• eine relevante SAP Note keine ausreichende Lösung bietet,
• ein Problem nach einem Patch oder Upgrade auftritt,
• die Ursache nur durch SAP selbst analysiert werden kann,
• ein produktspezifisches Verhalten bestätigt werden muss,
• ein Hotfix oder eine Korrektur durch den Hersteller notwendig ist.

Für eine effektive Bearbeitung sollten Reproduktionsschritte, Logs, Dumps, Systeminformationen und Ergebnisse der bisherigen Analyse bereitgestellt werden.

Je vollständiger die technische Dokumentation ist, desto schneller kann SAP das Problem nachvollziehen.

Was ist eine hierarchische Eskalation?

Bei einer hierarchischen Eskalation wird ein Ticket nicht zwingend an ein technisch höheres Support-Level weitergegeben. Stattdessen werden zusätzliche Verantwortliche eingebunden.

Dazu können gehören:

• Service Manager,
• Incident Manager,
• Support Team Lead,
• IT-Leitung,
• Prozessverantwortliche,
• Fachbereichsleitung,
• Management des Support-Anbieters,
• SAP oder weitere externe Partner.

Eine hierarchische Eskalation ist insbesondere dann sinnvoll, wenn Entscheidungen, zusätzliche Ressourcen oder eine übergreifende Koordination notwendig sind.

Typische Gründe für eine hierarchische Eskalation

• Ein geschäftskritischer Prozess steht still.
• Mehrere Standorte oder Gesellschaften sind betroffen.
• Eine SLA-Verletzung droht oder ist bereits eingetreten.
• Es gibt keinen akzeptablen Workaround.
• Die Lösung hängt von mehreren Teams oder Dienstleistern ab.
• Ein Incident verursacht erhebliche finanzielle oder operative Risiken.
• Ein Ticket bleibt trotz wiederholter Analyse ungelöst.
• Eine Entscheidung über Risiken, Kosten oder Prioritäten ist erforderlich.
• Es bestehen Kommunikationsprobleme zwischen den Beteiligten.

Die hierarchische Eskalation soll nicht nach Schuldigen suchen. Ihr Ziel ist es, Entscheidungen zu beschleunigen, Verantwortlichkeiten zu klären und notwendige Ressourcen bereitzustellen.

Technische und geschäftliche Priorität unterscheiden

Die technische Komplexität eines Incidents ist nicht automatisch identisch mit seiner geschäftlichen Priorität.

Ein technisch einfacher Fehler kann sehr kritisch sein, wenn er beispielsweise die Fakturierung, Produktion oder Auslieferung vollständig blockiert. Umgekehrt kann ein technisch komplexer Fehler eine niedrigere Priorität haben, wenn nur ein selten genutzter Prozess betroffen ist und ein Workaround besteht.

Die Priorität sollte deshalb anhand mehrerer Kriterien bestimmt werden:

• Anzahl betroffener Anwender,
• betroffene Standorte oder Gesellschaften,
• Bedeutung des Geschäftsprozesses,
• Umfang der Prozessunterbrechung,
• Verfügbarkeit eines Workarounds,
• finanzielle und regulatorische Auswirkungen,
• zeitliche Abhängigkeiten,
• Risiko für Kunden, Lieferanten oder Produktion.

Beispiel einer Eskalationsmatrix

Welche Informationen müssen bei einer Eskalation übergeben werden?

Eine Eskalation ist nur dann effektiv, wenn das übernehmende Team alle relevanten Informationen erhält.

Ein vollständig vorbereitetes Ticket sollte enthalten:

• eindeutige Beschreibung des Problems,
• betroffene Systeme und Mandanten,
• betroffenes SAP-Modul und Geschäftsprozess,
• Benutzer, Standorte oder Gesellschaften,
• genaue Fehlermeldung,
• Zeitpunkt und Häufigkeit des Auftretens,
• Schritte zur Reproduktion,
• Screenshots, Logs oder Dumps,
• Geschäftsauswirkung,
• aktuelle Priorität,
• vorhandener Workaround,
• bereits durchgeführte Analysen,
• getestete Lösungsansätze,
• letzte Änderungen oder Transporte,
• verantwortliche Ansprechpartner,
• erwartetes Ergebnis.

Unvollständige Eskalationen führen häufig zu Rückfragen und verlängern die Lösungszeit. Deshalb sollte die Qualität der Ticketübergabe als Teil des Support-Prozesses gemessen werden.

Wie läuft die Eskalation eines kritischen SAP Incidents ab?

Bei einem kritischen Incident sollte der Eskalationsprozess unmittelbar nach der Priorisierung gestartet werden.

Ein möglicher Ablauf ist:

1. Der L1 Support nimmt die Störung auf und prüft die Geschäftsauswirkungen.
2. Das Ticket wird als kritisch priorisiert.
3. L2- und gegebenenfalls L3-Experten werden sofort eingebunden.
4. Der Incident Manager koordiniert Teams, Kommunikation und nächste Schritte.
5. Ein kurzfristiger Workaround wird geprüft.
6. Betroffene Fachbereiche und Verantwortliche erhalten regelmäßige Statusupdates.
7. Falls notwendig, werden SAP und weitere Anbieter eingebunden.
8. Nach der Wiederherstellung des Betriebs wird die dauerhafte Lösung umgesetzt.
9. Abschließend erfolgt eine Root Cause Analysis.
10. Maßnahmen zur Vermeidung ähnlicher Incidents werden dokumentiert.

Während eines Major Incidents sollte es einen zentralen Kommunikationskanal und einen eindeutig verantwortlichen Incident Manager geben. So werden widersprüchliche Informationen und parallele, unkoordinierte Änderungen vermieden.

Praxisbeispiel: Die Fakturierung ist vollständig blockiert

Am Monatsende können in einem SAP-System keine Kundenrechnungen mehr erstellt werden. Mehrere Gesellschaften sind betroffen, und es gibt keinen Workaround.

Der Incident wird aufgrund der hohen Geschäftsauswirkung als kritisch priorisiert.

Der Eskalationsprozess kann folgendermaßen aussehen:

• L1 dokumentiert die betroffenen Benutzer, Systeme und Fehlermeldungen.
• L2 prüft Customizing, Stammdaten, Job-Protokolle und aktuelle Transporte.
• L3 analysiert kundenspezifischen Code und technische Abhängigkeiten.
• Der Incident Manager koordiniert die Kommunikation mit Finance, IT und Management.
• Falls ein Fehler im SAP-Standard vermutet wird, eröffnet L3 eine Meldung bei SAP.
• Sobald ein sicherer Workaround verfügbar ist, wird der Geschäftsbetrieb wiederhergestellt.
• Nach der endgültigen Lösung wird eine Root Cause Analysis durchgeführt.

Das Beispiel zeigt, dass ein kritischer Incident häufig nicht linear von L1 über L2 zu L3 bearbeitet wird. Bei hoher Dringlichkeit können mehrere Support-Level gleichzeitig arbeiten, während die hierarchische Eskalation parallel erfolgt.

Wie lassen sich unnötige Eskalationen vermeiden?

Nicht jede Eskalation ist ein Hinweis auf einen schlechten Support-Prozess. Komplexe Probleme müssen an spezialisierte Experten weitergegeben werden.

Zu viele unnötige Eskalationen können jedoch auf strukturelle Schwächen hindeuten.

Mögliche Gegenmaßnahmen sind:

• klare Zuständigkeiten für jedes Support-Level,
• definierte Ticketkategorien,
• aktuelle Support-Dokumentation,
• gut gepflegte Knowledge Base,
• regelmäßige Schulungen für L1 und L2,
• standardisierte Übergabe-Checklisten,
• Analyse häufig wiederkehrender Ticketarten,
• automatisierte Weiterleitung anhand definierter Regeln,
• regelmäßige Service Reviews,
• kontinuierlicher Wissenstransfer zwischen L3, L2 und L1.

Wenn eine Lösung wiederholt durch L2 oder L3 bereitgestellt wird, sollte geprüft werden, ob sie dokumentiert und künftig bereits durch ein niedrigeres Support-Level angewendet werden kann.

So verbessert sich die First Contact Resolution Rate, während spezialisierte SAP-Experten mehr Zeit für komplexe Aufgaben erhalten.

Welche Rolle spielen Prioritäten, SLAs und Reaktionszeiten im SAP Support?

Prioritäten und Service Level Agreements bestimmen, wie schnell ein SAP-Ticket angenommen, analysiert, eskaliert und bearbeitet werden muss.

Die Priorität eines Tickets sollte sich nicht nur nach der technischen Komplexität richten. Entscheidend ist vor allem, welche Auswirkungen die Störung auf den Geschäftsbetrieb hat. Ein technisch kleiner Fehler kann höchste Priorität erhalten, wenn er beispielsweise Produktion, Fakturierung oder Warenausgang vollständig blockiert.

Ein SLA definiert anschließend, welche Leistungen der SAP Support innerhalb welcher Zeiten erbringen muss. Dazu gehören typischerweise Servicezeiten, Reaktionszeiten, Eskalationswege, Kommunikationspflichten und gegebenenfalls Wiederherstellungs- oder Lösungsziele.

Was ist ein SLA im SAP Support?

Ein Service Level Agreement, kurz SLA, ist eine verbindliche Vereinbarung zwischen dem Unternehmen und dem internen oder externen SAP Support.

Es legt unter anderem fest:

• 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 ein Incident eskaliert werden muss,
• wie häufig Statusupdates erfolgen,
• welche Rollen und Ansprechpartner verantwortlich sind,
• wie die Servicequalität gemessen wird,
• welche Leistungen nicht zum vereinbarten Umfang gehören.

Ein SLA sollte eindeutig formuliert sein. Allgemeine Aussagen wie „schnelle Bearbeitung“ oder „hohe Verfügbarkeit“ reichen nicht aus, wenn keine messbaren Kriterien definiert werden.

Was ist der Unterschied zwischen Reaktionszeit, Wiederherstellungszeit und Lösungszeit?

Diese Begriffe werden im SAP Support häufig verwechselt.

Reaktionszeit

Die Reaktionszeit beschreibt den Zeitraum zwischen dem Eingang eines Tickets und der ersten qualifizierten Reaktion des Support-Teams.

Eine qualifizierte Reaktion bedeutet mehr als eine automatische Eingangsbestätigung. Das Ticket sollte angenommen, priorisiert und einem verantwortlichen Bearbeiter zugeordnet worden sein.

Zeit bis zur Wiederherstellung

Die Wiederherstellungszeit beschreibt, wie lange es dauert, den betroffenen Geschäftsprozess oder Service wieder nutzbar zu machen.

Dies kann durch eine dauerhafte Lösung oder zunächst durch einen sicheren Workaround erfolgen.

Lösungszeit

Die Lösungszeit bezeichnet den Zeitraum bis zur vollständigen und dauerhaften Behebung der Ursache.

Bei komplexen Incidents kann der Geschäftsbetrieb bereits wiederhergestellt sein, obwohl die endgültige Fehlerkorrektur noch entwickelt, getestet und implementiert werden muss.

Beispiel

Ein Produktionsprozess fällt aufgrund eines Fehlers in einer kundenspezifischen Erweiterung aus.

• Nach 15 Minuten bestätigt der Support die Übernahme des Incidents: Reaktionszeit
• Nach zwei Stunden wird ein Workaround aktiviert und die Produktion läuft wieder: Wiederherstellungszeit
• Drei Tage später wird eine getestete Codekorrektur produktiv gesetzt: Lösungszeit

Diese drei Zeitpunkte sollten im Reporting getrennt betrachtet werden.

Wie werden SAP-Tickets priorisiert?

Die Ticketpriorität ergibt sich aus einer Kombination von Auswirkung und Dringlichkeit.

Die Auswirkung beschreibt, wie stark das Unternehmen betroffen ist. Die Dringlichkeit zeigt, wie schnell eine Lösung benötigt wird.

Wichtige Bewertungskriterien sind:

• Anzahl betroffener Anwender
• Anzahl betroffener Standorte oder Gesellschaften
• Bedeutung des Geschäftsprozesses
• vollständiger oder teilweiser Prozessausfall
• Verfügbarkeit eines Workarounds
• finanzielle Auswirkungen
• Auswirkungen auf Kunden oder Lieferanten
• regulatorische oder gesetzliche Risiken
• Abhängigkeit von Monats-, Quartals- oder Jahresabschlüssen
• Auswirkungen auf Produktion, Logistik oder Auslieferung
• zeitkritische Geschäftsfristen

Die Priorität sollte nicht allein durch den meldenden Anwender festgelegt werden. Sie sollte anhand einer vereinbarten Matrix geprüft und bei veränderten Geschäftsauswirkungen angepasst werden können.

Beispielhafte Prioritätsmatrix für SAP Support

Die konkrete Bezeichnung und Ausgestaltung kann je nach Unternehmen variieren. Häufig werden vier Prioritätsstufen verwendet.

Diese Tabelle ist keine allgemeingültige SAP-Vorgabe. Unternehmen sollten ihre Prioritäten an die eigenen Prozesse, Risiken und Betriebszeiten anpassen.

Wann ist ein SAP Incident wirklich kritisch?

Ein Ticket sollte normalerweise nur dann als P1 oder kritisch eingestuft werden, wenn mehrere Bedingungen erfüllt sind:

• Ein geschäftskritischer Prozess ist vollständig unterbrochen.
• Viele Anwender, ein ganzer Standort oder mehrere Gesellschaften sind betroffen.
• Es gibt keinen akzeptablen Workaround.
• Die Auswirkungen sind unmittelbar und erheblich.
• Eine sofortige Bearbeitung ist erforderlich, um größere Schäden zu vermeiden.

Ein einzelner Anwender mit einem dringenden Problem hat nicht automatisch einen kritischen Incident. Die Priorität muss sich an der gesamten Geschäftsauswirkung orientieren.

Beispielhafte Reaktionszeiten nach Priorität

Die tatsächlichen Werte müssen individuell im SLA vereinbart werden. Eine beispielhafte Struktur kann folgendermaßen aussehen:

Solche Zeiten sind nur Beispiele. Ein SLA sollte berücksichtigen:

• vereinbarte Support-Zeiten,
• Zeitzonen,
• Wochenenden und Feiertage,
• 24/7-Bereitschaft,
• kritische Geschäftsperioden,
• Verfügbarkeit interner Ansprechpartner,
• Abhängigkeiten von SAP oder Drittanbietern.

Warum sollte ein SLA nicht nur Lösungszeiten versprechen?

Eine verbindliche Lösungszeit lässt sich bei komplexen SAP-Problemen nicht immer zuverlässig vorhersagen.

Die tatsächliche Dauer kann davon abhängen:

• ob der Fehler reproduzierbar ist,
• ob mehrere Systeme beteiligt sind,
• ob kundenspezifischer Code betroffen ist,
• ob Änderungen getestet werden müssen,
• ob ein Wartungsfenster erforderlich ist,
• ob SAP oder ein weiterer Anbieter eingebunden werden muss,
• ob der Kunde Informationen oder Freigaben bereitstellen muss.

Deshalb sind messbare Reaktions-, Eskalations- und Kommunikationszeiten häufig realistischer als eine pauschale Garantie für die vollständige Lösung.

Für kritische Prozesse kann zusätzlich ein Ziel für die Wiederherstellung des Betriebs vereinbart werden.

Welche Servicezeiten sollte ein SAP SLA abdecken?

Das passende Servicefenster hängt davon ab, wann die unterstützten Geschäftsprozesse aktiv sind.

Mögliche Modelle sind:

Support während regulärer Geschäftszeiten

Geeignet für Unternehmen, deren kritische Prozesse hauptsächlich an Werktagen innerhalb eines Landes stattfinden.

Erweiterte Servicezeiten

Geeignet für Unternehmen mit längeren Produktions-, Logistik- oder Vertriebszeiten.

Beispielsweise kann der Support morgens früher beginnen und bis in den Abend verfügbar sein.

Bereitschaft für kritische Incidents

Außerhalb der regulären Servicezeiten werden nur P1- oder P2-Incidents bearbeitet.

Dieses Modell kann wirtschaftlicher sein als eine vollständige Rund-um-die-Uhr-Besetzung.

24/7 SAP Support

Geeignet für internationale Organisationen, kontinuierliche Produktion, globale Logistik oder andere Prozesse, bei denen ein Ausfall zu jeder Tageszeit erhebliche Auswirkungen haben kann.

Ein 24/7-Modell sollte jedoch nicht automatisch für sämtliche Systeme und Ticketarten gelten. Häufig ist es sinnvoller, die Rund-um-die-Uhr-Abdeckung auf klar definierte produktive Systeme und kritische Incidents zu begrenzen.

Welche Leistungen sollten im SLA klar abgegrenzt werden?

Neben den enthaltenen Leistungen sollte das SLA auch Ausschlüsse und Abhängigkeiten beschreiben.

Klar definiert werden sollten:

• unterstützte Systeme, Mandanten und Module,
• produktive und nicht produktive Umgebungen,
• enthaltene Support-Level,
• Incident und Problem Management,
• Service Requests,
• kleinere Changes,
• Entwicklungen und Erweiterungen,
• Schnittstellen zu Drittanbietern,
• Support für kundenspezifischen Code,
• Test- und Transportleistungen,
• Bereitschaft und 24/7-Abdeckung,
• Pflichten des Kunden,
• notwendige Zugänge und Dokumentation,
• Abhängigkeiten von SAP und weiteren Anbietern.

Eine unklare Abgrenzung führt häufig zu Diskussionen darüber, ob eine Anforderung zum Support, zu einem Change Request oder zu einem separaten Projekt gehört.

Welche Pflichten hat der Kunde im SLA?

Die Einhaltung eines SLA hängt nicht nur vom Support-Anbieter ab. Auch das Unternehmen muss bestimmte Voraussetzungen erfüllen.

Typische Kundenpflichten sind:

• vollständige und korrekte Ticketinformationen bereitstellen,
• Zugänge zu den betroffenen Systemen ermöglichen,
• verantwortliche Ansprechpartner benennen,
• Rückfragen zeitnah beantworten,
• Tests und fachliche Freigaben durchführen,
• Wartungsfenster abstimmen,
• Änderungen dokumentieren,
• Drittanbieter bei Bedarf einbinden,
• Prioritäten anhand der vereinbarten Kriterien vergeben.

Wenn wichtige Informationen, Zugänge oder Freigaben fehlen, kann die Lösungszeit nicht vollständig durch den Support-Anbieter kontrolliert werden.

Wie wird die Einhaltung von SAP SLAs gemessen?

Die Servicequalität sollte regelmäßig anhand transparenter Kennzahlen überprüft werden.

Wichtige SLA-Kennzahlen sind:

• Anteil innerhalb der Reaktionszeit angenommener Tickets
• Anteil innerhalb der Zielzeit wiederhergestellter Services
• Anzahl drohender oder tatsächlicher SLA-Verletzungen
• Lösungszeit nach Priorität
• durchschnittliche Wartezeit auf Kundeninformationen
• Anzahl eskalierter Tickets
• Wiedereröffnungsrate
• Ticket-Backlog nach Alter und Priorität
• Häufigkeit von Major Incidents
• Qualität und Regelmäßigkeit der Statuskommunikation

Die Kennzahlen sollten nicht isoliert betrachtet werden. Eine hohe SLA-Erfüllung kann irreführend sein, wenn Tickets falsch priorisiert, vorschnell geschlossen oder regelmäßig wiedereröffnet werden.

Was passiert bei einer drohenden SLA-Verletzung?

Eine drohende SLA-Verletzung sollte frühzeitig erkannt und nicht erst nach Ablauf der Frist gemeldet werden.

Ein sinnvoller Prozess umfasst:

1. automatische Warnung vor Ablauf der Zielzeit,
2. Prüfung des aktuellen Bearbeitungsstands,
3. funktionale Eskalation an zusätzliche Experten,
4. Information des Service oder Incident Managers,
5. Bewertung eines möglichen Workarounds,
6. transparente Kommunikation mit dem Kunden,
7. Dokumentation von Ursache und nächsten Schritten.

Nach einer tatsächlichen SLA-Verletzung sollte analysiert werden, warum das Ziel nicht erreicht wurde.

Mögliche Ursachen sind:

• falsche Priorisierung,
• unvollständige Ticketinformationen,
• fehlende technische Kompetenzen,
• unklare Verantwortlichkeiten,
• verspätete Eskalation,
• Abhängigkeit von Drittanbietern,
• fehlende Zugänge,
• unzureichende Dokumentation,
• unrealistisch definierte Service Levels.

Ziel der Analyse sollte nicht nur die Erklärung eines einzelnen Verstoßes sein. Sie sollte dazu beitragen, vergleichbare Verzögerungen künftig zu vermeiden.

Praxisbeispiel: Unterschiedliche Prioritäten bei derselben Fehlermeldung

Zwei Anwender melden dieselbe Fehlermeldung beim Erstellen eines Lieferbelegs.

Im ersten Fall ist nur ein einzelner Testauftrag betroffen. Ein alternativer Prozess ist verfügbar. Das Ticket kann als P3 eingestuft werden.

Im zweiten Fall können mehrere Werke keine Lieferungen erstellen. Der Warenausgang steht still, und Kundenaufträge können nicht ausgeliefert werden. Es gibt keinen Workaround. Das Ticket kann als P1 eingestuft werden.

Die technische Fehlermeldung ist in beiden Fällen identisch. Die Geschäftsauswirkung und damit die Priorität sind jedoch grundlegend verschieden.

Dieses Beispiel zeigt, warum Priorisierung im SAP Support immer den geschäftlichen Kontext berücksichtigen muss.

Welches SAP Support Level sollte intern bleiben und was kann ausgelagert werden?

Unternehmen müssen nicht den gesamten SAP Support intern aufbauen oder vollständig an einen externen Dienstleister übertragen. In der Praxis ist häufig ein hybrides Modell sinnvoll: Interne Mitarbeiter übernehmen Aufgaben, die Nähe zu Anwendern, Geschäftsprozessen und Unternehmensentscheidungen erfordern, während externe SAP-Spezialisten zusätzliche Kapazitäten und tiefgehendes Fachwissen bereitstellen.

Welche Support-Level intern bleiben sollten, hängt insbesondere von der Größe des SAP-Teams, der Komplexität der Systemlandschaft, dem Ticketvolumen und den benötigten Servicezeiten ab.

Typische Aufteilung zwischen internem Team und externem SAP Support

Diese Aufteilung ist keine allgemeingültige Vorgabe. Ein international tätiges Unternehmen mit einem großen SAP Center of Excellence kann auch L2 und L3 weitgehend intern abdecken. Ein mittelständisches Unternehmen verfügt dagegen möglicherweise nur über Key User und einen internen IT-Koordinator und lagert alle drei Support-Level teilweise oder vollständig aus.

Wann sollte der L1 Support intern bleiben?

Ein interner L1 Support ist besonders sinnvoll, wenn:

• viele Anfragen unternehmensspezifische Abläufe betreffen,
• eine direkte Kommunikation mit Anwendern wichtig ist,
• interne Sprachen, Standorte oder Arbeitsweisen berücksichtigt werden müssen,
• das Unternehmen über gut geschulte Key User verfügt,
• sensible Berechtigungs- oder Personaldaten betroffen sind,
• ein bestehender interner Service Desk mehrere Anwendungen betreut.

Interne L1-Mitarbeiter kennen häufig die organisatorischen Besonderheiten besser als ein externer Anbieter. Sie können schneller erkennen, ob tatsächlich eine SAP-Störung vorliegt oder ob ein internes Verfahren, fehlende Stammdaten oder eine organisatorische Entscheidung das Problem verursacht.

Ein externer Anbieter kann den L1 Support dennoch ergänzen, beispielsweise außerhalb der regulären Geschäftszeiten, bei hohem Ticketvolumen oder für klar standardisierte Anfragen.

Wann lohnt sich externer L2 Support?

Der L2 Support wird häufig teilweise oder vollständig ausgelagert, weil Unternehmen nicht für jedes SAP-Modul dauerhaft eigene Spezialisten beschäftigen können.

Externer L2 Support ist besonders relevant, wenn:

• internes Modulwissen fehlt,
• einzelne Experten stark ausgelastet sind,
• das Ticket-Backlog wächst,
• mehrere SAP-Module unterstützt werden müssen,
• zusätzliche Kapazität für Releases oder kritische Geschäftsphasen benötigt wird,
• internationale Servicezeiten abgedeckt werden sollen,
• wiederkehrende Incidents nicht nachhaltig gelöst werden,
• interne Mitarbeiter sich stärker auf strategische Aufgaben konzentrieren sollen.

Ein hybrides Modell kann beispielsweise vorsehen, dass interne Process Owner und Key User die geschäftlichen Anforderungen steuern, während externe SAP-Berater die funktionale Analyse, das Customizing und die technische Fehlerbehebung übernehmen.

Wann sollte der L3 Support extern unterstützt werden?

L3-Kompetenzen werden häufig nur für bestimmte Technologien oder komplexe Problemfälle benötigt. Der dauerhafte interne Aufbau aller erforderlichen Rollen ist deshalb nicht für jedes Unternehmen wirtschaftlich.

Externe L3-Spezialisten können unter anderem unterstützen bei:

• ABAP-Entwicklung und Codeanalyse,
• SAP Fiori und SAPUI5,
• SAP BTP und Erweiterungsarchitekturen,
• Schnittstellen und SAP Integration Suite,
• SAP Basis und SAP HANA,
• Performance-Optimierung,
• komplexen Berechtigungskonzepten,
• Root Cause Analysen,
• technischen Problemen nach Releases oder Upgrades.

Für geschäftskritische Eigenentwicklungen sollte dennoch sichergestellt sein, dass das Unternehmen Zugriff auf Dokumentation, Quellcode, technische Entscheidungen und notwendiges Systemwissen behält.

Welche Aufgaben sollten beim Unternehmen bleiben?

Auch bei einem weitgehend ausgelagerten SAP Support sollten bestimmte Verantwortlichkeiten normalerweise intern bleiben.

Dazu gehören:

• Festlegung geschäftlicher Prioritäten,
• Entscheidung über kritische Prozesse,
• Freigabe produktiver Änderungen,
• Verantwortung für Governance und Compliance,
• Benennung von Process Ownern,
• fachliche Abnahme von Lösungen,
• Steuerung des Support-Anbieters,
• Kontrolle von SLAs und Servicequalität,
• Entscheidung über größere Changes und Projekte.

Ein externer SAP Support kann technische und funktionale Verantwortung übernehmen. Die Verantwortung für Geschäftsziele, Risiken und strategische Entscheidungen verbleibt jedoch beim Unternehmen.

Drei mögliche SAP Support Modelle

1. Interner L1 Support mit externem L2 und L3

Dieses Modell eignet sich für Unternehmen mit einem eigenen Service Desk oder gut etablierten Key-User-Strukturen.

Interne Teams übernehmen Anwenderkommunikation und Erstqualifizierung. Externe Spezialisten bearbeiten funktionale und technische Probleme.

2. Gemeinsames Support-Team

Interne und externe Mitarbeiter arbeiten in einem integrierten Team mit gemeinsamen Prozessen, Ticket-Systemen und SLAs.

Dieses Modell bietet Nähe zum Geschäft und gleichzeitig Zugang zu zusätzlichen Kompetenzen.

3. Weitgehend ausgelagerter SAP Support

Ein externer Dienstleister übernimmt L1, L2 und L3 sowie Teile des Service Managements.

Intern bleiben insbesondere Governance, Priorisierung, fachliche Entscheidungen und die Kontrolle der Servicequalität.

Dieses Modell kann für Unternehmen sinnvoll sein, die kein vollständiges internes SAP Support Team aufbauen möchten oder Support über mehrere Länder und Zeitzonen benötigen.

Nach welchen Kriterien sollte das Modell ausgewählt werden?

Vor der Entscheidung sollten Unternehmen folgende Fragen beantworten:

• Wie viele Tickets entstehen pro Monat?
• Welche SAP-Systeme und Module müssen unterstützt werden?
• Welche Kompetenzen sind intern bereits vorhanden?
• Welche Prozesse sind geschäftskritisch?
• Welche Servicezeiten werden benötigt?
• Wie stark schwankt der Unterstützungsbedarf?
• Welche Aufgaben erfordern internes Unternehmenswissen?
• Welche Spezialisten werden nur gelegentlich benötigt?
• Wer trägt die Verantwortung für Priorisierung und Freigaben?
• Wie wird Wissen dokumentiert und im Unternehmen gesichert?

Das beste Modell ist nicht automatisch das mit dem höchsten Auslagerungsgrad. Entscheidend ist eine klare Rollenverteilung zwischen internen Teams und externem SAP Support.

Empfehlung für viele Unternehmen

Für viele mittelständische und größere Unternehmen ist ein hybrides Modell sinnvoll:

• L1 bleibt intern oder wird gemeinsam betrieben.
• L2 wird durch externe Modul- und Prozessexperten ergänzt.
• L3 wird durch spezialisierte Entwickler und Architekten abgedeckt.
• Geschäftliche Priorisierung und Governance bleiben beim Unternehmen.

So verbindet das Unternehmen internes Prozesswissen mit flexibel verfügbaren SAP-Kompetenzen.

Wie läuft ein SAP Support Ticket in der Praxis ab?

Ein SAP Support Ticket durchläuft normalerweise mehrere Schritte: von der Meldung und Priorisierung über die funktionale oder technische Analyse bis zur Lösung und Dokumentation.

Nicht jedes Ticket muss alle drei Support-Level durchlaufen. Einfache Anfragen können direkt im L1 Support gelöst werden. Komplexere Incidents werden an L2 oder L3 eskaliert. Bei geschäftskritischen Störungen können mehrere Support-Level gleichzeitig eingebunden werden.

1. Anwender meldet das Problem

Der Anwender erstellt ein Ticket über das vereinbarte Support-Portal, per E-Mail, telefonisch oder über einen internen Service Desk.

Die Meldung sollte möglichst enthalten:

• betroffenen Geschäftsprozess,
• SAP-System und Mandant,
• Transaktion oder Anwendung,
• genaue Fehlermeldung,
• Zeitpunkt des Auftretens,
• betroffene Benutzer,
• Screenshots oder relevante Belege,
• Beschreibung der Geschäftsauswirkung.

Je vollständiger die Meldung ist, desto schneller kann der Support mit der Analyse beginnen.

2. L1 Support erfasst und priorisiert das Ticket

Der First-Level-Support prüft, ob alle notwendigen Informationen vorhanden sind, kategorisiert das Ticket und bewertet seine Dringlichkeit.

Dabei wird unter anderem geklärt:

• Handelt es sich um einen Incident, Service Request oder eine Anwenderfrage?
• Wie viele Benutzer und Standorte sind betroffen?
• Ist ein geschäftskritischer Prozess eingeschränkt?
• Gibt es einen Workaround?
• Welches SAP-Modul oder Support-Team ist zuständig?

Anschließend wird das Ticket entsprechend der vereinbarten Prioritätsmatrix eingestuft.

3. L1 prüft bekannte Lösungen

Der L1 Support durchsucht die Knowledge Base, vorhandene Dokumentation und bekannte Fehlermuster.

Kann das Problem mit einer standardisierten Anleitung gelöst werden, informiert L1 den Anwender und dokumentiert die Lösung.

Ist eine vertiefte Analyse erforderlich, wird das Ticket mit allen gesammelten Informationen an den L2 Support übergeben.

4. L2 analysiert Prozess, Stammdaten und Konfiguration

Der Second-Level-Support prüft den betroffenen Geschäftsprozess und versucht, den Fehler zu reproduzieren.

Abhängig vom Ticket können beispielsweise folgende Bereiche untersucht werden:

• Customizing,
• Stammdaten,
• Berechtigungen,
• Schnittstellenmeldungen,
• Hintergrundjobs,
• Anwendungsprotokolle,
• kürzlich eingespielte Transporte,
• Unterschiede zwischen funktionierenden und fehlerhaften Fällen.

Kann L2 die Ursache durch eine Konfigurations- oder Stammdatenkorrektur beheben, wird die Lösung getestet, freigegeben und dokumentiert.

5. L3 übernimmt komplexe technische Ursachen

Stellt sich heraus, dass kundenspezifischer Code, eine Erweiterung oder eine komplexe Integration betroffen ist, wird das Ticket an den L3 Support eskaliert.

Der Third-Level-Support kann dann:

• ABAP-Code analysieren,
• Debugging durchführen,
• Schnittstellen und Datenflüsse untersuchen,
• eine technische Korrektur entwickeln,
• Performance-Probleme analysieren,
• SAP Fiori oder SAPUI5 prüfen,
• SAP oder einen weiteren Anbieter einbinden.

Vor der Produktivsetzung wird die Lösung in einer geeigneten Umgebung getestet und fachlich freigegeben.

6. Lösung wird umgesetzt und validiert

Nach der technischen oder funktionalen Korrektur prüft der betroffene Fachbereich, ob der Geschäftsprozess wieder wie erwartet funktioniert.

Je nach Änderung können folgende Tests erforderlich sein:

• technischer Unit-Test,
• funktionaler Test,
• Integrationstest,
• Regressionstest,
• User Acceptance Test.

Bei kritischen Incidents kann zunächst ein Workaround bereitgestellt werden, damit der Geschäftsbetrieb fortgesetzt werden kann. Die dauerhafte Lösung wird anschließend entwickelt und kontrolliert implementiert.

7. Ticket wird dokumentiert und geschlossen

Ein Ticket sollte erst geschlossen werden, wenn:

• die Lösung erfolgreich umgesetzt wurde,
• der betroffene Prozess wieder funktioniert,
• der Anwender oder Fachbereich informiert wurde,
• Ursache und Lösung dokumentiert sind,
• relevante Knowledge-Base-Artikel aktualisiert wurden,
• mögliche Folgeaufgaben erfasst sind.

Bei wiederkehrenden oder kritischen Incidents sollte zusätzlich eine Root Cause Analysis durchgeführt werden.

Praxisbeispiel: Kundenaufträge werden nicht an das Lager übertragen

Ein Unternehmen stellt fest, dass bestimmte Kundenaufträge aus SAP S/4HANA nicht an das Lagerverwaltungssystem übertragen werden. Die betroffenen Aufträge können deshalb nicht kommissioniert und ausgeliefert werden.

Bearbeitung durch L1

Der L1 Support erfasst:

• betroffene Auftragsnummern,
• Verkaufsorganisation und Werk,
• Zeitpunkt des Fehlers,
• betroffene Benutzer,
• Fehlermeldungen,
• Auswirkungen auf die Auslieferung.

Da mehrere Aufträge betroffen sind und Lieferungen blockiert werden, wird das Ticket mit hoher Priorität eingestuft.

Analyse durch L2

Der L2 Support prüft:

• Auftrags- und Materialstammdaten,
• Lieferrelevanz,
• Customizing,
• Nachrichtenstatus,
• Schnittstellenprotokolle,
• Unterschiede zwischen erfolgreichen und fehlerhaften Aufträgen.

Die Analyse zeigt, dass nur Aufträge mit einer bestimmten Produktgruppe betroffen sind. Die Stammdaten und Konfiguration sind jedoch korrekt.

Analyse durch L3

Der L3 Support untersucht die kundenspezifische Integrationslogik. Dabei wird festgestellt, dass eine Erweiterung die betroffenen Aufträge aufgrund einer fehlerhaften Bedingung von der Übertragung ausschließt.

L3 korrigiert den Code und stellt die Änderung im Testsystem bereit.

Test und Produktivsetzung

Der Fachbereich testet mehrere Auftragstypen und bestätigt, dass die Übertragung wieder korrekt funktioniert.

Nach der Freigabe wird die Änderung produktiv gesetzt. Anschließend werden die zuvor blockierten Aufträge erneut verarbeitet.

Abschluss und Prävention

Die Fehlerursache, Codeänderung und Testfälle werden dokumentiert. Zusätzlich wird ein Monitoring eingerichtet, das künftig auf nicht übertragene Aufträge hinweist.

Das Beispiel zeigt, wie die drei SAP Support Level zusammenarbeiten:

• L1 erfasst, priorisiert und qualifiziert das Ticket.
• L2 analysiert Prozess, Stammdaten und Konfiguration.
• L3 behebt die technische Ursache in der kundenspezifischen Entwicklung.

Durch eine klare Übergabe zwischen den Support-Leveln kann das Problem schneller gelöst und dauerhaft vermieden werden.

Fazit: Die richtige Aufteilung beschleunigt den SAP Support

Die Unterteilung in SAP Support Level 1, 2 und 3 sorgt dafür, dass Anfragen entsprechend ihrer Komplexität bearbeitet werden.

Der L1 Support ist die erste Anlaufstelle für Anwender, dokumentiert Anfragen und löst bekannte Standardprobleme. Der L2 Support übernimmt funktionale und technische Analysen, beispielsweise bei Problemen mit Prozessen, Stammdaten, Berechtigungen oder Customizing. Der L3 Support bearbeitet komplexe Fehler in kundenspezifischen Entwicklungen, Integrationen und technischen Architekturen.

Entscheidend ist jedoch nicht allein die Anzahl der Support-Level. Ein leistungsfähiges SAP Support Modell benötigt außerdem:

• klar definierte Verantwortlichkeiten,
• eine einheitliche Prioritätsmatrix,
• realistische und messbare SLAs,
• vollständige Ticketinformationen,
• dokumentierte Eskalationswege,
• regelmäßigen Wissenstransfer,
• eine gepflegte Knowledge Base,
• strukturierte Root Cause Analysen.

Unternehmen sollten ihre Support-Struktur an der eigenen SAP-Landschaft ausrichten. Während der L1 Support häufig intern oder gemeinsam mit einem Dienstleister betrieben wird, können externe SAP-Spezialisten insbesondere im L2- und L3-Support fehlende Kompetenzen und zusätzliche Kapazitäten bereitstellen.

Ein hybrides Modell verbindet internes Prozesswissen mit spezialisierten SAP-Kompetenzen. Geschäftliche Priorisierung, Governance und Freigaben bleiben beim Unternehmen, während ein externer Partner funktionale und technische Support-Aufgaben übernimmt.

SAP Support mit klaren SLAs und Eskalationswegen

LeverX unterstützt Unternehmen bei der Betreuung und Weiterentwicklung komplexer SAP-Landschaften. Abhängig vom Bedarf können einzelne Module, bestimmte Support-Level oder der vollständige L1–L3-Support abgedeckt werden.

Unsere Leistungen können unter anderem umfassen:

• funktionalen und technischen SAP Support,
• Incident und Problem Management,
• SAP ABAP und kundenspezifische Entwicklungen,
• SAP Fiori, SAPUI5 und SAP BTP,
• Integrations- und Schnittstellensupport,
• Root Cause Analysen,
• Ticket- und Change-Backlog-Bearbeitung,
• Unterstützung während kritischer Geschäftsperioden,
• definierte Servicezeiten und SLAs.

Gemeinsam analysieren wir Ihre SAP-Landschaft, bestehende Support-Prozesse und aktuelle Herausforderungen. Darauf aufbauend entwickeln wir ein Support-Modell mit klaren Rollen, Eskalationswegen und Service Levels.

Benötigen Sie Unterstützung für einzelne SAP Support Level oder Ihre gesamte SAP-Landschaft?

SAP Support besprechen

Häufig gestellte Fragen zu SAP Support Level 1, 2 und 3

Was ist der Unterschied zwischen L1, L2 und L3 Support?

Der Unterschied liegt vor allem in der Komplexität der Aufgaben und der benötigten Expertise. Der L1 Support nimmt Tickets auf und löst standardisierte Anwenderprobleme. Der L2 Support analysiert funktionale und technische Störungen. Der L3 Support bearbeitet komplexe Fehler, kundenspezifische Entwicklungen, Integrationen und Architekturfragen.

Muss jedes SAP-Ticket zuerst durch den L1 Support?

Nein. Bei kritischen Incidents oder klar erkennbaren technischen Problemen können L2- und L3-Experten sofort eingebunden werden. Ein zentraler L1 Service Desk bleibt dennoch sinnvoll, weil er Tickets dokumentiert, priorisiert und die Kommunikation koordiniert. Der genaue Ablauf sollte im Support-Modell und im SLA definiert sein.

Welche Tickets gehören in den SAP L1 Support?

Zum L1 Support gehören vor allem Anwenderfragen, bekannte Fehlermeldungen, standardisierte Service Requests und Probleme, die mithilfe dokumentierter Lösungen behoben werden können. L1 erfasst außerdem alle relevanten Informationen und leitet das Ticket an L2 weiter, wenn vertiefte SAP-Kenntnisse erforderlich sind.

Wann wird ein Ticket an den L2 Support eskaliert?

Eine Eskalation an L2 erfolgt typischerweise, wenn Customizing, Stammdaten, Berechtigungen oder ein bestimmter SAP-Prozess analysiert werden müssen. Auch wiederkehrende Incidents und Fehler, die nur bei bestimmten Organisationseinheiten oder Prozessvarianten auftreten, werden häufig vom Second-Level-Support bearbeitet.

Wann wird der SAP L3 Support benötigt?

Der L3 Support wird benötigt, wenn kundenspezifischer Code, komplexe Integrationen, SAP Fiori, SAP BTP, Performance-Probleme oder technische Architektur betroffen sind. L3 übernimmt außerdem tiefgehende Root Cause Analysen und koordiniert bei Bedarf die technische Abstimmung mit SAP oder weiteren Anbietern.

Ist der L3 Support dasselbe wie der SAP Support des Herstellers?

Nein. Der L3 Support wird häufig durch interne Entwickler oder einen externen SAP-Dienstleister bereitgestellt. Er analysiert zunächst die kundenspezifische Landschaft und bereitet technische Informationen vor. SAP selbst wird eingebunden, wenn ein Fehler im Standardprodukt vermutet wird oder eine Korrektur durch den Hersteller erforderlich ist.

Wie viele Support-Level benötigt ein Unternehmen?

Das hängt von der Größe, Komplexität und Kritikalität der SAP-Landschaft ab. Kleinere Unternehmen können L1 und L2 teilweise zusammenfassen. Internationale Organisationen mit vielen Modulen, Integrationen und kundenspezifischen Entwicklungen benötigen häufig klar getrennte L1-, L2- und L3-Teams sowie ein übergreifendes Incident und Service Management.

Können alle drei SAP Support Level ausgelagert werden?

Ja. Ein externer SAP-Dienstleister kann L1, L2 und L3 vollständig oder teilweise übernehmen. Viele Unternehmen wählen jedoch ein hybrides Modell: Interne Teams behalten Anwendernähe, Priorisierung und Governance, während externe SAP-Spezialisten funktionale und technische Aufgaben abdecken.

Welche Kennzahlen sind im SAP Support besonders wichtig?

Wichtige Kennzahlen sind Reaktionszeit, Wiederherstellungszeit, Lösungszeit, SLA-Erfüllung, First Contact Resolution Rate, Eskalationsquote, Wiedereröffnungsrate und Ticket-Backlog. Zusätzlich sollten Unternehmen die Qualität der Ursachenanalysen, die Anzahl wiederkehrender Incidents und die Zufriedenheit der Anwender berücksichtigen.

Was macht ein gutes SAP Support Modell aus?

Ein gutes Support-Modell verbindet klare Zuständigkeiten mit definierten Eskalationswegen, realistischen SLAs und vollständiger Dokumentation. Tickets sollten möglichst schnell beim richtigen Experten landen. Gleichzeitig müssen Wissen zwischen L1, L2 und L3 übertragen und wiederkehrende Probleme dauerhaft analysiert werden.