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:
- 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 |
Discussie
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
Output
| Valkuilen |
| teveel couleur locale, te weinig standaardisatie |
| LLM (language model - machine leesbaar) is geen oplossing, kan als hulpmiddel gebruikt maar niet als tool, validator zelf |
| AI voor reglementen kan een mw zijn , nog onderzoeken wat de mogelikheden zijn |
| 'lokale invulling' vs automatisatie en kost: hoe meer vrijheid dat je toelaat hoe minder kans tot automatisatie waar trek je de lijn |
| Scope Vlaanderen is beperkt (subsidie), generiek maken door bv aanvrager geeft aan of hij/zij al dan niet Vlaams is |
| gesloten platform?: nog niet duidelijk of er 1 platform wordt gebouwd voor heel Vlaanderen of worden alle blouwblokken ter beschikking gesteld. Open platform waar iedreen kan integreren. Scope nog niet duidelijk |
| Toeliching: scope autoluwe zone, nog open of het 1 platform wordt, platform waat alle vergunningen naast elkaar staan en 1 specifieke kunt aanvragen voor autoluwezone. Breder maken nog geen zicht maar mogelijkheden |
| niet starten met een duidelijke scope en timing voor poc |
| uptime platform moet maximaal zijn: moet kunnen voldoen aan piekdagen/uren als zondag bv |
| integriteit van de databronnen |
| niet-schaalbaarheid naar andere use-cases |
| aanpassingen LPDC ivm parametrisatie door Vlaanderen nodig: hoeveel nummerplaten aanvragen per burger bv in een generieke formulier ztten dat kan ingevuld zijn per stad/gemeentes. Nu zijn het enkel tekstvelden nu niet beschikbaar |
| Governance voor duurzaamheid van platform |
| te vaak dynamische aanpassingen nodig nadien / stabiliteit : niet te veel wijzigingen in regels van steden |
| te moeilijk dus eigen websites blijven: formulier te complex -> dan gaan ze toch naar de algemene stad site en gaat het niet gebruikt worden ( vraag komt van ondernemingen) |
| stad/gemeente of leverancier van aanvraagsysteem die niet wil meedoen |
| niet alle steden en gemeentes hebben een aanvraagsysteem |
| Uitsluiting van bepaalde steden geeft minder waarde aan dit project |
| cyber security |
| financiering bouw of business model |
| Uitdagingen: Datamodel, intelligentie van data |
| iedereen meekrijgen |
| commerci le belangen vs open data: veel bronnen aangehaald en deel ervan zijn open data of worden open data -> commerciele spelers meekrijgen. bv Parking die in autoluwe zone ligt |
| lokale specificiteit vs generieke regelgeving |
| opsec: operational security. End points voorzien voor handhaving voor ophalen en syncen van vergunningen gaan bepaalde zaken publiek zijn. bv qr code waar persoon makkelijk kan nagaan - OPSEC is deel waar wordt gekeken dat er info ook niet ge-expoded kan zijn. Info die je niet met concurrentie wilt delen |
| onderhoudskost |
Discussie
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?
- Verwerking van de input van de brainstorm oefening.
- Verder onderzoek en voorbereiding van de volgende thematische werkgroep.
- 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 |