VlocaSessie/45

Functionele werkgroep

Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de functionele noden en interacties. Na de data- en informatiewerkgroep zijn deze respectievelijke noden helder geworden. Deze functionele werkgroep bouwt hierop verder om de data- en informatie-uitwisseling tussen mensen en systemen, mensen onderling en systemen onderling te schetsen.

De tweede thematische werkgroep vond plaats op 16 mei 2024.

Context

Initiatief

In samenwerking met Mobiliteit en Parkeren Antwerpen en de Stad Antwerpen werkt VLOCA (Vlaamse Open City Architectuur) samen met OSLO (Open Standaarden voor Linkende Organisaties) aan een City of Things project genaamd "Citerra". Citerra staat voor 'City Environmental Regulations and Rights for Access' voor steden, gemeenten, bedrijven, burgers, verenigingen en overheden , en heeft als doel de link te leggen tussen de genoemde stakeholders en de lokale regelgeving.

Het doel van Citerra is om alle regelgevingen te centraliseren en te uniformeren, waarbij de aanvragen voor vergunningen kunnen worden ingediend. De focus van dit City of Things traject ligt op vergunningen voor autoluwe zones of gebieden met cameratoezicht. Hoewel de Stad Antwerpen het project leidt, is het de bedoeling om dit initiatief breder te zien richting alle lokale besturen.

Op dit moment is de informatie over verschillende gereglementeerde zones in de stad niet goed georganiseerd, wat het voor burgers en bedrijven moeilijk maakt om te begrijpen welke regels waar van toepassing zijn. Het handmatig invullen van persoonlijke gegevens bij herhaalde aanvragen leidt ook tot frustratie. Om dit te verbeteren, streeft het project ernaar gebruikers zelf hun profiel te laten beheren, inclusief het toevoegen van extra nummerplaten, en om gegevens automatisch in te vullen bij nieuwe aanvragen. Bovendien voldoet het project aan de Europese Commissie Directive over "Intelligent Transport Systems" door steden te verplichten Urban Vehicle Access Rights (UVAR) data naar het Europese Platform te uploaden, wat geautomatiseerd zal verlopen.

VLOCA

VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. Meer informatie over VLOCA en onze werking kan je terugvinden op https://www.vlaanderen.be/lokaal-bestuur/digitale-transformatie/vloca/vloca-trajectbegeleiding-waarom.

VLOCA-model

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

ID	Samenvatting	Beschrijving
UC1	UC1: Registratie	Registratie
UC2	UC2: Informatieplatform	informatie platform en zoek opdrachten
UC3	UC3: Profiel & Formulier aanvullen	Profiel aan- en formulier invullen
UC4	UC4: Indiening	Indienen aanvraag
UC5	UC5: Opvolging dossier	opvolging dossier
UC6	UC6: toekenningsproces	toekenning, weigering, betwisting, advies aanvraag
UC7	UC7: dossierbeheer	beheer dossier (overzicht, toevoegingen, verlengingen, aanpassingen, herinneringen, …)
UC8	UC8: Message Center	CRM voor communicatie (uitgaande/inkomende, contact strategie en historiek)
UC9	UC9: Helpdesk	helpdesk & FAQ & Reviews
UC10	UC10: betaalmodule	betaalmodule en business model vinden en bouwen
UC11	UC11: Monitoring	Monitoring en analytische rapportering incl fraudedetectie
UC12	UC12: Inzichten	Rapporting BI Dashboards en Inzichten
UC13	UC13: Duurzaamheid	Van een piloot tot een 'operationeel' draaiende applicatie en platform

Tijdens de vorige sessie bespraken we de onderstaande figuur die het proces weergeeft van het aanvraagformulier:

Vandaag staan we stil bij het informatieplatform:

Hierbij willen we scherp stellen wat de verwachtingen zijn over een platform.

Brainstormsessie

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

Doel

Het doel van de brainstormsessie is het volgende:

• Zicht krijgen op welke data/informatie we nodig hebben om een antwoord te bieden aan de nood aan efficiëntie/tijdwinst en effectiviteit/optimalisering door middel van een centraal informatieplatform
• Oplijsten van databronnen waaruit je de informatie kan halen, welke applicaties en functieprofielen je nodig hebt
• Inzicht krijgen in wat je moet kunnen doen met de data
• Valkuilen identificeren

Oefening 1+2

Instructies

Bij deze oefeningen stonden we stil bij de volgende vragen:

1. Welke data/informatie hebben we nodig om een antwoord te bieden aan de nood aan efficiëntie/tijdwinst en effectiviteit/optimalisering door middel van een centraal informatieplatform?

Voorbeeld:

- Wetgeving van lokale besturen

2. Uit welke databronnen haal je deze informatie? Welke data is reeds beschikbaar (gratis of betalend)? Welke moeten we zelf gaan verzamelen? Hoe doen we dit? Welke applicaties (tools die je gaat gebruiken) heb je nodig om de databronnen te sturen/ondersteunen? Welke functieprofielen heb je hiervoor nodig?

Voorbeeld:

- Wetgeving van een lokaal bestuur bevindt zich  in een lokaal intern systeem

Output

Data	Databronnen	Applicaties/tools	Functieprofielen
Bestaande vergunningen	Standardisatie model/Uitbreidingen huidig model: voorwaarde van een goeie databron OSLO	vendors/applicaties van de gemeenten: veel vendors van de gemeentes hebben deze info al gepubliceerd (assumptie)	data
hoe wordt omgegaan met oa. hulp diensten / stad gemeenten (zit in de reglementen)	publicaties gemeentes (www)	loket.lokaalbestur	modelleerder met kennis besluiten / reglementen / OSLO
welke steden hebben welke vergunningen	vergunningenlijst per lok. bestuur	centrale vindplaats: applicaties die info en besluiten van de verschillende gemeentes centralisseerd ( lopend traject) - lokale gemeentes zouden dit ook kunnen gebruiken en minder zwaar  ipv API individueel maar er blijven beperkte API's	juridische dienst - LB-en
Contact gegevens van steden en gemeenten	Besluiten/Regelgeving	LDES: data ter beschikking stellen, op verchillende manieren query end point. Zorgt data data kan doorstromen	Mobiliteits dienst - LB-en
welke steden hebben welke systemen voor handhaving: steden hebben verdwijnpalen, andere gebruiken polities enzo - Kan ook zijn dat je badge nodig hebt naast vergunning	LPDC: Vlaanderen (catalagus def per gemeente)		agile team: po, pm, analist, dev,...)
regels/voorwaarden voor vergunning/stad	CRAB: adrespunt bepalen binnen polygoon	Bouwblokken waarmee oslo data worden gestuurd - door digitaal vlaanderen ontwikkeld	business user (lokaal bestuur)
GIS informatie autoluwe zones	GIS databronnen: polygonen, sommigen straten vallen er net in of uit ->  validatie		OSLO team standaard government
venstertijden: ter info als je geen vergunning nodig hebt want je kan uw houden aan de venstertijden	eGOV? - Wallet	Vrijer manier om data te consumeren	Leveranciers aanvraagsystemen: integraties en koppeling voorzien
welke steden hebben  autoluwe zones	DIV (voertuigen) via MAGDA		Beheerder/stad
waar liggen de autoluwe zones	Adressenregister /CRAB	Database gaat reproduceren bij wijzigingen  automatisch.  bv adressen enkel de wijzigen krijg je door zonder API call	IT verantwoordelijke voor support
EID/ITSme	MAGDA		Beheerder overkoepelend
Ondernemersloket	RRN via Magda IT20/IT19 (rijksregister op basis hiervan krijg je de domicile en huis)		testusergroup
Burgerprofiel	KBO via Magda
Kostprijs om vergunning aan te vragen	soc. nr en geldigheid zorgverstrekker VIA MAGDA (automatische vergunningen)	Burgerprofiel op header/notificatie / document niveau: aanvraag moet door goedkeuringproces ze een notificatie krijgen voor status en vergunning wordt opgeladen bij akkoord
wat kost een vergunning?	Vlaamse codex	SOLID? Persoonlijke data kluis -> gdpr -> Aligneren met die vlaamse bouwblok
Alternatieve Routes: visuele tip	LBLOD gepubliceerde reglementen en besluiten  (lokale belsuiten - machine leesbare kijken naar standaard - per bestuur gepubliceerd en Vlaanderen gaat dit ook verzamelen )	Simulatie tool
Informatie in verschillende talen	RIZIV	standaardisering
Overzicht regelgeving over gans Vlaanderen van de verschillende steden , europese, vlaamse, ... (Vlaamse codex)	DIV (via magda)	Citerra
simulatie van wat wel of niet mag na invoering van tijd en plaats - op basis van aangegeven tijstip en locatie de relevante info krijgen	signalisatie plan: voetgangersgebied - borden laten besluiten in gemeenteraad. Eersta stap om tot besluit komen waar komen de borden -> automatisch besluit
Machine readable policy: beleidsmatig best vertaald worden naar regels die door computer vertaald kunnen worden
Doorlooptijd aanvrager + VTEs (volgorde van belangrijkheid voor process automatisatie te bepalen - werkkracht die achter een bepaald proces moeten worden gezet => om zo makkelijk te zien waar je tijdswinst kan halen door optimaliseren of automatiseren) overheid	Visualiseren op basis van signalisatieplan (impact autoluwe zone) - maar vergunning pas toegekend als werken zijn uitgevoerd
Toegang voor derde partijen zoals navigatie applicaties	lokale vergunningen
Abstracties	database (voor kleinere steden/gemeentes niet makkelijk om API te voorzien) federaal? -> binnen ABB bezig om dit bechikbaar te maken voor lokale besturen . Lokale bron voor kleinere steden
& geconnecteerde delen (bv bewonersparkeren aantal vergunning is dynamsich - afhankelijk van de bewoners moet er parking voorzien worden en kan er geen vrije bewonerskaarten meer voorzien worden voor de bewoners van het app, bouwheer moet parking voorzien vooe gebouw ) identificeren -> automatisatie	FOD FAS
dummy aanvraagmodule: veel mensen willen oefenen voor ze een aanvraag officieel indienen. Kan ook via video's	authenticatie / authorisatie
heb ik eigenlijk wel een vergunning nodig? of ben ik vrijgesteld?	data space
soorten vergunningen	mobiliteit
Aanvraag via nummerplaat of op aanvrager opvolgen?
regel
Wat is kost retributie bij handhaving
Bulkaanvragen op basis van Asterix nummerplaten ( vaste serie van nummerplaten zoals politie bv)
voertuiggegevens

Discussie

• Besluitvorming over Vergunningen: Vaststellen van criteria voor vergunningsverlening en hoe deze criteria toe te passen om eerlijke en consistente beslissingen te waarborgen.
• Handhaving van Autoluwe Zones: Effectieve methoden voor handhaving, inclusief technologische systemen en menselijke handhaving, en hoe deze het beste kunnen worden geïmplementeerd en gecoördineerd.
• Automatisering van Aanvraagprocessen: Verminderen van administratieve lasten door het automatiseren van aanvraagprocessen en het verkennen van mogelijkheden voor efficiënte en gebruikersvriendelijke systemen.
• Toegang voor Derde Partijen: Overwegingen omvatten hoe informatie over autoluwe zones beschikbaar kan worden gesteld aan derde partijen zoals navigatie-apps, met aandacht voor privacy en veiligheid.
• Gebruiksvriendelijkheid van Aanvraagprocessen: Discussie focust op het verbeteren van de gebruiksvriendelijkheid van aanvraagprocessen om de drempel voor aanvragers te verlagen, mogelijk door middel van begeleiding en ondersteuning.
• Automatische Goedkeuring en Weigering van Vergunningen: Overwegingen betreffen de criteria en procedures voor automatische goedkeuring of weigering van vergunningen, en hoe dit kan bijdragen aan een efficiënter proces.
• Uniformiteit en Standaardisatie: Bespreking van de voordelen en uitdagingen van het standaardiseren van processen en informatie over autoluwe zones voor alle steden en gemeenten in Vlaanderen.
• Uitzonderingen en Flexibiliteit: Behandelen van uitzonderingen op het vergunningsbeleid en het integreren van flexibiliteit om maatwerk mogelijk te maken voor specifieke situaties.
• Noodzakelijke Databronnen: Er werd gesproken over het identificeren van databronnen die nodig zijn voor het vergunningenaanvraagproces, zoals gemeentewebsites, LBD (Lokale Producten Catalogus), Gis (Geografisch Informatiesysteem), e-government, Rijksregister, KBO (Kruispuntbank van Ondernemingen), CP (Contactpunt), etc.
• Automatisering van Vergunningsaanvragen: Er was discussie over het automatiseren van vergunningsaanvragen en hoe dit kan worden ondersteund door relevante databronnen, zoals het gebruik van machineleesbare besluiten en standaardisatie van processen.
• Signalisatieplannen en Besluitvorming: Er werd opgemerkt dat signalisatieplannen belangrijk zijn voor het bepalen van autoluwe zones en dat deze informatie moet worden gekoppeld aan besluitvormingsprocessen voor vergunningen.
• Lokale versus Federaal Databeheer: Er was discussie over het verschil in benadering tussen grote steden en kleinere gemeenten wat betreft het beheer van lokale vergunningendatabases en de mogelijke rol van federale instanties in het faciliteren van toegang tot deze data.
• Datamodellen en Lokale Centrales: Er werd gesproken over het ontwikkelen van datamodellen en lokale centrales om kleinere gemeenten toegang te geven tot relevante informatie, met een focus op het delen van gegevens tussen verschillende niveaus van bestuur.
• Applicaties en tools voor gegevensbeheer: Er wordt gesproken over verschillende tools en applicaties die worden gebruikt om gegevens te ondersteunen en te sturen, zoals Eldes voor linked data event streams.
• Centrale vindplaats voor informatie: Deze applicatie is bedoeld om informatie over besluiten van verschillende gemeenten te centraliseren en beschikbaar te stellen voor machines, mogelijk met behulp van gestandaardiseerde protocollen.
• Vendors en gemeentelijke applicaties: Er wordt verwezen naar de applicaties van zowel externe leveranciers als de gemeenten zelf, die mogelijk al informatie publiceren op gestandaardiseerde wijze.
• Gebruik van API's en centrale vindplaats: Er wordt besproken hoe een centrale vindplaats het gebruik van API's kan verminderen, maar toch mogelijk nog beperkte API-functionaliteit vereist voor specifieke taken.
• Burgerprofiel en notificaties: Er wordt gesproken over het gebruik van burgerprofielen en notificaties voor statusupdates van aanvragen of dossiers.
• Solid en persoonlijke datakluis: Er wordt overwogen hoe Solid en persoonlijke datakluisconcepten kunnen worden toegepast op de behandeling van persoonsgegevens, met inachtneming van GDPR-vereisten.
• Simulatietool en standaardisering: Er wordt gesproken over het gebruik van simulatietools en het belang van standaardisering in het proces.

Oefening 3

Instructies

Wat moet je kunnen doen met de data? Welke acties kan je identificeren qua databeheer?

Voorbeeld:

-Je brengt de wetgeving van de verschillende lokale besturen samen

Output

Databeheer & integratie

overschrijven van unieke bron gegevens (met label aangepast): bv domicile manueel overschrijven en aangeven dat dit niet een authentieke bron maar nieuwe info is

leesbare_txt generieke info_txt Voorwaarden_txt_xml Couleurlocal_parameters_txt_xml Attesten.pdf_xml types data die beschikbaar moeten zijn en samengevoegd moeten worden in een formulier

samenvoegen van data in formulier en dan alles samen doorsturen. 1 API met alle mogelijke velden maar niet alles noodzakelijk ingevuld afh van vereisten stad ( 1 API met alle mogelijke velden (moet niet allemaal ingevuld zijn) en niet per leverancier)

beheren van aanvragen en vergunningen (hergebruiken/editeren en deleten of archive)

verlengen van aanvraag/vergunning

oslo datamodel

bestaande data capteren: 3 elementen door slimme lokaal bron te genereren

bestaande data gestandaardiseerd herbruikbaar delen

een omgeving waar lokale data aangemeld kan worden ifv citerra: verschillende toepassingen waar de vergunningen zitten ter beschikking stellen aan citerra (data vindplaats)

besluitdata vertalen in machineleesbare data (verdere detaillering

Voertuigen, 200 numemrplaat aanvragen leveranciers registreren in Citerra of op vind plaats zelf? Mogelijkheden * Behouden in applicaties en opvragen * Centraal behouden Citerra * uploaden wallet, solid * Ondernemersloket * Rechstreeks in eigen erp van leveranciers Bulk aanvragen in XML

Bulkoplading moet mogelijk zijn

bewaren van data voor meerdere aanvragen/opnieuw aanvragen van vergunning

gemeente moet business rules kunnen updaten

tijdelijk bewaren van data/onafgewerkte aanvraag

payment gateway: centraal systeem betalingen - hoe 1 keer afrekening en juist doorbetale,n naar de verschillende steden, diensten

QA (quality assurance)

Data ownership ( bewerkingen die gebeuren moeten gelinkt worden aan de bewerker -> welke stad dienst heeft vergunning geweigerd: transparentie & opvolging)

CMS met sync naar dependent & dependencies: vanuit centrale platform vergunning aangevraagd worden, zal er iets van database aan dit platform en sync moeten zitten/ BV leverancier en je moet door de 2 zones rijden, eerste goedkeuring en tweede weigering -> relevante info moet terug komen van 1 van de vragen. Dus er moet een link zijn - om de link te houden => Duidelijk vermelden aan aanvrager om dit mee te delen

valideren volgens het data model (SHACL): als gemeente iets pubiceerd dans moet je nakijken of data correct is.

tergukoppeling indieen validatie faalt

Discussie

• Definiëren van benodigde data en acties: De discussie richtte zich op het identificeren van alle relevante data en acties die nodig zijn voor het informatieplatform.
• Beheren en hergebruiken van aanvragen en vergunningen: Gesprek over de benodigde functionaliteit voor het beheren van aanvragen en vergunningen, inclusief opties zoals aanpassen, verwijderen en archiveren.
• Integreren van verschillende soorten data: Overwegingen bij het integreren van diverse data in formulieren en het gebruik van een centrale API voor gegevensverzending.
• Valideren van data volgens een bekend datamodel: De discussie betrof het valideren van data volgens een vastgesteld datamodel dat consistent is voor lokale besturen.
• Vaststellen van data-eigenaarschap: Gesprek over wie verantwoordelijk is voor de data die op het platform staat om duidelijkheid te scheppen over verantwoordelijkheden.
• Opzetten van een payment gateway: Overwegingen bij het implementeren van een payment gateway voor efficiënte betalingen bij vergunningsaanvragen.
• Thematische vergunningsconcept van de Vlaamse overheid: Bespreking van het concept van thematische vergunningen en hoe dit kan worden toegepast voor automatische identificatie van vereiste vergunningen bij verschillende verplaatsingen.
• Overwegen van verschillende benaderingen voor authenticatie: Discussie over de mogelijke benaderingen voor authenticatie, met de nadruk op HTTP-technologie als een mogelijke optie met externe systemen.

Oefening 4

Instructies

Hoe gaan we om met de verschuiving van aanvragen die rechtstreeks verlopen via de website van de lokale besturen naar een overkoepelend medium? Wat zijn mogelijke valkuilen?

Voorbeeld:

- Integratie van verschillende systemen en databronnen kan technisch uitdagend zijn

- Financiering verdeling over de verschillende lokale besturen

Output

Valkuilen

teveel couleur locale, te weinig standaardisatie

LLM (language model - machine leesbaar) is geen oplossing, kan als hulpmiddel gebruikt maar niet als tool, validator zelf

AI voor reglementen kan een mw zijn , nog onderzoeken wat de mogelikheden zijn

'lokale invulling' vs automatisatie en kost: hoe meer vrijheid dat je toelaat hoe minder kans tot automatisatie waar trek je de lijn

Scope Vlaanderen is beperkt (subsidie), generiek maken door bv aanvrager geeft aan of hij/zij al dan niet Vlaams is

gesloten platform?: nog niet duidelijk of er 1 platform wordt gebouwd voor heel Vlaanderen of worden alle blouwblokken ter beschikking gesteld. Open platform waar iedreen kan integreren. Scope nog niet duidelijk

Toeliching: scope autoluwe zone, nog open of het 1 platform wordt, platform waat alle vergunningen naast elkaar staan en 1 specifieke kunt aanvragen voor autoluwezone. Breder maken nog geen zicht maar mogelijkheden

niet starten met een duidelijke scope en timing voor poc

uptime platform moet maximaal zijn: moet kunnen voldoen aan piekdagen/uren als zondag bv

integriteit van de databronnen

niet-schaalbaarheid naar andere use-cases

aanpassingen LPDC ivm parametrisatie door Vlaanderen nodig: hoeveel nummerplaten aanvragen per burger bv in een generieke formulier ztten dat kan ingevuld zijn per stad/gemeentes. Nu zijn het enkel tekstvelden nu niet beschikbaar

Governance voor duurzaamheid van platform

te vaak dynamische aanpassingen nodig nadien / stabiliteit : niet te veel wijzigingen in regels van steden

te moeilijk dus eigen websites blijven: formulier te complex -> dan gaan ze toch naar de algemene stad site en gaat het niet gebruikt worden ( vraag komt van ondernemingen)

stad/gemeente of leverancier van aanvraagsysteem die niet wil meedoen

niet alle steden en gemeentes hebben een aanvraagsysteem

Uitsluiting van bepaalde steden geeft minder waarde aan dit project

cyber security

financiering bouw of business model

Uitdagingen: Datamodel, intelligentie van data

iedereen meekrijgen

commerci le belangen vs open data: veel bronnen aangehaald en deel ervan zijn open data of worden open data -> commerciele spelers meekrijgen. bv Parking die in autoluwe zone ligt

lokale specificiteit vs generieke regelgeving

opsec: operational security. End points voorzien voor handhaving voor ophalen en syncen van vergunningen gaan bepaalde zaken publiek zijn. bv qr code waar persoon makkelijk kan nagaan - OPSEC is deel waar wordt gekeken dat er info ook niet ge-expoded kan zijn. Info die je niet met concurrentie wilt delen

onderhoudskost

Discussie

• Lokale invulling versus automatisatie: Hoe lokale aanpassingen de automatisatie kunnen belemmeren omdat standaardisatie moeilijker wordt. Dit kan leiden tot hogere kosten voor automatisering.
• Scope van het platform: Er is onduidelijkheid over de reikwijdte van het platform. Moet het een centraal platform zijn voor alle vergunningsaanvragen in Vlaanderen, of eerder een open platform waar verschillende integratoren en oplossingen kunnen worden gebruikt?
• Financiering en businessmodel: Hoe wordt de financiering verdeeld en wat is het businessmodel voor de verschillende spelers? Dit omvat ook de vraag of het platform commerciële belangen moet dienen of juist moet focussen op open data.
• Integratie en schaalbaarheid: Het platform moet niet alleen voor autoluwe zones werken, maar ook schaalbaar zijn voor andere vergunningsaanvragen en gebruiksscenario's.
• Operationele veiligheid: Zorgen over de beveiliging van endpoints en het voorkomen van onbedoelde blootstelling van gevoelige informatie, zoals wie welke vergunningen aanvraagt.
• Governance en duurzaamheid: Het creëren van een duurzaam governancemodel voor het platform en ervoor zorgen dat het platform dynamische aanpassingen kan doorvoeren zonder de stabiliteit in gevaar te brengen.
• Inclusiviteit en acceptatie: Het belang van het betrekken van alle belanghebbenden om de waarde van het platform te maximaliseren en ervoor te zorgen dat het breed wordt geaccepteerd en gebruikt.

Opname en Miro bord

Miro bord

Het Miro bord kan je consulteren via deze link.

Opname

De opname van deze sessie is te bekijken via deze link.

Volgende stappen

Wat na deze werkgroep?

1. Verwerking van de input van de brainstorm oefening.
2. Verder onderzoek en voorbereiding van de volgende thematische werkgroep.
3. Publicatie op de Kennishub

Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be

Andere werkgroepen

Werkgroep	Type werkgroep	Datum	Tijd	Locatie
Business werkgroep	Business werkgroep	2024-02-27	13u-16u	VAC Antwerpen
Thematische werkgroep 1	Data en informatie werkgroep	2024-03-28	13u-16u	Teams
Thematische werkgroep 2	Functionele werkgroep	2024-05-16	13u-16u	Teams
Thematische werkgroep 3	Technologie werkgroep	2024-06-25	13u-16u	Teams