Multi-Brand E-Commerce-Betreiber: Ein Plugin-Konflikt während der Shopware-Migration wurde zum Musterbeispiel für Service-Wiederherstellung. NPS 10. Ein Senior-Experte ist fest im Team integriert. Da…

Die Herausforderung

Gradion wurde beauftragt, die Migration des Kunden von OXID zu Shopware zu unterstützen, beginnend mit dem Modesegment. Das interne Team des Unternehmens übernahm die Migration des Reitsport-Segments. Obwohl die Shops eine gemeinsame Infrastruktur nutzten, waren ihre Geschäftsanforderungen unterschiedlich – eine Komplexität, die sich als entscheidend erweisen sollte. Gradion entwickelte eine Reihe kundenspezifischer Plugins, die auf die spezifischen Anforderungen des Modesegments zugeschnitten waren. Eines dieser Plugins wurde später von einer anderen Partei im Reitsport-Segment wiederverwendet, ohne vorherige Abstimmung mit Gradion oder gemeinsame Tests gegen die abweichende Geschäftslogik des Reitsport-Segments. Das Plugin funktionierte zwar, doch in einer Live-Umgebung mit unterschiedlichen Betriebsregeln führten kleine Inkompatibilitäten zu operativen Problemen. Es entstand ein vielschichtiges Problem: Technische Fehlfunktion: Das Plugin war für das Modesegment entwickelt worden. Ohne Anpassung im Reitsport-Segment eingesetzt, führte es zu Reibungsverlusten mit dessen spezifischen Prozessen. Diese Probleme traten schrittweise im Produktivbetrieb auf, nicht in Tests. Lücke bei Standards: Einige der von Gradion angewandten Entwicklungspraktiken entsprachen nicht vollständig den internen Qualitätsanforderungen des Kunden. Dies wurde erst entdeckt, als der Plugin-Konflikt auftrat. Zu diesem Zeitpunkt mussten beide Teams ein offenes Gespräch darüber führen, was „fertig“ bedeutet. Kommunikationsfehler: Die Ursache war weder böse Absicht noch Inkompetenz. Das Plugin wurde als gut gemeinte Abkürzung wiederverwendet. Diese Abkürzung umging jedoch die Abstimmungs- und Testschritte, die das Problem hätten aufdecken können. Das System war nicht wegen schlechten Codes fragil, sondern wegen einer Kommunikationslücke im Prozess. Die Frage zu diesem Zeitpunkt war nicht technischer Natur. Es ging darum, ob die Beziehung genügend Vertrauen und Reife besaß, um das Problem offen anzugehen und gestärkt daraus hervorzugehen.

Der Ansatz

Gradion wandte das Service-Recovery-Paradoxon als bewusstes Rahmenwerk an: das Prinzip, dass ein gut bewältigter Fehler einen Kunden zufriedener machen kann, als wenn das Problem nie aufgetreten wäre. Der Ansatz strukturierte sich in vier Arbeitsbereiche. Gemeinsame Diagnose mittels 5-Why-Methode: Gradion setzte einen erfahrenen Shopware-Spezialisten ein, der direkt mit dem Team des Kunden zusammenarbeitete. Gemeinsam analysierten die beiden Teams das Problem systematisch mittels der 5-Why-Methode zur Ursachenforschung. Die Diagnose bestätigte die Vermutung beider Parteien, dass das Kernproblem ein Kommunikationsbruch im Übergabeprozess war und keine grundlegenden Qualitätsmängel vorlagen. Vereinheitlichte Codierungsstandards: Unter Einbeziehung des Kunden entwickelte Gradion eine detaillierte Checkliste für Codierungsstandards, die die Erwartungen des Unternehmens explizit widerspiegelte. Diese wurde zum Referenzstandard des Projekts, leitete einen umfassenden Code-Refactoring-Plan mit definierten Meilensteinen und wandelte die angesammelten technischen Schulden in eine dokumentierte und getestete Basis um. Prozessneugestaltung und Wissensaustausch: Gradion überarbeitete seine internen Überprüfungsprozesse für das Engagement, führte strenge Code-Review-Prüfpunkte ein und ernannte den erfahrenen Spezialisten zum finalen Qualitäts-Gatekeeper vor jeder Auslieferung. Über die Prozesse hinaus führte der Spezialist Shopware-Schulungen und Wissensaustausch-Sitzungen für das Team des Kunden durch, die als Zeichen der Verantwortung und als Investition in gemeinsame Fähigkeiten kostenlos angeboten wurden. Strukturierter Dialog und gemeinsame Priorisierung: Statt isolierter Lieferungen etablierten Gradion und der Kunde einen Rhythmus regelmäßiger, offener Gespräche. Refactoring-Arbeiten wurden zusammen mit der Entwicklung neuer Funktionen in einem transparenten Backlog priorisiert, das beide Teams gemeinsam überprüften, um sicherzustellen, dass jede Entscheidung auf dem Geschäftsnutzen und nicht nur auf technischen Präferenzen basierte.