Veel organisaties weten dat hun IT-infrastructuur aan vernieuwing toe is, maar weten niet goed waar te beginnen. De kloof tussen het technische ideaal en de dagelijkse werkelijkheid van mensen, processen en systemen is vaak groter dan verwacht. Hoe pakt u zo’n transformatie aan zonder de organisatie te ontwrichten?
Waarom IT-transformatie zelden puur technisch is
Het is verleidelijk om een IT-transformatie te beschouwen als een project van technici voor technici. In de praktijk blijkt echter keer op keer dat de technische component weliswaar complex is, maar zelden de grootste bron van vertraging of mislukking. Wat organisaties het meest tegenhoudt, is de wisselwerking tussen de nieuwe systemen en de bestaande manier van werken.
Neem een middelgroot familiebedrijf dat besluit over te stappen van een verouderd ERP-systeem naar een moderne cloudoplossing. De software zelf is misschien binnen zes maanden geïmplementeerd, maar de medewerkers die twintig jaar lang op dezelfde manier hebben gewerkt, passen zich niet automatisch aan. Zij hebben gewoonten, ongeschreven regels en informele werkwijzen ontwikkeld die nergens in een handleiding staan, maar wel degelijk de continuïteit van het bedrijf dragen.
Weerstand bij verandering is in dit verband geen onwil, maar een begrijpelijke reactie op onzekerheid. Wie jarenlang weet hoe hij zijn werk goed doet, en ineens merkt dat die kennis deels waardeloos is geworden, ervaart dat als een verlies. Dat vraagt om erkenning, niet om een cursus van twee uur in een vergaderzaal.
De valkuil van het grote plan
Organisaties die een IT-transformatie aanpakken met een uitgebreid masterplan voor drie of vier jaar, lopen regelmatig vast. Niet omdat plannen maken zinloos is, maar omdat de werkelijkheid zich nu eenmaal niet aan planningen houdt. Systemen gedragen zich anders dan verwacht, leveranciers leveren later dan beloofd, en de organisatie zelf verandert in de tussentijd.
Een aanpak die in de praktijk beter blijkt te werken, is die van gefaseerde implementatie: kleine, beheersbare stappen waarbij telkens een afgebakend onderdeel van de infrastructuur wordt aangepakt, geëvalueerd en bijgesteld voordat het volgende onderdeel aan de beurt komt. Dit vergt geduld, en het vergt bestuurders die bereid zijn om tussentijdse resultaten te accepteren die er op papier misschien onvolledig uitzien.
Wat daarbij helpt, is het onderscheid te bewaken tussen een probleem en een symptoom. Een trage server is een symptoom. Het eigenlijke probleem kan zijn dat de architectuur van tien jaar geleden nooit is herzien, of dat de groei van de organisatie nooit is vertaald naar een bijbehorende IT-strategie. Wie alleen het symptoom aanpakt, koopt tijd maar lost niets op.
Bij het inrichten van gefaseerde trajecten is het bovendien nuttig om te weten welke tooling en leveranciers in vergelijkbare sectoren worden gebruikt. Informatie hierover is soms te vinden bij gespecialiseerde partijen (https://www.adts.nl), al blijft de uiteindelijke keuze altijd afhankelijk van de specifieke context van de organisatie.
Rollen, verantwoordelijkheden en de vergeetput
Een van de meest voorkomende problemen bij technische projectimplementatie is niet dat niemand iets doet, maar dat onduidelijk is wie wat doet. In organisaties met een vlakke structuur of een lange geschiedenis van informeel overleg, zijn rollen zelden scherp gedefinieerd. Iedereen doet een beetje van alles, en dat werkt prima zolang de organisatie klein is en de systemen overzichtelijk.
Zodra een IT-transformatie van start gaat, wordt die onduidelijkheid echter een risico. Beslissingen worden uitgesteld omdat niemand zeker weet of hij daartoe bevoegd is. Problemen worden gesignaleerd maar niet opgepakt omdat de verantwoordelijkheid ergens in het midden hangt. En de projectleider, die formeel de regie heeft, mist de mandaat om door te pakken.
Het helpt om in een vroeg stadium een onderscheid te maken tussen functies en rollen. Een functie beschrijft wat iemand in de organisatie is; een rol beschrijft wat iemand in een specifiek project of proces doet. Die twee hoeven niet samen te vallen. Een medewerker die in zijn functie weinig met IT te maken heeft, kan in een transformatieproject een sleutelrol vervullen als proceseigenaar of als verbindingspersoon tussen de werkvloer en het projectteam.
Dat vraagt om expliciete afspraken, vastgelegd op papier, en regelmatig besproken in een gestructureerde overlegvorm. Niet als bureaucratisch ritueel, maar als middel om te voorkomen dat verantwoordelijkheden wegglijden in wat ik de vergeetput zou willen noemen: het gebied tussen de officiële taakomschrijvingen waar niemand zich eigenaar voelt.
Wat praktijkervaring leert over tempo en terugval
Organisaties die een IT-transformatie succesvol afronden, hebben vrijwel altijd één ding gemeen: zij hebben het tempo van de verandering afgestemd op de absorptiecapaciteit van de organisatie, niet op de wensen van de leverancier of de ambities van het management. Dat klinkt vanzelfsprekend, maar is het in de praktijk zelden.
De druk om snel te implementeren komt van meerdere kanten. Licentiekosten lopen door zolang het oude systeem nog draait. Bestuurders willen resultaat zien. En leveranciers hebben hun eigen planning die niet altijd flexibel is. Al die prikkels wijzen in de richting van snelheid, terwijl de organisatie behoefte heeft aan ruimte.
Terugval is in dit verband een begrip dat te weinig aandacht krijgt. Bijna elke transformatie kent momenten waarop de organisatie terugvalt in oude gewoonten: medewerkers die de nieuwe werkwijze omzeilen omdat ze de oude sneller vinden, leidinggevenden die informele beslissingen nemen buiten het nieuwe systeem om, of afdelingen die hun eigen schaduwadministratie bijhouden omdat ze het nieuwe systeem nog niet vertrouwen. Dat is geen falen. Het is een normaal onderdeel van verandering.
Wat helpt, is niet harder duwen, maar begrijpen waarom de terugval optreedt. Soms is het een kwestie van onvoldoende training. Soms ontbreekt het aan vertrouwen in de betrouwbaarheid van het nieuwe systeem. En soms is de terugval een signaal dat het systeem zelf niet goed aansluit op de werkprocessen, en dat er een aanpassing nodig is die eerder als zwakte wordt gezien dan als correctie.
Een eerlijke evaluatie halverwege een implementatietraject, waarbij ook kritische geluiden van de werkvloer serieus worden genomen, is in mijn ervaring meer waard dan een voltooide implementatie die op papier klaar is maar in de praktijk niet wordt gebruikt.
Veelgestelde vragen over IT-transformatie in organisaties
Hoe weet u of uw organisatie klaar is voor een IT-transformatie?
Gereedheid is zelden een absolute toestand. Het is eerder een kwestie van voldoende stabiliteit in de basisprocessen, enige mate van draagvlak bij het management, en de bereidheid om tijdelijk productiviteitsverlies te accepteren. Organisaties die midden in een andere ingrijpende verandering zitten, zoals een fusie of een leiderschapswisseling, doen er verstandig aan een grote IT-transformatie uit te stellen totdat de rust is teruggekeerd. Twee gelijktijdige veranderingsprocessen versterken elkaars weerstand.
Wat is het verschil tussen een IT-project en een IT-transformatie?
Een project heeft een begin, een einde en een concreet op te leveren resultaat. Een transformatie is een verandering van de manier waarop de organisatie werkt, ondersteund door technologie. Die twee worden in de praktijk vaak door elkaar gehaald, met als gevolg dat een transformatie wordt beheerd als een project: met een strak tijdschema, een opleverdatum en een projectteam dat daarna wordt ontbonden. Het probleem is dat de organisatorische verandering die bij een transformatie hoort, niet stopt op de opleverdatum. Wie daar geen rekening mee houdt, ziet de winst van de implementatie snel verdampen.
Hoe gaat u om met medewerkers die de nieuwe systemen blijven vermijden?
De eerste vraag is altijd: waarom vermijden zij het systeem? Is het een kwestie van onbekendheid, van ongemak, of van een dieper wantrouwen in de richting die de organisatie opgaat? Elk van die oorzaken vraagt om een andere aanpak. Onbekendheid lost u op met training en begeleiding. Ongemak vraagt om aanpassingen in de gebruikerservaring of de werkwijze. Wantrouwen vraagt om een gesprek, niet om een instructie. Medewerkers die het gevoel hebben dat hun bezwaren serieus worden genomen, zijn eerder bereid een nieuw systeem een eerlijke kans te geven dan medewerkers die het idee hebben dat de beslissing al lang geleden is genomen zonder hen.