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

Transcriptie

1 Regionale UitvoeringsDiensten Informatiearchitectuur (RUDI) 'Op weg naar een Informatiemodel' Versie: 1.0 Datum: Auteur: Mark van den Broek 1

2 Inhoudsopgave 1 Managementsamenvatting Basis- en kerngegevens Procesgegevens Gegevensuitwisseling Aanbevelingen Tot slot Inleiding Doel en afbakening Doel RUDI Reikwijdte Randvoorwaarden Uitgangspunten Informatiebehoefte Basis- en kerngegevens Referentiemodellen en RITHm Procesgegevens Zaakgericht Werken en referentiemodel RGBZ Zaaktypecatalogus (ZTC) Geaggregeerde gegevens Gegevensuitwisseling Technisch en Logistiek Gestructureerde gegevens Ongestructureerde gegevens Bedrijfsfunctie- en procesmodellen Zaakgericht werken: een andere manier van kijken naar processen De Zaak: een container met daarin alle relevante informatie Virtuele dossiers: de satéprikker door alle Zaken De Zaak, Subzaken en Vervolgzaken: de basis voor samenwerking in de keten Vergunningverlening Toezicht en Handhaving Bezwaar en Beroep Klachten en Meldingen Bouwstenen en hun stand van zaken Basis- en kerngegevens Het Stelsel van Basisregistraties Referentiemodel voor het Stelsel van Gemeentelijke Basisgegevens ( 2.01, GEMMA) Referentie Informatiemodel Toezicht en Handhaving (RITHm) Procesmodellen en -gegevens Bedrijfsfunctiemodel Provincies Bedrijfsfunctiemodel Inspecties GEMMA-Procesarchitectuur (1.0, GEMMA) Referentiemodel Gemeentelijke Basisgegevens Zaken (RGBZ 1.0, GEMMA) Zaaktypecatalogus (ZTC 1.0, GEMMA) Gegevensuitwisseling Bestandsformaten Uitwisseling van gegevens

3 7 Bijlagen Bijlage A: mapping van gegevens(vragen) op, RITHm, RGBZ en ZTC Bijlage B: beantwoording Informatievragen met behulp van het informatiemodel Vergunningverlening Handhaving Bijlage C: RITHm versie

4 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 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

5 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 (). 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 een belangrijke pijler in het informatiemodel. Het 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. 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. en RITHm gezamenlijk voorzien uitstekend in de behoefte aan basis- en kerngegevens van de RUD en zijn Opdrachtgevers en Ketenpartners 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 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

6 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) 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 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 resp. RGBZ middels XML-berichten kunnen worden uitgewisseld 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 Aanbeveling 5 Aanbeveling 6 hanteer als basis voor de registratie van basis- en kerngegevens. actualiseer, met name waar het NHR betreft. 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 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. breid RITHm (Objecten) uit met INSTALLATIE. harmoniseer de naamgeving van entiteiten en attributen over de verschillende standaarden heen. 6

7 Aanbeveling 7 Aanbeveling 8 Aanbeveling 9 Aanbeveling 10 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 en RITHm met elkaar te verbinden wordt vormgegeven. Het is immers van belang om - naast basisgegevens o.b.v. - 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. 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. Aanbeveling 13 hanteer StUF 3.01 en de sectormodellen StUF-BG 3.10 en StUF-ZKN 3.10 voor gegevensuitwisseling. Aanbeveling 14 breid de StUF sectormodellen uit, afhankelijk van of en hoe de aanbeveling om en RITHm met elkaar te verbinden wordt vormgegeven. Het is immers van belang om - naast basisgegevens o.b.v. - ook de entiteiten uit RITHm elektronisch te kunnen uitwisselen. 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 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 of leg uit, resp. Gangbare Open Standaarden ) bestandsformaat uitgewisseld. Aanbeveling 17 breid het sectormodel StUF-ZKN zodanig uit dat ook documenten / dossiers kunnen worden uitgewisseld. Aanbeveling 18 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

8 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

9 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

10 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

11 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 Reikwijdte De reikwijdte van dit model beperkt zich tot het modelleren van de informatie 1 die relevant is voor de volgende primaire processen 2 : 1. Vergunningverlening 2. Toezicht en Handhaving 3. Bezwaar en Beroep 4. 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 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. Het informatiemodel moet een zo breed mogelijke basis leggen voor gemeenschappelijkheid, maar 2. moet ook voldoende flexibel zijn om lokale verschillen te absorberen. Kortom: gemeenschappelijk waar dat kan, apart waar het moet. 1 Omwille van de leesbaarheid worden de begrippen informatie en gegevens in dit document enigszins vrij gehanteerd. 2 Genoemde processen worden niet gemodelleerd. Er wordt aansluiting gezocht bij reeds bestaande procesmodellen. 11

12 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 (, 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 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

13 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. Basis- en kerngegevens 2. Procesgegevens 3. Geaggregeerde gegevens 4.1. Basis- en kerngegevens 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 Referentiemodellen en RITHm Het meest ontwikkelde model voor basisgegevens is, dat voortbouwt op het landelijke Stelsel van Basisregistraties. Maar - ook - in 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) Subject Rechtspersoon Natuurlijk Persoon Ingeschreven Persoon Ingezetene (GBA) Niet-Ingezetene (RNI) Ander Natuurlijk Persoon Niet-Natuurlijk Persoon Ingeschreven Niet-Natuurlijk Persoon (NHR) Samenwerkingsverband (NHR) Ander Buitenlands Niet-Natuurlijk Persoon Vestiging (NHR) Functionaris (NHR) Model + RITHm RITHm Activiteit Maatschappelijke Activiteit (NHR) Activiteit (NHR, niet authentiek!) Handelingen RITHm RITHm 13

14 Entiteit (oorsprong) Onderwijs (NHR) Inrichting Werk Vervoer Productstroom Model RITHm RITHm RITHm RITHm RITHm Object Adres, Gebouw en Terrein Gemeente Woonplaats (BAG) Wijk (CBS) Buurt (CBS) Gemeentelijke Openbare Ruimte Openbare Ruimte (BAG) Adresseerbaar Object Aanduiding Nummeraanduiding (BAG) Verblijfsobject (BAG) Standplaats (BAG) Ligplaats (BAG) Overige Adresseerbaar Object Aanduiding Overig Gebouwd Object Overig Terrein Pand (BAG) Overige Geo-objecten Wegdeel (IMGeo) Waterdeel (IMGeo) Terreindeel (IMGeo) Spoorbaandeel (IMGeo) Kunstwerkdeel (IMGeo) Inrichtingselement (IMGeo) Kadastrale Onroerende Zaak en Recht Kadastraal Perceel (BRK) Appartementsrecht (BRK) Zakelijk Recht (BRK) Gebruiksperceel? Tracé Voertuig (BRV) Vaartuig Vissersvaartuig (NRvV)? Dier? Product Stoffen en Producten Afvalstoffen RITHm RITHm RITHm RITHm RITHm RITHm RITHm RITHm RITHm Samenhangend met genoemde entiteiten modelleert een kleine 400 attributen. RITHm is op dit moment nog niet zover ontwikkeld dat er al attributen zijn gemodelleerd. 14

15 Een eerste - empirische - verkenning 3 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 als basis voor de registratie van basis- en kerngegevens. Aanbeveling 2. actualiseer, met name waar het NHR betreft. 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. Aanbeveling 4. verbind en RITHm 4 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. 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 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, 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

16 Dit is in een notendop wat Zaakgericht Werken behelst en waarvoor in de afgelopen jaren - sinds het vaststellen van GFO Zaken in 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 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 aannemen (Typedeclaraties 5 ) 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 Zaaktype Statustype Besluittype Documenttype Zaak Zaakobject Object Rol Betrokkene Subject Rechtspersoon Natuurlijk Persoon Niet-Natuurlijk Persoon Model RGBZ RGBZ RGBZ RGBZ RGBZ RGBZ (object) RGBZ RGBZ (subject) 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

17 Entiteit Vestiging Vestiging van Zaakbehandelende Organisatie Organisatorische Eenheid Medewerker Status Zaakdocument Document Enkelvoudig Document Samengesteld Document Besluit Model RGBZ RGBZ RGBZ RGBZ RGBZ RGBZ RGBZ RGBZ RGBZ Gerelateerd aan deze entiteiten zijn in RGBZ een kleine 150 attributen gedefinieerd en via de koppelingen met 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 en RITHm met elkaar te verbinden wordt vormgegeven. Het is immers van belang om - naast basisgegevens o.b.v. - 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 gestructureerde 6 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

18 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 ZAAKEIGENSCHAP 7. 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 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 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

19 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 Gegevensuitwisseling 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 Technisch en Logistiek Voor de technische en logistieke elementen van zo n infrastructuur wordt kortheidshalve verwezen naar generieke landelijke voorzieningen 9 (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 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 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

20 UitwisselingsFormaat (StUF). Deze standaard is geschikt voor gebruik op de hierboven genoemde infrastructuur. Zowel 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 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 gegevensuitwisseling 10. Aanbeveling 14. breid de StUF sectormodellen uit, afhankelijk van of en hoe de aanbeveling om en RITHm met elkaar te verbinden wordt vormgegeven. Het is immers van belang om - naast basisgegevens o.b.v. - ook de entiteiten uit RITHm elektronisch te kunnen uitwisselen 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 Standaarden 11. 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 of leg uit, resp. Gangbare Open Standaarden ) bestandsformaat uitgewisseld 12. 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

21 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

22 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. Vergunningverlening 2. Toezicht en Handhaving 3. Bezwaar en Beroep 4. 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 Zaakgericht werken: een andere manier van kijken naar processen 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

23 Een Zaak is 13 : 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 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 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

24 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 14 en Vervolgzaken. 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 een aantal modelprocessen 15 op hoofdlijnen, uitgewerkt hoe dit er in de praktijk kan uitzien 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. 15 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. 24

25 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

26 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

27 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: Aanschrijven: er zijn discrepanties geconstateerd tussen de wet- en 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 wet- en 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 wet- en 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

28 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

29 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

30 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 Basis- en kerngegevens 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. In onderstaande figuur is de stand van zaken opgenomen zoals die gold op 1 mei 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 ( 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

31 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 Referentiemodel voor het Stelsel van Gemeentelijke Basisgegevens ( 2.01, GEMMA) Het Referentiemodel voor Gemeentelijke Basisgegevens () is onderdeel van GEMMA en heeft het stelsel van basisregistraties als basis. De redenen voor de ontwikkeling van het referentiemodel waren meerledig: 1. 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 hebben gemeenten onder leiding van EGEM/KING een uitbreiding op het stelsel van basisregistraties gemaakt die wél populatiedekkend is. 2. Het stelsel van basisregistraties voorzag (en voorziet, zie ook hierboven) niet in alle relaties tussen basisregistraties / -gegevens die voor adequaat gegevensbeheer noodzakelijk zijn. 3. Gemeenten zijn bronhouder van GBA/RNI, BAG, WOZ en - deels - GBKN/BGT. Het 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

32 Momenteel zijn in het 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 () Het 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 naar het landelijk stelsel te vertalen en vice versa. kan derhalve worden beschouwd als het Stelsel van Basisregistraties-Plus Referentie Informatiemodel Toezicht en Handhaving (RITHm) Dit model is nog in ontwikkeling maar is gestoeld op dezelfde uitgangspunten als het : neem het stelsel van basisregistraties als basis en breid dit uit met entiteiten die van belang zijn voor adequate ondersteuning van toezicht en handhavingsprocessen Inmiddels is voor de ontwikkeling van RITHm al aansluiting gezocht bij het, zij het enigszins ambivalent: waar het het landelijke stelsel van basisgegevens - voor zover die basisgegevens die worden gemodelleerd in - volledig incorporeert en daarop voortbouwt, is het vertrekpunt van RITHm opnieuw het landelijk stelsel, terwijl dat al meekomt met. Door deze benadering dreigen slechts de aanvullingen op entiteitniveau die in zijn gemodelleerd te worden meegenomen in RITHM, maar blijven de relationele aanvullingen en wijzigingen en attribuutuitbreidingen buiten beeld. 32

33 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 de basis vormt waarop RITHm voortbouwt. Het voegt juist 33

34 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

35 6.2. Procesmodellen en -gegevens Bedrijfsfunctiemodel Provincies In PETRA hebben de provincies hun bedrijfsfunctiemodel uitgewerkt. Figuur 17 - Bedrijfsfunctiemodel Provincies 35

36 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 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

37 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. Generiek proces Vergunning Aanvragen, versie 1.0 d.d Generiek proces Subsidie Aanvragen, versie 1.0 d.d Generiek procesmodel Inkomens- en Maatschappelijke Ondersteuning Aanvragen, versie 1.0 d.d Generiek procesmodel Meldingen, versie 1.0 d.d Generiek procesmodel Bezwaren en Beroepen, concept, versie 0.6 d.d , planning Q Generiek procesmodel Publieke Producten, concept, versie 0.7 d.d , planning Q Klachten, planning Q Generiek procesmodel Aangiften en Verzoeken, concept, versie 0.1 d.d , planning Q 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

38 Figuur 20 - Referentiemodel Gemeentelijke Basisgegevens Zaken (RGBZ) Waar het 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 () 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

39 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 e- formulier. 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 GEMMA- Procesarchitectuur 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

40 6.3. Gegevensuitwisseling 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 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 ) voor het gebruik van grafische afbeeldingen ( lossy compressie) binnen ODF-documenten Portable Document Format Archivable (PDF/A-1, NEN-ISO :2005 EN) voor de lange termijn archivering van niet-reviseerbare documenten 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

41 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. Een bestand 2. WSDL 1.1 (Web Services Description Language) met SOAP 1.1 en http als onderliggend transportmechanisme 3. 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). Er zijn momenteel twee versies van StUF in gebruik 18 : StUF 2.04 in combinatie met sectormodel StUF-BG Verticale sectormodellen worden buiten beschouwing gelaten. 41