Architectuur Model Gemeentelijke E-Dienstverlening

Transcriptie

1 Architectuur Model Gemeentelijke E-Dienstverlening Project Referentiemodel Midoffice ten behoeve van Gemeenten Auteurs: EGEM werkgroep Midoffice Versie: 0.9 Datum: Pagina 1

2 Inhoudsopgave 1. Inleiding Aanleiding Werkgroep Midoffice Leeswijzer Schets bestaande E-Dienstverlening Inrichting van de Backoffice Inrichting van de Frontoffice Noodzaak van een Midoffice Architectuurbenadering Bedrijfsarchitectuur Midoffice Inleiding Procesmodel Dienstverlening Levering en ontwikkeling Gegevensverzamelingen Elektronische dienstverlening Kanalen Classificeren klantvraag Assisteren en informeren klant Registreren zaak Beheren zaak Behandelen zaak Informatie architectuur Midoffice Architectuurprincipes Applicatie architectuur Kanalen Classificeren Klantvraag Assisteren en Informeren Klant Registreren Zaak Beheren Zaak Behandelen Zaak Service klassen De rol van Business Process Management Het zakensysteem als centrale spil De rol van de Dienstenbus Inrichting van de frontoffice Invulling met standaard componenten Technische architectuur Midoffice Applicatie Integratie Webservices Pagina 2

3 6.3. Koppelingen Broker Dienstenbus StUF Portaal Transitiestrategie voor het Midoffice Stadia van het Midoffice Eén Loket (Multi-Channel) Organisatorisch Midoffice Technisch Midoffice Midoffice conform Service Georiënteerde Architectuur Routeplan Korte termijn Middellange termijn Lange termijn Scenario s Bijlage A. Midoffice Woordenboek Bijlage B. Lijst Services Midoffice Bijlage C. Functionaliteiten versus Diensten Pagina 3

4 1. Inleiding 1.1. Aanleiding Gemeenten worden geconfronteerd met een groot aantal veranderingen. Deze veranderingen worden deels veroorzaakt door de wens om de burger beter van dienst te zijn door een grotere toepassing van moderne media, zoals het internet. Voor een ander deel worden de veranderingen veroorzaakt door het beschikbaar stellen vanuit de centrale overheid van het stelsel Basisregistraties, die een efficiëntere en kwalitatief betere dienstverlening mogelijk maken. Gemeenten zijn traditioneel georganiseerd rondom een stelsel van backoffice systemen welke vanuit een vakgerichte benadering de dienstverlening aan de burger gestalte geven. Deze vakgerichte benadering staat ter discussie bij de introductie van de nieuwe basisregistraties. Vanuit de wens om de burger beter van dienst te willen zijn, ontstaat de behoefte om de frontoffice bij gemeenten in te richten op een wijze, die beter aansluit bij de belevingswereld van de burger. Uit de twee hierboven beschreven trends ontstaat een spanningsveld. De klantgerichte frontoffice moet immers afgestemd worden met de vakgerichte backoffice. Deze draaiing is het werkterrein van de midoffice. Omdat zowel het backoffice als het frontoffice sterk in beweging zijn ontstaat de behoefte aan het geven van richting aan de inrichting van de midoffice. Het in dit document besproken Referentiemodel Midoffice heeft als doel om deze richting aan te geven. Gemeenten kunnen dit model gebruiken bij het inrichten van hun midoffice. Het model geeft de scope van de midoffice weer in relatie tot de processtappen binnen de gemeentelijke organisatie. Het gaat dan bijvoorbeeld om alle processtappen die nodig zijn om een verhuizing of vergunningaanvraag te verwerken Pagina 4

5 1.2. Werkgroep Midoffice Dit document is het resultaat van de EGEM werkgroep Midoffice. Aan de totstandkoming van het in dit document neergelegde resultaat hebben de volgende personen meegewerkt: Chris Batist, gemeente Den Haag Charley Beekhuizen, gemeente Den Haag Alexander Bijl, EGEM Gerwin Bolt, EGEM Mark van den Broek, EGEM John Brus, gemeente Delft Corné Dekker, gemeente Dordrecht Raymond van Erkel, gemeente Amsterdam Menno Gmelig Meijling, gemeente Amsterdam Sietse de Haan, gemeente Arnhem Marrie Hol, gemeente Zwolle Elka Helmers, EGEM Peter Keijzers, gemeente Tilburg Marijke Salters, gemeente Rotterdam Gerrit Slot, EGEM Frits Smit, gemeente Zoetermeer Jan van de Straat, gemeente Haarlem 1.3. Leeswijzer Dit document is als volgt opgebouwd: Hoofdstuk 2 geeft een beeld van de problematiek rondom elektronische dienstverlening en geeft de rationale voor de noodzaak van een midoffice; Hoofdstuk 3 gaat kort in op de gebruikte Architectuurbenadering Architectuurmodel electronische overheid (ELO); Hoodstuk 4 behandelt het procesmodel Midoffice zoals dit door de EGEM werkgroep Midoffice is ontwikkeld; Hoofdstuk 5 gaat in op de Informatie Architectuur conform een Service Georiënteerde Architectuur; Hoofdstuk 6 beschrijft in het kort de technische componenten die in een midoffice oplossing een rol spelen; Hoofdstuk 7 tenslotte geeft een beeld van de overgang van de huidige E- Dienstverleningspraktijk naar een volledig elektronische dienstverlening conform een Service Georiënteerde Architectuur Pagina 5

6 2. Schets bestaande E-Dienstverlening In het ideale geval bestaat er een directe koppeling tussen de dienstverlening in de frontoffice en de afhandeling van de aanvragen in de backoffice. In de praktijk is dit niet zo eenvoudig als het lijkt. Iedere gemeentelijke dienst heeft zijn eigen applicaties. De onderlinge koppeling tussen al deze geautomatiseerde systemen blijkt vaak een probleem. Gemeenten zien zich met betrekking tot het aanbieden van elektronische dienstverlening dan ook voor de volgende uitdagingen geplaatst: Hoe krijg je het voor elkaar dat aanvragen van burgers of bedrijven via de gemeentelijke website goed in de systemen van de juiste gemeentelijke dienst terecht komen; Hoe krijg je deze informatie tussen systemen van vaak verschillende gemeentelijke diensten en ketenpartners goed uitgewisseld en hoe zorg je ervoor dat alle systemen over de dezelfde informatie beschikken; Hoe verschaf je de aanvrager inzicht in wat met zijn aanvraag gebeurt; Hoe kan de ambtenaar de status van alle door hem te behandelen aanvragen en informatieverzoeken volgen. Het midoffice moet hier een oplossing voor bieden. Deze fungeert als een draaischijf tussen een klantgerichte voorkant en een vakgerichte achterkant. In dit hoofdstuk wordt de problematiek aan de orde gesteld om de doelstellingen van de gemeente uit te voeren om met de bestaande architectuur dit midoffice te realiseren Inrichting van de Backoffice De inrichting van gemeentelijke backoffices wordt gekenmerkt door een statisch applicatielandschap, dat is ingericht rondom de ondersteuning van vakafdelingen voor specifieke gebieden van zorg. Zo kent elke gemeente een Dienst Burgerzaken, een Dienst Sociale Zaken enzovoort. Elk van deze diensten worden ondersteund door een applicatiesysteem, dat specifiek is toegerust voor de taken van zo n dienst. Daarbij wordt meestal geen onderscheid gemaakt tussen gegevens, die voor het uitvoeren van taken van de dienst noodzakelijk zijn en gegevens, die een breder toepassingsgebied binnen een gemeente kennen. Deze inrichting is ontstaan in een tijd dat het normaal was dat een burger of bedrijf die een dienst van een gemeente wenste af te nemen, zich daarvoor diende te melden bij het juiste loket. De ondersteunende applicatiesystemen voor deze diensten omvatten dan meestal ook deze loket functionaliteit. Integratie van deze backoffices is meestal ver te zoeken. Het is niet ongebruikelijk, dat elke backoffice er bijvoorbeeld zijn eigen persoonsregistratie op na houdt. Ook andere gegevens (adressen, gebouwen, percelen, uitkeringen, etc.) kunnen slechts moeizaam met elkaar worden gedeeld Pagina 6

7 2.2. Inrichting van de Frontoffice Zowel vanuit de burger en het bedrijfsleven, maar ook vanuit de overheid zelf komt de wens om het contact tussen overheid en burger/bedrijf te verbeteren. Vanuit de burger en het bedrijfsleven zijn daarvoor de volgende oorzaken aan te wijzen: Een grotere bekendheid met elektronische dienstverlening via het internet vergroot de wens om ook met de overheid op deze eenvoudiger manier zaken te kunnen doen; De roep om administratieve lastenverlichting vanuit de burger, maar vooral vanuit het bedrijfsleven, stelt grotere eisen aan het elektronisch uitwisselen van gegevens. Vanuit de overheid komt ook een sterke wens tot verbetering van het contact met burger en bedrijf. Deze wens komt voort uit: 1. De wens van burger en bedrijfsleven; 2. Het efficiënter willen werken met gemeenschapsgelden; 3. Flexibeler in te kunnen spelen op veranderingen in wetgeving; 4. Het voorkomen van fraude. Zowel de agenda s van burger en bedrijfsleven als de overheid bevatten op deze wijze de wens om de interactie tussen overheid en burger/bedrijf via nieuwe elektronische media te willen vereenvoudigen. Dit vereist een geheel nieuwe denkwijze vanuit de overheid. Deze interactie dient om succesvol te zijn veel meer te worden ingericht vanuit het denken van de klant (de burger en het bedrijfsleven) dan vanuit de vastgestelde wet- en regelgeving. De loketfunctionaliteit in de bestaande backoffices is daarvoor niet toereikend. Veel gemeenten hebben inmiddels dan ook al een reorganisatieslag van hun frontoffice achter de rug, waarbij het frontoffice veel meer, dan tevoren, wordt ingericht op een klantgerichte manier, waarbij meestal een website is ingericht om ook via dit kanaal de burger en het bedrijf te kunnen bereiken Noodzaak van een Midoffice Zodra de overheid aan de slag gaat met de herinrichting van haar frontoffice ontstaat al gauw zicht op het probleem om dit nieuwe frontoffice afgestemd te krijgen op de bestaande backoffices. Dit probleem is als volgt inzichtelijk te maken: 1. De frontoffice wordt heringericht volgens een werkwijze, die zo goed mogelijk aansluit bij de belevingswereld van de klant; 2. De backoffice is nog steeds georganiseerd rondom de vakkennis van de bestaande reeks diensten, zoals Burgerzaken, Sociale Zaken enz. Er ontstaat hierdoor een afstemmingsprobleem tussen de ene wereld en de andere. Voorheen werd deze vertaalslag overgelaten aan burger en bedrijf. Het feit, dat zij daar een probleem mee kregen geeft eens te meer aan, dat het ook voor de overheid niet eenvoudig op te lossen is. Binnen het gedachtegoed van OL2000 ontstond het besef van een midoffice. Een specifiek organisatie onderdeel, dat zorg moet dragen voor het afstemmen van de frontoffice op de backoffice. Een reorganisatie ( kanteling ) van de organisatie zelf is nodig om de verbinding van Pagina 7

8 de processen tussen front- en backoffice tot stand te brengen. Deze kanteling wordt bemoeilijkt, doordat het niet eenvoudig blijkt om de ondersteunende ICT systemen in de backoffices te veranderen in systemen, die ook de midoffice ondersteunen. Een aantal factoren speelt hierbij een rol: 1. De bestaande backoffice systemen zijn veelal pakket oplossingen van een beperkt aantal leveranciers, die behoefte hebben aan een groot aantal wijzigingen in hun pakketten, die per gemeente bovendien sterk verschilden; 2. De bestaande backoffice systemen kennen geen gestandaardiseerde open interfaces, zodat het niet eenvoudig is om uitbreidingen op de bestaande pakketten te realiseren voor ondersteuning van de midoffice; 3. Er is weinig eenheid in de wijze, waarop deze backoffice systemen hun interface met de gebruiker hebben ingericht. Het combineren van meerdere applicaties op één beeldscherm blijkt daarbij onmogelijk. Inmiddels heeft de gemeentelijke wereld reeds enige jaren ervaring opgedaan met de (on)mogelijkheden om bestaande backoffices aan te passen de nieuwe eisen in de frontoffice. De meeste van deze initiatieven lopen stuk op de hierboven genoemde factoren. Om deze reden het de werkgroep Referentiemodel Midoffice, geïnitieerd vanuit EGEM, zich gestort op het probleem om een begaanbaar pad te ontwikkelen om deze problematiek op te lossen. De volgende hoofdstukken zijn de weerslag van hun bevindingen Pagina 8

9 3. Architectuurbenadering Leidraad voor het opstellen van het referentiemodel Midoffice is het Architectuurmodel electronische overheid (ELO) uit het rapport Architectuur Elektronische Overheid 1. Het Architectuurmodel dient drie doelen: 1. gemeenschappelijke taal en referentiekader: gebleken is dat er binnen de Nederlandse overheid op het gebied van architectuur veel verschillende modellen en referentiekaders worden gebruikt. Een allesomvattend model voor de elektronische overheid, beschreven in één consistente taal, ontbreekt, terwijl de behoefte hieraan groot is. Het Architectuurmodel beoogt invulling te geven aan deze behoefte. 2. inzicht in functionele (on)mogelijkheden: het Architectuurmodel geeft een overzicht van en inzicht in functionele (on)mogelijkheden van relevante informatie en communicatietechnologie (ICT). 3. aanreiken van technische "bouwblokken : Het Architectuurmodel kan beschouwd worden als een "bouwdoos" die bestaat uit een gestructureerde verzameling "bouwblokken" waaruit de feitelijke architectuur volledig en in samenhang kan worden samengesteld Het model ziet er als volgt uit: Figuur 1: Architectuur Matrix 1 Dit rapport kan worden gedownload vanaf de volgende link: Pagina 9

10 Daarbij wordt vanuit een context een eerste benadering van het onderwerp van studie verkregen. In de werkgroep is dit vormgegeven door het samenstellen van een midoffice begrippen woordenboek (Bijlage A). Vervolgens wordt een procesmodel gemaakt van de primaire processen in het gebied van studie, in dit geval een gemeente. Dit heeft geleid tot het overzichtsschema, dat verderop in dit hoofdstuk wordt uitgelegd. Vervolghoofdstukken nemen vervolgens een deel van de overige kolommen nader onder de loupe. Het procesmodel wordt daartoe vertaald in een informatie architectuur. Deze wordt vervolgens ingevuld met informatiesystemen. De Technologie infrastructuur is niet verder uitgewerkt, omdat het landschap per gemeente hiervoor te verschillend is. Bedrijfs architectuur Op deze laag herkennen we de aspect architecturen organisatie architectuur, product architectuur en proces architectuur. Actuele thema s bij de bedrijfsarchitectuur zijn doelstellingen (strategie), politiek en beleid, maar ook reorganisatie en herinrichting van processen, bijvoorbeeld als gevolg van nieuwe technologische mogelijkheden. Informatie architectuur Hier gaat het om het zogenaamde functionele beheer van applicaties, van processen (workflow) en van informatie (gegevens- en documentbeheer). Technische architectuur Hier concentreren we ons op de ICT infrastructuur, opgesplitst in de systeem architectuur, de gegevensarchitectuur en de netwerk architectuur. In feite herkennen we hier de aloude driedeling binnen de ICT: gegevensverwerking, gegevensopslag en gegevenstransport. Naast de drie lagen en de drie aspecten, die samen de negen architectuur aspecten bepalen, zijn er nog twee generieke dimensies: beveiliging en beheer. Beveiliging Hier kunnen we weer naar alle drie lagen kijken. Bij de bedrijfslaag gaat het bijvoorbeeld om de veiligheid van medewerkers, producten en bedrijfsprocessen. Op de middelste laag ligt de nadruk op de informatiebeveiliging: van applicaties (beschikbaarheid), van gegevens (integriteit) en van de communicatie (vertrouwelijkheid). Op de onderste laag (techniek) spreken we over authenticatie (PKI etc) en encryptie, naast de fysieke aspecten als firewalls etc. Beheer Beheer is een van de belangrijkste dimensies uit het rijtje Strategie ( richten ), Ontwerp ( inrichten ) en Beheer ( verrichten ). Op de bovenste laag van beheer (bedrijfs architectuur) gaat het dan om zaken als relatiebeheer, beheer van de administratieve organisatie en om kwaliteitsbeheer met betrekking tot het product of dienst. Hier spelen vaak ook veiligheids (en vertrouwens) aspecten mee. Op de middelste laag (informatie architectuur) gaat het om het zogenaamde functionele beheer van applicaties, van processen (workflow) en van informatie (gegevens- en documentbeheer). Op het laagste Pagina 10

11 niveau (technische architectuur) gaat het in het bijzonder om het technische beheer van hardware (clients, servers), software (versiebeheer etc.), en netwerkbeheer (inclusief netwerk beveiliging, zoals firewals, etc.). Voor een gedetailleerde beschrijving van het Architectuurmodel ELO wordt verwezen naar het document Architectuur Electronische Overheid. In het kader van de werkzaamheden van de Werkgroep Referentiemodel Midoffice is primair de laag Bedrijfsarchitectuur uitgewerkt, namelijk die van de primaire bedrijfsprocessen, de procesarchitectuur. Wel zijn er raakvlakken met de twee andere lagen aan de orde geweest, maar die hebben niet geleid tot een formele invulling van het model. In een vervolgactiviteit kunnen deze lagen verder worden uitgewerkt. Bij het opzetten van het referentiemodel Midoffice is allereerst gekeken naar proces van de gehele gemeente op hoofdlijnen. In dit rapport wordt het resultaat hiervan in de vorm van een procesmodel gepresenteerd. In het volgende hoofdstuk wordt op grond van een overzichtsschema stapsgewijs ingezoomd op de processen, die de werkgroep Referentiemodel Midoffice het meest wezenlijk vindt voor de problematiek rond het midoffice Pagina 11

12 4. Bedrijfsarchitectuur Midoffice 4.1. Inleiding Binnen de NORA 2 worden gemeenten, zoals ook andere overheidsinstellingen op het hoogste niveau, gekenschetst door een indeling in drieën, zoals hieronder getoond: Figuur 2: zienswijze NORA, gemeenten kunnen opgedeeld worden in een frontoffice, midoffice en backoffice De indeling in frontoffice, midoffice en backoffice is ook binnen gemeenten niet nieuw. De centrale vraag daarbij is echter op welke wijze vooral de midoffice haar taak kan vervullen als intermediair tussen front- en backoffice. Teneinde zicht te krijgen op de benodigde functionaliteit in de midoffice zijn als eerste stap de besturingsprocessen in kaart gebracht, zoals deze binnen een gemeente kunnen worden gehanteerd om de huidige organisatie m.b.t. dienstverlening te ondersteunen in het realiseren van een klantgericht frontoffice en de afhandeling van klantvragen in de huidige backoffice. Dit heeft geresulteerd in een procesmodel wat in de volgende paragrafen wordt uitgelegd. In het volgende hoofdstuk (5) zal dit procesmodel vervolgens worden uitgewerkt naar een informatiemodel. 2 Afkorting voor Nederlandse Overheids Referentie Architectuur Pagina 12

13 4.2. Procesmodel Hieronder zijn de besturingsprocessen voor de gemeentelijke dienstverlening uitgewerkt. Dit resulteert in onderstaand overzichtsschema: Figuur 3: Procesmodel Gemeentelijk Dienstverleningsproces Bij dit schema hoort een toelichting. Deze wordt in dit hoofdstuk per hoofdgroep beschreven. De hoofdgroeperingen zoals deze in het schema staan weergegeven zijn: Procesmanagement. Het gemeente onderdeel, waarin op grond van externe en interne informatie het beleid wordt vastgesteld voor het interne functioneren van de gemeente. Beleid kan uiteraard ook andere aspecten omvatten, maar voor het doel van dit processchema is deze omschrijving voldoende. Dit proces heeft een duidelijk raakvlak met de beheer kolom uit het ELO Architectuurmodel, maar is niet verder gedetailleerd. Dienstverlening. In dit proces worden alle processen uitgevoerd, die te maken hebben met het honoreren van verzoeken om dienstverlening door de buitenwereld, burgers en bedrijven. Het initiatief voor de uitvoering van deze processen is dus extern. Levering en ontwikkeling. In dit proces worden alle processen gebundeld, die te maken hebben met het primaire proces van de gemeente, waarin het initiatief bij de gemeente ligt. Het initiatief voor het uitvoeren van de processen is dus intern Pagina 13

14 Gegevensverzamelingen. Het betreft hier de totale set van gegevens op grond waarvan en met behulp waarvan de operationele processen binnen de gemeente worden uitgevoerd. Het hoofdproces Dienstverlening is in het schema uitgedetailleerd in een aantal subprocessen, waarmee de relaties tussen de hoofdprocessen inzichtelijk worden gemaakt Dienstverlening Gemeenten hebben te maken met de uitvoering van een groot aantal taken. Voor ieder van deze taken hebben de meeste gemeenten een organisatorisch verband gerealiseerd, die primair verantwoordelijk is voor het uitvoeren van de taak. Daarbij zijn deze taken geordend op overeenkomsten in de benodigde kennis voor de uitvoering van deze taken. Het resultaat is een organisatie, die in de taakuitvoering vooral vakgericht is opgebouwd. Bij het verlenen van diensten aan burgers en bedrijven willen gemeenten vooral inspelen op de eigen belevingswereld van burgers en bedrijven. Daarbij staat de vraag van de burger of het bedrijf centraal. De wijze waarop gemeenten hun taken hebben geordend en georganiseerd speelt daarbij voor burger en bedrijf geen rol. Het gevolg van enerzijds de vraagoriëntatie in de frontoffice en anderzijds de vakgerichte organisatiewijze van de meeste gemeenten levert een spanningsveld op. De vraag van burger en bedrijf dient te worden vertaald naar een geschikte vraagstelling voor de vakgericht backoffice. Het omvormen en bewaken van deze vertaalslag is het werkterrein van de midoffice. Teneinde de hierboven beschreven problematiek in kaart te brengen heeft de werkgroep Midoffice zich bij het opstellen van het procesmodel niet beperkt tot alleen de midoffice. Het procesmodel bevat elementen van de frontoffice, de midoffice en de backoffice. Bij de verdere uitwerking van het hoofdproces Dienstverlening is daarbij vooral de aandacht uitgegaan naar het vormgeven van de besturing, ofwel de vertaling van de klantvraag in een afhandeling van de zaak. De uitwerking richt zich op het zichtbaar maken van de besturing van de uitvoering van primaire processen, zoals het verlenen van een Bouwvergunning. Er is derhalve geen inventarisatie gemaakt van alle voor een gemeente relevante primaire processen. Hiervoor zijn binnen gemeenten reeds vele onderzoeken verricht. Deze worden in EGEM verband samengevoegd tot een voor alle gemeenten geldende inventarisatie. Globaal kan gesteld worden, dat ieder van de Gemeentelijke producten een daarbij behorend primair proces heeft, waarmee het product geleverd kan worden. De subprocessen in dit hoofdproces zijn: 1. Kanalen De klant kan zijn vraag via verschillende ingangen stellen. Het proces kanalen verwerkt de verschillende vraagvormen tot een uniforme klantvraag. Afhankelijk van de specifieke eigenschappen van het kanaal worden subprocessen uitgevoerd om de klantvraag te uniformeren. Het eindresultaat van het proces is een klantvraag in een uniform formaat, waardoor deze door de overige processen kunnen worden behandeld Pagina 14

15 Voorbeelden: Een binnengekomen poststuk wordt eerst gescand en als elektronisch document opgeslagen. Tevens worden indicatieve gegevens m.b.t. het poststuk en de afzender bij het document opgeslagen. Een binnengekomen telefoontje wordt door een callcenter medewerker aangenomen. De vraag wordt elektronisch vastgelegd en voorzien van indicatieve gegevens. Een binnengekomen webformulier wordt elektronisch omgevormd tot hetzelfde formaat, waarop ook andere vragen worden vastgelegd. Een binnengekomen vraag via een Voice Response Systeem wordt elektronisch omgevormd tot hetzelfde formaat als de andere kanalen. Het proces Kanalen is tevens verantwoordelijk voor het formuleren van het antwoord op de vraag in een formaat dat past bij het betreffende kanaal. Voorbeelden: Het antwoord op een brief wordt afgedrukt op briefpapier en via een enveloppenproces verstuurd naar de afzender van de brief. Een vraag via de telefoon wordt door de callcenter medewerker afgehandeld door het antwoord telefonisch te geven. Een binnengekomen webformulier leidt tot het creëren van een zaak. Een antwoord op het aanmelden van een zaak leidt tot een webpagina met daarop het zaaknummer en de status, die de zaak op dat moment heeft. Tevens wordt informatie gegeven over de wijze, waarop de klant de zaak kan volgen. Een vraag via het VRS wordt beantwoordt door een boodschap af te spelen via de telefoon, waarop de relevante antwoorden zijn vermeld. 2. Classificeren klantvraag Na binnenkomst van een geüniformeerde klantvraag alle voorbereidende werkzaamheden uit te voeren voordat de klantvraag als zaak kan worden vastgelegd. Klantvragen die betrekking hebben op een verzoek om assistentie of informatie worden doorgegeven aan het proces Assisteren en informeren klant. Vragen met een formeel karakter worden doorgegeven aan het proces Registreren zaak. Vragen, die niet geclassificeerd kunnen worden, worden door het proces Assisteren en informeren klant afgehandeld. Voorbeelden: De klant vraagt om informatie m.b.t. de te volgen procedure bij het bouwen van een dakkapel. Classificeren klantvraag beoordeelt deze aanvraag als een informatievraag en stuurt de vraag door naar Assisteren en Informeren Klant Pagina 15

16 De klant vraagt via een webformulier een lichte bouwvergunning aan voor het bouwen van een dakkapel. Classificeren klantvraag beoordeelt deze aanvraag als een Zaak en stuurt de vraag door naar Registreren Zaak. 3. Assisteren en informeren klant Het proces assisteren en informeren klant helpt de klant bij het beantwoorden van zijn/haar vraag. Hiertoe staan verschillende hulpmiddelen ten dienste, zoals zoekfunctionaliteit, een productencatalogus, een geleide zoekprocedure (vraagtrechter) etc. Voorbeelden: De klant vraagt om informatie m.b.t. de te volgen procedure voor het bouwen van een dakkapel. Via de productcatalogus presenteert Assisteren en Informeren klant de gevraagde informatie. De klant vraagt om de procedure te starten voor het aanvragen van een lichte bouwvergunning voor het bouwen van een dakkapel. Assisteren en Informeren klant biedt een webformulier aan vanuit de productcatalogus en vult de klantgegevens reeds vooraf in op grond van informatie uit de basisregistratie personen. Indien de klantgegevens niet bekend zijn (klant is niet ingelogd in de website) vraagt Assisteren en informeren via DigiD eerst om authenticatie informatie teneinde het formulier te kunnen vullen met klantgegevens. 4. Registreren zaak Indien de vraag is geclassificeerd als een verzoek om afhandeling van een zaak, wordt hiertoe een Zaak geregistreerd. Dit registratieproces houdt in, dat wordt beoordeeld of er voldoende informatie voorhanden is om de Zaak in behandeling te nemen. Tevens wordt een initiële toewijzing van een Zaaktype uitgevoerd d.m.v. de Zaaktype catalogus. Vervolgens wordt de geregistreerde Zaak in beheer genomen door het proces Beheren Zaak. Voorbeeld: De klant heeft gevraagd om het starten van de aanvraagprocedure lichte bouwvergunning voor het bouwen van een dakkapel. Registreren zaak beoordeelt de verstrekte informatie op het webformulier om te zien of alle informatie voor zo n aanvraag aanwezig is en voorziet de Zaakvoorlopig van het Zaaktype Aanvraag lichte bouwvergunning. Vervolgens wordt de Zaak aangeleverd aan Beheren Zaak. 5. Beheren zaak Het proces Beheren Zaak is primair verantwoordelijk voor het sturen en bewaken van de uitvoeren van de Zaak. Hiertoe worden alle relevante Zaken regelmatig beoordeeld op geschiktheid voor het uitvoeren van een processtap in de totale Zaakafhandeling. Zaken, die zich hiervoor classificeren worden actief gemaakt en doorgestuurd naar Behandelen zaak. Behandelen Zaak is verantwoordelijk voor de terugmelding van statusinformatie aan Beheren Zaak. Beheren Zaak kan deze statusinformatie beschikbaar maken aan de klant (via het Pagina 16

17 proces Kanalen) en aan de interne organisatie (Behandelen Zaak). Een belangrijke rol is weggelegd voor Beheren Zaak in het bewaken van termijnen. Een zaak, die tijdelijk niet voor continuering in aanmerking komt, moet zijn voorzien van een termijn, waarop er uiterlijk wel gecontinueerd moet worden. Zaken, waarvan de termijn is verstreken, worden opnieuw aangeboden aan Behandelen Zaak. Voorbeelden: Behandelen Zaak krijgt een Zaak van Registreren Zaak voor het aanvragen van een lichte bouwvergunning. Registreren Zaak heeft ontdekt, dat niet alle informatie aanwezig is voor het kunnen behandelen van deze Zaak. Behandelen Zaak initieert daarom een informatieverzoek aan de aanvrager om de ontbrekende informatie alsnog te verstrekken. De zaak wordt opgeschort tot de eerstvolgende vervaltermijn, waarbinnen de aanvrager dient te reageren. De status van de Zaak wordt op Opgeschort tot nadere informatie beschikbaar komt gezet. Behandelen Zaak krijgt een Zaak van Registreren Zaak voor het aanvragen van een lichte bouwvergunning. Registreren Zaak heeft ontdekt, dat alle informatie aanwezig is voor het kunnen behandelen van deze Zaak. Behandelen Zaak initieert daarom het bij het betreffende Zaaktype behorende BehandelZaak proces. De status van de Zaak wordt veranderd in In behandeling. 6. Behandelen zaak In Behandelen Zaak worden Primaire Processen (of deelprocessen daarvan) afgehandeld..na de afhandeling wordt statusinformatie teruggegeven aan Beheren Zaak. Als gevolg van de Behandeling van een Zaak moeten soms nieuwe Zaken worden gecreëerd. Hiertoe wordt een verzoek hiertoe gericht aan Beheren Zaak. Het proces Behandelen Zaak is zelf verantwoordelijk voor de beslissing of er in het geval van het starten van een nieuwe Zaak doorgegaan kan worden met de behandeling van de actuele Zaak of dat deze opgeschort moet worden. Verzoeken met opschorting worden zonodig via Beheren Zaak gerealiseerd. Voorbeeld: Eén van de processen van Behandelen Zaak (Aanvraag lichte bouwvergunning) wordt aangestuurd met een aanvraag voor de bouw van een dakkapel. Aanvraag lichte bouwvergunning bepaalt of aan alle voorwaarden is voldaan om de aanvraag te verrichten en neemt de zaak in behandeling. Deelprocessen voor het behandelen van de aanvraag worden gecreëerd en opgestart via Behandelen Zaak. De termijn voor continuering van de Zaak wordt gesteld op de eerstvolgende vervaltermijn van het eerste deelproces. De aansturing van deze primaire processen vanuit een frontoffice, die gemeentelijke diensten beschikbaar maakt via een groot aantal verschillende kanalen is naar het oordeel van de werkgroep het belangrijkste onderwerp voor het Referentiemodel Midoffice. In paragraaf 4.3 worden de genoemde subprocessen verder behandeld Pagina 17

18 Levering en ontwikkeling In dit proces zijn een aantal processen gegroepeerd, waarin is onderkend, dat deze binnen een gemeente een belangrijke rol spelen, maar geen directe relatie hebben met het dienstverleningsproces zelf. De tot deze groep behorende processen vallen uiteen in twee deelverzamelingen. Enerzijds zijn er processen die voorwaarde scheppend zijn voor de andere processen. Processen als Onderzoek en Beleidsontwikkeling vallen in deze categorie. Vaak spelen deze processen een rol in het leveren van informatie aan het Dienstverleningsproces. Anderzijds zijn er processen, die uitvoerend zijn. Vaak worden deze uitvoerende processen deels ook door het Dienstverleningsproces gevoed. Voorbeelden van dergelijke processen zijn Levering (plantsoenendienst, huisvuil etc.). De subprocessen in dit hoofdproces zijn: 1. Vergunning; 2. Onderzoek; 3. Opdracht; 4. Levering; 5. Ontwikkeling. De werkgroep Midoffice heeft zich met de uitwerking van deze processen verder niet bezig gehouden Gegevensverzamelingen Hieronder valt de gemeentelijke kernregistratie, met daaraan gekoppeld de Basisregistraties. Het betreft hier de set van statische basisgegevens, op grond waarvan en met behulp waarvan de operationele processen binnen de gemeente worden uitgevoerd. De Kernregistratie is daarbij zo gedefinieerd, dat deze de aanvullende informatie omvat, die gemeentebreed van belang zijn, maar (nog) niet zijn opgenomen in de Basisregistratie. Daarnaast omvat de Kernregistratie ook die gegevens, waarover verschillende partijen een andere opvatting hebben van de meest recente versie ervan. Deze gegevens zijn op dat moment in onderzoek, maar de meest actuele gegevens worden in de Kernregistratie bewaard t.b.v. operationeel gebruik door gemeentelijke afdelingen. De volgende gegevensverzamelingen worden in het model onderkend: Basisregistraties Een door het kabinet benoemde authentieke registratie die als zodanig het fundament vormt van het stelsel van overheidsregistraties. Op dit moment zijn aangewezen als basisregistraties: Nieuwe Handelsregister, Basis Gebouwen Registratie, Basis Registratie Adressen, Basisregistratie Topografie, Gemeentelijke Basis Administratie & Basisregistratie Kadaster. Kernadministraties Een door de gemeente zelf vastgestelde registratie van gegevens die noodzakelijk is voor de uitoefening van de taak van die overheidsinstantie. Voor zover relevant vormen de (landelijke) basisregistraties een subset van de kernregistratie Pagina 18

19 Zakendossier Een ingevuld formulier leidt tot een zogeheten zaak, een samenhangende hoeveelheid werk met een welgedefinieerde aanleiding en resultaat waarvan kwaliteit en doorlooptijd bewaakt moet worden. De gestructureerde (records) en ongestructureerde (documenten) gegevens van een zaak vormen samen een zaakdossier dat betrekking heeft op zowel de inhoud als het proces. Gemeenten kunnen procesgegevens (zaakgegevens in een zakensysteem) apart opslaan van inhoudelijke gegevens (zaakdossiers in een document management systeem) en andere (basis)gegevens (in een gegevensmagazijn). Productencatalogus Zaaktypecatalogus Gegevens uit het zakendossier kunnen in de toekomst ook worden gebruikt voor het project PIP (Persoonlijke Internet Pagina). Een gestructureerde inventaris van diensten (zogenaamde 'producten') die een overheid aanbiedt. Een voorbeeld van een productencatalogus is de VIND catalogus. Een bibliotheek van alle verschillende zaaktypen die die voor de gemeente van toepassing zijn. Het zaaktype bepaalt de wijze van afhandeling van de klantaanvraag. Voor ieder zaaktype zijn bedrijfsregels vastgelegd (in de vorm van een beslisboom) die bepalen op welke wijze de aanvraag binnen het gemeentelijk proces verder moet worden afgehandeld. Klantgegevens Openbare informatie De zaaktypecatalogus is te beschouwen als een verdere detaillering van de productencatalogus. Verzameling gegevens waarin alle relevante informatie over de klant zijn vastgelegd. Bijvoorbeeld de persoonlijke gegevens van de klant en de contacthistorie met de gemeente. Andere benaming hiervoor is klantprofiel. Gegevensverzameling waarin voor burgers relevante, openbare informatie aangaande de gemeente is opgenomen. Voorbeelden hiervan zijn raadsbesluiten, nieuwsberichten, openingstijden, informatie over openbare ruimte, GIS informatie t.b.v. burgers Elektronische dienstverlening Vanuit de doelstellingen van de Elektronische Overheid is het proces Dienstverlening het meest interessant. Immers, hier vinden als eerste de voornaamste veranderingen plaats. Om deze reden zijn de deelprocessen van dit hoofdproces nader gedetailleerd in de hieronder volgende paragrafen. Bij de uitwerking van het hoofdproces Dienstverlening is gestreefd naar het in kaart brengen van de benodigde besturingsprocessen. Uiteraard worden uiteindelijk de gevraagde diensten geleverd Pagina 19

20 door een uniek proces, dat behoort bij elk product dat een gemeente levert. Er is niet gepoogd om een inventarisatie van deze processen te maken. Er wordt verwezen naar relevante product catalogi voor gemeenten, zoals de VIND catalogus. Ieder van de daarin benoemde producten wordt in de visie van de werkgroep geleverd door een uniek proces. De hieronder getoonde uitwerking van het Dienstverleningsproces is vooral gericht op het in kaart brengen van de benodigde generieke aansturings- en bewakingsprocessen. In het Procesmodel Gemeentelijk Dienstverleningsproces is elektronische dienstverlening reeds uitgedetailleerd in een aantal eerder genoemde subprocessen, te weten: 1. Kanalen; 2. Classificeren klantvraag; 3. Assisteren en informeren klant; 4. Registreren zaak; 5. Beheren zaak; 6. Behandelen zaak. Ieder van deze subprocessen wordt in de komende paragrafen nader gedetailleerd uitgewerkt Pagina 20

21 Kanalen Bij kanalen denken we vooral aan de voorkant van de systemen, de frontoffice. Gemeenten hebben aan de voorkant vaak meer dan één kanaal voor communicatie met burgers en bedrijven. Dat kunnen verschillende functies betreffen zoals bestellen van een gemeentelijke dienst, informatie opvragen, maar ook klachtenafhandeling. Aan de achterkant onderscheiden we, vanwege verschillende toeleveranciers die misschien ook zelfde producten kunnen leveren, evenzo extra complexiteit. De burger verwacht daarbij een consistente benadering en up-to-date gegevens via alle kanalen. Figuur 4: Subproces 1, Kanalen Er kunnen 2 typen kanalen worden onderscheiden: Directe kanalen: Deze kenmerken zich door een direct contact van de gemeente met de klant; Indirecte kanalen: Bij deze kanalen is geen direct contact tussen de gemeente en de burger aanwezig. De burger dient een aanvraag in en krijgt pas later een reactie van de gemeente Pagina 21

22 Toelichting bij de processtappen in het proces Kanalen: 1.1 Internet Kanaal waarmee de aanvrager (burger) interactief via een webformulier op de internetpagina van de gemeente een aanvraag voor een gemeentelijke dienst kan invoeren. De aanvrager kan direct na verzending van het formulier een melding krijgen dat zijn aanvraag goed is verwerkt. Het is daarnaast ook mogelijk dat de burger toegang heeft tot zijn eigen electronisch loket (digitaal kluisje, mijnloket, PIP) waarin bijvoorbeeld de status van zijn/haar aanvraag kan worden gevolgd. 1.2 Telefoon Kanaal waarmee de aanvrager (burger) in telefonisch contact met een ambtenaar van de gemeente een vraag kan stellen of een product/dienst kan aanvragen. Indien mogelijk wordt de burger direct geholpen. 1.3 Balie Kanaal waarmee de aanvrager (burger) in direct contact met een ambtenaar van de gemeente een vraag kan stellen of een product/dienst kan aanvragen. Indien mogelijk wordt de burger direct geholpen. 1.4 Chat Kanaal waarmee de aanvrager (burger) in direct contact via chat met een ambtenaar van de gemeente een vraag kan stellen of een product/dienst kan aanvragen. Indien mogelijk wordt de burger direct geholpen. 1.5 Post Kanaal waarmee de aanvrager (burger) per post een vraag kan stellen of een product/dienst kan aanvragen. Er bestaat in dit geval geen direct contact tussen de burger en de ambtenaar (stateless, asynchrone communicatie) Kanaal waarmee de aanvrager (burger) per een vraag kan stellen of een product/dienst kan aanvragen. Er bestaat in dit geval geen direct contact tussen de burger en de ambtenaar (stateless, asynchrone communicatie). 1.7 SMS Kanaal waarmee de aanvrager (burger) per sms bericht een vraag kan stellen of een product/dienst kan aanvragen. Er bestaat in dit geval geen direct contact tussen de burger en de ambtenaar (stateless, asynchrone communicatie). 1.8 Uniformeren vraag De aanvragen zoals deze via de kanalen zijn binnengekomen, worden geuniformeerd naar één en hetzelfde formaat. Dit maakt het mogelijk om de aanvraag in een volgende stap in een zelfde formaat binnen het gemeentelijke zakensysteem vast te leggen, te behandelen en de voortgang te volgen. Hieronder valt bijvoorbeeld het scannen van een (niet digitaal) poststuk. Hierdoor wordt het mogelijk dit document op te slaan in een elektronisch (zaken)dossier Pagina 22

23 Classificeren klantvraag Het doel van het proces Classificeren klantvraag is om alle voorbereidende werkzaamheden uit te voeren voordat de klantvraag als zaak kan worden vastgelegd. Het profiel van de burger dient hierbij te worden aangevuld en eventueel dient de burger geïdentificeerd te worden. Aangezien vragen via verschillende kanalen kunnen worden toegeleverd is het van belang onderscheid te maken tussen vragen, die ontstaan in dialoog met de klant en vragen, waarop geen onmiddellijk (binnen minuten) antwoord hoeft te worden geformuleerd. Figuur 5: Subproces 2, Classificeren klantvraag Pagina 23

24 Toelichting bij de processtappen in het proces Klantvraag: 2.1 Identificeren Wordt ook aangeduid als authenticeren. Identificeren of authenticeren houdt in dat wordt gecontroleerd of de persoon daadwerkelijk diegene is wie hij of zij beweert te zijn. Dit kan zowel een handmatig proces zijn (bijvoorbeeld de controle van een paspoort) als een geautomatiseerd proces. Meestal gebeurt dit door het aanloggen met een gebruikersnaam en wachtwoord, maar dit kan ook op basis van een token (bijvoorbeeld een smartcard) of op basis van biometrische kenmerken(bijvoorbeeld een vingerafdruk of een irisscan). Na de authenticatie vindt autorisatie plaats om na te gaan welke toegangsrechten de geauthenticeerde gebruiker, computer of applicatie heeft. Het gemeenschappelijke authenticatiesysteem voor de overheid is DigiD. 2.2 Aanvullen klantbeeld 2.3 Queue Management Deze stap is optioneel binnen het proces. Niet voor alle soorten aanvragen (zaaktypen) is identificatie/authenticatie een verplichte stap. Beoordelen en indien nodig aanvullen van de gegevens van de aanvrager. Dit wordt meestal bereikt door gegevens uit kernregistraties te verzamelen. Voor simpele vragen (bv. de telefonische vraag 'hoe laat is het loket burgerzaken open') is het niet nodig dat de gegevens van de persoon bekend hoeven te zijn bij de ambtenaar die de aanvraag behandelt. Hierbij kan worden volstaan met een direct antwoord aan de burger. Evt. kan een notitie van het gesprek worden vastgelegd in het klantgegevens systeem van de gemeente. Routering van de vraag naar de juiste personen en/of afdelingen. Daarbij kan eveneens de prioritering van afhandeling worden vastgelegd Pagina 24

25 Assisteren en informeren klant In dit proces zijn alle activiteiten gebundeld, die benodigd zijn voor het verstrekken van informatie aan de burgers/bedrijven. Het doel van het proces is om m.b.v. deze informatieverstrekking de klanten te helpen met het selecteren en afnemen van diensten van de gemeente. Figuur 6: Subproces 3: Assisteren en informeren klant Pagina 25

26 Toelichting bij de processtappen in het proces Assisteren en Informeren Klant: 3.1 Vastleggen in klantprofiel 3.2 Bekijken Productcatalogus 3.3 Zoeken via vraagtrechter 3.4 Zoeken via zoekdienst 3.5 Publicatie Openbare documenten 3.6 Opvragen Status Zaak 3.7 Completeren aanvraag De geüniformeerde gegevens worden vastgelegd bij het profiel van de klant Overzicht van alle gemeentelijke producten en diensten. Deze producten en diensten kunnen zowel door de burger als door de ambtenaren binnen de gemeente worden geraadpleegd. Zoeken binnen de gemeentelijke productencatalogus Zoekmogelijkheid over alle gemeentelijke informatie heen (Productencatalogus én Openbare informatie). Opvragen van openbare documenten door de aanvrager zelf én het versturen van de openbare informatie aan de burger door een ambtenaar Opvragen van de status van de zaak door de aanvrager zelf én het versturen van de status van de zaak aan de burger door een ambtenaar Op basis van het bekende klantprofiel van de aanvrager, kunnen gegevens van de aanvrager zoals deze bekend zijn binnen de gemeentelijke administratie, worden voorgevuld. Te denken valt aan het voorvullen van persoons- en NAW gegevens op basis van het sofinummer of gemeentelijk A-nummer. Deze stap is ook verantwoordelijk voor een dialoog met de aanvrager. Op basis van regels uit een beslisboom kan een dialoog met een aanvrager worden uitgevoerd. De stappen hiervoor liggen vast in een Beslisbomen database. Deze wordt ook wel aangeduid als Business Rule engine Pagina 26

27 Registreren zaak Processtappen die leiden tot het vastleggen van de klantvraag als een zaak in het elektronische zaakdossier van de gemeente. Het zaakdossier is hierbij opgesteld conform de richtlijnen van het GFO Zaken. Het GFO zaken geeft aan welke sleutelgegevens minimaal nodig zijn om essentiële gegevens over een zaak (procedure) uit verschillende informatiesystemen te ontsluiten en te koppelen. Een zaak is bijvoorbeeld de behandeling van een klacht, een vergunningsaanvraag of een paspoortafgifte. Het GFO Zaken zorgt ervoor dat alle relevante informatie wordt ontsloten en gekoppeld op een centraal punt. Het gaat daarbij bijvoorbeeld om de over de gegevens van de indiener van een verzoek, de status van een te behandelen zaak, de ambtenaar of het organisatieonderdeel dat het verzoek behandelt. Figuur 7: Subproces 4, Registreren zaak Pagina 27

28 Toelichting bij de processtappen in het proces Registreren Zaak: 4.1 Inhoudelijk controleren Intake 4.2 Toekennen Voorlopig Zaaktype Controle of de intake zoals deze is ontvangen, aan alle eisen die aan de aanvraag worden gesteld voldoet om als zaak binnen het zakendossier kan worden geregistreerd. Bijvoorbeeld: mag de burger een dergelijke aanvraag doen, voldoet de aanvraag aan de bedrijfsregels zoals deze binnen de zaaktype catalogus zijn vastgelegd. Op basis van de gegevens die gestructureerd zijn vastgelegd, kan een ambtenaar nu bepalen wat het zaaktype is. Hiertoe wordt gebruik gemaakt van zaaktypen zoals deze binnen de zaaktypecatalogus aanwezig zijn. 4.3 Creëren zaak Vastleggen van de intake in het zakendossier conform GFO zaken. Hierbij wordt tevens het in de vorige stap behandelde zaaktype vastgelegd Pagina 28

29 Beheren zaak In dit proces worden alle handelingen uitgevoerd voor het bijhouden van de status en informatie rond een zaak. Bij een intake wordt een zaak gecreëerd, die in de volgende afhandeling telkens wordt voorzien van de relevante informatie, inclusief de status. Deze status kan door de klant tijdens de uitvoering van de zaak worden geraadpleegd. Figuur 8: Subproces 5, Beheren zaak Pagina 29

30 Toelichting bij de processtappen in het proces Beheren Zaak: 5.1 Sturen en bewaken zaak Proces voor het bewaken van (de voortgang van) de zaak. 5.2 Bijwerken zaak Op basis van nieuwe informatie over de zaak, wordt de zaak bijgewerkt. 5.3 Melden interne status 5.4 Melden klantstatus 5.5 Pro-actieve diensten verlenen Na het bijwerken van de status van de zaak wordt de status van de zaak gemeld aan het routeringsproces van de administratieve afhandeling. Na het bijwerken van een voor de aanvrager relevante status van de zaak, wordt dit gemeld aan de burger. Dit kan via diverse kanalen als post, , telefoon of de website (PIP of MijnLoket) gebeuren. De klant van de gemeente wordt geattendeerd op voor hem of haar relevante informatie. Een voorbeeld is het elektronisch attenderen van klanten van wie reisdocumenten en/of rijbewijs op korte termijn verloopt. De klantgerichtheid van de gemeente zal door deze toepassing aanzienlijk worden vergroot. 5.6 Opschorten zaak Uitstellen van een zaak, bijvoorbeeld om een beslissing af te wachten. Een voorbeeld is een bouwvergunning waarvoor een bezwaarschrift is ingediend. Het bezwaarschrift heeft als zaak een relatie met de specifieke bouwvergunningsprocedure. De bouwvergunningsprocedure kan hierdoor worden opgeschort. 5.7 Archiveren zaak Het bewaren van een zaak. In de meeste gevallen betreft dit zaken die zijn afgehandeld. Meestal met het doel om inzicht te houden in de historie van zaken om hierop te kunnen sturen. Ook om redenen van wet- en regelgeving zijn gemeenten hiertoe verplicht Pagina 30

31 Behandelen zaak Dit proces heeft de taak om alle aanvragen van een klant af te handelen. Dit gebeurt volgens een generiek toepasbaar proces, waarbij het kenmerk is, dat de besturing van het proces uniform is voor alle soorten afhandelingen. De afhandelingen zelf zijn op te vatten als een reeks van vele honderden producten, die een gemeente levert. Hiertoe behoren niet alleen de producten, die bedoeld zijn voor klanten, maar evenzo producten t.b.v. interne levering. De rol van deze laatste is vooral als elementair proces, dat in het kader van een samengesteld proces moet worden uitgevoerd voor een totale dienstverlening aan de klant. Figuur 9: Subproces 6, Behandelen zaak Per proces worden de specifieke eigenschappen vastgesteld en het aantal en de soort processtappen geïnventariseerd. Bij de uitvoering van een processtap kan er gebruik worden gemaakt van andere processen in de bibliotheek door het recursief opstarten van een nieuwe intake. Nadat alle processtappen zijn uitgevoerd, wordt het resultaat (een besluit) kenbaar gemaakt aan de klant. Indien de klant intern is, betekent dit, dat een subproces aan de procesorganisatie het resultaat kenbaar maakt van de processtap, waarna het moederproces haar weg kan vervolgen Pagina 31

32 Toelichting bij de processtappen in het proces Behandelen Zaak: 6.1 Accepteren Zaak Een zaak wordt door de afdeling of medewerker die de zaak uiteindelijk zal afhandelen, geaccepteerd. Hiermee start het proces van afhandeling van de zaak in de Backoffice. 6.2 Toekennen Definitief Zaaktype 6.3 Beoordelen Ontvankelijkheid De behandelende afdeling of medeweker controleert of het zaaktype zoals dat eerder bij het registreren van de zaak (hoofdproces 4) door de intake medewerker is bepaald, juist is. Indien nodig wordt het zaaktype aangepast. Toetsing of de aanvraag voldoet aan de voorwaarden die op het vlak van de vorm en van de aanvraagprocedure door de wet worden opgelegd (bv. het verplichte gebruik van het officiële aanvraagformulier voor een bouwvergunning). Dit houdt dus niet in dat een uitspraak wordt gedaan over de inhoud van het dossier en de grond van de zaak. Een zaak die ontvankelijk is verklaard, hoeft dus niet automatisch een goedkeuring, erkenning of financiering te krijgen. 6.4 Behandeling Alle producten en diensten die een gemeente aanbiedt aan haar burgers. Voor de meeste gemeenten zullen dit er enkele honderden zijn. Daarnaast zijn ook subproducten denkbaar die horen bij een hoofdproduct. Bijvoorbeeld: Hoofdproduct 'Aanvraag Bouwvergunning': deze heeft als subproducten 'Verzoek Vrijstelling Artikel-X procedure'én 'Inspecties n.a.v. besluit Aanvraag Bouwvergunning'. 6.5 Terugmelding verzorgen 6.6 Publiceren Besluit Bij het doorlopen van een proces dat behoort bij het betreffende product, zal er terugmelding moeten plaatsvinden naar de aanvrager. Een behandeling van een zaak kan leiden tot een genomen besluit. Afhankelijk van de aard het besluit kan dit worden teruggemeld aan de aanvrager of worden toegevoegd aan de gegevensverzameling met openbare informatie Pagina 32