Wertbeitrags-Prinzip: AI im Automotive Software Engineering

Das Wertbeitrags-Prinzip im Automotive Software Engineering: AI dort einsetzen, wo sie Aufwand nimmt und Wert schützt

Das Wertbeitrags-Prinzip ist ein Vorgehensmodell für den AI-Einsatz im Automotive Software Engineering. Es klassifiziert die Arbeit jeder Rolle eines Automotive-SPICE-Projekts (SWE.1 bis SWE.6, SUP.1/8/9/10, MAN.3/5) nach vier Tätigkeitsklassen, zerlegt jede Tätigkeit in Urteils-, Ausführungs- und Logistikanteil und entscheidet erst danach, welcher Anteil automatisiert, augmentiert oder bewusst beim Menschen belassen wird. Ergebnis ist eine versionierte Entscheidungsmatrix, die Hebel vergleichbar macht, bevor Budget an einzelne Use-Cases gebunden wird.

Wenn in einem Entwicklungsbereich über Künstliche Intelligenz gesprochen wird, beginnt das Gespräch fast immer bei den Werkzeugen: ein Assistent für die Testfall-Erstellung, ein Copilot für die Implementierung, ein Bot für die Ticket-Pflege. Jede dieser Ideen kann tragen. Was in dieser Reihenfolge jedoch fehlt, ist die gemeinsame Grundlage: Welche Arbeit welcher Natur steckt tatsächlich in den Rollen eines ASPICE-Projekts, wovon hängt sie ab, und wo liegt der größte Hebel im Verhältnis zum Risiko.

Dieser Beitrag beschreibt das Wertbeitrags-Prinzip, mit dem sensified diese Grundlage legt: die vier Tätigkeitsklassen in ihrer Automotive-Lesart, das Zerlegungs-Prinzip, die These zur Compliance-Arbeit, die vier Wertströme eines Software-Engineering-Projekts, die Dreifach-Triage und den Weg zur kundenspezifischen Entscheidungsmatrix. Am Ende steht ein Abschnitt, den viele Methodendarstellungen weglassen: die Grenzen des Modells.

Warum Use-Case-Listen im ASPICE-Umfeld zu früh kommen

Use-Case-Diskussionen ohne Rollen- und Wertstrom-Bild optimieren lokal: Der lauteste Schmerz gewinnt, nicht der größte Hebel. Im Automotive Software Engineering kommt eine zweite Ebene hinzu, denn jede Intervention berührt Work Products, die in Assessments und Safety-Audits bestehen müssen. Wer automatisiert, bevor klassifiziert ist, riskiert, Compliance-Substanz zu beschädigen, und das ist in dieser Domäne ein teures Anti-Pattern mit Downrating- und Nacharbeits-Risiko.

Der lauteste Schmerz ist selten der größte Hebel

Ein Team, das unter der Testdokumentation leidet, wird Testautomatisierung fordern. Ein anderes, das an Change-Requests erstickt, will das Change-Board entlasten. Beide Wünsche sind legitim, aber ohne vergleichende Betrachtung bindet das Budget sich an den Wunsch, der am lautesten vorgetragen wird. Die Entscheidungsmatrix des Wertbeitrags-Prinzips macht die Hebel über Rollen und Wertströme hinweg vergleichbar, bevor eine einzelne Initiative beauftragt wird. Kommt ein Haus mit einem fertigen Use-Case-Wunsch, wird dieser als Hypothese in die Analyse eingeordnet, weder abgewiesen noch an der Matrix vorbei beauftragt.

AI im Prozess, AI im Fahrzeug: die erste Abgrenzung

Das Wertbeitrags-Prinzip behandelt AI im Engineering-Prozess, also auf der Werkzeug- und Betriebsschicht-Ebene. AI im Fahrzeug, etwa ML-basierte Fahrfunktionen mit den Prozessen MLE.1 bis MLE.4 und ISO/PAS 8800, ist ausdrücklich nicht Gegenstand. Diese Unterscheidung gehört in die ersten fünf Minuten jedes Gesprächs, weil sie über Normenrahmen, Nachweispflichten und Zuständigkeiten entscheidet.

Die vier Tätigkeitsklassen K1 bis K4 in der Automotive-Lesart

Grundlage der Analyse sind vier Tätigkeitsklassen, die beschreiben, welcher Natur eine Arbeit ist. Die Klassen selbst sind branchenneutral, ihre Verteilung und ihr Charakter verschieben sich im Automotive Software Engineering jedoch deutlich, vor allem bei der Kontroll- und Compliance-Arbeit.

K1 und K2: der Kern bleibt Menschenarbeit

Verhandlung, Führung und Urteilsbildung sind keine Automatisierungskandidaten. Für K2 gilt jedoch: Die Entscheidung bleibt beim Menschen, die Entscheidungsgrundlage darf maschinell aufbereitet werden. Ein Architekt, der zu jeder Architekturfrage die betroffenen Anforderungen, vorhandene Rationales und ähnliche frühere Entscheidungen als Dossier abruft, entscheidet schneller und besser dokumentiert. Wie sich das je Rolle konkret darstellt, zeigen die Beiträge zum Requirements Engineer am SWE.1-Arbeitsplatz und zu den Test-Rollen SWE.4 bis SWE.6.

K3 ist im ASPICE-Umfeld Struktur, kein Rand

Im generischen Mittelstandsbild ist K3 die kleinste Klasse. In ASPICE- und ISO-26262-Projekten ist sie konstitutiv: Traceability und Konsistenz sind in Automotive SPICE 4.0 als eigene Base Practices in jedem Engineering-Prozess verankert, Output-Items heißen ausdrücklich Evidences. Genau deshalb verdient diese Klasse eine eigene These, die der nächste Abschnitt ausführt.

Das Zerlegungs-Prinzip: Design, Ausführung, Logistik

Die wichtigste handwerkliche Regel des Vorgehensmodells lautet: Tätigkeiten werden nicht als Ganzes klassifiziert. Jede Tätigkeit wird in ihren Design- und Urteilsanteil, ihren Implementierungs- und Ausführungsanteil und ihren Dokumentations- und Logistikanteil zerlegt. Erst auf dieser Anteilsebene wird entschieden, was Automatisierungskandidat ist und was beim Menschen bleibt.

Begriffsdisziplin: Overload heißt nicht unnötige Arbeit

Als Overload bezeichnet das Modell den automatisierbaren Ausführungs- und Logistikanteil einer Tätigkeit. Das ist keine Wertung. Normativ geforderte Tätigkeiten wie Statusberichte, Backup-Verifikation oder Modifikationskontrolle sind Prozesswert, klassifiziert wird ausschließlich ihr mechanischer Anteil. Ein Beispiel aus der Traceability: Die inhaltliche Konsistenz-Entscheidung, dass eine Anforderung durch bestimmte Verifikationsmaßnahmen abgedeckt ist, gehört zu K2 und K3. Das Anlegen, Nachziehen und Reparieren der Links nach jeder Änderung ist K4.

Normative Pflicht bestimmt nicht die Klasse

Dass eine Tätigkeit als Base Practice gefordert ist, macht sie nicht automatisch zu Urteilsarbeit. Auch Durchführungs-Base-Practices werden zerlegt. Bei der Unit-Verifikation nach SWE.4.BP3 liegt die Entscheidung, dass und wie verifiziert wird, samt Beurteilung der Ergebnisse im K2/K3-Kern. Die technische Ausführung der Läufe und die Ergebnis-Aufzeichnung sind regelgebundene K4-Anteile, die heute schon weitgehend werkzeuggestützt sind, etwa durch Testrunner und Coverage-Tools. Die Verantwortung bleibt dabei ungeteilt in der Rolle.

Die K3-These: Compliance-Arbeit bleibt und wird leichter

Aus der Zerlegung folgt die zentrale Botschaft des Modells für alle, die Assessments und Audits verantworten. Sie widerspricht sowohl der Angst, AI höhle die Compliance aus, als auch dem Versprechen, AI schaffe die Compliance-Arbeit ab.

„K3 wird nicht wegautomatisiert. Der Ausführungsanteil von K3 wird maschinell vorbereitet. Der Mensch verantwortet Outcome und Evidenz weiterhin namentlich, aber er verbringt seine Zeit mit dem Urteil, nicht mit dem Zusammensuchen der Unterlagen.“

Der Druck hinter dieser These ist real: In der Selbstauskunft-Erhebung von Perforce geben 46 % der befragten Automotive-Teams an (Erhebungsjahr 2025), Schwierigkeiten zu haben, die Einhaltung der ISO 26262 nachzuweisen (Quelle: Perforce, State of Automotive Software Development 2025, Befragten-Selbstauskunft). Zugleich bewerten Assessoren nach der Logik der ISO/IEC-330xx-Reihe die Erreichung der Prozess-Outcomes und die Capability-Attribute; Work Products und Trace-Links sind Indikatoren dafür, kein Selbstzweck. Die bloße Existenz von Links genügt nicht, inhaltliche Konsistenz zählt. Die vollständige Ausarbeitung dieser These, einschließlich des Assessment-Bilds und eines durchgerechneten Traceability-Beispiels, steht im Beitrag K3 wird nicht wegautomatisiert. Wie daraus ein konkretes Vorgehen für die Assessment-Vorbereitung wird, beschreibt die Seite ASPICE-Evidenz und Traceability mit AI.

Vier Wertströme statt Organigramm

Analysiert wird über Wertströme, erzählt über Rollen. Vier Standard-Wertströme strukturieren jedes Automotive-Software-Engineering-Projekt, sie sind zugleich die Begehungs-Einheiten der Analyse. Quer dazu liegen zwei Versorgungsströme: der Evidenz- und Reporting-Strom (VS1) und die Tool-Kette (VS2) aus Requirements-Management, ALM, Versionsverwaltung, Test-Management und HIL/SIL-Umgebungen.

Die Brüche zwischen den Systemen der Tool-Kette sind ein wiederkehrend belegter Aufwandstreiber. Ob sie beim konkreten Haus der größte Treiber sind, ist allerdings Analyse-Ergebnis, keine Vorannahme. Die vier Ströme mit Grenzregeln und Beispiel-Kennzahlen vertieft der Beitrag Die vier Wertströme eines Automotive-SWE-Projekts; die oft unterschätzten Support-Prozesse entlang W2 bis W4 behandelt SUP.8 bis SUP.10 mit AI.

Die Dreifach-Triage: Automatisierung, Augmentation, autonome Fallabwicklung

Für jeden zerlegten Tätigkeits-Anteil wird entschieden, welche Interventionsform überhaupt zulässig ist. Die Triage arbeitet über vier Prüfdimensionen: Wer entscheidet den Einzelfall, verändert das Ergebnis einen freigabepflichtigen Work-Product-Stand, welche Freigabegranularität gilt, und schreibt das System in führende Systeme oder liefert es nur Sichten darauf.

Zwei Abgrenzungen entscheiden die häufigsten Grenzfälle: Erzeugt ein System einen Arbeitsstand, ist es A2 und nicht B, weshalb auch Coding-Assistenz und Trace-Link-Vorschläge A2 sind. Und deterministisch-regelgebundene Abläufe ohne Urteilsspielraum sind A1 und nicht C, denn die aufwendige C-Governance wird nur dort bezahlt, wo ein System tatsächlich Interpretationsspielraum ausübt. Jeder C-Kandidat startet als Prüfkandidat mit Status „nicht zulässig“ und wird erst über einen gemessenen A2-Piloten hochgestuft. Die vollständige Entscheidungslogik mit allen Abgrenzungsregeln steht im Beitrag Welche AI-Klasse welche Engineering-Arbeit tragen darf.

Vor jeder Automatisierung: die Nebenwert-Prüfung

Manche manuelle Arbeit erzeugt stillen Zweitnutzen. Wer Trace-Links von Hand zieht, liest die Anforderung; wer den Statusbericht von Hand baut, sieht die Abweichung zwischen Plan und Realität. Automatisierung, die diesen Nebenwert übersieht, erhöht die formale Quote und senkt die inhaltliche Konsistenz. Deshalb durchläuft jeder Automatisierungskandidat vor der Freigabe eine Nebenwert-Prüfung mit gestalteten Gegenmechaniken, ausgeführt im Beitrag Wenn Automatisierung Verständnis kostet.

Vom Prinzip zur Entscheidung: Rollenkarten, Interviews, Matrix

Das Prinzip wird über einen definierten Analyse-Weg auf ein konkretes Haus angewendet. Startpunkt sind typisierte Rollenkarten für die Rollen im Scope, die Kern, Overload, Begründung, Abhängigkeiten und Triage-Hypothesen je Rolle dokumentieren. ASPICE normiert keine Rollen, deshalb sind die Karten Hypothesen, die in Interviews gegen die Realität des Hauses geprüft werden: bestätigt, gestrichen, ergänzt, umgewichtet.

Der Ablauf in Kürze

Auf die Wertstrom-Begehung anhand realer, abgeschlossener Fälle folgen Rollen-Interviews entlang der Karten, eine interne Voranalyse, in der die Matrix mit zerlegten Tätigkeiten, Klassen-Hypothesen und Source-of-Truth-Angaben entsteht, und Validierungs-Workshops, in denen strittige und hoch priorisierte Einträge bereichsübergreifend entschieden werden. Erst danach werden priorisierte Einträge zu übergabefähigen Backlog-Kandidaten ausgearbeitet. Wie die Rollenkarten aufgebaut sind, zeigt Rollenkarten statt Stellenbeschreibungen; den Weg vom Matrix-Eintrag zum umsetzbaren Baustein beschreibt Von der Entscheidungsmatrix zum Backlog.

Zusagen an die Belegschaft, nicht nur an das Management

Die Analyse bewertet Prozesse und Tätigkeiten, keine Personen. Kennzahlen werden ausschließlich auf Wertstrom- und Prozess-Ebene erhoben, Entwickler-Telemetrie aus Git, Ticket-System oder Test-Management ist tabu, auch wenn die Tool-Kette sie hergäbe. Bei weniger als fünf vergleichbaren Rolleninhabern wird jeder Befund automatisch auf Prozess-Ebene aggregiert berichtet, und jede Berichtsfassung durchläuft vor Auslieferung eine Identifizierbarkeitsprüfung. Grundlage jeder Erhebung ist eine Audit-Charter unter Einbindung des Betriebsrats. Wer diesen Weg als strukturiertes Angebot gehen will, findet die Beschreibung auf der Seite Wertbeitrags-Audit für Automotive Software Engineering.

Grenzen: was dieses Vorgehensmodell nicht verspricht

Ein Vorgehensmodell, das Vertrauen verdienen will, benennt seine Grenzen selbst und wartet damit nicht auf kritische Nachfragen. Fünf Punkte gehören zu jeder ehrlichen Darstellung des Wertbeitrags-Prinzips, und sie werden in jedem Gespräch offengelegt, bevor über einen Einsatz entschieden wird.

Erstens sind die Rollenkarten typisiert und nicht normativ; beim konkreten Haus können die Rollenschnitte völlig anders liegen, das Kundenbild entsteht erst in Interviews und Validierung. Zweitens gibt es keinen belastbaren Overload-Prozentwert je Rolle. Verfügbare Zahlen wie die Tätigkeitsverteilung aus IDC-Erhebungen oder die Perforce-Selbstauskunft sind Größenordnungs-Belege aus anderen Kontexten, und eine Tätigkeitsverteilung ist kein Verschwendungsmaß. Wer fragt, wie viel Prozent sich sparen lassen, bekommt die Analyse als Antwort, keine erfundene Zahl. Drittens stammen die verfügbaren AI-Wirkbelege überwiegend aus generischen Entwicklungs-Kontexten oder betreffen vorbereitende Generierung; die Übertragung auf safety-kritische Automotive-Arbeit ist plausibel, wird aber je Baustein im Piloten nachgewiesen. Viertens sind Safety- und Rechts-Einordnungen des Modells Arbeitshypothesen, die vor dem Einsatz von den zuständigen Rollen bestätigt werden, vom Safety-Verantwortlichen bis zum Datenschutz, einschließlich der laufend aktuell zu haltenden Einordnung zur EU-AI-Verordnung. Und fünftens ist das Modell ein junger Stand: Es hat einen mehrstufigen, dokumentierten Review-Prozess mit unabhängiger Gegenprüfung über sechs Runden durchlaufen und den Konsens-Stand erreicht, steht aber vor seiner ersten Kundenanwendung. Wir nennen es deshalb unser Vorgehensmodell und nicht eine hundertfach erprobte Methode.

Nächste Schritte

Wer das Prinzip auf das eigene Haus anwenden will, hat zwei naheliegende Einstiege. Der strukturierte Weg ist das Wertbeitrags-Audit, mit dem sensified das Vorgehensmodell auf ein konkretes Haus instanziiert: Wertstrom-Begehung, Rollen-Interviews, validierte Entscheidungsmatrix und übergabefähige Backlog-Einträge, mit klaren Compliance-Zusagen an die Belegschaft. Wer vom akuten Assessment-Schmerz kommt, findet auf der Seite ASPICE-Evidenz und Traceability mit AI den Einstieg über die Evidenz-Arbeit.

Den größeren Rahmen, wie aus einzelnen Bausteinen eine beherrschte, auditierbare AI-Engineering-Capability wird, beschreibt die Seite AI-Transformation im Automotive-Engineering.

Für die fachliche Vertiefung einzelner Aspekte stehen die Beiträge dieses Clusters bereit: die K3-These, die Wertströme, die Triage-Klassen, die Rollenkarten, die Rollen-Tiefenblicke zu SWE.1 und SWE.4 bis SWE.6, die Support-Prozesse, die Nebenwert-Prüfung und die Entscheidungsmatrix.

Häufige Fragen

Was ist das Wertbeitrags-Prinzip im Automotive Software Engineering?

Ein Vorgehensmodell, das vor jeder AI-Einführung klärt, welche Arbeit welcher Natur in den Rollen eines ASPICE-Projekts steckt. Tätigkeiten werden in vier Klassen eingeordnet, in Urteils-, Ausführungs- und Logistikanteile zerlegt und über eine Dreifach-Triage bewertet. Ergebnis ist eine versionierte Entscheidungsmatrix, die Hebel vergleichbar macht, bevor Budget an einzelne Use-Cases gebunden wird.

Welche Tätigkeiten kann AI im ASPICE-Umfeld übernehmen?

Regelgebundene Betriebsarbeit wie Synchronisation über Tool-Brüche, Status-Aggregation oder Testumgebungs-Provisionierung kann nach Prüfung im Hintergrund laufen. Entwurfsarbeit wie Trace-Link-Vorschläge, Testfall-Entwürfe oder Review-Vorbefunde wird maschinell vorbereitet und je Einzelfall von einem Menschen übernommen. Für Urteile liefert AI Sichten und Dossiers als Entscheidungsgrundlage.

Was wird bewusst nicht automatisiert?

Ergebnis- und Beziehungsarbeit wie die technische Verhandlung mit dem OEM sowie Urteilsarbeit wie Architektur-Entscheidungen, Test-Design, Ursachenanalyse und alle Freigaben. Auch der Urteilsanteil der Compliance-Arbeit bleibt namentlich beim Menschen: Review-Urteil, Baseline-Freigabe und CCB-Entscheid werden vorbereitet, aber nie maschinell getroffen.

Wie unterscheidet sich das Vorgehen von einer Tool-Einführung?

Eine Tool-Einführung beginnt beim Werkzeug und sucht Anwendungsfälle. Das Wertbeitrags-Prinzip beginnt bei der Arbeit: Erst wird je Rolle und Wertstrom geklärt, welche Anteile automatisierbar sind und welche Nebenwerte dabei erhalten bleiben müssen, dann erst wird über konkrete Bausteine und deren Werkzeuge entschieden. Die Reihenfolge schützt vor lokal optimierten Einzellösungen.

Woher wissen wir, wo wir anfangen sollen?

Aus der validierten Entscheidungsmatrix. Sie entsteht in einer strukturierten Analyse aus Wertstrom-Begehung, Rollen-Interviews, interner Voranalyse und Validierungs-Workshops und weist je Eintrag Klasse, Triage-Ergebnis, Schadensklasse und führendes System aus. Priorisiert wird gemeinsam im Workshop, auf Basis vergleichbarer Einträge statt einzelner Zurufe.

Ersetzt AI Entwickler im Automotive Software Engineering?

Nach diesem Modell nicht. Die Klassen K1 und K2, also Verhandlung, Führung, Architektur, Analyse und Test-Design, bleiben Menschenarbeit. Automatisiert werden Ausführungs- und Logistikanteile, die heute Engineering-Zeit binden. Ehrlich ist auch: Einen belastbaren Prozentwert, wie viel Kapazität das je Rolle freisetzt, gibt es vorab nicht, das ist Ergebnis der Analyse.

Was bedeutet das Modell für ISO 26262 und Safety-Software?

Bausteine, die Work Products safety-relevanter Software erzeugen oder prüfen, durchlaufen eine Tool-Confidence-Vorprüfung je Verwendungsfall und Fehlermodus. Die Einstufung bestätigt der Safety-Verantwortliche des Hauses, bis dahin gilt sie als offene Annahme mit Owner und Frist. Kein Baustein darf Evidenzketten unterbrechen, jeder protokolliert nachvollziehbar, damit die Prozess-Evidenz assessierbar bleibt.

Wie startet man mit dem Wertbeitrags-Prinzip?

Mit einem abgegrenzten Analyse-Schritt statt einem Plattform-Projekt: Scope festlegen, Audit-Charter mit Betriebsrats-Einbindung aufsetzen, Wertströme begehen, Rollen interviewen, Matrix validieren. Das Wertbeitrags-Audit bündelt diesen Weg als definiertes Vorgehen mit versionierter Matrix und übergabefähigen Backlog-Einträgen als Ergebnis.

Hinweis zu AI-Inhalten gemäß EU AI Act Art. 50: Texte auf dieser Seite wurden teilweise mit Unterstützung Künstlicher Intelligenz erstellt.

Den strategischen Rahmen erklärt der Beitrag AI im Engineering ist ein Capability-Thema, kein Tool-Thema.