Warum es Automotive SPICE & Co. gibt

Wozu gibt es so viele Standards und Referenzmodelle für Software- und Systementwicklung? Sind sie wirklich nötig? Oder ist das gar eine raffinierte Schikane der Kunden, um ihre Verhandlungsposition zu verbessern? Nein; zumindest nicht in erster Linie. Es handelt sich nämlich einfach um ein Missverständnis.

Im Fahrzeugzuliefererbereich ist die Zahl alter, aktueller, neuer und teils oder größtenteils redundanter Standards erdrückend. Automotive SPICE überschneidet sich mit zahlreichen Referenzmodellen und Standards: CMMI (inzwischen obsolet), ISO 15504 (SPICE, veraltet und vollkommen redundant), Funktionale Sicherheit ISO 26262 (teils redundant, teils weiterführend), ISO 9000 (weitgehend redundant), ISO/TS 16949 (Fokus auf Herstellungsprozesse, jedoch auch teils redundant), um nur einige Beispiele zu nennen.

Jeder Lieferant in dieser Branche hat solche Standards im Vertrag mit unterschrieben. Hunderte von Lieferanten investieren teils Millionenbeträge, um diese Modelle und Standards umzusetzen. Es werden unzählige Assessments durchgeführt. Rund um diese Standards herum entwickelte sich eine ansehnliche Beraterindustrie. Und doch fallen Hunderte von Assessments jedes Jahr negativ aus, meist mit kommerziellen Folgen. Die Problematik dauert seit etlichen Jahrzehnten an. Was ist der Grund für diese oft frustrierende Situation? Sind wir als Industrie etwa nicht lernfähig? Die sogenannte „Softwarekrise“, die inzwischen längst auch andere Disziplinen umfasst, wie Mechanik und Elektronik, besteht unverändert weiter. Eine Linderung ist nicht in Sicht.

Als Ursache werden oft verschiedene Faktoren angeführt:

  • Die Prozessdokumentation ist nicht ausreichend.
  • Eine umfassende Planung findet nicht oder nur ungenügend statt.
  • Die Testaktivitäten sind unzureichend.
  • „Links“ zwischen dem rechten und dem linken Teil des V-Modells sind lückenhaft.
  • Die Projektstrategie ist nicht definiert.
  • Die Anforderungen sind unzureichend und nicht abgestimmt.
  • Kerndokumente, wie Systemdesign oder Testplan, werden keinem systematischen Review unterzogen.
  • System- und Softwarekonfigurationen sind nicht dokumentiert.
  • Es werden keine oder zu wenige Audits durchgeführt und dokumentiert.
  • Veränderungen (Change Requests) werden nicht „sauber“ geprüft und mit den wichtigen Stakeholdern abgestimmt.
  • Die Zeit- und Aufwandsplanung ist unzulänglich.
  • Wir sind nicht agil.

… und so weiter. Vor lauter Bäumen sehen wir den Wald nicht mehr. Die Grundursache ist jedoch recht eindimensional und wird klarer, wenn der Grund für die Existenz dieser Standards auf den Punkt gebracht wird:

Diese Standards existieren ausschließlich, um das Risiko für den Kunden zu minimieren.

Schauen wir uns noch einige Beispiele an für die soeben aufgeführten „Grundursachen“:

  • „Die Anforderungen sind unzureichend und nicht abgestimmt.“ Anforderungen sind das A und O allen Tuns. Anforderungen werden aber nicht ernst genommen, weil sie häufig unscharf erscheinen und die Kompetenz in dieser Disziplin selten vorliegt. Dabei ist kaum etwas teurer als eine falsche Anforderung. Dieses Risiko wird leider oft übersehen oder gar wissentlich ignoriert.
  • „Die Zeit- und Aufwandsplanung ist unzulänglich.“ Projektmanagement ist eine der ältesten Herausforderungen des Homo sapiens. Und doch sind wir immer aufs Neue überrascht, dass Pläne und das Endergebnis oft lediglich recht lose korrelieren. Die Annahme muss lauten, dass Pläne, Aufwand und Zeitplanung nie stimmen werden. Dabei ist ein unnachgiebiges, aktives Risikomanagement die wichtigste Aufgabe des Managementteams.
  • „‚Links‘ zwischen dem rechten und dem linken Teil des V-Modells sind lückenhaft.“ Die sogenannten „Links“ (aka Traceability) werden benötigt, damit keine Anforderungen und Arbeitspakete übersehen werden. Dieses Risiko ist extraordinär und muss mit hohem Aufwand unter Kontrolle gebracht und gehalten werden.

… und so weiter. Buchstäblich alle Prozessqualitätsanforderungen lassen sich direkt oder indirekt auf das Thema Risikomanagement zurückverfolgen. Das ist der Grund, warum Automotive SPICE oder der funktionale Sicherheitsstandard ISO 26262 überhaupt existieren. Wenn kein Risikomanagement nötig wäre, gäbe es diese Standards nicht. Keinen einzigen! Es gäbe auch keine Audits, Assessments, und auch keine Prozessberater, die sich auf Prozessverbesserung spezialisieren würden.

Sowohl das V-Modell als auch die vor 20 Jahren postulierte Agilität sind Beraterkonzepte, die von den eigentlichen Aufgaben, Projektrisiken intensiv zu managen, mithilfe verschiedener Euphemismen lediglich ablenken. Fangen wir indes mit Risikominimierung anstatt mit „Prozessdesign“ oder „Agilität“ an, ergeben sich fast alle daraus resultierenden Aktivitäten praktisch von alleine, vorausgesetzt die technische und verwaltungstechnische Kompetenz ist in ausreichendem Maße vorhanden. Ich bin absolut überzeugt, dass fast jede betroffene Entwicklungsorganisation Millionen sparen könnte, wenn Risikominimierung von Beginn an im Zentrum der Managementaufmerksamkeit stünde.

Es ist mir natürlich bewusst, dass auch das Risikomanagement als Euphemismus aufgefasst werden kann. Als „Allheilmittel“ kann es wahrscheinlich einen ähnlich prekären Schaden anrichten wie andere Wunderkonzepte wie „V-Modell“, „Prozessmanagement“ oder „Agilität“.

Doch es ändert nichts an der Richtigkeit der Erkenntnis, dass die Risikominimierung für jede systementwickelnde Organisation das primäre Ziel darstellen muss. Beachtet man dieses Prinzip, wird es einfach zu erkennen, wie viel „Prozessdesign“ und  „Agilität“ benötigt werden, welche Planungsinstrumente und Planungswerkzeuge benötigt werden und wie viel externe Beraterunterstützung (und welcher Art) nötig ist.

Wichtiger noch: Es wird auf diese Weise deutlich, mit welcher Motivation sämtliche Qualitätsmaßnahmen durchgeführt werden sollten. Es wird auch klar, mit welchem „Mindset“ die Personalakquise betrieben werden muss.

Was der Kunde will

Es ist eine oft erstaunliche Erkenntnis, dass der Kunde im Grunde das Gleiche will wie der Lieferant: die Risikominimierung. Es werden Klauseln in den Lieferantenvertrag aufgenommen, in denen Agilität und/oder Automotive SPICE mit hohen Reifegraden als Ziel verkauft werden. Jedoch ergeben sich diese Ziele automatisch, wenn die Risikominimierung im Kern der Organisationsstrategie steht.

Risikominimierung soll indes nicht bedeuten, ängstlich zu werden und nur noch an potenzielle Probleme zu denken. Es ist die Aufgabe der Führung und des Projektmanagements, das Team vor der möglichen Angststarre abzuschirmen. Stattdessen sollte das Positive durch das Risikobewusstsein kultiviert werden.

Die so verstandene Risikominimierungsstrategie ermöglicht es, günstiger und leichter die geforderten Qualitätsziele zu erreichen: schlanke  Prozesse, Agilität und Kostenminimierung. Auch der Kunde wird Ihnen danken. Mit Sicherheit.

Roman Mildner
Über Roman Mildner 76 Artikel
Roman Mildner is ein zertifizierter Projektmanager (PMP), Berater bei der United Mentors und Buchautor. Er arbeitete seit 1992 in der IT-Branche und ist seit 1998 ein Managementberater. Zu seinen Beratungsschwerpunkten gehören IT-Strategieberatung und Prozessverbesserung, insbesondere im Bereich von Automotive SPICE. Weitere Details finden Sie auf seiner United Mentors-Seite.

Hinterlasse jetzt einen Kommentar

Kommentar hinterlassen

E-Mail Adresse wird nicht veröffentlicht.


*


*