Het meten van de kwaliteit van Problem Management in een ITIL omgeving

Probleembeheer nader bekeken

Begrijpen hoe analisten en ingenieurs aan problemen werken, onderliggende oorzaken vinden en de juiste acties ondernemen, klinkt als een gemakkelijke taak. Zodra men toegang heeft tot de applicatie die gebruikt wordt voor het documenteren van ITIL Problem Management, kan de case-inhoud gelezen worden. Het enige wat nodig lijkt te zijn, is toegang tot de case management tool en enige vaardigheden om die tool te gebruiken.

Als Problem Managers echter wordt gevraagd hoe zij problemen aanpakken, komen meestal de echte procedures aan het licht die beschrijven welke stappen zij nemen bij het vinden van en werken aan problemen. Deze gedocumenteerde processen en procedures zijn zeer nuttig: de verwachtingen over de stappen die moeten worden ondernomen om problemen die aandacht behoeven, op te lossen, worden zeer duidelijk gesteld.

Het lezen van problem tickets, of het vragen aan Problem Managers hoe zij de stappen in de procedures invullen, lijkt een logische volgende stap om meer te weten te komen over hoe waarde wordt gecreëerd in Problem Management, want dit is waar echt informatie wordt verzameld, gegevens worden geanalyseerd en conclusies worden getrokken. Dus, hoe worden de prestaties van Problem Management gemeten? Veel organisaties lijken timing-gerelateerde parameters rond de problemen te meten, of het tellen van het aantal problem tickets in een bepaalde staat. Voorbeelden zijn:

• Aantal open probleemtickets (backlog) per groep applicaties, bekeken in de tijd
• Gemiddelde leeftijd van openstaande probleemtickets, vaak beschouwd in de tijd
• Gemiddelde tijd om de hoofdoorzaak te vinden in probleemtickets
• Aantal terugkerende problemen

Gezien de doelstellingen van Problem Management: oorzaken van problemen vinden en proactief maatregelen nemen om toekomstige incidenten en problemen te voorkomen, hoe goed zeggen de bovenstaande voorbeelden dan hoe succesvol een team is in het bereiken van deze doelstellingen? Vragen we om het ene en meten we iets totaal anders?

Een echte levenservaring

Ongeveer twee dagen na een evaluatie van de manier waarop Problem Management werd uitgevoerd in een wereldwijde IT-afdeling van een wereldwijd bedrijf, besloten we een pauze in te lassen om onze bevindingen te vergelijken tussen de deelnemers aan de evaluatie. Velden die in aanmerking kwamen voor inspectie waren onder andere de ticket samenvatting en probleemomschrijving, evenals individuele voortgangsupdates en de oplossingsbeschrijvingen.

Het patroon was dat in de meeste Problem tickets de samenvatting duidelijk aangaf om welke applicatie of hardware het ging en wat er mis mee was, gevolgd door enkele onderliggende gegevens in de gedetailleerde probleembeschrijving. Verdere updates gaven meestal aan hoe het probleem de procedurele stappen van Problem Management doorliep naarmate de tijd vorderde en een conclusie bereikte in de beschrijving van de oplossing.

Hoewel dit een individueel geval lijkt, geeft het het patroon weer dat werd waargenomen in het team dat de beoordeling uitvoerde. Al pratend over andere ervaringen werd het volgende beeld geschetst, dat de waarnemingen weergeeft:

Dit doet een aantal vragen rijzen over de wijze waarop conclusies werden getrokken en acties werden ondernomen of gepland:

• Welke gegevens moeten worden verzameld om daadwerkelijk een oorzaak te vinden?
• Hoe zorgen deskundigen ervoor dat zij op het juiste moment de juiste gegevens hebben verzameld?
• Hoe ziet de magie eruit? Welke ongedocumenteerde stappen zijn er genomen? Wat voor ongedocumenteerd denkwerk is er gedaan?
• Welke andere oorzaken werden overwogen?
• Hoeveel vertrouwen had het oplossende team dat de gevonden oorzaak werkelijk de "ware oorzaak" was?
• Welke neveneffecten kunnen acties om het probleem te verhelpen hebben veroorzaakt?

Antwoorden op deze vragen kunnen een goed inzicht geven in hoe waarde is gecreëerd in Problem Management voor een bepaald ticket. De antwoorden op deze vragen hebben meestal niets te maken met timing of numerieke parameters rond de Problem Management-procedures. Ze gaan over de kwaliteit van de gegevensverzameling en de kwaliteit van de denkprocessen door de betrokken personen.

Krijg controle over terugkerende problemen - Krijg stabiliteit.

Sommigen zullen beweren dat wanneer de "magie" goed wordt verricht, het bedrijf een laag aantal terugkerende problemen zal zien, wat hierboven werd aangegeven als een prestatie-indicator voor Probleembeheer. Dit is waar!

Helaas.

Wat een bedrijf krijgt door terugkerende problemen is een boodschap dat het Problem Management-proces geen goed (of niet goed genoeg) werk heeft geleverd bij het vinden van de hoofdoorzaak toen het probleem zich voor de eerste keer voordeed. Aangezien het weken of maanden kan duren voor een probleem zich opnieuw voordoet, is dit een achterblijvende en onnauwkeurige indicator voor de prestaties van Problem Management. Wat echt nodig is, is een manier om de prestaties (en dus de waarde) van Problem Management zodanig te meten dat een bedrijf kan voorspellen dat het aantal terugkerende problemen zal afnemen. Met andere woorden: wat zijn de belangrijkste prestatie-indicatoren voor Problem Management?

Maatregelen die aangeven hoe goed problemen zijn opgelost, kunnen slechts een mild effect hebben voor eenvoudige problemen (met een geringe impact), waarbij herhaling niet op prijs zou worden gesteld, maar ook niet catastrofaal zou zijn. Sommige bedrijven hebben af en toe kritieke incidenten en problemen waarbij ze balanceren op de rand van een catastrofale bedrijfsgebeurtenis die verband houdt met een of meer IT-gerelateerde gebeurtenissen, en ze nemen zich voor om die ervaring nooit meer mee te maken! Het meten van terugkerende problemen en trends is waarschijnlijk geen goed genoeg meetinstrument.

Een beste praktijk voor het doen van magie?

Als ingenieurs en analisten wordt gevraagd naar hun interne denkprocessen bij het afhandelen van probleemtickets, krijgt men veel verschillende antwoorden. Dit is totaal anders dan wanneer hetzelfde publiek gevraagd wordt hoe een specifieke applicatie of een stuk hardware te configureren. Het is tegenwoordig overduidelijk dat een gemeenschappelijke aanpak voor het configureren van een applicatie of een stuk hardware veel voordelen heeft:

• Een "beste configuratie" voor het gebruikte goed vermindert de variatie
• Een gemeenschappelijk inzicht in hoe activa waarde toevoegen aan de gehele infrastructuur helpt bij het capaciteitsbeheer
• Het vereenvoudigt de communicatie over hoe activa worden geconfigureerd of gewijzigd
• Het maakt een naadloze en hoogwaardige overdracht en onderhoud mogelijk

Gezien deze factoren is het opmerkelijk dat er vaak geen gemeenschappelijke aanpak voor probleembehandeling bestaat. Als gevolg daarvan blijft dit als magie over.

Wanneer een "best practice" voor het opsporen van onderliggende oorzaken van problemen wordt vastgesteld, biedt dat vergelijkbare voordelen als een "best practice" voor het configureren van een activum. Bovendien zou het een nieuwe taal voor probleemoplossing mogelijk maken, met terminologie waarmee kan worden gedocumenteerd hoe de "magie" eruitziet, en hoe conclusies worden getrokken.

Hoe ziet de "magie" eruit?

Er zijn vele manieren om de onderliggende oorzaak van een probleem te vinden. Sommige zijn succesvoller dan andere, en verschillende mensen (zonder standaardkader) hebben natuurlijk verschillende benaderingen. De effectiviteit van een groep troubleshooters valt ergens langs een klok-curve. Troubleshooting-experts hebben een goede reputatie en kunnen met een gerust hart alles krijgen om aan te werken. Goede presteerders zijn goed voor de meeste taken en hebben ruimte om te verbeteren, en degenen met een slechte reputatie op het gebied van troubleshooting hebben waarschijnlijk hulp nodig.

De Kepner-Tregoe (KT) methode voor Probleemanalyse werd onderzocht en gedefinieerd in de jaren 1950, en is sindsdien steeds verder verfijnd en getest. Het is gemakkelijk te beseffen dat dit vele jaren was voordat het acroniem ITIL werd uitgevonden.

Er is betoogd dat een methode die al zo lang bestaat, niet geschikt kan zijn voor de IT-industrie, omdat noch IT noch ITIL bestond toen de methode voor het eerst werd onderzocht. De KT-methode voor Probleemanalyse moet nader worden bekeken om een passender oordeel te kunnen vellen. De belangrijkste stappen in Probleemanalyse bestaan uit:

• Beschrijving van het probleem
• Lijst van mogelijke oorzaken
• Evaluatie van mogelijke oorzaken
• Het bewijzen van de ware oorzaak
• Verder denken dan de oplossing

Voor elk van deze stappen zijn er duidelijke bedoelingen en enkele sub-stappen - die aan het werk worden gezet door de formulering van vragen en de documentatie van de antwoorden om de juiste gegevens in het Problem Analysis denkproces te krijgen. Dit alles wordt gedaan zonder een specifiek product of probleem in gedachten, en het is zeer vergelijkbaar met ITIL, dat werkt voor alle soorten IT-organisaties. Probleemanalyse is een aanpak voor het vinden van de hoofdoorzaak voor veel verschillende problemen, ongeacht de industrie of technologie.

Is er een probleem?

Wel... ja! Maar er is een zeer specifieke KT-definitie van de term "probleem", die anders is, maar wel goed aansluit bij ITIL. Volgens KT moeten drie criteria kloppen, voordat we het Problem Analysis proces in gang zetten:

1. Er moet een kloof zijn tussen de werkelijke prestatie en de gewenste prestatie. Dit is wat wij een afwijking noemen (bv. machine werkt niet, terwijl hij wel zou moeten werken);
2. De oorzaak van de afwijking is onbekend (d.w.z. geen Bekende Fout);
3. Er moet een noodzaak zijn om de afwijking te kennen (b.v. om actie te kunnen ondernemen).

Het resultaat van het doorlopen van een welomschreven reeks stappen om de hoofdoorzaak te vinden is dat probleemoplossers kunnen beginnen met communiceren en documenteren wat er al gedaan is en wat er nog gedaan moet worden in het proces. Een voorbeeld van hoe verzamelde gegevens tekstueel gemodelleerd worden om de symptomen van een probleem te beschrijven staat in de afbeelding hieronder.

Bekende Magie

Wanneer de stappen voor een consistente en reproduceerbare aanpak van probleemanalyse goed begrepen zijn, wordt het meten van de kwaliteit van een gevonden hoofdoorzaak veel gemakkelijker. Als de magie van het vinden van de onderliggende oorzaak wordt begrepen, kan deze worden gedocumenteerd, gereproduceerd, vlot worden overgedragen en efficiënt worden getimed; dit zijn allemaal kenmerken van een Best Practice.

Zodra een IT-ondersteuningsorganisatie een uniforme benadering van Probleemanalyse gaat gebruiken, kan de onmiddellijke kwaliteit of waarde van individuen en teams worden gemeten. Dit is precies wat KT consultants doen bij het beoordelen van de kwaliteit van bestaande troubleshooting processen die worden uitgevoerd in een IT support omgeving. Door het doorlezen van bestaande incident en problem tickets, en door in te schatten in hoeverre de aanpak gestructureerd moet worden ten opzichte van een bekende standaard, kunnen we helpen bij het genereren van een baseline leading indicator voor de kwaliteit van troubleshooting.

Als voorbeeld: IT-medewerkers die hun Synopsis (of een gelijkwaardig veld in hun case management tool) consequent documenteren in termen van een Object met een Afwijking (waarmee de vraag wordt beantwoord: "Wat is er mis met wat?") blijken gemiddeld iets meer dan 10 procent minder tijd kwijt te zijn voordat een hoofdoorzaak is gevonden.

Het klinkt misschien allemaal zo eenvoudig dat dit niet waar kan zijn - alleen al het documenteren van het object en het defect waarvan de deskundigen de hoofdoorzaak willen vinden, bespaart iets meer dan 10 procent op de tijd tot sluiting. Wel, u zou wel eens gelijk kunnen hebben: het klinkt misschien gemakkelijk, maar dat is het niet. Om dit denkproces ingeprent en reflexief te krijgen is een gedragsverandering nodig, en in het heetst van de strijd, onder tijds- en andere druk van de business kan deze eenvoudige stap terzijde vallen als hij niet wordt geoefend en ondersteund, weg van de hoge druk problemen. De stappen voor het implementeren van een best practice voor troubleshooting zijn goed begrepen, maar het doorvoeren van de verandering vergt nog steeds aandacht, focus, goede planning en denkwerk. Gelukkig is denken gemakkelijk, maar implementatieteams kunnen afgeleid raken. De KT-denkprocessen, zoals Probleemanalyse, zijn geen wondermiddel dat garandeert dat de hoofdoorzaak wordt gevonden. Het is slechts een methode die reeds goed geïnformeerde deskundigen naar het doel leidt, en het aantal kilometers dat wordt afgelegd om de hoofdoorzaak te vinden kan variëren naargelang de kwaliteit van de gegevens (en de waarneembaarheid) die in het proces worden gebruikt.

Dit laatste is een belangrijk ingrediënt voor succes; alleen het invullen van een formulier, sjabloon of spreadsheet geeft geen goede hoofdoorzaak, omdat Probleemanalyse is gebouwd op een stevig fundament van harde logica die actief moet worden gebruikt. Het vergt nog steeds intensieve gegevensverzameling, denkwerk en controle, wat niet verschilt van het oplossen van problemen in een ongestructureerde probleemoplossingsomgeving. De grote verandering is dat de denkstappen zichtbaar worden en ze een naam krijgen, allemaal gebaseerd op een duidelijk onderliggend plan voor Probleemanalyse. Als gevolg hiervan kunnen we meten en communiceren over waar we zijn en hoe we het doen in het proces van het vinden van de onderliggende oorzaak.

In dit geval is het meten geen database query die laat zien hoeveel tijd of hoeveel tickets aan een bepaalde set van criteria voldoen. Het gaat om een beoordeling die kan worden gegeven door interne (troubleshooting) experts die de kwaliteit van de verzamelde gegevens beoordelen in de verschillende stappen van Probleemanalyse. Zo'n beoordeling wordt dan een leidende prestatie-indicator voor de kwaliteit van Probleemanalyse.

Waar gaan we nu heen?

Het lezen van een boek over vioolspelen maakt van de lezer nog geen groot violist. Op dezelfde manier zal het trainen van een organisatie in hoe beter te denken bij het oplossen van problemen de organisatie waarschijnlijk niet veranderen in een groep troubleshooters van wereldklasse. Het zal aandacht, oefening en toewijding vergen om de aanpak te verankeren in de denkwijzen die individuen hanteren, en de resultaten zullen zich uitbetalen. Investeren in het vinden van onderliggende oorzaken in Problem Management ondersteunt investeringen in technische vaardigheden en ervaring die leiden tot een personeelsbestand dat zich bewust is van en goed is toegerust voor wat er nodig is om kwalitatief goede oplossingen te vinden voor complexe problemen. Aan het begin van een Problem Management zaak zal een manager (nog steeds) nooit weten hoe lang het zal duren voordat de hoofdoorzaak is gevonden, maar er zal een duidelijke en geplande richting zijn en de aankomsttijd zal meer voorspelbaar zijn, wat het meten van kwaliteit in Problem Management mogelijk maakt.

Door Berrie Schuurhuis, Kepner-Tregoe

 

Over Kepner-Tregoe

Kepner-Tregoe is de leider in het oplossen van problemen. Al meer dan zes decennia helpt Kepner-Tregoe duizenden organisaties over de hele wereld bij het oplossen van miljoenen problemen door middel van een effectievere analyse van de onderliggende oorzaak en besluitvormingsvaardigheden. Kepner-Tregoe werkt samen met organisaties om de kosten aanzienlijk te verlagen en de operationele prestaties te verbeteren door
probleemoplossende training, technologie en adviesdiensten.