VlocaSessie/74

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

1. Lokale besturen zetten in op bovenlokale samenwerking
2. Bereidheid van intercommunales en Vlaamse Overheid
3. Betrokken partijen zetten in op service management principes en tools
4. 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

1. Enkel capaciteit om in te zetten op belangrijkste doelgroepen voor lokale besturen.

Voorwaarden

1. Interne werking van de organisatie is voldoende matuur om informatie op een gestructureerde manier uit te wisselen
2. Voldoende bewustzijn bij de betrokken partner

De belangrijkste meerwaarde

1. Burger kan zijn meldingen ongeacht de context via een plaats naar keuze doorgeven
2. Heldere en verbeterde communicatie naar de burger door duidelijke afspraken rond beheer van meldingen
3. 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?

1. Besturen hebben reeds een digitaal loket waar feedback richting de burger kan worden voorzien
2. Er is nood aan een groter bewustzijn en bereidheid tot samenwerken tussen de verschillende partners
3. Alle communicatie wordt bijgehouden in service-software zodat deze kunnen geraadpleegd worden
4. Documenten moeten eenvoudig digitaal uitgewisseld kunnen worden

Belangrijke punten uit het model

1. Gebruik van verschillende service software bemoelijkt vlotte integratie
2. Regionale samenwerking bevorderdt structurele aanpak van bovenlokale noden
3. 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
Functionaliteiten werkgroep	Functionele werkgroep	2024-06-20	9u00-12u00	Teams
Applicatie componenten werkgroep	Functionele werkgroep	2024-09-11	13u00-16u00	Teams