Eine Rechnung bleibt erneut liegen. Der Key User kennt den Umweg und hilft weiter. Der Vorgang ist erledigt, bis dieselbe Frage einige Tage später wieder auftaucht.
Solange jeder Einzelfall lösbar bleibt, fällt der zusätzliche Aufwand im Tagesgeschäft kaum auf. Die entscheidende Frage lautet deshalb nicht, ob einzelne SAP-Probleme gelöst werden können. Sondern: Wann wird aus einzelnen Anfragen ein wiederkehrender Betreuungsbedarf?
Hinweise darauf können sich an ganz unterschiedlichen Stellen zeigen - bei Anwenderfragen, kleinen Änderungen, Schnittstellen oder regelmäßig neu organisierten Tests.
Dieser Beitrag zeigt fünf typische Anzeichen und einen einfachen Ansatz, mit dem Sie prüfen können, ob einzelne Unterstützungsanfragen weiterhin ausreichen oder eine laufende SAP-Betreuung sinnvoller organisiert werden sollte.
Welche Aufgaben grundsätzlich zur Betreuung eines SAP-Systems gehören, haben wir im Beitrag SAP Systembetreuung: Was gehört eigentlich alles dazu? zusammengefasst.
1. Dieselben SAP-Fragen kommen immer wieder
Ein einzelner Fehler ist zunächst ein Einzelfall.
Interessant wird es, wenn ähnliche Fragen regelmäßig zurückkehren:
- Ein bestimmter Beleg lässt sich wiederholt nicht verarbeiten.
- Anwender benötigen immer wieder Hilfe beim gleichen Prozessschritt.
- Eine Auswertung muss regelmäßig manuell korrigiert werden.
- Bestimmte Buchungen landen immer wieder beim selben Key User.
Dann lohnt sich ein Blick hinter das einzelne Ticket. Mehrere Meldungen können beispielsweise auf dieselbe technische Ursache zurückgehen. Ebenso möglich sind unklare Arbeitsabläufe, fehlende Dokumentation oder Probleme mit Stammdaten.
Entscheidend ist deshalb nicht allein, wie viele Anfragen entstehen, sondern ob sich dahinter wiederkehrende Ursachen erkennen lassen. Wer jeden Vorgang ausschließlich einzeln löst, beseitigt möglicherweise das Symptom – nicht aber den Grund dafür.
2. Kritisches SAP-Wissen hängt an einzelnen Personen
„Frag am besten Frau Müller, die weiß, wie das geht.“ Solche Sätze sind im Tagesgeschäft zunächst praktisch. Sie zeigen aber auch, dass wichtiges Prozess- oder Systemwissen möglicherweise nicht ausreichend dokumentiert ist. Problematisch wird das spätestens bei Urlaub, Krankheit, Rollenwechsel oder steigender Zahl von Anfragen.
Typische Hinweise sind:
- Nur ein Key User kennt bestimmte Sonderfälle.
- Lösungswege sind nicht oder nur teilweise dokumentiert.
- Andere Mitarbeiter müssen bei bekannten Problemen erneut recherchieren.
- Technische Entscheidungen lassen sich später nur schwer nachvollziehen.
- Vertretungen funktionieren nur mit umfangreicher persönlicher Übergabe.
Eine mögliche Aufgabe laufender Betreuung besteht dann nicht darin, den Key User zu ersetzen. Sinnvoller ist es, wiederkehrende Lösungen nachvollziehbar zu dokumentieren, Verantwortlichkeiten zu klären und Wissen so zu sichern, dass nicht jede Frage erneut bei derselben Person landet.
3. Kleine SAP-Änderungen bleiben dauerhaft liegen
Nicht jede Anforderung rechtfertigt ein eigenes Projekt. Ein zusätzliches Feld, eine Anpassung an einem Formular, eine Rollenänderung oder eine kleine Erweiterung einer Auswertung kann für sich genommen überschaubar sein.
Im Tagesgeschäft passiert jedoch häufig etwas anderes:
Die Anforderung ist wichtig, aber nie wichtig genug, um sofort ein eigenes Projekt daraus zu machen.
So entsteht mit der Zeit ein Rückstand aus kleineren Verbesserungen.
Typische Beispiele sind:
- ein Report, dem eine benötigte Kennzahl fehlt,
- ein Formular, das nicht mehr zum aktuellen Prozess passt,
- Berechtigungen, die immer wieder manuell nachbearbeitet werden,
- ein unnötiger manueller Zwischenschritt,
- eine kleinere Prozessanpassung ohne klaren Verantwortlichen.
Das eigentliche Problem ist dann häufig nicht die einzelne Änderung. Es fehlt ein Verfahren, um Anforderungen aufzunehmen, fachlich zu bewerten, zu priorisieren und kontrolliert umzusetzen. Genau an dieser Stelle kann aus punktueller Unterstützung ein kontinuierlicher Betreuungsbedarf entstehen.
4. Bei Schnittstellen wird vor allem weitergereicht
Ein Prozess funktioniert nicht, aber das SAP-System ist nur eines von mehreren beteiligten Systemen. Dann beginnt häufig die Suche:
Liegt es an SAP? Am angebundenen System? An der Schnittstelle? An den Daten? Oder an einer Änderung, die an anderer Stelle vorgenommen wurde?
Schwierig wird es, wenn Meldungen vor allem zwischen Beteiligten weitergereicht werden.
Für wiederkehrende Schnittstellenthemen sollte deshalb geklärt sein:
- Wer übernimmt die erste Analyse?
- Welche Informationen werden für die Fehlersuche benötigt?
- Wer koordiniert weitere beteiligte Systeme oder Dienstleister?
- Wie werden Ursache und Lösung dokumentiert?
- Wann ist ein Vorgang tatsächlich fachlich abgeschlossen?
Nicht jede Schnittstellenstörung erfordert eine dauerhafte Betreuung. Treten solche Situationen jedoch regelmäßig auf, kann ein fester Analyse- und Eskalationsweg erheblich wichtiger sein als die jeweils einzelne technische Lösung.
5. Tests werden bei jeder Änderung neu organisiert
Eine Änderung steht an und erst kurz vorher wird geklärt, wer eigentlich testen soll. Welche Prozesse müssen geprüft werden? Welche Testdaten werden benötigt? Wer entscheidet, ob das Ergebnis fachlich korrekt ist?
Wenn diese Abstimmung bei jeder Änderung von vorne beginnt, entsteht vermeidbarer Aufwand. Ein gepflegter Bestand wichtiger Testfälle kann deshalb ebenfalls Bestandteil einer laufenden Betreuung sein.
Dabei geht es beispielsweise darum,
- geschäftskritische Abläufe zu identifizieren,
- fachliche Verantwortliche festzulegen,
- relevante Testfälle nachvollziehbar zu beschreiben,
- Testergebnisse zu dokumentieren und
- bekannte Tests bei späteren Änderungen erneut nutzen zu können.
Gerade bei regelmäßig aktualisierten Cloud-Lösungen gewinnt dieses Vorgehen an Bedeutung.
Einzelauftrag oder laufende SAP-Betreuung?
Nicht jede wiederkehrende Frage bedeutet automatisch, dass ein umfangreiches Betreuungsmodell notwendig ist.
Eine einfache Einordnung kann bei der Entscheidung helfen:
| Ausgangslage | Möglicher nächster Schritt |
|---|---|
| Eine klar abgegrenzte Frage mit bekanntem Ergebnis | Einzelne Unterstützungsanfrage |
| Mehrere ähnliche Vorgänge mit vermuteter gemeinsamer Ursache | Ursachenanalyse bündeln |
| Wiederkehrende Fragen, kleine Änderungen und regelmäßiger Abstimmungsbedarf | Laufende Betreuung prüfen |
| Neue Prozesse mit mehreren Beteiligten und größeren Abhängigkeiten | Eigenes Vorhaben oder Projekt abgrenzen |
Die Grenzen sind nicht starr. Aus einer zunächst kleinen Supportanfrage kann sich beispielsweise herausstellen, dass ein Prozess grundsätzlich angepasst werden sollte. Umgekehrt kann eine vermeintlich technische Fragestellung nach kurzer Analyse mit einer klareren Arbeitsanweisung gelöst werden.
Eine laufende Betreuung sollte deshalb auch festlegen, wann aus einer Anfrage ein eigenes Vorhaben wird und zusätzliche Abstimmungen oder Freigaben erforderlich sind.
Praxisbeispiel: Wiederkehrende Rechnungsfragen
Ein vereinfachtes Beispiel zeigt, wie sich der Bedarf untersuchen lässt. Das folgende Szenario ist frei konstruiert und keine Kundenreferenz der Bradler GmbH.
In einem Unternehmen werden ähnliche Fragen zu Eingangsrechnungen wiederholt an denselben Key User weitergeleitet. Der Key User kennt meist eine Lösung oder einen Umweg. Unklar bleibt allerdings, warum die Fragen überhaupt immer wieder entstehen.
Die Ursache könnte beispielsweise in:
- den zugrunde liegenden Daten,
- einer Systemeinstellung,
- dem Prozessablauf,
- fehlenden Berechtigungen,
- einer unklaren Arbeitsanweisung oder
- unterschiedlichen fachlichen Sonderfällen
liegen.
Statt weitere Einzelfälle lediglich abzuarbeiten, kann das Thema begrenzt untersucht werden.
1. Wiederkehrende Vorgänge erfassen
Für einige typische Fälle werden Prozessschritt, Häufigkeit, Auswirkung und bisheriger Lösungsweg dokumentiert.
Für eine erste Einordnung reichen bereinigte Beispiele. Vertrauliche Belege sollten ausschließlich über dafür vereinbarte sichere Wege ausgetauscht werden.
2. Nach gemeinsamen Ursachen suchen
Ähnliche Symptome sind nicht automatisch dieselbe Ursache.
Deshalb werden die Vorgänge zunächst fachlich und technisch eingeordnet. Dabei kann sich beispielsweise herausstellen, dass mehrere Fälle tatsächlich auf dieselbe Einstellung zurückgehen oder dass unterschiedliche Situationen nur auf den ersten Blick gleich aussehen.
3. Verantwortlichkeiten festlegen
Der Fachbereich beschreibt, welches Ergebnis fachlich erwartet wird. Die Betreuung untersucht mögliche technische Ursachen und Lösungswege. Die fachliche Freigabe bleibt bei den dafür vorgesehenen Verantwortlichen.
4. Änderung bewusst begrenzen
Nicht sofort die größtmögliche Lösung umsetzen. Je nach Ursache kann der erste Schritt beispielsweise darin bestehen, eine Arbeitsanweisung zu verbessern, Stammdaten zu korrigieren oder eine konkret begründete Systemeinstellung anzupassen. Aufwand, Abhängigkeiten und Abnahmekriterium sollten vorher feststehen.
5. Ergebnis fachlich prüfen
Eine technische Änderung allein bestätigt noch nicht, dass der Rechnungsprozess anschließend fachlich richtig funktioniert.
Deshalb werden beispielsweise ein typischer Vorgang und ein relevanter Ausnahmefall anhand der vorher vereinbarten Erwartungen geprüft.
6. Wissen sichern
Lösung, Ursache, Zuständigkeit und Prüfergebnis werden dokumentiert. Anschließend lässt sich beobachten, ob vergleichbare Rückfragen weiterhin auftreten. Wichtig dabei: Auch das Ergebnis „keine Systemänderung erforderlich“ kann richtig sein.
Liegt die Ursache in einer missverständlichen Arbeitsweise, sollte dort angesetzt werden. Umgekehrt sollte ein nachgewiesenes technisches Problem nicht dauerhaft durch einen manuellen Umweg oder zusätzliche Schulung kompensiert werden.
Warum Release-Tests ein typisches Betreuungsthema sein können
Ein konkretes Beispiel aus SAP S/4HANA Cloud Public Edition sind wiederkehrende Tests im Zusammenhang mit Upgrades und neuen Funktionen.
SAP empfiehlt in der Dokumentation für Release 2608 ausdrücklich manuelle und automatisierte Regressionstests. Dafür steht unter anderem ein Testautomatisierungswerkzeug zur Verfügung; vorhandene Testfälle können angepasst und neue Testfälle aufgezeichnet werden.
Für die eigene Organisation ergibt sich daraus eine wiederkehrende praktische Aufgabe:
Welche Geschäftsprozesse müssen nach Änderungen geprüft werden, wer verantwortet die fachliche Prüfung und wie wird das Ergebnis nachvollziehbar dokumentiert?
Wenn diese Fragen vor jedem Release neu geklärt werden müssen, kann es sinnvoll sein, Testfälle und Verantwortlichkeiten als laufende Betriebsaufgabe zu pflegen.
Welche Tests erforderlich sind und welche Funktionen im jeweiligen System verfügbar sind, hängt von Produkt, Release, Konfiguration und den tatsächlich genutzten Geschäftsprozessen ab.
SAP-Projekte strukturiert von der Umsetzung bis in den Betrieb führen
Wie greifen Projektphasen, Verantwortlichkeiten, Tests und die Übergabe in den laufenden Betrieb ineinander? Unser kostenloses SAP-Activate-Whitepaper gibt Ihnen einen kompakten Überblick.
Mit welchen Zahlen lässt sich der Betreuungsbedarf beurteilen?
Eine Entscheidung über laufende Betreuung sollte nicht nur auf einem allgemeinen Gefühl beruhen. Für einen ersten Überblick können bereits wenige Kennzahlen helfen.
Wiederkehrende Vorgänge je Ursache
Wie häufig taucht dieselbe bestätigte Ursache erneut auf? Dabei sollte nicht nur nach ähnlich klingenden Ticketbeschreibungen gesucht werden. Entscheidend ist die tatsächlich festgestellte Ursache.
Aktive Bearbeitungszeit
Wie viel Arbeitszeit verwenden Key User, Fachbereiche, IT oder externe Unterstützung tatsächlich für diese Vorgänge? Wartezeit sollte separat betrachtet werden, damit sie nicht mit aktiver Bearbeitung vermischt wird.
Zeit bis zur fachlichen Klärung
Wie lange dauert es, bis ein nachvollziehbarer Lösungsweg feststeht? Ein formal geschlossenes Ticket bedeutet nicht automatisch, dass die Ursache verstanden oder dauerhaft beseitigt wurde.
Dokumentierte Lösungswege
Für wie viele wiederkehrende Situationen gibt es eine aktuelle und geprüfte Beschreibung? Und ist festgelegt, wer für das jeweilige Thema verantwortlich ist?
E-Invoicing mit SAP richtig vorbereiten
Von Stammdaten und Formaten bis zu Tests und Verantwortlichkeiten: Unser kostenloser Guide zeigt, worauf Unternehmen bei der elektronischen Rechnungsverarbeitung mit SAP achten sollten.
So können Sie mit einem begrenzten Thema starten
Eine laufende SAP-Betreuung muss nicht mit einem umfangreichen Maßnahmenkatalog beginnen.
Für einen ersten Schritt reichen häufig:
- das eingesetzte SAP-Produkt,
- ein betroffener Geschäftsprozess,
- einige typische wiederkehrende Situationen und
- der bisherige Lösungsweg.
Anschließend kann geklärt werden:
- Welche Ursachen wiederholen sich tatsächlich?
- Welche Themen lassen sich bündeln?
- Wer übernimmt welche Verantwortung?
- Welche Anforderungen sollten priorisiert werden?
- Welche Ergebnisse müssen dokumentiert werden?
- Wann wird aus einer Betreuungstätigkeit ein separates Projekt?
Auch Reaktionszeiten, Erreichbarkeit und Vertretungsregeln sollten ausdrücklich vereinbart werden. Sie ergeben sich nicht automatisch daraus, dass eine Zusammenarbeit als „Systembetreuung“ bezeichnet wird.
Fazit: Nicht die Zahl der Tickets ist entscheidend
Laufende SAP-Betreuung wird nicht automatisch notwendig, sobald mehrere Supportanfragen auftreten. Wichtiger ist, welches Muster hinter den Anfragen steckt.
Wenn dieselben Ursachen wiederkehren, Wissen an einzelnen Personen hängt, kleinere Verbesserungen dauerhaft liegen bleiben oder Verantwortlichkeiten bei Schnittstellen und Tests immer wieder neu geklärt werden müssen, lohnt sich eine strukturierte Betrachtung.
Der erste Schritt muss dabei kein langfristiges Betreuungsmodell sein. Ein begrenztes Thema mit klarer Fragestellung, dokumentierten Vorgängen und einem überprüfbaren Ergebnis reicht häufig aus, um den tatsächlichen Bedarf besser einzuschätzen.
So wird aus der Frage „Brauchen wir mehr SAP-Support?“ eine konkretere Entscheidung:
Welche Aufgaben treten regelmäßig auf und wie sollten wir sie dauerhaft organisieren?
Produkt und Gültigkeit
Dieser Beitrag ist eine organisatorische Entscheidungshilfe zur laufenden SAP-Betreuung. Der konkrete technische Dokumentationsbezug im Abschnitt zu Regressionstests gilt für SAP S/4HANA Cloud Public Edition, Release 2608. Grundlage ist die SAP-Help-Dokumentation „Regressionstests durchführen“, geprüft im September 2026.
Produktumfang, Systemkonfiguration und geeignete Testverfahren müssen für die jeweilige Systemlandschaft separat bewertet werden.
Das Rechnungsbeispiel sowie das Rechenbeispiel sind frei gewählte Illustrationen und keine gemessenen Kundenresultate der Bradler GmbH.
Damit Ihr SAP-System auch im Alltag zuverlässig läuft
Ob Support, Prozessoptimierung oder Weiterentwicklung - wir unterstützen Sie dabei, Ihre SAP-Landschaft langfristig erfolgreich zu betreiben.