De voordelen van een prioriteitenmatrix

Wat zijn de voordelen van het gebruik van een prioriteitenmatrix?

Het gebruik van een prioriteitenmatrix helpt u om taken in de beste volgorde voor het bedrijf af te handelen. Dit omvat onder meer het beheren van incidenten, problemen, veranderingen en projecten. Door de meest geschikte prioriteit te bepalen met behulp van de matrix, kunnen uw medewerkers consistent zijn in hoe ze beslissen in welke volgorde taken moeten worden aangepakt. Dit geeft hen het vertrouwen om te doen wat zij denken dat goed is, aangezien de prioriteitenmatrix door alle medewerkers op dezelfde manier zal worden gebruikt. Dit zal ook de tevredenheid van de klanten over uw diensten verbeteren. Als u de prioriteitenmatrix deelt met uw klanten, kunnen zij begrijpen waarom bepaalde incidenten eerder worden afgehandeld dan andere. Een prioriteitenmatrix kan de onderlinge verhoudingen tussen IT, ITSM en het bedrijf verbeteren. Als u de prioriteitenmatrix ontwikkelt als een gezamenlijke inspanning van al deze partijen, zullen ze elkaars perspectieven voor het prioriteren van taken beter kunnen begrijpen.

Door te verwoorden en te documenteren hoe impact en urgentie worden gebruikt om prioriteiten te bepalen met behulp van de matrix, kan onzekerheid worden weggenomen over hoe de IT beslist in welke volgorde aan taken moet worden gewerkt. Het gebruik van een prioriteitenmatrix kan ook helpen om te voorkomen dat de IT het ene deel van het bedrijf of een bepaald individu bevoordeelt boven anderen bij het bepalen van de prioriteit van taken.

Een prioriteitenmatrix is vooral handig wanneer support teams overbelast raken en meer taken hebben dan ze tegelijkertijd aankunnen. Als er geen matrix wordt gebruikt om prioriteiten te bepalen, bestaat het risico dat medewerkers kunnen kiezen waar ze aan willen werken. Dit kan leiden tot vertragingen bij het oplossen van taken met een hoge urgentie of impact, zoals incidenten. Door een prioriteitenmatrix te gebruiken om te bepalen wanneer een incident een groot incident is, wordt de situatie vermeden waarin veel middelen worden toegewezen aan een incident dat onder druk van het bedrijf prioriteit heeft gekregen, maar in werkelijkheid geen hoge impact heeft. Ook het prioriteren op basis van druk vanuit gebruikers in plaats van de prioriteitenmatrix zorgt ervoor dat incidenten worden uitgesteld, die eigenlijk prioriteit zouden moeten hebben.

Hoeveel prioriteiten moet u hebben?

Een prioriteitenmatrix kan zo veel verschillende prioriteiten ondersteunen als u wilt. Het is echter aanbevolen om niet meer dan vijf prioriteiten te hebben, veel organisaties hebben er maar drie. Dit komt doordat complexiteit en verwarring toenemen naarmate het aantal prioriteiten in de matrix toeneemt. Het concept van een hoge prioriteit, een lage prioriteit en een gemiddelde prioriteit, elk met een bijbehorende numerieke waarde wordt algemeen geaccepteerd. Als uw prioriteitenmatrix meer dan drie waarden bevat, kan het moeilijk zijn om de juiste beschrijving te gebruiken voor elke prioriteit.

Gewoonlijk krijgt een lagere prioriteit een hogere waarde, en vice versa. Daarom is in een prioriteitenmatrix een prioriteit van 1 de hoogste en moet deze altijd als eerste worden behandeld. Dit kan in strijd zijn met andere nummersystemen, zoals beveiligingsniveaus, waarbij het hoogste nummer de hoogste prioriteit en het hoogste risico voor een organisatie vormt. Het is erg belangrijk om te begrijpen wat wordt bedoeld met elke numerieke waarde in een prioriteitenmatrix, omdat dit verwarring voorkomt.

Voorbeelden van verschillende prioriteiten in een prioriteitenmatrix

Het is een goed idee om uw medewerkers voorbeelden te geven van de verschillende prioriteiten die uit een prioriteitenmatrix kunnen worden afgeleid. Dit zal helpen om de matrix te begrijpen en zal er waarschijnlijk toe leiden dat medewerkers de prioriteitenmatrix op een intelligente manier zullen gebruiken.

Als we de eerder aangehaalde prioriteitenmatrix als voorbeeld nemen, zijn er vijf mogelijke prioriteiten, met een prioriteit van 1, afgekort tot P1, als de hoogste.

Taken met zeer hoge prioriteit

Een taak die in de voorbeeldmatrix is gedefinieerd als een P1 heeft een hoge impact en een hoge urgentie. Deze taken zijn meestal van cruciaal belang voor de voortdurende werking van de organisatie, of vormen het grootste risico voor de organisatie. P1-taken uit de prioriteitenmatrix kunnen het volgende omvatten:

• Een zeer belangrijk systeem of een essentiële service is niet beschikbaar
• Een grote hoeveelheid gegevens is beschadigd
• Alle gebruikers zijn betroffen en kunnen hun werk niet uitvoeren
• Zeer belangrijke gebruikers kunnen de systemen niet gebruiken
• Er is een vermoedelijke inbreuk op de IT-beveiliging die alle gebruikers kan treffen
• Er zijn mogelijke inbreuken op wet- of regelgeving

Voorbeelden van storingen die kunnen resulteren in een P1 uit de prioriteitenmatrix zijn volledige netwerkstoringen, wijdverbreide virusinfecties, denial-of-service-aanvallen, e-mailstoringen en volledige uitval van applicaties.

 

Taken met hoge prioriteit

Een P2-taak in de voorbeeldmatrix heeft een gemiddelde impact en een hoge urgentie, of een hoge impact en een gemiddelde urgentie. Dit zijn taken waarbij het belangrijk is om snel tot een oplossing te komen, maar het effect voor de organisatie is niet zo groot als bij een P1-taak. P2-taken uit de prioriteitenmatrix kunnen het volgende omvatten:

• Een volledig systeem of een service is niet beschikbaar

• Gegevens zijn beschadig, met gevolgen voor verschillende gebruikers

• Een groot deel van de gebruikers is betroffen en kan hun werk niet uitvoeren

• Er is een vermoedelijke inbreuk op de IT-beveiliging die sommige gebruikers treft

Voorbeelden van storingen die kunnen resulteren in een P2 uit de prioriteitenmatrix zijn gedeeltelijke netwerkstoringen, lokale virussen, verlies van bepaalde e-mailfunctionaliteit en uitval van niet-essentiële toepassingen.

 

Taken met normale prioriteit

Aan taken met een normale prioriteit wordt doorgaans prioriteit P3 of P4 toegekend in de prioriteitenmatrix. Dit zijn taken waarbij:

• Standaardfunctionaliteit beschikbaar is, maar met beperkingen

• Alternatieve werkwijzen beschikbaar zijn

• Een laag aantal gebruikers getroffen wordt

Dit zijn vaak routinematige IT-problemen, waaronder printerstoringen of problemen met applicaties die slechts enkele gebruikers treffen. Deze problemen moeten worden opgelost, maar ze zijn niet zo urgent als taken die volgens de prioriteitenmatrix een hogere prioriteit hebben. Dus als er openstaande taken zijn met een hogere prioriteit uit de matrix, moeten deze worden afgehandeld vóór deze P3- en P4-taken

 

Taken met lage prioriteit

Taken die zijn ingeschaald als P5 in de prioriteitenmatrix hebben een lage impact en een lage urgentie. Deze taken hebben de laagste prioriteit. Het zijn kleine problemen waarbij de gebruikers hun zakelijke activiteiten nog kunnen uitoefenen. P5-taken zijn meestal cosmetische problemen of kleine ergernissen. Voorbeelden van P5-taken die kunnen voortvloeien uit het gebruik van een prioriteitenmatrix zijn spelfouten in rapporten of een slechte layout op een webpagina. Ze moeten nog steeds worden opgelost, maar mogen nooit worden geprioriteerd boven taken met een hogere prioriteit.

 

Richtlijnen voor het gebruik van een prioriteitenmatrix

Het is voor elke organisatie een goed idee om richtlijnen op te stellen voor het gebruik van de prioriteitenmatrix. Deze richtlijnen moeten zinvolle voorbeelden bevatten voor taken met elke prioriteit uit de matrix. De richtlijnen voor het gebruik van de prioriteitenmatrix moeten in de loop der tijd worden bijgewerkt als er nieuwe voorbeelden worden gevonden en problemen met onjuiste prioriteiten in staan.

De richtlijnen moeten specifiek zijn. Zo is ‘waar meerdere gebruikers worden geraakt’ voor interpretatie vatbaar. Daarom dienen precieze aantallen die relevant zijn voor de organisatie in kwestie te worden gebruikt in de richtlijnen voor de prioriteitenmatrix. Bijvoorbeeld 'waar meer dan 10 maar minder dan 100 gebruikers zijn getroffen'. De richtlijnen voor de prioriteitenmatrix moeten ook eenduidig zijn. Wat voor de persoon die de richtlijnen opstelt duidelijk is, is misschien minder duidelijk voor de mensen die de prioriteitenmatrix gebruiken.

Het is een goed idee om de richtlijnen te testen in een vergadering. Hier worden verschillende scenario's gepresenteerd aan de medewerkers die de prioriteitenmatrix gaan gebruiken. Het personeel bepaalt de prioriteit van de taak aan de hand van het scenario, de richtlijnen en de prioriteitenmatrix zelf. De maker van de prioriteitenmatrix en het personeel beoordelen vervolgens de resultaten en verifiëren of een passende prioriteit uit de matrix is afgeleid. Als er problemen zijn, moeten de richtlijnen en de prioriteitenmatrix zelf worden herzien en zo nodig worden bijgewerkt. Alle scenario's moeten dan opnieuw worden uitgevoerd, omdat een wijziging om één probleem op te lossen onbedoeld nieuwe problemen kan veroorzaken met scenario's die voorheen wel een passende prioriteit uit de prioriteitenmatrix kregen.

Incident-escalaties en de prioriteitenmatrix

Incident-escalaties zijn mechanismen die helpen om incidenten op tijd op te lossen. Escalaties gebruiken de prioriteit van het incident die is bepaald met behulp van de prioriteitenmatrix. In ITSM zijn er twee soorten incident-escalaties:

Functionele escalatie

Bij een functionele escalatie wordt een incident opnieuw toegewezen aan een ander team, omdat het huidige team dat aan het incident werkt niet over de nodige vaardigheden beschikt om het op te lossen. Sommige organisaties kiezen ervoor om incidenten opnieuw toe te wijzen aan een meer ervaren team, nadat een vooraf gedefinieerd tijdsinterval is verstreken, in overeenstemming met het serviceniveau. Het tijdsinterval varieert doorgaans op basis van de prioriteit van het incident en is korter voor incidenten met een hogere prioriteit.

 

Hiërarchische escalatie

Een hiërarchische escalatie houdt in dat medewerkers iemand met meer bevoegdheden waarschuwen over een incident, meestal hun leidinggevende en de degene die verantwoordelijk is voor de getroffen service. De trigger voor wanneer hiërarchische escalatie moet worden gebruikt, is afhankelijk van de prioriteit uit de prioriteitenmatrix en het serviceniveau voor het incident. Als het serviceniveau dreigt te worden geschonden, moeten de manager en de verantwoordelijke voor de service worden geïnformeerd, zodat ze kunnen helpen het beoogde serviceniveau te behouden en proactieve stappen kunnen ondernemen om klanten tevreden te houden. Het bepalen van de prioriteit met de matrix is een belangrijke stap, omdat dit helpt om onnodige hiërarchische escalaties te voorkomen. Dit is met name het geval bij incidenten met een hoge prioriteit, omdat veel organisaties willen dat het management en de verantwoordelijken worden gewaarschuwd, kort nadat de incidenten zijn ingeschaald in de prioriteitenmatrix.

Een organisatie kan bijvoorbeeld een serviceniveau hebben om binnen 30 minuten op een P1-incident te reageren, maar het na 20 minuten te escaleren naar het management als het niet is opgelost. Dit zorgt ervoor dat het management op de hoogte is van het probleem met prioriteit 1, voordat het serviceniveau wordt overschreden. Voor een P2-incident met een oplossingstijd van 4 uur kan de escalatie echter pas na 3 uur plaatsvinden. Een P3-incident met een oplossingstijd van 1 dag wordt mogelijk niet geëscaleerd totdat het serviceniveau wordt overschreden, en een P4 en P5 krijgen mogelijk nooit een escalatie naar het management.

Waar hiërarchische escalaties aanwezig zijn, is het belangrijk om het testen van de escalaties op te nemen als onderdeel van de scenariotests voor de prioriteitenmatrix. Er moeten ook regelmatige evaluaties zijn van de escalaties die hebben plaatsgevonden, met inbegrip van ondersteunend personeel en management. Zo kan worden vastgesteld of er problemen zijn met de prioriteitenmatrix en of de bijbehorende richtlijnen moeten worden aangepast.

 

Een prioriteitenmatrix gebruiken voor incidenten

Incidenten management is het meest voorkomende proces waarbij gebruik wordt gemaakt van een prioriteitenmatrix. Vrijwel elke organisatie doet aan incidenten management. Zelfs organisaties die geen servicedesk hebben, moeten nog steeds incidenten beheren. Het ontwerpen en gebruiken van een prioriteitenmatrix om de prioriteit te bepalen van alle incidenten die door gebruikers worden gemeld, is essentieel voor het binnenhalen en tevreden houden van klanten. Meestal hebben uw support teams meer open incidenten dan dat ze kunnen afhandelen. Een prioriteitenmatrix helpt ze om hun activiteiten te ordenen, waarbij ze eerst aan de belangrijkste incidenten werken. De prioriteitenmatrix zal gebruik maken van een beoordeling van de gevolgen van het incident voor gebruikers, zowel qua impact als urgentie, om de prioriteit te bepalen. Door de prioriteitenmatrix op deze manier te gebruiken, zorgt u ervoor dat de incidenten die van invloed zijn op de bedrijfsvoering prioriteit krijgen, waardoor al het giswerk van het ondersteunend personeel wordt weggenomen en ook wordt voorkomen dat ze gaan kiezen welke taken ze het liefst als eerste doen.

De meeste tools ondersteunen de automatische toewijzing van prioriteit aan een incident door gebruik te maken van een ingebouwde prioritering. Dit kan helpen om het proces van incidenten management te versnellen, hoewel het ook een goed idee kan zijn voor de servicedeskmedewerkers om de prioriteit die automatisch is toegewezen met behulp van de matrix te controleren, omdat de impact en urgentie mogelijk verkeerd kunnen zijn ingevoerd.

Sommige tools maken het mogelijk om bepaalde gebruikers, zoals de directie en belangrijke gebruikers, te identificeren als 'very important persons' (VIP's). Wanneer er zich een incident voordoet waar deze gebruikers hinder van ondervinden, kan de tool automatisch de urgentie en/of impact verhogen in de prioriteitenmatrix, waardoor hogere prioriteiten dan gebruikelijk aan deze incidenten worden toegekend.

Tools hebben ook functies die de impact van incidenten kunnen beoordelen op basis van factoren zoals de mate van belangrijkheid van bepaalde systemen of services, op tijden van de dag en voor groepen gebruikers. Die worden vervolgens meegenomen in het hanteren van de prioriteitenmatrix om de juiste prioriteit te bepalen. De tool registreert deze factoren ten opzichte van het incident. In het geval van een geschil kan dit worden gebruikt om de prioriteit te verdedigen die uit de matrix is afgeleid.

Het is een goed idee om een procedure te ontwikkelen voor het betwisten van incidentprioriteiten. Hoewel een prioriteitenmatrix de toewijzing van prioriteiten zal vereenvoudigen, is de resulterende prioriteit nog steeds afhankelijk van informatie die is verzameld onder gebruikers en door monitoringsystemen, en de verwachtingen van gebruikers kunnen variëren. Het kan dus voorkomen dat de prioriteitenmatrix het incident een andere prioriteit geeft dan de gebruiker verwacht. Wanneer dit gebeurt, moet de gebruiker de prioriteit die is toegewezen door de matrix kunnen betwisten, met de mogelijkheid voor de servicedesk om de prioriteit te wijzigen als het geschil als gegrond wordt verklaard.

Ook moet het mogelijk zijn om de prioriteit van een incident tijdens de levenscyclus te wijzigen. Van veel incidenten is de volledige impact niet bekend bij de eerste melding door één gebruiker. Het incident krijgt een lage prioriteit, omdat bij het gebruik van de prioriteitenmatrix een lage impact wordt toegekend. Naarmate meer gebruikers dezelfde of vergelijkbare symptomen melden, neemt de impact toe en zal de prioriteitenmatrix een hogere prioriteit geven. Voor dit soort incidenten, waarbij de bekende impact in de loop van de tijd toeneemt, is het van belang om de prioriteitenmatrix te blijven gebruiken om de nieuwe prioriteit te bepalen. Anders kan het gebeuren dat servicedesks reageren op druk van gebruikers om prioriteiten te verhogen zonder de matrix te gebruiken. Dit kan leiden tot inconsistenties en contraproductief gebruikersgedrag aanmoedigen.

 

Een prioriteitenmatrix gebruiken voor grote incidenten

Een groot incident is een incident met een zeer negatieve impact op het bedrijf. Dit kan zijn door een buitensporige verstoring van de diensten of het risico van een daaropvolgende verstoring, zoals een virusaanval. Voor deze grote incidenten is het gebruikelijk om een aparte variant van het incidenten management proces te hebben, waarin de noodzakelijke urgentie om het incident op te lossen wordt erkend. Uw prioriteitenmatrix moet op basis van impact en urgentie duidelijk kunnen identificeren welke incidenten groot zijn. Grote incidenten hebben per definitie de hoogste prioriteit. Het is belangrijk om door middel van scenariotests te verifiëren of uw prioriteitenmatrix duidelijk kan identificeren welke incidenten groot zijn en welke incidenten slechts een hoge prioriteit hebben. 

Welke prioriteiten worden gedefinieerd als grote incidenten, hangt af van hoeveel verschillende prioriteiten er in uw prioriteitenmatrix zijn opgenomen. Als u maar drie prioriteiten hebt, zullen grote incidenten altijd P1 zijn. Met slechts drie prioriteitsniveaus loopt u het risico dat er regelmatig een beroep wordt gedaan op uw proces voor grote incidenten. Het is beter om een groter aantal prioriteiten in uw prioriteitenmatrix te hebben, waarbij u P1 reserveert voor echt grote incidenten die een extreem negatieve impact hebben op uw bedrijf. De verschillende niveaus van impact en urgentie in uw prioriteitenmatrix moeten zorgvuldig worden ontworpen, zodat een P1 alleen toegekend wordt voor echt grote incidenten. Dit vereist een zorgvuldige analyse van uw diensten, inclusief een beoordeling van hun werkelijke belang voor het bedrijf, en ook inzicht in hoe gebruikers die diensten gebruiken.