Införande av nya arbetssätt - hur hanterar man bieffekterna av det?

AlmostAsleep AB har under sin VD:s och CIO:s ledning i stor enighet fattat beslut att införa ett nytt arbetssätt på sin IT-avdelning! Det här blir succé! Inte bara ledande personer och nästan alla andra på IT-avdelningen. Denna gång även den normalt något IT-frånvända verksamhetssidan är eniga om att detta är vägen framåt. Projekt har startats med upphandling av tjänster och produkter. Man har också investerat i utbildning i nya system och dessutom nya processer. 

Men så sakteliga börjar det gå upp för några att detta faktiskt kommer att börja påverka deras vardag och invanda mönster. Insikten i att morgondagen (bokstavligt talat!) kommer att se annorlunda ut börjar sätta sig i magen och många frågor börjar ställas. Ett veritabelt Shakespeare-drama tar sin början!

Det som ska genomföras har redan motiverats teoretiskt och precis som i de flesta företag går det relativt lätt även för AlmostAsleep AB att få acceptans för förbättrade arbetssätt. Det CIO:n inte har förutsett är att konsekvenserna av en förändring av arbetssätt innebär också en mer genomgripande förändring för de människor som direkt eller indirekt berörs av den. Förändringen på IT-avdelningen sätter fart på krafter som slår an djupt nedärvda sociala behov och förmågan att hantera dessa kan avgöra i vilken utsträckning förändringen lyckas eller ej.
När man gör en organisationsförändring kommer den i de flesta fall påverka någon eller alla av:

  • Ledning och Styrning – Nya arbetssätt kan medföra att maktpositioner förändras. En person som tidigare varit en nyckelspelare vid beslutsfattande kan få sitt ansvar halverat. För AlmostAsleep AB:s chefsarkitekt leder den nya rollen till att hennes tidigare mandat plötsligt delas upp på två där en ny person med fokus på digitalisering anställs, hon får ta ansvar för legacy-systemen och en ny person anställs som chefsarkitekt för att hålla samman.
  • Ledarskap – Ett nytt arbetssätt innebär många gånger att ett nytt ledarskap krävs. AlmostAsleep AB:s huvudsaklige tekniskt lösningsansvarige har byggt en lång karriär på bolaget på stor insikt i den tekniska plattformen och förmågan att driva både förvaltning och nyutveckling på legacy-systemen. Nu förändras i ett slag arbetsuppgiften till att leda sin gruppering i förflyttningen från ett ansvar i att bygga tekniska lösningar till att vara ansvariga för att kravställa och följa upp leverantören för den tilltänkta outsource:ade leveransen.
  • Kompetens – Den tid vi lever i ställer historiskt höga krav på snabb kompetensanpassning för att motsvara företagens kontinuerligt skiftande behov. På AlmostAsleep AB finns t ex Lasse som precis överlevt småbarnsåren, men inte helt hängt med i teknikutvecklingen under tiden. Utvecklingen har möjliggjort för verksamhetssidan att gå direkt till leverantören utan IT som mellanhand. Lena å andra sidan har ytterligare några år på CV:t och har för länge sen slutat ”gå på kurser som ändå bara blir ytterligare en pärm som står och dammar i hyllan”. De är båda exempel på bristande förmåga och vilja att lära sig nya tekniker och kanske helt kunna skifta arbetsområden.
Jag tror inte att något av detta är nytt för någon, men jag förvånas om och om igen över att så få organisationer väljer att på riktigt proaktivt ta tag i frågan och planera för dess genomförande då effekterna av ett misslyckat hanterande av detta kan vara förödande för både den framtida förändringen, men kanske även för andra delar av organisationen.

Hur ska man då angripa detta? Vad är det för frågeställningar man står inför? 

  • Hur förändra ansvarsförhållanden och maktpositioner för personer utan att motverka förändringsviljan?
  • Hur möjliggör man både formellt och informellt ledarskap som kan driva förändringen mot målet?
  • Hur säkerställa kompetenshöjningen men också den oundvikliga frågan om hur man hanterar den nuvarande personalen som kanske inte varken vill eller kan möta de nya kompetensbehoven?
Min bild av detta är att faktiskt inse att detta är frågeställningar som oundvikligen kommer att behöva hanteras. En annan aspekt är att också hantera det på ett strukturerat sätt – även om det är ”ostrukturerad materia” (=människor) som behöver hanteras. Verktygen för detta är Analys och planering, Ledarskap och Mod.
  • Analys och planering - Gör en analys av nuläge och önskat läge som omfattar var förändringen av beslutsmandat kommer ske, vilket kompetensbehov och kompetensöverskott man kommer att ha samt vilka nuvarande personer och roller som kommer att vara nyckelroller både under förändringen och efter genomförandet.
  • Ledarskap - Det kommer att vara många utmaningar som kommer ställa krav på tydligt ledarskap i hantering av missnöje och motstånd, men kan också uppstå i mer formella chefsuppgifter som personalavveckling och konflikthantering. Högre chefer och ledning behöver också skapa arenor för underställda chefer och informella ledare att agera inom trots att de kan vara mer utsatta när misstag görs som en följd av en ny och delvis okänd miljö.
  • Mod - Slutligen och kanske en basplatta för hela förändringen: Mod. Vi har alla sett dessa situationer i större och mindre utsträckning. Att gå igenom en sån fas med ett realiserat resultat, men förhoppningsvis också en positiv organisation kräver styrka, uthållighet och som sagt, mod.
Naturligtvis är detta en väldigt övergripande betraktelse, men jag tror att många med mig – både som genomförande konsulter och chefer och ledare i en organisation – kan dela huvuddragen i den. Och även om det är svåra och stora saker så inspirerar det i alla fall mig dagligen att försöka bemästra Shakespeare-spektaklet samtidigt som jag stöttar bolag i att arbeta bättre och smartare.

Här hittar du Informators utbildningar inom IT, projektledning och ledarskap.


 
Christian Wahlström är senior projekt- och förändringsledare hos Olingo samt kursledare. 

Munnen säger Agil – hjärnan säger Stabil

Under århundraden har människan strävat efter förbättringar av och i sin omgivning. Samtidigt är människan av sitt genetiska ursprung präglad att inte vilja förändras.

Vi har nedärvt att förändringar belastar energiförråden. Inte bara fysisk energi utan även mental energi. Den insikten ligger djupt rotat i vårt medvetande. Att göra som man alltid gjort är mycket energisnålt i jämförelse med att förändra eller lära sig på nytt. Det är därför våra hjärnor i regel reagerar negativt på förändring. Vi vill inte förändra oss men det paradoxala är att vi vill att andra ska göra det.

Vi läser i media dagligen om att vi vill få saker utförda snabbare och få leveranser oftare. Vi ropar alla efter agila arbetssätt. När det gäller systemutveckling är detta en regel. När det gäller tjänsteutveckling vanligt. Men hur är det när det gäller verksamhetsutveckling? Kan vi utveckla förmågan att förändra vår verksamhet snabbare? Kan vi bli agila här också? Hur kan vi arbeta med att ändra människors vanor och arbetssätt agilt? Vad säger vår hjärna om vi inför agil verksamhetsutveckling? Förmodligen nej, aj, och stop, om vi gör fel. Förmodligen ja, ja och ja om vi gör rätt.

Jag tror att vi absolut kan utveckla verksamheter agilt. Det kommer att vara nödvändigt för att vara konkurrenskraftig och en förutsättning för att kunna attrahera duktiga medarbetare. Nyckeln är att skapa ett engagemang och en trygghet i förändringarna. Att bygga på vilja, nyttor, gemensamma värderingar och vision. Man behöver också bygga in i sin kultur, och i var och ens medvetande, att förändringar är bra och att det är nödvändigt att utmana sitt sätt att arbeta.

Idag råder det ingen brist på ramverk, modeller och metoder för att arbeta med förändringsledning, processutveckling, effektivisering och lärande team. Kunskap om dessa är naturligtvis viktigt, och skapar en bra grund för agil verksamhetsutveckling. Det som är än mer viktigt är istället att hitta den takt verksamheten är mogen att ta emot förändringar i, för att de ska bli varaktiga och ge önskad effekt. Och att successivt öka den takten. Det agila handlar om att göra små justeringar ofta, följa upp resultatet och korrigera. Mer pull än push.

Traditionellt har vi utvecklat våra verksamheter genom stora omorganisationer och andra strukturförändringar som krävt mycket initialt arbete och en massiv förankringsprocess för att skapa acceptans. När den nya organisationen är operativ är den troligtvis till vissa delar redan föråldrad.

En sak som ibland slår mig är att många organisationer har hela avdelningar för att förvalta sina tillgångar. Ekonomiavdelning, HR-avdelning, upphandlingsavdelning och säkerhetsavdelning. Det är däremot ganska ovanligt att man har en avdelning som arbetar med metod-, process- och verksamhetsutveckling. Verksamhetsutvecklingen är ofta begränsad till vad ledningsgrupper mäktar med att genomföra.

Verksamhetsutvecklingen behöver lämna ledningsnivån och delegeras till den operativa verksamheten. Den operativa verksamheten behöver ta emot och acceptera ansvaret att ständigt utföra förbättringar i linje med organisationens vision, strategi och som är värdeskapande. Ledande personal behöver skapa engagemang och en vilja att hitta fel och förbättringsområden. Alltid belöna när fel upptäcks. Frigöra tid för korrigering och hitta rätt takt i förändringsarbetet.

Vikla fle grö du igad?


Ragnar Eliasson arbetar på Olingo Consulting som verksamhetsutvecklare och är ackrediterad kursledare inom ITIL hos Informator. Han använder en blandning av ramverk, modeller och metoder i sina uppdrag. Exempel på det är förändringsledning genom ADKAR, Service Management med stöd av ITIL samt kulturförändring och optimering genom Lean for Services.

Fördjupning i området hos Informator:

ITIL® Lifecycle - Continual Service Improvements
Lean Agile Change Management

Införande av nya arbetssätt – Hur hanterar man bieffekterna av det?

AlmostAsleep AB har under sin VD:s och CIO:s ledning i stor enighet fattat beslut att införa ett nytt arbetssätt på sin IT-avdelning! Det här blir succé! Inte bara ledande personer och nästan alla andra på IT-avdelningen. Denna gång även den normalt något IT-frånvända verksamhetssidan är eniga om att detta är vägen framåt. Projekt har startats med upphandling av tjänster och produkter. Man har också investerat i utbildning i nya system och dessutom nya processer.

Men så sakteliga börjar det gå upp för några att detta faktiskt kommer att börja påverka deras vardag och invanda mönster. Insikten i att morgondagen (bokstavligt talat!) kommer att se annorlunda ut börjar sätta sig i magen och många frågor börjar ställas. Ett veritabelt Shakespeare-drama tar sin början!

Det som ska genomföras har redan motiverats teoretiskt och precis som i de flesta företag går det relativt lätt även för AlmostAsleep AB att få acceptans för förbättrade arbetssätt. Det CIO:n inte har förutsett är att konsekvenserna av en förändring av arbetssätt innebär också en mer genomgripande förändring för de människor som direkt eller indirekt berörs av den. Förändringen på IT-avdelningen sätter fart på krafter som slår an djupt nedärvda sociala behov och förmågan att hantera dessa kan avgöra i vilken utsträckning förändringen lyckas eller ej.
När man gör en organisationsförändring kommer den i de flesta fall påverka någon eller alla av:
  • Ledning och Styrning – Nya arbetssätt kan medföra att maktpositioner förändras. En person som tidigare varit en nyckelspelare vid beslutsfattande kan få sitt ansvar halverat. För AlmostAsleep AB:s chefsarkitekt leder den nya rollen till att hennes tidigare mandat plötsligt delas upp på två där en ny person med fokus på digitalisering anställs, hon får ta ansvar för legacy-systemen och en ny person anställs som chefsarkitekt för att hålla samman.
  • Ledarskap – Ett nytt arbetssätt innebär många gånger att ett nytt ledarskap krävs. AlmostAsleep AB:s huvudsaklige tekniskt lösningsansvarige har byggt en lång karriär på bolaget på stor insikt i den tekniska plattformen och förmågan att driva både förvaltning och nyutveckling på legacy-systemen. Nu förändras i ett slag arbetsuppgiften till att leda sin gruppering i förflyttningen från ett ansvar i att bygga tekniska lösningar till att vara ansvariga för att kravställa och följa upp leverantören för den tilltänkta outsource:ade leveransen.
  • Kompetens – Den tid vi lever i ställer historiskt höga krav på snabb kompetensanpassning för att motsvara företagens kontinuerligt skiftande behov. På AlmostAsleep AB finns t ex Lasse som precis överlevt småbarnsåren, men inte helt hängt med i teknikutvecklingen under tiden. Utvecklingen har möjliggjort för verksamhetssidan att gå direkt till leverantören utan IT som mellanhand. Lena å andra sidan har ytterligare några år på CV:t och har för länge sen slutat ”gå på kurser som ändå bara blir ytterligare en pärm som står och dammar i hyllan”. De är båda exempel på bristande förmåga och vilja att lära sig nya tekniker och kanske helt kunna skifta arbetsområden.
Jag tror inte att något av detta är nytt för någon, men jag förvånas om och om igen över att så få organisationer väljer att på riktigt proaktivt ta tag i frågan och planera för dess genomförande då effekterna av ett misslyckat hanterande av detta kan vara förödande för både den framtida förändringen, men kanske även för andra delar av organisationen.

Hur ska man då angripa detta? Vad är det för frågeställningar man står inför?
  • Hur förändra ansvarsförhållanden och maktpositioner för personer utan att motverka förändringsviljan?
  • Hur möjliggör man både formellt och informellt ledarskap som kan driva förändringen mot målet?
  • Hur säkerställa kompetenshöjningen men också den oundvikliga frågan om hur man hanterar den nuvarande personalen som kanske inte varken vill eller kan möta de nya kompetensbehoven?
Min bild av detta är att faktiskt inse att detta är frågeställningar som oundvikligen kommer att behöva hanteras. En annan aspekt är att också hantera det på ett strukturerat sätt – även om det är ”ostrukturerad materia” (=människor) som behöver hanteras. Verktygen för detta är Analys och planering, Ledarskap och Mod.
  • Analys och planering - Gör en analys av nuläge och önskat läge som omfattar var förändringen av beslutsmandat kommer ske, vilket kompetensbehov och kompetensöverskott man kommer att ha samt vilka nuvarande personer och roller som kommer att vara nyckelroller både under förändringen och efter genomförandet.
  • Ledarskap - Det kommer att vara många utmaningar som kommer ställa krav på tydligt ledarskap i hantering av missnöje och motstånd, men kan också uppstå i mer formella chefsuppgifter som personalavveckling och konflikthantering. Högre chefer och ledning behöver också skapa arenor för underställda chefer och informella ledare att agera inom trots att de kan vara mer utsatta när misstag görs som en följd av en ny och delvis okänd miljö.
  • Mod - Slutligen och kanske en basplatta för hela förändringen: Mod. Vi har alla sett dessa situationer i större och mindre utsträckning. Att gå igenom en sån fas med ett realiserat resultat, men förhoppningsvis också en positiv organisation kräver styrka, uthållighet och som sagt, mod.
Naturligtvis är detta en väldigt övergripande betraktelse, men jag tror att många med mig – både som genomförande konsulter och chefer och ledare i en organisation – kan dela huvuddragen i den. Och även om det är svåra och stora saker så inspirerar det i alla fall mig dagligen att försöka bemästra Shakespeare-spektaklet samtidigt som jag stöttar bolag i att arbeta bättre och smartare.

Här hittar du Informators utbildningar inom IT, projektledning och ledarskap.

 Christian Wahlström är senior projekt- och förändringsledare hos Olingo samt kursledare. 

ITSM-verktyg - do's and don'ts

Jag har ofta fått frågor som ”Finns det ett verktyg som kan lösa det här?” ”Behöver vi verkligen ett verktyg till?” ”Vilket verktyg är bäst?” Jag har inte alla svaren, men lite erfarenhet kan jag dela.

Till att börja med tänkte jag definiera vad jag menar med ITSM-verktyg. Oavsett var i en IT-organisation man arbetar behöver man stödverktyg, oftast applikationer, som hjälper till i IT-leveransen. Det kan vara verktyg som används i samband med utvecklingen av IT-tjänster eller verktyg för att hantera drift och support. De verktyg som stödjer tjänsteleveransen kan vi kalla ITSM-verktyg. Exempel på ITSM-verktyg kan vara ärendehanteringsverktyg, konfigurationsdatabaser, självhjälpsportaler.

Om vi börjar med frågan varför man behöver ett verktyg? Oftast när verktygsstöd kommer upp på tapeten så beror det på att något i och runt IT-leveransen har vuxit ett eller flera steg på kort tid. Exempelvis kan mängden kunder ökat och därigenom generera fler ärenden. Effekten av detta yttrar sig oftast i växtvärk med symptom som tappade eller glömda bollar, fel innehåll i leveransen, dålig kvalité i leveransen, stressad personal och missnöjda kunder.

Så hur gör man när symptomen av växtvärk blir för jobbig? Här är några exempel på frågeställningar som man kan använda sig av när man utvärderar verktygsstöd.


  • Vad behöver vi verktygsstöd till?
  • Finns det något befintligt verktyg i vår organisation som faktiskt kan hantera vårt behov? 
  • Kan vi ersätta något eller några befintliga verktyg (läs Excel-ark)med ett nytt verktyg?
  • Finns det fler i vår organisation som skulle ha nytta av den funktionalitet som vi söker?

Som i de flesta fall när man genomför en större förändring bör man ta fram ett bra beslutsunderlag och det gäller även vid verktygsval. Själva upphandlingen av verktyg är ett eget kapitel och jag tänkte återkomma till den i ett senare blogg-inlägg.

Så vad är då viktigast när vi tittar på själva verktyget? Verktygsfunktionalitet eller verksamhetsstöd?

Jag har sett många som faller i fällan att basera valet på vilket verktyg som har mest avancerad och omfattande funktionalitet. Risken är att man skjuter över ribban och får betala för funktionalitet som organisationen inte är mogen att dra nytta av. Försök lyfta blicken från funktionaliteten och istället fokusera på verktygets förmåga att stötta just de verksamhetsprocesser som behöver stöd.

Ett annat tips är att ta fram en tydlig roadmap för verktyget och dess funktionalitet och staka ut vägen i etapper. Prioritera och avgränsa med hänsyn till önskad effekt.

Själva införandet av ett nytt verktyg kan man göra på mer eller mindre bra sätt. Det är oftast lättast att fokusera på att få igång tekniken, men man bör också tänka på nuvarande arbetsprocesser samt personalens förutsättningar. Processen behöver ibland uppdateras då verktyget gör att vissa processteg och rutiner inte längre behövs eller görs på ett enklare sätt tack vare verktyget, jobba iterativt med verktyg-/processutvecklingen.

Utbildningen av verktygsanvändare är central för att få ut fullt värde av en verktygsinvestering. Det är lämpligt att dela upp utbildningsinsatsen i dagliganvändare och sällananvändare, för att kunna fokusera på rätt detaljer och hålla rätt tempo. Ta fram scenarion som stämmer med de processer som verktyget skall stötta och genomför små rollspel hellre än att gå igenom ”tryck här och sen tryck där”. Det får man ändå på köpet. Se till att användarna förstår i vilket sammanhang verktyget kommer in. Då blir det lättare att förstå funktionaliteten i verktyget. Passa gärna på att ta ett omtag och utbilda i processerna samtidigt som det nya verktyget införs.

Ett nytt verktyg behöver även förvaltas och utvecklas. Se till att få med utvecklingen av dessa områden vid etableringen. De personer som skall jobba i verktyget måste ha ett enkelt sätt att framföra åsikter och tankar som är relaterade till verktygsutveckling/förbättring. En tydlig mottagare och ägare måste utses samt en process för förbättringsarbetet bör etableras eller vidareutvecklas för att omfatta ett nytt verktyg.

Summa summarum - tänk efter före och se till att ha svar på dessa frågor:

Varför behöver vi ett verktyg? Hur ser vår Roadmap ut för verktyget? Hur inför vi verktyget? Hur förvaltar och förbättrar vi verktygsstödet?


Thomas Godawszky, utbildare inom ITIL hos Informator och
verksamhetsutvecklare inom ITSM på Olingo.

ITIL Practitioner, ny ITIL-kurs på gång - vad är syftet och vad händer med ITIL-ramverket?

Axelos, som äger varumärket ITIL, har aviserat en ny kurs som ska heta ITIL Practitioner. Den kommer bli tillgänglig som kurs och certifiering i slutet av 2015. Än så länge finns ingen syllabus (innehållsförteckning) framtagen för kursen men Axelos har givit en ungefärlig beskrivning av syfte och innehåll.

ITIL

Kursens syfte är att ge deltagarna en god förståelse för vad som krävs för att få ITIL att landa bra inom organisationen. Den fokuserar alltså inte på ITIL-processerna i sig, utan är snarare en kurs i förändringsledning kopplat till ITIL. Det är utlovat att det ska finnas delar som beskriver hur ITIL kan samverka med andra modeller och ramverk som t.ex. Lean, devops, cloud-tjänster, agile och SIAM.

Det är viktigt att påpeka att kursen inte ersätter befintliga fördjupningskurser i ITIL-pyramiden. Den kommer utgöra ett komplement där en avklarad certifiering ger "poäng", för den som vill uppnå 'ITIL Expert'-nivå, på motsvarande sätt som nuvarande fördjupningskurser.

ITIL-pyramiden, dvs den kurs/certifieringspyramid, som beskriver hur en person kan ta sig från Foundation-nivå till Expert-nivå har fått utstå en del kritik i branschen. En uppfattning är att det finns för många fördjupningskurser att välja på samt att det är otydligt vilken eller vilka fördjupningskurser, baserat på roll i organisation, som är mest lämpliga.

Axelos har i dagsläget ingen officiell plan för vad som ska hända med kursutbudet på sikt. Det finns heller inte någon officiell information om när nästa version av ITIL kommer. Eller hur den kommer paketeras. Det som är helt klart är att de certifieringar som finns på marknaden idag kommer att vara värdefulla även framöver samt att den kunskap en fördjupningskurs i ITIL ger är fortsatt relevant.

ITIL-grundkursen "ITIL Foundation" hittar du här.
Samtliga ITIL-kurser hos Informator hittar du här.

Har du frågor om ITIL eller vad som händer i ITSM-branschen får du gärna lämna en kommentar nedan eller höra av dig.

// Ola Källgården
Ola är ITIL-utbildare hos Informator.
Han är även VD, verksamhetskonsult
och en av grundarna till Olingo.

ITIL - bara en fluga

Årets händelse inom IT Service Management gick av stapeln i veckan. En tvådagars konferens som anordnas av intresseföreningen itSMf (IT Service Management forum). Två dagar fullmatade med föreläsningar, fallstudier, framgångssagor och statistik som påvisar värdet av att effektivisera tjänsteleveransen med ITIL som verktyg. Mest applåder av alla fick det företag som vågade bjuda på sina motgångar. Vi i publiken fick ta del av försenade processetableringar, kraschade system, misslyckade leveranser och svikna förhoppningar.  Igenkänningsfaktorn var stor. Vilket företag det var? Systembolaget.

Har ITIL haft sin peak var en av frågorna som bubblade hos branschfolket. Är ITIL, likt internet, en fluga som är på väg att flyga bort mot horisonten?

Det totala antal personer som certifierierar sig inom ITIL planar ut. Trots det är min analys att ITIL har aldrig mått bättre. Den senaste versionen av ITIL har funnits i fem år och det vore märkligt om det inte uppstår en mättnad i antalet certifieringar. En stor del av målgruppen har ju redan certifierat sig. IT-branschen börjar mogna. Att intresset, trots detta, är fortsatt stort är ett bevis för att företagen fortsätter att jobba med ITIL som verktyg. Det är inte längre en fråga för IT-avdelningen OM man ska använda ITIL, endast en fråga om HUR. Att ha (minst) en ITIL-certifiering på CVn är en självklar merit.

Min profetia är att nästa stora erövring för ITIL-ramverket, nu när IT-avdelningarna sitter stadigt i båten, är andra delar av organisationen. Även avdelningar som HR och ekonomi har behov av ett bra ramverk för att jobba med effektiv tjänsteleverans.

Skulle vara intressant att höra vad du tror. Skriv gärna en kommentar.   

Ola

PS. Trots misslyckanden på vägen kunde Systembolaget visa att det viktigaste mätetalet av alla, kundnöjdheten, pekade stadigt uppåt.   

Finns det ett värde i att folk inte ska förstå?

När jag först kom i kontakt med termen IT Service Management (ITSM) hade jag ingen aning om vad det handlade om. Jag hade precis blivit anställd som konsult på ett bolag som fokuserade på ITIL. Jag hade en vag uppfattning om vad ITIL var men hade aldrig hört talas om ITSM. Det tog mig minst ett år innan jag hade en någorlunda tydlig uppfattning om vad som menades med ITSM. Under den tiden hade jag hållit kurser i ämnet. Inte ens idag, nio år senare, är jag helt säker på innebörden av termen ITSM. Det verkar nämligen råda lite olika uppfattningar om det, även hos oss (självutnämnda) experter.
Vid en handuppräckning på vårt senaste ITIL-frukostseminarium var det tre (3) personer av totalt 30 som hade hört talas om ITSM.
Varför fortsätter vi då (=branschen) använda termen ITSM i alla möjliga sammanhang, inklusive marknadsföring!?

Finns det ett värde i att målgruppen inte ska förstå?!

Eller är vi så insnöade i vår ITSM-värld att vi tappat kollen på verkligheten?

Jag hoppas och tror på det senare. Det är så lätt att glömma hur det är att inte kunna. När man väl kan. Jag påminns om det i alla möjliga sammanhang. T.ex. igår kväll när grannpojken Erik skulle lära mig cykla på bakhjulet, samtidigt som jag försökte lära min snart 3-årige son åka sparkcykel. Erik såg inte svårigheten i att cykla på bakhjulet. Det gjorde jag.
Den mest utmärkande egenskapen för en duktig lärare är förmågan att minnas hur det är att inte kunna.

Nästa vecka går itSMFs vårkonferens av stapeln. itSMF är en ideell förening som syftar till att värna medlemmarnas intresse genom att sprida och dela kunskap om ITSM. Vårkonferensen är årets stora händelse (läs mer på http://www.itsmf.se/public/conferenceSpring2013/). Programmet är packat med intressanta föredrag och uppträdanden men tillströmningen av deltagare har varit under förväntan.
I itSMFs styrelsen har vi återkommande diskussioner kring hur vi ska utöka antalet medlemmar.  Ett första steg är att få potentiella medlemmar att förstå, på riktigt, vad ITSM är och vad det skapar för värde.


Vad innebär då termen ITSM? Ja, som sagt, helt säker är jag ju inte men vi gör ett försök att förklara i våra kurser och frukostseminarium.  Välkommen dit!



Till Informators ITIL-utbildningar 

Boka plats i tid på kostnadsfria seminarier!
ITIL-frukost

Liten kurs i kompetensstrategi – del 3

Välkomna till tredje och sista delen i ”kursen”. I detta inlägg bockar vi av den sista punkten på listan och knyter ihop säcken. 

1. Varför är det inte fler organisationer som har en tydlig bild av nuvarande och framtida kompetensbehov?
2. Varför är det inte fler organisationer som har en uppdaterad kompetensinventering?
3. Varför är det inte fler organisationer som kombinerar olika typer av utbildningsmetoder?
4. Varför är det inte fler organisationer som mäter och följer upp värdet av utbildningsinsatser?

5. Varför är det inte fler organisationer som ser till att kombinera kompetenshöjning med värdeskapande insatser på hemmaplan?

5. Varför är det inte fler organisationer som ser till att kombinera kompetenshöjning med värdeskapande insatser på hemmaplan?
Vi har konstaterat att det finns goda skäl att kombinera olika utbildningsmetoder för att nå bästa utbildningseffekt. Såväl pedagogiska som ekonomiska. På motsvarande sätt känns det uppenbart att en utbildning bör kombineras med praktisk tillämpning för att få bästa effekt. Varför är det då inte fler organisationer som väver samman praktiskt arbete med en utbildning? Jag tror det hänger ihop med det vi lärt oss från barnsben. I skolan lär man sig och på arbetsplatsen arbetar man. För femtio år sedan kanske det resonemanget höll men knappast idag. I dagens kunskapssamhälle behöver både organisationer och dess anställda utbilda sig kontinuerligt, och ibland omskola sig helt, för att möta en värld i allt snabbare förändring. Av ekonomiska och praktiska skäl behöver en större del av utbildningen ske på arbetsplatsen och vävas ihop med de dagliga arbetsuppgifterna.
Vad ska man göra då?
Grunden är att ta fram en kompetensstrategi och tillhörande plan, dvs tänka till kring vilka kompetenser organisationen behöver och se till att det finns en plan för realisering. Det bör vara tydligt i planen hur kompetensbehoven är kopplade till organisationens operativa behov. Vi tar ett exempel. 
Om behovet är att bli  bättre på leverantörsuppföljning så bör utbildningsinsatsen kopplas till faktiska förbättringsbehov inom just det området, t.ex. att i samband med utbildningsinsatsen ta fram mätetal och rapporter som är relevanta för den specifika organisationens leverantörsuppföljning. 
Detta är relativt enkelt att åstadkomma om utbildningsinsatsen är skräddarsydd för den egna organisationen men går även att åstadkomma vid punktinsatser för en anställd. Oavsett om utbildningen är för en intern gruppering eller enskild person krävs ofta uppföljning och stöd för att säkerställa att det faktiska värdet realiseras. Detta stöd kan vara svårt att åstadkomma internt och då kan det vara en bra investering att komplettera utbildningsinsatsen med konsult/mentor-stöd.
Sammanfattningsvis kan vi konstatera att en kombination av utbildningsinsats och praktik i den egna organisationen slår två flugor i en smäll. Dels värdeskapande arbete för organisationen men även förstärkt lärande genom att teorin får praktiseras – en av grundpelarna för ett långsiktigt lärande.
Med det sagt är mini-kursen avklarad. Jag hoppas att du har fått ut något av den och att den sått ett frö till en mer genomtänkt utbildningsstrategi.
Du får jättegärna höra av dig med  dina synpunkter och erfarenheter. Var inte rädd för att ifrågasätta eller argumentera. Det är så vi lär oss ännu mer!

Jag nås lättast på ola.kallgarden@olingo.se men det går naturligtvis även att kommentera på bloggen!  

Liten kurs i kompetensstrategi - del 2

Välkomna till andra delen i ”kursen”. I första delen klarade vi av de två första frågeställningarna och i denna del ska vi ta oss an ytterligare två.
  
1.       Varför är det inte fler organisationer som har en tydlig bild av nuvarande och framtida kompetensbehov?
2.       Varför är det inte fler organisationer som har en uppdaterad kompetensinventering?
3.       Varför är det inte fler organisationer som kombinerar olika typer av utbildningsmetoder?
4.       Varför är det inte fler organisationer som mäter och följer upp värdet av utbildningsinsatser?
5.       Varför är det inte fler organisationer som ser till att kombinera kompetenshöjning med värdeskapande insatser på hemmaplan?

3. Varför är det inte fler organisationer som kombinerar olika typer av utbildningsmetoder?
Det finns olika sätt att ta till sig kunskap. På individnivå föredrar vi olika typer av inlärningsstilar som t.ex. auditiv, kinestetisk samt visuell. Olika inlärningsstilar kan kopplas till olika utbildningsmetoder. Detta har det forskats en hel del kring. Om man generaliserar forskningen en aning kan man konstatera att man gör bäst i att kombinera olika utbildningsmetoder.  Tydligt från forskningen är även att den bästa inlärningseffekten uppnås om eleven får chansen att praktisera teorin.  
Med dagens pedagogiska kunskap och tekniska förutsättningar finns det inga teoretiska gränser för vad som går att åstadkomma i utbildningsväg. Det är fantasin och plånboken som sätter gränserna. Och vanan. Jag vågar påstå att det är vanan som gör att de flesta organisationer lägger en betydligt större del av utbildningsbudgeten på klassiska kurser än alternativa utbildningsmetoder. Det känns tryggast så.  
Vad ska man göra då?
 Till att börja med ska man ta fram en utbildningsstrategi och tillhörande kompetensplan (se del 1).  Utifrån de identifierade kompetensbehoven ska man se över de utbildningsalternativ som marknaden erbjuder. Både på grupp- och individnivå. Det troliga är att en mix av utbildningsmetoder ger den bästa effekten. Se över hur klassiska kurser kan varvas med andra metoder och medier. Se till att inte missa praktiserandet. Våga testa simuleringar, e-learning och scenariobaserade övningar.
Kurser kan även kombineras med expertstöd så att kompetensutveckling kan kombineras med värdeskapande aktiviteter på hemmaplan (se mer på punkt 5 i nästa inlägg).    

4. Varför är det inte fler organisationer som mäter och följer upp värdet av utbildningsinsatser?
Om man nu lägger ner en ansenlig mängd pengar på att utbilda sin organisation, är det då inte rimligt att följa upp värdet? Självklart borde man det. Problemet är att det är svårt att på ett objektivt sätt följa upp utbildningsinsatser.
Vad ska man göra då?
Det bästa är att använda sig av en etablerad modell som t.ex. Kirkpatrick. På det sättet får man åtminstone någonting att hålla sig i vid uppföljningen. Kirkpatrick delar in uppföljningen i fyra delar:
·         Reaktion – Individens subjektiva reaktion till utbildningsinsatsen
·         Lärande – Mätbart resultat för individen, t.ex. testresultat och certifieringar
·         Beteende – Hur har utbildningen förändrat individens och/eller gruppens beteende
·         Resultat – Hur har förändringen i beteende hos individ och grupp påverkat organisationens resultat
De första två delarna, reaktion och lärande, är lätta att mäta med hjälp av enkäter och tester. De två sistnämnda är betydligt svårare men Kirkpatrick ger en del tips på hur man kan gå tillväga.

Så ja, då var del 2 avklarad. I nästa inlägg knyter jag ihop säcken!

Liten kurs i kompetensstrategi - del 1

Liten kurs i kompetensstrategi - del 1

I förra inlägget påstod jag att många IT-organisationer saknar en tydlig kompetensstrategi och/eller plan för att säkerställa rätt kompetens.  Sammanfattningsvis ställde jag följande frågor:

1.       Varför är det inte fler organisationer som har en tydlig bild av nuvarande och framtida kompetensbehov?
2.       Varför är det inte fler organisationer som har en uppdaterad kompetensinventering?
3.       Varför är det inte fler organisationer som kombinerar olika typer av utbildningsmetoder?
4.       Varför är det inte fler organisationer som mäter och följer upp värdet av utbildningsinsatser?
5.       Varför är det inte fler organisationer som ser till att kombinera kompetenshöjning med värdeskapande insatser på hemmaplan?
För mig är det lite obegripligt att det ser ut som det gör eftersom det inte är svårt att få till. Faktiskt.
Jag vill även vara tydlig med att det självklart finns organisationer som har en strategisk, men ändå pragmatisk, syn på kompetensutveckling. Jag tänkte dela med mig av erfarenheter från dessa organisationer och samtidigt bemöta frågorna ovan. Det blir totalt tre delar som blir utspridda över veckan som kommer.


1.       Varför är det inte fler organisationer som har en tydlig bild av nuvarande och framtida kompetensbehov?
Det finns flera anledningar och ursäkter. Den vanligaste anledningen är att många IT-organisationer har en otydlig bild av framtida kundkrav, samt genomgår så mycket förändringar, att man inte kan eller orkar ta tag i kompetensplaneringen. De nuvarande behoven vill man inte få konkretiserade eftersom det finns risk att de förtydligar att man sitter med fel kompetens. Man ställs då inför en jobbig situation att byta ut personal och/eller göra en kompetensomläggning modell större. Då kan det vara skönare, åtminstone på kort sikt, att sticka huvudet i sanden.  Ungefär som att kissa i byxorna.
Vad ska man då göra?
Framför allt gäller det för IT att förstå sin roll i företagets, eller kundens, utveckling. Hur ser strategin ut för företaget/kunden och vilken position har IT-organisationen i företaget som helhet? Det är självklart även viktigt för IT att hålla sig uppdaterad kring nymodigheter i IT-världen så att man ligger steget före och kan föreslå nya och bättre tjänster. Helst innan kunden själv föreslår det. Det var inte mycket snack om molntjänster för tio år sedan…
Ett steg i att bättre förstå de nuvarande behoven är att först skaffa sig en tydlig bild av vilka IT-tjänster man faktiskt levererar. Det kan tyckas självklart men det är häpnadsväckande många IT-organisationer som fortfarande inte har en tydlig bild av sin egen tjänsteleverans. När man vet vilka tjänster som levereras är det lättare att koppla dessa till leveransprocesser och kompetensbehov.  

2.       Varför är det inte fler organisationer som har en uppdaterad kompetensinventering?
Den elaka gissningen är att man är rädd för att få reda på hur det verkligen ligger till. Den lite mindre elaka gissningen är att man tror sig ha ”rätt bra koll” på vad personalen kan. En tredje gissning är att det saknas en effektiv process för att hålla informationen uppdaterad.  Vad ska man då göra?
Man ska se till att ha en fungerande process och verktyg för att dokumentera kompetens. De flesta organisationer har mer eller mindre utnyttjade verktyg för detta (kolla med HR!). Oftast är dessa ganska enkla och möjliggör för den anställde och/eller chefen att fylla i enskilda individers kompetensnivåer inom ett antal områden. Nyckeln är förstås att identifiera och sätta upp de områden som kompetensnivån ska jämföras emot, samt ha en tydlig process för när och hur kompetensen ska dokumenteras.
För de områden där den egna personalen saknar nödvändig kompetens får man ta sig en funderare. Kan denna kompetens enkelt ”sourcas” från annat håll, t.ex. underleverantörer eller konsulter? Om svaret är nej får man överväga rekrytering som alternativ till att utbilda den egna personalen. Även denna typ av information bör ingå i kunskapsinventeringen.

Det var allt för det här inlägget. Nu kan du gå vidare till del 2!

Liten kurs i kompetensstrategi - del 2

Kunskapssamhälle utan utbildningsstrategi

Det finns inte en IT-organisation i Sverige som skulle påstå att kompetens är oviktigt. Hur kommer det sig då att de flesta av Sveriges IT-organisationer, både privata och offentliga, saknar både strategi och plan för kompetensutveckling?
Mönstret upprepar sig i så gott som samtliga organisationer jag möter: två varianter av utbildning. Den ena på individnivå där varje anställd får löfte om att gå en eller flera kurser. Oftast fastslagna i ett utvecklingssamtal i början av året. Inte sällan baserat på den anställdes önskan om att få gå en viss utbildning, snarare än kopplat till organisationens faktiska behov.
Den andra varianten är på organisationsnivå där en hel grupp, ibland en hel avdelning, får gå en viss kurs.
Båda dessa varianter är punktinsatser och risken är stor att utbildningsinvesteringen är bortkastad om det inte finns en tydlig plan för att omvandla utbildningsinsatsen till värdeskapande insatser i det dagliga arbetet.
  • Varför är det inte fler organisationer som har en tydlig bild av nuvarande och framtida kompetensbehov?
  • Varför är det inte fler organisationer som har en uppdaterad kompetensinventering?
  • Varför är det inte fler organisationer som kombinerar olika typer av utbildningsmetoder?
  • Varför är det inte fler organisationer som ser mäter och följer upp värdet av utbildningsinsatser?
  • Varför är det inte fler organisationer som ser till att kombinera kompetenshöjning med värdeskapande insatser på hemmaplan?
Många frågor i det här inlägget. I mitt nästa inlägg tänker jag bemöta några av dessa genom att beskriva ett alternativ till den förlegade utbildningsdogm som, enligt mig, fortfarande råder.          

ITIL och Lean - finns det en koppling?

Jag får ibland höra följande kommentar från potentiella kunder ”vi ska jobba med Lean istället för ITIL nu”. Är det ett rimligt påstående? 

I mitt senaste inlägg förklarade jag hur ITIL förhåller sig till en rad andra ramverk inom området IT Service Management. Den här gången tänkte jag förklara kopplingen till Lean – i den mån det nu finns en sådan…

Innan jag går in på kopplingen mellan ITIL och Lean är en kortfattad beskrivning av Lean på sin plats. Det är dock inte helt enkelt eftersom det, till skillnad mot ITIL, inte är helt glasklart vad som avses med Lean. Ett populärt sätt att beskriva syftet med Lean är ”mer värde för mindre arbete” eller ”få bort allt slöseri som inte är direkt bidragande till värdeskapandet”. Lean är alltså inte något ramverk eller modell utan snarare en filosofi eller ett tänk. Detta tänk appliceras på olika sätt i olika företag och det kanske mest kända är det som Toyota anammat i sitt TPS – Toyota Production System. TPS vilar på fjorton principer som tillsammans bildar en helhet. Exempel på principer:

• Basera besluten på långsiktigt tänkande, även då det sker på bekostnad av kortsiktiga mål
• Skapa processflöden som för upp problem till ytan
• Standardiserat arbete är grunden till ständiga förbättringar och för personalens delaktighet
• Bli en lärande organisation genom att oförtröttligt reflektera och ständigt förbättra

Det är lätt att få uppfattningen att Lean endast är applicerbart på industrin, men det stämmer inte riktigt. Det går att anamma lean-tänket för vilka verksamhetsprocesser som helst. De som är baserade på ITIL, till exempel. Även om en IT-avdelning inte har samma processer som en biltillverkare så är slutmålet detsamma – att leverera en värdeskapande tjänst/produkt och att göra det så kostnadseffektivt som möjligt. En biltillverkare har processer för att förstå kravbilden från kunderna, designa bilen, tillverka bilen, marknadsföra bilen och sälja bilen på precis samma sätt som en IT-leverantör har processer för att förstå behov, designa tjänster, skapa tjänster, driftsätta tjänster, marknadsföra och sälja tjänster. Både en biltillverkare och en IT-tjänsteleverantör behöver även ha processer för service och support samt hantering av underleverantörer.
Det är lätt att inse att de principer från TPS som listas ovan är relevanta för en IT-avdelning och att de ligger väl i linje med ITILs syfte och budskap.

Sammanfattningsvis kan vi alltså konstatera att det finns en koppling, eller kanske snarare synergi, mellan ITIL och Lean. Vi kan även konstatera att kommentaren ”vi ska jobba med Lean istället för ITIL” är rent nonsens. Lean-filosofin behöver appliceras på processer och dessa processer kan mycket väl vara ITIL-processer.

Det räcker inte med ITIL – allt är inte en spik

Det finns ett engelskt uttryck som kan översättas till "om allt du har är en hammare kommer allt se ut som en spik”.
Det har varit många företags inställning till ramverket (verktyget) ITIL - alla IT-avdelningens utmaningar ska lösas med hjälp av ITIL.

För några år sedan räckte det med att kunna stava till ITIL för att bli hälsad som en frälsare. ITIL var lösningen på IT-avdelningens alla problem. Man skulle bli bättre på att förstå kunden, kostnaderna skulle sjunka, driftsäkerheten öka och medarbetarna skulle bli lyckligare.
Idag har flera företag vaknat upp från sitt ITIL-rus till en ganska kraftig baksmälla. Vad var det som hände?
Det som hände var minst ett av nedanstående alternativ, troligtvis allihop:

• Oförmåga att inse att ITIL är ett verktyg och ingen färdig lösning
• Orimliga förväntningar på organisationens förändringsförmåga
• Bristande kunskaper hos egen personal OCH externa konsulter

Jag hävdar med en dåres envishet att ITIL är ett mycket effektivt verktyg. Men man måste förstå hur det ska användas och inse att världen inte bara består av spikar.
Det finns många ramverk och modeller som är alldeles utmärkta, och nödvändiga, komplement till ITIL. Några exempel som kan nämnas är COBIT, ISO/IEC 20000, CMMI, Balanserat Styrkort, PM3 samt Lean. Dessa verktyg ersätter dock inte ITIL utan de har andra styrkor. Med flera verktyg i verktygslådan ser inte allt ut som en spik längre. 
 
I min nästa blogg tänkte jag berätta lite mer om hur några av ovanstående verktyg kompletterar ITIL.  Det blir ett lite längre inlägg som jag hoppas du tar dig tid att läsa. Bra koll på verktygen ökar möjligheterna till ett lyckat bygge!

När är en process färdig?

”Den processen har vi redan implementerat”, får jag höra titt som tätt. Eller ”Vi har Incident på plats, så nu vill vi börja med Problem”.
Vad innebär det att processen är ”implementerad” eller ”på plats” brukar jag fråga. Svaret jag får varierar men vanligtvis ingår något eller några av nedanstående påståenden:

• Processen är dokumenterad
• Vi har utsett processägare
• Verktyget stöder processen
• Vi har utbildat vår personal i processen

Det finns inget entydigt svar på när en process är ”på plats” men det som finns är sätt att bedöma hur mogen en viss process är i en specifik organisationen. Man kan använda sig av en mognadsmodell.
Med en mognadsmodell är det inte längre digitalt om en process är ”implementerad” eller ej. Istället gör man en mognadsbedömning av varje enskild process på en skala från 1 till 5. På så sätt får man ett mer nyanserat svar på frågan hur långt man har kommit i sitt processinförande. Svaret kan t.ex. bli ”Vi är på nivå 3 för Incident och Change Management och på nivå 2 för Problem och Configuration Management”.
Ett ramverk som kan användas för att skapa en mognadsmodell är CMMI (Capability Maturity Model Integration). På Olingo har vi skapat en ”egen” version som på ett pragmatiskt sätt gifter ihop CMMI-modellen med ITILs processer. Den har visat sig vara mycket användbar och uppskattad av våra kunder.

Mognadsbedömningen görs i fem dimensioner för varje process som mognadsbedöms;
1. Vision och Styrning
2. Processaktiviteter
3. Verktyg
4. Organisation/personal
5. Kultur

Inom varje dimension sätts konkreta mål per mognadsnivå och process, dvs det blir tydligt vad som krävs för att nå upp till varje enskild nivå i varje enskild dimension. Eftersom varje dimension är viktig för den totala mognaden är det lägsta mognadsvärdet som styr den sammantagna nivån. T.ex. om vi för Incident-processen har mognadsnivå 4 på dimensionen ”verktyg” men bara nivå 2 på ”vision och styrning” så kan den totala mognadsnivån inte vara högre än 2 för processen som helhet.

Mognadsmodellen blir ett kraftfullt verktyg i förändringsarbetet eftersom det skapar en tydlighet kring nuläget men även ger direkt input till en utvecklingsplan. Genom att tydliggöra i en utvecklingsplan vilken mognadsnivå organisation ska uppnå för respektive process, samt hur dessa nivåer ska nås, blir förutsättningarna och målen tydliga för alla. 

Kontakta gärna mig om du vill veta mer om hur en mognadsmodell kan hjälpa dig att få driv i förbättringsarbetet!

ITIL i sambaland


För att få ett exotisk touch inför midsommarhelgen tänkte jag låta en av mina kollegor rapportera om ITIL-läget i sambaland... Nicke är en av våra populära konsulter och ITIL-kursledare som för tillfället befinner sig på uppdrag i Brasilien.

-----------
IT Service Management/ITIL är fortfarande i sin linda i Brasilien, dvs man ligger lite ”efter” oss Svenskar/Européer. Givetvis kan man spekulera vilt i vad detta kan bero på, säkerligen kommer en och annan tänka på stränder, iskalla fruktdrinkar, karnevaler och annat. Jag lämnar dock spekulationerna åt sidan och konstaterar att man är väldans nyfiken på ITSM/ITIL. Om inte annat vittnar hyggligt deltagande på vårt seminarium på SwedCham om detta.

För såväl exilsvenskar som för brassar med svenska intressen utgör den svenska handelskammaren, populärt kallad SwedCham, i São Paulo ett populärt forum för erfarenhetsutbyte och kompetensutveckling. Brasilien är en viktig plats för Sveriges näringsliv med hyggligt stor närvaro som följd. Så självklart ville Olingo, nu även med lokal närvaro, eder ödmjuke undertecknad, vara med och vifta med svenska flaggan kompletterad med ett ITSM och ITIL-banér.
Det hela blev ett mycket interaktivt och populärt seminarium om varför det inte bara är en bra idé utan ren och skär överlevnad att använda ITSM/ITIL. Seminariet följdes av många bra frågor och en hel del fruktsamma diskussioner. Så eder ödmjuke tillika på plats varandes Olingoan var så där härligt varm om öronen och glad i själen efter ett lyckad evenemang och jag skulle bli mycket förvånad om inte Brassarna gasar på blixtsnabbt med ITSM för vi vet ju alla hur bra det kan bli. Eller hur!?

På plats i Brasilien

// Brassenicke (a k a Nicklas Fredriksson)
---------------------------------

Med det sagt kompletterar vi brännvinssupen med en caipirinha på midsommarbordet och utbringar en skål till våra vänner i sambaland. Skål och glad midsommar!

Ola

ITIL – varför heter det så?


ITIL står för Information Technology Infrastructure Library. Hur tråkigt låter inte det?! Snacka om att ett ramverk jobbar i motvind med ett sådant namn.
Inte nog med att namnet är tråkigt. Det är dessutom totalt missvisande. ITIL har i praktiken ingenting med infrastruktur att göra och inte ens kopplingen till IT är särskilt stark.
 
Varför heter det då ITIL? Det har med historik att göra.

ITIL skapades i början av 1980-talet av en statlig engelsk instans, CCTA, med uppgift att ge IT-stöd till regeringsdepartement. Ursprungligen var inriktningen ganska teknisk och det fanns visst fog för namnet ITIL. Allteftersom ITIL-ramverket utvecklades i version 2, som kom ut runt sekelskiftet, och version 3, som släpptes 2007, har dock inriktningen glidit över mer och mer mot verksamhetsfrågor. I samband med att version 3 skulle släppas pågick faktiskt en debatt huruvida namnet ITIL skulle ändras till något som bättre beskriver vad det handlar om – verksamhetsutveckling. Beslutet blev dock att behålla namnet eftersom det anses vara inarbetat och att ett namnbyte skulle gunga den tröga IT-industrin alltför mycket.

Kvar står vi alltså med ett taskigt namn på ett i övrigt användbart ramverk.
Det är lite synd eftersom det gör att ITIL har svårt att få ”cred” inom andra avdelningar än IT-avdelningen, trots att ramverket skulle skapa värde även på andra håll i en organisation.


Olingo har äntligen dragit igång på Twitter - https://twitter.com/#!/Olingo_
Följ oss gärna där om du är intresserad av ITSM (IT Service Management) och ITIL.

Köp wienerbröd för pengarna


För några dagar sedan skrev jag ett inlägg om att de flesta så kallade ”ITIL-projekt” är misslyckade. I sann journalistisk anda spetsade jag till verkligheten lite. Misslyckade är ett starkt ord. Det handlar nog snarare om att många ITIL-projekt inte lever upp till högt ställda förväntningar.
Som botgöring ska jag nu försöka ge ITIL lite upprättelse genom att nyansera mig en aning.
ITIL är ett förträffligt verktyg som kan göra underverk för vilken IT-verksamhet som helst. Om det används på rätt sätt.

På Olingo är vi allergiska mot uttrycket ”Vi ska implementera/införa ITIL”. Vi brukar bemöta det påståendet med ett motförslaget att ni kommer troligtvis få bättre valuta för pengarna om ni köper wienerbröd till personalen istället.

Uttrycket ”införa ITIL” skapar en förväntan av att man ska
ersätta nuvarande arbetssätt med ITIL-processer. Man ska gå från ett ineffektivt och gammalmodigt sätt att arbeta till ITIL ”best practice” och, som genom ett trollslag, ska alla IT-problem man tidigare upplevt lösa sig.

Det funkar inte riktigt så.

Tanken med ITIL är att man ska utgå från den egna verksamheten och hämta tips och idéer från ITIL-ramverket. Dessa idéer kan användas för att utveckla verksamheten stegvis. En sak i taget.

Så, om du hör någon i din organisation som snackar om att införa ITIL – be om en kanelbulle istället.