Als team werken we dag in dag uit aan het versterken van onze democratie door burgers en bedrijven actief te informeren en te betrekken bij (lokale) besluitvorming. Daarnaast streven wij ernaar de digitale dienstverlening te vereenvoudigen door informatie efficiënt te onderhouden en te hergebruiken via één digitale invoer.

Lees hier meer over in onderstaand document waarin onze visie en missie worden beschreven, over onze waarden als organisatie:

Of bekijk onderstaand filmpje waarin onze Missie en Visie meer in detail wordt uitgelegd:

Wat is LBLOD

Lokale Besluiten als geLinkte Open Data (LBLOD) is een programma. Het omvat alle ABB-projecten in kader van lokale besluitvoering, en gelinkte data (linked data).

Om ervoor te zorgen dat deze informatie open en gelinkt beschikbaar gesteld kan worden, hebben de partijen in het ecosysteem verschillende oplossingen bedacht en daar applicaties voor ontwikkeld.

Het doel van LBLOD

Lokale besluiten bevatten waardevolle authentieke gegevens voor iedereen.

• Als burger wil ik weten wanneer mijn straat ontoegankelijk is door werken.

• Als ondernemer wil ik weten aan welke verplichtingen ik moet voldoen.

• Als vereniging wil ik weten of en hoeveel subsidies ik kan krijgen.

• Als middenveld wil ik weten hoe lokale besturen hun cultuurbeleid vormgeven.

Door de gegevens in lokale besluiten gelinkt te publiceren, kunnen organisaties die gegevens gemakkelijker hergebruiken. Gelinkte gegevens zijn gestandaardiseerd, waardoor machines ze eenvoudig kunnen vinden en verwerken. Iedereen kan met de informatie in de lokale besluiten aan de slag dankzij LBLOD.

Een concreet voorbeeld: agentschappen en departementen van de Vlaamse overheid kunnen zelf de informatie die zij nodig hebben uit de gepubliceerde besluiten halen. Lokale besturen hoeven die niet telkens opnieuw op te sturen of aan te leveren.

De ruggengraat voor de producten en diensten voor ABB

Wat is linked open data?

Linked Open Data in mensentaal

Linked Open Data in mensentaal voor mensen die applicaties bouwen

Agentschap Binnenland Bestuur / Agency for Home Affairs

Actief in zes domeinen

• Lokale besturen

• Steden

• Brussel

• Gelijke Kansen

• Integratie en inburgering

• Vlaamse Rand

Opdracht

Binnen deze domeinen werken we aan:

• goed functionerende lokale besturen;

• sterke en duurzame steden;

• de ondersteuning van de Vlaamse aanwezigheid in Brussel en de banden tussen Brussel en Vlaanderen;

• gelijke kansen voor elke Vlaming;

• het dichten van de herkomstkloof in onze samenleving;

• de ondersteuning van het Vlaamse en groene karakter in de Vlaamse Rand.

Missie

Het Agentschap Binnenlands Bestuur bouwt mee aan duurzaam en democratisch samenleven in diversiteit door burgers en bestuur te verbinden en te versterken.

Visie

Het Agentschap Binnenlands Bestuur is een wendbare organisatie die het beleid inspireert en antwoorden aanreikt voor de bestuurlijke en maatschappelijke uitdagingen van vandaag en morgen.

Door het verder uitbouwen en aanwenden van onze kennis, onze expertise en ons netwerk willen we de referentie zijn voor burgers en bestuur.

Wij verbinden en versterken burgers en bestuur door:

• het bevorderen van gelijke kansen en het samenleven van burgers in diversiteit.

• een beleidskader en instrumenten aan te reiken die de relatie tussen burgers en bestuur bevorderen.

• in te zetten op de versterking van de bestuurskracht van lokale besturen, zodat taken op het meest burgernabije niveau kunnen worden uitgevoerd.

Waarden

• Samenwerking en wendbaarheid We vinden samen oplossingen, geloven in de kracht van samenwerking en staan open voor nieuwe uitdagingen.

• Vertrouwen & Integriteit We geven en verdienen vertrouwen en bevorderen integriteit.

• Openheid We geven duidelijke informatie, delen onze kennis en werken met transparantie.

• Besluitvaardigheid We zeggen wat we doen en doen wat we zeggen.

Een Semantisch Ecosysteem

De waarde die we leveren aan onze samenleving

Meer dan 300 lokale besturen in Vlaanderen schrijven elke dag beslissingen die waardevolle informatie bevatten. Wij willen ervoor zorgen dat zij, door gebruik te maken van linked open data, hun informatie en (juridische) documenten rechtstreeks kunnen publiceren, en directe gegevensuitwisseling mogelijk maken. We zorgen voor herbruikbare bronnen, zodat informatie kan doorstromen naar andere overheden & diensten, burgers, organisaties en bedrijven.

ABB biedt ondersteuning voor kwaliteit & efficiëntie, om die lokale overheden te versterken.

De oplossingen die we bouwen

Om die waarde tot leven te brengen, bouwen we diverse digitale oplossingen.

ABB biedt ondersteuning via hun helpdesk, geeft opleidingen en ontwikkelt relevante functionaliteiten die lokale besturen nodig hebben om efficiënt te communiceren en gegevens uit te wisselen met allerlei actoren.

Ontdek het ecosysteem en onze applicaties

Bijdragen

Agile ontwikkelen! Waarom?

Grote uitdagingen worden in kleine, concrete stappen ontwikkeld. Zo ontstaat er een constante flow en zien we het geheel groeien.

• Transparant overzicht houden op het werk

• Werken in behapbare blokken

• Voldoende en flexibel plannen

• Verantwoordelijkheden op de juiste plaats

Vaste cadans op drie niveaus

Product teams

Product teams hebben alle benodigde vaardigheden om elke Sprint waarde te creëren. Ze zijn dus multidisciplinair. Daarnaast is het Scrum Team zelfsturend en bepalen ze dus onderling wie wat opneemt.

Product Owner

• vertaalt de visie op het product naar functionele acties om zo de doelstellingen te garanderen;

• stimuleert het team om kwaliteitsvolle stories te definiëren en de backlog te prioriteren;

• maximaliseert samen met het productteam de waarde die gecreëerd wordt voor belanghebbenden;

• zorgt ervoor dat wat wordt opgeleverd voldoet aan de behoeften van de belanghebbenden;

• haalt waardevolle informatie op binnen en buiten de organisatie en bouwt daarvoor stabiele interne en externe netwerken op;

• past de technieken van agile product management en business analyse toe volgens de vooropgestelde kwaliteitsvereisten en procedures;

Ontwikkelteam

Product Manager

De Product Manager definieert op een strategisch niveau de visie voor de klanten op een product met als doel deze visie te vertalen naar een roadmap voor het product en oplossingen. Dit gebeurt in lijn met de overeengekomen normen in termen van tijd, kwaliteit en kosten.

• werkt nauw samen met een breed scala aan mensen om de behoeften van belanghebbenden te identificeren en de oplossingscontext te begrijpen;

• stimuleert en organiseert de samenwerking binnen het team zodat het product waarde creëert voor de belanghebbenden;

• ontwikkelt visie op het product, stelt een roadmap op en vertaalt deze in oplossingen waar het team verder aan werkt;

• boort nieuwe domeinen aan waarvoor het product waarde kan leveren;

• identificeert en contacteert potentiële gebruikers en integratie-partners;

• (optioneel) een PM kan ook verantwoordelijk zijn voor een oplossing waar zelf meer dan zijn/haar product bij betrokken is.

Business analist

De product manager kan de oplossingen op de product roadmap niet op zijn of haar eentje uitwerken en bepalen. Hij of zij kan hiervoor beroep doen op een business analist, die de beste business oplossing samen met anderen (designers, architecten, product owner) uitwerkt en hiervoor gebruik maakt van een methodiek en een set aan tools.

De business analist helpt dus mee om de high level oplossing te vertalen naar epics waarin de best mogelijke invulling van de oplossing op de product roadmap wordt uitgewerkt zodat ze kan worden uitgevoerd en - na oplevering - ook de vooropgestelde waarde realiseert.

Zodra de 'business probleemstelling' goed is begrepen en de best passende oplossing is gedocumenteerd, biedt de business analist verdere ondersteuning bieden tijdens het schrijven en bijwerken van de epics zodat ze (technisch) kunnen worden geimplementeerd en nadien de verwachte doelstellingen mee inlossen.

Communities of Practise (COP)

Ondersteunde rollen op Solution-niveau

Solution Manager

Bewaakt de effectieve waarderealisatie uit oplossingen door

• potentieel van oplossingen te verduidelijken o.b.v. input van andere stakeholders. Bijvoorbeeld door gebruik te maken van waardefiches, oplossingenfiches & impactmaps;

• stimuleren en ondersteunen van contact tussen projectteam en (eind)gebruikers;

• lanceren van oplossingen binnen en buiten ABB.

Treinbegeleider

• werkt nauw samen met de Product Owners en Product Managers om afstemming te stimuleren en begeleiden;

• zorgt dat de waardestromen en roadmap up-to-date en gekend zijn;

• organiseert en faciliteert belangrijke overlegmomenten (Centrale Planningsdag, Communities of Practises, Solution Stand-ups);

• organiseert periodieke retrospectieves en zorgt dat verbeteringen o.b.v. de inzichten tot stand komen;

• ondersteuning en eerste hulp bieden rond Agile werken van product- tot solution-niveau.

Andere rollen op Solution-niveau

• De manager Digitale Oplossingen incorporeert oplossingen in Solution Roadmap. Coördineert informatie, middelen en capaciteit zodat oplossingen ontwikkeld kunnen worden.

• De ICT architect bepaalt de architecturale roadmap en technologiestrategie. Binnen dit kader bewaakt die de beste fit van oplossing met technologie.

• De ICT directeur brengt mogelijke waardevragen uit de organisatie in en bewaakt de strategische alineëring.

De capaciteitscheck(s) die tijdens het IPI worden uitgevoerd, zijn een moment om informatie te verzamelen over de beschikbaarheid van teamleden tijdens de komende groeispurt. De check is nodig om te voorkomen dat teamleden "overgepland" worden in één of meerdere productteams waardoor frustratie ontstaat en uiteindelijk sprintdoelen niet worden gehaald. Een capaciteitscheck met de ontwikkelaars, ontwerpers en analisten wordt gevolgd door een capaciteitscheck met Product Managers en Product Owners op de dag voor de CPD. De uitkomst van de check is een overzicht van de beschikbare mandagen per teamlid per sprint. Deze info wordt vervolgens gebruikt om werkzaamheden te plannen tijdens de planningssessie van de CPD.

Voor de capaciteitscheck - georganiseerd door het solution niveau van Digiteam - bellen de PM's en/of PO's in om te overleggen met leden van het solution niveau. Zij deden voorafgaand met alle leveranciers (ontwikkelaars, designers, testers, ...) een check op beschikbaarheid/ budget voor de volgende groeispurt.

Definitie

Doel van de CPD

Planning

De groeispurt (planning)

Een groeispurt heeft steeds een duur van 10 weken. Het omvat vier ontwikkelsprints en een Innovatie en Planning Iteratie van telkens 2 weken. In de laatste week van de een groeispurt is er een Centrale Planningsdag (CPD) waar de doelen voor de volgende groeispurt wordt vastgelegd.

Door in periodes van 10 weken te werken is er voldoende focus om stappen te zetten maar niet te veel rigiditeit om met een steeds veranderende context om te gaan. Het geeft de ontwikkelteams een duidelijke focus voor 10 weken maar wel de mogelijkheid om met de volgende groeispurt in te spelen op (veranderde) prioriteiten uit de organisatie.

De methodiek van de groeispurt planning

Wat kunnen we wanneer doen? (Roadmap planning)

Bij de roadmap planning is de eerste invalshoek die van de oplossingen. Enkel voor de meest nabije groeispurten wordt verwacht dat deze oplossingen ook in epics zijn onderverdeeld.

Als je op de roadmap enkel kijkt naar de volgende groeispurt, dan heb je dus een overzicht van de epics waaraan in de volgende groeispurt zal gewerkt worden. Dat overzicht is het startpunt voor de groeispurtplanning.

Wat kunnen we wanneer doen? (Groeispurt planning)

Definitie

Op basis van de Roadmap planning hebben we nu een beeld van (de oplossingen en) de epics waaraan we in de volgende groeispurt willen werken. Dan is de volgende vraag of we kunnen inschatten wanneer we aan welke epic kunnen werken gelet op onze beschikbare middelen. We proberen met andere woorden een zo realistisch mogelijke planning te maken en voorspelbaarheid te creëren voor de komende 10 weken.

Die voorspelbaarheid is belangrijk om eventuele bottlenecks tijdig te ontdekken en om te vermijden dat we onrealistische engagementen aangaan ten aanzien van onze andere collega's en teams binnen het digiteam.

Methodiek

• aan welke epics we de komende 10 weken (4+1 sprints) verwachten te werken

• aan welke issues we in welke sprint verwachten te werken

Voor de epics waaraan gewerkt zal worden in de eerstvolgende sprints zal het nodig zijn om de epics uit elkaar te trekken in kleinere "hoopjes" werk die passen binnen een sprint (=issues). Dit vereenvoudigt het plannen in de sprintplanning.

Epics waarvoor het werk nog meerdere sprints in de toekomst ligt , kunnen vager omschreven blijven en moeten nog niet opgedeeld zijn in issues.

Bij deze oefening hanteren we de volgende principes:

• we mikken op maximale focus (aan zo weinig mogelijk epics / issues tegelijkertijd werken; maar eerder focus op een beperkt aantal epics en deze afwerken alvorens aan de volgende te beginnen.

• het bepalen van de volgtijdelijkheid / afhankelijkheden van en tussen de epics en issues is belangrijker dan het plaatsen van de epics en issues in de juiste sprint. De groeispurt planning is geen kalender met engagementen, maar onze best mogelijke (realistische) inschatting van de planning voor de volgende sprints.

• Naarmate we op de groeispurt planning verder vooruit kijken, daalt de mate van detail. Het werk dat gepland is voor de eerstvolgende sprint moet best tot op issue niveau gedefinieerd zijn; voor het werk dat gepland is om te starten in een van de latere sprints is het perfect aanvaardbaar wanneer dit nog niet volledig in issues is omschreven.

2026

Groeispurt 39: 29/12/25 - 6/03/36

• Sprint 1: 29/12/25 - 9/01/26

• Sprint 2: 12/01/26 - 23/01/26

• Sprint 3: 26/01/26 - 6/02/26

• Sprint 4: 9/02/26 - 20/02/26

• Sprint 5: 23/02/26 - 6/03/26 - (CPD op woensdag 4/03/26 en donderdag 5/03/26)

Groeispurt 40: 9/03/26 - 15/05/26

• Sprint 1: 9/03/26 - 20/03/26

• Sprint 2: 23/03/26 - 3/04/26

• Sprint 3: 6/04/26 - 17/04/26

• Sprint 4: 20/04/26 - 1/05/26

• Sprint 5: 4/05/26 - 15/05/26 - (CPD op woensdag 13/05/26 en donderdag 14/05/26)

Groeispurt 41: 18/05/26 - 24/07/26

• Sprint 1: 18/05/26 - 29/05/26

• Sprint 2: 1/06/26 - 12/06/26

• Sprint 3: 15/06/26 - 26/06/26

• Sprint 4: 29/06/26 - 10/07/26

• Sprint 5: 13/07/26 - 24/07/26 - (CPD op woensdag 22/07/26 en donderdag 23/07/26)

Groeispurt 42: 27/07/26 - 2/10/26

• Sprint 1: 27/07/26 - 7/08/26

• Sprint 2: 10/08/26 - 21/08/26

• Sprint 3: 24/08/26 - 4/09/26

• Sprint 4: 7/09/26 - 18/09/26

• Sprint 5: 21/09/26 - 2/10/26 - (CPD op woensdag 30/09/26 en donderdag 1/10/26)

Groeispurt 43: 5/10/26 - 11/12/26

• Sprint 1: 5/10/26 - 16/10/26

• Sprint 2: 19/10/26 - 30/10/26

• Sprint 3: 2/11/16 - 13/11/26

• Sprint 4: 16/11/26 - 27/11/26

• Sprint 5: 30/11/26 - 11/12/26 - (CPD op woensdag 9/12/26 en donderdag 10/12/26)

2025

Groeispurt 34: 13/01/25 - 21/03/25

• Sprint 1: 13/01/25 - 24/01/25

• Sprint 2: 27/01/25 - 7/02/25

• Sprint 3: 10/02/25 - 21/02/25

• Sprint 4: 24/02/25 - 7/03/25

• Sprint 5 - IPI: 10/03/25 - 21/03/25 - (CPD op donderdag 20/03/25)

Groeispurt 35: 24/03/25 - 30/05/25

• Sprint 1: 24/03/25 - 4/04/25

• Sprint 2: 7/04/25 - 18/04/25

• Sprint 3: 21/04/25 - 2/05/25

• Sprint 4: 5/05/25 - 16/05/25

• Sprint 5 - IPI: 19/05/25 - 30/05/25 - (CPD op dinsdag 27/05/25 en woensdag 28/05/25)

Groeispurt 36: 2/06/25 - 8/08/25

• Sprint 1: 2/06/25 - 13/06/25

• Sprint 2: 16/06/25 - 27/06/25

• Sprint 3: 30/06/25 - 11/07/25

• Sprint 4: 14/07/25 - 25/07/25

• Sprint 5 - IPI: 28/07/25 - 8/08/2025 - (CPD op woensdag 6/08/25 en donderdag 7/08/25)

Groeispurt 37: 11/08/25 - 17/10/25

• Sprint 1: 11/08/25 - 22/08/25

• Sprint 2: 25/08/25 - 5/09/25

• Sprint 3: 8/09/25 - 19/09/25

• Sprint 4: 22/09/25 - 3/10/25

• Sprint 5 - IPI: 6/10/25 - 17/10/25 - (CPD op woensdag 15/10/25 en donderdag 16/10/25)

Groeispurt 38: 20/10/25 - 26/12/25

• Sprint 1: 20/10/25 - 31/10/25

• Sprint 2: 3/11/25 - 14/11/25

• Sprint 3: 17/11/25 - 28/11/25

• Sprint 4: 1/12/25 - 12/12/25

• Sprint 5 - IPI: 15/12/25 - 26/12/25 - (CPD op woensdag 17/12/25 en donderdag 18/12/25)

2024

Groeispurt 28: 20/11/23 - 26/01/24

• Sprint 4: 2/01/24 - 12/01/24

• Sprint 5 - IPI: 15/01/24 - 26/01/24 - (CPD op donderdag 25/01/24)

Groeispurt 29: 29/01/24 - 5/04/24

• Sprint 1: 29/01/24 - 9/02/24

• Sprint 2: 12/02/24 - 23/02/24

• Sprint 3: 26/02/24 - 8/03/24

• Sprint 4: 11/03/24 - 22/03/24

• Sprint 5: 25/03/24 - 5/04/24 (CPD op donderdag 4/04/24)

Groeispurt 30: 8/04/24 - 14/06/24

• Sprint 1: 8/04/24 - 19/04/24

• Sprint 2: 22/04/24 - 3/05/24

• Sprint 3: 6/05/24 - 17/05/24

• Sprint 4: 20/05/24 - 31/05/24

• Sprint 5: 3/06/24 - 14/06/24 (CPD op donderdag 13/06/24)

Groeispurt 31: 17/06/24 - 23/08/24

• Sprint 1: 17/06/24 - 28/06/24

• Sprint 2: 1/07/24 - 12/07/24

• Sprint 3: 15/07/24 - 26/07/24

• Sprint 4: 29/07/24 - 9/08/24

• Sprint 5: 12/08/24 - 23/08/24 (CPD op donderdag 22/08/24)

Groeispurt 32: 26/08/24 - 1/11/24

• Sprint 1: 26/08/24 - 6/09/24

• Sprint 2: 9/09/24 - 20/09/24

• Sprint 3: 23/09/24 - 4/10/24

• Sprint 4: 7/10/24 - 18/10/24

• Sprint 5: 21/10/24 - 1/11/24 (CPD op donderdag 31/10/24)

Groeispurt 33: 4/11/24 - 10/01/25

• Sprint 1: 4/11/24 - 15/11/24

• Sprint 2: 18/11/24 - 29/11/24

• Sprint 3: 2/12/24 - 13/12/24

• Sprint 4: 16/12/24 - 27/12/24

• Sprint 5: 30/12/24 - 10/01/25 (CPD op donderdag 9/01/25)

2023

Groeispurt 23: 05/12/22 – 10/02/23

• Sprint 1: 05/12/22 – 16/12/22

• Sprint 2: 19/12/22 – 30/12/22

• Sprint 3: 2/01/23 - 13/01/23

• Sprint 4: 16/01/23 - 27/01/23

• Sprint 5 - IPI: 30/01/23 - 10/02/23 - (CPD op donderdag 9/02/23)

Groeispurt 24: 13/02/23 - 21/04/23

• Sprint 1: 13/02/23 - 24/02/23

• Sprint 2: 27/02/23 - 10/03/23

• Sprint 3: 13/03/23 - 24/03/23

• Sprint 4: 27/03/23 - 7/04/23

• Sprint 5 - IPI: 10/04/23 - 21/04/23 - (CPD op donderdag 20/04/23)

Groeispurt 25: 24/04/23 - 30/06/23

• Sprint 1: 24/04/23 - 5/05/23

• Sprint 2: 8/05/23 - 19/05/23

• Sprint 3: 22/05/23 - 2/06/23

• Sprint 4: 5/06/23 - 16/06/23

• Sprint 5 - IPI: 19/06/23 - 30/06/23 - (CPD op donderdag 29/06/23)

Groeispurt 26: 3/07/23 - 8/09/23

• Sprint 1: 3/07/23 - 14/07/23

• Sprint 2: 17/07/23 - 28/07/23

• Sprint 3: 31/07/23 - 11/08/23

• Sprint 4: 14/08/23 - 25/08/23

• Sprint 5 - IPI: 28/08/23 - 8/09/23 - (CPD op donderdag 7/09/23)

Groeispurt 27: 11/09/23 - 17/11/23

• Sprint 1: 11/09/23 - 22/09/23

• Sprint 2: 25/09/23 - 6/10/23

• Sprint 3: 9/10/23 - 20/10/23

• Sprint 4: 23/10/23 - 3/11/23

• Sprint 5 - IPI: 6/11/23 - 17/11/23 - (CPD op donderdag 16/11/23)

Groeispurt 28: 20/11/23 - 26/01/24

• Sprint 1: 20/11/23 - 1/12/23

• Sprint 2: 4/12/23 - 15/12/23

• Sprint 3: 18/12/23 - 29/12/23

• Sprint 4: 2/01/24 - 12/01/24

• Sprint 5 - IPI: 15/01/24 - 26/01/24 - (CPD op donderdag 25/01/24)

2022

Groeispurt 18: 20/12/21 – 25/02/2022

• Sprint 1: 20/12 – 31/12

• Sprint 2: 03/01 – 14/01

• Sprint 3: 17/01 – 28/01

• Sprint 4 : 31/01 – 11/02

• Sprint 5: 14/02 – 25/02

CPD: 24/02

Groeispurt 19: 28/02/22 – 06/05/22

• Sprint 1: 28/02 – 11/03

• Sprint 2: 14/03 – 25/03

• Sprint 3: 28/03 – 08/04

• Sprint 4: 11/04 – 22/04

• Sprint 5: 25/04 – 06/05

CPD: 05/05

Feestdagen:

• 18/04: Paasmaandag

Groeispurt 20: 09/05/22 – 15/07/22

• Sprint 1: 09/05 – 20/05

• Sprint 2: 23/05 – 03/06

• Sprint 3: 06/06 – 17/06

• Sprint 4: 20/06 – 01/07

• Sprint 5: 04/07 – 15/07

CPD: 14/07

Feestdagen:

• 26/05: OLH Hemelvaart,

• 06/06: Pinkstermaandag

• 11/07: Dag van de Vlaamse Gemeenschap

Groeispurt 21: 18/07/22 – 23/09/22

• Sprint 1: 18/07 – 29/07

• Sprint 2 : 01/08 – 12/08

• Sprint 3: 15/08 – 26/08

• Sprint 4: 29/08 – 09/09

• Sprint 5: 12/09 – 23/09

CPD: 22/09

Feestdagen:

• 21/07: Nationale Feestdag

• 15/08: OLV Hemelvaart

Groeispurt 22: 26/09/22 – 02/12/22

• Sprint 1: 26/09 – 07/10

• Sprint 2: 10/10 – 21/10

• Sprint 3: 24/10 – 04/11

• Sprint 4: 07/11 – 18/11

• Sprint 5: 21/11 – 02/12

CPD: 01/12

Feestdagen:

• 01/11: Allerheiligen

• 02/11: Allerzielen

• 11/11: Wapenstilstand

• 15/11: Dag van de Dynastie

Groeispurt 23: 05/12/22 – 10/02/23

• Sprint 1: 05/12 – 16/12

• Sprint 2: 19/12 – 30/12

2021

Groeispurt 13: 04/01/21 – 12/03/21

• Sprint 1: 04/01 – 15/01

• Sprint 2: 18/01 – 29/01

• Sprint 3: 01/02 - 12/02

• Sprint 4: 15/02 – 26/02

• Sprint 5: 01/03 – 12/03

CPD 11/03

Groeispurt 14: 15/03/21 –21/05/21

• Sprint 1: 15/03 – 26/03

• Sprint 2: 29/03 – 09/04

• Sprint 3: 12/04 – 23/04

• Sprint 4: 26/04 – 07/05

• Sprint 5: 10/05 – 21/05

CPD: 20/05

Feestdagen:

• 05/04: paasmaandag,

• 13/05: OLH Hemelvaart

Groeispurt 15: 24/05/21 – 30/07/21

• Sprint 1: 24/05 – 04/06

• Sprint 2: 07/06 – 18/06

• Sprint 3: 21/06 – 02/07

• Sprint 4: 05/07 – 16/07

• Sprint 5: 19/07 – 30/07

CPD: 29/07

Feestdagen:

• 24/05: Pinkstermaandag,

• 21/07: Nationale Feestdag

Groeispurt 16: 02/08/21 – 08/10/21

• Sprint 1: 02/08 – 13/08

• Sprint 2: 16/08 – 27/08

• Sprint 3: 30/08 – 10/09

• Sprint 4: 13/09 – 24/09

• Sprint 5: 27/09 – 08/10

CPD: 07/10

Groeispurt 17: 11/10/21 – 17/12/21

• Sprint 1: 11/10 – 22/10

• Sprint 2: 25/10 – 05/11

• Sprint 3: 08/11 – 19/11

• Sprint 4: 22/11 – 03/12

• Sprint 5: 06/12 – 17/12

CPD: 16/12

Feestdagen:

• 01/11: Allerheiligen

• 02/11: Allerzielen

• 11/11: Wapenstilstand

• 15/11: dag van de Dynastie

Groeispurt 18: 20/12/21 – 25/02/2022

• Sprint 1: 20/12 – 31/12

De sprintplanning is de eerste ceremonie van een sprint en vindt plaats op de eerste (werk)dag van een nieuwe sprint. Tijdens de sprintplanningsmeeting plant het scrum team samen met de scrum master en de product owner de aankomende sprint door de stories op de backlog (in Jira) te bespreken en in te schatten. Indien nodig licht de product owner items op de product backlog nog toe zodat iedereen deze begrijpt. (let wel: voorafgaandelijke kan er een backlog refinement gebeurd zijn met het team en kan het zijn dat de inhoud van de hoogst geprioriteerde user stories nog fris in het hoofd zit van de deelnemers en dus weinig extra uitleg behoeft).

De leden van het scrum team (designers, analisten, developers) stellen op basis van hun capaciteit en de prestaties in vorige sprints vast welke user stories zij oppakken. De lijst met geselecteerde user stories vormt de sprint backlog. Vervolgens formuleert het scrum team gezamenlijk een definitief sprintdoel dat een duidelijk antwoord geeft op de vraag: voor welke doelstellingen engageren we ons met het team tijdens de komende sprint?

Deelnemers aan de sprintplanning zijn (minimaal) de product owner - (lead) developers - designer - analist- scrum master.

Aan het werken in sprints - als onderdeel van een groeispurt- zijn bij ABB, zoals klassiek in de sprintwerking, een aantal vaste ceremonies verbonden.

In deze rubriek beschrijven we hoe de teams deze ceremonies invullen en wie er aan deel neemt.

Het doel van de backlog Refinement Meeting is om de hoogste prioriteit items in de product backlog te ontleden in user stories die geschikt zijn voor opname in de volgende sprint. Tijdens deze bijeenkomst neemt het team gezamenlijk de items bovenaan de product backlog en ontleedt ze in ‘goede’ user stories. Tijdens de backlog refinement vergadering bekijkt het team elk item om de beurt en bespreekt of het haalbaar is om in de volgende sprint op te nemen of dat het verder moet worden opgesplitst en/of verfijnd om het uitvoerbaar te maken in de volgende sprint.

Een belangrijke verantwoordelijkheid rust bij de Product Owner en de Scrum Master om als voorbereiding op deze vergadering - de backlog in juiste orde te zetten. Uiteraard kan vanuit het scrum team ook - voorafgaandelijk - backlog items klaargezet worden om te bespreken samen met de items bovenaan de backlog.

Deelnemers aan de backlog refinement meeting zijn - minimaal - de product owner, de (lead) developer(s), de designer en de scrum master.

1. PI-systeemdemo

2. Kwantitatieve en kwalitatieve meting

3. Retrospectieve en probleemoplossende workshop

Het uiteindelijke doel van de Inspect and Adapt workshop is om een routine aan te kweken waarbij de belangrijkste gebreken aan de toepassing via een verbeterstory de weg vinden naar de backlog voor de volgende groeispurt(s).

Naast het ontwikkelen van functionaliteiten is er ook nood aan andere activiteiten om een product(team) verder te laten groeien. Daarom zijn de laatste twee weken van een groeispurt steeds speciaal omdat het expliciet ruimte biedt voor ...

• Innovatie en experimenten

• Training

• Planningsactiviteiten voor volgende groeispurt

Wanneer? De Innovatie en Planning (IPI) iteratie gebeurt steeds op het einde van een Spurt.

Centrale Planningsdag - CPD

De centrale planningsdag is een essentieel terugblikmoment om terug te kijken naar de Groeispurt die eindigt en te plannen voor de volgende Groeispurt. Daarom vindt deze plaats tussen twee groeispurten in.

Het geeft tijd aan alle actoren in onze agile productontwikkeling om ...

• Delen van gerealiseerde oplossingen a.h.v. demo’s in een plenaire sessie.

• Afstemming tussen verschillende producten om tot gedeelde oplossingen te komen

Het programma van een CPD is gebaseerd op de onderdelen van het standaardprogramma dat binnen het Scaled Agile Framework wordt beschreven maar de activiteiten worden doorheen de volledige IPI verspreid. De belangrijkste finale afstemming gebeurt op een één dag.

Wanneer? De Centrale Planningsdag (CPD) gebeurt steeds tijdens de IPI op laatste donderdag van een Spurt.

Een user story mapping helpt je om user stories te ordenen in een zinvol model of patroon en om zodoende de functionaliteit van een systeem te begrijpen, en eventuele gebreken in de product functionaliteiten/ product backlog te achterhalen en daarna effectief releases te plannen die op het moment van release de best mogelijke waarde opleveren voor gebruikers. Het is met andere woorden een slimme techniek om hoofd-van bijzaak te onderscheiden in de productlog en op het juiste moment het best mogelijk in te spelen op gebruikersnoden.

User Story Mapping is de voorbije jaren een populaire techniek geworden voor het beheren van user stories dankzij de inspanningen van pionier Jeff Patton. Met de techniek kan je meerdere niveaus en dimensies voor een product backlog vastleggen ondermeer door de gebruikersbehoeften uit te splitsen als (gebruikersactiviteiten, gebruikerstaken), epics en user stories. Bij ABB wordt user story mapping doorgaans toegepast na de impact mapping en in voorbereiding van de planning op de Centrale Planningsdag. Het moet helpen om - binnen de beschikbare capaciteit voor de groeispurt en sprints - de meest waardevolle dingen te bouwen.

De story mapping wordt minstens 1 keer per groeispurt gedaan, ten laatste tijdens de IPI als voorbereiding van de volgende groeispurt en na de impact mapping. Deelnemers aan de story mapping zijn de product teams (PM, PO, Architect, Developer, Designer). Geinteresseerde business stakeholders zijn ook uitgenodigd om deel te nemen. De PM of PO (volgens afspraak in het product team) leidt de sessie.

Doel = klaar zijn voor de CPD

De techniek van Impact mapping helpt de productteams bij Digiteam ABB en hun belanghebbenden niet alleen om de product roadmaps te visualiseren, maar ook om uit te leggen hoe ‘deliverables’ aansluiten op de behoeften van gebruikers, en om te communiceren hoe gebruikersresultaten zich verhouden tot oplossingen op hoger niveau en waardeketens.

Voor deze oefening gebruiken we een techniek van impact maping, beschreven door Neuri Consulting LLP. Bij het maken en bijwerken van de impactmappings van een waardeketens denken de teams na over gedragsveranderingen die een grote impact zouden hebben op de gebruikers van de in de waardeketen betrokken product of producten. Vervolgens schrijven we ze op in de impactmap en groeperen we de impacts op actoren, persona's of gebruikerscategorieën met behulp van vertakkingen. Vervolgens voegen we per tak (impact per groep) deliverables toe die die gedragsveranderingen kunnen ondersteunen en streefdata die we nastreven om de impact te realiseren. Vervolgens nemen we de organisatiedoelen die door die impacts worden ondersteund op in de mindmap.

Waar vind je onze impact mappings?

Hoe een impact mapping maken?

Vertrek steeds vanuit een meetbare doelstelling voor de creatie van waarde. Vertak vervolgens naar de actoren die we moeten bereiken (en beinvloeden) om de doelstelling te realiseren. Schrijf vervolgens per actor op aparte vertakkingen uit welke impact we precies moeten bereiken om onze doelstelling te halen. Tenslotte bepalen we per impact concrete 'deliverables' die we moeten realiseren om de impact ook effectief te kunnen realiseren.

De roadmap

We plannen binnen ABB op basis van een rollende roadmap die ongeveer één jaar (5 groeispurts) vooruit kijkt.

Het opstellen en bijsturen van de roadmap is een continue gegeven: deze wordt elke groeispurt bijgestuurd in functie van de resultaten en ervaringen van de afgelopen groeispurt en eventuele bijkomende doelen of gewijzigde prioriteiten.

Methodiek Roadmap planning: een overzicht

Het opstellen van een roadmap gebeurt in essentie door het beantwoorden van een aantal vragen in een bepaalde volgorde. Deze worden hieronder besproken en vind je op MIRO ook in een schematische voorstelling.

Wat zijn onze strategische doelstellingen? (MJOP)

Definitie

Onze strategische doelstellingen worden slechts gedeeltelijk binnen het Digiteam bepaald. Ze zijn een combinatie van:

• de product visies / roadmap (hoe de PM's de toekomst van hun product zien)

• de visie / roadmap voor het ecosysteem

• het meerjaring ondernemingsplan (MJOP) van ABB dat de organisatiedoelstellingen van ABB en de beleidsdoelstellingen van de verschillende kabinetten omvat

• Beschikbare interne en externe financiering en de daaraan gekoppelde doelstellingen

• Andere Opportuniteiten om met andere partners samen te werken aan de uitbreiding en versterking van het ceosysteem

• ....

Methodiek

De doelstellingen worden geëxpliciteerd in het MJOP en bij de start van elke Centrale Planningsdag toegelicht om de context te schetsen waarbinnen gepland moet worden.

Wat moeten we doen om onze doelen te bereiken? (Impactmapping)

Definitie

De volgende stap is om te concretiseren hoe we de geformuleerde doelen kunnen bereiken. Dit is een opdracht die wel binnen het digiteam ligt.

Methodiek

Hiervoor kunnen we de techniek van de impactmapping gebruiken waarbij je doelstellingen kan vertalen in deliverables (oplossingen).

Wat moeten we eerst doen? (Roadmap Bord)

Definitie

Wanneer we weten welke oplossingen nodig zijn om een doelstelling te bereiken is de volgende vraag in welke volgorde we deze oplossingen best realiseren. Daarbij moet rekening gehouden worden met verschillende elementen:

• het belang / de urgentie van de verschillende doelstellingen

• de meerwaarde (belang / de urgentie) van de oplossingen

• de technische complexiteit / verwachte effort

• de onderlinge afhankelijkheden tussen oplossingen

• ....

Methodiek

Wat kunnen we wanneer doen? (Roadmap planning)

Definitie

Wanneer het duidelijk is welke oplossingen we in welke volgorde willen realiseren, is de volgende vraag of we kunnen inschatten wanneer we dan aan wat kunnen werken gelet op onze beschikbare middelen. We proberen met andere woorden een zo realistisch mogelijke planning te maken en voorspelbaarheid te creëren voor de toekomst.

Die voorspelbaarheid is belangrijk om eventuele bottlenecks tijdig te ontdekken en om te vermijden dat we onrealistische engagementen aangaan ten aanzien van onze andere collega's en teams binnen het digiteam en onze stakeholders.

Methodiek

We hebben een roadmap planning die elke groeispurt (10 weken) wordt geüpdatet en waarbij we inzichtelijk maken:

• aan welke oplossingen we het komende jaar verwachten te werken

• aan welke epics we de komende (2 tot 3) groeispurten verwachten te werken

Voor de oplossingen waaraan gewerkt zal worden in de eerstvolgende groeispurten zal het nodig zijn om de oplossingen uit elkaar te trekken in kleinere "hoopjes" werk die passen binnen een groeispurt (=epics). Dit vereenvoudigt het plannen in de groeispurtplanning.

Oplossingen waarvoor het werk nog verder in de toekomst ligt (3 of meer groeispurten in de toekomst), kunnen vager omschreven blijven en moeten nog niet opgedeeld zijn in Epics.

Bij deze oefening hanteren we de volgende principes:

• we mikken op maximale focus (aan zo weinig mogelijk oplossingen / epics tegelijkertijd werken; maar eerder focus op een beperkt aantal oplossingen en deze afwerken alvorens aan de volgende te beginnen.

• het bepalen van de volgtijdelijkheid / afhankelijkheden van en tussen de oplossingen en epics is belangrijker dan het plaatsen van de oplossingen en epics op een tijdslijn / kalender. De roadmap is geen kalender met engagementen, maar onze best mogelijke (realistische) inschatting van de planning voor toekomst

• Naarmate we op de roadmap planning verder vooruit kijken, daalt de mate van detail. Het werk dat gepland is voor de eerstvolgende groeispurt moet best tot op epic niveau gedefinieerd zijn; voor het werk dat gepland is om te starten binnen een halfjaar is het perfect aanvaardbaar wanneer dit enkel op het oplossingsniveau is omschreven.

Introduction

Doel

Gelinkt Notuleren is een webapplicatie die helpt met het opmaken en publiceren van agenda's, notulen en besluiten voor Lokale Besturen. De bedoeling van Gelinkt Notuleren is niet om rechtstreeks te concurreren met bestaande notulering-pakketten. Het doel van de applicatie is om te tonen dat notulen opstellen die verrijkt worden met linked open data mogelijk is, en om lokale besturen zonder notuleringpakket uit de nood te helpen.

Set-up

Datamodellen

Onderdelen

Gelinkt Notuleren bestaat uit modulaire bouwblokken die hergebruikt kunnen worden in andere applicaties.

Embeddable (Say Editor): een slimme tekstverwerker

De tekstverwerker is uitbreidbaar met verschillende plugins

Hergebruiken van informatie

Gelinkt Notuleren verzamelt kennis uit besluiten die lokale besturen maken. Deze kennis wordt vervolgens weer ter beschikking gesteld om te hergebruiken.

Publieke informatie sites

Een van de pijlers van de SAFe Lean-Agile Mindset is innovatie, maar het kan moeilijk zijn om tijd te vinden voor ideeën en verandering te midden van de drukte in de reguliere sprints. Daarom gebruiken we bij Digiteam - zoals veel organisaties die de SAFe structuur volgen - IP-iteraties voor onderzoeks- en ontwerpactiviteiten zoals hackathons. Er zijn twee eenvoudige regels voor hackathons: we werken bij voorkeur aan eenzelfde thema met verschillende groepen samengesteld uit leden van verschillende teams (cross-team). De teams demonstreren hun werk aan anderen aan het einde van de hackathon.

De sprint retrospective is een terugkerende bijeenkomst aan het einde van een Groeispurt en wordt gebruikt om te bespreken wat er goed en/of fout ging tijdens de vorige Groeispurt-cyclus en wat er verbeterd kan worden in de volgende Groeispurt. De sprint retrospective is een essentieel onderdeel van de (scaled) agile manier van werken. Bij Digiteam ABB hebben we afgesproken om een retrospective te doen aan het einde van vier sprints en niet aan het einde van elke sprint. Problemen die tijdens de sprint ontstaan en die een (zware) impact hebben op de samenwerking van de productteams of op hun efficiëntie worden uiteraard direct opgepakt door het team en de scrummaster(s) en wachten niet tot de retrospective bij de einde van de Groeispurt. Bijgevolg is ad hoc retrospective mogelijk.

Stappen in onze retrospectives

Stap 1: "Set the stage". Een retrospectieve is het meest effectief als iedereen in het team eerlijk is over wat goed ging en ook wat niet. Maak duidelijk waar de terugblik over gaat en hoe de retrospective praktisch zal verlopen.

(Stap 2: Opwarmen). Gebruik een kleine oefening om ervoor te zorgen dat iedereen minstens één ding zegt om op te warmen. bijv. Vertel wat je als ontbijt hebt gehad Vertel wat je favoriete vakantiebestemming is Beschrijf de laatste iteratie in slechts 3 woorden Stap 2: Verzamel gegevens via een sjabloon. Er zijn veel retrospectieve sjablonen beschikbaar op internet. Kies er een om de gegevensverzameling te structureren. bijv.

Vervolgens krijgt elke deelnemer de tijd om virtueel of fysiek post its te schrijven en op te plakken. We doen dit in real time zodat anderen kunnen zien wat er geplakt werd. Zo raken mensen met weinig inspiratie wellicht toch geinspireerd om gedachten te formuleren. Elk idee of elke gedachte is een post-it.

Stap 3: Inzichten genereren met de hele groep is de volgende stap. Begin met het identificeren van groepen en duplicaten, praat over wat er naar voren komt en wat kan helpen om het te verbeteren of te verhelpen.

Stap 4: Bepaal wat je moet doen door een korte lijst te maken met dingen om in gedachten te houden tijdens hun volgende sprint.

Applicatie

Gelinkt notuleren toont ook aan softwareleveranciers hoe aan de decretale verplichtingen te voldoen.

Functionaliteiten

Doel: ondersteunen, niet verstoren

Overzicht Notuleren

Algemene bouwblokken – onderdelen

Proces notuleren

Ontdek hoe wij notuleren mogelijk maken in Gelinkt Notuleren:

Code

Front-end

Applicatie

Handleiding (gitbook)

Binnen het productteam werken we - meer nog dan vóór de de pandemie - heel efficiënt en effectief (samen) op afstand. Alle sprint- en spurtrituelen die horen bij onze resultaatgerichte SAFE-werking, gaan digitaal door. Binnen en buiten vergaderingen is er ook voldoende ruimte en vertrouwen voor sociale interactie. Werktijd is ook nog nooit een issue geweest: iedereen is er op de momenten die nodig zijn of heeft afspraken gemaakt om eventuele afwezigheid op te vangen.

Hoewel er dus weinig of geen werkinhoud is die dit vereist, geven verschillende teamleden aan dat het wenselijk is om elkaar terug wat meer fysiek zien, bv. om samen te lunchen of koffie te drinken, elkaar eens in een andere omgeving echt spreken,... Alleen blijkt dat het niet evident is om elkaar te ontmoeten als iedereen op andere momenten op de werkvloer aanwezig. Bovendien zijn we sterk gegroeid waardoor een volledige terugkeer naar de vroegere situatie praktisch niet helemaal haalbaar is.

Om ervoor te zorgen dat we elkaar toch makkelijker tegen komen, proberen we volgende afspraken uit:

• We proberen zoveel als mogelijk op maandagen in Brussel te zijn en op vrijdagen in Gent.

• Minstens op de maandag van de tweewekelijkse rapportering blokkeren we ruimte in de agenda om samen te eten of samen een koffie te drinken.

In eerste instantie testen we dit vooral met de product managers en -owners, analisten, de leden van het solution team en andere collega's die over de producten heen werken. Wanneer ontwikkelaars, designers en testers nood hebben aan fysieke aanwezigheid en interactie, zijn zij uiteraard ook welkom. Uiteraard staat dit bijkomende regelingen binnen elk productteam niet in de weg.

We beseffen dat mensen minder productief kunnen zijn op dagen dat ze onderweg zijn. We hebben oog voor de impact die dat heeft op resultaten en stressniveau van individuele collega's. Open feedback is een belangrijke waarde binnen ons team en dat geldt hier ook: erover praten helpt om wederzijdse verwachtingen scherp te houden.

De sprint review of sprint demo meeting aan het einde van elke sprint gehouden. Deze informele bijeenkomst is bedoeld om terug te kijken op wat er behaald is en waar nodig de Product Backlog aan te passen. Bij deze meeting zijn ook alle belanghebbenden van het project aanwezig, die hier de kans hebben om feedback te geven. De sprint demo wordt elke laatste vrijdagnamiddag van de sprint gehouden en dit per product. De organisatie en moderatie is in handen van de scrum master.

Deelnemers aan de sprint demo zijn in essentie iedereen die bij de ontwikkeling van het product - als onderdeel van een of meerdere oplossingen - betrokken is. Dit betekent dus niet alleen de leden van het scrum team (developers, designer, analist, product owner en product manager, scrum master) maar ook product managers en product owners van andere producten, gebruikers van het product, business stakeholders, leden van het architectuurteam welkom zijn op de tweewekelijkse sprintdemo.

Elke eerste maandag van een sprint rapporteert de product owner/ product manager over het verloop van de vorige sprint op de Solution Stand-up. De rapportering wordt gedaan aan de hand van een status slide in een bepaalde template. Er wordt gerapporteerd over:

• is het sprintdoel gerealiseerd?

• zijn we nog on track om het groeispurt doel te realiseren?

• welke belangrijke inhoudelijke realisaties zijn er in de voorbije sprint (afgewerkt en begonnen maar niet afgewerkt)

• hoe zag de sprint burndown eruit en hoeveel story points werden gerealiseerd versus hoeveel waren er gepland?

• zijn er bepaalde issues of risico's waar de collega PM's en de Solution Stand-Up van op de hoogte moeten zijn?

De rapportering op de Solution Stand-up wordt in een plenaire sessie gedaan om iedereen zoveel mogelijk geinformeerd te houden. Meer en meer producten dragen samen bij aan een of meerdere waardestromen en de informatie uitwisseling tijdens een sprintrapportering is hier een belangrijke drijvende factor in.

Hoe?

De stand-up is een korte bijeenkomst (virtueel of fysiek) tijdens de lopende sprint op frequente basis (dagelijks tot enkele keren per sprint) waarin de deelnemers op beknopte wijze een antwoord geven op de volgende 3 vragen:

• Wat heb je sinds de vorige stand-up gedaan?

• Wat ga je doen tegen de volgende stand-up?

• Heb je vragen of problemen bij het uitvoeren je werk tijdens de sprint?

Tijdens de stand-up wordt in Jira het actieve sprintbord gebruikt.

Deelnemers aan de stand-up zijn minimaal de product owner, de (lead)developers, de designer, de analist en de scrum master. Bijkomend is het nuttig dat op bepaalde momenten ook de tester en de product manager deelnemen.

De verschillende product teams van het Digiteam ABB vullen de Daily Stand-up routine momenteel bewust op een andere manier in:

• Organisatieportaal: elke dag een stand-up, behalve op vrijdag, van 11:45 - 12:00

• Kalliope: elke woensdag en elke eerste vrijdag van de sprint is er een stand-up van 30 minuten

• Loket, Gelinkt Notuleren, Architectuurteam: de stand-up wordt samen met de backlog refinement gehouden op de eerste vrijdag van de sprint

De sprint

De sprint is de kleinste iteratie waarbinnen we plannen.

De Innovatie en Planning Iteratie

Naast het ontwikkelen van functionaliteiten is er ook nood aan andere activiteiten om een product(team) verder te laten groeien. Daarom zijn de laatste twee weken van een groeispurt steeds speciaal omdat het expliciet ruimte biedt voor ...

• Innovatie en experimenten

• Training

• Retrospectives

• Planningsactiviteiten voor volgende groeispurt

De methodiek van een sprintplanning

Het doel van ons ecosysteem is het vergemakkelijken van gegevensdeling. Dat impliceert dat we gegevens volgens het juiste openheidsniveau én beschermingsniveau moeten behandelen: het is dus belangrijk dat publieke data zo open mogelijk beschikbaar is en data die niet publiek mag zijn enkel gedeeld is volgens de regels die daarvoor gelden. Open data en gegevensbescherming gaan immers hand in hand: alleen wanneer we niet publieke data afdoende kunnen beschermen en kunnen vermijden dat deze onterecht gedeeld worden, creëren we vertrouwen om data te delen en open te stellen in het ecosysteem.

Het is dus voor de doelstellingen van ons ecosysteem cruciaal dat iedereen die binnen onze productwerking actief is, zich bewust is van de gegevens die ze verwerken en van de regels en procedures die gelden.

Openbaarheid van bestuur

Binnen het ecosysteem verwerken we veel bestuursdocumenten, waarvoor we verregaande openbaarheid ondersteunen.

Verwerking van persoonsgegevens

Bestuursdocumenten en databanken binnen het ecosysteem behandelen echter ook vaak persoonsgegevens. Tijdens het ontwikkelen en het beheren van onze producten in het ecosysteem zullen de verschillende rollen tijdens de uitvoering van hun taken dus ook persoonsgegevens verwerken.

Hiervoor gelden de regels uit de Algemene Verordening Gegevensbescherming (AVG) of General Data Protection Regulation (GDPR).

Over welke gegevens gaat het in het ecosysteem?

Onderstaande lijst toont welke persoonsgegevens de producten en gegevensstromen die in het ecosysteem actief verwerken, onder welke categorie deze vallen, wie de betrokkenen zijn, wat het doel is van de verwerking en welke juridische basis hiervoor geldt.

Wat doe je als medewerker in onze productwerking?

1. Zorg dat je weet wat de algemene principes en regels zijn.

Wanneer je concrete vragen hebt, aarzel dan niet om deze te stellen in jullie productteam. Maak dit bespreekbaar, zodat de groep ervan leert.

Als je er niet mee weg kan binnen het team, kan je altijd bij het solutions- en portfoliomanagement te rade gaan.

1. Zorg dat je weet wat de specifieke regels en procedures zijn.

Deze zullen te vinden zijn verderop op deze pagina.

Ook hier geldt: reach out als je iets niet begrijpt of niet weet hoe je met iets moet omgaan.

1. Denk bij de implementatie van functionaliteiten en gegevensstromen na over welk type gegevens het zijn

We werken in ons ecosysteem met bijna uitsluitend met semantische data standaarden. Dat wil zeggen dat we sowieso al goed nadenken over de data die we behandelen, de betekenis ervan, de structuur,…. Vergeet hierbij het element openheid en gevoeligheid niet!

Zorg ervoor dat dit geëxpliciteerd is van bij de start.

1. Denk vervolgens ook na hoe we best met de gevoelige(re) gegevens omgaan in de toepassing

Het is daarbij belangrijk om het juiste niveau van bescherming te vinden: uiteraard niet te weinig, maar ook niet teveel. Belangrijk is de doeltreffendheid van de gegevensbescherming voorop te stellen.

Wat moet ik doen als het mis gaat?

Bij een (mogelijk) veiligheidsincident geldt een strikte procedure.

1) Meldt zo snel mogelijk aan productmanager, solution manager of portfolio manager dat er een (mogelijk) incident is. Kies degene die voor jou op dat moment het snelst bereikbaar is. Idealiter doe je dit telefonisch. Als dat niet lukt, doe dat dan via een ander ‘snel’ chatkanaal en zorg dat je bevestiging krijgt van de betrokkene. Degene die je te pakken krijgt, zorg ervoor dat de ICT-directeur en de andere collega’s op solution niveau op de hoogte zijn.

Dit eerste bericht moet nog niet veel informatie bevatten. Het is vooral belangrijk dat er zo snel mogelijk een melding is.

Uiteraard is het nadien wel de bedoeling om zo snel mogelijk de nodige informatie over het incident (de feiten), de ernst en de impact ervan te verzamelen en door te geven (zie volgende stap)

2) Bij een incident meldt de ICT-directeur aan de Data Protection Officer en Administrateur-Generaal dat er een incident in onderzoek is. De Security Officer van het Digiteam bereidt met de ICT-directeur een feitenverslag en onze risico-inschatting voor. Dat doen ze op basis van info die ze van product managers of andere betrokkenen moeten krijgen. Aangezien de ICT-directeur verantwoordelijk is voor wat onder aansturing van Digiteam gebeurt, bewaakt hij de kwaliteit van verslag en risico-inschatting.

3) De ICT-directeur stuurt onze inschatting door aan de Data Protection Officer en Administrateur-Generaal voor een gezamenlijke beslissing rond acties.

4) Als er communicaties volgen in de afwikkeling van incidenten, dan ziet de ICT-directeur toe op de inhoud daarvan, gezien de gevoeligheid van communicaties naar klanten, leveranciers of andere belanghebbenden.

De Data Protection Officer en Data Protection Officer-jurist mogen vroeg op de hoogte zijn, maar hun rol start pas actief na eerste feitenverslag en inschatting uit Digiteam.

Contactgegevens:

Solution Manager: Pieter Van Hastel (binnenkort)

Portfolio Manager: Veronique Volders

ICT-directeur: Pieter Lenaerts

Administrateur-Generaal: Jeroen Windey

Security Officer: Jeroen Mercelis

Data Protection Officer: Yves Andriessen

Doel

Context/ aanleiding

Voorbeelden van velden die je op dit moment standaard kan invoegen in een formulier:

Code

Front-end

Back-end

Services, script and tooling

Evolutie

De Formbuilder POC evolueerde in 2023 van een alpha versie naar een eerste volwaardige productversie waarmee talrijke formulieren werden gebouwd. Om de formbuilder als product of technische component verder te ontwikkelen werd een apart product team samengesteld. Het team werkt momenteel aan een tweede versie van de Formbuilder.

Microsoft Teams

Microsoft Teams wordt gebruikt als het centrale communicatiemiddel voor online communicatie. Alle klassieke agile scrum 'ceremonies' worden gehouden met behulp van Microsoft Teams (o.a. sprintplanning, stand-up, Backlog Refinement, Sprint demo's) evenals de Groeispurt Voorbereidingsactiviteiten zoals Impact- en Story Mapping, Spurt Planning en Spurt Retrospectives.

Verder gebruiken een aantal producten Teams Channels om efficiënt te communiceren over bepaalde relevante onderwerpen met betrekking tot het bouwen, testen, vrijgeven en bedienen van de applicatie(s).

Sharepoint

Sharepoint wordt gebruikt om administratieve zaken van de werking en documenten die persoonsinformatie bevatten goed en veilig te capteren. Bijvoorbeeld de aanwezigheidskalender en contracten worden op deze manier bijgehouden.

Miro

Wij gebruiken Miro voor verschillende doeleinden. Productteams houden zich op verschillende momenten bezig met Impact Mappings en Story Mappings. Tijdens de Centrale Planningsdag stellen we de productplanning op Spurt-niveau op met behulp van een Miro-bord voor elk product. Tijdens de IPI wordt Miro ook gebruikt om Spurt retrospectives uit te voeren waar nodig.

Sommige productteams maken nog meer gebruik van Miro en bereiden ook productroadmaps en productreleases voor in Miro.

Diagram tools

Vandaag zijn er online toepassingen die in de browser werken en bestanden kunnen openen van of opslaan naar jouw computer.

Deel diagrammen van deze tools altijd met collega's via Sharepoint of versiecontrolesysteem.

Vermijd aub diagrammen in Visio. Visio is een dure licentie die ABB bovenop de standaard software paketten moet betalen.

Figma

De prototypetool Figma wordt gebruikt voor het ontwerpen van gebruikersinterfaces en gebruikerservaringen. Het stelt de productteams in staat om in realtime samen te werken aan gebruikersinterfaces: het helpt ons om relevante schermen voor gebruikers te ontwerpen en het helpt ons om zo goed mogelijk te beschrijven hoe de schermen moeten werken voor het scrum (dev) team dat de pagina's gaat bouwen . Vervolgens helpt het het testteam om de relevante informatie te krijgen over wat te testen zonder lange documenten te hoeven lezen die de gebruikersinterface en gebruikerservaring beschrijven.

Gitbook

Het platform Gitbook wordt door het Digiteam ABB gebruikt voor het beheren en delen van relevante informatie voor externe partners van het team die mee werken aan de bouw en het gebruik van het semantische ecosysteem van toepassingen en data. Het bevat technische en functionele informatie over de verschillende toepassingen en producten met als doel de instap voor externe partners zo laag mogelijk te maken en de zelfredzaamheid van deze partijen zo hoog mogelijk te maken.

Naast bovenstaande informatie bevat het Gitbook platform ook nog relevante informatie over de werking van het Digiteam om nieuwe (externe) mederwerkers vlot operationeel en in het team geintegreerd te krijgen.

Feature Passports

Een Feature Passport bevat alle informatie om een bepaalde functionaliteit van een product te berschrijven. Zo zorgen we ervoor dat iedereen begrijpt wat we gaan bouwen en wat de status daarvan is.

Inspiring books & studies on working together

Toezicht

Melden van publicatie van besluiten en overzichtslijsten (op hun webtoepassing). In kader van Bestuurlijk Toezicht.

Kader

Opgelegd voor Decreet Lokaal Bestuur; verplicht via LLB (BVR Communicatie).

Toekomst

Voor wie

Gemeente, OCMW, Disctrict, Provincie, AGB, APB, OCMW-verenigingen, IGS’en, HVZ & PZ

Wordt ontsloten naar

Interne databank Toezicht & Kalliope.

Berichtencentrum

Opsturen van opvragingen en kennisnames (ikv Bestuurlijk Toezicht) via Kalliope.

Kader

Opgelegd voor Decreet Lokaal Bestuur; verplicht via LLB (BVR Communicatie)

Voor wie

Gemeente, OCMW Disctrict, Provincie, AGB, APB, OCMW-verenigingen, IGS’en, HVZ & PZ

Wordt ontsloten naar

Kalliope

BBC-DR

Toesturen van digitale financiële documenten uit de boekhoudpakketten die horen bij bepaalde besluiten. Moet de toezichthouder in staat stellen budgetten, jaarrekeningen en meerjarenplannen goed te keuren.

Kader

Opgelegd voor Decreet Lokaal Bestuur; verplicht via LLB (BVR Communicatie).

Voor wie

Gemeente, OCMW (wordt geleidelijk aan opgenomen in gemeente), Disctrict, Provincie, AGB, APB, OCMW-verenigingen, IGS’en (sommige)

Wordt ontsloten naar

Qlikview via Management File Transfer

Mandatenbeheer

Ingeven en beheren van mandaten bij besturen

Kader

Opgelegd voor Decreet Lokaal Bestuur.

Voor wie

Gemeente, OCMW, Disctrict, Provincie

Wordt ontsloten naar

Leidinggevendenbeheer

Ingeven en beheren leidinggevende functies

Kader

Opgelegd voor Decreet Lokaal Bestuur; verplicht via LLB (BVR Communicatie)

Voor wie

Gemeente, OCMW Disctrict, Provincie, AGB, APB, OCMW-verenigingen, IGS’en,

Wordt ontsloten naar

Personeelsbeheer

Beheren van personeelsgegevens: aantal werknemers en voltijds equivalenten.

Kader

Gegevens nodig voor beleid (Comite C1).

Voor wie

Gemeente

Wordt ontsloten naar

Enkel intern gebruik

Subsidiebeheer

Volg aanvragen voor subsidiemaatregelen op.

Kader

/

Voor wie

Gemeenten, later meer.

Wordt ontsloten naar

Voorlopig enkel intern gebruik.

Bedienarenbeheer

Volg wijzigingen van de bedienaar van de eredienst op.

Kader

/

Voor wie

Besturen van de eredienst

Wordt ontsloten naar

Organisatieportaal, Kalliope, voor intern gebruik.

Mandatenbeheer Erediensten

Volg wijzigingen van de bestuursleden van de eredienst op.

Kader

/

Voor wie

Besturen van de eredienst

Wordt ontsloten naar

Organisatieportaal, Kalliope, voor intern gebruik.

Doel

Concept

Architectuur

Setup

Datamodellen

Beleidsdomein MOW implementatiemodel en vocabularia

Verkeersborden

Besluit mobiliteit

Code

Front-end

Applicatie

Feature Passports

Algemene feature passports voor LBLOD:

Vind specifieke feature passports voor het Register van Maatregelen hier

Actoren

Medewerkers van de secretarie Verrichten administratief werk voor de publieke organisatie, zoals de gemeente of het openbaar centrum voor maatschappelijk welzijn.

Algemeen directeur De algemeen directeur staat in voor de algemene en coördinerende leiding van de diensten van de gemeente en van het openbaar centrum voor maatschappelijk welzijn. De algemeen directeur realiseert samen met zijn medewerkers de decretale en wettelijk voorgeschreven taken en beleidsobjectieven.

Agenda

Agendapunt in concept / ontwerpbesluit Een (mogelijks nog aan te vullen of aan te passen) ontwerp voor het besluit dat uit dit agendapunt zou voortkomen.

Interne agenda Een agenda (mogelijks nog aan te vullen of aan te passen), die intern kan worden nagekeken.

Ontwerpagenda Een agenda (mogelijks nog aan te vullen of aan te passen), die voor de zitting gepubliceerd wordt naar zowel de raad als naar de burger.

Aanvullende agenda De ontwerpagenda kan na publicatie nog herzien worden. Na herziening wordt deze opnieuw gepubliceerd als aanvullende agenda. Ook deze kan nog aangevuld worden.

Spoedeisende agenda Agenda met punten aangebracht door de raad tot net voor de zitting.

Code

Front-end

Back-end

Services, scripts & tooling

Nieuwe besturen

Nieuwe besturen hebben een goedkeuring nodig van ABB, toegang tot het gebruikersbeheer van het facilitair bedrijf en het loket, en een connectie met Kalliope zodat tweewegscommunicatie kan gebeuren en ABB dossieropvolging kan doen.

Om dat te laten gebeuren, doen we het volgende:

• We verwachten een goedkeuringsbeslissing van het Agentschap Binnenlands Bestuur over het nieuwe lokale bestuur.

  • ABB verwittigt het loket voor Lokale Besturen.

• Dan kan het bestuur toegang vragen via het Gebruikersbeheer aan het Facilitair Bedrijf

  • ABB, de product manager van het loket, geeft verificatie en vraagt de OVO aan. Dit wordt teruggekoppeld, samen met de typering.

  • Hierna wordt connectie gemaakt met het KBO

• Er wordt een unieke code aangemaakt om het bestuur mee te identificeren, die we een URI noemen (Unique Resource Identifier)

  • Die wordt zowel gebruikt voor het Loket als in Kalliope, om dossieropvolging en tweewegscommunicatie mogelijk te maken.

Gebruikersbeheer & Inloggen

• Het gebruikersrecht dat gebruikt wordt om in te loggen voor het Loket voor Lokale Besturen is "Loket Lokaal Bestuur Gebruiker".

• Per gebruiker kan ingesteld worden welke modules ze zien. De keuze bestaat momenteel uit: Toezicht, berichtencentrum, leidinggevenden, mandatenbeheer, personeelsbeheer, BBC-DR, subsidies. Dit kan later nog uitgebreid worden.

• Er bestaan drie gebruikersbeheren per doelgroep:

  • Vlaamse Overheid​

  • Economische actoren​

  • Lokale Besturen.​ De doelgroepverantwoordelijke voor Lokale Besturen is ABB.

Het verloop van de agenda

Concept agenda*

Nadat de agendapunten werden voorbereid worden deze bezorgd aan de secretarie om te agenderen. De agenda wordt over het algemeen voorbereid door een medewerker van de secretarie en/of de algemeen directeur. Daarna wordt deze nagekeken en aangevuld door de algemeen directeur.

*Dit is geen officiële term. Deze term wordt hier gebruikt om het proces te duiden.

Ontwerpagenda

De ontwerpagenda wordt voor de zitting gecommuniceerd naar de raad en gepubliceerd naar voor de burger. Deze agenda kan nog aangepast of aangevuld worden.

Aanvullende agenda

De raadsleden kunnen nog agendapunten aanbrengen tot enkele dagen voor de zitting. Deze wordt dan opnieuw gecommuniceerd en gepubliceerd als aanvullende agenda.

Spoedeisende agenda

Tot net voor de zitting kunnen de raadsleden nog agendapunten aanbrengen. De spoedeisende agenda wordt ook gecommuniceerd en gepubliceerd als aanvullende agenda.

Communicatie & Publicatie

Communicatie naar raadsleden

De ontwerpagenda, aanvullende agenda en spoedeisende agenda [Hulp nodig; wordt de spoedeisende altijd op voorhand nog gecommuniceerd, of is dat optioneel?] worden gecommuniceerd naar de raadsleden. Dit gebeurt over het algemeen door een medewerker van de secretarie of algemeen directeur, via het softwarepakket of per mail. Digitale communicatie wordt aangemoedigd.

Externe communicatie

Hoe werkt het in GN?

Bekijk hoe het werkt in Gelinkt Notuleren

Rollen

Voor het agenderen heb je de rol schrijver nodig.

Via Gelinkt Notuleren kunnen de mensen die geen schrijfrechten nodig hebben, maar wel de agenda nakijken, met de rol lezer de geagendeerde agendapunten bekijken.

Locatie

Binnen Gelinkt Notuleren maak je een agenda aan binnen een zitting – dus deze moet eerst aangemaakt worden. Je vult de informatie in van de zitting die je op voorhand ter beschikking hebt:

Vervolgens worden de agendapunten die werden voorbereid toegevoegd aan de zitting.

Eerst wordt het agendapunt gelinkt aan de zitting. Vervolgens wordt er een titel en een beschrijving (optioneel) toegevoegd aan de zitting voor dat agendapunt. Deze titel en beschrijving worden gebruikt bij het publiceren van de agenda's. Deze titel en beschrijving mogen verschillen van de titel en beschrijving van het agendapunt zelf. De titel in het agendapunt zelf worden gebruikt bij de besluitenlijst, de notulen en de uittreksels.

Openbaarheid

Status

Vanaf het moment dat een agendapunt geagendeerd wordt en gekoppeld aan een zitting, wordt de status geagendeerd toegevoegd aan het agendapunt, en kan je het aan geen andere zitting meer toevoegen.

Context

Een lokaal bestuur bereidt agendapunten – ook dossiers of ontwerpbesluiten genoemd – apart voor. Dat gebeurt door de bevoegde dienst(en) binnen dat lokaal bestuur. Het gebeurt ook dat medewerkers van de secretarie agendapunten die geen specifieke kennis vereisten voorbereiden, zoals de goedkeuring van de notulen van de vorige zitting.

[Hulp nodig: kloppen de mensen die betrokken zijn?]

Bestuursorganen

De agendapunten worden voor verschillende bestuursorganen voorbereid. In de applicatie log je in als medewerker van een Gemeente, OCMW of Provincie. [Hulp nodig: district ook? missen er organen of eenheden?]

• Gemeente

  • Gemeenteraad

  • College Burgemeester & Schepenen (CBS)

  • Burgemeester

  • Autonoom Gemeentebedrijf (AGB)

• OCMW

  • Bijzonder comité

  • Vast Bureau

• Provincie

  • Provincieraad

  • Deputatie

  • Autonoom Provinciebedrijf (APB)

Inhoud agendapunt

Hoe werkt het in GN?

Bekijk hoe het werkt in Gelinkt Notuleren [Hulp nodig: aparte pagina aanmaken?]

Rollen

• Lezer kan alle agendapunten bekijken.

• Schrijver kan alle agendapunten bekijken en bewerken.

Locatie

In Gelinkt Notuleren kunnen dossiers voorbereid worden in de tab Agendapunten. Het is ook mogelijk om rechtstreeks een zitting aan te maken en daar agendapunten toe te voegen – maar dat is minder flexibel.

Agendapunten die verdaagd werden kunnen gekopieerd worden, zodat ze niet opnieuw opgebouwd moeten worden.

Status

Er zijn 3 statussen

• Concept Het agendapunt is in voorbereiding, maar werd nog niet aan een zitting gekoppeld. Het agendapunt kan ten allen tijde aangepast worden.

• Geagendeerd Het agendapunt werd in een voorbereiding van een zitting opgenomen. De agenda kan nog veranderen, en het agendapunt kan nog aangepast worden.

• Gepubliceerd Het agendapunt werd gekoppeld aan een zitting, en deze werd gepubliceerd. Het agendapunt kan niet meer aangepast worden.

In deze fase is enkel Concept van toepassing.

Sjablonen

Wanneer je start met een nieuw agendapunt, start je met een van de 2 generieke sjablonen aan: besluiten (met een stemming) en vrije tekst. Voorbeelden van agendapunten:

• Besluiten

  • Goedkeuren van notulen

  • Reglementen

  • Verordeningen

  • Mededelingen [Hulp nodig: of vrije tekst?]

• Vrije tekst

  • Discussiepunten

  • Varia

Stijl

We bieden 2 stijlen aan voor besluiten:

• Nieuwe stijl: gebruikt rubrieken om bevoegdheden, juridische context en motivering te scheiden. Sommige besturen gebruiken nog extra rubrieken, maar wij maken hier geen verder onderscheid.

• Klassieke stijl: gebruiken "gelet op" en "overwegende dat" om juridische context en motivering te scheiden.

Informatie zitting vervolledigen: zitting

De context waarin de agendapunten behandeld worden kan nu meegegeven worden.

[hulp nodig: in deze context secretaris of algemeen directeur?]

Verloop van de zitting vervolledigen: behandeling van agendapunt

Vervolgens worden per agendapunt aanwezigen, stemmingen en het besluit ingegeven worden. Er kunnen meerdere stemmingen per agendapunt gehouden worden.

Hoe werkt het in GN?

Bekijk hoe het werkt in Gelinkt Notuleren

Rollen

• Lezer kan alle agendapunten bekijken.

• Schrijver kan alle agendapunten bekijken en bewerken.

Locatie

In Gelinkt Notuleren kunnen dossiers voorbereid worden in de tab Agendapunten. Het is ook mogelijk om rechtstreeks een zitting aan te maken en daar agendapunten toe te voegen – maar dat is minder flexibel.

Status

Vanaf het moment dat een een zitting gepubliceerd wordt, kan je het niet meer van de zitting ontkoppelen, en krijgt het agendapunt de statusgepubliceerd .

Agendapunten die verdaagd werden kunnen gekopieerd worden, zodat ze niet opnieuw opgebouwd moeten worden.

Bekijk de mandaten in een bestuur. Deze data komt in deze databank terecht via

Code

Set-up

Front-end

Back-end

Microservices, scripts and other modules

Services connected to Loket

Services connected to the RDFa-editor

Doel

Het organisatieportaal is de toegangspoort tot informatie over organisaties en personen die ABB contacteert. Via het organisatieportaal kan je verschillende authentieke databronnen met betrekking tot organisatiegegevens van lokale besturen aanspreken – allemaal op één plek. Het platform maakt connectie naar interne producten en applicaties, om de informatiestromen beter in de hand te houden.

Doelpubliek

Modules/ Componenten in het Organisatieportaal

We hebben op dit moment twee manieren om gegevens te exploreren, opgedeeld in twee onderdelen: organisaties en personen. De volgende cases werden toegepast op erediensten.

Organisaties

Deze bestaan uit publieke organisaties zoals bestuurseenheden, bestuursorganen, formele organisaties en algemene organisaties.

Voorbeelden voor informatie omtrent lokale besturen en meer specifiek erediensten:

Publieke organisaties, zoals Bestuurseenheden: Autonoom gemeentebedrijf, Autonoom provinciebedrijf, Bestuur van de eredienst, Centraal bestuur van de eredienst, Dienstverlenende vereniging, District Gemeente, Hulpverleningszone, OCMW, OCMW vereniging, Opdrachthoudende vereniging, Polders, Politiezone, Projectvereniging, Provincie, Watering, Welzijnsvereniging

Bestuursorganen: Gemeenteraad, College van Burgemeesters en Schepenen, Provincieraad, Raad van Bestuur, Centraal Bestuursorgaan, Eredienstenbestuursorgaan, ...

Formele organisaties, zoals Geregistreerde organisaties: Ondernemingen (Vennootschappen, Verenigingen, Stichtingen), Representatief Orgaan, ...

Algemene organisaties: Feitelijke verenigingen, zonder winstuitkering, ...

Personen

U kan de posities van een persoon binnen de verschillende organisaties terugvinden, zoals leidinggevenden, mandatarissen, bedienaren, ...

Voorbeelden voor informatie omtrent lokale besturen en meer specifiek erediensten:

Posities binnen verschillende organisaties: Penningmeester, Secretaris, Bedienaar, Expert, Vertegenwoordiger van rechtswege, …

Leidinggevenden: Algemeen directeur, Adjunct algemeen directeur, Financieel directeur, Adjunct financieel directeur, Leidend ambtenaar, Griffier, Financieel beheerder …

Mandatarissen: Burgemeester, Aangewezen burgemeester, Schepen, Toegevoegde schepen, Voorzitter Bestuurslid …

Opbouw

Generiek opzet

Het organisatieportaal heeft een aantal basisgegevens, core gegevens, die elke organisatie en persoon heeft, bijvoorbeeld:

Personen: kerngegevens (naam, geboortedatum, ...), posities bij organisaties, contactgegevens per positie

Organisaties: kerngegevens (naam, type, status, ...), vestigingen, veranderingsgebeurtenissen, verbonden organisaties, leidinggevenden, mandatarissen, ..

Aangepast traject

Naargelang de noden voor de contactgegevens die nodig is per organisatie en workflow, kunnen er zowel verschillende types organisaties en gegevens gekoppeld worden.

Bijvoorbeeld, in kader van erediensten werden volgende organisaties gekoppeld: Bestuur van de eredienst Centraal bestuur van de eredienst, betrokken bestuursorganen, representatieve organen.

Omgeving

Handleidingen

Code

Draag hier bij aan onze applicaties, en bekijk onze datamodellen [EN]:

Fase 4: Ondertekenen

Zowel de agenda, besluitenlijst, notulen als uittreksels dienen ondertekend te worden.

Men kan digitaal ondertekenen via Gelinkt Notuleren. De ondertekening verloopt op basis van de identiteit van de bevoegde personen. Deze personen loggen in via ACM-IDM, en kunnen dan eenvoudigweg ondertekend worden door op "onderteken" te klikken.

Fase 5: Publiceren & Melden van Besluitenlijst, Notulen en Specifieke besluiten

Per document lopen hier verschillende termijnen:

• Agenda: publicatie 8 dagen voor de zitting

• Besluitenlijst: publicatie en melding 10 dagen na de zitting

• Notulen: publicatie en melding na goedkeuren op de volgende zitting

• Afhankelijk van het besluittype worden er nog andere agendapunten apart gepubliceerd en gemeld. Deze hebben verschillende termijnen.

[Hulp nodig: termijnen]

Hoe werkt het in Gelinkt Notuleren

Publiceren

Melden

Melden kan automatisch gebeuren via een leverancier, semi-automatisch via Gelinkt Notuleren (met nazicht) of manueel via het loket:

Goedkeuring notulen

In de volgende zitting worden de notulen van de vorige zitting goedgekeurd (of de zitting erna, indien er nog aanpassingen dienen te gebeuren).

Uittreksels

Er zijn bepaalde documenten, zoals omgevingsvergunningen, die nog voor het goedkeuren van de notulen aan bepaalde partijen bezorgd kunnen worden. Het is mogelijk om deze apart te ondertekenen, publiceren en te melden.

Hier kan men ook expliciet een print van maken in Gelinkt Notuleren.

Doel

Lokaal Beslist is een online tool die agendapunten van Vlaamse lokale besturen samenbrengt op 1 centrale plek. Dat maakt het voor de burger gemakkelijk om te begrijpen waar lokale besturen mee bezig zijn en welke beslissingen ze nemen. Lokaal Beslist maakt de lokale besluitvorming transparanter en vergroot de betrokkenheid van burgers. Als lokale mandataris kan je met Lokaal Beslist ontdekken hoe andere gemeenten uitdagingen aanpakken en innovatieve oplossingen implementeren.

Visie en Ambitie

De informatie in de applicatie is niet altijd even volledig. In de komende maanden en jaren zullen we nauw samenwerken met lokale besturen en hun leveranciers om meer en betere informatie beschikbaar te stellen. We willen samen met burgers en lokale besturen de functionaliteit en bruikbaarheid van Lokaal Beslist optimaliseren. Zo zal de applicatie steeds beter aan alle behoeften voldoen. Programma's als Gemeente Zonder Gemeentehuis en Lokaal Beslist helpen alvast aanzienlijk om de kwaliteit en de maturiteit van gegevensuitwisseling tussen overheden te verbeteren. De oefening moet nog even vol gehouden worden om de vruchten ervan te kunnen plukken.

Voor wie?

Design/ Concept

Hoe werkt de applicatie?

Code

De Embeddable is een bouwsteen van Gelinkt Notuleren. Het is een slimme, open-source tekstverwerker die specifieke informatie uit notulen verrijkt met data, op een gestructureerde manier, zodat we achteraf die informatie kunnen extraheren en hergebruiken.

Externe notuleringpakketten die lokale besturen helpen met het opstellen van notulen, kunnen deze embeddable ook hergebruiken in hun software pakket om de data te extraheren.

We bieden deze tekstverwerker aan als embeddable (eenvoudig inplugbaar) voor die besturen of hun software leveranciers kunnen gebruiken in hun notuleringpakketten. We stellen deze embeddable ook open onder de naam van Say Editor voor eender wie die hun tekstverwerking willen verrijken met kennis.

Bouwblokken

De embeddable bestaat uit verschillende bouwblokken die gelinkt notuleren mogelijk maken.

Databronnen.

Wij gebruiken meerdere gegevensbronnen om notulen en besluiten te verrijken:

• De Vlaamse Codex – verwijzingen naar de rechtsgronden in beslissingen.

• Mandaten – om aanwezigen bij te houden, te benoemen en te ontslaan.

• Leidinggevenden – om aanwezigen bij te houden.

Functionaliteiten & Plugins

We hebben aparte kleine apps gemaakt die in de teksteditor kunnen worden gestopt:

• Toolbar: basisfuncties voor tekstbewerking.

• Sjablonen: om het makkelijker te maken om te beginnen met noteren.

  • In de toekomst zullen we ook een sjablonenbouwer maken, waar besturen en overheden zelf hun sjablonen kunnen samenstellen.

• Citaten plugin: maakt gebruik van de Vlaamse Codex – om te verwijzen naar juridische gronden in beslissingen.

• Stemming: stem over beslissingen.

• Aanwezigen: volg wie deel uitmaakte van de vergadering, en deel uitmaakt van bepaalde beslissingen.

• Import – export: beslissingen kunnen geïmporteerd en geëxporteerd worden (in uitvoering).

• Annotaties: annoteer tekst met specifieke gekoppelde informatie, zoals mandaten.

• Ondertekenen: ondertekenen van notulen, uittreksels, agenda's, besluitenlijsten.

• Anonimiseren: verwijder persoonlijke informatie voor publieke weergave.

Code

Embeddable

Microservices, plugins en scripts

Tutorial: je eigen slimme tekstverwerker

Voeg zelf de slimme tekstverwerker toe aan je ember applicatie:

Documentatiesite Say-Editor

Doel

Met de Module Toezicht doelen we op de interne besluitendatabank Toezicht voor medewerkers van het Agentschap Binnenlands Bestuur. Via deze databank zijn alle besluiten terug te vinden die door de lokale besturen gemeld of ingezonden werden via het Loket voor Lokale Besturen.

Deze databank bestaat om gegevensdeling binnen de Vlaamse overheid te versoepelen. Zo worden er ook connecties gelegd met Vlabel en Vlaams Huis Verkeersveiligheid (MOW).

Code

Set-up

⚠️Voor Toegankelijk Vlaanderen wordt er geen gebruik gemaakt van ACM-IDM, het gebruikersbeheer.

Front-end

Back-end

Microservices and scripts

Shared microservices with Loket and other applications

Bekijk de leidinggevenden in een bestuur.

Deze informatie komt momenteel uit:

Code

Set-up

Front-end

Back-end

Applicatie

Zoek naar gelinkte en gepubliceerde agenda's, besluiten en notulen van een bestuur:

Deze informatie komt momenteel uit:

Doel

De applicatie Gelinkt Notuleren maakt het mogelijk om dat te doen, en publiceert de informatie hier. Lokale besturen kunnen op hun website linken naar deze pagina.

Code

Set-up

Front-end

Back-end

Microservices & Scripts

Doel

Het loket voor lokale besturen is een digitale manier voor communicatie tussen Lokale Besturen in Vlaanderen en het Agentschap Binnenlands Bestuur.

Om dat mogelijk te maken, bouwen we het loket zo op:

• De communicatie wordt opgebouwd als een beveiligde zending (vaststelling tijdstip van verzending en aflevering van communicatie) – volgens het BVR 20/04/2018​

• Het loket werd modulair opgebouwd, per type communicatie, om eenvoudig onderscheid te maken en toegang te geven.

• Werd gebaseerd op semantische formulieren – die het mogelijk maakt om data open en gelinkt te delen.

Visie & Ambities

• Digitale gegevensuitwisseling tussen lokale besturen enerzijds en de bredere centrale (Vlaamse) overheid anderzijds.​

• Gemakkelijke gegevensdeling vanuit de lokale besturen door open data uit lokale besluiten (LBLOD) – met als doel efficientiëwinst voor lokale besturen.

• Informatie op een gebruiksvriendelijke manier ter beschikking stellen aan (Vlaamse) overheidsinstanties zodat zij deze makkelijk kunnen verwerken/behandelen.​

Voor wie: Lokale Besturen

• Gemeente

• OCMW

• Autonoom Gemeentebedrijf (AGB)

• OCMW-vereniging (welzijnsvereniging)

• Intergemeentelijke Samenwerkingsverbanden (IGS) Intercommunale, Dienstverlenende Vereniging, Opdrachthoudende Vereniging, Projectvereniging

• Districten

• Provincie Autonoom Provinciebedrijf (APB)

• Hulpverleningszone (HVZ)

• Politiezone (PV)

• Erediensten

Voor wie niet

• Watering & Polders

Verschillende modules en hun doeleinden

Hoe werkt de applicatie

Code

Set-up

Front-end

Back-end

Microservices and scripts

Shared microservices with Gelinkt Notuleren

Shared microservices and scripts with Kalliope

Shared microservices with Toezicht and other applications

Handleding

Doel

We willen ontwikkelaars een instrument aanreiken waarmee ze efficient en snel 'slimme formulieren' - dit wil zeggen formulieren die eens ingevuld correcte Linked Open Data genereren - kunnen samenstellen.​

Doelpubliek

Ontwikkelaars in product teams (van Agentschap Binnenlands Bestuur en bij uitbreiding in andere Vlaamse agentschappen) die veelvuldig formulieren voor toepassingen bouwen of onderhouden.

Visie en ambitie

De visie en de ambitie sluit nog steeds aan bij de initiele gedachte achter de Proof of Concept die destijds met het product team van het Loket Lokale Besturen werd gerealiseerd, namelijk formulieren modulair opbouwen uit herbruikbare componenten om de bouw en het onderhoud van talloze formulieren te vergemakkelijken.

Onderdelen van de formulierenbouwer

Code tab

Op het tabblad Code Builder vindt een gebruiker aan de rechterkant de code die achter een bepaald formulier zit. Aan de linkerzijde van de tab ziet hij of zij de visuele weergave van deze code. Dit tabblad wordt voornamelijk gebruikt door de ontwikkelaars. Zij kunnen de code hierop aanpassen.

Form builder tab

Op dit tabblad kan de gebruiker (die geen ontwikkelaar is) formulieren maken door het volgende toe te voegen: 1. Secties , 2.Velden (met verschillende veldtypes: invoer, tekstgebied, numeriek, data, url,...) 3. Tabellen en 4. Lijsten.

Validaties tab

Dit onderdeel wordt gebruikt om validaties op formulieronderdelen te beheren. Het wordt zowel door ontwikkelaars als 'gewone' gebruikers van de Formbuilder gebruikt.

Hoe werkt de applicatie?

Code