Händler- und B2B-Portals für einen großen Automobilzulieferer
Wenn zwei gewachsene Portale parallel betrieben werden, frisst der Betreuungsaufwand stillschweigend Monat für Monat Arbeitszeit auf – im HQ, in den Märkten, im Support. Solange beide laufen, scheint das hinnehmbar. Sichtbar wird das wahre Ausmaß meist erst, wenn man sie zusammenführt.
Worum es dem Kunden ging
Der Zulieferer wollte den Betreuungsaufwand für seine bestehenden Portallandschaft deutlich senken – sowohl im Headquarter als auch in den einzelnen Märkten. Drei Hebel standen im Fokus:
- Weniger Arbeitszeit für Portalbetreuung – HQ und Märkte verbrachten zusammen erhebliche monatliche Stunden mit der Pflege von zwei getrennten Systemen.
- Niedrigere Betriebskosten – zwei parallele Plattformen bedeuten doppelte Infrastruktur, doppelte Lizenzen, doppelte Verträge.
- Mehr Self-Service, weniger Support-Tickets – jede Routineanfrage, die ein Händler nicht selbst lösen konnte, landete bislang als Ticket beim HQ oder bei den Märkten.
Auf einen Blick
Wir haben ein zentrales B2B-Portal entwickelt, das ein bestehendes Händlerportal und ein B2B-Portal ablöst – mit Unterstützung für 10 Märkte und 24 Sprachen, zentralem Identitätsmanagement und einer Architektur, die so flexibel ist, dass auch andere Marken des Konzerns auf derselben Basis aufsetzen können.
Kunde: Großer Automobilzulieferer Branche: Automobilzulieferindustrie Geschäftsfeld: B2B Projektstart: 2023 Projektdauer: 14 Monate Team: 5 Personen bei DMG, 2 Personen kundenseitiges Kernteam
Shortfacts
Unsere Arbeitsfelder



Die Ausgangssituation
Der Zulieferer betrieb zwei getrennte Portale für Händler und B2B-Kunden, gewachsen über Jahre, mit eigenen Identitätsmanagement-Systemen, eigenen Inhalten und eigener Pflege. In zehn Märkten mussten alle Änderungen mehrfach gemacht werden – Inhalte mehrsprachig aufbereiten, Rollen anpassen, Berechtigungen verwalten, Support leisten.
Hinzu kam: Fünf verschiedene Login-Systeme waren über die Jahre entstanden. Jede Routineänderung wurde so zur Mehrfachaufgabe, jede Bereitstellung neuer Inhalte zog sich, jede Berechtigungsfrage landete als Ticket. Im Hintergrund war außerdem ein zentrales Konzern-SSO geplant – aber erst für die übernächsten zwei bis drei Jahre.
Erst verstehen, dann bauen
Bevor wir Architekturskizzen erstellten, haben wir mit allen relevanten Stakeholdern gesprochen – HQ, Märkte, Support, IT. Das war keine Formalität, sondern Voraussetzung, um den effizientesten Pfad zu finden. Aus diesen Gesprächen entstanden zwei Entscheidungen, die das Projekt geprägt haben.
Die erste war architektonisch: Statt eines klassischen Portal-Neubaus haben wir auf eine decoupled Architektur gesetzt – Backend und Frontend strikt getrennt. Das klingt nach einem rein technischen Detail, ist aber strategisch: Über dasselbe Backend lassen sich künftig auch Portale anderer Marken im Konzern bedienen, ohne jedes Mal neu zu bauen.
Die zweite Entscheidung betraf das SSO – und sie war intern die schwierigste des gesamten Projekts. Naheliegend wäre gewesen, auf das geplante Konzern-SSO zu warten oder die fünf bestehenden Logins zu migrieren. Beides hätte den Projektzeitplan zerstört: Warten hätte die Lösung um zwei bis drei Jahre verzögert, Migration der Altsysteme hätte massive Performance-Probleme verursacht. Unsere Empfehlung war ein Zwischenschritt: ein eigenes, schlankes SSO für die Portale, gebaut für eine spätere, möglichst bruchlose Übernahme durch das Konzern-SSO.
Das war eine unbequeme Empfehlung. Sie bedeutete für den Kunden, eine Übergangslösung zu finanzieren, die später wieder abgelöst werden würde. Rechts- und Datenschutzabteilung und die zentrale IT mussten überzeugt werden, denn ein eigenes SSO neben einer geplanten Konzernlösung wirft Compliance- und Strategiefragen auf. Wir haben diese Diskussionen geführt – mit klaren Argumenten, was passieren würde, wenn man entweder zwei Jahre wartet oder die Altsysteme migriert.
Heute, zwei Jahre später, ist das Konzern-SSO eingeführt. Die Migration vom Übergangs-SSO auf die zentrale Lösung dauerte vier Tage. Die Annahme, auf die wir damals den Zwischenschritt gebaut haben, hat sich gehalten.


Die Lösung
Auf Basis dieser Entscheidungen haben wir ein zentrales B2B-Portal entwickelt, das Händler- und B2B-Funktionen in einer Plattform vereint.
Das decoupled System trennt Backend und Frontend vollständig. Inhalte, Berechtigungen und Daten werden zentral verwaltet, das Frontend kann je nach Marke und Markt unterschiedlich aussehen – auf derselben technischen Basis. Das zentrale Identitätsmanagement ersetzt fünf verschiedene Login-Systeme; Rollen und Rechte lassen sich pro Markt feingranular vergeben. Eine KI-gestützte Übersetzung sorgt dafür, dass Inhalte in allen 24 Sprachen schnell und konsistent verfügbar sind, ohne dass jede Marktredaktion einzeln nacharbeiten muss. Eine optimierte Suche macht die Plattform für Nutzer beherrschbar, auch wenn das Informationsvolumen wächst.
Wichtig dabei: Bestehende Inhalte und Nutzerkonten wurden übernommen, nicht neu erfasst. Der Wechsel verlief ohne Bruch für die Anwender.
Das Ergebnis
Die Wirkung lässt sich an den drei Hebeln vom Anfang ablesen:
- Rund 50 % weniger monatliche Arbeitszeit für die Portalbetreuung in HQ und Märkten zusammen.
- 30 % niedrigere Betriebskosten durch die Konsolidierung der Infrastruktur.
- Halbierte Support-Anfragen – Nutzer erledigen heute selbst, was früher beim HQ und in den Märkten als Ticket landete.
Hinzu kommt ein Effekt, der sich schwer in Zahlen fassen lässt, aber den Kunden besonders überzeugt hat: Inhalte erreichen heute zeitnah und in konsistenter Qualität alle 24 Sprachen – statt mit Wochen Verzögerung und sichtbaren Qualitätsunterschieden zwischen den Märkten.
Und der Wechsel auf das später eingeführte Konzern-SSO – einer der größten Streitpunkte zu Projektbeginn – ließ sich in vier Tagen umsetzen.

Ihr Vorhaben besprechen
Sie betreiben mehrere Portale parallel und überlegen, sie zusammenzuführen? Sagen Sie uns in zwei Sätzen, worum es geht – wir melden uns innerhalb von zwei Werktagen mit einer ehrlichen Einschätzung, ob und wie wir helfen können.


