Wat is 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, wijzigingen en projecten. Door de meest geschikte prioriteit te bepalen met behulp van de matrix, kunnen uw medewerkers consistent zijn in hoe ze beslissen welke taak in welke volgorde moet 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 op hun beurt 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 relaties 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 werk beter kunnen begrijpen.

Door te articuleren en te documenteren hoe Impact en Urgentie worden gebruikt om prioriteiten te bepalen met behulp van de matrix, kan onzekerheid worden weggenomen over hoe IT beslist in welke volgorde aan taken moet worden gewerkt. Het gebruik van een prioriteitenmatrix kan ook helpen voorkomen dat 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 ondersteuningsteams overbelast raken, met meer taken die ze tegelijkertijd aankunnen. Tenzij een overeengekomen matrix wordt gebruikt om prioriteiten te bepalen, bestaat het risico dat medewerkers kunnen 'kiezen' waar ze aan willen werken, wat 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. Het domino-effect van het vertrouwen op druk vanuit gebruikers in plaats van een prioriteitenmatrix is dat incidenten worden uitgesteld terwijl ze prioriteit zouden moeten hebben.

Wanneer moet je een prioriteitenmatrix gebruiken?

Alle organisaties zouden een prioriteitenmatrix moeten gebruiken in elk ITSM-proces dat taakgericht is, waar beslissingen moeten worden genomen over wat de volgende taak is waaraan moet worden gewerkt. Dit omvat de volgende processen:

Incidentbeheer
Beheer van grote incidenten
Probleembeheer
Wijzigingsbeheer
Release management
Project management
Beheer van Servicecontinuïteit

Door voor al deze processen een prioriteitenmatrix te gebruiken om te bepalen waaraan moet worden gewerkt, wordt de situatie voorkomen waarin veel middelen worden toegewezen aan een taak die door druk of gebrek aan informatie prioriteit heeft gekregen.

Een prioriteitenmatrix moet worden opgenomen in de definitie van elke processtap waar een beslissing moet worden genomen over de volgende taak. De prioriteitenmatrix zal die beslissing op een consistente en transparante manier ondersteunen. Elk ITSM-proces moet worden onderzocht om deze beslissingspunten te vinden en er moet een geschikte prioriteitenmatrix worden ontworpen en geïmplementeerd. Het ontwerp moet alle betrokken partijen omvatten. Dit zijn waarschijnlijk IT, ITSM en het bedrijf. De impact op de dagelijkse bedrijfsvoering van de organisatie moet de drijfveer zijn voor het bepalen van de taken met de hoogste prioriteit uit de matrix.

Het meest voorkomende proces waarbij organisaties een prioriteitenmatrix gebruiken, is het proces voor incidentbeheer, waar het wordt gebruikt om de prioriteit van incidenten te bepalen. Dit is een ideaal proces om te leren hoe u een prioriteitenmatrix definieert en gebruikt, aangezien voor de meeste organisaties het proces voor incidentbeheer het grootste aantal taken afhandelt en de werkbelasting meestal de beschikbare capaciteit overschrijdt. Er kunnen echter voordelen worden behaald door het gebruik van een prioriteitenmatrix op te nemen in de andere hierboven genoemde processen. Idealiter zou de prioriteitenmatrix moeten worden opgenomen in het oorspronkelijke ontwerp van deze andere processen, om latere herbewerking en wijzigingen aan tools te voorkomen.

Impact versus urgentie in een prioriteitenmatrix

Idealiter moeten taken worden geprioriteerd met behulp van een combinatie van factoren, waaronder impact, urgentie, omvang, reikwijdte, complexiteit en middelen die nodig zijn voor de oplossing. Het opnemen van al deze factoren kan echter ingewikkeld zijn om te modelleren en moeilijk te begrijpen. Vandaar dat de meeste voorbeelden van een prioriteitenmatrix een vereenvoudigde versie zijn die alleen impact en urgentie beschouwt om de prioriteit te bepalen.

De precieze definities van Impact en Urgentie in een prioriteitenmatrix zijn afhankelijk van het proces waarin de matrix wordt gebruikt, de kenmerken en eisen van de organisatie, de bedrijfsprocessen die het proces ondersteunt en eventuele contractueel vastgelegde serviceniveaus waarvan verwacht wordt dat ze bereikt worden. Voor een beter begrip zijn de volgende definities bedoeld voor het gebruik van een prioriteitenmatrix om de prioriteit van een incident in een incidentbeheerproces te bepalen.

De Impact van het incident is de maatstaf voor de verstoring van de dagelijkse gang van zaken van de organisatie. Houd er rekening mee dat dit de impact op het bedrijf is, niet op een individuele gebruiker, en daarom weerspiegelt het hoe cruciaal het verlies van service voor het bedrijf is. Omdat dit een uitdaging kan zijn voor een servicedeskmedewerker of een programma om te evalueren met behulp van de prioriteitenmatrix, passen veel organisaties een eenvoudige maatstaf toe om de impact te bepalen: het aantal gebruikers dat door het incident wordt getroffen. De Impact wordt rechtstreeks bepaald door het aantal gebruikers dat door het incident wordt beïnvloed. Daarom is het incident met de hoogste impact in de prioriteitenmatrix een incident waarbij alle gebruikers worden getroffen door het incident, en het incident met de laagste prioriteit is een incident waarbij slechts één gebruiker wordt getroffen. Dit kan problemen opleveren voor kritieke diensten met een laag aantal gebruikers, dus een betere benadering voor het beoordelen van de Impact in een prioriteitenmatrix is om het percentage getroffen gebruikers te gebruiken voor de betreffende dienst of diensten. De Impact is dus het grootst als 100% van de gebruikers wordt getroffen, ongeacht het daadwerkelijke aantal gebruikers. Deze betere aanpak is vooral nuttig wanneer kritieke diensten 's avonds en in het weekend worden beïnvloed, waar het aantal gebruikers veel lager is dan tijdens normale werktijden op werkdagen.

Urgentie is de noodzakelijke snelheid om het incident op te lossen. Dit staat vaak in verband met serviceniveaudoelen voor de betrokken diensten, waarbij Urgentie in de prioriteitenmatrix toeneemt als de contracten korte oplossingstijden voor incidenten bevatten. De urgentie kan ook afhangen van het belang van de dienst waarop het incident betrekking heeft. Waar deze benadering wordt gebruikt, moet de prioriteitenmatrix de verschillende kritieke punten van de dienst bevatten en moet informatie over de kriticiteit van elke dienst beschikbaar zijn, zodat de juiste beoordeling van de urgentie kan worden gemaakt. Sommige tools kunnen automatische berekeningen uitvoeren om de Urgentie te bepalen op basis van deze factoren. De urgentie voor bepaalde diensten kan in de loop van de tijd variëren, bijvoorbeeld salarisadministratie aan het einde van de maand. Het kan een uitdaging zijn om dit in een prioriteitenmatrix op te nemen, tenzij automatische berekeningen beschikbaar zijn.

Voorbeeld prioriteitenmatrix

De opzet van de prioriteitenmatrix zal per organisatie en per proces verschillen. Een voorbeeld van een generieke prioriteitenmatrix voor het bepalen van de prioriteit op basis van Impact en Urgentie:

Deze eenvoudige prioriteitenmatrix bevat:

Drie niveaus van Urgentie (Hoog/Midden/Laag)
Drie niveaus van Impact (Hoog/Midden/Laag)
Vijf niveaus van Prioriteit (1 tot 5, waarbij 1 de hoogste prioriteit is)

Denk bijvoorbeeld aan een incident dat gevolgen heeft voor alle gebruikers van een dienst met een lage kriticiteit, zoals een service voor het reserveren van vergaderruimten. Het incident heeft een hoge impact omdat het alle gebruikers treft. De Urgentie is laag, omdat de kriticiteit van de dienst laag is. Door de prioriteitenmatrix te gebruiken om deze waarden op te zoeken, wordt de prioriteit van het incident bepaald op 3 - dit is de waarde waar de kolom Hoge Impact samenkomt met de rij met Lage Impact. Deze prioriteit, zoals bepaald met de prioriteitenmatrix, wordt dan toegewezen aan het incident, zodat het ondersteunend personeel kan zien wat de prioriteit is.

Prioriteiten begrijpen

Wanneer een prioriteitenmatrix wordt gebruikt, is het nog steeds belangrijk dat alle betrokken medewerkers begrijpen wat de prioriteit bepaalt. Zo gebruikt de prioriteitenmatrix in het incidentbeheerproces vaak alleen Impact en Urgentie om de prioriteit van een incident te bepalen. Bij het ontwerpen van de prioriteitenmatrix hebben de meeste organisaties geen moeite om de verschillende niveaus van Impact te definiëren en te beoordelen, maar het definiëren van Urgentie kan een grotere uitdaging zijn. U moet in de echte wereld beslissen wat telt voor deze factoren. In plaats van alleen waarden voor urgentie te definiëren, is het een beter idee om afstand te nemen van de prioriteitenmatrix zelf en voor uw organisatie te bespreken hoe prioriteiten bepaald worden. Er zijn meestal vijf verschillende aspecten die moeten worden overwogen en begrepen bij het ontwerpen van een prioriteitenmatrix:

Hoe de productiviteit wordt beïnvloed, zowel de productiviteit van de organisatie als geheel als die van individuele gebruikers
Om hoeveel gebruikers en welk type gebruiker het gaat. Sommige gebruikers, zoals VIP's, stellen mogelijk hogere eisen of zijn belangrijker voor de bedrijfsvoering van de organisatie, bijvoorbeeld personeel dat contact heeft met klanten
Om hoeveel systemen of services het gaat
Hoe belangrijk deze systemen/services zijn voor de organisatie. Dit kan variëren afhankelijk van het tijdstip van de dag en eventuele cyclische bedrijfspatronen
Het risiconiveau voor de organisatie en individuen. Dit kunnen risico's zijn voor IT-beveiliging en veiligheidsrisico's voor gebruikers of klanten

Het is belangrijk om deze factoren te gebruiken om verschillende scenario's te modelleren met behulp van de prioriteitenmatrix om te controleren dat de matrix u een geschikte prioriteit zal geven. Als dit niet het geval is, moet u de waarden in uw prioriteitenmatrix controleren, evenals de waarden voor de voorwaarden waarmee ze bepaald worden. Het kan zijn dat u meer dan één matrix nodig heeft, bijvoorbeeld één prioriteitenmatrix die wordt gebruikt in kritieke bedrijfsperioden en een andere die de rest van de tijd wordt gebruikt.

Om dit te illustreren, bepalen sommige organisaties de impact in de prioriteitenmatrix op basis van welke niveaus van de organisatie worden beïnvloed. Denk bijvoorbeeld aan de organisatie, een locatie, een afdeling, een team en een individu. Dit ondersteunt het maken van een inschatting van de schaal van het risico met behulp van de prioriteitenmatrix als de taak niet wordt aangepakt.

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, en veel organisaties hebben er maar drie. Dit komt doordat complexiteit en verwarring toenemen naarmate het aantal prioriteiten in de matrix toeneemt. De meeste mensen accepteren het concept van een hoge prioriteit, een lage prioriteit en een gemiddelde prioriteit, elk met een bijbehorende numerieke waarde. Als uw prioriteitenmatrix meer dan drie waarden bevat, kan het moeilijk zijn om de juiste woorden te gebruiken voor elke prioriteit.

Gewoonlijk is de waarde voor een prioriteit hoger wanneer de prioriteit lager is, 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

In uw eigen organisatie is het een goed idee om medewerkers voorbeelden te geven van de verschillende prioriteiten die uit een prioriteitenmatrix kunnen worden afgeleid. Dit zal helpen om het 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 kritieke 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 service is niet beschikbaar
Een grote hoeveelheid gegevens is beschadigd
Alle gebruikers zijn getroffen en kunnen hun werk niet uitvoeren
Kritieke 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 een P1-taak. P2-taken uit de prioriteitenmatrix kunnen het volgende omvatten:

Een volledig systeem of service is niet beschikbaar
Gegevens zijn beschadigd en hebben gevolgen voor verschillende gebruikers
Een groot deel van de gebruikers is getroffen 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, gelokaliseerde virusinfecties, verlies van bepaalde e-mailfunctionaliteit en uitval van niet-kritieke 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 nog 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 bepaald 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 de specifieke organisatie voor taken met elke prioriteit uit de matrix. De richtlijnen voor het gebruik van de prioriteitenmatrix moeten in de loop van de tijd worden bijgewerkt als er nieuwe voorbeelden worden gevonden en problemen met onjuiste prioriteiten worden ervaren.

De richtlijnen moeten specifieke bereiken bevatten als het om aantallen gaat. Zo is ‘waar meerdere gebruikers worden geraakt’ voor interpretatie vatbaar. Precieze aantallen die relevant zijn voor de organisatie in kwestie dienen 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 begeleiding 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 dat 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.

Prioriteitenmatrix en serviceniveaus

Veel organisaties hebben serviceniveaus die de tijd specificeren die is toegestaan om problemen, verzoeken en incidenten op te lossen. Als er serviceniveaus zijn, moet het ontwerp van de prioriteitenmatrix hiermee rekening houden, met name wanneer het serviceniveau voor probleemoplossing varieert op basis van de prioriteit. Als in een contract serviceniveaus zijn vastgelegd die afhankelijk zijn van prioriteiten, dan moet de prioriteitenmatrix precies dezelfde prioriteiten bevatten, anders ontstaat er verwarring. Als een contract bijvoorbeeld serviceniveaus heeft met verschillende doelen voor taken met prioriteit 1, prioriteit 2 en prioriteit 3, dan moet de prioriteitenmatrix alleen een uitkomst van P1, P2 of P3 kunnen geven. Het contract moet in woorden omschrijven wat deze verschillende prioriteiten zijn en wat moet worden gebruikt om ze te bepalen. Idealiter moet dit in een prioriteitenmatrix staan, als onderdeel van het contract.

De gespecificeerde tijden om taken op te lossen, afhankelijk van de prioriteit uit de prioriteitenmatrix, variëren van organisatie tot organisatie, maar hier is een voorbeeld:

Prioriteit 1 – Binnen 15 minuten een reactie geven, binnen 2 uur oplossen
Prioriteit 2 – Binnen 15 minuten een reactie geven, binnen 4 uur oplossen
Prioriteit 3 – Binnen 1 uur een reactie geven, binnen 2 dagen oplossen
Prioriteit 4 – Binnen 4 uur een reactie geven, binnen 5 dagen oplossen
Prioriteit 5 – Binnen 1 dag een reactie geven, binnen 2 uur oplossen

Deze tijden zullen worden gedefinieerd in de gedocumenteerde serviceniveaus en worden niet opgenomen in de prioriteitenmatrix. Het is een goed idee om in de serviceniveaus een link toe te voegen naar de prioriteitenmatrix. Het kopiëren van de prioriteitenmatrix naar de gedocumenteerde serviceniveaus kan problemen met de consistentie veroorzaken als er latere wijzigingen in de prioriteitenmatrix zijn.

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 functionele escalatie wordt een incident opnieuw toegewezen aan een andere ondersteuningsgroep, omdat de huidige groep die aan het incident werkt niet over de nodige vaardigheden beschikt om het incident op te lossen. Sommige organisaties kiezen ervoor om incidenten opnieuw toe te wijzen aan een meer ervaren ondersteuningsgroep nadat een vooraf gedefinieerd tijdsinterval is verstreken, in overeenstemming met het serviceniveau. Het tijdsinterval varieert doorgaans volgens de incidentprioriteit uit de prioriteitenmatrix en is korter voor incidenten met een hogere prioriteit.

Hiërarchische Escalatie

Hiërarchische escalatie is wanneer medewerkers iemand met meer autoriteit waarschuwen over een incident, meestal hun leidinggevende en de service-eigenaar voor de service die door het incident is getroffen. 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 service-eigenaar worden geïnformeerd, zodat ze kunnen helpen het serviceniveaudoel voor deze prioriteit van het incident te behouden en proactieve stappen te ondernemen om de klant 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 het management en de service-eigenaren willen waarschuwen kort nadat de incidenten zijn geïdentificeerd met behulp van 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 regelmatig evaluaties plaatsvinden van de escalaties die hebben plaatsgevonden, met inbegrip van ondersteunend personeel en management, om vast te stellen of er problemen zijn met de prioriteitenmatrix of de bijbehorende richtlijnen die moeten worden aangepakt.

Een prioriteitenmatrix gebruiken voor incidenten

Incidentbeheer is het meest voorkomende proces waarbij gebruik wordt gemaakt van een prioriteitenmatrix. Vrijwel elke organisatie doet aan incidentbeheer. 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 behouden van tevreden klanten. Meestal hebben uw ondersteuningsteams 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. Voor het beheren van incidenten zal de prioriteitenmatrix 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 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 prioriteit. Dit kan helpen om het incidentbeheerproces te versnellen, hoewel het toch een goed idee kan zijn voor de servicedeskmedewerkers om de prioriteit die automatisch is toegewezen met behulp van de matrix te bekijken, omdat ze de impact en urgentie mogelijk verkeerd hebben ingevoerd.

Sommige tools maken het mogelijk om bepaalde gebruikers, zoals directeuren van het bedrijf en kritische gebruikers, te identificeren als Very Important Persons (VIP). Wanneer een incident voor deze gebruikers wordt ontvangen, kan de tool automatisch de urgentie en/of impact verhogen voor gebruik in de prioriteitenmatrix, waardoor hogere dan gebruikelijke prioriteiten voor deze incidenten kunnen worden toegekend.

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

Het is een goed idee om een procedure te ontwikkelen voor het betwisten van incidentprioriteiten. Hoewel een prioriteitenmatrix de toewijzing van incidentprioriteiten zal vereenvoudigen, is de resulterende prioriteit nog steeds afhankelijk van informatie die is verzameld van gebruikers en 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 zou 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. Servicedesks kunnen reageren op druk van gebruikers om prioriteiten te verhogen zonder de matrix te gebruiken. Dit kan leiden tot inconsistenties en onbehulpzaam 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 buitensporige verstoring van de diensten of het risico van daaropvolgende verstoring door gebeurtenissen zoals een virusaanval. Voor deze grote incidenten is het gebruikelijk om een aparte variant van het incidentbeheerproces 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 grote incidenten zijn. Grote incidenten hebben per definitie de hoogste prioriteit. Het is belangrijk om door middel van scenariotests te verifiëren dat 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 riskeert u echter regelmatig een beroep te doen op uw proces voor grote incidenten. Het is veel beter om een groter aantal prioriteiten in uw prioriteitenmatrix te hebben, waarbij u P1 reserveert voor echte grote incidenten die een extreem negatieve impact hebben op het 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.

Een prioriteitenmatrix gebruiken voor problemen

Een prioriteitenmatrix kan nuttig zijn om de prioriteit van zowel problemen als incidenten te beoordelen. De afwegingen voor problemen zijn dezelfde als voor incidenten, de hoofdassen voor de prioriteitenmatrix kunnen nog steeds Impact en Urgentie zijn. De beoordelingen voor elk van deze dimensies in een prioriteitenmatrix voor problemen zullen vergelijkbaar zijn, maar de richtlijnen en de resulterende prioriteit zullen anders zijn. De impact in de prioriteitenmatrix kan nog steeds worden gebaseerd op het percentage gebruikers dat wordt getroffen door het specifieke probleem, zodat de prioriteit toeneemt naarmate er meer gebruikers worden getroffen. De urgentie in de prioriteitenmatrix moet echter meer in aanmerking nemen dan alleen de kriticiteit van de betrokken service voor de organisatie. Andere factoren waarmee rekening moet worden gehouden bij het gebruik van de prioriteitenmatrix zijn de haalbaarheid van het oplossen van het probleem, de kosten van de oplossing afgewogen tegen de voordelen van de oplossing, en vooral het bestaan van acceptabele tijdelijke oplossingen. Een prioriteitenmatrix kan bijvoorbeeld een lage prioriteit bepalen voor een probleem dat alle gebruikers treft, maar dat een acceptabele oplossing biedt, zelfs als de service een kritieke service is. Op dezelfde manier kan de prioriteitenmatrix een lage prioriteit bepalen voor een probleem dat meerdere gebruikers treft, maar waarvan de oplossingskosten aanzienlijk hoger zijn dan het voordeel dat wordt behaald met het oplossen.

Dit kan een ingewikkeld onderdeel zijn om te modelleren. Daarom gebruiken de meeste organisaties die een prioriteitenmatrix voor problemen gebruiken de matrix om een eerste indicatie te geven van de prioriteit. Ontwikkelingsteams hebben een eindige capaciteit en zullen daarom waarschijnlijk meer problemen van dezelfde prioriteit hebben dan ze tegelijkertijd aankunnen. De initiële prioriteit die is afgeleid van de prioriteitenmatrix wordt gezamenlijk beoordeeld door gebruikersvertegenwoordigers en IT-personeel, waarbij rekening wordt gehouden met de andere factoren en de andere problemen, inclusief de geschatte tijd om elk probleem op te lossen.

Prioriteitenmatrix