„Engineering und Software sind zwei verschiedene Welten“

Herr Hofmann, aus vielen Automotive-Unternehmen hört man momentan noch von viel Reibung zwischen klassischem Engineering und der Softwareentwicklung. Sind beide Welten noch nicht auf derselben Umlaufbahn?

Zunächst einmal gibt es eigentlich keine klassische Fahrzeugentwicklung mehr, da hat sich zuletzt viel verändert. Dennoch würde ich zustimmen, dass Engineering und Software zwei verschiedene Welten sind – allein wenn man sich die Denk- und Arbeitsweisen anschaut. Wenn man beginnt, Embedded Software für Fahrzeugkomponenten zu entwickeln, dann ist das immer noch eingebettet in den PEP, den Produktentwicklungsprozess, bei dem am Schluss der Entwicklungschef seinen Haken drunter setzt. Gleichzeitig gibt es Softwareentwickler, die parallel mit „verrückten“ Design Thinking-Workshops anfangen, User-Stories bauen und irgendwann sagen, dass die Software-Features eingeordnet und in die eigene Sprintplanung integriert sind. Da treffen natürlich unterschiedliche Sprachen und Erwartungshaltungen aufeinander. Das ist übrigens in einem Startup keinen Deut besser.

Inwiefern ist das Software-Defined Vehicle (SDV) eine Chance, beide Welten näher zusammenrücken zu lassen?

Ich frage mal so: Wer von den großen OEMs hat denn mal mit einem Kunden zusammengesessen und nach dessen Wünschen und Anforderungen gefragt? Wenn ich tief in der Hardwareentwicklung stecke, habe ich vielleicht keinen Blick dafür. Anders sieht es im Software-Bereich aus, der traditionell eher vom Kunden aus denkt. Das Software-Defined Vehicle ist auf jeden Fall eine Chance, beide Entwicklungs-Denkrichtungen zusammenzubringen. Natürlich müssen auch die Funktionen in einem SDV fehlerfrei laufen, daran führt auch in Zukunft kein Weg vorbei. Trotzdem braucht es Features, die der Kunde will oder in Zukunft wollen könnte. Das bedeutet, dass die Fahrzeugarchitektur rückwärts vom Kunden gedacht werden muss: Das Feature bestimmt die Rechenleistung, die Konnektivität oder, wenn wir über autonomes Fahren sprechen, die Sensor-Landschaft. Gleichzeitig sind die Ingenieure zweifelsohne angehalten, kritische Fahrzeugfunktionen weiterhin sauber vor Kunde zu bringen.

Seit kurzem arbeiten Sie beim Elektro-Lkw-Startup Volta Trucks. Gibt es dort Prozesse oder Strukturen, die vorbildhaft für andere sein können?

Bei dem Wort „vorbildhaft“ wäre ich vorsichtig. Ich weiß, wie viel Zeit und Energie Hersteller und Zulieferer, die ich im Übrigen in einer zentralen Treiberrolle beim Software-Defined Vehicle sehe, in das Thema investieren. Aber zurück zu Volta und unserem Vorgehen: Hier bewegen wir uns im Nutzfahrzeugbereich, unser Kunde ist der Fahrer, aber auch und vor allem der Flottenbetreiber, der mit dem Fahrzeug Geld verdient. Jede Minute, die das Fahrzeug auf der Straße fährt, verdient es Geld – umgekehrt verliert es auch Geld, wenn es nicht fährt. Für uns ist es daher entscheidend, den Kunden End-to-End in das Fahrzeug zu integrieren, wodurch es zur digitalen Erweiterung eines Unternehmens mit seinen Geschäftsprozessen wird. Um diesen spezifischen Kundenanforderungen gerecht zu werden, setzen sich unsere Entwickler, Produktmanager, Vertriebler und die IT von Anfang an mit dem Kunden zusammen und entwickeln gemeinsam die entsprechende Funktionalität. Das bietet die Chance, dass auch die Ingenieure und Elektronikentwickler von Beginn an verstehen, was der Kunde möchte und welche Konsequenz das für die Fahrzeugarchitektur hat.

Die Nutzfahrzeugbranche ist also schon so etwas wie ein Treiber der SDV-Entwicklung, da es schon viele konkrete Anwendungsfälle im B2B-Bereich gibt.

Es ist für die Player schlichtweg einfacher, sich der softwarebasierten Wertschöpfung zu nähern, da der Kundennutzen viel genauer definiert ist. Dazu kommt, dass sich im Nutzfahrzeugumfeld Features viel schneller umsetzen lassen. Das „Next Big Thing“ im Pkw-Bereich zu erfinden, ist für die OEMs logischerweise viel herausfordernder.

Zurück zu den Strukturen und Prozessen in der Entwicklung: Einige OEMs haben vor Jahren den Weg eingeschlagen, Softwareentwicklung in Spin-offs auszulagern – Volkswagen ist sicherlich das prominenteste Beispiel. Das hat, um es diplomatisch zu formulieren, nicht immer reibungslos funktioniert. Wie können schwerfällige Mehrmarkenkonzerne überhaupt Wandel herbeiführen?

Die Idee hinter dem Herauslösen einer solchen Softwareeinheit ist per se nicht schlecht: Ich schaffe mir viel Freiraum für Neues, der in den alten Strukturen überhaupt nicht entstehen kann. Doch der Vorteil ist gleichzeitig auch der Nachteil, denn die neue Einheit ist dermaßen losgelöst, dass der Organismus ihn als Fremdkörper identifiziert und abstößt. Und machen wir uns mal nichts vor: Am Ende des Tages unterschreibt nicht der Softwareentwickler oder der CIO die Freigabe eines Fahrzeugs, es ist der Entwicklungschef. Es zeigt sich momentan, das viele nicht bereit sind, sich von dem Fremdkörper ins Risiko fahren zu lassen, da gibt es gewisse „Körperreaktionen“.

Aber wie kann man dieser verfahrenen Situation begegnen?

Aus meiner Sicht ist es ganz entscheidend, wer an der Spitze dieser neuen Einheit steht. Hier braucht es jemanden mit großem Software-Knowhow, einen „Tekkie“, der mit seiner Erfahrung und einer gewissen Aura die Leute mitzieht und gleichzeitig stark in die Prozesse und Strukturen eingebunden ist. Wenn nicht jemand, der das Thema Software lebt und sich damit identifiziert, an der Spitze steht, wird es nicht funktionieren. Es ist natürlich eine große Herausforderung für die Autoindustrie, den perfekten Leader für eine solche Einheit zu finden. Viele sind jetzt auf dem richtigen Weg, sich mit Tech-Kompetenz an den richtigen Stellen zu verstärken.

Wie wichtig ist für den Schulterschluss der verschiedenen Abteilungen eine gemeinsame Grundlage in den Methoden und Prozessen zu haben? Stichwort: agile Entwicklung.

In erster Linie ist es entscheidend, dass alle Stakeholder im Entwicklungsprozess an einem Tisch sitzen und niemand sich in sein stilles Kämmerlein zurückzieht und vor sich hin entwickelt. Bei Volkswagen haben wir schon vor zehn Jahren die sogenannten „Balanced Teams“ eingeführt. Den Begriff haben wir vom Softwareunternehmen Pivotal gelernt, das damals die Softwareentwicklung bei uns vorangetrieben hat. Dabei ging es um Agilität, aber vor allem um Extreme Programming. Dabei werden zunächst die Testabläufe und dann erst der Code entwickelt – eine ganz andere Denkweise. Oder das Beispiel Pairing, bei dem zwei Entwickler an einem Bildschirm sitzen, der eine codet, der andere kontrolliert und stellt Fragen. Der dritte Aspekt ist eben die Balance, die Ausgewogenheit der Interessen in den agilen Teams: Das bedeutet, es gibt einen Produktmanager, der als Anwalt des Kunden alles, was nicht den Ansprüchen entspricht, gnadenlos rauswirft. Dazu kommt der technische Entwickler, der das Fahrzeug von innen nach außen wie seine Westentasche kennt. Und zu guter Letzt natürlich die Softwareentwickler. Diese selbstorganisierten Balanced Teams bekommen dann bestimmte Features in Eigenverantwortung. Wo dieses Team aufgehängt wird, ist letztlich egal. Wichtig ist, dass diese von Beginn autonom entscheiden können.

Ist das mit dem Druck, der beispielsweise durch den immer noch als heilig geltenden Start of Production (SoP) entsteht, vereinbar?

Das ist tatsächlich ein Problem. Wenn man in der alten Welt den SoP gerissen hat, wurde man einen Kopf kürzer gemacht. Heue werden die Anläufe fast mit einem Schulterzucken regelmäßig nach hinten verschoben. Das liegt an der gestiegenen Komplexität durch die Software: agile Teams arbeiten ihre Story Points ab und repriorisieren dabei immer wieder. Das macht einen Ingenieur verrückt.

Wie stark müssen sich Autobauer gegenüber Partnern beispielsweise aus der Tech-Welt öffnen, um Geschwindigkeit aufzunehmen und weiterhin die Zügel der softwarebasierten Wertschöpfung in den Händen zu halten?

Wer mich kennt, der weiß, dass ich ein absoluter Fan von Partnerschaften bin. Und zwar von Value-Partnerschaften, bei denen genau definiert ist, was am Ende rauskommt. Natürlich kann ich anfangen und mir über Jahre hinweg eigene Softwarekompetenzen aufbauen. Oder ich nehme mir einen Partner und bringe meine Produkte viel schneller auf die Straße. Und da sind für mich die Kosten auch erstmal sekundär, denn das Ergebnis steht immer an erster Stelle. Und das lautet, schnell zu liefern. Mein Lieblingsbeispiel ist hier Tesla: Elon Musk, der sicher nicht dafür bekannt ist, gerne Kompetenzen abzugeben, hat vor Jahren klargemacht: Solange Google Maps die beste Karte bietet, die die Kunden auch wollen, basiert das zentrale Navigationssystem in Teslas eben auf Google. Währenddessen grassierte bei den deutschen Herstellern immer die Angst, wenn man Google oder andere Tech-Unternehmen Zugang zum Auto gewährt, dass man dann die Schnittstelle zum Kunden verliert. Dabei hat man eigentlich nur Zeit verloren. Sich also am Anfang auf einen Partner zu verlassen, der mir Kompetenz, Innovation und Geschwindigkeit einbringt, ist wichtig. Dazu gehören im Bereich Software die großen Tech-Player, aber auch die Tier-1-Zulieferer wie Bosch, Conti oder ZF sind hier gefragt.

Zum Schluss noch eine Frage zu Ihrem aktuellen Arbeitgeber: Volta Trucks hat aufgrund der Pleite eines Batterielieferanten in den USA Insolvenz anmelden müssen. Gibt es dennoch Hoffnung?

Zunächst muss ich sagen, dass das Engagement bei Volta eine Lifetime-Opportunity für mich war. Ich hatte während und nach meiner Zeit bei Volkswagen schon viel Kontakt mit Startups und konnte nun als CTO bei Volta richtig einsteigen. Ich war begeistert von dem Produkt, das insgesamt ein sehr gutes Feedback bekam und lange im Voraus ausverkauft war. Die nächste Finanzierungsrunde stand an und dann meldete Proterra in den USA den Insolvenzantrag nach Chapter 11, was unsere Investoren natürlich erstmal zurückschrecken ließ und wir Probleme mit dem Cash-Flow bekamen. Jetzt hat sich eine Möglichkeit ergeben, das Unternehmen zu revitalisieren. Denn die Nachfrage ist da, das Fahrzeug ist fertig, die Produktion steht in den Startlöchern – nur fehlt aktuell noch das Geld. Das ist anders als im Großkonzern, in dem der Geldtopf eigentlich immer gut gefüllt ist. Das musste ich auch erstmal lernen.