Problem Management del 4 – Hitta rätt fel

Published 2:25 e m

ITIL Ramverket, ITIL-Nätverk, Problem Management

Root Cause Analysis (RCA)

Root Cause Analysis – I våra tidigare artiklar har vi resonerat runt det reaktiva arbetet i problem management och att ett problem lever i sin egen livscykel. Här tittar vi närmare på orsakerna.

Det reaktiva arbetet i problem management kräver både resurser och tid. Men ger oftast bra payback över tid.

Brandsläckning kräver personal och ticket-hopping kräver tid. Det är svårt att optimera resurser genom oplanerat och reaktivt arbete. I den tredje artikeln är fokus på de samverkande processerna Incident, Problem och Change. Det finns ett starkt beroende mellan dessa processer och ett proaktivt arbete i Problem management ger goda effekter på både Incident- och change processen över tid.

Medan Incidentprocessen enbart har till syfte att återställa tjänsten så fort som möjligt så går problemprocessen djupare. Att hitta de verkliga orsakerna. Tidigare har vi nämnt att det finns 3 tillfällen där Problem Management Processen gör sig väldigt bra.

Major Incident
Surdegar
Återkommande incidenter

Enkla men kraftfulla metoder

I denna artikel ska vi titta närmare på två metoder för att hitta rot-orsaken till ett problem. Det gör man i rot-orsaksanalysen, Root Cause Analysis, som är grundläggande i det reaktiva arbetet inom Problem management. Vi behöver definiera problemet och hitta den verkliga orsaken till att problemet har uppstått. Ta fram en acceptabel lösning som, i vissa fall, även innefattar ett ekonomiskt övervägande. Det är en av de stora skillnaderna mot Incident processen. En annan stor skillnad är att problem processen ofta arbetar i ett mindre tidskritiskt läge.

Kepner-Tregoe

Är en Root Cause Analysis som använder en metod för problemanalys för att definiera problemet och möjliga förändringar som kan orsaka problemet. I beslutsanalysen beskrivs åtgärderna, målsättningen samt alternativa åtgärder och risker. I detta läge är change processen ofta inblandad för att göra en kontrollerad förändring för att återställa effekterna av en okontrollerad/oplanerad förändring eller en förändring som inte kunnat förutses. Slutligen genomförs en potentiell problemanalys där man säkerställer att problemet eller liknande problem inte kan uppkomma igen. Den delen är ett proaktivt problemarbete där ”lessons learned” ger underlag för de ständiga förbättringar som är resultatet av en fungerande Problem Management process.

5-Why

En annan metod för Root Cause Analysis är Five Ys, 5Ys, Five why´s, ja du kan välja benämning själv. Det är en populär metod som går ut på att du ställer frågan varför? i, upp till fem underliggande nivåer för att hitta den verkliga orsaken till problemet. Med denna metod kan man även hitta potentiella risker. Målsättningen är att hitta rot-orsaken till problemet och därefter ta fram åtgärder för att lösa problemet.

Det finns många fler verktyg och metoder för att arbeta med problem management och en del är utformade för speciella branscher och verksamheter men kepner-tregoe och five why´s är vanligt förekommande inom IT. Dessutom är de relativt rakt på, enkla men väldigt effektiva. Vi hoppas ni fått en liten inblick i metoder för att lösa problem och att ni tar tag i major incidents, surdegar som ligger över tid samt återkommande incidenter genom en väl definierad problem process.

När ni har en väl implementerad problem process kommer ni få positiva effekter även i andra processer och arbetar ni proaktivt så gör ni verklig skillnad.

Behöver ni hjälp så hoppas vi att ni hör av er för ett inledande samtal, kanske över en lunch?

För mer inblick i hur man söker rätt fel, kom på vår nätverksträff, frukost ingår!

Datum: 23 November2018
Tid: 08:00 – 10:00
Plats: Lindholmen Science Park, ”Kuggen” – vån 3, stora konferensrummet
Adress: Lindholmsplatsen 1
Kostnad: Nätverket är öppet för alla
För upplysningar kontakta: kansliet@west.dfs.se eller kontakta någon av nätverksledarna.

–

NÄTVERKSLEDARE/ARRANGÖRER

Antonio Tomar, 0708-57 90 28
Andreas Lindström 0708-10 21 42

Anmäl er på den här länken

Läs gärna våra andra artiklar i serien:

Problem Management – del 3

Problem Management – del 2

Problem Management – del 1

Knowledge Centered Service – nätverksträff

Upplys mig!

Hmm…. Det låter mycket bättre på Engelska ”Enlighten Me!”

Nu har ITIL Service Desk nätverket träffats igen för att lära av varandra och ämnet var Knowledge Centered Service (KCS). Det första vi gjorde var att

fundera över förkortningen som i den gamla skolan står för Knowledge Centered Support och i den nya skolan står för

Knowledge Centered Service.

Vi tittade på det nya och mer spännande angreppssättet och där finns mycket att hämta.

I ITIL tittar vi bland annat på DIKW modellen, med Data som grund som vi samlar till en informationskälla ur vilken vi kan

bygga vår kunskap som vi behöver för att fatta kloka beslut.

ITIL levererar men i KCS tittar vi nu på vem som har kunskap, hur vi delar den och vad som krävs för att lyckas med knowledge.

Kan man skapa en kultur där de som har kunskapen vidgar sina vyer och också ser sin kunskap i ett större perspektiv så kan

vi skapa bättre kunskapskällor och om vi sedan delar på ansvaret för kunskapskällorna i team och grupperingar skapar vi förutsättningar

för bättre lösningar. Detta kräver dock ett engagerat och motiverande ledarskap och en tillåtande kultur vilket kan vara en omställning.

Den omställningen är värde insatsen flera gånger om när en ökad kunskapsnivå genomsyrar hela organisationen och resultatet ger

en ökad operationell stabilitet, ökad kvalitet i ”Self-service” och i förlängningen även ett holistiskt angreppssätt som föds tillbaka

som förbättringsmöjligheter till produkter och tjänster.

Bigger picture! Me, My team, My organization! Sharing is caring!

What are you waiting for…..Just DO IT ????

Nästa träff är den 23 November och ämnet är Problem Mgmt (med kopplingen till Incident och den gemensamma kategoriseringen).

Om vi på Larsson & Co kan få loss lite info om hur funktionen Service Desk ser ut i ITIL® v4 kollar vi också på det som avslutning.

//Antonio Tomar

Glöm inte att anmälan numer sker via dfs.se, ett separat email med info om nästa träff kommer så snart vi fått upp eventet på dfs.se

Men boka gärna in 23:e November 8-10 redan nu.

För er som vill är ni välkomna att haka på nästa nätverksträff på nu på fredag med ämnet Service Level Agreement – Att doumentera förväntningar

Anmäl er här: https://natverk.dfs.se/node/2033/register

Service Desk – 7 viktiga mätetal

Att mäta sin service desk med hårda siffror och tydliga mätetal är viktigt, för att kunna se trender, hitta underliggande problem, se till att man uppfyller SLA. Minst lika viktigt är de mjuka värdena, hur mår personalen?

Det finns spaltmeter skrivna om KPI:er för Service Desk, här är 7 riktigt bra värden:

Kostnad per kontakt/ärende
Kundnöjdhet
Utnyttjandegrad
First Contact Resolution Rate (FCR)
First Level Resolution Rate (FLR)
Nöjda medarbetare
Aggregerad Service Desk Prestanda – balanced scorecard

Alla dessa värden är tätt kopplade till varandra och genom att mäta dessa värden kan man:

Följa och trendsätta prestation över tid
Jämföra sin prestanda med andra organisationer (benchmarking)
Identifiera styrkor och svagheter i sin Service Desk
Diagnosticera och förstå de underliggande drivkrafterna där det finns gap
Föreslå aktiviteter för att öka prestandan
Sätta mål för både individer och Service Desken i stort

Alla vill åt hög kvalitet till låg kostnad. Då är det just det man bör mäta.

Kostnad per kontakt & utnyttjandegrad
För att få en låg kostnad per kontakt måste man arbeta med att ha en hög FCR och även en hög utnyttjandegrad på Service Desken.

VARNING! en för hög utnyttjandegrad kommer oundvikligen att leda till hög personalomsättning vilket kommer påverka FCR negativt. Någonstans vid 80-90% kommer man troligen börja se stressrelaterade problem.

Höj kvalitén (dvs nöja kunder) – Höj First Contact Resolution Rate (FCR).

När man ringer vill man ha hjälp, inte bli kopplad vidare. Det är här man får klart mest pang för pengarna när det kommer till nöjda kunder.

HUR höjer man då FCR? Ja en viktig del är att ha nöjda, engagerade och kompetenta medarbetare i Service Desken. För de stannar i organisationen och kommer onekligen lära känna verksamheten.

Se till att kontinuerligt utbilda medarbetarna
Se till att utbilda nya medarbetare ordentligt, det lönar sig i längden.

Hur skapar man då nöjda medarbetare? Det finns drivor med böcker i ämnet, ett enkelt knep är att höra med sin HR-avdelning som rimligtvis bör mäta detta på något sätt, hitta den avdelningen med nöjdast medarbetare och gå och fråga dem hur de gör. Dvs benchmark inom den egna verksamheten först. Negligera inte de ”små” sakerna som fredagsfika och andra trivselfaktorer, en inbjudande arbetsplats är viktigt. Erbjud kontinuerlig utbildning och karriärplanering för de som vill.

NYHET: Vi söker fler som vill följa med oss på resan!

Är du expert på ITIL, Service Operation &/eller Support-utveckling? Då vill jag gärna komma i kontakt med dig.

Det finns verksamhetskonsulter och så finns det vi på Larsson & Co! Med ambitionen att bli Sveriges ledande konsulter inom Service Operation och Supportutveckling söker vi (supportoptimering.se) seniora konsulter/partners för expansion.

För oss är ganska enkelt, inga processer, projekt eller ramverk realisera sig själva. Allt hänger på hur involverade, engagerade och motiverade vi är som människor och anställda. Genom att kombinera Process, Ledarskap och Verktyg erbjuder vi ett helt unikt koncept som pragmatiskt realiserar våra kunders faktiska behov och förväntningar.

Vi söker dig med praktisk erfarenhet av att utveckla, införa och förvalta ITIL-processer och/eller Supportorganisationer. Du ska ha ett sinne för affärer och en pragmatisk syn på ITIL och dess bidrag.Du får gärna ha haft en linjeroll som Supportchef, Service desk chef eller IT-chef. Det viktigaste är att du har en strävan och vilja att faktiskt göra skillnad hos våra kunder. Vad karaktäriserar en konsult hos Larsson & Co?

Viljan att förstå kundens behov
Vetgirighet och nyfikenhet
Vara personligt engagerad i att lösa kundernas utmaningar
Att professionellt analysera, levererar och följa upp sina åtaganden
Exceptionell kundservice och god kommunikationsförmåga
Förmåga att arbeta bra i grupp och självständigt
Certifierad i ramverket ITIL

Det är meriterande om du har drivit IT- oh förändringsprojekt. Det är också ett plus om du har certifieringar inom ITIL eller Prince2.

Våra uppdrag finns främst inom Västra Götaland/Halland. Vi ser därför att du bor i anslutning till våra kunder. Söker du däremot partnerskap spelar din geografiska placering mindre roll.

Vilka är vi?

Larsson & Co lever som vi lär. Medarbetarna är vår viktiga resurs, punkt! Vi ser individen för den hon är och driver ett individualistiskt ledarskap där du förväntas ta ansvar och bidra till utvecklingen av företaget. Vi marknadsför oss via vårt goda renommé och har förbjudit skrivbordsprodukter som inte fungera i vardagen. Vi lägger en stolthet och ett personligt engagemang i alla våra uppdrag.

Läs mer om oss och våra tjänster Experter på ITIL och förändring – ITIL konsulter.

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 Management) med 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.

– Ladda ner Gartners analys av ITSSM-verktyg

Gartners analys av marknadens ITSSM/Support-verktyg

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.

Gartners analys av ITSSM-verktyg-2013

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

Problem Management del 4 – Hitta rätt fel

Root Cause Analysis (RCA)