Problem Management enligt ITIL

Published 2:20 e m

Problem Management enligt ITIL

I dagens moderna IT-miljöer är effektiv hantering av problem en avgörande faktor för att säkerställa smidiga driftsättningar och hög tillgänglighet. ITIL, som står för IT Infrastructure Library, är en ramverk som tillhandahåller bästa praxis och riktlinjer för att hantera IT-tjänster på ett strukturerat och effektivt sätt. I denna artikel kommer vi att utforska Problem Management enligt ITIL och diskutera dess vikt och processer.

Vad är ITIL?

ITIL är en samling av bästa praxis och riktlinjer som utvecklades av brittiska myndigheten för handel och industri i slutet av 1980-talet. Sedan dess har ITIL blivit en global standard för IT-Service Management och används av organisationer över hela världen. Genom att tillämpa ITIL-ramverket kan organisationer förbättra sin IT-serviceleverans, minimera driftsavbrott och möta affärsbehov på ett bättre sätt.

ITIL:s historia och utveckling

ITIL-ramverket utvecklades från erfarenheter och bästa praxis som användes av brittiska myndigheter och privata företag. Det uppdateras regelbundet för att ständigt anpassa sig till de föränderliga behoven hos IT-industrin och för att inkludera de senaste teknologierna och trenderna. Genom åren har ITIL genomgått flera versioner och utvidgningar för att bättre stödja organisationers IT-Service Management.

ITIL:s grundläggande principer

ITIL bygger på ett antal grundläggande principer som hjälper till att uppnå effektivitet och kvalitet i IT-Service Management. Dessa principer inkluderar bland annat:

Kundfokus: Att sätta kundernas behov och förväntningar i centrum för IT-Service Management.
Kontinuerlig förbättring: Att sträva efter ständiga förbättringar och optimering av processer.
Standardisering: Att använda gemensamma processer och metoder för att säkerställa enhetlighet och kvalitet i leveransen.
Samarbete: Att främja samarbete och kommunikation mellan olika IT-avdelningar och intressenter.

ITIL är inte bara en metodik för IT-Service Management, utan det är också en filosofi som främjar en holistisk syn på IT-verksamheten. Genom att tillämpa ITIL-ramverket kan organisationer skapa en kultur av kontinuerlig förbättring och effektivitet.

En av de viktigaste fördelarna med att använda ITIL är att det ger organisationer en gemensam referenspunkt och ett gemensamt språk för att kommunicera om IT-tjänster och processer. Detta underlättar samarbetet mellan olika IT-avdelningar och intressenter och minskar risken för missförstånd och felaktig kommunikation.

En annan fördel med ITIL är att det hjälper organisationer att fokusera på kundens behov och förväntningar. Genom att sätta kunden i centrum för IT-Service Management kan organisationer leverera bättre service och skapa nöjda och lojala kunder.

ITIL-ramverket innehåller också en mängd olika processer och metoder som organisationer kan använda för att förbättra sin IT-Service Management. Dessa inkluderar bland annat incidenthantering, Problem Management, förändringshantering och kapacitetshantering.

Genom att tillämpa dessa processer och metoder kan organisationer effektivisera sina IT-tjänster, minska driftsavbrott och förbättra kvaliteten på sin IT-serviceleverans.

ITIL har också en stark koppling till andra ramverk och metoder inom IT-servicehantering, såsom COBIT, ISO/IEC 20000 och Lean IT. Genom att kombinera ITIL med dessa andra ramverk kan organisationer skapa en integrerad och holistisk syn på IT-servicehantering och uppnå ännu bättre resultat.

I slutändan handlar ITIL om att skapa en kultur av kontinuerlig förbättring och effektivitet inom IT-Service Management. Genom att tillämpa ITIL-ramverket kan organisationer förbättra sin IT-serviceleverans, minimera driftsavbrott och möta affärsbehov på ett bättre sätt.

Förståelse för Problem Management

För att kunna hantera problem på ett effektivt sätt är det viktigt att förstå vad Problem Management innebär och vilken roll den spelar inom ITIL-ramverket.

Problem Management är en process inom ITIL som syftar till att identifiera och eliminera underliggande orsaker till driftsavbrott och återkommande incidenter. Genom att genomföra en systematisk och strukturerad analys av problemet kan IT-avdelningen förhindra att incidenter upprepas och därmed minska påverkan på affärsprocesserna.

En viktig aspekt av Problem Management är att förstå att det inte bara handlar om att lösa enskilda incidenter, utan att identifiera och åtgärda de underliggande problemen som orsakar dessa incidenter. Detta kan vara allt från tekniska fel och brister i systemet till felaktiga processer eller bristande kompetens hos användarna.

Genom att ha en väldefinierad process för Problem Management kan organisationer snabbt identifiera och åtgärda problem innan de leder till större incidenter eller driftsavbrott. Detta kan spara tid, pengar och resurser för företaget och bidra till en mer effektiv och pålitlig IT-miljö.

Definition av Problem Management

Problem Management är den process inom ITIL som syftar till att identifiera och eliminera underliggande orsaker till driftsavbrott och återkommande incidenter. Genom att genomföra en systematisk och strukturerad analys av problemet kan IT-avdelningen förhindra att incidenter upprepas och därmed minska påverkan på affärsprocesserna.

En viktig del av Problem Management är att kunna skilja mellan en incident och ett problem. En incident är en enskild händelse som påverkar användaren eller affärsprocessen, medan ett problem är en underliggande orsak till en eller flera incidenter. Genom att identifiera och åtgärda problem kan IT-avdelningen förhindra att incidenter upprepas och därmed minska påverkan på affärsprocesserna.

En effektiv Problem Management innebär att ha en tydlig process för att rapportera, registrera, prioritera och åtgärda problem. Det är också viktigt att ha en strukturerad metod för att analysera problem och identifiera underliggande orsaker. Detta kan inkludera att samla in data och information, genomföra tekniska analyser och involvera olika intressenter och experter.

Vikten av Problem Management inom IT

Problem Management är en viktig del av ITIL-ramverket då den hjälper organisationer att minska incidenternas negativa inverkan på affärsprocesserna och förbättra kvaliteten på IT-tjänsterna. Genom att identifiera och åtgärda underliggande orsaker till problem kan företag undvika att störa sina kunders verksamhet och förlora potentiella affärsmöjligheter.

En effektiv Problem Management kan också bidra till att förbättra IT-avdelningens rykte och förtroende inom organisationen. Genom att snabbt och effektivt lösa problem kan IT-avdelningen visa att de är kompetenta och pålitliga och att de har förmågan att hantera och förhindra incidenter.

En viktig del av Problem Management är att ha en proaktiv inställning och att inte bara reagera på incidenter när de inträffar, utan att försöka förutse och förebygga problem innan de uppstår. Detta kan göras genom att analysera tidigare incidenter och problem, genomföra riskanalyser och implementera förebyggande åtgärder och förbättringar.

Genom att ha en väl fungerande Problem Management kan organisationer också dra nytta av möjligheterna till kontinuerlig förbättring. Genom att analysera och lära sig av tidigare problem kan företag identifiera mönster och trender och implementera åtgärder för att förhindra att liknande problem uppstår i framtiden.

Problem Managementprocess enligt ITIL

ITIL-ramverket tillhandahåller en strukturerad process för att hantera problem. Denna process kan delas upp i flera steg:

Identifiering och registrering av problem

Det första steget i Problem Managementprocessen är att identifiera och registrera problemen. Det kan göras genom att övervaka incidenter och undersöka de mer komplexa eller återkommande incidenterna. Genom att dokumentera problemen kan IT-avdelningen analysera mönster och identifiera underliggande orsaker till problemen.

En viktig del av identifierings- och registreringsprocessen är att involvera användarna. Genom att samla in feedback och rapporter från användarna kan IT-avdelningen få en bättre förståelse för problemens omfattning och påverkan på verksamheten. Detta kan hjälpa till att prioritera och lösa problemen mer effektivt.

Klassificering och prioritering av problem

När problemen har identifierats och registrerats är nästa steg att klassificera och prioritera dem. Detta görs baserat på faktorer som inverkan på verksamheten och brådskande åtgärdsbehov. Genom att tilldela rätt prioritering kan IT-avdelningen fokusera på att lösa de mest kritiska problemen först.

En viktig aspekt av klassificeringen och prioriteringen är att ta hänsyn till användarnas behov och förväntningar. Genom att kommunicera med användarna och förstå deras krav kan IT-avdelningen bättre bedöma vilka problem som har högst prioritet och vilka som kan vänta.

Undersökning och diagnos

Efter att problemen har klassificerats och prioriterats är det dags att undersöka och diagnostisera orsakerna till problemen. Detta kan kräva en noggrann analys av systemet, loggfiler och annan relevant information. Genom att identifiera de underliggande orsakerna kan IT-avdelningen fatta informerade beslut om lämpliga lösningar.

Under undersöknings- och diagnosprocessen är det viktigt att ha en tvärfunktionell arbetsgrupp som kan samarbeta och dela kunskap. Genom att involvera experter från olika områden kan IT-avdelningen få en bredare och djupare förståelse för problemet och därigenom hitta mer effektiva lösningar.

Lösning och stängning

När diagnosen är klar och lämpliga lösningar har hittats, är det dags att implementera dessa lösningar och lösa problemen. Efter att problemet har lösts och lösningen har implementerats, är det viktigt att utvärdera resultatet och säkerställa att problemet inte återkommer. Genom att stänga problemrapporten kan IT-avdelningen slutföra Problem Managementprocessen.

En viktig del av lösningen och stängningsprocessen är att kommunicera med användarna och informera dem om åtgärderna som har vidtagits. Detta kan hjälpa till att återupprätta användarnas förtroende och minska eventuell oro.

Rollerna inom Problem Management enligt ITIL

För att säkerställa effektiv Problem Management definierar ITIL också olika roller och ansvarsområden. Här är några av de viktiga rollerna:

Problemhanterarens roll

Problemhanteraren har ansvaret att leda och utföra den dagliga Problem Managementprocessen. De ansvarar för att identifiera, analysera och lösa problem baserat på ITIL-ramverket och bästa praxis. Problemhanteraren samarbetar också med andra IT-avdelningar för att säkerställa en effektiv hantering av problemen.

IT-chefens roll

IT-chefen har det övergripande ansvaret för Problem Managementprocessen och säkerställer att ITIL-ramverket följs. De ansvarar för att tillhandahålla resurser och stöd till problemhanterarna samt utvärdera effektiviteten av Problem Managementprocessen. IT-chefen har också ansvaret för att kommunicera problemens status och framsteg till intressenter och ledningen.

Användarens roll

Användarna har en viktig roll inom Problem Managementprocessen. Genom att rapportera incidenter och problem i tid hjälper användarna till att identifiera och lösa problemen snabbare. Det är viktigt att användarna samarbetar med IT-avdelningen genom att tillhandahålla tillräcklig information och feedback för att underlätta diagnosen och lösningen av problemet.

Sammanfattningsvis är Problem Management en viktig del av ITIL-ramverket och hjälper organisationer att effektivt identifiera, analysera och lösa problem som kan påverka IT-tjänsterna och verksamheten negativt. Genom att tillämpa ITIL:s bästa praxis och följa den strukturerade Problem Managementprocessen kan organisationer förbättra sin driftsäkerhet och kundnöjdhet, samtidigt som de minskar tid och resurser som krävs för att hantera problem.

Frukostmöte 7/5 – Problem med Problem

Hur kan vi använda Problem Management för att minimera sannolikheten för och påverkan av incidenter?

Vi ser några nyckelfaktorer till ett framgångsrikt arbete med Problem Management.

Tydligt ägarskap:
- För att lyckas är det viktigt att någon får ansvar för att driva arbetet med Problem Management för att skapa arbetssätt, rutiner som hjälper oss att identifiera problem.
Etablerat arbetssätt:
- Arbetet med Problem Management bör planeras och bedrivas på ett strukturerat sätt. Detta för att vi kontinuerligt skall identifiera problem och åtgärda de mest prioriterade problemen så snart som möjligt.
- Detta innebär ett tydligt arbete kring de tre delarna:
  - Problem Identification
  - Problem Control
  - Error Control
Proaktivt och reaktivt arbete:
- Genom att titta på vilka risker vi ser och vilka problem vi kan förutse kan vi förebygga incidenter och på så sätt undvika incidenterna helt alternativt skapa en workaround i förväg vilket minskar påverkan av de som vi inte kan lösa.

Vill du ha fler tips och idéer kring Problem Management titta på presentationen på vår YOuTube-kanal.

Frågor & svar

Under frukostmötet fick vi in flera frågor, vi hann inte med att besvara alla. Men du hittar våra tankar kring dessa frågor här.

Först vill vi bara påpeka att det är svårt att ge generella svar eftersom hur vi implementerar och använder ITIL varierar från organisation till organisation.
ITIL pratar om ”adopt and adapt” vilket betyder att vi skall anpassa ramverket efter oss men också anpassa oss efter ramverket. Detta är det givetvis viktigt att ta hänsyn till när ni läser svaren.

Vill du diskutera hur det ser ut hos er eller mer i detalj kring en fråga är du givetvis välkommen att kontakta oss.

Vem ska äga ett problem?
- När vi har identifierat ett problem behöver den person eller det team som hanterar det berörda systemet, tjänsten, produkten, komponenten etc. få ägarskap för hur vi kan ta hand om detta problem. Dels för att se om vi kan skapa en Workaround för att minimera påverkan men även för att se om vi kan identifiera lösningar för att åtgärda problemet.
  Det kan ibland finnas flera möjliga ägare till ett problem och vi rekommenderar då att den som är utsedd till Problem Manager får mandat att delegera ansvaret för det specifika problemet.
I en organisation som jobbar med agile och devOps team – var passar problem, incident, och transition management in? Som egna delar/team/funktioner eller inbyggda i DevOpsteamen?
- Vår bild är att det gäller att vi skapar en tydlighet kring vem som ansvarar för vad här. Vi skulle föreslå följande arbetssätt:
  - Service Desk bör ta emot, prioritera och vid behov eskalera incidenter.
  - De agila/devops teamen behöver vid behov kunna bistå med lösning av Incident.
  - Problem management bör hanteras enligt frågan här ovan.
  - Transition hanteras normalt i de agila teamen, självklart i samarbete med Service Desk.
Finns det ett hinder att samma personer som har driftansvaret för systemet/infrastrukturen och är den som äger Problem management för detta område?
- Risken som vi ser är att det kan bli suboptimering om vi inte hittar ett sätt att prioritera och hantera Problem inom olika områden i relation till varandra. Det finns en styrka i att ha en ”oberoende part” som ansvarar för Problem Management.
  Om vi gör det blir det viktigt att vi använder ITIL’s Guiding Principle ”Collaborate and promote visibility” för att ta med rätt personer i beslut och synliggöra det vi jobbar med.
Hur kan vi prioritera lösning av problem istället för att bara använda workarounds hela tiden?
- Med hjälp av ett strukturerat arbete med Problem Management.
- Skapa en process för att kontinuerligt analysera och utvärdera de incidenter som hänt samt att gå igenom de workarounds som ni har och värdera (räkna på) tiden ni lägger på att använda dessa workarounds och jämför det med tiden/kostnaden för att åtgärda problemet.
Min tanke är att Problem oftast angrips på samma sätt som Incident, och man missar den mer systematiska delen i Problem Management som inte är lika viktig i Incident Management.
- Vi ser också detta och det är anledningen till att vi anser att det bör finnas någon som är uttalat ansvarig för att driva och inspirera till ett aktivt Problem Management och att det även innebär proaktivt arbete.
- Problem Manager kan driva arbetet framåt för att undvika just detta.
Vem och hur gör man bedömningen om problemhanteringen är så omfattande så lösningen istället är att ”börja om” är det en ren kostnadsfråga eller finns det stöd i ITIL som vägleder en att ta beslutet att välja helt nytt istället?
- ITIL beskriver i den Guiding Priciple som kallas ”Start where you are” mer om hur vi bör tänka kring detta. Rekommenderar att läsa den även om den inte ger exakta svar på hur vi skall göra så hjälper den till med hur vi bör tänka.
- Vi rekommenderar att vi först ta reda på vad nuvarande tjänst/system/lösning gör för att säkra att eventuella ersättningssystem täcker detta.
- Vi behöver också göra en ordentlig riskbedömning, dels av problemet samt på bytet och det nya systemet. Hur vi sen värderar det beror på fall till fall vilket gör det svårt att svara på rent generellt. Men om värdet/nyttan av att byta överväger risken och kostnaden är det givetvis rätt att byta.
Hur bör man jobba för att ”mata” Problem Manager med info. dvs hur ger man PM underlag för att hen ska kunna analysera och prioritera ev.?
- För att göra detta behöver vi sätta upp ett system för insamling av information, det kan till exempel handla om att skapa rapporter för:
  - Antal Incidenter per klassificering
  - Major incident rapporter
  - Information från Partners & Suppliers
  - Samt information om potentiella problem i nya och befintliga system

Vill du veta mer?

Kontakta oss gärna för mer information eller bara för att diskutera mer kring ämnet.

Du hittar denna och tidigare frukostmöten på vår Youtube-kanal! Klicka här!

Hör gärna av dig!

Telefon: 031-337 57 50
Mail: info@larssonco.com

Klicka på bilden!

Klicka på bilden för att komma till presentationen!

Nästa frukostmöte

11 juni är det dags för
”Agile med ITIL – del 2”.

Läs mer och anmäl dig här:

ITIL® Frukost

Problem Management del 4 – Hitta rätt fel

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

Problem Management, del 3 processerna hör ihop

Ni har säkert hört uttrycket att ”Ingen kedja är starkare än sin svagaste länk”. Detta gäller också sambandet mellan incident, problem och change management. Om en av dessa processer inte fungerar tillfredställande, så är risken stor att de andra inte heller gör det, slutresultatet kommer i alla fall inte blis så bras om det kunde ha blivit.

Som vi har nämnt i föregående artiklar (del 1 & del 2) om Problem Management så är INTE incidentprocessen designad för att ta hand om incidenter som återkommer eller som man inte har löst inom en relativt kort tid (surdegar) på ett bra och strukturerat sätt. Incident management-processens syfte och mål är att återställa en IT-tjänst/system/lösning så snabbt som möjligt och minimera påverkan för verksamheten. Det dedikeras varken tid eller resurser inom incident management för att ”stanna upp” och göra en mer djuplodande undersökning för att hitta grundorsaken till varför te.x. återkommande incidenter uppstår.

Problem management-processen däremot, är designad för att tillåta teknikerna att ”gå in mer på djupet” i sin felsökning. Det bör också vara med i beräkningarna att det får ta extra tid att hitta grundorsaken till varför t.ex. vissa typer av incidenter återkommer. Man bör också ha en person som är utsedd till Problem Manager och som är ansvarig för att processen förvaltas på bästa sätt. Det är också önskvärt att ha tillgång till tekniker som enbart jobbar med problemhantering eller som avsätter schemalagd tid för att förvalta och utveckla problemhanteringen.

Change management säkerställer att alla ändringar som görs är planerade, godkända och testade. D.v.s. changeprocessen kan aktiveras med input från incident eller problemprocessen.

Slutsatsen av detta resonemang är att de tre processerna inte bara har ett samband, utan är djupt involverade och beroende av varandra. De kan både stötta och komplettera varandra på ett utmärkt sätt. Ju mer vi resonerar och diskuterar med våra kunder om de tre processernas relationer desto mer inser vi och kunderna, att problemprocessen är ett måste för att få en stabil IT-drift och effektiv IT-support!

Läs artikeln, Problem Management – del 1

Läs artikeln, Problem Management – del 2

Av Robert Johnsson

Problem Management, del 2 – en avgörande process

Problem management är ITIL-processen som proaktivt förhindrar incidenter från att uppstå och minimera påverkan från de incidenter som inte kan förhindras.

Problem management-processen är ofta en av de minst prioriterade processerna hos organisationer. När vi frågar organisationer vilka processer de har infört, så är vår erfarenhet att de flesta inför Incident Management, Change Management och ibland Service Level Management och tjänstekatalogen. Däremot saknas oftast Problem Management-processen. En av anledningarna kan vara att man inte ser fördelarna i det korta perspektivet eller att man tror att det räcker med Incident Management-processen. Vi är av en helt annan uppfattning, vi tycker att Problem Management är en av de viktigaste processerna vi har. Den spar tid, pengar användarnas frustration!

Brandsläckning eller en enkel process?

För några år sedan var vi med och lanserade en ny landsomspännande TV-tjänst. Allt var frid och fröjd till en början. Sedan började barnsjukdomar att visa sig mer och mer. Incidenterna skickades likt en flipperkula mellan ett antal olika enheter. Samma incident kunde komma tillbaka till första linjen, ibland tre gånger eller mer, olöst. Alltid med förklaringen att ”den incidenten är inget vi hanterar”. Det skapade naturligtvis stor irritation och ett mindre krig pågick under en tid. Till slut tog några kloka människor ett samlat grepp för att lösa upp de värsta knutarna. Man samlades i en grupp för att diskutera situationen, man analyserade orsak och verkan, man gjorde en plan för att eliminera strulet och man satte en ansvarig person på att leda arbetet.

När vi några år senare fick höra talas om ITIL och bland annat processen Problem Management, var det som att ljuv musik uppstod! Det var mer eller mindre så vi hade jobbat, vi hade använt sunt förnuft och löst det prekära läget. Men, och det är ett stort MEN. Tänk om vi hade haft Problem Management-processen på plats redan från början, tänk om vi redan innan alla barnsjukdomar dök upp hade haft en process där alla visste vad som förväntades av en och vilka aktiviteter som ska utföras tillsammans med vem som gör vad, ja då hade situationen aldrig uppstått från början.

Så, för er som inte har en Problem Management-process på plats säger vi bara en sak, se till att ni har mycket personal över som kan jobba med brandsläckning eller inför en enkel Problem Management-process enligt ITIL. Ett bra steg på vägen är att gå en ITIL Foundation hos Larsson & Co.

Problem Management del 3

Läs artikeln, Problem Management – del 1

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

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 incidenter 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:

Förebygga att problem uppstår
Eliminera återkommande incidenter
Minimera påverkan av de incidenter som inte kan förhindras

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

Problem Management enligt ITIL

Vad är ITIL?

ITIL:s historia och utveckling

ITIL:s grundläggande principer

Förståelse för Problem Management

Definition av Problem Management

Vikten av Problem Management inom IT

Problem Managementprocess enligt ITIL

Identifiering och registrering av problem

Klassificering och prioritering av problem

Undersökning och diagnos

Lösning och stängning

Rollerna inom Problem Management enligt ITIL

Problemhanterarens roll

IT-chefens roll

Användarens roll

Hur kan vi använda Problem Management för att minimera sannolikheten för och påverkan av incidenter?

Frågor & svar

Vill du veta mer?

Klicka på bilden!

Nästa frukostmöte

11 juni är det dags för ”Agile med ITIL – del 2”.

Läs mer och anmäl dig här:

Root Cause Analysis (RCA)

Enkla men kraftfulla metoder

Kepner-Tregoe

5-Why

NÄTVERKSLEDARE/ARRANGÖRER

Problem Management, del 3 processerna hör ihop

Problem Management, del 2 – en avgörande process

Brandsläckning eller en enkel process?

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

En bra process för surdegar

Nyheter

De viktigaste ITIL-processer som alla IT-organisationer bör implementera för att strömlinjeforma IT

Läs vidare →