Is jouw bedrijf afhankelijk van zijn helpdesk? Wees er dan trots op. Om businesscontinuïteit te garanderen, zijn er namelijk maar weinig vaardigheden waardevoller dan het oplossen van it-problemen. Ja, zelfs de werkdruk van de marketingafdeling en vergelijkbare afdelingen verbleekt naast die van de medewerkers die zich dagelijks bezighouden met troubleshooting.
Zoals bij de meeste beroepen is ook in it niet iedereen hetzelfde, en de vaardigheden van it-personeel verschillen van bedrijf tot bedrijf (net als hun salaris, overigens). Wat onderscheidt het doorsnee it-personeel van de echte professionals, oftewel degenen die geraadpleegd worden bij een crisis?
Misschien zijn het wel zebra’s
Sommige werkgevers gebruiken diploma’s en certificaten, de werkervaring of zakelijke prestaties als richtlijn. Maar hoe kom je – als je het cv opzij schuift – er nu echt achter of iemand goed is in het oplossen van it-problemen? Door hun vaardigheden te testen. It-problemen oplossen is een vaardigheid die zich door de tijd heen ontwikkelt. In tegenstelling tot wat veel mensen denken, is het niet jarenlange ervaring (al helpt dat wel) of een onderbuikgevoel waar de beste it-werknemers in de praktijk op vertrouwen om problemen te achterhalen.
Een veelgebruikte term is ‘confirmation bias’: de neiging van mensen om te zien wat ze verwachten te zien. Het gaat dan om een situatie waarin een it-probleem wordt vastgesteld zonder analyse en voordat daadwerkelijk een oplossing is gevonden. Bijvoorbeeld de neiging om de analyse op zo’n manier te interpreteren, dat het past bij het probleem. Zo’n ad-hoc-benadering is echter geen goed plan, en helemaal niet wanneer bedrijfskritische processen ervan afhankelijk zijn om te blijven draaien.
Een gezegde in de medische wereld luidt: ‘Als je hoefgetrappel hoort, denk dan eerst aan paarden en niet meteen aan zebra’s.’ Oftewel, gebruik bij een diagnose je gezonde verstand en ga uit van de meest alledaagse verklaring. Dit gaat echter niet op voor de it-wereld. Voor mensen in bepaalde delen van Afrika zijn zebra’s waarschijnlijker, en hetzelfde geldt voor de helpdesk: die ziet bedreigingen die andere gebruikers wellicht niet zouden verwachten. Als je serieus aan de slag wilt met probleemoplossing in it, dan is een vast proces noodzakelijk. Of je het nu troubleshooting of diagnostiek noemt: een gestructureerde en logische methode is altijd aan te raden. Hoewel het advies ‘uit- en aanzetten’ nog altijd relevant kan zijn, is het geen vervanger voor logica – hoe vluchtig ook – wanneer je op zoek bent naar een fout.
It-problemen zijn er in veel soorten en maten, en hebben soms meerdere mogelijke oplossingen en die kunnen allemaal in bepaalde mate helpen. Documenten met standard operating Pprocedures (sop) zijn iets flexibeler in het vereenvoudigen van diagnostiek, zonder dat je direct beperkt bent tot één vaste processtroom. In tegenstelling tot andere afdelingen is het voor it onmogelijk om processen en procedures in steen te beitelen. Troubleshooting is per definitie een zoektocht door allerlei aanwijzingen die zomaar kunnen leiden naar een gloednieuwe bron – die op zijn beurt weer een oplossing verschaft – die je opnieuw kunt gebruiken als het probleem zich nogmaals voordoet.
Echt waar, Sherlock?
Net als detectives hebben it-professionals te maken met een case – meestal een klacht van een gebruiker of de observatie dat het netwerk abnormaal overbelast is. Het oplossen van het probleem omvat altijd vijf hoofdstappen die doorlopen moeten worden. En dit proces biedt geen ruimte voor geïmproviseerde patches. De vijf stappen beginnen bij de signalering van een probleem, gevolgd door:
- verzamelen van alle beschikbare informatie of de vraag ‘Hoe openbaart het probleem zich?’;
- analyse van de informatie ‘Wat betekent dit, technisch gezien?’;
- eliminatieproces: als het draadloze netwerk traag is, is het onwaarschijnlijk dat het koffiezetapparaat er iets mee te maken heeft (dat op een apart netwerk zit);
- nadenken over de oorzaak: ‘Wat kan het probleem zijn?’ Er zijn meerdere mogelijkheden en die moeten op volgorde van waarschijnlijkheid gerangschikt worden;
- testen van de oplossing: afhankelijk van het tijdstip en het risico op downtime, is verdere analyse wellicht noodzakelijk voor de implementatie.
Diagnostische methoden
Een vast proces volgen is één ding, maar hoe zit het met methoden? Helaas zijn er meerdere methoden die regelmatig toegepast worden tijdens het oplossen van it-problemen. De keuze is vaak afhankelijk van het betreffende probleem. De meest voorkomende zijn:
- volgen van verkeer: met netwerkmonitoringtools is veel mogelijk om diagnostiek te vereenvoudigen, zoals het in de gaten houden van routes, ping en verkeersanalyse;
- zoeken van verschillen: vergelijk apparaten of processen die wel werken, met de apparaten of processen die niet werken;
- verplaatsing van het probleem: als je een apparaat verplaatst of kabels omwisselt, verplaatst het probleem dan mee?
It-diagnostiek vraagt om een protocol van een specialist. En hoewel gangbare problemen mogelijk prima op te lossen zijn op basis van instinct of logica, is het beter om alle problemen op een gestructureerde manier aan te pakken. Een ticketsysteem is wellicht de meest zichtbare vorm hiervan, waarmee je bedrijf een tastbaar naslagwerk in handen heeft met alle problemen, de tijd die het heeft gekost om ze op te lossen, en de gebruikte oplossingsmethoden. Dit is in ieder geval een betere manier dan slechts vertrouwen op een onderbuikgevoel of aannames over bepaalde apparaten of software.
Michael O’Dwyer, copywriter bij Ipswitch
