[ITIL] Wat doe je met incidenten, als er een problem is

[MisterEagle]

Ik ben benieuwd hoe (er bij) jullie (wordt) om(ge)gaan met het volgende:

Wat doe je met incidenten die gekoppeld worden aan, of leiden tot, een problem registratie?

Volgens ITIL spreek je oa over een problem wanneer incidenten repeterend zijn. Maar ook proactief kunnen problems gedefinieerd worden ter preventie van incidenten.

Nu loop ik al geruime tijd tegen het volgende aan, een incident afsluiten zonder dat er een oplossing voor is voelt in mijn beleving niet goed. Daarnaast is dit lastig aan een gebruiker te verkopen. Dus, koppel je het incident aan een problem. Echter in dit geval, waar laat je dan het incident? Op de workstack van de specialisten? Terwijl er voor het oplossen van het problem wellicht een heel andere afdeling voor nodig is.

Om continu de incidenten en problems heen en weer te zetten lijkt me ook niet efficient. Maar wat doe je dan wel? Wat is de meest efficiente wijze hierin?

Overigens, geldt dezelfde vraag voor wanneer er een workaround beschikbaar is, hierna is het incident verholpen (althans de impact van de verstoring is weggenomen, dit zegt niets over de werkbaarheid van de workaround) Sluit je dan wel het incident?

[DAzN]

Wanneer je een problem record maakt, dan ga je er vanuit dat er een analyse wordt uitgevoerd die hopelijk een of meerdere changes tot gevolg heeft waarmee toekomstige incidenten worden voorkomen. Tot het zover is, registreer je normaliter een known error met dan wel een workaround of andere tijdelijke oplossing. Dus het incident kun je koppelen aan je problem record, maar zonder meer sluiten doe je niet. Je probeert de klant wel te helpen met de workaround. Overigens, als de workaround niet werkbaar is, dan is het geen workaround toch?

Het kan ook zijn dat de workaround uiteindelijk de permanente oplossing wordt. Dit kan wanneer de change te ingrijpend is en de business case niet te verantwoorden.

Dit is de theorie, Hoe dit is opgelost in jullie ITSM tool is uiteraard een tweede.

[MisterEagle]

Bedankt voor je reactie @DAzN !
Eens met wat je zegt, echter, als je dan een incident hebt waar nog geen oplossing voor is (ook geen workaround) wat doe je dan met het incident? Blijf je daar op doorwerken, of ga je juist vanuit je problem aan de slag (Dit lijkt mij de logische werkwijze, maar waar blijft dan je incident)

[Qwerty-273]

Afhankelijk van de implementatie van de tools, heb ik vaak gezien dat inderdaad of de workaround of de melding dat het bekend is en gezocht wordt naar de permanente oplossing in het incident wordt gezet en het incident gesloten wordt, waarna de mensen toegevoegd worden aan de communicatie lijst van het probleem. Maar afhankelijk van de tools en de manier van invoering binnen het bedrijf kan het ook zijn dat de incidenten open blijven staan, maar dan op naam van de problem manager. Zodat een engineer niet "lastig" gevallen wordt met incidenten die veel te lang open te blijven staan (impact op performance statistieken etc).

[Frieda]

Incident blijft open zolang er geen oplossing is. Je koppelt het incident aan het problem ticket en in het problem ticket wordt de voortgang bijgehouden. Als er een workaround is die werkt, kun je het incident dus afsluiten.

[DragonChaser]

Beste van alle system naar mijn ogen: aparte "problem" ticket aanmaken met aparte extensie en die linken naar de main ticket waar alle child tickets aan vast zitten.

Rede om dit los te houden van alle andere tickets is omdat dit gewoon een andere soort ticket is.
Een collectie van 100 problem tickets kun je dan intern verder aan elkaar linken en vannuit daar een change ticket aanmaken. Het is belangrijk om dit apart te houden omdat het makkelijker word om structurele problemen te identificeren, immers kunnen problem tickets ook "aan elkaar gerelateerd zijn / linked / related".

Verder wordt alle research naar oorzaak etc.. ook in de problem ticket gezet, een ticket dient ook als middel om team work te bevorderen. Stel er is iets, je wilt dat netwerk team ernaar kijkt, dit zet zijn resultaat in de problem ticket, vervolgens assign je de ticket naar ServerOps die bijv. in azie zit en die voegt dan zijn resultaten toe etc..

[DragonChaser]

Even snel in elkaar geflatst, doel van een problem ticket is analyzeren en hopen dat we het in de toekomst kunnen voorkomen (eerst gelijk oplossen ) . Alle tickets behalve de problem ticket, gewoon sluiten als er een workarround is. Problem ticket open laten tot research done is.

Diagram:

[ Voor 27% gewijzigd door DragonChaser op 26-11-2018 11:23 ]

[lolgast]

MisterEagle schreef op vrijdag 23 november 2018 @ 15:20:
Bedankt voor je reactie @DAzN !
Eens met wat je zegt, echter, als je dan een incident hebt waar nog geen oplossing voor is (ook geen workaround) wat doe je dan met het incident? Blijf je daar op doorwerken, of ga je juist vanuit je problem aan de slag (Dit lijkt mij de logische werkwijze, maar waar blijft dan je incident)

Het hele idee van een problem is toch omdat het een groter plaatje betreft? Waarom dan nog vanuit het incident blijven werken? In mijn ogen:
- Incidenten koppel je aan het problem maar blijft open
- Problem wordt gebruikt om de voortgang in bij te houden
- Oplossing gevonden: De behandelaar(s) van de incidenten neemt/nemen contact op met de aanmelders om te controleren of het probleem inderdaad is verholpen. Dan pas sluit je het incident

[Anoniem: 1228930]

we hebben hier te maken met twee processen. Incident en problem proces.
In feite staan deze twee processen los van elkaar want incidenten moeten altijd binnen de SLA opgelost worden en een problem kan je inplannen!

Een problem gebruik je om te onderzoeken waarom een incident (meermalen) voorkomt en om ervoor te zorgen dat die via het change proces wordt opgelost.

Zolang een incident niet opgelost is blijft die openstaan totdat hier een (tijdelijke) oplossing voor gevonden wordt. Daarna kan je het incident afsluiten. (Als het incident nog niet is afgesloten, zorg er dan wel voor dat je het incident dagelijks update zodat de aanmelder het proces kan blijven volgen).
Check nog even of het incident of incidenten aan de problem zijn gekoppeld.

Als er een workaround is toegepast, zet dan die oplossing in de problem met daarin zoveel mogelijk informatie zodat men bij het onderzoek daar gebruik van kan maken.
Als men accepteert dat de workaround de definitieve oplossing is, zet die dan in de KEB!

dus nog even kort samengevat:
- Incidenten gaan altijd voor en moeten zo snel mogelijk opgelost worden. (kan soms even langer duren).
- Problem maak je aan als je niet weet waardoor het probleem wordt veroorzaakt en onderzoek nodig is.
- Koppel de incidenten aan de problem. (ook de afgesloten incidenten).
Na onderzoek, en je weet de (definitieve) oplossing, dan maak je een change aan. Pas na het sluiten van de change sluit je ook de problem.