Rollenkarten: AI-Potenzial je ASPICE-Rolle bestimmen

Rollenkarten statt Stellenbeschreibungen: AI-Potenzial je ASPICE-Rolle bestimmen

Eine Rollenkarte beschreibt für eine typisierte Rolle im Automotive Software Engineering, welche Tätigkeiten ihren Wertbeitrags-Kern ausmachen, welcher Ausführungs- und Logistikanteil sie belastet und welche AI-Bausteine dafür infrage kommen. Automotive SPICE (ASPICE) normiert Prozesse, keine Rollen; die Karten sind deshalb Hypothesen-Startpunkte, die im Audit gegen die Realität des jeweiligen Hauses geprüft werden. Sie beschreiben Rollen, nie Personen.

Wenn eine Engineering-Organisation wissen will, wo Künstliche Intelligenz (AI) im Prozess Aufwand nimmt, braucht sie eine Erhebungseinheit, die feiner ist als der Prozess und stabiler als das Organigramm. Genau dafür sind Rollenkarten gebaut. Dieser Beitrag beschreibt ihr Schema, den Überblick über die zwölf Karten von SWE.1 bis MAN.5 und den Anschluss an die Entscheidungsmatrix. Er vertieft ein Kapitel des Leitfadens zum Wertbeitrags-Prinzip im Automotive Software Engineering und richtet sich an Engineering-Leitung, Prozessverantwortliche und Qualitätssicherung.

ASPICE normiert keine Rollen: warum das der Ausgangspunkt ist

Das ASPICE-Referenzmodell definiert Prozesse, Base Practices und Work Products. Eine verbindliche Rollenlandschaft definiert es nicht; die einzige harte Rollen-Vorgabe im betrachteten Scope ist die Unabhängigkeit der Qualitätssicherung nach SUP.1. Wie ein Haus die Prozesse auf Köpfe verteilt, ist seine eigene Entscheidung, und sie fällt überall anders aus. In kleineren Streams werden Support-Rollen häufig in Teilzeit oder Personalunion getragen; der Unit-Test-Ingenieur ist oft dieselbe Person wie der Entwickler.

Daraus folgt die Arbeitsweise der Karten: Sie beschreiben typisierte Industrie-Rollenschnitte, wie sie in Tier-1- und Tier-2-Projekten wiederkehren, ausdrücklich als Hypothese. Beim Kunden dienen sie als Interview-Leitfaden und werden bestätigt, korrigiert, gestrichen oder ergänzt. Die Karte ist Startpunkt mit Belegen, nie Behauptung über das konkrete Haus.

„Die Rollenkarte ist ein Hypothesen-Startpunkt mit Belegen, nie eine Behauptung über den konkreten Kunden.“

Das Schema: was jede Rollenkarte enthält

Alle zwölf Karten im Karten-Satz von sensified folgen demselben Schema mit sieben Feldern, vom Prozess-Anker bis zur Triage. Das macht die Erhebung über alle Interviews hinweg vergleichbar und die spätere Entscheidungsmatrix konsistent, unabhängig davon, welche Rolle gerade befragt wird und wie das Haus seine Rollenschnitte gezogen hat.

Zwei Begriffe verdienen Präzision. „Overload“ meint den automatisierbaren Ausführungs- und Logistikanteil einer Tätigkeit nach Zerlegung, ausdrücklich keine unnötige Arbeit: Auch normativ geforderte Tätigkeiten wie Statusberichte sind Prozesswert, klassifiziert wird nur ihr mechanischer Anteil. Und die Triage-Klassen folgen der Logik, die der Beitrag zur Triage von Automatisierung, Augmentation und autonomer Fallabwicklung im Detail beschreibt.

Die zwölf Rollenkarten im Überblick

Der typisierte Karten-Satz von sensified deckt die Engineering-Prozesse SWE.1 bis SWE.6, die Support-Prozesse SUP.1, SUP.8, SUP.9 und SUP.10 sowie das Projekt- und Risikomanagement MAN.3 und MAN.5 ab. Die Tabelle zeigt je Karte den typischen Kern, der beim Menschen bleibt, und den typischen Overload-Schwerpunkt; beides sind Hypothesen, die im Interview geprüft werden.

Quer über alle Karten zeigt sich ein Muster: Der Kern ist Urteils-, Entscheidungs- und Beziehungsarbeit und bleibt beim Menschen. Der Overload ist überwiegend Datenlogistik über Tool-Grenzen, getrieben von Änderungsfrequenz und Evidenzpflicht. Wie stark diese Evidenzpflicht die Branche belastet, zeigt eine Befragung: 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). Wo diese Logistik in den Arbeitsströmen liegt, ordnet der Beitrag zu den vier Wertströmen eines Automotive-SWE-Projekts.

Vom Karten-Satz zur Kundenrealität

Im Audit dienen die Karten als Leitfaden für Rollen-Interviews. Jedes Interview beginnt mit offenen Fragen zum letzten abgeschlossenen Fall, bevor die Karte aufgelegt wird; so entsteht kein Ankereffekt. Danach wird jeder Kern- und Overload-Eintrag abgeglichen: bestätigt, anders, kommt nicht vor oder fehlt. Jede Abweichung landet in einem Abweichungslog. Für bestätigte Overload-Einträge wird ein konkretes Beispiel erhoben, welches Werkzeug, welcher Schritt, welche Häufigkeits-Bandbreite, damit aus Meinung ein Beleg wird.

Der Anschluss: von der Karte in die Entscheidungsmatrix

Rollenkarten sind bei sensified Erhebungs-Werkzeug, kein Endprodukt. Ihre Triage-Einträge tragen stabile Karten-Kennungen und werden bei der Kundeninstanziierung auf die Einträge einer versionierten Entscheidungsmatrix abgebildet. Dort wird jede Tätigkeit in Anteile zerlegt, je Anteil mit genau einer Tätigkeitsklasse und einer Triage-Klasse, mit Angaben zu führendem System, Befund-Herkunft und Schadensklasse. Wie diese Matrix aufgebaut ist und wie aus ihr übergabefähige Backlog-Einträge werden, beschreibt der Beitrag zur Entscheidungsmatrix und ihrem Weg ins Backlog.

Wichtig für die Erwartungssteuerung: Ein belastbarer Overload-Prozentwert je Rolle existiert nicht. Verfügbare Branchenzahlen sind Größenordnungs-Belege aus anderen Kontexten. Was eine Rolle im konkreten Haus tatsächlich trägt, zeigt erst die Erhebung.

Compliance: Rollen bewerten, nie Personen

Die Karten beschreiben Rollen, und diese Grenze ist verbindliche Regel der Erhebung bei sensified. Es gibt keine Individualbewertung, keine personenbezogenen Zeitanteile und keine Leistungsdaten aus Git, Ticket-System oder Test-Werkzeugen. Erhoben werden Tätigkeits-Eigenschaften und Häufigkeits-Bandbreiten auf Prozess-Ebene; diese Zusage trägt das Vertrauen der Rolleninhaber in die Interviews.

Dazu kommt die Aggregations-Regel für kleine Populationen: Gibt es weniger als fünf vergleichbare Rolleninhaber, und das ist in Automotive-Streams der Normalfall, wird jeder Befund automatisch auf Wertstromschritt- oder Prozess-Ebene aggregiert berichtet, nie als Rollenbefund. Weil auch ein Prozessbefund in kleinen Teams auf eine einzelne Person zeigen kann, durchläuft jede Berichtsfassung vor Auslieferung eine Identifizierbarkeitsprüfung; wo nötig, wird generalisiert oder unterdrückt. Die Einbindung von Datenschutz und Betriebsrat (BR) ist Teil der Audit-Charter, die vor jeder Erhebung steht. AI assistiert, der Mensch verantwortet, und bewertet wird der Prozess, nie die Person.

Nächste Schritte

Die Rollenkarten sind das Erhebungs-Werkzeug im zweiten Schritt eines längeren Wegs, den der Leitfaden zum Wertbeitrags-Prinzip im Automotive Software Engineering im Zusammenhang beschreibt. Wie die Karten im konkreten Projekt eingesetzt werden, von der Audit-Charter über die Interviews bis zur validierten Matrix, zeigt das Wertbeitrags-Audit für Automotive Software Engineering. sensified bringt den typisierten Karten-Satz mit und prüft ihn gemeinsam mit den Rolleninhabern.

Der Einstieg ist ein Qualifying-Call, in dem beide Seiten den Zuschnitt klären; Sie können dieses Gespräch über die Audit-Seite direkt als Termin buchen.

Häufige Fragen

Sind Rollenkarten Stellenbeschreibungen?

Nein. Eine Stellenbeschreibung regelt arbeitsvertraglich, was eine Person tut. Eine Rollenkarte beschreibt einen typisierten Industrie-Rollenschnitt entlang der ASPICE-Prozesse als Erhebungs-Hypothese: Kern-Tätigkeiten, Ausführungs- und Logistikanteile, Abhängigkeiten und AI-Kandidaten. Beim Kunden wird die Karte gegen die tatsächlichen Rollenschnitte geprüft und angepasst; sie ersetzt keine organisatorische Festlegung.

Werden mit den Rollenkarten Personen bewertet?

Nein. Die Karten beschreiben Rollen, und die Erhebung folgt festen Regeln: keine Individualbewertung, keine personenbezogenen Zeitanteile, keine Leistungsdaten aus der Tool-Kette. Bei weniger als fünf vergleichbaren Rolleninhabern werden Befunde automatisch auf Prozess-Ebene aggregiert, und jede Berichtsfassung durchläuft eine Identifizierbarkeitsprüfung. Datenschutz und Betriebsrat sind über die Audit-Charter eingebunden.

Warum definiert ASPICE keine Rollen?

Automotive SPICE ist ein Prozess-Referenzmodell: Es definiert Prozesse, Base Practices und Work Products, damit Fähigkeitsgrade vergleichbar bewertet werden können. Wie eine Organisation diese Prozesse auf Rollen und Köpfe verteilt, bleibt ihre Entscheidung. Die einzige harte Rollen-Vorgabe im betrachteten Scope ist die Unabhängigkeit der Qualitätssicherung nach SUP.1. Deshalb arbeiten die Karten mit typisierten Schnitten statt mit Normrollen.

Was bedeutet Overload auf einer Rollenkarte?

Overload bezeichnet den automatisierbaren Ausführungs- und Logistikanteil einer Tätigkeit nach ihrer Zerlegung in Urteils-, Ausführungs- und Dokumentationsanteile. Es bedeutet ausdrücklich keine unnötige Arbeit: Auch normativ geforderte Tätigkeiten wie Statusberichte oder Trace-Pflege sind Prozesswert. Klassifiziert wird nur der mechanische Anteil, der nach Prüfung maschinell vorbereitet oder ausgeführt werden kann.

Gelten die Karten auch bei Personalunion?

Ja. Die Karten gelten pro Rolle, nicht pro Kopf. Trägt eine Person mehrere Rollen, etwa Entwickler und Unit-Test-Ingenieur oder Projektleiter und Risikomanager, werden die Tätigkeiten beider Karten als Anteile derselben Person erhoben. Für die Berichterstattung greift dann die Aggregations-Regel besonders streng, weil kleine Populationen die Identifizierbarkeit erhöhen.

Wie kommen die Karten-Ergebnisse in ein AI-Backlog?

Über die Entscheidungsmatrix. Die Triage-Einträge der Karten werden bei der Kundeninstanziierung auf Matrix-Einträge abgebildet: je Tätigkeits-Anteil eine Zeile mit Tätigkeitsklasse, Triage-Klasse, führendem System und Befund-Herkunft. Nach Validierungs-Workshops und Priorisierung werden die ausgearbeiteten Einträge mit stabiler Kennung an die Backlog-Härtung übergeben, wo die technische und wirtschaftliche Prüfung stattfindet.

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.