Praktische tips voor het oplossen van problemen

Wat is een probleem? Een discrepantie tussen wat is en wat zou moeten zijn, waarbij de oplossing bekend staat als 'de opgeloste staat'.

Het primaire doel van probleemmanagement is het identificeren en managen van de onderliggende oorzaak van incidenten en ondertussen het minimaliseren van de verstoring voor klanten. Om de best mogelijke resultaten te behalen, heeft u een gestructureerd 'framework' nodig voor probleemanalyse en verwachtingsmanagement. Niet alle problemen worden veroorzaakt, niet alle oorzaken kunnen worden gecorrigeerd. Focus direct op de kern van de zaak - het bereiken van de hoofdoorzaak met als doel het probleem permanent op te lossen. Wees duidelijk over de eindresultaten en de methodes om deze te bereiken, dat is de essentie van probleemoplossing.

Analyse van het probleem

Wees niet bang om het communicatieproces te 'vertragen', praat met klanten in hun bedrijfstaal, probeer dit niet te verwarren met technisch jargon. Verwacht niet dat de klant (of supportmedewerker) een 'expert' in IT is. Vergeet niet dat de 'klant' een expert is op hun vakgebied. Zorg ervoor dat u hun probleem 'begrijpt'; vraag opnieuw als u iets, wat ze zeggen, niet begrijpt. Geef het 'probleem' altijd opnieuw aan ter verduidelijking om ervoor te zorgen dat u volledig begrijpt wat ze zeggen. Doe het meer dan eens als u twijfelt.

Heeft u, voordat u te ver in het proces verstrikt raakt,tenminste vijf keer gevraagd naar het "Waarom?"*.

Vraag "Waarom" een probleem zich voordoet en vraag dan "Waarom" nog eens vier keer, bijvoorbeeld:

1. Waarom is de machine gestopt? - Een zekering blies door overbelasting
2. Waarom was er sprake van overbelasting? -Er was niet genoeg smering voor de lagers
3. Waarom was er niet genoeg smering? -De pomp pompt niet genoeg
4. Waarom werd er geen smeermiddel gepompt? De pomp-as trilde als gevolg van slijtage
5. Waarom was er slijtage? -Er was geen filter, waardoor er spanen van materiaal in de pomp terechtkwamen.

De installatie van een filter lost het bovenstaande probleem op.
_{*Uit "Wat een geweldig idee" van Chic Thompson}

Dit kan de oorzaak van het probleem achterhalen. Als dat niet het geval is, moet u misschien verder graven met behulp van het 12-stappen-probleemoplossingsproces van Marval.

Houd altijd rekening met de impact op het bedrijf, de afdeling en de perceptie van de klant als een probleem niet wordt opgelost.

Niet alle problemen kunnen op dezelfde manier worden behandeld. Je hebt een business impact, urgentie en prioritaire opdrachtaanpak nodig die ervoor zorgt dat bedrijfskritische problemen als eerste worden aangepakt. Overweeg om een proces en procedure voor grote incidenten in te voeren om ervoor te zorgen dat er een gestructureerde aanpak wordt gevolgd wanneer u onder druk staat.

Marval's 12 Stappen Probleemoplossingsproces

Deze 12 stappen kunnen van toepassing zijn op elk type probleem (hardware, software, netwerk, applicatie etc.). Identificeer en elimineer snel irrelevante vragen in elke stap, vat elke vraagreactie samen. Schrijf een aparte lijst om de in- en output te identificeren die mogelijk input/bewijs/bevestigingen uit andere bronnen vereisen. Ga niet off-track, focus op het lezen en beantwoorden van de specifieke vraag. Houd u aan het tijdschema en zorg ervoor dat u elke stap opnieuw bekijkt en rapporteert.

Stap 1 - Definieer het probleem, bijv.

• Wat is er misgegaan? Wat werkt niet goed? Wat is dat?
• Wat zou er moeten gebeuren dat niet gebeurd? Wat moet er niet gebeuren dat nu wel gebeurd?
• Wat zijn de specifieke symptomen die waargenomen worden? Wat en wie wordt er getroffen?
• Waar gebeurt het? Is het slechts op één plaats of op meerdere plaatsen?
• Is er een patroon (dezelfde tijd, dezelfde locatie, dezelfde mensen etc.)?
• Wat houdt het in? Wat sluit het uit?
• Hoe dringend is het? Wanneer moet het gerepareerd zijn? Kan het wachten?
• Zal het uit zichzelf weggaan?
• Wat gebeurt er als we niets doen?
• Wat is het gevolg als we het verkeerde doen?
• Wat is de financiële/zakelijke/politieke impact?

Stap 2 - Specificeer de opgeloste staat, bijv.

• Wat zou er moeten gebeuren dat niet gebeurd?
• Wat proberen we te bereiken?
• Wat willen we bewaren of behouden?
• Wat proberen we te elimineren of te vermijden?
• Wat is de geïdentificeerde opgeloste staat?
• Wie zegt wat de "opgeloste staat" of "zou moeten zijn" is? Hoe weten we dat het probleem is opgelost?

Stap 3 - Bouwen aan consensus en ondersteuning met een gedefinieerd communicatieplan, bijv.

• Wie moet weten wat er gebeurt? Wanneer? Hoe vaak?
• Wie moet erbij betrokken worden? Wanneer? Hoe?
• Wie kan onze probleemstelling ondersteunen of tegenwerken? Waarom?
• Wie zou onze visie op de opgeloste staat kunnen ondersteunen of tegenwerken? Waarom?
• Wiens steun hebben we nodig om dit 'ding' te laten werken?
• Wie moet zich ertoe zetten om iets te doen om dit te laten slagen?

Stap 4 - Het probleem analyseren, bijv.

• Denken we te weten wat het probleem zou kunnen zijn? Identificeer de meest waarschijnlijke oorzaak
• Hebben we vastgesteld wat de gevolgen zijn? Spreken we met de juiste mensen en stellen we de juiste vragen?
• Moeten we naar oorzaken zoeken? Waren de zaken eerder in orde?
• Is het probleem plotseling opgedoken of heeft het zich in de loop der tijd ontwikkeld?
• Wanneer is het precies misgegaan? Kunnen we de aandoening reproduceren?
• Zijn er externe gebeurtenissen die kunnen bijdragen aan het probleem (bijv. telecom, stroom, ISP)?
• Is er de laatste tijd iets veranderd?
• Spreken we met de juiste mensen, stellen we de juiste vragen?

Stap 5 - Ontwerp een oplossing, bijvoorbeeld

• Beoordeel en bereik overeenstemming over het risiconiveau, de betrokken Diensten, Configuratie Items /Zakelijke gebruikers
• Definieer de vereiste goedkeuringen (met inbegrip van de bevoegdheid tot back-out)
• Beoordeel de mogelijke downtime en de geschatte werklast
• Overeenstemming bereiken over de reikwijdte van het testplan
• Wat voor soort of klasse van probleem is het (hardware, applicatie, data, communicatie)?
• Wat noemen we het? Hoe zullen we het classificeren/documenteren?
• Hebben we te maken met een mensenkwestie?
• Hebben we te maken met een vorm van productie of 'state-change' proces?
• Welke van deze factoren zijn de drijvende kracht achter het probleem (bv. een server, software, netwerkapparatuur)?
• Moeten we het gedrag van mensen, hun procedures, het systeem dat ze gebruiken, of al het bovenstaande veranderen?

Stap 6 - Identificeer de middelen van verandering, bijv.

• Overeenstemming bereiken over de reikwijdte van eventuele verzoeken tot wijziging van een release die moeten worden opgenomen
• Identificeer elke toename van de benodigde middelen (bijv. hardware, schijfruimte, toegangsrechten, CPU-grootte, netwerkbandbreedte)
• Een "workaround" of "quick fix" implementeren?
• Training voor personen?
• Proces herontwerp?
• Een procedure- of methodewijziging?
• Een configuratie, hardware- of softwarewijziging?
• Documentatiewijziging?
• Wijzigingen in personeel/leverancier?
• Toewijzing van middelen?

Stap 7 - Een koers uitstippelen, bijv.

• Bepaal de geplande datum voor implementatie van de oplossing
• Identificeer welke medewerkers en middelen nodig zijn
• Akkoord over de reikwijdte van het communicatieplan
• Hoe beslissen we? Hoe lang moeten we beslissen?
• Wat zijn onze mogelijkheden?
• Wat zijn de risico's?
• Wie moeten we op de hoogte blijven?
• Wat zijn de kosten? Wat zijn de voordelen?
• Wat zijn de neveneffecten?

Stap 8 - Werk om beperkingen en kaders heen, bijvoorbeeld

• Identificeer wie er betrokken moet worden en wanneer
• Review verandering en release forward schema voor mogelijke conflicten
• Wat zijn onze beperkingen en kaders (bijv. middelen, tijd, goedkeuring, autoriteit, toegang, geld, vaardigheden)?
• Kunnen we eventuele beperkingen en kaders beïnvloeden?
• Wat zijn de dingen die we moeten doen (b.v. het verwijderen van een machine, het maken van een back-up van gegevens)?
• Wat zijn de dingen die we niet kunnen doen? Wie zegt er? Zijn ze echt of denkbeeldig?
• Wat gaan we ervan uit? Wat zien we over het hoofd?
• Wat moet er wijken? Mensen, tijd, geld?

Stap 9 - Bereid plannen en schema's voor, bijv.

• Test-, back-out-, communicatie- en continuïteitsplannen maken
• Wat kan er misgaan?
• Hoe houden we de voortgang in de gaten?
• Hoe lang duurt de implementatie ervan?
• Wanneer is het veilig om de oplossing te implementeren?
• Hebben we de zakelijke impact en urgentie bevestigd?
• Wie is eigenaar/doet wat wanneer?
• Hebben we de vaardigheden/controles om succes te bevestigen?
• Hoe weten we of het goed gaat of niet?
• Hoe en wanneer houden we mensen op de hoogte?

Stap 10 - Onderneem actie

• Doe het!

Stap 11 - Beoordeel de effecten en gevolgen, bijv.

• Monitor de effecten van acties
• Bevestig succes of mislukking van acties. Werkte het volgens plan?
• Getroffen klanten op de hoogte brengen
• Informeer de service desk om de resultaten van de actie te documenteren en vast te leggen
• Wat hebben we uitgegeven? Wat hebben we gewonnen (bijv. tijd, geld, klant/zakelijk vertrouwen)?
• Was het de moeite waard?
• Zijn er nieuwe incidenten ontstaan door de geïmplementeerde oplossing? Wegen deze op tov de voordelen van het oplossen van de oorspronkelijke probleem?
• Zijn we beter af of slechter af dan voorheen?
• Wat hebben we geleerd?
• Hoe was de perceptie van onze prestaties bij de klant?

Stap 12 - Aanpassen voor toekomstige actie, bijv.

• Wat hebben we geleerd? Wat werkte wel en niet? Waarom?
• Wat had beter gekund?
• Waren onze continuïteits- en communicatieplannen effectief?
• Welke operationele informatie moet worden herzien/gecreëerd (bijv. processen, procedures, plannen, checklists, competentiematrix, kennisbanken, bekende fouten)?
• Welke training moet wanneer voor wie/wanneer worden gevolgd?

Bekende barrières voor effectieve besluitvorming die ons ervan weerhouden om effectieve probleemanalyse en probleemoplossing te implementeren en uit te voeren, zijn onder andere:

• Besluiteloosheid - Vermijd beslissingen om te ontsnappen aan aspecten van risico's, politieke druk, angst en bezorgdheid
• Negeren - Weigeren om de kwestie onder ogen te zien; verantwoordelijkheid nemen, obsessief verzamelen van eindeloze feiten
• Overreageren -Een situatie uit de hand laten lopen; emoties de controle laten nemen
• Vacilleren - beslissingen terugdraaien; zich halfslachtig committeren aan een actiekoers
• Halfslachtige maatregelen - Beslissingen nemen om controverse te voorkomen, maar niet om het hele probleem aan te pakken
• Het maken van aannames - Beslissingen nemen op basis van gehoorsignalen en aannames in plaats van feiten

Met een goed gedefinieerde probleemanalyse en probleemoplossend proces realiseert u belangrijke bedrijfsvoordelen: repetitieve problemen permanent opgelost; vermindering van het aantal incidenten en problemen; geminimaliseerde bedrijfsimpact; gedeelde kennis; verminderde oplostijd; verbeterde productiviteit en meer vertrouwen in IT-diensten.

Probeer naar meerdere oplossingen te zoeken. Vaak is er meer dan één acceptabele oplossing. Wacht met oordelen en kritiek in de fase van het verzamelen van ideeën. Probeer niet op zoek te gaan naar al te complexe oplossingen wanneer er een veel eenvoudiger oplossing beschikbaar is en zich aandient - kies altijd het beste alternatief voor het probleem in kwestie.

"Zorg ervoor dat u het probleem behandelt en niet het symptoom".