Tijdens de vorige sessie bespraken we de onderstaande figuur die het proces weergeeft van het aanvraagformulier:
+
Tijdens de eerste werkgroep bespraken we de onderstaande figuur die het proces weergeeft van het aanvraagformulier:
[[Bestand:Citerra slide 1 wg 2.jpg|geen|miniatuur]]
[[Bestand:Citerra slide 1 wg 2.jpg|geen|miniatuur]]
−
Vandaag staan we stil bij het informatieplatform:
+
Bij de tweede werkgroep stonden we stil bij het informatieplatform:
[[Bestand:Citerra slide 2 wg 2.jpg|geen|miniatuur]]
[[Bestand:Citerra slide 2 wg 2.jpg|geen|miniatuur]]
−
+
−
+
Vandaag
−
Hierbij willen we scherp stellen wat de verwachtingen zijn over een platform.
==Brainstormsessie==
==Brainstormsessie==
Regel 89:
Regel 88:
===Doel===
===Doel===
Het doel van de brainstormsessie is het volgende:
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
+
*Zicht krijgen op hoe het overkoepelde platform het toekenningsproces verbeteren?
*Oplijsten van databronnen waaruit je de informatie kan halen, welke applicaties en functieprofielen je nodig hebt
*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
*Inzicht krijgen in wat je moet kunnen doen met de data
Regel 95:
Regel 94:
*
*
−
===Oefening 1+2===
+
===Oefening 1===
====Instructies====
====Instructies====
Bij deze oefeningen stonden we stil bij de volgende vragen:
Bij deze oefeningen stonden we stil bij de volgende vragen:
|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====
====Discussie====
−
* Besluitvorming over Vergunningen: Vaststellen van criteria voor vergunningsverlening en hoe deze criteria toe te passen om eerlijke en consistente beslissingen te waarborgen.
+
*
−
* Handhaving van Autoluwe Zones: Effectieve methoden voor handhaving, inclusief technologische systemen en menselijke handhaving, en hoe deze het beste kunnen worden geïmplementeerd en gecoördineerd.
−
* Automatisering van Aanvraagprocessen: Verminderen van administratieve lasten door het automatiseren van aanvraagprocessen en het verkennen van mogelijkheden voor efficiënte en gebruikersvriendelijke systemen.
−
* Toegang voor Derde Partijen: Overwegingen omvatten hoe informatie over autoluwe zones beschikbaar kan worden gesteld aan derde partijen zoals navigatie-apps, met aandacht voor privacy en veiligheid.
−
* Gebruiksvriendelijkheid van Aanvraagprocessen: Discussie focust op het verbeteren van de gebruiksvriendelijkheid van aanvraagprocessen om de drempel voor aanvragers te verlagen, mogelijk door middel van begeleiding en ondersteuning.
−
* Automatische Goedkeuring en Weigering van Vergunningen: Overwegingen betreffen de criteria en procedures voor automatische goedkeuring of weigering van vergunningen, en hoe dit kan bijdragen aan een efficiënter proces.
−
* Uniformiteit en Standaardisatie: Bespreking van de voordelen en uitdagingen van het standaardiseren van processen en informatie over autoluwe zones voor alle steden en gemeenten in Vlaanderen.
−
* Uitzonderingen en Flexibiliteit: Behandelen van uitzonderingen op het vergunningsbeleid en het integreren van flexibiliteit om maatwerk mogelijk te maken voor specifieke situaties.
−
* Noodzakelijke Databronnen: Er werd gesproken over het identificeren van databronnen die nodig zijn voor het vergunningenaanvraagproces, zoals gemeentewebsites, LBD (Lokale Producten Catalogus), Gis (Geografisch Informatiesysteem), e-government, Rijksregister, KBO (Kruispuntbank van Ondernemingen), CP (Contactpunt), etc.
−
* Automatisering van Vergunningsaanvragen: Er was discussie over het automatiseren van vergunningsaanvragen en hoe dit kan worden ondersteund door relevante databronnen, zoals het gebruik van machineleesbare besluiten en standaardisatie van processen.
−
* Signalisatieplannen en Besluitvorming: Er werd opgemerkt dat signalisatieplannen belangrijk zijn voor het bepalen van autoluwe zones en dat deze informatie moet worden gekoppeld aan besluitvormingsprocessen voor vergunningen.
−
* Lokale versus Federaal Databeheer: Er was discussie over het verschil in benadering tussen grote steden en kleinere gemeenten wat betreft het beheer van lokale vergunningendatabases en de mogelijke rol van federale instanties in het faciliteren van toegang tot deze data.
−
* Datamodellen en Lokale Centrales: Er werd gesproken over het ontwikkelen van datamodellen en lokale centrales om kleinere gemeenten toegang te geven tot relevante informatie, met een focus op het delen van gegevens tussen verschillende niveaus van bestuur.
−
* Applicaties en tools voor gegevensbeheer: Er wordt gesproken over verschillende tools en applicaties die worden gebruikt om gegevens te ondersteunen en te sturen, zoals Eldes voor linked data event streams.
−
* Centrale vindplaats voor informatie: Deze applicatie is bedoeld om informatie over besluiten van verschillende gemeenten te centraliseren en beschikbaar te stellen voor machines, mogelijk met behulp van gestandaardiseerde protocollen.
−
* Vendors en gemeentelijke applicaties: Er wordt verwezen naar de applicaties van zowel externe leveranciers als de gemeenten zelf, die mogelijk al informatie publiceren op gestandaardiseerde wijze.
−
* Gebruik van API's en centrale vindplaats: Er wordt besproken hoe een centrale vindplaats het gebruik van API's kan verminderen, maar toch mogelijk nog beperkte API-functionaliteit vereist voor specifieke taken.
−
* Burgerprofiel en notificaties: Er wordt gesproken over het gebruik van burgerprofielen en notificaties voor statusupdates van aanvragen of dossiers.
−
* Solid en persoonlijke datakluis: Er wordt overwogen hoe Solid en persoonlijke datakluisconcepten kunnen worden toegepast op de behandeling van persoonsgegevens, met inachtneming van GDPR-vereisten.
−
* Simulatietool en standaardisering: Er wordt gesproken over het gebruik van simulatietools en het belang van standaardisering in het proces.
|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<BR>generieke info_txt<BR>Voorwaarden_txt_xml<BR>Couleurlocal_parameters_txt_xml<BR>Attesten.pdf_xml<BR><BR>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<BR>* Behouden in applicaties en opvragen<BR>* Centraal behouden Citerra<BR>* uploaden wallet, solid <BR>* Ondernemersloket<BR>* Rechstreeks in eigen erp van leveranciers<BR>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
−
|}
−
==== Discussie ====
==== Discussie ====
−
* Definiëren van benodigde data en acties: De discussie richtte zich op het identificeren van alle relevante data en acties die nodig zijn voor het informatieplatform.
+
*
−
* Beheren en hergebruiken van aanvragen en vergunningen: Gesprek over de benodigde functionaliteit voor het beheren van aanvragen en vergunningen, inclusief opties zoals aanpassen, verwijderen en archiveren.
−
* Integreren van verschillende soorten data: Overwegingen bij het integreren van diverse data in formulieren en het gebruik van een centrale API voor gegevensverzending.
−
* Valideren van data volgens een bekend datamodel: De discussie betrof het valideren van data volgens een vastgesteld datamodel dat consistent is voor lokale besturen.
−
* Vaststellen van data-eigenaarschap: Gesprek over wie verantwoordelijk is voor de data die op het platform staat om duidelijkheid te scheppen over verantwoordelijkheden.
−
* Opzetten van een payment gateway: Overwegingen bij het implementeren van een payment gateway voor efficiënte betalingen bij vergunningsaanvragen.
−
* Thematische vergunningsconcept van de Vlaamse overheid: Bespreking van het concept van thematische vergunningen en hoe dit kan worden toegepast voor automatische identificatie van vereiste vergunningen bij verschillende verplaatsingen.
−
* Overwegen van verschillende benaderingen voor authenticatie: Discussie over de mogelijke benaderingen voor authenticatie, met de nadruk op HTTP-technologie als een mogelijke optie met externe systemen.
|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 ====
==== Discussie ====
−
* Lokale invulling versus automatisatie: Hoe lokale aanpassingen de automatisatie kunnen belemmeren omdat standaardisatie moeilijker wordt. Dit kan leiden tot hogere kosten voor automatisering.
+
*
−
* Scope van het platform: Er is onduidelijkheid over de reikwijdte van het platform. Moet het een centraal platform zijn voor alle vergunningsaanvragen in Vlaanderen, of eerder een open platform waar verschillende integratoren en oplossingen kunnen worden gebruikt?
−
* Financiering en businessmodel: Hoe wordt de financiering verdeeld en wat is het businessmodel voor de verschillende spelers? Dit omvat ook de vraag of het platform commerciële belangen moet dienen of juist moet focussen op open data.
−
* Integratie en schaalbaarheid: Het platform moet niet alleen voor autoluwe zones werken, maar ook schaalbaar zijn voor andere vergunningsaanvragen en gebruiksscenario's.
−
* Operationele veiligheid: Zorgen over de beveiliging van endpoints en het voorkomen van onbedoelde blootstelling van gevoelige informatie, zoals wie welke vergunningen aanvraagt.
−
* Governance en duurzaamheid: Het creëren van een duurzaam governancemodel voor het platform en ervoor zorgen dat het platform dynamische aanpassingen kan doorvoeren zonder de stabiliteit in gevaar te brengen.
−
* Inclusiviteit en acceptatie: Het belang van het betrekken van alle belanghebbenden om de waarde van het platform te maximaliseren en ervoor te zorgen dat het breed wordt geaccepteerd en gebruikt.
==Opname en Miro bord==
==Opname en Miro bord==
===Miro bord===
===Miro bord===
−
Het Miro bord kan je consulteren via [https://miro.com/app/board/uXjVKH1mtDo=/?share_link_id=83948339969 deze link].
+
Het Miro bord kan je consulteren via [https://miro.com/app/board/uXjVK4zi_MU=/?share_link_id=516119999518 deze link].
===Opname===
===Opname===
−
De opname van deze sessie is te bekijken via [https://www.youtube.com/watch?v=1jTBbqOzufo deze link].{{Video|Url=https://www.youtube.com/embed/b_DwSZCCCqg?si=8ubN_1R7n4_t2nTL""}}
+
De opname van deze sessie is te bekijken via [https://www.youtube.com/watch?v=b_DwSZCCCqg deze link].{{Video|Url=https://www.youtube.com/embed/b_DwSZCCCqg?si=8ubN_1R7n4_t2nTL""}}
Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur. In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix.
De derde thematische werkgroep vond plaats op 25 juni 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:
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 eerste werkgroep bespraken we de onderstaande figuur die het proces weergeeft van het aanvraagformulier:
Bij de tweede werkgroep stonden we stil bij het informatieplatform:
Vandaag
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 hoe het overkoepelde platform het toekenningsproces verbeteren?
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
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
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
Discussie
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
