Die Integrationskosten, die jeder OEM trägt

Das Netzwerk existiert. Die Verbindung nicht.

OEMs investieren massiv in KI. Die meisten von ihnen können sich nicht zuverlässig mit den Daten verbinden, die diese Investitionen zum Funktionieren bringen würden.

In der gesamten Branche fließen Budgets in Modelle zur Bedarfsprognose, in Plattformen für vorausschauende Wartung und in Werkzeuge zur Bestandsoptimierung. Die verbreitete Annahme lautet, dass die Technologie der Engpass sei. In den meisten Fällen ist sie es nicht. Der Engpass ist die Konnektivität, genauer gesagt die anhaltende strukturelle Lücke zwischen den Backend-Systemen der OEMs und den Händlernetzen, die jene operativen Daten erzeugen, die diese Initiativen benötigen.

Auf dem Winning After Sales Forum im vergangenen Monat in München kamen mehr als zwanzig OEMs zusammen, um über KI, digitale Transformation und die kommerzielle Zukunft des After-Sales zu sprechen. Trotz der Bandbreite der Themen auf der Agenda tauchte eine Herausforderung in nahezu jedem Gespräch auf: die Schwierigkeit, OEM-Systeme im großen Maßstab konsistent mit den Händlernetzen zu verbinden. Diese Übereinstimmung war kein Zufall. Sie spiegelt eine architektonische Realität wider, die die Branche zu lange aufgeschoben hat.

‍

‍

Die Lücke, die nie eine Rolle spielen sollte

Die Integration von Händlerdaten ist der Prozess, die Backend-Systeme eines OEM, typischerweise SAP, Oracle oder ein proprietäres ERP, mit den Dealer-Management-Systemen zu verbinden, die im gesamten Vertriebs- und Servicenetz betrieben werden. Ihr Zweck besteht darin, den automatisierten, standardisierten und kontinuierlichen Austausch operativer Daten zwischen beiden Seiten des Geschäfts zu ermöglichen.

Während des größten Teils der Branchengeschichte wurde dies nicht als Priorität behandelt. Die Händlernetze waren kleiner. Die Geschäftsprozesse waren weniger komplex. Organisationen koordinierten sich über E-Mails, Tabellenkalkulationen und manuelle Dateneingabe, also über Methoden, die unvollkommen, aber für die damaligen Rahmenbedingungen ausreichend waren.

Diese Rahmenbedingungen gibt es nicht mehr.

Das Händlernetz wirkt auf dem Organigramm vernetzt. Operativ funktioniert es als eine Ansammlung von Silos. Bestellungen, Servicedaten, Teiletransaktionen, Garantieansprüche und Maschinendaten überqueren diese Lücke jeden Tag, langsam, manuell und unvollständig. Wachsende Händlernetze, steigende Transaktionsvolumina, zunehmende Kundenerwartungen und die Datenanforderungen moderner KI-Initiativen haben gemeinsam offengelegt, was schon immer eine architektonische Schwachstelle war.

Das Unternehmen zahlt für jede Konnektivitätslücke, ob sich diese Kosten als entgangener Umsatz, geringere Effizienz, niedrigere Kundenzufriedenheit oder angehäufte technische Schulden zeigen.

Die Build-Entscheidung, und warum sie vernünftig erscheint

Wenn ein CIO dieses Problem zum ersten Mal untersucht, ist der Instinkt, intern selbst zu bauen, nachvollziehbar. Die erforderlichen Technologien existieren. Integrationskompetenz ist in der Organisation bereits vorhanden. Und die ersten großen Integrationen, die die zwei oder drei weit verbreiteten Dealer-Management-Systeme abdecken, erscheinen beherrschbar.

Diese frühen Integrationen sind in der Regel erfolgreich. Dieser Erfolg ist jedoch auch irreführend.

Die großen Plattformen machen nur fünf bis zwanzig Prozent eines typischen Händlerportfolios aus. Sie sind gut dokumentiert, breit unterstützt und werden von erfahrenen Anbietern professionell gepflegt. Sie zu integrieren erzeugt den plausiblen Eindruck, dass die umfassendere Integrationsaufgabe mit demselben Ansatz gelöst werden kann.

Das kann sie nicht...

Die eigentliche Komplexität liegt in den verbleibenden achtzig Prozent: den regionalen Plattformen, den Legacy-Anwendungen, den lokal angepassten Lösungen und den händlerspezifischen Implementierungen, die sich in Dokumentationsqualität, technischer Zugänglichkeit und Datenstruktur erheblich unterscheiden. Das ist der Long Tail, und genau hier geraten Integrationsprojekte ins Stocken, wachsen Budgets und lösen sich Zeitpläne auf.

Was IT-Teams in der Praxis vorfinden:

🔶 Unvollständige oder veraltete technische Dokumentation

🔶 Begrenzter oder eingeschränkter Anbieterzugang

🔶 Einzigartige und inkompatible Datenmodelle

🔶 Regionale Anpassungen ohne standardisierte Struktur

🔶 Interne organisatorische Anforderungen, die sich von Markt zu Markt unterscheiden

‍

Jedes System erfordert Analyse, Mapping, Tests, laufende Wartung, Monitoring und Support. Kleine Unterschiede summieren sich über Hunderte von Händlern hinweg. Was als strukturiertes Projekt begann, wird zu einem wachsenden Bestand individueller Entwicklungsarbeit, schwer zu besetzen, teuer zu warten und anfällig gegenüber Anbieter-Updates und geschäftlichen Veränderungen.

Neue Händler-Onboardings lösen zusätzliche Arbeit aus. Software-Upgrades brechen bestehende Verbindungen. Regionale Rollouts führen neue Systemvarianten ein. Die Kosten häufen sich weiter an, lange nachdem das ursprüngliche Projekt als abgeschlossen gilt.

Das ist kein Versagen in der IT-Umsetzung. Es ist ein architektonisches Problem, eines, das in dem Moment strukturell unlösbar wurde, als die Händlernetze über eine Handvoll Partner hinaus skaliert wurden.

‍

‍

Das mahnende Muster

Die Branche hat diese Dynamik schon zuvor erlebt.

Bei OEMs bleiben Integrationsinitiativen selten statische Projekte. Was als klar definierter Aufwand beginnt, um Systeme zu verbinden oder Datenflüsse zu standardisieren, weitet sich allmählich aus, während die Händlernetze wachsen.

Mit der Zeit führt dies zu einem kumulativen Effekt. Integrationsumgebungen werden dichter, nicht einfacher. Abhängigkeiten vervielfachen sich, Dokumentationslücken verbreitern sich, und die Pflege bestehender Verbindungen verbraucht zunehmend dieselben Ressourcen, die zum Aufbau neuer Verbindungen benötigt werden.

Die Details unterscheiden sich je nach Organisation und Branchensegment, aber das zugrunde liegende Muster ist konsistent: Integrationskomplexität verläuft nicht linear. Sie häuft sich an. Und ab einer bestimmten Größenordnung verwandelt sie sich von einer projektbezogenen Herausforderung in eine strukturelle Einschränkung der gesamten IT- und Datenarchitektur. [Quelle 1, 2, 3, 4].

‍

Drei strategische Kosten, wenn man dies falsch angeht

Die Folgen ungelöster Händlerkonnektivität reichen weit über das IT-Budget hinaus. Sie beeinflussen die Wettbewerbsposition entlang dreier Dimensionen, für die CIOs unmittelbar verantwortlich sind.

1. Operative Leistung 🟠

Wenn Händlerdaten verspätet, inkonsistent oder gar nicht eintreffen, pflanzen sich die Auswirkungen durch das gesamte Geschäft fort. Teileengpässe nehmen zu. Die Erfüllung verlangsamt sich. Die Garantieabwicklung wird ungenau. Die Servicereaktionszeiten verlängern sich und erhöhen damit direkt die Maschinenstillstandszeiten für Endkunden. Die Zuverlässigkeit der Prognosen verschlechtert sich. Jedes dieser Ergebnisse hat messbare Kosten, beim Umsatz, bei der Kundenzufriedenheit und bei der Qualität der Händlerbeziehung.

2. KI- und Datenfähigkeit 🔶

Jede bedeutende digitale Initiative, KI-gestützte Prognosen, vorausschauende Wartung, Flottenanalytik, Bestandsoptimierung, hängt von derselben Voraussetzung ab: saubere, strukturierte, kontinuierlich verfügbare Händlerdaten. Ohne zuverlässige Konnektivität arbeiten diese Initiativen mit unvollständigen Eingaben und liefern unzuverlässige Ergebnisse. Investitionen in KI-Fähigkeit ohne Investitionen in Dateninfrastruktur sind Investitionen in Potenzial, nicht in Leistung.

3. IT-Ressourcenverteilung 🟧

Jede Ingenieurstunde, die für die Pflege fragmentierter Händlerintegrationen aufgewendet wird, ist eine Stunde, die nicht für die digitalen Initiativen aufgewendet wird, die Wettbewerbsvorteile schaffen. Organisationen, die in der Integrationswartung gefangen sind, können der strategischen Entwicklung von Fähigkeiten keine Priorität einräumen. Die Opportunitätskosten sind schwer präzise zu beziffern und leicht zu unterschätzen, bis sie strukturell werden.

‍

Ein architektonisches Problem erfordert eine architektonische Antwort

Generische Integrationswerkzeuge wurden nicht für diese Umgebung gebaut. ETL-Werkzeuge stoßen dort an ihre Grenzen, wo Tausende von Partnern unterschiedliche Systeme nutzen und rohe Transaktionsdaten ohne geschäftlichen Kontext liefern. Die Logik, die nötig ist, um eine rohe Händlertransaktion in eine bedeutsame Teilebestellung oder einen Garantieanspruch zu verwandeln, muss aufgebaut, gepflegt und kontinuierlich aktualisiert werden, eine Arbeit, die sich mit jedem neuen Händler, jedem Software-Release und jeder Marktexpansion vervielfacht.

Das Vorbild für die richtige Reaktion ist bereits etabliert.

Vor Jahrzehnten bauten viele Hersteller proprietäre ERP-Systeme, weil kommerzielle Alternativen begrenzt waren. Mit wachsender Geschäftskomplexität kamen die meisten zu dem Schluss, dass die Pflege einer maßgeschneiderten ERP-Infrastruktur keine produktive Nutzung knapper technischer Ressourcen war. Sie wechselten zu spezialisierten Anbietern, nicht als Zugeständnis, sondern als strategische Neuverteilung. Die Fähigkeit war weiterhin vorhanden. Die Verpflichtung, sie zu bauen und zu pflegen, nicht mehr.

Die Händlerkonnektivität folgt demselben Verlauf. Die Systeme, Prozesse und Datenanforderungen, die sie definieren, entwickeln sich ständig weiter. Neue Anbieter treten in regionale Märkte ein. Bestehende Plattformen veröffentlichen Updates. KI-Anwendungsfälle stellen neue Anforderungen an Datenqualität, Latenz und Struktur. Wirksame Konnektivität in dieser Umgebung aufrechtzuerhalten, ist kein einmaliges Projekt. Es erfordert kontinuierliche Investitionen, allein um auf dem aktuellen Stand zu bleiben.

Die Frage für CIOs lautet nicht, ob die Organisation in der Lage ist, Integrationen zu bauen. Sie lautet, ob der Aufbau und die Pflege der Integrationsinfrastruktur die wertvollste Nutzung ihrer technischen Ressourcen ist.

Was ein Plattformansatz leistet

Eine Plattform für Händlerkonnektivität stellt eine standardisierte Integrationsschicht zwischen den OEM-Systemen und dem Händlernetz bereit, unabhängig davon, welche Management-Systeme die einzelnen Händler betreiben.

Anstatt Hunderte einzelner Punkt-zu-Punkt-Integrationen zu verwalten, pflegt der OEM eine einzige Schnittstelle. Die Plattform übernimmt Systemänderungen, Händler-Onboarding, Software-Upgrades und das kontinuierliche Mapping, das nötig ist, um Daten akkurat fließen zu lassen. Händlerdaten werden nicht einfach übertragen, sie werden interpretiert, standardisiert, validiert und mit After-Sales-Geschäftslogik angereichert, bevor sie die OEM-Systeme erreichen.

Der strukturelle Vorteil ist erheblich: Statt die Komplexität von Hunderten einzelner Händlerverbindungen zu besitzen, besitzt die Organisation eine standardisierte Schnittstelle. Integration ist nicht länger ein Engpass, sondern wird zum Wegbereiter.

Mit dieser Grundlage werden Geschäftsfähigkeiten, die zuvor durch Datenlücken blockiert waren, einsatzbereit:

‍

🔶 Automatisierte Teile-Erfüllung: Händler reichen Teileanfragen über einen standardisierten Kanal ein, der direkt mit dem OEM-ERP verbunden ist. Bestellungen werden schneller bestätigt; die Erfüllung wird automatisiert.

🔶 KI-gestützte Prognose und Bestandsoptimierung: Zuverlässige, strukturierte Transaktionsdaten ermöglichen es, Bestände dynamisch über das Netzwerk hinweg auszubalancieren, wodurch Überbestände und Engpässe gleichzeitig reduziert werden.

🔶 Vorausschauende Wartung: IoT-Plattformen, die mit den Servicedaten der Händler verbunden sind, schaffen eine kontinuierliche Schleife zwischen Maschinenzustand und Servicereaktion. Anomalien lösen proaktive Warnungen aus, bevor Kunden den Support kontaktieren.

‍

Das sind keine theoretischen Vorteile. Es sind die Geschäftsergebnisse, die Konnektivität strukturell möglich macht, und deren Fehlen sie strukturell unmöglich macht.

‍

‍

Die Entscheidung, die vor den CIOs liegt

Die Integration von Händlerdaten ist keine Ansammlung von IT-Projekten. Sie ist eine grundlegende Fähigkeit, eine, die darüber entscheidet, ob jede bedeutende digitale Initiative, die die Organisation verfolgt, auf einer verlässlichen operativen Basis aufbaut.

Die Organisationen, die im After-Sales einen dauerhaften Vorteil erlangen, werden nicht jene sein, die die meisten Integrationen gebaut haben. Es werden jene sein, die ihre technischen Ressourcen auf die Geschäftsprozesse und Kundenerlebnisse gerichtet haben, die Konnektivität ermöglicht: intelligentere Prognosen, schnellere Servicereaktion, höhere Maschinenverfügbarkeit und agilere Händlernetze.

Das Konnektivitätsproblem ist lösbar. Wie eine Organisation sich entscheidet, es zu lösen, und ob diese Entscheidung strategische Kapazität vermehrt oder verbraucht, ist die Entscheidung, die das Feld trennen wird.

Henry Greulich, Partner bei Scaia Group

‍

Bereit, von fragmentierten Verbindungen zu einem vernetzten After-Sales-Betrieb überzugehen? Buchen Sie eine kostenlose Beratung: Beratung buchen

‍

Quellen:

[1], https://www.motiveretail.com/case-study/motive-retail-reduced-time-to-dms-integration-with-jaguar-land-rover-by-90

[2], https://www.daimlertruck.com/en/newsroom/stories/we-did-it-it-carve-out-at-daimler-truck-successfully-completed

[3], https://www.infosys.com/industries/automotive/case-studies/seamless-dms-integration.html

[4], https://www.clearops.com/case-studies/agco

‍