ITIL – et gufs fra 90-tallet

Jeg har alltid hatt et avslappet forhold til ITIL. ITIL er “noen support-prosesser” som tar i mot kundehenvendelser, kategoriserer og enten løser saken eller sender videre til “utviklingsavdelingen”. Trodde jeg. Jeg husker vagt jeg satte meg inn i Problem Management, Service Management, Incident Management, Release Management og sånt en gang for lenge siden. Det virket fornuftig å etablere et standardisert begrepsapparat for slikt, og jeg husker at en av prosessene gikk på læring. Jeg har tenkt at hovedfokuset for en god ITIL implementasjon må være å samle erfaring og å identifisere systematiske feil slik at de kan rettes en gang for alle. Fornuftig det! 

Jeg får fra tid til annen spørsmål og hvordan Scrum og ITIL passer sammen – og jeg skjønner nå at jeg har tatt litt for lett på dette spørsmålet. I mitt enkle verdensbilde har ITIL representert 1. linje support – de som avgjør om Scrum teamet skal få saken eller om det kan løses av andre. Alle gode prosesser med fokus på kvalitet (som jo Scrum er) foreskriver at de som forårssaket feilen skal få den rett tilbake så fort som overhodet mulig. Kjører man korte iterasjoner (14 dager eller mindre) og leverer små inkrementer fortløpende vil dette kunne bli helt optimalt.

Jeg leste med interesse innstikket om ITIL i Computerworld for et par uker siden. En lang sammenhengende hyllest til dette rammeverket, med ett lite unntak, nemlig “universalskeptiker” Helge Skrivervik som sier Itil er gammeldags. (Han blir her kraftig marginalisert ved at journalisten gjentar “universalskeptiker” flere ganger i artikkelen.) Uansett, det Skrivervik sa var nok til å pirre nysgjerrigheten min, så jeg satt i gang med å orientere meg litt i ITIL-jungelen. Og det er en jungel med ekstremt mange aktører på kurs og tjenester. Men det var ikke så vanskelig å finne beskrivelser som gjor at en novise som meg kunne orientere meg i dette uten å måtte gå i detalj.

Den gjeldende versjonen er ITIL V3. Dette rammeverket er et gigantisk, altomfattende rammeverk for drift, vedlikehold, release, og nyutvikling. Hvor omfattende dette er kan man få et inntrykk av her og her.  Jeg har sett og brukt utallige prosessmodeller opp igjennom tidene. Vi brukte Cleanroom Software Engineering på tidlig 90-tall i Siemens Forsvarssystemer. Jeg har brukt hjemmesnekrede, detaljerte vannfallsorienterte modeller og jeg har brukt RUP. All denne erfaringen har lært meg en ting: Standardisering av arbeidsflyt er fornuftig – så lenge man ikke detaljspesifiserer og så lenge man holder seg til minimumsløsninger. Rigorøse prosesser fører enten til at man sementerer prosessen og dermed umuliggjør systematisk forbedringsarbeid eller det fører til “ulydighet” ved at man omgår prosessen for å klare å jobbe effektivt. Alle prosedyreverk bør starte med et absolutt minimum og så kan vi legge til detaljerte prosedyrer på områder som er spesielt kritisk for oss. Det er mye vanskeligere å begynne med noe stort, komplett og detaljert og så fjerne det vi ikke trenger. Jeg kaller dette på spøk Geirs første og eneste lov: “Det er 10 ganger lettere å legge til enn å trekke fra”. Helge Skrivervik har tydeligvis samme syn.

Helge Skrivervik: FFF: Forandring uten Forenkling er Forkastelig!

ITIL-prosessene er noen store mammuter, eller dinosaurer er kanskje et bedre ord. Jeg finner et 40-talls roller, en mengde store prosesskart som typisk nok blir helt uleselige når de forminskes for å passe inn i et normalt dokument eller en web-side. Jeg ga fort opp å forstå de hierarkisk oppbygde flytdiagrammene. Kan dette være nødvendig da? Det som er helt sikkert er at dette er anti Agile, anti Lean og det sikk motsatte av Systems Thinking. ITIL systematiserer jo alt de John Seddon advarer så sterkt mot.

Ikke nok med det – ITIL er først og fremst laget for å optimalisere feilhåndtering. Hvorfor skal vi det? Dette er jo i utgangspunktet Waste, eller slikt John Seddon definerer som Failure Demand.

John Seddon: Failure Demand is demand on the resources of an organization caused by its own failures.

Mary Poppendieck: Your objective is not to handle failure demand more efficiently; it is to eliminate failure.

Det slår meg at dette rimer veldig godt med god gammeldags vannfallstankegang eller “Command and Control”; Vi håndterer kompleksitet og avhengigheter ved å modellere virkeligheten. Gantt-diagrammer er et godt eksempel på dette. Tenker man Lean vil man i stedet for å modellere eller håndtere avhengigheter redusere avhengigheter. Moderne, effektive organisasjoner verdsetter innovasjon, kvalitet og fleksibilitet, nærhet til kunden og jobber med enkle, fleksible rammeverk som Scrum og Kanban.

Problem Management: Skremmende ineffektiv “handover” prosess – lang avstand til brukeren:

ProblemManagementProcess

Hva med å kjøre en “Eliminate Waste” på denne ved å bruke Total Value Stram Maps? Ikke helt få køer og prosesstrinn der det ikke foregår mye verdiskapning – om en har på kundebrillene.

Posted on March 17, 2010 at 7:57 am by gamsjo · Permalink
In: ITIL, Lean, systems thinking · Tagged with: , , ,

Leave a Reply