Een zombie-idee is een idee dat grondig is weerlegd door analyse en bewijs, en dus allang dood zou moeten zijn — maar dat nog steeds rondwaart. In de wereld van servicemanagement kom je af en toe zulke hardnekkige wezens tegen. In deze blog leg ik uit hoe je ze herkent en uiteindelijk vernietigt.
MEER DAN 50 TINTEN GRIJS
Onlangs vroeg mijn vrouw me om de radiator in onze keuken een nieuw kleurtje te geven, namelijk grijs. In de verfwinkel vroeg ik om grijze radiatorverf, en de verkoper gaf me een boekje van vijf pagina’s met elk vijf kolommen en zes rijen piepkleine rechthoekjes, elk in een andere grijstint – in totaal dus 150 tinten grijs – met de dwingende opdracht: “Hier, kies maar!”
Een onmogelijke keuze. “Wat zou u aanraden?” vroeg ik. De verkoper had die vraag vaker gekregen. Hij sloeg het boekje open op de derde pagina en wees het eerste vakje aan: “Deze wordt vaak gekozen, vooral voor radiatoren. Nooit iemand gehad die ontevreden terugkwam.”
Dus het werd die grijstint. Ook al wist ik eigenlijk wel zeker dat de populariteit van deze tint niets met zijn unieke uitstraling te maken had, maar alles met zijn positie in het midden van het boekje en de geruststellende gedachte dat iedereen deze kleur koos. Dit verschijnsel is bekend in de consumentenpsychologie en heeft een fraaie naam: “Overchoice”. De consument met keuzestress en tijdsdruk kiest gewoon het eerste veilige alternatief dat langskomt.
Een servicedeskmedewerker werkt voortdurend tegen de klok: nieuwe telefoontjes aannemen, tickets correct registreren, meteen een oplossing proberen te vinden en als dat niet lukt het ticket toewijzen aan het juiste team … Dus wil je die medewerker absoluut niet opzadelen met keuzestress.
DE “OVERCHOICE”-VAL
En toch gebeurt dat regelmatig. Een schrijnend voorbeeld is het bepalen van prioriteit op basis van het algoritme ‘prioriteit = impact x urgentie’. Dit algoritme is nog steeds prominent aanwezig in de ITIL Service Operation-handleiding van 2011, helaas niet als ‘in memoriam’. Daarbij worden de volgende richtlijnen gegeven: bij het bepalen van de prioriteit moet men rekening houden met hoe snel de business een oplossing nodig heeft, de potentiële financiële impact van het incident, de mogelijke impact op de reputatie van het bedrijf en het risico op wetsovertreding… Eh? Hoe snel wil de business een oplossing? Vraag het aan de gebruiker en die zegt: nu! Wat is de financiële impact? Vraag het aan vijf mensen en je krijgt zes verschillende antwoorden.
En dan moet die arme servicedeskmedewerker óók nog even nadenken over de juridische gevolgen van het incident en de reputatieschade voor het bedrijf.
Die prioriteitsbepaling op basis van ‘impact x urgentie’ is een horror voor een medewerker die onder tijdsdruk werkt. En onder die keuzestress doet hij wat een consument ook doet: het eerste veilige alternatief kiezen. Net zoals ik – en velen met mij – kies voor het grijze vakje linksboven op pagina drie, kiest de servicedeskmedewerker steevast voor dezelfde impact- en urgentiecodes. Op termijn wordt de prioritering in zo’n systeem zo plat als een dubbeltje.
De zilveren kogel om dit hardnekkige monstertje te doden is het algoritme ‘impact x servicekritikaliteit’. Niet elke service is immers even belangrijk of kritisch – de schade bij onbeschikbaarheid van de SAP-service is niet dezelfde als bij SharePoint. In de meeste gevallen zal SAP belangrijker zijn. Die ‘servicekritikaliteit’ bepaal je vooraf en leg je vast in de configuratie van het ITSM-systeem. Elk incident wordt gekoppeld aan een service, dus de servicedeskmedewerker hoeft zich daar niet druk om te maken. Die bepaalt alleen de impact. En dat kun je in eerste instantie eenvoudig houden: impact op één of meerdere gebruikers, service onbeschikbaar of slechts gedegradeerd — gecombineerd met maximaal vier simpele keuzes.
Het omzetten van de prioriteit naar een exacte tijdslimiet is de voorhamer waarmee je deze zombie volledig uitschakelt. ‘Exact’ betekent dat het ITSM-systeem de oplostijd automatisch berekent met inachtneming van supporturen en feestdagen. Weg met de vlakke wachtrijen — je tweede- en derdelijnsteams kunnen nu objectief werken aan de meest urgente incidenten.
URGENTIE – HOE GA JE DAARMEE OM?
En wat dan met ‘urgentie’, is dat concept nu dood en begraven? Niet als je het correct toepast. Het bovenstaande algoritme implementeert je SLA’s, je afspraken met de business. Die zeggen bijvoorbeeld dat als een individuele gebruiker geen toegang heeft tot SAP (impact = gemiddeld), dit binnen 8 uur opgelost moet zijn. In de meeste gevallen is dat prima voor de gebruiker. Maar voor de financieel controller die aan het eind van de maand zijn rapportage moet afronden, zijn die 8 uur een eeuwigheid te laat. Daar komt de urgentievlag om de hoek kijken.
De SLA bepaalt de streeftijd waarbinnen we een meerderheid (bijv. 90%) van de incidenten opgelost willen hebben. De wachtrij zorgt ervoor dat we beginnen met de incidenten die het dichtst tegen hun deadline zitten. Door de urgentievlag kunnen we een specifiek incident bovenaan de wachtrij plaatsen, zodat we er sneller aan beginnen — zonder dat we daarvoor de SLA-parameters (zoals impact of servicekritikaliteit) hoeven te ‘misbruiken’.
Zolang het ‘prioriteit = impact x urgentie’-algoritme in de ITIL-boeken staat, zal dit zombie-idee nog veel procesontwerpen en standaard ITSM-configuraties blijven teisteren. Ervaart jouw organisatie weerstand bij het afscheid nemen van dit achterhaalde algoritme? Quote dan Steve Jobs:
“Don’t be trapped by dogma – which is living with the results of other people’s thinking.”