Deze pagina biedt een eenvoudige bladerinteractie voor het vinden van entiteiten met een eigenschap met een bepaalde waarde. Andere beschikbare zoekinteracties zijn de zoekpagina voor pagina-eigenschappen en de querybouwer.

Lijst van resultaten

• Impact  +
• Impact van repair op CO2 uitstoot  +
• Impactmap Genk  +
• Impactmap Gent  +
• Impactmap van het project sterke authenticatie van Gent - GZG  +
• InfluxDB [1] ↑ https://en.wikipedia.org/wiki/InfluxDB  +
• Informatie  +
• Inleiding Intro  +
• Inloggen  +
• Inloggen Inloggen  +
• Ik wil data van een watersensornetwerk geb … Ik wil data van een watersensornetwerk gebruiken (data broker vraagzijde) </br> Opvragen </br> </br> Data opvragen technisch gezien kan best verlopen via:</br> </br> API op database </br> subscription op een data broker </br> Momenteel zijn er verschillende bronnen waar water gerelateerde data kan opgevraagd worden. </br> </br> waterinfo </br> geopunt </br> Curiezeneuzen bodem(vocht) - in verwachting </br> </br> </br> Analyseren (machine learning, AI, data science, …) </br> </br> Data pipeline concept </br> Bij het verwerken dan data in de brede zin (vanaf hier "data analyse" genoemd) is het belangrijk de data analyse als een pipeline te beschouwen. Data start als een ruw object, wordt code-matig bewerkt tot een meer verwerkt data object, en eindigt na verschillende stappen als een finaal product dat meerwaarde geeft tov het originele ruwe data object.</br> </br> Codematig data behandelen </br> Het is belangrijk dat de data verwerking code matig gebeurd. Editeer geen excel files met de hand, programeer dit proces.</br>Ruwe data mag niet overschreven worden, sla deze apart op, en laat een script een nieuwe versie van dit bestand maken na bewerking ervan.</br> </br> Project structuur </br> Eens data analyse code matig gebeurd, is er nog altijd het risico dat de transparantie van de code verloren gaat na een tijd, beschouw volgende gedachtegangen tijdens een data analyse project:</br> Was het nu make_figures.py, make_figures_working.py or new_make_figures01.py om de figuren te plotten? </br> Moet ik read_process.py eerst lopen of is clean_data2.py het eerste script om te laten lopen? </br> Indien de code niet gestructureerd bijgehouden wordt, gaan na verloop van tijd zulke vragen de transparantie van de analyse ondermijnen.</br> Hoe kan dit opgelost worden? Er zijn verschillende project management structuren om je code in te gieten. Eentje hiervan is Cookie Cutter . [1] Het volgen van deze structuur kan de pijn al enigszins verlichten.</br> </br> Configuratie files </br> Eens er een goede structuur is, kan het lopen van verschillende analyses best ook gestructureerd worden obv een configuratie file. Een configuratie file kan je zien als een bestand dat allerlei verschillende processen bijhoudt, en de bijhorende parameters oplijst die gebruikt werden om een bepaald process te laten lopen. Zo'n configuratie file zou er als volgt kunnen uitzien:</br> </br> </br> </br> </br> </br> </br> Voorbeeld 1 configuratie file data analyse</br> </br> </br> </br> </br> </br> </br> Voorbeeld 2 configuratie file data analyse</br> </br> </br> </br> </br> Deze configuratie file kan gebruik worden om obv één naam (in deze 2 voorbeelden "first_sim" en "second_sim") een volledige keten van analyses te definiëren en te laten lopen.</br>Er zijn verschillende velden die de data bronnen specifieren. In deze 2 voorbeelden worden er 2 verschillende machine learning modellen gebruikt. Voorbeeld 1 gebruikt een suipport vector machine, voorbeeld 2 een neuraal netwerk.</br>Er wordt ook genoteerd welk script gebruikt wordt voor het plotten van figuren.</br> Uiteraard kan dit zo ver uitgebreid worden als wenselijk, maar dit geeft een idee hoe een data pipeline degelijk gedocumenteerd kan worden.</br> </br> Data oplevering = data + metadata </br> Indien er data gedeeld of opgeleverd wordt, is het aan te raden om niet enkel de data maar ook methodes en parameters mee te geven.</br>In volgend draaiboek worden suggesties gedaan hoe dit best gebeurd: Hoe deel ik mijn data? </br> </br> Online vs offline learning </br> Notebooks </br> Notebooks dienen in de eerste plaats voor data exploratie en communicatie. Vermijd het gebruik van notebooks als single point of truth's. Refereer in notebooks naar functies die in de source code van het project gedefinieerd zijn.</br> </br> Environment + requirements file </br> Om data analyse reproduceerbaar te maken, wordt sterk aangeraden om de data analyse te laten beginnen vanuit een requirements file die specificeert welke packages (en versienummer) gebruikt werden.</br>Voor elk project wordt best een unieke omgeving (environment) aangemaakt, zodat er geen conflicten ontstaan tussen verschillende projecten.</br>Het is standaard om in python - data science projecten een requirements.txt file te voorzien in de root van de repository, die je via de command line kan opgeroepen via:</br> pip install -r requirements.txt indien pip gebruikt wordt</br> conda install --file requirements.txt indien conda gebruikt wordt</br> Meer info over conda hier .</br>Meer info over pip hier .</br> </br> Version control </br> Het is sterk aangeraden om de code die de data analyse stuurt te opslaan en bijhouden in een repository met version control.</br>Dit laat toe om een gedocumenteerde geschiedenis van alle wijzigingen bij te houden, waarop later naar terug gegrepen kan worden.</br> Meer info over een populair version control system: git .</br> </br> Visualiseren (dashboard, …) </br> </br> Er zijn een groot aantal verschillende opties om water data te visualiseren en te communiceren.</br>Het belangrijkste voor VLOCA is dat de data eerst beschikbaar is en correct, de visualisatie ervan kan makkelijk volgen.</br> Enkele guidelines voor het visualiseren van data, en de keuze van de geschikte visualisatie (in python): https://www.python-graph-gallery.com/matplotlib/ </br> Enkele opties voor het opzetten van dashboards in Python en R (open source):</br> </br> https://plotly.com/dash/ (zie ook Dash GitHub - (R, Python, Julia, .NET) </br> https://rstudio.github.io/shiny/tutorial/ </br> Dash is het meest gedownloadede Python framework om machine learning en data science apps/dashboards op het web te bouwen.</br>Deployment kan o.a. via Heroku </br> </br> </br> ↑ https://drivendata.github.io/cookiecutter-data-science/#analysis-is-a-dag-dag  +
• Ik wil de data van een watersensornetwerk … Ik wil de data van een watersensornetwerk beheren </br> Ik wil de data bewaren (keuze databank, backups, toegangscontrole,…) </br> </br> Hoe houden we gestructureerd data bij? Voor aanbevelingen, zie volgend draaiboek. </br> Voor de keuze van een database, zie volgend draaiboek. </br> </br> Ik wil de data ontsluiten voor anderen (data broker aanbodzijde) </br> </br> Hoe deel ik mijn data?dzijde) Hoe deel ik mijn data?  +
• Imec ontstaat in 1984 als onafhankelijk on … Imec ontstaat in 1984 als onafhankelijk onderzoekscentrum voor micro- en later nano-elektronica. Het doel is om alle academische kennis rond chiptechnologie in Vlaanderen te bundelen. Want die technologie is de motor voor de derde industriële revolutie – en daarmee voor de blijvende welvaart van de regio. Sinds 2016 is ook iMinds (voorheen IBBT), het strategische onderzoekscentrum van Vlaanderen op het gebied van digitale innovatie, onderdeel van imec. Daardoor vind je bij imec vandaag zowel soft- als hardware onder één dak, en ligt de focus zowel op het internationale als Vlaamse terrein. Imec start vanuit het geloof in duurzame innovatie die kan mogelijk gemaakt worden door gebruik te maken van technologie. </br> Meer informatie kan hier gevonden worden, alsook op de Wikipedia pagina .ikipedia pagina .  +
• In april 2018 keurde de Vlaamse Regering h … In april 2018 keurde de Vlaamse Regering het Besluit voor Collectieve Kennisverspreiding en Collectief Onderzoek en Ontwikkeling (COOCK) goed. COOCK-projecten [1] hebben als doel kennis en prototypes die recent werden ontwikkeld in de schoot van onderzoeksinstellingen over te dragen naar een ruime groep van ondernemingen. Agentschap Innoveren & Ondernemen ( VLAIO ) wil hiermee het effectief toepassen van innovaties in de ondernemingswereld stimuleren en versnellen.</br> </br> </br> </br> </br> Dit project wil collectieve inzichten rond de ontsluiting van Standaarden en data voor een open ‘gedataficeeerde’ maatschappij in het domein van omgeving en milieu vertalen en implementeren, wat de realisatie van een visie rond een ‘open stad’ zal versnellen. Meer info is te vinden op de specifieke web pagina's van IMEC [2] en [[ VITO ]] [3] . De deelnemende kennisinstellingen zijn universiteit van Antwerpen, universiteit van Gent, [[ VITO ]] en IMEC .</br> Gezien de synergie tussen de kennis die beschikbaar gesteld wordt binnen Coock Open Stad en VLOCA, zal deze kennis ook via deze kennishub-pagina verspreid worden.</br> </br> </br> Overzicht Collectieve Workshops </br> </br></br> </br> Workshop Datum </br> Topic </br> Organisatie </br> Registratielink </br> Meer informatie</br> </br> </br> 12/01/2021 </br> Smart Towards a high quality living environment - a pioneering role for Flanders </br> UGent-Waves, IMEC -Waves </br> </br> Registratie </br> </br> </br> </br> Meer informatie </br> </br> </br> </br> 02/02/2021 </br> Connecting, storing and publishing sensor data </br> IMEC -IDLab Antwerpen </br> Registratie </br> Meer informatie </br> </br> </br> 09/02/2021 </br> Open City and its Citizens </br> IMEC -SMIT </br> Registratie </br> Meer informatie </br> </br> </br> 23/02/2021 </br> Publishing and using sensor data as linked open data </br> IMEC -IDLab Gent </br> Registratie </br> Meer informatie </br> </br> </br> 09/03/2021 </br> IoT and Air Quality in Cities part 1 - Air Quality Sensing </br> VITO & IMEC -NL </br> Registratie </br> Meer informatie </br> </br> </br> 23/03/2021 </br> IoT and Air Quality in Cities part 2 - Air Quality Mapping </br> VITO & IMEC -NL </br> Registratie </br> Meer informatie </br> </br> </br> 20/04/2021 </br> Healthy Indoor Quality of Living </br> Universiteit Antwerpen </br> Registratie </br> Meer informatie </br> </br> </br> 27/04/2021 </br> Learnings from international and local smart city initiatives </br> IMEC -EDiT </br> Registratie </br> Meer informatie </br> </br> </br> 04/05/2021 </br> Mobile environmental sensing </br> VITO </br> Registratie </br> Meer informatie </br> </br> </br> 03/06/2021 </br> Building Trust and Value in Data Ecosystems </br> IMEC -SMIT / DSP Valley </br> Registratie </br> Meer informatie </br> </br> </br> </br> </br> </br> ↑ https://www.vlaio.be/nl/nieuws/vlaio-stimuleert-brede-verspreiding-van-kennis-en-innovatie </br> </br> ↑ https://www . IMEC .be/nl/r-d-samenwerking/coperatieve-r-d-samenwerking/coock-brengt-r-d-naar-het-bedrijfsleven/open-stad </br> </br> ↑ https://vito.be/nl/open-stadbe/nl/open-stad  +
• In het “Ecodesign for Sustainable Product … In het “Ecodesign for Sustainable Product Regulation proposal” van 30 maart 2022 wordt er een voorstel voor een digitaal product paspoort beschreven voor elk fysiek goed dat binnen de Europese markt verhandeld wordt. Naast producten verstaan we onder fysieke goederen ook componenten en tussentijdse producten, met uitzondering van voedsel, diervoeder en geneesmiddelen. Het product paspoort zal van toepassing zijn voor alle producten die in Europa gemaakt worden, maar ook die in de EU geëxporteerd worden. Dit wil dus zeggen dat het voorstel een impact zal hebben op de globale handel. </br> Reden </br> Het gebruik van een digitaal product paspoort kan de milieueffecten gedurende de levenscyclus van producten verminderen en circulariteit stimuleren. Zo kan het product paspoort bijvoorbeeld informatie bevatten over hoe het product kan gerecycleerd worden en welke en hoeveel materialen het bevat.</br> </br> Hoe ziet het product paspoort eruit? </br> De concrete implementatie van een product paspoort is nog niet beslist en wordt tot op heden nog onderzocht (in Europese onderzoeksprojecten projecten zoals “CIRPASS”). Om een algemeen idee te geven, tonen we een voorbeeld van specifieke velden die kunnen worden opgenomen in het product paspoort:</br> </br> </br> </br> </br> </br> GTIN</br> </br> Een Global Trade Item Number is een unieke nummer die een verhandeld goed kan voorstellen: https://www.gs1.org/standards/id-keys/gtin </br> </br> </br> Brand Name</br> </br> Producent van het product</br> </br> </br> Product Description</br> </br> Beschrijving van het product.</br> </br> </br> Countries of Sale</br> </br> Landen waar het product verkocht wordt.</br> </br> </br> Photo</br> </br> Een foto van het product.</br> </br> </br> Bill of materials</br> </br> Een tabel van materialen die gebruikt zijn om het product te maken. Dit is belangrijke informatie voor het recycleren van het product na einde van de levensduur.</br> </br> Een demo implementatie van QLIKTAG is hier te vinden.er te vinden.  +
• In het Engels: "A Data Space is a virtual … In het Engels: "A Data Space is a virtual data integration concept defined as a set of participants and a set of relationships among them, where participants provide their data resources and computing services." </br> [1] </br> In het Nederlands: "Een data space is een virtueel data-integratieconcept dat wordt gedefinieerd als een reeks deelnemers en een reeks onderlinge relaties, waarbij deelnemers hun databronnen en computerservices leveren."</br> Een data space vormt dus een ruimte waarin data wordt uitgewisseld tussen verschillende actoren in een ecosysteem. Elke toepassing heeft zijn eigen data space, dus is opgebouwd uit de verschillende databronnen die nodig zijn om de toepassingen mogelijk te maken. Er is dus niet 1 data space per toepassingsdomein, maar een schier oneindig mogelijk aantal data spaces.</br> </br> </br> ↑ https://www.gaia-x.eu/pdf/Gaia-X_Architecture_Document_2103.pdfGaia-X_Architecture_Document_2103.pdf  +
• In onderstaande youtube filmpje worden de … In onderstaande youtube filmpje worden de belangrijkste principes van machine readable data uitgelegd:</br> </br> </br> </br>Het komt erop neer dat:</br> </br> data op een logische manier gestructureerd is </br> Dit format niet veranderd wordt! </br> data opgeslagen in .csv bestanden, json, etc... nooit met "de hand" ge-editeerd wordt. </br> data verwerking gebeurt met scripts, maar van de ruwe data blijft men af! </br> in een tabulair formaat is elke row een observatie, en elke kolom een variabele.n observatie, en elke kolom een variabele.  +
• In traditionele transformatieprojecten, en … In traditionele transformatieprojecten, en smart cities zijn helaas geen uitzondering, wordt het niet voorzien of aanwezig zijn van data om bepaalde functies mogelijk te maken vaak te laat in de project levenscyclus gedetecteerd. Dit verhoogt de kost en vertragingen in het project. Daarom is het nodig om van in het begin van een project de focus te leggen op het identificeren en oplossen van de nood aan data tijdens de hele looptijd van het project, inclusief na afloop van het project. Deze "Data-first" benadering laat organisaties toe om sneller strategische doelstellingen te realiseren. Een "Data-Ops" proces ondersteunt deze benadering. "Data-first" wil niet alleen zeggen dat er moet nagedacht worden over welke data gegenereerd kunnen worden of nodig zijn in het project alleen, maar ook hoe data als een hefboom kunnen werken voor toekomstige projecten. </br> Dit wil zeggen dat er moet nagedacht worden waar de data kunnen ontsloten worden, wat de kwaliteit van de data moet zijn, hoe deze duurzaam en interoperabel kunnen voorgesteld worden, wat de kost is om deze bij te houden en wat de kost is om deze eventueel later te ontsluiten. Elk project kan data genereren die misschien niet direct relevant lijken, maar vanuit strategisch oogpunt heel belangrijk kunnen zijn. Een voorbeeld is slimme verlichting, waar de data die gebruikt worden om beweging te detecteren via camera's ook kunnen gebruikt worden voor eventuele "crowd monitoring", of geluidssensoren voor het aansturen van de verlichting ook kunnen gebruikt worden om noodsituaties in de stad in kaart te brengen. Op die manier kan een data-first benadering dus ook de basis zijn voor een aanbesteding voor hardware en software van Smart City initiatieven.e en software van Smart City initiatieven.  +
• Inhoud 1 Context 2 Beschrijvi … Inhoud </br> </br> 1 Context </br> 2 Beschrijving </br> 3 Use cases </br> 4 VLOCA-Donut </br> 5 Relaties </br> 6 Schema's </br> 7 Standaarden en specificaties </br> 8 Meer informatie </br> </br> </br></br> </br>Deze pagina laat toe informatie volgens focus te bezoeken. Klik op het hand icoon om meer of minder informatie weer te geven.</br> </br> </br></br> </br> Algemene informatie </br> </br> Niveau Informatie </br> </br> Niveau informatie is nu zichtbaar</br> </br> </br> </br> Niveau Technologie & Architectuur </br> </br> Niveau Technologie en architectuur is nu zichtbaar</br> </br> </br> </br> </br> Voor alle gebruikers</br> </br> Voorkennis IT met beperkte architectuur-kennis</br> </br> Voorkennis van architectuur</br> </br> Context </br> In een open city architectuur worden datasets en modellen beschikbaar gesteld voor hergebruik in verschillende toepassingen. Het Asset Register is een centrale verzamelplaats waar de beschikbare gegevens en modellen worden geïnventariseerd ten einde de betrouwbaarheid en herkomst van de gegevens te kunnen garanderen en aldus de asset /data governance te waarborgen.</br> </br> </br> Het Asset Register bevat de data schema’s, ontologieën, datatypes, en data locatie gegevens zodat de relaties tussen de data zijn voor eindgebruikers en voor systeemtoepassingen.</br> </br> </br> </br> Tekst rond technologie en architectuur</br> </br> </br> Beschrijving </br> Het Asset Register en de metadata van zijn componenten zorgen voor de semantiek van de gegevens. Het Asset register beschrijft gegevens en modellen zowel op technisch niveau (technische schema's) als op functioneel niveau (bv. bedrijfstermen of domeinontologieën). De functionele beschrijving wordt gekoppeld aan het technische schema van een dataset zodat gebruikers de gegevens kunnen begrijpen met behulp van alomtegenwoordige termen. In het Asset register zullen doorgaans aanvullende metadata beschikbaar zijn die kunnen worden gebruikt voor de vindbaarheid van de data en de toepasbaarheid voor datadeling.</br> </br> </br> In het Asset Register worden technische data schema’s gedefinieerd en ontologieën bepaald- referentie na ...</br> </br> </br> </br> Referentie naar RDF, Topbraid? </br> </br> </br> Use cases </br> Het Asset register is toegankelijk voor eindgebruikers die de inventaris en beschrijving van de beschikbare componenten kunnen raadplegen. Op systeemniveau wordt het asset register gebruikt om data op te zoeken en de relaties tussen technische data componenten te verduidelijken. </br> </br> </br> Tekst rond informatie</br> </br> </br> </br> Tekst rond technologie en architectuur</br> </br> </br> VLOCA-Donut </br> Algemene tekst, verstaanbaar door iedereen</br> </br> </br> Tekst rond informatie</br> </br> </br> </br> Tekst rond technologie en architectuur</br> </br> </br> Relaties </br> Naargelang het type data en de oorsprong, kan de data bewaard worden op verschillende plaatsen zoals toegelicht in het storage to scale domein. De data kan zowel intern als extern bewaard worden en wordt via data capture mechanismes aangesproken voor het gebruik binnen de toepassingen. </br> </br> </br> Tekst rond informatie</br> </br> </br> </br> Tekst rond technologie en architectuur</br> </br> </br> Schema's </br> Algemene tekst, verstaanbaar door iedereen</br> </br> </br> Tekst rond informatie</br> </br> </br> </br> Tekst rond technologie en architectuur</br> </br> </br> Standaarden en specificaties </br> Algemene tekst, verstaanbaar door iedereen</br> </br> </br> Tekst rond informatie</br> </br> </br> </br> Tekst rond technologie en architectuur</br> </br> </br> Meer informatieeer informatie  +
• Inhoud 1 Impactmap 2 Blauwdru … Inhoud </br> </br> 1 Impactmap </br> 2 Blauwdruk template </br> 3 Succesmeting </br> </br> </br></br> Impactmap </br> </br></br> </br> Naam van de dienst/aanpak/project: Fundament Proactieve dienstverlening </br> </br> Datum: 27/01/2022 </br> </br> </br> Doel </br> </br> Doelgroep </br> </br> Impact </br> </br> Deliverable </br> </br> </br> Met deze nieuwe aanpak bieden we de UITPAS automatisch aan KANSENTARIEF (KT) aan bij aankoop door op basis van beschikbare data in gekoppelde bronnen in real time te onderzoeken of de aankopende burger daar recht op heeft.</br> </br> Burger die UITPAS KT aankoopt aan de UITPAS-balie (10.000 per jaar - ongeveer 65% aan kansentarief)</br> </br> Proactieve toekenning van juiste tarieven: Burger hoeft niet langer zelf aan te geven dat hij/zij kansentarief wenst, of daarvoor denkt in aanmerking te komen. Soms bestaat er schroom om dit aan de balie te moeten aangeven. Bovendien zijn er ook burgers die niet weten over het bestaan van KT, of die niet weten dat ze daar voor in aanmerking komen. Zij zullen nu het juiste tarief automatisch krijgen. => grotere take-u p Administratieve vereenvoudiging : Burger moet geen attesten meer ter bewijsvoering aanleveren: - attest Verhoogde Tegemoetkoming (via mutualiteit) - attest schuldbegeleiding/budgetbeheer,-bemiddeling - bewijs leefloon Meer vrijetijdsbesteding voor personen in armoed e: Hogere take-up leidt er toe dat meer mensen een UITPAS aan kansentarief zullen hebben en dus daar ook gebruik van zullen maken. Dankzij het kansentarief genieten ze van 80% korting bij deelname aan sport- of vrijetijdsactiviteiten. We gaan er van uit dat door meer en juister de UITPAS aan het kansentarief te verkopen dat dit ook leidt tot meer vrijetijdsdeelname van deze doelgroep.</br> </br> Het rijksregisternummer van de aankoper wordt ofwel manueel ofwel via uitlezen e-id in het UI-scherm ingegeven door de baliemedewerker (die daartoe gemachtigd is) en start de bevraging. Volgende criteria worden binnen Automatisch Advies (MAGDA) afgetoetst obv het ingegeven rijksregisternummer: - is X inwoner van Gent (via GeefPersoon) én - heeft X statuut Verhoogde Tegemoetkoming (via GeefSociaalStatuut) of - is persoon gekend bij OCMW als leefloner (via GeefSociaalStatuut) of - is persoon X gekend bij OCMW Gent onder schuldbegeleiding/budgetbeheer, -bemiddeling (via koppeling interne OCMW-bron van GENT) Indien aan bovenstaande regels wordt voldaan krijgt de baliemedewerker een positief advies in het UI-scherm om Kansentarief UITPAS toe te kennen. Indien niet, krijgt die te zien op welke van de voorwaarden niet werd voldaan en wordt de UITPAS aan gewoon tarief verkocht.</br> </br> </br> </br> </br> </br> Baliemedewerker die UITPAS verkoopt (17 verschillende verkooppunten: Gentinfopunten, dienstencentra, UITwinkel, Stadswinkel, Krook-bib,…)</br> </br> Gebruiksvriendelijker e dienstverlening: de medewerker hoeft de burger niet meer om zeer persoonlijke en soms gevoelige zaken te vragen zoals of die eventueel in schulden zit, een leefloon krijgt, een sociaal statuut heeft, …</br> </br> Baliemedewerker leest eID in of geeft rijksregisternummer manueel in UI-scherm in en krijgt te zien of persoon aan balie wel of niet in aanmerking komt voor kansentarief. We maken een UI-scherm op voor de baliemedewerkers. Bij de opzet van dit scherm worden de medewerkers betrokken en zullen gebruikerstesten uitgevoerd worden.</br> </br> </br> Efficiëntiewins t: Hoeft bewijsstukken niet langer op te vragen, te controleren. Tijdswinst want minder tijd kruipt in uitleggen welke attesten, waar ze die attesten kunnen opvragen, controleren van de attesten.</br> </br> Gegevens worden opgevraagd via MAGDA/Automatisch Advies in de gekoppelde databronnen. Indien nodig kan de medewerker het advies meer in detail bekijken om te zien op basis van welke data het advies tot stand is gekomen.</br> </br> </br> </br> </br> </br> Burgers met persoonsgevoelige gegevens gekend bij OCMW</br> </br> Dataminimalisati e: Er zullen minder gegevens over burgers die gekend zijn bij OCMW onder vorm van schuldbegeleiding/ budgetbeheer,-bemiddeling gedeeld worden binnen de organisatie. Vroeger stonden alle mogelijke rechthebbenden in een lijst op een beveiligde sharepoint waar baliemedewerkers in konden nagaan of persoon X inderdaad rechthebbend was. Niet alleen was deze data niet altijd actueel, maar bovendien werd op deze manier ook persoonsgevoelige data over burgers gedeeld die niet gekend hoefden te zijn bij de baliemedewerkers. De lijst omvatte immers ook personen die geen UITPAS kwamen aankopen.</br> </br> Via een puntbevragin g wordt enkel de data van de persoon die aan de balie de UITPAS komt kopen op dat moment opgevraagd in de gekoppelde bronnen. Bovendien zal in het advies dat getoond wordt aan de baliemedewerker het achterliggende detail in de eerste plaats niet te zien zijn. Het is immers niet van belang of die burger nu recht heeft omwille van dat hij VT heeft, of omwille van feit dat hij misschien in budgetbeheer zit. De baliemedewerker hoeft dat niveau aan detail dus niet meteen te zien. (Het kan echter zijn dat het wél nodig is om dit te bekijken, vb als de burger daar vragen over heeft, en dan zal de baliemedewerker het detail van advies kunnen openklikken en bekijken. Maar we nemen dit dus niet als standaard op in het advies dat getoond zal worden.) We onderzoeken in het project door middel van gebruikerstesten bij de baliemedewerkers hoe men best en efficiëntst deze info te zien wil/kan krijgen.</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Met deze nieuwe aanpak bieden we ouders met een laag inkome n of met een leefloo n automatisch het kortingstarief toe op hun facturen van het stedelijk onderwijs Gent en de dienst kinderopvang door op basis van beschikbare data in gekoppelde bronnen te onderzoeken of ze daar recht op hebben.</br> </br> Ouder van kind in school van stedelijk onderwijs of kinderopvang Gent met laag inkomen en/of leefloon. (12.000 schoolgaande kinderen => 20% armoederisico = schatting van 2.400 lln). (voor onderwijs kregen in 2021 991 unieke kinderen een korting op basis van het loon of sociale korting. Voor kinderopvang waren dat er 509)</br> </br> Proactieve toekenning van juiste tarieven : Ouders die de kortingstarieven niet kennen, of niet weten dat ze daar voor in aanmerking komen, gaan nu automatisch het juiste tarief gefactureerd krijgen => Grotere take up Ouders hoeven niet langer zelf aan te geven dat ze denken in aanmerking te komen voor een korting. Vaak bestaat schroom of schaamte om dit door te geven aan de school. Korting obv fiscaal inkomen : Vandaag bestond al een gedeeltelijke oplossing voor ouders met een leefloon. Dankzij deze opzet zal ook voor ouders met een laag inkomen (maar dus geen leefloon) alsnog automatisch een korting op hun schoolfacturen toegekend worden, zonder dat ze dit moeten aangeven.</br> </br> Bij de start van het schooljaar, en voor nieuwe ingeschreven kinderen bij de instapmomenten, wordt de lijst met (nieuwe) ingeschreven kinderen uit de toepassingen van Stedelijk Onderwijs (stadsscholen) & dienst Kinderopvang via de toepassing bevraagd naar relevante gegevens over de ouders. De bevraging verloopt via MAGDA en de criteria worden in Automatisch Advies gemodelleerd in business-rules en afgetoetst. Obv een lijst met de rijksregisternummers van de ingeschreven leerlingen/kinderen bevragen we op 15/09; 15/11; 15/01 en 15/05 (na diverse instapmomenten schooljaar voor nieuwe kinderen): - hebben ouders van X een leefloon (bevraging via GeefSociaalStatuut) - is het GBI van de ouders lager dan 30.000 euro OF lager dan 20.000 euro OF gelijk aan of lager dan het (equivalent) leefloon? Deze datastroom is nieuw op te zetten vanuit FOD.FIN / drempelbedragen worden in de bibliotheek mat businessrules van Automatisch Advies gemodelleerd. Het advies geeft ons per kind duidelijk weer in welk kortingstarief die valt.</br> </br> </br> Administratieve vereenvoudiging : Ouders moeten het fiscaal attest of attest leefloon niet meer ter bewijsvoering aan de school doorgeven. (Bewijs leefloon of Fiscaal attest) Dikwijls is dit niet meteen duidelijk voor ouders welke specifieke attesten er nodig zijn.</br> </br> </br> Dataminimalisatie : Ouders die in de huidige situatie hun fiscaal attest als bewijsstuk moeten doorgeven geven een veel grotere inzage in hun persoonlijke inkomenssituatie dan eigenlijk nodig is voor het specifieke doeleinde. Bovendien krijgen meerdere mensen dit document te zien vooraleer het bij de dienst toekomt die de facturen opmaakt. Door het fundament zal dit fiscaal attest helemaal niet meer opgevraag moeten worden. Via het fundament wordt bovendien énkel onderzocht of het GBI van de ouders lager ligt dan bepaalde drempelbedragen.</br> </br> </br> </br> </br> </br> Brugfiguren, of personeelsleden binnen de schooladministraties en de kinderopvanginitiatieven (aantal; 805 unieke kleuters en lagere schoolkinderen waarvan vaak overlap bij DIKO en school)</br> </br> Efficiëntiewins t Brugfiguren steken nu heel veel tijd in het informeren van ouders over hun rechten, in het herhaaldelijk opvragen en herinneren aan ouders om de juiste bewijsstukken aan te leveren zodat de korting kan aangevraagd worden bij departement Stedelijk Onderwijs. Al deze taken zullen komen te vervallen waardoor tijd vrijkomt om ouders met andere zorgen bij te staan.</br> </br> Onze oplossing zorgt ervoor dat de handelingen die de scholen in dit proces moesten uitvoeren, automatisch zullen verlopen. De handelingen van de brugfiguren en schooladministraties zijn in onze nieuwe aanpak niet meer nodig.</br> </br> </br> De aanvraagprocedure, waarbij de scholen en brugfiguren ouders vaak bijstonden, komt te vervallen voor de meeste dossiers. Op deze manier komt tijd vrij voor hen om ouders bij te staan rond andere zaken ipv enkel administratieve rompslomp te regelen.</br> </br> </br> Persoonsgevoelige informati e Brugfiguren zullen minder moeten doorvragen naar zeer persoonlijke informatie zoals of de ouders misschien een laag inkomen hebben of een leefloon genieten. Deze vraag valt niet altijd in goede aarde bij de ouders en is vaak een moeilijk gesprek.</br> </br> </br> </br> </br> </br> Stedelijk Onderwijs Gent en dienst Kinderopvang</br> </br> Efficiëntiewins t: De administratie moet de vele bewijsstukken die vanuit de scholen komen over de dossiers waar korting toegekend moet worden niet meer controleren, verwerken, opvolgen. In de huidige situatie zijn er binnen het departement Onderwijs 5 medewerkers voltijds bezig in de maanden september & oktober met deze administratieve opvolging.</br> </br> De administratie zal via ons fundament de lijst met ingeschreven leerlingen (totaal 12.000 rijksregisternummers) bevragen. Voor deze 12.000 records wordt bij opmaak van de facturen eind september afgetoetst via Automatisch Advies wie recht heeft op een korting, en welk kortingstarief dat is. Ook bij bijkomende instapmomenten doorheen het schooljaar wordt voor nieuwe leerlingen bevraagd welke ouders een kortingstarief genieten. Het kortingstarief wordt vervolgens door de medewerkers die de facturen opmaken toegepast bij de opmaak van de facturatie. Concreet zal via Automatisch Advies obv de businessrules de verschillende kortingstarieven afgetoetst worden en per leerling weergegeven worden: Korting A (Leefloon) / Korting B GBI <30.000 euro / Korting C GBI ts 20k en 30k / Korting D GBI onder of gelijk aan leefloon-equivalentleefloon.</br> </br> </br> Uiteindelijk zal dit ook leiden tot minder kosten bij de administratie aan herinneringsbrieven om facturen die niet/laattijdig betaald worden; en uiteindelijk zelfs kosten van deurwaarders die ingezet worden bij niet-betaling van facturen.</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Met deze nieuwe aanpak bieden we 1) inwoners van de LEZ-zone die VT hebben automatisch hun verlaagd tarie f; en 2) personen met een parkeerkaart voor handicap die ook het Verhoogde Tegemoetkoming (VT)-statuut hebben eenvoudiger hun gratis registratie, door bij hun aankoop van hun LEZ-toegang op basis van beschikbare data in de gekoppelde bronnen na te gaan of ze daar recht toe hebben.</br> </br> Inwoners LEZ-zone met VT statuut die verlaagd tarief krijgen (#300/jaar)</br> </br> Administratieve vereenvoudiging : Burger hoeft het attest ter bewijsvoering niet meer zelf aan te leveren bij de aanvraag. Het volstaat om aan te vinken dat hij/zij Verhoogde Tegemoetkoming geniet. Nu moeten burgers dit attest nog vaak bij hun mutualiteit gaan opvragen. Heel dikwijls wordt het verkeerde bewijsstuk aangeleverd of zijn daar nog veel vragen over.</br> </br> De burger zal in de LEZ-tool het attest van Verhoogde Tegemoetkoming niet meer zelf moeten opladen. Het zal volstaan dat de burger aangeeft dat ie een VT attest heeft door dit aan te vinken op de LEZ-tool. Het zal vervolgens door de LEZ-stadsmedewerker in de backoffice via een bevraging naar onze tool gecontroleerd worden obv het rijksregisternummer van de aanvragende burger. Volgende criteria worden binnen Automatisch Advies (MAGDA) afgetoetst obv het rijksregisternummer: - heeft X statuut Verhoogde Tegemoetkoming (via GeefSociaalStatuut). Indien aan bovenstaande regels wordt voldaan, krijgt de stadsmedewerker een positief advies terug en kan die de verwerking van de aanvraag verder afhandelen.</br> </br> </br> </br> </br> </br> Burger met parkeerkaart voor handicap én VT-statuut die gratis registratie van wagen doet (VT: #700/jaar; parkeerkaart: #800/jaar)</br> </br> Administratieve vereenvoudiging : Burger hoeft geen attest meer ter bewijsvoering aan te leveren bij de aanvraag: - attest Verhoogde Tegemoetkoming Nu moeten burgers dit attest nog vaak bij hun mutualiteit gaan opvragen, dikwijls wordt het verkeerde bewijsstuk aangeleverd of zijn daar nog veel vragen over. - Ook de gegevens over de parkeerkaart voor gehandicapten zal niet meer moeten doorgegeven door de aanvrager.</br> </br> Via Automatisch Advies wordt, op basis van de aanvraag die een LEZ-medewerker vanuit hun backofficesysteem (Traffiek) initieert, nagegaan of: - persoon (obv rrnr) over VT beschikt (GeefSociaalStatuut) + einddatum VT - of: iemand gedomicilieerd op hetzelfde adres heeft VT - persoon een parkeerkaart handicap heeft (GeefDossierHandicap) - of: iemand gedomicilieerd op hetzelfde adres als de titularis een parkeerkaart handicap heeft (GeefPersoon) Er wordt een API koppeling tussen de LEZ-tool (Traffiek) en Automatisch Advies opgezet. </br> </br> </br> </br> </br> </br> Administratie LEZ (Milieudienst Gent)</br> </br> Efficiëntiewinste n: Er kruipt vandaag heel veel tijd in het begeleiden van burgers bij de aanvraag van deze sociale maatregelen. Het op weg helpen om het attest Verhoogde Tegemoetkoming te verkrijgen bij de mutualiteiten, toelichting en informatie geven. Bellen en mailen wanneer het bewijsstuk niet juist of laattijdig, of niet wordt aangeleverd. Indien deze check digitaal bij de authentieke bron kan gebeuren, zal dit voor medewerkers véél tijd en werklast besparen.</br> </br> We ontwikkelen een API vanuit de backoffice-tool van de LEZ (TRAFFIEK) naar Automatisch Advies. Medewerkers kunnen dan voor een specifiek rijksregisternummer het advies opvragen.</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Blauwdruk template </br> </br></br> </br> Pagina </br> </br> 1 </br> </br> Blauwdruk: </br> </br> Fundament proactieve dienstverlening - UITPAS KT (1) </br> </br> </br> </br> </br> Fase</br> </br> </br> </br> Vragen aankoop UITPAS </br> </br> Controleren kansentarief aankoper</br> </br> Afleveren UITPA S aan juiste tarief</br> </br> </br> Interactiepunt</br> </br> </br> </br> - Ik ga naar één van de verkooppunten van de UITPAS. - Ik heb eigenlijk geen weet van verschillende tarieven maar ben wel geïnteresseerd in het aanbod en spaar-mogelijkheden. - Ik luister bij de baliemedewerker hoe de UITPAS werkt en welke opties er zijn.</br> </br> - Ik geef mijn identiteitskaart aan de baliemedewerker, daarmee kan hij/zij controleren of ik eventueel ook recht heb op het kansentarief. - Ik zeg dat ik denk van wel, maar niet weet welke bewijsstukken ik daar voor misschien moet aanleveren. - De baliemedewerker informeert me dat dit niet nodig is, en dat hij/zij op basis van mijn rijksregisternummer kan nagaan of ik daar recht op heb.</br> </br> - Blijkbaar heb ik recht op kansentarief, fijn, dat wist ik helemaal niet! En ik hoef niet eens documenten of iets dergelijks aanleveren! - Dat ging zeer snel, en ik moet maar 1 euro betalen. - Dankzij mijn kansentarief UITPAS geniet ik nu blijkbaar 80% korting op superveel vrijetijd- en sportactiviteiten!</br> </br> </br> Medium</br> </br> </br> </br> Balies UITPAS / 17 verkooppunten</br> </br> - Balies UITPAS / verkooppunten - E-id kaart of doorgeven rijksregisternummer aan baliemedewerker</br> </br> - Balies UITPAS / verkooppunten - Bancontact - Afleveren UITPAS</br> </br> </br> Ervaring</br> </br> </br> </br> </br> Frontoffice</br> </br> </br> </br> - Baliemedewerkers informeren over aanbod en gebruik UITPAS. - Informeren over bestaan van diverse tarieven en kostprijzen.</br> </br> - Baliemedewerker geeft rijksregisternummer van burger / of leest e-id kaart in van burger in UI-scherm dat we ontwikkelen. - Baliemedewerker start aanvraag voor Kansentarief UITPAS.</br> </br> - Baliemedewerker krijgt in het UI-scherm te zien of de persoon die UITPAS wenst aan te kopen recht heeft op het kansentarief of niet. - In het systeem wordt een Advies gegenereerd dat de baliemedewerker bijkomend kan openen en waarin het detail achter het Advies meegedeeld wordt. Zo kan de baliemedewerker bijvoorbeeld inkijken obv welke criteria er wél of geen kansentarief toegekend wordt indien daar vragen bij zouden zijn. - Op basis van het advies maakt de baliemedewerker de juiste UITPAS aan en vraagt die het jui ste tarief (5 euro of 1 euro voor de aankoopprijs) aan de burger.</br> </br> </br> Backoffice</br> </br> </br> </br> Geen</br> </br> - Via API vanuit UI-scherm start de puntbevraging voor het opgegeven rijksregisternummer in Automatisch Advies. - In Automatische Advies staan de geldende voorwaarden in machineleesbare business-rules beschreven. - De nodige data wordt in de gekoppelde bronnen (KSZ + interne OCMW New Horizon bron) opgevraagd. - De opgevraagde data wordt afgetoetst aan de businessrules. - Zodra één van de doorslaggevende criteria voldoende uitsluitsel geeft over eventueel recht op Kansentarief wordt het advies aan de baliemedewerker bezorgd. - Indien onvoldoende gegevens beschikbaar zijn wordt het advies gegeven "Advies niet beschikbaar". - In het systeem wordt een Advies gegenereerd dat de baliemedewerker bijkomend kan openen en waarin het detail achter het Advies meegedeeld wordt. Zo kan de baliemedewerker bijvoorbeeld inkijken obv welke criteria er wél of geen kansentarief toegekend wordt indien daar vragen bij zouden zijn.</br> </br> Geen</br> </br> </br> Verschil huidige aanpak (wanneer van toepassing)</br> </br> </br> </br> Baliemedewerker zal niet meer moeten informeren welke bewijsstukken de burger nodig heeft om het kansenstatuut te attesteren.</br> </br> Vandaag moet de baliemederker de bewijsstukken op moment van aanvraag bij de klant opvragen. Het attest van Verhoogde Tegemoetkoming, of een bewijs dat die persoon een Leefloon geniet of in schuldbemiddeling of budgetbegeleiding of budgetbeheer zit bij het OCMW. Vaak heeft de burger niet meteen de juiste bewijsstukken mee en moet de burger opnieuw naar huis, eerst de documenten opvragen/opzoeken en later opnieuw komen.</br> </br> Geen</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Succesmeting </br> </br></br> </br> </br> </br> Impact (uit impactmap)</br> </br> Meetpunt</br> </br> SMART specificatie</br> </br> Huidige waarde</br> </br> Doel waarde</br> </br> </br> </br> </br> </br> UITPAS </br> </br> Proactieve toekenning van juiste tarieven: Burger hoeft niet langer zelf aan te geven dat hij/zij kansentarief wenst, of daarvoor denkt in aanmerking te komen. Burgers die misschien niet weten over het bestaan van KT, of die niet weten dat ze daar voor in aanmerking komen, gaan nu het juiste tarief automatisch krijgen. => grotere take-up Administratieve vereenvoudiging: Burger moet geen attesten meer ter bewijsvoering aanleveren: - attest Verhoogde Tegemoetkoming (via mutualiteit) - attest schuldbegeleiding/budgetbeheer,-bemiddeling - bewijs leefloon Burgers zullen bij aankoop aan de UITPAS-balie meteen hun UITPAS kunnen meenemen aan juiste tarief. Vandaag moeten mensen soms nog eens opnieuw komen omdat ze de (juiste) bewijsstukken niet mee hebben. Meer vrijetijdsbesteding voor personen in armoede: Juister en proactief toekennen van KT bij UITPAS biedt deze doelgroep 80% korting op de kostprijs van sport- en vrijetijdsactiviteiten. Deze oplossing zal ook resulteren in een grotere participatie van burgers in armoede aan vrijetijdsbesteding. </br> </br> Aantal UITPAS met kansentarief die verkocht zijn</br> </br> Percentage van het aantal verkochte UITPASsen met kansentarief aan balie in verhouding tot aantal UITPAS (zonder kansentarief).</br> </br> 65% van UITPAS is met Kansentarief</br> </br> Stijging van aandeel met Kansentarief met 5% 1 jaar na oplevering oplossing</br> </br> </br> Efficiëntiewinst voor de baliemedewerker : Hoeft bewijsstukken niet langer op te vragen, te controleren, te verwerken Gebruiksvriendelijke dienstverlening: Medewerker moet minder vaak burger terug naar huis sturen wanneer de nodige bewijsstukken ontbreken. Verkoop kan veel vlotter verlopen. </br> </br> Doorlooptijd verkoop UITPAS aan balie UITPAS</br> </br> Maximaal aantal minuten van doorlooptijd bij verkoop UITPAS kansentarief die medewerker besteedt aan uitleg en controle bewijsstukken.</br> </br> 15 minuten</br> </br> 5 minuten Daling met 10 minuten per verkochte UITPAS KT</br> </br> </br> Dataminimalisatie : Er zullen minder gegevens over burgers die gekend zijn bij OCMW onder leefloon, VT-statuut, of onder vorm van schuldbegeleiding/ budgetbeheer,-bemiddeling gedeeld worden binnen de organisatie. Vroeger stonden alle mogelijke rechthebbenden in een lijst op een beveiligde sharepoint waar baliemedewerkers dan konden nagaan of persoon X inderdaad rechthebbend was. Niet alleen was deze data niet altijd actueel, maar bovendien werd op deze manier ook persoonsgevoelige data over burgers gedeeld die niet gekend hoefden te zijn bij de baliemedewerkers. </br> </br> Gedeelde lijst met personen in schuldbegeleiding, budgetbeheer, budget bemiddeling tussen OCMW en UITPAS verkooppunten</br> </br> Aantal gedeelde lijsten</br> </br> 1 per verkooppunt 17 verschillende verkooppunten over de Stad</br> </br> 0 Er is geen gedeelde lijst meer, enkel digitale bevraging voor burger die UITPAS aankoopt.</br> </br> </br> Onderwijs </br> </br> Proactieve toekenning van juiste tarieven voor ouders van leerlingen in Stedelijk onderwijs en Kinderopvang. Ouders die de kortingstarieven niet kennen, of niet weten dat ze daar voor in aanmerking komen, gaan nu automatisch het juiste tarief gefactureerd krijgen => grotere take u p Ouders hoeven niet langer zelf aan te geven dat ze denken in aanmerking te komen voor een korting. Vaak bestaat schroom of schaamte om dit door te geven aan de school. Korting obv fiscaal inkomen : Vandaag bestond al een gedeeltelijke oplossing voor ouders met een leefloon. Dankzij deze opzet zal ook voor ouders met een laag inkomen (maar dus geen leefloon) alsnog automatisch een korting op hun schoolfacturen toegekend worden, zonder dat ze dit moeten aangeven. </br> </br> Facturen die naar ouders verstuurd worden, met een kortingstarief</br> </br> Aantal ouders die korting op hun facturen genieten obv fiscaal inkomen en/of leefloon.</br> </br> In 2021 kregen binnen Stedelijk Onderwijs 991 unieke kinderen al een korting op basis van het loon of sociale korting (obv bewijsstukken ) Voor kinderopvang waren dat er 509 in 2021.</br> </br> Ruwe schatting (obv armoedecijfers en totaal van 12.000 lln) mikken we op een totaal aantal van 2.000 kinderen die we op deze manier proactief hun korting willen toekennen. (1 op 6 zou in armoede verkeren)</br> </br> </br> Administratieve vereenvoudiging : Ouders moeten hun fiscale inkomensattesten ter bewijsvoering niet meer aanleveren via de school. </br> </br> Attesten die bij aanvraag worden toegevoegd ter bewijsstuk</br> </br> Aantal fiscale attesten die nu ter bewijsvoering bij aanvraag van de korting worden opgestuurd.</br> </br> Aandeel van rechthebbenden die obv hun fiscaal attest hun recht op korting aantonen.</br> </br> 0</br> </br> </br> Efficiëntiewinst schole n Brugfiguren steken nu heel veel tijd in het informeren van ouders over hun rechten, in het herhaaldelijk opvragen en herinneren aan ouders om de juiste bewijsstukken aan te leveren zodat de korting kan aangevraagd worden bij departement Stedelijk Onderwijs. Al deze taken zullen komen te vervallen waardoor tijd vrijkomt om ouders met andere zorgen bij te staan. </br> </br> Tijdsbesteding personeel scholen (administratie, brugfiguren)</br> </br> Aantal uren aan begeleiding, herinnering, ondersteuning van ouders bij indienen van aanvragen korting.</br> </br> Bevraging aan schooladministraties en brugfiguren leert dat ze per dossier gemiddeld 2 uur besteden aan opvolgen, herinneren, begeleiden en indienen van formulier.</br> </br> Via deze oplossing zal deze werking niet meer nodig zijn. De brugfiguren en scholen kunnen de vrijgemaakte tijd besteden aan andere nodige begeleiding.</br> </br> </br> Dataminimalisatie: Er zullen minder persoonsgevoelige gegevens over de ouders van leerlingen gedeeld moeten worden binnen de organisatie. Nu werden deze attesten doorgegeven aan verschillende personen. Bovendien bevat het fiscale attest veel meer informatie dan hetgeen nodig is (enkel het Gezamenlijk Belastbaar Inkomen). </br> </br> Attesten die bij aanvraag worden toegevoegd ter bewijsstuk</br> </br> Aantal fiscale attesten die nu ter bewijsvoering bij aanvraag van de korting worden opgestuurd.</br> </br> Aandeel van rechthebbenden die obv hun fiscaal attest hun recht op korting aantonen.</br> </br> 0</br> </br> </br> Efficiëntiewinst departement Stedelijk Onderwij s Medewerkers bij departement Stedelijk Onderwijs die facturen opmaken moeten de aanvragen van de ouders verwerken. Daarbij moeten ze veel tijd besteden bij het opvragen van bijkomende bewijsstukken om de aanvraag te attesteren. </br> </br> Tijdsbesteding personeel Stedelijk Onderwijs</br> </br> Aantal uren/mandagen die personeel bij Dept. Stedelijk Onderwijs besteedt aan opmaak & controle van facturen.</br> </br> In maanden sept/okt is 5 VTE fulltime met de opmaak en update van die facturen bezig.</br> </br> Die 5 VTE zal zeker blijvend nodig zijn, maar dan om nog meer scholen te servicen. Nu worden enkel de basisscholen en de opvanglocaties van Dienst Kinderopvang ondersteund. We willen die dienstverlening met dezelfde equipe uitbreiden naar de secundaire scholen. De tijd die kruipt in het verzamelen, opvragen, nakijken van bewijsstukken zal door deze oplossing volledig wegvallen.</br> </br> </br> Efficiëntiewinst departement Stedelijk Onderwij s Door juiste korting zullen minder onbetaalde facturen opgevolgd moeten worden. Dit resulteert in minder aanmaningsbrieven, aangetekende zendingen en op termijn zelfs het minder inschakelen van deurwaarders. </br> </br> Aantal herinneringsbrieven (maandelijks ongeveer 8.000), aangetekende zendingen (jaarlijks ongeveer 1.000), deurwaarderskosten bij niet-betalen van facturen .</br> </br> Het aantal herinneringsbrieven, aangetekende zendingen en deurwaarders en bedrag aan deurwaarderskosten.</br> </br> Aantal herinneringsbrieven (maandelijks ongeveer 8.000), aangetekende zendingen (jaarlijks ongeveer 1.000), deurwaarderskosten bij niet-betalen van facturen.</br> </br> Een halvering van die aantallen en deurwaarderskosten is een mooi objectief</br> </br> </br> LEZ </br> </br> Administratieve vereenvoudiging: Burger moet geen attesten meer ter bewijsvoering aanleveren: - attest Verhoogde Tegemoetkoming - attest parkeerkaart handicap </br> </br> Attesten die bij aanvraag worden toegevoegd ter bewijsstuk</br> </br> Aantal ontvangen attesten</br> </br> • 700 VT (gratis registratie) • 300 VT (verlaagd tarief) • 800 parkeerkaarten (gratis registratie)</br> </br> 0</br> </br> </br> Efficiëntiewins t Medewerkers bij LEZ-dienst besteden veel tijd bij het opvragen van de juiste bijkomende bewijsstukken aan burgers die het sociaal tarief of gratis registratie aanvragen. </br> </br> Tijdsbesteding personeel LEZ</br> </br> Aantal uren/mandagen die personeel LEZ besteedt aan controle en opvragen van bewijsstukken.</br> </br> 40% van 1000 dossiers => 400u/jaar</br> </br> 0  +
• Inhoud 1 Inleiding 2 Proces e … Inhoud </br> </br> 1 Inleiding </br> 2 Proces en deliverables </br> 3 Overzicht VLOCA trajecten en voortrajecten </br> 4 Overzicht VLOCA assessments en ondersteuning </br> </br> </br></br> Inleiding </br> In de onderstaande tabel vind je een overzicht van de VLOCA trajecten en de link naar de startpagina van elk traject. </br>Een tweede tabel beschrijft de initiële aanvragen tot co-creatie m.b.t. thema's, met de link naar een VLOCA traject na integratie van dat onderwerp in een traject. </br> </br> Proces en deliverables </br> De VLOCA trajecten volgen een gestandaardiseerd proces dat we op de volgende pagina's beschrijven: </br> </br> </br></br> </br> Type </br> </br> Beschrijving </br> </br> </br> VLOCA traject </br> </br> Het gestandaardiseerd proces van een VLOCA traject, met beschrijving van werkstromen en deliverables</br> </br> </br> VLOCA/OSLO traject voor VLAIO CoT 2021 projecten </br> </br> Het proces van een gecombineerd VLOCA en OSLO traject, zoals bepaald beschreven voor de VLAIO City of Things oproepen gegund in 2021 (projecten in uitvoer vanaf 2022).</br> </br> </br> VLOCA deliverables </br> </br> De beschrijving van wat VLOCA als deliverable oplevert in trajecten en in aparte ondersteuningsvragen aan steden en gemeenten, worden beschreven op deze pagina. De beschrijvingen worden tevens aangevuld door sjablonen van deze deliverables.</br> </br> </br> Vraag voor VLOCA ondersteuning</br> </br> Voor supportvragen ivm open city architectuur, of nieuwe aanvragen voor een co-creatie traject, kan u best contact opnemen team VLOCA via vloca@vlaanderen.be . We maken graag tijd vrij om uw vraag te behandelen, op basis van onze kennis en ervaring in andere Open City trajecten.</br> </br> Overzicht VLOCA trajecten en voortrajecten </br>   Type Jaar Status Initiatiefnemer Domeinen Indicatoren Linkende Initiatieven Burgerloket Traject 2022 Geregistreerd Stad Mechelen Smart Government Circulaire economie: Repair cafés Traject 2021,2022 In co-creatie Stad Leuven,VITO Smart Environment Combimobiliteit: Hoppin punten Traject 2020,2021 In co-creatie ABB,IMEC Smart Government,Smart Mobility DINA: Dienstverlening via integratie naadloos aanbieden Traject 2022 Geregistreerd Stad Leuven Smart Government Data Broker Traject 2021 In co-creatie IMEC,Stad Antwerpen,Stad Gent,Stad Roeselare Smart Government Digitalisering volledige customer journey parkeren en GAS4 en GAS5 Traject 2022 In opstart Stad Genk Smart Government Het potentieel van urban mining & BIM voor de bouwsector Traject 2022 Lopend Stad Oostende Smart Environment Leefomgeving: Water in de Stad Traject 2020,2021 In co-creatie ABB,VITO Smart Environment Local Digital Twin Traject 2022 In co-creatie ABB,IMEC Smart Government Lokaal digitaal ondernemingsloket Traject 2022 In opstart Stad Mechelen Smart Government Lokale Open Data Economie (LODE) Traject 2022 Lopend Stad Brugge Smart Economy Maatgerichte implementatie van een document management systeem Traject 2022 Geregistreerd Stad Gent Smart Government Machine Learning as a Service (MLaaS) Traject 2022 Lopend Stad Roeselare Smart Government,Smart Environment Mobiele Sensor Units Traject 2022 Lopend Stad Roeselare Smart Government Mobiliteitsbudget voor burgers Traject 2022,2023 Lopend Stad Hasselt,Stad Leuven Smart Mobility Nachtlawaai verminderen d.m.v. technologie en nudging Voortraject 2021 In co-creatie Stad Leuven Smart People Preventieve gezondheidszorg: persoonlijke gezondheidsdata en lokale overheden Voortraject 2022,2023 Lopend Smart People Regionaal plugable incentiveringsplatform Traject 2022 Lopend Stad Geel,IOK Smart Living Slimme Markten Traject 2022 Lopend Stad Hasselt Smart Economy Slimme stadsdistributie Traject 2022 Lopend Stad Hasselt,Stad Leuven Smart Mobility Smart Innovation Factory Traject 2022 Lopend Stad Mechelen Smart Economy Sociaal Dossier Platform Traject 2022 Geregistreerd Stad Antwerpen Smart Government Tijd- en plaatsonafhankelijke klantencontacten Traject 2022 Geregistreerd Stad Mortsel Smart Government Transparante efficiënte en klantvriendelijke dienstverlening voor onze burgers verenigingen en ondernemingen Traject 2022 Gemeente Boechout Smart Government Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) Traject 2022 Lopend Provincie Oost-Vlaanderen,Stad Dendermonde,Stad Halle,VERA Smart Economy </br> Overzicht VLOCA assessments en ondersteuning </br>   Type Jaar Status Initiatiefnemer Domeinen Indicatoren Linkende Initiatieven API-led Ondersteuning Antwerp Living Labs: levendige en leefbare (universiteits)buurt Ondersteuning Stad Antwerpen Smart Environment,Smart People,Smart Living B-WaterSmart Ondersteuning 2020,2021,2022,2023,2024 Stad Mechelen Smart Environment Datagestuurde handelskern Ondersteuning 2022 Lopend Stad Hasselt DenCITY Ondersteuning 2020 Stad Antwerpen,VMM Smart Mobility,Smart Environment Flood4Cast Ondersteuning Smart Government,Smart Environment Hydrologisch meetnet provincie Antwerpen Ondersteuning Provincie Antwerpen Smart Environment Internet of Water Ondersteuning Smart Government,Smart Environment Iot-gestuurde mobipunten Ondersteuning Smart Mobility Koppeling IoT-peilsensordata naar andere IoT- stacks Ondersteuning IMEC,VITO,VMM Smart Environment Monitoring van de Laak Ondersteuning Smart Environment Online Reserveren en Betalen: type locatie in de stad Ondersteuning Stad Gent Smart Government,Smart Economy PROBE Ondersteuning Stad Gent Smart Government Proactive Flooding Detection Ondersteuning 2019 Stad Antwerpen Smart Government,Smart Environment Rainbrain Ondersteuning 2019,2020,2021,2022,2023 Stad Roeselare Smart Government,Smart Environment Sensorhotels Ondersteuning Smart Waterland Ondersteuning 2020,2021,2022 Stad Roeselare Smart Environment Stiemerlab Ondersteuning Stad Genk Smart Environment Tipping Points Ondersteuning Smart Environment Urban digital twin Ondersteuning 2021 Stad Brugge Smart Government Velopark Ondersteuning In co-creatie Smart Mobility Vertellende vlotten Ondersteuning Smart Environment WerfWater Ondersteuning Smart Environment Smart Environment  +
• Initiatieven A ANPR-camera's - Turnho … Initiatieven </br> A ANPR-camera's - Turnhout B BEReSLIM - Boilers en Ruimteverwarmers elektrisch SLIM sturen - Genk Burenondersteuning - Aalst C Citerra - City Environmental Regulations and Rights for Access Citizen science City of Things City of Things 2018 City of Things 2019 City of Things 2020 City of Things 2021 City of Things 2022 City of Things 2023 City of Things Mobiliteitsmanagement met ANPR - Puurs CityFlows Compair D DAKS 2.0 – Data in Kleine Steden DUET Data gedreven beleidsondersteuning Data-gestuurde winkelgebieden – Mechelen Databroker - Gent De Sint-Niklase Stadsmunt – Sint-Niklaas De creatie van open (IoT) data awareness bij lokale overheden - Leuven Digitaal parkeerrecht voor personen met een handicap Digitale customer journey parkeren en GAS 4/5 E EVENTMACHIEN - Pepingen Een digitale innovatietrack ter ondersteuning van een leefbare en bruisende universiteitsbuurt – Antwerpen (welzijn) Eenheid van schuld Energie Management Systeem – datagedreven optimalisering energieverbruik in steden EMS DOE G GAIA-X Gebruiksvriendelijk verenigingsloket Geconnecteerde openbare verlichting op fietspaden - Mechelen Gemeente zonder gemeentehuis G meer Gemeentelijk sensornetwerk voor luchtkwaliteitsmetingen - Kampenhout H H2020 Het potentieel van urban mining voor de bouwsector – Oostende I INVEST – POM West-Vlaanderen CityTRAQ Interoperable Europe IoT gestuurde mobipunten – Aalst (mobiliteit) L Living-in.eu LocusFocus – POM Vlaams-Brabant Lokaal 3D Project – Provincie Oost-Vlaanderen Lokale Open Data Economie (LODE) – Brugge M Machine Learning as a Service (MLaaS) – Roeselare Marktplaats Smart City - Bonheiden MoDi:2B - Mobiliteit als een dienst aan burgers via derde-betalersystemen - Leuven Mobiele Sensor Units – Roeselare Mobiliteitsbudget voor burgers – Hasselt Mobiliteitsmanagement met ANPR - Puurs Modderstroom Monitoring Monitoring energetische renovaties – Gent (energie) Monitoring van de Laak – Tremelo (waterbeheer) Move&Shop – Vilvoorde (mobiliteit) Museum of Things for People - Gent N Naar een open, nabij en loketvrij huis van de gemeente Nachtlawaai verminderen d.m.v. technologie en nudging – Leuven (geluidsoverlast) Netwerkregelingen in een stedelijke context – Antwerpen (mobiliteit) O Oases van rust - Dendermonde Op zoek naar digitale oplossingen voor burgerparticipatie Open Data Institute OpenDei P PILL PRECINCT Plaats- en kanaalonafhankelijke sterke authenticatie P meer Proactive Openbaarheid van Bestuur als Linked Open Data – Gent (bestuur) R REVOLT Rainbrain – Roeselare (waterbeheer) Regionaal plugable incentiveringsplatform – Geel S SHOK – Slimme Handel en events met Openbare Kasten SIncR - SustainableInsights for Cities & Retailers Sensoc – Gent (veiligheid) Sharepair Slim Ruimtelijk Plannen Slim Vrachtwagenparkeren Slim beheer openbaar domein - Edegem Slim gemeentevuil - Neerpelt Slimme IoT technologie gekoppeld aan slimme zorgverlening voor levensloopbestendig wonen - Leuven Slimme Markten – Hasselt Slimme mobiliteit als hoeksteen van een levendige dorpskern – Geetbets (mobiliteit) Slimme mobipunten - Peer Slimme stadsdistributie – Hasselt Smart Flow - Herent Smart Innovation Factory – Mechelen Smart Retail Area – Antwerpen Structurering innovatieve studentenprojecten in studentensteden - Leuven T TestTitel van project ThermAi U URBANAGE V VGS@school – Ingelmunster (mobiliteit) VLOED - Gent Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) – Halle W Website van de Toekomst Wegdekkwaliteitsinspectie - Lubbeek Welkomapp voor nieuwkomers Wij Leveren – Leuven  +
• Inleiding Een VLOCA traject biedt de … Inleiding </br> </br>Een VLOCA traject biedt de initiatiefnemer een gestandaardiseerde aanpak in het tot stand brengen van de architecturale elementen van een open city project. </br> De gestandaardiseerde aanpak en deliverables van VLOCA zorgen ervoor dat elk open city project op dezelfde wijze gevormd wordt, kan genieten van elkaars verwezenlijkingen en uiteindelijk resulteert in een optimaal interoperabele oplossing doorheen Vlaanderen.</br> Meer informatie over welke VLOCA trajecten concreet bestaan vind je hier . De gecombineerde OSLO-VLOCA aanpak in het kader van City of Things vind je eveneens vanop die pagina.</br> </br> De vier hoofdonderdelen van de VLOCA aanpak </br> VLOCA vertrekt vanuit de maatschappelijke context en de ambitie van het lokaal bestuur, over een doordachte aaneenschakeling van architecturale elementen, tot aan de uiteindelijke technologische elementen waaraan de oplossing dient te voldoen. </br> We volgen hier vier stappen, waarvan de eerste twee de basis vormen van de uit te werken architectuur:</br> </br> Context </br> Motivatie </br> Bedrijfsarchitectuur </br> IT architectuur </br> De strategie, de bedrijfsarchitectuur en de IT-architectuur vormen samen de Open City Architectuur.</br> </br> Context </br> Onder context verstaan we alle instromen die samenkomen en een idee of concept tot resultaat hebben.</br> </br> </br></br> </br> Open City Ambitie</br> </br> Thematische lokale en bovenlokale open city ambitie</br> Raakvlakken met andere ambities</br> </br> </br> </br> </br> </br> </br> </br> </br> Beleid lokaal bestuur</br> </br> Open City ambitie als antwoord op beleid lokaal bestuur</br> Digitale maturiteit lokaal bestuur</br> </br> </br> </br> </br> </br> </br> </br> </br> Noden en behoeften stakeholders</br> </br> Specifieke noden en behoeften van stakeholders</br> Quadruple helix: overheden, bedrijven, kenniscentra, burgers</br> </br> </br> </br> </br> </br> </br> </br> </br> Omgevingsfactoren</br> </br> Maatschappelijke eisen en beperkingen</br> Beleidsthema’s: milieu, verkeer, economie, …</br> </br> </br> Motivatie </br> De motivatie stelt aan de hand van een aantal vragen de open city ambitie scherp. Deze concretisering zal het trajectambitie kort maar gericht samenvatten.</br> </br> </br></br> </br> Visie</br> </br> Wat is de bestaansreden van dit project?</br> </br> </br> </br> </br> </br> </br> </br> Missie</br> </br> Wat willen we met dit project bereiken?</br> </br> </br> </br> </br> </br> </br> </br> Doel</br> </br> Wat is het doel van dit project?</br> </br> </br> </br> </br> </br> </br> </br> Successfactor</br> </br> Hoe meten we het succes van dit project?</br> </br> Bedrijfsarchitectuur </br> VLOCA architecten werken volgens een standaard methodiek samen met initiatiefnemende lokale besturen in het tot stand komen van een uitgewerkte bedrijfsarchitectuur. In het VLOCA model worden exploratief alle mogelijk relevante elementen opgesomd. De stad voor wie de use case specifiek uitgewerkt wordt maakt de keuze tussen welke elementen in scope van het project zijn en welke niet. De niet meegenomen elementen worden hier gedocumenteerd als startpunt voor vervolgprojecten al of niet in dezelfde stad of gemeente. Tussen de overgebleven elementen worden prioriteiten gesteld, waaruit uiteindelijk een roadmap kan worden gefilterd, dat de aanzet is van het plan van aanpak van het te realiseren project door de stad. Data en informatie wordt hier eveneens bekeken: de informatienoden worden in kaart gebracht. Een OSLO project kan hieruit volgen, met de totstandkoming van een semantische standaard als doel.</br> </br> </br></br> </br> Business capabilities</br> </br> Wat moet de oplossing specifiek kunnen waarmaken?</br> Bestaat uit data vereisten, functionaliteiten en techniciteiten</br> </br> </br> </br> </br> </br> </br> </br> </br> Data vereisten</br> </br> Welke data hebben we nodig?</br> Aan welke parameters moet de data voldoen?</br> </br> </br> </br> </br> </br> </br> </br> </br> Functionaliteiten</br> </br> Wat moet een toepassing met informatie kunnen?</br> Wat is de interactie tussen toepassingen?</br> </br> </br> </br> </br> </br> </br> </br> </br> Techniciteiten</br> </br> Wat zijn de technologische vereisten?</br> Welke technologieën moeten onderling verbonden worden?</br> </br> </br> IT architectuur </br> Een specifieke IT architectuur wordt opgesteld voor de stad die het VLOCA traject initieert. Team VLOCA werkt daarbij nauw samen met het lokaal bestuur en haar gekozen IT partner. Tegelijkertijd zorgt team VLOCA ervoor dat een generieke architectuur wordt uitgewerkt, waarop andere steden en gemeenten hun project in een latere fase kunnen baseren. De specifieke context van het eerste project in onze regio zorgt op deze wijze voor een snelle start voor de volgende projecten, waarbij herbruikbaarheid en interoperabiliteit centraal staan.</br> </br> </br></br> </br> Informatie architectuur</br> </br> Gewenste informatie op dashboards, portaalsite, apps, …</br> Uitgewerkt in een mindmap</br> </br> </br> </br> </br> </br> </br> </br> </br> Data architectuur</br> </br> Voorbereiding voor OSLO traject/ semantische standaard</br> Data governance</br> </br> </br> </br> </br> </br> </br> </br> </br> Applicatie architectuur</br> </br> Rol van relevante toepassingen en hun interactie met informatie</br> Uitgewerkt met een use case diagram</br> </br> </br> </br> </br> </br> </br> </br> </br> Technologische architectuur</br> </br> Hard, soft en hybride infrastructuur voor applicatie architectuur</br> Uitgewerkt met technische tekeningen</br> </br> </br> VLOCA trajectwerking </br> Doel </br> Het doel van VLOCA in een open city project is tweeledig: </br> </br> enerzijds het lokale project zo goed en snel mogelijk te ondersteunen in de bouw van de architectuur specifiek voor de stad of gemeente; </br> anderzijds wordt de focus gelegd op de herbruikbaarheid van de architectuur. Zo laten we toe om andere lokale besturen die op een later moment een gelijkaardig project aanvangen, een snelle en kwalitatieve start te kunnen bezorgen. </br> Inhoud </br> Een VLOCA traject bestaat uit een aantal workshops en vergaderingen, met elk een specifieke focus afhankelijk van de fase waarin het traject zich bevindt. </br> </br> Voortraject: in het voortraject beperken we de deelnemers tot de kernpartners van het project: het lokale bestuur en hun gekozen projectpartners (intercommunales, provinciebestuur, hun IT partner, kennisinstelling) </br> Traject: wanneer het traject ten volle actief is, zijn alle stakeholders welkom om hun bijdrage te leveren aan het traject. We beperken ons hierbij niet aan overheidsinstellingen: inzichten uit de bedrijfswereld, kenniscentra of burgerorganisaties zijn welkom. Het doel is immers niet enkel om de architectuur uit te werken voor één stad, maar een generiek bruikbare architectuur. </br> VLOCA traject: het proces </br> Types werk </br> Een VLOCA traject omhelst drie types werk, die nauw met elkaar verbonden zijn:</br> </br> Bedrijfsarchitectuur: inhoudelijk werk dat focust op de business elementen, belangrijk om nadien een IT architectuur op te definiëren; </br> IT architectuur: inhoudelijk werk dat focust op IT architectuur rekening houdend met de bedrijfsdoelstellingen; </br> Projectbeheer, communicatie en community: vormelijk werk dat focust op het maken van afspraken, disseminatie van de resultaten en het samenwerken van de voor de use case relevante stakeholders uit de quadruple helix; </br> Hieronder beschrijven we in meer detail waarop de focus ligt op elk van deze onderdelen, met in elke fase verbonden deliverables. </br> </br> Detailbeschrijving van proces en deliverables </br> Projectbeheer, communicatie en community </br> Team VLOCA begeleidt de stad in haar ambitie, door professionele ontzorging door middel van projectleiderschap gedurende de architectuurfase van het project. Daarenboven zorgt team VLOCA voor co-creatie en disseminatie via de bovenlokale kanalen. Belanghebbende derden worden betrokken tijdens het project. Het uiteindelijke resultaat wordt bekrachtigd in een architectuurstandaard. In de loop van 2023 plannen we het mechanisme en het proces van de bekrachtiging van de standaard te ontwikkelen.</br> </br> Deliverables </br> De deliverables worden beschreven op één algemene pagina , van waaruit kan worden doorgeklikt naar de sjablonen per deliverable.</br> </br> Standaard schema van een VLOCA traject </br> Het onderstaande plaatje geeft de werkstromen en de deliverables van een VLOCA traject schematisch weer.</br> </br> </br> Positionering van een VLOCA traject </br> Een VLOCA-traject volgt geen Smart City project van A tot Z. VLOCA zal in de beginfase van een project een een aantal stappen zetten en deliverables opleveren die tijdens de levensloop van het project van toegevoegde waarde zal zijn.</br>Dit geven we tevens schematisch weer:  +
• Inleiding Agentschap Innoveren en Ondern … Inleiding </br> Agentschap Innoveren en Ondernemen (VLAIO) voorziet elk jaar middelen voor projecten binnen de oproepen City of Things. Lokale besturen die een maatschappelijke uitdaging op een slimme manier willen aanpakken via Internet of Things (IoT) of met open data kunnen een aanvraag indienen. We mikken op maatschappelijke uitdagingen in de domeinen Smart Economy, Smart Government, Smart Living, Smart People, Smart Mobility en Smart Environment. Samenwerking, opschaling, implementatie, disseminatie, interoperabiliteit en herbruikbaarheid zijn daarbij belangrijke elementen.</br> Omdat we willen dat steden en gemeenten kennis en ervaring opdoen en een heel innovatietraject doorlopen, kunnen projecten met de steun alle nodige externe ondersteuning en expertise inkopen. Ook een proof of concept (PoC), marktverkenning, aanbesteden,… kunnen met de steun gerealiseerd worden.</br> Meer informatie vind je op de VLAIO website .</br> </br> City of Things oproepen </br> City of Things 2018 </br> City of Things 2019 </br> City of Things 2020 </br> City of Things 2021 </br> City of Things 2022 </br> City of Things 2023 </br> City of Things VLOCA trajecten </br> De aanpak voor een gecombineerd VLOCA & OSLO proces voor City of Things trajecten zorgt voor een efficiënte en effectieve benadering van een goede architectuur en datastandaarden.</br> </br> Overzicht City Of Things trajecten </br> Geen resultatenThings trajecten Geen resultaten  +
• Inleiding Circulaire economie is een sle … Inleiding </br> Circulaire economie is een sleutelstrategie om onze maatschappij binnen de planetaire grenzen te sturen, emissies te verminderen en het herstel na covid verder aan te zwengelen. In een circulaire economie gaat het erom producten en materialen zo lang en zo hoogwaardig mogelijk te blijven inzetten met minimale milieu-impacten. Recent zijn steden sterk naar voren gekomen in de circulaire economie transitie, geïllustreerd door intentieverklaringen om een circulaire stad te worden zoals in Leuven of Antwerpen. In stedelijke omgevingen komen veel materiaalstromen samen en zijn er veel consumenten en bedrijven actief om circulaire businessmodellen uit te proberen en op te schalen. Als we materialen en producten kunnen voorzien van de nodige data, die bijvoorbeeld kwaliteit, oorsprong, samenstelling etc. aangeven, kunnen we de meerwaarde van de circulaire economie effectief binnenhalen. Dit stelt heel wat uitdagingen op vlak van data governance, en de vraag is hoe we die best aanpakken door architecturen, standaarden , concepten en modellen te ontwikkelen, temeer omdat er op Europees vlak veel in beweging is als het gaat over rechten en plichten bij het gebruik van data.</br> </br> Sharepair </br> Het Europees Interreg project Sharepair ligt aan de basis van de VLOCA activiteiten rond het thema van repair cafés. De Vlaamse deelnemers van het Sharepair verenigden zich eveneens in de VLOCA activiteiten, en namen enkele marktspelers mee in de co-creatie, met als uiteindelijk doel een VLOCA architectuurstandaard op te stellen rond dit thema.</br> </br> VLOCA verkenningstraject </br> In het najaar van 2021 werd besloten om een kort traject op te starten om dit onderwerp te exploreren vanuit het oogpunt van noden aan open data en de behoefte aan een gestructureerde architectuur. Twee workshops werden gehouden in Leuven, waarin de exploratie werd geconcretiseerd door het samenbrengen van verscheidene stakeholders.</br> Twee workshops werden georganiseerd in dit VLOCA verkenningstraject</br> </br> Werkgroep Type werkgroep Datum Tijd Locatie Circulaire Economie: Repair cafés - Workshop 1 Business werkgroep 2021-10-28 Circulaire Economie: Repair cafés - Workshop 2 Data en informatie werkgroep 2022-03-09 </br> Overzicht Draaiboeken </br>   Actoren Hoe het Digital Product Paspoort gebruiken Hoe kan je gemiste “repair opportunities” in kaart brengen en reduceren? Hoe kunnen we repair cafés en herstel in het algemeen ondersteunen en zo de kans op succesvol herstel vergroten? Overheden Ik wil de bijdrage van reparatie aan de circulaire economie kunnen meten Ik wil gerichte campagnes rond repair cafés lanceren Ik wil kunnen meten hoeveel CO2 er vermeden is doordat burgers kapotte toestellen hersteld hebben Ik wil weten wat de impact van repair cafés/digitale tools is op elektrisch & elektronisch afval Waarom repair data loggen? Wat is een repair café en hoe kan ik er een starten? Overheden Wat is het SHAREPAIR project? Welke data standaard bestaat er in het repair landschap? </br> Beschrijving Architectuur </br> Lessons Learned </br>   Deliverable Versie Actoren Circulaire economie: Repair cafés VLOCA-model V0.2 VLOCA-Model V0.2 Kennisinstellingen Overheden  +
• Inleiding Deze pagina bevat de eerste ve … Inleiding </br> Deze pagina bevat de eerste versie van het VLOCA model. Het is een finale versie die we 1.0 noemen.</br>Dit kwam tot stand na de inhoudelijke intro met de initiatiefnemer van dit VLOCA traject en een studie van de aangeleverde informatie bij de start van het project.</br> </br> Situering van deze deliverable in het traject </br> Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. </br>Het is in de 1.0-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is. </br>Dit document vormt een basis voor het verdere verloop van het traject. </br>In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. </br> </br> Doel en doelgroep </br> Initiatiefnemers (lokale en bovenlokale besturen): De initiatiefnemers en hun project partners werken aan de hand van deze pagina de inhoud verder uit, waarna validatie en prioritering volgt. </br> Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. </br>Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be .</br>Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) </br> Bedrijven en kennisinstellingen: Heb je als bedrijf een visie op de generieke business vereisten van dit thema, dan nodigen we je uit om samen deze oefening verder mee vorm te geven.</br>Ben je leverancier aan overheden, vragen we je specifieke oplossingen niet te vermelden maar de generieke business en IT architectuur in co-creatie mee uit te werken. </br> Burgers en burgergroeperingen: </br>Voel je je als burger aangesproken door dit onderwerp en je hebt een visie op de ontwikkeling van oplossingen van dit thema, laat het ons zeker weten. </br> </br> Aanpak (korte beschrijving) </br> In dit VLOCA model v1.0 vertrekken we van de visie, missie en doelen zoals ze geformuleerd worden door de initiatiefnemer. </br>Deze gegevens worden verder verfijnd en uitgesplitst in objectieven, en hun de daaraan gelinkte business capabilities, data vereisten, functionele capabilities en technische vereisten. Een volledige omschrijving van het VLOCA-model kan je hier lezen.</br>In deze fase exploreert team VLOCA tevens de extra mogelijkheden rond deze use case. Deze worden in het project gevalideerd en al of niet in scope van het project genomen. Wanneer ze niet in scope worden genomen, kan deze bijdragen aan het uitwerken van een ander of een vervolgproject.</br> </br> Inhoud </br> Hieronder kan je de elementen van versie 1.0 van dit VLOCA model bekijken.</br> </br> </br></br> </br> Level2 </br> </br> Level3 </br> </br> </br></br> </br> CoT Regionaal plugable incentiveringsplatform Geel</br> </br> </br> 2022</br> </br> VLOCA-model versie 1.0</br> </br> </br> VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be</br> </br> </br> Beschrijving en aanpak:</br> </br> https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model </br> </br> </br> </br> </br> </br> Strategie van de open city uitdaging </br> </br> </br> </br> </br> </br> </br> </br> Status</br> </br> Toelichting</br> </br> Beschrijving</br> </br> </br> Visie</br> </br> Voorstel</br> </br> Wat is de bestaansreden ?</br> </br> Steden hebben het moeilijk om het gedrag van de burgers te veranderen zonder incentivering. Uit vorige projecten blijkt dat 'vouchers' en 'lokale (digitale) munten' (sociale krediet zoals duimpjes up) daarvoor goed werken. Maar die worden ook te snel verzilverd in euro's en blijven niet binnen het systeem. Daarnaast leiden verschillende incentiveringen ook tot eigen vouchers of (digitale) munten hetgeen resulteert in een versnipperd landschap van systemen. De keuze om al de lokale economie te steunen dan wel expliciet te kiezen voor een digitale munt die regionaal besteed kan worden (= aantrekkelijker voor de burger) moet bij de initiatiefnemer (lees: lokaal bestuur) liggen: waar steun aan lokale economie belangrijkste finaliteit is, moet er gekozen kunnen worden voor een lokale munt. Wanneer een incentivering op een bepaalde maatschappelijk wenselijk gedrag ligt, is een regionale campagne die toeleidt tot een regionale munt vaak interessanter. -Lokale besturen wensen ook aan de bestedingszijde meer te kunnen richten naar doelen, projecten... met een maatschappelijke meerwaarde.</br> </br> </br> Missie</br> </br> Voorstel</br> </br> Wat willen we bereiken ?</br> </br> Een oplossing die zowel het duurzaam gedrag van de burger wil beinvloeden door beloning alsook (of) de lokale economie of lokale organisaties wil ondersteunen.</br> </br> </br> Doel</br> </br> Voorstel</br> </br> Wat is het doel van dit project ?</br> </br> Een platform die eigenlijk 'goed gedrag' beloont met een 'lokale munt' die enkel in de regio kan ingeruild/gespendeerd worden = 'regio breed incentiveringsplatform' die ook dmv een 'schaalbaar' architectuur snel en efficient uitrolbaar is in andere regio die dat zouden wensen. De Lokale/digitale munt moet ook kunnen dienen als 'betaalmiddel' tussen B2B om die munt zo lang mogelijk binnen de regio te houden. Het eigenlijke 'beloning' van goed gedrag zal niet in het platform zelf gebeuren, maar via de 'verticals', dus de applicaties die allemaal dit platform zullen gebruiken voor de transacties bij te houden en uitgaven te kunnen doen.</br> </br> </br> Succesfactor</br> </br> Voorstel</br> </br> Hoe meten we succes ? (SMART)</br> </br> Een schaalbaar regiobreed incentiveringsplatform met een 'slimme' configuratie die volledig parametriseerbaar is tegen 2025. schaalbaar = - uitbreidbaar naar andere gemeenten / regio's - andere (nieuwe of bestaande) use cases moeten kunnen koppelen met het platform - ook aan bestedingszijde moet het platform flexibiliteit bieden (besteding bij handelaar, B2B, donatie aan lokale organisatie/doel/project, andere (crowd funding) systemen...</br> </br> </br> </br> </br> </br> Use cases </br> </br> </br> </br> </br> </br> ID</br> </br> Status</br> </br> Samenvatting</br> </br> Beschrijving</br> </br> </br> UC1</br> </br> Voorstel</br> </br> UC1: Digitale Wallet</br> </br> Digitale wallet van meerdere soorten munten (lokaal, regionaal, enz. En evt andere systemen, zoals Uitpas) waar zowel stortingen, uitgaven/overschrijven en consulteren van saldo's door de eigenaar en participanten kunnen gebeuren</br> </br> </br> UC2</br> </br> Voorstel</br> </br> UC2: Integratie</br> </br> Integratie met bestaande applicaties zoals de stadsapplicaties, websites, cadeaubonnen applicaties en zelfs mijnburgerprofiel</br> </br> </br> UC3</br> </br> Voorstel</br> </br> UC3: Participatie Mechanisme</br> </br> Een gebruiksvriendelijke platform om zowel als 'donor' als 'collector' als 'spender' zichzelf kunnen registreren en 'regels'/'parameters' voor ontvangen en gebruiken kunnen vastgelegd worden. Voor definities Donor, Collector en Spender, zie beneden Metadata</br> </br> </br> UC4</br> </br> Voorstel</br> </br> UC4: Marketing (CRM)</br> </br> Aanradingsprogramma om de lokale economie aan te trekken om mee te doen zowel als 'donor' (participerende organisatie die een goed gedrag willen belonen) alsook als 'collector' (=winkels die deze munt aanvaarden als betaling) Inclusief communicatie platform om berichten, nieuwsletter, alerts, bevestigingen enz te kunnen beheren.</br> </br> </br> UC5</br> </br> Voorstel</br> </br> UC5: Omzettingsmechanisme</br> </br> Een facturatie en betalings systeem die de eerste en allerlaatste conversie regelt, zodat de lokale munt in praktijk omgezet kunnen worden in euros.</br> </br> </br> UC6</br> </br> Voorstel</br> </br> UC6: Inzichten & Dashboarding</br> </br> Het verkrijgen van inzichten in het gebruik en de positieve impact op 'goed gedrag' en 'lokale economie' die het beleid kan gebruiken. (Analyse van 'verval' of 'demurage' = waardeverlies, waar gaat dat geld naartoe bvb goed doel,...)</br> </br> </br> UC7</br> </br> Voorstel</br> </br> UC7: Principes</br> </br> Schaalbaarheid (voor extra steden en regio's), interoperabiliteit (voor extra toepassingen) en cross verticale principes van het platform is cruciaal. schaalbaar = - uitbreidbaar naar andere gemeenten / regio's - andere (nieuwe of bestaande) use cases moeten kunnen koppelen met het platform - ook aan bestedingszijde moet het platform flexibiliteit bieden (besteding bij handelaar, B2B, donatie aan lokale organisatie/doel/project, andere (crowd funding) systemen...</br> </br> </br> UC8</br> </br> Voorstel</br> </br> UC8: Draaiboeken</br> </br> Een bibliotheek leveren van draaiboeken die de steden en gemeenten een 'how to' uitleggen ifv hun behoeften en context</br> </br> </br> UC9</br> </br> Voorstel</br> </br> UC9: Compensatie mogelijkheden (governance model)</br> </br> Bij het kiezen voor een (additionele) lokale economie ondersteuning, willen we een evenwichtig systeem hebben tussen regionaal en lokaal muntsystemen, opdat eventueel geld zou kunnen terugvloeien tussen gemeenten/steden. Onevenwichtig is bvb indien een gemeente A sponsort met de hoop op het spenderen bij lokale handelaars terwijl er factueel buiten proporties uitgegeven wordt door de burgers in gemeente B.</br> </br> </br> UC10</br> </br> Voorstel</br> </br> UC10:helpdesk, klachten, reviews</br> </br> Helpdesk bij vragen, FAQ, klachten en reviews door alle betrokken partijen</br> </br> </br> UC11</br> </br> Voorstel</br> </br> UC11:betalingen</br> </br> Vanuit het platform n betalingsmodule die over alle 'verticals' heen kan gebruikt worden, om te vermijden dat de handelaar verschillende systemen moet hebben per vertikaal om geld te kunnen 'krijgen' van de 'shopper'</br> </br> </br> </br> </br> </br> Metadata </br> </br> </br> </br> </br> </br> </br> </br> Metaveld</br> </br> Beschrijving</br> </br> </br> </br> </br> Regionaal Munt</br> </br> Een munt die breder is dan lokaal, dus weider geografisch alsook sectorieel, dit wordt gebruikt om puur een gedrag te stimuleren bvb</br> </br> </br> </br> </br> Lokaal Munt</br> </br> Een munt die beperkt geografisch of sectorisch bruikbaar is, dit wordt gebruikt om een geografische of sector te ondersteunen</br> </br> </br> </br> </br> Donor</br> </br> organisatie, lokaal bestuur, bedrijf, persoon die euros omzet in digitale munt</br> </br> </br> </br> </br> Collector</br> </br> (=handelaar) organisatie, lokaal bestuur, bedrijf die digitale munt omzet in euros (niet voorzien dat burgers dit kunnen)</br> </br> </br> </br> </br> Spender</br> </br> (=participant) deelnemer die lokale munten ontvangt als beloning en die deze kan spenderen bij een collector</br> </br> </br> </br> </br> User</br> </br> (=gebruiker) burger, organisatie, lokaal bestuur, bedrijf... dat kan inloggen en gebruik maken van de digitale wallet</br> </br> </br> </br> </br> Guest</br> </br> (= tijdelijke gebruiker) burger, organisatie, lokaal bestuur, bedrijf... Anoniem in de wallet applicatie wil rondneuzen om te zien wat er wordt aangeboden</br> </br> </br> </br> </br> Wallet applicatie</br> </br> De 'kern' applicatie die de transacties van alle digitale munten beheert</br> </br> </br> </br> </br> Vertical</br> </br> Een applicatie (incentiveringsproject) die gebruikt maakt van de 'wallet' applicatie</br> </br> </br> </br> </br> Superadmin</br> </br> is een user die het volledig incentiveringsplatform beheert en toegang heeft tot alle economieen via het dashboard</br> </br> </br> </br> </br> Owner</br> </br> is de initiatiefnemer van een incentive. Vaak een lokale overheid die de economy beheert. Een owner kan inloggen op het incentiveringsplatform en is en user in het systeem</br> </br> </br> </br> </br> Advertiser</br> </br> De financierder van een incentive iseen advertiser. Een advertiser stort de financiele middelen op een fonds. Advertisers zijn geen users in het systeem</br> </br> </br> </br> </br> </br> Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases </br> </br> </br> </br> </br> </br> ID</br> </br> Type</br> </br> Samenvatting</br> </br> Beschrijving</br> </br> </br> UC1</br> </br> Use case</br> </br> UC1: Digitale Wallet</br> </br> Digitale wallet van meerdere soorten munten (lokaal, regionaal, enz. En evt andere systemen, zoals Uitpas) waar zowel stortingen, uitgaven/overschrijven en consulteren van saldo's door de eigenaar en participanten kunnen gebeuren</br> </br> </br> BC1.1</br> </br> Business capability</br> </br> Donor</br> </br> Als donor wil ik aan een ontvanger een som in een digitale munt kunnen storten</br> </br> </br> DV1.1.1</br> </br> Data vereiste</br> </br> Transactie met A (betaler) en B (ontvanger) : tijd, bedrag, reden, geldigheidsduur</br> </br> </br> DV1.1.2</br> </br> Data vereiste</br> </br> </br> FC1.1.1</br> </br> Functionaliteit</br> </br> Banking Applicatie</br> </br> </br> FC1.1.2</br> </br> Functionaliteit</br> </br> Controle Veiligheid</br> </br> </br> TV1.1.1</br> </br> Techniciteit</br> </br> Authenticatie Systeem</br> </br> </br> TV1.1.2</br> </br> Techniciteit</br> </br> Verificatie Systeem</br> </br> </br> </br> </br> </br> BC1.2</br> </br> Business capability</br> </br> Collector</br> </br> Als collector wil ik mijn digitale munt kunnen uitgeven binnen een handelstransactie</br> </br> </br> </br> </br> </br> BC1.3</br> </br> Business capability</br> </br> Spender</br> </br> Als spender wil ik mijn saldo van de digitale munt op mijn rekening kunnen consulteren in real time</br> </br> </br> </br> </br> </br> BC1.4</br> </br> Business capability</br> </br> betaling</br> </br> Als spender wil ik gemakkelijk, klantvriendelijk, kunnen betalen zoals bvb dit met een bankkaart mogelijk is</br> </br> </br> </br> </br> </br> BC1.5</br> </br> Business capability</br> </br> Overzicht</br> </br> Als spender wil ik duidelijk informatie kunnen terugvinden over mijn munten, zoals type, houbaarheidsdatum, demurrage, spelregels van de munt enz.</br> </br> </br> </br> </br> </br> BC1.6</br> </br> Business capability</br> </br> verzilveren</br> </br> Als collector wil ik mijn digitale munten gemakkelijk kunnen verzilveren tot euros</br> </br> </br> </br> </br> </br> BC1.7</br> </br> Business capability</br> </br> cadeaubonnen</br> </br> Als donor/collector wil ik aan de user/spender 'cadeaubonnen' kunnen schenken via het platform (bij een volgend bezoek)</br> </br> </br> </br> </br> </br> BC1.8</br> </br> Business capability</br> </br> gratis parkeren</br> </br> Als donor wil ik bvb n gratis parking kunnen schenken aan de spender in mijn winkel</br> </br> </br> </br> </br> </br> ID</br> </br> Type</br> </br> Samenvatting</br> </br> Beschrijving</br> </br> </br> UC2</br> </br> Use case</br> </br> UC2: Integratie</br> </br> Integratie met bestaande applicaties zoals de stadsapplicaties, websites, cadeaubonnen applicaties en zelfs mijnburgerprofiel</br> </br> </br> BC2.1</br> </br> Business capability</br> </br> Integratie Applicaties</br> </br> Als superadmin wil ik een 'vertaling' van de interne standaarden naar de 'standaarden' van de externe participerende applicaties en omgekeerd kunnen doorvoeren</br> </br> </br> </br> </br> </br> BC2.2</br> </br> Business capability</br> </br> cross applicatie</br> </br> Als superadmin wil ik alle participerende applicaties op n scherm of via een gemakkelijke integratie kunnen gevisualiseerd worden, maar ook interacties tussen de applicaties (transfer van tokens tot euros van n applicatie tot een andere)</br> </br> </br> </br> </br> </br> BC2.3</br> </br> Business capability</br> </br> op mijnburgerprofiel</br> </br> Als user wil ik mijn wallet ook kunnen zien via mijnburgerprofiel</br> </br> </br> </br> </br> </br> ID</br> </br> Type</br> </br> Samenvatting</br> </br> Beschrijving</br> </br> </br> UC3</br> </br> Use case</br> </br> UC3: Participatie Mechanisme</br> </br> Een gebruiksvriendelijke platform om zowel als 'donor' als 'collector' als 'spender' zichzelf kunnen registreren en 'regels'/'parameters' voor ontvangen en gebruiken kunnen vastgelegd worden. Voor definities Donor, Collector en Spender, zie beneden Metadata</br> </br> </br> BC3.1</br> </br> Business capability</br> </br> Donor Registratie</br> </br> Als donor wil ik mij gemakkelijk kunnen registreren om als 'donor' van fondsen te kunnen fungeren.</br> </br> </br> </br> </br> </br> BC3.2</br> </br> Business capability</br> </br> Handelaar Registratie</br> </br> Als Handelaar of organisatie wil ik mij gemakkelijk kunnen registreren om als 'collector' te kunnen fungeren</br> </br> </br> </br> </br> </br> BC3.3</br> </br> Business capability</br> </br> Burger Registratie</br> </br> Als burger wil ik mij gemakkelijk kunnen registreren als 'spender' om te kunnen participeren in het verkrijgen en spenderen van de digitale munt</br> </br> </br> </br> </br> </br> BC3.4</br> </br> Business capability</br> </br> Burger Promo Participatie</br> </br> Als spender wil ik mij gemakkelijk kunnen registreren om mee te doen aan specifieke acties (promoties ed)</br> </br> </br> </br> </br> </br> BC3.5</br> </br> Business capability</br> </br> Hierarchie Rechten</br> </br> Als owner wil ik een hierarchie van 'rechten' kunnen invoeren om regels te kunnen 'hierarchiseren' ten behoeve van de gebruiksvriendelijkheid van de burger/gebruiker</br> </br> </br> </br> </br> </br> BC3.6</br> </br> Business capability</br> </br> Regels en Rechten</br> </br> Als owner wil ik regels kunnen creeren en invoeren die de toekenning (via de verticals/apps) alsook uitgave (houdbaarheids termijn, minimale threshold, ...) van de munten bepalen</br> </br> </br> </br> </br> </br> BC3.7</br> </br> Business capability</br> </br> Limiet van donor</br> </br> Als owner wil ik de donors een mogelijkheid kunnen bieden voor een limiet die gemakkelijk zichtbaar moet zijn in de applicatie (hoeveel totale munten zijn nog beschikbaar bij die actie). Uiteraard zal dit in de applicaties (verticals) zelf moeten gebeuren, maar ook in de wallet kan de 'fondsen' van de donor vergeleken worden ifv die limiet.</br> </br> </br> </br> </br> </br> BC3.8</br> </br> Business capability</br> </br> Anonieme Test Registratie</br> </br> Als guest wil ik anoniem kunnen uitproberen om te zien wat er in het systeem beschikbaar is (zonder echte deelname met transacties)</br> </br> </br> </br> </br> </br> BC3.9</br> </br> Business capability</br> </br> Vendorlocking vermijdend</br> </br> De beheerder van het platform moet 'naadloos' kunnen veranderd worden zonder het project in gevaar te brengen. Dus de data ownership en documentatie moet voldoende beschreven en beschikbaar zijn om de 'transitie' en 'handover' zo optimaal mogelijk te maken.</br> </br> </br> </br> </br> </br> BC3.10</br> </br> Business capability</br> </br> e-inclusie</br> </br> Als user (spender, donor en collector) die niet digitaal ben wil ik ook via andere manieren kunnen registreren en gebruik maken van het platform.</br> </br> </br> </br> </br> </br> BC3.10</br> </br> Business capability</br> </br> Validatie 'goede doel' collector</br> </br> Als collector wil ik kunnen bewijzen dat ik een 'goede doel' ben via bvb de VKBO/mijnburgerprofiel, zodat bij het afromen of bij doorlopende of automatische betalingen er enkel naar 'goede doelen' bvb betaald zullen worden.</br> </br> </br> </br> </br> </br> ID</br> </br> Type</br> </br> Samenvatting</br> </br> Beschrijving</br> </br> </br> UC4</br> </br> Use case</br> </br> UC4: Marketing (CRM)</br> </br> Aanradingsprogramma om de lokale economie aan te trekken om mee te doen zowel als 'donor' (participerende organisatie die een goed gedrag willen belonen) alsook als 'collector' (=winkels die deze munt aanvaarden als betaling) Inclusief communicatie platform om berichten, nieuwsletter, alerts, bevestigingen enz te kunnen beheren.</br> </br> </br> </br> </br> </br> BC4.1</br> </br> Business capability</br> </br> Doelgroepen</br> </br> Als owner wil ik een Identificatie van de doelgroepen (donors, handelaars/collectors en burgers/spenders) kunnen bepalen</br> </br> </br> </br> </br> </br> BC4.2</br> </br> Business capability</br> </br> Targeting</br> </br> Als owner wil ik een 'doellijst' (targetlist) kunnen opladen in een CRM voor mijn 'acquisitie' strategie</br> </br> </br> </br> </br> </br> BC4.3</br> </br> Business capability</br> </br> Acquisitie</br> </br> Als owner wil ik mijn doelgroep kunnen benaderen met promoties om bij interesse de regels te volgen om te kunnen genieten van een donatie</br> </br> </br> </br> </br> </br> BC4.4</br> </br> Business capability</br> </br> Communicatie</br> </br> Als donor wil ik eventueel een mogelijkheid om extra reklame te krijgen (banner ? enz.) door een bepaalde visibiliteit te krijgen bij het gebruik van het platform. Bvb gesponsord door xyz, enz.</br> </br> </br> </br> </br> </br> ID</br> </br> Type</br> </br> Samenvatting</br> </br> Beschrijving</br> </br> </br> UC5</br> </br> Use case</br> </br> UC5: Omzettingsmechanisme</br> </br> Een facturatie en betalings systeem die de eerste en allerlaatste conversie regelt, zodat de lokale munt in praktijk omgezet kunnen worden in euros.</br> </br> </br> BC5.1</br> </br> Business capability</br> </br> Donatie</br> </br> Als owner wil ik de donoren kunnen factureren opdat dit bedrag (min administratie kosten?) worden gestort op hun digitale munt rekening.</br> </br> </br> </br> </br> </br> BC5.2</br> </br> Business capability</br> </br> Verzilvering</br> </br> Als collector wil ik een factuur kunnen sturen naar het beleid om mijn digitale munt te verzilveren in echte euros</br> </br> </br> </br> </br> </br> BC5.3</br> </br> Business capability</br> </br> NBB Licentie</br> </br> Als owner wil ik aan de e-money licentie voorwaarden (Nationale Bank van Belgie) voldoen</br> </br> </br> </br> </br> </br> BC5.4</br> </br> Business capability</br> </br> Wisselkoersen</br> </br> Als owner wil ik de wisselkoersen (munt vs euros, munt vs andere munt) kunnen invoeren, bijhouden, visualiseren en gebruiken bij transacties.</br> </br> </br> </br> </br> </br> BC5.5</br> </br> Business capability</br> </br> Waardeverlies</br> </br> Als owner wil ik de waardeverlies (vervallen munten) kunnen visualiseren.</br> </br> </br> </br> </br> </br> BC5.6</br> </br> Business capability</br> </br> Waarde Fluctuaties?</br> </br> Als owner wil ik de waarde van een munt ifv vraag en aanbod kunnen laten fluctueren ?</br> </br> </br> </br> </br> </br> BC5.7</br> </br> Business capability</br> </br> Afromen Slaapende munten</br> </br> Als owner wil ik het 'afromen' van slapende munten (die niet meer gebruikt kunnen worden) kunnen 'schenken' aan goede doel projecten of organisaties.</br> </br> </br> </br> </br> </br> ID</br> </br> Type</br> </br> Samenvatting</br> </br> Beschrijving</br> </br> </br> UC6</br> </br> Use case</br> </br> UC6: Inzichten & Dashboarding</br> </br> Het verkrijgen van inzichten in het gebruik en de positieve impact op 'goed gedrag' en 'lokale economie' die het beleid kan gebruiken. (Analyse van 'verval' of 'demurage' = waardeverlies, waar gaat dat geld naartoe bvb goed doel,...)</br> </br> </br> BC6.1</br> </br> Business capability</br> </br> Doelgroep Analyse</br> </br> Als owner (en donor) wil ik mijn campagne resultaten kunnen meten om de doelgroepen beter te kennen</br> </br> </br> </br> </br> </br> BC6.2</br> </br> Business capability</br> </br> ROI berekening</br> </br> Als owner en donor wil ik onze beleidsdoelstellingen kunnen formuleren en meten als KPIs om een actie of verschillende acties samen te evalueren op succes (ROI)</br> </br> </br> </br> </br> </br> BC6.3</br> </br> Business capability</br> </br> Rapportage</br> </br> Als owner en donor wil ik alle betalingen/transacties per actie (gedrag) en per doelgroep kunnen analyseren en visualiseren</br> </br> </br> </br> </br> </br> BC6.4</br> </br> Business capability</br> </br> Drill Down</br> </br> Als owner wil ik alle transacties die binnen een regio (of sector, ed meer) werden gespendeerd kunnen analyseren en visualiseren</br> </br> </br> </br> </br> </br> BC6.5</br> </br> Business capability</br> </br> Churn Prediction</br> </br> Als owner wil ik kunnen zien welke gebruikers het platform bvb minder en minder gebruiken en waarom en wat kunnen we doen om die weer naar ons toe te trekken</br> </br> </br> </br> </br> </br> BC6.6</br> </br> Business capability</br> </br> Forecasten</br> </br> Als owner of Vertical wil ik een 'forecast' kunnen doen van de donors, transacties, saldo's ed meer in de komende periodes</br> </br> </br> </br> </br> </br> ID</br> </br> Type</br> </br> Samenvatting</br> </br> Beschrijving</br> </br> </br> UC7</br> </br> Use case</br> </br> UC7: Principes</br> </br> Schaalbaarheid (voor extra steden en regio's), interoperabiliteit (voor extra toepassingen) en cross verticale principes van het platform is cruciaal. schaalbaar = - uitbreidbaar naar andere gemeenten / regio's - andere (nieuwe of bestaande) use cases moeten kunnen koppelen met het platform - ook aan bestedingszijde moet het platform flexibiliteit bieden (besteding bij handelaar, B2B, donatie aan lokale organisatie/doel/project, andere (crowd funding) systemen...</br> </br> </br> BC7.1</br> </br> Business capability</br> </br> Integratie nieuwe stad of gemeente</br> </br> Als super admin wil ik een nieuwe extra lokale overheid tot het incentiveringsplatform kunnen toevoegen</br> </br> </br> </br> </br> </br> BC7.2</br> </br> Business capability</br> </br> Integratie Applicatie</br> </br> Als super admin wil ik een nieuwe extra applicatie kunnen toevoegen (zowel donor als besteders)</br> </br> </br> </br> </br> </br> BC7.3</br> </br> Business capability</br> </br> OSLO standaarden</br> </br> Als super admin wil ik dat mijn datamodel volledig volgens de OSLO standaarden toegankelijk worden gesteld</br> </br> </br> </br> </br> </br> BC7.4</br> </br> Business capability</br> </br> herbruikbare munten</br> </br> Als superadmin wil ik dat de munten kunnen hergebruikt worden door andere applicaties om te vermijden dat er telkens een nieuwe munt wordt gegenereerd.</br> </br> </br> </br> </br> </br> BC7.5</br> </br> Business capability</br> </br> punten vs munten</br> </br> Als super admin wil ik dat zowel munten als punten kunnen opgeslagen en gebruikt worden in de wallet</br> </br> </br> </br> </br> </br> BC7.6</br> </br> Business capability</br> </br> Acties ipv munten of punten</br> </br> Als super admin wil ik ook 'acties' willen registreren ipv munten of punten, bvb 'planten van bomen'</br> </br> </br> </br> </br> </br> BC7.7</br> </br> Business capability</br> </br> AML en KYC</br> </br> Als superadmin moet ik de AML en KYC kunnen garanderen.</br> </br> </br> </br> </br> </br> BC7.8</br> </br> Business capability</br> </br> Verdoken beloning</br> </br> Als superadmin wil ik de 'administratie' kunnen informeren van de premies die betaald werden aan de spenders om zo bvb verdoken salarissen/compensaties te kunnen aangeven.</br> </br> </br> </br> </br> </br> BC7.9</br> </br> Business capability</br> </br> Actie voor actie</br> </br> Als super admin wil ik ook dat bij geleverde actie aan iemand en tegoed komt te staan van een actie in de andere richting (klusjes voor andere klusjes)</br> </br> </br> </br> </br> </br> ID</br> </br> Type</br> </br> Samenvatting</br> </br> Beschrijving</br> </br> </br> UC8</br> </br> Use case</br> </br> UC8: Draaiboeken</br> </br> Een bibliotheek leveren van draaiboeken die de steden en gemeenten een 'how to' uitleggen ifv hun behoeften en context</br> </br> </br> BC8.1</br> </br> Business capability</br> </br> Nieuwe ontwikkeling</br> </br> Als overheid wil ik alle versies van draaiboeken, bestekteksten, enz. voor opstartende lokale overheden kunnen bewaren, delen en publiceren</br> </br> </br> </br> </br> </br> ID</br> </br> Type</br> </br> Samenvatting</br> </br> Beschrijving</br> </br> </br> UC9</br> </br> Use case</br> </br> UC9: Compensatie mogelijkheden (governance model)</br> </br> Bij het kiezen voor een (additionele) lokale economie ondersteuning, willen we een evenwichtig systeem hebben tussen regionaal en lokaal muntsystemen, opdat eventueel geld zou kunnen terugvloeien tussen gemeenten/steden. Onevenwichtig is bvb indien een gemeente A sponsort met de hoop op het spenderen bij lokale handelaars terwijl er factueel buiten proporties uitgegeven wordt door de burgers in gemeente B.</br> </br> </br> BC9.1</br> </br> Business capability</br> </br> Automatische terugvloeing</br> </br> Als overheid en lokaal beleid wil ik dat bij niet evenwichtige transfers van waarden tussen regios er een compensatie kan 'gefactureerd' worden om die evenwicht opnieuw in te stellen (bvb een gemeente is donor, maar alle burgers kopen bij een handelaar bij een andere participerende gemeente (met akkoord), wat niet echt de bedoeling was, moeten de fondsen ook kunnen terugvloeien tussen de gemeenten)</br> </br> </br> </br> </br> </br> BC9.2</br> </br> Business capability</br> </br> Inzichten</br> </br> Als owner wil inzichten kunnen geven van waar munten gespendeerd worden en vergelijken met wie de donoren waren om zo een vergelijking te kunnen maken van het evenwichtssysteem</br> </br> </br> </br> </br> </br> BC9.3</br> </br> Business capability</br> </br> goed gedrag vs lokale economie</br> </br> Als owner wil ik gemakkelijk kunnen kiezen welke munt ik wil gebruiken ifv of het een 'goed gedrag beloning' en/of 'lokale economie steunen'</br> </br> </br> </br> </br> </br> ID</br> </br> Type</br> </br> Samenvatting</br> </br> Beschrijving</br> </br> </br> UC10</br> </br> Use case</br> </br> UC10:helpdesk, klachten, reviews</br> </br> Helpdesk bij vragen, FAQ, klachten en reviews door alle betrokken partijen</br> </br> </br> BC10.1</br> </br> Business capability</br> </br> Standaard Antwoorden</br> </br> Als medewerker wil ik efficient standaard antwoorden kunnen beantwoorden op standaard vragen</br> </br> </br> </br> </br> </br> BC10.2</br> </br> Business capability</br> </br> FAQ</br> </br> Als medewerker wil ik mijn FAQ telkens meer relevanter maken ifv de adhoc vragen die telkens weer binnenkomen</br> </br> </br> </br> </br> </br> BC10.3</br> </br> Business capability</br> </br> Klachten</br> </br> Als user wil ik mijn klachten ivm het platform (en 'vertikalen) eenvoudig kunnen communiceren</br> </br> </br> </br> </br> </br> BC10.4</br> </br> Business capability</br> </br> Reviews</br> </br> Als user wil ik mijn tevredenheid kunnen uitdrukken via reviews</br> </br> </br> </br> </br> </br> BC10.5</br> </br> Business capability</br> </br> Inzichten</br> </br> Als owner wil inzichten kunnen halen van de vragen, klachten en reviews om het platform telkens relevanter te maken</br> </br> </br> </br> </br> </br> BC10.6</br> </br> Business capability</br> </br> Fraudebestrijding</br> </br> Als superadmin moet ik de AML en KYC kunnen garanderen.</br> </br> </br> </br> </br> </br> ID</br> </br> Type</br> </br> Samenvatting</br> </br> Beschrijving</br> </br> </br> UC11</br> </br> Use case</br> </br> UC11:betalingen</br> </br> Vanuit het platform n betalingsmodule die over alle 'verticals' heen kan gebruikt worden, om te vermijden dat de handelaar verschillende systemen moet hebben per vertikaal om geld te kunnen 'krijgen' van de 'shopper'</br> </br> </br> BC11.1</br> </br> Business capability</br> </br> Handelaars</br> </br> Als collector wil ik via n applicatie betalingen van allerlei munten kunnen ontvangen</br> </br> </br> </br> </br> </br> BC11.2</br> </br> Business capability</br> </br> Shopper</br> </br> Als spender wil ik via n applicatie mijn betalingen van allerlei munten kunnen uitvoeren</br> </br> </br> </br> </br> </br> BC11.3</br> </br> Business capability</br> </br> Inzichten</br> </br> Als super admin wil ik kunnen zien hoeveel 'geweigerde' of 'niet doorgegaan' betalingen zijn geweest met reden waarom</br> </br> </br> </br> </br> </br> BC11.4</br> </br> Business capability</br> </br> Commissies</br> </br> Als super admin wil ik een 'commissie' kunnen 'aftrekken' voordat het 'geld' naar de collector gaat of van de donor komt</br> </br> </br> </br> </br> </br> BC11.5</br> </br> Business capability</br> </br> Fraudebesrijding</br> </br> Als super admin wil ik mijn betalingsapplicatie kunnen monitoren en beveiligen tegen fraude</br> </br> </br> </br> </br> </br> BC11.6</br> </br> Business capability</br> </br> Betalingskaarten</br> </br> Als super admin wil ik de gebruikers een electronische chip kaart (zelfde formaat Maestro en kredietkaarten) kunnen geven waarmee ook betalingen kunnen gebeuren</br> </br> </br> </br> </br> </br> BC11.7</br> </br> Business capability</br> </br> Domiciliering/doorlopende opdrachten</br> </br> Als spender wil ik mijn betalingen ook recurrent kunnen laten uitvoeren naar een goede doel</br> </br> </br> </br> </br> </br> BC11.8</br> </br> Business capability</br> </br> Overschrijvingen</br> </br> Als spender wil ik mijn betaling ook via een overschrijving, domiciliering, doorlopende opdracht of automatisch doorsturen naar goede doelen bvb kunnen doen naar derden</br> </br> </br> </br> </br> </br> BC11.9</br> </br> Business capability</br> </br> Cancellations</br> </br> Als collector wil ik de betaling kunnen terugdraaien (bij teruggave product) naar de spender</br> </br> </br> </br> </br> </br> BC11.10</br> </br> Business capability</br> </br> QR of andere 'bonnen'</br> </br> Als spender wil ik via een code (QR bvb) mijn betaling kunnen doen</br> </br> </br> </br> </br> </br> BC11.11</br> </br> Business capability</br> </br> Gecombineerde munten</br> </br> Als spender wil ik 'cross' munten betalingen kunnen uitvoeren, dus n betaling die van mijn verschillende munten de saldo afhalen. saldo afhalen.  +
• Inleiding Deze pagina bevat de eerste ve … Inleiding </br> Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we 0 noemen.</br>Dit kwam tot stand na de inhoudelijke intro met de initiatiefnemer van dit VLOCA traject en een studie van de aangeleverde informatie bij de start van het project.</br> </br> Situering van deze deliverable in het traject </br> Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. </br>Het is in de 0-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is. </br>Dit document vormt een basis voor het verdere verloop van het traject. </br>In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. </br> </br> Doel en doelgroep </br> Initiatiefnemers (lokale en bovenlokale besturen): De initiatiefnemers en hun project partners werken aan de hand van deze pagina de inhoud verder uit, waarna validatie en prioritering volgt. </br> Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. </br>Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be .</br>Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) </br> Bedrijven en kennisinstellingen: Heb je als bedrijf een visie op de generieke business vereisten van dit thema, dan nodigen we je uit om samen deze oefening verder mee vorm te geven.</br>Ben je leverancier aan overheden, vragen we je specifieke oplossingen niet te vermelden maar de generieke business en IT architectuur in co-creatie mee uit te werken. </br> Burgers en burgergroeperingen: </br>Voel je je als burger aangesproken door dit onderwerp en je hebt een visie op de ontwikkeling van oplossingen van dit thema, laat het ons zeker weten. </br> </br> Aanpak (korte beschrijving) </br> Andere versie</br> </br> Inhoud </br> Hieronder kan je de elementen van versie 0 van dit VLOCA model bekijken.van versie 0 van dit VLOCA model bekijken.  +
• Inleiding Deze pagina bevat de eerste ve … Inleiding </br> Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we 0 noemen.</br>Dit kwam tot stand na de inhoudelijke intro met de initiatiefnemer van dit VLOCA traject en een studie van de aangeleverde informatie bij de start van het project.</br> </br> Situering van deze deliverable in het traject </br> Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. </br>Het is in de 0-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is. </br>Dit document vormt een basis voor het verdere verloop van het traject. </br>In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. </br> </br> Doel en doelgroep </br> Initiatiefnemers (lokale en bovenlokale besturen): De initiatiefnemers en hun project partners werken aan de hand van deze pagina de inhoud verder uit, waarna validatie en prioritering volgt. </br> Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. </br>Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be .</br>Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) </br> Bedrijven en kennisinstellingen: Heb je als bedrijf een visie op de generieke business vereisten van dit thema, dan nodigen we je uit om samen deze oefening verder mee vorm te geven.</br>Ben je leverancier aan overheden, vragen we je specifieke oplossingen niet te vermelden maar de generieke business en IT architectuur in co-creatie mee uit te werken. </br> Burgers en burgergroeperingen: </br>Voel je je als burger aangesproken door dit onderwerp en je hebt een visie op de ontwikkeling van oplossingen van dit thema, laat het ons zeker weten. </br> </br> Aanpak (korte beschrijving) </br> Andere versie</br> </br> Inhoud </br> Hieronder kan je de elementen van versie 0 van dit VLOCA model bekijken.</br> </br> </br></br> </br> Naam Traject : Slim Ruimtelijk Plannen (Gent met Leiedal) </br> </br> </br> Start periode traject </br> </br> VLOCA-model versie 0.3 </br> </br> </br> VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be </br> </br> </br> Beschrijving en aanpak: </br> </br> https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model </br> </br> </br> </br> </br> </br> Strategie van de open city uitdaging </br> </br> </br> </br> </br> </br> </br> </br> Status </br> </br> Toelichting </br> </br> Beschrijving </br> </br> </br> Visie </br> </br> Voorstel</br> </br> Wat is de bestaansreden ?</br> </br> De druk op de ruimte in Vlaanderen is bijzonder groot. We moeten onze ruimte dus verstandig gebruiken. In de bebouwde gebieden betekent dat meer doen met de beschikbare ruimte: aandacht hebben dus voor ruimtelijk rendement. Tegelijk willen we onze open ruimte beschermen.</br> </br> </br> Missie </br> </br> Voorstel</br> </br> Wat willen we bereiken ?</br> </br> We willen toekomstige ontwikkelingen op een slimme manier kunnen plannen en begeleiden om leefbare buurten en levendige kernen te cre ren. Hiervoor moeten we de databronnen (incl simuleren en visualiseren)</br> </br> </br> Doel </br> </br> Voorstel</br> </br> Wat is het doel van dit project ?</br> </br> De fundamenten zetten van een digital twin voor een concreet en tastbaar domein, nl. ruimtelijke planning, stapsgewijs een data-aanpak uitbouwen voor een economisch en menselijk leefbare ruimtelijke structuur. Ook de rol van 3D-visualisatie hierin wordt verkend. Voor dit specifiek COT project blijft het primaire doel : 1, we willen data op het juiste niveau aggregeren en ontsluiten. Daarvoor moeten we weten welke indicatoren wenselijk zijn, welke indicatoren haalbaar zijn, en tijdens het project de juiste subset aan indicatoren effectief cre ren. 2, we willen weten welke simulaties we willen kunnen doen over nieuwe evoluties of bestaand beleid. We testen tijdens het project de juiste simulaties 3, deze data moet intern en extern ontsloten worden. Dat kan op verschillende manieren. We kiezen de meest geschikte scenario's en testen deze uit.</br> </br> </br> Succesfactor </br> </br> Voorstel</br> </br> Hoe meten we succes ? (SMART)</br> </br> De lokale besturen (ruimtelijk planners, economie, groen, ambtenaren, ) een 'opschaling' van het meer data gedreven werken, evaluaties, simulaties hebben gevoeld dankzij dit project. (via een bevraging of het aantal logins en gebruik van de tool, enz. bvb) Het aantal gebruikers en gebruik stijgt doorheen de tijd. Ook de 'adoptiegraad' (aantal gebruikers/aantal potentiele gebruikers) Democratiseringsgraad van de tool (aan niet data-experten gebruikers/totaal gebruikers)</br> </br> </br> </br> </br> </br> Use cases </br> </br> </br> </br> </br> </br> ID </br> </br> Status </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC1</br> </br> Voorstel</br> </br> UC1: Ruimtelijke Indicatoren : Behoeften Design Fase</br> </br> Behoeften, visie en ideale oplossingsdesign op de ruimtelijke Indicatoren en de respectievelijk schaalniveaus uittekenen die voor analyse, advies, simulaties, voorspellingen, ed meer nuttig zouden kunnen zijn</br> </br> </br> UC2</br> </br> Voorstel</br> </br> UC2: Gap Analyse As Is vs To Be</br> </br> Exploratie en evaluatie van wat gewenst is aan data tov van wat beschikbaar is aan data mbt de ideale oplossingsdesign</br> </br> </br> UC3</br> </br> Voorstel</br> </br> UC3: Verwerken en ontsluiten</br> </br> Ruimtelijke indicatoren ter beschikking stellen (berekenen, publicatie, ontwikkeling ook voor opschaling mogelijk te maken) en inzichtelijk maken (per gewenste schaalniveau) voor diverse doelstellingen voor de verschillende applicaties</br> </br> </br> UC4</br> </br> Voorstel</br> </br> UC4: Evaluatie (terugkijken)</br> </br> Evaluatie mogelijkheden van specifieke beleidsdoelstellingen of beleidslijnen, op een objectieve (en subjectieve) manier door gebruik te maken van de gemeten Ruimtelijke Indicatoren (Before&After, planning/uitvoering/evaluatie/bijsturing) tov een 'objectief' (of 'target') (=doelstelling)</br> </br> </br> UC5</br> </br> Voorstel</br> </br> UC5: Simulatie (vooruitkijken)</br> </br> Simulatie mogelijkheden om door een organisatie (bvb) voorgestelde plannen te kunnen aftoetsen, of vooral bepaalde input (kwantitatief als kwalitatief) te geven die de beslissende ambtenaar eventueel kan gebruiken bij zijn beslissing.</br> </br> </br> UC6</br> </br> Voorstel</br> </br> UC6 =>UC4: applicaties en services</br> </br> Data platform (met zowel open als niet-open data) die zowel intern als externe partijen toelaat om applicaties en services te bouwen inclusief buiten het domein van ruimtelijk plannen (bvb andere digital twin applicaties)</br> </br> </br> UC7</br> </br> Voorstel</br> </br> UC7: Verticale UC's</br> </br> Promotie om derde partijen aan te trekken die verticale applicaties kunnen en willen bouwen op het platform</br> </br> </br> UC8</br> </br> Voorstel</br> </br> UC8: Samenvatting</br> </br> UC8: Beschrijving</br> </br> </br> UC9</br> </br> Voorstel</br> </br> UC9: Samenvatting</br> </br> UC9: Beschrijving</br> </br> </br> UC10</br> </br> Voorstel</br> </br> UC10: Samenvatting</br> </br> UC10: Beschrijving</br> </br> </br> </br> </br> </br> Metadata </br> </br> </br> </br> </br> </br> </br> </br> Metaveld </br> </br> Beschrijving </br> </br> </br> </br> </br> Meta1</br> </br> Beschrijving meta 1</br> </br> </br> </br> </br> Meta2</br> </br> Beschrijving meta 2</br> </br> </br> </br> </br> </br> Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases </br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC1</br> </br> Use case</br> </br> UC1: Ruimtelijke Indicatoren : Behoeften Design Fase </br> </br> Behoeften, visie en ideale oplossingsdesign op de ruimtelijke Indicatoren en de respectievelijk schaalniveaus uittekenen die voor analyse, advies, simulaties, voorspellingen, ed meer nuttig zouden kunnen zijn</br> </br> </br> </br> </br> </br> BR1.1 </br> </br> Business Requirement </br> </br> Ruimtedruk </br> </br> Als beleid wil ik slimme ruimtelijke indicatoren kunnen meten die de ruimtedruk op verschillende dimensies (=niveaulijnen) berekenen</br> </br> </br> </br> </br> </br> BR1.2 </br> </br> Business Requirement </br> </br> ruimteversnippering </br> </br> Als beleid wil ik slimme ruimtelijke indicatoren kunnen meten die de ruimteversnippering op verschillende dimensies (=niveaulijnen) berekenen</br> </br> </br> </br> </br> </br> BR1.3 </br> </br> Business Requirement </br> </br> Levendigheid </br> </br> Als beleid wil ik slimme ruimtelijke indicatoren kunnen meten die de ruimtelevendigheid op verschillende dimensies (=niveaulijnen) berekenen</br> </br> </br> </br> </br> </br> BR1.4 </br> </br> Business Requirement </br> </br> Leefbaarheid </br> </br> Als beleid wil ik slimme ruimtelijke indicatoren kunnen meten die de leefbaarheid op verschillende dimensies (=niveaulijnen) berekenen</br> </br> </br> </br> </br> </br> BR1.5 </br> </br> Business Requirement </br> </br> Algoritmes </br> </br> Als medewerker wil ik die indicatoren met een algoritme kunnen bepalen waarin de input meetbare sub-indicatoren zijn</br> </br> </br> </br> </br> </br> BR1.6 </br> </br> Business Requirement </br> </br> Visualisatie </br> </br> Als beleid wil ik een algemene dashboard hebben die de indicatoren voorstellen en die via een 'drilldown' via bvb een kaartweergave de 'sub-indicatoren' (dus een diepere datalaag/kaartlaag) visualiseren.</br> </br> </br> </br> </br> </br> BR1.7 </br> </br> Business Requirement </br> </br> businessplan en ROI </br> </br> Als beleid wil ik een business plan kunnen uittekenen die de 'inversteringen' tegenover de verbeteringen van de KPIs kunnen gesimuleerd worden. Een grafiek die de mogelijke inversteringen tov de winst/verbetering in de belangrijke KPI voorstelt, om zo beleidsbeslissingen te kunnen nemen die echt datagedreven zijn.</br> </br> </br> </br> </br> </br> BR1.8 </br> </br> Business Requirement </br> </br> subjectieve beleving </br> </br> Als beleid wil ik ook een 'subjectieve' bevraging kunnen doen, en bewaren voor opvolging, om de echte of subjectieve beleving met de objectieve metrieken te vergelijken</br> </br> </br> </br> </br> </br> BR1.9 </br> </br> Business Requirement </br> </br> feedbackloop </br> </br> Als medewerker wil ik de formules die de metrieken berekenen kunnen aanpassen ifv de 'declaratieve'/ 'subjectieve' beleving op ruimtedruk, -versnippering., leefbaar- en levendigheid. Vooral indien bvb de KPI 'groen' zijn terwijl de subjectieve beleving 'rood' kleuren in het dashboard.</br> </br> </br> </br> </br> </br> BR1.10 </br> </br> Business Requirement </br> </br> metadata </br> </br> Als medewerker en beleid wil ik de metadata van de KPIs of Pis kunnen opvragen die bij de cijfers in het dashboard beschrijven. Een versionering, updates en datastewardship duidelijk en transparant afgestemd.</br> </br> </br> </br> </br> </br> BR1.11 </br> </br> Business Requirement </br> </br> burgerparticipatie / 'consultatie-omgeving' </br> </br> Als burger of organisatie wil ik de dashboard kunnen gebruiken om zelf geinformeerd te worden (bewustwording) en eventueel ook voorstellen te kunnen doen mbt ruimtedruk en -versnippering</br> </br> </br> </br> </br> </br> BR1.12 </br> </br> Business Requirement </br> </br> datakwaliteit evaluatie </br> </br> Als medewerker wil ik de data kunnen evalueren en dan ook visualiseren hoe de kwaliteit van data is op correctheid, recentie, frequentie, dekking, granulariteit, enz.</br> </br> </br> </br> </br> </br> BR1.13 </br> </br> Business Requirement </br> </br> Gebruik dashboard </br> </br> Als beleid wil ik kunnen zien hoeveel het dashboard platform gebruikt werd en door wie</br> </br> </br> </br> </br> </br> BR1.14 </br> </br> Business Requirement </br> </br> regionale standaarden </br> </br> Als overheid wil ik kunnen waken dat de KPI definities en formules gealigneerd zijn tussen de gemeenten en steden opdat benchmarking/vergelijkingen mogelijk worden.</br> </br> </br> </br> </br> </br> BR1.15 </br> </br> Business Requirement </br> </br> Bouwblokvisie </br> </br> Als medewerker en beleid wil ik de indicatoren kunnen meten mbt Bouwblokvisie, zoals woningsdichtheid, groencapaciteitsbereik, bebouwingsgraad en verhardingsgraad op schaalniveau bouwblokken (netto)</br> </br> </br> </br> </br> </br> BR1.16 </br> </br> Business Requirement </br> </br> Bouwshift </br> </br> Als medewerker en beleid wil ik de indicatoren kunnen meten mbt Bouwshift, zoals bebouwingsgraad, verhardingsgraad, aanwezigheid groen, volumeoppervlakte-index, gemiddelde hoogte, adressen per hectare, ruimtebeslag, synthese knooppuntwaarde en voorzieningenniveau op schaalniveau bouwblokken (netto en bruto)</br> </br> </br> </br> </br> </br> BR1.17 </br> </br> Business Requirement </br> </br> LocusFocus </br> </br> Als medewerker en beleid wil ik de indicatoren kunnen meten mbt LocusFocus, zoals bereikbaarheid, aantrekkelijkheid, hinderbestendigheid, economische activiteit op schaalniveau bouwblokken (netto)</br> </br> </br> </br> </br> </br> BR1.18 </br> </br> Business Requirement </br> </br> Stedenbouwkundige Lasten </br> </br> Als medewerker en beleid wil ik de indicatoren kunnen meten mbt stedenbouwkundige lasten, zoals bereikbaarheid en capaciteit aan voorzieningen die vallen onder de taakstelling van de overheid zoals parken, onderwijs en kinderopvang, buurtsportterreinen, jeugdwerklokalen, bibliotheken,enz. op schaalniveau heathmap</br> </br> </br> </br> </br> </br> BR1.19 </br> </br> Business Requirement </br> </br> Panel voor klimaat en duurzaamheid </br> </br> Als medewerker en beleid wil ik de indicatoren kunnen meten mbt Panel voor klimaat en duurzaamheid, zoals woningen per hectare, V/T-index, bebouwingsgraad, oppervlakte verharding, waterdoorlatende oppervlakte, oppervlakte tuin, oppervlakte ecologisch waardevol of beschermd groen op schaalniveau bouwblokken</br> </br> </br> </br> </br> </br> BR1.20 </br> </br> Business Requirement </br> </br> Schaalniveaus bepaling </br> </br> Als medewerker en beleid wil ik de verschillende schaalniveaus kunnen bepalen die gebruikt zullen worden bij de rapportering van de indicatoren. Bvb Bouwblokken, heat-map, hexagonalen, isochronen, wijk, straatsegmenten, straat</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC2</br> </br> Use case</br> </br> UC2: Gap Analyse As Is vs To Be </br> </br> Exploratie en evaluatie van wat gewenst is aan data tov van wat beschikbaar is aan data mbt de ideale oplossingsdesign</br> </br> </br> </br> </br> </br> BR2.1 </br> </br> Business Requirement </br> </br> Hoe vandaag ? </br> </br> Als beleid wil ik een overzicht hebben van hoe dat we vandaag ruimtelijke ordening meten</br> </br> </br> </br> </br> </br> BR2.2 </br> </br> Business Requirement </br> </br> Haalbaarheidstudie </br> </br> Als beleid wil ik een 'haabaarheidstudie' (feasability) voor het meten en rapporteren van de nieuwe Ruimtelijke indicatoren</br> </br> </br> </br> </br> </br> BR2.3 </br> </br> Business Requirement </br> </br> Afhankelijkheden </br> </br> Als beleid wil ik de afhankelijkheden kunnen bepalen tussen de nieuwe en bestaande indicatoren</br> </br> </br> </br> </br> </br> BR2.4 </br> </br> Business Requirement </br> </br> Data Governance </br> </br> Als beleid wil ik per indicator de attributen kunnen bepalen zoals frequentie, granulariteit, niveaulagen, cijfer of kaart,enz.</br> </br> </br> </br> </br> </br> BR2.5 </br> </br> Business Requirement </br> </br> Benchmark andere regio's </br> </br> Als beleid wil ik een benchmark hebben van andere regio's die het al dan niet beter doen mbt datagedreven ruimtelijke ordening</br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC3</br> </br> Use case</br> </br> UC3: Verwerken en ontsluiten </br> </br> Ruimtelijke indicatoren ter beschikking stellen (berekenen, publicatie, ontwikkeling ook voor opschaling mogelijk te maken) en inzichtelijk maken (per gewenste schaalniveau) voor diverse doelstellingen voor de verschillende applicaties</br> </br> </br> </br> </br> </br> BR3.1 </br> </br> Business Requirement </br> </br> Dashboard vorm </br> </br> Als beleid wil ik applicaties kunnen bouwen die de data visualiseren in een 'dashboard' vorm</br> </br> </br> </br> </br> </br> BR3.2 </br> </br> Business Requirement </br> </br> 2D grafieken (kaart,...) </br> </br> Als beleid wil ik applicaties kunnen bouwen die de data visualiseren in 2D formaat (bebouwingsgraad, verhardingsgraad,...)</br> </br> </br> </br> </br> </br> BR3.3 </br> </br> Business Requirement </br> </br> 3D grafieken (gebouwen,...) </br> </br> Als beleid wil ik applicaties kunnen bouwen die de data visualiseren in 3D formaat (gebouwhoogte, gebouwvolume, vloeroppervlakte,...)</br> </br> </br> </br> </br> </br> BR3.4 </br> </br> Business Requirement </br> </br> Mobiliteits Indicatoren </br> </br> Als beleid wil ik applicaties kunnen bouwen die mobilteit uitrekent en visualiseert (15 minuten stad regel,...)</br> </br> </br> </br> </br> </br> BR3.5 </br> </br> Business Requirement </br> </br> Bevolkings ea externe indicatoren </br> </br> Als beleid wil ik ook andere types van data kunnen integreren in mijn rapportering zoals bvb bevolkingsdata, (inwoners, huishoudens, leeftijdsstructuur, nationaliteit, enz.)*</br> </br> </br> </br> </br> </br> BR3.6 </br> </br> Business Requirement </br> </br> Advanced Analytics Capabilities </br> </br> Als beleid wil ik een applicatie kunnen bouwen die mij toelaten om geavanceerde analyse te kunnen maken zoals een 'before&after' analyse, predictieve of forecasting analyses, ed meer</br> </br> </br> </br> </br> </br> BR3.7 </br> </br> Business Requirement </br> </br> Behoeften aan Cijfers </br> </br> Als medewerker wil ik een behoefte analyse en dus een behoefte segmentatie van wie welke rapportage nodig hebben. (van slides naar self-service, van high-level dashboarding tot advanced analytical tools)</br> </br> </br> </br> </br> </br> BR3.8 </br> </br> Business Requirement </br> </br> Data Preparation for Machine Learning </br> </br> Als medewerker wil ik de data klaargemaakt hebben voor Machine Learning en andere Aritifiele Intelligentie applicaties.</br> </br> </br> </br> </br> </br> BR3.9 </br> </br> Business Requirement </br> </br> Retail support voor keuze locaties </br> </br> Als beleid wil ik aan de 'retail' rapporten kunnen sturen die hen helpen bij het kiezen van de juiste locaties binnen de stad/regio/gemeente/...</br> </br> </br> </br> </br> </br> BR3.10 </br> </br> Business Requirement </br> </br> Rapportage gebruik data en applicaties </br> </br> Als beleid wil ik kunnen zien hoeveel (wie, welke profiel, wat, wanneer, hoeveel, hoe lang,...) en waarvoor de data gebruikt werd en hoe tevreden en bruikbaar dit was.</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC4</br> </br> Use case</br> </br> UC4: Evaluatie (terugkijken) </br> </br> Evaluatie mogelijkheden van specifieke beleidsdoelstellingen of beleidslijnen, op een objectieve (en subjectieve) manier door gebruik te maken van de gemeten Ruimtelijke Indicatoren (Before&After, planning/uitvoering/evaluatie/bijsturing) tov een 'objectief' (of 'target') (=doelstelling)</br> </br> </br> </br> </br> </br> BR4.1 </br> </br> Business Requirement </br> </br> Evaluatie Beleidsdoelstellingen </br> </br> Als beleid wil ik kunnen zien of mijn beleidsdoelstellingen een impact hebben gehad op de verschillende Ruimtelijke indicatoren en KPIs</br> </br> </br> </br> </br> </br> BR4.2 </br> </br> Business Requirement </br> </br> Evaluatie Beleidslijnen en Acties </br> </br> Als beleid en medewerker wil ik mijn uitgevoerde ruimtelijke plannings beleidslijnen kunnen meten om te weten of die efficient al dan niet effectief waren</br> </br> </br> </br> </br> </br> BR4.3 </br> </br> Business Requirement </br> </br> strengere of laxere regels </br> </br> Als beleid wil ik de impact van strengere of versoepelde/laxere regels op het aantal aanvragen per type kunnen meten en simuleren.</br> </br> </br> </br> </br> </br> BR4.4 </br> </br> Business Requirement </br> </br> Impact strengheid op aantal aanvragen </br> </br> Als beleid wil ik een parameter 'strengheid' (minimum of maximum) kunnen challengen ifv zowel het verbeteren van de ruimtelijke planning maar ook van de aanvraag dynamiek die ofwel daalt ofwel stijgt (door die 'streng- of laxheid in de regels)</br> </br> </br> </br> </br> </br> BR4.5 </br> </br> Business Requirement </br> </br> Nulmeting </br> </br> Als medewerker wil ik een nulmeting hebben om zo de beleidslijnen te kunnen evalueren</br> </br> </br> </br> </br> </br> BR4.6 </br> </br> Business Requirement </br> </br> AB testing </br> </br> Als medewerker wil ik een AB testing (2 gemeenten andere beleidslijnen bvb) kunnen doen om zo de beleidslijnen te kunnen evalueren</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC5</br> </br> Use case</br> </br> UC5: Simulatie (vooruitkijken) </br> </br> Simulatie mogelijkheden om door een organisatie (bvb) voorgestelde plannen te kunnen aftoetsen, of vooral bepaalde input (kwantitatief als kwalitatief) te geven die de beslissende ambtenaar eventueel kan gebruiken bij zijn beslissing.</br> </br> </br> </br> </br> </br> BR5.1 </br> </br> Business Requirement </br> </br> Simulatie van bouwplan op de indicatoren </br> </br> Als burger, organisatie, bedrijf wil ik een bouw gerelateerde plan/project kunnen invoeren (BIM formaat?) om de impact op de ruimtelijke indicatoren te kunnen meten (hoeveel beter/slechter) : nl ruimtedruk, -versnippering, levendigheid en leefbaarheid</br> </br> </br> </br> </br> </br> BR5.2 </br> </br> Business Requirement </br> </br> Simulatie om te evalueren </br> </br> Als beleid wil ik plannen/projecten kunnen evalueren ifv de impact op de KPIs van de ruimtelijke indicatoren (ruimtedruk, -versnippering, levendigheid en leefbaarheid)</br> </br> </br> </br> </br> </br> BR5.3 </br> </br> Business Requirement </br> </br> Simulatie om advies (pareto regels) te krijgen </br> </br> Als burger, organisatie, bedrijf en medewerker wil ik via AI/ML (lineair programmeren bvb) de meest efficiente dimensionering die de doelstelling van het project tov de KPIs van de ruimtelijke dimensies optimaliseerd. Dit betekent dat we reeds bij de aanvang van het project het datamanagement aanpassen ifv deze behoefte, zoals een aparte gedenormaliseerde tabelvorm ed meer)</br> </br> </br> </br> </br> </br> BR5.4 </br> </br> Business Requirement </br> </br> Feedback met voorstellen </br> </br> Als beleid wil ik een overzicht kunnen krijgen van data gedreven semi-automatische voorstellen waarbij (snelle, pareto regels) de KPIs kunnen verbeteren met relatief weinig 'inspanning' of 'investering' of 'rellocaties' enz. Dus de tool zou een lijst semi-automatisch kunnen genereren van 'simpele' voorstellen tot 'impactvolle' verbeteringen</br> </br> </br> </br> </br> </br> BR5.5 </br> </br> Business Requirement </br> </br> Quick&Dirty eerste evaluatie </br> </br> Als beleid wil ik dat de computer een eerste automatische AI geleide validatie oefening maakt die ik dan 'sneller' kan valideren.</br> </br> </br> </br> </br> </br> BR5.6 </br> </br> Business Requirement </br> </br> BIM opladen </br> </br> Als burger, organisatie, bedrijf (architectenbureau, ingenieurs, ) wil ik mijn bouwplannen in een BIM standaard kunnen opladen in het systeem om die te verwerken.</br> </br> </br> </br> </br> </br> BR5.7 </br> </br> Business Requirement </br> </br> automatische evaluatie </br> </br> Als ambtenaar wil ik sommige gevallen automatisch kunnen verwerpen of goedkeuren, samen met argumentatie en voorgestelde verbeteringspunten.</br> </br> </br> </br> </br> </br> BR5.8 </br> </br> Business Requirement </br> </br> overzicht evaluaties </br> </br> Als beleid wil ik een overzicht krijgen van de aantallen en profielen van de goedgekeurde of verworpen plannen en dit met argumentatie</br> </br> </br> </br> </br> </br> BR5.9 </br> </br> Business Requirement </br> </br> vergelijkingen </br> </br> Als medewerker wil ik scenarios tov elkaar kunnen afwegen, dus na simulaties de Indicatoren en KPIs naast elkaar kunnen leggen en vergelijken.</br> </br> </br> </br> </br> </br> BR5.10 </br> </br> Business Requirement </br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC6</br> </br> Use case</br> </br> UC6=>UC4: applicaties en services </br> </br> Data platform (met zowel open als niet-open data) die zowel intern als externe partijen toelaat om applicaties en services te bouwen inclusief buiten het domein van ruimtelijk plannen (bvb andere digital twin applicaties)</br> </br> </br> </br> </br> </br> BR6.1 </br> </br> Business Requirement </br> </br> Toegang beheer </br> </br> Als systeem beheerder wil ik API kunnen activeren aan verschillende partijen om de toegang beter te beheren</br> </br> </br> </br> </br> </br> BR6.2 </br> </br> Business Requirement </br> </br> Data Opladen beheer </br> </br> Als systeem beheerder wil ik API kunnen opstellen die data leveranciers de mogelijkheid geeft om data op te laden</br> </br> </br> </br> </br> </br> BR6.3 </br> </br> Business Requirement </br> </br> Data bevragen beheer </br> </br> Als systeem beheerder wil ik API kunnen opstellen die data klanten de mogelijkheid geeft om data te bevragen</br> </br> </br> </br> </br> </br> BR6.4 </br> </br> Business Requirement </br> </br> Rapportage 'uitwisseling' </br> </br> Als beleid wil ik een overzicht zien van hoeveel en welke type van data, applicaties werden opgeladen of gedownload</br> </br> </br> </br> </br> </br> BR6.5 </br> </br> Business Requirement </br> </br> clearinghouse </br> </br> Als beleid wil ik een soort 'clearinghouse' systeem opstellen om eventueel in de toekomst te kunnen factureren.</br> </br> </br> </br> </br> </br> BR6.6 </br> </br> Business Requirement </br> </br> data market place </br> </br> Als beleid wil ik een data market place kunnen bouwen waar burgers, organisaties en beleid data en applicaties met elkaar delen.</br> </br> </br> </br> </br> </br> BR6.7 </br> </br> Business Requirement </br> </br> datavindplaats </br> </br> Als beleid wil ik een 'datavindplaats' bouwen die de beschikbare data volledig documenteert</br> </br> </br> </br> </br> </br> BR6.8 </br> </br> Business Requirement </br> </br> Publishing/subscribing </br> </br> Als beleid wil ik dat de subscribers de nodige informatie krijgen bij het publiceren van (nieuwe) data.</br> </br> </br> </br> </br> </br> BR6.9 </br> </br> Business Requirement </br> </br> Ruwe of verwerkte data </br> </br> Als medewerker wil ik een onderscheid kunnen maken tot de toegang van verwerkte of geaggregeerde data versus ruwe gedetailleerde (bron) data</br> </br> </br> </br> </br> </br> BR6.10 </br> </br> Business Requirement </br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC7</br> </br> Use case</br> </br> UC7: Verticale UC's </br> </br> Promotie om derde partijen aan te trekken die verticale applicaties kunnen en willen bouwen op het platform</br> </br> </br> </br> </br> </br> BR7.1 </br> </br> Business Requirement </br> </br> Behoefte Segmentatie </br> </br> Als beleid wil ik een 'segmentatie' kunnen bouwen die de behoeftes en opportuniteiten 'clusteren' zowel binnen als buiten de sector. Dit aangevuld met het aantal potentiele gebruikers intern als extern.</br> </br> </br> </br> </br> </br> BR7.2 </br> </br> Business Requirement </br> </br> Acquisitie gebruikers </br> </br> Als beleid wil ik de markt kunnen contacteren om hen uit te nodigen om applicaties te bouwen op het platform</br> </br> </br> </br> </br> </br> BR7.3 </br> </br> Business Requirement </br> </br> Reviews en klachten </br> </br> Als beleid wil ik alle feedback van de markt kunnen capteren om de 'dienstverlening' rond het platform beter af te stemmen</br> </br> </br> </br> </br> </br> BR7.4 </br> </br> Business Requirement </br> </br> CRM, GDPR,... </br> </br> Als beleid wil ik informatie kunnen uitsturen, capteren en bijhouden mbt communicatie naar derde partijen</br> </br> </br> </br> </br> </br> BR7.5 </br> </br> Business Requirement </br> </br> Vertikale en Horizontale Applicaties </br> </br> Als beleid wil ik een overzicht kunnen zien van alle vertikale en horizontale use cases en dus applicaties er op het platform actief zijn. En wat is de intensiteit van het gebruik.</br> </br> </br> </br> </br> </br> BR7.6 </br> </br> Business Requirement </br> </br> Vergoeding of Appreciatie </br> </br> Als beleid wil ik een vergoeding/incentivering kunnen geven aan databronnen bij het opladen van hun data ifv de kwaliteit. Bij het willen opladen van waardevolle data, willen we daar ook een appreciatie laten zien.</br> </br> </br> </br> </br> </br> BR7.7 </br> </br> Business Requirement </br> </br> Voor wat hoort wat </br> </br> Als beleid wil ik een 'vergoeding'/'compensatie'(voor wat hoort wat) kunnen vragen aan derde partijen om toegang tot de data te kunnen reguleren, via bvb Urban Sensevb Urban Sense  +
• Inleiding Deze pagina bevat de eerste ve … Inleiding </br> Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we V0.1 noemen.</br>Dit kwam tot stand na de inhoudelijke intro met de initiatiefnemer van dit VLOCA traject en een studie van de aangeleverde informatie bij de start van het project.</br> </br> Situering van deze deliverable in het traject </br> Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. </br>Het is in de V0.1-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is. </br>Dit document vormt een basis voor het verdere verloop van het traject. </br>In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. </br> </br> Doel en doelgroep </br> Initiatiefnemers (lokale en bovenlokale besturen): De initiatiefnemers en hun project partners werken aan de hand van deze pagina de inhoud verder uit, waarna validatie en prioritering volgt. </br> Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. </br>Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be .</br>Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) </br> Bedrijven en kennisinstellingen: Heb je als bedrijf een visie op de generieke business vereisten van dit thema, dan nodigen we je uit om samen deze oefening verder mee vorm te geven.</br>Ben je leverancier aan overheden, vragen we je specifieke oplossingen niet te vermelden maar de generieke business en IT architectuur in co-creatie mee uit te werken. </br> Burgers en burgergroeperingen: </br>Voel je je als burger aangesproken door dit onderwerp en je hebt een visie op de ontwikkeling van oplossingen van dit thema, laat het ons zeker weten. </br> </br> Aanpak (korte beschrijving) </br> In dit VLOCA model V0.1 vertrekken we van de visie, missie en doelen zoals ze geformuleerd worden door de initiatiefnemer. </br>Deze gegevens worden verder verfijnd en uitgesplitst in objectieven, en hun de daaraan gelinkte business capabilities, data vereisten, functionele capabilities en technische vereisten. Een volledige omschrijving van het VLOCA-model kan je hier lezen.</br>In deze fase exploreert team VLOCA tevens de extra mogelijkheden rond deze use case. Deze worden in het project gevalideerd en al of niet in scope van het project genomen. Wanneer ze niet in scope worden genomen, kan deze bijdragen aan het uitwerken van een ander of een vervolgproject.</br> </br> Inhoud </br> Hieronder kan je de elementen van versie V0.1 van dit VLOCA model bekijken.</br> </br> </br></br> </br> CoT Machine Learning as a Service (MLaaS) – Roeselare </br> </br> </br> 2022 </br> </br> VLOCA-model versie 0.1 </br> </br> </br> VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be </br> </br> </br> Beschrijving en aanpak: </br> </br> https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model </br> </br> </br> </br> </br> </br> Strategie van de open city uitdaging </br> </br> </br> </br> </br> </br> </br> </br> Status </br> </br> Toelichting </br> </br> Beschrijving </br> </br> </br> Visie </br> </br> Voorstel</br> </br> Wat is de bestaansreden ?</br> </br> Vandaag wordt in Roeselare en Brugge reeds mobiele sensoren in de vorm van camera's op drones gebruikt die een overzicht geven (op bvb het aantal bomen in een bos) die 'fijnmaziger' is en meer uitgestrekt dan 'vaste' sensoren. Er is blijkbaar een nood om meer geografisch fijnmazig sensor data te verzamelen.</br> </br> </br> Missie </br> </br> Voorstel</br> </br> Wat willen we bereiken ?</br> </br> Een platform en draaiboek voor alle steden en gemeenten die via mobiele/vliegende sensoren willen experimenteren of hun beleidsvorming en sturing willen ondersteunen, zodat ze gebruik kunnen maken van de ervaring en gebouwde platform van Roeselare en Brugge om zo duurzaam te investeren en dus het warm water niet heruitvinden.</br> </br> </br> Doel </br> </br> Voorstel</br> </br> Wat is het doel van dit project ?</br> </br> Bouwen van schaalbaar platform voor vliegende sensoren data die open staat voor alle steden en gemeenten. Alle stappen van sensor data management wordt geleverd : connectie, datacontext, callibratie, machine learning, faultmanagement, rapportage, enz.</br> </br> </br> Succesfactor </br> </br> Voorstel</br> </br> Hoe meten we succes ? (SMART)</br> </br> Een bibliotheek met minstens 2 Machine Learning modellen op bvb luchtfoto's om bomen inventaris, wegmarkering ed ook voor andere steden ter beschikking stellen met hun eigen luchtfoto's tegen 2023</br> </br> </br> </br> </br> </br> Use cases </br> </br> </br> </br> </br> </br> ID </br> </br> Status </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC1</br> </br> voorstel</br> </br> UC1: Model Training</br> </br> We moeten de modellen kunnen trainen om patronen te herkennen, zoals verkeersborden, aantal bomen, gezondheid bomen, status van de wegen, ed.</br> </br> </br> UC2</br> </br> voorstel</br> </br> UC2: Model Implementation</br> </br> De modellen moeten in een bibiliotheek beschikbaar zijn met documentatie, bestekteksten en conformiteitsmodellen</br> </br> </br> UC3</br> </br> voorstel</br> </br> UC3: Model Quality</br> </br> De kwaliteit van de modellen moeten telkens gecheckt worden en gerapporteerd</br> </br> </br> UC4</br> </br> voorstel</br> </br> UC4: Dynamic Modelling</br> </br> Nieuwe modellen moeten kunnen gebouwd worden op basis van nieuwe (dependent en independent) variabelen.</br> </br> </br> UC5</br> </br> voorstel</br> </br> UC5: Beeldmateriaal : Luchtfoto's</br> </br> Het verkrijgen van luchtfoto's die beschikbaar zijn voor machine learning om iets te 'identificeren'</br> </br> </br> UC6</br> </br> voorstel</br> </br> UC6: Bomen Telling</br> </br> Het aantal bomen kunnen inventariseren via luchtfoto's : Vlaamse Standaard</br> </br> </br> UC7</br> </br> voorstel</br> </br> UC7: Wegmarkering</br> </br> Via Luchtfoto's de markeringen op de wegen te identificeren : Vlaamse Standaard</br> </br> </br> UC8</br> </br> voorstel</br> </br> UC8: Exploratie Luchtfoto's</br> </br> Via Exploratie : het opzoeken van andere opportuniteiten die we van luchtfoto's kunnen halen.</br> </br> </br> UC9</br> </br> voorstel</br> </br> UC9: Verkeersborden</br> </br> Gebruik van machine learning (zie CoT Mobiele Sensoren) om met mobiele sensoren de verkeersborden te inventariseren en de 'besmeuringen' te herkennen : Vlaamse Standaard</br> </br> </br> </br> </br> </br> Metadata </br> </br> </br> </br> </br> </br> Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases </br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC1</br> </br> Use case</br> </br> UC1: Model Training</br> </br> We moeten de modellen kunnen trainen om patronen te herkennen, zoals verkeersborden, aantal bomen, gezondheid bomen, status van de wegen, ed.</br> </br> </br> BC1.1 </br> </br> Business capability </br> </br> Samenvatting </br> </br> train en test dataset hebben om de machine learning tool de kans te geven om een model te bouwen die de output voorspeld ifv allerlei data input.</br> </br> </br> BC1.2 </br> </br> Business capability </br> </br> beslissen wanneer is een model 'goed genoeg'</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC2</br> </br> Use case</br> </br> UC2: Model Implementation</br> </br> De modellen moeten in een bibiliotheek beschikbaar zijn met documentatie, bestekteksten en conformiteitsmodellen</br> </br> </br> BC2.1 </br> </br> Business capability </br> </br> Het opladen van de modellen met documentatie op een server zodat die gebruikt kunnen worden door 'derde' partijen.</br> </br> </br> BC2.2 </br> </br> Business capability </br> </br> Metadata over de modellen en versies van de documentatie.</br> </br> </br> BC2.3 </br> </br> Business capability </br> </br> Het bouwen van een 'bibliotheek' platform met versionering van de documentatie.</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC3</br> </br> Use case</br> </br> UC3: Model Quality</br> </br> De kwaliteit van de modellen moeten telkens gecheckt worden en gerapporteerd</br> </br> </br> BC3.1 </br> </br> Business capability </br> </br> Trends analyse van een constante iteratie die de modellen op de proef stellen door nieuwe train en test sets te gebruiken.</br> </br> </br> BC3.2 </br> </br> Business capability </br> </br> Overzicht van de trends van de kwaliteit van de modellen ifv lift curve, false positives, betrouwbaarheids intervallen,...</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC4</br> </br> Use case</br> </br> UC4: Dynamic Modelling</br> </br> Nieuwe modellen moeten kunnen gebouwd worden op basis van nieuwe (dependent en independent) variabelen.</br> </br> </br> BC4.1 </br> </br> Business capability </br> </br> moduleerbare ML systeem die gemakkelijk uitbreidbaar zijn om nieuwe variabelen te voorspellen ifv input variabelen.</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC5</br> </br> Use case</br> </br> UC5: Beeldmateriaal : Luchtfoto's</br> </br> Het verkrijgen van luchtfoto's die beschikbaar zijn voor machine learning om iets te 'identificeren'</br> </br> </br> BC5.1 </br> </br> Business capability </br> </br> Maken en verwerken van luchtfoto's tot hoogkwalitatieve beelden</br> </br> </br> BC5.2 </br> </br> Business capability </br> </br> Bepalen van de kwaliteitcriteria nodig voor de Machine Learning analyse</br> </br> </br> BC5.3 </br> </br> Business capability </br> </br> Toetsen van de hoogkwalitatieve beelden aan de kwaliteitscriteria nodig voor de Machine Learning analyse</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC6</br> </br> Use case</br> </br> UC6: Bomen Telling</br> </br> Het aantal bomen kunnen inventariseren via luchtfoto's : Vlaamse Standaard</br> </br> </br> BC6.1 </br> </br> Business capability </br> </br> Bekijken en analyseren van potentiaal bestaande standaarden (Vlaams en/of internationaal)</br> </br> </br> BC6.2 </br> </br> Business capability </br> </br> Opmaken van een OSLO standaard voor het inventariseren van bomen via luchtfoto's</br> </br> </br> BC6.3 </br> </br> Business capability </br> </br> Inventariseren van de bomen via luchtfoto's, gekoppeld aan historiek en gap analyse</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC7</br> </br> Use case</br> </br> UC7: Wegmarkering</br> </br> Via Luchtfoto's de markeringen op de wegen te identificeren : Vlaamse Standaard</br> </br> </br> BC7.1 </br> </br> Business capability </br> </br> Bekijken en analyseren van potentiaal bestaande standaarden (Vlaams en/of internationaal)</br> </br> </br> BC7.2 </br> </br> Business capability </br> </br> Opmaken van een OSLO standaard voor het inventariseren van wegmarkeringen via luchtfoto's</br> </br> </br> BC7.3 </br> </br> Business capability </br> </br> Inventariseren van de wegmarkeringen via luchtfoto's, gekoppeld aan historiek en gap analyse</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC8</br> </br> Use case</br> </br> UC8: Exploratie Luchtfoto's</br> </br> Via Exploratie : het opzoeken van andere opportuniteiten die we van luchtfoto's kunnen halen.</br> </br> </br> BC8.1 </br> </br> Business capability </br> </br> Bekijken en analyseren van potentiaal bestaande standaarden (Vlaams en/of internationaal)</br> </br> </br> BC8.2 </br> </br> Business capability </br> </br> Opmaken van een OSLO standaard voor het inventariseren van verkeersborden</br> </br> </br> BC8.3 </br> </br> Business capability </br> </br> Inventariseren van de verkeersborden via beelden van mobiele sensoren, gekoppeld aan historiek en gap analyse</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC9</br> </br> Use case</br> </br> UC9: Verkeersborden</br> </br> Gebruik van machine learning (zie CoT Mobiele Sensoren) om met mobiele sensoren de verkeersborden te inventariseren en de 'besmeuringen' te herkennen : Vlaamse Standaard  +
• Inleiding Deze pagina bevat de eerste ve … Inleiding </br> Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we V0.1 noemen.</br>Dit kwam tot stand na de inhoudelijke intro met de initiatiefnemer van dit VLOCA traject en een studie van de aangeleverde informatie bij de start van het project.</br> </br> Situering van deze deliverable in het traject </br> Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. </br>Het is in de V0.1-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is. </br>Dit document vormt een basis voor het verdere verloop van het traject. </br>In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. </br> </br> Doel en doelgroep </br> Initiatiefnemers (lokale en bovenlokale besturen): De initiatiefnemers en hun project partners werken aan de hand van deze pagina de inhoud verder uit, waarna validatie en prioritering volgt. </br> Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. </br>Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be .</br>Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) </br> Bedrijven en kennisinstellingen: Heb je als bedrijf een visie op de generieke business vereisten van dit thema, dan nodigen we je uit om samen deze oefening verder mee vorm te geven.</br>Ben je leverancier aan overheden, vragen we je specifieke oplossingen niet te vermelden maar de generieke business en IT architectuur in co-creatie mee uit te werken. </br> Burgers en burgergroeperingen: </br>Voel je je als burger aangesproken door dit onderwerp en je hebt een visie op de ontwikkeling van oplossingen van dit thema, laat het ons zeker weten. </br> </br> Aanpak (korte beschrijving) </br> In dit VLOCA model V0.1 vertrekken we van de visie, missie en doelen zoals ze geformuleerd worden door de initiatiefnemer. </br>Deze gegevens worden verder verfijnd en uitgesplitst in objectieven, en hun de daaraan gelinkte business capabilities, data vereisten, functionele capabilities en technische vereisten. Een volledige omschrijving van het VLOCA-model kan je hier lezen.</br>In deze fase exploreert team VLOCA tevens de extra mogelijkheden rond deze use case. Deze worden in het project gevalideerd en al of niet in scope van het project genomen. Wanneer ze niet in scope worden genomen, kan deze bijdragen aan het uitwerken van een ander of een vervolgproject.</br> </br> Inhoud </br> Hieronder kan je de elementen van versie V0.1 van dit VLOCA model bekijken.</br> </br> </br></br> </br> CoT Mobiele Sensor Units – Roeselare </br> </br> </br> 01/06/2022 </br> </br> VLOCA-model versie 0.1 </br> </br> </br> VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be </br> </br> </br> Beschrijving en aanpak: </br> </br> https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model </br> </br> </br> </br> </br> </br> Strategie van de open city uitdaging </br> </br> </br> </br> </br> </br> </br> </br> Status </br> </br> Toelichting </br> </br> Beschrijving </br> </br> </br> Visie </br> </br> Voorstel</br> </br> Wat is de bestaansreden ?</br> </br> Vandaag wordt in Roeselare en Brugge reeds mobiele sensoren in de vorm van camera's op voertuigen (wagens in RSL en Scooters in Brugge) die een overzicht geven die 'fijnmaziger' is en meer uitgestrekt dan 'vaste' sensoren. Er is blijkbaar een nood om meer geografisch fijnmazig sensor data te verzamelen.</br> </br> </br> Missie </br> </br> Voorstel</br> </br> Wat willen we bereiken ?</br> </br> Een platform en draaiboek voor alle steden en gemeenten die via mobiele sensoren willen experimenteren of hun beleidsvorming en sturing willen ondersteunen, zodat ze gebruik kunnen maken van de ervaring en gebouwde platform van Roeselare en Brugge om zo duurzaam te investeren en dus het warm water niet heruitvinden.</br> </br> </br> Doel </br> </br> Voorstel</br> </br> Wat is het doel van dit project ?</br> </br> Bouwen van schaalbaar platform voor mobiele sensoren data die open staat voor alle steden en gemeenten. Alle stappen van sensor data management wordt geleverd : connectie, datacontext, callibratie, machine learning, faultmanagement, rapportage, enz.</br> </br> </br> Succesfactor </br> </br> Voorstel</br> </br> Hoe meten we succes ? (SMART)</br> </br> Een volledige mobiele sensor platform voor Roeselare, Brugge en Knokke tegen 2025.</br> </br> </br> </br> </br> </br> Use cases </br> </br> </br> </br> </br> </br> ID </br> </br> Status </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC1</br> </br> Voorstel</br> </br> UC1: Mobiele Sensors</br> </br> Een keuze van sensoren moederbord en behuizing die passen op verschillende types van voertuigen (auto's, camionetten, vrachtwagens, fietsen, scooters, drones, ed meer)</br> </br> </br> UC2</br> </br> Voorstel</br> </br> UC2: Verkeersborden Databanken</br> </br> Een volledige up to date databank van alle bestaande verkeersborden die al dan niet op zijn plaats staat, of (niet) besmeurd of gebogen zijn, ed meer.</br> </br> </br> UC3</br> </br> Voorstel</br> </br> UC3: Connectie</br> </br> Een keuze van connectie mogelijkheden die 'mobiele' sensoren kunnen bedienen in de omgeving die gemeten moet worden. (5G, 4G, enz.)</br> </br> </br> UC4</br> </br> Voorstel</br> </br> UC4: Open Data</br> </br> Datastandaardisatie zowel op metadata (OSLO) alsook formaat(JSON-LD), bestekteksten, conformiteitsdocumenten, schaalbaarheid, interoperabiliteit, ...</br> </br> </br> UC5</br> </br> Voorstel</br> </br> UC5: Service</br> </br> Het kunnen opladen, verwerken en terugkrijgen van de data alsook het factureren van gebruikers van het platform ifv 'modulair' principe. Inclusief draaiboeken hoe de data te capteren, verwerken, terugkrijgen en stockeren.</br> </br> </br> UC6</br> </br> Voorstel</br> </br> UC6: Incentivering</br> </br> Het kunnen vergoeden van 'bedrijven' wiens voertuigen dienen als 'base' voor de mobiele sensoren.</br> </br> </br> UC7</br> </br> Voorstel</br> </br> UC7: Inzichten & Dashboarding</br> </br> Het verkrijgen van inzichten die het beleid kan beinvloeden en/of bijsturen</br> </br> </br> UC8</br> </br> Voorstel</br> </br> UC8: Exploratie opportuniteit : Luchtkwaliteit, verkeersdrukte, enz.</br> </br> Vinden van extra use cases om de mobiele sensoren/camera's andere metingen te kunnen laten uitvoeren zoals luchtkwaliteit, verkeersdrukte, sluikstorten...</br> </br> </br> </br> </br> </br> Metadata </br> </br> </br> </br> </br> </br> Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases </br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC1</br> </br> Use case</br> </br> UC1: Mobiele Sensors</br> </br> Een keuze van sensoren moederbord en behuizing die passen op verschillende types van voertuigen (auto's, camionetten, vrachtwagens, fietsen, scooters, drones, ed meer)</br> </br> </br> BC1.1 </br> </br> Business capability </br> </br> Analyse van wat er al op de markt beschikbaar is</br> </br> </br> BC1.2 </br> </br> Business capability </br> </br> Recommendaties ifv verschillende scenario's (budget beschikbaar ?, context, thema, ed meer)</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC2</br> </br> Use case</br> </br> UC2: Verkeersborden Databanken</br> </br> Een volledige up to date databank van alle bestaande verkeersborden die al dan niet op zijn plaats staat, of (niet) besmeurd of gebogen zijn, ed meer.</br> </br> </br> BC2.1 </br> </br> Business capability </br> </br> Overzicht van alle verkeersborden die via de camera gecapteerd zijn tov de gekende verkeersborden databank</br> </br> </br> BC2.2 </br> </br> Business capability </br> </br> ifv prioritisatie een herstellingplan kunnen opstellen.</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC3</br> </br> Use case</br> </br> UC3: Connectie</br> </br> Een keuze van connectie mogelijkheden die 'mobiele' sensoren kunnen bedienen in de omgeving die gemeten moet worden. (5G, 4G, enz.)</br> </br> </br> BC3.1 </br> </br> Business capability </br> </br> markt en omgevingsanalyse</br> </br> </br> BC3.2 </br> </br> Business capability </br> </br> een connectie recommendatie ifv verschillende scenario's</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC4</br> </br> Use case</br> </br> UC4: Open Data</br> </br> Datastandaardisatie zowel op metadata (OSLO) alsook formaat(JSON-LD), bestekteksten, conformiteitsdocumenten, schaalbaarheid, interoperabiliteit, ...</br> </br> </br> BC4.1 </br> </br> Business capability </br> </br> Gap analyse met evt bestaande OSLO data standaarden</br> </br> </br> BC4.2 </br> </br> Business capability </br> </br> Definieren van de OSLO data standaarden</br> </br> </br> BC4.3 </br> </br> Business capability </br> </br> Definieren van bestekteksten, conformiteitsdocumenten</br> </br> </br> BC4.4 </br> </br> Business capability </br> </br> Valideren van interoperabiliteit en schaalbaarheid van de gekozen oplossing</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC5</br> </br> Use case</br> </br> UC5: Service</br> </br> Het kunnen opladen, verwerken en terugkrijgen van de data alsook het factureren van gebruikers van het platform ifv 'modulair' principe. Inclusief draaiboeken hoe de data te capteren, verwerken, terugkrijgen en stockeren.</br> </br> </br> BC5.1 </br> </br> Business capability </br> </br> foto's (en video's) kunnen opladen, na authenticicatie van gebruiker, om via algoritme een 'waarde' terug te krijgen over bvb verkeersborden die besmeurd zijn.</br> </br> </br> BC5.2 </br> </br> Business capability </br> </br> Het kunnen doorsturen van facturatie gegevens</br> </br> </br> BC5.3 </br> </br> Business capability </br> </br> Het kunnen online betalen van de service</br> </br> </br> BC5.4 </br> </br> Business capability </br> </br> Bibliotheek van draaiboeken voor steden die ook willen gebruik maken van deze platform</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC6</br> </br> Use case</br> </br> UC6: Incentivering</br> </br> Het kunnen vergoeden van 'bedrijven' wiens voertuigen dienen als 'base' voor de mobiele sensoren.</br> </br> </br> BC6.1 </br> </br> Business capability </br> </br> Standaard contracten die herbruikbaar zijn bij nieuwe 'leveranciers'</br> </br> </br> BC6.2 </br> </br> Business capability </br> </br> Betalingsmogelijkheden</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC7</br> </br> Use case</br> </br> UC7: Inzichten & Dashboarding</br> </br> Het verkrijgen van inzichten die het beleid kan beinvloeden en/of bijsturen</br> </br> </br> BC7.1 </br> </br> Business capability </br> </br> Het aantal gebruikers van service machine learning via mobiele sensoren per thema</br> </br> </br> BC7.2 </br> </br> Business capability </br> </br> De kosten en inkomsten van die service = P&L</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC8</br> </br> Use case</br> </br> UC8: Exploratie opportuniteit : Luchtkwaliteit, verkeersdrukte, enz.</br> </br> Vinden van extra use cases om de mobiele sensoren/camera's andere metingen te kunnen laten uitvoeren zoals luchtkwaliteit, verkeersdrukte, sluikstorten...</br> </br> </br> BC8.1 </br> </br> Business capability </br> </br> Analyse van beleidsdomeinen en prioriteiten om extra use cases te vinden. vinden.  +
• Inleiding Deze pagina bevat de eerste ve … Inleiding </br> Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we V0.1 noemen.</br>Dit kwam tot stand na de inhoudelijke intro met de initiatiefnemer van dit VLOCA traject en een studie van de aangeleverde informatie bij de start van het project.</br> </br> Situering van deze deliverable in het traject </br> Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. </br>Het is in de V0.1-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is. </br>Dit document vormt een basis voor het verdere verloop van het traject. </br>In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. </br> </br> Doel en doelgroep </br> Initiatiefnemers (lokale en bovenlokale besturen): De initiatiefnemers en hun project partners werken aan de hand van deze pagina de inhoud verder uit, waarna validatie en prioritering volgt. </br> Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. </br>Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be .</br>Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) </br> Bedrijven en kennisinstellingen: Heb je als bedrijf een visie op de generieke business vereisten van dit thema, dan nodigen we je uit om samen deze oefening verder mee vorm te geven.</br>Ben je leverancier aan overheden, vragen we je specifieke oplossingen niet te vermelden maar de generieke business en IT architectuur in co-creatie mee uit te werken. </br> Burgers en burgergroeperingen: </br>Voel je je als burger aangesproken door dit onderwerp en je hebt een visie op de ontwikkeling van oplossingen van dit thema, laat het ons zeker weten. </br> </br> Aanpak (korte beschrijving) </br> In dit VLOCA model V0.1 vertrekken we van de visie, missie en doelen zoals ze geformuleerd worden door de initiatiefnemer. </br>Deze gegevens worden verder verfijnd en uitgesplitst in objectieven, en hun de daaraan gelinkte business capabilities, data vereisten, functionele capabilities en technische vereisten. Een volledige omschrijving van het VLOCA-model kan je hier lezen.</br>In deze fase exploreert team VLOCA tevens de extra mogelijkheden rond deze use case. Deze worden in het project gevalideerd en al of niet in scope van het project genomen. Wanneer ze niet in scope worden genomen, kan deze bijdragen aan het uitwerken van een ander of een vervolgproject.</br> </br> Inhoud </br> Hieronder kan je de elementen van versie V0.1 van dit VLOCA model bekijken.</br> </br> </br></br> </br> CoT Slimme Markten: Hasselt, Turnhout, Halle </br> </br> </br> 2022 </br> </br> VLOCA-model versie 0.1 </br> </br> </br> VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be </br> </br> </br> Beschrijving en aanpak: </br> </br> https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model </br> </br> </br> </br> </br> </br> Strategie van de open city uitdaging </br> </br> </br> </br> </br> </br> </br> </br> Status </br> </br> Toelichting </br> </br> Beschrijving </br> </br> </br> Visie </br> </br> Voorstel</br> </br> Wat is de bestaansreden ?</br> </br> Ambulante handel maakt een belangrijk deel uit van het 'leven' binnen de lokale handelskernen, ze is het product van puur ondernemerschap en brengt ook 'publiek' naar de steden of deelgemeente toe. Vandaag is de ondersteuning daarvan helemaal niet digitaal. Dit belemmert de verdere ontwikkeling ervan in Vlaanderen, en met name in Hasselt, Turnhout en Halle.</br> </br> </br> Missie </br> </br> Voorstel</br> </br> Wat willen we bereiken ?</br> </br> Een volledige digitalisering van de 'ondersteuning' van lokale markten, zodat aanbieders met vragende partijen (bezoekers) bij elkaar kunnen komen in een digitale efficiente manier.</br> </br> </br> Doel </br> </br> Voorstel</br> </br> Wat is het doel van dit project ?</br> </br> (1) Een 'matchmaking/boekingsysteem' applicatie bouwen die de aanbod en vraag zowel voor de marktkramers (aanvragers) en steden en gemeenten (aanbieders) als voor de consumenten (aanvragers) en marktkramers (aanbieders). (2) Betere positionering van het markt gebeuren door de lokale overheid. (3) Vergemakkelijken van de administratie bij de aanvraag van een 'standplaats' of 'vergunning'. (4) Betere monitoring van de 'performantie' van de markten (sporadisch/op risico vs vaste marktkramers, welke producten, welke producten worden door de bezoekers gezocht worden maar worden niet aangeboden) => (5) revitaliseren van de markt via nieuwe bezoekers en marktkramers aan te trekken <= studie van 'behoeften' en 'aanbieders' gap zowel voor bezoeker en marktmaker. (Globale problematiek) =>(6) 'ik zoek iets, in welke stad kan ik dat vinden op welke dag' = centrale matchmaking platform intergemeentelijk (nu momenteel lokaal, maar het moet opschaalbaar op centrale niveau.</br> </br> </br> Succesfactor </br> </br> Voorstel</br> </br> Hoe meten we succes ? (SMART)</br> </br> Tegen 2025 moeten minstens 4 verschillende markten reeds digitaal zijn gemigreerd voor zowel aanvragers, aanbieders, zoekopdrachten mogelijkheden, ed meer in Hasselt, Turnhout en Halle.</br> </br> </br> </br> </br> </br> Use cases </br> </br> </br> </br> </br> </br> ID </br> </br> Status </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC1</br> </br> Voorstel</br> </br> UC1: Reservering Marktplaatsen</br> </br> Een visuele applicatie waar de markten per datum plaatsvinden, de beschikbare plaatsen grafisch getoond worden en met een muisklik een reservatie kan beheerd worden (aanvraag, verandering, verwijdering, enz.)</br> </br> </br> UC2</br> </br> Voorstel</br> </br> UC2: Planning Support</br> </br> De steden kunnen hun markten of 'standplaatsen' visueel en beschrijvend weergeven (wie staat waar, wat komt wanneer, wat is nog beschikbaar, enz) zodat de consumenten, maar ook de ambulante ondernemers hun planning efficient kunnen maken, waar ga ik wanneer voor wat.</br> </br> </br> UC3</br> </br> Voorstel</br> </br> UC3: Markt Bezoek Trends & Inzichten</br> </br> Rapportering van aantal marktaanbieders, bezoekers, wandelroutes binnen de markten, segmenten van bezoekers, om zo inzichten te verschaffen aan de 'overheid', 'marktkramers' en consumenten om zo betere beslissingen te kunnen nemen. (Incl. gap studie tussen behoefte en aanbod voor bezoekers en marktkramers)</br> </br> </br> UC4</br> </br> Voorstel</br> </br> UC4: Lokale economie in binnenstad stimuleren</br> </br> Het aantrekken van mensen buiten de stad tot de 'binnenstad' en zo zorgen voor extra bezoek en zo de binnenstad retail te laten mee profiteren met extra groei van 'passage' en hopelijk 'verkoop'</br> </br> </br> UC5</br> </br> Voorstel</br> </br> UC5: Beheer Vergunningen</br> </br> Beheer (=aanvraag, annulatie, aanpassing,…) van 'vergunningen' van ambulante handel volledig digitaliseren. Gelinkt aan e-loket voor ondernemers van VLAIO, alsook gelinkt aan een boekhouding systeem voor financiele opvolging (facturatie, betalingen, betwistingen, enz.)</br> </br> </br> UC6</br> </br> Voorstel</br> </br> UC6: Gerichte Markt Thema's</br> </br> Thema's van markten kunnen aanpassen ifv de type/segment van de marktkramers en de type/segment van de consumenten. (enkel voor initiatief vanuit stad, niet vanuit organisaties als 'evenement')</br> </br> </br> UC7</br> </br> Voorstel</br> </br> UC7: communicatie broker</br> </br> Speciale makelaars (broker) communicatie kanaal van handelaars naar consumenten ifv hun voorkeuren mbt interessen en manier van communicatie. Dus niet directe maar 'indirecte' manier van communicatie van 'publisher' tot 'subscribers' van een interesse thema. (via de stads app <= in Hasselt, in Turnhout en Halle ? => via een stadskanaal)</br> </br> </br> UC8</br> </br> Voorstel</br> </br> UC8: Aanmaak nieuwe markt en standplaatsen in digitaal systeem</br> </br> Creatie van een markt (keuze uit verschillende types : wekelijkse markt, jaarmarkt, rommelmarkt, boerenmarkt, …), invoering van de basis design van de markt (standplaatsen), de geokaart van de markt opstellen en opladen, standplaatsen opsplitsen, toevoegen, samenvoegen, verwijderen binnen een markt, ed meer</br> </br> </br> </br> </br> </br> Metadata </br> </br> </br> </br> </br> </br> Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases </br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC1</br> </br> Use case</br> </br> UC1: Reservering Marktplaatsen</br> </br> Een visuele applicatie waar de markten per datum plaatsvinden, de beschikbare plaatsen grafisch getoond worden en met een muisklik een reservatie kan beheerd worden (aanvraag, verandering, verwijdering, enz.)</br> </br> </br> BC1.1 </br> </br> Business capability </br> </br> Inlog en authenticatie systeem voor ambulante handelaars met vergunning toe te laten om hun reservaties te doen.</br> </br> </br> BC1.2 </br> </br> Business capability </br> </br> Ter beschikking stellen Visuele overzicht van alle standplaatsen per markt of locatie, wie waar staat, met type van markt (thema), en status van reservervaties op die plaatsen (groen : nog vrij, oranje : 'in optie' -nog niet bevestigd, rood : bevestigd gereserveerd, grijs te vroeg om te reserveren)</br> </br> </br> BC1.3 </br> </br> Business capability </br> </br> Reservatie management mogelijkheden van een 'standplaats'</br> </br> </br> BC1.4 </br> </br> Business capability </br> </br> rapportering </br> </br> Overzicht van status van standplaatsen om inzichten te verschaffen</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC2</br> </br> Use case</br> </br> UC2: Planning Support</br> </br> De steden kunnen hun markten of 'standplaatsen' visueel en beschrijvend weergeven (wie staat waar, wat komt wanneer, wat is nog beschikbaar, enz) zodat de consumenten, maar ook de ambulante ondernemers hun planning efficient kunnen maken, waar ga ik wanneer voor wat.</br> </br> </br> BC2.1 </br> </br> Business capability </br> </br> Zoekopdrachten </br> </br> Via filters een selectie kunnen doen van nog beschikbare standplaatsen per type van markten</br> </br> </br> BC2.2 </br> </br> Business capability </br> </br> Zoekopdrachten </br> </br> Via filters een selectie kunnen doen van bevestigde standplaatsen (=product aanbod) per type van markten en type van ambulante handel</br> </br> </br> BC2.3 </br> </br> Business capability </br> </br> Planningstool </br> </br> Planning kunnen opstellen ifv randvoorwaarden hoe je in 'gans' vlaanderen (of regionaal) overal aanwezig kunt zijn binnen de ingestelde randvoorwaarden.</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC3</br> </br> Use case</br> </br> UC3: Markt Bezoek Trends & Inzichten</br> </br> Rapportering van aantal marktaanbieders, bezoekers, wandelroutes binnen de markten, segmenten van bezoekers, om zo inzichten te verschaffen aan de 'overheid', 'marktkramers' en consumenten om zo betere beslissingen te kunnen nemen. (Incl. gap studie tussen behoefte en aanbod voor bezoekers en marktkramers)</br> </br> </br> BC3.1 </br> </br> Business capability </br> </br> Reviews op standplaatsen, bezoekers, handelaars en markten </br> </br> Toelaten om 'reviews' in te voeren door ambulante handelaars ivm hun standplaats, markt of passanten, maar ook van de exploitanten en passanten op ambulante handelaars, standplaatsen en markten</br> </br> </br> BC3.2 </br> </br> Business capability </br> </br> Rapportering </br> </br> Aantal Passanten, journey analyses, segmentaties van bezoekers en handelaars (mis)match</br> </br> </br> BC3.3 </br> </br> Business capability </br> </br> Toegang Rapportering </br> </br> Wie toegang heeft tot welke rapporten, analyses en data</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC4</br> </br> Use case</br> </br> UC4: Lokale economie in binnenstad stimuleren</br> </br> Het aantrekken van mensen buiten de stad tot de 'binnenstad' en zo zorgen voor extra bezoek en zo de binnenstad retail te laten mee profiteren met extra groei van 'passage' en hopelijk 'verkoop'</br> </br> </br> BC4.1 </br> </br> Business capability </br> </br> Vergelijken met en zonder markt </br> </br> Aantal bezoekers en omzet in binnenstad handelaars ifv het al dan niet aanwezig zijn van een markt in de buurt</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC5</br> </br> Use case</br> </br> UC5: Beheer Vergunningen</br> </br> Beheer (=aanvraag, annulatie, aanpassing,…) van 'vergunningen' van ambulante handel volledig digitaliseren. Gelinkt aan e-loket voor ondernemers van VLAIO, alsook gelinkt aan een boekhouding systeem voor financiele opvolging (facturatie, betalingen, betwistingen, enz.)</br> </br> </br> BC5.1 </br> </br> Business capability </br> </br> Vergunningen </br> </br> Het kunnen beheren van de vergunningen (aanvragen, betalen, verlengen, stopzeten, terugbetalen, enz.)</br> </br> </br> BC5.2 </br> </br> Business capability </br> </br> Rapportering </br> </br> Het kunnen rapportering van aantal vergunnings aanvragen en beheersmogelijkheden per markt</br> </br> </br> BC5.3 </br> </br> Business capability </br> </br> feedback, klachten reviews </br> </br> Het kunnen invullen van een 'feedback' mbt de geleverde dienst bij vergunning beheer</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC6</br> </br> Use case</br> </br> UC6: Gerichte Markt Thema's</br> </br> Thema's van markten kunnen aanpassen ifv de type/segment van de marktkramers en de type/segment van de consumenten. (enkel voor initiatief vanuit stad, niet vanuit organisaties als 'evenement')</br> </br> </br> BC6.1 </br> </br> Business capability </br> </br> Communicatie en CRM naar handelaars toe </br> </br> Het kunnen aanspreken van ambulante handelaars ifv hun segment type dat er een specifieke thema markt zal georganiseerd worden in de toekomst, of wanneer er nieuwe vacante standplaatsen 'vrijkomen'</br> </br> </br> BC6.2 </br> </br> Business capability </br> </br> Communicatie en CRM naar consumenten toe </br> </br> Het kunnen aanspreken van consumenten ifv hun segment type en voorkeuren dat er een specifieke thema markt zal georganiseerd worden in de toekomst.</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC7</br> </br> Use case</br> </br> UC7: communicatie broker</br> </br> Speciale makelaars (broker) communicatie kanaal van handelaars naar consumenten ifv hun voorkeuren mbt interessen en manier van communicatie. Dus niet directe maar 'indirecte' manier van communicatie van 'publisher' tot 'subscribers' van een interesse thema. (via de stads app <= in Hasselt, in Turnhout en Halle ? => via een stadskanaal)</br> </br> </br> BC7.1 </br> </br> Business capability </br> </br> Mogelijkheid om als consument interesse en voorkeuren in te vullen met de 'hoop' om bij interessante aanbiedingen een communicatie te krijgen van een handelaar die op een bepaalde ogenblik aanwezig zou zijn in een markt met een product die in de aangevinkte interesse ligt van de consument.</br> </br> </br> BC7.2 </br> </br> Business capability </br> </br> Het kunnen communiceren/invullen door de handelaars van bepaalde product categorieen die in een bepaalde 'interesse' sfeer vallen van een consument, met bijbehorende promoties of leuke weetjes ed meer</br> </br> </br> BC 7.3 </br> </br> Business capability </br> </br> Het kunnen registreren van consumenten (vragers) en handelaars (aanbieders) op de tool om de communicatie te faciliteren (via een systeem van 'broker', dus niet direct maar ifv 'subscribers' naar een 'thema' en 'publisher')</br> </br> </br> BC7.4 </br> </br> Business capability </br> </br> Het kunnen 'unsubscriben' van consumenten tot een bepaalde handelaar (bij bvb spamming)</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC8</br> </br> Use case</br> </br> UC8: Aanmaak nieuwe markt en standplaatsen in digitaal systeem</br> </br> Creatie van een markt (keuze uit verschillende types : wekelijkse markt, jaarmarkt, rommelmarkt, boerenmarkt, …), invoering van de basis design van de markt (standplaatsen), de geokaart van de markt opstellen en opladen, standplaatsen opsplitsen, toevoegen, samenvoegen, verwijderen binnen een markt, ed meer  +
• Inleiding Deze pagina bevat de eerste ve … Inleiding </br> Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we V0.1 noemen.</br>Dit kwam tot stand na de inhoudelijke intro met de initiatiefnemer van dit VLOCA traject en een studie van de aangeleverde informatie bij de start van het project.</br> </br> Situering van deze deliverable in het traject </br> Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. </br>Het is in de V0.1-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is. </br>Dit document vormt een basis voor het verdere verloop van het traject. </br>In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. </br> </br> Doel en doelgroep </br> Initiatiefnemers (lokale en bovenlokale besturen): De initiatiefnemers en hun project partners werken aan de hand van deze pagina de inhoud verder uit, waarna validatie en prioritering volgt. </br> Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. </br>Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be .</br>Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) </br> Bedrijven en kennisinstellingen: Heb je als bedrijf een visie op de generieke business vereisten van dit thema, dan nodigen we je uit om samen deze oefening verder mee vorm te geven.</br>Ben je leverancier aan overheden, vragen we je specifieke oplossingen niet te vermelden maar de generieke business en IT architectuur in co-creatie mee uit te werken. </br> Burgers en burgergroeperingen: </br>Voel je je als burger aangesproken door dit onderwerp en je hebt een visie op de ontwikkeling van oplossingen van dit thema, laat het ons zeker weten. </br> </br> Aanpak (korte beschrijving) </br> In dit VLOCA model V0.1 vertrekken we van de visie, missie en doelen zoals ze geformuleerd worden door de initiatiefnemer. </br>Deze gegevens worden verder verfijnd en uitgesplitst in objectieven, en hun de daaraan gelinkte business capabilities, data vereisten, functionele capabilities en technische vereisten. Een volledige omschrijving van het VLOCA-model kan je hier lezen.</br>In deze fase exploreert team VLOCA tevens de extra mogelijkheden rond deze use case. Deze worden in het project gevalideerd en al of niet in scope van het project genomen. Wanneer ze niet in scope worden genomen, kan deze bijdragen aan het uitwerken van een ander of een vervolgproject.</br> </br> Inhoud </br> Hieronder kan je de elementen van versie V0.1 van dit VLOCA model bekijken.</br> </br> </br></br> </br> CoT Smart Innovation Factory – Mechelen </br> </br> </br> 2022 </br> </br> VLOCA-model versie 0.1 </br> </br> </br> VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be </br> </br> </br> Beschrijving en aanpak: </br> </br> https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model </br> </br> </br> </br> </br> </br> Strategie van de open city uitdaging </br> </br> </br> </br> </br> </br> </br> </br> Status </br> </br> Toelichting </br> </br> Beschrijving </br> </br> </br> Visie </br> </br> Voorstel</br> </br> Wat is de bestaansreden ?</br> </br> Maximale waarde creaties door verschillende stakeholders op beschikbare databronnen (bestaande of potentieel beschikbaar, open of gesloten, gratis of betalend, dekkend/extrapollaties, ownership vraagstuk,...)</br> </br> </br> Missie </br> </br> Voorstel</br> </br> Wat willen we bereiken ?</br> </br> Inzichten over hoe de vraag en aanbod van open data kunnen afstemmen op elkaar, alsook het opzetten van een 'Smart Innovation Factory' die innovaties stimuleert vanuit een datagedreven perspectief.</br> </br> </br> Doel </br> </br> Voorstel</br> </br> Wat is het doel van dit project ?</br> </br> 1.Via exploratieve verkennende marktstudie overzicht van de vragende partijen voor open data binnen de quadruple helix, alsook de bestaande en potentiele bronnen van open data in kaart te brengen. 2.Bouwen van een 'innovatie' incubator in de regio rivierenland. 3.Een paar innovatie stimulerende usecases uitwerken met focus op thema klimaat en energie</br> </br> </br> Succesfactor </br> </br> Voorstel</br> </br> Hoe meten we succes ? (SMART)</br> </br> Aantonen van concrete innovaties geleverd dankzij het delen van data via de Smart Innovation Factory</br> </br> </br> </br> </br> </br> Use cases </br> </br> </br> </br> </br> </br> ID </br> </br> Status </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC1</br> </br> Voorstel</br> </br> UC1</br> </br> Overzicht via een 'segmentatie' van entiteiten (instituten, bedrijven, organisaties, individuen,...) die de vraag in kaart brengt. De vraag moet gevaloriseerd worden in 'intensiteit' en dus ook in 'bereidheid te betalen'.</br> </br> </br> UC2</br> </br> Voorstel</br> </br> UC2</br> </br> Overzicht via een typologie van data elementen die reeds of mogelijks in de toekomst kan aangeboden worden door de 'overheid' of andere partijen binnen de quadruple helix.</br> </br> </br> UC3</br> </br> Voorstel</br> </br> UC3</br> </br> Overzicht van de 'affiniteit' tussen de 'behoefte' segmentatie met de 'typologien' van open data (bronnen). =Matrix Segmenten tov open data typologien.</br> </br> </br> UC4</br> </br> Voorstel</br> </br> UC4</br> </br> Een platform die innovatie vanuit de bestaande databronnen mogelijk maakt. Het is een wisselwerking iteratief 'top down' en 'bottom up' proces, die kijkt naar wat er bestaat en hoe dit kan leiden tot economische en maatschappelijke innovaties. (niet: the sky is the limit brainstorm sessies)</br> </br> </br> UC5</br> </br> Voorstel</br> </br> UC5</br> </br> Bibliotheek van draaiboeken per typologie van data (= productgedreven), per behoefte segment (= klantgedreven) en per 'innovatie' traject.</br> </br> </br> UC6</br> </br> Voorstel</br> </br> UC6</br> </br> Een piloot data marktplaats laten bouwen en co-beheren waar de vraag en aanbod elkaar tegenkomen. Die marktplaats moet innovaties stimuleren en draagt dit ook in zijn kernbestaan. (Zonder innovaties en economische waarde = business development (geen piloot projectjes, geen puur onderzoeksomgeving) heeft dit geen bestaansredenen).</br> </br> </br> UC7</br> </br> Voorstel</br> </br> UC7</br> </br> De factory moet gemakkelijk connecteerbaar zijn met andere dataspaces initiatieven primair in de regio rivierenland en bij uitbreiding gans Vlaanderen en buiten. (Dataspaces principe)</br> </br> </br> </br> </br> </br> Metadata </br> </br> </br> </br> </br> </br> Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases </br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC1</br> </br> Use case</br> </br> UC1</br> </br> Overzicht via een 'segmentatie' van entiteiten (instituten, bedrijven, organisaties, individuen,...) die de vraag in kaart brengt. De vraag moet gevaloriseerd worden in 'intensiteit' en dus ook in 'bereidheid te betalen'.</br> </br> </br> BC1.1 </br> </br> Business capability </br> </br> Hoe groot is de vraag naar open data in aantal 'Entiteiten', intensiteit van de behoefte, bereidheid te betalen, welke type van data, frequentie, minimum kwaliteit, ed meer.</br> </br> </br> BC1.2 </br> </br> Business capability </br> </br> Welke behoefte gebaseerde segmenten (Needs Based Segmentation) bestaan er in de quadruple helix die homogeen dezelfde behoeften hebben binnen de segmenten en heterogeen anders zijn tussen de segmenten.</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC2</br> </br> Use case</br> </br> UC2</br> </br> Overzicht via een typologie van data elementen die reeds of mogelijks in de toekomst kan aangeboden worden door de 'overheid' of andere partijen binnen de quadruple helix.</br> </br> </br> BC2.1 </br> </br> Business capability </br> </br> Welke zijn de verschillende databronnen die reeds bestaan en wat is hun 'specificiteit' die een behoefte kan beantwoorden</br> </br> </br> BC2.2 </br> </br> Business capability </br> </br> Welke zijn de verschillende potentiele databronnen die nog 'ontgonnen' kunnen worden met hun specificiteit</br> </br> </br> BC2.3 </br> </br> Business capability </br> </br> Welke zijn de 'typologien' die de verschillende databronnen groeperen/clusteren die homogeen binnen en heterogeen tussen de groepen zijn.</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC3</br> </br> Use case</br> </br> UC3</br> </br> Overzicht van de 'affiniteit' tussen de 'behoefte' segmentatie met de 'typologien' van open data (bronnen). =Matrix Segmenten tov open data typologien.</br> </br> </br> BC3.1 </br> </br> Business capability </br> </br> Lijst van alle data (typologien) die een behoefte van een segment beantwoord.</br> </br> </br> BC3.2 </br> </br> Business capability </br> </br> Matrix die de affiniteit van de segmenten naar de data typologien visualiseert om daarmee een 'marketing', 'strategische' en 'operationeel' plan te kunnen uittekenen.</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC4</br> </br> Use case</br> </br> UC4</br> </br> Een platform die innovatie vanuit de bestaande databronnen mogelijk maakt. Het is een wisselwerking iteratief 'top down' en 'bottom up' proces, die kijkt naar wat er bestaat en hoe dit kan leiden tot economische en maatschappelijke innovaties. (niet: the sky is the limit brainstorm sessies)</br> </br> </br> BC4.1 </br> </br> Business capability </br> </br> Bevatten/Capteren van de 'probleemstellingen' per sector (met focus op energie en klimaat). De huidige noden, beperkingen en manier van werken.</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC5</br> </br> Use case</br> </br> UC5</br> </br> Bibliotheek van draaiboeken per typologie van data (= productgedreven), per behoefte segment (= klantgedreven) en per 'innovatie' traject.</br> </br> </br> BC5.1 </br> </br> Business capability </br> </br> Per databron een 'draaiboek' terugvinden die uitlegt hoe die data te capteren, verwerken, opslaan en ontsluiten voor een bepaalde segment behoefte</br> </br> </br> BC5.2 </br> </br> Business capability </br> </br> Per Segment behoefte, een 'draaiboek' terugvinden die uitlegt welke databronnen er moet 'ontgonnen' worden om zo de behoefte te kunnen invullen.</br> </br> </br> BC5.3 </br> </br> Business capability </br> </br> Draaiboek van hoe een lokale 'innovatie' platform te bouwen</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC6</br> </br> Use case</br> </br> UC6</br> </br> Een piloot data marktplaats laten bouwen en co-beheren waar de vraag en aanbod elkaar tegenkomen. Die marktplaats moet innovaties stimuleren en draagt dit ook in zijn kernbestaan. (Zonder innovaties en economische waarde = business development (geen piloot projectjes, geen puur onderzoeksomgeving) heeft dit geen bestaansredenen).</br> </br> </br> BC6.1 </br> </br> Business capability </br> </br> Het gemakkelijk/transparant kunnen ontsluiten van data (of andere assets zoals componenten, schema's, vocabularium, ed) in de marktplaats</br> </br> </br> BC6.2 </br> </br> Business capability </br> </br> Publiceren van metadata in lijn met internationale standaarden zoals DCAT</br> </br> </br> BC6.3 </br> </br> Business capability </br> </br> Transparant publiceren van de 'afkomst'/'Lineage'/'Callibraties'/Intrapollaties en Extrapollaties/enz.</br> </br> </br> BC6.4 </br> </br> Business capability </br> </br> Publicatie van of verwijzen naar schema en semantiek</br> </br> </br> BC6.5 </br> </br> Business capability </br> </br> Publiceren van de transport schema waarmee de data beschikbaar is (http, mqtt, ftp,...)</br> </br> </br> BC6.6 </br> </br> Business capability </br> </br> Het kunnen factureren van de data downloads a priori of a posteriori</br> </br> </br> BC6.7 </br> </br> Business capability </br> </br> Wat is de 'inhoudelijke' metadata van de verschillende beschikbare databronnen (via DCAT ?)</br> </br> </br> BC6.8 </br> </br> Business capability </br> </br> Het kunnen toegang verlenen via toegansbeheer platform afhankelijk van de gebruikersrechten</br> </br> </br> BC6.9 </br> </br> Business capability </br> </br> Reviews en feedback kunnen geven op die data (vanuit de gebruiker)</br> </br> </br> BC6.10 </br> </br> Business capability </br> </br> Notificaties wanneer data geupdate werden</br> </br> </br> BC6.11 </br> </br> Business capability </br> </br> Het registreren van transacties (= clearinghouse + voor inzichten op statistieken)</br> </br> </br> BC6.12 </br> </br> Business capability </br> </br> Access controle</br> </br> </br> BC6.13 </br> </br> Business capability </br> </br> Moet gebruik kunnen maken van derde identiteits providers (it's me,...)</br> </br> </br> BC6.14 </br> </br> Business capability </br> </br> CRM communicatie and marketing en verkoopsplanning</br> </br> </br> BC6.15 </br> </br> Business capability </br> </br> Betalingsmogelijkheden</br> </br> </br> BC6.16 </br> </br> Business capability </br> </br> Prijs structuur opstellen en publiceren</br> </br> </br> BC6.17 </br> </br> Business capability </br> </br> Publiceren van gebruiksrechten van data (alsook een open data charter waar de aanbieders en gebruikers zich moeten houden)</br> </br> </br> BC6.18 </br> </br> Business capability </br> </br> Een 'google' manier (search engine) om data terug te vinden.</br> </br> </br> BC6.19 </br> </br> Business capability </br> </br> Een visuele manier om data te categoriseren of behoeften te segmenteren.</br> </br> </br> BC6.20 </br> </br> Business capability </br> </br> Moet passen in een gefedereerde netwerk van catalogi (ref. dataspaces)</br> </br> </br> BC6.21 </br> </br> Business capability </br> </br> Zoeken naar potentiele co-beheerders van de SIF</br> </br> </br> BC6.22 </br> </br> Business capability </br> </br> Aanbesteding van het bouwen van de SIF</br> </br> </br> BC6.23 </br> </br> Business capability </br> </br> Uitwerken van een 'innovatie' methodologie (meerdere ?, per thema ?) voor het functioneren van SIF</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> UC7</br> </br> Use case</br> </br> UC7</br> </br> De factory moet gemakkelijk connecteerbaar zijn met andere dataspaces initiatieven primair in de regio rivierenland en bij uitbreiding gans Vlaanderen en buiten. (Dataspaces principe)</br> </br> </br> BC7.1 </br> </br> Business capability </br> </br> Wie zijn de relevante betrokken partijen uit de quadruple helix</br> </br> </br> BC7.2 </br> </br> Business capability </br> </br> Zoeken naar de bestaande Dataspaces met relevantie naar de SIF</br> </br> </br> BC 7.3 </br> </br> Business capability </br> </br> Organiseren van live of digitale communicatie tussen de partijen (innovatie workshops, overlegmomenten, newsletters, conferenties, webinars, enz.). Niet :overload aan hackatons..  +
• Inleiding Deze pagina bevat de eerste ve … Inleiding </br> Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we V0.1 noemen.</br>Dit kwam tot stand na de inhoudelijke intro met de initiatiefnemer van dit VLOCA traject en een studie van de aangeleverde informatie bij de start van het project.</br> </br> Situering van deze deliverable in het traject </br> Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. </br>Het is in de V0.1-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is. </br>Dit document vormt een basis voor het verdere verloop van het traject. </br>In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. </br> </br> Doel en doelgroep </br> Initiatiefnemers (lokale en bovenlokale besturen): De initiatiefnemers en hun project partners werken aan de hand van deze pagina de inhoud verder uit, waarna validatie en prioritering volgt. </br> Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. </br>Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be .</br>Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) </br> Bedrijven en kennisinstellingen: Heb je als bedrijf een visie op de generieke business vereisten van dit thema, dan nodigen we je uit om samen deze oefening verder mee vorm te geven.</br>Ben je leverancier aan overheden, vragen we je specifieke oplossingen niet te vermelden maar de generieke business en IT architectuur in co-creatie mee uit te werken. </br> Burgers en burgergroeperingen: </br>Voel je je als burger aangesproken door dit onderwerp en je hebt een visie op de ontwikkeling van oplossingen van dit thema, laat het ons zeker weten. </br> </br> Aanpak (korte beschrijving) </br> In dit VLOCA model V0.1 vertrekken we van de visie, missie en doelen zoals ze geformuleerd worden door de initiatiefnemer. </br>Deze gegevens worden verder verfijnd en uitgesplitst in objectieven, en hun de daaraan gelinkte business capabilities, data vereisten, functionele capabilities en technische vereisten. Een volledige omschrijving van het VLOCA-model kan je hier lezen.</br>In deze fase exploreert team VLOCA tevens de extra mogelijkheden rond deze use case. Deze worden in het project gevalideerd en al of niet in scope van het project genomen. Wanneer ze niet in scope worden genomen, kan deze bijdragen aan het uitwerken van een ander of een vervolgproject.</br> </br> Inhoud </br> Hieronder kan je de elementen van versie V0.1 van dit VLOCA model bekijken.</br> </br> </br></br> </br> Support Traject : Datagedreven handelsbeleid binnenstad </br> </br> </br> juli 2022 </br> </br> VLOCA-model versie 0.1 </br> </br> </br> VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be </br> </br> </br> Beschrijving en aanpak: </br> </br> https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model </br> </br> </br> </br> </br> </br> Strategie volgens use case </br> </br> </br> </br> </br> </br> </br> </br> Status </br> </br> Toelichting </br> </br> Beschrijving </br> </br> </br> Visie </br> </br> Voorstel</br> </br> Wat is de bestaansreden ?</br> </br> De binnenstad is het hart van de stad, een bruisende omgeving die de bezoekers begeestert met zowel cultuur, horeca als winkelen. Deze drie activiteiten versterken elkaar 'opportunistisch'.</br> </br> </br> Missie </br> </br> Voorstel</br> </br> Wat willen we bereiken ?</br> </br> We willen in de binnenstad een retail beleid kunnen voeren die meer data gedreven is, waarbij de stad de retailers helpt om te bloeien en groeien.</br> </br> </br> Doel </br> </br> Voorstel</br> </br> Wat is het doel van dit project ?</br> </br> De binnenstad moet continue attractiever worden voor de retailers</br> </br> </br> Succesfactor </br> </br> Voorstel</br> </br> Hoe meten we succes ? (SMART)</br> </br> De gemiddelde huur- en verkoopprijs voor winkelpanden (alsook woonpanden in zekere mate) in de binnenstad stijgt jaaarlijks met x% omdat de vraag groter wordt dan de aanbod.</br> </br> </br> </br> </br> </br> Objectieven van de use case </br> </br> </br> </br> </br> </br> ID </br> </br> Status </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> O1</br> </br> Voorstel</br> </br> Stadsmarketing</br> </br> De marketing campagnes van de stad zijn efficient en gericht ("targeted") zijn tegen 2023 (in tegenstelling tot eerder "broadcasting")</br> </br> </br> O2</br> </br> Voorstel</br> </br> Intelligentie</br> </br> De stad levert actioneerbare inzichten en intelligente cijfers mbt trends van bezoekers in de binnenstad aan de bestaande en potentiele retailers tegen 2023</br> </br> </br> O3</br> </br> Voorstel</br> </br> Druktegraad tov capaciteit</br> </br> De druktegraad en de parkeerbezetting om de winkelende bezoekers te kunnen opvangen moet altijd lager zijn dan 90% van de totale capaciteit</br> </br> </br> O4</br> </br> Voorstel</br> </br> Attractiviteit</br> </br> De attractiviteit van de binnenstad opvolgen met objectieve KPIs</br> </br> </br> O5</br> </br> Voorstel</br> </br> Mobiliteitsbeleid</br> </br> Verbeteren van de stad toegangkelijkheid via vervoersmodi</br> </br> </br> </br> </br> </br> Metadata van de objectieven </br> </br> </br> </br> </br> </br> </br> </br> Metaveld </br> </br> Beschrijving </br> </br> </br> </br> </br> Marketing</br> </br> Acquisitie van nieuwe bezoekers naar de binnenstad (liefst die nog ook kunnen en willen spenderen), Retentie (zorgen dat de bezoekers herhalend komen shoppen), Ontwikkelen (bij een bezoek van een bvb cultureel evenement begeleiden naar de winkelstraten = x-selling) of stimuleren van aankoop bij verschillende winkels = upselling.</br> </br> </br> </br> </br> Campagnes</br> </br> Een Campagne kan zowel puur communicatief zijn, of organiseren van 'evenementen' die bezoekers moet brengen naar een gebied. Een campagne word gevalueerd ifv de ' gr p'</br> </br> </br> </br> </br> GRP</br> </br> Gross Rating Point, of afgekort GRP, is een manier om de omvang van een advertentiecampagne te meten op basis van een specifiek medium of schema. In plaats van de omvang te meten van het publiek dat bereikt is, worden impressies gemeten als percentage van de totale doelgroep.</br> </br> </br> </br> </br> Captatie</br> </br> Hoeveel percentage van de doelgroep heeft minstens 1 impressie bereikt.</br> </br> </br> </br> </br> gericht</br> </br> gebaseerd op een doelgroep die men bereikt. GRP en Captatie maximaliseren en 'waste' minimaliseren.</br> </br> </br> </br> </br> actioneerbare inzichten</br> </br> Informatie die nadruk legt op de 'now what' ipv enkel de 'what' en de 'so what', soms worden die verrijkt met 'vooruitzichten' zowel macro als micro economisch</br> </br> </br> </br> </br> micro economische vooruitzichting</br> </br> Een externe inzicht gebaseerd op een lokale verwachte event, zoals bvb grote werken binnen de stad, grote shoppingcenter net buiten de stad, ed.</br> </br> </br> </br> </br> macro economisch</br> </br> Een externe inzicht gebaseerd op nationale of internationale tendensen waar de stad niet aan kan ontsnappen. Bvb het online boeken van reizen, corona beperkingen, enz.</br> </br> </br> </br> </br> intelligente cijfers</br> </br> pure cijfers kunnen ook inzichtvol gemaakt worden indien ze 'slim' zijn opgebouwd, men spreekt ook over 'smart kpi', bvb een ratio is veel sterker dan een absolute cijfer.</br> </br> </br> </br> </br> trends</br> </br> tegenpool van snapshot waar ipv de laatste gegevens ook de tendens gevoed door het gedrag van het verleden. Een snapshot zegt niet of dit aan het dalen is of aan het stijgen.</br> </br> </br> </br> </br> bezoeker</br> </br> iemand die een gebied binnenkomt via allerlei kanalen (wagen, trein, te voet)</br> </br> </br> </br> </br> retailers</br> </br> winkels, cabinetten van</br> </br> </br> </br> </br> bezorgen</br> </br> Bezorgen kan ofwel in een ' pus h' of ' pul l' modus zijn, kan in de vorm van csv/xls of ppt/pdf waarbij conclusies en recommendaties mogelijk worden, en met bepaalde frequentie </br> </br> </br> </br> </br> push modus</br> </br> de retailers krijgen die informatie toegestuurd via papieren document of in hun email box</br> </br> </br> </br> </br> pull modus</br> </br> de informatie wordt centraal terbeschikking gesteld op een portaal waar de retailers ze 'vrij' kunnen bekijken of downloaden</br> </br> </br> </br> </br> csv/xls</br> </br> de cijfers zijn in ruwe formaat beschikbaar zodat de retailer die zelf kunnen manipuleren en integreren in eigen business modellen</br> </br> </br> </br> </br> ppt/pdf</br> </br> de cijfers worden reeds geagregeerd met conclusies en eventueel recommendaties</br> </br> </br> </br> </br> frequentie</br> </br> bepaalt welke informatie wordt geupdate met welke frequentie (realtime, dagelijks, wekelijks, maandelijks, kwartaal, seizoen, semester of jaarlijks)</br> </br> </br> </br> </br> Capaciteit</br> </br> Een indicator die zowel de maximale 'drukte' in de binnenstad (waarbij het nog 'leuk' is voor de gemiddelde bezoeker') alsook de 'parkeerbezetting' berekend wordt in een percentage die frequent kan gemeten en gerapporteerd worden</br> </br> </br> </br> </br> Vervoersmodi</br> </br> Manier waarop bezoeker de stad (kan) binnentreden (auto, trein, fiets, te voet, shuttle, tram, bus, enz.)</br> </br> </br> </br> </br> Attractiviteit</br> </br> Attractiviteit is gemeten door de huurprijs, aankoopprijs per vierkante meter, leegstand in aantal en in gemiddelde tijd, enz. En dit vooral voor winkelpanden, maar ook voor bewoners van panden in de binnenstad.</br> </br> </br> </br> </br> </br> Per objectief: business capabilities (BC) >> data vereiste (DV) >> functionele capabilities (FC) >> technische vereiste (TV) </br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> O1</br> </br> Objectief</br> </br> Stadsmarketing </br> </br> De marketing campagnes van de stad zijn efficient en gericht ("targeted") zijn tegen 2023 (in tegenstelling tot eerder "broadcasting")</br> </br> </br> BC1.1 </br> </br> Business capability </br> </br> We meten de conversie ratio 'bezoekers ' tot ' binnenstapper s' met historiek</br> </br> </br> BC1.2 </br> </br> Business capability </br> </br> We meten de conversie ratio tot ' besteder s' met historiek</br> </br> </br> BC1.3 </br> </br> Business capability </br> </br> We 'de-averagen ' de ratio van BC1.1 en BC1.2 per 'profiel ' in de tijd</br> </br> </br> BC1.4 </br> </br> Business capability </br> </br> We ' profilere n' de 'bezoeker' op ' soci o demografisch e' variabelen op criteria bvb kassatickets</br> </br> </br> BC1.5 </br> </br> Business capability </br> </br> We 'profileren ' de 'bezoeker ' op zijn/haar 'winkelmissie' </br> </br> </br> BC1.6 </br> </br> Business capability </br> </br> We 'profileren ' de 'bezoeker ' op zijn/haar ' behoeft e', ' motivati e' en ' verwachtin g'</br> </br> </br> BC1.7 </br> </br> Business capability </br> </br> We documenteren het 'potentiël e afzetgebie d' van de 'prospecten ' van de binnenstad</br> </br> </br> BC1.8 </br> </br> Business capability </br> </br> We analyseren via een ' uitwisselingsmatri x' hoe de participatie of bezoek van een evenement of attractie 'park' elkaar al dan niet versterken</br> </br> </br> BC1.9 </br> </br> Business capability </br> </br> We analyseren de commerciele impact van evenementen (zoals jaarmarkten, festivals,...) op de detailhandel door te vergelijken met gelijkaardige momenten (of plaatsen) waar er geen eventement aanwezig was.</br> </br> </br> BC1.10 </br> </br> Business capability </br> </br> We tekenen met behulp van BC1.1 tem BC1.7 een marketing plan uit dat de ideale 'prospect ' met ' communicatie op maat ' naar de binnenstad moet brengen. De juiste boodschap voor de juiste prospect door middel van het juiste kanaal op het juiste moment.</br> </br> </br> BC1.11 </br> </br> Business capability </br> </br> We meten voor elke campagnes de geschatte ' ROI ' voor de handelaars in de binnenstad, vooral in termen van 'binnenstappers ', 'besteders ' en ' omzet' </br> </br> </br> BC1.12 </br> </br> Business capability </br> </br> We meten en visualiseren de ' customer journe y' om zo te begrijpen waar de winkels/horeca zich ook kunnen plaatsen in de zijstraten bvb.</br> </br> </br> BC1.13 </br> </br> Business capability </br> </br> We meten en visualiseren de 'Koopstromen'</br> </br> </br> BC1.14 </br> </br> Business capability </br> </br> We gebruiken externe parameters om bepaalde resultaten te verklaren, bvb het weer, de temperatuur, corona maatregelen, aantal werken in de stad, treinstakingen, enz.</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> O2</br> </br> Objectief</br> </br> Intelligentie </br> </br> De stad levert actioneerbare inzichten en intelligente cijfers mbt trends van bezoekers in de binnenstad aan de bestaande en potentiele retailers tegen 2023</br> </br> </br> BC2.1 </br> </br> Business capability </br> </br> We capteren de behoeften van de retailers voor data, van de datacatalogus, en inzichten per 'sector'</br> </br> </br> BC2.2 </br> </br> Business capability </br> </br> We communiceren met de handelaars</br> </br> </br> BC2.3 </br> </br> Business capability </br> </br> We ontsluiten de data van BC1 op een platform en een catalogus met uitleg over de data, alsook de metadata en schema</br> </br> </br> BC2.4 </br> </br> Business capability </br> </br> We analyseren de data van BC1 en formuleren daaruit conclusies en aanbevelingen.</br> </br> </br> BC2.5 </br> </br> Business capability </br> </br> We maken de toegang tot bepaalde data van BC1 betalend</br> </br> </br> BC2.6 </br> </br> Business capability </br> </br> We beantwoorden de ad ho c vragen van handelaars</br> </br> </br> BC2.7 </br> </br> Business capability </br> </br> We factureren de dienst aan de handelaar</br> </br> </br> BC2.8 </br> </br> Business capability </br> </br> We stellen trends per sector op om te begrijpen welke data elementen door welke sector gebruikt worden</br> </br> </br> BC2.9 </br> </br> Business capability </br> </br> We voorzien een regelmatig overzicht van conclusies en aanbevelingen voor de verschillende sectoren</br> </br> </br> BC2.10 </br> </br> Business capability </br> </br> We verrijken de conclusies en aanbevelingen met externe micro- en macro-economische factoren</br> </br> </br> BC2.11 </br> </br> Business capability </br> </br> Wij adviseren de lokale handelaars op vlak van verwachte drukte, personeelsinzet, openingsdagen/uren</br> </br> </br> BC2.12 </br> </br> Business capability </br> </br> Wij analiseren de performantie van aantrekkings incentives zoals loyalty, spaarkaarten, vouchers en stadsapp punten, ed op het bezoek en besteding in de stad</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> O3</br> </br> Objectief</br> </br> Druktegraad tov capaciteit </br> </br> De druktegraad en de parkeerbezetting om de winkelende bezoekers te kunnen opvangen moet altijd lager zijn dan 90% van de totale capaciteit</br> </br> </br> BC3.1 </br> </br> Business capability </br> </br> We meten de pieken en dalen van de parkeerbezetting, geografisch, per dag en per moment van de dag</br> </br> </br> BC3.2 </br> </br> Business capability </br> </br> We meten de bezoekers aantallen en bestedingen per transportmodus (trein, wagen, fiets, voetganger, bus, ea)</br> </br> </br> BC3.3 </br> </br> Business capability </br> </br> We meten de pieken en dalen van de wandeldrukt e geografisch, per dag en per moment van de dag</br> </br> </br> BC3.4 </br> </br> Business capability </br> </br> We bepalen een objectieve inde x, die subjectief aangeeft of het aangenaam wandelen en winkelen is in de binnenstad.</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> O4</br> </br> Objectief</br> </br> Attractiviteit </br> </br> De attractiviteit van de binnenstad opvolgen met objectieve KPIs</br> </br> </br> BC4.1 </br> </br> Business capability </br> </br> We meten de huurprijs per vierkante meter van winkelpanden in de binnenstad</br> </br> </br> BC4.2 </br> </br> Business capability </br> </br> We meten de huurprijs per vierkante meter van woonpanden in de binnenstad</br> </br> </br> BC4.3 </br> </br> Business capability </br> </br> We meten de verkoopprijs per vierkante meter van winkelpanden in de binnenstad</br> </br> </br> BC4.4 </br> </br> Business capability </br> </br> We meten de verkoopprijs per vierkante meter van woonpanden in de binnenstad</br> </br> </br> BC4.5 </br> </br> Business capability </br> </br> We meten de leegstand en de duur van de leegstand van winkelpanden in de binnenstad</br> </br> </br> BC4.6 </br> </br> Business capability </br> </br> We meten de leegstand en de duur van de leegstand van woonpanden in de binnenstad</br> </br> </br> BC4.7 </br> </br> Business capability </br> </br> We berekenen een attractiviteits index van de binnenstad</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> </br> O5</br> </br> Objectief</br> </br> Mobiliteitsbeleid </br> </br> Verbeteren van de stad toegangkelijkheid via vervoersmodi</br> </br> </br> BC5.1 </br> </br> Business capability </br> </br> Tijdsspanne om van de randgemeenten en randsteden tot in de binnenstad te geraken</br> </br> </br> BC5.2 </br> </br> Business capability </br> </br> Simulaties van impact van maatregelen op de tijdsspanne</br> </br> </br> BC5.3 </br> </br> Business capability </br> </br> Kosten per transportmodi kunnen bepalen om een ROI van het beleid op retail omzet te kunnen bepalenretail omzet te kunnen bepalen  +
• Inleiding Deze pagina bevat de eerste ve … Inleiding </br> Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we V0.2 noemen.</br>Dit kwam tot stand na de inhoudelijke intro met de initiatiefnemer van dit VLOCA traject en een studie van de aangeleverde informatie bij de start van het project.</br> </br> Situering van deze deliverable in het traject </br> Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. </br>Het is in de V0.2-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is. </br>Dit document vormt een basis voor het verdere verloop van het traject. </br>In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. </br> </br> Doel en doelgroep </br> Initiatiefnemers (lokale en bovenlokale besturen): De initiatiefnemers en hun project partners werken aan de hand van deze pagina de inhoud verder uit, waarna validatie en prioritering volgt. </br> Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. </br>Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be .</br>Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) </br> Bedrijven en kennisinstellingen: Heb je als bedrijf een visie op de generieke business vereisten van dit thema, dan nodigen we je uit om samen deze oefening verder mee vorm te geven.</br>Ben je leverancier aan overheden, vragen we je specifieke oplossingen niet te vermelden maar de generieke business en IT architectuur in co-creatie mee uit te werken. </br> Burgers en burgergroeperingen: </br>Voel je je als burger aangesproken door dit onderwerp en je hebt een visie op de ontwikkeling van oplossingen van dit thema, laat het ons zeker weten. </br> </br> Aanpak (korte beschrijving) </br> In dit VLOCA model V0.2 vertrekken we van de visie, missie en doelen zoals ze geformuleerd worden door de initiatiefnemer. </br>Deze gegevens worden verder verfijnd en uitgesplitst in objectieven, en hun de daaraan gelinkte business capabilities, data vereisten, functionele capabilities en technische vereisten. Een volledige omschrijving van het VLOCA-model kan je hier lezen.</br>In deze fase exploreert team VLOCA tevens de extra mogelijkheden rond deze use case. Deze worden in het project gevalideerd en al of niet in scope van het project genomen. Wanneer ze niet in scope worden genomen, kan deze bijdragen aan het uitwerken van een ander of een vervolgproject.</br> </br> Inhoud </br> Hieronder kan je de elementen van versie V0.2 van dit VLOCA model bekijken.</br> </br> </br></br> </br> Open Repair Data Platform ("ORDP") - van business capability naar technische vereisten </br> </br> </br> najaar 2021 </br> </br> VLOCA-model versie 0.1 </br> </br> </br> VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Beschrijving en aanpak: </br> </br> https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model </br> </br> Prioritering voor project van initiatiefnemer </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Strategie volgens use case </br> </br> </br> </br> </br> </br> </br> </br> Status </br> </br> Toelichting </br> </br> Beschrijving </br> </br> </br> Visie </br> </br> Voorstel</br> </br> Wat is de bestaansreden ?</br> </br> De circulaire economie is een economisch systeem waarbij de waarde van producten, materialen en andere hulpbronnen in de economie zo lang mogelijk wordt behouden, waarbij deze efficiënter worden gebruikt bij productie en consumptie, en waardoor het milieueffect van het gebruik ervan wordt verminderd, en afval en het vrijkomen van gevaarlijke stoffen in alle stadia van de levenscyclus zo veel mogelijk worden beperkt. (bron: Vlaanderen circulair) Op deze manier draagt ze bij aan de transitie naar een (ecologisch) duurzame economie (die binnen de "planetary boundaries" opereert). In een circulaire economie worden tal van strategieën toegepast om materialen en producten van bij de start zo te ontwerpen dat ze blijvend hoogwaardig in de economie kunnen worden ingezet. (bron: OVAM) Een van deze strateegieën is herstel. Hoewel herstel een optie kan zijn voor verschillende productgroepen zoals kledij, meubels, auto's,... richten we ons in dit initiatief enkel tot elektrische en elektronische apparaten. Uit verschillende studies en bevragingen (e.g. Special Eurobarometer 501 2019) weten we dat burgers die geconfrontreerd werden met een gefaald toestel, niet vaak voor herstel kiezen (~32%). De hoge zoekkosten (wie kan mij helpen?) en de onzekerheid of het toestel de investering nog waard is zijn de grootste drempels. Des te duurder de herstel is (arbeid- en transportkost nemen het grootste aandeel, maar wisselstukken kunnen soms ook zeer duur zijn tov de aankoop van een nieuw toestel) en des te onduidelijker het is hoelang het toestel nog zal meegaan na herstel, des te hoger deze onzekerheid.</br> </br> </br> Missie </br> </br> Voorstel</br> </br> Wat willen we bereiken ?</br> </br> Met dit initiatief willen we herstel aantrekkelijker maken door een (kosten-) efficientere werking met hoge succesgraad te faciliteren. Dit willen we doen door herstel data te verzamelen en te poolen om zo met behulp van AI in staat te zijn er inzichten uit te trekken:</br> (1) voor (vrijwillige/professionele) herstellers, retailers en burgers zodat de identificatie van het toestel en de faling en het vinden van de beste hersteloptie vlotter en beter gaat;</br>(2) voor invoerders/producenten om "design for repair" en voorraadbeheer van onderdelen te faciliteren;</br>(3) voor beleidsmakers (op alle niveaus) bij het formuleren van doelstellingen of nieuwe beleidsmaatregelen (op gebied van circulaire economie, klimaat, digitalisering) en het opvolgen van de voortgang. </br> </br> </br> </br> Doel </br> </br> Voorstel</br> </br> Wat is het doel van dit project ?</br> </br> EEA producten zo lang mogelijk en tegen zo hoog mogelijke waarde in de economie houden.</br> </br> </br> Succesfactor </br> </br> Voorstel</br> </br> Hoe meten we succes ? (SMART)</br> </br> Tegen 2025 gebruiken de 5 voornaamste bedrijven binnen de EEA waardeketen en de burgers en stadsbesturen van 5 Vlaamse steden, de ORDP infrastrcutuur, die 3 verschillende views heeft (hersteller, burger, lokaal bestuur) en hen 3 inzichten aanbiedt die voor een tijdbesparing zorgen.</br> </br> </br> </br> </br> </br> Objectieven van de use case </br> </br> scope in bold of met cijfertjes</br> </br> </br> </br> </br> </br> ID </br> </br> Status </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> In scope? </br> </br> Dringendheid 1-5 </br> </br> Belangrijkheid 1-5 </br> </br> Prioriteitscore fx </br> </br> </br> O1</br> </br> Voorstel</br> </br> input</br> </br> Data moet makkelijk ingevoerd kunnen worden door de "data opladers". Dit zijn: invoerders/producenten, retailers, professionele en vrijwillige herstellers van EEA.</br> </br> Ja</br> </br> 5</br> </br> 5</br> </br> 10 </br> </br> </br> O2</br> </br> Voorstel</br> </br> output</br> </br> Data moet gemakkelijk opgevraagd kunnen worden door de "klanten" (dit zijn de data opvragers en gebruikers van de inzichten van het ORDP). Deze komen uit alle hoeken van de quadruple helix en hebben zo ook verschillende profielen, noden en verwachtingen. We denken aan: grote tot kleine bedrijven (invoerders/producenten EEA, retailers, herstellers), overheden (verschillende niveaus van lokaal tot EU), onderzoek/innovatie, tot verenigingen en burgers.</br> </br> Ja</br> </br> 4</br> </br> 5</br> </br> 9 </br> </br> </br> O3</br> </br> Voorstel</br> </br> Applicatie</br> </br> De basisuitrusting is een databank en API die op een server staat. Er worden bewerkingen uitgevoerd op (delen van) de data set. De achterliggende code is voldoende afgeschermd, modulair opgesteld en staat gedetailleerd gedocumenteerd. Een procedure rond versiebeheer is opgesteld en strikt toegepast.</br> </br> Ja</br> </br> 4</br> </br> 4</br> </br> 8 </br> </br> </br> O4</br> </br> Voorstel</br> </br> Controle Kwalitatieve Data</br> </br> De data kwaliteit van zowel ingevoerde data als opgeleverde inzichten moet gegarandeerd kunnen worden door service level agreement met de eigenaars maar ook via sanity checks, data correcties, etc.</br> </br> Ja</br> </br> 3</br> </br> 4</br> </br> 7 </br> </br> </br> O5</br> </br> Voorstel</br> </br> systeem monitoring</br> </br> Het volledige proces wordt continu gemeten bij elke stap (hoeveel opladers, aanvragers, hoeveel ingelogd, hoeveel data correcties, hoeveel klachten,…)</br> </br> Ja</br> </br> 2</br> </br> 2</br> </br> 4 </br> </br> </br> O6</br> </br> Voorstel</br> </br> CRM</br> </br> Het ORDP moet haar bestaande en toekomstige 'stakeholders' (klanten, leveranciers, beleid, enz) kunnen contacteren met inzichten, belangrijke informatie, nieuwsbrieven en andere marketing tools.</br> </br> Ja</br> </br> 2</br> </br> 3</br> </br> 5 </br> </br> </br> O7</br> </br> Voorstel</br> </br> zelfbedruipend</br> </br> Het ORDP moet op termijn zijn eigen kosten kunnen dekken via inkomsten. (Betalend, incentives, reclame derde partijen, lidmaatschap, subsidies,…)</br> </br> Ja</br> </br> 2</br> </br> 5</br> </br> 7 </br> </br> </br> </br> </br> </br> Metadata van de objectieven </br> </br> </br> </br> </br> </br> </br> </br> Metaveld </br> </br> Beschrijving </br> </br> </br> </br> </br> EEA</br> </br> elektrische en electronische apparaten</br> </br> </br> </br> </br> ORDP</br> </br> een databank met (gelinkte) hersteldata uit verschillende bronnen (Open repair data allaince, repair connects, my minifactory, IFIXIT)</br> </br> </br> </br> </br> POM</br> </br> Afkorting voor "put on market" - hoeveelheden product op de marckt gebracht (gepubliceerd door Eurostat)</br> </br> </br> </br> </br> materiaalstock</br> </br> Hoeveelheden product aanwezig in een bepaald gebied. (Het toestel is al dan niet in gebruik.)</br> </br> </br> </br> </br> herstel</br> </br> het weer in goede staat terugbrengen</br> </br> </br> </br> </br> binnengebracht voor herstel</br> </br> een gefaald product afleveren zodat het eventueel zou kunnen hersteld worden</br> </br> </br> </br> </br> recyclage</br> </br> (een set van) materialen vervat in een product terugwinnen</br> </br> </br> </br> </br> binnengebracht voor recyclage</br> </br> een materiaal of product afleveren zodat er materialen uit kunnen teruggewonnen worden</br> </br> </br> </br> </br> hergebruik</br> </br> het weer gebruiken van een artikel zonder dat daarvoor de nodige handelingen moeten worden verricht; het product veranderd dus van eigenaar</br> </br> </br> </br> </br> binnengebracht voor hergebruik</br> </br> het materiaal/product aanbieden aan organsitei dat hergebruikte goederen weer op de markt brengt</br> </br> </br> </br> </br> vrijwillige herstel</br> </br> aanbieden van herstelactiviteiten (kennis, apparatuur) op vrijwillige basis dus onbezoldigd (bv. Repair café of aan kennis, buur,...)</br> </br> </br> </br> </br> self repair</br> </br> Eigenhandig herstellen van goederen in bezit met of zonder externe hulp</br> </br> </br> </br> </br> professionele herstel</br> </br> Activiteiten onder (B2B) NACE 33.1 en (B2C) NACE 95.1 & 95.2 .</br> </br> </br> </br> </br> succesvolle reparatie</br> </br> een herstel dat met succes heeft plaatsgevonden</br> </br> </br> </br> </br> 3D print designs</br> </br> een 3D representatie van een product</br> </br> </br> </br> </br> peer-to-peer</br> </br> delen van bestanden</br> </br> </br> </br> </br> user interface</br> </br> digitaal platform waar data verzameld worden en inzichten op aangeboden worden</br> </br> </br> </br> </br> dashboard</br> </br> een soort grafische gebruikersinterface die vaak in één oogopslag een overzicht geeft van de belangrijkste prestatie-indicatoren die relevant zijn voor een bepaald doel of bedrijfsproces</br> </br> </br> </br> </br> data infrastructuur</br> </br> de verzameling voorzieningen die nodig is voor het transport van digitale signalen die gegevens bevatten</br> </br> </br> </br> </br> data architectuur</br> </br> een overzicht van de aanwezige en benodigde gegevens in een ecosysteem</br> </br> </br> </br> </br> data leverancier</br> </br> een organisatie die data capteert en aanbiedt</br> </br> </br> </br> </br> gebruiker</br> </br> vraag naar inzichten, indicatoren,…</br> </br> </br> </br> </br> AI</br> </br> artificiele intelligentie, in deze context meestal gezien als deep learning waarbij men leert uit historisch herstelactiviteiten en dit gebruikt voor het formuleren van de beste hersteloptie</br> </br> </br> </br> </br> onderhoudsvriendelijk</br> </br> weinig effort nodig om het systeem te onderhouden</br> </br> </br> </br> </br> kostenefficiënt</br> </br> het ontwerp van het ORDP houdt rekening met de mogelijkheid nieuwe uitbreidingen te doen met zo weinig mogelijk tijdsinspanning en extra kosten</br> </br> </br> </br> </br> analysetool</br> </br> een hulpmiddel voor het uitvoeren van een analyse</br> </br> </br> </br> </br> monitoring framework</br> </br> een set van indicatoren die helpen om te bepalen of een beleid de gewenste resultaten heeft</br> </br> </br> </br> </br> CE</br> </br> Circulaire economie</br> </br> </br> </br> </br> OEM</br> </br> Original equipment manufacturer ofwel invoerder en producten van EEA (in Europa)</br> </br> </br> </br> </br> SLA</br> </br> service level agreement, een type overeenkomst waarin afspraken staan tussen aanbieder en afnemer van een dienst of product.</br> </br> </br> </br> </br> Data oplader</br> </br> Organisaties en initiatieven zoals invoerders/producenten, retailers, professionele en vrijwillige herstellers van EEA, die herstellingen digitaal rapporteren en deze data aanleveren aan het ORDP.</br> </br> </br> </br> </br> Klant</br> </br> data bevragers en gebruikers van de inzichten uit ORDP</br> </br> </br> </br> </br> </br> Per objectief: business capabilities (BC) >> data vereiste (DV) >> functionele capabilities (FC) >> technische vereiste (TV) </br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> In scope? </br> </br> Dringendheid 1-5 </br> </br> Belangrijkheid 1-5 </br> </br> Prioriteitscore fx </br> </br> </br> O1</br> </br> Objectief</br> </br> input </br> </br> Data moet makkelijk ingevoerd kunnen worden door de "data opladers". Dit zijn: invoerders/producenten, retailers, professionele en vrijwillige herstellers van EEA.</br> </br> Ja</br> </br> 5</br> </br> 5</br> </br> 10</br> </br> </br> BC1.1 </br> </br> Business capability </br> </br> Profielen </br> </br> Als data oplader moet ik mij kunnen authenticeren om schrijfrechten te krijgen.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC1.2 </br> </br> Business capability </br> </br> Data ophalen </br> </br> Als beheerder wil ik dat het ORDP zelf (semi- of volautomatisch) data die online gepubliceerd worden op regelmatige tijdstippen of bij bepaalde triggers of events kan opladen in de ORDP Database.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC1.3 </br> </br> Business capability </br> </br> Data instroom tools </br> </br> Als beheerder wil ik dat alle applicaties die het ORDP platform lezen ook hun ingevoerde data automatisch in de ORDP database opgeladen worden. Ook als de 'gebruiker' bvb slechts een handleiding heeft gedownload, willen wij dat weten om daarmee "profielen" af te bakenen of verder te verfijnen.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC1.4 </br> </br> Business capability </br> </br> Data dumpen </br> </br> Als beheerder wil ik een datafile als 'dump' file, in bvb JSON or CSV, kunnen opladen in de ORDP database.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC1.5 </br> </br> Business capability </br> </br> Validatie </br> </br> Als beheerder of als 'oplader' moet ik genoeg data krijgen rond de kwaliteit van het opladen alsook de data zelf. Dit kan visueel, met snelle tabellen met cijfers (aantal rijen, aantal kolommen, enz.) of zelfs via AI die een 'eerste' indruk geven van mogelijke 'issues' in de data.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC1.6 </br> </br> Business capability </br> </br> Rapportering </br> </br> Als beheerder wil ik aan de 'oplader' een rapportje sturen mbt alle opgeladen data (stromen), alsook aan de stakeholders statistieken kunnen geven ivm aantal en volume van data opladingen.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC1.7 </br> </br> Business capability </br> </br> Feedback </br> </br> Als data oplader wil ik feedback kunnen geven ivm de data die ik heb opgeladen (kwaliteit, metadata, 'let ops', 'FAQ', …)</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC1.8 </br> </br> Business capability </br> </br> Review </br> </br> Als data oplader wil ik ook mijn mening kunnen geven ivm ORDP samenwerking en als beheerder wil ik dat kunnen rapporteren.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC1.9 </br> </br> Business capability </br> </br> Data afschermen </br> </br> Als beheerder wil ik de data van bepaalde opladers beschermen (op vraag van de data eigenaars en opladers) en beperkte leesrechten geven aan bepaalde klantenprofielen.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC1.10 </br> </br> Business capability </br> </br> foutmelding </br> </br> Als data oplader wil ik een foutmelding krijgen die mij uitlegt waar het probleem zich situeert.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> In scope? </br> </br> Dringendheid 1-5 </br> </br> Belangrijkheid 1-5 </br> </br> Prioriteitscore fx </br> </br> </br> O2</br> </br> Objectief</br> </br> output </br> </br> Data moet gemakkelijk opgevraagd kunnen worden door de "klanten" (dit zijn de data opvragers en gebruikers van de inzichten van het ORDP). Deze komen uit alle hoeken van de quadruple helix en hebben zo ook verschillende profielen, noden en verwachtingen. We denken aan: grote tot kleine bedrijven (invoerders/producenten EEA, retailers, herstellers), overheden (verschillende niveaus van lokaal tot EU), onderzoek/innovatie, tot verenigingen en burgers.</br> </br> Ja</br> </br> 4</br> </br> 5</br> </br> 9</br> </br> </br> BC2.1 </br> </br> Business capability </br> </br> Noden/profielen </br> </br> Als beheerder wil ik de "klanten" segmenteren ifv hun behoeften (frequentie, type van bevragingen, type van gewenste inzichten, enz.)</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC2.2 </br> </br> Business capability </br> </br> Authenticatie </br> </br> Als klant wil ik mij kunnen inloggen om mijn leesrechten te verkrijgen (ook evt schrijfrechten), soms ben ik zowel klant als dataoplader van ORDP.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC2.3 </br> </br> Business capability </br> </br> Dashboard </br> </br> Als beheerder wil ik het dashboard (eerste pagina na inloggen, ook landingspagina bvb) op maat maken ifv het klanten profiel.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC2.4 </br> </br> Business capability </br> </br> Rapportering </br> </br> Als klant wil ik een overzicht hebben over mijn gebruik binnen ORDP.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC2.5 </br> </br> Business capability </br> </br> Feedback </br> </br> Als klant wil ik feedback en evaluatie kunnen geven van de data in ORDP of van de inzichten uit ORDP.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC2.6 </br> </br> Business capability </br> </br> Reviews </br> </br> Als klant wil ik ook mijn mening kunnen geven ivm ORDP samenwerking en als beheerder wil ik dat kunnen meten.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> BC2.7 </br> </br> Business capability </br> </br> Ad hoc inzichten </br> </br> Als klant wil ik ook inzichten (zoals bv. is Samsung beter dan Apple?, 'grote kans dat een gefaald onderdeel aan de basis ligt van uw probleem') die kunnen afgeleid worden uit statistieken iin onze databank, kunnen verkrijgen rond het problematiek waar ik momenteel mee bezig ben.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC2.8 </br> </br> Business capability </br> </br> Recurrent Analysis </br> </br> Als klant wil ik meer 'complexe' rapporten kunnen draaien die mij inzichten verschaffen rond het problematiek waar ik momenteel mee bezig ben.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC2.9 </br> </br> Business capability </br> </br> Opgeslagen Rapporten </br> </br> Als klant wil ik mijn eigen rapport kunnen 'schrijven' die ik ook kan opslaan bij een volgende inlog moment.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC2.10 </br> </br> Business capability </br> </br> Rapporten sharing </br> </br> Als klant wil ik mijn rapport ook met andere kunnen delen, of wil ik een rapport van een andere klant kunnen inzien.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC2.11 </br> </br> Business capability </br> </br> foutmelding </br> </br> Als klant wil ik een foutmelding krijgen bij een probleem die uitlegt wat het probleem is en hoe hiermee verder te kunnen.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> In scope? </br> </br> Dringendheid 1-5 </br> </br> Belangrijkheid 1-5 </br> </br> Prioriteitscore fx </br> </br> </br> O3</br> </br> Objectief</br> </br> Applicatie </br> </br> De basisuitrusting is een databank en API die op een server staat. Er worden bewerkingen uitgevoerd op (delen van) de data set. De achterliggende code is voldoende afgeschermd, modulair opgesteld en staat gedetailleerd gedocumenteerd. Een procedure rond versiebeheer is opgesteld en strikt toegepast.</br> </br> Ja</br> </br> 4</br> </br> 4</br> </br> 8</br> </br> </br> BC3.1 </br> </br> Business capability </br> </br> Basisuitrusting </br> </br> Als beheerder wil ik kunnen garanderen en managen dat de toegangen en data manipulatie scriptjes continue blijven werken. Dit moet ik ook kunnen rapporteren en communiceren (bvb. Systeem heeft al dan niet succesvol verlopen, zondag tussen 1h en 5h is ORDP niet bereikbaar wegens onderhoud, enz.)</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC3.2 </br> </br> Business capability </br> </br> Versiebeheer </br> </br> Als beheerder wil ik alle versies van scripts maar ook data kunnen bijhouden en eventueel bij incidenten kunnen 'restoren'.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC3.3 </br> </br> Business capability </br> </br> Stockeren </br> </br> Als beheerder wil ik de data en scriptjes op een 'deftige'/'legale'/'wenselijke' locatie geplaatst worden waarbij er een minimum aan SLA kan gegarandeerd worden.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC3.4 </br> </br> Business capability </br> </br> Bewerkingen instroom </br> </br> Als beheerder wil ik een sofware scriptje kunnen gebruiken om de opgeladen data te kunnen 'manipuleren' (debugging, outliers verwijderen, formatteren van tabellen in correcte formaten, aligneren en opladen, enz.)</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC3.5 </br> </br> Business capability </br> </br> Inzichten </br> </br> Als beheerder wil ik inzichten verkrijgen over het gebruik van de applicatie (aantal inloggers, type van bevragingen, gedraaide scriptjes, aantal foutmeldingen, aantal 'fraudeurs', enz.)</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC3.6 </br> </br> Business capability </br> </br> BI Team </br> </br> Als beheerder wil ik een service kunnen geven aan de klanten om de (toekomstige) noden te helpen identificeren. Dit bevordert de klantentevredenheid (des te meer inzichten gebruikt worden door de klanten ze te waardevoller de samenwerking wordt) nu maar ook in de toekomst (door onze systemenen steeds verder te otnwikkelen, willen we garanderen dat we ook in de toekomst relevant kunnen zijn). (Van data naar inzichten)</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC3.7 </br> </br> Business capability </br> </br> Beheer van 3de partijen </br> </br> Als beheerder wil ik alle applicaties die toegang krijgen tot ORDP kunnen overzichtelijk maken en vooral beheren (toegang geven, stopzetten, controleren, inzichten, …)</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC3.8 </br> </br> Business capability </br> </br> AI beslissingsboom </br> </br> Een machine learning methode om te weten welke informatie er telkens nodig is om een reparatie plan voor te stellen. Dit via een 'beslissingsboom' : welke merk ?=> welk aankoopjaar => enz.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC3.9 </br> </br> Business capability </br> </br> 3de partijen </br> </br> Als beheerder wil ik derde partijen (voor een vooraf vastgelegde periode) toegang geven tot het platform en dit op een degelijke manier managen. Eventueel betalend maken ifv type toegang, enz.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC3.10 </br> </br> Business capability </br> </br> foutmeldingen </br> </br> Als beheerder wil ik geinformeerd worden bij elke 'mankement' door een specifieke foutmelding te krijgen</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC3.11 </br> </br> Business capability </br> </br> Automatische AI ML </br> </br> Als applicatie beheerder wil ik modellen 'on the fly' kunnen bouwen (en valideren) en zo voorkomen dat er teveel tijd gestoken worden in eenmalige acties. Zo willen we modellen bouwen en in productie zetten tot de kwaliteits scores te laag te worden. Indien zo, sturen we bij.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> In scope? </br> </br> Dringendheid 1-5 </br> </br> Belangrijkheid 1-5 </br> </br> Prioriteitscore fx </br> </br> </br> O4</br> </br> Objectief</br> </br> Controle Kwalitatieve Data </br> </br> De data kwaliteit van zowel ingevoerde data als opgeleverde inzichten moet gegarandeerd kunnen worden door service level agreement met de eigenaars maar ook via sanity checks, data correcties, etc.</br> </br> Ja</br> </br> 3</br> </br> 4</br> </br> 7</br> </br> </br> BC4.1 </br> </br> Business capability </br> </br> SLA </br> </br> Als beheerder wil ik met de eigenaars van de data en applicatie een SLA kunnen opstellen die een minimum kwaliteit garanderen (data volumes, kolommen, frequentie, correcties, recencies,…)</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC4.2 </br> </br> Business capability </br> </br> Opvolging SLA </br> </br> Als beheerder wil ik een plaform hebben waar we de SLA kunnen opvolgen, bespreken, heronderhandelen en zelfs eventueel opheffen (beboeten door de flow te stoppen)</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC4.3 </br> </br> Business capability </br> </br> Sanity checks </br> </br> Als beheerder wil ik sanity checks rapporten kunnen bouwen die mij inzichten geven over de kwaliteit van de data alsook over de kwaliteit van de applicaties en geleverde inzichten.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC4.4 </br> </br> Business capability </br> </br> Automatic Correction </br> </br> Als beheerder wil ik een zelf corrigerende scriptjes (AI via Machine Learning) kunnen lanceren die de data zelf gaan opvullen, vervangen of verwijderen.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC4.5 </br> </br> Business capability </br> </br> Kwaliteitsscore </br> </br> Als beheerder wil ik een score kunnen berekenen en rapporteren ivm de ingeschatte kwaliteit van de data of applicatie.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC4.6 </br> </br> Business capability </br> </br> Benchmarking </br> </br> Als beheerder wil ik de kwaliteit van de data en applicaties kunnen vergelijken met wat er in andere steden en landen of organisaties gebeuren.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC4.7 </br> </br> Business capability </br> </br> AI kwaliteit </br> </br> Als beheerder en klant wil ik de kwaliteit kennen van de voorgestelde reparatie stappen door te vergelijken met actuele resultaten. (the proof of the pudding is in the eating)</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> In scope? </br> </br> Dringendheid 1-5 </br> </br> Belangrijkheid 1-5 </br> </br> Prioriteitscore fx </br> </br> </br> O5</br> </br> Objectief</br> </br> systeem monitoring </br> </br> Het volledige proces wordt continu gemeten bij elke stap (hoeveel opladers, aanvragers, hoeveel ingelogd, hoeveel data correcties, hoeveel klachten,…)</br> </br> Ja</br> </br> 2</br> </br> 2</br> </br> 4</br> </br> </br> BC5.1 </br> </br> Business capability </br> </br> Current use </br> </br> Als beheerder wil ik op elke moment weten wie momenteel is ingelogd, aan het opladen, queries aan het schrijven, aan het draaien, enz.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC5.2 </br> </br> Business capability </br> </br> Historiek </br> </br> Als beheerder wil ik een overzicht kunnen krijgen ivm historiek van inlogging, opladen, queries, klachten, foutmeldingen, enz.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC5.3 </br> </br> Business capability </br> </br> Performantie </br> </br> Als beheerder wil ik de performantie van alle proces stappen kunnen meten en rapporteren (bvb hoe lang duurt een oplading van duizend rijen,…)</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC5.4 </br> </br> Business capability </br> </br> Financien </br> </br> Als beheerder wil ik monitoring van 'prestaties' (mandagen), 'facturaties', 'kosten', 'cashflow', enz.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> In scope? </br> </br> Dringendheid 1-5 </br> </br> Belangrijkheid 1-5 </br> </br> Prioriteitscore fx </br> </br> </br> O6</br> </br> Objectief</br> </br> CRM </br> </br> Het ORDP moet haar bestaande en toekomstige 'stakeholders' (klanten, leveranciers, beleid, enz) kunnen contacteren met inzichten, belangrijke informatie, nieuwsbrieven en andere marketing tools.</br> </br> Ja</br> </br> 2</br> </br> 3</br> </br> 5</br> </br> </br> BC6.1 </br> </br> Business capability </br> </br> Data </br> </br> Als beheerder wil ik een databank met optin optout van de stakeholders met relevante contact informatie, profielen, enz.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC6.2 </br> </br> Business capability </br> </br> Trigger Based Comm. </br> </br> Als beheerder wil ik een marketing automation systeem hebben dat mijn stakeholders contacteert met informatie die gerelateerd is aan hun profiel of activiteiten die zij in het (nabije) verleden hebben uitgevoerd.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC6.3 </br> </br> Business capability </br> </br> Acquisitie </br> </br> Als beheerder wil ik prospectie kunnen doen om ons platform te promoten bij eventuele toekomstige gebruikers, opladers, stakeholders, beleidsmensen, enz.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC6.4 </br> </br> Business capability </br> </br> Loyalty </br> </br> Als beheerder wil ik loyale gebruikers belonen</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC6.5 </br> </br> Business capability </br> </br> Retentie </br> </br> Als beheerder wil ik 'churners' (gebruikers die afgehaakt zijn) of churnrisk gebruikers kunnen contacteren om hen terug op onze platform te komen.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC6.6 </br> </br> Business capability </br> </br> KPI </br> </br> Als beheerder wil ik weten welke KPI's we best nastreven, en hoe we scoren op elke KPI.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> </br> </br> </br> ID </br> </br> Type </br> </br> Samenvatting </br> </br> Beschrijving </br> </br> In scope? </br> </br> Dringendheid 1-5 </br> </br> Belangrijkheid 1-5 </br> </br> Prioriteitscore fx </br> </br> </br> O7</br> </br> Objectief</br> </br> zelfbedruipend </br> </br> Het ORDP moet op termijn zijn eigen kosten kunnen dekken via inkomsten. (Betalend, incentives, reclame derde partijen, lidmaatschap, subsidies,…)</br> </br> Ja</br> </br> 2</br> </br> 5</br> </br> 7</br> </br> </br> BC7.1 </br> </br> Business capability </br> </br> </br> </br> Als beheerder wil ik een betalende registratie mogelijk maken.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC7.2 </br> </br> Business capability </br> </br> </br> </br> Als beheerder wil ik verschillende 'offer design' (abonnementen, pay per use, rent, buy, enz.) kunnen voorstellen.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC7.3 </br> </br> Business capability </br> </br> </br> </br> Als beheerder moet de data oplader eventueel ook vergoeden/vergoed worden ifv contractuele bepalingen.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC7.4 </br> </br> Business capability </br> </br> </br> </br> Als beheerder wil ik de 'gebruikers' kunnen aanmanen, disconnecteren, herinneren, in gebreke stellen,… in functie van hun betalingsgedrag.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC7.5 </br> </br> Business capability </br> </br> </br> </br> Als beheerder wil ik de klant online laten betalen, of via factuur en overschrijving, of via de bankapp, enz.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC7.6 </br> </br> Business capability </br> </br> </br> </br> Als beheerder wil ik op onze applicatie of website reclame kunnen plaatsen om inkomsten te genereren.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC7.7 </br> </br> Business capability </br> </br> </br> </br> Als beheerder wil ik de applicaties die op het ORDP gebouwd kunnen worden, factureren ifv hun gebruik, vaste prijs (lump sum), cost based, enz.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC7.8 </br> </br> Business capability </br> </br> </br> </br> Als beheerder wil ik alternatieve inkomsten stromen kunnen voorzien (creatie van entiteit (VZW, Cooperatieve,…), facturatie systeem, boekhouding, enz.)</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC7.9 </br> </br> Business capability </br> </br> </br> </br> Als beheerder wil ik op een 'lucratieve' manier de opladers van data maar ook van reviews, opmerkingen, tips, enz) belonen.</br> </br> Ja</br> </br> </br> </br> </br> </br> 0</br> </br> </br> BC7.10 </br> </br> Business capability </br> </br> </br> </br> Als beheerder wil ik 'sponsoring' kunnen toestaan ifv de 'waarden' die we delen met de 'sponsor'</br> </br> Ja</br> </br> </br> </br> </br> </br> 0  +
• Inleiding Deze pagina bevat de eerste ve … Inleiding </br> Deze pagina bevat de eerste versie van stakeholder analyse. Het is een niet finale versie die we v0.1 noemen.</br>Dit kwam tot stand na het opstellen van een [Deliverable:_VLOCA-model VLOCA-model] en het verzamelen van input bij de initiatiefnemers, tijdens en na de kennismakingsworkshop.</br> </br> Situering van deze deliverable in het traject </br> Deze deliverable wordt uitgewerkt na de kennismakingsworkshop en het VLOCA-model V0.1 en wordt opgeleverd bij de opstartworkshop van het traject (workshop 1).</br>Het is in de v0.1-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is. </br>Dit document vormt een basis voor het verdere verloop van het traject. </br>In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. </br> </br> Doel en doelgroep </br> Het Doel van de stakeholder analyse is om alle belanghebbenden bij het traject in kaart te zetten, hun verwachtingen, noden, behoeften en uitdagingen in kaart te zetten.</br>De analyse werkt verder uit hoe we welke stakeholders moeten betrekken en communiceren.</br> Initiatiefnemers (lokale en bovenlokale besturen): De initiatiefnemers werken aan de hand van deze pagina de inhoud verder uit, waarna validatie volgt. </br> Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. </br>Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be .</br>Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) </br> Bedrijven en kennisinstellingen: Heb je als bedrijf een visie op de generieke business vereisten van dit thema, dan nodigen we je uit om samen deze oefening verder mee vorm te geven.</br>Ben je leverancier aan overheden, vragen we je specifieke oplossingen niet te vermelden maar de generieke business en IT architectuur in co-creatie mee uit te werken. </br> Burgers en burgergroeperingen: </br>Voel je je als burger aangesproken door dit onderwerp en je hebt een visie op de ontwikkeling van oplossingen van dit thema, of blijf je graag op de hoogte, laat het ons zeker weten. </br> </br> Aanpak (korte beschrijving) </br> Een volledige omschrijving van de stakeholder analyse kan je hier lezen.</br> </br> Inhoud </br> Hieronder kan je de elementen van de stakeholder analyse bekijken.enten van de stakeholder analyse bekijken.  +
• Inleiding Deze pagina bevat de eerste ve … Inleiding </br> Deze pagina bevat de eerste versie van stakeholder analyse. Het is een niet finale versie die we v0.1 noemen.</br>Dit kwam tot stand na het opstellen van een [Deliverable:_VLOCA-model VLOCA-model] en het verzamelen van input bij de initiatiefnemers, tijdens en na de kennismakingsworkshop.</br> </br> Situering van deze deliverable in het traject </br> Deze deliverable wordt uitgewerkt na de kennismakingsworkshop en het VLOCA-model V0.1 en wordt opgeleverd bij de opstartworkshop van het traject (workshop 1).</br>Het is in de v0.1-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is. </br>Dit document vormt een basis voor het verdere verloop van het traject. </br>In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. </br> </br> Doel en doelgroep </br> Het Doel van de stakeholder analyse is om alle belanghebbenden bij het traject in kaart te zetten, hun verwachtingen, noden, behoeften en uitdagingen in kaart te zetten.</br>De analyse werkt verder uit hoe we welke stakeholders moeten betrekken en communiceren.</br> Initiatiefnemers (lokale en bovenlokale besturen): De initiatiefnemers werken aan de hand van deze pagina de inhoud verder uit, waarna validatie volgt. </br> Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. </br>Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be .</br>Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) </br> Bedrijven en kennisinstellingen: Heb je als bedrijf een visie op de generieke business vereisten van dit thema, dan nodigen we je uit om samen deze oefening verder mee vorm te geven.</br>Ben je leverancier aan overheden, vragen we je specifieke oplossingen niet te vermelden maar de generieke business en IT architectuur in co-creatie mee uit te werken. </br> Burgers en burgergroeperingen: </br>Voel je je als burger aangesproken door dit onderwerp en je hebt een visie op de ontwikkeling van oplossingen van dit thema, of blijf je graag op de hoogte, laat het ons zeker weten. </br> </br> Aanpak (korte beschrijving) </br> Een volledige omschrijving van de stakeholder analyse kan je hier lezen.</br> </br> Inhoud </br> Hieronder kan je de elementen van de stakeholder analyse bekijken.</br> </br> </br></br> </br> CoT Slimme stadsdistributie – Hasselt </br> </br> </br> Start periode traject </br> </br> Stakeholderanalyse V0.1 </br> </br> </br> VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be </br> </br> </br> Beschrijving en aanpak: </br> </br> https://vloca-kennishub.vlaanderen.be/Deliverable:Stakeholderanalyse </br> </br> </br> </br> </br> </br> Toelichting van de velden </br> </br> </br> </br> </br> </br> Stakeholder </br> </br> Wie is de stakeholder?</br> </br> </br> Functie </br> </br> Wat is functie van de stakeholder bij dit traject?</br> </br> </br> Intern of extern </br> </br> Interne of externe stakeholder</br> </br> </br> Quadruple Helix </br> </br> Overheden, kenniscentra, burgerparticipaties of industrie</br> </br> </br> Stakeholder actie </br> </br> Volgens gezag en interesse: monitoren, informeren, tevreden houden of nauw betrekken</br> </br> </br> Specifieke noden, behoeften en barrières </br> </br> Welke specifieke noden, behoeften en barrières?</br> </br> </br> Communicatiekanalen </br> </br> Via welke kanalen wordt er gecommuniceerd over het traject of use cases?</br> </br> </br> </br> </br> </br> Identificatie van de stakeholders </br> </br> </br> </br> </br> </br> Stakeholder </br> </br> Functie </br> </br> Intern of extern </br> </br> Quadruple Helix </br> </br> Stakeholder actie </br> </br> </br> Stad Hasselt</br> </br> Initiatiefnemer (lead)</br> </br> Intern</br> </br> Overheden</br> </br> Nauw betrekken</br> </br> </br> Stad Leuven</br> </br> Initiatiefnemer (volgend)</br> </br> Intern</br> </br> Overheden</br> </br> Nauw betrekken</br> </br> </br> Stad Antwerpen</br> </br> Initiatiefnemer (volgend ter inspiratie)</br> </br> Intern</br> </br> Overheden</br> </br> Nauw betrekken</br> </br> </br> Stuurgroep Slimme stadsdistributie</br> </br> Stuurorgaan van initiatief</br> </br> Intern</br> </br> Overheden</br> </br> Tevreden houden</br> </br> </br> Inwoners binnenstad</br> </br> Als inwoners (overlast) en bestemmelingen</br> </br> Extern</br> </br> Burgerparticipatie</br> </br> Tevreden houden</br> </br> </br> Handelaars binnenstad</br> </br> Registreerders en bestemmelingen</br> </br> Extern</br> </br> Industrie</br> </br> Tevreden houden</br> </br> </br> Andere steden en gemeenten</br> </br> Deelnemers werkgroep</br> </br> Extern</br> </br> Overheden</br> </br> Informereren</br> </br> </br> Digitaal Vlaanderen (OSLO)</br> </br> Data standaarden</br> </br> Extern</br> </br> Overheden</br> </br> Informereren</br> </br> </br> Agentschap Binnenlands Bestuur</br> </br> Architectuur</br> </br> Extern</br> </br> Overheden</br> </br> Informereren</br> </br> </br> Politie</br> </br> Deelnemers werkgroep</br> </br> Extern</br> </br> Overheden</br> </br> Monitor</br> </br> </br> Departement Mobiliteit en Openbare Werken</br> </br> Deelnemers werkgroep</br> </br> Extern</br> </br> Overheden</br> </br> Monitor</br> </br> </br> Vlaamse Milieu Maatschappij</br> </br> Deelnemers werkgroep</br> </br> Extern</br> </br> Overheden</br> </br> Monitor</br> </br> </br> Universiteiten</br> </br> Deelnemers werkgroep</br> </br> Extern</br> </br> Kenniscentra</br> </br> Monitor</br> </br> </br> Leveringsdiensten en transportbedrijven</br> </br> Deelnemers werkgroep</br> </br> Extern</br> </br> Industrie</br> </br> Monitor</br> </br> </br> Onderzoeksintstellingen</br> </br> Deelnemers werkgroep</br> </br> Extern</br> </br> Kenniscentra</br> </br> Monitor</br> </br> </br> Mobiliteit en MaaS</br> </br> Deelnemers werkgroep</br> </br> Extern</br> </br> Industrie</br> </br> Monitor</br> </br> </br> Verenigen van ondernemingen</br> </br> Deelnemers werkgroep</br> </br> Extern</br> </br> Industrie</br> </br> Monitor Industrie Monitor  +
• Inleiding Het belang van data voor onze … Inleiding </br> Het belang van data voor onze huidige maatschappij is wereldwijd zichtbaar en het is algemeen aanvaard dat het in de toekomst steeds bepalender zal worden. Deze verhoogde nood aan data manifesteert zich ook in de gezondheidssector, over de gehele quadruple helix. Er is al veel data beschikbaar die zou toelaten om een efficiënt preventiebeleid te voeren, maar levensstijldata zit gefragmenteerd en wordt vandaag bijgevolg niet optimaal toegepast. De specifieke wettelijke, ethische en economische randvoorwaarden van de gezondheidssector vereisen ook een andere aanpak, een burgergedreven aanpak. Dit wordt Europees erkend en Vlaanderen speelt hierin op dit moment een voortrekkersrol met het We Are project op het gebied van - en met steun van de bevoegde overheden van - innovatie, gezondheid en digitalisatie. Deze specifieke aanpak moet het ook mogelijk maken om burgergegenereerde data over verschillende sectoren heen te ontsluiten met de burger aan het roer en de GDPR als hefboom (zie Figuur 1). Door een meer datagedreven preventiebeleid te voeren, kan de gezondheid van burgers verbeterd worden. </br> </br> Figuur 1: het We Are ecosysteem: data, beheerd door burgers, leidt tot het correct ontsluiten ervan voor innovatie en onderzoek door o.a. overheden. </br> Dit creëert ook mogelijkheden voor lokale overheden om hun beleid en hun diensten naar burgers toe te verbeteren. Een concrete use case waarmee lokale besturen levensstijldata voor hun preventiebeleid kunnen verzamelen is bijvoorbeeld het recent gelanceerde online preventieplatform BIBOPP , waarop burgers met hun eigen gezondheidsdata aan de slag kunnen. BIBOPP is een applicatie op het We Are data platform. Het omvat momenteel de digitale Gezondheidsgids van Domus Medica, een survey die het persoonlijk risico op chronische ziekten berekent. Voordelen voor de burger zijn dat BIBOPP gekoppeld is aan het elektronisch medisch dossier van de huisarts, dat het wetenschappelijk onderbouwd gepersonaliseerd advies levert én dit koppelt aan een lokaal aanbod van niet-klinische diensten zoals sportclubs, wandelroutes, workshops over gezond eten, …. Het gebruik van de applicatie creëert nieuwe informatie over de noden van de inwoners. Via We Are zullen data correct ontsloten worden en dit geeft steden en gemeenten nieuwe instrumenten om o.a. hun gezondheidsbeleid af te stemmen op maat van burgers en zorg- / hulpverleners. Met andere woorden: het draagt bij aan datagedreven populatiemanagement.nt.  +
• Inleiding In het kader het (VLAIO) City … Inleiding </br> In het kader het (VLAIO) City of Things 2021: Smart Innovation Factory (Stad Mechelen en Igemo) werd VLOCA ingeschakeld. Het doel van de Smart Innovation Factory (SIF) is om via een open data infrastructuur als innovatiefunnel te opereren voor innoverende initiatieven en smart city ideeën te stimuleren in de regio rivierenland.</br>De Stad Mechelen heeft hier geen sturende maar activerende rol: initiatieven worden gedragen door de quadrupel helix. </br>Meer info: https://www.smartinnovationfactory.be/ </br> De SIF is in deze fase op zoek naar innoverende initiatieven (tastbare use cases) met een maatschappelijk doel. Een van de uitdagingen die vandaag in verkenningsfase zit is het 'datapotentieel van laadpaalinfrastructuur'.</br> </br> Doel van de werkgroep </br> Het 'datapotentieel van laadpaalinfrastructuur' willen we verder uitdiepen en het landschap schetsen en mappen met de smart innovation factory als backbone. Het “what’s in it for me” vraagstuk stelt zich hier ook zodat oplossingen door de bredere gemeenschap als een aanwinst wordt gezien.</br>Concreet: we wensen een werkgroep te organiseren waar we de onderstaande gegevens willen capteren en samenbrengen om vervolgens in een analyse te kunnen vormgeven (verslag en schema).</br> </br> Deelnemers </br> </br></br> </br> Naam </br> </br> Hoedanigheid </br> </br> Organisatie </br> </br> </br> Dieter Cuypers</br> </br> Action-researcher</br> </br> VITO-Nexus</br> </br> </br> Fabian de la Meilleure</br> </br> Coördinator Proces & Methodiek</br> </br> VLOCA Agentschap voor Binnenlands Bestuur</br> </br> </br> Dimitri Hertoghts</br> </br> Programmamanager</br> </br> VSDS Digitaal Vlaanderen</br> </br> </br> Mieke Van Cauwenberghe</br> </br> Programmamanager Slimme Stad & Innovatie</br> </br> Stad Mechelen</br> </br> </br> Benjamin Vermeulen</br> </br> Data analist Slimme Stad</br> </br> Stad Mechelen</br> </br> </br> Jan Vanalphen</br> </br> Innovatiemanager Smart Innovation Factory</br> </br> Raccoons</br> </br> </br> Pieter</br> </br> Mobiliteitsdeskundige (data management)</br> </br> Igemo</br> </br> </br> Carlo Mol</br> </br> Project Manager Energy Technology</br> </br> VITO</br> </br> </br> Matthias Strobbe</br> </br> Senior Researcher & Business Developer</br> </br> IDLab (imec)</br> </br> </br> Ingrid Croket</br> </br> Projectlead Sustainable Urban Environment (SUE)</br> </br> imec</br> </br> </br> Thomas Roosen</br> </br> Mobiliteitsdeskundige</br> </br> Stad Mechelen</br> </br> </br> Simon Ruyters</br> </br> Beleidsmedewerker Groene Mobiliteit</br> </br> Departement Mobiliteit en Openbare Werken Vlaamse Overheid</br> </br> De sessie begint met een tour de table, wie is wie vatten we samen in de bovenstaande tabel met deelnemers.</br>Dieter licht toe wie de quadruple helix is. De quadruple helix bestaat uit vier groepen: onderzoek, bedrijven, overheid en burger. Een persoon kan deel uitmaken van één of meerdere groepen. Zo is iedereen aanwezig vandaag, zowel burger als lid van een andere groepering. Op deze manier capteren we tijdens deze exploratieve werkgroep eveneens de noden van de burgers.</br> Er werd gekozen om tijdens deze werkgroep niet actief de bedrijven te betrekken. Het doel van de werkgroep is hier om maximaal te denken naar het datapotentieel van de laadinfrastructuur en haar beperkingen, zonder naar een (bestaande) oplossing te werken. Industriële spelers betrekken we in een vervolgfase.</br> </br> Doel en rol van Smart Innovation Factory </br> </br> Notities van Fabian verder te verwerken </br> Concept van Smart Innovation Factory  het is een fabriek en hier maken we slimme innovatieve oplossingen.</br> Uitdaging: datagedreven oplossingen zijn duur en (overheids)middelen zijn schaars.</br> Aanpak: samen risico’s dragen door samen te investeren</br> Investering is te groot als er niet naar data wordt gekeken. Er is meerwaarde en innovatie als (real)-time data wordt gebruikt en wordt samengebracht.</br> SIF is IOT platform maar geen dataplatform.</br> Het SIF helpt bedrijven en organisaties bij het identificeren en benutten van kansen om maatschappelijke problemen op te lossen met (sensor)data - van de eerste afwegingen tot oplevering - in het Rivierenland en daarbuiten.</br> We formuleren vraagstukken die hoog op de agenda staan maar moeilijk op te lossen zijn</br> We verbinden diverse stakeholders binnen concrete oplossingsgebieden en we zoeken kennis uit andere sectoren in een innovatie-ecosysteem</br> We werken in een open innovatiefunnel om een</br> constante stroom van ideeën te voeden</br> Elke innovatie voedt het onderliggend data platform / data space.</br> Discussie: hoe betrekken we de burger? Wat is de toegevoegde waarde voor de burger?</br> Dimitri: als data het nieuwe goud is; hoe verander je die data dan om in geld? Niemand lijkt daar eenvoudig in te slagen.</br> Kan dit door te modelleren wat de impact van data delen is?</br> Wat als een use case te regionaal is? Bv verzekeringsmaatschappij gaat niet over gaan tot een project rivierenland als ze voor andere regio’s een andere aanpak hebben? We kunnen wel beginnen met een testgebied.</br> Verdienen op data is niet het doel, wel verdienen door impact van data.</br> Wat kan de rol zijn van studenten/ hoge scholen om bepaalde topics verder te onderzoeken?</br> Toelichting door Benjamin</br> Idee voor Jan: hoe burgers betrekken: kan bv via experimenten lange termijn bij studenten thuis?</br> Ombouwen van 7 straatkasten naar (x2 3fase 400V) laadpunten door de koperinfrastructuur te herbruiken (en lichtjes om te bouwen).</br> Toelichting access</br> Alle data kan on request worden opgevraagd (geen real time)</br> Aanvraag publieke laadpalen via e-loket Vlaanderen</br> Nieuwe concessie is met Engie (niet meer met Allego)</br> Google maps laat andere records zien volgens engelstalige of nederlandstalige zoekopdracht  in mobiele toepassingen specifiek voor laadpalen worden ze wel allemaal opgenomen.</br> Elke paal is verplicht ad hoc toe te laten  Europese richtlijn. Enige minpunt is dat je niet weet welke prijs je betaalt</br> Er is nog steeds weerstand om data te delen</br> Toelichting Fabian</br> Toelichting Dimitri</br> Kort uitschrijven van wat Dimitri heeft verteld</br> Carlo</br> Internationaal Energie Agentschap</br> Afgevaardigd voor België</br> Oefening stakeholders</br> CPO: charging point Operator</br> MSP: </br> Ecomomevent: verkoopt datasets van CPO’s (aan DMOW)</br> De overheid gaat op termijn niet anders kunnen dan data rechtstreeks binnen te halen van CPO’s</br> Elke CPO moet data kunnen aanleveren, hoe lang laden, hoeveel KWU geladen, …</br> Moet data gratis ontsloten worden? In toekomstige EU wetgeving: data (statisch en dynamisch) moet gratis gedeeld worden  geen sessiedate, wel: is er een actieve sessie, laadprijs, … NIET: hoe lang is de paal al aan het kleven</br> Overheid maakt geen onderscheid tussen publiek of semipubliek: enkel welke laadplaatsen staan open. Geen rekening houdend met ‘afgesloten parkings’ na bepaalde uren of wat staat op privaat domein.</br> Enkel publieke of ook private?</br> Er zijn veel uitdagingen bij het plaatsen van laadpalen: bv mag niet in appartementsgebouw (infra niet aangepast + maar 1 ‘gebruiker’ op 100 staanplaatsen (ze willen de kost niet dragen voor 1 wagen). Laadplaatsen op straat niet genoeg voor appartementsbewoners want zal worden gebruikt door straatbewoners waardoor ze nog steeds niet gaan kunnen laden. Wel laadplaatsen op parkings van de winkels maar die zitten vanaf een bepaald uur achter een gesloten poort.</br> Fluvius maakt onderdeel van elk ecosysteem</br> Publieke laadpunten moeten altijd aan volle capaciteit draaien (laden en weg, plaats voor volgende wagen). Private of (semi publieke zoals aan bv winkelcentrum) laadcapaciteit ifv de totale energie beschikbaarheid, lokaal opgewekte hernieuwbare energie, …</br> Niet alle data is beschikbaar: bv totale laadcapaciteit wagen, …</br> Data kan opgeroepen worden via CPO’s maar ook via autofabrikanten</br> Moderne apps laten toe ‘goedkoper’ te laden ifv vooraf ingegeven schema: ik wil tegen dat uur zoveel % batterij hebben  focus op laden wanneer stroom goedkoper is/ overschot aan energie is met mogelijkheid om te overrullen als de vertrektijd vroeger is of % batterij meer moet zijn, met meerkost</br> Ideale laadinfrastructuur nog niet gedefiniëerd door Mechelen maar volgt de VO voor oa:</br> • Laden voor inwoners</br> • Ontzorgen van mobiliteit door bv parkeren aan rand van de stad</br> • Laden bij hoppin points</br> • Rekening houdend met netjes parkeren, niet voor beschermde monumenten, stoepbreedte, esthetisch, dwarsparkeren ipv in strook parkeren, …</br> LEKP Strategie</br> Verdienmodel voor handelaars die hun laadplaatsen na de uren beschikbaar stellen</br> OCPI protocol voor facturatiedata uit te delen tussen CPO en MSP (geen OLSO standaard)  kan OSLO daarvoor een traject opstarten?</br> Handhaving is ook belangrijk: hoe kunnen we data daarvoor inzetten?</br> MOW zegt dat er een meerwaarde is om een OSLO standaard te hebben voor laadinfra maar dat het geen must is, zonder lukt het ook</br> Welke data is nodig: bezetting, …</br> Van wie krijgen we welke data?</br> Proximus deelt al data on request. Kunnen andere (alle) CPO’s de gevraagde data op regelmatige basis delen?</br> Colruyt heeft interesse in Energiemanagementsysteem (EMS). Ze gaan heel veel laadpalen installeren op verschillende sites. Hoe kunnen ze het potentieel uit die laadpalen halen? Databeheer zit bij DATS. Er is iemand die het beheer van de sites doet. En iemand die de laadinfra beheert.</br> Wat zijn de plannen van Telenet (omwille van drukte in woonbuurten). Willen/ kunnen ze hun laadinfra delen?</br> Eerst case goed uitwerken en vervolgens 2e workshop rond die use case met de juiste mensen samen aan tafel?</br> Kan gebruikersprofiel worden opgesteld volgens laadpas en laadpasgebruik?</br> Er waren ook incentives vanuit DMOW (of VO) voor bedrijven om laadpalen publiek open te stellen. Er kan worden gekeken of er nog dergelijke subsidies gegeven worden in de toekomst.</br> 1000 euro per CPE (ong 20% van investeringskosten subsidiëren).</br> Kan er een premiesysteem komen?</br> Algemene bevindingen van benjamin, verder te verwerken </br> CPO's zitten op een hele rijke bron van data</br> Europa wil CPOs verplichten om data vrij te stellen van publieke laadinfrastructuur</br> Vlaanderen gaat gebruikers data van publieke laadpalen opeisen</br> Semi-publieke laadpalen worden gezien als publieke laadpalen maar geen verplichting om data vrij te stellen. Moet dit ook gedaan worden?</br> Vanaf dat een paal "gepubliceerd" is zal dit in een gedeelde dataset zitten van CPO (private palen zijn doorgaans niet gepubliceerd semi-publieke en publieke palen wel) Soms komt het voor dat een private paal gepubliceerd wordt.</br> Bij nieuwbouw, van grote gebouwen met parkeervoorziening, komen er verplichtingen om laadinfra te voorzien op parkeerruimte.</br> Verenigingen van mede-eigenaars van vastgoed moet</br> voordelen zien van laadinfra uit te baten op semi-publieke ruimte. Hoe deze business-case uitwerken?</br> Ecomovement aggregeerd heel veel data van CPO's om kwaliteitsanalyse en accuratheid van data te verbeteren om vervolgens door te verkopen aan andere bedrijven of organisiaties. Momenteel wordt deze dataset bekeken om binnen te trekken op Vlaamse servers van MOW?</br> Lokale overheden hangen vast aan Vlaamse strategie en kunnen dus niet altijd onderhandelen met private bedrijven.</br> CPO & (e)-MSP werken doorgaans goed samen om hun diensten te verbeteren volgens OCPI protocol maar willen liever niet delen met overheden met schrik omdat de data lekt en er concurrentieel voordeel kan ontstaan of wetgevingen aangepast worden.</br> </br>Uitbouwen van een use-case is beter af te bakenen in het ecosysteem van (semi)-publieke / private laadpalen. Oefening: </br> </br></br> </br> Onderzoek </br> </br> Bedrijven </br> </br> Overheid </br> </br> Burger </br> </br> </br> SMART INNOVATION FACTORY </br> </br> </br> Netbeheerders DSO/ TSO Fluvius</br> </br> Energielieveranciers Eigenaars elektische voertuigen Mobiliteitsbedrijf (bus, taxi, …) Leasingmaatschappijen Autofabrikanten Databrokers Data aggregatoren MaaS providers MSPO / CPO Park management (industrieterrein) Aanbieders deelmobiliteit Softwareleveranciers</br> </br> Federale Overheid Europese Unie Fiscus Vlaamse overheid (en agentschappen)</br> </br> Eigenaars privé laadpalen VME Eigenaars elektrische voertuigen Bewoners  +
• Inleiding Luchtvervuiling is volgens de … Inleiding </br> Luchtvervuiling is volgens de Wereldgezondheidsorganisatie (WHO) het grootste milieugezondheidsrisico in Europa. Een groot deel van de bevolking wordt er regelmatig aan blootgesteld. Europa kent al verschillende initiatieven om de luchtkwaliteit te meten, maar die initiatieven hebben vaak een verschillende invalshoek of methodologie.</br> Voor beleidsmakers is het net essentieel om de verschillende informatie op elkaar af te stemmen, zodat ze een wetenschappelijk onderbouwd lucht- en mobiliteitsbeleid kunnen voeren. Binnen het Life CityTRAQ-project werken we daarom met 6 partners samen aan een betere lokale luchtkwaliteit. Dankzij informatie uit verkeerstellingen en luchtkwaliteitsmetingen detecteren en meten we luchtvervuiling en simuleren we de impact van eventuele maatregelen op het mobiliteitsnetwerk.</br> </br> Doel van het project </br> Het CityTRAQ-project geeft lokale overheden meer inzicht in de metingen die nodig zijn om luchtkwaliteit te beoordelen. De screenings- en scenariotool helpen lokalen besturen om maatregelen uit te werken ter verbetering van de lokale luchtkwaliteit. Zo creëren ze een beter leefmilieu voor de inwoners. De lokale overheden worden ook aangemoedigd om hun beleidskeuzes vorm te geven in een luchtbeleidsplan.</br> </br> Partners </br> LIFE CityTRAQ wordt uitgevoerd in opdracht van de Europese Commissie binnen het LIFE-programma onder leiding van de Vlaamse Milieumaatschappij.</br> </br> Stad Antwerpen zal in het CityTRAQ project werken rond logistiek en zwaar verkeer. Samen met de VMM zet de stad verkeerstellingen van vrachtverkeer en luchtkwaliteitsmetingen in lokale hotspots en schoolomgevingen op. </br> Stad Brugge zet in op de verdere uitbouw van een duurzaam meetnet in de hele stad. </br> Stad Gent meet de impact op de luchtkwaliteit in een schoolstraat en evalueert de circulatieplannen. </br> Zagreb volgt het voorbeeld van de Vlaamse steden en zal luchtkwaliteitsprojecten opstarten </br> Situering van deze deliverable in het traject </br> Deze eerste versie is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt, we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is.</br> </br> Richtlijnen voor het kopen van sensoren </br> a. Sjabloon voor aanbesteding: bijlage Bestekvoorwaarden_multiparametersensoren en invulfiche technische specificaties </br> b. Testprocedure: bijlage Testprocedure sensoren </br> c. Code voor testen </br> Roadmap voor de implementatie van een sensornetwerk </br> a. Workshops </br> b. Experimenteel ontwerp: bijlage Onderzoeksvragen </br> c. QA/QC-procedure </br> Roadmap voor beleidsbeoordeling </br> a. Sjabloon voor aanbesteding voor een luchtkwaliteitsplan </br> b. Technische beschrijving en praktische voorbeelden </br> c. Roadmap voor implementatie </br> d. Handleiding voor het gebruik van modelberekeningen </br> Beoordelingstool </br> a. Functionele analyse (wat zijn de belangrijkste functionaliteiten?) </br> b. Gebruikersgericht ontwerp </br> c. Architectuur </br> d. Relevante bronnen van milieuvervuiling </br> e. Businesscase (kosten en baten) </br> Scenario-tool </br> a. Functionele analyse (wat zijn de belangrijkste functionaliteiten?): bijlage functionele analyse VMM </br> b. Gebruikersgericht ontwerp </br> c. Architectuur </br> d. Open-source modellen </br> e. Businesscase (kosten en baten) </br> Aanpak gedragsonderzoek </br> a. Script gedragsverandering: bijlage gedragsonderzoek Gent </br> b. Sjabloon voor aanbesteding van gedragsonderzoek: bijlage gedragsonderzoek Gent </br> c. Aanbevelingen en praktische voorbeelden </br> Opvolging van sensormetingen </br> a. Beschrijving van dataportaal </br> b. Architectuur van dataportaal </br> c. Code voor dataportaalataportaal c. Code voor dataportaal  +
• Inleiding Sharepair is een Interreg proj … Inleiding </br> Sharepair is een Interreg project waarin vanuit Vlaanderen verscheidene organisaties partneren, geleid door de stad Leuven.</br> De stad Roeselare, de KULeuven, VITO, Maakbaar Leuven, Repair & Share, Statik en Test aankoop zijn partners vanuit Vlaanderen mee actief in het project. </br> Het doel is de duurzame ontwikkeling en werking van repair cafés te ondersteunen.</br> </br> Links </br> https://www.nweurope.eu/projects/project-search/sharepair-digital-support-infrastructure-for-citizens-in-the-repair-economy/ </br> Circulaire economie: Repair cafésirculaire economie: Repair cafés  +
• Inspire heeft verschillende data standaarden gedefinieerd voor verschillende thema's. Een voorbeeld voor hydrography vind je hier: https://inspire.ec.europa.eu/id/document/tg/hy  +
• International Data Spaces Association In … International Data Spaces Association </br> International Data Spaces </br> Het uitwisselen van gegevens is de sleutel voor veel Organisaties . Binnen het domein van slimme steden worden gegevens gegenereerd door apparaten, opgeslagen in een database en gebruikt voor evaluatie door anderen. Bij alle drie de stappen zijn verschillende Organisaties betrokken. Ze willen weten, en bepalen hoe hun gegevens worden gebruikt of waar ze vandaan komen.</br> </br> </br> De International Data Spaces Association pakt dit probleem aan: het heeft een referentiearchitectuur en een formele standaard gedefinieerd die moet worden gebruikt voor het maken en beheren van “virtuele gegevensruimten”(virtual data spaces). De IDS-architectuur is gebaseerd op algemeen aanvaarde modellen voor gegevensbeheer die veilige uitwisseling en eenvoudige koppeling van gegevens binnen ecosystemen mogelijk maken.</br> De IDS-architectuur zorgt voor digitale soevereiniteit voor gegevenseigenaren die gegevens beschikbaar stellen voor de uitwisseling of het delen met met anderen. Het vormt daarmee de basis voor het ontwikkelen en aanbieden van slimme diensten en voor het opzetten van innovatieve bedrijfsprocessen. Het is gericht op het creëren van een veilige en vertrouwde ruimte waarin bedrijven hun gegevens soeverein kunnen beheren.</br> </br> IDSA Organisatie </br> IDSA bestaat uit een groot aantal Organisaties uit verschillende domeinen zoals automotive, Telecom , retail, kennisinstellingen, software consultancy Organisaties en anderen. Ook FIWARE is lid en vertegenwoordigd in de IDSA Raad van bestuur. Verder is ook IMEC lid van IDSA .</br>Een volledige lijst is hier te vinden [1] </br> </br> Certificatie </br> Naast software is het ook belangrijk ervoor te zorgen dat Organisaties die data delen, elkaar vertrouwen met betrekking tot data soevereiniteit . Om dit te garanderen kan IDSA ook Organisaties en software certificeren. Daartoe heeft het de volgende certificaten gecreëerd:</br> IDS READY Organisation. Certificering wordt afgehandeld door PWC of TUV SUD;</br>IDS Ready Component. Certificering wordt afgehandeld door Fraunhofer. </br> [2] </br> </br> IDS Architectuur </br> De IDS-architectuur is gebaseerd op de volgende drie principes</br> </br> Onbeperkte interoperabiliteit: IDS wil de standaard zijn voor de gegevensstroom tussen allerlei gegevenseindpunten; </br> Vertrouwen tussen verschillende beveiligingsdomeinen: uitgebreide beveiligingsfuncties bieden die een maximum aan vertrouwen bieden; </br> governance voor data-economie: gebruikscontrole en handhaving voor datastromen </br> [[File: IDSA trustworthy architecture.jpg|thumb|left|800px]]</br> </br> IDS-connector </br> De belangrijkste IDS-component is de IDS-connector. Het is de softwarecomponent die verantwoordelijk is om gegevensuitgevers en gegevensconsumenten in staat te stellen gegevens uit te wisselen, te delen en te verwerken. Dit, rekening houdend met de soevereiniteit van de gegevenseigenaren.</br> De architectuurspecificatie van IDS is hier te vinden: [3] </br> </br> Relatie tussen IDSA en Gaia-X </br> Hiervoor werd een heel interessante position paper gepubliceerd die een mapping weergeeft van de IDSA bouwblokken op de Gaia-X technische architectuur : https://internationaldataspaces.org/wp-content/uploads/IDSA-Position-Paper-GAIA-X-and-IDS.pdf </br>Dit ziet er als volgt uit :olgt uit :  +
• Introductie Begin 2021 erkent het Smart … Introductie </br> Begin 2021 erkent het Smart Flanders-programma van het Agentschap Binnenlands Bestuur (ABB) de noodzaak om mobiliteitsstromen van alle transportmodi overzichtelijk in kaart te brengen om (de mobiliteitsexpert van) de steden te ondersteunen bij de uitwerking van hun datagedreven mobiliteitsbeleid. Het vooropgezette plan was om een totaalbeeld van de mobiliteitsstromen te ontwikkelen door de al bestaande databronnen rond mobiliteit te integreren met eenvoudige wiskundige fusies. Samen met imec werd er binnen het kader van het CityFlows-traject gezocht naar twee pilootsteden die het datafusiemodel wilden gebruiken en hieraan een use case konden koppelen. </br> Als pilootsteden werden Stad Mechelen en Gent geselecteerd. In Mechelen moest de invoering van een schoolstraat getoetst worden aan de hand van het model. Er moest beoordeeld worden of en hoe het mobiliteitsgedrag was veranderd nadat de schoolstraat ingevoerd was. In Gent moest een wijkmobiliteitsplan (Zwijnaarde) geëvalueerd worden als onderdeel van het project. In beide pilootsteden moest de evaluatie uitgevoerd worden op basis van een combinatie van databronnen, zodat er niet enkel uitspraken gedaan konden worden op plaatsen waar gemeten werd, maar ook daar waar niet werd gemeten </br> Het model dat hiervoor ontwikkeld werd, bouwt verder op een proof of concept (PoC) dat de universiteit van Antwerpen ontwikkelde in de Sint-Andrieswijk die de naam Antwerp Smart Zone kreeg. Hier werden verschillende technologische toepassingen getest in een echte leefomgeving. Een van die toepassingen was een datafusiemodel dat verschillende databronnen rond mobiliteit combineerde om het aantal deelnemers aan het verkeer te bepalen per modaliteit in elke straat en op elk moment van de dag. Het model dat daarvoor gebouwd was, combineerde databronnen zonder echte regels (bijvoorbeeld de regel dat mensen ’s ochtends hun woongebied verlaten en ’s avonds weer terugkomen), maar op basis van een wiskundige verdeling. Het oorspronkelijke model in de PoC had slechts een beperkt aantal modaliteiten (twee: wel en niet-gemotoriseerd) werkte slechts op een kleine geografische oppervlakte met beperkte databronnen. </br> De opdracht van imec was om het ontwikkelde model van de PoC op te schalen naar meer modaliteiten en meer databronnen. Er moest ook een mechanisme ontwikkeld worden dat de accuraatheid van de output van het model controleerde. imec voegde meer databronnen toe (Telraam, fietstellussen van Signco, tijdelijke tellingen en ANPR-data) en trachtte het model bruikbaar te maken op stadsniveau en voor alle modaliteiten (voetgangers, fietsers en gemotoriseerde voertuigen). </br> Het mechanisme dat de accuraatheid van de output van het model controleerde (validatiescore) werd ontwikkeld aan de hand van Straatvinkendata (ground truth). Bij het samenvoegen van de eerste databronnen bleek de validatiescore echter laag. Onze hypothese was dat de validatiescore zou toenemen naarmate er meer databronnen toegevoegd zouden worden. Die hypothese werd echter niet bevestigd. Om de kwaliteit van het model te optimaliseren werd ook de verdeling van de modaliteiten per straat geoptimaliseerd, maar ook hierna bleef een positief effect op de validatiescore uit. </br> We kunnen daaruit concluderen dat deze versie van het opgeschaalde model geen betrouwbaar middel is om de use cases in de pilootsteden op te lossen. Delen van het model zijn mogelijk wel herbruikbaar, zodat de data-uniformisatie en - ingestie. Die zullen dan ook samen met de andere componenten van het model beschikbaar worden gemaakt. Onze belangrijkste aanbeveling is dat een toekomstig model meer rekening zal moeten houden met het dynamische karakter van een stad. Dat wil zeggen: de wegingscoëfficiënten die wij hebben toegepast, zouden dynamischer moeten zijn en bedacht moeten zijn op het menselijke verplaatsingsgedrag. Artificiële intelligentie kan daarvoor mogelijk een oplossing zijn. </br> Nadat de lage betrouwbaarheid van het model aan het licht was gekomen, zijn de use cases met de pilootsteden herbekeken om te onderzoeken hoe die wel opgelost konden worden. Na nauw overleg met de twee centrumsteden en de stuurgroep van CityFlows heeft imec een analysetoolbox ontwikkeld die de mobiliteitsexpert in staat stelt met enkele muisklikken een bepaalde beleidsuitdaging op vlak van mobiliteit te evalueren. Op die manier creëerden we meer zekerheid dat de steden echt vooruitgeholpen waren met hun problematiek. </br> De opdeling van deze pagina bestaat er als volgt in: in de eerste sectie worden de gebruikte databronnen geëvalueerd waarna er opvergegaan wordt op een beschrijving van het model in deel 2. In deel 3 benoemen we de uitdagingen en de mogelijke oplossingen. In dit deel wordt ook de toolbox toegelicht. </br> </br> Input van het model </br> Zoals aangegeven in de inleiding worden de databronnen die gebruikt zijn voor het CityFlows-project met de twee pilootsteden, als eerste nader bekeken. In iedere sectie komt een andere databron aan bod. Aan de hand van een SWOTanalyse wordt elke databron afzonderlijk geanalyseerd en op basis van die analyse worden er enkele aanbevelingen voor de sensoren en databronnen gedaan. </br> </br> Telecomdata </br> Telecomdata is data over het aantal smartphones dat aanwezig is in een specifieke zone (vierkante cellen van 500 m x 500 m, of in het geval van Mechelen één grote onregelmatige cel). De frequentie waarmee geüpdatet wordt wie aanwezig is in een cel, verschilt per data-aanbieder. Voor Mechelen was de updatefrequentie vijftien minuten, terwijl dat voor Gent een keer per uur was. Per updatefrequentie wordt bijgehouden hoe veel smartphones zich in een specifieke cel bevinden (snapshots). De locatie van een smartphone wordt, afhankelijk van wat eerst komt, elk kwartier of aan de hand van de laatste ping (de laatste connectie met het netwerk) bepaald. Het is hierbij belangrijk om te vermelden dat er in elke stad met één provider gewerkt wordt en dat die enkel data heeft over zijn eigen gebruikers. Om een telling te kunnen leveren voor alle toestellen zal de provider extrapoleren op zijn geschatte marktaandeel. </br> ➢ Sterktes </br> • Deze databron geeft een beeld van het totaal aantal mensen dat aanwezig is. Dat beeld omvat dus alle modaliteiten, maar ook de achtergrond (mensen die niet deelnemen aan het verkeer, maar die hun smartphone bijvoorbeeld in huis gebruiken). </br> • De data is al veel gebruikt in een andere context (Toerisme). </br> • Goede geografische dekking: geeft niet enkel een lokaal beeld van een plek waar een specifieke sensor staat, maar geeft een beeld van een grotere zone. </br> ➢ Zwaktes </br> • Er is geen opsplitsing per modaliteit mogelijk, omdat er geen beeld is van de snelheid/modaliteit per persoon. </br> • Ook mensen die niet deelnemen aan mobiliteit worden meegenomen in de telling. </br> • Door anonimisatie kan er geen link gelegd worden tussen verschillende snapshots. </br> • Weinig tot geen inkijk in hoe de output (snapshots) tot stand komen. </br> • Het is onduidelijk hoe accuraat de extrapolatie op basis van het marktaandeel is. </br> • Het update van de locatie van een smartphone gebeurt niet realtime (in functie van het gebruik van de smartphone). Dat zorgt voor vertraging en kan betekenen dat de persoon in kwestie inmiddels al uit de zone is, en dat er dus onjuist geteld wordt. Bovendien is er geen inschatting van hoe groot deze “fout” is. </br> ➢ Opportuniteiten </br> • Dankzij CityFlows werden gebreken in datakwaliteit aangekaart en konden de steden die gebreken terugkoppelen aan hun leverancier. De ervaring van CityFlows geeft de steden de kans om kwaliteitsvollere data in de toekomst in een contract te laten beschrijven. </br> • Hogere updatefrequenties van smartphonelocaties (bij gebruik van meer apps) zorgt ervoor dat deze databron in de toekomst potentieel heeft. </br> • De verkoop van smartphones groeit nog steeds. Hoe meer mensen een smartphone bezitten, hoe meer mensen gedetecteerd kunnen worden. </br> ➢ Bedreigingen </br> • Door de GDPR-wetgeving kan deze databron mogelijk extra beperkingen/anonimisering opgelegd krijgen. </br> • De verantwoordelijkheid voor het oplossen van bepaalde beperkingen het potentieel gebruik van deze data ligt bij de telecomproviders. Zij zouden de snelheid van verplaatsing of modaliteit kunnen meegeven. De vraag is of deze (vaak grote) telecomproviders het potentieel hiervan inzien en de technische uitdagingen kunnen en willen aangaan. </br> ➢ Conclusies </br> Deze databron had veel potentieel, maar na het eerste gebruik gaf de databron meer problemen dan vooraf verwacht. De achtergrond (zowel van personen die niet deelnemen aan het verkeer als van smartphones die nog niet geüpdatet zijn op vlak van locatie) is groot en variabel. Bovendien is het formaat (snapshots) een beperking, want veranderingen tussen snapshots kunnen moeilijk gedetecteerd worden en de modaliteit kan daaruit ook moeilijk worden afgeleid. </br> Voor beide pilootsteden werd deze data aan imec overhandigd door middel van een datadump. Beide steden hadden echter wel een andere operator. Bovendien verschilde de updatefrequentie per stad (15 minuten voor Mechelen en 60 minuten voor Gent). </br> De interessante opportuniteiten die hieruit afgeleid kunnen worden, zijn kansen die grote telecomoperatoren moeten aannemen om hun data te verbeteren en in lijn te brengen met de behoeften van de steden. Onze aanbeveling is dan ook dat steden de kwaliteit van de data meenemen in een aanbestedingsprocedure bij een volgende aankoop van deze data. Op basis van een eerste analyse stelde Gent bijvoorbeeld al vast dat de eerste datalevering niet klopte. Na overleg met de provider werd dat echter bijgestuurd. De ervaring die is opgedaan binnen CityFlows kan dan ook helpen om het potentieel van deze databron te verbeteren voordat er wordt over gegaan tot de aankoop van dergelijke data. </br> Er kan bijvoorbeeld gevraagd worden om niet enkel aantallen per snapshot te leveren, maar ook om aantallen per modaliteit en per snapshot te leveren. Het is echter nog de vraag of dat technisch binnen de mogelijkheden van de telecomoperatoren valt. Er kan ook gevraagd worden naar meer inzicht in de zogenaamde “black box” die nu al achter de data zit. De steden krijgen momenteel namelijk enkel ruwe aantallen per cel en niet meer. Meer inzicht in de manier waarop de data verzameld worden en de manier waarop die geïnterpreteerd moeten worden, zal de kwaliteit en het gebruik ervan alleen maar ten goede komen. </br> </br> Telraam </br> Telraam is een Citizen Science-initiatief van het beleidsondersteunend onderzoeksbureau TML (Transport & Mobiliteit Leuven). Dat initiatief voorziet camera’s voor burgers die daarvoor betalen (127 euro op 02/03/2023) om een beeld te krijgen van de mobiliteit in hun straat. De door de burger zelf geïnstalleerde camera bevat beeldherkenningssoftware die detecteert hoeveel auto’s, fietsers en/of voetgangers er per uur passeren. TML ontwikkelde een architectuur, hardware en software voor deze sensor binnen het Europees project WeCount. Er werd een pilootstudie uitgevoerd in Kessel-Lo (Leuven) waarbij er veel Telraamsensoren gratis ter beschikking werden gesteld aan enthousiaste burgers. </br> ➢ Sterktes </br> • Een lokaal beeld van verkeersvolumes (op secundaire en tertiaire wegen) </br> • Multimodaal </br> • Laagdrempelig en goedkoop vanuit het oogpunt van de steden, want de kost wordt gedragen door de burgers (met uitzondering van projecten waarvoor de steden de sensors kopen). </br> • Langdurige meting en dus een grote tijdspanne, wat deze databron geschikt maakt voor zowel use cases met kleine tijdsvensters als voor use cases met grote tijdsvensters. </br> ➢ Zwaktes </br> • Beeldherkenningssoftware werkt niet altijd zonder problemen (dubbele telling fietsers/voetgangers). </br> • Bij schemering of donkere omstandigheden en ’s nachts werkt de camera niet. </br> • Het blijft een burgerinitiatief en is dus afhankelijk van de bereidheid van burgers om de camera’s te betalen, te installeren en te onderhouden (verbinding/stroomverbruik). </br> • De invloed die de stand van de camera (hoek tot de straat, parkeren van vrachtwagens voor de camera, invallende zon, etc.) uitoefent op de metingen is vaak onbekend. </br> • De camera staat op een vast punt en meet dus enkel op dat punt en niet over een grote geografische zone </br> ➢ Opportuniteiten </br> • Dankzij verschillende projecten kunnen deze camera’s beschikbaar worden gesteld voor burgers zodat zij een constante meting kunnen opstarten en zo andere projecten kunnen ondersteunen (zoals het WeCount-project waarnaar hierboven verwezen is). </br> • Telraam werkt aan een verbetering van zijn sensor met een Telraam 2.0-sensor die geüpdatete beeldherkenningssoftware bevat en minder gevoelig is voor tijdelijke onderbrekingen van elektriciteit en/of internet. </br> • Telraam wint meer en meer aan bekendheid binnen de maatschappij, wat de bereidheid tot aankoop en installatie vergroot </br> ➢ Bedreigingen </br> • Sterk afhankelijk van de bereidwilligheid van de bewoners om te investeren in de camera en die te blijven monitoren </br> • De verschillen in beschikbare Telraamsensoren per wijk/stad zijn zeer divers en bepalen in veel gevallen de functionaliteit van deze sensor voor een specifieke use case. </br> ➢ Conclusies </br> De multimodale telling en lokale beschikbaarheid van deze sensor is een meerwaarde ten opzichte van veel andere sensoren. Het belangrijkste nadeel blijft echter de lokale context die vaak ontbreek. Dat zorgt er ook voor dat er geen algemene oplossing toegepast kan worden op alle Telraamdata. Er moet namelijk steeds lokaal nagegaan worden wat de mogelijke afwijkingen kunnen zijn, en dat zelfs voor elk tijdstip. Dat nadeel heeft een grote invloed op de nauwkeurigheid van deze sensor. Deze databron kan mogelijk verbeterd worden door bij de installatie een validatie per sensor uit te voeren. Dat kan bijvoorbeeld een kwaliteitscontrole zijn die patronen detecteren op lange en korte termijn om op die manier afwijkingen te bepalen en wiskundig te kunnen opheffen. </br> De Telraamdata is redelijk eenvoudig op te vragen via een publieke API die je voor elke sensor/straatsegment afzonderlijk dient op te vragen. Als je de data hebt opgevraagd, ontvang je de verwerkte data met het aantal passages per uur per modaliteit terug. Deze dataverwerking heeft reeds plaatsgevonden op de camera zelf om privacyproblemen uit de weg te gaan. </br> Als verbetering stellen we voor om de beeldherkenningssoftware te verbeteren en het toestel bestendiger te maken tegen tijdelijk netwerk- en stroomverlies. We zien daarvoor wel mogelijkheden in de Telraam 2.0-versie. Die moet echter wel nog uitvoerig getest worden om te kunnen bepalen of dat ook daadwerkelijk een positieve invloed heeft op de nauwkeurigheid van de resultaten. De vraag daarbij blijft ook of dat technisch gezien toch niet op beperkingen gaat botsen (slechte zichtbaarheid, ...). Ook hier zou gedacht kunnen worden aan een validatieproces per sensor. Bovendien moet er rekening gehouden worden met een overgangsperiode voordat de bestaande Telraamsensoren vervangen zijn door nieuwe exemplaren. Het gevaar dreigt daarbij dat de oude sensors evenwaardig behandeld worden als de (betere) nieuwe generatie. Daar komt bij dat het type sensor ook duidelijk weergegeven moet worden in de metadata. </br> </br> ANPR </br> ANPR is een afkorting die staat voor “automatic number plate recognition” (automatische nummerplaatherkenning). Sinds de terroristische aanslagen in België is deze sensor wijdverspreid in Vlaanderen. ANPR werkt via een camera die een foto maakt van de voorkant van elk voertuig en zo de passage van dat voertuig op die plaats registreert. </br> ANPR data werd voor de use case in Mechelen meegenomen in het CityFlows-project. Het ontsluiten van de ANPR data voor analyse doeleinden is tot op vandaag geen eenvoudige klus. Het gebruik van deze camera’s wordt geregeld door de Wet op het politieambt (WPA) en de Camerawet (21/3/2007). Het Controleorgaan op de politionele informatie (COC) kijkt toe op het naleven van deze wetgeving. Daarnaast is ook de Algemene Verordering Gegevenbescherming (AVG) van toepassing die regels op verwerking van persoonsgegevens beschrijft. </br> In de casus van Mechelen onderzoekt het projectteam de impact van het afsluiten van een schoolstraat. Meer specifiek wordt er onderzocht of er met de beschikbare mobiliteitsdata iets kan verteld worden over de verandering in de verkeersveiligheid, leefbaarheid en doorstroming op de straten rond de schoolstraat. Dit draagt bij tot handhaving van de openbare orde en het verzekeren van de veiligheid. Dit vormt de grond waarop de motivatie tot gebruik van deze ANPRdata stoelt. Stad Mechelen diende een aanvraag bij het Controleorgaan op de politionele informatie COC in om de ANPR-gegevens op te vragen. De aanvraag bestond uit twee delen. </br> • In het eerste deel vraagt Stad Mechelen (aanvrager en primaire verwerkingsverantwoordelijke) aan de Politiezone Mechelen-Willebroek om geanonimiseerde gegevens van de ANPR-camera registraties te verkrijgen. Dit aspect valt onder de Wet op het Politieambt (WPA), meer bepaald artikel 44/11/7. </br> • In het tweede deel geeft Stad Mechelen de opdracht aan imec (verwerker) om de gegevensstroom van geanonimiseerde ANPR-gegevens te verwerken. Dit aspect valt onder de AVG. Daarnaast beroept Stad Mechelen zich ook op Artikel 2 uit het gemeentedecreet “De gemeenten beogen om op het lokale niveau bij te dragen tot het welzijn van de burgers en tot de duurzame ontwikkeling van het gemeentelijk gebied”. Dit is ook overeenkomstig met artikel 41 uit de Grondwet dat aangeeft dat ze bevoegd zijn voor “de aangelegenheden van gemeentelijk belang voor de verwezenlijking waarvan ze alle initiatieven kunnen nemen.” </br> Na goedkeuring van het COC werden de uiteindelijke gegevens uitgewisseld. In eerste instantie betreft het gegevens over plaats en tijdstip van de registratie door de camera die door de Politiezone Mechelen-Willebroek aan de stad Mechelen overgemaakt worden. Er wordt geen verrijking gemaakt met de databank van Dienst Inschrijving Voertuigen (DIV) en ook geen gepseudonimiseerde gegevens om voertuigen over meerdere camera’s te volgen. In een tweede instantie worden deze gegevens overgedragen aan imec (verwerker) die als eerste actie een aggregatie op hoger niveau doorvoert in lijn met bepalingen in het AVG (minimum 5 voertuigen per record). Door de finale aggregatie van de verschillende mobiliteitsdata is resulterende datastroom niet langer onderhevig aan de WPA en/of AVG. </br> In dit proces is een nauwe samenwerking tussen de verschillende actoren belangrijk. In de casus van stad Mechelen was de mobilitieitsdienst de initiatiefnemer om de ANPR data te gebruiken. Samen met de verwerker imec werd er ingeschat of deze databron een toegevoegde waarde kon brengen in de analyse. De Data Protection Officer (DPO) van de stad evalueerde mee of de juiste evaluaties en stappen inzake gegevensverwerking gevolgd werden. </br> ➢ Sterktes </br> • Zeer nauwkeurige sensor die zo goed als al het gemotoriseerde verkeer meet. </br> • Link met voertuigklasse/motortype is in principe mogelijk (hoewel dat niet in de scope van CityFlows zat), dit houdt een koppeling in met DIV databank. </br> • Reeds op grote schaal uitgerold en beschikbaar in Vlaanderen. </br> ➢ Zwaktes </br> • Wetgeving bemoeilijkt wijdverspreid gebruik van deze sensor voor analyse doeleinden. In deze casus diende een duidelijke link met de handhaving van openbare orde en verzekeren van de veiligheid aangetoond te worden. </br> • Niet multimodaal: enkel gemotoriseerd verkeer wordt gedetecteerd. Nieuwe generatie camera's zijn in staat zijn meerdere modaliteiten te identificeren. </br> • Camera staat op één vast punt en meet dus ook enkel op dat vaste punt en geeft geen data over een grote geografische zone. </br> ➢ Opportuniteiten </br> • Indien het wetgevend kader zou gevormd worden (dat ANPR-data beschikbaar maakt voor analyse doeleinden) dan dienen ook de achterliggende diensten, die instaan voor verwerking van de ruwe data, ondersteund te worden. De huidige technologie staat vandaag ver genoeg om deze verwerking procedures in hoge mate te automatiseren. Dit zou een volgende stap kunnen zijn in de digitale transformatie van de publieke diensten met het oog op betere dienstverlening. </br> • In financieel moeilijke tijden is het voor steden en gemeenten belangrijk om bestaande infrastructuur optimaal te benutten. Die politieke wil zorgt ervoor dat er nu een uitgelezen kans is om het gebruik van deze data in mobiliteitstoepassingen in een wettelijk kader te plaatsen en al doende de beschikbaarheid van deze data te verbeteren. </br> • Deze sensor staat op veel plaatsen en als deze data beschikbaar wordt gesteld, is die daardoor geschikt voor verschillende use cases. </br> ➢ Bedreigingen </br> • Het aanslepende debat rond het gebruik van ANPR data voor analyse doeleinden (dat aanpassingen aan huidige wetgevend kader vraagt) zorgt ervoor dat het geloof dat deze data beschikbaar gesteld kan worden, aan het afbrokkelen is </br> ➢ Conclusies </br> De sterkte van deze sensor is vooral de grote nauwkeurigheid in het meten van al het gemotoriseerde verkeer. Die sterkte is echter ook meteen het grootste nadeel: er is namelijk geen meting van niet-gemotoriseerde transportmodi. Bovendien zorgt de huidige wetgeving ervoor dat deze databron op het moment nog niet eenvoudig benut kan worden. Wij adviseren dan ook aan om die wetgeving zo spoedig mogelijk te herzien zodat er een duidelijk afgebakend toepassingsgebied kan komen voor deze sensor. Nu moet er per initiatief bekeken worden waar deze sensor wel en niet voor gebruikt mag worden. Uit de use case van CityFlows in Mechelen is gebleken dat dat veel tijd vraagt. </br> </br> Fietstelpalen </br> Deze databron bevat data die komt uit een tellus, een geleider die in het fietspad of wegdek geslepen is. Wanneer die geleider onder stroom gezet wordt, genereert die een magnetisch veld. Wanneer er vervolgens magnetisch materiaal (een fiets) door en over dat magnetische veld rijdt, wordt het gegenereerde magnetische veld verstoord en wordt de stroom in de geleider beïnvloed. De verwerking van deze stroomveranderingen in het aantal fietsers wordt lokaal uitgevoerd. De provincie Oost-Vlaanderen was de eigenaar van de fietstelpaal in Gent en stelde de data van deze fietstelpaal ter beschikking via een datadump. Andere instanties van fietstelpalen zoals Signco en AWV stelde hun data ter beschikking via een openbare API. In Mechelen werd er bijvoorbeeld gebruik gemaakt van een fietstelpaal van Signco. </br> ➢ Sterktes </br> • De nauwkeurigheid is relatief voldoende. </br> • De uitrol in Vlaanderen is aan de gang. </br> ➢ Zwaktes </br> • Enkel fietsers worden gemeten. </br> • Aangezien carbonfietsen geen magnetisch materiaal hebben, worden die niet gemeten. </br> • Er is nog geen eenduidige standaard voor data uit fietstelpalen. </br> • De paal staat op een vast punt en meet dus enkel op dat punt en geeft dus geen data voor een grote geografische zone. </br> • De kostprijs is nog relatief hoog, wat een verdere geografische verspreiding beperkt. </br> ➢ Opportuniteiten </br> • Dankzij de ervaringen in CityFlows en andere projecten is het OSLO-traject voor verkeersmetingen gestart om datastromen uit verkeerssensoren semantisch te modelleren en de structuur van die data te standaardiseren . Dat traject werd opgestart binnen het relanceproject “Data Integratiediensten voor Slimme Mobiliteit” (DIM) waarvoor imec de geleerde lessen van CityFlows ingebracht. </br> • De uitrol van fietssnelwegen en het groeiende belang voor de fietsers zorgen ervoor dat het aantal meetpunten toeneemt. </br> • Als alle organisaties die deze palen plaatsen, de data die uit die palen voortkomt, ook zouden delen (na anonimisatie), zou de geografische dekking van deze databron verbeteren. </br> ➢ Bedreigingen </br> • Er is geen classificatie mogelijk tussen e-bike/speedpedelec of een gewone fiets. </br> • Enkel het aantal fietsers wordt gemeten. </br> • Bij afhankelijkheid van een API moet de voorbewerking van de data herbekeken worden wanneer er wijzigingen zijn aan de standaarden van de API. </br> ➢ Conclusies </br> De conclusies die uit de analyse van deze databron getrokken kunnen worden, zijn te vergelijken met de conclusies over de ANPR-camera. Ook deze databron meet slechts één modaliteit, niettemin met een aanvaardbare nauwkeurigheid. Het probleem is echter dat zowel AWV als de provincies voorlopig werken volgens de standaard die CROW Fietsberaad samen met UGent heeft opgebouwd. Die standaard wordt (nog) niet overal gebruikt en is ook (nog) niet vertaald in een OSLOstandaard. Op basis van de ervaring die is opgedaan in CityFlows, gaat imec samen met Digitaal Vlaanderen echter wel OSLO-verkeersmetingen opstellen waarin dat wordt meegenomen. Ons voorstel te verbetering van deze databron is dan ook het OSLO-traject waaraan imec actief meewerkt als deel van het kernteam. </br> Voor de use case in Gent is de data van deze soort sensoren ter beschikking gesteld via een datadump. Voor de fietspaal van Signco in Mechelen werd die als open data (via API) afgehaald. Voor telpalen van andere leveranciers (de provincies of andere spelers) moest er aparte toegang verkregen worden. Het zou een positieve verandering zijn als het verlenen van die toegang geoptimaliseerd kan worden (bijvoorbeeld met behulp van dataspaces of een andere technologie voor datadeling). Met de kennis die is opgedaan binnen het CityFlows-project is imec dan ook in het VSDS-project (Vlaamse Smart Data Space) en het CitCom.AI-project gestapt. Daarover volgt later in dit document meer. </br> </br> Tijdelijke meetinstallaties </br> Tijdelijke meetcampagnes werden in Gent en Mechelen uitgevoerd door telslangen. In Gent werd gewerkt met een onderleverancier die de telslangen plaatste. In Mechelen werden er enkele door de politie gelegd voor een specifieke use case (politierapporten genoemd). Er zijn zowel fietstelslangen als algemene telslangen geplaatst. Telslangen werken op een gelijkaardige manier als tellussen, maar de geleider wordt bij telslangen niet in het wegdek geslepen, maar tijdelijk in een rubberen “slang” over het wegdek gelegd. </br> ➢ Sterktes </br> • Relatief hoge nauwkeurigheid </br> • Relatief eenvoudige installatie met minimale schade aan wegdek en zonder invloed op de doorstroming </br> ➢ Zwaktes </br> • Weggebruikers proberen dergelijke installaties vaak te vermijden als ze zien liggen, wat kan leiden tot onnauwkeurige tellingen. </br> • Carbonfietsen worden niet gedetecteerd. </br> • Tijdelijk van aard, en daardoor wordt het door seizoenseffecten moeilijk om trends op lange termijn te zien. </br> • Er bestaat geen echte standaard voor deze metingen (op basis van de geleerde lessen van CityFlows is het OSLOtraject voor verkeersmetingen opgestart). </br> • Bij remmend/stilstaand verkeer (file) is de werking van de lus niet optimaal. </br> ➢ Opportuniteiten </br> • Op basis van de ervaringen van CityFlows en andere projecten is het OSLO-traject voor verkeersmetingen opgestart om de semantiek rond data eenduidig te krijgen. </br> • Deze data blijft vaak bij één lokaal bestuur en lokale bevinden worden niet gedeeld buiten de grenzen van de steden. Er is dus nog ruimte om die data- en kennisdeling te optimaliseren aan de hand van een dataspace/samenwerking. </br> ➢ Bedreigingen </br> • Classificatie tussen soorten fietsers blijft moeilijk. </br> • Classificatie tussen wagen/bestelwagen/vrachtwagen bij traag, accelererend of remmend verkeer is niet 16 nauwkeurig </br> ➢ Conclusies </br> In het algemeen werd de data uit deze tijdelijke meetcampagnes binnen CityFlows als zeer waardevol gezien, omdat deze databron door de relatief hoge nauwkeurigheid als “ground truth” beschouwd kan worden en daardoor geschikt is om te vergelijken met andere databronnen. Het is aan te bevelen om deze data beter te delen buiten de grenzen van steden. Een dataspace zoals de Vlaamse Smart Data Space (VSDS) kan een mogelijke enabler zijn om dat te bereiken. Ook zouden alle vormen van tijdelijke telcampagnes een eenduidige beschrijving moeten hebben. Op basis van deze aanbevelingen heeft imec het al eerdergenoemde OSLO-traject voor verkeersmetingen opgestart. </br> Voor het CityFlows-project werd de data op verschillende manieren ter beschikking gesteld. Sommige leveranciers hadden daarvoor een API voorzien waarvan de data afgehaald kon worden. De politierapporten in Mechelen werden via een datadump beschikbaar gesteld. </br> </br> Straatvinken </br> Straatvinken is een burgerinitiatief dat jaarlijks burgers tellingen gedurende één uur (van 17.00 uur tot 18.00 uur) laat uitvoeren. De tellingen worden elk jaar rond hetzelfde moment uitgevoerd (in de tweede helft van mei) om ervoor te zorgen dat die statistisch gezien correct zijn. Burgers krijgen de kans om het voorbijkomende verkeer te tellen met een applicatie. Via die applicatie worden hun tellingen vervolgens verwerkt. </br> ➢ Sterktes </br> • Relatief hoge nauwkeurigheid die kan dienen als ground truth </br> • Lage kostprijs </br> • Multimodaal beeld </br> • Kwaliteitscontrole op de tellingen door Ringland Academie , Universiteit Antwerpen en HIVA - KU Leuven </br> ➢ Zwaktes </br> • Confirmation bias speelt mogelijk bij burgers (ik zie wat ik wil zien en/of ik wil mijn gelijk bewijzen). </br> • Beperkt in tijd (slechts één uur op jaarbasis), dus beperkt bruikbaar voor kleinere tijdsvensters. </br> • De burger maakt mogelijk fouten als hij één uur lang gefocust moet blijven en daarnaast is het in een drukke straat soms moeilijk om het verkeer goed te blijven volgen en tellen. Aangezien elke telling achteraf nog geanalyseerd wordt, blijft deze foutgevoeligheid echter beperkt. </br> ➢ Opportuniteiten </br> • De geografische dekking is relatief gezien voldoende (het initiatief is relatief wijdverspreid en bekend). </br> • Ondersteuning door universiteiten zorgt ervoor dat deze databron voldoende gecontroleerd wordt. Een transparante communicatie daarover kan het vertrouwen in de data mogelijks nog doen toenemen </br> ➢ Bedreigingen </br> • Deze data is mogelijk foutgevoelig, omdat de aandacht van burgers kan verslappen als ze één uur lang achter elkaar volledig geconcentreerd moeten tellen. </br> • Vrijwillige participatie van burgers is noodzakelijk. Het blijft daardoor onzeker of er een engagement is voor meerdere jaren zodat de lange termijn in kaart gebracht kan worden. </br> ➢ Conclusies </br> De conclusies die we kunnen trekken uit de analyse van deze databron is beperkter in vergelijking met de andere databronnen, omdat de databron beperkter is in tijd ten opzichte van de andere databronnen. Het nadeel van deze databron is dat het gevoelig is voor menselijke fouten, ondanks controle achteraf. Daarover dient dan ook duidelijk gecommuniceerd te worden. </br> Het is aan te raden om deze tellingen vooral te laten uitvoeren door burgers met een Telraamsensor. De toegevoegde waarde van een dergelijke sensor is de creatie van een lokaal kalibratiepunt. De vraag is echter of burgers die een Telraamsensor in hun bezit hebben, de extra inspanning willen en kunnen leveren om een dergelijke telling binnen dit initiatief uit te voeren. Daarnaast is het ook aan te bevelen om de telling twee keer per jaar te organiseren om meer meetpunten te hebben aangezien één uur per jaar te beperkt is. </br> </br> Floating car data </br> Floating car data is data van weggebruikers die gebruikmaken van een navigatieapp (op hun smartphone) tijdens hun verplaatsing. De data is goed te gebruiken om te weten hoeveel wagens naar een stad rijden en via welke wegen ze dat doen. Bij meer lokale use cases (bijvoorbeeld bij metingen in een schoolstraat of bij het meten van lokaal verkeer) is deze data echter vaak beperkt bruikbaar aangezien mensen voor kleine, lokale verplaatsingen vaak geen navigatie gebruiken. Hoewel het in theorie mogelijk is om op dezelfde manier data te verzamen van actieve weggebruikers (fietsers en voetgangers), is dat in de praktijk onuitvoerbaar omdat navigatieapps door deze weggebruikers beperkt of zelfs niet gebruikt worden. Als deze soort data van fietsers komt, wordt er gesproken over floating bike data. Voor het CityFlowsproject werd uitsluitend floating car data (FCD) voor Mechelen ter beschikking gesteld. </br> ➢ Sterktes </br> • Multimodaal verkeer is in theorie mogelijk. </br> • Het is mogelijk om een heel traject te volgen; er is dus geen beperkte puntmeting. </br> • Geografische dekking is direct op stadsniveau. </br> ➢ Zwaktes </br> • Het aantal gebruikers van dergelijke navigatieapps is voor lokaal verkeer zeer laag. Voor de schoolstraat in Mechelen was er vaak geen enkel datapunt beschikbaar. </br> • In de praktijk worden dergelijke navigatieapps niet gebruikt door actieve weggebruikers. </br> ➢ Opportuniteiten </br> • De uitrol van intelligente verkeerslichten (iVRI) binnen het Mobilidata-programma zal het gebruik van dergelijke navigatieapps wellicht kunnen aanmoedigen. </br> • Geconnecteerde wagens delen veel meer data waardoor het in de toekomst interessanter kan zijn om gebruik te maken van deze databron. </br> ➢ Bedreigingen </br> • Steden nemen vaak bij één leverancier af en zijn dus ook afhankelijk van het aantal gebruikers van één app. </br> ➢ Conclusies </br> De meerwaarde van deze data is de hogere geografische dekking doordat de data trajectdata bevat en niet enkel data van een lokale sensor. Het nadeel van deze data is de zeer beperkte penetratiegraad. Op primaire wegen is die penetratiegraad nog relatief hoog, maar op secundaire en tertiaire wegen is die vaak toch zeer beperkt. Voor lokale use cases zoals de evaluatie van een wijkmobiliteitsplan of het invoeren van een schoolstraat, is deze databron minder geschikt, omdat weggebruikers zelden tot nooit gebruikmaken van een navigatieapp voor wegen die ze al goed kennen. Bovendien worden dergelijke navigatieapps door actieve weggebruikers zelden gebruikt. In de praktijk is deze databron dus enkel geschikt voor gemotoriseerd verkeer. </br> Deze databron werd enkel gebruikt in Mechelen. Er werd gewerkt met leverancier Be-Mobile. Deze databron is doorgaans relatief duur vergeleken met de mogelijke functionaliteiten die de databron oplevert (althans binnen de context van het CityFlows-project). De data werd ter beschikking gesteld via een datadump (een statisch CSV-bestand dat doorgestuurd werd). </br> </br> Datafusiemodel </br> In dit deel wordt beschreven hoe er vanuit de data, de dataverwerking en het model naar de output gegaan wordt. Aangezien dit deel technischer van aard is, wordt in dit deel soms verwezen naar een PowerPointpresentatie. Met beelden kunnen zaken soms namelijk veel beter overgebracht worden dan met een lange tekst. De algemene dataflow is te zien in onderstaande figuur. Vanuit die dataflow is dit deel van het rapport opgebouwd. Deze flow wordt in de volgende delen van de tekst verklaard. </br> </br> Architectuur datafusiemodel CityFlows </br> In het eerste blok van de dataflow worden de datadumps of API-bevragingen uit het eerste deel van dit rapport gecontroleerd op hun kwaliteit. Er wordt bekeken hoe het signaal van de sensoren zich gedraagt om eventuele gaten of hiaten in de data te kunnen signaleren. De meetfrequentie en opbouw van de data wordt ook in deze fase gecontroleerd. Het formaat waarin de data binnenkomt, wordt getransformeerd naar een uniform formaat dat specifiek is voor het CityFlows-model. Als elke bron individueel bewerkt is tot het gewenste formaat, wordt alle data samengevoegd in één bestand (het “all_data.csv”-bestand in Figuur 5). </br> Het handling script voor een bepaalde databron begint telkens met het opkuisen van lege velden en het verwijderen van onnodige of lege kolommen. Voor een databron die voor een punt intensiteiten (aantal passages per tijdseenheid) 20 teruggeeft, is de volgende stap om deze intensiteiten om te zetten naar dichtheden (het aantal weggebruikers per lengteeenheid). Hiervoor geldt de volgende formule: </br> dichtheid = aantal passages / ( tijdsperiode * snelheid) </br> Voor deze formule is het nodig om het gegeven “snelheid” te kennen. Als die niet gekend is (omdat de databron dat niet meet), wordt er een bepaalde snelheid aangenomen. Voor databronnen die de data direct in een snapshotformaat aanleveren, is dat uiteraard niet nodig </br> Als meettoestellen een puntmeting uitvoeren, moet het punt gelinkt worden aan het corresponderende straatsegment in het Vlaamse wegenregister. Als de meting uitgevoerd wordt voor een groter geografisch gebied, kan dat uiteraard niet gelinkt worden aan een straat, en zal het gehele gebied beschreven moeten worden. In dat geval beschrijft de kolom voor de geometrie een oppervlak en geen lijn. </br> In de laatste stap krijgen alle kolommen een andere naam en worden ze gestructureerd tot ze overeenkomen met het formaat van het “all_data.csv”-bestand. </br> </br> Model </br> Er werd een model ontwikkeld dat data van verschillende databronnen benut om een beeld te geven van de dichtheid van verschillende modaliteiten. Het ontwikkelende model bouwt verder op het rapport “Data fusion model for CityFlows” van de Universiteit Antwerpen. Dat model werd ontwikkeld in een PoC in de smart zone van Antwerpen. In de smart zone (waar veel databronnen aanwezig waren) werkte het model voor twee modaliteiten (wel en niet-gemotoriseerd). Binnen dat traject werd onderzocht of het model ook op grotere schaal (stadsniveau) en voor meer modaliteiten kan werken. </br> Het model heeft in essentie maar drie elementen nodig om te werken: </br> • “street_segments.csv” – Straatinformatie </br> • “intersections.csv” - Kruispuntinformatie </br> • “all_data.csv” - Data met de tellingen van de verschillende gegevensbronnen </br> Het model dient die input aan te krijgen als CSV-bestanden met een specifieke structuur. Op GitHub staat ook een voorbeeld van de roadcutter procedure. Dat is een procedure om de eerste twee bestanden (met straat- en kruispuntinformatie) te creëren. Als basis zal daarvoor het Vlaamse Wegenregister gebruikt worden. De roadcutter heeft als input ook het “all_data”-bestand nodig. </br> Voor elke beschikbare meting van elk van de niet-weerhouden databronnen is er een lijn in het databestand. Die lijn bevat ook informatie over de regio van de meting. Dat is belangrijk voor de roadcutter procedure. Daarnaast staan er in de lijn nog het tijdstip en enkele indexen. </br> De gewichten van de gewogen verdeling is optioneel. Die input is ook een CSV-bestand. De structuur van dat bestand is simpel: elke straat heeft een lijn en in de kolommen staan de gewichten per modaliteit. Als deze optionele input niet ingegeven wordt in het model zullen alle gewichten gelijkgesteld worden aan 1 en zal het model in feite dus een uniforme verdeling maken. </br> </br> Output van model </br> De outputdata van CityFlows kan worden aangeleverd in het NGSI-LD formaat TrafficFlowObserved. Enkele attributen zijn daaraan toegevoegd om tot een werkbare standaard te komen voor CityFlows. Het bovenstaande dataformaat staat het toe om data in te geven:</br> • voor elk straatsegment in de afgebakende zone; </br> • voor elke vijf minuten - op voorwaarde dat er voldoende databronnen bestaan die deze mate van detail kunnen aanleveren; </br> • voor elke modaliteit - indien er voldoende sensoren zijn die de betrokken modaliteiten meten. In het kader van de voorgestelde scope zullen dat de volgende gemodelleerde modaliteiten zijn: voetgangers, fietsers, gemotoriseerd verkeer en de achtergrond (de personen die geteld zijn door telecomdata maar die niet actief deelnemen aan het verkeer).</br> Het model bepaalt de verkeersdichtheid (het resultaat van de modelberekening) voor elk van de bovenstaande gegevens. Daarmee kan men vervolgens de use cases per stad evalueren.</br> </br> Datafusie </br> Het model is een datafusiemodel dat zo min mogelijk effecten of menselijk gedrag opgelegd kreeg om ervoor te zorgen dat het gedrag enkel in kaart gebracht zou worden door de data. Zonder a priori kennis van het wegennet bleek dat echter niet mogelijk. De wiskundige insteek bleek onvoldoende om het menselijke gedrag weer te geven.</br> Stapsgewijs werd er meer data aan het model toegevoegd om de hypothese dat het model betrouwbaarder zou worden naarmate er meer databronnen aan toegevoegd zouden worden, te kunnen bewijzen. Zoals eerder aangegeven, waren de resultaten daarvan teleurstellend. </br> Nog een ander effect was zichtbaar. De uniforme verdeling die gebruikt werd, was nog te zien in de output. Daarom werd er gezocht naar een gewogen verdeling. Die gewogen verdeling gaf visueel een beter beeld, maar zorgde uiteindelijk niet voor een verbetering van de resultaten op zich.</br> </br> Validatieproces </br> In het validatieproces voor het model werden de data van Straatvinken gebruikt als ground truth.</br> Het model geeft zijn uitkomsten weer in dichtheden. Om de dichtheden van het model te kunnen vergelijken met die van de Straatvinkendataset moet het resultaat van die dataset eerst omgezet worden van intensiteiten (het aantal personen per tijdseenheid) naar dichtheden (het aantal personen per meter). De Straatvinkentelling houdt het gegeven “snelheid” echter niet bij. Aangezien dat gegeven noodzakelijk is voor het omzetten van de data wordt er een bepaalde snelheid verondersteld. Om één enkele validatiescore te krijgen, wordt de gewogen som genomen met de relatieve straatlengtes als gewichten. De validatiescore die daaruit volgt, is de gewogen verhouding van het aantal straten waarvan het resultaat ligt in een geaccepteerde zone (tussen de 66% en 150% van de Straatvinkendata). Zoals hierboven reeds vermeld zijn er stapsgewijs extra databronnen aan het model toegevoegd. Een dergelijke stap wordt aangeduid met een “learning cycle”. In Tabel 2 staan de validatiescores van de verschillende learning cycles en van de gewone en de aangepaste gewogen verdeling.</br> </br> Validatiescore CityFlows </br> Uit de tabel blijkt dat het model een validatiescore heeft die grofweg tussen de 1% en 5% accuraatheid varieert, afhankelijk van het aantal gebruikte databronnen. Volgens de validatiehypothese levert het model dus in 1 tot 5% van de berekende dichtheden op straatniveau een betrouwbaar resultaat, een zeer laag resultaat. De hypothese dat de score zou stijgen zodra er meer bronnen toegevoegd zouden worden, is bij dezen dus verworpen. Ook de gewogen verdelingen leidden niet tot een verbetering van de validatiescore. Dit suggereert ook dat het design van het CityFlows validatieproces niet exact meet wat het zou moeten meten.</br> </br> Resultaten model </br> Voor het controleren van de output van het model ontwikkelde imec een methode. De validatiescore (het resultaat van het validatieproces van imec) was laag en kon niet verbeterd worden door meerdere databronnen aan het model toe te voegen. Ook het toevoegen van de gewogen verdeling leverde geen betere validatiescore op.</br> In het rapport dat de basis vormde voor het CityFlows-project werd de hypothese naar voren gebracht dat andere databronnen toegevoegd konden worden aan het model. Die hypothese bleek te kloppen. Het is inderdaad mogelijk gebleken om databronnen te gebruiken die oorspronkelijk niet in het model zaten. Daarbij moet wel opgemerkt worden dat het belangrijk is om de context van de meettoestellen goed te kennen. De locatie van een ANPR-camera is bijvoorbeeld onvoldoende om te weten wat die camera exact meet. Het bemachtigen, uniformiseren en analyseren van de data vergde meer werk dan oorspronkelijk was voorzien. Het werk dat verzet is, is echter wel herbruikbaar voor verdere analyses van de besproken bronnen. Het kan ook gebruikt worden als een voorbeeld voor eventuele nieuwe gegevensbronnen in de toekomst.</br> Het kan gezegd worden dat het model vollediger is geworden. Het functioneert op stadsniveau en werkt met meerdere databronnen. Hoewel de input van de verschillende bronnen goed gefit worden, is de output van het model gelet op de lage validatiescores toch onbetrouwbaar.</br> </br> Analyse toolbox </br> Een van de grote lessen van het project CityFlows is dat er nog heel wat uitdagingen zijn opdat lokale besturen effectief aan de slag kunnen met mobiliteitsdata. Enerzijds bleek het opzetten van een datafusiemodel geen sinecure: zowel het tekort aan data en de ongelijkmatige spreiding, kwaliteitsvolle data als het gebrek aan standaarden, speelden in belangrijke mate parten. Omdat er met het CityFlows project wel een antwoord gevonden wou worden op de use cases van de steden werd een Analyse toolbox ontwikkeld. </br> Om lokale besturen toch een beter inzicht in bestaande mobiliteitsdata op hun grondgebied te verschaffen, ontwikkelde imec een analyse-toolbox die de huidige datameetpunten in de stad visualiseert en de voor- en na-situatie van een mobiliteitsingreep statistisch toetst. Samen met de twee pilootsteden, Mechelen en Gent, werd de analyse-toolbox verder vormgegeven. De toolbox kan worden ingezet in de dagelijkse praktijk van de mobiliteitsambtenaar: mits het opladen van de beschikbare databronnen per stad kan je analyseren wat de huidige situatie is en hoe deze verandert na de implementatie van een ingreep in de mobiliteitsstromen van de verschillende modi van de stad.</br> </br> Interessante linken </br> De codering van zowel het model (opent in nieuw venster) als de toolbox (opent in nieuw venster) zijn open-source ter beschikking gesteld, met bijhorende guidelines.</br> Om zeker te zijn dat de toolbox voldoende toegankelijk is voor de steden werd er ook een instructiefilmpje opgesteld dat hier terug te vinden is. </br> Het rapport over het project CityFlows kan je hier vinden.</br> De website van het CityFlows project kan je hier vinden  +
• Introductie De digitalisering van de par … Introductie </br> De digitalisering van de parkeerrechten voor personen met een handicap zorgt ervoor dat de parkeerrechten van de voertuigen op de parkeerplaatsen voor gehandicapten digitaal kan gecontroleerd worden. </br> Dit project werd uitgewerkt in 2022-2023 door het Mobiliteitsbedrijf Antwerpen en resulteerde in haalbaarheidsstudie die bestond uit een analyse en een uitgewerkte architectuur.</br> </br> </br> Pitch </br> Voor personen met een handicap die met één enkel digitaal recht on street en op voorbehouden plaatsen kunnen parkeren in alle Vlaamse steden en gemeenten waar digitaal gehandhaafd wordt, zonder voorlegging van een fysieke parkeerkaart </br> biedt deze vernieuwde aanpak</br> een volledig digitale behandeling van de parkeervergunningen voor personen met een handicap </br> door het bezit van een parkeerkaart op naam te koppelen aan één of meerdere nummerplaten en te controleren of de aanvrager de rechthebbende is waardoor grote fraude met deze kaarten kan worden tegengegaan. </br> in tegenstelling tot de huidige manier van werken is deze aanpak eenvoudig, digitaal en voordelig voor zowel de houder van het recht als voor de parkeerhandhaving in de Vlaamse steden en gemeenten. </br> </br> Impactmap </br> </br></br> </br> Doel</br> </br> Doelgroep</br> </br> Impact</br> </br> Deliverable</br> </br> </br> Met deze vernieuwde aanpak willen we een volledige digitale behandeling van de parkeervergunningen voor personen met een handicap door het recht op een fysieke federale parkeerkaart voor personen met een handicap te koppelen aan één of meerdere nummerplaten en te controleren of de aavrager de rechthebbende is waardoor de grote fraude met deze kaarten kan worden tegengegaan.</br> </br> Burger die over een federale parkeerkaart voor personen met een handicap beschikt en parkeert in een Vlaamse gemeente waarbij deze gebruik wil maken van het gemeentelijk regime betreffende parkeren met een parkeerkaart voor personen met een handicap (gratis, verminderd tarief, voorbehouden plaats..)</br> </br> We willen voor de burger een digitaal parkeerrecht voor personen met een handicap creëren dat geldig is in alle Vlaamse gemeenten en dat oneindig is in tijd of geldig is voor de duur zoals aangegeven in de kruispuntenbank Sociale Zaken. Impactmeting - Aantal burgers dat gebruik maakt van een digtaal parkeerrecht voor personen met een handicap. - Aantal vaststellingen dat gebeurt op basis van fysiek voorliggende parkeerkaart. - Sustantieel minder aantal retributies wegens niet voorliggen parkeerkaart. - Substantieel minder aantal GAS boetes wegens foutief parkeren op voorbehouden plaatsen voor personen met een handicap. - Substantieel meer voorbehouden plaatsen beschikbaar voor personen met een recht om er te parkeren. - Substantieel minder fraude met oneigenlijke kaarten. - Substantieel lagere handhavingskost waardoor gratis parkeren mogelijk blijft.</br> </br> - Aanpassing wegcode zodat ook digitaal parkeerrecht wettelijk en jurdisch mogelijk is. - Verkrijgen van een machtiging voor de online bevraging rechthebbenden parkeerkaart personen met een handicap op basis van rijkregisternummer. - Centrale database die alle digitale parkeerechten voor personen met een handicap bevat. - Centraal beheer en onderhoud van de database - Koppeling van persoonlijk recht (houder parkeerkaart) met de nummerplaat van het voertuig waarmee deze zich verplaatst.</br> </br> </br> We willen voor de burger één uniforme eenmalige registratieprocedure waarmee een digitaal parkeerrecht voor personen met een handicap kan worden aangevraagd.</br> </br> - Multikanaals registratieprocedure zodat deze toegankelijk is voor iedereen in de doelgroep om een aanvraag in te dienen. - Digitale registratieprcocessen zijn WCAG compliant en voldoen aan de normering om maximale digitale toegankelijkheid te waarborgen.</br> </br> </br> Burger die over een federale parkeerkaart voor personen met een handicap beschikt en zich registreert voor een digitale parkeervergunning</br> </br> We willen de burger een volledig digitaal online registratieproces en maximaal hergebruik van digitale informatie aanbieden met maximale toegankelijkheid gericht op de specifieke doelgroep Impactmeting - Aantal aanvragen dat via volledig digitale weg wordt ingediend. - Aantal digitale parkeervergunningen dat meteen na indienen wordt aangemaakt en uitgereikt.</br> </br> - Real-time bevestiging van de identiteit van de aanvrager door sterke authenticatie via eID, ITSME en dergelijke. - Real-time bevestiging van het recht op een parkeerkaart voor personen met een handicap door kruispuntenbank Sociale zaken (MAGDA bouwsteen Geef_Handicap 2.0). - Wegschrijven van het digitale recht naar een centrale database. - Integratie van alle bouwstenen en API's nodig voor de digitalisering van het volledige proces aavraag parkeervergunning personen met een handicap - Mogelijkheid om attesten op te laden (kopie identiteitskaart houder parkeerkaart, volmacht) indien aanvrager niet de houder is van de federale parkeerkaart. - Aflevering van parkeervergunning in digitale vorm</br> </br> </br> We willen de burger een volledig digitaal registratieproces aanbieden met maximaal hergebruik van digitale informatie Impactmeting - Aantal aanvragen dat digitale drager (mail) wordt ingediend. - Aantal digitale parkeervergunningen dat binnen de afgesproken termijn wordt aangemaakt en uitgereikt.</br> </br> - Mogelijkheid tot indienen aanvraag door gemeenteambtenaar namens de burger - Real-time bevestiging van het recht op een parkeerkaart voor personen met een handicap door kruispuntenbank Sociale zaken (MAGDA bouwsteen Geef_Handicap 2.0). - Wegschrijven van het digitale recht naar een centrale database. - Integratie van alle bouwstenen en API's nodig voor de digitalisering van het volledige proces aavraag parkeervergunning personen met een handicap - Mogelijkheid om attesten op te laden (kopie identiteitskaart houder parkeerkaart, volmacht) indien aanvrager niet de houder is van de federale parkeerkaart. - Aflevering van parkeervergunning in digitale of analoge vorm</br> </br> </br> We willen de burger een fysiek (loket) registratieproces aanbieden met maximaal hergebruik van hergebruik van digitale informatie Impactmeting - Aantal burgers dat zich aan het loket aanbiedt voor een aanvraag - Aantal digitale parkeervergunningen aan het gemeenteloket wordt aangemaakt.</br> </br> - Mogelijkheid tot indienen aanvraag door gemeenteambtenaar namens de burger - Real-time bevestiging van het recht op een parkeerkaart voor personen met een handicap door kruispuntenbank Sociale zaken (MAGDA bouwsteen Geef_Handicap 2.0). - Wegschrijven van het digitale recht naar een centrale database. - Integratie van alle bouwstenen en API's nodig voor de digitalisering van het volledige proces aavraag parkeervergunning personen met een handicap - Mogelijkheid om attesten op te laden (kopie identiteitskaart houder parkeerkaart, volmacht) indien aanvrager niet de houder is van de federale parkeerkaart. - Real- time aflevering van fysieke parkeervergunning (papier)</br> </br> </br> Burger niet handelingsbekwaam om aanvraag in te dienen</br> </br> Wij willen dat een gevolmachtigde 'derde' (voogden bewindvoerders, maar derden met een volmacht van de gerechtigde) een aanvraag kan indienen voor een burger die handelingsonbekwaam is of door omstandigheden geen gebruik kan maken van de verschillende aangeboden registratieprocedures (digitaal niet voldoende beslagen of geen toegang tot IT infrastructuur...)</br> </br> - Mogelijkheid om in het registratieproces aan te geven of de aavraag door een derde wordt ingediend. - Mogelijkheid om attesten op te laden (kopie identiteitskaart houder parkeerkaart, volmacht) indien aanvrager niet de houder is van de federale parkeerkaart. - Creatie van takeninbox waarin aanvragen met dcocumentvalidatie in terecht komen.</br> </br> </br> Wijzigen voertuigen</br> </br> Wij willen de burger de mogelijkheid geven om digitaal op eenvoudige wijze de nummerplaat van voertuig waarmee deze zich verplaatst te wijzigen en waarbij het recht ten allen tijde aan slechts één nummerplaat is gekoppeld.</br> </br> - Mobiele applicatie waarmee - een oneindige parkeersessie kan worden op een nummerplaat kan worden stopgezet - een nieuwe oneindige parkeersessie kan worden aangegaan op een andere nummerplaat - Credentials om gebruik te maken van de mobiele applicatie - Geen beperking op het aantal te gebruiken nummerplaten - Creatie van shortlist met meest gebruikte nummerplaten - Intgratie van de nodige API's om aanpassing numerplaat van digitaal parkeerrecht door te geven aan de centrale database - Doorgeven time stamp met wanneer nieuwe nummerplaat geldig is</br> </br> </br> Wij willen de burger de mogelijkheid geven om via contact met een gemeente op eenvoudig wijze de nummerplaat van voertuig waarmee deze zich verplaatst te wijzigen en waarbij het recht ten allen tijde aan slechts één nummerplaat is gekoppeld.</br> </br> </br> Koepelorganisaties en belangengroepen (Hoge Raad voor personen met een handicap, UNIA…)</br> </br> Wij willen de koepelorganisaties en belanggroepen bevragen om zo hun steun en actieve medewerking te verkrijgen bij de ontwikkeling van ons project.</br> </br> - Identificatie belangrijkste stakeholders. - Opzetten overlegstructuur om procesontwerp en business rules af te stemmen. - Formele steun door koepelorganisaties en belanggroepen. - Onderbouwd en ondersteund dossier voor verkrijgen machtiging bevraging kruispuntenbank Sociale Zaken.</br> </br> </br> Medewerkers loketwerking</br> </br> Wij willen dat de medewerkers van de loketten namens de klant in het loket een aanvraag voor een digitale parkeervergunning voor personen met een handicap digitaal kunnen indienen.</br> </br> - Opzetten van rechtenbeheer en usermanagement - Real-time bevestiging van het recht op een parkeerkaart voor personen met een handicap door kruispuntenbank Sociale zaken (MAGDA bouwsteen Geef_Handicap 2.0). - Wegschrijven van het digitale recht naar een centrale database. - Integratie van alle bouwstenen en API's nodig voor de digitalisering van het volledige proces aavraag parkeervergunning personen met een handicap - Mogelijkheid om attesten op te laden (kopie identiteitskaart houder parkeerkaart, volmacht) indien aanvrager niet de houder is van de federale parkeerkaart. - Creatie van takeninbox waarin aanvragen met dcocumentvalidatie in terecht komen.</br> </br> </br> Medewerkers backoffice</br> </br> Wij willen dat de medewerkers van de backoffice namens de klant in het loket een aanvraag voor een digitale parkeervergunning voor personen met een handicap digitaal kunnen indienen. Impactmeting - minder retributies wegens niet voorliggen kaart - minder GAS boetes wegens onterecht parkeren op voorbehouden plaatsen - minder bezwarenbehandeling</br> </br> - Opzetten van rechtenbeheer en usermanagement - Real-time bevestiging van het recht op een parkeerkaart voor personen met een handicap door kruispuntenbank Sociale zaken (MAGDA bouwsteen Geef_Handicap 2.0). - Wegschrijven van het digitale recht naar een centrale database. - Integratie van alle bouwstenen en API's nodig voor de digitalisering van het volledige proces aavraag parkeervergunning personen met een handicap - Mogelijkheid om attesten op te laden (kopie identiteitskaart houder parkeerkaart, volmacht) indien aanvrager niet de houder is van de federale parkeerkaart. - Creatie van takeninbox waarin aanvragen met dcocumentvalidatie in terecht komen.</br> </br> </br> Parkeertoezichters</br> </br> De parkeerwachters zullen het bezit en de geldigheid van het parkeerrecht voor personen met een handicap controleren door het scannen van een nummerplaat. Impactmeting - Geen visuele controle van parkeerrechten meer nodig - Efficiëntere en effectievere handhaving - uitreiken van retributies mogelijk door systeem in plaats van de handhaver ter plaatse</br> </br> - on street connectie met centrale rechtendatabase (scanwagen, handheld..) </br> </br> </br> </br> </br> Vlaamse Instanties o.a. kenniscentrum Vlaanderen en digitaal Vlaaderen</br> </br> In samenwerking met kenniscentrum Vlaanderen wordt bekeken welk model voor deling en financiering (kostenverdeling) we kunnen toepassen om het digitale parkeerrecht beschikbaar te maken voor alle Vlaamse gemeenten. Het project digitalisering parkeervergunning voor personen met een handicap zal een aanvulling zijn aan het huidige project over de deling van een gemeenschappelijke parkeerrechtendatabase en omliggende toepassingen dat reeds loopt binnen kenniscentrum Vlaanderen. Met digitaal Vlaanderen bekijken weer of we de user interface, de backend en de database, de hosting en onderhoud meteen of Vlaams niveau kunnen opzetten volgens de gevraagde standaarden. De andere optie is om te ontwikkelen op lokaal niveau en daarna pas op een hoger bestuurlijk niveau te ontsluiten.</br> </br> - ontwerpovereenkomsten tussen de gemeenten onderling over delings- en financieringsmodel - concrete afspraken over userinterface en hosting</br> </br> </br> </br> </br> FOD Sociale Zaken en FOD Mobiliteit</br> </br> We overleggen en overtuigen de Federale overheidsdiensten Sociale Zaken en Mobliteit van de noodzaak om de parkeervergunning voor personen met een handicap digitaal te maken. We gaan hiervoor in overleg om de voorwaarden te bespreken en de paramaters te bepalen waaraan onze oplossing moet voldoen. Deze nemen we mee in de opdracht voor de businessanalyse. We onderzoeken eveneens de mogelijkheid om de impact van ons project op te schalen naar een federaal niveau. De inhoud van ons project belangt in casu alle Belgische gemeenten aan.</br> </br> - machtiging bevraging Kruispuntenbank Sociale Zekerheid</br> </br> </br> </br> </br> Blauwdruk </br> </br></br> </br> Fase</br> </br> aanpassing retributiereglementen</br> </br> communicatietraject</br> </br> Proactieve bezorging code</br> </br> initiatie van de regsitratie</br> </br> creatie digitaal parkeerrecht</br> </br> aflevering van het recht</br> </br> controle van het recht</br> </br> </br> Interactiepunt</br> </br> In de retributierglementen die van de toepassing gebruik willen maken wordt opgenomen dat er een digitaal parkeerrecht moet aangemaakt worden indien men wil genieten van de verschillende parkeervoordelen voor personen met een handicap dit worden geboden door het desbetreffend lokale bestuur</br> </br> In samenwerking met de federale overheid, de lokale besturen en de organisaties uit de doelgroep wordt een communicatietraject opgezet om de personen met een handicap op de hoogte te brengen van het nieuwe digitale parkeerrecht, het waarom ervan en de wijzen men dit kan aanvragen</br> </br> De houders van een federale parkeerkaart ontvangen van de Directie-Generaal voor de gehandicapten per post een unieke code waarmee de persoon met een handicap zich kan aanmelden De houders van een federale parkeerkaart ontvangen een begleidend schrijven met de uitleg over wat het digitaal parkeerrecht inhoud, waarom men dit moet aanvragen en op welke manieren men dit kan doen.</br> </br> ik surf naar de URL en kies de methode waarmee ik mij wil aanmelden eID/ITSME of kaartnummer en code ik kies de taal waarin ik wil verder gaan om een nummerplaat opgeven ik selecteer of ik een Belgische of buitenlandse houder ben van een Europees model parkeerkaart voor personen met een handicap ik surf naar 'mijn burgerprofiel','mon espace' waar ik mij aanmeld met eID/ISTME waar deze aanmeld methode als singel sign-on dient om in de web applicatie te komen Bij de aanmelding wordt meteen gecontroleerd of ik een houder ben van een federale parkeerkaart voor personen met een handicap in de webapplicatie krijg ik meteen te zien aan welke nummerplaat het actieve parkeerrecht hangt. Dit kan een langlopend of kortlopend recht zijn. Ik krijg ook meteen de 5 laatste gebruikte nummerplaten te zien die aan het recht werden gekoppeld met hun respectievelijk datum en duurtijd. Ik de webapplicatie kan ik ook een nummerplaat opgeven of wijzigen. Als ik over een buitenlands Europees model parkeerkaart voor personen met een handicap beschik kan ik met opgave van mijn kaartnummer alleen een kortlopend recht registeren</br> </br> Ik open op een mobiele drager (android, IOS) de native app en meld mij aan via eID/ITSME of kaartnummer en code ik kies de taal waarin ik wil verder gaan om een nummerplaat opgeven ik selecteer of ik een Belgische of buitenlandse houder ben van een Europees model parkeerkaart voor personen met een handicap Bij de aanmelding wordt meteen gecontroleerd of ik een houder ben van een federale parkeerkaart voor personen met een handicap in de webapplicatie krijg ik meteen te zien aan welke nummerplaat het actieve parkeerrecht hangt. Dit kan een langlopend of kortlopend recht zijn. Ik krijg ook meteen de 5 laatste gebruikte nummerplaten te zien die aan het recht werden gekoppeld met hun respectievelijk datum en duurtijd. Ik de webapplicatie kan ik ook een nummerplaat opgeven of wijzigen. Als ik over een buitenlands Europees model parkeerkaart voor personen met een handicap beschik kan ik met opgave van mijn kaartnummer alleen een kortlopend recht registeren</br> </br> Ik bel naar het gratis nummer Na het welkomstbericht krijg ik de vraag om mij aan te melden met kaartnummer en code ik meld mij aan met kaartnummer, door dit in te spreken of via klavier Bij de aanmelding wordt meteen gecontroleerd of ik een houder ben van een federale parkeerkaart voor personen met een handicap</br> </br> Ik SMS naar een gratis nummer om een kortlopend digitaal parkeerrecht te creëren Ik typ kaartnummer#code#nummerplaat# Er wordt gecontroleerd of de combinatie kaartnummer+code geldig is </br> </br> Ik begeef mij naar een lokaal loket van eender welk Belgisch lokaal bestuur De medewerker van het lokaal bestuur logt in in de webapplicatie De medewerker van lokaal bestuur meld mij aan in de webapplicatie via mij eID of kaartnummer + code Bij de aanmelding wordt meteen gecontroleerd of ik een houder ben van een federale parkeerkaart voor personen met een handicap in de webapplicatie krijg ik meteen te zien aan welke nummerplaat het actieve parkeerrecht hangt. Dit kan een langlopend of kortlopend recht zijn. Ik krijg ook meteen de 5 laatste gebruikte nummerplaten te zien die aan het recht werden gekoppeld met hun respectievelijk datum en duurtijd. Ik de webapplicatie kan ik ook een nummerplaat opgeven of wijzigen. Als ik over een buitenlands Europees model parkeerkaart voor personen met een handicap beschik kan ik met opgave van mijn kaartnummer alleen een kortlopend recht registeren</br> </br> Ik doe een aanvraag bij de federale overheid voor een nieuw analoog Europees model parkeerkaart voor personen met een handicap</br> </br> Ik geef mijn nummerplaat op voor een langlopend recht (eigen wagen, vaste chauffeur, mantelzorger..) via de webapplicatie, de native app, het intelligent telefoonsysteem (spraak/klavier) of een loket van een lokaal bestuur. Als ik van meerdere wagens gebruik maak kan ik een kortlopend digitaal parkeerecht creëren dat maximaal loopt tot het einde van de dag waarop het werd aangemaakt of tot er een andere nummerplaat wordt opgegeven. Ik kan dit doen via de webapplicatie, de native app, het intelligent telefoonsysteem (spraak/klavier), SMS of een loket van een lokaal bestuur Als ik een recht creëer via de website of de native app kan ik via een drop down menu uit mijn 5 laatst meest nummerplaten kiezen zodat ik niet steeds opnieuwe moet intypen. Ik kan zo dikwijls van nummerplaat wisselen als ik wil. Als houder van een niet-Belgische houder kan ik via de website of native app mijn nummerplaat opgeven waarna er een kortlopend recht wordt aangemaakt.</br> </br> mijn digitaal parkeerrecht wordt meteen actief mijn digitaal parkeerrecht is geldig in heel België </br> </br> bij het scannen van mij nummerplaat door een scanwagen of een pda wordt mijn actief recht gevonden in de parkeerrechtendatabase</br> </br> </br> Medium</br> </br> folder, website</br> </br> brief</br> </br> website</br> </br> native app</br> </br> intelligent telefoonsysteem</br> </br> SMS</br> </br> fysiek loket</br> </br> website MyHandicap</br> </br> website, app, intelligent telefoonsysteem, SMS, fysiek loket</br> </br> API</br> </br> </br> Ervaring</br> </br> </br> Frontoffice</br> </br> publicatie van het reglement na goedekeuring door gemeenteraad</br> </br> uitwerken boodschap en bepalen communicatiemix</br> </br> afleveren van het bericht</br> </br> https://webpagina.be </br> </br> 0800 nummer met verkorte nummering</br> </br> SMS nummer</br> </br> opgeven nummerplaat voor langlopend of kortlopend recht</br> </br> </br> Backoffice</br> </br> controle of de aanvrager of gemachtigde de houder is van Belgische federale parkeerkaart indien aanmelden met eID/ITSME, API bevraging via MAGDA naar DCGHAN indien aanmelden met kaartnummer+code, API bevraging naar Handi2park</br> </br> controle of de aanvrager of gemachtigde dehouder is van Belgische federale parkeerkaart indien aanmelden met eID/ITSME, API bevraging via MAGDA naar DCGHAN indien aanmelden met kaartnummer+code, API bevraging naar Handi2park</br> </br> controle of de aanvrager houder is van een federale parkeerkaart aanmelden met kaartnummer+code, API bevraging naar Handi2park</br> </br> controle of de aanvrager houder is van een federale parkeerkaart aanmelden met kaartnummer+code, API bevraging naar Handi2park</br> </br> controle of de aanvrager houder is van Belgische federale parkeerkaart indien aanmelden met eID/ITSME, API bevraging via MAGDA naar DCGHAN indien aanmelden met kaartnummer+code, API bevraging naar Handi2park</br> </br> de nummerplaat wordt weggeschreven naar een klantendatabase en een parkeerrechten database aan de opgegeven nummerplaat wordt een codering van het soort recht gehangen; langlopend, kortlopend, kortlopend niet-Belg de datum en tijd waarop het het (nieuwe) actieve recht wordt aagevraagd wordt weggeschreven naar de klanten- en de parkeerrechtendatabase als het kortlopend recht wordt aangegaan met een GSM nummer, dan wordt dit nummer ook weggeschreven naar de klantendatabase als er al een parkeerrecht bestaat in de parkeerrechtendatabase wordt dit vervangen door een nieuw recht met de andere nummerplaat zodat er altijd maar één recht tegelijkertijd actief is</br> </br> </br> Verschil huidige aanpak (wanneer van toepassing)</br> </br> Nu in sommige gemeenten alleen via fysiek loket of op basis van een whitelist na het verkrijgen van een retributie</br> </br> </br> </br> van fysieke controle van een voorliggende kaart naar digitale controle met scanwagen of pda</br> </br> </br> </br> Succes-meting </br> </br></br> </br> Impact (uit impactmap)</br> </br> Meetpunt</br> </br> SMART specificatie</br> </br> Huidige waarde</br> </br> Doel waarde</br> </br> </br> Belgische en niet Belgische houders van een federale parkeerkaart voor personen met een handicap en een unieke federaal uitgreikte code die parkeert in een Belgische gemeente waarbij deze gebruik wil maken van het gemeentelijk regime betreffende parkeren met een parkeerkaart voor personen met een handicap (gratis, verminderd tarief..)</br> </br> …</br> </br> …</br> </br> …</br> </br> </br> </br> </br> Aantal Belgische houders houders van Europees model parkeerkaart voor personen met een handicap met een digitaal parkeerrecht </br> </br> Telling van het aantal unieke parkeerrechten in de parkeerrechtendatabase om de drie maanden</br> </br> 0</br> </br> 250000</br> </br> </br> </br> </br> Aantal niet-Belgische houders houders van Europees model parkeerkaart voor personen met een handicap met een digitaal parkeerrecht</br> </br> Telling van het aantal unieke parkeerrechten met buitenlandse nummerplaat in de parkeerrechtendatabase om de drie maanden</br> </br> 0</br> </br> geen streefwaarde, alleen meten</br> </br> </br> </br> </br> Substantieel minder aantal retributies wegens digitale waarneming zonder digitaal parkeerkrecht voor personen met een handicap</br> </br> Procentuele daling van het aantal retributies uitgeschreven wegens niet voorliggen parkeerkaart om de drie maanden voor een periode van een jaar na livegang</br> </br> 1</br> </br> 0,5</br> </br> </br> </br> </br> Substantieel minder aantal retributies wegens digitale waarneming wegens zonder digitaal parkeerrecht en niet voorliggen parkeerkaart.</br> </br> Procentuele daling van het aantal retributies uitgeschreven wegens niet voorliggen parkeerkaart om de drie maanden voor een periode van een jaar na livegang</br> </br> 1</br> </br> 0,5</br> </br> </br> </br> </br> Substantieel minder aantal GAS boetes wegens foutief parkeren op voorbehouden plaatsen voor personen met een handicap.</br> </br> Procentuele daling van het aantal GAS boetes uitgeschreven wegens het foutief parkeren op voorbehouden plaatste voor personen met een handicap om de 3 maanden voor een periode van een jaar na livegang</br> </br> 1</br> </br> 0,5</br> </br> </br> </br> </br> Substantieel minder GAS boetes voor fraude met oneigenlijke kaarten</br> </br> Procentuele daling van het aantal GAS boetes uitgeschreven wegens fraude met oneigenlijk gebruikter kaarten voor personen met een handicap om de 3 maanden voor een periode van een jaar na livegang</br> </br> 1</br> </br> 0,5</br> </br> </br> De Belgische en niet-Belgische houders van een Europees model parkeerkaart voor personen met een handicap die een digitaal parkeerrecht op nummerplaat creëren.</br> </br> </br> </br> </br> Aantal aanvragen dat via volledig digitale weg wordt ingediend</br> </br> Telling van het aantal digitale parkeerrechten dat niet via fysiek loket, mail, telefoonsysteem of SMS wordt aangemaakt om de drie maanden over de periode van één jaar</br> </br> 0</br> </br> 0,5</br> </br> </br> </br> </br> Aantal aanvragen voor een digitaal parkeerrecht dat via digitale drager (mail) wordt ingediend.</br> </br> Telling van het aantal digitale parkeerrechten dat niet via web, app, fysiek loket, telefoonsysteem of SMS wordt aangemaakt om de drie maanden over de periode van één jaar</br> </br> 0</br> </br> 0,05</br> </br> </br> </br> </br> Aantal digitale parkeerechten dat binnen de afgesproken termijn wordt aangemaakt.</br> </br> De mediaan van het aantal dagen tussen ontvangst van de aanvraag en de creatie van het digitale recht</br> </br> 0</br> </br> 2 dagen</br> </br> </br> </br> </br> Aantal aanvragen dat via het intelligent telefoonsysteem wordt ingediend.</br> </br> Telling van het aantal digitale parkeerrechten dat niet via web of app, fysiek loket, mail of SMS wordt aangemaakt om de drie maanden over de periode van één jaar</br> </br> 0</br> </br> 0,3</br> </br> </br> </br> </br> Aantal digitale parkeervergunningen dat door een medewerker van een gemeenteloket aangemaakt.</br> </br> Telling van het aantal digitale parkeerrechten dat niet via web of app, mail, telefoonsysteem of SMS wordt aangemaakt om de drie maanden over de periode van één jaar</br> </br> 0</br> </br> 0,25</br> </br> </br> </br> </br> Aantal kortlopende digitale rechten dat per SMS wordt geregistreerd</br> </br> Telling van het aantal digitale parkeerrechten dat niet via web of app, mail, telefoonsysteem wordt aangemaakt om de drie maanden over de periode van één jaar</br> </br> 0</br> </br> 0,6</br> </br> </br> Wij willen dat een gevolmachtigde 'derde' (voogden bewindvoerders, maar derden met een volmacht van de gerechtigde) een aanvraag kan indienen voor een burger die handelingsonbekwaam is of door omstandigheden geen gebruik kan maken van de verschillende aangeboden registratieprocedures (digitaal niet voldoende beslagen of geen toegang tot IT infrastructuur...)</br> </br> </br> </br> </br> Aantal digitale parkeerrechten dat wordt aangevraagd met een rijksregisternummer dat niet overeenstemt met het rijkregisternummer van de kaarthouder maar waarvoor toch een relatie wordt gevonden met de persoon met een handicap</br> </br> Telling van het aantal aanvragen dat gebeurt op basis van eID/Itsme in combinatie met kaartnummer om de drie maanden voor een periode van een jaar</br> </br> 0</br> </br> geen streefwaarde, alleen meten</br> </br> </br> De parkeerwachters scannen een nummerplaat om zo het bezit en de geldigheid van een digitaal parkeerrecht voor personen met een handicap te controleren</br> </br> </br> </br> </br> Aantal voertuigen waarvoor een digitaal parkeerrecht voor personen met een handicap wordt gevonden</br> </br> Het procentuele verschil tussen het aantal voertuigen waarvoor een digitaal parkeerrechten voo personen met een handicap wordt gevonden versus het aantale visuele vaststellingen van een analoge kaart er worden uitgevoerd om de 3 maanden voor een periode van één jaar</br> </br> 0</br> </br> 0,5</br> </br> </br> </br> </br> Significante daling van het aantal voertuigen dat visueel gecontroleerd moet worden</br> </br> Het percentage van het aantal fysieke opvolgingen dat gebeurt als gevolg van het niet waarnemen van een parkeerrecht om de drie maanden voor een periode van één jaar</br> </br> 0</br> </br> 0,45</br> </br> </br> </br> Andere projectdocumenten </br> Geen documenten beschikbaar via de VLOCA kennishub.</br> </br> Interesse in dit project? </br> Gelieve contact op te nemen met gzg@vlaanderen.be.  +
• Introductie Deze pagina bevat een generi … Introductie </br> Deze pagina bevat een generiek overzicht van de verschillende beleidsdomeinen waar lokale overheden in aan de slag zijn. Dit overzicht zal gebruikt worden om de structurering van de VLOCA kennishub zo efficiënt en logisch mogelijk te maken. Enerzijds zijn er bovenlokale beleidsdomeinen, anderzijds zijn er de lokale beleidsdomeinen. Alle lokale beleidsdomeinen zijn gekoppeld aan één of meerdere bovenlokale beleidsdomeinen. </br> </br> Methodologie </br> Voor het maken van dit overzicht van beleidsdomeinen werd de volgende methodologie gevolgd: </br> </br> In een eerste stap werden de verschillende beleidsdomeinen van de 13 Vlaamse centrumsteden opgelijst, per centrumstad. Dit gaf een overzicht van alle beleidsdomeinen waarbij de centrumsteden aan de slag gaan. De assumptie is dat deze beleidsdomeinen representatief zijn voor de beleidsdomeinen van de andere Vlaamse lokale overheden. Het laagst aantal gevonden beleidsdomeinen bij één centrumstad was 25, het hoogste aantal was 135. </br> In een tweede stap werden alle beleidsdomeinen geanalyseerd en geclusters tot één lijst van beleidsdomeinen. Dit gaf een totaal van 65 beleidsdomeinen. Er werd hierbij, per beleidsdomein voor iedere stad gekeken naar identieke en/of zeer sterk gelijkaardige beleidsdomeinen in andere steden. </br> In een derde stap werden de bovenlokale beleidsdomeinen bekomen door te gaan kijken naar de beleidsdomeinen van de Vlaamse overheid, en werden deze licht aangepast om als bovenlokale beleidsdomeinen te fungeren. Dit gaf in totaal 11 bovenlokale beleidsdomeinen. </br> In een vierde stap werden de 64 lokale beleidsdomeinen gekoppeld aan de 11 bovenlokale beleidsdomeinen, wat resulteerde in het onderstaande overzicht van beleidsdomeinen. </br> Deze lijst zal, naast de co-creatie (hieronder meer), bijgewerkt worden - waar nodig - wanneer nieuwe besturen worden aangesteld op het lokale niveau. </br> </br> Co-creatie </br> Dit overzicht kwam tot stand aan de hand van de hierboven beschreven methodologie. Medewerkers van lokale besturen, en andere geïnteresseerden en experten, zijn vrij om dit overzicht aan te passen al naar gelang de noden. Er dient rekening mee gehouden te worden dat dit een generiek overzicht is, en dat een overzicht specifiek gebonden aan de beleidsdomeinen van iedere individuele lokale overheid niet mogelijk is/was. </br> </br> Overzicht Beleidsdomeinen </br> De onderstaande tabel bevat een overzicht van alle beleidsdomeinen (lokaal - rijen / bovenlokaal - kolommen), met de connectie tussen het lokale beleidsdomein en het bovenlokale beleidsdomein. </br> </br> </br> </br> </br> </br> </br> </br> Algemeen bestuur,</br> binnenlandse zaken & </br> justitie</br> </br> </br> Buitenlandse</br> zaken</br> </br> </br> Financiën</br> & begroting</br> </br> </br> Economie, wetenschap</br> & innovatie</br> </br> </br> Onderwijs</br> & vorming</br> </br> </br> Welzijn, volksgezondheid</br> & gezin</br> </br> </br> Cultuur, jeugd,</br> sport & media</br> </br> </br> Werk & sociale</br> economie</br> </br> </br> Landbouw</br> & visserij</br> </br> </br> Omgeving</br> </br> Mobiliteit & openbare werken</br> </br> </br> Afvalbeleid</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> Bestuurzaken & administratieve vereenvoudiging</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Bevolking & burgerzaken</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Bibliotheek</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Buurt- & wijkwerking</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Ceremonieën, plechtigheden & begrafenissen</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Circulaire economie & korte keten</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Consumenten & consumptiebeleid</br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> X</br> </br> </br> </br> </br> </br> </br> Cultureel erfgoed (roerend & immaterieel erfgoed)</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Cultureel & administratief archief</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Cultuur</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Dierenwelzijn</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> Digitalisering, ICT en Smart City</br> </br> X</br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Diversiteit & gelijke kansen</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Economie & ondernemen (omvat o.a. sociale economie, werk, duurzaam ondernemen)</br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> X</br> </br> </br> </br> </br> </br> </br> Energie</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> Eredienten</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Europese & internationale samenwerking</br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Facilitair beheer (omvat o.a. informaticahardware, patrimoniumbeheer, elektromechanica, economaat & wagenpark)</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Financiën & begroting</br> </br> X</br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Gebiedsgerichte werking</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> X</br> </br> </br> </br> </br> Gezin & kinderopvang</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Havenbeleid</br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> Inburgering & integratie</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Inname openbaar domein</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Intergemeentelijke samenwerking & intercommunales</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Internationale solidariteit</br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Jeugd- & jongerenbeleid</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Juridische zaken</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Klimaat & duurzaamheid</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> Landbouw & visserij</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> Lokale handel, horeca & centrummanagement</br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> Markten & foren</br> </br> X</br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Milieu</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> Mobiliteit & verkeer</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> Natuur</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> Onderwijs</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Onroerend erfgoed</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Openbaar domein & groenbeleid</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> X</br> </br> </br> Openbare gezondheid</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Openbare werken</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> Opvoedingsbeleid</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Ouderenzorg</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Parkeerbeleid</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> X</br> </br> </br> Participatiebeleid</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Personeel & organisatie</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Politie & brandweer</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Preventie & bescherming</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Regionale samenwerking</br> </br> X</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Seniorenbeleid</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Sociale zaken & welzijn</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Sportbeleid</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Stadsmarketing, interne & externe communicatie & onthaal</br> </br> X</br> </br> X</br> </br> X</br> </br> X</br> </br> X</br> </br> X</br> </br> X</br> </br> X</br> </br> X</br> </br> X</br> </br> X</br> </br> </br> Stadsontwikkeling</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> Strategische planning</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Stedenbouw, ruimtelijke ordening & omgevingsvergunning</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> Studentenbeleid</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Subsidiewerving</br> </br> X</br> </br> </br> </br> X</br> </br> X</br> </br> X</br> </br> X</br> </br> X</br> </br> X</br> </br> X</br> </br> X</br> </br> X</br> </br> </br> Toerisme</br> </br> X</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Veiligheidsbeleid, noodplanning, GAS & crisisbeleid</br> </br> X</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Verkiezingen</br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> Werkbeleid</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> </br> </br> </br> </br> Woonbeleid</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X</br> </br> </br> </br> </br> Zorg- & ziekenhuisbeleid</br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> </br> X X Woonbeleid X Zorg- & ziekenhuisbeleid X  +
• Introductie Dit draaiboek kan jou en je … Introductie </br> Dit draaiboek kan jou en je organisatie helpen om te komen tot evidence-based decision making in een beslissingproces . Door de hieronder beschreven flow te doorlopen kan je het beslissingsproces van je organisatie verder gaan ondersteunen. </br> Deze flow detaileert het volledige process doorheen het platform & hoe het een beslissingsproces kan ondersteunen vanuit verschillende perspectieven. De oplossing zal niet één enkele applicatie zijn. Maar wel een combinatie van verschillende aspecten</br> </br> Technologische componenten </br> Een andere mindset om met data te werken waar data centraal staat </br> Gealigneerde bedrijfsprocessen </br> De juiste rollen, verantwoordelijkheden & skills </br> Het schema is opgedeeld in 4 stroken, hieronder in meer detail uitgelegd.</br> </br> B voor Business </br> D voor Data </br> M voor Modellen </br> A voor Applicaties </br> Voor iedere strook zijn een aantal actie gedefinieerd die je kan doorlopen. </br> De BPMN werd opgesteld in MIRO, een webapplicatie die met een kosteloze licentie toelaat deze BPMN te importeren, te visualiseren en aan te passen. Hoe dit kan, vind je terug op de community van Miro . </br> </br> Strook 1: Business perspectief </br> B01 =  Business Motivation & Goals </br> Specifieer heel duidelijk wat het problem is. </br> Waarom is het relevant? </br> Welke outcome is wenselijk? </br> Hoe zal het resultaat geëvalueerd worden? </br> B02 =  Business Glossary </br> Definieer alle termen die gebruikt worden nauwgezet & zo wetenschappelijk mogelijk. </br> Leg alle termen vast (wanneer spreekt men over geluidsoverlast, hoe definieer je ‘bereikbaarheid’ van de horeca, ...). </br> Op welke modaliteiten willen we focussen? </br> Welke metriek gebruiken we, NO2, PM1, PM2.5, BelAQI? Decibels? Is alles even storend? Verkeersintensiteit of snelheid? (e.g. #/min, #/m, ...) </br> Kunnen we patronen afleiden a.h.v. klachten (e.g. welke straten, welke timeslots (AM of PM), ...)? </br> Identificeer de geografische regio (de stad Brugland, of enkele wijken, ...). </br> Zijn er bepaalde standaarden die limieten vastleggen van ‘te veel’ verkeer, lawaai of slechte lucht? </br> Kunnen we dit vergelijken met andere buurten of gemeenten? </br> B03 = Zoek data die relevant zijn voor de business case </br> Onderzoek welke data gebruikt kan worden om te bewijzen dat er inderdaad een significant probleem is. </br> E.g. aantal klachten, historische groei van verkeersintensiteit, ... </br> Eerst en vooral data die gebruikt kan worden om het problem te valideren. </br> Dezelfde data zal later het beslissingsproces ondersteunen om het probleem op te lossen. </br> B04 = Definieer queries bouwend op de vorige stap </br> Bereken de verkeersintensiteit, luchtkwaliteit & geluidsdruk </br> Gedurende de ochtend-spits vs. de avond-spits </br> Week dagen vs. weekends </br> Hoofdwegen vs. secundaire Wegen </br> Schoolvakanties vs. werkdagen </br> Evolutie over de tijd heen </br> Drukte per wijk ~ De eigenlijke number-crunching </br> Deze stappen zijn NIET optioneel. Ze zijn cruciaal als startpunt in het ‘evidence-based decision-making’ process. </br> </br> Strook 2: Data Engineering perspectief </br> D01 = Verkrijg de data </br> Krijg toegang tot de data die nodig was om de business case te ondersteunen </br> E.g. downloads, extracts, API , pipelines, ... </br> Linkt sterk met de FAIR data principes </br> D02 = Evalueer de datasets </br> Technische stap die hand in hand gaat met B04, schrijf queries </br> D03 = Breng de dataset under governance </br> Als beslist wordt dat de dataset inderdaad nuttig is in deze exploratieve fase, kan de volgende stap van start gaan (e.g. raw files on datalake, queried with notebooks) </br> Ze worden onder governance gebracht zodat men ze structureel kan gebruiken, i.p.v. enkel ad-hoc (link met B02) </br> D05 = Data collection </br> Kickstart (continue) collectie van data naar het datalakehouse </br> Deze stap vervormt de datasets om tot echte assets </br> De data zal niet enkel in notebooks, gedeconnecteerde analyzes of scripts gelaten worden, maar alles kan hergebruikt worden in toekomstige flows én wordt continu bijgewerkt. </br> D06 = Data projection </br> Niet enkel op de brondata, maar ook op de data projections of feature engineering </br> Voer de relevante queries (and possibly persist) uit </br> E.g. The specific query for rainy days, summer holidays, ... </br> E.g. Feature engineering to add relevant predictors </br> Strook 3: Modelleringsperspectief </br> We begrijpen reeds de business case & hebben de data onder controle </br> De business case is uitgedrukt in uniforme termen & wordt geverifieerd door data. </br> De datasets & queries zijn gemanagede assets die transparent & efficient gebruikt kunnen worden. </br> M1, M2 & M3 = Zoek & bekom het juiste model voor de use case </br> e.g. Brugge context, multiple model providers evaluated </br> M4 & M5 = Probeer modellen & data management te ontkoppelen </br> Geen hidden feature engineering als deel van het model. </br> Werk beter met een transparente signature die inputs vastlegt. </br> Werk niet met hardcoded flatfiles, maar met data under management. </br> M6 = Train, score & evalueer meerdere verises van het model </br> e.g. weekdag model vs. weekend model </br> e.g. zomer vs. winter model </br> e.g. fiets vs. auto model </br> e.g. SVM-algorithme vs. FF Neural Network </br> Strook 4: Applicatie perspectief </br> Niet enkel één model run, wel: </br> Meerdere modellen, cross-domain </br> Verschillende scenario’s </br> Of zelfs meerdere versies van hetzelfde model </br> Alles werkt transparant </br> Op welke data was het model getraind? </br> Op welke data is het gevalideerd? </br> Welke bewerkingen worden uitgevoerd? </br> Wat kan ik verwachten als output? </br> Zodat we het resultaat niet enkel visueel kunnen interpreteren </br> Maar ook wetenschappelijk gebaseerd op de input & output datasets. </br> Dit alles wordt terug gelinkt aan de originele business case. </br> Het is een process dat zich herhaalt en geen lineair process dat je 1 keer doorloopt.doorloopt.  +
• Introductie Dit onderzoeksproject had al … Introductie </br> Dit onderzoeksproject had als doelstelling om te analyseren hoe men voor een bredere en meer diverse groep burgers een vlottere, toegankelijker en eenvoudigere betrokkenheid bij het beleid kan aanbieden. Het project werd getrokken door Gent en werd uitgevoerd in samenwerking met Oudenaarde en Genk.</br> Het project resulteerde in 2 eindrapporten met aanbevelingen, conclusie en nieuwe inzichten alsook de ontwikkeling van een prototype.</br> </br> </br> Pitch </br> Voor een bredere en meer diverse groep burgers (en bij uitbreiding burgerinitiatieven, organisaties, bedrijven, instellingen,..) </br> biedt deze vernieuwde aanpak </br> een vlottere, toegankelijker, en eenvoudigere betrokkenheid bij het beleid , </br> door meer asynchrone, plaats onafhankelijke, visuele, periodiekere participatievormen aan te bieden . </br> In tegenstelling tot de huidige manier van werken is deze aanpak vlotter, eenvoudiger, toegankelijker, en opener,.. .</br> </br> Impactmap </br> </br> </br> Blauwdruk </br> Succes-meting </br> </br></br> </br> projectdoelstelling</br> </br> doelgroep</br> </br> impact</br> </br> meetpunt</br> </br> waarde</br> </br> </br> nieuwe digitale oplossingen bevorderen de betrokkenheid van een bredere en diverse groep burgers bij het beleid</br> </br> burgers (en in uitbreiding georganiseerd in burgerinitiatieven, wijkorganisaties, middenveldorganisaties, onderwijsinstellingen en bedrijven, … )</br> </br> meer en diverse burgers worden bereikt omdat de digitale oplossingen zorgen voor: 1, een grotere toegankelijheid tot participatievormen (asynchroon, plaatsonafhankelijk en via nieuwe kanalen), en 2, een eenvoudigere communicatie (door audio en beeldend te werken) en 3, door een en-en verhaal (combinatie offline en online)</br> </br> verhoging van het aantal respondenten op onze bestaande platformen (participatieplatform) en in digitale participatietrajecten</br> </br> bij een experiment rond project naamgeving en onboarden sociale media op participatieplatform kregen we meer respons dan voorheen</br> </br> </br> meten van het profiel van deelnemers die betrokken zijn via een digitaal instrument</br> </br> door meer respondenten leiden we af dat we andere profielen bereiken</br> </br> </br> verhoging van het aantal diensten dat enthousiast is en vertrouwen heeft om aan de slag te gaan met digitale oplossingen en experimenten</br> </br> dienst communicatie, jeugddienst en beleidsparticipatie (wijkregie) is bereid gevonden om digitale experimenten op te zetten</br> </br> </br> aantal nieuwe experimenten van digitale participatieprojecten op basis van het eindrapport</br> </br> 3 nieuwe projecten zijn opgestart</br> </br> </br> meten van het profiel van deelnemers die betrokken zijn via een digitaal instrument</br> </br> door meer respondenten leiden we af dat we andere profielen bereiken</br> </br> </br> de tevredenheid, toegankelijkheid en gebruiksvriendelijkheid van het prototype worden postiever beoordeeld tov evaluatie bestaande platformen</br> </br> resultaten van de in-lab testing zijn postief (neergeschreven in eindrapprt fase 2)</br> </br> </br> nieuwe digitale oplossingen ondersteunen het betrekken van een bredere en meer diverse groep van burgers bij het beleid</br> </br> lokaal bestuur</br> </br> een bredere en meer diverse input op het beleid en een breder maatschappelijk debat zorgt voor een meer gedragen beleid</br> </br> keuze voor de betrokken burgerprofielen in het burgerpanel</br> </br> duidelijke keuze voor jongeren in de focusgroep</br> </br> </br> evaluatie van de input in het gelopen participatieproject (digitaal <-> analoog)</br> </br> rapport met de resultaten van het ingezette prototype naar bereik en toepassing , maar de meting van de input is moeilijk, gezien er weinig input is geweest</br> </br> </br> meerdere diensten zijn enthousiast en hebben vertrouwen om aan de slag te gaan met digitale oplossingen en experimenten</br> </br> dienst communicatie , jeugd en eigen team (wijkregie) is bereid gevonden om digitale experimenten op te zetten</br> </br> </br> </br> Andere projectdocumenten </br> Geen documenten beschikbaar via de VLOCA kennishub.</br> </br> Interesse in dit project? </br> Gelieve contact op te nemen via gzg@vlaanderen.be .ntact op te nemen via gzg@vlaanderen.be .  +
• Introductie Dit project had als doelstel … Introductie </br> Dit project had als doelstelling om een blauwdruk te ontwikkelen die toelaat de customer journey voor parkeren en GAS4 en GAS5 te digitaliseren. Het project werd getrokken door Genk en werd uitgevoerd in samenwerking met Vilvoorde. Verder werden ook de steden Antwerpen, Hasselt en Mechelen betrokken.</br> Het project resulteerde in een blauwdruk van de business modellen en de technische architectuur.</br> </br> Pitch </br> Voor parkeerklanten op het maaiveld en gedupeerden GAS4 en GAS5 </br> biedt deze vernieuwde aanpak </br> een volledig digitale customer journey , </br> door enkel nog gebruik te maken van digitale registratietechnologieën (app/sms) en in te zetten op een digitaal loket voor vragen en klachtenafhandeling . </br> In tegenstelling tot de huidige manier van werken is deze aanpak proactiever en klantvriendelijker, efficiënter en schept het de mogelijkheid om dossiers volledig digitaal op te volgen en af te handelen .</br> </br> Impactmap </br> </br> </br> Blauwdruk </br> </br></br> </br> Blauwdruk:</br> </br> E-Loket diensten voor parkeer- en GAS4/5-diensten</br> </br> </br> Fase</br> </br> Heden</br> </br> RB in PTR-pas via Mijn Burgerprofiel</br> </br> GAS in PTR-pas via Mijn Burgerprofiel</br> </br> White list in PTR-pas via Mijn Burgerprofiel</br> </br> IOD-parkeren in PTR-pas via Mijn Burgerprofiel</br> </br> IOD-parkeren in PTR</br> </br> </br> Interactiepunt</br> </br> Verschillend per gemeente, meestal per brief</br> </br> Ik heb ingelogd in Mijn Burgerprofiel (in eigen naam, of naam van de onderneming), de PTR-pas geopend en zie al mijn parkeerretributies over het hele grondgebied van Vlaanderen met hun betalingsstatus, klachtenstatus, Ik kan de details per dossier raadplegen, de nodige betalingen doorvoeren en klachten neerleggen/vragen stellen/betwisten.</br> </br> Ik heb ingelogd in Mijn Burgerprofiel (in eigen naam, of naam van de onderneming), de PTR-pas geopend en zie al mijn GAS4/5-boetes over het hele grondgebied van Vlaanderen met hun betalingsstatus, klachtenstatus, Ik kan de details per dossier raadplegen, de nodige betalingen doorvoeren en klachten neerleggen/vragen stellen/betwisten.</br> </br> Ik heb ingelogd in Mijn Burgerprofiel (in eigen naam, of naam van de onderneming), de PTR-pas geopend en zie al mijn bewonerskaarten, werknemersvergunningen, over het hele grondgebied van Vlaanderen met hun betalingsstatus, klachtenstatus, Ik kan de details per dossier raadplegen, de nodige betalingen doorvoeren en klachten neerleggen/vragen stellen/betwisten.</br> </br> Ik heb ingelogd in Mijn Burgerprofiel, de PTR-pas geopend en zie mijn vergunningen inname openbaar domein over het hele grondgebied Vlaanderen. Ik kan de details per dossier raadplegen, de nodige betalingen doorvoeren en klachten neerleggen/vragen stellen/betwisten.</br> </br> Geen, verloopt automatisch</br> </br> </br> Medium</br> </br> /</br> </br> Eender welk medium dat toegang geeft tot Mijn Burgerprofiel (Stadsapp, MijnBurgerprofiel-app, website van de lokale overheid, ) + geregistreerd mailadres</br> </br> Eender welk medium dat toegang geeft tot Mijn Burgerprofiel (Stadsapp, MijnBurgerprofiel-app, website van de lokale overheid, ) + geregistreerd mailadres</br> </br> Eender welk medium dat toegang geeft tot Mijn Burgerprofiel (Stadsapp, MijnBurgerprofiel-app, website van de lokale overheid, ) + geregistreerd mailadres</br> </br> Eender welk medium dat toegang geeft tot Mijn Burgerprofiel (Stadsapp, MijnBurgerprofiel-app, website van de lokale overheid, ) + geregistreerd mailadres</br> </br> De PTR-pas</br> </br> </br> Ervaring</br> </br> </br> Frontoffice</br> </br> RB's via brief GAS via brief White list via brief/mail IOD-vergunning via brief/mail Klachten/betwistingen via specifieke platformen, telefonisch of fysiek</br> </br> - Melding via e-mail van nieuw beschikbare retributie - Lijst van retributies + details beschikbaar via Mijn Burgerprofiel</br> </br> - Melding via e-mail van nieuw beschikbare GAS-boete - Lijst van boetes + details beschikbaar via Mijn Burgerprofiel</br> </br> - Melding via e-mail van nieuw beschikbare White listing - Lijst van White listing + details beschikbaar via Mijn Burgerprofiel</br> </br> - Melding via e-mail van nieuw beschikbare IOD-vergunning - Lijst van IOD-vergunningen + details beschikbaar via Mijn Burgerprofiel</br> </br> /</br> </br> </br> Backoffice</br> </br> '- Brieven opmaken & versturen via postdienst - Retributies manueel afchecken tegen IOD-vergunning</br> </br> /</br> </br> /</br> </br> /</br> </br> /</br> </br> /</br> </br> </br> Verschil huidige aanpak (wanneer van toepassing)</br> </br> /</br> </br> Elk individu heeft zicht op al zijn/haar retributies over het hele grondgebied van Vlaanderen, via Mijn Burgerprofiel. Er kunnen geen fouten meer gebeuren via post. Burgers moeten niet meer naar een individuele gemeente voor vragen/info/klachten, maar kunnen dit digitaal afhandelen.</br> </br> Elk individu heeft zicht op al zijn/haar GAS4/5-boetes over het hele grondgebied van Vlaanderen, via Mijn Burgerprofiel. Er kunnen geen fouten meer gebeuren via post. Burgers moeten niet meer naar een individuele gemeente voor vragen/info/klachten, maar kunnen dit digitaal afhandelen.</br> </br> Elk individu heeft zicht op al zijn/haar white listing over het hele grondgebied van Vlaanderen, via Mijn Burgerprofiel. Er kunnen geen fouten meer gebeuren via post. Burgers moeten niet meer naar een individuele gemeente voor vragen/info/klachten, maar kunnen dit digitaal afhandelen.</br> </br> Elk individu heeft zicht op al zijn/haar IOD-vergunningen over het hele grondgebied van Vlaanderen, via Mijn Burgerprofiel. Er kunnen geen fouten meer gebeuren via post. Burgers moeten niet meer naar een individuele gemeente voor vragen/info/klachten, maar kunnen dit digitaal afhandelen.</br> </br> De gegevens IOD worden hergebruikt in het PTR zodoende niet zowel een vergunning te betalen als een retributie te moeten ontvangen (bij administratieve onoplettendheid nu)</br> </br> </br> </br> Andere projectdocumenten </br> Geen documenten beschikbaar via de VLOCA kennishub.</br> </br> Interesse in dit project? </br> Gelieve contact op te nemen via gzg@vlaanderen.be . op te nemen via gzg@vlaanderen.be .  +
• Introductie Dit project, dat liep van 1 … Introductie </br> Dit project, dat liep van 1 april 2022 tot 31 maart 2023, had als doelstelling om te onderzoeken wat de mogelijkheden zijn om een plaats- en kanaalonafhankelijke sterke authenticatie mogelijk te maken. Het project werd getrokken door Gent en werd uitgevoerd in samenwerking met Roeselare.</br> Het project resulteerde in een gebruikersonderzoek en de ontwikkeling van een prototype.</br> </br> </br> Pitch </br> Voor alle burgers en ondernemers die tijdens een klantencontact, anders dan een fysiek bezoek, hun identiteit moeten bewijzen vanuit veiligheidsoverwegingen </br> biedt deze nieuwe aanpak </br> de mogelijkheid om zich sterk te authenticeren ongeacht het gekozen kanaal , </br> door een PoC uit te werken rond hoe we sterke authenticatie kunnen integreren bij kanalen zoals in eerste instantie videobellen en bij voorkeur uitbreidbaar naar telefonisch contact en chat . </br> In tegenstelling tot de huidige manier van werken is deze aanpak veiliger, betrouwbaarder, privacyvriendelijker, inclusiever, breder toegankelijk en meer plaats- en kanaalonafhankelijk .</br> </br> Impactmap </br> </br> </br> Blauwdruk </br> </br></br> </br> Pagina</br> </br> Blauwdruk:</br> </br> Digitale Balie (theoretische blauwdruk)</br> </br> </br> </br> </br> Fase</br> </br> Afspraak maken voor een videogesprek</br> </br> Openen van het videogesprek</br> </br> Het voeren van een videogesprek</br> </br> Formele handelingen tijdens het videogesprek</br> </br> Afronding van het videogesprek</br> </br> Evaluatie van het videogesprek</br> </br> </br> </br> </br> Interactiepunt</br> </br> De burger/onderneming/vereniging heeft een vraag met betrekking tot een dienst/product (1) of wenst gebruik te maken van een bepaalde dienst/product (2). Hiertoe kan hij/zij via zijn voorkeurskanaal (digitaal/fysiek/telefonisch) een afspraak maken tot het voeren van een videogesprek. Mogelijke uitdaging is de captatie van het correcte e-mailadres bij een gesprek per telefoon of fysiek. De burger/onderneming/vereniging krijgt een e-mailbericht waarin een link staat naar het videogesprek. Er is een testomgeving waar de burger indien hij wil al eens vooraf kan testen of hij vlot de verbinding kan maken. Zo hoeft hij niet zenuwachtig zijn de eerste keer dat hij een afspraak heeft voor een videogesprek of het wel zal lukken. Eén dag voor de afspraak ontvangt de burger/vereniging/onderneming een herinnering (mail/sms) van de afspraak. </br> </br> De burger/vereniging/onderneming opent de link en komt automatisch, zonder authentificatie terecht in de video-omgeving van de gemeente. Hij moet vooraf geen toepassing downloaden om te kunnen videobellen. Hij/Zij wacht hier op de loketmedewerker die de digitale balie bemant. Op het afgesproken uur start de medewerker het videogesprek op. Als de medewerker klaar is met de vorige burger en hij ziet dat de burger aanwezig is, kan hij vroeger het videogesprek opstarten. Wanneer de burger graag een extra persoon betrekt (tolk, mantelzorger, ...) dan kan deze persoon vlot mee aansluiten door hem de link te bezorgen. De baliemedewerker bemant een digitaal balieloket vanuit een soort van 'vaste zetel' in het digitale loket. Hierbij dient hij/zij niet telkens van omgeving te veranderen bij het opstarten van een nieuw gesprek met een burger. De burger wordt hierbij in een virtuele wachtkamer gezet waarbij de baliemedewerker van hieruit het gesprek op professionele wijze kan opstarten.</br> </br> De burger/vereniging/onderneming gaat digitaal en plaatsonafhankelijk in gesprek met desbetreffende beleidsmedewerker om een antwoord te krijgen op zijn specifieke vragen. Daarbijkomend heeft de burger de mogelijkheid om via het videogesprek een beroep te doen op een breed gamma van producten en diensten.</br> </br> In functie van het product is het mogelijk dat gedurende het videogesprek er bijkomende handelingen nodig zijn: - Het ondertekenen van documenten - Het authenticeren van zichzelf om een beroep te kunnen doen op de dienst/product - Het uitvoeren van een betaling om toegang te krijgen tot een dienst/product - Het uitwisselen van informatie zodoende het mogelijk is om realtime over de meest accurate gegevens/informatie te beschikken Al deze verschillende toepassingen/functionaliteiten zorgen ervoor dat de burger indien hij/zij dit wenst een product digitaal kan aanvragen en afhandelen.</br> </br> - De burger/vereniging/onderneming en beleidsmedewerker beëindigen het videogesprek en bespreken met elkaar wat de volgende acties zijn (indien van toepassing). Indien nodig plannen ze een vervolgafspraak in. De burger kan na het beëindigen van het gesprek onmiddellijk verder doen met wat hij wil. Hij moet zich niet eerst weer van het gemeentehuis/stadskantoor naar huis verplaatsen.</br> </br> - Na het videogesprek wordt aan de burger gevraagd of hij/zij wenst te participeren aan een bevraging omtrent het videogesprek: (1) Niet dwingend en volledig vrijwillig (2) Bevraging bij burger omtrent gebruik/klantentevredenheid/laagdrempeligheid/ mogelijke verbeterpunten van het videogesprek - Burger heeft de keuze om te participeren aan dit feedbackmoment of om de digitale balie te verlaten en het gesprek definitief af te ronden.</br> </br> </br> Medium</br> </br> Via loket, telefoon, mail, website/Afsprakenmodule/ Mijn Burgerprofiel en het eigenlijk gesprek via de daarvoor voorziene software</br> </br> Website/ Digitale omgeving digitale balie (software)</br> </br> - het platform waarop de videogesprekken plaatsvinden</br> </br> - het platform waarop de videogesprekken plaatsvinden en de daarbijkomende connecties die worden gemaakt om documenten uit te wisselen, documenten te ondertekenen, betalingen uit te voeren, formulieren in te voeren, de nodige authentificaties uit te voeren enzovoort.</br> </br> - Het platform waarop de videogesprekken plaatsvinden</br> </br> - Idealiter in de omgeving (software) waarbinnen de digitale balie plaats heeft, suboptimaal wordt er na het gesprek een link doorgestuurd waarbij hij/zij wordt doorgestuurd naar een andere externe omgeving</br> </br> </br> Ervaring</br> </br> </br> Frontoffice</br> </br> - Afleveren van het bevestigingsbericht en herinneringsbericht van de afspraak</br> </br> - Ambtenaar bereidt zich voor in desbetreffende vraag/dossier van de klant - De ambtenaar zorgt ervoor dat hij/zij op tijd aan het videogesprek begint en in geval van verlet door uitzonderlijke omstandigheden de burger tijdig en correct hiervan op de hoogte brengt. </br> </br> - De ambtenaar gaat actief het gesprek aan met de klant en beantwoordt zijn vragen en behoeften zo goed mogelijk. Hierbij is het mogelijk dat de ambtenaar één van volgende handelingen stelt binnen de digitale balie: - Het controleren van de identiteit van de burger (identificatie/authentificatie) - Het mogelijk maken van het uitwisselen van documentatie betreffende de vraag en nood van de burger - Het toepassen van een betaalsysteem waardoor voor bepaalde producten en diensten de betaling onmiddellijk kan uitgevoerd worden - Het toepassen van een systeem waarbij de klant de nodige aanvraagformulieren en - Mogelijkheid om 'live' dingen (of ad hoc) te tonen bv bezwaar verwaarloosde woning?</br> </br> - De ambtenaar gaat actief het gesprek aan met de klant en beantwoordt zijn vragen en behoeften zo goed mogelijk. Hierbij is het mogelijk dat de ambtenaar één van volgende handelingen stelt binnen de digitale balie: - Het controleren van de identiteit van de burger (identificatie/authentificatie) - Het mogelijk maken van het uitwisselen van documentatie betreffende de vraag en nood van de burger - Het toepassen van een betaalsysteem waardoor voor bepaalde producten en diensten de betaling onmiddellijk kan uitgevoerd worden - Het toepassen van een systeem waarbij de klant de nodige aanvraagformulieren en - Mogelijkheid om 'live' dingen (of ad hoc) te tonen bv bezwaar verwaarloosde woning?</br> </br> - De burger/vereniging/onderneming en beleidsmedewerker beëindigen het videogesprek waarna de ambtenaar de verdere afhandeling voert van het gesprek, dit kan verscheidene vormen aannemen i.f.v. de vraag of het product (verslag, activatie bepaald product,...).</br> </br> - Bij het afsluiten van het gesprek wordt er automatisch via een pop-upscherm de burger attent gemaakt om feedback te geven over het videogesprek.</br> </br> </br> Backoffice</br> </br> - Check of er nog afspraken vrij staan - Genereren van bericht in CRM/via het afsprakensysteem - Automatisch versturen bericht via CRM/afsprakensysteem - Automatische genereren van toengangslink voor het videogesprek (koppeling met toepassing die videogesprekken voert) - Nagaan of het verstuurde herinneringsbericht correct afgeleverd is (1) en gelezen door desbetreffende contact (2).</br> </br> - De burger wordt automatisch verbonden met de omgeving waarbinnen het videobellen zal plaatsvinden zonder nog bijkomende gegevens of stappen te ondernemen. - Permissie tot gebruik micro en camera in browser op laptop of op mobiel device via een tool met duidelijke begeleiding en mogelijkheid tot het uittesten van de microfoon en camera.</br> </br> - De ontwikkeling van de nodige functionaliteiten opdat iedereen hiermee effectief aan de slag kan. Daarbijkomend dient er ook een voortdurend onderhoud plaats te vinden van het systeem zodat dit steevast in optimale condities operationeel blijft. - De nodige koppelingen voorzien tussen de website van de gemeente, het videoplatform en de verschillende functionaliteiten van de digitale balie (authentificatie, documenten uitwisselen, handtekenen en betaling uitvoeren - Ervoor zorgen dat ieder dossier in de CRM wordt vastgelegd</br> </br> - De ontwikkeling van de nodige functionaliteiten opdat iedereen hiermee effectief aan de slag kan. Daarbijkomend dient er ook een voortdurend onderhoud plaats te vinden van het systeem zodat dit steevast in optimale condities operationeel blijft. - De nodige koppelingen voorzien tussen de website van de gemeente, het videoplatform en de verschillende functionaliteiten van de digitale balie (authentificatie, documenten uitwisselen, handtekenen en betaling uitvoeren - Ervoor zorgen dat ieder dossier in de CRM wordt vastgelegd</br> </br> - Automatisch omgaan met gegevens/informatie (opslaan gesprek/wissen gesprek, wissen unieke link,…) via de gangbare security protocols.</br> </br> - Het opzetten van een bevraging alsook de mogelijkheid om op eenvoudige wijze hier analyses op uit te voeren op het juiste niveau</br> </br> </br> Verschil huidige aanpak (wanneer van toepassing)</br> </br> Burger kan via een verscheidenheid van kanalen een digitale afspraak maken waardoor zowel de burger als de medewerker plaatsonafhankelijk dit videogesprek kan aangaan. Indien dit gesprek fysiek diende door te gaan moest de burger zich fysiek begeven naar het gemeentehuis/dienstverleningscentrum. Daarbijkomend door een digitale balie aan te bieden met verschillende functionaliteiten (betalen, documenten uitwisselen, ...) kan je ook met een breed aanbod naar de burger stappen waardoor de klant in één gesprek meerdere producten/diensten en vragen kan stellen en samen bespreken/behandelen.</br> </br> </br> </br> Succes-meting </br> </br></br> </br> Impact (uit impactmap) </br> </br> Doelgroep </br> </br> Meetpunt </br> </br> SMART specificatie </br> </br> Huidige waarde </br> </br> Doel waarde </br> </br> </br> De burger/ondernemer/vereniging kan van op een afstand een gesprek aangaan met een medewerker. Er is oogcontact tijdens het gesprek. Hierdoor voelt de dienstverlening nog steeds persoonlijk aan en is er geen afstand met de dienstverlenende overheid. De bezoeker van een digitale balie kan op een flexibele, gemakkelijke, empathische en veilige wijze efficiënt in interactie gaan met het lokaal bestuur. Een pos bij-effect is dat geen verplaatsing in praktijk vaak ook een voorkomen van CO2 afdruk (milieu, parkeren, ...) impliceert.</br> </br> Organisatie </br> </br> Het aantal gesprekken dat we voeren via de digitale balie in vergelijking met de andere kanalen</br> </br> We willen dat binnen 5 jaar min 35% van de gesprekken via de fysieke balie die ook kunnen verlopen via de digitale balie via dit nieuwe kanaal verlopen. We wensen heel bewust niet te recruteren onder de burgers die reeds zelfstandig aan de slag gaan met online formulieren.</br> </br> 0</br> </br> 0,35</br> </br> </br> Burger/Onderneming/ Vereniging (klant) </br> </br> Een vermindering van het aantal verplaatsingen door de klant naar het administratief centrum/ gemeentehuis</br> </br> We verwachten dat min 35% van de verplaatsingen naar het fysieke loket niet meer zullen moeten plaatsvinden door de invoering van de digtale balie</br> </br> 0</br> </br> 0,35</br> </br> </br> Een verhoogde klantentevredenheid op vlak van toegankelijkheid</br> </br> We verwachten een verhoogde klantentevredenheid (+20%) door het aanbieden van een digitale balie waardoor we een extra kanaal aanbieden waar burgers zich niet moeten voor verplaatsen.</br> </br> 0</br> </br> 0,2</br> </br> </br> Medewerker/ambtenaar </br> </br> Een verlaging van het aantal bezoekers aan de fysieke balies</br> </br> We verwachten een daling van 35% van het aantal bezoekers aan de fysieke balies voor producten en diensten die we ook via de digitale balie aanbieden.</br> </br> 0</br> </br> -35%</br> </br> </br> De medewerkers zijn minimaal even tevreden over de digitale balie dan andere kanalen waarmee zij in contact treden met de klant</br> </br> We verwachten minstens eenzelfde tevredenheid over de digitale balie dan over de andere kanalen</br> </br> 0</br> </br> 0</br> </br> </br> Een verhoogde flexibiliteit voor de medewerkers om via telewerk burgers te bedienen</br> </br> We verwachten dat de digitale balie de betrokken medewerkers meer kansen geeft om via telewerk hun werk uit te oefenen. Hierbij denken we dat in desbetreffende diensten het aandeel telewerk met 20% kan toenemen.</br> </br> 0</br> </br> 0,2</br> </br> </br> De burger/ondernemer/vereniging kan zijn identiteit tijdens een videogesprek bewijzen.</br> </br> Burger/Onderneming/ Vereniging (klant) </br> </br> De burger kan indien nodig altijd zijn identiteit bewijzen tijdens een videogesprek (authenticatie)</br> </br> De burger kan tijdens het videogesprek als het nodig is zijn identiteit bewijzen. (100%)</br> </br> 0</br> </br> 1</br> </br> </br> Medewerker/ambtenaar </br> </br> De medewerker kan indien nodig vragen aan de burger om zijn identiteit te bewijzen</br> </br> De medewerker kan tijdens het videogesprek, indien nodig het identiteitsbewijs opvragen aan de burger in het digitaal loket (100%)</br> </br> 0</br> </br> 1</br> </br> </br> Organisatie </br> </br> De organisatie kan door deze functionaliteit meer producten aanbieden in de digitale balie</br> </br> Het aantal producten en diensten die in de digitale balie worden opgenomen stijgt door de functionaliteit 'authenticatie' toe te voegen aan de digitale balie.</br> </br> 0 producten</br> </br> Minstens 1 product</br> </br> </br> De burger/ondernemer kan tijdens een videogesprek documenten uitwisselen.</br> </br> Burger/Onderneming/ Vereniging (klant) </br> </br> De burger kan indien nodig documenten uitwisselen tijdens een videogesprek</br> </br> De burger kan tijdens het videogesprek als het nodig is documenten uitwisselen met de betrokken ambtenaar. (100%)</br> </br> 0</br> </br> 1</br> </br> </br> Medewerker/ambtenaar </br> </br> De medewerker kan indien nodig documenten uitwisselen met de burger tijdens het videogesprek.</br> </br> De medewerker kan tijdens het videogesprek, indien nodig documenten uitwisselen met de burger.</br> </br> 0</br> </br> 1</br> </br> </br> Organisatie </br> </br> De organisatie kan door deze functionaliteit meer producten aanbieden in de digitale balie</br> </br> Het aantal producten en diensten die in de digitale balie worden opgenomen stijgt door de functionaliteit 'documenten uit te wisselen' toe te voegen aan de digitale balie.</br> </br> 0 producten</br> </br> Minstens 1 product</br> </br> </br> De burger/ondernemer kan tijdens een videogesprek een digitale handtekening plaatsen.</br> </br> Burger/Onderneming/ Vereniging (klant) </br> </br> De burger kan indien nodig een digitale handtekening plaatsen tijdens een videogesprek</br> </br> De burger kan tijdens het videogesprek als het nodig is digitaal een document ondertekenen. (100%)</br> </br> 0</br> </br> 1</br> </br> </br> Medewerker/ambtenaar </br> </br> De medewerker kan indien nodig een document digitaal laten ondertekenen door de burger tijdens het videogesprek.</br> </br> De medewerker kan tijdens het videogesprek, indien nodig documenten laten ondertekenen door de burger.</br> </br> 0</br> </br> 1</br> </br> </br> Organisatie </br> </br> De organisatie kan door deze functionaliteit meer producten aanbieden in de digitale balie</br> </br> Het aantal producten en diensten die in de digitale balie worden opgenomen stijgt door de functionaliteit 'digitaal handtekenen' toe te voegen aan de digitale balie.</br> </br> 0 producten</br> </br> Minstens 1 product</br> </br> </br> De burger/ondernemer kan tijdens een videogesprek een betaling uitvoeren</br> </br> Burger/Onderneming/ Vereniging (klant) </br> </br> De burger kan indien nodig een digitale betaling uitvoeren tijdens een videogesprek</br> </br> De burger kan tijdens het videogesprek als het nodig is digitaal een betaling uitvoeren. (100%)</br> </br> 0</br> </br> 1</br> </br> </br> Medewerker/ambtenaar </br> </br> De medewerker kan indien nodig een digitale betaling vragen en/of uitvoeren van/naar de burger tijdens het videogesprek.</br> </br> De medewerker kan tijdens het videogesprek, indien nodig een digitale betaling vragen aan de burger.</br> </br> 0</br> </br> 1</br> </br> </br> Organisatie </br> </br> De organisatie kan door deze functionaliteit meer producten aanbieden in de digitale balie</br> </br> Het aantal producten en diensten die in de digitale balie worden opgenomen stijgt door de functionaliteit 'online betaling' toe te voegen aan de digitale balie.</br> </br> 0 producten</br> </br> Minstens 1 product</br> </br> Andere projectdocumenten </br> Geen documenten beschikbaar via de VLOCA kennishub.</br> </br> Interesse in dit project? </br> Gelieve contact op te nemen via gzg@vlaanderen.be .  +
• Introductie Het project “Gebruiksvriende … Introductie </br> Het project “Gebruiksvriendelijk Verenigingsloket met ontsluiting van lokale dienstverlening” had als doel het Verenigingsloket sneller bekend te maken en gebruikt te laten worden door verenigingen door het zo snel mogelijk van input te voorzien vanuit de lokale besturen. Het project werd getrokken door Gent en werd uitgevoerd in samenwerking met Brugge, Evergem, Kortrijk, Leuven en Puurs-Sint-Amands.</br> Het project resulteerde in:</br> </br> Een AS IS analyse van het dienstverleningslandschap van lokale besturen naar verenigingen; </br> Analyse rond datavragen m.b.t. het project authentieke bron voor verenigingen (het Verenigingsregister); </br> POC: aansluiting van 1 product bij 1 lokaal bestuur. </br> Pitch </br> Voor verenigingen die gebruik maken van lokale dienstverlening </br> biedt deze nieuwe aanpak </br> een online plaats waar alles voor een vereniging over verschillende besturen heen gebruiksvriendelijk gebuneld is , </br> door aansluiting van lokale dienstverlening op het verenigingsloket, analoog aan mijn Burgerprofiel en het e-loket voor ondernemers . </br> In tegenstelling tot de huidige manier van werken is deze aanpak niet langer aanbodgericht maar klantgericht. Het startpunt is de vereniging die een bundeling van functionaliteiten over verschillende besturen heen achter 1 toegangspoort vindt. Hierdoor kunnen verenigingen overzichtelijker en vlotter administratieve zaken (leren) kennen regelen .</br> </br> Impactmap </br> </br> </br> Blauwdruk </br> Succes-meting </br> Andere projectdocumenten </br> Geen documenten beschikbaar via de VLOCA kennishub.</br> </br> Interesse in dit project? </br> Gelieve contact op te nemen via gzg@vlaanderen.be . nemen via gzg@vlaanderen.be .  +