Shopware B2B: Komponenten vor der Aufwandsschätzung prüfen

Ein Händler sieht den Katalog in Shopware, kann seinen Warenkorb aber nicht zur Freigabe einreichen. Das Team plant bereits ein eigenes Modul, obwohl die Ursache in der Version, dem kommerziellen Plan oder einer für den Kunden nicht aktivierten Funktion liegen kann. Bewerten Sie Shopware B2B anhand der konkreten Installation, nicht anhand einer Funktionsliste in einer Präsentation. Prüfen Sie zuerst die Verfügbarkeit der Komponente, dann ihre Konfiguration und erst danach den Entwicklungsbedarf.

Fit-Gap bedeutet, eine Geschäftsanforderung mit den funktionierenden Möglichkeiten abzugleichen und die Lücke festzustellen. Das Ergebnis ist eine belegte Lösungskarte: Standardkern, offizielle kommerzielle Komponente, Drittanbieter-Erweiterung oder individuelle Entwicklung.

1. Erfassen Sie den Installationsstand vor der Funktionsdiskussion

Notieren Sie die vollständige installierte Shopware-Version, das Bereitstellungsmodell, den aktuellen Plan und die vertraglichen Nutzungsrechte. Erfassen Sie separat Version und Status von Shopware Commercial, aktive B2B-Komponenten, Drittanbieter-Erweiterungen, Theme und eigene Änderungen. „Shopware 6“ reicht nicht aus: Die Bezeichnung erklärt weder die Möglichkeiten Ihres konkreten Shops noch mögliche Update-Hindernisse.

Plan, Erweiterung und Aktivierung sind getrennte Voraussetzungen

Laut der am 10. November 2026 geprüften offiziellen Dokumentation sind B2B Components ab dem Evolve-Plan über die Erweiterung Shopware Commercial verfügbar. „B2B vorhanden“ bedeutet daher nicht, dass jede Installation oder der kostenlose Kern alle Funktionen enthält. Ein Nutzungsrecht belegt ebenfalls nicht, dass die benötigte Erweiterung installiert, aktiv und konfiguriert ist.

Die Dokumentation nennt Employee Management ab Shopware 6.5.6.0 und Bestellfreigaben ab 6.5.8.0, jeweils mit dem Evolve-Plan. Dies sind die Versionen, mit denen die Funktionen eingeführt wurden, keine Empfehlung, auf diesen alten Versionen zu bleiben. Prüfen Sie vor Änderungen die aktuelle Kompatibilität von Plattform und Commercial; wählen Sie eine Version nicht nur anhand eines einzigen B2B-Szenarios.

2. Prüfen Sie, für wen die Komponenten aktiviert sind

Die Dokumentation der B2B Components beschreibt mehrere Ebenen der Verfügbarkeit. Für einzelne Kunden werden Funktionen im administrativen Kundendatensatz unter Customers → Overview aktiviert. Für eine Kundengruppe lassen sich B2B-Funktionen bei der Registrierung voreinstellen; dafür muss das entsprechende angepasste Registrierungsformular der Gruppe aktiviert sein.

Globale Vorgaben unter Settings → Customer → B2B Components gelten ausschließlich für neu angelegte Geschäftskunden. Sie aktualisieren bestehende Unternehmen nicht gesammelt. Wenn eine Funktion bei einem neuen Händler erscheint, bei einem bestehenden aber fehlt, vergleichen Sie zuerst die Einstellungen. Beauftragen Sie kein Migrationsskript, bevor geklärt ist, ob das Problem tatsächlich eine Datenänderung erfordert.

3. Erstellen Sie eine Abdeckungsmatrix statt einer Wunschliste

Eine Kompatibilitätsmatrix der Komponenten muss mit einem überprüfbaren Ergebnis beginnen. Schreiben Sie statt „wir brauchen Unternehmensrollen“: „Ein Mitarbeiter erstellt einen Warenkorb, schließt die Bestellung aber nicht ohne die festgelegte Freigabe ab.“ Die Geschäftslogik der Rollen lässt sich separat anhand des Artikels zum B2B-Self-Service-Portal präzisieren; hier geht es dagegen darum, den Mechanismus in einer konkreten Shopware-Installation zu finden.

Ergänzen Sie pro Zeile Priorität, Verantwortlichen für die Geschäftsregel, Umsetzungsweg, Abhängigkeit und Status. Sinnvolle Statusangaben sind „durch Test bestätigt“, „Konfiguration erforderlich“, „Update erforderlich“, „Untersuchung erforderlich“ und „Lücke“. Kennzeichnen Sie eine unbekannte Möglichkeit nicht als individuelle Entwicklung: Unkenntnis der Dokumentation beweist nicht, dass kein fertiger Mechanismus existiert.

4. Trennen Sie Konfiguration, Erweiterung und individuelle Entwicklung

In Kostenschätzungen kann „Standard“ Unterschiedliches bedeuten. Trennen Sie den Shopware-Kern von offiziellen kommerziellen Komponenten: Letztere werden nicht zum kostenlosen Kern, nur weil sie vom Hersteller stammen. Eine Drittanbieter-Erweiterung hat einen anderen Anbieter und einen eigenen Supportzyklus. Individuelle Entwicklung bedeutet Code und Verantwortung bei Ihrem Team oder Auftragnehmer.

Wann Konfiguration ausreicht

Lässt sich der benötigte Ablauf nach Aktivierung einer Komponente und Einstellung der Regeln vollständig reproduzieren, kalkulieren Sie Konfiguration, Tests und Schulung statt einer Neuentwicklung. Lassen Sie sich das Szenario mit der vereinbarten Konfiguration vorführen. Als Ergebnis sollten eine Parameterbeschreibung, Testdaten und ein Kriterium für die erneute Prüfung nach einem Update vorliegen.

Deckt ein fertiges Werkzeug nur einen Teil der Anforderung ab, benennen Sie die Grenze. Eine Freigabe im Shop belegt beispielsweise noch keine Versandsperre wegen offener Schulden im ERP. Auch Vertragspreise erfordern eine gesonderte Prüfung von Mechanismus und Nutzungsrechten: Aus der Verfügbarkeit von B2B Components folgt nicht die Verfügbarkeit jedes Preismodells.

Wann eine Anpassung gerechtfertigt ist

Erwägen Sie individuelle Entwicklung für eine konkrete nicht abgedeckte Regel, nicht allgemein zur „Verbesserung von B2B“. Beschreiben Sie Eingangsdaten, Ergebnis, Fehler, Verantwortungsgrenzen und Update-Verfahren. Prüfen Sie vor der Auswahl eines Drittanbietermoduls nicht nur die Funktionsbeschreibung, sondern auch Konflikte, unterstützte Versionen, Datenexport und die Zuständigkeit bei Störungen im Zusammenspiel mit Commercial.

5. Hypothetisches Beispiel: Freigaben funktionieren nur für neue Händler

Dies ist ein hypothetisches Szenario, kein GL.ua-Projekt. Ein Großhändler nutzt Shopware mit Evolve-Plan, installiertem Commercial und einer zu den benötigten Komponenten passenden Version. Ein neues Unternehmen kann den Freigabeablauf nutzen, ein bestehender Händler nicht. Außerdem möchte das Unternehmen die Übermittlung einer Bestellung an das ERP verhindern, wenn die Warenwirtschaft überfällige Schulden meldet.

Der erste Prüfschritt besteht nicht darin, einen neuen Kundenbereich zu entwickeln. Das Team vergleicht die Komponentenaktivierung beider Unternehmen und die Freigaberegeln. Da globale Einstellungen nur neue Geschäftskunden betreffen, wird der Datensatz des bestehenden Händlers separat geprüft. Funktioniert das Szenario nach korrekter Konfiguration, wird diese Matrixzeile durch Konfiguration geschlossen.

Die Schuldenregel bleibt bis zur Integrationsprüfung eine eigene Lücke. Ein beispielhaftes Abnahmekriterium lautet: Bestätigt das ERP eine Sperre, wird die Bestellung nicht weitergeleitet, und die verantwortliche Person sieht den Grund. Ist das ERP nicht erreichbar, handelt das System nach einer zuvor vereinbarten Regelung, statt stillschweigend Schuldenfreiheit anzunehmen. Das ist eine Anforderung des Beispiels, kein Versprechen zum Standardverhalten von Shopware.

Die Lösung wird in zwei Aufgaben aufgeteilt: Konfiguration der verfügbaren Komponente und Untersuchung der Schuldenprüfung. Für die zweite Aufgabe werden zunächst das ERP-Antwortformat, der Prüfzeitpunkt und die Wiederholungsregel benötigt. Erst nach einem Test wird eine fertige Erweiterung oder eigener Code ausgewählt. So vermischt die Kalkulation keine Konfigurationskorrektur mit tatsächlich neuer Geschäftslogik.

6. Führen Sie vor dem Start aufeinanderfolgende Tests durch

Führen Sie die Abnahme der B2B-Funktionen in einer Testumgebung mit passender Konfiguration und anonymisierten Daten durch. Halten Sie für jeden Schritt das erwartete Ergebnis und den tatsächlichen Nachweis fest.

1. Gleichen Sie die Versionen von Shopware, Commercial und abhängigen Erweiterungen mit dem erfassten Installationsstand ab. Bestätigen Sie Nutzungsrechte und das Fehlen nicht vereinbarter Unterschiede zwischen den Umgebungen.
2. Prüfen Sie bestehende und neue Geschäftskunden getrennt, die Registrierung über das Gruppenformular sowie gewöhnliche Käufer. Funktionen dürfen nur für die vereinbarten Kundengruppen verfügbar sein.
3. Durchlaufen Sie den erlaubten Prozess der Bestellerstellung und Freigabe. Versuchen Sie anschließend den Abschluss mit einem Nutzer ohne erforderliche Berechtigung und dokumentieren Sie die Ablehnung.
4. Ändern Sie den Warenkorb nach der Freigabe, sofern dieses Szenario in Ihrer Konfiguration möglich ist. Prüfen Sie, ob das Ergebnis der vereinbarten Regel zur erneuten Kontrolle entspricht.
5. Prüfen Sie ERP-Antwort, Nichterreichbarkeit und erneute Übermittlung. Die Abnahmebedingungen müssen einen unbemerkten Bestellverlust und unkontrollierte Duplikate ausschließen.
6. Wiederholen Sie kritische Szenarien nach dem geplanten Update auf einer Testkopie. Prüfen Sie Wiederherstellung und Rollback, bevor Sie die Produktivumgebung ändern.

7. Bewerten Sie Risiken, Kostenbestandteile und Terminabhängigkeiten

Das größte Risiko besteht darin, einen Komponentennamen mit einer erfüllten Anforderung gleichzusetzen. Weitere Risiken sind inkompatible Drittanbietermodule, unterschiedliche Umgebungsparameter, geänderte vertragliche Verfügbarkeit und eigener Code ohne Regressionstests. Bestimmen Sie für jedes Risiko Erkennungsmethode und Verantwortlichen. Prüfen Sie besonders, ob zwei Module denselben Prozess doppelt abbilden oder dieselben Daten verändern.

Die Kosten setzen sich aus Bestandsaufnahme und Fit-Gap, Nutzungsrechten für Plan und Erweiterungen, Update, Konfiguration, Integrationen, Anpassungen, Tests und Schulung zusammen. Ergänzen Sie Infrastruktur der Testumgebung, Support und erneute Prüfungen nach Releases. Das sind getrennte Kostenpositionen: Einmalige Entwicklung ersetzt weder regelmäßige Zahlungen noch Wartung.

Die Dauer hängt vom Zugriff auf Installation und Vertrag, dem Update-Stand, der Modulkompatibilität, der ERP-Bereitschaft und der Geschwindigkeit der Regelabstimmung ab. Die Reihenfolge lautet: Installationsstand → Verfügbarkeitsprüfung → Demonstration des riskanten Szenarios → Lückenbewertung → Umsetzung → Abnahme. Eine unbekannte Integration sollte nicht hinter einem exakten Kalendertermin in der Gesamtkalkulation versteckt werden.

Nach der Fit-Gap-Analyse können Sie eine vergleichbare Anfrage an Auftragnehmer vorbereiten: bestätigte Komponenten, offene Anforderungen, Nachweise und Ausschlüsse. Bei der Wahl des Beschaffungsformats hilft der Artikel über RFI, RFP und RFQ für einen Onlineshop. Übergeben Sie bereits geprüfte Grenzen statt der Annahme, jeder B2B-Wunsch sei im Plan enthalten.

8. Entscheiden Sie anhand der Lücken, nicht der Plattformmarke

Ein gutes Prüfergebnis ist eine kurze Liste bestätigter Möglichkeiten, Einstellungen, Abhängigkeiten und separater Anpassungen. Deckt die bestehende Shopware-Installation kritische Szenarien ab, rechtfertigt allein die Komplexität der Erstkonfiguration keinen Plattformwechsel. Sind die Lücken erheblich, vergleichen Sie Alternativen anhand gleicher Abnahmeregeln und der vollständigen Supportkosten.

Um die Geschäftsarchitektur eines Websystems auf Drupal zu besprechen, kontaktieren Sie GL.ua (Glyanec) über die Seite zur Website-Entwicklung für Unternehmen. Bereiten Sie eine Anforderungsübersicht, Datenverantwortliche und geprüfte Lücken vor. Das ist die Grundlage einer konkreten Beratung, kein Versprechen einer Shopware-Implementierung und keine Empfehlung, Ihre Plattform zwingend zu ersetzen.