Aktuelles / News
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.
Wenn etwas nicht funktioniert, sucht man zuerst in der Struktur.
Meistens ist die Struktur jedoch der falsche Ort.
Business bestimmt Architektur. Architektur bestimmt Prozesse. Prozesse bestimmen Organisation. Diese Reihenfolge beschreibt keine Handlungsanleitung, sondern wo Probleme wirklich entstehen.
Bevor man das als Denkrahmen akzeptiert, drei Einwände die ernst genommen werden sollten.
Erstens: Die Richtung stimmt nicht immer. Veränderung funktioniert oft bottom-up. Eine neue Technologie verändert die Architektur, bevor die Strategie es vorsieht. Ein Team entwickelt eine bessere Arbeitsweise, bevor der Prozess es vorschreibt. BAPO beschreibt keine Einbahnstraße, sondern wo Abhängigkeiten sitzen. Auch bottom-up ausgelöste Veränderungen folgen dieser Logik, nur in umgekehrter Richtung.
Zweitens: Die meisten Probleme sind simpler. Zu langsam, zu teuer, zu viele Meetings. Das hat oft banale Ursachen: schlechte Führung, fehlende Klarheit, falsche Prioritäten. BAPO ist keine Universaldiagnose, eher eine Brille für die Fälle, in denen einfache Antworten nicht greifen.
Drittens: Architektur ist selten der Hebel, den man bewegen kann. Produktarchitekturen sind über Jahre gewachsen, durch Kundenanforderungen, Zulieferverträge und technische Schulden geprägt. Was nützt eine Diagnose, wenn der Befund nicht behandelbar ist? Die ehrliche Antwort: Manchmal zeigt die Diagnose, dass Architektur vereinfacht werden muss und nicht die Organisation. Und manchmal zeigt sie, dass das Problem woanders sitzt als ursprünglich angenommen. Auch das ist ein Ergebnis.
Eine Organisation, die zu langsam ist, hat meistens ein Prozessproblem. Das Prozessproblem hat eine Ursache in der technischen Architektur. Und die Architektur folgt oder folgt eben nicht der Produkt- und Businessstrategie. Was auf der Oberfläche wie ein Strukturproblem aussieht, ist oft eine Konsequenz von Entscheidungen, die zwei Ebenen früher getroffen wurden.
Das gilt branchenübergreifend. Im Automotive-Bereich, wenn neue Softwarearchitekturen auf alte Organisationslogiken treffen. Im Maschinenbau, wenn Plattformstrategien eingeführt werden, ohne Prozesse und Rollen anzupassen. Bei Rüstungszulieferern, die mit Strukturen skalieren sollen, die für kleine Serien gebaut wurden.
Dieser Denkrahmen heißt BAPO: Business, Architecture, Process, Organisation. Nicht als Vorgehensmodell, dafür ist die Realität zu unordentlich. Ich setze ihn als Diagnosebrille ein: Auf welcher Ebene sitzt das eigentliche Problem? Und wo muss angesetzt werden?
Wer mehr als das Organigramm ändern will: ich freue mich über einen Austausch.
Drei Probleme in der deutschen Industrie. Ein überholter KPI als Antwort.
Die deutsche Automobilindustrie kämpft mit sinkenden Absatzzahlen und Personalüberhang. Rüstungsunternehmen und ihre Supply Chains sollen plötzlich deutlich mehr produzieren als ihre Strukturen hergeben. Viele andere, wie Maschinenbau, Industrieelektronik, Medizintechnik merken, dass ihre Innovationsgeschwindigkeit nicht mehr mit dem Markt Schritt hält.
Drei verschiedene Probleme. Und ein KPI, der in vielen Entwicklungsorganisationen noch immer die Steuerung prägt: Effizienz.
Das ist in manchen Fällen richtig. Wer ein Ausbringungsproblem hat, muss Durchsatz und Kapazität verstehen. Wer Personalkosten senken muss, kommt um Strukturfragen nicht herum.
Und ja – viele Entwicklungsorganisationen sind tatsächlich ineffizient: doppelte Arbeit, unklare Zuständigkeiten, Abstimmungsrunden ohne Entscheidung. Das ist keine wertvolle Iterationszeit, sondern Verschwendung.
Aber Verschwendung eliminieren und auf Auslastung optimieren sind zwei verschiedene Dinge.
Produktentwicklung ist kein Durchlaufprozess. Ihr Wertbeitrag liegt nicht im reibungslosen Ablauf, sondern in der Qualität der Entscheidungen, die dabei getroffen werden – und im Zeitpunkt, an dem Fehler erkannt werden. Was unter dem Auslastungsgebot verschwindet: die Iteration, bevor eine Lösung festgeschrieben wird. Die Zeit, ein Problem wirklich zu durchdenken. Die Frage, ob die Anforderung überhaupt die richtige war.
Gerade für Unternehmen, die ein Innovationsproblem haben, ist das folgenreich. Wer Entwicklungsorganisationen auf Auslastung optimiert, bekommt gut ausgelastete Ingenieur*innen und weniger Innovation. Wer das Innovationsproblem mit Effizienzprogrammen angeht, verstärkt es.
Der teuerste Moment in der Produktentwicklung ist nicht der, in dem eine Ingenieur*in nachdenkt. Es ist der, in dem ein Fehler in der Serie auftaucht.
Bevor eine Entwicklungsorganisation weiterhin auf Effizienz getrimmt wird, lohnt sich eine Frage: Was ist eigentlich das Problem und ist Effizienz wirklich die Antwort darauf?
