applatenmaken.com/kennisbank/software die niemand gebruikt
Software die niemand gebruikt
Er is opgeleverd, er is getest, en na drie maanden blijkt dat de helft van de afdeling nog steeds het oude bestand bijhoudt. Dat is zelden een kwestie van onwil. Meestal is het een signaal dat er iets in het ontwerp of in de invoering niet klopt, en dat is nog te repareren.
Wat er meestal werkelijk aan de hand is
Als mensen een systeem omzeilen, is dat bijna altijd rationeel gedrag. Het kost ze meer tijd dan de oude manier, of het levert hun eigen werk niets op terwijl het management er wel iets aan heeft. Dat is geen weerstand maar een rekensom.
De klassieke vorm is het registratiesysteem: de monteur, verpleegkundige of buitendienstmedewerker voert gegevens in waar iemand anders een rapport uit haalt. Voor de invoerder is het puur extra werk. Zolang daar niets tegenover staat, wint het bonnetje in de broekzak.
De tweede vorm is dat het systeem niet past bij hoe het werk werkelijk gaat. Vaak omdat het is ontworpen op basis van hoe het proces hóórt te lopen, beschreven door iemand die het niet dagelijks doet. In de praktijk zijn er uitzonderingen, en als die niet in het systeem passen, gaat de hele uitzonderingsstroom eromheen.
Drie patronen die u kunt herkennen
De symptomen verschillen en de oplossing daarmee ook.
| Patroon | Waaraan u het herkent | Wat het meestal vraagt |
|---|---|---|
| Het kost invoerders alleen tijd | ✓Gegevens worden laat, onvolledig of verzameld aan het eind van de week ingevoerd | !Iets teruggeven aan de invoerder: overzicht, minder dubbel werk, een stap die vervalt |
| De uitzondering past niet | ✓Er ontstaat een schaduwlijst voor de gevallen die het systeem niet aankan | !De uitzondering alsnog ondersteunen, of expliciet erkennen en ernaar handelen |
| Niemand weet dat het bestaat | ✓Gebruikers vragen om functies die er al zijn, of gebruiken één schermpje | !Invoering en begeleiding, niet meer functionaliteit |
Wat u tijdens het bouwen al kunt doen
Adoptie is geen fase na de oplevering. Het meeste wordt bepaald tijdens de bouw, en dat kost weinig extra.
De derde en de vierde vraag doen in de praktijk het meest. Een systeem dat de invoerder helpt en een collega die het uitlegt, verslaan elke training.
Meet of het gebruikt wordt
Zonder cijfers is dit een discussie over indrukken. Met een paar simpele metingen weet u binnen een maand waar u staat.
Kijk niet naar het aantal aanmeldingen maar naar wie het systeem in de afgelopen week werkelijk heeft gebruikt, uitgesplitst per afdeling of locatie. Verschillen tussen teams zeggen meer dan een gemiddelde: als locatie A het wel gebruikt en locatie B niet, ligt het zelden aan de software.
Kijk daarnaast naar het proces zelf. Als het systeem de doorlooptijd van een aanvraag moest verkorten, meet dan die doorlooptijd. Blijft die gelijk terwijl het gebruik hoog is, dan wordt het systeem wel gevuld maar verandert er niets — en dat is een ander probleem dan adoptie.
Als het al misgegaan is
Een systeem dat na een half jaar nauwelijks wordt gebruikt, is niet verloren. De volgorde van herstel is wel anders dan de meeste organisaties kiezen.
Begin niet met een nieuwe training en ook niet met verplichten. Begin met vragen: ga zitten bij drie mensen die het niet gebruiken en kijk mee met hoe ze hun werk wél doen. In vrijwel alle gevallen komt daar een concrete reden uit die te repareren is.
Repareer die reden zichtbaar en snel. Eén aanpassing die duidelijk voortkomt uit wat iemand op de werkvloer zei, doet meer voor het vertrouwen in het systeem dan een half jaar aan communicatie. Pas daarna is verplichten een redelijk gesprek.
Veelgestelde vragen
Ligt het aan de software of aan de mensen?
Bijna altijd aan de aansluiting tussen die twee. Mensen omzeilen een systeem wanneer de oude manier sneller is of wanneer het invoeren hun eigen werk niets oplevert. Dat is rationeel gedrag. Ga daarom eerst kijken wat het systeem hun kost en oplevert, voordat u het over weerstand heeft.
Helpt het om gebruik te verplichten?
Als sluitstuk wel, als beginpunt zelden. Verplichten zonder de onderliggende reden weg te nemen levert gegevens op die net genoeg zijn om aan de verplichting te voldoen en verder onbruikbaar. Los eerst op waarom mensen eromheen gaan, dan is verplichten een formaliteit.
Hoe voorkom ik dit bij een volgend project?
Door tijdens het bouwen met de invoerders zelf te praten en hun uitzonderingen serieus te nemen. En door te zorgen dat wie gegevens invoert er zelf iets voor terugkrijgt: een overzicht, een stap die vervalt, minder dubbel werk. Dat is een ontwerpkeuze en geen communicatievraagstuk.
Wat meet ik om te weten of het goed gaat?
Wekelijks actieve gebruikers per afdeling of locatie, niet het totaal aantal accounts. En daarnaast de uitkomst die het systeem moest verbeteren, bijvoorbeeld doorlooptijd of aantal fouten. Als het gebruik hoog is maar die uitkomst niet beweegt, wordt het systeem gevuld zonder dat het iets verandert.
Moeten we opnieuw beginnen als niemand het gebruikt?
Zelden. In de meeste gevallen zit het probleem in een handvol concrete punten die uit een middag meekijken naar boven komen. Opnieuw beginnen kost het budget dat u nodig heeft om die punten op te lossen, en levert een tweede systeem op met dezelfde blinde vlek.