Shopify Plus Migration bei Unilever Food Solutions: Ein Beispiel davon was nach dem Launch wirklich zählt

Im B2C-Commerce kann ein Shop-Projekt manchmal noch relativ klar abgegrenzt werden: Produktdaten, Theme, Checkout, Zahlungsarten, Tracking, Launch. Natürlich steckt auch dort viel Detailarbeit drin, aber die grundlegende Struktur ist oft vergleichsweise stabil.

Im Enterprise B2B-Commerce sieht das anders aus. Hier hängt der Shop häufig an einer gewachsenen Systemlandschaft und an Vertriebsprozessen, die nicht einfach durch einen Warenkorb ersetzt werden können. Preise, Verfügbarkeit, Lieferanten, Mindestbestellwerte, Sortimente, Kundenkonten, interne Rollen, Außendienst, Wiederbestellungen und lokale Marktanforderungen greifen ineinander.

Bei Unilever Food Solutions bedeutete das unter anderem, dass Shopify Plus nicht isoliert betrachtet werden konnte. Der Shop musste mit bestehenden Systemen, Produktdaten und externen Handelspartnern zusammenspielen. Dazu kamen Integrationen zu Partnern wie Saviva und Mercanto, die für den operativen Bestellprozess relevant waren. Wenn solche Abhängigkeiten nicht sauber verstanden werden, entsteht schnell ein Shop, der technisch modern aussieht, aber im Alltag nicht gut genug funktioniert.

Das ist einer der häufigsten Denkfehler bei Migrationen: Man bewertet die Plattform, aber unterschätzt das Betriebssystem des Unternehmens dahinter.

Natürlich ist Shopify Plus ein zentraler Teil der Lösung. Die Plattform bringt viele starke Grundlagen mit, gerade wenn Unternehmen schneller werden und technische Altlasten reduzieren wollen. Trotzdem ist die wichtigste Frage in solchen Projekten nicht nur, was Shopify kann.

Wichtiger ist oft: Wo sollte welche Geschäftslogik leben?

Bei Unilever Food Solutions mussten wir bewusst entscheiden, welche Anforderungen direkt in Shopify, welche über Custom Development und welche über angebundene Systeme gelöst werden. Die Authentifizierung wurde mit Auth0 umgesetzt, weil der Zugriff auf kundenspezifische Inhalte, Preise und Funktionen kontrolliert und über den Shop hinaus gedacht werden musste. Gleichzeitig wurde kein Standard-Theme verwendet, sondern ein Custom Theme entwickelt, um die Anforderungen an UX, B2B-Logik und Performance sauber abbilden zu können.

Solche Entscheidungen wirken auf den ersten Blick technisch. In der Praxis entscheiden sie aber darüber, wie gut ein System später erweitert, gewartet und betrieben werden kann. Ein Standard-Theme kann für viele Shops völlig ausreichend sein. In einem Enterprise-B2B-Kontext kann es aber zu eng werden, wenn zentrale Anforderungen dauerhaft gegen die Struktur des Themes gebaut werden müssen.

Das gleiche gilt für Apps. Standard-Apps können viel Zeit sparen, wenn sie zum Prozess passen. Wenn sie aber zentrale B2B-Abläufe nur halb abdecken, entstehen Workarounds, die später teuer werden. Deshalb haben wir bei Unilever Food Solutions unter anderem Custom Apps für Funktionen wie Wunschlisten und B2B-Loyalty eingesetzt.

Besonders die Bestelllisten waren im B2B-Kontext wichtig, weil sie nicht nur persönliche Favoriten abbilden, sondern innerhalb einer Kundenfirma geteilt werden können. Für professionelle Küchen ist das kein nettes Zusatzfeature, sondern ein echter operativer Vorteil.

Ein entscheidender Punkt in diesem Projekt war, dass nicht nur aus der Zentrale heraus geplant wurde. Während der gesamten Entwicklung gab es eine Super User Group aus dem Vertrieb, die Designs abgesegnet, frühe Tests durchgeführt und kontinuierlich Feedback aus der Praxis eingebracht hat.

Dieses Super-User-Feedback war sehr wichtig, weil es viele Annahmen früh überprüfbar gemacht hat. Ein Design kann intern sauber wirken und trotzdem an der Realität der Nutzer vorbeigehen. Ein Feature kann technisch korrekt umgesetzt sein und trotzdem nicht zu den Arbeitsweisen im Vertrieb oder zu den Bestellgewohnheiten der Kunden passen. Die Super User Group hat geholfen, diese Lücke während der Entwicklung zu schließen, nicht erst nach dem Launch.

Vor dem Launch im Februar sind wir zusätzlich bereits im Dezember zum Jahrestreffen der Schweizer Vertriebsteams von Unilever Food Solutions gereist und haben den neuen Shop dort vorgestellt.

Das war kein klassischer Präsentationstermin, bei dem ein fertiges System gezeigt und danach nur noch ausgerollt wird. Es war ein wichtiger Moment, um Rückmeldung aus der Praxis zu bekommen. Die Vertriebler kannten die Kunden, die Bestellgewohnheiten, die Einwände, die wiederkehrenden Fragen und die Stellen, an denen ein digitaler Prozess im Alltag scheitern kann.

Nach diesem Termin haben wir mit Nolt.io eine Feature-Liste aufgebaut. Vertriebler konnten dort neue Ideen einreichen und bestehende Vorschläge upvoten. Dadurch entstand sehr schnell ein klares Bild davon, welche Funktionen für die Praxis wirklich relevant waren. Einige wichtige Features konnten dadurch noch kurz vor dem Launch ergänzt oder nachgeschärft werden.

Dieser Teil war für den Projekterfolg zentral. Nicht weil jedes gewünschte Feature sofort umgesetzt werden sollte, sondern weil die relevanten Stakeholder sichtbar eingebunden wurden. Sie konnten sehen, dass ihre Rückmeldungen ernst genommen wurden. Sie wurden nicht erst nach dem Launch mit einem neuen System konfrontiert, sondern waren Teil der finalen Ausrichtung.

Diese Rückendeckung hat später einen großen Unterschied gemacht. Ein digitaler B2B-Shop wird nicht automatisch erfolgreich, nur weil er technisch besser ist als das alte System. Er muss intern akzeptiert, erklärt und aktiv mitgetragen werden. Gerade im Vertrieb entscheidet sich oft, ob ein neuer Commerce-Kanal als Hilfe oder als Konkurrenz wahrgenommen wird.

Die späteren Ergebnisse zeigen, wie wichtig diese Akzeptanz war. Ein Umsatzplus von 41 Prozent entsteht nicht nur durch bessere Technologie. Es entsteht, wenn Plattform, Prozesse und Menschen zusammenpassen.

Vor einem Launch kann man viel testen: Datenmigration, Checkout, Performance, Integrationen, Tracking, Berechtigungen, Responsive Design und viele Edge Cases. Trotzdem ersetzt kein Test die reale Nutzung.

Nach dem Launch wurde sichtbar, was das neue Setup im Alltag besser leisten konnte. Die APIs waren stabiler. Wichtige Seiten fielen deutlich seltener aus. Featurewünsche und Bugs konnten schneller bearbeitet werden als im alten System. Die UX war besser, die Performance war besser, und es konnten Funktionen umgesetzt werden, die vorher nicht oder nur eingeschränkt möglich waren.

Das klingt zunächst nach einer technischen Verbesserung, aber für den Kunden bedeutet es etwas Konkreteres: weniger Reibung im Tagesgeschäft.

Wenn professionelle Küchen online bestellen, ist das kein gemütlicher Shopping-Prozess. Die Nutzer haben wenig Zeit, häufig wiederkehrende Bestellungen und konkrete Erwartungen an Verfügbarkeit, Geschwindigkeit und Übersichtlichkeit. Eine bessere Produktdetailseite, eine geteilte Bestellliste oder ein stabilerer Bestellprozess sind in diesem Umfeld keine kosmetischen Verbesserungen. Sie reduzieren Aufwand, vermeiden Fehler und machen den digitalen Kanal verlässlicher.

Das zeigt sich auch in den Zahlen. 15 Prozent mehr B2B-Bestellungen bedeuten nicht einfach nur mehr Traffic oder mehr Nutzung. In einem B2B-Kontext deuten sie darauf hin, dass der Kanal für Kunden zugänglicher und verlässlicher geworden ist. Ein um 4 Prozent höherer durchschnittlicher Bestellwert zeigt zusätzlich, dass der Shop nicht nur häufiger genutzt wurde, sondern auch besser darin war, relevante Bestellungen abzubilden.

Genau hier zeigt sich, warum Post-Launch-Optimierung nicht einfach Bugfixing ist. Nach dem Launch beginnt die Phase, in der ein Commerce-System an echten Nutzern, echten Prozessen und echten Anforderungen weiter geschärft wird.

In vielen Projekten wird Stakeholder-Management als organisatorisches Thema behandelt. Es steht dann neben Architektur, Entwicklung, UX und Integrationen. In Enterprise-Commerce-Projekten ist diese Trennung oft künstlich.

Wenn relevante Stakeholder zu spät eingebunden werden, entstehen technische Probleme. Anforderungen werden spät sichtbar. Schnittstellen werden falsch priorisiert. Features werden für die falschen Nutzer optimiert. Die zentrale Roadmap sieht sauber aus, aber lokale Teams erkennen ihre Realität darin nicht wieder.

Bei Unilever Food Solutions war eine der wichtigsten Lehren, die relevanten Stakeholder noch früher zu identifizieren und stärker einzubeziehen. Nicht nur die zentrale Projektgruppe, sondern auch die Menschen, die nah an Kunden, Vertrieb und operativen Prozessen arbeiten.

Die Super User Group war dafür ein wichtiger Mechanismus. Sie hat Feedback nicht auf einen großen Abnahmetermin am Ende reduziert, sondern während der Entwicklung immer wieder nutzbar gemacht. Dadurch konnten Designs, Abläufe und Features früh mit Menschen gespiegelt werden, die den späteren Alltag des Systems deutlich besser einschätzen konnten als ein rein zentrales Projektteam.

Das ist besonders wichtig, wenn ein Projekt mehrere Ebenen berührt: globale Markenstruktur, lokale Märkte, externe Handelspartner, interne IT, E-Commerce, Vertrieb und Endkunden. In solchen Umfeldern reicht es nicht, Anforderungen einmal aufzunehmen und dann umzusetzen. Man muss herausfinden, wer wirklich beurteilen kann, ob eine Lösung im Alltag funktioniert.

Die technische Architektur kann noch so sauber sein. Wenn die falschen Menschen zu spät sprechen, wird das Projekt trotzdem unnötig riskant.

Ein häufiger Fehler in Shopify-Projekten ist, Custom Development entweder grundsätzlich zu vermeiden oder zu schnell einzusetzen. Beides kann falsch sein.

Zu viel Custom Development macht Systeme schwerer wartbar, teurer und abhängiger von einzelnen Implementierungsdetails. Zu wenig Custom Development kann aber dazu führen, dass zentrale Geschäftsprozesse in Standardlösungen gepresst werden, die nicht dafür gebaut wurden.

Bei Enterprise B2B muss diese Entscheidung besonders bewusst getroffen werden. Nicht jede Besonderheit verdient eine individuelle Lösung. Aber bestimmte Prozesse sind so nah am Geschäftsmodell, dass sie sauber modelliert werden müssen.

Bei Unilever Food Solutions gehörten dazu unter anderem Authentifizierung, kundenspezifische Funktionen, geteilte Bestelllisten, Loyalty und die Einbindung externer Handelspartner. Diese Teile waren nicht nur Feature-Wünsche, sondern relevant für die Frage, ob der neue Shop den tatsächlichen B2B-Vertrieb unterstützen kann.

Die bessere Frage lautet deshalb nicht: Standard oder Custom?

Die bessere Frage lautet: Welche Teile des Systems sind differenzierend genug, dass sie präzise gebaut werden müssen, und welche Teile sollten möglichst nah am Shopify-Standard bleiben?

Aus Projekten wie diesem ergeben sich einige Punkte, die Unternehmen vor einer Migration ernster nehmen sollten.

Der erste Punkt ist Stakeholder-Mapping. Wer entscheidet offiziell, wer beeinflusst das Projekt informell, wer arbeitet später täglich mit dem System und wer kann früh erkennen, ob die Lösung an der Praxis vorbeigeht? Diese Gruppen sind nicht immer identisch.

Der zweite Punkt ist ein kontinuierlicher Feedback-Prozess. Eine Super User Group kann hier sehr wertvoll sein, weil sie Designs, Prototypen und frühe Funktionen nicht nur aus Projektsicht bewertet, sondern aus der späteren Nutzung heraus. Dadurch wird Feedback konkreter, früher und besser priorisierbar.

Der dritte Punkt ist Systemgrenzen. Unternehmen sollten früh klären, welche Logik in Shopify liegt, welche im ERP, welche im PIM, welche in Middleware oder Custom Apps und welche bewusst aus dem ersten Launch herausgehalten wird. Je später diese Grenzen geklärt werden, desto größer wird das Risiko von Workarounds.

Der vierte Punkt ist Post-Launch-Kapazität. Viele Projektpläne behandeln den Launch als Zielpunkt und unterschätzen die ersten Monate danach. Gerade in dieser Phase entstehen aber die wichtigsten Learnings. Teams brauchen dann nicht nur technischen Support, sondern Entscheidungsfähigkeit, Priorisierung und schnelle Umsetzung.

Der fünfte Punkt ist interne Kommunikation. Ein neues System muss nicht nur funktionieren, sondern verstanden und akzeptiert werden. Besonders im B2B-Commerce sollte der Vertrieb früh eingebunden werden, weil er oft die Brücke zwischen digitalem Kanal und Kundenrealität ist.

Der sechste Punkt ist die Bereitschaft, kurz vor Launch noch die richtigen Dinge zu ändern. Nicht beliebig, nicht chaotisch und nicht auf Zuruf, aber bewusst dort, wo Feedback aus der Praxis zeigt, dass ein Feature entscheidend für Akzeptanz und Nutzung ist.