02.04.2026: Unternehmen A arbeitet mit SAP, Unternehmen B mit Microsoft Dynamics, Unternehmen C hat eine Eigenentwicklung. Alle drei haben eigene Artikelnummern - dasselbe Produkt heißt in jedem System anders. Preise werden unterschiedlich berechnet: Rabattgruppen hier, Nettopreislisten dort, Staffelpreise im dritten System. Lagerbestände liegen in verschiedenen Formaten vor. Und der Kunde soll im Shop eine einheitliche Erfahrung haben - einheitlicher Katalog, einheitlicher Warenkorb, einheitliche Bestellhistorie.
Kosten und Zeitrahmen: Drei ERPs zu einem zusammenzuführen ist ein Großprojekt, das je nach Komplexität Jahre dauern und erhebliche Budgets binden kann. Die meisten Unternehmen brauchen aber deutlich schneller einen funktionierenden gemeinsamen Commerce-Auftritt.
Unterschiedliche Geschäftsmodelle: Unternehmen A verkauft über Handelsvertreter, Unternehmen B über einen Online-Shop, Unternehmen C primär über EDI. Jedes ERP bildet diese Geschäftslogik ab. Eine Zusammenführung würde bedeuten, alle drei Modelle gleichzeitig umzubauen.
Laufende Verträge und Lizenzen: ERP-Verträge laufen über Jahre. Migrationen müssen zu Laufzeitenden passen. In der Zwischenzeit müssen die Systeme parallel betrieben - und trotzdem integriert werden.
Lokale Anforderungen: Jede Landesgesellschaft hat eigene steuerliche, rechtliche und logistische Anforderungen, die im jeweiligen ERP abgebildet sind. Diese lassen sich nicht ohne Weiteres in ein zentrales System überführen.
Betriebskontinuität: Die Unternehmen müssen während der gesamten Integration weiter verkaufen, liefern und fakturieren. Ein Stillstand ist keine Option - ein Parallelbetrieb mit intelligenter Abstraktionsschicht schon.
Statt die ERPs zusammenzuführen, bauen wir eine einheitliche Commerce-Schicht darüber. Der Kunde sieht einen Shop, einen Katalog, einen Warenkorb. Darunter verteilt eine Integrationsplattform Bestellungen, Preisanfragen und Bestandsabfragen an das jeweils zuständige ERP - unsichtbar für den Nutzer. Die ERPs bleiben bestehen, bedienen aber nur noch ihre jeweilige Domäne.
Kerngedanke: Man muss die ERPs nicht vereinen, um dem Kunden ein einheitliches Erlebnis zu bieten. Die Commerce-Schicht abstrahiert die Komplexität - und gibt dem Unternehmen gleichzeitig Zeit, die ERP-Landschaft langfristig zu konsolidieren, wenn das überhaupt sinnvoll ist.
Das größte Hindernis bei Multi-ERP-Integrationen sind nicht die Schnittstellen - sondern die Daten. Dasselbe Produkt heißt in jedem System anders, hat andere Attribute und andere Preise. Bevor man integriert, muss man harmonisieren.
Artikelstamm-Mapping: Produkt „SK-4820" in SAP ist dasselbe wie „DYN-MK-482" in Dynamics und „art_482_legacy" in der Eigenentwicklung. Dieses Mapping muss für jeden einzelnen Artikel hergestellt werden - bei Katalogen mit Hunderttausenden Artikeln eine erhebliche Aufgabe.
Attribut-Harmonisierung: SAP speichert das Gewicht in Kilogramm, Dynamics in Pfund, die Eigenentwicklung hat gar kein Gewichtsfeld. Maßeinheiten, Datentypen, Wertebereiche -alles muss auf ein gemeinsames Schema normalisiert werden.
Preislogik-Abstimmung: System A rechnet mit Bruttopreisen minus Rabatt, System B mit Nettopreisen plus Aufschlag, System C hat kundenindividuelle Festpreise. Die Commerce-Schicht muss alle drei Modelle verstehen und dem Kunden den richtigen Preis anzeigen -unabhängig davon, welches ERP dahinter rechnet.
Bestandsaggregation: Verfügbarkeiten aus drei Lagersystemen zusammenführen, ohne doppelt zu zählen. Reservierungen systemübergreifend sichtbar machen. Lieferzeiten je nach Ursprungslager korrekt berechnen.
Historische Daten: Bestellhistorien, Rechnungen, Retouren - alles liegt in verschiedenen Systemen. Dem Kunden eine einheitliche Übersicht zu bieten erfordert eine konsolidierte Datenansicht, die aus allen Quellen zusammengeführt wird.
Wir etablieren ein PIM (Produktinformations-Management) als führendes System für den Commerce-Layer. Alle drei Artikelstämme werden dorthin synchronisiert, gemappt und auf ein gemeinsames Datenmodell normalisiert. Das PIM wird zur „Single Source of Truth" für den Shop - die ERPs bleiben weiterhin führend für ihre jeweilige Domäne (Buchhaltung, Logistik, Einkauf).
Bei Hunderttausenden Artikeln ist manuelles Mapping nicht realistisch. KI-Modelle können Produktübereinstimmungen automatisch erkennen - anhand von Beschreibungen, technischen Attributen, Herstellerangaben und Bildern. Das Team validiert und korrigiert die Vorschläge. Ergebnis: Was manuell Monate dauern würde, reduziert sich auf Wochen. Gleichzeitig werden Dubletten erkannt und die Datenqualität insgesamt verbessert.
Die Commerce-Schicht muss nicht alle Preismodelle vereinheitlichen - sie muss wissen, welches ERP für welchen Kunden den richtigen Preis liefert. Ein Routing-Mechanismus ordnet jeden Kunden dem zuständigen ERP zu und leitet Preisanfragen entsprechend weiter. Der Kunde merkt davon nichts - er sieht seinen Preis, egal ob er aus SAP, Dynamics oder der Eigenentwicklung kommt.
Einheitliche API für den Commerce-Layer: Der Shop kennt nur eine Schnittstelle - für Produkte, Preise, Bestände, Bestellungen. Die Integrationsplattform übersetzt diese Anfragen in das jeweilige ERP-Format und leitet sie an das zuständige System weiter.
Asynchrone Verarbeitung: Bestellungen werden nicht synchron an das ERP geschickt (was bei Ausfall den Shop blockieren würde), sondern über eine Warteschlange entkoppelt verarbeitet. Der Kunde bekommt sofort eine Bestellbestätigung - die ERP-Buchung erfolgt im Hintergrund.
Fehlertoleranz und Wiederholung: Wenn eine ERP-Anbindung kurzzeitig nicht erreichbar ist, werden Nachrichten zwischengespeichert und automatisch wiederholt. Jede Nachricht ist so gestaltet, dass sie sicher mehrfach verarbeitet werden kann, ohne Duplikate zu erzeugen.
Transformationsschicht: Datenformate, Zeichensätze, Datumsformate, Währungen - alles wird in der Integrationsplattform übersetzt. Das ERP liefert CSV? Die Plattform transformiert. Das andere ERP braucht EDIFACT? Die Plattform übersetzt. Kein System muss sich an das Format eines anderen anpassen.
Schrittweise Anbindung: Nicht alle drei ERPs müssen gleichzeitig integriert werden. Wir beginnen mit dem ERP, das den größten Kundenstamm bedient, und binden die weiteren Systeme Schritt für Schritt an. Jeder Schritt liefert sofort Mehrwert.
Ein Kunde legt Produkte aus zwei verschiedenen Sortimenten in den Warenkorb - eines wird von SAP bedient, das andere von Dynamics. Die Commerce-Schicht erkennt das und splittet die Bestellung automatisch: Zwei ERP-Aufträge werden erzeugt, an die jeweiligen Systeme geroutet und unabhängig verarbeitet. Der Kunde sieht eine Bestellung, eine Bestellnummer, eine Bestätigung.
Wenn eine Bestellung hängt, muss sofort klar sein: In welchem System und warum? Wir implementieren verteiltes Tracing über alle beteiligten Systeme. Jede Bestellung bekommt eine eindeutige Tracking-ID, die über Commerce-Schicht, Integrationsplattform und ERP mitläuft. Im Monitoring-Dashboard ist der gesamte Lebenszyklus sichtbar - von der Bestellung im Shop bis zur Buchung im ERP und der Versandbestätigung aus dem Lager.
Nicht jede Bestellung passt in den Standardprozess. Ein Artikel ist in beiden ERPs gelistet - welches soll bedienen? Ein Preis weicht zwischen den Systemen ab. Ein Lagerbestand ist negativ. Für solche Fälle definieren wir klare Eskalationspfade: Automatische Regeln lösen die einfachen Konflikte, komplexe Fälle werden an ein zuständiges Team geroutet - mit allen relevanten Informationen, damit die Entscheidung schnell fallen kann.
Phase 1 - Koexistenz: Alle ERPs bleiben wie sie sind. Die Commerce-Schicht und Integrationsplattform werden aufgebaut. Der Kunde bekommt einen einheitlichen Shop, die ERPs arbeiten im Hintergrund weiter wie bisher. Je nach Komplexität der Landschaft kann diese Phase wenige Monate oder auch deutlich länger dauern.
Phase 2 - Optimierung: Datenqualität verbessern, Prozesse angleichen, überflüssige Sonderfälle eliminieren. KI-gestützte Datenanalyse zeigt, welche Geschäftsregeln über alle ERPs identisch sind und wo echte Unterschiede bestehen. Diese Phase läuft oft parallel zum laufenden Betrieb und kann sich über Monate erstrecken.
Phase 3 - Selektive Konsolidierung: Wo es sinnvoll ist, werden ERPs zusammengeführt - aber nicht um jeden Preis. Manchmal ist die langfristige Lösung nicht ein ERP, sondern zwei gut integrierte. Die Entscheidung fällt auf Basis realer Daten und Erfahrungen aus Phase 1 und 2 - nicht auf Basis eines PowerPoint-Zielbilds.
Durchgehend: Neue Funktionen im neuen System: Jede neue Anforderung wird direkt in der Commerce-Schicht umgesetzt - nicht in den Legacy-ERPs. So wird die neue Architektur mit jedem Feature wertvoller und die Abhängigkeit von den Altsystemen nimmt kontinuierlich ab.
Durch die Abstraktionsschicht ist jedes einzelne ERP unabhängig austauschbar. Wenn in drei Jahren der Dynamics-Vertrag ausläuft, kann das System durch SAP, eine andere Lösung oder eine Eigenentwicklung ersetzt werden - ohne dass der Commerce-Layer oder die anderen Integrationen davon betroffen sind. Die Integrationsplattform ist die Versicherung gegen zukünftige Vendor-Lock-ins.
Eine saubere Integrationsarchitektur ist nicht nur Schadensbegrenzung - sie eröffnet neue Möglichkeiten. Cross-Selling über Sortimentsgrenzen hinweg: Ein Kunde von Unternehmen A sieht auch relevante Produkte von Unternehmen B. Gebündelte Angebote aus verschiedenen Produktwelten. Konsolidierte Analytik über alle Vertriebskanäle. Das sind Dinge, die vor der Integration schlicht nicht möglich waren.
Wichtig: Die Dauer jeder Phase hängt stark von der individuellen Situation ab - Anzahl der ERPs, Kataloggröße, Teamkapazität, organisatorische Komplexität. Diesen Fahrplan passen wir gemeinsam an Ihre Realität an.
Ergebnis: Statt eines riskanten Multi-Millionen-ERP-Konsolidierungsprojekts ein pragmatischer Ansatz, der in Monaten statt Jahren Ergebnisse liefert. Der Kunde sieht einen Shop, die Organisation gewinnt Zeit für fundierte Konsolidierungsentscheidungen - und die Architektur ist vorbereitet, egal welchen Weg das Unternehmen langfristig einschlägt.