Shopware B2B

Shopware für B2B: Eignung, Funktionen und Grenzen.

Shopware 6 ist eine solide Basis für B2B-Szenarien – aber nicht jede B2B-Anforderung ist Standard. Wir trennen sauber, was das System mitbringt, was individuell entwickelt wird und wo andere Wege sinnvoller sind.

Drei Szenarien, in denen Shopware B2B trägt

Diese Konstellationen sehen wir in Projekten regelmäßig – sie unterscheiden sich deutlich voneinander und brauchen unterschiedliche Antworten.

SZENARIO 1

B2B und B2C auf einer Plattform

Geschäftskunden und Endkunden bestellen im selben System: Kundengruppen und Regeln steuern Preise, Verpackungslogik, Zahl- und Versandarten. Das ersetzt getrennte Shops.

SZENARIO 2

Mehrere Sales Channels

Mehrere Marken, Shops oder Zielgruppen auf einer technischen Basis: zentrale Produkte und Rechte, getrennte Sortimente und Erscheinungsbilder je Kanal.

SZENARIO 3

ERP als führendes System

Kunden-, Artikel- und Bestelldaten bleiben im ERP. Shopware dient als Bestelloberfläche und Prozessplattform – ohne unnötige Datenkopien.

E-Commerce und Content auf einer technischen Basis

Shopware kann nicht nur Bestellungen abbilden. Verkaufskanäle, redaktionelle Inhalte und Informationsportale lassen sich gemeinsam betreiben, wenn Zuständigkeiten und Zielgruppen klar getrennt sind.

MEHRSPRACHIGKEIT

Mehr als übersetzte Produkttexte

Neben Katalogdaten gehören Navigation, Kategorien, Erlebniswelten, System-E-Mails und weitere Shoptexte in das Sprachkonzept. Neue Sprachen werden mit Pflege- und Freigabeprozess geplant.

REDAKTION

Inhalte über Erlebniswelten pflegen

Startseiten, Landingpages, Banner und Inhaltsbereiche können so aufgebaut werden, dass Redakteure sie ohne laufende Entwicklungsarbeit aktualisieren.

ARCHITEKTUR

Shop und Informationsportal verbinden

Ein System kann Shopware-Shops, geschützte Portale und zentral gepflegte Inhalte für unterschiedliche Partner, Regionen oder Marken bereitstellen, ohne jeden Einstieg separat zu betreiben.

Standard vs. individuelle Entwicklung

Diese Unterscheidung entscheidet über Budget und Zeitplan. Wer sie früh trifft, vermeidet die häufigsten Fehleinschätzungen.

STANDARDFUNKTIONEN

  • Kundengruppen und regelbasierte Preise
  • Mehrere Sales Channels und Sprachen
  • Rechte- und Rollenverwaltung im Backend
  • Erlebniswelten für pflegbare Inhaltsseiten
  • APIs für Produkte, Bestellungen und Kunden
  • Regeln für Versand- und Zahlungsarten

INDIVIDUELL ZU ENTWICKELN

  • Budgets, Kontingente und Punkte-Logiken
  • Freigabeprozesse mit Regeln und Vertretern
  • Kostenstellen und Bestellreferenzen im Checkout
  • OCI/PunchOut- und SAP-Ariba-Anbindung
  • Quick Order, Bulk-Bestellung und Abos
  • SSO über OpenID Connect oder SAML 2.0

Grenzen, Alternativen und Architekturentscheidungen

Wir empfehlen Shopware nur dort, wo die Kriterien passen. Diese Fragen klären wir vor jedem Projekt.

GRENZE

Tiefe Procurement-Prozesse

Wenn ein vorhandenes Einkaufssystem den Prozess bereits vollständig abbildet, kann die Integration in das Bestandssystem sinnvoller sein als ein neuer Shop.

ALTERNATIVE

Erweiterung statt Neubau

Manchmal ist eine Bestelloberfläche vor dem ERP die schlankere Lösung. Wir bewerten das im Briefing – auch gegen Shopware.

ARCHITEKTUR

Erweiterbarkeit planen

Individuelle Prozesse entstehen als Erweiterungen mit klaren Schnittstellen – nicht als Umbau des Kerns. So bleiben Updates und Erweiterungen beherrschbar.

Beispielhafte Systemlandschaft

So kann eine Shopware-B2B-Architektur aussehen: Das ERP führt die Daten, der Shop führt den Prozess.

Stammdaten aus dem ERP

ERP → Shop
  • ERP/SAP
  • Kunden & Rollen
  • Artikel & Preise
  • Shopware

Das ERP bleibt führend für Stammdaten. Der Shop erhält nur, was er für den Bestellprozess benötigt.

Bestellung zurück ins ERP

Shop → ERP
  • Checkout
  • Kostenstelle & Referenzen
  • Bestellung
  • ERP-Verarbeitung

Bestellungen gehen strukturiert zurück – inklusive Kostenstellen und Bestellnummern für die Verrechnung.

Optional: Procurement-Anbindung

Einkauf ↔ Shop
  • SAP Ariba / OCI
  • PunchOut in den Shop
  • Warenkorb zurück
  • Genehmigung im Einkauf

Der Einkauf startet im Procurement-System; Produktauswahl und Konfiguration erfolgen im Shop.

Häufige Fragen

Antworten zu Eignung, Funktionen und Alternativen von Shopware im B2B.

Shopware 6 bringt Grundlagen mit, die für B2B relevant sind: Kundengruppen, regelbasierte Preise, mehrere Sales Channels, Rechteverwaltung und Erweiterbarkeit über Plugins und APIs. Viele B2B-Anforderungen wie Budgets, Freigabeprozesse, Kostenstellen oder PunchOut entstehen als individuelle Erweiterungen. Ob Shopware passt, hängt vom Prozess ab – wir benennen auch Grenzen ehrlich.

Ja. In Projekten wird ein gemeinsamer Sales Channel vorgesehen, in dem Kundengruppen und Regeln die Unterschiede steuern: Nettopreise und Verpackungseinheiten für Geschäftskunden, Bruttopreise und Stückbestellung für Endkunden. Zahl- und Versandarten können ebenfalls pro Kundengruppe variieren.

Ja. Ein typischer Prozess sieht vor, dass Benutzer und Produktdaten aus SAP übernommen werden und Bestellungen aus dem Shop zurück an SAP fließen. Lagerbestände können synchronisiert und Sendungsnummern zurückgespielt werden. Damit kann SAP führendes System bleiben, während Shopware als Bestelloberfläche dient.

Ja. Je nach Anforderungen können mehrere Marken oder Verkaufskanäle auf einer gemeinsamen technischen Basis organisiert werden: zentral gepflegte Produkte, Rechte und Benutzerstrukturen, während jeder Shop ein eigenes Erscheinungsbild und Sortiment erhält. Ob sich das lohnt, hängt von Sortimenten und Prozessen ab.

Wenn der Prozess primär aus hochspezialisierter Beschaffungslogik besteht, die ein vorhandenes Procurement-System bereits vollständig abdeckt, oder wenn eine bestehende Plattform wirtschaftlicher erweitert werden kann, kann eine Integration in das Bestandssystem sinnvoller sein als ein neuer Shop. Wir empfehlen Shopware dort, wo die Kriterien passen – nicht grundsätzlich.