Workaround! Incident of Problem Management?

Ik heb laatst een vraag op LinkedIn Workaround!Incident of Problem Management geplaats over de positionering van de “Workaround” binnen de ITIL-processen. Volgens de theorie (bv te lezen op site van Pink) is Problem Management het proces waarbinnen deze wordt opgeleverd. Echter is het het Incident Proces dat verantwoordelijk is voor een spoedig (quick & dirty) herstel van de verstoring. Incident Management kent veelal doorlooptijden op voor het oplossen van verstoringen, waar Problem Management juist gaat voor kwaliteit van de oplossing en geen doorlooptijden erkent. Een schijnbare tegenstrijdigheid die in bovenstaande vraagstelling in de theorie kan botsen. Ik vroeg derhalve de volgende vraag:

“Als Incident Management het proces is om de storing zo spoedig mogelijk te verhelpen, waarom ligt dan de verantwoordelijkheid voor het vinden van de workaround bij Problem Management?”

Terwijl de vraag niet gesteld was uit een hulpbehoefte, maar ter discussie wilde stellen waar de theorie een mogelijke tegenstrijdigheid opwerpt, leverde deze toch interessante en mooie inkijkjes op. Na bijna 9000 views en een aantal reacties en commentaren inventariseer ik de stand van zaken. Al zou ik heel graag nog veel meer reacties willen zien.

Ondanks het beperkt aantal reacties (in verhouding met de views) lijkt het mij redelijk veilig te stellen dat niemand de verantwoordelijkheid voor het opleveren van de workaround binnen Problem Management plaatst. In mijn ogen is dit ook logisch, aangezien het proces Incident Management – tijdsgebonden – de verstoring moet verhelpen. Afhankelijk zijn van een niet tijdsgebonden proces is dan niet wenselijk.

Het spreekt, voor mij, voor zich dat de ITIL-theorie niet 1op1 doorgevoerd moet worden, en dat deze aangepast moet worden als de situatie daartoe vraagt. Toch komen bij mij een aantal vragen naar boven borrelen in dit vraagstuk:

  • Is de theorie dan zo afwijkend van wat wij doorgaans in de praktijk uitvoeren?
  • En slaat de ITIL-theorie hier dan volledig de plank mis?
  • Is het logisch dat een “Best Practice-theorie” een keuze maakt die (kennelijk) door niemand gevolgd wordt?
  • Moet de theorie dan niet aangepast worden of speelt er iets wat we nog niet weten of snappen?

Ik herken wel een grote verantwoordelijkheid t.o.v. de workaround in het proces Problem Management. Wellicht ligt daar de basis van ITIL om “Workaround” in het Problem Managementproces te plaatsen. Dit wordt duidelijk als we de stappen van de workaround gaan bekijken. Als we het in een eenvoudige tijdlijn zetten, kom ik tot het volgende plaatje:

Groen is de reguliere “Running organisation”, in het rood wordt het incident weergegeven, in paars de toegepaste workaround en vervolgens in het groen weer de definitief herstelde situatie. Om vervolgens te bekijken wat er gebeurt als er een incident plaatsvindt zoomen we in op het stukje in de rode explosie en dan zien we volgens mij het volgende gebeuren:

Zodra een incident zich voordoet, welke niet direct opgelost kan worden, wordt er in de kennisdatabase gekeken of er een bekende workaround voor handen is. Zo ja, wordt deze uiteraard toegepast. Is deze niet bekend dient, binnen de gestelde oplostijden een workaround te worden opgesteld. Zodra deze is opgesteld en toegepast zal deze worden geverifieerd worden op toepasbaarheid, haalbaarheid, betrouwbaarheid, ed. Zodra deze workaround is goed gekeurd (en waar nodig aangepast) zal deze moeten worden geborgd en gedocumenteerd in de kennisdatabase.

In bovenstaand figuur vinden de blauwe stappen plaats onder het proces Incident Management en de gele stappen onder Problem Management. Daarmee is een mogelijke achtergrond van de ITIL-keuze aan het licht gebracht.

De vragen die bij mij opborrelden zijn hiermee niet (volledig) beantwoord, dat laat ik graag aan jullie – de lezer – over en zie ik dan ook graag tegemoet.


The Problem Management trap

Recently I have been asked many times about my view on Incident- and Problemmanagement processes. Many claim these processes are a like, and should be treated in the same way andor by the same person. In the past years I also noticed that Problem Management is many times forgotten or is joined with Incident Management. Even if there was a Problem Manager, his authority was less strong than the Incident Manager. His influence and possibilities are restrained, compared to his partner from Incident Mangament. I never studied or questioned the situation, I accepted it, as it was.

Recently my thoughts are shifting….

challenges-and-risks-of-incident-management-2At first and in highover view the two processen seem alike. Both processes solve an open issue to improve/restore the service. Both processes are done by the same experts. The only obvious difference is the timely manner of them. Both are prioritized, but only the Incidents have strict deadlines on them. EG. An High-prio call has to be solved within 2 clockhours. Another difference might be that most problems are solved using (urgent)changes, but this can also be the case for incidents. So this cannot be seen as a major difference. Also it has no (or minor) impact on the process itself.

Looking deeper into both processes we notice a difference that does impact a lot on the process. Well actually not really the process but influences the way we deal with it. Incident Management is driven by the need to restore the service, where Problem Management is driven to restore the system. Allthough it does not look like a big difference, it sure is one major difference that decides the succes of Problem Management. Where Incident Management is only focussing on restoring, it does not need to comply with the best solution for the longer term. PRoblem Management on the other hand, needs to focus on the best solution for the future, and should not be distracted by restoring the service.

When a Problem Manager picks up a solved Incident with the same people who solved that incident he should be aware that these technicians could be blinded by the solution already provided. This may cause a problem solution that will look correct, but might not be the best solution for the longer term. The Problem Manager should avoid a narrow solutiontrack when picking up a problem. He has to force the team to look beyond and beside the already given (temperarily) solution to reach the best results.