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.

Kanban – Projektarbeit und Betrieb (Support) mischen

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​1 erreicht man so jedoch nicht​2. 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“​3 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!

Fuß­no­ten:

  1.  Gesetzt den Fall, man hat es nicht mit einem ver­teil­ten Team zu tun.
  2.  Mehr zu den Vor­tei­len eines „hap­ti­schen“ Boards fin­det sich bspw. in Flo­ri­an Eisen­bergs Blog unter <https://​www​.kanb​wa​na​.de/​2​0​1​8​/​0​6​/​2​6​/​w​a​r​u​m​-​h​a​p​t​i​s​c​h​e​-​b​o​a​r​d​s​-​s​o​-​cool-sind/> (21.10.2019).
  3.  Und nicht anders wer­den die Arbeits­ein­hei­ten in einem Kan­ban-Sys­tem ja oft (m. E. inhalt­lich ver­fäl­schend) genannt.

2 Replies to “Warum ein Ticket-System kein Kanban-Board ersetzt”

  1. Schö­ner Arti­kel, aller­dings steht und fällt die Lösung, mit dem Kan­ban ALLE Arbei­ten sicht­bar zu machen, mit der Akri­bie, die­ses per­ma­nent auf aktu­el­len Stand zu hal­ten. Gera­de die (wichtigsten)Geschehnisse und dar­aus resul­tie­ren­de Ein­fluss-Fak­to­ren des täg­li­chen Inci­dents Manage­ments auf das Kan­ban zu brin­gen bedarf eines nicht uner­heb­li­chen Auf­wan­des. Und hier kann meist man nicht nur 1 Per­son für defi­nie­ren, son­dern es ist ein „com­mon approach“ aller in der IT Abtei­lung arbei­ten­den. Zudem bekommt man durch eine SW-Lösung des Boards die bes­se­re Mög­lich­keit, Ver­än­de­run­gen auto­ma­ti­siert mit­zu­be­kom­men, wer sie ver­an­lasst hat und vllt sogar war­um. Ganz zu schwei­gen bei dem (nach­voll­zieh­bar) stei­gen­den Wunsch der Mit­ar­bei­ter nach Tagen im Home­Of­fice. Bei phy­si­ka­li­schem Ein­satz des Boards ist das m.E. schwer realisierbar.

    • In der Tat: Ein phy­si­sches Board fin­det sei­ne Gren­zen, sobald das Team in grö­ße­rem Umfang aus der Fer­ne arbei­tet – Home Office und dis­lo­zier­te Teams sind m. E. hier die wohl vali­des­ten Grün­de für den Ein­satz von Soft­ware­lö­sun­gen. Die Pro­ble­ma­tik der not­wen­di­gen „Akri­bie“ wird häu­fig gelöst, indem (expli­zier­te!) Regeln dafür geschaf­fen wer­den, was nicht auf dem Board lan­det – z. B. Pass­wort-Rück­set­zun­gen, Ent­sper­ren von Accounts o. ä. Wich­tig dabei ist aber sicher­lich, die Men­ge die­ser (dann ja meist nur noch „pau­schal“ visua­li­sier­ten) Arbei­ten den­noch eini­ger­ma­ßen quan­ti­fi­zie­ren zu kön­nen. Im Fal­le von Soft­ware-Lösun­gen kann man übri­gens nöti­gen­falls auch das Ticket-Sys­tem mit der Board-Soft­ware syn­chro­ni­sie­ren – und spä­tes­tens im Ticket-Sys­tem wäre die „Akri­bie“ ja sowie­so zumin­dest wün­schens­wert wenn nicht gar notwendig!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*