I korthet är Itil ett ramverk som definierar ett antal processer för it-verksamheter, för att designa, produktionssätta och förvalta tillämpningar, för att ta hand om problem och för att jobba med ständiga förbättringar. Processerna bygger på många års samlade erfarenheter av vad som fungerat bra för olika it-verksamheter.
Det är en god idé att ta efter andras framgång i stället för att själv uppfinna hjulet. Standardisering gör att vi säger och menar samma sak. Härigenom undviks missförstånd och det blir enklare att avtala om vad it-verksamheten ska leverera. It-avdelningen kan då ägna sig åt att hjälpa den övriga verksamheten att leverera affärsnytta, i stället för att ständigt släcka bränder.
Farhågorna som dyker upp handlar bland annat om rädsla för förändring, ytterligare arbetsuppgifter, övervakning, ökade kostnader, krångel, stelbenthet och komplexitet.
Här märker jag att många tappar bort sig i diskussioner om vad Itil är, i stället för att diskutera vad man kan åstadkomma med Itil. I kölvattnet på nya processer simmar ofta processpoliserna som dränker oss i dokument och meningslösa detaljer, utan att ha förstått de egentliga behoven.
Att försöka införa alla Itils processer på en gång är jobbigt, dyrt och dömt att misslyckas. I stället måste man utgå ifrån verksamheten och där försöka identifiera problem som kan relateras till it, eller affärsmål som inte uppnås på grund av brister i it-verksamheten.'
Förändringar misslyckas vanligen om man inte kan troliggöra nyttan. Därför kan det vara fiffigt att först plocka några ”lågt hängande frukter” och berätta om den framgångsrika skörden. Försök alltså att identifiera problem som är kända, smärtsamma, samt möjliga att åtgärda med väl valda delar av Itil. Genomför sedan ett lyckat pilotprojekt och kommunicera framgången för att skapa sug efter mer. För att lyckas här är verksamhetskunskap, erfarenhet av processutveckling och sunt förnuft långt viktigare än detaljerade kunskaper om Itil.
Hur äter man en elefant? Man skär upp den i små bitar och börjar med de godaste. Oftast blir man mätt innan elefanten är uppäten.
Det är en god idé att ta efter andras framgång i stället för att själv uppfinna hjulet. Standardisering gör att vi säger och menar samma sak. Härigenom undviks missförstånd och det blir enklare att avtala om vad it-verksamheten ska leverera. It-avdelningen kan då ägna sig åt att hjälpa den övriga verksamheten att leverera affärsnytta, i stället för att ständigt släcka bränder.
Farhågorna som dyker upp handlar bland annat om rädsla för förändring, ytterligare arbetsuppgifter, övervakning, ökade kostnader, krångel, stelbenthet och komplexitet.
Här märker jag att många tappar bort sig i diskussioner om vad Itil är, i stället för att diskutera vad man kan åstadkomma med Itil. I kölvattnet på nya processer simmar ofta processpoliserna som dränker oss i dokument och meningslösa detaljer, utan att ha förstått de egentliga behoven.
Att försöka införa alla Itils processer på en gång är jobbigt, dyrt och dömt att misslyckas. I stället måste man utgå ifrån verksamheten och där försöka identifiera problem som kan relateras till it, eller affärsmål som inte uppnås på grund av brister i it-verksamheten.'
Förändringar misslyckas vanligen om man inte kan troliggöra nyttan. Därför kan det vara fiffigt att först plocka några ”lågt hängande frukter” och berätta om den framgångsrika skörden. Försök alltså att identifiera problem som är kända, smärtsamma, samt möjliga att åtgärda med väl valda delar av Itil. Genomför sedan ett lyckat pilotprojekt och kommunicera framgången för att skapa sug efter mer. För att lyckas här är verksamhetskunskap, erfarenhet av processutveckling och sunt förnuft långt viktigare än detaljerade kunskaper om Itil.
Hur äter man en elefant? Man skär upp den i små bitar och börjar med de godaste. Oftast blir man mätt innan elefanten är uppäten.
(
Den här artikeln har 0 kommentarer:
