TL;DR: je moet SLA-diensten gebruiken als je rapporteert over oplostijden van meldingen. Doe je dat niet? Dan weet je niet wat je meet.
TOPdesk kan rekenen, en best wel goed. Iets wat TOPdesk erg goed kan uitrekenen, is hoe lang het heeft geduurd voordat meldingen zijn opgelost. Daar kun je mooie rapportages over maken, om die vervolgens aan hoger management te laten zien. Zinnige stuurinformatie over de prestaties van de dienstverlening aan je klanten of eindgebruikers. Ja toch niet dan!?
De realiteit is weerbarstiger. Geregeld zie ik bij organisaties dat er wel rapportages zijn over hoe snel meldingen zijn opgelost, maar dat er geen SLA-diensten zijn ingeklikt. Dat is niet handig, en om dit aan te tonen zoom ik in op een onbeduidend veldje, een van de velen, op de meldingskaart. Dat veldje heeft het echter wel in z’n mars om je hele rapportage onderuit te halen. Rapporteer je dus aan een kritische IT-manager die wil weten wat je meet? Dan moet je eerst zelf goed weten wat je meet. En dit begint bij begrijpen hoe het veldje streefdatum precies werkt.
Echt gebeurd verhaal
Stel dat jij ervoor moet zorgen dat TOPdesk zinnige stuurgegevens over je meldingen genereert. Dan moet je aan de bak. Er moet een sloot data goed worden ingevoerd of gecontroleerd in de applicatie: impact, urgentie, prioriteiten, matrixje erbij, service windowtje, doorlooptijden, vakantiedagen, en alles moet goed aan elkaar gekoppeld zijn. Ook moet je goed checken of meldingen op on hold kunnen en mogen staan en wanneer niet. Al met al best ingewikkeld om goed in te regelen.
Zijn alle variabelen goed ingevuld? Dan doet TOPdesk de magic. TOPdesk pakt de begindatum van de melding, en gaat vervolgens optellen, aftrekken, delen, vermenigvuldigen. Daar komt een datum en tijdstip uit, dat weergeeft wanneer de melding moet zijn opgelost volgens de norm. Dat tijdstip verschijnt in het veld streefdatum. Is je melding opgelost voor de streefdatum? Dan blijft de melding zwart. Is de streefdatum verstreken maar de melding is nog niet opgelost? Dan wordt ie rood. Een melding is dus zwart of rood, en niet iets ertussenin. Dat is best logisch: het geeft houvast voor IT-managers die iets moeten vinden over stuurgegevens.
Maar neem nou het volgende scenario: de databasebeheerder heeft een ticket in z’n queue met streefdatum 21:23u morgenavond. Maar ja, hij/zij moet echt een nieuwe applicatie testen en er is nog een wijziging die sowieso eerst moet. En hij/zij moet ook nog naar de tandarts. De databasebeheerder verandert met de hand de streefdatum naar eigen inzicht, vijf dagen verder in de toekomst. 
Dat kan namelijk als je niet met SLA-diensten werkt. Daarvoor is het kalenderknopje bij streefdatum (zie gele rondje). Resultaat: het moeilijke rekenwerk van TOPdesk: allemaal voor niets geweest! En al die instellingen van TOPdesk: zomaar in de wind geslagen.
Is dit dan erg?
Het echte punt is natuurlijk dat die melding in de rapportage als zwart terugkomt, terwijl ie eigenlijk rood had moeten zijn. De klant of de eindgebruiker moest namelijk toch langer wachten dan de norm die in TOPdesk is ingeklikt. Je rapportage is dus rooskleuriger geworden. Tegelijkertijd gaat er waarschijnlijk niemand uit eigen beweging de streefdatum eerder zetten dan de norm. Er is dus geen compensatiemechaniekje de andere kant op. Meet je dus over oplostijden, maar zonder SLA-diensten? Realiseer dan dat je die cijfers niet zomaar kunt vertrouwen.
Problematischer is echter dat je je rapportages niet zomaar kloppend kunt maken. TOPdesk heeft geen knopje om bij alle meldingen waarbij de streefdatum ooit is veranderd de waarde weer terug te zetten op de standaard. Je moet dus met de hand gaan workarounden. Dit is soms al bij voorbaat onmogelijk vanwege de aantallen. Ga je toch die weg bewandelen? Dan verzand je al snel in selectiecriteria, doorlooptijden, en geschiedenisentries. Niet leuk. Je kunt beter Droomhuis gezocht kijken, met Sybrand Niessen. Of een borrel drinken. Met Sybrand Niessen.
Het feit dat behandelaars in TOPdesk zelf een streefdatum kunnen kiezen en daarmee de uitgerekende streefdatum kunnen overschrijven heeft dus verregaande consequenties. Je weet niet of je rapportage een accurate weergave is van de realiteit. Met andere woorden: je weet niet wat je meet.
Help! En nu?
Het kan gelukkig wel anders, namelijk door te werken met SLA-diensten in meldingen. Hiermee maak je het eigengereide behandelaars onmogelijk om naar eigenlijk inzicht het veldje streefdatum aan te passen. Dat vinden ze misschien niet leuk, maar ja, zo is de leven. In het screenshot zie je hoe een melding met SLA eruit ziet: het veld streefdatum is verdwenen, en het veldje SLA-streefdatum is erbij. 
Dat laatste veld heeft geen klikbaar kalenderknopje meer; je kunt de datum niet veranderen. Wat je hiermee wint is de zekerheid dat je weet wat je meet.
Ben jij verantwoordelijk voor IT en wil je kritisch doorvragen op de rapportage over oplostijden van meldingen? Vraag dan of de rapportage is gemaakt op basis van ingeklikte SLA-diensten op meldingen. Zo niet, neem de cijfers dan met een korreltje zout. Ben je servicemanager en zie je je IT-manager al aanlopen? Ga dan met je TOPdesk-applicatiebeheerder zitten om SLA-diensten goed in te richten. En ben je TOPdesk-applicatiebeheerder maar weet je niet waar je moet beginnen om dit netjes in te richten? Neem dan contact op!
