Deze pagina beschrijft het stappenplan om bestaande verenigingsgegevens op te laden in de productie-omgeving voor de eerste piloot-aansluiters richting de lancering van het loket. De concrete partijen worden hieronder benoemd.
Voor alle andere aansluiters, na de lancering van het Verenigingsloket, zal er in een gelijkaardig traject opgezet worden (met lessen die we leren uit de piloten). We bekijken nog hoeveel aansluiters we kunnen ondersteunen binnen welke tijdsspanne.
Piloot aansluiters richting lancering Verenigingsloket
Organisatie | SPOC |
|---|---|
Bregt Van Den Bergh | |
Marc Goethals | |
ULDK (Departement CJM) | Didier Claessens |
Eva Hambach | |
Kiosk (Departement CJM) | Johan Daniëls |
Methoden om data te migreren
Er bestaan 2 manieren om de initiële set van data op te laden, zowel in het verenigingsregister als in het master data systeem voor verenigingsgegevens van de piloot.
Migratie via API
In deze methode wordt de data vanuit de huidige gegevensbronnen opgeladen naar het masterdatasysteem (1). Van daaruit zal een initiële synchronisatie tussen masterdata systeem en het verenigingsregister (over MAGDA) de gegevens opladen in het verenigingsregister (2).
Migratie via Excel
In deze methode wordt de data vanuit de huidige gegevensbronnen overgezet naar de Excel template zoals die voorzien wordt door DV (1). Vervolgens wordt deze Excel op een veilige manier verzonden naar DV (2). DV laadt de data via een speciaal daarvoor ontworpen migratietool op in het verenigingsregister (3). Tenslotte wordt de data ingelezen in het eigen masterdata systeem op basis van een initiële leesoperatie in het verenigingsregister (via MAGDA).
Wat wordt wel/niet ondersteund in deze methode
Deze migratie via Excel ondersteunt het eenmalig toevoegen van verenigingsdata aan het verenigingsregister (in naam van de piloot aansluiter) op basis van gegevens ingevuld in een daarvoor bestemd Excel document.
Deze migratie methode ondersteunt niet het wijzigen, toevoegen of verwijderen van gegevens van een vereniging eens deze is opgeladen.
Overzicht en tijdslijjn
Uitleg per fase
Betrokken partijen:
Piloot: de piloot aansluiters
DV: Digitaal Vlaanderen
Voorbereiden van de gegevens
→
Migratie via Excel
De piloot zorgt er voor dat de migratie Excels (zie sjablonen) ingevuld worden met de gegevens van ALLE verenigingen die ze wensen op te laden.
Hierbij is het niet de bedoeling om gegevens te gaan opzoeken die op dit moment niet gekend zijn (zoals bijvoorbeeld de website van de vereniging). Het is WEL de bedoeling om verplichte gegevens te gaan opzoeken of opvragen (zoals bijvoorbeeld het rijksregisternummer van de vertegenwoordigers, of andere gevens om te voldoen aan de minimum dataset)
Wanneer de Excels klaar zijn, worden deze opgeladen naar DV en dit ten laatste op . DV zoekt momenteel nog naar het beste mechanisme om deze gegevens beveiligd door te sturen. Ten laatste wordt deze methode beschreven.
Migratie via API
Indien dit nog niet is gebeurd, worden de huidige gegevens bronnen overgezet naar het master data systeem voor verenigingsdata.
Beide methoden
Piloten geven aan op welke manier zij de migratie-Excels hebben opgemaakt (zie sjablonen). Hierin staat van waar de gegevens komen, hoe de actualiteit en correctheid wordt ingeschat, etc.
Eerste validatie ronde
→
Migratie via Excel
In deze ronde zijn de INSZ nummers van de vertegenwoordigers NIET aanwezig. Als ze in het interne bestand al ingevuld zijn, dan worden deze eerst leeg gemaakt vooraleer ze naar DV verstuurd worden ter validatie.
Zodra de eerste versie van het migratie bestand klaar is, zal DV deze nakijken en valideren. Er wordt vooral gecontroleerd op:
Is voor elke vereniging voldaan aan de minimum dataset ?
Zijn de verplichte velden allemaal aanwezig?
Hebben alle velden een plausibele waarde?
Ziet het formaat van de velden er uit zoals we dat zouden verwachten?
Zijn er dubbels binnen de verenigingen?
Zijn alle afdelingen en feitelijke verenigingen opgedeeld in de juiste groep? Zitten hier geen KBO verenigingen tussen? Of afdelingen die eigenlijk een feitelijke vereniging onder koepel zijn?
Van zodra het bestand gevalideerd is, koppelt DV de bevindingen terug naar de piloot die deze kan verwerken tot een verbeterde versie. Deze validatie kan itereren tot ten laatste
Migratie via API
DV neemt contact op met de piloot om de data te valideren die aanwezig is in het masterdata systeem.
Indien mogelijk genereert de piloot reeds de API calls die zullen uitgevoerd worden voor de initiële synchronisatie (JSON formaat van de request bodies), waarbij de INSZ nummers leeg gemaakt worden (of geanonimiseerd).
DV controleert deze data met dezelfde criteria als bij de Excel migratie.
Tweede validatie ronde
→
Migratie via Excel
Ten laatste op ontvangt DV van de piloot de 2 Excel bestanden die gebruikt gaan worden in deze validatie ronde. XXXXXXXX HIER OOK AANLEVEREN VRAGENLIJST XXXXXXX
In deze ronde zal DV de gegevens effectief opladen, maar wel in een gescheiden omgeving. DV maakt hierbij gebruik van de tools en de validaties zoals dit ook voor productie zal gebeuren. Na het opladen wordt een rapport bezorgd met de resultaten:
Welke verenigingen zijn correct opgeladen
Voor welke verenigingen waren er nog fouten in de op te laden data
Welke verenigingen werden gemarkeerd als een potentiële dubbel met andere verenigingen
DV bezorgt dit rapport aan de piloot die deze kan verwerken tot een verbeterde versie. In deze versie zijn:
de fouten verbeterd
de gemarkeerde dubbels gecontroleerd. Wanneer het om een effectieve dubbel ging, wordt de vereniging uit het bestand gehaald. Wanneer de vereniging toch uniek blijkt te zijn, dan wordt aangeduid in het bestand dat deze geverifieerd is.
Wanneer alle piloten een eerste versie opgeladen hebben, bestaat er de mogelijkheid om het verbeterde bestand op te laden. Dit bestand kan met of zonder de reeds correct opgeladen verenigingen zijn. Wanneer deze er nog in aanwezig zijn, dan zullen deze als potentiële dubbel (van zichzelf) naar boven komen.
Migratie via API
DV bezorgt aan piloot de methode om een gescheiden omgeving te benaderen. De piloot zal daar al een eerste synchronisatie van de gegevens op kunnen uitproberen.
De piloot bezorgt een verslag van de upload aan DV met daarin:
hoeveel verenigingen correct zijn opgeladen
hoeveel fouten nog aanwezig waren en welk soort fouten nog moeten gecorrigeerd worden
hoeveel registraties niet gelukt zijn vanwege een potentiële dubbels en op welke manier deze dan verder behandeld gaan worden.
Beide methoden
Deze fase eindigt op , wanneer de effectieve productie omgeving wordt klaargezet.
Opladen van de gegevens (+ plan van aanpak)
→
Migratie via Excel
Ten laatste op is DV in het bezit van de gevalideerde bestanden met verenigingen die mogen opgeladen worden in de productie omgeving.
Deze bestanden worden opgeladen zoals bij de vorige ronde. Eventuele validatie issues worden teruggekoppeld en kunnen nog verbeterd worden. Door de dry-run in validatie ronde 2 zou dit al sterk beperkt moeten zijn. DV kan alsnog gecorrigeerde bestanden ontvangen en verwerken tot . Vanaf dan stopt de migratie ronde.
Migratie via API
DV geeft het groene licht aan Magda om de aansluiting open te zetten voor deze piloot. De piloot lanceert vervolgens de eerste synchronisatie met de echte productie omgeving.
De piloot bezorgt een verslag van de upload aan DV met daarin:
hoeveel verenigingen correct zijn opgeladen
hoeveel vereniging niet zijn opgeladen met de reden waarom + hoe dit aangepakt gaat worden.
Beide methoden - streefdoel
We streven er naar om tegen dan >=80% van de initiële data opgeladen te hebben. Dit cijfer houdt rekening met o.a.
verplichte, ontbrekende data die niet tijdig kon opgevraagd worden
verenigingen die als potentiële dubbel gemarkeerd zijn en ofwel niet geverifieerd zijn ofwel erkend als dubbel.
Beheer via MAGDA
Vanaf
Van zodra de data van een piloot opgeladen is in de productie omgeving, wordt deze piloot geacht om de data van deze verenigingen up to date te houden met behulp van de MAGDA interface.
Sjablonen voor aan te leveren data
Migratie Excels
De Excel templates zijn hier terug te vinden: https://vlaamseoverheid.atlassian.net/wiki/spaces/AGB/pages/6305743459/Verenigingsgegevens+voorbereiden#Voorbereidingskit . We verwachten uiteindelijk 2 Excel bestanden (een voor de feitelijke verenigingen & afdelingen en een andere voor de KBO verenigingen)
Oorsprong van de gegevens
Om een idee te krijgen van de oorsprong van de gegevens alsook actualiteit en correctheid, voorziet de piloot een antwoord op volgende vragen:
[nog om te zetten in een invulsjabloon]
Hoe zijn deze migratie Excels tot stand gekomen? Wat was de werkwijze?
Op welke manier weten jullie of de verenigingen nog actief zijn?
Hebben jullie deze data voorgelegd aan de verenigingen om deze te valideren?
Hoe hebben jullie de verenigingen geïnformeerd dat hun gegevens overgezet gaan worden naar het verenigingsregister? Hoe hebben jullie de verenigingen de kans gegeven om deze gegevens te actualiseren vooraleer de finale data aangeleverd werd?
Welke data was al aanwezig en welk is omwille van deze migratie opgezocht en aangevuld?
Is er intern al gecontroleerd dat er geen dubbels aanwezig zijn in de data?
Ook al bevat deze data nog geen INSZ… hebben jullie de INSZ al verzameld en beschikbaar?
[…]
Beschrijving plan van aanpak voor beheer als gegevensinitiator na migratie
Na de initiële migratie nemen de piloten hun taak op als gegevensinitiator. Een onderdeel van deze taak is het meewerken aan het actueel houden van de verenigingsdata op een correct en veilige manier. Om dit te evalueren, vragen we aan de piloten om een antwoord te geven op de volgende vragen.
DV zal pas data opladen in productie wanneer de antwoorden ontvangen zijn en DV geoordeeld heeft dat de piloot de taak van initiator op een afdoende manier opneemt startende van het moment van migratie.
[nog om te zetten in een invulsjabloon]
Wie is het unieke aanspreek (SPOC) punt wanneer DV (tijdens migratie en later) in contact wenst te treden in verband met het verenigingsregister (denk aan updates van de datadiensten maar ook beheercomité/werkgroep waarin de verschillende initiatoren kunnen zetelen)
Gelieve naam, functie, e-mail adres en telefoon nummer te voorzien. Het e-mail adres mag eventueel een generiek e-mail adres zijn.
Op welke manier dragen jullie bij tot de actualisatie van de gegevens? Welke werkwijze en tools zijn hiervoor beschikbaar?
Welke incentive strategie voorzien jullie? Welke voordelen koppelen jullie aan de registratie van gegevens? Voorbeeld: in welke dienstverleningsprocessen gaan jullie vragen aan de vereniging om de V-code op te geven, gegevens te actualiseren, opdat jullie deze gaan gebruiken in de aanvraag, etc.
In welke toepassingen worden updates voorzien richting het Verenigingsregister? Dit kunnen eigen softwaretoepassingen zijn die zowel voor ambtenaren als verenigingen toegankelijke zijn, alsook het gebruik van het Verenigingsloket waarnaar jullie de vereniging doorverwijzen.
Welke sensibilisering voorzien jullie t.a.v. de vereniging om gegevens te actualiseren? Zal er periodiek gevraag worden aan de verenigingen om gegevens na te kijken? Halen jullie zelf foutieve gegevens uit het register indien jullie op de hoogte gesteld worden van aanpassingen?
Op welke manier zorgen jullie voor de correcte interpretatie van het datamodel en bijhorende definities bij de interne collega’s en de vereniging
Op welke manier worden deze gegevens vanuit interne toepassingen gesynchroniseerd van en naar het verenigingsregister zodat jullie steeds over de laatste gegevens beschikken voor hergebruik? Geef voor elk van deze toepassingen aan op welke manier zij de data uit het verenigingsregister gaan hergebruiken en of deze de data uit het verenigingsregister ook zal actualiseren. Geef ook een tijdsindicatie aan vanaf wanneer deze toepassing dit zal doen.
[informatieveiligheid] Hoe zorgen jullie dat interne collega’s de gegevens gebruiken conform de doeleinden?
In het bijzonder: Zijn de persoonsgegevens voldoende afgeschermd voor oneigenlijk gebruik buiten de bevoegde ambtenaren?
0 Comments