SUP.8 bis SUP.10 mit AI: Baselines, Defects, Changes

SUP.8 bis SUP.10 mit AI: Baselines, Defects und Change-Boards von der Koordinationslast befreien

Baseline-Schnitt, Problem-Kategorisierung und der Entscheid des Change Control Boards bleiben menschliche Urteile. Maschinell wird die Koordinationslast darunter: Baseline-Kandidaten zusammenstellen, Problem-Dossiers aufbereiten, Impact-Sichten über den Trace-Graph liefern. sensified beschreibt diese Trennung in drei Rollenkarten für SUP.8 bis SUP.10, die im Audit gegen die Realität des jeweiligen Projekts geprüft werden.

Die Support-Prozesse von Automotive SPICE (ASPICE) tragen die Koordination des gesamten Projekts: SUP.8 Configuration Management, SUP.9 Problem Resolution Management und SUP.10 Change Request Management. In vielen Projekten werden diese Rollen in Teilzeit oder Personalunion getragen, und genau dort klafft die Lücke zwischen dem, was die Rolle entscheiden soll, und dem, was sie täglich zusammenträgt. Dieser Beitrag zerlegt die drei Rollen entlang unserer Rollenkarten; das Modell mit den Tätigkeitsklassen K1 bis K4 und der Triage erläutert der Grundlagen-Beitrag zum Wertbeitrags-Prinzip im Automotive Software Engineering. Die Karten beschreiben typisierte Rollen und Tätigkeits-Anteile als Hypothesen-Startpunkt, der beim Kunden validiert wird. Sie treffen keine Aussage über Personen.

Drei Rollen, drei Wertströme

Die drei SUP-Rollen sind die Taktgeber von drei der vier Wertströme, über die sensified ein Automotive-SWE-Projekt analysiert: Der Change Manager führt den CR-Durchlauf (W2) vom Eingang über Analyse und Board-Entscheid bis zur Closure. Der Problem-Manager führt den Defect-Lifecycle (W3) von der Meldung über die Ursachen-Analyse bis zum Trend. Der Konfigurationsmanager führt den Baseline- und Release-Strom (W4) bis zur gelieferten, geprüften Baseline.

Alle drei Ströme sind ereignisgetrieben und laufen quer über Fach- und Systemgrenzen; jede Statusänderung erzeugt Nachverfolgungs- und Verlinkungsarbeit in mehreren Systemen. Wie die vier Wertströme insgesamt geschnitten sind, zeigt der Beitrag zu den vier Wertströmen eines Automotive-SWE-Projekts.

Kern und Overload je Rolle: SUP.8, SUP.9, SUP.10

Die Karten von sensified trennen je Rolle das Urteil vom Zusammenbau: Das Vollständigkeits-Urteil, die Ursachen-Analyse und der Board-Entscheid bleiben beim Menschen, die Sammel-, Verpackungs- und Verlinkungsarbeit davor wird maschinell vorbereitet. Jede Zeile der folgenden Tabelle ist eine Hypothese, die im Audit am realen Projekt bestätigt oder verworfen wird:

Der Reason dahinter ist in allen drei Karten derselbe: Die Entscheidungen sind erfahrungsintensive K1- bis K3-Arbeit, ihre Vor- und Nachbereitung skaliert mit dem Volumen an Änderungsanträgen, Problemen und Configuration Items und ist der klassische Fall von vorbereitbarer Koordinationsarbeit über Tool-Brüche hinweg.

Konfigurationsmanager: Baseline-Kandidat maschinell, Freigabe beim Menschen

Für SUP.8 enthält die Rollenkarte von sensified zwei zentrale Bausteine, beide als vorbereitende Automatisierung mit Einzelfall-Prüfpunkt (A2). Erstens die Baseline-Kandidaten-Zusammenstellung: Das System sammelt Configuration Items nach maschinenlesbaren Kriterien ein, prüft Status, verpackt und legt den Kandidaten in einem Staging-Bereich ab; der Konfigurationsmanager prüft und gibt jeden Kandidaten einzeln frei.

Dieser Einzelfall-Commit ist der Grund für die Einordnung: Nach der Vorrangregel unseres Triage-Modells macht ein menschlicher Einzelfall-Commit den Baustein zu A2, unabhängig davon, wie deterministisch die Erzeugung ist. Baseline-Status, und damit die Referenzierbarkeit als Evidenz, entsteht erst durch das Vollständigkeits- und Konsistenz-Urteil des Menschen.

Zweitens die Vollständigkeits- und Konsistenz-Vorprüfung: fehlende Configuration Items, Status-Verstöße und Inkonsistenz-Kandidaten als Befundliste, aus der der Konfigurationsmanager jeden Befund behandelt. Regelgebundene Hintergrund-Automatisierung (A1) ist dagegen die CI-Listen-Synchronisation über die Ablagesysteme, mit der Vorbedingung, dass je CI-Typ ein führendes System definiert ist, sowie Restore-Proben nach versioniertem Proben-Plan, sofern der Kunde diese Verifikationsmethode definiert hat. Das Verifikations-Urteil bleibt auch dort beim Menschen.

Problem-Manager: das Dossier kommt, die Ursachen-Analyse bleibt

Für SUP.9 liegt der stärkste Hebel in der Augmentation (B): das Problem-Dossier je Analyse. Es führt ähnliche historische Probleme, die Änderungshistorie verdächtiger Komponenten und die betroffenen Baselines zu einer abrufbaren Sicht zusammen, rein lesend, ohne einen Arbeitsstand zu erzeugen. Die Ursachen-Analyse selbst bleibt Entscheidungsarbeit der Klasse K2, geführt vom Problem-Manager gemeinsam mit den Fachrollen. Voraussetzung ist eine verknüpft abfragbare Problem-, CR- und Quellcode-Historie, deren Ausbaustufe im Audit je Eintrag geprüft wird.

Um das Dossier herum ordnet die Karte die Eingangslogistik: Die Formalprüfung fehlender Pflichtinformationen mit regelgebundener Nachforderung an den Melder ist A1, Dubletten-Kandidaten per Ähnlichkeitssuche und Kategorisierungs-Vorschläge nach versioniertem Regelwerk sind A2, der Problem-Manager entscheidet jeden Fall. Eine lernende Eingangs-Kategorisierung oder ein lernendes Routing ohne Einzelfall-Prüfung ist dagegen ein C-Prüfkandidat mit Status nicht zulässig, bis unter anderem die Fehlkategorisierungs-Rate je Klasse gegen menschliche Referenz belegt ist, insbesondere bei hoher Schwere. „Ein unbemerkt falsch gerouteter kritischer Defect darf nicht altern.“ Deshalb verlangt schon der Prüfpfad unabhängige Betriebs-Monitore, etwa für Fälle ohne Bearbeitungsfortschritt.

Change Manager: Impact-Sicht über den Trace-Graph, Entscheid im Board

Für SUP.10 benennt die Karte von sensified als stärksten Hebel eine Augmentations-Sicht, wobei der Rang eine Hypothese ist, die am CR-Volumen des Kunden zu prüfen bleibt: die Impact-Sicht je Änderungsantrag (Change Request, CR). Sie zeigt die betroffenen Work Products über den Trace-Graph, abhängige CRs und den historischen Aufwand ähnlicher Anträge, und ersetzt das manuelle Ablaufen des Trace-Graphen vor jeder Impact-Analyse.

Das Impact-Urteil bleibt bei den Fachrollen, die Priorisierungs- und Freigabe-Entscheidung beim Change Control Board (CCB). Vorbedingung ist gepflegte Traceability, weshalb dieser Baustein auf den Automatisierungs-Bausteinen der Engineering-Rollen aufsetzt.

Der Entwurf der Sitzungsunterlagen, also Agenda, Analysen-Zusammenstellung und Abhängigkeits-Graph, ist A2: Die Mappe ist Entscheidungsgrundlage eines Gremiums, ihre Zusammenstellung enthält Auswahl- und Gewichtungsspielraum, deshalb gibt der Change Manager jede Mappe vor Verteilung frei. Status-Kommunikation nach Statuswechsel und die Formalprüfung der CR-Erfassung sind A1; die Link-Mechanik der Traceability ist A1 nur für die Übertragung menschlich benannter Betroffenheiten, jede semantische Neu-Verlinkung bleibt A2. Für den Freigabe-Entscheid selbst kennt die Karte bewusst keinen Kandidaten autonomer Fallabwicklung: CR-Entscheidungen haben Vertrags- und Außenwirkung, und der Gremien-Entscheid ist der Prozesszweck. Wie die Evidenz- und Traceability-Seite dieser Prozesse maschinell vorbereitet wird, vertieft die Seite zu ASPICE-Evidenz und Traceability mit AI.

Warum die Prüfrollen nicht ausgedünnt werden

Ein Querschnitts-Befund der sensified-Karten verdient einen eigenen Absatz: Die SUP-Rollen sind die Prüfpunkt-Lieferanten des Gesamtsystems. Viele Automatisierungs-Bausteine der Engineering-Rollen stützen ihre Sicherheits-Argumentation auf nachgelagerte menschliche Prüfung, und die liegt häufig genau hier, beim Baseline-Urteil des Konfigurationsmanagers und beim Board-Entscheid. Diese Urteils-Kapazität ist ein knappes Gut. Die A- und B-Bausteine dieser Karten spielen sie frei, sie rationalisieren sie nicht weg.

Wer die Prüfrollen ausdünnt, bricht die Argumentation des Gesamtsystems, und zwar an ihrer empfindlichsten Stelle: der Evidenz. Wie schwer der Nachweis in der Breite ohnehin fällt, zeigt eine Selbstauskunfts-Zahl: 46 % der Automotive-Teams fällt der ISO-26262-Nachweis schwer (Quelle: Perforce, 2025). Dazu gehört auch die Compliance-Seite gegenüber der Belegschaft: Status- und Aufwandsdaten sind personenbeziehbar, und SUP-Rollen sind oft einfach besetzt. Alle Kennzahlen unseres Vorgehens sind deshalb auf Wertstrom- und Prozess-Ebene definiert, bei kleinen Rollen-Populationen werden Befunde automatisch aggregiert berichtet.

Nächste Schritte

Ob Baseline-Strom, Defect-Lifecycle oder CR-Durchlauf in Ihrem Projekt die meiste Koordinationslast trägt, ist Audit-Ergebnis, keine Vorannahme. Der Einstieg bei sensified ist ein strukturiertes Audit entlang der Wertströme und Rollenkarten, das die Hypothesen dieser Karten am realen Projekt prüft und die Bausteine nach Wirkung ordnet.

1. Grundlagen lesen: Das Wertbeitrags-Prinzip im Automotive Software Engineering erklärt Tätigkeitsklassen, Wertströme und Triage im Zusammenhang.
2. Audit prüfen: Das Wertbeitrags-Audit für Automotive Software Engineering beschreibt Ablauf, Ergebnisse und Compliance-Leitplanken des Einstiegs.
3. Evidenz-Thema vertiefen: Die Seite ASPICE-Evidenz und Traceability mit AI zeigt, wie Baseline-Vorprüfung, Review-Pakete und Konsistenz-Sichten die Assessment-Vorbereitung tragen.

Häufige Fragen

Die folgenden Antworten fassen die Position von sensified zu den Support-Rollen in SUP.8 bis SUP.10 zusammen. Sie beziehen sich auf typisierte Rollenkarten und Tätigkeits-Anteile; wie die Anteile in einem konkreten Projekt tatsächlich liegen, wird im Audit beim Kunden validiert.

Kann AI eine Baseline automatisch freigeben?

Nein. In der Rollenkarte von sensified ist die Baseline-Kandidaten-Zusammenstellung ein A2-Baustein: Das System sammelt Configuration Items nach Kriterien ein und legt den Kandidaten im Staging-Bereich ab, der Konfigurationsmanager prüft und gibt jeden Kandidaten einzeln frei. Erst dieses Urteil verleiht dem Stand Baseline-Status und macht ihn als Evidenz referenzierbar.

Was ist ein Problem-Dossier und was leistet es?

Ein Problem-Dossier ist eine rein lesende Augmentations-Sicht je Ursachen-Analyse: ähnliche historische Probleme, die Änderungshistorie verdächtiger Komponenten und die betroffenen Baselines, zusammengeführt aus Problem-, CR- und Quellcode-Historie. Es ersetzt das Zusammensuchen, urteilen bleibt Aufgabe des Problem-Managers und der Fachrollen. Voraussetzung ist eine verknüpft abfragbare Datenlage.

Darf AI eingehende Probleme selbst kategorisieren und routen?

Als Vorschlag ja: Kategorisierungs-Vorschläge nach versioniertem Regelwerk und Dubletten-Kandidaten sind A2, der Problem-Manager entscheidet jeden Fall. Eine lernende Kategorisierung oder ein lernendes Routing ohne Einzelfall-Prüfung ist ein C-Prüfkandidat mit Status nicht zulässig, bis Fehlkategorisierungs-Raten gegen menschliche Referenz belegt sind und unabhängige Betriebs-Monitore liegengebliebene Fälle erkennen.

Ersetzt die CR-Impact-Sicht die Impact-Analyse der Fachrollen?

Nein. Die Impact-Sicht zeigt betroffene Work Products über den Trace-Graph, abhängige Änderungsanträge und historische Aufwände ähnlicher Fälle, und ersetzt damit das manuelle Zusammensuchen. Das Impact-Urteil bleibt bei den Fachrollen, die Freigabe-Entscheidung beim Change Control Board. Vorbedingung ist gepflegte Traceability, auf der die Sicht aufsetzt.

Warum gibt es für das CCB keinen Autonomie-Kandidaten?

Weil der Gremien-Entscheid der Prozesszweck von SUP.10 ist. CR-Entscheidungen wirken vertraglich nach außen, ein Fehlentscheid wird erst nach Wirkung sichtbar, und eine unabhängige Laufzeit-Erkennung mit belegter Abdeckung ist dafür nicht konstruierbar. Ein Freigabepunkt, der jede Entscheidung prüft, wäre die Entscheidung selbst. Maschinell wird die Vorbereitung, vom Unterlagen-Entwurf bis zur Status-Kommunikation.

Werden mit diesen Karten einzelne Rolleninhaber bewertet?

Nein. Die Karten beschreiben typisierte Rollen, keine Personen, und gerade bei SUP-Rollen mit oft einfacher Besetzung gelten verschärfte Leitplanken: Kennzahlen ausschließlich auf Wertstrom- und Prozess-Ebene, automatische Aggregation der Befunde bei kleinen Rollen-Populationen und eine Identifizierbarkeitsprüfung jeder Berichtsfassung, bevor sie ausgeliefert wird.

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.