Warum ein Ticket-System kein Kanban-Board ersetzt

Vie­le gera­de klei­ne­re IT-Abtei­lun­gen haben mei­ner Erfah­rung nach gro­ße Schwie­rig­kei­ten, die (meist knap­pe) zur Ver­fü­gung ste­hen­de Zeit zwi­schen zwei Arten von Arbeit auf­zu­tei­len: reak­ti­vem Sup­port und (gleich­sam pro­ak­ti­ver) Pro­jekt­ar­beit – Betrieb und Pro­jekt. Eine kla­re per­so­nel­le Tren­nung zwi­schen die­sen Berei­chen ist meist spä­tes­tens im Fal­le von Eska­la­tio­nen in den 2nd Level kaum mög­lich – dafür steht in mit­tel­stän­di­schen IT-Abtei­lun­gen in aller Regel schlicht nicht genü­gend aus­rei­chend qua­li­fi­zier­tes Per­so­nal zur Ver­fü­gung. Die Men­schen müs­sen sich bzw. ihre Zeit also zwangs­läu­fig auf­tei­len und fast immer gewinnt dann (ver­meint­li­che oder ech­te) Dring­lich­keit gegen­über Wich­tig­keit – meist also Betrieb (bzw. Stö­rung) gegen­über Projektarbeit. 

Ich emp­feh­le IT-Infra­struk­tur-Abtei­lun­gen inzwi­schen oft und gern die Ein­füh­rung von (zumin­dest Proto‑)​Kanban (vgl. hier) – vor allem, weil genau die­ser Kon­flikt am Kan­ban-Board sicht- und damit mana­ge­bar wird: Die Kan­ban-Prak­tik, durch Visua­li­sie­ren alle Arbeit (in die­sem Fall also: sowohl „Tickets“ aus dem Betrieb als auch Arbeits­pa­ke­te aus den Pro­jek­ten) sicht­bar zu machen, för­dert das Dilem­ma zuta­ge, führt vor Augen, wie sehr sich die IT-Mit­ar­bei­ter in der täg­li­chen Arbeit zer­rei­ßen müs­sen – und zeigt in aller Regel auch, an wel­chen Punk­ten kla­re Ent­schei­dun­gen und eben­so kla­re Zusa­gen feh­len. Die hohe Sicht­bar­keit aller Arbeit sorgt also nicht nur dafür, dass den Aus­füh­ren­den „nichts durch­rutscht“, son­dern auch dafür, dass die zustän­di­gen Füh­rungs­kräf­te sehen kön­nen, wo bei­spiels­wei­se Ent­schei­dun­gen gefragt sind. Manage­ment by Excep­ti­on setzt nun ein­mal vor­aus, dass die Excep­ti­on auch erkannt wird – und genau dafür erscheint mir ein für alle sicht­ba­res Kan­ban-Board als sehr effektiv.

So weit, so gut – bis hier­her fol­gen mir in aller Regel die meis­ten Men­schen, mit denen ich dar­über spre­che. Im wei­te­ren Ver­lauf beob­ach­te ich aller­dings häu­fig zwei Gedan­ken­schrit­te, die sehr geeig­net sind, den m. E. guten Ansatz nach­hal­tig zu torpedieren:

1. ITler imple­men­tie­ren gern IT-Sys­te­me – sonst wären sie nicht in der IT gelan­det. Ein phy­si­sches Kan­ban-Board mit Zet­teln in den Flur zu hän­gen, wider­strebt gera­de IT-Infra­struk­tur-Spe­zia­lis­ten (anders als offen­bar Soft­ware­ent­wick­lern) mei­ner Erfah­rung nach extrem. Nun gibt es sicher­lich gut ein­setz­ba­re Soft­ware-Lösun­gen, mit denen sich die Funk­tio­na­li­tät eines Kan­ban-Boards abbil­den lässt – die unbe­que­me Omni­prä­senz eines phy­si­schen Boards​¹ erreicht man so jedoch nicht​². Anders for­mu­liert: Ein in Soft­ware „gegos­se­nes“ Board kann man viel ein­fa­cher igno­rie­ren – das klappt mit dem jeweils ein­ge­setz­ten Ticket-Tool meist ja schon ganz gut.
2. Ist erst ein­mal die Ent­schei­dung gefal­len, das Board in Form einer Soft­ware-Lösung umzu­set­zen, ist der nächs­te m. E. fata­le Gedan­ken­schritt nicht weit: In prak­tisch jeder etwas grö­ße­ren IT-Orga­ni­sa­ti­on exis­tiert ja bereits ein Sys­tem, das „Tickets“​³ managt. Was liegt also näher, als die­ses Sys­tem zweck­zu­ent­frem­den – vor allem, weil die eine Hälf­te der gesam­ten Arbeit in die­sem Sys­tem ja bereits ent­hal­ten ist? Pro­jekt­ar­beit wird also auf ein­mal müh­sam in ein Sys­tem gepresst, des­sen Work­flow und des­sen wei­te­re Funk­tio­na­li­tä­ten extrem spe­zi­fisch zuge­schnit­ten sind auf eine völ­lig ande­re Form von Arbeit – Betrieb, i. d. R. Inci­dents und Requests. Nun sind weder User Inter­face noch die Report­ing-Mög­lich­kei­ten typi­scher Help­desk-Lösun­gen geeig­net, Pro­jekt­ar­beit zu ver­wal­ten; in aller Regel gibt es auch kei­ne sinn­vol­le Mög­lich­keit, die gesam­te Arbeit auf ein­mal sicht­bar dar­zu­stel­len – von der Imple­men­tie­rung von WIP-Limits (vgl. hier und hier) ganz zu schwei­gen. Von dem löb­li­chen Ansatz, wirk­lich alle Arbeit und damit den andau­ern­den Kon­flikt zwi­schen Betriebs- und Pro­jekt­ar­beit ans Licht zu zer­ren, ist so kaum noch etwas übrig – und in einen klas­si­schen Sup­port-Work­flow gezwun­gen gerät die („nur“ wich­ti­ge) Pro­jekt­ar­beit ob der (eigent­lich immer dring­li­chen) betrieb­li­chen Pro­ble­me meist end­gül­tig ins Hintertreffen.

Von Intra­nets sagt man ja oft scherz­haft (und erfreu­lich häu­fig unbe­rech­tigt), sie sei­en der Ort, an den Infor­ma­tio­nen zum Ster­ben gehen. Stopft man Pro­jekt­ar­beit mehr oder min­der bru­tal in ein zweck­ent­frem­de­tes Ticket-Sys­tem, kann man sich m. E. fast sicher sein: Eben die­ses Ticket-Sys­tem ist genau der Ort, an den die Arbeits­pa­ke­te zum Ster­ben gehen!