B2B-Portale und Onlineshops zusammenführen: Eine Plattform statt 50 Einzellösungen
Wer über 50 B2B-Portale und Shops betreibt, pflegt jede Funktion, jede Preisregel und jede Sicherheitslücke 50-mal. Dieser Beitrag zeigt, wie sich B2B-Portale und Onlineshops auf einer gemeinsamen Plattform zusammenführen lassen und worauf es bei der Planung ankommt.
Eine gemeinsame Plattform bringt klare Vorteile: Daten werden nur noch einmal gepflegt, Preise und Lieferzeiten kommen in allen Ländern aus derselben Quelle, Weiterentwicklung und Sicherheitsupdates entstehen einmal statt 50-mal, und Auswertungen über alle Länder werden erstmals möglich.
Wir zeigen, worauf es bei der Planung ankommt, am Beispiel eines international tätigen Industrieherstellers, für den wir diesen Weg vorsehen.
Das Thema kurz und kompakt
Ausgangslage: Ein international tätiger Industriehersteller (Familienunternehmen) betreibt weltweit rund 35 bis 40 B2B-Kundenportale und 15 Onlineshops auf Magento 2, meist je Land oder Region. Das sind über 50 getrennte Instanzen.
Ziel: Eine globale, mandantenfähige E-Commerce- und Serviceplattform mit einer zentralen Datenbank als Single Source of Truth. Die Kunden ziehen schrittweise um.
Geplanter Ansatz: Ein Standard-Stack auf Laravel-Basis, Betrieb in Microsoft Azure, global replizierte Datenbank mit Mandantentrennung auf Datenbankebene, ERP-Anbindung für Live-Preise und Lieferzeiten, SSO, Anbindung des bestehenden Produktkonfigurators und Weiterbetrieb der Punchout-Kataloge.
Warum viele getrennte Portale und Shops zum Problem werden
Gewachsene Strukturen entstehen meist aus guten Gründen: Ein Land braucht schnell einen Shop, ein Geschäftsbereich ein eigenes Händlerportal. Mit jeder weiteren Instanz steigt jedoch der Aufwand, und niemand kann mehr über alle Daten hinweg auswerten, was verkauft wird oder wo Preise voneinander abweichen.
Bei diesem Projekt kommt hinzu, dass Preise und Lieferzeiten im Portal live aus dem ERP kommen und viele Kunden über ihre eigenen Einkaufssysteme bestellen. Beides muss die neue Plattform von Beginn an leisten.
Von vielen Einzelinstanzen zu einer Plattform
Gegenüberstellung des heutigen Zustands und des geplanten Zielbilds. Es handelt sich um unsere Planung, nicht um ein umgesetztes Ergebnis.
| Bereich | Heute | Geplantes Zielbild |
|---|---|---|
| Datenhaltung | Portal und Shop sind getrennte Systeme, Daten werden doppelt gepflegt | Eine zentrale Datenbank (Single Source of Truth), Daten werden einmal gepflegt |
| Weiterentwicklung | Schnittstellen sind komplex, Synergien gibt es kaum, Korrekturen müssen pro Instanz eingespielt werden | Änderungen werden einmal entwickelt und stehen allen Mandanten zur Verfügung |
| Länder und Einheiten | Meist eine eigene Magento-2-Instanz je Land oder Region | Getrennte Mandanten auf einer Plattform, Trennung auf Datenbankebene (Row-Level Security) |
| Preise und Lieferzeiten | Im Portal live aus dem ERP, jeweils pro Instanz angebunden | Gemeinsame ERP-Schnittstelle mit Live-Preisen und Lieferzeiten |
| Einkauf beim Kunden | Beschaffungssysteme der Kunden (zum Beispiel Ariba) sind an einzelne Portale angebunden | Bestehende Punchout-Kataloge laufen weiter, ohne dass Kunden umstellen müssen |
| Betrieb und Sicherheit | Updates und Sicherheitskorrekturen pro Instanz | Ein Betriebskonzept in Microsoft Azure, Updates und Sicherheit zentral |
Datenhaltung
- Heute
- Portal und Shop sind getrennte Systeme, Daten werden doppelt gepflegt
- Geplantes Zielbild
- Eine zentrale Datenbank (Single Source of Truth), Daten werden einmal gepflegt
Weiterentwicklung
- Heute
- Schnittstellen sind komplex, Synergien gibt es kaum, Korrekturen müssen pro Instanz eingespielt werden
- Geplantes Zielbild
- Änderungen werden einmal entwickelt und stehen allen Mandanten zur Verfügung
Länder und Einheiten
- Heute
- Meist eine eigene Magento-2-Instanz je Land oder Region
- Geplantes Zielbild
- Getrennte Mandanten auf einer Plattform, Trennung auf Datenbankebene (Row-Level Security)
Preise und Lieferzeiten
- Heute
- Im Portal live aus dem ERP, jeweils pro Instanz angebunden
- Geplantes Zielbild
- Gemeinsame ERP-Schnittstelle mit Live-Preisen und Lieferzeiten
Einkauf beim Kunden
- Heute
- Beschaffungssysteme der Kunden (zum Beispiel Ariba) sind an einzelne Portale angebunden
- Geplantes Zielbild
- Bestehende Punchout-Kataloge laufen weiter, ohne dass Kunden umstellen müssen
Betrieb und Sicherheit
- Heute
- Updates und Sicherheitskorrekturen pro Instanz
- Geplantes Zielbild
- Ein Betriebskonzept in Microsoft Azure, Updates und Sicherheit zentral
Die Tabelle fasst unser Zielbild zusammen. Entscheidend für den Erfolg sind weniger die einzelnen Bausteine als die Reihenfolge, in der sie eingeführt werden.
So planen wir die Zusammenführung: fünf Schritte
Konsolidierungen dieser Größe scheitern selten an der Technik, sondern an zu großen Schritten. Wir planen deshalb ein Vorgehen, das jederzeit einen lauffähigen Stand liefert.
1. Bestand aufnehmen: Welche Instanzen gibt es, wie unterscheiden sie sich, welche Sonderfunktionen und Schnittstellen gibt es? Das Ergebnis ist eine Landkarte, die zeigt, was gemeinsam genutzt werden kann und was bleiben muss.
2. Gemeinsames Datenmodell festlegen: Produkte, Kunden, Preise und Rechte werden einmal fachlich definiert. Die Mandantentrennung ist auf Datenbankebene geplant (Row-Level Security) und die Datenbank global repliziert, damit sich Länder nicht gegenseitig sehen und Händler weltweit kurze Antwortzeiten haben.
3. ERP-Anbindung aufbauen: Preise und Lieferzeiten kommen live aus dem ERP. So bleibt das ERP die Quelle der Wahrheit, und die Plattform pflegt keine Preise doppelt. Dazu kommen Single Sign-on und die Anbindung des bestehenden Produktkonfigurators.
4. Punchout-Kataloge weiterbetreiben: Viele Kunden bestellen über ihre eigenen Beschaffungssysteme, zum Beispiel Ariba. Diese bestehenden Kataloge werden weiterbetrieben, damit die Umstellung beim Kunden nicht scheitert.
5. In Schritten migrieren: Die Kunden ziehen schrittweise um, zuerst ein überschaubarer Teil, dann in Wellen die weiteren. Jede Welle liefert Erkenntnisse für die nächste.
Mehr zu Aufwand und Richtwerten finden Sie unter Kosten und Preise und auf unseren Seiten zu Kundenportalen und ERP-Systemen für den Mittelstand.
Technische Eckpunkte und Team
Standard-Stack: Wir bleiben nah am Framework und setzen auf Laravel. Je weniger Sonderlösungen, desto leichter lassen sich Plattform und Updates über Jahre betreiben.
Betrieb: Microsoft Azure.
Datenbank: Global repliziert, Mandantentrennung auf Datenbankebene mit Row-Level Security.
Integrationen: ERP für Live-Preise und Lieferzeiten, Single Sign-on, bestehender Produktkonfigurator, Punchout-Kataloge.
Team: Geplant ist ein gemischtes Team aus der IT des Kunden und InnoGE.
Wie wir solche Projekte grundsätzlich aufsetzen, steht auf unserer Seite Software entwickeln lassen.
Worauf es bei der Planung ankommt: Fragen vor dem Start
Nicht alles lässt sich vorab beantworten. Folgende Punkte sollten aber vor dem ersten Entwicklungsschritt auf dem Tisch liegen:
Datenqualität: Gleiche Produkte sind in verschiedenen Instanzen oft unterschiedlich benannt oder beschrieben. Ohne Bereinigung wandert dieses Problem in die neue Plattform.
Länderspezifische Anforderungen: Steuern, Rechtstexte, Sprachen und Währungen unterscheiden sich. Dazu gehören auch Anforderungen an Datenhaltung und Zugriff über Ländergrenzen hinweg.
Performance weltweit: Händler in Asien, Amerika und Europa erwarten kurze Ladezeiten. Das beeinflusst, wo und wie Daten gehalten und repliziert werden.
Umstellung für Händler: Je weniger sich für Kunden ändert, desto schneller akzeptieren sie das neue Portal. Zugänge, Kataloge und Bestellwege sollten möglichst erhalten bleiben.
Zuständigkeiten: Wer entscheidet, wenn zwei Länder unterschiedliche Funktionen möchten? Eine klare Produktverantwortung vermeidet, dass wieder 50 Sonderlösungen entstehen.
Betreiben Sie viele Portale oder Shops?
Im Erstgespräch sortieren wir gemeinsam, ob eine Konsolidierung für Sie sinnvoll ist und in welchen Schritten sie sich umsetzen lässt.
FAQ – B2B-Portale und Shops zusammenführen
In Schritten: Bestand aufnehmen, ein gemeinsames Datenmodell mit getrennten Mandanten festlegen, ERP-Schnittstellen aufbauen, bestehende Einkaufskataloge weiterbetreiben und anschließend in Wellen migrieren. So entsteht nach jedem Schritt ein lauffähiger Stand.
Produkt-, Kunden- und Preisdaten werden an einer Stelle gepflegt und von allen Shops und Portalen genutzt. Änderungen müssen nicht mehr in jeder Instanz wiederholt werden, und Auswertungen über alle Einheiten hinweg werden möglich.
Über Mandanten. Jeder Mandant hat eigene Daten, Rechte und Einstellungen, die Trennung erfolgt auf Datenebene. Gemeinsam genutzt werden Funktionen und Betrieb.
Punchout ist eine Schnittstelle, über die Kunden direkt aus ihrem Beschaffungssystem in den Katalog des Lieferanten wechseln und den Warenkorb zurückübergeben. Bei einer Konsolidierung müssen diese Anbindungen weiterlaufen, damit Händler nichts umstellen müssen.
Geplant ist ein Standard-Stack, der nah am Framework bleibt. Das hält den Anteil individueller Sonderlösungen klein und erleichtert Wartung und Weiterentwicklung. Azure ist die Betriebsumgebung, in der die Plattform laufen soll.
Auf eine saubere Bestandsaufnahme, ein gemeinsames Datenmodell, klare Regeln für Länder und Rechte, die ERP-Anbindung und darauf, dass bestehende Bestellwege der Kunden weiterlaufen. Dazu kommen ein realistischer Zeitplan mit einem ersten lauffähigen Stand und eine feste Produktverantwortung.
