Je kunt software opleveren die precies doet wat in de opdracht stond. De schermen werken. De koppeling werkt. De handleiding is verstuurd.
En toch kan het oude spreadsheet kort daarna weer openstaan.
Dan is er technisch iets gebouwd, maar in het bedrijf nog weinig veranderd. Voor Tienvoud is opleveren daarom een tussenstand. Een oplossing is pas af wanneer mensen haar in hun echte werk gebruiken en het bedoelde probleem merkbaar kleiner wordt.
Technisch klaar is een tussenstand
Bij een IT-project is de verleiding groot om de definitie van klaar uit de techniek te halen. De functies zijn gebouwd, de test is groen en de knop doet wat hij moet doen.
Dat zijn belangrijke voorwaarden. Ze zeggen alleen nog niet of de oplossing past in een drukke werkdag.
Misschien moet een medewerker informatie invoeren die pas later beschikbaar is. Misschien is onduidelijk wie een voorstel controleert. Misschien vertrouwt iemand de uitkomst niet, omdat nergens zichtbaar is hoe die tot stand kwam.
Zulke vragen horen niet bij de nazorg. Ze zijn onderdeel van het ontwerp.
Weerstand bevat informatie
Wanneer mensen een nieuwe werkwijze niet gebruiken, is het gemakkelijk om dat af te doen als weerstand tegen verandering. Soms speelt gewoonte zeker mee. Toch is weerstand vaak preciezer dan dat.
Een medewerker kan zien dat een belangrijke uitzondering ontbreekt. Iemand kan bang zijn om verantwoordelijkheid te dragen voor een uitkomst die niet te controleren is. Of de nieuwe stap kan op papier sneller zijn en in de praktijk extra herstelwerk veroorzaken.
Dat betekent niet dat ieder bezwaar de oplossing moet tegenhouden. Het betekent wel dat je wilt weten wat erachter zit.
Vraag waar iemand terugschakelt naar de oude manier. Kijk mee op het moment dat het gebeurt. Daar vind je vaak informatie die in een latere evaluatie al is gladgestreken.
Adoptie begint vóór de bouw
Een team betrekken nadat alle belangrijke keuzes zijn gemaakt, is laat. Dan kunnen medewerkers vooral nog reageren op iets dat er al staat.
Begin eerder. Laat de mensen die het werk doen zien hoe het proces werkelijk loopt. Vraag welke fouten ze voorkomen, welke uitzonderingen ertoe doen en wat nooit verloren mag gaan.
Maak vervolgens een kleine eerste versie die in echt werk te testen is. Geen toneeldemo met perfecte invoer, maar een bruikbare stap waar mensen tijdens hun werk op kunnen reageren.
Het doel van zo'n versie is leren. Wat begrijpt iemand zonder uitleg? Waar ontstaat twijfel? Welke stap voelt als dubbel werk? De antwoorden bepalen wat er daarna gebouwd of veranderd moet worden.
Dat sluit aan op een overtuiging die onder veel werk van Tienvoud ligt: de mensen die het werk doen, zien waar het vastloopt.
Maak de nieuwe werkwijze logisch
Mensen blijven een nieuwe oplossing niet gebruiken omdat de lancering enthousiast was. De nieuwe manier moet op een gewone dinsdag logisch blijven.
Dat vraagt soms techniek. Het vraagt ook heldere afspraken. Wie doet wat? Wanneer neemt een mens het over? Waar kan iemand terecht bij twijfel? Welke oude route stoppen we bewust, en welke blijft nodig als vangnet?
Ook leren hoort erbij. Mensen met AI leren werken betekent meer dan een lijst prompts uitdelen. Ze moeten begrijpen waar het systeem goed in is, waar het kan missen en welke verantwoordelijkheid bij henzelf blijft.
Een goede oplossing maakt het gewenste gedrag makkelijker. Ze geeft genoeg uitleg op het moment dat die nodig is en laat zien wat er met iemands invoer gebeurt.
Kijk naar gebruik én effect
Het aantal aangemaakte accounts zegt weinig als mensen na het inloggen alsnog alles buiten het systeem afhandelen.
Kijk daarom naar het echte werk. Wordt de nieuwe route gebruikt? Waar ontstaan omwegen? Hoeveel controle of herstel blijft nodig? Ervaren medewerkers en klanten de verandering die bij de start was bedoeld?
Dat laatste is belangrijk. Een oplossing kan veel gebruikt worden en toch het verkeerde verbeteren. Meer snelheid helpt bijvoorbeeld niet wanneer de kwaliteit ondertussen daalt.
Spreek dus vooraf af wat beter moet worden. Combineer wat je kunt tellen met wat mensen in de praktijk merken. Zo wordt adoptie geen doel op zichzelf, maar een teken dat de verbetering werkelijk deel van het bedrijf wordt.
Blijf na de oplevering
Veel waarde ontstaat nadat de eerste versie live staat. Dan verschijnen de uitzonderingen, gewoontes en vragen die vooraf nog onzichtbaar waren.
Daarom blijft een vertienvoudiger betrokken. Die verzamelt signalen, helpt mensen met de nieuwe werkwijze, lost op wat knelt en bespreekt met de opdrachtgever wat er echt verandert.
Soms moet de software beter. Soms ontbreekt een afspraak of vaardigheid. Soms blijkt de gekozen oplossing niet de juiste. Ook dan is stoppen of terugbouwen vooruitgang, zolang het probleem er eerlijker door wordt bekeken.
Het doel is geen project dat netjes kan worden afgesloten. Het doel is een verbetering die gebruikt wordt, effect heeft en mee kan bewegen met het bedrijf.
Heb je iets gebouwd dat nog niet echt landt? Stuur me een appje. Dan kijken we naar het werk achter de oplevering.