Inrichting prioriteitenmatrix (urgentie x impact)

Oeh is een lastige hoor. Bij ons vult de aanmelder wel in in hoeverre ze last hebben op basis van die opties wat je zelf aangeeft. Sommige processen hebben automatisch hogere voorrang. Denk aan klantenservice die niet kan bellen of als een verhuur proces hangt (ons primair inkomen). Dus wij passen soms nog wel daarna de prioriteit aan. 

Dus voor jullie wellicht ook de vraag welk proces of applicatie heeft impact op jullie primaire processen die dus automatisch meer voorrang zouden moeten krijgen?

Wat wij overigens wel gedaan hebben is e-mail import uit. Mensen kunnen alleen telefonisch, via balie of via de selfserviceportal iets melden. Via e-mail kregen we te vaak vage meldingen of misten we heel veel informatie terwijl het onderwerp “SPOED” was bijvoorbeeld. We konden er niets mee.
Door middel van een regel in Exchange komen alleen antwoorden op mails binnen die een melding nummer hebben in het onderwerp.

Hopelijk heb je hier iets aan.

Maak je ook onderscheid in call soort? Een incident heeft normaal een andere doorlooptijd dan een service request. Dat kan nog helpen in het prioriteren.

Bij call soort hebben wij meestal een “Incident” of een “Vraag”. Bij de laatste is de prio meestal inderdaad lager. Ik weet alleen niet of je dat kun automatiseren in een prioriteiten matrix?

Om de prioriteitentabel goed in te richten op de verschillende call soorten zul je iets met de diensten  en dienstenniveaus moeten doen, volgens mij. Als je dat niet inricht, heb je alleen de eenvoudige matrix prioriteiten in de instellingen. Wij doen dat helaas zelf ook niet, maar er zijn plannen om ‘request fulfilment’ in te richten, dus daar ben ik zelf naar aan het kijken en testen op dit moment.

Goedemorgen, 
Wij werken ook met urgency en impact, zowel op onze incident formulieren als in de IT chatbot (die momenteel niet in Topdesk zit).

We hebben geprobeerd om dit zo duidelijk mogelijk te maken voor de gebruikers. Alsook een kennisartikel is beschikbaar om wat duiding over de IT services te geven.

Bij het enablen van de keuzes op de formulieren en de chatbot, was er een gigantische verhoging van de high priority tickets. Met wat change management, is dit drastisch gereduceerd, echter vooralsnog geeft onze service provider aan dat zij nog vaak te veel tickets met een hoge prioriteit binnenkrijgen.

Ik geef dit ook graag even mee, aangezien het enablen of aanpassen van deze keuzes in de incidentformulieren (die bij ons in 5 talen beschikbaar zijn) toch vrij tijdsintensief is — zowel om op te zetten als om eventueel nadien opnieuw aan te passen.
Tot op heden, hebben wij dit nog niet teruggedraaid, hebben we de afspraak dat onze IT service provider naar eigen inschatting, indien nodig, de prioriteit kan verlagen en dit als een zichtbare notitie in het ticket melden. In sommige gevallen werkt dit goed, maar het gebeurt ook dat de inschatting niet altijd correct is.

Goedemorgen, 
Wij werken ook met urgency en impact, zowel op onze incident formulieren als in de IT chatbot (die momenteel niet in Topdesk zit).

We hebben geprobeerd om dit zo duidelijk mogelijk te maken voor de gebruikers. Alsook een kennisartikel is beschikbaar om wat duiding over de IT services te geven.

Bij het enablen van de keuzes op de formulieren en de chatbot, was er een gigantische verhoging van de high priority tickets. Met wat change management, is dit drastisch gereduceerd, echter vooralsnog geeft onze service provider aan dat zij nog vaak te veel tickets met een hoge prioriteit binnenkrijgen.

Ik geef dit ook graag even mee, aangezien het enablen of aanpassen van deze keuzes in de incidentformulieren (die bij ons in 5 talen beschikbaar zijn) toch vrij tijdsintensief is — zowel om op te zetten als om eventueel nadien opnieuw aan te passen.
Tot op heden, hebben wij dit nog niet teruggedraaid, hebben we de afspraak dat onze IT service provider naar eigen inschatting, indien nodig, de prioriteit kan verlagen en dit als een zichtbare notitie in het ticket melden. In sommige gevallen werkt dit goed, maar het gebeurt ook dat de inschatting niet altijd correct is.

Eens met ​@Joost Oostindie KISS aka houd het bij P1 tot en met P4. Elke app, dienst of product met een beheercomponent is anders, dus richt prio niet te gedetailleerd dicht. eerste of tweedelijns bepaalt op basis van een goede uitvraag wat de impact is voor de klant en hoe urgent het is. 

Wij houden ons daarnaast aan wat platte afspraken: als een ticket niet raakt aan een primair bedrijfsproces of een kritische app of dienst, kun je daar geen P1 op loggen. In beheer helpt een P1 tot en met P4 vooral om je werkvoorraad te zien wat eerst aandacht vraagt. Daarna stuur je op plandatum of streefdatum, afhankelijk van het soort ticket. Een klant denkt niet in prioriteiten. Die wil graag geholpen worden. En graag snel. 

Zo had ik vroeger in het ziekenhuis een P2 of zelfs P1 zijn als er impact was op patiëntveiligheid ook al was het een servicerequest. Voor sommige ICT beheerders voelde dat vreemd, omdat er technisch gezien geen storing of security issue was. Procesmatig klopte dat wel: de prio zat niet in het tickettype, maar in de impact op het primaire zorgproces. Daarnaast ook vaak meegemaakt dat er een dienstdoende in de nacht wakker gebeld werd omdat iemands account gelocked was. En ook dan was het soms echt kritisch. Als je dan impact individu omschrijft dan heb kun je nooit hoog uit komen in prio. 

Ben wel benieuwd of jullie bij de inrichting ook rekening houden met auditeisen, wet en regelgeving, zoals NIS2, NEN, SURF of CMM. Je organisatie moet kunnen aantonen dat tickets niet alleen worden geregistreerd, maar ook logisch zijn beoordeeld, geprioriteerd en opgevolgd. Maar mssn is dat wel een ander onderwerptopic waardig.