Aktuelles / News
Uneindeutigkeit im Engineering verschwindet durch KI nicht
Im Engineering beklagen wir seit Jahrzehnten unklare Anforderungen, späte Entscheidungen und Wissen, das in Köpfen steckt statt in Systemen. Trotzdem entstehen funktionierende und erfolgreiche Produkte. Das scheint also kein Widerspruch zu sein, sondern verweist auf einen Punkt, den wir in der KI Diskussion häufig übersehen:
Uneindeutigkeit ist im Engineering nicht nur ein Defizit. Sie kann funktional sein.
Gerade zu Beginn einer Entwicklung fehlen Daten, Zusammenhänge sind noch nicht verstanden und Entscheidungen würden den Lösungsraum möglicherweise zu früh einengen. Entwickler*innen halten deshalb Optionen offen. Führungskräfte verschieben Entscheidungen, weil Konsequenzen noch nicht ausreichend abschätzbar sind, Risiken nicht transparent sind oder die Vielzahl offener Punkte nicht auf der richtigen Entscheidungsebene ankommt.
Solche Muster sind nicht automatisch Ausdruck schlechter Organisation. Sie können eine Funktion erfüllen: Unsicherheit aushalten, Verantwortung vertagen, Optionen erhalten oder fehlende Entscheidungsreife kompensieren.
Bislang hatte Engineering dafür einen sehr wirkungsvollen Mechanismus:
Erfahrene Menschen haben die Kosten dieser Uneindeutigkeit weitgehend unsichtbar kompensiert.
Erfahrene Ingenieur*innen kennen Produkt, Kunden, Historie, typische Fehlerbilder und technische Wechselwirkungen. Sie erkennen, wenn eine Anforderung zwar nicht dokumentiert ist, aber faktisch existiert. Sie ergänzen fehlenden Kontext, hinterfragen Annahmen, erinnern sich an vergleichbare Fälle und treffen auf Basis unvollständiger Informationen trotzdem tragfähige Entscheidungen.
Diese Leistung taucht in keinem Prozessdiagramm auf. Sie steckt in Erfahrung, Kommunikation, Abstimmung und situativer Urteilskraft.
Hier genau verändert KI die Situation: KI-Werkzeuge treffen in realen Engineering Organisationen nicht plötzlich auf vollständige, konsistente und hervorragend strukturierte Daten. Die Vorstellung, Unternehmen würden zunächst ihre gesamte Wissensbasis bereinigen und anschließend KI einführen, halte ich (sorry) für unrealistisch.
KI wird deshalb mit derselben Uneindeutigkeit arbeiten müssen wie Menschen bisher.
Der entscheidende Unterschied liegt darin, wie mit den Lücken umgegangen wird.
Menschen erkennen häufig, dass ihnen Kontext fehlt. Sie fragen nach, zweifeln, vergleichen mit Erfahrungswissen oder holen weitere Personen hinzu. KI Systeme können fehlenden Kontext dagegen mit plausiblen Annahmen ergänzen. Das Ergebnis kann schlüssig wirken, obwohl relevante Informationen fehlen.
Damit verschwindet das Problem nicht, denn KI beseitigt die Kosten der Uneindeutigkeit nicht, sondern verschiebt sie entlang der Wertschöpfung.
Was bisher durch Erfahrung, Rückfragen, Abstimmung und implizites Wissen absorbiert wurde, kann nun an anderer Stelle wieder auftauchen: bei der Prüfung von Ergebnissen, in späteren Entscheidungen, in Rework, in zusätzlichen Iterationen oder im schlimmsten Fall erst beim Kunden.
Genau deshalb halte ich den blinden oder rein lokalen Einsatz von KI-Werkzeugen für riskant.
Wenn ein KI-Tool an einer Stelle Zeit spart, sagt das noch nichts darüber aus, ob der gesamte Engineering Prozess besser wird. Ein lokal plausibles Ergebnis kann in einem nachgelagerten Schritt zusätzlichen Aufwand erzeugen, falsche Annahmen verstärken oder Entscheidungen auf eine unsichere Grundlage stellen.
Das eigentliche Problem ist deshalb nicht, dass KI mit Uneindeutigkeit arbeitet.
Das Problem entsteht, wenn eine Organisation nicht weiß, wo diese Uneindeutigkeit anschließend wirksam wird.
Besonders kritisch wird es, wenn mehrere Faktoren zusammenkommen: KI-Werkzeuge werden punktuell eingeführt, ohne End-to-End Betrachtung. Ergebnisse werden übernommen, ohne Annahmen und Unsicherheiten sichtbar zu machen. Menschliche Prüfpunkte existieren zwar formal, sind aber nicht mit ausreichend Erfahrung, Zeit oder Entscheidungskompetenz ausgestattet.
Dann entsteht ein neues Muster:
KI erzeugt schnell einen plausiblen Vorschlag.
Der Vorschlag wird übernommen.
Darauf bauen weitere Prozessschritte auf.
Eine falsche Annahme wird weitergetragen.
Und je später sie erkannt wird, desto teurer wird ihre Korrektur.
Die Organisation wird dadurch nicht zwingend produktiver.
Sie kann lediglich schneller in die falsche Richtung laufen.
Geschwindigkeit ohne Urteilskraft und ohne End to End Verständnis ist kein Produktivitätsgewinn. Sie ist beschleunigte Fehlentwicklung.
Die zentrale Frage beim Einsatz von KI im Engineering sollte deshalb nicht lauten: Wo können wir ein KI Tool einsetzen?
Sondern:
Was passiert mit Unsicherheit, Uneindeutigkeit und fehlendem Kontext, wenn wir diesen Prozessschritt automatisieren?
Daraus folgen für mich vier Konsequenzen:
- KI-Einsatz muss immer End-to-End entlang der Engineering- Wertschöpfung betrachtet werden.
- Menschliche Entscheidungspunkte müssen dort bewusst gesetzt werden, wo Erfahrung, Kontext und Trade-offs relevant sind.
- KI sollte bei Unsicherheit nicht vorschnell eine eindeutige Antwort erzeugen, sondern Szenarien, Annahmen und Konsequenzen sichtbar machen.
- Anwender*innen müssen lernen, KI-Ergebnisse systematisch zu challengen und nicht nur effizient zu verwenden.
Und ja: Das hat auch Konsequenzen für Kompetenzen. Je stärker operative Tätigkeiten automatisiert werden, desto wichtiger werden Menschen, die technische Zusammenhänge verstehen, Annahmen hinterfragen und Entscheidungen verantworten können. Wer diese Kompetenz abbaut, verschärft das Problem zusätzlich.
Die entscheidende Erkenntnis ist für mich deshalb:
KI wird Uneindeutigkeit im Engineering nicht beseitigen. Entscheidend ist, ob Organisationen ihren Einsatz so gestalten, dass Unsicherheit sichtbar und beherrschbar bleibt, oder ob sie sie nur schneller durch den Prozess transportieren.
Und vielleicht macht KI dabei erstmals sichtbar, wie viel erfolgreiche Produktentwicklung bislang davon gelebt hat, dass erfahrene Menschen genau diese Uneindeutigkeit stillschweigend kompensiert haben.
Weniger Prävention?
In den letzten beiden Posts ging es um zwei Muster: mehr Anfragen für Strategiearbeit, mehr Anfragen für akutes Problemlösen im Anlauf. Ein drittes Muster gehört dazu, das eher durch sein Fehlen auffällt.
Was seltener nachgefragt wird: präventive Methodenarbeit. APQP frühzeitig aufsetzen, DRBFM als Standardmethodik einführen, Design-for-Manufacturing und Design-for-Reliability von Anfang an verankern.
Das ist bemerkenswert, weil genau diese Methoden am günstigsten wirken, nämlich solange noch kein Problem entstanden ist. Ein DRBFM-Workshop in der Konzeptphase kostet einen Bruchteil dessen, was eine Anlauf-Rettung später kostet.
Eine naheliegende Erklärung: Wenn akute Probleme die Kapazität binden, bleibt für Prävention kaum Budget und kaum Aufmerksamkeit übrig. Prävention verliert im Vergleich zum brennenden Thema fast immer – nicht, weil sie weniger wichtig wäre, sondern weil sie weniger dringend wirkt.
Das lässt sich ändern, ohne dass es zusätzliches Budget in schwierigen Zeiten braucht: Prävention muss nicht als eigenes Programm laufen. Sie lässt sich zwischen Produktplanung und Anlauf einbauen, als fester Bestandteil, nicht als Add-on, das zuerst gestrichen wird.
Die Frage, die daraus folgt: Wie viele der aktuellen Strategie- und Problemanfragen wären kleiner ausgefallen, wenn vor zwei Jahren in Prävention investiert worden wäre?
Problem Solving im Engineering
In meinem letzten Post habe ich von gehäuften Anfragen für Strategiearbeit gesprochen. Was sich seit einem Jahr ebenfalls auffällig häuft, sind Problemsolvings, entweder intern oder bei Lieferanten, meist im Anlauf.
Noch vor drei, vier Jahren ging es häufiger um „Wie führen wir Systems Engineering sauber ein", oder um den Aufbau von Design-for-Reliability oder DRBFM als Standardmethodik. Es wurde auch in Methodenausbildungen investiert, die jedoch schon vor ca. zwei Jahren heruntergefahren wurden.
Jetzt geht es um: schnell den Anlauf retten.
Problemlösen unter Druck verlangt eine andere Reihenfolge: erst Ursache verstehen, dann abstellen. Und es verlangt Ehrlichkeit darüber, dass manches Problem eine systemische Ursache hat. Manchmal ist es eine Entscheidung, die zu früh oder mit falschen Annahmen getroffen wurde.
Diese nachgelagerte Analyse braucht Raum, den der akute Druck selten hergibt. Wer im Anlauf-Rettungsmodus steckt, hat kaum Kapazität, die eigentliche Entscheidung in Frage zu stellen, die zum Problem geführt hat.
Ein Ausweg entsteht selten durch mehr Tempo im Abstellen. Er entsteht, wenn die Ursachenanalyse fester Bestandteil des Engineeringprozesses wird und nicht als Sonderaufgabe im Krisenfall: als Routine, die auch unter Druck ihren Platz behält.
Strategieanfragen häufen sich
Mehrere Anfragen in den letzten 6 Monaten, alle mit ähnlichem Kern: Ein Zukunftsbild des virtuellen Entwickelns entwerfen, Ausrichten eines Global Engineering Frameworks, Strategie der Supply Chain Organisation erarbeiten, alle aus unterschiedlichen Branchen und Unternehmensgrößen.
Auffällig dabei: die Häufung und der Zeitpunkt. Vor zwei Jahren wären das Anfragen über 2-3 Jahre gewesen und meist durch einen Führungswechsel ausgelöst. Jetzt kommen sie gehäuft, weil Unternehmen merken, dass ihre bisherige Engineering-Strategie nicht mehr zur globalen Marktlage passt, und zwar akut, nicht als Zukunftsprojekt.
Das ändert die Aufgabe. Strategiearbeit unter Zeitdruck ist etwas anderes als Strategiearbeit im ruhigen Planungszyklus. Der operative Teil dabei ist auch größer, es geht nicht nur um die Richtung, sondern auch darum, wer sie morgen umsetzt.
Es bleibt weniger Raum für den langen Assessment-Vorlauf und mehr Verantwortung, mit unvollständigen Daten trotzdem tragfähige Schritte vorzubereiten.
Was ich daraus mitnehme: Die Frage „Wo steht unsere Organisation strategisch?" wird gerade neu gestellt, auch von Unternehmen, die sie lange für beantwortet hielten.
Was der Stückpreis nicht verrät.
60–80% der Lebenszykluskosten eines Produkts werden durch Architektur- und Variantenentscheidungen festgelegt, nicht durch den Stückpreis.
Was das konkret bedeutet: Zwei Steuergeräte mit ähnlichen Hardwarekosten, eines auf einer Plattformarchitektur mit standardisierten Interfaces, das andere für einen spezifischen Kunden adaptiert mit eigener Softwarelogik, eigener Testsuite, eigener Qualifikation. Bei jeder Modellgeneration wiederholt sich der Aufwand. Der TCO-Unterschied (Gesamtkosten): 30–50%. Das ist nicht im Einkauf sichtbar, sondern in der Architekturentscheidung verankert, die Jahre früher getroffen wurde.
Total Cost of Ownership (hier nicht aus Kundenperspektive, sondern aus Herstellersicht): was kostet diese Variante das Unternehmen über ihren gesamten Lebenszyklus, macht das sichtbar. Nicht nur der Teilepreis, sondern Einmalinvestitionen, um eine Variante produktionsfähig zu machen, und laufende Kosten über den gesamten Lebenszyklus: variantenspezifische Nacharbeit, Softwarepflege, Ersatzteile, Wartung, Engineering durch späte Änderungen. Je weiter eine Variante vom Plattformstandard abweicht, desto höher werden CAPEX und OPEX.
Die Konsequenz daraus ist eine Entscheidungslogik: keine Checkliste, sondern vier Fragen, die bei jeder neuen Variante gestellt werden müssen: Erhöht sie dauerhaft die Variantenanzahl? Schafft sie neue Abhängigkeiten zu anderen Modulen? Ist sie reversibel? Und übersteigt der Nutzen die Lebenszykluskosten?
Ich habe dafür ein vereinfachtes Modell entwickelt – management-tauglich und schnell anwendbar. Es hilft bei einer konkreten Frage: Sollen wir diese neue Variante einführen und zu welchem Preis? Für die Portfoliobereinigung braucht es zusätzlich eine systemische Betrachtung der Verbundeffekte. Wer Interesse am Modell hat, meldet sich gern.
Modulare Produktarchitektur ist die strukturelle Antwort auf Komplexitätskosten. Dazu mehr im übernächsten Post.
20% Ihrer Produkte finanzieren den Rest – und der Rest kostet mehr als er bringt.
Variantenvielfalt entsteht selten als bewusste Entscheidung. Jede neue Kundenanforderung, jede Marktanpassung, jedes "das bauen wir noch schnell" addiert sich. Irgendwann ist die Frage nicht mehr, ob die Vielfalt beherrschbar ist, sondern wann sie es aufgehört hat zu sein.
Gerade in der Konsolidierungsphase der Automobilindustrie wird das sichtbar. Was in guten Zeiten quersubventioniert wurde, steht jetzt ohne Deckung da. Die Frage "Welche Varianten finanzieren uns wirklich?" ist für viele Unternehmen gerade brennend aktuell.
Woran erkennt man den Kipppunkt? Entwicklungsprojekte dauern immer gleich lang, egal wie viel Erfahrung das Team hat. In Einkauf, Qualitätssicherung und Logistik fehlen Ressourcen, weil die Lieferantenbasis mit jeder Variante gewachsen ist, viele davon unreif, wenige davon wirtschaftlich.
Das eigentliche Problem zeigt sich erst in den Zahlen. Die Wal-Kurve macht es sichtbar: 20% der Varianten generieren 150 bis 300% des Gewinns. Der Rest ist wertneutral oder vernichtet Wert. Das ist kein Randphänomen, es ist das strukturelle Ergebnis unkontrollierter Variantenvielfalt.
Was hilft: eine Komplexitätsstrategie, die Vielfalt aktiv steuert. Und Reduktion in großen Schritten, nicht in kleinen. Wer einzelne Varianten herausverhandelt, verstärkt das Muster. Wer eine ganze Komponentengeneration ablöst, bricht es.
Drei Fragen, die dabei fast immer kommen:
„Welche streichen wir, ohne Kunden zu verlieren?" Die Whale Curve beantwortet das, nicht Bauchgefühl, sondern Profitabilitätsanalyse.
„Der Vertrieb verkauft jeden Auftrag." Solange Vertrieb an Umsatz gemessen wird und nicht an Deckungsbeitrag, wächst die Vielfalt weiter.
„Wir haben das vor drei Jahren versucht, es hat nicht funktioniert." Fast immer war die Reduktion zu inkrementell. Komplexitätsreduktion erfordert Mut zu großen Schritten.
Die Wal-Kurve allein, d.h. die Analyse, ist nur der erste Schritt. In Kombination mit einem Vollkosten-Ansatz (Total Cost of Ownership) und einem Komplexitätsmanagement gelangt man in den profitablen Bereich und bleibt dort. Sprechen Sie mich an, wenn Sie an den Methoden und Modellen interessiert sind.
