4 problemen van Problem Management

Problem Management gaat niet alleen over het vinden en oplossen van problemen.

Door de dagelijkse routine van het oplossen van problemen kan je het grotere plaatje gemakkelijk over het hoofd zien. Laten we daarom eens kijken naar ​​paar van de meest voorkomende obstakels van IT supportteams. De tips die je krijgt gaan niet  over het oplossen van problemen, maar om ze te voorkomen.

Probleem 1: De reactieve valstrik

Als je de hele dag tickets binnen krijgt ga je gemakkelijk over op de automatische piloot. De “vind en repareer het” -modus. Standaard servicedesk KPI’s stimuleren servicedeskmedewerkers om zoveel mogelijk problemen op te lossen, en terecht.

Bedenk echter dat een dergelijk Problem Management proces slechts een fractie van de waarde toevoegt aan het bedrijf. In tegenstelling tot alleen maar te reageren op problemen, is het echte doel van Problem Management altijd het voorkomen van herhaling van incidenten. Einddoel moet een IT-service zijn die continu en probleemloos draait.

Om dit te bereiken moet je de definitie van Problem Management verbreden. Dit is de volledige reikwijdte waarvoor je Problem Management verantwoordelijkheid zou moeten zijn voor:

• Voorkomen van terugkerende incidenten en de service-verstoringen die ze kunnen veroorzaken.
• De impact van incidenten tot een minimum beperken wanneer ze niet volledig kunnen worden voorkomen.
• Informatie over problemen en tijdelijke oplossingen documenteren en ervoor zorgen dat medewerkers weten waar deze documentatie het te vinden is.
• Ervoor zorgen dat de juiste processen worden gevolgd.

Dit is overeenkomstig de vele frameworks voor best practices zoals ITIL en ASL. In de praktijk gooien een hoog ticketvolume en beperkte middelen echter vaak roet in het eten. Kritieke taken, zoals het bijwerken van de kennisdatabase, of voorspellende monitoring blijven dan achterwege. Dit soort taken zouden echter het aantal ernstige toekomstige onderbrekingen met een aanzienlijk percentage kan verminderen. Loop niet in die valstrik, dat kan je je gewoon niet permitteren.

Probleem 2: Problemen niet delen

Een veel voorkomende misvatting is dat Problem Management een solitaire rol is, of de verantwoordelijkheid van een kleine deel van de servicedesk.

Problem Manager is inderdaad een rol. En de verantwoordelijkheidsmatrix van ITIL zorgt ervoor dat het lijkt alsof de Problem Manager verantwoordelijk is voor het proces. Maar ook Applicatie Beheer en de technische analisten hebben een grote rol in de hele probleemdiagnose en oplossingsfase.

Het idee dat een probleem één enkele oorzaak heeft moet je achter je laten. Meestal leiden meerdere storingen tot een probleem. Daarom moeten de gespecialiseerde teams (netwerken, infrastructuur, hosting, enz.) samenwerken. Samen werken ze als een agile probleemresponsteam, dat verschillende theorieën of mogelijke oplossingsrichtingen ontrafelt en onderzoekt.

Het lijkt misschien een beetje luxueus of arbeidsintensief, maar complexe incidenten worden zo het snelste opgelost.

Probleem 3: Te weinig vragen stellen

Als met een probleem naar de garage ga doen ze alsof ze luisteren en knikken ze hun hoofd. Dan koppelen ze mijn auto aan een machine die zegt dat er niets aan de hand is. Ik betaal voor de “check up” en twee dagen later sta ik aan de kant van de weg; gestrand.

Het lijkt net of ze zijn vergeten hoe ze moeten denken en vragen moeten stellen, vooral de ‘waaromvraag’.

Ironisch genoeg is het de auto-industrie waarin een van de beste technieken voor het vinden van probleemoorzaken is ontwikkeld. Het wordt “The 5 Whys” genoemd en het werd bedacht door Sakichi Toyoda (Toyota Motor Corporation).

Het is een eenvoudige methode die goed werkt in IT. De beste manier om ‘Five Why’s’ uit te leggen is met een voorbeeld.

Geef eerst het probleem aan: Het systeem is heel traag.

Waarom? – Het ophalen van de data gaat moeizaam. (Eerst waarom)

Waarom? – Er is een storing op het SAN. (Tweede waarom)

Waarom? – Een van de disks in het SAN is defect. (Derde waarom)

Waarom? – De disk had eerder vervangen moeten worden. (Vierde waarom)

Waarom? – Het SAN is niet onderhouden volgens het aanbevolen onderhoudsschema. (Vijfde reden, een oorzaak)

Het is oké om meer dan het voorgeschreven aantal stappen te nemen om tot het antwoord te komen. Als je zeven “waaromvragen” nodig hebt om de oorzaak te achterhalen, gebruik er dan zeven. Het gaat erom dat je een ​​logische, stapsgewijze benadering te volgt. Troubleshooters moeten hun aannames opzij te zetten en de mogelijke oorzaken zorgvuldig op sporen totdat ze de oorzaak hebben gevonden.

Probleem 4. Niet delen van de kennis

Dit probleem sluit rechtstreeks aan op over de neiging van problemmanagers om de probleemoplossing direct uit te voeren.

Als iets nieuws leert of een moeilijk probleem oplost, kun je het resultaat onthouden en later weer toepassen.

In een team is je eigen geheugen echter de minst gunstige plek om je kennis in op te slaan. Het zou op zijn minst niet de enige plaats moeten zijn. Dan is een kennisdatabase van belang. Het is een centrale plek om artikelen die kunnen helpen bij het oplossen van problemen in op te slaan.

Op kennis gebaseerde support is niet iets dat je doet naast het oplossen van problemen. Het is eigenlijk de manier waarop je problemen oplost. Het schrijven of bijwerken van kennisbankartikelen is dan geen zware stap. Het is de meest cruciale stap om de gevolgen van toekomstige te voorkomen.

Problem Management praktijk

Problem Management is gebaseerd op ervaring. Dit betekent dat je niet vanaf het begin de perfecte servicedesk hebt. Hou daarbij de volgende uitgangspunten in het oog:

• Problem Management is niet solitair, beschouw het als de som der delen.
• Heb oog voor het voorkomen van problemen, niet alleen het oplossen van problemen.
• bouwt een sterke, duurzame servicedesk, met behulp van een kennisdatabase.

Discussieer mee op LinkedIn.