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
Miro link
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
Miro link
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
Link 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.