Viables Kontinuum Organisation | Kompendium-VI

SKALIERUNG

Vernetzte Abläufe sind durchaus von Vorteil. Wenn Produkte von der Idee bis zur Erstellung miteinander in Bezug stehen, kann die Steuerung weit durchgängiger und konsequenter erfolgen. Oftmals übersclägt sich der Markt mit Ansätzen, sehr vieles in möglichst komplexe Strukturen zu stopfen. Das wirft die Frage nach der Sinnhaftigkeit aus. Die nachstehenden Ausführungen adressieren die grundlegenden Optionen von Kanban.

EINLEITUNG

Diesmal kann ich mich mal etwas zurücklehnen, da der folgende Artikel von meinem Kollegen Thomas Michl so praktikabel ausgeführt worden ist, weswegen ich ihm die Bühne lasse und nur ganz wenige Kommentare ergänzt habe.

Da die Ausführungen sehr wichtig sind, nehme ich diese in Absprache in mein Kompendium dankend auf. Der Autor Thomas Michl ist abschliessend mit allen Details angeführt.

AUSGANGSSITUATION

Die Skalierung über „Teams" hinaus ist immer dann sinnvoll, wenn es um Schnittstellen zwischen verschiedenen Einheiten geht und die Schnittstellen nicht in das Team integriert werden können. Dies kann verschiedene Gründe haben. Unter anderem kann dies zu Teams mit zu hoher Anzahl an Mitgliedern führen, was lediglich zur Ineffizienz führt (eine Teamgröße zwischen 5 und 8 Personen gilt als ideal). Aber auch rechtliche und technische Gründe können eine Rolle spielen, wie z.B. die organisatorische Trennung von Anweisung und Auszahlung. In der Praxis lässt sich das Thema Skalierung daher kaum umgehen. Grundsätzlich empfehlen wir jedoch, Skalierung als Ausnahme von der Regel zu betrachten. Skalierung bedeutet immer einen erhöhten Kommunikations- und Steuerungsaufwand.

Die meisten agilen Frameworks, die diesen Aspekt beleuchten, fokussieren auf die Produktentwicklung (Scrum of Scrum, Nexus, LeSS) oder versuchen wie SAFe alle Eventualitäten der „Business Agility" mit einer klaren - aber leider auch komplizierten - Struktur zu lösen. Mich persönlich wundert ein wenig die geringe Beachtung von Kanban als Skalierungsoption. Dabei kann Kanban auch hier wertvolle Dienste leisten und hat den Vorteil, nicht mit der Brechstange neue "Rollen" und "Funktionen" einführen zu wollen. Dies mag auch an den Kanban-Prinzipien liegen, die den evolutionären Wandel in den Vordergrund stellen.

(Gleich vorweg, Kanban skaliert keine Teams. Kanban skaliert Services durch die Verknüpfung der Dienste untereinander. Der Fokus liegt wie immer bei Kanban auf der Arbeit - Anmerkung des Herausgebers.)

Im Kanban-Kontext werden in aller Regel drei mögliche Skalierungsdimension unterschieden:

SKALIERUNG IN DIE BREITE

Die Skalierung in die Breite orientiert sich am sogenannten Wertstrom. Der Wertstrom (engl. value stream) umfasst alle Aktivitäten, sprich die Gesamtheit aller wertschöpfenden und nicht-wertschöpfenden Geschäftsprozesse, die notwendig sind, um ein Produkt beziehungsweise eine Dienstleistung herzustellen und anzubieten, wobei der Strom auch über die Unternehmensgrenzen hinausgehen kann; siehe Verlängerte Werkbank. Er ist ein Begriff aus der Betriebswirtschaftslehre insbesondere im Bereich der Produktionsplanung und -steuerung. Das Wertstrom-Konzept wird beim sogenannten Wertstrommanagement genutzt. (Wikipedia, https://de.wikipedia.org/wiki/Wertstro aufgerufen am 27.06.2023). Vereinfacht ausgedrückt umfasst der Wertstrom alle Geschäftsprozesse, die zur Erstellung eines Produktes oder einer Dienstleistung notwendig sind.

Mit Kanban kann dieser Wertstrom visuell dargestellt werden. In der Regel wird, wie in der folgenden Abbildung, zwischen Upstream und Downstream unterschieden. Upstream verdichtet in der Abbildung die Vielzahl der Möglichkeiten bis zum Erreichen des Zusagepunktes, der den Übergang zum bekannten Teil von Kanban – dem Lieferkanban (Anmerkung des Herausgebers) - markiert.

(Um ganz exakt zu sein, ist es erst dann Upstream, wenn die Aufgaben auch tatsächlich mit den strategischen Vorhaben von ganz oben her abgeleitet sind und in stetem Zusammenhang stehen. Ansonsten ist der Abschnitt link vor dem Zusagepunkt vielmehr Arbeitsorbereitung und -filterung. Bleiben wir dennoch in diesem Artikel bei der herkömmlichen Bezeichnung Upstream – Anmerkung des Herausgebers.)

Upstream umfasst somit alle Geschäftsprozesse und Aufgaben, die dem eigentlichen Kanban-System vorgelagert sind. Vereinfacht ausgedrückt sind dies die Vorbereitung und Beschaffung. Downstream sind die nachgelagerten Geschäftsprozesse. Etwas deutlicher wird dies noch einmal in Abbildung 2: Ende-zu-Ende-Fluss.

In der Mitte befindet sich das Kanbansystem, das die Erstellung der „Leistung" darstellt. Davor und dahinter sind die notwendigen vor- und nachgelagerten „Hilfsprozesse" dargestellt.

Zur Veranschaulichung machen wir einen Ausflug nach Agilhausen in die dortige Stadtverwaltung und betrachten das Ganze am Beispiel der Erstellung einer Baugenehmigung. Der Baugenehmigungsprozess beginnt mit der eigentlichen Antragstellung durch den Bauherrn (Zusagepunkt) und endet mit der Erteilung der Baugenehmigung (Lieferung). Upstream wäre in diesem Fall das Thema der Vorinformationen und ähnlichem, die zur Erteilung der Baugenehmigung führen.

Nachgelagert wäre dann das Thema der Gebührenberechnung durch die Stadtkasse, die Übergabe an die „Bauaufsicht" etc.

Durch die Ende-zu-Ende-Darstellung können wir erkennen, wo es Schnittstellen und Übergabebrüche gibt. Dies erleichtert uns, darüber nachzudenken, wie wir den gesamten Workflow möglichst so gestalten können, damit wichtige Informationen nicht verloren gehen (Schnittstellen), was der jeweils nachgelagerte „Prozess" benötigt, um nahtlos übernehmen zu können. Auf diese Weise erkennen wir, wo wir Verbesserungen vornehmen können. Betrachtet man nur den Fluss im Liefer-Kanbansystem, verliert man schnell die Schnittstellen aus den Augen.

Wenn wir unser Kanbansystem verbessern, hat dies möglicherweise Auswirkungen auf den Ende-zu-Ende-Fluss, die wir vermeiden wollen. Die ganzheitliche Betrachtung ermöglicht es uns, mögliche Probleme an den Schnittstellen zu erkennen und das große Bild in unsere Überlegungen mit einzubeziehen.

SKALIERUNG IN DER TIEFE

Bei der Skalierung in der Tiefe werden Dienstleistungen auf der gleichen Flughöhe der Organisation miteinander gekoppelt, die in Zusammenhang miteinander stehen. Anders als bei der Skalierung nach Oben werden die Informationen nicht nach Flughöhe aggregiert. Wir haben es in aller Regel mit „gleichberechtigten" Services zu tun, die in Zusammenhang miteinander stehen, jedoch getrennt voneinander bearbeitet werden (unter anderem weil die Teams zu groß oder der Umfang bzw. Komplexität der Arbeit zuviel werden oder – wie im Falle der öffentlichen Verwaltung häufig der Fall, die Zuständigkeiten eine Trennung erforderlich machen).

Die Stadtverwaltung Agilhausen liefert wieder ein schönes Beispiel. Im Projekt „Digitalisierung der assensysteme" arbeiten derzeit zwei „Spezialistenteams" an unterschiedlichen Aufgaben. Das eine Team untersucht die technischen Möglichkeiten, das andere die rechtlichen Rahmenbedingungen. Beide Themen sind miteinander verknüpft.

SKALIERUNG NACH OBEN (FLUGHÖHE)

Bei der Skalierung in die Tiefe geht es darum, die verschiedenen Betrachtungsebenen miteinander zu verknüpfen. Dabei lassen sich häufig vier spezifische Ebenen unterscheiden:

1) Die persönliche Ebene (Personal Kanban)
2) Team-Ebene
3) Produkt/Service
4) Portfolio

Dabei wird versucht, den unterschiedlichen Bedürfnissen in der Darstellung des Prozesses (mit den unterschiedlichen Prozessregeln und Maßstäben, des jeweiligen Systems) in der jeweiligen Flughöhe gerecht zu werden und sie entsprechend der Flughöhe darzustellen.

Nehmen wir das Beispiel Agilhausen. In der Stadtverwaltung Agilhausen ist es üblich, übergeordnete Themen/Projekte mit Hilfe eines Portfolio-Kanbans transparent zu machen. Es macht jedoch wenig Sinn, die Details der Projektarbeit ebenfalls im Portfolio-Kanban abzubilden. Diese werden in den jeweiligen Team-Kanbans (das sind der Kanban-Sprache gemäss dem Kanban Maturity Modell „Proto-Kanbans – sprich prototypische Kanbans mit oftmals dem Fokus auf die Arbeiter statt auf die Arbeit bei voll ausgebauten Kanbans. Schon da entsteht erster Nutzen durch die Visualisierung der Arbeit – Anmerkung des Herausgebers.) abgebildet, je nach Bedarf im Kontext des Teams. Einzelne Mitarbeiter nutzen für ihre tägliche Aufgabenkoordination wiederum das Personal-Kanban.

FAZIT

Kanban ist in allen drei Dimensionen gut skalierbar und leistet auch jenseits der Teamarbeit sehr gute Dienste. Der große Vorteil gegenüber anderen Rahmenwerken: Kanban ist durch seinen evolutionären Ansatz geeignet, dort anzusetzen, wo die Organisation steht, ohne die Gesamtorganisation mit neuen Regeln und Rollen zu überfordern. Es bietet vielfältige Möglichkeiten der Übertragung auf die eigene Organisation. Es muss also nicht immer eines der großen Skalierungsframeworks sein, um in das Thema einzusteigen. Allerdings hat die hohe Flexibilität und Anpassungsfähigkeit von Kanban auch ihren Preis: Die Integration und Entwicklung eines Kanbansystems erfordert einiges an Denk- und Reflexionsarbeit. Der Ansatz STATIK bietet hierbei eine gewisse Orientierung.

Für die Skalierung empfiehlt auch sich die Orientierung an den folgenden drei Prinzipien (David J. Anderson, Theodora Bozehva - Kanban Maturity Modell Heidelberg, 2022: 482), die sich an den bekannten 6 Kanban-Prinzipien ausrichten:

1) Skaliere serviceorientiert einen Service nach dem anderen.
2) Entwurf jedes Kanbansystem nach den grundlegenenden Prinzipien unter Nutzung es systemischen Denkansatzes (STATIK). Versuche nicht, eine unternemensweite große Lösung zu gestalten.
3) Nutze die Kanban-Kadenzen als Managementystem, um alles auszubalancieren und so zu einer besseren Servicelieferung zu führen.

Autor

Thomas Michl
▪ This email address is being protected from spambots. You need JavaScript enabled to view it. / This email address is being protected from spambots. You need JavaScript enabled to view it.
▪ https://www.linkedin.com/in/deragilemichl/

Lead Coach bei der exxeta AG und Gründungsmitglied beim Forum Agile Verwaltung e. V.
▪ Exxeta AG: http://exxeta.com
▪ Forum Agile Verwaltung: https://agile-verwaltung.org

Herausgeber

Dieter Strasser, MSc, CMC, Geschäftsführer:
▪ This email address is being protected from spambots. You need JavaScript enabled to view it.

Trainer, Coach, Facilitator bei Viable Projects GmbH:
▪ www.viableprojects.eu