Warum E-Commerce Plattform-Denke braucht und wie die Organisation folgt

Projektlogik produziert per Definition ein Ende.
Ende heißt: Ressourcen werden abgezogen, Budgets wandern weiter, Wissen verteilt sich, Entscheidungen werden nicht mehr gepflegt.

In einem modernen Commerce-Setup ist das fatal – weil die Wertschöpfung nicht im Launch liegt, sondern in der kontinuierlichen Verbesserung:

• Performance-Optimierung, weil „schnell“ direkt Umsatz ist
• Conversion-Experimente, weil „besser“ nie fertig ist
• Search-Tuning, weil Daten, Sortiment und Nutzerverhalten ständig kippen
• Plattform-Updates, weil Security und Kompatibilität nicht verhandelt werden
• Integrationen, weil ERP/PIM/CRM nie statisch sind
• Multi-Market/Brand, weil Skalierung Governance braucht

Wer das als Projekt behandelt, bekommt zwangsläufig „Launch & Forget“. Und damit: technische Schulden, organisatorische Schulden, Ergebnis-Schulden.

Eine Plattform hat kein Enddatum.
Das ist nicht Philosophie – das ist Operating Reality.

Ob Adobe Commerce, Shopify, Search, PIM oder Middleware: Das sind Infrastrukturen, die dauerhaft betrieben, weiterentwickelt und geschützt werden müssen. Nach einem Relaunch beginnt die Arbeit: Stabilität, Skalierung, Standards, Enablement.

Und an dieser Stelle wird es unbequem. Denn dann stellt sich die Frage, die in Projekten gerne umschifft wird:

Wer ist eigentlich zuständig?

Nach einem Shopify-Launch oder Adobe Commerce-Rollout gibt es meistens ein diffuses Gefühl von Verantwortung. Marketing kümmert sich um Content. IT macht „technische Sachen“. Eine Agentur liegt auf Abruf. Und wenn etwas schiefgeht, wird es zur Verhandlungssache: Wessen Budget? Wessen Priorität? Wer entscheidet?

Besonders spannend wird es bei Search. Die Technologie ist implementiert. Aber wer pflegt Synonyme? Wer optimiert Merchandising-Regeln? Wer analysiert, warum die Conversion in dieser Kategorie so schlecht ist? Wer kümmert sich darum, dass neue Produktattribute sauber in den Index fließen?

Oft passiert: niemand. Oder alle ein bisschen. Was dasselbe ist.

Das führt zu einer merkwürdigen Situation: Man hat eine teure Commerce-Plattform, eine professionelle Search-Lösung, vielleicht sogar ein gutes Team – aber es läuft nicht rund, weil Ownership fehlt.

Wenn man Plattformen ernst nimmt, braucht man unterschiedliche Rollen. Nicht jeder macht alles. Nicht jeder ist für alles verantwortlich.

Produktteams: Die Frontlinie

Das sind die Teams, die am Customer Outcome gemessen werden. Conversion Rate. Average Order Value. Bounce Rate. Customer Lifetime Value. Sie bauen und optimieren die Storefronts – die Website, die App, die Brand-Microsite.

Ihr Job ist: schnell sein, testen, lernen, iterieren. Sie leben in kürzeren Zyklen. Eine Kampagne läuft drei Wochen. Ein A/B-Test zwei Wochen. Sie müssen reagieren können.

Produktteams sind keine Plattformbauer. Sie sollten es auch nicht sein. Wenn ein Produktteam anfängt, die Plattform umzubauen, damit ein Feature funktioniert, geht meistens etwas schief. Entweder wird die Plattform instabil. Oder das Feature ist so spezifisch gebaut, dass es niemand sonst nutzen kann.

Produktteams brauchen eine Plattform, auf der sie arbeiten können – nicht eine, die sie selbst warten müssen.

Plattformteams: Die unsichtbaren Helden

Plattformteams bauen keine Features, die Endkund:innen direkt sehen. Ihre Kund:innen sind andere Teams.

Sie kümmern sich um das, was unter der Oberfläche läuft:

• Adobe Commerce Updates einspielen, ohne dass drei Märkte offline gehen
• Performance optimieren, damit Black Friday nicht crasht
• Extensions managen – welche sind sicher, welche machen Probleme, welche fressen Performance
• Produktdatenmodelle definieren, damit alle Märkte mit denselben Attributen arbeiten können
• Search-Infrastruktur betreiben, Relevanz tunen, Merchandising-Tools bereitstellen
• Integrationen pflegen – ERP, PIM, CRM, Marketing Automation

Das sind längere Zyklen. Man investiert in Stabilität, in Skalierbarkeit, in Developer Experience. Man denkt in Quartalen, nicht in Wochen.

Und – das ist wichtig – Plattformteams müssen Nein sagen können.

Wenn ein Produktteam sagt: „Wir brauchen diese Extension bis nächste Woche für die Kampagne“, muss das Plattformteam sagen können: „Nein, die Extension ist nicht performant genug. Wir finden eine andere Lösung.“ Ohne dabei als Blocker wahrgenommen zu werden, sondern als Enabler, der die langfristige Gesundheit der Plattform schützt.

Das funktioniert nur, wenn das Plattformteam ein echtes Mandat hat. Nicht nur Verantwortung, sondern auch Entscheidungsmacht.

Enabling-Teams: Die Wissensvermittler

Nicht alles kann man zentral lösen. Manche Fähigkeiten sind Querschnittsthemen. Performance-Optimierung. SEO. Search-Tuning. Adobe Commerce-Entwicklung. Accessibility.

Enabling-Teams sind temporär. Sie kommen, helfen, schulen, dokumentieren – und gehen wieder.

Beispiel: Ein neuer Markt soll mit einem eigenen Shopify Store starten. Das lokale Team kennt E-Commerce, aber nicht die spezifische Theme-Architektur. Das Enabling-Team arbeitet vier Wochen mit ihnen: Setup, Best Practices, Schulung. Dann ist das lokale Team autonom.

Oder: Die Search-Relevanz in einer Kategorie ist miserabel. Das Enabling-Team analysiert mit dem Merchandising-Team das Nutzer:innenverhalten, optimiert Synonyme, erklärt die Ranking-Faktoren – und übergibt.

Enabling-Teams sind keine Dauerlösung. Wenn ein Enabling-Team dauerhaft bei einem Thema bleibt, ist das ein Zeichen, dass etwas strukturell nicht stimmt. Entweder fehlt Ownership. Oder die Plattform ist nicht gut genug gebaut.

Organisation ist das eine. Ownership das andere.

Wer trifft welche Entscheidungen? Wer darf was? Wer ist wofür rechenschaftspflichtig?

Das klingt banal, ist es aber nicht. In den meisten E-Commerce-Organisationen ist Ownership implizit geregelt – durch Gewohnheit, durch Persönlichkeiten, durch Politik. Und das führt zu Konflikten.

Product Ownership: Das Endkund:innen-Mandat

Ein Product Owner verantwortet ein Geschäftsergebnis. Mehr Traffic. Höhere Conversion. Besserer Customer Lifetime Value.

Dafür priorisiert er Features, trifft Entscheidungen, balanciert Wünsche mit Machbarkeit.

Aber – und das wird oft übersehen – ein Product Owner entscheidet nicht über die Plattform.

Wenn ein Product Owner sagt: „Wir installieren jetzt diese Extension, weil ich sie für meine Roadmap brauche“, ist das eine Grenzüberschreitung. Die Plattform gehört nicht einem Produktteam. Sie gehört allen.

Das führt manchmal zu Frustration. „Früher konnten wir einfach machen. Jetzt müssen wir auf das Plattformteam warten.“

Ja. Genau. Weil „einfach machen“ langfristig in Chaos endet.

Platform Ownership: Das Infrastruktur-Mandat

Ein Platform Owner verantwortet die Gesundheit der Plattform. Performance. Stabilität. Skalierbarkeit. Developer Experience. Adoption.

Das ist eine schwierige Rolle. Man muss technisch tief genug sein, um zu verstehen, warum eine Extension problematisch ist. Aber kommunikativ stark genug, um das einem ungeduldigen Produktteam zu erklären.

Ein Platform Owner muss zwischen vielen Stakeholdern vermitteln. Alle Märkte haben Wünsche. Alle Produktteams haben Deadlines. Und die Plattform muss trotzdem stabil bleiben.

Typisches Dilemma: Ein Storefront-Team will eine neue Funktion. Schnell. Der Platform Owner muss entscheiden: Bauen wir das als Quick Fix – mit dem Risiko, dass es später technische Schulden verursacht? Oder investieren wir Zeit in eine saubere, generische Lösung – mit dem Risiko, dass das Business ungeduldig wird?

Es gibt keine einfache Antwort. Aber es gibt eine falsche Antwort: die Entscheidung nicht zu treffen.

Shared Ownership: Wenn mehrere ran müssen

Manche Dinge gehören niemandem allein. Produktdaten. Search-Relevanz. Content.

Beispiel Search: Die technische Infrastruktur gehört dem Plattformteam. Die Merchandising-Entscheidungen gehören dem Category Management. Die Optimierung der Relevanz braucht beide.

Das ist Shared Ownership. Und die ist heikel.

Wenn niemand allein zuständig ist, fühlt sich oft niemand zuständig. Synonyme werden nicht gepflegt. Produktattribute sind inkonsistent. Niemand hat Zeit, weil es nicht klar in der Jobbeschreibung steht.

Shared Ownership funktioniert nur mit expliziten Regeln. Wer macht was? Wer entscheidet bei Konflikten? Wer trägt welche Kosten?

Das muss aufgeschrieben werden. Und es muss regelmäßig überprüft werden, ob es noch funktioniert.

Speed vs. Stability

E-Commerce lebt von Kampagnen. Black Friday. Sale. Produkt-Launches. Alles muss schnell gehen.

Plattformteams denken anders. „Wir deployen zwei Wochen vor Black Friday nichts Neues. Zu riskant.“

Produktteams: „Aber wir brauchen dieses Feature für die Kampagne!“

Klassischer Konflikt.

Die Lösung ist nicht, dass eine Seite gewinnt. Die Lösung ist Planung. Freeze-Perioden vor kritischen Events. Feature Flags, damit man Features testen kann, ohne die Plattform zu destabilisieren. Klare Kommunikation: Was geht wann? Was geht nicht?

Aber das setzt voraus, dass beide Seiten sich als Partner sehen, nicht als Gegner.

Autonomie vs. Standards

Multi-Market-Setups sind kompliziert. Jeder Markt hat eigene Anforderungen. Andere Payment-Methoden. Andere Versandlogik. Andere rechtliche Vorgaben.

Gleichzeitig: Wenn jeder Markt macht, was er will, entsteht Wildwuchs. Inkonsistente Daten. Performance-Probleme durch unkontrollierte Extensions. Sicherheitsrisiken.

Zu viel Kontrolle bremst. Zu wenig Kontrolle führt zu Chaos.

Die beste Lösung, die wir gesehen haben: Standards als Enabler, nicht als Blocker.

Beispiel: Ein Plattformteam definiert eine Whitelist von Extensions, die performant und sicher sind. Märkte können daraus frei wählen. Aber wenn sie etwas anderes wollen, muss es durch einen Review-Prozess. Das schützt die Plattform, ohne Märkte zu gängeln.

Oder: Ein Design System mit vorgefertigten Komponenten. Märkte können Content anpassen, Layouts gestalten – aber die Komponenten folgen globalen Standards. Autonomie innerhalb sicherer Leitplanken.

Der Fashion-Retailer mit dem Adobe Commerce-Chaos

Sieben Länder. Eine Adobe Commerce-Instanz. Jedes Land hatte eine eigene Store View – soweit, so normal.

Aber: Kein Operating Model. Manche Länder installierten eigene Extensions. Andere schrieben Custom-Code direkt in den Core. Die Produktdaten waren ein Desaster – mal fehlten Bilder, mal Beschreibungen, mal beides.

Nach jedem Major-Update: Panik. Extensions brachen. Custom-Code funktionierte nicht mehr. Manche Märkte warteten Monate auf Fixes, weil niemand wusste, wer zuständig war.

Die Lösung: Radikale Umorganisation.

Ein Platform Core Team (klein, aber mächtig: 3 Entwickler, 1 DevOps, 1 Platform Owner) übernahm die Instanz. Volle Verantwortung. Updates, Performance, Extension-Management, alles.

Jeder Markt bekam ein kleines Market Team (1-2 Frontend-Entwickler, 1 Merchandiser). Zuständig für: Theme-Anpassungen, lokaler Content, lokale Promotions. Nicht mehr.

Ein Search & Merchandising Team (2 Leute, shared) kümmerte sich kontinuierlich um Onsite Search über alle Märkte.

Das Platform Core Team setzte harte Regeln durch:

• Alle Extensions müssen approved werden. Performance-Check. Security-Audit. Keine Diskussion.
• Custom-Code nur in marktspezifischen Modulen. Core bleibt sauber.
• Produktdaten-Standards: Pflichtfelder definiert. Attribut-Konsistenz über alle Store Views.

Manche Märkte waren frustriert. „Das bremst uns!“

Das Platform Team antwortete mit Enablement, nicht mit Durchsetzung. Dokumentation. Self-Service-Portal für Standard-Anfragen. Office Hours, wo Märkte technische Fragen stellen konnten.

18 Monate später: Time-to-Market halbiert (weil Features nur einmal gebaut wurden). Updates liefen planbar. Ein achter Markt ging in sechs Wochen live statt sechs Monaten.

Der Shopify-Multi-Brand-Kampf um Search-Ownership

Drei Lifestyle-Brands. Drei Shopify Stores. Überschneidende Produktkataloge, aber unterschiedliche Positionierung.

Das Unternehmen implementierte eine einheitliche Search-Lösung. Synergien nutzen. Gemeinsames Synonym-Management. Lerneffekte teilen.

Sofort: Konflikt.

Brand A wollte nachhaltige Produkte boosten. Brand B wollte Bestseller oben. Brand C wollte neue Kollektionen priorisieren.

Wer entscheidet? Wer pflegt die Daten? Wer zahlt?

Die Lösung: Ein Search Platform Team (2 Leute) für Technik. Index. Performance. Baseline-Relevanz.

Jede Brand bekam einen Brand Merchandiser für brand-spezifische Regeln – aber innerhalb definierter Grenzen. (Merchandising darf Relevanz nicht komplett überschreiben.)

Ein Search Governance Council (Platform Team + 3 Brand Merchandiser + E-Commerce-Leitung) traf vierteljährlich Entscheidungen über übergreifende Themen.

Nicht perfekt. Aber strukturiert.

Ergebnis: Die Brands hatten verstanden, dass zentrale Standards ihre Autonomie ermöglichen, nicht einschränken.

Drei Dinge müssen stimmen:

1. Organisationsdesign
Plattformen brauchen dauerhafte Teams. Mit Budgets, die nicht an Kampagnen hängen. Mit Roadmaps, die länger als ein Quartal denken. Mit Mandat, Entscheidungen zu treffen.

Das ist kein Luxus. Das ist Grundvoraussetzung.

2. Ownership-Klarheit
Wer entscheidet über Extensions? Wer pflegt Produktdaten? Wer optimiert Search? Nicht „alle irgendwie“. Sondern konkret: Namen, Rollen, Budgets.

Das erfordert manchmal unbequeme Gespräche. Aber Unklarheit ist teurer.

3. Kultur
Plattformen funktionieren nur, wenn Teams bereit sind, Standards zu akzeptieren. Voneinander zu lernen. Autonomie als etwas zu verstehen, das innerhalb von Leitplanken stattfindet, nicht ohne sie.

Das entsteht nicht durch Ansagen. Das entsteht durch Vorbilder, durch Transparenz, durch Fehlerkultur.

1. Deine Commerce-Plattform ist kein abgeschlossenes Projekt
Sie ist ein strategisches Asset. Behandle sie so. Dauerhaftes Team. Klare Ownership. Kontinuierliche Investition.

2. Search ist kein „Set and forget“
Die beste Technologie nützt nichts ohne kontinuierliche Optimierung. Synonyme. Merchandising. Relevanz-Tuning. Datenqualität. Das braucht dedizierte Ownership.

3. Multi-Store/Multi-Market ohne Governance ist Chaos mit Zeitverzögerung
Kläre: Welche Extensions dürfen lokal installiert werden? Wer definiert Produktdaten-Standards? Wie wird Search über Märkte optimiert? Jetzt klären, nicht später reparieren.

4. Fange irgendwo an. Aber bewusst.
Du musst nicht alles auf einmal ändern. Aber du musst anfangen. Ein Bereich. Search-Ownership. Extension-Governance. Produktdaten-Management. Mit Strategie, nicht mit Zufall.

Viele Unternehmen wissen, dass sie sich ändern müssen. Aber wie?

Wir arbeiten oft als Enabling Team. Wir analysieren dein Setup (Adobe Commerce, Shopify, Search). Wir arbeiten mit deinen Teams. Wir transferieren Wissen. Und dann ziehen wir uns zurück, weil dein Team es selbst kann.

Unser Ansatz:

• Platform Health Checks
  Technische Schulden identifizieren. Performance-Bottlenecks finden. Extension-Wildwuchs aufräumen. Quick Wins definieren.
• Search Management
  Kontinuierliche Search-Optimierung etablieren. Baseline-Relevanz. Synonym-Management. Merchandising-Regeln. Und klären, wer dauerhaft verantwortlich ist.
• Multi-Store Governance Design
  Governance-Modelle entwickeln. Zentrale Standards + lokale Autonomie. Nicht gegeneinander, sondern miteinander.
• Platform Team Enablement
  Mit Ihrem Team arbeiten. Know-how transferieren (Adobe Commerce-Architektur, Performance, Search-Tuning). Dann überflüssig machen.

Sprich uns an. Wir finden gemeinsam heraus, wo ihr steht. Wo die größten Hebel liegen. Wie ihr aus der Launch-Forget-Falle rauskommt.

Damit du eine Organisation aufbaust, die Plattformen als das behandelt, was sie sind: strategische Assets, keine abgeschlossenen Projekte.

E-Commerce ist längst kein Kanal mehr. Es ist das Geschäftsmodell.

Wer alle sechs Monate einen Relaunch plant statt kontinuierlich zu optimieren, verliert. Wer Search als einmalige Implementierung sieht statt als dauerhaften Wettbewerbsvorteil, verschenkt Conversion. Wer Multi-Market ohne Governance betreibt, baut technische Schulden auf, die irgendwann nicht mehr beherrschbar sind.

Der Wechsel zur Plattform-Organisation muss nicht disruptiv sein. Er kann evolutionär passieren.

Aber er braucht eine Entscheidung. Jetzt, nicht irgendwann.

Die Unternehmen, die das verstanden haben, sind nicht die mit der modernsten Technologie. Es sind die, die ihre Technologie als Plattform behandeln. Mit dauerhaften Teams. Klarer Ownership. Und einer Kultur, die kontinuierliche Verbesserung über kurzfristige Projektabschlüsse stellt.

Die Frage ist nicht ob. Die Frage ist wann.