E-Commerce-Systemarchitektur: Prozesse, Systeme und Steuerung eines Handelsgeschäfts

Die E-Commerce-Systemarchitektur beschreibt, welche Prozesse ein Handelsgeschäft im Onlinevertrieb durchlaufen muss und welche Systeme diese Prozesse tragen. Sie beginnt beim Sortiment und den Produktdaten, führt über Shop, Checkout und Payment zu Versand, Retoure und Kundenservice und endet nicht bei der Auslieferung, sondern bei der Steuerung durch Kennzahlen. Dieser Leitfaden behandelt die Kette als Ganzes: Wer eine Stufe ohne die anderen plant, baut Bruchstellen ein, die später als Retourenquote, als Supportaufkommen oder als nicht abstimmbare Buchhaltung sichtbar werden.

Begriffsklärungen bleiben hier bewusst kurz. Es geht um den operativen Aufbau: welche Datenobjekte entstehen, welches System sie führt, an welcher Stelle sie weitergereicht werden und woran man merkt, dass die Übergabe nicht funktioniert.

Die Prozesskette im Überblick

Ein Handelsgeschäft im Netz besteht aus sieben aufeinander aufbauenden Stufen. Jede Stufe erzeugt ein Datenobjekt, das die nächste Stufe braucht.

Der häufigste Architekturfehler liegt nicht in einer dieser Stufen, sondern zwischen ihnen: Zwei Systeme führen dieselbe Information, ohne dass definiert ist, welches von beiden recht hat. Der Preis steht im Shop und im Warenwirtschaftssystem, der Lagerbestand ebenso, die Kundenadresse in Shop, CRM und Versandsoftware. Legen Sie vor jeder Systemauswahl fest, welches System für welches Feld die Quelle ist und in welche Richtung synchronisiert wird.

Sortiment und Produktdaten

Das Sortiment ist eine kaufmännische Entscheidung, die Produktdatenpflege eine operative. Beide hängen zusammen, weil die Datenqualität bestimmt, ob ein Artikel überhaupt verkäuflich ist.

Ein produktionsfähiger Artikelstamm braucht mindestens: eindeutige Artikelnummer, Varianten mit eigener Nummer, Einkaufs- und Verkaufspreis, Steuersatz je Zielland, Gewicht und Maße für die Versandkalkulation, Zolltarifnummer und Ursprungsland bei grenzüberschreitendem Versand, Verfügbarkeitslogik und Lieferzeit.

Darüber liegt die Anreicherung: Titel, Beschreibung, technische Attribute, Bilder, gegebenenfalls Video und Datenblatt. Ab einer dreistelligen Artikelzahl mit mehreren Kanälen lohnt ein eigenes Product Information Management, weil sonst jede Kanalanpassung im Shop selbst passiert und beim nächsten Import überschrieben wird.

Zwei Regeln haben sich operativ bewährt. Erstens: Attribute, nach denen Kunden filtern sollen, gehören in strukturierte Felder, nicht in den Fließtext der Beschreibung. Zweitens: Jedes Pflichtfeld braucht eine Prüfung vor der Freigabe, sonst geht ein Artikel ohne Gewicht online und der Checkout kann keine Versandkosten berechnen.

Shopsystem und Katalogfrontend

Das Shopsystem ist die Verkaufsoberfläche und zugleich der Ort, an dem Bestellungen entstehen. Bei der Auswahl entscheiden weniger die Featurelisten als drei Fragen: Wie werden Produktdaten importiert, wie werden Bestellungen exportiert, und wie tief lässt sich der Checkout anpassen, ohne die Update-Fähigkeit zu verlieren.

Architektonisch stehen sich zwei Muster gegenüber. Das integrierte Shopsystem liefert Katalog, Checkout und Verwaltung aus einer Hand und ist schneller startklar. Der entkoppelte Aufbau trennt Frontend und Commerce-Backend über Schnittstellen und erlaubt eigene Oberflächen und mehrere Kanäle, verlangt dafür aber eigene Entwicklungskapazität. Für ein Handelsgeschäft ohne festes Entwicklerteam ist das integrierte Muster in der Regel die belastbarere Wahl, weil jeder Schnittstellenbruch sonst zum Betriebsrisiko wird.

Funktional zählen im Katalog vor allem die Suche mit Synonymen und Tippfehlertoleranz, belastbare Filter aus den strukturierten Attributen, sichtbare Verfügbarkeit und Lieferzeit sowie eine Produktdetailseite, die Versandkosten, Rückgabebedingungen und Zahlungsarten bereits vor dem Warenkorb zeigt. Was dort fehlt, taucht später als Abbruch im Checkout oder als Serviceanfrage wieder auf.

Checkout: die rechtlich und operativ heikelste Stufe

Der Checkout ist der Punkt, an dem aus einem Besuch ein Vertrag wird. Er ist deshalb gleichzeitig ein Konversions- und ein Rechtsthema.

Operativ gilt: so wenige Pflichtangaben wie möglich, Gastbestellung anbieten, Adressprüfung und Adressvervollständigung einsetzen, Zahlungsarten erst nach der Adresse zeigen, damit Risikoregeln greifen können, und alle Kosten inklusive Versand vor dem letzten Klick ausweisen.

Rechtlich ist der Bestellabschluss in Deutschland eng geführt. Bei zahlungspflichtigen Onlinebestellungen muss die Bestellsituation nach § 312j BGB eindeutig erkennen lassen, dass die Bestellung eine Zahlungspflicht auslöst (gesetze-im-internet.de). Praktisch heißt das: eine unmissverständlich beschriftete Schaltfläche und eine unmittelbar davor stehende Zusammenfassung der wesentlichen Bestellangaben. Ein Checkout, der diese Stelle „schöner" gestalten will, ist kein Designprojekt, sondern ein Compliance-Eingriff und gehört entsprechend abgenommen.

Die Bestellung selbst ist das zentrale Datenobjekt des gesamten Systems. Sie sollte unveränderlich protokolliert werden: Was der Kunde zu welchem Preis unter welchen Bedingungen bestellt hat, muss auch nach einer späteren Preisänderung im Katalog rekonstruierbar bleiben. Systeme, die den Bestellpositionen nur eine Referenz auf den Artikel mitgeben und den Preis live nachschlagen, produzieren im Streitfall keine belastbare Auskunft.

Payment: Autorisierung, Einzug und Abgleich

Zahlungsabwicklung besteht aus drei Vorgängen, die häufig verwechselt werden: die Autorisierung im Checkout, der tatsächliche Einzug bei Versand und der Abgleich der Zahlungseingänge mit den Bestellungen.

Der europäische Rechtsrahmen dafür ist die Zweite Zahlungsdiensterichtlinie PSD2, die unter anderem Vorgaben zur starken Kundenauthentifizierung bei elektronischen Zahlungen eingeführt hat (Europäische Kommission). Für den Betrieb bedeutet das: Ein zusätzlicher Authentifizierungsschritt ist im Kartenzahlungsprozess der Normalfall, und der Checkout muss mit dessen Abbruch umgehen können, ohne die Bestellung zu verlieren oder doppelt anzulegen.

Bei der Auswahl des Zahlartenmixes entscheidet weniger die Anzahl als die Passung zum Sortiment und zur Zielgruppe. Rechnungskauf senkt Kaufabbrüche, verschiebt aber das Ausfallrisiko und erzeugt einen Mahnprozess, den jemand betreiben muss. Vorkasse ist risikoarm und verzögert die Auslieferung. Wallets und Kartenzahlung sind schnell, kosten Gebühren pro Transaktion. Jede zusätzliche Zahlart erhöht außerdem den Abgleichaufwand, weil sie ein eigenes Auszahlungsschema und eigene Gebührenpositionen mitbringt.

Der Abgleich ist der Teil, den Projekte regelmäßig unterschätzen. Planen Sie von Anfang ein, dass Zahlungsvorgänge mit einer eindeutigen Referenz zur Bestellung in die Buchhaltung fließen und Teilzahlungen, Teilstornos, Rückerstattungen und Gebühren dort abbildbar sind. Wird das nachträglich gebaut, ist der Monatsabschluss Handarbeit.

Versand und Fulfillment im Systemzusammenhang

Fulfillment im Detail, also Lagerwahl, Kommissioniermethoden und Dienstleistervergleich, ist ein eigenes Thema. Für die Systemarchitektur zählt, welche Objekte entstehen und wer sie führt.

Aus der Bestellung wird ein Lieferauftrag. Er braucht eine Bestandsreservierung, damit derselbe Artikel nicht zweimal verkauft wird, eine Packvorgabe bei mehreren Positionen oder Lagerorten, ein Versandlabel und eine Sendungsverfolgungsnummer, die zurück in Shop und Kundenkommunikation fließt. Ab mehreren Lagerorten oder Kanälen übernimmt ein Order Management System die Entscheidung, aus welchem Bestand eine Bestellung bedient wird.

Ein Compliance-Punkt gehört unmittelbar hierher: Unternehmen, die in Deutschland erstmals mit Ware befüllte, systembeteiligungspflichtige Verpackungen in Verkehr bringen, müssen sich vor dem Vertrieb im Verpackungsregister LUCID registrieren (Verpackungsregister). Das betrifft Versandkartons und Füllmaterial genauso wie die Produktverpackung und ist eine Voraussetzung des Vertriebs, kein nachgelagerter Formalakt.

Retoure und Widerruf

Die Retoure ist kein Sonderfall, sondern ein regulärer Prozesspfad, der im System denselben Rang wie der Versand haben sollte.

Rechtlicher Ausgangspunkt: Verbraucher können Fernabsatzverträge in der EU grundsätzlich innerhalb von 14 Tagen ohne Angabe von Gründen widerrufen, wobei für bestimmte Waren und Dienstleistungen Ausnahmen gelten (Your Europe). Daraus folgt operativ eine Widerrufsbelehrung, ein Muster-Widerrufsformular, eine definierte Rückerstattungsfrist und die Fähigkeit, eine Zahlung ganz oder teilweise zurückzuführen.

Der Prozess selbst gliedert sich in Anmeldung, Wareneingang, Prüfung, Entscheidung über Wiedereinlagerung oder Aussortierung und die Erstattung. Zwei Details entscheiden über den Aufwand. Erstens die Rückgabegründe: Werden sie strukturiert erfasst und dem Artikel zugeordnet, wird die Retourenquote zu einer Sortiments- und Datenqualitätsauskunft statt zu einer reinen Kostenposition. Zweitens die Kopplung an die Zahlung: Eine Erstattung, die im Zahlungssystem ausgelöst, aber in der Bestellung nicht vermerkt wird, führt zu doppelten Rückzahlungen und zu Mahnungen an Kunden, die längst zurückgeschickt haben.

Kundenservice als Teil der Kette

Der Kundenservice ist in dieser Architektur kein eigener Kanal, sondern ein Zugriff auf dieselben Daten. Entscheidend ist, dass eine Servicekraft in einer Ansicht sieht: Bestellung, Zahlungsstatus, Lieferstatus, Retourenstatus und die bisherige Kommunikation. Fehlt diese Zusammenführung, entsteht der typische Rückfrageverkehr, bei dem Kunden mehrfach dasselbe erklären.

Für die Systemplanung heißt das vor allem: Das Servicewerkzeug braucht lesenden Zugriff auf Bestellung und Lieferung sowie klar abgegrenzte Schreibrechte, etwa für Adressänderung vor Versand, Stornierung und Erstattung. Alles darüber hinaus, also Servicequalität, Erreichbarkeit und Reklamationsführung, ist ein Thema für sich.

Compliance als Querschnitt

Compliance ist keine Stufe der Kette, sondern eine Anforderung an mehrere Stufen gleichzeitig. Vier Punkte prägen die Architektur unmittelbar.

Datenschutz. Die Datenschutz-Grundverordnung gilt für die ganz oder teilweise automatisierte Verarbeitung personenbezogener Daten und prägt damit unter anderem Kundenkonten, Tracking und Bestellabwicklung (EUR-Lex). Praktisch bedeutet das: ein Verzeichnis der Verarbeitungstätigkeiten, Auftragsverarbeitungsverträge mit Shop-Hoster, Zahlungsdienstleister und Versanddienstleister, ein Löschkonzept, das mit den handels- und steuerrechtlichen Aufbewahrungspflichten vereinbar ist, sowie eine Einwilligungslogik für alles, was über den Betrieb des Shops hinausgeht.

Bestellprozess. Die Anforderung aus § 312j BGB an die Erkennbarkeit der Zahlungspflicht, siehe oben, betrifft den Checkout direkt.

Zahlungsverkehr. PSD2 und die starke Kundenauthentifizierung wirken in den Payment-Flow hinein.

Verpackung und Steuern. Neben der LUCID-Registrierung ist die Umsatzsteuer bei grenzüberschreitendem Verkauf der Punkt, der Systemanforderungen erzeugt. Der EU-One-Stop-Shop ermöglicht es Unternehmen, bestimmte grenzüberschreitende B2C-Umsätze zentral in einem Mitgliedstaat zu erklären und die darauf entfallende Umsatzsteuer abzuführen (Europäische Kommission). Damit das funktioniert, muss der Shop je Bestellung Zielland und angewandten Steuersatz sauber führen und an die Buchhaltung übergeben. Ein System, das nur einen Steuersatz pro Artikel kennt, blockiert die Auslandsexpansion.

Die Systemlandschaft und ihre Schnittstellen

Für jede Verbindung zwischen zwei Systemen sollten vier Angaben schriftlich festgehalten sein: Richtung, Auslöser, Frequenz und Verhalten im Fehlerfall. Der letzte Punkt ist der wichtigste. Was passiert, wenn der Bestellexport ins ERP scheitert? Ohne Wiederholung mit Idempotenzschlüssel entstehen entweder verlorene oder doppelte Bestellungen, und beides fällt oft erst beim Monatsabschluss auf.

Steuerung durch Kennzahlen

Ein Handelsgeschäft wird nicht über einen Umsatzwert gesteuert, sondern über die Kennzahlen der einzelnen Stufen. Sinnvoll ist eine Zuordnung entlang der Kette, damit eine Verschlechterung lokalisierbar bleibt.

Die Kontaktquote je Bestellung ist dabei die unterschätzte Größe. Sie misst nicht die Servicequalität, sondern die Qualität aller vorgelagerten Stufen: Jede Anfrage nach dem Lieferstatus zeigt eine fehlende Statusinformation, jede Rückfrage zur Passform eine Lücke in den Produktdaten.

Eine belastbare Aufbaureihenfolge

Wer die Architektur neu aufsetzt, sollte nicht alle Systeme parallel einführen. Bewährt hat sich diese Reihenfolge:

1. Artikelstamm und Datenmodell festlegen, inklusive Steuersätzen je Zielland und Versandattributen.
2. Führendes System je Datenfeld bestimmen und schriftlich fixieren.
3. Shop mit einem kleinen, vollständig gepflegten Sortiment produktiv nehmen.
4. Checkout und eine Kernzahlart rechtlich abnehmen lassen, bevor weitere Zahlarten folgen.
5. Versand- und Retourenprozess mit echten Sendungen durchspielen, nicht nur konfigurieren.
6. Buchhaltungsabgleich herstellen, solange die Bestellmengen noch klein sind.
7. Erst dann Sortiment, Kanäle und Automatisierung ausbauen.

Der Grund für diese Reihenfolge ist wirtschaftlich: Fehler im Datenmodell und in der Zahlungsabstimmung skalieren mit der Bestellmenge. Ein falsch geführtes Steuerfeld ist bei fünfzig Bestellungen eine Korrektur und bei fünfzigtausend ein Projekt.

Zusammenfassung

Ein Handelsgeschäft im Netz ist eine Kette aus Sortiment, Produktdaten, Shop, Checkout, Payment, Fulfillment, Retoure und Service, überspannt von Compliance-Anforderungen und gesteuert über stufenbezogene Kennzahlen. Die Systemauswahl entscheidet weniger über den Erfolg als die Frage, welches System welches Datenfeld führt und wie sich die Übergaben im Fehlerfall verhalten. Wer diese Festlegungen vor dem ersten Import trifft, den Checkout und die Zahlungsabstimmung früh rechtlich und buchhalterisch absichert und die Retoure als gleichwertigen Prozesspfad plant, hat die Architektur, auf der Wachstum überhaupt erst tragfähig wird.