Vier antipatronen die vernieuwingen in ICT-beheer belemmeren

01 juni 2016 Consultancy.nl

In elke organisatie bestaan krachten die de status quo willen handhaven. Zij zorgen voor een conservatieve houding van IT-afdelingen. Eelco Rommes van M&I/Partners spreekt over vier antipatronen rond IT-beheer die vernieuwingen in de weg staan. Met als mogelijk dramatisch effect een IT-landschap dat verandert in een archipel van geïsoleerde applicaties.

IT-beheerafdelingen staan niet bekend om hun voorliefde voor veranderingen. Vaak gaat het grootste deel van hun tijd en energie op aan het in stand houden van de bestaande situatie, wijzigingen worden dan al snel gezien als een bron van problemen. Maar omdat innovatie en IT hand in hand gaan, is stilstand geen optie. Daarom ontwikkelen organisaties manieren van werken om met deze tegenstelling om te gaan. Vaak zijn dergelijke manieren van werken terug te vinden bij andere organisaties en dan spreken we van patronen. Kiest een organisatie bijvoorbeeld voor agile ontwikkelen, dan worden patronen als daily standups of pair programming geïntroduceerd. Wie PRINCE2 omarmt, zal stuurgroepen in het leven roepen die gaan sturen op businesscases. Zulke organisatiepatronen kunnen ook vanzelf ontstaan in de dynamiek van alledag. Door herhaald gebruik slijten ze steeds dieper in en worden ze onderdeel van de organisatiecultuur (‘zo werken wij hier’).

Een patroon waarvan de effecten schadelijker zijn dan de problemen die het oplost, noemen we een antipatroon. Antipatronen maken organisaties stram en belemmeren innovatie, en ze doorbreken kan een taai en lastig proces zijn. Zulke antipatronen bieden slechts tijdelijk soelaas waarna het probleem verergerd terugkeert, of ze verplaatsen de pijn naar een ander deel van de organisatie zonder de werkelijke oorzaak weg te nemen.

Antipatronen ontstaan onder invloed van krachten die in elke organisatie een rol spelen, zoals macht, cultuur, leiderschap en beloningssystemen. Juist omdat alle betrokkenen doen wat zij in de gegeven situatie het beste vinden, kunnen antipatronen hardnekkig zijn. Vaak zijn de betrokkenen zich wel bewust dat er iets niet goed zit, maar overheerst een gevoel van machteloosheid: in mijn eentje kan ik er toch niets aan veranderen. Er zijn vier antipatronen rond IT-beheer te beschrijven die innovatie in de weg staan.

ICT-beheer

Keuzestress
Hoewel sommige organisaties meer veranderingen aankunnen dan andere, heeft zelfs de meest flexibele organisatie een beperkte verandercapaciteit. Als de grens bereikt wordt, komen veranderingen piepend en knarsend tot stilstand. Toch proberen organisaties vaak veel te veel veranderingen tegelijk door te voeren. Dat leidt tot projecten die jaren doorsudderen, geen wezenlijke resultaten bereiken en toch niet worden stopgezet; tot afdelingen waar iedereen het razend druk heeft terwijl er zelden zaken worden afgerond; of tot leidinggevenden die verzuchten dat ze het zicht kwijt zijn op wat er op hun afdeling speelt.

Het simpelweg op een rij zetten van alle lopende programma’s, projecten en initiatieven werkt ontnuchterend. Niet zelden blijkt het aantal parallelle veranderingen in de honderden te lopen, rijp en groen door elkaar. Door zo’n lijst vervolgens af te beelden op het IT-landschap, worden risico’s zichtbaar en ziet men waar veranderingen elkaar in de weg zitten of zelfs tegenwerken. Het is dan essentieel om prioriteiten te stellen: vol inzetten op een paar echt belangrijke veranderingen en al het andere stopzetten, geeft lucht.

Problemen en oplossingen isoleren
Informatiemanagers in gemeenten kennen het gezegde wel: ‘ieder wetje een pakketje’. Voor elke wetswijziging waar een gemeente mee te maken heeft – en dat zijn er nogal wat – wordt er een nieuw softwarepakket aangeschaft. Deze tactiek biedt op de korte termijn verlichting en het stelt een gemeente in staat om tenminste aan de nieuwe wet te voldoen. Maar het heeft ook een dramatisch effect op het IT-landschap, dat langzaam verandert in een archipel van geïsoleerde applicaties. Het uitwisselen van informatie tussen deze losse pakketten wordt almaar moeilijker en de integratieproblemen kosten steeds meer tijd en inspanning. Dat maakt nieuwe veranderingen riskanter en de isolatietactiek des te verleidelijker. Een stap richting een oplossing is om het bestaande landschap in kaart te brengen voor alle beslissers, IT-landschapsfotografie is daarvoor een geschikte techniek. Problemen en oplossingen kunnen vervolgens in samenhang worden beoordeeld.

De loopgraven in
IT-beheer wordt doorgaans afgerekend op de beschikbaarheid van systemen. Op de beheerafdeling van een bank bijvoorbeeld, was het hoogste doel verwoord als: ‘niet in de krant komen’. Zolang de belangrijkste klantapplicaties niet omvallen, doen we het goed, was de gedachte. Zo’n focus op het voorkomen van storingen leidt tot risicomijdend gedrag en bijna als vanzelf ontstaan dan tactieken om veranderingen te blokkeren. Elke verandering kan het evenwicht immers verstoren en we willen vooral niet in de krant komen.

Vier belemmeringen voor IT-beheer

De onderliggende overtuiging lijkt te zijn dat een onbeweeglijk landschap makkelijker kan worden beheerd, maar dat is een illusie. Het kan langzaam gaan of sneller, maar geen modern IT-systeem staat stil. Zelfs niet voor heel even. Toch graven beheerafdelingen zich in om op allerlei manieren ongewenste veranderingen te vertragen. Door een overschot aan bureaucratie te creëren, bijvoorbeeld: processen worden naar de letter gevolgd, voor elk hulpverzoek is een projectcode nodig en er worden handtekeningen geëist van steeds hogere managers. Spelen op de macht is een andere tactiek: berucht zijn de e-mails met kopieën aan een trits leidinggevenden. Als iemand persoonlijk verhaal komt halen, is vervallen in IT-jargon een beproefd middel om niet-techneuten af te bluffen.

Hoe kinderachtig zulk gedrag ook lijkt, de bedoelingen zijn doorgaans goed. Zulke tactieken komen voor als beheerders worden aangesproken op de continuïteit van het IT-landschap terwijl hun geen invloed gegund wordt op de veranderingen die dat landschap vormgeven of aantasten. IT-beheer zou als volwaardig gesprekspartner de veranderingen mede vorm moeten bepalen: samen uit, samen thuis. DevOps is een voorbeeld van een aanpak in die richting, al is die enkel gericht op organisaties die hun eigen software ontwikkelen.

Doe-het-zelf-IT
Geconfronteerd met de loopgraven van IT-beheer, ontstaat gemakkelijk de neiging om het dan maar zelf te doen, met name in organisaties met zelfstandige professionals. Een logistiek bedrijf dacht miljoenen euro’s te besparen door een verouderde boekhoudapplicatie te vervangen door een moderne variant. Kort na de start van het project kwamen gebruikers in opstand: in de loop der jaren hadden ze tientallen Excel-macro’s geschreven die van de oude applicatie afhankelijk waren. De IT-afdeling wist nergens van. Die macro’s bleken zo belangrijk te zijn voor het financiële proces dat het verstandiger bleek om die dure boekhoudapplicatie nog enkele jaren in stand te houden terwijl de macro’s een voor een werden gemigreerd. Weg miljoenenbesparing.

Ook de anekdotes over managers die op de golfbaan enthousiaste verhalen horen over een nieuw stuk software en het de volgende dag zonder overleg aanschaffen, passen in dit patroon, net als de gebruikers die op eigen houtje via Dropbox werkdocumenten uitwisselen. Doe-het-zelf-IT ontstaat uit een behoefte en domweg verbieden is geen effectieve oplossing. Wie zich netjes aan zo’n verbod houdt, voelt zich gestraft, terwijl overtreders nog dieper wegduiken in de schaduw. Het is beter om een hobbyruimte te creëren aan de rand van het IT-landschap waar gebruikers hun gang kunnen gaan en hun successen met elkaar kunnen delen. Binnen die hobbyruimte geldt een losser regime, maar de ondersteuning is er ook beperkt. Geslaagde ideeën kunnen via een formeel proces richting het normale landschap worden geleid. Mislukkingen worden gedoogd of opgeruimd. Op die manier wordt de innovatiekracht van eindgebruikers ingezet voor het belang van de hele organisatie en kan een antipatroon worden omgebogen naar een waardevolle samenwerking.

Een artikel van Eelco Rommes, adviseur bij adviesbureau M&I/Partners. Dit artikel is eerder geplaatst in AutomatiseringGids.

Nieuws