SAP Shoring oder Nearshore? Modell- und Kostenvergleich

Von OXORY Redaktion · 1.11.2026 · 3 Min. Lesezeit

Zuletzt aktualisiert am 3.9.2026

Shoring ist ein Delivery-Modell, nicht nur ein Standort

Der Begriff Shoring wird oft fälschlicherweise rein als „Niedriglohnstandort“ verstanden. In Wirklichkeit ist Shoring eine Delivery-Architektur, die definiert, welcher Teil der Arbeit wo erbracht wird: Architekturentscheidungen und die Key-User-Kommunikation bleiben nah am Fachbereich, während wiederkehrende Entwicklungs- und Supportvolumina an kosteneffizienten Standorten angesiedelt werden.

Nearshore ist eine Ausprägung dieses Setups: Teams, die in derselben oder einer angrenzenden Zeitzone unter europäischen Vertrags- und Datenschutzstandards agieren. Die Frage lautet daher nicht „Shoring oder Nearshore?“, sondern: „Welcher Anteil meines Shoring-Setups sollte Nearshore sein?“

Vier Modelle im direkten Vergleich

Bereitstellungsoptionen ausschließlich anhand von Tagessätzen zu vergleichen, führt in die Irre. Für exakt denselben Leistungsumfang werden in verschiedenen Modellen aufgrund von Kommunikationsverzögerungen und Nacharbeiten unterschiedlich viele Projekttage benötigt.

• Onsite: Höchster Tagessatz, geringster Kommunikationsaufwand. Die richtige Wahl für Architektur, Prozessdesign und kritische Cutover-Phasen.
• Nearshore: Moderater Tagessatz, vollständige Zeitzonenüberschneidung. Der primäre Treiber für Entwicklung, Testing und AMS-Volumen.
• Offshore: Niedrigster Tagessatz, höchster Koordinationsaufwand. Reduziert die Gesamtkosten nur bei eng umrissenen, hochgradig standardisierten Arbeitspaketen.
• Hybrid: Onsite-Senior-Kern + Nearshore-Delivery-Team. In der Praxis das Setup mit den ausgewogensten Gesamtkosten für die Mehrheit aller SAP-Projekte.

So berechnen Sie die realen Gesamtkosten

Berechnen Sie die Gesamtkosten anhand von vier Parametern: Tagessatz × Projekttage, Koordinationsaufwand (vom internen Team aufgewendete Managementzeit), Nacharbeitsquote und Dauer für Einarbeitung/Ramp-up. Ein Offshore-Angebot lockt womöglich mit 30 % niedrigeren Tagessätzen – wenn Koordination und Nacharbeit jedoch 40 % Zusatzaufwand verursachen, schwindet der finanzielle Vorteil.

Ein praxisnaher Health-Check: Messen Sie die durchschnittliche Durchlaufzeit zwischen dem Stellen einer technischen Frage und dem Erhalt der Antwort. Fragen, die noch am selben Arbeitstag geklärt werden, sind der spürbarste finanzielle Hebel eines Nearshore-Setups.

• Wenden Sie Tagessatzunterschiede nur auf tatsächliche Projekttage an, nicht auf das gesamte Projektbudget.
• Kalkulieren Sie die Einarbeitungszeit je nach Modell separat: typischerweise 2–4 Wochen für Nearshore gegenüber 4–8 Wochen für Offshore.
• Stützen Sie Nacharbeitsquoten auf historische Projektdaten statt auf theoretische Annahmen.
• Rechnen Sie Koordinationsstunden des internen Teams direkt in das Kostenmodell ein.

Welche Aufgaben passen zu welchem Modell?

Die Zerlegung des Scopes in einzelne Arbeitspakete versachlicht die Sourcing-Diskussion. Geschäftsprozessdesign, Key-User-Workshops und Core-Integrationsarchitektur sollten nah am Business verbleiben. ABAP-Entwicklung, Schnittstellenanpassungen, Testautomatisierung sowie Tier-2/Tier-3-Support lassen sich in Nearshore-Setups hocheffizient erbringen.

Für detaillierte Delivery-Konfigurationen entdecken Sie die drei Delivery-Modelle unter /en/shoring, prüfen Sie laufende Support-Umfänge unter /en/sap-ams-support, evaluieren Sie individuelle Rollenbesetzungen unter /en/sap-expert-staffing und informieren Sie sich über Migrationsprojekte unter /en/sap-s4hana-transformation.

Qualität und Risiko: Eine Frage des Setups, nicht des Standorts

Die meisten Herausforderungen bei der Zusammenarbeit mit Nearshore-Teams liegen nicht am Standort, sondern an strukturellen Defiziten: undefinierte Abnahmekriterien, Personenabhängigkeiten und undokumentierte Prozesse. Exakt dieselben Lücken führen auch bei Onsite-Teams zu identischen Problemen.

• Schriftliche Abnahmekriterien und definierte Deliverables für jedes Arbeitspaket.
• Ein benannter Stellvertreter für jeden kritischen Bereich (Bus-Faktor > 1).
• Gemeinsame Ticket- und Code-Repositories ohne parallele Toolchains.
• Ein präziser wöchentlicher Rhythmus: Scope, Blocker, nächste Schritte.
• Übergabepläne und Dokumentationsanforderungen, die explizit in der Exit-Klausel verankert sind.

Entscheidungsleitfaden

Wenn Ihr Scope kurz, risikoreich und konzeptionslastig ist, empfiehlt sich ein starker Onsite-Anteil. Geht es um Kontinuität, Entwicklungsvolumen oder AMS, erhöhen Sie den Nearshore-Anteil. Bei sehr großen, hochgradig standardisierten Paketen setzen Sie Offshore-Teams ein – idealerweise unter Nearshore-Koordination.

Bei OXORY beginnt jedes Shoring-Setup mit einer detaillierten Scope-Analyse: Wir definieren, welches Arbeitspaket wo erbracht wird, stimmen den Ramp-up-Zeitplan ab und finalisieren gemeinsam das kommerzielle Modell.