- De meeste bedrijven hebben geen volledig intern IT-team nodig om effectieve ondersteuning te bieden
- Het definiëren van niveaus (Tier 1 basis, Tier 2 technisch, Tier 3 specialist) voordat u tools kiest, bespaart tijd en geld
- Een ticketingsysteem is de basis. E-mailthreads en spreadsheets zijn geen servicedesk
- SLAs moet realistisch zijn. Als u voor alles een reactie van één uur hanteert, ontstaat er een steunschuld die u niet kunt inlossen
- Beheerde IT-providers bieden u een volledig team tegen een maandelijks bedrag, vaak goedkoper dan het inhuren van één senior
Wat een IT-servicedesk eigenlijk moet doen
Een IT-servicedesk heeft één taak: ervoor zorgen dat wanneer er iets kapot gaat of iemand blokkeert bij het uitvoeren van zijn werk, dit op een voorspelbare, traceerbare manier wordt opgelost. De meeste organisaties die beweren een servicedesk te hebben, draaien iets losser: een e-mailadres, een groepschat en een paar mensen die reageren als ze toevallig een bericht zien.
Een echte servicedesk ontvangt verzoeken via een gedefinieerd kanaal, registreert ze als afzonderlijke items, wijst het eigendom toe, houdt de voortgang bij en sluit ze af met de bevestiging dat het probleem is opgelost. Geen logboekregistratie betekent geen zichtbaarheid van de achterstand. Tickets die niet in eigendom zijn, worden genegeerd. Zonder sluitingsbevestiging vult uw wachtrij zich met problemen die zijn gemarkeerd als 'waarschijnlijk goed nu' en die niemand heeft geverifieerd.
Het moet ook twee verschillende stromen afhandelen: incidenten (er is iets kapot en moet nu worden opgelost) en serviceverzoeken (een gebruiker moet iets instellen, wijzigen of uitleggen). Als alle verzoeken op dezelfde manier worden behandeld, ontstaat er prioriteitsverwarring. Een laptop die niet opstart valt niet in dezelfde categorie als een verzoek om een nieuwe gebruiker toe te voegen aan een gedeelde schijf. Uw bureau moet onderscheid maken tussen deze twee, zelfs op een basisniveau.
Onopgeloste IT-problemen kosten een gemiddelde werknemer 22 minuten productiviteitsverlies per incident. In een organisatie van vijftig mensen die met een handvol dagelijkse problemen te maken heeft, leidt dat elke maand tot dagen verlies aan output: kosten die nooit op een factuur verschijnen.
Definieer uw ondersteuningsniveaus voordat u tools aanschaft
Het allernuttigste dat u kunt doen voordat u een software of dienst evalueert, is definiëren met welke soorten IT-problemen uw organisatie daadwerkelijk wordt geconfronteerd, en deze in lagen indelen. Dit duurt ongeveer twee uur, kost niets en voorkomt dat u een ondersteuningsmodel overbouwt voor problemen die u niet heeft.
De meeste problemen zouden op niveau 1 moeten worden opgelost. Alles wat er doorheen gaat, gaat naar niveau 2, en alleen echt complex werk bereikt niveau 3.
- Niveau 1: Basisondersteuning. Het opnieuw instellen van wachtwoorden, printerproblemen, vragen over de software-installatie, e-mailconfiguratie, eenvoudige hardwareproblemen oplossen en alles wat kan worden opgelost met een kennisbankartikel of een sessie van 10 minuten op afstand. De persoon die met Tier 1 omgaat, heeft geen diepgaande technische kennis nodig. Ze hebben geduld, een goede kennisbasis en toegang tot tools voor ondersteuning op afstand nodig.
- Niveau 2: Technische ondersteuning. Netwerkconfiguratie, applicatiefouten die loganalyse vereisen, apparaatimaging, VPN-installatie, problemen met softwarelicenties en alles waarvoor toegang op beheerdersniveau vereist is. Tier 2-ingenieurs hebben echte technische vaardigheden nodig en het vermogen om problemen te diagnosticeren zonder een script. De responstijden zijn langzamer dan die van niveau 1, omdat deze problemen meer onderzoek vergen.
- Niveau 3: Specialistische ondersteuning. Beveiligingsincidenten, infrastructuurarchitectuur, aangepaste integraties, compliance-gerelateerde systeemwijzigingen en alles waarvoor een specifiek expertisegebied vereist is waar uw Tier 2-team niet over beschikt. Bij niveau 3 kunnen externe specialisten, een beheerde beveiligingsprovider of het eigen ondersteuningsteam van de leverancier betrokken zijn. Deze tickets hebben van nature langere resolutietijdlijnen.
Niveaudefinities maken beslissingen over personeel en tools eenvoudig. Een bedrijf waar 90% van de problemen Tier 1 betreft, heeft een andere opzet nodig dan een bedrijf waar veranderingen in de infrastructuur constant zijn. Het kan zijn dat uw gehele Tier 1-lading kan worden afgehandeld door een zelfbedieningsportaal en een beheerde provider, zonder dat er intern personeel hoeft te worden ingehuurd.
Ticketing en tracking: de minimaal haalbare opzet
De basisregel van een servicedesk is deze: als deze niet in het systeem staat, bestaat deze niet. Voor elke aanvraag is een ticket nodig. Elk ticket heeft een status nodig (open, in uitvoering, wachtend op gebruiker, opgelost). Voor elk opgelost ticket is een registratie nodig van wat er is gedaan. Dit is geen bureaucratie op zichzelf. Het is de enige manier om een wachtrij te beheren waar meer dan één persoon aan werkt, en de enige manier om patronen te identificeren wanneer hetzelfde probleem steeds terugkeert.
"Een servicedesk zonder ticketingsysteem is een wachtrij die niemand kan zien."
Voor kleine en middelgrote bedrijven is de keuze van het gereedschap minder belangrijk dan de discipline waarmee het wordt gebruikt. Freshservice, Zoho Desk, Jira Service Management en HelpScout werken allemaal goed op deze schaal. Freshservice is het meest speciaal gebouwd voor IT-servicebeheer: het omvat het volgen van bedrijfsmiddelen, een zelfbedieningsportaal en kant-en-klare automatiseringsregels. Zoho Desk kan probleemloos worden geïntegreerd met andere Zoho-producten als u zich al in dat ecosysteem bevindt. Jira Service Management is geschikt voor technische teams die al Atlassian gebruiken. Ze kunnen alle drie binnen een dag worden geconfigureerd en operationeel zijn.
De minimale configuratie die u nodig heeft voordat u live gaat, is: één intakekanaal (een formulier of e-mailadres dat automatisch tickets aanmaakt), ticketcategorieën die overeenkomen met uw niveaudefinities, een toewijzingsregel zodat tickets bij de juiste persoon terechtkomen, en een eenvoudige SLA-klok zodat u kunt zien wat te laat is. Al het andere (vermogensbeheer, automatisering, klanttevredenheidsonderzoeken) kan worden toegevoegd zodra de basis soepel loopt. Proberen alles in één keer te configureren, is de reden waarom de uitrol van de servicedesk vastloopt.
SLAs: waar u zich aan moet committeren en wat u moet vermijden
Een Service Level Agreement (SLA) is een afspraak over hoe snel u zult reageren op verschillende soorten ondersteuningsverzoeken en deze zult oplossen. SLA's zijn nuttig omdat ze verwachtingen scheppen, verantwoordelijkheid creëren en u een manier bieden om te meten of uw servicedesk presteert. Ze worden een probleem als ze onrealistisch worden ingesteld, omdat u dan meer energie besteedt aan het beheren van SLA-inbreuken dan aan het oplossen van problemen.
De meest voorkomende fout die groeiende bedrijven maken, is het instellen van dezelfde SLA voor alles. Een enkele regel "reageer binnen een uur" klinkt professioneel, maar is onwerkbaar als u over een Tier 2- of Tier 3-volume beschikt. Een netwerkrouteringsprobleem dat door een gekwalificeerde technicus moet worden onderzocht, wordt niet binnen een uur opgelost. Als je je aan die tijdlijn houdt, ontstaat er alleen maar een lijst met SLA-overtredingen die niemand vertrouwt en die iedereen negeert.
Een duurzamere aanpak is om SLAs in te stellen op prioriteitsniveau. Prioriteit wordt bepaald door impact (hoeveel mensen worden getroffen) en urgentie (in hoeverre blokkeert dit op dit moment). De onderstaande tabel is een redelijk uitgangspunt voor een bedrijf met 20 tot 150 gebruikers. Pas de tijdschema's aan uw ondersteuningscapaciteit aan en wees eerlijk over wat u daadwerkelijk kunt volhouden.
- Kritiek (systeem defect, meerdere gebruikers getroffen): binnen 30 minuten reageren, binnen 4 uur oplossen
- High (one user blocked from core work): binnen 2 uur reageren, binnen 8 uur oplossen
- Gemiddeld (slechte service, oplossing beschikbaar): binnen 4 uur reageren, binnen 2 werkdagen oplossen
- Laag (vraag, klein probleem, niet-blokkerend): binnen 1 werkdag reageren, binnen 5 werkdagen oplossen
Het is beter om conservatieve SLA's in te stellen en deze consequent te verslaan dan agressieve doelen te stellen en deze regelmatig te missen. Gebruikers onthouden de tijden die u hebt gemist beter dan de tijden die u hebt afgeleverd. Als u met een beheerde provider werkt, moeten de SLAs in uw contract overeenkomen met wat u intern publiceert. Als uw interne verplichtingen niet overeenkomen met de contractuele verplichtingen van uw provider, ontstaan er hiaten die gebruikers altijd opmerken.
Vermijd het maken van SLA-doelen op basis van wat goed klinkt in plaats van wat uw capaciteit ondersteunt. Als uw Tier 2-ingenieur één persoon is die meerdere verantwoordelijkheden draagt, zal een SLA met een resolutie van 4 uur over complexe problemen voortdurend inbreuk maken. Begin met wat u betrouwbaar kunt leveren en haal de SLAs aan naarmate uw capaciteit groeit.
Wanneer schakel je een managed service provider in?
Een Managed IT Service Provider (MSP) geeft u toegang tot een volledig team van IT-professionals tegen een maandelijks bedrag. In de praktijk omvat dit doorgaans uw Tier 1- en Tier 2-ondersteuning, proactieve monitoring van uw infrastructuur, patchbeheer en vaak ook beveiligingsdiensten. Het businessmodel werkt omdat de MSP specialistische personeelskosten over veel klanten spreidt. U krijgt het voordeel van een team zonder de kosten om er een te bouwen.
De financiële casus is eenvoudig. Een senior IT-ingenieur met de vaardigheden om Tier 2-ondersteuning, enige beveiligingskennis en infrastructuurcompetentie te dekken, kost in Nederland tussen €60.000 en €85.000 per jaar, exclusief vergoedingen, apparatuur en beheeroverhead. Een MSP-contract uit het middensegment voor dezelfde organisatie kost doorgaans een fractie van dat bedrag. Je koopt niet alleen goedkopere ondersteuning. U koopt dekking voor vakanties, ziekte en de onderbrekingsperioden die optreden wanneer één interne persoon vertrekt. Continuïteit heeft echte waarde.
De vraag wanneer je een MSP moet inschakelen in plaats van intern in te huren, komt neer op volume en variëteit. Als uw IT-aanvragen voorspelbaar van aard zijn en een laag volume hebben, kunnen een goed geconfigureerde selfserviceportal en een parttime interne hulpbron voldoende zijn. Als uw verzoeken qua technische complexiteit sterk variëren, of als u 24-uurs dekking, beveiligingsmonitoring of compliance-gerelateerde IT-ondersteuning nodig heeft, is een MSP bijna altijd de kosteneffectievere en veerkrachtigere optie. Een hybride model is ook gebruikelijk: een MSP verzorgt de dagelijkse wachtrij, terwijl een interne IT-manager eigenaar is van leveranciersrelaties, inkoop en strategische beslissingen.
Meten of uw servicedesk werkt
Een servicedesk die u niet kunt meten, is een servicedesk die u niet kunt verbeteren. De meeste ticketingtools bieden standaard basisrapportage en je hebt geen complexe analyses nodig om nuttig inzicht te krijgen. Begin met vier statistieken en bekijk deze maandelijks. Zodra deze stabiel en begrepen zijn, voegt u meer diepte toe. Als je vanaf het begin tien statistieken nastreeft, betekent dit meestal dat geen van deze de juiste aandacht krijgt.
De vier meetgegevens die er het meest toe doen in de beginfase van een servicedesk zijn: eerste reactietijd (hoe lang duurt het voordat een gebruiker een bevestiging krijgt dat zijn ticket is gezien), oplossing tijd (hoe lang vanaf het aanmaken van het ticket tot de bevestigde oplossing), SLA-nalevingspercentage (welk percentage tickets wordt opgelost binnen de vastgelegde tijdschaal), en percentage herhaalde uitgiften (hoeveel tickets deze maand gaan over hetzelfde onderliggende probleem dat eerder verscheen). Vooral dat laatste is waardevol. Een hoog herhalingspercentage geeft aan dat uw servicedesk symptomen verhelpt en geen oorzaken. Terugkerende printerproblemen die week na week voorkomen, zijn een hardwareaankoopprobleem en geen ondersteuningsprobleem.
Naast de cijfers is het de moeite waard om een korte tevredenheidsenquête uit te voeren bij het sluiten van de tickets. Een enkele vraag ("Is uw probleem naar tevredenheid opgelost?") met een ja of nee antwoord en een optioneel commentaarveld geeft u een kwalitatief signaal dat statistieken alleen niet kunnen bieden. Gebruikers die ontevreden zijn ondanks dat een ticket als opgelost is gemarkeerd, wijzen vaak op iets belangrijks: de oplossing was tijdelijk, de communicatie was slecht of de oplossingstijd lag technisch gezien binnen SLA, maar voelde onaanvaardbaar traag gezien de impact. Die feedback is goud waard als je ernaar handelt.
De ITIL-framework, onderhouden door Axelos, is de industriestandaard voor IT-servicemanagementprocessen en definieert de praktijken waarnaar in deze handleiding wordt verwezen. De itSMF Nederland is de lokale beroepsorganisatie voor servicemanagementbeoefenaars.