Jede Phase im Lebenszyklus eines Fahrzeugs nutzt unterschiedliche Software. Entwicklungsteams verwenden Simulationsplattformen. Testteams nutzen Datenlogger und Validierungssysteme. Fertigungsteams führen End-of-Line-Tests auf ihren eigenen Systemen durch. Kundendienstteams verwenden wiederum andere Diagnosewerkzeuge. Jedes Team wählt die für seinen spezifischen Bereich geeigneten Lösungen aus.
Das Problem liegt darin, was zwischen und über die einzelnen Phasen hinweg geschieht, nicht innerhalb dieser Phasen. Stellen Sie sich den traditionellen Lebenszyklus eines Fahrzeugs als Staffellauf vor. Die Entwicklung übergibt an die Testphase. Die Testphase übergibt an die Produktion. Die Produktion übergibt an den Service. Bei jedem Wechsel muss das Wissen neu aufbereitet oder neu aufgebaut werden. Oft ist es sogar noch schlimmer: Die Tools in den einzelnen Phasen tauschen keinerlei Wissen oder Erkenntnisse untereinander aus. Daraus ergeben sich drei Kostenfaktoren, die sich mit jedem Übergang verschlimmern:
- Der Aufwand für die Systemwartung vervielfacht sich, da jedes zusätzliche Tool in der Kette ein weiteres System darstellt, für das Lizenzen erworben, das integriert, mit Patches versehen und gewartet werden muss.
- Der Schulungsaufwand steigt, da neue Mitarbeiter und funktionsübergreifende Teams für jede Phase, an der sie beteiligt sind, ein anderes Tool erlernen müssen.
- Vor allem bricht die Kontinuität des Wissens zusammen. Der Kontext, den ein Entwickler bei der Erstellung einer Funktion vor Augen hatte, lässt sich nicht nahtlos an die Person weitergeben, die sechs Monate später vor Ort die Fehlerbehebung durchführt.
Nichts davon ist das Versagen eines einzelnen Teams. Es handelt sich um strukturelle Kosten, die dadurch entstehen, dass Design, Entwicklung, Test, Produktion und Support als fünf separate Arbeitsabläufe statt als einen kontinuierlichen Prozess behandelt werden. Für OEMs äußern sich diese Kosten in zusätzlichem Zeitaufwand in jeder Phase: langsamere Entwicklung, langsamere Tests, langsamere Fehleruntersuchungen – dazu kommen Doppelarbeit und der Verlust von institutionellem Wissen beim Wechsel von einem Team zum nächsten.
Was die Wiedervereinigung zuvor unrealistisch machte
Über weite Teile der Softwaregeschichte hinweg war eine Vereinheitlichung dieser Werkzeuge nicht realistisch. Software wird zweckgebunden entwickelt. Ein Testwerkzeug dient dazu, zu überprüfen, ob sich ein System unter definierten Bedingungen wie erwartet verhält, und ein Diagnosewerkzeug soll die Ursache eines Fehlers lokalisieren, sobald etwas schiefgelaufen ist. Das eine Werkzeug so anzupassen, dass es die Aufgabe des anderen übernimmt, bedeutet, wesentliche Teile des Codes neu zu schreiben. Wenn ein Entwickler möchte, dass eine Schaltfläche verschoben oder ein Arbeitsablauf geändert wird, ist das ein Entwicklungszyklus.
AI beginnt, diese Gleichung zu verändern, da agentenbasierte Lösungen AI in all diesen Phasen zunehmend auf derselben Grundlage beruhen. Das große Sprachmodell (LLM), das einem Testtool zugrunde liegt, ist im Grunde dasselbe Modell, das auch einem Felddiagnosetool zugrunde liegt. Ganz gleich, ob es darum geht, einen Validierungstestfall vor der Markteinführung zu analysieren oder ein Kundenproblem nach dem Verkauf zu beheben – das AI , das die Schlussfolgerungen zieht, ist dasselbe. Nur der umgebende Kontext ändert sich.
Anstatt für jeden Bereich ein eigenes System aufzubauen, können Unternehmen dieselbe zugrunde liegende Intelligenz auf Entwicklung, Test und Betrieb ausweiten und an den Kontext jedes Teams anpassen, ohne jedes Mal bei Null anfangen zu müssen. Das ist die Idee hinter dem Sonatus Fastlane™ Platform, einer „Closed-Loop“- AI -Plattform, die Fahrzeugdaten und -wissen von einer Phase des Lebenszyklus zur nächsten weiterleitet. Das ist ein grundlegend anderer Ansatz als bisher in der Branche üblich, auch wenn die meisten Unternehmen noch in den Anfängen stehen, diesen umzusetzen.
Die schwierigere Arbeit liegt in der Organisation
Erste Anzeichen dafür sind branchenweit zu erkennen, selbst dort, wo Unternehmen derzeit vielleicht nur eine oder zwei dieser Maßnahmen umsetzen:
- Fehler im Routing-Bereich direkter in die OTA-Update-Zyklen einbinden, mithilfe von Fahrzeug- AI n wie Sonatus Fastlane™ Edge dazu beitragen, den Kreislauf vom Problem bis zur Bereitstellung der Korrektur zu schließen.
- Die Erkenntnisse aus dem Service Desk fließen zurück in die Konstruktions- und Testkriterien für das nächste Modelljahr ein – und genau hier kann ein Tool wie Fastlane™ Insight Diagnoseergebnisse in umsetzbare Erkenntnisse für die Entwicklungsteams umwandeln kann
- Nutzung von Anomaliedaten aus der Fertigung zum Vergleich der Teilequalität verschiedener Lieferanten.
- Untersuchung, ob Validierungsdaten aus der Entwicklungsphase mit dem Fahrzeug übertragen werden können, um die Diagnose bei der Inbetriebnahme zu beschleunigen, unterstützt durch Fahrzeugkontextdaten aus dem „ AI “ von Sonatus Fastlane™ Collector.
All dies ist noch nirgendwo vollständig gelöst, aber es zeigt, in welche Richtung sich die Branche entwickeln wird, sobald sich die Tools nicht mehr bei jedem Übergang zurücksetzen.
Es geht hier auch nicht einfach nur darum, die Software auszutauschen. Die Vereinheitlichung der Tools über alle Lebenszyklusphasen hinweg bedeutet in der Regel, dass auch die Zuständigkeiten, das Budget und die Prozesse zwischen Teams vereinheitlicht werden müssen, die jahrelang unabhängig voneinander gearbeitet haben. Dies stellt sowohl eine Herausforderung im Bereich des Veränderungsmanagements als auch eine technische Herausforderung dar. Unternehmen, die dies lediglich als eine Entscheidung bezüglich der Tools betrachten, werden wahrscheinlich feststellen, dass der größere Aufwand auf organisatorischer Ebene liegt.
Entwicklung der Vereinigungsstrategie
Meiner Erfahrung nach folgt diese Art der organisatorischen Transformation in der Regel einigen wenigen Grundprinzipien:
- Machen Sie die Vereinheitlichung zu einer unternehmensweiten Strategie. Die Vereinheitlichung von Daten, Wissen und AI muss ein Auftrag der Unternehmensleitung sein und darf kein Projekt bleiben, das von einem einzelnen Team getragen wird.
- Bestimmen Sie in jeder Phase des Prozesses „Champions“. Das Projekt benötigt Fürsprecher, die in den Bereichen Entwicklung, Test, Fertigung und Service vertreten sind.
- Ermitteln Sie, was zum gemeinsamen Kontext gehört. Nicht jede Information, jedes Wissen oder jedes Artefakt muss zwischen den Phasen weitergegeben werden, aber die richtigen Signale schon.
- Führen Sie zunächst „ AI “-Lösungen für einen oder zwei Anwendungsfälle ein. Dabei sollte der Schwerpunkt auf solchen Fällen liegen, die den wechselseitigen Wissensfluss über den gesamten Lebenszyklus hinweg gezielt nutzen, anstatt eine vollständige Einführung auf einmal vorzunehmen.
- Betrachten Sie frühe Umsetzungen als Ausgangspunkt. Lernen Sie daraus, verfeinern Sie sie und bauen Sie darauf auf.
Warum das nicht warten kann
Der Druck, sich mit diesen Tools auseinanderzusetzen, nimmt zu. Da Fahrzeuge zunehmend softwaregesteuert werden und sich das Tempo der Iterationen beschleunigt, steigen die Kosten für isoliert betriebene Tools. Jedes zusätzliche, phasenspezifische Tool ist ein weiterer Punkt, an dem institutionelles Wissen eingeschlossen wird, ein weiterer Integrationspunkt, der gewartet werden muss, und eine weitere Verzögerung zwischen dem Zeitpunkt, zu dem ein Problem entdeckt wird, und dem Zeitpunkt, zu dem eine Lösung implementiert wird.
Diese Lücke lässt sich schließen, indem in jeder Phase dieselben Tools – oder zumindest dieselbe zugrunde liegende Intelligenz – eingesetzt werden. Unternehmen, denen es gelingt, Design, Entwicklung, Test, Produktion und Support als ein zusammenhängendes System und nicht als fünf separate Funktionen zu betrachten, können sich strukturelle Wettbewerbsvorteile sichern:
- Probleme werden früher erkannt, da Erkenntnisse aus einer Phase schneller in die nächste gelangen.
- Reduzierung der Anzahl physischer Testfahrzeuge und doppelter Validierungsaufwände, da Daten und Kontext übernommen werden.
- Die Kluft zwischen einem realen Signal und einer implementierten Lösung verringern.
Die technischen Gründe für eine weiterhin isolierte Arbeitsweise sind weitgehend weggefallen. Was bleibt, ist eine Entscheidung der Unternehmensführung: Entweder wird jede Phase des Fahrzeuglebenszyklus weiter optimiert, oder man beginnt, den Lebenszyklus als ein zusammenhängendes System zu betrachten, das auf einer einheitlichen Toolchain basiert. In einer Branche, in der die Zeit bis zur Serienreife (Time-to-SOP) und die Geschwindigkeit der Problemlösung zu den entscheidenden Wettbewerbsfaktoren werden, wird diese Entscheidung nicht mehr lange optional bleiben. Die Unternehmen, die diesen Schritt frühzeitig gehen, werden das Tempo vorgeben, dem alle anderen folgen müssen.
Möchten Sie erfahren, wie ein vernetzter Lebenszyklus in der Praxis aussieht? Entdecken Sie die Sonatus Fastlane Platform und erfahren Sie, wie Erstausrüster und Zulieferer mithilfe von Closed-Loop- AI n den Weg von der Entwicklung über die Produktion bis hin zum Service beschleunigen.