Funktionen und Anforderungen in FMEA

Wider die Vermischung von Funktionen und Anforderungen in FMEA

1. Zielsetzung (Warum?)
Die Vermischung von "Funktionen" (z. B. "Diesel einspritzen") und "Anforderungen" (z. B. "zwei Millionen Lastwechsel") können bei FMEA-Entwicklungen zu Unsicherheiten, Inkonsistenzen der Analyseergebnisse und unnötig hohen FMEA-Umfängen führen.

Daher propagieren wir folgende Ziele:

  1. Funktionen und Anforderungen bleiben in Lasten- und Pflichtenheft sowie in der FMEA "galvanisch" getrennt.
  2. Anforderungen können Bestandteil von FMEA sein. Durch eine methodisch saubere Bearbeitung (und Trennung) können Anforderungen und deren Negierungen Bestandteile der Fehlernetze sein.
  3. Die "Kontamination" einer Vielzahl von Systemelementen (SE) der FMEA mit Anforderungen ist zu vermeiden, da nicht zielführend (erzeugt Datenmüll und Nebel).

Anmerkung: Bereits das Wort "Anforderung" ist problematisch. In der deutschen Sprache wird damit ausgedrückt, dass ein Gegenstand in den Lenkungsbereich gelangen soll. Es müsste "Forderung" heißen (diese "Unschärfe" ist in nahezu allen Normen der letzten Jahrzehnte aufgetreten).

Voraussetzungen: Funktionen und Anforderungen werden differenziert wahrgenommen, verstanden und behandelt (Differenzierungsvermögen).

2. Vorgehensweise (Wie?)
1. Klären, definieren und kommunizieren Sie den Unterschied und die Separierung von Funktionen und Anforderungen im Rahmen der FMEA-Entwicklung.

Unser Vorschlag: Funktionen beschreiben lösungsneutral die Wandlung von Eingangs- in Ausgangsgrößen in einem System mit dem Ziel, eine Aufgabe zu erfüllen / ein Ziel zu erreichen.
Anforderungen beschreiben "Qualitätsfilter = Eigenschaften" für die Eingangs- und Ausgangsgrößen eines Systems.

Abb. 1 Modell für "Funktionen" und "Anforderungen" (Quelle: Dietz Consultants)

Abb. 2 Prozess "Kaffee kochen" mit Anforderungen (Quelle: Dietz Consultants)

2. FMEA-Entwicklung: Darstellung der Anforderungen in einem exponierten Systemelement der Systemstruktur (Name des Systemelementes beispielsweise: "Anforderungen" oder "Anforderungen aus dem Lastenheft", ...). Empfohlen wird die dritte Ebene in der Systemstruktur.

  1. Ebene: Kundensystem
  2. Ebene: Analyseobjekt
  3. Ebene: Baugruppen und "Anforderungen"

3. Vermeidung der Darstellung von Anforderungen in weiteren Systemelementen (SE) (z.B. auf Komponenten-/ Bauteilebene der Systemstruktur).

4. Verknüpfung aller negierten Anforderungen mit der Ebene (Analyseobjekt) und der ersten ebene (Kundensystem)

5. Beispielhafte Frageformulierung für:
Funktionen: „Welche Funktionen führt das Systemelement aus?" „Was macht das Ding?“
Anforderungen: „Welche (Test-/Prüf-) Anforderungen muss das System erfüllen?“ „Welche Anforderungen gibt das Lasten-/Pflichtenheft vor?“

Beispiele:
Umgang mit Funktionen und Anforderungen

Abb. 3: Systemstruktur mit SE "Anforderungen" (Quelle: Dietz Consultants)

Abb. 4: Fehlernetz mit integrierten negierten Anforderungen (Quelle: Dietz Consultants)

3. Ergebnis

  1. Systematische Bearbeitung der Anforderungen aus dem Lastenheft in den Fehlernetzen und den korrespondierenden Vermeidungs- und Verifizierungsmaßnahmen (einschließlich Maßnahmenbewertung)
  2. Vermeidung, dass wildwuchsartig in den Ebenen der Baugruppen und Bauteile die Anforderungen vielfach dargestellt und bearbeitet werden
  3. Positionierung der Anforderungen in einer Ebene, in der diese verifiziert werden (der Ebene des Analyseobjektes und nicht auf der Bauteilebene)
  4. Konsistente und schlanke Analyse der Anforderungen in der FMEA