Kan een prijsmodel op basis van gebruik de kwaliteit van Common Ground-software verbeteren?
Roxit heeft OneGround ontwikkeld als zaak- en documentregistratie. De registratie is uitsluitend te benaderen via standaard ZGW-API’s en is beschikbaar als Open Source. Daarnaast biedt Roxit deze component in SaaS-vorm onder de naam ‘Oneground Unlimited’. Het gebruik van de broncode van OneGround is dus kosteloos, maar het hosten en beheren van de dienst zijn dat niet. Bij het beprijzen van OneGround Unlimited rees dan ook de vraag hoe de kostprijs van de dienst om te slaan naar afnemende organisaties. We hadden daarbij keuze tussen betalen naar gebruik of, zoals gebruikelijk bij veel van onze andere applicaties, naar rato van het aantal inwoners. Dat laatste leek onredelijk, omdat de benutting niet evenredig is aan het aantal inwoners. Er zijn bijvoorbeeld kleine gemeenten die documenten van vele jaren in OneGround bewaren en dus veel meer opslag nodig hebben dan sommige grote gemeenten die alleen maar lopende en recent afgeronde zaken hebben.
We kozen daarom voor een prijsmodel op basis van gebruik met twee componenten: de opslag van documenten en het aantal API-bevragingen. Het idee was dat deze tezamen een goede indicatie vormen voor het gebruik van alle voorzieningen als servers, API Gateway, opslagmedia, CPU’s, mensuren etc, die bekostigd moeten worden.
Wat zijn de ervaringen?
Inmiddels is dit prijsmodel geïmplementeerd en kunnen klanten hun gebruik in een dashboard zien. Het eerste wat opvalt is dat we weinig vragen over dit dashboard krijgen. Vermoedelijk is de interesse in dit onderwerp nog beperkt. Wel kwamen we er door de duidelijke dashboards snel achter dat sommige apps (applicaties in laag 4 en 5 van Common Ground) wel heel veel bevragingen doen. Bij een relatief kleine gemeente bijvoorbeeld zorgde één app voor disproportioneel veel ZGW-bevragingen. Daardoor nam deze ene gemeente in zijn eentje meer dan alle overige organisaties tezamen van al het ‘externe’ berichtenverkeer van OneGround voor zijn rekening. De kosten voor deze gemeente werden daardoor 17 maal hoger dan het basisbedrag dat voor de meesten voldoende is. De gemeente heeft de ontwikkelaar van de app gevraagd aanpassingen te doen. Inmiddels is hierdoor het gebruik nu gedaald met een factor 6. Desgevraagd zegt de gemeente dat de prijs van de bundels de prikkel was om de softwareontwikkelaar te verzoeken de app aan te passen naast vraagtekens bij de ‘bruutheid’ van de vele bevragingen.
Is de software ook beter geworden?
De aanpassing van de software leidde dus tot een kostenbesparing bij de gemeente. Is de software ook verbeterd? Voor Roxit is duurzaamheid een belangrijk thema. Mogelijk wordt energie bespaard bij de enorme reductie in gebruik, maar we konden dit nog niet achterhalen. De betrokken componenten draaien in met andere gemeenten gedeelde containers die met velen op één server gehost worden. Om het energiegebruik terug te leiden tot één specifieke klant of component bleek nog niet mogelijk. Wel hebben we het meten hiervan naar aanleiding van deze vraag in gang gezet.
Een ander belangrijk aandachtspunt is privacy. De gegevens die bevraagd worden bevatten privé-data zoals, namen, adressen en BSN’s. Is de voortdurende bevraging ervan gerechtvaardigd, vooral als een zaak al is afgerond? Het lijkt strijdig met het principe van dataminimalisatie. In plaats van zo min mogelijk gegevens te bevragen worden persoonsgegevens juist vele malen opgevraagd terwijl er geen duidelijke doelbinding is. Nu de bevragingen met een factor zes zijn verminderd is dus ook het aantal bevragingen van persoonsgegevens zesvoudig verminderd. Vanuit het oogpunt van privacybescherming is dit een verbetering.
De datakwaliteit wordt bij dit alles niet aangetast. In het hierboven besproken geval wordt de data iedere keer volledig opgehaald bij de bron, OneGround. De resulterende data in het doelsysteem is op dat moment dus een betrouwbare kopie. Na de aanpassingen werd het aantal bevragingen verminderd maar bleef de hoeveelheid data en daarmee de kwaliteit hetzelfde. De software is dus eigenlijk een stuk slimmer geworden: hetzelfde resultaat met veel minder bevragingen.
Conclusie en vervolgvraag
Ons doel was een eerlijke beprijzing van het gebruik van OneGround. Een onvoorzien effect is dat het prijsmodel heeft geleid tot lagere kosten voor de gemeente en een verbetering van de aansluitende software. Deze casus suggereert dat prijsprikkels invloed kunnen hebben op het ontwerp en gebruik van aangesloten software. Is beprijzing misschien ook te gebruiken om veranderingen actief in een gewenste richting te stimuleren? Te denken valt aan extra hoge prijzen voor opslag en bevraging van privédata. Het effect hiervan kan zijn dat deze data alleen opgehaald worden als het echt nodig is, en daadwerkelijk vernietigd op de archiefactiedatum wat nu vaak niet gebeurt. Een andere toepassing zou kunnen zijn het hoger beprijzen van verouderde API’s, waardoor aangesloten apps sneller overstappen naar nieuwe versies. Een voor iedereen inzichtelijk prijsmodel, vergelijkbaar tussen producten en leveranciers, zou dit mogelijk moeten maken.
Geschreven door Johannes Battjes