Reni Friis bloghoved

Uden Lean får man ikke nok ud af ITIL

Masser af virksomheder implementerer ITIL i håbet om, at der så vil komme styr på tingene – at man vil blive mere effektive, koordinerede og få gladere medarbejdere og kunder. Det er de bedste intentioner at have, men jeg mener på ingen måde, at en implementering af ITIL nødvendigvis gør nogen forskel i forhold til de faktorer.

ITIL er et godt rammeværktøj af it-processer, som har en stor styrke i at få styr på, HVAD man skal gøre ifm. procesområderne, som ITIL dækker. At man i fx Incident Management starter med at tage imod en sag i SPOC, registrerer, prioriterer osv., inden man sender videre til 2nd level, er jo genialt. Sådan bør alle jo gøre det!

Det, ITIL ikke siger så meget om, er så, HVORDAN man kan udføre de trin, processerne har.

Tag fx et spørgsmål som ”Hvor mange samtidige opgaver er det effektivt at tillade, at en medarbejder arbejder på?”. Det får man ikke svar på via ITIL. Jeg ser ofte medarbejdere, der har op til 15 samtidige opgaver. Ingen arbejder på 15 opgaver på samme tid, så der må være nogle af opgaverne, som bare venter. Hvorfor ikke lade opgaverne ligge i en bunke et bestemt sted i processen?

Der kan man overskue, hvilke opgaver der er, prioritere dem og sikre, at ingen spilder tid på opgaverne, før de har tid nok til at gøre dem færdige. På den måde spildes mindre af medarbejdernes tid på at gå til og fra opgaver, svare på rykkere (man kan jo tydeligt se status, når den ikke er halvt i gang hos en medarbejder, der i øvrigt har for travlt) og holde styr på de opgaver, han/hun arbejder på. Der er lavet flere undersøgelser, der viser, at denne måde at styre arbejdet på giver kortere gennemløbstider på opgaverne og færre fejl.

Det lyder måske ikke som Lean, men det er lige præcis det, som Lean-princippet om FLOW handler om: At sikre, at opgaverne flyder, når først de er sat i gang, undgå fejl og omprioriteringer sent i forløbet samt at sikre gennemsigtighed omkring kapacitet i processen.

Dette er blot et eksempel ud af mange på, hvordan man kan køre det flotteste ITIL, men stadig være ineffektive, levere dårlig kvalitet og have utilfredse kunder. Kombinationen af ITIL og Lean gør, at man både får best practice-input til, HVAD man bør gøre ift. procestrinsrækkefølge osv., og samtidig får man input til, HVORDAN man kan arbejde i processen på en effektiv og effektfuld måde. Det er da win-win!

Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jari Bøg Larsen

Jeg synes det er en meget relevant artikel som netop understreger at man ikke nødvendigvis er mere effektiv fordi man arbejder efter processer defineret af et rammeværk som fx ITIL. Den samme observation kunne man sikkert gøre om projektarbejde, hvor PRINCE2 eller statens it-projektmodel ikke er tilstrækkeligt til at sikre at man hurtigere får udviklet brugbare it-systemer. Her kunne erfaringerne fra agile tilgange måske fungere som inspiration.

  • 0
  • 0
Tom Høg Sørensen

Har i en periode arbejdet med denne problemstilling i en IT serviceorganisation. For godt 1½ år siden overtog jeg driften af den virksomhed, hvori jeg havde fungeret som udviklingschef i 13 år. Det første jeg tog fat i var serviceafdelingen. Her arbejdede alle medarbejdere med de incidents de hver havde modtaget direkte fra kunden eller en kollega, noget måtte gøres. Jeg arbejdede i en måneds tid med ITIL som løsningen, men fandt den ikke tilstrækkelig. Havde arbejdet med agil udvikling, og forsøgte derfor at udnytte denne viden. Fandt nogle amerikanske artikler om KanBan (en oplysningstavle anvendt i LEAN) i serviceteams. Fik lavet en model (servicedesk version 2.0), der bygger på en kombineret ITIL og LEAN, hvor KanBan er et centralt element. Denne model har vi i dag stor success med, hvor KanBan-tavlen giver et aktuelt billede af de modtagne incidents med prioritering og hvor incidents hver servicemedarbejder arbejder på. Vores erfaring siger efter godt et år, at det antal incidents en medarbejder må arbejde på samtidigt (WIP) må ligge mellem 2 og 4, hvor 2 er det ideelle, hvis kunden skal have rimelig sikkerhed for at få håndteret en incident inden for deadline.

Vores udviklingsafdeling har taget modellen til sig, så de idag er gået væk fra at køre en stram SCRUM til en kombineret model, som er en blanding mellem SCRUM og KanBan.

  • 1
  • 0
Thomas Ehler

Problemet med Lean er bare at det meget ofte misbruges.
Når alle medarbejdere har siddet og bidraget med alle de små effektiviseringer de kan se mulighed for og så pludselig sidder med et kraftigt reduceret arbejdsområde, og dermed langt mere ensformig hverdag, føler de sig forrådt. Og det er de også!
Jeg har arbejdet sammen med Lean konsulenter som ikke lagde skjul på at de var hyret ind for at lave "fabrikker". Lean er sikkert ok i de rette hænder men når ledelsen lugter guldet, går det oftest galt!

  • 1
  • 0
Michael Juel

Ligger det ikke latent i litteraturen at ITIL skal applikeres ud fra LEAN principperne?

ligesom alle de andre new age management typer hvor konceptualiseringen er frarøvet arbejderen, hierakiet opløst og eneste ledelsesværktøj er kontrol?

  • 2
  • 0
Reni Friis

Der er mere eller mindre videnskabelige og matematiske tilgange til det emne... Min personlige erfaring er, at 3-5 opgaver ad gangen er godt. Har man en grænse på 3, så kræver det en del af ledelsen ift beslutninger, brugere ift at vende tilbage osv, for at medarbejderen ikke sidder stille for meget... Har man mange igangværende opgaver, vil de ofte bare vente på at medarbejderen får tid. Det er altså brugeren der venter (fokuspunkt nummer 1 indenfor Lean er, at en sag ikke skal vente unødigt) hvor en anden medarbejder måske kunne have gået i gang med sagsløsningen. Men det kan han/hun kun med omkostninger i form af tabt viden, risiko for fejl osv, hvis den allerede er påbegyndt... Jeg mener man skal sætte WIP (work in progress...) grænsen til noget overskueligt, og så skrue ned derfra efterhånden som barriererne for lavere WIP grænser viser sig... At bare sætte den ned fra fx 20 til 3 vil bringe kaos og ingen kan se hvilket problem dermed er det største...

Den mere matematiske tilgang kredser om sammenhængen mellem gennemløbstider, ankomstrater og køstørrelse (WIP). Erlang arbejde i sin tid en del på at optimere køstørrelsen ud fra disse principper. Little har også arbejdet med dette, og Capers Jones har i mange mange studier bevist en effekt mellem fejl, gennemløbstider og WIP (antallet er fejl siger eksponentielt med antallet af WIP).

Det er et meget spændende emne, som man kan angribe begge veje... jeg mener at mange it-processer bedst egner sig til en ikke-helt-målfast tilgang - altså at man prøver sig frem...

  • 0
  • 0
Reni Friis

Hej Casper

Jep - det gør det. OPEX står jo bare for Operational Excellence (i sig selv et acronym, som man kan elske eller hade), og indenfor it-verden giver det ikke mening at kikke på ITIL i den forbindelse. Herunder også "deres" ramme for løbende forbedringer = CSI, og SPOC som måden at sikre optimal kø-afvikling af indkomne sager igennem EN KØ. Ifølge Erlang i hvert fald...

  • 0
  • 0
Reni Friis

Hej 109836

Jeg er enig med dig i, at man ikke bare bør snuppe ITIL ned fra hylden, og så kører det bare... jeg synes også det er logik, at man bør fortsætte med at forbedre "fittet" af processerne med behovet osv... og gid det var så vel, at alle gjorde det!!!

Jeg oplever næsten altid dog, at virksomheder hvilker på et ITIL fundament uden at reflektere yderligere over om ikke de skulle tænke lidt i løbende forbedringer osv... Det koster jo penge at forbedre og ændre ting (uanset om man bruger ekstene eller interne ressourcer i øvrigt), og omend besparelsen ved at forbedre overstiger omkostningen i de fleste tilfælde, så sker det bare ikke...

hvorfor ikke spørger jeg bare??

Reni

  • 0
  • 0
Kenneth Darling Sørensen

Det er et meget spændende emne, som man kan angribe begge veje... jeg mener at mange it-processer bedst egner sig til en ikke-helt-målfast tilgang - altså at man prøver sig frem...

Meget enig i at man skal prøve sig frem. Hvor mange sager en medarbejder kan håndtere afhænger jo af en række faktorer som er forskellige på tværs af organisationer, fx hvor komplekse er sagerne og hvor lang tid er kunderne om at svare tilbage.

  • 0
  • 0
Log ind eller Opret konto for at kommentere