5.3 Kanban

Der Begriff „Kanban“ bezeichnet in der Fertigung Signalkarten, die zur Steuerung von Produktionsabläufen eingesetzt werden. Während der gesamten Produktion begleiten diese Karten die einzelnen Materialien und signalisieren den jeweiligen Produktionsstufen, dass die vorgelagerten Arbeitsschritte fertiggestellt wurden. Die Anzahl der Signalkarten ist allerdings limitiert, wodurch Produktionsstaus vermieden werden. Sofern alle Signalkarten in Bearbeitung sind, kann mit neuer Arbeit erst dann begonnen werden, sobald eine Karte den gesamten Prozess durchlaufen hat und wieder verfügbar wird (vgl. Leopold / Kaltenecker 2012: S. 11–12). Dieses Prinzip, bei dem neu begonnene Arbeiten begrenzt werden, nutzte David J. Anderson für die Entwicklung von Kanban in der Softwareentwicklung. Er entwickelte ein System, mit dem Unternehmen eine Kultur der kontinuierlichen Verbesserung erreichen können (vgl. Anderson 2011: S. 19). Im Folgenden werden die Grundzüge dieses Systems erläutert und auf Six Sigma Projekte übertragen.

 

5.3.1 Vorstellung der Methodik

Nach Anderson setzt sich Kanban aus den folgenden fünf Praktiken zusammen (vgl. Anderson 2011: S. 19):

  1. Visualisiere den Fluss der Arbeit (Workflow)
  2. Begrenze den Work in Progress (Menge an begonnener Arbeit)
  3. Führe Messungen zum Fluss durch und kontrolliere ihn
  4. Mache die Regeln für den Prozess explizit
  5. Verwende Modelle, um Chancen für Verbesserungen zu erkennen (vgl. Anderson 2011: S. 19)

Eine erfolgreiche Anwendung von Kanban beginnt mit der Visualisierung des Prozesses. Dies geschieht unter Zusammenarbeit aller Mitarbeiter, die an dem betreffenden Prozess beteiligt sind und somit das Kanban-Team bilden. Sie grenzen die einzelnen Prozessschritte voneinander ab und legen fest, welche Aufgaben von welchem Bereich übernommen werden. Zentrales Element bei der Visualisierung des Prozesses ist das Kanban-Board, welches in Bild 3.1 beispielhaft dargestellt ist (vgl. Leopold / Kaltenecker 2012: S. 24–25).

Das Kanban-Board umfasst alle zu erledigenden Aufgaben in Form von beschriebenen Haftnotizen oder einfachen Karten. Diese werden spaltenweise jeweils dem Prozessschritt zugeordnet, der aktuell mit deren Bearbeitung beschäftigt ist. Zur besseren Transparenz über den aktuellen Status einzelner Aufgaben, können die Spalten der Prozessschritte außerdem in die Abschnitte „in Arbeit“ und „Fertig“ unterteilt werden. In der Spalte der Input Queue finden sich dabei alle Aufgaben, die noch zu erledigen sind und aktuell nicht bearbeitet werden (vgl. Leopold / Kaltenecker 2012: S. 25–28). Die einzelnen Aufgaben durchwandern im weiteren Arbeitsverlauf die einzelnen Spalten, gemäß des tatsächlichen Arbeitsfortschrittes. Nach dem Pull-Prinzip bestimmen die jeweiligen Mitarbeiter, wann eine neue Karte aus dem vorgelagerten Teilprozess zu ihrem Bereich wandern darf. Damit geben sie das Signal, dass sie alle Arbeiten erledigt haben und mit der neuen Aufgabe beginnen können. Auf diese Weise wird vermieden, dass die Mitarbeiter einzelner Prozessabschnitte mit zu viel Arbeit überfordert werden (vgl. Wolf / Bleek 2011: S. 170–171).
Eine weitere Anforderung an Kanban-Systeme, die das Kanban-Board erfüllt, ist die Begrenzung des „work in progress“ (WIP). Demnach wird jeweils die maximale Anzahl an Karten festgelegt, die in einer Spalte aufgeführt sein darf. Diese Begrenzungen werden als „WIP-Limits“ bezeichnet. Sie beugen zum einen der Überlastung einzelner Prozessabschnitte vor und zeigen gleichzeitig Engpässe auf. Falls beispielsweise die Analyse bestimmter Anforderungen abgeschlossen sein sollte, so wird mit der entsprechenden Entwicklung nicht begonnen, wenn das WIP-Limit dieses Prozessabschnitts bereits erreicht worden ist. Durch das Kanban-Board wird die angestaute Arbeit für alle Teammitglieder sichtbar und Lösungen werden zeitnah diskutiert (vgl. Wolf / Bleek 2011: S. 171).
Nachdem das Kanban-Board mit den entsprechenden WIP-Limits angefertigt worden ist, steht das Team vor der Herausforderung, den Arbeitsfluss zu koordinieren und zu managen (vgl. Leopold 2016: S. 22). Darunter fallen die verschiedensten Tätigkeiten, wie beispielsweise die Einteilung der zu bearbeitenden Aufgaben in Serviceklassen. Nach Anderson können die Aufgaben zum Beispiel nach dem Grad ihrer Dringlichkeit klassifiziert werden. Dementsprechend durchwandern die Aufgaben bzw. die entsprechenden Karten auf dem Kanban-Board, in unterschiedlicher Reihenfolge das System. Dies hilft dabei, auf Kundenwünsche einzugehen und besonders dringende Tätigkeiten schneller zu erledigen (vgl. Anderson 2011: S. 131–132).
Um einen gleichmäßigen Arbeitsfluss sicherzustellen, sieht das Kanban-System außerdem Messungen zur Leistungsbewertung der aktuellen Arbeitsabläufe vor. Neben der Durchlaufzeit und dem Durchsatz, wird hierzu häufig ein „Cumulative Flow Diagram“ (CFD) genutzt. Dieses gibt Aufschluss über das Verhältnis zwischen begonnenen, fertiggestellten und sich in Bearbeitung befindenden Arbeiten (vgl. Leopold 2016: S. 161). Bild 3.2 zeigt ein Beispiel für ein CFD, bei dem entweder keine WIP-Limits eingefügt worden sind oder diese nicht eingehalten werden. Dies ist daran zu erkennen, dass der Graph des WIP eine höhere Steigung aufweist, als der Graph der fertiggestellten Arbeiten. In dem Beispiel werden also zunehmend mehr Arbeiten begonnen, als fertiggestellt werden. In diesem Fall sollte das Team die Einhaltung der WIP-Limits kontrollieren und die entsprechenden Engpässe im Prozessablauf analysieren (vgl. Leopold 2016: S. 161). Die Diskussion über bestehende Engpässe findet meist während den täglichen Standup-Meetings statt. Hierbei trifft sich das gesamte Team und bespricht den aktuellen Status einzelner Aufgaben. Die Diskussion erfolgt anhand des Kanban-Boards, da dies den derzeitigen Stand visualisiert und dementsprechend angestaute Kanban-Karten sichtbar werden (vgl. Anderson 2011: S. 90–91).



Letztlich sind zwei weitere Praktiken zu erwähnen, die Kanban auszeichnen. Zum einen sieht ein Kanban-System vor, dass die Prozessregeln für alle Beteiligten deutlich gemacht werden. Damit sind Arbeits- und Verhaltensweisen gemeint, die den Ablauf des Prozesses regeln. Hierunter sind nicht die offiziell vorgegebenen Regeln zu verstehen, sondern solche, die den realen Prozessablauf wiedergeben. Oft sehen offizielle Arbeitsanweisungen die Einhaltung bestimmter Vorgaben vor, die im alltäglichen Arbeitsablauf von Mitarbeitern ignoriert werden. Für das Kanban-System sollten demnach Regeln dokumentiert werden, welche die tatsächlichen Arbeitsweisen der Mitarbeiter festhalten. An diese Regeln haben sich alle Mitglieder des Kanban-Teams zu halten. Lediglich wenn Einigkeit darüber herrscht, dass eine Regel nicht länger sinnvoll ist, muss diese geändert werden (vgl. Leopold 2016: S. 22–23). Die letzte Praktik, auf der Kanban basiert, bezieht sich auf die kontinuierliche Verbesserung durch den Einsatz von Methoden und Modellen. Dies ist dem Umstand geschuldet, dass Kanban lediglich Praktiken und Prinzipien vorgibt, allerdings keine festen Regeln aufstellt, wie diese umzusetzen sind. Die zuvor beschriebenen Werkzeuge sind lediglich als Vorschläge zu sehen, die bei der Implementierung eines Kanban-Systems helfen können. Daher wird Kanban häufig mit anderen Methoden, wie beispielsweise Scrum, kombiniert (vgl. Wolf / Bleek 2011: S. 173). Durch dieses Zusammenspiel mit konkreteren Modellen sollen Verbesserungspotenziale identifiziert und letztendlich genutzt werden.

 

5.3.2 Anwendbarkeit bei Six Sigma Projekten

Wie in Kapitel 5.3.1 deutlich wurde, ist das grundlegende Werkzeug von Kanban das Kanban-Board. Es visualisiert die Aufteilung eines Prozesses in dessen einzelne Abschnitte und gibt den Arbeitsfluss der verschiedenen Aufgaben wieder (vgl. Leopold / Kaltenecker 2012: S. 24-25). Um ein solches Konzept bei Six Sigma Projekten anzuwenden, ist es möglich, die einzelnen Phasen des DMAIC-Zyklus als Prozessschritte anzusehen. Hierzu teilt sich das Projektteam in mehrere kleine Teams auf. Jedes Team ist für eine der Six- Sigma-Phasen zuständig und damit verantwortlich für die Erledigung der jeweils anfallenden Aufgaben. Die zu bearbeitenden Aufgaben durchlaufen anschließend nach dem Pull-Prinzip alle Phasen bzw. Prozessschritte. Ähnlich zu der in Kapitel 5.1.2 beschriebenen Anwendung der Scrum-Methodik bei Six Sigma Projekten, bildet auch hier die Define-Phase eine Ausnahme. Diese ist lediglich einmalig für das gesamte Projekt zu durchlaufen, da die Definition der Gesamtproblematik die Grundlage für alle darauffolgenden Phasen bildet. Die Define-Phase ist nach dem Kanban-System vergleichbar mit den Input Queue, welche sich aus allen zu bearbeitenden Aufgaben zusammensetzen (vgl. Leopold / Kaltenecker 2012: S. 25). Hier müssen also alle Aufgabenpakete definiert werden, bevor diese in den einzelnen Teams bearbeitet werden.



Szenarien wie dieses sind nicht unwahrscheinlich, da in den einzelnen Phasen des DMAIC-Zyklus unterschiedliche Arten von Aufgaben erledigt werden. Die Zeit, die für die verschiedenen zu erledigenden Tätigkeiten benötigt wird, ist demzufolge bei jeder Phase individuell. Bei Six Sigma Projekten sind Staus im Arbeitsablauf allerdings schwerwiegender als im Rahmen von unternehmensinternen Abläufen. Durch den Stau der Arbeit werden normalerweise die Engpässe innerhalb eines Prozesses aufgedeckt. Dadurch können Verbesserungen vorgenommen werden und das Unternehmen profitiert langfristig durch einen durchgängigen Arbeitsfluss. Die Anwendung von Six Sigma erfolgt allerdings im Rahmen eines Projekts, welches in einem bestimmten Zeitraum abgeschlossen werden muss (vgl. Töpfer 2007: S.72). Engpässe innerhalb des Projekts sollten demnach von Anfang an vermieden werden, da diese die Projektdauer und die damit verbundenen Projektkosten weiter ansteigen lassen. Wenngleich sich die Umsetzung eines Six Sigma Projekts nach dem Kanban-System als schwierig erweist, so können dennoch WIP-Limits eingefügt werden, um die begonnene Arbeit zu beschränken. Demnach wird innerhalb des Teams festgelegt, wie viele Aufgaben gleichzeitig bearbeitet werden dürfen. Während des gesamten Projekts wird schließlich festgehalten, welche Aufgaben bereits in Bearbeitung sind. Das Projektteam darf zu keiner Zeit das vorher vereinbarte WIP-Limit übersteigen. Hierzu ist eine genaue Definition der Arbeitspakete unerlässlich, damit erkennbar ist, welche Arbeitsschritte mit einer Aufgabe verbunden sind.
Das Kanban-Board selbst kann außerdem als Werkzeug genutzt werden. Während der Measure-Phase wird der Arbeitsfluss des zu verbessernden Prozesses durch ein Kanban-Board visualisiert. Die an dem Prozess beteiligten Mitarbeiter müssen dazu den auf dem Board dargestellten Arbeitsfluss durchgängig aktualisieren. Das Projektteam erstellt zur besseren Erfassung der Gesamtsituation außerdem ein Cumulative Flow Diagram. Dadurch erkennt das Team, ob an bestimmten Prozessabschnitten zu viele Arbeiten gleichzeitig verrichtet werden. Anschließend kann das Projektteam die gewonnenen Informationen über den Arbeitsfluss nutzen, um in der Analyze-Phase Engpässe zu identifizieren. Diese geben Hinweise auf die Problemursache und beschleunigen daher die Optimierung des Prozesses. Durch die Einführung von WIP-Limits an Engpässen können in diesem Fall bereits frühzeitig Verbesserungen erzielt werden.

 

5.3.3 Nutzen der Anwendung

Six Sigma Projekte profitieren vor allem von der Einführung von WIP-Limits. Diese wirken sich hauptsächlich auf die Zusammenarbeit im Projektteam aus. Projekte scheitern häufig daran, dass das Projektteam zu viele Aspekte gleichzeitig bearbeiten und optimieren möchte (vgl. Toutenburg / Knöfel 2009: S. 48). Durch die Einführung der WIP-Limits wird die begonnene Arbeit innerhalb des Projektteams beschränkt. Die Teammitglieder sind demnach gezwungen, sich auf die Bearbeitung und Fertigstellung ausgewählter Aufgaben zu konzentrieren. Die Arbeitsweise des Teams gewinnt dadurch an Effizienz, da die wenigen begonnenen Aufgaben die volle Aufmerksamkeit der Teammitglieder erhalten.
Aus der gesteigerten Arbeitseffizienz lässt sich schließen, dass die Projektdauer langfristig gesehen sinkt. Anstatt viele verschiedene Arbeiten lediglich in Teilen fertigzustellen, wird jede einzelne Aufgabe nacheinander abgeschlossen. Dies sorgt für mehr Struktur innerhalb des Projekts und den Beteiligten ist zu jeder Zeit bekannt, welche Aufgaben erledigt sind. Das wiederum vereinfacht sowohl die aktuelle Bestandsaufnahme des Projekts, als auch die Einschätzung der benötigten Zeit bis zum Abschluss des Projekts. Zusätzlich wird die Effektivität des Projektteams durch den Einsatz des Kanban-Boards als Werkzeug gesteigert. Da das Projektteam den Arbeitsfluss des zu verbessernden Prozesses visualisiert und auf dem aktuellen Stand hält, erkennt es frühzeitig eventuelle Engpässe. Dadurch erhält das Team Hinweise darauf, welche Prozessschritte genauer untersucht werden sollten. Im Idealfall findet sich hierdurch frühzeitig die Problemursache, wodurch früher an der entsprechenden Verbesserung gearbeitet werden kann. Das Projektteam muss sich im günstigsten Fall also nicht mit weiterführenden Analysen aller Prozessschritte aufhalten, sondern erkennt, auf welche Bereiche es sich konkret konzentrieren sollte. Auf diese Weise werden die tatsächlich relevanten Aspekte früher erkannt und bearbeitet.

 

Navigation

1. - 4. Einleitung

5.1 Scrum

5.2 Design-Thinking

5.3 Kanban




Literaturverzeichnis

  • Anderson 2011 Anderson, David J.: Kanban. Evolutionäres Change Ma- nagement für IT-Organisationen, Heidelberg: dpunkt.verlag GmbH, 2011.
  • Leopold / Kaltenecker 2012 Leopold, Klaus / Kaltenecker, Siegfried: Kan- ban in der IT. Eine Kultur der kontinuierlichen Verbesserung schaffen, Mün- chen: Carl Hanser Verlag, 2012.
  • Leopold 2016 Leopold, Klaus: Kanban in der Praxis. Vom Teamfokus zur Wertschöpfung, München: Carl Hanser Verlag, 2016, online unter: https://www.hanser-elibrary.com/doi/book/10.3139/9783446446540, [Stand: 28.05.2018].
  • Töpfer 2007 Töpfer, Armin: Six Sigma als Projektmanagement für höhere Kundenzufriedenheit und bessere Unternehmensergebnisse. In: Töpfer, Armin (Hrsg.), Six Sigma. Konzeption und Erfolgsbeispiele für praktizierte Null-Fehler- Qualität, 4. Auflage, Berlin: Springer-Verlag, 2007, S. 45-99, online unter: https://link.springer.com/content/pdf/10.1007%2F978-3-540-48593-3.pdf, [Stand: 28.05.2018].
  • Toutenburg / Knöfel 2009 Toutenburg, Helge / Knöfel, Philipp: Six Sigma. Methoden und Statistik für die Praxis, 2. Auflage, Berlin: Springer-Verlag, 2009.
  • Wolf / Bleek 2011 Wolf, Henning / Bleek, Wolf-Gideon: Agile Softwareent- wicklung. Werte, Konzepte und Methoden, 2. Auflage, Heidelberg: dpunkt.verlag GmbH, 2011.

agile Methoden


Der Begriff „agil“ selbst beschreibt keine Methode, sondern eine bestimmte Denkweise. Dies bedeutet allerdings nicht, dass keine agilen Methoden existieren. Hierbei handelt es sich unter anderem um Methoden wie Scrum, Design-Thinking und Kanban. Diese Methoden werden in dem folgenden Artikel „Anwendung ausgewählter agiler Methoden bei Six Sigma Projekten" beschrieben.

 

Flexibles Projektmanagement ist ein Teil der agilen Methoden. APQC hat zu diesem Bereich eine kurze Umfrage durchgeführt.
 

Six Sigma Deutschland GmbH – Ihr Spezialist für Six Sigma Trainings

DMC Firewall is a Joomla Security extension!
Cookies erleichtern die Bereitstellung unserer Dienste. Mit der Nutzung unserer Dienste erklären Sie sich damit einverstanden, dass wir Cookies verwenden.
Ok