Download ppt - Kanban zur Abwicklung von Reporting-Anforderungen

Kanban zur Abwicklung von Reporting-Anforderungen und

Datenänderungen

Thomas Aglassinger

Version 1.2

Folie 2 Stand September 2011Version 1.2

Agenda

• Ausgangssituation

• Überblick Kanban

• Umsetzung: theoretisch und praktisch

• Kennzahlen

• Fragen und Antworten


Ausgangssituation

• Reportinglandschaft der Raiffeisen Bankengruppe Steiermark

• Rolle der Abt. Solution Development (SDC)

• Auftraggeber

• Herausforderungen


Reporting für RBG Steiermark

Steiermark-spezifische

Auswertungen

Ad hocAuswertungenund generelle

Datenänderungen

Abt. Solution DevelopmentRRZ Süd

SektorweiteAuswertungen

AndereHersteller


Wer sind die Auftraggeber?

Ca. 20 Fachbereiche

Ca. 90 Banken

Steiermark-spezifische

Auswertungen

Ad hocAuswertungenund generelle

Datenänderungen

Abt. Solution DevelopmentRRZ Süd

Auftrag


Herausforderungen

• Mehr als 100 verschiedene Auftraggeber

• Breite Streuung bei Umsetzungszeit

• Breiter technologischer Werkzeugkasten


Sich daraus ergebende Fragen

• Wie wird ein Auftrag priorisiert?

• Wie gehen wir mit den unterschiedlichen Durchlaufzeiten um?

• Wie erkennen wir frühzeitig Handlungsbedarf und Verbesserungspotential?

• Wie berücksichtigen wir, dass die Mitarbeiter die einzelnen Werkzeuge in unterschiedlicher Tiefe beherrschen?

• Wie können wir unsere Leistung darstellen?


Kanban

• jap. 看板 , dt. „Karte“, „Tafel“, „Beleg“

• Ursprünglich bei Autoherstellung• Minimierung der Lagerbestands

• Gezieltes Herstellen von Zwischenprodukte

• In Folge auch in anderenProduktionsbetrieben

• Seit einigen Jahren auch fürSoftware-Entwicklung


Kernprinzipien von Kanban

• Konsequente Darstellung der aktuellen Aufträge

• Geringhalten der gleichzeitig bearbeiteten Aufträge (Limit für „work in progress“)

• Abgestimmte Priorisierung gemeinsam mit den Auftraggebern (Warteschlange)

• Pull-Prinzip: Mitarbeiter holt sichAuftrag selbst aus Warteschlange

• Buffet-Ansatz: jene Maßnahmenumsetzen, die Nutzen bringen

• Eigentliche Bearbeitung des Auftragsbleibt gleich


Darstellung der aktuellen Aufträge

• Über Tafel („White board“)

• Analog und/oder digital

• Basis für tägliche Kurzabstimmung


White board

• Enthält alle derzeit bearbeiteten Aufträge

• Auftrag durchläuft Stati bis zur Erledigung.

• Bei Bedarf: verschiedene Schwimmbahnen („swim lanes“).

ErledigteAufträge

Auftrags-bestand

Priorisierung Erledigung


White board - Gestaltung

• Auftragsstati und Schwimmbahnen frei wählbar

• Vom Team entwickeln lassen

• Darf sich im Laufe der Zeit wandeln

• Viele verschiedene Varianten im Einsatz


White board - analog

• Ein Post-It für jeden Auftrag

• Kurzbeschreibung, Startdatum, Enddatum

• Verschiedene Farben für Klassifizierung


White board - digital

1. Vollständige Kanban-Anwendungen

2. Auf Basis von Ticket-Trackern• Kanban über Plugins oder Customing• Kennzahlen über Plugins oder Scripting

Zahlreiche Systeme am Markt


White board – analog oder digital?

• Analog• Benötigt keine technische Infrastruktur

• Ständig sichtbar

• „Zum Angreifen“

• Digital• Unabhängig vom Aufenthaltsort

• Kennzahlen automatisiert ermittelbar

• Auftragsdetails ablegbar

• Empfehlung Literatur: beides gleichzeitig oder nur analog


White board - konkret

• Entscheidung: nur digital

• Infrastruktur weitgehend vorhanden

• Mitarbeiter in mehreren Räume

• Synchronisieren mit Analog-Kopie entfällt

• geringe Teamgrößen ein Bildschirm ok


White board - konkret

• Schwimmbahnen für Software (SW) und Organisatorisches (ORG)

• Über Trac und dynamische Wiki-Dokumente

Spalte entspricht Auftragsstatus

Eindeutige Auftragsnummer

Kurzbeschreibung


White board - Zusammenfassung

• Kompakte Darstellung aller aktuell bearbeiteten Aufträge

• Analog und/oder digital

• Auftragsstatus und ev. Schwimmbahnen

• Gestaltung nach eigenem Bedarf


Tägliche Kurzabstimmung

• Vor dem White board

• Jeder Mitarbeiter stellt kurz dar:

• Welche Aufträge habe ich gestern bearbeitet?

• Welche Aufträge werde ich heute bearbeiten?

• Gegebenenfalls: Wo gibt es Blockaden und wer unternimmt etwas dagegen?

• Kurz und kompakt (Richtwert: 5 Minuten)

• Gegebenenfalls Nachbesprechung


Tägliche Kurzabstimmung - konkret

• Vor Mittagspause

• Dauer i.d.R. 5 bis 10 Minuten

• Kurze inhaltliche Diskussionen erlaubt

• Kaum Nachbesprechungen


Konkreter Nutzen für uns

• Im Team immer alle aktuell informiert

• Vereinfachung für Vertretung bei Urlaub oder Krankenstand

• Einheitliche Ablage der Auftragsinformation

• Kaum Aufwände für Statusberichte


WIP-Limit

• WIP = „work in progress“

• Grenze für die Anzahl der Aufträge im White board

• Weniger Themensprünge

• Mitarbeiter bleiben eher im Flow

• Bessere Nutzung des Kurzzeitgedächtnisses


WIP-Limit - konkret

• WIP-Limit ist im White board eingetragen

• Auftragsbestand und erledigte Aufträge zählen nicht zu WIP

• Je Bedarf: Gesamt-Limit, Limit pro Status, Limit pro Schwimmbahn, Limit pro Mitarbeiter, …

Software-Aufträge in Bearbeitung: 8

WIP-Limit für Software-Aufträge: 10


Was ist ein sinnvolles WIP-Limit?

• Anfangswert finden:

1. Normal arbeiten und beobachten

2. Startwert wählen, ändern wenn notwendig

• So lange reduzieren, bis sich die Durchlaufzeit von Aufträgen nicht mehr ändert

• WIP-Limit darf sich ändern – mit gutem Grund (z.B. neuer Mitarbeiter)


Umgang mit WIP-Limit

• Oft: in der Anfangsphase „zu hoch“

• Im Zweifel: zwischenzeitlich erhöhen

• Immer etwas aktiv bearbeiten

• Wenn absehbar, dass Auftrag längerfristig blockiert ist: abbrechen und später wieder in die Warteschlange stellen

• Eventuell mit Auftraggeber umpriorisieren


Priorisierung der Aufträge

• Welcher Aufträge kommen in Warteschlange?

• Gemeinsam mit dem Auftraggeber

• Literatur:• Periodisches Treffen aller Auftraggeber (z.B.

monatlich)

• Auftraggeber verteilen WIP-Anteile untereinander

• Moderation durch Auftragnehmer


Priorisierung - konkret

• Herausforderung:• mehr als 100 Auftraggeber

• Kanban-Maßnahme mit Außenwirksamkeit

• Aktuelle Lösung:• Auftraggeber mit vielen Aufträgen erhalten Anfrage: „Welche

fünf eurer Aufträge sollen wir als nächstes in Arbeit nehmen?“

• Auftraggeber mit sporadischen Aufträgen: priorisieren wir selbst

• Bei Engpässen: spontane Priorisierung mit betroffenen Auftraggebern oder extern Beteiligten (Projekt-Abteilung, Geschäftsleitung, …)


Konkreter Nutzen für uns

• Erkennen von Engpässen

• Sachliches Darstellen von Engpässen

• Kaum konkrete Zieltermine für Aufträge

• Kaum Terminverschiebungen


Pull-Prinzip

• Mitarbeiter holt selbstständig nächsten Auftrag aus der Warteschlange

• Höhere Selbstständigkeit

• Keine konkrete Anweisung vom Vorgesetzten


Pull-Prinzip - konkret

• Nicht in Verwendung

• Kein erkennbarer Vorteil

• Nicht jeder Auftrag für jeden bearbeitbar

• Stattdessen: Team ermittelt Bearbeiter


Kennzahlen

• Zum Erkennen von Verbesserungspotential

• Zur Darstellung des Erfolges von gesetzten Maßnahmen für Verbesserungen

• Zur Darstellung der eigenen Leistung

• Einfache Messung über White board


Verteilung der Durchlaufzeit

• Durchlaufzeit = von Auftragserteilung bis Einsatz

• Ergibt zusicherbare Durchlaufzeit

• Zum Erkennen von „Ausreißern“ Spektralanalyse


Verlauf des Work in progress (WIP)

• Ziel: Höhen sind stabil

Verbesserung bei Einsatzplanung

Ferialpraktikant mehr Kapazität

Urlaube bei Auftraggeber weniger

Testabnahmen


Zusammenfassung

• Kanban: für Abwicklung von Aufträgen

• Effizienz durch verschiedene Maßnahmen:• Aktueller Stand (White board, Kurzabstimmung)

• Priorisierung mit Auftraggeber

• Limit für gleichzeitig bearbeitete Aufträge (WIP)

• Einführung nach Buffet-Ansatz

• Kennzahlen für Verbesserung

• Erfolgreich verwendet bei SDC/RRZ Süd


Referenzen

• Anderson, D.: Kanban – Successful evolutionary change for your technology business (2010, Blue Hole Press)

• Leopold, K.: Software Kanban im Einsatzhttp://heise.de/-1235465

• Hiranabe, K.: Visualizing agile projects using Kanban boardshttp://www.infoq.com/articles/agile-kanban-boards

• Patton, J.: Kanban oversimplifiedhttp://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html

• Ladas, C.: Scrum-banhttp://leansoftwareengineering.com/ksse/scrum-ban/

• Trachttp://trac.edgewall.org/


Fragen und Antworten