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