Regionale UitvoeringsDiensten Informatiearchitectuur (RUDI) 'Op weg naar een Informatiemodel'

Regionale UitvoeringsDiensten Informatiearchitectuur (RUDI) 'Op weg naar een Informatiemodel'

Versie: 1.0 Datum: 11-4-2011 Auteur: Mark van den Broek

'Op weg naar een Informatiemodel' v 1.0 Regionale UitvoeringsDiensten Informatiearchitectuur (RUDI)

1

Inhoudsopgave 1

Managementsamenvatting ......................................................................................................4 1.1. Basis- en kerngegevens........................................................................................................... 4 1.2. Procesgegevens ........................................................................................................................ 5 1.3. Gegevensuitwisseling .............................................................................................................. 6 1.4. Aanbevelingen ......................................................................................................................... 6 1.5. Tot slot ...................................................................................................................................... 8

2

Inleiding .....................................................................................................................................9

3

Doel en afbakening .................................................................................................................11 3.1. Doel RUDI ................................................................................................................................ 11 3.2. Reikwijdte ............................................................................................................................... 11 3.3. Randvoorwaarden ................................................................................................................. 11 3.4. Uitgangspunten ..................................................................................................................... 12

4

Informatiebehoefte .................................................................................................................13 4.1. Basis- en kerngegevens......................................................................................................... 13 4.1.1.

4.2.

4.2.1.

Zaakgericht Werken en referentiemodel RGBZ .......................................................................... 16

4.2.2.

Zaaktypecatalogus (ZTC) ............................................................................................................... 18

4.3. 4.4.

5

Geaggregeerde gegevens....................................................................................................... 19 Gegevensuitwisseling ............................................................................................................ 19

4.4.1.

Technisch en Logistiek .................................................................................................................. 19

4.4.2.

Gestructureerde gegevens ............................................................................................................. 19

4.4.3.

Ongestructureerde gegevens ........................................................................................................ 20

Bedrijfsfunctie- en procesmodellen .......................................................................................22 5.1. Zaakgericht werken: een andere manier van kijken naar processen............................. 22 5.1.1.

De Zaak: een container met daarin alle relevante informatie .................................................. 22

5.1.2.

Virtuele dossiers: de satéprikker door alle Zaken ...................................................................... 23

5.1.3.

De Zaak, Subzaken en Vervolgzaken: de basis voor samenwerking in de keten .................... 24

5.2. 5.3. 5.4. 5.5. 6

Referentiemodellen RSGB en RITHm ........................................................................................... 13

Procesgegevens ...................................................................................................................... 15

Vergunningverlening ............................................................................................................ 24 Toezicht en Handhaving....................................................................................................... 26 Bezwaar en Beroep ................................................................................................................ 27 Klachten en Meldingen ......................................................................................................... 29

Bouwstenen en hun stand van zaken ...................................................................................30 6.1. Basis- en kerngegevens......................................................................................................... 30 6.1.1.

Het Stelsel van Basisregistraties................................................................................................... 30

6.1.2.

Referentiemodel voor het Stelsel van Gemeentelijke Basisgegevens (RSGB 2.01, GEMMA) ... 31

6.1.3.

Referentie Informatiemodel Toezicht en Handhaving (RITHm) ............................................... 32

6.2.

Procesmodellen en -gegevens .............................................................................................. 35

6.2.1.

Bedrijfsfunctiemodel Provincies................................................................................................... 35

6.2.2.

Bedrijfsfunctiemodel Inspecties ................................................................................................... 36

6.2.3.

GEMMA-Procesarchitectuur (1.0, GEMMA) .................................................................................. 36

6.2.4.

Referentiemodel Gemeentelijke Basisgegevens Zaken (RGBZ 1.0, GEMMA) ............................ 37

6.2.5.

Zaaktypecatalogus (ZTC 1.0, GEMMA) ......................................................................................... 38

6.3.

Gegevensuitwisseling ............................................................................................................ 40

6.3.1.

Bestandsformaten .......................................................................................................................... 40

6.3.2.

Uitwisseling van gegevens ............................................................................................................ 40


2

7

Bijlagen ....................................................................................................................................43 7.1. Bijlage A: mapping van gegevens(vragen) op RSGB, RITHm, RGBZ en ZTC ................... 43 7.2. Bijlage B: beantwoording Informatievragen met behulp van het informatiemodel ..... 44 7.2.1.

Vergunningverlening ..................................................................................................................... 44

7.2.2.

Handhaving .................................................................................................................................... 48

7.3.

Bijlage C: RITHm versie 0.8 ................................................................................................... 53


3

1

Managementsamenvatting

De basis voor dit informatiemodel ligt in de opdracht een model te ontwikkelen waarmee Regionale Uitvoeringsdiensten eenvoudig en gestandaardiseerd informatie over hun primaire processen kunnen uitwisselen met Opdrachtgevers en Ketenpartners. Vanwege de complexe omgeving waarin de RUD moet opereren, is als randvoorwaarde meegegeven dat het model zowel maximale gemeenschappelijkheid moet nastreven, als ruimte moet bieden aan de lokale verschillen die onvermijdelijk zullen optreden bij het vormgeven van de afspraken tussen de RUD en verschillende opdrachtgevers. Populair gezegd: gemeenschappelijk waar dat kan, apart waar het moet. Uitgangspunt voor de opdracht is dat zoveel mogelijk gebruik dient te worden gemaakt van, c.q. aansluiting dient te worden gezocht bij, reeds bestaande modellen en standaarden. Bij het verstrekken van de opdracht voor de ontwikkeling van dit informatiemodel was een aantal van dergelijke modellen en standaarden al in beeld (zie § 3.4). Laatstgenoemd uitgangspunt heeft grote invloed gehad op de bouwstenen waaruit het informatiemodel is opgebouwd. Zo bleek een aantal bestaande standaarden en referentiemodellen - ook - zeer goed toepasbaar voor informatie-uitwisseling tussen de RUD en haar Opdrachtgevers en Ketenpartners. Sterker nog, deze standaarden en modellen zijn in de basis zo generiek inzetbaar, dat ze ook in veel andere situaties toepasbaar zullen blijken te zijn. In onderstaand schema is geschetst uit welke bouwstenen het informatiemodel voor de RUD is opgebouwd:

Figuur 1 - Schematische weergave van de bestanddelen van het informatiemodel

Dit schema wordt - van beneden naar boven - in de volgende twee paragrafen toegelicht. Aansluitend wordt de wijze van gegevensuitwisseling en een aantal aanbevelingen beschreven.

1.1.

Basis- en kerngegevens

De basisgegevens vormen het fundament voor de informatiehuishouding van de overheid. In de afgelopen jaren is hard gewerkt aan het afbakenen, beschrijven en registreren van de


4

gegevens over personen (subjecten) en voorwerpen (objecten) die overheidsbreed gemeenschappelijk - moeten - worden gebruikt: het landelijk stelsel van basisregistraties. Vanuit hun aard zijn de landelijke basisgegevens niet toereikend voor het voorzien in de informatiebehoefte van elk proces dat zich binnen de overheid voltrekt. Overheidslagen en sectoren vullen deze basisgegevens dus aan met gegevens die van belang zijn voor hùn specifieke processen. Omwille van het onderscheid met de landelijk gedefinieerde basisgegevens, worden deze aanvullende gegevens over personen en voorwerpen in dit document ‘kerngegevens’ genoemd. Gemeenten hebben hun kerngegevens gemodelleerd in het Referentiemodel voor het Stelsel van Gemeentelijke Basisgegevens (RSGB). Dit model omvat de landelijke basisgegevens uit de Basisregistratie Adressen en Gebouwen (BAG), Gemeentelijke Basisadministratie (GBA), Register Niet-Ingezetenen (RNI), Nieuw Handelsregistrer (NHR), Basisregistratie Kadaster (BRK), Basisregistratie Waarde Onroerende Zaken (BRWOZ), Basisregistratie Grootschalige Topografie (GBKN/BGT/IMGeo) en breidt deze landelijke gegevensverzamelingen uit met entiteiten en attributen die voor de gemeentelijke processen van belang zijn. Omdat veel van deze gegevens ook van belang zijn voor de RUD, is het RSGB een belangrijke pijler in het informatiemodel. Het RSGB dekt echter niet de volledige informatiebehoefte met betrekking tot basis- en kerngegevens van de RUD af. Met name de gegevens die van belang zijn voor vergunningverlening en toezicht en handhaving vanuit milieuperspectief, ontbreken in RSGB. Deze basis- en kerngegevens worden momenteel vanuit het inspectiedomein geïnventariseerd en gemodelleerd in het Referentie Informatiemodel Toezicht en Handhaving (RITHm). Ook RITHm vertrekt vanuit de landelijke basisregistraties. RSGB en RITHm gezamenlijk voorzien uitstekend in de behoefte aan basis- en kerngegevens van de RUD en zijn Opdrachtgevers en Ketenpartners.

1.2.

Procesgegevens

Op dit fundament van basis- en kerngegevens bouwt het informatiemodel een laag, bestaande uit twee onderdelen (RGBZ en ZTC) voor het configureren, registreren en uitwisselen van gegevens over processen. Het Referentiemodel voor Gemeentelijke Basisgegevens Zaken (RGBZ) is een generiek objectmodel waarin alle gegevens die relevant - kunnen - zijn voor een individueel proces (de ‘Zaak’) zijn gemodelleerd. Anders dan de term ‘Gemeentelijk’ doet vermoeden, is het model bruikbaar voor elk type proces en dus veel breder inzetbaar dan alleen binnen het gemeentelijke domein. RGBZ omvat gegevens over de procesvoortgang (o.a. de status), de voor het proces relevante documentatie (zoals de aanvraag en een eventueel besluit) en de bij het proces betrokken subjecten en objecten (basis- en kerngegevens). Met deze laatste categorie gegevens bindt het RGBZ de relevante basis- en kerngegevens uit RSGB aan individuele processen. De charme en kracht van het RGBZ ligt in het generieke karakter van het model. Zo is in het model wel vastgelegd dat een proces bepaalde subjecten en/of objecten betreft, een aantal statussen doorloopt, dat daarbij documenten ontstaan en dat er een resultaat en/of besluit uit het proces volgt. Maar het model zegt niets over wélke statussen, document(typ)en en uitkomsten processen kunnen hebben. Logisch, want daarmee zou het model niet langer generiek zijn. Om dit generieke model ook daadwerkelijk inzetbaar te maken voor specifieke typen processen, zoals de behandeling van een vergunningaanvraag of melding, zijn aanvullende


5

afspraken nodig. Zeker als processen de grenzen van afdelingen of organisaties overstijgen. Aan welk(e) (soort) basisgegevens moet het proces gerelateerd kunnen worden? Welke statussen onderscheiden we in het proces en wat betekenen ze? Welke document(typ)en kunnen - of moeten - tijdens het proces ontstaan? Welke uitkomsten kan het proces hebben? Etcetera. Deze afspraken, waarmee het generieke RGBZ dus specifiek wordt ingevuld voor een bepaald type proces, worden vastgelegd in de Zaaktypecatalogus (ZTC). Door deze ZTC te delen met de afdelingen en organisaties waarmee wordt samengewerkt, ontstaat een gemeenschappelijk vocabulaire voor het communiceren over de verschillende typen processen. Dit gemeenschappelijke vocabulaire is in de eerste plaats noodzakelijk voor het gezamenlijk kunnen uitvoeren van individuele processen. Maar het is ook cruciaal voor het kunnen aggregeren van informatie, bijvoorbeeld voor de verantwoording over kritieke prestatie indicatoren (KPI’s).

1.3.

Gegevensuitwisseling

Aan de hand van de hierboven geschetste modellen kunnen de RUD, Opdrachtgevers en Ketenpartners hun gegevens op gelijke wijze modelleren en - gebruikmakend van de ZTC - de voor processen relevante parameters overeenkomstig configureren. Maar daarmee zijn die gegevens nog niet uitwisselbaar tussen partijen. Dat is waar het Standaard UitwisselingsFormaat (StUF) in voorziet. StUF is net als RSGB en RGBZ onderdeel van de GEMeentelijke Model Architectuur (GEMMA) en werkt in een tweetal sectormodellen (StUF-BG en StUF-ZKN) uit hoe gegevens afkomstig uit RSGB resp. RGBZ middels XML-berichten kunnen worden uitgewisseld.

1.4.

Aanbevelingen

Hoewel uit het bovenstaande de conclusie kan worden getrokken dat het informatiemodel voor de RUD volledig kan worden samengesteld uit reeds bestaande standaarden en referentiemodellen, is die conclusie een beetje voorbarig. Ja, in genoemde standaarden en referentiemodellen wordt een belangrijke en brede basis gevonden voor het informatiemodel voor de RUD. Maar er moet aan elk van de modellen ook nog wel wat ‘verbouwd’ worden om ze voor de RUD écht toepasbaar te maken. Welke aanpassingen nodig zijn wordt in de navolgende hoofdstukken beschreven. Dit heeft geleid tot het formuleren van onderstaande aanbevelingen. Aanbeveling 1 Aanbeveling 2

Aanbeveling 3 Aanbeveling 4


hanteer RSGB als basis voor de registratie van basis- en kerngegevens. actualiseer RSGB, met name waar het NHR betreft. RSGB is ontwikkeld o.b.v. een concept Gegevenscatalogus uit juli 2008; de meest recente versie (1.5) dateert van februari 2011 en bevat significante wijzigingen ten opzichte van eerstgenoemde versie. zorg dat de informatiebehoefte van de RUD-en in de verdere ontwikkeling van RITHm wordt betrokken. verbind RSGB en RITHm met elkaar: zo ontstaat een model waarmee - in potentie - de volledige populatie basisgegevens en voor toezicht en handhaving relevante entiteiten kunnen worden geregistreerd. Voor de huidige versie van RITHm betekent dit dat het deel dat nu wordt ontleend aan landelijke basisregistraties, verbonden wordt met de betreffende entiteiten uit RSGB. breid RITHm (Objecten) uit met INSTALLATIE. harmoniseer de naamgeving van entiteiten en attributen over de verschillende standaarden heen.


6


Aanbeveling 9

Aanbeveling 10

Aanbeveling 11

Aanbeveling 12 Aanbeveling 13 Aanbeveling 14

Aanbeveling 15

Aanbeveling 16


hanteer RGBZ als basis voor de registratie van gegevens over processen (zaken). breid de domeintabellen voor Zaaktypen en Documenttypen uit met de zaaktypen, respectievelijk documenttypen die voor de RUD en ketenpartners van belang zijn. Idealiter krijgt dit zijn weerslag in een nieuwe - uitgebreide - versie van de Zaaktypecatalogus (zie hieronder in § 4.2.2), maar als die ontwikkeling te onzeker blijft, dienen ten minste de domeintabellen van RGBZ te worden aangepast. breid RGBZ uit, afhankelijk van of en hoe de aanbeveling om RSGB en RITHm met elkaar te verbinden wordt vormgegeven. Het is immers van belang om - naast basisgegevens o.b.v. RSGB - ook de entiteiten uit RITHm te kunnen binden aan zaken. breid RGBZ uit met eigenschappen: ZAAKEIGENSCHAPTYPE (‘hoort bij’ ZAAKTYPE) en ZAAKEIGENSCHAP (‘is van’ ZAAKEIGENSCHAPTYPE) en ZAAK ‘heeft’ ZAAKEIGENSCHAP. Daarmee kunnen, zonder het generieke karakter van RGBZ aan te tasten, nieuwe gestructureerde gegevens en classificaties eenvoudig als eigenschap aan zaaktypen worden gebonden en bij individuele zaken worden gebruikt. breid de GEMMA ZTC uit met de andere entiteiten - hoofdzakelijk uit RGBZ - die een zaaktype definiëren, zoals STATUSTYPE, DOCUMENTTYPE, ROL, ZAAKOBJECT(?). breid de standaardinhoud van de GEMMA ZTC uit met toezicht en handhavingsprocessen. hanteer StUF 3.01 en de sectormodellen StUF-BG 3.10 en StUF-ZKN 3.10 voor gegevensuitwisseling. breid de StUF sectormodellen uit, afhankelijk van of en hoe de aanbeveling om RSGB en RITHm met elkaar te verbinden wordt vormgegeven. Het is immers van belang om - naast basisgegevens o.b.v. RSGB - ook de entiteiten uit RITHm elektronisch te kunnen uitwisselen. bestanden die door de RUD of ketenpartners digitaal worden gecreëerd, worden uitgewisseld in een bestandsformaat dat voorkomt op de ‘Pas toe of leg uit’-lijst van het College Standaardisatie of - indien deze lijst niet voorziet in een toepasselijk bestandsformaat - in een bestandsformaat dat voorkomt op de lijst ‘Gangbare Open Standaarden’. bestanden die niet door de RUD of ketenpartners digitaal zijn gecreëerd, worden zowel in hun oorspronkelijke bestandsformaat als in een gestandaardiseerd (‘Pas toe of leg uit’, resp. ‘Gangbare Open Standaarden’) bestandsformaat uitgewisseld. breid het sectormodel StUF-ZKN zodanig uit dat ook documenten / dossiers kunnen worden uitgewisseld. neem RESULTAATTYPE en RESULTAAT op als entiteiten in RGBZ.

In dit document wordt geen uitspraak gedaan over wie verantwoordelijk is voor het nemen van besluiten over de opvolging van deze aanbevelingen, noch over de verantwoordelijkheid voor de uitvoering die daaruit voortvloeit.


7

1.5.

Tot slot

Het is niet eenvoudig een informatiemodel te ontwikkelen voor een omgeving waarin nog zoveel beweging is. Het overgrote deel van de Regionale Uitvoeringsdiensten moet nog worden gevormd, inclusief afspraken over taken, verantwoordelijkheden, processen en procesknips, prestatie-indicatoren, etcetera met Opdrachtgevers en Ketenpartners. De Regionale Uitvoeringsdiensten hebben dus nog een lange reis voor de boeg en tijdens die reis zullen inzichten worden opgedaan die bij het opstellen van dit informatiemodel niet bestonden. Dit informatiemodel moet dezelfde reis volgen, zodat nieuwe inzichten leiden tot bijstelling en verdere detaillering van het model. Focus on the journey, not the destination!


8

2

Inleiding

De aanleiding voor het ontwikkelen van dit informatiemodel ligt in het advies dat een groep deskundigen medio april 2010 formuleerde in hun rapportage ‘Architectuur RUD, de samenhang in de kluwen’. De voornaamste conclusie uit deze rapportage luidde: “uitwerking informatiestromen is nu nodig met focus op standaardisatie / uniformering van zaakinformatie en daaruit geaggregeerde informatie voor beleid”. Dit advies is uitgebracht aan en overgenomen door het ‘projectleidersoverleg RUD’. In de zomer van 2010 is onder regie van IPO en met steun van het Ministerie van VROM (nu: IenM) door ICTU gestart met het uitwerken van deze conclusie. Begeleid door een Expertgroep met vertegenwoordigers uit provincies, milieudiensten en gemeenten is een informatiemodel ontwikkeld dat, zo luidde de opdracht, zoveel mogelijk voortbouwt op bestaande modellen, standaarden en best practices. Een ieder die de complexe omgeving kent waarin de RUD wordt gepositioneerd, begrijpt dat hiervoor wel een ingewikkelde puzzel moest worden gelegd. Tot veler verrassing bleken veel al bestaande puzzelstukjes goed te passen in deze RUDpuzzel. Het is mogelijk om een in groot deel van de informatiebehoefte van de RUD en zijn ketenpartners te voorzien door gebruik te maken van reeds ontwikkelde modellen en standaarden. Weliswaar met een aantal aanpassingen, maar die zijn te overzien. Deze constatering is waardevol voor de Regionale Uitvoeringsdiensten, maar ook een belangrijk bewijs dat alle investeringen die de overheid als geheel heeft gedaan in het ontwikkelen van modellen en standaarden, vruchten afwerpen. Of beter: kùnnen afwerpen. Onbekend maakt onbemind en zelfs als modellen en standaarden worden gekend, betekent dit niet automatisch dat ze worden herkend, laat staan erkend. Voor dat laatste moeten partijen weerstand kunnen bieden aan de natuurlijke Not Invented Here-reflex en open staan voor ‘het gemeenschappelijke’ in plaats van ‘de verschillen’. Ik prijs me gelukkig met een Expertgroep die daartoe in staat was: dat heeft het pad geëffend voor het informatiemodel dat voorligt. Maar ook met dit informatiemodel is ‘(ver)eenvoudig(d)e en gestandaardiseerde informatieuitwisseling tussen de RUD en zijn opdrachtgevers en ketenpartners’ nog geen realiteit. Naast de aanbevelingen die worden gedaan voor het uitbreiden en/of verbeteren van modellen en standaarden, rust dit model op een zaakgerichte uitwerking en implementatie van de procesgang. Die zaakgerichte benadering van processen is weliswaar in zwang binnen het gemeentelijk domein, maar nog verre van vanzelfsprekend voor andere opdrachtgevers en ketenpartners van de RUD. Het ‘succes’ van dit informatiemodel wordt daarmee dus niet slechts bepaald door de implementatie van de - architecturale en informatorische aanbevelingen uit dit document. Zonder significante organisatorische en procesmatige aanpassingen in de richting van zaakgericht werken gaat het model niet werken. En die laatste opgave is vele malen groter dan het verder uitwerken van - de aanbevelingen uit - dit informatiemodel.

Mark van den Broek in.spiratie.nl


9

Leden Expertgroep: André Batenburg (Provincie Zuid-Holland) Tim Berkelaar (ICTU) Jan Bruijn (Provincie Overijssel) Emile Hagelen (Provincie Gelderland) Dick de Heer (Gemeente Utrecht, op persoonlijke titel) André Hoogeboom (Milieudienst Midden-Holland) Sjaak Kanbier (Provincie Noord-Holland) Wilbert Kurvers (Provincie Limburg) Wim Letzer (DCMR Milieudienst Rijnmond) Arianne de Man (IPO) Adrie Spruit (Kwaliteitsinstituut Nederlandse Gemeenten) Johannes Tadema (Provincie Noord-Brabant) Monique Verhoeven (IPO) Ron de Visser (Provincie Zeeland)


10

3

Doel en afbakening

3.1.

Doel RUDI

Het vereenvoudigen en standaardiseren van de informatie-uitwisseling tussen de Regionale Uitvoeringsdienst en zijn opdrachtgevers en ketenpartners.

3.2.

Reikwijdte 1

De reikwijdte van dit model beperkt zich tot het modelleren van de informatie die relevant is 2 voor de volgende primaire processen : 1. 2. 3. 4.

Vergunningverlening Toezicht en Handhaving Bezwaar en Beroep Behandeling Klachten en Meldingen

Deze reikwijdte betekent overigens niet dat processen als Beleidsvorming en Planning & Control niet worden geraakt; integendeel. De informatie die in dit informatiemodel wordt gemodelleerd omvat cruciale informatie voor zowel de Beleidsvorming als Planning & Control. Het perspectief van waaruit de informatie is gemodelleerd, is de RUD. De focus ligt daarbij op de ‘Wat’-/’Welke’-vraag, in de context van het - kunnen - uitwisselen van gegevens met relevante partijen. Welke informatie heeft de RUD nodig om genoemde primaire processen adequaat te kunnen uitvoeren en daarover te communiceren met, c.q. rapporteren aan opdrachtgevers, ketenpartners en andere belanghebbenden? In dit document worden zo min mogelijk uitspraken gedaan over de ‘Hoe’-vraag. Het is aan elke RUD om - in overleg met voor hem relevante partijen - te bepalen met welke applicaties / systemen de informatie wordt voortgebracht en/of uitgewisseld.

3.3.

Randvoorwaarden

De dynamiek rond - de vorming van - RUD-en is groot. Per individuele RUD worden afspraken gemaakt met opdrachtgevers / deelnemers (Provincie, Gemeenten) en ketenpartners. En hoewel zoveel mogelijk standaardisatie wordt bepleit, is het onwaarschijnlijk dat alle RUD-en tot exact dezelfde afspraken zullen komen over het takenpakket, de processen, de mandatering, etc. 1. 2.

Het informatiemodel moet een zo breed mogelijke basis leggen voor gemeenschappelijkheid, maar moet ook voldoende flexibel zijn om lokale verschillen te absorberen.

Kortom: gemeenschappelijk waar dat kan, apart waar het moet.

1 2

Omwille van de leesbaarheid worden de begrippen informatie en gegevens in dit document enigszins vrij gehanteerd. Genoemde processen worden niet gemodelleerd. Er wordt aansluiting gezocht bij reeds bestaande procesmodellen.


11

3.4.

Uitgangspunten

Tijdens het eerste overleg van de Expertgroep zijn de volgende uitgangspunten vastgesteld. Het te ontwikkelen informatiemodel past binnen de volgende, al bestaande, architecturen:   

Nederlandse Overheids Referentie Architectuur (NORA, versie 3.0) Provinciale EnTerprise Referentie Architectuur (PETRA, versie 1.0) GEMeentelijke Model Architectuur (GEMMA)

Binnen genoemde architecturen is geen discussie over het nut en de noodzaak van een tweetal onderwerpen:  

Het gemeenschappelijk - verplicht - gebruik van basisgegevens. Zaakgericht werken.

Gerelateerd aan deze architecturen, zijn de volgende referentiemodellen en standaarden als vertrekpunt vastgesteld:     

Stelselcatalogus Basisregistraties (in beheer bij Logius) Referentiemodel voor het Stelsel van Gemeentelijke Basisgegevens (RSGB, versie 2.01, onderdeel van GEMMA) Referentiemodel voor Gemeentelijke Basisgegevens Zaken (RGBZ, versie 1.0, onderdeel van GEMMA) Zaaktypecatalogus (ZTC versie 1.0, onderdeel van GEMMA) Standaard UitwisselingsFormaat (StUF, versie 3.01, onderdeel van GEMMA) en de sectormodellen: o StUF-BG 3.10 voor de uitwisseling van basisgegevens conform RSGB o StUF-ZKN 3.10 voor de uitwisseling van zaakgegevens conform RGBZ

De toepasbaarheid van elk van deze architecturen, referentiemodellen en standaarden zal tijdens het ontwikkelen van het informatiemodel worden onderzocht.


12

4

Informatiebehoefte

Gelet op de complexe context waarbinnen de RUD opereert, zal het niet mogelijk zijn een volledig - 100% dekkend - model te ontwikkelen waarin alle informatie die de RUD, opdrachtgevers en andere ketenpartners met elkaar willen delen, een plek heeft. Dit zou immers vergen dat alle processen van alle RUD-en en alle opdrachtgevers en ketenpartners gestandaardiseerd zouden worden. Gelet op de autonomie van de verschillende partijen, is dat niet realistisch. Voor het inventariseren van de informatiebehoefte is daarom pragmatisch en empirisch gekeken naar vele bestaande beschrijvingen van processen, gegevens, prestatie-indicatoren, etc. Uiteraard is daarbij zo goed als mogelijk ingeschat of c.q. in welke mate een beschrijving representatief is voor een willekeurige RUD en zijn opdrachtgevers en andere ketenpartners. In dit informatiemodel wordt een drietal categorieën gegevens onderscheiden: 1. 2. 3.

Basis- en kerngegevens Procesgegevens Geaggregeerde gegevens

4.1.


Basis- en kerngegevens vormen het fundament voor nagenoeg alle processen die zich binnen de RUD voltrekken. Ze beschrijven de (rechts)persoon (subject) die betrokken is bij, resp. het voorwerp (object) van processen, activiteiten, etc. 4.1.1. Referentiemodellen RSGB en RITHm Het meest ontwikkelde model voor basisgegevens is RSGB, dat voortbouwt op het landelijke Stelsel van Basisregistraties. Maar - ook - in RSGB zijn gegevens die nodig zijn voor vergunningverlening, toezicht en handhaving, bezwaar en beroep en klachten en meldingen niet toereikend. Hierin voorziet het nog in ontwikkeling zijnde RITHm veel beter. In onderstaand tabel zijn de entiteiten uit genoemde modellen opgenomen die - potentieel - van belang zijn voor de RUD. Entiteit (oorsprong)

Model

Subject

RSGB

Rechtspersoon Natuurlijk Persoon Ingeschreven Persoon

RSGB RSGB RSGB

Ingezetene (GBA)

RSGB

Niet-Ingezetene (RNI)

RSGB

Ander Natuurlijk Persoon Niet-Natuurlijk Persoon

RSGB RSGB + RITHm

Ingeschreven Niet-Natuurlijk Persoon (NHR)

RSGB

Samenwerkingsverband (NHR)

RITHm

Ander Buitenlands Niet-Natuurlijk Persoon

RSGB

Vestiging (NHR)

RSGB

Functionaris (NHR)

RSGB

Activiteit Maatschappelijke Activiteit (NHR)

RSGB

Activiteit (NHR, niet authentiek!)

RITHm

Handelingen


RITHm

13

Entiteit (oorsprong)

Model

Onderwijs (NHR)

RITHm

Inrichting

RITHm

Werk

RITHm

Vervoer

RITHm

… Productstroom

RITHm

Object Adres, Gebouw en Terrein

RSGB

Gemeente

RSGB

Woonplaats (BAG)

RSGB

Wijk (CBS)

RSGB

Buurt (CBS)

RSGB

Gemeentelijke Openbare Ruimte

RSGB

Openbare Ruimte (BAG)

RSGB

Adresseerbaar Object Aanduiding

RSGB

Nummeraanduiding (BAG)

RSGB

Verblijfsobject (BAG)

RSGB

Standplaats (BAG)

RSGB

Ligplaats (BAG)

RSGB

Overige Adresseerbaar Object Aanduiding

RSGB

Overig Gebouwd Object

RSGB

Overig Terrein

RSGB

Pand (BAG) Overige Geo-objecten

RSGB RSGB

Wegdeel (IMGeo)

RSGB

Waterdeel (IMGeo)

RSGB

Terreindeel (IMGeo)

RSGB

Spoorbaandeel (IMGeo)

RSGB

Kunstwerkdeel (IMGeo)

RSGB

Inrichtingselement (IMGeo)

RSGB

Kadastrale Onroerende Zaak en Recht

RSGB

Kadastraal Perceel (BRK)

RSGB

Appartementsrecht (BRK)

RSGB

Zakelijk Recht (BRK)

RSGB

Gebruiksperceel?

RITHm

Tracé

RITHm

Voertuig (BRV)

RITHm

Vaartuig

RITHm

Vissersvaartuig (NRvV)?

RITHm

Dier?

RITHm

Product

RITHm

Stoffen en Producten

RITHm

Afvalstoffen

RITHm

Samenhangend met genoemde entiteiten modelleert RSGB een kleine 400 attributen. RITHm is op dit moment nog niet zover ontwikkeld dat er al attributen zijn gemodelleerd.


14

3

Een eerste - empirische - verkenning van de informatiebehoefte die samenhangt met de verschillende processen, geeft het beeld dat die met deze entiteiten voor basis- en kerngegevens nagenoeg geheel wordt afgedekt. Hieronder volgt een aantal aanbevelingen om dit fundament nog iets te verstevigen. Aanbeveling 1. hanteer RSGB als basis voor de registratie van basis- en kerngegevens. Aanbeveling 2. actualiseer RSGB, met name waar het NHR betreft. RSGB is ontwikkeld o.b.v. een concept Gegevenscatalogus uit juli 2008; de meest recente versie (1.5) dateert van februari 2011 en bevat significante wijzigingen ten opzichte van eerstgenoemde versie. Aanbeveling 3. zorg dat de informatiebehoefte van de RUD-en in de verdere ontwikkeling van RITHm wordt betrokken. 4

Aanbeveling 4. verbind RSGB en RITHm met elkaar: zo ontstaat een model waarmee - in potentie de volledige populatie basisgegevens en voor toezicht en handhaving relevante entiteiten kunnen worden geregistreerd. Voor de huidige versie van RITHm betekent dit dat het deel dat nu wordt ontleend aan landelijke basisregistraties, verbonden wordt met de betreffende entiteiten uit RSGB. Aanbeveling 5. breid RITHm (Objecten) uit met INSTALLATIE. Aanbeveling 6. harmoniseer de naamgeving van entiteiten en attributen over de verschillende standaarden heen. Het belang van een breed gedeeld fundament is zo groot, dat op dit punt maximaal moet worden gestandaardiseerd. Hier past geen ‘couleur locale’. Dit betekent dat alle betrokken partijen zich moeten scharen achter dit model voor Basis- en Kerngegevens.

4.2.

Procesgegevens

Basis- en kerngegevens beschrijven - vooral - de onderwerpen en/of voorwerpen van gebeurtenissen, activiteiten, handelingen, etc. Deze onderwerpen en voorwerpen vindt de overheid zo belangrijk dat zij het ontstaan, bestaan, wijzigen en weer verdwijnen ervan aan regels heeft gebonden en actief toeziet - vooraf en/of achteraf - op naleving van die regels. Deze overheidsprocessen zijn zelf ook weer aan regels gebonden, zodat belanghebbenden te allen tijde - kunnen - weten wat hun rechten en plichten zijn. Het spreekt vanzelf dat de overheid al haar handelen moet kunnen verantwoorden, zowel procesmatig (is de behandeling conform de spelregels verlopen?), als inhoudelijk (voldoet de uitkomst / het resultaat van de behandeling aan de spelregels?). Processen die door de overheid worden uitgevoerd, vertonen grote overeenkomsten met elkaar, ook als de onderwerpen (bijvoorbeeld het verlenen van een kapvergunning tegenover het verstrekken van een uitkering) enorm verschillen. Zo is er altijd een aanleiding voor - het starten van - een proces, zijn de subjecten en objecten bekend, kent het een maximale doorlooptijd, doorloopt het een aantal vaste statussen en heeft het een aantal - vooraf bekende - mogelijke uitkomsten. Tijdens - en dus niet pas na - de uitvoering van het proces wordt een volledig en gestandaardiseerd dossier gevormd, waarmee de overheid haar handelen zowel tijdens als na afloop van het proces kan verantwoorden. 3

Zie § 7.1 voor een mapping van de gegevensvragen die door de Expertgroep zijn aangeleverd, op de referentiemodellen RSGB, RITHm, RGBZ en ZTC. 4 Deze aanbeveling impliceert dat het Informatiemodel van de RUDen de ontwikkeling volgt van RITHm en dus géén eigen model ontwikkelt. Dit leidt wel tot een afhankelijkheid van e-Inspecties waar de (door)ontwikkeling RITHm is voorzien in spoor ‘c.’ - en deels wellicht in spoor ‘e.’ - van het Programma Informatieuitwisseling Milieuhandhaving (PIM).


15

Dit is in een notendop wat Zaakgericht Werken behelst en waarvoor in de afgelopen jaren sinds het vaststellen van GFO Zaken in 2004 - een breed instrumentarium is ontwikkeld. Zowel in de vorm van informatiemodellen - GFO Zaken, inmiddels opgevolgd door RGBZ(aken) -, een catalogus met daarin uitgewerkte processen - de Zaaktypecatalogus -, als een standaard (StUF-ZKN) voor het uitwisselen van zaakgegevens. Deze modellen en standaarden zijn geen ‘dode letters’: ze worden door ‘de markt’ in hoog tempo en in felle concurrentie geïmplementeerd, zowel in dedicated zaaksystemen als in de applicaties in de front- en backofficeapplicaties die met zulke zaaksystemen moeten koppelen. Ook landelijke voorzieningen als het OLO en MijnOverheid sluiten aan bij dit concept. In principe is elk(e) proces(gang) te registreren als een zaak; er is immers geen proces dat start zonder aanleiding of eindigt zonder resultaat en voor elk proces zijn de begrippen kwaliteit en doorlooptijd relevant. Het ‘zaakgericht maken’ van een type proces vergt echter wel enig denk- en configuratiewerk vooraf: wat is/zijn de aanleiding(en) en mogelijke resultaten, welke statussen doorloopt het proces, hoe is de dossieropbouw, etc. Logischerwijs rendeert deze investering in het vooraf uitdenken en configureren van een zaaktype meer naarmate het vaker - voor individuele procesgangen - kan worden hergebruikt. Zaakgericht werken leent zich dus bij uitstek voor repeterende, voorspelbare processen. En omgekeerd geldt natuurlijk ook dat een proces met een sterk ad-hoc-karakter (lage frequentie en/of hoge onvoorspelbaarheid van het procesverloop) minder profiteert van een investering in het vooraf uitdenken van een zaaktypeconfiguratie. 4.2.1. Zaakgericht Werken en referentiemodel RGBZ Zaakgericht Werken is een vastgesteld uitgangspunt voor de RUD en daarmee is ook het informatiemodel RGBZ een gegeven. Voor een goed begrip van de wijze waarop RGBZ ‘omgaat’ met processen, is het van belang onderscheid te maken tussen: 

Entiteiten die processen - ongeacht het type - gemeenschappelijk kunnen hebben (RGBZ) De voor een ‘type’ proces relevante entiteiten en de mogelijk waarden die ze kunnen 5 aannemen (Typedeclaraties ) De waarden die de entiteiten van een bepaald ‘type’ proces krijgen bij een individuele procesgang (Zaak)

 

Dit mondt uit in de volgende entiteiten die zijn gemodelleerd in RGBZ. Entiteit

Model

Zaaktype

RGBZ

Statustype

RGBZ

Besluittype

RGBZ

Documenttype

RGBZ

Zaak

RGBZ

Zaakobject

RGBZ

Object

RSGB (object)

Rol

RGBZ Betrokkene Subject Rechtspersoon

RGBZ RSGB (subject) RSGB

Natuurlijk Persoon

RSGB

Niet-Natuurlijk Persoon

RSGB

5

Een voorbeeld van zo’n typedeclaratie is het STATUSTYPE, waarmee de statussen worden benoemd die een zaken van een bepaald zaaktype doorlopen. Naast een omschrijving van de status wordt in zo’n typedeclaratie vastgelegd wat het volgnummer is en welke doorlooptijd de status heeft.


16

Entiteit

Model Vestiging

RSGB

Vestiging van Zaakbehandelende Organisatie Organisatorische Eenheid Medewerker

RGBZ RGBZ RGBZ

Status

RGBZ

Zaakdocument

RGBZ

Document

RGBZ

Enkelvoudig Document

RGBZ

Samengesteld Document

RGBZ

Besluit

RGBZ

Gerelateerd aan deze entiteiten zijn in RGBZ een kleine 150 attributen gedefinieerd en via de koppelingen met RSGB t.b.v. subjecten en objecten komen daar nog honderden attributen bij. Voor de entiteiten Zaaktype en Documenttype zijn domeintabellen in RGBZ opgenomen met daarin 317 zaaktypen en 89 documenttypen. Aanbeveling 7. hanteer RGBZ als basis voor de registratie van gegevens over processen (zaken). Aanbeveling 8. breid de domeintabellen voor Zaaktypen en Documenttypen uit met de zaaktypen, respectievelijk documenttypen die voor de RUD en ketenpartners van belang zijn. Idealiter krijgt dit zijn weerslag in een nieuwe - uitgebreide - versie van de Zaaktypecatalogus (zie hieronder in § 4.2.2), maar als die ontwikkeling te onzeker blijft, dienen ten minste de domeintabellen van RGBZ te worden aangepast. RGBZ registreert aldus alle generieke gegevens die van belang - kunnen - zijn voor een procesgang (zaak) en bindt daaraan de basis- en kerngegevens die relevant zijn voor die zaak. Aanbeveling 9. breid RGBZ uit, afhankelijk van of en hoe de aanbeveling om RSGB en RITHm met elkaar te verbinden wordt vormgegeven. Het is immers van belang om - naast basisgegevens o.b.v. RSGB - ook de entiteiten uit RITHm te kunnen binden aan zaken. Een heel belangrijk uitgangspunt bij het ontwerpen van RGBZ was dat het model moest passen op elk proces en dus geen processpecifieke entiteiten en attributen mocht bevatten. Dat kenmerkt RGBZ. De praktijk leert - inmiddels - dat dit niet helemaal goed aansluit bij de informatiebehoefte. Op alle niveaus - operationeel, tactisch en strategisch - bestaat voor specifieke typen processen de behoefte aan voor zo’n proces specifieke gegevens in een 6 gestructureerde vorm. Denk daarbij aan - rijp en groen -: 



 

Bij een Aanvraag Evenementenvergunning is de datum van het evenement van belang, zowel voor behandeling als voor bijvoorbeeld geautomatiseerde publicatie naar een evenementenkalender. Bij een Melding Openbare Ruimte is de categorie (straatverlichting, groen, afvalinzameling, milieu, ongedierte, etc.) zeer relevant voor het starten van de juiste (deel)zaak die de melding moet behandelen. Voor - het plannen van - Toezicht en Handhavingszaken waarin sprake is van gevaarlijke stoffen, kan de ADR-klasse en/of het UN-nummer van belang zijn. Voor de koppeling met de financiële administratie kunnen functies, categorieën, kostenplaatsen, kostensoorten, etc. van belang zijn.

6

Met ‘gestructureerd’ wordt bedoeld dat een gegeven geautomatiseerd kan worden verwerkt, bijvoorbeeld in workflows, filters, rapportages en dergelijke. Tegenover ‘gestructureerd’ staat ‘ongestructureerd’ waarmee gedoeld wordt op gegevens die zijn ingebed in een - voor machines moeilijk toegankelijke / interpreteerbare - context, zoals documenten.


17



Voor beleidsontwikkeling en managementrapportages is vaak behoefte aan een thematische classificatie: bodem, afval, vuurwerk, energie, etc.

Voor dit soort gestructureerde gegevens is momenteel geen plaats in RGBZ; ze zijn wel vast te leggen in documenten die in een zaakdossier belanden, maar daarmee zijn ze niet / moeilijk toegankelijk voor geautomatiseerde bewerkingen. Het is natuurlijk niet wenselijk dat elk gewenst processpecifiek gegeven wordt gemodelleerd in RGBZ; dat zou leiden tot een explosie van attributen en het generieke karakter van RGBZ volledig teniet doen. Aanbeveling 10. breid RGBZ uit met eigenschappen: ZAAKEIGENSCHAPTYPE (‘hoort bij’ ZAAKTYPE) en ZAAKEIGENSCHAP (‘is van’ ZAAKEIGENSCHAPTYPE) en ZAAK ‘heeft’ 7 ZAAKEIGENSCHAP . Daarmee kunnen, zonder het generieke karakter van RGBZ aan te tasten, nieuwe gestructureerde gegevens en classificaties eenvoudig als eigenschap 8 aan zaaktypen worden gebonden en bij individuele zaken worden gebruikt.

4.2.2. Zaaktypecatalogus (ZTC) De GEMMA ZTC (zie 6.2.5) is een eerste aanzet tot het beschrijven van Zaaktypeconfiguraties. Deze versie is een belangrijke stap in de richting van standaardisatie, bijvoorbeeld t.a.v. - de naamgeving van - zaaktypen, maar de ZTC dekt nog allerminst de volledige configuratie van zaaktypen af die op basis van RGBZ mogelijk is. Zo heeft een aanzienlijk aantal parameters in de ZTC betrekking op Documentaire Informatievoorziening (Archivering), maar ontbreken vele andere entiteiten en attributen uit RGBZ. Van verschillende kanten is bij KING al aangedrongen op uitbreiding van de Zaaktypecatalogus met de andere entiteiten en attributen die een zaaktype definiëren, zoals STATUSTYPE, DOCUMENTTYPE, ROL, ZAAKOBJECT(?), etc. Met een dergelijke uitbreiding (in de volksmond aangeduid met ‘ZTC+’) zou van de Zaaktypecatalogus een nog grotere standaardiserende werking uitgaan, nog steeds zonder al te zeer in de (proces)autonomie te treden. Zaakgericht Werken (en daarmee RGBZ en de ZTC) focust immers niet op de gedetailleerde procesgang - welke stappen worden in welke volgorde doorlopen -, maar op de (tussen)resultaten (o.a. documenten, statussen en resultaten) van het proces. Voor de RUD en haar ketenpartners is de ZTC cruciaal, omdat in de ZTC de gemeenschappelijke semantiek voor het ketenproces wordt vastgelegd: wat betekent een subzaak ‘Advies’? Welke statussen heeft deze zaak en wat betekenen ze, welke uitkomsten kan de zaak hebben, welke documenttypen worden in het dossier gestopt, etc. Aanbeveling 11. breid de GEMMA ZTC uit met de andere entiteiten - hoofdzakelijk uit RGBZ - die een zaaktype definiëren, zoals STATUSTYPE, DOCUMENTTYPE, ROL, ZAAKOBJECT(?). Aanbeveling 12. breid de standaardinhoud van de GEMMA ZTC uit met toezicht en handhavingsprocessen.

7

De meeste zaaksystemen die op dit moment op de markt zijn, bieden functionaliteit om dit soort proces(type)specifieke gegevens te definiëren. Omdat RGBZ ze niet standaardiseert, doet elke leverancier dit op geheel eigen wijze, hetgeen de interoperabiliteit niet ten goede komt. Overigens betekent het opvolgen van deze aanbeveling niet alleen het uitbreiden van RGBZ met deze entiteiten, maar ook het standaardiseren van de ‘content’ (domeintabellen) ervan. Dit laatste zou bij voorkeur neerslaan in een doorontwikkelde ZTC (zie Aanbeveling 11). 8 Deze aanbeveling is niet onomstreden, omdat op deze wijze toch proces(type)specifieke gegevens worden opgenomen in RGBZ. Een alternatief om hetzelfde doel te bereiken, is RGBZ zó aanpassen dat er sectormodellen met proces(type)specifieke gegevens aan kunnen worden gebonden; vergelijkbaar met de wijze waarop RSGB met RGBZ is verbonden. Omdat dit een ingrijpender aanpassing is én omdat de markt - zie voetnoot 7 - in de praktijk al voorsorteert op opname van proces(type)specifieke gegevens bij zaken, wordt de aanbeveling vooralsnog gehandhaafd.


18

4.3.

Geaggregeerde gegevens

Zowel voor de primaire als de planning en control processen bestaat behoefte aan het kunnen aggregeren van de gegevens. Voor primaire processen zorgt geaggregeerde informatie vooral voor het in de juiste context plaatsen van een individuele zaak. Denk bijvoorbeeld aan vragen als:   

Welke vergunningen zijn er al afgegeven voor dit bedrijf, deze inrichting, dit verblijfsobject? Zijn er meer meldingen / klachten van vergelijkbare aard en/of uit het zelfde gebied binnengekomen? Welke overtredingen zijn er in het verleden bij dit bedrijf geconstateerd, is er aangeschreven, zijn er strafrechtelijke of bestuurlijke sancties opgelegd?

Geaggregeerde informatie die wordt ingezet voor planning en control heeft meer het karakter van managementinformatie en wordt enerzijds ingezet voor het meten en bewaken van de kwantiteit / kwaliteit (KPI’s) en anderzijds voor beleidsvorming. Voorbeelden van dergelijke vragen zijn:   

Hoeveel vergunningen zijn binnen de wettelijke termijn afgehandeld? Tegen hoeveel besluiten is bezwaar aangetekend? Binnen welke branche werden veel overtredingen geconstateerd?

Voor het flexibel kunnen aggregeren van gegevens is Aanbeveling 10 van groot belang. Zonder deze toevoeging zijn de aggregatiemogelijkheden binnen het informatiemodel veel beperkter. In § 7.2 is op basis van de informatievragen die door de Expertgroep zijn aangeleverd, een aanzet gegeven voor de beantwoording van dit soort vragen aan de hand van de entiteiten en attributen uit dit informatiemodel. Daarmee wordt empirisch inzicht geboden in de mogelijkheden en beperkingen van het informatiemodel dat in dit document is geschetst.

4.4.


Het uiteindelijke doel van RUDI is het vereenvoudigen van de informatie-uitwisseling tussen de RUD en zijn opdrachtgevers en ketenpartners. Daarvoor is, naast de hierboven beschreven standaardisatie van gegevens, ook van belang dat er een infrastructuur is die de uitwisseling ook daadwerkelijk faciliteert. 4.4.1. Technisch en Logistiek Voor de technische en logistieke elementen van zo’n infrastructuur wordt kortheidshalve 9 verwezen naar generieke landelijke voorzieningen (e-overheidsbouwstenen) die daarvoor bedoeld zijn: Diginetwerk voor de fysieke infrastructuur en Digikoppeling - voorheen Overheidsservicebus genaamd - voor de logistiek van het berichtenverkeer. Deze voorzieningen zorgen ervoor dat enveloppen gepost, getransporteerd en afgeleverd kunnen worden. 4.4.2. Gestructureerde gegevens Het feitelijke bericht, de inhoud - payload - van de envelop, is vanzelfsprekend wel specifiek voor het domein van de RUD en zijn opdrachtgevers en ketenpartners. Een keuze voor de referentiemodellen RSGB en RGBZ brengt ook een al ontwikkelde standaard voor het uitwisselen van de gegevens uit deze modellen onder handbereik: het Standaard

9

Een punt van aandacht - en zorg - is wel dat alle betrokken partijen, incl. de relevante systemen, aangesloten moeten zijn op deze infrastructuur. Dat is op dit moment nog geenszins het geval.


19

UitwisselingsFormaat (StUF). Deze standaard is geschikt voor gebruik ‘op’ de hierboven genoemde infrastructuur. Zowel RSGB als RGBZ kennen een XML-doorvertaling naar StUF in de vorm van de horizontale sectormodellen StUF-BG respectievelijk StUF-ZKN. Dit betekent dat gegevens die zijn gemodelleerd conform RSGB en RGBZ, elektronisch kunnen worden uitgewisseld met behulp van de berichten die zijn gedefinieerd in de corresponderende StUF-sectormodellen. Aanbeveling 13. hanteer StUF 3.01 en de sectormodellen StUF-BG 3.10 en StUF-ZKN 3.10 voor 10 gegevensuitwisseling . Aanbeveling 14. breid de StUF sectormodellen uit, afhankelijk van of en hoe de aanbeveling om RSGB en RITHm met elkaar te verbinden wordt vormgegeven. Het is immers van belang om - naast basisgegevens o.b.v. RSGB - ook de entiteiten uit RITHm elektronisch te kunnen uitwisselen. 4.4.3. Ongestructureerde gegevens Voor het uitwisselen van ongestructureerde gegevens zijn twee aspecten van belang:  

Het bestandsformaat van de uit te wisselen bestanden. Het protocol waarmee de bestanden worden uitgewisseld.

Bestandsformaten blijven een heikel punt, ondanks alle initiatieven - door o.a. NOiV en het Forum en College Standaardisatie - die in de afgelopen jaren zijn ondernomen om op dit aspect de interoperabiliteit te bevorderen. Het voert te ver om in dit document alle voor- en nadelen van het wel of niet accepteren, c.q. gebruiken van specifieke bestandsformaten te bediscussiëren. Daarom is gekozen voor de volgende - pragmatische - aanbevelingen: Aanbeveling 15. bestanden die door de RUD of ketenpartners digitaal worden gecreëerd, worden uitgewisseld in een bestandsformaat dat voorkomt op de ‘Pas toe of leg uit’-lijst van het College Standaardisatie of - indien deze lijst niet voorziet in een toepasselijk bestandsformaat - in een bestandsformaat dat voorkomt op de lijst ‘Gangbare Open 11 Standaarden’ . Aanbeveling 16. bestanden die niet door de RUD of ketenpartners digitaal zijn gecreëerd, worden zowel in hun oorspronkelijke bestandsformaat als in een gestandaardiseerd (‘Pas toe 12 of leg uit’, resp. ‘Gangbare Open Standaarden’) bestandsformaat uitgewisseld . Waar het gaat om het - protocol voor het - uitwisselen van bestanden, wordt geconstateerd dat StUF niet voorziet in een mechanisme om naast gestructureerde gegevens ook

10

Deze versienummers zullen naar alle waarschijnlijkheid wijzigen als andere aanbevelingen worden overgenomen, omdat aanpassingen in de referentiemodellen ook zullen moeten leiden tot aanpassingen in de bijbehorende StUFsectormodellen. De versienummers zijn m.n. opgenomen om het vertrekpunt te markeren. 11 Deze aanbeveling vloeit voort uit het beleid dat is beschreven in het actieplan ‘Nederland Open in Verbinding’. 12 Deze aanbeveling betreft dus met name bestanden die niet digitaal binnen de ketenorganisatie worden gecreëerd. Denk bijvoorbeeld aan bestanden die door het bedrijfsleven aan de RUD of een ketenpartner worden verstrekt. De ratio achter deze aanbeveling is tweeledig. In de eerste plaats zal niet in alle gevallen regelgeving bestaan waarmee aanlevering in een bepaald bestandsformaat kan worden afgedwongen. En in de tweede plaats is de lijst met ‘open’ en/of ‘duurzame’ bestandsformaten (nog) onvoldoende - functioneel en technisch - dekkend voor alle toepassingsgebieden. Voor bijvoorbeeld het verifiëren van een sterkteberekening is het duurzame bestandsformaat ‘PDF/A’ buitengewoon onhandig en kan het Open Document Formaat niet bij bedrijven worden afgedwongen. Een soortgelijke situatie doet zich voor bij digitale bouw- of constructietekeningen; deze zijn weliswaar te converteren naar PDF/A, maar daarmee gaat veel functionaliteit - denk aan lagen, kleurgebruik, schaalbaarheid, maatvoering, etc. - van het oorspronkelijke bestandsformaat verloren. Het streven naar interoperabiliteit komt zo op gespannen voet te staan met de praktische bruikbaarheid van bepaalde bestandsformaten in processen. Deze aanbeveling tracht daarin een middenweg te formuleren, waarbij het wel zaak is synchroniciteit tussen en authenticiteit van de bestanden scherp in het oog te houden.


20

ongestructureerde gegevens (documenten) uit te wisselen. Dit is, gelet op de aanbevelingen die in dit document worden gedaan, een cruciale functionaliteit die moet worden ingevuld. Aanbeveling 17. breid het sectormodel StUF-ZKN zodanig uit dat ook documenten / dossiers kunnen worden uitgewisseld. Bovenstaande lacune van StUF is ook binnen de StUF-gemeenschap onderkend. Recent heeft een gemeente het initiatief genomen om deze lacune in te vullen in samenwerking met de gemeenschap (KING, gemeenten, leveranciers).


21

5

Bedrijfsfunctie- en procesmodellen

Kijkend naar de verschillende bedrijfsfunctie- en procesmodellen zijn deze op het eerste gezicht behoorlijk verschillend. Toch delen zij op hoog niveau min of meer dezelfde functies/processen. De geïdentificeerde primaire processen van de RUD zijn: 1. 2. 3. 4.

Vergunningverlening Toezicht en Handhaving Bezwaar en Beroep Behandeling Klachten en Meldingen

In de verkenning die voorafging aan het opstellen van dit informatiemodel, is het volgende procesmodel voor de RUD geschetst:

Figuur 2 - Procesmodel RUD

Deze processen zijn volledig terug te zien in de GEMMA-Procesarchitectuur en nagenoeg volledig (Klachten en Meldingen ontbreken) in PETRA. Het Bedrijfsfunctiemodel van inspecties is op een wat hoger abstractieniveau gemodelleerd, maar ook daarop kunnen de RUD-processen goed worden afgebeeld.

5.1.

Zaakgericht werken: een andere manier van kijken naar processen

5.1.1. De Zaak: een container met daarin alle relevante informatie Zaakgericht Werken (ZgW) en het daarvoor ontwikkelde instrumentarium (zoals RGBZ en de ZTC(+), maar ook de applicaties die de markt op basis van deze standaarden heeft ontwikkeld) zijn cruciaal voor een efficiënt en effectief functioneren van RUD-en in hun complexe omgeving.


22

13

Een Zaak is : een samenhangende hoeveelheid werk met een gedefinieerde aanleiding en een gedefinieerd resultaat, waarvan de kwaliteit en doorlooptijd bewaakt moet worden. Een proces dus, met een duidelijk begin en eind. RGBZ is zo gemodelleerd dat nagenoeg alle voor een zaak relevante informatie een plek heeft in het model:   



De voortgang van de ZAAK wordt geregistreerd aan de hand van STATUSsen. Basis- en kerngegevens (uit RSGB en RITHm) worden aan de ZAAK ‘gebonden’ via ROLlen (subjecten) en ZAAKOBJECTen (objecten). De documenten die tijdens de procesgang - eventueel gebonden aan het bereiken van een bepaalde STATUS - ontstaan, worden via ZAAKDOCUMENT aan de ZAAK gekoppeld. De uitkomst van de ZAAK wordt - indien van toepassing - vastgelegd in het BESLUIT.

Opmerkelijk is dat in RGBZ wel BESLUIT is gemodelleerd als entiteit, maar dat het ‘gedefinieerde resultaat’ uit de definitie van ‘Zaak’ geen entiteit is. In plaats daarvan is ervoor gekozen de attributen ‘Resultaatomschrijving’ en ‘Resultaattoelichting’ te modelleren bij de entiteit ZAAK. Dit is in de praktijk lastig werkbaar: zo leiden niet alle zaken tot een besluit maar wel altijd tot een resultaat - en kunnen zowel het resultaat van een zaak als een eventueel besluit bepalend zijn voor het archiefregime dat van toepassing is op de zaak. Om een onlosmakelijke verbinding te kunnen maken tussen de mogelijke resultaten van een zaaktype en het van toepassing zijnde archiefregime, is een typedeclaratie van resultaten (RESULTAATTYPE) gewenst en dient RESULTAAT als entiteit in RGBZ te worden gemodelleerd. Dit ligt overigens ook in de rede; in de GEMMA ZTC wordt al gebruik gemaakt van resultaattypen. Aanbeveling 18. neem RESULTAATTYPE en RESULTAAT op als entiteiten in RGBZ. Het generieke karakter van RGBZ maakt het erg krachtig. Elke procesgang kan aan de hand van dit model worden geregistreerd, gerelateerd aan relevante (basis)gegevens, gedocumenteerd en bewaakt. De Zaak is de - via RGBZ goed gestandaardiseerde informatiecontainer voor àlle voor een procesgang relevante gegevens.

5.1.2. Virtuele dossiers: de satéprikker door alle Zaken De waarde van ZgW wordt vaak geassocieerd met betere dienstverlening (de aanvrager die de status van het behandelproces eenvoudig kan volgen). En hoewel dit één van de pluspunten is, is de waarde van het relateren van de juiste basis- en kerngegevens aan zaken minstens zo groot. Door dit heel consequent te doen, kunnen eenvoudig ‘virtuele dossiers’ van alle zaken die ooit hebben gespeeld met betrekking tot een subject, object of eigenschap worden samengesteld. Bevraag de totale verzameling zaken met de sleutel van een subject (bijv. BSN) of object (bijv. VerblijfsobjectID) en alle aan het subject of object gerelateerde zaken zullen aan de satéprikker worden gestoken.

13

Er valt helaas niet te ontkomen aan een enigszins ambigu gebruik van het begrip ‘Zaak’ in dit document. ‘Zaak’ is in RGBZ zowel als begrip gedefinieerd (vrij vertaald: een proces), als als entiteit (informatieobject) gemodelleerd. In dit document worden ‘zaak’ en ‘zaakdossier’ daardoor gebruikt als conceptueel begrip voor de informatiecontainer waarin alle voor een proces relevante informatie wordt opgeslagen en uitgewisseld. Omdat het introduceren van allerlei nieuwe begrippen/definities de afstand tussen dit document en RGBZ vergroot en de leesbaarheid niet bevordert, is ervoor gekozen deze ambiguïteit voor lief te nemen; de context waarin ‘zaak’ en ‘zaakdossier’ worden gebruikt zal doorgaans voldoende duidelijk maken waarop wordt gedoeld.


23

5.1.3. De Zaak, Subzaken en Vervolgzaken: de basis voor samenwerking in de keten De RUD opereert in een complexe omgeving, met opdrachtgevers en andere ketenpartners waarmee wordt samengewerkt. De wijze waarop deze samenwerking wordt ingevuld, kan tussen RUD-en verschillen. Sterker nog, bij het opstellen van dit document moest er vanuit worden gegaan dat (a) processen over RUD-en heen niet zijn gestandaardiseerd en (b) dat de knips in processen flexibel moeten kunnen worden aangebracht. Het is zelfs denkbaar dat één RUD t.a.v. hetzelfde proces te maken krijgt met verschillende knips (knips afhankelijk van de opdrachtgever). Daarnaast spelen nog de verschillen die voortvloeien uit het Mandaatresp. Adviesmodel. Met zoveel mogelijke variaties in processen, knips en verantwoordelijkheden, lijkt standaardisatie van in de keten uit te wisselen informatie nagenoeg onmogelijk. De sleutel voor de oplossing van dit probleem ligt in het gebruik van Subzaken Vervolgzaken.

14

en

Een Subzaak is een zaak die zich uitsluitend onderscheidt van een (hoofd)Zaak door het hebben van een ‘ouder’ (parent). In elk ander opzicht is een Subzaak modelmatig identiek aan een (hoofd)Zaak en kan dus ‘beschikken’ over alle entiteiten, attributen en - indien geïmplementeerd in een zaaksysteem - gedragingen van een ‘gewone’ Zaak. Vanuit de hoofdzaak wordt een subzaak gestart die wordt toegewezen aan de behandeldienst, in dit geval de RUD. De subzaak neemt alle voor de behandeling van de subzaak relevante informatie over uit de hoofdzaak, waarmee effectief een compleet dossier wordt overgedragen aan de behandeldienst. Tijdens de behandeling van de zaak door de behandeldienst, wordt de status van de subzaak bij het Bevoegd Gezag voortdurend bijgewerkt. Hierdoor heeft het Bevoegd Gezag zicht op de voortgang en kan deze desgevraagd ook rapporteren aan de klant en andere betrokkenen. Een Vervolgzaak is - de naam zegt het al - een nieuwe zaak die wordt gestart na afloop van een zaak. Denk bijvoorbeeld aan een inspectie na het verlenen van een vergunning, of het instellen van bestuurlijke of strafrechtelijke handhaving na een inspectie. De (sub)zaak is een middels RGBZ goed gestandaardiseerde informatiecontainer die middels StUF-ZKN kan worden uitgewisseld tussen informatiesystemen. Tegelijkertijd is ‘de zaak’ een heel flexibele container: de inhoud kan en mag per zaak(type) sterk verschillen. Dit maakt ‘de zaak’ zeer geschikt als ‘eenheid van uitwisseling’ tussen de RUD en haar ketenpartners (opdrachtgevers inbegrepen). Dit geldt voor alle typen processen. De oplossing voor de hierboven geschetste problematiek verwordt daarmee tot het op de juiste c.q. gewenste plaats zetten van de ‘schotten’ (knips) tussen Zaken, Subzaken en Vervolgzaken. Om deze ietwat abstracte schets van het verdelen van werk - en overdragen van alle daarvoor benodigde gegevens - te concretiseren, wordt in de volgende paragrafen, aan de hand van 15 een aantal modelprocessen op hoofdlijnen, uitgewerkt hoe dit er in de praktijk kan uitzien.

5.2.

Vergunningverlening

Voor het voorbeeld is uitgegaan van het hoogste niveau van het GEMMA-procesmodel Vergunning aanvragen.

14

Binnen GEMMA wordt zowel gesproken over ‘Subzaak’ als ‘Deelzaak’; deze begrippen zijn uitwisselbaar. Let wel: de gebruikte processen zijn niet ontworpen in het kader van dit informatiemodel, maar overgenomen uit architectuurmodellen of andere bronnen. Ze zijn veelal vereenvoudigd en louter illustratief voor een mogelijke vormgeving van de samenwerking tussen de RUD en ketenpartners. 15


24

Figuur 3 - Procesmodel Vergunning aanvragen op hoofdlijnen

De RUD kan als uitvoeringsorganisatie voor vergunningverlening op twee manieren worden betrokken in dit proces: gemandateerd namens het bevoegd gezag of als adviseur van het bevoegd gezag. Dit leidt tot andere ‘knips’ in het proces. De ‘knips’ in het proces zijn in onderstaande voorbeelden enigszins arbitrair gekozen. Het doel van de voorbeelden is namelijk niet om voor te schrijven hoe Opdrachtgevers en RUD-en hun processen moeten opknippen, maar aan de hand van een voorbeeld te bewijzen dat het geen verschil maakt waar de ‘knips’ worden aangebracht zolang partijen (ketenpartners) zich conformeren aan Zaakgericht Werken en de daarvoor relevante standaarden. Het procesmodel waarin de RUD acteert als Adviseur van het Bevoegd Gezag, zou er als volgt uit kunnen zien:

Figuur 4 - Vergunningverlening met RUD als Adviseur van Bevoegd Gezag


25

Indien de RUD gemandateerd is door het Bevoegd gezag, kan het procesmodel er als volgt uitzien:

Figuur 5 - Vergunningverlening met RUD gemandateerd door Bevoegd Gezag

5.3.

Toezicht en Handhaving

Voor dit voorbeeld is het generieke procesmodel Handhaving uit het Adviesrapport Handhaving & GEMMA als richtsnoer genomen:

Figuur 6 - Procesmodel Toezicht en Handhaving op hoofdlijnen

In het adviesrapport wordt onderscheid gemaakt tussen Signaalgestuurde Toezicht en Handhaving en Proactieve Toezicht en Handhaving. Het verschil tussen deze twee vormen van Toezicht en Handhaving zit met name in de aanleiding (trigger) voor het starten van een Toezicht en Handhavingsproces: 



Signaalgestuurde Toezicht en Handhavingsprocessen worden gestart door een signaal, bijvoorbeeld een melding of een klacht. Kenmerkend is het ad-hoc starten van deze processen. Proactieve Toezicht en Handhavingsprocessen ontstaan vanuit beleidsmatige of politieke prioriteiten. Kenmerkend is het programmatisch (gepland) karakter van deze processen.

Buiten dit verschil in aanleiding, verlopen beide soorten processen langs dezelfde lijnen. Omdat het verschil tussen het Adviesmodel en Mandaatmodel voor Toezicht en Handhavingsprocessen marginaal is, wordt hieronder volstaan met een uitwerking van het


26

Toezicht en Handhavingsproces waarin met name de informatieoverdracht in geval van handhaving / sanctionering is uitgewerkt:

Figuur 7 - Procesmodel Toezicht en Handhaving i.g.v. handhaving / sanctionering

In bovenstaand procesmodel wordt een drietal ‘routes’ geschetst voor het geval een Toezicht en Handhavingszaak leidt tot vervolgstappen: 





5.4.

Aanschrijven: er zijn discrepanties geconstateerd tussen de weten regelgeving en de situatie ter plaatse. Het subject wordt middels een Aanschrijving in de gelegenheid gesteld e.e.a. te herstellen, waarna een Herinspectie (Vervolgzaak) plaatsvindt. Bestuurlijke handhaving: de aard van de discrepantie tussen weten regelgeving en de situatie ter plaatse is zodanig dat Bestuurlijke handhaving noodzakelijk is. De RUD bereid in zo’n geval - afhankelijk van het mandaat - een conceptbesluit voor of stuurt - gemandateerd namens het Bevoegd Gezag - een besluit naar het subject. In geval van een conceptbesluit, draagt de RUD het volledige dossier incl. conceptbesluit over aan het Bevoegd Gezag en start het Bevoegd Gezag een Vervolgzaak. Strafrechtelijke handhaving: de aard van de discrepantie tussen weten regelgeving en de situatie ter plaatse is zodanig dat Strafrechtelijke handhaving noodzakelijk is. De RUD stelt een Proces Verbaal op en draagt het volledige zaakdossier, incl. Proces Verbaal, over aan Justitie / Openbaar Ministerie. Daar wordt een Vervolgzaak gestart.

Bezwaar en Beroep

De basis voor dit procesvoorbeeld ligt in het Generiek Procesmodel Bezwaren en Beroepen uit de GEMMA procesarchitectuur. Het proces op hoofdlijnen volgt dezelfde indeling als die voor Vergunningverlening:

Figuur 8 - Procesmodel Bezwaar en Beroep


27

En daarmee volgt het procesmodel in de uitwerking naar het Adviesmodel resp. Mandaatmodel ook dezelfde indeling:

Figuur 9 - Bezwaar en Beroep met RUD als Adviseur van Bevoegd Gezag

Figuur 10 - Bezwaar en Beroep met RUD gemandateerd door Bevoegd Gezag


28

5.5.

Klachten en Meldingen

Ook voor dit procesmodel ligt de basis in de GEMMA procesarchitectuur. Het Generiek Procesmodel Meldingen schetst het volgende proces op hoofdlijnen:

Figuur 11 - Procesmodel Meldingen en Klachten op hoofdlijnen

Uit het proces op hoofdlijnen valt al op te maken dat dit een zeer eenvoudig proces is. Er zal in de praktijk dan ook niet snel sprake zijn van een onderscheid tussen een Advies- en Mandaatmodel. Een Melding of Klacht zal wel vaak leiden tot Vervolgzaken, bijvoorbeeld in de sfeer van Toezicht en Handhaving. In veel gevallen wordt - nu al - het ‘loket’ voor het doorgeven van Meldingen of Klachten rechtsreeks bij de RUD ondergebracht. In dat geval verloopt het volledige proces binnen de RUD. Indien een Melding of Klacht via het Bevoegd Gezag wordt ingediend, ziet het procesmodel er als volgt uit:

Figuur 12 - Procesmodel Meldingen en Klachten ingediend bij Bevoegd Gezag


29

6

Bouwstenen en hun stand van zaken

Voor zowel basis- en kerngegevens en procesgegevens is al het nodige denk- en ontwikkelwerk gedaan. Eén van de belangrijkste uitgangspunten bij het opstellen van RUDI is dat wielen niet opnieuw worden uitgevonden. De volgende architectuurmodellen en standaarden zijn relevant voor RUDI.

6.1.


6.1.1. Het Stelsel van Basisregistraties Het stelsel van basisregistraties bevat de gegevens die overheden verplicht - dat wil zeggen zonder onderzoek - gebruiken voor de uitvoering van hun taken. Het stelsel in zijn huidige vorm bestaat uit 13 basisregistraties. Nog niet alle basisregistraties zijn volledig operationeel. 16 In onderstaande figuur is de stand van zaken opgenomen zoals die gold op 1 mei 2010 .

Figuur 13 - Stand van zaken en planning basisregistraties

Een basisregistratie staat niet op zichzelf. Personen (GBA/BRP, NHR) verblijven in verblijfsobjecten (BAG) die een adres hebben (BAG). Bedrijven (NHR) worden bovendien ‘gerund’ door natuurlijke (GBA/BRP) of niet-natuurlijke personen (NHR). Etcetera. Basisregistraties kennen dus onderlinge relaties / afhankelijkheden die van grote betekenis zijn voor de consistentie van de gegevens binnen het stelsel. Deze relaties zorgen ervoor dat als bijvoorbeeld een pand wordt gesloopt (BAG) er ook administratief geen personen (GBA/BRP, NHR) achterblijven in / op de - dan niet meer bestaande - verblijfsobjecten / adressen. Of dat ten minste wordt gesignaleerd dat de administratieve werkelijkheid in de ene basisregistratie niet strookt met de administratieve werkelijkheid in de andere. Het leggen van deze relaties is nog niet voor alle basisregistraties gebeurd. In onderstaande figuur zijn deze afhankelijkheden afgebeeld en voorzien van datum waarop de relatie tussen twee basisregistraties operationeel moet zijn.

16

Op 9 maart 2011 is de pagina (https://wiki.noiv.nl/xwiki/bin/view/Stelselhandboek/Planning+en+voortgang) waarin de planning en voortgang van de basisregistraties kan worden gevolgd, door de beheerder op ‘In ontwikkeling’ gezet. Zodra deze is geactualiseerd, zal een bijgewerkt overzicht in dit document worden opgenomen.


30

Figuur 14 - Stand van zaken en planning verbindingen tussen basisregistraties

Het behoeft nauwelijks uitleg dat de realisatie van deze verbindingen van groot belang zijn voor de gegevenskwaliteit binnen individuele basisregistraties en het stelsel als geheel.

6.1.2. Referentiemodel voor het Stelsel van Gemeentelijke Basisgegevens (RSGB 2.01, GEMMA) Het Referentiemodel voor Gemeentelijke Basisgegevens (RSGB) is onderdeel van GEMMA en heeft het stelsel van basisregistraties als basis. De redenen voor de ontwikkeling van het referentiemodel waren meerledig: 1.

2.

3.

Het stelsel van basisregistraties dekt niet de volledige populatie van Subjecten en Objecten waarmee gemeenten - en overheden in het algemeen - te maken hebben. Met het RSGB hebben gemeenten onder leiding van EGEM/KING een uitbreiding op het stelsel van basisregistraties gemaakt die wél populatiedekkend is. Het stelsel van basisregistraties voorzag (en voorziet, zie ook hierboven) niet in alle relaties tussen basisregistraties / -gegevens die voor adequaat gegevensbeheer noodzakelijk zijn. Gemeenten zijn bronhouder van GBA/RNI, BAG, WOZ en - deels - GBKN/BGT. Het RSGB is vooral ontwikkeld vanuit de filosofie dat als registratie aan de bron goed geregeld is, het landelijk stelsel hiervan profiteert, ook als op landelijk niveau nog niet alle aspecten zijn ingevuld (zoals de onderlinge relaties).


31

Momenteel zijn in het RSGB de volgende basisregistraties gemodelleerd:      

Basisregistratie Adressen en Gebouwen (BAG), Basisregistratie Personen (GBA en RNI), Basisregistratie Ondernemingen en Rechtspersonen (NHR), Basisregistratie Kadaster (BRK), Basisregistratie Waarde Onroerende Zaken (BRWOZ) Basisregistratie Grootschalige Topografie (GBKN, in de toekomst BGT) c.q. het Informatiemodel Geo (IMGeo)

Dit ziet er op hoofdlijnen als volgt uit:

Figuur 15 - Stelsel van Gemeentelijke Basisgegevens op hoofdlijnen (RSGB)

Het RSGB incorporeert alle definities en afspraken die op landelijk niveau zijn gemaakt ten aanzien van genoemde basisregistraties en vult deze aan. Het is dus te allen tijde mogelijk om gegevens vanuit het RSGB naar het landelijk stelsel te ‘vertalen’ en vice versa. RSGB kan derhalve worden beschouwd als het ‘Stelsel van Basisregistraties-Plus’.

6.1.3. Referentie Informatiemodel Toezicht en Handhaving (RITHm) Dit model is nog in ontwikkeling maar is gestoeld op dezelfde uitgangspunten als het RSGB: neem het stelsel van basisregistraties als basis en breid dit uit met entiteiten die van belang 17 zijn voor adequate ondersteuning van toezicht en handhavingsprocessen .

17

Inmiddels is voor de ontwikkeling van RITHm al aansluiting gezocht bij het RSGB, zij het enigszins ambivalent: waar het RSGB het landelijke stelsel van basisgegevens - voor zover die basisgegevens die worden gemodelleerd in RSGB volledig incorporeert en daarop voortbouwt, is het vertrekpunt van RITHm opnieuw het landelijk stelsel, terwijl dat al ‘meekomt’ met RSGB. Door deze benadering dreigen slechts de aanvullingen op entiteitniveau die in RSGB zijn gemodelleerd te worden meegenomen in RITHM, maar blijven de relationele aanvullingen en wijzigingen en attribuutuitbreidingen buiten beeld.


32

Het model op hoofdlijnen ziet er als volgt uit, in bijlage 7.3 is het volledige model opgenomen:

Figuur 16 - Referentiemodel Stelsel van Basisgegevens voor Toezicht en Handhaving (RITHm)

Het model van de werkgroep RITHm gaat uit van het landelijk stelsel van basisregistraties. Zoals hierboven aanbevolen (Aanbeveling 4), levert het grote meerwaarde op als niet het landelijk stelsel, maar RSGB de basis vormt waarop RITHm voortbouwt. Het RSGB voegt juist


33

die subjecten en objecten toe die voor toezicht en handhaving zeer relevant kunnen zijn, maar niet - standaard - in de basisregistraties zijn gedefinieerd opgenomen. Denk aan entiteiten als OVERIG GEBOUWD OBJECT en OVERIG TERREIN (Adressen en Gebouwen), ANDER NATUURLIJK PERSOON en ANDER BUITENLANDS NIET-NATUURLIJK PERSOON (Rechtspersonen).


34

6.2.

Procesmodellen en -gegevens

6.2.1. Bedrijfsfunctiemodel Provincies In PETRA hebben de provincies hun bedrijfsfunctiemodel uitgewerkt.

Figuur 17 - Bedrijfsfunctiemodel Provincies


35

6.2.2. Bedrijfsfunctiemodel Inspecties Dit model is aanvankelijk ontwikkeld door dNVWA maar blijkt ook voor andere inspecties goed toepasbaar, in elk geval op het hoogste niveau.

Figuur 18 - Bedrijfsfunctiemodel van de Nieuwe Voedsel- en Warenautoriteit

Dit bedrijfsfunctiemodel is de ‘kapstok’ waaronder de processen van dNVWA - en andere inspecties die dit bedrijfsfunctiemodel ook gebruiken - in meer detail zijn / worden uitgewerkt.

6.2.3. GEMMA-Procesarchitectuur (1.0, GEMMA) De GEMMA-Procesarchitectuur beschrijft de hiërarchie van processen van gemeenten, en werkt met name de dienstverleningsprocessen (d.w.z. processen die gestart worden met een klantaanvraag of -verzoek en die resulteren in een product, dienst of informatieverstrekking aan de klant) in meer detail uit. Hoewel GEMMA niet spreekt van een bedrijfsfunctiemodel, zijn de overeenkomsten tussen het Hiërarchische Procesmodel in GEMMA en de bedrijfsfunctiemodellen van Provincies en dNVWA / Inspecties groot. De hiërarchie en scope - in geel - van de GEMMA-Procesarchitectuur is uitgewerkt in onderstaand schema.


36

Figuur 19 - Hiërarchisch procesmodel & scope GEMMA Procesarchitectuur

De in het schema genoemde processen zijn/worden door EGEM/KING uitgewerkt in GEMMAe-processen. De status daarvan is: 1. 2. 3. 4. 5. 6. 7. 8.

Generiek proces Vergunning Aanvragen, versie 1.0 d.d. 2-3-2010 Generiek proces Subsidie Aanvragen, versie 1.0 d.d. 2-3-2010 Generiek procesmodel Inkomens- en Maatschappelijke Ondersteuning Aanvragen, versie 1.0 d.d. 5-11-2009 Generiek procesmodel Meldingen, versie 1.0 d.d. 10-3-2010 Generiek procesmodel Bezwaren en Beroepen, concept, versie 0.6 d.d. 17-11-2009, planning Q4 2010 Generiek procesmodel Publieke Producten, concept, versie 0.7 d.d. 29-3-2010, planning Q4 2010 Klachten, planning Q4 2010 Generiek procesmodel Aangiften en Verzoeken, concept, versie 0.1 d.d. 30-3-2010, planning Q4 2010

6.2.4. Referentiemodel Gemeentelijke Basisgegevens Zaken (RGBZ 1.0, GEMMA) Het Referentiemodel Gemeentelijke Basisgegevens (RGBZ) is onderdeel van GEMMA en modelleert de gegevens die (kunnen) worden bijhouden over - de behandeling van - Zaken. Op basis van dit model kunnen belanghebbenden (betrokkenen, geïnteresseerden, medewerkers, management) worden geïnformeerd over lopende en afgeronde zaken. Met de gegevens in het model kan ook (achteraf) een zaak worden verantwoord, zowel inhoudelijk als qua proces. Zo kan de volledige - behandeling van de - zaak worden gereconstrueerd.


37

Figuur 20 - Referentiemodel Gemeentelijke Basisgegevens Zaken (RGBZ)

Waar het RSGB vooral betrekking heeft op relatief statische basisgegevens (‘koud’), modelleert het RGBZ de gegevens die van belang zijn voor de uitvoering van processen (‘warm’) en relateert deze - via ZAAKOBJECT en ROL - aan o.a. basisgegevens (RSGB).

6.2.5. Zaaktypecatalogus (ZTC 1.0, GEMMA) Op basis van RGBZ kunnen ‘zaaktypen’ worden gemodelleerd. Een zaaktype in RGBZ definieert een proces en aan dat proces verbonden domeinwaarden voor entiteiten, zoals de statussen die kunnen voorkomen in een zaak van het betreffende type, de verantwoordelijke organisatorische eenheid/eenheden, etc. De huidige (1.0) versie van de Zaaktypecatalogus bevat een groot aantal (317) gemeentelijke zaaktypen en daaraan gerelateerde parameters: A. Code: de code / het nummer van het zaaktype B. Handeling Initiator (klant): Werkwoord dat hoort bij de handeling die de initiator verricht bij dit zaaktype. Meestal aanvragen, indienen of melden. Soms ook inhuren, afmelden. C. Onderwerp: Te leveren product of dienst door de gemeente / behandelende organisatie. (Dit gaat niet in 100% van de gevallen op, zoals bij (afmelden) hond voor hondenbelasting.)


38

D. Werkwoord dat hoort bij de handeling die de behandelaar verricht bij dit zaaktype. Meestal behandelen, uitvoeren, vaststellen of onderhouden. E. Cat.: Geeft aan tot welke categorie het zaaktype behoort. Zaaktypen met een externe trigger (TE) worden door een partij (bijv. burger of bedrijf) buiten de behandelende organisatie geïnitieerd. Zaaktypen met een interne trigger (TI) worden geïnitieerd vanuit de eigen organisatie (bijv. een interne adviesaanvraag of aanvraag verlof). F. GEMMA Procesarchitectuur: Refereert aan het laagste niveau van de proceshiërarchie uit het GEMMA procesmodel. G. GEMMA eFormulier: Refereert aan de naam van het bijbehorende GEMMA eformulier. H. IV3 categorie: legt de relatie met de (financiële) verantwoording op basis van de IV3 (Informatievoorziening voor Derden) categorieën. I. Generiek: aanduiding van het soort product (Vergunning, Subsidie, Ontheffing, Advies, etc.) dat wordt gevraagd. J. Categorie Selectielijst 2005 I: Verwijzing naar de betreffende categorie uit de Selectielijst 2005 voor bewaren en vernietigen van archiefbescheiden. Tweede kolom (K, Categorie Selectielijst 2005 II) is gevuld bij meerdere categorieën (b.v. “2.7 Verlening van vergunningen, machtigingen”). K. Zie J. hierboven. L. Resultaattype: Verleend (v), Toegekend (t), Afgewezen (a), Verwerkt (vw), Gegrond (g), Ongegrond (o), Geweigerd (gw), niet nodig (n), ontvankelijk (ov), niet ontvankelijk (no), niet vastgesteld (nv) en vaststellen (vs). M. Zie L. hierboven. N. Zie L. hierboven. O. Besluittype: is uitsluitend gevuld indien de Datum Vernietigen afhangt van een besluit. De codering is gelijk aan Resultaattype (zie L.). P. Zie O. hierboven. Q. Zie O. hierboven. R. Bewaartermijn in jaren per gevuld Resultaattype (d.w.z. na vervallen bewaartermijn). S. Zie R. hierboven. T. Zie R. hierboven. U. Categorie brondatum voor de vernietigingstermijn na resultaat (zie L.) of gebeurtenis: vervallen (vv), onherroepelijk (oh), afhandeling (af), verwerking (vw), geweigerd (weigering) (gw), verleend (v), geboorte (gb), einde dienstverband, pensioen of overlijden (ed). V. Zie U. hierboven. W. Zie U. hierboven. X. Toelichting. Y. Bezwaar / beroep: geeft aan of het mogelijk is bezwaar aan te tekenen / in beroep te gaan tegen het genomen besluit van dit zaaktype en op welke wettelijke basis dit mogelijk is. Merk op dat de inhoud van de ZTC in haar huidige vorm met name zaaktypen bevat die leiden tot een bepaalde vorm van dienstverlening (zie ook de scope van de GEMMAProcesarchitectuur in 6.2.1); toezicht en handhavingszaaktypen ontbreken vooralsnog. De structuur van de ZTC leent zich echter prima om ook dit soort zaaktypen aan de ZTC toe te voegen.


39

6.3.


Voor het uitwisselen van gegevens wordt - zoveel als mogelijk - gebruik gemaakt van Open Standaarden, zoals vastgesteld door het Forum Standaardisatie. Voor toepassing in de primaire processen van RUD-en zijn de volgende standaarden van belang.

6.3.1. Bestandsformaten Het Forum Standaardisatie heeft de volgende bestandsformaten vastgesteld als Open Standaard en opgenomen op de ‘Pas toe of leg uit’-lijst:  

 

Open Document Format (ODF, ISO 26300) voor de uitwisseling van reviseerbare documenten tussen overheidsorganisaties Portable Network Graphics Specification (PNG, ISO/IEC 15948:2003) Second Edition voor het gebruik van grafische afbeeldingen (‘lossless’ compressie) binnen ODFdocumenten Joint Photographics Expert Group (JPEG, ISO/IEC IS 10918-1) voor het gebruik van grafische afbeeldingen (‘lossy’ compressie) binnen ODF-documenten Portable Document Format Archivable (PDF/A-1, NEN-ISO 19005-1:2005 EN) voor de lange termijn archivering van niet-reviseerbare documenten

6.3.2. Uitwisseling van gegevens Het Forum Standaardisatie heeft de volgende uitwisselingsstandaarden vastgesteld als Open Standaard en opgenomen op de ‘Pas toe of leg uit’-lijst:  

Standaard UitwisselingsFormaat (StUF) voor de uitwisseling en bevraging van Basisgegevens, Zaakgegevens en Sectorspecifieke gegevens eXtensible Business Reporting Language (XBRL) v2.1, eventueel in combinatie met Dimensions v1.0 voor elektronisch verkeer dat te kenmerken is als verantwoordingsverkeer waarin financiële informatie de kern vormt (en uitsluitend op basis van taxonomieën die als standaard op de ‘Pas toe of leg uit’-lijst voorkomen

Gelet op de scopeafbakening is laatstgenoemde standaard niet van toepassing op dit informatiemodel.


40

De StUF-standaard is een XML-standaard en bestaat uit een aantal bouwstenen:

De StUF protocolbindingen beschrijven op welke wijze StUF-berichten kunnen worden uitgewisseld op basis van verschillende communicatieprotocollen. Er zijn bindingen beschreven voor uitwisseling via: 1. 2. 3.

Een bestand WSDL 1.1 (Web Services Description Language) met SOAP 1.1 en http als onderliggend transportmechanisme Digikoppeling (voorheen OSB), zowel op basis van OSB WUS 1.1 (uitsluitend bevragingen) als OSB ebMS 1.1 (transacties)

In de StUF berichtenstandaard wordt uitvoerig de semantiek en syntax van de functionaliteit van de standaard beschreven. Het gaat daarbij om functionaliteit voor het opvragen van gegevens, het doorgeven van wijzigingen, de identificatie van objecten, het adresseren van berichten, en dergelijke. De StUF Berichtenstandaard definieert niet de inhoud van de berichten zelf. Dit is uitgewerkt in de sectormodellen. De StUF berichtenstandaard wordt beheerd door KING. De zogenaamde ‘horizontale sectormodellen’ StUF-BG en StUF-ZKN zijn strikt genomen geen sectormodellen, maar gespecialiseerde modellen voor de uitwisseling van basisgegevens (BG) respectievelijk Zaken (ZKN); ook over sectorgrenzen heen. Horizontale sectormodellen worden beheerd door KING. Verticale sectormodellen zijn wél sectorspecifieke modellen. Zij definiëren het berichtenverkeer binnen een sector, bijvoorbeeld tussen BAG-applicaties en de Landelijke Voorziening BAG (StUF-LVBAG). Verticale sectormodellen worden ontwikkeld door / onder verantwoordelijkheid van de sectoren zelf (en dus niet beheerd door KING; KING ziet wel toe op de kwaliteit). 18

Er zijn momenteel twee versies van StUF in gebruik :  18

StUF 2.04 in combinatie met sectormodel StUF-BG 2.04

Verticale sectormodellen worden buiten beschouwing gelaten.


41



StUF 3.01 in combinatie met sectormodel StUF-BG 3.10 en StUF-ZKN 3.10

Het voert te ver om in deze context uitputtend de verschillen te beschrijven tussen de versies van de StUF berichtenstandaard en sectormodellen. Op hoofdlijnen komt het neer op: 



StUF 2.04 in combinatie met StUF-BG 2.04 is een breed - in de markt geïmplementeerde XML-standaard voor de uitwisseling van basisgegevens op basis van het GFO-Basisgegevens uit 1998. Zoals uit dit jaartal valt af te leiden, zijn in deze standaard niet de ontwikkelingen meegenomen rondom het stelsel van basisregistraties. De StUF-standaard 2.04 is ondertussen wel doorontwikkeld naar uitwisseling op basis van XML. StUF 3.01 in combinatie met StUF-BG 3.10 en StUF-ZKN 3.10 weerspiegelt de meest actuele stand van zaken. De StUF 3.01 berichtenstandaard is - t.o.v. 2.04 - aangepast aan de Service Oriented Architecture en de sectormodellen StUF-BG 3.10 en StUFZKN 3.10 sluiten aan bij respectievelijk RSGB en RGBZ.

Een groot deel van de markt heeft aangegeven op korte termijn de StUF 3.xx-standaard te zullen implementeren. Om die reden is in dit document uitsluitend StUF 3.xx in de beschouwingen betrokken.


42

7

Bijlagen

7.1.

Bijlage A: mapping van gegevens(vragen) op RSGB, RITHm, RGBZ en ZTC

Zie separaat document: 20110411_RUD-Gegevens-en-Informatievragen-v032-Mapping-(versie 1).pdf


43

7.2.

Bijlage B: beantwoording Informatievragen met behulp van het informatiemodel

Onderstaande vragen zijn door de Expertgroep aangereikt voor de empirische toetsing van het informatiemodel.

7.2.1.

Vergunningverlening

7.2.1.1. Voortgang vergunningverlening Definitie: % afgedane besluiten afgezet tegen de jaarplanning, per type product, per regio Omschrijving: Het gaat om het aantal procedures waarover een definitief besluit is genomen. De status van deze producten is altijd afgerond. De planning is een schatting op basis van historische gegevens: het jaarplan levert een schatting van de in het jaar te realiseren afgedane besluiten. De rapportage moet per type product worden uitgesplitst. Dit wordt bepaald door het wettelijk kader. De rapportage moet per regio worden uitgesplitst. Dit wordt bepaald door de regio waarin de inrichting is gelegen. Benodigde gegevens:     

Datum indiening aanvraag Datum ontwerpbesluit Datum besluit Thema en Wettelijk kader van de zaak (dit bepaalt het type product) Organisatorische eenheid die verantwoordelijk is voor de inrichting (op basis van de regio waarin de inrichting is gelegen)

Beantwoording van de informatievragen m.b.v. het informatiemodel: Rapportage van alle zaken van één of meer zaaktypen (vergunningen). Uitsplitsing per regio kan op basis van de geo-kenmerken van de zaakobjecten.

7.2.1.2. Werkvoorraad vergunningverlening Definitie 1: % lopende procedures afgezet tegen de jaarplanning, per type product, per regio Omschrijving: Het gaat om het aantal procedures die in behandeling zijn. Dit zijn de procedures waarvoor datum indiening is ingevuld en datum besluit nog niet ingevuld. De planning is een schatting op basis van historische gegevens: het jaarplan levert een schatting van de in het jaar te realiseren afgedane besluiten. Definitie 2: aantal nieuwe concept aanvragen, per type product, per regio Omschrijving: Het gaat om het aantal nieuw ontvangen concept aanvragen in de verslagperiode. Dit zijn de procedures in de fase concept. Definitie 3: aantal nieuwe definitieve aanvragen, per type product, per regio Omschrijving: Het gaat om het aantal nieuw ontvangen definitieve aanvragen in de verslagperiode. Het gaat om het aantal procedures die in behandeling zijn. Zie verder onder definitie 1.


44

Definitie 4: aantal lopende procedures, per type product, per regio Omschrijving: Het gaat om het aantal procedures die in behandeling zijn. Zie verder onder definitie 1. De rapportage moet per type product worden uitgesplitst. Dit wordt bepaald door het wettelijk kader. De rapportage moet per regio worden uitgesplitst. Dit wordt bepaald door de regio waarin de inrichting is gelegen. Benodigde gegevens (grove analyse):     

Datum indiening aanvraag Datum ontwerpbesluit (indien van toepassing) Datum besluit Thema en Wettelijk kader van de zaak (dit bepaalt het type product) Organisatorische eenheid die verantwoordelijk is voor de inrichting (op basis van de regio waarin de inrichting is gelegen)

Beantwoording van de informatievragen m.b.v. het informatiemodel: 1. 2.

3. 4.

Alle zaken van één of meer zaaktypen (vergunningen) waarvoor Einddatum = leeg. Indien gedoeld wordt op de situatie waarin vooroverleg plaatsvindt, kan een dergelijke rapportage worden gebaseerd op apart ZAAKTYPE voor vergunningaanvragen met vooroverleg. Uitsplitsing per regio kan op basis van de geo-kenmerken van de zaakobjecten. Idem als 2, maar dan voor vergunningaanvragen zonder vooroverleg. Zie 1.

7.2.1.3. Tijdigheid vergunningverlening Definitie 1: % van de procedures afgewerkt binnen de wettelijke termijn, per type product, per regio Omschrijving: Het gaat om het aantal procedures waarvan de behandeling is afgerond binnen de geldende wettelijke termijn. De start is bepaald zoals beschreven als onder werkvoorraad. Het einde is bepaald als onder voortgang. Definitie 2: % van de procedures afgewerkt tussen 6 en 12 maanden, per type product, per regio Omschrijving: Het gaat om het aantal procedures waarvan de behandeling is afgerond tussen 6 en 12 maanden. De start is bepaald zoals beschreven als onder werkvoorraad. Het einde is bepaald als onder voortgang. Definitie 3: % van de procedures afgewerkt na meer dan 12 maanden, per type product, per regio Omschrijving: Het gaat om het aantal procedures waarvan de behandeling is afgerond na 12 maanden. De start is bepaald zoals beschreven als onder werkvoorraad. Het einde is bepaald als onder voortgang.


45

Definitie 4: gemiddelde doorlooptijd van de afgewerkte procedures, per type product, per regio Omschrijving: Het gaat om de procedures waarvan de behandeling is afgerond. De start is bepaald zoals beschreven als onder werkvoorraad. Het einde is bepaald als onder voortgang. De rapportage moet per type product worden uitgesplitst. Dit wordt bepaald door het wettelijk kader. De rapportage moet per regio worden uitgesplitst. Dit wordt bepaald door de regio waarin de inrichting is gelegen. Benodigde gegevens (grove analyse):     

Datum indiening aanvraag Datum ontwerpbesluit (indien van toepassing) Datum besluit Thema en Wettelijk kader van de zaak (dit bepaalt het type product) Organisatorische eenheid die verantwoordelijk is voor de inrichting (op basis van de regio waarin de inrichting is gelegen)

Beantwoording van de informatievragen m.b.v. het informatiemodel: 1.

2.

3.

4.

Alle zaken van één of meer zaaktypen (vergunningen) waarvoor Einddatum <= Uiterlijke einddatum afdoening. Uitsplitsing per regio kan op basis van de geokenmerken van de zaakobjecten. Alle zaken van één of meer zaaktypen (vergunningen) waarvoor geldt: 6 maanden < (Einddatum – Startdatum) < 12 maanden. Uitsplitsing per regio kan op basis van de geo-kenmerken van de zaakobjecten. Alle zaken van één of meer zaaktypen (vergunningen) waarvoor geldt: (Einddatum – Startdatum) > 12 maanden. Uitsplitsing per regio kan op basis van de geo-kenmerken van de zaakobjecten. Gemiddelde (Einddatum – Startdatum) van alle zaken van één of meer zaaktypen (vergunningen). Uitsplitsing per regio kan op basis van de geo-kenmerken van de zaakobjecten.

7.2.1.4. Doorlooptijd vergunningverlening Definitie 1: Aantal lopende procedures die tussen 8 weken en 13 weken lopen zonder ontwerpbesluit, per type product, per regio Omschrijving: Het gaat om het aantal procedures die in behandeling zijn maar waarvoor nog geen ontwerp besluit is genomen. Dit zijn de procedures in de processtatus vooroverleg, datum indienen aanvraag, opstellen besluit. Een procedure is in behandeling als de aanvraag formeel is ontvangen tenzij er sprake is van wettelijk vooroverleg. In dat laatste geval is een procedure in behandeling als het vooroverleg is gestart. Het gaat dus om de behandelfases tot het moment dat het ontwerp besluit is genomen. Definitie 2: Aantal lopende procedures die tussen 13 weken en 5 maanden lopen zonder ontwerpbesluit, per type product, per regio. Omschrijving: Zie onder definitie 1.


46

Definitie 3: Aantal lopende procedures die tussen 5 maanden en 6 maanden lopen zonder ontwerpbesluit, per type product, per regio. Omschrijving: Zie onder definitie 1. Definitie 4: Aantal lopende procedures die tussen 6 maanden en 12 maanden lopen zonder ontwerpbesluit, per type product, per regio. Omschrijving: Zie onder definitie 1. Definitie 5: Aantal lopende procedures die meer dan 12 maanden lopen zonder ontwerpbesluit, per type product, per regio. Omschrijving: Zie onder definitie 1. De rapportage moet per type product worden uitgesplitst. Dit wordt bepaald door het wettelijk kader. De rapportage moet per regio worden uitgesplitst. Dit wordt bepaald door de regio waarin de inrichting is gelegen. Benodigde gegevens (grove analyse):      

Datum indiening aanvraag Datum ontwerpbesluit (indien van toepassing) Datum besluit Wettelijke termijn van afdoening Thema en Wettelijk kader van de zaak (dit bepaalt het type product) Organisatorische eenheid die verantwoordelijk is voor de inrichting (op basis van de regio waarin de inrichting is gelegen)

Beantwoording van de informatievragen m.b.v. het informatiemodel: 1.

2. 3. 4. 5.

Alle zaken van één of meer zaaktypen (vergunningen) waarvoor geldt: STATUS >= ‘In behandeling’ EN ZAAK bevat geen DOCUMENT van DOCUMENTTYPE ‘Ontwerpbesluit’ EN 8 weken < (NU – Startdatum) <= 13 weken. Uitsplitsing per regio kan op basis van de geo-kenmerken van de zaakobjecten. Idem met 13 weken < (NU – Startdatum) <= 5 maanden Idem met 5 maanden < (NU – Startdatum) <= 6 maanden Idem met 6 maanden < (NU – Startdatum) <= 12 maanden Idem met (NU – Startdatum) > 12 maanden

7.2.1.5. Productiviteit vergunningverlening Definitie: Aantal benodigde uren ten opzichte van de geplande uren voor het realiseren van het product, per type product, per regio, periodiek Omschrijving: Het gaat om het aantal feitelijk gebruikte uren versus de geplande uren. De feitelijke uren komen uit de tijdregistratie. De geplande uren zijn een schatting op basis van historische gegevens: het jaarplan levert een schatting van de in het jaar benodigde uren voor de te realiseren productie. De rapportage moet per type product worden uitgesplitst. Dit wordt bepaald door het wettelijk kader. De rapportage moet een periode kunnen verslaan, daarom is het meest optimaal om de tijdregistratie per dag te voeren. 'Op weg naar een Informatiemodel' v 1.0 Regionale UitvoeringsDiensten Informatiearchitectuur (RUDI)

47

De rapportage moet per regio worden uitgesplitst. Dit wordt bepaald door de regio waarin de inrichting is gelegen. Benodigde gegevens (grove analyse):   

Aantal gebruikte uren voor een wettelijk kader, voor een inrichting, per dag. Aantal geplande uren voor een wettelijk kader, voor een regio. Organisatorische eenheid die verantwoordelijk is voor de inrichting (op basis van de regio waarin de inrichting is gelegen)

Beantwoording van de informatievragen m.b.v. het informatiemodel: Voor het beantwoorden van dit soort vragen zal een koppeling moeten worden gemaakt tussen de zaakfunctionaliteit en het tijdregistratiesysteem. Tijdverantwoording moet bij voorkeur kunnen plaatsvinden op Zaakidentificatie (zodat ook daadwerkelijk gemaakte kosten voor behandeling van een zaak kunnen worden doorbelast).

7.2.2.

Handhaving

7.2.2.1. Controledichtheid Definitie: % uitgevoerde controles ten opzichte van het aantal geplande controles, per type product Omschrijving: Het gaat om het aantal opgeleverde controlerapporten c.q. vastgelegde bevindingen van de daadwerkelijk uitgevoerde controlebezoeken ten opzichte van de geplande controlebezoeken. De rapportage moet per type product worden uitgesplitst. Dit wordt bepaald door het wettelijk kader. De rapportage moet per regio worden uitgesplitst. Dit wordt bepaald door de regio waarin de inrichting is gelegen. Benodigde gegevens (grove analyse):    

Datum uitvoeren controlebezoek Status van het controlebezoek Thema en Wettelijk kader van de inrichting van de controlezaak van het controlebezoek (dit bepaalt het type product) Organisatorische eenheid die verantwoordelijk is voor de inrichting (op basis van de regio waarin de inrichting is gelegen)

Beantwoording van de informatievragen m.b.v. het informatiemodel: Zie beantwoording onder 7.2.1.1., maar dan voor alle zaken van zaaktype controle.

7.2.2.2. Aspectdichtheid Definitie: % uitgevoerde controles ten opzichte van het aantal geplande controles, per type product, per regio Omschrijving: Het gaat om het aantal daadwerkelijk gecontroleerde aspecten ten opzichte van de te controleren aspecten van de geplande controlebezoeken. De rapportage moet per type product worden uitgesplitst. Dit wordt bepaald door het wettelijk kader.


48

De rapportage moet per regio worden uitgesplitst. Dit wordt bepaald door de regio waarin de inrichting is gelegen. Benodigde gegevens (grove analyse):      

Datum uitvoeren van het controlebezoek Status van het controlebezoek Controle beoordelingspunt aspect van het controlebezoek Controle beoordelingspunt status van het controlebezoek Thema en Wettelijk kader van de inrichting van de controlezaak van het controlebezoek (dit bepaalt het type product) Organisatorische eenheid die verantwoordelijk is voor de inrichting (op basis van de regio waarin de inrichting is gelegen)

Beantwoording van de informatievragen m.b.v. het informatiemodel: Zie beantwoording onder 7.2.1.1., maar dan voor alle zaken van zaaktype controle. Door alle aspecten te configureren als ‘Checklist’ met optioneel af te vinken checklistitems, kan rapportage op individuele aspecten plaatsvinden.

7.2.2.3. Toezichtdichtheid Definitie: Product van controledichtheid en aspectdichtheid, per type product, per regio Omschrijving: Dit geeft aan in welke mate er toezicht plaatsvindt op de aspecten die vanuit het oogpunt van risicomanagement belangrijk zijn. De rapportage moet per type product worden uitgesplitst. Dit wordt bepaald door het wettelijk kader. De rapportage moet per regio worden uitgesplitst. Dit wordt bepaald door de regio waarin de inrichting is gelegen. Benodigde gegevens (grove analyse): 

Zie hierboven onder controledichtheid en aspectdichtheid

Beantwoording van de informatievragen m.b.v. het informatiemodel: Zie 7.2.2.1 en 7.2.2.2.

7.2.2.4. Naleving Definitie: % akkoord beoordeelde aspecten ten opzichte van de gecontroleerde aspecten, per type product, per regio Omschrijving: Dit geeft aan in welke mate er naleving is. De akkoord beoordeelde aspecten zijn de daadwerkelijk gecontroleerde aspecten die de status akkoord hebben gekregen. Dit aantal wordt vergeleken met het totaal aantal daadwerkelijk gecontroleerde aspecten. De rapportage moet per type product worden uitgesplitst. Dit wordt bepaald door het wettelijk kader. De rapportage moet per regio worden uitgesplitst. Dit wordt bepaald door de regio waarin de inrichting is gelegen.


49

Benodigde gegevens (grove analyse):      

Datum uitvoeren van het controlebezoek Status van het controlebezoek Controle beoordelingspunt aspect van het controlebezoek Controle beoordelingspunt status van het controlebezoek Thema en Wettelijk kader van de inrichting van de controlezaak van het controlebezoek (dit bepaalt het type product) Organisatorische eenheid die verantwoordelijk is voor de inrichting (op basis van de regio waarin de inrichting is gelegen)

Beantwoording van de informatievragen m.b.v. het informatiemodel: Zie ook de beantwoording van 7.2.2.2. Door in de Checklists per aspect ook een checklistitem op te nemen waarmee een aspect ‘Akkoord’ kan worden bevonden, kan rapportage op gecontroleerd én nageleefd aspect plaatsvinden.

7.2.2.5. Doorlooptijd Definitie: % afgehandelde controlerapporten binnen de termijn (interne norm, niet wettelijk), per type product, per regio. Omschrijving: Het gaat er om of de geplande controlebezoeken binnen de geldende termijn worden afgehandeld. Hiervoor is geen wettelijke termijn. De start is bepaald door de datum waarop het controlebezoek is afgelegd. Het eind is bepaald door de datum waarop het controlerapport definitief is opgeleverd. Begonnen kan worden met hiervan de gemiddelde doorlooptijd te meten. De rapportage moet per type product worden uitgesplitst. Dit wordt bepaald door het wettelijk kader. De rapportage moet per regio worden uitgesplitst. Dit wordt bepaald door de regio waarin de inrichting is gelegen. Benodigde gegevens (grove analyse):      

Datum uitvoeren van het controlebezoek Datum definitief opleveren van het controlerapport (wordt nu niet vastgelegd) Thema en Wettelijk kader van de inrichting van de controlezaak van het controlebezoek (dit bepaalt het type product) Organisatorische eenheid die verantwoordelijk is voor de inrichting (op basis van de regio waarin de inrichting is gelegen)

Beantwoording van de informatievragen m.b.v. het informatiemodel: Zie beantwoording 7.2.1.3 maar dan op basis van Einddatum gepland i.p.v. Uiterlijke einddatum afdoening.

7.2.2.6. Productiviteit handhaving Definitie: Aantal benodigde uren ten opzichte van de geplande uren voor het realiseren van het product, per type product, per regio, per type productiviteit, periodiek Omschrijving: Het gaat om het aantal feitelijk gebruikte uren versus de geplande uren. De feitelijke uren komen uit de tijdregistratie. De geplande uren zijn een schatting op basis van


50

historische gegevens: het jaarplan levert een schatting van de in het jaar benodigde uren voor de te realiseren productie. De rapportage moet per type product worden uitgesplitst. Dit wordt bepaald door het wettelijk kader. De rapportage moet een periode kunnen verslaan, daarom is het meest optimaal om de tijdregistratie per dag te voeren. De rapportage moet per regio worden uitgesplitst. Dit wordt bepaald door de regio waarin de inrichting is gelegen. De rapportage moet per type productiviteit zijn uit te splitsen. De volgende classificatie wordt gehanteerd:  



directe uren: uren die direct zijn toe te wijzen aan één van de te realiseren producten. Indirecte uren: uren die gemaakt worden voor het uitvoeren van de activiteiten voor toezicht en handhaving, maar die niet direct zijn toe te wijzen aan één van de te realiseren producten (regievoering, kwaliteitsmanagement, staftaken, ondersteuning). Niet productieve uren: uren die in het geheel niet kunnen worden toegewezen aan de activiteiten voor toezicht en handhaving.

Benodigde gegevens (grove analyse):     

Aantal gebruikte uren voor een wettelijk kader, voor een inrichting, per dag. Aantal gebruikte uren uitgesplitst naar het type productiviteit Aantal geplande uren voor een thema en wettelijk kader (dit bepaalt het type product), voor een regio Aantal geplande uren uitgesplitst naar het type productiviteit Organisatorische eenheid die verantwoordelijk is voor de inrichting (op basis van de regio waarin de inrichting is gelegen)

Beantwoording van de informatievragen m.b.v. het informatiemodel: Zie beantwoording van 7.2.1.5; zaakgericht werken kan alleen informatievragen beantwoorden op basis van aan zaken gerelateerde uren (directe uren). De meeste out-of-thebox zaakfunctionaliteit zal dit soort informatievragen dus niet zelfstandig kunnen beantwoorden. In combinatie met een systeem waarin tijdverantwoording plaatsvindt, zijn dit soort vragen wel te beantwoorden.

7.2.2.7. Budgetrealisatie handhaving Definitie: Aantal gebudgetteerde, verplichte en uitgegeven euro’s voor het realiseren van het product, per type product, per regio, periodiek Omschrijving: Het gaat om inzicht in de uitputting van het jaarbudget. Het opgebouwde inzicht in de realisatie kan ook worden gebruikt om de budgetteren voor het volgende jaar goed te kunnen verdelen over de regio’s. Het budget komt uit het budgetteringssysteem, de uitputting (uitgegeven en verplicht) komt uit de financiële administratie. De gebudgetteerde euro’s is een schatting op basis van historische gegevens: het jaarplan levert een schatting van de in het jaar benodigde euro’s voor de te realiseren productie. De rapportage moet per type product worden uitgesplitst. Dit wordt bepaald door het wettelijk kader. Hierin moeten ook de indirecte kosten (bedrijfsvoering en opleiding) worden meegenomen.


51

De rapportage moet een periode kunnen verslaan. De rapportage moet per regio worden uitgesplitst. Benodigde gegevens (grove analyse):   

Aantal gebudgetteerde euro’s per thema en wettelijk kader (dit bepaalt het type product), per regio, per periode. Aantal euro’s van de aangegane verplichtingen per thema en wettelijk kader (dit bepaalt het type product), per regio, per periode Aantal euro’s van de verrichte betalingen per thema en wettelijk kader (dit bepaalt het type product), per regio, per periode

Beantwoording van de informatievragen m.b.v. het informatiemodel: Een zaaksysteem is geen financieel systeem. Rapportages vanuit het zaaksysteem kunnen wel ondersteuning bieden aan bovenstaande informatievragen. Zie bijv. 7.2.1.5 en 7.2.2.6 hierboven.

7.2.2.8. Productie output Definitie: Aantallen contactmomenten en aantallen brieven per type product. De contactmomenten zijn uitgesplitst naar controletype. De brieven zijn uitgesplitst naar besluitsoort. Omschrijving: Het gaat om inzicht in de productie van de output van de uitgevoerde activiteiten. Dit wordt gemeten door de aantallen uitgevoerde controles te tellen en door de aantallen verstuurde brieven te tellen. De rapportage moet per type product worden uitgesplitst. Dit wordt bepaald door het thema en het wettelijk kader. De rapportage moet een periode kunnen verslaan. De rapportage moet per regio worden uitgesplitst. Benodigde gegevens (grove analyse):  

Aantal uitgevoerde controles, per thema en wettelijk kader (dit bepaalt het type product), per controletype, per regio, per periode. Aantal verstuurde brieven, per thema en wettelijk kader (dit bepaalt het type product), per besluitsoort, per regio, per periode.

Beantwoording van de informatievragen m.b.v. het informatiemodel: Aantal zaken van een bepaald zaaktype, aantal documenten van een bepaald type binnen zaken van een bepaald type zijn eenvoudig uit een zaaksysteem/-registratie te destilleren.


52

7.3.

Bijlage C: RITHm versie 0.8

Zie separaat document: Rhythm_v08.pdf.


53

Regionale UitvoeringsDiensten Informatiearchitectuur (RUDI) 'Op weg naar een Informatiemodel'

Recommend Documents