Von der Entscheidungsmatrix zum AI-Backlog im Engineering

Von der Entscheidungsmatrix zum Backlog: wie aus der AI-Analyse umsetzbare Bausteine werden

Die Entscheidungsmatrix ist das Arbeitsartefakt, das eine AI-Analyse im Automotive Software Engineering umsetzbar macht: eine versionierte Tabelle, in der jeder Eintrag genau einen Tätigkeits-Anteil mit genau einer Tätigkeitsklasse und einer Triage-Klasse beschreibt. Vor jedem Klassen-Vorschlag ist die Source-of-Truth-Angabe Pflicht, ausgefüllt wird zweistufig, und übergeben wird mit stabiler Kennung, die als Audit-ID die Nachvollziehbarkeit bis in den Betrieb trägt.

Viele AI-Analysen im Engineering enden als Foliensatz: eine Liste vielversprechender Anwendungsfälle, der die Angaben fehlen, um daraus Aufträge zu machen. Dieser Beitrag beschreibt das Gegenstück, die kundenspezifische Klassifikations- und Entscheidungsmatrix aus unserem Vorgehensmodell. Er vertieft ein Kapitel des Leitfadens zum Wertbeitrags-Prinzip im Automotive Software Engineering und richtet sich an Engineering-Leitung, Prozessverantwortliche und alle, die aus einer AI-Bestandsaufnahme ein belastbares Backlog machen müssen.

Atomare Einträge: ein Anteil, eine Klasse, eine Zeile

Die wichtigste Regel der Matrix im Vorgehensmodell von sensified ist die Zeilenregel. Ein Eintrag beschreibt genau einen Tätigkeits-Anteil nach der Zerlegung in Urteils-, Ausführungs- und Logistikanteile, mit genau einer Tätigkeitsklasse und genau einer Triage-Klasse. Eine Tätigkeit wie „Trace-Links pflegen“ wird also nie als Ganzes klassifiziert: Das inhaltliche Konsistenz-Urteil ist ein Anteil, die Link-Mechanik nach jeder Änderung ein anderer, und beide bekommen eigene Zeilen mit eigener Einordnung.

Zusammengehörige Anteile werden über eine gemeinsame Parent-ID gruppiert; aus einem Eintrag wie AUTO-W1-014 werden die Anteile AUTO-W1-014.1, .2 und .3. Das klingt nach Verwaltungsaufwand und ist das Gegenteil: Erst atomare Einträge machen Kandidaten vergleichbar, verhindern Sammel-Zeilen, in denen sich Urteils- und Ausführungsarbeit vermischen, und erlauben es, einen Anteil umzusetzen, während ein anderer bewusst beim Menschen bleibt. Die Klassen-Logik dahinter beschreibt der Beitrag zur Triage von Automatisierung, Augmentation und autonomer Fallabwicklung.

„Ein Eintrag, ein Tätigkeits-Anteil, eine Klasse. Sammel-Zeilen sind der häufigste Grund, warum AI-Backlogs im Engineering nicht umsetzbar sind.“

Die Source-of-Truth-Pflicht: keine Triage ohne Systembild

Bevor für einen Eintrag eine Triage-Klasse vorgeschlagen werden darf, müssen drei Angaben vorliegen: das führende System des betroffenen Artefakts, die Lese- oder Schreibwirkung des angedachten Bausteins und die Lage des Commit-Punkts, also die Stelle, an der ein Arbeitsstand verbindlich wird, samt Rückholweg. Ohne diese Angaben ist kein Vorschlag für die Klassen A1, A2, B oder C zulässig.

Der Grund ist praktisch: Dieselbe Idee kann je nach Systembild harmlos oder riskant sein. Ein Baustein, der Sichten auf das Application-Lifecycle-Management (ALM) liest, ist anders zu behandeln als einer, der in das führende Requirements-Management-System (RM) schreibt. Wer die Triage vor der Source-of-Truth-Klärung durchführt, klassifiziert Vermutungen.

Zweistufiges Ausfüllen: Voranalyse und Härtungsfelder

Die Matrix wird bei sensified in zwei Stufen gefüllt, und die Reihenfolge ist Absicht. In Stufe 1, der internen Voranalyse, werden für alle Einträge die Basisfelder erhoben: Wertstrom und Station, beteiligte Rollen, der zerlegte Tätigkeits-Anteil, Tätigkeitsklasse und Triage-Vorschlag, Befund-Provenienz, Häufigkeits-Bandbreite, Schadensklasse und die Source-of-Truth-Angaben. Auf dieser Grundlage entstehen ein Priorisierungs-Vorschlag und eine Konfliktliste der strittigen Einträge.

Stufe 2 folgt erst nach der Priorisierung in den Validierungs-Workshops, und nur für die priorisierten Kandidaten: Betriebsmodell-Felder, der Nebenwert-Status, Abhängigkeiten, offene Annahmen mit Owner und Frist sowie der Initialstand der technischen Evidenzstufen. Nicht priorisierte Einträge bleiben als dokumentierte Stufe-1-Hypothesen erhalten. So fließt Ausarbeitungs-Aufwand nur in Kandidaten, die ihn verdient haben, und die Workshops entscheiden über Prioritäten, statt fertige Detailplanungen abzunicken.

Validierung: Schweigen gilt nicht als Bestätigung

Zwischen den beiden Stufen liegt die Validierung. In den Workshops werden nur die strittigen und hoch priorisierten Einträge behandelt; dort fällt die verbindliche Priorisierungs-Entscheidung, und Abweichungen wie Minderheitspositionen werden protokolliert. Unstrittige Einträge gehen in einen Umlauf mit benanntem Owner, fester Frist und definierter Mindestantwortquote. Dabei gilt eine Regel, die unscheinbar wirkt und die Qualität der Matrix trägt: Schweigen gilt nicht als Bestätigung. Unbeantwortete Einträge behalten den Status Hypothese und werden im Bericht als solche ausgewiesen. So kann später niemand behaupten, ein Eintrag sei validiert, nur weil niemand widersprochen hat; der Status jedes Eintrags, Hypothese, validiert, verworfen oder übergeben, bleibt jederzeit ablesbar.

Befund-Provenienz und Schadensklasse

Zwei Stufe-1-Felder verdienen besondere Erwähnung, weil sie über die Belastbarkeit der Matrix entscheiden. Die Befund-Provenienz hält je Eintrag fest, woher der Befund stammt: Interview, beobachteter Fall oder Einsicht in ein Work Product, mit Referenz und der Zahl bestätigender Quellen einschließlich etwaiger Gegenbelege. Ein Eintrag, den drei Rollen unabhängig bestätigen, trägt anders als eine Einzelmeinung. Die Schadensklasse beantwortet die Frage, was ein unentdeckter Fehler des Bausteins anrichten würde: intern korrigierbar, Work-Product-relevant oder liefer- beziehungsweise safety-relevant. Sie steuert später, welche Absicherung ein Kandidat in der Härtung nachweisen muss.

E-Stufen als Initialstand: was das Audit prüft und was nicht

Für jeden Eintrag wird der Stand der technischen Evidenz dokumentiert, etwa ob die benötigte Schnittstelle eines Werkzeugs schon produktiv genutzt wird oder ob ihre Eignung ungeprüft ist. Wichtig ist die Grenzziehung: Das Audit erhebt nur diesen Initialstand, in der Regel „ungeprüft“ oder vorhandene Nachweise des Kunden. Die tatsächliche technische Prüfung und die Anhebung der Evidenzstufen ist ausschließlich Aufgabe der anschließenden Backlog-Härtung, einschließlich Testzugängen und technischer Probestellungen.

Diese Trennung schützt beide Seiten: Das Audit-Budget wird nicht mit technischen Prüfungen belastet, die ein eigenes Setup brauchen, und die Härtung übernimmt keine ungeprüften Annahmen, weil jeder Eintrag seinen Evidenz-Initialstand offen ausweist. Erhoben werden die Angaben unter anderem in den Interviews entlang der Rollenkarten je ASPICE-Rolle und im Gespräch mit der Tool- und ALM-Administration, die die realen Schnittstellen-Fähigkeiten der Kette kennt. Dass diese Nachweisarbeit die Branche insgesamt fordert, belegt eine Befragung: 46 % der Automotive-Teams geben laut Perforce-Befragung 2025 an, dass ihnen der Konformitätsnachweis nach ISO 26262 schwerfällt (Quelle: Perforce, State of Automotive Software Development 2025).

Übergabe mit Audit-ID: die Kette reißt nicht

Am Ende werden bei sensified ausschließlich ausgearbeitete Stufe-2-Einträge an die Backlog-Härtung übergeben. Jeder übergebene Eintrag trägt seine Matrix-ID, Triage-Klasse, Schadensklasse, Provenienz, den Evidenz-Initialstand und die offenen Annahmen mit Owner und Frist. Die Matrix-ID wird dabei zur Audit-ID einer durchgehenden Nachvollziehbarkeits-Kette: vom Interview-Befund über den Matrix-Eintrag bis zu Anforderungsdokument und Architektur-Entscheidung des späteren Bausteins.

Das ist mehr als Ordnungsliebe. In einer Domäne, in der Assessments nach Automotive SPICE und Safety-Audits Nachvollziehbarkeit verlangen, muss auch die AI-Einführung selbst nachvollziehbar sein: Warum wurde dieser Baustein gebaut, worauf stützt sich die Einordnung, wer hat welche Annahme bis wann zu klären. Ein Backlog ohne diese Herkunfts-Kette ist eine Wunschliste; erst die dokumentierte Kette schafft Vertrauen bei Assessoren, Betriebsrat und Fachrollen. AI assistiert, der Mensch verantwortet, und die Matrix dokumentiert, wer was verantwortet.

Nächste Schritte

Die Entscheidungsmatrix ist der Übergabepunkt zwischen Analyse und Umsetzung. Wie die Einträge entstehen, von der Wertstrom-Begehung über die Rollen-Interviews bis zu den Validierungs-Workshops, ordnet der Leitfaden zum Wertbeitrags-Prinzip im Automotive Software Engineering; sensified führt die Voranalyse intern durch und validiert sie gemeinsam mit den Fachrollen des Kunden.

Wer den Weg zur eigenen, validierten Matrix gehen will, findet den Ablauf im Wertbeitrags-Audit für Automotive Software Engineering: Ergebnis sind eine versionierte Matrix, eine begründete Triage und übergabefähige Backlog-Einträge. Der Einstieg ist ein Qualifying-Call, den Sie über die Audit-Seite als Termin buchen können.

Häufige Fragen

Was ist eine Entscheidungsmatrix in der AI-Analyse?

Eine versionierte Tabelle, die alle AI-Kandidaten eines Engineering-Projekts vergleichbar macht. Jede Zeile beschreibt einen Tätigkeits-Anteil mit Tätigkeitsklasse, Triage-Klasse, Befund-Provenienz, Schadensklasse und Source-of-Truth-Angaben. Sie entsteht aus Wertstrom-Begehung und Rollen-Interviews, wird in Workshops validiert und ist die Grundlage für die Übergabe priorisierter Kandidaten an die Backlog-Härtung.

Warum müssen Matrix-Einträge atomar sein?

Weil Sammel-Einträge Urteils- und Ausführungsarbeit vermischen und damit jede saubere Klassen-Zuordnung verhindern. Erst die Zerlegung in Anteile mit je einer Zeile erlaubt es, den mechanischen Anteil einer Tätigkeit zu automatisieren, während das Urteil beim Menschen bleibt. Die Parent-ID hält zusammengehörige Anteile verbunden, sodass der Zusammenhang der ursprünglichen Tätigkeit erhalten bleibt.

Was bedeutet die Source-of-Truth-Pflicht konkret?

Vor jedem Triage-Vorschlag müssen führendes System, Lese- oder Schreibwirkung, Commit-Punkt und Rückholweg des Eintrags dokumentiert sein. Ein Baustein, der nur Sichten liest, ist anders einzuordnen als einer, der in das führende System schreibt. Ohne diese Angaben bleibt jede Klassen-Zuordnung eine Vermutung, deshalb ist das Feld in Stufe 1 verpflichtend, nicht optional.

Prüft das Audit die technische Machbarkeit der Bausteine?

Nein. Das Audit erhebt nur den Initialstand der technischen Evidenz, etwa vorhandene Schnittstellen-Nachweise des Kunden oder den Status „ungeprüft“. Die tatsächliche Prüfung, einschließlich Testzugängen und technischer Probestellungen, ist Aufgabe der anschließenden Backlog-Härtung. Diese Trennung hält das Audit fokussiert und stellt sicher, dass keine ungeprüfte Annahme unbemerkt in die Umsetzung wandert.

Was passiert mit nicht priorisierten Einträgen?

Sie bleiben als dokumentierte Stufe-1-Hypothesen in der Matrix erhalten, mit allen Basisfeldern, aber ohne Härtungs-Ausarbeitung. Damit gehen sie nicht verloren: Bei der nächsten Priorisierungsrunde oder veränderter Projektlage können sie wieder aufgenommen werden, ohne dass die Erhebung wiederholt werden muss. Übergeben an die Backlog-Härtung werden ausschließlich die ausgearbeiteten Stufe-2-Einträge.

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.