SERVICE MANAGEMENT, SIAM, SMAAS
29 April

Meer dan 50 tinten grijs

Een zombie idee is een idee dat na grondige analyse en lange ervaring als onzin kan beschouwd worden en dus dood zou moeten zijn – maar toch steeds opnieuw opduikt. Ook in service management zal je af en toe op dergelijke lelijkerds stuiten. In deze blog leg ik uit hoe je ze herkent en vakkundig kunt vernietigen.

Onlangs kreeg ik de opdracht van mijn eega om de radiator in onze keuken in een nieuwe kleur te zetten, namelijk grijs. In de verfwinkel overhandigde de verkoper me, op mijn vraag naar grijze radiator verf, een klein boekje met 5 pagina’s van telkens 5 kolommen en 6 rijen minuscule rechthoekjes in een andere tint grijs, 150 in totaal dus, met de dwingende vraag “Kies hier maar uit !”.

Een onmogelijke keuze. “Wat zou jij me aanraden?” vroeg ik. Die vraag kreeg de verkoper wel meer, hij opende het boekje op de derde pagina en wees naar de eerste rechthoek : “Deze wordt veel gevraagd, zeker voor radiatoren. Nog nooit iemand teruggezien die er niet tevreden over was.” Die tint grijs is het dus geworden. Ook al was ik heel zeker dat deze tint zijn populariteit niet had te danken aan zijn bijzondere uitstraling, maar alles aan de dankbare plaats midden in het boekje en aan de geruststellende gedachte dat al die anderen er ook voor gekozen hadden. Dit fenomeen is welgekend in de consumentenpsychologie en heeft een mooie naam gekregen: “keuzestress ”. De consument met keuzestress en in tijdsnood zal gewoon het eerste veilige alternatief kiezen dat voorbij komt.

Een service desk agent werkt voortdurend tegen de tijd: nieuwe oproepen aannemen, tickets correct registeren, trachten onmiddellijk een oplossing te vinden en indien dat niet lukt het ticket aan het geschikte team toewijzen …. Een service desk agent wil je dus geen keuzestress bezorgen.

About the author:

Wouter Wijns is a senior Service Management consultant at InfraVision with strong project management and business consultancy skills. His purpose is to help customers achieve their targets through creativity, quality and enthousiasm.



En toch gebeurt dit frequent. Een prioritizering gebaseerd op het algoritme ‘priority = impact x urgency’ is er een pijnlijk voorbeeld van. Dit algoritme staat nog altijd prominent in het ITIL 2011 service operations handboek en spijtig genoeg niet als een ‘in-memoriam’. Daarbij worden volgende richtlijnen gegeven: bij het bepalen van de prioriteit moet men rekening houden met hoe snel de business de oplossing nodig heeft, met de mogelijke financiële impact van het incident, met de mogelijke impact op de reputatie van de business, en met de mogelijke impact van de inbreuk op wetgeving, … Euh ? Hoe snel heeft de business een oplossing nodig ? Vraag het aan de gebruiker en hij/zij zal je antwoorden: nu! Wat is de mogelijke financiële impact van een incident ? Vraag dit aan 5 personen en je krijgt 6 verschillende antwoorden. Arme service desk agent die dan ook nog even moet nadenken over de juridische impact van het incident en de impact op het imago van het bedrijf.

Die prioriteitsbepaling gebaseerd op ‘impact x urgency’ is een verschrikking voor onze service desk agent in tijdsnood en hij zal onder deze keuzestress doen wat een consument doet: het eerste veilige alternatief kiezen dat voorbij komt. Zoals ik en vele anderen kiezen voor het grijze rechthoekje linksboven op de derde pagina, zal de service desk agent steevast kiezen voor dezelfde impact en urgency codes. De prioriteitsbepaling in dergelijke systemen wordt na verloop van tijd even vlak als een Hollands Polderlandschap.

De zilveren kogel om dit hardnekkige monstertje te doden is het algoritme ‘impact’ x ‘service criticality’. Niet elke service is even belangrijk of kritisch: de schade bij onbeschikbaarheid van de service SAP of de service SharePoint zal niet dezelfde zijn, laat ons stellen dat in de meeste gevallen SAP een hogere ‘service criticality’ heeft dan SharePoint. Die ‘service criticality’ bepalen we vooraf en is gedefinieerd in de ITSM tool configuratie. Elk incident wordt aan een service gekoppeld, dus over het bepalen van de service criticality hoeft de service desk agent zich alvast geen zorgen meer te maken. Hij bepaalt enkel de impact en dat kan je in eerste lijn heel eenvoudig houden: impact op 1 of meerdere gebruikers, service onbeschikbaar of enkel gedegradeerd, in combinatie maximaal 4 eenvoudige keuzemogelijkheden.
Het converteren van de prioriteit in een ‘exacte’ tijdsbepaling is de voorhamer waarmee je deze zombie volledig neutraliseert. ‘Exact’ betekent dat de ITSM tool in staat is om de oplostijd te berekenen, rekening houdend met supporturen en vakantiedagen. Weg de vlakke queues, je tweede en derde lijn kunnen nu op basis een objectieve queue aan de meest dringende incidenten werken.

En wat dan met ‘urgency’, is dat begrip dood en begraven ? Niet als je dit begrip op de juiste wijze toepast. Het bovenstaande algoritme implementeert uw SLA’s, uw afspraken met de business. Het zegt bv. dat als een individueel persoon geen access heeft tot SAP (impact = medium), we dit binnen de 8u zullen oplossen. In de meeste gevallen is dit heel aanvaardbaar voor de gebruikers. Maar voor de financial controller die op het einde van de maand zijn financiële rapportering moet afronden, kan die 8u een eeuwigheid te laat zijn. Dan komt de urgency flag in het spel. De SLA bepaalt een streeftijd waartegen we het merendeel (bv 90 %) van de incidenten ten laatste opgelost willen hebben. De queue zorgt ervoor dat we starten met het oplossen van de incidenten die het dichtst tegen de streefdatum zitten. Met de urgency flag kunen we een incident bovenaan de queue plaatsen en zullen we met dat ene incident toch sneller van start gaan, zonder dat we hiervoor de SLA parameters zoals impact of service criticality hebben moeten ‘misbruiken’.

Zolang dit algoritme ‘priority = impact x urgency’ in de ITIL boeken staat, zal dit Zombie idee menig process design en out-of-the box ITSM tool configuratie blijven teisteren. Als je in je organisatie weerstand ondervindt om van dit ongelukkige algoritme af te geraken, citeer dan Steve Jobs: “Don’t be trapped by dogma – which is living with the results of other people’s thinking”. En als dat ook niet helpt citeer dan Robert Kirkman (auteur van de The Walking Dead): “If it's dead - fucking KILL IT”.

Read more? Check out part 2 Zombie service management

About the author:

Wouter Wyns is a senior Service Management consultant at InfraVision with strong project management and business consultancy skills. His purpose is to help customers achieve their targets through creativity, quality and enthousiasm.