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