Problem Management, del 1 – Därför behövs Problem Management?

Published

ITIL Ramverket, Problem Management

Problem Management, del 1 – Därför behövs Problem Management?

Utbildning: Att införa ITIL
Utbildning: Att införa ITIL

Om ITIL-processen problem management behövs på just ditt företag, bestämmer givetvis ni själva. ITIL i sig är ingen trollformel som löser alla problem. En av de största missuppfattningarna med ramverket ITIL är att många tror att ITIL är en modell som löser alla problem. ”Om ni gör som det står i boken, så kommer allt att fungera perfekt”.

Inget kan vara mer fel. ITIL består av fem böcker på ca 2000 sidor, där de ger rekommendationer på arbetssätt för att hantera olika scenarion som kan uppstå i en organisation, inom t.ex. problem management. Sedan är det alltid organisationen som i sin tur bestämmer om och hur de vill använda de rekommenderade arbetssätten. Arbetssätten är väl värda att testa då de har fungerat hos tusentals företag runt om i världen. Vi tycker att det är lite lyxigt att det redan finns en hel rad med beprövade arbetssätt, som är helt gratis att bara börja använda!

En bra process för surdegar

Organisationer kontaktar oss regelbundet och vill ha hjälp och tips på hur de kan komma vidare med processinförandet av problem-processen. De flesta har infört incident-processen, men tycker inte att den fungerar optimalt. När det uppstår återkommande fel och ”surdegar” upptäcker de flesta att incident-processen inte alltid kan hantera den här typen av ITIL Foundation, ITIL kurs, ITIL Utbildning, ITIL Certifieringincidenter på ett bra och strukturerat sätt. Detta beror till stor del på att incidentprocessen inte är designad för att hantera återkommande fel och ”surdegar” på ett tillfredsställande sätt. Och det är vid dessa tillfällen som problem management-processen kan göra som mest nytta.

Målet med problem management är att:

Det är viktigt att komma ihåg att en incident aldrig blir ett problemärende, då incidenter och problem har sina egna livscyklar.

Problemprocessen är till skillnad mot incidentprocessen, designad för att hantera den oordning och merjobb som återkommande incidenter kan ställa till med. Det räcker dock inte bara med att problemprocessen fungerar bra. Problemprocessen är väldigt beroende av att incident och change management-processerna också fungerar på ett tillfredsställande sätt.

Problem Management del 2

Tjänstekatalog enligt ITIL – vad, varför & hur

Tips och råd vid etableringen av en tjänstekatalog enligt ITIL

Det finns många frågor och funderingar gällande ITIL och dess tjänstekatalogskoncept. De flesta frågor handlar om saker som:

  1. Vad är en tjänstekatalog?
  2. Vad består en tjänstekatalog av?
  3. Vem äger tjänstekatalogen?
  4. Och framförallt, Hur inför man en tjänstekatalog?

Se följande inspirerande film om ITILs tjänstekatalog.

Tjänstekatalog enligt itil, vad, vem och hurVad är en tjänstekatalog och vad innehåller den?

En tjänstekatalog enligt ITIL innehåller information om alla produktionssatta IT-tjänster och de tjänster som är förberedda och på ett enkelt sätt  produktionssättas.

Tjänstekatalogen innehåller information om bland annat tjänstens funktion, öppettider, priser, kontaktuppgifter och tillvägagångssätt för att beställa tjänsten. En tjänstekatalog enigt ITIL har två olika vyer. En kund/verksamhetsvy (Business Service catalog) och en för IT-avdelningen/IT-leverantören, den så kallade tekniska tjänstekatalogen (Technical Service Catalog).

En tjänstekatalog kan ha många olika format. Den kan till exempel ha formen av ett word-dokument, ett Excel-ark, en intranätsida, en databas eller ett pappersdokument.

Hur och varför inför man man ett tjänstekatalog enligt ITIL och vem äger den?

Nedan följer tre filmer som på ett bra och enkelt sätt beskriver varför man behöver en tjänstekatalog och vad man behöver tänka på vid införandet av en.

Del ett handlar främst om varför man kan behöva en tjänstekatalog. Avsnittet går också in på vad en tjänst är och hur den definieras vilket är en viktig grund i själva tjänstetänket som ITIL förespråkar.

Del 2 handlar om katalogens utseende och utformning. I det här avsnittet beskrivs de två olika vyerna som tjänstekatalogen består av. Men de går också in på ”aktiva” (acionable) eller statiska kataloger vilket är ett intressant sätt att beskriva möjligheterna till automatisering av vissa tjänstebeställningar och liknande.

Del 3 beskriver slutligen ”huret”, vilka steg man kan ta för att etablera tjänstekatalogen i praktiken.

Hoppas filmserien har varit lärorik och intressant.
Vi vill tacka rightstar för ett bra arbete med att sätta ihop denna filmserie.

Du bestämmer själv hur agilt ITIL ska vara

Du bestämmer själv hur agilt ITIL ska vara!

itil agilOrganisationer och företag har en stor utmaning framför sig med att tydliggöra hur IT och ITIL kan stödja deras verksamhet. Idag kan det lätt uppstå en kamp mellan olika falanger som dels förespråkar att agila metoder är ”vida överlägsna” det mer ”byråkratiska” ITIL. Detta är förstås en av de största missuppfattningarna ute i verksamheten.

Det ligger även ett stort ansvar för organisationer som Axelos att bidra och hjälpa till med att förtydliga och klargöra att det inte finns några motsättningar mellan agila metoder och ITIL, utan tvärtom, att de kompletterar varandra!

ITILs Change Management-process är så agil som du vill att den ska vara

ITIL ska bara ses som rekommendationer, och vet man hur ett agilt arbetssätt fungerar är det inga problem att exempelvis använda ITILs Change Management-process utifrån ett agilt arbetssätt.

ITIL har exempelvis inga krav på hur ofta en CAB (Change Advisory Board) måste träffas för att besluta om förändringar, inte heller förespråkar ITIL att man ska vara byråkratisk och dra saker i långbänk. Vilket en del tycks tro är synonymt med ITIL. Det går alldeles utmärkt att jobba med olika nivåer gällande flexibilitet och anpassningsbarhet (agilt arbete). Det har helt att göra med Changens natur och verksamhetens förmåga att tolka och nyttja ITIL.

Det många tror när man pratar om ITIL och Change Management-processen är att det är en långdragen beslutsprocess och att en Normal Change (en change som per definition måste gå hela vägen genom den normala change-processen med allt vad det innebär) är den vanligast typen av changear, så är inte fallet! Den vanligaste changen är en Standard Change som genomförs på ett strukturerat och någorlunda agilt sätt inom mjukvaruutveckling eller genom dagliga infrastrukturs-changear. Helt enligt definitionen: låg risk och att vi har gjort det förut. I själva verket är det ganska få changear i vår vardag som måste gå igenom en regelrätt (och ofta segdragen om man gör den helt enligt boken och inte förstår den) Normal Change process.

Kort och gott, man bestämmer själv om man vill jobba agilt med ITIL.

LÄS AXELOS ARTIKEL OM ITIL KOPPLAT TILL AGILA METODER OCH MYCKET MER


 

Kostnadsfri ITIL-workshop

ITIL Göteborg | ITIL 4 | ITIL Foundation
Copyright © AXELOS Limited 2016. Used under permission of AXELOS Limited. All rights reserved. (Figure 3.1 ITIL Foundation ITIL 4 Edition).

Erbjudande: Kostnadsfri ITIL-workshop

Vill du vet hur ni kan nyttja ITIL mer eller bättre? Är du nyfiken på vad ITIL är och hur det kan användas eller har ni påbörjat ett ITIL-arbete men vet inte hur ni tar nästa steg? Oanvsett ta tillfället i akt och träffa oss under en utifrån anpassad workshop om något ni känner ett intresse för. Med vår pragmatiska syn på vad ITIL är och innebär, hoppas vi kunna ge dig och din organisation nya idéer om hur ni kan utvecklas och jobba på ett smartare och mer strukturerat sätt.

Workshopen levereras KOSTNADSFRITT och på plats hos er så det krävs inget mer än er tid och ert intresse. Workshopen handleds av en av våra ITIL & Support-specialister.

Förslag på diskussionsämnen:

Tre timmar workshop/expertstöd – Agenda exempel

Villkor:

Inspirationsseminarier om att ”misslyckas” med ITIL

Vi håller även otroligt uppskattade och inspirerar föredrag där vi har vänt lite humoristiskt på kuttingen, hur man ”misslyckas” med sitt ITIL-arbete heter föredraget.

LÄS MER OM FÖREDRAGET HÄR


Öka lösningsgraden i Service desk del 1 – Förväntningarna

Öka lösningsgraden i Service desk/Kundtjänst del 1 – Förväntningarna

Vilka förväntningar har ni på er IT-avdelning och supportService Desk/Kundtjänst: Vi älskar dem när de hjälper oss. Och vi älskar att klaga på dem när de inte gör det!! För långsamma att svara, det tar för lång tid att lösa mitt problem, de är inte personliga nog eller inte tillräckligt kunniga. Vi har alla använt oss av liknande uttryck.

Sanningen är att vi har höga förväntningar på Service Desk-personalen eller människorna i kundtjänsten.

Allt service desken/kundtjänst egentligen behöver göra är att kommunicera effektivt och påskynda lösningen av problemen för att möta kundernas förväntningar. Det låter enkelt, men det kräver en bra blandning av människor, processer, information och teknik.

Följande text har jag skrivit för att stötta, hjälpa och inspirera alla er som arbetar med att utveckla en Service Desk eller en kundtjänst och som vill leverera era support-tjänster genom en modern, effektiv och inspirerade funktion. Resultatet – en ökning av lösningsgraden.

 

Tre saker som skapar en tydlig bild av Förväntningarna på Service Desk/Kundtjänst

När vi intervjuar Service Desk- och Kundtjänstpersonal om vad de anser behöver utvecklas angående deras arbetsmiljö och position, är otydliga förväntningar ett av de vanligaste områdena som kommer upp. Vanligtvis är vi snabba med att gå på lösningar och effektiviseringsåtgärder. Låt oss hejda oss en sekund och börja med att fråga oss vad våra kunder och användare faktiskt förväntar sig av oss. Har våra kunder uttryckligen sagt att Service Desken faktiskt måste svara i telefonen inom 20 sekunder eller är det något vi själva har satt upp som ett måste?? Jag vet inte hur många gånger vi har ställt samma fråga till våra kunder (supportorganisationer, IT-avdelningar och kundtjänster), för det mesta får vi samma svar. Nämligen, nja, vi har väl inte riktigt frågat dem vad de förväntar sig men vi tror att det är viktigt för dem. När vi sedan frågar verksamheten/kunderna får vi nästan alltid ett annat svar, nämligen något i stil med: 20 sekunder, nej så fort behöver de inte svara. Det viktigaste för mig är att de lyssnar på mitt problem och att de inte skickar mig vidare…

För att hantera förväntningarna på ett strukturerat sätt krävs ett bra ärendehanteringssystem/ITSM-verktyg och att man upprättar en nära dialog med sina kunder och användare för att ta reda på förväntningarna. Frågar man inte får man inget veta…

1 Skapa en relation och forum för dialog

Genom att etablera och driva olika typer av forum (IT-råd, förvaltningsforum, driftmöten, Service Reviews, m.m.) får ni reda på vilka förväntningar och krav som finns på er som supportorganisation.

En sak som vi ofta rekommenderar våra kunder är att införa ”spontana” samtal till sina kunder och användare. Det är både enkelt, tidsbesparande och makalöst effektivt när det gäller att förstå förväntningar och skapa förtroende. Så här går det till.

 

2 Etablera ITIL-processen ”förväntanshantering”, Service Level Management (SLM)

Det är vanligt att vi blir tillfrågade att hjälpa våra kunder med utveckling och införande av de s.k. ”supportprocesserna” Incident Management, Request Fullfilment och Problem Management. En återkommande rekommendation från oss är att i kombination med någon/några av ovan processer även titta på vad vi på Larsson & Co kallar för förväntanshanterings-processen, enligt ITIL heter den formellt Service Level Management. En process som används för att diskutera, förhandla och slutligen formulera förväntningarna mellan IT-avdelningen och/eller Service Desken och verksamheten/kunden.

Utan någon form av SLM famlar man i mörkret. Genom att överhuvudtaget inte arbeta med frågeställningar som hanteras av SLM säger man i praktiken till kunden: Vi kommer att leverera IT/support-tjänster till er men vi kan inte säga med vilken kvalitet, hur ni kan nyttja lösningen/tjänsten, vilka krav ni kan ställa på tjänsten/oss, hur mycket den kostar eller ens hur ni ska kontakta oss vid problem och frågor.

Vanligtvis har vi någon form av dialog med våra kunder/användare men det är inte alltid vi för en formaliserad dialog eller ens en regelbunden. Vi menar inte att ni måste etablera en fullskalig SLM-process eller ens kalla det Service Level Management. Det går alldeles utmärkt att i början etablera några enkla och regelbundna möten (kallade Service Reviews enligt ITIL) med sina kunder/användare för att på ett strukturerat sätt dokumentera och följa upp era förväntningar, roller och ansvar.

3 Använd ett systemstöd – Ärendehanteringssystem

Ärendehanteringssystemet måste kunna illustrera befintliga och överenskomna förväntningar, det vill säga så kallade tjänstenivåer. Exempel på vanliga tjänstenivåer kan vara att Service Desken är öppen och kontaktbar mellan 05:00 – 18:00, alla ärenden ska kommuniceras och följas upp mot användaren, lösenordsärenden ska lösas inom 6 timmar. Tjänstenivåerna böra formaliseras/dokumenteras på något sätt. Det kan vara direkt i ärendehanteringssystemet för mindre organisationer eller som en del i ett SLA (Service Level Agreement). Poängen är inte hur det dokumenteras utan Att det dokumenteras så att Service Desk-personalen vet vad de har att förhålla sig till.

Ärendehanteringssystemet bör ha möjlighet att spåra olika tidsmål, exempelvis den tid det har tagit att lösa varje typ av incident (print, PC, server, Nätverk, applikation o.s.v.). Service Desk personal kan sedan använda informationen för att tydliggöra förmågan att hantera olika ärenden utifrån fakta och inte gissningar. Med hjälp av data kan man sedan tydliggöra vad kunder och användare kan förvänta sig av Service Desken men också inom vilka områden Service Desken bör förbättra sig inom. Till exempel, ”90 procent av dessa frågor löses inom tre dagar”.

En av de absolut vanligaste frågeställningarna när det gäller leveransen av supporttjänster eller etableringen av en Service Desk är behovet/kravet av jouröppet, efter arbetstidssupport eller beredskap. Genom att inte bara ställa frågan om verksamheten önskar (vilket de i de flesta fall per default önskar) support dygnet runt utan också att utgå ifrån statistiken i ärendehanteringssystemet kan man med hjälp av fakta över tiden illustrera det faktiska behovet. Genom att utgå ifrån fakta undviker man onödigt gnissel och spekulationer. Men det förutsätter också att statistiken går att lita på. Har ni satt upp ert ärendehanteringssystem så att ni kan lita på statistiken? Inte, då går vi igenom det under nästa del i artikelserien: Öka lösningsgraden i Service Desk/Kundtjänst.

 

Registrera dig gärna för vårt nyhetsbrev (se uppe till höger på sidan) så får du nästa artikel (Öka lösningsgraden i Service Desk/Kundtjänst del 2 – KPI:er för Supportorganisationer) direkt i inboxen…

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.

 


 

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