Wat zijn veelgemaakte fouten bij de aanschaf van software door gemeenten?

Gemeenten maken bij de aanschaf van software regelmatig dezelfde fouten. De meest voorkomende zijn: een te vaag programma van eisen, de verkeerde leverancier kiezen op basis van prijs of naam, standaardsoftware kopen die niet past bij de specifieke processen van de gemeente, en onvoldoende aandacht besteden aan implementatie en vendor lock-in. Dit artikel zet de belangrijkste valkuilen op een rij, zodat je ze kunt herkennen én vermijden.

Waarom gaat de aanschaf van software bij gemeenten zo vaak mis?

Softwareaanschaf bij gemeenten gaat vaak mis omdat de technische keuze wordt losgekoppeld van de organisatorische werkelijkheid. Er wordt te vroeg gekozen voor een systeem, terwijl de processen die dat systeem moet ondersteunen nog niet goed in kaart zijn gebracht. Het resultaat: software die technisch werkt, maar in de praktijk niet aansluit op hoe mensen hun werk doen.

Daarnaast speelt de structuur van gemeentelijke organisaties een rol. Beslissingen worden genomen op managementniveau, maar de dagelijkse gebruikers zitten op de werkvloer. Als die twee groepen niet goed met elkaar communiceren tijdens het aankoopproces, koopt de gemeente software die managers op papier tevreden stelt, maar die medewerkers dagelijks frustreert in de uitvoering.

Ook de aanbestedingsprocedure zelf werkt soms averechts. De focus ligt op het voldoen aan formele eisen, niet op het vinden van de beste oplossing voor een concreet probleem. Dat nodigt leveranciers uit om te verkopen wat ze hebben, in plaats van te leveren wat de gemeente nodig heeft.

Wat zijn de meest gemaakte fouten bij het opstellen van een programma van eisen?

De meest gemaakte fouten bij het opstellen van een programma van eisen zijn: te algemeen formuleren, te veel eisen opnemen zonder prioritering, en de eisen baseren op wat de huidige software doet in plaats van op wat de organisatie nodig heeft. Een programma van eisen dat te breed is, maakt het onmogelijk om leveranciers goed te vergelijken.

Een veelgemaakte misstap is dat gemeenten hun huidige werkwijze als uitgangspunt nemen. Ze beschrijven wat het bestaande systeem doet en verwachten dat de nieuwe software dat overneemt. Maar als de huidige processen inefficiënt zijn, koopt de gemeente daarmee de inefficiëntie gewoon opnieuw in.

Goede eisen zijn concreet, meetbaar en gekoppeld aan een doel. Niet "de software moet rapportages kunnen genereren", maar "de software moet maandelijks automatisch een overzicht genereren van X per afdeling, exporteerbaar naar Excel." Dat soort specificiteit dwingt zowel de gemeente als de leverancier tot helderheid.

Hoe kiest een gemeente de verkeerde softwareleverancier?

Een gemeente kiest de verkeerde leverancier door te veel gewicht te leggen op bekendheid, referenties bij andere gemeenten, of een indrukwekkende demo. Een demo laat zien wat een systeem kan onder ideale omstandigheden. Het zegt weinig over hoe het systeem zich gedraagt als het geïntegreerd moet worden met bestaande systemen of als de organisatie groeit.

Referenties bij andere gemeenten zijn nuttig, maar niet automatisch relevant. Elke gemeente heeft andere processen, een andere schaalgrootte en andere ambities. Wat goed werkt in gemeente A, kan volledig mislukken in gemeente B.

Wat gemeenten zelden doen maar wel zouden moeten doen: een leverancier uitnodigen om mee te denken over een concreet probleem uit de eigen organisatie, nog vóór de aanbesteding. Dat geeft veel meer inzicht in hoe een leverancier werkt dan welke presentatie dan ook.

Wat gaat er mis bij de implementatie van nieuwe software in een gemeente?

Bij de implementatie van nieuwe software in een gemeente gaat het meest mis met de combinatie van onrealistische tijdlijnen, onvoldoende training en gebrekkige begeleiding van medewerkers. De software wordt technisch opgeleverd, maar de organisatie is er nog niet klaar voor. Medewerkers werken dan naast het nieuwe systeem door met oude methoden, wat de hele investering ondermijnt.

Een andere veelvoorkomende fout is dat de implementatie wordt behandeld als een IT-project in plaats van een organisatieverandering. Technisch gezien kan alles kloppen, maar als mensen het systeem niet begrijpen of er geen vertrouwen in hebben, gebruiken ze het niet goed. Verandermanagement is daarom minstens zo belangrijk als de technische uitrol.

Gemeenten onderschatten ook de datamigratieproblematiek. Historische data uit oude systemen is zelden schoon en gestructureerd. Zonder een goed migratieplan gaat waardevolle informatie verloren of belandt er ruis in het nieuwe systeem.

Waarom schiet standaardsoftware tekort voor gemeentelijke processen?

Standaardsoftware schiet tekort voor gemeentelijke processen omdat die processen te specifiek en te divers zijn om in een generiek systeem te passen. Gemeenten voeren taken uit die nergens anders op dezelfde manier plaatsvinden, zoals het uitvoeren van de Wet maatschappelijke ondersteuning, het beheren van vergunningen of het coördineren van jeugdzorg. Standaardpakketten zijn ontworpen voor de gemene deler, niet voor de uitzondering.

Het gevolg is dat gemeenten standaardsoftware gaan aanpassen. Ze bouwen maatwerk bovenop een systeem dat daar niet voor bedoeld is. Dat leidt tot technische schuld: elke update van de leverancier kan de aanpassingen breken, en de gemeente wordt afhankelijk van dure tussenoplossingen.

Bovendien verandert gemeentelijk beleid regelmatig door nieuwe wetgeving of politieke keuzes. Standaardsoftware kan dat tempo zelden bijhouden. Een systeem dat vandaag past, kan over twee jaar al verouderd zijn.

Hoe voorkomt een gemeente vendor lock-in na softwareaankoop?

Een gemeente voorkomt vendor lock-in door bij de aanschaf al contractueel vast te leggen dat data exporteerbaar is in open formaten, dat de broncode of documentatie beschikbaar is bij beëindiging van het contract, en dat er geen exclusieve afhankelijkheid ontstaat van één leverancier voor updates of beheer.

Vendor lock-in ontstaat niet alleen technisch, maar ook organisatorisch. Als medewerkers jarenlang werken met één systeem en de leverancier de enige is die het begrijpt, zit de gemeente feitelijk gevangen. Zorg daarom voor interne kennis over hoe het systeem werkt, ook als je het beheer uitbesteedt.

Stel bij de aanbesteding concrete vragen over exitprocedures. Wat kost het om over te stappen? Hoe lang duurt een datamigratie? Welke documentatie levert de leverancier bij vertrek? Een leverancier die deze vragen niet helder kan beantwoorden, is een risico.

Welke vragen moet een gemeente stellen vóór de aanschaf van software?

Vóór de aanschaf van software moet een gemeente minimaal de volgende vragen stellen: Welk concreet probleem lossen we op? Wie zijn de dagelijkse gebruikers en wat hebben zij nodig? Hoe integreert de software met bestaande systemen? Wat zijn de exitkosten en exitprocedures? En: hoe beweegt de software mee als onze organisatie verandert?

Die laatste vraag is misschien wel de meest onderschatte. Gemeenten veranderen. Beleid verandert, teams groeien of krimpen, wetgeving schrijft nieuwe processen voor. Software die nu perfect past, moet over drie jaar nog steeds bruikbaar zijn. Vraag leveranciers hoe zij omgaan met doorontwikkeling en wie de kosten daarvan draagt.

Betrek ook de werkvloer bij de selectie. Laat medewerkers die dagelijks met het systeem gaan werken de demo's bijwonen en hun feedback geven. Zij zien direct of een systeem aansluit op de praktijk, iets wat een manager vanachter een presentatie niet altijd kan beoordelen.

Bij Corver Development zien we keer op keer dat de beste softwarekeuzes ontstaan als organisaties eerst hun eigen processen begrijpen, dan pas een leverancier zoeken. Benieuwd wat wij voor jouw organisatie kunnen betekenen? Bekijk onze diensten en ontdek hoe wij samenwerken.