Sieben Systeme, ein Shop: warum Schnittstellen über Ihr Projekt entscheiden

Wenn ein Shop-Projekt aus dem Ruder läuft, liegt es fast nie am Shop. Es liegt an dem, was an ihm hängt: ERP, Lager, CMS, Benutzerkonten, CRM, Newsletter, Service-Tools. Die Plattform ist in den Angeboten die große Zahl; die Schnittstellen sind die Zahl, die am Ende stimmt. Bei BWT haben wir das Endkundengeschäft eines Konzerns mit über 5.000 Mitarbeitenden auf Shopware 6 neu aufgesetzt: sieben Backend-Systeme, elf Monate, über 1 Mio. € Projektvolumen. Dieser Text ist das, was wir aus diesem Projekt über Systemlandschaften wissen, geschrieben für die Person, die das nächste Budget dafür freigeben muss.

Was war bei BWT passiert, bevor wir übernommen haben?

Ein Lehrstück darüber, wie ein Shop an seinen Schnittstellen scheitert, obwohl jede einzelne davon technisch funktionierte. Bevor wir das Endkundengeschäft übernehmen durften, lief es auf Sitecore Commerce. Sitecore besteht aus einem CMS und einem Commerce-Teil, und für die beiden Hälften waren zwei verschiedene Agenturen beauftragt. Zwei Agenturen, ein Produkt, geteilte Hoheit. Wer schon einmal zwei Köche an einem Topf gesehen hat, weiß, wie das ausgeht.

Die Schnittstelle zum Konzern-ERP, Microsoft Dynamics, ist die eigentliche Pointe. Das Endkundengeschäft war Neuland, und irgendjemand hatte die verständliche Sorge, dass Zehntausende Privatkunden das ERP zumüllen. Die Lösung: Alle Shop-Kunden wurden im ERP auf ein einziges, generisches Shop-Kundenkonto gemappt. Ein Kunde, alle Bestellungen. Sauber, übersichtlich, und aus Sicht des ERP völlig in Ordnung. Nur sollten Stornos und Gutschriften aus dem ERP heraus erfolgen. Sie können sich ausmalen, wie das aussieht, wenn eine Gutschrift für Frau Müller an das Konto gehen soll, auf dem außer Frau Müller noch alle anderen Kunden des Landes buchen.

Das Endergebnis nach einem Budget, das den späteren Neuaufbau überstieg: ein Shop, dessen Frontend man nicht gern zeigte, und in dem der Endkunde eine Fünfzig-Prozent-Chance hatte. Nicht darauf, dass die Zahlung funktioniert; die funktionierte immer. Sondern darauf, dass seine Ware jemals das Lager verlässt. Der Bezahlvorgang war die eine Schnittstelle, die ihre Aufgabe zuverlässig erfüllte. Die Auftragsübergabe an Lager und ERP war die andere.

An dieser Stelle war das Projekt schachmatt, und wir durften übernehmen. Alles, was in diesem Text folgt, ist die Antwort auf die Frage, wie man dieselben sieben Systeme so anbindet, dass die Ware das Lager verlässt.

Warum bestimmen die Schnittstellen das Projekt und nicht die Shop-Software?

Weil die Shop-Software austauschbar ist und Ihre Systemlandschaft nicht. Ein Storefront-Template lässt sich in Wochen bauen; die Frage, welches System der führende Datenhalter für Preise, Bestände, Kunden und Aufträge ist, entscheidet über Monate. Das generische Kundenkonto oben ist genau so eine Entscheidung: Sie wurde als Entlastung des ERP getroffen und war in Wahrheit eine Entscheidung darüber, dass es für Endkunden kein führendes System gibt.

Sitecore Commerce trug für Sortiment, Länder-Rollout und Integrationsfähigkeit nicht mehr: begrenzte Anbindungsmöglichkeiten an Drittsysteme, fehlende Funktionen im Standard, ein Preis-Leistungs-Verhältnis, das intern nicht mehr überzeugte. Die Entscheidung für Shopware 6 fiel deshalb nicht wegen des Frontends, sondern wegen des API-First-Ansatzes: Sitecore-CMS, ein zentraler Identity Server und die Backend-Systeme sprechen über definierte Schnittstellen mit dem Shop, statt dass der Shop versucht, alles selbst zu sein.

Für Ihr Gremium heißt das: Die Plattformfrage ist nachrangig gegenüber der Integrationsfrage. Wer zuerst die Shop-Software wählt und dann schaut, wie sie an ERP und CMS kommt, hat die Reihenfolge umgedreht. Wer zuerst die Systemlandschaft aufnimmt, kann die Plattform an ihr messen. Welche Fragen das Gremium dabei sonst noch stellt, steht in unserem Artikel darüber, wie Sie Shopware 6 vor dem Vorstand vertreten.

Wie viele Systeme hängen wirklich an Ihrem Shop?

Mehr, als im ersten Meeting genannt werden, und die fehlenden sind die teuren. In der Regel nennt die Fachabteilung das ERP und vielleicht das Lager. Was fehlt, sind die Systeme, die niemand als Shop-System betrachtet, die aber jede Bestellung berühren.

Bei BWT waren es am Ende sieben Backend-Systeme: das Sitecore-CMS aller Ländergesellschaften, ein zentraler Identity Server für das gemeinsame BWT-Benutzerkonto über Shop, Partner-Portal und Apps, CRM, Newsletter-System, Customer-Service-Tools, die Lagerverwaltung mit Pickware und die bestehende Warenwirtschaft aus ERP und PIM, die bewusst nicht angetastet wurde. Nichts davon war exotisch. Alles davon war eine eigene Schnittstelle mit eigenem Datenmodell, eigenem Ansprechpartner und eigener Frage, wer im Konflikt recht hat.

Machen Sie vor dem ersten Angebot eine Inventur mit vier Spalten: Welches System, welche Daten fließen in welche Richtung, wie aktuell müssen sie sein (Echtzeit, stündlich, nächtlich), und wer auf Ihrer Seite kann Fragen dazu innerhalb eines Tages beantworten. Die vierte Spalte ist die wichtigste. Eine Schnittstelle, deren Gegenstück von einem externen Dienstleister betreut wird, der zwei Wochen Antwortzeit hat, dauert doppelt so lange wie eine, deren Ansprechpartner im Projektteam sitzt. Das hat nichts mit Technik zu tun, und es steht in keinem Angebot.

Was kostet eine Schnittstelle, und wie lange dauert sie?

Es gibt keinen Preis pro Schnittstelle, und jeder Anbieter, der einen nennt, hat Ihre Systemlandschaft nicht gesehen. Was es gibt, sind vier Treiber, die Sie vor dem Angebot selbst einschätzen können.

Datenhoheit. Für jedes Datum (Preis, Bestand, Kundenadresse, Auftragsstatus) muss ein System führend sein. Wo das ungeklärt ist, wird die Schnittstelle zum Schlichter, und Schlichtung ist teuer. Bei BWT war die Entscheidung klar: Pickware übernimmt Kommissionierung und Versand und macht bewusst keine Konkurrenz zu ERP und PIM. Diese Grenze war eine Architekturentscheidung, keine technische Notwendigkeit, und sie hat Monate gespart.

Aktualität. Echtzeit ist teurer als nächtlich, und meistens nicht nötig. Bestände im Shop müssen aktuell sein, Newsletter-Anmeldungen nicht. Wer für alles Echtzeit fordert, bezahlt für alles Echtzeit.

Qualität der Gegenseite. Ein System mit dokumentierter API und Testumgebung kostet einen Bruchteil eines Systems, das nur CSV-Export per FTP kann oder dessen Schnittstelle der Hersteller erst freischalten muss. Fragen Sie vor dem Projekt bei jedem System nach: Gibt es eine API, gibt es eine Doku, gibt es eine Testinstanz. Drei Nein sind ein Budgetposten.

Sonderfälle. Die Schnittstelle für den Normalfall ist schnell gebaut. Die Zeit geht in Retouren, Teillieferungen, Storno nach Versand, Preisänderung nach Bestellung, Kunde mit zwei Konten. Bei BWT gab es vier Bausteine, die weder Shopware noch Pickware im Standard hatten, und wir haben sie gebaut: eine Auftragsannahme, die das Lager per Buzzer über neue Bestellungen informiert, eine Scan-und-Pack-Erweiterung für den Packtisch, ein Modul für Ein- und Umlagerung über alle vier Lagerstellen und ein Performance-Dashboard. Nichts davon stand in der ursprünglichen Anforderungsliste. Alles davon wurde im Betrieb täglich gebraucht.

Zur Dauer: Bei BWT lagen zwischen Entscheidung und Go-Live elf Monate, und der größere Teil davon war Integrationsarbeit, nicht Shop-Aufbau. Bei thyssenkrupp materials4me, einer Shopware-5-Ablöse mit weniger Umsystemen, waren es sechs Monate. Die Differenz ist nicht die Shop-Software. Die Differenz ist die Zahl der Systeme und die Zahl der Menschen, die für sie zuständig sind. Was davon in einem Angebot typischerweise fehlt, haben wir gesondert aufgeschrieben: Was eine Shopware-Migration wirklich kostet.

Anbinden, ersetzen oder selbst bauen?

Jedes System, das an den Shop soll, hat drei mögliche Antworten, und die billigste ist selten die, die zuerst genannt wird.

Anbinden, wenn das System seinen Job gut macht und ein anderes Team davon abhängt. ERP und PIM bei BWT: bleiben, werden angebunden, werden nicht diskutiert. Ein Shop-Projekt ist kein Anlass, die Buchhaltung umzustellen.

Ersetzen, wenn das System nur noch existiert, weil es immer existiert hat. Bei BWT war das die externe Endkundenlogistik: Statt sie weiter fremd zu vergeben, holte BWT sie ins eigene Haus und baute vier Lagerstellen auf, Hauptlager, Hochregallager, Blocklager für Sperriges und ein Schnellpicklager für Schnelldreher. Das war die größte Einzelentscheidung im Projekt, und sie hatte mit Shopware nichts zu tun. Sie war möglich, weil die Plattform sie nicht verhinderte. In einem anderen Projekt, bei einem Händler mit sechsstelliger Kundenzahl, war das zu ersetzende System das ERP selbst, weil Shopware seine Aufgaben übernehmen konnte. Es gibt keine Regel, welches System geht; es gibt nur die Frage, welches Ihr Geschäft noch braucht.

Selbst bauen, wo der Standard endet und das Geschäft weitergeht. Die vier BWT-Bausteine oben sind das Beispiel. Der Fehler ist nicht, zu bauen; der Fehler ist, zu bauen, was der Standard schon kann, oder den Standard zu verbiegen, bis er beim nächsten Update bricht. Die Regel, die sich bewährt hat: Eigenentwicklung nur gegen die offiziellen APIs, nie in den Kern, und nur dort, wo ein Prozess täglich läuft.

Ein Sonderfall, den Entscheider unterschätzen: das Benutzerkonto. Wenn Shop, Partner-Portal und Apps eigene Logins haben, entstehen Konto-Wildwuchs, Support-Aufwand und Datenschutzfragen. Bei BWT teilen sich alle Services ein Benutzerkonto über einen zentralen Identity Server; Single Sign-On war Teil der Architektur, nicht eine spätere Ergänzung. Wer das nachträglich einführt, migriert seine Kunden ein zweites Mal.

Wie halten Sie den Umsatz während der Umstellung?

Indem jede Schnittstelle einzeln abgenommen wird, bevor irgendetwas umgeschaltet wird. Das größte Risiko einer Migration ist nicht das Budget, sondern der laufende Umsatz; ein Shop, der während der Umstellung Bestellungen verliert, kostet mehr als jede Überschreitung und kostet intern das Vertrauen in das Projekt.

Bei BWT ging die Migration ohne eine verlorene Bestellung über die Bühne. Das war kein Glück, sondern Reihenfolge: Für jede Schnittstelle gab es einen testbaren Satz, etwa: Eine Bestellung mit zwei Positionen aus zwei Lagerstellen erzeugt genau einen Lieferschein und eine korrekte Bestandsbuchung in beiden Lagern. Solche Sätze sind der eigentliche Vertrag. Sie machen die Frage, ob eine Schnittstelle fertig ist, zu einer Ja-Nein-Frage statt zu einer Verhandlung, und sie werden vor dem Cutover durchgespielt, mit echten Artikeln und echten Preisen, nicht mit Testdaten.

Dazu ein Cutover-Plan, der wie eine Operation geplant ist: Reihenfolge der Systeme, Verantwortliche, Prüfpunkte, und ein definierter Rückweg, falls ein Prüfpunkt scheitert. Im Regelbetrieb verlassen heute über 250 Bestellungen pro Tag die vier Lagerstellen von BWT; das Team dahinter ist auf über 25 Personen gewachsen, und der Umsatz hat sich nach der Umstellung verdoppelt. Das sind Zahlen aus dem Betrieb, nicht aus dem Projektabschluss. Und das ist der Maßstab, an dem Sie jede Migration messen dürfen: nicht, ob der Go-Live stattgefunden hat, sondern was ein Jahr danach durch die Systeme läuft.