Het systeem staat er. Het doet wat is afgesproken. En toch werkt niemand ermee. Dat is geen pech, dat is een patroon. En het is te voorkomen, als je verandering behandelt als ontwerpkeuze in plaats van als training achteraf.
Het gaat bijna altijd zo. Een bedrijf kiest of bouwt nieuwe software. De oplevering haalt de planning, de demo oogt strak, iedereen krijgt een inlog. Een kwartaal later kijk je nog eens: de offertes leven weer in de oude Excel, afspraken zitten weer in iemands hoofd, en het nieuwe systeem wordt af en toe bijgewerkt. Voor de vorm.
De reflex is dan om naar de techniek te wijzen. Te traag, te veel knoppen, dat ene veld op de verkeerde plek. Soms klopt dat. Maar meestal doet de software precies wat er is gevraagd. Wat ontbreekt is gebruik. En gebruik is geen functie die je achteraf bijbouwt.
Verandering is geen training achteraf
Bij de meeste projecten zit de verandering helemaal aan het eind. Een uitlegsessie in de laatste week, een handleiding, misschien een lunchpresentatie. Daarna heet het live. Maar op dat moment is de belangrijkste vraag nog niet beantwoord: waarom zou je team morgen anders werken dan vandaag?
De oude Excel is vertrouwd, snel en van henzelf. Het nieuwe systeem is onbekend en van het project. Zolang je dat verschil niet serieus neemt, wint de Excel. Niet uit onwil, maar omdat mensen op een drukke dinsdag doen wat het snelst voelt.
Verandering hoort daarom vooraan in het project te zitten, als ontwerpkeuze. In hoe het systeem eruitziet, en in hoe je het invoert.
Vier vragen die bepalen of iemand meegaat
Of een collega overstapt, hangt af van vier simpele vragen. Beantwoordt iemand er een met nee, dan valt diegene terug op de oude manier. Wij toetsen ze in elk traject; het model erachter, ons Veranderkompas, vind je in de kennisbank.