Kanban zur Abwicklung von Reporting-Anforderungen
-
Upload
roskakori -
Category
Technology
-
view
1.312 -
download
3
description
Transcript of 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
Folie 3 Stand September 2011Version 1.2
Ausgangssituation
• Reportinglandschaft der Raiffeisen Bankengruppe Steiermark
• Rolle der Abt. Solution Development (SDC)
• Auftraggeber
• Herausforderungen
Folie 4 Stand September 2011Version 1.2
Reporting für RBG Steiermark
Steiermark-spezifische
Auswertungen
Ad hocAuswertungenund generelle
Datenänderungen
Abt. Solution DevelopmentRRZ Süd
SektorweiteAuswertungen
AndereHersteller
Folie 5 Stand September 2011Version 1.2
Wer sind die Auftraggeber?
Ca. 20 Fachbereiche
Ca. 90 Banken
Steiermark-spezifische
Auswertungen
Ad hocAuswertungenund generelle
Datenänderungen
Abt. Solution DevelopmentRRZ Süd
Auftrag
Folie 6 Stand September 2011Version 1.2
Herausforderungen
• Mehr als 100 verschiedene Auftraggeber
• Breite Streuung bei Umsetzungszeit
• Breiter technologischer Werkzeugkasten
Folie 7 Stand September 2011Version 1.2
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?
Folie 8 Stand September 2011Version 1.2
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
Folie 9 Stand September 2011Version 1.2
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
Folie 10 Stand September 2011Version 1.2
Darstellung der aktuellen Aufträge
• Über Tafel („White board“)
• Analog und/oder digital
• Basis für tägliche Kurzabstimmung
Folie 11 Stand September 2011Version 1.2
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
Folie 12 Stand September 2011Version 1.2
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
Folie 13 Stand September 2011Version 1.2
White board - analog
• Ein Post-It für jeden Auftrag
• Kurzbeschreibung, Startdatum, Enddatum
• Verschiedene Farben für Klassifizierung
Folie 14 Stand September 2011Version 1.2
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
Folie 15 Stand September 2011Version 1.2
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
Folie 16 Stand September 2011Version 1.2
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
Folie 17 Stand September 2011Version 1.2
White board - konkret
• Schwimmbahnen für Software (SW) und Organisatorisches (ORG)
• Über Trac und dynamische Wiki-Dokumente
Spalte entspricht Auftragsstatus
Eindeutige Auftragsnummer
Kurzbeschreibung
Folie 18 Stand September 2011Version 1.2
White board - Zusammenfassung
• Kompakte Darstellung aller aktuell bearbeiteten Aufträge
• Analog und/oder digital
• Auftragsstatus und ev. Schwimmbahnen
• Gestaltung nach eigenem Bedarf
Folie 19 Stand September 2011Version 1.2
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
Folie 20 Stand September 2011Version 1.2
Tägliche Kurzabstimmung - konkret
• Vor Mittagspause
• Dauer i.d.R. 5 bis 10 Minuten
• Kurze inhaltliche Diskussionen erlaubt
• Kaum Nachbesprechungen
Folie 21 Stand September 2011Version 1.2
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
Folie 22 Stand September 2011Version 1.2
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
Folie 23 Stand September 2011Version 1.2
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
Folie 24 Stand September 2011Version 1.2
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)
Folie 25 Stand September 2011Version 1.2
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
Folie 26 Stand September 2011Version 1.2
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
Folie 27 Stand September 2011Version 1.2
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, …)
Folie 28 Stand September 2011Version 1.2
Konkreter Nutzen für uns
• Erkennen von Engpässen
• Sachliches Darstellen von Engpässen
• Kaum konkrete Zieltermine für Aufträge
• Kaum Terminverschiebungen
Folie 29 Stand September 2011Version 1.2
Pull-Prinzip
• Mitarbeiter holt selbstständig nächsten Auftrag aus der Warteschlange
• Höhere Selbstständigkeit
• Keine konkrete Anweisung vom Vorgesetzten
Folie 30 Stand September 2011Version 1.2
Pull-Prinzip - konkret
• Nicht in Verwendung
• Kein erkennbarer Vorteil
• Nicht jeder Auftrag für jeden bearbeitbar
• Stattdessen: Team ermittelt Bearbeiter
Folie 31 Stand September 2011Version 1.2
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
Folie 32 Stand September 2011Version 1.2
Verteilung der Durchlaufzeit
• Durchlaufzeit = von Auftragserteilung bis Einsatz
• Ergibt zusicherbare Durchlaufzeit
• Zum Erkennen von „Ausreißern“ Spektralanalyse
Folie 33 Stand September 2011Version 1.2
Verlauf des Work in progress (WIP)
• Ziel: Höhen sind stabil
Verbesserung bei Einsatzplanung
Ferialpraktikant mehr Kapazität
Urlaube bei Auftraggeber weniger
Testabnahmen
Folie 34 Stand September 2011Version 1.2
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
Folie 35 Stand September 2011Version 1.2
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/
Folie 36 Stand September 2011Version 1.2
Fragen und Antworten