Ihr B2B-Shop läuft – aber er skaliert nicht. Woran das wirklich liegt.

Es gibt einen Moment in fast jedem B2B-Projekt, den wir nach fast 75 Shopware-Projekten seit 2006 auswendig kennen.

Der Shop ist live. Die Bestellungen kommen rein. Der Geschäftsführer ist zufrieden. Und dann - sechs Monate später - sitzt das Team wieder bei manuellen Korrekturen, der Vertrieb beantwortet Preisanfragen per Telefon die der Shop eigentlich beantworten sollte, und die IT erklärt zum dritten Mal warum die ERP-Synchronisation heute Nacht wieder ausgefallen ist.
Laut einer aktuellen B2B-Studie binden Standardanfragen die längst automatisiert laufen könnten bei über der Hälfte aller Unternehmen zwischen 26 und 75 Prozent der täglichen Arbeitszeit. Das ist kein Randproblem. Das ist strukturelles Versagen - und es hat fast immer dieselbe Wurzel.

Das eigentliche Problem: Der Shop wurde gebaut, aber nicht durchdacht

Der häufigste Fehler den wir sehen ist kein technischer. Es ist ein konzeptioneller.
B2B-Shops werden oft wie B2C-Shops gebaut - mit einem Frontend das gut aussieht, einer Produktliste die funktioniert, und einem Checkout der Bestellungen annimmt. Was fehlt: die saubere Abbildung der realen Geschäftslogik dahinter.

Im B2B bedeutet das konkret: Kundenindividuelle Preise. Staffelkonditionen aus Rahmenverträgen. Freigabeprozesse bei Bestellungen über bestimmten Werten. Rollen und Budgets für verschiedene Einkäufer im selben Unternehmen. Produktkataloge die sich je nach Kundengruppe unterscheiden.

All diese Logiken existieren im Unternehmen - im ERP, im CRM, in den Köpfen der Vertriebsmitarbeiter. Wenn der Shop sie nicht abbildet, übernehmen Menschen die Lücke. Und Menschen kosten mehr als Code.

Die drei häufigsten Architektur-Fehler im B2B-Shopware-Projekt

1. ERP als Flaschenhals statt als Datenquelle

   Das klassische Szenario: Der Shop fragt bei jedem Seitenaufruf live das ERP ab, um kundenindividuelle Preise zu laden. Bei 50 gleichzeitigen Nutzern - in einem B2B-Umfeld mit aktiven Einkäufern am Vormittag völlig normal - bricht die Ladezeit dramatisch ein. Der Vertrieb bekommt Anrufe. Die IT bekommt Tickets.
   Die Lösung ist keine höhere Serverlast, sondern eine andere Architektur: asynchrone Preis-Synchronisation mit intelligentem Caching, kombiniert mit einer Fallback-Logik die den Shop auch bei einem ERP-Ausfall stabil hält. Wir bauen diese Middleware seit Jahren - sie ist kein Luxus, sondern Voraussetzung für stabilen B2B-Betrieb.

2. Plugin-Stapel statt sauberer Systemarchitektur

   Shopware hat einen leistungsfähigen Plugin-Store. Das verführt dazu, Anforderungen durch Plugin-Kombinationen zu lösen statt durch saubere Architekturentscheidungen. Das Ergebnis nach zwei Jahren: 40 aktive Plugins, von denen niemand mehr genau weiß welche sich gegenseitig beeinflussen - und ein Update wird zum Projekt weil keiner weiß was danach noch funktioniert.
   Wir empfehlen unseren Kunden einen klaren Grundsatz: Ein Plugin löst genau ein Problem. Alles was Business-kritische Logik abbildet - Preisfindung, ERP-Synchronisation, Genehmigungsprozesse - gehört in sauber dokumentierten, updatefähigen eigenen Code. Das kostet mehr am Anfang. Es spart ein Vielfaches über die Laufzeit.

3. Kein Plan für Datenmigration und Datenqualität
   Ein Shopware-Projekt das scheitert, scheitert selten am Code. Es scheitert an den Daten. Produktstammdaten aus 15 Jahren ERP-Betrieb, die nie bereinigt wurden. Kundendaten mit Duplikaten, veralteten Adressen und inkonsistenten Konditionsgruppen. Bestellhistorien in Formaten die kein Migrationsskript ohne manuelle Nacharbeit sauber übernehmen kann.
   Wir beginnen jedes B2B-Migrationsprojekt mit einer vollständigen Datenanalyse bevor der erste Code geschrieben wird. Das klingt selbstverständlich - ist es aber in der Praxis erschreckend selten.

Was das in echten Zahlen bedeutet

Ein mittelständischer B2B-Händler mit 500 aktiven Kundenkonten, der täglich 80 bis 120 Bestellungen verarbeitet und dabei auf manuellen Preiskorrekturen, ERP-Nachbearbeitung und Vertriebstelefonate angewiesen ist - dieser Händler hat ein operatives Problem das sich exakt beziffern lässt.

Wenn zwei Mitarbeiter täglich zwei Stunden mit Prozessen verbringen die ein sauber integrierter Shop automatisch abwickeln würde, sind das 20 Arbeitsstunden pro Woche. Pro Jahr über 1.000 Stunden - bei einem internen Stundensatz von 50 Euro sind das 50.000 Euro direkte Prozesskosten, die ein technisch sauberes System einsparen würde.
Das ist der Grund warum unsere Kunden im ersten Jahr nach einem Shopware-Projekt im Schnitt einen ROI von 12x erzielen. Nicht weil der Shop schöner aussieht - sondern weil er die Arbeit erledigt, für die vorher Menschen bezahlt wurden.

Was eine technisch saubere B2B-Architektur in Shopware leistet

Shopware 6 ist eine exzellente Plattform für B2B-E-Commerce wenn sie richtig eingesetzt wird. Der API-First-Ansatz ermöglicht es, die Plattform als Orchestrierungsschicht zu nutzen: Preise kommen aus dem ERP, Produktlogiken aus dem PIM, Kundendaten aus dem CRM. Shopware verbindet diese Quellen und macht sie für den Einkäufer konsistent nutzbar.

Was das konkret bedeutet:

• Kundenindividuelle Preise ohne Performance-Verlust - Synchronisation statt Live-Abfrage, mit definierter Cache-Strategie und automatischem Refresh bei Konditionsänderungen im ERP.

• Freigabeprozesse die die reale Unternehmenshierarchie abbilden - Budgets, Rollen, Genehmigungsworkflows die nicht am ersten Sonderfall scheitern.

• ERP-Integration die ausfallsicher ist - mit Error-Logging, Retry-Logik und einem Betriebszustand der auch bei einer ERP-Wartungsphase stabile Bestellannahme garantiert.

• Migrations-Strategie die SEO und Datenintegrität schützt - kein Ranking-Absturz nach dem Launch, keine fehlenden Bestellhistorien, kein „Das haben wir nicht gewusst".

Wann es Zeit ist, das System zu überdenken

Nicht jedes B2B-Shopware-System muss von Grund auf neu gebaut werden. Aber es gibt klare Signale, dass die aktuelle Architektur an ihre Grenzen gestoßen ist:

• Der Vertrieb beantwortet regelmäßig Preisanfragen die der Shop eigentlich beantworten sollte

• ERP-Synchronisation läuft fehlerhaft oder erfordert regelmäßige manuelle Nacharbeit

• Updates werden aufgeschoben weil niemand weiß was danach noch funktioniert

• Die Ladezeiten verschlechtern sich mit wachsendem Katalog

• Neue Anforderungen brauchen unverhältnismäßig lange Umsetzungszeiten

Wenn drei oder mehr dieser Punkte zutreffen, lohnt sich ein technischer Audit - bevor das nächste Symptom zu einem echten Betriebsproblem wird.

Was Sie als nächstes tun können

Wir führen seit 2006 technische Analysen für B2B-Shopware-Systeme durch - von der ersten Frage ob Shopware die richtige Plattform ist, bis zur konkreten Architekturentscheidung bei komplexen ERP-Integrationen.
Ein erstes Gespräch kostet Sie 30 Minuten und bringt Ihnen eine ehrliche Einschätzung, was in Ihrem System funktioniert, was nicht - und was es kosten würde, es zu ändern.
Technisches Erstgespräch anfragen
Oder lesen Sie weiter:

• Shopware Migration: Wie wir Datenverlust und Ranking-Einbrüche verhindern

• Shopware Performance: Warum Ladezeiten direkt auf den Umsatz einzahlen

• Unsere Shopware-Leistungen im Überblick