Ich dachte am Anfang selbst, mehr KI-Output bedeutet mehr Klarheit. Dieser Trugschluss hat mich eine Weile beschäftigt.

Das Bild, das ich dabei vor Augen hatte: Ein Entwicklungsteam lässt KI-Tools über seinen Recherche-Bestand laufen. Innerhalb weniger Stunden liegen Patenttreffer, Trend-Signale, Literaturzusammenfassungen und Querverweise aus Nachbarbranchen auf dem Tisch. Mehr Input als in drei Wochen manueller Recherche. Und danach? Das Team ist nicht klarer, sondern gelähmter. Jeder Insight scheint gleich wichtig. Niemand weiß, womit man anfangen soll.

Das ist kein Fleiß-Problem. Es ist ein Entscheidungslogik-Problem.

Was KI im Entwicklungsprozess wirklich gut kann

KI ist gut darin, Muster und Redundanzen sichtbar zu machen. Das ist keine kleine Leistung. Wer KI-gestützte Patentrecherche ernsthaft einsetzt, findet innerhalb von Minuten doppelte Patentfamilien, die das Team in getrennten Projekten unabhängig voneinander analysiert hat. KI erkennt wiederkehrende Fehlerursachen über Produktgenerationen hinweg. Sie findet ähnlich gelöste Probleme in Branchen, die kein Ingenieur im Tagesgeschäft im Blick hat.

Aber hier hört die Stärke auf. KI priorisiert nicht. Sie wägt keine Zielkonflikte ab. Sie übernimmt keine Verantwortung für eine Entscheidung. Sie produziert Diagnose, keine Therapie.

Genau diese Grenze zu kennen, ist der erste Schritt. KI in der Produktentwicklung ist ein Diagnosewerkzeug, kein Entscheidungsträger.

Die Lücke, die Teams frustriert

Viele Teams stecken gerade genau an dieser Stelle fest. Sie erhalten von KI-Tools eine Flut an Insights, aber keinen Rahmen, um daraus Prioritäten zu machen. Das zeigt sich in erkennbaren Symptomen: Recherchen zum gleichen Thema werden mehrfach angestoßen, weil die letzte Runde keine Entscheidung erzeugt hat. Meetings enden mit dem Beschluss, noch mehr Daten zu sammeln. Verworfene Ideen sind nirgends dokumentiert, also tauchen sie beim nächsten Projekt wieder auf.

Das ist kein Zeichen, dass das Team zu wenig arbeitet. Es ist ein Zeichen, dass Priorisierung eine Methode braucht, keinen zusätzlichen Arbeitseinsatz.

TRIZ in fünf Minuten erklärt

TRIZ steht für Teorija Reschenija Isobretatelskich Sadatsch, auf Deutsch: Theorie des erfinderischen Problemlösens. Der sowjetische Ingenieur Genrich Altschuller entwickelte sie ab den 1940er Jahren, indem er hunderttausende Patente systematisch auswertete. Seine Kernbeobachtung: Technische Probleme wiederholen sich branchenübergreifend, und erfolgreiche Lösungen folgen erkennbaren Mustern.

Das wichtigste Werkzeug für Einsteiger ist die Widerspruchsanalyse. Sie stellt eine direkte Frage: Was soll verbessert werden, ohne dass dabei etwas anderes schlechter wird? Aus diesem Widerspruch leitet TRIZ über die 40 innovativen Prinzipien konkrete Lösungsrichtungen ab. Diese Prinzipien sind kein Kreativitätszufall, sondern ein strukturierter Denk-Baukasten, der aus realen Erfindungen destilliert wurde.

TRIZ ist keine Kreativitätsmethode. Sie ist eine Entscheidungs- und Ableitungslogik. Genau das braucht die KI-Diagnose als nächsten Schritt.

Diagnose trifft Therapie-Logik

KI liefert die Diagnose, TRIZ liefert die Therapie-Logik. Ein konkretes Beispiel macht das greifbar.

Ein Bauteil soll leichter werden, darf aber nicht an Steifigkeit verlieren. KI zeigt: In der Patentliteratur gibt es 47 relevante Dokumente zu ähnlichen Leichtbau-Problemen, davon 12 aus der Luft- und Raumfahrt. Das ist Diagnose. Jetzt kommt TRIZ: Der Widerspruch lautet, Masse reduzieren ohne Steifigkeit zu opfern. Aus den 40 Prinzipien ergibt sich unter anderem das Prinzip der Segmentierung, Struktur aufteilen statt Vollmaterial verwenden. Das ist eine Lösungsrichtung, keine Idee aus dem Bauch.

Erst durch diese Kombination wird aus einem Insight eine nachvollziehbare, dokumentierte Entscheidung. Wer verstehen möchte, wie TRIZ Zielkonflikte systematisch auflöst, findet in unserem Artikel zu Zielkonflikten in der Produktentwicklung einen guten Einstieg.

Das Playbook: Fünf Schritte von der Insight-Flut zur Entscheidung

Der erste Schritt gilt, bevor die KI überhaupt läuft: das Problem sauber definieren. Ohne eine klare Systemgrenze, einen formulierten Zielkonflikt und bekannte Constraints produziert KI Rauschen. Eine Seite reicht. Wer mit einer offenen Suchfrage startet und hofft, dass die Ergebnisse das Problem klären, steuert direkt in die nächste Insight-Flut.

Danach kommt die eigentliche KI-Diagnose: Patent-, Literatur- und Marktrecherche durchführen, Redundanzen und Muster sichtbar machen, konkrete Suchhypothesen formulieren. Nicht jeden Output als gleichwertig behandeln.

Aus dieser Diagnose folgt der dritte Schritt: den eigentlichen Zielkonflikt herausarbeiten. Die Leitfrage lautet, was sich verbessern lässt, ohne etwas anderes zu verschlechtern. Wichtig dabei: einen Widerspruch bearbeiten, nicht mehrere gleichzeitig.

Der vierte Schritt ist die Ableitung von Lösungsrichtungen mit den 40 Prinzipien. Drei bis fünf Richtungen bewerten, nicht die erste plausible Idee sofort umsetzen.

Der fünfte Schritt schließt den Prozess: eine nachvollziehbare Entscheidung dokumentieren. Was wird verfolgt, was wird bewusst verworfen und warum. Verworfene Optionen mit Begründung festhalten. Entscheidungen, die nur mündlich getroffen werden, tauchen beim nächsten Projekt als neue Idee wieder auf.

Cut the work, not the people

Wenn KI redundante Recherche-Zyklen und Arbeit mit geringem Erkenntnisgewinn sichtbar macht, ist die richtige Konsequenz: diese Arbeit eliminieren. Nicht die Menschen, die sie bisher geleistet haben.

Das klingt offensichtlich. In der Praxis passiert trotzdem oft das Gegenteil: Die neu gewonnene Transparenz wird genutzt, um Auslastung zu messen, nicht um Prozesse zu verbessern.

Ingenieure sind die Instanz, die Zielkonflikte bewertet, Konzepte beurteilt und Entscheidungen verantwortet. Genau das kann KI nicht ersetzen. Die freiwerdende Zeit aus eliminierten Recherche-Schleifen gehört in diese urteilsintensive Arbeit, nicht in mehr Reporting.

Woran Sie merken, dass Ihre Entwicklung steckt

Vier Signale zeigen sich regelmäßig. Dieselbe Recherchefrage taucht in mehreren Projekten unabhängig auf. Entscheidungen werden vertagt, weil noch Daten fehlen. Verworfene Ideen sind nirgends dokumentiert. KI-Tools erzeugen Output, der in keiner Entscheidung landet.

Wer sich in diesen Punkten wiedererkennt, beginnt am besten mit Schritt 1 des Playbooks: Problem sauber definieren, bevor weitere Tools angeworfen werden. Für Teams, die das strukturiert angehen wollen, bietet Truinorva konkrete Formate, vom Impulse Day für die Problemdefinition bis zum TRIZ Basic Training für den systematischen Kompetenzaufbau.

Fazit

KI macht sichtbar. TRIZ entscheidet. Menschen verantworten.

Das ist die Auflösung des Trugschlusses, mit dem dieser Artikel begann. Mehr Output führt nicht zu mehr Klarheit, solange kein methodischer Rahmen entscheidet, was mit diesem Output passiert. Die Kombination aus KI-Diagnose und TRIZ-Entscheidungslogik ist kein Versprechen, sondern ein Prozess, der klein anfangen kann.

Starten Sie mit einem einzigen, klar definierten Problem. Spielen Sie die Diagnose-Therapie-Logik einmal durch. Der Impulse Day von Truinorva ist genau dafür gedacht, diesen ersten Schritt strukturiert zu gehen.

Quellen

  • Altschuller, G. S.: Erfinden: Wege zur Lösung technischer Probleme. Verlag Technik Berlin, 1984.
  • European Patent Office (EPO): Patents and the Fourth Industrial Revolution, 2017. epo.org
  • Truinorva, interne Projekterfahrung: Beobachtungen aus F&E-Workshops und Sparring-Sessions mit Ingenieur- und Produktentwicklungsteams, 2023/2024.