Your SlideShare is downloading. ×
0
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Kanban zur Abwicklung von Reporting-Anforderungen
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Kanban zur Abwicklung von Reporting-Anforderungen

1,294

Published on

Aufträge zu Auswertungen im Bankwesen stelle durch ihre eine hohe Anzahl möglicher Auftraggeber, eine breite Streuung in der Komplexität und Umsetzungszeit sowie das weit gestreute Technologie-Set …

Aufträge zu Auswertungen im Bankwesen stelle durch ihre eine hohe Anzahl möglicher Auftraggeber, eine breite Streuung in der Komplexität und Umsetzungszeit sowie das weit gestreute Technologie-Set eine Herausforderung dar. Kanban ist eine schlanke und flexible Abwicklung, die unterstützt, solche Aufträge produktiv und prompt zu erledigen, so dass sowohl der Kunde als auch der Bearbeiter zufrieden sind. Eine Präsentation erfolgte auf der 9. Anwenderkonferenz für Software Qualität und Test (ASQT) 2011.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,294
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • … damit Sie einen Überblick erhalten, was Kanban ist, Bewerten können, ob Kanban auch für ihre Anforderungen geeignet ist und ggf. Anregungen für eine Umsetzung erhalten.
  • Ausgangssituation Zum „Abholen“ Einschätzung, in wie weit unsere Situation mit Ihrer vergleichbar ist. Überblick Kanban Was bedeutet das Wort? Wie ist Kanban entstanden? Was sind die Ziele und Prinzipien dahinter? Umsetzung Theoretisch: Beschreibung der wichtigsten Maßnahmen und Empfehlungen aus der Literatur Praktisch: Wie haben wir die Maßnahmen konkret umgesetzt? Kennzahlen Beispiele für Kennzahlen, die sich aus der Abwicklung ergeben Wie kann ich damit Verbesserungspotential erkennen?
  • Beispiel: Sektorweit: Deckungsbeitragsrechnung. Steiermarkspezifisch: Ranking der Banken entsprechend der steirischen Vertriebsstrategie. Ad hoc: komplexe Kundenpotentialanalysen (einfach über Kundenbeziehungsmanagement-Anwendung) Generelle Datenänderungen: Umstellung von Kunden auf neue Bankomart-Karte  manuell möglich aber nicht sinnvoll
  • Umsetzungszeit: weniger als eine Stunde bis mehrere Monate; Linientätigkeit oder Projekt Technologien: EasyTrieve, FOCUS, SQL, Python, SAP, …
  • Priorisierung: Welcher Auftrag wird als nächster Bearbeitet? Wie stellen wir die einzelnen Auftraggeber untereinander zufrieden? Wie bearbeite ich produktiv langfristige Aufträge und zwischendurch kurzfristige? Handlungsbedarf: zB bei Engpässen Mitarbeiter beherrschen die einzelnen Werkzeuge in unterschiedlicher Tiefe.
  • Seit den späten 40iger Jahren Beispiel für zu vermeidende Situation: 100 Türen und nur 5 Karosserien sind für den Zusammenbau bereit Ergibt nur 5 Autos obwohl Türen für 25 Vermeiden durch „Türkarte“: Wenn Mitarbeiter Tür für den Einbau holt, legt er eine Türkarte ab und gibt damit den Aufrag, eine neue Tür nach zu produzuieren. Beschränkte Anzahl von Türkarten, Karosseriekarten, usw.; ohne Karte keine Produktion. Für Software-Entwicklung: In angepasster Form
  • Vorteile: Darstellung: Basis für Planung und Monitorung der Tätigkeiten; liefert Daten für Metriken WIP-Limit: Mitarbeiter bleiben eher im „Flow“. Priorisierung: Auftraggeber sagt selbst, was er am schnellsten haben will. Pull-Prinzip: Weniger Overhead für Bereichsleiter, mehr Eigenständigkeit für Mitarbeiter. Buffet: Viel Freiheit, was man wie verwendet. Schrittweise Umsetzung von Kanban möglich. Beabeitung bleibt gleich: Keine neuen Entwicklungswerkzeuge, Prozesse, Personen. Organisation bleibt gleich und ändert sich im Laufe der Zeit mit.
  • Stati und Schwimmbahnen sind „für mich“ da, nicht umgekehrt Team kennt Abwicklung selbst am besten Team kann sich mit den von ihm selbst definierten Gegebenheiten identifizieren
  • Digital Aufenthaltort: in jedem Büro mit Netzwerk verfügbar Prozesskennzahlen: i.d.R. in Datenbanken Analog Infatrstruktur: Post-It und Packpapier Ständig schtbar: auch für mehrere Personen, sofern im selben Raum
  • Technische Infrastruktur: Trac Ticket Tracker mit Customizing Keine fühlbaren nachteiligen Auswirkungen Details für Ticket: Auftragsdetails, Notizen, Konzeptüberlegungen usw.
  • Bedeutung der Stati: Warteschlange = wird demnächst in Arbeit genommen In Arbeit = wir Arbeiten an der Umsetzung Im Test = Umsetzung abgeschlossen, Auftraggeber kann testen Einsatzbereit = Auftraggeber hat Software abgenommen, Übergabe in den Betrieb kann erfolgen
  • Nachbesprechung: mit inhaltlichen Diskussion durch die unmittelbar Beteiligten
  • Vor Mittagspause: jeder strebt promptes Ende an Kurze inhaltliche Diskussion: solange Dauer im o.a. Rahmen bleibt Kaum Nachbesprechungen:  i.d.R. „Thema für Nachmittag“
  • Informiert: durch tägliche Kurzabstimmung Vereinfachung: aktuelle Aufträge des Mitarbeiters sind bekannt und einsehbar. Zuvor individuell über schriftliche Notizen, Todo-Liste in Excel, Notes-Aufgaben usw. Zuvor: Aufwand Statusberichte in der Größenordnung ein bis mehrere Stunden. Abteilungsintern kaum mehr Statusberichte. Externe Statusberichte = Liste der Aufträge und einige Sätze zu den Highlights
  • Aufträge im White board = Aufträge, die gleichzeitig in Bearbeitung sind
  • Wieder: WIP-Limit ist „für mich“ da, nicht umgekehrt Erster Startwert: Anzahl der Mitarbeiter mal 2 bis 3 Durchlaufzeit = Zeit von Auftragserteilung bis Erledigung (also auch Zeit vor Warteschlange)
  • Zwischenzeitlich erhöhen: Wenig hilfreich: Aufträge ablehnen mit Begründung „mein WIP-Limit ist bereits erreicht“ Immer aktiv bearbeiten: Wenig hilfreich: wenn WIP-Limit erreicht ist und alle aktiven Aufträge blockiert sind, dann nichts bearbeiten Blockiert: Einschränkung: nur wenn vom Team selbst nicht lösbar Anzahl der Abbrüche ist eine Aussage über die Reife des Prozesses und der Organisation
  • Annahme: Nicht jeder Auftraggeber hat nicht immer gleich viele Aufträge Auftraggeber können zwischendurch „aussetzen“ und habe dafür später einmal ein erhöhtes Auftragsaufkommen Mögliches Konsequenz: Auftraggeber stimmen sich bereits vorher ab
  • Außenwirksamkeit = Potential für Irritation
  • Erkennen von Engpässen: Datenbankabfragen und Statisitiken  Beispiele folgen Sachliches Darstellen von Engpässen: gegenüber Vorgesetzten, vorzugsweise mit Lösungsansatz oder Handlungsempfehlung; in Folge auch vor Kunden „ seine fünf wichtigsten“: die Priorität kommt vom Auftraggeber selbst, daher kein „Dazwischenpriorisieren“ mehr Zieltermine: Auftraggeber weiß aus den Erfahrungen, dass seine „fünf wichtigsten“ Aufträge „bald“ erledigt sind. Terminverschiebungen: Weniger organisatorischer Aufwand für etwaige Terminverschiebung und Sachverhaltsdarstellung, da kaum Termine
  • Kein Vorteil: stiftete eher Verwirrung. Nicht jeder Auftrag bearbeitbar: Grund: Breites Technologieset und Spezialwissen Abstimmung des Bearbeiters im Team: bereits in Warteschlange ist klar, wer es macht
  • Zusicherbare Durchlaufzeit: für Service Level Agreement (SLA)
  • Ändert lediglich Abwicklung, eigentliche Bearbeitung bleibt gleich (Personen, Werkzeuge, …; wenig Schulungsbedarf) Unterstützt Aufträge mit sehr unterschiedlichen Bearbeitungszeiten.
  • Transcript

    • 1. Kanban zur Abwicklung von Reporting-Anforderungen und Datenänderungen Thomas Aglassinger Version 1.2
    • 2. Agenda
      • Ausgangssituation
      • Überblick Kanban
      • Umsetzung: theoretisch und praktisch
      • Kennzahlen
      • Fragen und Antworten
    • 3. Ausgangssituation
      • Reportinglandschaft der Raiffeisen Bankengruppe Steiermark
      • Rolle der Abt. Solution Development (SDC)
      • Auftraggeber
      • Herausforderungen
    • 4. Reporting für RBG Steiermark Steiermark- spezifische Auswertungen Ad hoc Auswertungen und generelle Datenänderungen Abt. Solution Development RRZ Süd Sektorweite Auswertungen Andere Hersteller
    • 5. Wer sind die Auftraggeber?
      • Ca. 20 Fachbereiche
      Ca. 90 Banken Steiermark- spezifische Auswertungen Ad hoc Auswertungen und generelle Datenänderungen Abt. Solution Development RRZ Süd Auftrag
    • 6. Herausforderungen
      • Mehr als 100 verschiedene Auftraggeber
      • Breite Streuung bei Umsetzungszeit
      • Breiter technologischer Werkzeugkasten
    • 7. 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?
    • 8. Kanban
      • jap. 看板 , dt. „ Karte “, „Tafel“, „Beleg“
      • Ursprünglich bei Autoherstellung
        • Minimierung der Lagerbestands
        • Gezieltes Herstellen von Zwischenprodukte
      • In Folge auch in anderen Produktionsbetrieben
      • Seit einigen Jahren auch für Software-Entwicklung
    • 9. 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 sich Auftrag selbst aus Warteschlange
      • Buffet-Ansatz : jene Maßnahmen umsetzen, die Nutzen bringen
      • Eigentliche Bearbeitung des Auftrags bleibt gleich
    • 10. Darstellung der aktuellen Aufträge
      • Über Tafel („White board“)
      • Analog und/oder digital
      • Basis für tägliche Kurzabstimmung
    • 11. White board
      • Enthält alle derzeit bearbeiteten Aufträge
      • Auftrag durchläuft Stati bis zur Erledigung.
      • Bei Bedarf: verschiedene Schwimmbahnen („swim lanes“).
      Erledigte Aufträge Auftrags- bestand Priorisierung Erledigung
    • 12. 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
    • 13. White board - analog
      • Ein Post-It für jeden Auftrag
      • Kurzbeschreibung, Startdatum, Enddatum
      • Verschiedene Farben für Klassifizierung
    • 14. White board - digital
      • Vollständige Kanban-Anwendungen
      • Auf Basis von Ticket-Trackern
        • Kanban über Plugins oder Customing
        • Kennzahlen über Plugins oder Scripting
      • Zahlreiche Systeme am Markt
    • 15. 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
    • 16. 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
    • 17. White board - konkret
      • Schwimmbahnen für Software (SW) und Organisatorisches (ORG)
      • Über Trac und dynamische Wiki -Dokumente
      Spalte entspricht Auftragsstatus Eindeutige Auftragsnummer Kurzbeschreibung
    • 18. White board - Zusammenfassung
      • Kompakte Darstellung aller aktuell bearbeiteten Aufträge
      • Analog und/oder digital
      • Auftragsstatus und ev. Schwimmbahnen
      • Gestaltung nach eigenem Bedarf
    • 19. 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
    • 20. Tägliche Kurzabstimmung - konkret
      • Vor Mittagspause
      • Dauer i.d.R. 5 bis 10 Minuten
      • Kurze inhaltliche Diskussionen erlaubt
      • Kaum Nachbesprechungen
    • 21. 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
    • 22. 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
    • 23. 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
    • 24. Was ist ein sinnvolles WIP-Limit?
      • Anfangswert finden:
        • Normal arbeiten und beobachten
        • 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)
    • 25. 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
    • 26. 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 Auftrag nehmer
    • 27. 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, …)
    • 28. Konkreter Nutzen für uns
      • Erkennen von Engpässen
      • Sachliches Darstellen von Engpässen
      • Kaum konkrete Zieltermine für Aufträge
      • Kaum Terminverschiebungen
    • 29. Pull-Prinzip
      • Mitarbeiter holt selbstständig nächsten Auftrag aus der Warteschlange
      • Höhere Selbstständigkeit
      • Keine konkrete Anweisung vom Vorgesetzten
    • 30. Pull-Prinzip - konkret
      • Nicht in Verwendung
      • Kein erkennbarer Vorteil
      • Nicht jeder Auftrag für jeden bearbeitbar
      • Stattdessen: Team ermittelt Bearbeiter
    • 31. 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
    • 32. Verteilung der Durchlaufzeit
      • Durchlaufzeit = von Auftragserteilung bis Einsatz
      • Ergibt zusicherbare Durchlaufzeit
      • Zum Erkennen von „ Ausreißern “  Spektralanalyse
    • 33. Verlauf des Work in progress (WIP)
      • Ziel: Höhen sind stabil
      Verbesserung bei Einsatzplanung Ferialpraktikant  mehr Kapazität Urlaube bei Auftraggeber  weniger Testabnahmen
    • 34. 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
    • 35. Referenzen
      • Anderson, D.: Kanban – Successful evolutionary change for your technology business (2010, Blue Hole Press)
      • Leopold, K.: Software Kanban im Einsatz http://heise.de/-1235465
      • Hiranabe, K.: Visualizing agile projects using Kanban boards http://www.infoq.com/articles/agile-kanban-boards
      • Patton, J.: Kanban oversimplified http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html
      • Ladas, C.: Scrum-ban http://leansoftwareengineering.com/ksse/scrum-ban /
      • Trac http://trac.edgewall.org /
    • 36. Fragen und Antworten

    ×