Afschalen prioriteit

Zoals je aangeeft maak je een prio 1 melding aan wanneer er een grote storing is. In mijn optiek sluit je deze melding zodra de functionaliteit hersteld is.

De opvolging zoals het toevoegen van documentatie, een root cause analysis of maatregelen om kans op herhaling te minimaliseren kun je naderhand toevoegen in de (gesloten) melding of borgen met een eigen melding, wijziging, operationele activiteit of probleem.

Hoi Frank,

Mijn organisatie gebruikt de ODatafeed om onze reportingtool te voeden. Via de Odata feed kun je bij de  'IncidentSnapshots' tabel. Dit is de het geschiedenis tab van een melding waar je ziet wat de oude en nieuwe waarde is van bijvoorbeeld prioriteit. Ik gebruik dit zelf om bij te houden hoe vaak een melding van behandelaarsgroep en leverancier is geswitched.
Het kennisitem hieronder geeft informatie hierover.
 

KI 10941 - Retrieve historic information from incidents through OData

It is possible to export the status history of incidents through the OData feed table IncidentSnapshots. This table keeps track when the status of an incident has changed. It also stores other values the incident had when its status changed: category, operator, priority, ...
Keep in mind, this OData feed table works differently from the TOPdesk table for incident history: mutatie_incident (audit trail - see KI 5577 for more information). This TOPdesk table tracks when some specific, predefined fields have been changed and gets updated each time these fields are edited.

The table IncidentSnapshots is also used as a basis for the Duration distribution report and Response time compliance report, which are inbuilt functionalities. An introduction to these reports can be found in KI 9432 - Reports: how to create a Duration Report.
 

Notes

• KI 13627: OData: general information
• KI 10295: Field names in Datadict and the OData feed
• KI 11320: OData: Is it possible to report on duration?
• KI 13798: OData: which server-side filters are available in the duration tables?

Herkenbaar.

Onze voorkeur is dat je, zodra impact en urgentie zijn bepaald, de prioriteit achteraf niet meer aanpast. Je wilt de audittrails zuiver houden en inzicht behouden in verkeerde inschattingen, zodat beheer hiervan leert en steeds beter de juiste prioriteit bepaalt en daarmee efficienter werkt. Als de melder verder kan, zelfs met een approved workaround, dan sluit je het incident. 

En eens met Ruud: via problems onderzoek je een structurele oplossing, lever je een rca op, of voor je andere verbeteringen door zodat het incident niet meer voorkomt en als dit wel het geval is (bekende fout), je het zo snel mogelijk kunt oplossen.

Anders zou je kunnen overwegen om met een sub priority te kunnen gaan werken (bv een p1a). 

Wij werken met extra statussen (waiting update engineer)

Dank jullie wel voor de reacties.

Wij gaan onze procedure hiervoor aanpassen dat de prioriteit niet wordt gewijzigd, de melding snel wordt gesloten en later kan worden bijgewerkt.

Wij laten ook de prio staan zodra deze is bepaald. 

Volgensmij kan je oude data ophalen van een kaart als je het aanpast. Voor mij zou echter de voorkeur hebben om het te laten staan zoals het is, als er vervolgens een onderliggend probleem is, waarvan de P1 eigenlijk al is opgelost, dan maak ik een nieuwe aan, de P1 is opgelost, en ga ik project gebaseerd werken voor dat langdurigere probleem.