nld

Meten van Problem Management kwaliteit in een ITIL omgeving, deel 1

Door Berrie Schuurhuis, Kepner-Tregoe

Een nadere blik op hoe probleemmanagers prestaties meten

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 wanneer de verwachtingen over de stappen die moeten worden ondernomen om problemen die aandacht behoeven op te lossen, zeer duidelijk worden gesteld.

Het lezen van probleemtickets 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. 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 te meten rond de problemen, 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 de probleemomschrijving, evenals individuele voortgangsupdates en de oplossingsbeschrijvingen.

Het patroon was te zien in de meeste probleemtickets. In de samenvatting werd duidelijk aangegeven om welke toepassing 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 op zichzelf staand geval lijkt, geeft het het patroon weer dat werd waargenomen in het team dat de beoordeling uitvoerde. Na andere ervaringen te hebben doorgenomen, werd het volgende beeld geschetst van de waarnemingen

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?
  • Welke mate van 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.

Leer in onze volgende blog waar "magie" echt om draait. Het vinden van stabiliteit na terugkerende problemen en beseffen dat er geen gemeenschappelijke manier is om een enkel probleem aan te pakken, zullen precies onthullen hoe Problem Management "magie" wordt uitgevoerd.

 

Blog afbeelding 1
Meten van Problem Management kwaliteit in een ITIL omgeving, deel 2
Blog afbeelding 1
Meten van Problem Management kwaliteit in een ITIL omgeving, deel 3
Blog afbeelding 1
Meten van Problem Management kwaliteit in een ITIL omgeving, deel 4
Blog afbeelding 1
Wat bindt ITSM en ITIL® aan Agile en DevOps?

Wij zijn experts in:

Neem contact met ons op

Voor vragen, details, of offertes!