Wenn mehr Varianten keinen Fortschritt mehr bringen
Typisch für ein festgefahrenes Projekt ist nicht unbedingt Stillstand. Oft passiert sogar sehr viel: Modelle werden geändert, Meetings durchgeführt, Prototypen gebaut und neue Details diskutiert. Trotzdem bleibt das zentrale technische Problem bestehen.
Dann kann zusätzliche Aktivität die Situation sogar verschärfen. Jede neue Variante erzeugt weitere Abhängigkeiten, ohne dass klar ist, warum die bisherigen Lösungen scheitern.
Wenn zehn Varianten denselben Grundkonflikt enthalten, ist die elfte Variante selten die Lösung.
Dann sollte nicht zuerst weiterkonstruiert, sondern die technische Aufgabe neu strukturiert werden.
5 typische Ursachen festgefahrener Entwicklungsprojekte
1. Das Symptom wird bearbeitet – nicht die Ursache
Ein Bauteil bricht, eine Dichtung leckt oder eine Baugruppe lässt sich schlecht montieren. Die naheliegende Reaktion ist eine lokale Änderung. Doch wenn die eigentliche Ursache beispielsweise im Lastpfad, in einer Schnittstelle oder im Wirkprinzip liegt, verlagert die Änderung das Problem möglicherweise nur.
Hilfreich ist eine strukturierte Ursache-Wirkungs-Betrachtung: Welche Wechselwirkung erzeugt das unerwünschte Ergebnis? Welche Funktion ist unzureichend oder schädlich? Welche Randbedingung macht das Problem überhaupt erst kritisch?
2. Der eigentliche technische Widerspruch wurde nie formuliert
Viele schwierige Aufgaben enthalten zwei berechtigte Anforderungen, die sich gegenseitig behindern: leichter und steifer, kompakter und besser kühlbar, einfach montierbar und sicher verriegelt, flexibel und präzise.
Solange dieser Konflikt nur als Liste von Anforderungen erscheint, entstehen häufig Kompromissvarianten. Wird der technische oder physikalische Widerspruch dagegen klar formuliert, können TRIZ-Werkzeuge gezielt nach anderen Lösungsprinzipien suchen.
3. Zu früh wurde eine Lösung festgelegt
Ein erstes Konzept wird im Projekt schnell zum gedanklichen Standard. Danach versucht das Team, genau dieses Prinzip immer weiter zu optimieren. Alternative Wirkprinzipien werden kaum noch betrachtet, weil bereits CAD-Daten, Termine oder Investitionen an der bestehenden Lösung hängen.
In einer kritischen Situation kann es sinnvoll sein, bewusst eine Ebene zurückzugehen: Welche Funktion muss erfüllt werden – unabhängig davon, wie sie heute konstruktiv umgesetzt ist?
4. Schnittstellen und Randbedingungen sind nicht sauber getrennt
Manchmal wird eine Baugruppe optimiert, obwohl das Problem durch die Umgebung erzeugt wird. Unklare Kräfte, Bauraumänderungen, Montagebedingungen, Toleranzketten oder angrenzende Komponenten können dazu führen, dass eine lokale Lösung immer wieder scheitert.
Deshalb sollten feste und veränderbare Randbedingungen getrennt werden. Eine vermeintlich unveränderliche Schnittstelle kann sich dabei als genau der Punkt herausstellen, an dem ein besseres Gesamtkonzept möglich wird.
5. Varianten werden gebaut, aber nicht gegen eine klare Hypothese getestet
Ein Prototyp liefert nur dann Erkenntnis, wenn vorher klar ist, welche technische Annahme geprüft werden soll. Sonst lautet das Ergebnis häufig nur: „Variante B funktioniert etwas besser.“ Warum sie besser funktioniert und welcher Parameter dafür verantwortlich ist, bleibt offen.
FEM, Berechnung und Versuch sollten deshalb gezielt eingesetzt werden. Eine Simulation vor dem nächsten Prototyp kann beispielsweise helfen, kritische Zusammenhänge zu verstehen und den Versuch auf die entscheidende Unsicherheit auszurichten.
Der Neustart beginnt nicht zwingend bei null
Ein festgefahrenes Projekt bedeutet nicht, dass bisherige Arbeit wertlos war. Im Gegenteil: Fehlversuche, Messdaten, CAD-Varianten und Prototypen enthalten wertvolle Informationen. Sie müssen nur anders gelesen werden.
Die entscheidende Frage lautet: Was haben wir durch die bisherigen Versuche über das System gelernt? Aus diesen Erkenntnissen lässt sich eine neue Problemdefinition aufbauen.
Ein möglicher Weg zurück zu belastbaren Konzepten
1 · Ziel klärenWas muss das Produkt funktional wirklich leisten?
2 · System analysierenFunktionen, Komponenten und Wechselwirkungen sichtbar machen.
3 · Ursache findenSymptom von technischer Ursache und Randbedingung trennen.
4 · Widerspruch formulierenDen entscheidenden Zielkonflikt präzise beschreiben.
5 · Lösungsraum öffnenTRIZ, Ressourcen und alternative Wirkprinzipien nutzen.
6 · Gezielt validierenCAD, FEM und Versuch nur für entscheidungsrelevante Fragen einsetzen.
Wann TRIZ hilft – und wann nicht
TRIZ ist besonders wertvoll, wenn bekannte Lösungsansätze immer wieder denselben Zielkonflikt erzeugen oder ein Problem zunächst widersprüchlich erscheint. Es ersetzt jedoch weder Fachwissen noch Konstruktion, Berechnung oder Versuch.
Die Stärke entsteht aus der Kombination: TRIZ strukturiert die Suche nach neuen Lösungsprinzipien; Engineering übersetzt diese Prinzipien in reale Geometrie, Werkstoffe, Schnittstellen und Herstellverfahren.
Nicht jede Krise braucht ein großes Beratungsprojekt
Ein externer Problemlösungsauftrag kann bewusst klein beginnen. Beispielsweise mit einem technischen Workshop oder Analysepaket: vorhandene Unterlagen und Fehlversuche sichten, Funktionen strukturieren, Hauptursachen und Widersprüche herausarbeiten und mehrere Lösungsrichtungen formulieren.
Danach kann der Kunde entscheiden, ob eine Lösung intern weiterbearbeitet wird oder ob BOLTCAD Konzept, CAD, FEM und Prototyping bis zur nächsten Entwicklungsstufe übernimmt.
Der erste externe Auftrag muss nicht „entwickeln Sie das Produkt fertig“ heißen.
Manchmal ist das wertvollste erste Ergebnis eine belastbare Erklärung, warum das Projekt bisher nicht weiterkommt – und welche drei Lösungsrichtungen jetzt geprüft werden sollten.
Ein externer Blick kann besonders dann helfen, wenn das Team zu viel weiß
Das klingt zunächst widersprüchlich. Doch wer lange an einem Produkt arbeitet, kennt viele Gründe, warum bestimmte Dinge „nicht gehen“. Dieses Wissen ist wertvoll, kann den Lösungsraum aber gleichzeitig unbewusst begrenzen.
Ein externer Entwicklungspartner kann Annahmen hinterfragen, ohne das vorhandene Wissen zu ignorieren. Entscheidend ist dabei, nicht einfach fremde Ideen zu präsentieren, sondern gemeinsam zwischen echten technischen Randbedingungen und historisch entstandenen Annahmen zu unterscheiden.
Von der Problemanalyse zurück in den Entwicklungsprozess
Nach einer erfolgreichen Problemlösungsphase sollte das Ergebnis möglichst schnell technisch greifbar werden. Je nach Aufgabe kann das eine Prinzipskizze, ein parametrisches CAD-Modell, eine FEM-Variantenstudie oder ein einfacher Funktionsprototyp sein.
So wird aus der methodischen Analyse wieder Engineering: Problem verstehen → Lösungsprinzip entwickeln → Konzept konkretisieren → technisch bewerten → gezielt validieren.
Weiterführend: Für die nächste Entscheidung passen auch Technische Probleme systematisch lösen statt Varianten zufällig ausprobieren und Vom technischen Widerspruch zur patentfähigen Lösung: TRIZ-Werkzeuge zielgerichtet einsetzen. Die passende BOLTCAD-Leistung finden Sie unter Consulting / technische Problemlösung.
Technische Problemlösung bei BOLTCAD ENGINEERING
BOLTCAD verbindet langjährige Produktentwicklung mit Funktionsanalyse, TRIZ, Siemens NX, FEM/ANSYS, ISO GPS und Prototyping. Dadurch können wir sowohl bei einer einzelnen festgefahrenen technischen Aufgabe als auch bei der anschließenden konstruktiven Umsetzung unterstützen. Vertrauliche Projektunterlagen können über den Projektstart unter NDA ausgetauscht werden.
