Composable Commerce im Mittelstand: Wann Shop, CMS, CRM und ERP modular statt monolithisch zusammenspielen sollten

Composable Commerce im Mittelstand ist kein Architekturtrend für Konzerne, sondern oft die nüchterne Antwort auf ein ganz praktisches Problem: Das Unternehmen will Website, Shop, Produktdaten, Kundenprozesse und ERP sauber verbinden, aber ein einzelnes System soll plötzlich alles gleichzeitig leisten.

Dann entstehen typische Reibungen. Das CMS wird zum Datenbehelf. Der Shop trägt Inhalte, die dort nicht hingehören. Das ERP bekommt Sonderlogik für den Webbetrieb. Und jede neue Anforderung kostet wieder eine individuelle Ausnahme.

Die bessere Frage lautet deshalb nicht: Brauchen wir sofort eine komplett neue Plattform? Die bessere Frage ist: Welche Bausteine sollten in unserem Setup wirklich getrennt werden und welche bewusst zusammenbleiben?

1. Was mit Composable Commerce in der Praxis gemeint ist

Composable Commerce bedeutet nicht einfach nur Headless. Gemeint ist ein Setup, in dem Unternehmen bewusst einzelne Fachbereiche über klar getrennte Komponenten abbilden, zum Beispiel:

• Shop-Backend für Katalog, Preise, Checkout und Bestellungen
• CMS für redaktionelle Inhalte, Landingpages und Kampagnenseiten
• CRM für Leads, Vertriebsdaten und Kundenkommunikation
• ERP oder Warenwirtschaft für Aufträge, Lager, Einkauf und Belege
• PIM für Produktstammdaten, Attribute und kanalabhängige Produktinformationen

Der wichtige Punkt dabei: Diese Systeme werden nicht zufällig nebeneinander betrieben, sondern über APIs, Events und definierte Datenverantwortung verbunden.

Shopify beschreibt Composable Commerce treffend als Ansatz, bei dem Unternehmen die passenden Commerce-Fähigkeiten auswählen und zu einem eigenen Tech-Stack zusammensetzen. Genau darin liegt der Nutzen für den Mittelstand. Man muss nicht alles neu bauen. Man muss nur aufhören, ein einzelnes System für alle fachlichen Aufgaben zu überdehnen.

2. Woran monolithische Setups im Unternehmensalltag oft scheitern

Viele Unternehmen starten sinnvoll mit einer Plattform. Das ist oft wirtschaftlich und organisatorisch richtig.

Kritisch wird es, wenn das operative Geschäft schneller wächst als die ursprüngliche Systemlogik.

Inhalte und Commerce geraten in Konflikt

Marketing braucht flexible Landingpages, SEO-Einstiege, Kampagnenlogik und redaktionelle Freigaben. Das Shopsystem ist aber primär für Verkauf, Katalog und Checkout gebaut. Dann entstehen Workarounds in Templates, Plugins und Sonderfeldern.

Produktdaten werden fachlich zu komplex

Sobald Varianten, technische Merkmale, Dokumente, Übersetzungen oder kanalabhängige Daten zunehmen, reicht ein reines Shop-Backend oft nicht mehr sauber aus. Genau an diesem Punkt wird häufig auch ein vorgelagertes PIM relevant. Dazu passt unser Beitrag PIM im E-Commerce: Wann Produktdaten nicht mehr ins Shopsystem gehören.

ERP und Shop ziehen an derselben Datenbasis

Wenn Preise, Verfügbarkeiten, Aufträge, Kundenlogik und Belege in mehreren Systemen parallel verändert werden, entstehen Dubletten und Konflikte. Dann ist nicht nur die Integration das Problem, sondern die fehlende Entscheidung, welches System fachlich wofür verantwortlich ist.

Neue Anforderungen werden teuer

B2B-Preislogik, Rollen, Freigaben, mehrsprachige Inhalte, neue Länder, Marktplätze oder Self-Service-Portale lassen sich in gewachsenen Monolithen oft noch umsetzen. Die Frage ist nur: zu welchem Preis in Wartung, Release-Risiko und Prozessklarheit?

3. Wann Composable Commerce für den Mittelstand wirklich sinnvoll wird

Nicht jedes Unternehmen braucht sofort ein modulares Commerce-Setup. Es gibt aber klare Warnsignale.

1. Mehrere Teams arbeiten an denselben digitalen Prozessen

Wenn Marketing, Vertrieb, Produktmanagement, E-Commerce und IT regelmäßig dieselben Daten aus unterschiedlichen Blickwinkeln brauchen, wird fachliche Trennung wichtiger.

2. Website und Shop verfolgen unterschiedliche Ziele

Eine Unternehmenswebsite soll Inhalte erklären, Vertrauen aufbauen, Leads erzeugen und bei SEO sowie GEO sichtbar sein. Ein Shop soll verkaufen. Wenn beides in einem System dauerhaft gegeneinander arbeitet, ist Entkopplung oft sauberer als immer neue Kompromisse.

3. Integrationen werden geschäftskritisch

Sobald CRM, ERP, PIM, Support-System, Marketing-Automation und Shop gemeinsam funktionieren müssen, entscheidet nicht mehr das hübscheste Backend, sondern die Qualität der Architektur.

4. Release-Geschwindigkeit leidet

Wenn jede kleine Content-Änderung einen Entwickler braucht oder jede Shop-Anpassung versehentlich SEO-Seiten berührt, ist das meist kein Redaktionsproblem, sondern ein Architekturproblem.

5. Das Unternehmen braucht mehr als einen Kanal

B2B-Portal, klassischer Shop, Website, internationale Landingpages, Händlerbereich oder Produktportal lassen sich modular oft besser organisieren als in einem einzigen gewachsenen Backend.

4. Welche Bausteine typischerweise getrennt werden sollten

Die wichtigste Architekturfrage lautet nicht, ob alles headless sein muss. Die wichtigere Frage ist: Wo bringt fachliche Trennung wirklich weniger Reibung?

Shop-Backend

Der Shop sollte Verkauf verantworten:

• Katalog und Preislogik
• Warenkorb und Checkout
• Promotions
• Kundenkonto
• Bestellungen

CMS

Das CMS sollte Inhalte verantworten:

• Leistungsseiten
• Ratgeber, Blog und SEO-Seiten
• Kampagnen- und Landingpages
• modulare Content-Bausteine
• redaktionelle Freigaben und Vorschau

Wenn genau diese Content-Fragen gerade offen sind, hilft auch unser Vergleich Headless CMS für Unternehmenswebsites: Wann Contentful, Strapi oder Sanity die bessere Wahl sind.

CRM

Das CRM sollte Vertriebs- und Beziehungsdaten verantworten:

• Leads und Anfragen
• Sales-Pipeline
• Account-Historie
• Vertriebsaufgaben
• Marketing-Segmente

ERP oder Warenwirtschaft

ERP und WaWi bleiben die operative Prozesszentrale für:

• Auftragsabwicklung
• Lager und Einkauf
• Rechnungen und Belege
• Lieferstatus
• Finanz- und Stammdatenprozesse

Für Handelsunternehmen mit stärkerem Bestands- und Fulfillment-Fokus ergänzt unser Artikel WAWI Onlineshop – mit einer Single Source of Truth diese Sicht sehr gut.

5. Was Composable Commerce besser macht und was nicht

Composable Commerce hat klare Vorteile. Aber nicht jeder Vorteil gilt automatisch für jedes Projekt.

Vorteile

Schnellere fachliche Weiterentwicklung

Ein CMS kann weiterentwickelt werden, ohne Checkout-Logik zu zerlegen. Ein CRM-Prozess kann angepasst werden, ohne dass Produktdetailseiten neu gebaut werden müssen.

Klare Datenverantwortung

Wenn feststeht, welches System Preise, Produkttexte, Leads oder Lagerbestände verantwortet, sinkt die Fehlerquote oft stärker als durch jede einzelne neue Software.

Bessere Skalierbarkeit bei Spezialanforderungen

B2B-Freigaben, internationale Inhalte, SEO-Hubs, Produktportale oder Self-Service-Bereiche lassen sich modular gezielter aufbauen.

Weniger strategische Abhängigkeit von einem einzigen System

Wer CMS, Frontend und Commerce bewusst trennt, kann einzelne Teile später austauschen, ohne jedes Mal einen Komplettumbau auszulösen.

Grenzen

Mehr Architekturdisziplin ist Pflicht

Composable Commerce verzeiht keine unklaren Zuständigkeiten. Wenn niemand festlegt, welches System führend ist, verteilt man Chaos nur auf mehrere Bausteine.

Integrationen ersetzen keine Prozesse

Eine API verbindet Daten, aber sie klärt nicht automatisch Rollen, Freigaben oder Datenqualität.

Nicht jedes Unternehmen profitiert sofort

Ein kleiner Shop mit überschaubarem Sortiment und wenigen internen Beteiligten braucht oft eher saubere Basics als eine modulare Zielarchitektur.

6. Ein pragmatischer Umsetzungsweg statt Big-Bang-Relaunch

Der größte Fehler ist meist nicht zu wenig Technik, sondern zu viel Umbau auf einmal.

Ein sinnvoller Weg sieht oft so aus:

1. Systeme und Verantwortlichkeiten sichtbar machen

Welche Daten liegen heute in Shop, CMS, CRM, ERP, Excel oder Inbox? Wo entstehen Dubletten? Wo werden Informationen mehrfach gepflegt?

2. Fachlich führende Systeme definieren

Zum Beispiel:

• Produktstammdaten im PIM
• Preise und Verkauf im Shop
• Content im CMS
• Leads im CRM
• Aufträge und Bestand im ERP

3. Die wichtigsten Datenflüsse zuerst stabilisieren

Nicht alles muss in Phase 1 integriert werden. Oft reichen zuerst wenige belastbare Flüsse, etwa Produktdaten zum Shop, Formulardaten ins CRM und Bestellstatus aus dem ERP zurück ins Frontend.

4. Frontend und Redaktion getrennt prüfen

Gerade im Mittelstand lohnt sich die Frage, ob Website und Shop dieselbe Frontend-Logik brauchen oder ob ein performantes Website-Frontend neben einem spezialisierten Shop-Backend sinnvoller ist. Für diese technische Perspektive sind auch Astro für superschnelle Websites und Headless Magento oder Shopware relevant.

5. Erst dann die Zielarchitektur erweitern

Wenn die wichtigsten Schnittstellen laufen, kann man weitere Bausteine wie Marktplätze, Self-Service, Personalisierung oder zusätzliche Länder sauber ergänzen.

7. Woran man eine gute Entscheidung erkennt

In Workshops sind diese Fragen oft hilfreicher als jede Systemliste:

Wo verlieren Teams heute konkret Zeit?

Bei Content-Pflege, Produktanlage, Freigaben, Datenabgleichen oder Release-Prozessen?

Welche Integrationen sind geschäftskritisch?

Nicht jede Schnittstelle ist gleich wichtig. Entscheidend sind die Verbindungen, die Umsatz, Service oder Datenqualität direkt beeinflussen.

Welche Änderungen müssen intern ohne Entwicklerstau möglich sein?

Wenn Marketing für jede Seite ein Ticket braucht, ist das ein Signal. Wenn Vertrieb Angebots- und Account-Daten außerhalb des CRM pflegt, ebenfalls.

Wo wäre ein Systemwechsel heute am riskantesten?

Diese Antwort zeigt oft sehr gut, welche Komponente stabil bleiben sollte und welche eher modernisiert werden kann.

Fazit

Composable Commerce im Mittelstand ist dann sinnvoll, wenn ein Unternehmen Website, Shop, CRM, ERP und Produktdaten nicht mehr als Nebenaufgaben in einem einzigen System unterbringen kann.

Der Mehrwert liegt nicht im Buzzword, sondern in klarer Verantwortung, sauberer Integration und geringerer Reibung zwischen Marketing, Vertrieb, E-Commerce und Betrieb.

Wer gerade an genau dieser Schwelle steht, sollte nicht mit einer Komplettmigration starten, sondern mit einer ehrlichen Architekturaufnahme. Dafür sind unsere Seiten Webseiten & Shops, Leistungen und natürlich unser Kontaktformular der beste nächste Schritt.

Quellen

• Shopify Enterprise: What Is Composable Commerce — Is It Right for You?
• Contentful Docs: API basics
• HubSpot Docs: API reference overview
• Odoo Docs: External JSON-2 API
• Akeneo PIM Documentation: Akeneo PIM in a nutshell