• MisterEagle
  • Registratie: Juli 2010
  • Laatst online: 12:26
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
  • Registratie: April 2000
  • Niet online
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
  • Registratie: Juli 2010
  • Laatst online: 12:26
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
  • Registratie: Oktober 2001
  • Laatst online: 18:37

Qwerty-273

Meukposter

***** ***

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

Erzsébet Bathory | Strajk Kobiet | Met 2 armen heb je meer armen dan de gemiddelde mens.


  • Frieda
  • Registratie: Mei 2002
  • Niet online
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
  • Registratie: Mei 2013
  • Laatst online: 13-01 18:33
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
  • Registratie: Mei 2013
  • Laatst online: 13-01 18:33
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 :P ) . Alle tickets behalve de problem ticket, gewoon sluiten als er een workarround is. Problem ticket open laten tot research done is.

Diagram:
https://imgur.com/a/LUPfFwJ

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


  • lolgast
  • Registratie: November 2006
  • Laatst online: 22:48
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

Acties:
  • 0Henk 'm!

  • Jan en ITIL
  • Registratie: Juli 2019
  • Laatst online: 05-07-2019
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.
Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee