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.

Buying the best car….

This is a story about a friend and I. My friend is single, technical engineer, living and working in Amsterdam. I am married and we have three kids to take care of. Together with my wife we run a Brasilian webshop and im- and export to and from Brasil and some European countries.

Some years ago this friend called me to ask my advice. He wanted to buy a new car and wanted to know my opinion about it. At that time I drove an Toyota Avensis Verso and was very content with it. A great car, already 10 years old, it drove very well and in yearly costs for service very cheap. It always started and never left me alone. I was a big fan for Toyota-cars because of all these advantages an it was the best choice I ever made. So I told him about my best choice and we hung up.

TOYOTAAvensisVerso-648_7My friend went to the local garage and bought himselfe the same car. And indeed on his way back to his home, in the center of Amsterdam, he felt comfortable and at ease in his new car. Once he got home he was searching for a parking space and noticed that that was not easy. Some available places were way to small and driving around in the little streets the car was anoying him more and more. At a certain point he found a suitable place, but getting the car into the right position he had to drive back and forward a couple of times to avoid collisions to the neigbouring cars. Every time he drove backwards and looked over his shoulder or in the mirror he saw the extra 5 chairs in the back of the car. And the more often he looked the more he realized he did not need all these space. He was singly, he onle needed laptop for his work and sometimes a view prints roled as a tube.

MINI_Cooper_SD_JCW_Package-5After a while he became dissapointed on his choice and went back to the garage where he bought his car.The garage accepted the car back and sold him a new car, more suitable to his situation. He came back driving a Mini Cooper. He parked his new car in a second, had loads of space for his laptop and roles of paper. It was easy to handle in the narrow streets. “This was the absolute best choice a man could made for a car!”, he told me on the telephone. He continued his enthousiastic story about the best car a man could have and convinced me to swao my car as well. He garanteed me that his Mini Cooper would beat my Toyota Avensis Verso.

So I did and went to our garage and swapped my car for a Mini Cooper. Happy and proud I drove home. And indeed the car drove splendid, easy to handle and very nice to be seen with it, as well. I promissed my kids to take them with the car soon as they were just as enthousiastic as I was. The next day I needed to go to Germany for business and decided to take them with me. That morning I placed the three kids in the back seat, but it didn’t fit. Well not that easily anyway! When I arrived at my appointment my supplier gave me some boxes with try-outs to sell in The Netherlands. I opened theback of my car, but there was not enough space. I closed the deal, but went home without the trials. At home I immidiatiely swapped cars again. I went back to my old car and decided not to listen to what is supposed to be “the best” for someone else….?????????????????????????????????????????????????????????

In the world of IT we are used to talk about “Best Practices”, and yes…. in this example-story there should be a consultant giving advice not to swap cars because they do not fit the situation. But that is not the point. The point is: “What is BEST for one, can be the WORSE for someone else”. Calling a practice “Best Practice” gives false assumptions on the practice and puts a customer in a difficult situation. Because when the offered “best practice” does not seem to fit, we make him say “I do not want the BEST”!

Think about it……. Forget about BEST PRACTICES, and search for the BEST that fits the customer!!

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.

Servicedesk als startfunctie

In 2009 plaatste ik een paar stellingen op diverse fora (waaronder die van de de Computable en het ITSMF) over de rol van de servicedesk in een organisatie. De stellingen gingen over de rol van deze afdeling en over de kwaliteiten van de medewerker.


De stellingen werden in rap tempo trending topic op de diverse sites. Kennelijk een onderwerp wat er toe doet, wat leeft! Niet lang hierna werd ik benaderd door het ITSMF om hier toch vooral een artikel over te schrijven. Het werd mijn eerste artikel en valt te lezen onder de volgende thumbnail hiernaast.

Inmiddels zijn we ruim 5 jaar verder. Er is veel veranderd in de IT-wereld. Cloud is booming, privacy is hot en IT is nog meer dan toen van wezenlijk belang voor de organisatie. Ondanks deze verschuivingen is er op het gebied van de Servicedesk niet veel veranderd. Het onderzoek waar ik naar refereer is helaas nooit van de grond af gekomen. Wellicht zegt dit genoeg, maar waarom dan toch zo’n hot item op de diverse fora? Dat spreekt elkaar toch tegen?

“Maar hoe moeten we vanuit ons vakgebied de betrokken partijen overtuigen van het nut van de ommezwaai? En waarom dan wel?”

Met deze vragen sluit ik het artikel verder af. En hier wil ik de draad dan ook weer oppakken. Eerder in het artikel noem ik de 2 stellingen welke ik plaatste:

  • Stelling 1: Een goede servicedesk kan de fouten van de ict-organisatie goedmaken door goed met de klant te communiceren, en helaas geldt ook het omgekeerde. Al loopt de ict-organisatie nog zo goed, als de servicedesk niet goed communiceert, is de klant toch ontevreden.
  • Stelling 2: Is een goede servicedesker een ict-er met feeling voor communicatie (de Technicus) of iemand die goed communiceert en feeling heeft voor ict (de Communicator)?

In de tweede stelling breng ik twee profielen naar voren, namelijk de “Technicus” en de “Communicator“. In deze stelling zit mijns inziens ook gelijk een mogelijke oplossing van het probleem. Nog steeds zie ik namelijk in de praktijk dat de Servicedeskfuncties opgevuld worden door startende IT-ers, schoolverlatende MBO-ers. En in alle oude en recente sollicitatiegesprekken welke ik ondertussen binnen meerdere organisatie heb mogen voeren ligt hier mijn focus of ik de medewerker aan wil nemen of juist niet. Ik kijk niet (of nauwelijks) naar de technische skills die een sollicitant bevat, die geloof ik wel. Ik kijk hoe iemand zich houdt in het gesprek, hoe reageert iemand op moeilijke vragen, hoe komt iemand over. Dit zijn voor mij de aandachtspunten. Veel van deze aandachtspunten zijn niet te leren, echter enkele facetten ervan wel. Als ik op juist die facetten doorvraag, of in gesprek ga met MBO-instanties in den landen, blijkt daar al een omissie te zitten. Conflicthantering, communicatietechnieken zijn geen standaard vakken op het MBO-ICT. Wel de standaard basisvaardigheden voor ICT-kennis komen (ruimschoots) aan bod.

Hier begint de mismatch mogelijk al, en dit roept om een verandering. Het kan toch niet zo zijn dat leerlingen de school verlaten en niet matchen op de functies die ze als eerste aangeboden krijgen? Daarnaast speelt natuurlijk nog de wens van de leerling een grote rol. Willen de MBO-leerlingen wel op dergelijk functies terecht komen? Ambieren ze deze carrierestap wel? Is het een noodzakelijk kwaad om te beginnen waar ze beginnen? En is dit mede oorzaak van het imago-probleem wat er veelal is met betrekking tot de servicedesk? Zijn er alternatieven beschikbaar of te bedenken die antwoord geven aan deze dilemma’s?

Immers staat als een paal boven water dat de Servicedesk een (zeer grote!) rol speelt in de klanttevredenheid.