Hoe krijgen we betere it-dienstverlening? Dienstverlening die door gebruikers en opdrachtgevers als goed wordt ervaren, en die de leveranciers van die diensten bevredigend werk oplevert, zonder slapeloze nachten of stress?
Afgelopen week was ik op het Tooling Event, en als je het aan de leveranciers van beheertools vraagt, zeggen die: implementeer onze tool! Ja, zo ken ik er nog een, wij van WC-eend adviseren: WC-eend!
Wat die tools moeten doen is het ondersteunen van procesmatig werk. Maar welke processen dan? Daar zijn weer andere conferenties voor, waar een diarree van procesmodellen over je wordt uitgestort, met bijbehorende implementatiemethodieken en blikken consultants.
Het event was best een succes. De standhouders waren tevreden, er waren genoeg bezoekers, en ook die waren tevreden. Ik ga zelf volgend jaar ook weer, maar vooral om met oude en nieuwe bekenden te praten. Want het knagende gevoel bleef. Hoe gaan we nu werkelijk verbeteren? Al die tools en modellen dienen alleen maar om de onmacht te verbloemen. Het onvermogen dat we ervaren om goed samen te werken aan betere it dienstverlening.
Aan de spullen ligt het niet meer. Die zijn inmiddels goed genoeg. De tijd van de onverwachte blauwe schermen en onvoorstelbaar kreupele software ligt grotendeels achter ons.
Wat ons in de weg staat in de samenwerking zijn bijvoorbeeld diensten met een onduidelijke kwaliteit, of zelfs een onduidelijke definitie. Wat blijken we nu werkelijk te leveren? En aan wie? En als we al geen duidelijke diensten hebben, hoe kunnen we dan duidelijke eigenaren van die diensten hebben? En als er niemand eigenaar van de dienst wil zijn, wie moet er dan zorgen voor het invullen van de juiste competenties, of zelfs maar het vaststellen van wat die competenties zouden moeten zijn?
Kortom, ik ben op zoek. Op zoek naar een richting, en een betere manier om samen te werken, zodat we betere it krijgen. En als het even kan ook een betere nachtrust.
Met het stellen van de vraag ben je al halverwege de oplossing.
Zolang je de vragen blijft stellen zonder er iets aan te doen, zit je gevangen in de ‘check’-fase van de plan-do-check-act of deming-cyclus.
Door te bepalen wat je er aan kunt gaan doen, daar het belangrijkste uit te kiezen (overgaan naar de ‘act’-fase) en vervolgens te zorgen dat dat gebeurt, kun je genoemde zaken een voor een oplossen.
De problemen zijn niet het echte probleem. We zijn prima in staat om problemen op te lossen. Dat doen we immers iedere dag. Het echte probleem is dat we er niet iets aan doen.
In het streven om ict-diensten te leveren volgens contract of SLA maken we gebruik van heel wat meetinstrumenten om te bepalen of we aan onze technische verplichtingen voldoen, en daar zijn we inmiddels best goed in… Maar toch nog zoveel mensen ontevreden, de uitdaging zit in het in kaart brengen van de eigenlijke verwachtingen die niet in het door ‘inkoop’ gemaakte contract staan en het inzichtelijk maken van de percepties hierover. Ook hier zijn tools en processen voor, want je moet er wel wat voor doen.
Waarom is altijd de vraag. Genoeg bedrijven die decennia-oude systemen nog steeds gebruiken, omdat ‘het het doet’, niet te converteren is of uit kostenoogpunt.
Er wordt zoveel gereorganiseerd, gemigreerd, geconverteerd, opgeschaald, uitgebreid, iets in clouds gestopt… Waarom (daar is ie weer) is er geen enkel voorbeeld van een bedrijf dat met een [voor middellange termijn] eenmalige grote inrichting en bouwen klaar is, en hoogstens wat content/functionele updates nodig heeft?
@hypocriticus, dit lijkt me evident!
We werken volgens het Angelsaksisch Model,
“Bij een onderneming die volgens dit model bestuurd wordt heeft de directie als voornaamste taak de financiele belangen van de aandeelhouders te behartigen door een zo hoog mogelijke winst te genereren.”
En al die mistigheid rondom ICT helpt mee om dat te bereiken.
De zeer gerespecteerde spreker op IT-Dienstverlening gebied “Bart Stofberg” geeft aan dat dit een van de oorzaken is, en hij progageert het omdenken naar het Rijnlands model.
Ik heb het geluk gehad dat ik zijn boek “gestolde wijsheid” heb kunnen lezen.Ik geloof en hecht waarde aan zijn stellingen.
Kijk eens naar open source. Een learning curve, maar als je die eenmaal overwonnen hebt, vind ik het een prettige werkwijze. En ik heb weer een betere nachtrust. 😉
In toevoeging tot mijn reactie hierboven:
Uitzonderingen daargelaten natuurlijk.
Best of breed heeft voordelen in mijn ervaring. Het kaf van het koren scheiden. Alle onzinnige crap weg laten.
Bijvoorbeeld door code meer te zien als een taal zoals Frans, Nederlands, Esperanto.
Wereldwijd werk je aan hetzelfde.
Kan me nog heel goed herinneren dat ik als consultant was ingehuurd om een brainstormsessie te leiden. Onderwerp: Servicedesk SLA’s. Het bedrijf was daar al maanden nee bezig en wilde de haalbaarheid van hun plannen toetsen. Bij een eerste inventarisatie van de ideeen vlogen de committed response times, underpinning contracts en preventative escalations me om de oren.
Om het in perspectief te kunnen zien, vroeg ik welke gebruikers om die werkelijk messcherpe SLA’s hadden gevraagd, en waarom. Stilte. Gebruikers bleek niets gevraagd, er werd louter op basis van aannames gepraat. Een korte interviewronde bracht aan het licht dat de gebruikers eigenlijk wel tevreden waren met de dienstverlening. De ondersteuning tijdens de lunchpauze kon wel wat beter, en dat was in vijftien minuten gefikst door roosters naast elkaar te leggen en de afspraken op het prikbord te hangen. SLA = project werd afgeblazen. Moest de IT-manager wel gaan verzinnen wat hij met het gereserveerde budget van drie ton moest gaan doen.
Moraal: soms zoeken IT-afdelingen, met de beste bedoelingen overigens, problemen op die niet bestaan. En als de pogingen om om die problemen dan op te lossen voor complexiteit en beheerlast zorgen, heb je je eigen self-fulfilling prophecy gecreerd. De oplossing klinkt als een open deur: communicatie. Je moet niet over mensen praten, maar met mensen.