Einführung einer neuen Task-Verwaltung basierend auf dem Kanban-Prinzip

18. Juli 2013Andreas Bachmann

Immer mehr Unternehmen stützen sich bei der Verbesserung ihrer Prozesse auf Kanban. Ziel von Kanban ist es u. a., durch Visualisierung aller Tasks auf einem sogenannten „Kanban-Board“ über die gesamte Wertschöpfungskette hinweg Prozessabläufe zu verbessern und Durchlaufzeiten zu verkürzen.

Was verbirgt sich eigentlich genau hinter dem Begriff und auf welchen Prinzipien basiert die Kanban- Methode? Unser Gast-Autor Andreas Bachmann vom Hosting Spezialisten ADACOR hat die wichtigsten Fakten für Sie zusammengestellt.

Geprägt wurde der Begriff „Kanban“ 1947 in der japanischen Automobilindustrie, und zwar von Taiichi Ohno in der japanischen Toyota Motor Corporation. Kanban bedeutet „Signalkarte“. Diese Signalkarten sollten helfen, die Produktion – im Sinne einer Lean Production – so zu steuern, dass jeweils nur so viele Zwischenprodukte hergestellt werden, wie die nachfolgende Station braucht. Intention war, hierdurch Lagerbestände und auch die Kapitalbindung zu reduzieren. Gleichzeitig sollte dies mit einer verbesserten Flexibilität bezüglich der geänderten Bedarfsmengen einhergehen. All dies sollte außerdem ohne die Verschlechterung von Lieferbereitschaft und Ausschussquoten erreicht werden sowie ohne zusätzliche Aufwände, wie z. B. vermehrte Nachtarbeit oder zusätzliche Transporte.

Die Kanban-Prinzipien in der IT

Inzwischen hat Kanban auch Einzug in die IT, vor allem in die agile Softwareentwicklung gehalten. Es steht hier für ein Vorgehen, das sich auf wesentliche Prinzipien aus der Lean Production, der Engpasstheorie und der flussbasierten Produktentwicklung stützt. Die Ziele der Kanban-Mathode im Rahmen der Softwareentwicklung sind die Verkürzung von Durchlaufzeiten und hierdurch eine schnellere Auslieferung der jeweiligen Produktbausteine. Um dies zu erreichen, setzt Kanban auf vier Prinzipien:

VISUALISIERUNG

Will ein Unternehmen Kanban einführen, dann besteht der erste wichtige Schritt darin, die bestehende Wertschöpfungskette zu visualisieren. Wesentlich ist hierbei, den aktuellen Ist-Zustand zu skizzieren, und nicht die Wertschöpfungskette wie sie ggf. aussehen könnte. In der Softwareentwicklung beginnt diese Kette z. B. häufig mit einem sogenannten Backlog. Das ist ein Dokument, in dem alle bekannten Anforderungen gesammelt werden. Von hier aus gehen die Anforderungen eine nach der anderen in die Entwicklung. Ihr nachgelagert folgt dann die Testphase. Vorausgesetzt, es werden keine Qualitätsmängel gefunden, werden dann die Anforderungen ausgeliefert. Ein großes Whiteboard, das allen Mitarbeitern frei zugänglich ist, hat sich bereits in vielen Unternehmen für die Visualisierung als praktikable Lösung erwiesen. Auf ihm ist jeder Prozessschritt in einer eigenen Spalte dargestellt. Die einzelnen Anforderungen werden auf Karten notiert und durchlaufen als Tickets von links nach rechts die Wertschöpfungskette auf dem Kanban-Board.

PULL STATT PUSH

Unverzichtbar für den erfolgreichen Einsatz von Kanban ist, dass ein echtes Pull-System implementiert wird. D. h., Arbeit wird niemals an nachgelagerte Prozessschritte übergeben (Push-Prinzip). Das Pull-Prinzip arbeitet genau anders herum. Die einzelnen Prozessschritte holen sich neue Arbeit beim vorgelagerten Prozessschritt erst dann ab, wenn die andere Arbeit erledigt wurde. Pull-Systeme verhindern so effektiv die Überlastung von Mitarbeitern und stellen ein nachhaltiges Arbeitstempo sicher. Sie zeigen schnell, an welchen Schnittstellen der Workflow hakt und bieten so gute Ansatzpunkte zur Verbesserung, insbesondere wenn gleichzeitig die Menge an paralleler Arbeit begrenzt wird.

BEGRENZUNG PARALLELER ARBEIT

Hier geht es für jeden Prozessschritt darum, die Anzahl der Aufgaben, an denen gleichzeitig gearbeitet wird, zu begrenzen. Beispielsweise kann sich das Team darauf verständigen, dass sich niemals mehr als vier Tickets gleichzeitig in der Entwicklung befinden dürfen, höchstens zwei beim Testen und maximal ein Ticket in der Auslieferung. Diese Begrenzung hat zur Folge, dass die einzelnen Tickets deutlich zügiger abgearbeitet werden. Die Durchlaufzeit – die definiert ist als Menge an paralleler Arbeit dividiert durch den Durchsatz – verringert sich. Möchte ein Unternehmen also die Durchlaufzeiten verkürzen, dann gibt es zwei Möglichkeiten. Das Unternehmen kann versuchen, den Durchsatz zu erhöhen oder es begrenzt die Menge an paralleler Arbeit. Letzteres entspricht dem Ansatz von Kanban.

KAIZEN

Das letzte wichtige Prinzip von Kanban wird unter dem Begriff „Kaizen“ zusammengefasst. Der Begriff stammt ebenfalls aus dem Japanischen und bedeutet „Veränderung zum Besseren.“ Es geht also darum, dass ein kontinuierlicher Verbesserungsprozess etabliert wird. Dieser beinhaltet regelmäßig stattfindende Abstimmungsmeetings, in denen die Teammitglieder gemeinsam an Lösungen zur Prozessverbesserung arbeiten. Dies bedeutet, dass ein Fehler immer auch als eine Chance zum Lernen begriffen wird und es nicht nur um eine kurzfristige Korrektur geht. Vielmehr muss die Ursache behoben werden und hierfür ist jeder Mitarbeiter angehalten, seine Ideen und Verbesserungsvorschläge einzubringen.

Von Engpässen und Optimierungspotenzial

Ein besonderes Augenmerk legt Kanban auf sogenannte Engpässe. Diese treten durch das Pull-System und der gleichzeitigen Limitierung paralleler Arbeit am Kanban-Board offen zu Tage, und zwar, indem sich Tickets bei einem bestimmten Prozessschritt der beschriebenen Wertschöpfungskette stauen. An diesen Stellen ist der Durchsatz geringer, was dazu führt, dass für die nachgelagerten Prozessschritte schon bald keine Aufgaben mehr da sind, die sie übernehmen können. Auch die vorgelagerten Schritte werden in ihrer Arbeit blockiert, denn ihre fertige Arbeit bleibt liegen und wird vom Engpass nicht gezogen. Dadurch, dass hierdurch also sowohl dem Engpass vor- und nachgelagerte Prozessschritte lahm gelegt werden, erhält der Engpass eine große Aufmerksamkeit. Was aber tun, wenn einzelne Teammitglieder immer wieder temporär keine Arbeit haben? Völlig falsch wäre es, die Mitarbeiter anderweitig zu beschäftigen und in andere Projekte einzubinden. Eine Möglichkeit wäre in einem solchen Fall, einfach das Limit für den Engpass zu erhöhen. Allerdings ist dies oft nur kurzfristig sinnvoll und das Problem ist hiermit nicht behoben, da der Durchsatz an dieser Stelle im Schnitt voraussichtlich immer langsamer sein wird als anderswo. Das Problem wäre nur verschoben und früher oder später würden sich die Tickets wieder an derselben Stelle stauen. Alternativ wäre auch denkbar, am Engpass mehr Mitarbeiter zu beschäftigen. Allerdings hat das Recruiting neuer Mitarbeiter erfahrungsgemäß häufig zunächst nicht den gewünschten Effekt der Entlastung. Die Lösung liegt eher im Prinzip der Umverteilung: Könnte nicht z. B. ein Entwickler das Tester-Team unterstützen? Kanban geht es generell um die Optimierung und so könnten Entwickler und Tester gemeinsam überlegen, worin die Ursache für den Engpass liegt. Geht es wirklich rein um personelle Unterbesetzung oder kam der Engpass vielleicht zustande, weil einige der Tester auch noch mit anderen Aufgaben betraut waren und es ihnen schlicht an Zeit fehlte? Gibt es technische Probleme oder andere Rahmenbedingungen, die zu dem Engpass geführt haben? Der nicht ausgelastete Mitarbeiter könnte seine freie Zeit nutzen, um über diese Fragen, Optimierungsansätze für den Engpass sowie generelle Prozessverbesserungen nachzudenken und konkrete Maßnahmen hierzu erarbeiten. Leerlaufzeiten sollte das Team in diesem Kontext also nicht als „Bug“ begreifen, sondern als Optimierungspotenzial und Chance zur Verbesserung.

Das Kanban-Ideal: Der Single Piece Flow

Der Idealfall sieht in Kanban so aus: Eine einzige Aufgabe fließt gleichmäßig von links nach rechts durch das gesamte Kanban-System. Kennzeichnend für diesen „Single Piece Flow“ ist, dass die Aufgabe bzw. das Ticket ohne jede Wartezeit oder Verzögerung von einem zum nächsten Prozessschritt übergeben wird. Ob sich dies in der Softwareentwicklung jedoch so realisieren lässt, erscheint angesichts der Tatsache fraglich, dass Software Features in ihren Entwicklungs- und Bearbeitungsaufwänden erheblich variieren können und auch Menschen ungleichmäßig schnell arbeiten. Aber das Bestreben sollte dahin gehen, diesem Idealablauf sukzessive so nahe wie möglich zu kommen. Und zwar durch die Verkürzung der Wartezeiten und die Reduzierung der Limits.

Qualität und Geschwindigkeit – in Kanban kein Widerspruch

Was auf den ersten Blick für viele unvereinbar scheint – Qualität und Geschwindigkeit – ist bei genauerer Betrachtung kein Widerspruch. Denn wer wirklich schnell sein will, der erreicht dies nur durch das Erbringen von qualitativ hochwertiger Leistung. Nichts ist zeitraubender, als eine Aufgabe immer wieder anfassen zu müssen, weil z. B. im Rahmen der nachgelagerten Testphase Fehler gefunden wurden. Nicht nur, dass sich die Softwareentwickler abermals in die Zusammenhänge hineindenken müssen, sie müssen hierfür auch ihre aktuelle Aufgabe zurückstellen und so insgesamt mehr Aufgaben verwalten und tracken. Auch die Testphase muss anschließend ein weiteres Mal durchlaufen werden und kostet wertvolle Zeit. Sucht das Team nun nach Gründen für die Verzögerung, wird es mit großer Wahrscheinlichkeit schnell auf Qualitätsmängel in der Aufgabenbearbeitung stoßen. Werden diese behoben, verringern sich auch wieder die Durchlaufzeiten. Und kurze Durchlaufzeiten stellen gegenüber anderen Anbietern einen echten Wettbewerbsvorteil dar. Das qualitativ hochwertige Produkt ist schneller am Markt und die Kundenzufriedenheit ist höher. Was will man als Unternehmen mehr?

Scrum oder Kanban: Revolution versus Evolution

Im Zusammenhang mit agiler Softwareentwicklung werden die zwei Begriffe „Scrum“ und „Kanban“ oft in einem Atemzug miteinander genannt. Die beiden Vorgehensmodelle unterscheiden sich jedoch grundlegend.

Scrum ist eine organisierte Softwareentwicklungsmethode, die auf Rollen (Product Owner, Entwicklungsteam, ScrumMaster), Zeremonien (Sprint Planning, Sprint Review, Daily Scrum) und Artefakten (Product Backlog, Sprint Backlog, Burndown Chart) basiert, von denen angenommen wird, dass sie benötigt werden, um dem Ideal des höchstproduktiven Teams möglichst nahe zu kommen. Scrum baut auf hochqualifizierte, interdisziplinär besetzte Entwicklungsteams, die zwar eine klare Zielvorgabe bekommen, für die Umsetzung jedoch allein zuständig sind. Dadurch bekommen die Entwicklungsteams den nötigen Freiraum, um ihr Wissens- und Kreativitätspotenzial in Eigenregie zur Entfaltung zu bringen. Die Einführung von Scrum ist mit grundlegenden Prozessneuerungen verbunden und kommt daher einer Revolution des bisher Bestehenden gleich.

Bei Kanban hingegen handelt sich um eine evolutionär eingeführte Veränderungs- und Verbesserungsmethodik, die auf einem bereits bestehenden Prozess aufsetzt. Die Einführung geht mit nur kleinen Veränderungen einher. Den Ausgangspunkt für die Prozessoptimierung bildet die Visualisierung der eigenen individuellen Wertschöpfungskette auf dem Kanban-Board. Es ist nicht notwendig, neue Rollen, Tätigkeitsbereiche oder Technologien zu implementieren. Denn Kanban zielt basierend auf der gegebenen IST-Situation auf die schrittweise, kontinuierliche Verbesserung der existierenden Prozesse von innen heraus ab und motiviert alle Teammitglieder, hierzu einen Beitrag zu leisten.

Kanban bei ADACOR

Zwar wird Kanban heute hauptsächlich in der Softwareentwicklung eingesetzt, immer mehr Unternehmen stellen jedoch fest, dass auch andere Unternehmensbereiche von den vier systematisch ineinander greifenden Kanban-Prinzipien profitieren können. Auch ADACOR hat dies erkannt und plant die Einführung einer neuen Taskverwaltung basierend auf dem Kanban-Prinzip sowohl für das Entwickler- als auch das Betriebs- und Infrastrukturteam. Denn für alle drei Teams ist es wichtig, zu jedem Zeitpunkt zu wissen, in welchem Prozessschritt sich eine Aufgabe befindet. Kanban schafft die benötigte Transparenz, indem die einzelnen Prozessschritte der firmeneigenen Wertschöpfungskette an einem Kanban-Board visualisiert werden und zu jeder Zeit ersichtlich ist, an welcher Stelle im Prozess sich welche Aufgaben in welchem Bearbeitungszustand befinden. Da ADACOR die Taskverwaltung in Eigenregie entwickelt und in das bestehende Intranetsystem (XPMS)  integriert, werden zusätzlich einige genau auf das Unternehmen zugeschnittene Funktionen implementiert. So soll das neue System auch dabei helfen, Workflows zu standardisieren, indem das Kanban-Board mit verschiedenen Kartentypen, projektbasierten Regeln und Checklisten ergänzt wird.

Haben Sie bereits Erfahrungen gesammelt oder haben Sie Fragen zum Kanban-Prinzip? Ich freue mich über Ihre Kommentare.

Andreas Bachmann Andreas Bachmann ist Geschäftsführer (CIO) der ADACOR Hosting GmbH.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentar hinzufügen:

Ihr Kommentar: