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

Save this PDF as:
 WORD  PNG  TXT  JPG

Maat: px
Weergave met pagina beginnen:

Download "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

PIM Standaardisatie. Marco Aarts Programma Informatieuitwisseling Milieuhandhaving (PIM)

PIM Standaardisatie. Marco Aarts Programma Informatieuitwisseling Milieuhandhaving (PIM) PIM Standaardisatie Marco Aarts Programma Informatieuitwisseling Milieuhandhaving (PIM) Agenda PIM Standaardisatie: waarom, wat en hoe? PIM Standaarden in context RIHa: het handhavingsobject centraal RIHa:

Nadere informatie

Processen en juridische aspecten LV WOZ

Processen en juridische aspecten LV WOZ Processen en juridische aspecten LV WOZ LV WOZ Inlichtingen Peter van den Heuij T 070-3427816 p.p.a.heuij@minfin.nl Datum 23 mei 2011 Auteur Ruud Kathmann Bijlage: Inleiding Voor de aanbesteding van de

Nadere informatie

Implementatiewijzer PIM Standaarden

Implementatiewijzer PIM Standaarden Implementatiewijzer PIM Standaarden auteur: Marco Aarts maart 2013 Versie 1.1 concept tekst op hoofdlijnen vastgesteld: Titia van Leeuwen 22 april 2013 vastgesteld: 1/16 maart 2013 Implementatiewijzer

Nadere informatie

Bijlage 5.1 Zaakgericht (samen)werken en ondersteunende voorzieningen

Bijlage 5.1 Zaakgericht (samen)werken en ondersteunende voorzieningen Bijlage 5.1 Zaakgericht (samen)werken en ondersteunende voorzieningen Het uitvoering geven aan de Omgevingswet vindt plaats door het, veelal in samenwerking, uitvoeren van keten- en bedrijfsprocessen (zie

Nadere informatie

Referentie Informatiemodel Handhaving (RIHa); versie 1.0

Referentie Informatiemodel Handhaving (RIHa); versie 1.0 Wilhelmina v. Pruisenweg 52-78 2595 AN Den Haag Nederland www.inspectieloket.nl Contactpersoon Peter Lustenhouwer Sr adviseur e-inspecties M 06 50 768 073 peter.lustenhouwer@ inspectieraad.nl Referentie

Nadere informatie

Releaseplan RGBZ. Inleiding. Afhankelijkheden

Releaseplan RGBZ. Inleiding. Afhankelijkheden Releaseplan RGBZ Inleiding Het RGBZ bestaat sinds 2010 en is de opvolger van het GFO-zaken uit 2004. Op basis van RGBZ 1.0 is StUF-ZKN 3.10 gemaakt. De combinatie RGBZ/StUF-ZKN is een essentieel onderdeel

Nadere informatie

Referentiemodel Stelsel van Gemeentelijke Basisgegevens_UML

Referentiemodel Stelsel van Gemeentelijke Basisgegevens_UML Referentiemodel Stelsel van Gemeentelijke Basisgegevens_UML Deel I: Beschrijving onderdeel van de GEMeentelijke Model Architectuur (GEMMA) versie 2.1 (in ontwikkeling) 14 Februari 2011 Kwaliteitsinstituut

Nadere informatie

Objecttype Reactie Actie EGEM

Objecttype Reactie Actie EGEM 1 Overzicht ontvangen commentaar op het Referentiemodel Gemeentelijke Basisgegeven Zaken v0.9 (Herkomst van de reacties is bij EGEM bekend) 1 2.2 / 13 Besluit Een twijfelgeval is nog BESLUIT, goed beschouwd

Nadere informatie

Slotbijeenkomst Pilot E-depot Utrecht. Hier komt tekst. Hier komt ook tekst. Utrecht.nl

Slotbijeenkomst Pilot E-depot Utrecht. Hier komt tekst. Hier komt ook tekst. Utrecht.nl Slotbijeenkomst Pilot E-depot Utrecht Hier komt tekst Metagegevens Metagegevens & & Architectuur Architectuur Hier komt ook tekst 22-1-2015 22-1-2014 Ben de Jong Kennis- en Kwaliteitscentrum Documentaire

Nadere informatie

Implementatiewijzer PIM Standaarden (versie 1.2) Mei 2014

Implementatiewijzer PIM Standaarden (versie 1.2) Mei 2014 Implementatiewijzer PIM Standaarden (versie 1.2) Mei 2014 1/13 1. Inleiding In het Programma Informatie-uitwisseling Milieuhandhaving wordt gewerkt aan de informatieinfrastructuur waarmee informatie gedeeld

Nadere informatie

Realisatie Programma e-dienstverlening 2e fase

Realisatie Programma e-dienstverlening 2e fase Realisatie Programma e-dienstverlening 2e fase Inleiding In de periode 2008-2009 is een Realisatieplan Dienstverlening ontwikkeld om de informatievoorziening van de gemeente Oegstgeest te verbeteren en

Nadere informatie

CORA 1.0 Bedrijfs- en ICT-referentiearchitectuur voor woningcorporaties

CORA 1.0 Bedrijfs- en ICT-referentiearchitectuur voor woningcorporaties CORA 1.0 Bedrijfs- en ICT-referentiearchitectuur voor woningcorporaties Hoe zorgen we ervoor dat we nieuwe diensten en producten soepel in onze bedrijfsvoering op kunnen nemen? Hoe geven we betere invulling

Nadere informatie

Regionale uitvoeringsdiensten Samen onderweg naar een betere samenwerking

Regionale uitvoeringsdiensten Samen onderweg naar een betere samenwerking Regionale uitvoeringsdiensten Samen onderweg naar een betere samenwerking Versie: 1.0 Datum: 16 augustus 2011 Auteur: Niels van der Kolk Afdeling: Belasting & Vastgoed 1 Inhoudsopgave 1 Regionale uitvoeringsdiensten

Nadere informatie

Referentiemodel Gemeentelijke Basisgegevens Zaken UML (RGBZ) Deel I: Beschrijving. onderdeel van de GEMeentelijke Model Architectuur (GEMMA)

Referentiemodel Gemeentelijke Basisgegevens Zaken UML (RGBZ) Deel I: Beschrijving. onderdeel van de GEMeentelijke Model Architectuur (GEMMA) Referentiemodel Gemeentelijke Basisgegevens Zaken UML (RGBZ) Deel I: Beschrijving onderdeel van de GEMeentelijke Model Architectuur (GEMMA) versie 1.1 (in ontwikkeling) 1 maart 2011 Kwaliteitsinstituut

Nadere informatie

GEMMA ZAAKTYPECATALOGUS 2

GEMMA ZAAKTYPECATALOGUS 2 GEMMA ZAAKTYPECATALOGUS 2 (VERSIE 2.1) Begeleidend document Opgesteld door KING Gemeenten Datum 1 juli 2014 Versie 2.1 2 Inhoud 1 Inleiding 4 2 De context van de Zaaktypecatalogus: van klant naar klant

Nadere informatie

GEMeentelijke Model Architectuur GEMMA 2

GEMeentelijke Model Architectuur GEMMA 2 GEMeentelijke Model Architectuur GEMMA 2 Wordt het ook gebruikt? Het GEMMA portfolio GEMMA architectuurproducten Principes Informatiearchitectuur Procesarchitectuur en referentieprocessen (nu ook referentie

Nadere informatie

Voorstel voor wijziging Informatiemodel ZTC

Voorstel voor wijziging Informatiemodel ZTC Voorstel voor wijziging Informatiemodel ZTC Van: Arjan Kloosterboer Datum: 5-9-2013 Ter bespreking in Expertgroep Informatiemodellen dd. 12-9-2013 In maart 2013 is de ZTC 2.0 gepubliceerd. Een onderdeel

Nadere informatie

Visie op Digitaal Zaakgericht werken

Visie op Digitaal Zaakgericht werken Visie op Digitaal Zaakgericht werken Aanleiding om digitaal zaakgericht te gaan werken Digitaal Zaakgericht werken is een belangrijke ontwikkeling die al geruime tijd speelt binnen de overheid, en bij

Nadere informatie

Samen werken aan betere dienstverlening

Samen werken aan betere dienstverlening Samen werken aan betere dienstverlening Onze filosofie Het gaat om de dienstverlening Instandhouden ICT-infrastructuur is geen kerntaak van gemeenten GovUnited koopt de voorzieningen om (elektronische)

Nadere informatie

De impact van de basisregistraties op de informatievoorziening van gemeenten

De impact van de basisregistraties op de informatievoorziening van gemeenten De impact van de basisregistraties op de informatievoorziening van gemeenten Op weg naar de Gemeentelijke Service Bus Danny Greefhorst Gemeenten worden geconfronteerd met allerlei ontwikkelingen die van

Nadere informatie

Modellering geplande (geometrie)wijzingen binnen het informatiemodel RSGB.

Modellering geplande (geometrie)wijzingen binnen het informatiemodel RSGB. Modellering geplande (geometrie)wijzingen binnen het informatiemodel RSGB. Concept 0.8, september 2013 1. Aanleiding Begin dit jaar is de Basisregistratie Grootschalige Topografie (BGT) en het InformatieModel

Nadere informatie

Basisregistratie Grootschalige Topografie. RSV Zuid Holland / Utrecht 8 oktober 2008 Ruud van Rossem

Basisregistratie Grootschalige Topografie. RSV Zuid Holland / Utrecht 8 oktober 2008 Ruud van Rossem Basisregistratie Grootschalige Topografie RSV Zuid Holland / Utrecht 8 oktober 2008 Ruud van Rossem 8 oktober 2008 Basisregistratie Grootschalige Topografie - E-Overheid - Basisregistraties -BGT 8 oktober

Nadere informatie

ONDERLINGE POSITIONERING INFORMATIE- EN BERICHTMODELLEN

ONDERLINGE POSITIONERING INFORMATIE- EN BERICHTMODELLEN ONDERLINGE POSITIONERING INFORMATIE- EN BERICHTMODELLEN Geleidelijk komen er voor meer domeinen informatie- en berichtenmodellen, binnengemeentelijk maar vooral ook voor een breder toepassingsgebied: een

Nadere informatie

www.zaakgerichtwerken.nl Wat is ZGW? aanmaken van zaken voor hoeveelheden werk waarvan kwaliteit en doorlooptijd bewaakt moeten worden met per zaak een zaakdossier gericht op het vastleggen van de status

Nadere informatie

Programma Informatie-uitwisseling Milieuhandhaving. PIM is een samenwerking tussen Rijk, IPO en VNG www.informatieuitwisselingmilieu.

Programma Informatie-uitwisseling Milieuhandhaving. PIM is een samenwerking tussen Rijk, IPO en VNG www.informatieuitwisselingmilieu. Programma Informatie-uitwisseling Milieuhandhaving PIM is een samenwerking tussen Rijk, IPO en VNG www.informatieuitwisselingmilieu.nl PIM RUD s Politie Veiligheids- OM Rijksinspecties regio s Agenda 1.

Nadere informatie

Ligt uw uitdaging in het aansluiten op de voorzieningen en de distributie van basisgegevens?

Ligt uw uitdaging in het aansluiten op de voorzieningen en de distributie van basisgegevens? INTEGRATIE PLATFORM Ligt uw uitdaging in het aansluiten op de voorzieningen en de distributie van basisgegevens? Met het Neuron Integratie Platform kunt u uw informatievoorziening op betrouwbare en efficiënte

Nadere informatie

De complete oplossing voor uw kadastrale informatievoorziening.

De complete oplossing voor uw kadastrale informatievoorziening. De complete oplossing voor uw kadastrale informatievoorziening. Foto: Mugmedia Het Kadaster gaat de levering van kadastrale informatie ingrijpend vernieuwen. Het huidige proces van verwerken van kadastrale

Nadere informatie

Wijziging Informatiemodel ZTC

Wijziging Informatiemodel ZTC Wijziging Informatiemodel ZTC Van: Arjan Kloosterboer Datum: 11-3-2014 Aan: Expertgroep StUF [aangepaste versie van notitie dd. 11-12-2013, met wijzigingen als zodanig gemarkeerd] In maart 2013 is de ZTC

Nadere informatie

Bijlage 1. Overzicht van de basisvoorziening in het NUP: afspraken en gevolgen voor de gemeente

Bijlage 1. Overzicht van de basisvoorziening in het NUP: afspraken en gevolgen voor de gemeente Bijlage 1. Overzicht van de basisvoorziening in het NUP: afspraken en gevolgen voor de gemeente Waar hieronder wordt gesproken over partijen is bedoeld: gemeenten, provincies, waterschappen en rijksdiensten

Nadere informatie

Business case Digikoppeling

Business case Digikoppeling Business case Digikoppeling Versie 1.0 Datum 02/06/2014 Status Definitief Van toepassing op Digikoppeling versies: 1.0, 1.1, 2.0, 3.0 Colofon Logius Servicecentrum: Postbus 96810 2509 JE Den Haag t. 0900

Nadere informatie

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans Canonieke Data Modellering op basis van ArchiMate Canonieke Data Modellering op basis van Archimate Bert Dingemans Abstract Modelleren op basis van de open standard ArchiMate is een goed uitgangspunt voor

Nadere informatie

Functioneel ontwerp. Omgevingsloket online. Koppeling met BAG

Functioneel ontwerp. Omgevingsloket online. Koppeling met BAG Functioneel ontwerp Omgevingsloket online Koppeling met BAG Juli 2014 Release 2.10 Pagina 1 van 14 Inhoudsopgave 1 Inleiding 3 1.1 Identificatie 3 1.2 Doel van dit document 3 1.3 Randvoorwaarden, uitgangspunten

Nadere informatie

Ruimte voor verbeelding

Ruimte voor verbeelding Ruimte voor verbeelding Semantiek van de Basisregistraties door Marijke Abrahamse m.m.v. Jolanda van der Linden en Daniel Wunderink Semantiek??? = Betekenisleer gaat over betekenis van woorden of zinnen

Nadere informatie

Zaakgericht Werken - ochtendsessie

Zaakgericht Werken - ochtendsessie Zaakgericht Werken - ochtendsessie Corné Dekker, informatiearchitect, IenPM BV ISZF, IJlst, 11 april 2011 www.zaakgerichtwerken.nl 1 Schermvoorbeelden Schermvoorbeelden Mozard MidOffice Suite (Deventer,

Nadere informatie

Geo samenhang in de basisregistraties

Geo samenhang in de basisregistraties Geo samenhang in de basisregistraties Dag van de geo-standaarden Geonovum, 19 mei 2010 Dirk Moree Yvette Ellenkamp Aanleiding Basisregistraties BRK (kadaster) BRT (kleinschalige topografie) BAG (adressen

Nadere informatie

Kenmerk: MS/IV/2016/

Kenmerk: MS/IV/2016/ Inhoudsopgave Bekendmaking... 3 Procedure en tijdspad... 3 Overzicht planning... 3 1. Inleiding... 4 2. Probleemstelling... 4 3. Gewenste situatie en architectuur... 5 4. Waar is gemeente Haarlem naar

Nadere informatie

Samenwerken komt neer op het verbinden van. Zaakgericht werken in ketens. achtergrond Special ICT: Any time, any place, any device

Samenwerken komt neer op het verbinden van. Zaakgericht werken in ketens. achtergrond Special ICT: Any time, any place, any device 4 Od april 2013 #3 Het inrichten van de omgeving Zaakgericht werken in ketens Zaakgericht werken is goed uitgewerkt voor gebruik binnen een organisatie. Dat is minder het geval voor zaakgericht samenwerken.

Nadere informatie

Plan van aanpak Standaardisatie

Plan van aanpak Standaardisatie Plan van aanpak Standaardisatie Programma Informatie-uitwisseling Milieuhandhaving (PIM) Auteur Marco Aarts Versie 1.0 Status Concept Datum april 2012 Opdrachtgever: Ministerie van I&M (mede namens V&J),

Nadere informatie

Officiële uitgave van het Koninkrijk der Nederlanden sinds 1814.

Officiële uitgave van het Koninkrijk der Nederlanden sinds 1814. STAATSCOURANT Officiële uitgave van het Koninkrijk der Nederlanden sinds 1814. Nr. 44665 8 december 2015 Regeling van de Minister van Infrastructuur en Milieu, van 7 december 2015, nr. IENM/BSK-2015/161734,

Nadere informatie

KING wérkt voor gemeenten

KING wérkt voor gemeenten KING wérkt voor gemeenten KING is van gemeenten Onafhankelijke speler, zonder commercieel belang Ondersteunen en faciliteren Activiteiten samen met gemeenten Vraaggericht en op maat Inspirerend en verbindend

Nadere informatie

Producten- en Dienstencatalogus BAG Verstrekkingen. Bijlage A - Verklarende woordenlijst

Producten- en Dienstencatalogus BAG Verstrekkingen. Bijlage A - Verklarende woordenlijst Producten- en Dienstencatalogus BAG Verstrekkingen Bijlage A - Verklarende woordenlijst Versie 2011 Verklarende woordenlijst Deze verklarende woordenlijst bevat een uitleg van begrippen en afkortingen

Nadere informatie

Informatie-uitwisseling in de VTH-keten. 20 november 2012

Informatie-uitwisseling in de VTH-keten. 20 november 2012 Informatie-uitwisseling in de VTH-keten 20 november 2012 Vraag: Wat betekent de komst van RUD s voor de informatie-uitwisseling in de VTH-keten en welke rol spelen de basisregistraties en het OLO daarin?

Nadere informatie

Op weg met de basisregistratie voertuigen

Op weg met de basisregistratie voertuigen Op weg met de basisregistratie voertuigen 2 Inhoud 1 Waarom deze brochure? 4 2 Het stelsel van basisregistraties 5 3 De RDW en voertuigregistratie 6 4 Aanpassingen aan de kentekenregistratie 7 5 Consequenties

Nadere informatie

Naam presentatie. Basisregistraties 7 november 2013 Amersfoort

Naam presentatie. Basisregistraties 7 november 2013 Amersfoort Naam presentatie Vrienden van de Vrienden van de Basisregistraties 7 november 2013 Amersfoort 2 Jan Haasnoot Projectleider Sectoraal Knooppunt Wim Wispelweij Programmamanager PIB 3 B R O B R P N H R B

Nadere informatie

Wat betekent het Gegevenshuis in de praktijk? Marco Kok

Wat betekent het Gegevenshuis in de praktijk? Marco Kok Wat betekent het Gegevenshuis in de praktijk? Rudolf van Summeren Adviseur informatisering Marco Kok Adviseur Geotax Bas Eenhoorn Digicommissaris: De overheid moet aansluiten op de ontwikkelingen in de

Nadere informatie

Samenhang in brongegevens. Cees Kerkhoven

Samenhang in brongegevens. Cees Kerkhoven Samenhang in brongegevens Cees Kerkhoven Barkhuis Advies 31 maart 2016 Agenda Stelsel van Basisregistraties Samenhang Gegevensmagazijn Van GBA naar BRP Tips Agenda Stelsel van Basisregistraties Samenhang

Nadere informatie

Wijzigingenoverzicht Referentiemodel Stelsel van Gemeentelijke Basisgegevens

Wijzigingenoverzicht Referentiemodel Stelsel van Gemeentelijke Basisgegevens Wijzigingenoverzicht Referentiemodel Stelsel van Gemeentelijke Basisgegevens Wijzigingen in versie 2.01 ten opzichte van versie 2.0 april 2010 Voorwoord In dit document zijn de wijzigingen opgesomd die

Nadere informatie

Forum Standaardisatie & Open Standaarden. Standaard samenwerken

Forum Standaardisatie & Open Standaarden. Standaard samenwerken Forum Standaardisatie & Open Standaarden Standaard samenwerken Betere elektronische dienstverlening, lagere administratieve lasten, transparantere en efficiëntere overheid. Dat kan alleen door samen te

Nadere informatie

Nieuwe Sturing op de Basisregistraties. Doorontwikkeling in Samenhang. De I-agenda van IenM. Presentatie DGRW. Ruud van Rossem

Nieuwe Sturing op de Basisregistraties. Doorontwikkeling in Samenhang. De I-agenda van IenM. Presentatie DGRW. Ruud van Rossem Nieuwe Sturing op de Basisregistraties De I-agenda van IenM. Presentatie DGRW Doorontwikkeling in Samenhang Ruud van Rossem Open Geo Dag 31 mei 2017 6 juni 2017 Basisregistraties In het kader van de Generieke

Nadere informatie

Voortgang en tussenresultaten Vernieuwde gegevens- en berichtstandaarden. Utrecht, 7 december 2016 Regiegroep Gegevens en Berichtenstandaarden

Voortgang en tussenresultaten Vernieuwde gegevens- en berichtstandaarden. Utrecht, 7 december 2016 Regiegroep Gegevens en Berichtenstandaarden Voortgang en tussenresultaten Vernieuwde gegevens- en berichtstandaarden Utrecht, 7 december 2016 Regiegroep Gegevens en Berichtenstandaarden Agenda 1. Plan van aanpak 2. Modelgedreven ontwikkeling 3.

Nadere informatie

Actuele ontwikkelingen in IT en IT-audit

Actuele ontwikkelingen in IT en IT-audit BASISREGISTRATIES Actuele ontwikkelingen in IT en IT-audit Auteurs: Ender Atalay en David Campbell Samenvatting Sinds 2003 werken de rijksoverheid en gemeenten aan het ontwikkelen van basisregistraties

Nadere informatie

Bijlage 5.3 Gegevensarchitectuur Opgeleverde maar nog niet vastgestelde versie

Bijlage 5.3 Gegevensarchitectuur Opgeleverde maar nog niet vastgestelde versie Bijlage 5.3 Gegevensarchitectuur Opgeleverde maar nog niet vastgestelde versie Voor het realiseren van de doelen van de Omgevingswet hebben alle betrokkenen (burgers, bedrijven, belanghebbenden, adviesbureaus,

Nadere informatie

(Gemeentelijke) Samenwerking in het Geo-domein

(Gemeentelijke) Samenwerking in het Geo-domein (Gemeentelijke) Samenwerking in het Geo-domein Gabriel van Tiggelen senior beleidsmedewerker informatiebeleid VNG ambtelijk voorzitter Gemeentelijk Geo Beraad Geo-informatie Belang (Geo) informatie bij

Nadere informatie

19 e gebruikersdag dg DIALOG BOR. 17 november 2010. Ron Bloksma Dzenita Murguzovic NORA & GEMMA. Wat heb ik er aan?

19 e gebruikersdag dg DIALOG BOR. 17 november 2010. Ron Bloksma Dzenita Murguzovic NORA & GEMMA. Wat heb ik er aan? 19 e gebruikersdag dg DIALOG BOR 17 november 2010 Ron Bloksma Dzenita Murguzovic NORA & GEMMA Wat heb ik er aan? 1 NORA Gemma architectuur RSGB Waar gaat dat allemaal over? Doel: Duidelijkheid creëren

Nadere informatie

Basisregistraties en Inspire

Basisregistraties en Inspire Basisregistraties en Inspire Stand van zaken Beleid en Perspectieven Noud Hooyman 23 maart 2011 7 april 2011 Onderwerpen en Uitdaging Positionering Geo-informatie Gideon Geo-Basisregistraties Stelsel en

Nadere informatie

Geo-informatie buiten zetten voor de bouwwereld

Geo-informatie buiten zetten voor de bouwwereld Geo-informatie buiten zetten voor de bouwwereld Hein Corstens 10 november 2010 Inhoud Initiatiefnemers BIM BIM en omgevingsinformatie Knelpunten Oplossingen Kennisplatform BIM-Omgeving Stellingen Initiatiefnemers

Nadere informatie

Consultatieadvies verwijdering NTA 9040 van de lijst met open standaarden

Consultatieadvies verwijdering NTA 9040 van de lijst met open standaarden Forum Standaardisatie Consultatieadvies verwijdering NTA 9040 van de lijst met open standaarden 16 februari 2016 Pagina 1 van 5 INLEIDING Aanleiding voor deze notitie Op 30 november 2015 heeft het ministerie

Nadere informatie

Zaakgericht werken begint bij Model-DSP en i-navigator

Zaakgericht werken begint bij Model-DSP en i-navigator powered by Zaakgericht werken begint bij Model-DSP en i-navigator 1. Wat is het Model-DSP voor gemeenten Een DSP is een dashboard voor de informatiehuishouding in gemeenten. Het is gebaseerd op de werkprocessen

Nadere informatie

Kernregistratie Openbare Ruimte Overheid & ICT, Utrecht

Kernregistratie Openbare Ruimte Overheid & ICT, Utrecht Kernregistratie Openbare Ruimte Overheid & ICT, Utrecht DE KERNREGISTRATIE OPENBARE RUIMTE IS EEN ONMISBAAR INSTRUMENT VOOR IEDERE OVERHEIDSORGANISATIE DIE BEHEERTAKEN IN DE OPENBARE RUIMTE HEEFT René

Nadere informatie

Presentatie NORA/MARIJ

Presentatie NORA/MARIJ Presentatie NORA/MARIJ 6 november 2009 Peter Bergman Adviseur Architectuur ICTU RENOIR RENOIR = REgie NuP Ondersteuning Implementatie en Realisatie Overzicht presentatie Families van (referentie-)architecturen

Nadere informatie

Context Informatiestandaarden

Context Informatiestandaarden Context Informatiestandaarden Inleiding Om zorgverleners in staat te stellen om volgens een kwaliteitsstandaard te werken moeten proces, organisatie en ondersteunende middelen daarop aansluiten. Voor ICT-systemen

Nadere informatie

Platenset proces- en informatiearchitectuur

Platenset proces- en informatiearchitectuur GEMMA Platenset proces- en informatiearchitectuur Onderdeel van de GEMeentelijke Model Architectuur EGEM i-teams April 2009 Pagina 1 Toelichting op dit document EGEM i-teams heeft afgelopen periode in

Nadere informatie

Basisregistratie Grootschalige Topografie

Basisregistratie Grootschalige Topografie asisregistratie Grootschalige Topografie RSV Zuid 29 oktober 2008 Ruud van Rossem Algemeen Projectleider GT 29 oktober 2008 asisregistratie Grootschalige Topografie - E-Overheid - asisregistraties -GT

Nadere informatie

Het stelsel werkt, ook voor de WOZ

Het stelsel werkt, ook voor de WOZ Het stelsel werkt, ook voor de WOZ Dataland Congres 2014 12-6-2014 Harmen Tjeerdsma Agenda Voorstellen Trends Stelsel en Neuron Ontwikkelingen WOZ Neuron WOZ Registratie Samenwerking En verder Vragen en

Nadere informatie

IN. SPIRATIE.nl. Zaakgericht Werken voor managers. Tilburg, 19 juni 2012 Mark van den Broek

IN. SPIRATIE.nl. Zaakgericht Werken voor managers. Tilburg, 19 juni 2012 Mark van den Broek Zaakgericht Werken voor managers Tilburg, 19 juni 2012 Wat is een Zaak? Een zaak is een afgebakende hoeveelheid werk met een welgedefineerde aanleiding en een welgedefinieerd resultaat waarvan kwaliteit

Nadere informatie

Vernieuwing gegevens en berichtenstandaarden. Plan van aanpak vernieuwing standaarden - Project breakdown - Voorgestelde route 2017

Vernieuwing gegevens en berichtenstandaarden. Plan van aanpak vernieuwing standaarden - Project breakdown - Voorgestelde route 2017 Vernieuwing gegevens en berichtenstandaarden Plan van aanpak vernieuwing standaarden - Project breakdown - Voorgestelde route 2017 Regiegroep gegevens en berichten standaarden Utrecht 5 oktober 2016 Wat

Nadere informatie

Eén digitale overheid: betere service, meer gemak

Eén digitale overheid: betere service, meer gemak Eén digitale overheid: betere service, meer gemak Rob Evelo Programmamanager i-nup Ministerie van Binnenlandse Zaken en Koninkrijksrelaties Visie op dienstverlening: samen doen Overheden werken vanuit

Nadere informatie

MEMO I-SOCIAAL DOMEIN

MEMO I-SOCIAAL DOMEIN MEMO I-SOCIAAL DOMEIN Titel: Beveiligd uitwisselen van ongestructureerde gegevens met het aanvullend bericht voor gemeenten en aanbieders Datum: 15-11-2016 Versie: 1.0 Def Inleiding Gemeenten en aanbieders

Nadere informatie

Kwaliteitsinstituut Nederlandse Gemeenten & Logius & Gebruikersverenigingen / Samenwerkingsverbanden & Leveranciers

Kwaliteitsinstituut Nederlandse Gemeenten & Logius & Gebruikersverenigingen / Samenwerkingsverbanden & Leveranciers ADDENDUM: betreffende het implementeren en gebruiken van de standaard Zaak en Document services incl. MijnOverheid / Lopende Zaken. (Addendum op de SAMENWERKINGSOVEREENKOMST KWALITEITSINSTITUUT NEDERLANDSE

Nadere informatie

Vraagstuk: informatie-uitwisseling

Vraagstuk: informatie-uitwisseling Vraagstuk: informatie-uitwisseling Tussen RUD en Opdrachtgevers Wat worden de (complexe) taken? Hoe ziet proces eruit? Wie doet Wat in het proces? En Wie Mag Wat? Tussen RUD en Ketenpartners Wie wil wat

Nadere informatie

Mozard voor de omgevingsvergunning

Mozard voor de omgevingsvergunning VTH Suite Vergunningverlening, toezicht en handhaving De Mozard 'all in one' Suite is een softwareplatform voor het verbeteren van de dienstverlening en de interne bedrijfsvoering en kan meerdere organisaties

Nadere informatie

Basisregistraties en de Omgevingswet: wát een stel. Wim van Oekel & Marjolein Kavelaars

Basisregistraties en de Omgevingswet: wát een stel. Wim van Oekel & Marjolein Kavelaars Basisregistraties en de Omgevingswet: wát een stel Wim van Oekel & Marjolein Kavelaars Basisregistraties en de Omgevingswet: wát een stel Basisregistraties en de Omgevingswet: wát een stel Wim van Oekel

Nadere informatie

Archivering en de Omgevingswet. Archiefinnovatie decentrale overheden Nieuwegein 7 april 2016

Archivering en de Omgevingswet. Archiefinnovatie decentrale overheden Nieuwegein 7 april 2016 Archivering en de Omgevingswet Archiefinnovatie decentrale overheden Nieuwegein 7 april 2016 Wim van Oekel, 07.04.2016 Onderwerpen Omgevingswet (Ow) Doelen en Inhoud Stand van zaken Digitaal Stelsel Omgevingswet

Nadere informatie

Zaakgericht samenwerken. Visie en Koers

Zaakgericht samenwerken. Visie en Koers Zaakgericht samenwerken Visie en Koers 2009032816 We staan voor diverse ambities en knelpunten Burgers 7x24 inzicht in status aanvragen Efficiënter werken Borgen rechtmatigheid Inzicht bij medewerkers

Nadere informatie

Omgevingsloket online in de keten. Corine Flendrie, Peter Visser 18 december 2012

Omgevingsloket online in de keten. Corine Flendrie, Peter Visser 18 december 2012 Omgevingsloket online in de keten Corine Flendrie, Peter Visser 18 december 2012 Huidige Omgevingsloket Onderdeel Totaal aantal ingediend Wabo 287.796 (sinds 1-10-2010) Water 3.716 (sinds 1-4-2012) Olo

Nadere informatie

Draaiboek Invoering Basisregistratie Personen l Afnemers

Draaiboek Invoering Basisregistratie Personen l Afnemers Draaiboek Invoering Basisregistratie Personen l Afnemers Van Oriëntatie naar Gebruik van de BRP Inleiding & toelichting op de vijf hoofdstappen Publicatiedatum: oktober 2014 Ten geleide Voor u ligt de

Nadere informatie

Verbinden. Bestuurlijke Samenvatting

Verbinden. Bestuurlijke Samenvatting Verbinden Bestuurlijke Samenvatting Verbinding Burgers en bedrijven verwachten dat de overheid er voor hen is in plaats van andersom. Ze willen samenhangende en begrijpelijke communicatie van de overheid

Nadere informatie

VERA 3.0. Bijlage D.2 - Leeswijzer StUF. Versie: 3.0 Datum: Status: Definitief

VERA 3.0. Bijlage D.2 - Leeswijzer StUF. Versie: 3.0 Datum: Status: Definitief VERA 3.0 Bijlage D.2 - Leeswijzer StUF Versie: 3.0 Datum: 25-9-2014 Status: Definitief Stichting VERA Veenendaal 2013-2014 http://www.stichting-vera.nl Inhoudsopgave 1 Inleiding... 3 2 StUF toelichting...

Nadere informatie

Nieuwe aanpak StUF van informatiemodel naar eindproduct standaarden. Peter Klaver, KING Expertgroep StUF 21 oktober 2015, La Vie, Utrecht

Nieuwe aanpak StUF van informatiemodel naar eindproduct standaarden. Peter Klaver, KING Expertgroep StUF 21 oktober 2015, La Vie, Utrecht Nieuwe aanpak StUF van informatiemodel naar eindproduct standaarden Peter Klaver, KING Expertgroep StUF 21 oktober 2015, La Vie, Utrecht Inhoud Grootschalige implementatie Impact Strategieën Inventarisatieronde

Nadere informatie

DRAAIBOEK AANSLUITEN DOOR GEMEENTEN OP DE LV WOZ. VERSIE d.d. 08-07-2015

DRAAIBOEK AANSLUITEN DOOR GEMEENTEN OP DE LV WOZ. VERSIE d.d. 08-07-2015 DRAAIBOEK AANSLUITEN DOOR GEMEENTEN OP DE LV WOZ VERSIE d.d. 08-07-2015 INLEIDING De Basisregistratie Waarde Onroerende Zaken (Basisregistratie WOZ) is onderdeel van het overheidsstelsel van basisregistraties.

Nadere informatie

ons kenmerk 101209.001u_as

ons kenmerk 101209.001u_as Logius Forum Standaardisatie p/a Bureau Forum Standaardisatie Postbus 84011 2508AA Den Haag doorkiesnummer 070 373 8819 onderwerp Rapport Interoperabiliteit versie 1.0 d.d. 23 nov. 2010 uw kenmerk ons

Nadere informatie

Bevordering van Interoperabiliteit tussen Overheidsorganisaties

Bevordering van Interoperabiliteit tussen Overheidsorganisaties Bevordering van Interoperabiliteit tussen Overheidsorganisaties Fineke Beukema Mariska Scherphof Pim Keizer Justitiële Informatiedienst Ministerie van Veiligheid en Justitie Almelo, Nederland ABSTRACT:

Nadere informatie

Een andere aanpak: Informatiekundige ontwikkelingen komende jaren?

Een andere aanpak: Informatiekundige ontwikkelingen komende jaren? Een andere aanpak: Informatiekundige ontwikkelingen komende jaren? Theo Peters, KING. 11 april 2017 Waar zijn wij van. GEMMA architectuur Gegevens en berichten standaarden Leveranciersmanagement Architectuur

Nadere informatie

COLLEGEBESLUITEN D.D. 06-01-2015 Nr. Onderwerp Samenvatting / toelichting Besluit A01 Beëindiging programma elektronische dienstverlening (EDV)

COLLEGEBESLUITEN D.D. 06-01-2015 Nr. Onderwerp Samenvatting / toelichting Besluit A01 Beëindiging programma elektronische dienstverlening (EDV) A01 Beëindiging programma elektronische dienstverlening (EDV) Het Programma EDV is nu actief van 2009 2014. De basis voor dit programma waren indertijd wettelijke verplichtingen en het implementeren van

Nadere informatie

Handreiking uniforme gegevenslevering Stelselcatalogus 2.0

Handreiking uniforme gegevenslevering Stelselcatalogus 2.0 Handreiking uniforme gegevenslevering Stelselcatalogus 2.0 Versie 1.1 (toevoeging metagegevens Toegankelijkheid en Gebruiksvoorwaarden, na afstemming in beheeroverleg d.d. 28-01-2014) Gegevenslevering

Nadere informatie

Praktisch Implementeren van EA bij Gemeenten

Praktisch Implementeren van EA bij Gemeenten Praktisch Implementeren van EA bij Gemeenten Edwin de Vries 3 juni 2008 Praktisch Implementeren van Enterprise Architectuur bij Gemeenten Waarom Architectuur bij Gemeenten? Praktische aanpak Invulling

Nadere informatie

Voorbeeldwerkwijze bij overleden rechthebbenden in de Basisregistratie Kadaster (BRK) Handreiking op basis van best practices

Voorbeeldwerkwijze bij overleden rechthebbenden in de Basisregistratie Kadaster (BRK) Handreiking op basis van best practices Voorbeeldwerkwijze bij overleden rechthebbenden in de Basisregistratie Kadaster (BRK) Handreiking op basis van best practices Juni 2015 Servicepunt basisregistraties Email oplossingen@ictu.nl INHOUDSOPGAVE

Nadere informatie

DECOS EN STUF-ZAKEN VOOR FRONTOFFICE FUNCTIONELE BESCHRIJVING V2.1

DECOS EN STUF-ZAKEN VOOR FRONTOFFICE FUNCTIONELE BESCHRIJVING V2.1 DECOS EN STUF-ZAKEN VOOR FRONTOFFICE FUNCTIONELE BESCHRIJVING V2.1 Februari 2015 INHOUD 1 VERSIEBEHEER DOCUMENT 3 2 INLEIDING 4 3 VERZENDEN VAN LOPENDE ZAKEN NAAR FRONTOFFICE 5 4 GEEF ZAKEN PER BURGER

Nadere informatie

Productbeschrijving BRK Levering

Productbeschrijving BRK Levering Directie Rechtszekerheid Product- en Procesbeheer Productbeschrijving Basisregistratie Kadaster Levering Auteur(s) Kadaster Directie Rechtszekerheid Product- en Procesbeheer 1 van 6 Productbeschrijving

Nadere informatie

Factsheet Mozard Archief

Factsheet Mozard Archief Archivering met de Mozard Suite Factsheet Mozard Archief Mozard maakt het mogelijk de archiefprocessen volledig zaakgericht te ondersteunen. Een zaak is een hoeveelheid werk waarvan kwaliteit en doorlooptijd

Nadere informatie

Koppelvlakspecificatie BAG - WOZ

Koppelvlakspecificatie BAG - WOZ WAARDERINGSKAMER NOTITIE Betreft: Koppelvlakspecificatie BAG - WOZ Datum: 18 januari 2010 Bijlage(n): 1. Inleiding Specificatie uitgewerkt als onderdeel van Sectormodel WOZ in samenwerking met BAGleveranciers

Nadere informatie

I nspectierapportage Wet basisregistraties adressen en gebouwen. Gemeente Lelystad. 20 januari 2014

I nspectierapportage Wet basisregistraties adressen en gebouwen. Gemeente Lelystad. 20 januari 2014 I nspectierapportage Wet basisregistraties adressen en gebouwen Gemeente Lelystad 20 januari 2014 ï Woord vooraf Deze rapportage vormt de weerslag van de in opdracht van Burgemeester en wethouders van

Nadere informatie

Gemeente Amsterdam digitaliseert dienstverlening

Gemeente Amsterdam digitaliseert dienstverlening Gemeente Amsterdam digitaliseert dienstverlening De overheid zet zwaar in op e-government, bijvoorbeeld door verbetering van de digitale dienstverlening aan de burger. De gemeente Amsterdam pakt deze vernieuwingsslag

Nadere informatie

Geo-informatie is dood Leve geo-informatie!

Geo-informatie is dood Leve geo-informatie! Geo-informatie is dood Leve geo-informatie! Geo aspecten van NORA Ron Bloksma, namens Geonovum ron.bloksma@grontmij.nl NORA Wie kent NORA 2.0? Nederlandse Overheid Referentie Architectuur eoverheid & 1Overheid

Nadere informatie

WAARDERINGSKAMER LV WOZ en andere ontwikkelingen. Caspar Remmers Waarderingskamer

WAARDERINGSKAMER LV WOZ en andere ontwikkelingen. Caspar Remmers Waarderingskamer LV WOZ en andere ontwikkelingen Caspar Remmers Waarderingskamer 1 Vier ontwikkelingen WAARDERINGSKAMER? 2 Hoe werkt de WOZ? WAARDERINGSKAMER Beschikking/ taxatieverslag BAG Kadaster Bezwaren WOZ Terugmelding

Nadere informatie

Eerste uitwerking strategisch thema 'Betrouwbare digitale informatie is de basis'

Eerste uitwerking strategisch thema 'Betrouwbare digitale informatie is de basis' Eerste uitwerking strategisch thema 'Betrouwbare digitale informatie is de basis' versie 30 augustus 2013 De beschikbaarheid van betrouwbare digitale overheidsinformatie is de basis voor het goed kunnen

Nadere informatie

Whitepaper Zaaksgewijs werken volgens BCT

Whitepaper Zaaksgewijs werken volgens BCT Handelsnaam van BCT automatisering BV KvK 14043652 postbus 300 6430 AH Hoensbroek heiberg 40 6436 CL Amstenrade t. +31 (0)46-442 45 45 f. +31 (0)46-442 47 30 info@bct.nl www.bct.nl servicedesk: t. +31

Nadere informatie

Informatiebeleid & ICT Financiën en control Facilitaire zaken. Financiële administratie. backoffice applicatie (buiten Klantcontacten

Informatiebeleid & ICT Financiën en control Facilitaire zaken. Financiële administratie. backoffice applicatie (buiten Klantcontacten Voorinvullen (sectorspecifiek) svoering Serviceregister en - intranet Aanvragen van een dienst of product, dan wel het indienen van een verzoek of een bezwaar GEMMA e-formulieren specificatie 1.3 Zaaktypen

Nadere informatie

Stappenplan en voorbeeld afbakening studentencomplexen

Stappenplan en voorbeeld afbakening studentencomplexen Stappenplan en voorbeeld afbakening studentencomplexen Versie 1.0 Auteur(s) Kadaster (met inhoudelijke instemming van Ministerie van Infrastructuur en Milieu) Status Definitief Versiehistorie Versie Datum

Nadere informatie

Kwaliteitssysteem Documentaire informatie 2.0

Kwaliteitssysteem Documentaire informatie 2.0 Kwaliteitssysteem Documentaire informatie 2.0 voor een kwalitatief goede Utrechtse informatiehuishouding versie 0.96 Leidraad Metagegevens Metagegevens worden gebruikt om andere gegevens te beschrijven

Nadere informatie