Bij het invoeren van nieuwe software gaat de aandacht vaak uit naar de techniek. Er worden keuzes gemaakt, tests uitgevoerd en een planning opgesteld. Projectteams zijn vaak maanden bezig met het ontwerpen van functies, koppelingen en processen. Op het moment waarop de software dan eindelijk live gaat, voelt het alsof het grootste en belangrijkste werk erop zit.
In de praktijk pakt het toch vaak anders uit: het systeem wordt na de livegang regelmatig niet gebruikt zoals bedoelt. Medewerkers gebruiken bijvoorbeeld maar een klein deel van de mogelijkheden, zoeken hun weg buiten het systeem om, of vallen terug op hun oude werkwijzen. De conclusie is dan snel dat er “iets niet klopt” aan de techniek, al werkt deze vaak precies zoals ontworpen. Wat minder goed werkt, is de acceptatie ervan door mensen.
Acceptatie is geen vanzelfsprekend gevolg van implementatie
Binnen de informatiesystemen-theorie gaat het Technology Acceptance Model dieper op dit vraagstuk in. Het model laat zien dat het gebruik van een systeem afhankelijk is van twee factoren: de mate waarin iemand gelooft dat het systeem zijn werk verbetert (ervaren nut) en de mate waarin iemand het systeem als eenvoudig ervaart (ervaren gebruiksgemak). Belangrijk en opvallend aan in dit model is dat het niet gaat om wat objectief waar is, maar om wat mensen ervaren; hun perceptie.
Minder fouten en strakkere processen: op papier klopt het systeem. Maar in de praktijk blijft het systeem ongebruikt als medewerkers niet begrijpen hoe het bij hun werk kan helpen. Onder hoge werkdruk of bij twijfel over eigen skills wordt zelfs de simpelste tool een drempel. Zo wordt zichtbaar dat de kern van een implementatie niet bij de technologie zelf ligt, maar bij hoe mensen het nieuwe systeem begrijpen, gebruiken en ervaren.
Een kloof tussen projectverhaal en werkvloer
Terwijl in projectgroepen wordt gesproken over optimalisatie, compliance en procesverbetering, spelen voor de individuele medewerker hele andere vragen:
- Wat betekent dit voor mijn dagelijkse werk?
- Kost dit mij extra tijd?
- Kan ik dit voldoende beheersen?
- Wat gebeurt er als ik fouten maak?
Krijgen deze vragen onvoldoende aandacht, dan ontstaat er een kloof tussen het projectverhaal en de werkvloer. Op papier is de implementatie logisch, maar voor de mensen die ermee moeten werken, voelt dat vaak anders. Het Technology Acceptance Model helpt om die kloof zichtbaar te maken: het nodigt uit om niet alleen te kijken naar wat een systeem kan, maar vooral naar hoe het wordt beleefd.
Routine en competentie onder druk
Een nieuw systeem doorbreekt bestaande routines. Handelingen die jarenlang vanzelf gingen, vragen ineens weer aandacht en concentratie. Dat kost energie en vertraagt tijdelijk het werk. Ook raakt een implementatie vaak aan het gevoel van competentie. Medewerkers die zich zeker voelden in het oude systeem, moeten opnieuw leren en oefenen. Dat kan onzeker maken – zeker in omgevingen waar werkdruk hoog is en fouten zichtbaar zijn.
Wanneer het ervaren nut nog niet duidelijk is en het gebruik ingewikkeld voelt, is het logisch dat mensen teruggrijpen op vertrouwde werkwijzen. Wat van buitenaf op weerstand lijkt, is vaak een poging om grip te houden.
Wat vraagt dit van verandercommunicatie?
Als acceptatie wordt bepaald door ervaren nut en gebruiksgemak, dan vraagt dit om meer dan een communicatiekalender en een trainingsprogramma:
Allereerst vraagt het om concreet te zijn. Leg niet alleen uit wat er verandert, maar maak vooral zichtbaar wat het oplevert. Hoe bespaart dit systeem tijd? Welke fouten worden hiermee voorkomen? Welke samenwerking wordt eenvoudiger? Hoe dichter het voordeel bij het dagelijkse werk ligt, hoe groter de kans dat het als relevant wordt ervaren.
Daarnaast vraagt het om aandacht voor eenvoud in de beleving. Dat betekent niet dat elk systeem simpel moet zijn, maar wel dat de eerste ervaringen zo laagdrempelig mogelijk moeten zijn. Begeleide oefensessies, snelle ondersteuning en ruimte om vragen te stellen dragen bij aan het gevoel van controle.
Ook leiderschap speelt een rol. Acceptatie wordt niet alleen individueel, maar ook sociaal bepaald. Wanneer leidinggevenden het systeem zichtbaar gebruiken en laten zien dat zij zelf ook leren, verandert de norm. Gedrag wordt dan niet alleen verwacht, maar voorgeleefd.
Livegang als beginpunt
Livegang wordt vaak gezien als het eindpunt van het project. Vanuit acceptatieperspectief is het eerder het begin. De eerste weken na livegang zijn bepalend voor hoe het systeem wordt beoordeeld. Worden vragen snel opgepakt? Worden successen gedeeld? Is er ruimte om te wennen?
In deze fase wordt de perceptie van nut en gebruiksgemak gevormd. En juist die perceptie bepaalt of het systeem duurzaam onderdeel wordt van het dagelijks werk.
Tot slot
Wanneer een software-implementatie stroef verloopt, is het begrijpelijk om naar de techniek te kijken. Toch kan het waardevoller zijn om eerst andere vragen te stellen:
- Ervaren medewerkers daadwerkelijk dat het systeem hun werk verbetert?
- Wordt het gebruik als werkbaar en beheersbaar ervaren?
- Is er ruimte om nieuwe routines veilig te ontwikkelen?
- Wordt het gewenste gedrag zichtbaar voorgeleefd?
Het Technology Acceptance Model herinnert ons eraan dat technologie pas succesvol is wanneer mensen haar omarmen. En omarmen vraagt meer dan instructie; het vraagt inzicht in hoe mensen verandering beleven.
Misschien ligt de sleutel tot succesvolle implementaties dus minder in de software zelf, en meer in hoe we acceptatie ontwerpen.
aan de slag met acceptatie in jouw organisatie?
Anne helpt graag!
