VlocaSessie/45

Functionele werkgroep

Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de functionele noden en interacties. Na de data- en informatiewerkgroep zijn deze respectievelijke noden helder geworden. Deze functionele werkgroep bouwt hierop verder om de data- en informatie-uitwisseling tussen mensen en systemen, mensen onderling en systemen onderling te schetsen.

De tweede thematische werkgroep vond plaats op 16 mei 2024.

Context

Initiatief

In samenwerking met Mobiliteit en Parkeren Antwerpen en de Stad Antwerpen werkt VLOCA (Vlaamse Open City Architectuur) samen met OSLO (Open Standaarden voor Linkende Organisaties) aan een City of Things project genaamd "Citerra". Citerra staat voor 'City Environmental Regulations and Rights for Access' voor steden, gemeenten, bedrijven, burgers, verenigingen en overheden , en heeft als doel de link te leggen tussen de genoemde stakeholders en de lokale regelgeving.

Het doel van Citerra is om alle regelgevingen te centraliseren en te uniformeren, waarbij de aanvragen voor vergunningen kunnen worden ingediend. De focus van dit City of Things traject ligt op vergunningen voor autoluwe zones of gebieden met cameratoezicht. Hoewel de Stad Antwerpen het project leidt, is het de bedoeling om dit initiatief breder te zien richting alle lokale besturen.

Op dit moment is de informatie over verschillende gereglementeerde zones in de stad niet goed georganiseerd, wat het voor burgers en bedrijven moeilijk maakt om te begrijpen welke regels waar van toepassing zijn. Het handmatig invullen van persoonlijke gegevens bij herhaalde aanvragen leidt ook tot frustratie. Om dit te verbeteren, streeft het project ernaar gebruikers zelf hun profiel te laten beheren, inclusief het toevoegen van extra nummerplaten, en om gegevens automatisch in te vullen bij nieuwe aanvragen. Bovendien voldoet het project aan de Europese Commissie Directive over "Intelligent Transport Systems" door steden te verplichten Urban Vehicle Access Rights (UVAR) data naar het Europese Platform te uploaden, wat geautomatiseerd zal verlopen.

VLOCA

VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders.

VLOCA-model

De start van elk VLOCA-traject begint bij een VLOCA-model:

ID	Samenvatting	Beschrijving
UC1	UC1: Registratie	Registratie
UC2	UC2: Informatieplatform	informatie platform en zoek opdrachten
UC3	UC3: Profiel & Formulier aanvullen	Profiel aan- en formulier invullen
UC4	UC4: Indiening	Indienen aanvraag
UC5	UC5: Opvolging dossier	opvolging dossier
UC6	UC6: toekenningsproces	toekenning, weigering, betwisting, advies aanvraag
UC7	UC7: dossierbeheer	beheer dossier (overzicht, toevoegingen, verlengingen, aanpassingen, herinneringen, …)
UC8	UC8: Message Center	CRM voor communicatie (uitgaande/inkomende, contact strategie en historiek)
UC9	UC9: Helpdesk	helpdesk & FAQ & Reviews
UC10	UC10: betaalmodule	betaalmodule en business model vinden en bouwen
UC11	UC11: Monitoring	Monitoring en analytische rapportering incl fraudedetectie
UC12	UC12: Inzichten	Rapporting BI Dashboards en Inzichten
UC13	UC13: Duurzaamheid	Van een piloot tot een 'operationeel' draaiende applicatie en platform

Tijdens de vorige sessie bespraken we de onderstaande figuur die het proces weergeeft van het aanvraagformulier:

Vandaag staan we stil bij het informatieplatform:

Hierbij willen we scherp stellen wat de verwachtingen zijn over een platform.

Brainstormsessie

Het doel en de aanpak van de brainstormsessie worden hieronder beschreven. Tevens wordt de uitkomst van de brainstorm hierin samengevat.

Doel

Het doel van de brainstormsessie is het volgende:

• Zicht krijgen op welke data/informatie we nodig hebben om een antwoord te bieden aan de nood aan efficiëntie/tijdwinst en effectiviteit/optimalisering door middel van een centraal informatieplatform
• Oplijsten van databronnen waaruit je de informatie kan halen, welke applicaties en functieprofielen je nodig hebt
• Inzicht krijgen in wat je moet kunnen doen met de data
• Valkuilen identificeren

Oefening 1+2

Instructies

Bij deze oefeningen stonden we stil bij de volgende vragen:

1. Welke data/informatie hebben we nodig om een antwoord te bieden aan de nood aan efficiëntie/tijdwinst en effectiviteit/optimalisering door middel van een centraal informatieplatform?

Voorbeeld:

- Wetgeving van lokale besturen

2. Uit welke databronnen haal je deze informatie? Welke data is reeds beschikbaar (gratis of betalend)? Welke moeten we zelf gaan verzamelen? Hoe doen we dit? Welke applicaties (tools die je gaat gebruiken) heb je nodig om de databronnen te sturen/ondersteunen? Welke functieprofielen heb je hiervoor nodig?

Voorbeeld:

- Wetgeving van een lokaal bestuur bevindt zich  in een lokaal intern systeem

Output

Data	Databronnen	Applicaties/tools	Functieprofielen
Bestaande vergunningen	Standardisatie model/Uitbreidingen huidig model: voorwaarde van een goeie databron OSLO	vendors/applicaties van de gemeenten: veel vendors van de gemeentes hebben deze info al gepubliceerd (assumptie)	data
hoe wordt omgegaan met oa. hulp diensten / stad gemeenten (zit in de reglementen)	publicaties gemeentes (www)	loket.lokaalbestur	modelleerder met kennis besluiten / reglementen / OSLO
welke steden hebben welke vergunningen	vergunningenlijst per lok. bestuur	centrale vindplaats: applicaties die info en besluiten van de verschillende gemeentes centralisseerd ( lopend traject) - lokale gemeentes zouden dit ook kunnen gebruiken en minder zwaar  ipv API individueel maar er blijven beperkte API's	juridische dienst - LB-en
Contact gegevens van steden en gemeenten	Besluiten/Regelgeving	LDES: data ter beschikking stellen, op verchillende manieren query end point. Zorgt data data kan doorstromen	Mobiliteits dienst - LB-en
welke steden hebben welke systemen voor handhaving: steden hebben verdwijnpalen, andere gebruiken polities enzo - Kan ook zijn dat je badge nodig hebt naast vergunning	LPDC: Vlaanderen (catalagus def per gemeente)		agile team: po, pm, analist, dev,...)
regels/voorwaarden voor vergunning/stad	CRAB: adrespunt bepalen binnen polygoon	Bouwblokken waarmee oslo data worden gestuurd - door digitaal vlaanderen ontwikkeld	business user (lokaal bestuur)
GIS informatie autoluwe zones	GIS databronnen: polygonen, sommigen straten vallen er net in of uit ->  validatie		OSLO team standaard government
venstertijden: ter info als je geen vergunning nodig hebt want je kan uw houden aan de venstertijden	eGOV? - Wallet	Vrijer manier om data te consumeren	Leveranciers aanvraagsystemen: integraties en koppeling voorzien
welke steden hebben  autoluwe zones	DIV (voertuigen) via MAGDA		Beheerder/stad
waar liggen de autoluwe zones	Adressenregister /CRAB	Database gaat reproduceren bij wijzigingen  automatisch.  bv adressen enkel de wijzigen krijg je door zonder API call	IT verantwoordelijke voor support
EID/ITSme	MAGDA		Beheerder overkoepelend
Ondernemersloket	RRN via Magda IT20/IT19 (rijksregister op basis hiervan krijg je de domicile en huis)		testusergroup
Burgerprofiel	KBO via Magda
Kostprijs om vergunning aan te vragen	soc. nr en geldigheid zorgverstrekker VIA MAGDA (automatische vergunningen)	Burgerprofiel op header/notificatie / document niveau: aanvraag moet door goedkeuringproces ze een notificatie krijgen voor status en vergunning wordt opgeladen bij akkoord
wat kost een vergunning?	Vlaamse codex	SOLID? Persoonlijke data kluis -> gdpr -> Aligneren met die vlaamse bouwblok
Alternatieve Routes: visuele tip	LBLOD gepubliceerde reglementen en besluiten  (lokale belsuiten - machine leesbare kijken naar standaard - per bestuur gepubliceerd en Vlaanderen gaat dit ook verzamelen )	Simulatie tool
Informatie in verschillende talen	RIZIV	standaardisering
Overzicht regelgeving over gans Vlaanderen van de verschillende steden , europese, vlaamse, ... (Vlaamse codex)	DIV (via magda)	Citerra
simulatie van wat wel of niet mag na invoering van tijd en plaats - op basis van aangegeven tijstip en locatie de relevante info krijgen	signalisatie plan: voetgangersgebied - borden laten besluiten in gemeenteraad. Eersta stap om tot besluit komen waar komen de borden -> automatisch besluit
Machine readable policy: beleidsmatig best vertaald worden naar regels die door computer vertaald kunnen worden
Doorlooptijd aanvrager + VTEs (volgorde van belangrijkheid voor process automatisatie te bepalen - werkkracht die achter een bepaald proces moeten worden gezet => om zo makkelijk te zien waar je tijdswinst kan halen door optimaliseren of automatiseren) overheid	Visualiseren op basis van signalisatieplan (impact autoluwe zone) - maar vergunning pas toegekend als werken zijn uitgevoerd
Toegang voor derde partijen zoals navigatie applicaties	lokale vergunningen
Abstracties	database (voor kleinere steden/gemeentes niet makkelijk om API te voorzien) federaal? -> binnen ABB bezig om dit bechikbaar te maken voor lokale besturen . Lokale bron voor kleinere steden
& geconnecteerde delen (bv bewonersparkeren aantal vergunning is dynamsich - afhankelijk van de bewoners moet er parking voorzien worden en kan er geen vrije bewonerskaarten meer voorzien worden voor de bewoners van het app, bouwheer moet parking voorzien vooe gebouw ) identificeren -> automatisatie	FOD FAS
dummy aanvraagmodule: veel mensen willen oefenen voor ze een aanvraag officieel indienen. Kan ook via video's	authenticatie / authorisatie
heb ik eigenlijk wel een vergunning nodig? of ben ik vrijgesteld?	data space
soorten vergunningen	mobiliteit
Aanvraag via nummerplaat of op aanvrager opvolgen?
regel
Wat is kost retributie bij handhaving
Bulkaanvragen op basis van Asterix nummerplaten ( vaste serie van nummerplaten zoals politie bv)
voertuiggegevens

Oefening 3

Instructies

Wat moet je kunnen doen met de data? Welke acties kan je identificeren qua databeheer?

Voorbeeld:

-Je brengt de wetgeving van de verschillende lokale besturen samen

Output

Databeheer & integratie

overschrijven van unieke bron gegevens (met label aangepast): bv domicile manueel overschrijven en aangeven dat dit niet een authentieke bron maar nieuwe info is

leesbare_txt generieke info_txt Voorwaarden_txt_xml Couleurlocal_parameters_txt_xml Attesten.pdf_xml types data die beschikbaar moeten zijn en samengevoegd moeten worden in een formulier

samenvoegen van data in formulier en dan alles samen doorsturen. 1 API met alle mogelijke velden maar niet alles noodzakelijk ingevuld afh van vereisten stad ( 1 API met alle mogelijke velden (moet niet allemaal ingevuld zijn) en niet per leverancier)

beheren van aanvragen en vergunningen (hergebruiken/editeren en deleten of archive)

verlengen van aanvraag/vergunning

oslo datamodel

bestaande data capteren: 3 elementen door slimme lokaal bron te genereren

bestaande data gestandaardiseerd herbruikbaar delen

een omgeving waar lokale data aangemeld kan worden ifv citerra: verschillende toepassingen waar de vergunningen zitten ter beschikking stellen aan citerra (data vindplaats)

besluitdata vertalen in machineleesbare data (verdere detaillering

Voertuigen, 200 numemrplaat aanvragen leveranciers registreren in Citerra of op vind plaats zelf? Mogelijkheden * Behouden in applicaties en opvragen * Centraal behouden Citerra * uploaden wallet, solid * Ondernemersloket * Rechstreeks in eigen erp van leveranciers Bulk aanvragen in XML

Bulkoplading moet mogelijk zijn

bewaren van data voor meerdere aanvragen/opnieuw aanvragen van vergunning

gemeente moet business rules kunnen updaten

tijdelijk bewaren van data/onafgewerkte aanvraag

payment gateway: centraal systeem betalingen - hoe 1 keer afrekening en juist doorbetale,n naar de verschillende steden, diensten

QA (quality assurance)

Data ownership ( bewerkingen die gebeuren moeten gelinkt worden aan de bewerker -> welke stad dienst heeft vergunning geweigerd: transparentie & opvolging)

CMS met sync naar dependent & dependencies: vanuit centrale platform vergunning aangevraagd worden, zal er iets van database aan dit platform en sync moeten zitten/ BV leverancier en je moet door de 2 zones rijden, eerste goedkeuring en tweede weigering -> relevante info moet terug komen van 1 van de vragen. Dus er moet een link zijn - om de link te houden => Duidelijk vermelden aan aanvrager om dit mee te delen

valideren volgens het data model (SHACL): als gemeente iets pubiceerd dans moet je nakijken of data correct is.

tergukoppeling indieen validatie faalt

Oefening 4

Instructies

Hoe gaan we om met de verschuiving van aanvragen die rechtstreeks verlopen via de website van de lokale besturen naar een overkoepelend medium? Wat zijn mogelijke valkuilen?

Voorbeeld:

- Integratie van verschillende systemen en databronnen kan technisch uitdagend zijn

- Financiering verdeling over de verschillende lokale besturen

Opname en Miro bord

Miro bord

Het Miro bord kan je consulteren via deze link.

Opname

De opname van deze sessie is te bekijken via deze link.

Volgende stappen

Wat na deze werkgroep?

1. Verwerking van de input van de brainstorm oefening.
2. Verder onderzoek en voorbereiding van de volgende thematische werkgroep.
3. Publicatie op de Kennishub

Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be

Andere werkgroepen

Werkgroep	Type werkgroep	Datum	Tijd	Locatie
Business werkgroep	Business werkgroep	2024-02-27	13u-16u	VAC Antwerpen
Thematische werkgroep 1	Data en informatie werkgroep	2024-03-28	13u-16u	Teams
Thematische werkgroep 2	Functionele werkgroep	2024-05-16	13u-16u	Teams
Thematische werkgroep 3	Technologie werkgroep	2024-06-25	13u-16u	Teams