Software-definierte Fahrzeuge zwingen die Automobilhersteller dazu, die Art und Weise, wie Produkte entwickelt und betrieben werden, zu überdenken. Der regulatorische Druck steigt, Architekturen verschieben sich, und Software definiert nun einen wachsenden Anteil des Fahrzeugwerts. Gleichzeitig wird von den Entwicklungsabteilungen erwartet, dass sie schneller arbeiten, die Qualität verbessern und sich auf KI im großen Maßstab vorbereiten.
Die entscheidende Frage ist nicht mehr, ob OEMs Software einführen, sondern ob sie die damit einhergehende Komplexität beherrschen können.
Jahrzehntelang war die Automobilentwicklung für eine relativ stabile Realität optimiert. Die Geräte erfüllten klar definierte Funktionen. Die Zuständigkeiten waren klar getrennt. Die Systeme wurden schrittweise weiterentwickelt, und die Organisationen waren entsprechend strukturiert.
Diese Realität existiert nicht mehr.
Heute unterstützt ein einzelnes Steuergerät mehrere, miteinander verbundene Funktionen über verschiedene Bereiche, Fahrzeuglinien und Lebenszyklusphasen hinweg. Elektrische Systeme, Elektronik und Software sind eng miteinander verbunden. Funktionen hängen über Varianten und Generationen hinweg voneinander ab, was zu einer höheren technischen und systemischen Komplexität führt.
Fehler sind selten isoliert. Die Lösung von Problemen erfordert die Koordination zwischen verschiedenen Disziplinen, Organisationen und Zulieferern. Die Kommunikationswege vervielfachen sich, die Verantwortlichkeiten verschwimmen und der Fortschritt verlangsamt sich, weil das Organisationsmodell für eine andere Welt konzipiert wurde.
Was anfangs als Koordinationsaufwand erscheint, verwandelt sich im Stillen in verzögerte SOPs, konservative Architekturentscheidungen und verlorene Optionen für digitale Einnahmen.
Dieses Muster zeigt sich deutlich im Engineering Intelligence Index 2025 von SPREAD, einer Studie, die auf Interviews mit leitenden Ingenieuren in der verarbeitenden Industrie in Europa und den Vereinigten Staaten basiert:
75 % verbringen mindestens ein Drittel ihrer Zeit mit administrativen Aufgaben
67 % verlieren viel Zeit mit der Lösung von Problemen
64 % kämpfen täglich mit der Produktkomplexität
Mehr als die Hälfte berichtet von Problemen bei der Zusammenarbeit
Dabei handelt es sich nicht um isolierte Ineffizienzen, sondern um Symptome für die derzeitige Arbeitsweise von Ingenieurbüros.
Die meisten OEMs haben stark in leistungsstarke Toolchains investiert: PLM, ALM, ERP, CAD, Simulation und domänenspezifische Systeme. Einzeln betrachtet, erfüllen diese Tools ihre Aufgabe. Das Problem ist, dass sie für eine andere technische Realität entwickelt wurden.
Traditionelle Plattformen gehen von strukturierten Übergaben, stabilen Architekturen und klaren Lebenszyklusphasen aus. Vertikale Tools sind in den Bereichen Domänen, Anforderungen, Design und Tests hervorragend, aber ihnen fehlt der Kontext darüber hinaus.
Bei softwaredefinierten Fahrzeugen liegt die wahre Reibung nicht mehr innerhalb der Domänen, sondern zwischen ihnen.
Trotz jahrzehntelanger PLM-Investitionen verlassen sich 71 % der Ingenieure immer noch auf Excel und 64 % auf PowerPoint für ihre zentralen Arbeitsabläufe. Diese "Schattentools" sind zum Bindegewebe zwischen Systemen, Teams und Lebenszyklusphasen geworden. Dies zeigt eine einfache Wahrheit: Der Engpass ist nicht mehr die fehlende Funktionalität. Es sind fehlende Kohärenz und Kontext.
Daten sind zwar vorhanden, aber sie sind fragmentiert. Die Verantwortung ist auf die Bereiche Technik, IT, Produktion und Aftermarket verteilt. Die Rückverfolgbarkeit über die verschiedenen Bereiche hinweg ist fragil. Infolgedessen finden kritische Produktentscheidungen zunehmend außerhalb des Systems der Aufzeichnungen statt.
KI wird oft als die Antwort auf die steigende Komplexität dargestellt. OEMs testen Codegenerierungs-, Testautomatisierungs- und Dokumentationstools, und das Potenzial ist real, aber KI wird durch dieselbe Fragmentierung eingeschränkt, die Ingenieure ausbremst. Der limitierende Faktor sind nicht die Algorithmen, sondern der Mangel an verknüpften, kontextualisierten Produktdaten. Die technischen Daten sind über verschiedene Systeme, Formate und Abstraktionen verstreut und haben oft nichts mit der eigentlichen Produktarchitektur zu tun.
Ohne Kontext auf Produktebene kann die KI die wichtigsten Fragen nicht zuverlässig beantworten:
Was wird durch diese Änderung verändert?
Wo wird diese Funktion oder dieses Signal noch verwendet?
Welche Fahrzeuge und Kunden sind betroffen?
Wie können wir diese Änderung über alle Varianten hinweg validieren?
Solange die Produktdaten fragmentiert bleiben, bleibt die KI auf enge, lokale Anwendungsfälle beschränkt. Die Kluft zwischen KI-Ambition und betrieblicher Realität ist eine der am meisten unterschätzten Hürden in der Automobilforschung.
Um die Kontrolle wiederzuerlangen, bedarf es keiner weiteren Punktlösung. Sie erfordert ein gemeinsames Verständnis des Produkts, das widerspiegelt, wie Funktionen, Komponenten, Software und Signale über den gesamten Lebenszyklus hinweg zusammenwirken.
Bei allen OEM-Programmen erweisen sich vier Fähigkeiten immer wieder als entscheidend:
Zuverlässige, zentralisierte Produktdaten: Ingenieure brauchen eine verlässliche Quelle der Wahrheit und müssen nicht ständig Daten abgleichen.
Flexible Informationsstrukturen: Starre Schemata versagen, wenn sich die Architekturen weiterentwickeln. Modelle müssen sich an die tatsächliche technische Komplexität anpassen.
Domänen- und lebenszyklusübergreifende Rückverfolgbarkeit: Abhängigkeiten müssen sichtbar sein, bevor sich Änderungen nachgelagert ausbreiten.
KI, die im Kontext arbeitet: KI wird nur dann wertvoll, wenn sie in der Produktarchitektur und der technischen Semantik verankert ist.
Wenn diese Fähigkeiten vorhanden sind, gehen die Teams vom Suchen und Koordinieren zum Verstehen und Entscheiden über. Abhängigkeiten werden sichtbar. Die Auswirkungen von Änderungen werden vorhersehbar. Die Ursachen werden bereichsübergreifend verfolgt und nicht erst im nachgelagerten Bereich wiederentdeckt.
Dies ist die Grundlage für eine Entwicklung ohne Überraschungen.
Was vielen OEMs heute fehlt, ist nicht ein weiteres Aufzeichnungssystem, sondern eine horizontale Engineering-Intelligence-Ebene, die das Vorhandene zu einer kohärenten Produktansicht verbindet.
Eine solche Schicht ersetzt nicht PLM, ALM oder ERP. Sie verbindet sie. Sie verankert die Arbeit der vertikalen Bereiche in einem gemeinsamen, nachvollziehbaren Verständnis des Produkts als System.
In der Praxis ermöglicht dies:
Folgenabschätzung, bevor sich Änderungen ausbreiten
Domänenübergreifende Problemlösung anstelle von lokalen Korrekturen
Verwaltung von variantenreichen Architekturen ohne Tabellenkalkulationen
KI, die das gesamte Produkt und nicht nur einzelne Dokumente berücksichtigt
Bei SPREAD bezeichnen wir dieses Konzept als Engineering Intelligence: Wir machen Komplexität beherrschbar, indem wir fragmentierte Produktdaten in ein gemeinsames Verständnis umwandeln und diese Grundlage nutzen, um sowohl die Produktivität der Ingenieure als auch die KI zu skalieren.
Es zeichnet sich eine klare Kluft ab.
Einige OEMs betrachten die Produktdatenarchitektur als strategische Infrastruktur. Sie stimmen Entwicklung, IT, Produktion und Aftermarket auf gemeinsame Modelle und Governance ab. Diese Unternehmen berichten von schnelleren Problemlösungen, kürzeren Änderungszyklen und KI-Programmen, die einen echten Mehrwert bieten.
Andere optimieren weiterhin lokale Tools und lassen das zugrunde liegende Modell unangetastet. In diesen Umgebungen nimmt die Komplexität zu, und KI bleibt ein Experiment.
Da Fahrzeuge zunehmend softwaredefiniert werden, wird diese Lücke zu einem strukturellen Leistungsvorteil.
Letztendlich geht es beim Erfolg im Zeitalter der Software-Definition nicht darum, die Komplexität zu beseitigen.
Es geht darum, die Daten und die Architektur zu schaffen, die erforderlich sind, um sie ohne Überraschungen zu meistern.