Sveriges mest intressanta ITIL konsulter

Published

Videoinspiration

Vi vill ses som Sveriges mest intressanta ITIL konsulter!

Vi tror att vi är Sveriges intressantaste ITIL konsulter för att vi engagerar oss och satsar lika mycket i vårt eget företag som i våra kunders utmanigar.

Vi gör saker som andra inte ens skulle drömma om att göra. Som den här introduktionsvideon tillexempel.
Vi gör inte bara intressanta videos, vi erbjuder också intressanta och praktiska ITIL-lösningar…

Prova oss gärna om du inte tror mig. /Freddie


 

Oavsett vilken fråga ni står inför har vi kunskapen och erfarenheten att hjälpa er nå önskad effekt med hjälp av ITIL, ITSM och förändringsledning. Genom vår pragmatiska syn på ITIL skiljer vi oss från mängden. Vi har utvecklat en förmåga och verktyg för att omvandla teori till praktik, vilket resulterar i ett tydligt resultat för er.

ITIL och ITSM konsulter i verkligheten

100 % av alla kunder, företag och användare är människor. Lätt att veta, svårt att applicera. Vi ser alltid den direkta nyttan av processer och hur de på bästa sätt kan kartläggas och utnyttjas. Med ena benet i ramverket ITIL och det andra i verkligheten garanterar vi en faktisk effekt.

Coming soon at a cinema near you…

Missa inte nästa video, den kommer inom kort och är hysterigst rolig!

IT Support – Därför är den så viktig

IT Support – en allt viktigare faktor

Tempot ökar i dagens samhälle och en följd av detta är att allt mer fokus läggs på snabb service för att tillgodose kundernas behov. Många organisationer verkar ha en sund inställning till detta faktum och har därför en strategi för att bygga och upprätthålla en bra service.

IT support -vi hjälper utveckla er Service Desk och Help Desk enligt ITIL

En annan verklighet

Verkligheten är ofta en annan när kunden kontaktar en support. Det är inte ovanligt att kunden får vänta mer än 20 minuter, blir bortkopplad, kopplas runt i organisationen, historik på kunden saknas m.m. Detta är inget läge som någon involverad vill ha, men ändå uppstår detta scenario alltför ofta.

Vad kan organisationen göra för att undvika att detta uppstår?

Kultur

Det finns naturligtvis en rad åtgärder man kan sätta in i en organisation där en supportverksamhet inte fungerar optimalt. Men det grundläggande är att börja med de mjuka delarna. Alla i organisationen måste få lära sig hur hela kundlivscykeln hänger ihop och att alla är beroende av varandra. Ett mycket vanligt scenario hos våra kunder är att sälj och support inte kommer överens av olika anledningar. Därför är det grundläggande att organisationen satsar på att bygga en kultur där varje medarbetare vet vad det gemensamma målet är.

Konkurrensmedel

Idag är tjänsterna inom exempelvis telekom snarlika, kostar ungefär lika mycket och innehållet är detsamma, på grund av detta blir valet svårt för kunderna. Det som däremot skiljer sig åt, är de olika organisationerna IT support. Det är till exempel inte ovanligt att kunderna idag kan nå sina IT-leverantörer under en stor del av dygnet. Det har på senare tid blivit ett alltmer viktigt konkurrensmedel att ha en väl fungerande support. Detta kan vi se bevis på i media, där det relativt ofta görs mätningar på hur bra de olika organisationernas IT support fungerar.

En avgörande faktor

Kostnaden för att behålla en kund är relativt liten i jämförelse med att skaffa en ny kund. organisationer har inte råd med att tappa existerande kunder. Därför är det en avgörande faktor att kunna behålla sina kunder och en viktig del av organisationens strategi är att ha en väl fungerande support.

Skriven av Robert Johnsson

Läs gärna mer om hur vi kan hjälpa just er att utveckla en modern, förtroendeingivande och väl fungerande IT support, Service Desk eller Help Desk.


 

Projektmodellens betydelse i framgångsrika ITIL projekt – del 1

Projektmodellen framför allt…

En projektmodell ger struktur, fokus, gemensamt språk och tydliga roller.
Tanken med en projektmodell är inte att ”ITIL projektet” ska följa dess ramverk slaviskt utan dess främsta uppgift är att tjänstgöra som ett stödjande och vägledande ”verktyg.”

Då alla ITIL projekt anses vara unika behöver man göra anpassningar av den för stunden tänkta modellen. Hur ska denna anpassning göras? Och Vad ska anpassningen innefatta? Dessa är frågeställningarna som har legat till grund för den korta artikelserie.

Den empiriska bakgrunden bygger på studier av allehanda projektlitteratur samt samtal och diskussioner med projektledare och seniorkonsulter. Mycket av innehållet bygger på egna resonemang och erfarenheter men även från ingående diskussioner med kollegor med insyn i ämnet och branschen. Artikelserien utgår från ett resonemang från en generell projektmodell.

”Det är inte modellen eller metoden som avgör hur bra man lyckas med ITIL projektet utan hur den tillämpas av de inblandade.”
Projektmodell - en förenkling av verkligheten
Projektmodell – en förenkling av verkligheten

Projektmodell/metod – när, var, hur och varför

En projektmodell är ett samlat ”dokument” som innehåller ett företags regler, riktlinjer och dokumentation m.m.. Modellen är tänkt att användas vid företagets projektgenomförande. En projektmodell ger struktur, fokus, gemensamt språk och tydliga roller.

Beroende på vilken projektmodell man talar om, kan den användas på enskilda isolerade projekt eller innefatta hela flerprojektorganisationer. En projektmodell ska också vara ett hjälpmedel för personer som normalt inte jobbar med ITIL projekt och som blivit utsedda eller ombedda att medverka i projektarbete. Med det inte sagt att allt ska drivas efter en projektmodell.

Reflektioner bör inte bara göras utifrån om en projektmodell ska användas eller inte. Man bör även fråga sig hur respektive projektmodell bäst utnyttjas av ett projekt, d.v.s. hur en projektmodell anpassas till en viss typ av projekt. Vi vet ju att projekt per definition innebär att en unik (Marttala, A. & Karlsson, Å. (1999), s. 10) företeelse utförs. Så hur skulle det bli om man använde exakt samma projektmodell till alla typer av projekt. Ett kliniskt utvecklingsprojekt har ju inte samma förutsättningar som ett anläggningsprojekt. Efter en jämförelse mellan olika projektmodeller ser man tydligt att det är mer som är lika än vad som skiljer dem åt.

Innan man ens funderar på att använda en projektmodell måste man vara väl medveten om hur organisationen har använt modeller i tidigare sammanhang. Om projektdeltagarna inte är bevandrade i en specifik modell bör den helt enkelt inte användas. En annan otroligt viktig aspekt på modellanvändandet är att modellen har en acceptans och att den är förankrad i organisationen från högsta ledning. Detta för att ge legitimitet för användandet och basen till att modellutbildning ska ingå för respektive projektdeltagare. Det är således inte projektledarens ansvar att se till att deltagarna är kunniga i modellen utan företagsledningen.

Tanken med en modell är inte att ”projektet” ska följa dess ramverk slaviskt utan modellens främsta uppgift är som beskrivits ovan att var ett stödjande ”verktyg.” Ett hjälpmedel att gå tillbaks till under projektprocessen för att få vägledning och hjälp när det gäller allt från styrning, kommunikation och resurshantering till aktiviteter och osäkerhetshantering.

Att jobba med och i projekt kräver ordning och reda. Klara ramar, riktlinjer och roller är byggstenarna i ett lyckat ITIL projekt. Att starta projekt helt utan några som helst fördefinierad riktlinjer kan självklart lyckas men det rekommenderas varmt att åtminstone om än skriven på en servett följa någon typ av ”roadmap”, vad som behövs är en projektmodell eller som det ibland även kallas projektmetod (Marcusson, L. & Ahlin, A. (2002), s. 14). I resterande text kommer uttrycket projektmodell att användas.

SPOC? En förklaring av ITIL-termen SPOC

SPOC som i Singel Point Of Contact (Servicedesk-koncept)

 

SPOC Servicedesk helpdesk
Singel Point Of Contact – SPOC

Support handlar i mångt och mycket om tillgänglighet. Inte så mycket system-tillgänglighet utan främst tillgängligheten till snabb och effektiv hjälp och information. Det finns många sätt att strukturerar en IT support på.

När det gäller tillgänglighet och enkelhet för användare och kunder finns det dock en struktur som dominerar marknaden. En struktur som hanterar alla typer av support (incidenter, information, förfrågningar, standard förändringar (standard change) mm.). En servicedesk som samlar användarnas/kundernas behov av stöd till en och samma kontaktpunkt, en så kallad SPOC (Single Point of Contact).

Med en SPOC ökar ansvaret för supporten från att kanske bara svara i telefon, logga ärenden och eventuellt eskalera dem, till att äga samtliga ärenden från ”vagga till grav”, från att samtalet besvaras av servicedesken till att det stängs, oavsett vad ärendet handlade om. Ägarskapet för uppdatering, statushantering, informationshantering och slutligen återkoppling till användaren/kund ligger hos SPOC:en (som består av funktionen servicedesk).

Med SPOC menar vi på Larsson & Co en fokalpunkt för kontakt med supporten/kundtjänsten. Det innebär att man kan nå SPOC:en genom olika kanaler men bara genom en ”identitet” per kanal (identitet = telefonnummer eller e-postadress). Således begränsar vi inte en SPOC till att enbart vara nåbara via exempelvis ett telefonnummer. Vi menar att du kan tå en och samma SPOC genom ett telefonnummer, en e-postadress, ett självserviceformulär, en Facebooksida och så vidare.

Hur konstigt det än låter kan det finnas behov av flera SPOC:ar inom samma organisation. Exempelvis kan SPOC:ar hantera olika typer av områden, så som HR, IT och Ekonomi som exempel. Även geografiska orsaker kan kräva att man etablerar flera SPOC:ar över världen (Läs om hur man löser detta genom en Follow The Sun-servicedesk).

Vilka är då förutsättningarna för att man ska kunna etablera servicedesk-konceptet SPOC?

Nedan beskrivs fyra av de grundförutsättningar som krävs för att lyckas med sin SPOC-etablering.

1 . En enda identitet (ex. 1 st. telefonnummer och/eller 1 st. e-postadress) per kanal (ex. telefon, e-post, Intranät, självserviceportal, sociala medier) som är lätt tillgänglig för användarna att ställa sina frågor och få support genom. Ni vill inte ha 4 nummer och/eller 3 e-postadresser för användarna att komma ihåg. En identitet per kanal förhindrar även missförstånd och onödig stress då användarna inte behöver veta vem som hanterar vad.

2 . En kunskapsdatabas (Knowledge Managementmed alla typer av frågor och ärenden som har identifierats och till dem kopplade lösningar eller en passande eskalerings-information. Servicedesk-agenterna ska antigen kunna lösa ärendet eller veta vart de ska vända sig för att hjälpa användaren/kunden ytterligare. Kunskapsdatabasen säkerställer en enhetlig support med en jämn och hög kvalitet.

3 . SPOC:en (Servicedesken) behöver rutiner för kommunikationsflödet med användaren, inklusive tydliga tidskriterier att följa. Det är viktigt för kundnöjdheten och i arbetet med att skapa förtroende att snabbt, regelbundet och konsekvent hålla användarna informerade och att anteckna all interaktion och korrespondens med dem.

4 . Kunskapsbaserad ärendehantering. SPOC:en bör vara konstruerad för att hantera ärenden utifrån kunskap och erfarenhet. Det betyder att det ska finnas tydliga rutiner för intern eskalering av ärenden inom SPOC:en. Kunskapsbaserad ärendehantering innebär att ärenden styrs till den servicedesk-agent som är bäst lämpad för att hantera just den typen av ärenden. En kunskapsbaserad ärendehantering ökar den så kallade First Contact Resolution (FCR)  och minskar behovet av eskalering till andra support-linjer (så kallade funktionell eskalering).

Här kan man använda paretoprincipen 80/20 regel. 80% av alla ärenden (eller 80% av alla servicedesk-agenter) ska hanteras av SPOC:en (som i det här fallet kan ses som 1:a linjesupporten. 20% av ärendena ska hanteras av andra supportlinjer.


 

Major Incident Management – Vad är det?

Major Incident Management – En procedur inte en process

Den övergripande målsättningen med Incidentprocessen är att återställa störningar hos IT-tjänster så snart som möjligt. Allt i linje med att användaren känner sig väl- och professionellt bemött.

Vid större störningar som kan leda  till stor negativ och påverkan på verksamheten bör en separat rutin eller som ITIL kallar det en procedur aktiveras, den s.k. Major Incident Management rutinen, en rutin med kortare tidsfrister, snabba eskaleringsvägar och högre prioritet.

Major incidenthantering är en speciell form av Incident Management hantering där samordning och kommunikation internt och externt betonas för att åtgärda incidenten med högsta möjliga fokus.

Rutinen för Major incidenter anropas av rollen Incident Manager.

Syftet med Major incident management rutinen är att säkerställa att rätt resurser allokeras för att på snabbast möjliga sätt åtgärda en incident vilken kräver insatser utöver det vanliga, samt att styra informationsflödet till berörda parter så att rätt beslut kan tas av rätt beslutsfattare.

Major Incident definition:

En incident med en hög påverkan, eller potentiellt hög påverkan på verksamheten och/eller dess intressenter (användare, kunder m.m.) vilken kräver en hantering som ligger utanför det som anges för normala incidenter. Vanligtvis (men inte alltid) klassas en incident som en Major Incident om den har en direkt påverkan på verksamhetskritiska tjänster.

Observera att en incident kan klassas som en Major Incident trots att det inte existerar ett regelrätt tjänsteavbrott. En driftstörning likt en överdriven ”tröghet” (långa svarstider) i exempelvis ett affärssystem kan vara föremål för en Major incident klassning.

Incident Management Processen
Incident Management Processen

 

Vad är ITIL ramverket?

ITIL ramverket (IT Infrastructure Library ®)

ITIL ramverket är den mest använda ramverk för IT Service Management i världen. Det är ett praktiskt tillvägagångssätt som besvarar frågan HUR man; identifierarar, planerar, levererar och supporterar IT-tjänster med hjälp av bl.a. processer.

ITIL ramverket beskriver hur du nyttjar din IT-tillgångar (ex. teknik, information och finansiellt kapital) och organisatoriska förmågor (ex. processer, kunskap, kultur och organisation) så att du år en optimal användning och värde av IT.

Frågor som ITIL ramverket kan hjälpa dig att besvara är: Vilka roller, funktioner, processer, rutiner, dokument och vilken typ av en miljö behöver ni skapa för att nyttja IT optimalt.

ITIL ramverket stödjer den internationella Service Management standarden ISO/IEC 20000 som organisationer kan certifiera sig mot.

 

ITIL ramverkets fem byggstenar/faser/block:

Service Strategy

Syfte: Att besluta om en strategi för att tjäna kunderna. Med utgångspunkt från en bedömning av kundens behov och marknaden bestämmer man i Service Strategy vilka tjänster IT-organisationen ska erbjuda och vilka organisatoriska förmågor som behöver utvecklas. Det yttersta målet är att få IT-organisationen att tänka och agera på ett strategiskt sätt.

Service Design

Syfte: Att utveckla nya IT-tjänster. Omfattningen av fasen inkluderar design av nya tjänster, samt ändringar och förbättringar av befintliga. Man utvecklar ritningen på det man har beslutat om i Service Strategy.

Service Transition

Syfte: Att bygga och driftsätta IT-tjänster. Service Transition ser också till att förändringar av tjänster och processer genomförs på ett samordnat sätt. Fasen används till att flytta tjänster till och från produktionsmiljön och mellan tjänsteleverantörer.

Service Operation

Syfte: Att se till att IT-tjänster levereras effektivt och efter överenskommelse. Service Operation har till uppgift att uppfylla användarnas önskemål, hantera incidenter, lösa problem och att utföra rutinmässiga operativa uppgifter.

Continual Service Improvement – CSI

Syfte: Att använda metoder för att lära av tidigare framgångar och misslyckanden. Continual Service Improvementsyftar till att ständigt förbättra effektiviteten i leveransen, processer och tjänster, i linje med verksamhetens behov och krav.

Källa IT process map

 

ITIL:s historia

ITIL publicerades mellan 1989 och 1995 av Her Majesty’s Stationery Office (HMSO) i Storbritannien på uppdrag av centrala Central Computer and Telecommunications Agency (CCTA)- nu inordnad under Office of Government Commerce (OGC).

ITILS:s tidigaste användning var huvudsakligen begränsad till Storbritannien och Nederländerna. En andra version av ITIL publicerades som en uppsättning reviderade böcker mellan 2000 och 2004.

Den första versionen av ITIL bestod av ett bibliotek (där av library) med 31 tillhörande böcker som täcker alla aspekter av IT-tjänster. Denna första version reviderades och ersätts av sju böcker (ITIL V2).

Denna andra version blev allmänt accepterat och används nu i många länder och av tusentals organisationer som grund för en effektiv IT-tjänster. Under 2007 ersattes ITIL V2 av en förbättrad och mer tjänsteorientera version av ITIL, ITIL V3 som består av fem huvud böcker (Core books) täcker en IT-tjänsts livscykel. 2011 gjorde man den senaste uppdatering vilket innebar främst redaktionella justering och konsolidering av texten.

Sedan 2013 ägs ITIL av företaget Axelos (ITIL® is a Registered Trade Mark of AXELOS Limited).

 

Läs mer om ITIL på ITIL:s officiella hemsida

ITIL konsulter och experter
ITIL Livscykel

– Mognadsanalys av Incident Management

Ladda ner verktyg för mognadsanalys av Incident Management

En gap-analys är ett verktyg som gör det möjligt för en organisation att jämföra sin aktuella prestation med sin potentiella prestation. Målet med mognadsanalysen (GAP-analysen) är att identifiera gapet mellan den nuvarande och den optimala situationen för att ge insikt inom vilka områden det finns en förbättringsmöjlighet.

Detta verktyg kan användas för att göra en enkel Mognadsanalys på Incident Management processen. Du kan skapa nya eller ersätta befintliga frågor om du önskar komplettera eller ändra.
Verktyget har utvecklats som en utgångspunkt för att belysa områden inom Incident Management processen som kräver särskild uppmärksamhet och för att ge dig en uppfattning om er processmognad.

Verktyget Mognadsanalys på Incident Management processen är konstruerad för 10 respondenter.

Du kan använda flera kalkylblad för att göra en större analys.

Syftet är att använda verktyget som utgångspunkt för förbättringar och etablera en eller flera utgångspunkter (Base line) för era visioner och strategier gällande Incident Management processen. Frågorna och verktyget kan naturligtvis även användas på andra processer.

LADDA NER VERKTYGET GRATIS

Mognadsanalys av Incident Management processen
Mognadsanalys av Incident Management processen

Verktygets skapare: www.ucisa.ac.uk


 

Incident Management – Processbeskrivning

Incident Management – ITIL processen framför andra

Incident Management (den formella ITIL-förkortningen = IM) är supportprocessen framför andra. Ingen ITIL process är så spridd och utvecklade som just Incident Management-processen. Incident Management har till syfte att hantera alla incidenter. Den officiella ITIL definitionen på en incident är:

– En oplanerad störning av en IT-tjänst (eller försämring av kvaliteten)

                                            och/eller

– Fel på ett konfigurationsobjekt som ännu inte har påverkat en IT-tjänst

Incidenter kan nå Servicedesk genom olika kanaler, exempelvis kan incidenter rapporteras av slutanvändare, genom teknisk personal eller automatiskt via övervakningsverktyg (ITIL processen Event Management). Syftet med Incident Management processen är att återställa IT-tjänster/system så snabbt som möjligt och minimera de negativa effekterna på verksamheten. En Servicedesk/Helpdesk kan uppnå detta genom att använda en dokumenterad, kommunicerad, begriplig och mätbar Incident Management process och tillhörande verktyg.

Funktionen Servicedesk/Helpdesk är användarens/kundens centrala kontaktyta, en så kallad Singel Point Of Contact eller SPOC mot IT-organisationen. Funktionen äger ansvaret för att snabbt och effektivt hantera Incidenter, förfrågningar (service requests) och infrastrukturella larm (events).

Huvudaktiviteterna i incidentprocessen är upptäcka, registrera, analysera, hitta åtgärd och åtgärda, bekräfta åtgärd och stänga incidenter, förfrågningar och larm. Arbetet i incidentprocessen utförs främst med hjälp av ärendehanteringsverktyg. En incident som inkommer till Servicedesk/Helpdesk följer ett flöde (se nedan, Klicka för större bild) med olika aktiviteter. Exempel på aktiviteter är identifiera, logga, kategorisering, prioritera, diagnostisera och hantera Major Incident (Allvarlig Incident med behov att hanteras brådskande).

 

Incident Management Processen
Incident Management Processen