Automotive SPICE & Projektmanagement: Wie IT-gestützte PPM-Software die Prozessreife erhöht

Wenn ein Zulieferer zum ersten Mal mit Automotive SPICE® (ASPICE) konfrontiert wird, richtet sich der Blick fast reflexhaft auf die Entwicklung: Anforderungen, Architektur, Tests, Traceability. Das ist verständlich — und aus Sicht des Projektmanagements irreführend.

Denn der Einstieg in die Lieferkette läuft nicht über SWE.1. Er läuft über MAN.3.

Das VDA QMC hat 2024 mit der Automotive SPICE Potential Analysis (1. Auflage, Juni 2024) eine standardisierte Vorstufe zur Auftragsvergabe veröffentlicht — eine Kurzbewertung, die eine fehlende Lieferanten-Selbstbewertung ersetzen kann. Bewertet wird dort ausschließlich Process Attribute 1.1, also maximal Capability Level 1. Ihr verpflichtender BASIC Scope besteht aus genau vier Prozessen mit eigenen Kennungen:

• POPM — Project Management
• RTCM — Release and Technical Configuration Management
• PQAS — Process Quality Assurance
• TEPR — Technical Problem Resolution

Dazu kommt mindestens ein Plug-in aus der Engineering-Ebene. Aber im Pflichtteil: vier von vier sind Management- und Support-Prozesse.

Anders gesagt: Bevor ein OEM überhaupt prüft, wie Sie Software entwickeln, prüft er, wie Sie Projekte steuern.

Genau hier entscheidet sich, ob ASPICE zu einer dauerhaften Dokumentationslast wird oder zu einem Nebenprodukt gut gebauter Prozesse. Und genau hier liegt die Aufgabe von IT-gestütztem Projekt- und Portfoliomanagement: Prozessreife entsteht nicht dadurch, dass Prozesse beschrieben werden, sondern dadurch, dass sie im täglichen Arbeiten Spuren hinterlassen, die ein Assessor nachvollziehen kann.

---

Automotive SPICE in Kürze — und warum es ein PM-Thema ist

ASPICE ist ein Prozessreferenz- und Prozessassessmentmodell des VDA. Bewertet wird nicht das Produkt, sondern der Prozess: wie diszipliniert, wiederholbar und nachweisbar entwickelt wird. Ergebnis eines Assessments ist ein Capability Level je bewertetem Prozess — die Maßzahl für die Prozessreife der Organisation in genau diesem Prozess.

In der Praxis fordern OEMs und Tier-1-Lieferanten überwiegend Capability Level 2, für Schlüsselprozesse oder Folgeaufträge auch Level 3. Level 4 und 5 spielen in der Vergabepraxis kaum eine Rolle.

Level 2 gilt in der Assessment-Praxis als erster belastbarer Zustand: Erfahrungsberichte beschreiben, dass Reifegrade unterhalb von CL2 über etwa eineinhalb Jahre nicht stabil bleiben, sondern wieder steigen oder fallen. Eine normative Grundlage dafür gibt es im Modell nicht — es ist Praxiserfahrung, keine VDA-Vorgabe.

Dasselbe gilt für die Zeiträume, die in der Beratungspraxis kursieren: rund zwölf Monate bis CL2 bei einem neu aufgesetzten Projekt, eher 18 bis 24 Monate, wenn bestehende Projekte nachträglich auf Nachweisfähigkeit gebracht werden, und mindestens zwei Jahre, bis Level 2 organisationsweit konsistent gelebt wird. Das VDA-Modell nennt keine Fristen; diese Werte sind Erfahrungsgrößen und variieren stark mit Scope und Ausgangslage.

Wer diese Zeiträume mit manueller Nachweisführung überbrücken will, verbrennt Kapazität, die im Projekt fehlt.

---

MAN.3: der regeldichteste Prozess im gesamten VDA Scope

Der VDA Scope teilt sich in einen Basic Part (u. a. MAN.3, MAN.5, MAN.6, SUP.1, SUP.8, SUP.9, SUP.10, ACQ.4, SPL.2, REU.2, PIM.3) und domänenspezifische Prozessgruppen (SYS, SWE, HWE, MLE, VAL).

Interessant wird es, wenn man die Bewertungsregeln zählt. Die VDA-Guidelines legen je Prozess sogenannte Rating Lines fest — die Regeln, nach denen ein Assessor bewertet. Die folgenden Zahlen beziehen sich auf PAM 4.0 in Verbindung mit den Guidelines 2.0:

MAN.3 und SUP.10 tragen zusammen 35 der Bewertungsregeln des Basic Part. Das sind die beiden Prozesse mit dem höchsten Nachweisaufwand außerhalb der Engineering-Kette — und beide sind im Kern Projektmanagement.

Die zehn Base Practices von MAN.3 — und was sie im Werkzeug bedeuten

BP9 ist der eigentliche Knackpunkt — und die Stelle, an der die meisten Findings entstehen.

Die häufigsten Assessment-Findings zu MAN.3

Aus der veröffentlichten Assessment-Praxis lassen sich sechs wiederkehrende Muster ableiten:

1. Unvollständige Projektstrukturpläne. Nicht-technische Themen — Qualitätssicherung, Konfigurationsmanagement, Lieferantensteuerung, Schulung — fehlen im PSP, obwohl sie Aufwand binden.
2. Zu grobes Lebenszyklusmodell. Ein Dreiphasenmodell reicht nicht. Gefordert ist ein detailliertes V-Modell je Lieferzyklus, inklusive der Zwischenlieferungen an den Kunden.
3. Falsche Granularität der Arbeitspakete. Das Modell nennt hier keine Schwellenwerte, die Assessment-Praxis schon: als Faustregel zwischen einem Tag und zwei Wochen, Zielwert etwa eine Woche. Kleinere Pakete erzeugen Verwaltungsaufwand, größere lassen sich nicht mehr sinnvoll fortschrittsbewerten.
4. Schätzungen ohne Substanz. Grobe Hausnummern zu Projektbeginn, danach nie wieder angefasst — obwohl der Prozess ausdrücklich die fortlaufende Neubewertung verlangt.
5. Inkonsistenzen zwischen den Plänen. Der PSP sagt das eine, die Schätzung das andere, der Terminplan ein drittes, und die verfügbare Kapazität passt zu keinem davon. Die Grundfrage „Reichen unsere Ressourcen bis zum nächsten Meilenstein?" bleibt unbeantwortbar.
6. Risiken und Änderungen werden im Projektverlauf nicht nachverfolgt. Sie sind zu Projektbeginn dokumentiert und danach eingefroren.

Bemerkenswert ist, wie die Assessment-Praxis selbst den Ausweg beschreibt: Projekte, die Projektstrukturplan, Schätzungen, Terminpläne und zugeordnete Arbeit in ein gemeinsames Werkzeug integrieren, haben eine realistische Chance, diese Konsistenz zu halten. Das ist keine Herstelleraussage, sondern eine Beobachtung von Assessoren.

---

Die PM-nahen Prozesse jenseits von MAN.3

MAN.3 steht nicht allein. Sechs weitere Prozesse des Basic Part sind unmittelbar Projektmanagement-Arbeit:

Bei SUP.8 lohnt ein genauerer Blick, weil hier ein typischer Werkzeugbruch sichtbar wird. Die häufigste Schwäche ist nicht fehlende Versionierung, sondern unkoordinierte Versionierung: Software liegt im Git, Hardware im PLM, Dokumente auf dem Fileshare, Anforderungen im ALM — und niemand kann eine disziplinübergreifende Gesamt-Baseline ziehen. Genau die verlangt der Prozess aber. Hinzu kommt die Anforderung an Langzeitarchivierung, die in der Automobilindustrie bis zu 30 Jahre umfassen kann.

Und die Statusinformationen aus SUP.8 — „in Arbeit", „reviewt", „unit-getestet", „freigegeben" — sind direkter Input für das Projektcontrolling nach MAN.3.BP10. Wer sie manuell überträgt, produziert genau die Inkonsistenzen, die im Assessment auffallen.

---

Warum Capability Level 2 ohne Werkzeug kaum nachweisbar ist

Ab Level 2 kommen zu den Base Practices die Prozessattribute hinzu. Sie gelten nicht nur für MAN.3, sondern für jeden bewerteten Prozess.

PA 2.1 Performance Management verlangt: Ziele und Strategie definieren, Prozessausführung planen, Ressourcenbedarf bestimmen, Ressourcen bereitstellen, überwachen und anpassen, Schnittstellen managen.

PA 2.2 Work Product Management verlangt: Anforderungen an die Arbeitsergebnisse definieren, Anforderungen an Speicherung und Kontrolle definieren, Arbeitsergebnisse identifizieren, speichern und kontrollieren, sowie überprüfen und anpassen.

PA 2.2 ist faktisch eine Werkzeuganforderung. Für jedes Ergebnis jedes Prozesses ist definierte Ablage, Versionsführung, Zugriffskontrolle und Review-Nachweis gefordert. Das ist SUP.8-Mechanik, angewandt auf sämtliche Prozessergebnisse — nicht nur auf Anforderungen und Code, sondern auch auf Projektpläne, Statusberichte, Risikolisten, Protokolle und Schätzungen. Mit Netzlaufwerken und E-Mail-Freigaben ist das reproduzierbar nicht nachweisbar.

PA 2.1 und MAN.3 sind zwei Sichten auf dieselben Daten. PA 2.1 fordert die systematische Planung des Prozesses, MAN.3 konkretisiert die Planung des Projekts — und beide müssen konsistent sein. Ein System, das Prozessplanung und Projektplanung aus einer Datenbasis erzeugt, eliminiert diese Findings-Klasse strukturell statt sie vor jedem Assessment nachzuarbeiten.

Für Level 3 kommt hinzu: ein dokumentierter organisationsweiter Standardprozess (PA 3.1) plus der Nachweis, dass er projektspezifisch getailort und in seiner Leistung überwacht wird (PA 3.2). Das verlangt projektübergreifende Auswertbarkeit — und koppelt CL3 direkt an MAN.6 und damit an Kennzahlen aus dem Projektsystem. Teams, die projektweise gut arbeiten, aber keine belegten Standardprozesse mit Tailoring-Nachweis vorweisen, scheitern regelmäßig genau hier.

Wer sich für den grundsätzlichen Zusammenhang zwischen Reifegradmodellen und Projektsteuerung interessiert: Der Artikel „Reifegradmodelle im Projektmanagement" ordnet ASPICE in die breitere Modelllandschaft ein.

---

Was ASPICE 4.0 für das Projektmanagement geändert hat

Version 4.0 wurde laut Dokumenthistorie am 20. Oktober 2023 freigegeben und Ende 2023 veröffentlicht. Sie hat das Modell deutlich verschlankt: Die Base Practices sanken von 265 auf 199 (−25 %), die Generic-Practice-Indikatoren auf Capability Level 3 von 352 auf 256 (−27 %, auf Level 2 von 352 auf 320), die Rating Lines in den Guidelines von 499 auf 280 (−44 %). Zehn Prozesse entfielen, zehn kamen hinzu — darunter Hardware Engineering (HWE.1–4) und Machine Learning Engineering (MLE.1–4). Das Modell umfasst weiterhin 32 Prozesse.

Vier Änderungen sind für Projektmanagement und PMO relevant:

Erstens: Strategie ist jetzt eine Level-2-Pflicht für alle Prozesse. Die früheren Strategie-Base-Practices in SUP.1, SUP.8, SUP.9 und SUP.10 wurden gestrichen — ihr Inhalt wandert in GP 2.1.1 auf Capability Level 2. Level 1 wird dadurch leichter erreichbar, Level 2 aber strategiepflichtig für jeden einzelnen bewerteten Prozess.

Zweitens: MAN.3 arbeitet mit Arbeitspaketen statt Aktivitäten und ist konzeptionell auf „definieren, überwachen und anpassen" umgestellt. Die fortlaufende Neubewertung ist damit kein guter Stil mehr, sondern Prüfgegenstand.

Drittens: Eskalationsmechanismen wurden in MAN.3, SUP.1 und SUP.9 stärker betont. Ein Eskalationspfad, der nur im Prozesshandbuch existiert, aber im Projektalltag keine Spur hinterlässt, ist kein Nachweis.

Viertens: Die Rating Rules für Level 3 stiegen von 22 auf rund 55. Der Nachweisaufwand hat sich für CL3 mehr als verdoppelt — und zwar überwiegend in dem Bereich, den Projektmanagement-Werkzeuge abdecken.

Ein Hinweis zur Terminologie, der in Assessments für Verwirrung sorgt: Der Indikator Output Work Product heißt in 4.0 Output Information Item, analog wurden aus den Work Product Characteristics die Information Item Characteristics. Der Begriff „Work Product" verschwindet damit nicht aus dem Modell — PA 2.2 heißt weiterhin Work Product Management. Wer noch mit Dokumentvorlagen der Version 3.1 arbeitet, sollte die Benennung dennoch angleichen.

Und der Blick nach vorn: Das VDA QMC hat am 16. April 2026 eine Preview-Fassung des PAM 4.1 veröffentlicht — Status ausdrücklich „Preview", die Änderungshistorie steht auf „t.b.c.". Bindend ist sie damit nicht. Ebenfalls erschienen ist im März 2026 eine überarbeitete Auflage der Guidelines. Beides zeigt eine Konstante: Das Modell wird laufend fortgeschrieben. Wer Prozesswissen und Nachweisstrukturen in Word- und Excel-Landschaften abgelegt hat, zahlt bei jedem Modellwechsel erneut. Wer sie in einem konfigurierbaren System abbildet, migriert Felder statt Dokumente.

---

Agil und A-SPICE: Wo Scrum an MAN.3 anstößt

Die Vorstellung, agile Entwicklung und ASPICE seien unvereinbar, hält sich hartnäckig. Sie stimmt nicht — aber die Reibungspunkte sind konkret und in den VDA-Guidelines sogar ausformuliert. Drei der agilen Rating Rules wirken direkt auf MAN.3:

• AGE.RL.1: Zeigen die Planungsnachweise — Backlog, Burndown-Chart, Sprint-Planung — Lücken gegenüber der Release-Planung, führt das zur Abwertung von MAN.3.BP4, MAN.3.BP9 und SPL.2.BP1.
• AGE.RL.2: Fehlt die Schätzung der verbleibenden Aufwände für künftige Releases, wird MAN.3.BP5 abgewertet.
• AGE.RL.3: Passt das gewählte Lebenszyklusmodell nicht zu Umfang und Anforderungen, trifft es MAN.3.BP2.

Das Muster dahinter ist immer dasselbe: Scrum liefert die Sprint-Ebene zuverlässig. ASPICE verlangt zusätzlich die Release-, Meilenstein- und Kapazitätsebene — und den nachweisbaren Abgleich zwischen beiden. Genau an dieser Nahtstelle entsteht heute in vielen Organisationen Excel-Doppelpflege zwischen Backlog und Kundenmeilensteinplan.

Weitere bekannte Lücken: Schnittstellenmanagement nach BP7 verlangt klassische Kommunikationsmatrizen. Kosten müssen aktiv erhoben werden — Scrum liefert Scope, Qualität und Termin, aber keine Kostensicht. Und Eskalationsstrukturen brauchen eine Governance-Ebene oberhalb des Teams.

Der praktikable Weg ist deshalb nicht „agil oder phasenorientiert", sondern beides parallel im selben System: Quality Gates und Meilensteine auf Gesamtprojektebene, agile Boards in den Entwicklungssträngen — auf einer gemeinsamen Datenbasis. Genau dafür gibt es in WORKSPACE.PM neben Automotive SPICE] auch native Unterstützung für Scrum und das V-Modell XT, kombinierbar innerhalb eines Projekts.

---

Sieben Anforderungen an die Werkzeugkette

Wer PPM-Software für ASPICE-Projekte auswählt, sollte gezielt prüfen:

1. Eine Datenbasis für PSP, Schätzung, Termin und Kapazität. Wenn diese vier Sichten aus derselben Quelle stammen, ist MAN.3.BP9 strukturell erfüllt statt vor jedem Assessment nachgearbeitet.
2. Prozessgruppen als wiederverwendbare Container. SYS, SWE, MAN, SUP müssen sich als Struktur abbilden und projektübergreifend wiederverwenden lassen — das ist die Voraussetzung für den Standardprozess-Nachweis auf Level 3.
3. Phasen, Meilensteine und Quality Gates mit echter Terminlogik. Abhängigkeitstypen und Netzplanberechnung, nicht nur eine gemalte Zeitachse.
4. Versionierung und Freigabe für jedes Arbeitsergebnis. Mehrstufige Freigabe vom Entwurf über die Einreichung bis zur Freigabe, mit Historie — die direkte Antwort auf PA 2.2.
5. Bidirektionale Rückverfolgbarkeit mit Abdeckungsanalyse. Inklusive automatischer Kennzeichnung von Suspect Links, wenn sich ein verknüpftes Objekt ändert. Manuell gepflegte Trace-Matrizen veralten schneller, als sie erstellt werden.
6. Systemweiter Audit-Trail. Wer hat was wann geändert und freigegeben — über alle Entitätstypen hinweg. Das ist die Nachweisquelle für das Assessment und macht die Vorbereitung zur Recherche statt zur Rekonstruktion.
7. Datenhoheit und Deployment-Flexibilität. Im Automotive-Umfeld läuft die Toolauswahl durch das TISAX-Nadelöhr. Aktueller Prüfkatalog ist VDA ISA 6.0.3; für Assessments, die ab dem 1. Januar 2027 beauftragt werden, gilt der neue Katalog VDA ISA 2027 — er verschärft ausdrücklich die Aufsicht über Cloud- und ausgelagerte Dienste. Maßgeblich ist dabei das Beauftragungsdatum, nicht der Audittermin. EU-Hosting, On-Premises-Option und belastbare Auftragsverarbeitungs-Dokumentation sind damit keine Nice-to-haves. Welche Fragen dabei konkret zu stellen sind, behandelt der Artikel „DSGVO-Compliance in PPM: 5 Prüffragen für IT-Leiter".

Abgrenzung: PPM-Software ist kein ALM-Ersatz

Ein Punkt, der in Toolvergleichen regelmäßig untergeht: ALM- und Requirements-Management-Werkzeuge decken die Engineering-Prozesse ab — SYS.1 bis SYS.5, SWE.1 bis SWE.6. Sie sind dort stark und schwer zu ersetzen.

Sie decken aber nicht MAN.3, MAN.5, MAN.6, SUP.1, SUP.9 und SUP.10 ab. Und das ist ausgerechnet der Bereich, der in der VDA Potential Analysis den Pflichtumfang bildet und im Basic Part die höchste Regeldichte trägt.

Die realistische Zielarchitektur ist deshalb keine Ablösung, sondern eine saubere Aufgabenteilung mit definierten Schnittstellen: ALM für die Anforderungs- und Testkette, PPM für Planung, Ressourcen, Kennzahlen, Änderungen und Nachweisführung — und eine belastbare Verknüpfung dazwischen.

---

In fünf Schritten zur nachweisfähigen Prozessreife

1. Scope klären. Welche Prozesse verlangt der Kunde in welchem Capability Level? Ohne diese Festlegung optimieren Sie ins Leere.
2. Gap-Analyse gegen die Base Practices. Für MAN.3 heißt das: alle zehn BPs durchgehen und je BP festhalten, welches Artefakt heute den Nachweis liefert — und wo es keines gibt.
3. Nachweisquellen konsolidieren. Jedes Artefakt, das an zwei Stellen gepflegt wird, ist ein künftiges Konsistenz-Finding. Erst zusammenführen, dann dokumentieren.
4. Prozess im Werkzeug abbilden, nicht in der Präsentation. Phasen, Gates, Freigabestufen und Pflichtfelder gehören ins System. Ein Prozess, der nur im Handbuch existiert, erzeugt keine Evidenz.
5. Trockenlauf vor dem Assessment. In der Praxis bewährt: zwei bis drei Monate vorher eine interne Gap-Analyse mit Verbesserungsplan, zwei bis drei Wochen vorher die Nachweise ordnen und das Team briefen. Dauer und Teamgröße des Assessments selbst hängen vom vereinbarten Scope ab — verbindliche Vorgaben macht das Modell hier nicht.

---

Fazit

Automotive SPICE ist kein Engineering-Thema mit Projektmanagement-Anhang. Prozessreife im Sinne des Modells entsteht zu erheblichen Teilen im Projektmanagement: vier von vier Pflichtprozessen in der Lieferanten-Vorqualifizierung, 21 Rating Lines allein in MAN.3, PA 2.2 als faktische Werkzeuganforderung über sämtliche Prozessergebnisse hinweg.

Die häufigsten Findings sind keine fachlichen Fehler, sondern Konsistenzfehler zwischen Plänen, die getrennt gepflegt werden. Das ist eine Werkzeugfrage — und in dem Moment, in dem Planung, Schätzung, Kapazität, Risiken, Änderungen und Freigaben aus einer Datenbasis stammen, verschwindet diese ganze Fehlerklasse. Der Nachweis wird dann zum Nebenprodukt der täglichen Arbeit statt zum Projekt vor dem Projekt.

Und weil der Nachweis wiederkehrend ist — Ergebnisse einer Potential Analysis gelten nur für einen zwischen den Partnern vereinbarten Zeitraum, niedrige Reifegrade sind erfahrungsgemäß nicht stabil, das Modell selbst wird laufend fortgeschrieben — rechnet sich diese Umstellung nicht einmal, sondern bei jedem Zyklus erneut.

---

Häufige Fragen zu Automotive SPICE und Projektmanagement

Was fordert MAN.3 Projektmanagement in Automotive SPICE? MAN.3 fordert über zehn Base Practices, dass Projektumfang, Lebenszyklus, Machbarkeit, Arbeitspakete, Schätzungen, Kompetenzen, Schnittstellen, Terminplan, Konsistenz und Statusberichterstattung definiert, überwacht und angepasst werden. Mit 21 Rating Lines ist MAN.3 der regeldichteste Prozess im Basic Part des VDA Scope.

Welche Nachweise braucht man für MAN.3? Typischerweise Projektstrukturplan, Lebenszyklus- und Phasenmodell, dokumentierte Aufwandsschätzungen mit Fortschreibung, Terminplan mit Ressourcenzuordnung, Kompetenz- und Rollenzuordnung, Stakeholder- und Kommunikationsmatrix, Statusberichte sowie dokumentierte Korrekturmaßnahmen und Eskalationen. Entscheidend ist weniger die Existenz der einzelnen Dokumente als ihre nachweisbare Konsistenz untereinander.

Was bedeutet ASPICE Capability Level 2? Level 2 („Managed") bedeutet, dass ein Prozess nicht nur durchgeführt wird, sondern geplant, überwacht und gesteuert ist (PA 2.1) und seine Arbeitsergebnisse definiert abgelegt, versioniert, kontrolliert und reviewt werden (PA 2.2). Level 2 gilt als erster stabiler Reifegrad.

Fordern OEMs Level 2 oder Level 3? In der Vergabepraxis ist Level 2 die verbreitete Mindestanforderung. Für Schlüsselprozesse oder Folgeaufträge verlangen einzelne Hersteller Level 3. Level 4 und 5 werden in der Praxis kaum gefordert. Maßgeblich ist immer der vertraglich vereinbarte Scope.

Wie lange dauert es bis Capability Level 2? Das Modell nennt keine Fristen. Erfahrungswerte aus der Beratungspraxis: rund zwölf Monate für ein neu aufgesetztes Projekt, eher 18 bis 24 Monate bei bestehenden Projekten, bei denen Nachweise nachträglich erzeugt werden müssen, und mindestens zwei Jahre, bis Level 2 organisationsweit konsistent gelebt wird. Die Spanne hängt stark von Scope und Ausgangslage ab.

Ist Automotive SPICE für Zulieferer Pflicht? Es gibt keine gesetzliche Pflicht. ASPICE wird jedoch von OEMs und Tier-1-Lieferanten regelmäßig als vertragliche Anforderung gesetzt. Ohne den vereinbarten Capability Level droht der Ausschluss aus dem Vergabeverfahren — faktisch wirkt es damit wie eine Pflicht.

Welches Tool braucht man für ASPICE? ASPICE schreibt kein Werkzeug vor. Praktisch sind zwei Kategorien nötig: ein ALM-/Requirements-Werkzeug für die Engineering-Prozesse (SYS, SWE) und ein PPM-System für Management- und Support-Prozesse (MAN.3, MAN.5, MAN.6, SUP.1, SUP.8, SUP.9, SUP.10). Entscheidend ist, dass die Zahl der Werkzeuge begrenzt bleibt und die Schnittstellen definiert sind — zu viele parallele Tools sind ein bekannter Fallstrick.

Lassen sich Scrum und ASPICE kombinieren? Ja. Die VDA-Guidelines enthalten eigene agile Rating Rules. Reibung entsteht dort, wo die agilen Planungsnachweise Lücken gegenüber der Release-Planung zeigen (AGE.RL.1, mit Abwertung von MAN.3.BP4, MAN.3.BP9 und SPL.2.BP1), wo Restaufwände für künftige Releases nicht geschätzt werden (AGE.RL.2) oder wo das Lebenszyklusmodell nicht zum Projektumfang passt (AGE.RL.3). Die Kombination funktioniert, wenn Sprint- und Release-Ebene auf einer gemeinsamen Datenbasis nachweisbar abgeglichen werden.

Was hat sich mit Automotive SPICE 4.0 geändert? Das Modell wurde verschlankt (Base Practices 265 → 199), Hardware- und Machine-Learning-Engineering kamen als eigene Prozessgruppen hinzu, Strategie-Anforderungen wanderten auf Capability Level 2, MAN.3 arbeitet mit Arbeitspaketen statt Aktivitäten, Eskalationsmechanismen wurden stärker betont, und der Indikator „Output Work Product" heißt jetzt „Output Information Item". Für Level 3 stieg die Zahl der Rating Rules von 22 auf rund 55.

---

Automotive SPICE® ist eine eingetragene Marke des Verbandes der Automobilindustrie e. V. (VDA). Als anerkannte Assessments gelten in der Praxis nur solche, die von intacs-zertifizierten Assessoren geleitet werden; die Zertifizierung läuft über das VDA QMC und ist drei Jahre gültig. Die Angaben in diesem Beitrag beziehen sich auf PAM 4.0 in Verbindung mit den Automotive SPICE Guidelines 2.0. Der Beitrag beschreibt, wie sich Prozessanforderungen werkzeugseitig unterstützen lassen; er ersetzt keine Assessment-Beratung.