Definitiestudierapport Handhaving Vergunningverlening Internet Klantcontact

Definitiestudierapport Handhaving Vergunningverlening Internet Klantcontact

Versie 1.0 27 februari 2009

1

Definitiestudierapport Handhaving Vergunningverlening

........................................................................................

Colofon Uitgegeven door: Ministerie van Verkeer en Waterstaat Rijkswaterstaat Waterdienst en Data-ICT-Dienst Michiel Engelsman/Paul Bielen Informatie: Telefoon: 06 51 399 710/06 51 892 646 Fax: 0320- 24 92 18 Uitgevoerd door:

DID: James van Gemeren Thijs Muizelaar Edward Nuiten

Opmaak:

Rijkswaterstaat Waterdienst

Datum:

februari 2009

Nummer

WD2009.006

Bijlagen

WD2009.006 WD2009.006 WD2009.006 WD2009.006 WD2009.006 WD2009.006 WD2009.006

2

-1 -2 -3 -4 -5 -6 -7

Uittreksel voor niet ICT’ers Kosten Baten analyse Project start architectuur Programmavoorstel Planning Risico-inventarisatie Overzicht informanten


Inhoudsopgave

............................................. 0

METAGEGEVENS ................................................................................ 7 0.1 0.2 0.3 0.4

1

OPDRACHTGEVER EN STAKEHOLDERS ............................................... 7 DOCUMENTEIGENSCHAPPEN .............................................................. 7 AUTEURS ........................................................................................... 7 LEESWIJZER ....................................................................................... 7

MANAGEMENTSAMENVATTING .................................................... 9 1.1 AANLEIDING ...................................................................................... 9 1.2 HAVIK 2 IN DE OMGEVING ................................................................. 9 1.3 SCOPE .............................................................................................. 11 1.4 UITGEVOERDE ANALYSE .................................................................. 12 1.4.1 Processen ................................................................................ 12 1.4.2 ICT-landschap......................................................................... 12 1.4.3 Informatie/Gegevens ............................................................... 13 1.4.4 Conclusie van de analyse ........................................................ 13 1.5 AANBEVOLEN ICT-OPLOSSINGSRICHTING ....................................... 13 1.5.1 Mobiel werken......................................................................... 14 1.5.2 Kennistool ............................................................................... 14 1.6 VISIE OP DE OPLOSSING ................................................................... 15

2

INLEIDING .......................................................................................... 17 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10

3

AANLEIDING .................................................................................... 17 DOELSTELLING VAN DE DEFINITIESTUDIE ........................................ 18 RESULTAAT ..................................................................................... 18 DOELGROEP ..................................................................................... 18 TOTSTANDKOMING .......................................................................... 19 UITGANGSPUNTEN ........................................................................... 19 CRITERIA VOOR BEPALEN OPLOSSINGSRICHTING ............................. 20 RAAKVLAKKEN MET ANDER PROJECTEN .......................................... 21 ACHTERGROND VAN HET PROJECT HAVIK 2..................................... 21 AANSLUITING OP OVERHEIDSONTWIKKELINGEN .......................... 22

POSITIONERING HAVIK 2 .............................................................. 23 3.1 OVERHEIDSBREDE ONTWIKKELINGEN .............................................. 23 3.1.1 Administratieve lastenverlichting (NUP) ................................ 23 3.1.2 NOiV ....................................................................................... 25 3.1.3 Kaderstellende visie op toezicht (2005) .................................. 28 3.1.4 Programma Vernieuwing Toezicht.......................................... 29 3.1.5 Waterwet ................................................................................. 30 3.1.6 Digitaal loket voor Waterwet .................................................. 32 3.1.7 Wet Dwangsom en beroep bij niet-tijdig beslissen ................. 35 3.1.8 Archiefwet 1995 ...................................................................... 36 3.1.9 Binnenvaartwet ....................................................................... 36 3.1.10 Basisregistratie ....................................................................... 37 3.1.11 Nederlandse Overheid Referentie Architectuur ...................... 39 3.2 RIJKSWATERSTAAT BREDE ONTWIKKELINGEN ................................. 41

3


3.2.1 Agenda 2012 ........................................................................... 41 3.2.2 Enterprise Architectuur Rijkswaterstaat................................. 42 3.2.3 Kwaliteitsmanagement ............................................................ 43 3.2.4 WilWat .................................................................................... 43 3.2.5 Overige projecten.................................................................... 45 3.3 AFBAKENING HAVIK 2..................................................................... 47 3.4 CONTEXTDIAGRAM .......................................................................... 49 4

GLOBALE PROCESINVENTARISATIE IST .................................. 52 4.1 INLEIDING ....................................................................................... 52 4.2 PROCESNIVEAU EN PROCESTYPE ...................................................... 52 4.3 AFWIJKING VAN UPP....................................................................... 54 4.4 HUIDIGE PROCESSEN (IST) .............................................................. 55 4.4.1 Verlenen van een vergunning.................................................. 55 4.4.2 Behandelen van meldingen AmvB ........................................... 58 4.4.3 Handhaven .............................................................................. 59 4.4.4 Plannen, sturen en rapporteren .............................................. 62 4.5 BEVINDINGEN HUIDIGE PROCESSEN ................................................. 63

5

GLOBAAL PROCESONTWERP SOLL............................................ 67 5.1 INLEIDING ....................................................................................... 67 5.2 GEBRUIKERSINVENTARISATIE ......................................................... 68 5.3 AANSLUITEN OP E-OVERHEID .......................................................... 69 5.4 CONFORMEREN AAN DE ENTERPRISE ARCHITECTUUR RIJKSWATERSTAAT ..................................................................................... 70 5.5 GENERIEK PROCESMODEL E-DIENSTVERLENING HAVIK 2 ................ 70

6

GEGEVENSMANAGEMENT ............................................................ 74 6.1

HUIDIGE GEGEVENSHUISHOUDING VERGUNNINGVERLENING EN

HANDHAVING ..............................................................................................

74 EISEN VANUIT ARCHITECTUURPRINCIPES ......................................... 76 STANDAARDEN EN OMGEVING ........................................................ 77 OBJECTMODELLEN .......................................................................... 77 EISEN AAN DE GEGEVENSHUISHOUDING T.B.V. HANDHAVING ......... 78 EISEN AAN DE GEGEVENSHUISHOUDING T.B.V. VERGUNNINGVERLENING ............................................................................ 80 6.7 PLANNING, MANAGEMENT INFO, BESTURING .................................. 81 6.8 CONCLUSIES .................................................................................... 82 6.2 6.3 6.4 6.5 6.6

7

APPLICATIE SCHETS ....................................................................... 84 7.1 INLEIDING ....................................................................................... 84 7.2 FRONTOFFICE, MIDOFFICE, BACKOFFICE ......................................... 85 7.2.1 Frontoffice .............................................................................. 85 7.2.2 Backoffice................................................................................ 85 7.2.3 Midoffice ................................................................................. 85 7.3 HUIDIGE INFORMATIEVOORZIENING HH & VV ............................... 86 7.3.1 Huidig landschap van de informatievoorziening .................... 86 7.3.2 Huidige functionaliteiten ........................................................ 88 7.3.3 Gebruik van huidige applicaties ............................................. 89 7.4 MOGELIJK TOEKOMSTIG ICT-LANDSCHAP ....................................... 90 7.4.1 Algemene uitgangspunten ....................................................... 90 7.4.2 Toekomstig frontoffice ............................................................ 91

4


7.4.3 Toekomstig midoffice .............................................................. 92 7.4.4 Toekomstig backoffice............................................................. 92 7.4.5 Vier alternatieve oplossingsrichtingen ................................... 93 7.5 PROGRAMMA VAN EISEN ................................................................. 93 7.5.1 Gebruikerseisen en wensen ..................................................... 94 7.5.2 Eisen van Enterprise architectuur .......................................... 97 7.5.3 Architectuurprincipes NORA .................................................. 98 7.6 KOPPELVLAK ................................................................................. 100 7.7 MOBIEL WERKEN. .......................................................................... 101 7.7.1 MDA ...................................................................................... 101 7.7.2 Gebruikerseisen en wensen tav Mobiel werken .................... 102 7.7.3 Advies MDA .......................................................................... 103 7.8 KENNISTOOL ................................................................................. 104 7.8.1 Functionaliteiten kennistool.................................................. 104 7.9 CONCLUSIES KENNISTOOL ............................................................ 105 8

ICT-OPLOSSINGSRICHTINGEN................................................... 107 8.1 HUIDIGE SITUATIE INFORMATIEVOORZIENING ............................... 108 8.2 OPLOSSINGSRICHTING 1: CONSOLIDATIE HUIDIGE SYSTEMEN ....... 110 8.2.1 Maatregelen voor vergunningverlening ................................ 111 8.2.2 Maatregelen voor Handhaven............................................... 112 8.2.3 Beoordeling optie 1............................................................... 113 8.3 OPLOSSINGSRICHTING 2: SAP HAVIK + CRM EN DATAWAREHOUSE OPLOSSING ................................................................................................ 114 8.3.1 Maatregelen voor vergunningverlening ................................ 115 8.3.2 Maatregelen voor handhaven................................................ 117 8.3.3 Beoordeling optie 2............................................................... 118 8.4 OPLOSSINGSRICHTING 3: VERGUNNINGPAKKET, CRM-PAKKET EN DATAWAREHOUSE VOOR HH .................................................................... 120 8.4.1 Maatregelen voor vergunningverlening ................................ 121 8.4.2 Maatregelen voor handhaven................................................ 121 8.4.3 Beoordeling optie 3............................................................... 122 8.5 OPLOSSINGSRICHTING 4: SERVICE GEORIËNTEERDE ARCHITECTUUR 123 8.5.1 Beoordeling optie 4............................................................... 125 8.6 HERBRUIKBARE COMPONENTEN .................................................... 126 8.7 VERGELIJKING OPLOSSINGSRICHTINGEN ....................................... 129 8.8 CONCLUSIES .................................................................................. 129 8.9 OPEN SOURCE OPTIES .................................................................... 131

9

STAPPENPLAN ................................................................................. 132 9.1 INTEGRALE BENADERING VAN HET VERANDERINGSPROCES ........... 132 9.2 PROJECTENPLAN ............................................................................ 134 9.2.1 Organisatie ........................................................................... 134 9.2.2 Informatie.............................................................................. 135 9.2.3 ICT (projecten)...................................................................... 136 9.3 VISIE OP DE OPLOSSING ................................................................. 139 9.3.1 Papier op orde ...................................................................... 140 9.3.2 Van papier op naar digitaal.................................................. 140 9.3.3 Proces op orde ...................................................................... 141 9.3.4 Proces digitaal ...................................................................... 141 9.3.5 Informatie op orde ................................................................ 142

5


9.4 TRANSITIEDIAGRAM ...................................................................... 142 9.5 TRANSITIE VAN PROCEDUREEL NAAR GEAUTOMATISEERD MIDOFFICE T.B.V . DE WATERWET ............................................................................... 143 10 10.1 10.2 10.3 10.4 11 11.1 11.2 11.3 12 12.1 12.2 12.3 12.4 12.5 12.6 12.7 12.8 12.9 13 13.1 13.2 13.3 13.4 13.5 14 14.1 14.2 14.3 14.4 14.5 14.6

BEHEER ......................................................................................... 148 INLEIDING .................................................................................. 148 UITWERKING PER OPLOSSINGSRICHTING .................................... 148 MOBIEL WERKEN ....................................................................... 155 KENNISTOOL .............................................................................. 156 BEVEILIGING ............................................................................... 157 CLASSIFICATIEMODEL ............................................................... 157 RISICOCLASSIFICATIE ................................................................ 158 IMPACT BEVEILIGINGSMAATREGELEN ........................................ 159 IMPACT/ COPAFIJTH BINNEN DE RWS-ORGANISATIE.... 160 COMMUNICATIE ......................................................................... 160 ORGANISATIE ............................................................................ 160 PERSONEEL ................................................................................ 161 ADMINISTRATIEF ....................................................................... 161 FINANCIEEL ............................................................................... 162 INFORMATIE .............................................................................. 162 JURIDISCH .................................................................................. 162 TECHNIEK .................................................................................. 162 HUISVESTING ............................................................................. 163 OPENSTAANDE PUNTEN ........................................................... 164 HEFFINGEN ................................................................................ 164 BINNENVAARTWET .................................................................... 165 RELATIE MET IVW .................................................................... 165 PROCESSEN EN DIEPGANG .......................................................... 165 NAUTISCHE EN DROGE VERKEERSWETGEVING ........................... 166 BIJLAGEN...................................................................................... 167 DE TWINTIG NORA PRINCIPES................................................... 167 TOELICHTING OMGEVINGSDIAGRAM .......................................... 168 DEFINITIES PROCESNIVEAU ........................................................ 170 SYSTEEMFUNCTIONALITEITEN ................................................... 171 INGEVULDE VRAGENLIJSTEN RISICOCLASSIFICATIE ................... 172 OBJECTMODEL BESCHRIJVINGEN ............................................... 176

...........................................

6


0 Metagegevens 0.1 Opdrachtgever en stakeholders Opdrachtgever: Opdrachtnemer:

Luitzen Bijlsma (HID WD) Paul Bielen (WD) Michiel Engelsman (DID)

0.2 Documenteigenschappen Revisiedatum

Voorgaande revisie datum

Omschrijving wijziging Concept 01 Concept 03 Concept 05c, toevoegen H2, wijzigingen in H4 H6 t/m8 opgezet

09-01-2009 19-01-2009 20-01-2009

16-01-2009 19-01-2009

09-02-2009

20-01-2009

Concept 07 H2 t/m H8 aangevuld, H9 t/m H13 eerste opzet

13-02-2009

09-01-2009

20-02-2009

13-02-2009

27-02-2009

20-02-2009

Concept 09 commentaar van CBI verwerkt, reactie van Concept 0.95 commentaar toetsingscie Verwerking laatste aanvulling

Auteur Edward Nuiten Thijs Muizelaar Michiel Engelsman, James van Gemeren, Edward Nuiten & Thijs Muizelaar Michiel Engelsman, James van Gemeren, Edward Nuiten & Thijs Muizelaar Edward Nuiten, Thijs Muizelaar

Edward Nuiten Thijs Muizelaar Edward Nuiten Thijs Muizelaar

0.3 Auteurs Edward Nuiten (Projectarchitect) Thijs Muizelaar (Informatie-analist) James van Gemeren (Informatie-analist)

0.4 Leeswijzer Een definitiestudie is een fase in een systeemontwikkelingsproject. Vandaar dat bepaalde onderdelen van dit rapport uitgaan van bepaalde kennis op het gebied van systeemontwikkeling. Binnen

7


Rijkswaterstaat is geen template voorhanden om een definitiestudierapportage op te zetten, vandaar dat in het project Havik 2 zelf een opzet is gemaakt. Voor de lezer die werkzaam is in de business is het wellicht zinvol om bij het lezen te focussen op de hoofdstukken die onderwerpen behandelen die minder ICT-gerelateerd zijn. We hebben wel als auteurs geprobeerd het ICT-jargon zoveel mogelijk te vermijden om de leesbaarheid van het rapport te vergroten. In de management samenvatting wordt de essentie van Havik 2 samengevat. Hoofdstuk 2 geeft de aanleiding en inhoud van het project Havik 2 weer. In hoofdstuk 3 wordt uitgebreid ingegaan op de omgeving van Rijkswaterstaat omdat er relevante ontwikkelingen zijn die een andere benadering vragen dan bij het project SAP Havik en het project Digitale Handhaving. Hoofdstuk 4 beschrijft de huidige processen en hoofdstuk 5 geeft de beschrijving van de processen zoals deze door de gebruikersorganisatie, wetgeving en externe ontwikkelingen vormgegeven kunnen worden. Gegevens vormen het bloed door de aderen van een organisatie, vandaar dat hier met zorg mee omgegaan moet worden. Hoofdstuk 6 brengt daarvoor een aantal bevindingen aan de oppervlakte en adviseert over de verbeterde inrichting. Het objectmodel geeft een afbakening van de ‘onderwerpen van gesprek’ binnen het Havik 2 aandachtsgebied. Hoofdstuk 7 geeft een functionele beschrijving van het ICT-landschap in de huidige en gewenste situatie. Hoofdstuk 8 gaat dieper in op verschillende ICT-oplossingsrichtingen. Voor de gebruikersorganisatie is het minder relevant, als de ICT-voorzieningen maar voldoen aan de functionele beschrijvingen van hoofdstuk 7. De opdrachtgever zal echter de keuze moeten maken uit de genoemde oplossingsrichtingen. Hoofdstuk 9 behandelt de stappen die gezet moeten worden om een ideale inrichting te kunnen realiseren. Hierin zit ook de visie van het projectteam op de oplossing. Een concreet advies wordt in een seperate adviesnota uitgewerkt en aan de opdrachtgever aangeboden. Hoofdstuk 10 geeft de consequenties van het beheer per oplossingsrichting weer. Hoofdstuk 11 behandelt de risico’s. Hoofdstuk 12 beschrijft de consequenties voor de Rijkswaterstaat-organisatie als de functionaliteiten zijn gerealiseerd, zoals in hoofdstuk 7 zijn beschreven. Dit wordt beschreven per bedrijfsaspect (COPAFIJTH). Havik 2 heeft een erg breed aandachtsgebied. In hoofdstuk 13 is een aantal onderwerpen benoemd, die nog verdieping of nader onderzoek vereisen. In hoofdstuk 14 zitten de bijlagen.

8


1 Managementsamenvatting 1.1 Aanleiding Rijkswaterstaat heeft een belangrijke taak in het verlenen van vergunningen en het toezicht en de handhaving in dat kader. Dit werkveld is volop in beweging. In 2007 heeft een verkenning uitgewezen dat de ICT ondersteuning van de handhaving en vergunningverlening modernisering behoeft. Gebruikers zijn ontevreden over de ondersteuning, vandaar veel eigen oplossingen. Hierdoor ontbreekt het bij de handhavers aan een eenvoudige ontsluiting van de benodigde informatie. Versnipperde en onvolledige informatie maakt dat Rijkswaterstaat ten aanzien van de vergunningverlening en handhaving niet in control is. Nieuwe wetgeving, waaronder de Waterwet en de Binnenvaartwet en het verplicht gebruik van landelijke registers, is in aantocht en leidt tot taakverschuiving. Om de ondersteuning voor het werkveld op orde te brengen is het project Handhaving Vergunningverlening, Internet Klantcontact (Havik) 2 in september 2008 gestart. Opdrachtgever is de HID van de Waterdienst, Luitzen Bijlsma. 1.2 Doelstelling en resultaat Het project Havik 2 heeft tot doel een integrale ondersteuning met één gebruikersvriendelijke ICT voorziening voor alle wetten en het hele proces van handhaving en vergunningverlening te realiseren en te implementeren. De onderhavige definitiestudie geeft inzicht in het totale landschap van systemen, processen en gegevens rondom handhaving en vergunningverlening. Het project heeft in het werkveld een groot aantal gesprekken gevoerd, een aantal workshops met gebruikers, teamleiders, en beheerders uitgevoerd en de beelden hieruit getoetst bij ICT-architecten. Samen met de informatie over de omgeving van Havik, is op hoofdlijnen een totaal beeld verkregen van deze omgeving, de processen, de gegevens en het ICT landschap. Daarnaast heeft een benchmark plaatsgevonden, in de vorm van een deskstudy naar mogelijke oplossingen voor mobiel werken en een kennistool. Er is door het projectteam gekozen, binnen de beschikbare tijd, tot een zodanige uitwerking te komen, dat een verantwoord besluit over het vervolg kan worden genomen.Het advies bevat een voorkeursalternatief op basis van een viertal oplossingsrichtingen. De definitiestudie schetst het concept van de ICT-voorzieningen in functionele (gebruikers) termen. De beoordelingscriteria zijn samen met de gebruikers vastgesteld.

1.2 Havik 2 in de omgeving Het werkveld van handhaving en vergunningverlening bij Rijkswaterstaat kan niet meer los worden gezien van de omgeving.

9


Zowel extern vanuit de (Rijks)overheid als binnen de eigen organisatie vinden ontwikkelingen plaats die invloed hebben op Havik 2. • Dienstverlening Er zijn vele programma’s binnen de Rijksoverheid gericht op de professionalisering van de dienstverlening richting burger en bedrijfsleven. Havik 2 loopt daar namens RWS voorop. Het uitgangspunt bij de dienstverlening is een (administratieve) lastenverlichting, De overheid heeft in het Nationaal Uitvoerings Programma dienstverlening en e-overheid (NUP zowel wettelijke als organisatorische en procesmatige veranderingen aangekondigd. De Rijksoverheid onderkent de belangrijke rol voor ICT in: o de NORA (Nederlandse Overheid Referentie Architectuur) waarin principes worden vastgelegd over de wijze waarop wordt samengewerkt en informatie wordt uitgewisseld tussen overheden en, o het programma NoiV (Nederland Open in Verbinding) over Open Source Software en Open Standaarden. •

•

10

Professionalisering toezicht De tweede kaderstellende visie op toezicht geeft een invulling aan de verbetering van de dienstverlening. Hierin wordt een verandering beoogd van object toezicht naar systeemtoezicht, waarbij het geheel van processen, systemen en organisatie bij een bedrijf of branche wordt bekeken. Systeemtoezicht moet leiden tot minder bedrijfsbezoeken.Deze visie heeft geresulteerd tot o.a. twee programma’s: • Vernieuwing toezicht: burger en bedrijfsleven hebben te maken hebben met één aanspreekpunt waarbij het lijkt alsof er één rijkstoezichthouder is. • E-Inspecties: ICT ondersteuning van het programma Vernieuwing Toezicht. Er zijn acht generieke voorzieningen gedefinieerd, waaronder een Digitaal Dossier en Front Office website. Het Front Office Vervoer over Water is hier een voorbeeld van. Wetgeving De professionalisering van de dienstverlening resulteert ook in een aantal relevante wijzigingen en vernieuwingen in wetgeving. o Samenvoegen en harmoniseren van wetgeving: de Binnenvaartwet en de Waterwet voegen bestaande wetten samen, waardoor vergunningverlening, toezicht en handhaving voor de binnenvaart en het waterbeheer beter is geregeld. De Waterwet introduceert ook, vergelijkbaar met de Wet Algemene Bepalingen Omgevingsrecht (WABO), een digitaal loket (de Landelijke Voorziening Omgevingsloket of LVO). o Bij wet wordt ook geregeld dat de overheid gegevens moet hergebruiken. De basisregistraties zijn door de overheid benoemt als de authentieke bron voor bijvoorbeeld persoons- of bedrijfsgegevens. o De Wet Dwangsom en beroep bij niet-tijdig beslissen , waarmee de overheid wordt gedwongen binnen


afgesproken termijnen te werken behoort ook de wettelijke kant van de professionalisering. Rijkswaterstaat Agenda 2012 Binnen Rijkswaterstaat zijn vele projecten die invulling geven aan de Agenda 2012. In de Agenda 2012 zijn voor Rijkswaterstaat vijf pijlers en een gewaagd doel geformuleerd. Een van die pijlers is dat Rijkswaterstaat als publieksgerichte netwerkmanager moet opereren. Het werkveld van handhaving en vergunningverlening is bij uitstek een publieksgerichte taak, waarmee door Havik 2 invulling wordt gegeven aan deze pijler. Architectuur Bij het in de praktijk brengen van de Agenda 2012 speelt de architectuur binnen RWS een belangrijke rol. Deze architectuur zou richting moeten geven aan de processen, en hun gewenste informatievoorziening. De bestaande Enterprise Architectuur biedt op veel van de nieuwe ontwikkelingen nog geen concrete kaders, omdat Havik 2 voorop loopt op een aantal aspecten.

•

•

1.3 Scope Havik 2 zal oplossingen bieden voor aspecten in: 1. frontoffice: voor niet Waterwetvergunningen zal RWS een frontoffice (webportal) inrichten. Voor de Watervergunningen doet de LVO dat. 2. midoffice: voor het behandelen van verschillende zaaktypen (vergunningaanvragen, meldingen etc); 3. backoffice: waarin de gegevenshuishouding over vergunningen, risico’s en planningen worden opgeslagen en de koppeling met de basisregistraties wordt geregeld. E lektronis c he overheid op termijn onderlinge gegevens uitwis s eling binnen de e‐overheid

D igiD (e)‐NIK /P K I

B edrijven

O V E R HE ID S P O R T AL / O R G ANIS AT IE P O R T AL verwijzer (links )

BS N

Noord‐NL

Basisregistraties T O P ‐kaart

O os t‐NL

gebouwen

informatie e‐formulier

LVO

Noord‐ B rabant

pers onen

IJ s s elm.gebie d

adres s en

zoekmachine

burger

vragenboom

aanvraagmodule

B IN bedrijf

Havik 2

behandeldos s ier attenderings s ervice

. . . . D igiD PKI

L imburg

K adas ter

Noord‐ Holland

inkomens S chepen

Waterdiens t

O verheids trans actie poort

auto's O verige

koppeling aan gemeens chappelijk front office

etc. s ervicebus (s en)

Figuur 1 Scope van Havik 2

11


1.4 Uitgevoerde analyse 1.4.1 Processen Het werkveld van vergunningverlening in handhaving bevat globaal vier processen: • verlenen van een vergunning; • behandelen van een melding AMvB; • toezicht houden en handhaven, en • plannen, sturen en rapporteren. Het verlenen van een vergunning en het behandelen van een melding AMvB zijn op elkaar lijkende processen, evenals het afhandelen van beroep, bezwaar of (bestuurlijke) sancties zoals bestuursdwang. De Algemene Wet Bestuursrecht is hier leidend. Voor het proces toezicht houden en handhaven is het eindproduct (een vergunning of geregistreerde melding) van belang. Overkoepelend aan de andere processen is het plannen, sturen en rapporteren. De plannen worden gebaseerd op risico analyses in verband met het systeemtoezicht. Hierbij is een belangrijke koppeling met de informatie uit de drie andere processen. In deze processen ontstaat de informatie waarop wordt gepland, gestuurd en gerapporteerd. Belangrijke conclusies bij de analyse van de processen zijn: 1. dat de alignment (de mate waarin systeemfunctionaliteiten aansluiten bij de behoefte van de processen onvoldoende is; 2. Praktijk processen wijken af van de beschrijvingen processen(UPP) en dat er niet wordt toegezien op een correct uitvoering. 3. Slechte en verschillende processen per regio leiden tot onvoldoende accurate administraties, waardoor de toegankelijkheid en kwaliteit van de gegevens ernstig bemoeilijkt wordt. 4. UPP sluit niet aan bij nieuwe wetgeving. 5. Het ontbreekt aan gemeenschappelijke visie op dienstverlening rondom vergunningverlening. Op basis van bovenstaande bevindingen zijn functionele eisen gedefinieerd en vertaald in ICT-oplossingen. 1.4.2 ICT-landschap In het werkveld van handhaving en vergunningverlening bestaat een grote diversiteit aan applicaties die worden gebruikt. Drie belangrijke applicaties die worden gebruikt zijn WVO-info, SAP Havik en WIS. Deze applicaties ondersteunen grote delen van de vergunningen en meldingen waar Rijkswaterstaat bevoegd gezag is, maar niet alle. Naast deze applicaties worden tijdens de inhoudelijke beoordeling van verzoeken specifieke applicaties gebruikt, die onderling niet gekoppeld zijn. Het gebruik van de applicaties laat te wensen over. De gebruikersvriendelijkheid van de applicaties sluit onvoldoende aan aan de vaardigheden van de medewerkers. Daarnaast is de mogelijkheid om mobiel te werken niet of slecht ingevuld. Daarnaast is de wijze waarop het beheer van een aantal systemen is georganiseerd omslachtig.

12


1.4.3 Informatie/Gegevens Het belangrijkste verbindende element tussen de processen is de informatieuitwisseling. De vergunningverlening zorgt dat een beschikking wordt afgegeven, terwijl men bij toezicht en handhaving naziet op een correcte uitvoering volgens de geldende voorschriften die in deze beschikking zijn vastgelegd. Bij plannen, sturen en rapporteren heeft men dezelfde informatie nodig. In de huidige situatie zijn er echter meerdere administraties in verschillende informatiesystemen en archiefkasten, die per regio verschillend worden beheerd en gevuld. Bij RWS ontbreekt een beleid voor gegevensmanagement. De koppeling met landelijke basisregistraties, het uitwisselen van informatie in het kader van landelijke en internationale verdragen leidt tot toename van gegevensgebruik. Dat kan onmogelijk decentraal georganiseerd blijven, hiervoor zal op enterprise niveau beleid moeten worden ontwikkeld. De definitiestudie heeft voor Havik 2 een oplossing geschetst. 1.4.4 Conclusie van de analyse Havik 2 is niet alleen ICT, maar betreft ook organisatie, processen en informatie, derhalve heeft Havik 2 de volgende verbeterdoelstellingen: 1. oplossen van het alignment vraagstuk: visie ontwikkeling over organisatie, processen, informatie en ICT m.b.t. vergunningverlening en handhaving; 2. betere aansluiting op beleidsmatige en wettelijke ontwikkelingen; 3. flexibelere ICT-voorzieningen die aansluit bij de behoeften van de gebruikersorganisatie, management en beheerorganisatie; 4. verbeterde voorziening voor mobiel werken en kennisontsluiting; 5. betere informatie verstrekking aan derden. Om de doelstellingen te realiseren is een meerjaren programma noodzakelijk.

1.5 Aanbevolen ICT-oplossingsrichting Op basis van de analyse heeft de definitiestudie vier oplossingsrichtingen opgeleverd: 1. Behouden van bestaande systemen met lichte aanpassingen om te voldoen aan de wet (nuloptie); 2. Verbetering en uitbouw SAP Havik, gegevensmagazijn, klantbezoekregistratie en maatwerk-functionaliteiten; 3. Combinatie van Vergunningverleningpakket, Datawarehouse, klantbezoekregistratie en maatwerkfunctionaliteiten; 4. Service georiënteerde architectuur. De vier oplossingsrichtingen zijn opgebouwd uit verschillende functionele componenten. De gevraagde functionele componenten zijn in Figuur 2 weergegeven en zijn per oplossingsrichting in verschillende applicaties of meerdere gelijkwaardig applicaties ondergebracht. De functionele componenten

13


zijn van toepassing op zowel handhaving als vergunningverlening.De gebruikersinterface wordt specifiek gemaakt voor de afzonderlijke processen. ECM

Identificatie/ authenticatie

Inkomend bericht

Elektronische formulieren

Gebruikers interface vergunningverlening Elektronisch Dossier (zaken)

Gebruikers interface handhaving

Specialistische automatisering

Elektronische beschikkingen

Kennistool

Werkstroombesturing

DWH

LVO Document management Scanstraat Financieel systeem

Rapportage Tool (management Informatie)

Printen / document genereren

Uitgaand bericht

Website voor niet WW

Koppelingen / connectiviteit Kantoorautomatisering

Archivering

Figuur 2 Functionele componenten Oplossingsrichting 3 heeft de voorkeur. In een vervolgfase wordt het programma van eisen uit de definitiestudie (na definitieve keuze) concreter uitgewerkt, om zekerheid te kunnen geven dat de genoemde doelstellingen kunnen worden gerealiseerd. Deze aanbeveling voor deze oplossingsrichting is financieel onderbouwd in de Kosten/Baten analyse. 1.5.1 Mobiel werken Er is vanuit de gebruikersorganisatie een sterke wens geuit, om over mobiele toepassingen te kunnen beschikken. De functionele wensen bij gebruikers zijn echter niet generiek en verschillen sterk per discipline. De invoering van een geavanceerde Mobile Digital Assistant (MDA), waarmee op locatie inspectieresultaten kunnen worden gerapporteerd en informatie worden opgevraagd, is op dit moment een brug te ver voor Rijkswaterstaat. Een slimme keuze van de thans reeds beschikbare hardware (draagbare werkplek en UMTS) in combinatie met de Blackberry (agenda, e-mail, foto en navigatie) levert echter op korte termijn flinke meerwaarde voor een grote groep toezichthouders en handhavers. De baten van geavanceerde oplossingen zoals een tablet, zijn mede afhankelijk van de mate waarin Rijkswaterstaat de digitalisering en automatisering van het werkveld wil doorzetten. De keuze voor een geavanceerde oplossing (in combinatie met de hierna te behandelen kennistool) mist op dit punt de vereiste onderbouwing. 1.5.2 Kennistool Onderdeel van de ondersteuning van het werkveld van handhaving en vergunningverlening is het ontsluiten van kennis. Naar aanleiding van diverse gesprekken met handhavers blijkt dan men vooral de wens heeft om weten regelgeving in het veld te kunnen raadplegen Tijdswinst valt vooral te behalen wanneer men voor de situatie

14


specifieke, bijbehorende weten regelgeving kan raadplegen. In de markt wordt deze functionaliteit als dynamische checklisten aangeprijsd. De functionaliteit van checklisten heeft daarnaast alleen toegevoegde waarde als deze wordt gekoppeld aan kwaliteitsmanagement. Kwaliteitsmanagement bepaalt in welk proces een specifieke checklist nodig is. Er is een inventarisatie gemaakt van verschillende applicaties op dit vlak. Vanwege de afhankelijkheid met de gekozen oplossingsrichting wordt geadviseerd om een keuze voor een kennistool hier op te baseren. Tijdelijke oplossingen zoals doorlinken naar website met wetgeving kan wel worden gerealiseerd in een portal.

1.6 Visie op de oplossing De visie op het uiteindelijke “eindplaatje” is tot nu toe bepaald door de gebruiker en wetgeving. Het Rijkswaterstaat management (business én ICT) zal bij het nemen van een beslissing over het vervolgtraject van Havik 2 beleidskeuzes moeten maken. Het aandachtsgebied van Havik 2 gaat over de verschillende domeinen en diensten heen en heeft daarmee een corporate karakter. Ook het beleid over toepassing van landelijke basisregistraties en Rijkswaterstaatbrede kernregistraties in de bedrijfsprocessen en administraties is een Rijkswaterstaatbreed vraagstuk. Havik 2 adviseert dan ook voor het vervolgtraject een integrale benadering. Zowel het aspect organisatie (personeel, rollen, verantwoordelijkheden) én bedrijfs- en ondersteunende processen, informatie (gegevensarchitectuur, gegevensdefinities, administraties, standaarden) moeten op elkaar worden afgestemd en op de invulling en het gebruik van ICT voorzieningen. Vervolgens zal ook op het gebied van ICT (applicatielandschap, Service oriëntatie, uitbesteding, Open Source Software, Open Standaarden) beleid moeten worden ontwikkeld en zullen project gestart moeten worden. Hiervoor wordt dan ook een groeimodel voorzien voor Havik 2. Het groeimodel bestaat uit een aantal ontwikkelingsstadia (zie Figuur 30): 1. papier op orde 2. van papier naar digitaal 3. het proces op orde 4. het proces digitaal 5. informatie op orde

15


Het groeimodel voor Vergunningverlening en Handhaving

“Streefbeeld Havik 2” en uw ie n r Ve

r Ve

te be

Proces digitaal

n re

Proces op orde

Volwassenheid

Informatie op orde

n de re rb e V

Papier digitaal Papier op orde

Tijd/ inspanning

Figuur 3 Groeimodel voor Vergunningverlening en Handhaving Havik 2 adviseert ook om een Rijkswaterstaatbrede visie te ontwikkelen op vergunningverlening en handhaving waarin gekeken wordt naar de uitvoering van de wettelijke taken, met behulp van de markt en automatisering, waarbij een efficiënte en effectieve invulling wordt gegeven aan de processen. Ook het eigenaarschap van de processen, gegevens en applicaties moeten in deze visie belegd worden. In de separate adviesnota Havik 2 wordt in detail de transitie uitgewerkt.

16


2 Inleiding 2.1 Aanleiding De geautomatiseerde ondersteuning van het werkveld handhaving en vergunningverlening bij Rijkswaterstaat is aan herziening toe. Het is sterk versnipperd, sommige activiteiten worden niet door landelijk systemen ondersteund, andere juist door meerdere (soms verouderde) systemen met gelijke functionaliteit. De bestaande systemen zijn veelal niet onderling gekoppeld, waardoor gegevens niet hergebruikt kunnen worden en gegevensvervuiling ontstaat. Het werken met deze diversiteit aan systemen is tijdrovend en foutgevoelig. Als binnenkort nieuwe wetgeving in werking treedt en Rijkswaterstaat ook gaat aansluiten op het digitale overheidsloket, kan deze situatie niet meer blijven bestaan. Op korte termijn is nieuwe wetgeving voorzien op het gebied van Binnenvaart en de nieuwe Waterwet. Beide wetten hebben gevolgen voor de handhavende en vergunningverlenende processen van Rijkswaterstaat. Om hiervoor een oplossing te realiseren is het project Handhaving Vergunningverlening, Internet Klantcontact (Havik) 2 in september 2008 in opdracht van Luitzen Bijlsma, HID van de Waterdienst, gestart. Het project HAVIK 2 heeft tot doel een integrale ondersteuning met één gebruikersvriendelijke ICT voorziening voor alle wetten en het hele proces van handhaving en vergunningverlening te realiseren en te implementeren. Het eindresultaat bestaat uit: • een gefaseerde oplevering en ingebruikname van de integrale ICT voorziening voor vergunningverlening en handhaving; • inrichting van de ICT voorziening op zodanige wijze dat de relevante wetgeving (nat en droog) wordt ondersteunt; • invulling van de ICT voorziening op zodanige wijze dat wordt voldaan aan randvoorwaardelijke wetgeving (o.a. Wet Bescherming Persoonsgegevens, Archiefwet en Wet Dwangsom); • geüniformeerde werkprocessen waarvoor de ICT voorziening is ingericht; • opgeschoonde gegevenshuishouding en migratie van gegevens naar de nieuwe ICT voorziening; • aansluiting van de ICT voorziening op de relevante portalen (o.a. LVO Water en Frontoffice Binnenvaart); • aansluiting van de ICT voorziening op de relevante basisregistraties (o.a. GBA en NHR); • het uitfaseren van verouderde ICT toepassingen voor vergunningverlening en handhaving; • realisatie en in gebruik nemen functionaliteit voor mobiel werken en kennisontsluiting; • ingeregeld en vastgelegd beheer van de nieuwe ICT voorziening; • in het gebruik van de ICT voorziening geïnstrueerde medewerkers.

17


De definitiestudie vormt de eerste fase van het project Havik 2.

2.2 Doelstelling van de definitiestudie De definitiestudie heeft tot doel inzage te geven in het totale landschap van systemen en processen rondom handhaving en vergunningverlening. Het verkregen inzicht dient te leiden tot een onderbouwd advies voor een geschikte oplossingsrichting en een groeipad voor de komende jaren voor het gefaseerd toewerken naar het beoogde eindresultaat van het project Havik 2.

2.3 Resultaat De • • • • • • • • • • • • • • • • • • • • • •

definitiestudie levert als resultaat antwoord op de vragen: hoe ziet het systeemconcept er in functionele termen uit? welke inhoud krijgt het nieuwe systeem? welke wetten en processen worden ondersteund? wat zijn de grenzen van het nieuwe systeem? aan welke eisen dient het systeem te voldoen? wat zijn de prioriteiten in deze eisen? welke delen/componenten zijn te onderscheiden? wat zijn de prioriteiten in de realisatie van de delen/componenten? welke bestaande bouwstenen/oplossingen zijn te hergebruiken? welke bestaande applicaties kunnen worden geconsolideerd? met welke technische en organisatorische randvoorwaarden en afhankelijkheden moet rekening worden gehouden bij realisatie? op welke omgevingen (hardware) dient de oplossing te werken? voor welke (technische) oplossing kan het best worden gekozen? welk ontwikkelscenario dient te worden gevolgd? aan welke informatiebeveiligingseisen dient te worden voldaan? aan welke architectuur richtlijnen dient de oplossing te voldoen? via welke stappen kan het eindresultaat beheerst worden bereikt? welk implementatie/uitrol scenario dient te worden gevolgd? welke risico’s worden vooraf onderkend en welke maatregelen kunnen daartegen worden genomen? aan welke eisen dient een te selecteren kennismanagement applicatie te voldoen? welke eisen worden gesteld aan de Mobile Data Assistants (MDA)? welke management informatie gegenereerd moet worden?

2.4 Doelgroep De doelgroep van de definitie studie bestaat uit: • de opdrachtgever en het management van Rijkswaterstaat ten behoeve van besluitvorming over de oplossingsrichting; • de voor dit project relevante voorbereidings- en adviesgroepen van Rijkswaterstaat die de besluitvorming voorbereiden. Daarnaast dient dit document ter informatie voor: • de beheerders (functioneel en daarbuiten) van de bestaande applicaties binnen Rijkswaterstaat;

18


• •

de medewerkers van Rijkswaterstaat voor handhaving en vergunningverlening; het projectteam en de leverancier(s) in de volgende fasen van het project.

2.5 Totstandkoming De definitiestudie is tot stand gekomen in vier fasen. In de eerste fase is een uitgebreide inventarisatie gedaan van de bestaande documentatie en rapporten. Hierin zijn de bestaande applicaties, de gebruikte processen, procedures en werkwijze geïnventariseerd en beschreven. In deze fase zijn ook gesprekken gevoerd met functioneel beheerders van de bestaande applicaties, key-users binnen de werkvelden van handhaving en vergunningverlening en architecten van Rijkswaterstaat. Daarnaast is in diezelfde fase een drietal workshops georganiseerd met de medewerkers van Rijkswaterstaat voor handhaving en vergunningverlening en een ICT workshop met specialisten vanuit de DID en WD. De tweede fase bestond uit het analyseren van de verzamelde informatie. De processen en applicaties zijn geanalyseerd ten aanzien van de gebruikte en benodigde functionaliteit. Dit heeft gediend als input voor de derde fase. In deze derde fase zijn de oplossingsrichtingen ontworpen ten aanzien van de ICT voorziening ter ondersteuning van handhaving en vergunningverlening. Per oplossingsrichting is een ontwikkeltraject beschreven voor de ontwikkeling en implementatie van die oplossing. Tegelijkertijd is er voor elke oplossingsrichting een business case ingevuld. In de vierde en laatste fase is het rapport van de definitiestudie tot stand gekomen. In die fase is ook een onderbouwd advies voor een oplossingsrichting opgesteld.

2.6 Uitgangspunten Het project Havik 2 kent een aantal uitgangspunten die zijn opgesteld bij het begin van het project. Voor de definitiestudie zijn dat de volgende: • de resultaten van het project Digitalisering Handhaving gelden als vertrekpunt (in het eindrapport beantwoord de business de ‘wat’- vraag voor wat betreft de handhaving); • er wordt gebruik gemaakt van en voortgeborduurd op de resultaten en leerervaringen van SAP Havik; • de procesbeschrijvingen die zijn opgesteld door het project Uniforme Primaire Processen (UPP) gelden als startpunt; • het door het project Consolidatie Nat opgestelde dienstenmodel is startpunt; • de bestaande functionaliteit in de applicaties WVO-info (Wet Verontreiniging Oppervlaktewater) en SAP Havik wordt als uitgangspunt genomen voor herbouw. Daarbij wordt kritisch bekeken welke functionaliteit in de nieuwe oplossing terugkomt;

19


• •

•

•

•

•

•

•

waar mogelijk worden bestaande bouwstenen gebruikt; de beschikbare bouwstenen van ICTU en E-Inspecties, voor het virtueel samenwerken met mede-overheden in het vergunningentraject en rond meldingen en inspecties, worden meegenomen in het realisatieproces; het bereiken van het doel van een specifiek proces is belangrijker dan het handhaven van de huidige werkwijze, die bestaat uit de mix van werkproces en ICT systemen. Er wordt op basis van kosten en baten besloten tot aanpassing van het werkproces dan wel de ICT ondersteuning dan wel een mix daarvan; er wordt gebruik gemaakt van producten/technologieën die binnen de markt breed toegepast worden en daarbij stabiel en betrouwbaar opereren (bewezen technologieën); de vereiste functionaliteit van de integrale ICT voorziening voor het ondersteunen van de werkprocessen wordt gerealiseerd door het aanschaffen van een (combinatie van) standaard pakket(ten). Alleen indien noodzakelijke functionaliteit niet kan worden gekocht wordt maatwerk software ontwikkeld; aangeschafte en geïmplementeerde pakketten zijn standaard en worden zo min mogelijk aangepast. Alleen door de leverancier uitgevoerd maatwerk wordt verricht, onder de voorwaarde dat dit maatwerk door de leverancier in het standaard pakket wordt opgenomen. De leverancier is verantwoordelijk voor aanpassing bij volgende versies; het systeem moet zich conformeren aan de ICT standaarden en het beleid van de Data-ICT-Dienst, daar waar de Rijkswaterstaat architectuur aansluit op generieke voorzieningen van het Ministerie van VenW geldt het VenWbeleid als uitgangspunt; het systeem dient te passen binnen de informatie- en applicatiearchitectuur zoals gedefinieerd door DID Enterprise Architectuur.

2.7 Criteria voor bepalen oplossingsrichting De criteria die zijn gebruikt voor het advies voor een oplossingsrichting zijn als volgt: • de mate waarin de functionele vraag kan worden ingevuld; • de te verwachtten gebruiksvriendelijkheid; • de kwaliteit (o.a. robuustheid en stabiliteit) van de oplossing; • de openheid van de oplossing voor koppelingen met andere systemen, portalen en gegevensbronnen; • de flexibiliteit van de oplossing om aanpassingen (bijvoorbeeld bij toekomstige wetswijzigingen) snel en tegen beperkte kosten door te kunnen voeren; • de toekomstvastheid van de oplossing; • de te verwachtten beheerinspanning na oplevering; • de kosten die gemoeid zijn met de realisatie (maatwerk); • de doorlooptijd die de realisatie vergt; • de mate waarin de oplossing past in het ICT landschap van de Rijkswaterstaat (gedefinieerd door de Enterprise Architectuur).

20


2.8 Raakvlakken met ander projecten Het project Havik 2 heeft een aantal raakvlakken met andere projecten. De voornaamste zijn (worden verder uitgewerkt in Hoofdstuk 3): • Landelijke Implementatie Waterwet (WilWat); • Projecten bij CBI m.b.t. Sap aanpassingen • Project LVO Waterwet; • Project Generiek Vergunningen GIS; • Project NIS; • Project Digitaal Journaal; • Project ICT op schepen; • Project Mobiele werkplek; • Project LIMS; • Project WDN; • Pilot Ligplaatsbeheer (Scheepvaartverkeermanagement) • Ontwikkelingen zoals NUP, E-inspecties, Basisregistraties en overige E-overheidsontwikkelingen; • Transitie project Capgemini.

2.9 Achtergrond van het project Havik 2 In 2005 is het project HAVIK (Handhaving, Vergunningverlening, Internet en Klantcontact) gestart als pilot in SAP voor ondersteuning van het primair proces. Het project is 1 april 2008 geëindigd en inmiddels geëvalueerd. HAVIK geeft invulling aan belangrijke doelstellingen van het ondernemingsplan Rijkswaterstaat (publieksgerichtheid, huis op orde) en heeft grote verbeteringen in de dienstverlening van Rijkswaterstaat tot stand gebracht, op bepaalde onderdelen. Het systeem HAVIK richt zich voornamelijk op de ondersteuning van een vijftal niet-milieu wetten. Op een aantal facetten is SAP HAVIK nog niet volledig doorontwikkeld: • Niet alle weten regelgeving in het werkveld (zoals de Wet Verontreiniging Oppervlaktewateren en het Activiteitenbesluit) worden (reeds) ondersteund in SAP HAVIK. Het systeem biedt ook (nog) geen ondersteuning aan het volledige proces van handhaving en vergunningverlening. • De performance en gebruiksvriendelijkheid van SAP HAVIK voldoen (nog) niet volledig aan de wensen van de gebruikers. • Met de komst van landelijke voorzieningen in de Waterwet ontstaat een overlap tussen het nieuwe interdepartementale omgevingsloket en het in HAVIK gerealiseerde digitale loket van Rijkswaterstaat. Tussen juni en december 2007 is door het project Digitalisering Handhaving een uitgebreid behoefteonderzoek uitgevoerd naar de modernisering van de handhaving. Dit onderzoek is uitgevoerd in opdracht van de Adviesgroep Handhaving en in afstemming met de Voorbereidingsgroep Nat. In de besluitvorming is de Adviesgroep Emissiebeheer betrokken gezien de directe consequenties voor het werkveld vergunningverlening. Handhaving en vergunningverlening zijn nauw aan elkaar verbonden, waardoor wijzigingen vanuit gezamenlijk oogpunt dienen te worden beschouwd. De raakvlakken

21


bevinden zich met name op het gebied van de gegevens. Het behoefteonderzoek heeft geleid tot de aanbeveling de ICT voorzieningen voor handhaving en vergunningverlening te herzien. De resultaten van het project Digitalisering Handhaving zijn afgestemd met Scheepvaart Verkeerscentrum (SVC) en de Inspectie Verkeer & Waterstaat (IVW). Het behoefteonderzoek,de evaluatie van het project SAP-HAVIK en de komst van de Waterwet met de aansluiting daarbij op de LVO, waren aanleiding om te komen tot een voorstel voor de realisatie van één integrale ondersteuning met één ICT voorziening voor alle wetten en het hele proces van handhaving en vergunningverlening. Op voorspraak van de Adviesgroep Handhaving heeft de Voorbereidingsgroep Nat op 28 november 2007 de uitvoering van het project Havik 2 voor de realisatie van bovengenoemd voorstel aangemerkt als één van de vijf topprioriteiten van handhaving. De onderliggende Business Case is op 16 april 2008 door de Voorbereidingsgroep Nat goedgekeurd. De Voorbereidingsgroep Informatievoorziening heeft op 19 juni 2008 ingestemd met de uitvoering van het project Havik 2. Het project Havik 2 maakt onderdeel uit van de implementatie van de Waterwet binnen Rijkswaterstaat, waarvoor de Waterdienst de uitvoering op zich neemt.

2.10 Aansluiting op overheidsontwikkelingen Het project Havik 2 loopt vooruit op de aansluiting met de elektronische overheidsontwikkelingen. Gesprekken op verschillende niveaus en met uiteenlopende echelons binnen in buiten Rijkswaterstaat hebben op enterpriseniveau zijn nog geen beleid of kaders opgeleverd, waar het project Havik 2 zich op kan richten. Indien er beleid ontwikkeld is om aan te sluiten op overheidsontwikkelingen, zou het programmaplan van Havik 2 mogelijk aangepast moeten worden.

22


3 Positionering Havik 2 In dit hoofdstuk wordt Havik 2 in de omgeving geplaatst. Binnen de overheid worden afspraken gemaakt over de dienstverlening met als doel een lastenverlichting voor burger en bedrijfsleven. Deze overheidsbrede ontwikkelingen worden in dit hoofdstuk besproken, en de gevolgen hiervan voor Havik 2 worden benoemd in paragraaf 3.1. Paragraaf 3.2 behandelt de ontwikkelingen die zich binnen Rijkswaterstaat afspelen. In paragraaf 3.3 wordt op basis van deze ontwikkeling de afbakening van Havik 2 gepresenteerd. Paragraaf 3.4 beschrijft vervolgens op basis hiervan de context van Havik 2, gezien vanuit de gegevens die Havik 2 omvat.

3.1 Overheidsbrede ontwikkelingen 3.1.1 Administratieve lastenverlichting (NUP) Burgers en bedrijven vragen om een overheid die snel, efficiënt en klantgericht werkt en niet steeds naar de bekende weg vraagt; dus betere dienstverlening met minder administratieve lasten. Om dat te bereiken moeten overheden (nog) meer samenwerken, hun bedrijfsvoering en gegevenshuishouding op elkaar afstemmen en aansluiten op reeds ontwikkelde en nog te ontwikkelen basisvoorzieningen. Om die reden is het noodzakelijk dat de overheid de onderdelen (bouwstenen) van haar e-overheidprogramma’s zoveel mogelijk uniformeert en op elkaar afstemt en dat alle overheden hiervan gebruik maken. Met de ondertekening van een akkoordverklaring zijn afspraken gemaakt tussen Rijk, provincies, gemeenten en waterschappen om de potentie van de inmiddels bestaande infrastructuur van de e-overheid gericht te benutten voor betere dienstverlening. Het NUP (Nationaal Uitvoerings Programma dienstverlening en e-overheid) is het uitvoeringsprogramma met werkafspraken behorende bij die akkoordverklaring. Zo werken Rijk, provincies, gemeenten en waterschappen samen aan een optimale dienstverlening aan de samenleving. Daarbij levert dit programma een belangrijke bijdrage aan de doelstellingen voor de vermindering van administratieve lasten voor burgers en bedrijven.1 Het NUP is een dynamisch programma: basisvoorzieningen die gereed en in gebruik zijn, kunnen uit het NUP worden verwijderd en nieuwe projecten kunnen aan het NUP worden toegevoegd. Dat geldt zowel voor de basisvoorzieningen uit de basisinfrastructuur als voor de voorbeeldprojecten. Het initiële project heeft een duidelijke einddatum. Op 1 januari 2011 zijn alle voorzieningen uit de basisinfrastructuur ontwikkeld en in gebruik genomen.

1

NUP Nationaal UitvoeringsProgramma Dienstverlening en e-overheid (versie 2.0 december

2008 http://www.e-overheid.nl/sites/nup)

23


Het NUP is naar zijn aard een afgebakend programma. Uitgangspunten ten aanzien van basisinfrastructuur zijn: • generiek: de voorziening is in meerdere sectoren toepasbaar / herbruikbaar; • noodzakelijk: de voorziening is noodzakelijk om de verbetering van de dienstverlening of de handhaving mogelijk te maken; • t.b.v. communicatie: de voorziening is nodig om communicatie tussen burger / bedrijf en dienstverleners of tussen dienstverleners onderling mogelijk te maken; • doelmatig: de toegevoegde waarde en/of de noodzaak (voor dienstverlening, financieel, juridisch, technisch of anderszins) is voor alle partijen evident. Om verder focus aan te brengen worden in het NUP zes voorbeeldprojecten benoemd. Dit zijn projecten waarin de basisinfrastructuur zichtbaar voor betere dienstverlening wordt ingezet. Voor Havik 2 zijn er twee relevante voorbeeldprojecten. Dat zijn: 1. Het omgevingsloket. De Wet Algemene Bepaling Omgevingsrecht (Wabo) zorgt voor één integrale vergunning, één loket, één bevoegd gezag en één handhavende instantie. Het omgevingsloket is het énige, landelijke loket en bestaat uit drie modules, voor burgers en bedrijven de kennismodule, om na te gaan of voor bepaalde activiteiten een vergunning nodig is, de aanvraagmodule en voor overheidsorganisaties de behandelmodule. Het formulier voor een aanvraag wordt zoveel als mogelijk vooringevuld met bijvoorbeeld NAW gegevens. Het omgevingsloket wordt door alle betrokken overheidsorganisaties ingepast in hun systemen en faciliteert het elektronische berichtenverkeer tussen deze organisaties. Voor de waterwet wordt aangesloten op dit omgevingsloket (zie paragraaf 3.1.6). 2. Dienstenloket van de Dienstenrichtlijn. Op 28 december 2009 moet in alle EU-lidstaten de Dienstenrichtlijn zijn ingevoerd. Dankzij de richtlijn kunnen dienstverleners straks eenvoudiger aan de slag in de EU. Via het Dienstenloket kunnen dienstverleners relevante informatie vinden en procedures afwikkelen. Het NUP stelt daarmee een aantal basisprincipes vast voor Havik 2. Daarnaast geven de twee genoemde voorbeeldprojecten sturing aan Havik 2. Het omgevingsloket betekent een eenduidige ontsluiting van de vergunningaanvraag, waardoor Rijkswaterstaat geen eigen digitaal loket hoeft te ontwikkelen voor de watervergunning. Het omgevingsloket faciliteert ook de uitwisseling van vergunningaanvragen met andere overheidsorganisaties. Het dienstenloket is de methode om aan burger en bedrijfsleven de

24


relevante informatie en procedures kenbaar te maken en daarmee ook het omgevingsloket vindbaar te maken. Rijkswaterstaat moet, gezamenlijk met andere bevoegde gezagen zoals de waterschappen en provincies, invulling geven aan het omgevingsloket voor de watervergunning en een loket voor de overige vergunningen en meldingen waar Rijkswaterstaat bevoegd gezag is. Ook moet Rijkswaterstaat een invulling geven aan de kenbaarheid van beide loketten. 3.1.2 NOiV Het programma Nederland Open in Verbinding (NOiV) informeert overheidsorganisaties over de mogelijkheden van open standaarden (OS) en open source software (OSS) en stimuleert hen deze waar mogelijk toe te passen in hun informatiesystemen. Het programma volgt hierbij het Actieplan Nederland Open in Verbinding , dat de staatssecretarissen van Economische Zaken en van Binnenlandse Zaken en Koninkrijksrelaties in september 2007 naar de Tweede Kamer hebben gestuurd. NOiV is de opvolger van het programma OSOSS (2003 - 2008). Open standaarden en open source software zijn belangrijk voor de overheid door: • het verhogen van de toegankelijkheid van informatie doordat een open standaard vrije en toekomstvaste koppelingen naar informatie kan regelen; • het verbeteren van de transparantie van overheidshandelen doordat de werking van computertoepassingen volledig inzichtelijk is voor EDP-auditors; • het verhogen van de informatieveiligheid doordat de broncode door iedereen beoordeeld kan worden; • het vergroten van de toekomstvastheid van de gekozen oplossingen doordat de code ook door derden onderhouden kan worden en achteraf inzichtelijk blijft (leveranciersonafhankelijk) en doordat gegevens in bestanden met een vrije en openbare structuur worden opgeslagen; • het vergroten van de concurrentiekracht van lokale softwareleveranciers doordat ook zij in staat zijn toepassingen te onderhouden en uit te breiden, en koppelingen kunnen realiseren naar andere bestanden en programmatuur; • het bevorderen van innovatie op de softwaremarkt doordat open standaarden en open source software derden de mogelijkheid bieden door te bouwen op eerdere ontwikkelingen; • het verlagen van de licentiekosten doordat open standaarden en open source software per definitie kosteloos worden aangeboden. Voor Havik 2 zijn zowel de open standaarden als de open source software van belang, omdat Havik 2 een nieuw informatiesysteem beoogd voor het werkveld van handhaving en vergunningverlening bij Rijkswaterstaat als overheidsorganisatie.

25


Open source software is software met twee kenmerken: • de broncode van de software is vrij beschikbaar; • in het licentiemodel is het intellectueel eigendom en het (her)gebruik van de software en bijbehorende broncode dusdanig geregeld dat de licentienemer de broncode mag inzien, gebruiken, verbeteren, aanvullen en distribueren. Bij open standaarden gaat het om standaarden ten behoeve van interoperabiliteit van informatiesystemen (ofwel het kunnen uitwisselen van gegevens tussen computerprogramma's). Standaarden kunnen 'open' zijn of 'gesloten'. Door open standaarden te gebruiken in plaats van standaarden die leveranciergebonden zijn (door intellectueel eigendomsrecht) kan de gebruiker informatie vastleggen in een toekomstvast formaat. Hoewel open source software vaak (ook) gebruik maakt van open standaarden is dat niet noodzakelijk. Gesloten source software kan met open standaarden omgaan en omgekeerd. Voor Havik 2 zijn een aantal open standaarden relevant. Dit zijn de standaarden (Aquo) van InformatieDesk standaarden Water (IdsW), INSPIRE en NEN3610. en daarnaast de Overheidsservicebus (OSB). NEN3610 Het Basismodel Geo-informatie (NEN3610) heeft tot doel de uitwisseling van geo-informatie tussen partijen en informatiesystemen eenvoudig en het gebruik ervan eenduidig en betekenisvol te maken. Het bevat de gemeenschappelijke basis van de verschillende onderliggende sectorale informatiemodellen. Met behulp van dit model kan er in alle sectoren tot op detailniveau worden gemodelleerd. INSPIRE De kaderrichtlijn INSPIRE staat voor INfrastructure for SPatial InfoRmation in Europe (zie www.ec-gis.org/inspire). INSPIRE verplicht alle EU-landen om de toegang tot een omvangrijke en diverse set aan geo-informatie te verwezenlijken. INSPIRE zorgt voor Europese wetgeving op het gebied van geo-informatie die in de Nederlandse wetgeving wordt verankerd. De kaderrichtlijn wordt in detail ingevuld door invoeringsregels, die in termijnen van kracht worden. Zij hebben betrekking op metadata, dataspecificaties, netwerkdiensten, data- en dienstenuitwisseling en monitoren en rapporteren. Het ministerie van VROM is verantwoordelijk voor de invoering van INSPIRE in Nederland. Hiervoor moeten: • weten regelgeving worden aangepast; • de infrastructuur worden gerealiseerd voor de beschikbaarstelling met geo-informatie en metadata; • de basisgegevens worden geharmoniseerd. Voor Nederlandse overheden die bronhouder zijn van ruimtelijke gegevens die onder INSPIRE vallen geldt vanaf 15 mei 2009 de verplichting om deze gegevens te leveren conform de richtlijn. Aquo

26


De uitwisseling van informatie tussen organisaties is een voorwaarde voor doordacht waterbeheer in Nederland. De kwaliteit van deze informatiestromen verbetert door een juiste toepassing van standaarden. Bovendien zorgt standaardisatie voor een beperking van de kosten van de informatiestromen. InformatieDesk standaarden Water (IDsW) is een samenwerkingverband van vijf waterbeherende overheden, waaronder Rijkswaterstaat. IDsW beheert en ontwikkelt informatiestandaarden voor het Nederlandse Waterbeheer. IDsW adviseert en communiceert over het gebruik van deze standaarden en nieuwe ontwikkelingen. De volgende standaarden worden door IDsW aangeboden als Aquo: • Definitie van termen en begrippen • Gegevensopslag • Gegevensuitwisseling • Verwerking van gegevens en presentatie Voorbeeld van de standaarden zijn bijvoorbeeld Entiteit Relatie Diagrammen, bijvoorbeeld voor metingen in het werkveld van waterbeheer. Daarnaast geeft IDsW invulling aan Europese richtlijnen zoals INSPIRE. OSB Er vinden talloze berichtuitwisselingen plaats binnen de overheid en dat zullen er nog veel meer worden. Veel overheidsinstellingen hebben tot nog toe eigen keuzes gemaakt voor de logistieke afspraken. Daardoor kunnen ze niet zonder meer met elkaar berichten uitwisselen en moet er telkens een nieuwe set afspraken geïmplementeerd worden. Door de Overheidsservicebus verandert dat. Die zorgt ervoor dat instellingen zo efficiënt mogelijk kunnen communiceren; het is de postbode die het berichtenverkeer regelt. De Overheidsservicebus verzorgt de logistieke kant van het berichtenverkeer en omvat standaarden om berichten juist te adresseren en veilig en betrouwbaar te kunnen verzenden. Dat betreft zaken als: • Naar welk adres moet een bepaalde serviceaanvraag gestuurd worden? • Hoe kan de serviceaanbieder met zekerheid vaststellen wie de aanvrager is? • Hoe kan zeker worden vastgesteld dat de inhoud van een bericht alleen maar door de juiste partijen kan worden bekeken? • Hoe kan er vanuit worden gegaan dat een bericht is aangekomen, zonder dat de geadresseerde een inhoudelijk bericht hoeft terug te sturen? De Overheidsservicebus biedt hiervoor één standaard, met een beperkt aantal variaties die nodig zijn om verschillend berichtenverkeer met verschillende karakteristieken te ondersteunen.

27


Met name de open standaarden zijn relevant voor Havik 2. Er is immers grote behoefte aan informatieuitwisseling met partners voor handhaving en vergunningverlening. Daarnaast moet ook informatie worden betrokken van andere overheidsinstanties, waar een open standaard voor het berichtenverkeer wenselijk is. Havik 2 dient in haar invulling van de ICT voorziening daarom ook aan te sluiten op bestaande open standaarden. Qua open source software moet Havik 2 een keuze maken voor de invulling van de ICT voorziening. Open source software moet hier een mogelijkheid zijn. 3.1.3

Kaderstellende visie op toezicht (2005)

In 2005 is door het kabinet een tweede kaderstellende visie op toezicht uitgebracht, waarmee het kabinet inspeelt op de nieuwe ontwikkelingen sinds 2001 om te komen tot nieuwe verhoudingen tussen overheid en samenleving. Het kabinet gaat de verantwoordelijkheid en zeggenschap van burgers en samenleving versterken. Deze nieuwe verhoudingen hebben belangrijke gevolgen voor de organisatie en de inhoud van het toezicht. De toezichtvisie geeft daartoe de vernieuwde, rijksbrede kaders. De functie van toezicht is breed. Toezicht is het verzamelen van informatie of een handeling of zaak voldoet aan de daaraan gestelde eisen, het oordelen daarover en het eventueel naar aanleiding daarvan interveniëren. Handhaving richt zich op de vraag of burgers, bedrijven en overheden zich aan de gestelde regels houden. Het is daarbij gericht op repressief optreden. Deze repressie is de bevoegdheid om dwang uit te oefenen en vrijheden te beperken. Deze bevoegdheid wordt gebruikt voor het verzamelen van informatie of het opleggen van een sanctie. Het kabinet hanteert zes principes van goed toezicht: selectief, slagvaardig, samenwerkend, onafhankelijk, transparant en professioneel. De zes principes zijn leidend voor de vormgeving van alle soorten toezicht (zie Figuur 4). Hiermee wordt beoogd om van object gericht toezicht naar systeem toezicht te gaan. Bij object gericht toezicht wordt specifiek gekeken naar het voldoen aan de voorschriften per bedrijf. Systeemtoezicht bekijkt het geheel van processen, systemen en organisatie bij een bedrijf of branche. Het uitgangspunt bij systeemtoezicht is vertrouwen. Vertrouwen dat bedrijven de voorschriften naleven en zorgdragen voor het op orde hebben van hun werkzaamheden. Systeemtoezicht moet leiden tot minder bedrijfsbezoeken. Systeemtoezicht vergt een nieuwe manier van plannen. In plaats van bedrijven te controleren, moet gekeken worden naar risico’s van bedrijfstakken of individuele bedrijven. Risico’s kunnen gekwantificeerd worden met behulp van de “Tafel van Elf”, een analysemodel voorde naleving van regelgeving, en de mogelijke gevolgen van het niet naleven. Belangrijk is dat hier gebruik wordt gemaakt van gegevens uit administraties over het naleefgedrag, om het risico zo objectief mogelijk te bepalen. Kort samengevat houdt systeemtoezicht op die manier in dat men wil “vissen waar de vissen zitten”.

28


Figuur 4: Principes van toezicht Havik 2 heeft als ICT voorziening te maken met de kaderstellende visie op toezicht en de principes die daarin worden gehanteerd. Maar de principes gaan ook verder dan de ICT voorziening, omdat er ook wordt ingezet op een andere manier van werken in het toezicht. Deze manier van werken moet in de organisatie en de processen van Rijkswaterstaat worden verankerd en worden ondersteund door de ICT voorziening. 3.1.4 Programma Vernieuwing Toezicht Het programma Vernieuwing Toezicht is één van de vier onderdelen van het programma Vernieuwing Rijksdienst. De Inspectieraad waarin de inspecteurs‐ generaal en directeuren van de rijksinspecties zijn vertegenwoordigd, staat aan het roer van de vernieuwing van het rijkstoezicht. De nieuwe aanpak stelt de bedrijven en instellingen waarop toezicht is centraal en werkt van daaruit naar minder toezichtlast en beter en duidelijker toezicht. Bedrijven en instellingen krijgen dus te maken met toezicht vanuit één aanspreekpunt dat op een inzichtelijke manier het toezicht organiseert, alsof er één rijkstoezichthouder is die op één manier gegevens verzamelt. Belangrijke onderdelen bij de vernieuwing zijn de verplaatsing van object toezicht naar systeemtoezicht, waarbij niet meer de objecten centraal staan in de handhaving, maar het systeem als geheel. Daarnaast is er het belang van de risicoanalyse. Een van de projecten in het programma Vernieuwing Toezicht is Einspecties. Het Kabinet heeft middels de ‘Kaderstellende Visie op Toezicht – Minder last, meer effect’ de rijksinspecties opgeroepen het toezicht te moderniseren en intensief en vergaand samen te werken.

29


Ook zullen rijksinspecties in het kader van het kabinetsbesluit ten aanzien van ‘eenduidig toezicht’ op informatietechnisch vlak een aantal voorzieningen moeten treffen. Zo zal de samenwerking tussen inspecties worden verplicht, zal per domein in de toekomst maar op één manier gegevens mogen worden verzameld en zullen er bij het MKB maximaal twee inspecties per jaar worden uitgevoerd. Voor deze voorzieningen is in 2006 een quickscan onderzoek uitgevoerd naar potentiële inzet van ICT als hulpmiddel. Dit heeft geresulteerd in 8 generieke voorzieningen: • Digitaal Dossier; • Bezoekinformatie- en Aandachtvestigingsysteem (BIS/AVS); • Signalering en risicoanalyse; • Gemeenschappelijke Inspectieruimte (GIR); • Meldingensysteem (MES); • Selfassessment systeem; • Mijn Dossier; • Front Office Websites. Rijkswaterstaat is als een van de rijksinspecties een partij die aan kan sluiten op het project E-inspecties. Havik 2 als ICT-voorziening voor handhaving (en dus inspecties) zal dan ook rekening moeten houden met dit programma. Op dit moment vindt een herijking van het project e-Inspecties plaats, eerste kwartaal 2009 zal nog afstemming plaatsvinden met het project Havik 2 om nader onderzoek te doen naar toepassing van generieke voorzieningen Digitaal Dossier en de Gemeenschappelijke Inspectieruimte. 3.1.5 Waterwet De Waterwet vervangt acht bestaande wetten voor het waterbeheer in Nederland. De waterwet regelt het beheer van oppervlaktewater en grondwater en verbetert de samenhang tussen waterbeleid en ruimtelijke ordening. De Waterwet zal leiden tot een vermindering van regels, watervergunningstelsels en administratieve lasten. De Waterwet is bedoeld als kaderwet en vervangt daarmee de volgende bestaande wetten: • Wet op de waterhuishouding; • Wet op de waterkering; • Grondwaterwet; • Wet verontreiniging oppervlaktewateren; • Wet verontreiniging zeewater; • Wet droogmakerijen en indijkingen; • Wet beheer rijkswaterstaatswerken; • Waterstaatswet 1900 en • Wrakkenwet (via een nog in te dienen invoeringswet); • Wet Bodembescherming (saneringsregeling voor waterbodems, via een nog in te dienen invoeringswet). De Waterwet is in maart 2008 met algemene stemmen door de Tweede Kamer aangenomen en is in januari 2009 in de Eerste Kamer behandeld. Naar verwachting treedt de Waterwet eind 2009 in werking, samen met het onderliggende Waterbesluit en de

30


Waterregeling. Voor het Waterbesluit is een voorontwerp beschikbaar, voor de Waterregeling is januari 2009 voorzien. De invoeringswet bij de Waterwet wordt in het voorjaar van 2009 ingediend bij de Tweede Kamer en regelt onder meer het overgangsrecht, aanpassing van andere wetgeving en de intrekking van bestaande sectorale wetten. Binnen de bestaande acht wetten zijn er zes vergunningenstelsels van toepassing. Met de Waterwet worden deze gebundeld in één watervergunning. Dat betekent dat voor alle handeling in het watersysteem straks maar één vergunning nodig is. Hierbij is de waterbeheerder het bevoegde gezag. Voor rijkswateren is dat Rijkswaterstaat. In de Waterwet is ook geregeld dat bij een samenloop van bevoegde gezagen, het hoogste bestuursorgaan het bevoegd gezag is, tenzij er onderlinge afspraken worden gemaakt. Samenloop van bevoegdheden doet zich niet alleen voor buiten Rijkswaterstaat (externe samenloop), maar ook binnen Rijkswaterstaat diensten (interne samenloop), namelijk wanneer sprake is van overlap met bevoegdheden van de verschillende diensten. In alle gevallen verlangt de wet één integrale watervergunning, waarbij Rijkswaterstaat als bestuursorgaan van het hoogste gezag in principe als het bevoegde gezag fungeert. Er zal een voorstel moeten komen hoe om te gaan met zowel interne als externe samenloop. Voor vergunningverleners betekent de Waterwet dat integraal dient te worden getoetst op alle doelstellingen en kaders hiervan. Belangrijk is ook de afstemming met andere vergunningstelsels. De belangrijkste hiervan is de omgevingsvergunning. Afstemming moet mogelijk maken dat de gebruiker niet de een vergunning zonder de andere krijgt. Een integratie van beide vergunningstelsels is echter niet voorzien. Voor indirecte lozingen vindt er een verschuiven van vergunningverlening door Rijkswaterstaat plaats naar de gemeente. Rijkswaterstaat krijgt daarvoor een adviesrol. Dit adviesproces is nog als openstaand punt in hoofdstuk 13 opgenomen voor nader onderzoek. Naast de vergunningplicht beschrijft de Waterwet (en het onderliggende Waterbesluit en de Waterregeling) ook ontheffingen, algemene regels en algemene verboden. De insteek hierbij is om zoveel mogelijk handeling te reguleren met algemene regels door een AMvB, zodat de lasten voor burgers en bedrijven zoveel mogelijk worden beperkt. Dat betekent dat de huidige vergunningplicht steeds meer wordt vervangen door een meldingplicht. Het Activiteitenbesluit onder de WVO (Wet Verontreiniging Oppervlaktewateren) en WM (Wet Milieubeheer), is hier een voorbeeld van. Voor handhavers betekent de Waterwet dat er in plaats van toezicht op vergunningen, meer toezicht zal plaatsvinden op meldingen. Daarnaast zijn niet alle activiteiten in het watersysteem meer melding- of vergunningplichtig, waardoor pas achteraf kan worden gekeken of wordt voldaan aan de wetgeving. Daarnaast worden de vergunningen

31


waarop moet worden gehandhaafd complexer, omdat de Waterwet meerdere bestaande wetgeving integreert. Voor burgers en bedrijven betekent de Waterwet vooral één loket voor het aanvragen van de watervergunning of het melden van een activiteit onder het Waterbesluit. Dat loket is functioneel hetzelfde als voor de omgevingsvergunning en bestaat uit zowel een digitaal loket (Landelijke Voorziening Omgevingsvergunning) en een loket bij de gemeente. Het blijft dus mogelijk een aanvraag op papier in te dienen. Ook direct een aanvraag sturen naar het bevoegd gezag behoort in de Waterwet tot de mogelijkheden, al geldt voor de omgevingsvergunning dat het Ministerie van VROM op termijn bedrijven wil verplichten om vergunningaanvragen of meldingen onder AMvB digitaal via de LVO te doen. 3.1.6 Digitaal loket voor Waterwet Conform de Waterwet (artikelen 6.12 en verder) en het Waterbesluit (artikelen 6.16 en verder) zijn bedrijven in beginsel verplicht om een aanvraag voor een watervergunning uitsluitend via elektronische weg in te dienen. Burgers hebben daarin de vrijheid om te kiezen voor zowel een digitale als schriftelijke aanvraag. Het bevoegd gezag is, in afwijking van de Awb, verplicht om elektronisch ingediende aanvragen in ontvangst te nemen. De aanvraag voor een watervergunning wordt ingediend bij de burgemeester en wethouders van de gemeente waar het werk of inrichting wordt uitgevoerd, maar deze mag ook direct bij het (juiste) bevoegd gezag worden ingediend. Het bevoegd gezag geeft daarna een afschrift aan de betreffende burgemeester en wethouders van de gemeente. Het bevoegd gezag is volgens de wet verplicht om de aanvrager een ontvangstbevestiging te sturen en te melden dat het bevoegd is om te beslissen en welke procedure hiervoor wordt gebruikt. Daarvoor worden in de ontvangstbevestiging ook dossiergegevens verstrekt aan de aanvrager, zodat deze de status van zijn “zaak” kan volgen. Voor de digitale (en fysieke) aanvraag wordt door het Ministerie van VROM de Landelijke Voorziening Omgevingsloket (LVO2) ontwikkeld, een onderdeel van de e-overheid. Rijkswaterstaat stelt ten behoeve van de Waterwet een programma van eisen samen om de LVO ook toepasbaar te maken voor de Waterwet. De LVO is een geheel aan afspraken én ICT-voorzieningen dat ondersteuning biedt aan: • het via een elektronisch en fysiek (op papier) loket kunnen indienen van aanvragen voor de Watervergunning; • het verstrekken van informatie over weten regelgeving en informatie over de status van de aanvraagbehandeling;

2

Niet te verwarren met het RWS model voor LevensduurVerlengendOnderhoud (het LVO-

model)

32


•

het vaststellen van het bevoegd gezag dat de communicatie met de klant verzorgt; het bevoegd gezag dat verder de behandeling van de aanvraag coördineert; alle gegevens die de overheid van de aanvraag en de aanvrager bijhoudt (dossiervorming); de inrichting van het elektronisch gegevensverkeer voor dit proces wordt ingericht met berichten volgens de randvoorwaarden uit de NORA (Nederlandse Overheid Referentie Architectuur, zie paragraaf 3.1.11).

• • •

Voor Havik 2 betekent de LVO dat de digitale aanvraag wordt geregeld voor de waterwet en het activiteitenbesluit. Havik 2 is daarmee vooral bedoeld voor de (inhoudelijke) behandeling van die digitale aanvraag en het vormen van dossiers over vergunningverlening én handhaving hiervan. Dat neemt niet weg dat voor wetgeving die niet met het LVO ondersteund wordt, een digitaal loket beschikbaar moet zijn. Havik 2 zal daarom een invulling moeten geven aan een digitaal loket naast de LVO.

Oriënte ren

Aanvragen

Ontvange n

B ehandele n

B esluiten

L andelijke V oorziening Omge vings verg unning B ranc he ‐ wijz ers

A anvraagmodule Digitale aanvra ag

V rage nboom Informatie bronnen

D os sier module V oorportaal (dig itaa l vooroverleg )

R ijks waters taat

P apieren aanvra ag V oorove r‐ leg op papie r

Ont‐ va ngs t

B ehandeling

Status informatie

E igen Doc umenta fhandelings s ys teem

Digitaal arc hie f

Digitaal en/of fys iek arc hie f

W erks troombes turings s ys teem

Figuur 5 Schematisch ontwerp LVO De LVO bestaat uit de volgende functionele componenten: • Aanvragenmodule De Aanvraagmodule voor het opstellen en indienen van aanvragen. De aanvraagmodule bestaat een vragenboom en een (elektronisch) formulier. De vragenboom helpt de aanvrager bij het bepalen of een vergunning nodig is en welke onderdelen van de vergunning van toepassing zijn. Het doorlopen van de vragenboom leidt tot een formulier op maat. Daarbij wordt ook duidelijk welke instantie waarschijnlijk

33


•

bevoegd gezag is en waar de aanvraag moet worden ingediend. Voor aanvragers die regelmatig gebruik maken van de LVO wordt een verkorte procedure (vragenboom) beschikbaar gesteld. Het formulier is beschikbaar op papier en in elektronische vorm en wordt samengesteld op basis van het geven van antwoorden op de vragen. Omdat de aanvraagmodule een koppeling heeft met DIGID worden gegevens die reeds bekend zijn bij de overheid, op het formulier voor-ingevuld. Eventuele bijlagen (tekeningen, brieven etc) kan de aanvrager meezenden. De aanvraagmodule is een verplicht onderdeel van de LVO, maar het formulier zal niet in het hele land hetzelfde zijn. Het bevoegde gezag kan zelf vragen toevoegen of bepaalde onderdelen ‘uitzetten’. Dossiermodule De dossiermodule bestaat uit twee dossiers: 1 Aanvraagdossier In de dossiermodule zitten alle gegevens die door de aanvrager zijn ingevuld met bijlagen zoals tekeningen. Alle informatie die door de aanvrager is aangeleverd, is het ‘aanvraagdossier’. Tijdens het opstellen van de aanvraag is het aanvraagdossier niet toegankelijk voor het bevoegd gezag. Dat is alleen mogelijk als de aanvrager in het dossier heeft aangegeven overleg te willen plegen over de aanvraag. 2 Behandeldossier Het behandeldossier bestaat uit de informatie uit het aanvraagdossier én de informatie en documenten die gedurende de behandeling door of namens het bevoegd gezag zijn toegevoegd. Dit dossier biedt overheden en adviseurs de mogelijkheid om digitaal ingediende aanvragen via internet op te slaan, te raadplegen en van commentaar te voorzien. Bovendien kan men bouwtekeningen elektronisch bekijken en bewerken. Het gebruik van het behandeldossier is niet verplicht. Bevoegde gezagen kunnen ook andere voorzieningen gebruiken voor de uitwisseling van gegevens.

Omdat de LVO door verschillende overheidsinstanties gebruikt moet gaan worden, als frontoffice voor de Waterwet, worden er geen technische eisen gesteld aan de ICT-voorzieningen van de bevoegde gezagen, omdat de mate van digitalisering van werkprocessen per organisatie kan verschillen. Daarbij wordt dan met name gekeken naar de documentbehandeling, werkstroombesturing en archivering. De LVO faciliteert het aanvraagproces maar bevat geen specifieke administratie. Op het moment dat het aanvraagproces is beëindigd, worden de gegevens uit de LVO verwijderd. Dit houdt in dat de back office van het bevoegd gezag voorzieningen moet hebben om de informatie uit het aanvraagproces en vooroverlegproces te kunnen administreren.

34


De aanvrager moet in staat zijn om een beeld over de behandeling van de aanvraag te kunnen vormen. Daarvoor moet vanuit de backoffice van het bevoegd gezag statusinformatie worden verstrekt. Er zal dus een relatie moeten zijn tussen de gegevens in de aanvraagmodule en de administratie van het bevoegd gezag. Voor deze administratiefunctie en procesondersteuning wordt Havik 2 ingericht. Havik 2 zal derhalve de informatiebehoefte bij de LVO neerleggen. Rijkswaterstaat moet beslissen of voor de behandeling van de vergunningaanvraag gebruik wordt gemaakt van de behandeldossier uit het LVO. 3.1.7 Wet Dwangsom en beroep bij niet-tijdig beslissen De overheid wil burgers en bedrijven een effectief rechtsmiddel geven tegen te trage besluitvorming door het bestuur. Daarom komt er een nieuwe wet, de Wet dwangsom en beroep bij niet-tijdig beslissen. Deze treedt uiterlijk 1 januari 2010 in werking. De wet regelt dat burgers en bedrijven recht hebben op een dwangsom als de overheid niet binnen de wettelijke termijn beslist. Daartoe wordt in de Awb een regeling opgenomen die burger en bedrijf in staat stelt om, als een bestuursorgaan niet binnen de wettelijke termijn beslist, snel een uitspraak van de rechter te krijgen, zonder voorafgaande bezwaarschriftprocedure. Na het verstrijken van de wettelijke beslistermijn moet de burger of het bedrijf het bestuursorgaan schriftelijk in gebreke stellen. Het bestuursorgaan heeft vervolgens twee weken om alsnog een besluit te nemen. Na deze twee weken begint de dwangsom van rechtswege te lopen voor maximaal 42 dagen, tot een maximum van € 1.260,=. Achteraf - als het besluit alsnog is genomen of de 42 dagen zijn verstreken - stelt het bestuursorgaan zélf de verschuldigdheid en de hoogte van de dwangsom vast. Het gaat hierbij overigens om een ambtshalve te nemen beslissing, dus de dwangsomregeling is niet ook op deze beslissing van toepassing. Als een bestuursorgaan te laat beslist, dan staat daar voortaan een dwangsom op die aan de burger of het bedrijf betaald moet worden: 20 euro per dag in de eerste veertien dagen, de twee weken daarop 30 euro en daarna 40 euro per dag, met een maximum van 1260 euro. Gedurende de beroep procedure kan de dwangsom hoger uitvallen dan 1260 euro. Voordat de belanghebbende beroep kan instellen, moet hij het bestuursorgaan schriftelijk in gebreke stellen, tenzij dit redelijkerwijs niet kan worden gevergd. De wet dwangsom en beroep bij niet-tijdig beslissen vraagt van Rijkswaterstaat dat de termijn van vergunningaanvragen wordt bewaakt. Ook termijn bewaking en opvolging binnen de termijn van bezwaar en beroep is noodzakelijk. Door het management van Rijkswaterstaat zal vervolgens moeten worden gestuurd op deze termijnen.

35


Voor Havik 2 betekent de wet Dwangsom dat het mogelijk moet zijn om de termijnen van vergunningaanvragen, het registreren en behandelen van meldingen, en van bezwaar en beroep aan te passen en de nog resterende termijn te bewaken. 3.1.8 Archiefwet 1995 Overheidsorganisaties moeten voldoen aan een aantal wettelijke verplichtingen ten aanzien van hun archiefvorming en -beheer. Ook digitale informatie valt onder de werking van deze regels. Deze verplichtingen zijn vastgelegd in de Archiefwet 1995. Overheidsarchieven worden tijdens de werkprocessen van een organisatie gevormd om te documenteren hoe taken zijn verricht. Ongeacht hun vorm (papier, microfilm of digitaal) worden archieven gebruikt voor bedrijfsvoering en om verantwoording af te leggen aan de samenleving. Nu is iedereen zo langzamerhand wel overtuigd van de voordelen van een digitale overheid. De bijkomende problemen zijn echter nog niet opgelost. Meer digitale transacties tussen de burger en de overheid, betekent een omvangrijke omslag in de backoffice, oftewel de informatiehuishouding, van de overheidsorganisaties. De blijvende toegankelijkheid van digitale informatie is een ander probleem dat dringend oplossing behoeft. Duurzaam digitaal werken en bewaren is hiervoor de oplossing. Duurzaam digitaal werken betekent: het op zodanige wijze vastleggen, bewaren, beheren en beschikbaar stellen van digitale documenten (in de brede zin van het woord), dat deze ook na verloop van tijd raadpleegbaar, toegankelijk en authentiek zijn. Een officieel digitaal document moet in principe digitaal bewaard worden, omdat anders informatie verloren kan gaan. Voor Havik 2 biedt de archiefwet de mogelijkheid om digitaal te blijven werken en beschikkingen digitaal te archiveren. Vanuit het Nationaal Archief zijn hier voorbeelden voor opgesteld. Voor bestaande vergunningen, die niet beschikbaar zijn in digitale vorm, zal een keuze gemaakt moeten worden door Rijkswaterstaat om deze wel of niet te digitaliseren. Daarnaast is de Archiefwet 1995 de richtlijn voor Havik 2 voor de bewaartermijn van vergunningen zijn ingetrokken. 3.1.9 Binnenvaartwet De binnenvaartwet treedt in de loop van 2009 in werking en voegt een drietal wetten en ongeveer vijftig Ministeriële Regelingen samen. Daarbij gaat het in belangrijke mate over eisen aan schip en bemanning. De IVW en de KLPD verzorgen op dit moment de handhaving van deze wet maar er zal in 2010 waarschijnlijk een belangrijke verschuiving richting Rijkswaterstaat plaatsvinden. Dit omdat de KLPD zich terugtrekt en de IVW onvoldoende middelen heeft (onder andere in de vorm van vaartuigen) om dit alleen te kunnen doen. Daarmee ontstaat ook een behoefte aan ondersteunende systemen voor handhaving van de Binnenvaartwet. Voor de binnenvaart is een frontoffice opgericht in het kader van het programma Vernieuwing Toezicht met als doelstelling een vermindering

36


van de toezichtslasten. De organisatievorm verschilt, maar de uitgangspunten en doelstellingen zijn: • Toezichthouders werken nauwer samen door betere informatieuitwisseling,afgestemde inspectieprogramma’s, gezamenlijke risicoanalyses, signaaltoezicht en taakoverdracht. • Toezicht is gericht op risicovolle activiteiten en bedrijven; aantoonbaar goede bedrijven worden minder geïnspecteerd (verdiend vertrouwen). Het frontoffice is nog in een beginstadium. De belangrijkste spelers zijn het KLPD/Dienst Waterpolitie, de Zeehavenpolitie, Rijkswaterstaat, de Inspectie Verkeer en Waterstaat en de gemeentelijke havenbedrijven Rotterdam en Amsterdam. Binnen het project worden de volgende deelprojecten voorbereid: • informatiegestuurd inspecteren door informatie-uitwisseling tussen toezichthouders; • gezamenlijke risicoanalyses, en • een gezamenlijk inspectieprogramma voor 2009 (en volgende jaren). Om aan te kunnen sluiten op het frontoffice binnenvaart moet Havik 2 in staat zijn om te communiceren met de bouwstenen die er worden gebruikt (E-Inspecties). 3.1.10 Basisregistratie De overheid heeft een zestal basisregistraties benoemd, waarvoor ook wetgeving wordt of reeds is ontwikkeld. In de wetgeving wordt geregeld, dat de basisregistraties de authentieke bron zijn voor gegevens over GEBOUWEN, PERSONEN, BEDRIJVEN, ADRESSEN, KADASTER en TOPOGRAFIE. Authentieke bron betekent dat de bronhouder verantwoordelijk is voor de kwaliteit van het gegeven én dat de overheidsinstellingen (organisaties die publiekrechtelijke taken uitvoeren) verplicht zijn deze registraties te (gaan) gebruiken. Op dit moment (januari 2009) is de Wet GBA (voor natuurlijke personen) reeds inwerking getreden. De gemeenschappelijke gegevensverzamelingen (met name de basisregistraties) behoren tot een landelijk netwerk van registraties, waarvoor hoge eisen aan beveiliging worden gesteld. De toegankelijkheid is afhankelijk van diverse factoren zoals autorisatie, privacy en weten regelgeving. Dit leidt tot een aantal overheidsbreed vastgelegde afspraken: • overheidsbrede basisregistraties worden gebruikt boven eigen verzamelingen; • eigen basisregistraties (kernregistraties) worden gebruikt boven eigen lokale (taakspecifieke) verzamelingen; • ten behoeve van de toegankelijkheid tot de gegevens is een eenduidige sleutelstructuur noodzakelijk. Als sleutel dient binnen de overheid het Burgerservicenummer (BSN) of Bedrijfen Instellingen Nummer (BIN) worden gebruikt. Dit laatste nummer is nog niet verplicht. • gegevensbeheer is van groot belang gezien de organisatiebrede afhankelijkheid van actuele, correcte en consistente gegevens.

37


•

metadata in de vorm van standaard, uniforme eenduidige gegevensmodellen, gegevenselementen functiespecificaties moeten worden ontwikkeld of gekozen. De metadata specificeert de gemeenschappelijke omgeving en dient opgeslagen en toegankelijk gemaakt te worden via een bibliotheeksysteem (repository). De metadata voorziet in een gemeenschappelijke taal voor effectieve communicatie bij koppeling van systemen en gebruik en uitwisseling van gegevens.

Een veelvoud aan eigen, niet eenduidige, lokale definities moeten wijken voor eenduidige geaccepteerde Rijkswaterstaat-brede en daar waar verplicht of mogelijk en realistisch, geconformeerd te worden aan overheidsbrede en/of industriebrede definities en betekenissen. De basisregistraties dienen uiteraard ontsloten te worden. Hiervoor wordt de Overheids Service Bus (OSB) ontwikkeld. De OSB gaat alleen over de logistiek van het berichtenverkeer van en naar de basisregistraties (en tussen overheidsorganisaties) maar zegt niks over de inhoud hiervan. Een ander aspect wat met de basisregistraties samenhangt is de Terug Meld Faciliteit (TMF). Deze faciliteit ondersteunt het eenmalig melden aan de basisregistraties van het vermoeden van onjuiste gegevens in deze basisregistraties. Daarbij gaat het om bijvoorbeeld het vermoeden dat een persoon niet de echte eigenaar van een pand is. De betreffende eigenaar van de basisregistratie dient deze melding vervolgens uit te zoeken. Op deze manier zorgen alle overheidsinstanties dat de gegevens in de basisregistraties up-to-date en betrouwbaar zijn. Als laatste belangrijke onderdeel rondom de basisregistraties is er de Gemeenschappelijke Ontsluiting Basisregistraties (GOB). Hierin worden afspraken gemaakt over een eenduidige en uniforme manier van ontsluiten van alle basisregistraties. Regelmatig komt het voor dat een overheidsinstantie van meerdere basisregistraties tegelijk een gegeven wil, bijvoorbeeld bij de vraag ‘wat is het woonadres van persoon x, van welke voertuigen is hij eigenaar en wat is zijn inkomen over 2007?'. Dat kan alleen worden beantwoord door meerdere basisregistraties aan elkaar te koppelen, zodat een samengesteld gegeven ontstaat. Hierover worden in de GOB afspraken gemaakt. Voor Havik 2 betekenen de basisregistraties ten eerste dat het uitvragen van gegevens niet meer nodig is. Deze worden betrokken uit de basisregistraties die daarvoor de enige en authentieke bron zijn. Grotendeels wordt dit opvragen van gegevens al afgehandeld door de LVO. Havik 2 krijgt wel te maken met de basisregistraties bij wijzigingen in deze basisregistraties, die betrekking hebben op een vergunning in de administratie van Havik 2, bijvoorbeeld bij overlijden of faillissement. In de administratie van Havik 2 moeten hier voorzieningen voor beschikbaar zijn. Hiervoor zijn de drie geschetste projecten rondom de basisregistraties belangrijk, te weten de OSB, de TMF en de GOB.

38


3.1.11 Nederlandse Overheid Referentie Architectuur Vrijwel alle overheidsorganisaties zijn druk bezig een bijdrage te leveren aan de e-overheid. Daarbij is het van belang principes vast te leggen over de wijze waarop samengewerkt kan worden, processen naadloos aan elkaar kunnen worden gekoppeld en gegevens kunnen worden uitgewisseld. Deze principes zijn te vinden in de Nederlandse Overheid Referentie Architectuur (NORA). NORA is bestemd voor professionals, zoals management-adviseurs, informatiemanagers, architecten, ontwerpers van processen en systemen en ICT-ontwikkelaars. Door gebruik te maken van NORA kunnen deze professionals hun bestuurders en managers beter adviseren. NORA bevat modellen en principes van de werking van de e-overheid. Door deze modellen en principes te hanteren als uitgangspunten voor de ontwikkelingen binnen de eigen organisatie, kan een organisatie waarborgen dat haar ontwikkelingen passen binnen de ontwikkelingen binnen de e-overheid als geheel. NORA als referentiearchitectuur kan gezien worden als de vertaling van landelijke en sectorale beleidsuitgangspunten naar principes voor de inrichting van de landelijke en sectorale infrastructuren. NORA schrijft dus niet voor hoe overheidsorganisaties zich moeten gedragen. NORA beschrijft wel op welke wijze ze succesvol kunnen samenwerken. NORA is hiermee volgend aan beleid en kan gelden als kader of toetssteen voor nieuwe ontwikkelingen binnen de e-overheid. NORA kent geen wettelijke status. Organisaties werken op vrijwillige basis met NORA. NORA wordt inmiddels regelmatig ‘vertaald’ in een meer specifieke referentie architectuur, zoals bijvoorbeeld voor de kerndepartementen. Gebruik van de principes uit NORA maakt samenhang en samenwerking beter mogelijk. Binnen de NORA worden de overheidsinstellingen op het hoogste niveau, gekenschetst door een driedelige indeling: frontoffice, midoffice en backoffice (zie Figuur 6). Deze indeling is binnen veel organisaties nieuw, omdat voorheen elk product of elke dienst bij één specifieke afdeling binnen kwam en direct naar de juiste backoffice werd doorgesluisd. Daardoor hebben de burger en het bedrijf te maken met verschillende loketten in de huidige (oude) situatie.

39


Figuur 6 Overzicht bedrijfsinrichting van één overheidsorganisatie In de toekomstige situatie waarbij Rijkswaterstaat de Waterwet uitvoert en de LVO is geïmplementeerd, is op basis van de NORA een schets te geven van de bedrijfsinrichting (zie Figuur 7). Hierin is bijvoorbeeld de LVO te zien, waarbij de burger via het Burger Service Nummer (BSN) en het bedrijf via het Bedrijf- en Instellingen Nummer (BIN) een aanvraag kan doen. De LVO is gekoppeld aan de midoffice van de bevoegd gezagen van Rijkswaterstaat, waar de aanvraag wordt behandeld en waar een beschikking wordt gegeven. Hierin is niet alleen de midoffice terug te vinden (oranje) maar ook een frontoffice (lichtblauw). Immers, burgers mogen altijd een papieren aanvraag doen, en zodra bevoegd gezag en aanvrager besluiten dat digitaal niet wenselijk is, mag een bedrijf ook op papier aanvragen. Aan de achterkant van de midoffice bevindt zich een gegevensopslag van de vergunningverlening en handhaving, waarin de eigen gegevens over vergunningverlening en handhaving worden opgeslagen. Het laatste gedeelte beschrijft de basisregistraties die zowel bij aanvraag als bij behandeling kunnen worden uitgevraagd. De NORA biedt voor Havik 2 een manier om invulling te geven aan de principes van de e-overheid. Ook kan het worden gebruikt als toetssteen voor ontwikkelde systemen. Naast de NORA is er echter ook de Enterprise Architectuur Rijkswaterstaat (EAR, zie paragraaf 3.2.2) waarin uitspraken worden gedaan over de architectuur.

40


E lektronis c he overheid op termijn G emeens c happelijke e n gekoppelde frontoffice en backoffice voorzie ningen

onderlinge gegevens uitwis s eling binne n de e‐overheid

B edrijven D igiD (e)‐N IK /P K I

O V E R HE IDS P O R TA L / O R G A NIS A T IE P O R TA L

TOP ‐kaart verwijz e r (links )

BS N

Noord‐N L

O os t‐NL

gebouwen

informatie e‐form ulie r

Noord‐B ra bant

pers onen

z oekmac hine

burger

vra genboom

IJ s s elm.ge bied

adres s en

L imburg

K adas ter

aanvra agm odule

B IN bedrijf

beha ndeldos s ier attenderings s ervic e

Noord‐H olland

. . . . D ig iD P KI

inkomens S chepen

Ove rheids tra ns actie poort

W aterdiens t

auto's O ve rige

koppeling aan gemeens chappelijk fro nt office

etc. s ervicebus (s e n)

Figuur 7 Waterwet en Rijkswaterstaat

3.2 Rijkswaterstaat brede ontwikkelingen 3.2.1

Agenda 2012

Op de managementdag van 11 juni 2008 is de Agenda 2012 van het Ondernemingsplan Rijkswaterstaat gepresenteerd. Deze Agenda geeft de koers aan van de organisatie voor de komende vier jaar. Het schetst het toekomstperspectief en geeft concrete ambities en acties aan, om dat perspectief te realiseren. Onderdeel daarvan is een nieuw gewaagd doel voor 2012, dat richting geeft aan het dagelijks handelen in de komende jaren. De Agenda 2012 staat niet op zichzelf. Uitgangspunt van de Agenda is het Ondernemingsplan 2004-2008. Agenda 2012 bouwt voort op dat Ondernemingsplan en op de resultaten die de uitvoering van dat plan heeft opgeleverd. Het maakt bovendien deel uit van de ‘Vernieuwing VenW’, het project dat tot doel heeft heel VenW beter toegerust te maken voor de eisen van politiek en maatschappij. Zo levert Rijkswaterstaat zijn bijdrage aan de Vernieuwing van VenW en daarmee aan de Vernieuwing van de Rijksdienst.

41


In Figuur 8 zijn de pijlers van de Agenda 2012 weergegeven, met daarin centraal het gewaagde doel.

Figuur 8 Pijlers van de agenda 2012 De Agenda 2012 betekent veel voor het werkveld van handhaving en vergunningverlening, vanwege de publieksgerichte taak die daarbij komt kijken. Voor de ICT voorziening voor dit werkveld, die wordt gerealiseerd door Havik 2 betekent de Agenda 2012 dan ook veel, met name op het gebied van betrouwbare en bruikbare informatie als directe relatie en voldoende en schoon water, evenals vlot en veilig verkeer over weg en water als indirecte relatie. Havik 2 kan daarmee via het werkveld handhaving en vergunningverlening een bijdrage leveren aan de Agenda 2012. 3.2.2 Enterprise Architectuur Rijkswaterstaat Het bestuur van Rijkswaterstaat heeft in de agenda 2012 een richting uitgezet voor de toekomstige ontwikkeling van Rijkswaterstaat. Deze richting moet nu door de Rijkswaterstaat organisatie in de praktijk worden gebracht. Architectuur is hierbij een goed stuurmiddel om de Rijkswaterstaat processen en hun bijbehorende informatievoorziening in die gewenste richting te brengen. Architectuur geeft overzicht en maakt projecten beheersbaar, efficiënt en effectief. Het startpunt voor architectuur zijn architectuurprincipes; dit zijn kernachtige, sturende uitspraken die onder andere gebruikt kunnen worden voor het toetsen en opstellen van businesscases, strategische informatie¬plannen en projecten. Daardoor worden de principes vertaald naar concrete activiteiten zoals bijvoorbeeld, het inrichten van

42


een verkeerscentrale en de uniformering van de bediening van sluizen en bruggen. Voor Rijkswaterstaat is door de voorbereidingsgroep Informatievoorziening op 19 juni 2008 besloten om deze Enterprise Architectuurprincipes te gebruiken als toetsingskader voor businesscases. Het gaat hierbij om de volgende 10 principes: 1. Rijkswaterstaat is toonaangevend opdrachtgever; 2. Rijkswaterstaat is publieksgericht netwerkmanager; 3. Rijkswaterstaat heeft regie op de informatiehuishouding; 4. Rijkswaterstaat is een vernieuwende organisatie; 5. Rijkswaterstaat houdt rekening met de (onder)houdbaarheid van systemen; 6. gegevens worden één keer, verworven, opgeslagen en beheerd; 7. de informatieomgeving faciliteert de medewerker in zijn/haar rol en verantwoordelijkheid; 8. vertrouwen kweken met de juiste beveiliging; 9. Rijkswaterstaat heeft één integrale informatie-infrastructuur met goede ontsluitingsmogelijkheden; 10. Rijkswaterstaat is resultaatgedreven en ondernemend. De uitwerking van deze principes heeft betrekking op Havik 2. Bijvoorbeeld voor de gegevens, waarbij het architectuurprincipe zegt dat gebruik moet worden gemaakt van de basisregistraties, maar ook dat er een ketenbenadering is voor gegevens met afspraken over de opslag over heel Rijkswaterstaat. Ook voor de oplossingscenario’s en implementatie van Havik 2 bieden de architectuurprincipes een richtlijn, bijvoorbeeld ‘proven’ technology voor cruciale bedrijfsprocessen. Voor Havik 2 zijn de EAR principes van toepassing. 3.2.3 Kwaliteitsmanagement Kwaliteitsmanagement is een belangrijk onderdeel binnen Rijkswaterstaat. Voor handhaving voor de milieuwetten waar Rijkswaterstaat het bevoegd gezag is, is in 2005 het Besluit Kwaliteitseisen milieubeheer gepubliceerd, een resultaat van het project ‘professionalisering van de milieuwethandhaving’. Voor handhaving voor de WVO is dit besluit uitgewerkt in procedures en werkinstructies. Via de website van de Helpdesk Water zijn deze te vinden. Voor Havik 2 is kwaliteitsmanagement een belangrijk onderdeel. Vanuit kwaliteitsmanagement worden Rijkswaterstaatsbreed afspraken gemaakt over de manier waarop de primaire (en ondersteunende) taken worden uitgevoerd die worden vastgelegd in procedures en werkinstructies. Er dient dus afstemming te zijn tussen deze procedures en werkinstructies en de ICT-voorziening Havik 2. 3.2.4 WilWat WilWat (Werkgroep Implementatie Waterwet Rijkswaterstaat) is een breed samengestelde werkgroep om het implementatieproces van de Waterwet binnen Rijkswaterstaat te begeleiden. Onder de werkgroep zijn verschillende deelprojecten vormgegeven, elk met een eigen thema. Deze deelprojecten zijn (januari 2009):

43


• • • • • • • • •

communicatie en opleiding; organisatie na Waterwet; één loket; beheergrenzen; legger; waterbodems; indirecte lozing; handhaving; normeren niet-primaire waterkering.

In bijna alle gevallen verleent het ‘centrale apparaat’ van de regionale diensten van Rijkswaterstaat vergunningen op basis van de Wvo/Wwh en beschikkingen ex Wbb, terwijl Wbr-vergunningen veelal door de districten worden verleend. Na de inwerkingtreding van de Waterwet worden waterbeheerders geacht één integrale watervergunning te verlenen, waarbij de vergunningaanvraag aan álle aspecten van het waterbeheer moet worden getoetst. Ditzelfde geldt voor de handhaving voor deze wetten waarbij behalve op de watervergunning ook nog op andere vergunningen of meldingen moet worden toegezien. Het project “Organisatie na Waterwet“ buigt zich over de vraag, hoe deze integrale benadering binnen Rijkswaterstaat geïmplementeerd moet worden. De centrale vraag daarbij is of het mogelijk is met de huidige organisatie of dat daar wellicht een reorganisatie voor nodig is. Een aantal scenario’s is denkbaar: 1. Er is geen reorganisatie nodig. Met een goede afstemming tussen centraal apparaat en districten moet het mogelijk zijn een integrale afweging uit te voeren. Aandachtsput is de termijnbewaking. 2. Een reorganisatie is noodzakelijk. Een echte integrale afweging is pas mogelijk als sprake is van één afdeling vergunningverlening en één afdeling handhaving, die of bij het centrale apparaat of bij het district kan worden ondergebracht. Aandachtspunten zijn dat Rijkswaterstaat is net gereorganiseerd en versnippering van kennis moet worden voorkomen. 3. Een tussenvariant. Geen reorganisatie, maar per aanvraag een projectleider/accountmanager benoemen die verantwoordelijk is voor de afstemming tussen het centrale apparaat en de districten. Aandachtspunt is dat het traject al start met vooroverleg, als er nog geen aanvraag of melding is. Het project Havik 2 valt onder het project één loket. Havik 2 heeft daarmee vele raakvlakken met de overige deelprojecten onder WilWat, bijvoorbeeld over de organisatie na de Waterwet. De manier waarop de organisatie wordt ingericht voor het behandelen van vergunningen, meldingen AMvB en het handhaven heeft invloed op de te ondersteunen processen en de toegang tot de gegevens in de ICT voorziening van Havik 2.

44


3.2.5 Overige projecten Naast de al genoemde ontwikkelingen binnen Rijkswaterstaat zijn er een groot aantal projecten die relevant zijn voor het werkveld. Deze projecten worden hier kort besproken. Ten eerste is er het project ICT op Schepen. In dit project wordt een werkplek gerealiseerd op alle patrouilleschepen van Rijkswaterstaat, inclusief de daarvoor benodigde internetverbinding. Deze internetverbinding werkt via UMTS, maar heeft een beperkte bandbreedte en ondanks dat gebruik gemaakt wordt van twee providers, is een verbinding niet gegarandeerd. In fase een van dit project wordt vanwege deze beperkingen in de verbinding, het bestaande SAP Havik niet meegenomen. Deze fase loopt tot medio 2010. In fase twee en drie moet opnieuw gekeken worden of de applicatie die voor handhaving wordt gebruikt, via ICT op Schepen beschikbaar kan worden gesteld. Havik 2 kan dan als applicatie worden bekeken. Fase drie behelst ook een geografische ontsluiting van alle gegevens die noodzakelijk zijn voor het werk op een patrouilleschip. De gegevens hiervoor worden dan dagelijks gesynchroniseerd voor het gebied dat die dag wordt bezocht. Havik 2 kan hier mogelijk op aansluiten. Een aanverwant project wat al langer loopt is de Mobiele werkplek. Dit is bedoeld als kantoorautomatiseringomgeving voor de weginspecteur in de voertuigen. Deze hebben ook taken in het werkveld van handhaving, o.a. voor de wegenverkeerswet. Er zijn echter geen applicaties specifiek gerealiseerd voor dit werkveld. Ook hier zijn problemen met de verbinding, maar er zijn wel mogelijkheden om met een client applicatie te werken. Indien Havik 2 ook gebruikt moet kunnen worden op de mobiele werkplek, zal hier rekening gehouden mee moeten worden. Als derde het project Digitaal Journaal. In de scheepvaart en begeleiding van de scheepvaart is het gebruikelijk om aan verslaglegging te doen in een logboek. Men noemt dit een scheepsjournaal, reisjournaal of journaal. Een scheepsjournaal bevat gegevens over gebeurtenissen op, in of langs de vaarweg zoals verrichte werkzaamheden, handhavingen en ondersteuning bij incidenten. Het Digitaal Journaal is een webapplicatie, die Rijkswaterstaat-medewerkers ondersteunt bij het onderhouden van het (scheeps)journaal. Het onderhouden van het journaal is onderdeel van de primaire processen die vallen onder het Verkeersmanagement Hoofdvaarwegennet en Beheer, Onderhoud en Ontwikkeling Hoofdvaarwegennet en Vlootbeheer. Onder deze primaire processen valt ook handhaving. In Digitaal Journaal worden dan ook acties ten aanzien van handhaving vastgelegd. Havik 2 kan gebruik maken van deze registratie in een eigen administratie. Het vierde project waar Havik 2 rekening mee moet houden is LIMS. LIMS staat voor Laboratorium Informatie Management Systeem en wordt gebruikt om het plannen van monsternames en de resultaten hiervan te administreren. Momenteel is Labinfos in gebruik als LIMS,

45


maar in 2009 wordt een project uitgevoerd ter vervanging hiervan. Het huidige LIMS sluit aan op WVO-Info, omdat voor de WVO vele monsters worden uitgevoerd. In het project voor een nieuw LIMS, wordt uitgegaan van dezelfde koppeling als nu wordt gebruikt voor WVO-info. Voor handhaving is LIMS een belangrijke ondersteunende applicatie. Havik 2 zal moeten kunnen samenwerken met het LIMS, zowel het huidige als het toekomstige, omdat ook in de situatie mat de waterwet monsternames belangrijk zijn voor de handhaving. WaterDataNet (WDN) is een project wat is gericht op het maken van een integrale gegevens infrastructuur voor watermanagement. Hieronder valt bijvoorbeeld gegevens over bodemhoogte en waterstanden. De monsterresultaten uit het LIMS worden uiteindelijk ook opgeslagen in de infrastructuur van WDN. Havik 2 dient voor het ontsluiten van deze gegevens aan te kunnen sluiten op WDN, met name gericht op de handhavers. Binnen Rijkswaterstaat speelt op het moment van schrijven (februari 2009) een transitie van het beheer de kantoorautomatisering en het rekencentrum van Rijkswaterstaat naar een externe partij3. De verwachting is dat deze transitie in 2009 wordt afgerond. Dat betekent voor bestaande applicaties dat deze worden overgenomen door het beheer van de externe partij. Wijzigingen in deze applicaties op korte termijn zijn daarom naar verwachting moeilijker door te voeren. In een migratietraject van het huidige ICT landschap naar een toekomst landschap dient daarom rekening te worden gehouden met deze transitie. Voor het toekomstige ICT landschap schept de transitie ook kaders ten aanzien van beheer. NIS (Netwerkmanagement Informatie Systeem) is het systeem waarin de rapportage van de PIN (Prestatie Indicator) van Rijkswaterstaat wordt gepresenteerd. Hiervoor wordt gebruik gemaakt van gegevens die van uit de primaire processen wordt verzameld met behulp van Excel sheets. De gegevens die nodig zijn voor het vaststellen van de resultaten op de PIN’s moet uit de administratie van Havik 2 betrokken kunnen worden. Indien gewenst zou het zelfs automatisch mogelijk moeten zijn om de gegevens aan te kunnen leveren. Over het proces rondom de PIN’s volgt in hoofdstuk 4 meer informatie. Binnen Rijkswaterstaat wordt voor de registratie van post het TRIM systeem gebruikt. Ingaande en uitgaande post wordt gescand, met optical character recognition, en opgeslagen. Het uiteindelijke doel is om voor heel Rijkswaterstaat een volwaardig Document Management Systeem te introduceren. Voor Havik 2 betekent dat hier een mogelijkheid is om papieren vergunningaanvragen digitaal te ontvangen. Voor het geografisch ontsluiten van verleende vergunningen zijn nu twee applicaties beschikbaar en in gebruik bij Rijkswaterstaat. Gerelateerd aan de WVO is dat ATLOZ. Voor alle wetgeving, maar in 3

Capgemini

46


de praktijk vooral de WBR is er ook het Generiek Vergunningen GIS (GVG). GVG is in staat om administratieve gegevens over vergunningen vast te leggen en documenten te koppelen. GVG gaat gebruik maken van ArcGIS 9, waarbij de gegevens in een Oracle database worden opgeslagen. De gegevens worden centraal binnen Rijkswaterstaat opgeslagen. GVG is daarmee een belangrijke applicatie voor het ontsluiten van de geografische kant van vergunningen, en ook mogelijk handhavingacties. Havik 2 kan daarom aansluiten op de gebruikte database en ontwerpen van GVG.

3.3 Afbakening Havik 2 De overheidsbrede ontwikkelingen leiden ertoe dat de druk op Rijkswaterstaat toeneemt om een open architectuur te ontwikkelen die informatie uitwisseling met collega overheden optimaal ondersteund. Om dit mogelijk te maken, zonder te veel kosten en afhankelijkheden van pakketleveranciers, moet software zo toegankelijk mogelijk zijn en dienen de koppelvlakken tussen de overheden zoveel mogelijk op elkaar afgestemd te zijn. Om dit te stimuleren worden door de Centrale overheid “generieke” voorzieningen gerealiseerd en worden ontwikkeling gestimuleerd om Open Source4 en Open Standaarden te gaan gebruiken. De overheidsbrede ontwikkelingen geven ook richting aan de inrichting van de processen van handhaving en vergunningverlening binnen Rijkswaterstaat. De schetsen die afkomstig zijn uit de NORA geven hierbij een eerste beeld over wat Havik 2 precies is en gaat zijn (zie Figuur 9). In deze figuur zijn de LVO, de basisregistraties en Havik 2 opgenomen. De LVO is hierbij onderdeel van de voorkant, oftewel de frontoffice van handhaving en vergunningverlening voor de Waterwet. Voor niet waterwetvergunningen zal RWS een frontoffice moeten inrichten. De klant moet daarbij uit kunnen gaan van one-doorshopping. Dit vereist dus afstemming tussen de Rijkswaterstaat en LVO-frontoffices. Een groot deel van de achterkant met de gegevensopslag bestaat uit de basisregistraties die zorgen voor de juiste NAW gegevens van bedrijven en burgers. De midoffice, die de frontoffice en de gegevensopslag koppelt, samen met de eigen gegevensopslag, is daarmee Havik 2.

4

www.ososs.nl

47


E lektronis c he overheid op termijn G emeens c happelijke e n gekoppelde frontoffice en backoffice voorzie ningen

D ig iD (e)‐NIK /P K I

onderlinge gegevens uitwis s eling binne n de e‐overheid

B as is ‐ regis traties

B edrijven

OV E R HE ID S P OR TA L / OR G A N IS A T IE P OR TA L verwijzer (links )

BS N

Noord‐NL

TOP ‐kaart

Oos t‐NL gebouwen

informa tie e‐formulier

LVO

Noord‐ B rabant

pers onen

IJ s s e lm.gebie d

adres s en

L imburg

K adas ter

H avik II

inkomens

zoekmac hine

burger

vrage nboom aanvraagmodule behandeldos s ier

B IN bedrijf

attenderings s ervice

. . . . D ig iD P KI

Ove rheids tra ns actie poort

Noord‐ Holla nd

S chepen Waterdiens t auto's Ove rige

koppeling aan gemeens chappelijk fro nt office

etc. s ervicebus (s e n)

Figuur 9 Beschouwingsgebied Havik 2 De centrale vraag voor Havik 2 is op welke wijze de midoffice haar taak kan vervullen als intermediair tussen frontoffice en backoffice, op het gebied van handhaving en vergunningverlening. Havik 2 is dus niet de LVO. Havik 2 dient wel eisen te stellen aan LVO ten aanzien van de benodigde gegevens en de manier waarop deze worden verzonden naar Havik 2. Havik 2 is dus ook niet de basisregistraties, maar dient wel te weten welke basisregistraties er zijn en op welke manier er gegevens uitgewisseld en opgevraagd kunnen worden. Havik 2 is wel een loket voor de vergunningen (of meldingen) die niet via de LVO kunnen worden aangevraagd bij Rijkswaterstaat als bevoegd gezag. Dit zijn dus drie belangrijke koppelvlakken voor Havik 2. Havik 2 behelst verder het werkveld van vergunningverlening en handhaving zoals dat onder de waterwet komt te vallen. Daarmee worden dus bestaande vergunningen zoals onder de WVO of de WBR meegenomen in Havik 2. De systemen die nu gebruikt worden voor de front-, miden backoffice voor vergunningverlening en handhaving ondersteunen echter de administratie van meerdere wetten. Deze wetten worden in de scope van Havik 2 meegenomen. Het gaat dan om de volgende wetgeving (die niet in de Waterwet worden opgenomen): • Wegen Verkeer Wet; • Scheepvaart Verkeer Wet (Binnenvaartwet);

48


• Ontgrondingen Wet; • Wet Beheer Rijkswaterstaatswerken (droog); Specifiek voor deze wetgeving zal een eigen loket moeten worden gemaakt. Daarnaast worden een aantal Algemene Maatregelen van Bestuur meegenomen waar Rijkswaterstaat het bevoegd gezag voor is en wordt: • Besluit Bodemkwaliteit; • Activiteitenbesluit; • Lozingenbesluit open teelt en veehouderij; • Lozingenbesluit vaste objecten • Besluit Afvalwater Huishoudens • Waterbesluit. De definitiestudie van Havik 2 focust op de ICT voorziening die nodig is voor het werkveld van handhaving en vergunningverlening. Vanwege de afhankelijkheden tussen ICT, organisatie (en processen) en informatie en gegevens, wordt in deze definitiestudie wel aandacht besteed aan deze aspecten. Immers, het slagen van een ICT voorziening is afhankelijk van de aansluiting op de organisatie, de processen en de beschikbaarheid en kwaliteit van gegevens.

3.4 Contextdiagram

Provincie

Waterschap

r/

Ha ndhaver

Havik 2

Ministerie van V&W

Ministerie van LNV

Hulpverleners

i er r/ st n n sie e o at os t m l d s Be e su ng ni R un a tie g n r ne Ve form la n -in g sp n i e r ge s vo Ui t porta p a r Vergunninginfo es inspectiera pportag

Rapportage richtlijnen Ve r g Ha n unning d ha i ving nfo V er R info i n f g unn ric a p orm ing ht po a ti lij rta e ne g n e

Ministerie van Justitie

Ministerie van AZ

Figuur 10 Contextdiagram

49

Rijkswaterstaat

IVW

Europese unie

Handhaving

-

Ministerie van VROM

Laboratorium

ng

i ng nn rgu Ve o inf roe p Be

Frontoffice Vervoer over Water

ie r/ ingsd o ss Ve rgunn e ti informa en n/be sl uit a a nvra ge r/ ie s s gsd o in n ge n u rta V e rg a ti e po ne n m r o p f j in Ra htli ric

Rapportage richtlijnen

Gemeente

R ric a pp ht or lij ta ne ge n

Omgevings dienst

Ve r g -i nf unni n orm g a ti e sd o s sie

lo in z in fo gs rm at ie Ve inf rgun orm ni a ti ngsd e os sie Ve r r g un i nfo ni n gsd rm a o ss ti e ie r/ Ve rgun ningsd o ssi e r/ inform a ti a a nvra e ge n/be sl uite n

n Verleende vergunninge

n nvra ge e n g ning a a ve rgun ge s voor loz in a ra pport n ge m e ldin sluite n ning be ve rgun n ge vra an ga te n ni n l ui un ge n be s rg ve ldin ning me rgun ve

BVR

Basisregistraties

Pers

Bedrijf

Burger


Vergunningverlening

De Havik 2 administratie wordt gebruikt voor handhaving en vergunningverlening. Dat betekent dat er een groot aantal koppelvlakken is met de buitenwereld, die kunnen bestaan uit personen, instanties of systemen. Deze context van het werkveld en de gegevens wordt globaal weergegeven in Figuur 10met een toelichting in bijlage 14.2. In het diagram wordt uitgegaan van de gegevensuitwisselingen die er zijn vanuit de gegevens die benodigd of beschikbaar zijn in Havik 2. Om te beginnen met een burger en een bedrijf is er gegevensuitwisseling over de vergunningaanvraag, een melding voor een AMvB. Vanuit de Havik 2 administratie volgt (na behandeling) een beschikking in de vorm van een vergunning. Voor bedrijven geldt vaak ook dat ze rapportages over lozingen jaarlijks moeten indienen. Met andere bevoegd gezagen (bijvoorbeeld gemeente, provincie, waterschap) moeten gegevens worden uitgewisseld over verleende vergunningen, ontvangen en geregistreerde meldingen en over aanvragen waarbij er samenloop is van meerdere bevoegd gezagen. Ook een mogelijke omgevingsdienst voor de omgevingsvergunning kan hier een rol in hebben. De ministeries in het diagram hebben vooral een rol als wetgever in het opstellen van richtlijnen, voor bijvoorbeeld rapportages over lozingen of het invullen van de procedures rond de Algemene Wet Bestuursrecht. Het Ministerie van Justitie is echter ook afnemer van gegevens in het geval van strafrechtelijk optreden bij overtredingen van de vergunningen. Ook de Europese Unie speelt een belangrijke rol ten aanzien van richtlijnen en verlangt rapportages. Een andere afnemer van de gegevens is het Bureau Verontreinigingsheffing Rijkswateren (BVR) wat verantwoordelijk is voor het opleggen van de aanslag inzake de heffingen voor de WVO. Hiervoor zijn de lozingsrapportages benodigd. Ook de pers en hulpverleners zijn afnemers van de gegevens uit Havik 2. In bepaalde gevallen zullen deze geïnteresseerd zijn in de verleende vergunningen. De Inspectie Verkeer en Waterstaat (IVW) is behalve afnemer van de vergunningsinformatie ook een instantie die van invloed is op de administratie. Immers voor vergunningen van eigen werk voor Rijkswaterstaat is de Inspectie de eindverantwoordelijke voor het verlenen van de vergunning. IVW heeft deze taak echter neergelegd bij Rijkswaterstaat en houdt hier toezicht op. Rijkswaterstaat is zelf ook een belangrijke partij, omdat o.a. de plannen voor handhaving en vergunningverlening van invloed zijn op de manier waarop gewerkt wordt en welke gegevens worden vastgelegd in de administratie. Blijven als laatste partijen de handhavers en vergunningverleners over. Zij zijn verantwoordelijk voor het daadwerkelijk behandelen van de aanvraag en controleren op een juiste uitvoering van de activiteiten volgens de verleende vergunning of ontvangen en geregistreerde

50


melding. Hiermee zijn zij de belangrijkste partijen in het creëren van de gegevens in de administratie van Havik 2. Zij zijn verantwoordelijk voor de kwaliteit van de gegevens.

51


4 Globale procesinventarisatie IST 4.1 Inleiding Rijkswaterstaat levert een belangrijke bijdrage bij de uitvoering van verschillende wettelijke taken van de overheid. Vergunningverlening en handhaving zijn daar enkele voorbeelden van. Om de taken uit te kunnen voeren, én te kunnen herhalen zijn processen ontworpen. Alhoewel op detailniveau de uitvoering in de praktijk afwijkt, zijn de primaire processen binnen Rijkswaterstaat op uniforme wijze beschreven, de Uniforme Primaire Processen5. Om de processen uit te kunnen voeren, is informatie nodig. Deze informatie moet op de een of andere wijze, op het juiste tijdstip, in de juiste vorm en in de juiste kwaliteit beschikbaar zijn. Om dat te bewerkstelligen kunnen ICTvoorzieningen worden ingezet. De processen zijn daarmee bepalend voor wanneer ICT-voorzieningen kunnen worden ingezet en voor de wijze waarop de informatievoorziening wordt ingericht. Daarom is in de definitiestudiefase van Havik 2 naar de processen gekeken en zijn de medewerkers die de relevante processen uitvoeren betrokken geweest bij de totstandkoming van de eisen die gesteld zijn aan de ICTondersteuning voor de toekomstige situatie. In dit hoofdstuk is de beschrijving van de processen beperkt tot een globaal niveau. In dit hoofdstuk worden eerst de gebruikte procesniveaus en procestypen beschreven. Deze beschrijving geeft houvast voor een onderscheid tussen de primaire processen waarvoor een ICT voorziening wordt gemaakt en andersoortige processen. In paragraaf 4.3 wordt beschreven waarom UPP niet overal toereikend is als basis voor de te onderzoeken processen. Hierna volgt in paragraaf 4.4 een beschrijving van de vier processen die zijn onderzocht. Het hoofdstuk sluit af met bevindingen ten aanzien van de onderzochte processen. In het volgende hoofdstuk komt dit allemaal samen in een globaal procesontwerp voor de nieuwe situatie.

4.2 Procesniveau en procestype De processen zijn bepalend voor de informatiebehoefte die door ICTvoorzieningen zoveel mogelijk moet worden ingevuld. Processen kunnen echter op verschillende niveaus worden beschouwd. Om processen te modelleren en typeren worden verschillende methoden en technieken toegepast. Binnen de NORA wordt uitgegaan van een proceshiërarchie. Daarbij is sprake van een ketenproces op het hoogste beschouwingsniveau. De procesvoering wordt in de NORA verder gedecomponeerd in achtereenvolgens bedrijfsprocessen, werkprocessen, processtappen en in het laagste niveau in handelingen.

5

De UPP beschrijvingen zijn te vinden via http;//intranet.rws.nl/ via ‘Processen RWS in Aris’

52


Ketenproces

bedrijfsproces

Werkproces

Processtap

Handeling

bedrijfsproces

bedrijfsproces

Werkproces

Processtap

Handeling

Werkproces

Processtap

Handeling

Figuur 11 Ordening van processen (NORA) In het kader van de ontwikkeling van de ICT-ondersteuning voor de processen die Havik 2 gaat ondersteunen is het voldoende voor de definitiestudiefase om aandacht te schenken aan de verschillende bedrijfsprocessen en de werkprocessen. Hierbij ligt de nadruk op het ontwikkelen van een schets van de toekomstige applicatie architectuur. De processtappen en handelingen zijn voor de doelstelling van de definitiestudiefase nog van ondergeschikt belang. Ketenprocessen zijn relevant omdat bij vergunningverlening én bij handhaving sprake is van processen waarbij meer dan één organisatie bij betrokken is.

Figuur 12 Procestypen De verschillende bedrijfsprocessen en werkprocessen binnen Rijkswaterstaat kunnen van elkaar worden onderscheiden door deze te ordenen naar verschillende soorten procestypen. Met het begrip procestypering wordt in dit verband bedoeld een karakterisering te geven van de essentie van het betreffende proces. Het weergegeven model (zie Figuur 12), toont de zes procestypen die worden onderscheiden. Het is dit model dat primair zal worden gebruikt voor

53


het ordenen van de verschillende bedrijfsprocessen en werkprocessen binnen het aandachtsgebied van Havik 2 van Rijkswaterstaat en daarmee ook van de sterk met deze processen samenhangende informatievoorziening. De zes in het model onderscheiden procestypen kunnen als volgt worden beschreven: Procestypen Besturende processen

Omschrijving Processen waarvan de essentie is gelegen in het aansturen van de Rijkswaterstaat organisatie en haar bedrijfsvoering, het opstellen van rapportages en planning. Processen waarbij de ontwikkeling van (ver)nieuw(d) beleid en uit te voeren onderzoek in dat verband, centraal staat (zoals het opstellen beleidsvoorstellen). Processen waarvan de essentie is het voortbrengen van een of meerdere diensten die tot de kernactiviteiten van Rijkswaterstaat in het aandachtsgebied van Havik 2 worden gerekend (zoals vergunningen verlenen en handhaven).

Relatie met UPP UPP noemt dit sturende processen.

Dienstverlenende processen

Processen waarbinnen klantinteractie (inclusief de levering van producten) via diverse kanalen centraal staat (zoals verstrekken van informatie en het afhandelen van klachten)

UPP maakt dit onderscheid niet maar noemt dit primair proces.

Ondersteunende processen

Processen die de uitvoering van de andere procestypen mede mogelijk maken door het voortbrengen en leveren van interne producten en diensten (zoals financiële, facilitaire zaken, personeelszaken en ICT beheer). Processen waarbij (primaire) processen gekoppeld zijn aan processen van derden en die een significante rol spelen bij het verlenen van diensten door Rijkswaterstaat en/of een andere instelling.

UPP noemt dit ook ondersteunende processen.

Beleidsvormende processen Primaire processen

Ketenprocessen

UPP noemt dit ook sturende processen UPP noemt dit ook primaire processen..

UPP kent geen ketenprocessen.

Tabel 1 Omschrijving procestypen

4.3 Afwijking van UPP De processen Handhaving, Vergunningverlening en Meldingen (voor een Algemene Maatregel van Bestuur) worden zelf niet ontworpen binnen deze definitiestudie voor Havik 2. De beschrijvingen van UPP zijn de basis geweest voor de bepaling van de informatiebehoefte ten behoeve van Havik 2. De UPP-beschrijvingen zijn echter op een hoog abstractieniveau beschreven (op niveau van keten- en bedrijfsprocessen), waardoor ze breed toepasbaar zijn. Op verschillende aspecten zijn de beschrijvingen van UPP ook nog niet afgestemd op het beschouwingsgebied voor wat betreft de wetgeving en bijbehorende processen, zoals: • de processen rondom de meldingen in het kader van AMvB’s waarbij Rijkswaterstaat bevoegd gezag is zoals het Activiteitenbesluit komen binnen de UPP nog niet voor; • veel dienstverlenende processen ontbreken in UPP zoals het (wettelijk verplicht) rapporteren van milieu-informatie; • de processen rondom adviesrol en de benodigde registraties worden niet in UPP uitgewerkt.

54


•

de besturende processen zijn beperkt uitgewerkt in UPPbeschrijvingen.

Binnen de definitiestudie wordt daarom waar mogelijk gebruik gemaakt van UPP. Waar de UPP geen beschrijvingen geeft, is in het project gebruik gemaakt van overige beschrijvingen, werkinstructies en vergelijkbare processen.

4.4 Huidige processen (IST) Er worden vier processen onderkend: • verlenen van een vergunning (§4.4.1) • behandelen van meldingen (§4.4.2) • handhaven (§4.4.3) • plannen, sturen en rapporteren (§4.4.4) Hierbij zijn de eerste drie processen primair waarbij Rijkswaterstaat het bevoegd gezag is voor bepaalde wetgeving. Deze drie zijn echter ook dienstverlenend en ketenproces volgens Figuur 12. Het vierde proces plannen, sturen en rapporteren valt onder de noemer van besturende processen. De ondersteunende processen die in alle drie de gevallen noodzakelijk zijn worden per proces apart genoemd. Per proces, en dan met name bij het verlenen van vergunningen en behandelen van meldingen meerdere invullingen mogelijk. Deze worden daarbij behandeld. NB: Omdat er zoveel mogelijk gebruik is gemaakt van bestaande modellen of beschrijvingen, zijn de beschrijvingen in verschillende tekenschema’s opgenomen.

4.4.1 Verlenen van een vergunning Voor de huidige situatie zijn de UPP-beschrijvingen van toepassing op het proces van vergunningverlening. Zoals al geconstateerd zijn de UPP-beschrijvingen op een abstract niveau. Hierdoor vinden op hoofdlijnen wel overeenkomstige processtappen plaats voor de verschillende vergunningen (op basis van verschillende weten regelgeving), waarbij voor sommige vergunningen stappen kunnen worden overgeslagen. Een aggregatieniveau dieper ontstaan verschillen op gebied van doorlooptijd (verschillende AWB-termijnen), (inhoudelijke) behandeling, documentuitwisseling en archivering. In UPP zijn deze verschillen niet gedocumenteerd. Naast de UPP zijn verschillende werkinstructies en procedures gebruikt, die geënt zijn op de milieuwetgeving waarbij Rijkswaterstaat het bevoegd gezag is. UPP beschrijft het proces van het verlenen van een vergunning in twee stappen (zie Figuur 13). Er wordt in feite begonnen met het ‘Voorbereiden afhandelen vergunningaanvraag’. Daarna wordt een keuze gemaakt in de te volgen procedure van de Awb. Dit is ofwel de Artikel 3.4 procedure ofwel de Artikel 4.1 procedure. De Artikel 3.4 procedure is hierbij uitgebreider dan de 4.1 procedure vanwege de noodzaak tot het publiceren van een ontwerp-besluit en het verwerken van eventuele zienswijzen. Bij de Artikel 4.1 procedure is er geen verplichting tot het publiceren van een ontwerp-besluit, maar alleen

55


voor een definitief besluit. In beide gevallen eindigt de procedure met het ‘Operationeel voorbereiden handhaven’ uit het proces handhaven en/of ‘Procesvoering, incl. bezwaar en beroep’.

Figuur 13: Verlenen vergunning (UPP) In de processtap ‘voorbereiden afhandelen vergunningaanvraag’ is beschreven hoe de voorbereiding plaatsvindt. Dat begint met een vooroverleg. Indien daarna een aanvraag volgt, kan deze worden gedigitaliseerd (indien nodig) en gekoppeld aan een zaak of dossier. Een zaak is hierbij een specifieke vergunningaanvraag, en een dossier is een verzameling van zaken gekoppeld aan één relatie. Na het bepalen van de behandelend ambtenaar wordt bepaald of leges zijn verschuldigd. Na eventuele ontvangst van leges volgt een controle op volledigheid van de aanvraag. Bij een volledige aanvraag wordt de juiste Awb procedure gestart en begint de inhoudelijke behandeling. Volgens de UPP wordt een aanvraag bij niet tijdige betaling van leges of een onvolledige aanvraag deze buiten behandeling gesteld. In de afhandeling van de aanvraag wordt het inhoudelijke beoordelen van de aanvraag gedaan. Hierin vindt afstemming plaats met (technische) adviseurs. Nadat een concept-(ontwerp)besluit is opgesteld wordt een handhaafbaarheidstoets uitgevoerd en verwerkt in een definitief besluit. Indien er op het definitieve besluit bezwaar en/of beroep wordt ontvangen, wordt een nieuw proces ‘procesvoering’ opgestart. Dit is geen onderdeel van het verlenen van een vergunning. Het verlenen van een vergunning volgens een formele aanvraag is echter niet het enige wat in het werkveld van vergunningverlening voor komt. Ook het (ambtshalve) wijzigen van vergunningen, intrekken en

56


bezien van vergunningen evenals het opstellen van gedoogbeschikkingen maakt hier onderdeel van uit. In de workshops met de professionals zijn globaal de volgende vijf stappen gedefinieerd, gericht op het hoofdproces van vergunningverlening (zie Schema 1): 1. Oriënteren; 2. Ontvangen; 3. Behandelen; 4. Besluiten; 5. Publiceren. Primair proces verlenen van vergunning

Een klant oriënteert zich of een vergunning noodzakelijk is voor de voorgenomen werken en indien noodzakelijk vraagt hij vooroverleg aan bij de juiste regionale dienst. Als kan worden volstaan met het doen van een melding, wordt een melding opgesteld en aan de Regionale dienst verstuurd. Indien een vergunningaanvraag noodzakelijk blijkt, stelt de vergunningaanvrager zijn aanvraag op en biedt deze aan de Regionale dienst aan die bevoegd gezag is in het gebied waar de uit te voeren werken plaats zullen vinden. Het aanbieden van de aanvraag vindt plaats op de wijze die specifiek voor een vergunningtype is vastgesteld. De Regionale dienst ontvangt de vergunningaanvraag en weet op welke wet de vergunningaanvraag betrekking heeft. De medewerker van vergunningverlening met voldoende capaciteit neemt de aanvraag in behandeling en maakt een concept-(ontwerp)besluit aan. Indien aan alle voorwaarden is voldaan wordt een definitieve vergunning opgesteld en gecommuniceerd en gepubliceerd. Na publicatie worden het proces van handhaving en/of procesvoering opgestart. Ondersteunende werkprocessen Vaststellen en innen leges

Voor een vergunningaanvraag die betrekking heeft op een vergunningtype waarvoor leges betaald moeten worden, wordt een proces gestart om leges vast te stellen en zorg te dragen dat de leges daadwerkelijk betaald worden door de vergunningaanvrager.

Heffen en innen van de heffing t.g.v. vergunning.

Voor een vergunning die betrekking heeft op een vergunningtype waarvoor heffing (bijv. bij lozingen op het oppervlakte water) betaald moeten worden, wordt de hoogte van de heffing bepaald, de aanslag vastgesteld en geïnd.

Beheren relatiegegevens

Bij communicatie via elektronische weg, moet per vergunningtype een administratie beheerd worden i.v.m. authenticatie en identificatie van klanten die via elektronische weg een vergunningaanvraag indienen.

Beheren areaalgegevens

Vergunningen worden verleend door het bevoegd gezag van een bepaald gebied. Hiervoor is het noodzakelijk dat het juiste gebied in de administratie bekend is. Daarnaast worden vergunningen geregistreerd aan de hand van bekende naamgeving van het gebied van het bevoegd gezag (het areaal).

Verkrijgen technisch advies

Indien een vergunningaanvraag een technisch advies behoeft van een externe partij dient er een informatie uitwisseling plaats te vinden.

Procesvoering bezwaar en beroep

Indien na publicatie een bezwaar of beroep wordt ontvangen op de beschikking, dient het proces van procesvoering opgestart te worden waarin het beroep en/of bezwaar wordt behandeld.

Schema 1 Verlenen van vergunningen

57


Uit de workshops bleek dat met name in de eerste fase, het ‘oriënteren’ veel tijd moet worden gestoken. Hierin wordt veel besteed aan het juist informeren van de klant over de mogelijke aanvraag. Door de professionals is aangegeven dat juist in deze fase al veel werk wordt gedaan, zodat zodra een formele aanvraag voor een vergunning wordt ontvangen, de termijn eenvoudig kan worden gehaald omdat zowel de klant als het bevoegd gezag op de hoogte zijn van de aanvraag en de te nemen stappen. Tijdens het oriënteren kan ook door het bevoegd gezag rekening worden gehouden met de inzet van medewerkers voor het behandelen. Ook hier is het einde van het proces weer een verleende vergunningen, wat aanleiding is voor ofwel het opstarten van het proces handhaving, ofwel van het proces procesvoering bezwaar en beroep. Het proces handhaving wordt beschreven in paragraaf 4.4.3. 4.4.2 Behandelen van meldingen AmvB Het verlenen van een vergunning is in deze paragraaf als uitgangspunt genomen. Het behandelen van een melding maakt op hoofdlijnen gebruik van dezelfde processtappen, maar zal ook hier stappen overslaan waar nodig, afhankelijk van het type meding. Het proces van het behandelen van een melding is echter niet als zodanig beschreven in UPP. Hierdoor is er geen eenduidig beeld van de stappen die doorlopen moeten worden, terwijl Rijkswaterstaat als bevoegd gezag voor het Besluit Bodemkwaliteit al wel meldingen ontvangt, registreert en handhaaft. Daarom wordt gebruik gemaakt van de vijf stappen die ook zijn gebruikt voor het proces van vergunningverlenen uit de workshops (zie Schema 2): 1. Oriënteren; 2. Ontvangen; 3. Behandelen; 4. Besluiten; 5. Publiceren. Ook in het proces van het behandelen van meldingen is het oriënteren een belangrijke fase, omdat hier de klant duidelijk gemaakt kan worden of een melding volstaat, en aan welke indieningsvereisten deze moeten voldoen. Voor het bevoegd gezag wordt het dan ook duidelijk welke weten regelgeving van toepassing is en kan worden gekeken naar de noodzaak voor eventuele maatwerkvoorschriften. Tijdens het oriënteren kan ook door het bevoegd gezag rekening worden gehouden met de inzet van medewerkers voor het behandelen. In de meeste gevallen zal het behandelen van een melding niet of nauwelijks afwijken van het behandelen van een vergunningaanvraag, afgezien van de eventuele duur van deze processtap. Besluiten is bij meldingen over het algemeen niet noodzakelijk, omdat het besluit tot het toestaan van bepaalde activiteiten al in de Algemene Maatregel van Bestuur is genomen. Alleen voor maatwerkvoorschriften moet een besluit worden genomen. Publiceren is in alle gevallen van toepassing, maar verschilt per type melding.

58


Primair proces Behandelen van meldingen AMvB

Als gevolg van de inwerkingtreding van het “Besluit algemene regels voor inrichtingen milieubeheer” vervalt een aantal vergunningverplichtingen en kunnen bedrijven volstaan met het melden van hun activiteiten aan het bevoegd gezag.Ook voor andere wetgeving zoals het Besluit Bodemkwaliteit worden door Rijkswaterstaat meldingen ontvangen. Een bedrijf of burger oriënteert zich of een vergunning of meldingprocedure moet worden gestart. Indien een melding voldoende is voor de activiteit, wordt via een (digitaal) loket een melding aan het bevoegd gezag gestuurd. Indien de melding voldoet aan alle voorschriften wordt de melding geregistreerd en wordt het handhavingproces opgestart. Indien er maatwerkvoorschriften worden toegepast door het bevoegd gezag is een behandeling en beschikking noodzakelijk, evenals publicatie. De laatste drie onderdelen uit het globale vergunningverleningproces zijn hier min of meer optioneel. Het einde van het proces (afhankelijk van het type vergunningen) betekent dat het proces van handhaving en/of procesvoering beroep en bezwaar wordt opgestart. Ondersteunende werkprocessen Beheren relatiegegevens

Bij communicatie via elektronische weg, moet per vergunningtype een administratie beheerd worden i.v.m. authenticatie en identificatie van klanten die via elektronische weg een vergunningaanvraag indienen.


Indien na publicatie een bezwaar of beroep wordt ontvangen op de beschikking, dient het proces van procesvoering opgestart te worden waarin het beroep en/of bezwaar wordt behandeld.

Schema 2 Behandelen van meldingen AMvB 4.4.3 Handhaven Voor de huidige situatie zijn de UPP-beschrijvingen van toepassing op de handhavingprocessen. De UPP-beschrijvingen zijn op een hoog abstractieniveau beschreven (bedrijfsprocesniveau), waardoor ze ook breed toepasbaar zijn. Bij het proces vanuit UPP zijn er vier stappen (zie Figuur 14), te beginnen met ‘Operationeel voorbereiden handhaven’. Hierin worden de handhavingsuitvoeringsplannen en toezichtsplannen gemaakt op basis van o.a. risico analyses. Dit is een van de aanleidingen voor het starten van de overige drie stappen, waarbij ‘Houden van toezicht’ o.a. het toezichtsbezoek omvat. In UPP vindt hier het constateren van overtredingen plaats en kan worden gekozen voor het ‘Inzetten van sanctiemiddelen’. Hierin worden de verschillende mogelijkheden tot sanctie afgewogen en ingezet. Mogelijk wordt ook het risicioprofiel of toezichtsplan hierop aangepast. Overkoepelend over de voorgaande stappen is er het ‘Monitoren kwaliteit en prestatie handhaving’. Hierin worden de periodieke rapportages gemaakt en worden interne en externe audits gehouden.

59


Figuur 14 Handhaven (UPP) Naast UPP is door het project ‘Digitale Handhaving’ het proces van handhaving in kaart gebracht (zie Figuur 15). In dit project is een ander, meer gedetailleerd, abstractieniveau gebruikt. Monitoring Voorbereiden

Plannen

Constateren Beoordelen Interveniëren Voortgangsbewaking

Verbeteren

Programmeren

Nazorg

Verantwoorden

Figuur 15 Proces handhaven (Digitale Handhaving) Handhaving bestaat in z´n kern uit drie processen: Constateren, Beoordelen en Interveniëren. Randvoorwaardelijk voor de uitvoering van deze kernprocessen (groen) worden acht generieke processen onderkend. Vier generieke processen richten zich op de correcte uitvoering van individuele cases (geel). Nog eens vier generieke

60


processen richten zich op de wijze waarop de onderliggende deelprocessen worden uitgevoerd (blauw). Het startpunt voor handhaving is een geplande inspectie uit de E-MJV, toekomstige EPRTR6 en BRZO7 inspecties, een verleende vergunning, een waarneming gedurende een schouw of een calamiteit/incident. De deelprocessen Plannen, Programmeren, Monitoring en Verbeteren en Verantwoorden zijn, afhankelijk van het niveau, jaarlijkse, maandelijkse en/of dagelijks terugkerende bezigheden. Deze deelprocessen zorgen ervoor dat het handhavingproces plaatsvindt binnen de kaders van de jaarplannen (HUP). De deelprocessen Voorbereiden, Constateren, en Beoordelen worden doorlopen op basis van een controlerapport. het deelproces Interveniëren wordt gestart als op basis van het controlerapport besloten wordt om een bestuursrechtelijk sanctioneringtraject te starten. De resultaten van alle doorlopen deelprocessen worden in het deelproces Nazorg geordend opgenomen in een dossier en gearchiveerd. Voortgangsbewaking moet op zaakniveau leiden tot een correcte afhandeling van een zaak. Verbeteren betreft de kwaliteitszorg over het totaal van alle zaken, om te komen tot een efficiënter en effectiever handhavingproces. Hierbinnen wordt de afgesproken kwaliteit gecontroleerd en geborgd. Belangrijk in zowel de beschrijving van de UPP en Digitale Handhaving is dat de werkprocessen geen eenheid hebben van tijd, plaats en handeling. Immers het plannen en programmeren van handhavingsbezoeken heeft een hele andere scope dan bijvoorbeeld constateren en interveniëren. Daarom is er voor gekozen om in de workshops met de professionals globaal de volgende vijf stappen te gebruiken, waaraan ondersteunde processen kunnen worden gekoppeld (zie Schema 3). Het gaat hierbij om de volgende stappen: 1. Voorbereiden; 2. Constateren; 3. Beoordelen; 4. Interveniëren; 5. Verslaglegging/Nazorg. De processen van plannen, sturen en rapporteren worden behandeld in paragraaf 4.4.4.

6

European Pollutant Release Transfer Register verordening (E-PRTR)

7

Het Besluit risico's zware ongevallen 1999 is de Nederlandse implementatie van de

Europese Seveso II-richtlijn.

61


Primair proces Handhaven

Op basis van o.a. monitoring-, realisatierapportages en risicoanalyses worden per dienst handhavings- en toezichtsplannen (Handhavings-UitvoeringsPlannen ofwel HUP’s) opgesteld. Het geplande toezicht wordt uitgevoerd, maar ook ongepland kan eeninspectie plaatsvinden of schouw worden uitgevoerd. Constateringen worden beoordeeld waarvan een verslag wordt opgesteld. Indien noodzakelijk worden zowel bij een gepland als ongepland toezicht monsters genomen en doorgezonden naar het laboratorium voor nader onderzoek. Resultaten van monsters worden in een verslag vastgelegd. Indien noodzakelijk worden meldingen gemaakt van overtredingen en zal waar nodig interventie of een legalisatietoets plaatsvinden (waarbij het proces vergunningverlening wordt opgestart). In het geval van interventie wordt een sanctiespoor afgewogen en uitgevoerd wat kan resulteren in bijvoorbeeld een waarschuwing, dwangsom of proces-verbaal. Ondersteunende werkprocessen Laboratorium onderzoek

Monsters die tijdens de inspecties worden genomen, worden onderzocht. De resultaten van het laboratorium onderzoek, worden gemeld aan de handhaving.

Verstrekken van informatie

Ten behoeve van de handhaver is het noodzakelijk om actuele informatie over weten regelgeving, checklists, vergunningen, gedoogbesluiten, maatwerkbeslissingen ter beschikking te stellen.

Beheren relatiegegevens

Ook bij handhaving dienen de juiste relatiegegevens beschikbaar te zijn voor het communiceren met de klanten over zaken betreffende de vergunningen en meldingen.


Indien na het interveniëren beroep of bezwaar wordt ontvangen op de beschikking, dient het proces van procesvoering opgestart te worden waarin het beroep en/of bezwaar wordt behandeld.

Schema 3: Handhaven 4.4.4 Plannen, sturen en rapporteren Ten behoeve van het uitvoeren van de primaire processen van handhaving en vergunningverlening (waaronder ook de meldingen vallen) wordt door Rijkswaterstaat gepland, gestuurd en gerapporteerd. In UPP zijn deze processen niet als zodanig terug te vinden. In het proces van handhaving komt het maken van plannen en het rapporteren wel terug. Daarnaast blijkt ook uit de gesprekken en workshops met professionals uit het veld dat vooral voor handhaving (en dan met name voor milieu gerelateerde wetgeving) het plannen en rapporteren verder is uitgekristaliseerd. Voor vergunningverlening is er minder invulling gegeven aan het plannen, sturen en rapporteren. Dit is mede het gevolg van het Besluit Kwaliteitseisen Wet milieubeheer. Daarnaast is het voor het verlenen van een vergunning lastig om vooraf te plannen hoeveel aanvragen of meldingen er worden ontvangen op jaarbasis, zodat daar moeilijk een planning van gemaakt kan worden.

62


Inmiddels worden er wel voor zowel handhaving als voor vergunningverlening jaarplannen opgesteld. Voor de handhaving zijn dat de HUP’s (Handhaving Uitvoerings Programma) en voor vergunningverlening zijn dat JUP’s (Jaar Uitvoerings Programma). Beide zijn landelijk. Het proces van het opstellen van de HUP en JUP is op hoofdlijnen vergelijkbaar. In beide gevallen wordt een ideaalplanning opgesteld waarna op basis van prioritering een definitieve planning wordt vastgesteld. Bij het opstellen van het HUP wordt vooraf aan het opstellen van de ideaalplanning een risico analyse uitgevoerd waarin per branche wordt gekeken naar risico’s, de zogenaamde RiAnTH sessies. De HUP en JUP worden vastgelegd in de management contracten met de regionale diensten. Bij zowel handhaving als vergunningverlening is het vervolgens mogelijk om op de uitvoering van het programma te sturen. In praktijk blijkt dit een divers proces, waarbij per regio en district verschillende invulling aan wordt gegeven. Er is geen eenduidige werkwijze afgesproken binnen Rijkswaterstaat over de uitvoering van de afgesproken programma’s. Voor de rapportage geldt dat ook in de management contracten afspraken worden gemaakt, de zogenaamde PIN’s (prestatieindicatoren). Op basis van de PIN’s houden de diensten van Rijkswaterstaat zicht op de voortgang van hun prestatieafspraken. Drie keer in een contractjaar melden de diensten de voortgang. Voor vergunningverlening is de PIN: Vergunning zijn binnen de wettelijke termijn afgerond en bezien. Voor handhaving betreft de PIN van 2008: Gerealiseerd toezicht ten opzichte van geprogrammeerd toezicht. Voor 2009 is deze aangescherpt zodat het binnen de termijn beoordelen, categoriseren en registreren van meldingen wordt meegenomen in de PIN van handhaving. De diensten van Rijkswaterstaat ontvangen voor deze rapportage elk trimester een invulsheet waarbij de benodigde gegevens kunnen worden ingevuld. De resultaten worden uiteindelijk in NIS gepresenteerd.

4.5 Bevindingen huidige processen Met betrekking tot de huidige processen is een aantal zaken geconstateerd. Deze worden hieronder gepresenteerd. 1. Tijdens gesprekken en workshops is regelmatig aan de orde gekomen, dat per regionale dienst en district de processen kunnen afwijken van de UPP-beschrijving. Zo heeft niet elk gebied te maken met de Noordzee, of bepaalde vormen van industrie waardoor andere gegevens of processen noodzakelijk zijn. Ook organisatorisch zijn er verschillen, waardoor de processen verschillend zijn. Omdat processen op verschillende wijze worden uitgevoerd, ontstaat er verschil in inzicht over de wijze waarop de ondersteuning door ICT moet worden gerealiseerd. Deze verschillen tussen theorie (UPP & Digitale Handhaving) en praktijk hebben ertoe geleid dat reeds gerealiseerde ICT-voorzieningen in het geheel niet of

63


2.

3.

4.

5.

6.

7.

64

verschillend gebruikt worden. Dit heeft gevolgen voor de kwaliteit van de gegevens in de ICT-voorzieningen. Binnen Rijkswaterstaat wordt het uniform uitvoeren van de bestaande beschreven processen (UPP) niet afgedwongen. Er is geen controle op een juiste uitvoering, waardoor verschillende invullingen van de primaire processen mogelijk zijn. De UPP zijn beperkt in de beschrijvingen van de primaire en ondersteunende processen. Vele (onderdelen) van wettelijke taken worden niet beschreven. Ook de processen rondom het plannen, programmeren, sturen en rapporteren zijn niet voor alle processen eenduidig vastgelegd. Voor het proces ‘procesvoering bezwaar en beroep’ is in het geheel geen beschrijving beschikbaar binnen de UPP. Regionale diensten worden zowel intern als extern geaudit, om vast te stellen of de wetgeving op de juiste wijze is toegepast. Ofwel, zijn de juiste vergunningen verstrekt en zijn de vergunningen juist verstrekt. Er vindt geen audit plaats op de wijze waarop de processen volgens UPP worden uitgevoerd. De kwaliteit van de gegevens in een administratie wordt bepaald door de kwaliteit van de procesgang. Op dit moment worden niet alle gegevens van een vergunning adequaat vastgelegd in een administratie. Veel informatie wordt in fysieke vorm (papier) opgeslagen. Het proces van “Verlenen van een vergunning” houdt meer in dan alleen het verstrekken van vergunningen. Klanten leggen Rijkswaterstaat vragen voor, die niet altijd leiden tot een vergunning maar tot een andere vorm van besluit: a. Gedoogbeschikkingen: zaken die door een klant gemeld worden, waarvoor een vergunning niet tijdig kan worden verstrekt, maar waarvoor uitstel niet mogelijk is. b. Intrekkingen: het intrekken van een vergunning. c. Bezien: het periodiek bezien van een vergunning. d. AMvB-meldingen: zoals bijvoorbeeld op basis van het activiteiten besluit. e. Reacties op Milieu Effect Rapportages. f. Post met reactie: brieven van klanten waarop Rijkswaterstaat moet reageren in het kader van haar wettelijke taak; g. Meldingen 8.19: dit betreft wijzigingen op een bestaande vergunning waarvoor niet een nieuwe vergunning wordt vergeven; h. Gemeentelijke Riolerings Plannen en Veiligheidsrapportages waarbij Rijkswaterstaat advies dient te geven. i. Akkoordbrieven bij goedkeuring. Het digitaliseren van post in Maastricht door het Service Center Vergunningen.Hierbij gaat het met name om scans van tekeningen op papier groter dan A3. Ondanks contractuele afspraken over de tijdsduur van het scannen komt het vaak voor dat scannen langer duurt. Hierdoor wordt een deel van de


wettelijk toegestane behandeltermijn in beslaggenomen door het digitaliseren van de aanvraag. 8. In de vergunningverlening en in het behandelen van meldingen AMvB komt regelmatig voor dat niet het juiste bevoegd gezag de aanvraag of melding ontvangt. Dit is niet expliciet in UPP beschreven. Bij het niet tijdig doorsturen van de aanvraag en zeker in het geval van een melding, gaat het ten koste van de behandeltermijn die het juiste bevoegd gezag heeft. 9. In de vergunningverlening en in het behandelen van meldingen AMvB komt regelmatig voor dat niet het juiste bevoegd gezag de aanvraag of melding ontvangt. Dit is niet expliciet in UPP beschreven. Bij het niet tijdig doorsturen van de aanvraag en zeker in het geval van een melding, gaat het ten koste van de behandeltermijn die het juiste bevoegd gezag heeft. 10. Er zijn geen eenduidige processen of procedures vastgesteld in het geval van een samenloop van bevoegd gezagen. In het kader van de dienstverlening is het dan noodzakelijk om te overleggen met bijvoorbeeld gemeente en waterschap over aanvragen van vergunningen. Er is echter geen beschrijving beschikbaar van vergelijkbare processen. 11. De efficiency bij de uitvoering van de processen kan op veel punten worden verbeterd als de gegevens en faciliteiten op een eenduidige manier gebruikt worden. Bijvoorbeeld in de overgang van vergunningverlening van handhaving is het wenselijk dat de dossiers op een uniforme manier zijn vastgelegd, zodat handhavers bekend zijn hiermee en makkelijk informatie over de verleende vergunning kunnen vinden. Het geldt ook aan de voorkant van het proces van vergunningverlening. Er valt veel te winnen bij het vooraf juist informeren van de klant over de procedures van het aanvragen van vergunningen of het doen van meldingen en over de inhoud van deze zaken. Bij een juiste aanvraag of melding is het voor de behandelaar een “eenvoudige” zaak om het proces te doorlopen. Dit informeren is dus erg belangrijk voor de doorlooptijd van het proces. 12. De koppeling tussen vergunningverlening en handhaving loopt in de praktijk vaak niet soepel, bijvoorbeeld een handhaafbaarheidstoets of een opleveringsbezoek worden vaker niet dan wel uitgevoerd, ondanks dat deze processtappen wel zijn beschreven. De effectiviteit van de vergunningen en meldingen kan daarmee worden verbeterd, en daarmee de dienstverlening richting de klant. 13. De Plan-Do-Check-Act cyclus is in het project Digitale Handhaving ingevuld voor het proces van handhaving, maar dit is niet op hetzelfde niveau gebeurd in de UPP. Voor vergunningverlening is de cyclus niet terug te vinden in UPP of daarbuiten. Dat betekent dat er ook geen controle op de uitvoering van deze cyclus kan plaatsvinden. 14. De uitvoering van de processen is door de regionale diensten op verschillende wijzen in de organisatie belegd. Ook dit werkt een eenduidige uitvoering niet in de hand.

65


15. In de praktijk blijkt dat de vastgestelde plannen (HUP en JUP) niet worden bijgewerkt op basis van de geconstateerde feiten ten aanzien van naleving. Tijdens de workshops is geconstateerd dat nalevingsgedrag een belangrijke input is voor de risico analyse en daarmee voor het jaar plan. Dit zou terug moeten komen in de processen rondom de Plan-Do-Check-Act cyclus. Deze bevindingen betekenen voor Havik 2 onder andere dat er een aantal randvoorwaarden aanwezig moeten zijn voor een succesvol implementatietraject. In hoofdstuk 5 worden deze randvoorwaarden ten aanzien van de processen of de invulling daarvan verder uitgewerkt.

66


5 Globaal procesontwerp SOLL Dit hoofdstuk behandelt een globaal procesontwerp voor de toekomstige situatie (de SOLL situatie). In de inleiding wordt globaal aangegeven welke ontwikkelingen er zijn voor de veranderingen in de processen. In paragraaf 5.2 worden de eisen en wensen die naar voren zijn gekomen tijdens de workshops en gesprekken met professionals op een globaal niveau gepresenteerd. Daarna volgt in paragraaf 5.3 en 5.4 een relatie met de overheids- en rijkswaterstaatbrede ontwikkelingen. Dat leidt in paragraaf 5.5 tot een generiek procesmodel voor elektronische of e-dienstverlening.

5.1 Inleiding De processen binnen Rijkswaterstaat zullen en moeten in de toekomst gaan veranderen, om een aantal redenen: 1. Vanuit de organisatie is tijdens de workshops een aantal eisen en wensen ten aanzien van de organisatie, de processen en de informatie gedefinieerd. Ook de gesprekken met professionals uit het werkveld hebben geleid tot eisen en wensen voor een toekomstige situatie; 2. De overheid wil de administratieve lasten voor de burger en het bedrijf verlichten, door investeringen te doen in elektronische dienstverlening (de e-overheid). De processen “Verlenen van een vergunning” en “Handhaven” krijgen daar mee te maken en zullen daarom (deels) wijzigen; 3. ICT maakt het mogelijk om processen te stroomlijnen, te optimaliseren en efficiënter uit te voeren, waardoor ook de kwaliteit van de dienstverlening van Rijkswaterstaat kan verbeteren. Rijkswaterstaat heeft daarvoor beleid ontwikkeld, welke tot uitdrukking komen in de Enterprise Architectuur Rijkswaterstaat; 4. Nieuwe processen, zoals de verwerking van AMvB-meldingen, bieden kansen om processen te standaardiseren. Een goede administratievoorziening kan daarbij helpen als deze goed aansluit bij deze nieuwe processen, het voorkomt fouten en dringt diversiteit in processen terug; 5. Voor de organisatie van Rijkswaterstaat wordt onderzocht (medio januari 2009) wat de implementatie van de waterwet voor gevolgen heeft (zie paragraaf 3.2.4). De organisatieverandering is van belang voor Havik 2, vanwege de processen die ondersteund moeten worden. Deze schets van veranderingen vanuit de organisatie en daarbuiten geven aan dat voor het maken van een ICT voorziening voor handhaving en vergunningverlening de huidige processen niet in z’n geheel kunnen worden gebruikt als uitgangspunt. Voor deze processen zullen er verandering zijn die in een toekomstige situatie ondersteund moeten worden.

67


5.2 Gebruikersinventarisatie Tijdens de definitiestudiefase is een groot aantal gesprekken gevoerd met professionals uit het werkveld van vergunningverlening en handhaving en zijn 3 workshop georganiseerd voor deze groep. Doel van de gesprekken en de workshops was o.a. om in kaart te brengen welke eisen en wensen er zijn ten aanzien van de processen. Daarnaast zijn de minder of onbekende processen in kaart gebracht. De resultaten hiervan zijn geabstraheerd wat heeft geleid tot een aantal aspecten voor de processen die in Havik 2 een plek moeten krijgen. • De mate van zorgvuldigheid in de vooroverleg fase bij vergunningverlening, is bepalend voor de haalbaarheid van Awb-termijnen. Het vooroverleg is het moment om de mogelijke aanvrager te informeren over de procedure, de benodigde informatie en het juiste bevoegd gezag. Aan de andere kant wordt het vooroverleg ook gebruikt om een eerste beoordeling te doen over de aanvraag, om de aanvrager te informeren over de kans van slagen. In het vooroverleg vindt dus al een inhoudelijke beoordeling plaats, naast veelvuldig overleg met collega’s en andere bevoegd gezagen (in het geval van samenloop). • Het eenmalige invoeren van gegevens is een belangrijk aspect, waardoor doublures in gegevens worden voorkomen, maar ook een foutief gebruik van gegevens. • Het bewaken van termijnen volgens de Awb is, zeker gezien de Wet Dwangsom, een must voor het uitvoeren van de processen. • Het eenvoudig maken van management rapportages is belangrijk, zodat de gebruikers weinig tijd kwijt zijn aan de verplichte trimester rapportages. Hiermee zijn de gegevens voor de PIN’s snel en makkelijk te versturen. • Voor gebruikers is het belangrijk om bij de behandeling van een aanvraag, melding, het inzetten van een sanctiemiddel of het houden van toezicht inzicht te hebben in de fase van het proces waarin men bezig is, en welke taken of handeling hierbij uitgevoerd moeten worden. Dit garandeert de kwaliteit van de gegevens die worden vastgelegd over een zaak. • Vanuit handhaving is er de wens om een relatie te kunnen leggen tussen het HUP (doelstellingen) en geplande activiteiten, waarbij de geplande activiteiten automatisch worden vastgesteld op basis van het beheergebied, het HUP en de beschikbare mankracht. Daarbij volgt ook automatisch een wens om een overzicht te hebben van de werkzaamheden die nu worden uitgevoerd. Dit betreft stuurinformatie voor teamleiders. De wens om stuurinformatie te hebben leeft niet alleen bij handhaving maar ook bij vergunningverlening. • Bij de risicoanalyse die wordt uitgevoerd voor het HUP is het van belang om zoveel mogelijk objectief te oordelen. Het gebruiken van gegevens uit een dossier over naleefgedrag is hierbij een belangrijke wens. Daarnaast bestaat er de wens om het risicoprofiel van een branche of bedrijf automatisch bij te werken op basis van de constatering die worden gedaan.

68


•

•

•

•

•

Daarmee zou ook de planning (HUP of toezichtsplan) worden bijgewerkt. Voor vergunningverlening is er de wens om een, vergelijkbaar met handhaving, een relatie te leggen tussen het JUP (doelstellingen) en de uitvoering. Dit betreft informatie voor het maken van het JUP, maar ook stuurinformatie voor het werken volgens het JUP. Bij de professionals in het werkveld is er een wens voor het kunnen gebruiken van eenduidige werkinstructies en procedures. Een kwaliteitssysteem is hierbij onontbeerlijk. Door landelijk afspraken te maken over de werkinstructies en procedures ontstaat een uniforme werkwijze. Dit betekent voor klanten dat ze onafhankelijk van het bevoegd gezag op dezelfde manier behandelt worden. Daarnaast betekent het dat de gegevens van handhaving en vergunningverlening een juist beeld geven van het werkveld. Een ander aspect ten aanzien van werkinstructies is het hebben en gebruiken van checklists, voor zowel vergunningverleners als handhavers. Een checklist helpt bijvoorbeeld om op basis van de verleende vergunningen en gedane meldingen een handhavingbezoek te kunnen houden bij de klant. De handhaver kan hiermee per bedrijf een ander toezichtsbezoek doen, afhankelijk van het risico en de historie van een relatie. Hiermee wordt gerichter gehandhaafd. Een dossier van de klant is voor het werkveld erg belangrijk, zodat overzicht ontstaat van de verleende vergunningen, meldingen en de sanctiemiddelen die zijn toegepast. Daarnaast biedt het de mogelijkheid voor verschillende medewerkers om elkaars werkzaamheden te kunnen overnemen, omdat per klant is vastgelegd welke acties zijn afgehandeld en welke nog open staan. Voor zowel handhavers als vergunningverleners is het overleggen en afstemmen een belangrijk onderdeel van het werk. Dit komt bijvoorbeeld terug in de handhaafbaarheidstoets, maar ook in een legalisatietoets, zodra een handhaver een niet-vergunde activiteit waarneemt. Daarnaast is er ook afstemming nodig tussen de milieu en niet milieu gerelateerde medewerkers, voor zowel vergunningverlening als handhaving. Ook communicatie met andere bevoegd gezagen is onderdeel van het werkveld. Het ondersteunen van dit proces van overleggen en afstemmen is een wens van de professionals.

Deze aspecten worden meegenomen in het ontwerpen van een generiek proces voor Havik 2.

5.3 Aansluiten op e-overheid Zoals in hoofdstuk 3 naar voren is gekomen is er binnen de overheid een groot aantal ontwikkelingen op het gebied van dienstverlening richting burger en bedrijf. In de volgende aspecten worden de gevolgen voor de processen voor handhaving en vergunningverlening benoemd.

69


•

•

•

Met de LVO komt er een gezamenlijk frontoffice voor de omgevingsvergunning en de watervergunning. Maar voor wetgeving die niet onder de Wabo of de Waterwet valt is geen loket voorzien. Dit betekent dat voor aanvragen voor een vergunning of AMvB meldingen waarbij Rijkswaterstaat het bevoegd gezag is, er vanuit meerdere plekken aanvragen binnen kunnen komen, zowel op papier als digitaal. Het proces digitaliseren van aanvragen en melding blijft daarmee een belangrijk onderdeel. Daarnaast blijft er bij het bevoegd gezag de verantwoordelijkheid om te controleren of zij het juiste bevoegd gezag is voor de aanvraag of melding en moet het bevoegd gezag controleren of de aanvraag of melding juist is. Het LVO kan met een vragenboom de aanvrager of melder hierbij helpen, maar is niet feilloos. In de nieuwe waterwet en daarmee ook in het LVO is het bevoegd gezag verplicht om de klant op de hoogte te brengen van de voortgang van de behandeling. Het bevoegd gezag moet dus een status kunnen terugkoppelen. Met het LVO en de basisregistraties levert een klant maar één keer informatie aan. Deze informatie dient daarna te worden gebruikt door alle behandelaars van een zaak, zowel bij vergunningverlening als bij handhaving. Dat vergt een juiste koppeling van de processen onderling en met de basisregistraties. Het aansluiten op de basisregistraties betekent echter ook dat er een verplichting is om terug te melden, in het geval een verkeerd gegeven wordt geconstateerd. Vanuit handhaving of vergunningverlening moet hier een procedure voor zijn in Havik 2.

5.4 Conformeren aan de Enterprise Architectuur Rijkswaterstaat De processen die ingericht zijn en de voorzieningen die ingericht moeten worden, zijn bedoeld om de visie en het beleid van het Rijkswaterstaat bestuur te realiseren. Architectuur is een goed stuurmiddel om de Rijkswaterstaat organisatie, processen en informatievoorziening in de gewenste richting te brengen. Voor Havik 2 zijn voor een aantal relevante architectuur-aspecten de architectuurprincipes geïnterpreteerd en toegepast in de oplossingsrichtingen8.

5.5 Generiek procesmodel e-dienstverlening Havik 2 Bedrijven en burgers kunnen verschillende verzoeken indienen bij de Overheid. Een aantal van deze verzoeken zal leiden tot een vergunning. In bepaalde gevallen kan een klant volstaan met het melden van een bepaalde activiteit. Daarnaast kan de situatie zich voordoen, dat Rijkswaterstaat als bevoegd gezag een maatwerk voorschrift toevoegt 8

Voor een nadere uitwerking van de wijze waarop de architectuurprincipes zijn

geïnterpreteerd en toegepast, wordt verwezen naar de ProjectStartArchitectuur Havik 2 die parallel aan deze definitiestudierapportage is opgesteld.

70


aan de melding, of een andere vorm van besluit of beschikking aan de klant aanbiedt. Alle verschillende soorten vraagstukken, leiden tot de start van een specifiek proces. De verzoeken van de klant moeten “geclassificeerd” worden om de juiste processen in gang te zetten. Dit geheel aan stappen is in Figuur 16 uitgewerkt. Het procesmodel bevat elementen van de front, miden backoffice. Dit procesmodel voor dienstverlening kan zowel toegepast worden voor het leveren van diensten aan externe klanten (de burger of bedrijven) als voor interne klanten (verschillende diensten of organisatieonderdelen binnen of buiten de eigen organisatie zoals collega bevoegd gezagen bij vergunningverlening). Nadrukkelijk ook waarnemingen vanuit handhaving, die behandeld moeten worden, kunnen op deze manier in het generieke procesmodel worden behandeld.

Procesmanagement

Primaire processen

Dienstverlenende processen Overheid

overheid

Klant

Assisteren en informeren klant

Handhaven

Vergunning verlenen Communiceren klant en overheid

Ontvangen klantvraag

Classificeren klantvraag

Registreren zaak

Behandelen zaak

. . .

Rapporteren

Beheren zaak

burger

bedrijf

Gegevensverzamelingen Basisregistraties

Kernregistraties

Klantgegevens

Zakendossiers

Zaaktypen

Openbare informatie

Figuur 16: Generiek procesmodel e-dienstverlening tbv routering van “zaken” In de afbeelding zijn enkele hoofdgroepen onderkend: • Procesmanagement: het onderdeel binnen Rijkswaterstaat waarin op grond van externe en interne informatie het beleid wordt vastgesteld voor het intern functioneren van de dienst of district die het dienstverlenende en primaire proces moet uitvoeren. Bijvoorbeeld het opstellen van werkinstructie en kwaliteitsmanagement valt onder procesmanagement. • Dienstverlenende processen: In dit proces worden alle processen uitgevoerd, die te maken hebben met het honoreren van verzoeken voor dienstverlening uit de buitenwereld van

71


•

•

burgers en bedrijven. In de context van deze definitiestudierapportage betreft het de dienstverlenende activiteiten in de globale processen Vergunningverlening en Handhaving. Het verlenen van een vergunning is hier een voorbeeld van, maar ook het communiceren over waarnemingen en mogelijke sancties vanuit handhaving. Primaire processen: in dit proces worden alle processen gebundeld, die te maken hebben met het primaire proces van Rijkswaterstaat, waarin het initiatief bij Rijkswaterstaat ligt. De behandeling van aanvragen voor een vergunning of AMvB meldingen vallen hier bijvoorbeeld onder, maar ook het houden van toezicht. Gegevensverzamelingen: Het betreft hier de totale set van gegevens op grond waarvan en met behulp waarvan de operationele en primaire processen binnen Rijkswaterstaat worden uitgevoerd. Onderscheid wordt gemaakt tussen de landelijke gegevensverzamelingen (basisregistraties) en de eigen gegevensverzamelingen, zoals zakendossiers, monsters, HUP’s en LJUP’s en openbare informatie zoals vergunningen, besluiten en wetgeving.

Dit procesmodel concentreert zich op het aspect dienstverlening, omdat daar een belangrijke wijziging zit bij de invoering van de Waterwet. In principe wordt thans (januari 2009) per wet één vergunning aangevraagd. Na inwerkingtreding van de Waterwet, wordt één vergunning aanvraag ingediend en zal eerst vastgesteld moeten worden of er vergunningplicht of meldingplicht aanwezig is, welk artikelen van de Waterwet van toepassing is, of Rijkswaterstaat het juiste bevoegd gezag is, en welke procesgang gevolgd moet worden. Daarnaast biedt dit procesmodel ook de ingang voor de vergunningen en/of meldingen die niet onder de waterwet vallen en daarmee niet via de LVO naar het bevoegd gezag worden gestuurd. In dit procesmodel is het communiceren met de klant en overheid immers opgenomen als apart onderdeel. Dienstverleningsproces uit dit model bestaat uit een aantal deelprocessen: 1. Communiceren klant en overheid: De klant kan zijn vraag, verzoek of melding via verschillende ingangen (telefoon, balie, internet, schriftelijk etc.) indienen. De Waterwet schrijft voor dat bedrijven een digitale aanvraag indienen, waarbij de LVO het loket is. De burger mag dat ook, maar mag ook naar het gemeentelijk loket voor indiening van eventuele aanvragen of meldingen. Dit deelproces faciliteert de communicatiemogelijkheden. Dit proces wordt inzake Havik 2 ondersteund door de LVO voor zover het de dienstverlening voor de vergunningaanvraag of AMvB melding onder de waterwet betreft. Voor vergunningen of melding daarbuiten zal een andere invulling van het deelproces benoemd moeten worden. 2. Ontvangen klantvraag: Dit proces verwerkt de verschillende vraagvormen tot een uniforme (kanaalonafhankelijke)

72


3.

4.

5.

6.

7.

klantvraag. Afhankelijk van het gebruikte medium of kanaal met de specifieke eigenschappen vinden activiteiten plaats om de klantvraag te uniformeren. Met ander woorden, als de klantvraag in de vorm van een elektronisch bericht binnenkomt, dan wordt dit bericht verwerkt en presentabel gemaakt voor de medewerker van Rijkswaterstaat of geschikt gemaakt voor behandeling in een informatiesysteem. Als de klantvraag in briefvorm binnenkomt, kan (zoals nu al gebeurt) de brief gedigitaliseerd worden en verwerkt worden in de juiste administratie. Een klantvraag kan ook in e-mailvorm worden ontvangen. Dan wordt de klantvraag presentabel gemaakt in het emailpakket. Een klantvraag in deze betreft niet alleen de aanvraag voor een vergunning, maar kan bijvoorbeeld ook gaan om vooroverleg of de status van een aanvraag. Classificeren klantvraag: Na binnenkomst van een geüniformeerde klantvraag wordt vastgesteld welk type vraag het betreft en welke behandeling gewenst is. Vragen die niet geclassificeerd kunnen worden teruggekoppeld naar de klant voor een verdere invulling, zodat in een later stadium dit deelproces wel kan worden doorlopen. Hier wordt gekeken naar de inhoud van de klantvraag. Assisteren en informeren klant: Dit deelproces helpt de klant bij het beantwoorden van zijn/haar vraag. Hiertoe staan verschillende hulpmiddelen ten dienste, zoals zoekfunctionaliteit, een productencatalogus, een geleide zoekprocedure, etc. Registreren zaak: Indien een vraag is geclassificeerd als een “verzoek om afhandeling”van een zaak, wordt hiertoe een zaak geregistreerd. Dit registratieproces houdt in, dat wordt beoordeeld of er voldoende informatie voorhanden is om de zaak in behandeling te nemen. Beheren zaak: Dit deelproces is verantwoordelijk voor het sturen en bewaken van de uitvoering van een processtap in de totale zaakafhandeling. Behandelen zaak: In behandelen zaak worden de primaire processen (of deelprocessen daarvan) uitgevoerd. Na de afhandeling van de klantvraag wordt de zaak opnieuw aangeboden aan het deelproces Beheren zaak. Binnen Behandelen zaak kan het ook noodzakelijk zijn om een nieuwe zaak te creëren of om de onderhanden zaak op te schorten, als bijvoorbeeld een bezwaartermijn moet worden afgewacht.

Het geschetste generieke procesmodel kan daarmee worden toegepast op alle processen die moeten worden uitgevoerd in het kader van vergunningverlening en handhaving voor Rijkswaterstaat. Ook de ondersteunende, besturende en beleidsvormende processen kunnen in dit generieke procesmodel worden gevat. Het gaat immers telkens om een klantvraag (of het nu gaat om een vergunningaanvraag van een bedrijf, of een werkoverzicht van een teamleider van handhaving) die door de deelprocessen beantwoord kan worden. Het procesmodel is dan ook het uitgangspunt voor de verdere ICT oplossingsrichtingen.

73


6 Gegevensmanagement Rijkswaterstaat maakt deel uit van een overheid die steeds meer nationaal en internationaal samenwerkt. In de Enterprise Architectuur zijn principes genoemd, waaruit de visie van Rijkswaterstaat blijkt op de wijze waarop samenwerking tot stand is gekomen of wordt gebracht. Samenwerken betekent dat er gecommuniceerd wordt tussen partijen. Over deze communicatie moeten op verschillende niveaus afspraken gemaakt worden. Dit wordt in paragraaf 7.6 nader uiteengezet. Om vast te kunnen stellen wat de benodigde verandering is, wordt eerst een beknopte schets gegeven van de huidige gegevenshuishouding. Gegevens zijn qua aard stabiel, berichten zijn dynamisch, vandaar dat het berichtuitwisseling in een apart hoofdstuk wordt uitgewerkt. In dit hoofdstuk wordt gekeken naar de gegevens die gebruikt worden voor het proces van vergunningverlening en handhaving. Daarvoor wordt in paragraaf 6.1 een beeld geschetst van de huidige situatie. In paragraaf 6.4 worden de eisen ten aanzien van gegevenshuishouding vanuit de architectuurprincipes besproken en in paragraaf 6.3 wordt gekeken naar de aanwezige standaarden. In de paragraven Fout! Verwijzingsbron niet gevonden., 6.7 en Fout! Verwijzingsbron niet gevonden. worden de eisen aan de gegevenshuishouding vanuit handhaving, plannen, sturen en rapporteren en vergunningverlening, op basis van o.a. objectmodellen (paragraaf 6.4). In paragraaf 6.8 volgt vervolgens een conclusie t.a.v. de gegevenshuishouding.

6.1 Huidige gegevenshuishouding vergunningverlening en handhaving Gegevenshuishouding is het systematische geheel van, voor de bedrijfsvoering noodzakelijke gegevens en de hierbij behorende ”lifecycle” taken (zoals verzamelen, opslaan, beheren en toegankelijk maken of verstrekken). Gegevens vormen als het ware de goederenstromen door de administratieve organisatie. De gegevenshuishouding is te vergelijken met een magazijn waar de artikelvoorraad wordt beheerd, artikelen worden ontvangen en uitgegeven. Informatie is een set gegevens waaraan mensen in een bepaalde context betekenis hebben gegeven. De informatievoorziening vormt daarmee de wijze waarop de informatie wordt uitgewisseld. Anno 2009 zijn er binnen Rijkswaterstaat verschillende magazijnen aanwezig. Per regionale dienst worden dezelfde “artikelen” op verschillende wijze verzameld, beheerd en verstrekt. Een belangrijk onderscheid gemaakt kan worden tussen gestructureerde en ongestructureerde informatie. • Gestructureerde informatie heeft betrekking op de administraties (databases) waar informatiesystemen aan gekoppeld zijn. De gegevens zijn veelal volgens een bepaald patroon opgeslagen, waardoor de gegevens makkelijk terug te vinden zijn.

74


•

Ongestructureerde informatie heeft betrekking op brieven, spreadsheets, emails, gescande tekeningen (PDF), foto’s (JPEG, TIFF etc).

Op dit moment wordt ongestructureerde en gestructureerde informatie op verschillende wijze en plaatsen verzameld en beheerd. Er wordt ook niet in alle gevallen met dezelfde informatiesystemen gewerkt, zowel bij handhaving als vergunningverlening. Dit heeft gevolgen voor: • de kwaliteit van de gegevens (in termen van actualiteit, volledigheid en juistheid); • de toegankelijkheid van de benodigde informatie: als gevolg van verschillende vormen van opslag (veel papieren archieven, verschillende elektronische hulpmiddelen zoals brieven in GVG, SAP Havik, Word en tabellen in Excel); • de onderhoudbaarheid van de gegevens: verschillende administraties met dezelfde gegevens betekent dat ook beheer en onderhoud op verschillende plaatsen moet plaatsvinden. De kans op foutkosten is daarmee groter. • het genereren van managementrapportages over de processen vergunningverlening en handhaving bij de verschillende regionale diensten is een moeizaam proces. De kennis van bepaalde “tooltjes” zit bij enkele mensen en er moet uit verschillende bronnen op verschillende wijze management informatie worden gegenereerd en samengevoegd om te kunnen rapporteren. Bijvoorbeeld bij SAP Havik is een Excel spreadsheet beschikbaar, al wordt deze weinig gebruikt. De bedoeling was om deze informatie beschikbaar te hebben via SAP Business Warehouse om op een flexibele manier rapportages te kunnen genereren maar bij implementatie van SAP Havik functioneerde dit nog niet naar behoren. Inmiddels kan SAP BW wel worden gebruikt. • het ontsluiten van historische gegevens is moeilijk, omdat er verschillende bronnen zijn voor dezelfde wetgeving.9 • het niet beschikbaar zijn van alle vergunningen, meldingen, bezoekverslagen, etc. in elektronische in elektronische vorm. • de verschillen in de normalisatie van de gegevens en de gegevensstructuren. In de administratie van SAP Havik zijn de gegevens gestructureerd rondom het objecttype SUBJECT (de klant), in WVO-info zijn de gegevens gestructureerd rondom het objecttype LOZINGSOBJECT. Daarnaast worden bij WVOinfo ook lozingsnormen en verplichtingen over administratieve verslagen vastgelegd in de administratie, terwijl bij SAP Havik alleen de vergunning wordt vastgelegd. • In de vele verschillende Excel spreadsheets worden procesgegevens bijgehouden over statussen van aanvraagprocedures. Per regio worden hier weer andere spreadsheets voor gebruikt. • de definities die worden gebruikt. Bij overlap in de administraties worden dezelfde termen gebruikt, maar met een 9

Vergunningen WBR voor 2006 in Generiek Vergunningen GIS, andere vergunningen in SAP

Havik, papieren archieven.

75


•

andere definitie. Dit kan zorgen voor spraakverwarring en problemen bij conversie van gegevens naar één gegevensmagazijn. de vulling van de gegevensmagazijnen. Niet in elke regio of district worden dezelfde (meta) gegevens over vergunningen, meldingen AMvB, etc. vastgelegd of worden dezelfde standaarden gehanteerd. Het betreft dan bijvoorbeeld het ontbreken van geografische coördinaten, of een andere codering van de objecten.

Deze bevindingen leiden tot de conclusie dat de huidige gegevenshuishouding niet toereikend is. De toekomst met een verandering van het type vergunningen die worden verleend, een overgang naar meer AMvB’s en een verandering van het soort toezicht, zorgen dat Rijkswaterstaat niet zonder problemen met de huidige gegevenshuishouding kan blijven werken. Op basis van de bevindingen en de eisen vanuit de overheid en Rijkswaterstaat voor gegevens wordt een voorzet gegeven voor het verbeteren van de gegevenshuishouding.

6.2 Eisen vanuit architectuurprincipes Naast het vervangen van functionaliteit op termijn, is het noodzakelijk om op het gebied van gegevensmanagement maatregelen te nemen, zodat wordt voldaan aan de architectuurprincipes van de NORA: • Eenmalige gegevensopslag en meervoudig gebruik. De NORA hanteert daarvoor twee type registraties: de basisregistraties (op korte termijn landelijk verplicht gesteld) en kernregistraties (centrale gegevensverzamelingen binnen de eigen organisatie die als bron dienen voor afnemende applicaties). Alle gegevensverzamelingen van de overheid zijn van gemeenschappelijk nut. Voor zover mogelijk moeten de gegevens gedeeld kunnen worden voor de uitvoering van de bedrijfsprocessen, wat geldt voor zowel de basis- als de kernregistraties. • Centralisatie van gegevensopslag Dit heeft een kwaliteitsverhogende werking op de bedrijfsvoering. Herbruikbare gegevens worden op één plaats onderhouden, waardoor aanpassing sneller te realiseren is. De kans op fouten door gebruik van inaccurate gegevens wordt verkleind. Daarnaast voorkomt het redundantie waardoor miscommunicatie kan ontstaan die gepaard gaat met klachten of claims van klanten. Naast de NORA hanteert de Rijkswaterstaat Enterprise Architectuur de volgende architectuur principes met betrekking tot het gegevensmanagement: • Gegevens worden één keer, verworven, opgeslagen en beheerd o Elk gegeven kent precies één eigenaar o Elk gegeven kent één bronadministratie o Als een gegeven al wordt ingewonnen, sluit Rijkswaterstaat daar bij aan o Ketenbenadering (afspraken over gedeelde opslag)

76


o o o

Maak gebruik van basisregistraties Generiek waar kan, specifiek waar moet Iedere proceseigenaar verzamelt niet voor zichzelf gegevens als deze gegevens reeds elders worden ingewonnen

De eisen die gesteld worden vanuit architectuurprincipes geven andermaal aan dat de huidige gegevenshuishouding niet voldoet. Immers, het principe van basis- en kernregistraties wordt niet toegepast. Ook het ontbreken van duidelijke afspraken over gegevens (zoals een eigenaar en bronhouder) voldoet niet aan de principes.

6.3 Standaarden en Omgeving Ten behoeve van de Havik 2 is het noodzakelijk om te komen tot semantische en syntactische standaarden, die voor het hele werkveld worden afgestemd en vervolgens ook toegepast.. Afhankelijk van de uiteindelijk te realiseren oplossingsrichting kan hier verder invulling aan gegeven worden. Er zijn meerdere standaarden die van toepassing zijn op het werkveld van vergunningverlening en handhaving. • AQUO (IDsW): standaarden voor gegevens bij waterbeheerders • INSPIRE: Europese standaard voor geografische informatie • NEN 3610: standaard voor geografische informatie • GFO-zaken10: gemeentelijke standaard voor zaken • RSGB11.: referentiemodel voor gemeentelijke basisgegevens • OSB: standaard voor berichtverkeer met o.a. de basisregistraties In het vaststellen van de standaarden die van toepassing zijn op het werkveld van handhaving en vergunningverlening, kunnen deze standaarden worden gebruikt. Daarnaast is het noodzakelijk om op deze standaarden aan te sluiten voor de uitwisseling van gegevens met andere organisaties en omliggende systemen, zodat er geen problemen ontstaan met verschillende definities. Hiervoor moet worden afgestemd met: • LVO WABO en LVO water • E-inspecties • Frontoffice binnenvaart • E-MJV • Ministier van LNV voor informatie over het besluit Open Teelt en Veehouderij

6.4 Objectmodellen Het aandachtsgebied van Havik 2 is bijzonder breed. Door deze brede scope moeten begrippen gegeneraliseerd worden die in verschillende administraties voorkomen. Vanuit de bedrijfsprocessen zijn “objecttypen” onderkend en vertaald in een objectmodel. Een objecttype is een onderwerp van gesprek, gebeurtenis (abstracte objecten zoals een lozing of uitgevoerde inspectie), of concrete 10

GFO-zaken is een rijksbreed gedragen functioneel ontwerp van een zakensysteem.

11

RSGB: Is Referentiemodel Stelsel van Gemeentelijke Basisgegevens, daarin zitten alle

beschrijvingen van relevante basisregistraties.

77


objecten (een vergunning, persoon). Daarmee hebben objecten niet een één op één relatie met de gegevens zoals die worden gebruikt in de processen. Een objectmodel is dus geen databasestructuur. De doelstelling van het objectmodel is een afbakening te geven van de onderwerpen van gesprek in de processen verlenen van vergunning, handhaven, behandelen melding, plannen, sturen en rapporteren. Bij de totstandkoming van het objectmodel is gekeken naar de open standaarden en de gegevensverzamelingen waar vergunningen en handhaving gegevens in zitten. Dit zijn: • SAP Havik (PSRM) • WIS • WVO-info • GVG • TRIM Enkele opvallende zaken zijn geconstateerd bij de vergelijking van de bestaande objecten: 1. Veel homoniemen: er zijn begrippen met dezelfde naam maar met verschillende betekenissen. 2. Veel synoniemen: er zijn gelijkwaardige begrippen met verschillende naamgeving. 3. Begrippen verschillen qua formaat. In de definitiestudie heeft geen afstemming plaatsgevonden om begrippen te standaardiseren. Als de oplossingsrichting gekozen is, zal mogelijk alsnog standaardisatie van begrippen moeten plaatsvinden. De tekentechniek komt overeen met de enterprise richtlijnen. De objectmodellen worden in de volgende paragraven weergegeven, per type proces.

6.5 Eisen aan de gegevenshuishouding t.b.v. Handhaving Het handhavingsproces heeft een brede informatiebehoefte. Voor het vastleggen van bedrijfsrapportages, het voorbereiden van toezichtsbezoeken, het vastleggen van (bezoeks)verslagen dient een administratie beschikbaar te zijn, maar ook ter ondersteuning van de uitvoering van toezicht, bijvoorbeeld bij de controle op lozingsnormen. Het proces handhaven heeft tot doel om de correcte naleving van weten regelgeving, voorschriften en beleidsrichtlijnen te waarborgen die verbonden zijn aan de verleende vergunningen (of melding) waar Rijkswaterstaatbevoegd gezag voor is. Dit houdt in dat de handhaver ten minste de beschikking heeft over: • specifieke informatie: o actuele vergunning en melding informatie; o geografische informatie van het werk; o meetgegevens; o normen; o klantdossier (inclusief historie); • generieke informatie: o geografische informatie (topografische kaart);

78


o o o

kadastrale gegevens; weten regelgeving; procedures, werkinstructies en checklists.

Een deel van de benodigde informatie betreft gestructureerde informatie zoals vergunningen, lozingsgegevens en normen. Met name de klantdossiers bevatten ongestructureerde informatie zoals brieven, gedoogbesluiten, maatwerkbesluiten, intrekkingen en informatieuitwisseling in vooroverlegfase. In Figuur 17 is dit weergegeven in een objectmodel.

Handhav ing

B edrijfs ‐ rapport

Norm

Medewerk er

B evinding

Bez oek

Waarnem ing

Eenheid & param eter

Aanleid ing Dos s ier

Vers lag Meetpunt

Vers lag ‐ type

Handeling s ‐ loc atie

Aanleid ing ‐ type

Z aak Handeling

Vaartuig L ozin g s ‐ objec t

Werk

Voertuig

B es c hik k ing

Overig /Onbek end S AP Havik & WVO‐Info WVO‐Info

S ubjec t

S AP Havik

Figuur 17 Objectmodel handhaving Een BEZOEK vindt plaats op basis van een AANLEIDING. De AANLEIDING hoeft nog geen formele ZAAK te zijn, maar kan bijvoorbeeld gepland of ongepland zijn. Het BEZOEK heeft betrekking op een HANDELING en vindt plaats op een HANDELINGSLOCATIE. Een HANDELING kan gerelateerd zijn aan een VOERTUIG of VAARTUIG. Voor een meting is een MEETPUNT gedefinieerd op de HANDELING op een HANDELINGSLOCATIE. De WAARNEMING op het MEETPUNT wordt vastgelegd op basis van een bepaalde EENHEID & PARAMETER. Een bezoek kan reden zijn voor een MEDEWERKER om een BEVINDING ten opzichte van een bepaalde NORM vast te leggen in een VERSLAG. Dit kan reden zijn om een AANLEIDING aan te maken, ofwel om een ZAAK aan te maken voor interventie. Een ander wordt aan het DOSSIER toegevoegd.

79


6.6 Eisen aan de gegevenshuishouding t.b.v. vergunningverlening Met het in gebruik nemen van de LVO wordt een deel van de administratie gevuld door de aanvrager in de LVO. De LVO beschikt over een administratie die het behandelproces ondersteunt (de behandelmodule). Zodra de vergunning verleend is en het vergunningverleningsproces is afgerond, verdwijnen de gegevens in de behandelmodele uit de LVO-administratie. Rijkswaterstaat zal dus in de backoffice een voorziening moeten hebben die de gegevens overneemt, zowel in het geval dat de behandelmodule wordt gebruikt als in het geval dat deze niet wordt gebruikt. Op dit moment is nog niet bekend welke gegevens via de LVO worden aangeleverd. Het objectmodel voor de registratie van de vergunning is derhalve zoveel mogelijk afgestemd op het meest generieke model dat binnen de overheid wordt toegepast het: GFO-zaken. Dit is vertaald naar de situatie binnen het werkveld van vergunningverlening. Figuur 18 Objectmodel vergunningverlening

Verg unn ing v erlen ing Vaartuig

Meetpunt Handeling

Voertuig

Werk Handeling s ‐ loc atie

L oz in g s ‐ objec t

Aanleid ing ‐ type

P ublic atie L eg g er

Doc um ent

Aanleid ing B es c hik‐ king

B edrijfs ‐ rapport

Dos s ier Z aaktype B evoeg d g ez ag

Ops lag ‐ loc atie

S ubjec t NP

NN P

Z aak B etaling s ‐ verplic hting

Overig /Onbekend S AP Havik & WVO‐Info

Medewerker

B ehandel‐ wijze

Ad vies S tatus

WVO‐Info Wet

S AP Havik

De AANLEIDING om een ZAAK aan te maken, kan verschillend zijn, afhankelijk van het AANLEIDINGTYPE. Enkele voorkomens zijn de VERGUNNINGAANVRAAG, AMvB-MELDING of een aanvraag tot LEGALISATIETOETS van een HANDHAVER. De aanleiding komt altijd in een bepaalde verschijningsvorm bij Rijkswaterstaat, in de vorm van een

80


DOCUMENT. Een ZAAK behoort altijd toe tot een MEDEWERKER. Een ZAAK heeft een STATUS die afhankelijk kan zijn van de BEHANDELWIJZE van die ZAAK. Een ZAAK behoort altijd toe tot een ZAAKTYPE, bijvoorbeeld een handhavingszaak, vergunning of bezwaarschrift. De BEHANDELWIJZE van de ZAAK hangt af van de wetgeving die van toepassing is op de ZAAK. Uit een ZAAK kan een BETALINGSVERPLICHTING ontstaan, zoals leges of heffingen. Bij een ZAAK hoort altijd een SUBJECT geregistreerd te worden. Van een ZAAK wordt een DOSSIER bijgehouden. Een DOSSIER heeft derhalve altijd betrekking op een ZAAK, en is terug te vinden op een bepaalde OPSLAGLOCATIE via de onderliggende DOCUMENTen (documentmanagementsysteem, archiefkast etc). Een HANDELING is een WERK of LOZINGSOBJECT en heeft een HANDELINGSLOCATIE. Een HANDELING kan betrekking hebben op een VOERTUIG of VAARTUIG. De HANDELINGSLOCATIE is gelegen in een bepaald beheergebied en behoort daardoor bij een LEGGER. De LEGGER bepaalt wie BEVOEGD GEZAG is op de HANDELINGSLOCATIE. Het BEVOEGD GEZAG is mede bepaald op grond van WETgeving. Naar aanleiding van een HANDELING kan er een verplichting zijn om BAWrapportages aan te leveren aan Rijkswaterstaat. Bij een ZAAK kan het wenselijk zijn om ADVIES (bijvoorbeeld een technische beoordeling) aan te vragen bij een SUBJECT.

6.7 Planning, Management info, besturing Om zicht te krijgen op de bezettingsgraad, capaciteit, resultaten en de werkvoorraad, zullen op verschillende plaatsen metingen moeten worden verricht. Men wil per zaaktype of soort werkzaamheden kunnen inschatten wat de benodigde doorlooptijd, capaciteit en resultaat is. Ten behoeve van sturing wil men prestaties meten, zoals aantallen bezoeken, interventies, rapportages etc. In de verschillende spreadsheets die nu door verschillende organisatorische eenheden worden gebruikt, worden deze gegevens momenteel bijgehouden. Deze gegevens zullen ook in de Havik 2 administratie opgenomen moeten worden, of worden afgeleid.

81


P lannen, s turen & rapporteren

R is ic o‐ profiel

B ranc he

S ubjec t

B ranc hetype

O rg anis atoris c he eenheid

P lan

Dos s ier P lan type

C apac iteit

Aanleiding

P IN

R apport

O verig /O nbekend Aanleiding ‐ type

S AP Havik & WVO ‐Info

R apport type

WVO ‐Info S AP Havik

Figuur 19 Objectmodel plannen, sturen & rapporteren Van elk SUBJECT dat is gerelateerd aan een ZAAK omdat er bepaalde HANDELINGen plaatsvinden, wordt een BRANCHE-afhankelijk RISICOPROFIEL opgesteld. Op basis van een PIN (prestatieindicator) wordt een PLAN (HUP, JUP) opgesteld en geprogrammeerd. Het PLAN is afgestemd op de beschikbare CAPACITEIT .Nieuwe AANLEIDINGen worden aan het PLAN toegevoegd. Er worden RAPPORTen aangemaakt over de PIN’s, door ORGANISATORISCHE eenheden. Aan de hand van ontwikkelingen in de onderhanden DOSSIERS, kunnen prestaties worden afgeleid over een zekere periode.

6.8 Conclusies Op basis van de bevindingen over de huidige gegevenshuishouding van vergunningverlening en handhaving bij Rijkswaterstaat is te concluderen dat hier niet wordt voldaan aan de architectuurprincipes (van Rijkswaterstaat en de NORA) en dat er niet wordt voldaan aan de eisen en wensen vanuit de gebruikers. Daarmee is het ook duidelijk dat voor een ICT voorziening voor het werkveld er aandacht moet worden besteed aan de gegevenshuishouding. Havik 2 zal generieke functionaliteiten bevatten ten behoeve van de ondersteuning van de generieke aspecten voor de processen Verlenen van vergunning en Handhaven. Voor de taakspecifieke processtappen

82


hierin, die veelal wetspecifiek zijn, zullen gegevens geregistreerd moeten worden waarvan nog vast gesteld zal moeten worden of deze toebehoren tot de Havik 2 administratie,of een centrale plaats krijgen. Gegevensmanagement is op dit moment niet voldoende ingericht om de verantwoordelijkheid voor de gegevens op één plaats binnen Rijkswaterstaat te kunnen beleggen. Conform de architectuurprincipes zou elk gegeven een eigenaar moeten hebben, waarmee afspraken gemaakt moeten worden om gegevensleveringen. Dit is een van de zaken die dient te worden opgepakt.

83


7 Applicatie schets 7.1 Inleiding Het huidige applicatielandschap in de verschillende vergunningen en handhavingsprocessen ziet er divers uit. Elk Rijkswaterstaat-domein Water, Weg en Scheepvaart heeft een eigen landschap en wijze waarop beschrijvingen worden gemaakt. Havik 2 beoogt een integrale ICTondersteuning te bewerkstellingen voor alle wetten waar vergunningverlening en handhavingstaken voor Rijkswaterstaat in voorkomen. Dit houdt in dat er uniformiteit moet zijn in de wijze waarop er zaken beschreven worden.

Corporate (enterprise) Water management

Verkeer management

Scheepvaart verkeer management

Infrastructuur

Taak

Taak

Taak

Taak

Specifiek

specifiek

HAVIK II generiek specifiek

Specifiek

Bedrijfsvoering Financiën Daarom wordt in deze definitiestudierapportage gekozen voor de systematiek van de NORA om zaken te beschrijven. In §7.2 worden de theoretische kaders gezet en wordt de schematechniek nader toegelicht. In §7.3 passen we de schematechniek toe op de huidige situatie en worden kenmerken van het huidige applicatielandschap uiteengezet. In §7.4 wordt beschreven over welke functionaliteiten de front-, miden backoffice moet beschikken. In §7.5 wordt de vertaling gemaakt van gebruikerswensen, enterprise architectuurprincipes en NORA-principes naar een programma van eisen voor de ICT-ondersteuning. §7.6 gaat kort in op het koppelvlak tussen Havik 2 en de omgeving. §7.7 geeft een beschrijving van de eisen en wensen omtrent mobiel werken en de tooling. Ten behoeve van de ondersteuning van handhavers is reeds eerder onderzoek gedaan naar het gebruik van een kennistool. §7.8 gaat daar nader op in. §7.9 vat een aantal zaken samen.

84


7.2 Frontoffice, midoffice, Backoffice De modelmatige manier om een organisatie in te delen is het onderkennen van een frontoffice voor de klantcontacten, een backoffice met de verschillende afdelingen en een midoffice als verbinding tussen beide delen van de organisatie. Deze indeling blijkt goed te werken, ook voor de beschrijving van ICT-voorzieningen. Een combinatie van ICT en organisatie wordt getoond in de plaatjes van hoofdstuk 3 over de e-overheid.

KANALEN

DATA OPSLAG

WERK PROCESSEN

7.2.1 Frontoffice In de frontoffice bevindt zich de fysieke balie, shared service centre, de postkamer en ook de elektronische contacten tussen Rijkswaterstaat en de buitenwereld. De frontoffice stroomlijnt de binnenkomende en uitgaande (elektronische) contacten met de klant en ontkoppelt zo de veelal productspecifieke backoffice. In de frontoffice vindt ook de transformatie plaats om mail, elektronische berichten, post of telefooncontacten om te zetten in een verwerkbare vorm, zoals het registreren van een gesprek door een telefonist(e) in een administratie om een vooroverleg te gaan organiseren, of het scannen van een document in een documentmanagementsysteem of postregistratiesysteem etc. Steeds meer organisaties koppelen hun frontoffices aan elkaar, of delen elkaars voorzieningen in de vorm van shared service centra of gekoppelde internetsites. 7.2.2 Backoffice In de backoffice vindt de traditionele behandeling van zaken plaats, veelal binnen specifieke afdelingen met vakinhoudelijke specialisten (bijv. de Emissiebeheer, Milieuhandhaving, Vergunningverlening, Scheepvaartverkeercentrum etc). Veel informatiesystemen zijn taakspecifiek ingericht binnen zo’n backoffice. Over de gehele backoffices heen bekeken komen dan ook veelal dezelfde gegevens op meerdere plaatsen voor en komen dezelfde functionaliteiten in verschillende applicaties voor, zoals document beheer, zaakmanagement en relatiebeheer. 7.2.3 Midoffice De midoffice heeft een dubbele betekenis. Het verbindt de frontoffice met de backoffice. Elektronisch gebeurt dat met onder andere een zogenaamde “broker” of “berichtenmakelaar”. Deze broker ontvangt bijvoorbeeld een aanvraag in de vorm van een ingevuld elektronisch formulier uit de frontoffice, bepaalt naar welke informatiesystemen of mensen deze aanvraag moet worden doorgestuurd voor registratie en verdere afhandeling. De broker zendt het formulier vervolgens in de juiste vorm ( bijvoorbeeld een elektronisch bericht) en met de juiste adressering naar die systemen of mensen door. Afhankelijk van de automatiseringsgraad van een organisatie zal de midofficefunctie geautomatiseerd of door personen worden uitgevoerd. Daarnaast worden in de midoffice de werkprocessen en informatiesystemen gepositioneerd die verdwijnen uit de backoffices en als generieke oplossing een plek krijgen op concernniveau. Generieke

85


oplossingen zijn documentmanagementsysteem, een zaaksysteem, procesmanagement- of workflowmanagementsysteem. Ook gegevens uit de verschillende backofficesystemen die een centraal karakter hebben, worden in de midoffice gepositioneerd in de vorm van een gegevensmagazijn.

7.3 Huidige informatievoorziening HH & VV 7.3.1 Huidig landschap van de informatievoorziening De wijze waarop Rijkswaterstaat op dit moment is ingericht wordt op hoofdlijnen afgebeeld in Figuur 20. SAP-Hav ik Internetportal

Vergunning verlening Koppeling SAP

DIGID wetgeving

Gegevens opslag

Infraweb

Financieel systeem

LNV

Users wetgeving

koppeling

LIMS Belastingdienst

SAP-Hav ik Intranetportal

SAP Ha vik

BAW R COMA Gegevens opslag

RWS-website

Media

koppeling WVOinf o

bedrijf

Esparant

Koppelingen

burger

Loket regionaal

Word / Excel etc WIS

besluitvorming

WVO-info

C ontent mgt

wetgeving

GVG

almanak FAQ's

WIS

Archief

RWSMede werker

Excel

GEO Koppeling GEO

G E O‐ koppele n

koppeling

GVG Word

Figuur 20 Huidige voorzieningen landschap Huidig frontoffice m.b.t. vergunningverlening en handhaving Ter ondersteuning van de klantcontacten zijn er op dit moment verschillende kanalen in gebruik. De klant moet zelf uitvinden bij welk kanaal hij moet zijn voor een bepaalde dienst. Via de internetsite van Rijkswaterstaat kunnen burgers en bedrijven informatie vinden over de locatie van het fysiek loket binnen Rijkswaterstaat waar men naar toe kan om in contact te treden, of welk postadres, telefoon-nummer men kan gebruiken. Voor bepaalde vergunningen kan men reeds via het elektronisch loket (Internet) in contact treden met Rijkswaterstaat. Per wetgeving zijn verschillende voorzieningen beschikbaar. Per regionale

86


dienst of district zijn er verschillen in de gegevens die moeten worden aangeleverd aan Rijkswaterstaat. Ook de Rijkswaterstaat -vergunningverlener en handhaver moet op verschillende wijze informatie opvragen. Voor vergunningen in WVOinfo, GVG, WIS en SAP Havik zijn verschillende handelingen nodig om toegang te krijgen tot de gegevens. Veel informatie (brieven, vergunningen, besluiten) zit in slecht toegankelijke voorzieningen zoals Word en Excel. Ten behoeve van het uitvoeren van berekeningen en analyses zijn er specialistische systemen in gebruik. Een aantal specifieke functionaliteiten zijn in WVO-info opgenomen. Huidig backoffice m.b.t. vergunningverlening en handhaving Er zijn verschillende opslagmedia in gebruik om de verleende vergunningen, gedoogbesluiten, reacties op MER’s, intrekkingen, besluiten te registreren. Fysiek zijn er verschillende vormen van dossiervorming en archivering. In elektronische vorm worden vergunningen in verschillende systemen geregistreerd (zie Tabel 2). Systeem

Wet / AMvB

Vergunning

Melding

IST Wet Verontreiniging Oppervlaktewater

WVO

X

Lozingenbesluit Open teelt en veehouderij Activiteitenbesluit (sinds 1-1-2009)

WIS

SAP Havik

GVG

X X

Bouwstoffenbesluit

X

Lozingbesluit huishoudelijke lozingen

X

Lozingbesluit Stedelijk Afvalwater Lozingbesluit Glastuinbouw

X X

lozingbesluit bodemsanering en proefbronnering

X

Bouwstoffen besluit (is BBK geworden) Besluit Bodem Kwaliteit (BBK)

X X

Wet Bodembescherming

X

Wet Bodem Bescherming Scheepvaart Verkeer Wet (Binnenvaartwet)

X X

Wet Beheer Rijkswaterstaatswerken

X

Ontgrondingen Wet WegenVerkeerWet

X X

Wet Beheer Rijkswaterstaatwerken

X

Tabel 2 Huidige registratie van meldingen en vergunningen

87


De backoffice bevat een aantal informatiesystemen die over redundante functionaliteiten beschikken. In §7.2.2 is daarvan een inventarisatie gemaakt. Enkele toepassingen beschikken over vrij specifieke functionaliteiten, bijvoorbeeld ten behoeve van risicoanalyses, het maken van berekeningen, lozingseisen vaststellen etc, die niet generiek zijn. Deze specialistische toepassingen worden ook door specialistische leveranciers ontwikkeld voor één specifiek doel. Integratie van deze toepassingen in een applicatie met een generieker karakter is dan ook meestal niet mogelijk. WVO-info is een modulair systeem waarbij veel specifieke functionaliteiten in de loop der ca 15 jaren zijn ontwikkeld. Huidig midoffice m.b.t. vergunningverlening en handhaving Een midoffice is zoals reeds vermeld, meestal ingericht om verschillende inkomende berichten (van verschillende soort) naar het juiste backofficesysteem door te sluizen. Dat het een doorgeef functie heeft en er op toeziet dat er geen gegevens verloren gaan of processen te lang duren. Daarnaast bevat het functionaliteiten die generiek toepasbaar zijn, een voorheen in de backofficesystemen aanwezig waren. Alleen SAP Havik beschikt momenteel over midoffice functionaliteit. Inkomende papieren documenten worden gescand in Maastricht (Shared service centre Vergunningen). De documenten en de inhoud van de documenten zijn vervolgens elektronisch beschikbaar in SAP, vaak worden ook de papieren documenten nog als backup bewaard. Er wordt van de betreffende vergunning een zaak aangemaakt. Dit gebeurt ook als het bericht elektronisch door de klant wordt aangebonden via de Website. Afhankelijk van het zaaktype (type vergunning) wordt de juiste werkstroom gestart. In theorie is SAP Havik toegerust om meerdere wetten te ondersteunen en meerdere soorten berichten te kunnen ontvangen. Dit zijn nieuwe configuraties (zaaktypen en werkstromen) van reeds aanwezige functionaliteiten. In praktijk wordt het niet door elke regio of district ook zo toegepast. Poststukken worden in TRIM geregistreerd, dus ook poststukken ten behoeve van vergunningverlening. 7.3.2 Huidige functionaliteiten Door het project Consolidatie NAT is al aangegeven welke applicaties uitgefaseerd moeten gaan worden. Enkele applicaties die in de verschillende vergunningverlening en handhavingsprocessen worden gebruik, zijn in Tabel 3 nader uitgewerkt. Enkele opvallende kenmerken: 1. veel applicaties hebben een eigen administratie (database) 2. veel applicaties hebben functionaliteiten ten behoeve van identity management, ofwel ze hebben een eigen autorisatie/ beveilingsschil.

88


3. verschillende zaaktypen (vergunningen, meldingen, besluiten) zitten in verschillende systemen en kasten. Om een integraal klantbeeld te krijgen, is het fysieke dossier over het algemeen het meest betrouwbaar. Niet alle vergunning zijn elektronisch toegankelijk. 4. veel applicaties hebben eigen management rapportage functionaliteit. In de ICT-branche worden bepaalde functionaliteiten aangeduid met een specifieke term. In bijlage 14.4 is een toelichting opgenomen m.b.t. de gehanteerde begrippen.

Functionaliteit

x x x x

x

x

x x

x x

x x

x

x x

x

x

x

x x

x

x

x x x

x x x

x x

x

x

x

x

x

x

x x x

x

x

x

x

x

x

x x x

x x

x

x

x

x

x

x x x x x x x x x x x x

x

x x

x

x

x

x

x

x x x x x x x x

x x x x x x

Tabel 3 Functionaliteiten per applicatie 7.3.3 Gebruik van huidige applicaties Veel van de benodigde functionaliteiten zijn in de huidige systemen aanwezig, alleen sluit deze functionaliteit niet voldoende aan op de wens van de eindgebruiker. Ook de ervarenheid van Rijkswaterstaat medewerkers om met informatiesystemen te werken is erg uiteenlopend. Vanuit praktische invalshoek wordt derhalve in de bedrijfsvoering van handhaving en vergunningverlening nog steeds gewerkt met papieren documenten en wordt de elektronische administratie (soms als sluitpost) door een management assistent bijgewerkt. Dit leidt tot erg versnipperde administraties, slechte kwaliteit van de gegevens en hogere kans op het maken van faalkosten (kosten als gevolg van het onjuiste informatie, onjuist geplande bezoeken etc).

89


GVG

NIS

RiAnth

SAP-HAVIK x x x x x x x

Infraweb

x

QuickLic

x

WIS

CoMa

Esperant

Media

x x x

Atloz

x x x

LABinfos

x x

WVO-BAWR

x x

WVO-LNV

WVO-heffinge

Tekstverwerking Document management Scannen Printen of aanleveren bij printstraat Workflowmanagement Business proces management Management informatie Geografische informatie Audit trail Factureren en incasso Contentmanagement Publiceren op internet Clientrelatie-management Casemanagement Identity management Catalogus Administratie (gegevensbeheer) Vraagpatronen Statistische functionaliteit Offline en online werken

WVO-Info

Applicaties

x

x

x

Voor handhavers is het dus een moeilijke opgave om een integraal beeld te kunnen krijgen van het te inspecteren bedrijf of object. Eén systeem dat door slechts weinig diensten gebruikt wordt is SAP Havik. Op verschillende aspecten is er ontevredenheid over het systeem. Dit leidt er toe dat in de vergunningverlening én bij de handhaving de gegevens slecht of niet worden geadministreerd in de SAP administratie. Als in het administratieproces onvoldoende kwaliteit wordt geleverd, heeft dat invloed op de kwaliteit van de gegevens, daardoor wordt de handhaver geconfronteerd met inaccurate informatie indien deze het zaakdossier wil raadplegen ten behoeve van bijvoorbeeld een ingeplande inspectie.

7.4 Mogelijk toekomstig ICT-landschap In deze paragraaf wordt een mogelijk toekomstig ICT-landschap geschetst zoals het er functioneel uit zou kunnen zien. Deze schets (zie Figuur 21) is gebaseerd op de functionele wensen van de eindgebruikers (teamleiders, vergunningverleners, handhavers en de functioneel beheerders). Het geeft zoveel mogelijk invulling aan de architectuurprincipes van Rijkswaterstaat en het gedefinieerde beleid. De functionele wensen zijn vastgesteld tijdens het project Digitale Handhaving én in dit lopende project Havik 2 in workshops. 7.4.1 Algemene uitgangspunten Bij het realiseren van de toekomstige ICT-inrichting wordt uitgegaan van een aantal aspecten, ingegeven door de workshops: 1. de gegevenshuishouding is op orde: alle noodzakelijke gegevens zijn elektronisch beschikbaar. Dit houdt in dat: a. alle bestaande vergunningen gedigitaliseerd zijn; b. vergunningen zijn gekoppeld aan GEOgrafische gegevens; c. pakketten die gebruikt worden voor de ondersteuning van (deel)processen een open database hebben. Dus gegevens zijn van buitenaf benaderbaar; 2. de processen (Verlenen van vergunningen en Handhaven) zijn diepgaand beschreven en worden in de verschillende regio’s en districten op (nagenoeg) dezelfde uitgevoerd; 3. de informatiebehoefte is in de verschillende regio’s en districten geïnventariseerd dus bekend en toegepast op Havik 2. 4. definities en standaarden van de verschillende administraties zijn geüniformeerd. 5. elk gegeven heeft één bron; 6. gebruikers interfaces van verschillende applicaties zijn op elkaar afgestemd. 7. de ICT-voorzieningen zijn generiek waar kan en specifiek waar moet. 8. eenvoudige processen worden volledig geautomatiseerd; 9. ICT-beleid voorkomt redundante functionaliteit en gegevensopslag. 10. er is beleid over werkstroombeheersing.

90


Ideale Voorzieningen Landschap VV

LVO

Gegevens opslag

Vergunning verlening

Infraweb

Financieel systeem

LNV

Koppeling OSB

Lims Belastingdien st

Vergunning Melding Besluit

BAWR COMA Media Esparant

koppeling

DIGID

Geg e vens m ag az ijn

bedrijf

Koppelingen

?

RWS website

gebouw en

personen Koppeling OSB

z a ak m g t

adressen burger Portal

C ontent mgt

besluitvorming

Loket lokaal

bedrijven

w etgeving

medewerker

almanak

Basisregistraties

FAQ's ...

Kadaster

Topo

GE O ‐ beheren

Koppeling OSB

koppeling

GEO

…

kernregistraties

Figuur 21 Mogelijk ICT landschap 7.4.2 Toekomstig frontoffice De burger en het bedrijf heeft één elektronisch en één fysiek loket voor zijn of haar contact met de overheid. Ook de medewerkers heeft via één (elektronische) ingang toegang tot de werkopdrachten. In feit ziet nog de klant, nog de medewerker wat er onder de motorkap gebeurd of wordt ingezet. In praktijk betekent dat het volgende voor vergunningverlening: • Het LVO-frontoffice en het Rijkswaterstaat frontoffice gekoppeld moeten zijn. De klant merkt niet dat het verschillende loketten zijn. • Voor andere vergunningen dan de Water- of Omgevingsvergunningen moet Rijkswaterstaat een frontoffice beschikbaar hebben wil de klant het “one-door shopping” concept kunnen ervaren. • Het frontoffice is voorzien van eigen identity management voorzieningen (zoals Digid) die voldoen aan de eisen van het veiligheidsbeleid van het Ministerie van VenW. • Dat ook content (kennis zoals wetgeving, business rules) beheerd moet worden en via internet en intranet beschikbaar gesteld moet worden, zowel via de LVO, het eigen frontoffice en de ingang van de vergunningverlener. • Een medewerker aan het fysieke loket kan via dezelfde elektronische frontoffice voorzieningen processen starten, mits voldaan is aan authenticatie en identificatie eisen.

91


•

• • •

De gegevens uit de LVO (zaak-identificatie e.d.) en de andere Rijkswaterstaat -frontoffice moeten overeenkomen met de administratie van Rijkswaterstaat. De klant moet statusinformatie kunnen ontvangen over de status van behandeling van zijn aanvraag. De vergunningverlener heeft één ingang om alle voor zijn/haar werk benodigde applicaties te kunnen benaderen. Alle elektronische informatie wordt in elk geval elektronisch vastgelegd en als bron aangeduid.

In praktijk betekent dit voor handhaven: • De handhaver heeft één ingang om tot alle voor zijn/haar taak noodzakelijke informatie te kunnen raadplegen, afgestemd op de behoefte van het proces dat hij/zij op dat moment uit wil voeren. • De handhaver heeft één ingang om toegang te krijgen tot applicaties. • Dat ook content (kennis zoals wetgeving, business rules) beheerd moet worden en via internet en intranet beschikbaar gesteld moet worden via de ingang van de handhaver. In praktijk betekent dit voor plannen, sturen en rapporteren: • Managers hebben één ingang om de informatie voor plannen, sturing en rapportage te verkrijgen. • Alle input voor de werkprocessen komt via één ingang binnen, een teamleider kan door classificatie van de inkomende berichten de type zaken (werklast) vaststellen. • Inzet van management informatiemiddelen, leidt tot betere management rapportages.

7.4.3 Toekomstig midoffice Het midoffice beschikt over één zakensysteem, over één documentmanagementsysteem en één procesmanagementsysteem. Alle binnenkomende berichten (elektronisch of fysiek) worden kanaalonafhankelijk gemaakt, ofwel alles wordt gedigitaliseerd en elektronisch beschikbaar gesteld aan de behandelprocessen. Er wordt per zaaktype een proces (werkstroom) ingericht en indien noodzakelijk vindt termijnbewaking plaats. Gegevens uit de taakspecifieke systemen en basisregistraties worden in een centraal gegevensmagazijn geplaatst. De bron van de gegevens blijven de backoffice administraties. 7.4.4 Toekomstig backoffice Gegevens worden op één plaats beheerd en op meerdere plaatsen gebruikt. Dit betekent niet dat de gegevens op maar één plaats geregistreerd hoeven te zijn. Als er maar beleid is en afspraken zijn gemaakt wie eigenaar (bronhouder) is van het gegeven. De koppeling met de landelijke basisregistraties is op één (Rijkswaterstaat-brede) manier geregeld. Indien noodzakelijk worden

92


alleen de identificerende (sleutel) gegevens van objecten uit de basisregistraties opgenomen in de Rijkswaterstaat administraties en worden de aanvullende gegevens er bij het daadwerkelijk gebruiken van de gegevens geautomatiseerd bijgehaald. Dit is een visie van de overheid op de langere termijn, technisch en organisatorisch is daarvoor nog veel voor nodig. Er ligt alleen een bedrijfsidentificatienummer (BIN of Kvk-nummer) van een “rechtspersoon” vast in de administratie bij een vergunning, als deze de vergunninghouder is. De adresgegevens worden niet geregistreerd in de administratie, op het moment dat een handhaver het dossier wil gebruiken voor bijvoorbeeld een mededeling, worden de actuele gegevens uit het centrale gegevensmagazijn gehaald, dat gekoppeld is met de basisregistraties. 7.4.5 Vier alternatieve oplossingsrichtingen In de voorgaande paragrafen is functioneel beschreven hoe het toekomstige ICT-landschap zal kunnen werken. De wijze waarop deze mogelijke toekomstige inrichting daadwerkelijk wordt gerealiseerd, kan op verschillende manieren plaatsvinden. Er worden in dit rapport vier oplossingsrichtingen geschetst waar de voor- en nadelen van zijn uitgewerkt. Er zijn nog meer scenario’s denkbaar, maar daarvoor ontbreekt de tijd om de consequenties diepgaander te vergelijken. Ten behoeve daarvan zijn er vier scenario’s onderkend: 1. Consolidatie van bestaande systemen met lichte aanpassingen om te voldoen aan de wet (nuloptie) 2. Verbetering en uitbouw SAP Havik, gegevensmagazijn (EIM) en klantbezoekregistratie (CRM) en maatwerkfunctionaliteiten (voormalig WVO-info) ten behoeve van handhaving 3. Combinatie van Vergunningverleningpakket, Datawarehouse (ETL) en CRM en maatwerkfunctionaliteiten (voormalig WVO-info) ten behoeve van handhaving 4. Service georiënteerde architectuur. De scenario’s 2 t/m 4 hebben als gemeenschappelijke eigenschappen dat de gegevenshuishouding op orde is en processen geharmoniseerd zijn. Daarvoor zijn ook projecten noodzakelijk die nader zijn uitgewerkt in de komende hoofdstukken. Deze vier oplossingsrichtingen zijn in hoofdstuk 8 nader uitgewerkt.

7.5 Programma van eisen Vanuit verschillende invalshoeken moet ICT voldoen aan bepaalde eisen. Om draagvlak te hebben bij de gebruikersorganisatie is de gebruikerswens tot op zekere hoogte maatgevend. Vanuit beleids-, beheersen technische invalshoek kunnen deze soms strijdig zijn. In die gevallen moeten compromissen gezocht worden.

93


7.5.1 Gebruikerseisen en wensen Ten aanzien van de ICT-ondersteuning voor de verschillende processen zijn uiteenlopende eisen en wensen geïnventariseerd, die zeer uiteenlopend zijn qua diepgang en aard. De woordelijke eisen en wensen zijn vastgelegd in separate verslagen van de workshops en de verslagen van het project Digitale Handhaving. De gebruikerswensen zijn in de workshops geïnventariseerd aan de hand van cases met betrekking tot: 1. Verlenen van vergunningen 2. Handhaven (gepland en ad hoc) 3. Behandelen van AMvB-meldingen 4. Genereren van management rapportages De eisen en wensen zijn geclusterd en geabstraheerd waar mogelijk. Onderwerp

Typering

Algemeen

Gebruikersvriendelijk

-

Algemeen

Uniformiteit

-

Algemeen

Toegankelijkheid

-

94

Omschrijving gebruikerswens

ICT-component / voorziening (service)

Eenduidige, intuïtieve bediening van de applicatie Alleen benodigde informatie op scherm Gebruik van iconen Uniformiteit van Gebruikersinterface met Windows-omgeving Anti-RSI voorzieningen (toetsenbord bediening) Duidelijke, eenduidige veldnamen

o o o

Portal (GUI) Gegevensmagazijn gegevensstandaardisatie

toepassen van één systeem voor taak ipv meerdere bestanden en verschillende procedures en werkwijzen per regio uniformiteit in processen. Single sign on Mobiel bereik (voldoende dekking)

o o o

zakensysteem document management workflow management

o o o o o

SSO webtoepassing GPS, MDA contentmanagement Portal


Onderwerp

Typering

Algemeen

Functionaliteiten

-

-

-

Verlenen van vergunningen

-

Geografische informatie


Kennisbank

-


Functionaliteiten

-

95


ICT-component / voorziening (service)

Automatisch genereren van brieven adhv ingevoerde gegevens Elektronische koppeling ivm publicatie van verleende vergunningen, besluiten etc. Goede import en export van gegevens Diverse zoekfuncties: steekwoorden, onderwerpen, persoonsgegevens, bedrijfsgegevens, geo-informatie Geschikt voor verschillende zaaktypen (vergunningen, meldingen, brieven, intrekkingen, maatwerkbeslissingen etc) Logboekfunctionaliteit Relatie tussen uitvoeringsplannen en daadwerkelijke prestaties. Automatische agendafunctie (werkopdrachten, vooroverleggen in agenda geplaatst bij medewerker) Digitale handtekening ook toegepast Geautomatiseerde dossieruitwisseling Bezwaren en beroepen in dossier Presenteren van geografische informatie uit de vergunningaanvraag op kaart Opvragen van reeds aanwezige vergunningen of andere aanvragen op basis van locatie info Ontsluiten van informatie over vaarwegen, hoofdwegennet Alle dossierinformatie (verschillende zaken) elektronisch beschikbaar Ontsluiten van weten regelgeving Ondersteuning adhv vragenboom (rules engines) Ondersteuning bij risicoanalyse

o o o o o

Geautomatiseerde verwerking van aanvraag in schermen Procesondersteuning: kunnen afleiden in welke behandelstap de gebruiker is Geautomatiseerde koppeling met financieel systeem termijnbewaking Volledig geautomatiseerd proces bij eenvoudige vergunningen Kunnen ontsluiten van diverse rapportages (MER’s) Status informatie tbv klant zichtbaar Informatie uit vooroverleg beschikbaar Archiefstukken voorgaande vergunningen

o o


o o o o o

o o o o o

o o o o o

o o o o o

report generator berichtuitwisseling open database zoekmachine koppeling met basisregistraties zakensysteem tracking en tracing identity management document management datawarehouse

geografische informatie GPS topografische informatie koppeling met basisregistraties enterprise content management kennismanagement/ contentmanagement rule engine vragenboom e-formulier specialistische functionaliteit tbv risicoanalyse berichtenuitwisseling workflowmanagement, business proces management financiële functionaliteit document management zakensysteem archiefsysteem enterprise content mgt

Onderwerp

Typering


Correspondentie

-

Genereren van ontvangstbevestiging tbv klant Templates tbv besluit, betaling, vervolg

Handhaven


-

Idem als vergunningverlening Zoekfunctionaliteit op basis van verschillende criteria: bedrijfsgegevens, locatiecoördinaten, kadastrale info, trefwoorden, lozingsobjecten Alle vergunningen elektronisch beschikbaar

-

-


ICT-component / voorziening (service) o o o o o o o o

Handhaven

Kennisbank

Functionaliteit

kennismanagement/ contentmanagement rule engine vragenboom e-formulier lozingsinformatie enterprise content management datawarehouse

-

Idem als vergunning verlenen Ontsluiten van weten regelgeving op locatie Ondersteuning bij risicoanalyse Gevaarlijke stoffenkennisbank raadpleegbaar

-

o

-

Verslaglegging mogelijk: rapportage + foto’s, video Koppeling met HUP Metingen kunnen “uploaden” Ingediende rapportages elektronisch beschikbaar Klantdossier benaderbaar Inspectiehistorie raadpleegbaar Kunnen genereren van checklist

o o o o o o

enterprise content management planningfunctionaliteit open database document management customer relation mgt journalisering archivering

o o o o o o o

Handhaven

e-formulieren templates report generator geografische informatie GPS topografische informatie koppeling met basisregistraties enterprise content management

Handhaven

Correspondentie

-

Inspectierapportages genereren Brieven (waarschuwingsbrieven, maatwerk)

o o o

e-formulieren templates report generator

Behandelen van AMvBmeldingen

Functionaliteit

-

Geautomatiseerde werkopdracht voor behandeling bij ontvangst

o

workflowmanagement

Genereren van management rapportages

Gegevensuitwisseling

-

Elektronische informatie uitwisseling periodiek met LNV OTV, WVO

o


Teamleiding

standaard voor berichtenuitwisseling standaard semantiek standaard syntax planning business Intelligence datawarehouse workflowmanagement human resourcesmanagement


-

-

Correspondentie

o o o o o o o

Verschillende vormen van planning Diverse rapportages kunnen genereren zonder tussenkomst van programmeur mbt meldingen, incidenten, werkvoorraad, overschrijdingen etc. Regio overstijgende rapportages Voortgang HUP, JUP, PIN’s Bezettingsgraden per regio (ziekte, verlof etc) Toedelingsfunctionaliteit Rapportages van en aan andere Rijkswaterstaat- o onderdelen

Tabel 4 Eisen en wensen van gebruikers

96


management rapportage

7.5.2 Eisen van Enterprise architectuur De principes uit de enterprise architectuur zijn richtinggevend voor de uiteindelijk te realiseren oplossing. In de volgende tabel worden de relevante principes genoemd. Deze principes zijn uitgewerkt in subprincipes. Principe

Omschrijving EAR-principe

12

1

RWS is toonaangevend opdrachtgever: a) Leverancier onafhankelijk b) Bij voorkeur geen eigengemaakte software

2

RWS is a) b) c)

3

4

publieksgericht netwerkmanager Zorgen voor publieksgerichte netwerkinformatie Netwerkinformatie van deur tot deur RWS informeert via een Multi-channel benadering d) Gebruikersvriendelijkheid e) Open standaarden voor de-facto standaarden f) Informatie is geschikt om door te geven RWS heeft regie op de informatiehuishouding a) De kwaliteit van de broninformatie moet door RWS geborgd kunnen worden b) RWS heeft altijd toegang tot broninformatie c) Stuurinformatie put uit dezelfde bron als de productie-informatie d) RWS hanteert een uniform begrippenkader met een duidelijke eigenaar van de begrippen RWS is een vernieuwende organisatie a) ‘proven’-technologie in cruciale bedrijfsprocessen b) Beheerste risico’s nemen bij de innovatie c) Succesvolle innovaties worden geïmplementeerd in de werkprocessen

12

ICT-component/service/ voorziening/aspect o Open source software o Open standaarden o Of-the-shelf o proven-technology o contentmanagement o Portal o open standaarden

o o o

o

o

o

gegevensmanagement gegevensmagazijn business informatie management rapportage

“moderne” voorzieningen “moderne” interfaces

Nummer refereert aan principenummering in rapport: Enterprise ArchitectuurPrincipes,

gemandateerd werkdocument 2008 19 juni 2008. Auteur P.C. Bernhard (EAR)

97


Principe

Omschrijving EAR-principe

12

RWS houdt rekening met de (onder)houdbaarheid van systemen a) Geen initiatieven zonder structurele financiering b) Life-cyclebenadering c) Kosten afschrijving d) Baten zijn inboekbaar e) Toekomstvastheid f) Systemen worden niet gekocht op basis van de laagste aanschafprijs 713 De informatieomgeving faciliteert de medewerker in zijn/haar rol en verantwoordelijkheid a) Mensen hebben de juiste middelen om efficiënt te werken b) Rol en verantwoordelijkheden van medewerker zijn duidelijk c) Medewerkers kunnen any-time, any-place beschikken over de benodigde informatie nodig voor hun rol en verantwoordelijkheid d) De aangeboden gegevens zijn maatwerk per type medewerker 9 RWS heeft één informatie-infrastructuur met goede ontsluitingsmogelijkheden a) Heel Rijkswaterstaat maakt gebruik van gemeenschappelijke voorzieningen b) Aansluiten bij internationale en interdepartementale standaarden 10 RWS is resultaatgedreven en ondernemend a) RWS stuurt op gemeten prestaties van de organisatie b) Besturing en bekostiging in één hand c) Eenduidig opdrachtgeverschap per fase d) Tussen fases overdracht met gatewayreview e) RWS werkt met architectuur Tabel 5 Eisen vanuit de EAR

ICT-component/service/ voorziening/aspect

5

o o o o o

portal alignment informatiebeleid datawarehouse enterprise content management

o

generieke componenten

o service oriëntatie

o o

o

business Intelligence enterprise architectuur informatie beleid

7.5.3 Architectuurprincipes NORA In Bijlage 14.1 staan de fundamentele NORA-architectuurprincipes benoemd. Enkele principes die nog minder expliciet in voorgaande paragrafen aan de orde zijn gekomen, worden in deze paragraaf aangehaald. Principe P1

Omschrijving NORA 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.

13

Interpretatie Havik 2 Gekoppelde internetsites LVO, Rijkswaterstaat, Helpdeskwater

Principe 6 staat vermeldt in hoofdstuk 6 mbt gegevensmanagement

98


Principe P3

Omschrijving NORA Eén loket gedachte “no-wrong door”

P4

Overheidsinstellingen werken samen om diensten te leveren, one-door-shopping

P5

Burgers, bedrijven en maatschappelijke instellingen beschikken over één identiteit die bruikbaar is voor alle contacten met organisaties in het publieke domein die afhankelijk van de soort dienstverlening ook nodig is en gevraagd moet worden. Uitvoeren van controles op vlotte dienstverlening

P6 P7

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

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.

P11

Organisaties geven aan op welke momenten en stadia in het dienstverleningsproces doorlopen worden en streven daarbij naar zo kort mogelijke doorlooptijden.

P12

Organisaties geven inzicht in de status van de lopende dienstverleningprocessen.

P15

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

P18

Organisaties in het publieke domein gebruiken gegevens die accuraat, actueel en volgens wettelijke normen beveiligd zijn

99

Interpretatie Havik 2 Bevoegd gezag is bekend (Rijkswaterstaat) Bevoegd gezag draagt zorg voor communicatie en coördinatie met andere organisaties Gebruik van basisregistraties en Digid.

Inrichten en uitvoeren van kwaliteitsmanagement Bezwaren en beroepenprocedures bekend, documenten toegankelijk. De websites van LVO en Rijkswaterstaat hebben een gelijkwaardige functionaliteit, die klant helpt met aanleveren van gegevens. Door toepassing van bijvoorbeeld eformulieren in het frontoffice. Procedures moeten bekend worden gemaakt. Goede afstemming met Rijkswaterstaat en LVO noodzakelijk Verstrekken van statusinformatie per zaaktype bekend. Traceerbaarheid en transparantie door toegankelijke gegevenshuishouding. Havik 2 zal voldoen aan de eisen uit de A&K-analyse.


Principe P19

Omschrijving NORA Gebruik waar mogelijk generieke componenten. Organisaties in het publieke domein streven er naar om beschikbare gemeenschap-pelijke voorzieningen te gebruiken, als deze op de punten functionaliteit, beveiliging en kosten gelijkwaardig zijn aan indi-viduele voorzieningen

Interpretatie Havik 2 Havik 2 heeft contact met E-Inspecties, NOiV (Open Source Software en Open Standaarden). Daarnaast wordt rekening gehouden met landelijke voorzieningen zoals door programma ODP14 worden gerealiseerd.

Tabel 6 Eisen vanuit de NORA

7.6 Koppelvlak Havik 2 heeft een breed aandachtsgebied, met een groot aantal koppelingen met de omgeving. Bij de definitieve afbakening en de te maken transitie van de Havik 2 administratie zal worden bepaald welke koppelvlakken er (zullen) zijn. Koppelvlakken worden zoveel mogelijk geüniformeerd. Het overbrengen van gegevens vindt plaats via elektronische berichten tussen applicaties onderling en/of via menselijke tussenkomst, of via fysieke media zoals tapes, dvd’s etc. Soms is een ‘vertaling’ van gegevens nodig, omdat bepaalde systemen verschillende “talen” spreken. “Message brokers” en “gateways” zijn hierbij gebruikte ICT toepassingen.Om een koppelvlak vorm te geven moeten afspraken gemaakt worden op verschillende niveaus (zie Figuur 22).

Ketenpartner 1

Ketenpartner 2

bedrijfsproces

gegevens

bedrijfsinformatie

interactieproces

gegevenselementen

gegevensdefinities

communicatiefunctie

bedrijfstransactie

bericht

applicatie communicatieprotocol communicatiefunctie

datacommunicatievoorziening

14

infrastructuur

infrastructuur

gegevens

bedrijfsdocument + bijlagen

applicatie

bedrijfsproces

OverheidsDienstenPlatform: programma binnen ICTU verantwoordelijk voor realisatie van

stelselvoorzieningen (OverheidsServiceBus, Terugmeldfaciliteit, etc).

100


Figuur 22 Koppelvlakken Afspraken betreffen de taakverdeling tussen werkprocessen (een proces levert een vordering op, het volgende proces maakt een factuur), de gegevens die de processen van elkaar nodig hebben, en de structuur waarin deze gegevens worden aangeleverd (formulier, bericht). Daarbij komen we bij technische aspecten als het om een digitaal bericht gaat en de structuur plus het communicatieprotocol ook in technische termen moet worden gespecificeerd (XML, SOAP). Tenslotte is er een algemene datacommunicatievoorziening nodig voor het transport.

7.7 Mobiel werken. Ontsluiting van informatie met behulp van mobiele voorzieningen, zoals een Mobile Digital Assistant is een wens vanuit de gebruikersorganisatie. Daarbij valt te denken aan verschillende vormen van mobiele ondersteuning. Binnen Rijkswaterstaat zijn enige initiatieven met mobiel werken uitgewerkt. Zo werken Handhavers binnen het 2sselmeergebied vanuit een mobiel kantoor. In de busjes van Rijkswaterstaat hebben handhavers een klein kantoor met de nodigde voorzieningen zoals een bureau, stoel laptop en blackberry als telefoon en agenda. De organisatie rondom de handhavers is toegespitst op deze nieuwe situatie waarbij een centrale planner de handhavers efficiënt inzet zodat de laatste zo min mogelijk op kantoor noodzakelijk zijn. De handhavers werken vanuit thuis en hebben via de online verbinding in de bus toegang tot alle benodigde gegevens en documenten. Bezoekverslagen worden direct in het veld uitgewerkt. Het IJsselmeergebied heeft de verschillende applicaties onderling procesmatig gekoppeld via een centrale applicatie QSPM. QSPM faciliteert per processtap de benodigde snelkoppelingen voor handhavers naar diverse applicaties, van toepassing zijnde wetteksten en documenten. Bij de Inspectie Verkeer en Waterstaat hebben handhavers de beschikking over ingebouwde tablets in hun auto’s. 7.7.1

MDA

Gedurende het project Digitale Handhaving is de noodzaak aangetoond om op locatie naast de reguliere telefonische GSM verbinding toegang te hebben tot e-mail (Outlook) en lijsten met contactpersonen, met name in situaties van (dreigende) calamiteiten. Tevens is ruimschoots onderbouwd dat handhavers op locatie de beschikking dienen te hebben over: • • •

101

navigatiefunctionaliteit voor het aanduiden van x- / ycoördinaten en vinden en duiden van locaties; zoekmogelijkheden op internet om omgevings- bedrijfs- en situatiespecifieke data te vergaren; het op locatie kunnen maken van foto- en video-opnames ter vastlegging van geconstateerde feiten;


•

het kunnen registreren van aandachtspunten in dictaat (memorecorder) of vlugschrift (aantekening).

Deze functionaliteit is voor de handhavers niet op locatie beschikbaar óf beschikbaar in afzonderlijke apparaten. Gevolg is dat de handhaver onvolledige, niet specifieke registraties maakt, of deze achteraf op rapport stelt waarbij kwalitatieve informatie (zoals foto´s, x-y coördinaten) ontbreekt. In de gevallen waarbij controles leiden tot sancties is de bewijslast voor Rijkswaterstaat achteraf moeilijk samen te stellen. De handhavers gaven in aan hun waarnemingen te doen in het vrije veld (veelal zonder de nabijheid van de auto waarin de mobiele werkplek is geïnstalleerd), waarbij slechts een klein elektronisch hulpmiddel ter ondersteuning kan worden gebruikt. De voorkeur van de handhaver gaat uit naar een upgrade van de GSM-standaard naar een MDA (mobile digital assistent): een combinatie van de bestaande GSM met een Personal Digital Assistent. 7.7.2 Gebruikerseisen en wensen tav Mobiel werken Ontsluiting van informatie met behulp van mobiele voorzieningen, zoals een Mobile Digital Assistant is een wens vanuit de gebruikersorganisatie. In diverse gesprekken en workshops zijn de eisen en wensen van de gebruikers geïnventariseerd. Het onderzoek is toegespitst op de dagelijkse praktijk van de handhavers en nabije ontwikkelingen binnen het werkgebied van Handhaving en Toezicht voor: 1. Handhaven (gepland en ad hoc) 2. Behandelen van AMvB-meldingen Uit gesprekken met handhavers bleek er een diverse en soms tegenstrijdige behoefte aan verschillende eigenschappen. Zo moet het apparaat het liefst zo klein mogelijk zijn, maar moet het wel een goede mogelijkheid hebben tot gegevensinvoer en waarbij gegevens, documenten en kaarten vanaf het beeldscherm goed leesbaar zijn. Voor de ene handhaver is het genoeg om fatsoenlijk gegevens te kunnen raadplegen vanuit de auto, de ander geeft aan dat het echt vanuit een klein en handzaam apparaat moet zodat hij het bij zich kan dragen. Sommige functionaliteiten worden vaker genoemd. Zo is een GPS met x,y en z coördinaten een absolute must. Ook het hebben van een camera waarmee de situatie direct vastgelegd kan worden, behoord tot deze categorie. De requirements met betrekking tot de MDA zijn in onderstaande tabel geclusterd en waar mogelijk geabstraheerd: Typering Gebruiksvriendelijkheid

102

- Omschrijving gebruikerswens - Hanteerbaar apparaat - Eenduidige, intuïtieve bediening van de applicatie - Mogelijkheid van eigen toetsenbord of extern toetsenbord


Connectiviteit

GSM en Internet Hoge bandbreedte internet Online en offline kunnen gebruiken Toepassing Telefoneren Navigatie Foto’s maken Memorecorder Gebruik Het scherm moet in het donker en bij zonlicht raadpleegbaar zijn - Het apparaat moet tegen redelijke weersomstandigheden kunnen Functionaliteit - E-mail en Agenda inzien en beheren - Documenten en kaarten kunnen raadplegen - Op internet diverse gegevens kunnen opzoeken (windsnelheden en stroomversnellingen) - Wetteksten raadplegen - Geografische en kadastrale gegevens van object - Excel en Word bestanden lezen en bewerken - Calamiteit gegevens kunnen raadplegen Beveiliging - Data encryptie - (vingerafdruklezer) - Bescherming tegen virussen - Tegen oneigenlijk gebruik Beheer - Remote management - Meerdere soorten applicaties kunnen gebruiken GPS - X, Y en Z coördinaten inmeten en registreren - Nauwkeurigheid van 2 – 5 cm Tabel 7 Eisen ten aanzien van Mobiel Werken -

7.7.3 Advies MDA Gebruikers hebben aangegeven het mobiele apparaat ook te willen gebruiken als telefoon. Nadeel hiervan is dat de huidige functie van de telefoon in MDA niet gebruiksvriendelijk is op een aantal onderdelen een achteruitgang betekent aan functionaliteiten ten opzichte van in gebruik zijnde toestellen. Mede om deze redenen wordt er in het advies voor mobiele apparaten, ook apparaten meegenomen welke geen telefoonfunctie hebben. Een marktverkenning voor MDA is in de kosten en baten analyse opgenomen. Uit het onderzoek blijkt dat de werkzaamheden in het veld voor handhavers verschillend is. Zo zijn er verschillende groepen te onderscheiden met elk hun eigen programma van eisen. Een groep wil mobiel bereikbaar zijn en tegelijkertijd de agenda met email kunnen beheren. Daarnaast kan het handig zijn om een navigatiemiddel beschikbaar te stellen. Vanwege de al aanwezige infrastructuur met Blackberry’ is het een mogelijk een optie om voor een algemene groep de Blackberry Storm met navigatie beschikbaar te stellen.

103


Voor specifieke doelgroepen van Handhavers kan op grond van bovenstaand programma van eisen en de initiële marktverkenning, een industriële mda of rugged mda/pc beschikbaar te stellen. Van belang is onderscheid te maken voor gebruikers van kaarten, tekeningen en verder documenten welke niet vanaf een klein scherm leesbaar zijn. Daarnaast willen gebruikers diverse aantekeningen en bezoekverslag kunnen verwerken. Voor deze groep van gebruikers sluit een draagbare pc het beste aan de eisen en wensen. De uiteindelijke keuze voor een mobiel apparaat is vooral afhankelijk van de te ontwikkelen applicaties voor het mobiele domein en de beschikbaarheid van de gekozen oplossingrichting in het werkveld. Verder zijn een aantal randvoorwaarden van belang wil de handhaver tot tevredenheid het werk kunnen verrichten. De belangrijkste zijn dat de gegevens en andere bronnen gedigitaliseerd en beschikbaar zijn over een snelle en aanwezige verbinding. Mede op advies van IVW wordt eerst aandacht besteed aan de correct inrichting van de Backoffice, alvorens deze paragraaf diepgaand wordt uitgewerkt. Daarnaast wordt geluisterd naar signalen van Scheepvaart. Het project ICT op Schepen heeft ervaringen opgedaan met verbindingen tussen de mobiele werkplek (op schepen) en SAP Havik als backofficesysteem. Daarbij zijn technische “uitdagingen” aan het licht gekomen die nog onderzocht worden door het Havik 2 projectteam.

7.8 Kennistool De handhavers van Rijkswaterstaat hebben tot taak om burgers en bedrijven te controleren op de naleving van circa 15 wetten en een aantal Algemene Maatregelen van Bestuur waar Rijkswaterstaat het bevoegd gezag voor is. Deze wetgeving is in veel gevallen gedetailleerd en complex, zeker indien meerdere wetten tegelijk op één situatie van toepassing zijn. De handhaver heeft hiervoor in het veld slechts parate kennis ter beschikking en op kantoor wetboeken of digitale wetboeken via CD-rom of internet. Hier wordt in de praktijk slechts sporadisch gebruik van gemaakt. Vergunningverleners maken bij het samenstellen van vergunningen en bij voorlichting aan burger en bedrijf, gebruik van wetten en interpretatie. Het snel vinden van relevante wetten en tekstenblokken zal het werk efficiënter en doelmatiger maken. De Inspectie van Verkeer en Waterstaat heeft sinds enkele jaren een digitaal hulpmiddel ter beschikking die het mogelijk maakt per situatie aan de hand van criteria een selectie te maken van de wetgeving die op een bepaalde situatie van toepassing is. Een dergelijk hulpmiddel valt in de categorie Business Rule Management Systeem (BRMS). Hiermee is het gemakkelijk om regels vast te leggen, na te zoeken en de beslissingslogica uit te voeren. 7.8.1

104

Functionaliteiten kennistool


IVW heeft een onderzoek15 laten verrichten om vast te stellen of met de kennismanagementapplicatie Easyrules de juiste keuze is gemaakt door IVW. Het resultaat van het onderzoek is dat Easyrules voldoet aan de criteria die IVW hanteert voor Business Rule Management Systemen (BRSM). Daarnaast wordt geadviseerd om aan te sluiten aan het releasemanagement van de leverancier en niet te veel maatwerk toe te passen. Om de aan BRSM gerelateerde functionaliteiten specifieker te kunnen

beoordelen worden door onderzoeksbureau Gartner zeven componenten gehanteerd, waar een BRSM uit is opgebouwd. 1. Execution Engine a. Uitvoeren en beheren van regels b. Logica met betrekking tot het uitvoeren van regels 2. Repository a. Database waarin business rules worden opgeslagen b. Opslaan van verschillende verzamelingen regels c. Versiebeheer om verschillende (gebruikerafhankelijke) verzamelingen regels te maken d. Geavanceerde zoekmogelijkheden 3. Integrated Development Environment a. Grafische, gemodelleerde ontwikkelomgeving om regels te creëren, te ordenen, testen en debuggen 4. Rule-model simulation a. Grafische regel-simulatie tool waarmee what-if analyses gemaakt kunnen worden om het onderlinge verband tussen regels te analyseren 5. Monitoring and analyses a. Levert historische en runtime statistieken en gebruiksrapportages o.a. tbv audittrails 6. Management and administrator a. Tools om regels toe te voegen en/of te activeren, b. beveiligingsbeheer, toevoegen van nieuwe regels, systeemanalyse uit te voeren 7. Rule Templates a. Voorgedefinieerde verzamelingen regels tbv specifieke sector De handhavers geven aan dat er behoefte is aan een tool waarmee ze gemakkelijk gegevens kunnen raadplegen. Het raadplegen richt zich hierbij voornamelijk op het raadplegen van wetteksten.

7.9 Conclusies kennistool Belangrijk is dat de kennistool aansluit bij handhavers en vergunningverleners. Na aanleiding van diverse gesprekken met handhavers blijkt dan men vooral de wens heeft om weten regelgeving te raadplegen en overtreders op de feiten van de wet te confronteren. Tijdswinst valt vooral te behalen wanneer men voor de situatie specifiek, bijbehorende weten regelgeving kan raadplegen en bevindingen direct kan registeren. Nu vindt dat plaats via openbare websites en is de actualiteit niet altijd goed vast te stellen. 15

Rapport “Ontsluiting Wet- en Regelgeving IVW” door HEC 27-10-2008

105


In de markt wordt deze functionaliteit als dynamische checklisten aangeprijsd. Een concreet voorbeeld hiervan is wanneer een handhaver een binnenvaartschip handhaaft met een bepaalde lengte en loodlijn. De kennistool toont direct welke weten regelgeving van toepassing is op deze parameters. De checklist loodst de handhaver verder via een vragenboom langs de relevante aandachtspunten, waarmee direct de antwoorden kunnen worden vastgelegd De uiteindelijke versie van de Waterwet is niet bekend is en de algemene regels zijn nog vastgesteld. Tot deze tijd is het niet mogelijk om een kennistool in te richten zonder dat er naderhand dubbel werk moet worden verricht. De kennistool is verder afhankelijk van de gekozen oplossingsrichting. Als men alleen bewezen technologie wil voor samenwerkende applicaties, is Haley Office Ruls (voorheen RuleBurst) goed te combineren met SAP Netweaver voorzieningen. Bij IVW is Easyrules in gebruik. Koppelingen met andere systemen zijn niet bekend. De functionaliteit van checklisten heeft daarnaast alleen toegevoegde waarde als deze wordt gekoppeld aan kwaliteitsmanagement. Kwaliteitsmanagement bepaalt in welk proces per weten regelgeving een specifieke checklist nodig heeft. Door de afhankelijkheden is een gefundeerde keuze voor een kennistool op dit moment niet mogelijk.

106


8 ICT-Oplossingsrichtingen Dit hoofdstuk beschrijft vier oplossingsrichtingen voor een betere ondersteuning van de generieke bedrijfsprocessen Verlenen van vergunning en Handhaven, inclusief het Plannen, Sturen en Rapporteren. Daarbij zijn de figuren uit hoofdstuk 7 enigszins vereenvoudig om de overzichtelijkheid te bewaren. Er is uit planningsoverwegingen gekozen voor de uitwerking van vier oplossingsrichtingen. Er is echter een groot aantal andere varianten denkbaar. De vier oplossingsrichtingen zijn in de kosten/baten analyse cijfermatig voor zover mogelijk onderbouwd. Daarvoor wordt verwezen naar de Kosten/baten-analyse Havik 2 In voorliggend definitiestudierapport worden de vier ICT-oplossingsrichtingen beoordeeld op de punten in Tabel 8. Beoordelingscriterium Alignment Gebruikersvriendelijkheid Kwaliteit Openheid/connectiviteit

Omschrijving mate waarin de functionele vraag kan worden ingevuld mate van instelbaarheid voor gebruiker robuustheid en stabiliteit mate van koppelbaarheid met andere systemen, portalen en gegevensbronnen Flexibiliteit Aanpasbaarheid aan nieuwe zaaktypen, wetgeving, organisatie Toekomstvastheid duurzaamheid van de oplossing Kosten het kostenniveau voor exploitatie en de investering voor realisatie en implementatie Doorlooptijd de benodigde tijd voor realisatie van de uiteindelijke oplossing als implementatie geheel Compliancy / mate waarin de ICT-oplossing past in het ICT-landschap van architectuur Rijkswaterstaat. Beheer mate van beheerbaarheid, functioneel en technisch beheer Capaciteit mate van noodzakelijke ICT-voorzieningen (hardware, technische infrastructuur Organisatie organisatorische aanpassing tbv implementatie en exploitatie Beveiliging noodzakelijke voorziening voor beveiliging Hosting noodzakelijke voorzieningen/maatregelen voor hosting Tabel 8: Beoordelingscriteria De huidige situatie (baseline) is bepalend voor de waardering van de oplossingsrichtingen. Dit hoofdstuk begint met de bespreking van de huidige situatie voor de informatievoorziening. Daarna wordt in aparte paragraven een invulling gegeven aan de vier genoemde oplossingsrichtingen. Hierbij wordt per beoordelingscriterium een uitwerking gegeven. In paragraaf 8.6 wordt vervolgens gekeken naar welke huidige componenten in het ICT landschap kunnen worde hergebruikt. In de laatste twee paragraven wordt dan een vergelijking gemaakt van de oplossingsrichtingen op basis van de beoordelingscriteria, wat leidt tot een conclusie voor de oplossingsrichtingen.

107


8.1 Huidige situatie informatievoorziening Als referentie voor de verbeteringen wordt de huidige situatie gehanteerd.

Optie 0: Huidige situatie Frontoffice

Mid-/Backoffice Website


SAP Havik

Administraties

Man info

Man info

Proces Digitalise ren post

Proces

Gegevens

SAP Havik

SAP Havik

Website RWS

Man info Gegevens

Proces

WVOinfo

WVOinf o Uitvoeren analyses

Man info

Gegevens

GEO

Proces GEO inf o

Elektronisch loket

Taakspecifieke gegevens

GIS vergunningen

Man info AMvB Melding proces

bedrijf

LVO

Fysiek loket

Papieren document en

burger

Portal voor handhaver

Handhaven

Internet

Verwerken WVOf ormulier

Verwerken brieven

Verwerken Verwerken Journaal Journaal In Word / SAP Excel Leveren informatie externe bron

AMvB meldingen

Papieren Papieren vergunnin beschikkin gen gen Papieren Papieren gedoogbe besluiten sluiten Journalen Risico analyses Inspectie Wetrapportages regelgeving

Figuur 23 Huidige situatie ICT landschap Op dit moment wordt het proces vergunningverlening ondersteund door in de volgende applicaties: • SAP Havik • WVO-info cluster • WIS • Kantoor automatisering (MS Word, Excel & Project) Daarnaast worden nog een aantal applicaties gebruikt bij het inhoudelijk behandelen (bv. voor het uitvoeren van analyses) van een vergunningaanvraag of melding AMvB. Voorbeelden hiervan zijn Quicklic (voor voorschrift teksten), KRW-processen (beoordelen van lozingen) en Lozingseis-assistent (opstellen lozingseisen). Alleen SAP Havik heeft een elektronisch frontoffice. De LVO wordt per eerste kwartaal 2009 door het Ministerie van VROM ter beschikking gesteld voor de meldingen AMvB (m.n. Activiteitenbesluit), waarvoor Rijkswaterstaat in bepaalde gevallen ook bevoegd gezag is. Nu

108


(februari 2009) is er voor het Activiteitenbesluit de AIM (Activiteitenbesluit Internet Module). Behalve voor het Besluit Inrichtingsgebonden Activiteiten en het besluit Particulier Huishoudens kan voor alle andere AMvB’s WVO-info worden gebruikt voor registratie en ondersteuning. Voor zaaktypen die geen vergunningen zijn (meldingen, brieven, adviesverzoeken etc) wordt de standaard kantoorautomatisering gecombineerd met fysieke opslag gebruikt voor de ondersteuning. Op dit • • • • • •

moment wordt het proces handhaven ondersteund door: SAP Havik WVO-info cluster WIS Generiek vergunningen GIS (GVG) QSPM (voor Dienst IJsselmeergebied) als portal Kantoor automatisering (MS Word, Excel & Project tbv planning)

De vergunningen in SAP Havik kunnen niet via een GIS applicatie op een kaart worden geprojecteerd. Voor WVO-info kan daar ATLOZ (onderdeel van het WVO-info cluster) voor worden gebruikt, zolang de coordinaten zijn ingevuld. GVG bevat vergunningen die vóór 2006 zijn verleend, maar worden wel via GIS gepresenteerd op de kaart. De meeste informatie moet de handhaver echter op papier raadplegen. Registratie van de bezoeken en handhavingsacties wordt ondersteund door SAP Havik en WVO-info, maar met name SAP Havik sluit hier niet aan bij de wensen van de gebruiker. De getoonde Portals in de afbeelding vormen de werkplek van de handhaver. Veel applicaties (dus schermen) moeten apart geopend worden en er dient voor elke applicatie apart te worden ingelogd. Op dit moment wordt het proces plannen, sturen en rapporteren ondersteund door: • SAP Havik • WVO-info cluster • WIS • COMA & RiAnTH • Kantoor automatisering (MS Word, Excel & Project) Het plannen van zowel vergunningverlening als handhaving gebeurd grotendeels met de kantoorautomatisering, waarbij COMA & RiAnTH alleen ondersteuning bieden voor de risico analyse. Het rapporteren en sturen is wel mogelijk met SAP Havik, WIS en WVO-info, maar ook hier wordt veelal de kantoorautomatisering gebruikt. Beoordelingscriterium

Omschrijving huidige situatie

109


Beoordelingscriterium Alignment

Gebruikersvriendelijkheid

Kwaliteit Openheid/connectiviteit Flexibiliteit

Toekomstvastheid

Kosten Doorlooptijd implementatie Compliancy / architectuur Beheer

Omschrijving huidige situatie • In WVO-info is maatwerk verricht op bepaalde functionaliteiten. Daarover is men in het algemeen tevreden. • SAP Havik sluit niet aan bij de processen is een veel gehoorde mening, behalve bij Scheepvaartverkeercentrum (SVC). Bij SVC voldoet SAP Havik beter aan de wensen. • Men is reeds jaren gewend om met WVO-info te werken. De gebruikersvriendelijkheid is wisselend. SAP Havik wordt als gebruikersonvriendelijk ervaren door Handhaving en Vergunningverlening aan de Natte kant. • Het feit dat men uit verschillende bronnen informatie moet halen, wordt als gebruikersonvriendelijk ervaren. • Er is nog geen sprake van Single sign on, dat betekent veel inloghandelingen voor de medewerker. • De kwaliteit van de ICT-inrichting in termen van beschikbaarheid, volledigheid en juistheid is onvoldoende vanwege de diversiteit. • Vanwege de diversiteit van systemen en administraties is koppeling met andere (externe) bronnen moeizaam en inefficiënt. • De huidige ICT-ondersteuning is moeizaam aan te passen aan nieuwe wetgeving. Technisch gezien is SAP Havik modulair opgezet en kan het ‘snel’ aangepast worden nieuwe wetgeving. (los van de gebruiksvriendelijkheid) • Op dit moment is WVO-info outdated, ofwel aan het einde van de levenscyclus. SAP Havik is nog in de beginfase van de levenscyclus. GVG wordt nog doorontwikkeld om bestaande vergunningen te ontsluiten, WIS wordt uitgefaseerd. • Baseline zie kosten/baten-analyse Havik 2 • Niet van toepassing • • •

Capaciteit Organisatie Beveiliging

• • •

Hosting

•

De huidige situatie sluit niet aan bij de meeste architectuurprincipes van Rijkswaterstaat. WVO-info is in eigen beheer. Beheer van SAP Havik is ondergebracht bij CBI16. De beheerprocedures worden als omslachtig ervaren als gevolg van gemeenschappelijk gebruik van SAP met de IVW. Baseline Niet van toepassing Per applicatie moeten medewerkers apart toegang krijgen. Er is geen eenduidig beeld van wie waar toegang toe heeft. Niet van toepassing

8.2 Oplossingsrichting 1: Consolidatie huidige systemen Met de komst van de Waterwet en een eventuele nieuwe Binnenvaartwet zal Rijkswaterstaat maatregelen moeten nemen om de processen voldoende te ondersteunen met ICT. Een nuloptie (ofwel niets doen) is dus geen optie. Met bestaande voorzieningen en enkele

16

Directie Concern Bedrijfsprocessen & Informatie bij Min VenW

110


aanpassingen en vergezeld door procedurele aanpassingen, kan Rijkswaterstaat wel invulling geven aan de eisen vanuit de wetgeving.

Optie 1: Consolidatie WVO info en SAP VV en HH na Waterwet Mid-/Backoffice

Frontoffice

Man info Proces Digitalise ren post

Website SAP Havik voor niet WW


Administraties Gegevens

SAP Havik

Man info

(centraal)

Proces SAP Havik Gegevens

Elektronisch loket

Koppeling

Routering

Proces

LVO

GEO

Man info Geo Vergunning en

Word / Excel etc WIS

RWSMedewerker

AMvB Melding proces

behandel dossier

Handhaven



Portal Portal voorvoor Portal voor handhaver handhaver handhaver HAVIK WVO Internet

GEO (centraal)

Basisregistraties (Topo, kadaster)

Gegevens

GEO

Basisregistraties

AMvB meldingen

Basisregistraties

Man info

GVG

Fysiek loket

(centraal) Uitvoeren analyses

Basisregistraties (NHR, GBA, BAG)

Gegevens

GBA NHR BAG

burger

WVOinfo

Man info WVOinfo

bedrijf

Basisregistraties (NHR, GBA, BAG)

Verwerken brieven Verwerken Journaal In Word / Excel

Verwerken Journaal SAP (crm)

Leveren informatie externe bron

Leveren MGT informatie

Papieren Papieren vergunnin beschikkin gen gen Papieren Papieren gedoogbe besluiten sluiten

Journalen Risico analyses Inspectie Wetrapportages regelgeving

Figuur 24 ICT landschap oplossingsrichting 1

8.2.1 Maatregelen voor vergunningverlening Uitgangspunt voor de realisatie van optie 1 is het nemen van noodzakelijke maatregelen om de Waterwet te kunnen ondersteunen met zo min mogelijk aanpassingen van de huidige systemen. Structurele veranderingen voor bijvoorbeeld verbetering van het proces van plannen, sturen en rapporteren vindt niet plaats. De Waterwet schrijft het gebruik van de LVO min of meer voor. Dat betekent dat het one-door shoppingsconcept moet worden ingevuld. Dit kan plaatsvinden, door de frontoffices van de LVO te koppelen aan de backoffice systemen van Rijkswaterstaat. De LVO [1]17 kan op twee wijzen communiceren met de buitenwereld: via elektronisch berichtverkeer en via e-mail. Om vast te kunnen stellen

17

Deze nummering correspondeert met de nummering van projecten in hoofdstuk 9 tbv

migratie.

111


welke wet van toepassing is, moet een voorziening worden ingericht voor ondersteuning van “routering”. Dit kan organisatorisch, procedureel per regio en/of elektronisch in de vorm van een postbus, of door middel van een zakensysteem dat het zaaktype herkent aan de hand van de berichten uit de LVO [2]. Dan moet vastgesteld worden welke proces gestart moet worden op basis van wetgeving. Indien deze processtap routeren elektronisch wordt gerealiseerd dan moeten de zakensystemen van Sap Havik en WVO-info geconfigureerd worden voor de Watervergunning [3]. Ook de gebruikersvriendelijkheid wordt bij voorkeur mee genomen in de aanpassingen. Voor bestaande vergunningen en meldingen AMvB in SAP die niet via de LVO komen, blijven bestaande voorzieningen in stand. Deze voorziening wordt wel aangepast zodat de Watervergunningen (en verwante meldingen AMvB) via de LVO worden aangevraagd. Ten behoeve van de Watervergunning moet ook statusinformatie worden verstrekt. Dit vereist een beheerprocedure [4]. Er moet een keuze worden gemaakt om gebruik te maken van de behandelmodule van de LVO [5]. In de LVO ontstaan dossiers die administratief gekoppeld moeten kunnen worden aan de backoffice (bijvoorbeeld via een zaaknummer) in SAP of WVO-info [6]. Er zijn vervolgens twee varianten mogelijk: 1. Voor Watervergunningen die nu in WVO-info geregistreerd worden kan het betekenen dat bij “routering” een formulier moet worden samengesteld, door een Rijkswaterstaat medewerker om WVO-info te vullen. Waar ook het zaaknummer uit de LVO wordt gebruikt. De watervergunningen worden ingevoerd in WVO-info indien er lozingsgegevens geregistreerd moeten worden. 2. Vanaf de inwerkingtreding van de Waterwet, worden alle nieuwe vergunningen geregistreerd in SAP Havik. Voor lozingsnormen wordt tijdelijk een “dummy”-vergunning met hetzelfde SAP/LVO zaaknummer opgevoerd in WVO-info zodat voor de handhaving een aantal technische en administratieve controles in gebruik kunnen blijven, totdat voor deze functionaliteit een andere oplossing is ontwikkeld [4]. Vanuit het “routeren” zal de klant op de hoogte gehouden moeten worden van de voortgang van het vergunningverleningproces. Om vervolgens de juiste gegevens vast te kunnen leggen, zullen gegevens gestandaardiseerd of op elkaar afgestemd moeten worden [7]. Als Rijkswaterstaat kiest voor het gebruik van de behandelmodule in de LVO, moet er iemand verantwoordelijk worden gemaakt voor de administratieve handelingen in de LVO [8]. 8.2.2 Maatregelen voor Handhaven Voor handhaving zitten er weinig verbetering in deze optie, gezien vanuit ICT-technisch opzicht. Om wel een aantal gebruikerswensen in te kunnen vullen, kan een aantal maatregelen worden getroffen. Een belangrijke maatregel is hierbij het digitaliseren van bestaande dossiers en koppelen aan bestaande zaken in WVO-info en/of SAP

112


(vergunningen, maatwerkbesluiten, gedoogbesluiten, briefwisselingen ofwel ongestructureerde content) [9] en het elektronisch ter beschikking stellen van de dossiers via een toegang tot de elektronische administratie [10]. Als de toegang elektronisch is, bijvoorbeeld via een Portal, kan overwogen worden om meerdere applicaties te koppelen aan het Portal, zodat de handhaver meerdere bronnen via één toegang kan benaderen. Dit houdt in dat op het gebied van beveiliging een technische oplossing vastgesteld moet worden die aansluit op eventuele uitkomsten van het lopende onderzoek bij Ministerie van VenW naar Single Sign On. Voor SSO zijn verschillende implementatievarianten mogelijk. De keuze voor oplossingsrichting is in grote mate bepalend voor de wijze van SSO-implementatie. De overige voorzieningen rondom WVO-info blijven intact zoals automatische termijnbewaking voor administratieve verplichtingen en de controle op lozingsnormen en bedrijfsafvalrapportages. Ook bezoekverslag kunnen in WVO-info worden vastgelegd. Voor de handhaving kan een kennistool (voor het ontsluiten van weten regelgeving bijvoorbeeld in de vorm van checklists) worden geselecteerd, dat eventueel benaderd kan worden via de portal [11]. Maatregelen van algemene aard Er is wetgeving aangenomen (Wet GBA) en er komt nieuwe wetgeving aan (Nieuw HandelsRegister Wet per 1-7-2008 in werking, invoering loopt waarschijnlijk tot 2014) die voorschrijft dat gegevens uit basisregistraties gebruikt moeten worden door overheidsinstantie bij de uitvoering van wettelijke taken, zoals het verlenen van vergunningen, het interveniëren bij handhaving (processen verbaal), en de behandeling van bezwaar of beroep. De gegevens uit de basisregistraties worden ter beschikking gesteld aan zowel vergunningverleners als handhavers [12]. Dit betekent een aanpassing van elk betrokken systeem. Daarbij moeten ook de processen worden aangepast, om altijd actuele gegevens uit de basisregistraties te gebruiken bij wettelijke taken. 8.2.3 Beoordelingscriterium Alignment

113

Beoordeling optie 1 Omschrijving optie 1 • De werkprocessen blijven afwijken van de UPP en systemen worden functioneel slechts marginaal aangepast om beter aan te sluiten. Het alignment probleem blijft bestaan. • Voor vergunningverlening ontstaan nieuwe processen en verantwoordelijkheden waarvan getwijfeld wordt of dat een vooruitgang is. • Het is haast niet mogelijk om met de aangepaste ICTondersteuning één vergunning te kunnen verlenen, die mogelijk in verschillende systemen zijn geregistreerd. Dit is een gevolg van de samenvoeging van wetgeving.


Beoordelingscriterium Gebruikersvriendelijkheid

Kwaliteit

Openheid/connectiviteit Flexibiliteit

Toekomstvastheid

Kosten

Doorlooptijd implementatie

Compliancy / architectuur Beheer Capaciteit

Organisatie

Beveiliging Hosting

Omschrijving optie 1 • Voor handhaving kan een stap gezet worden om via een ICT voorziening dossiers (content) te kunnen ontsluiten. De handhaver moet zelf gegevens verzamelen en met elkaar in verband brengen. • De bestaande applicaties blijven in gebruik, met hun beperkte gebruikersvriendelijkheid. • Er is mogelijk sprake van Single Sign On voor toegang tot de verschillende applicaties. • De complexiteit neemt aanzienlijk toe. Elke voorziening behoudt de eigen management rapportage functionaliteiten, derhalve is sturing ook minder goed mogelijk. • Vanwege de toegenomen complexiteit neemt de openheid van de oplossing af. • Er komen meer componenten bij in plaats van dat er minder ICT-voorzieningen komen. De aanpasbaarheid van de oplossing neemt af. • Deze oplossing zou slechts korte tijd kunnen voortbestaan, in verband met de toename van complexiteit. • Het Portal voor handhaving zou toekomstvast kunnen zijn, mits voldaan wordt aan functionele en technische eisen van de uiteindelijk te realiseren voorzieningen voor Havik 2. • Het kostenniveau stijgt: o Er komen meer ICT-voorzieningen o Er moeten meer handelingen worden gedaan in verband met de basisregistraties, de Waterwet en synchronisatie van bestaande administraties. • De procedurele maatregelen zijn snel te realiseren. • Een portal heeft pas zin, als de backoffice op orde is. In deze oplossing is daarvan geen sprake. Voor het ontsluiten van content kan een snelle portaloplossing wel soelaas bieden. • Deze nieuwe situatie sluit niet aan bij de meeste architectuurprincipes. • Beheer complexiteit neemt toe als gevolg van de relatie met de basisregistraties. • Indien alle content gedigitaliseerd wordt zal de systeemcapaciteit toe moeten nemen. • Door de extra routering is er meer capaciteit nodig. • De organisatie wordt erg complex, omdat meerdere partijen verantwoordelijk zijn voor het leveren van diensten aan klanten, en omdat er meer partijen bij het beheer betrokken zijn. • Tenzij de portaloplossing hier invulling aan kan geven, verandert dit aspect weinig. • Er komen nieuwe voorzieningen die gehost moeten worden.

8.3 Oplossingsrichting 2: SAP Havik + CRM en Datawarehouse oplossing De oorspronkelijke doelstelling van SAP Havik was ondersteuning bieden aan alle vergunningverlenende en handhavingsprocessen van

114


verschillende wetten. Vanwege de complexiteit is de Wet Verontreiniging Oppervlaktewater niet in de eerste fase van het SAP Havik-project meegenomen. Daardoor bestaat voor de WVO nog de toepassing WVO-info. Er zijn wel verschillende andere wetten geïmplementeerd in SAP Havik. Uitgangspunt voor deze oplossing is het (grotendeels) realiseren van de oorspronkelijke doelstelling van SAP Havik I. De doelstelling was het stroomlijnen van de vergunningverleningsprocessen waarbij met één systeem gewerkt wordt ter ondersteuning. Daarnaast is het faciliteren van de handhaving met moderne middelen een uitgangspunt. Tijd- en plaatsonafhankelijk werken wordt hierbij steeds belangrijker. Derhalve wordt verzien dat meer informatie elektronisch ter beschikking gesteld moet worden. Ook het plannen en rapporteren wordt hierin meegenomen. Daarnaast ligt er een aantal ontwerpbeslissingen aan deze oplossing ten grondslag: • De processen handhaven en verlenen van vergunningen hebben een eigen eenheid van tijd, plaats en handeling. Hetgeen inhoudt dat voor de keuze voor ICT-oplossingen gekeken wordt naar aparte voorzieningen voor de verschillende processen. • De processen hebben de (gegevens over) vergunningen gemeenschappelijk. • Voor managementrapportage wordt voor handhaving en vergunningverlening één voorziening beschikbaar gesteld [23]. 8.3.1 Maatregelen voor vergunningverlening Naast het inrichten van het koppelvlak met de LVO voor de Watervergunning, moet ook een digitaal loket beschikbaar blijven voor niet-Watervergunningen. Dat is een bestaande voorziening die aangepast moet worden [1]. Daarnaast kunnen nog steeds op papier aanvragen (en bijlagen) worden aangeleverd. De Waterwet schrijft voor dat het bedrijfsleven in beginsel alleen elektronisch een aanvraag kan indienen voor de Waterwet. Ook andere vergunning aanvragen worden bij voorkeur elektronisch ontvangen. Dit betekent dat er een voorziening moet komen die de verschillende typen elektronische berichten, emails, papieren en elektronische documenten kan verwerken. Ook voor uitgaande berichten of documenten moet er een voorziening zijn waarin alle communicatie wordt gebundeld [13]. Alle berichten ten behoeve van één aanvraag, melding of ander verzoek van de klant moeten in één dossier worden ondergebracht.

115


Optie 2: SAP Havik uitbouwen (PSRM) VV en CRM en DWH voor HH Mid-/Backoffice

Frontoffice

Man info

Website SAP Havik voor niet WW

Kennisbank

Vergunning verlening Elektronisch loket

Man info

LVO

Administraties

Koppeling

Medium onafhankelijk maken

Gegevens

Proces SAP Havik

SAP Havik

Basisregistraties

Routering


Specif ieke f unctionaliteit

bedrijf

Portal voor vergunnin gverlening burger

Fysiek loket

Man info

Gegevens

Basisregistraties

GEO

Proces GEO-inf o

Papieren Document en

RWSMedewerker


Handhaven

Verwerken Journaal CRM

Journalen

Verzamelen informatie (ETL)

Wetregelgeving

Leveren informatie (interne/exter ne bronnen

Risico analyses Inspectie rapportages

Figuur 25 ICT landschap oplossingsrichting 2 Niet alleen aanvragen voor een vergunning, maar ook adviesverzoeken, gedoogverzoeken, AMvB-meldingen [14] moeten geregistreerd kunnen worden en naar de juiste Rijkswaterstaat medewerker of backofficesysteem gerouteerd worden. Daarvoor moet SAP Havik dusdanig worden geconfigureerd dat verschillende zaaktypen (waarbij een zaak een apart verzoek van een klant is) kunnen worden behandeld. De SAP Havik voorziening binnen Rijkswaterstaat is specifiek ingericht voor de overheidsmarkt. De module PSRM (Public Sector Records Management) is uitgerust met functionaliteiten die noodzakelijk zijn voor de correcte afhandeling van administratieve processen, die behoren bij verschillende zaaktypen. Centraal binnen de PSRM is de dossiervorming. Door voor de Waterwet een koppeling te realiseren tussen LVO en het reeds aanwezige SAP-zakensysteem in PSRM, kunnen nieuwe vergunningtypen (de Watervergunning) in de bestaande componenten worden ingevoerd [15]. Op basis van gegevensanalyse worden gegevens uit WVO-info (en WIS) geconverteerd, die gemapt kunnen worden op het gegevensmodel van SAP. Een aantal objecttypen worden niet binnen SAP geregistreerd [16]. Ten behoeve het beheer van deze objecttypen zal functionaliteit ontwikkeld worden, bijvoorbeeld voor de registratie van bedrijfsafvalrapportages en lozingsnormen. Stapsgewijs zal functionaliteit kunnen worden toegevoegd aan SAP Havik die nu in WVO-info voorhanden is. Dit betekent een uitbreiding van het gegevensmodel en de mogelijkheden van SAP. WIS wordt in deze oplossing uitgefaseerd [26].

116


De koppeling met de basisregistraties wordt gelegd voor persoonsgegevens (door het toevoegen van het BurgerServiceNummer en BedrijfsIdentificatie-Nummer) en mogelijk ook adres of kadastrale gegevens. Een belangrijke functionele wens van de gebruikers is de verbetering van de gebruikersvriendelijkheid van het SAP Havik-systeem [3].

8.3.2 Maatregelen voor handhaven Bij het proces van handhaving vindt meer dossiervorming plaats rond de klant, daar waar bij vergunningverlening de aandacht uit gaat naar de documenten van een vergunningaanvraagof AMvB-melding. De handhaving legt bezoekverslagen, rapportages en klantgegevens vast. Dit vereist uitgebreidere en andere functionaliteit dan in PSRM (waarschijnlijk) aanwezig is. SAP heeft hiervoor een CRM (Customer Relations Management)-module die mogelijk beter aansluit bij de Handhavingprocessen18 [17]. Op het moment dat een vergunning verleend is, een melding is ontvangen of een besluitvormingsproces is afgerond, kan dat aanleiding zijn om een werkopdracht voor handhaving in te plannen. In een business proces management voorziening (BPM) of workflowmanagement voorziening (WFM) [18] wordt een werkopdracht gestart om handhavingsprocessen op te starten. De handhaver krijgt daarvan een notificatie in zijn agenda [19]. Hierbij wordt ook aangesloten op de jaarplannen die worden gemaakt op basis van risico analyses. WVO-info bevat functionaliteit die nog niet in SAP aanwezig is, maar waar uitdrukkelijk om wordt verzocht door handhavers. Dit betreft o.a. het automatisch bewaken van lozingsnormen op basis van lozingsmonster en bewaking rondom bedrijfsrapportages. Ook de koppelingen met externe applicaties voor uitwisseling van gegevens met WVO-info, voor bijvoorbeeld het Ministerie van LNV of risico analyses zijn functionaliteiten die in SAP gerealiseerd moeten worden. Om alle informatie uit verschillende systemen te kunnen ontsluiten is een gegevensmagazijn wenselijk [21]. Dit heeft ook voordelen bij de koppeling met basisregistraties. De handhaver heeft een portal [10] tot zijn beschikking, waarmee hij alle benodigde relevante gegevens kan ontsluiten, zonder veelvuldig een inlogprocedure te moeten doorlopen. Een belangrijke voorwaarde voor dit alternatief is het verbeteren van de gebruikersvriendelijkheid. Belangrijk bij het portal is ook een koppeling met de GEO-database om de gegevens rondom een vergunning of melding AMvB op basis van locaties op te kunnen vragen [20]. Mogelijk dat GVG dit nog kan blijven ondersteunen, ook voor SAPvergunningen. 18

IVW is voor de inspecties van vliegtuigen en treinen begonnen met een pilot voor

toepassing van SAP CRM.

117


Naast een voorziening om (on)gestructureerde informatie te kunnen ontsluiten, heeft de handhaver ondersteuning nodig om kennis te kunnen ontsluiten. Aan de hand van een aantal vragen moet de handhaver snel vast kunnen stellen, welke (nieuwe) wet-, regelgeving en jurisprudentie [11, 22] van toepassing is op een situatie of gebeurtenis die hij op locatie aantreft. Hiermee kan een handhaver gericht toezicht uitoefenen. 8.3.3 Beoordelingscriterium Alignment


Kwaliteit

Openheid/connectiviteit

Flexibiliteit

118

Beoordeling optie 2 Omschrijving optie 2 • Mits de processen goed geconfigureerd kunnen worden binnen SAP, de processen uniform worden uitgevoerd, de gegevenshuishouding op orde is gebracht, wordt de alignment aanzienlijk verbeterd. • De portaloplossingen voor zowel vergunningverlener als handhaver biedt de mogelijkheid om alleen relevante functionaliteiten aan te bieden aan de gebruiker. Ook de bediening van SAP Havik wordt in deze optie flink verbeterd. • Door de verbeterde (gestructureerde) gegevenshuishouding kan de kwaliteit van dienstverlening en bedrijfsvoering verbeteren. • Een gegevensmagazijn (datawarehouse) dwingt gegevensstandaardisatie af, waardoor miscommunicatie zal afnemen en de kwaliteit van de gegevens toeneemt. • Doordat slechts één administratie voor vergunningverlening voorhanden is, wordt de connectiviteit vereenvoudigd. SAP is geen open administratie, daarom zal nog een voorziening door de leverancier ontwikkeld moeten worden om de gegevens te ontsluiten. • Het gegevensmagazijn voor de handhaving is slechts een laag over bestaande of nieuwe administraties heen. Afhankelijk van gewenste actualiteit zal de openheid en toegankelijkheid van de gegevens kunnen verbeteren. • Aanpasbaarheid aan nieuwe zaaktypen, wetgeving, organisatie blijft lastig indien het functioneel beheer ingericht blijft, zoals in de huidige situatie. Daarin is een afhankelijkheid met andere SAP-gebruikende organisaties. Het is in SAP wel mogelijk om deze verandering door te voeren. • Door het inrichten van een gegevensmagazijn (datawarehouse) wordt het eenvoudiger om maatwerk te leveren aan verschillende vergunningverlening en handhavingsprocessen Rijkswaterstaat breed.


Beoordelingscriterium Toekomstvastheid

Kosten

Doorlooptijd implementatie

Compliancy / architectuur

Beheer

Capaciteit

Organisatie

119

Omschrijving optie 2 • Door het werken met één administratie en configureerbare functionaliteiten voor vergunningverlening kan technisch relatief snel worden ingesprongen op nieuwe wetgeving (mits het beheer goed is geregeld, zie ook Flexibiliteit). De overheid ontwikkelt in toenemende mate beleid om met Open Source Software en Open Standaarden te gaan werken. Daarbij raken gesloten pakketten zoals SAP uit de gratie. • Door het gegevensmagazijn te implementeren wordt het eenvoudiger om nieuwe (verplichte) basisregistraties en kernregistraties aan te sluiten aan de voorzieningen. • De kosten zijn uitgewerkt in de kosten/baten analyse. • Bij het structureren van de gegevenshuishouding moet een investering plaatsvinden om de digitalisering plaats te laten vinden en gegevens uit verschillende administraties te converteren. • Belangrijke baten worden in elk geval behaald door het digitaliseren van archieven en dossiers en het verbeteren van de kwaliteit van de gegevens. • Afhankelijk van de snelheid waarmee de leverancier van SAP de wijziging technisch kan doorvoeren, zal de implementatietermijn korter zijn ivm het wegvallen van WVO-info. Op dit moment worden meerdere systemen naast elkaar gebruikt, de aanpassing beperkt zich dan alleen tot SAP. • De leverancier heeft aangegeven op basis van een FIT-GAP analyse tussen WVO-info en SAP Havik bepaalde functionaliteiten nog geen oplossing in SAP te zien. • Rijkswaterstaat heeft een divers ICT-landschap waar SAP onderdeel van uitmaakt. Door het inrichten van generieke voorzieningen zoals een gegevensmagazijn, portals en het hergebruiken van bestaande voorzieningen wordt tegemoet gekomen aan een aantal architectuurprincipes. Desondanks is SAP ook strijdig met een aantal architectuurprincipes. • Het beherenvan het -ICT-landschap van vergunningverlening en handhaving wordt vereenvoudigd als gevolg van het verdwijnen van een aantal applicaties. Functioneel en technisch beheer van SAP zal echter in complexiteit toenemen als gevolg van het creëren van meerdere zaaktypen in de administratie. Daarnaast wordt een aantal generieke voorzieningen ingericht, waarvoor binnen Rijkswaterstaat nog de verantwoordelijkheid zal moeten worden belegd. • Het gebruik van basisregistraties leidt tot nieuwe beheerprocessen [24]. • WVO-info en WIS zullen uitgefaseerd worden. Wellicht dat specialistische functionaliteiten zoals het automatisch bewaken van lozingsnormen toch behouden zullen blijven omdat het niet in SAP mogelijk is. Dit zal nog nader onderzocht moeten worden. • Er vindt een verschuiving plaats voor opslag en berichtuitwisseling (bandbreedte) richting SAP. • WVO-info beheerprocedures moeten herzien worden voor specialistische functionaliteiten.


Beoordelingscriterium

Omschrijving optie 2 • De organisatie zal beter kunnen inspringen op wijzigingen, doordat er minder voorzieningen aanwezig zijn. • Er is weinig draagvlak voor het toepassen van SAP voor de onderhavige processen. Hieraan moet expliciet gewerkt worden. • Eén goede identiteitmanagement voorziening is noodzakelijk. Ook aansluiting op PKI-overheid19, DigiD, etc. maakt hier onderdeel van uit.. • Het SAP account breidt uit met SAP CRM • Een aantal nieuwe voorzieningen worden ingericht: o Gegevensmagazijn (inclusief datamarts en datawarehouse) o Enterprise content management o Portal

Beveiliging

Hosting

8.4 Oplossingsrichting 3: Vergunningpakket, CRM-pakket en Datawarehouse voor HH De overheid is op dit moment erg actief op het gebied van ontwikkelen van voorzieningen om de Omgevingsvergunning (WABO) te kunnen verlenen. Met behulp van Open Source Software en Open Standaarden wordt hard aan de weg getimmerd om passende oplossingen te realiseren. Daarnaast zijn veel pakketleveranciers inmiddels ver gevorderd met het ontwikkelen van oplossingen specifiek voor vergunningverlenende processen. De pakketten omvatten midoffice functionaliteiten zoals zakensystemen, gegevensmagazijnen en servicebussen. Dit is vergelijkbaar met SAP uit optie 2, maar een vergunningenpakket is specifiek inzetbaar voor het werkveld. Ze zijn veelal ook geschikt om te communiceren met basisregistraties. Uitgangspunt voor deze oplossing is het creëren van één voorziening voor vergunningverlening door het selecteren van een pakket. Daarnaast, conform optie 2, het faciliteren van de handhaving met moderne middelen. Tijd- en plaatsonafhankelijk werken wordt hierbij steeds belangrijker. Derhalve wordt verzien dat meer informatie elektronisch ter beschikking gesteld moet worden. Daarenboven komt het verder structureren van de gegevenshuishouding.

19

PKI overheid is een beveiligingsprotocol van de Rijksoverheid.

120


Optie 3: Vergunningpakket voor VV, CRM-pakket en DWH voor HH Mid-/Backoffice

Frontoffice

Administraties

Man info Website voor niet WW

Kennisbank


Kernregistraties (incl GEO)

Vergunning pakket

Vergunning gegevens

Man info

Elektronisch loket

LVO

Koppeling

Medium onafhankelijk maken

Routering

Specifieke functionaliteit

bedrijf

Portal voor vergunnin gverlening

Basisregistraties

Man info Proces GEO-info

burger

Fysiek loket

Papieren Document en

RWSMedewerker


Handhaven

Verwerken Journaal CRM

Journalen

Verzamelen informatie (ETL)

Wetregelgeving

Leveren informatie (interne/exter ne bronnen

Risico analyses Inspectie rapportages

Figuur 26 ICT landschap oplossingsrichting 3 8.4.1 Maatregelen voor vergunningverlening In principe komt dit alternatief overeen met optie 2, met het verschil dat niet SAP, maar ook andere pakketten of Open Source Software integrale ondersteuning vormen voor de verschillende processen20. Om een vergunningverlening pakket te selecteren moet een gedetailleerd programma van eisen worden opgesteld (een aanbestedingsbestek) en zal een aanbestedingsprocedure moeten worden gestart [27]. Hierbij kan SAP uiteraard ook als potentiële oplossing weer inschrijven. 8.4.2 Maatregelen voor handhaven Wat aan deze oplossing is toegevoegd ten opzichte van optie 2 is het nog verder structureren van de gegevenshuishouding. Er worden centrale gegevensmagazijnen ontwikkeld, waar alle applicaties gebruik van maken. Daarbij worden gegevensdiensten geleverd vanuit zogenaamde kernregistraties voor Rijkswaterstaat specifieke gegevens en ook gegevensdiensten vanuit de Basisregistraties. Er hoeven binnen 20

NB: Projectteam Havik 2 heeft contact gelegd met NOiV (Nederland Open In

verbinding) dat is een landelijke stichting die overheidsinstellingen begeleid in het selecteren van Open Source Software en Open Standaarden. Op dit moment (feb 2009) wordt nog gezocht naar een vorm van samenwerking.

121


Rijkswaterstaat geen gegevens geregistreerd te worden die ook in de Basisregistraties aanwezig zijn. Er worden zoveel mogelijk referenties opgenomen, zoals het KvK-nummer of BurgerServiceNummer [25]. 8.4.3 Beoordelingscriterium Alignment


Kwaliteit

Openheid/connectiviteit

Flexibiliteit

Toekomstvastheid

122

Beoordeling optie 3 Omschrijving optie 3 • Mits de processen goed geconfigureerd kunnen worden binnen het vergunningenpakket, de gegevenshuishouding op orde is gebracht, wordt de alignment aanzienlijk verbeterd. • De portaloplossingen voor zowel vergunningverlener als handhaver biedt de mogelijkheid om alleen relevante functionaliteiten aan te bieden aan de gebruiker. • Door de gebruiker te betrekken bij de implementatie en het inrichten van het vergunningpakket en de portalen, wordt de gebruikersvriendelijkheid flink vergroot. • Door de verbeterde (gestructureerde) gegevenshuishouding kan de kwaliteit van dienstverlening en bedrijfsvoering verbeteren. • Een gegevensmagazijn (datawarehouse) dwingt gegevensstandaardisatie af, waardoor miscommunicatie zal afnemen en de kwaliteit van de gegevens toeneemt. • Doordat slechts één administratie voor vergunningverlening voorhanden is, wordt de connectiviteit vereenvoudigd. • Door het inrichten van kernregistraties en het toepassen van open source software kan de openheid aanzienlijk worden verbeterd. • Het gegevensmagazijn voor de handhaving is slechts een laag over bestaande of nieuwe administraties heen. Afhankelijk van gewenste actualiteit zal de openheid en toegankelijkheid van de gegevens kunnen verbeteren. • Aanpasbaarheid aan nieuwe zaaktypen, wetgeving, organisatie is in de meeste vergunningpakketten goed. • Bij implementatie moet rekeninggehouden worden met generieke en specifieke functionaliteiten in de verschillende vergunningverlenende processen. • Door het inrichten van een gegevensmagazijn (datawarehouse) wordt het eenvoudiger om maatwerk te leveren aan verschillende vergunningverlening en handhavingsprocessen Rijkswaterstaat breed. • Door het werken met één administratie, configureerbare functionaliteiten voor vergunningverlening kan technisch relatief snel worden ingesprongen op nieuwe wetgeving. • De overheid ontwikkelt in toenemende mate beleid om met Open Source Software en Open standaarden te gaan werken. Dit is een kans om daaraan invulling te geven. • Door het gegevensmagazijn te implementeren en gegevensdiensten te definiëren, wordt het eenvoudiger om nieuwe (verplichte) basisregistraties aan te sluiten aan de voorzieningen zonder dat er systeemaanpassingen nodig zijn.


Beoordelingscriterium Kosten

Doorlooptijd implementatie Compliancy / architectuur

Beheer

Capaciteit

Organisatie

Beveiliging

Hosting

Omschrijving optie 3 • De kosten zijn uitgewerkt in de Kosten/baten analyse. • Bij het structureren van de gegevenshuishouding moet een investering plaatsvinden om de digitalisering plaats te laten vinden, gegevens uit verschillende administraties te converteren en gegevensdiensten te ontwikkelen. • Belangrijke baten worden behaald door het digitaliseren van archieven en dossiers en het verbeteren van de kwaliteit van de gegevens • Afhankelijk van de keuze voor een type vergunningpakket kan de implementatie snel plaatsvinden. • Door bij de keuze van een vergunningpakket aan te sluiten op de architectuurprincipes van Rijkswaterstaat kan hier beter aan worden voldaan. • Door het inrichten van generieke voorzieningen zoals een gegevensmagazijn en portals wordt ook toegewerkt naar de architectuurprincipes. • Het beheer van het ICT landschap voor vergunningverlening en handhaving wordt vereenvoudigd. • Een nieuwe ICT voorziening voor vergunningverlening zal moeten worden toegewezen aan een verantwoordelijke. Daarnaast wordt een aantal generieke voorzieningen ingericht, waarvoor binnen Rijkswaterstaat nog de verantwoordelijkheid zal moeten worden belegd. • Het gebruik van basisregistraties leidt tot nieuwe beheerprocessen [24]. • WVO-info, SAP Havik en WIS zullen uitgefaseerd worden. Wellicht dat specialistische functionaliteiten zoals het automatisch bewaken van lozingsnormen toch behouden zullen blijven. • WVO-info, SAP Havik en WIS beheerprocedures moeten herzien worden voor specialistische functionaliteiten. • De organisatie zal beter kunnen inspringen op wijzigingen, doordat er minder voorzieningen aanwezig zijn. • Eén goede identiteitmanagement voorziening is noodzakelijk. Ook aansluiting op PKI-overheid, DigiD, etc. maakt hier onderdeel van uit.. • Een aantal nieuwe voorzieningen worden ingericht: o Gegevensmagazijn (incl datamarts) o Vergunningenpakket o Enterprise content management o Portal

8.5 Oplossingsrichting 4: Service georiënteerde architectuur De burger en het bedrijfsleven worden steeds mondiger. Dit leidt ertoe dat de overheid erg actief is om de dienstverlening te verbeteren. Ook Rijkswaterstaat heeft als doelstelling publieksgerichter te gaan werken. Dit vereist een hoge mate van flexibiliteit van zowel mensen, organisatie als ICT. Een service georiënteerde architectuur draagt

123


hieraan bij doordat diensten geleverd kunnen worden aan de klant zonder grote brokken functionaliteit of kennis in één component of afdeling te stoppen. Hiervoor worden services of componenten ingericht die afzonderlijk in te zetten zijn. Door samenwerkende services kan zonder al te veel aanpassing een nieuw proces worden ingericht om nieuwe diensten te kunnen leveren of om nieuwe wetgeving te ondersteunen. Uitgangspunt voor deze oplossing is het principe “generiek wat kan, specifiek wat moet”. Elke dienst die geleverd wordt is een resultaat van samenwerkende elementaire services. Elke service heeft de juiste granulariteit, zodat deze eenvoudig los te koppelen is en te vervangen is door een andere service. Deze oplossing geeft invulling aan de visie van de Overheid om een eerlijkere markt te creëren voor softwareleveranciers om oplossingen aan te bieden en daarmee een einde te brengen aan de vendor lock-in van grote softwareleveranciers.


Portal Vergunningverlener

Management informatie service

RWSMedewerker

Elektronisch loket

LVO bedrijf

Koppeling (OverheidsServiceBus)


Management Management inf ormatie

Zaken magazijn

Specialistische inf ormatie service services service

Koppeling (servicebus)

Archief service

Worksflow management service

Koppeling (OverheidsServiceBus)

Optie 4: Service georiënteerde architectuur VV en HH

Basisregistraties

Kernregistraties

Document behandeling service Externe bronnen

financiële afhandeling service

burger


Fysiek loket

Handhaven

Portal voor handhaver Customer Relation Mgt

Figuur 27 ICT landschap oplossingsrichting 4 De Directie Data van Rijkswaterstaat heeft reeds in 2007 een visie ontwikkeld over de wijze waarop Service Oriëntatie kan worden ingericht bij Rijkswaterstaat Voor Havik 2 zou het betekenen dat de Vergunningverlening, Handhaving, Meldingen en rapportage processen volledig ondersteund worden door services. Daarbij zijn de volgende algemene kenmerken van toepassing:

124


•

Een service is duidelijk gedefinieerde functie die een component (ICT of organisatie) aanbiedt aan andere componenten of ICTvoorzieningen; De services zijn ook los van elkaar toe te passen; het streven is om elke functionaliteit door één service te laten uitvoeren en redundante functionaliteit voorkomen;

• •

Momenteel is alleen de service voor Postregistratie (TRIM) binnen Rijkswaterstaat bestempeld als generiek én is afgesproken dat TRIM het pakket is, waar postregistratie in plaats moet vinden. Zoals reeds vermeld is, zijn voor het Havik 2 werkveld services noodzakelijk ten behoeve van onder andere documentverwerking, zakenmanagement, werkstroombeheersing, termijnbewaking, archivering, kennismanagement, etc.[28]. Deze functionaliteiten zijn in SAP Havik aanwezig als één grote module, ofwel één service. Door elke functionaliteit als aparte service te definiëren, kunnen aparte pakketten of voorzieningen worden gezocht om hetzelfde resultaat te kunnen leveren. Elke service zoals in paragraaf 7.5 is benoemd, is op de markt verkrijgbaar als apart pakket. Aan deze optie ligt een fundamentele keuze ten grondslag. Rijkswaterstaat werkt nu taakgericht, “elk probleem een eigen systeem”. In Service Georiënteerde Architectuur wordt meer procesgericht gedacht, waarbij processen als een “samenwerking van services” wordt beschouwd [29]. Een voorbeeld van Service Georiënteerd denken is: “kopen we de beste digitale videocamera waar we ook foto’s mee kunnen maken, of kopen we voor hetzelfde budget een goede video en een aparte fotocamera?” Elke optie leidt ertoe dat je zowel foto’s als video’s kunt opnemen. De optie van een aparte video en fotocamera biedt echter wel meer flexibiliteit. Er kunnen zelfs meerdere personen tegelijkertijd met de “voorziening” werken. Je kunt een nieuwe component kopen, zonder de andere daarvoor te hoeven aanpassen. Koop je alles geïntegreerd heeft als voordeel dat je slechts één beheer plaats hebt, er kan echter slechts één persoon met de “voorziening” werken in verschillende processen. Om een Service Georiënteerde Architectuur goed te kunnen toepassen zijn extra voorzieningen nodig zoals een servicebus voor communicatie en een servicecatalogus waarin staat welke services ontwikkeld zijn en geschikt zijn voor hergebruik. 8.5.1 Beoordelingscriterium Alignment

Gebruikersvriendelijkheid Kwaliteit

125

Beoordeling optie 4

Omschrijving optie 4 • Een SOA (service oriented architecture) is volledig in te richten naar de wensen van de omgeving. Alignment hoeft derhalve nimmer een probleem te zijn. • De gebruiker heeft voorzieningen op maat tot zijn beschikking en ziet niets van de onderliggende complexiteit. • De kwaliteit wordt bepaald door de “zwakste” schakel.


Beoordelingscriterium Openheid/connectiviteit

Flexibiliteit Toekomstvastheid

Kosten

Doorlooptijd implementatie Compliancy / architectuur Beheer

Capaciteit Organisatie

Beveiliging Hosting

Omschrijving optie 4 • De vaak specifieke koppelingen van applicaties worden vervangen door een kleiner aantal generieke koppelingen en servicebussen. Door het communiceren via servicebussen, wordt de connectiviteit aanzienlijk verbeterd, mits de juiste standaarden worden toegepast. • De SOA is optimaal aanpasbaar, mits de granulariteit van de services juist is. • Op dit moment is de visie van de overheid gericht op een service georiënteerde architectuur en het gebruik van Open Standaarden en Open Source Software. De implementatie van een volledige SOA gaat echter lange tijd in beslag nemen. • De kosten zijn uitgewerkt in de Kosten/baten analyse. • Het inrichten van een SOA gaat met hogere investeringskosten gepaard omdat vele generieke services moeten worden gerealiseerd voor Havik 2. Deze kosten worden echter snel terugverdiend, als de services voor meer dan handhaving en vergunningverlening kunnen worden toegepast. • Beheerkosten zullen aanzienlijk dalen. • Bij het structureren van de gegevenshuishouding moet een investering plaatsvinden om de digitalisering plaats te laten vinden, gegevens uit verschillende administraties te converteren en gegevensdiensten te ontwikkelen. Op langere termijn wordt de investering terugverdiend. • Het vervangen van alle services uit bestaande systemen door generieke services en het uitfaseren van deze systemen zal meerdere jaren in beslag nemen (min. 3 tot 5 jaar). • Aan de meeste architectuurprincipes wordt hiermee voldaan, mits gekozen wordt voor bewezen technologie. • Beheer zal volledig anders moeten worden ingericht, in verband met het generieke karakter van de oplossing. Services worden immers Rijkswaterstaat breed ingezet. • Nieuwe voorzieningen moeten worden ingericht, zoals servicebussen, brokers. • Het werken met services is niet alleen een ICT-vraagstuk, maar ook een organisatorisch vraagstuk. Uiteindelijk moeten generieke en specifieke taken belegd worden. • Beveiliging zal moeten voldoen aan Overheidsrichtlijnen. • Per service kan dit anders worden ingericht.

8.6 Herbruikbare componenten Alle vier de oplossingsrichtingen gaan uit van een aantal functionaliteiten die in Figuur 28 schematisch zijn weergegeven .

126


ECM

Identificatie/ authenticatie

Inkomend bericht

Elektronische formulieren

Gebruikers interface vergunningverlening Elektronisch Dossier (zaken)



Elektronische beschikkingen

Kennistool

Werkstroombesturing

DWH

LVO Document management Scanstraat Financieel systeem

Rapportage Tool (management Informatie)

Printen / document genereren

Uitgaand bericht


Koppelingen / connectiviteit Kantoorautomatisering

Archivering

Figuur 28 Overzicht functionele componenten Elke functionaliteit kan gezien worden als een service. Voor sommige functionaliteiten zijn reeds voorzieningen in gebruik, alleen zijn deze functionaliteiten in een pakket samengevoegd, zoals in SAP Havik. Deze functionaliteiten zijn dan ook moeilijk van elkaar los te koppelen. Losse services zijn juist de essentie is van service georiënteerde architectuur. In Tabel 9 is een inventarisatie gemaakt van functionaliteiten en huidige voorzieningen, die mogelijk als een service kunnen worden hergebruikt, zonder dat daarvoor eventueel een nieuw pakket aangeschaft hoeft te worden [30]. Functionele component LVO

ICT-voorziening externe website (CMS)

Bestaand / nieuw nieuw

Bruikbaar in SOA ja


Rijkswaterstaat website (Content management systeem)

Bestaand voor SAP en Rijkswaterstaat website

na aanpassing is mogelijk om één CMS te gebruiken

Nieuw, nu per systeem inloggen, Identitymanagement voor SAP aanwezig

Nog niet bekend

alleen binnen SAP

Identificatie / authenticatie DIGID of Identitymanagement SAP SSO Elektronische formulieren

E-forms

Bestaand voor SAP

Scanstraat Gebruikers interface vergunningverlening

Scanner Portal

Bestaand voor SAP & TRIM Nog niet bekend Nog niet bekend QSPM is basic maar ondersteunt bij IJsselmeergebied zowel handhaving als vergunningverlening.


Portal

QSPM is basic maar ondersteunt bij IJsselmeergebied zowel handhaving als vergunningverlening.

127


Nog niet bekend

Functionele component Specialistische automatisering

ICT-voorziening Ten behoeve van Lozingsnormen, Bedrijfsafvalrapportages en inhoudelijke berekeningen is maatwerk software noodzakelijk Geo-info

Bestaand / nieuw Bestaand in WVO-info en vele andere applicaties GVG voor geografische weergave van vergunningen

Bruikbaar in SOA Nog niet bekend

Kennistool

Rule engine

Easyrules bij IVW

nog niet in combinatie met SAP, mogelijk na doorontwikkeling

Werkstroombesturing

WFM / BPM

Bestaand voor SAP en WVO-info. Ook wordt MS Project gebruikt.

alleen binnen SAP

Documentmanagement

DMS

Bestaand voor SAP Wellicht toekomstig ook in een WabInfo component

alleen binnen SAP

Financieel systeem

SAP

Bestaand voor SAP, koppeling met OGONE (ext. betalings-systeem), WVO-info Heffingen

Nog niet bekend

Rapportage tool

Management informatie of business intelligence

Nog niet bekend Bestaand voor SAP (Business Warehouse) maar wordt niet gebruikt. WVO-info bevat wel rapportage mogelijkheden via Media en Esperenant. Daarnaast wordt meestal MS Excel gebruikt.

Gegevensmagazijn voor gestructureerde gegevens

Datawarehouse (gegevensmagazijn)

Bestaand voor SAP database, WVO-info database

alleen binnen SAP of nieuw

Gegevensmagazijn voor ongestructureerde gegevens

Enterprise Content Management (postregistratie)

TRIM, netwerkdirectory bij IJG

mogelijk TRIM

Bestaande oplossingen.

Onbekend

CarmaDocsys bij VenW, Word, PDF-generator, Quicklic worden gebruikt om documenten te genereren. geen Enterprise Service Bus aanwezig. SAP is SOA opgezet, maar als integrale service. Overheid heeft OSBadapters gerealiseerd

Nog niet bekend

Elektronische beschikkingen Printen / documenten genereren

XML-transformer, documentserver

Koppelingen/connectiviteit adapters

Kantoorautomatisering

Tekstverwerking, email

Bestaand MS Office, Windows XP Professional

Archivering

Archiefsysteem

TRIM?

Tabel 9 Overzicht bestaande ICT voorzieningen per functionele component

128


Nog niet bekend

Nog niet bekend

8.7 Vergelijking oplossingsrichtingen Elke oplossingsrichting heeft effect op de omgeving en de toetsingscriteria zoals omschreven in hoofdstuk 2. Ten opzichte van de baseline (huidige situatie) wordt het effect van op oplossing gezien als negatief of als positief . Een toelichting op de beoordelingscriteria per oplossingsrichtingen is in de vorige paragraven gegeven. Beoordelingscriterium Optie 1 Optie 2 Optie 3 Optie 4 Alignment Gebruikersvriendelijkheid Kwaliteit Openheid/connectiviteit Flexibiliteit Toekomstvastheid Kosten Doorlooptijd implementatie Compliancy / architectuur Beheer Capaciteit Organisatie Beveiliging Hosting Tabel 10 Vergelijking oplossingsrichtingen

8.8 Conclusies Elke oplossingsrichting bestaat uit een aantal gemeenschappelijke veranderingen, met uitzondering van de eerste optie. Optie 1 is alleen het treffen van maatregelen om aan de wetgeving en doelstellingen voor de dienstverlening van Rijkswaterstaat te voldoen. Het levert geen verbeteringen op. De opties 2 en 3 hebben gemeenschappelijkheden: 1. één voorziening voor vergunningverlening; 2. de gegevenshuishouding, de processen en de organisatie zijn op orde, en

129


3. één voorziening voor handhaving voor het ontsluiten van gegevens; Deze oplossingsrichtingen hebben gedeeltelijk te maken met ICT, maar de grootste veranderingen zitten in de wijze van werken én de wijze waarop het werk georganiseerd is. Eén gemeenschappelijke visie op vergunningverlening en handhaving ontbreekt nog voor Rijkswaterstaat. Decentraal bestaan ICT-voorzieningen die nu nog zijn ingericht per wetgeving. Sap Havik was een eerste aanzet om processen te uniformeren door met één systeem te gaan werken. De organisatie en gegevenshuishouding zijn hier echter niet op afgestemd, waardoor er vanuit het werkveld weinig noodzaak bestaat tot uniform werken. Optie 4 is de meest duurzame en flexibele oplossing. Service oriëntatie is een ontwikkeling die de Overheid en Rijkswaterstaat (gegeven de Enterprise Architectuur) ambieert bijvoorbeeld in de vorm van samenwerkende organisatie onderdelen die gezamenlijk verantwoordelijk zijn voor het leveren van diensten. Ook andere projecten binnen Rijkswaterstaat hebben de wens om met een generieke services een oplossing te realiseren (WabInfo, Infraweb). Door services te ontwikkelen, kan decentraal de keuze worden gemaakt welke service men wil gebruiken voor de eigen processen. Zo zijn er in Overijssel geen vergunningen met betrekking tot lozingen op de Noordzee. Zo zal er altijd differentiatie noodzakelijk en mogelijk zijn. De service georiënteerde architectuur is een stip op de horizon voor Rijkswaterstaat, maar zowel de organisatie als de ICT-voorzieningen zijn er op korte termijn niet klaar voor. Dit vraagt om ICT-beleid en een governance die erop toeziet dat ICT-projecten in lijn zijn met de ICTvisie. Het ICT-beleid zal geconcretiseerd moeten worden. Dit vraagt om een actieve, sturende rol van de enterprise architecten om deze visie daadwerkelijk ook te gaan realiseren. Oplossingsrichting 4 heeft daarom, ondanks de verwachte positieve effecten niet direct de voorkeur. Er dient wel rekening te worden gehouden met een eventuele service oriëntatie binnen Rijkswaterstaat, maar met oplossingsrichting 3 worden daar de mogelijkheden voor geschapen. In oplossingsrichting 3 wordt namelijk al een aantal services ingericht, waarbij in eerste instantie wordt gekozen voor één integraal pakket voor vergunningverlening. Dit is echter ook in later stadium op te knippen in aparte services. Daarnaast heeft oplossingsrichting 3 de voorkeur over oplossingsrichting 2, vanwege de meerdere positieve effecten op zaken als openheid, toekomstvastheid en compliancy. Dat betekent niet dat SAP geen optie meer is, maar dat de uitgangspunten van oplossingrichting 3 van toepassing zijn op een eventuele invulling met SAP.

130


8.9 Open Source opties Als mogelijke opties voor invulling van de ICT-bouwstenen worden enkele suggesties gedaan over beschikbare open source bouwstenen die geleid hebben tot succesvolle implementaties binnen de overheid. Functionele component Mogelijke te onderzoeken optie voor Open Source voorziening LVO Website voor niet WW

Wordt bepaald door VROM ism RWS, Waterschap, Provincies veel open source voorzieningen: http://php.opensourcecms.com/general/ratings.php

Identificatie / authenticatie Elektronische formulieren

Orbeon

Scanstraat Gebruikers interface vergunningverlening

Liferay met Jboss en Alfresco stack


idem


Nog niet bekend

Kennistool

Jboss stack

Werkstroombesturing Documentmanagement

Jboss stack, (BPM), Alfresco stack heeft WFM, zakenmagazijn maatwerk of ORAvision obv Oracle Alfresco

Financieel systeem

OFBizz.apache.org

Rapportage tool

OFBizz en Jasper reports

Gegevensmagazijn voor gestructureerde gegevens Gegevensmagazijn voor ongestructureerde gegevens Elektronische beschikkingen Printen / documenten genereren Koppelingen/connectiviteit

Alfresco

Jasper reports Alfresco Jboss broker

Kantoorautomatisering

Open office

Archivering

Alfresco

131


9 Stappenplan In het voorliggende hoofdstuk worden deze projecten geordend naar organisatie, informatie en ICT. Paragraaf 9.1 gaat in op de resultaten die in de definitiestudiefase zijn gerealiseerd en vertaald in een aantal oplossingsrichtingen. Paragraaf 9.2 gaat in op de projecten per oplossingsrichting uit het voorgaande hoofdstuk waarin de projecten benoemd zijn met de nummertjes [x]. In paragraaf 9.3 is de visie van het project Havik 2 op de oplossing globaal uitgewerkt in de groeiproces. Daarna volgt een transitiediagram en de beschrijving van de transitie van het huidige naar het toekomstige midoffice voor vergunningverlening en handhaving binnen Rijkswaterstaat.

9.1 Integrale benadering van het veranderingsproces Het project Havik 2 heeft de behoefte van de gebruiker in kaart gebracht. Daarnaast is onderzocht welke wettelijke ontwikkelingen er zijn die er toe leiden dat Rijkswaterstaat veranderingen moet doorvoeren. Omdat de komst van de nieuwe Waterwet en mogelijk ook nieuwe Binnenvaartwet leidt tot nieuwe taken en een andere invulling van taken voor Rijkswaterstaat, zal niet alleen de ICT maar ook de organisatie mee moeten veranderen. Over de wijze waarop Rijkswaterstaat daar invulling aan zal geven is nog geen beleid ontwikkeld.

B el

e id

s ke

uz e

s

W etgeving

Visie RWS Op Havik II

rs we ns G e bruike

Bestaande situatie organisatie informatie

organisatie

ICT

informatie

2009

2010

2011

2012

Figuur 29 Transitie van ICT, informatie en organisatie

132


ICT

De visie op het uiteindelijke “eindplaatje” is tot nu toe bepaald door de gebruiker en wetgeving. Het Rijkswaterstaat-management (business én ICT) zal bij het nemen van een beslissing over het vervolgtraject van Havik 2 beleidskeuzes moeten maken. Suggesties voor te maken beleidskeuzes: • inrichting procesgang en organisatie rondom het vergunningverlening: o eenvoudig (uit te besteden of volledig te automatiseren) een voorbeeld: een AMvB-melding wordt op vormvereisten gecontroleerd en vervolgens direct geregistreerd en een signaal naar Handhaving om eventueel een inspectie in te plannen. o gemiddeld (beperkt automatiseerbaar, uit te voeren door mensen met minder specifieke kennis), o complex ((functioneel ICT-ondersteund (termijn bewaking, documentmanagement) uitgevoerd door gekwalificeerde medewerkers) • inrichting rondom Handhavingsproces: o welk type AMvB-meldingen en vergunningen moeten geïnspecteerd worden welke niet? o welke informatie is per domein (water, weg, scheepvaart) nodig en tegen welke kwaliteit (juistheid, actualiteit, beschikbaarheid) Ten behoeve van de Handhaving vinden risico-analyses plaats om de PIN’s vast te stellen. In feite zal men dit voor elk zaaktype moeten uitvoeren. Het aandachtsgebied van Havik 2 gaat over de verschillende diensten heen en heeft dus een corporate karakter. Ook het beleid over toepassing van landelijke basisregistraties en Rijkswaterstaatsbrede kernregistraties in de bedrijfsprocessen en administraties is een corporate vraagstuk. Havik 2 adviseert dan ook voor het vervolgtraject een integrale benadering. Zowel het aspect organisatie (personeel, rollen, verantwoordelijkheden én bedrijfsprocessen), informatie (gegevensarchitectuur, gegevensdefinities, administraties, standaarden) moeten op elkaar worden afgestemd en op de invulling en het gebruik van ICT voorzieningen. Vervolgens zal ook op het gebied van ICT (applicatielandschap, Service oriëntatie, uitbesteding, Open source, Open Standaarden) beleid moeten worden ontwikkeld en zullen project gestart moeten worden. Deze aspecten zouden op het hoogste niveau samen moeten komen in de enterprise architectuur. De Enterprise Architectuur is nog niet voldoende uitgewerkt en geeft nog geen richting over veel aspecten. Het ontwikkelen van een Enterprise architectuur vallen buiten scope van Havik 2, omdat de verantwoordelijkheid daarvoor buiten de beïnvloedingssfeer van Havik 2 ligt. In de begeleidende ProjectStartArchitectuur wordt wel een werkende oplossing geschetst voor Havik 2 en loopt daarmee vooruit op de eventuele enterprise architectuur. Wel wordt geadviseerd om met andere domeinen samen te werken, en af te stemmen met de domeinarchitecten als de oplossingsrichting uit deze definitiestudierapportage is gekozen.

133


Het is onmogelijk om alleen naar het aandachtsgebied Vergunningverlening en Handhaving te kijken, zonder daarbij de veranderingen in de omgeving in ogenschouw te nemen. Derhalve wordt geadviseerd op alle drie de aspecten (organisatie, informatie en ICT) projecten op te starten die veranderingen gaan realiseren, die uiteindelijk gezamenlijk leiden tot de gewenste situatie.

9.2 Projectenplan In het projectenplan voor de implementatie van de Havik 2 oplossing wordt een aantal projecten voorzien, die deeloplossingen moeten realiseren. Een aantal deelprojecten komt in meerdere oplossingsrichtingen terug, een aantal is specifiek voor de oplossingsrichting. De volgende paragrafen geven globaal deelaspecten aan die in één of meerdere projecten gerealiseerd moeten worden. 9.2.1

Nr.

Projectnaam 2 Routering 3 Beheerprocedure

4 Organisatorische maatregelen 5 Digitaliseren dossiers

6 Uitrol basisregistraties

134

Organisatie Organisatie projecten Omschrijving Inrichten midoffice (routeringsvoorziening t.b.v. routering bericht naar juiste backoffice) Waterwet schrijft voor dat er een ontvangstbevestiging en statusinformatie moet worden verstrekt over status van de behandeling van een vergunningaanvraag. Dit moet procedureel en technisch worden ingericht. Aanpassen van processen i.v.m. vooroverleggen, vaststellen bevoegd gezag, definiëren zaaktypen en behandelwijzen. Verantwoordelijkheden moeten worden belegd voor nieuwe taken

Opties 1 2 3 4 x x x x x x x x

x x x

Om gegevens te kunnen ontsluiten via elektronische middelen x x x (internet, intranet, portals) moeten ze ook elektronische beschikbaar zijn. In de dossiers voor handhaving zitten verschillende soorten documenten. Deze moeten gedigitaliseerd en geüpdate worden. Ook om aan te kunnen sluiten op de basisregistraties is actie nodig. Dit leidt ook tot nieuwe processen om alle (in- en uitgaande) content te digitaliseren. Wettelijk worden verplichtingen opgelegd om gebruik te gaan x x x x maken van gegevens uit landelijke basisregistraties. Vervolgens is men ook verplicht terugmeldingen te doen aan de registerhouder als men onjuistheden aantreft. Dit betekent aanpassing van alle processen, formulieren en wellicht ook systemen die gegevens bevatten die ook in de basisregistraties aanwezig zijn. Dit moet opgepakt worden.


Nr.

Projectnaam 7 WFM, BPM

8 Datawarehouse

9 Beheerprocessen BRS

10 Redundante gegevensopslag reduceren 11 Keuze voor Service oriented architecture 12 Benoemen van services

9.2.2

Organisatie projecten Opties Omschrijving 1 2 3 4 Workflowmanagement en business proces management. x x x x Workflowmanagement is het sturen van processen, termijn bewaking. Indien men processen wil optimaliseren, moet men metingen doen, analyses waarom bepaalde zaken optreden om vervolgens bij te kunnen sturen en processen te herontwerpen. Het bijhouden van kengetallen, activitystudy is daarbij een hulpmiddelen. De Wet Dwangsom roept om sturing. Onderzocht moet worden of volstaan kan worden met workflow, of dat een meer integrale benadering noodzakelijke en mogelijk is. Inrichten van een gegevensmagazijn. Het op een centrale plaats x x x inrichten van een database, waarin gegevens uit verschillende bronnen aan elkaar gekoppeld worden. Alle raadplegingen en gegevensleveringen worden vanuit dit gegevensmagazijn gerealiseerd en niet via de individuele bronnen. Het gebruik van basisregistraties leidt tot nieuwe x x x beheerprocessen. Wijzigingen in de gegevens in de basisregistraties worden gemeld aan de afnemers van de gegevens. Deze wijzigingen moeten worden opgepakt en worden behandeld door de beheerder. Zonodig moeten de gegevens in de afnemende applicaties worden aangepast. Naast het inrichten van een gegevensmagazijn is het reduceren x x x van redundante gegevensopslag een oplossing om de kwaliteit van de gegevens te verbeteren. Het maken van afspraken over bronhouderschap (wie is eigenaar van het gegeven). Daar gaat een keuze aan vooraf om te kiezen voor een service x georiënteerde architectuur. Op enterprise niveau of op een lager niveau benoemen, x ontwerpen en realiseren van services. Informatie

Informatie projecten Omschrijving LVO/water inrichten, bestaande websites aanpassen Waterwet schrijft voor dat er een ontvangstbevestiging en statusinformatie moet worden verstrekt over status van de behandeling van een vergunningaanvraag. Dit moet procedureel en technisch worden ingericht. Aanpassen van processen i.v.m. vooroverleggen, vaststellen bevoegd gezag, definiëren zaaktypen en behandelwijzen. 3 Gegevenssynchronisatie Gegevens in de aanvraag (en behandelmodule) in de LVO moeten synchroon lopen met de gegevens in de backoffice van Rijkswaterstaat. Gegevens in lijn met de basisregistraties. 4 Gegevensstandaardisatie Gegevens over de verschillende vergunningverleningsprocessen moeten gestandaardiseerd worden. Elk type watervergunning heeft een gegevensverzameling die op punten van elkaar verschillen op dit moment. Gegevens in lijn met de basisregistraties.

Nr. Projectnaam 1 Frontoffice 2 Beheerprocedure

135


Opties 1 2 3 4 x x x x x x x x

x x x x

x x x x

Informatie projecten Opties Omschrijving 1 2 3 4 Om gegevens te kunnen ontsluiten via elektronische middelen x x x (internet, intranet, portals) moeten ze ook elektronische beschikbaar zijn. In de dossiers voor handhaving zitten verschillende soorten documenten. Deze moeten gedigitaliseerd en geüpdate worden 6 Uitrol basisregistraties Wettelijk worden verplichtingen opgelegd om gebruik te gaan maken x x x x van gegevens uit landelijke basisregistraties. Vervolgens is men ook verplicht terugmeldingen te doen aan de registerhouder als men onjuistheden aantreft. Dit betekent aanpassing van alle p 7 Zakensysteem Nieuwe AMvB-meldingen opnemen als zaaktypen in het x x x configureren zakensysteem of -module van het vergunningpakket. 8 LVO-koppeling LVO 'praat' volgens een bepaalde berichtstandaard met SAP of de x x x andere backofficesystemen van Rijkswaterstaat. Onderzocht moet worden of semantisch en technisch een koppeling mogelijk is. 9 GEO-koppeling Het via geografische voorziening kunnen raadplegen van x x x vergunningen. Daarvoor moeten ook geografische gegevens worden geregistreerd bij een vergunning. 10 Datawarehouse Inrichten van een gegevensmagazijn. Het op een centrale plaats x x x inrichten van een database, waarin gegevens uit verschillende bronnen aan elkaar gekoppeld worden. Alle raadplegingen en gegevensleveringen worden vanuit dit gegevensmagazijn gerealiseerd en n 11 Ontsluiten externe De overheid is op verschillende plaatsen actief om voorzieningen in x x x bronnen te richten zoals Digitaal dossier (programma e-Inspecties), advies.overheid.nl. Deze bronnen zijn via webservices te benaderen. Vastgesteld moet worden welke externe bronnen de handhaver 12 Management rapportage Vanuit de bronnen worden gegevens over de prestaties van de x x x organisaties verzameld en management informatie verstrekt. Hiervoor wordt één middel gebruikt. Voor SAP betekent dit in gebruik name van SAP BW, i.p.v. de spreadsheets die vervaardigd zijn op verzoek van Rijkswaterstaat. 13 Beheerprocessen BRS Het gebruik van basisregistraties leidt tot nieuwe beheerprocessen. x x x Wijzigingen in de gegevens in de basisregistraties worden gemeld aan de afnemers van de gegevens. Deze wijzigingen moeten worden opgepakt en worden behandeld door de beheerder. Zonodig moeten de gegevens in de afnemende applicaties worden aangepast. 14 Redundante Naast het inrichten van een gegevensmagazijn is het reduceren van x x x gegevensopslag redundante gegevensopslag een oplossing om de kwaliteit van de reduceren gegevens te verbeteren. Het maken van afspraken over bronhouderschap (wie is eigenaar van het gegeven). 15 Uitfaseren en WIS Het gebruik van WIS voor registratie van meldingen wordt x x x uitgefaseerd. Daarvoor wordt WIS uitgefaseerd. 16 Benoemen van services Op enterprise niveau of op een lager niveau benoemen, ontwerpen x en realiseren van services.

Nr. Projectnaam 5 Digitaliseren dossiers

9.2.3

ICT (projecten)

ICT projecten Omschrijving

Nr. Projectnaam

136


Opties 1 2 3 4

ICT projecten Omschrijving Inrichten midoffice (routeringsvoorziening tbv routering bericht naar juiste backoffice) 3 Configuratie huidige De huidige systemen moeten zodanig aangepast worden dat er systemen uiteindelijk één beschikking (watervergunning) wordt opgeleverd. Daarnaast moet een gebruikersvriendelijke interface worden gerealiseerd. 4 Beheerprocedure Waterwet schrijft voor dat er een ontvangstbevestiging en statusinformatie moet worden verstrekt over status van de behandeling van een vergunningaanvraag. Dit moet procedureel en technisch worden ingericht. Aanpassen van processen i.v.m. vooroverleggen, vaststellen bevoegd gezag, definiëren zaaktypen en behandelwijzen. 5 Beslissing De LVO realiseert voorzieningen om het aanvraagproces te behandeldossier LVO ondersteunen. Daarbij moet gekozen worden of men gebruik maakt van de behandeldossier-voorziening, of dat men daarvoor zelf een oplossing realiseert. 6 Gegevenssynchronisatie Gegevens in de aanvraag (en behandelmodule) in de LVO moeten synchroon lopen met de gegevens in de backoffice van RWS. Gegevens in lijn met de basisregistraties. 7 Digitaliseren dossiers Om gegevens te kunnen ontsluiten via elektronische middelen (internet, intranet, portals) moeten ze ook elektronische beschikbaar zijn. In de dossiers voor handhaving zitten verschillende soorten documenten. Deze moeten gedigitaliseerd en geüpdate worden. Ook om aan te kunnen sluiten op de basisregistraties is actie nodig. Dit leidt ook tot nieuwe processen om alle (in- en uitgaande) content te digitaliseren. 8 Ontwikkelen Portal en Ten behoeve van de ontsluiting van gegevens, afgestemd op het SSO proces dat de medewerker wil uitvoeren. Ook het ontsluiten van geografische informatie wordt mogelijk. Daarbij moet er een koppeling komen naar bestaande en nieuwe applicaties zodanig dat er geen extra handelingen voor beveiliging nodig zijn om de applicaties te kunnen gebruiken. Dit wordt verstaan onder Single Sign On. Er zijn echter verschillende vormen van SSO mogelijk. Hiervoor zal een passende oplossing gekozen moeten worden. 9 Selecteren kennistool Handhavers hebben de functionele behoefte aan ondersteuning bij het inschatten van risico's bij het uitvoeren van inspecties. Daarbij wil men op eenvoudige wijze de juiste wetgeving kunnen ontsluiten. Voorzieningen daarvoor zijn in de markt verkrijgbaar (RuleBurst, Easyrules etc). Deze kennistool moet ook ontsloten kunnen worden via het portal. 10 Uitrol basisregistraties Wettelijk worden verplichtingen opgelegd om gebruik te gaan maken van gegevens uit landelijke basisregistraties. Vervolgens is men ook verplicht terugmeldingen te doen aan de registerhouder als men onjuistheden aantreft. Dit betekent aanpassing van alle processen, formulieren en wellicht ook systemen die gegevens bevatten die ook in de basisregistraties aanwezig zijn. Dit moet opgepakt worden. 11 ECM of DMS Er moet besloten worden in welke voorziening (bijvoorbeeld TRIM, SAP) digitale content opgenomen gaat worden. Of wordt deze service uitbesteed, of in een nieuwe DMS ondergebracht.

Nr. Projectnaam 2 Routering

137


Opties 1 2 3 4 x x x x x x x

x x x x

x x x x

x x x x

x x x

x x x x

x x x x

x x x x

x x

ICT projecten Opties Omschrijving 1 2 3 4 Nieuwe AMvB-meldingen opnemen als zaaktypen in het x x x zakensysteem of -module van het vergunningpakket. LVO 'praat' volgens een bepaalde berichtstandaard met SAP of de x x x andere backofficesystemen van Rijkswaterstaat. Onderzocht moet worden of semantisch en technisch een koppeling mogelijk is. x x x 14 Maatwerk specialistische SAP kan het vergunningverlening proces ondersteunen. Ook vele software pakketten op de markt kunnen vergunningprocessen ondersteunen. Wat niet mogelijk is, zijn de specifieke analyses en berekeningen die in de behandeling van sommige vergunningverleningsprocessen plaats moeten vinden in één "kopen". Daarvoor is maatwerk nodig, of moeten componenten uit WVO-info worden omgebouwd. x 15 SAP CRM Onderzocht moet worden of SAP CRM voldoende ondersteuning kan bieden voor het vastleggen van klantbezoeken en contacten. 16 WFM, BPM Workflowmanagement en business proces management. x x x x Workflowmanagement is het sturen van processen, termijn bewaking. Indien men processen wil optimaliseren, moet men metingen doen, analyses waarom bepaalde zaken optreden om vervolgens bij te kunnen sturen en processen te herontwerpen. Het bijhouden van kengetallen, activitystudy is daarbij een hulpmiddelen. De Wet Dwangsom roept om sturing. Onderzocht moet worden of volstaan kan worden met workflow, of dat een meer integrale benadering noodzakelijke en mogelijk is. 17 Elektronische Om een relatie te leggen tussen werkopdrachten, planning en de x x x agenda/planning agenda van de handhaver is een koppeling noodzakelijk tussen WFM en de agenda van de handhaver (via zijn portal, mobiele werkplek of MDA te ontsluiten). 18 GEO-koppeling Het via geografische voorziening kunnen raadplegen van x x x vergunningen. Daarvoor moeten ook geografische gegevens worden geregistreerd bij een vergunning. 19 Datawarehouse Inrichten van een gegevensmagazijn. Het op een centrale plaats x x x inrichten van een database, waarin gegevens uit verschillende bronnen aan elkaar gekoppeld worden. Alle raadplegingen en gegevensleveringen worden vanuit dit gegevensmagazijn gerealiseerd en niet via de individuele bronnen. x x x 20 Ontsluiten externe De overheid is op verschillende plaatsen actief om voorzieningen in bronnen te richten zoals Digitaal dossier (programma e-Inspecties), advies.overheid.nl. Deze bronnen zijn via webservices te benaderen. Vastgesteld moet worden welke externe bronnen de handhaver via zijn portal wil kunnen benaderen. 21 Management rapportage Vanuit de bronnen worden gegevens over de prestaties van de x x x organisaties verzameld en management informatie verstrekt. Hiervoor wordt één middel gebruikt. Voor SAP betekent dit in gebruik name van SAP BW, i.p.v. de spreadsheets die vervaardigd zijn op verzoek van Rijkswaterstaat. 22 Redundante Naast het inrichten van een gegevensmagazijn is het reduceren van x x x gegevensopslag redundante gegevensopslag een oplossing om de kwaliteit van de reduceren gegevens te verbeteren. Het maken van afspraken over bronhouderschap (wie is eigenaar van het gegeven).

Nr. Projectnaam 12 Zakensysteem configureren 13 LVO-koppeling

138


ICT projecten Omschrijving Het gebruik van WIS voor registratie van meldingen wordt uitgefaseerd. Daarvoor wordt WIS uitgefaseerd. 24 Aanbestedingsprocedure Ter vervanging van alle vergunningverleningssystemen wordt een vergunningpakket aanbestedingsproces gestart.

Nr. Projectnaam 23 Uitfaseren en WIS

Opties 1 2 3 4 x x x x

25 Benoemen van services Op enterprise niveau of op een lager niveau benoemen, ontwerpen en realiseren van services. 30 Herbruikbaarheid In verschillende projecten binnen Rijkswaterstaat zijn reeds services bestaande ontwikkeld. Onderzocht moet worden of deze hergebruikt kunnen voorzieningen worden voor Havik 2. onderzoeken

x x

9.3 Visie op de oplossing De stuurgroep Goed Geïnformeerd binnen het Ministerie van VenW heeft naar aanleiding van de implementatie van de recordmanagement applicatie T2 e-records (TRIM) onderkend dat een Visie op Informatiemanagement noodzakelijk is om richting te geven aan de verdere ontwikkeling en professionalisering van het informatiemanagement binnen VenW. Op verzoek van de stuurgroep heeft IDEEA daartoe een eerste aanzet gegeven. Deze aanzet is vervolgens door het beleidsprogramma Goed Geïnformeerd en het uitvoeringsprogramma IDEEA uitgewerkt tot het document: “ Visie op Informatiemanagement VenW” als subtitel “ Toekomstbeeld en groeimodel”. Hieraan heeft Staf DG van Rijkswaterstaat meegewerkt. In analogie met de visie van het Ministerie van Verkeer en Waterstaat wordt een groeimodel voor Havik 2 voorzien. Het groeimodel bestaat uit een aantal ontwikkelingsstadia (zie Figuur 30): 6. papier op orde 7. van papier naar digitaal 8. het proces op orde 9. het proces digitaal 10. informatie op orde

139


Het groeimodel voor Vergunningverlening en Handhaving

“Streefbeeld Havik 2”

uw ie rn e V

er et rb e V

Informatie op orde

n de

Proces digitaal

en

Proces op orde

Volwassenheid

re rb Ve

en

Papier digitaal Papier op orde

Tijd/ inspanning

Figuur 30 Groeimodel voor Vergunningverlening en Handhaving Rijkswaterstaat21 De aspecten waarmee de groei gerealiseerd kunnen worden zijn Processen, Organisatie, ICT en Informatie. Het uiteindelijke resultaat kan uitkomen op oplossingsrichting 3 (of 2 als SAP kan voldoen aan het programma van eisen) of oplossingsrichting 4 als de permanente oplossing als Service Georiënteerde Architectuur wordt gerealiseerd door eventuele leveranciers. Per stadium wordt kort toegelicht welke werkzaamheden moeten plaatsvinden. 9.3.1 Papier op orde Per regionale dienst verschilt de toegankelijkheid en de kwaliteit van de opslag van fysieke documenten. Onderzocht moet worden welke archiefstukken wellicht overbodig zijn geworden. Achterstanden in het verwerken van documenten worden weggewerkt. Dit betekent ook een controle van het areaal op de juiste vergunningen of geregistreerde meldingen. 9.3.2 Van papier op naar digitaal Elk ontvangen en verzonden fysiek document wordt omgezet in een digitale versie. De digitale versie wordt als brondocument betiteld wat niet wil zeggen dat er geen papierenversies meer mogen bestaan. De elektronische versie wordt alleen gekozen als bron. De ICT-voorziening waar de documenten (vergunningen, meldingen, brieven, gedoogbesluiten etc) in worden geregistreerd heeft een goede 21

Het originele model gaat uit van Processen, Systemen, Organisatie en Mensen. Dit hebben

we om consistent te blijven met de andere delen van deze definitiestudierapportage aangepast en veranderd in Organisatie, Processen, ICT, Informatie.

140


taxonomie en goede zoekfunctionaliteiten. De metagegevens die over een document worden vastgelegd zijn gestandaardiseerd. De ICT-voorziening wordt een tijdelijke voorzieningen die het mogelijk maakt om aan de Waterwet te kunnen voldoen. Voor nieuwe aanleidingen (aanvragen voor de Waterwet, specifieke AMvBmeldingen) worden procedures ontwikkeld om eventuele papierstromen om te zetten in digitale bestanden. Van digitale stromen wordt afgesproken hoe deze worden geconverteerd naar de tijdelijke ICT voorziening. Voor het digitaliseren van stukken kan het bestaande T2 e-Records (of TRIM) mogelijk breder worden toegepast. Ten behoeve van de vastlegging van de inhoudelijke gegevens vergunningen en meldingen, wordt een tijdelijke voorziening ingericht. De inhoud van bestaande papieren vergunningen, besluiten en andere relevante dossierstukken worden gedigitaliseerd en in de tijdelijke voorziening geregistreerd. Voor het ontwerp van de benodigde tijdelijke voorziening vindt een nadere gegevensanalyse behoefte plaats, met name om aan te sluiten op de LVO. Om voor de handhaving ontsluiting van de digitale content mogelijk te maken, wordt de informatiebehoefte vastgesteld van de gegevens die verzameld moeten worden en toegankelijk gemaakt moeten worden voor de handhaver. 9.3.3 Proces op orde De verschillende processen (primaire processen, beleidsprocessen, ondersteunende processen) worden op orde gebracht. Op basis van een visie op de dienstverlening rondom Vergunningverlening en Handhaving worden processen herontworpen, ook rekeninghoudend met efficiëntie en effectiviteit en de mate van automatisering. Hierbij wordt aangesloten op de programma’s rondom de vernieuwing van het toezicht bij de overheid. Ook worden de verantwoordelijkheden voor processen belegd in de organisatie. De aanbeveling is om dit alles in een “Visie op Vergunningverlening en Handhaving” vast te leggen, zodanig dat er op gestuurd kan worden. De processen worden geïmplementeerd in de organisatie. Er vindt ook actieve sturing plaats op de naleving van de gewijzigde processen. Omdat er mogelijk tijdelijk met een ICT-voorziening gewerkt moet worden, om te kunnen voldoen aan de Waterwet, worden voor de Waterwet tijdelijke procedures ontwikkeld. 9.3.4 Proces digitaal Parallel aan de tijdelijke voorziening die naast SAP en WVO-info wordt ingericht in de eerdere fase, wordt een programma van eisen opgesteld, om de aanbesteding voor permanente ICT-voorzieningen te kunnen starten. Dat programma van eisen voldoet volledig aan de gewijzigde processen en de behoeften van de gebruikers. Veel pakketten zijn voorzien van functionaliteiten om procesontwerpen ‘in te lezen’ in de werkstroombesturing.

141


Op het moment dat de permanente voorziening is ingericht (inclusief alle benodigde functionaliteiten zoals gedefinieerd in hoofdstuk 7) worden de processen “aangesloten” en worden WVO-info en SAP uitgefaseerd. 9.3.5 Informatie op orde In deze fase is Rijkswaterstaat “in control”. De systemen zijn align met de processen, tijd en plaats onafhankelijk werken is mogelijk door de digitale beschikbaarheid van informatie. Gedurende de implementatie (tijdens het groeiproces) wordt aandacht besteed aan: • de governance: besluitvorming en verantwoordelijkheden zijn belegd voor zowel processen, procedures, gegevens en ICT voorzieningen; • de besluitvorming over ICT-voorzieningen worden getoetst aan de “Visie op Vergunningverlening en Handhaving” en de Enterprise Architectuur van Rijkswaterstaat; • een actieve regievoering op naleving van procedures en processen; • het inrichten van het functioneel en technische beheer van de ICT-voorzieningen, zodanig dat Rijkswaterstaat “in control” is.

9.4 Transitiediagram Afhankelijk van de gekozen eindoplossing, zal een transitiepad geschetst moeten worden. De projecten uit paragraaf 9.2 zullen uiteindelijk mijlpalen op moeten leveren. Deze projecten zullen in de loop van de tijd opgezet moeten worden. Het transitiediagram in Figuur 31 zal dan ook in een later stadium nader worden ingevuld. De getoonde transitie wordt uiteengezet in de Havik 2 projectfaseringsrapportage.

142


Figuur 31 Transitiediagram projectfasering

9.5 Transitie van procedureel naar geautomatiseerd midoffice t.b.v. de Waterwet De Waterwet houdt in dat de klant met één aanvraag een vergunning vraagt voor werken, die onder de huidige wetgeving nog onder meerdere wetgeving vallen maar onder de Waterwet tot één besluit leidt. Als de Waterwet in 2009 in werking treedt zal die routering van de aanvraag nog niet volledig elektronisch kunnen worden ondersteund. Derhalve zal er een zogenaamd organisatorisch of procedureel midoffice moeten worden ingericht. Om inzicht te geven in de fasen die kunnen worden onderscheiden bij de inrichting van het midoffice, is het goed om stil te staan bij de verschillende ontwikkelstadia van het midoffice.

143


Figuur 32 Huidige inrichting In de huidige situatie is er per backoffice (met een specifieke taak) een aparte invulling gegeven aan de verschillende kanalen (Figuur 32). In het eerste stadium wordt er één gemeenschappelijk loket voor de klanten van Rijkswaterstaat per regio gerealiseerd (Figuur 33). Daarbij kenmerkt het stadium zich door een sterke verkokering binnen de backoffice (de kantoorprocessen in het kader van WVO, WBR, WBB etc). De communicatie tussen de frontoffice en backoffice loopt via provisorische en organisatorische maatregelen. De aanvraag wordt via de LVO ontvangen in de vorm van een email of op papier aan het loket en vervolgens beoordeeld en doorgerouteerd in een organisatorisch midoffice. Aan de achterkant, in de backoffice is nog steeds sprake van taakspecifieke dienstverlening. Dit organisatorisch midoffice vormt de schakeling tussen het front- en backoffice. Het organisatieonderdeel dat voor dit midoffice verantwoordelijk is, zorgt op procedurele wijze voor de koppeling. Er is in de frontoffice functionaliteit voor de ondersteuning van meerdere kanalen, het scannen van fysieke documenten, of het invoeren van de documenten via een vergunningverlenersportal in een tijdelijke Vergunningvoorziening.

144


Figuur 33 Inrichting met frontoffice en organisatorisch midoffice Vervolgens ontstaat een technisch midoffice en een frontoffice met meerdere kanalen (Figuur 34). In dit stadium worden de verschillende kanalen van het E-loket ook gebruikt door de frontoffice medewerkers van Rijkswaterstaat. Tussen de kanalen aan de voorkant en de taakspecifieke backoffices is een volwaardig elektronisch midoffice gepositioneerd. Dit midoffice zorgt voor de automatische routering van zaken tussen front- en backoffice.

Figuur 34 Inrichting met technisch midoffice De volgende onderdelen zijn te onderkennen: • Broker: zorgt voor de geautomatiseerde routering van gegevens tussen de front- en backoffices op basis van de inhoud van de gegevens Hierbij behoort een orkestratiefunctie (BPM) waarin

145


•

•

•

kan worden vastgelegd op welke wijze gegevensstromen dienen te worden gerouteerd. Gegevensmagazijn: hierin worden de voor het frontoffice benodigde gegevens vastgelegd. Dit is nodig om 24x 7 beschikbaarheid van de elektronische dienstverlening aan de voorkant te kunnen garanderen. Zakenmagazijn: hierin wordt de orkestratie tussen de front- en backoffices bijgehouden en worden de statussen van de aanvragen (of intakes) vanuit het frontoffice hierin vastgelegd. Basisregistraties :de landelijke registraties worden gekoppeld aan de taakspecifieke systemen, waar gegevens worden gebruikt voor het dienstverlenende proces, zoals persoonsgegevens.

In de volwassen Service Georiënteerde Architectuur vormt het midoffice steeds meer het hart van de informatievoorziening (Figuur 35).

Figuur 35 Inrichting met SOA midoffice Enkelvoudige producten (bijv. meldingen, Vervoervergunning) schuiven op van het backoffice naar het midoffice. Basis- en procesgegevens komen steeds meer centraal beschikbaar waardoor betere sturing op zowel operationeel (orkestratie), tactisch en strategisch niveau mogelijk wordt. Documentmanagement biedt functionaliteit voor het invoeren, archiveren en ontsluiten van documenten binnen een organisatie. Het systeem bewaakt de toegang tot documenten en verzorgt versiebeheer. Sommige DMS’en bevatten tevens functionaliteit met betrekking tot de documenthandeling (workflow) en de werkstromen rondom documenten. Daarnaast verwacht men (Gartner en Forrester) dat DMS’en in de toekomst zelfs functionaliteit van een contentmanagement systeem zullen bevatten. De ontwikkelingen op dit terrein gaan heel snel. In feite start de documentmanagement in het

146


frontoffice, maar wordt in het midoffice en backoffice gebruikt voor de ondersteuning van de processen. Workflowmanagement heeft betrekking op de interactie tussen mens en machine. Het systeem deelt taken toe aan werknemers op basis van hun aangewezen rol, het routeert de bij die taken behorende informatie door de organisatie en genereert management en desgewenst status informatie met betrekking tot het onderliggende proces. Business proces management (BPM) richt zich op het routeren van elektronische berichten en orkestreren van werkstromen tussen applicaties onderling. De geschetste transitie is mogelijk door de inzet van tijdelijke ICTvoorzieningen en het tijdelijk procedureel uitvoeren van taken die in vervolgfasen geautomatiseerd kunnen worden.Deze transitie focust met name op de dienstverlening en sluit aan bij de gefaseerde inrichting van definitieve oplossingen aan de miden backoffice kant. Deze transitie vindt binnen de overheid veel plaats als gevolg van de invoering van de Omgevingsvergunning per 1-1-2010.

147


10 Beheer 10.1 Inleiding Een van belangrijke aspecten bij het inrichten van de ICT voorziening Havik 2 is het beheer en onderhoud hiervan. Bij het beheer en onderhoud kan worden gekeken naar de volgende aspecten: • kosten; • organisatie; • processen; • aanpasbaarheid; • beveiliging; • capaciteit; • architectuur; • hosting (huisvesting). Voor al deze aspecten zijn de oplossingsrichtingen in een workshop behandelt. De uitwerking hiervan wordt in dit hoofdstuk behandeld. Ook twee specifieke onderwerpen, het mobiel werken en de kennistool worden in dit hoofdstuk besproken.

10.2 Uitwerking per oplossingsrichting De vier oplossingsrichtingen zoals die zijn gepresenteerd in hoofdstuk 8, hebben behalve specifieke aspecten ten aanzien van beheer, ook algemene aspecten, die voor alle oplossingsrichtingen van belang zijn. Puntsgewijs zijn dat de volgende zaken: • De voorgestelde trajecten voor organisatie, proces, ICT en gegevenshuishouding moeten tegelijkertijd met beheer worden opgepakt, zodat op tijd afstemming kan plaatsvinden en invulling kan worden gegeven aan het beheer van de processen, ICT voorzieningen en de gegevenshuishouding. • Een vuistregel voor de beheerkosten per jaar is 10% - 20% van de ontwikkelkosten van een applicatie. Dit is gebaseerd op basis van maatwerk, • Bij het gebruik van TRIM als DMS in alle oplossingsrichtingen moet er rekening worden gehouden met de beheer afspraken die daar nu voor zijn gemaakt binnen het Ministerie van VenW en Rijkswaterstaat. • Rijkswaterstaat heeft nog weinig geconsolideerde systemen en nog bijna geen generieke bedrijfsvoeringsprocessen. Er is dan ook nog nauwelijks tot geen ervaring opgedaan met het beheer hiervan. • Bij de uitrol van Havik 2 dient de gevestigde orde (de bestaande beheersorganisatie) betrokken te worden. • Een belangrijk uitgangspunt voor het inrichten van het beheer van Havik 2 als geheel moet zijn dat Rijkswaterstaat “in control” is. Oplossingsrichting 1 betreft het behouden van de huidige applicaties waarbij licht aanpassingen worden gedaan om te kunnen voldoen aan

148


de wetgeving. Voor beheer heeft dat aanzienlijke gevolgen. Deze zijn beschreven in Tabel 11. Beheeraspect Algemeen

Kosten

Organisatie

Proces

149

Gevolgen • Voor de routering van de Waterwet is routering twee kanten op nodig. Met name de routering terug (statusmeldingen) vanuit alle verschillende systemen is zeer complex om te realiseren. • De beheer & testkosten zullen relatief hoog zijn omdat het gaat om o oude, niet afgestemde systemen o en systemen die complex in elkaar grijpen. • Er zijn geen generieke koppelvlakken • Er zijn veel meervoudige aanpassingen nodig voor één wijziging • Het is heel complex om overzicht te houden over de applicaties en alle wijzigingen. Daarmee is er een groot risico op fouten. • Het functioneel beheer is decentraal georganiseerd, zoals het nu ook is. • De interactie tussen gebruikers, functioneel beheer , technisch beheer en de DID loopt via veel lijnen met daardoor een grotere kans op miscommunicatie • Het wijzigen van de systemen is een complex traject om te organiseren, vanwege de complexiteit. • De verantwoordelijkheid voor het beheer van de verschillende applicaties beleggen is moeilijk, vanwege de consolidatie van de verschillende systemen. • De routering en het processchema van beheer zijn zeer complex. • Het beheerproces wordt vaker geraakt, waardoor meer inspanning nodig is om alle wijzigingen door te voeren. • Het is lastig om de gebruiker naar het juiste loket verwijzen, vanwege de hoeveelheid diverse applicaties. • Het vastleggen van beheergegevens (bijvoorbeeld zaaknummers van meldingen) is lastig.


Beheeraspect Aanpasbaarheid

Gevolgen • Aanpassingen zijn zeer complex om te realiseren. • Een aanpassing is lastig, vanwege de onderlinge afhankelijkheid tussen routering en applicaties waardoor je meervoudige aanpassingen krijgt. Dit is weer foutgevoeliger. • Wetswijzigingen zijn zeer moeizaam te realiseren in de applicaties. • In de toekomst zal de complexiteit verder stijgen, vanwege de meervoudige aanpassingen. • De Wet Dwangsom bijna niet te ondersteunen door de diversiteit aan applicaties. Beveiliging • Beveiliging van de applicaties is zeer complex omdat identity management per systeem is geregeld. • De gebruiker moet veelvuldig inloggen. Dit is alleen tegen hoge kosten en inspanning op te lossen • Er is geen “any place, any time” beschikbaarheid te garanderen. Capaciteit • De inspanning van beheer zal in de tijd toenemen door stijgende complexiteit en foutgevoeligheid • Het beheer kost meer dan in de huidige situatie (het divergeert i.p.v. dat het converteert). • Digitalisering van de gegevens vergt in dit scenario zeer veel inspanning, ook van beheer. • Deze is zeer complex. Architectuur • Het overzicht is snel zoek • Er verandert niet veel aan hosting, omdat er Hosting nauwelijks systemen verdwijnen. • Elk systeem heeft nu zijn eigen hosting. • Virtualisering van de hosting is lastig te realiseren. Tabel 11 Beheersaspecten van oplossingsrichting 1 Bij oplossingsrichting 2 wordt voortgebouwd op het bestaande SAP Havik, met een aantal aanpassingen en uitbreidingen. De gevolgen voor het beheer in deze oplossingsrichting zijn beschreven in Tabel 12. Beheeraspect Algemeen

150

Gevolgen • Het beheer van WVO-info vergt specifieke functionaliteit, ten aanzien van de lozingen en de koppeling met LIMS. Dat is in SAP waarschijnlijk niet mogelijk. • Bestaande systemen vervallen en daarmee ook het beheer hiervan, maar er blijven specifieke applicaties nodig buiten SAP die ook beheerd moeten worden.


Beheeraspect Kosten

Organisatie

Proces

Aanpasbaarheid

Beveiliging

151

Gevolgen • De onderhoudskosten zullen lager zijn dan in de bestaande situatie, maar de kosten voor aanpassingen zijn echter veel hoger. • De koppelingen van SAP met specifieke applicaties zijn duur. Ook de koppeling met een grafische schil (portal) is erg duur. • Het uurtarief voor SAP ontwikkelaars is zeer hoog. • Het efficiënt beheren van SAP koppelingen is moeilijk in te schatten qua kosten. • Er zijn twee beheerpartijen voor SAP. Dat maakt het complex qua organisatie en afspraken. • De afhankelijkheid van de IVW wegens de gedeelde database maakt het lastiger om wijzigingen door te voeren. Er zit echter geen functionele wens achter het delen van de database. • Het proces van aanpassingen en beheer is minder ingewikkeld dan in oplossingsrichting 1. Maar de routering van beheer over twee partijen maakt het proces wel complex en dus foutgevoelig. • Er zijn grenzen aan de mogelijkheden om SAP aan te passen. Het is geen maatwerk applicatie voor wat betreft mogelijkheden. • Het is wel mogelijk om SAP specifiek te tunen maar dat brengt hoge kosten met zich mee. • Door het delen van de database met de IVW zijn aanpassingen moeilijk te realiseren en hebben deze een lange doorlooptijd. • De standaarddocumenten (brieven) zitten nu in SAP Havik en worden beheerd door CBI. Wijzigingen (bijvoorbeeld adreswijziging) zijn moeilijk door te voeren. Elk detail vergt het doorlopen van het wijzigingsproces. Dit verhoogt ook de beheerlast. • SAP kent 4 major en minor releases per jaar. Voor het huidige SAP Havik zijn12 tot 14 wijzigingen per jaar nodig. Dit moet met elkaar worden afgestemd. • Ten opzichte van oplossingsrichting 1 hoeven wijzigingen op minder plekken te worden doorgevoerd. • De beveiliging is niet wezenlijk anders dan de huidige situatie. • Er is nu nog weinig voor geregeld, wat wel wijzigingen met zich meebrengt. • Single sign-on is eenvoudiger te realiseren dan in oplossingsrichting 1.


Beheeraspect Capaciteit

Gevolgen • De flexibiliteit van SAP is beperkt. Dit verhoogd de beheerinspanning en verlaagt het draagvlak bij de gebruikers. • Het functioneel beheer kan in dit scenario meer worden gebundeld waardoor met de bestaande capaciteit mogelijk meer kan worden gedaan. Maar dat is mede afhankelijk van waar het beheer van de handhaving portal wordt belegd. Als dat niet bij SAP beheer is, zijn er toch weer twee partijen nodig. Architectuur • Op het SAP deel is qua architectuur voor Rijkswaterstaat geen controle. • Het is een consolidatie ten opzicht van de Hosting huidige situatie, waardoor er minder virtuele servers nodig zijn. • Een goede afstemming tussen systemen en voldoende bandbreedte is bij SAP wel lastig. Tabel 12 Beheersaspecten van oplossingsrichting 2 In oplossingrichting 3 is een soortgelijke invulling gegeven als in oplossingsrichting 2, maar met een vergunningpakket, in plaats van SAP. Hierdoor zijn veel van de gevolgen vergelijkbaar ten opzichte van oplossingsrichting 2. Daarom wordt hier alleen genoemd wat anders is dan in oplossingsrichting 2. De gevolgen zijn beschreven in Tabel 13. Beheeraspect Algemeen Kosten

Organisatie

Proces

152

Gevolgen • Maak een duidelijke keuze voor Open Source Software en Open Standaarden. • De onderhoudskosten zullen lager zijn dan in de bestaande situatie, want er zijn goedkopere pakketten te vinden dan SAP. • Het maken koppelingen is eenvoudiger. Veel vergunningpakketten zijn voorbereid op de specifiek benodigde koppelingen. Dit bespaard kosten. • Een koppeling met geografische ontsluiting wordt mogelijk wel duurder. • Er wordt geprofiteerd van wijzigingen bij andere afnemende partijen van het pakket. • Voor een vergunningpakket moet een nieuwe beheerorganisatie worden ingericht. • Rijkswaterstaat houdt wel zelf de controle over de beheerorganisatie. • Het beheerproces is minder ingewikkeld om dan in oplossingsrichting 1 en 2 • Er zijn kortere lijnen mogelijk en minder afstemming met andere partijen (buiten Rijkswaterstaat). • De routering van verzoeken is eenvoudiger. • Dit alles is wel afhankelijkheid van de leverancier van het vergunningpakket.


Beheeraspect Aanpasbaarheid

Gevolgen • De aanpasbaarheid hangt af van het pakket en/of de leverancier. • Het biedt wel kansen om het eenvoudiger in te regelen dan in de huidige situatie. • Wijzigingen zijn makkelijker te realiseren, omdat het maar om één applicatie gaat die zelf wordt beheerd. • De gegevenshuishouding is eenvoudiger van opzet en op maat te maken. • Afhankelijk van pakket en/of de leverancier is het mogelijk om zelf maatwerk bij te bouwen. • Ten opzichte van scenario 1 hoeven wijzigingen op minder plekken te worden doorgevoerd. • Doordat alles in eigen hand is, is beveiliging Beveiliging eenvoudiger te regelen. • Single sign-on is eenvoudiger te realiseren dan in oplossingsrichting 1. • Mede afhankelijk van de leverancier en/of het Capaciteit pakket is het mogelijk om de huidige capaciteit effectiever te benutten of met minder beheercapaciteit te werken. • Een gebruiksvriendelijker pakket verlaagt automatisch de druk op beheer, omdat het aansluit bij de gebruikerswensen. Architectuur • Alles is in eigen hand en dus eenvoudiger in te richten en te besturen. • De hosting behoefte geconsolideerd t.o.v. de Hosting huidige situatie en dus zijn er minder virtuele servers nodig. • De afstemming en/of verbinding tussen componenten is eenvoudiger Tabel 13 Beheersaspecten van oplossingsrichting 3 Oplossingrichting 4 gaat uit van een service georiënteerde architectuur, waarbij afhankelijk van de processtap verschillende services worden aangehaakt. De gebruiker merkt hier in feite niets van. Voor beheer heeft het aanzienlijke gevolgen. Deze zijn beschreven in Tabel 14. Beheeraspect

153

Gevolgen


Beheeraspect Algemeen

Kosten

Organisatie

Proces

Aanpasbaarheid

154

Gevolgen • De meerwaarde is het delen van functionaliteit met andere systemen, toepassingen, organisatieonderdelen en/of werkgebieden. • Het project zal veel generieke componenten moeten realiseren voor Rijkswaterstaat, die er nu niet zijn. Het project kan worden gebruikt als vliegwiel om dit te realiseren vanuit het belang van vervanging van legacy systemen, consolidatie en de vernieuwing van de ICTinfrastructuur en het ICT-landschap. • Er zijn suites beschikbaar die alle benodigde functionaliteit kunnen bieden (Oracle, Microsoft, Centric). • De belangrijkste bouwstenen moeten eerst worden gerealiseerd. Dat zijn workflow en document management. • De keuze voor Open Source Software en Open Standaarden is hier een belangrijke. • Er is een uitspraak van EAR over beleid & strategie nodig bij deze oplossingsrichting. • De realisatie van deze oplossingsrichting is een lastig en ingewikkeld traject en vergt minimaal 3 tot 5 jaar. • De “kosten gaan voor de baten uit” en daarmee zijn de initiële kosten zijn zeer hoog. Volgende projecten behalen de baten (goedkoper, sneller, eenvoudiger). Het eerste project kent geen positieve business case als alle kosten aan het project worden toegerekend. Er is een keuze nodig om hierin Rijkswaterstaat breed te investeren. • Beheerkosten zijn naar schatting na 3 jaar terug te verdienen over alle toepassingen heen en niet voor alleen Havik 2. • Qua onderhoud is deze oplossingsrichting de meest efficiënte want het beheer is veel meer gebundeld over systemen heen. • Rijkswaterstaat kan ook alles zelf organiseren, waarbij de modules op het zwaartepunt in beheer kunnen worden genomen. • Het beheer is beter te stroomlijnen. • Rapportage en verantwoordelijkheid van het beheerproces is veel eenvoudiger • Specifieke toepassingen blijven bestaan, maar als een apart blokje binnen SOA. • Voor de gebruiker is het beheerproces erg transparant. • Deze richting is maximaal flexibel. • Wijzigingen zijn in een keer door te voeren, waardoor er een hoge en snelle aanpasbaarheid is de op gebruikerswensen. • Het beheren en wijzigen van de gegevenshuishouding is veel eenvoudiger.


Beheeraspect Beveiliging

Gevolgen • Beveiliging is een service dus eenvoudiger te regelen, mede doordat alles in eigen beheer is. • Single sign-on is meest eenvoudig te realiseren in deze oplossingsrichting. • Het is een andere benadering die een Capaciteit professionele beheerorganisatie (matrix organisatie) vergt die is ingericht naar bouwstenen en processen. • In absolute zin betekent het voor heel Rijkswaterstaat minder beheer en onderhoud van de systemen. • De flexibiliteit verlaagt automatisch de druk op het beheer. • De architectuur is in deze oplossingsrichting Architectuur maximaal flexibel en gestructureerd. • Eenmalig positioneren en hergebruiken van componenten is mogelijk, bijvoorbeeld single sign-on. • Er is geen afhankelijkheid van één leverancier of systeem. • Het vraagt wel om strikt informatie beleid. • Hosting is veel simpeler dan in de huidige Hosting situatie. • Er kan worden voortgebouwd op consolidatie naar één beheerder. • De afstemming en verbinding tussen componenten is zeer eenvoudig te realiseren en beheren. • Er zijn minder virtuele servers nodig. Tabel 14 Beheersaspecten van oplossingsrichting 4

10.3 Mobiel werken Mobiele toestellen met daarop vertrouwelijke informatie zijn niet alleen een risico voor virussen, wormen, trojans en spam, maar ook voor diefstal of verlies. Voor een optimaal blijvend gebruik van de mobiele toepassingen zijn drie aspecten van beheer te onderscheiden: beveiliging, bescherming en management. Beveiliging Mobiele toestellen hebben zich ontwikkeld tot kleine, krachtige computers met een grote opslagcapaciteit en netwerkverkeer met een hoge bandbreedte. Mobiele werknemers die deze toestellen gebruiken, vormen een risico doordat ze kostbare of vertrouwelijke informatie kwijt kunnen raken. Mobiele applicaties als push-mail, CRM en automatisering voor de buitendienst zorgen voor hogere productiviteit en meer gemak, maar vergroten de kwetsbaarheid van data. Rijkswaterstaat moet ervoor zorgen dat niet alleen de mobiele toestellen beveiligd zijn, maar ook de data die erin zit. Dat betekent onder andere dat gekeken dient te worden naar versleuteling van gegevens die op het apparaat worden opgeslagen, maar ook een goede beveiliging met behulp van virusscanners en een firewall.

155


Beheer & onderhoud De werknemersproductiviteit neemt af wanneer de mobiele medewerkers tijd moeten besteden aan onderhouds-, configuratie- en ondersteuningstaken voor hun apparaten. Handheld Management vereenvoudigt het beheer van apparaten zodat werknemers zich kunnen richten op hun werk, in plaats van tijd te besteden aan het herstellen of optimaliseren van hun mobiele apparaat. Onderdeel hiervan moet het updaten van firewall en virusscanner zijn.

10.4 Kennistool De kennistool beoogd het ontsluiten van weten regelgeving voor zowel vergunningverleners als handhavers. Daarmee weten medewerkers van Rijkswaterstaat in elk geval op eenvoudige wijze door voorschriften die van belang zijn op te vragen, zodat deze kunnen worden verwerkt in een vergunning of hierop kan worden gecontroleerd tijdens een toezichtsbezoek. Belangrijke voorwaarde voor het effectief kunnen inzetten van de kennistool, is dat deze alle relevante wetgeving, regelgeving en jurisprudentie kan ontsluiten. Al deze wetgeving moet worden vertaald naar de business rule logic van de gekozen oplossing. Dat is in principe een eenmalig actie. Maar om het systeem up-to-date te houden met alle wetswijzigingen en nieuwe regels en jurisprudentie, zal regelmatig onderhoud aan het systeem moeten worden gepleegd. Dat vergt een extra inhoudelijke inspanning van het beheer. In andere opzichten, qua hosting, proces, capaciteit, etc. is er geen afwijking ten opzichte van een willekeurige oplossingsrichting. De kennistool kan hier met name worden gezien als een service die is in te zetten op de gewenste momenten. Daarmee is het beheer en onderhoud wel het eenvoudigst vorm te geven in oplossingsrichtingen 3 en 4.

156


11 Beveiliging Dit hoofdstuk gaat in op de beveiligingsaspecten van Havik 2. In paragraaf 11.1 wordt ingegaan op het door Rijkswaterstaat gehanteerde classificatiemodel. Daarin staan de stappen beschreven die worden gezet om de te nemen beveiligingsmaatregelen te bepalen. Paragraaf 11.2 beschrijft de resultaten van de uitgevoerde risicoclassificatie. Tot slot wordt in paragraaf 11.3 een inschatting gegeven van de te verwachte impact en wordt op een aantal inhoudelijke aspecten nader ingegaan.

11.1 Classificatiemodel Informatie, bedrijfsprocessen, ondersteunende informatiesystemen en bedrijfsmiddelen staan bloot aan diverse bedreigingen. Dit impliceert, dat binnen Rijkswaterstaat de eigenaren of verantwoordelijken van informatie, bedrijfsprocessen en informatiesystemen risico’s lopen. Deze risico’s zullen de eigenaren of verantwoordelijken zoveel mogelijk proberen te beperken door het treffen van beveiligingsmaatregelen. Het is belangrijk te zoeken naar een evenwicht tussen risico’s en maatregelen. Een risicoanalyse ondersteunt het zoeken naar een evenwichtig en samenhangend pakket beveiligingsmaatregelen dat de informatie, bedrijfsprocessen, informatiesystemen en/of bedrijfsmiddelen van Rijkswaterstaat optimaal beveiligt. Het uitvoeren van een risicoanalyse is kostbaar en niet in alle situaties noodzakelijk. Om te kunnen bepalen of een risicoanalyse echt noodzakelijk is, wordt gebruik gemaakt van het Classificatiemodel. Aan de hand van dit model wordt de beveiligingsklasse bepaald. De beveiligingsklasse geeft aan of de baseline aan beveiligingseisen en maatregelen toereikend is voor de bescherming of dat er aanvullend een risicoanalyse uitgevoerd moet worden in vereenvoudigde of uitgebreide vorm. In het laatste geval wordt gesproken over een Afhankelijkheden en Kwetsbaarheden analyse (A&K-analyse). Het classificatiemodel voldoet aan de eisen zoals deze zijn verwoord in het VIR 2007 en het beveiligingsbeleid van VenW. De uit de beveiligingsklassen voortvloeiende beveiligingsmaatregelen gelden gedurende de gehele levensfase (ontwikkeling, exploitatie, afbouw) voor alle ICT-diensten die de DICT-organisatie levert aan Rijkswaterstaat. Onderstaand overzicht geeft de te nemen stappen weer.

157


Figuur 36 Schema classificatiemodel

11.2 Risicoclassificatie In het kader van de definitiestudie voor Havik 2 is de eerste stap in dit proces uitgevoerd om de beveiligingsklasse te bepalen. Daartoe zijn de vragenlijsten met betrekking tot vertrouwelijkheid, integriteit en beschikbaarheid ingevuld. Voor het invullen van de vragenlijsten hebben de Adviesgroepen Handhaving en Emissiebeheer een vertegenwoordiger aangewezen, die hiervoor namens hen is gemandateerd. Vanuit de Data-ICT-dienst is het invullen van de vragenlijsten begeleid door een beveiligingsarchitect.

158


Uitgangspunten bij het invullen van de vragenlijsten waren: Havik 2 kent geen strafrechtelijke informatie, alleen een nummer en datum van een eventueel procesverbaal. Havik 2 bevat concurrentie gevoelige informatie over bedrijven. Havik 2 bevat privacy gevoelige informatie over personen. Het resultaat van de risicoclassificatie is weergegeven in onderstaand overzicht. De ingevulde vragenlijsten zijn weergegeven in bijlage 14.5 Verlies van Vertrouwelijkheid A B C D E Bedrijfsimpact schaal A Levensbedreigende situaties, maatschappelijke ontwrichting en schade

Verlies van Integriteit

A

B

C

D

E

B Hoge impact en schade C Aanzienlijke impact en schade D Lichte impact en schade

Verlies van Beschikbaarheid gedurende de service tijden:

E Verwaarloosbare impact en schade

¾

Eén uur

A

B

C

D

E

¾

Eén dag

A

B

C

D

E

¾

2–3 dagen

A

B

C

D

E

¾

Één week

A

B

C

D

E

¾

Één maand

A

B

C

D

E

A

B

C

D

E

Eindscore beschikbaarheid

Voor vertrouwelijkheid en integriteit wordt de hoogste individuele score per kolom gehanteerd. Voor beschikbaarheid wordt de hoogste individuele score uit de rijen gehanteerd.

Tabel 15 Overzicht resultaat impactanalyse Op basis van bovenstaande resultaten kan Havik 2 geclassificeerd worden als: kritiek (beveiligingsklasse hoog) op het gebied van integriteit. Ten aanzien van vertrouwelijkheid en beschikbaarheid is de classificatie lager. Gezien de kritieke classificatie voor integriteit geldt voor Havik 2 als vervolgstap het uitvoeren van een volledige A&Kanalyse. Deze A&K-analyse dient ten aanzien van zowel integriteit, vertrouwelijkheid en beschikbaarheid te worden uitgevoerd. Het uitvoeren van de A&K-analyse dient in een volgende projectfase plaats te vinden op het moment dat de requirements en de te implementeren IT-oplossing bekend zijn.

11.3 Impact beveiligingsmaatregelen In overleg met de beveiligingsexpert van DID is vastgesteld, dat het wenselijk is om de Afhankelijkheidsanalyse uit te voeren, op het moment dat de keuze is gemaakt voor een oplossingsrichting. Na selectie van een mogelijke permanente oplossing, zal in samenwerking met Rijkswaterstaat de leverancier van de oplossing een Kwetsbaarheidsanalyse moeten opleveren.

159


12 Impact/ COPAFIJTH binnen de RWS-organisatie In dit hoofdstuk wordt beschreven wat de impact is voor Rijkswaterstaat, als de functionaliteiten volledig gerealiseerd zijn zoals ze beschreven zijn genoemd in paragraaf 7.4 en 7.5. Voor de beschrijving van de impact is gekozen voor een aantal bedrijfsaspecten die aangeduid worden met het acroniem COPAFIJTH (Communicatie, Organisatie, Personeel, Administratieve organisatie, Financiën, Informatie, Juridisch en Techniek.

12.1 Communicatie SAP Havik 1 heeft bij de gebruikersorganisatie geleidt tot diversiteit. Bepaalde organisatorische onderdelen zijn tevreden, bepaalde andere organisatorische onderdelen zijn buitengewoon ontevreden. Kortom, er moet veel aandacht besteed worden aan draagvlak en communicatie over de te verwachten oplossing. De betrokkenen bij Havik 2 zijn verwachtingsvol. Als het draagvlak wederom weg valt, is elke implementatie van een nieuw systeem gedoemd te mislukken. Verwachtingenmanagement is een groot aandachtspunt. Communicatie richting de burger of bedrijf verandert doordat voor een vergunningaanvraag, een melding, bezwaar of beroep, etc. een digitaal loket is ingericht, waarmee gecommuniceerd kan worden met Rijkswaterstaat. Rijkswaterstaat kan ook communiceren via dit loket over de status of aanvullende verzoeken, maar behoudt ook de mogelijkheid voor communicatie in fysieke vorm, bijvoorbeeld bij het verstrekken van een vergunning. Dit houdt in dat mensen op een andere manier zullen moeten gaan werken. Hierover zal tijdig met de gebruikersorganisatie gecommuniceerd moeten worden.

12.2 Organisatie Om uniform werken landelijk bij Rijkswaterstaat in te voeren, in combinatie met een centrale ICT voorziening dient er in de organisatie een aantal wijzigingen doorgevoerd te worden. Dat betreft bijvoorbeeld afspraken over de processen, de verantwoordelijkheden en uitvoering hiervan, maar ook de naleving en controle op juiste uitvoering van de processen. De Rijkswaterstaat-frontoffice is het gezicht naar de burger en bedrijfsleven. Om uiting te geven aan publieksgericht en dienstverlenend werken, zal ook naar buiten gericht de uniformiteit moeten blijken. De consequenties van de wijze waarop vergunningverlening wordt ingericht hebben gevolgen voor de wijze waarop teams worden

160


ingedeeld en benodigde expertise wordt aangetrokken. Daarnaast kunnen bepaalde strategische keuzes leiden tot mogelijk nieuwe taken, zoals bijvoorbeeld: • eenvoudige vergunningen kunnen worden uitbesteed. Dit leidt tot servicemanagement etc. • gemiddelde vergunningen kunnen door minder hoogopgeleid personeel op lagere functieniveaus wellicht worden uitgevoerd. • complexe vergunningen leiden wellicht tot specialistische teams geconcentreerd op een beperkt aantal plaatsen in het land.

12.3 Personeel Om te kunnen werken in de nieuwe situatie, moet het juiste personeel beschikbaar zijn. Juiste personeel doelt op juist expertise, opleidingsniveau en beschikken over de juiste vaardigheden zoals sociale vaardigheden om met klantcontacten om te gaan, dienstbaar etc. Daarbij moet gekeken worden naar de inrichting van de organisatie waarbij de verantwoordelijkheden en taken in het werkveld van vergunningverlening en handhaving worden bepaald. Er kan bijvoorbeeld worden gekozen om de kennis van het handhaven in het veld te beleggen in één rol, en de administratieve kant van het handhaven in een andere rol. Datzelfde geld in feite voor het handhaven van één of meerdere typen wetgeving, bijvoorbeeld voor lozingen. De organisatie en het personeel moet dus op elkaar zijn afgestemd, qua taken, verantwoordelijkheden, competenties en aantallen. Daarnaast is het noodzakelijk om het personeel op te leiden. Dat geldt voor het werken met nieuwe systemen en applicaties, als voor veranderingen in werkwijzen. Ook een juiste opleiding voor nieuwe wetgeving en veranderingen in bestaande wetgeving is noodzakelijk om op een juiste manier te kunnen werken. Een optie is het train-detrainer concept. Een teamleider wordt opgeleid en traint vervolgens de medewerkers. Dan blijft de kennis waar hij hoort. Geadviseerd wordt dan ook om de trainers zo vroeg mogelijk in het ontwikkeltraject te betrekken, bijvoorbeeld bij het vaststellen van functionele specificaties, acceptatietesten van gerealiseerde ICT-voorzieningen.

12.4 Administratief Procesontwerpen en systeemdocumentatie moeten worden gescheiden. Procesontwerpen beschrijven wat en hoe een proces werkt, wie verantwoordelijk is, welke rollen er voorkomen. Systeemdocumentatie beschrijft hoe een systeem werkt. In gebruikershandleidingen worden beide op een gedetailleerder niveau aan elkaar gekoppeld. Door procesontwerpen en systeemdocumenten van elkaar te scheiden, wordt de onderhoudbaarheid van de documenten verbeterd. Immers, er wijzigt geen proces als er een nieuw systeem komt. Wel veranderen de werkinstructies. De processen, zoals die zijn gedefinieerd voor de wetgeving waar Rijkswaterstaat voor staat opgesteld, zoals vergunningverlening, maar

161


ook advisering over Gemeentelijke Rioleringsplannen, kunnen worden uitgevoerd met ICT voorzieningen. Het is daarbij wel noodzakelijk om de processen, en daarmee de werkinstructies, goed en eenduidig uit te werken en toe te zien op een correcte uitvoering hiervan.

12.5 Financieel Door de functionaliteiten in de ICT voorziening, waaronder termijnbewaking, is een maatregel voorhanden die voorkomt dat termijnoverschrijding voor behandeling van vergunningaanvragen en bezwaarprocedures optreedt, met als mogelijk gevolg een dwangsom. In de kosten/baten-analyse Havik 2 worden de financiele consequenties van de gerealiseerde oplossing nader uitgewerkt.

12.6 Informatie De gegevenshuishouding is volledig op orde, na implementatie. Functionarissen zullen te maken hebben met nieuwe of andere begrippen als gevolg van standaardisatie. In een aantal gevallen zal er verschil zijn in de informatie die men registreert ten opzichte van de huidige situatie. Vaak worden gegevens geregistreerd, waarvan niet meer duidelijk is, waarom men deze registreert. Kortom, een kwestie van gewenning en niet meer van noodzaak. Gegevens die niet worden gebruikt, zullen slecht onderhouden worden dus hebben veelal een slechte kwaliteit.

12.7 Juridisch Met de nieuwe ICT voorziening is Rijkswaterstaat in staat om nieuwe en bestaande wetgeving uit te voeren, qua vergunningverlening en handhaving. Hierbij kan ook worden voldaan aan Europese richtlijnen voor het publiceren van milieu informatie, INSPIRE. Daarnaast zijn er voorzieningen om snel te kunnen anticiperen op nieuwe wetgeving in de toekomst.

12.8 Techniek Voor de gebruikersorganisatie mag het niet uitmaken met welke techniek de functionaliteit wordt gerealiseerd, zolang het voldoet aan de eisen.Met de nieuwe ICT voorzieningen kan men op eenvoudige wijze toegang krijgen tot benodigde applicaties voor het werk. Hierbij wordt gebruik gemaakt van de standaard kantoorautomatisering omgeving, die ook beschikbaar is op bijvoorbeeld patrouilleschepen. Om te kunnen werken is één keer inloggen voldoende. Ontsluiten van informatie voor handhavers is ook mogelijk met behulp van mobiele werkplekken, waarbij rekening gehouden moet worden met de verbinding met de kantoorautomatisering. Voor specifieke taken zullen maatwerkoplossingen gerealiseerd moeten worden. Daarvoor zal een programmeertaal, platform of andere oplossing bedacht moeten worden waarvan de kennis beschikbaar is. In

162


de overheidsmarkt vindt veel innovatie plaats op het gebied van Open Source. Door de diversiteit in techniek te beperken wordt het mogelijk om de kennis te behouden en beheerkosten te beheersen.

12.9 Huisvesting Indien alle vergunningendossiers zijn gedigitaliseerd en de organisatie en de processen zijn ingericht om deze als bron te gebruiken, betekent dit voor de huisvesting dat de ruimte voor archivering van dossiers over vergunningen kan worden geminimaliseerd. Er zal altijd een bepaalde behoefte aan originele papieren vergunningen zijn, vanuit bijvoorbeeld historisch oogpunt. Daarnaast kan er voor handhavers, doordat ook mobiel werken mogelijk is, minder ruimte op kantoor beschikbaar worden gesteld. Er zullen een beperkt aantal flexplekken nodig zijn. Ten aanzien van de huisvesting voor vergunningverleners zijn geen grote gevolgen te verwachten.

163


13 Openstaande punten In het definitiestudie rapport zijn een aantal punten zijdelings benoemd maar (nog) niet verder uitgewerkt. Deze punten worden hieronder genoemd. Per punt wordt kort toegelicht wat de relatie is met Havik 2 en het definitiestudie rapport.

13.1 Heffingen Het Bureau Verontreinigingsheffing Rijkswateren (BVR) is verantwoordelijk voor het opleggen van de aanslagen voor de verontreinigingsheffing in het kader van de WVO. Het Uitvoeringsbesluit verontreiniging rijkswateren (Uvr) beschrijft in detail de rechten en verplichtingen van zowel BVR als van de heffingplichtigen. De afdeling Emissiebeheer van de RWS Waterdienst adviseert het BVR over de juistheid van de aangifte door de heffingplichtigen, de frequentie en wijze van bemonsteren en analyseren van de heffingparameters, en adviseert de heffingplichtigen met betrekking tot de meet- en bemonsteringsvoorzieningen. Heffingen heeft nu een relatie met de WVO en daarmee ook met WVO-Info. In onderstaand schema is dat ook aangegeven. WVO-info cluster Geel is beheer derden

LABinfos

WVO-heffing

WVO-info Infraweb

Management infomatie

Management informatie

CoMa

Bezwaren WVO-BB Aanslagen

Handhaving WVO-BAWR

Belasting dienst

ATLOZ Aanslagregelingen Vergunningen RiAnth Aangiften WVO-LNV Module inlezen LNV gegevens

Vaste gegevens

=

WVO-heffing

Basisgegevens

Basis gegevens WVO-info

Esperant querytool

Gebruik en beheer

Gebruik en beheer

Media MI tool

Er is (nog) niet uitgezocht welke informatie het proces heffingen precies nodig heeft en hoe dat proces precies verloopt. Daarmee is ook nog niet duidelijk of de functionaliteit uit WVO-Info betreffende heffingen kan worden ondersteund door Havik 2. Zowel de processen en de gegevens voor heffingen dienen nog te worden uitgezocht.

164


13.2 Binnenvaartwet De Binnenvaartwet is de implementatie van de EU richtlijn 2006/87/EG en vervangt gelijktijdig de huidige Binnenschepenwet (technische voorschriften aan binnenvaartschepen), Wet Vervoer Binnenvaart (toelating tot de markt) en Wet Vaartijden en Bemanningssterkte. In de nieuwe Binnenvaartwet staat welke schepen op de binnenwateren voorzien moeten zijn van een geldig Certificaat van Onderzoek (CvO) en dat ze niet gebruikt mogen worden op een andere manier dan in het certificaat vermeld staat. Voor Havik 2 is nog niet uitgezocht welke taken uit de Binnenvaartwet worden uitgevoerd door Rijkswaterstaat en welke processen hierbij worden uitgevoerd. Ook is nog niet bekend welke gegevens er benodigd zijn.

13.3 Relatie met IVW De administratieve afhandeling van vergunningverlenings- en handhavingstaken in het waterbeheer is een taak van het bevoegd gezag. Zolang het bij de rijkswateren om ‘werken van derden’ gaat, is dit Rijkswaterstaat. Bij ‘werken eigen dienst’ ligt dat anders. Rijkswaterstaat kan nu eenmaal niet zijn eigen bevoegd gezag zijn. Bij ‘werken eigen dienst’ is daarom niet Rijkswaterstaat eindverantwoordelijk, maar de Inspectie Verkeer en Waterstaat. Rijkswaterstaat voert echter namens de Inspectie wel veel taken uit. Om duidelijk te maken waar nu precies de verantwoordelijkheden liggen, wie welke taken heeft en hoe werkwijzen en procedures in elkaar steken, heeft de Inspectie samen met Rijkswaterstaat het ‘Uitvoeringskader Werken eigen dienst Rijkswaterstaat’ opgesteld. Zie ook: www.ivw.nl/eigenwerken Voor Havik 2 is nog niet bekend of en hoe dit gaat veranderen met de Waterwet. Daarnaast is er nog geen duidelijke analyse geweest van de processen en uitwisseling van gegevens van eigen werken.

13.4 Processen en diepgang Naast de primaire processen heeft Rijkswaterstaat een adviesfunctie bijvoorbeeld ten aanzien van gemeentelijke rioleringsplannen en veiligheidsrapportages. Hierbij worden door Rijkswaterstaat wel beschikkingen verstrekt. Ook een MER procedure heeft een beginpunt in vergunningverlening. Hetzelfde geld voor het opnemen van de processen rondom de E-MJV en het geven van voorlichting. Deze processen vallen deels onder de primaire processen, deels niet. Deze processen dienen verder te worden uitgezocht, inclusief een beschrijving van de benodigde gegevens en gebruikte applicaties.

165


13.5 Nautische en droge verkeerswetgeving In de definitiestudie is momenteel veel aandacht besteed aan de gevolgen van de Waterwet voor de werkzaamheden van vergunningverlening en handhaving. De scope is echter het gehele werkveld van vergunningverlening en handhaving bij Rijkswaterstaat. Onderdelen daarvan liggen ook bij de nautische en droge verkeerswetgeving. Tijdens een gesprek met Hans Goedvolk is bijvoorbeeld de vergunningverlening en handhaving rondom ligplaatsbeheer bij Rijkswaterstaat aan de orde geweest. Hier vinden op kleine schaal, meestal met beperkte noodzaak tot een uitgebreide inhoudelijke beoordeling, vergunningverleningsprocessen plaats. In principe is de opzet die is gekozen voor Havik 2 ook toereikend voor deze processen. Immers voor vergunningverlening is de AWB het enige proces. Echter, de gegevens die bij en over zo’n vergunning (of gedoogbesluit) worden vastgelegd zijn niet noodzakelijkerwijs hetzelfde als bijvoorbeeld voor de WVO of de WBR. Het objectmodel dat is gepresenteerd in Hoofdstuk 6 dekt daarmee niet met zekerheid het hele veld.

166


14 Bijlagen 14.1 De twintig NORA principes In verkorte vorm zijn dit de twintig principes van NORA. Een hoge kwaliteit van dienstverlening nastreeft door: 1. dienstverlening via internet aan te bieden; 2. daarbij de bestaande kanalen zoals post en telefonie te handhaven; 3. er voor te zorgen dat uw klanten uw diensten makkelijk kunnen vinden; 4. in samenwerking met anderen, voor de klant logische diensten te leveren; 5. gebruik te maken van unieke identificatienummers zoals BSN en BIN; 6. contoles te ontwerpen als onderdeel van het primaire proces; 7. een transparante en toegankelijke klachten- en bezwarenprocedure. Administratieve lastenverlichting nastreeft door: 8. gegevens eenmalig uit te vragen waar mogelijk opnieuw te gebruiken; 9. bij het ontwerp van uw diensten administratieve lasten mee te wegen; 10. onderling consistente, controleerbare en handhaafbare regels op te stellen; Transparantie nastreeft door: 11. te tonen hoe uw dienstverleningsprocessen moeten worden doorlopen; 12. inzicht te geven in de status van lopende dienstverleningsprocessen; 13. periodiek publieke verantwoording af te leggen over de kwaliteit van uw dienstverlening; 14. toegang te geven tot algemene overheidsinformatie zoals weten regelgeving; 15. te laten zien welke besluiten uw organisatie neemt en welke gegevens hierbij zijn gebruikt. Proactieve dienstverlening nastreeft door: 16. uw klanten pro actief te attenderen op relevante diensten. Streeft naar een integrale en betrouwbaren overheid door; 17. zich te organiseren als onderdeel van een integrale overheid; 18. gegevens te gebruiken die accuraat, actueel en volgens wettelijke normen beveiligd zijn. Streeft naar verbetering van de doelmatigheid van de overheid door: 19. gebruik te maken van generieke componenten en gemeenschappelijke voorzieningen; 20. de interne bedrijfsvoering te standaardiseren en optimaliseren.

167


x

Bedrijf

Aanleiding Bedrijfsrapport

x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x

x

Beschikking Status Beschikking

Pers Basisregistraties

Subject Handelingslocatie Waarneming

Laboratorium

Lozingsobject Meetpunt Beschikking Dossier Status

Hulpverleners

Wet

IVW

Beschikking Dossier Status Wet

Europese Unie Bureau Verontreinigingsheffing Frontoffice Vervoer over water

Rapport Bedrijfsrapport Aanleiding Dossier Dossier Beschikking Status Aanleiding

Gemeente

Beschikking Advies Status Aanleiding

Provincie

Beschikking Advies Status Waterschap

Aanleiding Beschikking Advies Status Wet Bedrijfsrapport

Ministerie van VROM

Bedrijfsrapport

168


x x

x

x x

x

x x x x x x x x x x x x x

Aantal

x Beschikking Status

Frequentie

Fysiek

Aanleiding

Digitaal

Ingaand

Burger

Uitgaand

Relatie

14.2 Toelichting omgevingsdiagram

Bedrijfsrapport Ministerie van V&W

Wet Bedrijfsrapport

Ministerie van Justitie

Wet

Bedrijfsrapport Dossier Beschikking Aanleiding Status Verslag Bevinding Behandelwijze Advies PIN Legger Capaciteit Organisatorische eenheid Branche

Rijkswaterstaat

Advies Dossier Beschikking Aanleiding Status Verslag Bevinding Plan Rapport Document Capaciteit Medewerker

Vergunningverlener

Aanleiding Dossier Zaak Plan

169

x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x


x

x

x x

x x x x x x x x x x x x x x x x x x x x

x

Aantal

Frequentie

Fysiek

Digitaal

Uitgaand

Ingaand

Relatie

Wet Bedrijfsrapport

Ministerie van LNV

Aanleiding Beschikking Dossier Zaak Plan

x x x x x x x x x x x

14.3 Definities procesniveau Procesniveau

Omschrijving

Ketenproces

Een ketenproces is een geordende reeks bedrijfsprocessen die door verschillende organisaties wordt uitgevoerd met als doel om via één organisatie een (combinatie van) dienst(en) te leveren aan een burger of een bedrijf.

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).

170


x x x x x x x x

x

Aantal

Frequentie

Fysiek

Digitaal

Uitgaand

Ingaand

Relatie

Document Capaciteit Medewerker Bevinding Waarneming Verslag

Handhaver

14.4 Systeemfunctionaliteiten De volgende functionaliteiten kunnen aanwezig zijn in applicaties die gebruikt worden bij de Handhaving en Vergunningverlening. Functionaliteit

Omschrijving

Tekstverwerking

Functionaliteit om teksten te kunnen genereren

Document management

Functionaliteit voor dossiervorming, opslag en archivering van elektronische documenten, producten

Scannen

Functionaliteit voor het digitaliseren van fysieke documenten

Printen of aanleveren bij printstraat

Functionaliteit voor het afdrukken van documenten op papier, dan wel het genereren van printbestanden ten behoeve van het afdrukken

Workflowmanagement

Functionaliteit voor werkstroombesturing, termijnbewaking binnen één werkproces

Business proces management

Functionaliteit voor werkstroombesturing over verschillende werkprocessen heen

Management info

Functionaliteit voor het genereren van management informatie


Functionaliteit voor het presenteren van (administratieve gegevens op) Geografische informatie

Audit trail

Functionaliteit om alle beheershandelingen en andere activiteiten m.b.t. documenten vast te leggen.

Factureren en incasso

Functionaliteit om facturen en incasso opdracht te genereren en termijnbewaking daarop toe te passen

Contentmanagement

Webfunctionaliteit die het mogelijk maakt om zonder al te veel technische kennis, documenten en gegeven op internet te kunnen publiceren

Publiceren op internet

Functionaliteit om de producten en documenten die m.b.v. het informatiesysteem tot stand komen, te publiceren via Internet, zonder tussenkomst van andere systemen dan het contentmanagement systeem

Clientrelatiemgt

Functionaliteit om klantgegevens en klantcontactgegevens te bewaren

Casemanagement

Functionaliteit om procesgegevens over de afhandeling van een zaak toe kunnen genereren

Identity management

Functionaliteit om onder een bepaalde identiteit toegang te krijgen tot een applicatie, of valt het systeem binnen een beveiligingsschil (single sign on)

Catalogus

Functionaliteit om producten en diensten te beschrijven en ontsluiten

Administratie (gegevensbeheer)

Functionaliteit om informatie op te slaan en te beheren.

Vraagpatronen

Functionaliteit voor het beheren/maken en publiceren van beslisbomen en (groepen van) vragen over producten en diensten

Statistische functionaliteit

Functionaliteit voor het verrichten van statistische analyses

Offline en online werken

De mogelijkheid om offline te werken en vervolgens te synchroniseren.

171


14.5 Ingevulde vragenlijsten risicoclassificatie Impact vertrouwelijkheid Bedrijfsimpact

Gevolgen voor RWS Door onbedoelde of ongeautoriseerde toegang tot informatie, bedrijfsprocessen, informatiesystemen en bedrijfsmiddelen.

Toelichting

A Levensbedreigende situaties, maatschappelijke ontwrichting en schade B Hoge impact en schade C Aanzienlijke impact en schade D Lichte impact en schade E Verwaarloosbare impact en schade

1

Maatschappelijke consequenties Als de vertrouwelijkheid wordt geschonden, wat zijn de maatschappelijke gevolgen in termen van

A

B

C

D

E

A

B

C

D

E

A

B

C

D

E

A

B

C

D

E

A

B

C

D

E

A

B

C

D

E

A

B

C

D

E

A

B

C

D

E

veiligheid/gezondheid/welzijn of milieu?

2

Organisatie en bedrijfsprocessen Als de vertrouwelijkheid wordt geschonden, welke gevolgen heeft dit voor de continuïteit van de RWS-organisatie en bedrijfsprocessen?

3

Directe schade / financiële gevolgen Als de vertrouwelijkheid wordt geschonden, wat is de directe

nvt

schade in financiële termen?

4

Indirecte schade / financiële gevolgen Als de vertrouwelijkheid wordt geschonden, welke schade loopt RWS op door het maken van extra kosten? (Denk aan kosten onderzoek lek, claims, herstelkosten, etc)

5

Maatschappelijke taken Als de vertrouwelijkheid wordt geschonden, welke schade loopt RWS op door het niet kunnen nakomen van maatschappelijke, reguliere of contractuele verplichtingen?

6

Imago Als de vertrouwelijkheid wordt geschonden, welke schade loopt RWS door verlies aan vertrouwen van de maatschappij?

7

Motivatie medewerkers Als informatie niet meer vertrouwelijk is, welke schade loopt RWS op door negatieve uitstraling hiervan op de motivatie van medewerkers?

Totaal score Vertrouwelijkheid Samenvattend, wat is rekening houdend met de hierboven genoteerde scores en eventuele andere omstandigheden de meest ernstige schade die kan ontstaan door onbedoelde of ongeautoriseerde inzage of toegang tot informatie, bedrijfsprocessen, informatiesystemen of bedrijfsmiddelen? (De hoogste individuele score wordt overgenomen)

172


Impact Integriteit Gevolgen voor RWS

Bedrijfsimpact A

Door fouten in RWS gegevens of door moedwillige manipulatie (door fraude) van informatie binnen de bedrijfsprocessen, informatiesystemen en/of bedrijfsmiddelen.

Levensbedreigende situaties, maatschappelijke ontwrichting en schade B Hoge impact en schade C Aanzienlijke impact en schade D Lichte impact en schade E Verwaarloosbare impact en schade

1

Maatschappelijke consequenties Als de integriteit wordt geschonden, wat zijn de maatschappelijke gevolgen in termen van

A B C D E

veiligheid/gezondheid/welzijn/milieu?

2

Organisatie en bedrijfsprocessen Als de integriteit wordt geschonden, welke gevolgen heeft dit voor het in control zijn en

A B C D E

daarmee de continuïteit van de RWS organisatie en bedrijfsprocessen?

3

Directe schade / financiële gevolgen Als de integriteit wordt geschonden, wat is de directe schade in financiële termen?

4

A B C D E

Indirecte schade / financiële gevolgen Als de integriteit wordt geschonden, welke schade loopt RWS op door het maken van extra

A B C D E

kosten? (Denk aan kosten onderzoek lek, herstel kosten, etc)

5

Maatschappelijke taken Als de integriteit wordt geschonden, welke schade loopt RWS op door het niet kunnen

A B C D E

nakomen van maatschappelijke, reguliere of contractuele verplichtingen?

6

Imago Als de integriteit wordt geschonden, welke schade loopt RWS door verlies aan vertrouwen

A B C D E

van de maatschappij?

7

Motivatie medewerkers Als informatie niet meer integer is, welke schade loopt RWS op door negatieve uitstraling

A B C D E

hiervan op de motivatie van medewerkers?

8

Uitvoering maatschappelijke taken Als informatie is aangetast, welke schade loopt RWS/de maatschappij doordat beslissingen

A B C D E

worden genomen op basis van niet actuele of onjuiste informatie?

Totaal score Integriteit Samenvattend, wat is rekening houdend met de hierboven genoteerde scores en eventuele andere omstandigheden de meest ernstige schade die kan ontstaan door onbedoelde of ongeautoriseerde mutatie of verlies van informatie, bedrijfsprocessen, informatiesystemen

A B C D E

of bedrijfsmiddelen? (De hoogste individuele score wordt overgenomen)

173


Toelichting

Impact Beschikbaarheid Gevolgen voor RWS

Bedrijfsimpact

Toelichting

A Levensbedreigende situaties,

Van niet beschikbare informatie, bedrijfsprocessen, informatiesystemen en/of bedrijfsmiddelen.

maatschappelijke ontwrichting en schade B Hoge impact en schade C Aanzienlijke impact en schade D Lichte impact en schade E Verwaarloosbare impact en schade

Duur van de uitval Eén Eén

2-3

Eén

Eén

uur dag dag. week maand

1 Maatschappelijke consequenties Als de informatie, bedrijfsproces, informatiesysteem of bedrijfsmiddel een

E

E

E

D

D

E

E

D

C

C

E

E

D

D

C

E

E

E

D

B

E

E

E

D

C

E

E

E

D

C

E

D

C

C

B

E

E

D

C

C

E

D

C

C

B

bepaalde tijd niet beschikbaar is, wat zijn de maatschappelijke gevolgen in termen van veiligheid/gezondheid/welzijn/milieu?

2 Organisatie en bedrijfsprocessen Als de informatie, bedrijfsproces, informatiesysteem of bedrijfsmiddel een bepaalde tijd niet beschikbaar is, welke gevolgen heeft dit voor het in control zijn en daarmee de continuïteit van de RWS organisatie en bedrijfsprocessen?

3 Directe schade / financiële gevolgen Als de informatie, bedrijfsproces, informatiesysteem of bedrijfsmiddel een bepaalde tijd niet beschikbaar is, wat is de directe schade in financiële termen?

4 Indirecte schade / financiële gevolgen Als de informatie, bedrijfsproces, informatiesysteem of bedrijfsmiddel een bepaalde tijd niet beschikbaar is, welke schade loopt RWS op door het maken van extra kosten? (Denk aan kosten onderzoek lek, herstel kosten, etc)

5 Maatschappelijke taken Als de informatie, bedrijfsproces, informatiesysteem of bedrijfsmiddel een bepaalde tijd niet beschikbaar is, welke schade loopt RWS op door het niet kunnen nakomen van maatschappelijke, reguliere of contractuele verplichtingen?

6 Imago Als de informatie, bedrijfsproces, informatiesysteem of bedrijfsmiddel een bepaalde tijd niet beschikbaar is, welke schade loopt RWS door verlies aan vertrouwen van de maatschappij?

7 Motivatie medewerkers Als de informatie, bedrijfsproces, informatiesysteem of bedrijfsmiddel een bepaalde tijd niet beschikbaar is, welke schade loopt RWS op door negatieve uitstraling hiervan op de motivatie van medewerkers?

8 Relatie met andere bedrijfsprocessen en informatiesystemen Als de informatie, bedrijfsproces, informatiesysteem of bedrijfsmiddel een bepaalde tijd niet beschikbaar is, welke schade loopt RWS op door aantasting of minder functioneren van hiervan afhankelijke bedrijfsprocessen of informatiesystemen?

Totaal score Beschikbaarheid Samenvattend, wat is de meest ernstige schade die kan voortvloeien door uitval van informatie, bedrijfsproces, informatiesysteem of bedrijfsmiddel in de meest ernstige situatie?

174


De hoogste individuele score per kolom wordt overgenomen

175


14.6 Objectmodel beschrijvingen Deze beschrijvingen zijn een eerste uitwerking van de objecttypen bij een volgende versie van het objectmodel zullen zaken worden toegevoegd en in lijn worden gebracht met Open Standaarden en beschikbare definities uit de Basisregistraties. Aanleiding Definitie

Toelichting

Voorbeeld

Eigenaar Bijzonderheden

Advies Definitie Toelichting

Voorbeeld

De aanleiding voor Rijkswaterstaat als bevoegd gezag om een zaak te openen, te beschouwen als logische hoeveelheid werk. De aanleiding is een generiek object wat een koppeling is tussen de processen van vergunningverlening, handhaving en plannen, sturen en rapporteren. Vergunningaanvraag Melding Bezwaar Vooroverleg Plan Bestuurlijke sanctie Aanleiding type definieert alle mogelijke aanleidingen. In de verschillende administraties en processen worden voor meldingen meerdere betekenissen gebruikt. In SAP is een vergunningaanvraag het behandelen van een melding. Daarnaast is er een melding uit het veld, wat betrekking heeft op handhavingszaken, wat een incident kan worden genoemd. Ook is er een melding voor een Algemene Maatregel van Bestuur. Een aanleiding betreft al deze drie zaken.

Raadgeving betreffende een zaak, verleend door een subject. Subject kan zowel intern als extern zijn. Advies kan bedoeld zijn voor een zaak, of gerelateerd aan een zaak van een andere partij. Berekening van effect van het werk op de sterkte van een dijklichaam. Berekening van effect van lozing op waterkwaliteit. Advies van Rijkswaterstaat over een Gemeentelijk Rioleringsplan


176


Bedrijfsrapport Definitie Toelichting Voorbeeld

Rapportage van subjecten over hun handelingen. Vooral van toepassing op lozingsobjecten en milieu aspecten. BAWR (Bedrijfs Afval Water Rapport) E-MJV (Elektronisch Milieu Jaar Verslag)

Eigenaar Bijzonderheden Behandelwijze Definitie Toelichting

Voorbeeld

De processen die van toepassing zijn op de onderhanden zaak. Elke zaak heeft op basis van wetgeving, kwaliteitsmanagement een bepaalde manier waarop deze wordt behandeld, afhankelijk van het zaaktype. Procesvoering beroep Behandeling aanvraag waterwetvergunning met leges volgens AWB artikel 3.4

Eigenaar Bijzonderheden Beschikking Definitie

Toelichting Voorbeeld

Een schriftelijke beslissing van een bestuursorgaan inhoudende een publiekrechtelijke rechtshandeling voor een algemeen, individueel of concreet geval. Verleende vergunning Afgewezen bezwaar Algemene Maatregel van Bestuur

Eigenaar Bijzonderheden Betalingsverplichting Definitie Financiële verplichting behorende bij een zaak Toelichting Bij sommige zaken behoort een financiële verplichting gerelateerd aan een subject. Voorbeeld Leges Dwangsom Heffing Eigenaar Bijzonderheden Bevinding Definitie Toelichting Voorbeeld

Een bevinding is de uitkomst van een waarneming vergeleken met een norm. Overschrijding van de afstand met 1 meter Lozing van CO2 is lager dan toegestaan.


177


Bevoegd gezag Definitie Toelichting Voorbeeld

Op basis van wetgeving bevoegd bestuursorgaan. WVO-Info noemt dit instantie. Rijkswaterstaat Waterschap

Eigenaar Bijzonderheden Bezoek Definitie


Een bezoek aan een handeling door een medewerker van Rijkswaterstaat met als doel het waarnemen. Bezoek aan lozingsobject voor het nemen van een monster. Bezoek aan een werk voor het controleren van de gebruikte materialen en afmetingen.

Eigenaar Bijzonderheden Branche Definitie Toelichting

Voorbeeld

Een bepaald cluster van nijverheid met enige samenhang. Van belang voor het samenstellen van een risicoprofiel. O.a. de IPPC indeling kan hier worden toegepast, evenals die uit het Activiteitenbesluit. Autowasstraten Drukkerijen

Eigenaar Bijzonderheden Capaciteit Definitie Toelichting Voorbeeld Eigenaar Bijzonderheden Document Definitie Toelichting Voorbeeld


178

Het vermogen om bepaalde plannen tot uitvoer te brengen. Aantal medewerkers

Correspondentie of behandelstuk dat verband houdt met een aanleiding. Gerelateerd aan archiefstukken. Vergunningaanvraag Tekening Extern technisch advies Elektronisch formulier Ook een melding van een handhaver kan in de vorm van een e-formulier worden aangeleverd.


Dossier Definitie Toelichting Voorbeeld Eigenaar Bijzonderheden

Een verzameling gerelateerde zaken per subject inclusief alle documenten. Alle vergunningenaanvragen per subject Dossier heeft verschillende betekenissen in verschillende systemen. TRIM wijkt daarin af van SAP en WVO.

Eenheid & Parameter Definitie Een parameter is een specifiek grootheid waarop kan worden waargenomen in een bepaalde maat of dimensie. Toelichting Voorbeeld afmeting: meter hoeveelheid: kg/m3 Eigenaar Bijzonderheden Handeling Definitie

Toelichting

Een handeling is een activiteit in het gebied waar Rijkswaterstaat bevoegd gezag is die een bepaald risico met zich meebrengt. Een handeling is een generalisatie van een werk of lozingsobject

Voorbeeld Eigenaar Bijzonderheden Handelingslocatie Definitie Toelichting Voorbeeld Eigenaar Bijzonderheden Legger Definitie

Toelichting

179

De aanduiding van de plaats waar een handeling wordt verricht Kan betrekking hebben op een punt, lijn of vlak (in geografische begrippen). X,Y,Z coördinaten van een steiger in rijkswater.

Beschrijving van het beheersgebied van een bevoegd gezag op basis van wetgeving in termen van afmetingen en onderhoudsstatus. Legger is een breed begrip, ook gebruikt bij waterschappen. Hier geeft het vooral het profiel van beheersgebied aan (dwarsdoorsnede van een rivier). In Havik 2 wordt ook de grens van het gebied wat bij een bepaalde bevoegd gezag hoort hiermee bedoelt. In WVO-Info is dit een “gebied”. Ook gerelateerd aan de EROW (Elementair


Voorbeeld Eigenaar Bijzonderheden Lozingsobject Definitie

Toelichting

Voorbeeld Eigenaar Bijzonderheden Medewerker Definitie Toelichting Voorbeeld

Rioleringsgedeelte of OppervlakteWater) en Rijkswater (in gebruik als indeling van de Rijkswateren bij BVR voor heffingen). Rijkswateren

Het object dat systematisch lozing van aan het objectgebonden afvalwater voortbrengt, waarbij het geloosde afvalwater al dan niet via werken op directe of indirecte wijze in het oppervlaktewater terecht komt. Van toepassing voor de WVO en het activiteitenbesluit. Opgenomen in de WVO-info administratie. Proceswater dat wordt geloosd op rijkswater Subobject van een Handeling

Een subject (natuurlijk persoon) in dienst van Rijkswaterstaat met een bepaalde bevoegdheid. WVO-Info noemt dit functionaris. Handhaver Zuidervliet Teamleder Baziger

Eigenaar Bijzonderheden Meetpunt Definitie



Norm Definitie Toelichting

180

WVO-info: een punt waar de kwaliteit van het geloosde afvalwater (of ingenomen oppervlaktewater) gemeten kan worden. IDsW: aanduiding van een plaats of gebied waar een meting is/wordt verricht. Homoniem Plaats in de uiterwaarden waar een werk wordt gemeten. Plaats waar de lozingspijp in het rijkswater uitkomt. De definitie van IDsW heeft de voorkeur vanwege open standaarden.

Maatstaf of richtsnoer waar een handeling aan dient te voldoen, gebaseerd op een beschikking. In WVO-Info zijn er algemene en specifieke normen. De eerste hebben betrekking op “algemene” generiek normen. De tweede op een


Voorbeeld

specifiek gebied. Maximale afstand is 5 meter. Maximale lozing van CO2 is 300 gram per uur.

Eigenaar Bijzonderheden Opslaglocatie Definitie Toelichting Voorbeeld

De plaats waar een document is opgeslagen en kan worden teruggevonden. Archiefkast Hardeschijf

Eigenaar Bijzonderheden Organisatorische eenheid Definitie Een indeling van een bevoegd gezag met een bepaalde taak. Toelichting Voorbeeld Afdeling JBO Afdeling toezicht Eigenaar Bijzonderheden PIN Definitie Toelichting Voorbeeld Eigenaar Bijzonderheden Plan Definitie Toelichting Voorbeeld

Indicator van het prestatieniveau PIN handhaving

Het voornemen tot het doen van bepaalde activiteiten. HUP JUP Weekplanning

Eigenaar Bijzonderheden Publicatie Definitie Toelichting Voorbeeld

Het geven van kenbaarheid aan een beschikking naar de samenleving via beschikbare media. Internetpublicatie Krantenpublicatie


181


Rapport Definitie Toelichting Voorbeeld Eigenaar Bijzonderheden Risicoprofiel Definitie

Toelichting Voorbeeld Eigenaar Bijzonderheden Status Definitie Toelichting Voorbeeld

Verslag over de prestatie T1 rapportage

De mate waarin een bepaalde branche een risico oplevert voor het beheersgebied van het bevoegd gezag, gebaseerd op naleefgedrag en impact. Hoog risico voor drukkerijen.

De fase waarin de zaak zich bevindt vanuit de procesgang. Ontvangen In behandeling

Eigenaar Bijzonderheden Subject Definitie


Een natuurlijk of niet-natuurlijk persoon die onderwerp van rechten kan zijn. Natuurlijke persoon (NP): Een ingeschreven persoon of ander buitenlands natuurlijk persoon (een natuurlijke persoon woonachtig in het buitenland) van belang voor de taakuitoefening van de overheid. Niet-natuurlijke persoon (NNP): een ingeschreven niet-natuurlijke persoon of ander buitenlands nietnatuurlijk persoon. Afkomstig van GFO zaken. Shell Meneer Noordervliet

Eigenaar Bijzonderheden Vaartuig Definitie Toelichting Voorbeeld

Transportmiddel voor vervoer over water. Schip Duwbak

Eigenaar Bijzonderheden Verslag

182


Definitie Toelichting Voorbeeld Eigenaar Bijzonderheden Voertuig Definitie Toelichting Voorbeeld Eigenaar Bijzonderheden Waarneming Definitie Toelichting Voorbeeld

Vastgelegde gegevens betreffende de bevindingen van een bezoek. Bezoekverslag van een lozingsobject

Transportmiddel voor vervoer over lans Vrachtwagen

Metingen of constatering ten aanzien van een handeling op een meetpunt. Monster van lozingen Omvang van een pijpleiding

Eigenaar Bijzonderheden Werk Definitie

Toelichting Voorbeeld Eigenaar Bijzonderheden Wet Definitie


Een handeling die betrekking heeft op fysieke werken in of aan het gebied waar Rijkswaterstaat bevoegd gezag is, met een bepaald risico. Met name van toepassing op de Wbr en Wbb. Daarmee ook in SAP Havik. Graafwerkzaamheden in een uiterwaard Aanleggen steiger in rijkswater Subobject van een Handeling

Het geheel van geldende rechtsvoorschriften of blijvende verordeningen uitgevaardigd door de overheid. Waterwet Algemene wet bestuursrecht

Eigenaar Bijzonderheden Zaak Definitie


183

Een zaak is een samenhangende hoeveelheid werk met een welgedefinieerde aanleiding en een welgedefinieerd eindresultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden. Afkomstig uit GFO zaken Vergunningzaak


Sanctiezaak Eigenaar Bijzonderheden

184


Definitiestudierapport Handhaving Vergunningverlening Internet Klantcontact

Recommend Documents