O'Reilly logo

Automotive SPICE in der Praxis: Interpretationshilfe für Anwender und Assessoren by Jörg Zimmer, Lars Dittmann, Klaus Hörmann, Markus Müller

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

2 Interpretationen zur Prozessdimension
148
2.17 SUP.9 Problemlösungsmanagement
2.17.1 Zweck
Zweck des Prozesses ist es, sicherzustellen, dass alle entdeckten Probleme ermit-
telt, analysiert und bis zu ihrer Behebung gemanagt und überwacht werden.
Beim Problemlösungsmanagement geht es um das Vermögen der Organisation,
Probleme in einer strukturierten, nachvollziehbaren Art und Weise zu erfassen, zu
analysieren, zu überwachen, zu steuern und abzustellen. In der Praxis wird bei
der Implementierung dieses Prozesses oft ein Statusmodell zugrunde gelegt. Ein
solches Modell enthält die verschiedenen Zustände eines Problems (z.B. akzep-
tiert, in Bearbeitung, in Untersuchung, siehe Abb. 2–15) sowie die Bedingungen
für die Zustandsübergänge. Das Erheben von statistischen Daten, wie z.B. über
die Verweildauer eines Problems in einem bestimmten Status sowie die Auswer-
tung dieser Daten in Form von Trendanalysen, hilft dabei, die Verbesserung oder
Verschlechterung in der Problembearbeitung im Projekt über die Zeit festzustel-
len, Trends abzuleiten und falls nötig gegenzusteuern. Problemlösungsmanage-
ment kann für Probleme und Fehler aller Art angewendet werden und trägt
wesentlich zur Kundenzufriedenheit bei. Dieser Prozess hängt eng mit dem Ände-
rungsmanagementprozess (SUP.10) zusammen. SUP.10 beschreibt den Ablauf
innerhalb des Änderungsmanagements für alle Arten von Änderungen, nicht nur
für Probleme. Aus Sicht des Änderungsmanagements werden Probleme und sons-
tige Änderungen (z.B. Anforderungsänderungen, Designänderungen) in gleicher
Weise verwaltet, bearbeitet und verfolgt. SUP.9 konzentriert sich auf die speziell
für Problemlösung erforderlichen Arbeitsschritte und hat in BP7 eine klare
Schnittstelle zu SUP.10: Ein diagnostizierter Fehler ist der Ausgangspunkt für
Änderungen an Arbeitsprodukten und wird im Änderungsmanagement weiter
bearbeitet.
2.17.2 Besonderheiten in der Automobilindustrie
Bei der Entwicklung von Systemen für das Automobil gibt es einen Produktions-
beginn, zu dem das Produkt (ein System aus Hard- und Software) zu 100% fertig
und fehlerfrei sein soll. Jeder danach entdeckte Fehler führt zu Reparaturen oder
Rückrufaktionen und damit verbunden zu hohen Kosten und Imageverlusten des
Hinweis für Assessoren
Aufgrund ähnlicher Prozessanforderungen, gleicher Bearbeitung und gleicher Ver-
antwortlichkeit werden die Interviews beider Prozesse häufig zusammengefasst.
Zu beachten ist dabei das Zusammenspiel der beiden Prozesse: SUP.9 ist ein mög-
licher Inputgeber für SUP.10.
149
2.17 SUP.9 Problemlösungsmanagement
Unternehmens. Einem gut funktionierenden Problemlösungsmanagement kommt
daher im Vergleich zu einer kommerziellen Anwendungsentwicklung (bei der
Fehlerbehebung im Rahmen sukzessiver Softwarereleases problemlos möglich
ist) eine erhöhte Bedeutung zu.
Komplexe Automobilkomponenten bestehen aus zahlreichen Teilsystemen
mit verteilten Funktionen. Ein Problem, das an einer bestimmten Stelle im System
aufgetreten ist, muss nicht zwangsläufig an dieser Stelle verursacht worden sein.
Die Lokalisierung von Problemen wird dadurch erschwert.
2.17.3 Basispraktiken
BP1: Entwickle eine Problemlösungsmanagementstrategie. Entwickle eine Pro-
blemlösungsmanagementstrategie einschließlich Problemlösungsmanagementak-
tivitäten, eines Lebenszyklusmodell sowie Zuständigkeiten und Ressourcen für
die Durchführung dieser Aktivitäten.
Minimalbestandteile dieser Strategie sind:
Festlegungen zur Problemhandhabung einschließlich der benötigten Aktivitä-
ten (Problembeschreibung und -erfassung, Datensammlung, Analyse, Korrek-
tur usw.)
Verantwortliche für die Durchführung der Aktivitäten
System zur Problemverfolgung (Lebenszyklus inklusive Problemstatus, Pro-
blempriorisierung)
Zeitvorgaben zur Bearbeitung (maximale Zeit für einen Statusübergang)
Vorgaben zum Feedback an die Beteiligten (Problemmelder, Projektmitarbei-
ter, Management)
Die Problemlösungsmanagementstrategie kann Bestandteil eines Problemma-
nagementplans sein (Level 2) und sollte mit der Änderungsmanagementstrategie
(SUP.10, BP1) zusammenspielen.
BP2: Lege eine einheitliche und definierte Vorgehensweise für das Problemlö-
sungsmanagement fest. Eine einheitliche und definierte Vorgehensweise für das
Problemlösungsmanagement wird festgelegt, mit der gewährleistet wird, dass –
basierend auf der Problemlösungsmanagementstrategie – Probleme einheitlich
und nachvollziehbar erkannt, beschrieben, aufgezeichnet, untersucht, gelöst und
zukünftig verhindert werden. Schnittstellen zu betroffenen Parteien werden defi-
niert und gepflegt.
Eine auf der Problemlösungsmanagementstrategie basierende Vorgehensweise
muss festgelegt und dokumentiert werden (z.B. in Form eines Problemmanage-
mentplans). Sie beginnt meist mit der Meldung und Erfassung des Problems und
endet bei dessen endgültiger, nachgewiesener Abstellung. Es ist notwendig, die
2 Interpretationen zur Prozessdimension
150
Wege der Problemmeldung zu kanalisieren. Dazu sollte ein zentraler Ansprech-
partner im Projekt benannt und wie die übrigen Verantwortlichkeiten im Projekt
dokumentiert werden. Eine gute Toolunterstützung ist sinnvoll, z.B. über Ände-
rungsmanagementsysteme oder eine über das Intranet oder Internet verfügbare
Datenbank.
In größeren Projekten mit Teilprojekten ist es oft schwierig, zu bestimmten
Terminen (z.B. vor Auslieferungen) einen Überblick über alle offenen Probleme
und deren Bearbeitungsstand zu erhalten. Um das aufwendige Zusammentragen
der Informationen von Hand zu umgehen, empfiehlt es sich, ein Problemlösungs-
managementsystem aufzubauen, das folgende Anforderungen erfüllen sollte:
Informationen zur Problembeschreibung werden möglichst genau erfasst.
Dazu gehören neben der inhaltlichen Beschreibung auch die Bedingungen,
unter denen das Problem aufgetreten ist, das zugehörige Datum, die meldende
Person etc.
Jedes Problem wird eindeutig gekennzeichnet, z.B. mithilfe eines Nummerie-
rungsschemas.
Jedes Problem wird einer Person zur Analyse, Bearbeitung usw. zugewiesen.
Die Verantwortlichkeiten bzgl. der verschiedenen resultierenden Arbeits-
schritte sind eindeutig zugeordnet.
Verschiedene Problemstatus werden unterschieden. Dadurch kann genau
bestimmt werden, in welchem Status sich welches Problem gerade befindet
und wie lange es dort schon verweilt. Überschreitet die Verweildauer in einem
Status die Vorgabe, kann dieses schnell erkannt und darauf reagiert werden.
Es kann beispielsweise festgelegt werden, dass ein Kunde maximal 3 Tage
GESCHLOSSEN
Entwicklung
DOPPELT
ABGELEHNT
NICHT
REPRODU-
ZIERBAR
SPEZI-
FIKATIONS-
ÄNDE-
RUNG
ÄNDERUNGS-
TEAM (CCB)
IN UNTER-
SUCHUNG
OFFEN
AKZEPTIERT
IN
BEARBEITUNG
BEHOBEN VERSCHOBEN
GESCHLOSSEN
Kunde
ZUSTAND GESCHLOSSEN
ZUSTAND GEÖFFNET
Problem
Abb. 2–15
Beispiel für Problemstatus

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required