Det här med vad, varför och hur är en annan del som tas upp i artikeln och det här med best practise – enligt vem?:

Itil fokuserer mer på hvordan enn hva og hvorfor. Det er en liten gruppes oppfatning av hva som er best praksis.

Man måste se itil för vad det är, använda sig av dokumentationen på rätt sätt och vara fullt medveten om och ha kunskap om de luckor som finns och vad som faktiskt fungerar i praktiken.  Artikeln avslutas med orden:

Itil er ikke dårlig, men veldig ofte misbrukt. Brukt riktig og i passe mengder vil Itil være nyttig for de fleste organisasjoner

Itil måste ses för vad det faktiskt är och användas på rätt sätt.

Angelica Haverblad

Dela med andra:

Det har annonserats om en uppdatering av senaste ITIL® litteraturen och positivt att ett av syftena är att:

Standardize the use of glossary definitions within the five titles. Ensure that the explanations in the text align with those in the glossary.

Källa: Scope and development plan ITIL® v3 update

Bra att det nu framgår att argumentet: ”ITIL ger gemensamt språk och man ska förstå varandra internt och sina leverantörer/kunder” inte håller. Det är inte så enkelt ens om det i böckerna hade varit konsekvent användande av begrepp och definitioner.

Angelica Haverblad

Dela med andra:

Roller är ett område som kommer att ses över i den uppdatering som ska göras av itil litteraturen:

Roles need to be made consistent across the books,
ensuring that the activities apply only to one role

Give clear explanations and descriptions of roles and
responsibilities

Examine the definition and usage of the roles of Product
Manager and Service Owner

Källa: Scope and development plan itil v3 update

Angelica Haverblad

Dela med andra:

Här är itil och SOA varandras motsatser – Itil är en förkortning som många använder men få praktiserar fullt ut.

Angelica Haverblad

Dela med andra:

Guiden ska ge en bättre förståelse för behovet av IT-styrning utifrån rollen som Service Manager. Strukturen i guiden utgår ifrån Cobits delar så som kontroller, mål och mätetal, roller och ansvar (RACI) och mognadsnivåer. Guiden omfattar en mappning av cobit och itil och visar på hur dessa kan användas tillsammans.

”Enterprises that want to put the itil progam into the context of a wider control and governance framework should use cobit.”

(Citerat från Cobit user guide for Service Managers)

Angelica Haverblad

Dela med andra:

Jag har i tidigare inlägg skrivit om påstådda nyheter i itil v3 som Event Management och har fått frågan var denna nyhet har sitt ursprung. Ursprunget är inte enkelt att spåra eftersom nyheten finns att läsa i flertal olika forum (i form av artiklar och presentationer).

I en artikel (publicerad i tidningen servicetalk juli numret 2007 som ges ut av itsmf uk) står det om boken Service Operations bland annat: ”In v2, incident management included events and service requests, but did not define the relationship between them.”.

Troligen är det behovet att lyfta fram någonting nytt som har gjort att det har övertolkats och därav beskrivs i termer av nyhet.

Man kan ställa sig frågande till var det kommer ifrån, hur en sådan nyhet kan få en sådan spridning…

Angelica Haverblad

Dela med andra:

Ibland verkar behov av nyhet vara större än själva ”nyheten”.

Angelica Haverblad

Dela med andra:

Itil v3 ska vara “nyckeln till affärsnytta” men även denna gång har man skjutit förbi målet. Faktum är att budskapet är tvärs emot samverkan mellan affär och IT bland annat genom att hävda att IT-verksamheten ensamt ansvarar för risk och värde. Här fortsätter itil på samma spår som tidigare – allt ansvar läggs enbart på IT-verksamheten. Och service management ska drivas av IT-personalens vilja att behålla sina jobb, inte för företagets bästa. Det framgår av citatet som inleder ”Service Strategy”: “How do you become not optional?”, med innebörden att hela syftet med service management är att om man inte tillämpar det blir man av med jobbet eftersom det annars blir outsourcing.

En del luckor som fanns i tidigare version har tätats vilket är positivt men innehåller egentligen inte något nytt, lite kejsarens nya kläder över det hela. Det vill säga om man har satt sig ner med v2 och omvandlat teori till praktik och därmed identifierat luckorna (flertal finns fortfarande) och täppt till dessa för att “få ihop det”. Bland de nyheter som lyfts fram finns t ex Event Management, vilken fanns i tidigare version.

Itil har börjat åka ner på “hype kurvan” och ramverket cobit tar sig upp. Det är uppenbart att cobit funnits med i bilden för nya versionen inte minst cykeln från strategi till kontinuerlig förbättring. Andra delar är begreppen värde och risk som genomsyrar cobit, men tyvärr inte i itil tankemässigt utan enbart i form av förekomsten av begreppen. Itil sätts inte in i sitt sammanhang ur ett helhetsperspektiv, till skillnad från cobit där det perspektivet finns och det tydligt framgår hur och var bland annat itil kan komma in i sammanhanget. Vissa ser cobit som en konkurrent istället för komplement. Det ena utesluter inte det andra, de kompletterar varandra.

Itil marknadsförs som “best practise” baserat på 1000-tals företags erfarenheter och min förhoppning var att dessa skulle vara delaktiga i nya versionen. Så är inte fallet utan åter igen är det övervägande konsult- och verktygsföretag som återfinns bland författare och granskare. Itil är inte “out of the box” och kräver lika mycket insats som tidigare även om en del aktörer hävdar annat. Risken finns att konsulter enbart lyfter fram vissa delar precis som med itil v2 då mest fokus var på “service support” delen.

Itil är fortsatt bra som idébank och man ska fortfarande ha både kritiskt och analytiskt öra och öga, som i så många andra sammanhang.

Angelica Haverblad

Dela med andra:

ISACA publicerar mycket intressant material och som medlem har man fri access. Det finns också material som är tillgängligt även för icke medlemmar, som bland annat Cobit dokumentationen.

Angelica Haverblad

Dela med andra:

Itil för itils skull

Ibland blir det för stort fokus på itil, när målet och andemeningen är itil, Itil för itils egen skull helt enkelt. ”Vi vill itil” hör jag ibland och min fråga blir då vad de menar med itil. Vad är det som ska uppnås, det vill säga mål, strategi och förväntningar? Dessa frågeställningar gäller oavsett vilka ramverk eller modeller som finns på agendan. Det är inte ovanligt att det saknas mål med initiativet där någon i organisationen helt enkelt får i uppgift att ”införa itil”. Det finns inte något egentligt syfte och mål med det förutom att det verkar bra, det måste vi ha och för att ”alla andra gör det”. I organisationer där någon får i uppgift att ”införa” itil är förväntningarna ofta höga och orealistiska och uppfattningen, eller kanske önskan, att itil är något som går att ”installera” och ”införa” förekommer.

Enligt itil

”Enligt itil” och ”vi arbetar enligt itil” – det hör och läser man i många sammanhang. Frågan är vad ”enligt itil” egentligen är och innebär. Litet resonemang kring det här i form av några exempel: Om man registrerar alla incidenter i form av incidentärenden, arbetar man enligt itil då? Är det först när specifika fält finns och är ifyllda i incidentärendet som man arbetar enligt itil? Om man inte registrerar och dokumenterar ändringar, arbetar man enligt itil ändå, eftersom alla incidenter registreras? Om man inte har definierat IT-tjänster, inte formulerat servicenivåer och mäter dessa, arbetar man enligt itil med incidenthantering ändå?

En del organisationer genomför analyser för att ”jämföra sina processer mot itil”. Frågan är vad man jämför emot, vilka är egentligen kriterierna och var lägger man ribban. Det innebär att analysens omfattning och resultat beror helt på utförarens tolkning och perspektiv, varför värdet med en sådan analys kan ifrågasättas.

Det man istället i dessa sammanhang kan utgå ifrån är ISO/IEC 20000 IT Service Management, där kan man säga att man lever upp till eller inte lever upp till de krav som specificerats för att organisationen ska kvalificera sig för en ISO/IEC 20000 certifiering. Ett annat sätt är modeller för att identifiera processmognadsnivåer (bland annat Cobit), där det finns tydliga kriterier. Om man ska välja ISO/IEC 20000 eller en processmognadsmodell (eller både och) beror bland annat på ”scopet” och syftet med analysen. Och vad man menar med ”enligt itil” och itil överhuvudtaget.

Om någon arbetar eller vill arbeta ”enligt itil” säger det inte mig speciellt mycket. Termer i form av i förhållande till ISO/IEC 20000 säger mer och i termer av processmognadsnivå betydligt mer. Tala om era process- mognadsnivåer och jag vet hur ni har det, vad ni gör och inte gör.

Installera och uppgradera itil

Kan itil installeras, införas och uppgraderas? Enligt mig kan man inte det, men däremot tillämpa. I en generellt teknik fokuserad IT-bransch är det emellertid tydligen fullt möjligt. Inte minst i samband med att de nya böckerna lanserades pratades det i termer av att ”uppgradera från 2 till version 3″. Själv tycker jag att ”utgåva” är en bättre benämning än ”version” i det här sammanhanget.

Frågeställningar som ”ska vi vänta till trean kommer eller börja med tvåan?” och ”ska vi fortsätta med tvåan eller invänta trean?” får svar som ”det går bra att fortsätta installera de tidigare versionerna”. Jag tycker att det är högst märkliga frågeställningar (och svar), och påminner mer om en ny version av ett operativsystem eller en applikation. Dessa går både att installera och uppgradera och där det förs förståeliga diskussioner kring om och när man ska uppgradera och eventuellt invänta köp av ny applikation om en ny version snart ska komma.

Termer som ”installera” och ”uppgradera” förekommer sällan i samband med att organisationer ska ta fram och etablera till exempel en projektmodell. Den varken installeras eller uppgraderas, däremot
tillämpas den och förändras vid ändrade behov och krav och är någonting som kan förbättras över tiden. Det är samma sak med en ”modell” för leverans av IT-tjänster.

Itil handlar inte om itil

Frågan är vad man menar när man ”vill itil”. När det gäller projekt- modeller inför man inte PMI, PPS eller Prince2 och kommunicerar vanligen inte heller i de termerna. Man pratar om och kommunicerar i termen projektmodell. PMI handlar inte om PMI utan om en modell för att styra och leda projekt. Precis som att Itil inte handlar om itil.

Angelica Haverblad

Dela med andra: