Donderdag 7 maart jl. vond in Utrecht een bijeenkomst van VNG plaats over Omnichannel. In verschillende presentaties werd een toelichting gegeven over de relatie tussen Omnichannel en de Wet modernisering elektronisch bestuurlijk verkeer (Wmebv), over de voortgang van MijnZaken en over nieuwe services die ontwikkeld worden onder MijnServices. In dit artikel geef ik een korte samenvatting van die laatste nieuwe services en wat dat voor uw organisatie kan betekenen.

Van de overheid wordt verwacht dat deze meer transparant wordt en is in haar handelen. Burgers en bedrijven vragen om een veilige omgeving van waaruit ze doeltreffende en doelmatige dienstverlening van gemeenten kunnen ontvangen. Met een dienstverlening die op de toekomst is voorbereid en die het vertrouwen in de overheid weer teruggeeft. VNG heeft met een aantal gemeenten en hun leveranciers de handschoen opgepakt en heeft hiervoor MijnZaken ontwikkeld. In een vorig artikel heb ik dit al eens toegelicht. Het aanbod is nu uitgebreid en meer generieke services worden ontwikkeld onder de noemer MijnServices.

Onderstaande afbeelding van de VNG toont de relatie tussen de generieke services en de Wmebv. Door als organisatie de omnichannel kanaalstrategie te omarmen en MijnServices in te zetten, wordt voor een deel ook invulling gegeven aan de Wmebv.

Figuur 1: Programma Omnichannel (bron: VNG)

MijnZaken

MijnZaken was een aparte ontwikkeling, maar is nu als onderdeel van MijnServices gepositioneerd. Deze service is bedoeld om burgers en bedrijven op de hoogte te stellen over de voortgang van een behandeling van een aanvraag. Verschillende gemeenten hebben deze service in hun eigen gemeenteportaal (een MijnOmgeving) geïmplementeerd. Burgers en bedrijven kunnen na inloggen (bijvoorbeeld DigiD) de status van de lopende zaken volgen. Hierbij wordt gebruik gemaakt van de API Standaarden voor Zaakgericht Werken. Zo kunnen zaakgegevens niet alleen in de eigen MijnOmgeving getoond worden, maar kunnen ook opgevraagd worden vanuit MijnOverheid Lopende Zaken.

MijnTaken

Met MijnZaken wordt de dienstverlening meer interactief. Burgers en bedrijven kunnen op elk gewenst moment zelf de status via een portaal opvragen. Maar dat is feitelijk éénrichtingsverkeer. Interactie vanuit de burger naar de overheid wordt daarmee nog niet voorzien. Dat wordt met MijnTaken aangepakt. In de MijnOmgeving kan een taak voor de burger worden ‘klaargezet’. Er kan via de taak bijvoorbeeld een document worden geüpload die nodig is voor de verdere behandeling van een vergunningaanvraag. Dit document wordt gekoppeld aan de zaak en is ook direct in het zaakdossier zichtbaar voor de burger. Eventuele parkeerboetes kunnen ook via een taak worden voldaan.

MijnBerichten

Als de gemeente een aanvraag heeft afgehandeld, volgt daaruit een besluit. Dit besluit moet aan de aanvrager worden uitgereikt. Dat kan via het post-kanaal, maar mag ook via een digitaal kanaal uitgereikt worden als de ontvanger dat heeft aangegeven. Via een bericht wordt kenbaar gemaakt dat de gemeente het besluit heeft genomen en dat het besluit in te zien is via een digitale omgeving. Gemeenten gebruiken hiervoor al de Berichtenbox van MijnOverheid. Om meer invulling te geven aan de omnichannel kanaalstrategie worden berichten ook beschikbaar gesteld via de service MijnBerichten in een MijnOmgeving. Daarmee is het bericht voor de burger via meerdere kanalen in te zien. Het bericht kan ook beschikbaar gesteld kan worden aan (bijvoorbeeld) een KCC-medewerker. Dit levert een completer samengesteld klantbeeld op. Zo kan de medewerker betere dienstverlening aan de balie of telefoon bieden.

MijnContactmomenten

Een burger of bedrijf heeft regelmatig contact met de overheid. Deze contactmomenten worden vastgelegd. Via de MijnContactmomenten service kan de burger zien wanneer er contact heeft plaatsgevonden, via welk kanaal de communicatie heeft plaatsgevonden en waarover contact is geweest. Dit kunnen bijvoorbeeld telefonische contacten zijn, brieven die met de post zijn verstuurd, aanvragen die zijn ingediend, ontvangstbevestigingen die via e-mail zijn uitgegaan of notificaties die per SMS zijn verstuurd. Per zaak kan er een overzicht van contactmomenten worden getoond, maar ook in een totaaloverzicht. Dit is niet alleen nuttig voor de burger, ook de KCC-medewerker heeft hier profijt van. Denk alleen maar aan de betere dienstverlening als de burger aan de balie staat. Ook deze laatste vorm van contact kan trouwens geregistreerd worden.

MijnProfiel

Contactgegevens zijn belangrijk in de interactieve dienstverlening tussen overheid en burger. Welke voorkeurskanalen heeft een burger, wat zijn de contactgegevens? Wil de burger digitale post ontvangen? Waarover wil de burger genotificeerd worden? Deze gegevens kan de burger via de MijnOmgeving zelf vastleggen via de MijnProfiel service. Daarmee krijgt de burger meer regie over interactie met de overheid. Nu zal elke overheidsorganisatie dat nog moeten vastleggen. Mogelijk dat dit in de toekomst een landelijke service wordt. Dan hoeven burgers maar op één plek vast te leggen hoe ze graag met de overheid communiceren en via welk kanaal.

Notificatieservice

Bovenstaande services hebben als doel de interactieve dienstverlening te verbeteren en burgers via digitale omgevingen te voorzien van informatie. Maar hoe weet een burger dat de status van een zaak is veranderd? Of dat er een besluit is genomen en hierover een bericht beschikbaar is? Of dat een taak moet worden afgehandeld? Net als bij de Berichtenbox van MijnOverheid wordt de burger geïnformeerd via een notificatie. VNG, de SVB, gemeenten en leveranciers hebben hiervoor een generieke voorziening ontwikkeld. Op basis van voorkeuren die de burger via de MijnProfiel service heeft aangegeven, wordt een notificatie gestuurd. Voorlopig kan de notificatie alleen via een e-mail of een SMS gestuurd worden. Er worden sjablonen gebruikt die opgesteld zijn om te voldoen aan de Wmebv. Zo is er bijvoorbeeld een handelingsperspectief en een handelingstermijn opgenomen. Ook wordt de notificatie opnieuw verstuurd als blijkt dat de notificatie niet kan worden afgeleverd. Elke notificatie is een contactmoment en wordt dan ook vastgelegd. Zo kunnen burgers (en KCC-medewerkers) zien wanneer en hoe de notificatie is verstuurd.

Nu en in de toekomst

Uit de verschillende presentaties en de beschikbare documentatie  blijkt dat een aantal gemeenten de services al beproefd heeft. Sommige gemeenten bieden ze al in hun MijnOmgeving aan. De MijnServices tonen aan dat verbetering in interactieve, digitale dienstverlening nu al door gemeenten kan worden doorgevoerd. Steeds meer gemeenten tonen interesse en geven aan toegevoegde waarde te zien in de MijnServices.

Naast een steeds grotere samenwerking tussen gemeenten en leveranciers, zien we ook meer samenwerking ontstaan tussen VNG, gemeenten, de rijksoverheid en uitvoeringsorganisaties. Ontwikkelingen die gemeenten initiëren worden mogelijk landelijk opgepakt. Dit zorgt ervoor dat de overheid steeds meer als één overheid zichtbaar wordt. Gemeenten die MijnServices implementeren zijn hierbij de katalysator en dragen zo bij aan een zichtbare, transparante, veilige en betrouwbare dienstverlening. Draagt uw gemeente ook een steentje bij? Ik ga graag met u in gesprek over de mogelijkheden voor uw organisatie.

Meer weten?

Wilt u meer informatie, neem dan contact op met Paul Jansen, adviseur bij Telengy, 06 53 63 93 02, p.jansen@telengy.nl.

Sinds het artikel over ProductDienstStatus heeft er op dit onderwerp een aantal nieuwe ontwikkelingen plaatsgevonden. De pilotgemeenten hebben hard aan de weg getimmerd en als klap op de vuurpijl: het project heeft een andere naam gekregen. Met MijnZaken willen de VNG en de gemeenten duidelijk een sprong voorwaarts maken met een vernieuwende manier van digitale dienstverlening.

Na de hackathon eind april 2022 hebben de deelnemende pilotgemeenten niet stil gezeten. Samen met hun leveranciers hebben ze de ingeslagen weg verder bewandeld en zijn ze tot mooie oplossingen gekomen. Tijdens een druk bezocht VNG-event op 27 september jl. in Utrecht presenteerden de gemeenten hun resultaten. De aanwezigheid van onder andere het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties en Logius geeft wel aan dat het onderwerp binnen de (landelijke) overheid steeds meer aandacht krijgt.

Onnodige contactmomenten

En dat het aandacht krijgt is zeker niet zo gek. Tijdens de deelsessies van de pilotgemeenten is goed naar voren gekomen dat MijnZaken heel mooi aansluit bij een moderne, digitale dienstverlening aan burgers en bedrijven. Met MijnZaken wordt inzicht gegeven in de behandeling van een aanvraag. Uit onderzoek blijkt ook dat burgers hierom vragen. In een voorlopige business case geeft VNG als voorbeeld dat bij de gemeente Den Haag 40% van de telefonische contacten gaan over het vragen naar de status van een aanvraag. En bij de OWO-gemeenten wordt 20% doorgezet naar een vakspecialist omdat niet de juiste informatie direct beschikbaar is. Met MijnZaken kunnen gemeenten (én andere overheidsorganisaties) deze onnodige contactmomenten voorkomen. Onnodige contactmomenten? Jazeker, want de gevraagde informatie is namelijk beschikbaar en kan proactief gedeeld worden met een burger.

API-standaard Zaakgericht werken

MijnZaken maakt gebruik van de API-standaarden voor Zaakgericht werken. Daarmee wordt het niet alleen makkelijker om inzicht te geven in huidige status van de behandeling van een zaak, maar kan ook inzicht gegeven worden in de statussen die nog doorlopen moeten worden. Door ook nog de (te verwachte) doorlooptijden te vermelden bij de statussen, krijgt een burger in één oogopslag de gevraagde informatie te zien: welke stappen zijn er doorlopen, waar is de gemeente nu mee bezig en welke stappen zijn de komende tijd (en wanneer) nog te verwachten. Proactief geïnformeerd dus!

Voordelen

Gemeenten kunnen heel goed gebruikmaken van MijnZaken om hun dienstverlening aan burgers en bedrijven te verbeteren. Door inzicht te geven in de statusinformatie is een gemeente transparant over het behandeltermijn van een aanvraag en ziet een burger wanneer het product geleverd wordt. Daarmee laat een gemeente zien wat ze doet en doet wat ze laat zien. Dat wekt vertrouwen en zorgt ervoor dat de burger de gemeente weer als een betrouwbare overheidsorganisatie gaat zien.

En er zijn nog meer voordelen voor MijnZaken. Er wordt maximaal ingezet op het gebruik van standaarden. Niet alleen om (bron)gegevens via gestandaardiseerde API’s op te vragen, maar ook om gegevens op een standaard manier te presenteren. Bijvoorbeeld door gebruik te maken van NL Design System in een webportaal. Door standaarden te gebruiken kunnen verschillende toepassingen worden ontwikkeld die dezelfde gegevens via andere kanalen beschikbaar stelt. Gemeenten worden zo wendbaarder en kunnen direct inspelen op de behoefte van burgers en bedrijven. In een snel veranderende maatschappij is een gemeente die snel meegaat met die veranderingen bijna een vereiste.

Standaardisatie heeft nog een groot voordeel: gemeenten slaan gegevens op eenzelfde manier op, halen gegevens op eenzelfde manier op en presenteren gegevens op eenzelfde manier. Dankzij het gebruik van standaarden kunnen gegevens tussen overheidsorganisaties ook eenvoudiger aan elkaar beschikbaar gesteld worden. Uiteraard binnen de gestelde eisen voor beveiliging en privacy. Een burger kan zo informatie gebundeld gepresenteerd krijgen in bijvoorbeeld één portaal, terwijl de gegevens door meerdere organisaties geleverd wordt. Burgers hoeven niet meer te ‘shoppen’ maar krijgen antwoord via één organisatie. Gebundeld, begrijpelijk en overzichtelijk. Ze herkennen zo sneller dat ze te maken hebben met een overheid die weet waarover ze het heeft.

Naast de genoemde voordelen voor burgers en bedrijven is er nog een voordeel voor gemeenten. De MijnZaken-functionaliteit wordt veelal gebouwd op basis van open source software. Wat één gemeente heeft gebouwd (of laat bouwen) is deelbaar met andere gemeenten. Eén keer (laten) ontwikkelen, meervoudig gebruiken. Dat is wel zo kostenefficiënt en versnelt de innovatie binnen een gemeente.

Uw zaak?

MijnZaken draagt bij aan een overheid waar vertrouwen van uitgaat, die veilig gegevens beschikbaar stelt, toekomstgerichte dienstverlening biedt, doeltreffend omgaat met toegankelijke communicatie(middelen) en doelmatig omgaat met informatieverstrekking. Zorgt u ervoor dat MijnZaken uw zaak wordt?

Meer weten?

Wilt u meer informatie over wat MijnZaken inhoudt en wat het voor uw organisatie kan betekenen,  neem dan contact op met Paul Jansen, adviseur bij Telengy, 06 53 63 93 02, p.jansen@telengy.nl.

Burgers en bedrijven die producten of diensten afnemen van gemeenten, kunnen vaak het verloop van de afhandeling daarvan niet volgen. Gemeenten bieden namelijk niet altijd een Persoonlijke Internet Pagina of een MijnGemeente portaal aan. En als die wél aan burgers en bedrijven wordt aangeboden, is de informatie veelal summier en niet altijd toereikend. VNG heeft samen met een aantal gemeenten ProductDienstStatus gelanceerd: de publieke variant van de commerciële Track&Trace. Real-time en kanaalonafhankelijk statusinformatie opvragen over zaken die een burger of bedrijf bij een gemeente heeft lopen.

Vanuit het programma Omnichannel is een referentiearchitectuur opgesteld waarin ProductDienstStatus (PDS) is uitgewerkt. De basis hiervoor betreffen de API-standaarden voor Zaakgericht Werken die het bestuur van de VNG al per 1 april 2021 volgens het principe ‘pas-toe-of-leg-uit’ als standaard heeft verklaard. De referentiearchitectuur is uitgewerkt volgens de 5-lagen van de informatiekundige visie Common Ground en past zo prima in de ontwikkelingen die momenteel binnen de overheid plaatsvinden. Uitgangspunt hierbij is dat zowel burgers en bedrijven als de medewerker van de gemeente over dezelfde informatie beschikken. Gegevens kunnen via verschillende kanalen bij de bron worden opgevraagd. Een burger gebruikt hiervoor bijvoorbeeld een webpagina of een app terwijl een medewerker van de gemeente een procesapplicatie tot zijn of haar beschikking heeft.

Van StUF naar API

Maar gemeenten kunnen toch al statusinformatie over zaken opvragen en beschikbaar stellen? Er is toch al een standaard die hierin voorziet? Dat klopt, maar de StUF-standaard wordt niet meer doorontwikkeld en staat innovatie en snelle aanpassingen aan nieuwe (klant)behoeften in de weg. De API-standaard voor Zaakgericht Werken is eenvoudiger te implementeren en de techniek (gebruik van API’s) wordt over de gehele wereld toegepast.

Hackathon

In de week na Pasen heeft een aantal gemeenten tijdens een 4-daagse hackathon PDS beproefd. Gemeenten hebben samen met hun leveranciers oplossingen bedacht en ontwikkeld om aan te tonen dat het verstrekken van statusinformatie over zaken op een nieuwe en innovatieve manier mogelijk is. Bovendien is aangetoond dat de implementatie van de oplossing relatief snel te realiseren is.

MijnOmgeving Den Haag

De gemeente Den Haag had de focus gelegd op het tonen van statusinformatie in een MijnOmgeving. Via de interface (gebaseerd op NL Design System) van de MijnOmgeving kunnen burgers en bedrijven nu het verloop van hun aanvraag volgen en krijgen ze inzicht in de processtappen die de gemeente nog moet uitvoeren. Met de introductie van substatussen krijgt een burger of bedrijf rijkere informatie aangereikt waardoor (naar verwachting) onnodige telefoontjes naar het KCC worden voorkomen.

Open Webconcept Buren

Dat nieuwe ontwikkelingen gebaseerd op Common Ground makkelijk door andere gemeenten overgenomen kunnen worden, heeft gemeente Buren aangetoond. Door de code van de gemeente Den Haag te (her)gebruiken en aan te passen naar hun eigen ‘couleur locale’ heeft de gemeente Buren in een paar dagen tijd een eigen MijnOmgeving ingericht. Dit is de basis voor verdere uitbreiding van hun digitale dienstverlening en een mooie toevoeging op het Open Webconcept.

Hybride StUF en API OWO-samenwerking

De OWO-samenwerking (gemeenten Ooststellingwerf, Weststellingwerf en Opsterland) wilde aantonen dat hun huidige, StUF-gebaseerd zaaksysteem aangepast kon worden naar de nieuwe API-standaard voor Zaakgericht Werken. Beide standaarden blijven in gebruik (het Common Ground principe Nieuw naast Oud) zodat gefaseerd en in eigen tempo de nieuwe standaard in gebruik genomen kan worden. Bestaande procesapplicaties die nog StUF gebruiken, blijven op die manier functioneren en procesapplicaties die al API-gebaseerd werken, kunnen dan ook de statussen van zaken opvragen.

Medewerkersportaal Tilburg

Gemeente Tilburg heeft een proef gedaan vanuit het perspectief van de medewerker. Vanuit een medewerkersportaal (CRM-systeem) wilde de gemeente Tilburg meerdere zaaksystemen bevragen. Dit zijn niet alleen StUF-gebaseerde zaaksystemen, maar ook API-gebaseerde zaaksystemen. Er is een mechanisme bedacht die het mogelijk maakt om via één API-bevraging meerdere zaaksystemen met verschillende koppelvlakstandaarden te benaderen.

Toekomstig gebruik

Tijdens de demo’s op de laatste dag van de hackathon is gebleken dat er in een relatief korte tijd mooie resultaten door de gemeenten en hun leveranciers zijn behaald. De komende maanden werken de gemeenten samen met hun leveranciers de ideeën en oplossingen verder uit en worden testomgevingen ingericht. In een gecontroleerde pilotomgeving wordt ervaring opgedaan en getoetst of deze nieuwe functionaliteit aansluit bij de behoefte van de burger, bedrijf of medewerker. De verwachting is dat volgend jaar de gemeenten PDS in productie gaan nemen. Het idee is om vanaf 2023 bij veel meer gemeenten de PDS-functionaliteit te implementeren.

Als u als gemeente nu al aan de slag wilt met PDS, hoeft u niet tot volgend jaar te wachten. Veel componenten zijn (in de basis) al beschikbaar. Een aantal leveranciers biedt al zaaksystemen aan die voldoen aan de API-standaard voor Zaakgericht Werken. Ook leveranciers die Persoonlijke Internet Pagina’s of MijnGemeente componenten aanbieden, werken soms al met de nieuwe standaard. En tot slot zijn er genoeg leveranciers die integratiesoftware leveren om alle componenten met elkaar te verbinden.

Meer weten?

Wilt u meer informatie over wat ProductDienstStatus inhoudt en wat het voor uw organisatie kan betekenen, neem dan contact met me op. Ik vertel u er graag meer over: Paul Jansen, adviseur bij Telengy, 06 53 63 93 02, p.jansen@telengy.nl.

Bij de start van Common Ground werd al gezegd dat de transformatie en transitie van ‘oud’ naar ‘nieuw’ een langere tijd in beslag zou nemen. Minstens 10 jaar. Inmiddels zijn we (bijna) 5 jaar verder en is er veel gebeurd. Gemeenten hebben de handschoen opgepakt en zijn samen met leveranciers software gaan ontwikkelen. Nieuwe leveranciers zagen kansen en zijn vanuit eigen ideeën nieuwe oplossingen gaan ontwikkelen. En vanuit de (landelijke) overheid komen meer standaarden beschikbaar. Dan rijst de vraag: stap ik nu in de trein of kan ik nog rustig op het perron blijven wachten op de volgende trein?

In mijn vorige artikel over Common Ground ben ik ingegaan op het tempoverschil van aanpassingen aan informatiesystemen. Men zou verwachten dat nieuwe, innovatieve software de 5 lagen van Common Ground volledig heeft geïmplementeerd. En dat logge, traditionele systemen nog een eerste stap moeten zetten. Dat lijkt inderdaad zo, maar schijn bedriegt. Ook traditionele software wordt inmiddels aangepast. In dit artikel beschrijf ik een aantal interessante landelijke ontwikkelingen.

ZGW-componenten

Eén van de eerste Common Ground-ontwikkelingen waren de nieuwe componenten voor Zaakgericht Werken. De verouderde StUF-standaard is verlaten en een nieuwe standaard is ontwikkeld conform de landelijke API-strategie. De specificaties van deze standaard zijn al geruime tijd gepubliceerd. Een groeiend aantal leveranciers adopteert de nieuwe standaard inmiddels. En niet alleen leveranciers maar ook gemeenten zijn er al actief mee. Zo bouwt de gemeente Den Haag samen met een aantal andere gemeenten een MijnOmgeving dat gebruik maakt van de ZGW-componenten en nog een aantal Open Source Softwarecomponenten. En de gemeente Súdwest-Fryslân heeft zelf een voorziening gebouwd om nog ‘oude’ systemen te kunnen koppelen aan de nieuwe ZGW-componenten: de Open Zaakbrug.

Haal Centraal

Systemen met basisregistraties zijn precies die traditionele systemen die een langzaam verandertempo kennen. Het is daarom goed om te zien dat er veel nieuwe standaarden ontwikkeld worden rondom de basisregistraties. Verschillende softwarecomponenten kunnen op die manier gegevens bij de bron ophalen waardoor het kopiëren van de basisgegevens voorkomen wordt. Vanuit het programma Haal Centraal worden er API’s ontwikkeld voor de ontsluiting van gegevens uit de BRP, BAG, BRK, BGT, WOZ en het Handelsregister. Een aantal grote gemeenten (waaronder Amsterdam en Den Haag) experimenteren intern al met het gebruik van de nieuwe BRP Bevragen API. En de Rijksdienst voor Identiteitsgegevens (RvIG) voert een pilot uit met deze nieuwe manier van persoonsgegevens ontsluiten.

Verwerkingenlogging

Het verwerken van persoonsgegevens moet natuurlijk aan de AVG voldoen. Een gemeente moet kunnen verantwoorden dat persoonsgegevens op een juiste, rechtmatige en transparante wijze zijn verwerkt. Om te voorkomen dat de vastlegging van verwerkingen van persoonsgegevens bij overheidsorganisaties op verschillende wijze wordt uitgevoerd, ontwikkelt VNG Realisatie een nieuwe standaard: de Verwerkingenlogging API-standaard. Leveranciers als Centric en PinkRoccade Local Government hebben al interesse getoond in deze nieuwe standaard. De verwachting is dan ook dat ze de nieuwe standaard in hun systemen gaan implementeren zodra de definitieve, stabiele versie wordt gepubliceerd.

Ontwikkelagenda API-standaarden

“Leuk!” hoor ik u denken. “Maar welke standaarden worden er nu ontwikkeld en vanaf wanneer kan ik die van leveranciers eisen?” De nieuwe standaarden die door VNG Realisatie ontwikkeld worden, volgen een standaardisatieproces. Ook standaarden of API’s die door gemeenten zijn ontwikkeld en zijn aangedragen aan VNG Realisatie volgen deze stappen. Een compleet overzicht van standaarden (die bij VNG Realisatie bekend zijn) is gepubliceerd op GEMMA Online onder het menu Standaarden. Naast een korte omschrijving van de API is ook de status te lezen. Als je meer informatie over een specifieke API wilt, kun je deze inwinnen via de bij de API vermelde contactpersoon.

Demodam

Zoals u kunt lezen is er al veel beschikbaar en wordt er nog veel ontwikkeld. Maar werken de nieuwe softwarecomponenten en de nieuwe API’s wel allemaal met elkaar samen? Doet het wat het moet doen? Die vraag heeft een aantal leveranciers zichzelf ook gesteld. Via de website van de fictieve gemeente Demodam wordt aangetoond dat de dienstverlening daadwerkelijk kan plaatsvinden op basis van verschillende, losse componenten die ontwikkeld zijn vanuit de informatiekundige visie Common Ground. Het is zeker de moeite waard om eens een bezoek te brengen aan de website van deze gemeente en te ontdekken wat er nu al mogelijk is.

Instappen of wachten?

Bovenstaande voorbeelden geven aan dat er de afgelopen jaren veel is ontwikkeld en dat leveranciers de informatiekundige visie Common Ground inmiddels omarmen. Een groot aantal standaarden en bijhorende API’s is al beschikbaar en klaar om geïmplementeerd en toegepast te worden. Enkele gemeenten gebruikt ze al in productie of staat aan de vooravond van implementeren. Common Ground staat niet meer in de kinderschoenen maar is langzaam volwassen aan het worden. En hoewel voor sommige gemeenten de trein wellicht op het punt staat te vertrekken, een volgende trein arriveert zo. Stap in, reis mee en ontdek een nieuwe wereld!

Meer weten?

Wil je weten welke mogelijkheden er zijn en hoe je deze nieuwe ontwikkelingen kunt uitvragen bij leveranciers, neem dan contact op met Paul Jansen, adviseur bij Telengy, via tel. nr. 06 53 63 93 02, p.jansen@telengy.nl.

Het jaar 2021 staat in het teken van aansluiten op het DSO-LV, implementeren en testen. Met onderstaande ontwikkelingen kunt u rekening houden.

Gezamenlijke route 2022

Komend jaar staat er veel op de rol voor de inwerkingtreding van de Omgevingswet. Een goede planning voor implementatie helpt daarbij. Alle organisaties die bij de invoering van de Omgevingswet betrokken zijn, hebben samen een roadmap opgesteld: Route 2022.

Twee concrete ontwikkelingen beschrijft Paul Jansen in het kort:

Samenwerkingsfunctionaliteit

Er komt vanuit het DSO-LV meer functionaliteit beschikbaar om vanuit uw eigen VTH-systeem te kunnen gaan samenwerken met andere organisaties. Door hierop (technisch) aan te sluiten, kunt u samen met de organisaties in uw regio beoordelen of er nog afspraken gemaakt moeten worden, of er in de eigen organisatie nog aanpassingen doorgevoerd moeten worden en of de informatievoorziening op orde is.

Register Externe Veiligheid

Het huidige Risicoregister Gevaarlijke Stoffen wordt per 1 januari 2022 vervangen door een nieuw register: Register Externe Veiligheid (REV). Gemeenten zullen via een aanleverportaal of direct via API’s gegevens moeten gaan aanleveren aan dit landelijke register. Verwacht wordt, dat begin 2021 de specificaties van het bestandsformaat wordt opgeleverd. Dan pas is bekend welke gegevens een gemeente exact moet aanleveren en in welke vorm dat moet gebeuren. De gegevens in het REV worden uiteindelijk ook gebruikt in de viewers van de Omgevingswet. Ga in gesprek met uw leverancier om te vragen hoe zij u met hun software kunnen ondersteunen bij het aanleveren van de gegevens aan het REV.

Meer weten?

Voor meer informatie kunt u contact opnemen met Paul Jansen, adviseur bij Telengy, via tel. nr. 06 53 63 93 02, p.jansen@telengy.nl.

Onderstaande ontwikkelingen zullen beschikbaar worden gesteld aan gemeenten op het gebied van het GEMMA Gegevenslandschap en Common Ground. Een toelichting door Telengy-adviseur Paul Jansen.

Verwerkingsactiviteiten en Verwerkingenlog

Om te kunnen voldoen aan de AVG, wordt gewerkt aan een standaard voor het vastleggen van verwerkingen die zijn uitgevoerd op persoonsgegevens. Inmiddels zijn de eerste uitwerkingen van het Verwerkingenlog op Github gepubliceerd en wordt gemeenten en leveranciers gevraagd een review te geven. Elke applicatie dat persoonsgegevens verwerkt moet uiteindelijk deze Logging API implementeren. Leveranciers en gemeenten kunnen vanaf 2021 de implementatie hiervan gaan starten. Samenhangend hiermee wordt ook gestart met het opstellen van de specificaties voor een gemeentelijk Verwerkingsactiviteiten register. De verwachting is dat ook deze in 2021 beschikbaar gesteld gaat worden door VNG Realisatie.

Zaakgericht Werken

Sinds november 2019 zijn de API-specificaties en bijhorende componenten voor Zaakgericht Werken beschikbaar. Vanaf 2021 komt daar minimaal een Verzoeken register bij. Gemeenten kunnen losse verzoeken die burgers of bedrijven bij een gemeente indienen, als zodanig registeren zonder dat er gelijk een Zaak voor wordt aangemaakt. Aanvullend worden ook de specificaties van een Contactmomenten register en een Klanten register opgeleverd. De Zaakgericht Werken componenten vormen daarmee een goede basis voor Ominchannel dienstverlening waardoor gemeenten vanaf 2021 een nog betere dienstverlening kunnen gaan bieden. Ga in gesprek met uw leverancier om te bepalen wanneer deze functionaliteit voor u beschikbaar komt.

Omnichannel

Op 8 december 2020 heeft VNG Realisatie tijdens een inspiratiedag de handreiking voor de Omnichannel dienstverlening gepresenteerd. Het geeft gemeenten een praktische invulling in de aanpak naar een goede Omnichannel strategie. Er is ook een referentiearchitectuur opgesteld die gemeenten kunnen gebruiken in het inrichten van hun informatievoorziening. In 2021 wordt de referentiearchitectuur verder uitgebreid met verschillende implementatievoorbeelden, specifiek voor kleine tot grote gemeenten en van een geringe tot uitgebreide strategie implementatie.

Meer weten?

Voor meer informatie kunt u contact opnemen met Paul Jansen, adviseur bij Telengy, via tel. nr. 06 53 63 93 02, p.jansen@telengy.nl.

De informatiekundige visie ‘Common Ground’ is bij menig gemeente inmiddels wel bekend. Veel gemeenten en leveranciers zijn al een tijd actief in het ontwikkelen van nieuwe oplossingen en het implementeren van nieuwe standaarden. Bij zowel gemeenten als leveranciers is het duidelijk dat deze beweging niet meer te stoppen is. Langzaam wordt duidelijk wat deze nieuwe opzet van de informatiehuishouding voor een organisatie gaat betekenen. Niet alleen de manier van ontwikkelen is nieuw voor een organisatie, ook de implementatie van de nieuwe componenten en het beheer hiervan gaat veranderen.

In een serie van 3 artikelen bespreekt Telengy-adviseur Paul Jansen de ontwikkelingen van Common Ground. Hij legt uit wat de 5 lagen van Common Ground nu eigenlijk echt inhouden, gaat in op de transitie en verschillende migratievarianten die mogelijk kunnen worden doorgevoerd en ook wordt het effect van Common Ground op de rol van de beheerder besproken. In dit derde artikel: de transitie en migratie van applicaties.

De 5 lagen

Weet u het nog? In mijn artikel van 29 januari beschreef ik de 5 lagen van Common Ground. Daarin heb ik per laag uitgelegd wat ermee bedoeld wordt. Een aantal gemeenten timmert hard aan de weg met het bouwen van nieuwe componenten op deze lagen. Ook leveranciers zijn druk bezig met het implementeren van nieuwe standaarden en oplossingen. En dan hoor ik u hardop afvragen: “Maar hoe passen die nieuwe ontwikkelingen dan in mijn bestaande applicatielandschap? Hoe sluit ik mijn software aan op de nieuwe standaard? Wat moet ik aan mijn leverancier vragen als ik met Common Ground aan de slag wil?” In dit artikel noem ik enkele stappen die u zou kunnen nemen.

Pace Layered Model

Niet elke applicatie verandert op dezelfde manier en op dezelfde snelheid. Gartner plaatst informatiesystemen De eerste categorie applicaties (Systems of Record) hebben een lage verandersnelheid. Dit zijn bijvoorbeeld informatiesystemen die de uitvoering van wettelijke taken ondersteunen waarbij het proces grotendeels hetzelfde blijft. De tweede categorie applicaties (Systems of Differentiation) zijn specifiek voor een organisatie en kennen een middellange levenscyclus. Deze applicaties worden opnieuw bijvoorbeeld met een nieuw proces ingericht om te voldoen aan de veranderende behoefte van de organisatie. De laatste categorie applicaties (Systems of Innovation) spelen in op de onmiddellijke behoefte van een organisatie en hebben vanwege hun vluchtigheid een beperkte levensduur.

Ambitie

Als u een applicatie gaat aanpassen of vervangen en dat in lijn wilt brengen met de informatiekundige visie van Common Ground, is het zeker de moeite waard om te kijken in welke categorie uw applicatie valt. Een applicatie in de categorie Systems of Record zal waarschijnlijk minder eenvoudig aangepast kunnen worden naar de 5-lagen indeling. Een nieuwe app voor burgers die een specifieke informatiebehoefte invult en geen gegevens uit andere systemen nodig heeft zal wel ontwikkeld kunnen worden op basis van verschillende componenten op de 5 lagen. Het is belangrijk dat u daarin (samen met uw leverancier) bepaalt wat uw ambitie hierin is en hoeveel tijd en geld u hiervoor beschikbaar heeft.

Adoptiecurve

In het gesprek met uw leverancier moet u bepalen welke wijzigingen u wilt doorvoeren. Springt u van de kelder gelijk op het dak of gaat u met de trap via elke etage naar boven? Om u hierbij te helpen heeft VNG Realisatie een document[1] gepubliceerd waarin het Globaal Programma van Eisen wordt besproken. In het document staat een adoptiecurve met 6 niveaus vermeld die een groeipad aangeven naar een applicatielandschap volledig gebaseerd op de 5 Common Ground lagen. Ik licht deze niveaus hieronder kort toe.

Ik ga uit van een beginsituatie waarin er sprake is van een silo en er geen scheiding is in 5 lagen. Dit is niveau 0. Een minimale eerste stap is het kunnen opvragen van de gegevens in de silo via een API. Dit is niveau 1. De leverancier moet daarvoor de applicatie wel aanpassen. Op die manier kunnen andere applicaties de gegevens al raadplegen, blijven gegevens bij de bron en hoeven deze niet meer te worden gekopieerd naar andere applicaties. Idealiter is dit gerealiseerd via een gestandaardiseerde API. Mocht er (nog) geen standaard beschikbaar zijn, laat dan de leverancier minimaal de specificaties van de API publiceren.

Als de gegevens niet alleen bij de bron kunnen worden opgevraagd, maar ook kunnen worden gemuteerd via een (gestandaardiseerde) API, dan praten we over niveau 2. Het kunnen muteren van gegevens is een grotere aanpassing omdat allerlei interne checks (t.b.v. consistentie op data) uitgevoerd worden voordat een wijziging (in de database) wordt doorgevoerd. Vanaf dit niveau wordt het al mogelijk om interactie op de opgesloten gegevens te kunnen uitvoeren via andere applicaties.

Een uitgangspunt in het GEMMA Gegevenslandschap[2] is dat een leverancier zelf ook gebruik maakt van zijn aangeboden API’s. Oók als het gaat om de gegevens in zijn eigen applicatie. Als een applicatie de gegevens alleen nog via API’s gaat bevragen, is niveau 3 bereikt.

Vanaf niveau 4 wordt uitgegaan dat er een gestandaardiseerd informatiemodel is waarop de API’s worden ontwikkeld en gebruikt. Dit informatiemodel is zeker ook gewenst bij niveau 1, 2 en 3. De focus bij de eerste 3 niveaus ligt echter op het kunnen ontsluiten van de gegevens en er geen data lock-in meer bestaat, terwijl niveau 4 echt uitgaat van een gestandaardiseerd informatiemodel en gestandaardiseerde API’s die landelijk afgestemd en gebruikt worden.

De volgende stap is het doorvoeren van de scheiding van de processen (laag 4) en de (gebruikers)interface of interactie (laag 5). Processen die eerst in de silo zijn opgeslagen kunnen nu ook via andere gebruikersinterfaces worden toegepast. Een aanpassing aan het proces wordt zo integraal doorgevoerd in alle interactie. Met deze laatste actie is de ‘oude’ silo opgeknipt in 5 lagen gebaseerd op de informatiekundige visie Common Ground.

Een volgende stap is het combineren van de verschillende componenten die op de 5 lagen beschikbaar zijn gesteld. Daarmee kunt u een ‘eigen’ toepassing samenstellen aan de hand van uw behoefte en vraag naar dienstverlening. Dit kan worden gezien als niveau 6.

Meer weten?

De niveaus uit de adoptiecurve geven een groeipad aan waarlangs een applicatie kan evolueren naar een gelaagde toepassing. Afhankelijk van uw gestelde ambitie, beschikbare tijd en geld kunt u een keuze maken naar welk niveau u uw applicatie wilt aanpassen of (laat) ontwikkelen.

Wilt u weten welke mogelijkheden er voor u zijn en hoe u een dergelijk traject zou kunnen aanvliegen, neem dan contact op met Paul Jansen, adviseur bij Telengy, via tel. nr. 06 53 63 93 02, p.jansen@telengy.nl.

[1] https://www.gemmaonline.nl/images/gemmaonline/1/1b/GEMMA_Gegevenslandschap_-_Globaal_Programma_van_Eisen_v1.0.pdf

[2] https://www.gemmaonline.nl/images/gemmaonline/5/56/GEMMA_Gegevenslandschap_-_Beschrijving_informatiearchitectuur.pdf

De informatiekundige visie ‘Common Ground’ is bij menig gemeente inmiddels wel bekend. Veel gemeenten en leveranciers zijn al een tijd actief in het ontwikkelen van nieuwe oplossingen en het implementeren van nieuwe standaarden. Bij zowel gemeenten als leveranciers is het duidelijk dat deze beweging niet meer te stoppen is. Langzaam wordt duidelijk wat deze nieuwe opzet van de informatiehuishouding voor een organisatie gaat betekenen. Niet alleen de manier van ontwikkelen is nieuw voor een organisatie, ook de implementatie van de nieuwe componenten gaat veranderen. Vergeet tot slot niet het beheer hiervan.

In een serie van drie artikelen bespreekt Telengy-adviseur Paul Jansen de ontwikkelingen van Common Ground. Paul legt uit wat de vijf lagen van Common Ground nu eigenlijk echt inhouden, gaat in op de transitie en verschillende migratievarianten die mogelijk kunnen worden doorgevoerd. Ook wordt het effect van Common Ground op de rol van de beheerder besproken. In dit tweede artikel: de rol van de functioneel beheerder.

Losse componenten

In het vorige artikel heb ik de vijf lagen van Common Ground besproken. Daarin heb ik aangegeven dat wanneer men een ‘silo’ splitst in vijf lagen, meerdere componenten ontstaan. Dit is in eerste instantie een horizontale opdeling. Echter kan ook iedere laag verticaal verder worden uitgesplitst.

Door deze verticale splitsing vormen er nog meer componenten. Zo ontstaat een soort matrix met verschillende componenten die allemaal een eigen functionaliteit bevatten. Hoe groter de opdeling, hoe meer losse componenten er zullen ontstaan. Meer componenten geeft een gemeente meer flexibiliteit om sneller aanpassingen door te voeren aan de informatievoorziening. Echter, meer componenten maken het totale landschap ook complexer. Dit vraagt om meer inzicht en overzicht van de gebruikte componenten. Er ontstaan vragen als:

• Voldoet een component nog wel aan de gewenste functionaliteit, of missen we bepaalde functionaliteit?
• Past een vervangend component wel goed in het bestaande geheel?
• Aan welke eisen en wensen moet een component voldoen?
• Met welke componenten kan een vraag vanuit de business worden beantwoord?

Vragen die verschillende expertises binnen een ICT-organisatie kunnen beantwoorden.

BiSL en Common Ground

Mijn collega Arno van Waesberghe heeft in november 2019 een artikel geschreven over een aanpak bij de transitie van functioneel beheer. Arno ging vooral in op de ondersteuning bij de verandering van de Functioneel Beheerder. Ik bespreek in dit artikel de meer inhoudelijke verandering van de taken, natuurlijk in de relatie tot Common Ground.

Over de rol van de functioneel beheerder is al veel geschreven. Het meest bekende raamwerk hiervoor is Business Information Services Library (BiSL). Hierin staan beschrijvingen van de taken, verantwoordelijkheden en bevoegdheden die bij de rol van de functioneel beheerder horen. In dit artikel bespreek ik enkele taken die door het toepassen van Common Ground naar mijn mening zullen worden geraakt.

Het artikel gaat door onder de afbeelding.

Gebruikersbeheer

Eén van de taken bij gebruikersbeheer, is het aan de ene kant contact onderhouden met de verschillende leveranciers en specialisten, en aan de andere kant de gebruikers. Storingen die door een component optreden worden vaak door gebruikers gemeld. Leveranciers zullen deze storingen verhelpen. Vanwege de vele (verschillende) componenten kunnen er bij deze storingen veel leveranciers betrokken zijn. De functioneel beheerder moet goed weten welk component door welke leveranciers geleverd wordt, zodat snel en adequaat een oplossing kan worden gezocht.

Wijzigingenbeheer

Wijzigingsverzoeken die vanuit de organisatie worden aangedragen, moeten worden beoordeeld op de impact daarvan. Enkele belangrijke vragen die de functioneel beheerder zichzelf stelt:

• Op welk component heeft de wijziging betrekking?
• Hoe groot is die wijziging?
• Verandert het proces niet of juist heel ingrijpend?

Doordat meerdere losse componenten worden gebruikt, moet per component waarop de wijziging betrekking heeft een impactanalyse komen. Omdat de wijziging vaak gerelateerd is aan een bepaalde functionaliteit, blijft het aantal componenten dat bekeken moet worden beperkt. Een impactanalyse op het volledige informatiesysteem is niet meer nodig.

Functionaliteitenbeheer

Bij het gebruik van een silo worden functionele specificaties voor de gehele applicatie opgesteld. Met het toepassen van Common Ground worden meerdere specifieke componenten gebruikt die hun eigen specificatie kennen. De functioneel beheerder moet goed weten welke specificaties er geëist worden aan een component, passend bij de functie waarvoor het component wordt ingezet. Het totaal aan componenten geeft dan een overzicht van de functionaliteiten die nodig zijn om een bepaalde business vraag te kunnen beantwoorden. Het onderhouden van dit overzicht en inzicht is een groeiende taak van de functioneel beheerder.

Met het beschikbaar komen van verschillende componenten, wordt het eenvoudiger om nieuwe samenstellingen te vormen. Hierdoor kan sneller ingespeeld worden op de behoefte van de business. De nieuwe samenstelling kan leiden tot een andere werking van het geheel of wordt nieuwe functionaliteit toegevoegd. Door het vluchtige karakter van samenstellingen moeten handleidingen sneller aangepast worden zodat deze weer aansluiten bij de werking van de (nieuwe) componenten.

Arno geeft in zijn artikel aan dat voor een functioneel beheerder de rol van adviseur meer aandacht gaat vragen. Dit zie je vooral terug in het beschrijven van de processen. De gewenste functionaliteit wordt immers aangestuurd vanuit processen. De relatie tussen (deel)processen en functionaliteiten krijgt bij het toepassen van Common Ground veel meer aandacht. Procesmodellen kunnen lezen en maken op basis van een standaard modelleertaal (zoals BPMN) wordt steeds belangrijker. Op basis van zijn of haar kennis van de beschikbare (losse) functionaliteiten, kan de functioneel beheerder aangeven hoe en welke (deel)processen het beste met welke functionaliteit ondersteund kunnen worden. Hierbij treedt de functioneel beheerder als adviseur op naar zijn collega’s.

Behoeftemanagement

De veranderende behoeften van dienstverlening richting burgers, bedrijven en instellingen zorgen ervoor dat organisaties in beweging blijven met hun dienstverlening. De ondersteunende middelen moeten hierin ook meebewegen. Common Ground maakt het mogelijk dat de beweging ook sneller gemaakt kan worden. Functioneel beheerders zullen daarom meer dan eerst de behoeften van de organisatie in kaart moeten brengen en afstemmen met de mogelijkheden die beschikbaar zijn of komen. Hierin ligt ook een relatie naar het functionaliteitenbeheer waarin bekeken wordt welke eisen en wensen gesteld worden aan bepaalde functionaliteit. Dit moet aansluiten bij de behoeften die een organisatie stelt. De functioneel beheerder heeft hier een belangrijke rol in.

Uitdaging

Zoals uit bovenstaande blijkt, ligt er voor de functioneel beheerder een mooie uitdaging om de nieuwe ontwikkelingen van Common Ground te ondersteunen. De functioneel beheerder van de toekomst krijgt een belangrijke rol in de afstemming tussen wat een organisatie aan veranderende behoeften heeft en hoe daarop snel kan worden ingespeeld. Dit met de beschikbare functionaliteiten die door losse componenten wordt geboden. Waar in het verleden de nadruk lag op het beheren van één pakket, verschuift de aandacht naar meerdere componenten. Is uw functioneel beheerder al op de hoogte van zijn veranderende rol?

Meer weten?

Voor meer informatie kunt u contact opnemen met Paul Jansen, adviseur bij Telengy, via tel. nr. 06 53 63 93 02, of e-mail: p.jansen@telengy.nl.