Die FMEA als Fehlerursachen und -folgen Werkzeug in Prozessen.
Die FMEA eignet sich nicht nur um Konstruktion, Design oder ein System zu analysieren. Auch Prozesse lassen sich auf Fehlerursachen und Fehlerfolgen, die dann weitere Risiken initiieren könnten, untersuchen.
Der PmBok Guide 6th besteht aus fünf Prozessgruppen die insgesamt 49 Prozesse involvieren. Da auch im Projektmanagement viele Fehler unterlaufen, die zu interdependenten Folgen führen, bietet sich die FMEA geradezu an, diese „Fehler Netzwerke“ zu enttarnen.
Die 7 Schritte der FMEA
Schritt 1: Vorbereitung und Planung: Scoping
· Projektplanung. Fast jede FMEA ist ein Projekt. Ein Projekt hat immer einen Anfang und ein Ende. Es existiert aber auch eine fortlaufende FMEA im Rahmen von KVP, die nicht als Projekt definiert werden kann.
· Scoping. Diese Tätigkeit korreliert ganz intensiv mit dem Kapitel 5 im PmBok Guide 6, „Scope Management“ oder „Inhalts- und Umfangsmanagement“. Hier arbeite ich immer mit dem Beispiel: „Entwicklung und Integration eines Robotik Systems in einer Produktionsumgebung.“ Die Vorgehensweise im Scoping ist während der FMEA sehr ähnlich dem Prozess „Anforderungen sammeln“ und „Inhalt und Umfang definieren“, aus dem Kapitel 5 des PmBok Guides*. Hier kann man sich für das Scoping handfeste Inspiration aneignen.
a) Die Systemgrenzen: Bei unserem „Stempelbeispiel“ besteht das innere System aus „Stempelkappe, Stempelfuß und Gummiplatte“. Altgriechisch beurteilt, handelt es sich um ein System. FMEA bezogen, kann man die systemische Sicht hier vernachlässigen, insbesondere wenn Stempelkappe und Stempelfuß aus einem Stück gegossen sind. Aber auch sonst existieren zwischen den drei Komponenten keine Interaktionen, die in irgendeiner Weise den Dreiklang Fehlerart, Fehlerursache und Fehlerfolgen befruchten könnten. Ausnahme wäre eine nicht sachgemäße Verbindung zwischen Stempelkappe und Stempelfuß oder Stempelfuß und Gummiplatte. Das Thema wäre schnell erledigt. Ein Stempelkissen mit Farbe gehört ebenfalls zum inneren System. Ohne Farbe, kann der Stempel seine Funktion nicht erfüllen.
Im Falle des Stempels sind des Weiteren die Umgebungsfaktoren wichtig, die das Gesamtsystem ausmachen. Stempel, Stempelkissen und die Hand des Benutzers ergeben zusammen das System.
Eine Hand jedoch, die die Richtung vorgibt und Druck auf den Stempel ausübt, gehört zur Umgebung oder zu einem äußeren System, da es nicht unbedingt eine Hand sein muss. Es könnte auch eine mechanische Vorrichtung als „Druckgeber“ dienen, die bspw. durch eine Lichtschranke ausgelöst wird.
Das innere und äußere System (Umgebung) sollte durch ein Boundary Diagramm dargestellt werden.
Ein Roboter jedoch, der menschliche Arbeit in einer produktionellen Infrastruktur ersetzen soll – seine Systemgrenzen sind elementar für den weiteren Verlauf des Projekts.
Schon allein aus Sicherheitsgründen müssen die Systemgrenzen genauestens festgelegt werden, da sich Menschen im Umfeld bewegen können. Ein PMP zertifizierter Projektmanager würde in jedem Fall mit seinem Team die Systemgrenzen vor Ort begutachten und festlegen.
Auch wird es Schnittstellen geben, Mensch – Maschine und Maschine-Maschine Schnittstellen, die genauestens beschrieben werden müssen.
Wobei aus der FMEA Perspektive die Mensch-Maschine Schnittstellen, genau wie es in den Prozessen der Fall ist, in denen Menschen agieren, als „nicht trivial“ bezeichnet werden. Menschen erweitern in der Regel den Komplexitätsgrad. Maschinen dagegen, können zwar kompliziert sein, Kompliziertheit lässt sich aber eher beherrschen als Komplexität. Von daher werden Prozesse, die einzig und allein durch Maschinen oder Software besetzt werden, als trivial bezeichnet.
FMEA Prozess Optimierung bezogen auf den Prozess „Kosten schätzen“: Prozessgrenzen
Da ich Trainer für Projektmanagement und der PMP Zertifizierung bin, möchte ich auch ein Beispiel aus dem Projektmanagement aufzeigen. Es soll um den Projektmanagementprozess „Kosten schätzen“, des PmBok Guides 6 auf Seite 240 gehen.
Gerade bei den Projektmanagementprozessen kommt es häufig zu Überlappungen oder Lücken von oder zwischen Prozessgrenzen – „Systemgrenzen“ können wir hier durch „Prozessgrenzen“ ersetzen – , die dann zu erheblichen Problemen (Folgefehlern) führen können. Bei Überlappungen kommt es i.d.R. außer zu redundanten Aufwänden und den damit verbundenen Kosten, nicht zu signifikanten Folgen. Lücken dagegen, können ganz erhebliche Folgefehler und damit verbundene Risiken erzeugen.
Der Prozess „Kosten schätzen“ ist einer der interdependentesten Prozesse der insgesamt 49 Prozesse. Von daher sind hier eine Menge Schnittstellen zu beachten, wovon ich hier nur einige frequentieren möchte.
Für PmBok Anfänger könnte diese Aussage verwirrend sein, da die Eingangswerte aus anderen Prozessen auf Seite 240, scheinbar überschaubar sind. Sie finden aber als Eingangswert 1, den Projektmanagementplan (PMP; PmBok Guide 6, Seite 599) vor, der dann alle Prozesse enthält, die mit dem „Kosten schätzen“ Prozess interagieren. Der Projektmanagementplan ist das zentrale Dokument, das alle zu beachtenden Elemente enthält.
Sie finden die Eingangswerte, Werkzeuge und Methoden und die Ausgangswerte in dem Schaubild auf Seite 240 PmBok Guide 6.
Sie können sich das Schaubild auf der PMIstandard+ Website ansehen:
https://standardsplus.pmi.org/SharedPosts/Show/pmbok6_1_7_2/8d5d804d-38a0-453f-97a5-1db64fa826b4
Müssen aber Mitglied bei PMI sein um sich dort einloggen zu können.
*Der PmBok Guide ist die zentrale Unterlage zur Zertifizierung zum Project Management Professional (PMP) des PMI.
Fortsetzung folgt!
Ich möchte mich zu einem FMEA Moderator ausbilden lassen. Gut zu wissen, dass man in 7 Schritten zur FMEA gelangen kann. Das die Planung Phase 1 ist, überrascht mich nicht.
Liebe Frau Hayder, ich selbst bilde keine FMEA Moderatoren aus. Meine Themen sind die PMP Zertifizierung, Projektmanagement, MS Project, Rhetorik und Kommunikation.