KI & Automatisierung
In der Automobilindustrie ist Zeit Geld, aber Versuchsträger sind noch mehr Geld. Ein Prototyp oder Vorserienfahrzeug kostet je nach Entwicklungsstand zwischen 150.000 und 800.000 Euro. Wer in der Fahrzeugentwicklung arbeitet, kennt die Situation: Die Fahrzeugentwicklung ist in große Entwicklungsbereiche gegliedert, beispielsweise Antrieb, Elektrik/Elektronik oder Fahrerassistenzsysteme. Jeder dieser Bereiche verantwortet seine eigene Versuchsträgerplanung, weil die Fahrzeuge in der Regel bereichsspezifisch konfiguriert sind und eine Quernutzung zwischen den Bereichen in den meisten Fällen nicht möglich ist.
Innerhalb eines Bereichs aber, etwa innerhalb der Fahrerassistenzsysteme, sieht die Lage anders aus. Dort arbeiten mehrere Abteilungen mit unterschiedlichen Testaufgaben, unterschiedlichen Anforderungen an den Entwicklungsstand des Fahrzeugs und unterschiedlichen Zeitbedarfen, und alle konkurrieren um denselben Pool an Versuchsträgern. Kamerabasierte Systeme, Radarsensorik, Fusionsalgorithmen, Homologation, Software-Validierung, jede Einheit hat ihren Bedarf, ihre Deadlines und ihre Abhängigkeiten.
Koordiniert wird das heute meistens von einer einzelnen Person oder einem kleinen Team, das als menschlicher Optimierungsalgorithmus funktioniert. Bedarfe werden per E-Mail eingesammelt, in Tabellen zusammengeführt, Konflikte in Abstimmungsrunden gelöst. Der fertige Plan ist in dem Moment, in dem er verteilt wird, bereits wieder überholt, weil eine Abteilung ihren Testumfang geändert hat, ein Fahrzeug ungeplant in die Werkstatt muss oder im schlimmsten Fall verunfallt.
Das ist kein Nischenproblem. Es ist ein strukturelles Problem, das in jedem größeren Entwicklungsbereich jeden OEM und jeden größeren Tier-1-Zulieferer betrifft. Und es ist ein Problem, das sich mit einer Kombination aus Automatisierung, KI und einer durchdachten Systemarchitektur erheblich entschärfen lässt.
Eine Tabellenkalkulation kann planen, aber nicht denken. Ein Kalendertool kann Buchungen anzeigen, aber nicht erkennen, dass zwei aufeinanderfolgende Buchungen auf demselben Fahrzeug einen Umbau erfordern, der vier Wochen dauert und alle nachfolgenden Termine verschiebt. Eine E-Mail kann eine Änderung kommunizieren, aber nicht automatisch prüfen, welche anderen Buchungen davon betroffen sind und ob ein Konflikt entsteht.
Das eigentliche Problem ist nicht das Fehlen von Daten. Es ist das Fehlen von Logik, die mit diesen Daten etwas anfangen kann. Und: das Wissen steckt in Menschen. Wenn die Person, die den Überblick hält, das Unternehmen verlässt oder längere Zeit ausfällt, kollabiert der Prozess.
Was gebraucht wird, ist kein besseres Excel. Was gebraucht wird, ist ein lebendes System.
Das System denkt in zwei klar getrennten Phasen.
In der Planungsphase wird einmalig zu Beginn eines Entwicklungsprojekts der gesamte Testbedarf eingesammelt, durch eine KI-Optimierungsanalyse verarbeitet und in einen initialen Plan überführt. Am Ende dieser Phase steht eine fixierte Versuchsträgerflotte. Wie viele Fahrzeuge beschafft oder reserviert werden, entscheidet diese Phase. Danach gilt: Mit dem, was vorhanden ist, wird gearbeitet. Planänderungen sind möglich, aber die Flottengröße ist gesetzt. Fällt ein Fahrzeug durch einen Unfall oder irreparablen Defekt aus, greift ein definierter Prozess zur Ersatzbeschaffung oder Neuverteilung, der ebenfalls im System abgebildet ist.
In der Betriebsphase lebt der Plan. Abteilungen melden Änderungen, Fahrzeuge fallen für Werkstattarbeiten aus, Termine verschieben sich. Das System verarbeitet das kontinuierlich, aktualisiert den Plan automatisch, kommuniziert Änderungen an alle Betroffenen und eskaliert genau dann zum Menschen, wenn es selbst keine Lösung findet oder eine Entscheidung eine menschliche Verantwortung erfordert.
Diese zwei Phasen spiegeln sich in vier Workflows wider, die miteinander kommunizieren.
Der erste Workflow wird einmalig manuell angestoßen. Jede beteiligte Abteilung erhält einen Link zu einer strukturierten Eingabemaske. Was dort abgefragt wird, ist kein Freitext, sondern strukturierte Daten: benötigte Fahrzeuganzahl, Testdauer, erforderlicher Entwicklungsstand des Fahrzeugs, Flexibilität im Zeitfenster, Abhängigkeiten zu anderen Abteilungen, Priorität des Testvorhabens.
Alle Eingaben landen in einer geeigneten Datenbank. Solange noch Abteilungen ausstehen, versendet das System automatisch Erinnerungen. Wenn alle geantwortet haben, übergibt der Workflow die gesammelten Daten an die KI.
Die KI bekommt damit eine klassische Optimierungsaufgabe: Wie viele Versuchsträger werden mindestens benötigt, und wie müssen die Nutzungszeiten angeordnet werden, damit möglichst viele Abteilungen ihre Anforderungen erfüllen können und gleichzeitig möglichst wenige Fahrzeuge nötig sind? Das Ergebnis ist kein blindes Rechenresultat, sondern ein erklärter Vorschlag: Welche Abteilungen können sequenziell auf demselben Fahrzeug testen? Wo gibt es Konflikte, die eine Entscheidung brauchen? Welche Abteilung ist zeitlich flexibel genug, um zu verschieben?
Der Versuchsträgermanager bekommt diesen Vorschlag zur Prüfung und Freigabe. Erst nach seiner Freigabe wechselt das System in die Betriebsphase.
Ab dem Moment, in dem die Betriebsphase aktiv ist, nimmt Workflow 2 alle eingehenden Änderungsanfragen entgegen. Er wird ausgelöst, wenn eine Abteilung über die Weboberfläche eine Änderung am Plan beantragt.
Wichtig: Änderungen am initialisierten Plan sind keine Selbstverständlichkeit. Wer eine Änderung beantragt, muss sie begründen. Das ist keine bürokratische Hürde, sondern eine notwendige Schranke gegen unkontrolliertes Umplanen, das in der Praxis schnell zu Chaos führt, weil jede Änderung Folgewirkungen auf andere Abteilungen haben kann.
Der Prozess sieht wie folgt aus: Die Abteilung reicht die Änderungsanfrage mit Begründung ein. Die KI analysiert daraufhin den Änderungswunsch, prüft die Auswirkungen auf den Gesamtplan und erstellt eine strukturierte Genehmigungsvorlage für den Versuchsträgermanager. Diese Vorlage enthält die ursprüngliche Begründung der Abteilung, die Machbarkeitsanalyse der KI, die betroffenen Buchungen und die möglichen Konsequenzen bei Genehmigung oder Ablehnung.
Der Versuchsträgermanager entscheidet auf Basis dieser Vorlage. Er genehmigt, lehnt ab oder gibt einen modifizierten Gegenvorschlag zurück. Erst nach Genehmigung wird der Plan aktualisiert und alle betroffenen Abteilungen werden informiert.
Erkennt die KI bei der Analyse einen Konflikt, der über eine einfache Machbarkeitsprüfung hinausgeht, eskaliert sie direkt an Workflow 4, ohne dass der Manager zunächst eine einfache Genehmigungsentscheidung treffen muss. Er bekommt stattdessen das vollständige Konflikt-Briefing.
Dieser Workflow ist der technisch anspruchsvollste, weil er eine Dimension in die Planung einführt, die kein klassisches Kalendertool kennt: den Konfigurationszustand eines Fahrzeugs.
Ein Versuchsträger ist kein generisches Asset, das man einfach weiterreicht. Wenn eine Abteilung ein Fahrzeug mit einer bestimmten Sensorkonfiguration, einem spezifischen Softwarestand und definierten Anbauteilen testet, und die nächste Abteilung dasselbe Fahrzeug mit einer grundlegend anderen Konfiguration benötigt, dann liegt dazwischen Arbeit. Umbauzeit, Werkstattkapazität, möglicherweise Wartezeit auf Teile oder eine neue Softwarekalibrierung.
Workflow 3 wird ausgelöst, sobald eine neue Buchung auf einem bereits belegten Versuchsträger eingeht. Er lädt die Vorgängerbuchung und vergleicht die Konfigurationen. Wenn kein Umbau nötig ist, plant er die direkte Übergabe. Wenn ein Umbau nötig ist, prüft er die Werkstattkapazität und die verfügbare Zeit zwischen den Buchungen.
Passt alles, wird ein Umbaublock im Plan eingetragen und die zuständige Werkstatt wird benachrichtigt. Passt es nicht, geht der Fall an Workflow 4.
Für die Weboberfläche bedeutet das: Jeder Versuchsträger hat nicht nur Buchungsblöcke, sondern auch explizite Umbauperioden als eigene Planelemente. Sichtbar für alle Beteiligten, mit dem jeweiligen Konfigurationsstatus vor und nach dem Umbau.
Dieser Workflow ist der Kern des gesamten Konzepts, weil er das Verhältnis zwischen Mensch und System definiert.
Das System ist kein autonomer Entscheider. Es ist ein strukturierter Assistent, der alle lösbaren Fälle selbst löst und für alle unlösbaren Fälle die bestmögliche Entscheidungsgrundlage liefert. Workflow 4 stellt sicher, dass diese Grenze sauber eingehalten wird.
Wenn Workflow 2 oder 3 einen nicht lösbaren Konflikt erkennt, lädt Workflow 4 alle relevanten Daten und übergibt sie an die KI. Die KI erstellt kein generisches Fehlermeldungs-Template, sondern ein spezifisches Eskalationsbriefing: Was ist das konkrete Problem, welche Buchungen sind betroffen, welche Lösungsoptionen hat das System bereits geprüft und warum haben sie nicht funktioniert, welche Entscheidungsoptionen gibt es und welche Konsequenzen hat jede davon.
Dieses Briefing geht an den Versuchsträgermanager, inklusive einem direkten Link zur Eskalationsansicht in der Weboberfläche. Dort sieht er alles auf einen Blick, trifft seine Entscheidung oder gibt einen eigenen Lösungsvorschlag ein. Das System übersetzt diese Entscheidung in konkrete Planänderungen, aktualisiert alle betroffenen Buchungen und informiert die beteiligten Abteilungen.
Der Manager entscheidet. Das System exekutiert.
Jenseits der Workflow-Logik gibt es einige technische Aspekte, die für eine ernsthafte Implementierung durchgedacht sein müssen.
Versuchsträger als Datenobjekte: Jedes Fahrzeug im System ist ein eigenständiges Objekt mit einer vollständigen Konfigurationshistorie. Welche Softwareversion läuft aktuell, welche Anbauteile sind verbaut, welcher Entwicklungsstand liegt vor. Diese Information ist nicht statisch, sie ändert sich mit jedem Umbau, und jede Änderung wird versioniert, damit der Plan zu jedem Zeitpunkt nachvollziehbar ist. Fällt ein Fahrzeug dauerhaft aus, wird es im System deaktiviert und ein Ersatzprozess wird angestoßen.
Konfigurationskompatibilität: Nicht jede Abteilung kann mit jeder Fahrzeugkonfiguration arbeiten. Ein Fahrwerktest braucht keinen bestimmten Softwarestand, ein Steuergerätetest schon. Das System muss diese Abhängigkeiten kennen und bei der Zuweisung berücksichtigen.
Differenzierte Konflikttypen: Ein Terminkonflikt ist anders als ein Konfigurationskonflikt, der ist anders als ein Kapazitätsengpass in der Werkstatt. Die KI muss diese Typen unterscheiden, weil die Lösungsoptionen unterschiedlich sind und die Entscheidungsgrundlage für den Manager eine andere ist.
Auditierbarkeit: In der Automotive-Entwicklung mit ihren Qualitätssicherungsprozessen ist nicht nur das Ergebnis relevant, sondern auch der Weg dorthin. Jede Planänderung, jede Genehmigung, jede Ablehnung, jede Eskalation und jede Managemententscheidung wird mit Zeitstempel und Begründung dokumentiert. Das ist kein Nice-to-have, das ist eine Grundanforderung.
Das System ist nur so gut wie seine Oberfläche. Eine Gantt-ähnliche Ansicht pro Versuchsträger zeigt auf einen Blick, wer wann welches Fahrzeug nutzt, welche Umbauarbeiten geplant sind, wo Lücken sind und welche Genehmigungen oder Eskalationen offen sind.
Jede Abteilung sieht ihre eigenen Buchungen sowie die unmittelbar relevanten Nachbarbuchungen auf denselben Fahrzeugen. Der Versuchsträgermanager sieht alles. Änderungen werden nicht per E-Mail gemeldet, sondern direkt über die Oberfläche beantragt, mit Pflichtfeld für die Begründung. Genehmigungsvorlagen und Eskalationen haben eigene Ansichten mit allen nötigen Informationen zur Entscheidung.
Das ist der eigentliche Vergleich zum Status quo: Statt eines zentral verwalteten Dokuments, das nur eine Person wirklich versteht, hat jeder Beteiligte Zugriff auf seinen relevanten Ausschnitt des Plans, in Echtzeit, immer aktuell, mit einer klaren Struktur für Änderungen und Entscheidungen.
Der offensichtliche Nutzen ist die Einsparung von Versuchsträgern durch bessere Auslastung. Wenn das System zwei oder drei Fahrzeuge einspart, rechnet sich die Implementierung bereits im ersten Projekt.
Der nachhaltigere Nutzen ist ein anderer: Das Wissen bleibt im System. Heute hängt die Qualität der Versuchsträgerplanung maßgeblich an einzelnen Personen. Wenn diese Personen das Unternehmen verlassen, geht das Planungswissen mit. Im System ist jede Entscheidung, jeder Konflikt, jede Lösung dokumentiert. Onboarding wird von einer monatelangen Einarbeitung zu einem strukturierten Einstieg.
Dazu kommt die Reaktionsgeschwindigkeit. Heute dauert es Tage, bis eine gemeldete Änderung eingearbeitet, kommuniziert und abgestimmt ist. Im System passiert das innerhalb von Stunden, in einfachen Fällen in Minuten.
Und schließlich: Kontrolle ohne Mehraufwand. Der Genehmigungsprozess in Workflow 2 stellt sicher, dass keine unkontrollierten Änderungen am Plan vorgenommen werden, ohne dass der Versuchsträgermanager dafür täglich in Abstimmungsmeetings sitzen muss. Er entscheidet informiert, wenn es nötig ist, und das System kümmert sich um den Rest.
Die Versuchsträgerplanung ist kein glamouröses Problem. Es ist ein operatives Problem, das in jedem Entwicklungsprojekt auftaucht, viel Koordinationsaufwand erzeugt und direkte Auswirkungen auf Kosten und Entwicklungsgeschwindigkeit hat. KI und Automatisierung können hier nicht alles lösen, und das sollten sie auch nicht. Aber sie können den großen Teil des Prozesses, der heute manuell, fehleranfällig und zeitaufwendig ist, auf eine Qualität und Geschwindigkeit heben, die mit menschlicher Koordination allein nicht erreichbar ist.
Was bleibt: die Entscheidung, wenn das System nicht weiterkommt. Das ist der Punkt, an dem der Mensch gebraucht wird. Und dafür ist er dann auch wirklich da.
Viele Unternehmen kämpfen mit genau diesen Problemen und das oft ohne es bewusst zu erkennen.
Gemeinsam lässt sich schnell herausfinden, wo Automatisierung und KI konkret Mehrwert schaffen können.
