Wertströme im Automotive-SWE-Projekt: wo AI Aufwand nimmt
Die vier Wertströme eines Automotive-SWE-Projekts und wo AI je Strom Aufwand nimmt
Ein Automotive-Softwareprojekt nach Automotive SPICE (ASPICE) lässt sich über vier Wertströme beschreiben: W1 von der freigegebenen Systemanforderung zur verifizierten Software, W2 für den Change-Request-Durchlauf, W3 für den Defect-Lifecycle und W4 für den Baseline- und Release-Strom. Wer Künstliche Intelligenz (AI) im Engineering-Prozess einsetzen will, analysiert zuerst diese Ströme. Dort wird sichtbar, welcher Aufwand strukturell entsteht und welcher Anteil davon maschinell vorbereitet werden kann.
Wenn Engineering-Leitungen über AI sprechen, beginnt das Gespräch häufig bei einzelnen Anwendungsfällen: Testautomatisierung, Anforderungs-Prüfung, Coding-Assistenz. Dieser Beitrag schlägt eine andere Reihenfolge vor. Bevor über Werkzeuge entschieden wird, lohnt der Blick auf die Wertströme, in denen die Arbeit eines Software-Engineering-Projekts (SWE-Projekts) tatsächlich fließt. Er vertieft ein Kapitel des Leitfadens zum Wertbeitrags-Prinzip im Automotive Software Engineering und richtet sich an Engineering-Leitung, Prozessverantwortliche und Qualitätssicherung bei Zulieferern und Engineering-Dienstleistern.
Warum Wertströme die richtige Analyseeinheit sind
Use-Case-Diskussionen ohne ein Bild der Wertströme optimieren lokal: Der lauteste Schmerz gewinnt, der größte Hebel bleibt unsichtbar. Erst die Wertstrom-Betrachtung macht Aufwände über Rollen und Prozesse hinweg vergleichbar, bevor Budget an einzelne Anwendungsfälle gebunden wird. Deshalb gilt im Vorgehensmodell von sensified eine feste Reihenfolge: analysiert wird über Wertströme, erzählt und erhoben wird über Rollen.
Der zweite Grund ist die Evidenzpflicht der Domäne. Jede AI-Intervention berührt Work Products, die in Assessments und Safety-Audits bestehen müssen. Ohne vorherige Einordnung, was Urteils-Kern ist, was normative Pflicht und was automatisierbarer Ausführungsanteil, wird versehentlich Compliance-Substanz angetastet. Das ist eines der teuersten Anti-Pattern dieser Domäne, weil es Downrating- und Nacharbeits-Risiken in Assessments erzeugt.
„Der lauteste Schmerz gewinnt, nicht der größte Hebel. Die Wertstrom-Betrachtung macht Hebel vergleichbar, bevor Budget an Einzel-Use-Cases gebunden wird.“
Die vier Wertströme im Überblick
Die vier Standard-Wertströme eines Automotive-SWE-Projekts folgen den Prozessen des ASPICE-Referenzmodells: den Engineering-Prozessen SWE.1 bis SWE.6, den Support-Prozessen (SUP) für Änderungen, Probleme und Konfigurationsmanagement sowie dem Projektmanagement (MAN.3). Die Tabelle zeigt je Strom die Strecke, die beteiligten Prozesse und Beispiel-Kennzahlen, so wie sensified sie im Audit als Analyseraster nutzt. Die Kennzahlen sind bewusst Beispiele: Welche Größen ein konkretes Projekt misst, wird kundenindividuell festgelegt.
| Wertstrom | Strecke | Beteiligte Prozesse | Beispiel-Kennzahlen (kundenindividuell zu wählen) |
|---|---|---|---|
| W1 Anforderung zu verifizierter Software | freigegebene System-/Stakeholder-Anforderung, dann SW-Requirement, Architektur, Design und Unit, Verifikation | SWE.1 bis SWE.6, Eingangsschnittstelle SYS.2/SYS.3 | Durchlaufzeit von der Anforderung bis zum Verifikationsnachweis, Anteil der Reviews ohne Nacharbeit, Verifikations-Abdeckung je Release |
| W2 Change-Request-Durchlauf | CR-Eingang, Analyse und Impact, Change Control Board (CCB), Umsetzung, Bestätigung, Closure | SUP.10 quer über SWE.1 bis 6, MAN.3 | CR-Durchlaufzeit, Impact-Analyse-Aufwand je CR, Anteil der CRs mit vollständiger Traceability bei Closure |
| W3 Defect-Lifecycle | Problem-Meldung, Analyse und Ursache, gegebenenfalls CR, Lösung, Closure, Trend | SUP.9, SWE.4 bis 6, SUP.10 | Time-to-Analyze, Time-to-Close, Reopen-Quote, Latenz der Trend-Berichte |
| W4 Baseline- und Release-Strom | Identifikation der Configuration Items, Änderungskontrolle, Baseline, Vollständigkeits- und Konsistenzprüfung, Lieferung | SUP.8, MAN.3, SWE.5/6 | Baseline-Erstellungsaufwand, Anteil der Baseline-Findings, Release-Vorbereitungszeit |
Ein Change Request (CR) ist dabei die formale Änderungsanforderung, eine Baseline der eingefrorene, referenzierbare Stand aller Configuration Items (CIs) zu einem definierten Zeitpunkt.

Die W1-Grenzregel: der Übergabepunkt aus dem System-Engineering
W1 beginnt bewusst erst am Übergabepunkt der freigegebenen Systemanforderung beziehungsweise Systemarchitektur. Die Qualität und Stabilität dieses Inputs gehört bei Tier-1- und Tier-2-Projekten zu den großen Aufwandstreibern der SWE.1-Arbeit; das ist als Hypothese formuliert und wird je Kunde geprüft. Die System-Seite (SYS.2/SYS.3) wird über eine Schnittstellen-Erhebung mit betrachtet, aber in diesem Scope weder bewertet noch umgebaut. Diese Grenzziehung schützt vor einem verbreiteten Fehler: Software-seitige Automatisierung soll keine system-seitigen Qualitätsprobleme kaschieren.
Ein realer Fall je Strom als Begehungs-Einheit
In der Analysephase wird jeder Wertstrom anhand eines realen, abgeschlossenen Falls begangen: ein Requirement bis zum Verifikationsnachweis, ein CR, ein Defect, eine Baseline. Das Ergebnis sind Wertstrom-Karten des Ist-Zustands mit der tatsächlichen Tool-Kette und ihren Bruchstellen. Der Unterschied zu einer Prozess-Landkarte aus dem Qualitätsmanagement-Handbuch: Die Begehung zeigt, wie die Arbeit wirklich läuft, nicht wie sie dokumentiert ist.
VS1 und VS2: die zwei Versorgungsströme
Quer zu den vier Wertströmen liegen zwei Versorgungsströme, die keine eigenen Wertströme sind, aber in fast jeder Rolle als Abhängigkeit auftauchen. VS1 ist der Evidenz- und Reporting-Strom: Qualitätssicherungs-Berichte nach SUP.1, Statusberichte nach MAN.3 und die Assessment-Vorbereitung konsumieren laufend Daten aus W1 bis W4.
Wie stark diese Nachweisarbeit die Branche beschäftigt, zeigt eine Branchenbefragung: 46 % der Automotive-Teams geben laut Perforce-Befragung 2025 an, dass ihnen der Nachweis der Konformität mit ISO 26262 schwerfällt (Quelle: Perforce, State of Automotive Software Development 2025). Die Zahl belegt eine Größenordnung in der Branche, keinen Wert für ein konkretes Haus.
VS2 ist die Tool-Kette: das Requirements-Management-Werkzeug (RM), das Application-Lifecycle-Management (ALM) mit Ticket-System, die Quellcode-Verwaltung, das Test-Management sowie Hardware-in-the-Loop- und Software-in-the-Loop-Umgebungen (HIL/SIL) mit CI/CD-Pipelines.
Tool-Brüche: belegtes Muster, offene Rangfrage
Die Brüche zwischen diesen Systemen sind ein wiederkehrend belegter Aufwandstreiber: Anforderungen werden zwischen Kunden-RM und eigenem RM übertragen, Trace-Links nach jeder Änderung nachgezogen, Statusdaten für Berichte aus mehreren Systemen von Hand eingesammelt. Hier ist Präzision wichtig. Belegt ist das Muster. Ob die Tool-Brüche beim konkreten Kunden der größte Treiber sind, ist eine Hypothese, die erst das Audit beantwortet, keine Vorannahme. Wer diese Rangfrage vorab beantwortet, kauft am Bedarf vorbei.
Für die spätere AI-Einordnung liefert VS2 den häufigsten Kandidatentyp: Datenlogistik über Systemgrenzen, die regelgebunden abläuft und deshalb für Hintergrund-Automatisierung infrage kommt. Welche Klasse von AI-Baustein welche Arbeit tragen darf, ordnet der Beitrag zur Triage von Automatisierung, Augmentation und autonomer Fallabwicklung.

Kennzahlen auf Wertstrom-Ebene: die Compliance-Zusage
Alle Kennzahlen der Wertstrom-Betrachtung messen Prozess-Ströme: Durchlaufzeiten, Bestände, Quoten je Wertstrom oder Prozessschritt. Personenbezogene Leistungsdaten sind tabu, auch wenn die Tool-Kette sie technisch hergäbe. Git-, Ticket- und Test-Metriken sind personenbeziehbar und bleiben deshalb außen vor. Das ist zugleich Hygiene im Sinne der AI-Verordnung der EU (kein Beschäftigten-Monitoring) und eine belastbare Verhandlungsgrundlage gegenüber dem Betriebsrat (BR). Diese Messlogik ist bei sensified Teil der Audit-Charter und schafft Vertrauen in die Erhebung.
Dazu gehört eine zweite Zusage: Bei kleinen Rollen-Populationen, in einem 20-Personen-Stream gibt es oft genau einen Konfigurationsmanager, werden Befunde grundsätzlich auf Prozess- oder Wertstrom-Ebene aggregiert berichtet. Kennzahlen dienen der Verbesserung der Ströme, nie der Bewertung von Personen. AI assistiert, der Mensch verantwortet; dieser Grundsatz gilt auch für die Messlogik.
Vom Wertstrom-Bild zur Entscheidungsmatrix
Die Wertstrom-Begehung ist der erste Schritt einer längeren Kette. Auf sie folgen Rollen-Interviews entlang typisierter Rollenkarten für die ASPICE-Rollen, dann die Voranalyse und Validierung in einer versionierten Entscheidungsmatrix, die Kandidaten backlog-fähig macht. Erst danach wird über konkrete Anwendungsfälle gesprochen. Kommt ein Team mit einem fertigen Wunsch, etwa Testautomatisierung, wird der Wunsch als Hypothese in die Voranalyse eingeordnet: nicht abgewiesen, aber auch nicht an der Analyse vorbei beauftragt.
Ehrlich bleibt dabei eine Grenze: Es gibt keinen belastbaren Prozentwert, wie viel Aufwand AI je Wertstrom nimmt. Verfügbare Branchenzahlen sind Größenordnungs-Belege aus anderen Kontexten. Wer nach der Einsparquote fragt, bekommt die Audit-Antwort, keine erfundene Zahl.
Nächste Schritte
Die Wertstrom-Betrachtung ist ein Baustein des übergeordneten Vorgehensmodells. Die Gesamtlogik mit den Tätigkeitsklassen, der Triage und dem Weg ins Backlog ordnet der Leitfaden zum Wertbeitrags-Prinzip im Automotive Software Engineering. Wie die Begehung der Ströme W1 bis W4 beim Kunden konkret abläuft, von der Audit-Charter über die Rollen-Interviews bis zur validierten Matrix, zeigt das Wertbeitrags-Audit für Automotive Software Engineering. sensified begleitet Engineering-Organisationen auf diesem Weg.
Der Einstieg ist ein Qualifying-Call, in dem beide Seiten prüfen, ob Aufgabenstellung und Vorgehensmodell zusammenpassen. Sie können dieses Gespräch direkt als Termin buchen; die Audit-Seite beschreibt Ablauf, Beteiligte und Ergebnisse.
Häufige Fragen
Was ist ein Wertstrom im Automotive Software Engineering?
Ein Wertstrom ist die durchgängige Strecke, auf der ein Arbeitsgegenstand durch das Projekt fließt: eine Anforderung bis zur verifizierten Software (W1), ein Change Request bis zur Closure (W2), ein Defect bis zur Lösung (W3) oder eine Baseline bis zur Lieferung (W4). Die Betrachtung macht Aufwände über Rollen- und Prozessgrenzen hinweg sichtbar und vergleichbar.
Warum beginnt W1 erst an der freigegebenen Systemanforderung?
Weil der Scope der Analyse die Software-Seite ist. Qualität und Stabilität des System-Inputs gehören zu den großen externen Aufwandstreibern der Anforderungsarbeit, das wird über eine Schnittstellen-Erhebung mit aufgenommen. Bewertet oder umgebaut wird die System-Seite dabei aber nicht. Die Grenzregel verhindert, dass software-seitige Automatisierung system-seitige Probleme verdeckt.
Sind die Beispiel-Kennzahlen verbindliche Zielwerte?
Nein. Die Tabelle nennt Beispiel-Größen wie Durchlaufzeiten, Reopen-Quoten oder Baseline-Aufwände, die sich in vielen Projekten bewährt haben. Welche Kennzahlen ein konkretes Projekt misst, wird kundenindividuell festgelegt, mit definierter Datenquelle und Messmethode. Zielwerte entstehen erst aus der eigenen Baseline, nie aus Branchenvergleichen ohne Kontext.
Sind Tool-Brüche wirklich der größte Aufwandstreiber?
Das Muster ist wiederkehrend belegt: Übertragungen zwischen Systemen, nachgezogene Trace-Links und von Hand eingesammelte Statusdaten erzeugen strukturellen Aufwand. Ob die Tool-Brüche beim konkreten Kunden der größte Treiber sind, bleibt eine Hypothese, die erst die Wertstrom-Begehung und die Rollen-Interviews im Audit beantworten. Diese Rangfrage vorab zu beantworten wäre eine Vorannahme.
Werden mit den Wertstrom-Kennzahlen Mitarbeiter gemessen?
Nein. Alle Kennzahlen messen Prozess-Ströme auf Wertstrom-Ebene: Durchlaufzeiten, Bestände, Quoten. Personenbezogene Leistungsdaten aus Git, Ticket-System oder Test-Werkzeugen werden nicht erhoben. Bei kleinen Rollen-Populationen werden Befunde zusätzlich aggregiert berichtet, damit kein Rückschluss auf Einzelpersonen möglich ist. Diese Zusage ist Teil der Audit-Charter und wird mit dem Betriebsrat abgestimmt.
Wie hängen Wertströme und Rollenkarten zusammen?
Analysiert wird über Wertströme, erhoben wird über Rollen. Die Wertstrom-Begehung zeigt, wo Arbeit fließt und wo sie stockt; die Rollen-Interviews entlang typisierter Rollenkarten zeigen, welche Tätigkeiten diesen Aufwand tragen und wovon sie abhängen. Beide Sichten laufen in derselben Entscheidungsmatrix zusammen, die Kandidaten für AI-Bausteine vergleichbar macht.
Wie dieser Baustein in eine beherrschte Gesamt-Capability passt, zeigt unsere Seite zur AI-Transformation im Automotive-Engineering. Den strategischen Rahmen erklärt der Beitrag AI im Engineering ist ein Capability-Thema, kein Tool-Thema.













































