Met de komst van Common Ground gaan veel gemeenten opnieuw rond de tekentafel om uit te denken op welke wijze ze de komende jaren hun applicatielandschap willen inrichten. Een flinke verandering, voor zowel de gemeenten zelf, maar zeker ook voor de leveranciers. Vanuit KBenP vinden wij dat wel mooi. De markt is duidelijk in beweging, maar praatjes vullen nog geen gaatjes.
De publicaties over Common Ground schieten als paddenstoelen uit de grond, maar op een simpel verzoek welke leveranciers concreet bezig zijn met Common Ground bij een gemeente blijft het angstvallig stil. Tegelijkertijd zien wij dat gemeenten die nu een aanbesteding starten willen voorsorteren op de ontwikkelingen rondom Common Ground. Sterker nog, het liefst leggen ze het gedachtengoed van Common Ground volledig vast in eisen, iets wat op dit moment nog niet realistisch is. Kortom, de vraag en het aanbod is momenteel uit balans.
Ben je als gemeente al in het bezit van een acceptabel zaaksysteem dan is het plan relatief simpel. Zet de komende jaren naast je huidige zaaksysteem Common Ground initiatieven op om het zaaksysteem te kunnen ‘ontmantelen’ om zo aan te sluiten op de nieuwe Common Ground componenten. De keuze voor moderne losse componenten biedt ook kans om een nieuwe markt van leveranciers aan te boren. Echter hebben deze nieuwe leveranciers ook nog een flinke weg te gaan.
Complexer is het als je binnen afzienbare tijd van je huidige zaaksysteem af moet. Soms omdat de leverancier een andere strategie voor het zaaksysteem gaat voeren (Centric en GreenValley) of omdat de software simpelweg te verouderd is om nog op de juiste wijze te kunnen functioneren. Voor deze groep is de keuze een stuk complexer.
Een andere strategie is om het oude zaaksysteem te laten staan en maximaal in te zetten op Common Ground. Een ambitieus plan en vooral ook lastig omdat binnenkort pas de Zaakregistratiecomponent (ZRC)als eerste component definitief zal worden en het dus onbekend is wanneer alle overige onderdelen van het huidige zaaksysteem vervangen kunnen worden. Bovendien zal het niet gemakkelijk zijn om het oude zaaksysteem aan te laten sluiten op de nieuwe moderne componenten tijdens de transitie.
Wat het nog lastiger maakt is dat als je nu een zaaksysteem hebt van meer dan 10 jaar oud je waarschijnlijk op de markt een modern zaaksysteem in de cloud kan kopen voor de helft van het geld, met twee keer zoveel functionaliteit en nog gebruiksvriendelijk(er) ook. Een andere strategie kan dus zijn om toch het zaaksysteem te vervangen. Bij de verwerving is het dan verstandig flink in te zetten op ‘Common Ground bereidheid’ en samen met de nieuwe leverancier het zaaksysteem de komende jaren steeds meer op Common Ground componenten te laten aansluiten. Helaas zal je dan wel flink moeten vertrouwen op de beloftes van je leverancier, iets waar veel gemeenten nog altijd moeite mee hebben, in sommige gevallen terecht.
Dit bericht heeft 4 reacties
“Maar praatjes vullen nog geen gaatjes” suggereert dat er alleen maar gepraat wordt en dat is zeker niet het geval. Inmiddels zijn de API’s voor Zaakgericht Werken gepubliceerd als release candidate. Naar verwachting worden deze per 1 september definitief als nieuwe standaard. Deze API’s zijn ontwikkeld met gemeenten en leveranciers. De leveranciers zijn al bezig met het inbouwen in hun applicaties. Tijdens een drietal API-labs en twee Fieldlabs konden zij aan de slag met de nieuwe standaard en zijn de eerste serieuze stappen gezet naar integratie. Hetzelfde geldt voor andere Common Ground projecten zoals HaalCentraal en NLX, die hard op weg zijn hun producten gereed voor gebruik te maken.
Daarmee zeg ik niet dat de overgang naar een API-landschap eenvoudig is of snel zal gaan. De beoogde strategie is die van ‘twee sporen’, dat wil zeggen het stapsgewijs (of beter procesgewijs) migreren van de oude applicaties naar de nieuwe applicaties die de vijflagenarchitectuur volgen. Inderdaad zal het niet gemakkelijk zijn om bestaande zaaksystemen aan te laten sluiten op de nieuwe architectuur. Veel zal afhangen van de opbouw van deze applicaties en van de inventiviteit van leveranciers. Sommige leveranciers zullen ervoor kiezen een nieuw product neer te zetten, anderen voor een evolutionaire aanpak. Veel belangrijker is de marktwerking die ontstaat als gemeenten hun leveranciers vragen om een zaaksysteem volgens Common Ground uitgangspunten. En daarbij hoef je echt niet alleen te vertrouwen op de beloftes van leveranciers, maar kun je goede resultaatafspraken maken over de te leveren oplossing(en).
Hugo ter Doest
Product Owner API’s voor Zaakgericht Werken, VNG-Realisatie
Dag Hugo, met die zin refereer ik enkel naar het feit dat veel leveranciers vanalles publiceren over hun betrokkenheid en ambitie, maar dat op ons verzoek geen enkele reactie binnen is gekomen. Dat staat helemaal los van al het werk wat nu wordt verzet.
‘Een ambitieus plan en vooral ook lastig omdat binnenkort pas de Zaakregistratiecomponent (ZRC)als eerste component definitief zal worden en het dus onbekend is wanneer alle overige onderdelen van het huidige zaaksysteem vervangen kunnen worden.’
Volgens mij is het een structurele denkfout om de enige manier van API integratie te zien als een standaard. Dat is exact wat er zo mis is met stuf, en die (doodlopende)weg lijkt VNG nu weer te gaan bewandelen. Applicaties op basis van losse API componenten is niets nieuws, Mozard werkt al jaren op deze manier. Met REST API’s die als componenten prima op Common Ground kunnen aansluiten. De kracht van dat model zit juist in het feit dat REST een architectuur keuze is waarbij je, je richt op acties (componenten bij CG) en niet zo zeer op inhoud (ZGW API standaard) en je daarbij gelaagdheid creëert (die ook niet nieuw is maar bij CG vijflagenarchitectuur heet). Het is niet voor niets dat er voor REST geen bericht ‘standaard’ bestaat, en als je via dat principe ontwikkeld heb je die ook helemaal niet nodig (zie als bewijs daarvoor zo ongeveer alle moderne webapplicaties op het internet). Voor de komst van Common Ground bestond Mozard dus ook al uit die zo gewenste gelaagdheid en componenten (API’s).
Om het dan over voorbeelden te hebben, met de Gemeente Haarlem hebben we een 100% REST gebaseerde API oplossing uitgerold voor de afhandeling van MOR zaken door Spaarnelanden. Dat zijn +-1500 zaken per maand die binnen komen in systeem Haarlem, via componenten behandeld worden in Mozard en vervolgens weer afgehandeld worden door Haarlem waarbij de informatie ten alle tijden actueel is. Daar hadden we helemaal geen ZGW API standaard voor nodig (sterker nog, dat had het waarschijnlijk onnodig complex gemaakt) omdat beide partijen REST API’s spreken en begrijpen.
De vernieuwing van het applicatielandschap juich ik zeker toe. Tegelijkertijd is er het gevaar van oude wijn in nieuwe zakken zolang het oude concept van zaak blijft bestaan. Uiteindelijk gaat het om het verbinden van een product/dienst (know) met een bepaalde afhandelingswijze (flow). Zolang beide aan elkaar geklonken worden als een “zaak” met bijbehorende zaakdossier, blijft het bij het oude. Flexibiliteit ontstaat doordat de inhoudelijke verschillen tussen de producten/diensten worden losgekoppeld van generieke processen. Vervolgens moet dit gekoppeld worden aan het loslaten van het analoge concept dossier (waarbij vooral nog wordt gedacht in termen van het fysieke dossier in de kast). Digitale transformatie ontstaat doordat je niet meer op basis van een analoog concept kijkt. Gegevens met betrekking tot de levering van een product/dienst is dan niet meer dan een query op de actuele of de historische gegevens. Zaakgericht werken wordt als een uniek concept binnen gemeenten beschouwd maar verzekeraars (conceptueel is er geen verschil tussen een aanvraag van een verzekeringsproduct en de aanvraag van een parkeervergunning oid) werken al jaren met ‘dynamic case management’ systemen.
Kortom, zolang er geen fundamenteel andere visie komt op de wijze waarop de gemeentelijke dienstverlening wordt ondersteund middels informatiesystemen, veranderd er niets en zal de balans zich vanzelf weer terugvinden in het oude evenwicht.