De (on)zin over de Incident Tasks-functie

Vanuit onze succesvolle Vanilla-aanpak helpen we organisaties over te stappen van een (bijna) custom-build versie van ServiceNow naar een out-of-the-box-versie. Tijdens deze conversie stuiten we vaak op een probleem: het gebruik van de Incident Tasks-functie. In de custom-build versies worden incidenttaken doorgaans door eerstelijns servicedesks gebruikt om werk naar andere afdelingen te routeren. Dit wordt vaak gedaan in organisaties waar de IT-werkzaamheden zijn uitbesteed. Hoewel je op deze manier kunt werken, raden wij dit sterk af. En wel vanwege het volgende.

Werk vs. verantwoordelijkheid toewijzen
Volgens ITIL is het doel van incidentmanagement ervoor te zorgen dat een service zo snel mogelijk weer wordt hersteld. Omdat de meeste incidenten één oorzaak hebben en door één groep worden opgelost, is het heel belangrijk dat het incident aan de juiste afdeling of groep wordt toegewezen. Zo kan het incident snel worden opgelost. Servicedesks zijn meestal belast met deze taak. Voor het toewijzen dienen zij gebruik te maken van de velden Assignment Group en Assigned To in ServiceNow, in plaats van de Incident Tasks-functie te gebruiken. Als ze deze functie daar wél voor gebruiken, is het niet duidelijk wie er verantwoordelijkheid is. En het bevat simpelweg niet dezelfde mate van urgentie. We weten allemaal heel goed dat als je een lange lijst met taken op jouw naam hebt staan, een nieuwe taak onderaan het lijstje komt. En jij voelt je hier niet verantwoordelijk voor. Dit is anders als je een urgent incident hebt toegewezen gekregen, waarbij jouw groep als enige verantwoordelijk is voor het oplossen van het probleem.

Werk vs. Service Level Agreements traceren
Sommigen zeggen dat het belangrijk is voor servicedesks om het incident aan hun eigen groep toe te wijzen, zodat zij het oplosproces van incidenten kunnen monitoren. Maar wij zijn van mening dat servicedesks dan de verkeerde data of tabel gebruiken. Je wilt namelijk geen werk traceren, maar iets veel belangrijkers: Service Level Agreements (SLA’s). Gebaseerd op de tijd die nodig is om een incident op te lossen, bepalen servicedesks of dat zij een groep achterna moeten zitten om de oplossing te versnellen. Wat servicedesks nodig hebben is een overzicht van alle incidenten die zich in de gevarenzone bevinden, omdat ze mogelijk niet aan de SLA voldoen, en ze moeten weten wie ze achterna moeten zitten. Als je de taak en SLA in één overzicht hebt, kan de servicedesk veel efficiënter en effectiever zijn werk doen. Bovendien hoeven zij geen complexe rapportages van meerdere incidenten en incidenttaken meer aan te leveren.

Meer vs. minder werk
Anderen beargumenteren dat het gebruik van de Incident Tasks-functie nodig is om meerdere groepen te betrekken. Maar als de meeste incidenten slechts één oorzaak hebben, zorgt het aanmaken van meerdere incidenttaken alleen maar voor meer werk. Ook de kans dat er meer dan een groep hetzelfde incident onderzoekt, neemt toe. Plus, informatie over de oplossing wordt in verschillende taken opgeslagen in plaats van de enige bron van waarheid: het incident. Het maakt communicatie met de eindgebruiker omslachtig, waardoor je vergeet te communiceren. Een hele menselijke reactie is tevens dat je wacht totdat anderen de oorzaak van het incident hebben achterhaald. Dit leidt tot:

• Meer administratie voor de servicedesk
• Oplossen kost meer tijd
• Tickets coördineren kost meer tijd
• Groepen spenderen meer tijd aan het onderzoeken van incidenten waarbij de oplossing buiten hun macht ligt

En om er nog een schepje bovenop te doen: het opdelen van een incident in verschillende taken compliceert de communicatie tussen de verschillende oplosgroepen. Als je met één incidentrecord werkt, kan iedereen alle relevante informatie en geschiedenis direct terugvinden.

Status quo vs. continue verbetering
De meest gebruikte KPI voor incidentmanagement is het verkorten van de oplostijd, omdat dit de tevredenheid van eindgebruikers verhoogt. Dit wordt bereikt door:

• Het aantal hertoewijzingen te beperken (ticketpingpong)
• De gemiddelde afhandelingstijd van een groep te reduceren *
• Tickets automatisch aan de juiste groep toe te wijzen

ServiceNow heeft al jaren een zeer uitgebreide, krachtige rapportagefunctie die de factoren die bijdragen aan kortere oplostijden meet, rapporteert en beïnvloedt. In een eerdere release heeft ServiceNow machine learning toegevoegd, die incidentbeschrijvingen aan de meest waarschijnlijke Assignment Group koppelt om tickets automatisch toe te wijzen. En hier zit nou juist de crux: dit wordt gedaan op basis van het veld Assignment Group. Als je dus de Incident Tasks-functie gebruikt om taken onder te verdelen, mis je al deze voordelen. Dat betekent dat je blijft hangen in een status quo in plaats van dat je continu verbeteringen doorvoert.

Ware intentie: Major Incident Management
Het echte doel van de Incident Tasks-functie is om grote incidenten op te lossen. De Major Incident Manager kan met deze functie individuele taken aanmaken en deze aan groepen en individuen toewijzen als onderdeel van het onderzoeken en oplossen van het incident.

Het moraal van dit verhaal
Als het bovenstaande waar is, hoe kan je dan voorstander zijn van een manier van werken die tot méér werk leidt en je in een status quo gevangenhoudt? Als je wordt geadviseerd de Incident Tasks-functie te gebruiken om taken te routeren, denk dan nog eens goed na. Er is namelijk maar één geval waarin je het onjuiste gebruik van de Incident Tasks-functie zou kunnen goedpraten: als er een winstmodel op basis van hoeveelheid werk (tickets, taken of uren) van toepassing is.

* ServiceNow heeft een geweldige functie hiervoor: Metric Timeline.

---

Blijf op de hoogte, net als 1400 andere ServiceNow-professionals

Schrijf je in voor onze maandelijkse Flow@Work Exclusive nieuwsbrief bomvol inzichten, best practices en tips over hoe je werk laat flowen op het Now®-platform.