Vad är ITIL Incident Definition?

Published

Incident Management, ITIL Ramverket

Incident management inom ITIL ramverket

Vad är ITIL Incident Definition?

Vad är ITIL Incident Definition?

ITIL, även känt som Information Technology Infrastructure Library, är en välkänd ramverk för att hantera och förbättra IT-tjänster inom en organisation. Inom ITIL definieras en mängd olika begrepp och processer som syftar till att optimera hanteringen av IT-tjänster. En av dessa viktiga processer är Incident Definition, vilket spelar en avgörande roll i att hantera incidenter och upprätthålla en stabil IT-miljö.

Förståelse för ITIL

Innan vi gräver djupare in i Incident Definition är det viktigt att förstå grunden för ITIL och dess betydelse i IT-branschen. ITIL har en lång historia och har utvecklats över tid för att möta de ökande behoven inom IT-service management. Ramverket består av en serie best practices och principer som hjälper organisationer att strukturera och förbättra sina IT-processer.

ITIL började utvecklas på 1980-talet av det brittiska handels- och industriministeriet. Det skapades som ett svar på behovet av en standardiserad metod för att hantera IT-tjänster. Sedan dess har ITIL vuxit och blivit en branschstandard som används över hela världen.

Inom IT-branschen spelar ITIL en viktig roll eftersom det hjälper organisationer att etablera effektiva processer för att hantera olika IT-tjänster. Genom att implementera ITIL kan organisationer förbättra sin serviceleverans, öka kundnöjdhet och minska incidenter och driftavbrott.

En av de viktigaste komponenterna i ITIL är Incident Management. Detta är processen för att hantera och lösa incidenter som uppstår i IT-tjänster. En incident kan vara allt från en enkel användarfråga till en allvarlig driftavbrott. Incidenthantering innebär att identifiera, registrera, kategorisera och prioritera incidenter för att säkerställa att de åtgärdas på ett effektivt sätt.

En annan viktig del av ITIL är Problem Management. Detta är processen för att identifiera och lösa underliggande orsaker till incidenter. Genom att analysera incidenter och identifiera mönster och trender kan problemhanteringsteamet arbeta för att förhindra att incidenter upprepas. Detta kan inkludera att genomföra förbättringar i IT-infrastrukturen eller att uppdatera processer och rutiner.

ITIL omfattar också Change Management, som är processen för att hantera förändringar i IT-miljön. Detta kan vara allt från att installera ny programvara till att implementera större infrastrukturprojekt. Genom att ha en strukturerad metod för att hantera förändringar kan organisationer minimera risken för fel och driftavbrott och säkerställa att förändringar genomförs på ett kontrollerat och effektivt sätt.

Utöver dessa processer omfattar ITIL också Service Level Management, som handlar om att etablera och övervaka servicenivåavtal med kunder och leverantörer. Detta säkerställer att IT-tjänster levereras enligt överenskomna nivåer och att kundernas förväntningar uppfylls.

Sammanfattningsvis är ITIL en viktig metod för att strukturera och förbättra IT-processer inom organisationer. Genom att implementera ITIL kan organisationer förbättra sin serviceleverans, öka kundnöjdhet och minska incidenter och driftavbrott. Genom att använda best practices och principer inom ITIL kan organisationer dra nytta av en standardiserad och effektiv metod för att hantera IT-tjänster.

Djupdykning i Incident Definition

Eftersom Incident Definition är en viktig del av ITIL är det värt att undersöka det närmare och förstå dess roll och funktion inom ramverket. Incident Definition syftar till att snabbt och effektivt hantera och lösa incidenter som påverkar IT-tjänsterna.

Incident Definition är en process inom ITIL som tar hand om att hantera incidenter. En incident kan definieras som en oplanerad händelse eller avbrott i IT-service som påverkar användare och kunder. Incident Definitionen hjälper till att identifiera, registrera, prioritera och lösa dessa incidenter på ett strukturerat sätt.

En viktig del av Incident Definition är att säkerställa snabb återställning av IT-tjänsterna och minimera störningar för användarna. Genom att ha en tydlig process för Incident Definition kan organisationer hantera incidenter på ett enhetligt sätt och snabbt återställa normal drift efter en incident.

Incident Definition involverar flera steg som hjälper till att hantera en incident. Först och främst krävs det att incidenten identifieras och registreras. Detta görs genom att användare rapporterar incidenten till IT-supporten eller genom att IT-avdelningen upptäcker och registrerar incidenten på egen hand.

När incidenten har registrerats måste den sedan prioriteras baserat på dess inverkan på användare och verksamheten som helhet. Prioriteringen hjälper till att avgöra hur snabbt incidenten behöver lösas. Incidenter med hög prioritet kommer vanligtvis att hanteras först för att minska påverkan på användare och verksamhet.

Efter att incidenten har prioriterats och klassificerats, inleds arbetet med att lösa den. Detta kan innebära att utföra felsökning, återställa system, tillämpa tekniska lösningar eller samarbeta med andra IT-team för att lösa problemet. Incident Definition-processen fortskrider tills incidenten är löst och normal drift har återställts.

Incident Definition är en viktig del av ITIL och hjälper organisationer att hantera och lösa incidenter på ett strukturerat sätt. Genom att följa Incident Definition-processen kan organisationer snabbt återställa normal drift och minimera störningar för användarna. Det är därför viktigt att ha en tydlig och effektiv Incident Definition-process implementerad inom ITIL-ramverket.

En annan viktig aspekt av Incident Definition är att ha en bra kommunikation med användarna under incidenthanteringsprocessen. Genom att hålla användarna informerade om incidentens status och framsteg kan organisationen minska oro och frustration hos användarna. Det är också viktigt att ge användarna en uppskattad tid för när incidenten förväntas vara löst.

Utöver att hantera incidenter spelar Incident Definition även en roll i att identifiera mönster och trender i incidenter. Genom att analysera och utvärdera incidentdata kan organisationer upptäcka underliggande problem och vidta åtgärder för att förhindra framtida incidenter. Detta kan bidra till att förbättra IT-tjänsternas stabilitet och tillförlitlighet.

Sammanfattningsvis är Incident Definition en viktig process inom ITIL som hjälper till att hantera och lösa incidenter på ett strukturerat sätt. Genom att följa Incident Definition-processen kan organisationer snabbt återställa normal drift och minimera störningar för användarna. Det är därför viktigt att ha en tydlig och effektiv Incident Definition-process implementerad inom ITIL-ramverket.

Incident Definition i praktiken

Eftersom Incident Definition är en central process inom ITIL är det viktigt att förstå dess inverkan på IT-service och hur den kan tillämpas i praktiken. Genom att implementera och följa Incident Definition kan organisationer uppnå flera fördelar:

En av fördelarna med Incident Definition är att den hjälper till att snabbt återställa drift efter en incident. Genom att ha en strukturerad process för Incident Definition kan organisationer minimera störningar för användare och kunder. Detta är särskilt viktigt i dagens snabbrörliga IT-miljö där företag är beroende av sina IT-tjänster för att driva sin verksamhet.

En annan fördel med Incident Definition är att den hjälper till att säkerställa att incidenter hanteras på ett konsekvent och professionellt sätt. Genom att ha tydliga riktlinjer och processer för Incident Definition kan organisationer säkerställa att alla incidenter behandlas på samma sätt och att ingen incident blir bortglömd eller felaktigt åtgärdad.

En välimplementerad Incident Definition-process kan också leda till ökad kundnöjdhet och förtroende för IT-tjänsterna. När incidenter hanteras snabbt och effektivt kan användare och kunder känna sig trygga i att deras problem blir åtgärdade och att de kan fortsätta använda IT-tjänsterna utan avbrott.

Incident Definitions inverkan på IT-service

Genom att ha en strukturerad process för Incident Definition kan organisationer snabbt återställa drift efter en incident och minimera störningar för användare och kunder. Incident Definition hjälper till att säkerställa att incidenter hanteras på ett konsekvent och professionellt sätt, vilket i sin tur leder till ökad kundnöjdhet och förtroende för IT-tjänsterna.

En väl fungerande Incident Definition-process kan också bidra till att organisationer upprätthåller en hög tillgänglighet på sina IT-tjänster. Genom att snabbt identifiera och åtgärda incidenter kan organisationer minimera den tid som användare och kunder är utan tillgång till viktiga IT-tjänster.

En annan positiv effekt av Incident Definition är att den kan hjälpa organisationer att lära sig av incidenter och förbättra sin IT-infrastruktur och processer. Genom att noggrant dokumentera och analysera varje incident kan organisationer identifiera mönster och trender som kan hjälpa till att förebygga framtida incidenter och förbättra IT-tjänsternas stabilitet och prestanda.

Vanliga utmaningar och lösningar med Incident Definition

Trots fördelarna med Incident Definition kan det finnas utmaningar som organisationer kan stöta på. Ett vanligt problem är att hantera stora mängder incidenter samtidigt och prioritera dem korrekt. Det kan också vara svårt att säkerställa att Incident Definition-processen följs strikt och att alla incidenter dokumenteras och åtgärdas på ett korrekt sätt.

För att hantera dessa utmaningar kan organisationer implementera automatiserade verktyg för incidenthantering och använda data och analyser för att identifiera mönster och trender i incidenter. Genom att använda dessa lösningar kan organisationer förbättra sina Incident Definition-processer och effektivisera hanteringen av incidenter.

En annan lösning kan vara att utbilda och informera personalen om vikten av Incident Definition och hur processen ska följas. Genom att öka medvetenheten och kunskapen om Incident Definition kan organisationer säkerställa att alla incidenter dokumenteras och åtgärdas på rätt sätt.

Det är också viktigt att organisationer regelbundet utvärderar och reviderar sin Incident Definition-process för att säkerställa att den är anpassad till organisationens behov och att den fortsätter att vara effektiv. Genom att kontinuerligt förbättra och uppdatera processen kan organisationer möta nya utmaningar och säkerställa att deras IT-tjänster är tillförlitliga och av hög kvalitet.

Framtiden för ITIL och Incident Definition

Som med alla metoder och ramverk förändras även ITIL och Incident Definition över tiden. Det är viktigt att hålla sig uppdaterad om de framtida trenderna och förväntade förändringarna inom ITIL och Incident Definition för att kunna anpassa och förbättra sina egna processer.

Förväntade trender och förändringar

En av de framtida trenderna inom ITIL och Incident Definition är införandet av AI och maskininlärning i incidenthanteringen. Genom att använda AI-teknik kan organisationer automatisera vissa delar av Incident Definition-processen och effektivisera hanteringen av incidenter.

En annan förändring är införandet av DevOps-principer i ITIL. DevOps syftar till att förena utveckling och drift genom att involvera utvecklare och driftspersonal i hela ITIL-processen. Genom att integrera DevOps i Incident Definition kan organisationer öka samarbetet mellan olika IT-team och förbättra hanteringen av incidenter.

Hur man håller sig uppdaterad om ITIL och Incident Definition

För att hålla sig uppdaterad om ITIL och Incident Definition kan man delta i certifieringar och kurser som erbjuds av olika organisationer och utbildningsinstitut. Det finns också en mängd resurser på internet, inklusive böcker, webbplatser och forum som ger information och nyheter om ITIL och Incident Definition.

Genom att hålla sig informerad och kontinuerligt lära sig om ITIL och Incident Definition kan organisationer säkerställa att de är väl förberedda för framtida förändringar och kan dra nytta av de senaste bästa praxisen inom IT-service management.

Avslutande tankar

Incident Definition är en viktig och central process inom ITIL som hjälper organisationer att hantera och lösa incidenter som påverkar IT-tjänsterna. Genom att implementera och följa Incident Definition kan organisationer öka sin effektivitet, förbättra kundnöjdheten och upprätthålla en stabil IT-miljö.

Som ITIL och Incident Definition fortsätter att utvecklas och anpassas till de nya trenderna inom IT-branschen är det viktigt att organisationer håller sig uppdaterade och förbli flexibla. Genom att göra detta kan organisationer fortsätta att dra nytta av de fördelar som ITIL och Incident Definition erbjuder och säkerställa en fortsatt framgångsrik IT-service management.

Varför gå en ITIL Foundation kurs?

Varför gå en ITIL Foundation kurs?

ITIL Foundation ITIL kurs ITIL 4 Foundation ITIL 4

Om du arbetar inom IT har du förmodligen hört talas om ITIL Foundation. Men vad exakt är det, och varför ska du bry dig? ITIL (Information Technology Infrastructure Library) är ett ramverk för IT Service Management, som används av organisationer runt om i världen för att förbättra kvaliteten på sina IT-tjänster.

ITIL Foundation-kursen ger en introduktion till ITIL-ramverket, som täcker dess nyckelbegrepp, terminologi och processer. Det är en bra utgångspunkt för alla som vill förbättra sin förståelse för ITIL och hur den kan tillämpas i deras organisation.

Så varför ska du gå en ITIL Foundation-kurs? För det första kan det hjälpa dig att avancera din karriär inom IT Service Management. Arbetsgivare värdesätter ITIL-certifiering, eftersom det visar en gedigen förståelse för ITIL-ramverket och dess tillämpning.

Dessutom kan ITIL Foundation hjälpa dig att förbättra din organisations IT-tjänster. Genom att lära dig om de bästa metoderna och processerna som beskrivs i ITIL kommer du att vara bättre rustad att identifiera förbättringsområden och genomföra förändringar som kan gynna både din organisation och dess kunder.

Agil överallt

Vi snubblade över en video med Henrik Kniberg där han pratar om sin resa på Spotify & Lego.

Vårt förra frukostmöte handlade om hur man kan kombinera Agila metoder med ITIL. Henrik pratar om hur man kan vara agil inom andra områden är just mjukvaruutveckling.

Det känns som hösten är i antågande.

ITIL4, ITIL4foundation, ITILgbg

Sommaren har bjudit på minst sagt blandat väder kombinerat med COVID-19 så har det väl i ärlighetens namn inte varit den mest konventionella semester.

Men trots det så har vi på Larsson & Co laddat batterierna rejält för att ånga på i vårt arbete att vara bäst i väst på ITIL.

Vi rivstartar med ett ITIL-Event fredagen 28:e Augusti där vi kikar närmare på hur man kan göra det som just ITIL 4 vill, leverera värde. Vi kikar närmare på de operativa elementen i Incident, Problem & Change och hur vi kan leverera värde där.

Nästa händelse i kalendern kommer kort därefter med en ITIL 4 Foundation – All Inclusive 31/8-2/9 på Marstrand och hoppas att vi får vädret med oss. I övrigt har vi planerat ITIL 4 Foundationkurser följande datum:
19-21:a oktober samt 7-9:e december

Vi har även precis släppt datumen för vidareutbildningarna inom ITIL 4.

Create, Deliver & Support 5-7:e oktober

High Velocity IT 12-14:e oktober

Drive Stakeholder Value 2-4:e november

Direct, Plan & Improve 9-11:e november

Mer info kommer på hemsidan här

Mitt i det spränger vi in nästa ITIL Event 6:e November. Här har vi inte riktigt satt ämnet än, men det kommer garanterat handla om ITIL 4 på ett eller annat sätt.

Men vi arbetar ju som bekant inte bara med ITIL-utbildningar. Vi är såklart även konsulter, och genom det får vi både, teori, praktik och pedagogik att vävas ihop till något som vi tror just du och ditt företag skulle kunna uppskatta.

Kom gärna på ett av våra event, haka på en skön kurs, eller boka in oss på en timmes workshopande runt ITIL (kostnadsfritt).

För bokningar eller frågor, hör av er till Andreas Lindström, andreas.lindstrom@larssonco.com alt 031-337 57 50

Lyckat frukostmöte om ITIL 4

För er som inte var på plats i fredags så kan vi ödmjukt meddela att ni missade en förmiddag fylld med godbitar från ITIL 4.

Deltagarna på plats fick en genomgång av de största skillnaderna och nyttan med uppdateringen av ITIL v3 till ITIL 4.

ITIL 4 | ITIL 4 Foundation | ITIL | Nätverk

ITIL 4 innebär ett större fokus på samarbetet och värdeskapandet. Co-create value! Att tillsammans skapa värde genom Service Value Stream och de 7 guiding principles kommer ge stor nytta för alla organisationer som väljer att ta nästa steg med ITIL. ITIL 4 tar även ett större steg för att genomföra förbättringar snabbare och oftare, en välbehövlig anpassning till dagens arbetssätt och takt. Agila arbetssätt stöds numer på ett mycket bättre sätt inom ITIL 4 än tidigare.

Läs gärna mer om skillnaderna i ITIL 4 i vår artikel på länken nedan:

Vet du redan nu att du vill gå en ITIL 4 Foundation erbjuder vi 3 alternativ. Klicka på respektive rubrik för att läsa mer och boka.

ITIL 4 Foundation – All Inclusive
En omfattande kurs, men möjlighet att diskutera, gå lite djupare i frågor och komma bort en stund från vardagen för att kunna koncentrera dig på att inhämta kunskap. 2,5 dagar i en avslappnande och härlig skärgårdsmiljö. Allt ingår, boende, mat, material, cert.

ITIL 4 Foundation – Accelererad
Alla är vi olika, för dig som vill optimera tiden, hinna hem och hinna med vardagen har vi ITIL Accelererad. 2 dagar i våra lokaler, material, cert, lunch och fika ingår såklart. (erbjuds även som företagsintern).

ITIL 4 – Bridge
En överbryggningskurs som tar upp skillnaderna mellan ITIL v3 och ITIL 4. Har du kanske arbetat länge med ITIL? Har du kanske precis tagit ditt cert? 1 dag i våra lokaler och kan tas som en certifieringsförberedande kurs. Du bär ha goda kunskaper om ITIL för att lyckas med certet.
Kursen kräver också hemstudier, varför certifiering bokas separat.

ITIL Foundation | ITIL Certifiering | ITIL Konsult

SLM – En process med dubbla budskap

(SLM) Service Level Management – en dubbel process

Processen Service Level Management (SLM) är en av de viktigaste gränsytorna mellan IT/serviceorganisationen och verksamheten. Service Level Management har dubbla roller i det att den representerar både IT (eller den servicegivande organisationen, om man så vill) och kunderna.

 

Rollen som IT’s representant:Service Level Agreement | SLA | ITIL

Deltar i regelbundna möten med verksamheten/kunden för att säkerställa att de överenskomna nivåerna av tjänsterna efterlevs vad gäller leveranskvalitet, uppföljning av leveransmål, statusrapportering, kundnöjdhetsdialoger samt diskussioner kring tjänsteutveckling i form av nya kundkrav och behov.

Rollen som verksamhetens representant:

Processen för Service Level Management ansvarar sedan för att information, krav och behov från dessa tjänstemöten omhändertas och överförs till ansvariga inom IT för att planera och exekvera passande aktiviteter som bl.a. leder till utveckling av nya och befintliga tjänster samt att säkerställa att de linjerar på bästa sätt med kundens krav och behov.

Dubbla roller

Med andra ord representerar SLM bägge sidorna av myntet, något som kanske inte alltid fungerar som det ska. SLM måste BÅDE hantera efterlevnad, men även önskemål och krav. Inte sällan blir en av sidorna tongivande med en kantring som resultat. Dvs antingen blir man en stoppkloss internt på IT-avdelningen som ständigt säger blankt nej till nya önskemål och behov. Eller så blir man en orimlig kravställare från verksamheten.

För att förenkla det ytterligare, SLM är kundens röst till IT samtidigt som det är IT’s röst till kunden. Ett lösningsfokus är inte bara önskvärt utan ett definitivt krav. Business Relationship Management (BRM) inom ITIL hanterar även den en hel del av detta, men i en lite annan kontext, vi på Larsson & Co anser att man utan några större hinder kan slå ihop de två processerna.

 

Processen Service Level Management har som mål att samla in behov, definiera, förhandla, dokumentera, mäta och rapportera tjänsteleveranserna utifrån (med verksamheten/kunden) överenskomna kvalitetsmål.

Målsättningen med processen är bl.a. att höja kundnöjdheten och nå en djupare kundrelation genom en transparent målstyrning och uppföljning. Men även att synliggöra förbättringsbehov och att linjera tjänsteleveransen med verksamhetens behov.

 

Förväntade resultatet av en införd Service Level Management process är:

 

Processen består av fyra delprocesser.

SLM | Service Level Management | ITIL | ITIL 4

Gartners analys av ITSSM verktyg 2015

Här kan du ladda ner Gartners analys av marknadens ITSSM/Support-verktyg för 2015

Vi har tidigare presenterat denna undersökning och här kommer nu en uppdatering.

IT support management (ITSSM) verktyg har utökade funktionerna jämfört med ett traditionellt servicedesk-verktyg genom att tillhandahålla moduler som automatiserar konfiguration och stödjer styrprocesser och ger samtidigt ett verksamhetsperspektiv på IT-tjänsterna. Dessa funktioner gör det möjligt för IT-supportorganisationen för att hantera incidenter, problem, förändringar och förfrågningar under hela deras livscykel på ett mer effektivt sätt. ITSSM verktyg har också funktioner som gör det möjligt för användare att få kunskap att stöd i att själv lösa sina IT-frågor eller begära hjälp.

Nedan kan du ladda ner och läsa Gartners analys av ett antal utvalda leverantörer och deras ITSSM-verktyg.

2015 Magic Quadrant for IT Service Support Management Tools incl SMB & Europe Context

Ö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.

 


 

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