Agiles Fehlermanagement für digitale Produkte in der Automobilindustrie

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung
1.1 Problemstellung und Ziele
1.2 Aufbau der Arbeit

2 Einordnung des Themas
2.1 Prozess,- Aufbau- und Organisationsstruktur in der Automobilindustrie
2.2 Der Produktlebenszyklus in der Automobilindustrie
2.3 Qualitätsmanagement
2.4 Reifegradmanagement
2.5 Supply Chain Management

3 Grundlagen des Fehlermanagements
3.1 Fehler
3.2 Fehlermanagement

4 Softwareentwicklung
4.1 Vorgehensmodelle der Softwareentwicklung

5 DevOps

6 Experteninterviews

7 Ergebnisse
7.1 Entwurf eines agilen Fehlermanagementprozesses
7.2 Allgemeine Ideen, Hypothesen & Ansätze

8 Zusammenfassung

Literaturverzeichnis

Anhänge

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abb.1: Darstellung Kommunikation

Abb.2: Layerbasierte Produktarchitektur

Abb.3: Anforderung, Ergebnis, Qualität

Abb.4: Qualitätsmanagement PDCA-Zyklus

Abb.5: Relative Kosten für die Beseitigung eines Softwarefehlers

Abb.6: eingeführte Softwarefehler in der Anforderungsentwicklung

Abb.7: Reifegrade und Schlüsselbereiche des CMM

Abb.8: Reifegradstufen SPICE

Abb.9: Code Zeilen Vergleich

Abb.10: kontinuierlicher PEP - Lieferantenintegration

Abb.11: Fehlerentstehung, Fehlerbehebung, Kosten pro Fehler

Abb.12: Six-Sigma DMAIC-Zyklus

Abb.13: Ablauf 8D-Prozess

Abb.14: Wasserfallmodell

Abb.15: V-Modell

Abb.16: Scrum Framework

Abb.17: PDCA-Scrum Framework

Abb.18: Burndown Chart

Abb.19: Fehlerhandhabung in Scrum

Abb.20: DevOps im Überblick

Abb.21: State of DevOps Report

Abb.22: Entwurf eine agilen Fehlermanagementprozesses

1 Einleitung

Nachdem in der zweiten Hälfte des 20. Jahrhunderts im Zuge der Industrialisierung 3.0 die Grundlagen für Themen wie Digitalisierung, IoT, BigData, digitale Vernetzung und Künstliche Intelligenz (KI) gelegt wurden und nach der Jahrtausendwende Informationstechnologien und das Internet in jegliche Bereiche des alltäglichen Lebens vorgedrungen sind, steht die technologische Entwicklung jetzt an einem Punkt der exponentiellen Beschleunigung. Innerhalb eines Jahrzehnts hat sich für den durchschnittlichen modernen westlichen Bürger so viel verändert, wie es zuvor nur innerhalb einer Epoche möglich war. 10 Jahre zwischen der technischen Reife, Markteinführung und massenhafter Verbreitung waren für technologische Innovationen wie Telefon, Radio oder Fernsehgerät ein normaler Zeithorizont. Aus heutiger Sicht scheinen solch langen Zeiträume unvorstellbar, wenn es um die Verbreitung neuer Technologien und Innovationen geht. Smartphones, Tablets oder auch soziale Plattformen haben sich innerhalb von zwei bis drei Jahren nach der Markteinführung zu Massenprodukten entwickelt, die nicht mehr aus unserem Alltag wegzudenken sind. Alte Produkte wie Telefone, Radios und Fernsehgeräte wurden dabei ganz nebenbei ersetzt. Neue Ideen und Techniken, die etablierte Technologien, Produkte oder Dienstleistungen verdrängen oder gar vollständig ersetzen, werden als disruptive Innovationen bezeichnet. Die Folgen disruptiver Innovationen können sehr weitreichend sein. Unternehmen können innerhalb kurzer Zeit vom einstigen Branchenprimus in die Bedeutungslosigkeit absinken, es können neue Wirtschaftszweige und Branchen entstehen oder auch verschwinden und ganze Gesellschaften können dadurch grundlegend verändert werden.

Die Automobilindustrie wird von drei grundlegenden disruptiven Entwicklungen beeinflusst, die das Potential haben die wichtigste deutsche Industriesparte grundlegend zu verändern: Das Elektroauto, Das autonome Fahrzeug und Der Wechsel vom Privatbesitz hin zum Carsharing. Alle diese Entwicklungen sind getrieben von dem rasanten Fortschritt im Bereich der IT- und Kommunikationsindustrie. Die immer kürzer werdenden Innovationszyklen und die zunehmende Digitalisierung von Prozessen und Produkten stellt viele Unternehmen vor große Herausforderungen. Es entstehen völlig neue Geschäftsmodelle, die oftmals zu einer Verschmelzung mehrerer Branchen führen.

In der Vergangenheit bestand die Kernkompetenz der Automobilunternehmen darin, mit Hilfe eines großen Lieferantennetzwerkes Autos zu entwickeln, diese zu montieren und zu vertreiben. Dabei war es von entscheidender Bedeutung das große Netzwerk an Bauteillieferanten so effizient wie möglich zu steuern, um am Ende ein physikalisches Produkt von höchster ingenieurtechnischer Qualität anbieten zu können. In Zukunft wird das jedoch nicht ausreichen. Ein großer Anteil der Wertschöpfungskette wird aufgrund sich wandelnder Geschäftsmodelle auf Datenverarbeitung, Software und digitale Produkte entfallen. Die großen Automobilhersteller werden von Fahrzeugproduzenten zu Mobilitätsanbietern. Auch die Lieferantenstruktur wird sich massiv verändern. Softwaredienstleister, App- und Betriebssystementwickler werden zunehmend zu bedeutenden Lieferanten und Partnern der Automobilhersteller. Diese branchenübergreifende Zusammenarbeit erfordert nicht nur eine noch komplexere Steuerung des Lieferantenkreises. Um hier weiter erfolgreich zu agieren, müssen erfolgreiche, historisch gewachsene Methoden, Prozesse und Systeme, die für Bauteillieferanten optimiert sind, für die Lieferanten von digitalen Produkten mindestens angepasst und wohl in nicht wenigen Bereichen vollkommen neue, innovative Herangehensweisen, Prozesse und Methoden entwickelt werden. Nur wenn das auf höchstem Niveau gelingt, werden die Automobilunternehmen die disruptiven Innovationen für sich nutzen und ihre herausragende Position in der Wertschöpfungskette behaupten können.

Die extrem schnellen Innovationszyklen der IT-Industrie insbesondere im Bereich der Consumer Electronics führen dazu, dass Fahrzeuge aufgrund des langen Produktentstehungsprozesses (PEP) bei Markteinführung oftmals nicht dem aktuellsten Stand der Technik entsprechen. Die Kunden erwarten jedoch, dass auch ein so komplexes Produkt wie das Auto den schnellen Innovationszyklen der Software und Elektronikartikel folgt. Die großen Softwareunternehmen wie Apple, Facebook, Amazon etc. standen Anfang der Jahrtausendwende vor einem ähnlichen Problem. Aufgrund wachsender Komplexität, steigendem Funktionsumfang und schneller Innovationszyklen im Bereich der Hardwareausstattung konnte nicht mehr schnell genug entwickelt bzw. insbesondere eingeführt werden. Um diese Herausforderung zu lösen, wurden agile Methoden entwickelt, um flexibel, schnell und trotzdem zielorientiert Software entwickeln zu können.

In einem Auto befinden sich eine hohe Anzahl an verschiedenen Komponenten: Bauteile, Elektronik und Software. Die große Herausforderung für einen OEM, auch im Vergleich zu den großen Softwareunternehmen, besteht nun darin, die unterschiedlichen Entwicklungszeiten der Komponenten während des Produktentstehungsprozesses aufeinander abzustimmen und dabei die steigenden Qualitätsanforderungen an das Gesamtprodukt zu gewährleisten. Ein wichtiger Bestandteil der Qualitätssicherung ist das Fehlermanagement. Um die hohen Kundenanforderungen in Bezug auf digitale Produkte im Fahrzeug und den immer schnelleren Innovationszyklen gerecht zu werden muss das Fehlermanagement an die agilen Entwicklungsmethoden der Softwarelieferanten angepasst werden, um ein aktuelles, sicheres und fehlerfreies digitales Produkt zu liefern.

1.1 Problemstellung und Ziele

Um die Problemstellung zu verdeutlichen und daraus die Ziele dieser Arbeit abzuleiten, bietet es sich an, einen beispielhaften vereinfachten Prozess einer fehlerhaften digitalen Anwendung zu beschreiben. Eine digitale Anwendung, die derzeit von Fahrzeuganbietern angeboten wird ermöglicht es, die Tür eines Fahrzeuges mittels einer Applikation zu öffnen (Digital Key). Dazu muss eine Kommunikation zwischen dem Smartphone und dem Fahrzeug, zwischen dem Smartphone und den Unternehmensservern, zwischen verschiedenen internen Unternehmensservern, zwischen Unternehmensserver und Fahrzeug stattfinden und zwischen verschiedenen Systemen innerhalb des Fahrzeuges selbst stattfinden (s. Abb. 1). Die Systeme, Module und Einheiten, die dabei miteinander kommunizieren, wurden nicht im Zuge der Anwendung „Digital Key“ entwickelt, sondern wurden zu unterschiedlichen Zeitpunkten von unterschiedlichen Entwicklern, Teams oder gar Unternehmen implementiert. So kann bspw. das Programmieren und Betreuen der Smartphoneapplikation durch einen externen Softwarelieferanten erfolgen, die Backendsysteme werden jedoch intern von verschiedenen Abteilungen betreut. Steht nun ein Kunde vor seinem Auto und kann dies nicht öffnen, wird die erste Reaktion sein, den Hersteller zu kontaktieren. Die möglichen Fehlerquellen und Ursachen können dabei nahezu unendlich groß sein.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Darstellung Kommunikation

Quelle: eigene Darstellung

Wie kann nun in diesem Fall ein effektives schnelles Fehlermanagement stattfinden? Wie kann der Fehler eingegrenzt werden? Wer ist für das Beheben des Fehlers zuständig ist? Wie können Fehler möglichst vor der Nutzungsphase lokalisiert und ausgeschlossen werden? Die Antworten auf diese Fragen sind in verschiedensten Bereichen zu suchen. Organisationsstruktur, Zuständigkeiten, Qualitätsmanagement, Lieferantenmanagement, Standardisierung während der Entwicklung und Testmanagement sind nur einige Bereiche, die abgesehen von der technischen Komponente bei der Beantwortung der Fragen zu betrachten sind.

Ziel ist es zunächst ein Überblick zu schaffen, welche Bereiche im Unternehmen vor Herausforderungen stehen, um ein kundenorientiertes Fehlermanagement von digitalen Produkten zu ermöglichen aber gleichzeitig den schnellen Entwicklungszyklus bei digitalen Anwendungen mitbestimmen zu können. Dazu ist es einerseits notwendig darzustellen, wo die Automobilhersteller „herkommen“, welchen herausragenden Erfahrungsschatz sie haben. Auf der anderen Seite soll aber auch betrachtet werden, ob ein Blick in Richtung Prozesse und Vorgehensweisen in reinen IT-Unternehmen lohnenswert ist und ggf. Lösungskonzepte ableitbar sind. Es sollen erste Ansätze eines Konzepts entwickelt werden, wie ein agiler Fehler­managementprozess zwischen Kunde, OEM und Softwarelieferant aussehen kann. Dazu muss zunächst der aktuelle PEP mit Fokus auf das Fehlermanagement beschrieben werden.

1.2 Aufbau der Arbeit

Die vorliegende Arbeit unterteilt sich in acht Kapitel. Das erste Kapitel umfasst die Motivation, die Formulierung des Problems sowie die Zielsetzung der Arbeit. Im zweiten Teil werden angrenzende Gebiete, die Qualitätsmanagement, Supply Chain Management und Reifegradmanagement aufgezeigt, die einen bedeutenden Einfluss auf das Fehlermanagement haben. Ohne Verständnis dieser Bereiche ist das Fehlermanagement nicht vollständig erfassbar. Nur durch die Beschäftigung mit diesen Bereichen können Umfang und Art der notwendigen Anpassungen hergeleitet werden. Das dritte Kapitel behandelt das Thema Fehlermanagement allgemein. Hier werden die wesentlichen Begriffe definiert und eingeordnet, die Relevanz eines effektiven, effizienten Fehlermanagements aufgezeigt, sowie wesentliche Fehlermanagementmethoden vorgestellt. In Kapitel 2 bis 3 stehen also die bisherigen Erfahrungen der (traditionellen) Automobilhersteller in den vorgestellten Bereichen im Vordergrund. Im vierten Kapitel wird auf die Besonderheiten der Softwareentwicklung eingegangen. Dabei wird der Fokus auf Methoden gelegt, wie sie vor allem in den großen Softwareunternehmen eingesetzt bzw. entwickelt wurden. Es werden verschiedene Vorgehensmodelle aufgezeigt und am Beispiel von Scrum ein agiles Vorgehen in der Softwareentwicklung beschrieben. Hier wird u.a. ein Prozess dargestellt, wie ein Umgang mit Fehlern während der agilen Entwicklung mit Scrum gelingen kann. Anschließend wird im fünften Kapitel auf die immer engere Verknüpfung von Entwicklung und Betrieb (DevOps) eingegangen. Dabei wird auch kurz das Thema der Softwaretest, insbesondere automatisierte Tests kurz vorgestellt. Um einen Einblick zu bekommen, vor welchen Herausforderungen die Automobilindustrie im Bereich des Fehlermanagements steht, wurden Experteninterviews durchgeführt. Das Vorgehen und die Ziele des Experteninterviews sind Thema des sechsten Kapitels. Im siebten Kapitel werden einige Thesen aus dem deskriptiven Teil und den Interviews abgeleitet, sowie ein übergeordneter Ansatz eines Fehlermanagementprozesses aufgezeigt. Im vorletzten Kapitel findet eine Zusammenfassung der Arbeit statt.

2 Einordnung des Themas

Ziel des Abschnitts ist es dem Leser zu vermitteln, wie Automobilhersteller in ihrer Organisation aufgebaut sind, welche Managementbereiche, -prozesse und -methoden rund um das Fehlermanagement relevant sind und welche Rolle Lieferanten in dem komplexen Produktlebenszyklus eines Fahrzeugs spielen. Ohne die Einordnung des Themas ist eine logische Herangehensweise zu Entwicklung eines agilen Fehlermanagementprozesses schwer nachvollziehbar. Der gesamte Produktlebenszyklus und seine Bestandteile mit Fokus auf Qualitäts-, Fehler- und Lieferantenmanagement wird kurz beschrieben.

2.1 Prozess,- Aufbau- und Organisationsstruktur in der Automobilindustrie

Durch die Digitalisierung ergibt sich für die Automobilhersteller neben der traditionellen Wertschöpfungskette, Fahrzeugentwicklung, Produktion, Verkauf eine neue Wertschöpfungskette deren Grundressource Daten, genaugenommen Kundendaten, sind. Die Herausforderung für die Zukunft wird darin bestehen traditionelle und digitale Wertschöpfungsketten bzw. Geschäftsmodelle in die bestehenden Unternehmensstrukturen zu integrieren. Diese Verknüpfung wird zu großen Herausforderungen in Bezug auf Organisationsaufbau, Zuständigkeiten und Abstimmungen führen. Daher wird in diesem Kapitel kurz der Aufbau bzw. die Organisationsstruktur heutiger OEMs vorgestellt.

Eine zielgerichtete Aufgabenbewältigung ist nur durch eindeutig geklärte Verantwortlichkeiten, Befugnisse und Beziehungen zwischen den Personen bzw. Abteilungen im Unternehmen möglich. In den meisten Automobilunternehmen hat sich die Matrixorganisation als Organisationsform (Aufbauorganisation) durchgesetzt. Diese setzt sich zum einen aus den einzelnen Linien bzw.- Fachbereichen (horizontal) und zum anderen aus den einzelnen Projekten oder auch Fahrzeugbaureihen (vertikal) zusammen. Dabei sind die Fachbereiche nach den traditionellen Fahrzeugmodulen Karosserie, Interieur, Elektrik/Elektronik, Fahrwerk und Antrieb strukturiert. Die operative Zusammenarbeit zwischen Projekt- und Linienorganisation erfolgt über die sogenannten Arbeitspakete. Äquivalent zu einem klassischen Kunden-Lieferanten-Verhältnis beauftragt der Projektleiter (als interner Kunde) die Linienabteilungen (als interne Lieferanten) und externe Partner mit Hilfe definierter Arbeitspakete.¹ Die einzelnen Fachbereiche arbeiten projektübergreifend.² Ihr Ziel ist es durch Skaleneffekte und Kommunalität ein projektübergreifendes Gesamtoptimum anzustreben.³ Die Fahrzeugprojekte verfolgen hingegen die Produktziele und -interessen, durch eine maximale Eigenständigkeit und kundenwirksame Differenzierung.⁴ Dieses bewusst erzeugte Spannungsfeld zwischen den Fachbereichen und Fahrzeugprojekten dient auch der Qualitätssicherung.

Die Ablauforganisation beschäftigt sich mit dem Ablauf der Geschäftsprozesse im Unternehmen. Die Normenreihe ISO 9000 ff. gliedert die Geschäftsprozesse in drei Prozesskategorien: Kernprozesse, Managementprozesse und Supportprozesse. Als Kernprozesse gelten alle Tätigkeiten, die direkt an der Wertschöpfung des Unternehmens beteiligt sind und einen unmittelbaren Kundennutzen erzeugen. Diese sind bspw. der Produktentwicklungsprozess und der Marketingprozess. Managementprozesse definieren, verfolgen und überwachen die Zielvorgaben des Unternehmens. Eine typische Form der Managementprozesse stellt das Projektmanagement dar. Prozesse, die zur Unterstützung der Kern- und Geschäftsprozesse dienen, werden als Supportprozesse bezeichnet (bspw. Qualitäts- und Informationsmanagement). Die Durchführung der Geschäftsprozesse wird durch verschiedene Methoden und Tools unterstützt.

Der über Jahrzehnte gewachsene Prozess- und Organisationsaufbau hat sich für das traditionelle Geschäftsmodell der OEM´s bewährt. Ob der bisherige Organisationsaufbau mit Blick auf disruptive Entwicklungen und damit einhergehend neue Geschäftsmodelle, die zunehmend zentrale Rolle der Digitalisierung und Vernetzung weiterhin optimal ist, wird diskutiert.

2.2 Der Produktlebenszyklus in der Automobilindustrie

In der Fachliteratur wird der Produktlebenszyklus klassischerweise in die Phasen Einführung – Wachstum – Reife – Sättigung – Niedergang unterteilt.⁵ Dabei werden zwei wichtige Phasen nicht betont, die eine entscheidende Rolle bei der Wertschöpfung eines OEM einnehmen. Zum einen die Phase der Produktentstehung, welche wesentlich für den Erfolg des Produktes am Markt ist und während der ein großer Teil der Gesamtkosten anfallen. Zum anderen werden die Dienstleistungen außer Acht gelassen, die nach dem Verkauf des Produktes angeboten werden und die in der Automobilindustrie einen nicht unbedeutenden Anteil am Gewinn haben - die „After-Sales-Services“. Der Produktlebenszyklus umfasst daher vielmehr die 3 Phasen: die Produktentstehung, den Betrieb und die Phase Aftersales.⁶ Parallel zum gesamten Produktlebenszyklus, kommen eine Vielzahl an bereichsübergreifenden Managementprozessen und unterstützenden Prozessen zum Einsatz mit dem Ziel die Kernprozesse zu optimieren. Kernprozesse sind Prozesse, die unmittelbar zur Wertschöpfung des Unternehmens beitragen, wie bspw. der Produktions- oder der Entwicklungsprozess.

2.2.1 Der Produktentstehungsprozess in der Automobilindustrie

Der PEP umfasst alle Prozesse, um ein Produkt termin-, qualitäts- und kostengerecht am Markt zu platzieren. Dabei besteht die große Herausforderung darin die Entwicklung der Vielzahl an einzelnen Komponenten, die in einem Automobil verbaut sind, aufeinander abzustimmen. Die Komponenten können dabei den Kategorien: Mechanik, Elektronik und Software zugeordnet werden. Ein zunehmendes Problem im Zuge der Koordinierung des Entwicklungsprozesses stellt die Harmonisierung der unterschiedlichen Innovationszyklen der einzelnen Komponenten dar. Trotz steigender Komplexität des Gesamtproduktes müssen dabei die hohen Qualitätsanforderungen des Kunden und des Gesetzgebers erfüllt werden.

Der traditionelle PEP folgt einer inkrementellen Vorgehensweise, dh. die Abläufe folgen einer relativ starren Struktur, die durch das Erreichen von Meilensteinen und Freigaben geprägt ist. Dabei wird immer die Gesamtentwicklung und -freigabe eines Fahrzeuges durchgeführt und nicht beachtet, welche Komponenten im Vergleich zum Vorgänger maßgeblich verändert wurden.⁷ Durchschnittlich dauert die Serienentwicklung eines Fahrzeuges ca. 30 Monate bis Start of Production.⁸ Die Innovationszyklen von Elektrik‐ und Elektronik (E/E)-Systemen betragen hingegen oft nur wenige Monate. Am schnellsten finden Innovationen jedoch im Bereich der Software statt, sodass im schlimmsten Fall der Kunde ein Fahrzeug mit Software- und Elektronikkomponenten erhält, deren Anforderungen und Spezifikationen drei Jahre alt sind.⁹

Diese historisch gewachsene produktionsorientierte Herangehensweise der Automobilindustrie war bisher erfolgreich und logisch. Durch den Einzug der digitalen Dienste und Anwendungen wird dieser starre, produktionsorientierte Produktentstehungsprozess jedoch den schnellen Innovationszyklen, besonders im Bereich der Consumer Electronics, nicht mehr gerecht. Die Erwartungen der Kunden an das Produkt „Automobil“ werden von der Digitalisierung stark beeinflusst. Es muss ein Wandel von der produktionsorientierten zu einer kundengerechten, funktionsorientierten Produktentstehung stattfinden. Nicht nur, um den Kundenanforderungen gerecht zu werden, sondern auch, um sich gegen eine wachsende Konkurrenz der großen IT-Unternehmen wie Google, Apple, Amazon und Co. durchzusetzen.

Am Fachgebiet für Qualitätsstrategie und Qualitätskompetenz der TU Berlin wurde ein systematisches Vorgehen entwickelt, welches einen Produktentstehungsprozess ermöglicht, der die unterschiedlichen Entwicklungsstände und Innovationsgeschwindigkeiten verschiedener Komponenten berücksichtigt (s. Abb. 2). Als Vorlage dieser neuen Vorgehensweise diente das Schichtenmodell aus der IT bzw. Softwareentwicklung. Demnach kann die neue Produktstruktur in Layer aufgebaut werden.¹⁰ Komponenten, die schnelleren Innovation unterliegen, befinden sich auf oberen Layern (hier: Layer X); Komponenten, die nur selten von Innovationen betroffen sind, befinden sich auf unteren Layern (hier: Layer A).¹¹

Somit ist es möglich, dass Komponenten des obersten Layer mehrere Innovationszyklen durchlaufen, während auf den unteren Layern keine Innovationen stattfinden. Die Vorteile dieser Herangehensweise liegen auf der Hand. Die Innovationszyklen folgen nicht mehr den Zyklen, in denen ein neues Gesamtprodukt entwickelt wird. Außerdem wird eine teure und unflexible Gesamtabsicherung und ‐freigabe eines Fahrzeuges nicht mehr für jede Innovation benötigt.¹² Soll ein neues Produkt/Fahrzeug auf den Markt gebracht werden, können die Module der Layer kombiniert werden. Somit werden kürze Entwicklungszeiten ermöglicht.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Layerbasierte Produktarchitektur

Quelle: Ramm, A; Dust, R. (2017), S.115

Die verwendeten Absicherungsmethoden und -tools sind abhängig von den Produkten des jeweiligen Layers. Daher müssen auch die Managementmethoden, Prozesse und Tools angepasst werden, um die Vorteile der schnellen Innovation nicht zu gefährden. Die QM-Methoden, speziell Qualitätssicherung, Fehler- und Lieferantenmanagement sind eher auf eine schnelle Gesamtabsicherung optimiert. Der Fokus dieser Arbeit liegt primär auf einem effektiven agilen Fehlermanagement für digitale Dienste und Apps. Digitale Dienste und Apps sind Komponenten mit den schnellsten Innovationszyklen und finden sich daher im obersten Layer des Modells wieder.

Die oben beschriebenen 3 Phasen des Produktlebenszyklus Produktentstehung, Betrieb und Aftersales verschmelzen im Zuge der permanenten Innovationszyklen und können nicht mehr eindeutig voneinander getrennt werden. Es findet eine permanente, ständige Optimierung der Produkte statt (besonders im digitalen Bereich). Dabei spielt der Kundenkontakt eine entscheidende Rolle, welcher hauptsächlich während des Betriebes und des Aftersales stattfindet. Es ergibt sich ein kontinuierlicher Produktentstehungsprozess, der die Phasen des Betriebes und des Aftersales integriert.

Die Produktentwicklung ist ein fundamentaler Bestandteil des PEP. Auf die verschiedenen Vorgehensmodelle wird im Kapitel Softwareentwicklung genauer eingegangen.

2.3 Qualitätsmanagement

Gemäß EN ISO 9000 ff. ist Qualität der Grad, in dem ein Satz inhärenter Merkmale eines Objekts Anforderungen erfüllt (s. Abb. 3). Management beschreibt aufeinander abgestimmte Tätigkeiten zum Führen und Steuern einer Organisation. Daraus lässt sich ableiten, dass Qualitätsmanagement abgestimmte Tätigkeiten zum Führen einer Organisation umfasst, die das Ziel haben die Anforderungen an ein Objekt mit den höchstmöglichen Grad zu erfüllen. Dabei kann ein Objekt sowohl als Produkt, als auch als Prozess verstanden werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Anforderung, Ergebnis, Qualität

Quelle: eigene Darstellung

Die zentralen Aufgaben des Qualitätsmanagements umfassen die Qualitätsplanung, die Qualitätslenkung, die Qualitätssicherung sowie die Qualitätsverbesserung. Im Zuge der Qualitätsplanung werden die Qualitätsziele sowie deren Prozesse und Ressourcen festgelegt, die zum Erreichen der festgelegten Ziele benötigt werden. Die Qualitätslenkung hat das Ziel die Qualitätsanforderungen zu erfüllen. Die Qualitätsverbesserung befasst sich mit den potentiellen Verbesserungsmöglichkeiten in Bezug auf Wirksamkeit, Effizienz und Rückverfolgbarkeit. Die Qualitätssicherung umfasst die Tätigkeiten zur Erzeugung von Vertrauen, dass Qualitätsanforderungen erfüllt werden und umfasst drei große Zuständigkeiten: Messen und Prüfen, Fehlermanagement und Anforderungsmanagement.¹³ Das Anforderungsmanagement legt die Anforderungen an ein Produkt fest, welche durch entsprechende Tests gemessen und überprüft werden. Fehler, die dabei erkannt werden, werden durch ein effektives Fehlermanagement verhindert bzw. beseitigt (Bisschen komisch der Satz…). Als Kern dieser Arbeit ist dem Fehlermanagement ein eigenes Kapitel gewidmet.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: Qualitätsmanagement PDCA-Zyklus

Quelle: eigene Darstellung

Die Hauptkomponenten des QM lassen sich im Sinne des Demingkreises veranschaulichen (s. Abb.4)

In vielen Produktgruppen, wie bspw. der Unterhaltungselektronik oder Smartphones sind traditionelle Qualitätsmerkmale wie eine möglichst lange Lebensdauer und Robustheit keine zentralen Anforderungen mehr an das Produkt. Aufgrund der kurzen Innovations-, und damit auch Produktlebenszyklen und einem überzeugenden Marketing werden die Konsumenten dazu angehalten Produkte in immer schnelleren Rythmen zu ersetzen. Vor allem das deutsche Verhältnis zu Qualität entspricht eher dem traditionellen Verständnis, was sicherlich im Hinblick auf Ressourcenverbrauch und Umweltbelastung positiv zu bewerten ist. In den Industriebereichen, in denen besonders schnelle Innovationszyklen herrschen, sind deutsche Unternehmen jedoch eher weniger vertreten. Da auch in der Automobilindustrie die Innovations- und Produktzyklen immer kürzer werden und Entwicklungen wie Elektrifizierung und Carsharing voranschreiten ist das traditionelle Qualitätsverständnis im Sinne der Robustheit und Haltbarkeit eventuell nicht mehr optimal. Diese gewagte These sollte jedoch keineswegs damit verwechselt werden, dass die Qualität in Bezug auf Sicherheit bzw. sicherheitsrelevante Systeme zu hinterfragen ist. In diesem Bereich hat der Qualitätsanspruch absolute Priorität. Erst recht, wenn es um das Vertrauen der Nutzer in Hinblick auf digitale Anwendungen im Fahrzeug oder autonomes Fahren geht.

2.4 Reifegradmanagement

„Das Reifegradmanagement ist ein operatives Instrument zur Umsetzung der VDA Qualitätsoffensive. Es beschreibt einen Prozess der Lenkung und Steuerung notwendiger Tätigkeiten, zur Erfassung der Reife sowie die Vorgabe von Zielen und Aktivitäten im Projektentwicklungsprozess“.¹⁴ Ziel des Reifegradmanagements ist es Transparenz in Bezug auf den Entwicklungsstand sicherzustellen, frühzeitig Risiken und Zielabweichungen zu erkennen, Basisdaten für operative und strategische Entscheidungen bereitzustellen sowie die Ermittlung von Trendverläufen und Prognosewerten zum Projektende durchzuführen.¹⁵ Dabei wird zum einen die Produktreife und zum anderen die Prozessreife ermittelt, wobei Kriterien wie bspw. die Anzahl der Fehlerpunkte, Lastenhefte oder Prozessserien als Indikatoren für den Reifegrad ermittelt werden. Ein konsequenter Fehlerbehebungsprozess ist dabei eine Voraussetzung für das Erreichen einer definierten Produkt- bzw. Prozessreife. Da die Produkt- bzw. Prozessreife vor Beginn der Entwicklung definiert wird, liegt dem Reifegradmanagement ein eher sukzessives Vorgehen zu Grunde, was in Bezug auf agiles Vorgehen im Bereich der Softwareentwicklung zu Problemen führt. Das Festlegen von Meilensteinen ist bei einem agilen Vorgehen eine Herausforderung, da hier der Erwartungshorizont erst im Laufe des Entwicklungsprozesses konkretisiert wird.

2.4.1 Anforderungsmanagement

Anforderungsmanagement ist ein wesentlicher Bestandteil des Qualitätsmanagements. Laut Rupp ist eine Anforderung eine Aussage über eine zu erfüllende Eigenschaft oder eine zu erbringende Leistung eines Produktes, eines Prozesses oder der am Prozess beteiligten Personen.¹⁶ Daraus leitet sich die Definition des Anforderungsmanagements ab: (Requirements management is) “a systematic approach to eliciting, organizing and documenting the requirements of the system, and process that establishes and maintains agreements between the customer and the project team on the changing requirements of the system.“¹⁷

In Abbildung 5 sind die relativen Kosten für die Beseitigung eines Softwarefehlers in Abhängigkeit von der Phase der Softwareentwicklung dargestellt. Es ist deutlich zu erkennen, dass Fehler, die während des Betriebes bzw. der Wartungsphase auftreten einen Großteil der relativen Kosten verursachen. Zieht man zusätzlich in Betracht, dass 55% der Fehler, die ein Software-Produkt aufweist, durch unzureichende Anforderungsanalyse und -definition zustande kommen, wird die Relevanz klar definierter Anforderungen deutlich (s. Abb. 6).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5: Relative Kosten für die Beseitigung eines Softwarefehlers

Quelle: eigene Darstellung in Anlehnung an Leffingwell, D.; Widrig, D. (2000)

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6: eingeführte Softwarefehler in der Anforderungsentwicklung

Quelle: eigene Darstellung in Anlehnung an Grande, M. (2011)

Als Beispiel für eine Fehlerbehebung in einer sehr späten Phase sind Rückrufaktionen zu nennen. Diese sind mit enormen Kosten verbunden, denn die Rückrufaktionen fallen häufig unter die Garantie bzw. Kulanzregelungen der Hersteller, betreffen schnell tausende oder sogar hunderttausende Fahrzeughalter und werden für diese meist kostenfrei angeboten. Der dabei einhergehende Imageverlust verursacht ebenfalls beträchtliche finanzielle Schäden.

Die Dokumentation der Anforderungen erfolgt in einem Lasten- und Pflichtenheft und wird im Laufe des PEP durch das Änderungsmanagement angepasst. Das Lastenheft beschreibt alle Forderungen des Auftraggebers bezüglich der Leistungen und Lieferungen an den Auftragnehmer. Synonyme sind Spezifikation, Kundenspezifikation oder Anforderungsspezifikation.¹⁸ Im Pflichtenheft beschreibt der Auftragnehmer, wie er die Forderungen aus dem Lastenheft umzusetzen gedenkt.¹⁹ Die hier spezifizierten Anforderungen bilden oftmals auch die Grundlagen für die Werk- bzw. Dienstverträge der Lieferanten. Erst mit dem Dokumentieren der Anforderungen und den damit verbundenen Abnahmekriterien können die Anforderungen durch spätere Tests überprüft werden. Je detaillierter die Anforderungen formuliert und kommuniziert werden, desto wahrscheinlicher wird es, ein fehlerarmes Produkt zu erhalten, welches den Anforderungen des Auftraggebers entspricht.²⁰ In agilen Projekten stellt das frühe detaillierte Festlegen von Produktanforderungen jedoch eine Herausforderung dar, denn hier werde wie oben schon erwähnt, die Anforderungen erst im Laufe des PEP durch iterative Schritte in enger Absprache mit dem Auftraggeber konkretisiert. Dazu wird im Kapitel über agile Entwicklungsmethoden umfassender eingegangen.

2.4.2 Übersicht Reifegradmodelle

Reifegradmodelle dienen der Bewertung, Qualitätsbeurteilung und Optimierung von Prozessen im Unternehmen. Die Verwendung von Reifegradmodellen bei der Softwareentwicklung führt zur Standardisierung des Softwareentwicklungsprozesses. Oftmals stehen Standardisierung und ein damit verbundener hoher Aufwand für die Dokumentation und agile Vorgehensweisen im Widerspruch. In der Vergangenheit haben sich verschiedene Modelle etabliert. Im Folgenden werden die wichtigsten Modelle kurz vorgestellt.

CMM Capability Maturity Model

In den späten Sechzigerjahren standen viele Softwareprojekte vor dem Problem, dass Budget- und Zeitrestriktionen, Qualitätsmaßstäbe und Anforderungen nicht mehr eingehalten werden konnten. In Folge dessen entwickelte das SEI (Software Engineering Institute) das Capability Maturity Model. Dieses Modell wurde hauptsächlich für die Softwareentwicklung entworfen und bildet die Grundlage für später entwickelte Modelle wie CMMI, SPICE & AutomotiveSPICE.

Die oberste Ebene des CMM wird durch fünf Reifegrade (initial, gemanagt, definiert, quantitativ gemanagt, und optimierend) gebildet (s. Abb.7). Ein Reifegrad zeigt an welche Prozessreife ein Unternehmen aufweist. Um einen bestimmten Reifegrad zu erlangen, muss das Unternehmen alle Anforderungen der darunterliegenden Reifegrade erfüllen. Der unterste Reifegrad beschreibt dabei Unternehmen, die keine erkennbare Planungsaktivitäten vorweisen (Level 1).²¹ Unternehmen, die über Organisationsstrukturen auf Basis selbstoptimierender Prozesse verfügen, erreichen den höchsten Reifegrad (Level 5).²² Für jeden Reifegrad existieren untergeordnete Ebenen, durch die Schlüsselbereiche zugeordnet werden (außer Level 1), die für das Erreichen des Reifegrades relevant sind. In den wiederum untergeordneten Ebenen werden die Ziele (goals), Fähigkeiten (common features) und Methoden (key practices) der Schlüsselbereiche spezifiziert.²³

[...]

---

¹ Vgl. Hab, G., Wagner, R. (2017), S.41

² Vgl. Dust, R. (2018), S. 117

³ Vgl. ebenda

⁴ Vgl. ebenda

⁵ Vgl. Blinn, N. et al. (2008), S. 712

⁶ Vgl. Blinn, N. et al. (2008), S. 715

⁷ Vgl. Ramm, A.; Dust, R. (2017), S. 116

⁸ Vgl. ebenda

⁹ Vgl. Ramm, A.; Dust, R. (2017), S. 116

¹⁰ Vgl. Ramm, A.; Dust, R. (2017), S. 117

¹¹ ebenda

¹² Vgl. ebenda

¹³ Vgl Sommerhoff, B. et al (k.A.), S.3

¹⁴ Vgl. Dust, R. (2018a), S. 138

¹⁵ ebenda

¹⁶ Rupp, C. (2001), S10

¹⁷ Leffingwell, D.; Widrig, D. (2000), S. 16

¹⁸ Grande, M. (2011), S.6

¹⁹ ebenda

²⁰ Grande, M. (2011), S.10

²¹ Vgl. Hoffmann, W.D. (2013), S.521

²² Vgl. Hoffmann, W.D. (2013), S.521

²³ Vgl. ebenda