previous 202050100250500next 20
Showing 20 pages using this property.
D
VLOCA-model V0.1 Mobiele Sensor Units – Roeselare +
Inleiding Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we V0.1 noemen. 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. Situering van deze deliverable in het traject Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. 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. Dit document vormt een basis voor het verdere verloop van het traject. In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. Doel en doelgroep 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. Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be . Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) 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. 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. Burgers en burgergroeperingen: 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. Aanpak (korte beschrijving) In dit VLOCA model V0.1 vertrekken we van de visie, missie en doelen zoals ze geformuleerd worden door de initiatiefnemer. 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. 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. Inhoud Hieronder kan je de elementen van versie V0.1 van dit VLOCA model bekijken. CoT Mobiele Sensor Units – Roeselare 01/06/2022 VLOCA-model versie 0.1 VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be Beschrijving en aanpak: https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model Strategie van de open city uitdaging Status Toelichting Beschrijving Visie Voorstel Wat is de bestaansreden ? 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. Missie Voorstel Wat willen we bereiken ? 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. Doel Voorstel Wat is het doel van dit project ? 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. Succesfactor Voorstel Hoe meten we succes ? (SMART) Een volledige mobiele sensor platform voor Roeselare, Brugge en Knokke tegen 2025. Use cases ID Status Samenvatting Beschrijving UC1 Voorstel UC1: Mobiele Sensors Een keuze van sensoren moederbord en behuizing die passen op verschillende types van voertuigen (auto's, camionetten, vrachtwagens, fietsen, scooters, drones, ed meer) UC2 Voorstel UC2: Verkeersborden Databanken 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. UC3 Voorstel UC3: Connectie Een keuze van connectie mogelijkheden die 'mobiele' sensoren kunnen bedienen in de omgeving die gemeten moet worden. (5G, 4G, enz.) UC4 Voorstel UC4: Open Data Datastandaardisatie zowel op metadata (OSLO) alsook formaat(JSON-LD), bestekteksten, conformiteitsdocumenten, schaalbaarheid, interoperabiliteit, ... UC5 Voorstel UC5: Service 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. UC6 Voorstel UC6: Incentivering Het kunnen vergoeden van 'bedrijven' wiens voertuigen dienen als 'base' voor de mobiele sensoren. UC7 Voorstel UC7: Inzichten & Dashboarding Het verkrijgen van inzichten die het beleid kan beinvloeden en/of bijsturen UC8 Voorstel UC8: Exploratie opportuniteit : Luchtkwaliteit, verkeersdrukte, enz. Vinden van extra use cases om de mobiele sensoren/camera's andere metingen te kunnen laten uitvoeren zoals luchtkwaliteit, verkeersdrukte, sluikstorten... Metadata Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases ID Type Samenvatting Beschrijving UC1 Use case UC1: Mobiele Sensors Een keuze van sensoren moederbord en behuizing die passen op verschillende types van voertuigen (auto's, camionetten, vrachtwagens, fietsen, scooters, drones, ed meer) BC1.1 Business capability Analyse van wat er al op de markt beschikbaar is BC1.2 Business capability Recommendaties ifv verschillende scenario's (budget beschikbaar ?, context, thema, ed meer) ID Type Samenvatting Beschrijving UC2 Use case UC2: Verkeersborden Databanken 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. BC2.1 Business capability Overzicht van alle verkeersborden die via de camera gecapteerd zijn tov de gekende verkeersborden databank BC2.2 Business capability ifv prioritisatie een herstellingplan kunnen opstellen. ID Type Samenvatting Beschrijving UC3 Use case UC3: Connectie Een keuze van connectie mogelijkheden die 'mobiele' sensoren kunnen bedienen in de omgeving die gemeten moet worden. (5G, 4G, enz.) BC3.1 Business capability markt en omgevingsanalyse BC3.2 Business capability een connectie recommendatie ifv verschillende scenario's ID Type Samenvatting Beschrijving UC4 Use case UC4: Open Data Datastandaardisatie zowel op metadata (OSLO) alsook formaat(JSON-LD), bestekteksten, conformiteitsdocumenten, schaalbaarheid, interoperabiliteit, ... BC4.1 Business capability Gap analyse met evt bestaande OSLO data standaarden BC4.2 Business capability Definieren van de OSLO data standaarden BC4.3 Business capability Definieren van bestekteksten, conformiteitsdocumenten BC4.4 Business capability Valideren van interoperabiliteit en schaalbaarheid van de gekozen oplossing ID Type Samenvatting Beschrijving UC5 Use case UC5: Service 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. BC5.1 Business capability 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. BC5.2 Business capability Het kunnen doorsturen van facturatie gegevens BC5.3 Business capability Het kunnen online betalen van de service BC5.4 Business capability Bibliotheek van draaiboeken voor steden die ook willen gebruik maken van deze platform ID Type Samenvatting Beschrijving UC6 Use case UC6: Incentivering Het kunnen vergoeden van 'bedrijven' wiens voertuigen dienen als 'base' voor de mobiele sensoren. BC6.1 Business capability Standaard contracten die herbruikbaar zijn bij nieuwe 'leveranciers' BC6.2 Business capability Betalingsmogelijkheden ID Type Samenvatting Beschrijving UC7 Use case UC7: Inzichten & Dashboarding Het verkrijgen van inzichten die het beleid kan beinvloeden en/of bijsturen BC7.1 Business capability Het aantal gebruikers van service machine learning via mobiele sensoren per thema BC7.2 Business capability De kosten en inkomsten van die service = P&L ID Type Samenvatting Beschrijving UC8 Use case UC8: Exploratie opportuniteit : Luchtkwaliteit, verkeersdrukte, enz. Vinden van extra use cases om de mobiele sensoren/camera's andere metingen te kunnen laten uitvoeren zoals luchtkwaliteit, verkeersdrukte, sluikstorten... BC8.1 Business capability Analyse van beleidsdomeinen en prioriteiten om extra use cases te vinden.  
VLOCA-model V0.1 Machine Learning as a Service (MLaaS) – Roeselare +
Inleiding Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we V0.1 noemen. 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. Situering van deze deliverable in het traject Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. 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. Dit document vormt een basis voor het verdere verloop van het traject. In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. Doel en doelgroep 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. Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be . Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) 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. 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. Burgers en burgergroeperingen: 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. Aanpak (korte beschrijving) In dit VLOCA model V0.1 vertrekken we van de visie, missie en doelen zoals ze geformuleerd worden door de initiatiefnemer. 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. 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. Inhoud Hieronder kan je de elementen van versie V0.1 van dit VLOCA model bekijken. CoT Machine Learning as a Service (MLaaS) – Roeselare 2022 VLOCA-model versie 0.1 VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be Beschrijving en aanpak: https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model Strategie van de open city uitdaging Status Toelichting Beschrijving Visie Voorstel Wat is de bestaansreden ? 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. Missie Voorstel Wat willen we bereiken ? 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. Doel Voorstel Wat is het doel van dit project ? 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. Succesfactor Voorstel Hoe meten we succes ? (SMART) 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 Use cases ID Status Samenvatting Beschrijving UC1 voorstel UC1: Model Training We moeten de modellen kunnen trainen om patronen te herkennen, zoals verkeersborden, aantal bomen, gezondheid bomen, status van de wegen, ed. UC2 voorstel UC2: Model Implementation De modellen moeten in een bibiliotheek beschikbaar zijn met documentatie, bestekteksten en conformiteitsmodellen UC3 voorstel UC3: Model Quality De kwaliteit van de modellen moeten telkens gecheckt worden en gerapporteerd UC4 voorstel UC4: Dynamic Modelling Nieuwe modellen moeten kunnen gebouwd worden op basis van nieuwe (dependent en independent) variabelen. UC5 voorstel UC5: Beeldmateriaal : Luchtfoto's Het verkrijgen van luchtfoto's die beschikbaar zijn voor machine learning om iets te 'identificeren' UC6 voorstel UC6: Bomen Telling Het aantal bomen kunnen inventariseren via luchtfoto's : Vlaamse Standaard UC7 voorstel UC7: Wegmarkering Via Luchtfoto's de markeringen op de wegen te identificeren : Vlaamse Standaard UC8 voorstel UC8: Exploratie Luchtfoto's Via Exploratie : het opzoeken van andere opportuniteiten die we van luchtfoto's kunnen halen. UC9 voorstel UC9: Verkeersborden Gebruik van machine learning (zie CoT Mobiele Sensoren) om met mobiele sensoren de verkeersborden te inventariseren en de 'besmeuringen' te herkennen : Vlaamse Standaard Metadata Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases ID Type Samenvatting Beschrijving UC1 Use case UC1: Model Training We moeten de modellen kunnen trainen om patronen te herkennen, zoals verkeersborden, aantal bomen, gezondheid bomen, status van de wegen, ed. BC1.1 Business capability Samenvatting 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. BC1.2 Business capability beslissen wanneer is een model 'goed genoeg' ID Type Samenvatting Beschrijving UC2 Use case UC2: Model Implementation De modellen moeten in een bibiliotheek beschikbaar zijn met documentatie, bestekteksten en conformiteitsmodellen BC2.1 Business capability Het opladen van de modellen met documentatie op een server zodat die gebruikt kunnen worden door 'derde' partijen. BC2.2 Business capability Metadata over de modellen en versies van de documentatie. BC2.3 Business capability Het bouwen van een 'bibliotheek' platform met versionering van de documentatie. ID Type Samenvatting Beschrijving UC3 Use case UC3: Model Quality De kwaliteit van de modellen moeten telkens gecheckt worden en gerapporteerd BC3.1 Business capability Trends analyse van een constante iteratie die de modellen op de proef stellen door nieuwe train en test sets te gebruiken. BC3.2 Business capability Overzicht van de trends van de kwaliteit van de modellen ifv lift curve, false positives, betrouwbaarheids intervallen,... ID Type Samenvatting Beschrijving UC4 Use case UC4: Dynamic Modelling Nieuwe modellen moeten kunnen gebouwd worden op basis van nieuwe (dependent en independent) variabelen. BC4.1 Business capability moduleerbare ML systeem die gemakkelijk uitbreidbaar zijn om nieuwe variabelen te voorspellen ifv input variabelen. ID Type Samenvatting Beschrijving UC5 Use case UC5: Beeldmateriaal : Luchtfoto's Het verkrijgen van luchtfoto's die beschikbaar zijn voor machine learning om iets te 'identificeren' BC5.1 Business capability Maken en verwerken van luchtfoto's tot hoogkwalitatieve beelden BC5.2 Business capability Bepalen van de kwaliteitcriteria nodig voor de Machine Learning analyse BC5.3 Business capability Toetsen van de hoogkwalitatieve beelden aan de kwaliteitscriteria nodig voor de Machine Learning analyse ID Type Samenvatting Beschrijving UC6 Use case UC6: Bomen Telling Het aantal bomen kunnen inventariseren via luchtfoto's : Vlaamse Standaard BC6.1 Business capability Bekijken en analyseren van potentiaal bestaande standaarden (Vlaams en/of internationaal) BC6.2 Business capability Opmaken van een OSLO standaard voor het inventariseren van bomen via luchtfoto's BC6.3 Business capability Inventariseren van de bomen via luchtfoto's, gekoppeld aan historiek en gap analyse ID Type Samenvatting Beschrijving UC7 Use case UC7: Wegmarkering Via Luchtfoto's de markeringen op de wegen te identificeren : Vlaamse Standaard BC7.1 Business capability Bekijken en analyseren van potentiaal bestaande standaarden (Vlaams en/of internationaal) BC7.2 Business capability Opmaken van een OSLO standaard voor het inventariseren van wegmarkeringen via luchtfoto's BC7.3 Business capability Inventariseren van de wegmarkeringen via luchtfoto's, gekoppeld aan historiek en gap analyse ID Type Samenvatting Beschrijving UC8 Use case UC8: Exploratie Luchtfoto's Via Exploratie : het opzoeken van andere opportuniteiten die we van luchtfoto's kunnen halen. BC8.1 Business capability Bekijken en analyseren van potentiaal bestaande standaarden (Vlaams en/of internationaal) BC8.2 Business capability Opmaken van een OSLO standaard voor het inventariseren van verkeersborden BC8.3 Business capability Inventariseren van de verkeersborden via beelden van mobiele sensoren, gekoppeld aan historiek en gap analyse ID Type Samenvatting Beschrijving UC9 Use case UC9: Verkeersborden Gebruik van machine learning (zie CoT Mobiele Sensoren) om met mobiele sensoren de verkeersborden te inventariseren en de 'besmeuringen' te herkennen : Vlaamse Standaard  
Visualo VLOCA-model V0.1 +
Opgelet, er zijn andere versies van deze deliverable beschikbaar. Inleiding Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we V0.1 noemen. 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. Situering van deze deliverable in het traject Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. 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. Dit document vormt een basis voor het verdere verloop van het traject. In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. Doel en doelgroep 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. Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be . Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) 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. 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. Burgers en burgergroeperingen: 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. Aanpak (korte beschrijving) In dit VLOCA model V0.1 vertrekken we van de visie, missie en doelen zoals ze geformuleerd worden door de initiatiefnemer. 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. 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. Overzicht andere versies van deze deliverable   Deliverable Versie Visualo VLOCA-model V0.2 VLOCA-Model V0.2 Visualo VLOCA-model V0.1 VLOCA-Model V0.1 Inhoud Hieronder kan je de elementen van versie V0.1 van dit VLOCA model bekijken. Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) – Halle 2022 Versie: 0.1 VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be Beschrijving en aanpak: https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model Strategie van de open city uitdaging Status Toelichting Beschrijving Visie Voorstel Wat is de bestaansreden ? Corona heeft grote impact gehad op lokale handelszaken. Aanbod van lokale handelszaken is weinig bekend bij inwoners en nog minder bij bezoekers. Digitale Infoschermen in het straatbeeld zouden een oplossing kunnen zijn, maar tonen vooral advertenties voor multinationals en webshops, en de lokale besturen beperken zich vaak tot aankondiging voor evenementen. Missie Voorstel Wat willen we bereiken ? Mensen (shoppers) via digitale schermen aanzetten tot het lokaal kopen. Doel Voorstel Wat is het doel van dit project ? 1.Laagdrempelig gebruiksvriendelijke app voor de handelaars om hun advertentie te kunnen posten, 2. Performance platform voor centrum manager (data verzamelen, data analyseren, campaign performance analysis, tips and tricks,...) 3. Advertenties op slimme infoborden (interactief, inlog mogelijkheden, met QR code, ...) => nudging van markt naar binnenstad en vice versa. Succesfactor Voorstel Hoe meten we succes ? (SMART) indien de lokale adverteerders 'meer' verkopen nadat ze hun advertentie hebben kunnen plaatsen. Use cases ID Status Samenvatting Beschrijving UC1 Voorstel UC1: Digitale Scherm Digitale Scherm die al dan niet ' interactie f' een advertentie van de lokale winkels laat zien UC2 Voorstel UC2: Media Centrale Een pseudo media centrale die de advertenties controleert, toekent en ' factureer t' ifv regels en GRP (Reach, frequentie, enz.) UC3 Voorstel UC3: App Een app die gemakkelijk door de lokale adverteerder toelaat om zijn eigen advertentie te kunnen inplannen en projecteren. UC4 Voorstel UC4: Inzichten Rapportage van performantie van campagnes met inzichten van wat heeft gewerkt en wat niet (Tips en Tricks), incl beleidsrapportering. UC5 Voorstel UC5: Schaalbaarheid Oplossing is uitbreidbaar (en interoperabel) naar andere steden en gemeenten zonder veel aanpassingen Metadata Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases ID Type Samenvatting Beschrijving UC1 Use case UC1: Digitale Scherm Digitale Scherm die al dan niet 'interactief' een advertentie van de lokale winkels laat zien BC1.1 Business capability Samenvatting Roterende visualisering van advertenties BC1.2 Business capability Samenvatting interactieve opzoek mogelijkheden (via touchscreen of via handgebaren...) BC1.3 Business capability Samenvatting snelle begeleiding of kortingen bvb via QR codes BC1.4 Business capability Samenvatting BC1.5 Business capability Samenvatting BC1.7 Business capability Samenvatting ID Type Samenvatting Beschrijving UC2 Use case UC2: Media Centrale Een pseudo media centrale die de advertenties controleert, toekent en 'factureert' ifv regels en GRP (Reach, frequentie, enz.) BC2.1 Business capability Samenvatting Bepalen van de advertentieregels (bvb maar 7% van schermtijd voor de corporates/niet lokale handelaars) BC2.2 Business capability Samenvatting Roterings Planning opmaken BC2.3 Business capability Samenvatting facturatie van de adverteerders BC2.4 Business capability Samenvatting Aanbieden van een advertentie templates met tips en tricks BC2.5 Business capability Samenvatting Controle op de te vertonen advertentie (ethische richtlijnen moeten gevolgd worden, enz.) ID Type Samenvatting Beschrijving UC3 Use case UC3: App Een app die gemakkelijk door de lokale adverteerder toelaat om zijn eigen advertentie te kunnen inplannen en projecteren. BC3.1 Business capability Samenvatting Keuze uit templates met drag en drop van foto materiaal en logo met bijhorende tekst BC3.2 Business capability Samenvatting Ontwikkelen van een prijs settings mechanisme die pragmatisch last minute advertenties toelaat BC3.3 Business capability Samenvatting Registratie met validatie van een nieuwe adverteerder ID Type Samenvatting Beschrijving UC4 Use case UC4: Inzichten Rapportage van performantie van campagnes met inzichten van wat heeft gewerkt en wat niet (Tips en Tricks), incl beleidsrapportering. BC4.1 Business capability Samenvatting Het meten van passanten BC4.2 Business capability Samenvatting Het meten van ' viewer s' BC4.3 Business capability Samenvatting Het meten van gezichtsuitdrukkingen van de ' viewer s' BC4.4 Business capability Samenvatting Het bepalen van de ROI van een campagne door de binnenstappers en besteders te bepalen van de 'viewers' BC4.5 Business capability Samenvatting Mogelijkheid om (experimentele) AB testen te doen (vergelijken van verschillende advertenties op de commerciele resultaten van de adverteerder) ID Type Samenvatting Beschrijving UC5 Use case UC5: Schaalbaarheid Oplossing is uitbreidbaar (en interoperabel) naar andere steden en gemeenten zonder veel aanpassingen BC5.1 Business capability Samenvatting Bepalen van de OSLO standaarden voor de app en media centrale BC5.2 Business capability Samenvatting uitbreidbaarheid van de media centrale en de app voor andere steden mits afspraken op delen van budgetten/kosten  
VLOCA-model V0.1 Het potentieel van urban mining voor de bouwsector +
Opgelet, er zijn andere versies van deze deliverable beschikbaar. Inleiding Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we V0.1 noemen. 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. Situering van deze deliverable in het traject Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. 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. Dit document vormt een basis voor het verdere verloop van het traject. In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. Doel en doelgroep 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. Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be . Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) 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. 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. Burgers en burgergroeperingen: 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. Aanpak (korte beschrijving) In dit VLOCA model V0.1 vertrekken we van de visie, missie en doelen zoals ze geformuleerd worden door de initiatiefnemer. 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. 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. Overzicht andere versies van deze deliverable   Deliverable Versie VLOCA-model V0.2 Het potentieel van urban mining voor de bouwsector VLOCA-Model V0.2 VLOCA-model V0.1 Het potentieel van urban mining voor de bouwsector VLOCA-Model V0.1 Inhoud Hieronder kan je de elementen van versie V0.1 van dit VLOCA model bekijken. CoT Het potentieel van urban mining voor de bouwsector – Oostende 2022 VLOCA-model versie 0.1 VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be Beschrijving en aanpak: https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model Strategie van de open city uitdaging Status Toelichting Beschrijving Visie Voorstel Wat is de bestaansreden ? Klimaat neutraal zijn tegen 2050 betekent concrete acties reeds nu ondernemen. Daaronder valt circulaire economie als belangrijke onderdeel. Binnen Circulaire economie is urban mining een grote opportuniteit want 35% van de afval komt van de bouwsector. Missie Voorstel Wat willen we bereiken ? Via urban mining onze klimaat doelstelling, alsook economische groei mee te behalen doordat lokale spelers kunnen inspringen ipv internationale leveranciers te gebruiken. Doel Voorstel Wat is het doel van dit project ? (1) Een 'dashboard' die de aanbod en de vraag in kaart brengt van 'herbruikbare' bouwmaterialen (2) alsook de partijen bij elkaar brengt (=makelaars functionaliteit) en (3) resultaten visualiseert. Succesfactor Voorstel Hoe meten we succes ? (SMART) Een werkende infrastructuur met minstens 5 BIMs van bestaande gebouwen en 5 vragende partijen voor herbruikbare bouwmateriaal en 1 'matchmaking' geval tussen vraag en aanbod tegen 2024 Use cases ID Status Samenvatting Beschrijving UC1 Voorstel UC1: Aanbod deel Een data register systeem (databank) van alle (al dan niet) geplande af te breken gebouwen met hun gebruikte materiaal ter beschikking stellen UC2 Voorstel UC2: Vraag deel Een mogelijkheid om een 'vraag' in te dienen van een nieuwbouw of renovatie project met de beoogde materiaal dimensies en specificaties UC3 Voorstel UC3: Makelaars deel De mogelijkheid om de vraag en aanbod te 'match maken' door een 'intelligente' algoritme te berekenen voor wie welke materiaal zou kunnen dienen UC4 Voorstel UC4: Offerte aanbod Het kunnen aanbieden van materiaal voor specifieke aanvragers met een concrete offerte UC5 Voorstel UC5: Bestelling uitvoeren Het kunnen aanvaarden van een 'offerte' van de aanbieder van herbruikbare bouw materiaal UC6 Voorstel UC6: Inzichten & Dashboarding Het verkrijgen van inzichten die het beleid kan beinvloeden en/of bijsturen UC7 Voorstel UC7: Principes Schaalbaarheid (voor extra steden en regio's) en interoperabiliteit (voor extra toepassingen) van de toepassing is cruciaal Metadata Metaveld Beschrijving circulaire economie urban mining klimaat neutraal BIM makelaar of matchmaking Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases ID Type Samenvatting Beschrijving UC1 Use case UC1: Aanbod deel Een data register systeem (databank) van alle (al dan niet) geplande af te breken gebouwen met hun gebruikte materiaal ter beschikking stellen BC1.1 Business capability Alle eigenaars van gebouwen moeten een standaard BIM model kunnen invoeren en aanpassen BC1.2 Business capability Bestaande andere standaarden moeten kunnen automatisch vertaald worden naar de standaard BIM model (eigenaars die een soortgelijke maar geen identieke BIM formaten gebruiken moeten de mogelijkheden hebben om die alsnog op te laden en te 'vertalen' naar de BIM formaten) BC1.3 Business capability Bestaande ingevulde databases van BIM's (of vertaalbare) modelen moeten met 'druk op een knop' kunnen opgeladen worden in het systeem BC1.4 Business capability Review' van de 'herbruikbaarheid' = 'herbruikbaarheidsgraad Herbruikbaarheidsgraad (kwaliteit van het materiaal) kunnen invoeren met objectieve en subjectieve criteria met ook foto's of andere ongestructureerde data bronnen BC1.5 Business capability Aritificial Intelligence en Machine Learning Via allerlei data over de gebouwen een estimatie kunnen geven van de BIM en die na evaluatie al dan niet op te laden in de BIM databank met vermelding van methode, verwachte kwaliteit van de model ed meer. BC1.6 Business capability Rapportering Overzicht van opvulling van de BIM databank ID Type Samenvatting Beschrijving UC2 Use case UC2: Vraag deel Een mogelijkheid om een 'vraag' in te dienen van een nieuwbouw of renovatie project met de beoogde materiaal dimensies en specificaties BC2.1 Business capability BIM opladen van nieuwe project Bij nieuwe project kunnen opladen van de 'beoogde' BIM van het nieuwe gebouw/project met laatste datum van aanvraag BC2.2 Business capability Specifieke aanvraag Het kunnen aanvragen van specifieke materiaal met laatste datum waarop nog kan geboden worden BC2.3 Business capability rapportering Overzicht van opvulling van de aanvraag databank ID Type Samenvatting Beschrijving UC3 Use case UC3: Makelaars deel De mogelijkheid om de vraag en aanbod te 'match maken' door een 'intelligente' algoritme te berekenen voor wie welke materiaal zou kunnen dienen BC3.1 Business capability Optimalisatie Berekenen van de meest efficiente indeling van welke beschikbare materiaal voor welke aanvrager kan dienen die bepaalde criteria minimaliseerd bvb afstand aanbieder vs aanvrager BC3.2 Business capability Rapportering Het kunnen zien hoeveel offertes er reeds uitgeschreven werden en al dan niet aanvaard ID Type Samenvatting Beschrijving UC4 Use case UC4: Offerte aanbod Het kunnen aanbieden van materiaal voor specifieke aanvragers met een concrete offerte BC4.1 Business capability Offerte Maken en sturen Een offerte kunnen schrijven of opladen die herbruikbare materiaal aanbiedt aan een aanvrager ID Type Samenvatting Beschrijving UC5 Use case UC5: Bestelling uitvoeren Het kunnen aanvaarden van een 'offerte' van de aanbieder van herbruikbare bouw materiaal BC5.1 Business capability Aanvaarde Offertes Het kunnen aanvaarden van een offerte of feedback geven mbt extra vragen of negotiaties BC5.2 Business capability betalingsmogelijkheid Het kunnen betalen van een offerte ifv een factuur die automatisch wordt opgestuurd ifv de offerte BC5.3 Business capability feedback reviews Het kunnen invullen van een 'feedback' mbt de geleverde materiaal en service daarrond ID Type Samenvatting Beschrijving UC6 Use case UC6: Inzichten & Dashboarding Het verkrijgen van inzichten die het beleid kan beinvloeden en/of bijsturen BC6.1 Business capability Circulaire Economie KPI Mogelijkheid om een lijst van KPIs te kunnen berekenen die urban mining in context van circulaire economie voorstelt alsook klimaat neutraliteit BC6.2 Business capability urban mining success factor Het SENSORHOTEL heeft een voorziening die bij uitval van de data connectie de opslag van de door de sensoren gegenereerde data garandeert gedurende XXX uren ID Type Samenvatting Beschrijving UC7 Use case UC7: Principes Schaalbaarheid (voor extra steden en regio's) en interoperabiliteit (voor extra toepassingen) van de toepassing is cruciaal BC7.1 Business capability modulair Schaalbaarheid van de oplossing BC7.2 Business capability interoperabiliteit Het openstellen van de data voor andere toepassingen BC7.3 Business capability onderhoudshistoriek Bijhouden van alle interventies op de applicaties (upgrades, fixes van bugs, downtime, enz.) BC7.4 Business capability gebruiksanalyse Bijhouden en visualisatie van het gebruik van de applicaties BC7.5 Business capability gebruiksgemak Opvragen, bijhouden en rapporteren van de 'tevredenheid' van de gebruikers BC7.6 Business capability verspreiden van de applicatie Communiceren van de applicatie via 'direct marketing' kanalen  
VLOCA-model V0.1 Slimme Markten – Hasselt +
Inleiding Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we V0.1 noemen. 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. Situering van deze deliverable in het traject Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. 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. Dit document vormt een basis voor het verdere verloop van het traject. In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. Doel en doelgroep 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. Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be . Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) 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. 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. Burgers en burgergroeperingen: 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. Aanpak (korte beschrijving) In dit VLOCA model V0.1 vertrekken we van de visie, missie en doelen zoals ze geformuleerd worden door de initiatiefnemer. 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. 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. Inhoud Hieronder kan je de elementen van versie V0.1 van dit VLOCA model bekijken. CoT Slimme Markten: Hasselt, Turnhout, Halle 2022 VLOCA-model versie 0.1 VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be Beschrijving en aanpak: https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model Strategie van de open city uitdaging Status Toelichting Beschrijving Visie Voorstel Wat is de bestaansreden ? 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. Missie Voorstel Wat willen we bereiken ? Een volledige digitalisering van de 'ondersteuning' van lokale markten, zodat aanbieders met vragende partijen (bezoekers) bij elkaar kunnen komen in een digitale efficiente manier. Doel Voorstel Wat is het doel van dit project ? (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. Succesfactor Voorstel Hoe meten we succes ? (SMART) Tegen 2025 moeten minstens 4 verschillende markten reeds digitaal zijn gemigreerd voor zowel aanvragers, aanbieders, zoekopdrachten mogelijkheden, ed meer in Hasselt, Turnhout en Halle. Use cases ID Status Samenvatting Beschrijving UC1 Voorstel UC1: Reservering Marktplaatsen 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.) UC2 Voorstel UC2: Planning Support 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. UC3 Voorstel UC3: Markt Bezoek Trends & Inzichten 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) UC4 Voorstel UC4: Lokale economie in binnenstad stimuleren 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' UC5 Voorstel UC5: Beheer Vergunningen 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.) UC6 Voorstel UC6: Gerichte Markt Thema's 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') UC7 Voorstel UC7: communicatie broker 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) UC8 Voorstel UC8: Aanmaak nieuwe markt en standplaatsen in digitaal systeem 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 Metadata Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases ID Type Samenvatting Beschrijving UC1 Use case UC1: Reservering Marktplaatsen 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.) BC1.1 Business capability Inlog en authenticatie systeem voor ambulante handelaars met vergunning toe te laten om hun reservaties te doen. BC1.2 Business capability 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) BC1.3 Business capability Reservatie management mogelijkheden van een 'standplaats' BC1.4 Business capability rapportering Overzicht van status van standplaatsen om inzichten te verschaffen ID Type Samenvatting Beschrijving UC2 Use case UC2: Planning Support 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. BC2.1 Business capability Zoekopdrachten Via filters een selectie kunnen doen van nog beschikbare standplaatsen per type van markten BC2.2 Business capability Zoekopdrachten Via filters een selectie kunnen doen van bevestigde standplaatsen (=product aanbod) per type van markten en type van ambulante handel BC2.3 Business capability Planningstool Planning kunnen opstellen ifv randvoorwaarden hoe je in 'gans' vlaanderen (of regionaal) overal aanwezig kunt zijn binnen de ingestelde randvoorwaarden. ID Type Samenvatting Beschrijving UC3 Use case UC3: Markt Bezoek Trends & Inzichten 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) BC3.1 Business capability Reviews op standplaatsen, bezoekers, handelaars en markten 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 BC3.2 Business capability Rapportering Aantal Passanten, journey analyses, segmentaties van bezoekers en handelaars (mis)match BC3.3 Business capability Toegang Rapportering Wie toegang heeft tot welke rapporten, analyses en data ID Type Samenvatting Beschrijving UC4 Use case UC4: Lokale economie in binnenstad stimuleren 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' BC4.1 Business capability Vergelijken met en zonder markt Aantal bezoekers en omzet in binnenstad handelaars ifv het al dan niet aanwezig zijn van een markt in de buurt ID Type Samenvatting Beschrijving UC5 Use case UC5: Beheer Vergunningen 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.) BC5.1 Business capability Vergunningen Het kunnen beheren van de vergunningen (aanvragen, betalen, verlengen, stopzeten, terugbetalen, enz.) BC5.2 Business capability Rapportering Het kunnen rapportering van aantal vergunnings aanvragen en beheersmogelijkheden per markt BC5.3 Business capability feedback, klachten reviews Het kunnen invullen van een 'feedback' mbt de geleverde dienst bij vergunning beheer ID Type Samenvatting Beschrijving UC6 Use case UC6: Gerichte Markt Thema's 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') BC6.1 Business capability Communicatie en CRM naar handelaars toe 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' BC6.2 Business capability Communicatie en CRM naar consumenten toe Het kunnen aanspreken van consumenten ifv hun segment type en voorkeuren dat er een specifieke thema markt zal georganiseerd worden in de toekomst. ID Type Samenvatting Beschrijving UC7 Use case UC7: communicatie broker 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) BC7.1 Business capability 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. BC7.2 Business capability 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 BC 7.3 Business capability 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') BC7.4 Business capability Het kunnen 'unsubscriben' van consumenten tot een bepaalde handelaar (bij bvb spamming) ID Type Samenvatting Beschrijving UC8 Use case UC8: Aanmaak nieuwe markt en standplaatsen in digitaal systeem 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  
VLOCA-model V0.1 Mobiliteitsbudget voor burgers – Hasselt +
Opgelet, er zijn andere versies van deze deliverable beschikbaar. Inleiding Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we V0.1 noemen. 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. Situering van deze deliverable in het traject Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. 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. Dit document vormt een basis voor het verdere verloop van het traject. In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. Doel en doelgroep 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. Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be . Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) 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. 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. Burgers en burgergroeperingen: 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. Aanpak (korte beschrijving) In dit VLOCA model V0.1 vertrekken we van de visie, missie en doelen zoals ze geformuleerd worden door de initiatiefnemer. 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. 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. Overzicht andere versies van deze deliverable   Deliverable Versie VLOCA-model V0.2 Mobiliteitsbudget voor burgers – Hasselt VLOCA-Donut V0.2 VLOCA-model V0.1 Mobiliteitsbudget voor burgers – Hasselt VLOCA-Donut V0.1 Inhoud Hieronder kan je de elementen van versie V0.1 van dit VLOCA model bekijken. CoT Mobiliteitskrediet voor burgers (MoBurger) – Hasselt 2022 VLOCA-model versie 0.1 VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be Beschrijving en aanpak: https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model Strategie van de open city uitdaging Status Toelichting Beschrijving Visie Voorstel Wat is de bestaansreden ? Het verminderen van wagens in de binnenstad, ook voor de bewoners, gaat in tegen het gemak van het krijgen van een bewonerskaart en is dus een 'paradox'. Het is niet aangeraden om de bewonerskaart te geven aan diesel en benzine wagens terwijl we alles doen om de wagens van de binnenstad te mijden. Er staan veel wagens voor lange termijn stil in de straten van de binnenstad. Er zijn ook veel alternatieven in Hasselt en Leuven. We gaan duidelijk naar een MaaS. Missie Voorstel Wat willen we bereiken ? Een alternatief aanbieden via een 'krediet'/'Budget' om de wagen buiten de stad te laten door ipv een bewonerskaart met gratis parkeren, een krediet kunnen geven op een centrale 'applicatie' die zorgt dat de burger een alternatieve mobiliteit heeft om zich te verplaatsen in de stad maar ook waar de spelers (mobiliteits aanbieders) als de stad (=facilitator) de 'kortingen' zelf kunnen bepalen. Maar de (spel-) regels/contracten moeten digitaal gestandaardiseerd worden zodat de 'spelers' gemakkelijk eenmalig hun applicaties kunnen aanpassen en koppelen aan die centrale applicatie. Doel Voorstel Wat is het doel van dit project ? 1. Een centrale systeem waarin de 'contracten' worden gedefinieerd en gestandaardiseerd zodat die gebruikt kan worden door de spelers en budget gevers (= stad of bedrijven die hun medewerkers belonen bij het niet nemen van een bedrijfswagen bvb). 2. één applicatie die een overzicht geeft van alle mogelijke mobiliteits alternatieven, 3. één applicatie waar de burger zijn mobiliteits alternatief kan 'reserveren' en 'betalen' om van plaats A tot aan plaats B te gaan. 4. Een krediet toe te kennen vanuit de stad om bvb door de bewonerskaart niet te krijgen, een bedrag te krijgen die kan gebruikt worden om de alternatieven te gebruiken. 5. Een 'budget' moet kunnen gegeven worden voor een stuk van de MaaS spelers, door de stad, door de spelers als promo of door een 'derde' partij bvb. Succesfactor Voorstel Hoe meten we succes ? (SMART) Het aantal bewonerskaarten tov bestaande wagens zal dalen met bvb 25% tegen 2025. Use cases ID Status Samenvatting Beschrijving UC1 Voorstel UC1 Een applicatie die via één login een totale overzicht geeft van alle mobiliteits alternatieven die er vandaag ter beschikking zijn om van positie A tot positie B in de stad te geraken. UC2 Voorstel UC2 (Bestellen en) betalen (van budget) moet kunnen via één applicatie, één login en één betalingsopdracht ook al passeert het over zowel publieke transport (DeLijn, NMBS) routes alsook priveransport (electrische deelwagens, fiets, steps, enz) routes. UC3 Voorstel UC3 Door duurzaam handelen, wordt de burger beloont met 'krediet'/'Budget' op zijn rekening zodat hij zijn 'ritten' kan betalen met dit krediet. UC4 Voorstel UC4 Aantonen dat de alternatieve mobiliteitskrediet (en applicatie) geholpen heeft om de wagen uit de stad te weren, zowel geparkeerd als gereden. UC5 Voorstel UC5 Bij het invoeren van een destinatie zal de applicatie zoeken naar alternatieve snelste of goedkoopste of duurzaamste of gezondste (betere luchtkwaliteit) route om van de start positie tot het doel te 'reizen'. UC6 Voorstel UC6 Steun, via subsidies, naar initiatieven moeten meer 'variabel' en beperkt in tijd zijn ifv het gebruik door de burger, ipv een vlakke steun. UC7 Voorstel UC7 Werkgevers kunnen ook krediet 'betalen' aan de MaaS applicatie op de 'rekening' van de werknemer, dat eigenlijk neerkomt op een alternatieve duurzame verloning van werkgever naar -nemer. UC8 Voorstel UC8 Een 'speler' op de markt moet gemakkelijk zijn applicatie kunnen 'linken' aan de 'centrale applicatie' zodat zijn klant kan (gedeeltelijk) betalen met zijn huidige budget/krediet. Ook de bankapplicatie moet gekoppeld kunnen worden. Alsook moet het zonder 'app' kunnen (niet iedereen heeft een smartphone) functioneren. Metadata Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases ID Type Samenvatting Beschrijving UC1 Use case UC1 Een applicatie die via één login een totale overzicht geeft van alle mobiliteits alternatieven die er vandaag ter beschikking zijn om van positie A tot positie B in de stad te geraken. BC1.1 Business capability Een mapping tool om adres of POI (point of interest) in te voeren voor 'start' punt en 'eind' punt BC1.2 Business capability Inloggen en check of burger een bewoner is van de stad BC1.3 Business capability Voorstel van (alternatieve) routes, wanneer en via welke route, die passen binnen het budget en dat kan gevalideerd worden door de gebruiker met een muisklik in de tool. BC1.4 Business capability Overzicht van alle relevante mobiliteit en openbare domein (openbare werken, omleidingen,ed) ID Type Samenvatting Beschrijving UC2 Use case UC2 (Bestellen en) betalen (van budget) moet kunnen via één applicatie, één login en één betalingsopdracht ook al passeert het over zowel publieke transport (DeLijn, NMBS) routes alsook priveransport (electrische deelwagens, fiets, steps, enz) routes. BC2.1 Business capability betalingsmogelijkheid via de applicaties aan de verschillende participerende mobiliteits aanbieders BC2.2 Business capability gemakkelijke betalingsbewijs produceren om bij controles te kunnen laten zien. ID Type Samenvatting Beschrijving UC3 Use case UC3 Door duurzaam handelen, wordt de burger beloont met 'krediet'/'Budget' op zijn rekening zodat hij zijn 'ritten' kan betalen met dit krediet. BC3.1 Business capability Capteren van duurzaam handelen per participerende burger BC3.2 Business capability registratie mogelijkheid van burger om te participeren met validatie proces BC3.3 Business capability Toekennen van de 'budget' gelinkt aan een 'duurzaam handelen' aan de participerende burger, door de stad of participerende mobiliteits organisatie of derde partijen. BC3.4 Business capability Overzichtsmogelijkheid om eigen 'rekening' budget met transacties te visualiseren. ID Type Samenvatting Beschrijving UC4 Use case UC4 Aantonen dat de alternatieve mobiliteitskrediet (en applicatie) geholpen heeft om de wagen uit de stad te weren, zowel geparkeerd als gereden. BC4.1 Business capability Opstellen van een controle groep die de budgetten niet krijgen. BC4.2 Business capability Meten van de toegekende en gebruikte budgetten per type van gebruiker (segmentatie) BC4.3 Business capability Historiek van de toekening van bewonerskaarten per segment BC4.4 Business capability Verschil in toegekende bewonerskaarten ifv gebruik van mobiliteitskredieten applicatie. ID Type Samenvatting Beschrijving UC5 Use case UC5 Bij het invoeren van een destinatie zal de applicatie zoeken naar alternatieve snelste of goedkoopste of duurzaamste of gezondste (betere luchtkwaliteit) route om van de start positie tot het doel te 'reizen'. ID Type Samenvatting Beschrijving UC6 Use case UC6 Steun, via subsidies, naar initiatieven moeten meer 'variabel' en beperkt in tijd zijn ifv het gebruik door de burger, ipv een vlakke steun. BC6.1 Business capability Samenvatting capteren van het variabele gebruik BC6.2 Business capability Historiek alsook beleidslijn van subsidie toekenning. BC6.3 Business capability Berekenen van de te betalen subsidie ifv beleidlijn en variabel gebruik door de burger ID Type Samenvatting Beschrijving UC7 Use case UC7 Werkgevers kunnen ook krediet 'betalen' aan de MaaS applicatie op de 'rekening' van de werknemer, dat eigenlijk neerkomt op een alternatieve duurzame verloning van werkgever naar -nemer. ID Type Samenvatting Beschrijving UC8 Use case UC8 Een 'speler' op de markt moet gemakkelijk zijn applicatie kunnen 'linken' aan de 'centrale applicatie' zodat zijn klant kan (gedeeltelijk) betalen met zijn huidige budget/krediet. Ook de bankapplicatie moet gekoppeld kunnen worden. Alsook moet het zonder 'app' kunnen (niet iedereen heeft een smartphone) functioneren. BC8.1 Business capability Proces om nieuwe spelers toe te voegen. BC8.2 Business capability Toekenning van budget moet ook via 'website' kunnen verlopen. BC8.3 Business capability Het gebruik van de applicatie moet ook via website en geprinte documenten (qr code?) kunnen verlopen.  
Architectuurtekeningen Regionaal plugable incentiveringsplatform – Geel +
Architecturale context Context Samenvatting hoe we de architectuur opdracht hebben begrepen. Visie Steden hebben het moeilijk om het gedrag van de burgers te veranderen zonder incentivering. Uit vorige projecten blijkt dat 'vouchers' en 'lokale (digitale) munten' (sociaal 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. (Bron: REF01) Doelstellingen De lokale/digitale munt moet kunnen dienen als 'betaalmiddel' tussen C2C en B2B (mits wetgevend kader) om die munt zo lang mogelijk binnen de regio te houden. (Bron: REF01) Een platform dat 'goed gedrag' beloont met een 'lokale munt' die enkel in de regio kan ingeruild/gespendeerd worden = 'regio breed incentiveringsplatform'. (Bron: REF01) Een 'schaalbare' architectuur dat snel en efficiënt uitrolbaar is in andere regio die dat zouden wensen. (Bron: REF01) Stakeholders Deze paragraaf beschrijft de belangrijkste stakeholders. Stakeholders zijn mensen die actief betrokken zijn bij de architectuur opdracht en/of het project, of wiens belangen positief of negatief kunnen worden beïnvloed door de uitvoering of voltooiing van de integratie opdracht en/of het project. Stakeholders behoeften Rol Vertegenwoordigd door Verantwoordelijkheid Bezorgdheden Actie (*) Stad Geel OSLO IOK Stijn Claes - Koen Van den Eynde Ondersteuning van Kempense lokale besturen (en in eerste instantie stad Geel) met het uitrollen van een schaalbaar platform dat incentivering mogelijk maakt aan de hand van digitale munten. VLOCA Mieke Van Cauwenberghe Verantwoordelijkheid is tweeledig. Enerzijds wil VLOCA in co-creatie met kenniscentra, bedrijven, lokale besturen en burger(organisaties) een gedragen referentiekader, dat bestaat uit principes, concepten en architectuurcomponenten, tot stand brengen. Dit moet gaandeweg leiden tot een beheersbare open city architectuur voor slimme steden en gemeenten. Anderzijds is het de bedoeling om bovenstaande (eerste) resultaten door te vertalen naar een draaiboek voor aanbestedende (lokale) overheden. Dit draaiboek moet hen ondersteunen om slimme oplossingen uit te rollen, conform de Vlaamse Open City Architectuur. Hebben we de vereiste capabilities om de lokale besturen te ondersteunen zodat we hun keuzes veilig kunnen stellen naar de software leveranciers dat toekomstbestendig, consistent en in overeenstemming is met de VLOCA architectuur richtlijnen? (*) KS : Keep satisfied (High Power en Low Interest). MC : Manage Closely (High Power en High Interest) KI : Keep Informed (Low Power en High Interest). M : Monitor (Low Power en Low Interest) Use cases In deze paragraaf worden de use cases (goals) beschreven t.o.v. dat de doelstellingen (drivers) die gerealiseerd dienen te worden door de transitiearchitectuur. (Bron: REF01) N° Doelstelling (Driver) N° Use Cases CoT.2021.003.1 Een platform die 'goed gedrag' beloont met een 'lokale munt' die enkel in de regio kan ingeruild/gespendeerd worden = 'regio breed incentiveringsplatform' UC3 Participatie Mechanisme : Een gebruiksvriendelijke platform om zowel als 'donor' als 'collector' als 'spender' zichzelf te kunnen registreren en 'regels'/'parameters' voor ontvangen en gebruiken te kunnen vastleggen. Voor de definities van Donor, Collector en Spender. UC4 Marketing: Aanradingsprogramma om de lokale economie aan te trekken om mee te doen zowel als 'donor' (= participerende organisatie die zelf een stimulansaanbod aanbiedt) of 'sponsor'/'advertiser' (= organisatie die een stimulansaanbod wil financieren) alsook als 'collector' (= winkels die deze munt aanvaarden als betaling) Inclusief communicatieplatform om berichten, nieuwsletter, alerts, bevestigingen enz te kunnen beheren. UC10 Helpdesk, klachten & reviews: Helpdesk bij vragen, FAQ, klachten en reviews door alle betrokken partijen. UC6 Inzichten & Dashboarding: 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,...) CoT.2021.003.2 Een 'schaalbaar' architectuur dat snel en efficient uitrolbaar is in andere regio die dat zouden wensen. UC2 Integratie: Integratie met bestaande (en nieuwe) applicaties die als 'vertical' (organiseren van een stimulansaanbod) fungeren maar ook stadsapplicaties, websites, cadeaubonnen applicaties en zelfs MijnBurgerProfiel (app) UC7 Principes: 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) verticals moeten kunnen koppelen met het platform * ook aan bestedingszijde moet het platform flexibiliteit bieden (besteding bij handelaar, B2B (mits wetgevend kader), donatie aan lokale organisatie/doel/project, andere (crowd funding) systemen... UC8 Draaiboeken : Een bibliotheek leveren van draaiboeken die de steden en gemeenten een 'how to' uitleggen ifv hun behoeften en context. CoT.2021.003.3 De lokale/digitale munt moet kunnen dienen als 'betaalmiddel' tussen C2C en B2B (mits wetgevend kader) om die munt zo lang mogelijk binnen de regio te houden. UC1 Digitale wallet : 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. UC9 Compensatie mogelijkheden : Bij het kiezen voor een (additionele) lokale economie, willen we een evenwichtig systeem hebben tussen regionale en lokale 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 in gemeente A terwijl er factueel buiten proporties uitgegeven wordt door de burgers in gemeente B. UC11 Betalingen: Vanuit het platform één betalingsmodule die over alle 'verticals' heen kan gebruikt worden om te vermijden dat de handelaar verschillende systemen moet hebben per verticaal om geld te kunnen 'krijgen' van de 'shopper' UC5 Omzetting Mechanisme: Een facturatie- en betalingssysteem dat de eerste en allerlaatste conversie regelt zodat de lokale munt in praktijk omgezet kan worden in euros. KPI behoeften N° KPI Prestatie maatstaf Streefwaarde CoT.2021.003.X-UCnn KPI-001 Verkoop KPI ter illustratie : Als handelaar kan je kijken naar je het aantal verkoop per uur, dag, week, maand, kwartaal of jaar. Als streefwaarde kan je een percentage, een getal (in een bereik), … opgeven. Eventueel opgedeeld in tijd. KPI-002 Marketing KPI ter illustratie: Als handelaar kan je kijken naar het App verkeer, zoals het totaal aantal bezoeken voor jouw account. Meer verkeer betekent meer potentiële klanten. KPI-003 Customer Service KPI ter illustratie: De Net Promotor Score (NPS) meet de klanttevredenheid en klantenloyaliteit. Deze score wordt afgemeten aan de mate waarin klanten jou als handelaar aan iemand zouden aanbevelen. KPI-004 Productie KPI ter illustratie: De productiecyclus KPI vertelt je hoe lang het duurt om één advertentie te maken van start tot finish. Als je deze KPI goed in de gaten houdt krijg je belangrijke inzichten in de efficientie van jouw productie proces. KPI-005 Financiële KPI ter illustratie: De Return on Investement (ROI) KPI vertelt je wat je terug hebt verdiend t.o.v. jouw inspanningen. Hoe hoger het getal, hoe beter. De ROI heeft betrekking op alle uitgaven en inkomsten. DY-UCnn KPI-006 KPI-007 DZ-UCnn KPI-008, … Enterprise generieke architectuur De L1-capabilities als startpunt voor de enterprise architectuur. VLOCA Capability map De VLOCA capabilities die in staat zijn om de doelstellingen en use cases te realiseren. De omkaderde capabilities zijn diegenen die werden gedetecteerd voor dit traject. Er zijn verschillende L1-value streams (= VLOCA-cirkel) aanwezig in het VLOCA Capability map: Visie en strategie ontwikkeling: Het vaststellen van een richting en visie voor een organisatie. Dit omvat het definiëren van de bedrijfsstrategie en het beheren van strategische initiatieven. Het creëren van een visie, een missie en strategische doelstellingen en dus om ervoor te zorgen dat de organisatie in de gewenste richting beweegt. Ontwikkelen en beheren van Smart City producten en diensten: Beschrijven van het aanbod met betrekking tot het concept van het ontwikkelen en beheren van 'Smart City' producten en diensten. Promotie van de Smart City producten en diensten: Het begrijpen van markten, klanten en mogelijkheden. Het ontwikkelen van marketingstrategieën. Het ontwikkelen, beheren en uitvoeren van marketingplannen. Het ontwikkelen van verkoopstrategieën. Het beheren van verkooppartners en allianties. Leveren van Smart City producten en diensten:  Gaat over het plannen, beheren en uitvoeren van supply chain-activiteiten. Het aanschaffen van producten en diensten van leveranciers en het beheren van logistiek. Alsook het aanbieden van producten en diensten aan klanten en het identificeren van uitvoeringsplannen voor de levering van de verkochte producten en diensten. Opvolgen van klanten: Het opvolgen van klanten na de levering van producten en diensten. Dit omvat het ontwikkelen en plannen van klantenservice praktijken met het oog op het sturen van processen met betrekking tot vragen na verkoop, feedback, garanties en terugroepacties. Alsook zijn er verschillende (soorten van) L1-capabilities (= VLOCA-pillaren): Strategisch: Maken deel uit van de algehele strategie, ze ondersteunen (deels) de ambitie van de Vlaamse Overheid, Agentschap Binnenlands Bestuur & VLOCA. Strategic Control : Het definiëren en sturen van de VLOCA-visie, missie en strategie op steden en gemeenten Market Watch : Het definiëren en uitvoeren van onderzoek voor het begrijpen van de markten. Afhandelen van de externe marktanalyses (bv. PEST) als strategische input voor marketing afdelingen. Enabling: Creëren van mogelijkheden. Ze dragen bij aan het succes van operationele capabilities. Information Management : Informatie beheer is het bedrijfsproces van het verzamelen, opslaan, beheren en onderhouden van informatie in al zijn vormen gedurende de informatielevenscyclus. Operationeel: Wat een organisatie moet doen om zijn bedrijfsstrategie te kunnen uitvoeren. Zij worden gedefinieerd en opgebouwd doorheen de tijd, kunnen niet gemakkelijk worden geïmiteerd en vormen daarom een concurrentievoordeel voor de organisatie. Product Management: Ervoor zorgen dat de kwaliteit van alle producten (goederen en diensten) voldoet aan de verwachtingen in het aanbod. Deze capability omvat o.a. de markt- en consumentenbehoeften, productstrategie en portfolioveranderingen. Ook de ontwikkeling van productverbeteringen of nieuwe innovatie-ideeën komen aan bod. Supplier Management: Het beheren van de relatie die de lokale besturen onderhouden met haar leveranciers. Het omvat het stellen van doelen voor de samenwerking met leveranciers, het plannen van de activiteiten om met leveranciers in contact te komen, het classificeren van leveranciers op strategisch belang en het evalueren en controleren van leveranciers. Marketing Management : Beheert enerzijds de tactiek en anderzijds de marketing planning voor het komende jaar. Deze capability ontvangt zijn primaire informatie van andere capabilities zoals Market Watch, Product-, Sales & Distribution en Customer Management. Supply Chain Management : Coördineren van vraag en aanbod van/naar producten en diensten met klanten, medewerkers, partners en leveranciers. Sales & Distribution Management : Het beheren van de acceptatie van verkooporders via touchpoints , het coördineren van resterende activiteiten die nodig zijn om de bestelde producten en diensten aan de klanten en partners te leveren volgens een gespecificeerd leveringscontract. Customer Management : Het organiseren en beheersen van de continuïteit en ontwikkeling van kennis over de individuele B2B / B2C en klant en onze relatie met hem/haar. Het maken en beheren van overeenkomsten met klanten. Deze overeenkomsten kunnen formele (levering) contracten zijn, maar ook marketing toestemmingen en algemene voorwaarden, aanvaard door de klanten. Contact Center Management : Het registreren van de context en inhoud van het service request contact via tickets. Bevat service catalogi, waarin alle mogelijke vragen staan vermeld die we verwachten te behandelen met behulp van een kennisbank om de afhandeling van service requesten efficiënter en coherenter te maken. De kennisbank zorgt voor transparantie over beschikbare oplossingen & antwoorden op bekende problemen. Supporting: Waarde toevoegen aan andere capabilities. Geen specifieke concurrentievoordeel, kunnen worden geïmiteerd en uitbesteed. Finance : Beheer van alle business- en IT functies die nodig zijn voor het beheer van de financiële middelen van Smart City producten en diensten, inclusief boekhouding, treasury en interne en externe financiële rapportage. Human Resources : Beheer van alle activiteiten die nodig zijn om de best mogelijke match te creëren tussen de Smart City behoeften en de behoeften van de medewerkers die op de markt beschikbaar zijn om arbeid te verrichten. Het omvat het hele scala aan activiteiten, van instroom tot uitstroom van medewerkers, gedurende de gehele levenscyclus van medewerkers binnen een (lokale) organisatie. Enterprise architectuur (EA) principes EA principes (L1) definiëren de onderliggende algemene regels en richtlijnen voor het gebruik en de inzet van de L1-capabilities in de VLOCA trajecten. Ze weerspiegelen een mate van consensus tussen de verschillende architectuur onderdelen van het traject en vormen de basis voor het nemen van toekomstige beslissingen. Niet te verwarren met L2 & L3 vereisten (requirements). Enterprise architectuur principe beschrijvingen Bij het ontwerp van de transitiearchitectuur binnen trajecten & projecten dient er rekening te worden gehouden met de EA-principes. Voor elk principe wordt de volgende informatie verstrekt: Principe: een korte definitie van het principe, meestal in één woord Statement: een korte beschrijving wat we willen bereiken Rationale: de reden waarom het principe belangrijk is Implicaties: implicatie van het principe voor de uitvoerende organisatie EA Principe Statement Rationale Implicaties Functionaliteit in de juiste business area We zorgen er voor dat de ICT toepassingen zich binnen de juiste operationele omgevingen bevinden, binnen de steeds veranderde wensen en noden van de organisatie. Nieuwe en bestaande systemen en applicaties zullen de huidige grenzen van de operationele werking overschrijden. Creëren, bijwerken en onderhouden van business-, applicatie- en technologie architecturen via veranderingsgerichte ontwerpen. Omni channel We gaan voor een omni channel aanpak zodat de eindgebruiker tijdens een interactie, zoals aandacht (terug) aantrekken, kan schakelen tussen verschillende digitale kanalen. De eindgebruiker gebruikt de diverse digitale kanalen door elkaar terwijl de ervaring, prijzen, informatie, ... hetzelfde zijn. Alle digitale kanalen komen volledig samen, waardoor een volledig transparant proces ontstaat. Elk eindgebruiker gerichte applicatie dient te worden gebouwd met het oog op responsiviteit, zodat het geschikt is voor tablets, mobiele apparaten, pc/laptop, sociale media, chatbots, ... Op widget (of micro client)-niveau is co-development met derde partijen mogelijk, waarbij we niet alleen ICT services (IaaS & PaaS) delen, maar ook business services (SaaS). Cross Channel We gaan voor een cross channel aanpak zodat we de interacties tussen de eindgebruikers geïntegreerd kunnen afstemmen op de operationele activiteiten van de medewerkers van de Vlaamse Overheid. Op het eindgebruiker niveau worden business en ICT-services gebouwd met het oog op geïntegreerd gebruik van diverse operationele kanalen. Op het eindgebruiker niveau worden business en ICT-services gebouwd met het oog op geïntegreerd gebruik van diverse operationele kanalen. Implicaties: Door online en offline kanalen te mixen, dient de eindgebruiker op één uniforme manier bediend te worden zodat er zowel externe afspraken met de eindgebruiker, als interne afspraken tussen front- en back-office personeel dienen gemaakt te worden. In commerciële bedrijven zijn verkoopkanalen meestal gemixt, waarbij de klant er kan voor kiezen om artikelen online te bestellen en af ??te halen in een fysieke winkel. De klantenservice moet hiervan ook op de hoogte zijn. Hetzelfde principe kan toegepast worden door de burger centraal te stellen, want burgers, die in een ander context klanten zijn, verwachten hier ook een vlotte dienstverlening die tegemoetkomen aan hun noden. KISS Keep it simple, stupid. We willen eenvoud en duidelijkheid brengen in een steeds complexere ICT landschap. Systemen en applicaties als geheel volgen de solution architecturen, gemaakt in de PLAN fase, als input voor solution development in de BUILD fase. Afstemming nodig tussen VLOCA -, solution- en software architecturen via een architectuur & technologie governance. Ontkoppeling We willen dat de systemen en applicaties ontkoppeld worden, zodat ze onafhankelijker van elkaar werken. Om overal veranderingen te voorkomen met nieuwe systeem- en applicatie functies, worden lagen ontkoppeld door gebruik te maken van duidelijke en gedocumenteerde gestandaardiseerde interfaces. Presentatiegericht naar front-end en service gerichte interfaces naar back-end. Als technisch resultaat moeten de interfacing en aangepaste code naar de systemen en applicaties nauw aansluiten bij de technologie van de leverancier of de technologie van het ontwikkelingsteam. Robuustheid We willen betrouwbare systemen en applicaties die voldoen aan de noden en wensen van de eindgebruikers. Systemen en applicaties worden gebouwd, gekocht, samengevoegd en geconfigureerd volgens robuustheid criteria. Dit betekent dat een systeem of applicatie na een onderbreking zo snel mogelijk een aanvaardbare werkende staat moet hebben, waarbij de graad van robuustheid zal afhangen van de maturiteit en de positie van de ICT oplossing in de organisatie, zoals enerzijds de prototypes, MVPs, aangekochte (kern) en legacy systemen en anderzijds de front- en back-office applicaties. Onderhoudbaarheid We zorgen voor een degelijk onderhoud van de (nieuwe) ICT oplossingen binnen de gewenste prestatie vereisten. De algehele (business & ICT) operationele efficiëntie mag niet worden beperkt door nieuwe ICT oplossingen, noch zullen we enige functionele en technische achteruitgang van de huidige ICT oplossingen toestaan ??tijdens een projectfase. Operationele, business en ICT presatie (service) contracten dienen opgesteld te worden tussen dienstverleners en dienstafnemers, om zo de bedrijfscontinuïteit te waarborgen. Standaard software We gaan er zoveel mogelijk vanuit om eerst te herbruiken, dan aan te kopen en uiteindelijk te beslissen om systemen en applicaties zelf te bouwen. De systemen en applicaties volgen zoveel als mogelijk de "reuse, before buy & before build" richtlijnen. Dit betekent dat er (integratie) architectuur en technologie richtlijnen nodig zijn, zodat voorstellen van ICT-leveranciers / integratoren en deliverables van het ontwikkelteam kunnen worden bepaald zodat we op het juiste moment, de goede dingen doen teneinde ICT oplossingen uit te voeren aan de juiste prijs. Scheiding van verantwoordelijkheden We willen systemen en applicaties goed van elkaar scheiden zodat er meer mogelijkheden zijn voor uitbreidingen via (micro) componenten, hergebruik en onafhankelijke ontwikkeling (separation of concerns). De componenten en modules van de systemen en applicaties moeten worden gescheiden op basis van het soort werk dat wordt uitgevoerd. De realisatie van de ICT services dienen te worden geclassificeerd via functionele decompositie, zodat we de algehele complexiteit kunnen opsplitsen en de ontbonden elementen (componenten en modules) in kaart kunnen brengen op de business realisatie. Flexibiliteit We willen meer flexibiliteit inbouwen in de ICT ontwikkelingsomgevingen om de winstgevendheid en productiviteit van de ICT oplossingen te verhogen. De systemen en applicaties moeten worden ontworpen en aangestuurd om de kosten van toekomstige veranderingen te minimaliseren met respect voor de verschillende ICT evolutie behoeften binnen de organisatie. Dit impliceert dat ICT evoluties zoveel mogelijk onafhankelijk gebeuren binnen drie ontwikkelingslagen want presentatie-georiënteerde ontwikkelingen evolueren veel sneller in de front-ends dan ontwikkelingen in de back-ends. Dit weerspiegelt voor front-end ontwikkelingen in Agile methodieken en DevOps-tooling, in container- en workflow gebaseerde applicaties in de tussenlaag en in back-ends ontwikkelingen waar men de legacy / buy investeringen wenst te waarborgen. Deze verschillende ICT evoluties, leiden tot verschillende oplevering cycli (release cycles). Content, web en mobiele ICT evoluties veranderen veel sneller (wekelijks) dan producten die door de back-ends worden aangeboden (trimestrieel). Ontwikkeling en installatie processen en hun bijbehorende tooling, die verschillende technologieën, ontwikkelaar profielen en verwachtingen scheppen, moeten deze diversiteit van behoeften kunnen ondersteunen. Eindgebruikerservaring We gaan voor een passende eindgebruikerservaring die herbruikbaar is binnen verschillende web sites en mobiele toestellen. De passende gebruikerservaringen worden zoveel mogelijk bepaald op basis van de volledige cross-channel ervaring van de eindgebruiker ook wel customer journey genoemd. Dit betekent dat binnen een algemeen aanvaarde huisstijl (en een huisstijl per lokale entiteit), stijl gidsen (style guides) moeten worden gedefinieerd en geïmplementeerd, die bepalend zijn voor de keuze van UI-applicatie patronen. Zoals adaptieve schermen gebaseerd op de rol(len) van de eindgebruiker. Technologie standaardisatie We willen een éénmalige integratie met de achterliggende systemen en applicaties door meer in te zetten op service georiënteerde oplossingen. Reduceren van de technologiekosten door gebruik te maken van service georiënteerde oplossingen die worden aangedreven door interoperabiliteit, teneinde de herbruikbaarheid van de achterliggende systemen en applicaties te verhogen. Om interoperailiteit te organiseren, moeten applicaties worden ingedeeld in drie soorten applicaties: * consumer services in de front-ends of end-user experience, die informatie (inhoud) aan de eindgebruiker leveren * broker services in de service-communication laag, die de verzoeken van eindgebruikers van een willekeurig aantal consumer services naar provider services beheren. * provider services , in de back-ends of core systems laag, die informatie (inhoud) verschaffen, al dan niet via broker services, door toegang te krijgen tot gegevens die worden beheerd door een bepaald kern systeem (CRM, ERP, ...). De gegevensstromen die tussen de bovenstaande applicaties worden gebruikt, omvatten standaard gegevensformaten en protocollen, die worden beschreven in integratie architectuur documenten. Levenscyclusbeheer We willen een duidelijk zicht krijgen hoelang systemen en applicaties in de organisatie worden gebruikt. Men weet welke systemen & applicaties in de organisatie worden gebruikt om de organisatie te veranderen door middel van innovaties, en/of transformaties en/of verbeteringen. Maar ook welke systemen & applicaties er gebruikt worden om de organisatie draaiende te houden. Als gevolg hiervan moeten we ons ervan bewust zijn dat niet alle (huidige) ICT oplossingen worden geleverd met de bedoeling om eeuwig mee te gaan. Sommige ICT oplossingen voor nieuwe ideeën zijn erop gericht om snel te worden vervangen, zoals prototypes. Andere ICT oplossingen zijn er als 'enabler' voor gemeenschappelijke ideeën en worden daarom geleverd met de bedoeling om lang mee te gaan. Daarom is een technologie selectie proces nodig ondersteund door architectuur, zodat we de juiste investeringsbeslissingen kunnen nemen over de verderzetting van ICT oplossingen. Een heat-map dus met de betrokken applicaties en systemen. Schaalbaarheid We willen schaalbare systemen en applicaties om de toenemende communicatie, data en gebruik onderling tussen eindgebruikers, systemen en applicaties, aan te kunnen. De systemen en applicaties verwerken de toenemende werkdruk, volgens de eisen van de (eind)gebruikers, op een verwachte manier zonder daarbij in de fout te gaan. Dit door extra 'resources' toe te voegen aan het ICT landschap, extra vermogen voor deze 'resources' en een efficiënt beheer van het werkgeheugen en data. Systemen en applicaties zouden bij voorkeur steeds meer in de cloud of in tweede orde op schaalbare on-prem infrastructuur moeten worden aangekocht en/of geïmplementeerd. De applicaties moeten ook worden gekocht en/of gebouwd met het oog op 'service stateless', wat inhoudt dat (status) gegevens in een 'in-memory state' zoveel mogelijk dienen te worden gepersisteerd naar (tijdelijke) schaalbare databronnen. Bedrijfsbeveiliging We zorgen er voor dat de communicatie, data en gebruik onderling tussen eindgebruikers, systemen en applicaties op een veilige manier gebeuren. Alle ICT-oplossingen die binnen de organisatie worden gebruikt, moeten voldoen aan alle beveiligings- en privacybeleidsregels om de kans op inbreuken te verkleinen of liefst onmogelijk te maken. Gegevens zijn daardoor beschermd tegen ongeautoriseerd gebruik en openbaarmaking. Beveiliging moet in de eerste plaats vanuit een business perspectief worden bekeken, omdat beveiligingsbeleid nauw verband houdt met business veranderingen. De (lokale) organisatie(s) dient/dienen hiervoor een eigen beveiligingsbeheer (bv. group policies op departement, dienst, team, ...) te hebben waar eindgebruikers (users), rollen, toegankelijkheid, ... lokaal en centraal beheerd kunnen worden via duidelijke procedures, richtlijnen en standaarden. Als gevolg hiervan zullen we alleen toegang tot gegevens verlenen aan die personen die toegang zouden moeten hebben. Databeveiliging We willen vermijden dat de manier waarop data wordt behandeld en beheerd, grote beperkingen opleveren in de uitvoering van de activiteiten binnen de organisatie, waarbij we data zien als een enabler en niet als knelpunt. We zien data als een troef (data as a product) waaruit we verschillende voordelen kunnen creëren zoals de behoeften en ervaringen van de (eind)gebruikers beter leren kennen om een betere relatie te ontwikkelen, sneller kunnen reageren op veranderingen, verhogen van de operationele efficiëntie door transparante communicatie, beter kunnen beslissen via huidige en toekomstige inzichten, snellere verwerking van (gewijzigde) wet- en regelgevingen via notificaties uit betrouwbare bronnen, verlagen van allerlei risico's door hogere data kwaliteit, ... met data als onderdeel van de organisatie cultuur. Een data-gedreven organisatie omvat het correct classificeren via een betere segmentatie en gerichte communicatie in de organisatie. De organisatie en haar entiteiten hebben hiervoor een afgestemde data management en governance zodat (lokaal) georganiseerde data door de juiste stakeholders kan worden vertrouwd, georganiseerd en geconsumeerd. Een goed draaiende 'information management' haalt steeds meer gegevens uit interne systemen en applicaties en maak beter en nuttig gebruik van externe data, waarbij data kwaliteit van groot belang is voor het bepalen van efficiënte inzichten en nakomingen van o.a. GDPR regelgevingen. Om de datastromen die vertrekken van de operationele omgevingen naar de comsumptie omgeving in goede banen te leiden, is een overkoepelende Data Flow Manager (DFM) nodig om de data binnen en buiten de organisatie op te nemen, te transformeren en te distribueren. De hoofdtaak van de DFM is om data te verplaatsen en te laten evolueren over drie verschillende DFM-lagen, nl.: # Onboarding Data Layer , waarbij de data van de operationele omgevingen eerst tijdelijk worden opgeslagen in Landing Zones om ze nadien te consolideren waarop regels kunnen worden toegepast. De data met conflicten worden in een aparte quarantaine geplaatst, zodat de bronnen in de operationele omgevingen die kunnen verbeteren en opnieuw kunnen introduceren. # Integration Layer , waarbij de aanvaarde data wordt geïntegreerd volgens het business data model van de organisatie # Consumption Layer , zodat de (eind)gebruikers de benodigde gegevens in de meest geschikte formaten en technologieën, kunnen consumeren Enterprise specifieke architectuur Duidelijke indicatie van de business-, informatie- en applicatie architectuur op de gedetecteerde capabilities Strategic Control, Supplier Management, Marketing Management, Suppply Chain Management, Sales & Distribution Management, Customer Management, Contact Center Management & Information Mangement . Enterprise Business architectuur Capability realisatie vanuit een business perspectief, start vanuit business functies.  Een business functie is een concept dat wordt gebruikt in het domein Business Architecture en vertegenwoordigt wat er wordt gedaan. Dit betekent dat we kijken naar het gedrag, de acties, oftewel wat er GEBEURT. Incentivering business architectuur tekening Incentivering business architectuur beschrijvingen Hierbij een lijst van de business functies die een extra woordje uitleg nodig hebben. Business functie Omschrijving Beheer tarificatie Tarificatie bevat de business logica om de prestaties van de Consumenten, alsook de handelstransacties van de Aanbieders te verwerken volgens de nomenclatuur. Tevens communiceert ze de verschillende tarificatie stappen met de financiële dienst. Beheer facturatie Facturatie verwerkt de binnenkomende vorderingen van de Aanbieders, stelt facturen op naar de Donors, berekent de verdeling van de uitbetalingen naar de Aanbieders en communiceert de verschillende facturatie stappen met de financiële dienst. Financieel & klanten beheer Boeken van (correcties op) vorderingen, voorschotten, provisies, saldi, ... Zakelijke woordenlijst Het hoofddoel van de zakelijke woordenlijst is om ons begrip van algehele terminologie te verbeteren, zodat we effectiever kunnen communiceren in de hele organisatie, in plaats van mensen woorden anders te laten gebruiken of hun eigen interne vocabulaire te laten ontwikkelen, wat leidt tot zinloze discussies. Data governance Het organiseren van een efficiënte informatiestroom binnen de organisatie, ervoor zorgen dat deze gemakkelijk vindbaar en moeiteloos toegankelijk is, rekening houdend met de geldende privacy wetgeving. Data beheer Beheer van (master)databronnen, waardoor data effectief en efficiënt kunnen worden ontsloten, verwerkt en gebruikt. Intelligentie beheer Het organiseren van het verzamelen, vormgeven en delen van (inzichtelijke) informatie-elementen over één enkel of een groep van onderwerpen en/of dingen . Inzicht in deze onderwerpen en dingen en hun gedrag door het profiel van een onderwerp of ding te beschrijven, ze in segmenten te groeperen, voorkeuren te voorspellen en de evolutie van het gedrag van deze onderwerpen en dingen in de loop van de tijd te volgen. Enterprise Information architectuur De business objecten, binnen de informatie architectuur, worden gebruikt om de bedrijfsconcepten en terminologie te communiceren en te beheren, samen met de bijbehorende definities en relaties tussen die termen. Bij business objecten kijken we naar de statische werkelijkheid, wat HEBBEN we. We onderscheiden 3 niveau’s : Het hoogste niveau zijn de informatie onderwerp gebieden of subject area’s, zodat men sneller kan navigeren naar deze gebieden die het meest interessant zijn en reeds eerste definities en relaties kunnen worden opgesteld en bepaald. Het tweede niveau zijn de L2-business objecten en deze maken deel uit van minstens één informatie onderwerp gebied. L2-business objecten zijn voor het merendeel een abstractie van de OSLO kern data entiteiten, dus zonder gerelateerde data entiteiten. Het derde niveau zijn de L3-business objecten en hun gerelateerde data entiteiten. Zij worden gekoppeld aan L3-business processen met vermelding van hun CRUD-actie (Create, Read, Update & Delete). Deze viewpoints worden beschreven in het Solutions Continuüm en maken  dus geen deel uit van deze architectuur studie. Incentivering Supply Chain information architectuur tekening Incentivering Supply Chain informatie beschrijvingen Hierbij een lijst van de informatie elementen die een extra woordje uitleg nodig hebben. Subject Area of Business object OSLO-type Omschrijving Sponsor JA AGENT (generieke OSLO-classe). Consument JA AGENT (generieke OSLO-classe). Iemand die of iets dat kan handelen of een effect kan teweeg brengen. Aanbieder JA AGENT (generieke OSLO-classe). Aanbieder van het stimulansaanbod CriteriumVereiste JA Criterium dat toelaat te bepalen of een gebruiker recht heeft op een stimulansaanbod. Stimulansaanbod JA Bewijs JA De beschrijving van wat men moet voorleggen om te kunnen voldoen aan de CriteriumVereiste(n) van een specifiek Stimulansaanbod. Beloning JA Beschrijving van de beloning die bij een stimulansaanbod hoort. Dit is wat zal ontvangen worden bij de consumptie van dit stimulansaanbod. Dit is niet de effectief ontvangen beloning, maar de beschrijving van wat je zal ontvangen. Stimulans consumptie JA Consumptie van een stimulansaanbod Beloningsontvangst JA De effectieve beloning die ontvangen is bij de consumptie van een stimulansaanbod Bewijslevering JA Het bewijs dat effectief geleverd wordt bij de consumptie van het stimulansaanbod door een Agent. Incentivering Marketing informatie architectuur tekening Incentivering Marketing informatie beschrijvingen Hierbij een lijst van de informatie elementen die een extra woordje uitleg nodig hebben. Subject Area of Business object OSLO-type Omschrijving Product aanbiedingen NEE Vrijwillige maar voorwaardelijke toezegging die ter acceptatie aan de consument via een advertentie werd voorgelegd en die commercieel afdwingbaar wordt als deze door de consument wordt geaccepteerd. Campagnes NEE Een campagne is een gegroepeerde actie om gedurende een bepaalde periode een product aanbieding te promoten om consumenten te boeien Marketing betrokkenen NEE Een partij (individu of organisatie) die een interactie heeft met een handelaar, om een product en/of dienst te leveren. Marketingkanalen NEE Een marketingkanaal is waarop een burger of consument wordt blootgesteld aan het merk, product, dienst, ... van een bepaalde handelaar (via een marketing agentschap). Dus elke interactie die de perceptie van de consument kan veranderen. Promoties NEE Is een marketingactie die bestaat uit het bezorgen van een specifieke boodschap aan een specifieke subgroep van geselecteerde betrokkenen voor een bepaalde marketingcampagne. Sponsor JA AGENT (generieke OSLO-classe). Consument JA AGENT (generieke OSLO-classe). Iemand die of iets dat kan handelen of een effect kan teweeg brengen. Aanbieder JA AGENT (generieke OSLO-classe). Aanbieder van het stimulansaanbod DirectMarketing JA Directe communicatie met de consument, dit kan via kanalen zoals e-mail, sociaal media, (push) notificaties, websites, webchat, ... Consent NEE Vrijwillige indicatie van de wens van de burger of consument waarmee hij/zij akkoord gaat met de verwerking van de betreffende persoonsgegevens voor een bepaalde vorm van verwerking. Een toestemming kan 3 statussen hebben gegeven, niet gegeven of ingetrokken. Distributie JA PublicRelations JA Campagne met als doel om het imago te verbeteren VerkoopPromotie JA Reclame, advertenties, korting, PublicatieEvent JA Een PublicatieEvent zal altijd deel uitmaken van een bredere Campagne. Dit maakt het mogelijk om een Campagne op te starten die meerdere PublicatieEvents kan omvatten. Bevat o.a. de attribuut 'PublicatieKanaaltype' en dat kanaal wordt gebruikt om publicatie te verspreiden en staat dus dichter bij het publiceren ipv het maken van de inhoud. Campagne JA Een Campagne is het geheel van acties om te informeren en het stimuleren van gewenst gedrag bij het doelpubliek. InformatieObject JA InformatieObject kan de vorm aannemen van tekst, beeld, audio PublicatieExpressie JA Bevat o.a. de attribuut 'PublicatieTooltype' en die tool wordt gebruikt om publicatie te maken en staat dus dichter bij het maken van inhoud ipv het publiceren. Stimulansaanbod JA Incentivering Contact Center informatie architectuur tekening Incentivering Contact Center informatie beschrijvingen Hierbij een lijst van de informatie elementen die een extra woordje uitleg nodig hebben. Subject Area of Business object OSLO-type Omschrijving InformeerActie JA OSLO-Notificatie:InformeerActie Kennisgeving van informatie aan zij die het aanbelangt. Deze informatie kan via meerdere kanalen naar een individu of naar een doelgroep genotificeerd worden. NotificatieBericht JA OSLO-Notificatie:Notificatiebericht Een bericht van een afzender naar een bestemmeling met als doel het informeren van de bestemmeling. Melding JA OSLOthema-melding:Melding Beschrijft de melding van een probleem of een vaststelling die mogelijks aanleiding geeft tot een actie van de overheid. De Melding kan gebruikt worden voor het capteren van feedback met betrekking tot concrete informatievelden. Terugmelding JA OSLOthema-melding:Terugmelding Beschrijft de terugmelding van fouten of onvolledigheden in digitale gegevensbronnen naar de verantwoordelijke bronbeheerder. Een terugmelding kan gebruikt worden om bijvoorbeeld een foutief adres te melden op een website of een fout in de digitale weergave van een diploma. Meldingsobject JA OSLOthema-melding:Meldingsobject Het Meldingsobject identificeert een resource,een specifiek deel van een resource,een bepaalde representatie van een resource of een combinatie hiervan welke gebruikt wordt binnen de (Terug)Melding. In de praktijk kan het Meldingsobject beschreven worden aan de hand van instanties van de klasse Eigenschap. Het Meldingsobject heeft een Dataset als bron en een TijdToestand, om de datum en het tijdstip vast te leggen, waarop het Meldingsobject dient ge nterpreteerd te worden. De klasse Eigenschap beschrijft de data velden waaruit een Dataset bestaat met Concept waarden bestaande uit een exhaustieve lijst aan mogelijk waarden (bv. een codelijst). Behandelaar JA OSLO-Generiek:Agent (Applicatie, Organisatie of Persoon) Agent die werd aangewezen om de melding en/of het meldingsobject op te volgen en af te handelen. Indiener JA OSLO-Generiek:Agent (Applicatie, Organisatie of Persoon) Agent die de Melding heeft aangemaakt en/of ingediend. Betrokkene JA OSLO-Generiek:Agent (Applicatie, Organisatie of Persoon) Agent die als derde belang heeft bij de Melding of ge mpacteerd is door de behandeling ervan. Bijvoorbeeld indien de melding werd aangemaakt door een derde, bijvoorbeeld een ambtenaar van de gemeente op vraag van een burger. Melder JA OSLO-Generiek:Agent (Applicatie, Organisatie of Persoon) De Agent die het probleem waarover gemeld wordt opmerkte. De melder zal niet telkens gekend zijn. Bijvoorbeeld in het geval van een anonieme melding via een website. Enterprise Applicatie architectuur De Applicatie Architectuur ondersteunt de Business Architectuur. De L2-Application Components realiseren de L1-capabilities, waarbij de L3-applicatie elementen, die behoren tot het Solutions Continuüm en niet in-scope voor deze studie, een "implementatie" is van de L3-business processen. Incentivering applicatie architectuur tekening Hierbij een lijst van de applicatie componenten die een extra woordje uitleg nodig hebben. Applicatie Component Omschrijving Strategic Management Tool Strategic management tools omvatten instrumenten als een SWOT-analyse en een PEST-analyse. Men gebruikt deze tools voor strategische managementplanning om precies te bepalen waar men de komende jaren en daarna naartoe gaat en hoe ze daar moeten komen. Data Explorer Technologie dat op een eenvoudige wijze de evolutieve ‘Onboarding’ gegevens kan opnemen waarop men binnen enkele seconden, complexe ad-hoc queries op deze gegevens kan uitvoeren. De source connectoren zijn verantwoordelijk om een technische verbinding te maken met de externe bron en leest de brongegevens uit in de meeste geschikte formaat volgens de data-verantwoordelijke van de brongegevens, na voorlegging van gesupporteerde connectoren van de gekozen ‘Data Explorer’ technologie. Indien de gewenste connector niet standaard aanwezig is, moet het mogelijk zijn om een custom connector te maken. ETL Technologie dat bij het beheren van databanken verwijst naar extraheren (Extract), transformeren (Transform) en laden (Load) naar drie afzonderlijke functies die worden gecombineerd in één technologisch platform. API Management API-management technologie wordt ingezet om een zo goed mogelijk beheer te hebben van gegevensuitwisseling, dit zowel voor de data-consument (consumer) als voor data-producent (producer). APIs stellen gegevens ter beschikking voor consumptie via drie specifieke 'Loads' meestal binnen een near/real-time streaming context waarbij de consumer applicatie zich aanpast aan de aangeboden data definities van de APIs: * initial loads, eerste keer, met geplande downtimes en meestal grote hoeveelheid aan data * incremental loads, volgende keren, met eventuele downtimes en meestal minder grote hoeveelheid aan data aangezien deze worden uitgevoerd na initial loads. * recurring loads, voor gewijzigde gegevens via zero-downtime deployment d.m.v. on-the-fly schema migraties (delta files) en meestal voor kleine hoeveelheid aan data aangezien deze gebeuren na de incremental loads. Men dient voor deze ‘Load’ type wel de keuze te maken om dit ofwel verder aan te bieden via het data of applicatie integratie platform. Business Intelligence (BI) Technologie ten dienste voor de: * data-analist: ze analyseren de verstrekte gegevens om bv. de omzet van de organisatie te verbeteren. Ze hebben mogelijk een data-mart nodig, inclusief enkele aggregaties, toegepaste bedrijfsregels en filtering, en het gebruik van een datamodel als dimensionale modellering die analytische query's mogelijk maakt. * BI-ontwikkelaar: ze hebben toegang tot de ‘Organized Data’ om data marts, BI-rapporten en dashboards te maken voor de data-analisten en/of BI-eindgebruikers. * BI-eindgebruiker: ze hebben gegevens nodig uit de ‘Organized Data’ en/of de beschikbare data marts van de BI-ontwikkelaars, alsook self-service BI tooling dat hen in staat stelt om de gegevens te verkennen en te exploiteren. Artificial Intelligence (AI) Technologie dat de data scientist in staat stelt om data: * te verkennen: gegevens worden verkend om te selecteren welke gegevens nuttig zijn voor hun model * te exporteren: nadat de gegevens zijn geselecteerd tijdens de verkenning, exporteren de data scientists de vereiste gegevens naar hun eigen data science workbench om feature-engineering en model training op te starten. * te industrialiseren: wanneer het analytische model klaar is om in productie te worden gebruikt, zal een geautomatiseerd proces de gegevens van de ‘Organized Data’ exporteren naar de data science industrialization omgeving. * te trainen: data scientists moeten hun analytisch model ook vaak trainen en kalibreren op basis van productie gegevens. * Data scientists gebruiken o.a. tools en talen als python, R, databricks, ...om de data te analyseren en analyse modellen te creëren. Datawarehousing Is de technologie waar de gegevens centraal worden gehistoriseerd waaruit men verder deze gegevens geaggregeerd, getransformeerd en verrijkt kunnen ophalen om geinformeerde keuzes te kunnen maken d.m.v. rapportages of/en-analyses. Master Data Management Is de technologie om de belangrijkste bedrijfsgegevens te beheren ter ondersteuning van de transactionele of operationele gegevens. Master data beschrijft op een unieke wijze de klanten, medewerkers, materialen, leveranciers, enz. die bij data uitwisseling betrokken zijn. Ze worden typisch onderverdeeld in ofwel Plaatsen (locaties, geografie, sites, ...), Partijen (personen, klanten, leveranciers, werknemers, ...) en Dingen (producten, materiaal, voertuigen, ...). Document Management ERP Via een ERP-oplossing kan elke afdeling of elk bedrijfsdomein onafhankelijk en centraal beheerd worden. Voordelen zijn onder meer interoperabiliteit van gegevens, verbeterde communicatie en verhoogde gegevensbetrouwbaarheid door het gebruik van een enkele database. ERP verbetert ook de kwaliteit van bedrijfs-brede besluitvorming. Een op maat gemaakte bestelling kan bijvoorbeeld van de verkoopafdeling naar voorraadbeheer gaan en vervolgens naar facturering naar financiën en productie. Door een ERP te gebruiken, is dit type proces een efficiënte en continue reeks gebeurtenissen die het gemakkelijk maken om individuele bestellingen te volgen. CRM Customer Relationship Management (CRM) is een technologie voor het centraal beheer van alle relaties en interacties van een organisatie met zijn (externe) contactpersonen. Een CRM-systeem biedt een 360-graden beeld van hun contact, waardoor ze betere relaties kunnen opbouwen door persoonlijker en relevanter te communiceren. Derdebetalersysteem Het derdebetalerssysteem verwijst naar de mogelijkheid om het volledige bedrag van handelstransacties niet direct te moeten betalen in digitale munt. Het is een soort alternatief voor de klassieke terugbetaling, een meer directe en toegankelijke oplossing. Bij dit systeem wordt de ontvanger rechtstreeks door de donor vergoed. Dit betekent dat er geen directe betaling moet gebeuren tussen de burger en ontvanger en dat de ontvanger na de prestatie wordt terugbetaald. Als men een derdebetalerssysteem toepast, betaalt men alleen het persoonlijk aandeel, indien van toepassing, d.w.z. het bedrag dat na tussenkomst van de donor nog voor eigen rekening van de burger blijft.  
Prioriteringsoefening Regionaal plugable incentiveringsplatform – Geel +
  +
DeliverableStakeholderAnalyse +
Inleiding Deze pagina bevat de eerste versie van stakeholder analyse. Het is een niet finale versie die we v0.1 noemen. 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. Situering van deze deliverable in het traject Deze deliverable wordt uitgewerkt na de kennismakingsworkshop en het VLOCA-model V0.1 en wordt opgeleverd bij de opstartworkshop van het traject (workshop 1). 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. Dit document vormt een basis voor het verdere verloop van het traject. In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. Doel en doelgroep 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. De analyse werkt verder uit hoe we welke stakeholders moeten betrekken en communiceren. Initiatiefnemers (lokale en bovenlokale besturen): De initiatiefnemers werken aan de hand van deze pagina de inhoud verder uit, waarna validatie volgt. Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be . Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) 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. 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. Burgers en burgergroeperingen: 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. Aanpak (korte beschrijving) Een volledige omschrijving van de stakeholder analyse kan je hier lezen. Inhoud Hieronder kan je de elementen van de stakeholder analyse bekijken.  
DeliverableVlocaModel +
Inleiding Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we 0 noemen. 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. Situering van deze deliverable in het traject Deze eerste versie van het VLOCA model is een werkdocument dat in een latere fase van het traject verder verfijnd en uitgewerkt wordt. 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. Dit document vormt een basis voor het verdere verloop van het traject. In dit overzicht kan je de fasering en andere deliverables binnen een VLOCA traject bekijken. Doel en doelgroep 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. Lokale besturen: Lokale besturen worden uitgenodigd om inhoudelijk mee te werken aan aan de co-creatie over dit thema. Laat ons weten dat je wenst deel te nemen, en geef je inhoudelijke opmerkingen door op vloca@vlaanderen.be . Dit kan je in de nabije toekomst doen door op de discussie pagina van deze wiki pagina. (op dit moment nog in ontwikkeling) 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. 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. Burgers en burgergroeperingen: 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. Aanpak (korte beschrijving) Andere versie Inhoud Hieronder kan je de elementen van versie 0 van dit VLOCA model bekijken.  
DenCITY +
Korte Beschrijving Overzicht van de DenCITY locaties in de smart Zone in Antwerpen DenCITY is een real time luchtkwaliteitsmonitoring project in Antwerpen, waarbij luchtkwaliteitssensoren voor PM 10 , PM 2.5 , NO 2 en O 3 getest werden in labocondities en vervolgens geinstalleerd op 35 locaties in de Smart Zone in Antwerpen. Daarnaast werd een real-time versie van het ATMO-Street model opgezet en een data assimilatie keten die de real time sensor informatie verwerkte tot een verbeterde, ruimtelijk explicite, real time inschatting van de locale luchtkwaliteit in Antwerpen. Beschrijving Architectuur Onderstaand diagram geeft een schematisch overzicht weer van de opgezette architectuur binnen DenCITY. Databronnen In DenCITY wordt data gegenereerd door low cost luchtkwaliteitssensoren , die sturen hun data via LoRa verbinding naar een IoT agent die de datastroom omzet naar NGSI-v2 om die vervolgens te posten op de DYAMAND Context broker . Daarnaast werd ook gebruik gemaakt van de VMM luchtkwaliteitsmeetposten. De data hiervan wordt door IRCEL ontsloten via een OGC Sensor Observation Service waarlangs de real time luchtkwaliteitsmetingen van het telemetrisch netwerk als Open Data worden beschikbaargesteld. Verkeerstellingen uit het telraam initiatief werden gebruikt om tot een verbeterde inschatting van verkeersemissies te bekomen in het luchtkwaliteitsmodel. Deze data worden via een REST-API [1] ter beschikking gesteld. Informatie omtrent de gebouwhoogtes en de ligging van de straatsegementen om de street canyon bijdrage te kunnen berekenen in het luchtkwaliteitsmodel werden gedownload onder de vorm van shapefiles uit het 3D GRB , ter beschikking gesteld door AIV en van het Openstreetmap initiatief respectivelijk. Real-time data flow Toegevoegd De real time sensor data wordt ter beschikking gesteld via een NGSI-v2 compliant context broker . Deze wordt gevoed vanuit de luchtkwaliteitssensoren via een NGSI Agent die de data vertaald in NGSI entities volgens het FIWARE AirQualityObserved data model. Meteo data afkomstig van het Europees Centrum voor Medium Range Weather Forecasts (ECMWF) wordt via REST-API binnengehaald en vertaald door een NGSI agent in een WeatherObserved entitie en zo op de context broker aangeboden. Gezien de kwaliteit van de low cost sensor data niet altijd gegarandeerd is, werden uitgebreide labo tests uitgevoerd, op basis hiervan werden algoritmes opgesteld en een cloud gebaseerd real time calibratie systeem opgezet. Deze component maakt handig gebruik van de beschikbare meteo gegevens in de context broker (WeaterObserved entities). En pusht verrijkte AirQualityCalibrated entities terug op de broker. Deze component in de architectuur is geïmplementeerd als subscriber op de FIWARE AirQualityObserved en WeatherObserved entities in de context broker . De data die op de context broker verschijnt wordt via een QuantumLeap REST service naar een tijdsreeks databank gestuurd op de [1] . Naast de real time sensor gegevens is in deze proof of concept ook een real-time luchtkwaliteitmodel keten opgezet, waarbij de gecalibreerde luchtkwaliteits sensordata vanaf de context broker door een data assimilation agent worden geconverteerd naar CSV bestanden om te voldoen aan input vereisten van het luchtkwaliteitsmodel. Naast de real time low cost sensor metingen maakt het luchtkwaliteitsmodel ook gebruik van de VMM luchtkwaliteit referentiemetingen, die via Sensor Observation Service worden aangeboden. Het luchtkwaliteitsmodel haalt z'n meteo data uit de meteo service binnen via een specifieke API die toelaat om NetCDF bestanden te downloaden met 4D meteo model data. De ruimtelijk expliciete modelkaarten die het resultaat zijn van de geassimileerde real time luchtkwaliteitsmodellering worden in een GIS databank bijgehouden en via een Geoserver als OGC Web Map Service ontsloten. Op die manier kon heel makkelijk een app gebouwd worden die een ruimtelijk expliciet beeld geeft van de actuele luchtkwaliteit. Referenties ↑ https://telraam-api.net/ Lessons learned Tegen volgende zaken zijn we aangebotst : eenvoudige beschrijving van geografische data in NGSI data model is onvoldoende, ontbreken van geospatiale functionaliteiten m.b.t. locaties linken van meta data in geospatiale databanken aan real time dataflows : welk process opzetten om real time geospatiale meta data (e.g. opgeslagen in een PostgresSQL/PostGIS databank in sync te houden met real time IoT dataflows bij vervanging van sensoren & updates sensor data postproductie nodig bij offline calibratie algoritmes, hoe omgaan met versiebeheer voor historische sensor data. Deze pagina beschrijft een fictief initiatief dat als illustratie kan dienen voor de informatie die we wensen te capteren op de kennishub. Deze beschijving is gebaseerd op het oorspronkelijke DenCITY project, waarin de bedoeling was om een dicht stedelijk luchtkwaliteit sensornetwerk op te zetten en zo luchtkwaliteitsmodellen te verrijken met real time informatie. Deze illustratieve case werd verder verrijkt met enkele architecturale elementen, semantische links etc... om het ingeven van informatie op de kennishub te illustreren. Onderstaande beschrijving wijkt m.a.w. af van de originele opzet van het project.  
DenCITY +
Korte Beschrijving Overzicht van de DenCITY locaties in de smart Zone in Antwerpen DenCITY is een real time luchtkwaliteitsmonitoring project in Antwerpen, waarbij luchtkwaliteitssensoren voor PM 10 , PM 2.5 , NO 2 en O 3 getest werden in labocondities en vervolgens geinstalleerd op 35 locaties in de Smart Zone in Antwerpen. Daarnaast werd een real-time versie van het ATMO-Street model opgezet en een data assimilatie keten die de real time sensor informatie verwerkte tot een verbeterde, ruimtelijk explicite, real time inschatting van de locale luchtkwaliteit in Antwerpen. Beschrijving Architectuur Onderstaand diagram geeft een schematisch overzicht weer van de opgezette architectuur binnen DenCITY. Databronnen In DenCITY wordt data gegenereerd door low cost luchtkwaliteitssensoren , die sturen hun data via LoRa verbinding naar een IoT agent die de datastroom omzet naar NGSI-v2 om die vervolgens te posten op de DYAMAND Context broker . Daarnaast werd ook gebruik gemaakt van de VMM luchtkwaliteitsmeetposten. De data hiervan wordt door IRCEL ontsloten via een OGC Sensor Observation Service waarlangs de real time luchtkwaliteitsmetingen van het telemetrisch netwerk als Open Data worden beschikbaargesteld. Verkeerstellingen uit het telraam initiatief werden gebruikt om tot een verbeterde inschatting van verkeersemissies te bekomen in het luchtkwaliteitsmodel. Deze data worden via een REST-API [1] ter beschikking gesteld. Informatie omtrent de gebouwhoogtes en de ligging van de straatsegementen om de street canyon bijdrage te kunnen berekenen in het luchtkwaliteitsmodel werden gedownload onder de vorm van shapefiles uit het 3D GRB , ter beschikking gesteld door AIV en van het Openstreetmap initiatief respectivelijk. Real-time data flow Toegevoegd De real time sensor data wordt ter beschikking gesteld via een NGSI-v2 compliant context broker . Deze wordt gevoed vanuit de luchtkwaliteitssensoren via een NGSI Agent die de data vertaald in NGSI entities volgens het FIWARE AirQualityObserved data model. Meteo data afkomstig van het Europees Centrum voor Medium Range Weather Forecasts (ECMWF) wordt via REST-API binnengehaald en vertaald door een NGSI agent in een WeatherObserved entitie en zo op de context broker aangeboden. Gezien de kwaliteit van de low cost sensor data niet altijd gegarandeerd is, werden uitgebreide labo tests uitgevoerd, op basis hiervan werden algoritmes opgesteld en een cloud gebaseerd real time calibratie systeem opgezet. Deze component maakt handig gebruik van de beschikbare meteo gegevens in de context broker (WeaterObserved entities). En pusht verrijkte AirQualityCalibrated entities terug op de broker. Deze component in de architectuur is geïmplementeerd als subscriber op de FIWARE AirQualityObserved en WeatherObserved entities in de context broker . De data die op de context broker verschijnt wordt via een QuantumLeap REST service naar een tijdsreeks databank gestuurd op de [1] . Naast de real time sensor gegevens is in deze proof of concept ook een real-time luchtkwaliteitmodel keten opgezet, waarbij de gecalibreerde luchtkwaliteits sensordata vanaf de context broker door een data assimilation agent worden geconverteerd naar CSV bestanden om te voldoen aan input vereisten van het luchtkwaliteitsmodel. Naast de real time low cost sensor metingen maakt het luchtkwaliteitsmodel ook gebruik van de VMM luchtkwaliteit referentiemetingen, die via Sensor Observation Service worden aangeboden. Het luchtkwaliteitsmodel haalt z'n meteo data uit de meteo service binnen via een specifieke API die toelaat om NetCDF bestanden te downloaden met 4D meteo model data. De ruimtelijk expliciete modelkaarten die het resultaat zijn van de geassimileerde real time luchtkwaliteitsmodellering worden in een GIS databank bijgehouden en via een Geoserver als OGC Web Map Service ontsloten. Op die manier kon heel makkelijk een app gebouwd worden die een ruimtelijk expliciet beeld geeft van de actuele luchtkwaliteit. Referenties ↑ https://telraam-api.net/ Lessons learned Tegen volgende zaken zijn we aangebotst : eenvoudige beschrijving van geografische data in NGSI data model is onvoldoende, ontbreken van geospatiale functionaliteiten m.b.t. locaties linken van meta data in geospatiale databanken aan real time dataflows : welk process opzetten om real time geospatiale meta data (e.g. opgeslagen in een PostgresSQL/PostGIS databank in sync te houden met real time IoT dataflows bij vervanging van sensoren & updates sensor data postproductie nodig bij offline calibratie algoritmes, hoe omgaan met versiebeheer voor historische sensor data. Deze pagina beschrijft een fictief initiatief dat als illustratie kan dienen voor de informatie die we wensen te capteren op de kennishub. Deze beschijving is gebaseerd op het oorspronkelijke DenCITY project, waarin de bedoeling was om een dicht stedelijk luchtkwaliteit sensornetwerk op te zetten en zo luchtkwaliteitsmodellen te verrijken met real time informatie. Deze illustratieve case werd verder verrijkt met enkele architecturale elementen, semantische links etc... om het ingeven van informatie op de kennishub te illustreren. Onderstaande beschrijving wijkt m.a.w. af van de originele opzet van het project.  
DenCITY architecture.png +
  +
DenCITY locations.png +
  +
Denmark IoT and Smart Cities +
Denemarken heeft zich ook recent geëngageerd vanuit het Deense instituut voor Standaarden om een nationale vertaling te maken van internationale open city Standaarden . Meer info is via deze link beschikbaar.  +
Destination Earth +
Summary Destination Earth also known as DestinE, is an initiative from the European Commission of Ursula Von der Leyen. It aims to create a digital simulation of Earth with a digital twin that will be used to better understand the effects of climate change and environmental disasters and to permit policymakers more effectively respond to these issues. The project Destination Earth embodies the wider scope of the Von der Leyen’s Commission. The project inscribes itself in the two-key priorities of the Commission which are the digital transition and climate transition, aiming together to achieve carbon neutrality by 2050. Integrated to the Digital Europe Programme and the European Green Deal, Destination Earth projects to create a digital simulation of Earth with a digital twin of our planet meaning an exact digital reproduction of the Earth. It will use an unprecedented amount of real-time data from climate, meteorological, behavioral, atmospheric sensors to develop this high-precision model of our planet. This very precise digital model of the Earth would enable different user groups such as public groups and the scientific and private communities to monitor and simulate natural and human activity, and to develop test scenarios in order to better predict the effects of climate change. With the current climate change challenge, this initiative is very relevant. Using DestinE modeling, the European Commission, as part of the European Green Deal, and also states will be able to evaluate the impact and efficiency of environmental legislative proposals. Scope DestinE will unlock the potential of digital modelling of the Earth system. It will focus on the effects of the climate change, water and marine environments, polar areas, cryosphere, biodiversity or extreme weather events, together with possible adaptation and mitigation strategies. It will help to predict major environmental degradation and disasters with unprecedented fidelity and reliability. By opening up access to public datasets across Europe, DestinE represents also a key component of the European strategy for data. Users of DestinE will be able to access vast amounts of natural and socio-economic information in order to: Continuously monitor the health of the planet: For example, to study the effects of climate change, the state of the oceans, the cryosphere, biodiversity, land use, and natural resources. Support EU policy-making and implementation: For example, to assess the impact and efficiency of environmental policy and relevant legislative measures. Perform high precision, dynamic simulations of the Earth’s natural systems, focusing on thematic domains such as marine, land, coasts, and atmosphere. Improve modelling and predictive capacities: For example, to help anticipate and plan measures in case of storms, floods and other extreme weather events and natural disasters. Reinforce Europe’s industrial and technological capabilities in simulation, modelling, predictive data analytics, artificial intelligence (AI) and high performance computing (HPC). At the heart of DestinE will be a user-friendly and secure cloud-based digital modelling and simulation platform. This platform will provide access to data, advanced computing infrastructure including HPC, software, AI applications and analytics. It will integrate digital twins — digital replicas of various aspects of the Earth's system — on topics such as extreme weather events, climate change adaptation, oceans, biodiversity and more. DestinE will allow users to access to thematic information, services, models, scenarios, simulations, forecasts and visualizations. The underlying models and data will be continuously assessed to provide the most reliable scenario predictions for the users. The platform will also enable application development and the integration of users’ own data. DestinE will initially serve public authorities and will gradually open up to a larger range of scientific and industrial users, to spur innovation and enable the benchmarking of models and data. Domains Extreme natural events Climate change adaptation Ocean Cryosphere Biodiversity Land use Weather Marine systems Partners ESA (European Space Agency) ECMWF (European Centre for Medium-Range Weather Forecasts) EUMETSAT (European Organisation for the Exploitation of Meteorological Satellites) European Commission services and agencies Link to website https://digital-strategy.ec.europa.eu/en/policies/destination-earth  
Devices +
  +
Dia1.jpg +
Dia1  +
Dia2.jpg +
Dia2  +
Dia3.jpg +
Dia3  +
Overgenomen van "https://vloca-kennishub.vlaanderen.be/Eigenschap:Parsed_text"