Instructeur: In deze
les gaan we het hebben over de laatste
stap in de methodologie voor probleemoplossing,
namelijk stap zes, documentatie.
CompTIA noemt dit document de bevindingen,
acties en uitkomsten en dit gaat
echt over documenteren wat er mis was, wat je eraan hebt gedaan
en wat je kunt doen
om het in de toekomst te voorkomen.
Nu is elke organisatie een beetje anders in hoe
ze hun documentatie maken voor alle verschillende
problemen en problemen die
ze binnen het bedrijf hebben gehad.
In mijn bedrijf gebruiken we een speciaal trouble ticketing
systeem waarmee we alle problemen kunnen
documenteren, aan wie ze zijn toegewezen, wat ze hebben gedaan om
het probleem op te lossen en wat de oplossing was.
Daarnaast hebben we ook
onze eigen interne kennisbank waar we al onze stappen voor
probleemoplossing kunnen verzamelen en alle
dingen die we in het verleden hebben geleerd toen
we verschillende problemen aan het oplossen waren.
Daarnaast hebben we ook een
gebied genaamd onze Veelgestelde vragen, en dit is een gebied met
een heleboel verschillende
ondersteuningsartikelen gebaseerd op de vragen
die we dagelijks krijgen van onze eindgebruikers.
Het heeft lang geduurd om onze kennisbank en onze
veelgestelde vragen op te bouwen,
maar het is iets dat echt nuttig is,
vooral voor nieuwe technici als ze bij het team komen, omdat
ze onze veelgestelde
vragen en onze kennisbank kunnen doornemen
en leren hoe we zaken doen en hoe we problemen oplossen.
Als je als technicus werkt, heeft
je organisatie misschien wel of niet een kennisbank, veelgestelde
vragen of een probleemticketsysteem,
afhankelijk van de grootte van je
organisatie.
Tegenwoordig kunnen zelfs kleine organisaties
een goed trouble ticketing systeem krijgen
voor een zeer lage prijs of zelfs gratis in sommige gevallen.
Er zijn er veel, zoals Freshdesk,
Jira, Help Scout, Intercom en vele, vele anderen.
Het maakt niet uit welke je gebruikt,
maar het idee is hetzelfde.
Je wilt je bevindingen, acties en
resultaten kunnen documenteren.
Een ander onderdeel hiervan
is dat je niet per se tot het einde wilt wachten
om dit te doen.
Als je een ticket krijgt toegewezen
en het probleem identificeert, moet
je teruggaan naar het trouble ticket systeem
en documenteren wat je hebt geïdentificeerd, wat de
symptomen waren die je zag, wat denk
je dat de waarschijnlijke oorzaak van dit probleem is, en terwijl
je door de stappen gaat, wil je dit blijven
bijwerken.
Als je te maken hebt met een klein probleem dat in één
keer kan worden opgelost,
hoef je het ticket waarschijnlijk niet voor
elke stap bij te werken.
Maar als je te maken hebt met een groter probleem,
dan is het echt belangrijk om dit te documenteren binnen
dat trouble ticket systeem.
Een andere reden waarom het trouble
ticket systeem zo belangrijk is, vooral in grote organisaties,
is dat je er trendanalyses mee kunt doen.
Zo kun je erachter komen wat de gemeenschappelijke
thema's of problemen zijn waarmee je organisatie
te kampen heeft.
In een organisatie waar ik werkte, ontdekten we bijvoorbeeld
dat 90% van onze telefoontjes voor trouble tickets te maken had met mensen
die hun wachtwoord opnieuw moesten instellen.
Dat waren enorm veel uren die we
besteedden aan het resetten
van wachtwoorden.
Dus besloten we dat dit geen trend was die we leuk
vonden en uiteindelijk werkten we
samen met onze ontwikkelaars en
onze systeemingenieurs om een optie te maken waarmee mensen hun
eigen wachtwoorden konden resetten.
En dit verminderde onze hoeveelheid trouble tickets met ongeveer 90% zodra
dat systeem in gebruik werd genomen.
Deze documentatie kan dus heel belangrijk zijn bij
het identificeren van gebieden voor voortdurende
verbetering voor je organisatie.
Een ander nevengebruik van dit trouble ticketing systeem
dat je gebruikt om je bevindingen, acties en resultaten
te documenteren, is dat je de hoeveelheid werk die je hebt gedaan
kunt documenteren.
Dit kan een goede of slechte zaak zijn, afhankelijk
van hoeveel werk je doet, maar ik kan je persoonlijk
vertellen dat als IT-directeur die een helpdesk leidde
met 150 mensen die meer dan 15.000 gebruikers ondersteunden,
we ons trouble ticket systeem voortdurend gebruikten om het feit te rechtvaardigen dat ik meer
mensen nodig had om die 15.000 gebruikers te ondersteunen.
En dat kwam omdat we het volume van onze
tickets zagen stijgen.
Toen we ernaar gingen kijken,
ontdekten we dat het kwam doordat er nieuwe
systemen werden geïnstalleerd en vaak
gaf de organisatie wel geld uit aan nieuwe
systemen, maar niet aan het
trainen van de gebruikers, waardoor er meer telefoontjes naar de servicedesk
kwamen.
Anders loopt het hele systeem vast.
Houd dit dus in gedachten.
Hoe meer je kunt documenteren, hoe beter je kunt verantwoorden
wat jij als technicus doet en van welke grotere
helpdeskmedewerkers je deel uitmaakt, en dit kan helpen om te bepalen
wanneer er meer middelen in je servicedesksysteem
moeten worden gestoken om meer mensen aan te nemen of om het vaardigheidsniveau van de mensen die je hebt
te verhogen zodat ze die oproepen op een betere
en efficiëntere manier kunnen beantwoorden.