Prax

Wenn es kein Vorgängersystem gibt, kannst du nicht aus Bestellzahlen oder Lagerumschlag ableiten, was die Plattform leisten muss. Also leitest du die Kriterien aus den Zielen ab. Bei Prax waren das im Kern drei: Die Plattform musste schnelles Wachstum tragen, B2B und B2C parallel abbilden und sich tief in eine bestehende Systemlandschaft integrieren lassen — ERP, Preis- und Freigabelogiken, Prüfprozesse im Checkout. Zur Auswahl standen Magento, Shopify und Shopware.

Für Shopware sprach am Ende die Reife des Ökosystems im deutschen Markt: eine große Zahl vergleichbarer Shops im Produktivbetrieb, verfügbare Integrationspartner und ein Entwicklermarkt, auf den man auch in fünf Jahren noch zugreifen kann. Das ist ein härteres Kriterium, als es zunächst klingt. Du entscheidest nicht nur über Software, sondern über die Verfügbarkeit von Know-how über die gesamte Lebensdauer der Plattform.

Bei Magento war es kein Ausschluss, sondern eine Abwägung. Beide Plattformen hätten die Anforderungen abgedeckt — das war nie die Frage. Jede Plattformentscheidung ist ein Tausch: Du gewinnst an einer Stelle Flexibilität und zahlst sie an anderer mit Komplexität, Betriebsaufwand oder Abhängigkeiten. Bei Magento hätten die Kompromisse an Stellen gelegen, die für die Ziele von Prax kritisch waren, bei Shopware dort, wo sie das Vorhaben weniger eingeschränkt haben. Wir haben Magento bewusst mit ins Rennen geschickt, wir arbeiten seit vielen Jahren damit und hätten das Projekt auch dort umgesetzt. Für dieses Setup war Shopware die passendere Wahl.

Shopify hätte das Wachstum ebenfalls getragen. Ausschlaggebend waren die Anforderungen an den Bestellprozess: eine Prüfung gegen Sanktionslisten im Checkout, eine USt-IdNr.-Validierung für Geschäftskunden, unterschiedliche Freigabelogiken für B2B und B2C. Je tiefer du in den Bestellprozess eingreifen musst, desto mehr Kontrolle über den Code brauchst du. Deshalb ist die Entscheidung früh gegen ein SaaS-Modell gefallen.

Die anspruchsvollste Anbindung war die Sanktionslistenprüfung im Checkout. Prax vertreibt Werkzeuge, die je nach Verwendungszweck exportkontrollrechtlich relevant sein können. Entsprechend werden die Kundendaten bei jeder Bestellung im Hintergrund geprüft, bevor der Auftrag in den Order-Workflow geht — ein gesetztes Requirement, kein Nice-to-have, und es musste sich sauber in den Bestellprozess einfügen, ohne die Conversion zu beschädigen.

Die ERP-Anbindung lief reibungsloser, als man das bei einem Partner erwartet, mit dem man zum ersten Mal zusammenarbeitet. Der Grund war genau der Ökosystem-Effekt, der schon bei der Plattformauswahl eine Rolle gespielt hat: Der ERP-Anbieter hatte kurz zuvor ein anderes Shopware-Projekt umgesetzt und konnte bestehende Komponenten übernehmen, statt bei null anzufangen. Dazu kamen eine USt-IdNr.-Validierung für Geschäftskunden und ein Terminbuchungs-Tool, über das Kunden einen freien Slot für ein Beratungsgespräch mit einem Produktexperten wählen können.

Dass es keine bestehenden Abläufe gab, an denen man sich orientieren konnte — das ist Vorteil und Aufwand zugleich. Der Vorteil: Wir mussten keine gewachsenen Prozesse migrieren, sondern konnten den Soll-Zustand gemeinsam mit dem Fachbereich von Grund auf entwerfen. Bei einer Migration schleppst du fast immer Altlasten mit, hier nicht.

Der Aufwand lag in der Taktung. Grundsatzentscheidungen — welches System führend ist, welches nur lesend zugreift, wohin Daten fließen, wie Retouren und Reklamationen laufen — mussten parallel zur Umsetzung getroffen werden. Wir haben deshalb viel Zeit in Workshops investiert, bevor Funktionen gebaut wurden. Die eigentliche Herausforderung war keine technische, sondern die Frage, wie man viele Weichenstellungen in kurzer Zeit so trifft, dass keine davon später teuer korrigiert werden muss.

Es sind viele feine Unterschiede, an die man zuerst gar nicht denkt. Der deutlichste ist die Warenkorbgröße — bei Prax liegt sie im Geschäftskundenbereich etwa um den Faktor zehn über der von Privatkunden. Das verändert die Anforderungen an den gesamten Bestellprozess, von der Zahlungsart bis zur Freigabelogik.

Konkret wird es beim Payment. Will ein Privatkunde auf Rechnung kaufen, prüfst du Geburtsdatum und ob Liefer- und Rechnungsadresse übereinstimmen. Beim Geschäftskunden genügt in der Regel eine USt-IdNr.-Abfrage für die Freigabe. Solche Unterschiede ziehen sich durch Warenkorb, Zahlungsarten und Checkout — und sie sind der Grund, warum ein Shop, der beide Zielgruppen bedient, mehr ist als ein Shop mit zwei Preislisten.

Der erste Commit war Anfang April, der Go-live war für Anfang Oktober geplant. Live gegangen sind wir Ende Januar. Das Team war bewusst schlank aufgestellt: Projektleitung, ein Frontend-Entwickler, ein Backend-Entwickler und eine QA-Kraft.

Die Verschiebung lag nicht an der Entwicklung — zum geplanten Termin waren wir fertig. Ein Launch, bei dem Marke, Sortiment und Shop gleichzeitig entstehen, hängt aber von mehr ab als von der Software. Als sich Abhängigkeiten außerhalb des Projektteams verschoben haben, ist der Termin mitgewandert. Das ist bei einem Markenstart eher die Regel als die Ausnahme.

Die Total Cost of Ownership. Die Infrastruktur liegt im niedrigen fünfstelligen Bereich pro Jahr — bei einem Shop dieser Größenordnung ist das ein spürbarer Anteil der Gesamtkosten, und es ist der Posten, den man bei Shopware am ehesten unterschätzt.

Dazu kommen Lizenzkosten für Extensions. Gerade im B2B-Umfeld sind die guten Erweiterungen nicht billig, und mit jeder zusätzlichen Anforderung steigt der TCO weiter. Hätten wir den vollen Anforderungsumfang von Beginn an gekannt, hätten wir diesen Punkt in der Plattformentscheidung stärker gewichtet. Das heißt nicht, dass die Entscheidung falsch war. Aber wer Shopware nur über die Lizenzkosten der Plattform bewertet, rechnet zu kurz — die Betriebs- und Erweiterungskosten gehören von Anfang an in die Kalkulation.

Sie läuft im Run Mode weiter, und das war von Anfang an so angelegt. Ein Shop ist zum Go-live nicht fertig, sondern startklar. Seitdem entstehen laufend neue Anforderungen aus dem operativen Geschäft, die wir umsetzen.

Ein großer Teil der Arbeit ist dabei Beratung, und das ist die Arbeitsteilung, auf die wir uns verständigt haben: Prax kennt seinen Markt und seine Produkte, wir bringen ein, was ein Shop technisch und regulatorisch braucht. DSGVO-Konformität und Consent-Management waren von Beginn an Teil der Anforderungen — das mitzudenken, ist unsere Aufgabe, nicht die des Händlers. Zuletzt kamen die Kennzeichnungspflichten für KI-generierte Inhalte dazu. Solche Themen bringen wir aktiv ein, bevor sie akut werden.

Rund 80 Prozent des Projekts liefen sehr gut. Die verbleibenden 20 Prozent betrafen Abhängigkeiten außerhalb des Projektteams — und genau da liegt das Learning. Lieferketten, Partnerressourcen, Freigabewege: solche externen Abhängigkeiten würde ich beim nächsten Mal noch früher gemeinsam mit dem Kunden auf den Tisch legen.

Intern kann alles nach Plan laufen und der Termin verschiebt sich trotzdem. Diese Abhängigkeiten früh sichtbar zu machen, ist der Unterschied zwischen einem realistischen und einem optimistischen Plan. Wir nehmen das inzwischen fest in die Projektinitialisierung auf und fragen zu Beginn explizit nach allem, was außerhalb unseres Einflussbereichs liegt.