Frustraties wegnemen uit het werkende leven van mensen. Dat is ons doel. Dit is ook de intentie van het platform dat we gebruiken. Maar helaas zien we een trend rondom het gebruik van de Incident Tasks-functie die precies het tegenovergestelde effect heeft. Het gebruik van deze functie om taken te routeren is duur, inefficiënt en levert een enorme berg aan administratie op. Bovendien bezorgt het eindgebruikers hoofdpijn, omdat het oplossen van incidenten langer duurt. De functie is ook helemaal niet bedoeld om op deze manier te gebruiken.
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:
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:
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.
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.
