Het onderstaande artikel heb ik 8 jaar geleden geschreven. Het is frappant om te constateren dat het nog steeds actueel is.

Ergens moet het ontstaan zijn; wij ICT-ers werden tovenaars en de rest bleef eenvoudig. Waar en wanneer het precies gebeurd is weet ik niet, maar wat ik wèl weet is dat we het hardnekkig in stand proberen te houden. ICT en alles wat er mee samenhangt, is ingewikkeld en dat moet je zo houden!

Een tijdje geleden ben ik naar de ITSMF academy geweest. De introductie van Itil V3, ASL, Bisl, ISO 20.000 etc. De afsluitende spreker was Paul Wilkinson, o.a. auteur van de boekjes “IT Service Management from hell” en “Not the IT Infrastructure Library”  De plaatjes in deze presentatie komen uit zijn presentaties en boeken. Was ik al een fan van hem om zijn cynische benadering van wat er aan de hand is in IT beheer land in zijn boekjes, deze presentatie deed er weer een flinke schep bovenop! Paul gaf aan dat we in al die jaren dat we IT beheer dachten te verbeteren met modellen en technieken, daadwerkelijk niets veranderd hebben aan dàt wat wèl belangrijk is, namelijk, dat wat hij noemt: “The ABC of ICT”. ABC staat voor Attitude, Behaviour en Culture. Ik hoop dat de onderstaande voorbeelden uit mijn werkomgevingen er een bijdrage aan leveren dat we met zijn allen weer met beide benen op de aarde terug komen, en beseffen dat wij op velerlei fronten niet vóór maar achter lopen. Of zoals mijn oma altijd zei: “Doe maar gewoon, dan doej al gek genog”.

Attitude

Een paar weken geleden ben ik weer begonnen aan een nieuwe klus. Ik was geïntroduceerd als iemand die alles weet over het inrichten van beheer en de verwachtingen waren dan ook hooggespannen. Ik mag een presentatieservice voor service niveau rapportages inrichten, een taak die ik overneem van een andere projectmedewerker. De dame in kwestie wil graag ook wat van mij leren over het inrichten van beheer en vraagt mij wat ik haar zoal kan bijbrengen, per slot van rekening ben ik ingehuurd als magisch tovenaar! Er ontwikkelt zich een leuk gesprek waarin zij aangeeft uit de bibliotheekwereld te komen ze heeft de 4 jarig HBO opleiding Informatiedienstverlening en -management gevolgd om vervolgens in een bibliotheek te gaan werken.

Als we het over het project hebben dan heeft zij het over “dozen”, ik over servers, zij over “takketooltjes”, ik over monitoringapplicaties. De teleurstelling is aan haar gezicht af te lezen als we tot de conclusie komen dat zij vanuit haar benadering veel meer ervaring heeft met het ontsluiten van informatie dan ik als “ijzerboer” en dat ik dus van haar kan leren in plaats van andersom! Toch heeft zij moeite om haar visie onder de aandacht te krijgen bij de medewerkers van het bedrijf. Blijkbaar heeft onze attitude het er moeilijker mee om iets aan te nemen van een ervaren bibliothecaresse dan van een omhooggevallen operator die technische ICT terminologie gebruikt.

Behaviour

In één van mijn functies als interim manager mocht ik een groep mensen aansturen die de infrastructuur (servers en storage) beheren van het bedrijf. We zijn als groep ook verantwoordelijk voor de doorbelasting van deze dienst en hebben veel last van de klant die ons continu vertelt dat hij het elders (bij 3^e partijen) veel goedkoper en sneller kan krijgen dan bij ons! Als de klant de deur uit is vertellen we elkaar dat hij het toch allemaal niet snapt en dat wij ons het snot voor de ogen werken en vervolgens stank voor dank krijgen! Als we nog eens nuchter nadenken komen we tot de conclusie dat het eigenlijk onmogelijk is dat een 3^e partij goedkoper aan kan bieden dan wij als interne partij. Er moet dus iets mis zijn in de matching van de dienst. We besluiten de klant uit te nodigen met zijn offerte van de 3^e partij en leggen ons eigen voorstel er naast. Het zijn appels en peren, niet vergelijkbaar. Wij doen veel meer en andere dingen dan de 3^e partij! Het probleem is dat wij ook dingen doen waar de klant geen behoefte aan heeft. We geven openheid van zaken inzake de financiën op onze afdeling. Door deze openheid is de klant bereid met ons mee te denken, en stellen we samen een offerte op, die goedkoper voor de klant is, en ons minder inspanning kost! Gestimuleerd door de goede resultaten besluiten we een pilot met de klant aan te gaan inzake doorbelasting van beheer op servers. De prijs die betaald moet worden voor beheer is in grote mate afhankelijk van het aantal gebruikers. Dat lijkt op zich logisch, maar wij beheren systemen met 300+ gebruikers waar we nooit een vinger naar uit hoeven steken en ontwikkelsystemen met 3 ontwikkelaars waar we praktisch elke dag wel wat aan moeten doen. We bedenken een systeem waarbij de complexiteit van de server een parameter in de doorbelasting wordt. De prijs per gebruiker is dan aanzienlijk lager als je een eenvoudig systeem hebt dan de prijs voor een complex systeem. De bepaling van de complexiteit van het systeem doen we door de aantallen wijzigingen en incidenten op jaarbasis te tellen. Vanaf nu betaalt de vervuiler! Waar kennen we dat ook al weer van? Maar de vervuiler kan ook invloed uitoefenen op zijn prijs. Door de klant serieus te nemen (behaviour) hebben we er een supporter bij gekregen in plaats van een klager.

Culture

Één van de belangrijkste redenen waarom een flink aantal mensen jeuk krijgen bij de term ITIL is omdat het te rigide is ingevoerd. Mensen worden niet meer gestimuleerd om zelf na te denken over het waarom van deze processen. Toen ik manager van een servicedesk was ben ik eerst met de medewerkers gaan praten over hun werkzaamheden. Ik vroeg ze naar de gemiddelde tijd van een call. De betreffende medewerker vertelde me dat hij met een klant ongeveer 5 minuten aan de lijn zat en vervolgens 10 minuten bezig was in het systeem met de afhandeling. Ik vroeg hem vervolgens waarom hij de incidenten registreerde in een systeem? Alsof hij water zag branden! Een servicedeskmanager die vraagt waarom je incidenten registreert? Hij legde me geduldig uit dat dit was om een soort van kennisdatabase op te bouwen zodat, als een collega toevallig hetzelfde incident kreeg, hij dan snel een antwoord kon opzoeken. Ik vroeg hem waarom hij dit zoeken in de database niet aan mij vermeld had in de procedure die hij mij beschreven had. “Nou dat is nogal logisch, ik kan niets vinden in die database. De één registreert een incident op gebruiker, de ander op de pc, de derde op de afdeling en de vierde op applicatie.” Toen ik de week erop in het managementteam kwam vertellen dat ik het probleem met de wachtrijen had opgelost stond iedereen te popelen om mijn oplossing te horen. Ik vertelde ze dat we vanaf morgen zouden stoppen met het registreren van incidenten. In plaats van 1 klant per 15 minuten kunnen we nu 3 klanten per 15 minuten helpen! Uiteraard zijn we niet gestopt met het registreren van incidenten, maar we zijn toen wel in de registratieprocedure gedoken om te kijken hoe we moeten registreren zodat je wèl wat kunt vinden in de kennisdatabase en het incidentmanagementproces daadwerkelijk een toegevoegde waarde heeft in plaats van een beperking van de service. We hebben een cultuur gekweekt waarin we niet meer nadenken over de onderliggende redenen waarom we dingen doen en genomen besluiten niet meer onderwerpen aan een onderzoek of ze nog steeds valide zijn.

We leven momenteel in een afrekencultuur. Je moet als medewerker te allen tijde zorgen, dat je in geval van problemen, de documenten boven water kunt toveren, waaruit blijkt dat jij er allemaal niets aan kon doen, maar dat een ander de schuld moet hebben. En het werkt! Recentelijk zat ik bij een bedrijf die een boeteclausule had opgenomen in de SLA waarbij de leverancier voor €10.000 aansprakelijk gesteld kon worden indien bleek dat door een foutief uitgevoerde change een prio 1 incident was ontstaan. Bij het aankoppelen van extra storage ontstaat een prio 1 incident. Het incident wordt verholpen en we gaan op zoek naar de oorzaak. De leverancier zwijgt in alle talen want “dat kon wel eens geld gaan kosten!”. Naast het feit dat we nu een verstoring hebben gehad kunnen we ditzelfde probleem dus morgen weer krijgen omdat we niet kunnen bepalen waar het probleem ontstaan is!

Wie werkt maakt fouten, dat is een gegeven. Fouten maken is synoniem geworden voor falen, en dat willen, en mogen we niet van ons bedrijf. Diegene die faalt krijgt een slechte beoordeling en een dito financiële waardering. Als je de dingen blijft doen zoals je ze altijd doet, zul je ook altijd hetzelfde resultaat krijgen. Om vooruit te komen zullen we dingen anders moeten doen, en dingen anders doen houd dus risico’s in. Het rottige van risico’s nemen is dat het fout af kan lopen, en dat was nou nèt wat we niet wilden! Zolang we de cultuur handhaven waarin fouten genadeloos afgestraft worden zullen we nooit de vooruitgang boeken waar we zo naarstig naar op zoek zijn. Ik wil dan ook een vurig pleidooi houden om de cultuur te creëren waarin fouten gemaakt mogen (moeten?) worden, om vervolgens te genieten van de creativiteit en ondernemingszin van medewerkers. Vraag me niet precies hoe het werkt, het heeft iets te maken met mensen serieus nemen, maar dàt het werkt weet ik zeker, dat heb ik namelijk met mijn eigen ogen gezien.