Op eigenschap zoeken

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

Lijst van resultaten

+
+++ Pagina is in aanmaak +++ +
0 +
20210311 VLOCA traject mobiliteit WS2 +
20210311 VLOCA traject mobiliteit WS2 Stemmingen +
3D ref architectuur +
5-star open data [1] ↑ https://5stardata.info/en/ +
<img src="/logo/Logo.svg" id="img_logo" /> +
@ Example +
A book ontology +
A knowledge describing books and their relationships +
AP led +
API led +
API-led +
"Cross-Cutting" is een adjectief dat gebru … "Cross-Cutting" is een adjectief dat gebruikt wordt om aan te geven dat bepaalde aspecten of functionaliteiten een impact hebben op verschillende onderdelen van het systeem, en dus niet beperkt zijn tot bijvoorbeeld 1 component of 1 stuk code. Deze "Cross-cutting Concerns" of Transversale aandachtspunten moeten dus globaal beheerd worden over alle aspecten en componenten van een systeem of architectuur. Een typisch voorbeeld is veiligheid, aangezien binnen geconnecteerde systemen elk onderdeel een mogelijke zwakke schakel kan zijn in de beveiliging van het geheel. We spreken bij geconnecteerde smart city systemen over een groot "gevaar oppervlak": gezien alle componenten op de een of andere manier geconnecteerd zijn en fysiek gezien op andere plaatsen kunnen uitgerold worden, "snijdt" het aspect veiligheid doorheen het volledige systeem en moet dit dus globaal bekeken worden. Meer informatie is te vinden op Wikipedia [1] ↑ https://en.wikipedia.org/wiki/Cross-cutting_concernipedia.org/wiki/Cross-cutting_concern +
"Smart environment" omvat slimme energie, … "Smart environment" omvat slimme energie, waaronder hernieuwbare energie, ICT -enabled energienetten, "metering", monitoring en controle van vervuiling, renovatie van gebouwen en voorzieningen, groene gebouwen, groene stedelijke planning, evenals efficiënt gebruik van hulpbronnen, hergebruik en vervanging van hulpbronnen die de bovenstaande doelen dient. Stedelijke diensten zoals straatverlichting, afvalbeheer, drainagesystemen en waterbronnen die worden gemonitord om het systeem te evalueren, vervuiling te verminderen en de waterkwaliteit te verbeteren, zijn ook goede voorbeelden. Volgens [1] horen hier ook in thuis : stedelijke omgeving afval beheer energie water ↑ https://aioti.eu/wp-content/uploads/2018/06/AIOTI-WG08-Smart-City-Replication-Guidelines-Part-1-Cross-Domain-Use-Cases-V1.0-with-new-logo.pdfases-V1.0-with-new-logo.pdf +
TypeNieuws Datum De ontwikkeling van d … TypeNieuws Datum De ontwikkeling van de Brugse Digital Twin: een verhaal uit de praktijk Nieuwsbericht 2022-10-27 VLOCA en de Vlaamse lokale besturen, een stand van zaken Nieuwsbericht 2022-06-28 Aankoop van data, een prioriteit voor lokale besturen? Nieuwsbericht 2022-06-24 Plaatsing van sensoren als eerste stap naar slim ecosysteem in en om de stad Mechelen Nieuwsbericht 2022-03-30ad Mechelen Nieuwsbericht 2022-03-30 +
(Deze richtlijnen worden momenteel opgemaa … (Deze richtlijnen worden momenteel opgemaakt in een co-creatie proces. Aanbeveling dus onder voorbehoud. Deze worden momenteel geregeld geüpdatet. Naar het einde van 2021 toe worden deze richtlijnen gefinaliseerd) Voor het kiezen van een geschikte sensor zien we 2 subvragen: Hoe kies ik een geschikte sensor voor meten van parameter X? Kan de sensor deze parameter meten? Meetprincipe Sommige parameters kunnen op verschillende wijze (meettechniek) gemeten worden. Meetprincipes vergelijken: voor-/nadelen, meer/minder geschikt voor bepaalde condities/omstandigheden. Vb. meting van het waterpeil : hydrostatische meting (druk), ultrasone meting (echo sounding), laser, radar, optisch,… Meetbereik (range): van… tot… Resolutie (resolution): kleinste stap/eenheid van die gedetecteerd kan worden Soms varieert de resolutie over het meetbereik. Aantal decimalen is niet noodzakelijk gelijk aan resolutie, vb. meting in m met 3 decimalen, maar resolutie is 2mm. Nauwkeurigheid (accuracy): meetfout, afwijking t.o.v. werkelijke waarde Nauwkeurigheid kan absoluut of relatief (% tov de meetwaarde) uitgedrukt worden. vb. nauwkeurigheid 1cm of nauwkeurigheid +/- 0.1% van de meetwaarde Geïntegreerde correcties Vb. temperatuur correct voor parameters die temperatuurgevoelig zijn. Vb. luchtdrukcompensatie bij hydrostatische waterpeilmeting. Combinatie van een aantal parameters op eenzelfde sensor Hoe kies ik een geschikte sensor voor de beoogde toepassing? Parameter(s) Meetprincipe Meetbereik, resolutie, nauwkeurigheid Geïntegreerde correcties Meetfrequentie en (remote) aanpasbaarheid van meetfrequentie Kabellengte : indien van toepassing bv. voor ophanging, datacommunicatie, luchtdrukcompensatie, … Toegelaten waterdruk : hoe diep mag de sensor onder water hangen Bestendigheid tegen droogval : indien van toepassing voor beoogde meetlocaties Bestendigheid tegen vorst : indien van toepassing voor beoogde meetlocaties Bestendigheid tegen vandalisme : indien van toepassing voor beoogde meetlocaties Algemene robuustheid :beperkt onderhoud en kalibratie Energieverbruik en autonomie : hoe lang kan de sensor meten met een bepaalde frequentie met de voorziene energiebron: is een batterij voldoende of extra zonnepaneel te voorzien? Dimensies en gewicht (i.f.v. installatie en ophanging) On-site uitlezing van de metingen (indien gewenst/nodig) Waterdichtheid bij hogere waterdruk (diepte in waterkolom) Modulair systeem : is er uitbreiding mogelijk, bv. extra parameters. Hierbij is een afweging van criteria/vereisten ten opzichte van budget (aankoop + installatie + onderhoud) belangrijk. Onderhoud en levensduur van sensoren Onderhoud en kosten/inspanningen voor onderhoud Het onderhoud van sensoren heeft een kostprijs die veelal uit het oog wordt verloren. Sensoren, die geen of slechte metingen geven omdat ze niet onderhouden worden, zijn een verloren investering. Onderhoudsintensiteit en gevoeligheid van sensor voor vervuiling wordt vooral bepaald door het type parameter (en bijhorend meetprincipe) en de matrix waarin je meet. Bijvoorbeeld, metingen in zoutwater of afvalwater vereisen vaak meer onderhoud. Het type water waarin je meet (afvalwater vs. drinkwater) is daarom bepalend voor de keuze sensor. Kosten/inspanningen van onderhoud zijn situatiespecifiek waardoor het moeilijk is om een algemene raming te maken. Belangrijke factoren in onderhoudskost zijn o.a.: verplaatsing (tijd en afstand) om sensoren te gaan onderhouden toegankelijkheid van de locatie vereiste onderhoudsfrequentie (sensor/parameter/locatie afhankelijk) intensiteit/omvang van onderhoudshandelingen (sensor/parameter/locatie afhankelijk) Levensduur van de sensor en beschikbaarheid van reserve onderdelen Er kan een onderscheid gemaakt worden tussen: type ‘wegwerp sensoren’ met een, door de frabrikant, opgegeven gebruikstermijn, bv. 6 maanden en dan vervangen type ‘compacte, relatief goedkope sensoren’ waarbij herstellen van een defect vaak niet de moeite is t.o.v. vervanging door een nieuwe sensor. Zonder defect kunnen dergelijke sensoren meerdere jaren worden gebruikt. type ‘multi-parameter sensoren’ waarbij sommige onderdelen een beperkte levensduur hebben en waarvoor vervangstukken beschikbaar zijn bij de fabrikant vervangen van sommige onderdelen is te beschouwen als een onderhoudskost, bv. vervangen van membranen of sensortippen de sensor zelf (met name de elektronica) kan vele jaren gebruikt worden Hoe kies ik een geschikte sensor ? Samengevat kan gesteld worden dat om een geschikte sensor te kiezen aandacht gegeven moet worden aan volgende: goed informeren over technische specificaties en het meetprincipe van de sensor informeren naar ervaringen, testen, reviews of feedback expliciet voordelen en nadelen vragen aan fabrikant/verkoper hoe beter je de condities van de toepassing kent en kan specifiëren, hoe beter de keuze afgestemd is op de toepassing indien je een breed inzetbare sensor wenst, zullen criteria/afwegingen anders zijn +
(Deze richtlijnen worden momenteel opgemaa … (Deze richtlijnen worden momenteel opgemaakt in een co-creatie proces. Aanbeveling dus onder voorbehoud. Deze worden momenteel geregeld geüpdatet. Naar het einde van 2021 toe worden deze richtlijnen gefinaliseerd) Criteria/aspecten om aantal sensoren en locaties te bepalen doelstelling : wat wil je meten? omvang van het gebied gewenst ruimtelijk detail niveau (hoe meer → hoe beter) hydrologisch systeem (bv. waar zijn cruciale/grote/belangrijke veranderingen te verwachten) beschikbaar budget en prijs van de beoogde sensor (zie sensor criteria) waar verwacht je ruimtelijke verschillen ? (bv. op basis van schepstalen) op welke locaties/zones verwacht je (hoge) temporele variatie ? (daar is de toegevoegde waarde van sensoren het grootste) combineren van locaties met schepstalen en locaties met sensoren (zie vorig criterium) leidt tot een gericht gedifferentieerde ruimtelijke dekking in specifieke omstandigheden of bij specifieke doelstellingen: sensoren op verschillende diepte en/of op verschillende positie in cross-sectie energievoorziening (electriciteit, batterij, zonnepanelen) toegankelijkheid en bereikbaarheid vegetatie (hinder/onderhoud) vergunningen en toelatingen risico op diefstal/vandalisme (mogelijkheid tot beveiliging) connectiviteit voor datacommunicatie Hierbij is een afweging van criteria/vereisten t.o.v. budget (aankoop + installatie + onderhoud) belangrijk! Praktische tips & tricks Meestal is het een goede aanpak om: te starten met meer locaties aan te duiden vervolgens prioriteiten toe te kennen en criteria af te wegen en vervolgens te optimaliseren Het is ook nuttig om wat ‘back-up locaties’ te hebben indien sommige gewenste locaties praktisch niet haalbaar of moeilijk blijken. Een getrapte aanpak is ook mogelijk, waarbij je o.b.v. sensoren op een beperkt aantal locaties een beter inzicht verkrijgt over het systeem en de ruimtelijk variabiliteit en je dit vervolgens gebruikt om extra locaties toe te voegen. +
(Deze richtlijnen worden momenteel opgemaa … (Deze richtlijnen worden momenteel opgemaakt in een co-creatie proces. Aanbeveling dus onder voorbehoud. Deze worden momenteel geregeld geüpdatet. Naar het einde van 2021 toe worden deze richtlijnen gefinaliseerd) Criteria/aspecten voor keuze datacommunicatie en logging frequentie datatransmissie , (remote) aanpasbaarheid van frequentie realtime voor bepaalde toepassingen: vb. overstromingen, RWZI, overstorten uurlijkse of dagelijkse data doorsturen: vb. droogte-monitoring optimalisatie door dynamische aanpassing van meetfrequentie of zendfrequentie (vb. overschrijding van grenswaarde, bij een specifiek event of alarm) energieverbruik en autonomie : Hoe lang kan de device data verzenden met een bepaalde frequentie en met de voorziene energiebron? Is een batterij voldoende of is het nodig om een extra zonnepaneel te voorzien? data logging : opslagcapaciteit datacommunicatie technologie zie extra info dekking (coverage) voor communicatie/transmissie: te controleren voor de beoogde locaties geschiktheid voor beoogde toepassing: outdoor of indoor? open ruimte of tussen bebouwing? bovengronds of ondergronds ? → mogelijks extra lokale gateways nodig voor indoor/ondergronds/dichte bebouwing type van remote communicatie/interactie (service): one-way / two-way dimensies en gewicht (i.f.v. installatie en bevestiging) vochtbestendigheid (IP normering) → afhankelijk van de locatie of de condities bv. overstromingsbestendigheid on-site uitlezing van de data (indien gewenst nodig) geschikte connector voor aansluiting van gewenste/beoogde sensor en compatibiliteit met beoogde sensor Hierbij is een afweging van criteria/vereisten t.o.v. budget (aankoop + telecom kosten + nodige IT infrastructuur) belangrijk! In de overleg pagina kunnen ervaringen m.b.t. de verschillende netwerken gedeeld worden (NB-Iot, LoRaWAN, Sigfox). +
+++ Deze pagina is in opmaak/ontwikkeling … +++ Deze pagina is in opmaak/ontwikkeling +++ Doel en doelgroep +++ Deze tekst is in opmaak +++ Inleiding +++ Deze tekst is in opmaak +++ Kadering +++ Deze tekst is in opmaak +++ Definitie Het Broker segment biedt technische capaciteiten aan die kaderen binnen het beheer van (meta) data. Data vindbaar maken via een catalogus is een sleutel capaciteit van een data plaform. Daarin moet niet alleen de locatie van een service te vinden zijn om die data te kunnen bevragen, maar ook metadata rond de betekenis van de data, het formaat, de evolutie, eventueel de lineage, .... Ook catalogi rond componenten uit de verschillende segmenten die bijdragen aan de rijkheid van het platform (zoals modellen, data transformatie componenten, ...) zijn daarbij belangrijke elementen. Data schema's (hoe ziet het formaat van de data er uit) zijn belangrijk om zowel de syntax als de vorm bij te houden en te versioneren. Herbruikbare compomenten zoals models-as-a-sevice, koppelbare modellen, (RML) mappings, pipeline componenten, ... Kunnen hier ook beschreven worden zodat ze kunnen gebruikt worden als platform dienst. Dit segment speelt ook een heel belangrijke rol in de creatie van een virtual smart data platform. Zo is het bijvoorbeeld belangrijk om in een dataspace op een gemakkelijke manier toegang te krijgen tot databronnen uit verschillende data platformen. Een voorbeeld is het zoeken naar databronnen die luchtkwaliteit meten en die door verschillende organisaties kunnen aangeboden worden. Daarom is het belangrijk om ook hier te kiezen voor interoperabiliteit (bijvoorbeeld via Linked Data en RDF) voor het beheren en delen van data schema's en data betekenis. Bedrijfscontext en mogelijkheden +++ Deze tekst is in opmaak +++ Onderliggende componenten Tabel (via semantische links) Best practices bij selectie van componenten +++ Deze tekst is in opmaak +++ponenten +++ Deze tekst is in opmaak +++ +
+++ Deze pagina is in opmaak/ontwikkeling … +++ Deze pagina is in opmaak/ontwikkeling +++ Doelgroep en doel Inleiding Bij het uitschrijven van een marktbevraging of openbare aanbesteding, RFI, RFP of RFQ, is het nuttig om generieke bestekteksten te kiezen uit een bibliotheek, gerelateerd aan het onderwerp. Uiteraard zal het document nog verder aangepast worden ifv de lokale context, maar het overgrote deel kan hergebruikt worden. Doorheen de levenscyclus van VLOCA worden steeds meer bestekteksten gepubliceerd, volgens eenzelfde structuur, toepasbaar in grootstedelijke, kleinstedelijke, gemeentelijke of intergemeentelijke context. Ook hier geldt het principe: gebruik de tekst vrij, en doe verbeteringen op de kennishub zodat je collega's in andere lokale besturen er ook beter van worden. Voorstel voor een Kennishub pagina van deze deliverable Introductie (in welke kader werd deze bestektekst ontwikkeld, wat is de doelstelling van de bestektekst– ‘deze bestektekst kan jou/je organisatie helpen om ....’, met een concrete formulering en aangeven waar deze bestektekst voor kan gebruikt worden in het eigenlijke bestek – i.e. het technische gedeelte van een bestek) Criteria voor gebruik van de bestektekst (wie kan er optimaal gebruik maken van de bestektekst, voor wie zijn er aanpassingen nodig, voor wie is dit niet van toepassing?) Participatiemogelijkheden (beschrijft de mogelijkheid voor externen om bestekteksten aan te passen) Bestektekst (beschrijving van de input voor het technisch gedeelte van de bestek, op zo’n manier dat dit quasi onmiddellijk bruikbaar is in het eigenlijke bestek). Aanpak bij het ontwikkelingen van deze deliverable Stap 1: Scopebepaling Bepaal wat er precies dient beschreven te worden in de generieke bestektekst, wat het kader is van deze bestektekst. Bepaal wat de precieze nood is: waarom is het nodig dat er hier een bestektekst wordt over geschreven? Voor welke lokale overheden (of andere organisaties) zal deze bestektekst dienen? Lees de informatie door die het Agentschap Binnenlands Bestuur heeft opgemaakt over Overheidsopdrachten. Bespreek met de lokale overheid/overheden betrokken in het traject wat zij wensen als bestektekst. Stap 2: Beschrijf het technisch gedeelte Een bestektekst van VLOCA zal een inhoudelijke focus hebben, en aldus focussen op het technische gedeelte van een overheidsopdracht (zie hier) Start met het neerschrijven van de gedetailleerde opdracht, maar op zo’n manier dat andere gebruikers deze tekst zelf nog kunnen aanvullen (vb. vul geen specifieke data in, maar wel termijnen waarbinnen iets dient te gebeuren). Schrijf, na het finaliseren van de gedetailleerde opdracht, een meetstaat uit. Deze meetstaat moet toelaten aan de geïnteresseerde marktpartijen om een gedetailleerde prijszetting op te maken. Bepaal de metadata (wie is de specifieke doelgroep) aan de hand van Stap 1 en Stap 2. Stap 3 (optioneel): Gebruikerstest Toets de bestektekst, opgemaakt in Stap 2, uit met potentiële gebruikers (zowel uitstuurders als indieners). Mogelijkheden gebruikers: Lokale overheid/overheden betrokken in het traject, andere lokale overheden die sessies meevolgen, lokale overheden die zouden moeten voldoen aan de criteria voor de bruikbaarheid van de bestektekst etc. Mogelijkheden test: Stuur de bestektekst op voorhand door, organiseer een bespreking nadat de gebruiker het draaiboek heeft kunnen doornemen Stap 4: Bijsturing Analyseer de feedback van de gebruikerstest: Wat was positief? Wat dient bijgewerkt te worden? Herwerk de bestektekst op basis van de voorgaande analyse. Stap 5: Publicatie van de resultaten op de Kennishub aan de hand van hierboven beschreven voorstel. +
+++ Deze pagina is in opmaak/ontwikkeling … +++ Deze pagina is in opmaak/ontwikkeling +++ Doelgroep en doel Inleiding Binnen een thematische use case formuleren we in het VLOCA-model verschillende objectieven. Binnen elk objectief worden business capabilities uitgewerkt. De VLOCA-EA methode laat toe dat het projectbeheer van een lokale besturen de business capabilities prioritiseren. Daarbij gebruiken we wereldwijde beste praktijken op het vlak van prioritisatie. Dit leidt tot de use case roadmap als volgende stap. Voorstel voor een Kennishub pagina van deze deliverable Introductie Methodologie (hoe komen we tot een prioritisering van de business capabilities?) Beschrijving van business capabilities Prioritisering van de business capabilities Uitgewerkte deliverables VlocaTraject Versie Use case prioritering Beschrijving Aanpak bij het ontwikkelingen van deze deliverable Elke use case wordt horizontaal ontleed: wat kunnen we met de use case allemaal bereiken? Omdat de uitwerking van een use case vaak een grote tijdsinvestering vraagt, wordt er ook verticaal naar de use case gekeken: wat moet de architectuuroplossing eerst kunnen waarmaken? Na identificatie van alle business objectieven en business capaciteiten, willen we naast al deze mogelijkheden, scopen en prioriteren. Om de scope zuiver te hebben, geven we samen aan of het in scope is (ja of nee). Om prioriteiten te stellen gaan we samen op het niveau van business objectieven en business capaciteiten een score toewijzen (van 1 tot 5). Hoe hoger het getal, hoe belangrijker of dringender. Deze twee cijfers worden opgesomd en geven ons de prioriteitscore van 0 tot 10). Deze prioriteiten worden visueel weergegeven en besproken met de initiatiefnemer(s). De niet meegenomen elementen worden gedocumenteerd als startpunt voor vervolgprojecten, al of niet in dezelfde stad of gemeente. De prioriteitscore per businessobjectief geven we weer in een matrix volgens de belangrijkheid en de dringendheid: De prioriteitscore per business capaciteit gaat een niveau verder. De belangrijkheid en de dringendheid wordt per business capacity bepaald (telkens weer met een score van 1 tot 5). De opgesomde waarden per business capaciteit vermenigvuldigen we met de prioriteitscore van de business objectieven. Dit geeft ons een score van 0 tot 100. Alle prioriteitscores van de business capaciteiten geven we weer in een radiaal:iteiten geven we weer in een radiaal: +
+++ Deze pagina is in opmaak/ontwikkeling … +++ Deze pagina is in opmaak/ontwikkeling +++ Doelgroep en doel Inleiding De roadmap visualiseert de ontwikkeling en uitrol van de business capabilities: welk deel van de thematische use case willen we klaar hebben tegen wanneer? Het is ook een handige tool om bovenlokale subsidies te ondersteunen, zodat we binnen de regio Vlaanderen stelselmatig en gestructureerd samenwerken aan de uitbouw van de slimme steden en de slimme regio in zijn geheel. Afhankelijkheden, risico's en prioriteiten liggen aan de basis van de planning. Een roadmap wordt gebouwd door te starten vanuit de situatie vandaag (de 'as-is') en wat de ideale situatie (de ‘to-be’) is. De ‘gap’ tussen as-is en to-be wordt opgevuld met acties in de tijd. Dit levert ons een ‘roadmap’ in de vorm van ‘blokken’ gespreid in de tijd, die elkaar opvolgen of in parallel worden uitgevoerd. Voorstel voor een Kennishub pagina van deze deliverable Introductie Methodologie (Hoe komen tot de roadmap, op basis van de prioritisering vanuit de business capabilities?) Beschrijving as-is (op basis van de probleemstelling) Beschrijving to-be (op basis van de business capabilities) Use case roadmap: Van as-is naar to-be (omvat beschrijving, textueel, alsook visualisering) Uitgewerkte deliverables VlocaTraject Versie Use case roadmap Beschrijving Aanpak bij het ontwikkelingen van deze deliverable De use case roadmap wordt vormgegeven in functie van het VLOCA-proces en de use case prioritering die met het lokaal bestuur en consortium wordt besproken. Deze roadmap is een aanzet tot het plan van aanpak van het te realiseren project door de stad of gemeente. +
+++ Deze pagina is in opmaak/ontwikkeling … +++ Deze pagina is in opmaak/ontwikkeling +++ Doelgroep en doel Inleiding Een OSLO standaard heeft een fase van publieke review. In gezamenlijke VLOCA-OSLO trajecten communiceren we ook gezamenlijk via onze beschikbare kanalen over de start van de publieke review van de datastandaard. In VLOCA is het doel om een community op te zetten rondom die use case, die de gecreëerde architectuurstandaard beheert. Continue verrijking ervan is cruciaal: de wereld staat immers niet stil na het opleveren van een eerste architectuurmodel. Voorstel voor een Kennishub pagina van deze deliverable[edit source] Introductie (waar gaat het over?) Beschrijving van de standaard Beschrijving van het proces en de bijhorende termijnen Beschrijving over hoe geïnteresseerde partij zelf kan bijdragen Aanpak bij het ontwikkelingen van deze deliverable[edit source] Noot: Het “organiseren van een publieke review” is stap 6 van onderdeel 2 “ontwikkelen van een specificatie” in een OSLO proces. Meer informatie over het OSLO proces kan hier gevonden worden. Deze deliverable sluit dus aan bij stap 6 van onderdeel 2. Stap 1: Opmaken en afstemmen basiscommunicatie met OSLO team Stap 2: Communiceren over de publieke review, via de verschillende VLOCA kanalen, wat minstens het volgende omvat: Informatie over de standaard, het proces en de termijnen Connectie van de standaard naar het VLOCA-OSLO traject Informatie over hoe de feedback op de standaard kan meegegeven worden Informatie over de mogelijkheid om de standaard ook in de toekomst nog verder te laten evoluerenren +
+++ Deze pagina is in opmaak/ontwikkeling … +++ Deze pagina is in opmaak/ontwikkeling +++ Doelgroep en doel Inleiding Een interview met een stakeholder wordt uitgeschreven en gepubliceerd via de VLOCA kanalen. Inzichten in voortgang, probleemstellingen en mogelijkheden staan hierin centraal. We willen reeds communiceren tijdens het onderzoek naar oplossingen. Zo willen we op deze wijze experten aanspreken om deel te nemen aan de co-creatie en de gedeelde inzichten inhoudelijk te verrijken. Zo bouwen we aan maximaal herbruikbare en interoperabele smart city architecturen. Voorstel voor een Kennishub pagina van deze deliverable Introductie (wat is de connectie naar VLOCA, wie is de spreker?) Uitgeschreven interview Lessons learned (wat zijn de belangrijkste aspecten om mee te nemen, zonder dat je het hele interview dient te lezen?) Aanpak bij het ontwikkelingen van deze deliverable Stap 1: Oplijsten van potentiële interview kandidaten. Stap 2: Contacteren interview kandidaat. Stap 3: Opmaken van topiclijst voor interview Voorstel van te bespreken onderwerp concretiseren Voorstel bespreken met de VLOCA talk spreker Bijwerken van het voorstel Stap 4: Afnemen van het interview. Stap 5: Uitschrijven van het interview, met nadruk op voortgang, probleemstellingen en mogelijkheden van een bepaald traject/thema. Stap 6: Goedkeuring interview: Aftoetsen van het resultaat met de respondent (en eventueel vragen van goedkeuring tot publicatie). Stap 7: Publiceren van het interview via de Kennishub & andere VLOCA kanalen (denk aan website) Noot: Voor de verspreiding via de andere kanalen kan een korte teaser/samenvatting al voldoende zijn, om zo de potentiële lezers naar het interview op de Kennishub te leiden.interview op de Kennishub te leiden. +
+++ Deze pagina is in opmaak/ontwikkeling … +++ Deze pagina is in opmaak/ontwikkeling +++ Doelgroep en doel Inleiding Een opname van een videogesprek in Microsoft Teams of Zoom waar we een expert aan het woord laten over een bepaald thema. Voorstel voor een Kennishub pagina van deze deliverable Introductie (wat is de connectie naar VLOCA, wie is de spreker?) Opname van de VLOCA talk Lessons learned (wat zijn de belangrijkste aspecten om mee te nemen, zonder dat je naar de opname dient te kijken?) Aanpak bij het ontwikkelingen van deze deliverable Stap 1: Opmaken van voorstel voor VLOCA talk (welke sprekers zijn potentieel relevant?) Stap 2: Contacteren VLOCA talk spreker Stap 3: Opmaken van topiclijst voor VLOCA talk Voorstel van te bespreken onderwerp concretiseren Voorstel bespreken met de VLOCA talk spreker Bijwerken van het voorstel Stap 4: Opnemen VLOCA talk: Opnemen van de VLOCA talk en verwerken van het materiaal. Stap 5: Goedkeuring VLOCA talk: Aftoetsen van het resultaat met de spreker (en eventueel vragen van goedkeuring tot publicatie). Stap 6: Publicatie van de resultaten op de Kennishub aan de hand van hierboven beschreven voorstel & verspreiden van informatie over de talk via andere VLOCA gerelateerde kanalen.de talk via andere VLOCA gerelateerde kanalen. +
+++ Deze pagina is in opmaak/ontwikkeling … +++ Deze pagina is in opmaak/ontwikkeling +++ Doelgroep en doel Inleiding Elk thema dat we aanraken verdient zijn eigen plek op de kennishub. Het platform wordt gebruikt als co-creatieplatform waar alle experten samen werken aan een correcte beschrijving van het thema. We doelen om per thema een aantal aspecten in de schijnwerper te zetten: de probleemstelling, de huidige mogelijkheden de innovatie die op komst is hoe kiezen tussen mogelijkheden de VLOCA hulpmiddelenssen mogelijkheden de VLOCA hulpmiddelen +
+++ Deze pagina is in opmaak/ontwikkeling … +++ Deze pagina is in opmaak/ontwikkeling +++ Doelgroep en doel Inleiding Het traject charter bevat de projectafspraken gemaakt tussen de Vlaamse Overheid en een lokaal bestuur: het bepaalt de scope en timing van het specifiek traject, uitgewerkt op basis van de deliverables op deze pagina opgesomd. Voorstel voor een Kennishub pagina van deze deliverable Bij het ontwikkelen van de deliverable Traject charter in een traject, kan de volgende Kennishub pagina structuur gevolgd worden: Introductie (Wat is het traject / Waarom dit traject? / Wat is de link naar VLOCA en de VLOCA principes?) Geplande activiteiten (Traject Deliverables) Tijdslijn (met focus op / koppeling naar Traject Deliverables) Participatiemogelijkheden Aanpak bij het ontwikkelingen van deze deliverable Stap 1: Bepaal de VLOCA doelstelling Stap 2: Overleg met de lokale overheid Bespreek de uitdagingen/noden/doelstellingen van de lokale overheid Bespreek de VLOCA doelstellingen Kom tot een gemeenschappelijke set van doelstellingen, met bijhorende scope, timing en deliverables Stap 3: Uitwerking Traject Charter Zet de gemaakte afspraken op papier Verdeel de bijhorende taken Stap 4: Goedkeuring traject charter door VLOCA en lokale overheid Stap 5: Publicatie van het traject charter op de VLOCA Kennishub aan de hand van hierboven beschreven voorstel de hand van hierboven beschreven voorstel +
+++ Deze pagina is in opmaak/ontwikkeling … +++ Deze pagina is in opmaak/ontwikkeling +++ Doelgroep en doel Inleiding Hoe begin je als lokaal bestuur aan een beleidsactie (vb. in het domein van water, mobiliteit, of circulariteit) waarvan je weinig of misschien wel geen kennis van hebt? Een VLOCA draaiboek biedt je daarin de nodige houvast: de ‘how to’ beschrijft de typische stappen om een uitrol van eenzelfde oplossing in de specifieke context, met bvb aan de locatie gerelateerde geografische elementen. De bedoeling is dat we het wiel niet telkens moeten heruitvinden, maar we de stappen van het draaiboek volgen. De nodige aandacht wordt gegeven aan de verschillen tussen grootstedelijke, kleinstedelijke, gemeentelijke of intergemeentelijke context. We nodigen de gebruikers tevens uit om, indien zij bij gebruik bijkomende inzichten hebben, het draaiboek op de kennishub te verfijnen of aan te passen. Zo evolueren de VLOCA draaiboeken doorheen de tijd en bekomen we maximale herbruikbaarheid. Voorstel voor een Kennishub pagina van deze deliverable Introductie (in welke kader werd dit draaiboek ontwikkeld, wat is de doelstelling van dit draaiboek – ‘dit draaiboek kan jou/je organisatie helpen om ....’, met een concrete formulering. Wat is de connectie naar andere draaiboeken & bestekteksten?) Criteria voor gebruik van het draaiboek (wie kan er optimaal gebruik maken van het draaiboek, voor wie zijn er aanpassingen nodig, voor wie is dit niet van toepassing?) Participatiemogelijkheden (beschrijft de mogelijkheid voor externen om draaiboeken aan te passen) Beschrijving van het draaiboek (alsook toevoeging van andere relevante draaiboeken & bestekteksten) Aanpak bij het ontwikkelingen van deze deliverable Stap 1: Bepalen gebruikers & themadraaiboek Wie heeft een draaiboek nodig? Welk type lokaal bestuur zal dit draaiboek kunnen gebruiken? Waarom is het draaiboek nodig? Wat is de uitdaging? Welke ondersteuning is er nodig? Wat zal behandeld worden in het draaiboek? Wat is de link naar andere draaiboeken en bestekteksten? Stap 2: Bepalen structuur & opbouw draaiboek Hoe kan het draaiboek vormgegeven worden, gegeven de aspecten uit Stap 1? Mogelijke sleutelcriteria: herbruikbaarheid & schaalbaarheid. Stap 3: Bepalen inhoud draaiboek Wat kan er meegenomen worden uit het traject? Wat dient er extra toegevoegd te worden om een generiek te gebruiken draaiboek te creëren? Schrijf het draaiboek neer. Bepaal de metadata (wie is de specifieke doelgroep) aan de hand van Stap 1 en Stap 2. Stap 4 (optioneel): Gebruikerstest Toets het draaiboek, opgemaakt in Stap 3, uit met potentiële gebruikers. Mogelijkheden gebruikers: Lokale overheid/overheden betrokken in het traject, andere lokale overheden die sessies meevolgen, lokale overheden die zouden moeten voldoen aan de criteria voor de bruikbaarheid van het draaiboek etc. Mogelijkheden test: Stuur het draaiboek op voorhand door, organiseer een bespreking nadat de gebruiker het draaiboek heeft kunnen doornemen. Stap 5: Bijsturing Analyseer de feedback van de gebruikerstest: Wat was positief? Wat dient bijgewerkt te worden? Herwerk het draaiboek op basis van de voorgaande analyse. Stap 6: Publicatie van de resultaten op de Kennishub aan de hand van hierboven beschreven voorstelen beschreven voorstel +
+++ Deze pagina is in opmaak/ontwikkeling … +++ Deze pagina is in opmaak/ontwikkeling +++ Doelgroep en doel Inleiding Op het einde van een VLOCA traject hebben we de doelstelling om een groep van experten, deelnemers in dat traject, bij elkaar te houden om de opgestelde architectuur van de use case ook na het traject levend te houden. Aanpassingen zullen gebeuren op de kennishub door gebruik en hergebruik van de elementen. Team VLOCA draagt hieraan uiteraard bij, terwijl inhoudelijke experten mee beslissen over het verder ontwikkelen van bepaalde elementen, of van daaruit mogelijke nieuw project en identificeren. Voorstel voor een Kennishub pagina van deze deliverable Afhankelijk van de noden kan er hier een kennishub pagina aangemaakt worden. Aanpak bij het ontwikkelingen van deze deliverable Stap 1: Bepaal toekomstacties: Bekijk voor het gehele traject waar de sterke toegevoegde waarde ligt volgens de deelnemers (vb. waar komen de meeste vragen over? Waar gaan de stakeholders dieper op in?) Stap 2: Stel een post-traject werkgroep benadering op Stap 3: Benader sleutelactoren Wie zijn de sleutelactoren? Enkel diegenen in de kern van het traject of zijn er tijdens het traject nog anderen opgedoken? Wat denken de sleutelactoren van de post-traject werkgroep benadering? Wie wil er instappen in zo’n werkgroep? Stap 4: Organiseer een kick-off Enkel voor de sleutelactoren die betrokken willen zijn bij de werkgroep Bespreek de werkmethode en activiteiten (financiering, governance, taken) Stap 5: Hou de community levend Voorzie een faciliterende rol in de eerste maanden na het traject Breng de sleutelactoren samen, maar zorg dat ook anderen kunnen deelnemen anderen kunnen deelnemen +
+++ Deze pagina is in opmaak/ontwikkeling … +++ Deze pagina is in opmaak/ontwikkeling +++ Doelgroep en doel Inleiding VLOCA en architectuur is vaak een eerste stap in een implementatie van een oplossing voor een use case. De uiteindelijke implementatie van het project neemt tijd in beslag. We willen op dat moment even stil blijven staan bij hoe het begon: het uittekenen van de architectuur. Voorstel voor een Kennishub pagina van deze deliverable Introductie (wat is de connectie naar VLOCA, wie is de spreker?) Opname van de testimonial Lessons learned (wat zijn de belangrijkste aspecten om mee te nemen, zonder dat je naar de opname dient te kijken?) Aanpak bij het ontwikkelingen van deze deliverable Stap 1: Opmaken van voorstel voor testimonial (welke sprekers zijn potentieel relevant?) Stap 2: Contacteren testimonial spreker Stap 3: Opmaken van topiclijst voor testimonial Voorstel van te bespreken onderwerp concretiseren Voorstel bespreken met de testimonial spreker Bijwerken van het voorstel Stap 4: Opnemen testimonial : Opnemen van de testimonial en verwerken van het materiaal. Stap 5: Goedkeuring testimonial : Aftoetsen van het resultaat met de spreker (en eventueel vragen van goedkeuring tot publicatie). Stap 6: Publicatie van de resultaten op de Kennishub aan de hand van hierboven beschreven voorstel & verspreiden van informatie over de testimonial via andere VLOCA gerelateerde kanalen.a andere VLOCA gerelateerde kanalen. +
+++ Deze pagina is in opmaak/ontwikkeling … +++ Deze pagina is in opmaak/ontwikkeling +++ Doelgroep en doel Inleiding Vooraleer we een nieuwe oplossing willen bouwen, analyseren we bestaande markt. Het bouwen van een volledig nieuwe applicatie is vaak niet de gemakkelijkste oplossing. Daarentegen zijn niet alle ervaringen met bestaande toepassingen voldoende om alle business noden af te dekken. De make-or-buy vraag stelt zich dan. De wet van openbare aanbestedingen blijft uiteraard leidend. We stellen ons vragen zoals: Welke bestaande oplossingen kunnen dit initiatief inspireren, informeren of verder aanzetten tot actie? (3 I's of Vibrancy) Zijn er thematische raakvlakken met andere initiatieven, lokaal en bovenlokaal? Zijn er andere initiatieven waar de technologie kan herbruikt worden? Uit welke andere initiatieven of oplossingen kunnen we iets leren? Zijn er reeds leveranciers betrokken bij dit initiatief? Voldoet een oplossing aan de business noden ? Zijn er reeds leveranciers betrokken bij dit initiatief en wensen ze mee te gaan in een opschaling van de oplossing, zonder garantie op afname ? Wat is de match tussen de VLOCA principes en de huidige markt ? Voorstel voor een Kennishub pagina van deze deliverable Introductie (Wat is het traject? / Waarom dit traject?) Positie in Traject (Welke traject deliverable is dit? Wat is de relatie naar de andere deliverables / tijdslijn?) Methodologie (Hoe zal de analyse van de markt gebeuren?) Overzicht marktanalyse (Behandeling van de beschrijvingsvragen) Lessons learned (wat zijn de belangrijkste bevindingen, hoe kunnen deze veralgemeend worden naar andere actoren? – ref. naar dimensies) Aanpak bij het ontwikkelingen van deze deliverable Stap 1: Zorg voor een volledig begrip van de noden en mogelijke oplossing Analyseer de noden & mogelijke oplossingen Lijst potentiële criteria op Bespreek bovenstaande met de lokale overheid en laat inbreng toe van de lokale overheid Stap 2: Verzamel marktinformatie, met de lokale overheid Begrijp welke spelers op de markt zijn Begrijp welke ervaring deze spelers hebben met bepaalde noden (van lokale overheden) en oplossingen (die de spelers kunnen bieden voor de noden van de lokale overheden) Begrijp welke oplossingen de actoren aanbieden Gebruik hierbij de criteria bepaald in Stap 1 Stap 3: Maak de marktanalyse, met de lokale overheid Analyseer of de doelstellingen kunnen bereikt worden via de huidige markt Analyseer hoe de doelstellingen kunnen bereikt worden via de huidige markt Stap 4: Publicatie van de resultaten op de Kennishub aan de hand van hierboven beschreven voorstel Uitgewerkte deliverables VlocaTraject Versie Marktanalyse Beschrijvingschrijving +
+++ Deze pagina is in opmaak/ontwikkeling … +++ Deze pagina is in opmaak/ontwikkeling +++ Doelgroep en doel Inleiding Wanneer een co-creatie traject wordt gestart, roepen we potentiële deelnemers op tot deelname aan de workshops en de co-creatie op de kennishub. Het leidend principe is dat iedereen welkom is, we werken in een Triple Helix model (overheden, bedrijven, kennisinstellingen) of Quadruple Helix model (ook burgers en/of burgerorganisaties betrokken). Een eerste voorselectie gebeurt per use case die we uitwerken door het kernteam van VLOCA samen met de initiatiefnemende overheid van de use case. Mogelijke deelnemers kunnen zich aanmelden door een account te activeren op de kennishub of ons te contacteren via email op [[ een vraag aan team VLOCA|VLOCA@Vlaanderen.be ]]. Voorstel voor een Kennishub pagina van deze deliverable Inleidende tekst trajectvoorstel Tijdslijn en deliverables Verwachtingen naar deelnemende stakeholders toe Opportuniteit/mogelijkheden voor de deelnemende stakeholders (what’s in it for me?) Aanpak bij het ontwikkelingen van deze deliverable Stap 1: Analyse van potentieel geïnteresseerde partijen, vòòr bespreking met initiatiefnemende overheid, en opmaakt voorstel. Stap 2: Bespreking voorstel Stap 1 met initiatiefnemende overheid. Stap 3a: Contacteren potentieel geïnteresseerde partijen op basis van Stap 2. Stap 3b: Algemene aankondiging op VLOCA Kennishub / VLOCA Algemene website van traject, en oproep tot deelname. Stap 3c: Verspreiding via klassieke lokale overheidskanalen: ABB mailinglijst & webiste, VVSG mailinglijst & website etc. Noot: Stap 3a, b en c omvatten minstens het volgende: Inleidende tekst trajectvoorstel Tijdslijn en deliverables Verwachtingen naar deelnemende stakeholders toe Opportuniteit/mogelijkheden voor de deelnemende stakeholders (what’s in it for me?) for me?) +
+++ Deze pagina niet finaal. De tekst in i … +++ Deze pagina niet finaal. De tekst in is in opbouw & review. +++ VLOCA Principes In de dagelijkse werking van de Vlaamse Open City Architectuur zijn er een aantal principes van belang. Deze principes scheppen een breder kader dat mee sturing geeft aan hoe VLOCA functioneert en wat er belangrijk is in de interactie met externe partners. Bij het uitwerken van de verschillende VLOCA deliverables zullen deze principes een leidraad vormen. Zoals de naam aangeeft functioneert VLOCA op een open manier: de deliverables die VLOCA, samen met overheden, private partners en andere stakeholders bereikt, worden op een vrije manier ter beschikking gesteld via de verschillende VLOCA kanalen. Open heeft echter ook grenzen in de context van VLOCA: er zal op een zorgvuldige manier omgegaan worden met privacy gerelateerde data of andere gevoelige informatie en data. Naast het belang van openheid, benadrukt VLOCA het belang van een aantal principes. Deze worden hieronder besproken en we willen je dan ook graag motiveren deze door te nemen. De volgende principes scheppen een kader voor VLOCA en zijn allen even belangrijk: Transparant De werking en resultaten van VLOCA zijn transparant en worden op een actieve manier gecommuniceerd. Door op transparante manier te werken kunnen gebruikers van de VLOCA deliverables makkelijk begrijpen hoe deliverables tot stand kwamen, hoe deze kunnen gebruikt worden en waar aanpassingen nodig zijn. Centraal daarbij staat het vrijgeven van zoveel mogelijk informatie, zonder daarbij anderen in moeilijkheden te brengen en de privacy van actoren te bewaren. Stellingen Informatie is eenvoudig terug te vinden en toegankelijk Het is duidelijk hoe de (deel)oplossingen tot stand zijn gekomen Het is duidelijk welke stakeholders hebben bijgedragen aan de (deel)oplossingen Contactgegevens voor vragen en feedback zijn tijdens en na het traject terug te vinden Schaalbaar Bij het uitwerken van de VLOCA deliverables, samen met overheden, private partners en andere stakeholders uitwerkt, staat het concept schaalbaarheid centraal. Het is cruciaal dat oplossingen die uitgewerkt worden op een eenvoudige manier kunnen blijven ingezet worden wanneer er een groter volume aan activiteiten dient te gebeuren via de ontwikkelde toepassing. Stellingen De (deel)oplossingen zijn ontwikkeld om grotere volumes aan te kunnen De architectuur achter de (deel)oplossingen biedt een oplossing voor lokale besturen met een verschillende digitale maturiteit De architectuur achter de (deel)oplossingen biedt een oplossing voor lokale besturen met een verschillende grootte Technologie agnostisch Deliverables uitgewerkt in de concept van VLOCA zijn technologie agnostisch. Het uitwerken van oplossingen focust op de bedrijfsarchitectuur, technische architectuur, data-architectuur en informatiearchitectuur en daarbij zal er geen keuze gemaakt worden voor de ene of de andere technologie. Een keuze voor een specifieke technologie zal niet gebeuren binnen de context van VLOCA. Stellingen De (deel)oplossingen zijn compatibel met andere software De (deel)oplossingen zijn compatibel met andere hardware De (deel)oplossingen zijn compatibel met andere cloud oplossingen De (deel)oplossingen kunnen andere databronnen consumeren De (deel)oplossingen kunnen ontwikkeld en onderhouden worden door verschillende partners De (deel)oplossingen zijn te koppelen met verschillende externe oplossingen Gebruikersgericht VLOCA stelt de gebruiker centraal. Bij de ontwikkeling van de VLOCA deliverables staat de gebruiker van de diensten centraal: hoe kan de gebruiker van de deliverables het meeste baat hebben bij de deliverables? Daarnaast verwijst dit principe eveneens naar de gebruiker van de dienst die extra ontwikkelingssteun krijgt via VLOCA: de dienst die een overheid zal aanbieden naar gebruikers toe, moet zo opgebouwd zijn dat er een optimale balans kan gevonden worden tussen de noden van de gebruiker en mogelijkheden die de overheid heeft. Tot slot dient aangegeven te worden dat VLOCA een participatieve benadering heeft, waarbij co-creatie met de verschillende quadruple helix actoren (overheid, burgers, bedrijven en maatschappelijke actoren) centraal staat. Stellingen De stakeholders werden voldoende betrokken bij het tot stand komen van de (deel)oplossingen Er werd tijdens het traject voldoende teruggekoppeld met de initiatiefnemers De architectuur van de (deel)oplossingen is bruikbaar voor de lokale besturen De architectuur van de (deel)oplossingen is bruikbaar door de industrie Interoperabel Een vijfde VLOCA principe is interoperabiliteit. Voor VLOCA verwijst dit zowel naar een principe dat dient gevolgd te worden in de oplossingen die uitgewerkt worden door VLOCA – met aandacht voor technische systemen, maar evenzeer voor juridische en organisationele relaties – , als naar een principe te volgen in de werking van VLOCA. Een omschrijving van het concept interoperabiliteit kan je vinden bij het concept interoperabiliteit . Stellingen De Vlaamse Bouwstenen worden contextueel gebruikt in de (deel)oplossingen De architectuur van de (deel)oplossing houdt rekening met de referentiearchitectuur van VLOCA De architectuur is voldoende generiek om samen te werken met andere (deel)oplossingen De architectuur is voldoende generiek om samen te werken met andere lokale besturen De (deel)oplossing laat data-delen toe Architectuurstandaarden zijn geraadpleegd en/of verwerkt in de architectuur Duurzaam Tot slot hanteert VLOCA het principe duurzaam. Het is belangrijk dat de resultaten van VLOCA zowel kunnen hergebruikt worden binnen verschillende contexten, en dus binnen éénzelfde tijdskader (denk bijvoorbeeld aan verschillende steden & gemeenten die gebruik maken van de VLOCA resultaten), alsook dat deze resultaten bruikbaar blijven op een middellange – lange termijn. De resultaten van vandaag moeten ook binnen afzienbare tijd nog steeds van toepassing zijn. Daarom werkt VLOCA resultaten uit die enerzijds specifiek zijn, maar anderzijds ook voldoende generiek en dus een herbruikbaarheid toelaten binnen projecten, thema’s, steden & gemeenten etc. Stellingen De architectuur houdt rekening met de expertise van thematische experten De architectuur is voldoende generiek om toekomstige noden en technologieën op te nemen De architectuur houdt rekening met het minimum aantal componenten voor werkbare en kostenefficiënte (deel)oplossingen De (deel)oplossingen dragen bij aan verschillende maatschappelijke uitdagingen De (deel)oplossingen houden rekening met anomalieën Slimme Data Attributen Naast de VLOCA principes die zorgen voor een principiële sturing van het VLOCA werk, zijn er de Slimme Data Attributen. Willen overheden meer gebruik gaan maken van data in hun beleidsuitdagingen, dan zal het belangrijk zijn om over data te beschikken die klaar is voor besluitvorming. Dit vraagt data die voldoet aan een aantal attributen. Deze attributen zijn, vanuit een VLOCA perspectief, cruciaal voor het werk rond de VLOCA IT Architectuur Deliverables en bieden een inhoudelijk kader voor het mee vormgeven van deze deliverables. Er werd gekozen voor Slimme Data attributen en niet voor de FAIR principes : hoewel hoogst relevant, zijn de FAIR principes vooral geschikt voor Big Data en niet voor Slimme Data. VLOCA heeft echter de intentie om toe te werken naar Slimme Data in de IT Architectuur Deliverables om zo te komen tot de applicaties nodig voor de (lokale) overheden. Enkel Big Data zal niet volstaan om overheden beleidsuitdagingen te laten aanpakken met data. Wil je graag meer informatie over de relatie tussen FAIR Data & Slimme Data Attributen? Hier kan je daarover meer informatie vinden [link toevoegen bij publicatie]. Vanuit VLOCA hanteren we de volgende Slimme Data Attributen, waarbij deze allen even belangrijk zijn: Betrouwbaar Om beslissingen te kunnen nemen op basis van uit data verkregen inzichten is vertrouwen in de kwaliteit, consistentie, nauwkeurigheid, oorsprong, bescherming en beveiliging enz. van die data cruciaal. Een vooraf bepaald niveau van vertrouwen is nodig om verantwoording te kunnen afleggen voor de acties die op de data worden ondernomen. Contextueel De data context is een belangrijk onderdeel van de metagegevens van een gegevensverzameling. Het geeft context over de verzameling van de data (bv. locatie, tijd, meetomstandigheden, enz.), het gebruik van de data (gebruiksbeleid, belangrijkste interpretatierichtlijnen, beperkingen, restricties, enz.), de beheerde betekenis van de data en nog veel meer. De context van de data dient volledig te zijn voor het gebruik en dient ook gekoppeld te zijn aan de “commons” van de nodigde informatie uit de uitdagingen [zin te reviewen]. Hoe meer domeinen de data kunnen aanspreken, hoe meer context nodig zal zijn. Merk op dat contexten van data naar elkaar kunnen verwijzen, bijvoorbeeld met behulp van semantic web linked data-technieken. Tot slot is ook data provenance (i.e. gegevens over het spoor van de data) van toepassing op de context en is dit essentieel om vertrouwen in de data mogelijk te maken. Relevant Zelfs wanneer data betrouwbaar en contextueel zijn, zijn ze niet noodzakelijkerwijs onmiddellijk bruikbaar of relevant voor (beleids)use cases. Het is belangrijk de data uit verschillende bronnen zo te organiseren dat applicaties ze makkelijk kunnen vinden, en dat ze zo worden gepubliceerd en gepresenteerd dat ze onmiddellijk relevant zijn. Duidelijk In veel gevallen moeten ruwe data worden verwerkt om ze begrijpelijker te maken, vooral wanneer ze ongestructureerd zijn, zoals streaming media, afbeeldingen, enz. Cognitieve gegevensverwerking verwijst naar technologie zoals machine learning, machine reasoning, natural language processing, spraakherkenning en mens-computerinteractie om data om te zetten in meer bruikbare vormen voor economische of besluitvormingsdoeleinden. Voorspelbaar Bij het omzetten van ruwe data in inzichtelijke data om bepaalde beslissingen aan te sturen, is het belangrijk om te focussen op trends en voorspellingen. Bij digital twins is het bijvoorbeeld belangrijk om voorspellingen te kunnen doen over de evolutie van bepaalde datasets, zoals overstromingsrisico's of de impact van bepaalde acties, en om heen en weer te gaan in de tijd. Slimme data moeten zodanig worden afgestemd en gepresenteerd dat voorspellingen worden vereenvoudigd, bijvoorbeeld door voldoende context toe te voegen van bepaalde oorzaken van trendveranderingen in de data en 'tijdreizen' mogelijk te maken. Bruikbaar Data moeten zo worden gepresenteerd dat zij gemakkelijk door mensen en machines kunnen worden gebruikt. Het is dus erg belangrijk om de toegangs-, presentatie- en servicelagen (bv. API) zo te ontwerpen dat zij zijn afgestemd op het gebruik ervan. Om data bruikbaar te maken, moeten de behoeften van de besluitvormers en hun instrumenten (bv. digital twins ) goed worden begrepen en gefocust zijn. Methodologie: Hoe kwam VLOCA tot deze VLOCA principes & Slimme Data attributen? De totstandkoming van de VLOCA principes & Slimme Data attributen gebeurde via een aantal stappen. Deze stappen worden hieronder toegelicht. In een eerste stap werden een aantal bestaande documenten, met relevantie voor VLOCA en met een sterke focus op principes & waarden, geanalyseerd om hieruit de principes te distilleren. De volgende documenten werden daarvoor geselecteerd en geanalyseerd: FAIR Data Principes , European Interoperability Framework , European Interoperability Framework for Smart Cities and Communities , London Data Charter , OECD Digital Government , UK Data Principles , European Digital Rights and Principles , Principles for Digital Development , Principles for Digital-ready Legislation , Principes voor de digitale samenleving , Open DEI , VLOCA Effectiviteitsprincipes . Vanuit al de geïdentificeerde principes & waarden werd gekomen tot één eenvormige lijst van principes. Deze principes werden geïdentificeerd vanuit het idee dat deze relevant dienen te zijn voor het gedachtengoed van VLOCA en dienen te beschrijven hoe VLOCA functioneert. De volgende principes werden hierbij geïdentificeerd: Findable, Accessible, Interoperable, Reusable, Transparent, Open, Scalable, Technology agnostic, User centric. In een tweede stap werd besloten tot drie zaken. Na de voorgaande stap en verdere reflectie werd duidelijk dat de VLOCA principes een dubbel doel dienen: (1) het bepalen van principes waaraan de VLOCA werking dient te voldoen en (2) het bepalen van attributen die richting geven aan de IT Architectuur ontwikkeld door VLOCA via IT Architectuur Deliverables , en die cruciaal zijn voor de rol die data daarin speelt: de Slimme Data Attributen. Dit leidde, ten eerste, tot de selectie van de hierboven beschreven VLOCA Principes (transparant, schaalbaar, technologie agnostisch, gebruikersgericht, interoperabel, duurzaam). Daarnaast werden ook de Slimme Data attributen verder gespecifieerd en gedefinieerd (betrouwbaar, contextueel, relevant, duidelijk, voorspelbaar en bruikbaar), waarbij voor deze laatste principes werd teruggegrepen naar recent gepubliceerd onderzoek [link toevoegen bij publicatie]. Tot slot werden deze principes en attributen actief besproken en afgetoetst met een aantal experten. +
+++/// PAGINA IN OPMAAK \\\+++ Doel en do … +++/// PAGINA IN OPMAAK \\\+++ Doel en doelgroep Finaliteit: Antwoord op datagovernanceact --> weten hoe met data omgaan voor specifieke use cases en hoe bewaken? Generiek model specifiek ingevuld Inleiding Vragen die we adhv data governance model willen beantwoorden: Welke data wel en welke data niet toegangkelijk en bruikbaar (met vemelding van specifieke databronnen per traject), onderscheid per gebruiker? Matrix welke data mag door wie gebruikt worden? Hoe verschilt een data governance model van principes? Mix van generieke en specifieke bepalingen? Wie is de eigenaar van de data? (FAIR) Data-principes Sector specifieke bepalingen Bescherming van gegevens, de persoonlijke levenssfeer en de integriteit van het individu/ Persoonsgegevens indien van toepassing: privacyvriendelijkere gegevensverwerking/ GDPR Commercieel vertrouwelijke gegevens Uitwerking van architectuur volgens "open door ontwerp en door standaardinstellingen" Datagovernancemodel is niet-discriminerend, transparant, evenredig en objectief gerechtvaardigd Hebruik van data om verder onderzoek en gebruik te bevorderen. Afdwingbaarheid/ contract voor data gebruik/ commitment? Kan worden bewezen dat privacy en vertrouwelijkheid werd gewaarborgd? Concurrerend klimaat voor gegevensdeling : neutraliteit van de aanbieders van databemiddelingsdiensten? Willen wij aangeven welke data aanbieders data-altruïstisch is of moet dit eigen zijn aan partnerschap/ VLOCA 'charter'/ vrijwillige registratie? Kan een toelating tot gebruik van data worden ingetrokken? Reglement met informatie, technische en beveiligingsvereisten, en stappenplannen voor communicatie en interoperabiliteitsnormen? Willen we definities opnemen in het datagovernancemodel? (bv art. 2 datagovernanceverorderdening) Toepassingsgebied? (bv art. 3 datagovernanceverordening) Vergoeding (art. 6) Toezicht op naleving? (art. 14) (rol van ) VLOCA als/ voor erkende org voor Data altruïsme? (art. 17) Transparantievereisten (art. 20) Hoort data lineage thuis in een datagovernancemodel? Datagovernanceverordening De Europese Datagovernanceverordening van 30 mei 2022 kwam tot stand om ... Het moet ook de versterking van de open strategische autonomie van de Unie waarborgen, en tegelijk het internationale vrije verkeer van gegevens bevorderen . Gegevens zijn de hoeksteen van die transformatie: datagestuurde innovatie Verkleinen van de digitale kloof. Neutraliteit van de toegang tot en de overdraagbaarheid en interoperabiliteit van gegevens moeten worden gewaarborgd en lock-in-effecten moeten worden vermeden. FAIR -data principes. Voor het ontwerp, de totstandkoming en de handhaving van het gelijke speelveld in de data-economie is goede governance nodig waaraan alle belanghebbenden van een gemeenschappelijke Europese gegevensruimte moeten deelnemen en waarin zij vertegenwoordigd moeten zijn. Deze verordening moet gericht zijn op de verdere ontwikkeling van de digitale interne markt zonder grenzen en een betrouwbare en veilige datasamenleving en -economie waarin mensen centraal staan . Rechtspersonen die doeleinden van algemeen belang wensen te ondersteunen door op basis van data-altruïsme op een bepaalde schaal relevante gegevens beschikbaar te stellen en die aan de in deze verordening neergelegde vereisten voldoen, moeten zich kunnen registreren als “in de Unie erkende organisatie voor data-altruïsme” en moeten dat label kunnen gebruiken . Een Uniebreed governancekader moet als doel hebben vertrouwen te scheppen bij personen en ondernemingen wat betreft de toegang tot, de controle over, alsook het delen, het gebruik en het hergebruik van gegevens , met name door passende mechanismen in te stellen die het voor datasubjecten mogelijk maken om hun rechten te kennen en op zinvolle wijze uit te oefenen , alsook inzake het hergebruik van bepaalde soorten gegevens die in het bezit zijn van openbare lichamen, het verlenen van diensten door aanbieders van databemiddelingsdiensten aan datasubjecten, gegevenshouders en gegevensgebruikers, alsmede het verzamelen en verwerken van gegevens die door natuurlijke en rechtspersonen voor altruïstische doeleinden beschikbaar worden gesteld . Een grotere transparantie ten aanzien van het doel van het gebruik en de wijze van opslag van gegevens door ondernemingen kan met name helpen om het vertrouwen te versterken . Er zijn technieken die analyses van databanken met persoonsgegevens mogelijk maken, zoals anonimisering, differentiële privacy, generalisering, onderdrukking en randomisering, het gebruik van synthetische gegevens of soortgelijke methoden, en andere geavanceerde methoden om de privacy te beschermen , die kunnen bijdragen tot een privacyvriendelijkere gegevensverwerking . Aansporen om gegevens te genereren en beschikbaar te stellen overeenkomstig het beginsel “open door ontwerp en door standaardinstellingen” (“open by design and by default”). Commercieel vertrouwelijke gegevens zijn gegevens die beschermd zijn door bedrijfsgeheimen, beschermde knowhow en alle andere informatie waarvan de ongeoorloofde openbaarmaking gevolgen zou hebben voor de marktpositie of de financiële gezondheid van de onderneming. Bescherming van gegevens, de persoonlijke levenssfeer en de integriteit van het individu. Elke lidstaat daarom kunnen beslissen of gegevens toegankelijk worden gemaakt voor hergebruik, en over het doel en de reikwijdte van die toegang . Voorwaarden moeten niet-discriminerend, transparant, evenredig en objectief gerechtvaardigd zijn en mogen de mededinging niet beperken. De voorwaarden voor hergebruik moeten zodanig worden ontworpen dat zij wetenschappelijk onderzoek bevorderen . Openbare lichamen moeten vergoedingen kunnen aanrekenen voor het hergebruik van gegevens, maar moeten, in overeenstemming met de staatssteunregels, ook hergebruik tegen een gereduceerde vergoeding of kosteloos hergebruik kunnen toestaan, bijvoorbeeld voor bepaalde categorieën hergebruik, zoals niet-commercieel hergebruik voor wetenschappelijke onderzoeksdoeleinden, of hergebruik door kmo's en start-ups, maatschappelijke organisaties en onderwijsinstellingen, om dergelijk hergebruik ten behoeve van onderzoek en innovatie te stimuleren en ondernemingen te ondersteunen die een belangrijke bron van innovatie vormen en het oorgaans moeilijker vinden om zelf relevante gegevens te verzamelen. Technische middelen om een beveiligde verwerkingsomgeving beschikbaar te stellen of de technische middelen om privacy en vertrouwelijkheid te waarborgen indien toegang tot het hergebruik van gegevens die binnen het toepassingsgebied van deze verordening vallen, werd verleend. Van databemiddelingsdiensten wordt verwacht dat zij een sleutelrol spelen in de data-economie , met name bij het ondersteunen en bevorderen van vrijwillige praktijken voor het delen van gegevens tussen ondernemingen of bij het faciliteren van gegevensdeling in het kader van verplichtingen op basis van het Unierecht of het nationale recht. Zij kunnen een facilitator worden van de uitwisseling van aanzienlijke hoeveelheden relevante gegevens. Aanbieders van databemiddelingsdiensten moeten aanvullende specifieke instrumenten en diensten aan gegevenshouders en datasubjecten kunnen aanbieden met het specifieke doel de gegevensuitwisseling te faciliteren , zoals tijdelijke opslag, curatie, conversie, anonimisering en pseudonimisering. Tegelijkertijd moeten anbieders van databemiddelingsdiensten de mogelijkheid krijgen om de uitgewisselde gegevens aan te passen , bijvoorbeeld door ze om te zetten in een specifiek format, teneinde de bruikbaarheid van de gegevens voor de gegevensgebruiker te verbeteren wanneer de gegevensgebruiker dat wenst, of teneinde de interoperabiliteit te verbeteren . Het is belangrijk om voor een concurrerend klimaat voor gegevensdeling te zorgen. Een belangrijk element om het vertrouwen en de controle van gegevenshouders, datasubjecten en gegevensgebruikers met betrekking tot databemiddelingsdiensten te versterken, is de neutraliteit van de aanbieders van databemiddelingsdiensten met betrekking tot de tussen gegevenshouders of datasubjecten en gegevensgebruikers uitgewisselde gegevens. Daarom is het noodzakelijk dat aanbieders van databemiddelingsdiensten uitsluitend optreden als tussenpersoon bij de transacties en de uitgewisselde gegevens niet voor andere doeleinden gebruiken . Er is een groot potentieel voor doeleinden van algemeen belang bij het gebruik van gegevens die vrijwillig door datasubjecten beschikbaar worden gesteld op basis van hun geïnformeerde toestemming of, wanneer het niet-persoonsgebonden gegevens betreft, die door gegevenshouders beschikbaar worden gesteld. Tot dergelijke doeleinden behoren gezondheidszorg, bestrijding van de klimaatverandering, mobiliteitsverbetering, facilitering van de ontwikkeling, productie en verspreiding van officiële statistieken, verbetering van openbare diensten, of openbare besluitvorming. Steun voor wetenschappelijk onderzoek moet ook worden beschouwd als een doeleinde van algemeen belang. Om datasubjecten en gegevenshouders te helpen om erkende organisaties voor data-altruïsme eenvoudig te identificeren en aldus hun vertrouwen in die organisaties te vergroten, moet er een gemeenschappelijk logo worden ingevoerd dat in de hele Unie herkenbaar is. Het gemeenschappelijke logo moet vergezeld gaan van een QR-code met een link naar het openbaar Unieregister van erkende organisaties voor data-altruïsme. Om het vertrouwen te bevorderen en extra rechtszekerheid en gebruikersvriendelijkheid te bieden bij het proces inzake het verlenen en intrekken van toestemming, met name in het kader van wetenschappelijk onderzoek en statistisch gebruik van gegevens die uit altruïsme beschikbaar worden gesteld, moet een Europees toestemmings formulier voor data-altruïsme worden ontwikkeld en gebruikt in de context van het altruïstisch delen van gegevens. Dat formulier moet datasubjecten meer transparantie verschaffen over het feit dat hun gegevens zullen worden geraadpleegd en gebruikt in overeenstemming met hun toestemming en met volledige inachtneming van de regels inzake gegevensbescherming. Het formulier moet ook het verlenen en intrekken van toestemming faciliteren en worden gebruikt om het data-altruïsme van ondernemingen te stroomlijnen en die ondernemingen een mechanisme te bieden om hun toelating tot het gebruik van de gegevens in te trekken. Reglement op te stellen voor erkende organisaties voor data-altruïsme met daarin informatie, technische en beveiligingsvereisten, en stappenplannen voor communicatie en interoperabiliteitsnormen die die organisaties in acht moeten nemen. Daar de doelstellingen van deze verordening, te weten het hergebruik binnen de Unie van bepaalde categorieën gegevens die in het bezit zijn van openbare lichamen en de vaststelling van een aanmeldings- en toezichtskader voor de verstrekking van databemiddelingsdiensten, een kader voor de vrijwillige registratie van entiteiten die voor altruïstische doeleinden gegevens beschikbaar stellen en een kader voor de oprichting van een Europees Comité voor gegevensinnovatie, ... +
24/7 dienstverlening Context Burgers … 24/7 dienstverlening Context Burgers verwachten meer en meer dat de gemeentelijke dienstverlening op elk moment van de dag toegankelijk is. De bestaande openingsuren van de gemeentelijke dienstverlening worden vaak als te beperkt gevonden. Als onderdeel van het GzG-project ‘24/7 dienstverleningsconcepten’ lanceerde Aalter in 2023 een innovatieve 24/7-automaat waarmee burgers buiten kantooruren essentiële documenten (met uitzondering van persoonsgevoelige documenten waarvan reeds bestaand exemplaar bestaat, conform de wettelijke restrictie rond devaluatie en fysieke tussenkomst door een ambtenaar) kunnen ophalen. Deze automaat is momenteel werkzaam bij het Aalterse gemeentehuis voor voorlopige rijbewijzen, eerste internationale paspoorten, het uitlenen van sleutels, feestmateriaal etc. De bedoeling is om een 'architecturale blauwdruk' op te maken voor bredere implementatie bij lokale besturen, met focus op holistische dienstverlening en kostenbesparing. VLOCA VLOCA, een programma van het Agentschap Binnenlands Bestuur , biedt een architecturale blauwdruk om zowel strategische als operationele doelen van lokale besturen te ondersteunen , waardoor zij weloverwogen beslissingen kunnen nemen, risico's effectiever kunnen beheren en betere resultaten kunnen behalen. Een belangrijke focus ligt op het integreren van alle digitale bouwstenen om lokale besturen optimaal te ondersteunen tijdens hun digitale transformatieproces . Dit doen we aan de hand van desk research en een aantal werkgroepen: Business werkgroep : scherpstellen van de probleemstelling, context en motivatie van het project. Functionaliteiten werkgroep : inzicht krijgen in de functies, taken en rollen nodig om het project te realiseren. Profiel deelnemers werkgroep: business expert, functioneel/business analist, business/solution architect, project lead Applicatie componenten werkgroep : landschapsanalyse en onderzoeken waarop informatie gebruikt en gedeeld wordt en welke tools hiervoor kunnen gebruikt worden Profiel deelnemers werkgroep: business/functioneel analist, IT expert, entreprise architect, project lead Aanpak en risico’s werkgroep : voor de verschillende scenario’s wordt een evaluatie gemaakt op vlak van haalbaarheid, risico’s en impact. Business werkgroep Opzet Tijdens de werkgroep werden de volgende topics behandeld: Scoping aan de hand van use-cases: we leggen de nadruk op de context en wat we willen bereiken met een 24/7 dienstverlening. SWOT-analyse rond 24/7 dienstverlening Consolidatie van de SWOT-analyse in een aantal doelstellingen Scoping aan de hand van use-cases Burgers willen op flexibele tijdstippen beroep kunnen doen op dienstverlening van de overheid Doel van de Opdracht Het traject richt zich op het creëren van toekomstbestendige dienstverlening en zal verder uitklaren hoe het verhaal van een slimme automaat hierbinnen past. Door in te zetten op een holistische benadering, zorgen we ervoor dat we het product in lijn is met strategische en operationele doelstellingen van de lokale besturen. Zodat we de gemeentelijke dienstverlening maximaal op maat van de burger kunnen voorzien Assumpties 1.De 24/7 automaat is gebruiksvriendelijk, ook voor burgers die minder digitaal geletterd zijn 2.De 24/7 automaten kunnen integreren met andere bestuursoplossingen 3.De locaties van de automaten worden strategisch gekozen om een zo breed mogelijke toegankelijkheid te garanderen, inclusief voor mensen met een beperking 4.De kosten voor de aanschaf, installatie en onderhoud van de automaten zijn gerechtvaardigd door de voordelen die ze bieden Beperking 1.Uitwisselen van identiteitsgerelateerde gegevens zijn onderhevig aan juridische beperkingen Voorwaarden 1.Interne werking van de organisatie is voldoende matuur om informatie op een gestructureerde manier uit te wisselen 2.Voldoende bewustzijn bij de betrokken partner 3.Juridische beperkingen rond gegevens uitwisseling en delingen worden uitgezocht De belangrijkste meerwaarde: 1.Flexibelere toegankelijkheid gemeentelijke dienstverlening 2.Verbeterde efficiëntie door innovatieve dienstverlening 3.Drempels verlagen voor kleine gemeenten en landelijke gebieden Architecturale blauwdruk 24/7 dienstverlening: De onderstaande figuur beschrijft de flow en de verschillende onderdelen van een 24/7 dienstverlening: We leggen de focus op de rol van centrale dispatching: SWOT-Analyse rond ‘24-7 Dienstverlening’ Een SWOT-analyse is een strategische planningstechniek die wordt gebruikt om de Sterktes (Strengths), Zwaktes (Weaknesses), Kansen (Opportunities), en Bedreigingen (Threats) van een project of organisatie te identificeren en te evalueren. Sterktes: Interne kenmerken die bijdragen aan het succes. Zwaktes: Interne kenmerken die de prestaties belemmeren. Kansen: Externe factoren die benut kunnen worden voor voordeel. Bedreigingen: Externe factoren die risico’s vormen voor succes. Waarom belangrijk? Een SWOT-analyse biedt strategisch inzicht, ondersteunt besluitvorming en helpt bij risicobeheer voor het centraal meldingen platform. Toepassing op: Centraal Meldingen Platform Efficiëntie: Biedt inzicht in interne processen die verbeterd kunnen worden. Transparantie: Identificeert externe factoren die kansen bieden voor verbeterde communicatie met burgers. Effectiviteit: Helpt bij het bepalen van bedreigingen die de succesvolle implementatie van het platform kunnen belemmeren. Opdracht: Identificeer de sterktes, zwaktes, kansen en bedreigingen rond het digitaal meldingen platform. Besluit sterktes en zwaktes: De belangrijkste sterke punten zijn de verhoogde klanttevredenheid en flexibiliteit, maar intern zijn er zorgen rond technische uitdagingen, budgettaire beperkingen, en toegankelijkheid voor digitaal minder vaardige burgers. Sterktes : Toegankelijkheid: 24/7 beschikbaarheid verhoogt klanttevredenheid en vermindert wachttijden. Tijds- en werkdrukverlaging: Automatisatie bespaart tijd en vermindert werkdruk. Flexibiliteit: Dienstverlening zonder beperkingen door openingsuren, afgestemd op burgers. Kostenbesparing door samenwerking: Bundelen van krachten vermindert kosten. Gebruiksvriendelijk: Intuïtief en makkelijk te gebruiken. Centrale organisatie: Efficiënte, centrale regeling voor deelgemeenten. Uitbreiding buiten openingsuren: Biedt diensten aan wanneer balies gesloten zijn. Zwaktes : E-inclusie toegankelijkheid: Moeilijk voor digibeten en technisch minder vaardige burgers. Logistieke uitdagingen: Vraagt extra opvolging en verschuift werklast. Regelgevingsbeperkingen: Compliance met wetgeving (bijv. GDPR). Beperkt productaanbod: Niet alle producten beschikbaar via lockers. Veiligheidszorgen: Risico op diefstal en identiteitsfraude. Personeelstekort: Beperkte middelen voor beheer van lockers. Afhankelijkheid van IT: Behoefte aan interne IT-ondersteuning en training. Veranderende beleidsprioriteiten: Projecten kunnen wegvallen door bezuinigingen. Besluit opportuniteiten en bedreigingen: Buiten de eigen organisatie liggen kansen in samenwerking en uitbreiding van de dienstverlening, terwijl bedreigingen vooral komen van informatieveiligheid, vandalisme en wet- en regelgeving. Opportuniteiten : Uitbreiding naar dorpskernen: Lokale lockers dichter bij burgers. 24/7 dienstverlening: Vrijheid voor burgers om altijd producten aan te vragen. Samenwerking met andere gemeenten: Kosten delen en lobbyen voor wetgeving. Integratie met digitale diensten: Koppeling met platformen zoals "Mijn Burgerprofiel". Betrokkenheid burgers: Burgers laten meedenken over locatie en gebruik. Decentrale diensten: Versterking van deelgemeenten door verspreiding. Wettelijke versoepeling: Mogelijkheid om regelgeving te beïnvloeden. Bedreigingen : Hoge kosten in kleine gemeenten: Mogelijks hoge initiële investering Informatieveiligheid: Risico's op hacking, identiteitsfraude, en datalekken. Vandalisme en diefstal: Fysieke beveiliging tegen inbraak en vandalisme. Overheidsbeperkingen: Wetgeving kan de mogelijkheden beperken. Operationele storingen: Stroomuitval of defecten verstoren de dienstverlening. Verhouding ten aanzien van andere diensten: Thuislevering of buurtoplossingen kunnen relevanter zijn. Consolidatie SWOT-Analyse in doelstellingen en risico’s Algemene doelstelling: Efficiënte, veilige en inclusieve dienstverlening, altijd en overal beschikbaar voor elke burger. Prioriteiten: Versterken van klantgerichte en toegankelijke dienstverlening Optimaliseren van processen en samenwerking voor 24/7 dienstverlening Waarborgen van veiligheid en gebruikersauthenticatie Stimuleren van innovatie en digitaal gebruik bij burgers Verhogen van e-inclusie en digitale toegankelijkheid Opleiden van medewerkers en verbeteren van communicatie Vergroten van betrokkenheid van medewerkers in burgergerichte processen Verminderen van administratieve lasten door automatisering Krijgen van beleidsinzichten en vergroten van burgerdraagvlak Om deze doelstellingen te behalen moeten we ons behoeden voor de risico’s die hiermee gepaard gaan: Hacking, identiteitsfraude, datalekken (GDPR) Zorg voor sterke encryptie, regelmatige audits, en strikte GDPR-compliance. Vandalisme, diefstal, inbraak Overweeg veiligste oplossing, CCTV-installaties en gebruik plekken met sociale controle Uitsluiting van digitaal minder vaardige burgers Opleidingen, ondersteuning en alternatieve afhaalopties aanbieden Stroomuitval of defecten Zorg voor onderhoudscontracten met snelle responstijd Extra werklast, initiële kostprijs en logistiek Samenwerking en planning tussen gemeenten, kosten delen en subsidies zoeken. Beperkingen door wetgeving Samenwerken tussen verschillende overheden en voldoen aan wet- en regelgeving Laag gebruik door verhouding met andere 24/7 oplossingen Strategische keuzes maken door oplossingen met elkaar vergelijken Verlies van prioriteit door bezuinigingen Bewijzen van de kostenbesparing en efficiëntie van de oplossing Addendum Miro bord Het Miro bord kan je consulteren via deze link . Volgende stappen Verwerking van de input van de brainstorm oefening. Verder onderzoek en voorbereiding van de volgende thematische werkgroep. Publicatie op de Kennishub. Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2024-09-03 9u-12u Teams Functionaliteiten werkgroep Data en informatie werkgroep 2024-10-01 9u-12u Teams Applicatie componenten werkgroep Functionele werkgroep 2024-11-19 9u-12u Teams +
24/7 dienstverlening Context Burgers … 24/7 dienstverlening Context Burgers verwachten meer en meer dat de gemeentelijke dienstverlening op elk moment van de dag toegankelijk is. De bestaande openingsuren van de gemeentelijke dienstverlening worden vaak als te beperkt gevonden. Als onderdeel van het GzG-project ‘24/7 dienstverleningsconcepten’ lanceerde Aalter in 2023 een innovatieve 24/7-automaat waarmee burgers buiten kantooruren essentiële documenten (met uitzondering van persoonsgevoelige documenten waarvan reeds bestaand exemplaar bestaat, conform de wettelijke restrictie rond devaluatie en fysieke tussenkomst door een ambtenaar) kunnen ophalen. Deze automaat is momenteel werkzaam bij het Aalterse gemeentehuis voor voorlopige rijbewijzen, eerste internationale paspoorten, het uitlenen van sleutels, feestmateriaal etc. De bedoeling is om een 'architecturale blauwdruk' op te maken voor bredere implementatie bij lokale besturen, met focus op holistische dienstverlening en kostenbesparing. VLOCA VLOCA, een programma van het Agentschap Binnenlands Bestuur , biedt een architecturale blauwdruk om zowel strategische als operationele doelen van lokale besturen te ondersteunen , waardoor zij weloverwogen beslissingen kunnen nemen, risico's effectiever kunnen beheren en betere resultaten kunnen behalen. Een belangrijke focus ligt op het integreren van alle digitale bouwstenen om lokale besturen optimaal te ondersteunen tijdens hun digitale transformatieproces . Dit doen we aan de hand van desk research en een aantal werkgroepen: Business werkgroep : scherpstellen van de probleemstelling, context en motivatie van het project. Functionaliteiten werkgroep : inzicht krijgen in de functies, taken en rollen nodig om het project te realiseren. Profiel deelnemers werkgroep: business expert, functioneel/business analist, business/solution architect, project lead Applicatie componenten werkgroep : landschapsanalyse en onderzoeken waarop informatie gebruikt en gedeeld wordt en welke tools hiervoor kunnen gebruikt worden Profiel deelnemers werkgroep: business/functioneel analist, IT expert, entreprise architect, project lead Aanpak en risico’s werkgroep : voor de verschillende scenario’s wordt een evaluatie gemaakt op vlak van haalbaarheid, risico’s en impact. Profiel deelnemers werkgroep: business analist, architect, project leads Functionaliteiten werkgroep Algemene doelstelling: Efficiënte, veilige en inclusieve dienstverlening, altijd en overal beschikbaar voor elke burger. Prioriteiten: Versterken van klantgerichte en toegankelijke dienstverlening Optimaliseren van processen en samenwerking voor 24/7 dienstverlening Waarborgen van veiligheid en gebruikersauthenticatie Stimuleren van innovatie en digitaal gebruik bij burgers Verhogen van e-inclusie en digitale toegankelijkheid Opleiden van medewerkers en verbeteren van communicatie Vergroten van betrokkenheid van medewerkers in burgergerichte processen Verminderen van administratieve lasten door automatisering Krijgen van beleidsinzichten en vergroten van burgerdraagvlak Om deze doelstellingen te behalen moeten we ons behoeden voor de risico’s die hiermee gepaard gaan: Hacking, identiteitsfraude, datalekken (GDPR) Zorg voor sterke encryptie, regelmatige audits, en strikte GDPR-compliance. Vandalisme, diefstal, inbraak Overweeg veiligste oplossing, CCTV-installaties en gebruik plekken met sociale controle Uitsluiting van digitaal minder vaardige burgers Opleidingen, ondersteuning en alternatieve afhaalopties aanbieden Stroomuitval of defecten Zorg voor onderhoudscontracten met snelle responstijd Extra werklast, initiële kostprijs en logistiek Samenwerking en planning tussen gemeenten, kosten delen en subsidies zoeken. Beperkingen door wetgeving Samenwerken tussen verschillende overheden en voldoen aan wet- en regelgeving Laag gebruik door verhouding met andere 24/7 oplossingen Strategische keuzes maken door oplossingen met elkaar vergelijken Verlies van prioriteit door bezuinigingen Bewijzen van de kostenbesparing en efficiëntie van de oplossing Consolidatie MOSCOW analyse Algemeen: Bevraging toont behoefte aan 24/7 dienstverlening met focus op vereenvoudiging en E-inclusie, waarbij veiligheid en efficiëntie centraal staan Must have Toegangkelijkheid en klantgerichte dienstverlening: Burgers moeten via meerdere kanalen (fysiek en digitaal) 24/7 toegang hebben tot diensten, met veilige authenticatie zoals multi-factor authenticatie (MFA). E-inclusie: Alle digitale diensten moeten voldoen aan toegankelijkheidsnormen voor kwetsbare groepen. Veiligheid en gebruikersauthenticatie: Fysieke beveiling zowel tegen vandalisme, waterschade, en andere mogelijke onvoorziene omstandigheden. Veilige authenticatie mogelijkheden om fraude en diefstal te voorkomen. Interbestuurdelijke samenwerking: Er moeten samengewerkt worden tussen lokale en hogere overheden om een uniforme dienstverlening te waarborgen. Beschikbaarheid dienstverlening: Dienstverleningsrocessen moeten zo veel mogelijk 24/7 beschikbaar gemaakt worden. Downtime van de systemen moet maximaal vermeden worden Monitoring en opvolging: De afhandeling van het process moet zo veel mogelijk geautomatiseerd worden. Mederwerkers moeten op de hoogte gebracht worden van de afhaling of teruggave van de documenten of producten. Betalingen en uitchecken: Mogelijkheid om te betalen voor de geleverde diensten en producten in of uit te checken. Should have Snelle beschikbaarheid en opvolging: Producten moeten zo snel mogelijk na aanvraag beschikbaar gesteld worden. Multifunctionele identificatie: Documenten ophalen via app, e-ID, etc. 24/7 klantenondersteuning: Virtuele helpdesk met chatbot of FAQs Geïntegreerde oplossing: Maximale integratie bestaande sytemen of bouwstenen Uitbreiding in aanbod: Grote materialen zoals evenement apperatuur, tijdelijke verkeersborden, etc... Could have Uitgebreide features: Automatisering klantenondersteuning via AI, biometrische herkenning Uitgebreide integratie: Afdrukken van documenten, tickets, aanvragen andere diensten, resertvaties en afspraken maken Won't have Volledige virtualisate: Volledig digitaal systeem zonder fysieke kaarten of documenten Uitbesteding aan externe postdiensten (IE bpost): Gemeente behoud controle over de systemen Uitgebreid inventaris systeem: Geen complexe inventaris systemen voor simpele processen Organisatie: processen, rollen en verantwoordelijkheden Om het 24/7 dienst verlening te organiseren, is er nood aan een samenwerkingsmodel met afspraken rond processen, rollen en verantwoordelijkheden. Samenwerkingsmodel Dit model legt de nadruk op samenwerking tussen lokale overheden en hogere overheden. Lokale overheden verzorgen de operationele ondersteuning, terwijl hogere overheden (Vlaanderen, Federaal) zorgen voor strategische richting en juridische kaders. Elke laag draagt bij aan veilige, toegankelijke en continue dienstverlening. Hieronder de belangrijkste aspecten voor succes : •Heldere verantwoordelijkheidsverdeling tussen lokale overheden, hogere overheden en ICT-dienstverleners. •Gestandaardiseerde communicatie en tools om samenwerking en monitoring te stroomlijnen. •Continue verbetering op basis van feedback van burgers en medewerkers. •Regelmatige evaluatie van beveiligings- en samenwerkingsstandaarden. •Flexibele infrastructuur voor snelle aanpassingen aan veranderende behoeften of regelgeving. Heldere operationele processen zijn nodig om 24/7 dienstverlening soepel te laten verlopen, van aanvraag tot ondersteuning. Strategische samenwerking en duidelijke beleidsrichtlijnen zijn essentieel voor een succesvolle implementatie van 24/7 dienstverlening. Een doelgerichte aanpak rond meldingen vergt de juiste rollen: Loket medewerker Loket medewerkers staan in voor de klanten contacten en dossier opvolging Behandelaar Staat in voor de verwerking en uitvoering van de aanvragen Projectteam Ontwikkelt en verbetert de 24-7 systemen Projectcoördinator Coördineert nieuwe implementaties Interbestuurlijke samenwerking Verantwoordelijk voor beleidskaders en regelgeving Beheerder Verantwoordelijk voor het beheer, onderhoud en veiligheid van het systeem Beslisser Zorgt voor strategische besluitvoering rond nieuwe implementaties Expertise team Voorziet expertise rond naleving van privacy, business expertise, e-inlcusie en andere relevante kennis. Service level manager Beheert de service levels en is verantwoordelijk voor de processen Ondersteund door effectieve operationele werking met duidelijke rollen en verantwoordelijkheden Hiertoe werd een RACI-schema opgesteld: Een onderbouwde oplossing zet in op de onderstaande processen en bijhorende functies voor de organisatie: Gestuurd door een transversale samenwerking tussen de verschillende overheidslagen verantwoordelijk voor beleidsvoering en innovatie Een onderbouwde oplossing zet in op de onderstaande processen en bijhorende functies voor de organisatie. Miro bord Het Miro bord kan je consulteren via deze link . Volgende stappen Verwerking van de input van de brainstorm oefening. Verder onderzoek en voorbereiding van de volgende thematische werkgroep. Publicatie op de Kennishub. Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2024-09-03 9u-12u Teams Functionaliteiten werkgroep Data en informatie werkgroep 2024-10-01 9u-12u Teams Applicatie componenten werkgroep Functionele werkgroep 2024-11-19 9u-12u Teams +
80 776 1727 aantal paginas = 1462, aa … 80 776 1727 aantal paginas = 1462, aantal recreated = 581 Overleg aantal paginas = 0, aantal recreated = 0 VlocaTraject aantal paginas = 91, aantal recreated = 54 CoCreatieAanvraag aantal paginas = 21, aantal recreated = 21 VlocaSessie aantal paginas = 19, aantal recreated = 17 Draaiboek aantal paginas = 52, aantal recreated = 50 ArchitectuurComponent aantal paginas = 17, aantal recreated = 17 ArchitectuurBouwlaag aantal paginas = 13, aantal recreated = 12 ArchitectuurCapaciteit aantal paginas = 0, aantal recreated = 0 ArchitectuurSysteemeigenschap aantal paginas = 0, aantal recreated = 0 Deliverable aantal paginas = 51, aantal recreated = 23 Nieuws aantal paginas = 1, aantal recreated = 1s aantal paginas = 1, aantal recreated = 1 +
<a class="nav-link " id="-tab" data-toggle="pill" href="#" role="tab" aria-controls="" aria-selected="true"></a> +
<iframe title="Deelnemende VLOCA-bestur … <iframe title="Deelnemende VLOCA-besturen" aria-label="Map" id="datawrapper-chart-fD4ke" src=" https://datawrapper.dwcdn.net/fD4ke/1/ " scrolling="no" frameborder="0" style="width: 0; min-width: 100% !important; border: none;" height="300" data-external="1"></iframe> <script type="text/javascript">!function(){"use strict";window.addEventListener("message",(function(e){if(void 0!==e.data["datawrapper-height"]){var t=document.querySelectorAll("iframe");for(var a in e.data["datawrapper-height"])for(var r=0;r<t.length;r++){if(t[r].contentWindow===e.source)t[r].style.height=e.data["datawrapper-height"][a]+"px"}}}))}(); </script>.height=e.data["datawrapper-height"][a]+"px"}}}))}(); </script> +
<iframe width="560" height="315" src="" title="Video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> +
<img src=" https://vloca-images.s3.amaz … <img src=" https://vloca-images.s3.amazonaws.com/f/f9/TestPublicatieArchitectuur1.svg " alt="Workplace" usemap="#workmap" width="1080px"> <map name="workmap"> <area shape="rect" coords="706,694,886,847" href="" title="CoT2021.013.4.Ontsluiten van alle mogelijke data (via APIs bvb) naar commerciele 'logistieke planningstools' om die data te integreren, of nieuwe VAS toe te laten."> <area shape="rect" coords="502,694,682,847" href="" title="CoT2021.013.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."> <area shape="rect" coords="298,694,478,847" href="" title="CoT2021.013.2.Een 'dashboard' voor de 'vervoerder' om zijn transport te registreren en 'toestemming' te krijgen met een voorgestelde routeplanning "> <area shape="rect" coords="95,690,275,847" href="" title="CoT2021.013.1.Een 'cockpit' bouwen die het vrachtverkeer volledig weergeeft om inzichten te verschaffen mbt beleidsvorming, sturing en evaluatie"> <area shape="rect" coords="10,94,215,287" href="" title="CoT.2021.013.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)"> <area shape="rect" coords="802,106,1067,299" href="" title="CoT.2021.013.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."> <area shape="rect" coords="478,574,611,629" href="" title="Stuurgroep Slimme stadsdistributie"> <area shape="rect" coords="310,574,430,629" href="" title="Stad Antwerpen"> <area shape="rect" coords="478,490,611,545" href="" title="Stad Leuven"> <area shape="rect" coords="310,490,430,545" href="" title="Stad Hasselt"> <area shape="rect" coords="274,442,682,647" href="" title="Intern"> <area shape="rect" coords="286,358,406,413" href="" title="Vlaamse Milieu Maatschappij"> <area shape="rect" coords="550,286,670,341" href="" title="Verenigingen van ondernemingen"> <area shape="rect" coords="418,286,538,341" href="" title="Universiteiten"> <area shape="rect" coords="286,286,406,341" href="" title="Politie"> <area shape="rect" coords="550,211,670,266" href="" title="Onderzoeksinstellingen"> <area shape="rect" coords="418,211,538,266" href="" title="Mobiliteit en MaaS"> <area shape="rect" coords="286,202,406,275" href="" title="Leveringsdiensten en transportbedrijven"> <area shape="rect" coords="550,130,670,185" href="" title="Inwoners binnenstad"> <area shape="rect" coords="418,130,538,185" href="" title="Handelaars binnenstad"> <area shape="rect" coords="286,130,406,185" href="" title="Department Mobiliteit en Openbare Werken"> <area shape="rect" coords="550,46,670,101" href="" title="Andere steden en gemeenten"> <area shape="rect" coords="286,46,406,101" href="" title="Agentschap Binnenlands Bestuur"> <area shape="rect" coords="418,46,538,101" href="" title="OSLO"> <area shape="rect" coords="274,10,682,419" href="" title="Extern"> </map>tle="Agentschap Binnenlands Bestuur"> <area shape="rect" coords="418,46,538,101" href="" title="OSLO"> <area shape="rect" coords="274,10,682,419" href="" title="Extern"> </map> +
<style> /* #vloca_all { opacity: 0.7 … <style>/* #vloca_all { opacity: 0.7 } */.vloca-frame:hover #vloca_all { filter: grayscale(100%); } .vloca-layer > img { width: 700px; }.vloca-layer { position: absolute; }</style> <script src=" https://code.jquery.com/jquery-3.6.0.min.js " integrity="sha256-/xUj+3OJU5yExlq6GSYGSHk7tPXikynS7ogEvDej/m4=" crossorigin="anonymous"></script> <img src="/imec_files/kh_nav/vlocanavmap.png" id="vloca_all" > <img class="vloca-image" src="/imec_files/kh_nav/bouwlaag.png" id="vloca_bouwlaag"> <img class="vloca-image" src="/imec_files/kh_nav/architectuur.png" id="vloca_architectuur"> <img class="vloca-image" src="/imec_files/kh_nav/component.png" id="vloca_component"> <img class="vloca-image" src="/imec_files/kh_nav/capaciteit.png" id="vloca_capaciteit"> <img class="vloca-image" src="/imec_files/kh_nav/vereisten.png" id="vloca_vereisten"> <img class="vloca-image" src="/imec_files/kh_nav/randvoorwaarden.png" id="vloca_randvoorwaarden"> <img class="vloca-image" src="/imec_files/kh_nav/standaard.png" id="vloca_standaard"> <img class="vloca-image" src="/imec_files/kh_nav/organisatie.png" id="vloca_organisatie"> <img class="vloca-image" src="/imec_files/kh_nav/systeemeigenschappen.png" id="vloca_systeemeigenschappen"> <img class="vloca-image" src="/imec_files/kh_nav/principes.png" id="vloca_principes"> <img class="vloca-image" src="/imec_files/kh_nav/vlocausecase.png" id="vloca_vlocausecase"> <img src="/imec_files/kh_nav/emptynav.png" usemap="#image-map"> <map name="image-map" id="image-map"> <area href="VLOCA_Trajecten" class="vloca_area" id="vlocausecase" coords="1081,193,1423,390" shape="rect"> <area class="vloca_area" id="principes" href="VLOCA_Charter" coords="2514,227,2862,390" shape="rect"> <area class="vloca_area" id="organisatie" href="Organisaties" coords="135,562,476,755" shape="rect"> <area class="vloca_area" id="randvoorwaarden" href="Randvoorwaarden" coords="797,559,1138,746" shape="rect"> <area class="vloca_area" id="vereisten" href="Vereisten" coords="1356,559,1698,752" shape="rect"> <area class="vloca_area" id="capaciteit" href="Capaciteiten" coords="2012,556,2357,755" shape="rect"> <area class="vloca_area" id="standaard" href="Standaarden" coords="138,1073,482,1272" shape="rect"> <area class="vloca_area" id="component" href="Componenten" coords="1045,1076,1383,1266" shape="rect"> <area class="vloca_area" id="bouwlaag" href="Bouwlagen" coords="1668,1076,2006,1269" shape="rect"> <area class="vloca_area" id="architectuur" href="Open_Smart_City_Architectuur" coords="2285,1079,2626,1275" shape="rect"> <area class="vloca_area" id="systeemeigenschappen" href="Systeemeigenschappen" coords="2923,1073,3273,1275" shape="rect"> </map> <script type="text/javascript"> class ResponsiveImageMap { constructor(map, oldWidth, newWidth) { this.originalWidth = oldWidth; this.newWidth = newWidth this.areas = []; for (const area of map.getElementsByTagName('area')) { this.areas.push({ element: area, originalCoords: area.coords.split(',') }); } window.addEventListener('resize', e => this.resize(e)); this.resize(); } resize() { const ratio = this.newWidth / this.originalWidth; for (const area of this.areas) { const newCoords = []; for (const originalCoord of area.originalCoords) { newCoords.push(Math.round(originalCoord * ratio)); } area.element.coords = newCoords.join(','); } return true; }; } $(document).ready(function(){ $('.vloca-image').hide(); var map = document.getElementById('image-map'); new ResponsiveImageMap(map, 3432, 700); $('.vloca_area').mouseover(function() { $('#vloca_' + $(this)[0].id).fadeIn(200); }).mouseout(function(){ $('#vloca_' + $(this)[0].id).fadeOut(100); }); });</script>yId('image-map'); new ResponsiveImageMap(map, 3432, 700); $('.vloca_area').mouseover(function() { $('#vloca_' + $(this)[0].id).fadeIn(200); }).mouseout(function(){ $('#vloca_' + $(this)[0].id).fadeOut(100); }); }); </script> +
<style> /* #vloca_all { opacity: 0.7 … <style>/* #vloca_all { opacity: 0.7 } */.vloca-frame:hover #vloca_all { filter: grayscale(100%); }.vloca-layer > img { width: 700px; }.vloca-layer { position: absolute; } </style> <script src=" https://code.jquery.com/jquery-3.6.0.min.js " integrity="sha256-/xUj+3OJU5yExlq6GSYGSHk7tPXikynS7ogEvDej/m4=" crossorigin="anonymous"></script> <img src="/imec_files/tech_donut/all.png" id="vloca_all" > <img class="vloca-image" src="/imec_files/tech_donut/applications.png" id="vloca_applications"> <img class="vloca-image" src="/imec_files/tech_donut/network.png" id="vloca_network"> <img class="vloca-image" src="/imec_files/tech_donut/infrastructure.png" id="vloca_infrastructure"> <img class="vloca-image" src="/imec_files/tech_donut/monitoring.png" id="vloca_monitoring"> <img class="vloca-image" src="/imec_files/tech_donut/security.png" id="vloca_security"> <img class="vloca-image" src="/imec_files/tech_donut/devices.png" id="vloca_devices"> <img class="vloca-image" src="/imec_files/tech_donut/personal_data.png" id="vloca_personal"> <img class="vloca-image" src="/imec_files/tech_donut/iam.png" id="vloca_iam"> <img class="vloca-image" src="/imec_files/tech_donut/compute.png" id="vloca_compute"> <img class="vloca-image" src="/imec_files/tech_donut/process.png" id="vloca_process"> <img class="vloca-image" src="/imec_files/tech_donut/broker.png" id="vloca_broker"> <img class="vloca-image" src="/imec_files/tech_donut/service.png" id="vloca_service"> <img class="vloca-image" src="/imec_files/tech_donut/capture.png" id="vloca_capture"> <img class="vloca-image" src="/imec_files/tech_donut/storage.png" id="vloca_storage"> <img src="/imec_files/tech_donut/empty.png" usemap="#image-map"> <map name="image-map" id="image-map"> <area href="Devices" class="vloca_area" id="devices" coords="58,498,66,583,89,654,116,713,154,771,218,836,273,876,249,914,185,868,121,804,75,735,41,662,20,591,13,499" shape="poly"> <area href="Security" class="vloca_area" id="security" coords="330,953,404,974,494,984,596,973,668,954,736,921,711,881,648,911,583,929,495,937,415,928,349,910,277,879,255,917" shape="poly"> <area href="Monitoring" class="vloca_area" id="monitoring" coords="717,877,745,918,822,859,883,796,927,725,961,643,978,569,982,501,938,500,932,563,914,633,884,704,846,770,789,826" shape="poly"> <area href="Infrastructure" class="vloca_area" id="infrastructure" coords="743,80,796,114,861,177,922,262,953,330,974,409,981,494,937,494,931,412,907,339,876,277,829,210,767,151,718,119" shape="poly"> <area href="Network & connectivity" class="vloca_area" id="network" coords="258,77,280,116,340,86,414,67,490,58,565,64,638,83,712,115,738,75,653,37,571,17,486,13,401,22,325,44" shape="poly"> <area href="Applications" class="vloca_area" id="applications" coords="252,79,273,117,219,156,164,210,116,283,86,347,66,409,57,491,13,490,23,404,42,332,75,259,128,180,189,124" shape="poly"> <area href="?curid=956" class="vloca_area" id="personal" coords="313,647,339,674,372,699,274,863,235,838,194,801,162,770" shape="poly"> <area href="?curid=955" class="vloca_area" id="iam" coords="380,703,408,716,441,727,401,917,357,902,311,884,278,869" shape="poly"> <area href="?curid=958" class="vloca_area" id="compute" coords="449,730,525,736,599,715,647,686,688,644,716,595,732,550,919,586,905,639,883,693,843,756,784,820,716,868,641,902,569,922,485,928,405,916" shape="poly"> <area href="?curid=957" class="vloca_area" id="process" coords="731,542,917,576,929,493,919,407,900,342,868,275,804,192,668,330,698,364,720,413,735,474" shape="poly"> <area href="?curid=960" class="vloca_area" id="broker" coords="379,82,434,268,497,258,556,266,617,289,664,325,801,189,736,138,661,96,565,70,473,65" shape="poly"> <area href="?curid=959" class="vloca_area" id="service" coords="370,87,427,271,382,289,349,313,316,341,294,375,124,280,177,207,262,136,312,108" shape="poly"> <area href="?curid=963" class="vloca_area" id="capture" coords="124,285,286,380,263,441,256,497,264,554,279,599,309,642,159,763,116,697,82,615,68,518,68,436,89,357" shape="poly"> <area href="?curid=954" class="vloca_area" id="storage" coords="499,496,225" shape="circle"> </map> <script type="text/javascript"> class ResponsiveImageMap { constructor(map, oldWidth, newWidth) { this.originalWidth = oldWidth; this.newWidth = newWidth this.areas = []; for (const area of map.getElementsByTagName('area')) { this.areas.push({ element: area, originalCoords: area.coords.split(',') }); } window.addEventListener('resize', e => this.resize(e)); this.resize(); } resize() { const ratio = this.newWidth / this.originalWidth; for (const area of this.areas) { const newCoords = []; for (const originalCoord of area.originalCoords) { newCoords.push(Math.round(originalCoord * ratio)); } area.element.coords = newCoords.join(','); } return true; }; } $(document).ready(function(){ $('.vloca-image').hide(); var map = document.getElementById('image-map'); new ResponsiveImageMap(map, 1000, 700); $('.vloca_area').mouseover(function() { $('#vloca_' + $(this)[0].id).fadeIn(200); }).mouseout(function(){ $('#vloca_' + $(this)[0].id).fadeOut(100); }); });</script>hide(); var map = document.getElementById('image-map'); new ResponsiveImageMap(map, 1000, 700); $('.vloca_area').mouseover(function() { $('#vloca_' + $(this)[0].id).fadeIn(200); }).mouseout(function(){ $('#vloca_' + $(this)[0].id).fadeOut(100); }); }); </script> +
A digital twin is a virtual representation … A digital twin is a virtual representation of physical systems (traffic, water, air etc.) and physical assets (buildings, resources etc.) that can make simulations, tests and predictions of planned actions almost in real-time. A twin is essentially used to get information on an action in a simulated world, before the action is carried out in the real world, opening enormous opportunities for citizens, companies and authorities alike. At LIST we are working on a digital twin of Luxembourg, which would be the world's first-ever nationwide platform. Such a twin would catapult Luxembourg into a hub of excellence in terms of digital development, gaining attractiveness for both international industrials that would like to introduce their products and services onto the European market and academic players that seek a digital-friendly environment to develop their research and innovations. For researchers : a unique, open innovation platform For companies : a testbed for digital services and products For public authorities : a tool for taking better decisions For citizens : an instrument to obtain a better quality of lifetrument to obtain a better quality of life +
ANPR staat voor Automatic Number Plate Rec … ANPR staat voor Automatic Number Plate Recognition of Automatische kentekenplaatherkenning (of nummerplaatherkenning). Dit is een techniek die gebruikmaakt van optische tekenherkenning om kentekenplaten te kunnen lezen op voertuigen. [1] ↑ https://nl.wikipedia.org/wiki/Automatische_kentekenplaatherkenning/Automatische_kentekenplaatherkenning +
ANYWAYS is een Belgisch softwarehuis en co … ANYWAYS is een Belgisch softwarehuis en consultancy met een bijzondere expertise op het vlak van advanced web-based oplossingen gerelateerd aan mobiliteit en verkeer. Door een combinatie van een eigen ontwikkelde open source routeplanner en Open Data van mobiliteit maakt ANYWAYS tools om inzichten te bekomen in de complexiteit van mobiliteit en er interactief over te communiceren. ANYWAYS heeft specifiek mobiliteitsexpertise met focus op verkeerskundige engineering van complexe projecten (stationsomgevingen), ITS (Intelligent Transport Services) en routeplanning.gent Transport Services) en routeplanning. +
API is de afkorting voor Application Progr … API is de afkorting voor Application Programming Interface en meer info is terug te vinden op [1] Voorbeeld Situatieschets Een concreet voorbeeld van het gebruik van een API wordt hieronder geschetst voor een toepassing in de waterwereld. Een organisatie heeft temperatuur en pH sensoren geplaatst op verschillende plaatsen in een rivier. Via enkele technische stappen belanden deze data in een database.Stel dat de data als volgt wordt opgeslagen in de database: Bevraging database De organisatie zou graag deze data bevraagbaar maken via een website. Deze database zou via een SQL query bevraagd kunnen worden als volgt: select value, timestamp from measurements m join sensor s on s.id = m.sensor_id join location l on l.id = s.location_id where l.name = "stiemerbeek_loc_01"; Indien iemand dezelfde query zou willen doen op de database, kan dit ook zonder dat de query geschreven moet worden in SQL: en dit via een API. De API in gebruik De api zou bijvoorbeeld toelaten dat iemand naar volgende web url surft: www.fictiefvoorbeeld.be/query?location=stiemerbeek_loc_01?data=all en op deze url zou er dan dezelfde data verschijnen als men de SQL query rechtstreeks uitvoerde op de database.Enkel moet de gebruiker nu de "regels" van de api kennen, meer bepaald dat: na query?location= een locatienaam ingevuld kan worden, en na ?data= men kan specifieren of men alle data wil opvragen of niet . de code achter de API zelf vertaalt deze url specificaties naar de gewenste query in SQL formaat, bevraagt de database, en stuurt de resultaten terug naar de gebruiker: ↑ https://nl.wikipedia.org/wiki/Application_programming_interfaceiki/Application_programming_interface +
API-led API-led connectiviteit is een … API-led API-led connectiviteit is een methodische manier om gegevens met applicaties te verbinden via herbruikbare en doelgerichte API's. Deze API's zijn ontwikkeld om een specifieke rol te vervullen: het ontsluiten van gegevens uit systemen, het samenbrengen van gegevens in processen of het opzetten van ervaringen. Wanneer iedereen in de organisatie gebruik maakt een API-led connectiviteit aanpak, zorgt dat ervoor dat iedereen ook direct toegang krijgt tot de beste API’s om applicaties en projecten op te leveren middels discovery, self-service en hergebruik. API-led connectiviteit is niet alleen afhankelijk van *drie categorieën (experience, process en system API’s) *herbruikbare API's om nieuwe services en mogelijkheden samen te stellen, maar decentraliseert en democratiseert ook de toegang tot gegevens uit de organisatie. Centrale IT produceert herbruikbare API's en ontgrendelt daarbij belangrijke systemen, waaronder legacy-applicaties, databronnen en SaaS-apps. Centrale IT en andere teams kunnen deze API's vervolgens hergebruiken en informatie op procesniveau samenbrengen. Vervolgens kunnen app-ontwikkelaars al deze herbruikbare API's makkelijk terugvinden in onze marktplaats genaamd Exchange en hergebruiken waardoor er op de experience laag API's en uiteindelijk de eindtoepassingen ontstaat. Deze API-led benadering verhoogt de flexibiliteit, snelheid en productiviteit. Wanneer iedereen in de organisatie gebruik maakt een API-led connectiviteit aanpak, zorgt dat ervoor dat iedereen ook direct toegang krijgt tot de beste API’s om applicaties en projecten op te leveren middels discovery, self-service en hergebruik. API-led connectiviteit is niet alleen afhankelijk van drie categorieën (experience, process en system API’s) herbruikbare API's om nieuwe services en mogelijkheden samen te stellen, maar decentraliseert en democratiseert ook de toegang tot gegevens uit de organisatie. Centrale IT produceert herbruikbare API's en ontgrendelt daarbij belangrijke systemen, waaronder legacy-applicaties, databronnen en SaaS-apps. Centrale IT en andere teams kunnen deze API's vervolgens hergebruiken en informatie op procesniveau samenbrengen. Vervolgens kunnen app-ontwikkelaars al deze herbruikbare API's makkelijk terugvinden in onze marktplaats genaamd Exchange en hergebruiken waardoor er op de experience laag API's en uiteindelijk de eindtoepassingen ontstaat. Deze API-led benadering verhoogt de flexibiliteit, snelheid en productiviteit. Waarom is API-led connectiviteit belangrijk? API-led connectiviteit is een belangrijke integratiestrategie omdat de technologieën die [[::Category:Organisaties| Organisaties]] gebruiken om met hun klanten, werknemers en partners in contact te komen drastisch zijn veranderd. De convergentie van technologieën als IoT, SaaS, big data, social, mobiel en API's bieden krachtige nieuwe tools waarmee [[::Category:Organisaties| Organisaties]] meer kunnen doen: nieuwe inkomstenstromen kunnen ontgrendelen, hun klanten beter begrijpen en sneller kunnen innoveren. Om dat succesvol te doen, moeten ze echter wel deze nieuwe technologieën kunnen integreren. Traditioneel worden deze integraties gedaan via point-to-point verbindingen, op een ad hoc manier, wanneer een project dat vereist. Dit leidt tot gecompliceerde en broze verbindingen die vatbaar zijn voor storingen en die veel IT-tijd en middelen vergen om onderhouden te worden. Bovendien is de frequentie waarmee deze nieuwe verbindingen of integraties veranderen ook toegenomen. Terwijl het database-schema van een kernsysteem in een bank slechts op jaarbasis veranderend, kunnen de vereisten van de toepassingen voor online en mobiel bankieren die op die systemen zijn aangesloten, wekelijks, dagelijks of zelfs elk uur veranderen. De snelheid van deze veranderingen kan niet worden opgevangen door traditionele point-to-point-integratiemethoden. Een andere benadering is hiervoor vereist: API-led connectiviteit. Hoe vermindert API-led connectiviteit de werklast van IT? API-led connectiviteit speelt een belangrijke rol bij het verminderen van de werklast van IT. Dit komt doordat IT vaak de taak heeft om deze nieuwe technologieën te implementeren en de nodige wijzigingen aan te brengen, om legacy-systemen te onderhouden (en hun verbindingen met andere systemen). Ze moeten steeds en sneller projecten opleveren en hun middelen blijven vaak constant of groeien niet in dezelfde grootorde. Wat uiteindelijk resulteert in, wat wij noemen, de IT-delivery gap: Hoe wordt API-led connectiviteit mogelijk gemaakt? API-led connectiviteit biedt een benadering voor het verbinden en beschikbaar stellen van API’s. In plaats van integraties op te zetten op een point-to-point manier, wordt elke API een beheerde, moderne API, die makkelijk vindbaar is voor andere in de organisatie, zonder de controle te verliezen. De API's die worden gebruikt in een API-led benadering van connectiviteit vallen in drie categorieën: Syteem API's - Deze hebben toegang tot de kernsystemen en zorgen ervoor dat de complexiteit of eventuele wijzigingen geen impact hebben op de gebruiker. Dit zorgt er ook voor, dat eenmaal gebouwd, gebruikers toegang kunnen krijgen tot gegevens van deze kernsystemen zonder dat ze het onderliggende systeem moeten leren kennen en zo kunnen ze deze API's gemakkelijk hergebruiken in meerdere projecten. Process API's - Deze API's werken samen met en geven vorm aan gegevens binnen een systeem of enkele systemen (het opsplitsen van gegevenssilo's); en worden hier gemaakt zonder afhankelijk te zijn van de kernsystemen waaruit dee gegevens afkomstig zijn, evenals de front-end kanalen via welke de gegevens worden geleverd. Experience API's - Experience API's zijn het middel waarmee gegevens opnieuw kunnen worden geconfigureerd, zodat ze op een makkelijker manier kunnen worden geconsumeerd door de beoogde doelgroep. Dit allemaal vanuit een gemeenschappelijke gegevensbron, in plaats van afzonderlijke point-to-point integraties voor elk kanaal in te stellen. Een Experience API wordt meestal gemaakt met de API-first design principes, waarbij de API is ontworpen met de specifieke gebruikerservaring in gedachten. Door API's op deze manier te bouwen en te organiseren, en ze vervolgens vindbaar en beschikbaar te stellen voor de organisatie via self-service. Maakt het mogelijk voor andere teams in de organisatie om deze API's opnieuw samen te stellen en aan te passen naar de veranderende behoeften van het team of het deel van de organisatie. Hoe zou API-led connectiviteit werken in mijn organisatie? API-led connectiviteit is een cruciaal om de ‘IT-delivery gap’ te dichten. Laten we het voorbeeld nemen van een IT team dat een nieuwe webapp moet ontwikkelen om direct inzicht te geven aan vertegenwoordigers over de orderstatus en ordergeschiedenis van hun klanten. Laten we voor dit voorbeeld aannemen dat de klantgegevens in SAP en in Salesforce zitten; de inventaris gegevens in SAP; en ordergegevens in SAP e-commerce systeem. Traditioneel zou dit worden opgezet met een point-to-point-integratiebenadering, het IT-team verzameld de klantgegevens uit SAP en Salesforce dmv custom code. Vervolgens worden de geaggregeerde klantgegevens verder gecombineerd met ordergegevens uit het e-commercesysteem om zowel de orderstatus als de ordergeschiedenis te produceren - met opnieuw custom code. Vervolgens worden deze twee gegevensbronnen aan elkaar gekoppeld via een webapp-API. Dit project kan als een succes worden beschouwd; het werd op tijd opgeleverd, binnen budget en het heeft de juiste functionaliteiten. Maar een paar weken later eist het verkoopteam, dat vaak onderweg is, dat deze functionaliteit beschikbaar wordt gesteld op hun mobiele telefoons. Het IT-team moet nu dus opnieuw vanaf nul beginnen. De ontwikkelaars die de app bouwen, kunnen niet verder zonder dat zij toegang krijgen tot de juiste gegevens. Hoewel de meeste ontwikkelaars weten dat een point-to-point-integratiestrategie, een kortzichtige benadering is, rechtvaardigen ze dit gezien de intense tijdsdruk. Vaak wordt dit probleem zelfs groter bij her samenwerken met consultants, omdat zij weinig geneigd zijn om op lange termijn na te denken. Omdat verandering iets constant is geworden, wordt een point-to-point integratiestrategie over tijd erg duur of bijna onmogelijk. Zoals hieronder te zien is, begint het bekende "spaghetticode" -patroon vorm te krijgen. Wanneer IT-teams echter een API-led aanpak gebruiken, kunnen ze alles wat ze gebouwd hebben voor het eerste project (Web app) hergebruiken voor de mobile app. Want er zijn nu herbruikbare API’s gemaakt op basis van systeem en proces-API's, waardoor al het werk dat nodig is om ze opnieuw te bouwen, wordt geëlimineerd. Het maken van de mobiele app is dus een kwestie van de verschillende systemen op elkaar laten aansluiten. Dit maakt het ook veel gemakkelijker om te innoveren en nieuwe services toe te voegen. Zoals in dit voorbeeld, het toevoegen van informatie over de verzendstatus. Op vrijwel dezelfde manier waarop de orderstatus en de ordergeschiedenis werden opgezet. Dit bespaart tijd, geld, middelen en zorgt ervoor dat projecten sneller kunnen worden opgeleverd. Zoals u kunt zien, gebruikt API-led connectiviteit enkele van de principes van een service georiënteerde architectuur. De API-led connectiviteit benadering stelt ontwikkelaars in heel de organisatie in staat herbruikbare services samen te stellen en te hergebruiken om projecten te bouwen die zij nodig achten, in plaats van de top-down, zwaargewicht dictaten van traditionele SOA-benaderingen. De methode waarop deze middelen in een organisatie worden gebruikt, is net zo belangrijk voor de API-led connectiviteit benadering als de middelen zelf. Wat zijn de zakelijke voordelen van API-led connectiviteit? Een API-led connectiviteit benadering helpt niet alleen met het op tijd opleveren van uw huidige IT-projecten, het zorgt er ook voor dat u dmv het bouwen van herbruikbare middelen bij uw volgende projecten, tijd en geld zult besparen. Er wordt een infrastructuur gecreëerd die future-proof is. Gemiddeld zien we dat de toegenomen flexibiliteit en snelheid die wordt geboden door API-led connectiviteit ertoe leidt dat projecten 3-5x sneller worden opgeleverd en de teamproductiviteit verhoogt met 300% in vergelijking met andere integratiemethodes. +