Gegen Ende des Jahres 2010 machte sich Eric-Jan Kaak, damals Leiter Controlling und IT beim österreichischen Skihersteller Blizzard, ein paar grundsätzliche Gedanken: Die Fertigungsprozesse des zum italienischen Tecnica-Konzern gehörenden Sportartikelherstellers funktionierten beinahe wie am Schnürchen. Wieso war das in der IT eigentlich anders? An den Systemen konnte es kaum liegen. Die waren seit der jüngsten ERP-Einführung auf dem aktuellen Stand der Technik. Also musste etwas in den Abläufen haken.
Die damals fünfköpfige IT-Truppe - zwei Entwickler, zwei Operations-Spezialisten und ein "Zwitter" - wurde jeden Tag mit 20 bis 40 Requests bombardiert, die sie alle sofort bearbeiten sollten, um ihre internen Kunden zufriedenzustellen. Deshalb ließ sich vieles von dem, was begonnen wurde, nie beenden. Kaaks Fazit: Die Flut der Anforderungen, die da ständig über die IT hereinbrach, war mit den althergebrachten Verfahren kaum zu bewältigen.
Also schaute sich der IT- und Controlling-Spezialist die Fertigungsprozesse einmal genauer an. Am Standort Mittersill hatte Blizzard gerade die Prinzipien der möglichst verschwendungsfreien und aus sich selbst lernenden "Lean Production" umzusetzen begonnen. Diese Prinzipien müssten sich doch auf die Arbeit des IT-Bereichs übertragen lassen, fand der heutige CIO für die Unternehmensgruppe, zu der unter anderem die Marken Nordica und Lowa gehören.
Die Puzzle-Steine fallen zusammen
Ostern 2011 fand Kaak Muße, das kurz zuvor erschienene Standardwerk von David Anderson ("Evolutionäres Change-Management für IT-Organisationen") zu lesen. "Da fügten sich die Puzzle-Steine plötzlich zu einem Bild zusammen", erinnert er sich. Die Lösung war, nicht mehr alles gleichzeitig anzufangen, sondern zu selektieren, zu priorisieren und dann möglichst unterbrechungsfrei Aufgaben sequenziell abzuarbeiten ("One Piece Flow").
Am Anfang des Vorgehensmodells musste also eine strenge Auswahl der zu erledigenden Aufgaben stehen: Hat das einen Wert für das Gesamtunternehmen? Ist das überhaupt ein IT-Job oder doch eher eine Business-Aufgabe? Welche Tasks sollen in welcher Reihenfolge bearbeitet werden? Welche sind so wichtig, dass sie an den anderen vorbeiziehen dürfen?
Das Visitenkarten-Spiel
Bei der Bestandsaufnahme des IT-Teams stellte sich heraus: Um alle offenen Punkte abzuschließen, würde jeder Mitarbeiter etwa einen Monat benötigen. Aber während dieser 30 Tage risse der Strom der Aufgaben ja nicht ab, sondern würde sich weiter anstauen.
Dass die parallele Bearbeitung mehrerer Aufgaben das Problem noch verschlimmerte, belegte Kaak, indem er seine Mitarbeiter eine Simulation durchspielen ließ. Das "Projekt" war die Beschriftung von Visitenkarten. Im ersten Durchgang sollten alle Karten gleichzeitig geschrieben werden, um jedem "Kunden" das Gefühl zu geben, er werde ohne Verzug bedient. Jede Karte bekam immer nur einen weiteren Buchstaben - schön reihum, bis alle Namen vollständig waren. Im zweiten Durchgang ließ der CIO die Karten nacheinander vollständig beschriften. Das Ergebnis ist leicht prognostizierbar: Wer häufig den Arbeitskontext wechselt, braucht immer wieder "geistige Rüstzeiten", während derer er nicht produktiv ist. Wer aber eine Aufgabe abschließt, bevor er eine andere beginnt, spart nicht nur Nerven, sondern auch Zeit - zwischen 20 und 50 Prozent, wie Kaak festgestellt hat.
Pull-Prinzip statt Zuschütten
Anfang Mai 2011 wollte es Kaak mit Kanban "einfach mal versuchen". Schließlich waren dazu keine Upfront-Investitionen nötig - abgesehen von einem Board, wie es in den meisten Büros herumhängt, ein paar Karteikärtchen und Buntstiften. Zunächst ließ der CIO seine Mitarbeiter die To-do-Listen gründlich inspizieren: Jede Aufgabe, hinter der sich nach zwei Monaten immer noch kein Haken befand, war offenbar nicht wichtig für das Unternehmen. Sie wurde deshalb gestrichen.
Zum Kanban-Prinzip gehört auch, dass sich die Mitarbeiter die Aufgaben eigenständig und sukzessive auf den Schreibtisch holen (Pull-Prinzip), statt dass sie mit Arbeit zugeschüttet werden (siehe "Software-Kanban"). Insgesamt dürfen nicht mehr Aufgaben auf der To-do-Liste stehen, als das Team auch gleichzeitig bewältigen kann. Nur so wird die Arbeit gleichmäßig "fließen" und keine Engpässe bilden.
Zudem müssen die einzelnen Aufgaben in überschaubare Portionen unterteilt werden: "Keine Arbeit sollte mehr als zwei Wochen in Anspruch nehmen", sagt Kaak. Eine Frist, die in anderen Unternehmen, die Kanban praktizieren, bereits als zu lang erachtet wird. Aber Kanban ist ja ein Prinzip, das jedes Team für sich anpassen kann. Außerdem gelten für Helpdesk-Anfragen beispielsweise andere Beschränkungen als für Software-Changes.
Wie in den 70er Jahren bei Toyota, so installierte Kaak bei Blizzard eine Tafel (Whiteboard) mit horizontalen "Swimlanes", auf denen sich die einzelnen Aufgaben bewegen. Senkrecht dazu erstrecken sich die Phasen im Arbeitsablauf - angefangen von "to do" über diverse Stadien des "Work in Progress" (WiP) bis "done".
IT-Mitarbeiter bekommen den Rücken frei
Die Aufgaben werden auf dem Board durch Kärtchen symbolisiert (Das japanische Wort Kanban bedeutet auf Deutsch etwa: "Signalkarte"). Diese wandern im Verlauf der Bearbeitung von links nach rechts - jeweils mit dem Namen des zuständigen Mitarbeiters oder seinem "Avatar" gekennzeichnet. So lassen sich Arbeitsfortschritte und eventuelle Engpässe auf einen Blick erfassen - von Teammitgliedern wie Auftraggebern. Gibt es strittige Themen, beispielsweise konkurrierende Aufgaben, können die Beteiligten sie direkt an der Tafel - mit Kaak als Moderator - klären. So hält der CIO seinen in Entwicklung oder Operations tätigen Mitarbeitern den Rücken frei.
Kaaks Team nutzt Kanban sowohl für Helpdesk-Aufgaben als auch für Projekte, hat dabei aber unterschiedliche "Kanäle" definiert. Helpdesk-Aufgaben sind durch grüne Kärtchen dargestellt; hiervon kann jeder Operations-Mitarbeiter pro Arbeitstag bis zu sieben übernehmen. Wenn Platz auf dem Board ist, dürfen die internen Kunden ihre Requests auch direkt in die Schlange einreihen. Das erspart es den IT-Mitarbeitern, Kärtchen zu beschriften. Abgearbeitet werden die Tasks nach dem "Fifo"-Prinzip (First in, first out) - ohne Ansehen der Person. Nur Störungen, die sich direkt auf die Ski-Produktion auswirken, bekommen einen roten Punkt und werden in einer "Fast Lane" an den anderen Tickets vorbeigeführt.
Der Projekt-Kanal (gelbe Kärtchen) untergliedert sich noch einmal in zwei Kategorien: Entwicklung und Test. Hier sind jeweils zwei Aufgaben gleichzeitig bewältigbar. Häufig erweist sich, so Kaak, dass die Projektaufgabe beim Übergang von der Entwicklung in den Test stecken bleibt: Der Test erfordere nun einmal ein Feedback von Anwendern außerhalb der IT. Wenn das ausbleibe, stocke der "Flow".
Als Flaschenhals haben sich auch Aufträge an externe Dienstleister herausgestellt. Diese Kärtchen werden mit einem "E" gekennzeichnet und bekommen einen speziellen "Parkplatz" auf dem Board. Damit stehen sie unter besonderer Beobachtung.
Ein zweites Board wurde im IT-Raum des Unternehmens installiert. Hier sind die Tickets der vergangenen Monate nach Durchlaufzeiten geordnet - ein weiteres Mittel, um Transparenz in den Arbeitsfluss zu bringen. Tickets, die länger als fünf Tage benötigt haben, um von links nach rechts zu gelangen, gelten als "kritisch". Die Gründe werden analysiert und eventuell Gegenmaßnahmen eingeleitet.
Im Video: Kanban – Grundlagen (1/2)
Zum Video: Nach Scrum kommt nun Kanban
(Quelle: video2brain, Trainer: Patrick Lobacher)
Scrum als Einstiegsdroge
Wie Kaak setzt auch Michael Maretzke, CTO des Online-Dating-Portals "FriendScout24", neuerdings Teil des europäischen Marktführers Meetic Group, auf Kanban. Allerdings nur in der Softwareentwicklung. "Im Operations-Bereich ist das extrem schwierig", sagt Maretzke. Die Entwickler hätten mittlerweile ein anderes Verständnis von ihrer Rolle: "Das Berufsbild hat sich um 180 Grad gedreht; als Entwickler muss man heute ein kommunikatives Wesen sein, weil man sonst nicht mit den Fachbereichen reden kann." In Operations sei das Berufsbild noch traditioneller. Dort treffe man oft Menschen an, die eher introvertiert agierten und weniger kommunikativ seien
Außerdem gibt es in der Softwareentwicklung einen eklatanten Bedarf für neue Methoden. "Die Wasserfall-Entwicklung kommt oft zu spät mit Ergebnissen", hat der FriendScout24-CTO festgestellt. Eine schnelllebige Web-Plattform müsse sich innerhalb von Tagen ändern oder weiterentwickeln lassen. Die "Scrum"Methode ist aus Maretzkes Sicht die ideale "Einstiegsdroge" in das Thema Agilität. Hier gebe es immer noch ein Gerüst von Regeln, und seien es nur die "Planning"-, "Estimation"- oder die täglichen "Standup"- Meetings. Das Entwicklerteam übernehme zwar Eigenverantwortung, wie in der agilen Softwareentwicklung ja gewünscht, aber es praktiziere sie innerhalb eines Rahmenwerks.
Foto: James Thew - Fotolia.com
Praktikabler Kompromiss: Scrumban
Maretzke und sein 20-köpfiges Team sind schon einen Schritt weiter. Sie machen, wie der CTO sagt, "Scrumban": Sie nutzen die Kanban-Tafeln und "Task-Zettel", haben aber einen eigenen Satz Regeln vereinbart, an die sich alle halten. Dazu gehören unter anderem die regelmäßigen Meetings. Wie die Teams ihre Boards aufbauen, ist hingegen unterschiedlich. Selbstverständlich folgen alle dem Muster: To do - Doing - Done, aber "Doing" kann durchaus mehrere Phasen haben. Der "Agile Coach", den FriendScout24 als Position etabliert hat, konsolidiert die Boards wöchentlich in einem "Company Board", das öffentlich einsehbar ist.
Bei FriendScout24 sollen alle Entwicklungsaufgaben möglichst in einem Tag von "To do" bis "Done" vordringen. Größere Themen ("Stories") müssen auf kleine Tasks heruntergebrochen werden. Die Teams unterteilen die Stories in Aufgaben, die jeweils von einer Person abgedeckt werden können. Mehr als drei Zettel gleichzeitig sollte niemand auf dem Board haben. So bleiben Abhängigkeiten erkennbar, Ineffizienzen werden offenbar, Hindernisse lassen sich leichter identifizieren und beseitigen, so dass der erwünschte "Flow" entsteht.
Im Video: Kanban in der IT (2/2)
Zum Video: Nach Scrum kommt nun Kanban
(Quelle: video2brain, Trainer: Patrick Lobacher)
Mit 60 Stundenkilometern schneller ans Ziel
Um dieses kontinuierliche Fließen zu gewährleisten, nimmt Blizzard-CIO Kaak bisweilen sogar Leerlauf an einer Arbeitsstation in Kauf. "Manchmal kann ein Mitarbeiter kein neues Ticket öffnen, weil die nachfolgenden Stationen ihre Tickets noch nicht abgearbeitet haben", erläutert er. Warum hundertprozentige Auslastung keineswegs optimal ist, verdeutlich der IT-Chef am Beispiel der Tauern-Autobahn: Sie führte früher zweispurig auf den Tauerntunnel zu, in dem der Verkehr aber nur einspurig floss. Wenn nun die Autos mit 120 Stundenkilometern auf den Tunneleingang zurasten, bildete sich am Eingang oft ein kilometerlanger Rückstau. Hätten sich alle von Anfang an auf eine optimal berechnete Geschwindigkeit geeinigt, vielleicht 60 Stundenkilometer, wären alle eher angekommen.
Was auf der Autobahn meistens nicht funktioniert, lässt sich im Arbeitsumfeld durchsetzen. "Das erfordert selbstverständlich ein Umdenken", räumt Kaak ein, "weil es ja immer hieß, wir müssen die Leute auslasten." Doch um Rückstaus zu vermeiden, müsse sich ab und an ein Mitarbeiter mit anderem beschäftigen, so die Überzeugung des IT-Verantwortlichen:
"Entweder er hilft einem Kollegen, oder er dokumentiert den Engpass, damit andere daraus lernen können, oder - wenn die Ursache schon bekannt ist - er arbeitet an der Optimierung des Gesamtsystems. Und manchmal sage ich ihm sogar, er solle nach Hause gehen und ein Fachbuch lesen. Denn durch Lernen erhöhe ich die Kapazität ebenfalls."
Was tun, wenn sich der Fluss staut?
Bildet sich trotz ausreichend kleiner Skalierung und strikter Begrenzung des Work in Progress doch mal ein Rückstau, muss das Team entscheiden, was zu tun ist: Darf und soll die Aufgabe fallen gelassen werden, oder gibt es eine alternative Lösung? Muss man sie noch einmal unterteilen? Sind mehr Mitarbeiter für diese Aufgabe notwendig? Letzteres ist laut Kaak selten eine gute Idee. Schon Fred Brooks habe in "The Mythical Man-Month" nachgewiesen, dass mehr Leute im Projekt auch mehr Reibungsverluste bedeuten.
Als praktikable Lösung sieht der Blizzard-CIO hingegen die Automatisierung bestimmter Prozesse und - einmal mehr - die bessere Qualifizierung der Mitarbeiter. "Lean bedeutet ja nicht, dass das Unternehmen Kosten um jeden Preis spart, sondern dass die Organisation in der Lage ist, sich kontinuierlich zu verbessern." Kanban sei quasi die organisatorische Umsetzung des japanischen "Kaizen"-Prinzips (das so viel wie "kontinuierliche Verbesserung" bedeutet).
Software-Kanban nach David Anderson
Eines der Grundprinzipien von Kanban lautet: Der Arbeitsfluss wird sichtbar. Auf dem Kanban-Board lässt sich die gesamte Wertschöpfungskette mit ihren Prozessschritten für alle Beteiligten visualisieren. Die Menge der angefangenen Arbeit („Tickets“) ist begrenzt. In einem Kanban-System wird die Arbeit nach dem Pull-Prinzip verteilt: Anstatt fertige Aufgaben an die nächste Station zu übergeben, holt sich diese aktiv das nächste Ticket, sobald sie Kapazität frei hat. Und das ist nur der Fall, solange sie eine definierte Maximalzahl paralleler Aufgaben nicht überschritten hat. Der Durchfluss wird gemessen und gesteuert.
Typische Mess- größen sind die Länge von Warteschlangen, die Zykluszeit und der Durchsatz. Die Mitglieder des Prozesses messen und melden diese Werte. So wird ein etwaiger Verbesserungsbedarf erkennbar –und die Planung erleichtert. Alle Regeln für den Prozess sind für alle Beteiligten explizit; dazu gehört beispielsweise eine Definition von „fertig“. Jeder fühlt sich für den Erfolg verantwortlich: Nur wenn sich alle Ebenen der Organisation beteiligen, lassen sich tatsächlich Verbesserungen erzielen.
Kanban digital - nur im Notfall?
Seit dem Buch von Anderson hat sich einiges getan. Mittlerweile gibt es eine ganze Reihe von Softwarewerkzeugen, die sich anheischig machen, die "Zettelwirtschaft" abzulösen. Dazu zählen beispielsweise "Jira", "LeanKit", "Kanbanery" oder "Projectplace". Kaak sieht darin nicht unbedingt einen Fortschritt. Nur bei unternehmensübergreifenden und geografisch verteilten Projekten, beispielsweise der gruppenweiten ERP-Einführung, sei der Einsatz eines solchen Tools sinnvoll.
In den meisten Fällen bringe ein physisches Board jedoch mehr, beteuert der Blizzard-CIO: "In den ersten sechs Monaten habe ich meinen Mitarbeitern untersagt, nach einem Tool zu suchen. Wir wollten ja erst mal schauen, ob das überhaupt funktioniert. Und dann haben die Leute gesehen, wie gut es ist, tatsächlich vor einem Board zu stehen und zu diskutieren." Danach sei Softwareunterstützung kein Thema mehr gewesen. Einem digitalen Tool fehlten die Haptik und der kommunikative Faktor.
Auch bei FriendScout24 schätzen die Mitarbeiter die physischen Boards, die sie phantasievoll ausgestalten - teilweise mit Avataren und verdeutlichenden Graffiti. Aber die Methode lässt sich ja auch für externe Mitarbeiter nutzen, beispielsweise im Nearshore-Bereich. Für sie greift FriendScout24 auf eine Software zu, die Kanban-Abläufe abbilden kann: Jira mit dem Add-on "Agile" (ehemals "Greenhopper"). Wie Maretzke einräumt, ist das Tool "nahe am Original, aber lange nicht so kommunikativ".
ITIL allein reichte nicht aus
Auch Hellmann Worldwide Logistics setzt in Teilbereichen dieses Tool ein. Mit ihm lassen sich beispielsweise Punkte für bestimmte Anforderungen vergeben - um daraus zu einer Priorisierung zu kommen. Hellmann wollte so unter anderem die Nearshore-IT in Ungarn steuern. Wegen des entfernten Standorts dieser Mitabeiter setzte man anstelle des Schwarzen Bretts auf ein Softwarewerkzeug.
Mittlerweile wird das Tool auch in den USA genutzt. Dort fand das Kanban-Prinzip schon 2011 Eingang. Mit der Einführung betraute Stefan Borggreve, damals in seiner Eigenschaft als IT-Leiter für die Region Americas, den Business-Architekten Marco Mathews. Der führte Tafel und Aufgabenkarten ein. "Um die Methode und den Prozess zu lernen, war es ideal, mit einem physischen Board und Papierkarten anzufangen, um nicht direkt die zusätzliche Komplexität einer Softwarelösung ins Spiel zu bringen", so Borggreves Überzeugung.
Es ging zunächst um die Reorganisation der Arbeit von etwa einem Dutzend Mitarbeitern in den USA. Dort war der Infrastrukturbereich bis dato eher chaotisch "organisiert". Wie Borggreve anmerkt, reichte auch der Einsatz der Best Practices nach ITIL nicht aus, um dafür zu sorgen, dass "im Tagesgeschäft die richtigen Ressourcen zur richtigen Zeit an den richtigen Themen arbeiten".
Steine des Anstoßes waren der erhebliche Aufwand an Wartungsarbeiten sowie eine relativ geringe Bearbeitungsquote von Projekten und internen Verbesserungen. "Wenn man nicht den gesamten Tätigkeitsbereich der Ressourcen inklusive der Wartungsarbeiten im Blick hat, nutzt einem das schönste Projekt-Management nichts", sagt Borggreve, der heute verantwortlich für die Business Production Solutions bei Hellmann zeichnet.
Es galt also, die Support-Quote zu verringern, um die Aufgabenflut insgesamt besser bewältigen und mehr Zeit in zukunftsorientierte Projekte investieren zu können - kurzum: weniger Wartung, mehr Wertschöpfung. Aber wo anfangen, wenn es keine Prozesse dafür gibt oder sich zumindest niemand daran hält?
Durch die Kanban-Einführung definierten die Mitarbeiter sehr genau ihren Abarbeitungsprozess sowie die notwendigen Spielregeln - mit dem Erfolg, dass sie sich nun auch daran hielten. Unter Mathews` Anleitung wurde der Prozess regelmäßig auf den Prüfstand gestellt und weiter optimiert. Die Prozessverletzungen liegen seither unter einem Prozent, versichert Borggreve. Für wirklich dringende Probleme wie Server-Ausfälle gibt es selbstverständlich eine "Fastlane".
Mittlerweile ist der Kanban-Funke aus der kleinen US-IT in die zehnmal so große Global Information Systems und die operativen Einheiten übergesprungen. Immer mehr von den Teamaufgaben werden heute auf diese Weise transparent gemacht und vorangetrieben. Damit verbunden ist eine kontinuierliche Verbesserung, die sich aus den Informationen über Arbeitsfluss und Flaschenhälse speist.
Foto: violetkaipa - Fotolia.com
Die IT wird zum Kanban-Berater
Kanban geht fast überall, sagt Borggreve. Auch wenn das System seine Grenzen habe, also beispielsweise kein Projekt- und Portfolio-Management ersetzen könne. Dafür eigne es sich bestens zum kurzfristigen und effizienten Ressourcen- und Task-Management: "Für uns ist das Kanban-Board ein wunderbarer Durchschleusmechanismus."
Bei Blizzard wird Kanban heute in den unterschiedlichsten Fachbereichen genutzt: in der Qualitätssicherung, Instandhaltung, aber auch im Marketing, beispielsweise um Leads zu bearbeiten oder Messen zu planen, ja sogar für Ausschreibungen im HR-Bereich und dazu noch als Instrument zur Bewältigung von Adhoc-Aufgaben.
Die IT habe sich quasi als interne KanbanBeratung etabliert, freut sich Kaak: "Wir werden immer wieder geholt, um die Zusammenhänge darzustellen und Tipps für die Umsetzung zu geben."
Erfolgsfaktoren für eine Kanban-Einführung
Damit die Kanban-Einführung ein Erfolg wird, müssen laut Stefan Borggreve von Hellmann World- wide Logistics drei Voraussetzungen erfüllt sein:
Das Management auf allen Ebenen muss hinter diesem Prinzip stehen.
Man darf den Veränderungsprozess nicht zu sehr pushen. Vielmehr muss er in den Köpfen der Leute ankommen, um sich von dort langsam und stetig zu entwickeln.
Das Vorhaben sollte konti- nuierlich von einem Experten begleitet werden.