Kanban in der Praxis

Vom Teamfokus zur Wertschöpfung
 
 
Hanser, Carl (Verlag)
  • 1. Auflage
  • |
  • erschienen am 5. Dezember 2016
  • |
  • 237 Seiten
 
E-Book | ePUB mit Wasserzeichen-DRM | Systemvoraussetzungen
E-Book | PDF mit Wasserzeichen-DRM | Systemvoraussetzungen
978-3-446-45230-5 (ISBN)
 
KANBAN IN DER PRAXIS //
- Wissen Sie, warum Kanban keine Teammethode ist?
- Wie können Sie Ihr bestehendes Kanban-System verbessern?
- Worauf sollten Sie achten, wenn Sie Kanban "skalieren" wollen?
- Welchen Vorteil bietet Forecasting gegenüber Schätzungen?
- Woran sollte man zuerst arbeiten und was kann noch warten?
- Extra: E-Book inside

Das Kanban-Board ist aufgestellt, die Swimlanes sind gezogen und die Blockade-Sticker geklebt. Und jetzt?
In vielen Unternehmen kann Kanban nicht sein volles Potenzial ausspielen. Oft werden die Hintergründe der einzelnen Praktiken wie zum Beispiel WIP-Limits nicht richtig verstanden und alle Hoffnung wird in eine Methode gesetzt, statt in das eigene Handeln. Kanban hilft zu sehen, wo die Schwachpunkte eines Arbeitssystems liegen und offenbart damit, wie man für den Kunden noch besser Wert generieren kann. Dieses Buch hilft dabei, bestehende Kanban-Systeme neu zu justieren und so das eigene Handlungsrepertoire zu erweitern.
Dazu beleuchtet Klaus Leopold detailliert Prinzipien und Funktionsweisen von Kanban, die nicht immer intuitiv sind. Er erklärt typische Problemmuster aus der praktischen Arbeit mit Kanban und zeigt auf, wie sich die gesamte Wertschöpfungskette eines Unternehmens verbessern lässt. Instrumente wie Verzögerungskosten und das Forecasting werden zu strategischen Hilfen und spätestens an diesem Punkt wird klar: Kanban ist keine Teammethode, sondern hat die Optimierung der gesamten Wertschöpfung eines Unternehmens im Blick.

AUS DEM INHALT //
- Die Wirkmechanismen von Kanban
- Kanban-Systeme betreiben und verbessern
- Forecasting
- Priorisieren mit Verzögerungskosten
Systemvoraussetzungen für E-Book inside: Internet-Verbindung und Adobe-Reader oder Ebook-Reader bzw. Adobe Digital Editions.
  • Deutsch
  • München
  • |
  • Deutschland
  • 22,73 MB
978-3-446-45230-5 (9783446452305)
3446452303 (3446452303)
weitere Ausgaben werden ermittelt
Dr. Klaus Leopold ist Informatiker mit langjähriger Erfahrung in der Leitung von IT-Teams. Er ist einer der ersten von David J. Anderson persönlich akkreditierten Kanban-Trainer und -Coaches weltweit und begleitet Unternehmen bei der Einführung von Kanban und den damit einhergehenden Change-Prozessen.
1 - Inhalt [Seite 6]
2 - Warum dieses Buch? [Seite 9]
3 - Danke! [Seite 12]
4 - Der Autor [Seite 14]
5 - 1 Warum machen wir Kanban? [Seite 16]
5.1 - 1.1 Schiffe im Arbeitsfluss [Seite 21]
5.1.1 - 1.1.1 Wenn wir schneller arbeiten, wird trotzdem nicht mehr Arbeit fertig [Seite 24]
5.1.2 - 1.1.2 Wir haben genug Zeit für Aufgaben, für die wir nie Zeit haben [Seite 26]
5.1.3 - 1.1.3 Wir werden verlässlicher, wenn wir uns Grenzen setzen [Seite 27]
5.1.4 - 1.1.4 Wenn alles Priorität hat, hat nichts Priorität [Seite 28]
5.1.5 - 1.1.5 Je später wir anfangen, desto besser für den Kunden [Seite 29]
5.1.6 - 1.1.6 Lokale Optimierung führt zu globaler Suboptimierung [Seite 30]
5.2 - 1.2 Kanban: Viva la evolución! [Seite 32]
5.3 - 1.3 Wertgenerierung: In Services denken [Seite 39]
5.4 - 1.4 Ebenen der Gestaltung: Kanban Flight Levels [Seite 41]
5.4.1 - 1.4.1 Flight Level 1: Team mit unreguliertem Input und Task-Fokus [Seite 42]
5.4.2 - 1.4.2 Flight Level 2: Team mit koordiniertem Input, Etablierung eines Arbeitsflusses [Seite 43]
5.4.3 - 1.4.3 Flight Level 3: Optimierung des Wertstroms [Seite 45]
5.4.4 - 1.4.4 Flight Level 4: Optimierung von Strategie und Portfolio [Seite 47]
6 - 2 Kanban-Systeme betreiben und verbessern [Seite 52]
6.1 - 2.1 Visualisierung, WIP-Limits und Arbeitsfluss [Seite 52]
6.1.1 - 2.1.1 Mit WIP-Limits arbeiten [Seite 55]
6.1.2 - 2.1.2 Über Wert und Fluss [Seite 62]
6.1.3 - 2.1.3 Mit mehreren Arbeitstypen umgehen [Seite 65]
6.1.4 - 2.1.4 Veränderung von Arbeitstypen im Zeitverlauf [Seite 66]
6.1.5 - 2.1.5 Nicht geplante Arbeit [Seite 69]
6.1.6 - 2.1.6 Definition of Done [Seite 70]
6.2 - 2.2 Umgang mit Blockaden [Seite 73]
6.2.1 - 2.2.1 Blocker Clustering [Seite 73]
6.2.2 - 2.2.2 Umgang mit Rückfluss und Defekten [Seite 80]
6.2.3 - 2.2.3 Priorisierung von Lösungen [Seite 83]
6.3 - 2.3 Kundenvalidierung [Seite 90]
6.4 - 2.4 Wissenstransfer [Seite 94]
6.4.1 - 2.4.1 Kapazitätsengpass (Capacity Constrained Resource) [Seite 94]
6.4.2 - 2.4.2 Spezialistenengpass (Non Instant Availability) [Seite 96]
6.4.3 - 2.4.3 Spezialisten vs. Generalisten [Seite 97]
6.5 - 2.5 Koordination [Seite 102]
6.5.1 - 2.5.1 Von der Idee zum koordinierten Input - Nachschubmeeting [Seite 103]
6.5.2 - 2.5.2 Von der Input Queue ins Kanban-System - Regular Standup Meeting [Seite 104]
6.5.3 - 2.5.3 Besser werden - Retrospektive [Seite 106]
6.5.3.1 - 2.5.3.1 Check-in [Seite 110]
6.5.3.2 - 2.5.3.2 Fakten sammeln [Seite 112]
6.5.3.3 - 2.5.3.3 Den Problemkern definieren [Seite 113]
6.5.3.4 - 2.5.3.4 Das Problem verstehen [Seite 114]
6.5.3.5 - 2.5.3.5 Lösungen finden und Maßnahmen beschließen [Seite 115]
6.5.3.6 - 2.5.3.6 Check-out [Seite 116]
6.5.3.7 - 2.5.3.7 Verbesserungsarbeit sichtbar machen [Seite 117]
7 - 3 Kanban im Großen [Seite 120]
7.1 - 3.1 Praxisbeispiel: Eine Verkaufsplattform mit mehr als 200 Projektmitarbeitern [Seite 123]
7.2 - 3.2 Kanban vergrößern [Seite 129]
7.2.1 - 3.2.1 Aggregation von Services [Seite 131]
7.2.2 - 3.2.2 Verbinden von Services [Seite 132]
7.2.3 - 3.2.3 Geteilte Services [Seite 134]
7.3 - 3.3 Kanban im ganz Großen bei Bosch Automotive Electronics [Seite 136]
8 - 4 Forecasting [Seite 142]
8.1 - 4.1 Voraussetzungen für das Forecasting [Seite 144]
8.2 - 4.2 Forecast für eine Arbeitseinheit [Seite 149]
8.3 - 4.3 Forecast für mehrere Arbeiten ohne historische Daten [Seite 154]
8.3.1 - 4.3.1 Bestimmung von Minimum und Maximum [Seite 154]
8.3.2 - 4.3.2 Monte-Carlo-Simulation [Seite 158]
8.3.3 - 4.3.3 Kontinuierliches Durchsatz-Forecasting [Seite 162]
8.3.4 - 4.3.4 Interview mit Troy Magennis [Seite 170]
8.4 - 4.4 Kann man dem Forecast trauen? [Seite 171]
8.4.1 - 4.4.1 Zusammenhang zwischen Work in Progress, Durchlaufzeit und Durchsatz [Seite 172]
8.4.2 - 4.4.2 Messen der Stabilität eines Systems [Seite 174]
8.4.3 - 4.4.3 Stabilitätsmuster interpretieren [Seite 176]
8.4.4 - 4.4.4 Interview mit Dan Vacanti [Seite 179]
9 - 5 Von der Priorisierung zur Risikobewertung [Seite 184]
9.1 - 5.1 Die Nachfrage durch Verzögerungskosten managen [Seite 189]
9.2 - 5.2 Verzögerungskosten quantifizieren [Seite 194]
9.2.1 - 5.2.1 Schritt 1: den Wert bestimmen [Seite 194]
9.2.2 - 5.2.2 Schritt 2: die Verzögerungskosten bestimmen [Seite 197]
9.2.3 - 5.2.3 Schritt 3: Sequencing [Seite 203]
9.2.4 - 5.2.4 Bestimmung der Verzögerungskosten in der Praxis [Seite 208]
9.3 - 5.3 Weitere Nachfüllfaktoren: Risikobetrachtungen [Seite 213]
9.3.1 - 5.3.1 Risikoarten [Seite 215]
9.3.2 - 5.3.2 Risiken quantifizieren [Seite 216]
9.3.2.1 - 5.3.2.1 Freie Risikobewertung [Seite 217]
9.3.2.2 - 5.3.2.2 Modellbasierte Bewertung [Seite 220]
9.4 - 5.4 Interview mit Markus Andrezak [Seite 224]
10 - 6 Vom Ticket-Handling zur strategischen Weiterentwicklung [Seite 228]
11 - Index [Seite 238]
2 Kanban-Systeme betreiben und verbessern 2.1 Visualisierung, WIP-Limits und Arbeitsfluss

Mich fasziniert immer wieder aufs Neue die unglaubliche Kreativität, die in den Visualisierungen des Arbeitsflusses an Kanban-Boards steckt. Wenn Menschen sehen, was und wie viel sie eigentlich den ganzen Tag tun, wie alle Aufgaben miteinander verknüpft sind und sich allmählich zu einem lieferbaren, wertvollen Ergebnis für den Kunden zusammensetzen, entfacht das oft eine beeindruckende Dynamik. Die Beteiligten beginnen zu verstehen, dass ihnen dieses Board eine Fülle an Informationen über die Funktionsweise ihres Arbeitssystems zeigt, die sie nutzen können, um das System weiter zu verbessern. Natürlich sehe ich aber auch Boards, die diese Aufgabe nicht erfüllen und allmählich verwaisen, weil ihre Besitzer damit nichts anzufangen wissen. Überraschenderweise ist das selten der Fehler des Kanban-Boards. Die Besitzer wissen einfach nicht, wie dieses Instrument funktioniert und worauf sie achten sollten, um verwertbare Informationen aus ihrem Board zu gewinnen. Ich möchte hier einige Punkte sehr deutlich hervorheben, die oft missverstanden werden und daher die Aussagekraft eines Boards schwächen.

Die Frage klingt trivial: Was visualisiert man in Kanban eigentlich? Die instinktive Antwort darauf lautet wohl: "Na, was man halt so tut!" Daher sehen sehr viele sogenannte Kanban-Boards auch so aus wie in Bild 2.1.

Bild 2.1 Wie ein Kanban-Board nicht aussehen sollte

Warum führt ein solches Board nirgends hin, zumindest nicht, wenn man das Ziel der evolutionären Verbesserung verfolgt? Im Kanban-Kontext könnte man ein Board mit den Spalten To do ? doing ? done verwenden, wenn man ausschließlich den Überblick über seine eigenen Aufgaben bewahren und regelmäßig kleine Erfolgserlebnisse haben will. Man könnte das als Flight Level 0 oder auch als Personal Kanban bezeichnen ? Jim Benson und Tonianne DeMaria Barry haben dazu ein preisgekröntes Buch geschrieben (vgl. Benson, DeMaria Barry 2013). Ab Flight Level 1 helfen solche Boards aber nicht mehr, denn wenn das Arbeitssystem eines Service in Fluss gebracht werden soll, müssen die einzelnen Aktivitäten sichtbar gemacht werden, die eine Arbeitseinheit zur Wertgenerierung durchfließt. Diese Aktivitäten lassen sich konkret benennen. Visualisierung beginnt daher mit der Überlegung, welche Aktivitäten in einem Service in welcher Reihenfolge ausgeführt werden, um Wert zu generieren ? bezeichnen wir sie für den Anfang mit A, B und C (siehe Bild 2.2). Diese Aktivitäten sind die Namensgeber für die Spalten des Boards ? in der Realität sollten über den Spalten natürlich konkrete Aktivitäten, zum Beispiel "entwickeln", "ausliefern" etc. zu lesen sein. Die nächste Überlegung lautet: "An welchen konkreten Aufgaben arbeiten wir gerade?" Diese Frage generiert die einzelnen Arbeitseinheiten, die als Tickets nun in den jeweiligen Aktivitäten platziert werden.

Bild 2.2 Ein Kanban-Board zeigt die wertgenerierenden Aktivitäten

Ganz links am Board befindet sich die Input Queue, die manchmal auch als "Next" oder "Bereit" bezeichnet wird, je nach Geschmack. Idealerweise wird in der Spaltenüberschrift aber genau gesagt, wofür eine Arbeitseinheit bereit ist, also zum Beispiel "bereit für Entwicklung". In dieser Spalte werden alle Arbeitseinheiten gesammelt, die als Nächstes erledigt werden sollen. Es ist also das Wartezimmer für Arbeitseinheiten, die im Zuge eines Spice Girls Meetings bereits in eine Reihenfolge gebracht wurden. Alle anderen Ideen oder Wünsche, die irgendwann umgesetzt werden könnten, landen zunächst in einem Ideen- oder Optionenpool und die Spice Girls entscheiden, was und wann es umgesetzt wird. Ich bezeichne dieses Sammelbecken bewusst als Optionenpool, denn es sind Möglichkeiten für die Zukunft, die es bewusst abzuwägen gilt, bevor sie endgültig in Auftrag gegeben werden. Erst dann wandern sie als Arbeitseinheiten in die Input Queue. Das bedeutet also: Zu allen Arbeitseinheiten, die sich in der Input Queue und in den Aktivitäten befinden, wurde bereits eine eindeutige Zusage (ein Commitment) abgegeben. Wenn diese zugesagten Arbeitseinheiten schließlich in der letzten Spalte landen, wurde im Idealfall für den Kunden ein Wert generiert. Ich würde diese letzte Spalte nicht prinzipiell mit "done" oder "abgeschlossen" übertiteln, weil nicht automatisch der gesamte Wert für den Kunden generiert wurde, nur weil der eigene Prozess (manchmal nur vorerst) abgeschlossen ist. Vielmehr empfiehlt sich, auch hier wieder den gesamten Wertstrom bis zum Kunden im Auge zu behalten und für diese letzte Spalte eine Bezeichnung zu finden, die signalisiert, wie es ab diesem Punkt weitergeht. Zum Beispiel können sich weitere Services an diesen Punkt anschließen, dann könnte diese Spalte als "bereit für .?.?." bezeichnet werden (z.?B. "bereit für Kundenabnahme" ? das impliziert, dass es auch noch Feedback des Kunden geben kann).

Was sollte noch sichtbar werden? In den meisten Arbeitssystemen treten Probleme und Hindernisse auf, die den Arbeitsfluss ins Stocken bringen können. Also ist es naheliegend, deutlich zu machen, in welchen Aktivitäten diese Probleme auftreten und die beteiligten Personen am Weiterarbeiten hindern. In Bild 2.2 werden solche Blockaden anhand der kleinen Sticker auf den Tickets in den Spalten B und C dargestellt (in der Praxis sind diese Sticker meistens rot). Auf diesen Stickern wird vermerkt, um welche Blockade es sich handelt. Genauso lässt sich mit andersfarbigen Stickern signalisieren, ob eine Arbeit in einer Aktivität bereits abgeschlossen ist. Ist das der Fall, kann die Arbeit ? und das ist nun der wichtige Punkt ? in die nächste Aktivität geholt werden, wann immer es dort Kapazität gibt. Kurze Erinnerung an das Flussexperiment: Durch das Heben der Hände wird signalisiert, dass eine Aktivität abgeschlossen ist. Kanban ist also ein Pull- und kein Push-System. Eine andere Variante der Visualisierung ist, Spalten noch einmal in "in Arbeit" und "fertig" zu unterteilen.

Verglichen mit der sonst üblichen völligen Unsichtbarkeit von Wissensarbeit lässt sich mit wenigen Mitteln bereits sehr viel Sichtbarkeit herstellen. Bis zu diesem Punkt ist bereits erkennbar,

  • wie der Arbeitsfluss aussieht.

  • wo sich die einzelnen Arbeiten gerade befinden, wie weit die Arbeit insgesamt also bereits fortgeschritten ist.

  • welche Arbeiten als Nächstes abzuschließen sein werden (Next-Spalte).

  • welche Ideen und Optionen es gibt.

  • welche Blockaden im Arbeitsfluss bestehen.

  • welchen Grund diese Blockaden haben.

  • welche Arbeiten abgeschlossen sind.

Begrifflichkeiten

Bevor wir weitermachen, möchte ich vorweg noch die wichtigsten Begriffe klären, die immer wieder auftauchen werden. Grundsätzlich spreche ich in diesem Buch von Kanban-Systemen im engeren Sinn, man kann auch technisches Kanban-System oder Kanban-Arbeitssystem dazu sagen. Darunter verstehe ich die Form der Visualisierung des Arbeitsprozesses (z.?B. durch das Board) und die einzelnen Instrumente (z.?B. WIP-Limits, Tickets, Meetings), mit deren Hilfe man Einblick in die eigenen Abläufe bekommt.

Aktivität: Eine Aktivität ist ein Schritt, der in einem Arbeitssystem gesetzt wird, damit ein Wert generiert werden kann. Eine Aktivität kann unterschiedliche Aufgaben umfassen. Auf dem Kanban-Board spiegelt sich eine Aktivität als Spalte wider.

Arbeitseinheit (Arbeit, Work Item): Eine Arbeitseinheit oder Arbeit ist eine in sich geschlossene Aufgabe oder eine Teilaufgabe, die die einzelnen wertgenerierenden Aktivitäten durchläuft.

Arbeitsfluss: Der Arbeitsfluss bezeichnet den Lauf von Arbeitseinheiten durch die Sequenz der einzelnen Aktivitäten eines technischen Kanban-Systems. Die Prinzipien von Kanban sind darauf ausgelegt, diesen Arbeitsfluss möglichst ungehindert fließen zu lassen. Visualisierung, WIP-Limits und das Pull-Prinzip sind dafür die wichtigsten Werkzeuge.

Arbeitstyp: Arbeitseinheiten lassen sich bestimmten Kategorien zuordnen, den sogenannten Arbeitstypen oder Work Item Types. Eine Arbeitseinheit ist die konkrete Ausprägung eines Arbeitstyps. So könnte die Ausprägung des Arbeitstyps "Task" lauten: "Datenbankänderung durchführen".

Flusseffizienz: Die Flusseffizienz bezeichnet jenen Zeitanteil an der gesamten Durchlaufzeit einer Arbeitseinheit, in dem aktiv gearbeitet wird.

Input Queue: Die Input Queue ist eine Spalte am Kanban-Board, in der alle Arbeitseinheiten gesammelt werden, die als Nächstes erledigt werden sollen. Diese Arbeitseinheiten wurden zuvor im Nachschubmeeting in eine Reihenfolge gebracht. Zu allen Arbeitseinheiten in der Input Queue wurde bereits eine eindeutige Zusage abgegeben.

WIP: Work in Progress (WIP) bezeichnet die Anzahl der Arbeiten, die zu einem Zeitpunkt in einem Arbeitssystem oder in einer Aktivität ausgeführt werden.

2.1.1 Mit WIP-Limits arbeiten

Kanban ist nicht nur ein Pull-System, sondern ein WIP-limitiertes Pull-System, und das heißt: Die Menge der Arbeit in einem System wird beschränkt. Beim Falten der Schiffe habe ich in jeder Aktivität (am Board wären es Spalten) ein WIP-Limit von 1 gesetzt. Es durfte sich also immer nur ein Schiff in einer Aktivität befinden ? egal, ob daran gearbeitet wurde oder nicht. Die Menge der Arbeit in...

Dateiformat: EPUB
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie eine Lese-Software, die das Dateiformat EPUB verarbeiten kann: z.B. Adobe Digital Editions oder FBReader - beide kostenlos (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie bereits vor dem Download die kostenlose App Adobe Digital Editions (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nicht Kindle)

Das Dateiformat EPUB ist sehr gut für Romane und Sachbücher geeignet - also für "fließenden" Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.


Dateiformat: PDF
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie zum Lesen die kostenlose Software Adobe Reader, Adobe Digital Editions oder einen anderen PDF-Viewer Ihrer Wahl (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie die kostenlose App Adobe Digital Editions oder eine andere Lese-App für E-Books (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nur bedingt: Kindle)

Das Dateiformat PDF zeigt auf jeder Hardware eine Buchseite stets identisch an. Daher ist eine PDF auch für ein komplexes Layout geeignet, wie es bei Lehr- und Fachbüchern verwendet wird (Bilder, Tabellen, Spalten, Fußnoten). Bei kleinen Displays von E-Readern oder Smartphones sind PDF leider eher nervig, weil zu viel Scrollen notwendig ist. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.


Download (sofort verfügbar)

27,99 €
inkl. 19% MwSt.
Download / Einzel-Lizenz
ePUB mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
PDF mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
Hinweis: Die Auswahl des von Ihnen gewünschten Dateiformats und des Kopierschutzes erfolgt erst im System des E-Book Anbieters
E-Book bestellen

Unsere Web-Seiten verwenden Cookies. Mit der Nutzung des WebShops erklären Sie sich damit einverstanden. Mehr Informationen finden Sie in unserem Datenschutzhinweis. Ok