Aktuelles / News
Haben wir Entscheidungsfähigkeit ausreichend organisiert?
Entscheidungsfähigkeit muss organisiert werden.
Verantwortung wird in vielen Engineering-Organisationen dezentral erwartet.
Entscheidungsrechte, Informationen und Eskalationswege bleiben jedoch zentral, unklar oder widersprüchlich.
Dann entsteht kein Empowerment.
Dann entsteht Verantwortung ohne Gestaltungsmacht.
Gerade in wachsenden Organisationen wird das zum Engpass. Führungskräfte können nicht mehr jede technische Entscheidung selbst begleiten. Gleichzeitig werden Teams nicht automatisch entscheidungsfähig, nur weil ihnen mehr Verantwortung übertragen wird.
Entscheidungsfähigkeit braucht Struktur.
Aus meiner Sicht vor allem drei Dinge:
• Klare Entscheidungsräume: Wer entscheidet was, mit welchem Mandat und wo liegen die Grenzen?
• Passende technische und organisatorische Schnittstellen: Produktarchitektur und Verantwortungsstruktur müssen so zusammenspielen, dass Entscheidungen überhaupt lokal getroffen werden können.
• Eine belastbare Informationsbasis: Anforderungen, Architektur, Reifegrad und Auswirkungen von Entscheidungen müssen nachvollziehbar sein.
Der kritische Punkt ist:
Entscheidungsfähigkeit lässt sich nicht delegieren. Sie muss gestaltet werden.
Damit verändert sich auch die Führungslogik.
Führung muss weniger Entscheidungen an sich ziehen und stärker dafür sorgen, dass im System gute Entscheidungen entstehen können.
Das bedeutet: technische Autorität klären, Entscheidungsräume definieren, Eskalationen bewusst gestalten und Abhängigkeiten reduzieren.
Gerade beim Skalieren ist das zentral.
Denn wenn jede relevante Entscheidung weiterhin nach oben wandert, wächst die Organisation – aber nicht ihre Leistungsfähigkeit.
Skalierbar wird Engineering erst dann, wenn Entscheidungen nicht mit der Hierarchie wachsen.
Wenn Sie mehr erfahren wollen, oder an einem „Engineering Scalability / Transformation Reality Check“interessiert sind:
Wachsen oder skalieren?
Wachstum ist kein Skalieren. Gerade im Engineering wird das schnell sichtbar.
Der Defense-Markt zeigt das derzeit besonders deutlich: Neue Aufträge, neue Programme, neue Lieferant*innen, zusätzliche Standorte, mehr Varianten und hoher Zeitdruck treffen auf Engineering-Organisationen, deren Strukturen oft für deutlich stabilere Rahmenbedingungen entstanden sind.
Das Problem ist aber keineswegs auf Defense beschränkt. Auch Robotics, Aerospace, Maschinenbau und schnell wachsende Technologieunternehmen stehen vor derselben Frage:
Wie wächst Engineering-Leistung, ohne dass Koordinationsaufwand und Komplexität im gleichen Maß mitwachsen?
Die naheliegende Antwort auf Wachstum lautet häufig: mehr Personal.
Das kann notwendig sein. Aber mehr Personal erhöht zunächst nur die Kapazität. Skalierbar wird Engineering erst, wenn zusätzliche Menschen nicht im gleichen Maß zusätzliche Abstimmung erzeugen.
Dafür müssen sich mehrere Dinge gleichzeitig verändern:
- Produkt- und Variantenarchitektur: Modularisierung, klare Schnittstellen und eine beherrschbare Variantenlogik reduzieren Komplexität an der Quelle.
- Verantwortungs- und Entscheidungsarchitektur: Entscheidungen müssen dort getroffen werden können, wo Wissen und Verantwortung liegen.
- Entwicklungsfluss und Reifegradlogik: Klare Commit Points, transparente Reife und frühe Integration verhindern, dass Probleme nur schneller weitergereicht werden.
- Wissens- und Datenmodell: Anforderungen, Architektur, Nachweise und Änderungen müssen konsistent verknüpft sein.
- Kompetenz- und Integrationsfähigkeit: Neue Mitarbeitende, Teams und Lieferant*innen müssen schnell anschlussfähig werden.
Und auch die Führungslogik muss sich verändern.
Je größer eine Engineering-Organisation wird, desto weniger kann Führung über persönliche Intervention, Einzelentscheidungen und direkte Kontrolle funktionieren.
Führung muss stärker das System gestalten, in dem gute Entscheidungen entstehen:
klare Verantwortungsräume schaffen, Entscheidungsfähigkeit verteilen, technische Leitplanken setzen, Abhängigkeiten beherrschbar machen und dafür sorgen, dass Wissen nicht an einzelnen Personen hängt.
Mehr Menschen, die im gleichen System auf die gleiche Weise arbeiten, machen dieses System nicht automatisch leistungsfähiger.
Die eigentliche Skalierungsfrage lautet deshalb nicht:
Wie bekommen wir mehr Menschen ins Engineering?
Sondern:
Wie verändern wir Architektur, Organisation und Führungslogik so, dass mehr Kapazität tatsächlich zu mehr Entwicklungsleistung wird?
Wenn Sie mehr erfahren wollen, oder an einem „Engineering Scalability / Transformation Reality Check“interessiert sind:
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.
