SAP-Commerce-Cloud-Implementierung: Was in einem Projekt wirklich passiert

Die meisten Texte über Implementierungen von SAP Commerce Cloud lesen sich wie ein Prospekt. Dieser Beitrag beschreibt, was in einem Projekt tatsächlich passiert: welche Entscheidungen zählen, welche Phasen länger dauern als geplant und welche Gewohnheiten einen ruhigen Go-live von einem schmerzhaften unterscheiden.

SAP Commerce Cloud ist eine ausgereifte Plattform, aber eine ausgereifte Plattform macht eine Implementierung nicht einfach. Budgets und Zeitpläne scheitern selten an der Software, sondern an Entscheidungen, die niemand früh genug getroffen hat, an Daten, die niemand angeschaut hat, und an Integrationen, die niemand sauber geplant hat.

Kurzfassung: Implementierungen von SAP Commerce Cloud dauern je nach Umfang typischerweise drei bis neun Monate. Vier Phasen entscheiden über das Ergebnis: Discovery (Architekturentscheidungen und Analyse der Anpassungen), Aufbau (iterative Lieferung in Sprints von zwei bis vier Wochen), Integration (ERP, PIM, Zahlung, Versand) und Go-live (Datenmigration, Performancetests, Umstellung). Der Discovery-Workshop und die Analyse der Anpassungen zahlen sich im Aufbau um ein Vielfaches aus.

Sie suchen einen Partner statt einer Anleitung zum Selbermachen? Spadoom ist SAP Gold Partner und realisiert SAP Commerce Cloud in der Schweiz, in Deutschland, Österreich und Italien, sowohl die Cloud Edition als auch die neue ERP Edition, zusammen mit dem ERP-Kern. Fordern Sie ein Scoping-Gespräch an oder lesen Sie die Fallstudie zu Franke.

Phase	Typische Dauer	Schwerpunkt
Discovery	Zwei bis vier Wochen	Architektur, Anforderungen, Analyse der Anpassungen
Aufbau	Sechs bis sechzehn Wochen	Datenmodell, Storefront, iterative Sprints
Integration	Vier bis acht Wochen, parallel zum Aufbau	ERP, PIM, Zahlung, Versand
Go-live	Drei bis vier Wochen	Abnahmetests, Performancetests, Datenmigration, Umstellung

Was passiert in der Discovery-Phase?

In der Discovery werden Projekte gewonnen oder verloren. Hier finden Sie die technischen Altlasten der bisherigen Plattform, bevor sie den Aufbau aus der Bahn werfen.

Eine solide Discovery (zwei bis vier Wochen) umfasst:

Architekturentscheidungen. SAP Composable Storefront oder eigenes Frontend? Wie viele Umgebungen? Welche CI/CD-Pipeline? Diese Entscheidungen lassen sich später nur schwer rückgängig machen.

Analyse der Anpassungen. Wenn Sie von On-Premise migrieren, ordnen Sie jede Anpassung ein: weiterhin nötig, durch Standardfunktionen ersetzbar oder überflüssig. Meist erweist sich ein beträchtlicher Teil als entbehrlich, und jede Anpassung, die wegfällt, ist Code, den Sie weder migrieren noch pflegen müssen.

Datenanalyse. Prüfen Sie Produktkatalog, Kundendaten, Bestellhistorie und Inhalte und finden Sie Qualitätsprobleme, bevor sie die Migration blockieren. Projekte verlieren Wochen, wenn sich niemand die Produktdaten vor dem vierten Sprint ansieht.

Integrationslandkarte. Dokumentieren Sie jede eingehende und ausgehende Verbindung: ERP, PIM, CRM, Zahlung, Versand, Steuern, Analytics. Für jede: Protokoll, Datenformat, Frequenz und Fehlerbehandlung.

Teamstruktur und Governance. Wer verantwortet was, wie werden Entscheidungen getroffen, wöchentliche Demos oder monatliche Reviews? Projekte mit unklarer Governance ziehen sich in die Länge.

Wie sollte die Aufbauphase ablaufen?

Implementierungen von Commerce Cloud funktionieren am besten iterativ: Sprints von zwei bis vier Wochen, jeder mit einem lauffähigen Zwischenstand.

Sprint 1: Datenmodell und Grundkonfiguration. Eigene Typen, Katalogstruktur, Preisregeln, Promotion-Engine. Ziel ist ein funktionierender Katalog auf Staging innerhalb der ersten Wochen.

Sprints 2 und 3: Storefront und Checkout. Storefront mit Ihren Produktdaten ausrollen, Checkout, Warenkorblogik und Kontoverwaltung bauen. Jeder Sprint liefert etwas, das die Beteiligten nutzen und kommentieren können.

Ab Sprint 4: Geschäftslogik und Sonderfälle. Kundenspezifische und mengenabhängige Preise, Bestände über mehrere Lager, B2B-Funktionen wie Freigabeprozesse, Bestelllimiten und Einkäuferhierarchien.

Entscheidend ist die Disziplin: Jeder Sprint endet mit einem lauffähigen System, das die Beteiligten testen können. «Im vierten Monat zeigen wir Ihnen etwas» ist zu spät, um noch umzusteuern.

Warum ist die Integration der schwierigste Teil?

Die Integration ist oft der grösste einzelne Aufwandsblock. Diese Verbindungen zählen am meisten.

ERP (SAP S/4HANA, ECC). Auftragsexport, Bestandsabgleich, Preise, Kundenstammdaten. Meist die komplexeste Integration und diejenige, die funktionieren muss: Wenn Aufträge nicht im ERP ankommen, ist alles andere egal. Das Integrationsmodul von SAP für das Auftragsmanagement mit S/4HANA deckt Echtzeitpreise, Bestände, Kreditprüfungen und synchrone Auftragsanlage für B2B im Composable Storefront ab, das Mapping auf Ihre ERP-Konfiguration bleibt aber Projektarbeit. Wir liefern Commerce- und ERP-Seite mit einem Team; warum das wichtig ist, erklärt unser Beitrag zum integrierten Stack aus S/4HANA Public Cloud und Sales Cloud V2. Läuft dahinter noch SAP ECC, planen Sie die Commerce-Integration gegen das Zielsystem: Unser Überblick zum Wartungsende von SAP ECC 2027 zeigt Fristen und Migrationswege.

PIM. Produktdaten-Feeds, Medien, Klassifikationshierarchien. Ist das PIM das führende System für Produktdaten, brauchen Sie eine Integration in Echtzeit oder nahezu in Echtzeit.

Zahlung. Anbindung des Zahlungsanbieters, Tokenisierung, 3-D Secure, Rückerstattungen. Commerce Cloud unterstützt mehrere Zahlungs-Extensions, und die richtige zu wählen und zu konfigurieren, ist wichtiger, als viele erwarten.

Versand und Logistik. Frachtberechnung, Etikettendruck, Sendungsverfolgung. Oft mehrere Transporteure mit unterschiedlichen APIs.

Was funktioniert: Starten Sie die Integrationsentwicklung parallel zu den späteren Aufbau-Sprints, statt zu warten, bis die Plattform «fertig» ist. Sonst hängt eine lange Integrationsphase an einem ohnehin langen Aufbau.

Was gehört zum Go-live wirklich dazu?

Abnahmetests (zwei bis drei Wochen). Fachanwender, nicht Entwickler, testen jeden kritischen Ablauf mit echten Daten. Sie finden, was Entwickler nie finden würden.

Performancetests. Lasttests mit realistischem Verkehr inklusive Simulation eines Spitzentags, geprüftes Autoscaling und Ladezeiten gegen Zielwerte. Die Skalierung der Infrastruktur übernimmt Commerce Cloud, Ihr eigener Code und Ihre Datenabfragen müssen trotzdem performant sein.

Generalprobe der Datenmigration. Führen Sie die gesamte Migration einmal vollständig durch und messen Sie die Dauer: Sie bestimmt Ihr Umstellungsfenster. Testen Sie die Delta-Migration für Daten, die während des Übergangs entstehen.

Umstellung. Arbeiten Sie das Go-live-Drehbuch ab: altes System einfrieren, Delta-Migration ausführen, DNS umstellen, zentrale Abläufe prüfen und 48 Stunden lang mit dem ganzen Team in Bereitschaft überwachen. Danach übernimmt die Messung: Welche KPIs zählen und welche Werkzeuge Sie anbinden, beschreibt unser Beitrag zu Commerce-Cloud-Analytics und Shop-Performance.

Wer von SAP Commerce On-Premise migriert, sollte wissen, dass die Mainstream-Wartung der On-Premise-Version am 31. Juli 2026 endete; die Optionen beschreibt unser Beitrag dazu, was nach dem Ende des On-Premise-Supports zu tun ist.

Was unterscheidet gute Implementierungen von schlechten?

Investition in die Discovery. Projekte, die zwei bis vier Wochen in eine saubere Discovery investieren, sparen im Aufbau ein Vielfaches davon. Projekte, die sie auslassen, verbringen den Aufbau damit herauszufinden, was sie hätten planen sollen.

Disziplin beim Umfang. Das grösste Risiko ist nicht technisch, sondern ein wachsender Umfang. «Wenn wir schon dabei sind, könnten wir auch noch …» macht aus einem Viermonatsprojekt eines mit neun Monaten. Definieren Sie das erste Release, liefern Sie es aus und bauen Sie dann weiter. Sie sagen nicht für immer nein, sondern: noch nicht.

Integration zuerst. Beginnen Sie die Integrationsarchitektur in der Discovery und die Integrationsentwicklung in Sprint 2 oder 3. Die Plattform nützt erst etwas, wenn sie mit Ihrem ERP verbunden ist.

Zur Plattform selbst lesen Sie unseren Überblick zu SAP Commerce Cloud und die Schritt-für-Schritt-Einrichtung weiter unten. Zum Budget schlüsselt unser Leitfaden zu Preisen und TCO Lizenz-, Implementierungs- und Betriebskosten auf. Und wer Partner vergleicht, findet in unserer Übersicht der besten SAP-Commerce-Cloud-Partner in der Schweiz die Kriterien.

Wie richten Sie SAP Commerce Cloud Schritt für Schritt ein?

Technisch durchläuft die Einrichtung von Commerce Cloud zehn Schritte. Datenmodellierung und ERP-Integration bestimmen den kritischen Pfad; die meisten Verzögerungen entstehen, weil einer der beiden unterschätzt wird.

1. Bereitstellung der Umgebungen: SAP stellt das Cloud Portal und drei Umgebungen bereit (Entwicklung, Staging, Produktion), jede mit eigener Datenbank, eigenem Suchindex und eigener Konfiguration.
2. Projektaufbau: Rezept wählen (B2C, B2B oder eigenes), benötigte Extensions aktivieren und über das Frontend entscheiden; die Build-Konfiguration liegt in manifest.json.
3. Datenmodellierung: Produkt-, Kunden- und Katalogmodell über das Typsystem erweitern und die bestehenden Produktdaten darauf abbilden.
4. Konfiguration des Storefronts: Theme, Navigation, CMS-Vorlagen und Content-Slots, responsive Layouts und SEO-Einstellungen.
5. ERP-Integration: Echtzeitpreise und Verfügbarkeit, Kundenstammdaten, Auftragsreplikation und Kreditprüfung, meist über SAP Integration Suite.
6. Zahlung und Versand: Zahlungsanbieter, Lieferarten je Land und eine Steuer-Engine für grenzüberschreitenden Verkauf.
7. Inhalte erstellen: Produkttexte, Bilder und Landingpages in SmartEdit; grosse Datenmengen über ImpEx oder Hot Folders.
8. Tests: Funktion, Integration, Performance, Sicherheit, Browser und Geräte.
9. Performance-Optimierung: Caching, Suchindex, Auslieferung über das CDN, Datenbankabfragen und Autoscaling für Lastspitzen.
10. Go-live und Stabilisierung: deployen, DNS umstellen und zwei bis vier Wochen enges Monitoring einplanen.

Brauchen Sie Unterstützung bei der Umsetzung?

Spadoom realisiert SAP Commerce Cloud von Anfang bis Ende: die Cloud Edition für B2B und B2C im Enterprise-Umfeld, die ERP Edition für mittelständische Unternehmen auf S/4HANA Public Cloud und Hybris-Migrationen weg von On-Premise. Bei Franke haben wir eine festgefahrene Plattform übernommen, den Commerce-Launch in 90 Tagen live gebracht und die manuellen Bestellungen um 75 % reduziert; das Projekt erhielt den SAP Quality Award für «Rapid Time to Value». Jedes Projekt beginnt bei uns mit einem Discovery-Workshop, der die Architektur festlegt, die Integrationen erfasst und einen realistischen Zeitplan liefert. Sprechen Sie mit uns.

Häufige Fragen

Wie lange dauert eine typische SAP-Commerce-Cloud-Implementierung?

Das hängt vom Umfang ab. Die meisten Projekte dauern drei bis neun Monate: eine Migration von On-Premise mit moderatem Anpassungsumfang oft drei bis sechs Monate, eine B2B-Neuimplementierung mit mehreren Storefronts, vielen Integrationen und eigener Geschäftslogik sechs bis neun Monate. Bei Franke ging der Commerce-Launch in 90 Tagen live. Die grösste Variable ist die Komplexität der Integration, nicht die Konfiguration der Plattform.

Was kostet eine SAP-Commerce-Cloud-Implementierung?

Bei mittelständischen Projekten liegen die Implementierungskosten meist im mittleren sechsstelligen Bereich; komplexe Enterprise-Programme können eine Million übersteigen. Die wichtigsten Kostentreiber sind die Zahl der Integrationen, die Komplexität der Anpassungen, das Datenvolumen, die Zahl der Storefronts und Märkte und die Frage, ob Sie von einem bestehenden SAP-System migrieren oder neu beginnen.

Welches Team brauchen wir für ein SAP-Commerce-Cloud-Projekt?

Ein typisches mittelgrosses Projekt braucht drei bis fünf Implementierungsberater (SAP Commerce, Frontend, Integration) und zwei bis drei Personen auf Kundenseite (Product Owner, Business Analyst, IT-Ansprechperson). Die wichtigste Rolle ist der Product Owner auf Kundenseite, weil er über den Umfang entscheidet und den fachlichen Kontext liefert. Projekte ohne eigenen Product Owner dauern durchgehend länger.

Sollten wir den Composable Storefront oder ein eigenes Frontend verwenden?

Starten Sie in den meisten Projekten mit dem SAP Composable Storefront: Er ist in die Plattform integriert, wird aktiv weiterentwickelt und deckt Standardszenarien im B2B und B2C ab. Ein eigenes Frontend mit React oder Next.js lohnt sich, wenn Sie ein grundlegend anderes Nutzererlebnis brauchen oder mehrere sehr unterschiedliche Storefronts betreiben; es verlängert den Aufbau um einige Wochen und braucht eigene Frontend-Entwickler für die Wartung. Unser Vergleich von Composable Storefront und React/Next.js geht ins Detail.

Was ist der häufigste Grund, warum Commerce-Cloud-Implementierungen das Budget überschreiten?

Eine Integrationskomplexität, die in der Discovery nicht sauber erfasst wurde, gefolgt von einem wachsenden Umfang während des Aufbaus. Beides lässt sich mit einer disziplinierten Discovery verhindern, die jede Integration erfasst und jede Anpassung einordnet, und mit einem klar definierten ersten Release.

Wie funktioniert das Deployment?

Die Projektkonfiguration liegt in einer Datei manifest.json in Ihrem Code-Repository. Im Cloud Portal erstellen Sie aus einem Branch einen Build und deployen ihn in die Entwicklungs-, Staging- oder Produktionsumgebung. Rolling Deployments erlauben Updates der Produktion ohne Ausfallzeit.