In zijn vorige blog deelde branche-expert Stephen Mann tien praktische tips voor problem management. Deze keer gaat hij dieper in op ITIL incident management: een belangrijk fundament van elke IT-organisatie.
In dit blog bespreekt Stephen vijf best practices voor ITIL incident management die je kunt gebruiken om je IT-servicedesk te verbeteren. Hoe zou jouw IT-organisatie haar proces voor ITIL incident management kunnen verbeteren?
Incident management
Tegenwoordig kun je genoeg ITSM-blogs lezen over populaire onderwerpen zoals Artificial Intelligence, digitale transformatie en Enterprise Service Management. Soms lijken basiselementen van ITSM zoals ITIL incident management daardoor een beetje het ondergeschoven kindje te zijn. Maar incident management verdient juist alle aandacht: je employee experience valt of staat namelijk met de kwaliteit van jouw IT-servicedesk en of ze in staat zijn je medewerkers snel weer productief te maken.
1. Begrijp hoe jouw IT-servicedesk waarde oplevert voor je organisatie
Als het antwoord op de vraag ‘Hoe helpt jouw IT-servicedesk de organisatie?’ is dat ze slechts IT-problemen oplossen, dan is er nog heel wat werk aan de winkel. De tijd dat de IT-servicedesk gelijkstond aan ‘IT-support’ is allang voorbij. ‘People support’ komt tegenwoordig meer in de buurt, omdat je IT-servicedesk zowel je klanten als je medewerkers helpt te doen wat ze moeten doen.
Business stakeholders kijken steeds vaker naar de waarde die je IT-organisatie creëert, en niet alleen maar naar de kosten die ze maken. Jouw IT-servicedesk is daarop geen uitzondering. Dus hoe creëert je IT-servicedesk waarde voor je organisatie? Of hoe voorkomt je IT-servicedesk in ieder geval dat je organisatie waarde verliest?
Er bestaat jammer genoeg geen kant-en-klaar antwoord op die vragen. De waarde van je IT-servicedesk ontdek je door proactieve gesprekken te voeren met de belangrijkste stakeholders binnen je bedrijf. De IT-servicedesk van een fabrikant zou bijvoorbeeld waarde kunnen toevoegen door IT-problemen op te lossen om zo productieverliezen te minimaliseren, of door preventief onderhoud uit te voeren.
De kans is groot dat verschillende stakeholders elk hun eigen kijk hebben op de manier waarop je IT-servicedesk waarde creëert voor hun werkzaamheden, teams en klanten. Commerciële directeuren zullen bijvoorbeeld vooral waarde hechten aan zo min mogelijk productiviteitsverlies bij medewerkers. In dat geval is het belangrijk om IT-problemen die tot omzetverlies leiden snel op te lossen.
Je kunt de verschillende definities van waarde alleen bepalen door intensieve gesprekken met je stakeholders te voeren. Zo leer je wat je IT-servicedesk goed doet, wat de pijnpunten zijn en wat je kunt verbeteren. Het is belangrijk om alle aspecten te onderzoeken zodat je een beeld krijgt van de volledige impact van jouw IT-organisatie. Wees je ook bewust van het feit dat de waardeperceptie van je stakeholders met de tijd kan veranderen.
Zodra je de waarde van je IT-servicedesk hebt vastgesteld, kun je dit vertalen naar je strategieën, doelen, beleid, processen, servicelevels en metrics of KPI’s van je servicedesk.
2. Beoordeel de serviceleveldoelen van je IT-servicedesk opnieuw
Ik heb het niet zozeer over metrics, maar eerder over de meest belangrijke serviceleveldoelen waar je IT-servicedesk op dit moment naar toewerkt.
Vraag je het volgende af:
- Wanneer heb je de doelen gesteld? (Misschien was dat wel lang geleden, toen je IT-servicedesk voor het eerst werd opgezet.)
- Waren je belangrijkste stakeholders het eens met de doelen en hebben ze er invloed op gehad?
- Wanneer heb je de doelen voor het laatst aangepast aan de hand van veranderde bedrijfsbehoeften, technologie en verwachtingen van medewerkers?
Je moet precies weten hoe goed je doelen aansluiten bij de behoeften van jouw bedrijf. Wat heeft je organisatie er bijvoorbeeld aan dat je servicedesk incidenten die via de e-mail binnenkomen binnen 24 uur afhandelt? En, als je de waarde van je servicedesk in het achterhoofd houdt, kost meer tijd spenderen aan een incident je organisatie meer dan het inzetten van extra IT-middelen om voor een snellere oplossing te zorgen?
Daar kom je alleen achter als je het aan de mensen vraagt aan wie je je diensten levert: je medewerkers en mogelijk ook je externe klanten. Uiteraard kun je wijzigingen in je gestelde doelen alleen doorvoeren binnen de grenzen van de middelen die je IT-servicedesk heeft.
3. Kijk kritisch naar de waarde van je huidige metrics voor ITIL incident management
Logisch gezien zou dit voor de tweede best practice moeten komen. Maar als je je IT-prestaties wilt afstemmen op de bedrijfsverwachtingen, is het vaak gemakkelijker om gesprekken met stakeholders te beginnen door gewoon te vragen hoe het gaat. Openingen als ‘Dit is wat we meten. Wat denk jij?’ of ‘Wat moeten we meten om ervoor te zorgen dat we aan jouw behoeften voldoen?’ zijn vaak minder geschikt.
Wat zou er mis kunnen zijn met je huidige KPI’s en metrics voor ITIL incident management? IT-servicedesks maken veelvoorkomende fouten, zoals:
- te veel metrics gebruiken;
- de relaties tussen metrics niet begrijpen;
- de gedragsaspecten van metrics negeren;
- metrics alleen gebruiken als doelen, niet als een opstap naar verbetering.
Bovendien ligt de focus vaak op wat IT-support doet, in plaats van op wat IT-support bereikt met wat ze doen. Het draait vaak meer om de werkzaamheden die IT uitvoert, en niet om de uiteindelijke resultaten. De snelheid, aantallen en kosten van de werkzaamheden zijn uiteraard belangrijk, maar kun je met die informatie 100% zeker weten dat je IT-servicedesk optimaal functioneert en waarde toevoegt? Nogmaals, praat met je belangrijkste stakeholders over wat echt belangrijk is voor de organisatie en of jouw IT-servicedesk aan de verwachtingen voldoet.
In dit blog wordt uitgelegd hoe je je KPI’s voor incident management verbetert >>
4. Ga er niet van uit dat een positief ogende verandering automatisch goed is
Dit is een variant op een fout waarover ik het bij de derde best practice had – dat de relatie tussen metrics niet altijd wordt begrepen. Neem bijvoorbeeld het aantal incidenten. Niemand verheugt zich op incidenten, maar ze zijn er toch altijd. En als het aantal incidenten toeneemt of afneemt, dan is het belangrijk om goed te begrijpen wat die verandering betekent.
Neem bijvoorbeeld een IT-servicedesk die trots is op het grote aantal incidenten dat ze maandelijks afhandelen. Maar vanuit het oogpunt van de hele IT-organisatie is een groot aantal incidenten niet per se een goed teken (of iets om van de daken te schreeuwen).
En wat als het aantal incidenten langzaam maar zeker afneemt? Dat hoeft ook niet altijd te betekenen dat een IT-servicedesk het goed doet. Misschien zijn er eigenlijk zelfs meer IT-incidenten maar heeft de servicedesk zo’n beroerde reputatie dat ze niet altijd meer worden gemeld. Het omgekeerde kan natuurlijk ook: dat medewerkers juist wel met problemen bij IT aankloppen en zo voor een toename van het aantal incidenten zorgen omdat de IT-servicedesk zo goed functioneert.
Dus als je kijkt naar veranderingen in het aantal incidenten, moet je ook weten wat er nog meer is veranderd. Is de klanttevredenheid gedaald? Of is het aantal ‘eenvoudige’ of minder belangrijke incidenten gedaald?
Zorg dat je precies weet waardoor de cijfers zijn veranderd voordat je je hard op de borst klopt. Neem bijvoorbeeld je kosten per ticket of je gemiddelde afhandelingsduur. Misschien heeft je IT-servicedesk gewoon te maken met eenvoudigere incidenten, zoals het resetten van wachtwoorden. Als je dit soort eenvoudigere incidenten niet in de statistieken meeneemt, kan je gemiddelde afhandelingsduur zelfs zijn toegenomen. Vraag jezelf ook af waarom er überhaupt zoveel nieuwe wachtwoorden nodig zijn– en waarom dat niet allang is geautomatiseerd.
Waar het uiteindelijk om gaat is dat je er als IT-servicedesk niet automatisch van uit mag gaan dat iets wat op een positieve verandering lijkt ook daadwerkelijk goed is. Kijk altijd naar de relatie tussen verschillende metrics en wat dat betekent voor jouw organisatie.
5. Gebruik problem management om het aantal incidenten te verminderen
Over deze best practice voor ITIL incident management kan ik kort zijn. Ik heb al eerder een blog geschreven over waarom ITIL problem management zo weinig wordt toegepast – en nog een blog met tien praktische tips voor ITIL problem management.
Het spreekt voor zich dat IT-servicedesks het verschil moeten kennen tussen incidenten en problemen. Maar je IT-support moet zich ook proactief inzetten om tools en technieken voor problem management te gebruiken. Dan kun je voor eens en voor altijd afscheid nemen van die tijdrovende, terugkerende incidenten. Hierdoor kunnen de analisten van je IT-servicedesk zich bezighouden met de IT-problemen die echt om aandacht vragen.
Dit waren mijn vijf best practices waarmee je jouw ITIL incident managementproces naar een hoger plan kunt tillen. Natuurlijk had ik ook andere zaken kunnen toevoegen – bijvoorbeeld met betrekking tot mensen of het gebruik van automatisering. Zijn er best practices die ik volgens jou zeker aan dit lijstje moet toevoegen? Laat het me weten in de reacties.
In zijn volgende blog zal Stephen ingaan op de ITIL Service Lifecycle en wat er in ITIL 4 met dit essentiële onderdeel van ITIL v3 is gebeurd. Meld je aan voor ons blog om niets te missen.
