Category Archives: ITIL

De olie in je auto….

Posted on by

Een paar jaar geleden schreef ik op Facebook over slecht nieuws: Mijn auto was kapot, om precies te zijn de motor (krukas), hij bleek financieel total loss te zijn. Oorzaak: Door te weinig olie, liep deze in de soep. Onherstelbaar zo bleek. Het waarschuwingslampje ging echter pas branden toen het leed al geschied was. Erg zuur en met een slechte timing.

Een motor wordt vaak als metafoor gebruikt voor verschillende dingen in het leven. Ook daar is de olie wel eens op, of smeert deze en en ander even minder goed. Ook hier gaat het waarschuwingslampje soms niet op tijd branden en is ook dan het leed vaak ook al geschied. De olie levert eigenlijk niets (concreets) op, het geeft geen extra boost aan je auto of zoiets. Maar de olie is juist net datgene (of beter DIEgene) die jouw motor (soepel) draaiende kan houden. Pas op momenten dat zulke momenten zich voordoen realiseer je je de kracht van die olie, en ben je blij dat je jezelf omringd hebt door goede olie.

Binnen bedrijven wordt die olie vertegenwoordigd door procesmanagers. Een procesmanager heeft geen concreet eindproduct. Hij fungeert als de olie in de organisatie. Hij zorgt ervoor dat de hele keten de neuzen dezelfde kan op hebben. Hij zorgt ervoor dat mensen met de juiste prioriteit en aandacht het werk kunnen verzetten. Of het nu gaan om de Incident- of de Changemanager, of een andere procesmanager, dat maakt eigenlijk geen verschil.

Door het afwezig zijn van een concreet resultaat worden deze functies vaak als eerste aan de kant geschoven in tijden van bijvoorbeeld bezuinigingen. Dan worden deze functies omgezet in rollen of erger nog worden ze zelfs overbodig verklaard. Als dan na verloop van tijd de motor te lang te droog heeft gedraaid, de rek eruit is, draait deze in de soep. De schade die daaruit voortvloeit kan grote gevolgen hebben voor de organisatie en/of erger…. voor haar medewerkers. De medewerkers zitten vast, zijn overwerkt, veel zaken lopen niet meer zoals het hoort. Oplossingen komen moeizaam vooruit, terwijl iedereen hard (lijk) te werken. Er lijkt geen ruimte te zijn voor verbeteringen, medewerkers werken defensief. Ze verbergen fouten, ze durven geen initiatief meer te tonen. Wat de innovatie en inspiratie lam legt. Hoe langer dit duurt, hoe meer schade ontstaat aan mens en organisatie.

Zijn deze punten voor u herkenbaar? Heeft u het controlelampje gemist? Kijk dan eens naar uw processen! Zijn deze nog actief en up 2 date? Werken ze optimaal? Zijn ze ‘geborgd’ als rol, die in de drukte weleens onder geschoven kan worden?

Ik hoor graag hoe het met u en uw organisatie gaat! 

 

Workaround! Incident of Problem Management?

Posted on by

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.