Thematische werkgroep 3

Technologie werkgroep

Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur. In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix.

De tweede thematische werkgroep vond plaats op 23 mei 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. Meer informatie over VLOCA en onze werking kan je terugvinden op https://www.vlaanderen.be/lokaal-bestuur/digitale-transformatie/vloca/vloca-trajectbegeleiding-waarom.

VLOCA-model

De start van elk VLOCA-traject begint bij een VLOCA-model:

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

Tijdens deze werkgroep staan we stil bij use cases 2-5.

In de onderstaande figuur zie je een visuele voorstelling van dit VLOCA-model:

Brainstormsessie

Het doel en de aanpak van de brainstormsessie worden hieronder beschreven. Tevens wordt de uitkomst van de brainstorm hierin samengevat.

Doel

Het doel van de brainstormsessie is het volgende:

• Zicht krijgen op de wensen mbt het dashboard
• Zicht krijgen op de wensen mbt het message center
• Inzicht krijgen in het data management
• Valkuilen en principes identificeren
• Nadenken over verduurzaming ifv de keuze voor een bepaalde databron

In de onderstaande figuur wordt het proces weergegeven dat zich afspeelt binnen het dataplatform:

Oefening 1

Instructies

Bij deze oefeningen stonden we stil bij de volgende vragen:

Welke soort dashboards zijn interessant voor de verschillende doelgroepen? Welke parameters wil je kunnen monitoren? Hoe wil je dat je data gevisualiseerd wordt? Welke inzichten wil je krijgen? Wie heeft toegang tot het dashboard? Wie heeft welke rechten om wat te kunnen?

Voorbeeld:

-Als rampen coördinator wil ik toegang tot het regionaal dashboard

-Ik wil de waterstand van een bepaalde stroom kunnen zien

-Een rapport trekken over temperatuur

-Een visualisatie over luchtvochtigheid over een bepaalde periode

-Ik wil een melding zien wanneer een bepaalde waarde overschreden is

Output

Parameters

Hoeveelheid (voorspelde) neerslag in grafiek

Check of alle sensoren nog werken

Werking sensoren/ status batterij/GPS...

Iets zoals bij waterinfo VMM : https://www.waterinfo.be/Themas#item=overstroming/actueel

Vullingsgraad van de poel (in kader van technisch onderhoud)

Zelfs over historische data moeten snelle queries mogelijk zijn

Performantie Queries

Alerts moeten op verschillende applicaties/devices mogelijk zijn en configureerbaar wie welke alerts krijgt. Elke stad kan zijn eigen configuratie hierin doen. Scheiding op tenant=stadsniveau? (je kunt niet in de data van een andere stad kunnen zien)

Scheidingslijnen : data governance => is dit relevant voor modderstromen ?

Rechtstreekse koppeling naar brondata met dashboardapplicaties zodat eigen dashboards met bijv. PowerBi makkelijk gemaakt kunnen worden en automatisch geupdated worden (read only). Dit wel met al de security vereisten: alleen eigen data kunnen zien, binnen een stad een hierarchie wie wat mag zien.

vaste dashboard, vs dynamische/self service dashboard, integratie in bestaande lokale dashboard

Stakeholder : Academici : Inzicht: vul- en ledigingscurves

Stakeholder : Academici : Inzicht: historische data

Stakeholder : Academici : Inzicht: makkelijk data kunnen downloaden voor verder onderzoek

Stakeholder : Academici : Maximale vulpeilen van buffers (of andere %) in grafiek

Rampcoördinatie: predictie van tijdstip van overlopen (+ aftelklok)

Rampcoördinatie: op kaart groen/geel/oranje/rood

Technische teams : Onderhoud: datum laatste onderhoud (poelen & sensoren)

Technische teams : Onderhoud: percentage van oorspronkelijke buffercapaciteit die er nog is

Technische teams : Onderhoud:  bijhouden wie onderhoud heeft uitgevoerd

Lokale input interface van alle informatie bij het ruimen bvb. (feedback loop)

Landbouwers goed bij betrekken

Bodemvocht

Stakeholder

Jonge vs oudere generaties

Neerslag gegevens

Stakeholders: omwonenden goed bij betrekken

Als landbouwer toegang tot de volgende data: hoeveelheid grond die afgestroomd is, bodemvocht (via de sensoren), hoeveelheid neerslag die gevallen is, ... en dit allemaal overzichtelijk gepresenteerd in de tijd. Ook eventuele alerts (van het vollopen) gaan handig zijn voor hem

Overzicht van de statussen van de buffers op kaart (gekleurde puntjes bvb)

Mobiel toegankelijke website

Bedenking: mogelijkheid aansluiting met andere toepassingen (vb Sirio van sumaque of flood4cast van hyrdroportal) - deze tool moet niet allés zelf kunnen, focus op poelen

Data space ?

Dashboard dient te kunnen linken met datalake in de cloud, real time gevoed kunnen worden door IoT standaard technologie om metingen van de sensoren via fabrikant en globale protocollen tot in de omgeving te krijgen die het dashboard kan gebruiken, een service die OSLO compliant data publiceert van dezelfde bron is beter te gebruiken vanaf de service of de store. Dashboard dient geo selecties mogelijk te maken en kan native integreren met MS PowerBI, MS Excel en heeft open API. Parameters moeten niet beperkt zijn in type

Discussie

1. Neerslagdata en Sensoren:
   • Een dashboard moet de hoeveelheid neerslag (verleden, heden, voorspellingen) tonen, met data van bijvoorbeeld het KMI.
   • Er moet een alarmsysteem zijn om te controleren of sensoren nog werken, inclusief batterijstatus en GPS-locatie.
   • Directe koppeling naar brondata is belangrijk, zodat de data eenvoudig te downloaden en te analyseren is, bijvoorbeeld via CSV-bestanden.
2. Operationeel Gebruik en Onderhoud:
   • Het dashboard moet operationele rapporten kunnen genereren om de werking van sensoren te bewaken.
   • Onderhoudsinformatie moet bijgehouden worden, inclusief de datum van het laatste onderhoud van zowel de sensoren als de poelen.
   • Er moet een onderscheid zijn tussen dashboards voor operationele inzichten, technisch onderhoud en rampenbestrijding.
3. Configuratie en Toegang:
   • Alerts moeten configureerbaar zijn per stad, zodat elke stad eigen instellingen kan beheren.
   • Er moet een duidelijke scheiding zijn tussen data van verschillende steden (multi-tenant omgeving).
   • Landbouwers moeten toegang krijgen tot relevante data (neerslag, bodemvocht, status van de buffers) en eventueel alerts voor overstroomrisico’s.
4. Gebruiksgemak en Toegankelijkheid:
   • Het dashboard moet mobiel toegankelijk zijn, zodat gebruikers ter plaatse snel informatie kunnen inzien.
   • Er moet rekening gehouden worden met de mogelijkheid om het dashboard te integreren met andere bestaande systemen en applicaties.
5. Predictiemodellen en Visualisatie:
   • Het systeem moet rampcoördinatie ondersteunen door voorspellingen te doen over wanneer buffers zullen overlopen en visueel alarmeren (groen, oranje, rood).
   • Het is belangrijk om visueel overzicht te hebben van de vul- en ledigingsfrequentie van de buffers, inclusief een aftelklok voor voorspelde overstromingen.
6. Data Governance en Technische Overwegingen:
   • Er moet een flexibele data-architectuur zijn waarin data uit verschillende bronnen real-time kan worden geïntegreerd en geanalyseerd.
   • De data moet Oslo-compliant worden gepubliceerd waar mogelijk, maar de ruwe data moet ook behouden blijven voor flexibiliteit en toekomstige integraties.
7. Samenwerking en Feedback:
   • Het systeem moet het mogelijk maken om feedback van technische teams direct in te voeren, zodat onderhoud en andere acties goed gedocumenteerd worden.
   • Academici en andere geïnteresseerden moeten ook toegang hebben tot de data voor verder onderzoek en inzicht.

Oefening 2

Instructies

Wie wanneer contacteren? Welke type van communicatie gaan we hebben met de gebruikers en in welke scenario? Hoe verzamel je de contactpersonen? Hoe kan je een goede opvolging implementeren?

Voorbeeld:

·Contact persoon x moet gecontacteerd worden in geval een erosiepoel is overstroomd om efficiënte en snelle ontruiming te voorzien?

Output

Notificaties, communicatie en procesflow

Eerste melding: 75% vulling en neerslag voorspeld

Melding als poel overstort

Melding als poel aan schoonmaak toe is

Afhankelijk van voorspelde impact - voorbeeld poel in buurt van veel kritische infrastructuur

Een opt-in voor verschillende soorten meldingen (inschrijven wie wil)

GDPR

Status van afhandeling van alerts. Als er actie moet ondernomen worden, moet er kunnen aangeduid worden dat het ontvangen is en in verwerking door die persoon of dat team. Dus alerts leven ook op een desk waar status aanpassingen, comments en doorverwijzingen mogelijk zijn.

Burgemeester

Brandweer

De Lijn (als er bus passeert)

Omwonenden

Riool-beheerder

Valkuil: hoe spamming/te veel aan berichtjes vermijden.

bvb "be alert"

Proces ?

bvb "bin" (buurt informatie netwerken) via de politie

Ramp- coördinator

Technische dienst

Politie

Provincie

Ploeg van wacht als eerste contact bvb ?

Zou hiervoor standaard technologie gebruiken zodat je ontwikkeling en onderhoud minimaliseert. Je hoeft dan enkel configuratie te doen en je kan zowel emails, SMS, ... sturen als ook pompen aansturen of andere acties automatiseren. Bijvoorbeeld GeoEvent Server

Alert voor stroomafwaarts liggende buurtbewoners indien kans op overlopen poel (en indien relevant natuurlijk)

Koppeling met BE-Alert

Afhankelijk van urgentie een ander kanaal. Niets is zo storend/ineffectief als een kanaal met overbodige alerts waar geen acties aan gekoppeld moeten worden.

Hoogdringend: gsm

Belangrijk maar geen onmiddellijke actie: email

Om in de achtergrond in de gaten te houden: dashboard specifiek voor monitoring

proces uittekenen wie krijgt wat wanneer en hoe (welke kanaal)?

Opsplitsing wie men op de hoogte brengt  in functie van evolutie  situatie metingen in poel.

Discussie

1. Proactieve Meldingen:
   • Het systeem moet niet alleen reactief zijn maar ook proactief meldingen sturen bij gevaren, zoals modderstromen.
   • Burgemeester en andere relevante personen moeten notificaties ontvangen via WhatsApp of SMS.
2. Contactinformatie en GDPR:
   • Bepaal wie wanneer gecontacteerd moet worden.
   • Overweeg hoe contactinformatie wordt bijgehouden en voldoe aan GDPR-regelgeving.
3. Meldingscriteria:
   • Meldingen moeten gestuurd worden bij overschrijding van bepaalde drempelwaarden (bijvoorbeeld hoeveelheid neerslag).
   • Verschillende soorten meldingen vereisen specifieke responsen, zoals schoonmaak van een overstortende poel.
4. Betrokkenen en Communicatiekanalen:
   • Naast de burgemeester moeten ook noodplanningsambtenaren via mail of WhatsApp op de hoogte worden gesteld.
   • Betrokkenen kunnen onder andere de technische dienst, brandweer, politie, en omwonenden zijn.
   • Gebruik van bestaande systemen zoals BE-Alert en buurtinformatienetwerken.
5. Overdaad aan Informatie Vermijden:
   • Voorkom dat er te veel informatie wordt gestuurd naar betrokkenen, wat kan leiden tot informatie-overload.
   • Zorg voor duidelijke afspraken over wie wanneer verantwoordelijk is voor welke acties.
6. Opvolging en Statusbeheer:
   • Het systeem moet de status van meldingen kunnen bijhouden (ontvangen, in verwerking, etc.).
   • Gebruik een dashboard voor statusaanpassing, opmerkingen en doorverwijzingen.
7. Procesuitwerking:
   • Werk een duidelijk proces uit voor wie wanneer welke melding ontvangt via welk kanaal (GSM voor dringende zaken, e-mail voor minder dringende zaken, dashboard voor monitoring).
8. Gebruik van Bestaande Technologie:
   • Gebruik bestaande technologieën en platforms om meldingen te versturen en acties te automatiseren.
   • Zorg voor koppelingen met databanken voor contactinformatie (bijv. burgemeesters) om configuratie te vergemakkelijken.

Oefening 3

Instructies

Hoe ga je data beheren/gebruiken eens dat je deze gecapteerd hebt via de verschillende databronnen? Hoe lang wil je de data bijhouden? Hoe vaak moet de data verzameld worden (frequentie)? Wie neemt de verantwoordelijkheid voor data? Hoe er voor zorgen dat data juist geïnterpreteerd wordt? Welke profielen/rollen zullen met de data werken? Hoe zorgen we voor continuïteit bij ingebruikname van bvb nieuwe sensoren?

Voorbeeld:

-De milieu ambtenaar die voorheen geen data had, wilt nu kunnen inloggen op het dashboard om de ruwe data te downloaden voor analyses te kunnen doen

-Je hebt een data ingenieur nodig van data captatie tot ontsluiten van de data

Output

Databeheer en gebruik

Bestaande IoT platformen

Zelf een dataplatform bouwen is overkill. Er zijn voldoende bestaande dataplatformen waar oa integratie met sensoren al aanwezig is alsook de storage koppelingen en de ontsluiting naar dashboards, LDES-server, etc...

opkuisen/validatie van de data is belangrijk (zowel door iemand met technische achtergrond in sensoren als lokale terreinkennis)

data altijd bijhouden (belangrijk academisch maar ook om te leren uit operationeel beheer)

Bestaande real time batch processing tools?

gevalideerde data mee ontsluiten via bestaande platformen ? bv waterinfo waar info over GOG's staat  ? DOV met info over erosiepoelen en sedimentvangen, .... ? Zo kan je onderscheid maken tussen een operationaal platform dat real-time wordt gebruikt en archief met gevalideerde metingen via andere platform

Databeheer moet door één partij gebeuren dewelke enkel de relevante behoudt die voor toekomstige simulaties/gebeurtenissen bruikbaar zijn (goede data governance afspraken)

Kosten vs snelheid vs volume

Data verwijderen is niet nodig. Blobstorage is goedkoop. Enkel mss een strategie over snel toegankelijke data en historische offloading naar blob storage voor minder snel toegankelijke data

operationeel : realtime (snelheid belangrijk)

inzichten : belangrijk dat de data gevalideerd is (om zo tijdsreeksen te kunnen opmaken bvb)

Ruwe data van sensoren is wss onbruikbaar voor ambtenaar, meer nood aan al licht verwerkte en leesbare data. Bijv. al de sensoren die waterstand meten naar 1 datamodel mappen -> deze data beschikbaar stellen aan ambtenaar (aggregatie van de data, of standaardmodel, leesbare KPIs)

Bestaande scalable

Cloud gebaseerde data storage oplossingen? ?

De meest relevante en éénduidige data bijhouden, zoals KMI bvb doet. => bundelen in front office

Gert Verstraeten

context data en metadata (bvb locatie)

modderpoel met zijn eigen 'id' krijgen die met de sensoren data meegestuurd worden

datastandaarden - afspraken, bijvoorbeeld tijdsnotatie, Mogelijkheid aanduiden kwaliteit van data (in plaats van gewoon verwijderen),

niet gemakkelijk om door de techniekers te laten aanpassen

Historische semi-ruwe data (na een eerste verwerking naar standaard model)  is belangrijk voor AI dus mag niet gedelete worden.

Erosiepoelen zijn in de DOV gestockeerd (of alvast zeer veel)

GIS platformen gebruiken voor spatiale analyse , integratie met spatiale databases

Termen als Datawarehouses and Datalakes worden vernoemd. Ook Lakehouse bekijken? (best of breed ?)

Denken dat een 'platform' een oplossing is. Kwestie van semantiek misschien eerder 'Data componenten oplossing'?

Functieprofielen/rollen

Data eigenaar

Data engineer

Data analist

Data scientist

Dashboard/ visualisatie expert

tegen hackers die alarmen uisturen of pompen laten starten

Cybersecurity expert

Dataplatform beheerder

DPO (enkel voor GDPR data natuurlijk)

Toegangs- en rollen-beheerder

Financieel verantwoordelijke

Technische architect

Product Owner, Implementatie ProjectManager, Data Scientist,

Datamodel expert

Data strategist ?

Discussie

1. Data management: De discussie concentreerde zich op het belang van data management, inclusief data input, beheer, verwerking, en ontsluiting.
2. Data governance: De verantwoordelijkheid voor data, inclusief de vraag wie de eigenaar is, en het belang van goede data governance-afspraken.
3. Dataopslag en -beheer: Er werd gesproken over het bijhouden van historische data, het beheren van verschillende soorten data, en het gebruik van blob storage voor minder snel toegankelijke data.
4. Dataplatformen: Discussies omvatten het overwegen van bestaande dataplatformen versus het bouwen van een eigen platform, integratie met andere platforms, en de functionele en technische vereisten van een dataplatform.
5. Rollen en verantwoordelijkheden: Verschillende rollen werden besproken, waaronder data engineers, data scientists, data-analisten, en de rollen van een DPO (Data Protection Officer) en financieel verantwoordelijke.
6. Technische aspecten: De technische architectuur van het dataplatform, inclusief data warehouses, data lakes, en het concept van een 'lakehouse', werd behandeld.

Oefening 4

Instructies

Welke zijn de valkuilen waar we volgens jou rekening mee moeten houden?

Formuleer enkele basisprincipes waaraan de oplossing moet voldoen

Voorbeeld:

•Te veel dashboarden waardoor je geen overzicht meer hebt

•Complexe dashboard

•Verantwoordelijkheid van data

Output

Valkuilen	Principes
Geen spaghetti integraties
Goede afspraken duurzame databeheer (verantwoordelijkheid)
teveel informatie die niet meteen begrijpbaar zijn voor de gebruiker: goede selectie maken van wat relevant is om te tonen aan elk doelpubliek + goede metadata beschrijving.
Zorg voor opleiding van eindgebruikers
onderhoud van het materiaal - te lange periodes met 'no data' of met onrealistische data wegens problemen met de sensoren kunnen vertrouwen ondermijnen	goede opvolging noodzakelijk - feedback van lokale terreinbeheerders cruciaal - niet louter een data/IT project
Niet opvolgen kosten/baten lange termijn. TCO zicht. Ook kijken naar waar kan waarde gegenereerd worden, en welke schadekosten zijn vermeden. Bijvoorbeeld zeggen we dat goede grond wegspoelt, nu vangen we die (deels) op maar wat doen we ermee?
Afhankelijkheid van schaarse technische profielen op de markt
	Inkomende data op platform moet een eerste validatie krijgen,zodat fouten al in begin van de pipeline opgemerkt worden - Data quality checks : eerste lijn...
	Mogelijke principe: reeds ontwikkelde bouwstenen hergebruiken+ configuratie off the shelf functionaliteit bestaande technologiën, low code no code configuratie (reeds zelf  ontwikkeld-bestaande + technologiën,), configueren  en developen  enkel als 'bijkomende' capability
	Budgetten ifv retour hele systeem. Als door monitoring grote schade kan worden voorkomen dan zullen de budgetten te verantwoorden zijn.
	Dashboards kunnen een tree hebben, dus van overzicht naar detail via enkele klikken. (drill downs, slice/dice)
Na kantooruren geen service van dataplatform	helpdesk 24/7 ?

Discussie

1. Complexiteit van Dashboards: Te veel informatie op dashboards kan leiden tot verwarring en gebrek aan overzicht, waardoor gebruikers de gegevens niet goed begrijpen.
2. Verantwoordelijkheid van Data: Juridische aspecten rondom verantwoordelijkheid voor data in het geval van problemen moeten duidelijk zijn om mogelijke problemen te voorkomen.
3. Budgetten en Leveranciersafhankelijkheid: Het beheer van budgetten en de afhankelijkheid van externe leveranciers zijn cruciale factoren die het succes van het project kunnen beïnvloeden.
4. Datakwaliteit en Validatie: Het belang van datakwaliteit en het instellen van datavalidatieprocessen om fouten in de gegevens te voorkomen.
5. Gebruikersacceptatie en Change Management: Het anticiperen op weerstand tegen verandering en het implementeren van effectief change management om ervoor te zorgen dat gebruikers het nieuwe systeem omarmen.
6. Technische Capaciteiten en Talent: De beschikbaarheid van technisch talent en de afhankelijkheid van schaarse technische profielen op de markt kunnen uitdagingen vormen voor het project.
7. Duurzaamheid en Onderhoud: Het plannen van duurzame databeheerpraktijken en het garanderen van continuïteit en onderhoud van het systeem, inclusief het opzetten van serviceovereenkomsten en een helpdesk.

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?

1. Verwerking van de input van de brainstorm oefening.
2. Verder onderzoek en voorbereiding van de analyse.
3. 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