Een Project Start Architectuur …...Een Project Start Architectuur Omgevingsvergunning voor het...

Een Project Start Architectuur Omgevingsvergunning voor het voorbeeldproject Overijssel

December 2007 Versie 1.0 Provincies Drenthe, Flevoland, Gelderland, Utrecht, Zeeland, Zuid-Holland Gemeenten Enschede en Zwolle

Samenhang voor samenwerking, Project Start Architectuur Omgevingsvergunning voorbeeldproject Overijssel

1


2

Voorwoord In 2007 heeft het vakberaad IOG-info van het Interprovinciaal Overleg opdracht gegeven aan een werkgroep om de Nederlandse overheid Referentie Architectuur (NORA) te toetsen op bruikbaarheid voor provincies. De toets is uitgevoerd aan de hand van een casus ‘de omgevingsvergunning’. De NORA bleek voor provincies geschikt en heeft geleid tot een waardevolle interventie vanuit het IPO naar VROM over de ontwikkeling van de LVO. Het IOG-info heeft aanvullend op dit onderzoek een leergang architectuur laten ontwikkelen voor alle provinciale architecten in wording. De eerste stroom leergangcursisten heeft het voorbeeldproject WABO-ICT van de provincie Overijssel en de provincie Noord-Brabant opgepakt en een projectstartarchitectuur (PSA)voor dit project opgesteld. Voor u ligt het resultaat van deze eerste leergang en de werkgroep architectuur. Omdat de omgevingsvergunning een ketensamenwerking betreft, is dit ook te zien in de deelnemers van de leergang. Gemeenten en provincies hebben in samenwerking de PSA inhoud gegeven. Als voorzitter van het IOG-info mag ik u deze PSA aanbieden. Ik hoop dat dit werk een vervolg krijgt bij de implementatie van de landelijke omgevingsvergunning. Het is van groot belang dat alle bestuurslagen de noodzakelijke ketensamenwerking goed met elkaar afstemmen en binnen hun gebied inrichten. Dit instrument biedt daarvoor uitstekende aanknopingspunten en is een voorbeeld voor het werken onder architectuur in gemeenschappelijkheid. Samen werken kan en het samenwerken onder architectuur biedt de samenhang die wij overheden nodig hebben om complexe ketenprocessen te realiseren. Jan Bruijn, teamleider FD Informatisering en Projecten, provincie Overijssel Voorzitter IOG-info a.i.


3

Samenvatting In 2005 is door het ministerie van VROM de omgevingsvergunning geïntroduceerd. Het afgeven van een omgevingsvergunning vergt veel coördinatie, regie en samenwerking. Alle bestuurslagen zijn betrokken bij de WABO en de daaraan gekoppelde omgevingsvergunning. Een dergelijk veranderingsproces binnen de Nederlandse overheid wordt op kleine schaal uitgeprobeerd. Voor de omgevingsvergunning is binnen de provincies Overijssel en Noord Brabant een voorbeeldproject WABO-ICT ingericht. Dit voorbeeld project test de landelijke voorziening omgevingsloket als onderdeel van het vergunningverleningproces waarbij de verschillende bestuurslagen (gemeente, provincie en waterschap) zijn betrokken. Gemeenten, provincies en waterschap zijn onderdeel van een overheid waar digitaal werken de norm is. Het presteren van de overheid in termen van zichtbaarheid, bereikbaarheid, handelssnelheid en producteffectiviteit wordt digitaal meetbaar. De overheid wil digitalisering strategisch inzetten. Dit aspect is bij de uitwerking van de WABO en de omgevingsvergunning dan ook nadrukkelijk aan de orde gesteld. Dit rapport levert een bijdrage aan het voorbeeldproject WABO-ICT. Het rapport is een projectstartarchitectuur. Deze PSA is samen met het plan van aanpak voor de projectleider de basis voor zijn voorbeeldproject. Context van het voorbeeldproject WABO-ICT Het voorbeeldproject is een stap naar de e-overheid. Het is ketensamenwerking rondom omgevingsvergunning”. Vijfentwintig verschillende vergunningen worden gecombineerd in één aanvraag of een dienst. Het ministerie van VROM bouwt een applicatie “Landelijke Voorziening Omgevingsloket”. Deze toepassing zal het digitale loket worden voor het aanvragen van een omgevingsvergunning. De omgevingsvergunning kan niet zonder werken onder architectuur. Voor de overheid betekent dit dat de Nederlandse Overheid Referentie Architectuur (NORA) leidend is. Deze PSA is opgesteld door bedrijfsarchitecten van provincies en gemeenten. Inhoud Specificatie diensten vanuit WABO Diensten worden kanaalonafhankelijk geleverd. Dit wil zeggen dat een bedrijf of burger kan kiezen voor een aanvraag indienen bij de balie, door de LVO te gebruiken en daar een elektronisch formulier in te vullen of door telefonisch te informeren hoe het met zijn aanvraag staat. De diensten gaan over organisatiegrenzen heen. Specificatie procesverloop De diensten en producten worden geleverd door verschillende processen. Elke processtap voegt waarde toe aan het proces en levert een bijdrage aan het resultaat. Belangrijk voor burger en bedrijf is de status van de vergunningaanvraag, die inzicht geeft in de fasen van behandeling. De focus van de ketenpartners moet liggen bij het afstemmen van de procesbesturing. Hier wordt bedoeld businessprocesmanagement en zaakmanagement. De procesondersteuning met behulp van workflowmanagement regelen de individuele overheidsorganisaties intern.


4

Specificatie berichtenverkeer Het werken in ketens vereist eenduidige berichtenuitwisseling tussen de bestuurslagen. Een aanvrager dient via de LVO zijn aanvraag in. Vervolgens zorgen het LVO en het bevoegd gezag voor een betrouwbare afhandeling van de aanvraag. Deze afhandeling vindt plaats door berichtenuitwisseling. De berichten moeten functioneel benoemd en afgestemd worden op semantisch niveau met verdere detaillering naar het gegevensniveau. Specificatie technologie Het voorbeeldproject maakt gebruik van de beschikbare technologie bij de gemeente Enschede. Het betreft een testomgeving, die na afloop van het voorbeeldproject WABO-ICT ontmanteld wordt. Belangrijk voor de technologie is het beschikbaar zijn van gestandaardiseerde XML berichten uit de LVO en een middleware laag bij het bevoegd gezag (NORA 7.1.1). Evaluatie De projectstartarchitectuur is opgesteld in samenwerking van de gemeenten Enschede en Zwolle en de provincies Gelderland, Drenthe, Zeeland, Flevoland, Zuid Holland en Utrecht. Samen werken aan deze architectuur levert voor burger en bedrijven eenduidige dienstverlening en help de overheid haar dienstverlening in samenhang vorm en inhoud te geven. De opstellers van dit document hebben de volgende kanttekening gemaakt:

• Essentiële bouwstenen e-overheid (GBA, BAG, Percelen, Handelsregister, Overheidsservicebus, DigiD-bedrijven, etc.) zijn niet op tijd gereed. Voorlopig is een suboptimale dienstverlening het gevolg.

• Hierdoor is sprake van toenemende complicering van projectaanpak. (Zie verder rapport Algemene Rekenkamer over overheids ICT-projecten van 26 november 2007)

• Er is grote behoefte aan inhoudelijke regie. • Het ontwikkelen van een generiek procesmodel op bedrijfsprocesniveau (zie NORA) voor alle

bestuurlagen is gewenst. • Het is mogelijk om objectmodellen op elkaar aan te laten sluiten. Zodoende is aansluiting op het

stelsel van basisregistraties nu en in de toekomst mogelijk • De hoofdstukken beheer en beveiliging zijn minimaal ingevuld. Voor het voorbeeldproject was dit

nog niet urgent. Conclusies De samenstellers van deze projectstartarchitectuur willen afsluitend de volgende conclusies met de lezer delen:

• Werken onder architectuur kan zorgen voor samenhang en samenwerking • Architectuur maakt inhoudelijke regie mogelijk. • NORA zorgt voor inpassing in e-overheid, mits architecten de ruimte krijgen. • Samen ontwikkelen van architectuur en specifiek voor bedrijfsprocesmodellen is noodzakelijk om

regie aan de keten te geven. • Zorg voor geïntegreerde objectmodellen zodat aansluiting van huidige ontwikkelingen in de

toekomst geborgd zijn binnen het stelsel van basisregistraties. VNG, IPO en VROM moeten dit gezamenlijk oppakken.

• Begin nu vast met het uitwerken van het beheer voor de LVO en werk beveiliging verder uit. Dit hebben de bestuurslagen nodig voor een betrouwbare vergunningverlening.

• Een flexibele digitale ondersteuning voor de ketenpartners is gewenst. Door “couleur locale” zullen verschillende dienstverleningsafspraken gemaakt worden.


5

Inhoudsopgave 1 Inleiding ............................................................................................................................................ 9 1.1 Opdracht ............................................................................................................................................ 9 1.2 Resultaat.......................................................................................................................................... 10 1.3 Opdrachtgever-opdrachtnemer........................................................................................................ 10 1.4 Versiebeheer.................................................................................................................................... 10 1.5 Distributielijst .................................................................................................................................... 11 1.6 Aanpak............................................................................................................................................. 11 1.6.1 NORA............................................................................................................................................... 12 1.7 Referenties....................................................................................................................................... 13 1.8 Leeswijzer ........................................................................................................................................ 14 2 Project............................................................................................................................................. 15 2.1 Context............................................................................................................................................. 15 2.1.1 Aanleiding ........................................................................................................................................ 15 2.1.2 Doelstellingen van de WABO........................................................................................................... 15 2.1.3 Doelstellingen en scope voorbeeldproject WABO-ICT .................................................................... 15 2.2 Beleid ............................................................................................................................................... 17 2.2.1 Visie ................................................................................................................................................. 17 2.2.2 Klanten............................................................................................................................................. 17 2.2.3 Ketenpartners .................................................................................................................................. 17 2.2.4 Dienstverlening ................................................................................................................................ 17 2.2.5 Kanalen en media ............................................................................................................................ 18 2.2.6 Gezamenlijke voorzieningen............................................................................................................ 18 2.2.7 Fundamentele principes................................................................................................................... 20 2.3 Huidige situatie ................................................................................................................................ 23 2.3.1 Huidige werkwijze ............................................................................................................................ 23 2.3.2 Knelpunten....................................................................................................................................... 24 2.3.3 Afwijking van de nieuwe strategie.................................................................................................... 24 2.4 Producten, diensten en services...................................................................................................... 25 2.5 Distributiekanalen en media............................................................................................................. 26 2.5.1 Distributiekanalen ............................................................................................................................ 26 2.5.2 Media ............................................................................................................................................... 26 2.6 Principes en standaarden ................................................................................................................ 27 2.6.1 Generieke principes voor ketenprocessen....................................................................................... 27 2.6.2 Standaarden en Richtlijnen.............................................................................................................. 28 3 Bedrijfsarchitectuur....................................................................................................................... 30 3.1 Organisatie....................................................................................................................................... 30 3.1.1 Architectuurprincipes ....................................................................................................................... 32 3.1.2 Taken en verantwoordelijkheden ..................................................................................................... 32 3.1.3 Aanvullende architectuurprincipes ................................................................................................... 33 3.2 Diensten en services........................................................................................................................ 34 3.2.1 Architectuurprincipes ....................................................................................................................... 34 3.2.2 Dienstencatalogus ........................................................................................................................... 36 3.2.3 Servicecatalogus.............................................................................................................................. 36 3.2.4 Bedrijfsfunctiemodel......................................................................................................................... 38 3.3 Processen ........................................................................................................................................ 39


6

3.3.1 Inleiding en theorie........................................................................................................................... 39 3.3.2 Architectuurprincipes ....................................................................................................................... 40 3.3.3 Samenhang bedrijfsproces “Verlenen vergunning”.......................................................................... 41 3.3.4 Schema en toelichting...................................................................................................................... 41 4 Alternatieven gewenste situatie ................................................................................................... 48 4.1 Uitgangspunten en aannames ......................................................................................................... 48 4.2 Relevantie architectuurprincipes...................................................................................................... 49 4.3 Organisatievormen........................................................................................................................... 50 4.3.1 Loket zonder case-manager ............................................................................................................ 50 4.3.2 Loket met case-manager ................................................................................................................. 50 4.4 Alternatieven samenwerking............................................................................................................ 51 4.4.1 Alternatief 1 : Volledig gebruik LVO ................................................................................................. 51 4.4.2 Alternatief 2: Uitwisseling via LVO ................................................................................................... 52 4.4.3 Alternatief 3: Uitwisseling tussen Bevoegd Gezag en Adviserend Orgaan ..................................... 54 4.5 Aanvullende architectuurprincipes ................................................................................................... 55 5 Uitwerking voorkeursoplossing Informatiearchitectuur ............................................................ 57 5.1 Mensen en applicaties ..................................................................................................................... 57 5.1.1 Architectuurprincipes ....................................................................................................................... 58 5.1.2 Applicatielandschap ......................................................................................................................... 59 5.1.3 Informatieverwerkers ....................................................................................................................... 59 5.2 Berichten en gegevens .................................................................................................................... 60 5.2.1 Architectuurprincipes ....................................................................................................................... 60 5.2.2 Objectmodel..................................................................................................................................... 63 5.2.3 Berichtencatalogus .......................................................................................................................... 68 5.3 Informatie uitwisseling...................................................................................................................... 79 5.3.1 Architectuurprincipes ....................................................................................................................... 79 5.4 Servicebussen ................................................................................................................................. 79 6 Uitwerking voorkeursoplossing Technische architectuur......................................................... 81 6.1 Applicaties en koppelvlakken........................................................................................................... 81 6.1.1 Gebruikte architectuurprincipes ....................................................................................................... 81 6.1.2 Applicaties........................................................................................................................................ 82 6.1.3 Situatieschets beoogde componenten en koppelvlakken ................................................................ 84 6.1.4 Koppelvlak identificatie .................................................................................................................... 84 6.1.5 Koppelvlakspecificatie...................................................................................................................... 85 6.2 Gegevensopslag .............................................................................................................................. 86 6.3 Middleware....................................................................................................................................... 86 6.4 Platformen........................................................................................................................................ 86 6.5 Netwerk............................................................................................................................................ 87 7 Beheer............................................................................................................................................. 89 7.1 Beheer van de landelijke voorziening .............................................................................................. 89 7.2 Beheer van de voorzieningen bij de ketenpartner ........................................................................... 89 7.3 Beheeraspecten keten ..................................................................................................................... 90 8 Beveiliging en privacy ................................................................................................................... 91 8.1 Eisen en Architectuurprincipes ........................................................................................................ 91 8.2 Beveiligingsaspecten keten ............................................................................................................. 92 8.3 Autorisatie ........................................................................................................................................ 93


7

Bijlagen......................................................................................................................................................... 94 Bijlage A - Coördinatievarianten voor case-management ............................................................................. 95 Bijlage B - Schematische weergave plateaus ............................................................................................. 100 Bijlage C – Relatie met “Hoofdprocessen” voorbeeldproject ....................................................................... 101


8


9

1 Inleiding Wanneer een burger of een bedrijf een huis, fabriek of schuur wil bouwen, verbouwen, oprichten of gebruiken, krijgt deze te maken met veel vergunningen en voorschriften voor wonen, ruimte en milieu. Deze hebben elk hun eigen criteria, procedures, loketten, afhandelingtermijnen, leges en toezichthouders. Daarnaast zijn de voorschriften soms tegenstrijdig. Dit is onoverzichtelijk en tijdrovend en kost veel geld. Gemeenten, provincies en waterschappen gaan de verschillende vergunningen zoveel mogelijk bundelen in de omgevingsvergunning. Deze kan bij één loket worden aangevraagd. Er gaat één procedure gelden, waarop één besluit volgt. Ook komt er één beroepsprocedure. Om dit alles te kunnen bereiken, gaan de decentrale overheden in ketens samenwerken. Dit is een hele uitdaging. Er moeten op organisatorisch gebied veel afspraken worden gemaakt: “wie is waarvoor verantwoordelijk?”, “wie bewaakt de termijnen?”, “wie int de leges?”. Daarnaast moeten er op het gebied van informatie-uitwisseling duidelijke afspraken zijn: “hoe komt de aanvraag binnen?”, “hoe worden de diverse berichten op een gestandaardiseerde wijze vormgegeven?”, “Hoe zien de koppelvlakken eruit?”. Een eerste stap van de informatie-uitwisseling wordt gemaakt door het ministerie van VROM. Deze ontwikkelt één digitaal loket, waarin burgers en bedrijven hun aanvraag kunnen invullen en vervolgens kunnen verzenden naar het bevoegd gezag. Dit digitale loket is de Landelijke Voorziening Omgevingsloket (LVO). Voordat de LVO breed wordt ingezet, is het belangrijk deze eerst te testen. Op deze manier kan nuttige ervaring worden opgedaan, voordat alle overheden erop aansluiten. VROM heeft Overijssel en Noord-Brabant gevraagd dit digitale loket, in samenwerking met enkele ketenpartners, functioneel te testen. Het is goed vooraf na te denken over de principes en uitgangspunten die er voor een optimale informatie-uitwisseling in de ketensamenwerkingsverbanden belangrijk zijn. De Nederlandse Overheidsreferentie architectuur (NORA) bevat de inrichtingsprincipes van de elektronische (één-)overheid: als alle overheden deze standaarden toepassen, wordt de weg naar één-overheid gelegd.

1.1 Opdracht Het voorbeeldproject WABO-ICT test het nieuwe digitale loket voor het doen van aanvragen van de omgevingsvergunning (LVO). De opdracht van de werkgroep Architectuur richt zich op de pilot in de Provincie Overijssel. De opdracht is als volgt verwoord: “Maak op basis van de Nederlandse Overheids Referentie Architectuur (NORA) een projectstartarchitectuur (PSA) voor het pilotproject in Overijssel.”


10

1.2 Resultaat Het projectresultaat bestaat uit een projectstartarchitectuur (PSA) voor het pilotproject in Overijssel. In deze PSA worden generieke richtlijnen uitgewerkt ten behoeve van de aansluiting op de landelijke voorziening omgevingsloket (LVO). Deze zijn bruikbaar voor alle ketenpartners die bij de invoering van de omgevingsvergunning betrokken zijn. Daarnaast beschrijft deze PSA specifieke aandachtspunten voor de Overijsselse situatie. Deze bieden mogelijk nuttige inzichten bij de vormgeving van de overige ketensamenwerkingsverbanden. Het beoogde effect:

• De ketenpartners zijn in staat op een uniforme wijze gebruik te maken van de landelijke voorziening omgevingsloket van het VROM.

• De samenwerking in ketens op het gebied van vergunningaanvragen en vergunningverlening wordt vereenvoudigd.

Het projectresultaat is bruikbaar voor projectleiders, architecten en ontwerpers die bij de ketenpartners (gemeenten, provincies en waterschappen) betrokken zijn bij de implementatie van de omgevingsvergunning.

1.3 Opdrachtgever-opdrachtnemer De opdrachtgever is de Interprovinciale Overleggroep Informatievoorziening (IOG-info). De opdracht wordt uitgevoerd door de hieronder genoemde personen. Naam Functie Organisatie André Batenburg Senior informatiearchitect Provincie Zuid-Holland Aart Allemekinders Informatie analist Provincie Zeeland Jan Boerstra Organisatieadviseur Provincie Flevoland Annemarie van Grunsven Adviseur Informatievoorziening Provincie Utrecht Frank Herik Gemeente Enschede Ali Hoekstra Provincie Drenthe Marrie Hol Beleidsadviseur ICT Gemeente Zwolle Freddie Janssen Informatie adviseur Provincie Gelderland Simone Rodenburg Adviseur ontwikkeling

dienstverlening Gemeente Enschede

Anneke Spijker Senior beleidsmedewerker Provincie Flevoland Albert ten Oever Architect / procesbegeleider Imac Architectuur

Academie / Novius

1.4 Versiebeheer Versie Datum Wie Wijziging 0.1 24 oktober 2007 AtO Samenvoeging materiaal n.a.v. cursusblok 1 0.2 1 november 2007 AtO Samenvoeging materiaal n.a.v. cursusblok 2 0.3 15 november 2007 AtO Samenvoeging materiaal n.a.v. cursusblok 3


11

0.4 4 december 2007 AB Samenvoeging materiaal n.a.v. cursusblok 4 0.5.1 6 december 2007 AA Revisie hoofdstuk 6 en 8, invulling hoofdstuk 7 0.5.2 7 december 2007 AB Revisie hoofdstuk 4 0.5.3 8 december 2007 AB Revisie hoofdstuk 3, nieuw plaatje hoofdstuk 4 0.5.3 8 december 2007 AB Revisie Hoofdstuk 2, toevoeging bijlagen 0.5.3 8 december 2007 AvG Revisie inleiding (opdrachtbeschrijving, aanpak,

leeswijzer) en hoofdstuk 2 0.5.3 8 december 2007 AS Samenvatting 0.5.4 9 december 2007 AvG Redactie, samenvoegen 0.5.5 9 december 2007 AB Revisie hoofdstuk 5 0.5.6 9 december 2007 AB Afstemming hoofdstuk 6, 7 en 8, plaatje hoofdstuk 5 0.6 10 december 2007 AvG Redactie

1.5 Distributielijst Gremium Naam Rol Interprovinciale overleg groep informatievoorziening Koos Ju secretaris Interprovinciale overleg groep geoinformatie Koos Ju secretaris Interprovinciale overleg groep documentaire informatievoorziening

Koos Ju secretaris

Projectgroep voorbeeldproject WABO-ICT Jacques Duijvenvoorden

Projectleider

WABO platform projectleiders Freerk Mink Voorzitter Programmaoverleg WABO Joke de Vroom Programma

manager Project LVO Marc de Rooij projectleider VNG project WABO-ICT Kees Duijvelaar projectleider Unie van Waterschappen: waterschapshuis Richard Gankema projectleider

1.6 Aanpak Ten behoeve van het voorbeeldproject Overijssel wordt een projectstartarchitectuur opgesteld. Deze PSA geeft principes en uitgangspunten mee aan het project. De basis van deze principes bevindt zich in de NORA1, de eerdere doorvertaling van de NORA naar de WABO2 en de PSA van de LVO3.

1 Nederlandse Overheid Referentie Architectuur (NORA), ICTU

1.6.1 NORA De NORA definieert ‘architectuur’ op basis van de breed gedragen definitie van IEEE4

Figuur 1 Definitie Architectuur IEEE 1471 De term ‘systeem’ dient hier breed opgevat te worden. Het kan gaan over een applicatie, een afdeling van een organisatie, de organisatie als geheel of de gehele e-overheid. Om welke componenten het gaat is afhankelijk van het soort architectuur waarover wordt gesproken. Voorbeelden van componenten zijn: organisatieonderdelen, processen, administraties en ICT-systemen. Een architectuur bestaat – in het kort – uit ontwerpprincipes en modellen en gezichtspunten al naar gelang de belangen en doelen van de belanghebbenden. De modellen geven de componenten weer en hun onderling relatie. De NORA bevat de inrichtingsprincipes van de elektronische overheid: een set van multilaterale inrichtingsprincipes en omvat het gehele publieke domein, met zijn vele honderden overheidsorganisaties. Om tot een eerste indeling te komen, is in 2002 binnen de overheid gewerkt aan de ontwikkeling van een metamodel: een raamwerk voor architecten5. Dit raamwerk is de basis geworden voor de structuur van de NORA. Hieronder wordt het raamwerk kort geïntroduceerd.

Architectuur is de beschrijving van de fundamentele opbouw van een systeem, bestaande uit:

• zijn componenten;• hun onderlinge relaties en die tot hun omgeving;• de principes voor hun ontwerp en evolutie.

modellen

principes

Bedrijfsarchitectuur

Informatiearchitectuur

Technischearchitectuur

TechnischeComponenten

MedewerkersApplicaties

Organisatie

Wie

Gegevens-opslag

BerichtenGegevens

DienstenProducten

Wat

Netwerk

Informatie-uitwisseling

Processen

Hoe

Beheer

Beveiliging

Eisen van:

Europa

NL overheid

Bedrijven

Burgers


12

2 NORA – WABO, Vertaling van NORA-principes naar inrichtingkeuzes voor de implementatie van de WABO, Werkgroep Architectuur, in opdracht


13

Figuur 2 Architectuurraamwerk Het raamwerk kent drie architectuurlagen, te weten:

- de bedrijfsarchitectuur; - de informatiearchitectuur; - de technische architectuur.

Naast de drie lagen worden drie kolommen onderscheiden:

- Wie neemt actie: organisaties, informatieverwerkers (personen en applicaties) en machines/computers;

- Wat wordt geleverd: diensten, berichten, gegevens; - Hoe gebeurt dit: processen, communicatie, integratie en netwerk.

Daarnaast zijn er nog twee generieke dimensies: beveiliging en beheer. Deze dimensies hebben hun impact op alle vlakken.

1.7 Referenties Voor het maken van de PSA hebben de onderstaande documenten als input gediend: Nr Omschrijving [1] Programma van Eisen Landelijke Voorziening Omgevingsvergunning, VROM

[2] Startarchitectuur Landelijke Voorziening Omgevingsvergunning, VROM

[3] PvE Bijlage Gegevenswoordenboek, VROM

[4] Nederlandse Overheid Referentie Architectuur (NORA), ICTU

[5] Wetsontwerp, BOR, MOR

[6] Implementatie ICT-voorzieningen omgevingsvergunning (IVO), VROM

[7] Plan van Aanpak Voorbeeldproject Omgevingsvergunning, Overijssel en Noord-Brabant.

[8] NORA – WABO, Vertaling van NORA-principes naar inrichtingkeuzes voor de implementatie van de WABO

[9] Functioneel ontwerp Landelijke Voorziening Omgevingsloket, Be Value

[10] Eindrapportage Pilot Invoering Omgevingsvergunning, Koninklijke Ten Cate – gemeente Hellendoorn –

waterschap Regge en Dinkel – provincie Overijssel

[11] Zaken in Zicht, GFO-Zaken

[12] Concept DIV-katern NORA

van Interprovinciaal Overleg (IPO). 3 Startarchitectuur Landelijke Voorziening Omgevingsvergunning, VROM 4 Definitie van architectuur volgens recommended practice IEEE 1471: “Architecture: the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution”. IEEE Standard for Architectural Description of Software-Intensive Systems (IEEE P1471/D5.3) 5 Architectuur Elektronische Overheid, van den Dool, Keller en Wagenaar , 11-2002 versie 2.0


14

[13] Concept aanvulling Hoofdstuk 9 NORA voor informatiebeveiliging ketens

[14] Interne memo voorbeeldproject “Overzicht digitaal berichtenverkeer tussen LVO, Bevoegd Gezag (Provincie)

en Adviseurs (Gemeenten en Waterschappen)”

1.8 Leeswijzer

Hoofdstuk 2 beschrijft het project waarvoor deze PSA wordt gemaakt, het pilotproject in Overijssel. Daarbij gaat het in op de context en de afbakening. Hoofdstuk 3 beschrijft de bedrijfsarchitectuur. Hoofdstuk 4 geeft mogelijke alternatieven voor de gewenste situatie. Hoofdstuk 5 geeft een uitwerking van de voorkeursoplossing op het gebied van de informatie architectuur. Het gaat daarbij in op mensen en applicaties, berichten en gegevens en informatie-uitwisseling. Hoofdstuk 6 werkt de voorkeursoplossing uit op het gebied van de technische architectuur. Het geeft aandacht aan de technische componenten, gegevensopslag en netwerk. Tot slot gaan hoofdstuk 7 en 8 over de lagen “Beheer en Beveiliging” uit het NORA-model.


15

2 Project

2.1 Context

2.1.1 Aanleiding Het ministerie van VROM introduceerde in 2005 de “omgevingsvergunning”. Deze vergunning dient vanaf 1-1-2009 onder meer de bouwvergunning, de milieuvergunning en diverse vergunningen op basis van provinciale en gemeentelijke verordeningen te integreren tot één omgevingsvergunning. Het achterliggende doel is daarbij vermindering van de regeldruk bij gelijkblijvende of lagere lasten voor de overheid, burger en ondernemer. De provincies zien de omgevingsvergunning als kans om zowel ten aanzien van de regeldruk, ten aanzien van de bedrijfsvoering, als ten aanzien van de dienstverlening, een aantal forse slagen te maken. Daarnaast kan de implementatie van de omgevingsvergunning als hulpmiddel dienen waarmee de samenwerking tussen gemeenten, waterschappen en provincie kan worden geïntensiveerd. De provincies Overijssel en Noord-Brabant zijn na een consultatieronde geselecteerd door het ministerie van VROM om een “voorbeeldproject WABO-ICT” te starten. In deze PSA staat de provincie Overijssel centraal.

2.1.2 Doelstellingen van de WABO De doelstellingen van de WABO zijn:

• Minder administratieve lasten voor bedrijven en burgers; • Betere dienstverlening door de overheid aan bedrijven en burgers; • Kortere procedures; • Geen tegenstrijdige voorschriften.

Om deze doestellingen te realiseren is het volgende nodig:

• Samenwerking tussen bevoegd gezag en adviserende overheidsorganen. • Informatie-uitwisseling tussen aanvraag en behandeling; • De samenwerkende overheden de landelijke voorziening omgevingsvergunning gebruiken samen

met de aanvrager; • Handhaving wordt in een vervolg opgepakt.

2.1.3 Doelstellingen en scope voorbeeldproject WABO-ICT Het doel van het voorbeeldproject is drieledig:

• opstellen van service-georiënteerde procesbeschrijvingen (conform business process management) om de interactie met het LVO in zijn ketencontext te modelleren.

• het inrichten van een proefopstelling in de diverse decentrale infrastructuren op basis van de opgestelde service-georiënteerde procesbeschrijvingen en deze testen op de bruikbaarheid van en de interactie met het LVO, uitgaande van de aanbevelingen die het interprovinciale informatie-architectenoverleg (IOG-Info) heeft opgesteld.

• Lessons learned m.b.t. de implementatie en de resultaten van de testcases t.b.v. kennisdeling met andere provincies.


16

Om dit traject goed af te bakenen is een opsomming gemaakt van welke componenten expliciet buiten het voorbeeldproject vallen (naast kennisdeling):

• Het vergunningverleningproces zelf van de niet provinciale deelnemende partners; • Het organisatorische verandertraject bij de provincies om de processen in de toekomst optimaal de

WABO te laten ondersteunen; • Implementatie van de voorzieningen in de productieomgeving; • De inrichting van beheer van de proefomgeving en productieomgeving en daarmee ook bv.

changemanagement (denk aan wetswijzigingen); Daarnaast worden de volgende beperkingen in het voorbeeldproject in acht genomen:

• In de bedrijfsprocessen van de ketenpartners zijn we alleen op zaakmanagement-niveau geïnteresseerd (zoals een externe klant van gemeente of waterschap).

• Als de provincie voor advies een deel van een complexe vergunning uitzet bij een ketenpartner, gedraagt zij zich ten opzichte van die partner zoveel mogelijk als cliënt.

• Ontoereikende componenten (werkprocessen of LVO) worden óf geaccepteerd (als basis/proefmateriaal) of gesimuleerd met snel beschikbaar materiaal. Van belang is, dat het testen van de voorzieningen, werkprocessen en samenhang op voldoende niveau kan plaatsvinden.

• Voor het werkproces wordt ervan uitgegaan, dat de ter beschikking staande vergunningstandaarden/modules actueel en compleet zijn. Als tijdens het Voorbeeldproject anders blijkt, wordt er geen (of zeer beperkte) tijd ingestoken om die standaarden te verbeteren.

• Onderling worden afspraken gemaakt over de aandacht die in het kader van het Voorbeeldproject aan Documentaire Informatie en verdere GIS-toepassingen wordt besteed.


17

2.2 Beleid

2.2.1 Visie Uit de externe ontwikkelingen is duidelijk dat gemeenten, provincies en waterschappen onderdeel zijn van een overheid waarin digitaal de norm is. Hun prestaties, in termen van zichtbaarheid, bereikbaarheid, afhandelsnelheid, producteffectiviteit, zullen steeds meer digitaal meetbaar zijn. Daarom is het van strategisch belang producten niet alleen goed in de overheidsmarkt te zetten, maar daarbij ook de digitale mogelijkheden mee te wegen. De missie op het gebied van digitalisering is dan ook: strategische inzet van digitalisering in de ontwikkeling van gemeenten, provincies en waterschappen. Deze missie is binnen de context van het project WABO te vertalen naar een visie. De omgevingsvergunning is één geïntegreerde vergunning voor de fysieke leefomgeving, die moet leiden tot minder administratieve lasten voor bedrijven en burgers, betere dienstverlening door de overheid aan bedrijven en burgers, kortere procedures en geen tegenstrijdige voorschriften. Deze doelstellingen passen binnen de volgende visie: Gemeenten, provincies en waterschappen …

- leveren diensten in digitale ketens aan de klant; - werken samen om te komen tot e(én)-overheid; - oefenen invloed uit op landelijke kaders en dragen bij in de uitvoering van die kaders; - houden de informatiehuishouding toekomstvast en sluiten daarbij maximaal aan op landelijke

bouwstenen van de e-overheid en de mogelijkheden om te komen tot gemeenschappelijke beheerorganisaties voor ICT.

2.2.2 Klanten Burgers en bedrijven die zich aan het oriënteren zijn of werkelijk een aanvraag voor de omgevingsvergunning in willen dienen, gemachtigden die namens hen opereren; Belanghebbenden, geïnteresseerden die dossiers willen inzien.

2.2.3 Ketenpartners Gemeenten, provincies, waterschappen en ministeries (ministeries van VROM, EZ, OCW, LNV), zijn de ketenpartners waarbij, afhankelijk van het type klant, één van de partijen het bevoegd gezag is en de andere partij(en) adviserend overheidsorgaan. Binnen de context van dit voorbeeldproject zijn de ketenpartners:

- Gemeente; - Provincie; - Waterschap.

2.2.4 Dienstverlening Bij de aanvraag voor een omgevingsvergunning kan onderverdeeld worden op basis van een onderscheid in het kennisniveau van de aanvrager (niet of nauwelijks bekend met de materie / bekend met de materie)


18

én de aard van de aanvraag (complex / eenvoudig). Afhankelijk van het kwadrant wordt de dienstverlening in gestoken. Complex Eenvoudig Bekend met de materie Vooroverleg, samen

begeleiden, afstemmen eisen. Inzet vergunningmanager. Kanaal: mondeling/ balie

Indieningvereisten zijn duidelijk: geen vooroverleg, strakke ontvankelijkheid beoordeling. Kanaal Internet

Niet of nauwelijks bekend met de materie

Advisering deskundige in te huren. Kanaal: eventueel bedrijvenloket of KvK

Via informatie deskundigheid vergroten. Kanaal Internet

Tabel 1: Dienstverlening ingedeeld naar kennisniveau aanvrager en aard aanvraag

2.2.5 Kanalen en media Er wordt aangesloten bij het NORA-principe dat alle kanalen openstaan. Burgers en bedrijven zullen gestimuleerd worden in het gebruik van de (voor de overheid) goedkopere dienstverleningskanalen, zoals internet, elektronische formulieren en klant contact centra.

2.2.6 Gezamenlijke voorzieningen In deze paragraaf is onderscheid gemaakt in:

- Noodzakelijk voor LVO = Landelijke Voorziening Omgevingsvergunning - Noodzakelijk voor BG / AO = Bevoegd Gezag c.q. Adviserend Overheidsorgaan (provincie,

gemeente). Aan de hand van het Programma van Eisen LVO en de Startarchitectuur LVO zijn de volgende registraties geïdentificeerd: Registraties LVO BG/AO Nieuw HandelsRegister (NHR) – voor basisgegevens over bedrijven X X Basisregistratie Adressen en Gebouwen (BAG) – voor basisgegevens over de ligging van inrichtingen, dit is een samentrekking van de Basis Gebouwen Registratie (BGR) en Basis Registratie Adressen (BRA)

X X

Landelijke Raadpleegbare Deelverzameling (LRD) – voor basisgegevens over personen, een service die is gebaseerd op de gegevens in de Gemeentelijke Basis Administratie (GBA)

X X

Gemeentelijke Basis Administratie – voor basisgegevens over personen X X Basis Registratie Kadaster (BRK) – voor basisgegevens over de ligging van inrichtingen op het niveau van percelen

X X

Basis Registratie Topografie (BRT) – als referentiegegeven voor de projectie van de ruimtelijke ligging van inrichtingen en percelen

X

Landelijke machtigingsvoorziening – voor het machtigen van natuurlijke personen door de aanvrager

X


19

Daarnaast zijn aan de hand van het Programma van Eisen LVO, de Startarchitectuur LVO en het overzicht van de bouwstenen van de E-overheid de volgende bouwstenen (buiten de registraties) geïdentificeerd: Overige bouwstenen LVO BG/AO Persoonlijke Internet Pagina (PIP) – voor persoonlijke ontsluiting van informatie X X DigiD – voor authenticatie X X BurgerServiceNummer (BSN) – voor identificatie van burgers X X Beheervoorziening BSN – een service voor het ophalen van een set basisgegevens horende bij het BSN

X X

Bedrijven- en Instellingen Nummer (BIN) – voor identificatie van bedrijven en instellingen

X X

Beheervoorziening BIN – een service voor het ophalen van een set basisgegevens horende bij het BIN

X X

Overheidszoekdienst – voor publicatie op Internet X X E-formulierenvoorziening – voor het invullen van digitale formulieren X Bedrijvenloket – dé ingang van de overheid op internet voor alle ondernemers die informatie van de overheid nodig hebben. Ook biedt de site in de nabije toekomst mogelijkheden om gegevens uit te wisselen en transacties met de overheid uit te voeren – zoals het aanvragen van vergunningen. Het Bedrijvenloket wil ervoor zorgen dat ondernemers op één plaats de antwoorden vinden op al hun vragen aan de overheid bijvoorbeeld over wetten en regels. In de toekomst kunnen onder-nemers daar ook direct de daarmee samenhangende formaliteiten in gang zetten

X X

Overheidstransactiepoort (OTP) - ondersteunt en bevordert elektronische communicatie tussen bedrijfsleven en burgers enerzijds en overheden anderzijds. Het is hét elektronische postkantoor voor bedrijven (en burgers) die de gemeenschappelijke infrastructuur verzorgt voor onderling berichtenverkeer. Overheden en bedrijven hoeven hun gegevens slechts eenmalig aan te leveren waarna de Overheidstransactiepoort zorgt voor meervoudig gebruik. Het resultaat is een administratieve lastenverlichting voor zowel de overheid als het bedrijfsleven.

X X

Het project heeft behoefte aan een bouwsteen voor het uitvoeren van autorisatie. Gezocht is naar een bouwsteen van de E-overheid hiervoor. Die blijkt er niet te zijn. Wel zijn er aparte autorisatievoorzieningen, die bijvoorbeeld te vinden zijn in de architectuur voor de GBA (Startpakket GBA) en de architectuur voor de basisregistratie voor adressen. Bij de laatste worden in het kader van de beveiliging van de landelijke voorziening de volgende principes genoemd:

- Voor de beveiliging van de functionaliteit wordt gebruik gemaakt van authenticatie op basis van gebruikersnaam / wachtwoord;

- Voor aanbrengen van onderscheid in de benaderbaarheid van functionaliteit wordt gebruik gemaakt van autorisatie op basis van rollen, toegekend aan de combinatie gebruikersnaam/wachtwoord. Deze rechtenstructuur zal centraal worden bijgehouden.

Er is dus geen landelijke autorisatievoorziening. De NORA zegt hierover het volgende: “Gebruikers van overheidsadministraties, burgers, bedrijven en ambtenaren, mogen niet zonder meer service en gegeven betrekken. Er moet sprake zijn van een doel dat verbonden is met hun taak. Dit heet het doelbindingsprincipe in de Wet Bescherming Persoonsgegevens. Autorisatie van afnemers voor


20

services en gegevens is daarmee een e-overheidsbrede aangelegenheid. Of dit dan ook kan en moet gaan leiden tot een e-overheidsbrede autorisatievoorziening is echter nog zeker niet duidelijk. Een belangrijk probleem daarbij is dat de autorisatiestructuren en/of voorzieningen binnen de meeste overheidsorganisaties nog niet zodanig ver zijn ontwikkeld, dat zij kunnen dienen als fundament onder een mogelijk overheidsbrede autorisatieaanpak en –voorziening”.

2.2.7 Fundamentele principes In deze PSA worden op meerdere plaatsen architectuurprincipes behandeld. In dit hoofdstuk zijn de generieke ketenprincipes die de overheid hanteert voor dit project uitgewerkt. Uitgangspunt is dat deze principes ook zullen gelden voor andere ketenprocessen. In de volgende hoofdstukken worden de architectuurprincipes van de NORA nader gespecificeerd naar het pilotproject in Overijssel. Onderstaand volgt de doorvertaling van de twintig fundamentele principes van de NORA naar de Omgevingsvergunning. Vijf van deze principes zijn als meest belangrijk aangemerkt omdat deze rechtstreeks zijn te koppelen aan de WABO (P2, P8, P17, P19 en P20). Deze vijf principes zijn vetgedrukt. Fundamenteel principe uit de NORA Doorvertaling P1. Diensten via internet: organisaties in het publieke domein verlenen hun diensten aan burgers, bedrijven en maatschappelijke instellingen via het internet (elektronisch loket) en stimuleren het gebruik van dit kanaal.

De LVO voor de WABO is het elektronische loket. Stimulering vindt plaats doordat het gebruik van dit loket verplicht is voor Bedrijven.

P2. De bestaande kanalen zoals post, telefoon en balie blijven beschikbaar, zodat burgers, bedrijven en maatschappelijke instellingen gebruik kunnen maken van het kanaal van hun keuze.

Dit principe is van belang omdat in het ketenproces meerdere overheidsdiensten meedoen met een verschillend niveau van digitalisering. Dit maakt het nodig dat dezelfde informatie via de verschillende kanalen beschikbaar komt.

P3. Organisaties in het publieke domein geven een helder, vindbaar beeld van de diensten en producten die burgers, bedrijven en maatschappelijke organisaties van hen kunnen afnemen. Daartoe zijn hun elektronische loketten benaderbaar via landelijke ingangen zoals de website www.overheid.nl (één loketgedachte, no wrong door).

De LVO is een dergelijk loket. De klant moet via een loket van de provincie doorgeleid kunnen worden naar de LVO en omgekeerd.

P4. Organisaties in het publieke domein bieden hun diensten (producten) bij voorkeur aan in voor de klant logische bundels per (soort) gebeurtenis aan de kant van de klant (geboorte, huwelijk, starten bedrijf) en werken daartoe samen met andere organisaties in het publieke domein (onestop-shopping).

De branchewijzers van de LVO moeten zorgen voor de vindbaarheid van de informatie voor de klant.

P5. Burgers, bedrijven en maatschappelijke instellingen beschikken over één identiteit die

Volgens het PvE van de LVO krijgen klanten toegang tot de LVO door DigiD voor Personen


21

Fundamenteel principe uit de NORA Doorvertaling bruikbaar is voor alle contacten met organisaties in het publieke domein en die afhankelijk van de soort dienstverlening ook nodig is en gevraagd moet worden. Dit ongeacht de keuze voor een kanaal. Een en ander komt neer op één administratieve identiteit (één identificatienummer). Deze administratieve identiteit dient afgebeeld te worden op een(ook digitaal toepasbaar) identiteitsbewijs.

en DigiD voor Bedrijven. Klanten die daarover niet kunnen beschikken maken gebruik van LDAP. Overheden maken gebruik van LDAP.

P6. Om een vlotte dienstverlening mogelijk te maken leggen organisaties in het publieke domein routinematig uit te voeren controles binnen het primaire dienstverleningsproces. De noodzakelijke controles worden zo uitgevoerd dat een snelle en soepele dienstverlening plaatsvindt. Meer specifieke controles vinden in beginsel via afzonderlijke processen, parallel of achteraf plaats (eerst mensen, dan regels).

Controles die simpel en mechanisch toetsbaar zijn vinden plaats in het aanvraagformulier. Inhoudelijke controles vinden volgens de PSA van de LVO plaats in de processtap “ontvangen en besluit tot (niet) in behandeling nemen”.

P7. Organisaties in het publieke domein kennen een transparante en toegankelijke klachten en bezwarenprocedure.

Volgends de PSA van de LVO vindt de verwijzing naar het proces “bezwaar en beroep” plaats in de processtap “administratief behandelen”.

P8. Eénmaal uitvragen van gegevens, meermalen gebruiken; de organisaties in het publieke domein zullen burgers en bedrijven niet opnieuw om gegevens vragen die bij de overheid al bekend zijn.

Dit principe is van belang vanwege de volgende raakvlakken: gebruik van landelijke basisregistraties, voor provincies met name voor bedrijven het formulier stelt precies die vragen die voor de aanvraag relevant zijn ruimtelijke informatie over de fysieke leefomgeving maakt voor de klant toetsbaar of de aanvraag zinvol is systematiek van vastleggen van objectgegevens over de feitelijke, vergunde, handhavingsituatie.

P9. Organisaties in het publieke domein streven naar zo laag mogelijke administratieve lasten en een zo laag mogelijke regellast voor burgers, bedrijven en maatschappelijke organisaties.

Dit wordt gerealiseerd door meervoudig gegevensgebruik, productintegratie en procesharmonisatie.

P10. Organisaties in het publieke domein zorgen voor een eenvoudige regelgeving, in omvang beperkt, onderling consistent en goed controleerbaar en handhaafbaar.

De WABO is hierop gericht.

P11. Organisaties in het publieke domein De WABO is hierop gericht.


22

Fundamenteel principe uit de NORA Doorvertaling geven aan op welke momenten welke stadia in het dienstverleningsproces doorlopen dienen te zijn en streven daarbij naar zo kort mogelijke doorlooptijden. P12. Organisaties in het publieke domein geven burgers, bedrijven en maatschappelijke instellingen inzicht in de status van voor hen lopende dienstverleningsprocessen (transparante, traceerbare dienstverleningsprocessen).

De statusinformatie wordt geleverd door het bevoegd gezag. Hiervoor staan nog twee opties open:

• vanuit de LVO • vanuit de website van het bevoegd

gezag. Beide opties vragen om gestandaardiseerde berichtuitwisseling.

P13. Organisaties in het publieke domein zorgen dat zij naar burgers, bedrijven en maatschappelijke instellingen periodiek verantwoording afleggen over de kwaliteit van de gerealiseerde dienstverlening.

Dit valt vooralsnog buiten de scope van dit traject. Wel draagt het traject bij aan twee randvoorwaarden:

• integraal systeem voor vergunningverlening en handhaving

• publicatie van besluiten van vergunningverlening en handhaving

P14. Organisaties in het publieke domein ontsluiten algemene overheidsinformatie, waaronder weten regelgeving.

Dit valt buiten de scope van dit traject.

P15. Organisaties in het publieke domein maken zichtbaar wat zij doen, welke besluiten zij nemen, welke gegevens zij hebben en gebruiken en wat hun werkwijze is.

Het besluit wordt kenbaar gemaakt en gepubliceerd door het bevoegd gezag. Hiervoor staan nog twee opties open:

• vanuit de LVO • vanuit de website van het bevoegd

gezag. Beide opties vragen om gebruik van het Internet Publicatie Model.

P16. Organisaties in het publieke domein attenderen burgers en bedrijven op voor hen relevante diensten (pro-actieve dienstverlening), maar bieden ruimte voor eigen regie en verantwoordelijkheid door burgers en bedrijven op de feitelijke afname van diensten(zelfwerkzaamheid). Daarbij verstrekken organisaties begrijpelijke informatie, bijvoorkeur geïndividualiseerd, over rechten, plichten en mogelijkheden voor burgers en bedrijven.

Dit valt buiten de scope van dit traject.

P17. Organisaties in het publieke domein organiseren zich als een onderdeel van een integraal opererende en als eenheid optredende overheid, die in haar handelen naar burgers, bedrijven en

Dit principe is van belang omdat de Omgevingsvergunning vraagt om samenwerking in de keten. Het bevoegd gezag is hiervoor de ketenregisseur die met de adviserende overheden afspraken maakt


23

Fundamenteel principe uit de NORA Doorvertaling maatschappelijke instellingen consistent en betrouwbaar is.

over het niveau van dienstverlening.

P18. Organisaties in het publieke domein gebruiken gegevens die accuraat, actueel en volgens wettelijke normen beveiligd zijn en delen die gegevens met andere organisaties in het publieke domein.

Het delen van gegevens verloopt via de LVO.

P19. Gebruik waar mogelijk generieke componenten. Organisaties in het publieke domein streven er naar om beschikbare gemeenschappelijke voorzieningen te gebruiken, als deze op de punten functionaliteit, beveiliging en kosten gelijkwaardig zijn aan individuele voorzieningen.

De LVO is hier de generieke component die functionaliteit levert voor: brancheteksten

• vragenboom • aanvraagformulier • delen formele documenten (nog

optioneel) • ontkoppelpunt voor

gegevensuitwisseling • geven van statusinformatie • publicatie besluiten

P20. Standaardiseer waar mogelijk koppelvlakken en hiermee samenhangende componenten. Organisaties in het publiek domein streven er naar hun koppelvlakken en hiermee samenhangende componenten te standaardiseren, waardoor het eenvoudiger wordt om in ketens samen te werken en gebruik te maken van generieke voorzieningen.

De LVO levert een verzameling van standaardberichten voor uitwisseling op basis van de gegevensdefinities van het gegevenswoordenboek

2.3 Huidige situatie

2.3.1 Huidige werkwijze Momenteel moet een aanvrager voor een initiatief meerdere vergunningen aanvragen eventueel bij verschillende overheidsinstanties welke gevestigd zijn op verschillende locaties en elk hun eigen indieningvereisten kennen. Gevolg hiervan is dat gegevens dubbel worden uitgevraagd en tegenstrijdige voorschriften worden afgegeven. Door gebrek aan samenwerking wordt de aanvrager geconfronteerd met onnodig hoge kosten voor het aanvragen van de benodigde vergunningen en krijgt een onsamenhangend pakket van voorschriften terug. Er is geen overleg of afstemming tussen overheden. Kort samengevat leidt dat tot de volgende kenmerken:

- Iedere wet heeft eigen inhoud en procedure; - Veel verschillende voorzieningen voor procedurele coördinatie; - Fasering door keuze vergunningen; - Aanvragen alleen bij het “eigen” loket; - Elke aanvraag volgt eigen procedure;


24

- Iedere wet heeft eigen toetsingskader, maar er is een beperkt aantal voorzieningen voor inhoudelijke afstemming;

- Per vergunning een bevoegd gezag; - Elke aanvraag leidt tot een afzonderlijk besluit; - Elke vergunning heeft eigen bezwaar- en beroepsregels.

2.3.2 Knelpunten In geval van een complexe aanvraag dienen verschillende aanvragen te worden ingediend bij verschillende overheidsorganisaties. De wijze van aanvagen, de opzet van de invulformulieren en de verdere verwerking van de aanvraag zijn zeer divers. Bovendien moet de aanvrager dezelfde gegevens meerdere malen invullen. Dit is een zeer diverse omgeving met een groot aantal knelpunten. Enkele voorbeelden hiervan zijn:

- Er is geen een inhoudelijke afstemming: de diverse besluiten voor één “werk” kunnen conflicteren/strijdig zijn met elkaar.

- Gegevens worden op papier via de verschillende kanalen ontvangen. Deze gegevens worden op verschillende plaatsen opgeslagen, gekopieerd, etc. Naarmate het aantal ambtenaren dat betrokken is bij de afhandeling van een aanvraag, minder is, zijn de problemen minder groot. Voor elektronische aanvragen van omgevingsvergunningen geeft dit mogelijk problemen, namelijk:

o Het vergroot de kans op inconsistente informatie; o Het geeft beperkingen in voortgangsbewaking; o Het leidt tot langere doorlooptijden om statusinformatie te kunnen geven.

- De huidige vergunningsystemen zijn nog niet geschikt om alle gegevens van een omgevingsvergunning op te slaan:

- Vaak zijn het systemen voor een beperkt aantal, veel voorkomende vergunningen (dit zijn services in de context van de dienst ‘omgevingsvergunning’);

- Ook zijn de processen vaak ingericht voor de volledige ondersteuning van een bepaalde service en bevatten mogelijk gelijksoortige of strijdige stappen als de omgevingsvergunning wordt ingevoerd (denk aan de ontvankelijkheidtoets).

2.3.3 Afwijking van de nieuwe strategie Het huidige proces en de bijbehorende ICT-ondersteuning moet aanzienlijk worden aangepast:

- Gewijzigde wetgeving zal zorgen voor nieuwe procesinrichtingen en verantwoordelijkheden; - Meervoudig gegevensgebruik: alle relevante vergunningen worden in de nieuwe situatie

geïntegreerd tot één omgevingsvergunning; - Kanaalintegratie: dit heeft veel impact op de front-office processen van de bij de

omgevingsvergunning betrokken instanties; - Dossiervorming: nu is de informatie versnipperd over de verschillende overheidsinstanties. In de

nieuwe opzet wordt gestreefd naar een eenduidige bron van informatie; - Samenwerking: Er zal veel intensiever moeten worden samengewerkt dan in de huidige opzet.

2.4 Producten, diensten en services

Het WABO-project is gericht op het leveren van één dienst: de omgevingsvergunning. In onderstaand schema is een opsomming gegeven van producten en diensten die op het voorbeeldproject betrekking hebben. Producten Omgevingsvergunning Diensten Behandelen van omgevingsvergunning

Handhaven van omgevingsvergunning Behandelen van zienswijzen Behandelen van bezwaar en beroep

Services Oriëntatiemogelijkheid voor klant op LVO


25


26

Vragenboom voor indienen omgevingsvergunning aanvraag Dossieropbouw rondom omgevingsvergunning Het aan kunnen vragen van de omgevingsvergunning via het digitale kanaal Proactief attenderen op omgevingsvergunning aanvragen en voortgang Communiceren tussen ketenpartners voor behandelen omgevingsvergunning In kunnen dienen van zienswijzen via het digitale kanaal In kunnen dienen van bezwaar en beroep via het digitale kanaal Adviesvragen uitzetten bij adviespartijen Publiceren van vergunningen en bekendmakingen Beschikbaar stellen van status/dossierinformatie aan het LVO Beschikbaar stellen van status/dossierinformatie aan de klant Verstrekken van een besluit aan de klant

2.5 Distributiekanalen en media

2.5.1 Distributiekanalen De distributiekanalen zijn de gemeente, de provincie en het Rijk. Welk distributiekanaal wordt gebruikt, is per aanvraag verschillend. Het Rijk ligt buiten de scope van dit voorbeeldproject.

2.5.2 Media Het medium is de manier waarop het kanaal met de klant communiceert, m.a.w. hoe de klant binnenkomt. Bij de omgevingsvergunning staat de klant centraal. Bij de communicatie tussen overheidsinstelling en klant (burger, bedrijf) staat de keuzevrijheid van de te gebruiken media centraal. Medium Hoe Digitaal LVO Website bevoegd gezag / adviserend overheidsorgaan Email Elektronisch berichtenverkeer via services Telefonisch Regionaal loketfunctie Coördinatorfunctie bevoegd gezag Behandelend ambtenaar bevoegd gezag / adviserend overheidsorgaan Fysiek transport Post Koeriervracht Persoonlijk Baliefunctie gemeente / regionale milieudienst Overleg met behandelend ambtenaar Inrichtingseisen zijn:

- De klant heeft de keuze uit de verschillende media. Bestaande media zoals post, telefoon en balie blijven bestaan. Het gebruik maken van het medium internet en webintake van LVO wordt maximaal gestimuleerd;


27

- De ontvangst van een aanvraag leidt tot één zaak die mediumonafhankelijk wordt afgehandeld; - De status van de aanvraag wordt ontsloten via het zaaksysteem van Bevoegd Gezag en wordt

dusdanig ontsloten dat het ook via het LVO kan worden benaderd; - Aanvullende informatie bij een aanvraag wordt via het LVO ingebracht.

2.6 Principes en standaarden

2.6.1 Generieke principes voor ketenprocessen Deze paragraaf beschrijft generieke principes voor ketenprocessen, waaronder de WABO. Een ketenproces van de overheid gaat uit van:

- één integrale blik op de levensloopsituatie van de aanvrager - één loket voor aanvraag en informatie - één aanvraag - één bevoegd gezag - één procedure - één handhavend bestuursorgaan

Voor het project WABO geldt:

- Bij het organiseren van de intake en de afhandeling van de aanvraag is de levensloop van de aanvrager het uitgangspunt en kan de aanvrager de regie over de aanvraag voeren;

- Bij de inrichting van de voorzieningen is de zelfredzaamheid van de aanvrager uitgangspunt; - Voorafgaand aan de formele aanvraag is er ruimte voor de aanvrager om overleg te voeren met

het bevoegd gezag en adviserende overheidsorganen; - De aanvrager is verantwoordelijk voor de ingediende informatie, ook als deze digitaal worden

verwerkt; - De informatie die de aanvrager aanlevert wordt vertrouwelijk behandeld en niet actief gepubliceerd.

Informatie van overheidswege over de aanvraag is openbaar en burgers en bedrijven kunnen verzoeken om inzage, tenzij het vertrouwelijke of geheime informatie is;

- Bij de intake van de aanvraag wordt een bepaald gegeven maar één keer gevraagd en wordt gebruik gemaakt van de gegevens van eerdere aanvragen door de aanvrager;

- De vormgeving van de aanvraag is neutraal, waarbij wel duidelijk is dat de voorziening van de Nederlandse overheid is en welke overheidsinstantie het loket en welke het bevoegd gezag is;

- Bij de intake van de aanvraag wordt rekening gehouden met kwetsbare groepen (ouderen, allochtonen, geestelijk en visueel gehandicapten);

- Het loket voor de aanvrager is de gemeente. De aanvrager kan ook de aanvraag direct bij het bevoegd gezag indienen. De gemeente wordt daarover geïnformeerd. Bij afwijkende aanleveringen geldt het principe “no wrong door”;

- Het bevoegd gezag kent een coördinatorfunctie die procesverantwoordelijk is; - Het bevoegd gezag heeft door middel van advies of verklaring van geen bezwaar de mogelijkheid

om een andere regeling incidenteel te integreren met de vergunning; - De verleende vergunning is raadpleegbaar voor aanvrager, vergunningverlener en handhaver; - De voorzieningen voldoen aan de NORA en de GBO Overheid kan de voorzieningen beheren.


28

2.6.2 Standaarden en Richtlijnen

Aan de hand van het Programma van Eisen LVO en de Startarchitectuur LVO zijn de volgende standaarden geïdentificeerd: Algemeen Versie NORA – voor architectuurprincipes 2.0 Rijksbrede themalijst – voor taxonomie OSOSS – voor open standaarden en open source Beveiliging Versie Voorschrift Informatiebeveiliging Rijksdienst VIR 2007 Code van informatiebeveiliging ISO 17799:2005 Website Versie Stijlgids Rijksoverheid – voor vormgeving Schrijfwijzer begrijpelijke formulieren – voor gebruiksgemak formulieren Redactionele richtlijnen – voor redactie van formulieren Formulierenwijzer – voor redactie van formulieren Specificaties papieren vraagformulieren VROM – voor vormgeving van formulieren

Richtlijnen vraagformulieren beeldscherm VROM – voor vormgeving van formulieren

Webrichtlijnen van de overheid – technische en functionele richtlijnen websites

Drempels Weg richtlijnen – technische en functionele richtlijnen websites

Web Content Accessibility Guidelines – technische en functionele richtlijnen websites

1.0

Usability richtlijnen – technische en functionele richtlijnen, vormgeving en redactie

Berichtenuitwisseling Versie Internet Publicatie Model (IPM) – voor publicatie van informatie op Internet

3.0

XBRL – voor gegevensuitwisseling GFO-Zaken – voor koppelvlak met statusinformatie 2.05 StUF-ZKN –voor berichten over zaken 2.00 StUF-BG – voor gemeentelijke basisgegevens 2.04 OGO Ongestructureerde gegevens Versie Archiefwet en archiefbesluit 1995 – voor archivering DoD5015.2, ISO 15489 en MoReq – voor recordmanagement Regeling geordende en toegankelijke staat archiefbescheiden 2002 Rapport Rekenkamer “Beheer en archivering van digitale bestanden”


29

1998 Dublin Core – voor metadatering PDF/A – voor uitwisselen van documenten met open standaarden Overig versie XSD/XML – voor uitwisselen van berichten met open standaarden SOA – voor het uitwisselen van berichten via services LDAP – voor authenticatie buiten DigiD en voor autorisatie van gebruikers binnen overheidsorganisaties voor de LVO

PKI – voor authenticatie op basis van certificaten bij berichtenuitwisseling (statusberichten, publicatieberichten, dossier-archiveringberichten)

Defacto standaarden voor tekstverwerking en rekenbladen: .doc, .xls, .ppt, .odt, .ods

Defacto standaarden voor bestanden met tekeningen: .jpeg, .tiff, .dwf HTTPS / SSL– voor een beveiligd berichtentransport TCP/IP – voor netwerkprotocol

3 Bedrijfsarchitectuur

Actuele thema’s bij de bedrijfsarchitectuur volgens de NORA zijn doelstellingen (strategie), politiek en beleid, maar ook reorganisatie en herinrichting van processen, bijvoorbeeld als gevolg van nieuwe technologische mogelijkheden. Een goed voorbeeld hiervan is de één-loket gedachte. Met de komst van het internet werd het mogelijk dat klanten via meer (dienstverlenings-)kanalen - multi-channel - een overheidsorganisatie konden benaderen: niet alleen via het loket, maar ook via het web, e-mail of per telefoon. De bedrijfsarchitectuur bestaat uit drie aspecten: • overheidsorganisaties, die samen de e-overheid vormen: het "wie" • diensten, die overheidsorganisaties aan burgers en bedrijven leveren (en ook aan elkaar): het "wat" • processen, waarmee deze diensten worden voortgebracht: het "waar en wanneer". De met een “*” gemarkeerde onderdelen vallen buiten de scope van het voorbeeldproject. Bij de principes wordt tussen haakjes eventueel verwezen naar de principes van de NORA (zie dan refnr. [4]).

3.1 Organisatie In de Startarchitectuur Landelijke Voorziening Omgevingsvergunning (zie refnr. [2]) staat beschreven welke actoren bij een omgevingsvergunning zijn betrokken en wat hun rollen zijn: • Burgers en organisaties. Dit zijn burgers of medewerkers van organisaties. Zij kunnen de volgende

rollen hebben: o Aanvrager: een persoon die een aanvraag indient.


30

o Gemachtigde: een persoon die door een aanvrager gemachtigd is aanvragen namens hem te verrichten. Vanuit het perspectief van de bedrijfsarchitectuur heeft een Gemachtigde dezelfde bevoegdheden als een Aanvrager, en wordt daarom daarmee gelijkgesteld. Er is maximaal één gemachtigde per aanvraag.

o Betrokkene: een persoon die een rol speelt bij het opstellen van een aanvraag, anders dan een gemachtigde. Een voorbeeld is een architect die namens een gemachtigde een bouwtekening toevoegt. Betrokkenen hebben alleen rechten om een aanvraag en bijlagen te bekijken. Het indienen van een aanvraag of het doen van aanvullingen mag alleen door een aanvrager of zijn gemachtigde worden gedaan.

o Vergunninghouder: de persoon of de organisatie op wiens naam de vergunning wordt afgegeven. Dit is de aanvrager.

o Belanghebbende: overige burgers of organisaties die op enigerlei wijze belang heeft bij een aanvraag of een vergunning en daartoe zienswijze kan geven, bezwaar maken of beroep aantekenen. Een aanvrager kan ook een zienswijze indienen.

• Overheidsorganisatie. Dit zijn alle overheidsorganisaties die conform de WABO de volgende rollen kunnen aannemen:

o Bevoegd gezag: dit is de overheidsorganisatie die verantwoordelijk is voor de behandeling van een aanvraag.

o Adviserende organisatie: dit is de overheidsorganisatie waarbij het bevoegd gezag advies aanvraagt.

Figuur 3 Contextdiagram uit de PSA van de LVO (zie refnr. [2]) Bij een complexe, meervoudige omgevingsvergunning zijn de volgende bestuursorganen betrokken: • Ministerie van VROM. Dit ministerie faciliteert die de Landelijk Voorziening Omgevingsvergunning; • Bevoegd gezag. Dit is de overheidsorganisatie die verantwoordelijk is voor de afhandeling van een

aanvraag; • Adviserend orgaan. Dit is de overheidsorganisatie waarbij het bevoegd gezag advies aanvraagt. Het bevoegd gezag heeft de regie in handen over alle ketenpartners heen vanaf het moment van definitieve indiening van de formele aanvraag tot en met de levering van de WABO-beschikking.


31


32

3.1.1 Architectuurprincipes De volgende architectuurprincipes zijn van toepassing: • Overheidsorganisaties zijn soevereine deelnemers binnen de e-overheid (5.1.1). • De functies van overheidsorganisaties zijn inzichtelijk (5.1.2). • Overheidsorganisaties werken binnen de e-overheid samen, ongeacht de bestuurslaag of sector

waarvan zij deel uitmaken (5.1.3). • De architecturale opbouw van overheidsorganisaties is gericht op het verlenen van diensten aan

burgers en bedrijven via meerdere kanalen, evenals op onderlinge samenwerking door het koppelen van dienstverleningsprocessen en het gezamenlijke gebruik van gegevens (5.1.4).

• Overheidsorganisaties werken samen aan diensten aan burgers en bedrijven op basis van een service georiënteerde architectuur. Dit wil zeggen: overheidsorganisaties verlenen elkaar (elektronische) services, waarmee de diensten aan burgers en bedrijven kunnen worden geassembleerd (5.1.5).

3.1.2 Taken en verantwoordelijkheden Samenwerking in het kader van de WABO betekent het organiseren van processen over meerdere organisaties heen. Dit vergt een goede afstemming met de betrokken organisaties en een goed uitgelijnd ketenproces. Het bevoegd gezag voert de regie over de keten vanaf het moment van definitieve indiening van de formele aanvraag. Het bevoegd gezag bewaakt de afhandeling van de zaak (zaakgericht werken) en laat de zaak pas los nadat de klant volledig en goed door alle betrokken partijen is geholpen. De overige betrokken organisaties leveren alleen het gevraagde product conform gemaakt afspraken. De afspraken die in dit kader worden gemaakt dienen te worden vastgelegd in dienstverleningsovereenkomsten (SLA's). Hierin worden zaken vastgelegd als doorlooptijd, prijzen en kwaliteitscriteria. Een nader uitwerking van de taken en verantwoordelijkheden volgt hierna:6

Taken front-office (loketfunctie, deels klantmanagement): • Eerste contact met de aanvrager en derden (direct beantwoorden van algemene vragen, verstrekken,

aanvraagformulier en aangeven dat aanvrager binnen een bepaalde termijn zal worden benaderd door een contactpersoon).

• Bepalen van het bevoegd gezag en op hoofdlijnen nagaan welke activiteiten vergunningsplichtig zijn op basis van de WABO.

• De ingediende aanvraag op hoofdlijnen beoordelen (bijvoorbeeld beoordelen aan de administratieve indieningvereisten zoals ondertekening, aantal (‘intake’).

6 [refnr. 10] Koninklijke Ten Cate Nijverdal 2006

• Het direct doorsturen van de (concept)aanvraag en overige stukken (bijvoorbeeld zienswijzen) naar de provincie en het versturen van de ontvangstbevestiging bij formele stukken naar alle betrokkenen.

• Informatiebeheer rond de vergunningaanvraag (inboeken aanvragen in procedurebewakingssysteem en starten workflow).

• Adviseren van de aanvrager op procedureel vlak. • Verstrekken van informatie aan derden over het verloop van de procedure en de ter inzage liggende

stukken. • Evalueren van de kwaliteit van de diensten en uitzetten acties volgend uit de evaluatie. • Evalueren van beleid en uitzetten van acties volgend uit deze evaluatie. • Signaleren van ontwikkelingen in klantbehoeften en uitzetten acties. Taken contactpersoon (coördinatorfunctie, deels klantmanagement, zaakmanagement) • Eerste aanspreekpunt voor de aanvrager. • Beoordeling welke activiteiten vergunningsplichtig zijn op basis van de WABO. • Samenstellen van het projectteam. • Distribueren van diensten van het projectteam (zoals ontvankelijkheidtoets). • Adviseren van de aanvrager op procedureel vlak. • Procedurebewaking van de aangevraagde omgevingsvergunning. • Coördinatie van adviezen en/of zienswijzen. • Coördinatie van de voorbereiding van bezwaar en beroep. • Contact met derden bij inhoudelijke vragen over stukken die ter inzage liggen en zienswijzen. • Informatiebeheer rond de vergunningaanvraag. • Coördinatie van adviezen afkomstig van de projectgroepleden en het opstellen van het

(ontwerp)besluit. • Advisering richting bestuur inzake het (ontwerp)besluit. Taken backoffice (inhoudelijke behandeling bij bevoegd gezag en adviserend orgaan) • De aanvrager adviseren over complexe, vakinhoudelijke vragen. • Diensten produceren zoals het betrekken van specialisten, vooroverleg, ontvankelijkheidtoets,

voorbereiden bestuurlijk (ontwerp)besluit, mede verwerken adviezen en/of zienswijzen en medeopstellen verweerschrift bij bezwaar en beroep.

• Procedurebewaking verzorgen. Extra taak backoffice (bij bevoegd gezag) • Versturen van procedurestukken naar betrokken deskundigen, wettelijk adviseurs en derden.

Samenhang voor samenwerking, Project Start Architectuur Omgevingsvergunning voorbeeldproj

33 ect Overijssel

3.1.3 Aanvullende architectuurprincipes Bovenstaande taakbeschrijvingen maakt inzichtelijk dat er vier rollen zijn te onderscheiden en dat in de samenwerking afspraken moeten worden gemaakt over de coördinatie van de behandeling van de aanvraag in de keten:


34

Figuur 4 Rollen en coördinatiemechanisme In het voorbeeldproject kunnen de volgende aanvullende architectuurprincipes worden gebruikt: • Klantcontact vanuit het loket ligt bij de gemeente • Procedureel en inhoudelijk aanspreekpunt ligt bij de contactpersoon van de provincie • Elk van de deelnemende ketenpartners heeft een coördinator voor de bijdrage aan de behandeling van

de aanvraag. • Afhankelijk van het type aanvraag en de omvang van de ketenpartner kan ook de overall coördinatie bij

de contactpersoon van de provincie worden belegd. Deze coördineert in dat geval ook rechtstreeks naar de behandelaars binnen alle ketenpartners.

3.2 Diensten en services De principes in het domein “diensten en services” hebben betrekking op het kunnen leveren van transparante diensten die kanaalonafhankelijk gedefinieerd zijn; diensten die over organisatiegrenzen heen gaan en die via verschillende kanalen worden afgenomen. Bij het aangaan van servicerelaties tussen organisaties is de semantische samenhang cruciaal: de betekenis en de bedoeling van de uit te wisselen informatie moet voor alle betrokken organisaties hetzelfde zijn. Daarnaast is het belangrijk dat organisaties de bedrijfsprocesarchitectuur baseren op dezelfde procesdecompositie (procesgranulariteit) om op verschillende niveaus te kunnen samenwerken, en dat processen op een uniforme manier worden beschreven. De minimale eis is dat de bedrijfsprocessen worden opgesplitst (beschreven) in een invoer-, verwerkings- en uitvoerproces en de modelleringstandaard dient te voldoen aan algemeen geaccepteerde functionaliteiten.

3.2.1 Architectuurprincipes Voor de WABO zijn vooral de onderstaande principes van belang: Diensten en producten • Service- en dienstbeschrijving moeten gerelateerd worden aan een semantisch model dat de betekenis

van de service of dienst uitdrukt (NORA 5.2.1.5). Voor de WABO dient de input (aanvraag) en de output (ontwerpbesluit en definitief besluit) eenduidig te zijn beschreven

• Diensten van de overheid die via verschillende kanalen worden geleverd moeten hetzelfde resultaat

voor de afnemer van de dienst opleveren (NORA 5.2.1.6). Het WABO principe “Eens digitaal, altijd digitaal” houdt in dat de overheid digitaal reageert op een digitaal ingediende aanvraag. Het beperkt


35

niet het medium waarlangs de aanvraag wordt ingediend. Een aanvraag kan via de LVO maar ook via de balie worden ingediend. Het procesontwerp moet daarop zijn ingesteld. Het analoge en digitale formulier dient overeen te stemmen. Ook aanvullingen, bijlagen, zienswijzen moeten via de balie kunnen worden aangeboden en verwerkt.

• Organisaties in het publieke domein verlenen hun diensten via de volgende kanalen: internet, telefoon,

post en balie (NORA 5.2.1.9). Het aanvragen van een vergunning en het opvragen van statusinformatie zijn diensten die over meerdere kanalen beschikbaar moeten komen. De aanvrager kan op elk gewenst moment inzicht krijgen in de voortgang van de afhandeling van zijn aanvraag. Het voorbeeldproject voldoet hier niet aan, beperkt zich tot het digitale kanaal.

• Bij de overheid bent u nooit aan het verkeerde adres “no wrong door” (NORA 5.2.1.10). De

ketenpartner die de aanvraag ontvangt zorgt ervoor dat deze bij het bevoegd gezag terecht komt voor behandeling. Het bevoegd gezag dient invulling te geven aan een coördinatiefunctie inzake aanvragen; onderdeel van de coördinatiefunctie zal het routeren van aanvragen zijn.

• De loketfunctie is dusdanig georganiseerd dat de klant bij een vraag binnen enkele stappen

terechtkomt bij iemand die de vraag kan beantwoorden: loketfuncties kunnen direct doorverbinden naar coördinatoren met kennis over procedure en inhoud van een WABO aanvraag.

• De overheid biedt voor de klant een portaal waarin alle informatie over de omgevingsvergunning is te

vinden: lokale en regionale websites en portalen zijn verbonden aan dit portaal. De website van het bevoegde gezag bevat op zijn minst (via een productencatalogus) een doorverwijzing naar de LVO. Omgekeerd kan de LVO bij een aanvraag doorverwijzen naar de informatie op de website van het bevoegd gezag.

• Stimuleren kanaalgebruik met beste kosten / kwaliteit verhouding (NORA 5.2.1.11). Voor bedrijven

wordt het gebruik van het digitale kanaal gestimuleerd, daar ligt de kans op administratieve lastenverlichting. Het voorbeeldproject geeft voorrang aan het digitale kanaal.

• Diensten moeten “smart” beschreven worden (NORA 5.2.1.13). Het aanvraagformulier ondersteunt dit

door het gestructureerd benoemen en relateren van aangevraagde activiteiten en de verplichtingen en indieningvereisten die dit met zich meebrengt. De dienst wordt beschreven op basis van wettelijke regels, uitvoeringsregels en praktijkervaringen (bijvoorbeeld voor termijnen). Consequenties voor tijd, geld en informatie worden in prestatieafspraken vastgelegd.

• Burgers en Bedrijven krijgen een digitale, unieke identiteit (BSN, BIN). Dit dient maximaal door

overheidsorganisatie te worden benut (NORA 5.2.1.14-15). • Dienstverleningskanalen zijn ingericht vanuit het perspectief van de klant (NORA 5.2.1.18). Principe is

het aanvragen zo flexibel als mogelijk te laten verlopen binnen het geldende wettelijke kader. Hiermee wordt tot het moment van formeel indienen een stukje regievoering en zelfredzaamheid bij de klant gelegd.

Diensten en services • Dienstverlening gaat over organisatiegrenzen heen (NORA 5.2.1.8). Overheidsorganisaties maken

afspraken over het verlenen van services (NORA 5.2.2.3).Het bevoegd gezag treedt op als


36

ketenregisseur in de samenwerking met de ketenpartners en maakt prestatieafspraken. Ook op het gebied van ICT moet de samenwerking vorm krijgen.

• Het Rijk is middels de LVO verantwoordelijk voor het in ontvangst nemen van de digitale aanvraag.

Wanneer bescheiden bij een ander overheidsorgaan binnenkomen dan kan dit gebruik maken van een interne service om de bescheiden toe te voegen aan de aanvraag.

3.2.2 Dienstencatalogus De klant ontvangt de volgende diensten: (vanuit het landelijke loket) * • Geven van informatie ter oriëntatie; • Beschrijving van het te doorlopen (klant)proces; • Specificeren van (aanvullende) informatie om behandeling van aanvraag mogelijk te maken; • Ontvangst aanvraag omgevingsvergunning; • Terugmelding status. (vanuit het bevoegd gezag) • Inplannen van afspraken • Voeren van vooroverleg om tot een goede aanvraag te komen* • Leveren van informatie over het voorgenomen besluit • Verwerken van ingediende zienswijzen • Leveren van een omgevingsvergunning op basis van een aanvraag • Leveren van informatie over de status van behandeling • Leveren van informatie over het genomen besluit • Leveren van informatie over het opgebouwde dossier* • Verzorgen van handhaving* • Behandelen van bezwaren en het uitvoeren van beroepsprocedures*.

3.2.3 Servicecatalogus De aangeboden services zijn: (van Rijk/LVO aan bevoegd gezag) • Authenticeren van de klant (DigiD)* • Identificeren van de klant (BSN/BIN, basisgegevens uit landelijke basisregistraties)* • Authenticeren van een ketenpartner* • Doorsturen van de aanvraag naar (juiste) bevoegd gezag* (van bevoegd gezag aan adviserend orgaan) • Beantwoorden van loketvragen via balie, telefoon, email* • Aannemen van een aanvraag en vastleggen van bijbehorende bescheiden • Onderhouden van klantcontact • Coördineren van de behandeling van de aanvraag • Bewaken van de kwaliteit


37

• Bewaken van de voortgang (van adviserend orgaan aan bevoegd gezag) • Adviseren over een onderdeel van de aanvraag (bij vergunningverlening en vervolgprocessen als

handhaving en bezwaar / beroep), het advies kan vrijblijvend of bindend zijn • Leveren van statusinformatie over een onderdeel van de aanvraag • Handhaven van een onderdeel van de aanvraag*

3.2.4 Bedrijfsfunctiemodel

Hieronder volgt het bedrijfsfunctiemodel van een provincie. De bedrijfsfuncties die relevant zijn in de context van de WABO zijn groen omcirkeld. Indien het onderdeel buiten de scope van het voorbeeldproject valt, is het onderdeel gestippeld omcirkeld.


38


39

3.3 Processen

3.3.1 Inleiding en theorie

Processen zorgen voor de voortbrenging van diensten (en services en producten). Elke processtap voegt waarde toe en leidt tot een vooraf bekend resultaat. De NORA hanteert de volgende definitie Een proces is een geordende reeks van (in-) direct waarde toevoegende handelingen en oordelen door een mens of machine gericht op een bekend resultaat. In onderstaande tabel wordt de formele definitie gegeven van de hiërarchische niveaus of granulariteit (fijnmazigheid) in processen: “Ketenproces” of interactieperspectief

Een “ketenproces” is een geordende reeks services die door verschillende organisaties aan elkaar worden geleverd met als doel om via één organisatie een (combinatie van) dienst(en) te leveren aan een burger of een bedrijf. We spreken hier bij voorkeur over het ‘interactieperspectief’

Bedrijfsproces Een bedrijfsproces is een geordende reeks werkprocessen die binnen één organisatie wordt uitgevoerd met als doel om een (combinatie van) dienst(en) te leveren aan een burger, bedrijf of andere organisatie

Werkproces Een geordende reeks van processtappen die binnen één organisatorische eenheid binnen een organisatie wordt uitgevoerd met als doel een specifieke bijdrage (prestatie) te leveren aan een dienst die uiteindelijke zal worden geleverd aan een burger, een bedrijf of een andere organisatie.

Processtap Een geordende reeks handelingen die ononderbroken wordt uitgevoerd door één mens of machine binnen één bedrijfsfunctie.

Handeling Kleinst mogelijke eenheid van werk, uitgevoerd door één persoon of machine op één plek op één moment (eenheid van tijd, plaats en handeling.

Verantwoordelijkheid, regie (besturing) en uitvoering in ketenprocessen Samenwerking tussen organisaties roept de vraag op naar de regie of besturing over de keten. Om dit helder te maken, moet een onderscheid gemaakt worden naar drie rollen: • De verantwoordelijkheid voor de aan de klant te leveren dienst; • De regie of besturing van de ketensamenwerking; • De uitvoering.

3.3.2 Architectuurprincipes • Voor de WABO gelden onderstaande principes bij besturing van de keten, dit is afhankelijk van de

complexiteit van de aanvraag en het bevoegd gezag:

De organisatie die de dienst levert neemt de verantwoordelijkheid voor de totale keten van onderlinge serviceleveringen. Die rol heeft het bevoegd gezag bijvoorbeeld bij het behandelen van een meervoudige, complexe aanvraag.

De organisatie die de dienst levert neemt de verantwoordelijkheid voor de levering die door andere ketenpartners wordt gedaan. Die rol heeft het bevoegd gezag bijvoorbeeld bij een aanvraag die geheel door een ketenpartner wordt uitgevoerd, maar wel onder de verantwoordelijkheid valt van het bevoegd gezag.

• Voor de WABO gelden onderstaande principes bij besturing van de keten, dit is afhankelijk van de

complexiteit van de aanvraag en het bevoegd gezag • Services triggeren elkaar en kunnen daardoor processen verbinden (NORA 5.3.1). Het huidige proces

vergunningverlening dient heringericht te worden om in een ketenproces te kunnen participeren. Dit dient zowel vanuit de rol van bevoegd gezag als adviserend orgaan te worden gemodelleerd. Bij het modelleren van de services wordt de samenwerkingsafspraak benoemd en betekenis en bedoeling van de uit te wisselen informatie beschreven. De implementatie in het voorbeeldproject verankert de afspraken in de organisatie van de ketenpartners. Het voorbeeldproject richt zich daarnaast op het opstellen van servicegeoriënteerde procesbeschrijvingen voor de interactie met de LVO in de ketencontext.

• De besturing van ketenprocessen wordt gelegd bij de organisatie die het verzoek tot leveren van de

dienst heeft aangenomen. Deze heeft daarmee de eindverantwoordelijkheid voor het leveren van de dienst aan de burger of het bedrijf (NORA 5.3.3). In het voorbeeldproject is de coördinatiefunctie van het bevoegd gezag uitgewerkt en belegd.


40

• Klanten hebben de mogelijkheid zich op de hoogte te stellen van de stand van de uitvoering van de dienstverlening (NORA 5.3.4). Landelijk zal de statusinformatie moeten worden gedefinieerd, inclusief de afspraken hoe het bevoegd gezag dit bijhoudt en beschikbaar stelt. Binnen het voorbeeldproject heeft de klant de mogelijkheid om zich via de LVO (of de website van de provincie Overijssel) op de hoogte te stellen van de voortgang.

• Informatie wordt éénmalig uitgevraagd (NORA 5.3.6). Wanneer gebruik wordt gemaakt van de digitale

variant (aanvraagmodule), worden (op basis van andere e-overheid voorzieningen zoals DigiD, het burger service nummer (BSN), het bedrijven en instellingen nummer (BIN) en de basisregistratie adressen en gebouwen (BAG) bij de overheid bekende persoons-, bedrijfs- en adresgegevens vooringevuld zodat het invullen van het aanvraagformulier sneller gaat. Dit principe wordt uitgevoerd middels ontwikkeling en implementatie van de LVO. Dit principe is verankerd in de LVO en verder niet van toepassing in het voorbeeldproject.

NB: de overige principes zijn eveneens van toepassing voor het procesontwerp. Het betreft zaken als decompositie, standaarden, vastlegging van procesgegevens, wijze van beschrijving en gebruik van een semantisch model.

3.3.3 Samenhang bedrijfsproces “Verlenen vergunning”

3.3.4 Schema en toelichting Voor het modelleren van het omgevingsvergunningproces is gekozen voor een internationale standaard die ook door de Nederlandse Overheids Referentie Architectuur (NORA) wordt geadviseerd. Deze standaard


41

bestaat uit een “taal” de Business Process Modelling Language (BPML) en de bijbehorende notatie van deze taal, de Business Process Modelling notation (BPMn).

Verzameladviezen

Een processtap. <atomaire stap>

Ontwerpbeschikking

Een uitgaand document

Zienswijzebinnengekomen

Ontwerpbeschikkingter inzage

leggen

Zienswijze

Een timer die wordt geïnitieerd na een processtap. Als binnen de duur van de timer informatie wordt verkregen dan wordt de volgende processtap uitgevoerd, de timer wacht de gehele ingestelde tijd af.


Ja

Nee

Verwerk ziens-wijze

StelBeschikking op

Keuze uit twee processtappen

+ beoordeling ontvankelijkheid

beoordeling volledigheid

Parallel verwerking van processtappen. Beide processtappen worden gelijktijdig uitgevoerd.

Procesbeschrijving

Aanvraag of medling

(LVO)

Aanvraag ontvangen

Ontvangst-bevestiging

+ beoordeling ontvankelijkheid

Vergunning

Melding

Publiceer aanvraag

Inschakelen Adviseurs

beoordeling volledigheid

Verzoek aanvullingen

VerzoekAanvullendeinformatie

Nee

Verzoek totcompleteren

Bundelenverzoeken

Nee

4 weken

Aanvullendestukken (LVO)

1

2Ja

3

4

Tijdig

Niet tijdig


42

5

7

6

Inhoudelijketoetsing aanvraag

Maatwerkvoorschriften


Verzoek termijn verlenging

Informeeraanvrager

6 weken

Bezwaar-schrift

Bezwaar binnen gekomen

Bezwaar- en beroepproces

Ja

Nee

Termijn verlenging

Verzameladviezen

Verzamelmaatwerk

voorschriften

8

11

10

Beoordelingregulier/ uit-

gebreid

Stel ontwerpBeschikking op

Uitgebreid

9Regulier

8

11

10

9

+Verzending

ontwerp-beschikking

Ontwerpbeschikking

Publiceerontwerp-

beschikking


Ja

Nee

Ontwerpbeschikkingter inzage

leggen6 weken

Zienswijze

Verwerk ziens-wijze

StelBeschikking op


12

14

13


43

12

14

13

Beoordeling aanhoudings-

gronden

Samenvoegen

Nee

Publiceerbeschikking

Vergunning + Maatwerk-voorschriften

+

Verlopen

6 weken

Aanhouding

Publiceeraanhouding

Bezwaar-schrift

Bezwarenbinnen

gekomen

Bezwaar- en beroepproces

Ja

Beschikkingonherroepe-

lijkBeschikken

Informeeraanvrager

aanhouding

Nee

Einde

Uitwerking inschakeling adviseurs


44

Vraag Adviseurs

Splitsenvraag

Woningwet

WRO

Wm

Mijnbouwwet

WVO

Monumentenwet

Provincialeverordening

Bouw-verordening

Gemeentelijkeverordeningen

Bundelen Antwoord

Inrichtingsprincipes • Het dient mogelijk te zijn een dreigende overschrijding van een ingestelde termijn te signaleren. Er

dient rekening te worden gehouden met de volgende termijnen: o Termijn inbrengen van aanvullingen o Termijn beoordelen van aanvullingen o Termijn VVGB (Verklaring Van Geen Bedenkingen) o Termijn inbrengen van zienswijzen o Beslistermijn

• Om de termijnen te kunnen halen dient monitoring en voortgangsbewaking plaats te vinden van de

behandeling door de ketenpartners. Dit speelt vooral bij de processtappen waarbij activiteiten bij meerdere partijen worden uitgezet (procesbesturing):

o Het uitzetten van de toets op volledigheid o Het uitzetten van de toets op ontvankelijkheid o Het verlengen van de behandeling o Het uitzetten van het leveren van deelproducten voor het maken van de ontwerp beschikking o Het uizetten van verzoek om reacties op ingediende zienswijzen o Het uitzetten van het leveren van deelproducten voor het maken van de definitieve beschikking

• Het organiseren van overleggen

Uitgangspunt is dat het afstemmen van de gemaakte deelproducten en de adviezen op basis van eventuele zienswijzen of hoorzittingen plaatsvindt door overleg en niet door automatisering hoeft te worden ondersteund.

o overleg n.a.v. de toets op de ontvankelijkheid


45

o afstemmingsoverleg in de behandelfase, eventueel in combinatie met verlengen in verband met de complexiteit van de aanvraag

o afstemmingsoverleg om de deelproducten voor de vergunning af te stemmen o hoorzitting naar aanleiding van de ingebrachte zienswijzen o afstemmingsoverleg om de adviezen voor de definitieve beschikking af te stemmen

• Melding en aanvraag

Er is voor gekozen om in de processchema’s het meldingen- en het vergunningproces weer te geven vanwege het principe van één aanvraag, één uitvraag en één moment van afgifte. Van rechtswege valt de aanvrager al onder een melding, echter het bevoegde gezag heeft wel de mogelijkheid om maatwerkvoorschriften op te leggen. Een melding kan dus niet geweigerd worden vandaar dat in het begin alleen een poging wordt gedaan om de aanvraag te completeren.

• Het beschikken komt op verschillende momenten in het proces voor:

o Buiten behandeling stellen (onvolledig na aanvulling) o Buiten behandeling stellen (vergunning niet nodig) o Buiten behandeling stellen (aanvraag ingetrokken) o Legesheffing o Ontwerp besluit – verlenen, weigeren o Definitief besluit – verlenen, weigeren o Verklaring van geheimhouding.

Bijlage C legt de relatie tussen de schema’s en de “hoofdprocessen” van het voorbeeldproject. Statusovergangen Een belangrijke dienst aan de klant, naast het leveren van de omgevingsvergunning zelf, is het geven van informatie over de status van het behandelproces. Het volgende toestandsdiagram laat zien welke status(overgang)en zijn onderkend voor een aanvraag:


46


47


48

4 Alternatieven gewenste situatie

4.1 Uitgangspunten en aannames • LVO is de generieke component die functionaliteit levert voor:

a. brancheteksten b. vragenboom c. aanvraagformulier d. delen formele documenten (optioneel) e. ontkoppelpunt voor gegevensuitwisseling (optioneel) f. geven van statusinformatie g. publicatie van besluiten

• De aanvraag verloopt altijd via de LVO • Aanvullingen op de aanvraag worden altijd digitaal in de LVO ingebracht • Betrokken partijen en rol:

o Bevoegd gezag: is hier provincie of gemeente. Uiteindelijk besluit het bevoegd gezag over de vergunningaanvraag en blijft het bevoegd gezag verantwoordelijk voor de genomen beslissing.

o Externe adviseur is hier: provincie, gemeente en/of waterschap. De externe adviseur geeft advies aan het bevoegd gezag op een deelgebied van de vergunningaanvraag.

• Communicatie richting klant verloopt altijd via het bevoegd gezag • Aanvragen en aanvullingen via papier vallen buiten de scope van het voorbeeldproject: op het moment

dat voor multi-channel wordt gekozen, wordt e.e.a. complexer en dient de PSA te worden aangepast. In het kader van de WABO zijn drie aansluitvormen (voorheen verzendopties) gedefinieerd. In het voorbeeldproject worden twee aansluitvormen beproefd. Aansluitvorm 2: De aansluitende organisatie maakt gebruik van een materiesysteem in de backoffice maar het werkproces wordt niet noodzakelijkerwijs ondersteund door een workflowsysteem. De aansluitende organisatie zal de gestructureerde gegevens van de aanvraag (inclusief objectgegevens en subjectgegevens) digitaal willen ontvangen in de vorm van een XML bericht om te kunnen verwerken in de backoffice. De documenten kunnen ook digitaal worden overgehaald maar worden niet noodzakelijkerwijs automatisch verwerkt in een digitaal dossier. Relatie tot de LVO: de dossiermodule van de LVO wordt slechts gebruikt als zijnde authentieke opslag van gegevens. Zo zal aanvullende dossiervorming (commentaar / adviezen van behandelaar en adviseurs) ook via de LVO plaatsvinden. De (interne) processen, waaronder de communicatie met adviseurs, vinden echter via de eigen automatiseringsmiddelen plaats. Zodra een vergunningaanvraag is ingediend, wordt de aanvraag via een XML-bericht inclusief verwijzing naar de bescheiden vanuit LVO naar het bevoegd gezag gestuurd. M.b.v. bestandsoverdracht kan het bevoegd gezag vervolgens het aanvraagdocument ophalen bij de LVO.


49

Aansluitvorm 3: De aansluitende organisatie beschikt over een systeem voor procesbesturing (zaakmanagement) en eventueel een workflowsysteem voor ondersteuning van het werkproces. De aansluitende organisatie handelt aanvragen ook nu al volledig digitaal af. Het bevoegd gezag heeft dan de keuze om het volledige dossier direct vanuit de aanvraagmodule te ontvangen en in de systemen voor zaakmanagement en workflowmanagement verder af te handelen. Het XML bericht wordt samen met de PDF versie van de vergunningaanvraag en de bijlage(n) verstuurd. Aanvullingen worden via de LVO direct bij het bevoegd gezag ingediend. Relatie tot de LVO: de aansluitende organisatie maakt geen gebruik van de dossiermodule. De dossiermodule wordt uitsluitend gebruikt als ‘schaduw’ dossier voor opslag van de aanvraaggegevens. Zodra een vergunningaanvraag is ingediend, wordt de aanvraag via een XML-bericht inclusief verwijzing naar de bescheiden vanuit LVO naar het bevoegd gezag gestuurd. M.b.v. bestandsoverdracht kan het bevoegd gezag vervolgens het aanvraagdocument én de bescheiden ophalen bij de LVO. Vanuit het aanvragen- en meldingenoverzicht wordt ten behoeve van aanvragers en gemachtigden doorgelinkt naar het zaakmanagementsysteem of de website van het bevoegd gezag. De volgende aannames zijn hierbij van belang:

• Provincie Overijssel heeft gekozen om aansluitoptie 3 prioriteit te geven. • Door ervaring op te doen met de berichtenwisseling via XML is de veronderstelling dat ook ervaring

wordt opgedaan die bruikbaar is voor aansluitoptie 2. • Statusinformatie naar de aanvrager verloopt minimaal via de LVO. Andere opties die het bevoegd

gezag kan kiezen zijn buiten beschouwing gelaten.

4.2 Relevantie architectuurprincipes

De volgende architectuurprincipes zijn relevant (tussen haakjes wordt eventueel verwezen naar de principes van NORA, zie refnr. [4]). • De bestaande kanalen zoals post, telefoon en balie blijven beschikbaar, zodat burgers, bedrijven en

maatschappelijke instellingen gebruik kunnen maken van het kanaal van hun keuze (P2). Dit is van belang omdat ook de ketenpartners verschillen in digitaliseringsniveau.

• Eénmaal uitvragen van gegevens, meermalen gebruiken (P8). Dit principe is van belang vanwege de

volgende raakvlakken: o gebruik van landelijke basisregistraties (vooral bedrijven en personen) o het formulier stelt precies die vragen die voor de aanvraag relevant zijn o ruimtelijke informatie over de fysieke leefomgeving maakt voor de klant toetsbaar of de

aanvraag zinvol is o systematiek van vastleggen van objectgegevens over de feitelijke en vergunde situatie en

de handhavingsituatie. • Gebruik waar mogelijk generieke componenten (P19). De LVO is een generieke component (zie de

voorgaande paragraaf) en er wordt gebruik gemaakt van een groot aantal landelijke, generieke componenten (zie hoofdstuk 2).


50

• Standaardiseer waar mogelijk koppelvlakken en hiermee samenhangende componenten (P20). De LVO levert een verzameling van standaardberichten voor uitwisseling op basis van de semantische gegevensdefinities van het gegevenswoordenboek.

4.3 Organisatievormen In het wetsvoorstel WABO zijn voorwaarden voor het overheidsloket opgenomen. De ketenpartners dienen in het loket het volgende te waarborgen: - er is één aanspreekpunt voor de aanvrager, ongeacht wie het bevoegd gezag is - een aanvraag wordt onverwijld doorgestuurd naar het bevoegd gezag - de aanvrager krijgt een ontvangstbevestiging krijgt, ook indien de ontvangende ketenpartner niet zelf

het bevoegd gezag is - er wordt beoordeeld welke activiteiten volgens de Wabo vergunningplichtig zijn.

In de praktijk zijn twee typen loket-modellen mogelijk: een loket zonder case-manager en een loket met case-manager. Een case-manager is een medewerker die interne processen bij de back-office rondom de vergunningen stroomlijnt. Met of zonder inhoudelijk afstemming. Hierbij maken het loket en de case-manager onderdeel uit van de front-office

4.3.1 Loket zonder case-manager In dit model behandelt het loket alle aanvragen en meldingen van burgers. Dit kan waarschijnlijk alleen bij eenvoudige vragen van burgers en bedrijven. Aangezien bij complexe omgevingsvergunningen afstemming met de back-office noodzakelijk is, is afhandeling van de procedure bij het loket niet mogelijk.

4.3.2 Loket met case-manager In het loket met een case-manager zijn vier coördinatievarianten te onderscheiden: 1. Procedurele coördinatie: case management door front-office, aanvrager heeft geen contact met

backoffice 2. Professionele coördinatie: case-management door front-office, aanvrager heeft direct contact met front-

en backoffice 3. Vergunningmanager: case-management door vergunningmanager tussen front- en back-office,

aanvrager heeft alleen contact met vergunningmanager 4. Projectteam: case-management door projectleider tussen front- en backoffice, aanvrager heeft contact

met contractpersoon, projectleider en projectteam. Zie bijlage A voor een nadere omschrijving van de 4 organisatievormen (gebaseerd op Pilot Koninklijke Ten Cate Nijverdal, zie refnr. 10]). Omdat de keuzes in de organisatievorm afhankelijk zijn van het soort aanvraag (eenvoud/complex, enkelvoudig/meervoudig) en de grootte van de overheidsorganisatie zijn dit geen alternatieven waaruit generiek één keuze kan worden gemaakt.

4.4 Alternatieven samenwerking

4.4.1 Alternatief 1 : Volledig gebruik LVO Omschrijving De klant doet een aanvraag voor een omgevingsvergunning via de LVO (de aanvraag komt digitaal binnen) en bouwt een digitaal aanvraagdossier op. De digitale behandeling vindt plaats middels de LVO en daar wordt een behandeldossier opgebouwd. Het bevoegd gezag zet adviesverzoeken uit naar de benodigde externe adviseurs (provincie, gemeente, waterschap) via de LVO. De uitwisseling vindt plaats door documenten handmatig op de LVO te plaatsen en op te halen. Email-notificaties worden daarbij automatisch verzonden om elkaar op de hoogte te brengen. De LVO verzorgt de publicatie en de statusinformatie. Voordelen Nadelen Principe van hergebruik van generieke componenten komt in dit alternatief tot zijn recht.

Alle ketenpartijen moeten volledig gebruik maken van de LVO en kunnen de informatie niet integreren met de eigen informatiehuishouding.

Procesbesturing en procesondersteuning is geïntegreerd en landelijk gestandaardiseerd.

Het bevoegd gezag kan pas na afloop het dossier overhalen. Dossiervorming en gereed maken voor archiveren vindt aan het eind van het proces plaats.

Procesondersteuning is niet in te regelen naar de specifieke organisatorische eisen van een ketenpartij.

Dit alternatief is alleen geschikt als de ketenpartijen op hetzelfde (lage) digitaliseringsniveau gaan uitwisselen.


51

4.4.2 Alternatief 2: Uitwisseling via LVO

Omschrijving De klant doet een aanvraag voor een omgevingsvergunning via de LVO (de aanvraag komt digitaal binnen) en bouwt een digitaal aanvraagdossier op. Deze aanvraag wordt doorgezet naar het juiste bevoegd gezag via het berichtenverkeer (dit kan zijn de provincie of de gemeente). Bij het bevoegd gezag wordt een het behandeldossier opgebouwd. Het bevoegd gezag zet adviesverzoeken uit naar de benodigde externe adviseurs (provincie, gemeente, waterschap). De uitwisseling vindt plaats door documenten handmatig op de LVO te plaatsen en op te halen. Email-notificaties worden daarbij automatisch verzonden om elkaar op de hoogte te brengen. Het behandeldossier wordt actueel gehouden bij het bevoegd gezag. Het bevoegd gezag kan de publicatie verzorgen. Wel wordt er gezorgd voor status updates richting het LVO vanuit het bevoegd gezag. Voordelen Nadelen Principe van hergebruik van generieke componenten (berichtenverkeer via de LVO) komt in dit alternatief tot zijn recht.

Alle ketenpartijen moeten aansluiten op de LVO.

Mogelijkheid om koppelvlakken te standaardiseren doordat alle partijen aansluiten op de LVO en dit als het centrale punt voor berichtenuitwisseling te gebruiken.

LVO krijgt er een functie bij en wordt daarmee ook een kritische schakel in het omgevingsvergunning proces.

Dit alternatief is geschikt ongeacht het verschil in digitaliseringsniveau van de ketenpartijen.

Er dienen goede afspraken te worden gemaakt op welk moment het aanvraagdossier wordt gesynchroniseerd.


52


53

4.4.3 Alternatief 3: Uitwisseling tussen Bevoegd Gezag en Adviserend Orgaan

Omschrijving De klant doet een aanvraag voor een omgevingsvergunning via de LVO (de aanvraag komt digitaal binnen) en bouwt een digitaal aanvraagdossier op. Deze aanvraag wordt doorgezet naar het juiste bevoegd gezag via het berichtenverkeer (dit kan zijn de provincie of de gemeente). Bij het bevoegd gezag wordt een het behandeldossier opgebouwd. Het bevoegd gezag zet adviesverzoeken uit naar de benodigde externe adviseurs (provincie, gemeente, waterschap). Tussen deze partijen gaan berichten heen en weer en het behandeldossier wordt actueel gehouden bij het bevoegd gezag. Het bevoegd gezag kan de publicatie verzorgen. Wel wordt er gezorgd voor status updates richting het LVO vanuit het bevoegd gezag. Voordelen Nadelen Alleen de instanties die bevoegd gezag kunnen zijn hoeven aansluiting te realiseren met de LVO.

Bevoegde gezagen en externe adviseurs moeten in samenwerking de berichtenuitwisseling vormgeven en inrichten.

Rechtstreekse, nauwe samenwerking tussen bevoegd gezag en de externe adviseurs is meer voelbaar

Bevoegde gezagen en externe adviseurs moeten samen komen tot standaarden die zij allen onderling willen gebruiken voor uitwisseling van gegevens.

Principe van hergebruik van generieke componenten en scheiding van functionele componenten komt goed tot zijn recht.

Dit alternatief is alleen geschikt als de ketenpartijen op hetzelfde (hoge) digitaliseringsniveau gaan uitwisselen.


54


55

4.5 Aanvullende architectuurprincipes

Bovenstaande geeft de volgende aanvullende architectuurprincipes: • De procesbesturing dient zoveel mogelijk eenduidig generiek te worden beschreven (op regionaal of

landelijk niveau) om de samenwerking tussen de ketenpartners te vergemakkelijken. Dit geldt voor de procesbesturing in de LVO en bij de ketenpartners.

• De procesondersteuning bij de ketenpartners (eventueel toepassing van workflow) hoeft niet generiek

te zijn mits de werkwijze maar past binnen het generieke kader voor de procesbesturing. • De organisatievorm die een ketenpartner kiest maakt onderscheid in de rollen klantcontact, procedurele

coördinatie (intern én in de keten), inhoudelijke coördinatie en inhoudelijk behandeling en advisering. • De procesmodellen en informatiesystemen voor procesbesturing en procesondersteuning zijn zo

flexibel dat deze kunnen worden toegepast voor verschillende organisatievormen met inachtneming van de hierboven genoemde rollen. Het moet daarbij mogelijk zijn meerdere rollen te beleggen bij 1 functionaris.

• Architectuurontwikkelstrategie:

De drie alternatieven voor samenwerking kunnen ook worden gezien als ontwikkelplateaus. In het voorbeeldproject is gekozen voor het hoogste plateau, maar op onderdelen zal moeten worden teruggevallen op lagere plateaus omdat niet alle infrastructurele componenten bij de start van het voorbeeldproject aanwezig zijn. Om het eindplaatje te bereiken moeten wel aan de infrastructurele componenten worden gewerkt. Principe is de architectuur te ontwikkelen in plateaus en daarbij de volgende plateaus te onderkennen:

o Plateau 1: Volledig gebruik LVO. Randvoorwaarde is dat alle berichten semantisch zijn gedefinieerd

o Plateau 2: Uitwisseling via LVO. Extra randvoorwaarde is dat alle berichten zijn voorzien van services die landelijk beschikbaar zijn

o Plateau 3: Uitwisseling tussen Bevoegd gezag en Adviserend Orgaan met gebruik van eigen kernregistraties. Extra randvoorwaarde is dat infrastructuur voor servicebus regionaal of landelijk beschikbaar is.

o Plateau 4: Uitwisseling tussen Bevoegd gezag en Adviserend Orgaan met gebruik van basisregistraties. Extra randvoorwaarde is dat basisregistraties en infrastructuur voor servicebus landelijk beschikbaar is.

Zie bijlage B voor een schematische weergave van de plateaus.


56

5 Uitwerking voorkeursoplossing Informatiearchitectuur

5.1 Mensen en applicaties

De informatiearchitectuur heeft betrekking op de inrichting van de informatiehuishouding van de e-overheid. Hierbij gaat het om alle informatie, niet slechts op dat wat geautomatiseerd is. Immers, ook niet-geautomatiseerde informatie kan een onderdeel zijn van de dienstverlening. De informatiearchitectuur bestaat uit drie aspecten: • medewerkers en applicaties: de functionele aspecten daarvan: het "wie" • berichten: de informatie zelf en de betekenis daarvan: de content, het "wat" • communicatie: alles wat met het verzenden van berichten te maken heeft: het "waar en wanneer".


57


58

5.1.1 Architectuurprincipes De meest relevante principes in dit domein zijn: • De uitvoering van handmatige taken in werkprocessen en processtappen wordt bij voorkeur

ondersteund met een workflowmanagement applicatie (NORA 6.1.1.5) Dit principe kan niet zonder meer worden toegepast. De handmatige procesonderdelen van de behandeling van een aanvraag leent zich in principe voor workflowmanagement. Er dient echter wel een businesscase aan ten grondslag te liggen. Te hanteren criteria kunnen zijn:

o Hoge frequentie van de procesuitvoering o Standaardisatie van de procesinrichting o Mate waarin afspraken over de uniformering zijn te maken.

• Voor de WABO is procesbesturing belangrijker dan procesondersteuning. Bij het WABO-vraagstuk van

ketenintegratie ligt het belang in de besturing (regie) over de gehele keten. Ligt de keuze voor workflowmanagement bij de individuele ketenpartner, elke ketenpartner zal een vorm van businessprocesmanagement c.q. zaakmanagement / recordmanagement moeten toepassen. De WABO-problematiek leent zich daar uitstekend voor. Metadatering en classificatie moeten in de keten worden gedefinieerd. Dit is nodig om het zaakdossier uniform te kunnen opbouwen.

• Dienstverleningskanalen zijn ingericht vanuit het perspectief van de gebruiker (NORA 6.1.2.1).

Aan dit principe is invulling gegeven door een centrale voorziening voor het elektronisch aanvragen van een omgevingsvergunning. Deze is (evenals de branchewijzers) opgezet vanuit het perspectief van de gebruiker. In het vormgeven van de dienstverleningskanalen bij het bevoegd gezag, moet specifieke aandacht zijn voor: het aanleveren van extra documenten (elektronisch of op papier); het doorsluizen van vragen m.b.t. aanvragen; het inzichtelijk maken van de voortgang van de afhandeling. Kortom: er is meer dan de webintake, ook hier zal dus van buiten naar binnen moeten worden geredeneerd. De definitie van de statusinformatie moet in de keten zijn gedefinieerd en zijn gebaseerd op de wetgeving. Dit moet uitwisseling tussen LVO en applicaties voor zaakmanagement bij de ketenpartners eenduidig mogelijk maken.

• Dienstverleningskanalen kunnen zowel door burgers en bedrijven als door de overheid gecombineerd

worden gebruikt (NORA 6.1.2.4). De vrijheid van het gebruik van kanalen' wordt door de regelgeving deels ingeperkt. Bedrijven hebben de verplichting aanvragen elektronisch in te dienen. De LVO is ingericht om baliemedewerkers namens de aanvrager een aanvraag te laten indienen. Om de resterende 'kanaalvrijheid' goed te implementeren dient businessprocesmanagement c.q. zaakmanagement te worden gebruikt voor de coördinatie en de efficiënte informatie-uitwisseling voor de verschillende kanalen. Hiervoor is het nodig zicht te hebben op de mogelijke combinaties van het indienen van documenten, verzoeken, etc. ten opzichte van de kanalen.

5.1.2 Applicatielandschap

5.1.3 Informatieverwerkers Zoals in het hoofdstuk Bedrijfsarchitectuur in de paragraaf over Organisatie al is beschreven, zijn er informatieverwerkers aan de kant van Burgers en Bedrijven (het aanvragen en het reageren op de behandeling) en aan de kant van de overheid (het behandelen van de aanvraag). Op basis van de daar genoemde actoren en hun rollen zijn de volgende informatieverwerkers (mensen) bepaald: Burgers en Bedrijven • Aanvrager / gemachtigde: dient de aanvraag in, dient zienswijze in. De aanvrager autoriseert de

gemachtigde en eventuele betrokkenen • Betrokkene: kan de aanvraag inzien • Belanghebbende: kan kennisnemen van (voorgenomen) beslissingen van de overheid, zienswijze

indienen en bezwaar of beroep aantekenen. Heeft buiten de publicatieomgeving (website) geen directe toegang tot informatiesystemen

Overheden • Bevoegd gezag: krijgt de aanvraag toegewezen en behandelt deze.

o Coördinator: deze verzorgt de procesbesturing van de behandeling van de aanvraag en autoriseert de eventuele behandelaars bij het bevoegd gezag en de eventuele coördinatoren en behandelaars bij de adviserende organen


59


60

o Behandelaar: deze kan de aanvraag inzien en documenten van de overheid muteren. Het kunnen beoordelen van een aanvraag moet geautoriseerd worde door de coördinator.

• Adviserend orgaan: de rolverdeling is als bij het bevoegd gezag. Verschil is dat de inbreng bij een aanvraag beperkt is tot het geven van adviezen.

• Baliemedewerker: deze helpt de aanvrager bij het indienen van de aanvraag en heeft na het indienen van de formele aanvraag geen rol meer.

• Juridisch beheerder: deze beheert de kennisbank met wetgeving die de procesbesturing en procesondersteuning in de LVO bepaalt.

• Functioneel beheerder o Centraal: deze beheert de algemene gegevens van de LVO en autoriseert decentraal

functioneel beheer o Decentraal: deze beheert de gegevens van de ketenpartner waarvoor hij is geautoriseerd.

Hieronder valt ook het autoriseren van coördinatoren en behandelaren bij de ketenpartner. Op basis van het applicatielandschap zijn de volgende informatieverwerkers (applicaties) bepaald: Applicatie Functie Omgevingsportaal Verstrekken van informatie, indienen van de aanvraag Business Process Management Procesbesturing van de behandeling van de aanvraag Workflow Management Procesondersteuning bij de behandeling van de

aanvraag Vergunningverleningsysteem Materiesysteem voor inhoudelijke beoordeling van de

aanvraag Toezicht en Handhavingsysteem Materiesysteem voor het houden van toezicht op de

verleende vergunning en het handhaven Management Informatie Systeem Verstrekken van tactische en strategiesche informatie

over de performance van de behandeling van aanvragen en het resultaat (output en outcome)

Publicatiesysteem Genereren van informatie over de aanvraag en de behandeling

Incassosysteem Heffen van de leges voor de behandeling van de aanvraag

Boekhouding Verwerken van de inning van de leges Zakenregister Registratie met data over de zaak Kernregistraties Registratie met interne basisregistraties Dossier Management Registratie met data en context metadata van de

documenten die vrijkomen in de zaak Content Management Opslag van de data (documenten en webcontent) Archief Management Duurzame opslag van dossiers tot moment van

overdracht aan NA of vernietiging

5.2 Berichten en gegevens

5.2.1 Architectuurprincipes


61

• Gegevens- en procesinhoudelijke communicatiestandaarden moeten een semantisch model bevatten of verwijzen naar een dergelijk semantisch model (NORA 6.2.4.1). Het gegevenswoordenboek in wording is het instrument om aan dit principe invulling te geven. Essentieel is dat bovenliggende standaarden van de overheid (Gemeenschappelijk Functioneel Ontwerp Zaken, Dublin Core Government standaard, Internet Publicatiemodel voor Vergunningen, standaarden voor Water, Milieu, etc.) het kader vormen van waaruit dit gegevenswoordenboek specifieke invulling krijgt voor de functionaliteit van de Omgevingsvergunning. Voor het gegevensmodel van het Bevoegd Gezag wordt uitgegaan van het domein model GFO-Zaken. Dit is een metadatamodel. Voor het berichtenverkeer wordt uitgegaan van het XML Schema StUF-Zaken 3.0. In dit model is het mogelijk om te werken met zaaktypen (zie de volgende paragraaf). Specifieke onderdelen van het berichtenverkeer zijn gedefinieerd in een apart XML Schema (wabo-stuf-msg.xsd). Op dit moment is onduidelijk of en in hoeverre deze zaken al zijn uitgewerkt. Nauwkeurige informatie-analyse is vereist, waarbij alle ketenpartners worden betrokken. Voor het versturen van bijlagen wordt bij voorkeur uitgegaan van SOAP berichten inclusief attachments.

• Elk gegeven kent een eigenaar en een beheerder (NORA 6.2.2.2).

In de LVO zijn binnen één procesgang meerdere actoren actief, zowel van de kant van de aanvraag als de overheid. In dit perspectief dient het eigenaarschap en het beheer duidelijk te zijn belegd. Behalve binnen de LVO dient binnen het bevoegd gezag bij opties 2 en 3 hier ook e.e.a. voor geregeld te worden. Het Zakenregister bij het Bevoegd Gezag fungeert als centrale bron van de meeste belangrijke stuurinformatie. Denk daarbij aan statussen, datum van binnenkomst, verzenddatums, plandatums, uiterlijke datums. Het Bevoegd Gezag bouwt het complete dossier op van een zaak. Afgesproken moet worden hoe en op welke momenten het documentenarchief van de LVO vanuit het dossier wordt bijgewerkt vanuit het dossier van het Bevoegd Gezag.

• De eigenaar van een gegeven is verantwoordelijk voor de kwaliteit (actualiteit, betrouwbaarheid) van

een gegeven (6.2.2.3). De LVO dient functionaliteit te bezitten om te zorgen dat genoemde actoren deze verantwoordelijkheid kunnen waarmaken. De actoren aan de kant van de aanvraag zullen de natuurlijke behoefte te hebben om hun aanvraag zo kwalitatief mogelijk in te brengen. Aan de kant van de overheid dienen de ketenpartners afspraken te maken zodat elke partij haar deel van de gegevens kwalitatief levert en beheert. Generieke afspraken dienen te zijn:

a) VROM zorgt voor landelijke kaderstelling b) regionaal maken ketenpartners onderling kaderstellende afspraken die de kwaliteit garanderen c) per procesgang is het bevoegd gezag eigenaar van de gegevens en bewaakt dat de kaders worden gehandhaafd; d) per procesgang voert elke betrokken partij haar deel conform het kader uit. Generieke afspraken b, c en d dienen in het voorbeeldproject aan de orde te komen.

• Voor de opslag van de gegevens wordt gekozen voor open standaarden en bijvoorbeeld XML. De

bijlagen worden bewaard in native formaat en tevens automatisch geconverteerd naar het defacto standaard PDF-formaat. Als eerste stap dient validatie plaats te vinden van het XML-bericht op basis


62

van de betreffende XML-schema's (wabo-stuf-msg.xsd, bg.xsd). Vervolgens vindt validatie plaats van de bedrijfslogica. Pas daarna wordt het bericht geregistreerd in het Zakenmagazijn van het Bevoegd Gezag.

• Overheidsorganisaties maken gebruik van (landelijke) basisregistraties (NORA 6.2.6.1).

Aan dit principe wordt invulling gegeven doordat enerzijds VROM in de ontwikkeling van de LVO rekening houdt met de koppelingen aan de (landelijke) basisregistraties en doordat anderzijds de overheidsorganisaties met hun systemen aansluiten op die basisregistraties of daarvan afgeleide kernregistraties. De mate waarin hangt af van de status van de landelijke basisregistraties en van het niveau van digitalisering binnen de overheidsorganisaties. Met name de volgende registraties zijn van belang:

o Nieuw Handelsregister (NHR, als de aanvraag betrekking heeft op een bedrijf); o Basisregistratie kadaster (BRK, om de locatie (perceel) en eventueel het zakelijk recht te

kunnen vastleggen); o Gemeentelijke Basisregistratie (GBA, om de aanvrager, gemachtigde, betrokkene,

vergunninghouder zijnde een natuurlijk persoon (ingezetene) te kunnen vastleggen); o Basisregistratie Topografie / GBKN (voor het vastleggen van de ruimtelijke omgeving van

het fysieke object van aanvraag). o Voor de provincie is van belang dat de focus met name ligt op Bedrijven (NHR) en

Lokaties (BRK). Dit is in het voorbeeldproject niet aan de orde! • De definitie en taxonomie van gegevens die opgenomen zijn in nationale basisregistraties zijn leidend

(6.2.4.5). Dit is niet alleen van belang voor de ontwikkeling van de LVO maar ook voor de registraties in de backoffices van de overheidsorganisaties. Deze zullen vanuit de bedrijfsprocessen vergunningverlening, handhaving, bezwaar en beroep gegevens registeren die in verband moeten worden gebracht met de objecten en subjecten waarop de aanvraag betrekking heeft: het fysieke object van de aanvraag (de inrichting) en de natuurlijke en niet-natuurlijke subjecten die bij de aanvraag betrokken zijn. Dit is in het voorbeeldproject niet van toepassing.

5.2.2 Objectmodel

Allereerst worden drie objectmodellen gepresenteerd die in de scope van de WABO een rol spelen. 1. Objectmodel LVO Vanuit de scope van het LVO zie het objectmodel er als volgt uit. Voor nadere detaillering wordt verwezen naar het functioneel ontwerp (refnr. [9]). 2. Objectmodel GFO Zaken Vanuit de scope van het bevoegd gezag wordt uitgegaan van GFO-Zaken (refnr. [11]). Het onderstaande diagram toont de relaties tussen de verschillende objecten.

Samenhang voor samenwerking, Project Start Architectuur Omgevingsvergunning voorbeeldproject Overijssel 63


64

Centraal in het GFO-Zaken staat het begrip ZAAK. Een zaak is een samenhangende hoeveelheid werk met een welgedefinieerde aanleiding en een welgedefinieerd eindresultaat, waarvan kwaliteit en doorlooptijd bewaakt moet worden. Een ZAAK wordt geïnitieerd door hetzij een SUBJECT of een ACTOR. De uitvoering van een zaak leidt meestal tot een welgedefinieerd resultaat. In veel gevallen is dit resultaat een beschikking. Een ZAAK kan leiden tot meerdere BESCHIKKINGEN. Over het algemeen is een ACTOR (MEDEWERKER of ORGANISATORISCHE EENHEID) verantwoordelijk voor een ZAAK. In een aantal gevallen doet een burger een VERZOEK dat aanleiding geeft tot het starten van meerdere ZAKEN. Een veel voorkomend voorbeeld is de bouw van een garage, waarvoor nodig zijn een sloopvergunning voor het slopen van een schuurtje, een kapvergunning voor het kappen van een paar bomen, een inritvergunning voor de aanleg van een inrit en een bouwvergunning voor de bouw van de garage. Voor de burger is dit een samenhangend pakket. Het GFO-Zaken maakt het mogelijk om deze ZAKEN te bundelen in een VERZOEK. Een VERZOEK wordt ingediend door een SUBJECT. De initiator van een VERZOEK wordt niet per definitie overgenomen door de initiator van de ZAAK. Een VERZOEK heeft als verantwoordelijke een ACTOR. Een ZAAK kan ontsloten worden via de erbij betrokken ADRESSEN, SUBJECTEN, KADASTRALE OBJECTEN en VERBLIJFSOBJECTEN. Een SUBJECT kan als aanvrager of in verschillende andere rollen BETROKKENE bij een zaak zijn. 3. Objectmodel Referentie Gemeentelijke Basisregistraties Vanuit de scope van het LVO én het bevoegd gezag is het Stelsel van Basisregistraties van belang met name in verband met de ruimtelijke ligging van de inrichting (refnr. [15]). Het onderstaande diagram toont de relaties tussen de verschillende objecten.


65

Synergie van de objectmodellen Op basis van bovenstaande 3 modellen is een objectmodel samengesteld waarbij in het rood de relevante onderdelen voor het project zijn aangegeven: Inrichtingsprincipes (deels uit refnr. [12]): • Recordmanagement moet een plaats krijgen in de besturing van een overheidsorganisatie

o Ketenpartners moeten afspraken maken over recordmanagement Het gaat speciaal om afspraken m.b.t. metadata en zaken als classificatieschema. Hierbij moet helder zijn wie verantwoordelijk is voor welk deel van de records in een proces. De registratie moet ook zodanig zijn dat de records toegankelijk blijven.

• Een record moet voldoen aan de standaarden van recordmanagement: Een record moet authentiek,

betrouwbaar, integer en bruikbaar zijn o Een record moet gerelateerd zijn aan een processtap via de contextuele metadata. o De samenhang tussen records moet geborgd kunnen worden.

• Bij recordmanagement moet aandacht worden besteed aan informatiebeveiliging. • Samenwerkende organisaties organiseren de vastlegging van metagegevens met een

organisatieoverschrijdend karakter op een inhoudelijk consistente wijze o Dit betekent voor de WABO dat een ketenregisseur moet worden aangewezen die zorgt dat

deze afspraken worden gemaakt. o In deze context zijn het bevoegd gezag en de adviserende organen de ketenpartners. De

ketenregie moet bij 1 van die partijen worden gelegd. Omdat provincies, gemeenten en waterschappen in wisselende rollen deelnemen aan de keten is het logisch de afspraken op


66


67

niveau van de deelnemende provincies en gemeenten te benoemen en te laten bekrachtigen door IPO / VNG / UvW.


68

5.2.3 Berichtencatalogus

Bij de communicatie tussen de ketenpartners zijn een aantal berichten te onderscheiden. Hieronder worden de berichten opgesomd, waarbij een onderverdeling naar de processtappen is gemaakt. De processtap “Vooroverleg” en de aanroep van de service “Publicatie” is hier buiten beschouwing gelaten. Deze onderdelen liggen buiten de scope van het voorbeeldproject. Een interne memo van het voorbeeldproject is gebruikt (refnr. [14]). De berichten dienen nog verder verfijnd te worden en dienen een uitwerking te krijgen in de technische Architectuurlaag. Voeren vooroverleg * Intaken aanvraag (IA) Nummer IA1/1 Naam Aanvraag Inhoud bericht Bericht van ontvangst van de aanvraag. Dit bericht omvat een notificatie, de

aanvraaggegevens en de bijlagen. Afzender Aanvrager Geadresseerde Bevoegd gezag

Adviserend orgaan Opmerking Aanmaken van een nieuwe zaak in het Zakenmagazijn van het Bevoegd

Gezag. Het Bevoegd Gezag stuurt aanvraag naar adviserende organisatie incl. alle relevante bijlagen. Hieronder zijn ook ingediende aanvullingen gerekend.

Nummer IA1/2 Naam Ontvangstbevestiging Inhoud bericht Bericht met bevestiging van de ontvangst van de aanvraag Afzender Bevoegd gezag Geadresseerde Aanvrager Opmerking Nummer IA3 Naam Wijziging bevoegd gezag Inhoud bericht Bericht dat de aanvraag door een ander bevoegd gezag wordt behandeld Afzender Bevoegd gezag dat aanvraag heeft ontvangen Geadresseerde Bevoegd gezag dat aanvraag moet ontvangen

Aanvrager Opmerking Toevoegen service “bijwerken bevoegd gezag” Nummer IA4 Naam Verzoek aanvullende informatie Inhoud bericht Afzender Bevoegd gezag


69

Geadresseerde Aanvrager Opmerking Het ontvangen van de aanvullende informatie kan worden verzorgd door de

service “ontvangen aanvraag” Nummer IA5 Naam Kennisgeving aanvraag buiten behandeling Inhoud bericht Bericht dat de aanvraag buiten behandeling wordt gesteld Afzender Bevoegd gezag Geadresseerde Aanvrager Opmerking Nummer IA6/1 Naam Verzoek om geheimhouding Inhoud bericht Verzoek om geheimhouding van stukken in de aanvraag. Afzender Aanvrager Geadresseerde Bevoegd gezag Opmerking Dit verzoek kan worden aangevraagd op elk moment tot het moment dat de

aanvraag ontvankelijk is verklaard. Nummer IA6/2 Naam Verklaring geheimhouding Inhoud bericht Afzender Bevoegd gezag Geadresseerde Aanvrager Opmerking Hier wordt een besluit over genomen. Moet dit besluit ook worden

gepubliceerd. Hiervoor de service “publicatie besluit” toevoegen. Nummer IA7 Naam Melding behandelaar aanvraag bij subzaak Inhoud bericht Afzender Adviserend orgaan Geadresseerde Bevoegd gezag Opmerking Afspraak maken dat elke organisatie een coördinator heeft. De coördinator

bij het bevoegd gezag legt de adviserende organen vast in de LVO. Wat betekent dit voor het vastleggen van behandelaars?


70

Toetsen ontvankelijkheid (TO) Nummer TO1/1 Naam Verzoek toets ontvankelijkheid Inhoud bericht Bericht met de vraag om de ontvankelijkheid van de aanvraag te toetsen Afzender Bevoegd gezag Geadresseerde Adviserend orgaan Opmerking Dit bericht moet worden uitgesplitst naar alle interne en externe

adviserende overheidsorganen: toevoegen service “aanvragen toets ontvankelijkheid”

Nummer TO1/2 Naam Ontvangst toets ontvankelijkheid Inhoud bericht Bericht om de toets op de ontvankelijkheid van de aanvraag te ontvangen. Afzender Adviserend orgaan Geadresseerde Bevoegd gezag Opmerking Dit bericht moet worden verzameld vanuit alle interne en externe

adviserende overheidsorganen: toevoegen service “verzamelen toetsen ontvankelijkheid”

Nummer TO2 Naam Kennisgeving start behandeling Inhoud bericht Bericht om aan de aanvrager kenbaar te maken dat de behandeling is

gestart en welke procedure wordt gevolgd. Afzender Bevoegd gezag Geadresseerde Aanvrager Opmerking Nummer TO3 Naam Verzoek legesheffing Inhoud bericht Intern bericht met het verzoek om legesheffing Afzender Bevoegd gezag coördinator (intern) Geadresseerde Bevoegd gezag financiën (intern) Opmerking Toevoegen interne service “legesheffing”. Berichtgeving rond legesheffing

ligt buiten scope


71

Behandelen aanvraag (BA) Nummer BA1 Naam Kennisgeving verlengen behandeling Inhoud bericht Bericht dat de behandelingstermijn van de aanvraag wordt verlengd Afzender Bevoegd gezag Geadresseerde Aanvrager Opmerking Nummer BA2/1 Naam Verzoek advies (deelproducten) Inhoud bericht Bericht met de vraag om de deelproducten voor de vergunning te maken. Afzender Bevoegd gezag Geadresseerde Adviserend orgaan Opmerking Dit bericht moet worden uitgesplitst naar alle interne en externe

adviserende overheidsorganen: toevoegen service “aanvragen maken van deelproducten”

Nummer BA2/2 Naam Ontvangst advies (deelproducten) Inhoud bericht Bericht om een deelproduct van de vergunning te ontvangen. Afzender Adviserend orgaan Geadresseerde Bevoegd gezag Opmerking Dit bericht moet worden verzameld vanuit alle interne en externe

adviserende overheidsorganen: toevoegen service “verzamelen gemaakte deelproducten”

Nummer BA3/1 Naam Verzoek reactie op concept ontwerp beschikking Inhoud bericht Afzender Bevoegd gezag Geadresseerde Adviserend orgaan Opmerking Dit bericht moet worden uitgesplitst naar alle interne en externe

adviserende overheidsorganen: toevoegen service “aanvragen maken van deelproducten”

Nummer BA3/2 Naam Ontvangst reactie op concept ontwerp beschikking Inhoud bericht Afzender Adviserend orgaan Geadresseerde Bevoegd gezag Opmerking Dit bericht moet worden verzameld vanuit alle interne en externe

adviserende overheidsorganen: toevoegen service “verzamelen gemaakte deelproducten”


72

Opstellen en verwerken ontwerp besluit (OB) Nummer OB1 Naam Bekendmaking ontwerp besluit Inhoud bericht Afzender Bevoegd gezag Geadresseerde Aanvrager

Adviserend orgaan Opmerking Hier hoort ook bij de aanroep van de publicatie van het ontwerp besluit en

het ter inzage leggen van het ontwerp besluit. Hiervoor de service “publicatie besluit” toevoegen.

Nummer OB2 Naam Ontvangst zienswijze Inhoud bericht Afzender Aanvrager

Belanghebbende Geadresseerde Bevoegd gezag Opmerking Tevens een service “Registeren zienswijzen” toevoegen om de zienswijzen

te kunnen vastleggen. Op basis van het bericht van ontvangst kan het beoordelen van de ingebrachte zienswijzen in gang worden gezet.

Nummer OB3/1 Naam Verzoek advies op zienswijzen Inhoud bericht Bericht met de vraag om een advies te geven op de ingebrachte

zienswijzen. Afzender Bevoegd gezag Geadresseerde Adviserend orgaan Opmerking Dit bericht moet worden uitgesplitst naar alle interne en externe

adviserende overheidsorganen: toevoegen service “aanvragen advies ontwerp besluit”

Nummer OB3/2 Naam Ontvangst advies op zienswijzen Inhoud bericht Bericht om een advies op de zienswijzen te ontvangen. Afzender Adviserend orgaan Geadresseerde Bevoegd gezag Opmerking Dit bericht moet worden verzameld vanuit alle interne en externe

adviserende overheidsorganen: toevoegen service “verzamelen adviezen”


73

Opstellen definitief besluit (DB) Nummer DB1 Naam Bekendmaking definitief besluit Inhoud bericht Afzender Bevoegd gezag Geadresseerde Aanvrager

Adviserend orgaan Opmerking Bericht van de aanroep van de publicatie van het definitief. Hiervoor de

service “publicatie besluit” toevoegen. Nummer DB2 Naam Kennisgeving aanhouden beslissing Inhoud bericht Bericht dat het nemen van een beslissing is aangehouden Afzender Bevoegd gezag Geadresseerde Aanvrager

Adviserend orgaan Opmerking Overdragen * Nummer OD1 Naam Verzoek overdracht voor handhaving Inhoud bericht Bericht met de vraag om het dossier van de aanvraag en de uitgevoerde

zaak over te dragen voor handhaving. Afzender Bevoegd gezag voor vergunningverlening Geadresseerde Bevoegd gezag voor toezicht en handhaving Opmerking De overdracht is nodig om relevante onderdelen van het dossier

beschikbaar te stellen voor het bedrijfsproces “Toezicht houden en handhaven”.

Nummer OD2 Naam Verzoek overdracht voor archivering Inhoud bericht Bericht met de vraag om het dossier van de aanvraag en de uitgevoerde

zaak over te dragen voor archivering. Afzender Bevoegd gezag voor vergunningverlening Geadresseerde Bevoegd gezag voor toezicht en handhaving Opmerking De overdracht is enerzijds nodig om het dossier af te sluiten en voor te

bereiden voor archivering. Generiek (processtap onafhankelijk) Nummer G1/1


74

Naam Verzoek om statusinformatie van `subzaak` Inhoud bericht Opvragen van de status van een subzaak binnen een zaak. Afzender Bevoegd gezag Geadresseerde Adviserend orgaan Opmerking Dit is nodig om de actuele status van de gehele zaak te kunnen

communiceren. Nummer G1/2 Naam Levering van statusinformatie van `subzaak` Inhoud bericht Leveren van de status van een subzaak binnen een zaak. Afzender Adviserend orgaan Geadresseerde Bevoegd gezag Opmerking Dit is nodig om de actuele status van de gehele zaak te kunnen

communiceren. Nummer G2/1 Naam Verzoek om statusinformatie van `zaak` Inhoud bericht Opvragen van de status van de zaak. Afzender Aanvrager Geadresseerde Bevoegd gezag Opmerking Dit bericht is opgebouwd uit de statusinformatie van de onderliggende

subzaken. Hierin kan ook meer informatie worden gegeven, zoals Opvragen van de lopende zaken bij een bevoegd gezag, Opvragen van alle zaakgegevens.

Nummer G2/2 Naam Levering van statusinformatie van `zaak` Inhoud bericht Leveren van de status van de zaak. Afzender Bevoegd gezag Geadresseerde Aanvrager Opmerking Dit bericht is opgebouwd uit de statusinformatie van de onderliggende

subzaken. Hierin kan ook meer informatie worden gegeven, zoals Opvragen van de lopende zaken bij een bevoegd gezag, Opvragen van alle zaakgegevens.

Nummer G3 Naam Verzoek om intrekking van aanvraag Inhoud bericht De aanvrager verzoekt om de aanvraag in te trekken. Dit kan op elk

gewenst moment. Is met name relevant nadat de aanvraag formeel is ingediend.

Afzender Aanvrager Geadresseerde Bevoegd gezag

Adviserende orgaan


75

Opmerking Het Bevoegd Gezag stuurt een intrekking van de aanvraag door naar de adviserende organisatie

Overzicht van deze berichtenuitwisseling


76


77


78

Overzicht van de elektronische koppelvlakken van de LVO De Landelijke Voorziening Omgevingsvergunning voorziet momenteel in de volgende elektronische koppelvlakken: Elektronisch koppelvlak LVO Correspondeert met

berichtencatalogus K1 Verzenden van aanvraag met bijlage aan bevoegd gezag. IA1/1 K2 Verzenden van aanvullingen (extra bijlagen) aan bevoegd gezag, in feite is dit een beperkte vorm van koppelvlak K1

IA1/1

K3 Ontvangen van referentienummer van het verzoek (in feite de zaak waar de aanvraag bij hoort) van het bevoegd gezag

Nog niet onderkend

K4 Ontvangen van statusinformatie van het bevoegd gezag G2/2, niet G2/1 en G1/1-2. K5 Generiek bericht voor het verzenden van e-mail-notificaties (asynchroon)

De relatie tussen de notificaties en de berichten zijn nog niet bekend.

K6 Verzenden van adviezen (documenten) aan het bevoegd gezag.

Generiek bericht dat te gebruiken is voor TO1/2, BA2/2, BA3/2, OB3/2. Niet geschikt voor G1.

Conclusie De berichtenuitwisseling die nu is gedefinieerd c.q. die de LVO levert is veel smaller dan nodig is voor de berichtenuitwisseling tussen aanvrager – bevoegd gezag en adviserend orgaan. Daarom dient nader uitgezocht te worden welke berichten in de berichtencatalogus digitaal moeten worden ondersteund, al dan niet door de LVO. Daarover moeten afspraken worden gemaakt. Daarnaast dient nader uitgezocht te worden of het koppelvlak K5 van de LVO voor e-mail-notificaties in alle aansluitvormen de gewenste berichtenuitwisseling voldoende afdekt. Ten slotte is het wenselijk de berichtendefinities op gegevensniveau semantisch te beschrijven. Dit geldt bij de LVO berichten natuurlijk vooral voor de aanvraaggegevens (K1) en de statusinformatie (K5).


79

5.3 Informatie uitwisseling

Onder informatie-uitwisseling wordt verstaan ‘alles wat met het verzenden en ontvangen van berichten te maken heeft’. In dit domein staat het gebruiken van servicebussen als communicatiemechanisme centraal. Procesorchestratie is een belangrijke uitdaging binnen de WABO.

5.3.1 Architectuurprincipes De belangrijkste principes in dit domein zijn: • Het berichtenverkeer binnen de e-overheid ontwikkelt zich in de richting van een naadloos op elkaar

aangesloten hiërarchie van samenwerkende servicebussen (6.4.1). Bij de implementatie van de omgevingsvergunning moet rekening gehouden worden met het feit dat de samenwerking met de ketenpartners en het gebruik van landelijke voorziening (LVO) op termijn kan aansluiten op landelijke ontwikkelingen zoals de Overheids Service Bus. De ontwikkeling van de LVO en de regionale ketenafspraken moeten leiden tot het gebruik van servicebussen. Dit betekent dat rekening moet worden gehouden met de standaarden die daar bij horen. De Overheids Service Bus is momenteel nog niet beschikbaar. In het voorbeeldproject zal er praktijkervaring moeten worden opgedaan met de service bus bij het bevoegd gezag, randvoorwaarden en invulling van de infrastructuur moeten bekend zijn.

• De logische koppeling van organisaties aan sectorale bussen geschied door business proces

management oplossingen (6.4.7). Het orchestreren van het afhandelingsproces van een omgevingsvergunning is één van de belangrijkste vraagstukken bij de invoering van de WABO. In het voorbeeldproject zal praktijkervaring moeten worden opgedaan met business proces management bij het bevoegd gezag.

5.4 Servicebussen

Om de informatievoorziening in de keten efficiënt te laten verlopen is het noodzakelijk te beschikken over een transportlaag voor het aanroepen van diensten (webservices), het uitwisselen van berichten en het uitwisselen van bestanden. Inrichtingsprincipes Inrichtingsprincipes voor de WABO zijn: • Asynchrone verzending van e-mail-notificaties tussen aanvrager, bevoegd gezag en adviserend

orgaan. • Verzenden van een bericht met de gegevens van het aanvraagformulier en de bijlagen van aanvrager

naar bevoegd gezag en ketenpartners. De aanvraag wordt als 1 transactie verwerkt om veel handmatige handelingen en het risico van incompleetheid te voorkomen.

• Er dient rekening te worden gehouden met omvangrijke bijlagen. Het verzenden en ontvangen van de aanvraag mag niet leiden tot wachttijden bij aanvrager en ketenpartners.

• Berichten voor communicatie en besturing / coördinatie worden direct maar wel asynchroon verzonden. • Er ontstaat geen afhankelijkheid tussen de infrastructuur van de landelijke voorzieningen en de

infrastructuur van de ketenpartners. Dit betekent het gebruiken van een ontkoppelmechanisme bij de uitwisseling tussen informatiesystemen.

Architectuurontwikkelstrategie servicebussen De inzet van servicebussen is te koppelen aan de in hoofdstuk 4 genoemde architectuurontwikkelstrategie. Voor de servicebussen zien de plateaus van ontwikkeling er als volgt uit: De servicebus voor de WABO kent de volgende invulling:


80

6 Uitwerking voorkeursoplossing Technische architectuur

De technische architectuur beschrijft het samenstel van machines, opslagvoorzieningen en netwerkcomponenten vanuit technologische optiek. Het is een middel om de uitwisseling van informatie tussen applicaties te kunnen verwezenlijken, als uitwerking van de dienstgerichte architectuur (service oriented architecture'). De technische architectuur bestaat uit drie aspecten: • systeem: de technische actoren ('clients', 'servers') en logische systemen ('middleware') • gegevensopslag: de technische representatie van gegevens • netwerk: de manier waarop gegevens worden uitgewisseld De kerngedachte in dit domein is, dat overheidsorganisaties vrij zijn in het kiezen van technische componenten, mits aan eisen van beschikbaarheid, interoperabiliteit, robuustheid en beveiliging is voldaan.

6.1 Applicaties en koppelvlakken

Deze paragraaf beschrijft de applicaties en koppelvlakken waarvan het beheer en eigenaarschap binnen de context van het voorbeeldproject WABO-ICT vallen.

6.1.1 Gebruikte architectuurprincipes De volgende principes zijn relevant voor het voorbeeldproject:

Samenhang voor samenwerking, Project Start Architectuur Omgevingsvergunning voorbeeldproject Overijssel 81


82

• Het voorbeeldproject richt zich met name op de inzet van ICT t.b.v. het WABO-proces (NORA 6.1.1.1). • Er wordt gestreefd naar duidelijke functionele componenten en een (daaruit voortvloeiend) transparante

ontwerp van 'het geheel' (NORA 6.1.1.2 en 6.1.1.3). • In het voorbeeldproject wordt uitgegaan van digitale aanlevering via het LVO, besturing d.m.v. BPM

en/of workflow en het gebruik van een servicebus als (technisch) integratiemechanisme (NORA 6.1.1.4).

• Aandachtspunt voor het voorbeeldproject is dat workflow gecombineerd moet worden met de besturing van het gehele afhandelingsproces (NORA 6.1.1.5 en 6.1.1.6).

• Voor het zaakmanagement wordt gekozen voor een kant-en-klaar product dat voldoet aan internationale open standaarden. De internationale standaard Java/J2EE wordt gekozen als framework (NORA 6.1.1.8 en 6.1.1.9).

• Het is van belang om de juiste granulariteit te kiezen zodat de services direct gerelateerd kunnen worden aan het WABO-proces (NORA 6.1.3.1).

• Gegarandeerd moet worden dat transacties volledig kunnen worden uitgevoerd en in geval dat niet lukt, dat deze op beheerste wijze weer kunnen worden teruggedraaid met - indien nodig - een melding aan de betrokkenen (NORA 6.1.3.3).

• De gemaakte services dienen landelijk beschikbaar te komen indien hergebruik van toepassing is (NORA 6.1.3.4).

6.1.2 Applicaties

In het voorbeeldproject spelen de volgende applicaties een rol: • De LVO zoals gebouwd door het VROM maakt gebruik van:

o Be Informed omgeving voor Kennismanagement, Casemanagement en Documentmanagement

o Be Informed studio wordt gebruikt voor het beheer en onderhoud. • Het bevoegd gezag maakt gebruik van:

o Een zaakmanagementsysteem met zakenregister o Een klantcontactsysteem o Een vergunningverleningsysteem o Eigen kernregistraties gebaseerd op de registraties voor de Risicokaart o Een Documentmanagementsysteem voor dossiervorming

Voor de realisatie van de LVO zijn een aantal componenten vereist, die de functionaliteit bieden die door de informatie- en bedrijfsarchitectuur vereist zijn. De figuur geeft een overzicht van deze componenten op hoog niveau. De plaatsen waar communicatie tussen deze componenten plaatsvindt, zijn de koppelvlakken. De volgende paragraaf tracht in kaart te brengen welke functionaliteit precies door deze koppelvlakken geleverd moet worden. Bij de inrichting van de technische componenten zijn een aantal architectuurprincipes conform NORA te hanteren. Deze principes zijn niet alleen toepasbaar op de LVO als totaal, maar ook op de services die LVO levert. De principes zijn: • Beschikbaarheid van LVO, zijn afzonderlijke componenten en de services. LVO als landelijke

voorziening is een zogenaamd ‘mission critical system’ zodat hoge eisen op dit gebied gesteld worden. • Interoperabiliteit. Door te voldoen aan StUF 2.05 wordt interoperabiliteit met systemen van overheden

nagestreefd.


83

• Betrouwbaarheid. Door uitvoerig te testen van de gerealiseerd oplossing moet worden aangetoond dat LVO betrouwbaar is.

• Exclusiviteit. Dit dient binnen het LVO geregeld te worden met een autorisatiemechanisme, zoals dat ook bij de informatie architectuur is aangegeven. Het betreft naast autorisatie ook het toetsen of bepaalde informatie conform de wet openbaar gemaakt mag worden, zowel voor elke rol als voor een individu.

• Integriteit. Dit wordt nagestreefd door eenmalige gegevensopslag van die gegevens die ook in basisregisters voorkomen. Als een bevoegd gezag volgens verzendmethode 3 aansluit, zal LVO ook alleen als verwijsindex functioneren en geen gegevens dubbel opslaan. Naast opslag van gegevens dient ook integriteit van berichtuitwisseling gewaarborgd te worden. De technische infrastructuur dient hiervoor oplossingen aan te dragen, bijvoorbeeld door vercijferde verbindingen te gebruiken over publieke voorzieningen (zie verder).

6.1.3 Situatieschets beoogde componenten en koppelvlakken

6.1.4 Koppelvlak identificatie Onderstaande figuur aan welke services er vereist zijn voor de communicatie tussen de LVO en het bevoegd gezag.

LandelijkeVoorziening

Omgevingsvergunning

Bevoegd gezag

Backoffice / mid-office

Vragenboom

Dossiermodule

Formulierengenerator

KoppelvlakHet bevoegd gezag voert bewerkingen op een lopende aanvraag uit, zoals het toevoegen van documenten, of doorvoeren van statusupdates. Het soort bewerkingen hangt af van de manier waarop het bevoegd gezag de aanvraag wenst af te handelen.

Nadat het verkregen aanvraagformulier is ingevuld, wordt het naar de dossiermodule verstuurd. De aanvraag wordt als het ware ingediend.

Een aanvraag wordt (geheel of gedeeltelijk) doorgestuurd naar het juiste bevoegde gezag.

Op basis van een vragenboom wordt informatie aangaande het in te vullen formulier geleverd.


84

LandelijkeVoorziening

Omgevingsvergunning

Bevoegd gezag

formulierenService

Dossiermodule

Backoffice / mid-officeaanvraagControleService

Formulierengenerator

Vragenboom

aanvraagService

bijlageService

aanvraagService


85

De service waar we het nu over hebben wordt aangeboden door applicaties. Te zien is dat ook het bevoegd gezag een service aan moet bieden, op technisch vlak zal dit geleverd worden door het back- of mid-office systeem dat bij het bevoegd gezag operationeel is. Het is van belang afspraken te maken over het beheer van de specificaties van de services en de publicatie daarvan voor de ketenpartners in een serviceregister. Dit om wildgroei in technische services te voorkomen. Via het aangeboden koppelvlak kan de LVO ingediende aanvragen geheel, of gedeeltelijk doorsturen naar het juiste bevoegde gezag. Dit koppelvlak is in principe gelijk aan het koppelvlak dat hiervoor op de LVO is gedefinieerd. Indien een bevoegd gezag ervoor kiest deze service niet aan te bieden, zal de aanvraag via een ander kanaal aangeleverd moeten worden.

6.1.5 Koppelvlakspecificatie Na de identificatieslag van de koppelvlakken, zijn deze gespecificeerd. Dit is gedaan met de Web Service Description Language versie 1.1. Een WSDL-document van de omgevingsvergunningsdienst is samen met dit document verspreid. In dit document is voor relevante onderdelen documentatie en toelichting opgenomen. De specificatie en toelichting zijn door een XSLT-transformatie ook in HTML zichtbaar te maken door het WSDL document in een internet browser te laden. Deze browser activeert de transformatie en toont de documentatie uit het WSDL bestand in HTML.


86

6.2 Gegevensopslag

Gegevensopslag voldoet conform de uitwerking in de informatie architectuur aan de architectuurprincipes die NORA hiervoor stelt. Aanvullend worden de volgende principes gehanteerd:

• Gestructureerde gegevensopslag. Ontwikkel aan de hand van het objectmodel uit hoofdstuk 5 een relationeel databasemodel (NORA 7.2.1).

• Beschrijf de gegevensverzamelingen op een standaardmanier. Zie toelichting bij dit principe in de NORA (NORA 7.2.2).

• Zaaksysteem. De principes in NORA schrijven eenmalige gegevensopslag voor. Dit is realiseerbaar als alle daarvoor benodigde basisregisters zijn ingericht. Tot die tijd bevat het zaaksysteem van LVO ook de relevante gegevens uit de basisregisters, zoals die door een aanvrager zijn ingegeven (NORA 7.2.3).

• De gegevensstructuur van databases die door de ketenpartners worden gebruikt is gegevengericht opgezet, onafhankelijk van specifieke bedrijfsprocessen (NORA 7.2.1.1).

• Berichtendatabase. Aanroepen van services is een bijzondere vorm van een mutatie. Alle berichten die binnen die service worden uitgewisseld, worden apart opgeslagen. Deze database is een gecombineerd log en audit trail voor services. Opslag mag in XML formaat, waarbij wel de service consumer / provider wordt vermeld (NORA 7.2.1.2)

• Logging. Er dient een log te zijn, waarin alle ondernomen acties zijn opgenomen met datum en tijdstempel, identificatie van de functie/service, rol en gebruiker van die rol. Audit trail. Gerelateerd aan het log worden alle relevante mutaties opgeslagen. De combinatie van log en audit trail maakt het mogelijk een bepaalde situatie opnieuw te creëren, bijvoorbeeld om disputen op te lossen. (NORA 7.2.1.3)

• Documenten die gebruikt worden door meerdere overheidsorganisaties, of door burgers en bedrijven kunnen worden geraadpleegd, dienen elektronisch beschikbaar te worden gesteld via de landelijke voorziening (NORA 7.2.2.1)

6.3 Middleware

De volgende principes zijn van toepassing:

• De technische diversiteit van de middleware dient minimaal te zijn (NORA 7.1.1). • Het systeem dient opgebouwd te zijn uit open componenten en open interface

(NORA 7.1.1). • De logische koppeling van organisaties aan sectorale bussen geschied door business proces

management oplossingen. Dit is van belang voor het orkestreren van het afhandelingsproces van de WABO-omgevingsvergunning (NORA 6.1.1.6).

6.4 Platformen Hiervoor zijn de volgende principes aan te geven:

• De gekozen machines en platformen moeten open standaarden ondersteunen waardoor de uitwisselbaarheid tussen verschillende soorten soft- en hardware wordt gegarandeerd (NORA 7.1.1).


87

• Applicaties dienen zoveel mogelijk onafhankelijk te zijn van specifieke platformen (hardware en operating system. Hiermee wordt bereikt dat de ontwikkeling, upgrade, gebruik en overdracht van applicatie zo effectief en efficiënt mogelijk kan worden uitgevoerd (NORA 7.1.1).

6.5 Netwerk

De volgende principes zijn relevant:

• Communicatie tussen overheden dient te verlopen over een gescheiden netwerk of via VPN verbindingen (NORA 7.3.1)

• Voor communicatie met de klant dient gebruik te worden gemaakt van algemene beschikbare en vrij verkrijgbare beveiligingstechnieken (bijvoorbeeld SSL). De klant moet geen speciale software hoeven aan te schaffen of te installeren (NORA 7.3.2).

• Het interne netwerk van overheidsorganisaties is via één redundant en veilig uitgevoerde koppeling aangesloten op het publieke netwerk. Dit principe dient te worden geïmplementeerd in de ICT-infrastructuur (NORA 7.3.3).

• Voor de data-uitwisseling wordt gebruik gemaakt van het TCP/IP (Transmission Control Protocol/Internet protocol). TCP/IP is het onderliggende protocol dat de basis vormt voor de andere internetprotocols, zoals HTTP en FTP. TCP/IP kan gezien worden als een soort netwerk-esperanto, waarmee allerlei verschillende hardware en software met elkaar kan communiceren.

Het netwerk waarop de LVO aangesloten wordt, handelt de communicatie met de buitenwereld af. Naast het pure transport is extra functionaliteit vereist. Deze functionaliteit wordt enerzijds door een service bus geleverd. Service bussen zijn er in veel soorten en maten, welke functionaliteit precies vereist is hangt af van de beoogde eindsituatie en het ambitieniveau. Voor de LVO zijn minimaal de volgende aspecten van belang om met de buiten wereld te communiceren.

• Communicatie o Routering o Addressering o Messaging mechanisme (bij voorkeur publish/subscribe en request/response) o Transportprotocol

• Service interactie o Service interface definities (WSDL) o Service messaging modellen (orchestratie, bijvoorbeeld BPEL)

• Management o Beheersfaciliteit ter ondersteuning van service management o Monitoring en logging

Een deel van deze minimale set wordt geleverd door de Overheids Service Bus (OSB), in ontwikkeling bij de Gemeenschappelijke Beheer Organisatie (GBO). Aansluiting op deze service bus is dus een logische stap. Bekeken moet worden welke aspecten er precies ondersteund zullen worden. Voorlopig lijkt het erop dat de OSB enkel in de meest basale transportfunctionaliteit zal voorzien. In dat geval moeten de overige punten binnen de LVO afgehandeld worden. Meer informatie over het gebruik van servicebussen binnen het overheidsdomein is te vinden in [HOL06]. Anderzijds moet worden onderzocht in hoeverre er gebruik gemaakt gaat worden van besloten, separate netwerken of open netwerken. Voor de communicatie met personen wordt gebruik gemaakt van Internet


88

protocollen, waarbij personen zich moeten identificeren. Aanvullend kan worden besloten om na identificatie gebruik te maken van beveiligde protocollen, bijvoorbeeld https. Tussen overheidsorganisatie moet worden onderzocht welk identificatie mechanisme en welke technische Internet protocollen gebruikt gaan worden. Als overheden alleen LVO gebruiken, is communicatie na identificatie via https te regelen. Https kan ook tussen overheden worden gebruikt, als alle servers correcte, geldige certificaten van een bevoegde autoriteit hebben.


89

7 Beheer

7.1 Beheer van de landelijke voorziening Ten behoeve van de landelijke voorziening moet een beheer organisatie worden ingericht. Met de gebruikers van de landelijke voorzieningen moeten afspraken worden gemaakt (SLA’s) over dat beheer. Hierbij valt te denken aan beschikbaarheid, beveiligingsmaatregelen zoals het maken van back-ups, beveiligde internetlijnen, autorisatie (wie mag welke dossiers inzien), authenticatie (DigID), etcetera. Wie mag welk dossier inzien en wie bepaalt dat? Het vraagstuk rondom autorisatie van meerdere ambtenaren van meerdere overheidsorganisaties moet zorgvuldig worden uitgewerkt. Hierbij spelen diverse beveiligingsaspecten. Ook afspraken over het inrichten van een helpdesk voor ondersteuning bij incidenten, storingen e.d. is van belang. Deze helpdesk moet zowel de aanvrager kunnen ondersteunen als deze bijv. (technische) problemen heeft met het formulier, als ook een overheidsorganisatie die een bepaald dossier niet kan inzien of problemen ondervindt met het binnenhalen van het dossier (XML-bericht met bijlagen.) Maar ook het functioneel beheer hoort onderdeel van de overeenkomst te zijn. Hierbij kan gedacht worden aan: • Aanpassingen in het formulier (vragenboom) als (wets)wijzigingen daarvoor aanleiding geven; • Afstemming over gebruikte standaards en afspraken over de keten heen (bijv. templates van XML-

berichten) • Het coördineren van het doorvoeren van wijzigingen. • Planning en van voorgenomen wijzigingen in functionaliteit of ondersteuning van nieuwe berichten of

gegevens. Hierdoor ontstaat een bestuurbaar overzicht over de wijzigingen in de keten.

7.2 Beheer van de voorzieningen bij de ketenpartner Het inrichten van het beheer voor de eigen bijdrage in de keten is volgens het subsidiariteitsbeginsel een zaak van de organisatie zelf. Hierbij dient de organisatie er wel voor te zorgen dat het beheer op een dusdanige manier is ingericht, dat de externe diensten en bijbehorende dienstenniveaus met betrouwbaarheid kunnen worden geleverd. Over het algemeen wordt beheer onderverdeeld in drie soorten: • Het functionele beheer. Dit is verantwoordelijk voor het in stand houden van de functionaliteit van de

ICT voorzieningen en deze optimaal te laten blijven aansluiten op de bedrijfsprocessen en daarmee samenhangende klantwensen. Een best practice framework op dit gebied is de Business information Services Library (BiSL).

• Het applicatiebeheer. Dit betreft het op een verantwoorde manier managen van beheer en onderhoud van applicatieprogrammatuur, gegevensverzamelingen en de bijbehorende documentatie, voor de hele levensduur van de bedrijfsprocessen. Voor het inrichten van het applicatiebeheer is op dit moment de Application services library (ASL) een best practice.

• Het technische beheer. Dit omvat het in stand houden van het geheel van de technische infrastructuur. De IT Infrastructure Library (ITIL) is al enige tientallen jaren de de facto standaard op dit gebied.


90

7.3 Beheeraspecten keten Het beheer van de keten is de zwakste schakel, niet het beheer van de landelijke voorziening en het beheer van de voorzieningen bij de ketenpartner. De belangrijkste beheerobjecten van de keten zijn: - de semantische definities van de gegevens en de berichten - de semantische definities en functionaliteiten van de services - het model voor procesbesturing in de keten - de rolgebaseerde autorisatie van het gebruik.


91

8 Beveiliging en privacy

8.1 Eisen en Architectuurprincipes Het belangrijkste fundament voor de eisen aan verwerking van informatie is bestaande wet en regelgeving. Hieruit worden de basisbeveiliging en privacymaatregelen, voor een informatiesysteem om de WABO elektronisch te faciliteren, vastgesteld. Naast de eisen vanuit de WABO stellen ook andere wetten eisen aan de bewerking van informatie. In het bijzonder de WBP stelt eisen op het gebied van privacy. De eisen zijn: • Identificeren van de aanvrager naar natuurlijk persoon • Waarborgen van eisen in de gehele keten • Waarborgen vertrouwelijkheid gegevens • Verwerking persoonsgegevens borgen volgens de WBP • Borgen van de informatie (Integriteit / Onweerlegbaarheid De volgende principes zijn van toepassing: • Binnen het informatiesysteem voor de WABO wordt informatie waar nodig geanonimiseerd. Hierdoor

wordt al op systeemniveau verwerking van persoonsgegevens (WBP) gewaarborgd (NORA 9.4.7). • Bij de uitvoer van de WABO zijn één of meerdere overheidinstanties betrokken. Om de eisen (o.a. de

doorlooptijd) in de gehele keten te borgen is het noodzakelijk dat beveiliging & privacy maatregelen bij elke ketenpartner zijn geïmplementeerd. Hierop moet vanuit de keten één centraal kader worden ontwikkeld . Het bevoegd gezag voert de regie op basis van zakelijke SLA’s tussen de partners. Voorbeeld van een maatregel is dat de ketenpartners dezelfde tijdsaanduiding gebruiken (NORA 9.6.1)

• Om de vertrouwelijkheid van de informatie te borgen is het noodzakelijk dat de authenticiteit (echtheid) van elke gebruiker wordt vastgesteld. Door aan te sluiten bij DIGID wordt deze eis op een eenduidige en transparante methode voor burgers & bedrijven gerealiseerd. PKIOverheid kan worden gebruikt om de eisen voor onweerlegbaarheid te waarborgen (NORA 9.7.1)

• Binnen DIGID zijn 3 zekerheidsniveaus gedefinieerd (basis, midden en hoog). Niveau HOOG geeft de mogelijkheid om de authenticiteit en onweerlegbaarheid eisen te realiseren. Niet alle zekerheidsniveaus worden op dit moment door DIGID ondersteund. zie http://www.digid.nl/overheid/over-digid/zekerheidsniveaus/ (NORA 9.7.3)

Vanuit beveiliging en privacy staan de volgende aspecten voor een informatiesysteem, ter ondersteuning van de WABO, centraal: • Vertrouwelijkheid: het beschermen van gegevens tegen onbevoegde kennisname; • Integriteit: het waarborgen dat gegevens niet ongecontroleerd worden gewijzigd of verloren gaan; • Beschikbaarheid: het zekerstellen dat gegevens en informatiediensten op de gewenste momenten

beschikbaar zijn voor de gebruiker. Voorgesteld wordt om een landelijke risicoanalyse uit te voeren op deze aspecten.

8.2 Beveiligingsaspecten keten De informatiebeveiliging van de keten kan als volgt worden gepresenteerd (uit refnr. [13]): De LVO kan hierbij aan de linkerkant op het landelijke niveau worden gedacht en de informatievoorziening en ICT-infrastructuren van de ketenpartners aan de rechterkant. Het middengedeelte is voor de berichtenuitwisseling binnen de keten: met servicebus voor transport en services voor de uitwisseling. Dit middengedeelte ontbreekt op dit moment. Ongeacht de latere invulling van het middengedeelte dienen er afspraken te worden gemaakt over de informatiebeveiliging van de keten als geheel. Hiervoor is het nodig de afhankelijkheden en kwetsbaarheden van de gehele keten in kaart te brengen en na een risicoanalyse de beveiligingsmaatregelen vast te stellen en te implementeren. Afhankelijk van de gekozen invulling voor het middengedeelte zullen de beveiligingsmaatregelen dienen te worden ingevuld. Relevante inrichtingseisen zijn:

Service

ServiceBurgers

BedrijvenOSB Beveiligd

koppelvlakBeveiligd

koppelvlak

Organisatie X

PortalGemeensch.

FrontOffice

Beveiligdkoppelvlak

NORA compliant domein

Niet- ketendomein

Extern domein

EU Bus

Ketenpartner met gedeeltelijke NORA compliancy

Gegevens

Niveau 2

Niveau 1

Ketenpartner domein

OTP

Besturing IB componenten NORA compliant domein Besturing IB comp. Ketenpartner

• De ketenregisseur is verantwoordelijk voor het vaststellen van de ketentypologie en de wijze waarop deze doorwerkt naar de NORA-compliancy voor informatiebeveiliging, inclusief afwijkingen en/of aanvullingen op de NORA-kaders.

• Er is een referentiemodel voor de informatiebeveiliging van de keten waar de ketenpartijen gebruik van kunnen maken om hun beveiligingsmaatregelen in te vullen.

• Over het naleven van het NORA-kader wordt door de ketenparters verantwoording afgelegd in een beheerverslag. Hiervoor gelden per ketentype afzonderlijke verantwoordingsstandaards.

• Ketenpartners zijn zelf (via het lijnmanagement) verantwoordelijk voor de handhaving van de informatiebeveiliging van hun onderdeel binnen de keten.

• De ketenregisseur is verantwoordelijk voor de handhaving van de informatiebeveiliging van de keten als geheel. De ketenregisseur zorgt ook voor het referentiemodel voor de informatiebeveiliging van de keten.


92


93

• Indien de ketenregisseur zelf een partij is in de keten, dan dient deze via een Third Party Mededeling een onafhankelijke partij de keten te laten auditen.

8.3 Autorisatie

Het plaatje in de voorgaande paragraaf laat zien dat de LVO een verhoogd risico geeft. Weliswaar is de LVO links en rechts omringd door beveiligde koppelvlakken, maar het risicoverhogende element is dat er geen scheiding is tussen het aanvragen (door burgers en bedrijven) en het behandelen van de aanvraag (door de overheid). Dit omdat beide onderdelen in één systeem zijn opgenomen . Dit geldt met name voor overheden die kiezen voor aansluitvariant 1 (volledig gebruik van de LVO). Een ander risicoverhogend element hierbij is het aanvragen van vergunningen door overheden zelf. Dit vraagt om functiescheiding in het gebruik van de aanvraagmodule en de behandelmodule van de LVO. Bij een servicegerichte benadering zijn deze problemen te voorkomen. Vooralsnog moeten hier extra maatregelen voor genomen worden. De te hanteren principes zijn: • De keten voorziet in functiescheiding tussen de rollen die door overheden kunnen worden vervuld en

rollen die door burgers en bedrijven kunnen worden vervuld. Eén functionaris kan niet zowel een rol binnen het aanvraagproces krijgen als binnen het behandelproces.

• Functioneel beheer voor het aanvraagproces is controletechnisch gescheiden van het functioneel beheer voor het behandelproces. Eén functionaris kan niet zowel een rol binnen het beheer van het aanvraagproces krijgen als binnen het beheer van het behandelproces.

• Autorisatie van personen door de aanvrager is aanvraag gebonden. • Autorisatie van personen door de coördinator is aanvraag gebonden. • Bundeling van meerdere aanvragen tot één verzoek mag niet leiden tot een verlaagd

beveiligingsniveau. • De autorisatie borgt de afscherming van gegevens op grond van verzoeken om geheimhouding. • De informatieverstrekking aan het publiek (raadplegen van gepubliceerde aanvragen en besluiten) kent

een minimale set aan gegevens die verstrekt worden. Deze minimale set voldoet aan de WBP en kan alleen ingeperkt worden door een verzoek om geheimhouding (hierbij moet worden nagegaan of dit juridisch klopt).

Bijlagen


94


95

Bijlage A - Coördinatievarianten voor case-management


96


97


98

Tabel 2 Voor- en nadelen coördinatievarianten

Procedurele coördinatie Professionele coördinatie Voordelen:

• Aanvrager heeft alleen te maken met contactpersoon

• Contactpersoon coördineert inhoudelijke en procedurele afstemming

• Totaaloverzicht bij contactpersoon Nadelen:

• Aanvrager is afhankelijk van deskundigheid en vaardigheid contactpersoon

• Contactpersoon heeft geen bevoegdheden. • Contactpersoon is afhankelijk van

management en inhoudelijk deskundigen op vakafdelingen

• Contactpersoon kan niet alle inhoudelijke vragen beantwoorden

• Contactpersoon is verantwoordelijk voor procedurele afstemming tussen vakafdelingen

Voordelen: • Aanvrager heeft contact met inhoudelijk

deskundigen • Contactpersoon coördineert inhoudelijke en

procedurele afstemming • Totaaloverzicht bij contactpersoon

Nadelen:

• Aanvrager is afhankelijk van deskundigheid en vaardigheid contactpersoon

• Contactpersoon kan totaaloverzicht verliezen

• Contactpersoon heeft geen bevoegdheden. • Contactpersoon is afhankelijk van

management en inhoudelijk deskundigen op vakafdelingen

• Contactpersoon kan niet alle inhoudelijke vragen beantwoorden

• Contactpersoon is verantwoordelijk voor procedurele en inhoudelijke afstemming tussen vakafdelingen

Vergunningmanager (provincie) Projectteam (provincie) Voordelen:

• Geen organisatiewijziging noodzakelijk. • Goede en eenduidige vergunningverlening

door vergunningmanager • Contact met aanvrager via 1 persoon • Bevoegd gezag coördineert inhoudelijke

afstemming • Bevoegd gezag coördineert procedurele

afstemming • Totaal overzicht en inzicht bij

vergunningmanager • Korte fysieke afstand tussen

vergunningmanager en provinciale deskundigen

Nadelen:

Voordelen: • Geen organisatiewijziging noodzakelijk. • Projectleider heeft bevoegdheden binnen

projectteam • Goede en eenduidige vergunningverlening

door projectleider • Deskundigen direct contact met aanvrager • Bevoegd gezag coördineert inhoudelijke

afstemming • Bevoegd gezag coördineert procedurele

afstemming • Totaal overzicht bij projectleider • Korte fysieke afstand tussen projectleider

en provinciale deskundigen • Inhoudelijke afstemming met deskundigen

in projectteam. Nadelen:

• Projectleider kan niet alle inhoudelijke


99

• Vergunningmanager heeft geen bevoegdheden.

• Vergunningmanager extra schakel tussen front- en backoffice

• Vergunningmanager is afhankelijk van management

• Vergunningmanager kan niet alle inhoudelijke vragen beantwoorden

• Deskundigen komen niet formeel bijeen • Vergunningmanager beschikt over

onvoldoende kennis

vragen beantwoorden • Projectleider extra schakel tussen front- en

backoffice • Contactpersoon kan totaaloverzicht

verliezen • Aanvrager heeft met diverse partijen te

maken (dus geen 1 loket) • Projectleider beschikt over onvoldoende

kennis • Huidige vergunningverleners hebben

onvoldoende leidinggevende ervaring • Complexe procedures vereisen omvangrijk

projectteam • Huidige organisatie is onvoldoende

ingespeeld op projectteam structuur • Projectleider kan overzicht verliezen door

contacten tussen aanvrager en deskundigen.

Bijlage B - Schematische weergave plateaus

Samenhang voor samenwerking,

100 Project Start Architectuur Omgevingsvergunning voorbeeldproject Overijssel


101

Bijlage C – Relatie met “Hoofdprocessen” voorbeeldproject Vanuit het voorbeeldproject zijn twaalf “hoofdprocessen” benoemd. In feite gaat het om processtappen. Om de relatie met de processchema’s te kunnen leggen zijn de processchema’s van het bedrijfsproces “verlenen vergunning” vertaald naar processtappen (linkerkolom) en is de link naar de twaalf “hoofdprocessen” (rechterkolom) als volgt gelegd. Vetgedrukt zijn de toegevoegde “hoofdprocessen” in de rechterkolom. De met een “*” gemarkeerde processtappen vallen buiten de scope van het voorbeeldproject. Processtappen “Hoofdprocessen” Voeren vooroverleg * Intake aanvraag 1. Importeren aanvraag met bijlage van LVO

2. Beoordelen aanvraag (op volledigheid) 3. Plannen (organisatie en logistiek) aanvraag afhandeling 8. Beschikken - Buiten behandeling stellen 8. Beschikken – Verklaring van geheimhouding voor aanvrager

Toetsen ontvankelijkheid Beoordelen aanvraag Verdelen toetsen ontvankelijkheid (intern en extern) Aanleveren toetsen ontvankelijkheid Bundelen toetsen ontvankelijkheid 8. Beschikken - Buiten behandeling stellen 8. Beschikken – Legesheffing 8. Beschikken – Verklaring van geheimhouding voor aanvrager

Behandelen aanvraag 4. Verdelen adviesaanvragen (intern en extern) 6. Aanleveren adviezen 7. Bundelen adviezen

Opstellen en verwerken ontwerp besluit

8. Beschikken - Ontwerp besluit (verlenen, weigeren) 8. Beschikken – Verklaring van geheimhouding voor belanghebbenden Verdelen adviezen over zienswijzen (intern en extern) Aanleveren adviezen over zienswijzen Bundelen adviezen over zienswijzen

Opstellen definitief besluit

8. Beschikken – Definitief besluit (verlenen, weigeren) 10. Afsluiten aanvraag-proces

Overdragen * 11. Overdragen dossier aan archief 12. Overdragen gegevens aan handhaving

Hierbij worden de volgende kanttekeningen geplaatst: • “Hoofdproces 5. Bewaken van de voortgang en status aanvraag-afhandeling” van de behandeling vindt

gedurende het gehele proces plaats. • “Hoofdproces 9. Publiceren” is de aanroep van een service “Publicatie”.

Een Project Start Architectuur …...Een Project Start Architectuur Omgevingsvergunning voor het...

Documents

Transcript of Een Project Start Architectuur …...Een Project Start Architectuur Omgevingsvergunning voor het...