--- title: "Neuen B2B-Shop starten: Wo anfangen? Checkliste für Shopware" description: "Ein neuer B2B-Shop beginnt nicht mit dem Design. Unsere Checkliste zeigt, wie Prozesse, Daten, Shopware, Schnittstellen und Rollout sinnvoll geplant werden." canonical_url: "https://nuonic.de/insights/b2b-shop-starten-checkliste-shopware" --- Ein neuer B2B-Shop startet nicht mit Design oder Lastenheft, sondern mit einem klaren Geschäftsziel, echten Kundenprozessen und einer früh verfügbaren Shopware-Basis, an der Daten, Preise und ERP-Integration mit realen Beispielen geprüft werden. Aus der großen Vision entsteht so ein kontrollierbares MVP mit Pilotkunden statt eines Big-Bang-Go-lives. Denn ein neuer B2B-Shop soll Preise individualisieren, Bestellungen automatisieren, den Vertrieb entlasten und sich nahtlos mit ERP, PIM und CRM verbinden. Schon nach dem ersten Workshop entstehen lange Listen: Kundengruppen, Freigaben, Budgets, Angebote, Schnellbestellungen, Lieferadressen, Zahlungsbedingungen, kundenspezifische Sortimente und vieles mehr. Genau an diesem Punkt geraten viele Projekte ins Stocken. Wo soll man anfangen, wenn fast jeder Prozess wichtig erscheint und zahlreiche Abhängigkeiten noch unklar sind? Die wichtigste Empfehlung lautet: **Früh mit der Commerce-Plattform beginnen – nicht erst, wenn jede Anforderung abschließend dokumentiert wurde.** Das bedeutet nicht, einen unfertigen Shop früh live zu schalten. Es bedeutet, so früh wie möglich eine belastbare Shopware-Basis aufzubauen, an der Prozesse, Daten und Integrationen mit echten Beispielen geprüft werden können. Dieser Beitrag zeigt, wie ein B2B-Commerce-Projekt strukturiert gestartet wird, welche Entscheidungen zuerst getroffen werden sollten und wie aus einer großen Vision ein kontrollierbares MVP entsteht. ## Warum B2B-Projekte anders starten als klassische Onlineshops Im B2C-Commerce kann ein Shop häufig mit einem einheitlichen Sortiment, einer Preisliste und einem überschaubaren Checkout beginnen. Im B2B-Handel ist die Kaufoberfläche nur der sichtbare Teil eines größeren Vertriebs- und Beschaffungssystems. Ein Geschäftskunde erwartet möglicherweise: - individuelle Preise, Rabatte oder Staffelpreise, - ein freigegebenes Sortiment statt des vollständigen Katalogs, - mehrere Mitarbeiterkonten innerhalb eines Unternehmens, - Rollen, Budgets und Bestellfreigaben, - unterschiedliche Rechnungs- und Lieferadressen je Organisationseinheit, - Bestellungen per Artikelnummer, CSV oder Einkaufsliste, - Angebotsanfragen und persönliche Preisverhandlungen, - eigene Zahlungs- und Lieferbedingungen, - Zugriff auf Belege, Aufträge, Lieferscheine oder Rechnungen aus dem ERP, - Wiederbestellungen mit möglichst wenigen Schritten. Damit wird der neue Shop zu einem Teil der bestehenden Organisation. Vertrieb, Customer Service, Einkauf, IT, Buchhaltung, Logistik und Produktmanagement sind betroffen. Wer nur ein Webdesign-Projekt plant, erkennt viele kritische Fragen erst kurz vor dem Go-live. ## Der häufigste Fehlstart: Erst alles spezifizieren, dann Shopware installieren Ein umfangreiches Lastenheft vermittelt Sicherheit. Es kann jedoch nur beschreiben, was das Projektteam zu diesem Zeitpunkt verstanden hat. Viele Annahmen werden erst konkret, wenn echte Kunden, Artikel, Preise und Aufträge in einer funktionierenden Plattform sichtbar sind. Typische späte Überraschungen sind: - Artikelnummern und Varianten sind im ERP anders strukturiert als erwartet. - Eine vermeintliche Preisliste besteht tatsächlich aus zahlreichen Ausnahmen. - Kundennummer, Debitor und Lieferadresse lassen sich nicht eindeutig zuordnen. - Freigabeprozesse unterscheiden sich je Kunde oder Niederlassung. - Produktdaten sind zwar vorhanden, aber nicht für die digitale Suche geeignet. - Das ERP kann Daten lesen, aber bestimmte Änderungen nicht zuverlässig zurückschreiben. - Ein Prozess funktioniert intern, ist für den Einkäufer im Shop jedoch zu kompliziert. Wenn die Plattform erst nach mehreren Monaten Spezifikation hinzukommt, werden diese Erkenntnisse teuer. Datenmodell, Schnittstellen und bereits freigegebene Konzepte müssen dann gemeinsam geändert werden. ## Warum die Plattform so früh wie möglich bereitstehen sollte Ein früher Projektshop macht Annahmen überprüfbar. Bereits ein abgesicherter Entwicklungsstand mit wenigen Beispielkunden und Produkten schafft mehr Erkenntnis als zahlreiche abstrakte Prozessdiagramme. ### Anforderungen werden konkret Ein Vertriebsmitarbeiter kann an einem echten Beispiel zeigen, warum Kunde A andere Preise und Kunde B einen Freigabeprozess benötigt. Fachbegriffe werden zu sichtbaren Eingabefeldern, Regeln und Statuswerten. ### Datenprobleme werden früh sichtbar Ein erster Import von 50 repräsentativen Artikeln zeigt schnell, ob Medien, Einheiten, Varianten, Staffelpreise, Zubehörbeziehungen und Suchbegriffe ausreichen. Dafür muss nicht der gesamte Katalog migriert sein. ### Schnittstellen können vertikal getestet werden Statt zunächst jede API vollständig zu entwickeln, wird ein durchgängiger Geschäftsfall aufgebaut: Kunde synchronisieren, Artikel anzeigen, Preis ermitteln, Bestellung auslösen und Auftragsstatus zurückgeben. Dieser „Vertical Slice“ deckt technische und organisatorische Lücken früh auf. ### Fachbereiche entscheiden am gleichen Gegenstand Vertrieb, IT und Logistik diskutieren nicht länger drei unterschiedliche Vorstellungen desselben Prozesses. Sie beurteilen einen gemeinsamen, funktionierenden Stand. ### Schulung und Veränderung beginnen vor dem Go-live Key User können die neue Arbeitsweise früh kennenlernen, Rückmeldungen geben und später Kollegen oder Pilotkunden unterstützen. Akzeptanz entsteht nicht erst mit der Einführungs-E-Mail. Wichtig ist die Unterscheidung: **Früh mit der Plattform starten heißt früh lernen – nicht früh alles fertig bauen.** Architekturentscheidungen sollten bewusst getroffen werden, Funktionen aber nach Nutzen und Risiko priorisiert entstehen. ## Self-Service entlastet den Vertrieb – wenn er vollständig gedacht wird Eines der stärksten Argumente für einen B2B-Shop ist nicht zusätzlicher Umsatz allein, sondern die bessere Verteilung von Arbeit. In vielen Unternehmen verwendet der Vertrieb einen erheblichen Teil seiner Zeit auf wiederkehrende, administrative Vorgänge: - Bestellungen aus E-Mails oder PDFs in das ERP übertragen, - Artikelnummern und Verfügbarkeiten heraussuchen, - kundenspezifische Preise bestätigen, - Auftragsstatus und Liefertermine beantworten, - Rechnungen, Lieferscheine oder Datenblätter erneut versenden, - bestehende Warenkörbe für Wiederbestellungen rekonstruieren, - neue Ansprechpartner oder Lieferadressen manuell pflegen. Diese Tätigkeiten sind notwendig, schaffen aber selten den größten Vertriebswert. Ein gut integrierter B2B-Shop macht sie für Kunden rund um die Uhr selbstständig verfügbar. ### Was Kunden im Self-Service erledigen können sollten Ein wirkungsvoller Self-Service endet nicht am Warenkorb. Geschäftskunden sollten – abhängig von ihren Rechten – möglichst eigenständig: - das für sie freigegebene Sortiment und ihre Konditionen sehen, - Verfügbarkeit, Lieferzeit und Verpackungseinheit prüfen, - per Suche, Artikelnummer, CSV oder Einkaufsliste bestellen, - Angebote anfragen und deren Status verfolgen, - Mitarbeiter, Rollen und Freigaben verwalten, - Lieferadressen und Bestellreferenzen auswählen, - frühere Aufträge erneut bestellen, - Bestellstatus und Versandinformationen abrufen, - Rechnungen, Lieferscheine und Produktdokumente herunterladen. Der Nutzen entsteht nur, wenn Informationen zuverlässig und verständlich sind. Ein Kundenportal mit veralteten Beständen, unklaren Preisen oder fehlenden Belegen erzeugt zusätzliche Rückfragen und belastet den Vertrieb stärker statt weniger. ### Was sich für Vertriebsmitarbeiter verändert Self-Service ersetzt den persönlichen Vertrieb nicht. Er verschiebt dessen Arbeit von der Auftragserfassung zur Kundenentwicklung. Vertriebsmitarbeiter gewinnen mehr Zeit für: - Beratung bei komplexen Produkten und Anwendungen, - individuelle Angebote und Verhandlungen, - Entwicklung von Bestandskunden und Cross-Selling, - Reaktivierung inaktiver Kunden, - Gewinnung neuer Geschäftskunden, - Analyse von Bedarf, Sortiment und Kaufverhalten, - persönliche Eskalation, wenn der digitale Weg nicht ausreicht. Der Shop wird damit zum digitalen Kollegen des Vertriebs. Standardfälle laufen automatisiert, während Sonderfälle gezielt an einen Menschen übergeben werden. Wichtig ist ein sichtbarer Übergang: Kunden müssen jederzeit erkennen, wann sie selbst weiterkommen und wie sie bei einer komplexen Frage ihren bekannten Ansprechpartner erreichen. ### Vertrieb von Anfang an beteiligen Wird der Shop als reines IT-Projekt eingeführt, kann er intern als Konkurrenz oder Kontrollinstrument wahrgenommen werden. Deshalb sollten ausgewählte Vertriebsmitarbeiter schon am Daten-Sample, den Pilotkunden und den Self-Service-Prozessen mitarbeiten. Ihre Erfahrung zeigt, welche Ausnahmen wirklich geschäftskritisch sind. Im Gegenzug muss das Ziel klar sein: Der digitale Kanal nimmt repetitive Arbeit ab und liefert bessere Informationen für die persönliche Betreuung. Auch Provisions-, Ziel- und Zuständigkeitsmodelle dürfen digitale Bestellungen nicht gegen den betreuenden Vertrieb ausspielen. ### So wird die Entlastung messbar Geeignete Kennzahlen vor und nach dem Pilot sind: - Anteil der Bestellungen, die ohne manuelle Erfassung ins ERP gelangen, - Minuten interner Bearbeitungszeit pro Standardauftrag, - Anzahl der Status-, Preis- und Beleganfragen je 100 Bestellungen, - Anteil erfolgreicher Wiederbestellungen im Self-Service, - aktive Kundenkonten und aktive Mitarbeiterkonten, - Abbruchquote bei Suche, Warenkorb und Freigabe, - Zeit von der Angebotsanfrage bis zum versendeten Angebot, - Anteil der Vertriebszeit für Beratung gegenüber Administration. Diese KPIs gehören bereits in die Zieldefinition. So lässt sich nachweisen, ob der B2B-Shop tatsächlich Kapazität freisetzt oder lediglich einen zusätzlichen Kanal erzeugt, den der Vertrieb parallel betreuen muss. ## Die B2B-Shop-Checkliste: In welcher Reihenfolge beginnen? Die folgende Reihenfolge hat sich bewährt, weil sie zuerst Ziele und Geschäftsprozesse klärt (Schritte 1–4: Geschäftsziel, Kundenbeobachtung, Systemlandschaft, Daten-Sample), dann eine technische Lernumgebung schafft (Schritte 5–9: frühe Shopware-Plattform, Kundenorganisation, Preislogik, MVP, Integrationen) und erst anschließend Funktionsumfang und Rollout ausbaut (Schritte 10–12: UX, Sicherheit und Betrieb, Pilotkunden). ## 1. Geschäftsziel und Verantwortung festlegen „Wir brauchen einen B2B-Shop“ ist noch kein messbares Ziel. Definiert werden sollte, welches Problem zuerst gelöst werden soll. Mögliche Ziele sind: - Standardbestellungen vom Innendienst in den Self-Service verlagern, - Fehler aus E-Mail-, Telefon- oder Excel-Bestellungen reduzieren, - Bestandskunden rund um die Uhr bestellfähig machen, - neue Märkte oder Händler digital anbinden, - Angebotsprozesse beschleunigen, - den Vertrieb mit einem digitalen Verkaufskanal unterstützen, - Daten zu Nachfrage und Wiederbestellungen gewinnen. Zu jedem Ziel gehören Ausgangswert, Zielwert und Termin. Beispiele sind der Anteil digitaler Bestellungen, Bearbeitungszeit je Auftrag, Fehlerquote, Wiederbestellrate oder aktive Geschäftskunden. Außerdem braucht das Projekt eine Person mit echter Entscheidungsbefugnis. Ohne Product Owner werden Konflikte zwischen Vertrieb, IT und Operations nur vertagt. ## 2. Kunden und Kernprozesse beobachten Die besten Anforderungen entstehen nicht allein in internen Meetings. Sprecht mit fünf bis zehn repräsentativen Kunden und beobachtet, wie heute tatsächlich bestellt wird. Zu klären ist unter anderem: - Wer sucht Produkte und wer löst die Bestellung aus? - Wer muss sie freigeben? - Werden Artikelnummern, Namen oder technische Merkmale verwendet? - Welche Informationen fehlen regelmäßig? - Welche Aufträge wiederholen sich? - Wann wird ein Angebot statt eines direkten Kaufs benötigt? - Welche Belege und Statusinformationen werden nach der Bestellung gesucht? - Warum greifen Kunden heute zu Telefon oder E-Mail? Nicht jeder Sonderfall wird Bestandteil des ersten Releases. Die Interviews zeigen aber, welche zwei oder drei Abläufe den größten Nutzen erzeugen. ## 3. Systeme und Datenhoheit dokumentieren Vor der Schnittstellenplanung muss klar sein, welches System welche Information führt. Eine einfache Matrix verhindert spätere Mehrdeutigkeiten.
Information Typische Quelle Klärungsfrage
Kunden und Debitoren ERP oder CRM Wer darf Stammdaten ändern?
Produkte und Varianten ERP oder PIM Wo entstehen verkaufsfähige Texte und Medien?
Preise und Konditionen ERP oder Pricing Engine Echtzeitabfrage oder Synchronisation?
Bestände und Lieferzeiten ERP, WMS oder OMS Wie aktuell muss die Anzeige sein?
Bestellungen Shopware und ERP Ab welchem Status ist das ERP führend?
Rechnungen und Belege ERP oder DMS Werden Dateien kopiert oder nur bereitgestellt?
Benutzer und Rollen Shopware, CRM oder IAM Wer verwaltet Ein- und Austritte?
Für jedes Feld braucht es eine fachliche Quelle, eine technische Quelle und eine Regel für Fehlerfälle. „Das kommt aus dem ERP“ ist ohne zuständigen Prozess und konkrete Schnittstelle noch keine Lösung. ## 4. Ein realistisches Daten-Sample aufbauen Der erste Projektshop sollte nicht nur drei besonders einfache Demoartikel enthalten. Besser ist eine kleine, aber repräsentative Auswahl: - einfache Produkte und Varianten, - kleine und sehr große Sortimente, - unterschiedliche Einheiten und Verpackungsgrößen, - Staffelpreise und kundenspezifische Konditionen, - Artikel mit Dokumenten oder erklärungsbedürftigen Merkmalen, - Ersatzteile, Zubehör oder Alternativprodukte, - ein aktiver und ein gesperrter Kunde, - Unternehmen mit einem sowie mit mehreren Einkäufern. Dieses Sample wird zum gemeinsamen Testsatz für Datenmodell, Suche, Preise, Rechte und Schnittstellen. ## 5. Shopware früh als Projektplattform einrichten Jetzt sollte ein dauerhaft verfügbarer Entwicklungs- oder Integrationsshop entstehen – mit Versionsverwaltung, Deployment-Prozess, getrennten Umgebungen, Zugriffsschutz und nachvollziehbarer Konfiguration. Die erste Ausbaustufe benötigt noch kein finales Design. Sie sollte aber: - das repräsentative Daten-Sample enthalten, - mindestens zwei unterschiedliche Geschäftskunden abbilden, - einen vollständigen Bestellprozess ermöglichen, - erste Daten mit einem führenden System austauschen, - von Key Usern regelmäßig getestet werden können, - Änderungen reproduzierbar zwischen Umgebungen transportieren. So wird Shopware früh zum Integrations- und Lernpunkt des Projekts. Ein lokal installierter Entwickler-Demo-Shop ohne reale Daten, automatisierte Deployments und Fachbereichszugang erfüllt diesen Zweck nicht. ## 6. Kundenorganisation, Rollen und Freigaben modellieren B2B-Kunde ist nicht gleich Benutzerkonto. Ein Unternehmen kann mehrere Einkäufer, Kostenstellen, Niederlassungen und Freigabestufen besitzen. Für das Zielmodell sollten folgende Fragen beantwortet werden: - Was repräsentiert das Unternehmen und was eine Organisationseinheit? - Welche Benutzer dürfen Mitarbeiter einladen oder Rollen vergeben? - Wer sieht welche Preise, Sortimente und Bestellungen? - Ab welchem Betrag ist eine Freigabe notwendig? - Gelten Budgets für Personen, Rollen, Abteilungen oder Zeiträume? - Welche Lieferadressen und Zahlungsarten sind erlaubt? - Wie werden ausgeschiedene Mitarbeiter zuverlässig deaktiviert? Die [Shopware B2B Components](https://docs.shopware.com/de/shopware-6-de/commercial-features/b2b-components) bieten unter anderem Mitarbeiterverwaltung, Rollen, Freigabeprozesse, Organisationseinheiten und Budgets. Sie sind laut Shopware ab dem Evolve-Plan verfügbar. Wer einen neuen Shop plant, sollte diese Komponenten gegen Eigenentwicklung und Store-Erweiterungen vergleichen. Für neue Projekte ist außerdem wichtig: Shopware kündigt [in der Dokumentation](https://docs.shopware.com/de/shopware-6-de/erweiterungen/b2b-suite-administration) an, die ältere B2B Suite ab Shopware 6.8 nicht mehr zu unterstützen. Ein neuer 2026er Shop sollte daher nicht auf einer auslaufenden B2B-Architektur beginnen. ## 7. Preis- und Sortimentslogik entwirren Preise sind häufig der komplexeste Teil eines B2B-Projekts. Die Frage lautet nicht nur, welcher Preis angezeigt wird, sondern wann, für wen und aus welcher Quelle. Zu dokumentieren sind: - Basis-, Kunden-, Gruppen- und Aktionspreise, - Mengenstaffeln und Verpackungseinheiten, - Rabatthierarchien und Prioritäten, - Vertragslaufzeiten und Währungen, - Nettodarstellung und steuerliche Regeln, - Preisberechnung für Angebote und Wiederbestellungen, - Verhalten bei nicht verfügbarem ERP, - erlaubte und gesperrte Sortimente je Kunde. Eine Live-Abfrage aus dem ERP klingt einfach, kann aber Suche, Produktlisten und Performance belasten. Eine Synchronisation ist schneller, benötigt dafür klare Aktualisierungs- und Fehlerregeln. Diese Entscheidung sollte anhand eines Prototyps mit realen Konditionen getroffen werden. ## 8. Das MVP als vollständigen Nutzenpfad definieren Ein MVP ist nicht die Sammlung aller halb fertigen Funktionen. Es ist der kleinste **vollständige** Ablauf, der einer klaren Kundengruppe einen messbaren Nutzen bietet. Ein sinnvolles erstes B2B-MVP könnte umfassen: 1. Pilotkunde meldet sich an. 2. Er sieht sein freigegebenes Sortiment und seine Preise. 3. Er findet Artikel über Suche, Artikelnummer oder Schnellbestellung. 4. Er bestellt mit bekannten Liefer- und Zahlungsbedingungen. 5. Der Auftrag wird zuverlässig an das ERP übertragen. 6. Status und Bestellhistorie sind im Kundenkonto sichtbar. 7. Innendienst und Support können den Vorgang nachvollziehen. Ein komplexer Konfigurator, internationale Mandanten, Marketing Automation und alle denkbaren Freigaberegeln können wertvoll sein. Sie gehören aber nicht zwingend in den ersten Nutzenpfad. ## 9. Integrationen nach Geschäftsrisiko priorisieren Schnittstellen sollten nicht nur nach technischer Bequemlichkeit sortiert werden. Entscheidend ist, welcher Fehler den Betrieb am stärksten beeinträchtigt. Meist haben folgende Flüsse hohe Priorität: 1. Kunde und Berechtigung, 2. Produkt und Verkaufseinheit, 3. Preis und Verfügbarkeit, 4. Auftrag zum ERP, 5. Rückmeldung von Status und Belegen. Für jede Integration gehören Monitoring, Wiederholung, Fehlerablage und manueller Ersatzprozess zur Definition of Done. Eine erfolgreiche API-Antwort im Entwickler-Test ist noch kein belastbarer Betriebsprozess. Shopware ist API-first aufgebaut und kann ERP-, CRM-, PIM- und weitere Systeme integrieren. Die technische Offenheit ersetzt aber nicht die Entscheidung über Datenhoheit, Synchronisationsrichtung und Ausfallverhalten. ## 10. UX für Wiederholung und Effizienz entwickeln B2B-Einkäufer wollen häufig nicht inspiriert, sondern schnell fertig werden. Die Oberfläche sollte deshalb typische Arbeitsweisen unterstützen: - Suche nach Artikelnummer und technischen Merkmalen, - Schnellbestellung und CSV-Upload, - Einkaufs- und Favoritenlisten, - Wiederbestellung aus der Historie, - verständliche Verfügbarkeiten und Liefertermine, - gespeicherte Adressen und Bestellreferenzen, - klare Anzeige von Freigabe- und Angebotsstatus, - mobil nutzbare Freigaben für Entscheider. Das schließt gute Inhalte und Markenführung nicht aus. Im B2B-Shop muss Design jedoch zuerst Orientierung, Sicherheit und Geschwindigkeit erzeugen. ## 11. Sicherheit, Recht und Betrieb früh einplanen Vor dem Pilotbetrieb müssen Verantwortlichkeiten für Datenschutz, Steuern, Verträge, Barrierefreiheit, Informationssicherheit und Betrieb geklärt sein. Besondere Aufmerksamkeit verdienen: - Registrierung und Prüfung neuer Geschäftskunden, - Rollen- und Rechteänderungen, - Schutz kundenspezifischer Preise und Dokumente, - Protokollierung kritischer Aktionen, - Testdaten und personenbezogene Daten in Nicht-Produktivsystemen, - Backups, Wiederherstellung und Update-Prozess, - Monitoring von Shop, Queue, Suche und Schnittstellen, - Support- und Eskalationswege außerhalb der Geschäftszeiten. Diese Themen erst kurz vor dem Go-live zu prüfen, gefährdet Termin und Architektur gleichermaßen. ## 12. Mit Pilotkunden starten und kontrolliert skalieren Der erste Rollout sollte mit wenigen, bewusst ausgewählten Kunden erfolgen. Geeignet sind Partner, die regelmäßig bestellen, repräsentative Anforderungen haben und konstruktives Feedback geben. Für den Pilot braucht es: - einen klaren Zeitraum und Ansprechpartner, - persönliche Einführung statt nur einer Rundmail, - definierte Feedbackkanäle, - Messung von Nutzung, Abbrüchen und Supportanfragen, - täglichen Blick auf Schnittstellen und Aufträge, - einen sicheren Rückfallprozess für kritische Bestellungen. Erst wenn der vollständige Prozess stabil ist, werden weitere Kundengruppen, Länder oder Funktionen aktiviert. ## 30/60/90-Tage-Roadmap für den Projektstart Die ersten 90 Tage gliedern sich in drei Phasen: Tage 1 bis 30 verstehen und fokussieren, Tage 31 bis 60 Plattform und Vertical Slice aufbauen, Tage 61 bis 90 das MVP absichern. Nach 90 Tagen muss nicht der vollständige Shop live sein — aber ein realer Geschäftsprozess sollte auf der Zielplattform funktionieren und belastbar bewertet werden können. ### Tage 1 bis 30: Verstehen und fokussieren - Zielbild, Product Owner und Kennzahlen festlegen - Kundeninterviews und Prozessbeobachtung durchführen - Systeme, Datenquellen und Verantwortliche erfassen - repräsentative Kunden und Artikel auswählen - Plattform-, Plan- und Betriebsentscheidung vorbereiten - priorisierten End-to-End-Prozess beschreiben ### Tage 31 bis 60: Plattform und Vertical Slice - Shopware-Projekt mit Entwicklungs- und Testumgebung einrichten - Deployment, Zugriffe und Grundkonfiguration etablieren - Daten-Sample importieren - ersten Kunden mit Preis- und Sortimentslogik abbilden - Kernprozess bis zum ERP durchgängig integrieren - Fachbereiche regelmäßig am funktionierenden Stand testen lassen ### Tage 61 bis 90: MVP absichern - Rollen, Fehlerfälle und Betriebsprozesse ergänzen - Suche, Schnellbestellung und Kundenkonto optimieren - Datenqualität und Schnittstellen überwachen - Sicherheit, Datenschutz und rechtliche Anforderungen prüfen - Key User schulen und Support vorbereiten - Pilotkunden onboarden und Rolloutkriterien messen Die konkrete Dauer hängt von Systemlandschaft und Komplexität ab — entscheidend ist die Reihenfolge, nicht der Kalender. ## Welche Shopware-Ausbaustufe passt zum neuen B2B-Shop? Shopware Community Edition und Rise können für einfachere geschlossene Händlerbereiche oder individuell entwickelte B2B-Prozesse eingesetzt werden. Die von Shopware bereitgestellten B2B Components sind laut [aktueller Dokumentation](https://docs.shopware.com/de/shopware-6-de/commercial-features/b2b-components) jedoch Bestandteil von Evolve und Beyond. Die Entscheidung sollte nicht allein am Lizenzpreis hängen. Verglichen werden müssen: - benötigte Standardfunktionen, - Kosten von Plugins und Eigenentwicklung, - Hersteller- und Agentur-Support, - Anforderungen an Verfügbarkeit und Reaktionszeiten, - erwarteter GMV, - langfristiger Update- und Wartungsaufwand. Unser Vergleich der [Shopware-6-Lizenzen und Kosten](/insights/shopware-6-lizenzen-kosten-2026) ordnet Community Edition, Rise, Evolve und Beyond ausführlich ein. ## Typische Fehler, die die Checkliste verhindert Fünf Fehler kehren in B2B-Projekten immer wieder: der nur digital nachgebaute Offline-Prozess, alle Sonderfälle in Release eins, ein ERP, das die gesamte Customer Experience diktiert, eine zu spät eingerichtete Plattform und ein Go-live, das mit Projekterfolg verwechselt wird. Die Checkliste adressiert jeden davon. ### Der bestehende Offline-Prozess wird nur digital nachgebaut Ein schlechter E-Mail- oder Excel-Prozess wird durch eine Weboberfläche nicht automatisch gut. Prüft bei jedem Schritt, ob er notwendig ist oder nur aus historischen Gründen existiert. ### Alle Sonderfälle kommen in Release eins Seltene Ausnahmen erhöhen Komplexität und verzögern das Lernen. Sie brauchen einen dokumentierten Ersatzprozess, aber nicht immer sofort eine Automation. ### Das ERP bestimmt die gesamte Customer Experience Das ERP ist oft führend für kaufmännische Daten, aber nicht für Navigation, Suche oder verständliche Rückmeldungen. Zuständigkeiten sollten bewusst getrennt werden. ### Die Plattform wird zu spät eingerichtet Dann treffen Daten-, Prozess- und Technikrisiken gleichzeitig aufeinander. Ein früher Vertical Slice verteilt Erkenntnisse über das gesamte Projekt. ### Go-live wird mit Projekterfolg verwechselt Ein erreichbarer Shop erzeugt noch keine Nutzung. Onboarding, interne Vertriebsanreize, Datenqualität und kontinuierliche Optimierung entscheiden, ob Kunden dauerhaft digital bestellen. ## Fazit: Früh konkret werden, kontrolliert live gehen Der Start eines B2B-Shops beginnt nicht mit der Startseite. Er beginnt mit einem klaren Geschäftsziel, echten Kundenprozessen und der Frage, welche Daten und Systeme einen vollständigen Bestellablauf tragen. Shopware sollte trotzdem nicht bis zum Ende der Konzeptphase warten. Eine früh verfügbare, professionell betriebene Projektplattform macht Annahmen sichtbar, testet Daten und Schnittstellen und bringt alle Fachbereiche an einen gemeinsamen Gegenstand. Sie reduziert damit nicht die notwendige Planung, sondern verbessert deren Qualität. Der sinnvollste Weg ist ein kleiner, durchgängiger Nutzenpfad: wenige Pilotkunden, repräsentative Produkte, reale Preise, eine belastbare ERP- Integration und ein klarer Betriebsprozess. Sobald dieser Pfad funktioniert, kann der Shop schrittweise um weitere Kunden, Rollen, Länder und B2B-Funktionen wachsen. ### Offizielle Quellen - [Shopware B2B Components – Produktübersicht](https://www.shopware.com/de/produkte/b2b-components/) - [Shopware Dokumentation zu den B2B Components](https://docs.shopware.com/de/shopware-6-de/commercial-features/b2b-components) - [Shopware B2B-Lösungen und Systemintegration](https://www.shopware.com/de/loesungen/b2b/) - [Hinweis zum Supportende der bisherigen B2B Suite](https://docs.shopware.com/de/shopware-6-de/erweiterungen/b2b-suite-administration)