In elke organisatie bestaan krachten die de status quo willen handhaven. Zij zorgen voor een conservatieve houding van IT-afdelingen. Er zijn 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. 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.
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.
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 [Architectuur voor Leken, AG oktober 2015]. Problemen en oplossingen kunnen vervolgens in samenhang worden beoordeeld.
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.
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.
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.
Antipatronen ontmantelen
Antipatronen maken organisaties stram en belemmeren innovatie. Maar ze doorbreken kan een taai en lastig proces zijn. Hoe pak je dat aan? Stel, een beheerteam blust continu brandjes en besteedt nauwelijks tijd aan proactief beheer. Een poging om het gedrag te veranderen heeft geen blijvend effect. Geen wonder, want dat is slechts symtoombestrijding.
Stap 1 is herkennen dat er een antipatroon aanwezig is en dat dit geen probleem van het team is, maar een organisatieprobleem dat veel breder speelt.
Stap 2 is het uitvoeren van een krachtenanalyse. Ieder antipatroon wordt in stand gehouden door een samenspel van krachten en tegenkrachten, van gedrag en reacties daarop.
In kaart brengen hoe het antipatroon zichzelf in stand houdt, plaatst het gedrag van de betrokkenen in de juiste context. Brandjes blussen kost tijd en energie en gaat ten koste van aandacht voor preventie. Daarom ontstaan er steeds nieuwe branden. Bovendien werkt blussen verslavend: onder hoogspanning problemen oplossen geeft gewoon een kick. De inspanning en het effect van dergelijk werk zijn ook uiterst zichtbaar, wat schouderklopjes uitlokt van collega’s, maar ook van het management, zeker als er een ramp is afgewend. Samen kan dat leiden tot een cultuur waarin blussen als veel waardevoller wordt ervaren dan preventie.
Stap 3 is het krachtenveld doorbreken. De organisatie zal moeten afkicken: preventie moet stoer worden en brandjes blussen moet worden gezien als een noodzakelijk kwaad. Het kost tijd om zo’n verandering te bestendigen en het leidt onherroepelijk tot ontwenningsverschijnselen. Volhouden is het devies.
Wij organiseerden op woensdag 21 maart 2018 opnieuw de CIO-platformbijeenkomst. Ditmaal in het teken van Uitkomsttransparantie, Samen Beslissen en data- en artificial intelligence toepassingen om de kwaliteit van de zorg te verbeteren. Blik samen met ons terug op deze middag!
Lees verderVoor wie er nog niet helemaal van overtuigd is dat ICT en bijkomende technologiën de zorg op z’n kop zet, moet dit verhaal toch wel het laatste duwtje geven. Het digitale tijdperk is begonnen en eindigt ook niet meer.
