Aanbeveling |
Vervolgstap |
1. Maak afspraken met leveranciers over het wel/niet inzetten op nieuwbouw voor de BRK- applicaties, neem de ontwikkelingen rondom de WOZ, BRK-API en minimale gebruikersbehoefte hierin mee om te voorkomen dat er desinvesteringen worden gedaan. |
Informatiebijeenkomsten georganiseerd op 10 december, alsook op 29-1 en 11-2. |
2. Stel een roadmap op waarin alle toekomstige ontwikkelingen en migratiescenario's worden geplot. Bepaal met stakeholders op strategisch niveau welk scenario toekomstvast is. Daarnaast moet de roadmap afzonderlijke gemeenten helpen om een weloverwogen besluit te nemen. |
Een handreiking, inclusief roadmap, voor de verschillende scenario’s wordt opgesteld. Hierin wordt zowel productinformatie (specificaties, geïntegreerde planning, migratiestrategie) als gebruikersinformatie (gebruikersprofielen, voordelen per scenario, advies besluitvormingsproces) opgenomen. |
3. Doe nader onderzoek naar de haalbaarheid en planning van BRK-API's/ Haal Centraal. Inclusief aspecten als functionele behoefte, kwaliteit relaties, roadmap verschillende API's, mogelijkheid voor plateauplanning als stapsgewijze ontwikkeling (m.b.t. scenario 2) |
Onderzoek vindt plaats in nauwe samenwerking Haal Centraal, Kadaster en softwareleveranciers, bevindingen worden onderdeel van bovenstaande handreiking. |
4a. BRK Levering 2.0: Maak de vaststellingsprocedure van IMKAD 2.2 transparant en communiceer deze. 4b. BRK Levering 2.0: Onderzoek vanuit gebruikersperspectief wat de efficiëntste manier is om met de historische gegevens om te gaan en hoe het Kadaster hierin kan faciliteren. |
a. Communicatie over vaststellingsprocedure wordt geplaats op de website van het Kadaster b. Oplossingsrichtingen voor historische gegevens worden i.s.m. leveranciers onderzocht voor beide scenario’s en opgenomen in de handreiking. |
5a. Planning: Houd BRK Levering 1.0 ten minste tot Q2/Q3 '22 in de lucht |
a. Akkoord, zal ook als zodanig worden geïnformeerd met publicatie rapport b. De betrokken partijen committeren zich aan de inzet op alternatieve scenario’s (m.n. BRK-API), wat naast Levering 2.0 voorwaardelijk is om Levering 1.0 uit te faseren. |