Autonomes Fahren: eine neue Herausforderung für vernetztes Arbeiten

Das Ziel, hochautomatisiert fahren zu können, führt zu tief greifenden Veränderungen in der Automobilbranche. Das gilt nicht nur für die Automobiltechnik in Soft- und Hardware, sondern auch für das Projektmanagement während der Entwicklung. Im automotion-Interview berichten Timm Kellermann, Geschäftsführer von Consulting4Drive, dem Beratungsunternehmen der IAV-Gruppe, und Dr. Michael Gröschel, Projektleiter und Wirtschaftsmediator bei IAV, über ihre Projekterfahrungen und zeigen Optimierungspotenziale im Entwicklungsprozess auf.

Projektmanagement in der Entwicklung – ist das 2019 wirklich noch eine Herausforderung?

Timm Kellermann: Bei der Beantwortung dieser Frage werden wir in der Automobilindustrie gerade ein wenig demütiger, als wir es vielleicht vor fünf Jahren waren. Richtig ist: Alle Hersteller, mit denen wir zusammenarbeiten, kennzeichnet im Bereich der Fahrerassistenz eine sehr hohe Reife bezüglich der Planung, Führung und Umsetzung von Fahrzeug-Entwicklungsprojekten – das betrifft sowohl Hardware als auch automobile Software. Jedoch sehen wir bei der Entwicklung von hoch automatisierten Fahrsystemen aktuell dennoch fast jedes Projekt in einer Krise. Es hat sich nicht bestätigt, dass die Ursache hierfür mangelnde Stringenz oder Disziplin in der Projektleitung ist. Vielmehr zeichnet sich ab, dass Automated-Driving-Entwicklungsprojekte des Level 3 oder höher eine neue, eigene Kategorie von Projektsteuerungsproblemen darstellen. An einem solchen Projekt arbeiten zum Teil sieben Firmen mit mehr als 700 Personen, an mehr als 20 Standorten und in drei Zeitzonen. Diese Personen stammen aus mehr als 30 Ländern. Die Fragmentierung entsteht durch die umfangreichen neuen Kompetenzen und die Vielzahl der Partner und Domänen, die für diese Art von Entwicklung benötigt werden. Dies allein erklärt aber nicht die in den Projekten auftretenden Herausforderungen.

Worin liegen die weiteren Ursachen?

Dr. Michael Gröschel: Branchenweit geht die Entwicklung von Assistenzsystemen in eine neue Phase. Bis dato wurden einzelne Produkte wie ein Spurhalteassistent oder ein ACC-System als Stand-alone-Funktion bilateral zwischen Hersteller und Zulieferer entwickelt. Ab Level 3 besteht die Projektaufgabe in der Entwicklung eines Gesamtsystems statt einer einzelnen Funktion. Der Reifegrad der erforderlichen Systeme und Technologien ist noch nicht sehr hoch, sodass sich intensive Wechselwirkungen zwischen Sensoren, technischer Architektur und Software-Entwicklung ergeben. Im Zuge der Integration führt der hohe Vernetzungsgrad im Fahrzeug dabei häufig zu Abhängigkeiten, die sehr spät im Entwicklungsprozess umfangreiche Hardwareund Softwareänderungen in den Teilsystemen erfordern, um die Summe der Kundenanforderungen an das Gesamtsystem zu erfüllen. Sie können sich vorstellen, dass in solchen Situationen die Komplexität des entsprechenden Entwicklungs- und Absicherungsprozesses massiv steigt. Parallel nimmt der Zeitdruck zu, es müssen also in immer kürzerer Zeit immer komplexere Aufgaben in zunehmend verteilten Projektteams gelöst werden.

Kellermann: Die Symptomkette kennen wir gut: Zu Beginn des Projekts lassen sich Anforderungen nicht ausreichend vollständig und detailliert beschreiben, was zu erheblichen Problemen sowohl in der Entwicklung als auch bei Test und Absicherung bis hin zur Fehlerbehebung im Feld führt. Diese Lücken sind allerdings auch hier in der Regel nicht Mangel an Disziplin, sondern Mangel an Erkenntnis und Wissen: Mit ADAS-Level 3 und höher betreten wir – wenn wir ehrlich sind – unerwartet mehr Neuland als bekanntes Territorium. Die Entwicklung von hoch automatisierten Fahrsystemen ist Stand heute somit noch vornehmlich eine Suche nach neuer Effektivität. Dies ist auch der Grund, warum agil-iterative und MVP (Minimum Viable Product) basierende Vorgehensweisen so hoch im Kurs stehen: sie sind Methoden aus der Effektivitätswelt. Unsere wichtigsten Methoden aus der bisherigen automobilen Effizienzwelt sind der sequenzielle Produktentstehungsprozess (PEP) und der Fahrzeug- bzw. Feature-Business-Case. Somit stoßen aktuelle AD-Projekte an eine grund sätzliche Komplexitätsgrenze, die mit den bisherigen Werkzeugen und Vorgehensmodellen im Projekt nicht mehr zum gewohnten Erfolg geführt werden können.

Dr. Gröschel: Weitere Herausforderungen in der Projektbearbeitung ergeben sich für uns dabei insbesondere durch unterschiedliche Kommunikations-, Umsetzungs- und Arbeitskulturen aufgrund regionaler Prägungen und branchenspezifischer Sichtweisen. Regionale Unterschiede erleben wir etwa bei der Projektumsetzung im Team. In Asien hat für den Zulieferer die gemeinsame Zielerreichung in einer auf einem tiefem Vertrauensverhältnis fußenden Zusammenarbeit höchste Priorität, während man sich in Europa vorrangig an vordefinierten Lastenheftanforderungen in einem starren Vertragsverhältnis orientiert. Branchenspezifische Diskrepanzen gibt es beispielsweise in der Umsetzung cloudbasierter Funktionen zwischen der Automobilund der IT-Welt, welche sich durch eine wesentlich höhere Entwicklungsgeschwindigkeit auszeichnet. Letztere erfordert eine höhere Fehlertoleranz im Entwicklungsprozess, die beispielsweise im Smartphone-Bereich durch die Möglichkeit eines Software-Updates im späteren Betrieb ausgeglichen wird.

Der Bereich des hochautomatisierten Fahrens hingegen zeichnet sich durch sicherheitskritische und zugleich hochinnovative Produkte aus, die eine enge Kopplung der Hardwareund Software-Entwicklung bei Steuergeräten und Sensorik erfordern. Oftmals erleben wir, dass die Projektpartner zwar gleiche oder ganz ähnliche Begriffe nutzen, diese aber mit ganz anderen Inhalten füllen. Spannungen im Projektteam und Probleme bei der Projektumsetzung sind damit vorprogrammiert.

Warum treten die Probleme nun so deutlich zutage?

Kellermann: Weil wir seit Jahren erfolgreich Fahrassistenzsysteme entwickeln, scheint uns der Schritt von Level 2 zu Level 3 ein kleiner, systematischer Schritt zu sein. Mittlerweile bin ich der Überzeugung, dass genau das Gegenteil der Fall ist. An dieser Stelle wird eine fundamentale Grenze in unserem automobilen Geschäftsmodell überschritten: Bis Level 2 ist allein der Fahrer für den sicheren Betrieb des Fahrzeugs verantwortlich. Ab Level 3 übernimmt der Hersteller zeitweise die Verantwortung für den sicheren Betrieb des Fahrzeugs. Damit müssen de facto viele Herausforderungen des vollautomatisierten Fahrens höherer Level bereits heute adressiert werden. In den letzten Jahren wurde von den Herstellern zudem viel Verantwortung hinsichtlich der Entwicklung wie auch der Absicherung von Fahrerassistenzfunktionen auf die Zulieferer übertragen. Durch den hohen Vernetzungsgrad automatisierter Fahrzeuge ist dieser Trend derzeit jedoch gerade umzukehren, da ein System selten ausschließlich von einem Zulieferer vollumfänglich bereitgestellt werden kann.

Dr. Gröschel: Damit einhergehend erfordern die aktuellen Projekte bei den Herstellern wesentlich höhere Aufwände zur Systementwicklung, Integration und Absicherung und es ergeben sich weit umfangreichere Anforderungen an die Kommunikation und das Informationsmanagement zwischen den Projektteams. Darüber hinaus nimmt die Software einen immer größeren Stellenwert bei der Entwicklungsleistung ein. Waren es bei Level-2-Projekten noch 60 Prozent Soft- und 40 Prozent Hardware, sind es bei Level-3-Funktionen bereits 80 Prozent Software, mit steigender Tendenz. In der Hardware-Entwicklung benötigt man Zeit zur Darstellung robuster Lösungen, wodurch frühe Festlegungen hinsichtlich Architektur und Performance erforderlich sind. Allerdings dreht sich in dieser Zeit die Welt weiter, und oftmals erkennt man erst im Laufe des Projekts, dass die Hardware nicht mehr den aktuellen Anforderungen gerecht wird.
Demgegenüber verläuft die Software-Entwicklung sehr viel dynamischer, Änderungen – auch substanzieller Art – sind an der Tagesordnung und werden kurzfristig durchgeführt. In der Systementwicklung hochautomatisierter Fahrfunktionen stoßen damit durch den hohen Innovationsgrad und die erwähnte enge Kopplung zwischen Hard- und Software zwei Denkkulturen unter hohem Projektdruck aufeinander, die beide für sich ihre Berechtigung haben.

Und die Auswirkungen auf die Entwicklungsprojekte?

Dr. Gröschel: Als Projektpartner merkt man in der Regel sehr schnell, wenn es im Team nicht optimal läuft. Das äußert sich unter anderem durch zeitlichen Verzug im Projektverlauf und beim Meilensteinreporting sowie durch zu spät erkannte Funktionsdefizite, die aufwendige Hardware-Änderungen erforderlich machen. Kellermann: Beim Projektmanagement erleben wir einen sprunghaft ansteigenden Steuerungs- und Transparenzbedarf, um die vielen Teammitglieder zu koordinieren und auf dem Stand der neuesten Informationen zu halten. Ansonsten droht das Projekt aus dem sprichwörtlichen Ruder zu laufen.

Welche Gegenmaßnahmen ergreifen Sie?

Dr. Gröschel: Im aktuellen Projekt haben wir gemerkt, dass die auftretenden Probleme nicht durch eine reine Kapazitätserhöhung auf der Engineeringseite gelöst werden konnten. Durch einen intensiven Kundenkontakt wurde in der Diskussion immer deutlicher, dass parallel zur Technik auch das Zusammenarbeitsmodell der Projektpartner angepasst werden muss. Gemeinsam mit Consulting4Drive haben wir daraufhin zunächst eine weit über den üblichen Umfang hinausgehende Analyse der Gesamtsituation durchgeführt und die zu Beginn beschriebenen Herausforderungen identifiziert.

Kellermann: Um eine nachhaltige Verbesserung im Projekt zu erzielen, haben wir einen neuen Lösungsbaukasten erarbeitet. Er teilt sich auf in Management-Consulting, technische Beratung, operatives Engineering und ein erweitertes Projektmanagement an den Schnittstellen der Projektpartner. Beim Management-Consulting geht es darum, die Projektpartner schon im Vorfeld auf die Komplexität des Projekts vorzubereiten und ihnen deutlich zu machen, dass unterschiedliche Sichtweisen und Herangehensweisen eine gewollte Bereicherung und nicht kontraproduktiv für das Projekt sind. Auch führen Versuche, die Anforderungen bereits zu Projektbeginn zu fixieren, nicht zum gewünschten Erfolg.

Bei der technischen Beratung bringen wir die IAV-Kompetenz beispielsweise bei der Frage ein, welche System- oder Technologiearchitektur für die vorliegende Aufgabenstellung am besten geeignet ist. Das operative Engineering umfasst ein systematisches Anforderungsmanagement, das Testing und die Absicherung der im Projekt entwickelten Hardware- und Software-Systeme mit IAV-eigenen Simulationsumgebungen und Prüfständen.

Ein wichtiger Eckpfeiler unseres Projektmanagements an der Schnittstelle zu den Zulieferern ist die sogenannte Joint-OperationsPlattform. Mithilfe des Toolings können die Projektpartner beispielsweise sämtliche Informationen zentral ablegen und austauschen, miteinander kommunizieren oder Termine und Status des Gesamtprojekts und der Teilprojekte einsehen. Das sorgt für Transparenz und damit Klarheit über den Projektverlauf. Darüber hinaus werden ein ständiges Monitoring der Meilensteinziele und eine straffe Steuerung des Projekts ermöglicht.

Dr. Gröschel: Um intern im Tagesgeschäft eine übergreifende Koordination der aus dem Lösungsbaukasten abgeleiteten Projekte gewährleisten zu können, wurde eine Programmstruktur als Klammer um die breit gefächerten Aktivitäten entwickelt. In der Programmstruktur werden die verschiedenen Fragestellungen des Gesamtvorhabens in einzelne Projekte mit eigener Verantwortung aufgeteilt. Das Programm-Management verantwortet als übergeordnete Instanz nur das Zusammenspiel der Projekte, aber nicht deren Einzelerfolg. Die aus dieser Struktur resultierende verteilte Verantwortung spiegelt die Charakteristik der zu entwickelnden Systeme sehr gut wieder und ist somit ein entscheidender Erfolgsfaktor. Wesentlich waren hierbei gerade im internationalen Kontext das Verstehen und Reagieren auf die kulturellen Besonderheiten der Projektpartner wie beispielsweise der Aufbau einer starken Vertrauensbeziehung in Asien. Darüber hinaus ermöglichte der Aufbau einer intensiven Kundenbeziehung auf Managementebene im Rahmen des Consultings durch Consulting4Drive auch unserem Projektteam bei IAV, seitens des Engineerings eine neue Stufe in der Projektbearbeitung mit dem Kunden zu erreichen.

Fokussiert sich das Problem auf Projekte des automatisierten Fahrens?

Kellermann: Wir glauben, dass dies nicht der Fall ist. Die wesentliche Charakteristik der angesprochenen Projekte besteht in einem hohen Technologie- und Innovationsgrad, daher sind die Herausforderungen im Umfeld des hochautomatisierten Fahrens lediglich zuerst zutage getreten. Die Probleme sind jedoch grundsätzlicher Natur und ergeben sich aus der Transformation der Automobilwelt durch die Digitalisierung. Für mich ist das nur die Vorstufe zur endgültigen Komplexität, die sich aus den neuen Mobilitätskonzepten der „Smart Mobility“ ergibt. Dort müssen dann Digitalbereich, Automobilbereich und Infrastrukturanbieter mit ihren stark unterschiedlichen Entwicklungs- und Innovationsgeschwindigkeiten zusammengebracht – synchronisiert – werden.

Dr. Gröschel: Überall dort, wo unterschiedliche Technologiebereiche und verschiedene internationale Standorte zusammenarbeiten, werden die beschriebenen neuen Ansätze nötig sein, um strukturiert Lösungen entwickeln zu können. Wir haben in Kooperation mit Consulting4Drive ein Vorgehensmodell für vernetztes Arbeiten, Informationstransfer unter den Entwicklerteams sowie neue Formen der Zusammenarbeit auf Basis eines Verständnisses der Verschiedenartigkeit der beteiligten Partner entwickelt und bieten damit eine wesentliche Schlüsselkomponente erfolgreicher Mobilitätsprojekte an.

Kellermann: Noch ein Gedanke zum Schluss: In der Welt des digitalen IT-Bereichs gibt es einen Wettbewerbsvorteil, der uns in der Automobilbranche aktuell sehr intensiv beschäftigt: hohe Lerngeschwindigkeit, auf Neudeutsch „speed of learning“. Wir glauben, dass dieser Faktor auch für die Entwicklung von automatisierten Fahrsystemen wesentlichen Einfluss auf den Erfolg am Markt und damit die Profitabilität haben wird.

Meine Herren, vielen Dank für das Gespräch.