ASPICE CL3 in 90 Tagen vom CL1-Start.

1. CL1 → CL3 — Realitäts-Check: Was „managed“ und „established“ wirklich hinzufügen

Wir haben diesen Übergang oft genug begleitet, um deutlich zu sein: 90 Tage von einer echten CL1-Basis zu einer belastbaren CL3-Bewertung sind ambitioniert, aber machbar — auf einem fokussierten Prozess-Scope, mit einem Team, das die Engineering-Arbeit bereits gut ausführt. Sind die Base Practices schwach, bringen Ihnen 90 Tage nichts; man kann keine Prozessmanagement-Schicht auf Arbeit setzen, die gar nicht stattfindet. Die erste ehrliche Frage lautet daher nie „Wie kommen wir zu CL3?“, sondern „Ist unser CL1 echt?“

Im Automotive SPICE PAM 3.1 reicht die Fähigkeitsdimension von CL0 bis CL5. CL0 (incomplete) bedeutet, dass der Prozess seinen Zweck weitgehend verfehlt. CL1 (performed) bedeutet, dass die Base Practices ausgeführt werden und die erwarteten Arbeitsprodukte existieren — Sie erstellen die Architektur, schreiben die Tests, erzeugen die Outputs. Bewertet wird dies anhand des einen Attributs PA 1.1, Prozessdurchführung.

CL2 (managed) fügt zwei Attribute hinzu, die nichts mit Engineering-Können und alles mit Disziplin zu tun haben. PA 2.1, Performance Management, fragt, ob die Arbeit geplant, überwacht und angepasst wird: Gibt es Ziele, Schätzungen, einen Zeitplan, definierte Verantwortlichkeiten und Nachweise, dass neu geplant wird, wenn die Realität abweicht? PA 2.2, Work Product Management, fragt, ob die Outputs identifiziert, dokumentiert, versioniert, reviewt und änderungskontrolliert sind. Nach unserer Erfahrung verlieren genau hier die meisten Teams still ihre Bewertungen, die beteuern „Das machen wir doch alles schon“ — die Arbeit wird getan, aber das Management der Arbeit bleibt informell.

CL3 (established) fügt die Prozess-Asset-Schicht hinzu. PA 3.1, Prozessdefinition, fragt, ob ein Standardprozess existiert — ein organisatorisches Asset, kein Projektordner — mit definierten Rollen, Kompetenzen, Infrastruktur und Tailoring-Leitlinien. PA 3.2, Prozess-Deployment, fragt, ob jedes Projekt diesen Standardprozess tatsächlich durch Tailoring einsetzt, mit den Daten und Ressourcen für seine Durchführung und mit Feedback, das in die Verbesserung des Assets zurückfließt. Der Denkwechsel ist der Kern: CL3 ist kein Heldentum eines starken Teams. Es ist dasselbe gute Ergebnis — erzeugt, weil die Organisation das Wie definiert hat, nicht weil drei erfahrene Ingenieure es zufällig wussten.

Jedes Prozessattribut wird auf der N-P-L-F-Skala bewertet — Not / Partially / Largely / Fully achieved — und ein Level zählt erst, wenn die darunterliegenden Attribute mindestens Largely erreicht sind. Diese Ratsche ist der Grund für die Scope-Disziplin: Es ist weit besser, acht Prozesse solide auf CL3 zu bringen, als Aufwand auf zwanzig zu verteilen und alles auf einem wackeligen CL2 zu landen.

2. Der 12-Wochen-Plan auf einen Blick

Wir gliedern die 90 Tage in drei Phasen. Die Reihenfolge ist bewusst gewählt — man kann keinen sinnvollen Standardprozess (PA 3.1) definieren, bevor man verstanden hat, wie die Arbeit tatsächlich gemanagt wird (PA 2.1 / PA 2.2), und man kann kein Tailoring pilotieren, bevor der Standardprozess existiert.

Wochen 1–4 — Baseline & Institutionalisierung GP 2.x

• Woche 1: Scope bestätigen, eine Gap-Analyse gegen die heute beanspruchte Bewertung fahren und das VDA-Prozessset einfrieren (siehe Abschnitt 3). Bestehende Arbeitsprodukte gegen die erwarteten Outputs des PAM inventarisieren.
• Wochen 2–3: PA-2.1-Lücken schließen — Projektziele, Schätzungen, Zeitplan, definierte Verantwortlichkeiten und ein Trigger für Neuplanung. PA-2.2-Lücken schließen — Konfigurationsidentifikation, Baselining, Review-Records, Änderungssteuerung.
• Woche 4: Die GP-2.x-Praktiken auf einem Projekt einen vollen Zyklus lang live anwenden, damit objektive Nachweise entstehen, nicht nur ein Verfahrensdokument.

Wochen 5–9 — Standardprozess & Tailoring (GP 3.x)

• Wochen 5–6: Die gemanagten Praktiken zu einem organisatorischen Standardprozess verdichten: Prozessbeschreibungen, Rollen- und Kompetenzdefinitionen, erforderliche Infrastruktur sowie Eingangs-/Ausgangskriterien je Aktivität.
• Wochen 7–8: Die Tailoring-Richtlinie erstellen — die Regeln und Entscheidungskriterien, um den Standardprozess an den Projektkontext anzupassen (Variante, ASIL, Liefermodell, Wiederverwendung).
• Woche 9: Die Process Asset Library und den Feedback-Mechanismus aufsetzen (Lessons Learned, Metrik-Erfassung, definierter Verbesserungspfad zurück zum Asset-Owner).

Wochen 10–12 — Pilot, Readiness, Nachweise

• Wochen 10–11: Den Standardprozess im Pilotprojekt über eine dokumentierte Tailoring-Entscheidung einsetzen; Deployment-Daten erheben und den Feedback-Loop mindestens einmal nachweislich auslösen.
• Woche 12: Assessment-Readiness-Review — jede GP auf objektive Nachweise zurückführen, die Interviews proben und die Lücken schließen, die ein erfahrener Assessor zuerst prüft.

3. Welche Prozesse zuerst — der VDA-Scope

Man assessiert nicht alle 32 Prozesse des PAM auf einmal, und für einen CL3-Push erst recht nicht. Wir verankern uns am VDA-Scope — dem Engineering-Kern, den OEMs in der Praxis verlangen, der SYS.2–SYS.5 und SWE.1–SWE.6 sowie ACQ.4 und die unterstützenden MAN-/SUP-Prozesse umfasst — und behandeln die Support- und Management-Prozesse als Enabler, nicht als Beiwerk.

Das Engineering-V ist das Herzstück:

• SYS.2 — System Requirements Analysis (Systemanforderungsanalyse)
• SYS.3 — System Architectural Design (mit SYS.4 System Integration and Integration Test und SYS.5 System Qualification Test, sofern auf Systemseite im Scope)
• SWE.1 — Software Requirements Analysis
• SWE.2 — Software Architectural Design
• SWE.3 — Software Detailed Design and Unit Construction
• SWE.4 — Software Unit Verification
• SWE.5 — Software Integration and Integration Test
• SWE.6 — Software Qualification Test

Die Enabler wiegen schwerer, als Teams erwarten, weil die Attribute GP 2.x und 3.x auf ihnen aufbauen:

• SUP.1 — Quality Assurance: unabhängige Bestätigung, dass Prozesse und Produkte konform sind. Assessoren lesen dies früh; hat die QA keine Zähne, ist GP-Institutionalisierung schwer zu argumentieren.
• SUP.8 — Configuration Management: das Rückgrat von PA 2.2. Ohne sauberes CM gibt es kein Baselining, keine kontrollierte Änderung, keine belastbare Traceability.
• SUP.9 — Problem Resolution Management.
• SUP.10 — Change Request Management. SUP.9 und SUP.10 zusammen entscheiden darüber, ob „Pläne, die zur Realität passen“ bestehen oder scheitern.
• MAN.3 — Project Management: die natürliche Heimat eines Großteils der PA-2.1-Nachweise (Ziele, Schätzungen, Zeitplan, Überwachung).

Eine pragmatische Reihenfolge innerhalb der 12 Wochen: zuerst SUP.8 und MAN.3 stabilisieren (sie speisen jede GP-2.x-Bewertung), dann das Engineering-V von oben nach unten durchgehen, damit die Traceability mitwachsend entsteht statt am Ende nachgerüstet zu werden. Nachgerüstete Traceability ist die mit Abstand häufigste Ursache für einen gerissenen Zeitplan, die wir sehen.

4. Zuerst GP 2.x — wo die „Das machen wir schon“-Teams verlieren

Verbringen Sie die ersten vier Wochen hier, denn CL2 ist die Ratsche, auf der CL3 sitzt. Zwei Praktikenfamilien, beide auf eine Weise banal, die starke Ingenieure unterschätzen.

Performance Management (PA 2.1)

Die GP-2.1.x-Praktiken verlangen: Ziele für die Prozessdurchführung, einen Plan zur Durchführung, Schätzungen hinter diesem Plan, definierte Verantwortlichkeiten und Befugnisse, angemessene Ressourcen und Informationen sowie gemanagte Schnittstellen zwischen den Beteiligten. Das wiederkehrende Versagen ist nicht das Fehlen eines Plans — es ist ein einmal geschriebener und nie aktualisierter Plan ohne Schätzgrundlage und ohne Überwachung dagegen. Wir sehen, dass etwa ~60% der erstmaligen CL2-Selbsteinschätzungen hier fallen: Das Projekt lief gut, aber es gibt keinen objektiven Nachweis, dass das Team die Performance gegen definierte Ziele überwacht und angepasst hat. Beheben Sie es mit einer schlanken, echten Kadenz — eine überwachte Metrik je Prozess, ein Trigger für Neuplanung und Protokolle, die zeigen, dass tatsächlich angepasst wurde.

Work Product Management (PA 2.2)

Die GP-2.2.x-Praktiken verlangen Arbeitsprodukte mit definierten Anforderungen (einschließlich Struktur und Inhalt), dokumentiert und gesteuert, unter Konfigurationsmanagement, reviewt und angepasst. Hier verdient sich SUP.8 seinen Lohn. Das Leck ist fast immer die Review-Disziplin: Outputs existieren und sind sogar versioniert, aber es gibt keinen Nachweis, dass sie gegen Kriterien reviewt wurden und dass Findings bis zum Abschluss verfolgt wurden. Ein Review ohne dokumentierte Checkliste, Reviewer, Datum und Disposition ist für einen Assessor ein Gespräch, das stattgefunden haben mag oder nicht. Machen Sie jedes erwartete Arbeitsprodukt auf einen Review-Record rückverfolgbar. Diese eine Gewohnheit hebt mehr GP-2.2-Bewertungen als jeder Werkzeugkauf.

5. GP 3.x — den Standardprozess definieren, dann tailoren

CL3 wird häufig als „CL2 nur härter“ missverstanden. Das ist es nicht. Die prägende Idee: Das gute Ergebnis entsteht, weil die Organisation das Wie definiert hat, und jedes Projekt tailort diese Definition. Erneut zwei Praktikenfamilien.

Prozessdefinition (PA 3.1)

Sie brauchen einen Standardprozess als organisatorisches Asset: eine dokumentierte Prozessbeschreibung mit Reihenfolge und Interaktion der Aktivitäten, die zu seiner Durchführung erforderlichen Rollen und Kompetenzen, die benötigte Infrastruktur und Arbeitsumgebung und — entscheidend — Tailoring-Leitlinien. Geeignete Methoden zur Überwachung der Prozesswirksamkeit müssen ebenfalls bestimmt werden. Das Artefakt, das Teams am häufigsten auslassen, ist die Tailoring-Leitlinie selbst; ohne sie gibt es nichts, wovon getailort werden kann, und PA 3.2 bricht mit ihr zusammen.

Prozess-Deployment (PA 3.2)

Jedes Projekt muss den Standardprozess einsetzen, indem es ihn auswählt und gemäß den Leitlinien tailort, dann Rollen und Verantwortlichkeiten zuweist, die erforderlichen Kompetenzen sicherstellt, Ressourcen und Infrastruktur bereitstellt, Prozessdaten erhebt und diese Daten nutzt, um den Standardprozess zu steuern und zu verbessern. Unser Lackmustest: Können Sie eine dokumentierte Tailoring-Entscheidung und ein Stück Feedback zeigen, das das Asset tatsächlich verändert hat? Wurde der Standardprozess nie getailort und hat nie eine Lesson Learned aufgenommen, ist er ein Ordner im Regal — dokumentiert, aber nicht etabliert. Bauen Sie die Process Asset Library so, dass Tailoring eine fünfminütige dokumentierte Entscheidung ist, kein Ausgrabungsprojekt, und der Feedback-Weg zurück zum Prozess-Owner ein echter, genutzter Kanal.

6. Arbeitsprodukte, die der Assessor zuerst liest

Ein erfahrener Assessor beginnt nicht mit Ihrem Prozesshandbuch. Er zieht Stichproben aus Arbeitsprodukten und folgt den Fäden. Stimmen diese, verlaufen die Interviews ruhig; stimmen sie nicht, rettet keine Dokumentation die Bewertung.

Bidirektionale Traceability

Das PAM verlangt ausdrücklich bidirektionale Traceability: Stakeholder-Anforderungen ↔ Systemanforderungen (SYS.2) ↔ Systemarchitektur (SYS.3) ↔ Software-Anforderungen (SWE.1) ↔ Software-Architektur (SWE.2) ↔ Detailed Design (SWE.3) und vorwärts in die Verifikation — SWE.4 Unit Verification, SWE.5 Integrationstest, SWE.6 Qualification Test — wobei Testfälle auf die Anforderungen zurückverweisen, die sie verifizieren. „Bidirektional“ ist keine Dekoration: Der Assessor wählt eine Anforderung und geht sie abwärts bis zum Unit-Test, dann wählt er einen Testfall und geht ihn aufwärts bis zur Anforderung. Lücken in beiden Richtungen sind Findings.

Konsistenz

Über bloße Links hinaus erwartet das PAM Konsistenz zwischen den Ebenen — dass die Architektur die Anforderungen tatsächlich erfüllt, dass das Design die Architektur realisiert, dass die Tests wirklich das prüfen, was die Anforderungen verlangen. Ein Trace-Link zu einer Anforderung, die der Test gar nicht verifiziert, ist schlimmer als ein fehlender Link, weil er eine Behauptung ist, die nicht trägt.

Review-Records und Verifikationsnachweise

Für jede Ebene: Review-Records mit Kriterien, Reviewer, Datum und abgeschlossenen Findings; und Verifikationsnachweise, die das V schließen — Unit-Verification-Ergebnisse (SWE.4), Integrationstest-Ergebnisse (SWE.5) und Qualification-Test-Ergebnisse gegen die Software-Anforderungen (SWE.6), mit einer Abdeckung, die Sie verteidigen können. Dies sind die Artefakte, die ein Assessor stichprobenartig prüft, um zu bestätigen, dass die GPs real und nicht nur behauptet sind.

7. Häufige Herabstufungen — und wie wir ihnen zuvorkommen

Dieselbe Handvoll Probleme erklärt die große Mehrheit der in CL3-Assessments verlorenen Bewertungen. Wir fahren ein internes Pre-Assessment gezielt zu ihrer Jagd.

• Traceability-Lücken. Die mit Abstand häufigste Herabstufung. Vorwärts-Links vorhanden, Rückwärts-Links fehlen; oder Links vorhanden, aber inkonsistent (der Test verifiziert die referenzierte Anforderung nicht). Ein gerissener Faden in der Stichprobe lässt die gesamte Population unzuverlässig erscheinen.
• Kein Tailoring-Nachweis. Ein wunderschön geschriebener Standardprozess, von dem nie ein Projekt getailort hat. PA 3.2 braucht eine dokumentierte Tailoring-Entscheidung je Projekt, nicht die Behauptung, Tailoring sei „erlaubt“.
• Pläne, die nicht zur Realität passen. Ein MAN.3-Plan mit Datum vom Kickoff, nie revidiert, während das Projekt sichtbar abwich. Das versenkt PA 2.1: Es gibt keinen Nachweis von Überwachung und Anpassung.
• Fehlender objektiver Nachweis der GP-Institutionalisierung. Der Prozess existiert auf dem Papier, aber das Projekt lief auf die alte informelle Weise. Assessoren bewerten Nachweise, nicht Absichten — ein Verfahren ohne eine einzige Instanz seiner Befolgung ist Not achieved, so gut es auch geschrieben ist.
• Zahnlose QA (SUP.1). QA, die berichtet, aber nie Veränderung bewirkt, oder die keine Unabhängigkeit hat, untergräbt das Institutionalisierungsargument auf ganzer Linie.
• CM-Lücken (SUP.8). Keine sauberen Baselines bedeuten, dass PA 2.2 nicht Largely erreicht werden kann, und der Traceability ist nicht zu trauen, weil die verknüpften Items nicht unter Kontrolle sind.

Unsere Vorbeugung ist mechanisch: ein Vollständigkeits- und Konsistenz-Check der Traceability über das gesamte Stichproben-Faden-Set, eine dokumentierte Tailoring-Entscheidung je Pilot, Plan-Ist-Diffs auf den MAN.3-Artefakten des Piloten und eine GP-zu-Nachweis-Matrix, in der jede Generic Practice auf ein datiertes, zurechenbares Artefakt zeigt. Ist eine Zelle in Woche 12 leer, ist sie es auch im Assessment.

8. CL3 erhalten — es verfällt ohne Ownership

Eine Bewertung ist eine Momentaufnahme; Fähigkeit ist ein Verhalten, und Verhalten verfällt. Wir haben hart erkämpfte CL3-Bewertungen binnen eines Jahres zurückrutschen sehen — aus einem Grund: Nach dem Assessment hat niemand den Standardprozess besessen. Das Asset veraltet, Projekte driften still zu eigenen Wegen, Tailoring-Entscheidungen werden nicht mehr dokumentiert, und der Feedback-Loop — genau das, was PA 3.2 verlangt — verstummt.

Was ihn am Leben hält, ist unspektakulär und nicht verhandelbar. Erstens eine benannte Prozessgruppe (sie darf klein sein), die die Process Asset Library besitzt, Tailoring-Entscheidungen reviewt und Verbesserungs-Feedback triagiert — eine Engineering-Prozessgruppe ist der Unterschied zwischen „einmal etabliert“ und „etabliert“. Zweitens ein lebendiger Feedback-Loop: Jedes Projekt steuert mindestens eine Lesson Learned und mindestens eine Metrik zum Asset bei, und Sie können zeigen, dass sich das Asset deshalb verändert. Drittens periodische interne Assessments — ein leichter Quartals-Selbstcheck auf den Stichproben-Fäden und ein vollerer jährlicher Durchgang — damit Drift auf GP-Ebene gefangen wird, lange bevor ein externer Assessor sie sähe. Viertens Kompetenzpflege: Die im Standardprozess definierten Rollen brauchen die dahinterstehende Schulung gepflegt, sonst höhlt PA 3.1 aus, während Personen wechseln.

Nichts davon zielt darauf, ein Zertifikat erneut zu jagen — und Automotive SPICE liefert ohnehin eine Assessment-Bewertung, keine Zertifizierung. Es geht darum, die Organisation in dem Zustand zu halten, in dem das gute Engineering-Ergebnis der Default ist — erzeugt, weil der Prozess das Wie definiert. Was am Ende exakt die Definition eines etablierten Prozesses ist.

---

Möchten Sie einen 30-minütigen Walkthrough zu Ihrem Projekt?

Keine NDA nötig. Sagen Sie uns die Norm, das Item bzw. Asset, den Assessor und Ihre Deadline. Innerhalb von 48 Stunden erhalten Sie eine einseitige Diagnose, abgebildet auf die obigen Punkte — Ihre, ob Sie uns beauftragen oder nicht.

ASPICE-Walkthrough buchen →

---

Autor: Adrian Valea, Gründer & Geschäftsführer, SafetyTrust Software Technology GmbH. ASPICE Provisional Assessor (intacs / VDA), Functional Safety Engineer (TÜV Rheinland), Automotive Cybersecurity (TÜV NORD). Veröffentlicht 2026-05-28.