Z A A K GE R I C H T W E R K E N BETERE INFORMATIEVOORZIENING EN BETERE DIENSTVERLENING BIJ DE OVERHEID
CORNÉ DEKKER
2
Woord vooraf Zaakgericht werken staat enorm in de belangstelling. Maar wat houdt het in? Waarom denken steeds meer mensen dat het met zaakgericht werken wél gaat lukken de dienstverlening bij de overheid te verbeteren, waar eerdere pogingen met workflowmanagement- en documentmanagementsystemen steeds strandden? Dit document heeft als doel deze vragen te beantwoorden. Het beschrijft de onderwerpen die ik de afgelopen jaren heb besproken in columns, artikelen en presentaties over de e-overheid in het algemeen en zaakgericht werken in het bijzonder. Het is bedoeld voor diegenen die na het lezen van een column of artikel of na het zien van een presentatie meer van het betreffende onderwerp willen teruglezen. Dit verhaal pretendeert niet volledig te zijn en is ook niet gericht op alle doelgroepen. Het is primair gericht op informatiemanagers van overheidsinstellingen die de ambitie hebben de informatievoorziening en de dienstverlening bij hun organisatie daadwerkelijk te verbeteren. Op de website www.zaakgerichtwerken.nl zullen in de toekomst artikelen over dezelfde onderwerpen verschijnen, gericht op specifieke doelgroepen. Reacties zijn van harte welkom via
[email protected]. Ik bedank iedereen die de afgelopen jaren heeft geholpen mijn visie op zaakgericht werken te ontwikkelen en/of suggesties heeft gegeven naar aanleiding van eerdere (concept)versies van dit document, in het bijzonder: Arjan Kloosterboer, Arjen Hof, Atte Langenberg, Daan Rijsenbrij, Jan Schrotenboer, Ko van Schaik, Mark van den Broek, Mark Voogd, Niko Winkel, Patrizia Schiozzi, Rolf Gerritsen, Rudy Kaptein, Sjoerd Bruinsma, Timo ten Cate, Ton Mol, Ton Raaijmakers en Wouter Keller. Daarnaast bedank ik de Gemeente Dordrecht die mij veel kansen heeft geboden om mijn visie op een betere dienstverlening en op zaakgericht werken in de praktijk te kunnen brengen. Als informatiearchitect en ontwerper was ik betrokken bij de ontwikkeling van Mozaiek, de verzameling generieke functionaliteit in Dordrecht en de Drechtsteden, waar een zaaksysteem onderdeel van uitmaakt.
Versie 1.0, juni 2009 Corné Dekker
3
Inhoudsopgave WOORD VOORAF ..................................................................................................... 3 INHOUDSOPGAVE..................................................................................................... 4 1
HUIDIGE INFORMATIEVOORZIENING BIJ OVERHEIDSINSTELLINGEN ........................... 6
2
EGEM PROCESMODEL DIENSTVERLENING ........................................................... 7
3
GENERIEKE FUNCTIONALITEIT ........................................................................ 9
4
KANAALINTEGRATIE....................................................................................10
5
INFORMATIEARCHITECTUUR..........................................................................11
6
DE ROL VAN DE INFORMATIEARCHITECT ..........................................................13
7
RICHTLIJNEN VOOR PROJECTLEIDERS .............................................................14
8
RICHTLIJNEN VOOR PROCESEIGENAREN ...........................................................15
9
FASERING GENERIEKE FUNCTIONALITEIT..........................................................16
10
INLEIDING ZAAKGERICHT WERKEN ..................................................................17
11
ZAKENMAGAZIJN OF EEN ‘LEIDEND’ ZAAKSYSTEEM.............................................19
12
EEN ZAAKSYSTEEM TEN OPZICHTE VAN EEN WORKFLOWTOEPASSING (WFM) ............21
13
EEN ZAAKSYSTEEM TEN OPZICHTE VAN EEN DOCUMENT/DOSSIERTOEPASSING (DMS) ..23
14
ZAAKGERICHT WERKEN & ZAAKTYPEN.............................................................24
15
ZAAKGERICHT WERKEN & STATUSWIJZIGINGEN .................................................25
16
ZAAKGERICHT WERKEN & INSTRUCTIES EN CHECKLISTS .......................................26
17
ZAAKGERICHT WERKEN & GERELATEERDE ZAKEN...............................................27
18
ZAAKGERICHT WERKEN & SUB/VERVOLG ZAKEN.................................................28
19
ZAAKGERICHT WERKEN & KETENINTEGRATIE ....................................................30
20
ZAAKGERICHT WERKEN & SPECIFIEKE FUNCTIONALITEIT/PLUGINS..........................31
21
ZAAKGERICHT WERKEN & BACKOFFICETOEPASSINGEN ........................................32
22
ZAAKGERICHT WERKEN & MODERNE TECHNIEK ..................................................34
23
ZAAKGERICHT WERKEN & KOPPELEN EN KLOPPELEN ..........................................35
24
ZAAKGERICHT WERKEN & ARCHIEF/RECORDMANAGEMENT ...................................36
25
ZAAKGERICHT WERKEN & DE ZAAKTYPENCATALOGUS .........................................40
26
ZAAKGERICHT WERKEN & POSTREGISTRATIE.....................................................43
27
ZAAKGERICHT WERKEN & BASISREGISTRATIES ...................................................46
28
ZAAKGERICHT WERKEN & GEOINFORMATIE .......................................................48
29
ZAAKGERICHT WERKEN & BEVEILIGING/PRIVACY ................................................49
4
30
ZAAKGERICHT WERKEN & MANAGEMENTINFORMATIE ..........................................50
31
ZAAKGERICHT WERKEN & INTERNE DIENSTVERLENING ........................................52
32
FUNCTIONALITEIT ZAAKSYSTEEM VOOR DE BEHEERDER .......................................53
32.1
ALGEMENE KENMERKEN VAN HET ZAAKTYPE ................................................................. 53
32.2
DE AUTORISATIES ........................................................................................... 55
32.3
DE STATUSSEN .............................................................................................. 55
32.4
DE ONTVANGSTBEVESTIGING ................................................................................ 56
32.5
DE RELEVANTE BESLUITEN .................................................................................. 57
32.6
DE MOGELIJKE RESULTATEN................................................................................. 57
32.7
DE RELEVANTE DOCUMENTEN ............................................................................... 58
32.8
DE RELEVANTE KENMERKEN PER ZAAK ....................................................................... 59
32.9
DE RELEVANTE KOPPELINGEN MET REGISTRATIES IN HET GEGEVENSMAGAZIJN ................................ 59
32.10
VERPLICHTE DOCUMENTEN PER STATUS/RESULTAAT ........................................................ 60
32.11
VERPLICHTE KENMERKEN PER STATUS/RESULTAAT .......................................................... 60
32.12
VERPLICHTE KOPPELINGEN PER STATUS/RESULTAAT ........................................................ 60
32.13
CHECKLIST PER STATUS/RESULTAAT ........................................................................ 60
33
FUNCTIONALITEIT ZAAKSYSTEEM VOOR DE BEHANDELAAR ...................................62
33.1
DE INTAKE .................................................................................................. 62
33.2
DE ZAAKBAK ................................................................................................ 63
33.3
HET WIJZIGEN VAN DE STATUS .............................................................................. 65
33.4
HET OPSCHORTEN VAN DE ZAAK............................................................................. 66
33.5
DE NAW-GEGEVENS (GEGEVENSMAGAZIJN ALS BASIS)........................................................ 67
33.6
DE LOCATIE VAN DE ZAAK ................................................................................... 68
33.7
HET ZAAKDOSSIER .......................................................................................... 68
33.8
VERZOEK EXTERN ADVIES ................................................................................... 69
33.9
E-MAILBERICHTEN IN HET ZAAKDOSSIER ..................................................................... 69
33.10
OPVOEREN BESLUIT ......................................................................................... 69
33.11
PUBLICATIES MET BETREKKING TOT DE ZAAK ................................................................ 70
33.12
SIGNALEN MET BETREKKING TOT DE ZAAK ................................................................... 70
33.13
OPNEMEN PAPIEREN DOCUMENTEN IN HET DOSSIER .......................................................... 71
33.14
OPNEMEN WEBDOCUMENTEN IN HET DOSSIER ................................................................ 72
33.15
HET VERLENGEN VAN DE ZAAK .............................................................................. 72
34
FUNCTIONALITEIT ZAAKSYSTEEM VOOR DE KLANT .............................................73
34.1
COMMUNICATIE OPENBARE INFORMATIE ..................................................................... 73
34.2
COMMUNICATIE MET DE AANVRAGER ........................................................................ 74
35
CHECKLIST AANBOD FUNCTIONALITEIT ZAAKSYSTEEM.........................................77
36
IMPLEMENTATIE ORGANISATIEBREED ZAAKGERICHT WERKEN ................................79
37
IMPLEMENTATIE OVERHEIDSBREED ZAAKGERICHT WERKEN...................................81
5
1
Huidige informatievoorziening bij overheidsinstellingen
De informatievoorziening van de overheid is organisatiegericht en vooral organisatieonderdeelgericht. Vooral bij gemeenten is dat goed zichtbaar. Een gemeente kent immers van alle overheidsinstellingen de meeste processen. En het is historisch gegroeid dat de verantwoordelijkheid voor die vele processen over vele verschillende organisatieonderdelen is uitgesmeerd. Organisatieonderdelen houden geen rekening met andere organisatieonderdelen die voor een groot deel vergelijkbare werkzaamheden uitvoeren: elk organisatieonderdeel mag zelf haar informatievoorziening inrichten. Landelijke sturing ontbreekt en ook organisatiebrede sturing ontbreekt veelal. We noemen dit een verkokerde organisatie. Elk organisatieonderdeel schaft haar eigen procesondersteunende toepassing aan, zonder rekening te houden met in de organisatie reeds aanwezige toepassingen. Dit leidt niet alleen tot een zeer slechte informatievoorziening, deze is bovendien onnodig duur. Dezelfde gegevens worden op talloze plaatsen vastgelegd en onderhouden. Vergelijkbare functionaliteit wordt talloze keren aangeschaft.
Afbeelding 1a, elke afdeling een eigen loket en een eigen toepassing
Omdat een organisatieonderdeel verantwoordelijk is voor een geheel proces, zowel aan de achterkant voor de behandelaars als aan de voorkant, het loket voor de burgers, bedrijven en instellingen, is ook de dienstverlening verkokerd georganiseerd. Elk organisatieonderdeel heeft haar eigen loket. Het wordt aan de klant overgelaten om de weg te vinden naar het juiste loket. Omdat dat niet altijd meevalt, hebben burgers en bedrijven vaak het gevoel van het kastje naar de muur te worden gestuurd. Bovendien zijn er vaak gebeurtenissen, waarbij klanten van meerdere organisatieonderdelen informatie nodig hebben of een actie verwachten. Het is dan aan de klant om deze activiteiten te coördineren. De organisatieonderdelen weten niet van elkaar dat dezelfde burger of hetzelfde bedrijf ook bij andere organisatieonderdelen klant is. 6
2
EGEM Procesmodel Dienstverlening
Met het door EGEM (een landelijke programmaorganisatie dat gemeenten helpt de e-dienstverlening te verbeteren) opgestelde Procesmodel Dienstverlening is goed uit te leggen hoe het beter kan. In het linkerbovenvlak worden de subprocessen getoond van het hoofdproces ‘Dienstverlening’. Het subproces ‘Integreren kanalen’ zorgt ervoor dat alle klantvragen, ongeacht het kanaal, op een vergelijkbare wijze worden opgepakt. Het scannen van aanvragen via de post valt onder dit subproces. Het subproces ‘Classificeren klantvraag’ biedt hulpmiddelen om snel te achterhalen wat de klant precies verlangt. Beslisbomen vallen onder dit subproces. Zodra men exact weet wat de klant verlangt, zijn er twee opties: kun je de klant direct helpen of niet? De klant direct helpen door het beantwoorden van een vraag, valt onder het subproces ‘Assisteren en informeren klant’. Het belangrijkste hulpmiddel van dit subproces is de Producten- en Dienstencatalogus met Veelgestelde vragen.
Afbeelding 2a, EGEM Procesmodel Dienstverlening
Als de klant niet direct kan worden geholpen, wordt met het subproces ‘Registeren zaak’ een nieuwe zaak aangemaakt, zodat bewaakt kan worden of de klant later wel (en op tijd) geholpen wordt. 7
Ook het subproces ‘Administratief beheren zaak’ valt onder het proces ‘Dienstverlening’. Het betreft het bijhouden van de status van de zaak en ervoor zorgen dat het bijbehorende zaakdossier op orde is. Het proces ‘Afhandeling’ in het rechterbovenvlak vindt bij de vakafdeling plaats en is vanuit het gezichtspunt van de dienstverlening een blackbox. Voor de dienstverlening zijn basisgegevens nodig die in het onderste vlak zijn ‘Gegevensverzamelingen’ zijn weergegeven.
8
3
Generieke functionaliteit
De dienstverlening kan enorm worden verbeterd als voor de dienstverleningsprocessen en de hierbij benodigde gegevens (het linkerbovenvlak en het ondervlak van afbeelding 2a) generieke hulpmiddelen worden ingezet. Dus niet elke afdeling een aparte toepassing om de dienstverlening te ondersteunen, maar één organisatiebrede set hulpmiddelen die door alle afdelingen wordt gebruikt.
Afbeelding 3a, een gezamenlijk loket met generieke functionaliteit)
9
4
Kanaalintegratie
Als alle afdelingen voor de ondersteuning van de dienstverlening dezelfde set hulpmiddelen gebruiken, wordt de integratie van de verschillende contactkanalen veel eenvoudiger. Een klant kan voor álle informatie en vragen terecht op de website. Alle informatie kan worden gevonden in de productencatalogus met veelgestelde vragen. Aanvragen en meldingen kunnen via webformulieren worden ingediend. Voor het opvragen van de status van een zaak en reacties met betrekking tot een zaak wordt het zaaksysteem gebruikt. Als de klant het telefoonkanaal kiest, gebruikt de medewerker telefonie dezelfde generieke functionaliteit. De medewerker gebruikt geen apart hulpmiddel voor antwoorden op veelgestelde vragen, maar dezelfde productencatalogus. En als de klant naar de fysieke balie komt, gebruikt de baliemedewerker ook weer dezelfde generieke functionaliteit. Een hele verbetering ten opzichte van de huidige praktijk, waarbij baliemedewerkers vele toepassingen op hun pc moeten draaien om klanten te kunnen helpen, met alle risico’s van alt-tab-RSI en het vastlopen van de pc’s.
Afbeelding 4a, via alle kanalen wordt dezelfde generieke functionaliteit gebruikt
10
5
Informatiearchitectuur
Stop tien informatiearchitecten in een hok en de kans is groot dat het binnen de kortste keren alleen nog maar over een technische architectuur gaat. Termen als SOA, dienstenbus en broker vallen dan veelvuldig. Men richt zich daarbij op een ideaalbeeld dat nog erg ver in de toekomst ligt. Het is nooit goed de techniek leidend te laten zijn. Het is beter een informatiearchitectuur te definiëren die een overheidsinstelling daadwerkelijk en direct helpt haar informatievoorziening te verbeteren. De gebrekkige informatievoorziening bij overheidsinstellingen wordt voornamelijk veroorzaakt doordat afdelingen, vaak enthousiast geworden na een bezoek aan een beurs, hun informatievoorzieningswensen het liefst willen invullen door de aanschaf van een ‘eigen’ softwaretoepassing. Daarbij wordt geen rekening gehouden met de informatievoorziening van de overheidsinstelling als geheel. De ‘eigen’ softwaretoepassing is helemaal gericht op het administratieve proces van de betreffende afdeling. Hoewel vaak ook inlogcodes aan mensen buiten de eigen afdeling worden verstrekt, is het gebruik buiten de afdeling marginaal. Het gebruik kent immers een lage frequentie en dan worden de zoveelste inlogcode en de zoveelste gebruikersinterface als een belemmering ervaren. Daardoor vindt er ook nagenoeg geen gegevensuitwisseling plaats tussen afdelingen. Juist aan gegevensuitwisseling tussen verschillende afdelingen is steeds meer behoefte. Al was het maar omdat de wetgever ons daartoe verplicht. Het wordt overheidsorganisaties verboden naar de bekende weg te vragen. Niet alleen andere afdelingen, ook externen (klanten, ketenpartners, leveranciers) hebben behoefte aan informatie die momenteel in vele verschillende afdelingstoepassingen is opgeslagen. Het is daarom gewenst de functionaliteit, die buiten de ‘eigen’ afdeling nodig is, met elkaar te delen. De informatiearchitectuur moet dus definiëren welke functionaliteit generiek is en een fasering tonen voor nog te ontwikkelen generieke functionaliteit. Dát moet de kern zijn van de informatiearchitectuur van een overheidsinstelling. Generieke functionaliteit kunnen we ook benoemen als midofficefunctionaliteit. En afdelingsspecifieke functionaliteit als backofficefunctionaliteit. Zo is het bij gemeenten gebruikelijk dat men één gezamenlijke producten- en dienstencatalogus heeft ingericht. Maar als het gaat om webformulierenfunctionaliteit ziet men vaak al verschillen per afdeling. En als het gaat om de afhandeling van zaken en het onderhouden van dossiers, is het
11
momenteel zelfs gebruikelijk dat die functionaliteit is ondergebracht in de afdelingstoepassing. Op dit gebied is veel verbetering mogelijk. De architectuur die daadwerkelijk bijdraagt aan het direct aantoonbaar verbeteren van de informatievoorziening bij de overheid, is een architectuur die gericht is op generieke functionaliteit. Enerzijds op het ontwikkelen van deze generieke functionaliteit en anderzijds op het ervoor zorgen dat deze functionaliteit daadwerkelijk organisatiebreed wordt ingezet. Voorkomen moet worden dat alle processpecifieke toepassingen van de vakafdelingen een productencatalogus bevatten met uitsluitend producten van deze afdeling en dat deze toepassingen webformulieren bevatten. Een processpecifieke toepassing moet uitsluitend gericht zijn op de afdeling waarvoor deze toepassing bedoeld is. Buiten deze afdeling mag deze toepassing niet gebruikt worden. Dat houdt in dat ook het administratief beheren van zaken, het bijhouden van de status en het op orde houden van het zaakdossier, geen onderdeel zouden moeten uitmaken van de processpecifieke toepassing. Hoofdstuk 21 gaat verder in op processpecifieke toepassingen. Omdat een architectuur een schets is van een ideale situatie, is het acceptabel om tijdelijk generieke functionaliteit in backofficetoepassingen te gebruiken, als maar helder is dat daarnaast ook de generieke toepassing wordt gebruikt. Dit heeft wel als nadeel dat het een dubbele registratie met zich meebrengt. Bij nieuw aan te schaffen processpecifieke toepassingen is het van belang, de architectuurprincipes strenger toepassen. Kenmerken van een organisatie met een goed toegepaste informatiearchitectuur zijn: Proceseigenaren hebben niet langer een wens om een bepaald softwarepakket aan te schaffen, maar hebben een wens om hun informatievoorziening te verbeteren; Het aantal gebruikte softwaretoepassingen is beperkt; Er zijn veel afdelingen die volledig met generieke functionaliteit werken (geen ‘eigen’ softwarepakket).
12
6
De rol van de informatiearchitect
Bij informatievoorzieningsprojecten spelen drie aspecten een rol: doorlooptijd, budget en kwaliteit. Een projectleider is van nature geneigd de nadruk te leggen op de eerste twee aspecten. Dit komt omdat hij meestal ook wordt afgerekend op deze aspecten: is het project op tijd gereed gekomen en is de projectleider binnen het budget gebleven? Nadat het project is opgeleverd gaat de projectleider met een ander project aan de slag. De kwaliteit die door het project wordt opgeleverd, is voor de projectleider dus van minder belang. Hij is geneigd zich uitsluitend te richten op de eisen die door de directe opdrachtgever (vaak een afdelingshoofd) en de projectmedewerkers worden gesteld. Hier ligt dus een belangrijke taak voor de informatiearchitect. De informatiearchitect moet erop toezien dat het project ook kwaliteit oplevert, vanuit het oogpunt van de gehele organisatie. Resultaten van informatievoorzieningsprojecten moeten goed op elkaar worden afgestemd. Waar de projectleider een afdelingshoofd vaak als opdrachtgever ziet, ziet de informatiearchitect de algemene directie als opdrachtgever. Waar de (programma) manager projecten stuurt op doorlooptijd en budget, stuurt de informatiearchitect projecten op kwaliteit. Het is om die reden heel belangrijk een aparte functie informatiearchitect te benoemen en deze ook hiërarchisch hoger te positioneren dan de functie projectleider/adviseur.
13
7
Richtlijnen voor projectleiders
Het is de taak van de informatiearchitect ervoor te zorgen dat projectleiders zich houden aan wat de informatiearchitectuur voorschrijft. Dit lukt het best door bij de start van een project in een document kort en bondig de eisen en richtlijnen vast te leggen. Voorbeelden van kort en bondige richtlijnen zijn: Functionaliteit en de hiermee samenhangende gegevens die buiten de eigen afdeling worden gebruikt, zijn generiek en dus onderdeel van de midoffice; Projectleiders zorgen ervoor dat voor generieke functionaliteit de midoffice wordt ingezet; Gewenste uitzonderingen worden met de informatiearchitect besproken; De informatiearchitect houdt bij gewenste uitzonderingen vooral de gebruikersvriendelijkheid voor de klanten in het oog. In projectplannen moet een door de informatiearchitect goedgekeurde paragraaf worden opgenomen over generieke functionaliteit, waarin de relaties met midofficefunctionaliteit en hiermee samenhangende gegevens worden benoemd.
14
8
Richtlijnen voor proceseigenaren
Om de informatievoorziening te verbeteren is het niet alleen nodig dat de beschikbare generieke functionaliteit wordt gebruikt, deze moet zo goed mogelijk worden gebruikt. Dit is het best te realiseren door kort en bondig afspraken vast te leggen. Voorbeelden hiervan zijn: Werk waarvan doorlooptijd en kwaliteit bewaakt moeten worden, wordt in het generieke zaaksysteem geregistreerd als zaak; De behandelende afdeling weigert of accepteert elke zaak binnen één werkdag; Van een zaak wordt in het generieke zaaksysteem altijd de status bijgehouden; Het zaakdossier bevat altijd alle relevante documenten met betrekking tot de zaak (ook e-mailberichten); Aan de zaak wordt, indien relevant, altijd de locatie gekoppeld; Van een zaak worden in het generieke zaaksysteem altijd alle relevante besluiten geregistreerd; zeker als deze moeten worden gepubliceerd; Gewenste softwarematige koppelingen met backoffice-toepassingen zijn geen voorwaarde om te starten met het zaakgericht werken via het generieke zaaksysteem; het is aan de eigenaar van de backoffice-toepassing hiertoe een project op te starten. Naarmate de beschikbare generieke functionaliteit toeneemt, is het steeds minder nodig voor elke afdeling een aparte softwaretoepassing aan te schaffen. Dit betekent dat het inzetten van een informatiearchitectuur niet alleen leidt tot een betere informatievoorziening, maar ook tot een aanzienlijke kostenbesparing.
15
9
Fasering generieke functionaliteit
Elke overheidsinstelling kan zelf een fasering bepalen als het gaat om het ontwikkelen van generieke functionaliteit. Een mogelijke fasering is de volgende: Producten-diensten-catalogus (is vaak al gerealiseerd); Webformulieren; Zaken webkanaal in één omgeving; Zaken webkanaal plus zaken postkanaal in één omgeving; Dossiers/documenten in één omgeving; Basisregistratie medewerkers (wie werken er allemaal bij de organisatie, niet alleen medewerkers in vaste dienst, ook los ingehuurde krachten moeten op één plaats vastgelegd worden); Autorisaties (één autorisatiesysteem voor alle generieke functionaliteit); Parafering (alle paraafverzoeken in één omgeving); Beslisbomen; Documentcreatie/sjablonen; Gegevensmagazijn (gemeentelijke basisgegevens).
16
10 Inleiding Zaakgericht werken Om klanten goed te kunnen informeren over de status van hun zaak moeten de procesverantwoordelijken hun administratie zaakgericht inrichten. Elke hoeveelheid werk, waarvan kwaliteit en doorlooptijd bewaakt moet worden, wordt vastgelegd als zaak. Bij elke zaak hoort een zaakdossier. Nu waren er altijd al organisatieonderdelen die dat gewend waren te doen. Maar andere werkten vaak nog klantgericht (alle aanvragen, besluiten en verdere informatie over één klant in één klantdossier) of bijvoorbeeld adresgericht (alles over één adres in een adresdossier). Begrijpelijk in een tijd van papieren dossiers, maar niet langer in een tijd met digitale dossiers. Door elke zaak te koppelen aan een klant of een adres afkomstig uit de basisregistraties, is een klantdossier of een adresdossier ook prima samen te stellen door alle zaakdossiers van een bepaalde klant of van een bepaald adres op te vragen. De Vereniging Nederlandse Gemeenten (VNG) startte in 2002 een werkgroep met als doel te bepalen welke gegevens van een zaak centraal op te vragen zouden moeten zijn, om vooral de dienstverlening te kunnen verbeteren. In 2004 verscheen het GFO-Zaken (‘Gemeentelijk Functioneel Ontwerp Zaken’), waarin deze gegevens staan opgesomd. De werkgroep, met vertegenwoordigers van gemeenten en leveranciers, kwam met een definitie van een zaak ‘een hoeveelheid werk met een welgedefinieerde aanleiding en een welgedefinieerd resultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden’. Ook bedacht de werkgroep dat het organisatiebreed opslaan van alle zaakgegevens ook andere voordelen met zich mee zou brengen: Verbetering van de bedrijfsvoering (gemeentebrede managementrapportages); Effectievere handhaving (gemeentebreed alle informatie beschikbaar); Integratie van kanalen (aanvragen via post, balie, telefoon en website in één overzicht); Integratie in de keten (uitwisseling informatie over processen met andere overheidsorganisaties. Momenteel werkt EGEM aan een nieuwe versie van het GFO-Zaken. Deze zal in 2009 onder de naam RGBZ (‘Referentiemodel Gemeentelijke Basisgegevens Zaken’) verschijnen.
17
Ook het landelijke ICTU-programma ‘Persoonlijke Internet Pagina’ (PIP) heeft het zaakgericht werken omarmd door een onderdeel ‘Mijn Zaken’ op te nemen, waarmee burgers straks via mijnoverheid.nl in één overzicht de status van al hun zaken bij alle overheidsorganisaties op moeten kunnen vragen. Het GFO-Zaken is procesonafhankelijk, zoals ook een zaaksysteem procesonafhankelijk moet zijn. Het is aan elke overheidsinstelling zelf om te bepalen welke processen men met het zaaksysteem wil ondersteunen en op welke wijze men deze processen wil ondersteunen. Naast het bewaken op kwaliteit en/of doorlooptijd, kan ook de archiefwaardigheid van documenten een argument zijn om processen met het zaaksysteem te ondersteunen. Een goed voorbeeld waarmee het laatste kan worden toegelicht, is het proces rondom een afdelingsoverleg. Moet bewaakt worden dat de agenda en de notulen altijd op tijd worden vastgelegd? Moet bewaakt worden dat alle betrokkenen op tijd een uitnodiging krijgen? Het is aan de afdeling zelf of zij het afdelingsoverleg belangrijk genoeg vindt om dit proces middels zaken te bewaken.
18
11 Zakenmagazijn of een ‘leidend’ zaaksysteem Als een overheidsorganisatie beseft dat het mogelijk moet zijn van alle zaken in de organisatie te weten wat de status van deze zaken is, over alle kanalen heen, zijn er verschillende opties om dit mogelijk te maken. Men kan er voor kiezen het huidige gebruik van toepassingen zoveel mogelijk ongemoeid te laten en een extra gegevensverzameling, een zakenmagazijn, in te zetten om uit alle verschillende bestaande toepassingen de benodigde gegevens te halen. Dit is enorm complex. Enerzijds omdat er veel technische koppelingen nodig zijn. Anderzijds omdat veel bestaande toepassingen niet ingericht zijn op dienstverlening en op zaken. Vaak hebben deze toepassingen geen mogelijkheid om van een zaak de status vast te leggen. Een tweede mogelijkheid is het vervangen van de bestaande toepassingen door een generieke workflowtoepassing. Per proces wordt bepaald welke stappen (voor de behandelaar) en welke statussen (voor de klant) in een workflow moeten worden opgenomen. Door veel logica in de workflow op te nemen, wordt een processpecifieke toepassing overbodig. Veel overheidsorganisaties hebben deze ambitie de laatste jaren omarmd. Zij kwamen geleidelijk echter veelal tot het inzicht dat ook deze mogelijkheid te complex is. Het vergt een enorme inspanning om een proces met een workflowsysteem te implementeren. Nadat een project één of meerdere jaren heeft gelopen, zijn slechts enkele processen geïmplementeerd. Bovendien blijkt vaak veel maatwerk nodig, wat ten koste gaat van de flexibiliteit bij aanpassingen in het proces. Workflowsystemen zijn vooral zinvol in omgevingen waarin administratieve processen als lopende-band-werk kunnen worden gezien en waarin bovendien uitzonderingen zelden voorkomen. Overheidsprocessen lenen zich hier slecht voor. Als processen al op elkaar lijken, zijn organisatieonderdelen er beter in de verschillen ten opzichte van andere organisatieonderdelen te benadrukken, dan de overeenkomsten. Zelfs als op één afdeling verschillende behandelaren hetzelfde proces uitvoeren, zien we vaak dat er verschillend wordt gewerkt. Dit probleem moet eerst door de proceseigenaar, het afdelingshoofd, worden opgelost voordat men met een workflowsysteem aan de slag gaat. De oplossing met een workflowsysteem willen realiseren, is niet toepasbaar gebleken. Behandelaars hebben veel weerstand tegen toepassingen die exact voorschrijven hoe zij, de professionals, exact een proces moeten uitvoeren. Zo'n toepassing wordt als betuttelend ervaren.
19
Een derde mogelijkheid lijkt op het eerste gezicht wellicht minder ambitieus, maar draagt wél daadwerkelijk bij aan een betere informatievoorziening: een ‘leidend’ zaaksysteem dat, naast het zakenmagazijn, ook functionaliteit bevat om de administratie rondom zaken vast te leggen. Elke zaak start in het zaaksysteem, ongeacht het kanaal waarmee de zaak wordt geïnitieerd. Er wordt direct een bijbehorend zaakdossier aangemaakt waarin de aanvraag direct en later alle andere relevante documenten kunnen worden opgeslagen. In het zaaksysteem houdt de behandelaar de status van een zaak bij. Men kan tevens besluiten rondom een zaak vastleggen en bij de laatste status aangeven wat het eindresultaat van een zaak is. Door de ambities per proces beperkt te houden, kan tempo worden gemaakt bij het inrichten van de processen dat men via het zaaksysteem wil ondersteunen.
20
12 Een zaaksysteem ten opzichte van een Workflowtoepassing (WFM) Waarom lopen implementaties van workflowtoepassingen bij overheden steeds vast op geconstateerde complexiteit en waarom zouden implementaties van zaaksystemen wél succesvol kunnen verlopen? Wat is het verschil tussen deze twee soorten toepassingen? Workflowmanagement richt zich voornamelijk op behandelaars. Het digitaliseert stappen. Een stap is gericht op de behandelaar, een status is gericht op de klant. Een zaaksysteem digitaliseert statuswijzigingen.
Afbeelding 12a, slechts een deel van de processtappen (blauwe en witte stappen) wordt in het zaaksysteem vastgelegd
Afbeelding 12a verduidelijkt dit. Onderaan wordt een relatief eenvoudig proces getoond met 17 stappen. Sommige stappen moeten parallel uitgevoerd kunnen worden. Andere stappen moeten meerdere keren doorlopen kunnen worden. De processtappen zijn in rood, blauw en wit weergegeven.
21
Een blauwe stap betekent een statuswijziging. De behandelaar dient dit in het zaaksysteem vast leggen. Een witte stap betekent dat er een relevant document aan het zaakdossier moet worden toegevoegd. Alleen de blauwe en de witte stappen vereisen dus een actie in het zaaksysteem, maar alle rode stappen hebben geen actie in het zaaksysteem tot gevolg. Deze kunnen door de behandelaar worden uitgevoerd zoals deze dat al jaren gewend is. Uit het hoofd, met een kladpapiertje, in een excelsheet of wellicht met een backofficetoepassing. In plaats van 17 stappen, hoeft de behandelaar slechts vier statuswijzigingen in het zaaksysteem vast te leggen. Het spreekt voor zich dat het digitaliseren van vier statuswijzigingen veel minder complex is dan het digitaliseren van 17 stappen. Dát is het belangrijkste argument waarom organisatiebreed zaakgericht werken wél succesvol kan zijn. Want bovengenoemd voorbeeld betreft slechts een eenvoudig proces. Complexe processen kunnen honderden stappen bevatten. Heeft men met een workflowtoepassing dan niet dezelfde mogelijkheden als met een zaaksysteem, als men het aantal stappen zou beperken? Het probleem is dat bij een workflowtoepassing de status slechts een kenmerk is, terwijl in een zaaksysteem juist heel veel functionaliteit afhankelijk is van wat per statustype wordt geconfigureerd, zoals: checklists, signaleringsberichten en het opstarten van subzaken en plugins.
22
13 Een zaaksysteem ten opzichte van een Document/dossiertoepassing (DMS) Bij een leidend zaaksysteem worden ook alle relevante documenten vastgelegd. Bij elke nieuwe zaak wordt direct een bijbehorend zaakdossier aangemaakt. Een behandelaar moet zo gebruikersvriendelijk mogelijk documenten bij een zaak kunnen inzien en nieuwe documenten aan een zaakdossier kunnen toevoegen. Omdat functionaliteit met betrekking tot zaken en met betrekking tot zaakdossiers zo nauw met elkaar verweven is, is het verstandig deze functionaliteit in één toepassing te integreren, omdat er anders overlap in functionaliteit bestaat (zowel in het zaaksysteem als in het document/dossiersysteem) en het enorm veel moeite kost twee aparte toepassingen optimaal met elkaar te integreren. We zien in de markt ook een beweging dat leveranciers van zaaksystemen steeds meer document/dossierfunctionaliteit in hun systemen opnemen en dat leveranciers van document/dossiersystemen in hun systemen steeds meer zaakfunctionaliteit opnemen.
23
14 Zaakgericht werken & zaaktypen Bij een zaaksysteem configureert men per proces een zaaktype. Per zaaktype legt men kenmerken vast zoals.. het organisatieonderdeel dat eindverantwoordelijk is; de autorisaties (wie mag zaken van dit type behandelen, wie mag zaken toewijzen en wie mag zaakdossiers raadplegen); de te bewaken doorlooptijden; documenttypen, die in zaakdossiers van dit type kunnen voorkomen; de statussen die zaken van dit type zullen doorlopen en de mogelijke resultaten, inclusief de bijbehorende archiefkenmerken, die afhankelijk zijn van deze resultaattypen. De kracht van een goed zaaksysteem zit in het feit dat elk nieuw en gewijzigd proces heel eenvoudig in de vorm van een zaaktype kan worden geconfigureerd (zonder hulp van de leverancier)!
24
15 Zaakgericht werken & statuswijzigingen Per zaaktype definiëren we statustypen. Minimaal vier statustypen zijn voor elk zaaktype relevant, waarvan de eerste drie én de laatste altijd hetzelfde zijn. De eerste status ‘ontvangen (geregistreerd)’ wordt bereikt nadat een webformulier is ingevuld of de postintake is geboekt. De tweede status ‘geaccepteerd’ wordt bereikt nadat de behandelende afdeling de zaak heeft geaccepteerd. Richting de klant wordt deze status ‘aan de behandelende afdeling toegewezen’ genoemd. Binnen 24 uur moet de behandelende afdeling de zaak weigeren of accepteren. De derde status ‘in behandeling genomen’ wordt bereikt als alle benodigde stukken en gegevens zijn ontvangen. Per zaaktype kunnen na de derde status aanvullende statussen worden gedefinieerd. De laatste status heet altijd ‘afgehandeld’. Bij het bereiken van de laatste status moet de behandelaar ook aangeven wat het resultaat is. In toepassingen wordt vaak geen onderscheid gemaakt tussen statussen en resultaten. Ten onrechte. Elke zaak kent meerdere statussen, maar heeft altijd maar één resultaat, bijvoorbeeld ‘vergunning geweigerd’ of ‘vergunning verleend’. Het kan ook zijn dat een zaak voortijdig wordt afgebroken, op het moment dat nog niet alle statussen zijn doorlopen. Een voorbeeld van een resultaat van een afgebroken zaak is ‘aanvraag ingetrokken’.
25
16 Zaakgericht werken & instructies en checklists Om de behandelaar te ondersteunen bij z’n werkzaamheden, configureert men per statustype een instructietekst en een checklist. De checklist bestaat uit ja/nee vragen die door de behandelaar moeten worden beantwoord voordat de status kan worden gewijzigd. Denk aan vragen als ‘Zijn de externe adviezen uitgezet?’ of ‘Zijn de uitnodigingen voor de hoorzitting verstuurd?’. De behandelaar ziet dus steeds via de instructietekst welke activiteiten moeten worden uitgevoerd tot de volgende statuswijziging en kan via de checklist controleren of deze activiteiten zijn uitgevoerd. Door de antwoorden op de ja/nee vragen vast te leggen bij de zaak, kan het zaaksysteem bijdragen aan de rechtmatigheid van een proces. Of een checklistitem verplicht met ja moet worden beantwoord, voordat de status kan worden gewijzigd, kan worden geconfigureerd. De kracht van een goed zaaksysteem zit in het feit dat bij een zaaktype per statustype heel eenvoudig instructies en een checklist kunnen worden geconfigureerd (zonder hulp van de leverancier)!
26
17 Zaakgericht werken & gerelateerde zaken Als elke hoeveelheid werk, waarvan kwaliteit en doorlooptijd bewaakt moeten worden, als een aparte zaak wordt geregistreerd, is het wenselijk vast te leggen dat een zaak een relatie heeft met een andere zaak. In het verleden was men bijvoorbeeld gewend de behandeling van de ‘aanvraag vergunning’ met het besluit en de ‘bezwaarschriften met betrekking tot dat besluit’, in één papieren dossier op te slaan. Omdat bij zaakgericht werken elke zaak een apart zaakdossier oplevert, betekent elk bezwaarschrift dus een apart zaakdossier. Het is gewenst om per bezwaarschrift vast te leggen bij welke ‘aanvraag vergunning’ dit bezwaarschrift hoort. Bij de ‘aanvraag vergunning’ kan dan snel bekeken worden welke bezwaarschriften hierbij horen en bij elk bezwaarschrift welke ‘aanvraag vergunning’. Ook een advies met betrekking tot de ‘aanvraag vergunning’ en de ‘inspectie naar aanleiding van een vergunning’ kunnen aparte zaakdossiers opleveren en aan de ‘aanvraag vergunning’ worden gerelateerd.
Afbeelding 17a, gerelateerde zaken naar aanleiding van een aanvraag vergunning en een bezwaarprocedure
27
18 Zaakgericht werken & sub/vervolg zaken Het zaaksysteem administreert statuswijzigingen en geen stappen. Toch kan het gewenst zijn om ook de kwaliteit en de doorlooptijd van een processtap te bewaken. Hierin is voorzien door van zo’n processtap een aparte zaak te maken. Het subproces wordt daarmee geïmplementeerd als subzaak. Een subzaak heeft dezelfde eigenschappen als elke andere zaak. Bij het configureren van een subzaaktype legt men ook weer statustypen en resultaattypen vast. Per zaaktype kan men configureren welke typen subzaken moeten kunnen worden aangemaakt. En of deze geautomatiseerd op een vast tijdstip, bij het bereiken van een bepaalde status of het vastleggen van een bepaald resultaat, of door de behandelaar moeten kunnen worden aangemaakt.
Schets 18a: bij een stap kan geautomatiseerd of door een behandelaar (in groen weergegeven) een sub/vervolg zaak worden opgestart
28
Schets 18b: Subzaken, vervolgzaken en agenderingszaken
We maken onderscheid tussen subzaken, die gestart en afgehandeld worden tijdens een hoofdproces, en vervolgzaken, die pas gestart worden na afhandeling van een hoofdzaak. Een advies van de afdeling Milieu over een bouwvergunning is een voorbeeld van een subzaak. Een inspectie, die start na het verlenen van een bouwvergunning, is een voorbeeld van een vervolgzaak. Een vervolgzaak kan ook verder in de toekomst liggen. Na de afhandeling van een aanvraag subsidie, zou men direct kunnen vastleggen dat een jaar later een zaak moet worden gestart om de besteding van de subsidie te controleren. Dit noemen we een agenderingszaak. De kracht van een goed zaaksysteem zit in het feit dat bij een zaaktype heel eenvoudig sub- en vervolgzaaktypen kunnen worden geconfigureerd (zonder hulp van de leverancier)!
29
19 Zaakgericht werken & ketenintegratie Zoals basisregistraties bedoeld zijn om basisgegevens in een keten uit te wisselen, kunnen zaaksystemen worden gebruikt om gegevens over processen uit te wisselen. Zo wordt het heel eenvoudig in een keten alle zaken van één persoon op te vragen. Door sub- en vervolgzaken ook tussen verschillende overheidsorganisaties toe te passen, ontstaat optimale ketenintegratie. Heeft men bij een aanvraag evenementenvergunning bij een gemeente bijvoorbeeld een advies van de politie nodig, dan maakt het zaaksysteem van de gemeente geautomatiseerd een subzaak in het zaaksysteem van de politie aan. De behandelaar bij de gemeente kan als aanvrager van de subzaak, vanuit het zaakdossier van de evenementenvergunning, continu de status en het resultaat van het advies van de politie zien.
Afbeelding 19a, Ketenintegratie door het koppelen van zaaksystemen
30
20 Zaakgericht werken & specifieke functionaliteit/plugins Een zaaksysteem is generiek, dus bedoeld voor alle processen en voor alle organisatieonderdelen. Een zaaksysteem bevat dus geen processpecifieke functionaliteit. Dit is echter soms wel gewenst, bijvoorbeeld als daarmee de aanschaf van een backofficesysteem overbodig kan worden gemaakt. Denk bijvoorbeeld aan: Het opstellen van een agenda (ten behoeve van het bestuurlijk proces); Het bepalen van het subsidiebedrag (ten behoeve van een subsidie proces); Het bepalen van de leges (ten behoeve van een vergunning proces). Het moet daarom mogelijk zijn per zaaktype zaaktypespecifieke functionaliteit te kunnen aanroepen. De zaaktypespecifieke functionaliteit kan beschouwd worden als een plugin op het zaaksysteem. Per zaaktype kunnen we vastleggen welke plugins moeten kunnen worden aangeroepen, welke kenmerktypen van het zaaktype als input en output voor deze plugin relevant zijn en het documenttype van het document dat door de plugin eventueel wordt opgeleverd, zodat deze geautomatiseerd in het zaakdossier kan wordt vastgelegd. Als hiervoor een open koppelvlak wordt gespecificeerd, wordt het op termijn ook mogelijk plugins van andere leveranciers aan te roepen. De volgende stap is een standaard koppelvlak, zodat plugins kunnen worden gebruikt met alle zaaksystemen, die er op de markt beschikbaar zijn. Het zou ook mogelijk moeten worden, een plugin volledig geautomatiseerd uit te voeren, bijvoorbeeld bij het bereiken van een bepaalde status of het verkrijgen van een bepaald resultaat, eventueel afhankelijk van een bepaalde waarde van een kenmerk.
31
21 Zaakgericht werken & backofficetoepassingen Eenvoudige processen kunnen volledig met een zaaksysteem worden ondersteund, zonder dat daarvoor een aparte backofficetoepassing nodig is. Met de mogelijkheid van subzaken kunnen ook complexere processen met een zaaksysteem worden ondersteund. Ook de mogelijkheid van plugins, het toevoegen van processpecifieke functionaliteit, verkleint de noodzaak een aparte backofficetoepassing aan te schaffen. Voor welke processen blijft een aparte backofficetoepassing nodig, naast het zaaksysteem? Om die vraag te kunnen beantwoorden is het zinvol de verschillende onderdelen van zo’n toepassing te onderscheiden: Zaakfunctionaliteit (bewaken werkzaamheden) Dossier-/documentfunctionaliteit Parafeerfunctionaliteit (bewaken mandaten) Beperkte logica Complexe logica Bronregistratie Een goed zaaksysteem ondersteunt de eerste drie onderdelen (zaak-, dossier/document- en parafeerfunctionaliteit) en maakt via plugins ondersteuning van beperkte logica (bijvoorbeeld het berekenen van leges) mogelijk. Uitsluitend complexe logica (bijvoorbeeld een salarisadministratie of een financiële administratie) of een bronregistratie (bijvoorbeeld de registratie van burgers in de GBA of gereserveerde vergaderzalen) rechtvaardigen een aparte backofficetoepassing. Afbeelding 21a laat van een zestal toepassingen (A t/m F) de onderdelen zien. Vier van deze toepassingen (A, B, C en F) bevatten slechts onderdelen die ook door een generiek zaaksysteem worden ondersteund. Deze toepassingen zijn dus niet langer nodig. Slechts twee toepassingen (D en E) bevatten onderdelen (complexe logica en/of een bronregistratie) die een aparte backofficetoepassing rechtvaardigen.
32
Van deze toepassingen worden bij voorkeur uitsluitend de genoemde onderdelen gebruikt die door het generieke zaaksysteem niet worden ondersteund. Voor zaak-, dossier-/document- en parafeerfunctionaliteit wordt bij voorkeur het generieke zaaksysteem ingezet.
Afbeelding 21a, met een generiek zaaksysteem kan het aantal backofficetoepassingen sterk worden verminderd
33
22 Zaakgericht werken & moderne techniek Het aantal koppelingen tussen overheidsorganisaties wordt beperkt, wanneer elke overheidsorganisatie met één centraal zaaksysteem werkt. De functioneel servicegerichte architectuur van zaakgericht werken (een subzaak kan gezien worden als een service die wordt aangeroepen door een hoofdzaak), leent zich uitstekend voor een technische servicegerichte architectuur met webservices. Bovendien worden generieke zaaksystemen pas sinds enkele jaren ontwikkeld, wat aansluiting bij een moderne technische architectuur eenvoudiger maakt.
34
23 Zaakgericht werken & koppelen en kloppelen Het koppelen van het generieke zaaksysteem met de traditionele specifieke backofficetoepassingen is niet eenvoudig. Deze zijn vaak al vele jaren oud en bovendien niet ingericht op zaakgericht werken. Het is ongewenst zaken en dossiers, naast in het centrale zaaksysteem, óók in deze backofficetoepassingen vast te leggen. Maar maakt een organisatie toch die keuze, dan moeten dezelfde gegevens zowel in het zaaksysteem als in een backofficetoepassing worden vastgelegd. De ervaring leert dat projecten om geautomatiseerde koppelingen te realiseren (de aanvraag van het zaaksysteem richting de backoffice toepassingen en de statuswijzigingen van de backoffice toepassingen richting het zaaksysteem) meer tijd en geld kosten dan aanvankelijk geraamd, en niet zelden mislukken. Het is om die reden goed te overwegen gegevens handmatig over te tikken (kloppelen). Dit heeft het bijkomende voordeel dat de optie open blijft dat proceseigenaren er op termijn voor kunnen kiezen zaken en dossiers uitsluitend in het zaaksysteem vast te leggen. Zodra vergaande geautomatiseerde koppelingen gerealiseerd zijn en men gewend blijft aan het gebruik van de backofficetoepassing, wordt de stap om niet langer van die backofficetoepassing gebruik te maken, immers groter.
35
24 Zaakgericht werken & archief/recordmanagement Een generiek zaaksysteem bevat ook (bij voorkeur zelfs alle) archiefwaardige documenten en moet daarom ook archieffunctionaliteit bevatten. Archiefkenmerken van een zaak zijn afhankelijk van het resultaat van een zaak. Zo moet een aanvraag bouwvergunning bewaard worden als deze wordt verleend en geldt een vernietigingstermijn van drie jaar als de vergunning wordt geweigerd. Per mogelijk resultaattype wordt vastgelegd wat de nominatie is (‘bewaren’ of ‘vernietigen’), wat de bewaartermijn (in jaren) is en welke datum de bron is voor deze termijn. Er zijn vier opties voor de brondatum: Datum dat de zaak is afgehandeld; De ingangsdatum van een bij de zaak vastgelegd besluit; De vervaldatum van een bij de zaak vastgelegd besluit; Een ander datumkenmerk van de zaak (bijvoorbeeld ‘geboortedatum’, ‘datum beëindiging contract’ of ‘datum vervallen leerplicht’). Archiefkenmerken van een zaak kunnen echter ook afhankelijk zijn van een andere, gerelateerde zaak. De moeilijkheid is dat dit niet voor elke gerelateerde zaak geldt. Per resultaattype moeten we daarom vastleggen of de archiefkenmerken bij dit resultaattype afhankelijk zijn van een andere zaak (archiefkenmerken worden ontvangen) of dat deze van invloed zijn op een andere zaak (archiefkenmerken worden overgedragen). Dit doen we middels een kenmerk archiefkenmerkenrelatie welke de waarde ‘ja’ of ‘nee’ heeft.
36
Afbeelding 24a, gerelateerde zaken met een archiefkenmerkenrelatie zijn in rood weergegeven
In afbeelding 24a wordt met betrekking tot een vergunningproces een mogelijke indeling in zaaktypen weergegeven. De zaken advies, inspectie, bezwaarschrift en bewaarprocedure hebben een relatie naar de zaak vergunning. De zaken hoorzitting, beroepschrift en beroepsprocedure hebben een relatie naar de zaak bezwaarprocedure. De in rood weergegeven zaken hebben een resultaattype met een archiefkenmerkenrelatie. Bij deze resultaattypen wordt ook een archiefkenmerkenprioriteit vastgelegd. Zodra een zaak voor het eerst of gewijzigde archiefkenmerken krijgt (vanwege het verkrijgen van een resultaat of vanwege het bekend worden van een relevante brondatum) en het resultaattype heeft een archiefkenmerkenrelatie, krijgen alle gerelateerde zaken met een archiefkenmerkenrelatie de archiefkenmerken van de zaak met het resultaattype met de hoogste archiefkenmerkenprioriteit. Nadat met betrekking tot een zaak de nominatie ‘overbrengen’ of ‘vernietigen’ en de datum waarop deze zaak de archiefprocedure zal doorlopen, zijn bepaald, is het wachten tot de betreffende datum is aangebroken. Tijdens de archiefprocedure zullen de proceseigenaar/afdelingshoofd, archiefmedewerker/DIV-er en de archiefinspecteur adviseren en besluiten om zaakdossiers daadwerkelijk te vernietigen of over te brengen. Door per zaaktype doorlopende machtigingen vast te leggen, kunnen zaken die minder belangrijk zijn, volledig door het systeem afgehandeld worden, zodat de uitvoerende medewerkers zich kunnen concentreren op de belangrijkste zaakdossiers. 37
Als men het zaaksysteem ook als archiefsysteem wil inzetten, moet rekening worden gehouden met normen en standaarden op dit gebied. De NEN 2082 norm bevat eisen voor archieffunctionaliteit. Zo moet de verzameling relevante activiteiten rondom een zaakdossier worden vastgelegd. Het is daarnaast van groot belang dat gegevens en documenten in het zaaksysteem ook in de verre toekomst nog zijn op te vragen. Men dient het aantal toegestane bestandsformaten daarom te beperken door bijvoorbeeld bepaalde formaten niet toe te staan of te converteren naar wel toegestane formaten. Een mooi moment voor deze conversie is het moment dat het zaakdossier wordt bevroren. Het zaaksysteem voert dit geautomatiseerd uit, een bepaalde periode nadat de zaak is afgehandeld. Behandelaars kunnen vanaf dat tijdstip geen wijzigingen meer aanbrengen in het zaakdossier. Dit moment moet ook gebruikt worden om alle relevante gegevens van de zaak, waaronder de eerdergenoemde verzameling activiteiten en koppelingen met basisregistraties (zoals de aanvrager), als xml-bestand in het zaakdossier weg te schrijven. Hiermee wordt het mogelijk dat als het zaaksysteem zélf in de verre toekomst niet meer opvraagbaar is, alle relevante gegevens over de zaak nog steeds via dit xml-bestand opvraagbaar zijn. Zaakgericht werken verbetert de terugvindbaarheid van documenten enorm. Door kenmerken zoveel mogelijk bij de zaak vast te leggen en documenten altijd op te nemen in een zaakdossier, kan via al deze kenmerken van de zaak, een document worden teruggevonden en is de context van een document altijd bekend. Door het aantal verplichte kenmerken bij het opnemen van een document in een zaakdossier te beperken (vooral het documenttype is relevant), wordt bevorderd dat behandelaars daadwerkelijk álle relevante documenten in het zaakdossier op zullen nemen. Het is onverstandig onnodige drempels op te werpen voor het vastleggen van kenmerken. Zo wordt vaak gesteld dat bij het opvoeren van kenmerken met het gebruik van een beperkte set trefwoorden middels een thesaurus, de terugvindbaarheid zal verbeteren. Het is dan bijvoorbeeld niet toegestaan de term ‘fiets’ te gebruiken omdat alleen ‘rijwiel’ is toegestaan. Een probleem is dat medewerkers hierdoor onnodig veel tijd kwijt zijn met het registreren van documenten en het risico daardoor groot is dat vele belangrijke documenten buiten het zaaksysteem blijven en helemaal niet worden geregistreerd.
38
Deze verbetering van de terugvindbaarheid kan beter, geautomatiseerd, zonder handmatige activiteiten, gerealiseerd worden door de thesaurus op te nemen in de zoekfunctionaliteit. Zoekt men op ‘rijwiel’ dan krijgt men ook de resultaten van ‘fiets’ terug. En andersom. Mocht men via kenmerken het juiste zaakdossier niet kunnen terugvinden, dan is er altijd nog de mogelijkheid om alle documenten fulltext te doorzoeken. Het is hiervoor wel nodig dat bij het digitaliseren van papieren documenten optische teken herkenning (OCR) wordt ingzet.
39
25 Zaakgericht werken & de zaaktypencatalogus Een overheidsorganisatie is volgens de Ministeriële regeling ‘Geordende en toegankelijke staat archiefbescheiden’ verplicht een ‘Document Structuur Plan’ (DSP) te hebben. In dit plan moet ‘de wijze waarop de toegankelijkheid van de archiefbescheiden is georganiseerd en de wijze waarop archiefbescheiden zijn ingedeeld en gerangschikt’ worden vastgelegd. Het zaaksysteem bevat functionaliteit om alle kenmerken met betrekking tot een zaaktype vast te leggen. De gegevens van alle zaaktypen vormen samen de zaaktypencatalogus. Met een volledig ingerichte zaaktypencatalogus heeft de overheidsorganisatie invulling gegeven aan het DSP. In de zaaktypencatalogus worden, naast de kenmerken per zaaktype (zoals autorisaties, te doorlopen statustypen per zaak en mogelijke documenttypen) ook de kenmerken per resultaattype (zoals archiefkenmerken) opgenomen. Het is verstandig de naamgeving van zaaktypen te standaardiseren en in overeenstemming te brengen met de onderwerpen in de productencatalogus en de naamgeving van de webformulieren. Hiertoe moet men per zaaktype de volgende kenmerken vastleggen: De handeling van de klant Het onderwerp De handeling van de eigen organisatie Een categorie In het zaaksysteem kan het handig zijn van elke handeling het bijbehorende zelfstandige naamwoord vast te leggen, bijvoorbeeld ‘aanvraag’ bij ‘aanvragen’. We onderscheiden vier categorieën: E: externe dienstverlening, door een externe klant geïnitieerd (‘aanvragen paspoort’); I: interne dienstverlening, door een interne klant geïnitieerd (‘melden storing pc’); P: proces, niet direct door een interne of externe klant geïnitieerd (‘inspectie naar aanleiding van een vergunning’); M: monitoring van een zaak die door een derde partij moet worden afgehandeld (‘indienen bezwaar bij provincie’ in het zaaksysteem van een gemeente).
40
EGEM werkt momenteel aan een standaard zaaktypencatalogus voor gemeenten, waarin deze kenmerken en de archiefkenmerken voor honderden zaaktypen en resultaattypen zijn opgenomen. Tabel 25a toont de categorie en overige kenmerken die voor de naamgeving van zaaktypen, formulieren en het onderwerp in de productencatalogus van belang zijn.
Tabel 25a, acht voorbeeld zaaktypen
Een overheidsorganisatie kan zelf bepalen welke combinatie uit bovengenoemde kenmerken men voor de naamgeving kiest. Zo kan men voor de naamgeving van formulieren afspreken dat de combinatie ‘handeling klant’ + ‘onderwerp’ de naam bepaalt (als de ‘handeling klant’ leeg is, is de naam van een formulier niet van toepassing). Voor het onderwerp in de productencatalogus wordt uiteraard de kolom ‘onderwerp’ bepalend. Voor correspondentie met de klant kan de combinatie zelfstandig naamwoord ‘handeling klant’ + ‘onderwerp’ worden gebruikt. En voor de naam van een zaaktype kan de combinatie ‘handeling eigen organisatie’ + zelfstandig naamwoord ‘handeling klant’ + ‘onderwerp’ worden gebruikt.
Tabel 15b, namen formulier voor acht voorbeeld zaaktypen
Tabel 25c, namen in productencatalogus voor acht voorbeeld zaaktypen
41
Tabel 25d, onderwerp in correspondentie voor acht voorbeeld zaaktypen
Tabel 22e, namen voor acht voorbeeld zaaktypen
42
26 Zaakgericht werken & postregistratie Overheidsinstanties hebben ruime ervaring met het boeken van poststukken in zogenaamde postregistratiesystemen. Meestal is een afdeling Documentaire Informatie Voorziening (DIV) hier verantwoordelijk voor. Zoals de naam al aangeeft, wordt een postregistratiesysteem zelden gebruikt om documenten, die via andere kanalen tot een organisatie komen, te registreren. Ook wordt vaak slechts een deel van de relevante post in een postregistratiesysteem geregistreerd. Het komt vaak voor dat post van bepaalde afdelingen zonder registratie naar de afdeling wordt doorgestuurd. De post wordt dan wellicht bij de betreffende afdeling geregistreerd, maar DIV is het zicht op deze post volledig kwijt. Ook van alle relevante uitgaande post wordt in het algemeen slechts een deel geregistreerd. Veel behandelaren vergeten deze aan DIV aan te bieden, zodat organisatiebreed geen zicht is op deze stukken.
Afbeelding 26a, zaaksysteem vergeleken met een postregistratiesysteem
Afbeelding 26a toont de voordelen van een zaaksysteem ten opzichte van een traditioneel postregistratiesysteem. In tegenstelling tot een postregistratiesysteem wordt een zaaksysteem gebruikt om documenten met betrekking tot álle kanalen vast te leggen en te bewaken.
43
Bij een postregistratiesysteem wordt in het algemeen een inkomend document (I) geregistreerd en ter afhandeling aangeboden aan een bepaalde afdeling. De afdeling neemt stappen (rode S) ter afhandeling, creëert documenten (D) en produceert uiteindelijk een uitgaand document (U). Hoewel dit vaak wordt vergeten, is de afspraak dat DIV een kopie krijgt van het uitgaande document. DIV registreert het uitgaande document, zoekt het bijbehorende inkomende document erbij en vormt zo, op dat moment, dus nadat de zaak al is afgehandeld, een dossier. De enige informatie, die DIV over de zaak heeft, is ‘zaak is nog in behandeling’ of ‘zaak is afgehandeld’ (blauwe S). Bij een zaaksysteem wordt niet een inkomend document (I), maar een zaak geregistreerd. Er wordt direct een zaakdossier aangemaakt. Het inkomende document wordt in dit zaakdossier opgenomen. De afdeling neemt vergelijkbare stappen (rode S) ter afhandeling. Telkens als de status van de zaak wijzigt, geeft de behandelaar dit aan (blauwe S). Telkens als er een relevant document wordt gecreëerd, slaat de behandelaar dit op in het zaakdossier (D en U). Veel meer informatie over de zaak is centraal beschikbaar: naast de status zijn ook alle relevante documenten gedurende de afhandeling van de zaak beschikbaar. Voor medewerkers die de postregistratie verzorgen, veranderen de werkzaamheden. Waar in het verleden een inkomend stuk werd gekoppeld aan de behandelende afdeling, moet er nu gekoppeld worden aan een proces, een zaaktype. Het is van het grootste belang dat de postintakefunctionaliteit van het zaaksysteem de postintakemedewerkers zo goed mogelijk ondersteunt bij het selecteren van het juiste zaaktype. Als bijvoorbeeld een inkomende brief gaat over een te organiseren barbecue, moet de functionaliteit aangeven dat een barbecue moet worden geregistreerd als het zaaktype ‘behandelen aanvraag vergunning klein evenement’. Daarnaast helpt het de medewerkers om bij een postintake aan te kunnen geven dat een brief te complex is om het juiste zaaktype te kunnen selecteren. Deze brieven kunnen dan door een senior postintakemedewerker worden opgepakt. Een ander belangrijk verschil in werkzaamheden is dat voortaan relevante documenten die tijdens de behandeling van een zaak ontstaan, door de behandelaar zelf in het juiste zaakdossier worden geplaatst. 44
DIV krijgt een meer controlerende taak erbij: zijn de door de behandelaars samengestelde zaakdossiers juist geregistreerd en compleet?
45
27 Zaakgericht werken & basisregistraties Door elke zaak zoveel mogelijk te koppelen aan overheidsbrede basisregistraties of organisatiespecifieke kernregistraties, ontstaat de ideale informatievoorziening voor een overheidsorganisatie. Hier komen de wereld van de processen en die van de gegevens elkaar tegen. Het zou goed zijn als er een landelijke infrastructuur rondom basisregistraties zou ontstaan, waarmee elke overheidsorganisatie op een uniforme wijze zaken aan overheidsbrede basisregistraties moet kunnen koppelen. Per zaak dient men per koppeling een unieke code van de basisregistratie (bijvoorbeeld de GBA) samen met een unieke sleutel naar deze registratie (bijvoorbeeld het BSN) vast te leggen. De landelijke infrastructuur rondom basisregistraties zou ook op een uniforme wijze terugmeldingen als zaken bij de juiste bronhouder moeten aanbieden. Per basisgegeven is via het zaaksysteem van de bronhouder te achterhalen of er lopende zaken met betrekking tot dit basisgegeven zijn, wat inhoudt dat dit object ‘in onderzoek’ is. De architectuur rondom een zaaksysteem en basisregistraties is weergegeven in afbeelding 27a.
Afbeelding 27a, architectuur zaaksysteem - basisregistraties
Een nieuw object (basisgegeven) start altijd doordat een medewerker of een klant dit meldt. Van de melding wordt een zaak gemaakt (1). De bronhouder verwerkt de melding in de bronregistratie (2). Wijzigingen in de bronregistratie worden geautomatiseerd verwerkt in de basisregistratie (3). Een medewerker of klant raadpleegt gegevens uit de basisregistratie (4). De basisregistratie checkt of er met betrekking tot dit opgevraagde gegeven een lopende zaak is (5). Als dat het geval is, wordt vermeld dat het object ‘in 46
onderzoek’ is. De medewerker of klant kan, mits geautoriseerd, meer informatie over de lopende zaak opvragen in het zaaksysteem (6). Als een klant of medewerker in de basisregistratie verkeerde gegevens constateert, kan of moet dat worden gemeld via een terugmelding aan de bronhouder. Van de terugmelding wordt een zaak gemaakt (7). De bronhouder koppelt de zaak aan het betreffende object in de basisregistratie (8).
47
28 Zaakgericht werken & geoinformatie Geoinformatievoorziening wordt vaak ten onrechte als een aparte tak van sport gezien. Als een organisatieonderdeel voor haar administratie behoefte heeft aan tien kenmerken per gegeven (tien attributen per object) doet zij voor ondersteuning een beroep op de afdeling informatievoorziening. Als men nog een extra elfde kenmerk wil vastleggen, namelijk waar het object zich bevindt op de kaart, zou men dan een beroep op een andere afdeling moeten doen? Beter is het een plek op de kaart, de geometrie, als een normaal attribuut te beschouwen en de taak geoinformatievoorziening onder te brengen bij dezelfde afdeling informatievoorziening. Door basisregistraties te voorzien van attributen geometrie (waar ligt het officiële adres; waar ligt een buurt of een wijk) en zaken te koppelen aan deze basisregistraties, is van een zaak vaak al bekend waar deze zich op de kaart bevindt. Het moet echter ook mogelijk zijn, bij de zaak zelf geometrie vast te leggen in de vorm van een punt op de kaart, een vlak of zelfs een lijn, bijvoorbeeld als men bij een aanvraag voor een evenementenvergunning voor een optocht de route wil vastleggen. Burgers zijn immers zeer geïnteresseerd in zaken in hun directe omgeving. Men wil graag op de hoogte worden gehouden van alle bekendmakingen met betrekking tot een beperkte schaal rondom de eigen woning. Aan bekendmakingen over de andere kant van de stad is minder behoefte. Geometrie bij zaken vastleggen maakt deze persoonlijke dienstverlening mogelijk.
48
29 Zaakgericht werken & beveiliging/privacy In Nederland is men vanwege privacyoverwegingen nog altijd huiverig om overheidsbreed allerlei gegevens te delen. Een informatiearchitectuur met per overheidsorganisatie een zaaksysteem biedt de mogelijkheid om de verantwoordelijkheid voor autorisaties decentraal te beleggen. Elke overheidsorganisatie bepaalt wie welke gegevens mag inzien. Door andere overheidsorganisaties uitsluitend toegang te geven tot het organisatiebrede zaaksysteem en toegang tot alle andere toepassingen niet toe te staan, wordt het per overheidsorganisatie eenvoudiger het beveiligings- en privacybeleid goed uit te voeren, omdat men zich hierbij kan concentreren op het zaaksysteem.
49
30 Zaakgericht werken & managementinformatie Een van de voordelen van één generiek zaaksysteem per overheidsorganisatie voor alle gemeentelijke kanalen en processen is, dat ook managementinformatie beschikbaar komt per proces (zaaktype) over alle kanalen. Per zaaktype definiëren we wat volgens de wet de toegestane doorlooptijd is. Van elke zaak houden we bij of de vereiste doorlooptijd gehaald wordt. Per organisatie, per afdeling, per bureau... Het is begrijpelijk dat niet elk afdelingshoofd even blij is met deze transparantie. Veel overheidsorganisaties werken echter aan servicenormen die klanten beloven zaken nog sneller dan de wet vereist af te handelen. Die servicenormen definiëren we ook per zaaktype. Van elke zaak houden we dus ook bij of de servicenorm gehaald wordt. We onderscheiden: Managementinformatie over ingekomen zaken; Managementinformatie over afgehandelde zaken. Per zaaktype wordt over een bepaalde periode over ingekomen zaken minimaal getoond: Hoeveel zaken zijn ontvangen; Hoeveel zaken zijn ontvangen per kanaal; Hoeveel zaken zijn inmiddels afgehandeld; Hoeveel zaken zijn nog openstaand. Per zaaktype wordt over een bepaalde periode over de afgehandelde zaken minimaal getoond: Hoeveel zaken zijn afgehandeld; Hoeveel zaken zijn afgehandeld per initiërend kanaal; Hoeveel zaken per resultaat (bijvoorbeeld ‘vergunning verleend’ of ‘vergunning geweigerd’); Hoeveel zaken zijn op tijd afgehandeld; Hoeveel zaken zijn niet op tijd afgehandeld. Het is belangrijk om zaken op tijd af te handelen, maar het is nog belangrijker dat de klant tevreden is over de afhandeling van de zaak. Liever een tevreden klant
50
van een zaak die iets te laat is afgehandeld, dan een ontevreden klant van een zaak die op tijd is afgehandeld. Klanttevredenheid kan prima per zaak worden vastgelegd door bij het afhandelen van de zaak de klant direct enkele vragen te stellen over de tevredenheid met betrekking tot de afhandeling van deze zaak. We kunnen dus per proces managementinformatie krijgen over de klanttevredenheid. Een hele verbetering ten opzichte van de huidige klanttevredenheidsonderzoeken, die vooral bestaan uit algemene vragen waarbij altijd wel een zeven wordt gescoord. De servicenormen zouden moeten worden uitgebreid met klanttevredenheidsdoelstellingen per resultaattype, want het is goed te verklaren dat een klant minder tevreden is bij een afgewezen aanvraag dan bij een toegewezen aanvraag.
51
31 Zaakgericht werken & interne dienstverlening Zoals veel overheidsorganisaties nu plannen maken om de externe dienstverlening te verbeteren door het inrichten van een Klant Contact Centrum (KCC), zo zijn en worden er ook plannen gemaakt om de interne dienstverlening te verbeteren door het inrichten van een Shared Service Center (SSC) voor de middelenfuncties, zoals financiën, personeelszaken, facilitaire zaken en automatisering. De ambitie voor de externe dienstverlening geldt ook voor de interne dienstverlening: zorgen dat medewerkers voor al hun ondersteuning op deze gebieden terecht kunnen bij één loket. En zorgen dat alle interne dienstverlenende afdelingen hiervoor gezamenlijke functionaliteit gaan inzetten. Het ligt voor de hand dezelfde functionaliteit, die voor de verbetering van de dienstverlening aan burgers en bedrijven wordt gebruikt, ook in te zetten om de dienstverlening aan medewerkers naar een hoger plan te tillen. Zo kan de functionaliteit van de gemeentelijke producten- en dienstencatalogus ook worden gebruikt om de interne producten en diensten te beschrijven. En de functionaliteit om webformulieren te realiseren voor het aanvragen van een uittreksel of het melden van een kapotte straatlantaarn, kan ook worden gebruikt voor webformulieren voor ziekmeldingen en het melden van een storing van een pc. Als medewerkers in hun rol van interne klant de status van hun aanvragen bij alle verschillende interne dienstverlenende afdelingen in één overzicht ‘Mijn Zaken’ kunnen volgen, draagt dit bovendien enorm bij aan het besef, dat ook burgers en bedrijven het erg prettig vinden om op de hoogte te worden gehouden van de voortgang van hún zaken. En daarmee aan het verbeteren van de dienstverlenende instelling van de medewerkers in hun rol van behandelaar.
52
32 Functionaliteit zaaksysteem voor de beheerder Dit hoofdstuk schetst hoe in het zaak/dossiersysteem van Mozaiek, in gebruik bij Dordrecht en de Drechtsteden, een zaaktype wordt geconfigureerd. Ter verduidelijking zijn de daadwerkelijke gegevens over het voorbeeld zaaktype ‘behandelen aanvraag vergunning klein evenement’ steeds cursief opgenomen. Per zaaktype wordt vastgelegd: Algemene kenmerken van het zaaktype De autorisaties De statussen De ontvangstbevestiging De relevante besluiten De mogelijke resultaten De relevante documenten De relevante kenmerken per zaak De relevante koppelingen met registraties in het gegevensmagazijn Verplichte documenten per status/resultaat Verplichte kenmerken per status/resultaat Verplichte koppelingen per status/resultaat Checklist per status/resultaat In de volgende paragrafen komen de per zaaktype vast te leggen aspecten per stuk aan de orde. Het verlengen van de zaak
32.1 Algemene kenmerken van het zaaktype Naast de naam van het zaaktype => aanvraag vergunning klein evenement, leggen we voor publicaties van vergunningen op de website www.overheid.nl ook de naam ao vast => evenementenvergunning. Als verantwoordelijke leggen we het organisatieonderdeel vast => PD/BOWO/VG, welke eindverantwoordelijk is (ook als er meerdere afdelingen betrokken zijn bij de afhandeling, kiezen we één organisatieonderdeel als eindverantwoordelijke).
53
Afbeelding 32a, beheer zaaktype
We noteren zowel doorlooptijd gewenst => 21 dagen, als doorlooptijd vereist => 56 dagen. De eerste waarde geeft de servicenorm weer. De tweede waarde de wettelijk toegestane doorlooptijd. Mozaiek baseert zich bij het afhandelen op de eerste waarde, maar kan bij de managementinformatie ook rekening houden met de tweede waarde. Met doorlooptijd oranje => 3 dagen en doorlooptijd rood => 1 dag, kan worden aangegeven wanneer de resterende doorlooptijd van zaken in de zaakbak in oranje of rood moet worden weergegeven. Er kan worden aangegeven of en met welke termijn zaken van dit type kunnen worden verlengd => ja, 28 dagen. Door het invoeren van een publicatietekst worden zaken automatisch gepubliceerd op zowel de website van de overheidsorganisatie zelf als de website www.overheid.nl. Op termijn zullen ook publicaties in de krant automatisch gegenereerd worden. Tevens wordt op basis van documenttypen vastgelegd welke documenten uit het zaakdossier zullen worden gepubliceerd, bijvoorbeeld de aanvraag.
54
De burgermeester heeft de volgende aanvragen voor een evenementenvergunning ontvangen Er worden geen documenten gepubliceerd Door een gerelateerd zaaktype te selecteren => leeg, wordt het verplicht zaken van dit type te koppelen aan een zaak van een ander zaaktype. Denk hierbij aan een bezwaarschrift dat gekoppeld wordt aan een aanvraag vergunning.
32.2 De autorisaties We onderscheiden de volgende autorisatieobjecten: Beheer zaaktype ten behoeve van functioneel beheer; Behandel zaken van dit zaaktype / beheer documenten in dossier / raadplegen beperkt toegankelijke documenten voor alle behandelaars; Raadplegen zaken van dit zaaktype / raadplegen besloten documenten voor geïnteresseerden; Buiten behandeling stellen zaken van dit zaaktype voor sommige behandelaars; Toewijzen zaken van dit zaaktype voor medewerkers die zaken toewijzen aan behandelaars. Per object zijn zowel medewerkers, organisatieonderdelen, functies, rollen en groepen te selecteren. Daarnaast is er per status een autorisatieobject, zodat het mogelijk wordt voor verschillende statussen verschillende medewerkers te autoriseren.
32.3 De statussen Elk zaaktype kent minimaal vier statussen, waarvan de eerste drie statussen én de laatste status altijd hetzelfde zijn. Tussen status 3 en de laatste status kunnen extra statussen worden toegevoegd. Status 1: aanvraag vergunning klein evenement ontvangen Status 2: aanvraag vergunning klein evenement aan behandelende afdeling toegewezen Status 3: aanvraag vergunning klein evenement in behandeling genomen Status 4: aanvraag vergunning klein evenement afgehandeld Intern wordt status 2 gepresenteerd als ‘geaccepteerd’.
55
Afbeelding 32b, autorisaties
Zaken moeten binnen 24 uur na ontvangst door de behandelaars worden geaccepteerd (dus status 2) of geweigerd. In het laatste geval verschijnt de zaak opnieuw in het postintakeoverzicht, waarna men aan de zaak een ander zaaktype moet koppelen. Per status kan men de standaardtekst opgeven die klanten te zien krijgen, als zij aangeven op de hoogte te willen worden gehouden van de voortgang van de zaak. (status 2) => Uw aanvraag voor een evenementenvergunning is ontvangen door de behandelende afdeling. De aangeleverde informatie toetsen wij op volledigheid en wij kijken of de juiste vergunning is aangevraagd. Indien de aangeleverde informatie niet juist of niet volledig is, nemen wij zo spoedig mogelijk contact met u op. De teksten per status worden ook opgenomen in de bijlage van de ontvangstbevestiging.
32.4 De ontvangstbevestiging Zodra een zaak in status 3 belandt, wordt een document ontvangstbevestiging in behandeling verstuurd. Mocht na het in ontvangstbevestiging na maximaal dagen 56
=> 4 genoemde aantal dagen, de zaak nog niet in status 3 zijn beland, dan wordt een document ontvangstbevestiging ontvangen verstuurd. Men kan bij beide ontvangstbevestigingen kiezen voor een generieke ontvangstbevestiging of een zaaktype specifieke ontvangstbevestiging.
32.5 De relevante besluiten Binnen een zaak kunnen besluiten worden opgevoerd. Vergunning verleend Vergunning geweigerd Door het invoeren van een publicatietekst worden besluiten automatisch gepubliceerd op zowel de website van de overheisorganisatie zelf als de website www.overheid.nl. Tevens wordt op basis van documenttypen vastgelegd welke documenten worden gepubliceerd. (vergunning verleend) => Op grond van de Algemene Plaatselijke Verordening Dordrecht (APV) heeft de burgemeester besloten de onderstaande evenementenvergunningen te verlenen. De besluiten liggen voor u ter inzage bij de balie van het Stadskantoor, Spuiboulevard 300. Een belanghebbende kan tegen besluiten, binnen zes weken na verzending aan de aanvrager, een bezwaarschrift indienen bij de burgemeester (Postbus 8, 3300 AA Dordrecht). In spoedeisende gevallen kan de belanghebbende de voorzieningenrechter van de rechtbank te Dordrecht verzoeken een voorlopige voorziening te treffen. => Documenten van het type ‘vergunning’ worden gepubliceerd. Men kan tevens een reactietermijn => 42 opgeven, waardoor het mogelijk wordt bij de publicatie te vermelden tot wanneer men bezwaar kan maken naar aanleiding van het besluit. Via een vervolgprocedure kan naar aanleiding van een besluit automatisch een nieuwe zaak worden opgestart (het besluit een bouwvergunning te verlenen kan bijvoorbeeld automatisch leiden tot een inspectiezaak).
32.6 De mogelijke resultaten Resultaten en statussen worden vaak door elkaar heen gebruikt. Mozaiek kent een duidelijk onderscheid. Er zijn meerdere statussen, maar een zaak kent altijd maar één resultaat. Zo is ‘aanvraag afgehandeld’ een status en ‘vergunning verleend’ een resultaat.
57
Vergunning klein evenement verleend Vergunning klein evenement geweigerd Bij het zetten van de laatste status ‘aanvraag afgehandeld’ dient men altijd een resultaat te kiezen. Per resultaat kan men de standaardtekst opgeven die klanten te zien krijgen, als zij aangeven op de hoogte te willen worden gehouden van de voortgang van de zaak. => Alle benodigde adviezen zijn ontvangen. De aanvraag is beoordeeld en uw aanvraag kunnen wij toewijzen. De formele beschikking ontvangt u zo spoedig mogelijk per post. Voor nadere informatie, bijvoorbeeld met betrekking tot rechten en plichten, verwijzen wij u naar de website http://www.dordrecht.nl/zaakinfo De teksten per resultaat worden ook opgenomen in de bijlage van de ontvangstbevestiging. Naast resultaten, die worden vastgelegd indien de zaak de laatste status heeft bereikt, zijn er ook ‘bijzondere resultaten’, waar uit moet worden gekozen, indien een zaak voortijdig wordt afgehandeld. Geen vergunning nodig Aanvraag niet compleet Aanvraag niet tijdig ingediend Aanvraag ingetrokken Dubbel ingeboekt Gewijzigd zaaktype
32.7 De relevante documenten Een opsomming van documenttypen die kunnen voorkomen in dossiers van dit type zaken. Bij het plaatsen van een document in het zaakdossier is men verplicht het documenttype te kiezen. Het documenttype wordt gehangen aan de relatie tussen het document en het dossier. Hetzelfde document kan immers in een ander dossier een ander documenttype krijgen. => Aanvraag, Advies, Bijlage bij aanvraag/melding, Bijlage reactie aanvrager, Brief geen vergunning/melding nodig, Brief niet in / buiten behandeling, Intrekking, Ontvangstbevestiging, Rappelbrief, Reactie aanvrager met betrekking 58
tot zaak, Verdagingbesluit, Vergunning, Verslag, Verslag bevindingen, Verslag gesprek, Verzoek om aanvulling, Verzoek om advies, Voornemen, Weigering, Zienswijze
32.8 De relevante kenmerken per zaak Een opsomming van zaaktypespecifieke kenmerktypen die men kan vastleggen per zaak. => Geen zaaktype-specifieke kenmerken
32.9 De relevante koppelingen met registraties in het gegevensmagazijn Er zijn drie bijzondere koppelingen met registraties in het gegevensmagazijn: Aanvrager natuurlijk persoon kan ook een selectie zijn (b.v. 65-plussers) => alle personen; Aanvrager niet-natuurlijk persoon kan ook een selectie zijn => alle bedrijven; Locatie kan zowel via een koppeling naar het gegevensmagazijn => buurt, wijk, adres, als direct geometrie bij een zaak => punt, vlak, lijn. Daarnaast kunnen nog extra relevante koppelingen worden vastgelegd. => Geen extra relevante koppelingen Het is te ingewikkeld om alle registraties uit het gegevensmagazijn apart in het model weer te geven. Immers: het moet in de toekomst mogelijk zijn om met álle registraties te koppelen (en dus niet uitsluitend gegevens uit de bekende basisregistraties). Zo zou je idealiter bij een kapvergunning de bewuste boom kunnen koppelen. Of bij het melden van een defecte lantaarn de bewuste lantaarn. Wij hebben dat in Dordrecht opgelost door de verschillende registraties te benoemen. Per registratie bepalen we de identificerende sleutel waarmee we de zaak aan de registratie koppelen. Voorbeeld: zaak x is gekoppeld aan identificerende sleutel y van registratie z.
59
32.10 Verplichte documenten per status/resultaat Per status en per resultaat kan worden verplicht dat er een document van een bepaald type in het dossier aanwezig is. Als dit document ontbreekt, kan de status niet worden gewijzigd. (status 2) => Aanvraag (vergunning verleend) => Vergunning (vergunning geweigerd) => Weigering (geen vergunning/melding nodig) => Brief geen vergunning/melding nodig (aanvraag niet tijdig ingediend) => Brief niet in / buiten behandeling (aanvraag ingetrokken) => Intrekking
32.11 Verplichte kenmerken per status/resultaat Per status en per resultaat kan worden verplicht dat kenmerken een waarde hebben. => geen kenmerken, dus ook geen verplichte kenmerken
32.12 Verplichte koppelingen per status/resultaat Per status en per resultaat kan worden verplicht dat bepaalde extra koppelingen verplicht zijn. => geen extra koppelingen, dus ook geen verplichte extra koppelingen
32.13 Checklist per status/resultaat Om te kunnen controleren of behandelaars belangrijke stappen in het proces hebben uitgevoerd, kan per statuswijziging een checklist met ja/nee-vragen worden vastgelegd. Per ja/nee-vraag kan tevens bepaald worden of het antwoord ‘ja’ verplicht is om de status te kunnen wijzigen. De antwoorden worden vastgelegd bij de zaak. (status 3) => Is het zaaktype akkoord? (status 3) => Is de aanvraag volledig? (vergunning klein evenement verleend) => Zijn alle benodigde adviezen aangevraagd? (vergunning klein evenement verleend) => Zijn alle aangevraagde adviezen ontvangen?
60
(vergunning klein evenement verleend) => Is het dossier compleet? (vergunning klein evenement verleend) => Is het besluit gemotiveerd? (vergunning klein evenement verleend) => Is de beschikking door de mandaathouder ondertekend? (vergunning klein evenement geweigerd) => Zijn alle benodigde adviezen aangevraagd? (vergunning klein evenement geweigerd) => Zijn alle aangevraagde adviezen ontvangen? (vergunning klein evenement geweigerd) => Is het dossier compleet? (vergunning klein evenement geweigerd) => Is het besluit gemotiveerd? (vergunning klein evenement geweigerd) => Is de beschikking door de mandaathouder ondertekend?
61
33 Functionaliteit zaaksysteem voor de behandelaar Dit hoofdstuk schetst hoe in Mozaiek, het zaak/dossier-systeem van Dordrecht en de Drechtsteden, een zaak wordt afgehandeld. Bij het behandelen van een zaak is relevant: De intake De zaakbak Het wijzigen van de status Het opschorten van de zaak De naw-gegevens (gegevensmagazijn als basis) De locatie van de zaak Het zaakdossier Verzoek extern advies E-mailberichten in het zaakdossier Opvoeren besluit Publicaties met betrekking tot de zaak Signalen met betrekking tot de zaak Opnemen papieren documenten in het dossier Opnemen webdocumenten in het dossier Het verlengen van de zaak In de volgende paragrafen komen de aspecten van afhandeling van een zaak per stuk aan de orde.
33.1 De intake De postintakefunctionaliteit maakt het de medewerker mogelijk dat: Het juiste zaaktype aan het gescande pdf-bestand wordt gekoppeld; De naw-gegevens van de aanvrager worden vastgelegd; Algemene en evt. Zaaktype-specifieke kenmerken worden vastgelegd; Eventueel de locatie wordt vastgelegd; Eventueel de gerelateerde zaak wordt vastgelegd;
62
Eventueel een bijlage wordt gekoppeld (bijvoorbeeld a0-tekeningen bij een aanvraag bouwvergunning) middels de zogenaamde scanvelop functionaliteit (zie ook paragraaf 33.13). Met de postintakefunctionaliteit wordt een zaak en een bijbehorend zaakdossier aangemaakt en wordt de aanvraag en de eventuele bijlage(n) als pdf-document in het dossier geplaatst. De webintakefunctionaliteit wordt aangeroepen, nadat een klant het webformulier heeft verstuurd. De aangeroepen functionaliteit maakt een zaak en een bijbehorend zaakdossier aan, plaatst de gegevens van het ingevulde webformulier als xml-document in het dossier, plaatst eventuele bijlagen in het dossier, meldt de klant welk zaaknummer is toegekend en via welke url meer informatie over de zaak kan worden verkregen. Het is dus belangrijk dat de webformulierfunctionaliteit dit ondersteunt. De aanvraag en de eventuele bijlagen dienen ergens te worden geparkeerd. De aangeroepen functionaliteit haalt de aanvraag en eventuele bijlagen daar op. In Dordrecht zijn webformulieren beperkt tot uitsluitend webformulierspecifieke gegevens. De aangeroepen zaakfunctionaliteit vraagt om generieke gegevens, zoals de naw-gegevens en de vraag of signaleringen per email en/of sms gewenst zijn.
33.2 De zaakbak Na de intake heeft de zaak status 1. Via de zaakbak worden alle zaken van één zaaktype getoond. Een klik op de omschrijving van een zaak leidt tot het ‘zaak informatie’ scherm. Een andere naam voor de zaakbak is de taakbak of de inbak. Een taakbak lijkt meer bedoeld voor taken (stappen) die een behandelaar moet uitvoeren en is daarom meer geschikt voor workflowmanagementsystemen. Een inbak lijkt meer bedoeld om inkomende documenten te tonen en is daarom meer geschikt voor e-mailtoepassingen. De naam zaakbak sluit het best aan bij de functionaliteit in het zaaksysteem waarbij een overzicht van zaken wordt getoond. De kolom st geeft de status van de zaak weer. Status 1 wordt altijd in rood weergegeven, status 2 altijd oranje. De laatste status wordt altijd in groen weergegeven. De overige statussen in geel. De laatste kolom dl geeft de resterende doorlooptijd aan, gebaseerd op de servicenorm. Als er voldoende dagen beschikbaar zijn, wordt deze waarde in groen weergegeven. Bij minder beschikbare dagen wordt deze in oranje of in rood weergegeven.
63
De kolom behandelaar toont standaard de naam van het organisatieonderdeel. Maar medewerkers met toewijsautorisaties kunnen medewerkers toewijzen aan een zaak. In dat geval wordt de naam van de medewerker getoond. De zaakbak bevat tevens een aantal sneltoetsen: s met betrekking tot de signalen (rood betekent dat er ongelezen signalen aanwezig zijn) w met betrekking tot het wijzigen van de status o met betrekking tot het opschorten van de zaak (oranje betekent dat de zaak nu opgeschort is; rood dat de opgeschorte zaak aandacht behoeft), d met betrekking tot het dossier van de zaak a met betrekking tot de aanvraag van de zaak p met betrekking tot publicaties van de zaak (rood betekent dat de zaak nog niet gepubliceerd is) n met betrekking tot nog niet gelezen documenten in het dossier (rood betekent dat er ongelezen documenten aanwezig zijn) l met betrekking tot de locatie van de zaak (rood betekent dat aan de zaak nog geen locatie is gekoppeld)
64
Afbeelding 33a, de zaakbak
Behandelaars kunnen ook een totaaloverzicht aanroepen met zaken van alle zaaktypen, waarvoor men geautoriseerd is. De zaakbak is niet persoonlijk. Behandelaars kunnen dus altijd alle zaken zien. Men kan echter kiezen een selectie van alle zaken te laten zien, bijvoorbeeld alleen die zaken die aan de betreffende medewerker zijn toegewezen. Of alleen de nog niet afgehandelde zaken.
33.3 Het wijzigen van de status Binnen 24 uur moet de behandelaar de zaak accepteren (wijzigen naar status 2) of weigeren (waarbij de zaak uit deze zaakbak verdwijnt en terugkeert naar het postintake-overzicht). Bij het wijzigen van een status kan de checklist met ja/nee-vragen verschijnen en een standaardtekst t.b.v. signaleringen naar de klant. Deze standaardtekst kan door de behandelaar nog worden aangepast.
65
Afbeelding 33b, het wijzigen van de status van een zaak
Als de zaak ontvankelijk is (de aanvraag is volledig), wordt de zaak in behandeling genomen (wijzigen naar status 3). Bij het wijzigen naar de laatste status moet tevens een resultaat worden gekozen (bijvoorbeeld vergunning verleend of vergunning geweigerd). Voordat de laatste status is bereikt, kan men ook een bijzonder resultaat kiezen (bijvoorbeeld vergunning ingetrokken of geen vergunning nodig). De zaak wordt dan voortijdig afgehandeld.
33.4 Het opschorten van de zaak Er kan een reden zijn om een zaak op te schorten, bijvoorbeeld als de klant een onvolledige aanvraag heeft ingediend of als niet alle benodigde documenten zijn meegestuurd. In dat geval schort de behandelaar de zaak op, waarbij het verplicht is de reden op te geven. De opschorting wordt namelijk getoond als de klant de status van de zaak opvraagt. Aan de opschorting wordt geen termijn gehangen. Zodra de aanvraag volledig is, wordt de opschorting beëindigd. Het aantal dagen dat de opschorting duurt, wordt opgeteld bij de standaarddoorlooptijd van de zaak. De behandelaar is in staat ter 66
signalering een aantal dagen op te nemen. Als na het ingegeven aantal dagen de opschorting nog niet is beëindigd, krijgt de sneltoets een rode kleur.
Afbeelding 33c, het opschorten van een zaak
33.5 De naw-gegevens (gegevensmagazijn als basis) Bij de postintake wordt de aanvrager indien mogelijk gekoppeld aan burger- of bedrijfsgegevens uit het gegevensmagazijn. Gegevens van de gekoppelde burger of het gekoppelde bedrijf worden als xml-bestand weggeschreven, overigens nog een tweede keer na afhandeling van de zaak (zo ontstaat een zo compleet mogelijk beeld van de aanvrager binnen het dossier, dus los van het gegevensmagazijn). De adresgegevens worden automatisch overgenomen, maar kunnen door de postintakemedewerker worden gewijzigd, indien op de brief andere adresgegevens worden vermeld. De behandelaar ziet in dit geval zowel het correspondentieadres als het, volgens het gegevensmagazijn, officiële adres.
67
33.6 De locatie van de zaak Bij veel zaaktypen is de locatie relevant. Bij de configuratie van het zaaktype wordt vastgelegd of en zo ja, op welke manier, de locatie van een zaak kan worden vastgelegd: Door het koppelen van een adres Door het koppelen van een wijk Door het koppelen van een buurt Door het zetten van een punt Door het tekenen van een vlak (bijvoorbeeld in het geval van een terrein) Door het tekenen van een lijn (bijvoorbeeld in het geval van een optocht) Er zijn ook combinaties mogelijk.
Afbeelding 33d, de locatie van een zaak
33.7 Het zaakdossier Bij het toevoegen van een document aan een zaakdossier dient men allereerst het documenttype aan te geven. Afhankelijk van dit type kunnen extra kenmerken bij 68
het document worden vastgelegd naast de algemene kenmerken, zoals de naam, de omschrijving, de auteur, eventuele trefwoorden en het publicatieniveau (openbaar, besloten of beperkt toegankelijk).
33.8 Verzoek extern advies Vanuit het zaakdossier kunnen geselecteerde documenten aan derden worden gestuurd, bijvoorbeeld om advies aan te vragen. Derden ontvangen het verzoek om advies als e-mailbericht.
33.9 E-mailberichten in het zaakdossier Dordrecht gebruikt Groupwise als e-mailprogramma. Relevante e-mailberichten kunnen eenvoudig naar Mozaiek worden verplaatst via een speciaal Mozaiekicoon. De behandelaar kan de naam van het e-mailbericht in Mozaiek wijzigen. Door het zaaknummer te vermelden, verschijnt het e-mailbericht direct in het juiste zaakdossier.
33.10 Opvoeren besluit Bij het opvoeren van een besluit zijn vier datums relevant: Datum besluit betreft de datum waarop het besluit is genomen; Datum ingang betreft de datum waarop het besluit geldig wordt; Datum verval betreft de datum waarop het besluit niet langer geldig zal zijn; Datum verzonden betreft de datum waarop het besluit is verzonden naar de klant. De laatste datum is vooral relevant, als er bezwaar kan worden gemaakt. Op basis van deze datum wordt de uiterste datum berekend, waarop men bezwaar kan maken
69
33.11 Publicaties met betrekking tot de zaak
Afbeelding 33e, publicaties met betrekking tot een zaak
Zaken van een type, waarbij een publicatietekst is vastgelegd, worden op de website van de overheidsorganisatie zelf en op de website www.overheid.nl gepubliceerd, zodra de locatie van de zaak bekend is. Afhankelijk van het zaaktype worden ook de aanvraag en/of de bijlagen gepubliceerd. Besluiten binnen de zaak, waarbij een publicatietekst is vastgelegd, worden ook gepubliceerd. Ook hier worden, afhankelijk van het besluittype, documenten gepubliceerd, zodra deze in pdf-formaat beschikbaar zijn.
33.12 Signalen met betrekking tot de zaak De behandelaar kan een signaal vastleggen. Een signaal kan worden beschouwd als een e-mailbericht, gericht aan de zaak en/of medewerkers en/of derden, dat niet direct wordt verstuurd, maar op een vooraf opgegeven datum. Een signaal, gericht aan de zaak, verschijnt in de signaalbak van de zaak. Bij een ongelezen signaal wordt de sneltoets in de zaakbak rood.
70
33.13 Opnemen papieren documenten in het dossier Soms is het gewenst dat een scan van een papieren document in het zaakdossier wordt opgenomen. De behandelaar kan dit eenvoudig realiseren door bij het toevoegen van een document aan een dossier te kiezen voor de zogenaamde scanvelop functionaliteit. Men voert hierbij eerst op de gebruikelijke wijze alle kenmerken van het document in, zoals bijvoorbeeld het documenttype. Er verschijnt een voorblad met barcode, dat moet worden uitgeprint en samen met het papieren document moet worden verstuurd. Centraal worden al deze verzoeken gescand, waarna de scan als pdfdocument direct in het juiste dossier terecht komt. Totdat het document is gescand, wordt middels een grijs pdf-icoontje duidelijk gemaakt, dat het betreffende document binnenkort gescand zal worden.
Afbeelding 33f, opnemen papieren document in een dossier
71
33.14 Opnemen webdocumenten in het dossier Soms is het gewenst om snel een document in het zaakdossier op te nemen, zonder hiervoor een tekstverwerkingsprogramma te hoeven opstarten. Bijvoorbeeld in het geval van een telefoonnotitie. De behandelaar kan dit eenvoudig realiseren door bij het toevoegen van een document aan een dossier, te kiezen voor de zogenaamde webdocument functionaliteit. Men voert hierbij eerst op de gebruikelijke wijze alle kenmerken van het document in, zoals bijvoorbeeld het documenttype en daarna kan men direct via webfunctionaliteit het document samenstellen. Het document wordt vanuit het dossier als webpagina getoond.
33.15 Het verlengen van de zaak Wanneer er meer tijd nodig is om een zaak af te handelen, kan in sommige gevallen een verdagingbesluit worden genomen. De behandelaar kan in zo’n geval de zaak verlengen. Net als bij het opschorten van een zaak, moet er verplicht een reden worden opgegeven. De verlenging wordt namelijk getoond als de klant de status van de zaak opvraagt. Aan de verlenging wordt een termijn gehangen, die wordt opgeteld bij de standaard doorlooptijd zoals deze is gedefinieerd voor het betreffende zaaktype.
72
34 Functionaliteit zaaksysteem voor de klant Dit hoofdstuk schetst hoe via Mozaiek, het zaak/dossiersysteem van Dordrecht en de Drechtsteden, met klanten wordt gecommuniceerd over zaken. We onderscheiden hier: Communicatie openbare informatie Communicatie met de aanvrager
34.1 Communicatie openbare informatie
Afbeelding 34a, overzicht recente aanvragen en besluiten
Op de website worden automatisch alle recente aanvragen en besluiten getoond, zodra de locatie bekend is (vanwege het tonen op een kaart). De te publiceren documenten worden pas getoond, nadat het document in pdfformaat in het zaakdossier is opgenomen. Vanuit Mozaiek worden ook de publicaties op de landelijke website www.overheid.nl getoond.
73
34.2 Communicatie met de aanvrager De klant krijgt na het versturen van het webformulier en via een ontvangstbevestiging het unieke zaaknummer te zien.
Afbeelding 34b, zaakinformatie
Via www.dordrecht.nl/zaakinfo kan men de status van de zaak opvragen. Tevens wordt getoond hoe het staat met de doorlooptijd, waarbij de uiterste datum wordt genoemd, waarop de gemeente de zaak moet hebben afgehandeld. Hierbij wordt rekening gehouden met eventuele perioden van opschorting en/of verlenging van de zaak. In de ontvangstbevestiging wordt tevens een pincode genoemd, waarmee men meer informatie over de zaak kan krijgen. Hiertoe kan men ook de DigiD code gebruiken. Men krijgt tevens meer mogelijkheden. Zo kan men een e-mailadres en/of mobiel telefoonnummer opgeven en aangeven dat men via e-mail en/of sms op de hoogte wil worden gehouden van statuswijzigingen over de zaak. Ook kan men reageren op de zaak door een vraag of opmerking te versturen, eventueel met een document als bijlage. Deze reactie wordt uiteraard direct in het
74
juiste zaakdossier geplaatst. In de zaakbak krijgt de sneltoets ‘ongelezen documenten’ een rode kleur.
Afbeelding 34c (hierboven), meer informatie over de zaak Afbeelding 34d (volgende pagina boven), signaleringen via e-mail en/of sms Afbeelding 34e (volgende pagina onder), reageren met betrekking tot een zaak
75
76
35 Checklist aanbod functionaliteit zaaksysteem Wordt de in dit document beschreven visie gedeeld door leveranciers en is de daarbij behorende functionaliteit in hun oplossing beschikbaar? Door leveranciers te vragen onderstaande checklist in te vullen, kan daar snel inzicht in worden verkregen. Om de oplossing van een leverancier met het bij de Drechtsteden in gebruik zijnde Mozaiek te kunnen vergelijken, is de checklist voor Mozaiek ingevuld. In de tweede kolom staat vermeld in welk hoofdstuk meer informatie over de betreffende functionaliteit is terug te vinden. In de derde kolom kan een kruisje gezet worden als de functionaliteit niet aanwezig is. In de laatste kolom kan een kruisje gezet worden als de functionaliteit in productie is bij minimaal drie verschillende organisaties. In de vierde kolom kan een kruisje gezet worden als de functionaliteit wel aanwezig is, maar nog niet in productie is bij minimaal drie verschillende organisaties.
77
78
36 Implementatie organisatiebreed zaakgericht werken Het implementeren van organisatiebreed zaakgericht werken vereist een project dat wordt uitgevoerd door een multidisciplinair team. De beste resultaten worden bereikt als het verbeteren van de dienstverlening als uitgangspunt wordt genomen. Een fasering per kanaal ligt voor de hand. Door eerst alle aanvragen via de website met het zaaksysteem af te handelen, bereikt men klanten die graag de voortgang van de zaak via de website of via e-mailberichten willen volgen. Bovendien geeft aandacht voor dit kanaal weinig weerstand bij bestaande organisatieonderdelen, omdat de verantwoordelijkheid voor dit kanaal vaak nog niet bij één organisatieonderdeel is belegd. Vervolgens kan het kanaal post in het zaaksysteem worden opgenomen. Omdat een bestaand organisatieonderdeel (DIV) zich verantwoordelijk voelt voor dit kanaal, is de kans op weerstand groter. Dit speelt ook als men kaartfunctionaliteit in het zaaksysteem wil opnemen. Dit raakt de taken van het organisatieonderdeel dat zich verantwoordelijk voelt voor geoinformatievoorziening. Een oplossing voor dit probleem is alle informatievoorzieningtaken te integreren in één organisatieonderdeel. I-adviseurs, medewerkers documentaire informatievoorziening (DIV) en medewerkers geoinformatievoorziening zouden één afdeling ‘Informatie en Proces Management’ kunnen vormen. Een belangrijke taak van deze afdeling is het inrichten van zaaktypen en het verbeteren van de inrichting, zodat steeds meer organisatieonderdelen het generieke zaaksysteem zo optimaal mogelijk gaan gebruiken. Om te voorkomen dat bij het verbeteren van de informatievoorziening techniek teveel aandacht krijgt, is het wenselijk de taken Informatievoorziening en Automatisering te scheiden. Als deze taken gecombineerd worden, krijgen problemen op technisch gebied altijd de volledige aandacht, wat ten koste gaat van het verbeteren van de informatievoorziening. Automatisering kan daarom beter in een aparte afdeling ‘Computer- en Netwerkbeheer’ worden ondergebracht. Een fasering per proces is ook goed mogelijk. Door te starten met de processen van de afdelingen, die enthousiast zijn over het concept van zaakgericht werken, is de kans op een succesvolle start van de implementatie groot. Dit resultaat kan later helpen bij de implementatie bij de aanvankelijk minder enthousiaste afdelingen. Veel overheidsorganisaties werken momenteel aan het inrichten van een Klant Contact Centrum (KCC). Dit nieuwe organisatieonderdeel wordt verantwoordelijk 79
voor alle klantcontacten en de dienstverlening van de organisatie. Het spreekt voor zich dat dit organisatieonderdeel er veel belang bij heeft dat alle organisatieonderdelen zoveel mogelijk gebruik gaan maken van generieke functionaliteit, zoals het zaaksysteem. Het is verstandig bij de implementatie van zaakgericht werken de leiding van het KCC een prominente rol te geven. Als een overheidsorganisatie werkt aan een Shared Service Center(SSC) voor interne dienstverlening, ligt het voor de hand ook de leiding van het SCC prominent bij de implementatie van zaakgericht werken te betrekken. Een zaaksysteem biedt de mogelijkheid behandelaars te controleren en te sturen bij hun werkzaamheden. Processpecialisten en kwaliteitsmedewerkers hebben soms de neiging hierin door te schieten. Onnodig veel controle geeft veel weerstand bij behandelaars. Het wordt als betuttelend ervaren als het systeem te streng is geconfigureerd en vraagt of een bepaalde actie is uitgevoerd, als deze actie zó voor de hand liggend is, dat deze nooit wordt vergeten. Men verhoogt het draagvlak bij behandelaars door het aantal statustypen en vragen op de checklists als invoeringsstrategie te beperken tot de strikt noodzakelijke. Het is in een later stadium immers eenvoudig mogelijk een vraag alsnog aan een checklist toe te voegen. Gebleken is dat organisatiebreed zaakgericht werken eenvoudiger te implementeren is bij organisaties die niet te groot en niet te klein zijn. Met minder dan duizend medewerkers, ontbreken vaak de kennis en middelen voor een succesvolle implementatie. Met veel meer dan duizend medewerkers heeft men vaak te maken met machtige kokers, die geen boodschap hebben aan organisatiebrede ambities. In het eerste geval ligt samenwerking met andere overheidsorganisaties voor de hand. In het tweede geval kan men het best starten met een afgebakend deel van de organisatie.
80
37 Implementatie overheidsbreed zaakgericht werken Na het verplicht gebruik van landelijke basisregistraties door overheidsorganisaties, zou een volgende stap moeten zijn: het verplicht gebruiken van één organisatiebreed zaaksysteem door elke overheidsorganisatie. Met deze verplichting zullen meer leveranciers aan de slag gaan om generieke organisatiebrede zaaksystemen op de markt te brengen. Het aantal overheidsorganisaties is genoeg voor voldoende concurrentie op deze markt. De zaaksystemen van de verschillende leveranciers dienen op basis van open standaarden te kunnen samenwerken met elkaar. De ene overheidsorganisatie (de gemeente die een evenementenvergunning behandelt) moet eenvoudig een subzaak bij een andere overheidsorganisatie (de politie die moet adviseren over deze vergunning) kunnen starten. Vanuit het ene zaaksysteem moet de subzaak uit een ander zaaksysteem te volgen zijn, alsof de subzaak in hetzelfde zaaksysteem zou zijn ondergebracht. Het is daarnaast vereist dat landelijke initiatieven de architectuur van zaakgericht werken omarmen en geen functionaliteit voorschrijven of zelfs ontwikkelen, die bij overheidsorganisaties tot de verzameling generieke functionaliteit behoort. Een goed voorbeeld hoe het niet moet is de landelijke voorziening Omgevingsloket Online (OLO), waarbij het ministerie van VROM zaak- en dossierfunctionaliteit aanbiedt, die specifiek is voor de omgevingsvergunning. Het argument dat nog niet alle organisaties over een zaaksysteem beschikken, mag voor ministeries geen reden zijn voor elk proces zelf zaak- en dossiersystemen te ontwikkelen. Daarmee lossen we de problemen van de verkokerde informatievoorziening bij overheidsorganisaties niet op, maar creëren we nieuwe verkokerde informatievoorziening op landelijk niveau. VROM had beter overheidsorganisaties kunnen verplichten over een zaak- en dossiertoepassing te beschikken, die optimaal kan samenwerken met het Omgevingsloket Online. Het door de landelijke overheid verplichten tot het gebruik van één organisatiebreed zaaksysteem door elke overheidsorganisatie, zorgt er voor dat alle informatievoorzieningsprojecten met deze architectuur rekening gaan houden en draagt daarom bij aan het ontkokeren en verbeteren van de informatievoorziening van de gehele overheid
81
