Wijzigingsprotocol RO Standaarden v1.3.2

BC	Business Case
BOR	Beheeroverleg Ruimtelijkeplannen.nl van beheerorganisaties Kadaster en Geonovum
EC	Europese Commissie
EU	Europese Unie
IPO	Interprovinciaal Overleg
BZK	Ministerie van Binnenlandse Zaken en Koninkrijksrelaties
MR	Ministeriële Regeling
RO	Ruimtelijke Ordening
SDRO	Stuur- en beheergroep Digitale Ruimtelijke Ordening
TRIP	Tripartite overleg van BZK, Kadaster, Geonovum
VNG	Vereniging van Nederlandse Gemeenten
Wro	Wet ruimtelijke ordening

2. Inleiding

De RO Standaarden zijn een essentiële basis voor de uitvoeringspraktijk van de digitale aspecten van de Wro. De RO Standaarden zijn niet statisch. Daarom is het van groot belang dat het wijzigingsbeheer van deze standaarden goed geregeld is. Dit is iets waar vrijwel alle actoren - de belanghebbenden in de werkpraktijk van de ruimtelijke ordening - mee te maken zullen krijgen. Juist omdat de wijziging van de standaarden impact heeft op zoveel actoren, die bovendien veelal afhankelijkheidsrelaties met elkaar hebben, is het van belang om deze afhankelijkheden en verantwoordelijkheden in kaart te brengen en om hiermee afdoende rekening te houden. Met dit doel is dit wijzigingsprotocol opgesteld. Het beschrijft het geheel aan regels en afspraken om wijzigingen in de RO Standaarden op een gecontroleerde en acceptabele manier door te voeren.

2.1 Scope van dit document

Dit document beschrijft de manier waarop wijzigingen op de RO Standaarden plaatsvinden. Bij de procesbeschrijvingen wordt steeds uitgegaan van een model op hoofdlijnen. Dat betekent dat voor iedere actor duidelijk wordt wat er gedaan moet worden, wanneer, wat er verwacht kan worden van andere actoren en welke onderlinge afhankelijkheden er zijn. Verder wordt in het hoofdstuk Communicatie uiteengezet welke producten er gedurende het proces ontstaan. Dit protocol is geen handleiding voor hoe al deze zaken gerealiseerd moeten worden. Dit blijft een zaak van de actoren zelf. Zo wordt er niet ingegaan op de projectmatige aanpak om in een softwarepakket wijzigingen door te voeren; dit is de verantwoordelijkheid van de softwareleverancier. Evenmin wordt ingegaan op hoe Geonovum als beheerder van de standaarden de informatie aan het werkveld doseert. Wel wordt duidelijk gemaakt wat het werkveld op dit punt kan verwachten en wanneer van Geonovum.

2.2 Proces versus protocol

De titel van dit document geeft aan dat het hier om een protocol gaat. Toch wordt in dit document ook gesproken over processen. Het is goed om kort de verschillen te benoemen. Hiermee wordt ook meteen duidelijk wat de afbakening is van dit document. Van Dale[^1] geeft de volgende betekenissen:

[^1]: Bron: Dikke van Dale 3-in-1 Groot woordenboek, 4e editie.

protocol: een geheel van vastgelegde regels en afspraken op een bepaald gebied;
proces: het verloop, ontwikkelingsgang.

In dit document, het wijzigingsprotocol, wordt dus uitdrukkelijk het geheel van vastgelegde regels en afspraken voor het wijzigen van de RO Standaarden vastgelegd. Vanuit de aard van de zaak wordt daarbij veel aandacht besteed aan het verloop of de ontwikkelingsgang van de hiervoor noodzakelijke activiteiten.

Een wijzigingsproces is een daadwerkelijke wijziging van de RO Standaarden op een bepaald moment. Het volledig wijzigingsproces doorloopt de volgende tijdgebonden fasen met een vaste datum van inwerkingtreding van de nieuwe set RO Standaarden: A. Inhoud, B. Toetsing, C. Besluitvorming en D. Implementatie. Elk wijzigingsproces wordt begeleid volgens het beschreven protocol.

2.3 Het begrip wijziging

De RO Standaarden zijn niet statisch. Er wordt voortdurend gesproken over wijzigingen. Hiervoor wordt een veelvoud aan begrippen gehanteerd, waaronder kleine wijzigingen, technische wijzigingen, foutherstel, niet-juridische relevante wijzigingen, wijzigingen zonder impact, toevoegingen, weglatingen, structurele nieuwe ontwikkelingen en nieuwe standaarden. Het wijzigingsprotocol voorziet in het doorvoeren van al deze soorten wijzigingen.

Het is niet wenselijk om voor al soorten wijzigingen aparte afspraken vast te leggen. Wijzigingen die futiel zijn voor de één zijn ingrijpend voor de ander. Bij elk soort wijziging blijken steeds dezelfde actoren op hoofdlijnen een bepaalde rol te spelen, blijken steeds ongeveer dezelfde doorlooptijden en afhankelijkheden van toepassing en blijken steeds dezelfde randvoorwaarden ten grondslag te liggen aan de manier van doorvoeren. Daarom wordt in dit protocol steeds het algemene begrip "wijziging" gehanteerd. Dit kan slaan op het veranderen van de spreekwoordelijke komma tot het vaststellen van een geheel nieuwe standaard. Het belangrijkste voordeel van dit protocol is de duidelijkheid en voorspelbaarheid in het wijzigingsproces.

In dit document wordt ook gesproken over wijzigingsverzoeken en wijzigingsvoorstellen. Een wijzigingsverzoek is door een actor ingediend bij Geonovum, de beheerder van de RO Standaarden; de standaard moet op een bepaald punt met deze reden worden aangepast of aangevuld. In het wijzigingsproces worden de wijzigingsverzoeken die daarin worden meegenomen gebundeld tot één wijzigingsvoorstel. Dit wijzigingsvoorstel kan gedurende het wijzigingsproces veranderen: wijzigingsverzoeken kunnen afvallen, omdat besloten wordt hun toch niet mee te nemen. Een actueel overzicht van alle wijzigingsverzoeken voor de RO Standaarden zijn via de website van Geonovum beschikbaar gesteld.

Een uitgangspunt in het opzetten van dit protocol is dat de RO Standaarden zich dynamisch ontwikkelen en dus dat er geen behoefte is aan een geheel nieuw pakket standaarden zoals dat in het verleden is gebeurd: IMRO2003, DURP Standaarden 2006 en dan de RO Standaarden 2008 en vervolgens de RO Standaarden 2012. De intentie is om te werken met één set standaarden die in de tijd evolueert.

2.4 Wijzigingsvoorstel versus Business Case

Een business case is een projectmanagementbegrip. Het is een document waarin de zakelijke informatie en afweging, de kosten en de baten, staan voor de start of uitvoering van een project of taak. Voor de RO Standaarden stelt Geonovum per wijzigingsverzoek een business case op. Daarbij wordt gekeken naar de geschatte haalbaarheid van het verzoek en impact ervan op de werkwijze in het RO-praktijk met advies vanuit de RO-praktijk, zijnde BROS, Beheeroverleg Ruimtelijkeplannen.nl en softwareleveranciers. Bijlage 1 geeft een voorbeeld van initieel wijzigingsverzoek in het voorgeschreven formaat.

Een wijzigingsvoorstel is een collectie wijzigingsverzoeken, inclusief business case per verzoek. In de loop van een wijzigingsproces komen vier versies van een wijzigingsvoorstel langs, exclusief conceptversies. Elke versie is een verfijning van de vorige met bijdragen vanuit verschillende invalshoeken en partijen en wordt in een besluitmoment vastgesteld:

D-24: 1e versie wijzigingsvoorstel met initiële Business Case;
D-21: 2e versie wijzigingsvoorstel met eindconcept Business Case;
D-18: 3e versie wijzigingsvoorstel met definitieve Business Case;
D-12: Finale versie wijzigingsvoorstel met definitieve wijzigingen.

De verschillende versies en mijlpalen met besluitmomenten zijn beschreven in paragraaf 3.3.

N.B. Hoewel de begrippen wijzigingsvoorstel en business case in dit wijzigingsprotocol als afzonderlijke producten gehanteerd worden, ontstaat er in de praktijk een samenhangend document waarin zowel de voorgestelde wijzigingen zijn beschreven (“wijzigingsvoorstel”) met daarbij per onderdeel de noodzakelijke besluitondersteunende informatie (“business case”).

3. Het primair wijzigingsproces

Het wijzigingsprotocol ziet toe op een gecontroleerde manier van wijzigen van de RO Standaarden. Een belangrijk onderdeel van dit protocol is het primaire proces voor het doorvoeren van voorgestelde wijzigingen. Hierin is vastgelegd welke fasering en mijlpalen er zijn en de timing van het wijzigingsproces. Dit hoofdstuk beschrijft het primaire proces.

3.1 Hoofdlijnen van het wijzigingsproces

Schema 1 geeft de hoofdlijnen van het primaire proces weer: de algemene hoofdfasen en de timing van deze fasen. Het begrip “versie” refereert aan de versie van het wijzigingsvoorstel met business case.

Het primaire proces bestaat uit vier formele fasen en twee informele fasen die respectievelijk voorafgaat aan de eerste fase en volgt op de vierde fase. Tabel 1 geeft deze fasen kort weer. Paragraaf 3.3 geeft voor iedere fase een meer uitgebreide beschrijving.

Tabel 1 - Algemene fasering van het wijzigingsproces
Vooroverleg	informele afstemming
Fase A : inhoud	wat wordt het voorstel?
Fase B : toetsing	is het voorstel inhoudelijk en technisch correct?
Fase C : besluitvorming	willen wij het definitief?
Fase D : implementatie	doorvoeren in RO werkveld
Evaluatie	informele nazorg

3.2 Hoofdlijnen van het sturingsprincipe

Algemeen sturingsprincipe is dat voor elke wijziging een valide (positieve) business case moet zijn. Deze business case ontwikkelt mee met de uitvoering van het wijzigingsproces. Schema 2 geeft deze ontwikkeling weer. Bij iedere mijlpaal moet er een positieve business case (BC) zijn voor iedere wijziging. De Stuurgroep DRO beoordeelt of een business case positief is.

3.3 Beschrijving van de fasen en resultaten

3.3.1 Vooroverleg

Dit is een informele fase in het wijzigingsproces. Soms gaat er veel vooroverleg vooraf aan het daadwerkelijk in gang zetten van een bepaalde wijziging. Bij het ontwikkelen van een nieuwe standaard kan dit een proces van jaren zijn met activiteiten als onderzoek, voorstudies en het zoeken van draagvlak.

Resultaat: duidelijk zicht op de scope, draagvlak en oplossingsrichting van de beoogde wijzigingen.

3.3.2 Fase A: Inhoud

In deze fase wordt het inhoudelijke wijzigingsvoorstel bepaald door de concrete inhoud van elk wijzigingsverzoek uit te werken en de resultaten van uit het vooroverleg te concretiseren: welke wijzigingen worden er precies voorgesteld? Deze fases in onderverdeeld drie iteraties.

Inhoud A1 - Eerste wijzigingsvoorstel met initiële Business Case

Fase A1: In de eerste iteratie worden alle ingediende wijzigingsverzoeken uit de voorgaande periode gebundeld en op hoofdlijnen uitgewerkt met voorgestelde oplossing (of voorstel om niet mee te nemen).

Resultaat A1: Het eindproduct van deze iteratie is het eerste wijzigingsvoorstel met initiële Business Case. Het is de eerste volledige beschrijving van de voorgestelde wijzigingen, voldoende uitgewerkt voor besluitneming en voor toetsing op juistheid in meer detail.

Opmerkingen over A1: Het eerste wijzigingsvoorstel wordt bekend gemaakt bij alle actoren. Dit is het startpunt van fase C Besluitvorming.

Inhoud A2 – Toetsen, aanpassen, besluiten

Fase A2: In deze inhoudelijke iteratie wordt getoetst of het wijzigingsvoorstel inhoudelijke juist is, of de wijzigingen in het voorstel juist geformuleerd en uitvoerbaar zijn en of zij technisch haalbaar zijn voor ieder actor.

Resultaten A2: de resultaten van deze iteratie zijn het resp. tweede en derde wijzigingsvoorstel.

Opmerkingen A2: Gelijktijdig met deze inhoudelijke iteratie vindt besluitvorming (fase C) plaats op basis van het eerste wijzigingsvoorstel. Gekeken wordt of de wijzigingen in het voorstel wenselijk zijn en te prefereren boven alternatieven. In deze iteratie kunnen in het voorstel wijzigingen afvallen of veranderen als gevolg van de besluitvorming. Ook kunnen wijzigingen technische verbeterd worden als gevolg van de toets.

Inhoud A3 - Definitieve wijzigingen maken

Fase A3: In deze laatste inhoudelijke iteratie implementeert het werkveld de wijzigingen in de praktijk. Bij de implementatie kunnen nog technische tekortkomingen worden ontdekt. In deze iteratie kunnen zij worden hersteld: technisch foutherstel. Er worden geen nieuwe wijzigingen meer toegevoegd aan het wijzigingsvoorstel.

Resultaat A3: Het eindproduct is het definitieve wijzigingsvoorstel.

Opmerkingen A3: Wie de definitieve wijzigingen voor het voorstel maakt en hoe de koppeling met het werkveld plaats vindt wordt uitgewerkt in de volgende hoofdstukken.

3.3.3 Fase B: Toetsing

Deze fase vormt een brug tussen de inhoud, besluitvorming en implementatie. Toetsen betekent het bepalen van de inhoudelijke correctheid en technische haalbaarheid van de wijzigingen in het wijzigingsvoorstel. Er is een wezenlijk verschil met besluitvorming. Bij het toetsen wordt de inhoudelijke correctheid en technische haalbaarheid vastgesteld, bij besluitvorming de wenselijkheid om de voorgestelde wijzigingen door te voeren. Deze fase is opgedeeld in drie iteraties.

Toetsing B1 - Initiële Business Case toetsen

Fase B1: In de eerste iteratie toetsen de actoren inhoudelijk de eerste versie van het wijzigingsvoorstel op volledigheid: zijn deze inderdaad de wijzigingen die nodig zijn? Als het nodig is worden de formulering of details van het wijzigingsvoorstel inhoudelijk aangepast of alternatieven geboden.

Resultaat B1: Het eindproduct van deze iteratie is de tweede versie van het wijzigingsvoorstel met eindconcept Business Case. Dit voorstel moet inhoudelijk compleet zijn en na oplevering klaar voor technische toetsing voor de Definitieve Business Case.

Opmerkingen B1: Actoren mogen ervoor kiezen om in deze iteratie alvast technische aspecten naar eigen belang te toetsen.

Toetsing B2 - Eindconcept Business Case toetsen

Fase B2: In deze tweede iteratie toetsen de actoren of de wijzigingen technisch juist geformuleerd zijn, of zij haalbaar zijn (impact en kosten) en of zij in een productieomgeving te implementeren zijn. In deze toets kunnen wijzigingen pragmatisch aangepast worden.

Resultaat B2: Het eindproduct van deze iteratie is de definitieve Business Case. Het is nu helder welke wijzigingen gewenst zijn en haalbaar worden geacht en hoe zij juist geformuleerd moeten zijn.

Toetsing B3 - Definitieve Business Case toetsen

Fase B3: Dit is een technische iteratie. De verschillende actoren toetsen de effecten van de wijzigingen onderling in gezamenlijke technische proefomgevingen (testbeds). Ruimtelijkeplannen.nl maakt een versie waarmee softwareleveranciers hun nieuwe versie van de RO applicatie kunnen toetsen en daarmee Ruimtelijkeplannen.nl.

Resultaat B3: Het eindproduct van deze iteratie zijn de Definitieve Wijzigingen. In principe is de Definitieve Business Case gelijk aan de Definitieve Wijzigingen, tenzij er kleine technische kwesties aan het licht komen.

Opmerkingen B3: Dit is ook de eerste iteratie van de fase Implementatie. Deze iteratie is er alleen op gericht om kleine technische fouten die het werkveld ontdekt bij de implementatie op gecontroleerde wijze te herstellen. Het is niet de bedoeling dat er in deze iteratie pas serieus wordt gekeken naar de kwaliteit van de wijzigingen in het voorstel.

3.3.4 Fase C: Besluitvorming

Als er een eerste wijzigingsvoorstel met initiële Business Case ligt, vindt hier formele besluitvorming over plaats. Hierbij hoort onder andere het wettelijke traject dat doorlopen moet worden om de gewijzigde of nieuwe standaarden te verankeren in de Wro wetgevingsfamilie en de inhoudelijk toetsing van de wijzigingen. In bovenstaand schema is met een stippellijn de mogelijke uitloop aangegeven. Dit geeft aan dat het volledige besluitvormingsproces langer duurt bij de EU notificatieprocedure. In dat geval wordt de fase formeel afgerond met de ontvangstbevestiging van de concept ministeriële regeling waarin de wijzigingen zullen worden bekrachtigd. De fase besluitvorming is opgedeeld in drie iteraties.

Besluitvorming C1 - advies

Fase C1: In deze iteratie vormen BOR en TRIP een advies over de wijzigingen in het voorstel dat door Geonovum hen voorlegt. Dit is de eerste stap in de formele besluitvorming.

Resultaten C1: Business Case voorzien van advies.

Besluitvorming C2 - besluit

Fase C2: In deze iteratie neemt het ministerie van BZK als wetgever/beleidsmaker samen met andere leden van de Stuurgroep DRO een formeel besluit over het advies van de TRIP.

Resultaat C2: Een formeel besluit door BZK.

Besluitvorming C3 - verankering

Fase C3: In deze iteratie vindt de optionele EU notificatieprocedure plaats. Ook verzorgt BZK de wettelijke verankering.

Resultaat C3: Een (nieuwe) gepubliceerde ministeriële regeling waarmee de nieuwe RO Standaarden verankerd zijn.

3.3.5 Fase D: Implementatie

Nadat de besluitvorming over de voorgestelde wijzigingen wordt begonnen met de implementatie. Software moet aangepast worden bij alle bronhouders en afnemers van ruimtelijke plannen. Mogelijk moeten RO handboeken, de conformiteitstoets, de Validator en/of Ruimtelijkeplannen.nl worden aangepast. Tijdens deze fase wordt de implementatie begeleid waar nodig. Implementatie is opgedeeld in drie iteraties.

Implementatie D1

Fase D1: In deze iteratie worden voornamelijk de Validator, Ruimtelijkeplannen.nl en indien nodig de software voor de conformiteitstoetsing aangepast. Dit is een beperkte iteratie, omdat het hier gaat om de implementatie bij een beperkt aantal actoren. Naast het Kadaster en Geonovum als beheerders van deze voorzieningen, betreft het mogelijk ook softwareleveranciers die vroegtijdig de wijzigingen in hun software willen doorvoeren en toetsen. Het RO werkveld in brede zin zal bij iteratie D2 de wijzigingen starten met de implementatie van de wijzigingen.

Resultaat D1: een aangepaste Validator en een aangepaste Ruimtelijkeplannen.nl ten behoeve van implementatie van bronhouders- en afnemerssoftware.

Implementatie D2

Fase D2: In deze iteratie worden Ruimtelijkeplannen.nl, bronhouders- en afnemerssoftware ontwikkeld en worden conformiteitstoetsen afgenomen indien nodig.

Resultaat D1: Software is klaar voor de uitrol bij bronhouders en afnemers, bronhouders staan klaar om intern de implementatie uit te voeren voor de datum inwerkingtreding.

Implementatie D3

Fase D3: In deze iteratie wordt software uitgeleverd, worden RO handboeken aangepast en wordt dienstverlening op basis van de nieuwe RO Standaarden voorbereid.

Resultaat D3: Het werkveld heeft de wijzigingen verwerkt en kan hiermee aan de slag na de inwerkingtredingsdatum.

3.3.6 Evaluatie

Na de inwerkingtreding van de wijzigingen zal het soms nodig zijn om de juiste toepassing te monitoren en/of de effectiviteit te evalueren. Dit is afhankelijk van de aard en omvang van de wijzigingen. Net als het vooroverleg is dit een informele fase. Het resultaat hiervan is een helder beeld van de werking van de ingevoerde wijzigingen en mogelijk zicht op noodzakelijke en/of gewenste vervolgacties.

3.4 Belangrijkste afhankelijkheden

De belangrijkste afhankelijkheden tussen de fases zijn weergegeven in onderstaande tabel.

Tabel 2 - Afhankelijkheden tussen de fasen in het wijzigingsproces
- = weinig of geen afhankelijkheid * = matige afhankelijkheid ** = sterke afhankelijkheid
	Inhoud	toetsing	besluitvorming	implementatie	evaluatie
vooroverleg	**	-	*	-	-
inhoud		**	**	*	*
toetsing			*	**	*
besluitvorming				*	*
implementatie					**

Vooroverleg inhoud **

In het vooroverleg wordt feitelijk gewerkt aan draagvlak voor de scope en onderwerpen van de wijzigingen. Het heeft geen zin om inhoudelijk aan wijzigingsverzoeken te werken als op voorhand duidelijk is dat dit in de besluitvorming zal sneuvelen of dat slechts een beperkt deel van de voorgestelde wijzigingen binnen de beschikbare budgetten kan worden uitgewerkt en geïmplementeerd.

Vooroverleg besluitvorming *

In het vooroverleg vindt afstemming plaats over de scope en onderwerpen van de wijzigen waar aan gewerkt zal worden. Daarmee wordt draagvlak vooraf gecreëerd. Dit draagvlak is nodig voor de besluitvorming. Ook wordt de mate van besluitvorming in kaart gebracht – hoe formeel en juridisch het traject wel of niet moet zijn en de afhankelijkheden van of impact op andere wetten (bijvoorbeeld de Grex of Wabo).

Inhoud toetsing **

Dit is een sterke afhankelijkheid. De inhoud wordt getoetst op correctheid voorafgaand aan het proces van besluitvorming.

Inhoud besluitvorming **

Bij de besluitvorming is het met name van belang dat de voorgestelde wijzigingen gewenst zijn. Daarom is tijdens het inhoudelijk bepalen van het wijzigingsvoorstel afstemming nodig met TRIP en koepelorganisaties over punten waar in de besluitvorming discussie over zou kunnen ontstaan. Te denken valt aan het oplossen van een probleem dat op meerdere, verschillende manieren gedaan kan worden. Dan is het goed om af te stemmen welke oplossing het meest gewenst is.

Inhoud implementatie *

De fase van implementatie is de lakmoesproef voor de vastgestelde wijzigingen. Op dat moment moet blijken dat de wijzigingen realistisch en haalbaar zijn. Dit betekent dat al tijdens de inhoudelijke fase goed gekeken moet worden of de wijzigingsverzoeken hier aan voldoen.

Inhoud evaluatie *

In de evaluatie wordt teruggekeken hoe het hele proces verlopen is en hoe bepaalde keuzes hebben uitgepakt in de praktijk. De conclusies kunnen input zijn voor nieuwe inhoudelijke bijstellingen.

Toetsing besluitvorming *

Bij de besluitvorming moet een duidelijk beeld zijn van de kwaliteit van het concreet uitgewerkte wijzigingsvoorstel. Ook de uitkomsten van eventuele testbeds, die een indruk geven van de mate van realisme en haalbaarheid van de voorgestelde wijzigingen, worden meegewogen in de besluitvorming.

Toetsing implementatie **

Er is een sterke afhankelijkheid tussen het toetsen van de voorgestelde wijzigingen en het implementeren van de definitieve wijzigingen. Dit is cruciaal voor het slagen van het gehele wijzigingsproces. Niet goed doordachte wijzigingen zullen het werkveld in grote problemen brengen. Het werkveld moet daarom goed betrokken zijn tijdens de fase van het toetsen van de wijzigingen voordat deze definitief worden.

Toetsing evaluatie *

In de evaluatie wordt de wijze van toetsen bekeken. Dit kan tot nieuwe inzichten leiden.

Besluitvorming implementatie *

In de besluitvorming is het wezenlijk in te schatten hoe haalbaar en realistisch de voorgestelde wijzigingen zijn. De implementatie is hiermee afhankelijk van een gedegen besluitvorming. Om te kunnen monitoren hoe hun besluiten in de praktijk uitpakken is het van belang dat degene die betrokkenen zijn bij de besluitvorming de implementatie volgen.

Besluitvorming evaluatie *

In de evaluatie wordt de besluitvormingsprocedure bekeken. Dit kan tot nieuwe inzichten leiden.

Implementatie evaluatie **

De relatie tussen de evaluatie en de implementatie is het belangrijkst. Uiteindelijk is de hamvraag in de evaluatie: kan het beroepspraktijk er mee werken?

5. Uitgangspunten

Het wijzigingsprotocol gaat uit van een aantal uitgangspunten dat een vaste set randvoorwaarden vormt bij het doorvoeren van wijzigingen op de RO Standaarden. In dit hoofdstuk wordt nader ingegaan op deze uitgangspunten.

De uitgangspunten worden gegeven in Tabel 3 en hieronder verder uitgewerkt.

Tabel 3 - uitgangspunten bij het wijzigingsproces
Business Case is leidend
Altijd één geldige versie van de RO Standaarden
Start van de formele procedure is leidend bij versiebepaling
Eén maal per drie jaar wijzigingen doorvoeren
Vaste datum inwerkingtreding
Geen wijzigingsplicht voor eenmaal gepubliceerde plannen
Aanpassing van vorm- of technische aspecten van een gepubliceerd plan

5.1 Business Case is leidend

Het proces van een initieel idee tot de inwerkingtreding van een wijziging is een langdurig proces. Tijdens het proces verschuift de focus van idee naar inhoud naar aanpassingen naar besluitvorming naar systemen en werkprocessen en naar wetgeving. Als uitgangspunt wordt een business case (BC) opgesteld als rationalisatie voor het wel of niet doorvoeren van voorgestelde wijzigingen. In dit document is vastgelegd wat de toegevoegde waarde is van de wijzigingen. Daarbij wordt per wijziging beschreven waarom bepaalde keuzes zijn gemaakt, welke voordelen de wijziging biedt, wat de baten en kosten van de wijziging zijn -zowel kwalitatief als kwantitatief- en welke aannames hierbij zijn gehanteerd.

Een BC bevat liefst een goede investeringsanalyse en een risicoanalyse. Zij wordt vooraf goedgekeurd door de stuurgroep en bij ieder beslismoment opnieuw aangepast en beoordeeld op geldigheid (zie Schema 2). Na afronding van het wijzigingsproces vindt de evaluatie plaats op basis van de uitgangspunten die zijn vastgelegd in de BC.

5.2 Altijd één geldige versie van de RO Standaarden

Op ieder moment in de tijd is er slechts één versie van de RO Standaarden actueel. Tot aan de inwerkingtreding van een set wijzigingen op tijdstip D is de actuele versie de versie zonder de wijzigingen (X), vanaf tijdstip D zijn de RO Standaarden waarop de wijzigingen zijn doorgevoerd (X+1) actueel. In Schema 1 is de actuele versie weergegeven bij opeenvolgende wijzigingen.

In dit schema is weergegeven dat een nieuwe versie van de RO Standaarden actueel wordt op het moment van inwerkingtreding. Dit betekent een aantal dingen, te weten:

het gebruiken van de nieuwe standaarden voor de inwerkingtreding is niet toegestaan. Uitzondering zou kunnen zijn bij het opstellen van een nieuw plan dat naar verwachting de formele Wro procedure ingaat op het moment dat de nieuwe standaard actueel is;

het gebruiken van de nieuwe standaarden na de inwerkingtreding is verplicht;

het gebruiken van de oude standaarden na de inwerkingtreding is alleen toegestaan bij lopende procedures (zie paragraaf 5.3 en 5.6).

5.3 Start van de formele procedure is leidend bij versiebepaling

Het bepalen welke versie van de RO Standaarden er gebruikt moet worden is eenvoudig te beantwoorden. Er wordt namelijk altijd gewerkt met de actuele versie van de standaarden op het moment dat de formele Wro procedure van start gaat. Bij het bestemmingsplan is dit het moment waarop het ontwerp ter inzage wordt gelegd (Wro artikel 3.8 eerste lid), bij veel andere instrumenten is dit gelijk aan het moment van vaststelling.

De procedure wordt afgemaakt -tot het moment dat het instrument onherroepelijk wordt- met dezelfde versie van de RO Standaarden die actueel was bij de start van de procedure. In de praktijk heeft dit wel tot gevolg dat er dus soms van standaard moet worden "gewisseld" voor aanvang van de formele procedure. Dat kan lastig zijn in individuele gevallen en vergt voldoende aandacht van de bronhouder om bijvoorbeeld tijdig software updates door te voeren.

5.4 Eén maal per drie jaar wijzigingen doorvoeren

In maart 2018 is in samenspraak met BZK besloten om de RO Standaarden 2012 niet meer te wijzigen en deze RO Standaarden 2012 te blijven gebruiken in aanloop naar en in verband met overgangsrecht onder de Omgevingswet. Zonder een business case te hebben gemaakt, is geconcludeerd dat op basis van de relevante wijzigingsverzoeken die de afgelopen jaren zijn gedaan, dat de kosten van een wijzigingsproces nu niet opwegen tegen de baten.

5.5 Vaste datum inwerkingtreding

Binnen een driejaarlijkse cyclus van wijzigingen zal er gewerkt worden met een vaste datum inwerkingtreding, te weten 1 januari. Dit uitgangspunt geeft voorspelbaarheid bij het werkveld. Het is op die manier ver van tevoren duidelijk wanneer er bepaalde inspanningen geleverd moeten worden.

5.6 Geen wijzigingsplicht voor eenmaal gepubliceerde plannen

Een planprocedure wordt gestart en doorlopen met één versie van de RO Standaarden. Het starten van de formele procedure is daarmee het uitgangspunt, bijvoorbeeld bij bestemmingsplannen is dit de datum waarop het ontwerp ter inzage is gelegd. Het wijzigen van de RO Standaarden zal dus nooit effect hebben op plannen die in procedure zijn. Maar ook plannen die onherroepelijk zijn geworden ondervinden geen effecten van het doorvoeren van toekomstige wijzigingen op de RO Standaarden, juist vanwege de betekenis van de term onherroepelijk. Dit alles kan worden samengevat in het uitgangspunt dat eenmaal gepubliceerde informatie nooit gewijzigd hoeft te worden ten gevolge van het doorvoeren van wijzigingen in de RO Standaarden.

5.7 Aanpassing van vorm- of technische aspecten van een gepubliceerd plan

Ambtelijk foutherstel in een ruimtelijke plan of besluit door de bronhouder is mogelijk zonder voorafgaand besluit. Dit valt onder het herstellen van de metadata c.q. de technische kenmerken van het ruimtelijk plan of besluit of het opheffen van inconsistenties in de planvoorraad tussen bronhouder en Ruimtelijkeplannen.nl. Dit is vastgelegd in de werkafspraak ‘Wijzigen reeds eerder gepubliceerde plannen’[^1].

[^1]: Zie ook Werkafspraak Wijzigen reeds eerder gepubliceerde plannen en de Handreiking “Data op orde”

De hoofdregel is dat foutherstel niet gaat over de inhoud van een plan of besluit, maar om vorm- of technische aspecten die van belang zijn voor blijvende raadpleegbaarheid, bruikbaarheid en toegankelijkheid van het plan. Bij gebreken aan de inhoud van het plan of besluit zal het bevoegd gezag een nieuw besluit moeten nemen of een nieuwe procedure moeten volgen.

6. Tussentijdse werkafspraken

Het toepassen van de RO Standaarden roept soms vragen op. Bij onduidelijkheden, discrepanties of fouten in de RO Standaarden kan de RO praktijk vragen hoe zij de Standaarden – in afwachting van een formele wijziging– moet toepassen. Omdat er wordt gewerkt in een driejaarlijkse wijzigingscyclus, zullen geconstateerde fouten of gewenste wijzigingen in de regel niet heel snel worden doorgevoerd in de formele RO Standaarden. Een tussentijds gebruiksadvies noemen we een werkafspraak. In dit hoofdstuk lichten we de werkwijze van werkafspraken toe.

Als er een fout of probleem wordt geconstateerd, zal er altijd geruime tijd overheen gaan voordat dit wordt hersteld in de formele standaard. Typische voorbeelden van dit soort fouten zijn in algemene zin:

de ene standaard hanteert voor een bepaalde aanduiding een andere spelling dan een andere standaard, waardoor je plan formeel nooit aan alle standaarden kan voldoen;
in de standaarden zijn bepaalde technische vrijheden mogelijk die op grond van een goede RO praktijk niet zouden moeten worden benut;
in de standaarden is iets wel mogelijk, maar niet verplicht, terwijl dit wel sterk gewenst is.

In dit soort gevallen zal Geonovum na consultatie van softwareleveranciers, BOR en TRIP een werkafspraak publiceren over hoe er in afwachting van formele reparatie moet worden omgegaan met een geconstateerd probleem. Zo’n werkafspraak heeft de formele status van een advies van Geonovum aan het RO werkveld. De werkafspraak kan nooit de wettelijk verankerde RO Standaarden vervangen, omdat de Wro geen mogelijkheden biedt om bevoegdheden tot het vaststellen van technische regels over te dragen aan de beherende instantie. Echter, het beheer van de RO Standaarden wordt uitgevoerd in opdracht van BZK, en BZK beschouwt het maken van werkafspraken met het RO werkveld in afwachting van reparatie als een onderdeel van het reguliere beheer.

Voor bovengenoemde voorbeelden zouden de werkafspraken er resp. als volgt uit kunnen zien:

hanteer altijd de spelling volgens standaard X;
gebruik nooit de mogelijkheid Y die de standaarden bieden;
doe het altijd op manier Z.

In Schema 5 is weergegeven in welke periode er werkafspraken gelden in afwachting van de volgende versie van de RO Standaarden.

In dit schema is weergegeven dat er voorafgaand aan de inwerkingtreding van een set met wijzigingen werkafspraken worden gemaakt die vooruitlopen op de aanstaande wijzigingen.

De status van deze werkafspraken is als volgt:

de werkafspraken zijn van toepassing totdat de wijzigingen in werking zijn getreden, daarna zijn ze niet meer van toepassing;
indien mogelijk zijn de werkafspraken altijd een directe voorloper van de wijzigingen zelf die zullen worden doorgevoerd. Vaak zal een werkafspraak een keuze bevatten. Deze zal goed beredeneerd zijn, maar toch anders kunnen uitvallen als het daadwerkelijke wijzigingsproces wordt ingezet;
binnen het wijzigingsbeheer worden er alleen werkafspraken gemaakt die vooruitlopen op aanstaande wijzigingen. Er worden binnen dit kader geen permanente werkafspraken gemaakt die niet verankerd zullen worden in de RO Standaarden;
het toepassen van de werkafspraken is van rechtswege niet verplicht, maar met name de leveranciers van RO Software hebben aan Geonovum aangegeven hier behoefte aan te hebben;
het toepassen van de werkafspraken vergemakkelijkt de implementatie van wijzigingen, omdat het een al een voorbereidende werkwijze is voor het ander;
waar van toepassing zullen de werkafspraken niet leiden tot afkeuring van plannen die hier niet aan voldoen door de Validator. Eventueel kan wel een waarschuwing of andersoortige melding worden gegeven over de geconstateerde afwijking van de werkafspraak.

7. Praktijkrichtlijnen

Met de invoering van de RO Standaarden 2012 is een strikte(-re) scheiding aangebracht tussen de bij ministeriële regeling verankerde normdocumenten (IMRO, IMROPT, SVBP, STRI) en de praktijkrichtlijnen (PRxx) die daar een zelfstandig leesbare toelichting op vormen. Dit is gedaan vanuit de visie dat op die manier de toelichting door de tijd heen verbeterd zou kunnen worden naar behoefte van het werkveld, zonder noodzakelijke wijziging aan de normen zelf en/of de tussenkomst van een besluit van de minister van BZK.

7.1 Norm versus toelichting

Geonovum vormt via de helpdesk, meldingsformulier, beheeroverleg, leveranciersoverleg en de overige kanalen een antenne naar het werkveld. Alle signalen worden vastgelegd in het registratiesysteem dat Geonovum gebruikt. Op basis van deze signalen uit het werkveld wil Geonovum graag een jaarlijks actualisatie uitvoeren van de praktijkrichtlijnen binnen de RO Standaarden waar nodig. Op die manier kunnen actuele problemen of thema’s nader worden toegelicht, zodat er binnen het werkveld op deze onderwerpen een beter begrip en een gemeenschappelijke werkwijze ontstaat. Naast de kwaliteitsimpuls die dit oplevert voorkomt het ook kosten bij met name de helpdesk RO Standaarden.

We hanteren twee procedures voor het wijzigen van de praktijkrichtlijnen: een lichte procedure en een zware procedure. De lichte procedure passen we toe voor ondergeschikte wijzigingen die een beperkte aanpassing voor de toepassing van de standaard in de praktijk meebrengen. De zware procedure passen we toe voor meer ingrijpende wijzigingen en/of wijzigingen die een grotere aanpassing voor de toepassing van de standaard in de praktijk meebrengen. Deze laatste zijn met name wijzigingen van de huidige werkwijzen of een totaal nieuwe werkwijze dan wel nieuwe onderwerpen. Dit protocol geldt zowel voor de praktijkrichtlijnen van de wettelijk geldende standaarden, als voor de facultatieve standaarden en praktijkrichtlijnen behorende bij de set RO Standaarden[^1].

[^1]: Het betreft hier bijvoorbeeld de standaarden voor digitale welstandsnota’s en voor plancontour en PDF. Zie Geonovum Website

7.2 Lichte procedure

De procedure start met een voorstel van Geonovum: inhoudelijk en procedureel (lichte of zware procedure);
Ieder moment gedurende het jaar kan de procedure worden gestart;
Van voorstel tot publicatie van de nieuwe versie duurt het wijzigingsproces maximaal 3 maanden;
De conceptversie wordt 1 keer met, softwareleveranciers, BOR en TRIP besproken, waarbij in het overleg bepaald wordt of dit voorstel wordt doorgevoerd dan wel de zware procedure in moet gaan vanwege de complexiteit of gevolgen in de praktijk;
Eventuele andere voorstellen en conceptversies tijdens deze procedure worden per mail afgehandeld.

7.3 Zware procedure

De procedure start met een voorstel van Geonovum inhoudelijk en procedureel (lichte of zware procedure);
Ieder moment gedurende het jaar kan de procedure worden gestart;
Van voorstel tot publicatie van de nieuwe versie duurt het wijzigingsproces maximaal 6 maanden;
De conceptversie wordt 1 tot 2 keer met , softwareleveranciers, BOR en TRIP besproken. Hiervan in ieder geval 1 keer plenair, en indien nodig nogmaals;
De praktijk wordt via een publieke consultatie gevraagd om mee te denken;
Eventuele andere voorstellen en conceptversies worden per mail afgehandeld.

8. Communicatie

Het hele wijzigingsproces staat of valt met een goede communicatie. Onder goede communicatie wordt verstaan het tijdig leveren van de juiste informatie aan de juiste belanghebbenden. In dit hoofdstuk wordt de integrale communicatie als apart proces beschreven. Er wordt ingegaan op zowel de proceskant alsook de producten die er worden gehanteerd.

8.1 Communicatieproces

In het onderstaande schema worden de procesmatige aspecten van de integrale communicatie omtrent de RO Standaarden gegeven. Schema 7 geeft aan wat er in welke fase verwacht kan worden.

8.2 Communicatieproducten

De volgende producten spelen een rol binnen het communicatieproces.

Business Case

De Business Case beschrijft de rechtvaardiging voor het opzetten en continueren van de wijzigingen. Geeft de redenen voor de wijzigingen; beantwoord het ‘waarom’ en bevat een overzicht van te verwachte kosten en baten. De Business Case wordt aangepast aan de actualiteit op belangrijke momenten in het proces.

Initiële Business Case

De eerste versie van de Business Case is samengevoegd met de eerste versie van het wijzigingsvoorstel. Voor ieder wijziging is een indicatie van de redenering waarom de wijziging nodig geacht is en wat de impact zou zijn op welke ketenpartners. Een overzicht (samenvatting) van het geheel maakt onderdeel uit van het set documenten. In dit document is “eerste versie wijzigingsvoorstel” nagenoeg uitwisselbaar met de “initiële Business Case” vanwege de samenhangende presentatie van de informatie.

Eerste versie wijzigingsvoorstel: Initiële Business Case

Het eerste concept wijzigingsvoorstel is de eerste versie van gebundelde wijzigingsverzoeken met bij ieder wijzigingsverzoek de Business Case informatie. Het is het eerste product dat tijdens de inhoudelijke fase wordt gepubliceerd. Dit voorstel is niet per sé een volledig uitgewerkte set wijzigingsverzoeken, maar het is een middel om bij software leveranciers, stedenbouwkundige bureaus, Ruimtelijkeplannen.nl en de Validator te kunnen toetsen of de oplossingsrichting en keuzes worden gedragen. Het wordt opgeleverd omstreeks halverwege de inhoudelijke fase en vormt het startpunt voor de toetsingsfase.

Tweede versie wijzigingsvoorstel: Eindconcept Business Case

Het tweede versie wijzigingsvoorstel, oftewel Eindconcept Business Case, is een tussenproduct in de toetsingsfase, en is de laatste inhoudelijke fase voor het definitieve Business Case. Dit product is een uitwerking van de eerste versie en is aangevuld/gecorrigeerd naar aanleiding van feedback op de Initiële Business Case en ervaringen binnen de RO keten. Doel van dit product is het voorleggen voor formeel advies bij TRIP en de stuurgroep DRO. Binnen het besluitvormingsproces door de Stuurgroep DRO kunnen er nog wijzigingen aangebracht worden in deze versie. Ook zou het kunnen voorkomen dat er slechts over een deel van het wijzigingsvoorstel een positief advies wordt gegeven.

Derde versie wijzigingsvoorstel: Definitieve Business Case

De derde versie wijzigingsvoorstel is een eindproduct van de technische tests op de voorgestelde wijzigingen en bijbehorende oplossingen, en is de laatste inhoudelijke fase voordat de keuze van wijzigingen definitief wordt. Deze versie is een “kandidaat” voor de definitieve wijzigingen, waar het werkveld mee aan de slag gaat. De principe keuzes zijn gemaakt dus is dit de Definitieve Business Case. Indien er geen fouten meer in deze versie gevonden worden, zal dit derde wijzigingsvoorstel de definitieve versie worden.

Werkafspraken

De werkafspraken die bepalen hoe er in de tussentijd moet worden omgegaan met geconstateerde fouten en problemen (zie Hoofdstuk 6). De werkafspraken publiceren wij via de Geonovum website, onderdeel RO Standaarden. Door middel van nieuwsberichten op de website en het versturen van de nieuwsbrief Wro Digitaal informeren wij het werkveld over de nieuwe dan wel aangepaste werkafspraak.

Praktijkrichtlijnen

Het jaarlijks actualiseren van de toelichting op de bij ministeriële regeling verankerde normdocumenten (zie Hoofdstuk 7).

Testdata

Samen met het opleveren van de Definitieve Business Case wordt er ook relevante testdata geleverd aan het werkveld voor wie daar mee aan de slag wil. Definitieve Business Case (derde versie wijzigingsvoorstel) en testdata horen dus bij elkaar. In principe gaat het om technische testdata. Dit is dus iets anders dan de voorbeeldplannen die worden gemaakt (zie hier onder).

Vastgestelde wijzigingen: definitieve wijzigingen

Na positief advies van TRIP, een formeel besluit van BZK en de Stuurgroep DRO en het afronden van de laatste toetsingsiteratie ten behoeve van foutcorrectie zijn de wijzigingen vastgesteld. De vastgestelde wijzigingen zijn de inhoudelijk definitieve versie en vormen het eindpunt van de besluitvorming en toetsing.

Wijzigingsdocumenten

Met het beschikbaar komen van de vastgestelde definitieve wijzigingen worden door Geonovum zogenoemde wijzigingsdocumenten beschikbaar gesteld. Hierin zijn de wijzigingen zichtbaar en voor een ieder inzichtelijk.

Nieuwe RO Standaarden

Met het beschikbaar komen van de vastgestelde wijzigingen worden door Geonovum ook beschikbaar gesteld een integrale set nieuwe RO Standaarden.

oorbeeldplannen

Samen met de vastgestelde wijzigingen worden soms ook voorbeeldplannen geleverd aan het werkveld voor wie daar mee aan de slag wil. Dit is echter afhankelijk van de wijziging van de verschillende normen van de standaarden. Niet voor alle plannen kunnen voorbeeldplannen worden aangedragen. Het gaat hier om realistische voorbeelden, die wellicht een aanpassing zullen zijn van de reeds bestaande set voorbeelden of van (aangepaste) bestaande plannen uit de praktijk. Dit is dus iets anders dan de technische testdata, die al in een eerder stadium beschikbaar zullen komen (zie hier boven).

Ministeriële Regeling

De vastgestelde wijzigingen zullen door BZK wettelijk worden verankerd in een ministeriële regeling. In principe is dit een regeling die wordt vastgesteld door de minister van BZK. In voorkomende gevallen, bij structurele uitbreidingen van de RO Standaarden zal de concept MR ter notificatie aangeboden moeten worden aan de lidstaten van de EU en de Europese Commissie (EC). In theorie kan een lidstaat of de EC dan nog bezwaar aantekenen, waardoor er toch nog wijzigingen noodzakelijk zouden zijn op de vastgestelde versie. Maar gezien eerdere ervaring met het geheel nieuwe pakket RO Standaarden 2008 (dat deze notificatieprocedure daadwerkelijk doorlopen heeft) en de grondslagen waarop bezwaar gemaakt zou kunnen worden, is deze exceptionele situatie niet gemodelleerd in het wijzigingsproces.

Resultaten conformiteitstoets

Bij substantiële wijzigingen zal Geonovum beoordelen dat Wro software geheel of gedeeltelijk opnieuw gecertificeerd moet worden. In dat geval worden de resultaten na afname van de conformiteitstoets bekend gemaakt als leveranciers deze conformiteitstoets positief hebben afgelegd. Daarmee vormen ze een communicatieproduct binnen het wijzigingsproces.

Besprekingsverslagen overleg softwareleveranciers

Geonovum organiseert een regelmatig overleg met de softwareleveranciers. In dit overleg worden de leveranciers tijdig geïnformeerd over aanstaande wijzigingen en wordt ook gevraagd om input aangaande voorgestelde wijzigingen. Van het overleg wordt een verslag gemaakt.

10. Actoren

In dit hoofdstuk worden de verschillende actoren in de RO keten beschreven die bij het wijzigingsproces betrokken zijn. Voor iedere actor wordt een omschrijving gegeven, en vervolgens worden de eigen noodzakelijke taken en verantwoordelijkheden aangegeven binnen het algemene wijzigingsproces.

Niet alle actoren zijn gedurende het hele proces betrokken bij het wijzigingsproces. In Schema 8 wordt een overzicht gegeven van de betrokkenheid van de actoren per fase. Verderop in dit hoofdstuk wordt dit per actor nader uitgewerkt.

Hier onder volgt per actor een beschrijving van de belangrijkste verantwoordelijkheden en mijlpalen.

10.1 Stuurgroep Digitale Ruimtelijke Ordening (SDRO)

De stuurgroep Digitale Ruimtelijke Ordening(SDRO fungeert als het opdrachtgever- / opdrachtnemeroverleg voor het beheer van de RO-Standaarden en Ruimtelijkeplannen.nl. De Stuurgroep DRO verzorgt de opdrachtsturing naar Kadaster (voor Ruimtelijkeplannen.nl) en Geonovum (voor zowel Ruimtelijkeplannen.nl als RO Standaarden) en komt minstens 2x per jaar bij elkaar.

De Stuurgroep DRO heeft geen (sturings)relatie met de overige overlegverbanden en ze is niet gericht op de behandeling van alle inhoudelijke zaken over het beheer en de ontwikkeling van de RO Standaarden. Over kleine adaptieve wijzigingen beslist Geonovum.

De Stuurgroep DRO is het besluitvormend orgaan met betrekking tot de kaders voor de verschillende beheeropdrachten aan Kadaster en Geonovum (budget, tijd, prioriteitstelling, planning&control, kwaliteit, bereik) én met betrekking tot de inhoud. Over die inhoud laat de Stuurgroep DRO zich adviseren door Kadaster en Geonovum en door het TRIP overleg. BZK kan zelf ook vanuit wetgevingsoogpunt een adviserende rol vervullen. De Stuurgroep DRO fungeert ook als stuurgroep bij majeure projectmatige vernieuwingen.

Voorgenomen wijzigingen moeten passen binnen de visie en binnen de daar uit voortkomende ontwikkelplannen over meerdere jaren én resp. binnen de concrete jaarplannen – zo niet moet dit tot bewuste wijziging en herprioritering leiden. Ze moeten ook een plek krijgen op de lijst van vernieuwingsprojecten.

10.2 Tripartite overleg (TRIP)

De RO Standaarden zijn met, voor en door het werkveld tot stand komen en worden ook samen in stand gehouden. De rol van het TRIP is om dringend, maar geen dwingend advies aan de Minister van BZK over voorgestelde wijzigingen. Het TRIP wordt daarbij gevoed door de opdrachtnemer, Kadaster, Geonovum en door hun eigen achterban (vanuit de ministeriële RO praktijk, de provincies en de gemeenten). Mogelijke escalatie tijdens de besluitvormingsfase vindt plaats via het overleg van de stuurgroep. Met name ook in de periode van vooroverleg is de rol van het TRIP van belang, omdat hiermee de basis wordt gelegd voor het draagvlak tijdens de besluitvormingsfase.

10.3 Beheeroverleg Ruimtelijkeplannen.nl (BOR)

Ruimtelijkeplannen.nl is gezamenlijk in beheer bij Geonovum en het Kadaster. Het beheeroverleg vindt gemiddeld negen keer per jaar plaats. Het beheeroverleg wordt gevormd door specialisten van zowel Geonovum en Kadaster voor het beheer van Ruimtelijkeplannen.nl. In het overleg worden alle voorkomende zaken besproken die te maken hebben met het functioneren van Ruimtelijkeplannen.nl.

10.4 Softwareleveranciers

Hier wordt met name bedoeld: de leveranciers van standaard software producten waarmee Wro instrumenten gemaakt en gepubliceerd kunnen worden. Het onderstaande schema is dan ook van toepassing op deze groep van softwareleveranciers.

Er zijn ook leveranciers van maatwerk software ten behoeve van specifieke RO taken, zoals de software die nodig is voor het ondersteunen van de BZK inspectie. De verantwoordelijkheden die dit met zich meebrengt zijn in dit protocol niet opgenomen, behalve in het geval van Ruimtelijkeplannen.nl en de Validator (zie volgende paragrafen), vanwege de bijzondere relatie en afhankelijkheden met andere actoren in het wijzigingsproces.

In dit schema is de betrokkenheid geschetst bij het toetsen van nieuwe ontwikkelingen in de periode D-24 tot D-12. Verder is het duidelijk dat de inspanningen met name tijdens de implementatiefase plaatsvinden. Er is aangegeven dat er wellicht eerder kan worden begonnen met het aanpassen van de software dan het moment waarop de formele besluitvorming (D-12) wordt afgerond. Dit is een verantwoordelijkheid van de individuele leveranciers, die een zelfstandige afweging maakt wanneer een wijzigingsvoorstel voldoende zeker is. De meeste leveranciers hebben er vertrouwen in zodra de Adviesgroep DRO een positief dringend advies heeft gegeven.

Ook het uitleveren van de nieuwe software kent geen harde startdatum. Op enig moment is een leverancier klaar met de aanpassingen en kunnen de updates worden uitgerold bij de klanten. In bovenstaand schema is er een startpunt gegeven op D-12. Dit heeft als reden dat op dat moment de Validator klaar is om de nieuwe standaarden te toetsen, waardoor het voor de leveranciers op dit moment ook pas mogelijk is om de eigen software extern te toetsen.

10.5 Stedenbouwkundige bureaus

Stedenbouwkundige bureaus werken dienstverlenend naar Wro bronhouders. Zij zijn betrokken bij het vervaardigen van plannen, zowel inhoudelijk als ook technisch. De verantwoordelijkheden van stedenbouwkundige bureaus zijn vergelijkbaar met die van de Wro bronhouders zelf (zie aldaar).

10.6 Validator

De Validator is een technische voorziening die toetst of ruimtelijke plannen aan de RO Standaarden voldoen. Hiermee heeft de Validator de rol van de neutrale scheidsrechter binnen de RO. Hoewel de technische voorziening momenteel is in beheer is bij het Kadaster, zijn de validatieregels in beheer van Geonovum . De Validator heeft een zelfstandige functie die breder is dan de poortwachter rol voor plannen richting Ruimtelijkeplannen.nl. De Validator toetst op een welbepaalde set validatieregels. Het beheer van deze validatieregels is ondergebracht binnen de beheerstructuur van de RO Standaarden zelf, om daar een optimale afstemming in te krijgen. Geonovum stelt de validatieregels op. Het Kadaster ontwerpt en beheert de Validator. Samen zorgen zij ervoor dat (een testversie van) de Validator op tijd te gebruiken is in het proces.

In bovenstaand schema is de bijzondere verantwoordelijkheid van de Validator te zien. Er wordt al in een vroeg stadium begonnen met het aanpassen van de Validator, mogelijk meteen al op het moment dat de inhoudelijke fase is afgerond. Dit komt omdat de softwareleveranciers op een later tijdstip afhankelijk zullen worden van de Validator om hun eigen, aan de wijzigingen aangepaste producten te kunnen toetsen. Ook de relatie met de conformiteitstoets, die gebruik maakt van de diensten van de Validator, ligt ten grondslag aan deze vooruitlopende activiteiten.

10.7 Ruimtelijkeplannen.nl

Ruimtelijkeplannen.nl is de landelijke voorziening die verantwoordelijk is voor het toegankelijk en raadpleegbaar maken van alle door de bronhouders beschikbaar gestelde ruimtelijke plannen. De verantwoordelijkheden zijn opgesplitst in enerzijds de website, en anderzijds de webservices. Deze webservices moeten eerder klaar zijn dan de website, omdat afnemers hier mogelijk van afhankelijk van zijn bij de implementatie van de wijzigingen in hun eigen processen en software. Ook Ruimtelijkeplannen.nl werkt vooruit op de definitieve besluitvorming[^1].

[^1]: Ruimtelijkeplannen.nl en Validator kennen ook een wijzigingsprotocol zoals deze voor de RO Standaarden. Het wijzigingsprotocol van Ruimtelijkeplannen.nl is te vinden via het Wijzigingsprotocol_RO-Online_v1.0

In bovenstaand schema is bovendien te zien dat er vanuit gegaan wordt dat Ruimtelijkeplannen.nl 6 maanden voor de inwerkingtreding van de wijzigingen helemaal klaar is om deze nieuwe bestanden te kunnen ontvangen. Deze marge is ingebouwd om ketentesten te kunnen uitvoeren tijdens de implementatie bij andere belanghebbenden.

10.8 Professionele afnemers

De term professionele afnemer is gekozen om een onderscheid te maken met burgers die ruimtelijke plannen willen inzien. De doelgroep burgers wordt niet gezien als een actor in het wijzigingsproces, ondanks dat zij wellicht de belangrijkste doelgroep zijn voor het raadplegen van de ruimtelijke plannen. Maar de professionele afnemers worden wel gezien als actor, omdat de wijzigingen een impact hebben of kunnen hebben op hun werkwijze.

10.9 BZK als wetgever

BZK is bronhouder van ruimtelijk instrumentarium. Maar BZK is ook de wetgever/beleidsmaker op het terrein van de ruimtelijke ordening en de Wro. Dit brengt bepaalde extra verantwoordelijkheden met zich mee binnen het wijzigingsproces. Dit zit met name in het feit dat er door de minister van BZK formeel wordt besloten over wijzigingen, omdat de minister van BZK de standaarden heeft verankerd bij ministeriële regeling. Ook het wettelijk doorvoeren van de wijzigingen, eventueel met inbegrip van de EU notificatieprocedure, wordt dus uitgevoerd door BZK als onderdeel van het wijzigingsproces.

N.B. Behalve wetgever is BZK ook bronhouder van ruimtelijke instrumentarium, zie volgende paragraaf.

10.10 Wro bronhouders

De Wro bronhouders zijn alle partijen die ruimtelijke plannen, visies, verordeningen, besluiten en AMvB's maken. Kortom, alle gemeentes, alle provincies en het Rijk.

In onderstaand schema is te zien dat bronhouders alleen bij de implementatiefase betrokken zijn. Dit doet de bronhouders geen recht. Echter, hun betrokkenheid bij inhoudelijke afwegingen, toetsing en besluitvorming loopt gecoördineerd via de softwareleveranciers en het TRIP, waar met name de bronhouders een belangrijke rol spelen.

10.11 Geonovum als beheerder van de RO Standaarden

Geonovum is de beheerder van de RO Standaarden en in die hoedanigheid nauw betrokken bij het gehele wijzigingsproces. Geonovum faciliteert alle bovenstaande processen. In onderstaande schema zijn alleen de eigen activiteiten weergegeven, de faciliterende activiteiten niet. Ook voor het gemak zijn producten maar één keer weergegeven in één fase hoewel ze bij verschillende fasen kunnen behoren (de voortgang van Business Case van initiëel, naar eindconcept naar definitieve is onlosmakbaar van respectievelijk de eerste, tweede en derde versies van de wijzigingsvoorstellen; daarnaast hoort inhoudelijke toetsing zowel onder Inhoud als Toetsing, etc).

Uit onderstaand schema blijkt vooral de voortdurende betrokkenheid van Geonovum als trekker van het beheerproces. De niet weergegeven faciliterende rol is geformaliseerd in de inrichting van het beheer. Geonovum is voorzitter van BROS en organiseert regelmatig overleg met andere betrokken zoals de softwareleveranciers[^2]. Verder wordt er in Hoofdstuk 8 nader ingegaan op de integrale aspecten van communicatie. Ook op die plek wordt aan de rol van Geonovum meer invulling gegeven.

[^2]: Meer algemene informatie over het beheer van de RO Standaarden is te vinden op de website van Geonovum

Versie	Datum	Status	Aanpassing door	Toelichting
1.0	juni 2009	Vervallen	Monique van Scherpenzeel	Publicatie na toetsing van protocol bij BROS, AdWro en softwareleveranciers
			Arie Duindam
			Remco Koenders
1.1.1	september 2010	Vervallen	Monique van Scherpenzeel	- Protocol actualiseren
			Erica Verkerk,	- Afstemming met protocol Ruimtelijkeplannen.nl
			Arie Duindam	- Aanpassing sluitingsdatum wijzigingsverzoeken
				- Datum D= 1 januari
				- Verwijdering fouten
1.1.2	november 2010	Vervallen	Erica Verkerk, Ruby Beltman	tekstuele aanpassingen
				aanpassing terminologie
1.2	december 2010	Vervallen	Arie Duindam	verwerken laatste opmerkingen
1.3	Februari 2016	Vervallen	Irina Entrop	- Lijst van afkortingen bij inhoudsopgave geactualiseerd en verplaatst naar leeswijzer
				- Tekstuele aanpassingen: RO-online vervangen door Ruimtelijkplannen.nl, I&M vervangen door IenM, Wijzigingverzoek vervangen door wijzigingsverzoek, Wijzigingvoorstel vervangen door wijzigingsvoorstel, Wijzigingplicht (paragraaf 5.2) vervangen door wijzigingsplicht
				- Adviesgroep digitale Wro (AdWro) verwijderd.
				- Het overleg van TRIP toegevoegd
				- Beheer overleg Ruimtelijkeplannen.nl (BOR) toegevoegd
				- Wijzigingsprotocol praktijkrichtlijnen (hoofdstuk 7) toegevoegd
				- Paragraaf 8.2 :
				-- tekst over praktijkrichtlijnen toegevoegd;
				-- ‘Wijzigingsbladen’ vervangen door ‘wijzigingsdocumenten’;
				-- Besprekingsverslagen AdWro verwijderd;
				- Besprekingsverslagen Stedenbouwkundige bureaus verwijderd.
				- Paragraaf 10.6 Stedenbouwkundige bureaus als actor aangepast naar alleen implementatie
				- Bijlage 1:
				-- Bij wettelijke verankerde standaarden de praktijkrichtlijnen verwijderd;
				-- Bij niet wettelijk verankerde standaarden de praktijkrichtlijnen toegevoegd;
				-- IMWE toegevoegd bij wettelijk verankerde standaarden;
				-- PRWE toegevoegd bij de niet wettelijk verankerde standaarden.
				- Colofon verwijderd
1.3.1	24 maart 2016	Vervallen	Irina Entrop en Monique van Scherpenzeel	Hoofdstuk 6 aangepaste inleiding; hiermee vervalt het separate, via de website beschikbare, memo ‘werkafspraken RO Standaarden van 14 januari 2010’.
1.3.2	Februari 2019	Werkversie	Irina Entrop en Monique van Scherpenzeel	- Ministerie van Infrastructuur en Milieu (IenM) vervangen door Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK)
				- Paragraaf 2.3 de link naar de meldingen RO Standaarden verwijderd
				- Beheergroep RO Standaarden (BROS) verwijdert uit het document.
				- Paragraaf 5.4 aangepast en geactualiseerd.
				- Paragraaf 5.6 aangepast en 5.7 toegevoegd m.b.t. wijzigen reeds gepubliceerde plannen.
	26 februari 2019	Definitief