Ihre externe SAP-Abteilung: Wir halten Ihre Systeme stabil, lösen die Tickets Ihrer Anwender und entwickeln weiter, nativ in Ihrem Ticketsystem.

Die Kosten richten sich nach Systemlandschaft, Ticketvolumen, SLA-Anforderungen und Delivery-Modell – üblich sind monatliche Pauschalen für einen definierten Leistungsumfang, kombinierbar mit Kontingenten für Weiterentwicklungen. Nearshore- und Offshore-Anteile senken den Preis spürbar. Nach einem Erstgespräch erhalten Sie von Staufenberg Advisory innerhalb von fünf Werktagen eine unverbindliche Aufwandsindikation für Ihr konkretes Szenario. Beim Vergleich mehrerer Angebote lohnt der Blick auf drei Positionen, die die Monatspauschale relativieren. Erstens der Umgang mit Mengen über dem vereinbarten Volumen: Wird nachberechnet, und zu welchem Satz? Zweitens die Frage, ob Kontingente für Weiterentwicklungen verfallen oder in den Folgemonat übergehen. Drittens die Wissensübergabe beim Aufsetzen und beim Beenden des Vertrags – sie ist der Posten, der über die Abhängigkeit entscheidet und in Angeboten am häufigsten fehlt. Ein Vertrag ohne geregelte Übergabe am Ende ist teurer als sein Monatspreis.

Abgedeckt werden alle Module. Die Schwerpunkte von Staufenberg Advisory liegen auf FI/CO, SD, MM, EWM und HCM sowie auf ABAP- und BTP-Entwicklung, also den Bereichen, in denen im Betrieb die meisten Tickets entstehen. Der konkrete Modul-Zuschnitt wird im AMS-Vertrag auf Ihre Landschaft abgestimmt. Wichtiger als die Modulliste ist dabei die Prozesssicht, und das ist keine Floskel: Die meisten Störungen, die als Modulproblem gemeldet werden, entstehen an den Übergängen zwischen Modulen. Eine Lieferung, die nicht fakturiert wird, ist selten ein Fehler in SD allein. Ein Betriebsmodell, das je Modul einen Zuständigen ohne gemeinsame Prozesssicht vorsieht, verlagert diese Übergänge in Ihre Koordination – und dann moderieren Ihre Mitarbeiter zwischen Zuständigkeiten. Wir schneiden den Vertrag deshalb an Prozessen wie Order to Cash oder Procure to Pay zu und nicht an Modulnamen; die Modulrollen ergeben sich daraus, statt sie vorab zu zählen.

Reaktions- und Lösungszeiten werden je Prioritätsklasse vertraglich als SLA vereinbart: kritische Störungen mit kurzen Reaktionsfenstern, Standardanfragen im Regelprozess. Über Follow-the-Sun-Modelle sind auch Abdeckungen über die europäischen Geschäftszeiten hinaus möglich. Die Einhaltung wird monatlich transparent reportet. Zwei Begriffe sind dabei sauber zu trennen, weil ihre Vermischung die häufigste Ursache für Streit über SLAs ist: Die Reaktionszeit sagt, wann jemand mit der Bearbeitung beginnt, die Lösungszeit, wann die Störung behoben ist. Nur die erste lässt sich verlässlich zusagen, weil die zweite von der Ursache abhängt – ein Fehler in einer Schnittstelle zu einem Fremdsystem liegt teilweise nicht in unserer Hand. Ein Anbieter, der pauschale Lösungszeiten für alle Prioritätsklassen zusagt, verspricht entweder zu viel oder hat Ausnahmen im Kleingedruckten. Achten Sie deshalb auf die Definition der Prioritätsklassen: Wer sie festlegt, bestimmt faktisch, welche SLA gilt.

Nein – das ist ein Kernmerkmal des AMS-Modells von Staufenberg Advisory: Wir arbeiten nativ im Ticketsystem des Kunden, übernehmen Ihre Prozesse und Prioritätslogik und erzwingen kein eigenes Portal. Dadurch entfällt der Umstellungsaufwand auf Ihrer Seite fast vollständig. Der Vorteil ist größer, als er zunächst klingt, weil er nicht nur den Aufwand betrifft: Ihre Fachabteilungen melden weiter dorthin, wo sie es gewohnt sind, und Ihre eigene Auswertung über Ticketvolumen und Themen bleibt vollständig – Sie behalten also die Zahlen, mit denen Sie den Dienstleister beurteilen. Wo ein Anbieter auf sein eigenes Portal besteht, liegen die Kennzahlen bei ihm, und beim Wechsel bleibt die Historie dort. Was wir brauchen, sind lediglich Zugänge und die Abstimmung Ihrer Prioritätslogik. Wenn Sie noch kein Ticketsystem betreiben, richten wir eines ein, das Ihnen gehört und nicht uns – damit die Historie beim Wechsel bei Ihnen bleibt.

Klassischer Support reagiert auf Störungen; AMS verantwortet den Anwendungsbetrieb als Ganzes, inklusive Problem-Management, Monitoring, kleineren Weiterentwicklungen und kontinuierlicher Dokumentation. AMS ist damit ein dauerhaftes Betriebsmodell mit SLAs und Kennzahlen, kein Notfallkontakt. Der praktische Unterschied zeigt sich nicht am Tag der Störung, sondern nach einigen Monaten: Ein Support behebt dieselben Fehlerbilder wieder und wieder, ein Betriebsmodell arbeitet an den Ursachen und weist die sinkende Ticketzahl nach. Genau daran sollten Sie einen AMS-Vertrag messen. Wenn die Zahl der Störungen nach zwölf Monaten unverändert ist, wird reagiert statt betrieben – unabhängig davon, wie gut die Reaktionszeiten eingehalten wurden. Diese Kennzahl gehört deshalb von Anfang an in den Bericht, gemeinsam mit der Zahl der wiederkehrenden Fehlerbilder. Beide zusammen zeigen, ob am Problem gearbeitet wird oder nur am Symptom, und sie sind der einzige belastbare Maßstab für den Nutzen eines Betriebsvertrags.

Ein eigenes SAP-Team lohnt sich, wenn Systemgröße und Änderungsvolumen dauerhaft mehrere Vollzeitkräfte je Modulbereich auslasten; andernfalls zahlen Sie für Vorhaltung statt für Leistung. SAP AMS rechnet sich, wenn der Bedarf schwankt, das nötige Spezialwissen über viele Module verteilt ist oder das interne Team für Projekte frei werden soll. In der Praxis fahren viele Unternehmen ein Mischmodell: Kernwissen intern, Betrieb und Lastspitzen über AMS. Ein Punkt gehört bei dieser Entscheidung ausdrücklich mit auf den Tisch, weil er sich nicht in Kosten ausdrücken lässt: das Personalrisiko. Bei einer schlanken SAP-Organisation hängt das Wissen über gewachsene Eigenentwicklungen häufig an einer oder zwei Personen, und eine Kündigung nimmt es mit. Ein AMS-Vertrag verteilt dieses Wissen auf ein Team und verlangt eine Dokumentation, die es festhält. Wer den eigenen Weg wählt, sollte diese Dokumentation vertraglich einfordern und regelmäßig prüfen, ob sie existiert.

Ja. Kleinere Weiterentwicklungen, Changes, Reports und Formularanpassungen wickeln wir innerhalb des AMS über vereinbarte Kontingente ab. Wächst ein Change zum Projekt, geht er sauber in unsere Projektorganisation über, mit denselben Ansprechpartnern. Details dazu auf unserer Seite zu SAP S/4HANA und Enterprise Applications. Die Grenze zwischen Change und Projekt legen wir dabei vorab fest und nicht im Einzelfall, weil sonst jede größere Anforderung eine Verhandlung auslöst. Üblich ist eine Schwelle in Personentagen: Darunter läuft die Anforderung im Kontingent, darüber geht sie in die Projektorganisation über. Was in beiden Fällen gleich bleibt, sind die Ansprechpartner – der häufigste Ärger bei diesem Übergang entsteht nicht durch die Kosten, sondern dadurch, dass plötzlich andere Personen zuständig sind und die Vorgeschichte nicht kennen. Bei uns bleiben die Ansprechpartner deshalb dieselben, und die Schwelle steht im Vertrag statt im Ermessen des Anbieters.