Das Kanban-System begann seine Reise in den 1950er Jahren an den Produktionslinien von Toyota, danach wurde es in Büros übertragen und entwickelte sich zu einem wichtigen Werkzeug für Projektmanager.
Die grenzenlose Flexibilität der Praxis und ihre Fähigkeit, Personal selbst zu organisieren, ermöglichten Effizienz, wo andere Ansätze nicht funktionierten. Dies ist der Fall, wenn die Visitenkarte des Systems die Karte selbst wurde — sie hat sich als eine interne Währung in Organisationen etabliert, die Kanban implementiert haben.
Ursprung
Wie das Konzept der Lean-Produktion wurde das Kanban-System von Toyota-Managern entwickelt. Der Autor des Systems, der japanische Ingenieur Taiichi Ohno, ließ sich von den Betriebsprinzipien amerikanischer Supermärkte inspirieren, in denen die Kunden die Produkte, die sie benötigten, selbst auswählten. Die Rolle des „Supermarkts“ bei Toyota übernahm das Lager.Dort wurden Signalkarten — was „Kanban“ auf Japanisch wörtlich bedeutet — unter den Arbeitern ausgetauscht, die den Produktionsprozess manuell regulierten.Karten wurden an Kisten mit Teilen befestigt. Solche Etiketten gaben Informationen über die Teilenummer und die Menge an, welche Abteilung sie sendete und wo sie ankommen sollten.
Der Arbeiter, der direkt an der Montage von Maschinen beteiligt war („downstream“), nahm Teile aus der Kiste, an der die „Kanban“-Karte für Nachschub befestigt war. Die Karte wurde entfernt und zusammen mit der leeren Kiste an den Transporteur zum Lager weitergegeben. Dort bereitete ein anderer Arbeiter eine neue Kiste mit Ersatzteilen vor, an die die Produktions-“Kanban” — ein Etikett mit Informationen über die produzierten Ersatzteile — befestigt war.
Das Produktions-“Kanban” wurde durch ein “Kanban” ersetzt, das Nachschub anforderte und an die Produktionslinie für Ersatzteile („upstream“) gesandt. So wurde genau die Menge an Teilen produziert, die auf der Karte angegeben war. Die Kiste mit neuen Ersatzteilen wurde von Transporteuren auf das Montageband gelegt.
Prinzipien von Kanban
Toyota-Manager formulierten 6 systemformende Regeln:
- Arbeiter von „downstream“ entnehmen genau so viele Teile aus dem Bestand, wie auf dem Kanban angegeben
- Arbeiter von „upstream“ liefern ebenfalls Teile strikt gemäß den Karten
- Nichts wird ohne ein Kanban produziert oder bewegt
- Das Kanban muss immer an den Teilen befestigt sein
- Defekte Teile werden im System nicht verwendet
- Die Reduzierung der Anzahl der Kanban-Karten macht die Verwaltung sensibler für Veränderungen. Aber ohne extreme Notwendigkeit ist es nicht ratsam, die festgelegte Anzahl an Karten zu ändern.
Kanban ist ein „Pull“-System. Es schafft ein Gleichgewicht zwischen einem ständigen Fluss, der Wartekosten beseitigt, und einer minimalen Menge an laufenden Arbeiten (WIP), die die Risiken von Überproduktion reduziert. WIP wird mit Hilfe von Karten reguliert: Ihre Anzahl ist festgelegt, und die Anweisungen in ihnen leiten die „downstream“ Arbeiter.
Die WIP-Grenze besteht im Verhältnis zur Anzahl der Kanban-Karten, die anhand von Verkaufszahlen und statistischer Variabilität in aktuellen Prozessen berechnet wird. Die maximale Anzahl an Etiketten — die „Energie“ im System — sichert das obere WIP-Niveau zu jedem Zeitpunkt. WIP wird auch durch das Pull-Prinzip begrenzt: Die Produktionsgeschwindigkeit des Upstream hängt von der Arbeitsgeschwindigkeit des Downstream ab.
Die Grafik zeigt, dass eines der grundlegenden Elemente des Systems die Kaizen-Kultur ist. Autonome Prozesse und standardisierte Variabilität befreien das Management von ständiger Kontrolle und erlauben es ihm, sich auf die Leistungsverbesserung der Mitarbeiter zu konzentrieren.
Anwendung von Kanban in der IT
Das Kanban-System, das weiterhin Vorteile an Produktionslinien bietet, hat den Softwarebereich erobert.
Nur Karten, die Informationen über Fristen, Beschreibungen oder Prozessnummern und den Namen des Ausführenden enthalten, werden nun nicht mehr an Kisten mit Ersatzteilen, sondern an Tafeln mit geteilten Spalten angeheftet:
- Backlog — Aufgaben, die erledigt werden müssen
- Aktuell entwickelte Aufgaben
- Aufgaben, die abgeschlossen, aber noch nicht an Tester übergeben wurden
- Aufgaben bereit zur Übergabe an die Testabteilung
- Aufgaben, die sich in der Überprüfung durch den Projektmanager (PM) befinden
- Abgeschlossene Aufgaben
Die Nummer wird normalerweise über den Spalten geschrieben — das Limit, welches die maximale Anzahl der Prozesse darin angibt. Das Backlog-Limit wird in Abhängigkeit von der Vorlaufzeit berechnet. Wenn es 5 Arbeitsprozesse im System gibt und die durchschnittliche Bearbeitungszeit für jeden 1 Tag beträgt, kann das Backlog auf 5 begrenzt werden.
Die Struktur oben ist nicht streng — abhängig von den spezifischen Anforderungen des Projekts können improvisierte Spalten hinzugefügt werden. Ein Kanban-System hat häufig die Notwendigkeit, Kriterien für die Bereitschaft von Aufgaben vor der Ausführung zu definieren. In diesem Fall erscheinen zwei Spalten, die im Englischen als bestimmen (Parameter klarstellen) und ausführen (Arbeit annehmen) bezeichnet werden.
- Eine weitere Spalte mit einer Prioritätswarteschlange kann hinzugefügt werden. Wenn ein Ausführender frei wird, muss er diese Spalte zuerst von Aufgaben befreien, bevor er andere übernimmt.
- Aufgaben, die nicht abgeschlossen wurden, werden entweder ins Backlog zurückgegeben oder aus dem Schema gestrichen.
- Kanban fördert kein Multitasking und beschränkt damit die Anzahl der Prozesse für jeden Ausführenden.
- Abgeschlossene Arbeit ist besser als mehrere gestartete Aufgaben.
- Ein zweiter Job kann übernommen werden, wenn der erste blockiert ist.
- Die Zeit für die Ausführung von Aufgaben muss ausgeglichen sein. Zu kurze Fristen können die Qualität beeinträchtigen. Ein übermäßig ausgedehntes Limit verbraucht die Ressourcen des Teams und erhöht die Prozesskosten.
Warum wird das Kanban-Board überall anstelle von beispielsweise Tablets oder großen Monitoren verwendet? Befürworter des Systems beantworten diese Frage, indem sie sagen, dass ein reguläres Board zwei Vorteile hat: Es ist einfach und bietet visuelle Kontrolle. Es ist einfach, Änderungen daran vorzunehmen, und es fördert taktile und soziale Interaktionen unter Teammitgliedern.
Vorteile und Nachteile von Kanban
Kanban hat folgende Vorteile:
- Flexibilität in der Planung. Das Team konzentriert sich ausschließlich auf die aktuelle Arbeit, wobei die Aufgabenpriorität vom Manager festgelegt wird.
- Hohe Teamengagement im Entwicklungsprozess. Dank regelmäßiger Meetings, Prozess-Transparenz und Möglichkeiten zur Selbstorganisation kommen die Mitarbeiter zusammen und zeigen aufrichtiges Interesse.
- Verkürzte Zyklusdauer. Wenn die erforderlichen Fähigkeiten mehreren Personen zur Verfügung stehen, verringert sich die Dauer; besitzt nur eine Person sie, entsteht ein Engpass. Daher sollten die Mitarbeiter ihr Wissen teilen, um die Zyklusdauer zu optimieren. Dies ermöglicht es dem gesamten Team, an ins Stocken geratenen Aufgaben zu arbeiten und einen reibungslosen Fluss wiederherzustellen.
- Weniger Engpässe. WIP-Grenzen ermöglichen eine schnelle Identifikation von Engpässen und Problembereichen, die durch mangelnde Konzentration, Arbeitskraft oder Fähigkeiten entstehen.
- Sichtbarkeit. Wenn alle Ausführenden Zugang zu Daten haben, wird es einfacher, Engpässe zu erkennen. Kanban-Teams nutzen zusätzlich zu den Karten meistens zwei gängige Berichte: Kontrollcharts und kumulative Flüsse.
In der Praxis zeigt das System großartige Ergebnisse in nicht zentralen Produktionsbereichen:
- Software-Supportgruppen oder Helpdesks.
- Kanban funktioniert gut beim Management von Startups, die keinen klaren Plan haben, aber in denen eine aktive Entwicklung stattfindet.
Kanban hat auch Nachteile:
- Das System funktioniert schlecht mit Teams von mehr als 5 Personen
- Es ist nicht für langfristige Planung gedacht.
Unterschiede zu Scrum
Scrum, wie agiles Kanban, ist eine flexible Methodologie, die auch häufig im IT-Bereich angewendet wird. Die Unterschiede zwischen ihnen sind auf den ersten Blick nicht offensichtlich. Es gibt viele Ähnlichkeiten, beispielsweise das Vorhandensein eines Backlogs in beiden Ansätzen.
Scrum | Kanban | |
Tempo | Wiederholte Sprints fester Dauer | Kontinuierlicher Prozess |
Ausgabe der Version | Am Ende jedes Sprints nach Genehmigung durch den Projektmanager (Product Owner) | Fluss geht ununterbrochen weiter oder nach Ermessen des Teams |
Rollen | Product Owner, Scrum Master, Entwicklungsteam | Team unter Leitung des PM; in einigen Fällen werden agile Kanban-Coaches einbezogen |
Wichtige Kennzahlen | Teamgeschwindigkeit | Durchlaufzeit |
Im Hinblick auf die Änderungsakzeptanz | Änderungen sind während eines Sprints unerwünscht, da sie zu Fehlkalkulationen der Aufgaben führen können | Änderungen können jederzeit auftreten |
Beispiele für die Anwendung in der IT
Direkt von Microsoft: Das Debüt von Kanban in der Softwareentwicklung
Die Anwendung von Kanban-Prinzipien in der Informationstechnologie begann vor etwas mehr als 10 Jahren. David Anderson, einer der Hauptverfechter von Kanban für Softwareentwickler, beriet Microsoft im Jahr 2005. Sie waren mit der Leistung ihrer Abteilung — XIT Sustained Engineering, die Fehler in internen Anwendungen behob — unzufrieden. Zu Beginn des Berichtsjahres war diese Abteilung die schlechteste in ihrer Division. Das Backlog überschritt die akzeptable Größe um das Fünffache, und die Vorlaufzeit zur Bearbeitung einer Anfrage betrug typischerweise fünf Monate.
Der neue PM, mit Andersons Beratung, steigerte die Produktivität der angeschlagenen Abteilung innerhalb von neun Monaten um 155 %. Die Vorlaufzeit betrug nun fünf Wochen, das Backlog hatte wieder eine normale Größe, und die pünktliche Aufgabenerledigung stabilisierte sich auf 90 %. All diese Ergebnisse wurden mit minimaler Einarbeitung neuer Mitarbeiter erzielt; das Personal behielt die Art und Weise bei, wie sie Fehler beseitigten — nur die Ansätze zur Organisation der Arbeit haben sich geändert.
Eine interessante Tatsache: Programmmanager Dragos Dumitriu, der sich vorgenommen hatte, die Situation in XIT zu verbessern, war von Andersons Buch geradezu fasziniert. Zu seiner Überraschung traf er den Ideologen des Programm-Kanban genau in dem Microsoft, wo er gerade am Tag zuvor angefangen hatte. Dumitriu bat Anderson um Hilfe bei seiner Aufgabe, und letzterer stimmte zu, die Prinzipien seines Buches in die Praxis umzusetzen.Dumitriu traf auf eine Abteilung, die aus drei Entwicklern und drei Testern bestand, in der 80 Anfragen im Backlog ansammelten. Der PM selbst wurde vorübergehend ernannt, da die Anforderungen an den Job Fachwissen in ASP-Technologie, SQL-Server-Administration und Kenntnis des MS Project Server beinhalteten. Das Management stellte sich einen „Techie“ vor, der codieren, Berichte vorbereiten und die Rückstandslast voraussagen konnte. So glaubte man damals, würde das Problem der Abteilung offengelegt, wenn eine große Menge an Daten gesammelt würde. Dumitriu war kein solcher „Techie“.
Als er jedoch begann, die XIT-Operationen zusammen mit Anderson zu analysieren, identifizierte er schnell die Schlüsselfaktoren, die die Geschwindigkeit der Abteilung negativ beeinflussten:
- Die Vorhersage der Konsequenzen (ROM) der Erfüllung einer Anfrage dauerte viel Zeit. Sowohl der Entwickler als auch der Tester mussten einen ganzen Arbeitstag damit verbringen, notwendige Berechnungen durchzuführen, den Code zu überprüfen und Dokumentation zu vervollständigen. Im Durchschnitt kam täglich eine Anfrage. Laut den Berechnungen des PM gingen 40 % der Produktivität der Abteilung für ROM auf;
- Höhere Wertanfragen wurden priorisiert. XIT wurde basierend auf dem Auftragswert finanziert. Die Priorisierung der Anfragen wurde monatlich in den Besprechungen der Abteilungsleiter mit Kunden — Managern aus anderen Abteilungen — besprochen. Mit einem wachsenden Rückstand bei der aktuellen Geschwindigkeit, bei der nur 6 – 7 Anfragen monatlich bearbeitet wurden, änderten sich die Prioritäten anderer Anfragen ständig aufgrund der vergehenden Zeit. Viele von ihnen wurden auf ein erhebliches „Später“ verschoben, das nicht einmal dem nächsten Monat entsprach.
- In der ROM-Phase wurden die Hälfte der Anfragen herausgefiltert. Einige waren zu groß und wurden als Projekte umqualifiziert, die an andere Abteilungen weitergegeben werden sollten, andere waren zu teuer und wurden einfach abgelehnt. Einige Anfragen wurden nicht in die Entwicklung aufgenommen, weil ihre Umsetzung zu lange dauern würde. So wurden 40 % der Produktivität der Abteilung für die Analyse von Anfragen aufgewendet, von denen 50 % abgelehnt wurden. Ca. 15 – 20 % der Arbeitsressourcen wurden verschwendet.
- Die Vorarbeiten zu Anfragen konnten sich über Monate hinziehen, bevor die Implementierung begann. Berechnungen in der ROM-Phase gingen in dieser Zeit verloren oder wurden vergessen. Besonders wenn die Implementierung von einem anderen Entwickler gemeistert wurde als demjenigen, der die Analyse begonnen hatte.
Kanban-Lösungen für die angeschlagene Abteilung von Microsoft
Am Ende von 2005 steigerte sich die Produktivität der Abteilung um 155 %. Um die Arbeit von XIT weiter zu verbessern, wurden zwei Mitarbeiter eingestellt: ein Entwickler und ein Tester. Die Anzahl der Anfragen im Backlog sank auf 10, und ein Entwickler bearbeitete konstant 11 Anfragen pro Quartal. Im Durchschnitt wurden 56 Anfragen pro Quartal im Vergleich zu 11 zuvor abgeschlossen. Die Kosten der Anfragen fielen von 7500 $ auf 2900 $.
Anwendung bei Corbis
Nachdem er bei Microsoft Erfolg gehabt hatte, begann Anderson im Jahr 2006, sich einer neuen komplexen Aufgabe zu widmen. Jetzt arbeitete er bei Corbis — einem weiteren Unternehmen von Bill Gates, der MS noch nicht verlassen hatte. Eine der Aktivitäten von Corbis war die Lizenzierung von Fotos. Zu dieser Zeit war es die zweitgrößte Bilddatenbank der Welt mit einer Datenbank von etwa 3,5 Tausend Bildern.
Andersons Aufgabe bestand darin, die Hauptveröffentlichungen des Unternehmens zu beschleunigen. Das Intervall zwischen ihren Veröffentlichungen betrug drei Monate und konnte noch länger werden. Schon die Diskussion des Veröffentlichungsplans nahm dem Management zwei Wochen in Anspruch. Es war notwendig, die Veröffentlichung von sekundären Veröffentlichungen oder Updates alle zwei Wochen zu etablieren. Gleichzeitig mussten die wichtigsten Ressourcen auf das Hauptprojekt gerichtet werden.
Ein Kanban-Board erschien im Büro von Corbis, wo Anderson täglich mit dem Team sprach. Ziel des PM war es, die visuelle Kontrolle über die Prozesse zu verbessern, Selbstorganisation zu fördern und eine größere persönliche Verantwortung unter den Ausführenden zu erzielen. Das Kanban-System sollte auch dazu dienen, die Kontrolle des Managers zu verringern und die Produktivität zu steigern.
Neben bunten Karten und Grafiken erschien auf der Tafel ein „Müllcontainer“ — in den Aufgaben, die zu groß waren, geschickt wurden.
Foto aus der offiziellen Präsentation
Ein Kanban-System für Sustaining Engineering von Software-Systemen von David J Anderson
Das Kanban-System klärte, wann der Fluss nicht mehr reibungslos ist und wo Verzögerungen auftreten, das sogenannte Nadelöhr. Schnelle Diskussionen mit dem Team halfen, aktuelle Probleme zu identifizieren. Zum Beispiel benötigte das Testen 3 Tage, was sich negativ auf den Veröffentlichungszeitplan auswirkte. Drei Mitarbeiter kamen zusammen und fanden einen Weg, die Zeit auf einen Tag zu reduzieren.
Ein Nadelöhr ist ein Abschnitt des Schemas oder Algorithmus der Unternehmensabläufe, an dem Ressourcen- oder Menschproduktivitätsbeschränkungen den Durchsatz des Aufgabenflusses drastisch reduzieren. Ein Mangel an Arbeitskräften, schlechtes Internet oder ein Direktor im Urlaub blockiert oder verlangsamt dieAufgabenbearbeitung.
Limits für Kanban-Karten wurden empirisch zweimal festgelegt. In der Spalte „bereit zur Entwicklung“ wurden die Limits erhöht. Eine neue Spalte — „bereit zum Testen“ — erschien ebenfalls. Viele Anfragen für den Downstream waren falsch formuliert, was unnötige Zeitaufwendungen verursachte. Daher untersuchte PM die Abläufe im oberen Fluss und fand Fehler.
Das Verfahren zur Überprüfung von Anfragen konnte 100 Tage in Anspruch nehmen, aber die Veröffentlichungen begannen dennoch alle zwei Wochen wie geplant zu erscheinen. Entscheidungen über den Inhalt der Veröffentlichung wurden 5 Tage vor der Veröffentlichung getroffen. Die Zählpraxis, wie im Fall der XIT-Abteilung bei Microsoft, wurde zugunsten der Produktivität aufgegeben. Die Prioritäten von Aufgaben wurden gemäß „Kosten der Verzögerungen“ oder der Bereitschaft von Ressourcen festgelegt.
Das Kanban-System half nicht nur Anderson, das gesetzte Ziel zu erreichen, sondern verbesserte auch die Moral im Team. Dank kollektiver Diskussionen und der Sichtbarkeit der Prozesse etablierten die Mitarbeiter Vertrauen zueinander. Das Personal nahm auch Kaizen an, das heißt, die Praxis der kontinuierlichen Verbesserung.
Programme und Apps für KANBAN
Trello
Beliebtes Kanban -System für das Aufgabenmanagement. Es zeichnet sich durch seine visuelle Attraktivität und benutzerfreundliche Schnittstelle aus. Benutzer heben seine enorme Flexibilität hervor.
Kanbantool
Kostenloses Board für zwei Benutzer. API-Unterstützung und Touch-Oberflächen.
Lean Kit Kanban
Kostenloses Board für fünf Benutzer mit guten Kollaborationseigenschaften. API-Unterstützung und Import-/Exportmöglichkeiten, umfangreiche Statistiken.
Kanbanize
Völlig kostenloser Service mit anständiger Funktionalität. Seine Eigentümer garantieren eine Steigerung der Produktivität um 300 % bei Nutzung ihres Produkts.
Worksection
Ukrainisches SaaS — Anwendung für schnelles Tracking und Management von Projekten. Derzeit gibt es neben der Buchführung für Finanzen und Fristen auch ein Gantt-Diagramm. In den kommenden Monaten werden die Entwickler ein Kanban-Board mit Anpassungsoptionen hinzufügen, wodurch der Service noch besser für Kanban geeignet wird.
Fazit
Kanban ist eine Praxis, die zum Erfolg verhilft, während die Verwendung nur agiler Methoden nicht zwingend erforderlich ist. Bedeutende Veränderungen werden durch die Beseitigung von verschwendeter Zeit, das Management von Engpässen und die Verringerung von Variabilität erzielt.
Erfolgreiche Veränderungen benötigen jedoch Zeit. Sie erfolgen schrittweise, während der Widerstand des Teams gegen Innovationen minimal ist. Das Kanban-System motiviert das Personal zur Verbesserung, ohne dass Änderungen in den Ingenieurmethoden erforderlich sind.
Bücher für den Artikel werden bereitgestellt von kniga.biz.ua