+43-676-330-4803KontaktImpressum en de

Blog

Flight Levels: Die Verbesserungsebenen der Organisation

Sobald man etwas niedergeschrieben hat, kann man es sich ansehen, es weiterdenken und weiterentwickeln. Mit dem Modell der Flight Levels war das genau so: Kaum waren sie in meinem Buch „Kanban in der Praxis“ veröffentlicht und bereits davor zig Male im Beratungseinsatz bei Kunden, in Trainings und bei Vorträgen erzählt, hat sich meine Sicht darauf geändert – auch dank des Feedbacks von LeserInnen, ZuhörerInnen und TrainingsteilnehmerInnen.

Das Flight-Level-Modell stellt eine zentrale Frage: Welche Ebenen der Organisation bieten welche Hebel für die Verbesserung? Entlang dieser Frage habe ich die Flight Levels neu organisiert, denn ob der Input geregelt oder ungeregelt passiert (das bisherige Unterscheidungsmerkmal zwischen Flight Level 1 und 2) ist eine Detailfrage, die vom Wesentlichen ablenkt. In den meisten Unternehmen gibt es Mechanismen, mit denen entschieden wird, wer was als Nächstes tun soll. Ob diese Mechanismen effizient sind oder nicht, ist genau so ein Thema der Verbesserung, für das Flight-Level-Modell selbst ist sie aber nicht wichtig. Dadurch hat sich eine neue Ordnung ergeben, die so aussieht:

>  Flight Level 1 – Operative Ebene

>  Flight Level 2 – Koordination

>  Flight Level 3 – Strategisches Portfoliomanagement

Auch wenn die Flight Levels aus der Arbeit mit Kanban entstanden sind, ist es doch ein allgemeines Modell zur Weiterentwicklung von Organisationen. In meiner Arbeit mit Kunden geht es zum Beispiel sehr oft darum, mit Maßnahmen auf Flight Level 2 und 3 die Koordination und strategische Ausrichtung zu verbessern, während auf Teamebene bzw. der operativen Ebene mit Scrum gearbeitet wird. Es ist also nicht so wichtig, mit welchen Methoden auf den einzelnen Levels gearbeitet, sondern wie Kommunikation und Kooperation zwischen den Flight Levels und zwischen verschiedenen Einheiten auf den einzelnen Levels gestaltet werden. Schafft man hier Verbesserungen, beginnt sich die gesamte Wertschöpfung zu optimieren – und das ist ja schließlich unser Ziel.

Die Bezeichnung „Flight Levels“ habe ich nicht zufällig gewählt. Das Flight Level ist die Flughöhe und so soll es auch in diesem Zusammenhang verstanden werden: Je höher man fliegt, desto mehr Überblick hat man, man sieht aber auch weniger Details. Je niedriger man fliegt, desto mehr Details sieht man, aber man überblickt nicht mehr die gesamte Landschaft.

Kommunikationsinstrument
Das Modell der Flight Levels ist ein Kommunikationsinstrument, um die Wirkung von spezifischen Verbesserungsschritten  auf unterschiedlichen Ebenen deutlich zu machen und herauszufinden, wofür eine Organisation der sinnvolle und/oder mögliche Ausgangspunkt liegt, um eine Verbesserung zu starten.

Flight Level 1: Operative Ebene

Die erste Flugebene gehört dem Team, das die tägliche Arbeit erledigt. Häufig sind die involvierten Personen hoch spezialisierte Experten, vor allem in Hightech-Umgebungen begegne ich solchen Teams immer wieder. Diese Spezialisten arbeiten ausschließlich an Teilbereichen eines riesigen Gesamtsystems, etwa an den Einspritzsystemen eines Autos oder an der grafischen Aufbereitung eines Wetterradars für Flugzeuge. Eine andere typische Erscheinungsform von Einheiten auf Flight Level 1 sind crossfunktionale Software-Entwicklungs-Teams: zum Beispiel Analysten, Designer, Entwickler und Tester, die gemeinsam an einem kleineren Produkt oder an einem Subsystem eines größeren Produkts arbeiten. Meistens gelangt ein größeres Stück Arbeit zu einem Team, wird dort in sinnvolle Teile zerlegt und schrittweise umgesetzt. Nur für sich allein betrachtet, hilft ein Arbeitssystem in diesem Fall, den Arbeitsprozess dieses einen Teams zu visualisieren, zu limitieren und stetig zu verbessern. Wenn ein Unternehmen nicht nur aus einem Team besteht, sondern aus mehreren, stößt die Optimierung an den Schnittstellen zu anderen Einheiten an ihre Grenzen und sie kann sogar zur Suboptimierung des gesamten Systems führen. Die Verbesserung reicht nur bis an die Grenzen des Teams und kann in anderen Teams sogar mehr Schwierigkeiten verursachen.

Der größte Nachteil daran ist, dass trotz guter Intentionen eines Teams die Wünsche der Kunden nicht unbedingt besser erfüllt werden. Ich erkläre das gerne am Beispiel einer Tastatur. Nehmen wir an, ein Kunde wünscht sich einen Brief. Nehmen wir dazu weiter an, dass jedes Team unseres Unternehmens für eine Reihe der Tastatur zuständig ist. Jedes Team ist Meister seiner Reihe, aber Raum für Verbesserungen gibt es immer. Nun kann sich zum Beispiel Team 3 so lange optimieren, bis es einen neuen Weltrekord im Anschlagen des A aufstellt. Wunderbar! Allerdings wird der Brief dadurch kein bisschen schneller fertig. Beim Schreiben eines Briefs geht es nicht darum, dass man einen bestimmten Buchstaben besonders schnell anschlagen kann. Wichtiger ist es, den richtigen Buchstaben zur richtigen Zeit anzuschlagen, um eine wirkliche Leistungssteigerung zu erreichen. Daher sollte der Fokus einer Verbesserung am gesamten System liegen. Das Gesamtsystem ist es, das sich schrittweise auf den Kunden ausrichten soll: Was muss getan werden, um für den Kunden einen optimalen Wert zu generieren? Gibt es auf der operativen Ebene mehr als ein Team, ist es daher wichtig, die Arbeit zu koordinieren. Egal, in welcher Branche und in welchem Bereich: Auf dem Weg „from concept to cash“ bestehen zwischen den involvierten Teams in der Regel Abhängigkeiten. Jedes Team bzw. jede Einheit erledigt nur einen Teil der Wertgenerierung für den Kunden. Für eine sinnvolle Koordination müssen zunächst also die Wertschöpfungsketten von Produkten oder Projekten identifiziert werden. Ob eine Organisation agil ist, hat nichts damit zu tun, ob sie aus vielen agilen Teams besteht. Die Interaktionen zwischen den Teams müssen agil sein.

Flight Level 2: Koordination

Übersetzen wir es auf eine alltäglichere Situation in der Geschäftswelt. Das folgende Bild zeigt eine Situation, die ich in größeren Unternehmen (40 bis 40.000 MitarbeiterInnen) immer wieder sehe: Es braucht mehrere Teams, um einen Kundenwert zu generieren. In den meisten Fällen hat es für den Kunden keinen Wert, wenn er nur getesteten Code geliefert bekommt. Der Wert entsteht erst, wenn der Code in ein größeres (Live-)System integriert wird, das den Betrieb aufnimmt. Andererseits spezifizieren Kunden ihre Wünsche selten so kristallklar, dass sie sofort umgesetzt werden können. Ganz im Gegenteil: In der Regel ist vor der eigentlichen Entwicklungsarbeit noch viel anderes zu tun. Es müssen Leads generiert und Projektteams aufgesetzt werden, das Team muss verstehen, was der Kunde will, Verträge müssen geschlossen werden usw. In so einem Kontext kann die Devise nur lauten: Einen Wert für den Kunden zu schaffen, ist sehr viel wichtiger als ein hyperproduktives Team. Genau hier setzt Flight Level 2 an.

Auf Flight Level 2 wird die Interaktion der Teams optimiert. Um in der Metapher der Tastatur zu bleiben, wird auf Flight Level 2 sichergestellt, dass das richtige Team zur richtigen Zeit die richtige Taste drückt, also an der richtigen Arbeit zur richtigen Zeit arbeitet. Ein Flight Level 2 System koordiniert somit die Arbeit mehrerer Teams, die gemeinsam daran beteiligt sind, Kundenwünsche zu erfüllen und dazu bestimmte Leistungen in der Wertschöpfungskette erbringen. Ziel ist es, den Arbeitsfluss über die Teamgrenzen hinweg zu optimieren. Arbeitssysteme auf Flight Level 2 bringen massive Performance-Steigerungen, hauptsächlich aus zwei Gründen:

1.   Die Mitarbeiter arbeiten an den richtigen Dingen zum richtigen Zeitpunkt, denn der Arbeitsfluss wird teamübergreifend koordiniert.

2.   Die Anzahl der Arbeiten wird durchgehend limitiert und somit kann das Arbeitssystem insgesamt optimiert werden.

Da der Arbeitsfluss über den gesamten Wertstrom optimiert wird, verringern sich die Wartezeiten an den Schnittstellen und besonders wichtig: Engpässe werden deutlich sichtbar. Wer Organisationen auf diesem Flight Level erlebt hat, kann nur mehr lächeln, wenn High-Performance-Teams als Erfolgsgeheimnis verkauft werden. Je größer ein Unternehmen ist, desto mehr verschiedene Wertschöpfungsketten gibt es auch. Dementsprechend sind auch mehrere Koordinationsboards im Einsatz, die auch hierarchisch aufgebaut sein können.

Betrachten wir Flight Level 2 aus der Sicht des Change Management, sind Initiativen auf dieser Flughöhe – auch wenn damit mehrere Hundert Menschen koordiniert werden können – meistens einfacher einzuführen als auf Flight Level 1. Die Entscheidung, eine teamübergreifende Optimierung durchzuführen, fällt hier nämlich im höheren Management. Das bedeutet auch, dass das Management mit gutem Beispiel vorangeht und die gewünschte Veränderung vorlebt. Gleichzeitig muss nicht zwingend in jedem einzelnen Team auf der operativen Ebene die Arbeitsweise geändert werden. Ob ein Team nun Kanban oder Scrum macht oder einfach „nur arbeitet“, ist völlig irrelevant. Die einzige Veränderung, wenn man es so nennen will, ist, dass sich Vertreter aus den Teams in eigenen Meetings – meistens in regelmäßigen Standups – koordinieren.

Ist das ein Wasserfall?
Wenn man sich das Bild ansieht, kann man zur Auffassung kommen, dass Flight Level 2 die Manifestation einer wasserfallartigen Umsetzung ist. Was bedeutet Wasserfallentwicklung aber? Nur weil Dinge hintereinander abgearbeitet werden, bedeutet das nicht, dass man sich automatisch in einem Wasserfallentwicklungsprozess befindet (übrigens hat selbst Winston Royce das Wasserfallmodell als iterativen Prozess beschrieben). Es ist zum Beispiel ein gutes Muster, die Funktionalität einer Software zuerst zu programmieren, bevor man sie ausliefert.

Tatsächlich nach dem Wasserfallprinzip zu arbeiten, bedeutet, dass die Arbeitseinheiten, die durch den Arbeitsfluss gezogen werden, sehr groß sind, zum Beispiel ein komplettes Projekt. Es ist nicht zielführend, ein komplettes Projekt zuerst zu analysieren, dann zu entwickeln und schließlich zu implementieren. Davon spreche ich hier aber nicht. Die Arbeitseinheiten sollen möglichst klein sein, damit man so schnell wie möglich verifizieren kann, ob ein Ansatz richtig ist. Dazu gehört, so schnell wie möglich Feedback zu bekommen, um daraus lernen zu können.

Flight Level 3: Strategisches Portfoliomanagement

Üblicherweise arbeiten Organisationen nicht nur an einem einzigen Projekt oder einem einzigen Produkt. Das Portfolio eines Unternehmens setzt sich aus einer Vielzahl von Projekten und Produkten sowie strategischen Initiativen zusammen, die das Unternehmen fit für die Zukunft machen. Genau dieser Mix wird auf Flight Level 3 gemanagt. Man will den Überblick über das Geschehen im Unternehmen gewinnen, man will wissen, welche Projekte und strategischen Initiativen sich auf welche Art und Weise beeinflussen und wie weit die Umsetzung gediehen ist. Kann ein neues Projekt schon gestartet werden oder muss noch gewartet werden, bis ein anderes abgeschlossen ist? Welche Investments sollten getätigt werden? Soll ein neuer Markt erobert oder sollen Marktanteile gesteigert werden? Welche Change-Initiativen laufen derzeit im Unternehmen?

Vor allem diese letzte Frage – wo läuft gerade was in der Organisation und mit welchem Zweck – ist hervorragend für die Visualisierung an einem Strategieboard geeignet. So kann das Top-Management nämlich erkennen, ob widersprüchliche Signale ausgegeben wurden und sich Initiativen gegenseitig behindern. Vor allem wenn sich Unternehmen agilisieren wollen und mehrere Berater mit unterschiedlichen Ansichten im Haus unterwegs sind, treten solche Widersprüche oft auf: Während an einem Tag die Selbstorganisation gefeiert wird, werden am nächsten Tag Reportings der alten Schule gefordert. Auf dieser Flughöhe geht es also um die strategische Steuerung der gesamten Organisation und nicht um Mikromanagement in der operativen Umsetzung. Größere Unternehmen mit global verteilten Niederlassungen haben durch die unterschiedlichen lokalen Marktvoraussetzungen auch mehrere Strategien, daher trifft man dort meist auf mehrere Strategieboards, während es im Headquarter wiederum ein Koordinationsboard für alle Standorte gibt.

Grundsätzlich ist es ein gutes Problem, mehr Nachfrage als Möglichkeiten zur Umsetzung zu haben, denn sonst muss ein Unternehmen Mitarbeiter abbauen. Dadurch entsteht auf Portfolio-Ebene allerdings eine Konkurrenzsituation zwischen den Optionen. Dieses Missverhältnis zwischen Optionen und Umsetzungsmöglichkeiten muss explizit gemacht werden, da sonst der Eindruck entsteht, es stünden unendlich viele Ressourcen zur Verfügung. Dem ist aber nicht so und genau darum geht es bei Arbeitssystemen auf Flight Level 3: Um die kluge Auswahl und Kombination von Projekten, zu entwickelnden Produkten und strategischen Initiativen, um Abhängigkeiten zu erkennen und den Fluss durch die Wertschöpfungskette angesichts der tatsächlich verfügbaren Ressourcen zu optimieren.

Bei den Aufgabentypen handelt es sich auf Flight Level 3 um große Arbeitseinheiten, zum Beispiel „Markteintritt in Ungarn“ oder „weniger Automotive-, mehr Aviation-Business“. Auf dieser Flughöhe konkurrieren diese großen Funktionalitäten und Initiativen miteinander, also ist die Organisation gezwungen, überlegte und bewusste Entscheidungen darüber zu treffen, was als Nächstes abgeschlossen werden soll. Im Mittelpunkt stehen dabei nicht mehr die Ziele der einzelnen Projekte, sondern das Gesamtergebnis der Organisation. Bedarf und Möglichkeiten müssen genau abgewogen werden

Zusammenfassung

Das folgende Bild fasst die Flight Levels auf einen Blick zusammen:

Flight Level 3 ist das strategische Herz der Organisation. Hier laufen die Projekte und Initiativen des Unternehmens zusammen und hier findet auch das strategische Management statt. Flight Level 3 ist mit mehreren Systemen auf Flight Level 2 und Flight Level 1 verknüpft, wo die Arbeit operativ gemanagt wird. Das Beispiel „Markteintritt in Ungarn“ besteht auf Flight Level 3 vielleicht nur aus den zwei Tickets „Produktgruppe X bereitstellen“ und „Produktgruppe Y bereitstellen“, auf Flight Level 2 werden diese groben Arbeitseinheiten feiner zerlegt und für die Teams auf Flight Level 1 zur Verfügung gestellt.

Es ist auch häufig der Fall, dass Arbeit von Flight Level 3 direkt zu einem Team auf Flight Level 1 fließt. Nehmen wir an, bei unserem Unternehmen handelt es sich um einen Autoteilezulieferer und die Strategie auf Flight Level 3 lautet „mehr Aviation-Business“. Es gibt ein Produkt, das derzeit für den Automotive-Markt entwickelt wird, und es steht die Hypothese im Raum, dass dieses Produkt mit leichten Modifikationen auch für den Aviation-Markt interessant sein kann. Ein Spezialistenteam kümmert sich darum, diese Hypothese zu überprüfen, die Arbeitseinheit fließt also von Flight Level 3 direkt auf Flight Level 1 zum Spezialistenteam.

Die Flight Levels sind kein Maturitäts- oder Beurteilungsmodell. Ein Teamproblem wird man schlecht mit einem Strategieboard lösen können und umgekehrt lässt sich eine Strategie nicht mit einer versprengten Teaminitiative umsetzen. Trotzdem sehe ich eine ähnliche Denkweise bei agilen Initiativen: Es gibt ein strategisches Problem – nämlich die Ungewissheit darüber, wie sich der Markt in Zukunft entwickeln wird. Und obwohl niemand weiß, wo der Zug hinfährt, werden schon einmal vorsorglich alle Teams agilisiert. Agilität ist ein strategisches Thema und kann nicht primär auf der operativen Ebene gelöst werden – schon gar nicht durch die Agilisierung von Bereichen, in denen es gar nicht nötig ist. Wenn man in einer Organisation eine Verbesserung erzielen will, muss man sich zuerst darüber im Klaren sein, auf welcher Ebene der beste Hebel dafür angesiedelt ist. Die Flight Levels sollen dabei helfen, die passende Ebene zu identifizieren. Generell lässt sich sagen: Je höher das Flight Level, desto größer die Hebelwirkung. Wenn es die Möglichkeit gibt, mit einer Verbesserungsinitiative auf Flight Level 3 zu starten, sollte man das auch tun. Daher ist das einzige agile Team, das man am Anfang für eine agile Organisation unbedingt braucht, ein agiles Top-Management-Team, das agiles strategisches Portfoliomanagement betreibt. Daraus entsteht alles andere – lead by example.

Klaus Leopold

One comment

  1. Pingback: Kanban Flight Levels II: Die Verbesserungsebenen der Organisation - Agile Software DI C. Heumader

Leave a comment

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.