Das Kanban-System wurde in den 1950er Jahren in den Fertigungslinien der Toyota Corporation eingeführt.
Danach wurde es in Bürobereiche übertragen und wurde zu einem wesentlichen Werkzeug für Projektmanager.
Die grenzenlose Flexibilität von Kanban in der Praxis und die Fähigkeit zur Selbstverwaltung von Teams
haben dafür gesorgt, dass dort Effizienz erzielt wurde, wo andere Ansätze versagt haben. In diesem speziellen Fall hat sich die Identitätskarte des Systems
als grundsätzlich eine Karte etabliert, die sich weiter zur internen Währung in
Einrichtungen mit angenommenem Kanban entwickelt hat.
Ursprünge
Ähnlich wie das Lean-Management-Konzept wurde das Kanban-System von Toyota
Managern entwickelt. Taiichi Ohno, ein japanischer Wirtschaftsingenieur und Autor des Systems, ließ sich von dem Betriebsprinzip amerikanischer Supermärkte inspirieren, wo der Käufer selbst die benötigten Produkte auswählte. Das Lager spielte in der Toyota Corporation die Rolle eines solchen „Supermarktes“.
Dort tauschten die Arbeiter Signal-Karten (wörtliche Übersetzung von Kanban aus dem Japanischen) aus und kontrollierten so den Fertigungsprozess selbständig.
Die Karten wurden an Containern mit Teilen befestigt. Solche Etiketten gaben folgende Details an: die
Nummern und die Menge der Teile, die Abteilung, die sie sendete, und ihr Ziel. Der Arbeiter, der direkt mit der Fahrzeugmontage und ‑zerlegung beschäftigt war (downstream), entnahm Teile aus den Containern mit einem angehängten „Kanban“, das einen Antrag an das Lager anzeigte. Die Karte wurde abgenommen, um zusammen mit der leeren Box von einem Transportmitarbeiter ins Lager gebracht zu werden, wo ein anderer Arbeiter bereits einen weiteren Container mit Teilen vorbereitet hatte, an dem ein „Produktions-Kanban“-Etikett angebracht war, um die Daten der produzierten Teile anzuzeigen.
Ein solches Produktions-Kanban wurde durch ein Anfrage-Kanban ersetzt, das an das Lager gerichtet war, um anschließend an die Teilefertigungslinie (upstream) gesendet zu werden. So wurden nur die Menge an Teilen
hergestellt, die auf der Karte angegeben war. Container mit neuen Teilen wurden an die Montage
linie für die Transportarbeiter geliefert.
Prozess
Kanban-Grundlagen
Die Toyota-Manager haben 6 Rahmenregeln formuliert:
- Downstream-Arbeiter entnehmen aus dem Lager genau die Anzahl an Teilen, die in der Kanban-Karte angegeben ist
- Upstream-Spezialisten liefern ebenfalls Teile in strikter Übereinstimmung mit den Karten
- Es wird nichts ohne Kanban hergestellt oder bewegt
- Kanban sollte immer mit Teilen verbunden sein
- Defekte Teile werden im System nicht verwendet
- Jede Verringerung der Anzahl an Kanban-Karten macht das Management empfindlicher gegenüber Veränderungen. Aber Änderungen in der festgelegten Anzahl der Karten sollten nur dann vorgenommen werden, wenn es absolutely notwendig ist.
Kanban ist ein „erweiterndes“ System. Es schafft ein Gleichgewicht zwischen kontinuierlichem Fluss, um die Kosten für Erwartungen auf der einen Seite und der minimalen Menge an Arbeiten in Bearbeitung (WIP) auf der anderen zu beseitigen, was letztendlich das Risiko der Überproduktion reduziert. WIP wird durch Karten reguliert: ihre Anzahl ist festgelegt, und ihre Anweisungen leiten die downstream-Arbeiter.
Die strenge Regel zur Befestigung von Tags funktioniert wie das Gesetz der Energieerhaltung. Die WIP-Grenze ist in
Proportionalität zur Anzahl der Kanban-Karten angegeben, die auf Basis des Verkaufsniveaus und der statistischen
Varianz in aktuellen Prozessen berechnet wurden. Die maximale Anzahl an Tags, die genau die „Systemenergie“ darstellt, fixiert die Obergrenze der WIP innerhalb eines bestimmten Zeitrahmens. WIP wird auch durch das
Erweiterungsprinzip begrenzt: Die upstream-Ausbringungsrate hängt von der downstream-Produktionsrate ab.
Das Schaubild zeigt offensichtlich, dass die Kaizen-Kultur eines der Elemente zugrunde liegenden Systems ist.
Die Selbstnachhaltigkeit von Prozessen und die Standardabweichung entlasten das Management von kontinuierlicher
Kontrolle, sodass es möglich wird, sich auf die Verbesserung der Leistung der Mitarbeiter zu konzentrieren.
Verwendung von Kanban in der IT
Das Kanban-System fand Einzug in den Softwarebereich, während es weiterhin Wert auf den Fertigungsförderern generiert.
Jedoch werden Karten, die solche Details wie Fristen, Prozessbeschreibung oder Nummer und Namen des ausführenden Mitarbeiters anzeigen, jetzt nicht mehr an Containern mit Teilen befestigt, sondern an dem Board mit folgenden Spalten:
Backlog — Aufgaben, die umzusetzen sind
- Aufgaben, die derzeit entwickelt werden;
- Aufgaben, die bereits umgesetzt, jedoch noch nicht an Tester übergeben wurden;
- Aufgaben, die bereit sind, an die Testabteilung weitergegeben zu werden;
- Aufgaben, die gerade von dem Projektmanager (PM) überprüft werden;
- Abgeschlossene Aufgaben.
Eine Begrenzungszahl wird normalerweise über einer Spalte angegeben, um die maximale Anzahl an Prozessen darin zu kennzeichnen. Die Backlog-Grenze wird auf Basis der Durchlaufzeit berechnet. Wenn 5 Arbeiten in Bearbeitung sind
wobei jede von ihnen im Schnitt innerhalb von 1 Tag abgeschlossen werden kann, dann kann das Backlog auch auf 5 begrenzt werden.
Die obige Struktur ist nicht starr – Sie können improvisieren und Spalten je nach den spezifischen Merkmalen Ihres Projekts hinzufügen. Oft verlangen Kanban-Systeme, dass die Kriterien für die Aufgabenbereitschaft vor der Ausführung der Aufgabe bestimmt werden. In einem solchen Fall kommen zwei Spalten ins Spiel, die auf Englisch als specify (d.h. Parameter klären) und execute (d.h. mit der Arbeit beginnen) benannt sind.
- Eine Spalte für priorisierte Warteschlangen kann ebenfalls hinzugefügt werden. Wenn der ausführende Mitarbeiter frei wird, sollte er diese spezifische Aufgaben-Spalte leeren, und erst danach kann er sich um die anderen kümmern.
- Unbegonnene Aufgaben kehren entweder in den Backlog zurück oder werden aus dem Schaubild gelöscht.
- Kanban fördert kein Multitasking, daher wird eine Prozessobergrenze für einen ausführenden Mitarbeiter festgelegt.
- Eine abgeschlossene Aufgabe ist wünschenswerter als mehrere Aufgaben, die gerade begonnen wurden.
- Die zweite Arbeit kann angegangen werden, vorausgesetzt, dass die erste blockiert ist.
- Der Zeitrahmen für die Ausführung der Aufgabe sollte ausgewogen sein. Zu kurze Zeiträume wirken sich negativ auf die Qualität aus. Zu lange Fristen belasten die Ressourcen des Teams übermäßig und machen den Prozess teurer.
Kanban-Vorteile und ‑Nachteile
Kanban hat folgende Vorteile:
- Flexible Planung. Das Team konzentriert sich nur auf die aktuelle Arbeit, und der Manager priorisiert die Aufgaben.
- Das Team ist stark in den Entwicklungsprozess einbezogen. Regelmäßige Besprechungen, Prozess-Transparenz und Möglichkeiten zur Selbstverwaltung machen Teams vereint und wirklich engagiert.
- Reduzierte Zyklusdauer. Wenn mehrere Personen ähnliche Fähigkeiten haben, verringert sich die Dauer, aber wenn nur eine Person relevant qualifiziert ist, entsteht ein Engpass. Daher sollten Fachleute ihr Wissen teilen, um die Zyklusdauer zu optimieren. Dies ermöglicht es dem gesamten Team, die Arbeiten, die verzögert waren, anzugehen und den reibungslosen Workflow wiederherzustellen.
- Verringerte Anzahl an Engpässen. WIP-Limits machen es möglich, Engpässe und problematische Bereiche zu identifizieren, die aufgrund mangelnder Aufmerksamkeit, personeller Ressourcen oder Fähigkeiten entstanden sind.
- Sichtbarkeit. Wenn alle Mitarbeiter Zugang zu Daten haben, ist es einfacher, Engpässe zu bemerken. Neben den Karten verwenden Kanban-Teams normalerweise zwei allgemeine Arten von Berichten: Management-Diagramme und kumulative Workflow-Diagramme.
In der Praxis zeigt das System hervorragende Eigenschaften in solchen Nicht-Kern-Operationen wie:
- Software-Supportgruppen oder Unterstützungsdienste;
- Kanban funktioniert gut im Management von Startups ohne klare Zeitpläne, aber mit aktiver Förderung der Entwicklung.
Kanban hat auch seine Nachteile:
- Das System funktioniert schlecht mit Teams von mehr als 5 Personen.
- Es ist nicht für langfristige Planung ausgelegt.
Unterschied zu Scrum
Wie Agile Kanban ist Scrum eine flexible Methodik und wird ebenfalls häufig im IT-Bereich eingesetzt. Auf den ersten Blick ist der Unterschied zwischen ihnen nicht offensichtlich. Es gibt viele Ähnlichkeiten, z.B. bieten beide
Ansätze einen Backlog.
Beispiele für die Verwendung in der IT
Mit Microsoft direkt: Kanban-Debüt im Bereich der Softwareentwicklung
Die Kanban-Grundlagen fanden vor etwas über 10 Jahren Verwendung im Bereich der Informationstechnologien. David Anderson, einer der Hauptanhänger von Kanban für Softwareentwickler, beriet die Microsoft Company im Jahr 2005. Eine der Abteilungen des Unternehmens, XIT Sustained Engineering, die für die Fehlersuche in internen Anwendungen zuständig war, verursachte Unmut. Zu Beginn des Berichtsjahres stellte sich diese Abteilung als die schlechteste innerhalb ihrer Abteilung heraus. Der Backlog überstieg das fünffache tolerierbare Volumen, und die Bearbeitungszeit einer Anfrage — Lead Time — dauerte in der Regel 5 Monate.
Andersons Beratung ermöglichte dem neuen PM, die Leistung der problematischen Abteilung in 9 Monaten um 155% zu steigern. Die Lead Time wurde auf 5 Wochen reduziert, der Backlog erreichte sein normales Volumen zurück, und die rechtzeitige Ausführung von Aufgaben wurde auf 90% festgelegt. All diese Ergebnisse wurden mit minimalem Einfluss neuer Spezialisten erreicht, und das Personal setzte weiterhin Programmfehler mit denselben Methoden — nur die Arbeitsorganisationsansätze wurden geändert — behoben.
Interessanter Fall: Dragos Dumitriou, ein Softwaremanager, der sich vornahm, die Situation in XIT zu wenden, war gerade zu dieser Zeit in Andersons Buch vertieft. Zu seiner Überraschung traf er den Ideologen von Software Kanban in der Microsoft Company, wo dieser kurz zuvor beschäftigt war. Dumitriou bat Anderson um Unterstützung bei seiner Aufgabe, und Anderson stimmte zu, die in seinem Buch beschriebenen Prinzipien in die Praxis umzusetzen.
Dumitriou fand eine Abteilung mit drei Entwicklern und drei Testern vor, deren Backlog 80 Anfragen angesammelt hatte. Die Ernennung des PM war vorübergehend, da die Anforderungen an die Stelle die Fähigkeit zur Handhabung der ASP-Technologie, SQL-Server-Administration und Kenntnisse von MS Project Server umfassten. Die obere Führungsebene stellte sich „einen Techniker“ für diese Position vor, der programmieren kann und verantwortlich für die Erstellung von Berichten und das Vorhersagen der Backlog-Lasten ist. Das Problem der Abteilung sollte vermutet werden, da ein erhebliches Datenset zusammengestellt wurde. Dumitriou war aber tatsächlich kein solcher „Techniker“.
Nach Beginn der Analyse des XIT-Betriebs mit Anderson entdeckte er schnell die Schlüssel Faktoren, die sich negativ auf das Tempo der Abteilung auswirkten:
- Die Vorhersage der Konsequenzen (ROM) aus der Ausführung von Anfragen dauerte zu lange. Sowohl Entwickler als auch Tester mussten den gesamten Arbeitstag aufwenden, um erforderliche Berechnungen anzustellen, den Code zu überprüfen und Dokumente abzuschließen. Im Durchschnitt wurde eine Anfrage pro Tag empfangen. Laut den Berechnungen des PM benötigte ROM 40% der produktiven Kapazität der Abteilung;
- Priorität wurde Anfragen mit höherem Wert eingeräumt. XIT erhielt Mittel aus den Budgets der Aufträge.
- Die Prioritätsreihung der Aufträge wurde monatlich in den Meetings der Abteilungsleiter mit den Kunden — Managern anderer Abteilungen — besprochen. Angesichts des wachsenden Backlogs in der aktuellen Geschwindigkeit, als nur 6 – 7 Anfragen pro Monat bearbeitet wurden, verschoben sich die Prioritäten anderer Anfragen ständig im Laufe der Zeit. Viele von ihnen wurden auf die ferne „später“ verschoben, was nicht einmal den folgenden Monat bedeutete.
- Die Hälfte der Anfragen fiel im ROM-Stadium weg. Ein Teil von ihnen war zu groß, sodass sie in Projekte umklassifiziert werden mussten und an andere Abteilungen übertragen werden sollten, andere wiederum waren zu kostspielig und wurden einfach storniert. Einige Anfragen wurden nicht zur Entwicklung angenommen, weil deren Einführung zu zeitaufwändig sein würde. Daher wurden 40% der Produktivität der Abteilung für die Analyse von Anfragen aufgewendet, von denen 50% abgelehnt wurden. Ungefähr 15 – 20% der Arbeitsressourcen wurden verschwendet.
- Die Vorausplanung von Anfragen konnte Monate dauern, bevor mit der Einführung begonnen wurde. Berechnungen, die im ROM-Stadium durchgeführt wurden, konnten über einen solchen Zeitraum verloren gehen oder vergessen werden. Dies galt besonders dann, wenn das Einführungsverfahren von einem anderen Entwickler — nicht von dem, der die Analyse begonnen hatte — übernommen wurde.
Kanban-Lösungen für Microsofts problematische Abteilung
- Im Dialog mit den oberen Managern sowie mit den Kundenmanagern bestanden Dumitriou und Anderson darauf, die ROM-Phase abzubrechen. Die Berechnungen gingen unmittelbar der Einführungsphase voraus und wurden von demselben ausführenden Mitarbeiter durchgeführt, d.h. sie blieben immer „frisch“.
- Anfragen wurden nicht in monatlichen Meetings priorisiert, sondern je nach Situation, durch Telefonanrufe oder E‑Mails. Die 80 Backlog-Aufgaben wurden je nach Kunden sortiert. Die Kunden wurden gebeten, die Hauptanfragen, die zuerst umgesetzt werden sollten, zu kennzeichnen.
- Die Finanzierung von XIT wurde fixiert.
- Die Kosten der Anfragen wurden nicht mehr berücksichtigt.
- Der PM führte Puffer auf dem Kanban-Board ein. Entwickler nahmen Arbeiten aus zwei Bereichen: genehmigte Aufgaben und ausgeführte Aufgaben. Der Puffer enthielt 6 Anfragen, von denen 5 in den Workflow aufgenommen wurden. Tester wählten Elemente aus dem „zur Prüfung fälligen“ Puffer aus. Einige Aufgaben, die keine Codeänderungen benötigten, gelangten dorthin, nachdem sie die Entwickler umgangen hatten. Durch die Zerlegung der Anfragen in Ein-Aufgaben-Prozesse konnte der PM die Situation besser überwachen und Transparenz für die Kunden gewährleisten. Die Einführung von Puffern reduzierte die Lead Time. Angesichts eines solchen vorhersehbaren Systems konnten die Kunden besser bestimmen, wessen Anfrage als nächste in den Puffer aufgenommen werden würde.
- Entscheidungen wurden sofort zu zu großen und kostspieligen Anfragen getroffen. Wenn ein Entwickler seine Bereitschaft zur Ausführung einer Aufgabe innerhalb von 15 Tagen bestätigte, oder wenn Änderungen sinnvoll waren, wurde eine solche Anfrage unabhängig von ihrem Volumen und Kosten in Angriff genommen.
- Nach der Überwachung des Workflows in der Abteilung kam der PM zu dem Schluss, dass die Personalstruktur zugunsten von Entwicklern, die mit mehr Arbeitslast umgehen können, umgestaltet werden musste. Die Umgestaltung wurde im Verhältnis 2:1 durchgeführt: XIT bestand dann aus 4 Entwicklern und 2 Testern.
Nach der Zusammenfassung von 2005 wuchs die produktive Kapazität der Abteilung um 155%. Um die Leistung von XIT weiter zu verbessern, wurden zwei weitere Spezialisten einbezogen: ein Entwickler und ein Tester. Die Anzahl der Backlog-Anfragen sank auf 10, und ein Entwickler bearbeitete konsequent 11 Anfragen pro Quartal. 56 Anfragen pro Quartal wurden abgeschlossen im Vergleich zu zuvor 11. Die Anfragekosten sanken von 7500 $ auf 2900 $.
Bei der Verwendung durch Corbis
Nachdem er bei Microsoft erfolgreich war, wandte sich Anderson 2006 einem neuen komplexen Problem zu.
Zu dieser Zeit arbeitete er bei Corbis — einem weiteren Unternehmen von Bill Gates, der MS noch nicht verlassen hatte. Eine der Aktivitäten von Corbis war die Fotolizenzierung. Zu dieser Zeit war es das zweitgrößte Fotoarchiv der Welt mit einem Bestand von etwa 3.500 Bildern.
Andersons Ziel war es, die Hauptveröffentlichungen des Unternehmens zu beschleunigen. Der Zeitraum zwischen den Veröffentlichungen betrug drei Monate und konnte sogar noch länger werden. Allein die Diskussion des Veröffentlichungsplans erforderte zwei Wochen Managementarbeit. Es war notwendig, die Ausgabe sekundärer Veröffentlichungen oder Aktualisierungen alle zwei Wochen abzustimmen. Gleichzeitig mussten die Hauptressourcen auf die Durchführung des Hauptprojekts konzentriert werden.
Das Corbis-Büro erhielt ein Kanban-Board, das zum Schauplatz für Andersons tägliche Gespräche mit dem Personal wurde. Das Ziel des PM war es, die visuelle Überwachung der Prozesse zu verbessern, die Selbstverwaltung zu fördern und die persönliche Verantwortung der Mitarbeiter zu stärken.
Das Kanban-System war auch darauf ausgerichtet, die Managementüberwachung zu lockern und die
produktive Kapazität zu steigern.
Zusätzlich zu mehrfarbigen Karten und Diagrammen erschien auf dem Board ein „Müllcontainer“, um oversized Aufgaben zu sammeln.
Foto aus der offiziellen Präsentation
Ein Kanban-System für Sustaining Engineering on Software Systems von David J Anderson
Das Kanban-System klärte die Punkte, an denen die Workflows nicht mehr reibungslos verliefen und wo Verzögerungen auftraten, die einen sogenannten Flaschenhals verursachten. Schnelle Teamdiskussionen erleichterten die Entdeckung aktueller Probleme. Zum Beispiel dauerte der Testprozess 3 Tage, was sich negativ auf die Veröffentlichungsfristen auswirkte. Drei Spezialisten vereinten sich, um den Weg zu finden und diese Zeit auf 24 Stunden zu reduzieren.
Die Limits für Kanban-Karten wurden empirisch zweimal festgelegt. In der Spalte „bereits für die Entwicklung bereit“ wurden die Limits nicht erhöht. Eine neue Spalte – „bereit für Tests“ erschien ebenfalls. Viele downstream-Anfragen wurden falsch artikuliert, was zu Zeitüberschreitungen führte. Daher untersuchte der PM den upstream-Workflow und fand dort Fehler. Die Bearbeitung von Anfragen konnte 100 Tage dauern, dennoch wurden die Veröffentlichungen regelmäßig – alle zwei Wochen, wie geplant. Entscheidungen über den Inhalt der Veröffentlichungen wurden 5 Tage vor der Veröffentlichung getroffen. Wie in Microsofts XIT-Abteilung wurde die Praxis der Berechnungen zugunsten der Produktivität verschoben.
Aufgaben wurden basierend auf den „Kosten von Verzögerungen“ oder der Bereitschaft der Ressourcen priorisiert. Nicht nur ermöglichte das Kanban-System Anderson, das Ziel zu erreichen, sondern es verbesserte auch das Klima im Personal. Aufgrund gemeinsamer Diskussionen und der Sichtbarkeit der Prozesse wurden die Teammitglieder zutiefst vertraut miteinander. Das Personal hielt auch an Kaizen fest, der Praxis der kontinuierlichen Verbesserung.
Anwendungen und Programme für Kanban
Trello
Es ist ein beliebtes Kanban-System für das Aufgabenmanagement. Es unterscheidet sich durch visuelle Attraktivität und ein benutzerfreundliches Interface. Nutzer heben die Flexibilität hervor.
Kanbantool
Es stellt ein kostenloses Board für zwei Nutzer dar. Es bietet auch API- und Touch-Interface-Unterstützung.
Lean Kit Kanban
Es ist ein kostenloses Board für fünf Nutzer, das eine gute Realisierung der gemeinsamen Arbeit bietet. Es bietet auch API-Unterstützung, ermöglicht Import/Export und liefert gute Statistiken.
Kanbanize
Es ist ein völlig kostenloser Service mit angemessener Funktionalität. Seine Betreiber garantieren eine Produktivitätssteigerung von 300%, wenn ihre Anwendung verwendet wird.
Worksection
Es ist eine ukrainische SaaS-Anwendung für schnelles Projekt-Tracking und Management. Neben der finanziellen Buchhaltung, Fristen und Gantt-Diagramm umfasst ihre Funktionalität derzeit ein einstellbares Kanban-Board.
Urteil
Kanban ist die Methode, die hilft, erfolgreich zu sein, ohne dass es notwendig ist, ausschließlich agile Methoden anzuwenden.
Signifikante Änderungen werden durch die Beseitigung von Zeitverlusten, durch das Management von Engpässen mit verringerter Variabilität erreicht.
Allerdings erfordern effektive Änderungen Zeit. Sie sind schrittweise, und der Widerstand des Teams gegen Neuerungen ist minimal. Das Kanban-System motiviert die Teams zur Verbesserung, ohne ihre
Ingenieurmethoden zu verändern.