Aktuelles / News
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?
