Das Frontend ist sichtbar, die Komplexität liegt dahinter
Ein Commerce-Projekt wird häufig über Startseite, Navigation, Produktdetailseite und Checkout wahrgenommen. Diese Bereiche sind wichtig für Nutzererlebnis und Conversion. Sie sind aber nur die sichtbare Schicht.
Im Hintergrund müssen viele Systeme eine konsistente Realität erzeugen:
- Welche Produkte sind verfügbar?
- Welche Daten und Medien gehören dazu?
- Welcher Kunde sieht welchen Preis?
- Welche Bestände sind tatsächlich lieferbar?
- Welche Freigaben gelten im B2B-Prozess?
- Wohin wird die Bestellung übertragen?
- Wie werden Zahlung, Rechnung und Versand verarbeitet?
- Was passiert bei Storno, Retoure oder Teillieferung?
- Welche Informationen fließen zurück an den Kunden?
Ein Shop kann gestalterisch hervorragend und technisch erreichbar sein – und operativ trotzdem scheitern.
Produktdaten bestimmen die Verkaufsfähigkeit
Commerce benötigt mehr als eine Artikelnummer und einen Titel. Je nach Sortiment werden unter anderem benötigt:
- Kategorien
- Varianten
- technische Attribute
- Beschreibungen
- Bilder und Dokumente
- Zubehörbeziehungen
- Verfügbarkeiten
- Gültigkeiten
- länderspezifische Informationen
- rechtlich erforderliche Angaben
- Übersetzungen
Liegen diese Informationen in mehreren PIM-Systemen, Herstellerkatalogen oder Dateien, wird Product Data zu einem eigenen Integrationsprojekt.
Der Shop sollte nicht selbst versuchen, sämtliche Quellprobleme zu lösen. Eine vorgelagerte Product-Data-Schicht kann Daten normalisieren, validieren und passend für Commerce bereitstellen.
Preise sind häufig ein Prozess, kein Feld
Im einfachen B2C-Modell besitzt ein Produkt einen Preis. In realen B2B- und hybriden Modellen können Preise von vielen Faktoren abhängen:
Die Preislogik kann im ERP, in einem Pricing-System, im CRM oder in individueller Fachlogik liegen. Der Shop benötigt eine verlässliche Antwort und muss gleichzeitig mit Latenz, Verfügbarkeit und Änderungen umgehen können.
Bestände sind nicht immer eindeutig
Ein Bestand von zehn Stück sagt wenig, wenn nicht klar ist:
- an welchem Standort,
- für welchen Markt,
- zu welchem Zeitpunkt,
- unter Berücksichtigung welcher Reservierungen,
- mit welcher Lieferzeit,
- und ob das Produkt überhaupt online verkauft werden darf.
Commerce benötigt deshalb häufig eine eigene Sicht auf Verfügbarkeit, die operative Daten in eine für den Kunden verständliche Aussage übersetzt.
Kundenlogik wird im B2B schnell komplex
Ein B2B-Konto ist selten nur ein Login. Unternehmen können mehrere Nutzer, Rollen, Lieferadressen, Kostenstellen und Freigabeprozesse besitzen.
Mögliche Anforderungen:
- Einkäufer und Genehmiger
- individuelle Sortimente
- kundenspezifische Preise
- Budgets und Limits
- Bestellvorlagen
- wiederkehrende Bestellungen
- interne Freigaben
- Rechnungs- und Lieferadressen
- unterschiedliche Zahlungsbedingungen
- zentrale und dezentrale Organisationen
Diese Logik muss zwischen Shop, CRM, ERP und Identitätsmanagement konsistent bleiben.
Bestellung ist nicht gleich Auftrag
Nach dem Checkout beginnt der operative Teil:
- Bestellung prüfen
- Zahlung autorisieren oder einziehen
- Auftrag im ERP erzeugen
- Verfügbarkeit bestätigen
- Versand oder Leistungserbringung starten
- Rechnung erzeugen
- Statusänderungen zurückmelden
- Storno und Retoure verarbeiten
- Kundensupport mit Informationen versorgen
Jeder Übergang ist eine Systemgrenze. Fehler müssen erkannt, wiederholbar verarbeitet und für Mitarbeiter nachvollziehbar sein.
Eine sinnvolle Commerce-Architektur
Eine belastbare Architektur trennt Verantwortlichkeiten:
Shopware oder eine andere Commerce-Plattform übernimmt viele wichtige Standardfunktionen. Individuelle Fachlogik und Integrationen sollten jedoch dort liegen, wo sie langfristig kontrollierbar und wiederverwendbar bleiben.
Mit einer Commerce-Version 0 beginnen
Ein neuer Vertriebskanal muss nicht sofort jedes Sortiment, jedes Land und jede Kundengruppe abbilden. Ein sinnvoller erster Durchstich kann bewusst kleiner sein:
- ausgewählte Produktgruppe
- ein Markt
- klar definierter Kundentyp
- echte Produktdaten
- reale Bestellung
- vollständige Übergabe an die nachgelagerten Systeme
Damit wird der kritische Ende-zu-Ende-Prozess früh bewiesen. Weitere Sortimente, Märkte und Sonderfälle können anschließend schrittweise ergänzt werden.
Der laufende Betrieb entscheidet
Commerce-Systeme verändern sich kontinuierlich: neue Produkte und Attribute, veränderte Schnittstellen, neue Zahlungsarten, Sicherheitsupdates, Kampagnen, neue Märkte, geänderte Preislogik und organisatorische Prozesse.
Deshalb benötigt Commerce nicht nur ein Projektteam bis zum Launch, sondern ein Betriebs- und Weiterentwicklungsmodell.
Übertragbare Learnings
- 01Das Frontend ist wichtig, aber selten die einzige kritische Schicht.
- 02Produktdaten benötigen häufig eine eigene kontrollierte Architektur.
- 03Preise und Verfügbarkeiten sind Prozesse, nicht nur Felder.
- 04B2B-Kundenlogik muss über mehrere Systeme konsistent bleiben.
- 05Bestellung, Auftrag, Zahlung und Fulfillment sind unterschiedliche Zustände.
- 06Ein kleiner vollständiger Commerce-Prozess ist ein guter Startpunkt.
- 07Betrieb und Weiterentwicklung gehören zum Produkt.
Abschluss
Ein Commerce-System ist dann belastbar, wenn nicht nur der Checkout funktioniert, sondern Daten, Kundenlogik und nachgelagerte Prozesse gemeinsam eine zuverlässige operative Kette bilden.