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

Air purification technologies - UAntwerpen +
Air quality in cities part 1 +
Air quality map - VITO +
Architecturale blauwdruk +
Architecturale blauwdruk 24/7 dienstverlening +
Architectuur +
Beschrijving Power point Water workshop1 slide2.JPG +
Beschrijving Slide1 of PowerPoint presentation for Water workshop1 +
Beschrijving Water kennismaking presentation +
Beschrijving Water workshop0 kennismaking presentation in pdf format +
Beschrijving Welk meetprincipe past bij uw applicatie +
Beschrijving power point Water workshop1 slide3 +
Beschrijving van de opbouw van het model +
Bevat componenten Bouwlagen +
Boolean +
Building trust and value - COOCK workshop +
Burgerparticipatie +
Aantal gefaalde stofzuigers binnengebracht bij repair cafés, per repair status ( eindelven, gemaakt, repareerbaar maar nog niet mogelijk gezien ontbrekende wisselstukken, handleiding,…) en per leeftijd. +
About Digital technology is changing the … About Digital technology is changing the way we plan, build, maintain and use our social and economic infrastructure. Building Information Modelling (BIM) is already transforming the UK construction industry, using information management processes to gain efficiencies in the design and construction processes. Over the next decade this technology will combine with digital twins and the Internet of Things – sensors, advanced data analytics, data-driven manufacturing and the digital economy – enabling us to plan infrastructure more effectively, to build it at lower cost and to operate and maintain it for better performance over a longer lifespan. The Centre for Digital Built Britain (CDBB) is a partnership between the Department for Business, Energy & Industrial Strategy (BEIS) and the University of Cambridge, established by HM Government in the 2017 Autumn Budget as the home of the UK BIM and Digital Built Britain Programmes. It seeks to deliver a smart digital economy for infrastructure and construction, and to transform the UK construction industry’s approach to the way we plan, build, maintain and use our social and economic infrastructure for the future. CDBB is a member of the Construction Innovation Hub, alongside the Building Research Establishment (BRE) and the Manufacturing Technology Centre (MTC), and we collaborate with other partners in the Transforming Construction Sector Deal. It is also home to a number of UK government programmes including the UK BIM Programme, National Digital Twin Programme and parts of the Global Infrastructure Programme. The National Digital Twin Programme (NDTP), launched by HM Treasury in July 2018 to deliver key recommendations of the National Infrastructure Commission (2017) 'Data for the Public Good' report. Our work toward a digital built Britain seeks to digitise the entire life-cycle of our built assets finding innovative ways of delivering more capacity out of our existing social and economic infrastructure, dramatically improving the way these assets deliver social services to deliver improved capacity and better public services. Above all, it will enable citizens to make better use of the infrastructure we already have. Mission The mission of CDBB is to develop and demonstrate policy and practical insights that will enable the exploitation of new and emerging technologies, data and analytics to enhance the natural and built environment, thereby driving up commercial competitiveness and productivity, as well as citizen quality of life and well-being. Working Groups Digital Framework Task Group (DFTG) The DFTG was launched by HM Treasury in July 2018 to steer and guide the successful development and adoption of the Information Management Framework for the Built Environment. The framework will establish the building blocks to enable effective information management across the built environment and will pave the way for the development of the national digital twin. The DFTG is made up of senior leaders from industry, government and academia. Home Nations Working Group The Home Nations Working Group (HNWG) ensures that the benefits of effective information management are shared across England, Scotland, Wales and Northern Ireland. Formed in 2018, it brings together the four UK national BIM programmes to develop a consistent approach and to promote our vision of a digital built Britain. The HNWG provides a platform to: Enable the sharing of BIM knowledge and good practice between nations; Support the implementation of the UK BIM Framework (including ISO19650) across the UK and develop tools to facilitate this including a Home Nations Working Group Government Soft Landings Configurator Manage the interface between CDBB and the various devolved UK Government BIM and digital built environment programmes. Buildings Client Group The Buildings Client Group is a cross-sector leadership community working together to stimulate effective changes across the built environment. We aim to connect individuals who are leading digital adoption within their organisation. We provide a secure forum for discussion and creating the future – demonstrating good practice and sharing real-world case studies to inform and lead the way. Representatives are owners and operators of buildings; sectors represented include: government, housing, education and commercial property. Local Authorities (LA) Working Group The LA Working Group was set up as a special interest group (SIG) in 2019, comprising local authorities, Home Nation Reps, the UK BIM Alliance and the Ministry of Housing, Communities and Local Government (MHCLG). Its membership grew to include more local authorities, government departments and agencies. The LA Working Group’s remit is to champion BIM adoption by producing information tools and guidance to help local councils embrace the transition. Public Sector ISO Transition Working Group (PSITWG) The Public Sector ISO Transition Working Group (PSITWG) first met in June 2019 and was hosted by CDBB until April 2021 with its aim to build on Public Sector BIM adoption to date and allowing Departments and Agencies to collectively plan a consistent transition to the new BS EN ISO 19650 standards to improve information management in Government construction and asset management. BIM Interoperability Expert Group Interoperability is vital to ensure that BIM continues to thrive and deliver key benefits – the BIM Interoperability Expert Group was hosted by CDBB until April 2021 and worked with stakeholders from a wide range of expertise and experience to support UK BIM adoption. +
Agenda Wie is wie? Toelichting VLO … Agenda Wie is wie? Toelichting VLOCA-traject (+- 15 min) Wie zijn we? Wat doen we? Introductie van het project (+- 15 min) Presentatie van thema, scoping en bevindingen voorstudie rond het traject Aanpak van het VLOCA traject Tijdlijn Afstemming workshops & deliverables (35 min) Bespreken welke workshops en deliverables van toepassing zijn Wat willen we uit elke werkgroep halen Focus op deliverables Vervolledigen stakeholderlijst (+- 15 min) Navraag bij betrokken partijen voor de stakeholders die van toepassing zijn bij de verschillende werkgroepen Wie nodig, wie cruciaal, aan wie denken we vanuit eigen context, met wie hebben we meeste contact, hoofd stakeholders benoemen, MOSCOW Kernteam: wie is wie? Izegem – Slim contactpunt voor de gemeenten Slim contactpunt als één digitale service organisatie zet in op een snellere, doelgerichtigere en kwalitatieve dienstverlening via één centraal gekozen punt. Hierbinnen werd een maturiteitsmodel opgericht rond de verschillende stromen die nodig zijn voor een meldingen platform. Izegem, Roeselare en Wingene Geraardsbergen – Dienstverlening van de toekomst Dienstverlening van de toekomst zet eveneens in op een op een efficiëntere en doelgerichtirgere dienstverlening. Binnen het traject wordt nieuw meldingen platform ingericht voor de lokale besturen. Aalst, Assenede, Buggenhout, Dendermonde, Kruisem, Maarkedal, Merelbeke, Wichelen en Zelzate Gent – Volgen van Linked Asset Gegevens (VLAG) VLAG werkt een prototype uit rond een centraal meldingen platform dat gebruik maakt van linked data en Vlaamse Smart Data spaces, gericht op een meer klantgerichte samenwerking tussen de stadsdiensten en beheerders van het openbaar domein. Antwerpen, Brugge, Knokke-Heist, Nijlen en Oostende Shift – Regionaal meldpunt SHIFT onderzoekt wat de rol kan zijn van een centraal meldingen platform binnen de regio Zuid-West-Vlaanderen. Harelbeke, Kortrijk, Zwevegem, Wevelgem, Deerlijk VLOCA-traject 1. Business werkgroep Gedurende de business werkgroep zullen we de probleemstelling, de context en motivatie van het project trachten te bevestigen. Vervolgens zullen we het kernproduct vastleggen, de doelgroep en de waarde die we willen creëren. Tot slot zullen we in kaart brengen welke activiteiten nodig zijn om tot deze waarde te komen. Doelgroep: Strategische profielen, architecten, business analisten 2. Functionaliteiten werkgroep Gedurende de functionaliteiten werkgroep zullen we dieper ingaan op de verschillende functies, taken en rollen die we nodig hebben om de activiteiten te realiseren. Doelgroep : Business experten, architecten, business analisten 3. Applicatie componenten werkgroep Gedurende de applicatie componenten werkgroep zullen we een landschapsanalyse uitvoeren en dieper ingaan op de manier waarop informatie gebruikt en gedeeld wordt en welke tools hieraan gelinkt kunnen worden. Doelgroep : IT experten, IT architecten, business analisten 4. Aanpak en risico’s werkgroep Gedurende de aanpak en risico's werkgroep zullen we verschillende scenario’s bekijken met betrekking tot de aanpak om tot een centraal meldingsplatform te komen. Deze scenario’s zullen we vervolgens evalueren op haalbaarheid, risico’s en impact. Doelgroep: Strategische profielen, architecten, business analisten Thema en bevindingen voorstudie Context en doelstellingen ‘Digitale Meldingen' is een initiatief gericht op het verbeteren en transparanter maken van de communicatie tussen burgers, lokale besturen en de Vlaamse overheid. Via een centraal meldingsplatform willen we burgers in staat stellen om hun zorgen te delen met de juiste instanties, zodat problemen met de dienstverlening efficiënt en gestructureerd kunnen worden aangepakt. Burgers willen hun bezorgdheid rond dienstverlening kunnen melden Doel van de Opdracht Dit traject focust op het verbeteren van de doorstroom van burgermeldingen tussen verschillende bestuursniveaus. Het onderzoekt de integratie van burgermeldingen, de rol van een centraal beheerplatform, en de verdeling van verantwoordelijkheden tussen de betrokken bestuursvormen. Dit met als doel de bovenlokale integratie met Vlaamse Overheidsdiensten en Intercommunales mogelijk te maken. Binnen het centraal meldingen platform wordt extra aandacht besteed aan de definitie van de verantwoordelijkheden en aan het waarborgen van een duidelijke rolverdeling tussen de verschillende partijen. Assumpties Lokale besturen zetten in op bovenlokale samenwerking Bereidheid van intercommunales en Vlaamse Overheid Betrokken partijen zetten in op service management principes en tools Het onderzoek richt zich op een meldingen platform dat vlot integreert met verschillende dienstverleningen Peter: met betrekking tot stakeholders die actief zijn op het openbaar domein. Het gaat niet altijd enkel over een lokale overheid of intercommunale. Soms zijn er ook private bedrijven betrokken. Zitten deze voorlopig out of scope? - Janis: Straks te bekijken tijdens de oefening rond stakeholdermapping. Beperking Enkel capaciteit om in te zetten op belangrijkste doelgroepen voor lokale besturen. Voorwaarden Interne werking van de organisatie is voldoende matuur om informatie op een gestructureerde manier uit te wisselen Voldoende bewustzijn bij de betrokken partner De belangrijkste meerwaarde Burger kan zijn meldingen ongeacht de context via een plaats naar keuze doorgeven Heldere en verbeterde communicatie naar de burger door duidelijke afspraken rond beheer van meldingen Minder manuele opvolging en administratieve lasten door vereenvoudigde samenwerking tussen verschillende bestuursniveaus Veel voorkomende meldingen · Zwerfvuil · Defecten openbaar domein · Wegenwerken en signalisatie · Burgerzaken · Overlast dieren Opmerking: Dit is een zeer interessante slide. Waarop is dit gebaseerd? Bestaan hier cijfers over? Is het op basis van kwalitalitatieve analyse? - Janis: dit is een consolidatie van alles wat ik van jullie ontvangen heb. Dit komt een stuk van Izegem en Geraardsbergen maar is een voorstudie, nog niet definitief. We willen naar jullie luisteren om te bekijken waar de pijnpunten voornamelijk zitten in jullie trajecten. Het geeft een algemeen beeld. - Heeft iemand de cijfers? Als je cijfers hebt van hoeveel procent mbt een private speler komen, dan kan je prioriteiten beginnen te bepalen. De cijfers zijn van enorm belang dus moest het mogelijk zijn om deze te ontvangen, dat zou zeker interessant zijn. - Janis: vandaag is het vooral de bedoeling om in groep te beslissen waar de focus op zal liggen van het VLOCA-traject zodat de verwachtingen gelijk liggen. Daarnaast zijn jullie de experten en proberen we verder te bouwen op jullie expertise en studies. Niet alle lokale besturen hebben dezelfde maturiteit Maturiteitsmodel Binnen het slim contactpunt Izegem werd een maturiteitsmodel opgericht rond de verschillende stromen die nodig zijn rond meldingen. Dit is een krachtige tool om als lokaal bestuur een inschatting te kunnen maken over de positie van jouw organisatie en welke stappen er mogelijks nog moeten ondernomen worden om te komen tot een bovenlokale integratie voor meldingen. Wat moet een bestuur kunnen? Besturen hebben reeds een digitaal loket waar feedback richting de burger kan worden voorzien Er is nood aan een groter bewustzijn en bereidheid tot samenwerken tussen de verschillende partners Alle communicatie wordt bijgehouden in service-software zodat deze kunnen geraadpleegd worden Documenten moeten eenvoudig digitaal uitgewisseld kunnen worden Belangrijke punten uit het model Gebruik van verschillende service software bemoelijkt vlotte integratie Regionale samenwerking bevorderdt structurele aanpak van bovenlokale noden Het succes van centraal meldingen platform hangt volledig af van duidelijke afspraken tussen de betrokken partijen Opmerkingen Peter: het lijkt mij ook belangrijk om op de gele pijltjes te focussen die de verbinding maken. Zit dit ook in scope of niet? - Janis: de verbinding zit in scope. Het staat nog niet vast of dit één toepassing moet zijn of dat de resultaten van de werkgroepen. We willen de vrijheid hebben om daar breed te kunnen gaan. Het is wel de bedoeling dat het advies een oplossing voorzien met mogelijke scenario’s bvb eentje waar met minimale impact/kosten een volledige oplossing kan voorzien worden. Rond ontvangst, hoe dit moet gebeuren in mijn burgerprofiel of telefoondienst: dat gaat ons te ver leiden. Wel: wat voor afspraken zijn daarvoor nodig? We kunnen een centraal meldingen platform gaan ontwikkelen maar als de afspraken niet duidelijk zijn dan kan het snel fout lopen. Het einddoel is om de burger op een tijdige manier informeren en zijn bezorgdheden opgelost worden. Essin: hebben jullie de officiële Vlaamse fases en codes gebruikt in het schema? Ik zie terminologie die niet overeenkomt. Het is belangrijk om de juiste taal te gebruiken voor het doorgeven van statussen etc. Bijvoorbeeld, ik zie verwerking en afhandeling staan maar hiervoor bestaat een andere benaming. - Janis: voorlopig hebben we het hier in dit document generiek gehouden. Wanneer we een advies geven dan is dat op basis van het OSLO-model. Sarah: wordt de ontvangst van meldingen via de gemeentelijke apps meegenomen in de scope? - Janis: nee, zit niet in scope. We houden er wel rekening mee in de zin dat in het advies dat we geven, interoperabiliteit centraal staat. Het is met andere woorden belangrijk dat de mogelijkheid er is om met andere, bestaande software, in interactie te gaan. Daarnaast wordt bekeken of het mogelijk zou zijn om Mijn Burgerprofiel uit te breiden om meldingen te capteren. Dit zit hier echter niet in scope. Hier focussen we op het centraal meldingen platform. Tijdlijn VLOCA-traject 1) Kennismaking Gedurende de kennismaking wordt de scoping van de opdracht verfijnd met de verschillende betrokken partijen. De relevante workshops en deliverables worden geselecteerd 2) Generieke Business architectuur Twee werkgroepen: a. Business werkgroep Gedurende de business werkgroep wordt de onderliggende probleemstelling scherp gesteld en de noden van de verschillende betrokken partijen in kaart gebracht. Hier wordt de focus gelegd op de generieke behoeften en de meerwaarde die deze kunnen opbrengen. We gaan hierbij de ‘waarom’ toelichten van het traject. b. Werkgroep functionaliteiten Vervolgens wordt tijdens de werkgroep functionaliteiten de nodige high-level rollen en processen in kaart gebracht. 3) High-level applicatie componenten werkgroep § Gedurende de werkgroep “applicatie componenten” wordt dieper ingegaan op nodige dienstenverlening en functies die daarvoor nodig zijn. § Vervolgens wordt aan de hand van een landschapsanalyse de applicatiecomponenten nodig voor ondersteunen van de organisatie in kaart gebracht. 4) Werkgroep aanpak en risico’s Gedurende de werkgroep ‘aanpak en risico’s’ wordt nagedacht over de mogelijke risico’s de gepaard gaan met het opzetten van de verschillende applicatie componenten. Op basis van deze risico’s worden de toepasbare principes and referentie standaarden en mogelijke technologische voorwaarde naar voor geschoven. 5) Wrap-up Terugkoppeling resultaten Brainstorm in Miro-bord Wat willen we uit elke werkgroep halen Opdracht Welke deliverables willen we behalen op het einde van elk van de werkgroepen? Welke zijn de Must haves Should haves Could haves Won’t haves Focus op deliverables zelf en niet op hoe we deze gaan behalen. Output en discussie Business werkgroep Must haves Should haves Could haves Won't have Dit zijn eisen die absoluut noodzakelijk zijn om de werkgroep te laten functioneren zoals bedoeld. Hier is geen discussie over te voeren: zonder deze eisen wordt het eindresultaat niet behaald. Bij deze categorie verandert het van een eis in een wens. Het zou mooi zijn als aan deze wens(en) wordt voldaan, maar het is niet erg als het niet gebeurt. Belangrijk is dat het geen gevaar vormt voor de beschikbare tijd, het beschikbare budget of de voor handen zijnde capaciteit. Bij deze categorie verandert het van een eis in een wens. Het zou mooi zijn als aan deze wens(en) wordt voldaan, maar het is niet erg als het niet gebeurt. Belangrijk is dat het geen gevaar vormt voor de beschikbare tijd, het beschikbare budget of de voor handen zijnde capaciteit. Wensen die op dit moment nog niet relevant zijn, maar dat voor een later project eventueel wel kunnen zijn. In de huidige werkgroep worden deze wensen daarom niet nagestreefd. Rolverdeling Handvaten voor betrokken applicaties om te connecteren (vb dossierafh.) Betere inzichten, analyses Doelstellingen van het centraal meldingen beheer (maximaal cijfermatig beargumenteerd) Business-profielen :) Opportuniteiten voor standaarden te ontwikkelen Stakeholderanalyse + check bereidheid tot samenwerking OSLO verder aanvullen/uitbreiden Scoping van de activiteiten rond meldingen beheer Lokale context van betrokken partijen Bruikbare generieke processen Duidelijke procesbeschrijving (zodat we alle acties en mogelijke paden in rekening brengen) Input gebruikers! Gebruikersonderzoek. Hoe kan een burger makkelijk melden Motivatie rond (waarom gaan zouden we hierop moeten inzetten?) Informatieanalyse: Wat moet een goede melding bevatten Kennis van Appl.landschap en welke ontwikkelingen er zijn. Een 'to be'-situatie uitwerken rond afhandelen van meldingen (waarop LB zich op afstemmen) differentiatie aan profielen Voor wie? Toegankelijkheid op verschillende niveaus (tax.) en welke org. hierbij betrekken Janis: tijdens de eerste werkgroep is het voornamelijk de bedoeling om een kader te schappen voor de volgende werkgroepen: waarom dit project, wat is de rolverdeling,.. Bart: post it kennis van applicatielandschap en ontwikkelingen. De definities zullen belangrijk zijn wanneer we spreken over een platform. Soms bestaat hierover verwarring. Daarnaast bestaat er al heel wat qua oplossingen. Het is belangrijk dat we weten welke stakeholders we erbij kunnen halen. - Janis: belangrijk is om te weten hoe snel we wie gaan betrekken. Dit nemen we op bij de oefening rond stakeholders. We nemen dit mee. Janis: bruikbare, generieke processen. We kijken ook sowieso naar OSLO en andere high level processen die nodig zouden zijn. Essin: de (generieke) procesbeschrijving is belangrijk. - Janis: we kunnen bekijken welke generieke processen nodig zijn met mogelijks een stapje dieper. We gaan niet op elk niveau van de verschillende lokale besturen/(niet-) private partners die hierbij betrokken zijn hun processen gaan definiëren. Dit is niet noodzakelijk relevant. De generieke processen zijn dat wel. Janis: de lokale context van de betrokken partijen geeft een extra dimensie. Een aantal partijen zijn al aan de slag met oplossingen en deze zaken nemen we zeker mee. We vertrekken vanuit OSLO en indien er geen match zou zijn, dan kunnen we hierover communiceren. Janis: onderzoek bij gebruikers – hoe kan een burger gemakkelijker meldingen maken? – hiervoor kijken we naar de resultaten van jullie trajecten. In de business werkgroep komen we hierop terug. Belangrijk is om de informatie die voortkomt uit jullie onderzoeken mee te nemen. Het is echter niet de bedoeling om vanuit VLOCA nog voor elk lokaal bestuur gebruikersonderzoeken te doen. Karel: post it betere inzichten en analyse. Het is belangrijk om op het einde van het traject een lessons learned op te maken om te vermijden dat inzichten verloren gaan. - Janis: het kan interessant zijn om bij het formuleren van de doelstellingen, KPI’s gaan benoemen om ted weten of we die doelstellingen ook bereikt hebben. Dit kunnen we dan meenemen in ons advies. Functionaliteiten werkgroep Must haves Should haves Could haves Won't have Dit zijn eisen die absoluut noodzakelijk zijn om de werkgroep te laten functioneren zoals bedoeld. Hier is geen discussie over te voeren: zonder deze eisen wordt het eindresultaat niet behaald. Bij deze categorie verandert het van een eis in een wens. Het zou mooi zijn als aan deze wens(en) wordt voldaan, maar het is niet erg als het niet gebeurt. Belangrijk is dat het geen gevaar vormt voor de beschikbare tijd, het beschikbare budget of de voor handen zijnde capaciteit. Bij deze categorie verandert het van een eis in een wens. Het zou mooi zijn als aan deze wens(en) wordt voldaan, maar het is niet erg als het niet gebeurt. Belangrijk is dat het geen gevaar vormt voor de beschikbare tijd, het beschikbare budget of de voor handen zijnde capaciteit. Wensen die op dit moment nog niet relevant zijn, maar dat voor een later project eventueel wel kunnen zijn. In de huidige werkgroep worden deze wensen daarom niet nagestreefd. Connectoren Link met Authentieke bronnen Verplichtingen naar de prive markt voor koppelingen naar het platform (richtlijnen die moeten gevolgd worden)??? voor doorstroming proces melden naar andere appl. Gewenste functionaliteiten: getest? GDPR Intake voor de besturen (schaalbaarheid vs complexiteit) Data voor betere inzichten te genereren Procesbeschrijvingen gebruiken als basis voor functionaliteiten OSLO model meldingen vereisten en voorwaarden gelinkt aan functionaliteiten Open buikbare generieke Architectuur Informatie en stroommodellen rond dispatching * Op basis van welke gegevens wordt een melding toegewezen, doorgegeven Functionaliteiten vanuit burgers alsook vanuit perspectief medewerkers (de gebruikers) Usability: voor iedereen By design: functionaliteiten per profiel (gebruiker) voorzien Belangrijkste features voor een meldigen platform Janis: wat zijn precies de verwachtingen rond GDPR? - Bart: er worden persoonsgegevens doorgestuurd bij een melding dus specifieke wetgeving rond het gebruik van een chatbot of virtueel assisten is belangrijk om mee te nemen. Wanneer dit onderwerp behandeld wordt, zouden experts ter zake moeten aanwezig zijn. - Janis: we bekijken om iemand van DPO te betrekken bij de werkgroep. OSLO model - Janis: nemen we zeker mee. We bekijken wat we nodig hebben. Usability - Janis: user testen gaan we niet kunnen doen - Bart: design functionaliteiten per profiel zijn belangrijk. We mogen de groep van niet-digitaalvaardigen niet vergeten. Daarnaast is begrijpbare terminologie belangrijk. Gewenste functionaliteiten getest - Janis: we gaan nog geen oplossing uitbouwen. - Sarah: we denken soms dat we een bepaalde functionaliteit nodig hebben maar best is om dat eerst te bevragen. - Janis: dus de functionaliteiten die we uit het traject halen moeten gestaafd worden, al dan niet door een lokaal bestuur, door een gebruikersbevraging. Dit moeten we bekijken of het haalbaar is binnen dit traject of verschuiven naar effectieve implementatie. Intake besturen: schaalbaarheid vs complexiteit - Janis: het is de bedoeling om een oplossing uit te werken die voldoende flexibel is. Geen pakket dat voor iedereen verplicht te implementeren is. We weten dat veel lokale besturen al werken met bepaalde pakketten en we dus maximaal moeten inzetten op interoperabiliteit. Applicatie componenten werkgroep Must haves Should haves Could haves Won't have Dit zijn eisen die absoluut noodzakelijk zijn om de werkgroep te laten functioneren zoals bedoeld. Hier is geen discussie over te voeren: zonder deze eisen wordt het eindresultaat niet behaald. Bij deze categorie verandert het van een eis in een wens. Het zou mooi zijn als aan deze wens(en) wordt voldaan, maar het is niet erg als het niet gebeurt. Belangrijk is dat het geen gevaar vormt voor de beschikbare tijd, het beschikbare budget of de voor handen zijnde capaciteit. Bij deze categorie verandert het van een eis in een wens. Het zou mooi zijn als aan deze wens(en) wordt voldaan, maar het is niet erg als het niet gebeurt. Belangrijk is dat het geen gevaar vormt voor de beschikbare tijd, het beschikbare budget of de voor handen zijnde capaciteit. Wensen die op dit moment nog niet relevant zijn, maar dat voor een later project eventueel wel kunnen zijn. In de huidige werkgroep worden deze wensen daarom niet nagestreefd. HL applicatie landschap Standaard API's voorzien voor gegevensuitwisseling Verschillende onderdelen voor het meldingen platfomr Ophalen gekende data specifieke melding (vb infrastructuurelement, wegsegmentf, beheerder,...) Generieke Architectuur technische profielen en dus kennis rond die componenten Keuze technologie (VSDS, API's, ACM/IDM, ...) Centraal component dat beheerd w door Vlaanderen (al is die ontwikkeld door externen) matchen met functionaliteiten + haalbaarheid en prioritisering aan koppelen Ophalen gekende data specifieke meldingen - Janis: een centraal beheer platform gaat niet definiëren wat een bepaalde afnemer of provider moet gebruiken. Zij zullen eigen elementen hebben of andere onderdelen. - Karel: vanuit VLAG is dit een belangrijk gegeven. We willen dit open trekken naar ander zaken. Een centraal beheer platform kan gebruikt worden om meldingen te verrijken en centraal toe te wijzen. - Janis: we gaan niet bepalen wat een centraal infrastructuur element is en wat erin moet zitten. Aanpak en risico’s werkgroep Must haves Should haves Could haves Won't have Dit zijn eisen die absoluut noodzakelijk zijn om de werkgroep te laten functioneren zoals bedoeld. Hier is geen discussie over te voeren: zonder deze eisen wordt het eindresultaat niet behaald. Bij deze categorie verandert het van een eis in een wens. Het zou mooi zijn als aan deze wens(en) wordt voldaan, maar het is niet erg als het niet gebeurt. Belangrijk is dat het geen gevaar vormt voor de beschikbare tijd, het beschikbare budget of de voor handen zijnde capaciteit. Bij deze categorie verandert het van een eis in een wens. Het zou mooi zijn als aan deze wens(en) wordt voldaan, maar het is niet erg als het niet gebeurt. Belangrijk is dat het geen gevaar vormt voor de beschikbare tijd, het beschikbare budget of de voor handen zijnde capaciteit. Wensen die op dit moment nog niet relevant zijn, maar dat voor een later project eventueel wel kunnen zijn. In de huidige werkgroep worden deze wensen daarom niet nagestreefd. Stakeholdermanagement noden Zal er iets van 'wettelijk kader' voorzien worden rond het centraal meldingen-platform? Hoe kunnen we die afdwingbaar maken? Hoe kunnen we leveranciers verplichten om met bepaalde standaarden te werken?.... GDPR Vervolledigen stakeholderlijst Opdracht Welke stakeholders zijn nodig bij de verschillende werkgroepen? Wie is cruciaal? Aan wie denk je vanuit je eigen context/ervaringen? Bij wie ervaren jullie bottlenecks? Output en discussie Stakeholders Burgerwacht eerstelijnsmedewerkers LB Clearchannel afvalintercommunales Burgemeester & schepenen Eigenaars en beheerders van Laadpalen AWV Fluvius Telco? Andere overheden (buurgemeente, Vlaanderen, Politie, Brandweer, ...) Intercommunales die beheren voor een (lokaal) bestuur (Afvalintercommunale, fluvius voor lichtmasten, ...) Dienstverleners met raamcontracten voor het oplossen van meldingen (vb. Clearchannel) Next steps Aanvullen excel Neem je tijd om de stakeholderlijst zoveel mogelijk aan te vullen. Vergeet niet om naar de verschillende tabs te kijken: lijst kan verschillend zijn afhankelijk van de soort werkgroep. Voorbereiding volgende werkgroep · VLOCA verwerkt de input van de kick-off · Het verslag wordt rondgestuurd. Feedback is welkom. · Verder onderzoek en voorbereiding van de volgende werkgroepen Vragen Peter: wordt er voorbereidende input verwacht van ons voor de komende werkgroepen? - Janis: jullie input zal nog bevraagd worden zodat jullie kennis maximaal kan ingezet worden. Eerst en vooral mogen jullie een mail verwachten met een samenvatting. Daarnaast kunnen we nog even samenzitten met Izegem rond het maturiteitsmodel om dit mee te integreren in het verhaal. Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Kick-off Business werkgroep 2024-04-26 13u-14u30 Teams Business werkgroep Business werkgroep 2024-05-27 13u30-16u00 Teams +
Agoria baant het pad voor alle technologis … Agoria baant het pad voor alle technologisch geïnspireerde bedrijven in België die door de ontwikkeling of toepassing van innovaties vooruitgang in de wereld nastreven en die samen ruim 310.000 werknemers vertegenwoordigen. De acties, dienstverlening en standpunten van Agoria gaan over: Human capital & education Digitalisering Society Regelgeving & finance Maakindustrie Klimaat, milieu & energie Marktontwikkeling Infrastructuur Meer informatie over Agoria kan hier gevonden worden alsook op de Agoria wikipedia pagina .orden alsook op de Agoria wikipedia pagina . +
Alle deliverables VLOCA traject Deliv … Alle deliverables VLOCA traject Deliverable Versie Aankondiging start publieke review Andere Beschrijving Aanmaak co-creatie pagina op de kennishub Andere Beschrijving Architectuurstandaard Andere Beschrijving Bestekteksten Beschrijvende teksten Beschrijving Conformiteitsmodel Conformiteitsmodel Beschrijving Data Governance Model Data governance model Beschrijving VLOCA-model V0.1 Lokale Open Data Economie (LODE) – Brugge Lokale Open Data Economie (LODE) VLOCA-Model V0.1 VLOCA-model V0.1 Slimme stadsdistributie – Hasselt Slimme stadsdistributie VLOCA-Model V0.1 Circulaire economie: Repair cafés VLOCA-model V0.2 Circulaire economie: Repair cafés VLOCA-Model V0.2 VLOCA-model V0.2 Lokale Open Data Economie (LODE) – Brugge Lokale Open Data Economie (LODE) VLOCA-Model V0.2 VLOCA-model V0.2 Het potentieel van urban mining voor de bouwsector Het potentieel van urban mining & BIM voor de bouwsector VLOCA-Model V0.2 VLOCA-model Ondersteuning retail binnenstad activatie Datagestuurde handelskern VLOCA-Model V0.1 Stakeholderanalyse Slimme stadsdistributie Stakeholderanalyse V0 Voorbeeld architectuurtekening Slimme stadsdistributie TA-Tekening V0 Visualo VLOCA-model V0.2 Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) VLOCA-Model V0.2 VLOCA-model V0.2 Mobiliteitsbudget voor burgers – Hasselt Mobiliteitsbudget voor burgers VLOCA-Donut V0.2 VLOCA-model V0.1 Regionaal plugable incentiveringsplatform – Geel Regionaal plugable incentiveringsplatform VLOCA-Model V0.1 VLOCA-model V0.2 Slimme stadsdistributie – Hasselt Slimme stadsdistributie VLOCA-Model V0.2 VLOCA-model V1.0 Regionaal plugable incentiveringsplatform – Geel Regionaal plugable incentiveringsplatform VLOCA-Model V1.0 Roadmap Regionaal plugable incentiveringsplatform – Geel V0 VLOCA-model V1.8 Regionaal plugable incentiveringsplatform – Geel Regionaal plugable incentiveringsplatform VLOCA-Model Co-creatie Vereistenmodel Regionaal plugable incentiveringsplatform – Geel Regionaal plugable incentiveringsplatform Vereistenmodel V0 Vereistenmodel VISUALO Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) Beschrijvende teksten V0 VLOCA-model V0.1 Smart Innovation Factory – Mechelen Smart Innovation Factory VLOCA-Model V0.1 VLOCA-model V0.1 Mobiele Sensor Units – Roeselare Mobiele Sensor Units VLOCA-Model V0.1 VLOCA-model V0.1 Machine Learning as a Service (MLaaS) – Roeselare Machine Learning as a Service (MLaaS) VLOCA-Model V0.1 Visualo VLOCA-model V0.1 Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) VLOCA-Model V0.1 VLOCA-model V0.1 Het potentieel van urban mining voor de bouwsector Het potentieel van urban mining & BIM voor de bouwsector VLOCA-Model V0.1 VLOCA-model V0.1 Slimme Markten – Hasselt Slimme Markten VLOCA-Model V0.1 VLOCA-model V0.1 Mobiliteitsbudget voor burgers – Hasselt Mobiliteitsbudget voor burgers VLOCA-Donut V0.1 Architectuurtekeningen Regionaal plugable incentiveringsplatform – Geel Regionaal plugable incentiveringsplatform Andere V0 Prioriteringsoefening Regionaal plugable incentiveringsplatform – Geel V1.0 Informatienoden Informatiearchitectuur Beschrijving Marktanalyse Marktanalyse Beschrijving Oproep tot deelname Andere Beschrijving Opstart werkgroep beheer architectuur van de use case Andere Beschrijving Stakeholder interview Andere Beschrijving Stakeholderanalyse Stakeholderanalyse Beschrijving Technische Architectuur tekeningen TA-Tekening Beschrijving Testimonial Andere Beschrijving Traject charter Traject charter Beschrijving Use case prioritering Use case prioritering Beschrijving Use case roadmap Use case roadmap Beschrijving VLOCA Draaiboeken Draaiboeken Beschrijving VLOCA Talk Andere Beschrijving VLOCA assessment VLOCA-Assessment Beschrijving VLOCA donut VLOCA-Donut Beschrijving VLOCA-Model VLOCA-Model Beschrijving Vereistenmodel Vereistenmodel Beschrijving +
Als we geconfronteerd worden met een falin … Als we geconfronteerd worden met een faling, rijst de vraag of we het toestel best nog herstellen of beter vervangt door een nieuw en (eventueel) energiezuiniger exemplaar. Vanuit een financieel maar ook vanuit een klimaatperspectief is dit een belangrijke overweging waar men wat hulp bij kan gebruiken. De impacttool, zoals ontwikkeld binnen het Interreg SHAREPAIR project, geeft de eigenaar van het product inzichten in de uitstoot van broeikasgassen voor beide scenario’s Men herstelt het bestaande en maakt er nog een aantal jaar gebruik van. De herstel houdt enkele acties in (afhankelijk wat de faling precies was) zoals het vervangen van een onderdeel, transport, gebruik van een boormachine,… die eveneens gepaard gaan met de uitstoot van broeikasgassen. Na eindeleven wordt het toestel alsnog vervangen Men vervangt het toestel door een nieuw. De CO2 impact van de productie van het nieuwe toestel wordt weergegeven, alsook het energieverbruik tijdens de gebruiksfase. Tevens kan men met de impacttool voor alle herstellingen die plaatsvonden in een repair café of die geregistreerd werden op een digitale tool zoals RepairConnects (DIY repair) berekenen voor hoeveel (lokale) CO2 reductie ze zorgden. Een demo van de Repair Impact Tool kan u hier vinden:ool kan u hier vinden: +
An open city allows urban challenges to be … An open city allows urban challenges to be tackled using data. On the one hand, data must be shared in a uniform and scalable manner so that it forms the foundation for building specific views for a particular domain. On the other hand, the data (especially in the case of sensors as a data source) must be of sufficiently high quality so that true visualization models can be built. All these aspects are dealt with in a bottom-up, three-part COOCK workshop.This workshop (part three) is built up as follows: We start with an overview of state-of-the-art data platforms and which interoperability principles are followed. Next, the learnings of rolling out a network of air quality sensors in the Smart Zone in Antwerp will be explained. Finally, the processes, tooling and used semantic standards of the City of Things projects Databroker, MoDi and ANPR are explained. Here you can find the first and second part. Date: Tuesday April 27 th 2021, 10:00 - 12:00 Registration: https://share.hsforms.com/1-EmQ5yddT6GrAPeWYor0FA42q9f Registered participants will receive the conference-link a few days before themeeting. Agenda (2h online event) 10:00 - 10:10 Intro by IMEC -EDIT, Stefan Lefever 10:10 - 10:50 How is the international ecosystem evolving? by IMEC -EDIT, Stefan Lefever Slides: 10:50 - 11:10 Learnings from the Antwerp smart zone by IMEC -NL, Valerio Panzica La Manna Slides: Bestand:2021-04-27-COOCK-AQ-LessonLearned-Workshop.pdf 11:10 - 11:35 Learnings from VLAIO CityOfThings support (Databroker, MoDi and ANPR ) by IMEC -IDLab Ghent, Brecht Van de Vyvere Slides: Bestand:COOCK Workshop - Learnings from international and local smart city initiatives.pdf 11:35 - 12:00 Wrap-up and Q&A +
An open city allows urban challenges to be … An open city allows urban challenges to be tackled using data. On the one hand, data must be shared in a uniform and scalable manner so that it forms the foundation for building specific views for a particular domain. On the other hand, the data (especially in the case of sensors as a data source) must be of sufficiently high quality so that true visualization models can be built. All these aspects are dealt with in a bottom-up, three-part COOCK workshop. This workshop is part one. Here you can find the second and third part. Date: Tuesday February 2 nd 2021, 9:00 - 11:00 Registration: https://share.hsforms.com/1zgYrsrb_TzC6aW9bX8HlYQ42q9f Registered participants will receive the zoom-link a few days before themeeting. Topics This workshop (part one) is built up as follows: We will start with a practical look at connecting sensors in the smart city. We will continue with the different levels of interoperability that will be discussed in order to store and unlock this data and how this works concretely within the infrastructure of IDLab (Internet and Data science Lab). Finally, research results will be shared about publishing real-time data as open data. Agenda (2h online event) 9:00 - 9:05 Intro by IMEC -IDLab Antwerp, Bart Braem 9:05 - 9:25 How to connect sensors today? by IMEC -IDLab Antwerp, Johan Bergs Presentation: 9:25 - 9:45 Minimum Interoperability Mechnanisms and more by IMEC -EDIT, Stefan Lefever Presentation: 10:00 - 10:20 General introduction to NGSI & available tools by IMEC -IDLab Ghent, Philip Leroux Presentation: Bestand:Coock Workshop NGSI v02.pdf 10:20 - 10:40 Open Data Learnings from IMEC CityOfThings project "Observer" by IMEC -IDLab Ghent, Brecht Van de Vyvere Presentation: 10:40 - 11:00 Wrap-up and Q&A0 - 11:00 Wrap-up and Q&A +
An open city allows urban challenges to be … An open city allows urban challenges to be tackled using data. On the one hand, data must be shared in a uniform and scalable manner so that it forms the foundation for building specific views for a particular domain. On the other hand, the data (especially in the case of sensors as a data source) must be of sufficiently high quality so that true visualization models can be built. All these aspects are dealt with in a bottom-up, three-part COOCK workshop. This workshop is part one. Here you can find the second and third part. Date: Tuesday January 26 th 2021, 10:00 - 11:40 Registration: TBA Registered participants will receive the zoom-link a few days before themeeting. Topics This workshop (part one) is built up as follows: We will start with a practical look at connecting sensors in the smart city. We will continue with the different levels of interoperability that will be discussed in order to store and unlock this data and how this works concretely within the infrastructure of IDLab (Internet and Data science Lab). Finally, research results will be shared about publishing real-time data as open data. Agenda (2h online event) 10:00 - 10:05 Intro by IMEC -EDIT, Stefan Lefever 10:05 - 10:35 How to connect sensors today? by IDLab Antwerp, Bart Braem 10:35 - 10:55 Minimum Interoperability Mechnanisms and more by IMEC -EDIT, Stefan Lefever 11:05 - 11:20 General introduction to NGSI & available tools by IDLab Ghent, Philip Leroux 11:20 - 11:30 Open Data Learnings from IMEC CityOfThings project "Observer" by IDLab Ghent, Brecht Van de Vyvere 11:30 - 11:40 Wrap-up and Q&A0 - 11:40 Wrap-up and Q&A +
An open city allows urban challenges to be … An open city allows urban challenges to be tackled using data. On the one hand, data must be sharedin a uniform and scalable manner forming the foundation of domain-specific views. On the otherhand, the data must be of sufficiently high quality so that true visualization models can be built.In this COOCK Open City workshop, we will deep-dive into best-practices for sharing data on the Web, and what you can expect from Artificial Intelligence. This workshop is part two of a COOCK workshop-serie. Here you can find the first and third part. Date: Tuesday February 23 rd 2021, 10:00 - 12:00 Registration: https://share.hsforms.com/1ROLoEmNlSJiFi7xRPiyZTA42q9f Registered participants will receive the zoom-link a few days before themeeting. Agenda (2h online event) 10:00 - 10:05 Intro by IMEC -IDLab Ghent, Brecht Van de Vyvere 10:05 - 10:20 What is (Linked) Open Data? by IMEC -SMIT, Nils Walravens Presentation: 10:20 - 11:15 Best practices with sharing data with third parties by IMEC -IDLab Ghent, Pieter Colpaert and Brecht Van de Vyvere Presentation: Bestand:Best-practices-with-sharing-data-with-third-parties.pdf 11:15 - 11:45 From high quality data to reliable AI by IMEC -IDLab Antwerp, Bart Braem Presentation: Bestand:Intro-to-ai.pdf 11:45 - 12:00 Wrap-up and Q&A You can watch this workshop on Youtube here: Youtube-link +
Analyse door Alain Glickman, data scientis … Analyse door Alain Glickman, data scientist bij VLOCA Het bepalen van een coherent beleid door lokale besturen in deze complexe wereld omhelst heel wat variabelen. We denken aan factoren zoals de globale conjunctuur, de staat van de infrastructuur en de klimatologische omstandigheden, die ook op lokaal vlak een grote rol spelen. Het adagio "meten is weten" klinkt velen bekend in de oren, maar het vergaren, interpreteren en inzetten van accurate en relevante data om het beleid te bepalen of bij te sturen is niet eenvoudig. Lokale besturen hebben nood aan heel wat data én een presentatie-laag die aan een groot aantal belanghebbenden de gegevens en inzichten op een handige en verstaanbare manier weergeven. Beleidsmakers hebben uiteraard een visie en vaak jarenlang ervaring in de bepaling van prioriteiten. Vandaag worden ze aangemoedigd om deze visie, hun ervaring en dat "buikgevoel" te onderbouwen met data. De eerste “gemakkelijke” manier is de aankoop van data om dit buikgevoel te onderbouwen, en zo de uitwerking va het beleid te rechtvaardigen. De tweede wijze vertrekt vanuit de objectieven en de analyse van de reeds beschikbare databronnen. Deze worden dan aangevuld met gegevens uit nieuwe bronnen met als doel de objectieven te evalueren en bij te sturen op basis van de volledige dataset. Deze laatste manier is voor besturen vaak een radicale verandering en vereist een fundamentele aanpassing van hun modus operandi bij de beleidsbepaling. Samen met de Stad Hasselt gingen we door deze nieuwe manier van werken. Binnen de stad onderzoekt men hoe bezoekersstromen in de stad in kaart te brengen. Zo worden handelaren ondersteund met relevante data. Weten wie waar en wanneer de stad bezoekt en er winkelt of niet, is voor de lokale overheid en de betrokken handelaren van primordiaal belang om een ondersteuningsbeleid uit te tekenen en alle noden te begrijpen, daarbij uiteraard rekening te houden met de privacy van de bezoekers. Databrokers kunnen een veelheid aan data aanleveren maar de valkuil hierbij is om gegevens te verwerven zonder een gedegen analyse van de doelen, objectieven en precieze noden aan data. Op basis van een grondige analyse en scherpe omschrijving van deze noden en doelen kunnen we bepalen welke data nodig is om tot een relevant beeld van de situatie te komen. Hierna bekijken we welke gegevens al beschikbaar zijn, en op welke manier de ontbrekende data verworven kunnen worden. Tijdens deze analysefase kan het vanuit een exploratief standpunt interessant zijn om een beperkte dataset aan te kopen om de analyse rijker en vollediger te maken. Dit betekent niet per definitie dat de aankoop van data in de uiteindelijke oplossing noodzakelijk is. Een zeer interessante uitdaging voor het lokale bestuur. Het onderbouwen van het beleid met relevante, accurate en objectieve data laat toe om het draagvlak van beslissingen drastisch te vergroten. Is jouw lokale bestuur ook geïnteresseerd in een gesprek over onze aanpak? Laat ons dan zeker iets weten via vloca@vlaanderen.beloca@vlaanderen.be +
Apache Druid [1] ↑ https://en.wikipedia.org/wiki/Apache_Druid +
Applicatie componenten werkgroep 24/7 … Applicatie componenten werkgroep 24/7 dienstverlening 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. Deelname werkgroep Heb jij interesse, specifieke noden, expertise of andere belangen bij dit traject? Klik hier om je in te schrijven. 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-05 9u-12u Teams Aanpak en risico's werkgroep Technologie werkgroep 2024-11-26 9u-12u Teams +
Application pages Please log in first … Application pages Please log in first. Page Title Application page type Application page origin Wijzigingsdatum "Wijzigingsdatum (Modification date)" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . Pages Pages 18 april 2024 13:14:17 Module:WSNavMenu Module:WSNavMenu 15 maart 2024 11:06:35 Module:VersionHistoryItems Module:VersionHistoryItems 15 maart 2024 11:05:58 Version date Property:Version date 15 maart 2024 11:05:57 Version description Property:Version description 15 maart 2024 11:05:57 Version number Property:Version number 15 maart 2024 11:05:57 Title Property:Title 15 maart 2024 11:02:03 Tags Property:Tags 15 maart 2024 11:01:56 Sub header template Property:Sub header template 15 maart 2024 11:01:53 Wiki:Slots Wiki:Slots 15 maart 2024 11:01:37 Sidebar form Property:Sidebar form 15 maart 2024 11:01:31 Sidebar template Property:Sidebar template 15 maart 2024 11:01:31 Short description Property:Short description 15 maart 2024 11:01:30 Parameter definition property name Property:Parameter definition property name CSP Basis Core CSP Basis 14 maart 2024 14:23:27 Parameter definition required Property:Parameter definition required CSP Basis Core CSP Basis 14 maart 2024 14:23:27 Parameter definition slot Property:Parameter definition slot CSP Basis Core CSP Basis 14 maart 2024 14:23:27 Parameter definition sorting number Property:Parameter definition sorting number CSP Basis Core CSP Basis 14 maart 2024 14:23:27 Parameter definition multiple Property:Parameter definition multiple CSP Basis Core CSP Basis 14 maart 2024 14:23:26 Parameter definition name Property:Parameter definition name CSP Basis Core CSP Basis 14 maart 2024 14:23:26 Parameter definition formfield type Property:Parameter definition formfield type CSP Basis Core CSP Basis 14 maart 2024 14:23:26 Pagetitle format Property:Pagetitle format 14 maart 2024 14:23:26 Parameter definition allowed values Property:Parameter definition allowed values CSP Basis Core CSP Basis 14 maart 2024 14:23:26 Wiki:Page-types Wiki:Page-types 14 maart 2024 14:23:24 Page properties template Property:Page properties template 14 maart 2024 14:23:23 Name Property:Name 14 maart 2024 14:23:04 Layout columns Property:Layout columns 14 maart 2024 14:22:46 Layout areas Property:Layout areas 14 maart 2024 14:22:46 Layout rows Property:Layout rows 14 maart 2024 14:22:46 Is tag Property:Is tag 14 maart 2024 13:55:04 ID Property:ID 14 maart 2024 13:54:47 Has version history Property:Has version history 14 maart 2024 13:54:35 Footer template Property:Footer template 14 maart 2024 13:54:22 Defines class Property:Defines class 14 maart 2024 13:53:50 Module:CspFunctions Module:CspFunctions 14 maart 2024 13:52:45 Module:CspCreatePageForm Module:CspCreatePageForm 14 maart 2024 13:52:44 Module:CspComponents Module:CspComponents 14 maart 2024 13:52:44 CspError Property:CspError 14 maart 2024 13:52:44 Module:ClassDefinitionData Module:ClassDefinitionData 14 maart 2024 13:52:31 Wiki:Class definition Wiki:Class definition 14 maart 2024 13:52:30 Class Property:Class 14 maart 2024 13:52:30 Widget:Logo Widget:Logo 14 maart 2024 13:03:08 Widget:Searchbar Widget:Searchbar 14 maart 2024 13:03:08 Widget:Layout Widget:Layout 14 maart 2024 13:03:07 Widget:Link Widget:Link 14 maart 2024 13:03:07 Template:WSNavMenu Template:WSNavMenu 14 maart 2024 12:59:13 Template:Wsform is tag checkbox Template:Wsform is tag checkbox 14 maart 2024 12:59:13 Template:Slots Template:Slots 14 maart 2024 12:59:12 Template:Show version history Template:Show version history 14 maart 2024 12:59:11 Template:Sidebar item Template:Sidebar item CSP Basis Core CSP Basis 14 maart 2024 12:59:11 Template:Pages overview Template:Pages overview 14 maart 2024 12:59:10 Template:Parameter definition Template:Parameter definition 14 maart 2024 12:59:10 Template:Page-types Template:Page-types 14 maart 2024 12:59:10 Template:Modal Template:Modal 14 maart 2024 12:59:08 Template:Login button Template:Login button 14 maart 2024 12:59:08 Template:New application page Template:New application page 14 maart 2024 12:59:08 Template:Generate page properties template code Template:Generate page properties template code CSP Basis Core CSP Basis 14 maart 2024 12:59:07 Template:Generate sidebar template code Template:Generate sidebar template code CSP Basis Core CSP Basis 14 maart 2024 12:59:07 Template:Layout Template:Layout 14 maart 2024 12:59:07 Template:Dropdown link Template:Dropdown link CSP Basis Core CSP Basis 14 maart 2024 12:59:06 Template:Fa Template:Fa 14 maart 2024 12:59:06 Template:Csp show class definition Template:Csp show class definition 14 maart 2024 12:59:05 Template:Csp sidebar item Template:Csp sidebar item 14 maart 2024 12:59:05 Template:Csp sidebar tabs Template:Csp sidebar tabs 14 maart 2024 12:59:05 Template:Csp new component template Template:Csp new component template 14 maart 2024 12:59:04 Template:Csp parameter display/datetime Template:Csp parameter display/datetime 14 maart 2024 12:59:04 Template:Csp parameter display/link Template:Csp parameter display/link 14 maart 2024 12:59:04 Template:Csp parameter display/date Template:Csp parameter display/date 14 maart 2024 12:59:04 Template:Csp formfield/token Template:Csp formfield/token 14 maart 2024 12:59:03 Template:Csp formfield/textarea Template:Csp formfield/textarea 14 maart 2024 12:59:03 Template:Csp formfield/number Template:Csp formfield/number 14 maart 2024 12:59:02 Template:Csp formfield/select Template:Csp formfield/select 14 maart 2024 12:59:02 Template:Csp formfield/text Template:Csp formfield/text 14 maart 2024 12:59:02 Template:Csp formfield/checkbox Template:Csp formfield/checkbox 14 maart 2024 12:59:01 Template:Csp formfield/date Template:Csp formfield/date 14 maart 2024 12:59:01 Template:Csp formfield/ask token Template:Csp formfield/ask token 14 maart 2024 12:59:01 Template:Csp formfield/datetime-local Template:Csp formfield/datetime-local 14 maart 2024 12:59:01 Template:Csp default subheader Template:Csp default subheader 14 maart 2024 12:59:00 Template:Csp default sidebar Template:Csp default sidebar 14 maart 2024 12:59:00 Template:Csp class properties Template:Csp class properties 14 maart 2024 12:59:00 Template:Class definition form Template:Class definition form 14 maart 2024 12:58:59 Template:Class definition subheader Template:Class definition subheader 14 maart 2024 12:58:59 Template:Create page form Template:Create page form 14 maart 2024 12:58:59 Template:Class definition Template:Class definition 14 maart 2024 12:58:59 Template:CSP alert Template:CSP alert 14 maart 2024 12:14:15 Widget:Button link Widget:Button link 14 maart 2024 12:14:14 Base properties template Property:Base properties template 14 maart 2024 12:14:13 Archived Property:Archived 14 maart 2024 12:14:12 Template:Base properties Template:Base properties 14 maart 2024 12:14:12 Application page origin Property:Application page origin 14 maart 2024 12:14:11 Template:Application page properties Template:Application page properties CSP Basis Core CSP Basis 14 maart 2024 12:14:11 Application page type Property:Application page type 14 maart 2024 12:14:11 Template:Application page sidebar Template:Application page sidebar CSP Basis Core CSP Basis 14 maart 2024 12:14:11 Template:Application page subheader Template:Application page subheader 14 maart 2024 12:14:11 Wiki:Application pages Wiki:Application pages 14 maart 2024 12:14:11 Allowed namespaces Property:Allowed namespaces 14 maart 2024 12:14:11 Template:Add version history item Template:Add version history item 14 maart 2024 12:14:10 Template:Alert Template:Alert 14 maart 2024 12:14:10te:Alert Template:Alert 14 maart 2024 12:14:10 +
Aquafin zuivert rioolwater tot het weer de … Aquafin zuivert rioolwater tot het weer de natuur in kan. Geen drinkwater dus voor de mens, maar wel voor vissen, vogels en amfibieën. Voor jou werken we aan een leefomgeving in harmonie met water. Dat betekent proper water in stadskernen, waarlangs het aangenaam wonen en wandelen is. Maar ook een duurzame omgang met regenwater, om droge bodems te helpen voorkomen en de gevolgen van zware buien te beperken. Meer information over Aquafin kan je vinden op de Aquafin website en op de Aquafin wikipedia pagina .e en op de Aquafin wikipedia pagina . +
Architecturale context Context Samenva … Architecturale context Context Samenvatting hoe we de architectuur opdracht hebben begrepen. Visie Steden hebben het moeilijk om het gedrag van de burgers te veranderen zonder incentivering. Uit vorige projecten blijkt dat 'vouchers' en 'lokale (digitale) munten' (sociaal krediet zoals duimpjes up) daarvoor goed werken. Maar die worden ook te snel verzilverd in euro's en blijven niet binnen het systeem. Daarnaast leiden verschillende incentiveringen ook tot eigen vouchers of (digitale) munten hetgeen resulteert in een versnipperd landschap van systemen. De keuze om al de lokale economie te steunen dan wel expliciet te kiezen voor een digitale munt die regionaal besteed kan worden (= aantrekkelijker voor de burger) moet bij de initiatiefnemer (lees: lokaal bestuur) liggen: waar steun aan lokale economie belangrijkste finaliteit is, moet er gekozen kunnen worden voor een lokale munt. Wanneer een incentivering op een bepaalde maatschappelijk wenselijk gedrag ligt, is een regionale campagne die toeleidt tot een regionale munt vaak interessanter. (Bron: REF01) Doelstellingen De lokale/digitale munt moet kunnen dienen als 'betaalmiddel' tussen C2C en B2B (mits wetgevend kader) om die munt zo lang mogelijk binnen de regio te houden. (Bron: REF01) Een platform dat 'goed gedrag' beloont met een 'lokale munt' die enkel in de regio kan ingeruild/gespendeerd worden = 'regio breed incentiveringsplatform'. (Bron: REF01) Een 'schaalbare' architectuur dat snel en efficiënt uitrolbaar is in andere regio die dat zouden wensen. (Bron: REF01) Stakeholders Deze paragraaf beschrijft de belangrijkste stakeholders. Stakeholders zijn mensen die actief betrokken zijn bij de architectuur opdracht en/of het project, of wiens belangen positief of negatief kunnen worden beïnvloed door de uitvoering of voltooiing van de integratie opdracht en/of het project. Stakeholders behoeften Rol Vertegenwoordigd door Verantwoordelijkheid Bezorgdheden Actie (*) Stad Geel OSLO IOK Stijn Claes - Koen Van den Eynde Ondersteuning van Kempense lokale besturen (en in eerste instantie stad Geel) met het uitrollen van een schaalbaar platform dat incentivering mogelijk maakt aan de hand van digitale munten. VLOCA Mieke Van Cauwenberghe Verantwoordelijkheid is tweeledig. Enerzijds wil VLOCA in co-creatie met kenniscentra, bedrijven, lokale besturen en burger(organisaties) een gedragen referentiekader, dat bestaat uit principes, concepten en architectuurcomponenten, tot stand brengen. Dit moet gaandeweg leiden tot een beheersbare open city architectuur voor slimme steden en gemeenten. Anderzijds is het de bedoeling om bovenstaande (eerste) resultaten door te vertalen naar een draaiboek voor aanbestedende (lokale) overheden. Dit draaiboek moet hen ondersteunen om slimme oplossingen uit te rollen, conform de Vlaamse Open City Architectuur. Hebben we de vereiste capabilities om de lokale besturen te ondersteunen zodat we hun keuzes veilig kunnen stellen naar de software leveranciers dat toekomstbestendig, consistent en in overeenstemming is met de VLOCA architectuur richtlijnen? (*) KS : Keep satisfied (High Power en Low Interest). MC : Manage Closely (High Power en High Interest) KI : Keep Informed (Low Power en High Interest). M : Monitor (Low Power en Low Interest) Use cases In deze paragraaf worden de use cases (goals) beschreven t.o.v. dat de doelstellingen (drivers) die gerealiseerd dienen te worden door de transitiearchitectuur. (Bron: REF01) N° Doelstelling (Driver) N° Use Cases CoT.2021.003.1 Een platform die 'goed gedrag' beloont met een 'lokale munt' die enkel in de regio kan ingeruild/gespendeerd worden = 'regio breed incentiveringsplatform' UC3 Participatie Mechanisme : Een gebruiksvriendelijke platform om zowel als 'donor' als 'collector' als 'spender' zichzelf te kunnen registreren en 'regels'/'parameters' voor ontvangen en gebruiken te kunnen vastleggen. Voor de definities van Donor, Collector en Spender. UC4 Marketing: Aanradingsprogramma om de lokale economie aan te trekken om mee te doen zowel als 'donor' (= participerende organisatie die zelf een stimulansaanbod aanbiedt) of 'sponsor'/'advertiser' (= organisatie die een stimulansaanbod wil financieren) alsook als 'collector' (= winkels die deze munt aanvaarden als betaling) Inclusief communicatieplatform om berichten, nieuwsletter, alerts, bevestigingen enz te kunnen beheren. UC10 Helpdesk, klachten & reviews: Helpdesk bij vragen, FAQ, klachten en reviews door alle betrokken partijen. UC6 Inzichten & Dashboarding: Het verkrijgen van inzichten in het gebruik en de positieve impact op 'goed gedrag' en 'lokale economie' die het beleid kan gebruiken. (Analyse van 'verval' of 'demurage' = waardeverlies, waar gaat dat geld naartoe bvb goed doel,...) CoT.2021.003.2 Een 'schaalbaar' architectuur dat snel en efficient uitrolbaar is in andere regio die dat zouden wensen. UC2 Integratie: Integratie met bestaande (en nieuwe) applicaties die als 'vertical' (organiseren van een stimulansaanbod) fungeren maar ook stadsapplicaties, websites, cadeaubonnen applicaties en zelfs MijnBurgerProfiel (app) UC7 Principes: Schaalbaarheid (voor extra steden en regio's), interoperabiliteit (voor extra toepassingen) en cross verticale principes van het platform is cruciaal. Schaalbaar = * uitbreidbaar naar andere gemeenten / regio's * andere (nieuwe of bestaande) verticals moeten kunnen koppelen met het platform * ook aan bestedingszijde moet het platform flexibiliteit bieden (besteding bij handelaar, B2B (mits wetgevend kader), donatie aan lokale organisatie/doel/project, andere (crowd funding) systemen... UC8 Draaiboeken : Een bibliotheek leveren van draaiboeken die de steden en gemeenten een 'how to' uitleggen ifv hun behoeften en context. CoT.2021.003.3 De lokale/digitale munt moet kunnen dienen als 'betaalmiddel' tussen C2C en B2B (mits wetgevend kader) om die munt zo lang mogelijk binnen de regio te houden. UC1 Digitale wallet : Digitale wallet van meerdere soorten munten (lokaal, regionaal, enz. en evt andere systemen, zoals Uitpas) waar zowel stortingen, uitgaven/overschrijven en consulteren van saldo's door de eigenaar en participanten kunnen gebeuren. UC9 Compensatie mogelijkheden : Bij het kiezen voor een (additionele) lokale economie, willen we een evenwichtig systeem hebben tussen regionale en lokale muntsystemen opdat eventueel geld zou kunnen terugvloeien tussen gemeenten/steden. Onevenwichtig is bvb indien een gemeente A sponsort met de hoop op het spenderen bij lokale handelaars in gemeente A terwijl er factueel buiten proporties uitgegeven wordt door de burgers in gemeente B. UC11 Betalingen: Vanuit het platform één betalingsmodule die over alle 'verticals' heen kan gebruikt worden om te vermijden dat de handelaar verschillende systemen moet hebben per verticaal om geld te kunnen 'krijgen' van de 'shopper' UC5 Omzetting Mechanisme: Een facturatie- en betalingssysteem dat de eerste en allerlaatste conversie regelt zodat de lokale munt in praktijk omgezet kan worden in euros. KPI behoeften N° KPI Prestatie maatstaf Streefwaarde CoT.2021.003.X-UCnn KPI-001 Verkoop KPI ter illustratie : Als handelaar kan je kijken naar je het aantal verkoop per uur, dag, week, maand, kwartaal of jaar. Als streefwaarde kan je een percentage, een getal (in een bereik), … opgeven. Eventueel opgedeeld in tijd. KPI-002 Marketing KPI ter illustratie: Als handelaar kan je kijken naar het App verkeer, zoals het totaal aantal bezoeken voor jouw account. Meer verkeer betekent meer potentiële klanten. KPI-003 Customer Service KPI ter illustratie: De Net Promotor Score (NPS) meet de klanttevredenheid en klantenloyaliteit. Deze score wordt afgemeten aan de mate waarin klanten jou als handelaar aan iemand zouden aanbevelen. KPI-004 Productie KPI ter illustratie: De productiecyclus KPI vertelt je hoe lang het duurt om één advertentie te maken van start tot finish. Als je deze KPI goed in de gaten houdt krijg je belangrijke inzichten in de efficientie van jouw productie proces. KPI-005 Financiële KPI ter illustratie: De Return on Investement (ROI) KPI vertelt je wat je terug hebt verdiend t.o.v. jouw inspanningen. Hoe hoger het getal, hoe beter. De ROI heeft betrekking op alle uitgaven en inkomsten. DY-UCnn KPI-006 KPI-007 DZ-UCnn KPI-008, … Enterprise generieke architectuur De L1-capabilities als startpunt voor de enterprise architectuur. VLOCA Capability map De VLOCA capabilities die in staat zijn om de doelstellingen en use cases te realiseren. De omkaderde capabilities zijn diegenen die werden gedetecteerd voor dit traject. Er zijn verschillende L1-value streams (= VLOCA-cirkel) aanwezig in het VLOCA Capability map: Visie en strategie ontwikkeling: Het vaststellen van een richting en visie voor een organisatie. Dit omvat het definiëren van de bedrijfsstrategie en het beheren van strategische initiatieven. Het creëren van een visie, een missie en strategische doelstellingen en dus om ervoor te zorgen dat de organisatie in de gewenste richting beweegt. Ontwikkelen en beheren van Smart City producten en diensten: Beschrijven van het aanbod met betrekking tot het concept van het ontwikkelen en beheren van 'Smart City' producten en diensten. Promotie van de Smart City producten en diensten: Het begrijpen van markten, klanten en mogelijkheden. Het ontwikkelen van marketingstrategieën. Het ontwikkelen, beheren en uitvoeren van marketingplannen. Het ontwikkelen van verkoopstrategieën. Het beheren van verkooppartners en allianties. Leveren van Smart City producten en diensten: Gaat over het plannen, beheren en uitvoeren van supply chain-activiteiten. Het aanschaffen van producten en diensten van leveranciers en het beheren van logistiek. Alsook het aanbieden van producten en diensten aan klanten en het identificeren van uitvoeringsplannen voor de levering van de verkochte producten en diensten. Opvolgen van klanten: Het opvolgen van klanten na de levering van producten en diensten. Dit omvat het ontwikkelen en plannen van klantenservice praktijken met het oog op het sturen van processen met betrekking tot vragen na verkoop, feedback, garanties en terugroepacties. Alsook zijn er verschillende (soorten van) L1-capabilities (= VLOCA-pillaren): Strategisch: Maken deel uit van de algehele strategie, ze ondersteunen (deels) de ambitie van de Vlaamse Overheid, Agentschap Binnenlands Bestuur & VLOCA. Strategic Control : Het definiëren en sturen van de VLOCA-visie, missie en strategie op steden en gemeenten Market Watch : Het definiëren en uitvoeren van onderzoek voor het begrijpen van de markten. Afhandelen van de externe marktanalyses (bv. PEST) als strategische input voor marketing afdelingen. Enabling: Creëren van mogelijkheden. Ze dragen bij aan het succes van operationele capabilities. Information Management : Informatie beheer is het bedrijfsproces van het verzamelen, opslaan, beheren en onderhouden van informatie in al zijn vormen gedurende de informatielevenscyclus. Operationeel: Wat een organisatie moet doen om zijn bedrijfsstrategie te kunnen uitvoeren. Zij worden gedefinieerd en opgebouwd doorheen de tijd, kunnen niet gemakkelijk worden geïmiteerd en vormen daarom een concurrentievoordeel voor de organisatie. Product Management: Ervoor zorgen dat de kwaliteit van alle producten (goederen en diensten) voldoet aan de verwachtingen in het aanbod. Deze capability omvat o.a. de markt- en consumentenbehoeften, productstrategie en portfolioveranderingen. Ook de ontwikkeling van productverbeteringen of nieuwe innovatie-ideeën komen aan bod. Supplier Management: Het beheren van de relatie die de lokale besturen onderhouden met haar leveranciers. Het omvat het stellen van doelen voor de samenwerking met leveranciers, het plannen van de activiteiten om met leveranciers in contact te komen, het classificeren van leveranciers op strategisch belang en het evalueren en controleren van leveranciers. Marketing Management : Beheert enerzijds de tactiek en anderzijds de marketing planning voor het komende jaar. Deze capability ontvangt zijn primaire informatie van andere capabilities zoals Market Watch, Product-, Sales & Distribution en Customer Management. Supply Chain Management : Coördineren van vraag en aanbod van/naar producten en diensten met klanten, medewerkers, partners en leveranciers. Sales & Distribution Management : Het beheren van de acceptatie van verkooporders via touchpoints , het coördineren van resterende activiteiten die nodig zijn om de bestelde producten en diensten aan de klanten en partners te leveren volgens een gespecificeerd leveringscontract. Customer Management : Het organiseren en beheersen van de continuïteit en ontwikkeling van kennis over de individuele B2B / B2C en klant en onze relatie met hem/haar. Het maken en beheren van overeenkomsten met klanten. Deze overeenkomsten kunnen formele (levering) contracten zijn, maar ook marketing toestemmingen en algemene voorwaarden, aanvaard door de klanten. Contact Center Management : Het registreren van de context en inhoud van het service request contact via tickets. Bevat service catalogi, waarin alle mogelijke vragen staan vermeld die we verwachten te behandelen met behulp van een kennisbank om de afhandeling van service requesten efficiënter en coherenter te maken. De kennisbank zorgt voor transparantie over beschikbare oplossingen & antwoorden op bekende problemen. Supporting: Waarde toevoegen aan andere capabilities. Geen specifieke concurrentievoordeel, kunnen worden geïmiteerd en uitbesteed. Finance : Beheer van alle business- en IT functies die nodig zijn voor het beheer van de financiële middelen van Smart City producten en diensten, inclusief boekhouding, treasury en interne en externe financiële rapportage. Human Resources : Beheer van alle activiteiten die nodig zijn om de best mogelijke match te creëren tussen de Smart City behoeften en de behoeften van de medewerkers die op de markt beschikbaar zijn om arbeid te verrichten. Het omvat het hele scala aan activiteiten, van instroom tot uitstroom van medewerkers, gedurende de gehele levenscyclus van medewerkers binnen een (lokale) organisatie. Enterprise architectuur (EA) principes EA principes (L1) definiëren de onderliggende algemene regels en richtlijnen voor het gebruik en de inzet van de L1-capabilities in de VLOCA trajecten. Ze weerspiegelen een mate van consensus tussen de verschillende architectuur onderdelen van het traject en vormen de basis voor het nemen van toekomstige beslissingen. Niet te verwarren met L2 & L3 vereisten (requirements). Enterprise architectuur principe beschrijvingen Bij het ontwerp van de transitiearchitectuur binnen trajecten & projecten dient er rekening te worden gehouden met de EA-principes. Voor elk principe wordt de volgende informatie verstrekt: Principe: een korte definitie van het principe, meestal in één woord Statement: een korte beschrijving wat we willen bereiken Rationale: de reden waarom het principe belangrijk is Implicaties: implicatie van het principe voor de uitvoerende organisatie EA Principe Statement Rationale Implicaties Functionaliteit in de juiste business area We zorgen er voor dat de ICT toepassingen zich binnen de juiste operationele omgevingen bevinden, binnen de steeds veranderde wensen en noden van de organisatie. Nieuwe en bestaande systemen en applicaties zullen de huidige grenzen van de operationele werking overschrijden. Creëren, bijwerken en onderhouden van business-, applicatie- en technologie architecturen via veranderingsgerichte ontwerpen. Omni channel We gaan voor een omni channel aanpak zodat de eindgebruiker tijdens een interactie, zoals aandacht (terug) aantrekken, kan schakelen tussen verschillende digitale kanalen. De eindgebruiker gebruikt de diverse digitale kanalen door elkaar terwijl de ervaring, prijzen, informatie, ... hetzelfde zijn. Alle digitale kanalen komen volledig samen, waardoor een volledig transparant proces ontstaat. Elk eindgebruiker gerichte applicatie dient te worden gebouwd met het oog op responsiviteit, zodat het geschikt is voor tablets, mobiele apparaten, pc/laptop, sociale media, chatbots, ... Op widget (of micro client)-niveau is co-development met derde partijen mogelijk, waarbij we niet alleen ICT services (IaaS & PaaS) delen, maar ook business services (SaaS). Cross Channel We gaan voor een cross channel aanpak zodat we de interacties tussen de eindgebruikers geïntegreerd kunnen afstemmen op de operationele activiteiten van de medewerkers van de Vlaamse Overheid. Op het eindgebruiker niveau worden business en ICT-services gebouwd met het oog op geïntegreerd gebruik van diverse operationele kanalen. Op het eindgebruiker niveau worden business en ICT-services gebouwd met het oog op geïntegreerd gebruik van diverse operationele kanalen. Implicaties: Door online en offline kanalen te mixen, dient de eindgebruiker op één uniforme manier bediend te worden zodat er zowel externe afspraken met de eindgebruiker, als interne afspraken tussen front- en back-office personeel dienen gemaakt te worden. In commerciële bedrijven zijn verkoopkanalen meestal gemixt, waarbij de klant er kan voor kiezen om artikelen online te bestellen en af ??te halen in een fysieke winkel. De klantenservice moet hiervan ook op de hoogte zijn. Hetzelfde principe kan toegepast worden door de burger centraal te stellen, want burgers, die in een ander context klanten zijn, verwachten hier ook een vlotte dienstverlening die tegemoetkomen aan hun noden. KISS Keep it simple, stupid. We willen eenvoud en duidelijkheid brengen in een steeds complexere ICT landschap. Systemen en applicaties als geheel volgen de solution architecturen, gemaakt in de PLAN fase, als input voor solution development in de BUILD fase. Afstemming nodig tussen VLOCA -, solution- en software architecturen via een architectuur & technologie governance. Ontkoppeling We willen dat de systemen en applicaties ontkoppeld worden, zodat ze onafhankelijker van elkaar werken. Om overal veranderingen te voorkomen met nieuwe systeem- en applicatie functies, worden lagen ontkoppeld door gebruik te maken van duidelijke en gedocumenteerde gestandaardiseerde interfaces. Presentatiegericht naar front-end en service gerichte interfaces naar back-end. Als technisch resultaat moeten de interfacing en aangepaste code naar de systemen en applicaties nauw aansluiten bij de technologie van de leverancier of de technologie van het ontwikkelingsteam. Robuustheid We willen betrouwbare systemen en applicaties die voldoen aan de noden en wensen van de eindgebruikers. Systemen en applicaties worden gebouwd, gekocht, samengevoegd en geconfigureerd volgens robuustheid criteria. Dit betekent dat een systeem of applicatie na een onderbreking zo snel mogelijk een aanvaardbare werkende staat moet hebben, waarbij de graad van robuustheid zal afhangen van de maturiteit en de positie van de ICT oplossing in de organisatie, zoals enerzijds de prototypes, MVPs, aangekochte (kern) en legacy systemen en anderzijds de front- en back-office applicaties. Onderhoudbaarheid We zorgen voor een degelijk onderhoud van de (nieuwe) ICT oplossingen binnen de gewenste prestatie vereisten. De algehele (business & ICT) operationele efficiëntie mag niet worden beperkt door nieuwe ICT oplossingen, noch zullen we enige functionele en technische achteruitgang van de huidige ICT oplossingen toestaan ??tijdens een projectfase. Operationele, business en ICT presatie (service) contracten dienen opgesteld te worden tussen dienstverleners en dienstafnemers, om zo de bedrijfscontinuïteit te waarborgen. Standaard software We gaan er zoveel mogelijk vanuit om eerst te herbruiken, dan aan te kopen en uiteindelijk te beslissen om systemen en applicaties zelf te bouwen. De systemen en applicaties volgen zoveel als mogelijk de "reuse, before buy & before build" richtlijnen. Dit betekent dat er (integratie) architectuur en technologie richtlijnen nodig zijn, zodat voorstellen van ICT-leveranciers / integratoren en deliverables van het ontwikkelteam kunnen worden bepaald zodat we op het juiste moment, de goede dingen doen teneinde ICT oplossingen uit te voeren aan de juiste prijs. Scheiding van verantwoordelijkheden We willen systemen en applicaties goed van elkaar scheiden zodat er meer mogelijkheden zijn voor uitbreidingen via (micro) componenten, hergebruik en onafhankelijke ontwikkeling (separation of concerns). De componenten en modules van de systemen en applicaties moeten worden gescheiden op basis van het soort werk dat wordt uitgevoerd. De realisatie van de ICT services dienen te worden geclassificeerd via functionele decompositie, zodat we de algehele complexiteit kunnen opsplitsen en de ontbonden elementen (componenten en modules) in kaart kunnen brengen op de business realisatie. Flexibiliteit We willen meer flexibiliteit inbouwen in de ICT ontwikkelingsomgevingen om de winstgevendheid en productiviteit van de ICT oplossingen te verhogen. De systemen en applicaties moeten worden ontworpen en aangestuurd om de kosten van toekomstige veranderingen te minimaliseren met respect voor de verschillende ICT evolutie behoeften binnen de organisatie. Dit impliceert dat ICT evoluties zoveel mogelijk onafhankelijk gebeuren binnen drie ontwikkelingslagen want presentatie-georiënteerde ontwikkelingen evolueren veel sneller in de front-ends dan ontwikkelingen in de back-ends. Dit weerspiegelt voor front-end ontwikkelingen in Agile methodieken en DevOps-tooling, in container- en workflow gebaseerde applicaties in de tussenlaag en in back-ends ontwikkelingen waar men de legacy / buy investeringen wenst te waarborgen. Deze verschillende ICT evoluties, leiden tot verschillende oplevering cycli (release cycles). Content, web en mobiele ICT evoluties veranderen veel sneller (wekelijks) dan producten die door de back-ends worden aangeboden (trimestrieel). Ontwikkeling en installatie processen en hun bijbehorende tooling, die verschillende technologieën, ontwikkelaar profielen en verwachtingen scheppen, moeten deze diversiteit van behoeften kunnen ondersteunen. Eindgebruikerservaring We gaan voor een passende eindgebruikerservaring die herbruikbaar is binnen verschillende web sites en mobiele toestellen. De passende gebruikerservaringen worden zoveel mogelijk bepaald op basis van de volledige cross-channel ervaring van de eindgebruiker ook wel customer journey genoemd. Dit betekent dat binnen een algemeen aanvaarde huisstijl (en een huisstijl per lokale entiteit), stijl gidsen (style guides) moeten worden gedefinieerd en geïmplementeerd, die bepalend zijn voor de keuze van UI-applicatie patronen. Zoals adaptieve schermen gebaseerd op de rol(len) van de eindgebruiker. Technologie standaardisatie We willen een éénmalige integratie met de achterliggende systemen en applicaties door meer in te zetten op service georiënteerde oplossingen. Reduceren van de technologiekosten door gebruik te maken van service georiënteerde oplossingen die worden aangedreven door interoperabiliteit, teneinde de herbruikbaarheid van de achterliggende systemen en applicaties te verhogen. Om interoperailiteit te organiseren, moeten applicaties worden ingedeeld in drie soorten applicaties: * consumer services in de front-ends of end-user experience, die informatie (inhoud) aan de eindgebruiker leveren * broker services in de service-communication laag, die de verzoeken van eindgebruikers van een willekeurig aantal consumer services naar provider services beheren. * provider services , in de back-ends of core systems laag, die informatie (inhoud) verschaffen, al dan niet via broker services, door toegang te krijgen tot gegevens die worden beheerd door een bepaald kern systeem (CRM, ERP, ...). De gegevensstromen die tussen de bovenstaande applicaties worden gebruikt, omvatten standaard gegevensformaten en protocollen, die worden beschreven in integratie architectuur documenten. Levenscyclusbeheer We willen een duidelijk zicht krijgen hoelang systemen en applicaties in de organisatie worden gebruikt. Men weet welke systemen & applicaties in de organisatie worden gebruikt om de organisatie te veranderen door middel van innovaties, en/of transformaties en/of verbeteringen. Maar ook welke systemen & applicaties er gebruikt worden om de organisatie draaiende te houden. Als gevolg hiervan moeten we ons ervan bewust zijn dat niet alle (huidige) ICT oplossingen worden geleverd met de bedoeling om eeuwig mee te gaan. Sommige ICT oplossingen voor nieuwe ideeën zijn erop gericht om snel te worden vervangen, zoals prototypes. Andere ICT oplossingen zijn er als 'enabler' voor gemeenschappelijke ideeën en worden daarom geleverd met de bedoeling om lang mee te gaan. Daarom is een technologie selectie proces nodig ondersteund door architectuur, zodat we de juiste investeringsbeslissingen kunnen nemen over de verderzetting van ICT oplossingen. Een heat-map dus met de betrokken applicaties en systemen. Schaalbaarheid We willen schaalbare systemen en applicaties om de toenemende communicatie, data en gebruik onderling tussen eindgebruikers, systemen en applicaties, aan te kunnen. De systemen en applicaties verwerken de toenemende werkdruk, volgens de eisen van de (eind)gebruikers, op een verwachte manier zonder daarbij in de fout te gaan. Dit door extra 'resources' toe te voegen aan het ICT landschap, extra vermogen voor deze 'resources' en een efficiënt beheer van het werkgeheugen en data. Systemen en applicaties zouden bij voorkeur steeds meer in de cloud of in tweede orde op schaalbare on-prem infrastructuur moeten worden aangekocht en/of geïmplementeerd. De applicaties moeten ook worden gekocht en/of gebouwd met het oog op 'service stateless', wat inhoudt dat (status) gegevens in een 'in-memory state' zoveel mogelijk dienen te worden gepersisteerd naar (tijdelijke) schaalbare databronnen. Bedrijfsbeveiliging We zorgen er voor dat de communicatie, data en gebruik onderling tussen eindgebruikers, systemen en applicaties op een veilige manier gebeuren. Alle ICT-oplossingen die binnen de organisatie worden gebruikt, moeten voldoen aan alle beveiligings- en privacybeleidsregels om de kans op inbreuken te verkleinen of liefst onmogelijk te maken. Gegevens zijn daardoor beschermd tegen ongeautoriseerd gebruik en openbaarmaking. Beveiliging moet in de eerste plaats vanuit een business perspectief worden bekeken, omdat beveiligingsbeleid nauw verband houdt met business veranderingen. De (lokale) organisatie(s) dient/dienen hiervoor een eigen beveiligingsbeheer (bv. group policies op departement, dienst, team, ...) te hebben waar eindgebruikers (users), rollen, toegankelijkheid, ... lokaal en centraal beheerd kunnen worden via duidelijke procedures, richtlijnen en standaarden. Als gevolg hiervan zullen we alleen toegang tot gegevens verlenen aan die personen die toegang zouden moeten hebben. Databeveiliging We willen vermijden dat de manier waarop data wordt behandeld en beheerd, grote beperkingen opleveren in de uitvoering van de activiteiten binnen de organisatie, waarbij we data zien als een enabler en niet als knelpunt. We zien data als een troef (data as a product) waaruit we verschillende voordelen kunnen creëren zoals de behoeften en ervaringen van de (eind)gebruikers beter leren kennen om een betere relatie te ontwikkelen, sneller kunnen reageren op veranderingen, verhogen van de operationele efficiëntie door transparante communicatie, beter kunnen beslissen via huidige en toekomstige inzichten, snellere verwerking van (gewijzigde) wet- en regelgevingen via notificaties uit betrouwbare bronnen, verlagen van allerlei risico's door hogere data kwaliteit, ... met data als onderdeel van de organisatie cultuur. Een data-gedreven organisatie omvat het correct classificeren via een betere segmentatie en gerichte communicatie in de organisatie. De organisatie en haar entiteiten hebben hiervoor een afgestemde data management en governance zodat (lokaal) georganiseerde data door de juiste stakeholders kan worden vertrouwd, georganiseerd en geconsumeerd. Een goed draaiende 'information management' haalt steeds meer gegevens uit interne systemen en applicaties en maak beter en nuttig gebruik van externe data, waarbij data kwaliteit van groot belang is voor het bepalen van efficiënte inzichten en nakomingen van o.a. GDPR regelgevingen. Om de datastromen die vertrekken van de operationele omgevingen naar de comsumptie omgeving in goede banen te leiden, is een overkoepelende Data Flow Manager (DFM) nodig om de data binnen en buiten de organisatie op te nemen, te transformeren en te distribueren. De hoofdtaak van de DFM is om data te verplaatsen en te laten evolueren over drie verschillende DFM-lagen, nl.: # Onboarding Data Layer , waarbij de data van de operationele omgevingen eerst tijdelijk worden opgeslagen in Landing Zones om ze nadien te consolideren waarop regels kunnen worden toegepast. De data met conflicten worden in een aparte quarantaine geplaatst, zodat de bronnen in de operationele omgevingen die kunnen verbeteren en opnieuw kunnen introduceren. # Integration Layer , waarbij de aanvaarde data wordt geïntegreerd volgens het business data model van de organisatie # Consumption Layer , zodat de (eind)gebruikers de benodigde gegevens in de meest geschikte formaten en technologieën, kunnen consumeren Enterprise specifieke architectuur Duidelijke indicatie van de business-, informatie- en applicatie architectuur op de gedetecteerde capabilities Strategic Control, Supplier Management, Marketing Management, Suppply Chain Management, Sales & Distribution Management, Customer Management, Contact Center Management & Information Mangement . Enterprise Business architectuur Capability realisatie vanuit een business perspectief, start vanuit business functies. Een business functie is een concept dat wordt gebruikt in het domein Business Architecture en vertegenwoordigt wat er wordt gedaan. Dit betekent dat we kijken naar het gedrag, de acties, oftewel wat er GEBEURT. Incentivering business architectuur tekening Incentivering business architectuur beschrijvingen Hierbij een lijst van de business functies die een extra woordje uitleg nodig hebben. Business functie Omschrijving Beheer tarificatie Tarificatie bevat de business logica om de prestaties van de Consumenten, alsook de handelstransacties van de Aanbieders te verwerken volgens de nomenclatuur. Tevens communiceert ze de verschillende tarificatie stappen met de financiële dienst. Beheer facturatie Facturatie verwerkt de binnenkomende vorderingen van de Aanbieders, stelt facturen op naar de Donors, berekent de verdeling van de uitbetalingen naar de Aanbieders en communiceert de verschillende facturatie stappen met de financiële dienst. Financieel & klanten beheer Boeken van (correcties op) vorderingen, voorschotten, provisies, saldi, ... Zakelijke woordenlijst Het hoofddoel van de zakelijke woordenlijst is om ons begrip van algehele terminologie te verbeteren, zodat we effectiever kunnen communiceren in de hele organisatie, in plaats van mensen woorden anders te laten gebruiken of hun eigen interne vocabulaire te laten ontwikkelen, wat leidt tot zinloze discussies. Data governance Het organiseren van een efficiënte informatiestroom binnen de organisatie, ervoor zorgen dat deze gemakkelijk vindbaar en moeiteloos toegankelijk is, rekening houdend met de geldende privacy wetgeving. Data beheer Beheer van (master)databronnen, waardoor data effectief en efficiënt kunnen worden ontsloten, verwerkt en gebruikt. Intelligentie beheer Het organiseren van het verzamelen, vormgeven en delen van (inzichtelijke) informatie-elementen over één enkel of een groep van onderwerpen en/of dingen . Inzicht in deze onderwerpen en dingen en hun gedrag door het profiel van een onderwerp of ding te beschrijven, ze in segmenten te groeperen, voorkeuren te voorspellen en de evolutie van het gedrag van deze onderwerpen en dingen in de loop van de tijd te volgen. Enterprise Information architectuur De business objecten, binnen de informatie architectuur, worden gebruikt om de bedrijfsconcepten en terminologie te communiceren en te beheren, samen met de bijbehorende definities en relaties tussen die termen. Bij business objecten kijken we naar de statische werkelijkheid, wat HEBBEN we. We onderscheiden 3 niveau’s : Het hoogste niveau zijn de informatie onderwerp gebieden of subject area’s, zodat men sneller kan navigeren naar deze gebieden die het meest interessant zijn en reeds eerste definities en relaties kunnen worden opgesteld en bepaald. Het tweede niveau zijn de L2-business objecten en deze maken deel uit van minstens één informatie onderwerp gebied. L2-business objecten zijn voor het merendeel een abstractie van de OSLO kern data entiteiten, dus zonder gerelateerde data entiteiten. Het derde niveau zijn de L3-business objecten en hun gerelateerde data entiteiten. Zij worden gekoppeld aan L3-business processen met vermelding van hun CRUD-actie (Create, Read, Update & Delete). Deze viewpoints worden beschreven in het Solutions Continuüm en maken dus geen deel uit van deze architectuur studie. Incentivering Supply Chain information architectuur tekening Incentivering Supply Chain informatie beschrijvingen Hierbij een lijst van de informatie elementen die een extra woordje uitleg nodig hebben. Subject Area of Business object OSLO-type Omschrijving Sponsor JA AGENT (generieke OSLO-classe). Consument JA AGENT (generieke OSLO-classe). Iemand die of iets dat kan handelen of een effect kan teweeg brengen. Aanbieder JA AGENT (generieke OSLO-classe). Aanbieder van het stimulansaanbod CriteriumVereiste JA Criterium dat toelaat te bepalen of een gebruiker recht heeft op een stimulansaanbod. Stimulansaanbod JA Bewijs JA De beschrijving van wat men moet voorleggen om te kunnen voldoen aan de CriteriumVereiste(n) van een specifiek Stimulansaanbod. Beloning JA Beschrijving van de beloning die bij een stimulansaanbod hoort. Dit is wat zal ontvangen worden bij de consumptie van dit stimulansaanbod. Dit is niet de effectief ontvangen beloning, maar de beschrijving van wat je zal ontvangen. Stimulans consumptie JA Consumptie van een stimulansaanbod Beloningsontvangst JA De effectieve beloning die ontvangen is bij de consumptie van een stimulansaanbod Bewijslevering JA Het bewijs dat effectief geleverd wordt bij de consumptie van het stimulansaanbod door een Agent. Incentivering Marketing informatie architectuur tekening Incentivering Marketing informatie beschrijvingen Hierbij een lijst van de informatie elementen die een extra woordje uitleg nodig hebben. Subject Area of Business object OSLO-type Omschrijving Product aanbiedingen NEE Vrijwillige maar voorwaardelijke toezegging die ter acceptatie aan de consument via een advertentie werd voorgelegd en die commercieel afdwingbaar wordt als deze door de consument wordt geaccepteerd. Campagnes NEE Een campagne is een gegroepeerde actie om gedurende een bepaalde periode een product aanbieding te promoten om consumenten te boeien Marketing betrokkenen NEE Een partij (individu of organisatie) die een interactie heeft met een handelaar, om een product en/of dienst te leveren. Marketingkanalen NEE Een marketingkanaal is waarop een burger of consument wordt blootgesteld aan het merk, product, dienst, ... van een bepaalde handelaar (via een marketing agentschap). Dus elke interactie die de perceptie van de consument kan veranderen. Promoties NEE Is een marketingactie die bestaat uit het bezorgen van een specifieke boodschap aan een specifieke subgroep van geselecteerde betrokkenen voor een bepaalde marketingcampagne. Sponsor JA AGENT (generieke OSLO-classe). Consument JA AGENT (generieke OSLO-classe). Iemand die of iets dat kan handelen of een effect kan teweeg brengen. Aanbieder JA AGENT (generieke OSLO-classe). Aanbieder van het stimulansaanbod DirectMarketing JA Directe communicatie met de consument, dit kan via kanalen zoals e-mail, sociaal media, (push) notificaties, websites, webchat, ... Consent NEE Vrijwillige indicatie van de wens van de burger of consument waarmee hij/zij akkoord gaat met de verwerking van de betreffende persoonsgegevens voor een bepaalde vorm van verwerking. Een toestemming kan 3 statussen hebben gegeven, niet gegeven of ingetrokken. Distributie JA PublicRelations JA Campagne met als doel om het imago te verbeteren VerkoopPromotie JA Reclame, advertenties, korting, PublicatieEvent JA Een PublicatieEvent zal altijd deel uitmaken van een bredere Campagne. Dit maakt het mogelijk om een Campagne op te starten die meerdere PublicatieEvents kan omvatten. Bevat o.a. de attribuut 'PublicatieKanaaltype' en dat kanaal wordt gebruikt om publicatie te verspreiden en staat dus dichter bij het publiceren ipv het maken van de inhoud. Campagne JA Een Campagne is het geheel van acties om te informeren en het stimuleren van gewenst gedrag bij het doelpubliek. InformatieObject JA InformatieObject kan de vorm aannemen van tekst, beeld, audio PublicatieExpressie JA Bevat o.a. de attribuut 'PublicatieTooltype' en die tool wordt gebruikt om publicatie te maken en staat dus dichter bij het maken van inhoud ipv het publiceren. Stimulansaanbod JA Incentivering Contact Center informatie architectuur tekening Incentivering Contact Center informatie beschrijvingen Hierbij een lijst van de informatie elementen die een extra woordje uitleg nodig hebben. Subject Area of Business object OSLO-type Omschrijving InformeerActie JA OSLO-Notificatie:InformeerActie Kennisgeving van informatie aan zij die het aanbelangt. Deze informatie kan via meerdere kanalen naar een individu of naar een doelgroep genotificeerd worden. NotificatieBericht JA OSLO-Notificatie:Notificatiebericht Een bericht van een afzender naar een bestemmeling met als doel het informeren van de bestemmeling. Melding JA OSLOthema-melding:Melding Beschrijft de melding van een probleem of een vaststelling die mogelijks aanleiding geeft tot een actie van de overheid. De Melding kan gebruikt worden voor het capteren van feedback met betrekking tot concrete informatievelden. Terugmelding JA OSLOthema-melding:Terugmelding Beschrijft de terugmelding van fouten of onvolledigheden in digitale gegevensbronnen naar de verantwoordelijke bronbeheerder. Een terugmelding kan gebruikt worden om bijvoorbeeld een foutief adres te melden op een website of een fout in de digitale weergave van een diploma. Meldingsobject JA OSLOthema-melding:Meldingsobject Het Meldingsobject identificeert een resource,een specifiek deel van een resource,een bepaalde representatie van een resource of een combinatie hiervan welke gebruikt wordt binnen de (Terug)Melding. In de praktijk kan het Meldingsobject beschreven worden aan de hand van instanties van de klasse Eigenschap. Het Meldingsobject heeft een Dataset als bron en een TijdToestand, om de datum en het tijdstip vast te leggen, waarop het Meldingsobject dient ge nterpreteerd te worden. De klasse Eigenschap beschrijft de data velden waaruit een Dataset bestaat met Concept waarden bestaande uit een exhaustieve lijst aan mogelijk waarden (bv. een codelijst). Behandelaar JA OSLO-Generiek:Agent (Applicatie, Organisatie of Persoon) Agent die werd aangewezen om de melding en/of het meldingsobject op te volgen en af te handelen. Indiener JA OSLO-Generiek:Agent (Applicatie, Organisatie of Persoon) Agent die de Melding heeft aangemaakt en/of ingediend. Betrokkene JA OSLO-Generiek:Agent (Applicatie, Organisatie of Persoon) Agent die als derde belang heeft bij de Melding of ge mpacteerd is door de behandeling ervan. Bijvoorbeeld indien de melding werd aangemaakt door een derde, bijvoorbeeld een ambtenaar van de gemeente op vraag van een burger. Melder JA OSLO-Generiek:Agent (Applicatie, Organisatie of Persoon) De Agent die het probleem waarover gemeld wordt opmerkte. De melder zal niet telkens gekend zijn. Bijvoorbeeld in het geval van een anonieme melding via een website. Enterprise Applicatie architectuur De Applicatie Architectuur ondersteunt de Business Architectuur. De L2-Application Components realiseren de L1-capabilities, waarbij de L3-applicatie elementen, die behoren tot het Solutions Continuüm en niet in-scope voor deze studie, een "implementatie" is van de L3-business processen. Incentivering applicatie architectuur tekening Hierbij een lijst van de applicatie componenten die een extra woordje uitleg nodig hebben. Applicatie Component Omschrijving Strategic Management Tool Strategic management tools omvatten instrumenten als een SWOT-analyse en een PEST-analyse. Men gebruikt deze tools voor strategische managementplanning om precies te bepalen waar men de komende jaren en daarna naartoe gaat en hoe ze daar moeten komen. Data Explorer Technologie dat op een eenvoudige wijze de evolutieve ‘Onboarding’ gegevens kan opnemen waarop men binnen enkele seconden, complexe ad-hoc queries op deze gegevens kan uitvoeren. De source connectoren zijn verantwoordelijk om een technische verbinding te maken met de externe bron en leest de brongegevens uit in de meeste geschikte formaat volgens de data-verantwoordelijke van de brongegevens, na voorlegging van gesupporteerde connectoren van de gekozen ‘Data Explorer’ technologie. Indien de gewenste connector niet standaard aanwezig is, moet het mogelijk zijn om een custom connector te maken. ETL Technologie dat bij het beheren van databanken verwijst naar extraheren (Extract), transformeren (Transform) en laden (Load) naar drie afzonderlijke functies die worden gecombineerd in één technologisch platform. API Management API-management technologie wordt ingezet om een zo goed mogelijk beheer te hebben van gegevensuitwisseling, dit zowel voor de data-consument (consumer) als voor data-producent (producer). APIs stellen gegevens ter beschikking voor consumptie via drie specifieke 'Loads' meestal binnen een near/real-time streaming context waarbij de consumer applicatie zich aanpast aan de aangeboden data definities van de APIs: * initial loads, eerste keer, met geplande downtimes en meestal grote hoeveelheid aan data * incremental loads, volgende keren, met eventuele downtimes en meestal minder grote hoeveelheid aan data aangezien deze worden uitgevoerd na initial loads. * recurring loads, voor gewijzigde gegevens via zero-downtime deployment d.m.v. on-the-fly schema migraties (delta files) en meestal voor kleine hoeveelheid aan data aangezien deze gebeuren na de incremental loads. Men dient voor deze ‘Load’ type wel de keuze te maken om dit ofwel verder aan te bieden via het data of applicatie integratie platform. Business Intelligence (BI) Technologie ten dienste voor de: * data-analist: ze analyseren de verstrekte gegevens om bv. de omzet van de organisatie te verbeteren. Ze hebben mogelijk een data-mart nodig, inclusief enkele aggregaties, toegepaste bedrijfsregels en filtering, en het gebruik van een datamodel als dimensionale modellering die analytische query's mogelijk maakt. * BI-ontwikkelaar: ze hebben toegang tot de ‘Organized Data’ om data marts, BI-rapporten en dashboards te maken voor de data-analisten en/of BI-eindgebruikers. * BI-eindgebruiker: ze hebben gegevens nodig uit de ‘Organized Data’ en/of de beschikbare data marts van de BI-ontwikkelaars, alsook self-service BI tooling dat hen in staat stelt om de gegevens te verkennen en te exploiteren. Artificial Intelligence (AI) Technologie dat de data scientist in staat stelt om data: * te verkennen: gegevens worden verkend om te selecteren welke gegevens nuttig zijn voor hun model * te exporteren: nadat de gegevens zijn geselecteerd tijdens de verkenning, exporteren de data scientists de vereiste gegevens naar hun eigen data science workbench om feature-engineering en model training op te starten. * te industrialiseren: wanneer het analytische model klaar is om in productie te worden gebruikt, zal een geautomatiseerd proces de gegevens van de ‘Organized Data’ exporteren naar de data science industrialization omgeving. * te trainen: data scientists moeten hun analytisch model ook vaak trainen en kalibreren op basis van productie gegevens. * Data scientists gebruiken o.a. tools en talen als python, R, databricks, ...om de data te analyseren en analyse modellen te creëren. Datawarehousing Is de technologie waar de gegevens centraal worden gehistoriseerd waaruit men verder deze gegevens geaggregeerd, getransformeerd en verrijkt kunnen ophalen om geinformeerde keuzes te kunnen maken d.m.v. rapportages of/en-analyses. Master Data Management Is de technologie om de belangrijkste bedrijfsgegevens te beheren ter ondersteuning van de transactionele of operationele gegevens. Master data beschrijft op een unieke wijze de klanten, medewerkers, materialen, leveranciers, enz. die bij data uitwisseling betrokken zijn. Ze worden typisch onderverdeeld in ofwel Plaatsen (locaties, geografie, sites, ...), Partijen (personen, klanten, leveranciers, werknemers, ...) en Dingen (producten, materiaal, voertuigen, ...). Document Management ERP Via een ERP-oplossing kan elke afdeling of elk bedrijfsdomein onafhankelijk en centraal beheerd worden. Voordelen zijn onder meer interoperabiliteit van gegevens, verbeterde communicatie en verhoogde gegevensbetrouwbaarheid door het gebruik van een enkele database. ERP verbetert ook de kwaliteit van bedrijfs-brede besluitvorming. Een op maat gemaakte bestelling kan bijvoorbeeld van de verkoopafdeling naar voorraadbeheer gaan en vervolgens naar facturering naar financiën en productie. Door een ERP te gebruiken, is dit type proces een efficiënte en continue reeks gebeurtenissen die het gemakkelijk maken om individuele bestellingen te volgen. CRM Customer Relationship Management (CRM) is een technologie voor het centraal beheer van alle relaties en interacties van een organisatie met zijn (externe) contactpersonen. Een CRM-systeem biedt een 360-graden beeld van hun contact, waardoor ze betere relaties kunnen opbouwen door persoonlijker en relevanter te communiceren. Derdebetalersysteem Het derdebetalerssysteem verwijst naar de mogelijkheid om het volledige bedrag van handelstransacties niet direct te moeten betalen in digitale munt. Het is een soort alternatief voor de klassieke terugbetaling, een meer directe en toegankelijke oplossing. Bij dit systeem wordt de ontvanger rechtstreeks door de donor vergoed. Dit betekent dat er geen directe betaling moet gebeuren tussen de burger en ontvanger en dat de ontvanger na de prestatie wordt terugbetaald. Als men een derdebetalerssysteem toepast, betaalt men alleen het persoonlijk aandeel, indien van toepassing, d.w.z. het bedrag dat na tussenkomst van de donor nog voor eigen rekening van de burger blijft. +
Architectuur Vlaamse Open City Architec … Architectuur Vlaamse Open City Architectuur Bedrijfsarchitectuur IT-architectuur Open Smart City Architectuur Principes Standaarden Onderwerpen Stand van zaken VLOCA-Trajecten City of Things Gemeente zonder Gemeentehuis VLOCA-bibliotheek Zoeken per thema Werkgroepen en verslagen Projectwerking VLOCA projectwerking Architectuurstandaard Traject charter Bedrijfsarchitectuur Bestekteksten Informatienoden Marktanalyse Stakeholderanalyse Use cases prioritering Use cases roadmap Draaiboeken VLOCA-model IT-Architectuur Conformiteitsmodel Technische Architectuur tekeningen Vereistenmodel VLOCA assessment VLOCA Donut OSLO Co-creëren Open voor bijdrage Deelnemen aan werkgroepen Kandidaatstandaarden Forum Begrippen Termen & Concepten Organisaties Initiatieven Standaarden Nieuwsberichten Nieuwsoverzicht VLOCA-talks Agenda Werkwijze Waarom Mediawiki Hoe aanvullen Handige tools Page discussions Governance procesools Page discussions Governance proces +
Architectuurstandaarden Het gebruik van … Architectuurstandaarden Het gebruik van architectuurstandaarden voor slimme steden is essentieel. Het maakt mogelijk om een generieke architectuur uit te werken dat zowel specifiek bruikbaar is voor de gebouwde use cases als voor andere use cases. Herbruikbaarheid van bouwstenen staat hier centraal. Onder een architectuurstandaard verstaan we onder meer: Gebruik van gevalideerde principes ; Herbuikbaarheid van bouwstenen; Gestandaardiseerde aanpak, deliverables en formaat ; Definitie van een semantische lijst; Architectuur in co-creatie en architectuurstandaard in peer review en validatie. VLOCA zal vanaf 2023 open city architectuurstandaarden opleveren. Deze pagina wordt verder aangevuld.n. Deze pagina wordt verder aangevuld. +
Augmented Reality Markup Language 2.0 (ARM … Augmented Reality Markup Language 2.0 (ARML 2.0) stelt gebruikers in staat om virtuele objecten in een Augmented Reality (AR) scène te beschrijven met hun verschijningsvormen en hun ankers (een breder concept van een locatie) gerelateerd aan de echte wereld. Daarnaast definieert ARML 2.0 ECMAScript bindingen om de AR-scene dynamisch aan te passen op basis van gebruikersgedrag en gebruikersinput. [[Open Geospatial Consortium (OGC) | Overzicht van OGC Standaarden ›]][Open Geospatial Consortium (OGC) | Overzicht van OGC Standaarden ›]] +
BO Fase BC ID Naam business capaci … BO Fase BC ID Naam business capacity Fase 1 BC1.1 Donor transacties Fase 1 BC1.2 Spender transacties Fase 1 BC1.3 Spender(+Collector) Saldo Fase 1 BC1.4 betaling Fase 1 BC1.5 Overzicht Fase 2 BC1.7 cadeaubonnen Fase 3 BC1.8 gratis parkeren Fase 1 BC2.1 Integratie Applicaties Fase 2 BC2.2 cross applicatie Fase 2 BC2.3 op mijnburgerprofiel Fase 1 BC3.1 Donor Registratie Fase 1 BC3.2 Handelaar Registratie Fase 1 BC3.3 Burger Registratie Fase 2 BC3.4 Burger Promo Participatie Fase 1 BC3.6 Regels en Rechten Fase 2 BC3.7 Limiet van donor Fase 3 BC3.8 Anonieme Test Registratie Fase 1 BC3.9 Vendorlocking vermijdend Fase 1 BC3.10 e-inclusie Fase 3 BC3.10 Validatie 'goede doel' collector Fase 2 BC4.1 Doelgroepen Fase 1 BC4.2 Targeting Fase 1 BC4.3 Acquisitie Fase 3 BC4.4 Communicatie Fase 1 BC5.1 Donatie Fase 1 BC5.2 Verzilvering Fase 2 BC5.3 NBB Licentie Fase 1 BC5.4 Wisselkoersen Fase 1 BC5.5 Waardeverlies Fase 3 BC5.6 Waarde Fluctuaties? Fase 2 BC5.7 Afromen Slapende munten Fase 2 BC6.1 Impact campagne Fase 2 BC6.2 ROI berekening Fase 2 BC6.3 Rapportage Fase 2 BC6.4 Drill Down Fase 2 BC6.5 Churn Prediction Fase 2 BC6.6 Forecasten Fase 1 BC7.1 Integratie nieuwe stad of gemeente Fase 1 BC7.2 Integratie Applicatie Fase 1 BC7.3 OSLO standaarden Fase 1 BC7.4 herbruikbare munten Fase 2 BC7.5 punten vs munten Fase 3 BC7.6 Acties ipv munten of punten Fase 1 BC7.7 AML en KYC Fase 1 BC8.1 Uitrol / implementatie Fase 1 BC8.2 Nieuwe ontwikkeling Fase 1 BC8.3 GDPR Fase 2 BC9.1 Automatische terugvloeing Fase 1 BC9.3 goed gedrag vs lokale economie Fase 1 BC10.1 Standaard Antwoorden Fase 1 BC10.2 FAQ Fase 1 BC10.3 Klachten Fase 2 BC10.4 Reviews Fase 2 BC10.5 Inzichten Fase 1 BC11.1 Handelaars Fase 1 BC11.2 Shopper Fase 2 BC11.3 Inzichten Fase 3 BC11.4 Commissies Fase 1 BC11.5 Fraudebesrijding Fase 3 BC11.6 Betalingskaarten Fase 3 BC11.7 Domiciliering/doorlopende opdrachten Fase 3 BC11.8 Overschrijvingen Fase 2 BC11.9 Cancellations Fase 1 BC11.10 QR of andere 'bonnen' Fase 1 BC11.11 Gecombineerde munten Fase 1 BC11.11 Gecombineerde munten +
BUILDING TRUST AND VALUE IN IN DATA ECOSYS … BUILDING TRUST AND VALUE IN IN DATA ECOSYSTEMS Data can be exchanged between companies and governments, from governments to companies and can even be exchanged between citizens. Yet, if there is no trust between these actors, societal and business value cannot be created on a sustainable way. Today, the lack of trust is a major barrier to exchange data. How to build trust in complex ecosystems and create value from your data? During this webinar you will learn more about how different stakeholders can exchange data into the entire ecosystem in a trustworthy way. We will answer some of the following questions: How can value be created, captured and shared in the context of a data ecosystem? How can data quality be ensured? Can companies, governments and the citizens trust the data ecosystem with their data? Is the data exchange reliable? Date: June 3 rd , 14:00 - 16:00 Registration: https://share.hsforms.com/1yg4-bvtvRPmVhtsHwvrXzQ42q9f Registered participants will receive the MS Teams-link a few days before themeeting. Slides You can download the slides here: The workshop can be rewatched on Youtube Agenda (2h online event) 14:00 - 14:10 Welcome. Juanita Devis, imec-SMIT 14:10 - 14:30 Data ecosystems and Value Models in the open city: what are we talking about. Mark De Colvenaer DSP Valley 14:30 - 15:00 A framework for understanding value and trust in data ecosystems and an interactive discussion (part 1). Ruben D’Hauwers, imec-SMIT 15:00 - 15:05 Break 15:05 - 15:45 A framework for understanding value and trust in data ecosystems and an interactive discussion (part 2). Ruben D’Hauwers, imec-SMIT 15:45 - 16:00 Wrap-up and next steps6:00 Wrap-up and next steps +
Backward compatibility Met Backward comp … Backward compatibility Met Backward compatibility verstaan we dat een software/ data / hardware van versie n , kan interageren van versie n + 1 of n - 1 Hoe dit geïmplementeerd kan worden, staat mooi beschreven op volgende webpagina: https://stackoverflow.blog/2020/05/13/ensuring-backwards-compatibility-in-distributed-systems/compatibility-in-distributed-systems/ +
Bedrijfsarchitectuur VLOCA architecten … Bedrijfsarchitectuur VLOCA architecten werken volgens een standaard methodiek samen met initiatiefnemende lokale besturen in het tot stand komen van een uitgewerkte bedrijfsarchitectuur. In het VLOCA model worden exploratief alle mogelijk relevante elementen opgesomd. De stad voor wie de use case specifiek uitgewerkt wordt maakt de keuze tussen welke elementen in scope van het project zijn en welke niet. De niet meegenomen elementen worden hier gedocumenteerd als startpunt voor vervolgprojecten al of niet in dezelfde stad of gemeente. Tussen de overgebleven elementen worden prioriteiten gesteld, waaruit uiteindelijk een roadmap kan worden gefilterd, dat de aanzet is van het plan van aanpak van het te realiseren project door de stad. Data en informatie wordt hier eveneens bekeken: de informatienoden worden in kaart gebracht. Een OSLO project kan hieruit volgen, met de totstandkoming van een semantische standaard als doel. Business capabilities Wat moet de oplossing specifiek kunnen waarmaken? Bestaat uit data vereisten, functionaliteiten en techniciteiten Data vereisten Welke data hebben we nodig? Aan welke parameters moet de data voldoen? Functionaliteiten Wat moet een toepassing met informatie kunnen? Wat is de interactie tussen toepassingen? Techniciteiten Wat zijn de technologische vereisten? Welke technologieën moeten onderling verbonden worden?ën moeten onderling verbonden worden? +
Beschrijving van de dataflows naar en vanuit het Flood4Cast-voorspellingsalgoritme +
Boolean This property is used to mark pages that can be used as tags for other pages. +
Bouwlagen ArchitectuurBouwlaag Bouw … Bouwlagen ArchitectuurBouwlaag Bouwlagen OpenDei Data Capture Personal Data Segment Broker Segment Capture Segment Compute Segment Federation Segment IAM Segment Personal Data Segment Process&Transform Segment Service Segment Storage&Logisticsment Service Segment Storage&Logistics +
Bovenstaand schema geeft het overzicht van de in opbouw zijn architectuur en de dataflow voor de use case: Machine Learning toepassing voor laagwatervoorspellingen op onbevaarbare waterlopen adhv open data . Databronnen tbc +
Brugge Smart City Bram De Vreese, Datam … Brugge Smart City Bram De Vreese, Datamanager bij de Stad Brugge , gaat in gesprek met Steven Degelaen, VLOCA communicatie coördinator bij ABB . Bram vertelt over de ontwikkeling van de Brugse “Local Digital Twin” en het verloop van het VLOCA-traject. Steven: Hoe is in de stad Brugge het idee gerijpt om een Local Digital Twin te ontwikkelen? Bram: In de Beleidsnota 2019-2024 heeft ons bestuur de ambitie geuit dat door het gebruik van technologie betere inzichten moeten komen uit beschikbare data. Technologie wordt in Brugge dus niet beschouwd als een doel op zich, maar wel als een middel om maatschappelijk relevante doelstellingen te bereiken. Het doel van onze deelname aan het VLOCA-traject Local Digital Twin was om ervaringen en kennis uit te wisselen over de ontwikkeling van zo’n digitale tweeling van een stad, en dit specifiek uit te werken voor een aantal use cases en domeinen zoals luchtkwaliteit en mobiliteit. Tegelijk is dit allemaal vrij nieuw en innovatief. We kijken dus ook graag over onze grenzen heen en laten ons inspireren door voorbeelden uit andere landen, en laten ons in de realisatie van onze ambitie begeleiden door specialisten. Steven: Wie was er vanuit de Stad Brugge bij dit traject betrokken? Bram: Binnen onze stad werd er initieel een innovatieworkshop georganiseerd. Experten uit verschillende diensten werkten samen met VLOCA om de use case uit te werken. In de verfijnde use case werd de toegevoegde waarde voor de stad voor alle betrokken partijen stelselmatig duidelijker. Deze dienstoverschrijdende manier van samenwerking is intussen tevens in heel wat andere projecten ingeburgerd binnen het Brugs lokaal bestuur. Steven: Hoe ondersteunt de ontwikkeling van een digitale tweeling het beleid van de stad? Bram: De initiële aanname was dat experten de impact van nodige ingrepen op voorhand kunnen simuleren, scenario's modelleren om tot een beredeneerde oplossing te komen, op vraag van de beleidsmakers, voor onze burgers. Het is intussen wel duidelijk dat dit instrument ons bestuur kan toelaten om betere beleidsbeslissingen te nemen. In het verleden werd er vaak gebruikt gemaakt van ruwe data, maar door verfijning en juiste kadering binnen de Local Digital Twin moeten we in de toekomst in onze stad sterker onderbouwde beslissingen kunnen nemen. Steven: Is bepaalde kennis of ervaring nodig bij de beleidsmakers om de oplossing te gebruiken? Bram: Het is niet zo dat het een machine is die alle beslissingen voor de beleidsmensen zal voorkauwen. Duiding, ervaring en voorkennis blijven noodzakelijk om met deze technologie de juiste beslissing te nemen. Experten kunnen aan de hand van de tool heel wat voorbereidend werk verrichten maar uiteindelijk behoudt de beleidsmaker de nodige ruimte om accenten te leggen en de beslissing te nemen. Het interpreteren van data en het bij elkaar brengen van nog andere relevante parameters blijkt van belang. Bij het interpreteren van de gegevens en het formuleren van besluiten nemen partners zoals de Vlaamse Milieu Maatschappij en het departement Mobiliteit en Openbare Werken een waardevolle rol op. Steven: Welke toegevoegde waarde leverde VLOCA voor het lokaal bestuur? Bram: Het principe "kennis delen is kennis vermenigvuldigen" is cruciaal. Met onze partners bouwen we samen aan onze ambitie: de kennisinstellingen imec en VITO speelden een voorname rol, andere lokale besturen en onze partner Urban Sense (Cegeka – Sirus) leverden hun inzichten en bespraken hun behoeften, en de Vlaamse Overheid stimuleert het project door financiering, raad en daad. Het VLOCA initiatief bij ABB is als co-creatie platform een duidelijke meerwaarde in onze ontwikkeling gebleken maar ook de technologische principes legden de basis van de realisatie van de digitale tweeling. Het model biedt toegevoegde waarde voor de Stad Brugge maar ook voor andere lokale besturen met vergelijkbare doelstellingen. De beschikbare middelen bij alle lokale besturen zijn beperkt; daarom is het handig om beroep te doen op een groep experten om samen oplossingen te zoeken voor gemeenschappelijke uitdagingen. Steven: Wat is de volgende stap voor de digitale tweeling van de stad Brugge? Bram: De digital twin is een virtuele voorstelling van een echte situatie maar ze moet verder gaan dan enkel een 3D-voorstelling van de stad. Het is een voorstelling van de visie van onzen stad en alle factoren die het leven in de stad beïnvloeden. Onze ambitie in Brugge is om verder te gaan dan luchtkwaliteit en mobiliteit: andere factoren zoals druktemeting op het openbaar domein, hittemetingen, toeristische bezetting, calamiteiten zoals COVID-19 willen we meenemen als parameters in de digitale tweeling. Hierbij ligt de uitdaging niet zozeer bij het technische luik, maar eerder in het scherpstellen van de use cases, het correct interpreteren van de problematiek en de omzetting ervan in beleid. Steven: En daarin speelt allicht ook co-creatie een rol? Bram: Jazeker. Want als er één ding is dat we hebben geleerd, is dat we straffe ambities niet op eigen houtje kunnen realiseren. We blijven een voortrekkersrol in Vlaanderen spelen door onze ervaringen te blijven delen en staan open voor ervaringen van collega besturen en experten. +
Business werkgroep Slimme Markten Tijden … Business werkgroep Slimme Markten Tijdens de eerste sessie, de “business werkgroep”, duiken we in de use cases. Eerder werden er al een aantal use-cases geformuleerd door het kernteam. Deze werden verwerkt in het VLOCA-model. Het doel van deze sessie is om de use-cases te valideren, eventueel bijkomende use-cases te formuleren en de scope van het project af te bakenen. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen. Heb jij interesse, specifieke noden, expertise of andere belangen bij dit traject? Klik hier om je in te schrijven. Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2024-09-26 13u-16u VAC Leuven Thematische werkgroep 1 Data en informatie werkgroep 2024-10-21 13u-16u Teams Thematische werkgroep 2 Functionele werkgroep 2024-11-21 13u-16u Teams Thematische werkgroep 3 Technologie werkgroep 2024-12-19 13u-16u Teamsgroep 2024-12-19 13u-16u Teams +
Business werkgroep VlocaTraject/Citerra … Business werkgroep VlocaTraject/Citerra Tijdens de eerste sessie, de “business werkgroep”, duiken we in de use cases. Eerder werden er al een aantal use-cases geformuleerd door het kernteam. Deze werden verwerkt in het VLOCA-model. Het doel van deze sessie is om de use-cases te valideren, eventueel bijkomende use-cases te formuleren en de scope van het project af te bakenen. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen. De business werkgroep vond plaats op 27 februari 2024. Context Initiatief In samenwerking met Mobiliteit en Parkeren Antwerpen en de Stad Antwerpen werkt VLOCA (Vlaamse Open City Architectuur) samen met OSLO (Open Standaarden voor Linkende Organisaties) aan een City of Things project genaamd "Citerra". Citerra staat voor 'City Environmental Regulations and Rights for Access' voor steden, gemeenten, bedrijven, burgers, verenigingen en overheden , en heeft als doel de link te leggen tussen de genoemde stakeholders en de lokale regelgeving. Het doel van Citerra is om alle regelgevingen te centraliseren en te uniformeren, waarbij de aanvragen voor vergunningen kunnen worden ingediend. De focus van dit City of Things traject ligt op vergunningen voor autoluwe zones of gebieden met cameratoezicht. Hoewel de Stad Antwerpen het project leidt, is het de bedoeling om dit initiatief breder te zien richting alle lokale besturen. Op dit moment is de informatie over verschillende gereglementeerde zones in de stad niet goed georganiseerd, wat het voor burgers en bedrijven moeilijk maakt om te begrijpen welke regels waar van toepassing zijn. Het handmatig invullen van persoonlijke gegevens bij herhaalde aanvragen leidt ook tot frustratie. Om dit te verbeteren, streeft het project ernaar gebruikers zelf hun profiel te laten beheren, inclusief het toevoegen van extra nummerplaten, en om gegevens automatisch in te vullen bij nieuwe aanvragen. Bovendien voldoet het project aan de Europese Commissie Directive over "Intelligent Transport Systems" door steden te verplichten Urban Vehicle Access Rights (UVAR) data naar het Europese Platform te uploaden, wat geautomatiseerd zal verlopen. VLOCA VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders. OSLO Het doel van OSLO is om de datastromen semantisch te modelleren en de structuur van de data te standaardiseren in de context van lokale economie. Hierbij zal de focus gelegd worden op het verbeteren van de gegevensuitwisseling tussen lokale handelaars, horeca ondernemers en beleidsmakers. Met OSLO wordt er concreet ingezet op semantische en technische interoperabiliteit. De vocabularia en applicatieprofielen worden ontwikkeld in co-creatie met o.a. Vlaamse administraties, lokale besturen, federale partners, academici, de Europese Commissie en private partners (ondertussen meer dan 4000 bijdragers). Extra informatie en een verzameling van de datastandaarden zijn te vinden op volgende links: https://overheid.vlaanderen.be/oslo-wat-is-oslo en https://data.vlaanderen.be/ Brainstormsessie Het doel en de aanpak van de brainstormsessie worden hieronder beschreven. Tevens wordt de uitkomst van de brainstorm hierin samengevat. Doel van de brainstormsessie Het doel van de brainstormsessie is het volgende: De missie, visie en doelstellingen van het project, zoals geformuleerd in het VLOCA-model, valideren en feedback capteren De use cases, zoals geformuleerd in het VLOCA-model, valideren en feedback capteren Missie, visie en doelstellingen Missie Wat willen we bereiken? “Een centraal platform aanbieden om vergunningen voor burgers, ondernemingen en verenigingen aan te vragen dat benaderd kan worden vanuit MijnBurgerProfiel, e-loketondernemers en het verenigingsloket. Het dient ook gekoppeld te zijn aan de bestaande aanvraagsystemen van de steden en gemeenten.” Discussie De volgende opmerkingen werden gegeven: - Het gaat ruimer dan enkel aanvragen, ook beheren van de aanvraag. - Er worden slechts drie entiteiten genoemd: burgers, ondernemingen en verengingen, omdat steden en gemeenten ook onder ondernemingen vallen. - Iedere entiteit van de Vlaamse Gemeenschap, waaronder ook steden en gemeenten vallen, heeft een OVO-code dat dient als een soort ondernemingsnummer. - Hier worden enkel de loketten vernoemd, er moet ook vermeld worden dat er een permits.be moet komen. Eventueel kan het woord ‘minstens’ toegevoegd worden. - Het overkoepelende doel is om een one-stop-shop te maken zodat je niet naar die lokketten moet gaan. - Bij het vernoemen van vergunning bedoelen we, meer specifiek, een vergunning voor een autoluwe zone. Visie Wat is de bestaansreden? “Op dit ogenblik kunnen vergunningen voor verschillende gereglementeerde zones binnen een stad/gemeente helemaal niet digitaal of enkel via diverse websites per stad/gemeente aangevraagd worden. Dit is erg onoverzichtelijk en men moet zelf op zoek gaan naar wat er waar geldt en waar er, indien gewenst, extra rechten kunnen aangevraagd worden.” Discussie De volgende opmerkingen werden gegeven: - Voor ondernemingen kan het verwarrend zijn hoe de aanvragen moeten gedaan worden in de verschillende gemeenten. - We spreken beter van ‘lokaal bestuur’ wanneer we verwijzen naar stad of gemeente. Doelstellingen Wat is het doel van het project? “ 1) De aanvraagsystemen van steden en gemeenten te koppelen aan een centraal (e-loket) platform waar burgers, ondernemingen en verenigingen aanvragen kunnen doen en op die manier het ‘only-once principe’ te realiseren. 2) De steden en gemeenten via IPDC/LPDC de data en voorwaarden voor een vergunning laten beheren zodat dit kan ontsloten worden naar het centrale platform. 3) De statussen van vergunningen kunnen gevolgd worden en de goedgekeurde vergunningen kunnen worden gecommuniceerd. “ Discussie De volgende opmerkingen werden gegeven: - De scope vandaag is beperkt tot een vergunning van een voertuig. Is een onderscheid nodig tussen een persoon en een voertuig? In stad Gent wordt de vergunning gekoppeld aan een persoon die via het eLoket een nummerplaat kan linken aan zijn/haar/x vergunning. Uiteindelijk wordt de handhaving dus telkens gedaan via de nummerplaat van het voertuig. - Voor de OSLO-standaard zal het recht vasthangen aan de persoon, de persoon of de volmacht nemer om toegang te verlenen aan het voertuig. - Op dit moment wordt handhaving uitgevoerd via MAGDA om te controleren of het voertuig rechtmatige toegang heeft verkregen. Use cases ID Samenvatting Beschrijving UC1 UC1: Registratie Registratie UC2 UC2: Informatieplatform informatie platform en zoek opdrachten UC3 UC3: Profiel & Formulier aanvullen Profiel aan- en formulier invullen UC4 UC4: Indiening Indienen aanvraag UC5 UC5: Opvolging dossier opvolging dossier UC6 UC6: toekenningsproces toekenning, weigering, betwisting, advies aanvraag UC7 UC7: dossierbeheer beheer dossier (overzicht, toevoegingen, verlengingen, aanpassingen, herinneringen, …) UC8 UC8: Message Center CRM voor communicatie (uitgaande/inkomende, contact strategie en historiek) UC9 UC9: Helpdesk helpdesk & FAQ & Reviews UC10 UC10: betaalmodule betaalmodule en business model vinden en bouwen UC11 UC11: Monitoring Monitoring en analytische rapportering incl fraudedetectie UC12 UC12: Inzichten Rapporting BI Dashboards en Inzichten UC13 UC13: Duurzaamheid Van een piloot tot een 'operationeel' draaiende applicatie en platform UC1 ID Type Samenvatting Beschrijving UC1 Use case UC1: Registratie Registratie BC1.1 Business capability als burger Als burger wil ik mij kunnen registreren en inloggen met authenticatie ifv mijn mandaten BC1.2 Business capability als onderneming Als onderneming wil ik mij kunnen registreren en inloggen met authenticatie ifv mijn mandaten BC1.3 Business capability als vereniging Als vereniging wil ik mij kunnen registreren en inloggen met authenticatie ifv mijn mandaten BC1.4 Business capability als hulpdienst Als hulpdienst wil ik mij kunnen registreren en inloggen met authenticatie ifv mijn mandaten BC1.5 Business capability als stadsambtenaar Als stadsambtenaar wil ik mij kunnen registreren en inloggen met authenticatie ifv mijn mandaten BC1.6 Business capability als systeembeheerder Als systeembeheerder wil ik mij kunnen registreren en inloggen met authenticatie ifv mijn mandaten BC1.7 Business capability als lokale bestuur Als lokaal bestuur wil ik mij kunnen registreren en inloggen met authenticatie ifv mijn mandaten BC1.8 Business capability als overheid Als overheid wil ik mij kunnen registreren en inloggen met authenticatie ifv mijn mandaten BC1.9 Business capability inlog cookies Als gebruiker wil ik mijn inlogdata via cookies kunnen bijhouden zodat ik niet telkens opnieuw alles moet invullen bij het inloggen BC1.10 Business capability mandaten toekennen Als gemandateerde van een instantie wil ik andere personen een mandaat/volmacht kunnen toekennen opdat zij ook de aanvragen kunnen doen (via mandatensysteem VMS bvb) BC1.11 Business capability mandaten aanpassen Als gemandateerde van een instantie wil ik andere mandateerden kunnen verwijderen of statuut (welke rechten heeft ie op dit platform) aanpassen BC1.12 Business capability via centraal registerpunt Als gebruiker wil ik via het ondernemingsloket of via een centraal registerpunt mijn aanvraag kunnen invoeren BC1.13 Business capability rollen in de aanvraag proces Als gebruiker wil ik verschillende rollen voor aanvragen kunnen aanmaken (schrijven, indienen, annuleren, aanpassen) die op hun beurt beheerd kunnen worden (de rollen zelf aanpassen ed meer) BC1.14 Business capability Volmachten andere organisatie Als gebruiker wil ik een volmacht kunnen geven aan andere entiteiten (andere organisatie) BC1.15 Business capability aanvraag voor derden Ik moet mij als bvb ambtenaar kunnen inloggen om voor een andere persoon ook in te dienen BC1.16 Business capability KBO vs Vestigingsnummer Als gebruiker wil ik mijn kunnen identificeren als zowel KBO nummer als Vestigingsnummer in het systeem BC1.17 Business capability overnames Als gebruiker wil ik dat al mijn vergunningen worden overgenomen bij overname van mijn bedrijf BC1.18 Business capability herinneringen voor updates Als systeembeheerder wil ik periodiek (om de 12 maanden ?) herinnering krijgen om te checken of mijn profiel nog klopt BC1.19 Business capability Als gebruiker wil ik n unieke digitale bron voor de toekenning van mijn vergunning BC1.20 Business capability beheer volmachten Als gebruiker wil ik mijn volmachten die ik gegeven gemakkelijk beheren (aanpassen, aanmaken, annuleren, enz.) Aanvullende use cases - Als ondernemer wil ik ontzorgd worden - Als gebruiker wil ik via het ondernemingsloket of via een centraal registerpunt mijn aanvraag kunnen invoeren - Als gebruiker wil ik verschillende rollen voor aanvragen die op hun beurt beheerd kunnen worden - Als gebruiker wil ik een volmacht kunnen geven aan andere entiteiten (andere organisatie) - Als gebruiker wil ik één unieke digitale bron voor de toekenning van mijn vergunning - Als gebruiker wil ik dat vergunningen automatisch toegekend worden Discussie De volgende opmerkingen werden gegeven: - Momenteel moet je aanvinken voor welke entiteiten je vergunningen wil aanvragen - Unieke registratie bij een unieke bron, niet met duplicaten bij de vergunningen, er moet een centraal platform zijn - Volmacht moet gegeven worden aan de entiteiten. Dit zal zeer belangrijk zijn voor de logistiek, maar ook bv. voor PostNL moet het ook gemakkelijk zijn om volmachten te schrappen. - Via ondernemersloket of centraal registerpunt - Verschillende rollen: je hebt iemand nodig voor de registratie, hier moet je ook de link met MAGDA kunnen maken - Je moet een aanvraag kunnen doen voor iemand anders (mandatenregister) - Je hebt één KBO-nummer en verschillende vestigingen (bv hotelketens met verschillende vestigingen in één stad, maar hebben wel aparte vestigingsnummers, en de rechten zitten op KBO-niveau) - Op ondernemingsloket met bekeken worden naar het onderscheid tussen KBO-nummer vs. vestigingsnummer vs. mandaten. - Wat bij firma’s die overgenomen worden, kunnen we dit meenemen? UC2 ID Type Samenvatting Beschrijving UC2 Use case UC2: Informatieplatform informatie platform en zoek opdrachten BC2.1 Business capability Info over specifieke stad Als aanvrager wil ik een overzicht kunnen zien van alle regels en toelatingen/vergunningen die ik nodig heb in een specifieke stad BC2.2 Business capability Overzicht gans of geselecteerde 'Vlaanderen' Als aanvrager wil ik een overzicht kunnen zien van alle regels en toelatingen/vergunningen die van toepassing zijn in alle steden en gemeenten in Vlaanderen, of enkel van geselecteerde bestemmingen op n 'scherm' (overzichtelijk) BC2.3 Business capability formulieren Als aanvrager wil ik via een link de formulieren terugvinden die ik nodig heb voor mijn aanvraag BC2.4 Business capability Customized Informatie Als aanvrager wil ik dat de informatie aangepast wordt ifv mijn hoedanigheid, bvb burger, onderneming, vereniging, hulpdienst, ambtenaar, enz. BC2.5 Business capability strikte minimum Als aanvrager wil ik dat de gevraagde informatie beperkt blijft tot de noodzakelijke ifv mijn hoedanigheid (profiel, locatie, type aanvraag, enz.) BC2.6 Business capability search engine Als aanvrager wil ik de informatie kunnen opzoeken via sleutelwoorden of meest gezochte items BC2.7 Business capability voorbeeld formulieren Als aanvrager wil ik voorbeelden van ingevulde aanvragen kunnen zien BC2.8 Business capability Wizzard als gebruiker wil ik bij het invullen reeds autofill kunnen activeren (of desactiveren) die zou moeten leiden tot de juiste informatie BC2.9 Business capability filter Als gebruiker wil ik bij het zoeken filters kunnen instellen in de rand bvb om de resultaten die ik voor mij krijg te beperken BC2.10 Business capability WCAG normen Als aanvrager die 'slechtziende' is wil ik de informatie op een manier krijgen die voldoet aan de WCAG normen BC2.11 Business capability Andere Applicaties Als derde partij applicaties zoals waze en google maps wil ik die informatie gemakkelijk en gestructureerd kunnen opvragen BC2.12 Business capability vaste hoofdstukken Als gebruiker wens ik vaste hoofdstukken/onderdelen te zien krijgen om mij te informeren: doelgroep, voorwaarden, eigenschappen m.b.t. voertuigen BC2.13 Business capability Internationale bestuurder Als internationale gebruiker wil ik de informatie waar kan ik binnen met welke vergunningen enz ook in mijn taal kunnen terugvinden. BC2.14 Business capability Alternatieven (meertalig) Als (buitenlandse) gebruiker wil ik de alternatieve routes of acties kunnen voorgesteld krijgen indien ik geen vergunning kan verkrijgen Aanvullende use cases - Als gebruiker wens ik vaste hoofdstukken/onderdelen te zien krijgen om mij te informeren: doelgroep, voorwaarden, eigenschappen m.b.t. voertuigen - Als gebruiker wens ik de mogelijkheid te hebben om aan na registratie te doen Discussie - Er moet gecommuniceerd worden met vaste hoofstukken - Ook op doelgroep niveau aanpassen - Er moet een link zijn tussen het platform en andere apps voor bv Waze, Google Maps waardoor informatie-uitwisseling mogelijk is o Opm.: hier bovenop ook een economisch model te bouwen - extra services bovenop zetten, er moet een bereidheid zijn van de bedrijven die momenteel grote kost betalen, potentieel kijken naar Athumi voor implementatie. - Vraag: wat moet ik doen als ik een stad ben binnengereden en heb de registratie niet gedaan? Na registratie doen. - Wizard/filter toevoegen zodat er in de linker kolom een optie bestaat om de informatie behapbaar te maken. - WCAG – moet compliant zijn aan de normen voor slechtzienden etc. UC3 ID Type Samenvatting Beschrijving UC3 Use case UC3: Profiel & Formulier aanvullen Profiel aan- en formulier invullen BC3.1 Business capability download voor later Als aanvrager wil ik het document kunnen downloaden en invullen op mijn gemak BC3.2 Business capability gesaved voor later Als aanvrager wil ik het formulier online invullen, saven, terug openenen, aanvullen, enz. BC3.3 Business capability prefillen Als aanvrager wil ik dat de centraal gekende informatie (bvb DIV, magda, ) velden wordt opgehaald en voorgesteld of 'prefilled' wordt in het formulier BC3.4 Business capability attesten op zelfde pagina gekregen en opgeladen Als aanvrager wil ik dat de nodige attesten direct (op zelfde pagina) kan opgevraagd en toegevoegd worden aan het formulier BC3.5 Business capability manueel ingevuld en gescand opgeladen Als aanvrager wil ik ook een gescande ingevulde formulier kunnen opladen voor indiening BC3.6 Business capability OCR van scans Als systeembeheerder wil ik een gescande ingevulde formulier kunnen 'digitaliseren' via OCR modules en door de aanvrager laten valideren BC3.7 Business capability overschrijven van prefilled Als aanvrager wil ik de 'prefilled' velden kunnen 'overschrijven' met meer correctere informatie, maar dan wel met justificatie argumenten BC3.8 Business capability multi steden of gemeenten Als aanvrager wil ik het 'generieke' aangepaste formulier kunnen invullen met het oog op aanvraag voor verschillende steden of gemeenten (formulier wordt opgesplitst in formulier per stad en gemeente die gekozen werd) BC3.9 Business capability verplichte velden Als aanvrager wil ik steeds kunnen zien welke informatie noodzakelijk zijn die nog niet zijn ingevuld (in het rood bvb) BC3.10 Business capability multi aanvragen Als aanvrager wil ik verschillende formulieren kunnen invullen en bijhouden en bewerken BC3.11 Business capability validatie ingevulde velden Als ambtenaar wil ik een onderscheid kunnen zien welke velden gevalideerd zijn door centrale bronnen en welke werden overgeschreven door de aanvrager BC3.12 Business capability opmerkingen Als aanvrager wil ik bepaalde opmerkingen kunnen toevoegen die ik nodig acht voor de beslissingsproces BC3.13 Business capability extra opladen documenten Als aanvrager wil ik documenten kunnen opladen die ik zelf acht nodig te zijn als argumentatie BC3.14 Business capability copy/paste Als aanvrager wil ik oude ingevulde aanvragen kunnen copieren en plakken tot een nieuwe extra aanvraag BC3.15 Business capability via mijnburgerprofiel Als burger wil ik mijn aanvraag kunnen doen via mijnburgerprofiel (embedded of enkel voor de authenticatie) BC3.16 Business capability via e-loketondernemers Als onderneming wil ik mijn aanvraag kunnen doen via e-loketondernemers (embedded of enkel voor de authenticatie) BC3.17 Business capability via verenigingsloket Als vereniging wil ik mijn aanvraag kunnen doen via verenigingsloket (embedded of enkel voor de authenticatie) BC3.18 Business capability hulpdiensten Als hulpdienst wil ik mijn aanvraag kunnen doen via e-loketondernemers (embedded of enkel voor de authenticatie) BC3.19 Business capability API koppeling met eigen systemen Als aanvrager wil ik eigen beheer- of planningsytemen (bvb logistieke planningstool, of gewoon een excel sheet) kunnen koppelen aan mijn profiel zodat ik niet telkens bvb nummerplaten met datum en lokatie moet invullen bij elke aanvraag BC3.20 Business capability wagen van derden Als aanvrager wil ik ook voor voertuigen van derden een aanvraag kunnen doen bij bvb huur of lease wagen BC3.21 Business capability e-inclusie Als ambtenaar wil ik een aanvraag kunnen voor een aanvrager die niet op de website geraakt, maar die wel naast mij staat BC3.22 Business capability indienen enkel door gemandateerd Als bestuurder bvb wil ik dat mijn 'medewerker' de aanvragen invult en enkel ik kan valideren en indienen BC3.23 Business capability onderaannemer Als gebruiker wil ik een aanvraag kunnen doen voor mijn onderaannemer BC3.24 Business capability herbruikbare oude aanvraag Als gebruiker wil ik de formulier van een 'oude' aanvraag kunnen hergebruiken om een nieuwe aanvraag te starten BC3.25 Business capability buitenlandse gebruiker Als buitenlandse gebruiker wil ik de formulier in verschillende talen kunnen invullen BC3.26 Business capability een (virtuele) helpdesk bij invulling Als gebruiker wens ik een helpdesk om mij te ondersteunen bij het invoeren/invullen van mijn aanvraag Aanvullende use cases - Als lokale overheid wil ik aanvragen kunnen doen voor mijn burgers (loketfunctie) - Als gebruiker wens ik mijn profiel te kunnen definiëren - Als beheerder wens ik dat het platform, op regelmatige basis, een automatische check doet van alle parameters van de vergunninghouders zodat deze automatisch kunnen verlengd/verwijderd worden Discussie - Wat is de impact op bestaande vergunningen? idee: je verhuist, wat is de impact op mijn bestaande vergunningen. o Andere optimalisatieslagen voor aanvragers; trigger geven “let op: die firma moet ook - Up-to-date houden van profielen/ vernieuwen van informatie - Soms zijn er grootgebruikers gelinkt aan 1 profiel, wat hiermee? o Mandatensysteem van Vlaanderen koppelen o Loketfunctie? o API-wagenpark - Burger met loket, is er een specifiek profiel? We moeten dubbels vermijden. UC4 ID Type Samenvatting Beschrijving UC4 Use case UC4: Indiening Indienen aanvraag BC4.1 Business capability officieel 'indienen' Als aanvrager wil ik het ingevuld formulier kunnen 'indienen' via een 'indien' knop BC4.2 Business capability doorsturen naar derden Als aanvrager wil ik een ingevuld formulier kunnen emailen/opsturen naar een centraal email/adres (of via API) BC4.3 Business capability verplichte velden Als aanvrager wil ik bij het niet correct ingevuld formulier direct een 'weigering' van indiening kunnen zien met voorstel van 'correcties' (welke velden waren verplicht) BC4.4 Business capability bevestiging aanvraag Als aanvrager wil ik een bevestigingscode (=dossier nummer) en email krijgen met informatie over de volgende stappen BC4.5 Business capability retro actieve na-registratie Als aanvrager wil ik, indien het proces dit toelaat, ook naregistratie kunnen doen, dus wanneer ik zonder vergunning ben binnengereden wil ik nog binnen de x uren mezelf kunnen registreren en aanvraag indien retro actief. BC4.6 Business capability Belgische Talen Als gebruiker wens ik een meertalig platform (minstens Nederlands, Frans en Duits) BC4.7 Business capability happy flow garanties Als gebruiker wens ik dat er een happy flow ge mplementeerd wordt BC4.8 Business capability een (virtuele) helpdesk bij indiening Als gebruiker wens ik een helpdesk om mij te ondersteunen bij het indiening van mijn aanvraag BC4.9 Business capability meertalige bevestiging van de indiening Als gebruiker wens ik een gestandaardiseerde meertalige mail te ontvangen na de indiening BC4.10 Business capability buitenlandse logistiek dienstverlener Als buitenlandse logistieke dienstverlener wens ik een aanvraag te kunnen doen voor een levering BC4.11 Business capability CAPTCHA Als beheerder wens ik een CAPTCHA ter controle BC4.12 Business capability bewijsstelling aan de aanvrager Als beheerder wens ik dat de aanvrager kan bewijzen dat hij/zij een bedrijf vertegenwoordigt en op locatie x moet zijn BC4.13 Business capability contractors en onderaannemers Als gebruiker die met contractors of subcontractors werkt, wens ik voor hen een aangepaste oplossing Aanvullende use cases - Als gebruiker wens ik een meertalig platform (minstens Nederlands, Frans en Duits) - Als gebruiker wens ik dat er een ‘happy flow’ geïmplementeerd wordt - Als gebruiker wens ik een helpdesk om mij te ondersteunen bij het invoeren/de opvolging van mijn aanvraag - Als gebruiker wens ik een gestandaardiseerde mail te ontvangen - Als buitenlandse logistieke dienstverlener wens ik een aanvraag te kunnen doen voor een levering - Als beheerder wens ik een CAPTCHA ter controle - Als beheerder wens ik dat de aanvrager kan bewijzen dat hij/zij een bedrijf vertegenwoordigt en op locatie x moet zijn - Als gebruiker die met contractors of subcontractors werkt, wens ik voor hen een aangepaste oplossing - Als beheerder verkies ik een digitale flow en wens ik deze te stimuleren - Als beheerder wens ik buitenlandse bezoekers te informeren waar ze hun voertuig kwijt kunnen Discussie - Voor buitenlandse entiteiten ben je vaak heel laks of heel streng op vlak van data - Als je niet binnen mag, dat je dan ook geholpen wordt waar je dan wel mag staan. - In het platform niet bezighouden met de handhaving - Handhaving: hoe verloopt de controle van de aanvragen momenteel? Te goeder trouw? Als je per levering een bestelbon moet indienen wordt de administratieve last hoog. Hoe strikt en hoeveel bewijslast? o Gent: als bewoner kan je oneindig aanvragen indienen in functie van de (verwachte) nood - Na registratie: conditie op plaatsen in de tijd (maximum aantal dagen in het verleden of een datum in de toekomst) -> die regels moeten gestructureerd worden o Als lokale overheid ga je een soort configuratietool hebben waar je dan de parameters kan bepalen, hier zullen we een 80-20 manier gaan incorporeren - Taal aanvragen: goede dienstverlening in verschillende talen - Het is belangrijk dat buitenlandse bezoekers in acht genomen worden UC5 ID Type Samenvatting Beschrijving UC5 Use case UC5: Opvolging dossier opvolging dossier BC5.1 Business capability dossier status opvraging Als aanvrager wil ik de status kunnen zien van mijn aanvraag dossier, alsook wat de volgende statussen kunnen zijn BC5.2 Business capability notificaties status verandering Als aanvrager wil ik via email bvb een bericht krijgen bij het veranderen van de status met evt argumentatie BC5.3 Business capability status opvraging en aanpassing Als ambtenaar wil ik de status kunnen opvragen en evt manueel aanpassen BC5.4 Business capability advies bij weigering Als aanvrager wil ik bij een weigering de motivering kunnen zien zodat ik de aanvraag evt kan aanpassen en terug indienen BC5.5 Business capability last minute aanpassingen Als aanvrager wil ik aanpassingen kunnen doen in het proces ifv de huidige status (bvb invullen van nummerplaat indien nog niet gekend, bedrijfsvorm van bv tot NV bvb, enz.) BC5.6 Business capability betwisten weigering Als aanvrager wil ik de weigering kunnen betwisten BC5.7 Business capability herinnering notificatie Als aanvrager wil ik een notificatie kunnen krijgen als herinnering om een aanvraag opnieuw in te dienen of te verlengen BC5.8 Business capability annulatie Als aanvrager wil ik een aanvraag kunnen annuleren en opnieuw later indienen BC5.9 Business capability via mijnburgerprofiel Als burger wil ik mijn aanvragen kunnen opvolgen, aanpassen, betwisten en notificaties krijgen via mijnburgerprofiel BC5.10 Business capability e-ondernemingsloket Als onderneming wil ik mijn aanvragen kunnen opvolgen, aanpassen, betwisten en notificaties krijgen via e-loketondernemers BC5.11 Business capability verenigingsloket Als vereniging wil ik mijn aanvragen kunnen opvolgen, aanpassen, betwisten en notificaties krijgen via verenigingsloket BC5.12 Business capability hulpdiensten Als hulpdienst wil ik mijn aanvragen kunnen opvolgen, aanpassen, betwisten en notificaties krijgen via e-loketondernemers BC5.13 Business capability toevoeging nummerplaat Als aanvrager wil ik bij een goedgekeurde vergunning de uiteindelijke nummerplaat kunnen toevoegen die uiteindelijk zal gebruikt worden bij bvb verhuis of transport van meubelen ed meer, waar ik vergunning krijg nog voordat ik de exacte wagen nummerplaat ken. BC5.14 Business capability opzoeking dossier Als aanvrager wil ik mijn dossiers kunnen opzoeken en selecteren ifv criteria bvb op nummerplaat, stad of gemeente, type van wagen, type van vergunningsaanvraag, enz. BC5.15 Business capability herbruikbaarheid aanvraag Als gebruiker wil ik een nieuwe aanvraag kunnen starten/indienen op basis van een voorgaande aanvraag BC5.16 Business capability hoe lang nog volgende stap ? Als gebruiker wens ik informatie te ontvangen over hoe lang je moet wachten voor een goedkeuring/status update van je aanvraag Aanvullende use cases - Als gebruiker wens ik informatie te ontvangen over hoe lang je moet wachten voor een goedkeuring/update van je aanvraag - Als gebruiker wens ik een motivering te ontvangen waarom mijn aanvraag geweigerd is - Als gebruiker wil ik een nieuwe aanvraag kunnen starten/indienen op basis van een voorgaande aanvraag Discussie / UC6 ID Type Samenvatting Beschrijving UC6 Use case UC6: toekenningsproces toekenning, weigering, betwisting, advies aanvraag BC6.1 Business capability beslissingsbomen Als lokaal bestuur wil ik de beslissingsbomen kunnen invoeren, visualiseren en aanpassen BC6.2 Business capability automatisch toekenning of weigering Als systeembeheerder wil ik de aanvragen automatisch door de beslissingsboom laten draaien om automatisch toe te kennen, te weigeren of door te sturen naar ambtenaar BC6.3 Business capability manuele toekenning Als ambtenaar wil ik een aanvraag manueel kunnen toekennen BC6.4 Business capability weigering met advies Als ambtenaar wil ik een aanvraag kunnen weigeren met commentaar, justificaties of advies over de weigering BC6.5 Business capability betwisten van weigering Als aanvrager wil ik de weigering kunnen betwisten binnen een bepaalde periode BC6.6 Business capability betwisting opstarten Als ambtenaar wil ik de betwiste aanvraag kunnen heropstarten BC6.7 Business capability voor advies vragen Als ambtenaar wil ik een aanvraag voor advies naar een andere instantie kunnen sturen BC6.8 Business capability statistieken beslissingen Als lokaal bestuur en overheid wil ik statistieken kunnen draaien ivm toekenning en weigering (wie, wat, hoeveel, hoe lang, waarom, enz.) BC6.9 Business capability rechten en plichten communiceren Als lokaal bestuur wil ik met de toekenning een overzicht kunnen sturen met de rechten en plichten die gepaard gaan met de toekenning BC6.10 Business capability Triggers voor verandering Als lokaal bestuur wil ik indien er iets verandert, bvb verhuis, dat de vergunning automatisch wordt aangepast BC6.11 Business capability alternatieven na weigering Als aanvrager wil ik, bij weigering van mijn aanvraag, alternatieve routes of acties die ik kan nemen, indien die er zijn. BC6.12 Business capability automatische regelmatige checks Als beheerder wens ik dat het platform, op regelmatige basis, een automatische check doet van alle parameters van de vergunninghouders zodat deze automatisch kunnen verlengd/verwijderd worden BC6.13 Business capability screening situatie Als ambtenaar wil ik dat bij verandering van de situatie de vergunning automatisch/manueel wordt toegekend of geanulleerd/ingetrokken/tijdelijk geschorst en krijgt de aanvrager die notificaties (bvb bedrijf failliet, garage wordt niet meer door aanvrager gehuurd, ) Aanvullende use cases - Als gebruiker wens ik het front office aspect kunnen ingeven en een weigering/goedkeuring ontvangen - Als gebruiker wens ik een aanvraag kunnen doen voor mijn onderaannemer - Als gebruiker wens ik een back-end functionaliteit waarin je lokale besturen de mogelijkheid geeft om te linken met het systeem Discussie - Tot op welk niveau is de beslissing geautomatiseerd? - Wat met een voertuig/persoon die niet afkomstig is uit Vlaanderen/internationaal. Hoe ga je handhaven? Controleren? - Het is belangrijk om een onderscheid te maken tussen a) Het beheren van wie mag wat b) De handhaving achteraf - Er is een belangrijk 2 de luik binnen dit project, nl de speciale gebieden in kaart brengen UC7 ID Type Samenvatting Beschrijving UC7 Use case UC7: dossierbeheer beheer dossier (overzicht, toevoegingen, verlengingen, aanpassingen, herinneringen, …) BC7.1 Business capability overzicht alle interacties Als aanvrager wil ik een overzicht krijgen van mijn toegekende of geweigerde vergunningen, die ik kan downloaden, uitprinten en doorsturen naar andere email adressen, mijn ebox en in 'my wallet' BC7.2 Business capability aanpassing dossiers Als aanvrager wil ik bestaande dossiers kunnen aanpassen en terug indienen BC7.3 Business capability snelle verlenging aanvraag Als aanvrager wil ik toegekende vergunningen kunnen verlengen via een aparte verkorte proces BC7.4 Business capability herinnering verloop Als aanvrager wil ik herinneringen krijgen wanneer mijn vergunningen verlopen BC7.5 Business capability herinnering met link Als aanvrager wil ik in mijn herinneringsnotificaties een link staat waarin ik met een druk op een knop de verlengingsaanvraag kan gebeuren. BC7.6 Business capability status dossier update Als systeembeheerder wil ik dat de 'status' nodig voor mijn dossiers automatisch geupdate worden waarbij de regels opnieuw worden 'berekend' BC7.7 Business capability lijst bijna verlopen vergunningen Als aanvrager wil ik overzicht krijgen van alle toegekende vergunningen die binnen x maanden zullen verlopen BC7.8 Business capability forward toekenning Als aanvrager wil ik mijn dossier kunnen delen met andere email adressen (of gemandateerde personen) BC7.9 Business capability automatische verlenging Als systeembeheerder wil ik bepaalde vergunningen automatisch kunnen verlengen en notificeren naar de aanvrager Aanvullende use cases - Als beheerder wens ik een verdienmodel uit te bouwen voor het platform - Als beheerder wens ik data spaces per aanvraag per transactie - Als gebruiker wens ik meldingen te ontvangen voor vergunningen die komen te verlopen Discussie - Aandacht voor GDPR! Persoonsdata moeten verborgen worden - Aandacht voor cybersecurity UC8 ID Type Samenvatting Beschrijving UC8 Use case UC8: Message Center CRM voor communicatie (uitgaande/inkomende, contact strategie en historiek) BC8.1 Business capability Campaign automation Als lokaal bestuur wil ik een strategie via regels kunnen invoeren in het CRM om de communicatie (bevestigingen, herinneringen, generieke informatie,…) naar de aanvragers en dossierbeheerders kunnen uittekenen BC8.2 Business capability contact dossier beheerder Als aanvrager wil ik berichten kunnen sturen naar de huidige dossierbeheerder ivm mijn aanvraag of dossier BC8.3 Business capability contact aanvrager Als ambtenaar wil ik berichten kunnen sturen naar de aanvrager BC8.4 Business capability contact historiek Als aanvrager en ambtenaar wil ik een overzicht krijgen van alle contact historiek mbt aanvragen of specifieke onderwerpen BC8.5 Business capability communicatievoorkeuren Als aanvrager wil ik mijn communicatievoorkeuren kunnen instellen BC8.6 Business capability optin/optout Als aanvrager wil ik mijn optin en optout kunnen instellen op elk ogenblik BC8.7 Business capability DPO overzicht Als DPO wil ik een overzicht krijgen van alle bijgehouden contact informatie van de aanvragers BC8.8 Business capability email forwarding Als aanvrager wil ik mijn dossiers of vergunningen kunnen doorsturen naar andere email adressen BC8.9 Business capability GDPR Als systeembeheerder wil ik dat alle informatie die wordt bijgehouden de GDPR wetgeving volgen BC8.10 Business capability informatie communicatie Als lokaal bestuur wil ik een communicatie kunnen sturen die betrekking hebben op de vergunningen, bvb veranderde geografische zones, extra uitzonderingen, werken, evenementen, ed meer BC8.11 Business capability vertalingen via applicatie Als lokaal bestuur wil ik mijn communicaties ook in andere talen uitsturen door bvb google translate knopje in de communicatie te steken zodat de lezer zelf de vertaling snel en gemakkelijk kan opstarten Aanvullende use cases - Als aanvrager kan ik aangeven of ik communicatie wil ontvangen enkel via het platform en/of via lokale overheid - Als gebruiker wens ik communicatievoorkeuren per stad en/of type vergunning apart kunnen bepalen Discussie - CRM is heel breed! Hoort dit hier wel thuis? o Communicatiekanaal: hoe iemand contacteren? o Dit moet onderzocht worden: een standaard functionaliteit van ondernemers of burgerloket? UC9 ID Type Samenvatting Beschrijving UC9 Use case UC9: Helpdesk helpdesk & FAQ & Reviews BC9.1 Business capability helpdesk 24/7 Als aanvrager wil ik een contact helpdesk kunnen contacteren (via mail, chat, telefoon, brief, whatsup, enz.) bij issues BC9.2 Business capability FAQ Als ambtenaar wil ik een FAQ kunnen publiceren ifv de inkomende vragen en opmerkingen BC9.3 Business capability Overview inbound Als lokaal bestuur wil ik een overzicht kunnen zien van alle opmerkingen, vragen, klachten, reviews enz. Ivm het proces, de tool, de dossierbeheerder, enz. BC9.4 Business capability Review knop Als aanvrager wil ik een 'review' knop hebben mbt mijn ervaring BC9.5 Business capability Chatbot Als aanvrager wil ik mijn vraag aan een 'chatbot' kunnen stellen Aanvullende use cases - Als lokaal bestuur wil ik in het dashboard kunnen zien hoeveel vergunningen pending zijn - Als gebruiker wil ik op het platform kunnen zien bij welke contactpersoon ik terecht kan om informatie te bekomen rond mijn aanvraag (per regio) Discussie - Wat als je een boete/retributie krijgt terwijl je een vergunning had? o Procedures bij (dezelfde?) ambtenaar - Helpdesk kan ook soort communicatie zijn tussen ambtenaar en aanvrager o De juiste antwoorden voor de vraag - Als je een toelating krijgt, krijg je dat ook in elektronische vorm om te bewijzen. - Is dit een helpdesk voor het platform of voor de vergunningen? o Is die helpdesk een ambtenaar of kan je naar die helpdesk bellen als ambtenaar? UC10 ID Type Samenvatting Beschrijving UC10 Use case UC10: betaalmodule betaalmodule en business model vinden en bouwen BC10.1 Business capability betalend of gratis Als lokaal bestuur wil ik bepaalde aanvragen (dringende bvb) betalend maken BC10.2 Business capability betalingen in de tool Als aanvrager wil ik de betaling bij de aanvraag kunnen doen met bevestiging van betaling BC10.3 Business capability terugbetalingen Als ambtenaar wil ik een betaling kunnen 'terugdraaien' indien nodig BC10.4 Business capability overschrijving of cash Als aanvrager wil ik een betaling ook via overschrijving of contant kunnen doen waarbij ik mijn betalingsbewijs gescand kan opladen BC10.5 Business capability met factuur Als aanvrager wil ik een fiscaal correcte factuur kunnen opvragen voor de boekhouding BC10.6 Business capability n betaling meerdere aanvragen Als aanvrager wil ik voor veschillende aanvragingen nmalig kunnen betalen BC10.7 Business capability pre of postpaid Als lokaal bestuur wil ik de betaling conditioneel maken voor de toekenning of na de toekenning maar voor de bevestiging of na de bevestiging BC10.8 Business capability business model Als systeem owner wil ik een model kunnen vinden en bouwen om bvb bedrijven die enorme tijdswinsten maken te laten betalen om zo de kosten van die ontwikkeling mee te financieren. Aanvullende use cases - Als lokaal bestuur wens ik een centraal platform voor de betalingen dat de vergoedingen automatisch doorstuurt naar de juiste stad/gemeente waarvoor de aanvraag werd ingediend - Als gebruiker wens ik online te betalen voor mijn vergunning - Als beheerder wens ik overschrijvingen of contante betalingen af te raden en maximaal in te zetten op online betalingen Discussie - Idealiter wordt alles vooraf geregeld zoals bij een Zwitsers vignet - Periodieke toegang voor langere periode UC11 ID Type Samenvatting Beschrijving UC11 Use case UC11: Monitoring Monitoring en analytische rapportering incl fraudedetectie BC11.1 Business capability realtime activiteiten Als systeembeheerder wil ik een realtime overzicht kunnen krijgen van wie ingelogd is met elke acties die gevoerd werden op het systeem BC11.2 Business capability via welk portaal Als systeembeheerder wil ik kunnen zien via welke portaal de gebruikers ingelogd zijn BC11.3 Business capability antwoordtijden Als systeembeheerder wil ik de antwoordtijden kunnen zien van alle acties BC11.4 Business capability downtime Als systeembeheerder wil ik de 'down' tijd kunnen monitoren en rapporteren BC11.5 Business capability aanvragen/beslissingen Als lokaal bestuur wil ik het aantal aanvragen en beslissingen kunnen rapporteren BC11.6 Business capability fraude detectie Als lokaal bestuur wil ik 'onregelmatigheden' kunnen ontdekken die zou kunnen duiden op fraude BC11.7 Business capability SLA Als systeembeheerder wil ik KPI's kunnen stellen die de Kwaliteit van de Dienstverlening voorstelt BC11.8 Business capability API Load Als systeembeheerder wil ik API load op de externe systemen willen kunnen zien Aanvullende use cases - Als gebruiker wens ik dat het platform laadt op externe API’s - Als lokale overheid kan ik issues/bugs melden aan de systeembeheerder - Als aanvrager kan ik problemen melden aan de systeembeheerder en feedback ontvangen - Als beheerder wens ik een automatische detectie van meerdere identieke aanvragen - Als ondernemer wil ik zien welke voertuigen affectief gebruik maken van een vergunning - Als beheerder wens ik een melding te ontvangen bij analomieën bij aanvragen, bijvoorbeeld een profiel dat fouten bevat Discussie - KPI’s, SLA’s: mee rekening houden UC12 ID Type Samenvatting Beschrijving UC12 Use case UC12: Inzichten Rapporting BI Dashboards en Inzichten BC12.1 Business capability Aanvraag profielen Als lokaal bestuur wil ik begrijpen wie zijn de personen die een aanvraag indienen, hoe is de trend ervan, enz. Reeds gedefinieerde use cases / Aanvullende use cases - Als lokaal bestuur wil ik weten hoeveel aanvragen binnenkomen via de website en hoeveel via het platform - Als lokaal bestuur met beperkte backoffice wens ik een standaardpakket data outcome dat eenvoudig leesbaar is Discussie - Wat met security? Mag die info gedeeld worden? - Mijn profiel bijhouden & GDPR? o Indien de data bij Vlaanderen zit, is dit ok qua GDPR - Welke lokale besturen hebben vergunningen? Hoeveel worden er aangevraagd? Door wie? - Digitaal parkeren o Geeft weinig output rond verkeersinformatie o Belangrijk om te beslissen welke data je bijhoudt - Aanvragen geweigerd en waarom - Cfr Nederland: Centraal parkeer register o Centraal platform en governance is nog een andere stap - Partnerships & professionele weggebruikers vs. segment dat eenmalig gebruikt o Nieuwe spelers betrekken - Light dashboard voorzien voor kleinere lokale besturen - Wat met steden en gemeenten zonder backoffice? o Hoe breng je dit samen? o Welke data willen we aanleveren en lukt dat voor elk lokaal bestuur ifv technologie? - Wat met internationale aanvragen? - Handhaving als aparte use case? Zijn er bruggetjes en indien ja dewelke? o Het is interessant om uitwisseling van data voor whitelisting mee in de OSLO- standaard opnemen. Whitelisten betekent dat je op een witte lijst komt opdat je de vergunning hebt om in die zonde te passeren. o Zal dit gesynchroniseerd worden met de ANPR-camera’s? - Zal governance een aparte use case zijn? o Ja, binnen het financieel model zal de algemene governance opgenomen worden, zowel als de aansprakelijkheid binnen het platformen een overzicht bij wie je terecht kan. UC13 ID Type Samenvatting Beschrijving UC13 Use case UC13: Duurzaamheid Van een piloot tot een 'operationeel' draaiende applicatie en platform BC13.1 Business capability intake proces Als systeembeheerder wil ik andere steden en gemeenten gemakkelijk kunnen toevoegen op het platform BC13.2 Business capability kostenplaatje Als systeem owner wil ik een goede overzicht hebben van de kosten van het opstarten en beheer van een integratie van een stad of gemeente zodat ik die eventueel kan laten betalen aan de stad of gemeente BC13.3 Business capability Brussel ? Wallonie ? Als beleid wil ik eventueel ook steden en gemeenten toevoegen die niet tot de Vlaamse regio behoren BC11.4 Business capability economisch model : externe partijen Als systeem owner wil ik de externe partijen die onze data gebruiken kunnen laten betalen voor het gebruik ervan BC11.5 Business capability juridische aansprakelijkheid Als systeem owner wil ik een duidelijke juridische afbakening van wie is er bvb verantwoordelijk bij bugs in het systeem BC11.6 Business capability link met handhaving Als systeem owner wil ik een API of via lijsten op FTP bvb zo een link met handhaving kunnen opstellen Volgende stappen Wat na deze werkgroep? Verwerking van de input van de brainstorm oefening. Verder onderzoek en voorbereiding van de eerste 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-02-27 13u-16u VAC Antwerpen Thematische werkgroep 1 Data en informatie werkgroep 2024-03-28 13u-16u Teams Thematische werkgroep 2 Functionele werkgroep 2024-05-16 13u-16u Teams Thematische werkgroep 3 Technologie werkgroep 2024-06-25 13u-16u Teams +
Business werkgroep VlocaTraject/Modderstro … Business werkgroep VlocaTraject/Modderstroom Monitoring Tijdens de eerste sessie, de “business werkgroep”, duiken we in de use cases. Eerder werden er al een aantal use-cases geformuleerd door het kernteam. Deze werden verwerkt in het VLOCA-model. Het doel van deze sessie is om de use-cases te valideren, eventueel bijkomende use-cases te formuleren en de scope van het project af te bakenen. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen. De business werkgroep vond plaats op 29 februari 2024. Context Initiatief VERA werkt samen met verschillende lokale besturen en de provincie Vlaams-Brabant om het probleem van modderstromen als gevolg van bodemerosie aan te pakken. Meer dan 100 gemeenten in Vlaanderen ondervinden bodemerosie, wat aanzienlijke schade kan veroorzaken aan zowel private eigendommen als publieke infrastructuur. Door klimaatverandering, trends in de landbouw en verharding zal dit probleem naar verwachting in de toekomst verder versterkt worden.Op dit moment worden erosiepoelen gebruikt als oplossing. Deze poelen worden onderaan de helling aangelegd om modderstromen op te vangen en te voorkomen dat ze schade veroorzaken. Deze erosiepoelen zijn uitgerust met sensoren en overlopen, waardoor het water op een gecontroleerde en langzame manier kan wegstromen.De vraag die zich stelt, is of deze erosiepoelen effectief zijn. Er bestaat onzekerheid over hun capaciteit en functionaliteit, vooral in noodsituaties. Het is essentieel om dit op een kostenefficiënte manier te monitoren, met als doel zowel acute waarschuwingen bij rampen als proactieve oplossingen voor het probleem.Er wordt nagedacht over het gebruik van peilmeters of debietsensoren om de erosiepoelen te monitoren. Hiermee kan worden bijgehouden hoeveel water door de overlopen gaat. Hoewel dit geen exacte voorspellingen oplevert, biedt het wel inzicht in de hoeveelheid neerslag.Het overkoepelende doel van het project is om een gecentraliseerd dataplatform op te zetten en een raamcontract te ontwikkelen voor de sensoren. De verzamelde data kunnen gedeeld worden met rioolbeheerders, landbouwers en verzekeringsmaatschappijen, omdat deze informatie waardevol kan zijn voor alle betrokken partijen. VLOCA VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders. OSLO Het doel van OSLO is om de datastromen semantisch te modelleren en de structuur van de data te standaardiseren in de context van lokale economie. Hierbij zal de focus gelegd worden op het verbeteren van de gegevensuitwisseling tussen lokale handelaars, horeca ondernemers en beleidsmakers. Met OSLO wordt er concreet ingezet op semantische en technische interoperabiliteit. De vocabularia en applicatieprofielen worden ontwikkeld in co-creatie met o.a. Vlaamse administraties, lokale besturen, federale partners, academici, de Europese Commissie en private partners (ondertussen meer dan 4000 bijdragers). Extra informatie en een verzameling van de datastandaarden zijn te vinden op volgende links: https://overheid.vlaanderen.be/oslo-wat-is-oslo en https://data.vlaanderen.be/ Brainstormsessie Het doel en de aanpak van de brainstormsessie worden hieronder beschreven. Tevens wordt de uitkomst van de brainstorm hierin samengevat. Doel van de brainstormsessie Het doel van de brainstormsessie is het volgende: De missie, visie en doelstellingen van het project, zoals geformuleerd in het VLOCA-model, valideren en feedback capteren De use cases, zoals geformuleerd in het VLOCA-model, valideren en feedback capteren Missie, visie en doelstellingen Missie Wat willen we bereiken? “We willen bodemerosie en de bestrijdingsmaatregelen, meer specifiek erosiepoelen, duurzaam en slim gaan opvolgen, evalueren, verbeteren/slimmer maken, en hier nauwkeurigere voorspellingen over maken. De monitoring moet de verantwoordelijke diensten alarmeren om over te gaan tot (proactieve) ingrepen om modderstromen te voorkomen en/of verder in te perken.” Discussie De volgende opmerkingen werden gegeven: - Tussen duurzaam en slim, ook nog betaalbaar toevoegen. Je kan dit oplossen met bestaande middelen, maar dan zit je tussen de 30 en 60 duizend euro per poel en dat is ook niet de bedoeling. - Naast alarmeren ook ‘best practices’ meegeven om preventief te kunnen evalueren, en ook om toekomstige poelen te kunnen dimensioneren. - Het woord ‘evalueren’ moet verder uitgedacht worden tijdens de use cases en ‘verbeteren/slimmer maken’ moet toegevoegd worden want we willen de erosiepoelen verbeteren. - Dit is niet louter een haalbaarheidsstudie, er zijn namelijk verschillende zaken. Om te beginnen doorlopen we een VLOCA- en OSLO-traject. Vervolgens wordt bekeken om een Proof of concept op te zetten om de juiste sensoren te selecteren. Daarna wensen we een raamovereenkomst uit te schrijven om een aantal poelen te kunnen testen. - We willen de capaciteit van de bekkens/poelen monitoren en daarvan gedurende een bepaalde periode contextuele data verzamelen om de impact op de modderstromen te bepalen. Het gedeelte van de data-analyse wensen wij niet op te nemen. Hiervoor beschikken we niet over de nodige kennis. Volgende vragen werden gesteld: - Willen jullie de meterstand van de poelen en de diepte van de poelen meten? Antwoord : Ja, maar via een metingssysteem zouden we ook voorspellingen kunnen doen om meer proactief acties te ondernemen. Er moeten ook verschillende parameters in acht genomen worden zoals gewassen/hellingsgraad/regenval etc. Visie Wat is de bestaansreden? “Meer dan 100 gemeenten in Vlaanderen hebben vaak last van water- en modderoverlast bij hevige regenval ten gevolge van bodemerosie. Deze modderstromen kunnen met een hoge snelheid (tot zelfs 80 km/u) de lager gelegen (woon)gebieden bereiken. De modder richt schade aan straten, woningen, waterlopen, rioleringen en waterzuiveringsinstallaties. Door klimaatwijziging zal, zonder voldoende maatregelen, de modderoverlast in de toekomst alleen nog maar verergeren.” Discussie Volgende opmerkingen werden gegeven: - Aanpassen aan visie: “Door erosie verdwijnt vruchtbare bodemgrond en de modder richt schade aan de straat”. - De focus van de visie mag niet enkel op het inperken van erosie ter bescherming van woningen liggen, maar ook op “landbouwgronden”. o De bestaansreden van een erosiepoel is namelijk om de vruchtbare grond terug op de akker te krijgen. Vaak is die poel gevuld met zeer vruchtbare grond, maar kan deze niet terug op de akker gevoerd worden want die akker ligt vol met teelt. Er moet onderzocht worden waar die modder naartoe kan gebracht worden voor optimaal en duurzaam hergebruik. Hiervoor moet nog verder worden nagedacht over een brongerichte aanpak vs. symptoomgerichte aanpak. De focus ligt nu op de laatste optie, maar er wordt nog niet voldoende gedaan om die opgevangen modder optimaal te kunnen hergebruiken. Doelstellingen Wat is het doel van het project? “Een monitoring architectuur ontwikkelen die via sensoren en andere databronnen inzichten geeft om proactief schade te beperken, die snelle alarmsignalen kan uitsturen op tijd om nog acties te kunnen treffen en die na de feiten de modellen en inzichten telkens blijven verbeteren.” Discussie Geen opmerkingen Use cases ID Samenvatting Beschrijving UC1 UC1: Sensoren Verschillende actoren willen verschillende types sensoren kunnen plaatsen en beheren (bv. onderhoudsplan). UC2 UC2: Data Captatie Ik wil als gebruiker alle informatie correct binnenkrijgen (context, data, goede transmissie) UC3 UC3: Dataplatform Ik wil als gebruiker een visualisatie zien van alle data zodat ik deze kan analyseren.Ik wil als gebruiker data kunnen toevoegen, aanpassen, delen en opslaan. UC4 UC4: Dashboarding Ik wil als gebruiker een dashboard kunnen hanteren met KPI's (bv kleurencodes) die ik zelf kan beheren in functie van de data. UC5 UC5: Message Center Ik wil als gebruiker via mijn tool contacten kunnen aanspreken, toevoegen, wijzigen en behandelen (messaging systeem). UC6 UC6: Predictie Op basis van de verworven data wil ik modellen kunnen gebruiken om predicties uit te voeren zodat er tactisch advies gegeven kan worden. UC7 UC7: Mitigatie Op basis van real time data en advies wil ik als lokaal bestuur kunnen reageren om de schade te minimaliseren (crisis management). UC8 UC8: Preventie Als lokaal bestuur wil ik een overzicht krijgen van adviezen, acties en aanbevelingen om modderstromen te vermijden. UC9 UC9: Advies Op basis van data van modderstromen wil ik dit kunnen analyseren, correlaties zien en advies verlenen. UC10 UC10: Marktplaats ik wil als gebruiker data en datasciencemodellen kunnen aanbieden en verkrijgen. UC11 UC11: ROI Business Modelling UC12 UC12: Helpdesk Helpdesk - FAQ - Reviews Use case 1 ID Type Samenvatting Beschrijving UC1 Use case UC1: Sensoren Verschillende actoren willen verschillende types sensoren kunnen plaatsen en beheren (bv. onderhoudsplan). BC1.1 Business capability peilhoogte (3D?) Als terreintechnieker wil ik weten waar en hoe ik de peilhoogte sediment meters (sensoren of camera's) moet plaatsen BC1.2 Business capability bodemvocht Als terreintechnieker wil ik weten waar en hoe ik de bodemvochtsensoren moet plaatsen BC1.3 Business capability pluviometers Als terreintechnieker wil ik weten waar en hoe ik de pluviometers moet plaatsen BC1.4 Business capability scenario's Als lokaal bestuur wil ik weten welke sensoren mogelijk zijn met welk budget en voor welke situatie (alle scenario's) BC1.5 Business capability calibratie Als terreintechnieker wil ik weten hoe ik de sensor moet calibreren BC1.6 Business capability continuiteit ook na vervanging Als terreintechnieker wil ik data continuiteit kunnen garanderen bij het vervangen van verouderde sensoren door nieuwe sensoren BC1.7 Business capability zonnepanelen Als terreinbeheerder heb ik meestal geen stroomvoorziening voor sensoren en heb ik dus een oplossing met zonnepanelen nodig BC1.8 Business capability Debietmeter Als product owner wil ik weten waar en hoe ik een 'debietmeter' moet plaatsen BC1.9 Business capability Turbiditeitsmeter Als product owner wil ik weten waar en hoe ik een 'turbiditeitsmeter' moet plaatsen BC1.10 Business capability batterij status Als product owner wil ik de status van de batterij ook meekrijgen om zo snel te kunnen ingrijpen bij legelopen batterij BC1.11 Business capability plaatsing sensoren Als landbouwer wil ik dat de sensoren niet in de weg staan van mijn grond BC1.12 Business capability raamcontract Als lokaal bestuur wil ik een raamcontract kunnen uitkiezen waarbij ik het beheer van de sensoren volledig kan uitbesteden BC1.13 Business capability vandalisme Als lokaal bestuur wil ik vandalisme, van de sensoren, batterijen en zonnepanelen bvb, kunnen rapporteren, beschrijven en bestrijden BC1.14 Business capability dynamische frekwentie Als lokaal bestuur wil ik de frekwentie dynamisch maken (laag bij droog weer, hoog bij regen bvb) zodat de batterij kan gespaard worden en dus langer meekan, maw een kleinere batterij zou dan voldoende zijn bvb Aanvullende use cases: - Als terreinbeheerder heb ik meestal geen stroomvoorziening voor sensoren en heb ik dus een oplossing met zonnepanelen nodig - Als lokaal bestuur wil ik ook een sensor of camera om te zien hoeveel sediment in de poel aanwezig is - Als product owner wil ik de volgende zaken kunnen consulteren: o Pluviometer o Camera (voor analyse sediment) o Hoogtemeter (voor analyse sediment) o Debietmeter o Turbiditeitsmeter o Batterij toestand sensoren - Als landbouwer wil ik niet dat de sensoren niet in de weg staan. - Als terreintechnieker heb ik meestal geen stroom dus oplossing met zonnepaneel nodig. Discussie : De volgende opmerkingen werden gegeven: - Verschillende sensoren moeten worden meegenomen: Regen, camera’s, hoogtemeter, batterijstand sensor, … - Als LB wil ik ook een camera om te zien hoeveel sediment aanwezig is, niet alleen peil maar ook 3D beeld meten. - Het werd beslist verder onderzocht gevoerd moet worden naar wie de plaatsing van de sensoren zal doen. Idealiter kom je tot een oplossing dat een totaaloplossing is, dit zou toch door experts en onderhouders moeten gedaan worden. Meestal wordt alles geïnstalleerd door een aannemer, en wordt dat geregeld door raamcontracten met leveranciers. Het moet verder onderzocht worden of de interne technische dienst van de gemeente dat kan oplossen, maar de werkgroep is niet overtuigd dat dit mogelijk is om binnen de gemeente te houden. Daarom, andere term hanteren dan ‘terreintechnieker’. Als gemeente wil men de aankopende partij zijn die de volledige dienst van de plaatsing en onderhoud van de erosiepoelen en meters voorziet. - Wij hebben ervaring met vandalisme dus dit is iets dat moet worden opgenomen. Use case 2 ID Type Samenvatting Beschrijving UC2 Use case UC2: Data Captatie Ik wil als gebruiker alle informatie correct binnenkrijgen (context, data, goede transmissie) BC2.1 Business capability overzicht sensoren Als dataowner wil ik een overzicht hebben van alle bestaande sensoren met hun attributen (=context) BC2.2 Business capability context meekrijgen Als datamanager wil ik bij elke meting de context (callibratie gegevens, temperatuur, metadata, foutmarges, ed) meekrijgen BC2.3 Business capability buffer bij transmissie Als datamanager wil ik een buffer hebben zodat bij zwakke transmissie signaal of databank overload de data niet verloren gaat BC2.4 Business capability SIM kaarten prijs en gebruik Als datamanager wil ik overzicht hebben van alle SIM kaarten of andere transmissiekanalen met hun attributen (prijs, gebruik, enz.) BC2.5 Business capability stroomvoorzieningen Als datamanager wil ik overzicht hebben van alle stroomvoorzieningen (via kabel of via batterijen) met attributen (contracten, prijzen, verbruik, enz) BC2.6 Business capability onderhoudsplanning Als datamanager wil ik een datagedreven onderhoudsplanning kunnen opmaken voor alle gebruikte sensoren (en databronnen) BC2.7 Business capability contactpersonen Als datamanager wil ik eerste en tweedelijn contactpersonen hebben bij defecte sensoren of databronnen BC2.8 Business capability transmissie raamcontract Als lokaal bestuur wil ik een raamcontract kunnen uitkiezen waarbij ik de transmissie van de sensoren data optimaal kan beheren (4of5G, LoRa, Sigfox, ) BC2.9 Business capability transmissie Als data-owner heb ik LoRa, Sigfox, 4/5G, zonnepanelen/batterijen nodig om data te uploaden op het platform Aanvullende use cases: - Als data-owner heb ik LoRa, Sigfox, 4/5G, zonnepanelen/batterijen nodig om data te uploaden op het platform. - Als lokaal bestuur wil ik de status van een erosiepoel kennen op elk moment. Discussie De volgende opmerkingen werden gegeven: - LoRa (transmissietechniek): LoRa is een specificatie voor een telecomnetwerk en is geschikt voor langeafstandscommunicatie met weinig vermogen. Het is geschikt om data uit te wisselen tussen bijvoorbeeld verschillende objecten, zoals bushokjes, prullenbakken en lantaarnpalen. Dit kan ook gebruikt worden om data door te sturen van de sensoren. o De combinatie moet aangeboden worden om alle communicatie mogelijk te maken. o Camerabeelden zijn onmogelijk om over een LORA te brengen. - Men moet ook nadenken over dynamische frequentie van data die doorgestuurd wordt; batterijen kunnen dan voor 1-2 jaar meegaan als de frequentie dynamisch kan gemaakt wordt. Hierdoor zouden we de frequentie kunnen aansturen in functie van de context, bijvoorbeeld als er een storm aan komt kan men zo het verbruik van de batterij beheren, maar eerst moet een voorafgaande analyse gemaakt worden. Uiteindelijk zou dit kunnen betekenen dat er geen zonnepaneel nodig is. De volgende vragen werden gesteld: - Moet iedere gemeente dan een datamanager hebben? o Hier bedoelen we eerder iemand die de data gaat controleren, kan een manager zijn binnen het platform, maar is eerder een rol of profiel, i.p.v. een person op zich. Use case 3 ID Type Samenvatting Beschrijving UC3 Use case UC3: Dataplatform Ik wil als gebruiker een visualisatie zien van alle data zodat ik deze kan analyseren.Ik wil als gebruiker data kunnen toevoegen, aanpassen, delen en opslaan. BC3.1 Business capability Sensordata Als lokaal bestuur wil ik een platform waarop ik sensordata kan laten toestromen BC3.2 Business capability Andere data Als lokaal bestuur wil ik ook andere data (bv. Geodata, KMI, waterinfo.be) toevoegen (via bulk uploads, push/pull APIs, VSDS, ) BC3.3 Business capability verrijken Als lokaal bestuur wil ik de data kunnen verrijken BC3.4 Business capability veilige opslag Als lokaal bestuur wil ik alle data veilig kunnen opslaan BC3.5 Business capability Verwerking Als lokaal bestuur wil ik brondata verwerken BC3.6 Business capability Metadata Als lokaal bestuur wil ik data kunnen beschrijven met al zijn attributen, bronnen, kwaliteit, gebruiksvoorwaarden, enz. BC3.7 Business capability Analyseren & interpreteren Als lokaal bestuur wil ik data kunnen analyseren (zie UC6 en UC9) BC3.8 Business capability Acties Als lokaal bestuur wil ik alarmen kunnen laten genereren (zie UC5) BC3.9 Business capability Export Als lokaal bestuur wil ik data kunnen delen, bv. met boeren, verzekeringen, kennisinstellingen, (zie UC10) BC3.10 Business capability Beheer (=governance) Als lokaal bestuur wil ik goeie afspraken ivm beheer (rollen, verantwoordelijkheden) en dragen van kosten van het platform (zie UC11) BC3.11 Business capability Schaalbaar Als lokaal bestuur van een stad wil ik gemakkelijk mijn data kunnen opladen en verwerken op dezelfde manier BC3.12 Business capability Provinciebreed Als provincie wil ik meerdere dataplatformen kunnen combineren BC3.13 Business capability versnippering vermijden Als provincie wil ik dat zoveel mogelijk besturen toegang hebben tot een centraal dataplatform om versnippering te vermijden BC3.14 Business capability academie Als product owner wil ik dat de data ook ontsloten wordt naar de academische instellingen BC3.15 Business capability sensoren performantie Als lokaal bestuur wil ik weten of mijn sensoren nog correct data blijven doorsturen en dit aan de hand van een kleurencode : rood = kritiek, geel=waarschuwing BC3.16 Business capability opschaling sensoren en toepassingen Als gebruiker wil ik een eenvoudig opschaalbaar dataplatform waarbij sensoren kunnen worden toegevoegd (zie BC3.1), er een link kan gemaakt worden met externe data (zie BC3.2) en nieuwe toepassingen kunnen ge mplementeerd worden BC3.17 Business capability Als provincie wil ik een provincie breed zicht op de erosieproblematiek (actueel) BC3.18 Business capability Dataspaces (?) Als provincie wil ik meerdere dataplatformen kunnen combineren BC3.19 Business capability waterinfo.be Als lokaal bestuur wil ik een link met waterinfo.be BC3.20 Business capability externe databronnen Als lokaal bestuur wil ik naast mijn eigen sensordata ook andere data zien in grafieken (bv. KMI, waterinfo.be) zie BC3.2 BC3.21 Business capability centrale dataplatform Als provincie wil ik dat zoveel mogelijk besturen toegang hebben tot een centraal dataplatform om versnippering te vermijden BC3.22 Business capability API om te lezen Als systeembeheerder wil ik een API kunnen openstellen opdat andere applicaties ook toegang (lees) zouden hebben tot die data BC3.23 Business capability API om te schrijven Als systeembeheerder wil ik een API kunnen openstellen opdat andere applicaties ook data kunnen opladen, schrijven, aanpassen en verwijderen volgens hun rechten toegekend door de governance model Aanvullende use cases: - Als lokaal bestuur wil ik weten of mijn sensoren nog correct data blijven doorsturen en dit aan de hand van een kleurencode: rood = kritiek, geel = waarschuwing - Als gebruiker wil ik een eenvoudig opschaalbaar dataplatform waarbij sensoren kunnen worden toegevoegd, er een link kan gemaakt worden met externe data en nieuwe toepassingen kunnen geïmplementeerd worden - Als provincie wil ik een provincie breed zicht op de erosieproblematiek (actueel) - Als provincie wil ik meerdere dataplatformen kunnen combineren - Als lokaal bestuur wil ik een link met waterinfo.be - Als lokaal bestuur wil ik naast mijn eigen sensordata ook andere data zien in grafieken (bv. KMI, waterinfo.be) - Als provincie wil ik dat zoveel mogelijk besturen toegang hebben tot een centraal dataplatform om versnippering te vermijden Discussie Verschillende zaken kunnen toegevoegd worden: - Link met datawaterlopen / waterinfo - Als provinciebestuur wil ik dat zoveel mogelijk besturen toegang hebben tot het dataplatform om versnippering te vermijden. - Ik wil zoveel mogelijk data verzamelen om te verspreiden naar verschillende academische instellingen. - Data koppelen & Linken van externe data De volgende opmerkingen werden gegeven: - Vlaanderen blijft bij theoretische modellen, er is wel waterinfo, maar dat water stond lang niet op punt (VMM). We spreken over erosie het zou interessant zijn als Departement Omgeving hier aan tafel zit. We willen data delen en het verhaal dat we data verkopen is ook niet gecovered, AI is alles wat je niet mag doen i.p.v. dat er wel iets is. - Waterinfo werkt heel goed, of daar nu veel erosie inzit of niet maakt niet op dat moment, men wil real time weten of de tank vol zit of niet, en na een maand ofzo dan het wel interessant zijn om de erosie te meten. Dit is niet real time nodig; maar de waterstand wel. - We zullen moeten vermijden dat alle data versnipperd wordt op verschillende platformen, want later zal alles gemeten worden. We willen de data brengen op verschillende platformen. Use case 4 ID Type Samenvatting Beschrijving UC4 Use case UC4: Dashboarding Ik wil als gebruiker een dashboard kunnen hanteren met KPI's (bv kleurencodes) die ik zelf kan beheren in functie van de data. BC4.1 Business capability Story telling dashboard Als lokaal bestuur wil ik een overzicht dashboard krijgen die een goede situatie geeft van de risico en preventie elementen tegen modderstromen BC4.2 Business capability Sensoren Kwaliteit Als lokaal bestuur wil ik ook kunnen zien of de sensoren nog goed werken die de KPI produceren BC4.3 Business capability Self-service Als lokaal bestuur wil ik de layout en keuze van KPIs zelf kunnen instellen BC4.4 Business capability Thresholds Als lokaal bestuur wil de 'grenswaarden' kunnen invoeren die bepaald wat 'groen', 'geel', 'oranje', 'rood' en 'zwart' zijn BC4.5 Business capability data ontsluiten Als lokaal bestuur wil ik de cijfers van de dashboard in mijn eigen dashboard kunnen integreren om te vermijden dat ik altijd meerdere dashboard moet openen BC4.6 Business capability op sensor niveau Als lokaal bestuur wil ik alle sensoren zien op de kaart en op een specifieke sensor kunnen klikken waarbij data in een grafiek kan weergegeven worden BC4.7 Business capability Integratie bestaande Als lokaal bestuur wil ik dat de data van de dashboard ook ontsloten wordt om zo geintegreerd kan worden in mijn lokale dashboard die ik al gebruik, om te vermijden dat ik meerder applicaties moet openen. BC4.8 Business capability Real Time Als lokaal bestuur wil ik de status van een erosiepoel kennen op elk moment BC4.9 Business capability grafiek per sensor Als lokaal bestuur wil ik alle sensoren zien op de kaart en op een specifieke sensor kunnen klikken waarbij data in een grafiek kan weergegeven worden. BC4.10 Business capability voorspellingen overzicht Als lokaal bestuur wil ik zicht hebben op de voorspelde neerslag en het peil van de poelen. Daarbij moeten waarschuwingen weergegeven worden bij een (voorspelling van) een hoge waterstand Bijkomende use cases: - Als lokaal bestuur wil ik alle sensoren zien op de kaart en op een specifieke sensor kunnen klikken waarbij data in een grafiek kan weergegeven worden. - Als lokaal bestuur wil ik zicht hebben op de voorspelde neerslag en het peil van de poelen. Daarbij moeten waarschuwingen weergegeven worden bij een (voorspelling van) een hoge waterstand Discussie De volgende opmerking werd gegeven: - Het is niet wenselijk om telkens nieuwe dashboards te maken, we zouden moeten zorgen dat de bestaande dashboards geïntegreerd kunnen worden. Use case 5 ID Type Samenvatting Beschrijving UC5 Use case UC5: Message Center Ik wil als gebruiker via mijn tool contacten kunnen aanspreken, toevoegen, wijzigen en behandelen (messaging systeem). BC5.1 Business capability Contact info Als beleid wil ik de email, gsm, adressen, ed van landbouwers, stads- of dorpsbewoners, kunnen verzamelen om eventueel te contacteren (bvb bij calamiteiten, of downtime van de applicatie) BC5.2 Business capability Opt in/out & Voorkeuren Als gebruiker wil ik mijn opt in en opt out kunnen beheren wanneer ik wil, alsook mijn voorkeur kunnen geven in de onderwerpen alsook manier waarop ik informatie krijg BC5.3 Business capability GDPR Als beleid wil ik kunnen garanderen dat ik de data behandel volgens de GDPR regels in voege BC5.4 Business capability Historiek Als beleid wil ik kunnen bijhouden welke communicatie gestuurd werd naar welke gebruiker BC5.5 Business capability Marketing pressure Als beleid wil ik een overzicht krijgen van aantal communicatie per type van communicatie en per ontvanger in de laatste periode om zo te zorgen dat de ontvanger al dan niet het gevoel krijgen 'gestalkt' te worden. BC5.6 Business capability Segmented contact Als platform owner wil ik via het plafrom een individu, of een segment van individuen, kunnen contacteren op de meest gepaste en gewenste medium BC5.7 Business capability Trigger based Als lokaal bestuur wil ik een bericht automatisch kunnen laten uitsturen op basis van regels en beslissingsbomen BC5.8 Business capability Dashboard based Als lokaal bestuur wil ik een bericht automatisch kunnen laten uitsturen ifv de waarde condities in mijn dashboard (zie UC4) BC5.9 Business capability DPO overzicht Als DPO wil ik een overzicht krijgen van alle bijgehouden contact informatie van de aanvragers BC5.10 Business capability Live feed Als lokaal bestuur wil ik sommige gevallen een live feed kunnen krijgen op bepaalde metingen, vooral bij een crisis BC5.11 Business capability wie krijgt wat Als lokaal bestuur wil ik zelf bepalen wie een waarschuwing ontvangt en op welke manier. Bijkomende use cases: - Als lokaal bestuur wil ik zelf bepalen wie een waarschuwing ontvangt en op welke manier. - Als gemeente willen we bepalen wie de berichten/meldingen ontvangt. - Live feed zodat ik kan zien wat er gaande is, bovenop de data/alarmen. Use case 6 ID Type Samenvatting Beschrijving UC6 Use case UC6: Predictie Op basis van de verworven data wil ik modellen kunnen gebruiken om predicties uit te voeren zodat er tactisch advies gegeven kan worden. BC6.1 Business capability Historische data Als datascientist wil zoveel mogelijk data (incl. hoogfrequente) verzamelen van gebeurde modderstromen om die te analiseren en begrijpen BC6.2 Business capability Staven bestaande Als datascientist wil ik bestaande academische en theoretische predictieve modellen kunnen staven met eigen data BC6.3 Business capability Termijn predictie Als datascientist wil ik predicties kunnen doen op verschillende termijnen (binnen een week, een dag, 6 uur, enz.) van modderstromen BC6.4 Business capability Data reductie Als datascientist wil ik advies geven over de optimale of minimale databronnen die nodig zijn om hoogpredictieve modellen te bouwen. BC6.5 Business capability Frequentie & historisatie Als datascientist wil ik advies geven over de minimale frequentie en historisatie nodig om accurate en vroegtijdige predicties te kunnen doen. BC6.6 Business capability Context Data Als datascientist wil ik andere omgevingsdata kunnen meten en integreren zoals type gewassen, hellingsgraad, regenval, hoogte gewassen, richting akkerlijnen, BC6.7 Business capability doorslaggevende databron Als datascientist wil ik kunnen bepalen welke de meest doorslaggevende databron wanneer er bespaard moet worden Bijkomende use cases: Er werden geen bijkomende use cases besproken. Discussie De volgende opmerkingen werden gegeven: - Men moet de meest doorslaggevende databron bepalen die aangeeft wanneer er kosten moeten gemaakt worden. - We moeten nagaan hoeveel databronnen we nodig hebben om een juiste predictie te kunnen doen. Soms kan dat met 3 bronnen i.p.v. met 7. Dit zal ook bepaald worden in de komende werkgroepen van het VLOCA-traject. Use case 7 ID Type Samenvatting Beschrijving UC7 Use case UC7: Mitigatie Op basis van real time data en advies wil ik als lokaal bestuur kunnen reageren om de schade te minimaliseren (crisis management). BC7.1 Business capability Geo Heatmap Als lokaal bestuur wil ik een overzicht krijgen van een potentiele opkomende modderstroom met risico kans en estimatie van schade (via een geo'heatmap') BC7.2 Business capability 24/7 alarmsignaal Als burgemeester of lokaal bestuur wil ik kunnen instellen om een alarmbericht te krijgen in specifieke gevallen 24/7 BC7.3 Business capability Optimalisatie acties Als lokaal bestuur wil ik snelle data gedreven advies krijgen hoe we de inspanningen het meest optimaal verdelen BC7.4 Business capability Defect signaal Als lokaal bestuur wil ik een berichtje krijgen bij het 'uitvallen' van een belangrijke databron BC7.5 Business capability stock status Als lokaal bestuur wil ik de stock van bvb zandzakken per locatie en contactinfo willen zien BC7.6 Business capability standaard procedures Als lokaal bestuur wil ik standaard procedure willen krijgen bij elke situatie BC7.7 Business capability brandweerzone Als brandweerzone wil ik tijdig op de hoogte gebracht worden om in te grijpen bij modderstromen BC7.8 Business capability n platform voor real time data Als lokaal bestuur wil ik realtime data met een alarm op 1 platform kunnen raadplegen. Bijkomende use cases: - Als brandweerzone wil ik tijdig op de hoogte gebracht worden om in te grijpen bij modderstromen. - Als lokaal bestuur wil ik realtime data met een alarm op 1 platform kunnen raadplegen. Discussie De volgende opmerking werd gegeven: - Het is niet zozeer nuttig om toe te voegen hoeveel zandzakken er in stock zijn. Het is de bedoeling om proactief te werk te kunnen gaan en op voorhand al inzicht te krijgen of de technische dienst naar de poel in kwestie kan rijden om de situatie onder controle te houden. Use case 8 ID Type Samenvatting Beschrijving UC8 Use case UC8: Preventie Als lokaal bestuur wil ik een overzicht krijgen van adviezen, acties en aanbevelingen om modderstromen te vermijden. BC8.1 Business capability Vuistregels type Als lokaal bestuur wil ik 'vuistregels' krijgen welke type erosiepoelen geschikt zijn ifv de context BC8.2 Business capability Vuistregels locatie Als lokaal bestuur wil ik 'vuistregels' krijgen waar ik welke erosiepoelen het beste zou plaatsen BC8.3 Business capability Onderhoudsplan Als lokaal bestuur wil ik een datagedreven planning krijgen hoe de erosiepoelen moeten onderhouden worden BC8.4 Business capability Locatie sensoren Als lokaal bestuur wil ik advies krijgen waar ik welke sensoren moet plaatsen voor adviserende en/of predictieve modellen BC8.5 Business capability frequentie uitgraven Als landbouwer wil ik weten wanneer ik mijn modderpoel opnieuw uitgegraven hoeft te worden BC8.6 Business capability leegmaken erosiepoelen Als lokaal bestuur wil ik weten wanneer men moet optreden om terug volle capaciteit te hebben van de erosiepoelen BC8.7 Business capability inzichten modderstromen Als lokaal bestuur wil ik met de sensor data samen met hoogtekaarten, het overzicht van knelpunten voor erosiebestrijding van Departement Omgeving, en andere bronnen een inzicht kunnen krijgen waar de modderstromen probleem zit Bijkomende use cases Er werden geen bijkomende use cases aangehaald. Discussie De volgende opmerkingen werden gegeven: - Het is niet de bedoeling om een uitvoerige dataanalyse te doen, de data kan achteraf misschien nuttig zijn voor academisch onderzoek. - Er bestaan veel databronnen zoals bijvoorbeeld de hoogtekaarten van Vlaanderen of het overzicht van knelpunten voor erosiebestrijding van Departement Omgeving, als je deze combineert zal je wel een idee krijgen van waar het potentieel probleem zit. Dit zit echter niet in scope van het project. Use case 9 ID Type Samenvatting Beschrijving UC9 Use case UC9: Advies Op basis van data van modderstromen wil ik dit kunnen analyseren, correlaties zien en advies verlenen. BC9.1 Business capability data collectie Als datascientist wil zoveel mogelijk data verzamelen van gebeurde modderstromen om die te analiseren en begrijpen BC9.2 Business capability theoretische modellen staven Als datascientist wil ik bestaande academische en theoretische modellen kunnen staven met eigen data BC9.3 Business capability causaliteit tussen bronnen Als datascientist wil ik correlaties en causaliteiten kunnen ontdekken in de verschillende datastromen BC9.4 Business capability minimale data bronnen Als datascientist wil ik advies geven over de optimale of minimale databronnen die nodig zijn om adviezen te kunnen blijven formuleren BC9.5 Business capability data granulariteit Als datascientist wil ik advies geven over de frequentie en historisatie nodig om adviezen te kunnen blijven formuleren BC9.6 Business capability nulmeting Als datascientist wil ik een nulmeting kunnen doen om het toegevoegde waarde van het platform te kunnen staven BC9.7 Business capability hoogtekaarten Als datascientist wil ik met 'hoogtekaarten' bvb hotspots indentificeren waar bvb erosiepoelen zouden moeten komen BC9.8 Business capability vroegere acties analise Als datascientist wil ik de acties die gebeurd zijn in het verleden analiseren om zo advies te kunnen geven voor de volgende keer BC9.9 Business capability dynamische frequentie Als datascientist wil ik de frequentie dynamisch kunnen maken in functie van de urgentie, bvb bij gevaar kan de frequentie stijgen en dan weer dalen bij geen gevaar om zo de batterij de sparen opdat misschien geen zonnepalen moeten geplaatst worden (die dan niet gejat kunnen worden) BC9.10 Business capability win-win Als lokaal bestuur wil ik met data de meerwaarde van poelen kunnen aantonen om eigenaars van terreinen te overtuigen BC9.11 Business capability advies dimensionering erosiepoelen Als erosieco rdinator wil ik inzichten rond poelen krijgen zodat ik in de toekomst beter kan dimensioneren. (zie BC8.1) Bijkomende use cases: - Als lokaal bestuur wil ik met data de meerwaarde van poelen kunnen aantonen om eigenaars van terreinen te overtuigen. - Als erosiecoördinator wil ik inzichten rond poelen zodat ik in de toekomst beter kan dimensioneren. Discussie - De verschillende use cases onder UC9 zijn allemaal relevant, maar er bestaan al hoogtekaarten, meervoudige water afstromingslijnen en de potentiële erosiekaarten die de kleuren aangeven. Aangezien dit al bestaat moet de focus hier niet op liggen. Use case 10 ID Type Samenvatting Beschrijving UC10 Use case UC10: Marktplaats ik wil als gebruiker data en datasciencemodellen kunnen aanbieden en verkrijgen. BC10.1 Business capability interne data aanbod Als lokale speler wil ik gemeten of gekregen data kunnen opslaan en 'aanbieden' op een data platform marktplaats BC10.2 Business capability aanbod modellen Als lokale speler wil ik gebouwde of gekochte modellen kunnen opslaan en 'aanbieden' op een datascience platform marktplaats BC10.3 Business capability vraag modellen en data Als lokale speler wil ik data en/of modellen kunnen halen/kopen/huren/ van het datascience platform marktplaats BC10.4 Business capability financieel model Als marktplaats manager wil ik de gebruikers kunnen factureren via abonnementen of per gebruik of nog andere dimensies BC10.5 Business capability aanbod data Als data leverancier wil ik allerlei relevante data kunnen aanbieden op de marktplaats BC10.6 Business capability aanbod modellen Als datascientist leverancier wil ik allerlei relevante datascience modules kunnen aanbieden op de marktplaats BC10.7 Business capability reviews Als gebruiker van de marktplaats wil ik de data en modellen kunnen 'reviewen' op hun kwaliteit en relevantie BC10.8 Business capability bibliotheek Als gebruiker wil ik een overzicht kunnen zien van alle beschikbare data en daarbij relevante modellen die beschikbaar zijn voor mijn probleem BC10.9 Business capability landbouwer als gebruiker Als landbouwer wil ik op een gebruiksvriendelijke manier data ontvangen over neerslag en temperatuur BC10.10 Business capability provincie als gebruiker Als provincie wil ik dat gemeentebesturen op een laagdrempelige manier data kunnen delen en uitwisselen BC10.11 Business capability andere projecten als gebruiker Als provincie wil ik dat de data die verzameld wordt in dit project kan gebruikt worden voor andere, toekomstige projecten Bijkomende use cases: - Als landbouwer wil ik op een gebruiksvriendelijke manier data ontvangen over neerslag en temperatuur - Als provincie wil ik dat gemeentebesturen op een laagdrempelige manier data kunnen delen en uitwisselen - Als provincie wil ik dat de data die verzameld wordt in dit project kan gebruikt worden voor andere, toekomstige projecten Discussie De volgende opmerkingen werden gegeven: - Als er geld en tijd is wordt dit meegenomen in scope en anders niet. - Er zullen best practices uit het project van Roeselare meegenomen worden naar dit traject om zoveel mogelijk kennis te delen en te hergebruiken. Use case 11 ID Type Samenvatting Beschrijving UC11 Use case UC11: ROI Business Modelling BC11.1 Business capability kosten baten analyse Als lokaal bestuur wil ik gemakkelijk een kosten baten analyse kunnen doen die een paar scenario's kan voorleggen ivm sensoren planning BC11.2 Business capability estimatie kosten modderstromen Als lokaal bestuur wil ik een estimatie hebben van de kosten van modderstromen BC11.3 Business capability estimatie mitigatie Als lokaal bestuur wil ik een estimatie hebben van de mogelijke mitigatie dankzij een preventief platform BC11.4 Business capability estimatie aantal sensoren Als lokaal bestuur wil ik een estimatie hebben van de verschillende sensoren die nodig zouden zijn om het model te laten draaien BC11.5 Business capability kostendeling model Als lokaal bestuur wil ik de kosten kunnen laten delen met andere belanghebbenden BC11.6 Business capability duurzaamheid Als lokaal bestuur wil ik de onderhoudskosten van het 'systeem' kunnen inschatten om de duurzaamheid te garanderen BC11.7 Business capability kost erosiepoel Als beleidsmaker wil ik weten wat de totaalkost van een erosiepoel is, inclusief monitoring BC11.8 Business capability raamcontracten bibliotheek Als lokaal bestuur wil ik toegang hebben tot alle geldige raamcontracten mbt aankoop en uitbesteding van de onderdelen van dit project Bijkomende use cases: - Als beleidsmaker wil ik weten wat de totaalkost van een erosiepoel is, inclusief monitoring Discussie De volgende opmerkingen werden gegeven: - Dit is niet de basis voor het traject. Voor beleidsmakers is het doel om de totaalkost van de erosie (uitgraven + onderhoud) te kunnen communiceren naar omwonenden en andere belanghebbenden rond de erosiepoel. - Het gaat voornamelijk over de kostprijs op je meerjarenplan dat gecommuniceerd moet worden. Use case 12 ID Type Samenvatting Beschrijving UC12 Use case UC12: Helpdesk Helpdesk - FAQ - Reviews BC12.1 Business capability helpdesk 24/7 Als gebruiker wil ik een contact helpdesk kunnen contacteren (via mail, chat, telefoon, brief, whatsup, enz.) bij issues BC12.2 Business capability FAQ Als ambtenaar wil ik een FAQ kunnen publiceren ifv de inkomende vragen en opmerkingen BC12.3 Business capability Overview inbound Als lokaal bestuur wil ik een overzicht kunnen zien van alle opmerkingen, vragen, klachten, reviews enz. Ivm het proces, de tool, de dossierbeheerder, enz. BC12.4 Business capability Review knop Als gebruiker wil ik een 'review' knop hebben mbt mijn ervaring BC12.5 Business capability Chatbot Als gebruiker wil ik mijn vraag aan een 'chatbot' kunnen stellen Bijkomende use cases: Er werden geen bijkomende use cases aangehaald. Discussie : De volgende opmerkingen werden gegeven: - Als je zo gebruikt maakt van een system is het nodig om iemand te kunnen contacteren met klachten en vragen wanneer er iets niet werkt. Je kan dat niet zomaar uitlaten en de mensen hun plan te laten trekken. Hierbij zou ook nog training bij moeten komen. - Je moet ook rekening houden dat de helpdesk uit twee zaken zou bestaan (de backlog van het system enerzijds en iemand aan de front die de problemen kan oplossen). - Het is niet nodig en dringend om 24/7 helpdesk aan te bieden. - Deze helpdesk moet in elk system dat je bouwt ondergebracht worden. Dit kan wel nog out of scope gelaten voor dit traject indien zo nodig. Volgende stappen Wat na deze werkgroep? 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-02-29 13u30-16u30 Provinciehuis Leuven Thematische werkgroep 1 Data en informatie werkgroep 2024-03-19 9u-12u Teams Thematische werkgroep 2 Functionele werkgroep 2024-04-18 9u-12u Teams Thematische werkgroep 3 Technologie werkgroep 2024-05-23 9u-12u Teams +
Business werkgroep VlocaTraject/REVOLT T … Business werkgroep VlocaTraject/REVOLT Tijdens de eerste sessie, de “business werkgroep”, duiken we in de use cases. Eerder werden er al een aantal use-cases geformuleerd door het kernteam. Deze werden verwerkt in het VLOCA-model. Het doel van deze sessie is om de use-cases te valideren, eventueel bijkomende use-cases te formuleren en de scope van het project af te bakenen. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen. Context Initiatief Europa en Vlaanderen zetten nu meer dan ooit in op klimaat- en energiedoelstellingen. Lokale besturen engageren zich via het burgemeesterscovenant om hun steentje bij te dragen. Bedrijven blijken een moeilijke doelgroep te zijn om in dit verhaal te betrekken. Er zijn al verschillende maatregelen ondernomen om bedrijven aan te moedigen om meer te investeren in hernieuwbare energie, maar toch blijft veel potentieel onbenut. Bedrijven hebben onvoldoende zicht op hun huidig verbruiken of op de besparingen die deze investeringen hen kunnen opleveren. Met REVOLT willen we bedrijven op lokale bedrijventerreinen inzicht geven in hun energieproductie en –verbruik door het opzetten van een energieplatform met real-timedata. Het doel is om energie-efficiëntie te bevorderen en het aandeel hernieuwbare energie te verhogen. Het platform moet het mogelijk maken om als gebruiker berekeningen en simulaties te maken op basis van de gecapteerde data en de actuele energiemarktprijzen. Daarnaast is het slim aansturen van het verbruik een belangrijke toepassing die zal resulteren in een lagere energiefactuur voor de bedrijven. Het doel is om bedrijven te ontzorgen en gemeenten te ondersteunen in het behalen van hun klimaat- en energiedoelstellingen. VLOCA VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders. OSLO Het doel van OSLO is om de datastromen semantisch te modelleren en de structuur van de data te standaardiseren in de context van lokale economie. Hierbij zal de focus gelegd worden op het verbeteren van de gegevensuitwisseling tussen lokale handelaars, horeca ondernemers en beleidsmakers. Met OSLO wordt er concreet ingezet op semantische en technische interoperabiliteit. De vocabularia en applicatieprofielen worden ontwikkeld in co-creatie met o.a. Vlaamse administraties, lokale besturen, federale partners, academici, de Europese Commissie en private partners (ondertussen meer dan 4000 bijdragers). Extra informatie en een verzameling van de datastandaarden zijn te vinden op volgende links: https://overheid.vlaanderen.be/oslo-wat-is-oslo en https://data.vlaanderen.be/ Brainstormsessie Het doel en de aanpak van de brainstormsessie worden hieronder beschreven. Tevens wordt de uitkomst van de brainstorm hierin samengevat. Doel van de brainstormsessie Het doel van de brainstormsessie is het volgende: De missie, visie en doelstellingen van het project, zoals geformuleerd in het VLOCA-model, valideren en feedback capteren De use cases, zoals geformuleerd in het VLOCA-model, valideren en feedback capteren Noot: aangezien er ondertussen gekozen werd een bestaande EMS-oplossing, werd door de initiatiefnemers besloten om het zwaartepunt te verleggen naar de lokale besturen: het omschrijven van PI’s/KPI’s die door lokale besturen gebruikt kunnen worden en die meten hoe succesvol de inspanningen op een bedrijventerrein zijn. het vorm geven van een dashboard. Dit kan een theoretisch model blijven, aangezien het bouwen van een extra dashboard niet in scope zit. het verder ondersteunen van het draaiboek, dat een lokaal bestuur toelaat om dezelfde operaties op andere locaties met succes uit te voeren. Missie, visie en doelstellingen Gezien de aangepaste scope, werd aan de deelnemers gevraagd om de reeds geformuleerde missie, visie en doelstellingen te herbekijken en na te denken over de vraag 'hoe ga je zo lokale besturen ondersteunen'? Missie Wat willen we bereiken? "Ontzorgen van bedrijven door advies en real time data te bezorgen om energie-efficiëntie te bevorderen, netinfrastructuur belasting te verminderen, en het aandeel hernieuwbare energie te verhogen in bedrijventerreinen" Discussie : Vergemakkelijken communicatie met bedrijven = platform om gemakkelijker omdat hier de gemeente een actieve rol gaat spelen alsook mee investeert open dat deuren (om het niet top-down op te leggen gekregen) De industrie/bedrijven is een moeilijk te bereiken sector binnen het kader van het behalen van de klimaatdoelstellingen Indien er een platform zou bestaan waarbij de gemeente inzicht krijgt in het verbruik, kan dit als startbasis gebruikt worden om in gesprek te gaan met de bedrijven. Voordeel voor lokale besturen? Over welk niveau van overheid spreken we? = op provinciaal niveau ook? Krijg ik als lokale overheid dezelfde rechten als terreinbeheerder? = toegang tot data Ward: we merken op het terrein dat er iets/iemand nodig is om overzicht te bewaren/managen. De bedrijven staan niet met mekaar in contact. Een overkoepelende rol kan weggelegd zijn voor een lokaal bestuur of bvb WVI. De vraag is wel of bedrijven die data willen delen. Idealiter is alle data van Fluvius vrij beschikbaar voor de overheid om daarmee aan de slag te gaan Sommige bedrijven verkiezen dat een overheidsinstelling bvb WVI vanaf een bepaald moment niet meer aan tafel zit mbt het delen van (financiële) data omwille van wantrouwen tav overheid. Er is wel een rol weggelegd voor een overheid maar tot op een bepaald punt. Voor bedrijven is het volgende essentieel: indien er een business case is, bvb het garanderen van bedrijfscontinuïteit, dan is het interessant voor bedrijven om een actieve rol te gaan spelen in het project. Bedrijfscontinuïteit is onder andere zekerheid over een stabiele energietoevoer en, bijgevolg, hun productieproces. Net congestie kan een gevaar voor blackout, dus niet attractief voor de bedrijven om zich daar te vestigen. Zij worden minder gemotiveerd door het behalen van de klimaatdoelstellingen. Het gaat eerder over het financiële plaatje waarbij bedrijven de afweging maken van het delen van data in ruil voor advies. Hiervoor moet een overeenkomst afgesloten worden. Een win-win is essentieel. Voor lokale besturen is de 'win' enerzijds financieel: bedrijventerreinen zijn nu eenmaal een bron van inkomsten door middel van belastingen maar zorgen ook voor werkgelegenheid. Daarom is het belangrijk om in te zetten op de aantrekkelijkheid van de bedrijventerreinen. Bvb in Nederland is er op sommige momenten geen stroom beschikbaar op bedrijventerreinen, uiteraard verlies je dan bedrijven op die locatie. Anderzijds hebben lokale besturen hun klimaatdoelstellingen die ze moeten behalen, dit is een politiek element. Efficiënter inrichten (bvb windturbine, uitbreiding, zonnepanelen,...) nieuwe bedrijventerreinen op het grondgebied van de gemeente Complementair verbruik van bedrijven op elkaar afstemmen WVI als bedrijventerrein beheerder: bij nieuwe projecten rekening houden met data die zou kunnen verzameld worden via dit project en aan de hand hiervan, efficiënter inrichten van nieuwe bedrijventerreinen Door de integratie van energie efficiëntie bij de bedrijven komen er opportuniteiten voor de burgers. Goedkoop laden ipv premium price. De besturen krijgen maw hulp van de bedrijven binnen het vraagstuk van de energietransitie bvb zaterdag middag kan de overschot kan goedkoper aan de burger voorgesteld wordt) Goedkoper laden door energie overschot van bedrijven in publieke laad-infrastructuur ter beschikking stellen ipv dat bedrijf overschot op de markt moet brengen (tegen een kost) Alternatief: energie zelfs gratis ter beschikking stellen Een lokaal bestuur heeft weinig impact op het energieverbruik bij bedrijven. Door Revolt kan energie efficientie en hernieuwbare energie ondersteund worden door het lokaal bestuur bij bedrijven Lokale besturen kunnen hun publieke gebouwen evengoed aansluiten = herbruikbaarheid van het platform voor andere gebouwen enz. EMS systeem zoals momenteel gebruikt wordt door bedrijven, kan ook door lokale besturen gebruikt worden Alle inzichten die verworven worden via dit project, kunnen ook toegepast worden op publieke infrastructuur, net zoals het gebruikte systeem. Behalen klimaatdoelstellingen (aanzet om te gaan van highlevel ambities, naar meer KPI en data gedreven inzichten mbt klimaat doelstellingen Inzicht in verbruik bedrijventerreinen (trends om te zien of de capaciteit te vergroten binnen 5 jaar) en mogelijke productie hernieuwbare energie Wie het meeste verbruikt/produceert Het verbruik doorheen de tijd monitoren: wie, wanneer, hoeveel Inzichten krijgen om beslissingen te nemen (voor bedrijven, lokale overheden) Mbt toekomstvisie van het bedrijf: adhv data bepalen waarin investeren, Fluvius hierbij betrekken naar capaciteitsnood etc Klimaatactieplan: cijfers CO2 uitstoot zegt niet veel maar als je er acties aan moet koppelen, heb je inzichten nodig in het verbruik/productie Meerwaarde bieden aan bedrijven (gebruik platform) voor bijdrage aan klimaatdoelstellingen (klimaatplan, EPC niet residentiële gebouwen) - ze moeten bijdrage leveren aan hernieuwbare energie voor bedrijven: inzicht in (piek) verbruik Lokale economie steunen door energie efficiëntie = uitbreiding van de parken, meer werkgelegenheid = betere lokale economie Te gebruiken voor gemeentelijk patrimonium? Mogelijk wel in concurrentie met Terra = herbruikbaarheid (slim sturen niet via Terra?) Alle informatie Fluvius kan je in Terra opladen, mogelijkheden Terra zijn weliswaar beperkt Door de energievraag en het verbruik van bedrijven te optimaliseren, kan de belasting op de lokale netinfrastructuur verminderd worden (= fluvius) Door energie slim te sturen => minder pieken => minder nood aan verhoging capaciteit van het net Duurzame bedrijven en groene bedrijvenparken kunnen de leefbaarheid en aantrekkelijkheid van een regio verhogen. Dit trekt niet alleen nieuwe bedrijven en talenten aan, maar verbetert ook de kwaliteit van leven voor de lokale bevolking. Visie Wat is de bestaansreden? "Europese en Vlaamse klimaat-en energiedoelstellingen moeten gehaald worden, ook voor bedrijven op bedrijventerreinen. Ondertussen blijkt dat er veel onbenut potentieel ligt wegens weinig inzichten in de mogelijkheden en twijfels bij de ROI van zulke projecten. Dit komt grotendeels door gebrek aan (realtime) data. Indien meer data beschikbaar zou zijn, dan zijn bedrijventerreinen een ideale plaats om energie te delen, verdelen en produceren." De deelnemers van de werkgroep argumenteerden dat deze vraag overlapte met de vraag rond de 'missie'. De visie werd niet besproken. Doelstellingen Wat is het doel van het project? "Een energie platform dat zowel inzichten geeft om beslissingen te nemen die efficiënte en duurzame energieproductie- en gebruik ondersteunt, alsook toestellen direct kan aansturen om automatisch die efficiëntie en duurzaamheid te garanderen" Discussie: %verbruik van eigen geproduceerde hernieuwbare energie op het bedrijventerrein moet stijgen en onmiddellijk op het terrein zelf verbruikt worden (efficiëntie). Voor het aanwenden van een overschot moet dan een business case gebouwd worden. Geïnstalleerd vermogen van hernieuwbare energie moet stijgen, ook al zijn die 120% bvb maar kan die overschot naar een bedrijf die tekort heeft => een positieve business case voor extra zonnepanelen % van hun volledig gebruik op jaarbasis tov eigen geproduceerde energie => streven naar 100% of meer Energie sturing heeft niet tot doel om energieverbruik te doen dalen maar eerder om er efficiënt mee om te gaan Doelstelling: via de oplossing niet alleen bedrijven maar ook de overheid ondersteunen adhv het verzamelen en ter beschikking stellen van data Use cases Gezien de gewijzigde scope werd besloten om een nieuw VLOCA-model met bijhorende use cases te bouwen. Deze zullen bij de volgende werkgroep voorgelegd worden voor feedback. Opname en Miro bord Miro bord Het Miro bord kan je consulteren via deze link . Opname De opname van deze sessie is te bekijken via deze link . Volgende stappen Wat na deze werkgroep? 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-03-21 10u-13u VAC Brugge Thematische werkgroep 1 Data en informatie werkgroep 2024-05-21 9u-12u Teams Thematische werkgroep 2 Functionele werkgroep 2024-06-18 9u-12u Teams +
Business werkgroep VlocaTraject/SHOK Tij … Business werkgroep VlocaTraject/SHOK Tijdens de eerste sessie, de “business werkgroep”, duiken we in de use cases. Eerder werden er al een aantal use-cases geformuleerd door het kernteam. Deze werden verwerkt in het VLOCA-model. Het doel van deze sessie is om de use-cases te valideren, eventueel bijkomende use-cases te formuleren en de scope van het project af te bakenen. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen. Heb jij interesse, specifieke noden, expertise of andere belangen bij dit traject? Klik hier om je in te schrijven. Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2024-09-12 13u-16u VAC Antwerpen Thematische werkgroep 1 Data en informatie werkgroep 2024-10-15 13u-16u Teams Thematische werkgroep 2 Functionele werkgroep 2024-11-12 13u-16u Teams Thematische werkgroep 3 Technologie werkgroep 2024-12-10 9u-12u Teamskgroep 2024-12-10 9u-12u Teams +