Was vorher fertig sein muss
Eine schriftliche Beschreibung oder Skizze des untersuchten Prozesses oder Systems mit klaren Schritten und Schnittstellen liegt vor.
Die Skalen für Schwere (S), Auftretenswahrscheinlichkeit (O) und Entdeckungswahrscheinlichkeit (D) sind definiert und im Team bekannt.
Was vor Start vorliegen muss
FMEA-Tabelle mit Spalten Funktion, Fehlermodus, Auswirkung, S, Ursache, O, aktuelle Kontrolle, D, RPN, Maßnahme, Owner, Datum; geteiltes Dokument oder Spreadsheet; Prozessdiagramm als Referenz.
Ein Facilitator mit FMEA-Erfahrung; drei bis zehn Teilnehmer mit Kenntnis aller Prozessabschnitte; ein Quality Lead, der Skalen kalibriert; ein Scribe für die Tabelle.
Scope (Produkt, Prozess oder System); Prozessdiagramm; bisherige Vorfälle und Reklamationen; verbindliche S/O/D-Skalen; Schwellwert für „kritisch“ (z. B. RPN über 100).
2-6 h
Tabelle vorbereiten, Scope und Skalen oben fixieren. Pro Funktion eine Zeilengruppe vorab anlegen. Beispielzeile als Schreibvorlage. Regel: Risikobewertung erst nach vollständiger Beschreibung, nicht parallel.
Die eine Frage, die diese Methode beantwortet
Welche Fehlermodi des Prozesses haben so hohes Risiko, dass präventive oder detektive Maßnahmen vor dem Einsatz nötig sind?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Scope und Funktionen | 20-30 min | Scope der FMEA festlegen (z. B. „Bestellabwicklung von Auftragseingang bis Versandbestätigung“). Funktionen pro Prozessschritt auflisten. Schnittstellen explizit markieren. | Wenn Funktionen zu grob sind, werden Fehlermodi unklar. Pro Funktion klar formulieren, was sie produziert und unter welcher Bedingung. |
2Phase 2: Fehlermodi sammeln | 30-60 min | Pro Funktion fragen: wie kann diese Funktion versagen, falsch oder unvollständig ausgeführt werden? Mindestens zwei Fehlermodi pro Funktion. Auch unwahrscheinliche aufnehmen. | Wer nur „das Übliche“ aufnimmt, verfehlt seltene aber kritische Modi. Bei sicherheitsrelevanten Prozessen ist Vollständigkeit wichtiger als Effizienz. |
3Phase 3: Auswirkungen und Ursachen | 45-90 min | Pro Fehlermodus Auswirkung beschreiben (was passiert für Kunden oder System), eine oder mehrere Ursachen ergänzen. Aktuelle Kontrollen (Tests, Checks, Reviews) eintragen. | Pro Fehlermodus können mehrere Ursachen existieren. Diese als eigene Zeilen führen, sonst wird die Risikobewertung verfälscht. |
4Phase 4: Risiko bewerten (S, O, D, RPN) | 30-45 min | Pro Zeile S, O und D auf der vereinbarten Skala (typisch 1-10) bewerten. RPN = S x O x D berechnen. Top-Zeilen nach Schwellwert markieren. | S und O sind oft Konsens, D ist die strittige Achse. Wer „aktuelle Kontrolle“ leer hat, kann D nicht ehrlich bewerten. |
5Phase 5: Maßnahmen und Owner | 30-45 min | Pro Top-Zeile Maßnahme festlegen, Owner und Datum. Maßnahme nach Wirkung kategorisieren (Eliminierung, Reduktion, Detektion). Folge-RPN abschätzen, um Wirksamkeit zu prüfen. | Nicht jede Top-Zeile braucht eine Maßnahme; manche Risiken werden bewusst akzeptiert. Akzeptanz mit Begründung dokumentieren, nicht stillschweigend. |
Was am Ende rauskommt
FMEA-Tabelle mit allen Spalten plus Header (Scope, Datum, Teilnehmer, Skalen-Definition), Maßnahmenliste mit Owner und Datum, Akzeptanzbegründung für nicht behandelte Top-Risiken und Re-Review-Termin.
Pro Scope eigene FMEA-Version mit Datum. Bei Änderungen am Prozess Delta-FMEA anlegen, nicht überschreiben. Maßnahmenstatus regelmäßig prüfen, RPN nach Implementierung neu bewerten.
Kompakte Arbeitsvorlage für Failure Mode and Effects Analysis mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Failure Mode and Effects Analysis Arbeitsvorlage
## Ziel
Analysiert mögliche Fehlermodi, Auswirkungen, Ursachen und Prioritäten für Gegenmaßnahmen.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- FMEA Table:
- Risk Priority:
- Mitigation Actions:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## FMEA — Onboarding-E-Mail-Pipeline (16.05.2026)
**Scope**: Vom User-Signup bis zur Zustellung der Welcome-E-Mail innerhalb 5 min. Skala 1-10 pro S, O, D.
**Auszug aus Tabelle**:
| Funktion | Fehlermodus | Auswirkung | S | Ursache | O | Kontrolle | D | RPN | Maßnahme |
|---|---|---|---|---|---|---|---|---|---|
| Signup-Event verschicken | Event geht verloren | User erhält keine Mail | 8 | Queue-Overflow | 4 | keine Alerts | 7 | 224 | Alert auf Queue-Backlog über 1000, Retry-Logik mit DLQ. Owner @lisa, bis 30.05. |
| Personalisierung | Fehlender Vorname | Mail mit „Hallo NULL“ | 5 | Vorname optional im Signup | 6 | Template-Test | 3 | 90 | Fallback „Hallo!“ im Template. Owner @ben, bis 22.05. |
| Versand | E-Mail im Spam | User glaubt System defekt | 7 | SPF/DKIM nicht konfiguriert | 3 | manueller Test | 8 | 168 | SPF/DKIM einrichten, Postmaster-Tools setzen. Owner @marcus, bis 25.05. |
**Schwellwert**: RPN über 150 = Pflichtmaßnahme. Drei Zeilen überschritten, alle adressiert.Symptome erkennen, gegensteuern
Verschiedene Teilnehmer interpretieren S=7 als „kritisch“ oder „mittel“, RPNs schwanken stark.
Vor Phase 4 Skalen mit Beispielen abgleichen: was bedeutet S=10 konkret in diesem Scope. 10 min investieren, sonst ist die ganze Tabelle inkonsistent.
Einträge wie „Fehler im Prozess“ oder „falsche Ausgabe“ ohne Spezifikation.
Pro Fehlermodus eine konkrete Beobachtung verlangen: was wäre zu sehen, zu messen, zu reklamieren. Beispiel: „Welcome-Mail kommt mehr als 30 min nach Signup an“.
Maßnahmen werden nur an RPN ausgerichtet, S=10-Risiken mit niedrigem RPN werden ignoriert.
Zusätzliches Kriterium „S allein ≥ 9“ als Pflichtmaßnahme. Sicherheits- und Compliance-relevante Risiken nie nur über RPN steuern.
D wird geschätzt, ohne dass jemand benennen kann, welche Kontrolle existiert.
Pro Zeile Kontrolle benennen oder leer lassen. Bei leerem Feld D auf 9-10 setzen, das schmerzt und treibt Maßnahmen.
FMEA wird einmal erstellt und nie wieder geprüft, Maßnahmenstatus bleibt unklar.
Re-Review-Termin bei Erstellung fixieren (typisch nach 4-12 Wochen). RPN nach Maßnahme neu bewerten und in Tabelle als Folge-RPN führen.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.