Aktuelles / News
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.
Die Hexenküche der Skalierung
Es gibt ein Muster, das sich in Unternehmen mit Skalierungsproblemen regelmäßig wiederholt: Die Reaktion auf wachsende Nachfrage ist die Erhöhung des Ressourceneinsatzes. Mehr Personal, mehr Kapazität, mehr Druck auf die Lieferkette.
Das Problem dabei ist nicht, dass diese Reaktion falsch wäre. Das Problem ist, dass sie am falschen Punkt ansetzt.
Eine Haushaltsküche, die für vier Personen optimiert wurde, wird durch zusätzliche Herde und Spülmaschinen nicht zur Restaurantküche. Die Engpässe liegen woanders: in Abläufen, die nicht für paralleles Arbeiten gedacht sind, in Rezepturen, die nie für größere Mengen durchdacht wurden, in einer Grundstruktur, die unter Last ihre Ordnung verliert.
Organisationen, die skalieren wollen, reproduzieren dieses Muster mit bemerkenswerter Konsistenz. Die Frage, ob Produktarchitektur und Produktplanung für höhere Stückzahlen ausgelegt sind, wird dabei selten gestellt , vielleicht weil sie unbequemer ist als die Frage nach Kapazitäten.
Was eine skalierfähige Produktplanung kennzeichnet, ist bekannt:
modulare Architektur mit definierten Schnittstellen
Software, die wartbar und erweiterbar ist statt nur funktionierend
Hardware, bei der Fertigbarkeit von Anfang an Designkriterium ist
Variantenmanagement durch Plattformlogik statt durch Einzelentwicklung.
Das Unbequeme daran: Diese Entscheidungen müssen früh getroffen werden. Zu einem Zeitpunkt, an dem der Skalierungsdruck noch nicht spürbar ist und die Notwendigkeit abstrakt bleibt oder sogar als Bremse wahrgenommen wird.
Falls Sie an weiteren Informationen oder einem Austausch interessiert sind, nehmen Sie gerne Kontakt zu mir auf.
Termine werden nicht gehalten. Qualität stimmt nicht. Stückzahlen liegen zurück. Das ist kein reines Kapazitätsproblem.
Die Zeitenwende hat die Nachfrage verändert. Die Strukturen der Zulieferer noch nicht.
Was ich als einen der zentralen Faktoren beobachte: Produktarchitekturen im Rüstungsbereich sind häufig hochintegriert und auf individuelle Anforderungen zugeschnitten, richtig für Einzelfertigung, aber nicht für Skalierung. Prozesse, die für Qualifikation gebaut wurden, nicht für Durchsatz. Das wird selten als Skalierungshindernis erkannt, weil es lange keines war.
Drei Antworten, die ich immer wieder höre. Und warum sie zu kurz greifen.
"Wir fahren die Kapazitäten hoch." In Entwicklung und Qualifikation funktioniert das nicht. Mehr Ressourcen auf einen stark vernetzten Prozess zu geben, erzeugt mehr Koordinationsaufwand, nicht mehr Output.
„Wir brauchen schnellere Qualifikationsprozesse." Regulatorische Vereinfachung löst das Architekturproblem nicht. AQAP und AS9100D sind Qualitätssicherung für Systeme, bei denen Ausfälle keine Option sind.
„Das kennen wir selbst am besten." Stimmt. Aber ein System, das funktioniert hat, muss nicht für das funktionieren, was jetzt gefragt ist.
Die erste Reaktion ist fast immer dieselbe: mehr Ressourcen, mehr Druck, mehr Kontrolle. Die Engpässe bleiben, weil sie an einer anderen Stelle sitzen.
Skalierung ist keine reine Kapazitätsfrage. Es ist auch die Frage, ob Produktarchitektur und Prozesse für höhere Stückzahlen ausgelegt sind, und ob die Organisation das erkennt, bevor sie an den falschen Hebeln zieht.
Ich spreche gerade mit Zulieferern, die genau das erleben: Entwicklungsprojekte hinter dem Zeitplan, Qualitätsprobleme kurz vor oder nach dem Start. Wer das kennt: ich freue mich über den Austausch.
