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)
(Quelle: video2brain, Trainer: Patrick Lobacher)