Start Small, Scale Fast : Warum schnelle, relevante Veränderung mit dem Speedboot und nicht mit einem Transformationsprogramm beginnen sollten
Executive Summary
Transformation gewinnt an Geschwindigkeit, wenn Teams klein starten, Wirkung früh beweisen ‘müssen‘ und erst anschließend skalieren. Statt groß angelegter Programme mit komplexer Governance (ähnlich einem Tanker) schafft ein fokussierter Pilot im Team (Speedboot) schneller Evidenz: ein relevantes Businessproblem, ein kleines funktionsübergreifendes Team, klare Entscheidungsrechte und wenige messbare KPIs.
Der entscheidende Hebel liegt in der Verlagerung von Entscheidungen an den Ort der Wertschöpfung. Kurze Lernzyklen, enge Business-Anbindung und klare Checkpoints reduzieren Risiko, erhöhen Umsetzungsgeschwindigkeit und machen Skalierung zu einer Folge nachgewiesener Wirkung – nicht zu einer Vorabentscheidung.
Transformation sollte nicht mit dem Rollout beginnen, sondern mit dem Beweis, dass der neue Ansatz im Kleinen funktioniert.
Transformation im Speedboot statt im Tanker: Klein starten, schnell lernen, gezielt skalieren
Schnelle Veränderung beginnt selten mit einem unternehmensweiten Transformationsprogramm. Sie beginnt mit einem klar abgegrenzten Problem, einem kleinen entscheidungsfähigen Team und sichtbarer Wirkung. Erst wenn der Ansatz funktioniert, wird skaliert – nicht vorher.
Große Transformationen haben einen entscheidenden Vorteil: Sie sehen bedeutend aus
Ein Beitrag von Thomas R. Hueber · Lesezeit : ca. 5-7 Minuten
Unternehmen lieben Transformationen. Transformation klingt strategisch. Entscheidungen, Verzicht und Konsequenz sind weniger populär. Und Umsetzung klingt nach Arbeit.
- ‘Enterprise Transformation’– das Unternehmen neu ausrichten.
- ‘End-to-End Operating Model Redesign’ – Das Operating Model neu denken: Von Schnittstellen zu durchgängiger Wertschöpfung
- ‘Holistic Performance Journey’. – Performance ganzheitlich steigern
Das klingt nach Vorstandsetage, Steering Committee un mehreren hundert PowerPoint-Seiten.
Leider löst es noch kein Problem.
Je größer ein Veränderungsprogramm startet, desto mehr Zeit benötigt die Organisation zunächst dafür, die Veränderung zu organisieren: Governance definieren, Workstreams bilden, Schnittstellen abstimmen, Reporting etablieren und Termine für jene Meetings suchen, in denen später über Geschwindigkeit gesprochen wird.
Das Speedboot-Prinzip dreht diese Logik um:
Nicht zuerst die Organisation transformieren. Zuerst ein relevantes Problem lösen. Genau diese Fokussierung auf ein konkretes Businessproblem bildet den Ausgangspunkt des im Upload beschriebenen Ansatzes.
Ein Problem. Ein Team. Ein messbares Ergebnis.
Ein Pilot funktioniert nicht deshalb, weil er klein ist. Er funktioniert, weil er fokussiert ist.
Das Team bearbeitet ein klar definiertes Problem mit relevantem wirtschaftlichem Nutzen – beispielsweise:
- Durchlaufzeit einer Montagelinie reduzieren.
- Engineering-Aufwand einer Produktfamilie senken.
- Rüstzeiten an einem Engpass halbieren.
- Fehlerquote eines Entwicklungsprozesses reduzieren.
- Bestände in einem Wertstrom abbauen.
Nicht gleichzeitig Kultur, ERP, Organisation, Führungsmodell und Purpose.
Das wäre schließlich die große Maßnahme, der große Change, die Transformation.
Der Pilot ignoriert bewusst den Rest – zunächst. Genau diese Konzentration ist im Speedboat-Ansatz ausdrücklich vorgesehen.
Autonomie: Entscheiden dürfen, nicht nur schneller eskalieren
‘Empowerment’ gehört zu den beliebtesten Managementbegriffen.
In vielen Organisationen bedeutet er ungefähr: Das Team darf selbst entscheiden – nachdem alle relevanten Führungskräfte zugestimmt haben.
Aber das ist keine Autonomie. Das ist ein kürzer formulierter Genehmigungsprozess.
Ein Speedboat-Team benötigt echte Entscheidungsrechte (!). Es muss innerhalb klar definierter Grenzen handeln können, ohne jede operative Entscheidung wieder durch dieselbe Hierarchie zu schicken, deren Langsamkeit man eigentlich verändern wollte.
Der zugrunde liegende Ansatz ist eindeutig : Das Team muss entscheiden dürfen – nicht lediglich ausführen. Erst dadurch entsteht Momentum.
Oder einfacher:
Wer Geschwindigkeit möchte, muss Entscheidungen dorthin verlagern, wo die Arbeit stattfindet.
Nähe zum Business schlägt Transformationsarchitektur
Piloten verlieren schnell an Relevanz, wenn sie von der realen Wertschöpfung entkoppelt werden.
Deshalb braucht das Team einen klar verantwortlichen Vertreter des Geschäftsbereichs, der Produktionslinie, der regelmäßig bis immer beteiligt ist. Im Upload wird eine wöchentliche Einbindung ausdrücklich als Mechanismus genannt, um Relevanz und schnelle Umsetzung zu sichern.
Das klingt weniger imposant als ein ‘Transformation Board’. Ist aber um vieles nützlicher.
Denn jemand muss regelmäßig die relevante Frage beantworten : Hilft diese Lösung dem Geschäft – oder gefällt sie lediglich dem Projektteam?
Führung durch Leitplanken statt Mikromanagement : Warum gute Governance schneller macht
Transformationsteams benötigen Governance. Nur eben nicht über 14 Gremien.
- Klare Ziele.
- Definierte Entscheidungsrechte.
- Feste Checkpoints.
- Regelmäßige Reviews.
Das genügt häufig.
Der Speedboat-Ansatz unterscheidet deshalb ausdrücklich zwischen sinnvoller Governance und Mikromanagement:
Klare Kontrollpunkte halten das Team auf Kurs, ohne Geschwindigkeit zu zerstören.
Das ist eine wichtige Unterscheidung. Denn manche Unternehmen reagieren auf mangelnde Geschwindigkeit, indem sie zusätzliche Statusmeetings einführen. Effekt : Das Problem ist anschließend nur besser dokumentiert.
Produktion und Entwicklung folgen derselben Logik
Das Prinzip funktioniert der Speedboot-Ansatz in Produktion und Entwicklung gleichermaßen.
In der Produktion kann ein Pilot beispielsweise einen Wertstrom, eine Linie oder einen Engpass adressieren.
In der Entwicklung eine Produktfamilie, einen Freigabeprozess oder eine konkrete Engineering-Schleife.
Der Mechanismus bleibt derselbe : Problem isolieren → Team befähigen → Lösung testen → Wirkung messen → Standard entwickeln → skalieren.
Damit wird aus Transformation keine abstrakte Großveranstaltung, sondern eine Reihe kontrollierter Lernzyklen.
Das Unternehmen verändert sich nicht durch die Ankündigung der Transformation.
Es verändert sich dadurch, dass funktionierende Lösungen nach und nach den alten Zustand ersetzen.
Erst beweisen, dann skalieren
Das ist der vielleicht wichtigste Unterschied zwischen ‘Tanker‘ und ‘Speedboot‘.
Der Tanker definiert zuerst das passende Zielbild für die gesamte Organisation durch Abstimmung und versucht anschließend, hundert Menschen dorthin zu bewegen.
Das Speedboot beweist zunächst im Kleinen, dass der neue Ansatz tatsächlich funktioniert. Erst danach wird skaliert.
Damit reduziert sich auch das Transformationsrisiko.
Denn ein erfolgloser Pilot ist nur unangenehm. Schaden und Aufwand sind begrenzt.
Ein erfolgloses unternehmensweites Transformationsprogramm : Je größer das Transformationsprogramm, desto teurer wird das Scheitern.
Skalierung sollte deshalb das Ergebnis bewiesener(!) Wirkung sein – Erst Wirkung beweisen, dann skalieren. Nicht umgekehrt.
Skalierung ist das Ergebnis bewiesener Wirkung, nicht ihr Ersatz
Eckdaten für ein Speedboat
Keine quantifizierten Projektergebnisse wie Kosten-, Produktivitäts- oder Durchlaufzeitverbesserungen. Wo belastbare Daten fehlen, helfen auch präzise Zahlen nicht weiter. Für einen belastbaren Pilot sollten jedoch von Beginn an wenige messbare KPIs definiert werden.
| Steuerungsgröße | Sinnvolle KPI |
| Fokus | 1 klar abgegrenztes Businessproblem |
| Business-Nähe | wöchentliche Einbindung eines verantwortlichen Business-Vertreters |
| Entscheidungsgeschwindigkeit | Zeit von Problemidentifikation bis Entscheidung |
| Umsetzungsgeschwindigkeit | Lead Time von Entscheidung bis implementierter Lösung |
| Wirtschaftliche Wirkung | Kosten, Produktivität, Qualität, Bestand oder Durchlaufzeit – abhängig vom Pilot – in ZDF (Zahlen, Daten, Fakten) |
| Adoption | Anteil tatsächlich genutzter neuer Standards bzw. Prozesse |
| Skalierbarkeit | Zahl der übertragbaren Elemente auf BUs, Standorte oder Produktbereiche |
| Governance | wenige definierte Checkpoints und regelmäßige Reviews |
Die fünf Regeln des Speedboats
- Ein Problem auswählen, das wirtschaftlich relevant ist.
Nicht alles verbessern wollen. Etwas verbessern, das zählt. - Das Team klein und funktionsübergreifend halten.
Wer für jede Entscheidung einen weiteren Stakeholder benötigt, baut bereits wieder einen Tanker. - Echte Entscheidungsrechte geben.
‘Empowerment’ ohne Entscheidungsbefugnis ist Motivationsliteratur. - Business-Verantwortung eng einbinden.
Regelmäßig. Konkret. Nicht nur beim Kick-off und bei der Abschlusspräsentation. - Wirkung beweisen, dann skalieren.
Nicht jede Idee verdient einen Rollout.
Fazit : Transformation braucht weniger Dramaturgie – und mehr Evidenz
Große Veränderungsprogramme vermitteln Sicherheit. Es gibt Roadmaps. Workstreams. Milestones. Governance. Und selbstverständlich ein Transformation Office.
Das alles kann notwendig werden. Nur eben möglicherweise nachdem man herausgefunden hat, was tatsächlich funktioniert.
Der bessere Ausgangspunkt ist häufig kleiner:
- Ein relevantes Problem.
- Ein entscheidungsfähiges Team.
- Ein kurzer Lernzyklus.
- Ein messbares Ergebnis.
Dann der nächste Pilot. Dann Skalierung.
Transformation ohne Theater, weniger Transformationsrhetorik, mehr Wirkung : ein klarer Hebel verändert oft mehr als ein großes Programm, gezielte Eingriffe verändern mehr als breite Initiativen.
Verwendete Quellen
Die im Beitrag gemachten Aussagen basieren auf operativer Umsetzungserfahrung, Projekten und Erkenntnissen als Führungskraft auf VP und Direktoren Level in Produktionsunternehmen und im Maschinen- und Anlagenbau.
Bildquelle : Eigene Aufnahme aus dem Alltag auf dem Shopfloor.
