Warum Entwicklungsmethoden in der Praxis oft scheitern — und wann SPALTEN, FMEA und QFD wirklich helfen

Ich habe Produktentwicklungsmethoden zum ersten Mal nicht aus einem Lehrbuch gelernt. Ich habe sie in einem realen Projekt angewendet — unter Zeitdruck, mit einem echten Industriepartner, in einem Team das sich gerade erst gefunden hatte.

Das war das IP-Projekt am IPEK, dem Institut für Produktentwicklung am KIT. Vier Monate, sechs Personen, eine Aufgabe von Faurecia: Konzepte für den insassenzentrierten Innenraum der Zukunft entwickeln. Kein Übungsfall. Kein Musterlösungsblatt. Die Ergebnisse wurden vor Führungskräften des Unternehmens präsentiert.

Was ich dabei gelernt habe, hat mehr mit dem Scheitern von Methoden zu tun als mit ihrem Funktionieren.

Das eigentliche Problem mit Methoden

Methoden werden in der Praxis aus zwei Gründen nicht angewendet: entweder kennt man sie nicht — oder man kennt sie, hat sie einmal ausprobiert, und es hat nicht funktioniert wie erwartet.

Der zweite Fall ist häufiger und gefährlicher. Denn er führt zu der falschen Schlussfolgerung, die Methode tauge nichts. Dabei liegt das Problem fast nie in der Methode selbst. Es liegt darin, dass sie zur falschen Situation eingesetzt wurde. Oder zu früh. Oder zu spät. Oder mit falscher Erwartungshaltung.

SPALTEN: die Methode die ich am häufigsten einsetze

SPALTEN wurde am IPEK von Prof. Albers entwickelt und ist inzwischen in der VDI 2221 verankert. Das Akronym steht für Situationsanalyse, Problemeingrenzung, Alternative Lösungen, Tragweitenanalyse, Entscheiden und Umsetzen, Nachbereiten und Lernen.

Was das in der Praxis bedeutet: bevor man ein Problem löst, muss man verstehen was das Problem eigentlich ist. Das klingt trivial. Es ist es nicht.

Im Faurecia-Projekt hatten wir in Woche zwei eine scheinbar klare Aufgabenstellung — und drei verschiedene Interpretationen davon im Team. Nicht weil jemand nicht aufgepasst hatte, sondern weil komplexe Problemstellungen immer Interpretationsspielraum lassen. SPALTEN hat uns gezwungen, zuerst die Situation zu beschreiben bevor wir Lösungen entwickelt haben. Der erste Schritt — die Situationsanalyse — hat uns eine Woche "gekostet". Er hat uns vermutlich drei Wochen Fehlentwicklung erspart.

Was SPALTEN besonders macht: zwischen jedem Schritt steht ein expliziter Informationscheck. Man fragt sich: habe ich genug Informationen um weiterzumachen? Wenn nein — zurück. Das klingt nach Bürokratie. Es ist tatsächlich der Grund warum man am Ende nicht feststellt, dass man das falsche Problem gelöst hat.

• Wann SPALTEN hilft: bei jedem Problem das komplexer ist als eine Routineaufgabe. Bei Entscheidungen mit Unsicherheit. Bei Projekten die festgefahren sind.
• Wann SPALTEN nicht hilft: bei Problemen die man schon kennt. Wenn die Lösung bereits bekannt ist und nur noch umgesetzt werden muss.

FMEA: das mächtigste Werkzeug — das am häufigsten falsch eingesetzt wird

Failure Mode and Effects Analysis — systematische Analyse was schiefgehen kann, bevor es schiefgeht. Das Problem in der Praxis: FMEA wird entweder als QS-Pflichtübung am Ende des Projekts gemacht — dann ist sie wertlos, weil alle Entscheidungen bereits gefallen sind. Oder sie wird so früh gemacht, dass das System noch gar nicht gut genug verstanden ist um sinnvolle Fehlerszenarien zu entwickeln.

Der richtige Zeitpunkt ist wenn das Konzept steht, aber die Detailkonstruktion noch nicht begonnen hat. Dann kann die FMEA noch Einfluss auf Designentscheidungen nehmen — und genau das ist ihr Zweck.

• Wann FMEA hilft: wenn ein Konzept vorliegt das verstanden und abgesichert werden muss. Wenn Schnittstellen zwischen Subsystemen unklar sind. Wenn Serienentscheidungen bevorstehen.
• Wann FMEA nicht hilft: in der frühen Konzeptphase. Als Abschlussdokumentation nach Projektende.

QFD: Kundenwünsche in technische Anforderungen übersetzen

Quality Function Deployment ist in Deutschland verhältnismäßig wenig eingesetzt — obwohl es eines der nützlichsten Werkzeuge für die frühe Projektphase ist. Die Grundidee: man erfasst systematisch was der Kunde wirklich will, gewichtet diese Anforderungen, und übersetzt sie in messbare technische Merkmale.

Was das IP-Projekt gelehrt hat: ein lückenhaftes Lastenheft ist fast immer das Ergebnis übersprungener QFD-Logik. Man beginnt zu entwickeln bevor man wirklich verstanden hat was gebraucht wird. Anforderungen bleiben implizit — und explodieren dann später wenn Missverständnisse sichtbar werden.

• Wann QFD hilft: ganz am Anfang, wenn aus Kundenwünschen ein Lastenheft werden soll. Bei Produkten mit vielen Stakeholdern und konkurrierenden Anforderungen.
• Wann QFD nicht hilft: wenn die Anforderungen bereits klar und vollständig dokumentiert sind.

Nutzwertanalyse: Entscheidungen transparent machen

Die Nutzwertanalyse ist die unscheinbarste Methode in dieser Liste — und gleichzeitig diejenige die ich am häufigsten in Beratungsprojekten einsetze. Mehrere Alternativen werden anhand gewichteter Kriterien bewertet. Das Ergebnis ist eine Zahl. Kein Konsens durch Dominanz des Lautesten, kein Bauchgefühl das sich als Rationalität verkleidet.

• Wann sie hilft: wenn mehrere technisch valide Alternativen vorliegen und eine Entscheidung transparent sein muss. Vor Meilensteinentscheidungen.
• Wann sie nicht hilft: wenn die Entscheidung bereits gefallen ist und die Analyse nur noch Legitimation produzieren soll.

Was das für die Praxis bedeutet

Vier Methoden, vier verschiedene Situationen. Das ist die eigentliche Lektion.

Wer gelernt hat wann er welches Werkzeug einsetzt, ist schneller, genauer und überzeugender als jemand der dieselben Methoden aus dem Lehrbuch kennt aber nicht angewendet hat. Der Unterschied zwischen Methodenwissen und Methodenkompetenz ist genau das: die Fähigkeit situativ zu entscheiden.

Im IP-Projekt am IPEK haben wir das unter Bedingungen gelernt die dem Industriealltag näher waren als jede Vorlesung. Vier Monate, echter Auftraggeber, echte Präsentation. Kein Netz.

Wenn ich heute in praxisnahen Methodik-Workshops arbeite, bringe ich keine Methodenschulung mit. Ich bringe das Problem des Kunden mit — und die Methode die diesem Problem am besten hilft. Manchmal ist das SPALTEN. Manchmal eine FMEA. Manchmal ein leeres Whiteboard und die Frage: was ist hier eigentlich das eigentliche Problem?