"Parsed text" is een vooraf gedefinieerde eigenschap. Deze eigenschap is van te voren gedefinieerd (ook bekend als een speciale eigenschap) en komt met extra beheersprivileges, maar kan worden gebruikt net als elk andere door de gebruiker gedefinieerde eigenschap.
D
Sjabloon:Managed
{{Deliverable sidebar }}
$base array is defined in MediaWiki:Ws-sub-header
$page array is defined in MediaWiki:Ws-sub-header +
Class
Deliverable with pagetitle format next_available Allowed namespaces:
Deliverable Has version history: false
Layout
Areas : 'sub-header sidebar' 'main sidebar'
Columns : 3fr 1fr
Rows : auto 1fr
Storage templates
Base properties: Template:Base properties
Page properties: Template:Deliverable properties
Component templates
Sidebar template: Template:Deliverable sidebar
Defined parameters
Name
Property
Slot
Formfield type
Allowed values
Required
Multiple
Automatically generated template code
Info
Page properties template
Sidebar template
Open one of the tabs to view automatically generated template code. This is meant to be used when creating new templates.
If you are modifying an existing template, it might still be useful to update the parameter definitions and use parts of the generated code, but be careful not to completely overwrite existing templates. Existing templates will likely have had other modifications that are not included in the automatically generated code.
Template:Deliverable properties
<noinclude>
This is the '''Csp class properties''' template. It should be called in the following format:
<pre>
{{Csp class properties
}}
</pre>
</noinclude><includeonly>{{#set:
}}</includeonly>
Template:Deliverable sidebar <noinclude>
This is the '''Vloca default sidebar''' template. It should be called in the following format:
<pre>
{{Vloca default sidebar}}
</pre>
</noinclude><includeonly><!--
-->{{#vardefine:@allow sidebar edit |{{#ifingroup:user |{{#if:{{#urlget:veaction}}{{#urlget:action}}||yes}} }} }}<!--
--><div class="tab-content"><!--
-->{{#tag:_input||type=radio|id=sidebar-view|name=toggle-sidebar|checked=checked|class=d-none sidebar-view}}<!--
--><div class="card sidebar-view-tab">
<div class="card-header">{{#ifeq:{{#var:@allow sidebar edit}} |yes |<span style="float:right">{{#tag:label|Edit|for=sidebar-edit|class=btn btn-secondary}}</span>}}
<b class="d-block">{{#caprint:$base[Base properties][Class]}}</b>
{{#caprint:$base[Base properties][Title]}}
</div><!-- end of .card-header -->
<div class="card-body">
</div><!-- end of .card-body -->
</div><!-- end of .card
-->{{#ifeq:{{#var:@allow sidebar edit}} |yes |<!--
-->{{#tag:_input||type=radio|id=sidebar-edit|name=toggle-sidebar|class=d-none sidebar-edit}}<!--
--><div class="card sidebar-edit-tab"><!--
--><form action="addToWiki"><!--
// _edits for base properties
--><!--
// _create or _edits for page properties
// use casize to check if the slot already exists. Then _edit, else _create.
-->{{#if:{{#casize:$class}}
|
|<_create mwwrite="{{FULLPAGENAME}}" mwtemplate="Csp class properties" mwslot="ws-class-props" mwfields="" />
}}<!-- end of #if -->
<div class="card-header"><span style="float:right">{{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}}</span>
<b class="d-block">{{#caprint:$base[Base properties][Class]}}</b>
{{#caprint:$base[Base properties][Title]}}
</div><!-- end of .card-header -->
<div class="card-body">
<div class="text-right">
{{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}}
<input type="submit" value="Save" class="btn btn-primary" />
</div>
</div><!-- end of .card-body -->
</form>
</div><!-- end of .card -->
|}}<!-- end of #ifeq @allow sidebar edit == yes -->
</div><!-- end of .tab-content
--></includeonly>
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.1 Lokale Open Data Economie (LODE) – Brugge VLOCA-Model V0.1 VLOCA-model V0.2 Lokale Open Data Economie (LODE) – Brugge VLOCA-Model V0.2
Inhoud
Hieronder kan je de elementen van versie V0.1 van dit VLOCA model bekijken.
CoT Lode: Brugge - Gent
Jaar: 2022
01/09/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 ?
De lokale besturen en centrumsteden weten niet altijd wat te doen met hun open databronnen, hoe ze deze moeten 'vermarkten', welke databronnen de grootste meerwaarde zouden betekenen, enz. We gaan ervan uit dat er veel vraag en aanbod is van open data maar dat de lokale overheid inzichten en gedeelde platformen nodig hebben om dit te 'reguleren'.
Missie
Voorstel
Wat willen we bereiken ?
Inzichten van hoe de vraag en aanbod van open data af te stemmen op elkaar alsook een pilootcase van een open data marktplaats die MIM3 van OASC conform zal zijn en de meest relevante databronnen ter beschikking stelt.
Doel
Voorstel
Wat is het doel van dit project ?
1.Via marktstudi e overzicht van de vragende partijen voor open data binnen de quadruple helix, alsook de bestaande en potentiele bronnen van open data van de quadruple helix in kaart te brengen. 2.Een business pla n die de 'rendabiliteit' illustreert van het ter beschikking stellen van de open data. 3.Een piloo t data marktplaat s die de vraag en aanbod huist met alle vereiste functionaliteiten.
Succesfactor
Voorstel
Hoe meten we succes ? (SMART)
Segmentatie van vragende partijen die typologien van open data al dan niet voor een prijs willen aanschaffen. Een data marktplaats piloot volgens de normen van MIM3 van OASC.
Use cases
ID
Status
Samenvatting
Beschrijving
UC1
Voorstel
UC1: De Vraag naar open data
Overzicht via een 'segmentatie' van entiteiten (instituten, bedrijven, organisaties, individuen,...) die de vraag in kaart brengt. De vraag moet gevaloriseerd worden in 'intensiteit' en dus ook in 'bereidheid te betalen'.
UC2
Voorstel
UC2: Het aanbod van open data
Overzicht via een typologie van data elementen die reeds of mogelijks in de toekomst kan aangeboden worden door de 'overheid' of andere partijen binnen de quadruple helix.
UC3
Voorstel
UC3: Vraag en Aanbod Matching
Overzicht van de 'affiniteit' tussen de 'behoefte' segmentatie met de 'typologien' van open data (bronnen). =Matrix Segmenten tov open data typologien.
UC4
Voorstel
UC4: Business Case
Overzicht van de kosten en baten van het vrijgeven van open data door de data 'producent' die moet leiden naar een verzameling van business cases per data typologie.
UC5
Voorstel
UC5: Draaiboeken
Bibliotheek van draaiboeken per typologie van data (= productgedreven) en per behoefte segment (= klantgedreven).
UC6
Voorstel
UC6: Marktplaats
Een piloot open data marktplaats bouwen en beheren waar de vraag en aanbod elkaar tegenkomen. Die marktplaats moet interoperabel en conform de MIM3 van OASC standaarden zijn.
UC7
Voorstel
UC7: Futureproof
Een overlegplatform en proces die zorgt dat de marktplaats futureproof is door regelmatig overleg te organiseren tussen de verschillende betrokken (nieuwe) partijen om de vraag en aanbod telkens op elkaar af te stemmen.
UC8
Voorstel
UC8: juridisch
wettelijk kader
Metadata
Metaveld
Beschrijving
Meta1
Beschrijving meta 1
Meta2
Beschrijving meta 2
Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases
ID
Type
Samenvatting
Beschrijving
UC1
Use case
UC1: De Vraag naar open data
Overzicht via een 'segmentatie' van entiteiten (instituten, bedrijven, organisaties, individuen,...) die de vraag in kaart brengt. De vraag moet gevaloriseerd worden in 'intensiteit' en dus ook in 'bereidheid te betalen'.
BC1.1
Business capability
Samenvatting
Hoe groot is de vraag naar open data in aantal 'Entiteiten', intensiteit van de behoefte, bereidheid te betalen, welke type van data, frequentie, minimum kwaliteit, ed meer.
BC1.2
Business capability
Welke behoefte gebaseerde segmenten (Needs Based Segmentation) bestaan er in de quadruple helix die homogeen dezelfde behoeften hebben binnen de segmenten en heterogeen anders zijn tussen de segmenten.
ID
Type
Samenvatting
Beschrijving
UC2
Use case
UC2: Het aanbod van open data
Overzicht via een typologie van data elementen die reeds of mogelijks in de toekomst kan aangeboden worden door de 'overheid' of andere partijen binnen de quadruple helix.
BC2.1
Business capability
Welke zijn de verschillende databronnen die reeds bestaan en wat is hun 'specificiteit' die een behoefte kan beantwoorden
BC2.2
Business capability
Welke zijn de verschillende potentiele databronnen die nog 'ontgonnen' kunnen worden met hun specificiteit
BC2.3
Business capability
Welke zijn de 'typologien' die de verschillende databronnen groeperen/clusteren die homogeen binnen en heterogeen tussen de groepen zijn.
ID
Type
Samenvatting
Beschrijving
UC3
Use case
UC3: Vraag en Aanbod Matching
Overzicht van de 'affiniteit' tussen de 'behoefte' segmentatie met de 'typologien' van open data (bronnen). =Matrix Segmenten tov open data typologien.
BC3.1
Business capability
Lijst van alle data (typologien) die een behoefte van een segment beantwoord.
BC3.2
Business capability
Matrix die de affiniteit van de segmenten naar de data typologien visualiseert om daarmee een 'marketing', 'strategische' en 'operationeel' plan te kunnen uittekenen.
ID
Type
Samenvatting
Beschrijving
UC4
Use case
UC4: Business Case
Overzicht van de kosten en baten van het vrijgeven van open data door de data 'producent' die moet leiden naar een verzameling van business cases per data typologie.
BC4.1
Business capability
Een business plan kunnen opstellen om een 'product' op de markt te plaatsen. Dit 'product' bestaat uit een databron die beantwoord aan een behoefte van een 'segment'.
ID
Type
Samenvatting
Beschrijving
UC5
Use case
UC5: Draaiboeken
Bibliotheek van draaiboeken per typologie van data (= productgedreven) en per behoefte segment (= klantgedreven).
BC5.1
Business capability
Per databron een 'draaiboek' terugvinden die uitlegt hoe die data te capteren, verwerken, opslaan en ontsluiten voor een bepaalde segment behoefte
BC5.2
Business capability
Per Segment behoefte, een 'draaiboek' terugvinden die uitlegt welke databronnen er moet 'ontgonnen' worden om zo de behoefte te kunnen invullen.
BC5.3
Business capability
Draaiboek van hoe een lokale 'marktplaats' te bouwen, maar die geconnecteerd is met de andere marktplaatsen via een dataspace principe.
ID
Type
Samenvatting
Beschrijving
UC6
Use case
UC6: Marktplaats
Een piloot open data marktplaats bouwen en beheren waar de vraag en aanbod elkaar tegenkomen. Die marktplaats moet interoperabel en conform de MIM3 van OASC standaarden zijn.
BC6.1
Business capability
Het gemakkelijk/transparant kunnen ontsluiten van data (of andere assets zoals componenten, schema's, vocabularium, ed) in de marktplaats
BC6.2
Business capability
Publiceren van metadata in lijn met internationale standaarden zoals DCAT
BC6.3
Business capability
Transparant publiceren van de 'afkomst'/'Lineage'/'Callibraties'/Intrapollaties en Extrapollaties/enz.
BC6.4
Business capability
Publicatie van of verwijzen naar schema en semantiek
BC6.5
Business capability
Publiceren van de transport schema waarmee de data beschikbaar is (http, mqtt, ftp,...)
BC6.6
Business capability
Het kunnen factureren van de data downloads a priori of a posteriori
BC6.7
Business capability
Wat is de 'inhoudelijke' metadata van de verschillende beschikbare databronnen (via DCAT ?)
BC6.8
Business capability
Het kunnen toegang verlenen via toegansbeheer platform afhankelijk van de gebruikersrechten
BC6.9
Business capability
Reviews en feedback kunnen geven op die data (vanuit de gebruiker)
BC6.10
Business capability
Notificaties wanneer data geupdate werden
BC6.11
Business capability
Het registreren van transacties (= clearinghouse + voor inzichten op statistieken)
BC6.12
Business capability
Access controle
BC6.13
Business capability
Moet gebruik kunnen maken van derde identiteits providers (it's me,...)
BC6.14
Business capability
CRM communicatie and marketing en verkoopsplanning
BC6.15
Business capability
Betalingsmogelijkheden
BC6.16
Business capability
Prijs structuur opstellen en publiceren
BC6.17
Business capability
Publiceren van gebruiksrechten van data (alsook een open data charter waar de aanbieders en gebruikers zich moeten houden)
BC6.18
Business capability
Een 'google' manier (search engine) om data terug te vinden.
BC6.19
Business capability
Een visuele manier om data te categoriseren of behoeften te segmenteren.
BC6.20
Business capability
Moet passen in een gefedereerde netwerk van catalogi (ref. dataspaces)
ID
Type
Samenvatting
Beschrijving
UC7
Use case
UC7: Futureproof
Een overlegplatform en proces die zorgt dat de marktplaats futureproof is door regelmatig overleg te organiseren tussen de verschillende betrokken (nieuwe) partijen om de vraag en aanbod telkens op elkaar af te stemmen.
BC7.1
Business capability
Wie zijn de relevante betrokken partijen uit de quadruple helix
BC7.2
Business capability
Opstellen van een werkmethode
BC7.3
Business capability
Organiseren van live of digitale communicatie tussen de partijen (overlegmomenten, newsletters, conferenties, webinars, enz.)
ID
Type
Samenvatting
Beschrijving
UC8
Use case
UC8: juridisch
wettelijk kader
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.1 Slimme stadsdistributie – Hasselt VLOCA-Model V0.1 VLOCA-model V0.2 Slimme stadsdistributie – Hasselt VLOCA-Model V0.2
Inhoud
Hieronder kan je de elementen van versie V0.1 van dit VLOCA model bekijken.
CoT Slimme stadsdistributie – 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 ?
Stadsdistributie in de vorm van vrachtverkeer in de stadskern wordt alsmaar belangrijker en genereert een paradox mbt het autoluw maken van de binnenstad. Dit resulteert in alsmaar meer problemen zonder enige vorm van sturing.
Missie
Voorstel
Wat willen we bereiken ?
Het verkeer in de binnenstad aangenamer maken door het vrachtverkeer te minimaliseren door betere planning ifv verkeer (huidig of ingeschatte) alsook het verminderen van 'onnodige' transporten (beschikbare lege volume, lege terugkeer, ed meer)
Doel
Voorstel
Wat is het doel van dit project ?
(1) Een 'cockpit' bouwen die het vrachtverkeer volledig weergeeft om inzichten te verschaffen mbt beleidsvorming, sturing en evaluatie (2) Een 'dashboard' voor de 'vervoerder' om zijn transport te registreren en 'toestemming' te krijgen met een voorgestelde routeplanning (3) Het dashboard moet ook de mogelijkheid geven om aan de vervoerder een optimale planning te kunnen doen door op basis van de andere registraties, wegenwerken, ed meer. (4) Ontsluiten van alle mogelijke data (via APIs bvb) naar commerciele 'logistieke planningstools' om die data te integreren, of nieuwe VAS toe te laten.
Succesfactor
Voorstel
Hoe meten we succes ? (SMART)
Tegen 2024 moet Hasselt een cockpit hebben die de toegang van vrachtverkeer reguleert en visualiseert waarbij alle data de OSLO standaarden respecteert.
Use cases
ID
Status
Samenvatting
Beschrijving
UC1
Voorstel
UC1: Registratie Levering
Een visuele applicatie (='Dashboard') waar de vervoerder een reservatie/registratie, om de binnenstad binnen te rijden, kan aanvragen en ifv het flankerend beleid al dan niet toestemming krijgt om de gevraagde route te kunnen gebruiken. Alternatieve 'routes' (welke wagen, tijdstip, geografische route, enz) worden ook voorgesteld.
UC2
Voorstel
UC2: Beleids Cockpit
De steden krijgen een 'cockpit' die het volledige vrachtverkeer (registraties, sensoren, camera's data, ANPR, Toegangscontrole,...) grafisch en in cijfers weergeeft om zo een beter beleid te kunnen vormen, sturen en evalueren.
UC3
Voorstel
UC3: Beleids Cockpit uitvoering
Het flankerend beleid moet kunnen ingevoerd worden in de 'cockpit' zodat elke aanvraag (= registratie) ifv de gevraagde routes, maar ook de type wagen, ed meer de toegestane routes kan beslist en gevisualiseerd worden via een algoritme die een 'nudging' mogelijk maakt om bvb indien mogelijk een alternatieve moment te gebruiken bij 'piek momenten'
UC4
Voorstel
UC4: Toegang Binnenstad
De Binnenstad kan toegankelijk gemaakt worden enkel voor de degenen die zich geregistreerd en ook aan de 'beleids' criteria voldoen, via paaltjes of via ANPR camera's.
UC5
Voorstel
UC5: Inname openbaar domein
Via de dashboard kan ook openbaar domein gereserveerd worden met 'vergunning' met betaling (per dag, per week,...)
UC6
Voorstel
UC6: Laad- en Losplaatsen reserveren
De vervoerder/handelaar/leverancier moet een laad- en losplaats kunnen 'reserveren' om zeker te zijn dat de levering zo optimaal zou kunnen verlopen. (Betaling ? : misschien ifv EURO normen van de (vracht)wagen)
UC7
Voorstel
UC7: Matchmaking
Door alle verzamelde data, alsook de 'registratie' aanvragen, kan de 'waste' in de transport worden weggewerkt door de 'lege'/'beschikbare' volumes te benutten door andere vervoerders, handelaars en leveranciers.
UC8
Voorstel
UC8: Open Data
Alle data die uiteindelijk gecapteerd worden moet kunnen opengesteld worden om zo de ganse quadruple helix de mogelijkheid te bieden om 'Value Added Services' te kunnen bouwen op die data.
UC9
Voorstel
UC10
Voorstel
Metadata
Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases
ID
Type
Samenvatting
Beschrijving
UC1
Use case
UC1: Registratie Levering
Een visuele applicatie (='Dashboard') waar de vervoerder een reservatie/registratie, om de binnenstad binnen te rijden, kan aanvragen en ifv het flankerend beleid al dan niet toestemming krijgt om de gevraagde route te kunnen gebruiken. Alternatieve 'routes' (welke wagen, tijdstip, geografische route, enz) worden ook voorgesteld.
BC1.1
Business capability
Inlog en authenticatie systeem om 'kentekens' of 'badges' te kunnen 'aanmaken' voor de eerste keer met bijbehorende vragen (type van wagen, ed meer)
BC1.2
Business capability
'Registreren'/Invoeren van gewenste leverings of afhalingstermijn aan een adres.
BC1.3
Business capability
Voorstel van (alternatieve) routes, wanneer en via welke route, die toegelaten zouden zijn en kan gevalideerd worden door de vervoerder met een muisklik in de tool.
BC1.4
Business capability
dossier beheer
Aanvragen moet kunnen aangepast of zelfs geannuleerd door de vervoerder, met een visuele/grafische algemene overzicht van alle aanvragen per kenteken/badge
BC1.5
Business capability
rapportering
Opvolging van 'uitvoering/gebruik' van de aanvragen (om misbruiken tegen te gaan door bepaalde 'badge'/'kentekens' te blokkeren) alsook handhaving van ongeoorloofde leveringen (om te beboeten)
ID
Type
Samenvatting
Beschrijving
UC2
Use case
UC2: Beleids Cockpit
De steden krijgen een 'cockpit' die het volledige vrachtverkeer (registraties, sensoren, camera's data, ANPR, Toegangscontrole,...) grafisch en in cijfers weergeeft om zo een beter beleid te kunnen vormen, sturen en evalueren.
BC2.1
Business capability
rapportering
Alle 'registraties', 'aanvragen' en 'uitvoering' te visualiseren samen met andere 'stadsdrukte' metingen van gemotorizeerde vervoer.
BC2.2
Business capability
Lineaire programmatie
Simulatie om de beleidsbeslissings parameters te callibreren (hoe streng moeten we zijn) om het verkeer zo minimaal te maken alsook de aanvragen zo maximaal te beantwoorden
BC2.3
Business capability
Actuatie
Via IoT actuatoren (?) kunnen vervoerders al dan niet in de binnenstad of in een straat binnengelaten worden doordat bvb de paaltjes al dan niet in de grond zinken, of de hefbomen open gaan, of de ANPR camera de niet toegestande vervoerder capteert en beboet.
ID
Type
Samenvatting
Beschrijving
UC3
Use case
UC3: Beleids Cockpit uitvoering
Het flankerend beleid moet kunnen ingevoerd worden in de 'cockpit' zodat elke aanvraag (= registratie) ifv de gevraagde routes, maar ook de type wagen, ed meer de toegestane routes kan beslist en gevisualiseerd worden via een algoritme die een 'nudging' mogelijk maakt om bvb indien mogelijk een alternatieve moment te gebruiken bij 'piek momenten'
BC3.1
Business capability
Beslissingsboom
Een gekozen (zie BC2.2) beslissingsboom die bepaald wie waar al dan niet mag binnenrijden, moet kunnen ingevoerd worden, zodat er 'automatisch' de actuatoren aangestuurd worden, alsook de handhaving via GAS of andere boetes quasi automatisch kan uitgevoerd worden.
BC3.2
Business capability
Rapportering
De beslissingsboom moet kunnen ge 'versioneerd' worden, zodat er een historiek kan zijn van de gebruikte parameters die evt geleid hebben tot een zekere verkeersdrukte in de binnenstad in het verleden.
BC3.3
Business capability
Visualisatie
De beslissingsboom moet ook visueel kunnen voorgesteld worden zodat de aanvrager het voorstel van de tool beter kan begrijpen en in de toekomst zijn logistieke aanvraag beter kan afstemmen om de kansen tot aanvaarding te verhogen.
ID
Type
Samenvatting
Beschrijving
UC4
Use case
UC4: Toegang Binnenstad
De Binnenstad kan toegankelijk gemaakt worden enkel voor de degenen die zich geregistreerd en ook aan de 'beleids' criteria voldoen, via paaltjes of via ANPR camera's.
BC4.1
Business capability
Actuator systeem
Fysieke toegangen gelinkt aan de databank waarin de toestemmingen opgeslagen zijn in real time.
ID
Type
Samenvatting
Beschrijving
UC5
Use case
UC5: Inname openbaar domein
Via de dashboard kan ook openbaar domein gereserveerd worden met 'vergunning' met betaling (per dag, per week,...)
BC5.1
Business capability
Booking.com toepassing
Een visueel overzicht van de beschikbare tijdslot per operbaar domein (laad- en losplaats?), en reservatie mogelijkheid met een muisklik.
ID
Type
Samenvatting
Beschrijving
UC6
Use case
UC6: Laad- en Losplaatsen reserveren
De vervoerder/handelaar/leverancier moet een laad- en losplaats kunnen 'reserveren' om zeker te zijn dat de levering zo optimaal zou kunnen verlopen. (Betaling ? : misschien ifv EURO normen van de (vracht)wagen)
BC6.1
Business capability
Booking.com toepassing
Een visueel overzicht van de beschikbare tijdslot per operbaar domein (laad- en losplaats?), en reservatie mogelijkheid met een muisklik.
BC6.2
Business capability
Beheer van dossier
Beheer van het dossier van reservaties : overzicht aanvragen met status, aanpassen en annuleren van aangevraagde reservering, enz. Eventueel ook een 'betalings' module indien die reservaties niet gratis zal zijn.
BC6.3
Business capability
Rapportering
Overzicht van alle aanvragen van reservaties (en uitvoering van die reservaties)
ID
Type
Samenvatting
Beschrijving
UC7
Use case
UC7: Matchmaking
Door alle verzamelde data, alsook de 'registratie' aanvragen, kan de 'waste' in de transport worden weggewerkt door de 'lege'/'beschikbare' volumes te benutten door andere vervoerders, handelaars en leveranciers.
BC7.1
Business capability
Vergunningen
Door de vervoerders/handelaars/leveranciers in kaart te brengen alsook de gedeclareerde 'lege' volume in de vrachtwagen kan een matchmaking voorgesteld worden waarbij er maximaal volume met een minimum aan verplaatsing zou kunnen uitgevoerd worden.
BC7.2
Business capability
Vraag
Aanvraag mogelijkheid van een vervoerder/handelaar/leverancier om van adres A tot adres B tijdens periode X een vracht met volume Y en dimensie Z te kunnen mee vervoeren.
BC7.3
Business capability
Aanbod
Aanbod mogelijkheid van een vervoerder om een 'lege' volume voor te stellen om door een handelaar/andere vervoerder/leverancier te kunnen benutten.
ID
Type
Samenvatting
Beschrijving
UC8
Use case
UC8: Open Data
Alle data die uiteindelijk gecapteerd worden moet kunnen opengesteld worden om zo de ganse quadruple helix de mogelijkheid te bieden om 'Value Added Services' te kunnen bouwen op die data.
BC8.1
Business capability
OSLO-VLOCA
Alle data die opengesteld zullen worden moeten de OSLO standaarden alsook de VLOCA charter voldoen, zodat er andere spelers op de markt die data kunnen gebruiken om toegevoegde waarde applicaties te kunnen bouwen.
BC8.2
Business capability
Open Data Platform
Open data moet via centrale datavindplaats kunnen gevonden worden en toegang gegeven worden.
Inleiding
Deze pagina bevat de eerste versie van het VLOCA model. Het is een niet finale versie die we V0.2 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.2-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is.
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.2 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.2 van dit VLOCA model bekijken.
Open Repair Data Platform ("ORDP") - van business capability naar technische vereisten
najaar 2021
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
Prioritering voor project van initiatiefnemer
Strategie volgens use case
Status
Toelichting
Beschrijving
Visie
Voorstel
Wat is de bestaansreden ?
De circulaire economie is een economisch systeem waarbij de waarde van producten, materialen en andere hulpbronnen in de economie zo lang mogelijk wordt behouden, waarbij deze efficiënter worden gebruikt bij productie en consumptie, en waardoor het milieueffect van het gebruik ervan wordt verminderd, en afval en het vrijkomen van gevaarlijke stoffen in alle stadia van de levenscyclus zo veel mogelijk worden beperkt. (bron: Vlaanderen circulair) Op deze manier draagt ze bij aan de transitie naar een (ecologisch) duurzame economie (die binnen de "planetary boundaries" opereert). In een circulaire economie worden tal van strategieën toegepast om materialen en producten van bij de start zo te ontwerpen dat ze blijvend hoogwaardig in de economie kunnen worden ingezet. (bron: OVAM) Een van deze strateegieën is herstel. Hoewel herstel een optie kan zijn voor verschillende productgroepen zoals kledij, meubels, auto's,... richten we ons in dit initiatief enkel tot elektrische en elektronische apparaten. Uit verschillende studies en bevragingen (e.g. Special Eurobarometer 501 2019) weten we dat burgers die geconfrontreerd werden met een gefaald toestel, niet vaak voor herstel kiezen (~32%). De hoge zoekkosten (wie kan mij helpen?) en de onzekerheid of het toestel de investering nog waard is zijn de grootste drempels. Des te duurder de herstel is (arbeid- en transportkost nemen het grootste aandeel, maar wisselstukken kunnen soms ook zeer duur zijn tov de aankoop van een nieuw toestel) en des te onduidelijker het is hoelang het toestel nog zal meegaan na herstel, des te hoger deze onzekerheid.
Missie
Voorstel
Wat willen we bereiken ?
Met dit initiatief willen we herstel aantrekkelijker maken door een (kosten-) efficientere werking met hoge succesgraad te faciliteren. Dit willen we doen door herstel data te verzamelen en te poolen om zo met behulp van AI in staat te zijn er inzichten uit te trekken:
(1) voor (vrijwillige/professionele) herstellers, retailers en burgers zodat de identificatie van het toestel en de faling en het vinden van de beste hersteloptie vlotter en beter gaat;
(2) voor invoerders/producenten om "design for repair" en voorraadbeheer van onderdelen te faciliteren;
(3) voor beleidsmakers (op alle niveaus) bij het formuleren van doelstellingen of nieuwe beleidsmaatregelen (op gebied van circulaire economie, klimaat, digitalisering) en het opvolgen van de voortgang.
Doel
Voorstel
Wat is het doel van dit project ?
EEA producten zo lang mogelijk en tegen zo hoog mogelijke waarde in de economie houden.
Succesfactor
Voorstel
Hoe meten we succes ? (SMART)
Tegen 2025 gebruiken de 5 voornaamste bedrijven binnen de EEA waardeketen en de burgers en stadsbesturen van 5 Vlaamse steden, de ORDP infrastrcutuur, die 3 verschillende views heeft (hersteller, burger, lokaal bestuur) en hen 3 inzichten aanbiedt die voor een tijdbesparing zorgen.
Objectieven van de use case
scope in bold of met cijfertjes
ID
Status
Samenvatting
Beschrijving
In scope?
Dringendheid 1-5
Belangrijkheid 1-5
Prioriteitscore fx
O1
Voorstel
input
Data moet makkelijk ingevoerd kunnen worden door de "data opladers". Dit zijn: invoerders/producenten, retailers, professionele en vrijwillige herstellers van EEA.
Ja
5
5
10
O2
Voorstel
output
Data moet gemakkelijk opgevraagd kunnen worden door de "klanten" (dit zijn de data opvragers en gebruikers van de inzichten van het ORDP). Deze komen uit alle hoeken van de quadruple helix en hebben zo ook verschillende profielen, noden en verwachtingen. We denken aan: grote tot kleine bedrijven (invoerders/producenten EEA, retailers, herstellers), overheden (verschillende niveaus van lokaal tot EU), onderzoek/innovatie, tot verenigingen en burgers.
Ja
4
5
9
O3
Voorstel
Applicatie
De basisuitrusting is een databank en API die op een server staat. Er worden bewerkingen uitgevoerd op (delen van) de data set. De achterliggende code is voldoende afgeschermd, modulair opgesteld en staat gedetailleerd gedocumenteerd. Een procedure rond versiebeheer is opgesteld en strikt toegepast.
Ja
4
4
8
O4
Voorstel
Controle Kwalitatieve Data
De data kwaliteit van zowel ingevoerde data als opgeleverde inzichten moet gegarandeerd kunnen worden door service level agreement met de eigenaars maar ook via sanity checks, data correcties, etc.
Ja
3
4
7
O5
Voorstel
systeem monitoring
Het volledige proces wordt continu gemeten bij elke stap (hoeveel opladers, aanvragers, hoeveel ingelogd, hoeveel data correcties, hoeveel klachten,…)
Ja
2
2
4
O6
Voorstel
CRM
Het ORDP moet haar bestaande en toekomstige 'stakeholders' (klanten, leveranciers, beleid, enz) kunnen contacteren met inzichten, belangrijke informatie, nieuwsbrieven en andere marketing tools.
Ja
2
3
5
O7
Voorstel
zelfbedruipend
Het ORDP moet op termijn zijn eigen kosten kunnen dekken via inkomsten. (Betalend, incentives, reclame derde partijen, lidmaatschap, subsidies,…)
Ja
2
5
7
Metadata van de objectieven
Metaveld
Beschrijving
EEA
elektrische en electronische apparaten
ORDP
een databank met (gelinkte) hersteldata uit verschillende bronnen (Open repair data allaince, repair connects, my minifactory, IFIXIT)
POM
Afkorting voor "put on market" - hoeveelheden product op de marckt gebracht (gepubliceerd door Eurostat)
materiaalstock
Hoeveelheden product aanwezig in een bepaald gebied. (Het toestel is al dan niet in gebruik.)
herstel
het weer in goede staat terugbrengen
binnengebracht voor herstel
een gefaald product afleveren zodat het eventueel zou kunnen hersteld worden
recyclage
(een set van) materialen vervat in een product terugwinnen
binnengebracht voor recyclage
een materiaal of product afleveren zodat er materialen uit kunnen teruggewonnen worden
hergebruik
het weer gebruiken van een artikel zonder dat daarvoor de nodige handelingen moeten worden verricht; het product veranderd dus van eigenaar
binnengebracht voor hergebruik
het materiaal/product aanbieden aan organsitei dat hergebruikte goederen weer op de markt brengt
vrijwillige herstel
aanbieden van herstelactiviteiten (kennis, apparatuur) op vrijwillige basis dus onbezoldigd (bv. Repair café of aan kennis, buur,...)
self repair
Eigenhandig herstellen van goederen in bezit met of zonder externe hulp
professionele herstel
Activiteiten onder (B2B) NACE 33.1 en (B2C) NACE 95.1 & 95.2 .
succesvolle reparatie
een herstel dat met succes heeft plaatsgevonden
3D print designs
een 3D representatie van een product
peer-to-peer
delen van bestanden
user interface
digitaal platform waar data verzameld worden en inzichten op aangeboden worden
dashboard
een soort grafische gebruikersinterface die vaak in één oogopslag een overzicht geeft van de belangrijkste prestatie-indicatoren die relevant zijn voor een bepaald doel of bedrijfsproces
data infrastructuur
de verzameling voorzieningen die nodig is voor het transport van digitale signalen die gegevens bevatten
data architectuur
een overzicht van de aanwezige en benodigde gegevens in een ecosysteem
data leverancier
een organisatie die data capteert en aanbiedt
gebruiker
vraag naar inzichten, indicatoren,…
AI
artificiele intelligentie, in deze context meestal gezien als deep learning waarbij men leert uit historisch herstelactiviteiten en dit gebruikt voor het formuleren van de beste hersteloptie
onderhoudsvriendelijk
weinig effort nodig om het systeem te onderhouden
kostenefficiënt
het ontwerp van het ORDP houdt rekening met de mogelijkheid nieuwe uitbreidingen te doen met zo weinig mogelijk tijdsinspanning en extra kosten
analysetool
een hulpmiddel voor het uitvoeren van een analyse
monitoring framework
een set van indicatoren die helpen om te bepalen of een beleid de gewenste resultaten heeft
CE
Circulaire economie
OEM
Original equipment manufacturer ofwel invoerder en producten van EEA (in Europa)
SLA
service level agreement, een type overeenkomst waarin afspraken staan tussen aanbieder en afnemer van een dienst of product.
Data oplader
Organisaties en initiatieven zoals invoerders/producenten, retailers, professionele en vrijwillige herstellers van EEA, die herstellingen digitaal rapporteren en deze data aanleveren aan het ORDP.
Klant
data bevragers en gebruikers van de inzichten uit ORDP
Per objectief: business capabilities (BC) >> data vereiste (DV) >> functionele capabilities (FC) >> technische vereiste (TV)
ID
Type
Samenvatting
Beschrijving
In scope?
Dringendheid 1-5
Belangrijkheid 1-5
Prioriteitscore fx
O1
Objectief
input
Data moet makkelijk ingevoerd kunnen worden door de "data opladers". Dit zijn: invoerders/producenten, retailers, professionele en vrijwillige herstellers van EEA.
Ja
5
5
10
BC1.1
Business capability
Profielen
Als data oplader moet ik mij kunnen authenticeren om schrijfrechten te krijgen.
Ja
0
BC1.2
Business capability
Data ophalen
Als beheerder wil ik dat het ORDP zelf (semi- of volautomatisch) data die online gepubliceerd worden op regelmatige tijdstippen of bij bepaalde triggers of events kan opladen in de ORDP Database.
Ja
0
BC1.3
Business capability
Data instroom tools
Als beheerder wil ik dat alle applicaties die het ORDP platform lezen ook hun ingevoerde data automatisch in de ORDP database opgeladen worden. Ook als de 'gebruiker' bvb slechts een handleiding heeft gedownload, willen wij dat weten om daarmee "profielen" af te bakenen of verder te verfijnen.
Ja
0
BC1.4
Business capability
Data dumpen
Als beheerder wil ik een datafile als 'dump' file, in bvb JSON or CSV, kunnen opladen in de ORDP database.
Ja
0
BC1.5
Business capability
Validatie
Als beheerder of als 'oplader' moet ik genoeg data krijgen rond de kwaliteit van het opladen alsook de data zelf. Dit kan visueel, met snelle tabellen met cijfers (aantal rijen, aantal kolommen, enz.) of zelfs via AI die een 'eerste' indruk geven van mogelijke 'issues' in de data.
Ja
0
BC1.6
Business capability
Rapportering
Als beheerder wil ik aan de 'oplader' een rapportje sturen mbt alle opgeladen data (stromen), alsook aan de stakeholders statistieken kunnen geven ivm aantal en volume van data opladingen.
Ja
0
BC1.7
Business capability
Feedback
Als data oplader wil ik feedback kunnen geven ivm de data die ik heb opgeladen (kwaliteit, metadata, 'let ops', 'FAQ', …)
Ja
0
BC1.8
Business capability
Review
Als data oplader wil ik ook mijn mening kunnen geven ivm ORDP samenwerking en als beheerder wil ik dat kunnen rapporteren.
Ja
0
BC1.9
Business capability
Data afschermen
Als beheerder wil ik de data van bepaalde opladers beschermen (op vraag van de data eigenaars en opladers) en beperkte leesrechten geven aan bepaalde klantenprofielen.
Ja
0
BC1.10
Business capability
foutmelding
Als data oplader wil ik een foutmelding krijgen die mij uitlegt waar het probleem zich situeert.
Ja
0
ID
Type
Samenvatting
Beschrijving
In scope?
Dringendheid 1-5
Belangrijkheid 1-5
Prioriteitscore fx
O2
Objectief
output
Data moet gemakkelijk opgevraagd kunnen worden door de "klanten" (dit zijn de data opvragers en gebruikers van de inzichten van het ORDP). Deze komen uit alle hoeken van de quadruple helix en hebben zo ook verschillende profielen, noden en verwachtingen. We denken aan: grote tot kleine bedrijven (invoerders/producenten EEA, retailers, herstellers), overheden (verschillende niveaus van lokaal tot EU), onderzoek/innovatie, tot verenigingen en burgers.
Ja
4
5
9
BC2.1
Business capability
Noden/profielen
Als beheerder wil ik de "klanten" segmenteren ifv hun behoeften (frequentie, type van bevragingen, type van gewenste inzichten, enz.)
Ja
0
BC2.2
Business capability
Authenticatie
Als klant wil ik mij kunnen inloggen om mijn leesrechten te verkrijgen (ook evt schrijfrechten), soms ben ik zowel klant als dataoplader van ORDP.
Ja
0
BC2.3
Business capability
Dashboard
Als beheerder wil ik het dashboard (eerste pagina na inloggen, ook landingspagina bvb) op maat maken ifv het klanten profiel.
Ja
0
BC2.4
Business capability
Rapportering
Als klant wil ik een overzicht hebben over mijn gebruik binnen ORDP.
Ja
0
BC2.5
Business capability
Feedback
Als klant wil ik feedback en evaluatie kunnen geven van de data in ORDP of van de inzichten uit ORDP.
Ja
0
BC2.6
Business capability
Reviews
Als klant wil ik ook mijn mening kunnen geven ivm ORDP samenwerking en als beheerder wil ik dat kunnen meten.
Ja
0
BC2.7
Business capability
Ad hoc inzichten
Als klant wil ik ook inzichten (zoals bv. is Samsung beter dan Apple?, 'grote kans dat een gefaald onderdeel aan de basis ligt van uw probleem') die kunnen afgeleid worden uit statistieken iin onze databank, kunnen verkrijgen rond het problematiek waar ik momenteel mee bezig ben.
Ja
0
BC2.8
Business capability
Recurrent Analysis
Als klant wil ik meer 'complexe' rapporten kunnen draaien die mij inzichten verschaffen rond het problematiek waar ik momenteel mee bezig ben.
Ja
0
BC2.9
Business capability
Opgeslagen Rapporten
Als klant wil ik mijn eigen rapport kunnen 'schrijven' die ik ook kan opslaan bij een volgende inlog moment.
Ja
0
BC2.10
Business capability
Rapporten sharing
Als klant wil ik mijn rapport ook met andere kunnen delen, of wil ik een rapport van een andere klant kunnen inzien.
Ja
0
BC2.11
Business capability
foutmelding
Als klant wil ik een foutmelding krijgen bij een probleem die uitlegt wat het probleem is en hoe hiermee verder te kunnen.
Ja
0
ID
Type
Samenvatting
Beschrijving
In scope?
Dringendheid 1-5
Belangrijkheid 1-5
Prioriteitscore fx
O3
Objectief
Applicatie
De basisuitrusting is een databank en API die op een server staat. Er worden bewerkingen uitgevoerd op (delen van) de data set. De achterliggende code is voldoende afgeschermd, modulair opgesteld en staat gedetailleerd gedocumenteerd. Een procedure rond versiebeheer is opgesteld en strikt toegepast.
Ja
4
4
8
BC3.1
Business capability
Basisuitrusting
Als beheerder wil ik kunnen garanderen en managen dat de toegangen en data manipulatie scriptjes continue blijven werken. Dit moet ik ook kunnen rapporteren en communiceren (bvb. Systeem heeft al dan niet succesvol verlopen, zondag tussen 1h en 5h is ORDP niet bereikbaar wegens onderhoud, enz.)
Ja
0
BC3.2
Business capability
Versiebeheer
Als beheerder wil ik alle versies van scripts maar ook data kunnen bijhouden en eventueel bij incidenten kunnen 'restoren'.
Ja
0
BC3.3
Business capability
Stockeren
Als beheerder wil ik de data en scriptjes op een 'deftige'/'legale'/'wenselijke' locatie geplaatst worden waarbij er een minimum aan SLA kan gegarandeerd worden.
Ja
0
BC3.4
Business capability
Bewerkingen instroom
Als beheerder wil ik een sofware scriptje kunnen gebruiken om de opgeladen data te kunnen 'manipuleren' (debugging, outliers verwijderen, formatteren van tabellen in correcte formaten, aligneren en opladen, enz.)
Ja
0
BC3.5
Business capability
Inzichten
Als beheerder wil ik inzichten verkrijgen over het gebruik van de applicatie (aantal inloggers, type van bevragingen, gedraaide scriptjes, aantal foutmeldingen, aantal 'fraudeurs', enz.)
Ja
0
BC3.6
Business capability
BI Team
Als beheerder wil ik een service kunnen geven aan de klanten om de (toekomstige) noden te helpen identificeren. Dit bevordert de klantentevredenheid (des te meer inzichten gebruikt worden door de klanten ze te waardevoller de samenwerking wordt) nu maar ook in de toekomst (door onze systemenen steeds verder te otnwikkelen, willen we garanderen dat we ook in de toekomst relevant kunnen zijn). (Van data naar inzichten)
Ja
0
BC3.7
Business capability
Beheer van 3de partijen
Als beheerder wil ik alle applicaties die toegang krijgen tot ORDP kunnen overzichtelijk maken en vooral beheren (toegang geven, stopzetten, controleren, inzichten, …)
Ja
0
BC3.8
Business capability
AI beslissingsboom
Een machine learning methode om te weten welke informatie er telkens nodig is om een reparatie plan voor te stellen. Dit via een 'beslissingsboom' : welke merk ?=> welk aankoopjaar => enz.
Ja
0
BC3.9
Business capability
3de partijen
Als beheerder wil ik derde partijen (voor een vooraf vastgelegde periode) toegang geven tot het platform en dit op een degelijke manier managen. Eventueel betalend maken ifv type toegang, enz.
Ja
0
BC3.10
Business capability
foutmeldingen
Als beheerder wil ik geinformeerd worden bij elke 'mankement' door een specifieke foutmelding te krijgen
Ja
0
BC3.11
Business capability
Automatische AI ML
Als applicatie beheerder wil ik modellen 'on the fly' kunnen bouwen (en valideren) en zo voorkomen dat er teveel tijd gestoken worden in eenmalige acties. Zo willen we modellen bouwen en in productie zetten tot de kwaliteits scores te laag te worden. Indien zo, sturen we bij.
Ja
0
ID
Type
Samenvatting
Beschrijving
In scope?
Dringendheid 1-5
Belangrijkheid 1-5
Prioriteitscore fx
O4
Objectief
Controle Kwalitatieve Data
De data kwaliteit van zowel ingevoerde data als opgeleverde inzichten moet gegarandeerd kunnen worden door service level agreement met de eigenaars maar ook via sanity checks, data correcties, etc.
Ja
3
4
7
BC4.1
Business capability
SLA
Als beheerder wil ik met de eigenaars van de data en applicatie een SLA kunnen opstellen die een minimum kwaliteit garanderen (data volumes, kolommen, frequentie, correcties, recencies,…)
Ja
0
BC4.2
Business capability
Opvolging SLA
Als beheerder wil ik een plaform hebben waar we de SLA kunnen opvolgen, bespreken, heronderhandelen en zelfs eventueel opheffen (beboeten door de flow te stoppen)
Ja
0
BC4.3
Business capability
Sanity checks
Als beheerder wil ik sanity checks rapporten kunnen bouwen die mij inzichten geven over de kwaliteit van de data alsook over de kwaliteit van de applicaties en geleverde inzichten.
Ja
0
BC4.4
Business capability
Automatic Correction
Als beheerder wil ik een zelf corrigerende scriptjes (AI via Machine Learning) kunnen lanceren die de data zelf gaan opvullen, vervangen of verwijderen.
Ja
0
BC4.5
Business capability
Kwaliteitsscore
Als beheerder wil ik een score kunnen berekenen en rapporteren ivm de ingeschatte kwaliteit van de data of applicatie.
Ja
0
BC4.6
Business capability
Benchmarking
Als beheerder wil ik de kwaliteit van de data en applicaties kunnen vergelijken met wat er in andere steden en landen of organisaties gebeuren.
Ja
0
BC4.7
Business capability
AI kwaliteit
Als beheerder en klant wil ik de kwaliteit kennen van de voorgestelde reparatie stappen door te vergelijken met actuele resultaten. (the proof of the pudding is in the eating)
Ja
0
ID
Type
Samenvatting
Beschrijving
In scope?
Dringendheid 1-5
Belangrijkheid 1-5
Prioriteitscore fx
O5
Objectief
systeem monitoring
Het volledige proces wordt continu gemeten bij elke stap (hoeveel opladers, aanvragers, hoeveel ingelogd, hoeveel data correcties, hoeveel klachten,…)
Ja
2
2
4
BC5.1
Business capability
Current use
Als beheerder wil ik op elke moment weten wie momenteel is ingelogd, aan het opladen, queries aan het schrijven, aan het draaien, enz.
Ja
0
BC5.2
Business capability
Historiek
Als beheerder wil ik een overzicht kunnen krijgen ivm historiek van inlogging, opladen, queries, klachten, foutmeldingen, enz.
Ja
0
BC5.3
Business capability
Performantie
Als beheerder wil ik de performantie van alle proces stappen kunnen meten en rapporteren (bvb hoe lang duurt een oplading van duizend rijen,…)
Ja
0
BC5.4
Business capability
Financien
Als beheerder wil ik monitoring van 'prestaties' (mandagen), 'facturaties', 'kosten', 'cashflow', enz.
Ja
0
ID
Type
Samenvatting
Beschrijving
In scope?
Dringendheid 1-5
Belangrijkheid 1-5
Prioriteitscore fx
O6
Objectief
CRM
Het ORDP moet haar bestaande en toekomstige 'stakeholders' (klanten, leveranciers, beleid, enz) kunnen contacteren met inzichten, belangrijke informatie, nieuwsbrieven en andere marketing tools.
Ja
2
3
5
BC6.1
Business capability
Data
Als beheerder wil ik een databank met optin optout van de stakeholders met relevante contact informatie, profielen, enz.
Ja
0
BC6.2
Business capability
Trigger Based Comm.
Als beheerder wil ik een marketing automation systeem hebben dat mijn stakeholders contacteert met informatie die gerelateerd is aan hun profiel of activiteiten die zij in het (nabije) verleden hebben uitgevoerd.
Ja
0
BC6.3
Business capability
Acquisitie
Als beheerder wil ik prospectie kunnen doen om ons platform te promoten bij eventuele toekomstige gebruikers, opladers, stakeholders, beleidsmensen, enz.
Ja
0
BC6.4
Business capability
Loyalty
Als beheerder wil ik loyale gebruikers belonen
Ja
0
BC6.5
Business capability
Retentie
Als beheerder wil ik 'churners' (gebruikers die afgehaakt zijn) of churnrisk gebruikers kunnen contacteren om hen terug op onze platform te komen.
Ja
0
BC6.6
Business capability
KPI
Als beheerder wil ik weten welke KPI's we best nastreven, en hoe we scoren op elke KPI.
Ja
0
ID
Type
Samenvatting
Beschrijving
In scope?
Dringendheid 1-5
Belangrijkheid 1-5
Prioriteitscore fx
O7
Objectief
zelfbedruipend
Het ORDP moet op termijn zijn eigen kosten kunnen dekken via inkomsten. (Betalend, incentives, reclame derde partijen, lidmaatschap, subsidies,…)
Ja
2
5
7
BC7.1
Business capability
Als beheerder wil ik een betalende registratie mogelijk maken.
Ja
0
BC7.2
Business capability
Als beheerder wil ik verschillende 'offer design' (abonnementen, pay per use, rent, buy, enz.) kunnen voorstellen.
Ja
0
BC7.3
Business capability
Als beheerder moet de data oplader eventueel ook vergoeden/vergoed worden ifv contractuele bepalingen.
Ja
0
BC7.4
Business capability
Als beheerder wil ik de 'gebruikers' kunnen aanmanen, disconnecteren, herinneren, in gebreke stellen,… in functie van hun betalingsgedrag.
Ja
0
BC7.5
Business capability
Als beheerder wil ik de klant online laten betalen, of via factuur en overschrijving, of via de bankapp, enz.
Ja
0
BC7.6
Business capability
Als beheerder wil ik op onze applicatie of website reclame kunnen plaatsen om inkomsten te genereren.
Ja
0
BC7.7
Business capability
Als beheerder wil ik de applicaties die op het ORDP gebouwd kunnen worden, factureren ifv hun gebruik, vaste prijs (lump sum), cost based, enz.
Ja
0
BC7.8
Business capability
Als beheerder wil ik alternatieve inkomsten stromen kunnen voorzien (creatie van entiteit (VZW, Cooperatieve,…), facturatie systeem, boekhouding, enz.)
Ja
0
BC7.9
Business capability
Als beheerder wil ik op een 'lucratieve' manier de opladers van data maar ook van reviews, opmerkingen, tips, enz) belonen.
Ja
0
BC7.10
Business capability
Als beheerder wil ik 'sponsoring' kunnen toestaan ifv de 'waarden' die we delen met de 'sponsor'
Ja
0
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.2 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.2-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is.
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.2 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.1 Lokale Open Data Economie (LODE) – Brugge VLOCA-Model V0.1 VLOCA-model V0.2 Lokale Open Data Economie (LODE) – Brugge VLOCA-Model V0.2
Inhoud
Hieronder kan je de elementen van versie V0.2 van dit VLOCA model bekijken.
CoT LODE: Brugge en Gent
2022
VLOCA-model versie 0.2
VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be
Beschrijving en aanpak:
https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model
Strategie volgens use case
Status
Toelichting
Beschrijving
Visie
Voorstel
Wat is de bestaansreden ?
Lokale besturen willen nagaan hoe ze hun (open) data maximaal kunnen inzetten en financieel/maatschappelijk kunnen laten renderen. We zoeken hoe we er maximaal rendement uithalen als we maximaal weten welke samenwerkingsvormen en inzichten we uit de samenwerking willen halen. We vermoeden dat het potentieel kan gemaximaliseed worden wanneer we: -platformen hebben en samenwerking tussen verschillende steden kunnen verwezenlijken. We dienen de interoperabiliteit tussen datasets mogelijk te maken (eerder interoperabele systemen dan gedeelde steden). Steden creëren veel data. We dienen de inzet van open Data en het creëren ervan gerichter te maken.We willen niet enkel de focus op open data die beschikbaar is voor iederen maar tevens op data die we ter beschikking mogen stellen voor derden bv, data die we ter beschikking stellen aan een studiebureau of data die we willen delen met een andere overheidsinstelling bv labo data Brugge delen met VMM. Open data <-> vermarkten
Missie
Voorstel
Wat willen we bereiken ?
Inzichten van hoe de vraag en aanbod van (open) data af te stemmen op elkaar met aanbevelingen, scenario's en business cases voor een pilootcase van een (open) data marktplaats die MIM3 van OASC conform zal zijn en de meest relevante databronnen ter beschikking stelt.
Doel
Voorstel
Wat is het doel van dit project ?
1.Via marktstudi e overzicht van de vragende partijen voor open data binnen de quadruple helix, alsook de bestaande en potentiele bronnen van open data van de quadruple helix in kaart te brengen. 2.Een business pla n die de 'rendabiliteit' illustreert van het ter beschikking stellen van de open data. 3.Een piloo t data marktplaat s die de vraag en aanbod huist met alle vereiste functionaliteiten.
Succesfactor
Voorstel
Hoe meten we succes ? (SMART)
Segmentatie van vragende partijen die typologien van open data al dan niet voor een prijs willen aanschaffen. Een data marktplaats piloot volgens de normen van MIM3 van OASC.
Objectieven van de use case
ID
Status
Samenvatting
Beschrijving
UC1
Voorstel
UC1: De Vraag naar open data
Overzicht via een 'segmentatie' van entiteiten (instituten, bedrijven, organisaties, individuen,...) die de vraag in kaart brengt. De vraag moet gevaloriseerd worden in 'intensiteit' zoals bvb 'bereidheid te betalen' of 'een engagement aangaan' of 'hoeveel dit ons kan doen besparen'.
UC2
Voorstel
UC2: Het aanbod van open data
Overzicht via een typologie van data elementen die reeds of mogelijks in de toekomst kan aangeboden worden door de 'overheid' of andere partijen binnen de quadruple helix.
UC3
Voorstel
UC3: Vraag en Aanbod Matching
Overzicht van de 'affiniteit' tussen de 'behoefte' segmentatie met de 'typologien' van open data (bronnen). =Matrix met Segmenten tov open data typologien. Uiteraard moeten we een derde dimensie toevoegen die ook de 'attributen' van de 'affiniteiten' beschrijven (is het cruciaal, strategisch, tactisch, enz.)
UC4
Voorstel
UC4: Business Case
Overzicht van de kosten en baten van het vrijgeven van open data door de data 'producent' die moet leiden naar een verzameling van business cases per data typologie of per groep van data typologien (de waarde van gecombineerde data bronnen kan ook niet-lineair vermeerderen). Ook rekening houden met de 'dekking' van aanbod in gans Vlaanderen, en het meso niveau van het aanbod zullen een rol spelen in die business case.
UC5
Voorstel
UC5: Draaiboeken
Bibliotheek van draaiboeken per typologie van data (= productgedreven) en per behoefte segment (= klantgedreven) of op typologie- en segmentoverschrijdend niveau (dit laatste is de scope voor het LODE project)
UC6
Voorstel
UC6: Marktplaats
Een piloot open data marktplaats bouwen en beheren waar de vraag en aanbod elkaar tegenkomen. Die marktplaats moet interoperabel en conform de MIM3 van OASC standaarden zijn. De organisatie van de marktplaats zal op hoger niveau liggen dan de lokale besturen. De nadruk blijft op 'samenwerking', 'communicatie' en waarde creeren met 'open'/'niet open' data
UC7
Voorstel
UC7: Futureproof
Een overlegplatform en proces die zorgt dat de marktplaats futureproof is door regelmatig overleg te organiseren tussen de verschillende betrokken (nieuwe) partijen om de vraag en aanbod telkens op elkaar af te stemmen. Dit betekent ook het bouwen en beheren van 'communities', relaties opbouwen met bestaande 'communities', ontdekken van nieuwe 'experimentele' gebruikers van data ook binnen de burgers, ed meer.
UC8
Voorstel
UC8: juridisch
Bouwen van een wettelijk kader die op hoger niveau gevalideerd en dus bruikbaar door lokale besturen voor soortgelijke projecten. Wat kan, wat kan niet, waar liggen de risico's en welke zijn de 'juridische collaboratie documenten' die gebruikt kunnen worden bij elke nieuwe samenwerkingsakkoorden tussen leverancier, klant en marktplaats organisator.
Metadata van de objectieven
Metaveld
Beschrijving
Meta1
Beschrijving meta 1
Meta2
Beschrijving meta 2
Per objectief: business capabilities (BC) >> data vereiste (DV) >> functionele capabilities (FC) >> technische vereiste (TV)
ID
Type
Samenvatting
Beschrijving
UC1
Objectief
UC1: De Vraag naar open data
Overzicht via een 'segmentatie' van entiteiten (instituten, bedrijven, organisaties, individuen,...) die de vraag in kaart brengt. De vraag moet gevaloriseerd worden in 'intensiteit' zoals bvb 'bereidheid te betalen' of 'een engagement aangaan' of 'hoeveel dit ons kan doen besparen'.
BC1.1
Business capability
Grootte van vraag
Hoe groot is de vraag naar open data in aantal 'Entiteiten', intensiteit van de behoefte, bereidheid te betalen, welke type van data, frequentie, minimum kwaliteit, ed meer.
BC1.2
Business capability
Behoefte Segmentatie
Welke behoefte gebaseerde segmenten (Needs Based Segmentation) bestaan er in de quadruple helix die homogeen dezelfde behoeften hebben binnen de segmenten en heterogeen anders zijn tussen de segmenten.
ID
Type
Samenvatting
Beschrijving
UC2
Objectief
UC2: Het aanbod van open data
Overzicht via een typologie van data elementen die reeds of mogelijks in de toekomst kan aangeboden worden door de 'overheid' of andere partijen binnen de quadruple helix.
BC2.1
Business capability
databronnen met potent. Gebruik
Welke zijn de verschillende databronnen die reeds bestaan en wat is hun 'specificiteit' in 'potentieel' gebruik die een behoefte al dan niet kunnen beantwoorden.
BC2.2
Business capability
potentiele databronnen
Welke zijn de verschillende potentiele databronnen die nog 'ontgonnen' kunnen worden met hun specificiteit
BC2.3
Business capability
typologien van databronnen
Welke zijn de 'typologien' die de verschillende databronnen groeperen/clusteren die homogeen binnen en heterogeen tussen de groepen zijn.
BC2.4
Business capability
master/slave update
Bepalen wie de 'master' en wie de 'slave' is mbt het updaten, opkuisen en verwijderen van data.
BC2.5
Business capability
toegankelijkheid
Welke bronnen zijn snel en gemakkelijk ontgonnen en welke minder
BC2.6
Business capability
maturiteit
Welke maturiteitsniveau per databron per 'stad' of 'gemeente'
ID
Type
Samenvatting
Beschrijving
UC3
Objectief
UC3: Vraag en Aanbod Matching
Overzicht van de 'affiniteit' tussen de 'behoefte' segmentatie met de 'typologien' van open data (bronnen). =Matrix met Segmenten tov open data typologien. Uiteraard moeten we een derde dimensie toevoegen die ook de 'attributen' van de 'affiniteiten' beschrijven (is het cruciaal, strategisch, tactisch, enz.)
BC3.1
Business capability
link typologie-segmenten
Lijst van alle data (typologien) die een behoefte van een segment beantwoord.
BC3.2
Business capability
affiniteits matrix
Matrix die de affiniteit van de segmenten naar de data typologien visualiseert om daarmee een 'marketing', 'strategische' en 'operationeel' plan te kunnen uittekenen.
ID
Type
Samenvatting
Beschrijving
UC4
Objectief
UC4: Business Case
Overzicht van de kosten en baten van het vrijgeven van open data door de data 'producent' die moet leiden naar een verzameling van business cases per data typologie of per groep van data typologien (de waarde van gecombineerde data bronnen kan ook niet-lineair vermeerderen). Ook rekening houden met de 'dekking' van aanbod in gans Vlaanderen, en het meso niveau van het aanbod zullen een rol spelen in die business case.
BC4.1
Business capability
Business Planning
Een business plan kunnen opstellen om een 'product' op de markt te plaatsen. Dit 'product' bestaat uit een databron die beantwoord aan een behoefte van een 'segment'.
BC4.2
Business capability
Advies Piloot Start
Het kunnen adviseren over welke de meest relevante bronnen voor welke participerende vragende partij moeten ontsloten worden in de piloot marktplaats
ID
Type
Samenvatting
Beschrijving
UC5
Objectief
UC5: Draaiboeken
Bibliotheek van draaiboeken per typologie van data (= productgedreven) en per behoefte segment (= klantgedreven) of op typologie- en segmentoverschrijdend niveau (dit laatste is de scope voor het LODE project)
BC5.1
Business capability
draaiboek per bron
Per databron een 'draaiboek' terugvinden die uitlegt hoe die data te capteren, verwerken, opslaan en ontsluiten voor een bepaalde segment behoefte
BC5.2
Business capability
draaiboek per segment
Per Segment behoefte, een 'draaiboek' terugvinden die uitlegt welke databronnen er moet 'ontgonnen' worden om zo de behoefte te kunnen invullen.
BC5.3
Business capability
draaiboek dataspace
Draaiboek van hoe een lokale 'marktplaats' te bouwen, maar die geconnecteerd is met de andere marktplaatsen via een dataspace principe.
ID
Type
Samenvatting
Beschrijving
UC6
Objectief
UC6: Marktplaats
Een piloot open data marktplaats bouwen en beheren waar de vraag en aanbod elkaar tegenkomen. Die marktplaats moet interoperabel en conform de MIM3 van OASC standaarden zijn. De organisatie van de marktplaats zal op hoger niveau liggen dan de lokale besturen. De nadruk blijft op 'samenwerking', 'communicatie' en waarde creeren met 'open'/'niet open' data
BC6.1
Business capability
gemak ontsluiten
Het gemakkelijk/transparant kunnen ontsluiten van data (of andere assets zoals componenten, schema's, vocabularium, ed) in de marktplaats
BC6.2
Business capability
metadata (DCAT)
Publiceren van metadata in lijn met internationale standaarden zoals DCAT
BC6.3
Business capability
Lineage/Callibraties/…
Transparant publiceren van de 'afkomst'/'Lineage'/'Callibraties'/Intrapollaties en Extrapollaties/enz.
BC6.4
Business capability
Schema & Semantiek
Publicatie van of verwijzen naar schema en semantiek
BC6.5
Business capability
Transport Formaat
Publiceren van de transport schema waarmee de data beschikbaar is (http, mqtt, ftp,...)
BC6.6
Business capability
Facturatie
Het kunnen factureren van de data downloads a priori of a posteriori
BC6.7
Business capability
content metadata
Wat is de 'inhoudelijke' metadata van de verschillende beschikbare databronnen (via DCAT ?)
BC6.8
Business capability
toegang verlening
Het kunnen toegang verlenen via toegansbeheer platform afhankelijk van de gebruikersrechten
BC6.9
Business capability
Reviews & Feedback
Reviews en feedback kunnen geven op die data (vanuit de gebruiker)
BC6.10
Business capability
Update Notificatie
Notificaties wanneer data geupdate werden
BC6.11
Business capability
Transactionele Historiek
Het registreren van transacties (= clearinghouse + voor inzichten op statistieken)
BC6.12
Business capability
Access Controle
Access controle
BC6.13
Business capability
Identificatie Gebruiker
Moet gebruik kunnen maken van derde identiteits providers (it's me,...)
BC6.14
Business capability
CRM Activiteiten
CRM communicatie and marketing en verkoopsplanning
BC6.15
Business capability
Betalingsmogelijkheden
Betalingsmogelijkheden
BC6.16
Business capability
Prijs Catalogus
Prijs structuur opstellen en publiceren
BC6.17
Business capability
Gebruiksrechten & Charters
Publiceren van gebruiksrechten van data (alsook een open data charter waar de aanbieders en gebruikers zich moeten houden)
BC6.18
Business capability
Zoekmethodes
Een 'google' manier (search engine) om data terug te vinden.
BC6.19
Business capability
Groepering Visueel
Een visuele manier om data te categoriseren of behoeften te segmenteren.
BC6.20
Business capability
federerende catalogi
Moet passen in een gefedereerde netwerk van catalogi (ref. dataspaces)
ID
Type
Samenvatting
Beschrijving
UC7
Objectief
UC7: Futureproof
Een overlegplatform en proces die zorgt dat de marktplaats futureproof is door regelmatig overleg te organiseren tussen de verschillende betrokken (nieuwe) partijen om de vraag en aanbod telkens op elkaar af te stemmen. Dit betekent ook het bouwen en beheren van 'communities', relaties opbouwen met bestaande 'communities', ontdekken van nieuwe 'experimentele' gebruikers van data ook binnen de burgers, ed meer.
BC7.1
Business capability
Stakeholder Analysis
Wie zijn de relevante betrokken partijen uit de quadruple helix
BC7.2
Business capability
Werkmethode
Opstellen van een werkmethode/beheermethode
BC7.3
Business capability
overlegmomenten
Organiseren van live of digitale communicatie tussen de partijen (overlegmomenten, newsletters, conferenties, webinars, enz.)
ID
Type
Samenvatting
Beschrijving
UC8
Objectief
UC8: juridisch
Bouwen van een wettelijk kader die op hoger niveau gevalideerd en dus bruikbaar door lokale besturen voor soortgelijke projecten. Wat kan, wat kan niet, waar liggen de risico's en welke zijn de 'juridische collaboratie documenten' die gebruikt kunnen worden bij elke nieuwe samenwerkingsakkoorden tussen leverancier, klant en marktplaats organisator.
BC8.1
Business capability
snelle legale beslissing
Snel kunnen beslissen of iets al dan (nog) niet mag gepubliceerd worden via een 'beslissing boom'
BC8.2
Business capability
contract templates
templates' van contracten tussen leveranciers, marktplaats beheer en data klanten
BC8.3
Business capability
Overzicht verplichtingen
Overzicht hebben van welke verplichtingen en wetten moeten voldoen zijn bij welke type van data
BC8.4
Business capability
SLA enabling
Kunnen een SLA opstellen en afdwingen via contractuele verbintenissen
BC8.5
Business capability
dataregister
Opstellen van dataregister om conform te zijn met de wet
BC8.6
Business capability
Classificatie
Classificatie via labels (bvb van 1 tot 5) van databronnen ifv legale en contractuele beperkingen of verplichtingen
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.2 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.2-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is.
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.2 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.2 van dit VLOCA model bekijken.
Naam Traject
Start periode traject
VLOCA-model versie 0.2
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. Eigenlijk uiteindelijk is het de bedoeling van alle gebouwen een BIM bestand te hebben.
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. Kan 'open' of via 'login'
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
UC8
Voorstel
UC8 : Afbraakwaarde
Berekening kunnen doen om verkoopswaarde vs rennovatie vs afbraak van eender welk leegstand gebouw
UC9
Voorstel
UC10
Voorstel
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. Eigenlijk uiteindelijk is het de bedoeling van alle gebouwen een BIM bestand te hebben.
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. Kan 'open' of via 'login'
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
Mogelijkheid om en succesfactor van het project te kunnen visualiseren
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
ID
Type
Samenvatting
Beschrijving
UC8
Use case
UC8 : Afbraakwaarde
Berekening kunnen doen om verkoopswaarde vs rennovatie vs afbraak van eender welk leegstand gebouw
ID
Type
Samenvatting
Beschrijving
UC9
Use case
0
0
ID
Type
Samenvatting
Beschrijving
UC10
Use case
0
0
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.
Support Traject : Datagedreven handelsbeleid binnenstad
juli 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 volgens use case
Status
Toelichting
Beschrijving
Visie
Voorstel
Wat is de bestaansreden ?
De binnenstad is het hart van de stad, een bruisende omgeving die de bezoekers begeestert met zowel cultuur, horeca als winkelen. Deze drie activiteiten versterken elkaar 'opportunistisch'.
Missie
Voorstel
Wat willen we bereiken ?
We willen in de binnenstad een retail beleid kunnen voeren die meer data gedreven is, waarbij de stad de retailers helpt om te bloeien en groeien.
Doel
Voorstel
Wat is het doel van dit project ?
De binnenstad moet continue attractiever worden voor de retailers
Succesfactor
Voorstel
Hoe meten we succes ? (SMART)
De gemiddelde huur- en verkoopprijs voor winkelpanden (alsook woonpanden in zekere mate) in de binnenstad stijgt jaaarlijks met x% omdat de vraag groter wordt dan de aanbod.
Objectieven van de use case
ID
Status
Samenvatting
Beschrijving
O1
Voorstel
Stadsmarketing
De marketing campagnes van de stad zijn efficient en gericht ("targeted") zijn tegen 2023 (in tegenstelling tot eerder "broadcasting")
O2
Voorstel
Intelligentie
De stad levert actioneerbare inzichten en intelligente cijfers mbt trends van bezoekers in de binnenstad aan de bestaande en potentiele retailers tegen 2023
O3
Voorstel
Druktegraad tov capaciteit
De druktegraad en de parkeerbezetting om de winkelende bezoekers te kunnen opvangen moet altijd lager zijn dan 90% van de totale capaciteit
O4
Voorstel
Attractiviteit
De attractiviteit van de binnenstad opvolgen met objectieve KPIs
O5
Voorstel
Mobiliteitsbeleid
Verbeteren van de stad toegangkelijkheid via vervoersmodi
Metadata van de objectieven
Metaveld
Beschrijving
Marketing
Acquisitie van nieuwe bezoekers naar de binnenstad (liefst die nog ook kunnen en willen spenderen), Retentie (zorgen dat de bezoekers herhalend komen shoppen), Ontwikkelen (bij een bezoek van een bvb cultureel evenement begeleiden naar de winkelstraten = x-selling) of stimuleren van aankoop bij verschillende winkels = upselling.
Campagnes
Een Campagne kan zowel puur communicatief zijn, of organiseren van 'evenementen' die bezoekers moet brengen naar een gebied. Een campagne word gevalueerd ifv de ' gr p'
GRP
Gross Rating Point, of afgekort GRP, is een manier om de omvang van een advertentiecampagne te meten op basis van een specifiek medium of schema. In plaats van de omvang te meten van het publiek dat bereikt is, worden impressies gemeten als percentage van de totale doelgroep.
Captatie
Hoeveel percentage van de doelgroep heeft minstens 1 impressie bereikt.
gericht
gebaseerd op een doelgroep die men bereikt. GRP en Captatie maximaliseren en 'waste' minimaliseren.
actioneerbare inzichten
Informatie die nadruk legt op de 'now what' ipv enkel de 'what' en de 'so what', soms worden die verrijkt met 'vooruitzichten' zowel macro als micro economisch
micro economische vooruitzichting
Een externe inzicht gebaseerd op een lokale verwachte event, zoals bvb grote werken binnen de stad, grote shoppingcenter net buiten de stad, ed.
macro economisch
Een externe inzicht gebaseerd op nationale of internationale tendensen waar de stad niet aan kan ontsnappen. Bvb het online boeken van reizen, corona beperkingen, enz.
intelligente cijfers
pure cijfers kunnen ook inzichtvol gemaakt worden indien ze 'slim' zijn opgebouwd, men spreekt ook over 'smart kpi', bvb een ratio is veel sterker dan een absolute cijfer.
trends
tegenpool van snapshot waar ipv de laatste gegevens ook de tendens gevoed door het gedrag van het verleden. Een snapshot zegt niet of dit aan het dalen is of aan het stijgen.
bezoeker
iemand die een gebied binnenkomt via allerlei kanalen (wagen, trein, te voet)
retailers
winkels, cabinetten van
bezorgen
Bezorgen kan ofwel in een ' pus h' of ' pul l' modus zijn, kan in de vorm van csv/xls of ppt/pdf waarbij conclusies en recommendaties mogelijk worden, en met bepaalde frequentie
push modus
de retailers krijgen die informatie toegestuurd via papieren document of in hun email box
pull modus
de informatie wordt centraal terbeschikking gesteld op een portaal waar de retailers ze 'vrij' kunnen bekijken of downloaden
csv/xls
de cijfers zijn in ruwe formaat beschikbaar zodat de retailer die zelf kunnen manipuleren en integreren in eigen business modellen
ppt/pdf
de cijfers worden reeds geagregeerd met conclusies en eventueel recommendaties
frequentie
bepaalt welke informatie wordt geupdate met welke frequentie (realtime, dagelijks, wekelijks, maandelijks, kwartaal, seizoen, semester of jaarlijks)
Capaciteit
Een indicator die zowel de maximale 'drukte' in de binnenstad (waarbij het nog 'leuk' is voor de gemiddelde bezoeker') alsook de 'parkeerbezetting' berekend wordt in een percentage die frequent kan gemeten en gerapporteerd worden
Vervoersmodi
Manier waarop bezoeker de stad (kan) binnentreden (auto, trein, fiets, te voet, shuttle, tram, bus, enz.)
Attractiviteit
Attractiviteit is gemeten door de huurprijs, aankoopprijs per vierkante meter, leegstand in aantal en in gemiddelde tijd, enz. En dit vooral voor winkelpanden, maar ook voor bewoners van panden in de binnenstad.
Per objectief: business capabilities (BC) >> data vereiste (DV) >> functionele capabilities (FC) >> technische vereiste (TV)
ID
Type
Samenvatting
Beschrijving
O1
Objectief
Stadsmarketing
De marketing campagnes van de stad zijn efficient en gericht ("targeted") zijn tegen 2023 (in tegenstelling tot eerder "broadcasting")
BC1.1
Business capability
We meten de conversie ratio 'bezoekers ' tot ' binnenstapper s' met historiek
BC1.2
Business capability
We meten de conversie ratio tot ' besteder s' met historiek
BC1.3
Business capability
We 'de-averagen ' de ratio van BC1.1 en BC1.2 per 'profiel ' in de tijd
BC1.4
Business capability
We ' profilere n' de 'bezoeker' op ' soci o demografisch e' variabelen op criteria bvb kassatickets
BC1.5
Business capability
We 'profileren ' de 'bezoeker ' op zijn/haar 'winkelmissie'
BC1.6
Business capability
We 'profileren ' de 'bezoeker ' op zijn/haar ' behoeft e', ' motivati e' en ' verwachtin g'
BC1.7
Business capability
We documenteren het 'potentiël e afzetgebie d' van de 'prospecten ' van de binnenstad
BC1.8
Business capability
We analyseren via een ' uitwisselingsmatri x' hoe de participatie of bezoek van een evenement of attractie 'park' elkaar al dan niet versterken
BC1.9
Business capability
We analyseren de commerciele impact van evenementen (zoals jaarmarkten, festivals,...) op de detailhandel door te vergelijken met gelijkaardige momenten (of plaatsen) waar er geen eventement aanwezig was.
BC1.10
Business capability
We tekenen met behulp van BC1.1 tem BC1.7 een marketing plan uit dat de ideale 'prospect ' met ' communicatie op maat ' naar de binnenstad moet brengen. De juiste boodschap voor de juiste prospect door middel van het juiste kanaal op het juiste moment.
BC1.11
Business capability
We meten voor elke campagnes de geschatte ' ROI ' voor de handelaars in de binnenstad, vooral in termen van 'binnenstappers ', 'besteders ' en ' omzet'
BC1.12
Business capability
We meten en visualiseren de ' customer journe y' om zo te begrijpen waar de winkels/horeca zich ook kunnen plaatsen in de zijstraten bvb.
BC1.13
Business capability
We meten en visualiseren de 'Koopstromen'
BC1.14
Business capability
We gebruiken externe parameters om bepaalde resultaten te verklaren, bvb het weer, de temperatuur, corona maatregelen, aantal werken in de stad, treinstakingen, enz.
ID
Type
Samenvatting
Beschrijving
O2
Objectief
Intelligentie
De stad levert actioneerbare inzichten en intelligente cijfers mbt trends van bezoekers in de binnenstad aan de bestaande en potentiele retailers tegen 2023
BC2.1
Business capability
We capteren de behoeften van de retailers voor data, van de datacatalogus, en inzichten per 'sector'
BC2.2
Business capability
We communiceren met de handelaars
BC2.3
Business capability
We ontsluiten de data van BC1 op een platform en een catalogus met uitleg over de data, alsook de metadata en schema
BC2.4
Business capability
We analyseren de data van BC1 en formuleren daaruit conclusies en aanbevelingen.
BC2.5
Business capability
We maken de toegang tot bepaalde data van BC1 betalend
BC2.6
Business capability
We beantwoorden de ad ho c vragen van handelaars
BC2.7
Business capability
We factureren de dienst aan de handelaar
BC2.8
Business capability
We stellen trends per sector op om te begrijpen welke data elementen door welke sector gebruikt worden
BC2.9
Business capability
We voorzien een regelmatig overzicht van conclusies en aanbevelingen voor de verschillende sectoren
BC2.10
Business capability
We verrijken de conclusies en aanbevelingen met externe micro- en macro-economische factoren
BC2.11
Business capability
Wij adviseren de lokale handelaars op vlak van verwachte drukte, personeelsinzet, openingsdagen/uren
BC2.12
Business capability
Wij analiseren de performantie van aantrekkings incentives zoals loyalty, spaarkaarten, vouchers en stadsapp punten, ed op het bezoek en besteding in de stad
ID
Type
Samenvatting
Beschrijving
O3
Objectief
Druktegraad tov capaciteit
De druktegraad en de parkeerbezetting om de winkelende bezoekers te kunnen opvangen moet altijd lager zijn dan 90% van de totale capaciteit
BC3.1
Business capability
We meten de pieken en dalen van de parkeerbezetting, geografisch, per dag en per moment van de dag
BC3.2
Business capability
We meten de bezoekers aantallen en bestedingen per transportmodus (trein, wagen, fiets, voetganger, bus, ea)
BC3.3
Business capability
We meten de pieken en dalen van de wandeldrukt e geografisch, per dag en per moment van de dag
BC3.4
Business capability
We bepalen een objectieve inde x, die subjectief aangeeft of het aangenaam wandelen en winkelen is in de binnenstad.
ID
Type
Samenvatting
Beschrijving
O4
Objectief
Attractiviteit
De attractiviteit van de binnenstad opvolgen met objectieve KPIs
BC4.1
Business capability
We meten de huurprijs per vierkante meter van winkelpanden in de binnenstad
BC4.2
Business capability
We meten de huurprijs per vierkante meter van woonpanden in de binnenstad
BC4.3
Business capability
We meten de verkoopprijs per vierkante meter van winkelpanden in de binnenstad
BC4.4
Business capability
We meten de verkoopprijs per vierkante meter van woonpanden in de binnenstad
BC4.5
Business capability
We meten de leegstand en de duur van de leegstand van winkelpanden in de binnenstad
BC4.6
Business capability
We meten de leegstand en de duur van de leegstand van woonpanden in de binnenstad
BC4.7
Business capability
We berekenen een attractiviteits index van de binnenstad
ID
Type
Samenvatting
Beschrijving
O5
Objectief
Mobiliteitsbeleid
Verbeteren van de stad toegangkelijkheid via vervoersmodi
BC5.1
Business capability
Tijdsspanne om van de randgemeenten en randsteden tot in de binnenstad te geraken
BC5.2
Business capability
Simulaties van impact van maatregelen op de tijdsspanne
BC5.3
Business capability
Kosten per transportmodi kunnen bepalen om een ROI van het beleid op retail omzet te kunnen bepalen
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.
CoT Slimme stadsdistributie – Hasselt
Start periode traject
Stakeholderanalyse V0.1
VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be
Beschrijving en aanpak:
https://vloca-kennishub.vlaanderen.be/Deliverable:Stakeholderanalyse
Toelichting van de velden
Stakeholder
Wie is de stakeholder?
Functie
Wat is functie van de stakeholder bij dit traject?
Intern of extern
Interne of externe stakeholder
Quadruple Helix
Overheden, kenniscentra, burgerparticipaties of industrie
Stakeholder actie
Volgens gezag en interesse: monitoren, informeren, tevreden houden of nauw betrekken
Specifieke noden, behoeften en barrières
Welke specifieke noden, behoeften en barrières?
Communicatiekanalen
Via welke kanalen wordt er gecommuniceerd over het traject of use cases?
Identificatie van de stakeholders
Stakeholder
Functie
Intern of extern
Quadruple Helix
Stakeholder actie
Stad Hasselt
Initiatiefnemer (lead)
Intern
Overheden
Nauw betrekken
Stad Leuven
Initiatiefnemer (volgend)
Intern
Overheden
Nauw betrekken
Stad Antwerpen
Initiatiefnemer (volgend ter inspiratie)
Intern
Overheden
Nauw betrekken
Stuurgroep Slimme stadsdistributie
Stuurorgaan van initiatief
Intern
Overheden
Tevreden houden
Inwoners binnenstad
Als inwoners (overlast) en bestemmelingen
Extern
Burgerparticipatie
Tevreden houden
Handelaars binnenstad
Registreerders en bestemmelingen
Extern
Industrie
Tevreden houden
Andere steden en gemeenten
Deelnemers werkgroep
Extern
Overheden
Informereren
Digitaal Vlaanderen (OSLO)
Data standaarden
Extern
Overheden
Informereren
Agentschap Binnenlands Bestuur
Architectuur
Extern
Overheden
Informereren
Politie
Deelnemers werkgroep
Extern
Overheden
Monitor
Departement Mobiliteit en Openbare Werken
Deelnemers werkgroep
Extern
Overheden
Monitor
Vlaamse Milieu Maatschappij
Deelnemers werkgroep
Extern
Overheden
Monitor
Universiteiten
Deelnemers werkgroep
Extern
Kenniscentra
Monitor
Leveringsdiensten en transportbedrijven
Deelnemers werkgroep
Extern
Industrie
Monitor
Onderzoeksintstellingen
Deelnemers werkgroep
Extern
Kenniscentra
Monitor
Mobiliteit en MaaS
Deelnemers werkgroep
Extern
Industrie
Monitor
Verenigen van ondernemingen
Deelnemers werkgroep
Extern
Industrie
Monitor
Voorbeeld dynamische tekening +
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.2 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.2-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is.
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.2 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.2 van dit VLOCA model bekijken.
Level2
Level3
Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) – Halle
2022
Versie: 0.2
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 'interactief' een advertentie van de lokale winkels laat zien
UC2
Voorstel
UC2: Media Centrale
Een pseudo media centrale die de advertenties controleert, toekent en 'factureert' 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
UC6
Voorstel
UC6:CRM
Marketing Communicatie tool om gerichte of informatieve contacten met de klanten of prospecten te kunnen doen
UC7
Voorstel
UC7:Helpdesk
Meldingen en klachten alsook vragen en opmerkingen (FAQ, reviews, ...)
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
Activatie
Als beheerder wil ik roterende visualisering van advertenties kunnen activeren (technisch uitvoeren ipv de planning)
BC1.2
Business capability
interactief
Als beheerder wil ik de burger interactieve opzoek mogelijkheden (via touchscreen of via handgebaren...) kunnen aanbieden
BC1.3
Business capability
QR ea
Als beheerder wil ik aan de bezoeker een snelle begeleiding, kortingen of reservering bvb via touchscreen of QR codes kunnen aanbieden
BC1.4
Business capability
'referendum'
Als beleid wil ik de burgers kunnen bevragen om hun mening op bepaalde vragen te stellen
BC1.5
Business capability
media centrale stopzetting
Als adverteerder wil ik mijn advertentie vroegtijdig kunnen stoppen (out of stock bvb)
BC1.6
Business capability
uitsluiting (gratis vs subscription vs campagne grp vs...)
Als beleid wil ik adverteerders kunnen 'mijden' na bvb een misbruik of als tuchtmaatregeling of via prijssetting/suscription
BC1.7
Business capability
Via mob/desktop app
Als wandelaar wil ik het scherm ook kunnen terugvinden op een stadsapp bvb op mijn gsm of zelfs thuis via een website
BC1.8
Business capability
Sharing
Als wandelaar wil ik de info/korting/enz kunnen delen met derden (vrienden, familie,...)
BC1.9
Business capability
Sensoren & metingen
Als beleid wil ik bepaalde metrieken zoals passanten bvb kunnen tellen via camera's, micros (geluidsoverlast,...), luidsprekers, termometers, luchtkwaliteit en andere sensoren die aan de schermen gelinkt kunnen worden
BC1.10
Business capability
Continue QR code
Als wandelaar wil ik via een QR code kunnen gebruiken om tot een 'website' te komen waar ik de advertenties kan 'swipen' om de 'net verdwenen' advertentie te kunnen terugvinden, of de handelaar te kunnen contacteren direct via gsm, enz.
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
Regels
Als beleid wil ik de advertentieregels (bvb maar 7% van schermtijd voor de corporates/niet lokale handelaars) kunnen bepalen en invoeren, alsook de 'rechten' toekenning aan de verschillende types van adverteerders (zie 3.12). Ook zien hoe we iedereen een kast geven, niet enkel de 'rijke' succesvolle winkels bvb.
BC2.2
Business capability
Roteringsplanning
Als beleid wil ik de Roterings Planning kunnen opmaken en invoeren
BC2.3
Business capability
facturatie
Als medewerker wil ik de adverteerders kunnen factureren
BC2.4
Business capability
templates
Als medewerker wil advertentie templates met tips en tricks kunnen aanbieden aan de handelaars
BC2.5
Business capability
controle ethiek
Als beheerder wil ik controle kunnen voeren op de te vertonen advertentie (ethische richtlijnen moeten gevolgd worden, enz.)
BC2.6
Business capability
Marketing
Als adverteerder (of media agentschap) wil ik de advertentie kunnen integreren in mijn marketing campagne tool
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
templates
Als adverteerder wil ik een keuze uit templates kunnen maken met drag en drop van foto materiaal en logo met bijhorende tekst
BC3.2
Business capability
prijs setting
Als medewerker wil ik een prijs settings mechanisme kunnen ontwikkelen en implementeren, incl. die pragmatisch last minute advertenties toelaat, klein vs grote onderneming, betaalt reeds promotaks, of ifv promotaks, of gebruik maken van de data die hebben geleid promotaks berekening. Of zelfs ook 'gratis' packet (stukje gratis en stukje betalend). Abonnement vs Per 'Post' vs. Per Campagne vs. Per 'Views' vs. Per Passanten vs. Per QR code views, enz...
BC3.3
Business capability
Registratie
Als adverteerder wil ik mezelf gemakkelijk kunnen registreren met validatie van voorwaarden (is die in de stad geregistreerd, is die individu gemachtigd voor het 'bedrijf', enz.)
BC3.4
Business capability
Media Agentschap
Als media agentschap wil ik voor de eigenlijke adverteerders hun campagnes 'ontzorgen' door aparte login te krijgen
BC3.5
Business capability
Website vs App
Als adverteerder wil ik via een website (via laptop) dezelfde handelingen kunnen doen (om ook inclusie toe te laten bvb)
BC3.6
Business capability
Groeperingen
Als adverteerders willen wij 'events' kunnen adverteren waarin een groep handelaars samen een advertentie of informatie te kunnen doen.
BC3.7
Business capability
Training & toegang
Als beleid wil ik de toegang kunnen limiteren tot een handelaar die een geslaagde opleiding (ivm ethiek, esthetiek want we willen de straatbeeld niet pollueren met lelijke advertenties,...) kunnen voorleggen
BC3.8
Business capability
Gaming
Als beleid wil ik de bezoekers kunnen lokken naar de binnenstad door spelletjes die ze via de digitale schermen kunnen activeren
BC3.9
Business capability
Recrutering
Als handelaar wil ik ook jobadvertenties kunnen plaatsen op de digitale schermen
BC3.10
Business capability
Opportunistisch
Als horeca/markt wil ik 'vrije' tafels/overstock op het einde van de dag kunnen adverteren op een 'vluchtige' manier
BC3.11
Business capability
Spaarpunten
Als wandelaar wil ik spaarpunten kunnen krijgen bij het gebruik van de digitale schermen, of integratie met bestaande spaarpunten
BC3.12
Business capability
Rechten Toekenning
Als beleid wil ik aan verschillende typolgien van adverteerders verschillende 'rechten' kunnen geven, bvb Wegenwerken en Toerisme krijgen meer 'rechten' dan 'lokale handelaars'.
BC3.13
Business capability
Voorstel Segmentatie
Als adverteerder wil ik mijn doelgroep kunnen invoeren en een voorstel kunnen krijgen van waar en wanneer zou ik als beste mijn advertentie plaatsen.
BC3.14
Business capability
Special Request
Als adverteerder wil ik specifieke plaatsen (visueel voorstelling van de digitale schermen en met muisklik geselecteerd worden?) en tijdstippen kunnen kiezen waar mijn advertenties zullen getoond moeten worden. (bvb ontbijt enkel in de voormiddag, dagschotel die recurrent op een weekdag wordt getoont,...)
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
passanten
Als beleid wil ik het aantal passanten kunnen meten en ook rapporteren aan de adverteerders
BC4.2
Business capability
viewers
Als beleid wil ik het aantal 'viewers' kunnen capteren en tellen en ook rapporteren aan de (potentiele) adverteerders
BC4.3
Business capability
appreciatie
Als beleid wil ik de gezichtsuitdrukkingen van de 'viewers' kunnen meten en ook rapporteren aan de (potentiele) adverteerders
BC4.4
Business capability
ROI Campagnes
Als adverteerders wil de ROI van een campagne kunnen meten en berekenen door de binnenstappers en besteders te bepalen van de 'viewers'
BC4.5
Business capability
AB Testen
Als adverteerder (en medewerker) wil ik de mogelijkheid hebben om (experimentele) AB testen te kunnen doen (vergelijken van verschillende advertenties op de commerciele resultaten van de adverteerder)
BC4.6
Business capability
Segmentatie per periode
Als adverteerder wil ik weten welke segmenten ik kan bereiken op welk moment in welke straat segment die evt in mijn doelgroep zitten
BC4.7
Business capability
% Schermtijd
Als beleid wil ik de schermtijd (in piek momenten bvb) kunnen rapporteren ifv lokale business, overheid, instellingen, corporates, global brands, enz
BC4.8
Business capability
Zijstraten
Als beleid wil ik dat de winkels in de zijstraten ook visibiliteit kunnen krijgen dankzij de digitale schermen in de hoofdstraten
BC4.9
Business capability
Beleid & Info
Als stad wil ik de digitale schermen ook kunnen gebruiken om mijn beleid en andere info te verspreiden aan de wandelaars in de binnenstad
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
OSLO
Als ontwikkelaar wil ik de OSLO standaarden voor de app en media centrale bepalen en gebruiken in mijn applicatie
BC5.2
Business capability
Andere Steden
Als beleid, medewerker en ontwikkelaar wil ik de uitbreidbaarheid van de media centrale en de app voor andere steden openlaten mits afspraken op delen van budgetten/kosten (Raamovereenkomst)
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.2 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.2-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is.
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.2 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.2 van dit VLOCA model bekijken.
CoT Mobiliteitsbudget voor burgers – 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 gekregen en beschikbare 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.
UC9
Voorstel
UC9
Een platform die ook voor deelmobiliteit's aanbieders toegang te geven en te integreren
UC10
Voorstel
UC10
Metadata
Metaveld
Beschrijving
Meta1
Beschrijving meta 1
Meta2
Beschrijving meta 2
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
Traject Invoer
Als gebruiker wil ik via een mapping tool een adres of POI (point of interest) in te voeren voor een 'start' punt en 'eind' punt van mijn traject
BC1.2
Business capability
Inlog & check
Als beheerder wil ik de gebruiker laten inloggen en checken of hij/zij een burger/bewoner is van de stad
BC1.3
Business capability
Traject Voorstel
Als gebruiker wil ik een voorstel kunnen krijgen 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
Trajecten Overzicht
Als gebruiker wil ik een overzicht zien van alle relevante mobiliteit 'issues' en 'events' in de openbare domeinen (openbare werken, omleidingen,ed)
BC1.5
Business capability
Parkeerplaats
Als gebruiker wil ik een parkeerplaats kunnen bemachtigen (reserveren?) met korting
BC1.6
Business capability
multimodaal
Als gebruiker wil ik mijn traject kunnen kiezen die multi modaal (bvb trein+bus+step) zal zijn en daarop ook een korting krijgen op het totaal packet
BC1.7
Business capability
Menukaart
Als gebruiker wil ik een overzicht kunnen zien van alle mobiliteitsdiensten die ik eventueel zou kunnen raadplegen
BC1.8
Business capability
Extra Korting
Als burger wil ik extra kortingscodes kunnen invoeren die 'on top of' mijn huidige krediet/korting kan gecumuleerd worden
BC1.9
Business capability
Fietsaankoop
Als gebruiker wil ik met mijn 'krediet' ook een fiets (gedeeltelijk of met korting) kunnen kopen
BC1.10
Business capability
alerting
Als gebruiker wil ik een berichtje krijgen indien mijn budget bijna leeg is
BC1.11
Business capability
meereizigers
Als gebruiker wil ik een rit/traject kunnen kopen voor verschillende mensen in één keer (bvb kinderen in een gezin, groep reizigers)
BC1.12
Business capability
reviews
Als gebruiker wil ik een feedback kunnen geven over de aanbod, de applicatie, de uiteindelijk voorgestelde traject, ed meer.
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
Als gebruiker wil betalingsmogelijkheid hebben, via de applicaties, aan de verschillende participerende mobiliteits aanbieders
BC2.2
Business capability
betalingsbewijs
Als gebruiker wil ik gemakkelijke betalingsbewijs kunnen produceren om bij controles te kunnen laten zien.
BC2.3
Business capability
Website Toekenning
Als 'Speler', 'Stad', 'Werkgever' wil ik de toekenning van kredieten via een 'website' ook kunnen doen en beheren
BC2.4
Business capability
Website Gebruik
Als gebruiker wil ik de ganse transactie ook via een website (en niet enkel via een applicatie) kunnen doen (om inclusiviteit te verzekeren)
BC2.5
Business capability
Krediet naar Korting
Als beheerder wil ik een korting kunnen toekennen ipv een krediet op een aankoop
BC2.6
Business capability
facturatie
Als gebruiker wil ik een factuur kunnen krijgen van de bestelling met evt betalingsbewijs
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 gekregen en beschikbare krediet.
BC3.1
Business capability
Captatie Duurzaamheid
Als beheerder wil de duurzaam handelen per participerende burger capteren
BC3.2
Business capability
Inschrijving Participatie
Per gebruiker wil ik mij kunnen inschrijven om te participeren aan dit project met validatie proces (is die aanvraag correct en binnen doelgroep)
BC3.3
Business capability
Link Budget met handelen
Als beheerder wil de 'budget' die is gelinkt geweest aan een 'duurzaam handelen' kunnen laten toekennen door de stad of participerende mobiliteits organisatie of andere derde partijen.
BC3.4
Business capability
Overzicht Transacties
Als gebruiker wil ik een overzicht krijgen van mijn eigen 'rekening', alle inkomende budgetten met transacties.
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
Controlegroep
Als beleid en beheerder moeten we een 'controle groep' kunnen kiezen die de budgetten niet krijgen om nadien hun mobiliteitsgedrag te vergelijken met de participerende burgers
BC4.2
Business capability
Segmentatie
Als beleid wil ik de toegekende en gebruikte budgetten per type van gebruiker (segmentatie) kunnen meten om daaruit inzichten te halen (wie krijgt en spendeert wat, wanneer en waar)
BC4.3
Business capability
Bewonerskaart
Als beleid wil ik een historiek (en trends) van de toekening van bewonerskaarten per segment
BC4.4
Business capability
Impact Applicatie
Als beleid wil ik een verschil kunnen zien in toegekende bewonerskaarten ifv gebruik van mobiliteitskredieten applicatie.
BC4.5
Business capability
modal shift
Als beleid wil ik kunnen zien of dat project een modal shift heeft gegenereerd
BC4.6
Business capability
Impact Analyse
Als beleid wil ik weten wat de gebruiker zou gebruikt hebben indien hij geen gebruik kon maken van het mobiliteitsbudget
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
als beleid wil ik het variabele gebruik kunnen capteren opdat ik kan berekenen met een formule hoeveel subsidies moeten gegeven worden
BC6.2
Business capability
Historiek
Als beleid wil ik een volledige en gedetailleerde historiek alsook beleidslijn (versionering van alle beleidsbeslissingen) van subsidie toekenningen kunnen zien.
BC6.3
Business capability
rekenmachine
Als beleid wil ik een 'rekenmachine' hebben die de te betalen subsidie ifv beleidlijn en variabel gebruik door de burger kan berekenen
ID
Type
Samenvatting
Beschrijving
BC7.1
Business capability
Inlog & check
Als Werkgever wil ik mij kunnen inloggen en na checks de zekerheid hebben dat ik gemachtigd ben om te doen wat ik wil doen
BC7.2
Business capability
Historiek
Als werkgever wil ik een 'beslissingsboom' kunnen invoeren die bepaalt wie van mijn werknemers wat krijgt
BC7.3
Business capability
Overzicht Transacties
Als werkgever en werknemer wil ik een overzicht kunnen zien van alle transacties (inkomend en gebruik) voor bvb boekhouding en belastingsaangifte ed meer
BC7.4
Business capability
Betalingen
Als werkgever wil ik een budget kunnen betalen/transfereren op de 'rekening' van mijn werkgever
BC7.5
Business capability
Van Geld naar Krediet
Als werkgever wil ik 'geld' kunnen betalen (en gefactureerd worden door de 'owner' van de applicatie) om de krediet te kunnen transfereren naar de werknemers
BC7.6
Business capability
Van Krediet naar Geld
Als werkgever wil ik mijn geld kunnen terugkrijgen indien bvb de saldo niet is opgebruikt, of bij stopzetting van het project bij de werkgever.
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
Als 'Speler' moet ik gemakkelijk mijn eigen 'functionaliteiten' op mijn 'server' kunnen koppelen zodat mijn 'klanten' ook via de applicatie zijn rit/traject kan kopen en betalen.
BC8.2
Business capability
Als 'Speler' moet ik mijn klanten ook via mijn eigen applicaties de 'bugetten'/'kredieten' ook kunnen gebruiken om zijn rit/traject te kunnen betalen
BC8.3
Business capability
Als 'Speler' wil ik dat mijn klanten via mijn applicatie toegang kunnen krijgen naar de saldo (en historiek) van mijn 'Moburger' rekening
ID
Type
Samenvatting
Beschrijving
UC9
Use case
UC9
Een platform die ook voor deelmobiliteit's aanbieders toegang te geven en te integreren
BC9.1
Business capability
aanbod deelmob
Als 'aanbod' gebruiker wil ik mijn traject kunnen invoeren (van tot wanneer hoeveel plaatsen, volume bagage, taal, ed meer
BC9.2
Business capability
vraag deelmob
Als 'vraag' gebruiker wil ik de 'aanbod' gewoon geintegreerd zien in het voorstel kader binnen de applicatie
BC9.3
Business capability
overzicht deelmob
Als beheerder en beleid wil ik een overzicht zien van vraag en aanbod met feedback en reviews
BC9.4
Business capability
reviews deelmob
Als beheerder en beleid wil ik een overzicht zien van vraag en aanbod met feedback en reviews
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.1 Regionaal plugable incentiveringsplatform – Geel VLOCA-Model V0.1 VLOCA-model V1.0 Regionaal plugable incentiveringsplatform – Geel VLOCA-Model V1.0 VLOCA-model V1.8 Regionaal plugable incentiveringsplatform – Geel VLOCA-Model Co-creatie
Inhoud
Hieronder kan je de elementen van versie V0.1 van dit VLOCA model bekijken.
CoT Regionaal plugable incentiveringsplatform – Geel
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 ?
Steden hebben het moeilijk om het gedrag van de burgers te veranderen zonder incentivering. Uit vorige projecten blijkt dat 'vouchers' en 'lokale (digitale) munten' (sociale krediet zoals duimpjes up) daarvoor goed werken. Maar die worden ook te snel verzilverd in euro's en blijven niet binnen het systeem. Ze steunen ook niet noodzakelijk de lokale economie daar die euro's (in de vorm van de voucher of lokale munt) ook buiten de regio kunnen uitgegeven worden. Daarnaast leiden verschillende incentiveringen ook tot eigen vouchers of (digitale) munten hetgeen resulteert in een versnipperd landschap van systemen.
Missie
Voorstel
Wat willen we bereiken ?
Een oplossing die zowel het duurzaam gedrag van de burger wil beïnvloeden door beloning als de lokale economie wil ondersteunen via één systeem.
Doel
Voorstel
Wat is het doel van dit project ?
Een platform die 'goed gedrag' beloont met een 'lokale munt' die enkel in de regio kan ingeruild/gespendeerd worden = 'regio breed incentiveringsplatform' die ook dmv een 'schaalbaar' architectuur snel en efficiënt uitrolbaar is in andere regio's die dat zouden wensen. De Lokale/digitale munt moet ook kunnen dienen als 'betaalmiddel' tussen B2B of C2C om die munt zo lang mogelijk binnen de regio en binnen het systeem te houden.
Succesfactor
Voorstel
Hoe meten we succes ? (SMART)
Een schaalbaar regiobreed incentiveringsplatform met een 'slimme' configuratie die volledig parametriseerbaar is tegen 2025.
Use cases
ID
Status
Samenvatting
Beschrijving
UC1
Voorstel
UC1: Digitale Wallet
Digitale wallet waar zowel stortingen, uitgaven/overschrijven en consulteren van saldo's door de eigenaar en participanten.
UC2
Voorstel
UC2: Integratie
Integratie met bestaande applicaties zoals de stadsapplicaties, websites en zelfs mijnburgerprofiel
UC3
Voorstel
UC3: Participatiemechanisme
Een gebruiksvriendelijke platform om zowel als 'donor' als 'ontvanger' als 'gebruiker' zichzelf kunnen registreren en 'regels'/'parameters' voor ontvangen en gebruiken kunnen vastgelegd worden.
UC4
Voorstel
UC4: Marketing
Aanradingsprogramma om de lokale economie aan te trekken om mee te doen zowel als 'donor' (participerende organisatie die een goed gedrag willen belonen) alsook als 'ontvanger' (=winkels die deze munt aanvaarden als betaling)
UC5
Voorstel
UC5: Omzettingsmechanisme
Een facturatiesysteem die de eerste en allerlaatste conversie regelt, zodat de lokale munt in praktijk omgezet kunnen worden in euros.
UC6
Voorstel
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.
UC7
Voorstel
UC7: Principes
Schaalbaarheid (voor extra steden en regio's) en interoperabiliteit (voor extra toepassingen) van het platform is cruciaal
UC8
Voorstel
UC8: Draaiboeken
Een bibliotheek leveren van draaiboeken die de steden en gemeenten een 'how to' uitleggen ifv hun behoeften en context
UC9
Voorstel
UC9: Compensatiemogelijkheden ("governance model")
Om een evenwichtig systeem te hebben, moeten er regels geïmplementeerd kunnen worden die de solidariteit m.b.t. investeringen in incentives en het steunen van de lokale economie tussen o.a. de deelnemende gemeenten/steden kunnen bevorderen
UC10
Voorstel
UC10: Integratiemogelijkheden
Alle (bestaande) initiatieven (buck-e munten met tag-registratie bvb) met automatismen/digitalisering hebben de voorkeur
Metadata
Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases
ID
Type
Samenvatting
Beschrijving
UC1
Use case
UC1: Digitale Wallet
Digitale wallet waar zowel stortingen, uitgaven/overschrijven en consulteren van saldo's door de eigenaar en participanten.
BC1.1
Business capability
Donor
Digitale munt kunnen storten / ter beschikking stellen van een incentive
BC1.2
Business capability
Ontvanger
Digitale munt kunnen uitgeven binnen een (handels)transactie
BC1.3
Business capability
Gebruiker
Saldo van de digitale munt rekening consulteerbaar in real time
ID
Type
Samenvatting
Beschrijving
UC2
Use case
UC2: Integratie
Integratie met bestaande applicaties zoals de stads applicaties, websites en zelfs mijnburgerprofiel
BC2.1
Business capability
Lokale Overheid
Kunnen 'vertalen' van de interne standaarden naar de 'standaarden' van de externe participerende applicaties
ID
Type
Samenvatting
Beschrijving
UC3
Use case
UC3: Participatiemechanisme
Een gebruiksvriendelijke platform om zowel als 'donor' als 'ontvanger' als 'gebruiker' zichzelf kunnen registreren en 'regels'/'parameters' voor ontvangen en gebruiken kunnen vastgelegd worden.
BC3.1
Business capability
Lokale overheid + donor
Registratiemogelijkheden voor participerende 'donors'
BC3.2
Business capability
Lokale overheid + ontvanger
Registratiemogelijkheden voor participerende 'handelaars'/'ontvangers'
BC3.3
Business capability
Lokale overheid + gebruiker
Registratiemogelijkheden voor participerende 'burgers' of 'organisaties'
BC3.4
Business capability
Lokale overheid + gebruiker
Registratiemogelijkheden voor participerende 'burgers' of 'organisaties' aan specifieke 'acties'
BC3.5
Business capability
Lokale overheid + donor
Een hierarchie van 'rechten' om regels te kunnen 'hierarchiseren' ten behoeve van de gebruiksvriendelijkheid van de burger/gebruiker
BC3.6
Business capability
Lokale overheid + donor
Creeren van regels die de toekenning alsook uitgave van de munten bepaalt
ID
Type
Samenvatting
Beschrijving
UC4
Use case
UC4: Marketing
Aanradingsprogramma om de lokale economie aan te trekken om mee te doen zowel als 'donor' (participerende organisatie die een goed gedrag willen belonen) alsook als 'ontvanger' (=winkels die deze munt aanvaarden als betaling)
BC4.1
Business capability
Lokale Overheid+Donor+Ontvanger+gebruiker
Identificatie van de doelgroepen (donors, handelaars/ontvangers en burgers/organisaties)
ID
Type
Samenvatting
Beschrijving
UC5
Use case
UC5: Omzettingsmechanisme
Een facturatie systeem die de eerste en allerlaatste conversie regelt, zodat de lokale munt in praktijk omgezet kunnen worden in euros.
BC5.1
Business capability
Lokale Overheid+Donor
betalingsmogelijkheden (met facturatie referentie)
BC5.2
Business capability
Lokale Overheid+Ontvanger
ontvangstmogelijkheden (met facturatie referentie)
BC5.3
Business capability
Lokale Overheid+NBB
voldoen aan de e-money licentie voorwaarden (Nationale Bank van Belgie)
ID
Type
Samenvatting
Beschrijving
UC6
Use case
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.
BC6.1
Business capability
Lokale Overheid
Campagne Resultaten Meten om de doelgroepen beter te kennen
BC6.2
Business capability
Lokale Overheid
Beleidsdoelstellingen formuleren en meten als KPI om een actie of verschillende acties samen te evalueren
BC6.3
Business capability
Lokale Overheid
Alle betalingen/transacties per actie (gedrag) en per doelgroep kunnen analyseren en visualiseren
BC6.4
Business capability
Lokale Overheid
Alle transacties die binnen de regio werden gespendeerd kunnen analyseren en visualiseren
ID
Type
Samenvatting
Beschrijving
UC7
Use case
UC7: Principes
Schaalbaarheid (voor extra steden en regio's) en interoperabiliteit (voor extra toepassingen) van het platform is cruciaal
BC7.1
Business capability
Platform Beheer+Lokale Overheid
Toevoegen van een lokale overheid tot het incentiveringsplatform
ID
Type
Samenvatting
Beschrijving
UC8
Use case
UC8: Draaiboeken
Een bibliotheek leveren van draaiboeken die de steden en gemeenten een 'how to' uitleggen ifv hun behoeften en context
BC8.1
Business capability
VLOCA
Beheren van versies van draaiboeken, bestekteksten, enz. voor opstartende lokale overheden
ID
Type
Samenvatting
Beschrijving
UC9
Use case
UC9: Compensatiemogelijkheden ("governance model")
Om een evenwichtig systeem te hebben, moeten er regels geïmplementeerd kunnen worden die de solidariteit m.b.t. investeringen in incentives en het steunen van de lokale economie tussen o.a. de deelnemende gemeenten/steden kunnen bevorderen
ID
Type
Samenvatting
Beschrijving
UC10
Use case
UC10: Integratiemogelijkheden
Alle (bestaande) initiatieven (buck-e munten met tag-registratie bvb) met automatismen/digitalisering hebben de voorkeur
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.2 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.2-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is.
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.2 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.1 Slimme stadsdistributie – Hasselt VLOCA-Model V0.1 VLOCA-model V0.2 Slimme stadsdistributie – Hasselt VLOCA-Model V0.2
Inhoud
Hieronder kan je de elementen van versie V0.2 van dit VLOCA model bekijken.
Level2
Level3
CoT Slimme stadsdistributie – Hasselt
2022
VLOCA-model versie 0.2
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 ?
Stadsdistributie in de vorm van vrachtverkeer in de stadskern wordt alsmaar belangrijker en genereert een paradox mbt het autoluw maken van de binnenstad. Dit resulteert in alsmaar meer problemen zonder enige vorm van sturing.
Missie
Voorstel
Wat willen we bereiken ?
Het verkeer in de binnenstad aangenamer maken door het vrachtverkeer te minimaliseren door betere planning ifv verkeer (huidig of ingeschatte) alsook het verminderen van 'onnodige' transporten (beschikbare lege volume, lege terugkeer, ed meer)
Doel
Voorstel
Wat is het doel van dit project ?
(1) Een 'cockpit' bouwen die het vrachtverkeer volledig weergeeft om inzichten te verschaffen mbt beleidsvorming, sturing en evaluatie (2) Een 'dashboard' voor de 'vervoerder' om zijn transport te registreren en 'toestemming' te krijgen met een voorgestelde routeadvies (routeplanner?) (3) Het dashboard moet ook de mogelijkheid geven om aan de vervoerder een optimale planning te kunnen doen door op basis van de andere registraties, wegenwerken, ed meer. (4) Ontsluiten van alle mogelijke data/'business rules' (via APIs bvb) naar commerciele 'logistieke planningstools' om die data te integreren, of nieuwe VAS toe te laten. (5) Matchmaking van vraag en aanbod aan te bieden (6) Het beleid af te dwingen via IOT toepassingen (incl ANPR, verzinkbare paaltjes bvb)
Succesfactor
Voorstel
Hoe meten we succes ? (SMART)
Tegen 2024 moet Hasselt een cockpit hebben die de toegang van vrachtverkeer reguleert en visualiseert waarbij alle data de OSLO standaarden respecteert.
Use cases
ID
Status
Samenvatting
Beschrijving
UC1
Voorstel
UC1: Registratie Bedrijf
Aanmaken van een nieuwe registratie als organisatie/onderneming om vanaf nu via login/paswoord alle gegevens niet meer opnieuw te moeten invoeren, alsook de kentekens, vrachtwagens en chauffeurs te kunnen registreren en linken aan mijn organisatie.
UC2
Voorstel
UC2: Aanvraag Levering
Een visuele applicatie (='Dashboard') waar de vervoerder een reservatie/registratie, om de binnenstad binnen te rijden, kan aanvragen en ifv het flankerend beleid al dan niet toestemming krijgt om de gevraagde route te kunnen gebruiken. Alternatieve 'routes' (welke wagen, tijdstip, geografische route, enz) worden ook voorgesteld.
UC3
Voorstel
UC3: Beleids Cockpit uitvoering
Het flankerend beleid moet kunnen ingevoerd worden in de 'cockpit' zodat elke aanvraag (= registratie) ifv de gevraagde routes, maar ook de type wagen, ed meer de toegestane routes kan beslist en gevisualiseerd worden via een algoritme die een 'nudging' mogelijk maakt om bvb naar een levering te streven die conform het beleid is en/of geoptimaliseerd kan worden.
UC4
Voorstel
UC4: Toegang Binnenstad
De binnenstad kan toegankelijk gemaakt worden (via paaltjes of via een ANPR camera) voor degenen die een registratie conform het beleid hebben gedaan van de levering.
UC5
Voorstel
UC5: Monitoring Dashboard
De steden krijgen een 'monitoring dashboard' die het volledige vrachtverkeer (registraties, sensoren, camera's data, ANPR, Toegangscontrole,...) grafisch en in cijfers weergeeft om zo een beter beleid te kunnen vormen, evalueren, simuleren en aanpassen.
UC6
Voorstel
UC6: Reservatie domeinen
De vervoerder/handelaar/leverancier moet een laad- en losplaats kunnen 'reserveren' , gelinkt met bestaande software die reeds eventueel bestaat, om zeker te zijn dat de levering zo optimaal zou kunnen verlopen. (Betaling ? : misschien ifv EURO normen van de (vracht)wagen)
UC7
Voorstel
UC7: Matchmaking
Door alle verzamelde data, , zoals beladingsgraad, afmetingen, drops, enz.,alsook de 'registratie' aanvragen, kan de 'waste' in de transport worden weggewerkt door de 'lege'/'beschikbare' volumes te benutten door andere vervoerders, handelaars en leveranciers.
UC8
Voorstel
UC8: Open Data
Alle data die uiteindelijk gecapteerd worden moet kunnen opengesteld worden om zo de ganse quadruple helix de mogelijkheid te bieden om 'Value Added Services' te kunnen bouwen op die data.
UC9
Voorstel
UC9 : CRM Database
Alle contact gegevens om de gebruikers van de tool te kunnen contacteren met 'informatie' of 'customized' berichten met alle optin en optouts alsook 'voorkeuren' van informatie.
UC10
Voorstel
UC10 : Helpdesk
Een helpdesk (live, FAQ, chatbot,...)
Metadata
Metaveld
Beschrijving
Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases
ID
Type
Samenvatting
Beschrijving
UC1
Use case
UC1: Registratie Bedrijf
Aanmaken van een nieuwe registratie als organisatie/onderneming om vanaf nu via login/paswoord alle gegevens niet meer opnieuw te moeten invoeren, alsook de kentekens, vrachtwagens en chauffeurs te kunnen registreren en linken aan mijn organisatie.
BC1.1
Business capability
Registratie
Als transporteur wil ik mij gemakkelijk kunnen Inloggen en authenticeren om 'kentekens' of 'badges' te kunnen 'aanmaken' voor de eerste keer met bijbehorende vragen (type van wagen, ed meer) Dit zal maar één keer moeten gebeuren, bij de volgende inlogging blijven 'by default' alle data dezelfde. Aanpassingen moeten mogelijk zijn.
BC1.2
Business capability
Individu vs organisatie
Als transporteur wil ik mijzelf als individu kunnen inloggen en de organisaties creeren waarmee ik een link heb die ook gemachtigd is aan mijn persoon.
BC1.3
Business capability
autofill bedrijf
Als transport bedrijf wil ik bij het invoeren van mijn bedrijfsgegevens alle andere gegevens die in de centrale databanken bestaan automatisch worden ingevuld en voor validatie beschikbaar gesteld worden.
BC1.4
Business capability
autofill DIV
Als transporteur wil ik bij registratie na het invullen van mijn kenteken de nodige informatie automatisch wordt opgeladen en voorgesteld ter validatie.
BC1.5
Business capability
uniform regionaal/federaal
Als transporteur wil ik dat alle steden in Vlaanderen (en verder) dezelfde systeem gebruiken zodat ik niet telkens moet registreren en inloggen.
BC1.6
Business capability
Lastminute of Niet geinformeerde transporteurs
Als tansporteur wil ik toch de kans krijgen om binnen te rijden indien ik bvb niet wist en ik sta voor de verzinkbare paaltje, dat ik via een 'nood procedure' die paaltje toch naar beneden krijg.
BC1.7
Business capability
Noodprocedure
Als hulpdienst (internationaal) ed snel toegang moet kunnen krijgen in de binnenstad
BC1.8
Business capability
Internationaal
Als transporteur van het buitenland wil ik ook in bvb het engels de registratie en aanvragen kunnen doen.
BC1.9
Business capability
Overzicht beleidsvoering
Als transporteur wil ik een overzicht van alle zones met toegangsbeperkingen in een open data platform zodat die data kan opgeladen/gelinkt worden met de in house planningstool van het bedrijf.
BC1.10
Business capability
Overzicht beleidsvoering
Als transporteur wil ik mijn leveringsvoorkeuren kunnen ingeven bij de eerste en volgende registraties
ID
Type
Samenvatting
Beschrijving
UC2
Use case
UC2: Aanvraag Levering
Een visuele applicatie (='Dashboard') waar de vervoerder een reservatie/registratie, om de binnenstad binnen te rijden, kan aanvragen en ifv het flankerend beleid al dan niet toestemming krijgt om de gevraagde route te kunnen gebruiken. Alternatieve 'routes' (welke wagen, tijdstip, geografische route, enz) worden ook voorgesteld.
BC2.1
Business capability
Registratie levering
Als transporteur wil ik kunnen 'Registreren'/Invoeren van gewenste leverings of afhalingstermijn aan een adres.
BC2.2
Business capability
Voorstel validatie
Als transporteur wil ik een voorstel van (alternatieve) routes, wanneer en via welke route, die toegelaten zouden zijn en die ik kan valideren met een muisklik in de tool. Bij conforme maar suboptimale leveringen dient er een aanbeveling te komen naar een optimale belevering.
BC2.3
Business capability
dossier beheer
Aanvragen moet kunnen aangepast of zelfs geannuleerd door de vervoerder, met een visuele/grafische algemene overzicht van alle aanvragen per kenteken/badge
BC2.4
Business capability
rapportering
Opvolging van 'uitvoering/gebruik' van de aanvragen (om misbruiken tegen te gaan door bepaalde 'badge'/'kentekens',mogelijks gekoppeld aan het leveranciers'register', te blokkeren) alsook handhaving van ongeoorloofde leveringen (om te beboeten)
BC2.5
Business capability
handelaars
Als handelaar wil ik toegang tot het systeem om zeker te zijn dat iemand aanwezig zal tijdens de levering
BC2.6
Business capability
Bewoners
Als bewoner wil ik input kunnen geven die eventueel de planning kan beinvloeden
BC2.7
Business capability
non grata
Als beleid wil ik bepaalde bedrijven en kentekens 'bestraffen' om (tijdelijk) niet in de binnenstad toe te laten (nadat er ongeoorloofde handelingen werden vastgesteld)
BC2.8
Business capability
inloggen met 'kenteken', 'chauffeur' of 'bedrijf'
Als transporteur moet ik snel via mijn bedrijfs login alle reeds geregistreerde kentekens (met alias namen) kunnen aanvinken voor de huidige aanvraag. Ofwel, via direct 'kenteken' in te vullen.
BC2.9
Business capability
rapportering
Als transporteur wil ik een overzicht hebben van alle aanvragen (dossiers) per type, per kenteken, per ...
BC2.10
Business capability
Overzicht beleidsvoering
Als transporteur wil ik een overzicht van alle zones met toegangsbeperkingen in een open data platform zodat die data kan opgeladen/gelinkt worden met de in house planningstool van het bedrijf.
BC2.11
Business capability
Lastminute of Niet geinformeerde transporteurs
Als tansporteur wil ik toch de kans krijgen om binnen te rijden indien ik bvb niet wist en ik sta voor de verzinkbare paaltje, dat ik via een 'nood procedure' die paaltje toch naar beneden krijg.
BC2.12
Business capability
efficientie winst
Als transporteur wil ik (door derde partij bvb) kunnen zien hoeveel 'winst' (in tijd, in euros, in uitstoot,enz) ik heb gemaakt dankzij dit initiatief.
BC2.13
Business capability
beveiliging data
Als transporteur wil ik dat mijn concurrenten niet kunnen zien bij wie ik geleverd of zal leveren.
BC2.14
Business capability
Internationaal
Als transporteur van het buitenland wil ik ook in bvb het engels de registratie en aanvragen kunnen doen.
BC2.15
Business capability
afdwingen via handelaars
Als handelaar wil ik de transporteur kunnen 'dwingen' om gebruik te maken van de matchmaking procedure om mijn levering of afhaling te behandelen
BC2.16
Business capability
Noodprocedure
Als hulpdienst (internationaal) ed snel toegang moet kunnen krijgen tot de binnenstad
ID
Type
Samenvatting
Beschrijving
UC3
Use case
UC3: Beleids Cockpit uitvoering
Het flankerend beleid moet kunnen ingevoerd worden in de 'cockpit' zodat elke aanvraag (= registratie) ifv de gevraagde routes, maar ook de type wagen, ed meer de toegestane routes kan beslist en gevisualiseerd worden via een algoritme die een 'nudging' mogelijk maakt om bvb naar een levering te streven die conform het beleid is en/of geoptimaliseerd kan worden.
BC3.1
Business capability
Beslissingsboom
Als beleid en medewerker wil ik een gekozen (zie BC2.2) beslissingsboom die bepaalt wie waar al dan niet mag binnenrijden, kunnen invoeren, zodat er 'automatisch' de actuatoren aangestuurd worden, alsook de handhaving via GAS of andere boetes quasi automatisch kan uitgevoerd worden.
BC3.2
Business capability
Versionering
Als beleid en medewerker wil ik de beslissingsboom kunnen 'versioneren', zodat er een historiek kan zijn van de gebruikte parameters die evt geleid hebben tot een zekere verkeersdrukte in de binnenstad in het verleden.
BC3.3
Business capability
Visualisatie
Als beleid wil ik de beslissingsboom visueel kunnen voorstellen zodat de aanvrager het voorstel van de tool beter kan begrijpen en in de toekomst zijn logistieke aanvraag beter kan afstemmen om de kansen tot aanvaarding te verhogen.
BC3.4
Business capability
Parametrisatie
Als beleid wil ik de parameters kunnen aanpassen die de 'rigiditeit' van de toekenning en voorstel zullen beinvloeden
BC3.5
Business capability
Schoolstraten
Als beleid wil ik bepaalde routes bvb kunnen ontlast worden van vrachtverkeer tijdens de start en einde van de lessen.
BC3.6
Business capability
Evenementen (markten,...)
Als beleid wil ik bepaalde tijdelijke evenementen kunnen invoeren waar ik bvb het vrachtverkeer kan mijden
BC3.7
Business capability
A postiori Registratie
Als beleid wil ik eventueel de 'binnentreder' de kans laten om binnen 24 uur (met parameter voor rigiditeit te kunnen aanpassen) de registratie te doen om de boete te vermijden.
BC3.8
Business capability
Alignering bestaande vergunningen One stop shopping
Als beleid wil ik de bestaande vergunningen (bvb de inwoners van de binnenstad, zorgverleners, lijkwagen,...) aligneren met de business rules.
BC3.9
Business capability
Incentive
Als beleid wil ik goed gedrag kunnen belonen door bvb efficientiewinst aan te bieden door bvb reservatie laad- en losplaats.
BC3.10
Business capability
First time sinners
Als beleid wil ik de transporteurs de mogelijkheid bieden om zich a posteriori te kunnen registreren
ID
Type
Samenvatting
Beschrijving
UC4
Use case
UC4: Toegang Binnenstad
De binnenstad kan toegankelijk gemaakt worden (via paaltjes of via een ANPR camera) voor degenen die een registratie conform het beleid hebben gedaan van de levering.
BC4.1
Business capability
Actuator systeem
Als beleid wil ik een fysieke toegangen gelinkt aan de databank waarin de toestemmingen opgeslagen zijn in real time kunnen 'actueren' (zinken van palen, ANPR camera's aansturen,...)
BC4.2
Business capability
politie, brandweer en ambulances
Als medewerker wil ik de hulpdiensten onbelemmerd de binnenstad kunnen laten in en uitrijden
BC4.3
Business capability
Boetesysteem
Als beleid wil ik via ANPR camera's boetes kunnen opmaken bij het niet toegestane binnenrijden van de binnenstad.
BC4.4
Business capability
Privileges
Als medewerker wil ik bepaalde privileges kunnen toekennen worden aan bepaalde groepen zoals de eigenlijke bewoners die een mini vrachtwagen (bvb gehandicapten die een minivan nodig hebben) gebruiken om zich te verplaatsen
BC4.5
Business capability
Boete Motivatie
Als medewerker wil ik in de boete de exacte motivatie kunnen meegeven die van de 'beslissingsboom' moet komen
ID
Type
Samenvatting
Beschrijving
UC5
Use case
UC5: Monitoring Dashboard
De steden krijgen een 'monitoring dashboard' die het volledige vrachtverkeer (registraties, sensoren, camera's data, ANPR, Toegangscontrole,...) grafisch en in cijfers weergeeft om zo een beter beleid te kunnen vormen, evalueren, simuleren en aanpassen.
BC5.1
Business capability
rapportering
Als beleid wil ik alle 'registraties', 'aanvragen' en 'uitvoering' kunnen visualiseren samen met andere 'stadsdrukte' metingen van gemotorizeerde vervoer.
BC5.2
Business capability
Lineaire programmatie
Als beleid wil ik een simulatie kunnen doen om de beleidsbeslissings parameters te callibreren (hoe streng moeten we zijn) om het verkeer zo minimaal te maken alsook de aanvragen zo maximaal te beantwoorden
BC5.3
Business capability
Actuatie
Als beleid wil ik de IoT actuatoren (?) kunnen 'conditioneel' activeren om vervoerders al dan niet in de binnenstad of in een straat binnenlaten doordat bvb de paaltjes al dan niet in de grond zinken, of de hefbomen open gaan, of de ANPR camera de niet toegestande vervoerder capteert en beboet. Al dan niet binnenlaten moet via dashboard al gecommuniceerd worden. Als iemand bv. op een ander moment komt in tegenspraak met zijn registratie moet IoT dit tegengaan.
BC5.4
Business capability
lading vs capaciteit
Als beleid wil ik weten hoeveel 'lege' vrachtwagens de binnenstad binnenrijden en/of uitrijden
BC5.5
Business capability
kosten baten analyse
Als beleid wil ik kunnen meten hoeveel de 'kosten' (tijd nodig om aanvraag van begin tot einde, kosten om systeem te managen,enz.) zijn van het systeem tov de baten (luchtkwaliteit, drukte meting, enz.)
ID
Type
Samenvatting
Beschrijving
UC6
Use case
UC6: Reservatie domeinen
De vervoerder/handelaar/leverancier moet een laad- en losplaats kunnen 'reserveren' , gelinkt met bestaande software die reeds eventueel bestaat, om zeker te zijn dat de levering zo optimaal zou kunnen verlopen. (Betaling ? : misschien ifv EURO normen van de (vracht)wagen)
BC6.1
Business capability
Booking.com toepassing
Als transporteur en handelaar ed wil ik een visueel overzicht krijgen van de beschikbare tijdslot per laad- en losplaats, en reserveren mogelijk te moeten maken met een muisklik in de tool.
BC6.2
Business capability
Dossier Overzicht
Als aanvrager wil ik een overzicht krijgen van de aanvragen met de huidige status (aanvaard, pending, geweigerd,...)
BC6.3
Business capability
Dossier updaten
Als aanvrager wil ik mijn aanvragen kunnen aanpassen en eventueel annuleren van aangevraagde reservering, enz.
BC6.4
Business capability
Dossier betalen
Als aanvrager wil ik voor mijn aanvragen een betaling kunnen uitvoeren online of offline (overschrijving,...)
BC6.5
Business capability
Total aanvragen met status
Als beleid, medewerker en 'actor' wil ik een overzicht zien van alle aanvragen van reservaties (en uitvoering van die reservaties)
ID
Type
Samenvatting
Beschrijving
UC7
Use case
UC7: Matchmaking
Door alle verzamelde data, , zoals beladingsgraad, afmetingen, drops, enz.,alsook de 'registratie' aanvragen, kan de 'waste' in de transport worden weggewerkt door de 'lege'/'beschikbare' volumes te benutten door andere vervoerders, handelaars en leveranciers.
BC7.1
Business capability
Overzicht
Door de vervoerders/handelaars/leveranciers in kaart te brengen alsook de gedeclareerde 'lege' volume in de vrachtwagen kan een matchmaking voorgesteld worden waarbij er maximaal volume met een minimum aan verplaatsing zou kunnen uitgevoerd worden.
BC7.2
Business capability
Vraag
Als aanvrager wil ik de mogelijkheid hebben om aan te vragen welke vervoerder/handelaar/leverancier zou van adres A tot adres B tijdens periode X een vracht met volume Y en dimensie Z kunnen mee vervoeren.
BC7.3
Business capability
Aanbod
Als vervoerder wil ik mezelf kunnen aanbieden om een 'lege' volume voor te stellen om door een handelaar/andere vervoerder/leverancier te kunnen benutten bij mijn in of uitgang van de binnenstad
BC7.4
Business capability
Cargo-hitching
Als handelaar wil ik ook gebruik kunnen maken van het openbaar vervoer (bussen, tram en trein) om goederen mee in en uit de binnenstad te vervoeren
BC7.5
Business capability
speciale drop plaatsen binnen de stad/consolidatie hub buiten de stad
goed verspreide 'pickup'/'drop' PUDO plaatsen waar de handelaars hun goederen kunnen halen of droppen, en die (meermaals) dagelijks worden opgehaald en buiten de binnenstad wordt ge'dispatched' van/naar de verschillende transportbedrijven om te vermijden dat ze de binnenstad moeten inrijden.
BC7.6
Business capability
marktaandelen
Als beleid zou een overzicht van marktaandeel per regio en sector (kledij, horeca, retail, enz.) interessant kunnen zijn
BC7.7
Business capability
Optimalisatie
Als handelaar kan ik door de 'hitching' van lege ruimte een prijs optimalisatie verkrijgen ("ik moet toch uit te binnenstad, dus drop hem maar",...), of CO2 reductie, tijdsefficientie,...
BC7.8
Business capability
Matchmaking
Als beleid wil ik de matchmaking managen met evt facturatie, betalingen, ed meer. Of tenminste een 'acceptatie' knopje.
BC7.9
Business capability
SLA
Als transporteur wil ik een SLA kunnen opstellen en bekijken en een voorkeur van participerende partners kan invoeren (bvb categorien DHL met UPS, kleintjes onderling,...)
BC7.10
Business capability
Reviews
Als transporteur wil ik een 'eerlijke' feedback geven over de geleverde dienst van de 'pick up' van de gekozen partner.
BC7.11
Business capability
Real Time
Als beleid wil ik bij de eigenlijke aanvraag om stad binnen te mogen, een alternatief voor te stellen door matchmaking
BC7.10
Business capability
Acquisitie Registraties
Als beleid wil ik de transporteurs die geen beroep doen op matchmaking, via een analyse van zijn historische transporten een simulatie kunnen voorstelling : stel je had meegedaan, dan had je zoveel efficientie kunnen halen.
BC7.12
Business capability
Incentives
Als beleid wil ik de transporteurs die beroep doen op matchmaking belonen
BC7.12
Business capability
Transparantie Controle
Als transporteur wil ik mijn informatie/data zelf kunnen beslissen hoe die gedeeld wordt met de andere transporteurs
BC7.12
Business capability
Motivatie vanuit handelaars
Als handelaar wil ik kunnen quasi opleggen dat mijn leverancier transporteur meedoet aan matchmaking.
ID
Type
Samenvatting
Beschrijving
UC8
Use case
UC8: Open Data
Alle data die uiteindelijk gecapteerd worden moet kunnen opengesteld worden om zo de ganse quadruple helix de mogelijkheid te bieden om 'Value Added Services' te kunnen bouwen op die data.
BC8.1
Business capability
OSLO-VLOCA
Alle data die opengesteld zullen worden moeten de OSLO standaarden alsook de VLOCA charter voldoen, zodat er andere spelers op de markt die data kunnen gebruiken om toegevoegde waarde applicaties te kunnen bouwen.
BC8.2
Business capability
Open Data Platform
Open data moet via centrale datavindplaats kunnen gevonden worden en toegang gegeven worden.
BC8.3
Business capability
routes met beperkingen
alle routes met beperkingen moeten opengesteld worden en telkens up to date blijven om zo gebruikt te kunnen worden door andere planningstools
ID
Type
Samenvatting
Beschrijving
UC9
Use case
UC9 : CRM Database
Alle contact gegevens om de gebruikers van de tool te kunnen contacteren met 'informatie' of 'customized' berichten met alle optin en optouts alsook 'voorkeuren' van informatie.
BC9.1
Business capability
Contact info
Als beleid wil ik de email, gsm, adressen, ed kunnen verzamelen om te beslissen welke te gebruiken bij welke type van communicatie
BC9.2
Business capability
Opt in Opt out
Als gebruiker wil ik mijn opt in en opt out kunnen beheren wanneer ik wil, alsook mijn voorkeur kunnen geven in de onderwerpen alsook manier waarop ik informatie krijg
BC9.3
Business capability
GDPR
Als beleid wil ik kunnen garanderen dat ik de data behandel volgens de GDPR regels in voege
BC9.4
Business capability
Historiek
Als beleid wil ik kunnen bijhouden welke communicatie gestuurd werd naar welke gebruiker
BC9.5
Business capability
Automatische Bevestiging
Als gebruiker wil ik een berichtje krijgen dat mijn aanvraag is bevesitigd en aanvaard
BC9.6
Business capability
Weigering van aanvraag
Als gebruiker wil ik een berichtje krijgen dat mijn aanvraag is geweigerd
BC9.7
Business capability
Advies of suggesties binnen aanvraag
Als gebruiker wil ik advies krijgen of suggesties mbt mijn aanvraag (om de aanvraag meer kans te geven om aanvaard te worden bvb)
BC9.8
Business capability
Leveranciers via handelaars
Als handelaar wil ik mijn leveranciers kunnen oplijsten opdat die evt kunnen meedoen met 'matchmaking'
BC9.9
Business capability
Acquisitie Gebruikers
Als beleid wil ik een lijst van potentiele transporteurs kunnen 'verkrijgen' om op te laden en nadien te contacteren met vraag om mee te doen met bvb matchmaking initiatief
ID
Type
Samenvatting
Beschrijving
UC10
Use case
UC10 : Helpdesk
Een helpdesk (live, FAQ, chatbot,...)
BC10.1
Business capability
Specifieke Problemen
Als transporteur wil ik een instantie kunnen contacteren bij issues die zich voordoen
BC10.2
Business capability
Inzichten
Als beleid wil ik weten waarvoor bellen/contacteren de mensen : historiek en trends
BC10.3
Business capability
Indicatoren van issues
Als medewerker wil ik weten of de tool een 'downtime' heeft zodat ik gericht kan communiceren bij problemen
BC10.4
Business capability
Proactieve Communicatie
Als gebruiker wil ik op de hoogte gesteld worden dat de systemen 'down' zijn, of gepland worden stil te vallen voor bvb onderhoud
BC10.5
Business capability
FAQ
Als medewerker wil ik de FAQ kunnen invoeren op de website en applicatie
Inleiding
Deze pagina bevat de eerste versie van het VLOCA model. Het is een finale versie die we 1.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 1.0-vorm nog geen finaal en afgewerkt document; we baseren ons voor de opmaak ervan op informatie en inzicht die in deze fase van het traject bekend is.
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 v1.0 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 1.0 van dit VLOCA model bekijken.
Level2
Level3
CoT Regionaal plugable incentiveringsplatform Geel
2022
VLOCA-model versie 1.0
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 ?
Steden hebben het moeilijk om het gedrag van de burgers te veranderen zonder incentivering. Uit vorige projecten blijkt dat 'vouchers' en 'lokale (digitale) munten' (sociale krediet zoals duimpjes up) daarvoor goed werken. Maar die worden ook te snel verzilverd in euro's en blijven niet binnen het systeem. Daarnaast leiden verschillende incentiveringen ook tot eigen vouchers of (digitale) munten hetgeen resulteert in een versnipperd landschap van systemen. De keuze om al de lokale economie te steunen dan wel expliciet te kiezen voor een digitale munt die regionaal besteed kan worden (= aantrekkelijker voor de burger) moet bij de initiatiefnemer (lees: lokaal bestuur) liggen: waar steun aan lokale economie belangrijkste finaliteit is, moet er gekozen kunnen worden voor een lokale munt. Wanneer een incentivering op een bepaalde maatschappelijk wenselijk gedrag ligt, is een regionale campagne die toeleidt tot een regionale munt vaak interessanter. -Lokale besturen wensen ook aan de bestedingszijde meer te kunnen richten naar doelen, projecten... met een maatschappelijke meerwaarde.
Missie
Voorstel
Wat willen we bereiken ?
Een oplossing die zowel het duurzaam gedrag van de burger wil beinvloeden door beloning alsook (of) de lokale economie of lokale organisaties wil ondersteunen.
Doel
Voorstel
Wat is het doel van dit project ?
Een platform die eigenlijk 'goed gedrag' beloont met een 'lokale munt' die enkel in de regio kan ingeruild/gespendeerd worden = 'regio breed incentiveringsplatform' die ook dmv een 'schaalbaar' architectuur snel en efficient uitrolbaar is in andere regio die dat zouden wensen. De Lokale/digitale munt moet ook kunnen dienen als 'betaalmiddel' tussen B2B om die munt zo lang mogelijk binnen de regio te houden. Het eigenlijke 'beloning' van goed gedrag zal niet in het platform zelf gebeuren, maar via de 'verticals', dus de applicaties die allemaal dit platform zullen gebruiken voor de transacties bij te houden en uitgaven te kunnen doen.
Succesfactor
Voorstel
Hoe meten we succes ? (SMART)
Een schaalbaar regiobreed incentiveringsplatform met een 'slimme' configuratie die volledig parametriseerbaar is tegen 2025. schaalbaar = - uitbreidbaar naar andere gemeenten / regio's - andere (nieuwe of bestaande) use cases moeten kunnen koppelen met het platform - ook aan bestedingszijde moet het platform flexibiliteit bieden (besteding bij handelaar, B2B, donatie aan lokale organisatie/doel/project, andere (crowd funding) systemen...
Use cases
ID
Status
Samenvatting
Beschrijving
UC1
Voorstel
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
UC2
Voorstel
UC2: Integratie
Integratie met bestaande applicaties zoals de stadsapplicaties, websites, cadeaubonnen applicaties en zelfs mijnburgerprofiel
UC3
Voorstel
UC3: Participatie Mechanisme
Een gebruiksvriendelijke platform om zowel als 'donor' als 'collector' als 'spender' zichzelf kunnen registreren en 'regels'/'parameters' voor ontvangen en gebruiken kunnen vastgelegd worden. Voor definities Donor, Collector en Spender, zie beneden Metadata
UC4
Voorstel
UC4: Marketing (CRM)
Aanradingsprogramma om de lokale economie aan te trekken om mee te doen zowel als 'donor' (participerende organisatie die een goed gedrag willen belonen) alsook als 'collector' (=winkels die deze munt aanvaarden als betaling) Inclusief communicatie platform om berichten, nieuwsletter, alerts, bevestigingen enz te kunnen beheren.
UC5
Voorstel
UC5: Omzettingsmechanisme
Een facturatie en betalings systeem die de eerste en allerlaatste conversie regelt, zodat de lokale munt in praktijk omgezet kunnen worden in euros.
UC6
Voorstel
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,...)
UC7
Voorstel
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) use cases moeten kunnen koppelen met het platform - ook aan bestedingszijde moet het platform flexibiliteit bieden (besteding bij handelaar, B2B, donatie aan lokale organisatie/doel/project, andere (crowd funding) systemen...
UC8
Voorstel
UC8: Draaiboeken
Een bibliotheek leveren van draaiboeken die de steden en gemeenten een 'how to' uitleggen ifv hun behoeften en context
UC9
Voorstel
UC9: Compensatie mogelijkheden (governance model)
Bij het kiezen voor een (additionele) lokale economie ondersteuning, willen we een evenwichtig systeem hebben tussen regionaal en lokaal muntsystemen, opdat eventueel geld zou kunnen terugvloeien tussen gemeenten/steden. Onevenwichtig is bvb indien een gemeente A sponsort met de hoop op het spenderen bij lokale handelaars terwijl er factueel buiten proporties uitgegeven wordt door de burgers in gemeente B.
UC10
Voorstel
UC10:helpdesk, klachten, reviews
Helpdesk bij vragen, FAQ, klachten en reviews door alle betrokken partijen
UC11
Voorstel
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 vertikaal om geld te kunnen 'krijgen' van de 'shopper'
Metadata
Metaveld
Beschrijving
Regionaal Munt
Een munt die breder is dan lokaal, dus weider geografisch alsook sectorieel, dit wordt gebruikt om puur een gedrag te stimuleren bvb
Lokaal Munt
Een munt die beperkt geografisch of sectorisch bruikbaar is, dit wordt gebruikt om een geografische of sector te ondersteunen
Donor
organisatie, lokaal bestuur, bedrijf, persoon die euros omzet in digitale munt
Collector
(=handelaar) organisatie, lokaal bestuur, bedrijf die digitale munt omzet in euros (niet voorzien dat burgers dit kunnen)
Spender
(=participant) deelnemer die lokale munten ontvangt als beloning en die deze kan spenderen bij een collector
User
(=gebruiker) burger, organisatie, lokaal bestuur, bedrijf... dat kan inloggen en gebruik maken van de digitale wallet
Guest
(= tijdelijke gebruiker) burger, organisatie, lokaal bestuur, bedrijf... Anoniem in de wallet applicatie wil rondneuzen om te zien wat er wordt aangeboden
Wallet applicatie
De 'kern' applicatie die de transacties van alle digitale munten beheert
Vertical
Een applicatie (incentiveringsproject) die gebruikt maakt van de 'wallet' applicatie
Superadmin
is een user die het volledig incentiveringsplatform beheert en toegang heeft tot alle economieen via het dashboard
Owner
is de initiatiefnemer van een incentive. Vaak een lokale overheid die de economy beheert. Een owner kan inloggen op het incentiveringsplatform en is en user in het systeem
Advertiser
De financierder van een incentive iseen advertiser. Een advertiser stort de financiele middelen op een fonds. Advertisers zijn geen users in het systeem
Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases
ID
Type
Samenvatting
Beschrijving
UC1
Use case
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
BC1.1
Business capability
Donor
Als donor wil ik aan een ontvanger een som in een digitale munt kunnen storten
DV1.1.1
Data vereiste
Transactie met A (betaler) en B (ontvanger) : tijd, bedrag, reden, geldigheidsduur
DV1.1.2
Data vereiste
FC1.1.1
Functionaliteit
Banking Applicatie
FC1.1.2
Functionaliteit
Controle Veiligheid
TV1.1.1
Techniciteit
Authenticatie Systeem
TV1.1.2
Techniciteit
Verificatie Systeem
BC1.2
Business capability
Collector
Als collector wil ik mijn digitale munt kunnen uitgeven binnen een handelstransactie
BC1.3
Business capability
Spender
Als spender wil ik mijn saldo van de digitale munt op mijn rekening kunnen consulteren in real time
BC1.4
Business capability
betaling
Als spender wil ik gemakkelijk, klantvriendelijk, kunnen betalen zoals bvb dit met een bankkaart mogelijk is
BC1.5
Business capability
Overzicht
Als spender wil ik duidelijk informatie kunnen terugvinden over mijn munten, zoals type, houbaarheidsdatum, demurrage, spelregels van de munt enz.
BC1.6
Business capability
verzilveren
Als collector wil ik mijn digitale munten gemakkelijk kunnen verzilveren tot euros
BC1.7
Business capability
cadeaubonnen
Als donor/collector wil ik aan de user/spender 'cadeaubonnen' kunnen schenken via het platform (bij een volgend bezoek)
BC1.8
Business capability
gratis parkeren
Als donor wil ik bvb n gratis parking kunnen schenken aan de spender in mijn winkel
ID
Type
Samenvatting
Beschrijving
UC2
Use case
UC2: Integratie
Integratie met bestaande applicaties zoals de stadsapplicaties, websites, cadeaubonnen applicaties en zelfs mijnburgerprofiel
BC2.1
Business capability
Integratie Applicaties
Als superadmin wil ik een 'vertaling' van de interne standaarden naar de 'standaarden' van de externe participerende applicaties en omgekeerd kunnen doorvoeren
BC2.2
Business capability
cross applicatie
Als superadmin wil ik alle participerende applicaties op n scherm of via een gemakkelijke integratie kunnen gevisualiseerd worden, maar ook interacties tussen de applicaties (transfer van tokens tot euros van n applicatie tot een andere)
BC2.3
Business capability
op mijnburgerprofiel
Als user wil ik mijn wallet ook kunnen zien via mijnburgerprofiel
ID
Type
Samenvatting
Beschrijving
UC3
Use case
UC3: Participatie Mechanisme
Een gebruiksvriendelijke platform om zowel als 'donor' als 'collector' als 'spender' zichzelf kunnen registreren en 'regels'/'parameters' voor ontvangen en gebruiken kunnen vastgelegd worden. Voor definities Donor, Collector en Spender, zie beneden Metadata
BC3.1
Business capability
Donor Registratie
Als donor wil ik mij gemakkelijk kunnen registreren om als 'donor' van fondsen te kunnen fungeren.
BC3.2
Business capability
Handelaar Registratie
Als Handelaar of organisatie wil ik mij gemakkelijk kunnen registreren om als 'collector' te kunnen fungeren
BC3.3
Business capability
Burger Registratie
Als burger wil ik mij gemakkelijk kunnen registreren als 'spender' om te kunnen participeren in het verkrijgen en spenderen van de digitale munt
BC3.4
Business capability
Burger Promo Participatie
Als spender wil ik mij gemakkelijk kunnen registreren om mee te doen aan specifieke acties (promoties ed)
BC3.5
Business capability
Hierarchie Rechten
Als owner wil ik een hierarchie van 'rechten' kunnen invoeren om regels te kunnen 'hierarchiseren' ten behoeve van de gebruiksvriendelijkheid van de burger/gebruiker
BC3.6
Business capability
Regels en Rechten
Als owner wil ik regels kunnen creeren en invoeren die de toekenning (via de verticals/apps) alsook uitgave (houdbaarheids termijn, minimale threshold, ...) van de munten bepalen
BC3.7
Business capability
Limiet van donor
Als owner wil ik de donors een mogelijkheid kunnen bieden voor een limiet die gemakkelijk zichtbaar moet zijn in de applicatie (hoeveel totale munten zijn nog beschikbaar bij die actie). Uiteraard zal dit in de applicaties (verticals) zelf moeten gebeuren, maar ook in de wallet kan de 'fondsen' van de donor vergeleken worden ifv die limiet.
BC3.8
Business capability
Anonieme Test Registratie
Als guest wil ik anoniem kunnen uitproberen om te zien wat er in het systeem beschikbaar is (zonder echte deelname met transacties)
BC3.9
Business capability
Vendorlocking vermijdend
De beheerder van het platform moet 'naadloos' kunnen veranderd worden zonder het project in gevaar te brengen. Dus de data ownership en documentatie moet voldoende beschreven en beschikbaar zijn om de 'transitie' en 'handover' zo optimaal mogelijk te maken.
BC3.10
Business capability
e-inclusie
Als user (spender, donor en collector) die niet digitaal ben wil ik ook via andere manieren kunnen registreren en gebruik maken van het platform.
BC3.10
Business capability
Validatie 'goede doel' collector
Als collector wil ik kunnen bewijzen dat ik een 'goede doel' ben via bvb de VKBO/mijnburgerprofiel, zodat bij het afromen of bij doorlopende of automatische betalingen er enkel naar 'goede doelen' bvb betaald zullen worden.
ID
Type
Samenvatting
Beschrijving
UC4
Use case
UC4: Marketing (CRM)
Aanradingsprogramma om de lokale economie aan te trekken om mee te doen zowel als 'donor' (participerende organisatie die een goed gedrag willen belonen) alsook als 'collector' (=winkels die deze munt aanvaarden als betaling) Inclusief communicatie platform om berichten, nieuwsletter, alerts, bevestigingen enz te kunnen beheren.
BC4.1
Business capability
Doelgroepen
Als owner wil ik een Identificatie van de doelgroepen (donors, handelaars/collectors en burgers/spenders) kunnen bepalen
BC4.2
Business capability
Targeting
Als owner wil ik een 'doellijst' (targetlist) kunnen opladen in een CRM voor mijn 'acquisitie' strategie
BC4.3
Business capability
Acquisitie
Als owner wil ik mijn doelgroep kunnen benaderen met promoties om bij interesse de regels te volgen om te kunnen genieten van een donatie
BC4.4
Business capability
Communicatie
Als donor wil ik eventueel een mogelijkheid om extra reklame te krijgen (banner ? enz.) door een bepaalde visibiliteit te krijgen bij het gebruik van het platform. Bvb gesponsord door xyz, enz.
ID
Type
Samenvatting
Beschrijving
UC5
Use case
UC5: Omzettingsmechanisme
Een facturatie en betalings systeem die de eerste en allerlaatste conversie regelt, zodat de lokale munt in praktijk omgezet kunnen worden in euros.
BC5.1
Business capability
Donatie
Als owner wil ik de donoren kunnen factureren opdat dit bedrag (min administratie kosten?) worden gestort op hun digitale munt rekening.
BC5.2
Business capability
Verzilvering
Als collector wil ik een factuur kunnen sturen naar het beleid om mijn digitale munt te verzilveren in echte euros
BC5.3
Business capability
NBB Licentie
Als owner wil ik aan de e-money licentie voorwaarden (Nationale Bank van Belgie) voldoen
BC5.4
Business capability
Wisselkoersen
Als owner wil ik de wisselkoersen (munt vs euros, munt vs andere munt) kunnen invoeren, bijhouden, visualiseren en gebruiken bij transacties.
BC5.5
Business capability
Waardeverlies
Als owner wil ik de waardeverlies (vervallen munten) kunnen visualiseren.
BC5.6
Business capability
Waarde Fluctuaties?
Als owner wil ik de waarde van een munt ifv vraag en aanbod kunnen laten fluctueren ?
BC5.7
Business capability
Afromen Slaapende munten
Als owner wil ik het 'afromen' van slapende munten (die niet meer gebruikt kunnen worden) kunnen 'schenken' aan goede doel projecten of organisaties.
ID
Type
Samenvatting
Beschrijving
UC6
Use case
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,...)
BC6.1
Business capability
Doelgroep Analyse
Als owner (en donor) wil ik mijn campagne resultaten kunnen meten om de doelgroepen beter te kennen
BC6.2
Business capability
ROI berekening
Als owner en donor wil ik onze beleidsdoelstellingen kunnen formuleren en meten als KPIs om een actie of verschillende acties samen te evalueren op succes (ROI)
BC6.3
Business capability
Rapportage
Als owner en donor wil ik alle betalingen/transacties per actie (gedrag) en per doelgroep kunnen analyseren en visualiseren
BC6.4
Business capability
Drill Down
Als owner wil ik alle transacties die binnen een regio (of sector, ed meer) werden gespendeerd kunnen analyseren en visualiseren
BC6.5
Business capability
Churn Prediction
Als owner wil ik kunnen zien welke gebruikers het platform bvb minder en minder gebruiken en waarom en wat kunnen we doen om die weer naar ons toe te trekken
BC6.6
Business capability
Forecasten
Als owner of Vertical wil ik een 'forecast' kunnen doen van de donors, transacties, saldo's ed meer in de komende periodes
ID
Type
Samenvatting
Beschrijving
UC7
Use case
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) use cases moeten kunnen koppelen met het platform - ook aan bestedingszijde moet het platform flexibiliteit bieden (besteding bij handelaar, B2B, donatie aan lokale organisatie/doel/project, andere (crowd funding) systemen...
BC7.1
Business capability
Integratie nieuwe stad of gemeente
Als super admin wil ik een nieuwe extra lokale overheid tot het incentiveringsplatform kunnen toevoegen
BC7.2
Business capability
Integratie Applicatie
Als super admin wil ik een nieuwe extra applicatie kunnen toevoegen (zowel donor als besteders)
BC7.3
Business capability
OSLO standaarden
Als super admin wil ik dat mijn datamodel volledig volgens de OSLO standaarden toegankelijk worden gesteld
BC7.4
Business capability
herbruikbare munten
Als superadmin wil ik dat de munten kunnen hergebruikt worden door andere applicaties om te vermijden dat er telkens een nieuwe munt wordt gegenereerd.
BC7.5
Business capability
punten vs munten
Als super admin wil ik dat zowel munten als punten kunnen opgeslagen en gebruikt worden in de wallet
BC7.6
Business capability
Acties ipv munten of punten
Als super admin wil ik ook 'acties' willen registreren ipv munten of punten, bvb 'planten van bomen'
BC7.7
Business capability
AML en KYC
Als superadmin moet ik de AML en KYC kunnen garanderen.
BC7.8
Business capability
Verdoken beloning
Als superadmin wil ik de 'administratie' kunnen informeren van de premies die betaald werden aan de spenders om zo bvb verdoken salarissen/compensaties te kunnen aangeven.
BC7.9
Business capability
Actie voor actie
Als super admin wil ik ook dat bij geleverde actie aan iemand en tegoed komt te staan van een actie in de andere richting (klusjes voor andere klusjes)
ID
Type
Samenvatting
Beschrijving
UC8
Use case
UC8: Draaiboeken
Een bibliotheek leveren van draaiboeken die de steden en gemeenten een 'how to' uitleggen ifv hun behoeften en context
BC8.1
Business capability
Nieuwe ontwikkeling
Als overheid wil ik alle versies van draaiboeken, bestekteksten, enz. voor opstartende lokale overheden kunnen bewaren, delen en publiceren
ID
Type
Samenvatting
Beschrijving
UC9
Use case
UC9: Compensatie mogelijkheden (governance model)
Bij het kiezen voor een (additionele) lokale economie ondersteuning, willen we een evenwichtig systeem hebben tussen regionaal en lokaal muntsystemen, opdat eventueel geld zou kunnen terugvloeien tussen gemeenten/steden. Onevenwichtig is bvb indien een gemeente A sponsort met de hoop op het spenderen bij lokale handelaars terwijl er factueel buiten proporties uitgegeven wordt door de burgers in gemeente B.
BC9.1
Business capability
Automatische terugvloeing
Als overheid en lokaal beleid wil ik dat bij niet evenwichtige transfers van waarden tussen regios er een compensatie kan 'gefactureerd' worden om die evenwicht opnieuw in te stellen (bvb een gemeente is donor, maar alle burgers kopen bij een handelaar bij een andere participerende gemeente (met akkoord), wat niet echt de bedoeling was, moeten de fondsen ook kunnen terugvloeien tussen de gemeenten)
BC9.2
Business capability
Inzichten
Als owner wil inzichten kunnen geven van waar munten gespendeerd worden en vergelijken met wie de donoren waren om zo een vergelijking te kunnen maken van het evenwichtssysteem
BC9.3
Business capability
goed gedrag vs lokale economie
Als owner wil ik gemakkelijk kunnen kiezen welke munt ik wil gebruiken ifv of het een 'goed gedrag beloning' en/of 'lokale economie steunen'
ID
Type
Samenvatting
Beschrijving
UC10
Use case
UC10:helpdesk, klachten, reviews
Helpdesk bij vragen, FAQ, klachten en reviews door alle betrokken partijen
BC10.1
Business capability
Standaard Antwoorden
Als medewerker wil ik efficient standaard antwoorden kunnen beantwoorden op standaard vragen
BC10.2
Business capability
FAQ
Als medewerker wil ik mijn FAQ telkens meer relevanter maken ifv de adhoc vragen die telkens weer binnenkomen
BC10.3
Business capability
Klachten
Als user wil ik mijn klachten ivm het platform (en 'vertikalen) eenvoudig kunnen communiceren
BC10.4
Business capability
Reviews
Als user wil ik mijn tevredenheid kunnen uitdrukken via reviews
BC10.5
Business capability
Inzichten
Als owner wil inzichten kunnen halen van de vragen, klachten en reviews om het platform telkens relevanter te maken
BC10.6
Business capability
Fraudebestrijding
Als superadmin moet ik de AML en KYC kunnen garanderen.
ID
Type
Samenvatting
Beschrijving
UC11
Use case
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 vertikaal om geld te kunnen 'krijgen' van de 'shopper'
BC11.1
Business capability
Handelaars
Als collector wil ik via n applicatie betalingen van allerlei munten kunnen ontvangen
BC11.2
Business capability
Shopper
Als spender wil ik via n applicatie mijn betalingen van allerlei munten kunnen uitvoeren
BC11.3
Business capability
Inzichten
Als super admin wil ik kunnen zien hoeveel 'geweigerde' of 'niet doorgegaan' betalingen zijn geweest met reden waarom
BC11.4
Business capability
Commissies
Als super admin wil ik een 'commissie' kunnen 'aftrekken' voordat het 'geld' naar de collector gaat of van de donor komt
BC11.5
Business capability
Fraudebesrijding
Als super admin wil ik mijn betalingsapplicatie kunnen monitoren en beveiligen tegen fraude
BC11.6
Business capability
Betalingskaarten
Als super admin wil ik de gebruikers een electronische chip kaart (zelfde formaat Maestro en kredietkaarten) kunnen geven waarmee ook betalingen kunnen gebeuren
BC11.7
Business capability
Domiciliering/doorlopende opdrachten
Als spender wil ik mijn betalingen ook recurrent kunnen laten uitvoeren naar een goede doel
BC11.8
Business capability
Overschrijvingen
Als spender wil ik mijn betaling ook via een overschrijving, domiciliering, doorlopende opdracht of automatisch doorsturen naar goede doelen bvb kunnen doen naar derden
BC11.9
Business capability
Cancellations
Als collector wil ik de betaling kunnen terugdraaien (bij teruggave product) naar de spender
BC11.10
Business capability
QR of andere 'bonnen'
Als spender wil ik via een code (QR bvb) mijn betaling kunnen doen
BC11.11
Business capability
Gecombineerde munten
Als spender wil ik 'cross' munten betalingen kunnen uitvoeren, dus n betaling die van mijn verschillende munten de saldo afhalen.
BO Fase
BC ID
Naam business capacity
Fase 1
BC1.1
Donor transacties
Fase 1
BC1.2
Spender transacties
Fase 1
BC1.3
Spender(+Collector) Saldo
Fase 1
BC1.4
betaling
Fase 1
BC1.5
Overzicht
Fase 2
BC1.7
cadeaubonnen
Fase 3
BC1.8
gratis parkeren
Fase 1
BC2.1
Integratie Applicaties
Fase 2
BC2.2
cross applicatie
Fase 2
BC2.3
op mijnburgerprofiel
Fase 1
BC3.1
Donor Registratie
Fase 1
BC3.2
Handelaar Registratie
Fase 1
BC3.3
Burger Registratie
Fase 2
BC3.4
Burger Promo Participatie
Fase 1
BC3.6
Regels en Rechten
Fase 2
BC3.7
Limiet van donor
Fase 3
BC3.8
Anonieme Test Registratie
Fase 1
BC3.9
Vendorlocking vermijdend
Fase 1
BC3.10
e-inclusie
Fase 3
BC3.10
Validatie 'goede doel' collector
Fase 2
BC4.1
Doelgroepen
Fase 1
BC4.2
Targeting
Fase 1
BC4.3
Acquisitie
Fase 3
BC4.4
Communicatie
Fase 1
BC5.1
Donatie
Fase 1
BC5.2
Verzilvering
Fase 2
BC5.3
NBB Licentie
Fase 1
BC5.4
Wisselkoersen
Fase 1
BC5.5
Waardeverlies
Fase 3
BC5.6
Waarde Fluctuaties?
Fase 2
BC5.7
Afromen Slapende munten
Fase 2
BC6.1
Impact campagne
Fase 2
BC6.2
ROI berekening
Fase 2
BC6.3
Rapportage
Fase 2
BC6.4
Drill Down
Fase 2
BC6.5
Churn Prediction
Fase 2
BC6.6
Forecasten
Fase 1
BC7.1
Integratie nieuwe stad of gemeente
Fase 1
BC7.2
Integratie Applicatie
Fase 1
BC7.3
OSLO standaarden
Fase 1
BC7.4
herbruikbare munten
Fase 2
BC7.5
punten vs munten
Fase 3
BC7.6
Acties ipv munten of punten
Fase 1
BC7.7
AML en KYC
Fase 1
BC8.1
Uitrol / implementatie
Fase 1
BC8.2
Nieuwe ontwikkeling
Fase 1
BC8.3
GDPR
Fase 2
BC9.1
Automatische terugvloeing
Fase 1
BC9.3
goed gedrag vs lokale economie
Fase 1
BC10.1
Standaard Antwoorden
Fase 1
BC10.2
FAQ
Fase 1
BC10.3
Klachten
Fase 2
BC10.4
Reviews
Fase 2
BC10.5
Inzichten
Fase 1
BC11.1
Handelaars
Fase 1
BC11.2
Shopper
Fase 2
BC11.3
Inzichten
Fase 3
BC11.4
Commissies
Fase 1
BC11.5
Fraudebesrijding
Fase 3
BC11.6
Betalingskaarten
Fase 3
BC11.7
Domiciliering/doorlopende opdrachten
Fase 3
BC11.8
Overschrijvingen
Fase 2
BC11.9
Cancellations
Fase 1
BC11.10
QR of andere 'bonnen'
Fase 1
BC11.11
Gecombineerde munten
{| class="wikitable"style="background-color:#ffffff;font-size:90%"
|-
| Level2
| Level3
|}
CoT Regionaal plugable incentiveringsplatform Geel
2022
VLOCA-model versie 1.8
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 ?
Steden hebben het moeilijk om het gedrag van de burgers te veranderen zonder incentivering. Uit vorige projecten blijkt dat 'vouchers' en 'lokale (digitale) munten' (sociale krediet zoals duimpjes up) daarvoor goed werken. Maar die worden ook te snel verzilverd in euro's en blijven niet binnen het systeem. Daarnaast leiden verschillende incentiveringen ook tot eigen vouchers of (digitale) munten hetgeen resulteert in een versnipperd landschap van systemen. De keuze om al de lokale economie te steunen dan wel expliciet te kiezen voor een digitale munt die regionaal besteed kan worden (= aantrekkelijker voor de burger) moet bij de initiatiefnemer (lees: lokaal bestuur) liggen: waar steun aan lokale economie belangrijkste finaliteit is, moet er gekozen kunnen worden voor een lokale munt. Wanneer een incentivering op een bepaalde maatschappelijk wenselijk gedrag ligt, is een regionale campagne die toeleidt tot een regionale munt vaak interessanter. -Lokale besturen wensen ook aan de bestedingszijde meer te kunnen richten naar doelen, projecten... met een maatschappelijke meerwaarde.
Missie
Voorstel
Wat willen we bereiken ?
Een oplossing die zowel het duurzaam gedrag van de burger wil beinvloeden door beloning alsook (of) de lokale economie of lokale organisaties wil ondersteunen.
Doel
Voorstel
Wat is het doel van dit project ?
Een platform die eigenlijk 'goed gedrag' beloont met een 'lokale munt' die enkel in de regio kan ingeruild/gespendeerd worden = 'regio breed incentiveringsplatform' die ook dmv een 'schaalbaar' architectuur snel en efficient uitrolbaar is in andere regio die dat zouden wensen. Een digitale wallet waarop toepassingen die incentiveringen (stimulansaanbiedingen) kunnen connecteren vormt de basis van zo'n incentiveringsplatform. Het organiseren van de eigenlijke 'beloning' van goed gedrag zal niet in het platform zelf gebeuren, maar via de 'verticals', dus de applicaties die allemaal dit platform zullen gebruiken om de transacties bij te houden en uitgaven te kunnen doen.De lokale/digitale munt moet ook kunnen dienen als 'betaalmiddel' tussen C2C en B2B (mits wetgevend kader) om die munt zo lang mogelijk binnen de regio te houden.
Succesfactor
Voorstel
Hoe meten we succes ? (SMART)
Een schaalbaar regiobreed incentiveringsplatform met een 'slimme' configuratie die volledig parametriseerbaar is tegen 2025. schaalbaar = - uitbreidbaar naar andere gemeenten / regio's - andere (nieuwe of bestaande) 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...
Use cases
ID
Status
Samenvatting
Beschrijving
UC1
Voorstel
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
UC2
Voorstel
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)
UC3
Voorstel
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: zie beneden Metadata
UC4
Voorstel
UC4: Marketing (CRM)
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.
UC5
Voorstel
UC5: Omzettingsmechanisme
Een facturatie- en betalingssysteem dat de eerste en allerlaatste conversie regelt zodat de lokale munt in praktijk omgezet kan worden in euros.
UC6
Voorstel
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 (incl. analyse van 'verval' of 'demurage' = waardeverlies waarbij men de vrijgekomen (vervallen/verloren) budgetten inzet voor specifieke goed doelen)
UC7
Voorstel
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
Voorstel
UC8: Draaiboeken
Een bibliotheek leveren van draaiboeken die de steden en gemeenten een 'how to' uitleggen ifv hun behoeften en context
UC9
Voorstel
UC9: Compensatie mogelijkheden (governance model)
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.
UC10
Voorstel
UC10:helpdesk, klachten, reviews
Helpdesk bij vragen, FAQ, klachten en reviews door alle betrokken partijen
UC11
Voorstel
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 vertikaal om geld te kunnen 'krijgen' van de 'shopper'
Metadata
Metaveld
Beschrijving
Regionale Munt
Een munt die breder is dan lokaal, dus wijder geografisch alsook eventueel sectorieel. Kan ingezet worden als beloning om bepaald gedrag te incentiveren.
Lokale Munt
Een munt die beperkt geografisch bruikbaar is en die voornamelijk wordt gebruikt om de economie binnen een beperkte geografische omgeving (bijv. stad) te ondersteunen
Donor
organisatie, lokaal bestuur, bedrijf, persoon die euros omzet in digitale munt en die een stimulansaanbod aanbiedt
Collector
(=handelaar) organisatie, lokaal bestuur, bedrijf die digitale munt omzet in euros (niet voorzien dat burgers dit kunnen)
Spender
(=participant) deelnemer die lokale munten ontvangt (bijv. Agent met rol 'Consument' die een Beloningsontvangst krijgt bij deelname aan een Stimulansaanbod, cfr OSLO) en die deze kan spenderen bij een collector
User
(=gebruiker) burger, organisatie, lokaal bestuur, bedrijf... dat kan inloggen en gebruik maken van de digitale wallet
Guest
(= tijdelijke gebruiker) burger, organisatie, lokaal bestuur, bedrijf... Anoniem in de wallet applicatie om te zien wat er wordt aangeboden
Wallet applicatie
De 'kern' applicatie die de transacties van alle digitale munten beheert
Vertical
Een applicatie (bijv. applicatie die een stimulansaanbod organiseert of een overkoepelende applicatie) die interageert met de 'wallet' applicatie
Superadmin
is een user die het volledig incentiveringsplatform beheert en toegang heeft tot alle elementen. Een superadmin is de leverancier van het incentiveringsplatform die economie n kan onboarden.
Owner
is (de groep van) organisatie(s) die samen een specifieke digitale munt (economie) beheren/stimuleren. Vaak n of meerdere lokale overheden die de economie beheren. Een owner kan inloggen op het incentiveringsplatform en is een user (en vaak ook donor) in het systeem
Fund
Entiteit gelinkt aan een wachtrekening (holdingaccount) met achterliggend derdebetalersysteem. Een fund heeft een wallet. Wanneer een bepaald bedrag wordt gestort op de derdenbetalerrekening gekoppeld aan het fund, wordt het saldo van de wallet van het fund verhoogd met dezelfde monetaire waarde in lokale of regionale munten.
Economy
De lokale economie van een stad of regio. Een gesloten netwerk waar digitale munten (coins) circuleren onder de vorm van transacties tussen wallets van spenders en collectors
Sponsor (voorheen adverteerder)
Is geen echte gebruiker in het systeem maar een externe actor die vanuit duurzaamen maatschappelijk ondernemen een afgelijnd sponsorbudget ter beschikking heeft om een stimulansaanbod te financieren en zichtbaarheid te verkrijgen in de wallet app bij een groot publiek. Nadat de sponsor kiest voor een sponsorformule (gold/silver/brons of gelijkaardig) zal de owner of superadmin hem aanmaken in het systeem en lokale munten aankopen op het platform met middelen verkregen door de sponsor.
Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases
ID
Type
Samenvatting
Beschrijving
UC1
Use case
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
BC1.1
Business capability
Donor transacties
Als donor wil ik via de owner een som in de 'fonds' kunnen overschrijven om aan een ontvanger een som in een digitale munt te kunnen storten
Kolom
Sales & Distribution Mgt
Kolom2
Finance
Kolom3
Supplychain mgt
DV1.1.1
Data vereiste
OSLO Business Object
Consument
DV1.1.2
Data vereiste
OSLO Business Object
Sponsor
FC1.1.1
Functionaliteit
Beheer Tatificatie
FC1.1.2
Functionaliteit
Beheer Facturatie
TV1.1.1
Techniciteit
Authenticatie Systeem
TV1.1.2
Techniciteit
Verificatie Systeem
BC1.2
Business capability
Collector
Als spender wil ik mijn digitale munt kunnen uitgeven binnen een handelstransactie
DV1.2.1
Data vereiste
OSLO Business Object
Consument
DV1.2.2
Data vereiste
OSLO Business Object
Aanbieder
FC1.2.1
Functionaliteit
Beheer Uitgaande Betalingen
FC1.2.2
Functionaliteit
Beheer afhoudingspercentages
TV1.2.1
Techniciteit
Authenticatie Systeem
TV1.2.2
Techniciteit
Verificatie Systeem
BC1.3
Business capability
Spender(+Collector) Saldo
Als spender (alsook collector) wil ik mijn saldo van de digitale munt op mijn rekening kunnen consulteren in real time
BC1.4
Business capability
betaling
Als spender wil ik gemakkelijk, klantvriendelijk, kunnen betalen zoals bvb dit met een bankkaart mogelijk is maar in dit project met bvb payconic met QR code.
BC1.5
Business capability
Overzicht
Als spender wil ik duidelijk informatie kunnen terugvinden over mijn munten, zoals type, houdbaarheidsdatum, demurrage, spelregels van de munt enz. Principes van verval of waardeverlies (demurrage) van digitale munten moeten duidelijk zijn binnen de wallet
BC1.6
Business capability
cadeaubonnen
Als donor/collector wil ik aan een spender 'cadeaubonnen' kunnen schenken via het platform (bijv. bij een volgend bezoek) Dit is eigenlijk een speciale geval van een 'munt' dat enkel bij de collector kan gespendeerd worden met evt extra randvoorwaarden.
BC1.7
Business capability
gratis parkeren
Als collector wil ik bvb n gratis parkeersessie kunnen schenken aan de spender in mijn winkel. Dit is eigenlijk een speciale munt (parkeersessie) die enkel aan de parkeerautomaat bvb kan gebruikt worden.
BC1.8
Business capability
Regels en Rechten
Als owner wil ik regels kunnen creeren en invoeren die de toekenning (via de verticals/apps) alsook uitgave (houdbaarheids termijn, minimale threshold, ...) van de munten bepalen. In vele gevallen zal dit ofwel in de verticale app gebeuren en de 'netto' info naar de wallet gestuurd worden, maar soms kan de verticale app direct op de digital wallet regels opslaan en de saldo in de wallet berekenen, ofwel kan het in beide (zowel verticale als wallet)
BC1.9
Business capability
Limiet van donor
Als owner wil ik de donors een mogelijkheid kunnen bieden voor een limiet die gemakkelijk zichtbaar moet zijn in de applicatie (hoeveel totale munten zijn nog beschikbaar bij die actie). Uiteraard zal dit in de applicaties (verticals) zelf moeten gebeuren, maar ook in de wallet kan de 'fondsen' van de donor vergeleken worden ifv die limiet.
BC1.10
Business capability
Hierarchie Rechten
Als owner wil ik een hierarchie van 'rechten' kunnen invoeren om regels te kunnen 'hierarchiseren' ten behoeve van de gebruiksvriendelijkheid van de burger/gebruiker. Dus alle regels kunnen visualiseren en zorgen dat ze elkaar niet tegenspreken of veel te complex beginnen te worden. Dus, als owner wil ik de regels die ingevoerd worden kunnen controleren.
BC1.11
Business capability
Validatie 'goede doel' collector
Als collector wil ik kunnen bewijzen dat ik een 'goede doel' ben via bvb de VKBO/mijnburgerprofiel? Of enkel VZW zouden in aanmerking komen ?, zodat bij het afromen of bij doorlopende of automatische betalingen er enkel naar 'goede doelen' bvb betaald zullen worden. Een ander idee is een 'whitelist' bouwen van de 'goede doelen' organisaties die in aanmerking zouden kunnen komen.
BC1.12
Business capability
Inzichten
Als super admin wil ik kunnen zien hoeveel 'geweigerde' of 'niet doorgegaan' betalingen zijn geweest met reden waarom
BC1.13
Business capability
Commissies
Als super admin wil ik een 'commissie' (administratieve kost) kunnen 'aftrekken' voordat het 'geld' van de donor naar de 'fonds' komt of eventueel (niet gewenst in dit project) voordat het geld naar de collector gaat .
BC1.14
Business capability
Cancellations
Als collector wil ik de betaling kunnen terugdraaien (bij teruggave product) naar de spender. Dit is niet altijd evident, vooral wanneer de munt reeds is verzilverd door de collector in euros. Hoe gebeurt dit dan ?
BC1.15
Business capability
QR of andere 'bonnen'
Als spender wil ik via een code (QR bvb) mijn betaling kunnen doen
BC1.16
Business capability
Gecombineerde munten
Als spender wil ik 'cross' munten betalingen kunnen uitvoeren, dus n betaling die van het saldo van mijn verschillende munten bedragen afhaalt. Uiteraard moet de 'collector' beide munten dan accpeteren.
BC1.17
Business capability
Waardeverlies
Als owner wil ik verval en demurrage-regels kunnen toepassen op de digitale munten
BC1.18
Business capability
Waarde Fluctuaties?
Als owner wil ik de waarde van een munt ifv vraag en aanbod kunnen laten fluctueren ?
BC1.19
Business capability
Afromen Slapende munten
Als owner wil ik het bedrag ter waarde van de demurrage of de vervallen munten kunnen 'schenken' aan goede doel projecten of organisaties.
BC1.20
Business capability
punten vs munten
Als super admin wil ik dat zowel munten als punten kunnen opgeslagen en gebruikt worden in de wallet, uiteraard kunnen de punten gewoon als 'munten' beschouwd worden in het systeem.
BC1.21
Business capability
Acties ipv munten of punten
Als super admin wil ik ook 'acties' willen registreren ipv munten of punten, bvb 'planten van bomen'
BC1.22
Business capability
Actie voor actie
Als super admin wil ik ook dat bij geleverde actie aan iemand en tegoed komt te staan van een actie in de andere richting (klusjes voor andere klusjes) Dus ipv 'munten' ook in 'acties' kunnen opslaan.
BC1.23
Business capability
goed gedrag vs lokale economie
Als donor wil ik gemakkelijk kunnen kiezen welke munt ik wil gebruiken ifv of het een 'goed gedrag beloning' en/of 'lokale economie steunen'
ID
Type
Samenvatting
Beschrijving
UC2
Use case
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)
BC2.1
Business capability
Integratie Applicaties
Als superadmin wil ik een 'vertaling' van de interne standaarden naar de 'standaarden' van de externe participerende applicaties en omgekeerd kunnen doorvoeren
BC2.2
Business capability
cross applicatie
Als superadmin wil ik alle participerende applicaties op n scherm of via een gemakkelijke integratie kunnen gevisualiseerd worden, maar ook interacties tussen de applicaties (transfer van tokens tot euros van n applicatie tot een andere)
BC2.3
Business capability
op mijnburgerprofiel
Als user wil ik mijn wallet ook kunnen zien via de MijnBurgerProfiel app
ID
Type
Samenvatting
Beschrijving
UC3
Use case
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: zie beneden Metadata
BC3.1
Business capability
Als Donor via Owner Registratie
Als donor via owner wil ik mij gemakkelijk kunnen registreren om de economy te beheren
BC3.2
Business capability
Handelaar Registratie
Als Handelaar of organisatie wil ik mij gemakkelijk kunnen registreren om als 'collector' te kunnen fungeren
BC3.3
Business capability
Burger Registratie
Als burger wil ik mij gemakkelijk kunnen registreren als 'spender' om te kunnen participeren in het verkrijgen en spenderen van de digitale munt
BC3.4
Business capability
Burger Promo Participatie
Als spender wil ik mij gemakkelijk kunnen registreren om mee te doen aan specifieke acties (promoties ed)
BC3.5
Business capability
Anonieme Test Registratie
Als guest wil ik anoniem kunnen uitproberen om te zien wat er in het systeem beschikbaar is (zonder echte deelname met transacties)
BC3.6
Business capability
Vendorlocking vermijdend
De beheerder van het platform moet 'naadloos' kunnen veranderd worden zonder het project in gevaar te brengen. Dus de data ownership en documentatie moet voldoende beschreven en beschikbaar zijn om de 'transitie' en 'handover' zo optimaal mogelijk te maken.
BC3.7
Business capability
e-inclusie
Als user (spender, donor en collector) die niet digitaal ben wil ik ook via andere manieren kunnen registreren en gebruik maken van het platform, oftewel via Digidokter of via andere leden van de familie bvb. Mogelijkheid om QR codes met bedrag/coins in een afdrukbaar formaat aan gebruikers te bezorgen indien ze geen smartphone hebben of de app niet kunnen gebruiken.
ID
Type
Samenvatting
Beschrijving
UC4
Use case
UC4: Marketing (CRM)
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.
BC4.1
Business capability
Doelgroepen
Als owner wil ik een Identificatie van de potentiele doelgroepen (donors, handelaars/collectors en burgers/spenders) kunnen bepalen
BC4.2
Business capability
Targeting
Als owner wil ik een 'doellijst' (targetlist) kunnen opladen in een CRM voor mijn 'acquisitie' strategie
BC4.3
Business capability
Acquisitie
Als owner wil ik mijn doelgroep kunnen benaderen met promoties om bij interesse de regels te volgen om te kunnen genieten van een donatie
BC4.4
Business capability
Communicatie
Als donor wil ik eventueel een mogelijkheid om extra reklame te krijgen (banner ? enz.) door een bepaalde visibiliteit te krijgen bij het gebruik van het platform. Bvb gesponsord door xyz, enz.
ID
Type
Samenvatting
Beschrijving
UC5
Use case
UC5: Omzettingsmechanisme
Een facturatie- en betalingssysteem dat de eerste en allerlaatste conversie regelt zodat de lokale munt in praktijk omgezet kan worden in euros.
BC5.1
Business capability
Donatie
Als donor via de owner wil ik een bedrag in euros kunnen omzetten in digitale munten (euro facturatie van en overschrijving naar de 'owner' van het platform)
BC5.2
Business capability
Verzilvering
Als collector wil ik een factuur kunnen sturen om mijn digitale munt te verzilveren in echte euros
BC5.3
Business capability
NBB Licentie
Als superadmin (owner?) wil ik aan contractuele voorwaarden (bijv. e-money licentie van Nationale Bank van Belgie of anders) kunnen voldoen
BC5.4
Business capability
Wisselkoersen
Als owner wil ik de wisselkoersen (munt vs euros, munt vs andere munt) kunnen invoeren, bijhouden, visualiseren en gebruiken bij transacties.
BC5.5
Business capability
verzilveren
Als collector wil ik mijn digitale munten gemakkelijk kunnen verzilveren tot euros
ID
Type
Samenvatting
Beschrijving
UC6
Use case
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 (incl. analyse van 'verval' of 'demurage' = waardeverlies waarbij men de vrijgekomen (vervallen/verloren) budgetten inzet voor specifieke goed doelen)
BC6.1
Business capability
Impact campagne
Als owner (en donor) wil ik mijn campagneresultaten kunnen meten om impact op het gewenste maatschappelijk gedrag te meten
BC6.2
Business capability
ROI berekening
Als owner en donor wil ik onze beleidsdoelstellingen kunnen formuleren en meten als KPIs om een actie of verschillende acties samen te evalueren op succes (ROI)
BC6.3
Business capability
Rapportage
Als owner en donor wil ik alle betalingen/transacties per actie (gedrag) en per doelgroep kunnen analyseren en visualiseren
BC6.4
Business capability
Drill Down
Als owner wil ik alle transacties die binnen een regio (of sector, ed meer) werden gespendeerd kunnen analyseren en visualiseren
BC6.5
Business capability
Churn Prediction
Als owner wil ik kunnen zien welke gebruikers het platform bvb minder en minder gebruiken en waarom en wat kunnen we doen om die weer naar ons toe te trekken
BC6.6
Business capability
Forecasten
Als owner of Vertical wil ik een 'forecast' kunnen doen van de donors, transacties, saldo's ed meer in de komende periodes
BC6.7
Business capability
Inzichten
Als owner wil inzichten kunnen geven van waar munten gespendeerd worden en vergelijken met wie de donoren waren om zo een vergelijking te kunnen maken van het evenwichtssysteem (onderdeel van UC6?)
ID
Type
Samenvatting
Beschrijving
UC7
Use case
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...
BC7.1
Business capability
Integratie nieuwe stad of gemeente
Als super admin wil ik een nieuwe extra lokale overheid (als donor of owner) tot het incentiveringsplatform kunnen toevoegen
BC7.2
Business capability
Integratie Applicatie
Als super admin wil ik een nieuwe extra applicatie (vertical) kunnen connecteren (zowel donor als besteders)
BC7.3
Business capability
OSLO standaarden
Als super admin wil ik dat mijn datamodel volledig volgens de OSLO standaarden toegankelijk worden gesteld
BC7.4
Business capability
herbruikbare munten
Als superadmin wil ik dat de munten kunnen hergebruikt worden door andere applicaties om te vermijden dat er telkens een nieuwe munt wordt gegenereerd.
BC7.5
Business capability
AML en KYC
Als superadmin moet ik de AML en KYC kunnen garanderen.
BC7.6
Business capability
Verdoken beloning
Als superadmin wil ik de relevante 'administraties' kunnen informeren van de premies die betaald werden aan de spenders om zo bvb verdoken salarissen/compensaties te kunnen aangeven.
BC7.7
Business capability
Sponsor Creatie
Als owner wil ik via de Superadmin een sponsor aanmaken met een sponsorformule (='contract'?) die bepaalt het bedrag te storten door sponsor alsook wat de sponsor daarvoor terugkrijgt (visibiliteit op de app, enz.)
BC7.8
Business capability
Collector Validatie
Als Owner wil ik de collectors kunnen valideren en op een 'whitelist' plaatsen
BC7.9
Business capability
Munt-Collector Validatie
Als Owner wil ik de munten kunnen valideren die door de collector kan gebruikt worden en die reeds op een 'whitelist' plaatsen
ID
Type
Samenvatting
Beschrijving
UC8
Use case
UC8: Draaiboeken
Een bibliotheek leveren van draaiboeken die de steden en gemeenten een 'how to' uitleggen ifv hun behoeften en context
BC8.1
Business capability
Uitrol / implementatie
Als aanbestedende overheid wil ik over alle technische concepten, beschrijvingen, eisenpakketten beschikken in functie van een marktconsultatie/-bevraging om de digitale wallet en gelinkte verticals te kunnen uitrollen / implementeren
BC8.2
Business capability
Nieuwe ontwikkeling
Als overheid wil ik alle versies van draaiboeken, bestekteksten, enz. voor opstartende lokale overheden kunnen bewaren, delen en publiceren
BC8.3
Business capability
GDPR
Als aanbestedende overheid wil ik de rollen m.b.t. GDPR duidelijk uitgeklaard zien tussen de verschillende betrokkenen (inclusief aanwezigheid van de nodige overeenkomsten)
ID
Type
Samenvatting
Beschrijving
UC9
Use case
UC9: Compensatie mogelijkheden (governance model)
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.
BC9.1
Business capability
Automatische terugvloeing
Als overheid en lokaal beleid wil ik dat bij niet evenwichtige transfers van waarden tussen regios er een compensatie kan 'gefactureerd' worden om die evenwicht opnieuw in te stellen (bvb een gemeente is donor, maar alle burgers kopen bij een handelaar bij een andere participerende gemeente (met akkoord), wat niet echt de bedoeling was, moeten de fondsen ook kunnen terugvloeien tussen de gemeenten)
ID
Type
Samenvatting
Beschrijving
UC10
Use case
UC10:helpdesk, klachten, reviews
Helpdesk bij vragen, FAQ, klachten en reviews door alle betrokken partijen
BC10.1
Business capability
Standaard Antwoorden
Als medewerker wil ik efficient standaard antwoorden kunnen beantwoorden op standaard vragen
BC10.2
Business capability
FAQ
Als medewerker wil ik mijn FAQ telkens meer relevanter maken ifv de adhoc vragen die telkens weer binnenkomen
BC10.3
Business capability
Klachten
Als user wil ik mijn klachten ivm het platform (en 'vertikalen) eenvoudig kunnen communiceren
BC10.4
Business capability
Reviews
Als user wil ik mijn tevredenheid kunnen uitdrukken via reviews
BC10.5
Business capability
Inzichten
Als owner wil inzichten kunnen halen van de vragen, klachten en reviews om het platform telkens relevanter te maken
ID
Type
Samenvatting
Beschrijving
UC11
Use case
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 vertikaal om geld te kunnen 'krijgen' van de 'shopper'
BC11.1
Business capability
Handelaars
Als collector wil ik via n applicatie betalingen van allerlei munten kunnen ontvangen
BC11.2
Business capability
Shopper
Als spender wil ik via n applicatie mijn betalingen van allerlei munten kunnen uitvoeren
BC11.3
Business capability
Fraudebesrijding
Als super admin wil ik mijn betalingsapplicatie kunnen monitoren en beveiligen tegen fraude
BC11.4
Business capability
Betalingskaarten
Als super admin wil ik de gebruikers een electronische chip kaart (zelfde formaat Maestro en kredietkaarten) kunnen geven waarmee ook betalingen kunnen gebeuren
BC11.5
Business capability
Domiciliering/doorlopende opdrachten
Als spender wil ik mijn betalingen ook recurrent kunnen laten uitvoeren naar een goede doel bvb bij verval
BC11.6
Business capability
Overschrijvingen
Als spender wil ik mijn betaling ook via een overschrijving, domiciliering, doorlopende opdracht of automatisch doorsturen naar goede doelen bvb kunnen doen naar derden
Objectieve criteria
De objectieve criteria worden beschreven in deze functionele vereisten. We splitsen de vereisten op in applicatiecomponenten (wat is de deeloplossing, verzameling van applicatiefuncties, bijvoorbeeld Mijnburgerprofiel) en applicatiefuncties (wat moet een applicatiecomponent allemaal kunnen (bv Authenticeren)). Voor een gedetailleerde beschrijving van deze vereisten, verwijzen we naar de laatste versie van het VLOCA-model .
Minimale vereisten
Het voldoen aan de minimale criteria wordt berekend aan de hand van de kolom Weging en Checklist. De minimumwaarde om als essentieel beschouwd te worden is vrij te bepalen door de aanbesteder. Alle scores van bijvoorbeeld minimaal 50 beschouwen we als noodzakelijk ter uitvoering van het desbetreffend perceel. Alle specificaties met een weging die de aan de minimumwaarde voldoet, dienen uitvoerbaar te zijn.
Selectiecriteria
Om de selectie te faciliteren, wordt een score berekend op basis van de minimale criteria vermenigvuldigd met de waarde in de weging. De totale score per perceel wordt berekend en gedeeld door de totale waarden in de weging voor dat perceel om zo tot een percentage te komen.
Applicatiecomponent
Use Case
ID
Applicatiefunctie
Weging
Checklist
Minimale vereisten
Gunningscriteria
Formule
Resultaat
Formule
Resultaat
Applicatiecomponent1
UC1
1.1
Vereiste1
70
Ja
Checklist = Ja --> 1 Weging <50 --> 1 Weging >= 50 en Checklist = Nee --> 0
1
Minimale vereisten x Weging
70
1.2
Vereiste2
42
Nee
1
42
1.3
Vereiste3
21
Ja
1
21
UC2
2.1
Vereiste4
60
Nee
0
0
2.2
Vereiste5
60
Ja
1
60
2.3
Vereiste6
60
Ja
1
60
2.4
Vereiste7
48
Ja
1
48
Totaal
Som van alle resultaten vereisten / maximale som applicatiecomponent
83 %
Er wordt ook een totale weging gemaakt waar alle applicatiecfuncties voor alle applicatiecomponenten worden berekend.
Gunningscriteria
Een inschrijving wordt positief ontvangen wanneer bijvoorbeeld een score 50 % wordt behaald voor alle percelen en score van 75 % voor de totaliteit van de applicatiefuncties.
Applicatiecomponent
Use Case
ID
Applicatiefunctie
Weging
Checklist
API Management
UC2
BR2.1
Integratie Applicaties
70
BR2.2
cross applicatie
42
BR2.3
op mijnburgerprofiel
21
UC3
BR3.7
e-inclusie
60
UC7
BR7.1
Integratie nieuwe stad of gemeente
60
BR7.2
Integratie Applicatie
60
BR7.3
OSLO standaarden
48
Artificial Intelligence
UC6
BR6.1
Impact campagne
32
BR6.2
ROI berekening
32
BR6.4
Drill Down
20
BR6.5
Churn Prediction
12
BR6.6
Forecasten
16
UC7
BR7.5
AML en KYC
48
Business Intelligence
UC2
BR2.2
cross applicatie
42
UC6
BR6.1
Impact campagne
32
BR6.2
ROI berekening
32
BR6.3
Rapportage
20
BR6.4
Drill Down
20
BR6.5
Churn Prediction
12
BR6.6
Forecasten
16
UC7
BR7.4
herbruikbare munten
36
BR7.5
AML en KYC
48
UC8
BR8.1
Uitrol / implementatie
60
BR8.2
Nieuwe ontwikkeling
48
BR8.3
GDPR
60
CRM
UC1
BR1.13
Commissies
30
BR1.17
Waardeverlies
70
BR1.19
Afromen Slapende munten
40
BR1.2
Spender transacties
100
BR1.23
goed gedrag vs lokale economie
90
BR1.3
Spender(+Collector) Saldo
100
BR1.5
Overzicht
80
BR1.6
cadeaubonnen
30
BR1.7
gratis parkeren
20
BR1.9
Limiet van donor
60
UC3
BR3.1
Donor Registratie
100
BR3.2
Handelaar Registratie
100
BR3.3
Burger Registratie
100
BR3.4
Burger Promo Participatie
100
BR3.5
Anonieme Test Registratie
20
BR3.7
e-inclusie
60
UC4
BR4.1
Doelgroepen
21
BR4.2
Targeting
30
BR4.3
Acquisitie
30
BR4.4
Communicatie
6
UC10
BR10.1
Standaard Antwoorden
28
BR10.2
FAQ
28
BR10.3
Klachten
28
BR10.4
Reviews
12
BR10.5
Inzichten
16
Data Explorer
UC2
BR2.1
Integratie Applicaties
70
BR2.3
op mijnburgerprofiel
21
UC3
BR3.7
e-inclusie
60
UC7
BR7.1
Integratie nieuwe stad of gemeente
60
BR7.2
Integratie Applicatie
60
BR7.3
OSLO standaarden
48
Datawarehousing
UC7
BR7.5
AML en KYC
48
Derdebetalerssysteem
UC1
BR1.1
Donor transacties
100
BR1.11
Validatie 'goede doel' collector
20
BR1.12
Inzichten
40
BR1.13
Commissies
30
BR1.15
QR of andere 'bonnen'
70
BR1.16
Gecombineerde munten
70
BR1.17
Waardeverlies
70
BR1.18
Waarde Fluctuaties?
20
BR1.19
Afromen Slapende munten
40
BR1.2
Spender transacties
100
BR1.20
punten vs munten
30
BR1.21
Acties ipv munten of punten
20
BR1.23
goed gedrag vs lokale economie
90
BR1.3
Spender(+Collector) Saldo
100
BR1.4
betaling
80
BR1.5
Overzicht
80
BR1.6
cadeaubonnen
30
BR1.7
gratis parkeren
20
BR1.8
Regels en Rechten
100
BR1.9
Limiet van donor
60
ERP
UC1
BR1.1
Donor transacties
100
BR1.11
Validatie 'goede doel' collector
20
BR1.12
Inzichten
40
BR1.13
Commissies
30
UC3
BR3.1
Donor Registratie
100
BR3.2
Handelaar Registratie
100
BR3.3
Burger Registratie
100
BR3.5
Anonieme Test Registratie
20
UC5
BR5.1
Donatie
100
BR5.2
Verzilvering
100
BR5.3
NBB Licentie
70
UC9
BR9.1
Automatische terugvloeing
15
UC11
BR11.1
Handelaars
40
BR11.2
Shopper
40
BR11.3
Fraudebestrijding
28
BR11.5
Domiciliering/doorlopende opdrachten
8
BR11.6
Overschrijvingen
8
ETL
UC2
BR2.1
Integratie Applicaties
70
BR2.3
op mijnburgerprofiel
21
UC3
BR3.7
e-inclusie
60
UC7
BR7.1
Integratie nieuwe stad of gemeente
60
BR7.2
Integratie Applicatie
60
BR7.3
OSLO standaarden
48
Strategic Mgt Tool
UC6
BR6.1
Impact campagne
32
BR6.2
ROI berekening
32
BR6.3
Rapportage
20
BR6.4
Drill Down
20
BR6.5
Churn Prediction
12
BR6.6
Forecasten
16
UC7
BR7.1
Integratie nieuwe stad of gemeente
60
BR7.4
herbruikbare munten
36
BR7.5
AML en KYC
48
UC8
BR8.1
Uitrol / implementatie
60
BR8.2
Nieuwe ontwikkeling
48
BR8.3
GDPR
60
Objectieve criteria
De objectieve criteria worden beschreven in de functionele specificaties. Voor een gedetailleerde beschrijving van deze functionele specificaties, verwijzen we naar de laatste versie van het VLOCA-model.
Minimale criteria
Het voldoen aan de minimale criteria wordt berekend aan de hand van de kolom Weging en Checklist. De minimumwaarde om als essentieel beschouwd te worden is vrij te bepalen door de aanbesteder. Alle scores van bijvoorbeeld minimaal 50 beschouwen we als noodzakelijk ter uitvoering van het desbetreffend perceel. Alle specificaties met een weging die de aan de minimumwaarde voldoet, dienen uitvoerbaar te zijn.
Selectiecriteria
Om de selectie te faciliteren, wordt een score berekend op basis van de minimale criteria vermenigvuldigd met de waarde in de weging. De totale score per perceel wordt berekend en gedeeld door de totale waarden in de weging voor dat perceel om zo tot een percentage te komen.
Perceel
Use Case
ID
Functionele specificaties
Weging
Checklist
Minimale criteria
Selectiecriteria
Formule
Resultaat
Formule
Resultaat
Perceel 1
UC1
1.1
Specificatie 1
70
Ja
Checklist = Ja --> 1 Weging <50 --> 1 Weging >= 50 en Checklist = Nee --> 0
1
Minimale criteria x Weging
70
1.2
Specificatie 2
42
Nee
1
42
1.3
Specificatie 3
21
Ja
1
21
UC2
2.1
Specificatie 4
60
Nee
0
0
2.2
Specificatie 5
60
Ja
1
60
2.3
Specificatie 6
60
Ja
1
60
2.4
Specificatie 7
48
Ja
1
48
Totaal
Som van alle resultaten selectiecriteria perceel / som van alle wegingen perceel
83 %
Er wordt ook een totale weging gemaakt waar alle functionele specificaties van alle percelen worden berekend.
Gunningscriteria
Een inschrijving wordt positief ontvangen wanneer bijvoorbeeld een score 50 % wordt behaald voor alle percelen en score van 75 % voor de totaliteit van de functionele specificaties.
Applicatiecomponent
ID
Functionele specificaties
Weging
Checklist
API Management
BR1.1
Activatie
80
JA/NEE
BR1.2
interactief
70
JA/NEE
BR1.3
QR ea
40
JA/NEE
BR1.5
Continuiteit via QR code
60
JA/NEE
BR1.6
Roterende visualisatie
90
JA/NEE
BR2.11
Externe APIs
80
JA/NEE
BR2.14
Flash Campagnes
80
JA/NEE
BR2.7
Marketing
60
JA/NEE
BR2.8
Visualisatie
80
JA/NEE
BR2.9
Rapportage
80
JA/NEE
BR3.1
templates
63
JA/NEE
BR3.10
Sharing
36
JA/NEE
BR3.11
Previews
54
JA/NEE
BR3.12
perso templates
72
JA/NEE
BR3.2
prijs setting
81
JA/NEE
BR3.3
Registratie
81
JA/NEE
BR3.4
Website vs App
54
JA/NEE
BR3.5
Recrutering
72
JA/NEE
BR3.6
Voorstel Segmentatie
63
JA/NEE
BR3.7
Special Request
63
JA/NEE
BR3.8
referendum'
54
JA/NEE
BR3.9
Via mob/desktop app
BR4.1
passanten
15
JA/NEE
BR4.2
viewers
15
JA/NEE
BR4.3
profile of viewers
6
JA/NEE
BR4.4
ROI Beleidscampagnes
18
JA/NEE
BR4.5
AB Testen
6
JA/NEE
BR4.7
% Schermtijd
18
JA/NEE
BR5.1
OSLO
64
JA/NEE
BR5.2
Andere Steden
64
JA/NEE
Artificial Intelligence
BR2.15
uitsluiting (gratis vs subscription vs campagne grp vs...)
90
JA/NEE
BR2.3
facturatie
80
JA/NEE
BR2.6
controle ethiek
100
JA/NEE
BR2.8
Visualisatie
80
JA/NEE
BR3.6
Voorstel Segmentatie
63
JA/NEE
BR4.3
profile of viewers
6
JA/NEE
BR4.4
ROI Beleidscampagnes
18
JA/NEE
BR4.5
AB Testen
6
JA/NEE
BR4.6
Segmentatie per periode
15
JA/NEE
BR6.7
Advies of suggesties binnen aanvraag
24
JA/NEE
Business Intelligence
BR2.3
facturatie
80
JA/NEE
BR2.8
Visualisatie
80
JA/NEE
BR2.9
Rapportage
80
JA/NEE
BR4.1
passanten
15
JA/NEE
BR4.2
viewers
15
JA/NEE
BR4.4
ROI Beleidscampagnes
18
JA/NEE
BR4.5
AB Testen
6
JA/NEE
BR4.6
Segmentatie per periode
15
JA/NEE
BR4.7
% Schermtijd
18
JA/NEE
BR6.3
GDPR
64
JA/NEE
BR6.4
Historiek
24
JA/NEE
CRM
BR2.10
Communicatie
70
JA/NEE
BR2.15
uitsluiting (gratis vs subscription vs campagne grp vs...)
90
JA/NEE
BR6.1
Contact info
40
JA/NEE
BR6.2
Opt in Opt out
40
JA/NEE
BR6.3
GDPR
64
JA/NEE
BR6.4
Historiek
24
JA/NEE
BR6.5
Automatische Bevestiging
48
JA/NEE
BR6.6
Weigering van aanvraag
48
JA/NEE
BR6.7
Advies of suggesties binnen aanvraag
24
JA/NEE
BR6.8
interesses & permissies
16
JA/NEE
BR7.1
Specifieke Problemen
40
JA/NEE
BR7.10
Handleiding
24
JA/NEE
BR7.2
Inzichten
16
JA/NEE
BR7.3
Indicatoren van issues
40
JA/NEE
BR7.4
Proactieve Communicatie
48
JA/NEE
BR7.7
Reviews handelaars
24
JA/NEE
BR7.8
Reviews wandelaars
24
JA/NEE
Data Explorer
BR2.3
facturatie
80
JA/NEE
BR2.8
Visualisatie
80
JA/NEE
BR2.9
Rapportage
80
JA/NEE
BR4.1
passanten
15
JA/NEE
BR4.2
viewers
15
JA/NEE
BR4.4
ROI Beleidscampagnes
18
JA/NEE
BR4.5
AB Testen
6
JA/NEE
BR4.6
Segmentatie per periode
15
JA/NEE
BR4.7
% Schermtijd
18
JA/NEE
BR6.3
GDPR
64
JA/NEE
BR6.4
Historiek
24
JA/NEE
BR6.7
Advies of suggesties binnen aanvraag
24
JA/NEE
Datawarehousing
BR2.15
uitsluiting (gratis vs subscription vs campagne grp vs...)
90
JA/NEE
BR2.3
facturatie
80
JA/NEE
BR2.8
Visualisatie
80
JA/NEE
BR2.9
Rapportage
80
JA/NEE
BR4.1
passanten
15
JA/NEE
BR4.2
viewers
15
JA/NEE
BR4.4
ROI Beleidscampagnes
18
JA/NEE
BR4.5
AB Testen
6
JA/NEE
BR4.6
Segmentatie per periode
15
JA/NEE
BR4.7
% Schermtijd
18
JA/NEE
BR5.1
OSLO
64
JA/NEE
BR5.2
Andere Steden
64
JA/NEE
ERP
BR2.15
uitsluiting (gratis vs subscription vs campagne grp vs...)
90
JA/NEE
BR2.3
facturatie
80
JA/NEE
BR3.11
Previews
54
JA/NEE
BR3.2
prijs setting
81
JA/NEE
BR3.3
Registratie
81
JA/NEE
BR3.5
Recrutering
72
JA/NEE
BR3.6
Voorstel Segmentatie
63
JA/NEE
BR3.7
Special Request
63
JA/NEE
ETL
BR2.15
uitsluiting (gratis vs subscription vs campagne grp vs...)
90
JA/NEE
BR2.3
facturatie
80
JA/NEE
BR2.8
Visualisatie
80
JA/NEE
BR2.9
Rapportage
80
JA/NEE
BR4.1
passanten
15
JA/NEE
BR4.2
viewers
15
JA/NEE
BR4.4
ROI Beleidscampagnes
18
JA/NEE
BR4.5
AB Testen
6
JA/NEE
BR4.6
Segmentatie per periode
15
JA/NEE
BR4.7
% Schermtijd
18
JA/NEE
Physical Media Channel
BR1.1
Activatie
80
JA/NEE
BR1.2
interactief
70
JA/NEE
BR1.3
QR ea
40
JA/NEE
BR1.4
Sensoren & metingen
60
JA/NEE
BR1.5
Continuiteit via QR code
60
JA/NEE
BR1.6
Roterende visualisatie
90
JA/NEE
Sensoren
BR1.4
Sensoren & metingen
60
JA/NEE
Media Management
BR2.1
Regels
80
JA/NEE
BR2.10
Communicatie
70
JA/NEE
BR2.11
Externe APIs
80
JA/NEE
BR2.12
Users Rights
70
JA/NEE
BR2.13
QR code
60
JA/NEE
BR2.14
Flash Campagnes
80
JA/NEE
BR2.15
uitsluiting (gratis vs subscription vs campagne grp vs...)
90
JA/NEE
BR2.2
Roteringsplanning
80
JA/NEE
BR2.3
facturatie
80
JA/NEE
BR2.4
templates
50
JA/NEE
BR2.5
richtlijnen
100
JA/NEE
BR2.6
controle ethiek
100
JA/NEE
BR2.7
Marketing
60
JA/NEE
BR2.8
Visualisatie
80
JA/NEE
Master Data Management
BR2.15
uitsluiting (gratis vs subscription vs campagne grp vs...)
90
JA/NEE
BR2.3
facturatie
80
JA/NEE
BR2.8
Visualisatie
80
JA/NEE
BR2.9
Rapportage
80
JA/NEE
BR4.1
passanten
15
JA/NEE
BR4.2
viewers
15
JA/NEE
BR4.4
ROI Beleidscampagnes
18
JA/NEE
BR4.5
AB Testen
6
JA/NEE
BR4.6
Segmentatie per periode
15
JA/NEE
BR4.7
% Schermtijd
18
JA/NEE
BR5.1
OSLO
64
JA/NEE
BR5.2
Andere Steden
64
JA/NEE
Design & Editing Management
BR3.1
templates
63
JA/NEE
BR3.11
Previews
54
JA/NEE
BR3.12
perso templates
72
JA/NEE
BR3.8
referendum'
54
JA/NEE
Backoffice Management
BR7.2
Inzichten
16
JA/NEE
BR7.3
Indicatoren van issues
40
JA/NEE
BR7.4
Proactieve Communicatie
48
JA/NEE
BR7.6
FAQ
32
JA/NEE
BR7.7
Reviews handelaars
24
JA/NEE
BR7.9
FAQ Gebruik
16
JA/NEE
Frontoffice Management
BR7.1
Specifieke Problemen
40
JA/NEE
BR7.10
Handleiding
24
JA/NEE
BR7.2
Inzichten
16
JA/NEE
BR7.3
Indicatoren van issues
40
JA/NEE
BR7.4
Proactieve Communicatie
48
JA/NEE
BR7.7
Reviews handelaars
24
JA/NEE
BR7.9
FAQ Gebruik
16
JA/NEE
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 Smart Innovation Factory – Mechelen
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 ?
Maximale waarde creaties door verschillende stakeholders op beschikbare databronnen (bestaande of potentieel beschikbaar, open of gesloten, gratis of betalend, dekkend/extrapollaties, ownership vraagstuk,...)
Missie
Voorstel
Wat willen we bereiken ?
Inzichten over hoe de vraag en aanbod van open data kunnen afstemmen op elkaar, alsook het opzetten van een 'Smart Innovation Factory' die innovaties stimuleert vanuit een datagedreven perspectief.
Doel
Voorstel
Wat is het doel van dit project ?
1.Via exploratieve verkennende marktstudie overzicht van de vragende partijen voor open data binnen de quadruple helix, alsook de bestaande en potentiele bronnen van open data in kaart te brengen. 2.Bouwen van een 'innovatie' incubator in de regio rivierenland. 3.Een paar innovatie stimulerende usecases uitwerken met focus op thema klimaat en energie
Succesfactor
Voorstel
Hoe meten we succes ? (SMART)
Aantonen van concrete innovaties geleverd dankzij het delen van data via de Smart Innovation Factory
Use cases
ID
Status
Samenvatting
Beschrijving
UC1
Voorstel
UC1
Overzicht via een 'segmentatie' van entiteiten (instituten, bedrijven, organisaties, individuen,...) die de vraag in kaart brengt. De vraag moet gevaloriseerd worden in 'intensiteit' en dus ook in 'bereidheid te betalen'.
UC2
Voorstel
UC2
Overzicht via een typologie van data elementen die reeds of mogelijks in de toekomst kan aangeboden worden door de 'overheid' of andere partijen binnen de quadruple helix.
UC3
Voorstel
UC3
Overzicht van de 'affiniteit' tussen de 'behoefte' segmentatie met de 'typologien' van open data (bronnen). =Matrix Segmenten tov open data typologien.
UC4
Voorstel
UC4
Een platform die innovatie vanuit de bestaande databronnen mogelijk maakt. Het is een wisselwerking iteratief 'top down' en 'bottom up' proces, die kijkt naar wat er bestaat en hoe dit kan leiden tot economische en maatschappelijke innovaties. (niet: the sky is the limit brainstorm sessies)
UC5
Voorstel
UC5
Bibliotheek van draaiboeken per typologie van data (= productgedreven), per behoefte segment (= klantgedreven) en per 'innovatie' traject.
UC6
Voorstel
UC6
Een piloot data marktplaats laten bouwen en co-beheren waar de vraag en aanbod elkaar tegenkomen. Die marktplaats moet innovaties stimuleren en draagt dit ook in zijn kernbestaan. (Zonder innovaties en economische waarde = business development (geen piloot projectjes, geen puur onderzoeksomgeving) heeft dit geen bestaansredenen).
UC7
Voorstel
UC7
De factory moet gemakkelijk connecteerbaar zijn met andere dataspaces initiatieven primair in de regio rivierenland en bij uitbreiding gans Vlaanderen en buiten. (Dataspaces principe)
Metadata
Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases
ID
Type
Samenvatting
Beschrijving
UC1
Use case
UC1
Overzicht via een 'segmentatie' van entiteiten (instituten, bedrijven, organisaties, individuen,...) die de vraag in kaart brengt. De vraag moet gevaloriseerd worden in 'intensiteit' en dus ook in 'bereidheid te betalen'.
BC1.1
Business capability
Hoe groot is de vraag naar open data in aantal 'Entiteiten', intensiteit van de behoefte, bereidheid te betalen, welke type van data, frequentie, minimum kwaliteit, ed meer.
BC1.2
Business capability
Welke behoefte gebaseerde segmenten (Needs Based Segmentation) bestaan er in de quadruple helix die homogeen dezelfde behoeften hebben binnen de segmenten en heterogeen anders zijn tussen de segmenten.
ID
Type
Samenvatting
Beschrijving
UC2
Use case
UC2
Overzicht via een typologie van data elementen die reeds of mogelijks in de toekomst kan aangeboden worden door de 'overheid' of andere partijen binnen de quadruple helix.
BC2.1
Business capability
Welke zijn de verschillende databronnen die reeds bestaan en wat is hun 'specificiteit' die een behoefte kan beantwoorden
BC2.2
Business capability
Welke zijn de verschillende potentiele databronnen die nog 'ontgonnen' kunnen worden met hun specificiteit
BC2.3
Business capability
Welke zijn de 'typologien' die de verschillende databronnen groeperen/clusteren die homogeen binnen en heterogeen tussen de groepen zijn.
ID
Type
Samenvatting
Beschrijving
UC3
Use case
UC3
Overzicht van de 'affiniteit' tussen de 'behoefte' segmentatie met de 'typologien' van open data (bronnen). =Matrix Segmenten tov open data typologien.
BC3.1
Business capability
Lijst van alle data (typologien) die een behoefte van een segment beantwoord.
BC3.2
Business capability
Matrix die de affiniteit van de segmenten naar de data typologien visualiseert om daarmee een 'marketing', 'strategische' en 'operationeel' plan te kunnen uittekenen.
ID
Type
Samenvatting
Beschrijving
UC4
Use case
UC4
Een platform die innovatie vanuit de bestaande databronnen mogelijk maakt. Het is een wisselwerking iteratief 'top down' en 'bottom up' proces, die kijkt naar wat er bestaat en hoe dit kan leiden tot economische en maatschappelijke innovaties. (niet: the sky is the limit brainstorm sessies)
BC4.1
Business capability
Bevatten/Capteren van de 'probleemstellingen' per sector (met focus op energie en klimaat). De huidige noden, beperkingen en manier van werken.
ID
Type
Samenvatting
Beschrijving
UC5
Use case
UC5
Bibliotheek van draaiboeken per typologie van data (= productgedreven), per behoefte segment (= klantgedreven) en per 'innovatie' traject.
BC5.1
Business capability
Per databron een 'draaiboek' terugvinden die uitlegt hoe die data te capteren, verwerken, opslaan en ontsluiten voor een bepaalde segment behoefte
BC5.2
Business capability
Per Segment behoefte, een 'draaiboek' terugvinden die uitlegt welke databronnen er moet 'ontgonnen' worden om zo de behoefte te kunnen invullen.
BC5.3
Business capability
Draaiboek van hoe een lokale 'innovatie' platform te bouwen
ID
Type
Samenvatting
Beschrijving
UC6
Use case
UC6
Een piloot data marktplaats laten bouwen en co-beheren waar de vraag en aanbod elkaar tegenkomen. Die marktplaats moet innovaties stimuleren en draagt dit ook in zijn kernbestaan. (Zonder innovaties en economische waarde = business development (geen piloot projectjes, geen puur onderzoeksomgeving) heeft dit geen bestaansredenen).
BC6.1
Business capability
Het gemakkelijk/transparant kunnen ontsluiten van data (of andere assets zoals componenten, schema's, vocabularium, ed) in de marktplaats
BC6.2
Business capability
Publiceren van metadata in lijn met internationale standaarden zoals DCAT
BC6.3
Business capability
Transparant publiceren van de 'afkomst'/'Lineage'/'Callibraties'/Intrapollaties en Extrapollaties/enz.
BC6.4
Business capability
Publicatie van of verwijzen naar schema en semantiek
BC6.5
Business capability
Publiceren van de transport schema waarmee de data beschikbaar is (http, mqtt, ftp,...)
BC6.6
Business capability
Het kunnen factureren van de data downloads a priori of a posteriori
BC6.7
Business capability
Wat is de 'inhoudelijke' metadata van de verschillende beschikbare databronnen (via DCAT ?)
BC6.8
Business capability
Het kunnen toegang verlenen via toegansbeheer platform afhankelijk van de gebruikersrechten
BC6.9
Business capability
Reviews en feedback kunnen geven op die data (vanuit de gebruiker)
BC6.10
Business capability
Notificaties wanneer data geupdate werden
BC6.11
Business capability
Het registreren van transacties (= clearinghouse + voor inzichten op statistieken)
BC6.12
Business capability
Access controle
BC6.13
Business capability
Moet gebruik kunnen maken van derde identiteits providers (it's me,...)
BC6.14
Business capability
CRM communicatie and marketing en verkoopsplanning
BC6.15
Business capability
Betalingsmogelijkheden
BC6.16
Business capability
Prijs structuur opstellen en publiceren
BC6.17
Business capability
Publiceren van gebruiksrechten van data (alsook een open data charter waar de aanbieders en gebruikers zich moeten houden)
BC6.18
Business capability
Een 'google' manier (search engine) om data terug te vinden.
BC6.19
Business capability
Een visuele manier om data te categoriseren of behoeften te segmenteren.
BC6.20
Business capability
Moet passen in een gefedereerde netwerk van catalogi (ref. dataspaces)
BC6.21
Business capability
Zoeken naar potentiele co-beheerders van de SIF
BC6.22
Business capability
Aanbesteding van het bouwen van de SIF
BC6.23
Business capability
Uitwerken van een 'innovatie' methodologie (meerdere ?, per thema ?) voor het functioneren van SIF
ID
Type
Samenvatting
Beschrijving
UC7
Use case
UC7
De factory moet gemakkelijk connecteerbaar zijn met andere dataspaces initiatieven primair in de regio rivierenland en bij uitbreiding gans Vlaanderen en buiten. (Dataspaces principe)
BC7.1
Business capability
Wie zijn de relevante betrokken partijen uit de quadruple helix
BC7.2
Business capability
Zoeken naar de bestaande Dataspaces met relevantie naar de SIF
BC 7.3
Business capability
Organiseren van live of digitale communicatie tussen de partijen (innovatie workshops, overlegmomenten, newsletters, conferenties, webinars, enz.). Niet :overload aan hackatons.