Der Entwurf innovativer Produkte ist ein komplexer Prozess. Daher erfordert der Konstruktions- und Entwurfsprozess eine gerichtete Vorgehensweise. Heutzutage ist das Design Thinking als Methode in aller Munde. Ingenieure verwenden ganz ähnliche Methoden, und dies nicht erst seit gestern.
Das MIT hat ein hilfreiches Video veröffentlicht, das (angereichert um eigene Erfahrungen) die Leitlinie des heutigen Beitrags darstellt. Lassen Sie sich anhand eines Beispiels die wesentlichsten Elemente des Entwurfsprozesses zeigen.
Das folgende Video des MIT gibt in weniger als 15 Minuten einen guten Überblick über den ingenieurmäßigen Entwurfsprozess, und verweist an den jeweils geeigneten Stelle auf weiterführende Filme.
Der Referent startet mit der Ideenfindung, in der es ihm um die Aufnahme des Problems geht. Hierbei beobachtet er die Umwelt, um ungelöste technische Fragestellungen zu identifizieren. Er zeigt dann die Grobentwurfsphase, bei der er das Brainstorming verwendet, um zu Lösungswegen zu kommen, mit der er die ausgewählte Problematik angehen kann.
Danach zeigt er die Modellphase, in der er einfache Modelle zu seinem Problem erstellt, und geht dann in die Erprobungsphase des Models über. Anhand der in den Versuchen gelernten Eigenschaften des ersten Modells entwickelt er verfeinerte Modelle, die er solange weiter ausprobiert, bis sie tun, was sie sollen.
Ähnlich wie beim Design Thinking durchläuft er die gezeigten Phasen immer und immer wieder – bis er die Lösung kennt.
Der gezeigte Prozess ist relativ vollständig und praktikabel. Ich persönlich würde jedoch aus meiner Erfahrung an den folgenden Punkten alternative Vorgehensweisen anwenden.
Es gibt grundsätzlich zwei Herangehensweisen an eine Problematik. Einmal kann man, ähnlich wie es von den agilen Methoden propagiert wird, einen sehr iterativen Ansatz wählen, bei dem man sehr viel und früh im Prozess probiert, um das Endprodukt nötigenfalls anzupassen (das Prinzip „fail early and often“). Auf der anderen Seite kann man sehr viel analytischer vorgehen, in der Hoffnung wesentlich weniger nachbessern zu müssen.
Meiner Meinung nach hat das erste Prinzip bei technischen Problemen oft einen großen Nachteil – es bringt viel Bauchgefühl in die Lösung. Dieser ist hier oft unnötig, weil der Kundenbedarf in der frühen Entwurfsphase weniger relevant ist, als zum Beispiel in der Softwareentwicklung, und die Lösung gegebener Fragestellungen im Fokus steht, d.h die Wahl des Lösungsprinzips.
Der Referent wählt zum Anfang eine Vorrichtung aus, die den Ball schiessen soll, so wie dies ein Fußballspieler tun würde. Er sieht eine Rampe vor, damit der beschleunigte Ball abheben kann. Erst im Versuch werden ihm die Limitationen klar, und er wechselt zu einer anderen Lösung.
Im ingenieurmäßigen Entwurfsprozess sind Prinzipien sehr wichtig, und das Wissen über physikalische Zusammenhänge. Beides verwendet der Referent für sein erstes Modell nicht, sondern er probiert ohne Bezug zu Prinzipien und Physik. So ist eigentlich aber bereits am Anfang bei näherem Hinsehen klar, daß sein erster Entwurf schon aus physikalischen Gründen nicht funktionieren kann. Erst einmal liefert eine Vorrichtung mit einem Hammer, der frei fällt, viel zu wenig Kraft. Dann wird noch viel Kraft verwendet um den Ball umzulenken.
Die zweite Lösung umgeht diese Nachteile und funktioniert daher besser.
Meiner Meinung nach hilft es ungemein, wenn man sich etwas mit der Physik auskennt, da man so bereits in einer frühen Phase unpassende Lösungen ausschliessen kann.
Weiterhin ist es erfahrungsgemäß sinnvoll, wenn man sich nicht gleich auf ein Komplettmodell stürzt, sondern stattdessen das gesamte System erst einmal in kleinere Einheiten zerlegt, zu denen man sich jeweils mehrere Alternativen überlegt. Diese Vorgehensweise hat den Vorteil, daß sie methodischer ist, und, daß man so systematisch alle Alternativen erfaßt.
Das erste Beispiel hätte man z.B. zerlegen können in die Teilsysteme „Antrieb“, „Zielvorrichtung“. Hierfür hätte man sich dann z.B. über einen morphologischen Kasten Alternativen überlegen können, und man hätte jeweils die geeignete Alternativen kombinieren können.
Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links: