Hoe gemeenten twee keer betalen voor hun software

De grootste kostenpost voor gemeentelijke software? Die staat zelden in de offerte. Helaas komen gemeenten er na een paar jaar pas achter dat ze veel te veel geld kwijt zijn aan hun leverancier.

Een aanbestedingstraject voor software verloopt meestal via een vast patroon. De gemeente wil iets specifieks. Denk aan een nieuw zaaksysteem, documentmanagementsysteem, of integratieplatform. Er volgt een lijst met eisen. Leveranciers presenteren hun oplossing en prijs, functionaliteit, planning en implementatie worden met elkaar vergeleken. 

Heel concrete onderdelen, die passen in een besluitvormingsproces waarin je kosten moet onderbouwen. En eerlijk is eerlijk: tijdens demo’s en implementaties werken dit soort producten vaak heerlijk soepel. Problemen ontstaan pas later.

Wanneer je afhankelijkheid ineens gaat voelen

Neem een gemeente die een modern zaaksysteem invoert. Aanvragen, documenten en statussen zitten netjes bij elkaar. Medewerkers hoeven niet meer te zoeken en managers krijgen eindelijk dashboards waar ze iets mee kunnen. Alles ziet er strak en overzichtelijk uit. Een jaar later wil de gemeente iets extra's.

Inwoners moeten via een portaal realtime kunnen volgen wat de status van hun vergunningaanvraag is. Net zoals bij een pakketje van PostNL. Of de gemeente wil documenten uit verschillende systemen combineren om aanvragen automatisch samen te vatten en sneller af te handelen. In theorie lijkt dat overzichtelijk. De gegevens zijn er immers al. In de praktijk begint daar vaak de ellende.

Dan blijkt bijvoorbeeld dat metadata van documenten alleen binnen het platform goed bruikbaar is. Workflows gebruiken eigen statussen. Rapportages maken gebruik van velden die buiten het systeem niet bestaan. Het documentmanagementsysteem gebruikt andere definities dan het zaaksysteem. En het klantcontactsysteem spreekt weer een andere taal.

Dus moeten er exports gebouwd worden. Daarna vertaalslagen tussen systemen. Vervolgens nieuwe koppelingen. En zodra één leverancier iets aanpast, begint het hele circus opnieuw.

Wat begon als een uitbreiding van de dienstverlening, groeit uit tot een apart IT-project.

En precies daar verschijnen de verborgen kosten van afhankelijkheid.

Waarom dit bijna onvermijdelijk is

Het ongemakkelijke is: dit ontstaat meestal niet door slechte software. Juist succesvolle platformen creëren afhankelijkheid.

Leveranciers bouwen hun platformen logisch genoeg zo op dat alles binnen het eigen ecosysteem soepel samenwerkt. Dat maakt implementaties aantrekkelijk, maar zorgt er óók voor dat gemeenten later steeds moeilijker buiten dat ecosysteem kunnen bewegen. Daar profiteren gemeenten aanvankelijk van, totdat ze buiten dat ecosysteem willen bewegen.

Dan blijkt ineens hoe sterk processen, koppelingen, rapportages en werkwijzen met elkaar verweven zijn geraakt. Na een paar jaar draait niet alleen software op het platform, maar ook een groot deel van de werkwijze van de gemeente.

En dan verschijnt de tweede rekening. Puur voor de gevolgen van eerder gemaakte keuzes. Omdat een gemeente ongemerkt een landschap heeft opgebouwd waarin alles van elkaar afhankelijk is geworden.

Scenario’s vergelijken in plaats van prijzen

Het lastige is dat die toekomstige kosten tijdens een aanbesteding nauwelijks zichtbaar zijn. Bij softwarekeuzes kijken gemeenten nog vaak vooral naar de situatie van vandaag.
Werkt het systeem goed? Past het binnen het budget? Hoe snel kan het live? Interessanter wordt het als je een paar jaar vooruitkijkt.

Wat gebeurt er als een gemeente over drie jaar inwoners realtime inzicht wil geven? Of als AI toegang nodig heeft tot bezwaarschriften en vergunningaanvragen? Of wanneer een leverancier vervangen moet worden terwijl tientallen koppelingen aan het platform vastzitten? Dan verandert de vergelijking.

Stel je voor, je hebt de keuze uit twee oplossingen. Vandaag lijken ze sterk op elkaar, maar op de langere termijn kunnen ze enorm van elkaar verschillen in kosten en bewegingsruimte.

Bij de ene oplossing blijft data relatief toegankelijk en zijn koppelingen flexibel aanpasbaar. Bij de andere ontstaan nieuwe lagen middleware, maatwerk en afhankelijkheden zodra er iets verandert. Tijdens een strakke demo zie je dat verschil niet, maar als je het eenmaal gebruikt voel je het wel.

De duurste software staat vaak niet in de offerte

Gemeenten betalen bij softwareprojecten dus netjes voor licenties, implementatie en beheer. Maar de grootste kosten verschijnen vaak pas daarna, wanneer:

• koppelingen opnieuw gebouwd moeten worden
• data niet eenvoudig herbruikbaar is
• leveranciers prijzen verhogen
• migraties complexer blijken dan verwacht
• nieuwe dienstverlening vastloopt op bestaande systemen

Dit zijn vaak geen uitzonderingen meer.

En dat terwijl gemeenten meer digitale dienstverlening moeten leveren met minder budget en minder capaciteit. Inwoners verwachten ondertussen een overheid die net zo soepel werkt als commerciële platforms. Niemand begrijpt nog waarom een pakketje realtime te volgen is, terwijl een vergunningaanvraag in een digitaal zwart gat kan verdwijnen.

Toch zitten gemeentelijke systemen vaak nog vast in architecturen die vooral ontworpen zijn voor stabiliteit binnen één platform. Iedere verandering vraagt opnieuw budget, maatwerk en externe expertise. En zo betaalt een gemeente stap voor stap opnieuw voor dezelfde softwarekeuze.

Een bredere kijk op kosten

Gemeenten betalen nu vaak twee keer voor software. Eerst bij aanschaf, later opnieuw zodra verandering geld gaat kosten. Het kan ook anders. Richt je IT-landschap zo in dat nieuwe dienstverlening geen miljoenenproject wordt. Want software hoort verandering mogelijk te maken, niet tegen te houden.

Bij WeAreFrank! kijken we ook zo naar integratie en softwarekeuzes. We vragen niet alleen: “Werkt dit goed?” Maar ook: “Hoeveel vrijheid houd je later nog over?”

Kun je systemen vervangen zonder enorme migraties? Kun je data blijven gebruiken buiten één applicatie? Kun je koppelingen aanpassen zonder een compleet project op te starten? En kun je samenwerken met andere gemeenten zonder alles opnieuw te bouwen?

Dat zijn echt geen theoretische architectuurvragen. Het zijn vragen die bepalen hoeveel publieke middelen een gemeente later opnieuw moet uitgeven.

Want precies daar gaat het vaak mis. Gemeenten betalen eerst voor software die hun processen ondersteunt. En daarna opnieuw zodra diezelfde software verandering ingewikkeld maakt.

De echte vraag bij software is dus niet wat het vandaag kost. De echte vraag is hoeveel het kost zodra je later iets wilt veranderen.