Eine CMS-Modernisierung wird oft als Upgrade für Time-to-Market und Experience verkauft: bessere Content-Workflows, schnellere Ausspielung, neue Frontends, vielleicht ein Wechsel zu Headless.

Viele Programme verlieren jedoch nach dem Launch an Wirkung, weil das CMS selten der Engpass ist.

Die eigentliche Einschränkung liegt meist im Order Lifecycle und in den Systems of Record dahinter. Wenn Bestand, Preise, Kundendaten, Order Status, Returns und Refunds weiter an langsame, fragile oder batch-getriebene Backoffice-Prozesse gebunden sind, bleibt der Business-Effekt eines „neuen CMS“ begrenzt.

So entsteht das bekannte Bild: „Die Website ist schneller“ – aber „die Operations sind immer noch messy“. Und im Management bleibt das Gefühl aus, dass Conversion, Marge oder Servicequalität einen echten Schritt nach vorn gemacht haben.

Ein CMS berührt viel mehr als „Content“. Sobald Sie personalisieren, Verfügbarkeiten anzeigen, Lieferzusagen machen oder Promotions steuern, hängen Sie in Echtzeit an OMS und ERP (häufig auch PIM/WMS/CRM).

Typische Kopplungspunkte:

• Availability & ATP (available-to-promise) und Multi-Warehouse-Realität
• Pricing- & Contract-Logik (B2B-Preislisten, kundenspezifische Konditionen, Bundles)
• Customer Master Data (Accounts, Adressen, Tax IDs, Payment Terms)
• Order State (Teillieferungen, Split Orders, Stornos, Substitutionen)
• Returns & Refunds (Ausnahmen, Freigaben, Financial Posting)
• Datenlatenz (Batch Feeds vs. event-getriebene Updates)

Aus Management-Sicht ist Order Management deshalb eine strategische Commerce-Fähigkeit: Es muss Orders kanalübergreifend robust verarbeiten – nicht nur „für den Webshop“. Wenn diese Fähigkeiten nicht modernisiert werden (oder zumindest hinter stabilen APIs entkoppelt sind), modernisiert das CMS primär Darstellung – nicht Outcomes.

CMS-only Programme scheitern aus Sicht der Steuerung häufig in wiederkehrenden Mustern:

• Sie modernisieren die Front, behalten aber den gleichen Bottleneck
  Faster Pages lösen keine langsame Order-Bearbeitung, schlechte Exception-Workflows oder unzuverlässige Bestands- und Lieferzusagen.
• Sie machen Backoffice-Limits für Kunden sichtbar
  Das neue CMS „verspricht“ (Availability, Delivery Dates, Refunds), was OMS/ERP nicht konsistent halten können – das erhöht Contact Rate und manuelle Nacharbeit.
• Integration wird zum eigentlichen Projekt
  Aus „CMS Migration“ wird ungeplant ein ERP/OMS-Integration Rewrite: Datenmodelle passen nicht, APIs fehlen, Testing explodiert.
• Sie messen den falschen Erfolg
  Page Speed und Feature Parity sind nicht gleichbedeutend mit geringerem Cost-to-Serve, weniger Exceptions oder besserer Stock Accuracy.

Das Risiko steigt zusätzlich, weil große ERP-Initiativen in der Praxis oft hinter dem Business Case zurückbleiben – „wir fixen ERP später“ ist daher selten ein belastbarer Plan.

Das Ziel ist nicht „Big Bang ERP“. Ziel ist ein capability-first Fahrplan, der Versprechen an Kunden mit der tatsächlichen Ausführung synchronisiert.

Praktisches Sequencing:

• Step 1: Definieren Sie die Versprechen, die Ihre Experience Layer machen muss
  (Delivery Speed, Real-time Availability, Returns Policy, Personalisierung, B2B Contract Pricing)
• Step 2: Mappen Sie pro Versprechen die Source of Truth
  (OMS vs. ERP vs. WMS vs. PIM) – und wo Daten heute zu spät, inkonsistent oder „manuell korrigiert“ sind.
• Step 3: Stabilisieren Sie Integration, bevor Sie „Frontend skalieren“
  API Contracts, Event Streams und Reconciliation Rules, damit das CMS auf vorhersehbares Verhalten bauen kann.
• Step 4: Modernisieren Sie OMS/ERP dort, wo es direkt Value unlockt
  Order Lifecycle, Exception Handling und Data Governance – diese Bereiche treiben Cost-to-Serve und CX.

Relevant ist weniger das Tool, sondern die Fähigkeit dahinter. „Composable“ ist nicht primär eine CMS-Entscheidung – es ist eine Operating-Model-Entscheidung.

AI ist in Modernisierungsprogrammen dort am wertvollsten, wo Unsicherheit hoch ist: undokumentierte Integrationen, Tribal Knowledge, versteckte Abhängigkeiten zwischen Systemen.

Pragmatischer AI-assistierter Ansatz:

• Dependency Discovery & Mapping
  Integrationen aus Code/Config, Logs, Message Queues und API Gateways extrahieren – als lebenden Dependency Graph (wer ruft wen auf, mit welchen Payloads, in welcher Frequenz).
• Semantic Data Mapping
  Mappings zwischen ERP/OMS-Entitäten (Customers, Orders, Line Items, Returns) und Ziel-Domain-Modell vorschlagen – Validierung durch Business Owner.
• Test-Case Generation für „Order Truth“
  End-to-End Szenarien für Split Shipments, Partial Refunds, Substitutions, Backorders und Cancellations generieren – als Acceptance Criteria für CMS + OMS + ERP.
• Migration in Slices (Strangler Pattern)
  Nicht alles bewegen, sondern ein Versprechen nach dem anderen migrieren (z. B. Availability + Delivery Promise) und Stabilität beweisen, bevor erweitert wird.

Der Punkt ist nicht „AI automatisiert Transformation“. Der Punkt ist: AI kann schneller aufdecken, was Menschen übersehen – und Risiken früh genug sichtbar machen, um sie zu managen.

In der Praxis wird aus einer scheinbar klaren CMS-Migration häufig ein Integrationsprogramm: Datenmodelle, Prozessgrenzen und Echtzeit-Anforderungen treffen auf Legacy-Constraints. Wenn diese Abhängigkeiten nicht früh sichtbar sind, steigt der Aufwand in Testing, Incident-Handling und manuellen Workarounds.

Die eigentliche Frage ist nicht: „Welches CMS?“, sondern: „Welche Versprechen wollen wir operational zuverlässig halten – und welche Fähigkeiten müssen dafür im OMS/ERP sitzen?“

Wenn Sie gerade eine CMS-, Commerce- oder DXP-Modernisierung planen: Klären Sie zuerst die Versprechen (Availability, Delivery, Returns, Pricing) und prüfen Sie dann, ob OMS/ERP diese zuverlässig tragen.

Wir unterstützen typischerweise bei:

• Capability- & Promise-Mapping (Experience vs. Execution)
• OMS/ERP Dependency Mapping (inkl. AI-Assist)
• Teststrategie für Order Lifecycle & Exceptions
• Roadmap & Sequencing (Slices statt Big Bang)