Die Kosten von Ausnahmen im E-Commerce – warum zu viel Customization die Skalierung des Vertriebs blockiert
Im E-Commerce ist es sehr leicht, Flexibilität mit unkontrollierter Customization zu verwechseln. Am Anfang wirkt jede Ausnahme nachvollziehbar. Ein B2B-Kunde benötigt eine andere Preisliste. Ein Markt erfordert eine separate Methode zur Berechnung der Lieferung. Eine Vertriebsabteilung bittet um einen zusätzlichen Bestellstatus. Ein Produkt benötigt eine nicht standardmäßige Variante. Ein Reklamationsprozess passt nicht in das Standardmodell. Ein Marketplace verlangt ein anderes Datenformat. Eine Promotion soll „nur dieses eine Mal“ nach einer speziellen Logik funktionieren.
Einzeln betrachtet wirken solche Entscheidungen harmlos und oft sogar geschäftlich begründet. Das Problem beginnt erst nach einiger Zeit, wenn das Unternehmen feststellt, dass seine E-Commerce-Plattform kein konsistentes Vertriebssystem mehr ist, sondern eine Sammlung von Ausnahmen, Ergänzungen, Workarounds und Abhängigkeiten, die niemand mehr einfach ordnen kann. Das, was einst dabei helfen sollte, schneller auf Geschäftsanforderungen zu reagieren, beginnt die Entwicklung zu blockieren. Jede weitere Änderung dauert länger, jedes Update erfordert Vorsicht, jede Integration wird teurer, und jede neue Funktion muss darauf geprüft werden, ob sie nicht etwas verletzt, das vor einigen Jahren als Ausnahme geschaffen wurde.
In vielen Unternehmen sind die Kosten der Customization nicht sofort sichtbar, weil sie nicht als eine große Position im Budget erscheinen. Sie verteilen sich auf Dutzende kleinere Kosten: längere Entwicklung, schwierigeres Testen, kompliziertere Wartung, langsamere Implementierungen, größere Abhängigkeit von bestimmten Personen, höheres Fehlerrisiko und geringere Projektplanbarkeit. Das Unternehmen denkt oft, dass es für die Entwicklung der Plattform zahlt, während in der Praxis ein immer größerer Teil des Budgets für die Aufrechterhaltung der Komplexität verwendet wird, die es zuvor selbst geschaffen hat.
Das ist besonders wichtig im B2B-E-Commerce, wo Komplexität ein natürlicher Bestandteil des Vertriebs ist. Individuelle Preise, Benutzerrollen, Limits, Freigabeprozesse, Organisationsstrukturen von Kunden, Handelsdokumente, ERP-Integrationen, Vertrags-Preislisten, Lieferbedingungen und Angebotsprozesse sind kein Zusatz, sondern Alltag. Es geht also nicht darum, Komplexität zu vermeiden. Es geht darum, sie bewusst zu gestalten. Gut modellierte Komplexität kann ein Vorteil sein. Eine Sammlung zufälliger Ausnahmen wird sehr schnell zu architektonischen Schulden.
In den neuesten Shopware-Materialien zum B2B Ecommerce Compass 2026 wird die Bedeutung einer stabilen, skalierbaren Commerce-Grundlage hervorgehoben, die Automatisierung, langfristiges Wachstum und die Vorbereitung auf intelligentere B2B-Vertriebsmodelle ermöglicht. Das zeigt gut, in welche Richtung sich der Markt bewegt: Unternehmen brauchen nicht mehr nur weitere Funktionen, sondern eine Architektur, die ihnen erlaubt, den Vertrieb weiterzuentwickeln, ohne ständig Ausnahmen zu Ausnahmen hinzuzufügen.
Warum das Thema gerade jetzt wichtig wird
Lange Zeit haben viele E-Commerce-Unternehmen ihre Plattformen im reaktiven Modus entwickelt. Es entstand ein Geschäftsbedarf, also suchte das Team nach einer Möglichkeit, ihn schnell umzusetzen. Es entstand ein neuer Markt, also wurden lokale Lösungen hinzugefügt. Es erschien ein großer B2B-Kunde, also wurde eine separate Logik erstellt. Es trat ein operatives Problem auf, also wurde ein Workaround hinzugefügt. Es erschien eine Promotion, also wurde eine Ausnahme programmiert. Diese Arbeitsweise kann am Anfang effektiv sein, besonders wenn ein Unternehmen schnell wachsen möchte und keine Zeit hat, Prozesse vollständig zu ordnen.
Der heutige E-Commerce funktioniert jedoch in einem völlig anderen Kontext als noch vor einigen Jahren. Eine Vertriebsplattform ist immer seltener nur ein Online-Shop. Immer häufiger ist sie ein Element einer größeren Umgebung, verbunden mit ERP, PIM, WMS, CRM, Marketplaces, Zahlungssystemen, Marketing-Automation-Tools, mobilen Anwendungen, einem Customer Portal, einem Data Warehouse, KI-Systemen und internationalen Kanälen. In einer solchen Umgebung betrifft jede Ausnahme nicht mehr nur eine Stelle. Sie kann Daten, Integrationen, Automatisierungen, Analytik, Kundenservice und die weitere Entwicklung der gesamten Plattform beeinflussen.
Der Druck, die Architektur zu ordnen, wächst auch deshalb, weil Unternehmen immer mehr Prozesse automatisieren möchten. Automatisierung funktioniert dort nicht gut, wo Regeln unklar sind und Geschäftslogik hauptsächlich in E-Mails, Tabellen, im Gedächtnis des Teams oder in Custom Code existiert, der für einen einmaligen Bedarf geschrieben wurde. KI, Agentic Commerce, B2B Self-Service, Personalisierung, dynamische Empfehlungen und fortgeschrittene Analytik erfordern Daten und Prozesse, die konsistent und für Systeme interpretierbar sind. Wenn die Plattform voller Ausnahmen ist, löst Automatisierung das Problem nicht. Sie zeigt nur schneller, dass das Fundament nicht stabil ist.
Im B2B dürfen digitaler Self-Service, von Vertriebsmitarbeitern unterstützter Vertrieb und Operations nicht als getrennte Domänen betrachtet werden, sondern sollten sich zu einer konsistenten, skalierbaren Commerce-Grundlage verbinden. Das ist wichtig, weil gerade das Fehlen einer solchen Grundlage dazu führt, dass Unternehmen beginnen, Architektur durch weitere individuelle Lösungen zu ersetzen.
In der Praxis bedeutet das, dass 2026 und die folgenden Jahre nicht die Organisationen belohnen werden, die am meisten customizen, sondern diejenigen, die einen echten Geschäftsbedarf von einem Prozess unterscheiden können, der standardisiert werden sollte. Im modernen E-Commerce entsteht der Vorteil nicht durch die Anzahl der Ausnahmen, sondern durch die Fähigkeit, Flexibilität kontrolliert zu gestalten.
Wann Customization notwendig ist und wann sie zu schaden beginnt
Customization ist an sich kein Problem. In vielen E-Commerce-Projekten ist sie notwendig, besonders wenn ein Unternehmen ein komplexes Vertriebsmodell, spezifische B2B-Prozesse, individuelle Integrationen, nicht standardmäßige Logistik oder Branchenanforderungen hat, die sich nicht ausschließlich über die Standardkonfiguration der Plattform abbilden lassen. Gut gestaltete Customization kann eine Quelle von Wettbewerbsvorteilen sein, weil sie es ermöglicht, das Geschäftsmodell des Unternehmens in Technologie abzubilden.
Das Problem beginnt dann, wenn Customization das prozessuale Denken ersetzt. Anstatt zu fragen, warum eine bestimmte Ausnahme existiert und ob sie wirklich im System verankert werden sollte, fragt das Unternehmen sofort, wie viel es kosten wird, sie hinzuzufügen. Anstatt die Funktionsweise von Promotions, Preislisten, Lieferungen, Berechtigungen oder Produktdaten zu ordnen, erstellt es eine weitere Sonderregel. Anstatt ein Modell zu entwerfen, das skalierbar sein wird, baut es eine Lösung nur für den nächsten Fall.
Der Unterschied zwischen guter Customization und einer schädlichen Ausnahme liegt darin, ob die Lösung Teil einer durchdachten Architektur ist. Wenn eine nicht standardmäßige Funktion einen Owner, Dokumentation, Geschäftslogik, Tests, einen klaren Einfluss auf andere Systeme und einen Wartungsplan hat, kann sie ein wertvolles Element der Plattform sein. Wenn sie schnell, ohne Dokumentation, ohne Analyse der Abhängigkeiten und ohne Antwort auf die Frage entstanden ist, was bei der nächsten Änderung passieren wird, wird sie zu technologischen Schulden.
Im B2B-E-Commerce ist die Grenze besonders schmal. Individuelle Preise für Kunden sind normal. Das Problem entsteht, wenn jede Kundengruppe eine eigene Preislogik hat, jede Promotion anders bedient wird und Rabattregeln zwischen ERP, E-Commerce-Plattform, Vertriebsmitarbeitern und Tabellen verstreut sind. Unterschiedliche Liefermethoden sind normal. Das Problem entsteht, wenn die Lieferkosten von mehreren undokumentierten Bedingungen abhängen, die nur eine Person im Unternehmen versteht. Freigabeprozesse sind normal. Das Problem entsteht, wenn Ausnahmen von Freigaben wichtiger werden als der Prozess selbst.
Eine gut gestaltete Plattform sollte Flexibilität ermöglichen, ohne die Kontrolle zu verlieren. Genau deshalb haben Mechanismen für Konfiguration, Geschäftsregeln, Integrationen und Erweiterungen eine so große Bedeutung. Shopware Rule Builder ermöglicht den Aufbau von Regeln, die unter anderem in den Bereichen Zahlungsmethoden, Lieferungen, Promotions, Rabatte, erweiterte Preise sowie Sichtbarkeit von Produkten und Kategorien verwendet werden. Solche Mechanismen sind wichtig, weil sie ermöglichen, einen Teil der Komplexität konfigurierbar zu bedienen, anstatt jedes Mal separaten Code hinzuzufügen.
Der größte Fehler: eine Ausnahme mit einem Wettbewerbsvorteil verwechseln
In vielen Unternehmen gibt es die Überzeugung, dass ein Prozess automatisch einen Wettbewerbsvorteil darstellt, wenn er nicht standardmäßig ist. Das ist nicht immer wahr. Manchmal ergibt sich die Nicht-Standardisierung aus der tatsächlichen Spezifik des Geschäfts. Häufig ergibt sie sich jedoch aus historischen Entscheidungen, fehlender Ordnung, Gewohnheiten des Teams oder Versuchen, die Einschränkungen eines alten Systems zu umgehen.
Ein Unternehmen kann behaupten, ein einzigartiges Rabattmodell zu haben, besitzt in der Praxis aber mehrere inkonsistente Regeln, die in verschiedenen Jahren entstanden sind und nie geordnet wurden. Es kann behaupten, sein B2B-Prozess sei sehr spezifisch, während in Wirklichkeit viele Ausnahmen nur deshalb existieren, weil die vorherige Plattform die Kundenstruktur nicht bedienen konnte. Es kann meinen, dass es eine Custom-Lieferlogik benötigt, obwohl ein Teil des Problems aus fehlender Integration mit ERP oder WMS resultiert. Es kann manuelle Freigaben verteidigen, obwohl der Prozess automatisiert werden könnte, wenn Rollen, Limits und Bedingungen korrekt im System abgebildet wären.
Das ist einer der teuersten Momente in der Entwicklung des E-Commerce: Das Unternehmen zahlt dafür, Chaos zu erhalten, das es für Geschäftsspezifik hält. Anstatt die Implementierung oder Weiterentwicklung der Plattform zu nutzen, um Prozesse zu vereinfachen, überträgt es alte Ausnahmen in das neue System. In der Folge beginnt moderne Technologie, die Probleme der vorherigen Umgebung nachzubilden.
Ein Wettbewerbsvorteil besteht nicht darin, dass jeder Prozess anders ist. Er besteht darin, dass das Unternehmen Komplexität schneller, stabiler und besser als die Konkurrenz bedienen kann. Wenn Customization dem Kunden den Einkauf erleichtert, die operative Effizienz erhöht, die Bearbeitungszeit verkürzt, die Datenqualität verbessert oder die Skalierung des Vertriebs ermöglicht, kann sie ein Vorteil sein. Wenn sie manuelle Kontrolle erfordert, Integrationen erschwert, Updates blockiert und jede Änderung teuer macht, ist sie ein Kostenfaktor.
Deshalb lohnt es sich, vor jeder größeren Customization einige Fragen zu stellen. Schafft dieser Prozess tatsächlich Wert für den Kunden oder das Geschäft? Kann er durch Konfiguration statt durch Code bedient werden? Gibt es eine einfachere Variante? Wird die Ausnahme in einem Jahr noch benötigt? Verstehen wir ihren Einfluss auf ERP, PIM, WMS, CRM, Checkout, Analytik und Kundenservice? Werden wir sie testen, warten und weiterentwickeln können? Wenn die Antworten unklar sind, kann Customization eher ein Risiko als eine Investition sein.
Wie Ausnahmen architektonische Schulden erzeugen
Architektonische Schulden im E-Commerce entstehen nicht ausschließlich durch schlechten Code. Sie entstehen auch durch Geschäftsentscheidungen, die nicht in ein konsistentes Systemmodell übersetzt wurden. Jede Ausnahme hat ihre Kosten, auch wenn man sie im Moment der Implementierung nicht sieht. Die Kosten zeigen sich beim nächsten Projekt, der nächsten Integration, der nächsten Migration, dem nächsten Audit, dem nächsten Teamwechsel oder dem nächsten Automatisierungsversuch.
Ausnahmen erschweren das Testen, weil nicht nur der Standardpfad, sondern auch alle speziellen Szenarien geprüft werden müssen. Sie erschweren die Entwicklung, weil der Entwickler verstehen muss, warum eine bestimmte Funktion für eine konkrete Kundengruppe, einen Markt oder eine Kategorie anders funktioniert. Sie erschweren Integrationen, weil Daten nicht nach einem einheitlichen logischen Modell fließen. Sie erschweren Analytik, weil Reports nicht standardmäßige Definitionen von Bestellungen, Rabatten, Preisen, Status oder Marge berücksichtigen müssen. Sie erschweren das Onboarding neuer Personen, weil das Wissen über das System nicht aus der Dokumentation hervorgeht, sondern aus der Geschichte der Ausnahmen.
Das größte Problem besteht darin, dass architektonische Schulden dazu neigen, sich zu kumulieren. Eine nicht standardmäßige Preisregel muss kein Problem sein. Zehn solcher Regeln, die zu unterschiedlichen Zeitpunkten und an verschiedenen Stellen des Systems implementiert wurden, können die Entwicklung bereits blockieren. Ein nicht standardmäßiger Connector zu ERP kann eine Zeit lang gut funktionieren. Mehrere Connectoren, uneinheitliches Datenmapping und manuelle Korrekturen in Dateien beginnen eine Umgebung zu schaffen, die niemand ohne Angst vor Konsequenzen anfassen möchte.
In einem solchen Moment bemerkt das Unternehmen oft, dass die Entwicklung der Plattform immer langsamer wird, versteht aber nicht immer, warum. Es entsteht Frustration darüber, dass jede Änderung mehr kostet, als sie sollte. Das Business-Team findet, dass die Technologie zu langsam ist. Das Technologie-Team findet, dass die Anforderungen zu chaotisch sind. Der Implementierungspartner spricht von der Notwendigkeit eines Refactorings oder Umbaus. Die Geschäftsführung sieht steigende Kosten, sieht aber keine einzelne Entscheidung, die sie verursacht hat. Denn das Problem entstand nicht aus einer Entscheidung. Es entstand aus vielen Ausnahmen, die über Jahre nicht kontrolliert wurden.
Deshalb sollten die Kosten der Customization nicht nur im Moment ihrer Implementierung bewertet werden, sondern auch über den gesamten Lebenszyklus der Plattform. Die eigentliche Frage lautet nicht: „Wie viel kostet es, diese Funktion hinzuzufügen?“. Die eigentliche Frage lautet: „Wie viel wird es kosten, diese Logik in den nächsten Jahren bei Updates, Integrationen, Teamwechseln, B2B-Entwicklung, internationaler Expansion und Automatisierung zu warten?“.
B2B: dort, wo Ausnahmen natürlich sind, ist Architektur am wichtigsten
B2B-Vertrieb ist per Definition komplexer als klassisches B2C. Kunden kaufen nicht immer in ihrem eigenen Namen, sondern im Namen einer Organisation. Benutzer haben unterschiedliche Rollen. Preise sind individuell. Bestellungen können Freigaben erfordern. Handelsbedingungen hängen vom Vertrag, der Historie der Zusammenarbeit, dem Einkaufsvolumen oder Absprachen mit dem Vertriebsmitarbeiter ab. Produkte können nur für ausgewählte Kunden verfügbar sein. Der Einkaufsprozess kann mit dem System des Kunden verbunden sein. Dokumente, Rechnungen, Limits, Budgets und Angebote sind Teil des täglichen Vertriebs.
Genau deshalb ist B2B ein Bereich, in dem Customization gerechtfertigt sein kann, aber auch besonders riskant ist. Wenn ein Unternehmen den Unterschied zwischen Komplexität, die modelliert werden muss, und Ausnahmen, die geordnet werden müssen, nicht erkennt, wird die B2B-Plattform zu einem digitalen Spiegelbild aller Ineffizienzen der Organisation.
Guter B2B-E-Commerce sollte nicht darauf beruhen, dass jedem Kunden separat eine Logik hinzugefügt wird. Er sollte auf einem Modell basieren, das erlaubt, Unterschiede kontrolliert zu verwalten. Kundenstrukturen, Rollen, Preise, Rabatte, Limits, Lieferbedingungen und Freigabeprozesse sollten Teil der Architektur sein und nicht eine Sammlung versteckter Ausnahmen. Je größer die Vertriebsskala, desto wichtiger wird diese Unterscheidung.
Intelligenter B2B-Commerce basiert auf digitaler Reife sowie einer soliden, skalierbaren E-Commerce-Grundlage, die Automatisierung, langfristiges Wachstum und Agentic Commerce ermöglicht. Das ist wichtig, weil B2B nicht nur Flexibilität braucht. Es braucht Flexibilität, die gewartet und weiterentwickelt werden kann.
In der Praxis bedeutet das, dass ein Unternehmen sehr vorsichtig damit umgehen sollte, historische Ausnahmen auf eine neue Plattform zu übertragen. Die Implementierung oder Weiterentwicklung von B2B-E-Commerce ist ein guter Moment, um zu fragen, welche Regeln tatsächlich aus der Vertriebsstrategie resultieren und welche nur das Ergebnis jahrelanger Workarounds sind. Das ist eine schwierige Arbeit, weil sie Gespräche zwischen Vertrieb, Operations, Finanzen, IT und Geschäftsführung erfordert. Ohne sie wird Technologie lediglich Chaos automatisieren.
Ausnahmen in Produktdaten
Einer der am meisten unterschätzten Bereiche der Customization sind Produktdaten. Auf den ersten Blick betrifft das Problem nur den Katalog: Beschreibungen, Bilder, Parameter, Kategorien, Filter und Varianten. In der Praxis beeinflussen Produktdaten Suche, SEO, Empfehlungen, Marketplaces, internationalen Vertrieb, B2B, Digital Product Passport, PIM-Integrationen, Kundenservice, Verfügbarkeit von Ersatzteilen, technische Dokumentation und Automatisierung.
Ausnahmen in Produktdaten entstehen sehr leicht. Eine Kategorie hat andere Attribute als der Rest. Ein Lieferant übermittelt Daten in einem anderen Format. Ein Markt verlangt eine andere Beschreibung. Eine Produktgruppe hat nicht standardmäßige Varianten. Eine Marke möchte eine andere Art der Präsentation. Ein Marketplace erzwingt zusätzliche Felder. Am Anfang lässt sich alles manuell bedienen. Bei größerer Skalierung beginnt die manuelle Verwaltung von Ausnahmen, die Datenqualität zu zerstören.
Das Problem besteht darin, dass Produktdaten modelliert und nicht nur ergänzt werden sollten. Wenn ein Unternehmen keine klare Struktur von Attributen, Quellen der Wahrheit, Übersetzungsregeln, Variantenlogik, Qualitätskontrolle und Integration mit PIM hat, erhöht jede Ausnahme die Kosten für die Pflege des Katalogs. Das E-Commerce-Team verbringt mehr Zeit mit der Korrektur von Daten als mit der Weiterentwicklung des Vertriebs. Marketplace-Integrationen erfordern weitere Mappings. KI generiert Inhalte auf Basis unvollständiger Informationen. Der Kunde sieht Inkonsistenzen, und das Unternehmen verliert das Vertrauen in den eigenen Katalog.
Customization von Produktdaten ist manchmal notwendig, sollte aber auf der Ebene des Modells gestaltet werden, nicht auf der Ebene eines einzelnen Produkts. Wenn eine bestimmte Kategorie andere Attribute erfordert, muss dies modelliert werden. Wenn verschiedene Märkte unterschiedliche Inhalte erfordern, muss ein Lokalisierungsprozess entworfen werden. Wenn Daten von Lieferanten stammen, müssen Regeln für Import, Validierung und Aktualisierung festgelegt werden. Wenn PIM die Datenquelle ist, sollte die E-Commerce-Plattform wissen, welche Informationen sie abruft, wo sie sie präsentiert und wie sie auf Änderungen reagiert.
Andernfalls erstellt das Unternehmen einen Katalog, der im Frontend gut aussehen kann, operativ aber instabil ist. Und im modernen E-Commerce ist der Produktkatalog nicht mehr nur Inhalt. Er ist Teil der Vertriebsinfrastruktur.
Ausnahmen in Integrationen
Der zweite Bereich, in dem die Kosten von Ausnahmen sehr schnell wachsen, sind Integrationen. E-Commerce funktioniert selten eigenständig. Die Vertriebsplattform kommuniziert mit ERP, PIM, WMS, CRM, Zahlungen, Kurieren, Marketplaces, Buchhaltungssystemen, Marketing-Tools, BI und vielen anderen Elementen. Jede Integration erfordert Entscheidungen: welche Daten übertragen werden, in welche Richtung, wie oft, in welchem Format, mit welcher Priorität und was im Fehlerfall passiert.
Ausnahmen in Integrationen entstehen oft unter Zeitdruck. Ein System hat kein passendes Feld, also wird ein Workaround hinzugefügt. Ein Prozess passt nicht zur Standardsynchronisation, also entsteht ein nicht standardmäßiges Mapping. Ein Kanal erfordert ein anderes Format, also wird ein separater Export erstellt. Ein Lieferant unterstützt keine API, also werden Daten per Datei übertragen. Eine Operation erfordert eine manuelle Korrektur, also gewöhnt sich das Team daran, Daten unterwegs zu korrigieren.
Jeder solche Workaround kann funktionieren. Das Problem besteht darin, dass Integrationen wie das Nervensystem des E-Commerce sind. Wenn die Signale inkonsistent sind, beginnt der ganze Organismus falsch zu reagieren. Der Preis kann im ERP korrekt sein, aber im Shop falsch. Der Lagerbestand kann im WMS aktuell sein, aber im Marketplace verzögert. Kundendaten können im CRM geändert sein, aber in der B2B-Plattform unsichtbar bleiben. Eine Bestellung kann durch den Shop gehen, aber im operativen System stecken bleiben.
Shopware basiert auf einer offenen API-first-Architektur und kann laut offiziellen Materialien mit den Systemen integriert werden, von denen das Geschäft abhängt. Das gibt Unternehmen große Möglichkeiten, entbindet sie aber gleichzeitig nicht von der Verantwortung, Integrationen als Teil der Architektur zu gestalten und nicht als Sammlung punktueller Verbindungen.
Die Plattform, die wir bei CREHLER implementieren, stellt unter anderem die Admin API für Backend-Operationen wie Produkte, Bestellungen, Kunden, Plugins und Massenverarbeitung über die Sync API sowie die Store API für Storefront-Interaktionen wie Headless-Frontends, mobile Anwendungen, Warenkörbe, Checkout und Zugriff auf den Sales Channel zur Verfügung. Das zeigt, dass eine gut gestaltete Plattform ein offenes Element des Ökosystems sein kann, der Wert dieser Offenheit jedoch von der Qualität des Integrationsdesigns abhängt.
Ausnahmen im Checkout und im Kaufprozess
Der Checkout ist einer der Orte, an denen die Kosten von Ausnahmen den Vertrieb besonders stark beeinflussen. Im B2C senkt ein zu komplizierter Checkout die Conversion, erhöht Warenkorbabbrüche und verschlechtert die Kundenerfahrung. Im B2B sind die Konsequenzen noch gravierender, weil der Checkout oft nicht nur Zahlung und Lieferung bedienen muss, sondern auch Limits, Benutzerrollen, Freigaben, Rechnungen, Bestellnummern des Kunden, Handelsbedingungen, Produktverfügbarkeit, Mindestbestellwerte und Integration mit ERP.
Ausnahmen im Checkout entstehen dann, wenn ein Unternehmen versucht, jede ungewöhnliche Kaufsituation abzubilden, ohne zuvor ein Modell entworfen zu haben. Ein Kunde muss andere Zahlungsmethoden sehen. Der zweite darf nur ausgewählte Produkte bestellen. Der dritte benötigt die Freigabe eines Managers. Der vierte kauft auf Vertragsbasis. Der fünfte hat eine nicht standardmäßige Lieferung. Der sechste benötigt ein separates Feld in der Bestellung. Wenn jede solche Situation als separate Ausnahme bedient wird, wird der Checkout schnell zur riskantesten Stelle der Plattform.
Ein guter Checkout sollte flexibel, aber vorhersehbar sein. Er sollte aus Geschäftsregeln resultieren und nicht aus zufälligen Bedingungen im Code. Er sollte dem Kunden klar kommunizieren, was er tun kann, welche Einschränkungen er hat, welche Bedingungen gelten und was nach dem Absenden der Bestellung passiert. Im B2B ist es besonders wichtig, dass der Kaufprozess vom Kunden nicht verlangt, zu erraten, warum etwas nicht verfügbar ist, warum der Preis anders aussieht oder warum die Bestellung nicht aufgegeben werden kann.
Wenn der Checkout voller Ausnahmen ist, verliert das Unternehmen sehr schnell die Möglichkeit, ihn weiterzuentwickeln. Das Hinzufügen einer neuen Zahlungsmethode erfordert die Prüfung vieler Szenarien. Eine Änderung des Lieferprozesses kann die Logik für bestimmte Kunden verletzen. Ein neuer Markt erfordert separates Testen. Die Integration mit ERP wird schwieriger, weil eine Bestellung in verschiedenen Fällen unterschiedliche Bedeutungen hat. Anstatt der Ort des Abschlusses des Verkaufs zu sein, wird der Checkout zum Ort der Kumulation von Prozessschulden.
Deshalb lohnt es sich, den Checkout in E-Commerce-Projekten als Teil der Vertriebsarchitektur zu behandeln und nicht nur als letzte Etappe der User Journey. Besonders im B2B sollte er gemeinsam mit dem Modell der Kunden, Rollen, Preislisten, Handelsbedingungen, Verfügbarkeiten und Integrationen gestaltet werden.
Wo Unternehmen am häufigsten für übermäßige Customization zahlen
Am häufigsten zahlen Unternehmen für übermäßige Customization an Stellen, die für den Kunden nicht sichtbar sind. Der Kunde sieht den Shop, den Warenkorb, das Konto, das Formular und die Meldungen. Er sieht jedoch nicht die Kosten für die Aufrechterhaltung der Logik, die dafür sorgt, dass diese Elemente funktionieren. Genau deshalb ist Customization Debt dem Business so schwer zu erklären. Es scheint, dass eine Änderung einfach sein sollte, wenn das Frontend ähnlich aussieht. In der Tiefe kann jedoch ein komplexes System von Abhängigkeiten existieren.
Der erste Kostenbereich ist die Entwicklung. Jede Änderung erfordert das Verständnis bestehender Ausnahmen. Der Entwickler kann nicht einfach eine Funktion implementieren. Er muss prüfen, ob eine bestimmte Logik nicht konkrete Kundengruppen, Integrationen, Promotions, Lieferregeln, Marketplaces oder nicht standardmäßige Felder beeinflusst. Je weniger Dokumentation vorhanden ist, desto mehr Zeit nimmt die Analyse in Anspruch.
Der zweite Bereich ist das Testen. Standardtests reichen nicht aus, wenn die Plattform viele spezielle Szenarien hat. Es müssen B2B-Kunden, unterschiedliche Rollen, verschiedene Preislisten, Märkte, Sprachen, Liefermethoden, Promotions, Integrationen und Bestellstatus getestet werden. Je mehr Ausnahmen, desto größer das Risiko, dass etwas übersehen wird.
Der dritte Bereich ist die Wartung. Jedes Update der Plattform, eines Plugins, einer Integration oder des Frontends kann zusätzliche Vorsicht erfordern. Shopware ermöglicht die Erweiterung der Plattform durch Apps und Plugins, wobei Plugins sich tief in die Plattform integrieren und ihre grundlegenden Fähigkeiten verändern können. Solche Mechanismen sind sehr wertvoll, erfordern aber bewusste Gestaltung, weil ein tiefer Eingriff in das System immer die Verantwortung für Wartung und Kompatibilität erhöht.
Der vierte Bereich ist die Abhängigkeit von Menschen. Wenn das Wissen über Ausnahmen in den Köpfen weniger Personen liegt, verliert das Unternehmen Vorhersehbarkeit. Ein Wechsel des Teams, des Technologiepartners oder der Person auf Kundenseite kann plötzlich zeigen, dass niemand die vollständige Logik der Plattform versteht.
Der fünfte Bereich ist verlorene Geschwindigkeit. Das Unternehmen kann ein Budget für Entwicklung haben, es aber nicht effektiv nutzen, weil ein großer Teil der Arbeit in Analyse, Vorsicht, Korrekturen und Wartung fließt. Das ist einer der teuersten Kostenfaktoren, weil er nicht immer direkt auf der Rechnung erscheint. Er erscheint als verspäteter Launch, nicht implementierte Automatisierung, nicht abgeschlossene Expansion, langsamere B2B-Entwicklung oder Verzicht auf eine Funktion, die „auf unserer Plattform zu teuer wäre“.
Wie man notwendige Flexibilität von technologischen Schulden unterscheidet
Nicht jede Customization ist schlecht. Nicht jede Konfiguration reicht aus. Nicht jeder Standardprozess passt zum Unternehmen. Deshalb ist nicht die Frage entscheidend, ob man customizen soll, sondern wie Entscheidungen über Customization getroffen werden.
Das erste Kriterium sollte der Geschäftswert sein. Wenn Customization das zentrale Vertriebsmodell unterstützt, die Conversion erhöht, den Service für große Kunden verbessert, einen kostspieligen Prozess automatisiert oder den Eintritt in einen wichtigen Markt ermöglicht, kann sie sinnvoll sein. Wenn sie ausschließlich der Aufrechterhaltung einer historischen Gewohnheit dient, ist Vorsicht geboten.
Das zweite Kriterium sollte die Wiederholbarkeit sein. Ein Prozess, der viele Kunden, viele Märkte oder viele Kategorien betrifft, sollte systemisch modelliert werden. Ein Prozess, der einen einzigen Ausnahmefall betrifft, sollte nicht immer dauerhaft in der Architektur verankert werden. Manchmal ist eine Änderung des Geschäftsprozesses die bessere Lösung als das Hinzufügen einer Funktion.
Das dritte Kriterium sollte die Möglichkeit der Bedienung durch Konfiguration sein. Wenn die Plattform Mechanismen wie Regeln, Sales Channels, Custom Fields, Erweiterungen, Plugins oder API bietet, lohnt es sich zuerst zu prüfen, ob der Bedarf in einer Weise bedient werden kann, die mit der Plattformarchitektur übereinstimmt. Shopware besitzt eine modulare API-first-Architektur, in der Storefront, Administration und Geschäftslogik sich als separate Schichten entwickeln können, die ein gemeinsames Backend nutzen. Ein solches Modell bietet Entwicklungsmöglichkeiten, erfordert aber Entscheidungen darüber, welche Elemente Konfiguration, welche Erweiterung und welche separate Geschäftslogik sein sollten.
Das vierte Kriterium sollte der Wartungsaufwand sein. Jede Customization sollte einen Owner, Dokumentation, Tests, eine Monitoring-Methode und einen Aktualisierungsplan haben. Wenn das Unternehmen nicht bereit ist, eine Lösung zu warten, sollte es sie nicht nur deshalb implementieren, weil sie schnell geschrieben werden kann.
Das fünfte Kriterium sollte der Einfluss auf die Zukunft sein. Eine gute architektonische Entscheidung löst nicht nur das heutige Problem, sondern versperrt nicht den Weg zu weiteren Änderungen. Wenn Customization Migration, Updates, B2B-Entwicklung, PIM-Integration, KI-Implementierung oder internationale Expansion erschwert, können ihre Kosten deutlich höher sein als die ursprüngliche Schätzung.
Wie Shopware hilft, Komplexität ohne übermäßige Ausnahmen zu verwalten
Shopware ist eine Plattform, die gut zu einem Ansatz passt, in dem Komplexität modelliert und nicht zufällig hinzugefügt werden sollte. Ihr Wert liegt nicht nur darin, dass man sie customizen kann. Der Wert liegt darin, dass man die Plattform modular, offen und integrationsorientiert gestalten kann, indem man den passenden Grad an Konfiguration, Erweiterungen und Verbindungen zu anderen Systemen nutzt.
Mechanismen wie Rule Builder ermöglichen es, einen Teil der Geschäftslogik in konfigurierbare Regeln zu übertragen. Sales Channels erlauben es, verschiedene Vertriebskanäle als Elemente einer Plattform zu betrachten. Der API-first-Ansatz ermöglicht die Integration mit externen Systemen. Store API und Admin API ermöglichen die Bedienung verschiedener Kommunikationsszenarien mit der Plattform. Plugins und Apps geben die Möglichkeit, Funktionen zu erweitern, erfordern aber eine bewusste Entscheidung über den Grad des Eingriffs in das System.
Das ist wichtig, weil gute Architektur nicht im Fehlen von Customization besteht. Sie besteht darin, dass jede Customization ihren Platz hat. Eine einfache Promotion-Regel wird anders gestaltet, eine ERP-Integration anders, ein B2B-Angebotsprozess anders, die Logik eines Customer Portals wieder anders und ein Headless Frontend noch einmal anders. Wenn alle Bedürfnisse gleich behandelt werden, wird die Plattform schnell schwer wartbar.
In Shopware-Projekten ist es besonders wichtig zu unterscheiden, was Konfiguration sein sollte und was Integration, Erweiterung oder Änderung eines Geschäftsprozesses sein sollte. Nicht jeder Bedarf erfordert Code. Nicht jeder Bedarf sollte durch ein Plugin bedient werden. Nicht jeder Bedarf sollte ins ERP gelangen. Nicht jeder Bedarf sollte im Frontend gelöst werden. Die Entscheidung hängt davon ab, wo sich die Quelle der Wahrheit befindet, wer den Prozess verwaltet, wie oft sich die Logik ändern wird und welchen Einfluss sie auf das gesamte Ökosystem hat.
Deshalb kann Shopware eine sehr gute Grundlage für Unternehmen sein, die Flexibilität benötigen, aber keine Plattform als Sammlung zufälliger Lösungen aufbauen möchten. Entscheidend ist jedoch die Implementierung. Dieselbe Plattform kann als stabiles Entwicklungsumfeld oder als System voller undokumentierter Ausnahmen gestaltet werden. Der Unterschied ergibt sich nicht ausschließlich aus der Technologie. Er ergibt sich aus architektonischen Entscheidungen.
Flexibilität gestalten, statt Ausnahmen zu produzieren
Bei CREHLER betrachten wir Customization sehr praktisch. Wir gehen nicht davon aus, dass jede nicht standardmäßige Anforderung schlecht ist. In E-Commerce-Projekten, besonders im B2B, erfordern viele Prozesse tatsächlich einen individuellen Ansatz. Das Problem ist also nicht die Customization selbst, sondern der fehlende Überblick darüber, warum sie entsteht, wo sie platziert ist, wie sie das System beeinflusst und wie viel sie in der Wartung kosten wird.
Deshalb beginnen wir in Shopware-Projekten nicht ausschließlich mit einer Liste der zu implementierenden Funktionen. Wir analysieren Prozesse, Daten, Integrationen, Quellen der Wahrheit, Benutzerrollen, Preislogik, das Katalogmodell, Operations und Geschäftsziele. Erst dann lässt sich entscheiden, welche Anforderungen standardmäßig bedient werden sollten, welche durch Konfiguration, welche durch Integration, welche durch Erweiterung und welche eine Prozessänderung auf Seiten der Organisation erfordern.
Dieser Ansatz ist besonders wichtig in Unternehmen, die E-Commerce nach mehreren Jahren Betrieb auf einer älteren Plattform weiterentwickeln. In solchen Projekten entsteht sehr häufig die Versuchung, alles eins zu eins zu übertragen. Dasselbe Rabattmodell, dieselben Ausnahmen, dieselben manuellen Status, dieselben ungewöhnlichen Felder, dieselben Integrations-Workarounds und dieselben Prozesse, die zufällig entstanden sind. Unsere Rolle als Technologiepartner besteht nicht nur darin, das System zu implementieren, sondern dabei zu helfen zu bewerten, welche Elemente echten Wert darstellen und welche Kosten aus der vorherigen Umgebung geerbt wurden.
Bei CREHLER gestalten wir E-Commerce mit Blick auf langfristige Entwicklung. Das bedeutet, dass die Plattform nicht nur für den Start bereit sein sollte, sondern auch für weitere Märkte, Kanäle, Integrationen, Automatisierungen, B2B-Entwicklung, Änderungen im Katalog, KI, Analytik und weitere Optimierung. Übermäßige Ausnahmen blockieren sehr häufig genau diese zweite Phase: die Entwicklung nach der Implementierung.
In der Praxis sind die besten Implementierungen nicht diejenigen, bei denen alles um jeden Preis „angepasst“ wurde. Die besten Implementierungen sind diejenigen, bei denen das Unternehmen Kontrolle darüber hat, was Standard ist, was Regel ist, was Ausnahme ist und warum. Eine solche Plattform kann sich entwickeln, ohne dass die Kosten sprunghaft steigen, weil ihre Komplexität gestaltet und nicht zufällig angesammelt wurde.
Unternehmen, die die Kosten von Ausnahmen begrenzen, werden den Vertrieb schneller skalieren
E-Commerce braucht heute nicht weniger Flexibilität. Er braucht intelligentere Flexibilität. Unternehmen werden weiterhin individuelle Prozesse, unterschiedliche Kundenmodelle, lokale Anforderungen, Integrationen, komplexe Kataloge und spezifische Vertriebsregeln haben. Der Unterschied wird darin bestehen, ob diese Komplexität bewusst gestaltet wird oder als Sammlung von Ausnahmen anwächst.
Organisationen, die ihre Prozesse, Daten und Architektur ordnen, werden neue Funktionen schneller implementieren, Systeme leichter integrieren, den Vertrieb sicherer automatisieren, B2B effektiver entwickeln und sich besser auf KI, Agentic Commerce und neue Marktanforderungen vorbereiten können. Organisationen, die weiter unkontrolliert Ausnahmen hinzufügen, werden immer häufiger dasselbe Problem erleben: Je mehr sie in Entwicklung investieren, desto mehr Geld verschlingt die Wartung früherer Entscheidungen.
Die Kosten von Ausnahmen sind nicht immer im ersten Budget sichtbar. Sie werden sichtbar, wenn eine einfache Änderung einen Monat dauert. Wenn ein neuer Markt den Umbau der Logik erfordert. Wenn die Integration mit ERP sich als riskant erweist. Wenn KI die Daten nicht nutzen kann, weil sie nicht konsistent sind. Wenn ein B2B-Kunde zur E-Mail zurückkehrt, weil die Plattform seine realen Bedingungen nicht abbildet. Wenn das Team Angst vor Updates hat, weil es nicht weiß, was nicht mehr funktionieren wird.
Deshalb lohnt es sich, nicht mehr ausschließlich zu fragen, ob sich eine bestimmte Funktion implementieren lässt. Im modernen E-Commerce lautet die viel wichtigere Frage: Lässt sie sich so implementieren, dass sie das Chaos nicht vergrößert, sondern die Architektur stärkt?
Bei CREHLER helfen wir Unternehmen, skalierbare E-Commerce-Plattformen auf Basis von Shopware zu gestalten und weiterzuentwickeln, die Flexibilität mit Kontrolle verbinden. Wenn du prüfen möchtest, ob deine Plattform Entwicklung unterstützt oder immer häufiger die Kosten alter Ausnahmen aufrechterhält, lohnt es sich, mit einem Gespräch über Architektur, Prozesse und Daten zu beginnen. Genau dort beginnt am häufigsten der Unterschied zwischen E-Commerce, der wächst, und E-Commerce, der nur immer teurer funktioniert.
