Architectuur Model Gemeentelijke E-Dienstverlening

Architectuur Model Gemeentelijke E-Dienstverlening Project Referentiemodel Midoffice ten behoeve van Gemeenten

Auteurs: EGEM werkgroep Midoffice Versie: 0.9 Datum: 24-05-2006

24-5-2006

Pagina 1

Inhoudsopgave 1. Inleiding ........................................................................................................... 4 1.1. Aanleiding .............................................................................................................................. 4 1.2. Werkgroep Midoffice .............................................................................................................. 5 1.3. Leeswijzer .............................................................................................................................. 5

2. Schets bestaande E-Dienstverlening ............................................................ 6 2.1. Inrichting van de Backoffice ................................................................................................... 6 2.2. Inrichting van de Frontoffice................................................................................................... 7 2.3. Noodzaak van een Midoffice.................................................................................................. 7

3. Architectuurbenadering ................................................................................. 9 4. Bedrijfsarchitectuur Midoffice ..................................................................... 12 4.1. Inleiding................................................................................................................................ 12 4.2. Procesmodel ........................................................................................................................ 13 4.2.1. Dienstverlening.............................................................................................................. 14 4.2.2. Levering en ontwikkeling ............................................................................................... 18 4.2.3. Gegevensverzamelingen............................................................................................... 18 4.3. Elektronische dienstverlening .............................................................................................. 19 4.3.1. Kanalen ......................................................................................................................... 21 4.3.2. Classificeren klantvraag ................................................................................................ 23 4.3.3. Assisteren en informeren klant...................................................................................... 25 4.3.4. Registreren zaak ........................................................................................................... 27 4.3.5. Beheren zaak ................................................................................................................ 29 4.3.6. Behandelen zaak........................................................................................................... 31

5. Informatie architectuur Midoffice ................................................................ 33 5.1. Architectuurprincipes ........................................................................................................... 33 5.2. Applicatie architectuur.......................................................................................................... 34 5.2.1. Kanalen ......................................................................................................................... 38 5.2.2. Classificeren Klantvraag................................................................................................ 38 5.2.3. Assisteren en Informeren Klant ..................................................................................... 39 5.2.4. Registreren Zaak ........................................................................................................... 40 5.2.5. Beheren Zaak ................................................................................................................ 41 5.2.6. Behandelen Zaak .......................................................................................................... 42 5.3. Service klassen .................................................................................................................... 42 5.4. De rol van Business Process Management......................................................................... 43 5.5. Het zakensysteem als centrale spil ..................................................................................... 44 5.6. De rol van de Dienstenbus................................................................................................... 45 5.7. Inrichting van de frontoffice.................................................................................................. 46 5.8. Invulling met standaard componenten ................................................................................. 48

6. Technische architectuur Midoffice.............................................................. 49 6.1. Applicatie Integratie ............................................................................................................. 49 6.2. Webservices......................................................................................................................... 50

24-5-2006

Pagina 2

6.3. Koppelingen ......................................................................................................................... 50 6.4. Broker................................................................................................................................... 51 6.5. Dienstenbus ......................................................................................................................... 51 6.6. StUF ..................................................................................................................................... 54 6.7. Portaal.................................................................................................................................. 54

7. Transitiestrategie voor het Midoffice .......................................................... 56 7.1. Stadia van het Midoffice....................................................................................................... 56 7.1.1. Eén Loket (Multi-Channel)............................................................................................. 56 7.1.2. Organisatorisch Midoffice.............................................................................................. 57 7.1.3. Technisch Midoffice....................................................................................................... 58 7.1.4. Midoffice conform Service Georiënteerde Architectuur ................................................ 59 7.2. Routeplan............................................................................................................................. 60 7.2.1. Korte termijn .................................................................................................................. 60 7.2.2. Middellange termijn ....................................................................................................... 60 7.2.3. Lange termijn................................................................................................................. 63 7.3. Scenario’s ............................................................................................................................ 64

Bijlage A. Midoffice Woordenboek .................................................................. 67 Bijlage B. Lijst Services Midoffice................................................................... 75 Bijlage C. Functionaliteiten versus Diensten ................................................. 77

24-5-2006

Pagina 3

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.

24-5-2006

Pagina 4

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. Leesw ijzer 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 EDienstverleningspraktijk naar een volledig elektronische dienstverlening conform een Service Georiënteerde Architectuur.

24-5-2006

Pagina 5

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.

2.1. 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.

24-5-2006

Pagina 6

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.

2.3. 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

24-5-2006

Pagina 7

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.

24-5-2006

Pagina 8

3. Architectuurbenadering Leidraad voor het opstellen van het referentiemodel Midoffice is het Architectuurmodel 1 electronische overheid (ELO) uit het rapport Architectuur Elektronische Overheid . 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:

http://www.egem.nl/kennisbank/informatievoorziening/architectuurelektronischeoverheid.pdf

24-5-2006

Pagina 9

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

24-5-2006

Pagina 10

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.

24-5-2006

Pagina 11

4. Bedrijfsarchitectuur Midoffice 4.1. Inleiding 2

Binnen de NORA 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

24-5-2006

Pagina 12

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.

24-5-2006

Pagina 13

•

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. 4.2.1. 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.

24-5-2006

Pagina 14

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.

24-5-2006

Pagina 15

•

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

24-5-2006

Pagina 16

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.

24-5-2006

Pagina 17

4.2.2. 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.

4.2.3. 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.

24-5-2006

Pagina 18

Zakendossier

Productencatalogus

Zaaktypecatalogus

Klantgegevens

Openbare informatie

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). 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. 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.

4.3. 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

24-5-2006

Pagina 19

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.

24-5-2006

Pagina 20

4.3.1. 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.

24-5-2006

Pagina 21

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). 1.6

E-mail

Kanaal waarmee de aanvrager (burger) per e-mail 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.

24-5-2006

Pagina 22

4.3.2. 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

24-5-2006

Pagina 23

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

24-5-2006

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

4.3.3. 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

24-5-2006

Pagina 25

Toelichting bij de processtappen in het proces Assisteren en Informeren Klant: 3.1 Vastleggen in De geüniformeerde gegevens worden vastgelegd bij het profiel klantprofiel van de klant 3.2 Bekijken Overzicht van alle gemeentelijke producten en diensten. Deze Productcatalogus producten en diensten kunnen zowel door de burger als door de ambtenaren binnen de gemeente worden geraadpleegd. 3.3 3.4 3.5 3.6 3.7

Zoeken via vraagtrechter Zoeken via zoekdienst Publicatie Openbare documenten Opvragen Status Zaak Completeren aanvraag

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.

24-5-2006

Pagina 26

4.3.4. 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

24-5-2006

Pagina 27

Toelichting bij de processtappen in het proces Registreren Zaak: 4.1 Inhoudelijk Controle of de intake zoals deze is ontvangen, aan alle eisen die controleren aan de aanvraag worden gesteld voldoet om als zaak binnen het Intake 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. 4.2 Toekennen Op basis van de gegevens die gestructureerd zijn vastgelegd, kan Voorlopig een ambtenaar nu bepalen wat het zaaktype is. Hiertoe wordt Zaaktype 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.

24-5-2006

Pagina 28

4.3.5. 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

24-5-2006

Pagina 29

Toelichting bij de processtappen in het proces Beheren Zaak: 5.1 Sturen en Proces voor het bewaken van (de voortgang van) de zaak. bewaken zaak 5.2 Bijwerken zaak Op basis van nieuwe informatie over de zaak, wordt de zaak bijgewerkt. 5.3 Melden interne Na het bijwerken van de status van de zaak wordt de status van status de zaak gemeld aan het routeringsproces van de administratieve afhandeling. 5.4 Melden Na het bijwerken van een voor de aanvrager relevante status van klantstatus de zaak, wordt dit gemeld aan de burger. Dit kan via diverse kanalen als post, e-mail, telefoon of de website (PIP of MijnLoket) gebeuren. 5.5 Pro-actieve De klant van de gemeente wordt geattendeerd op voor hem of diensten haar relevante informatie. Een voorbeeld is het elektronisch verlenen 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.

24-5-2006

Pagina 30

4.3.6. 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.

24-5-2006

Pagina 31

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

6.4

Behandeling

6.5

Terugmelding verzorgen

6.6

Publiceren Besluit

24-5-2006

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. 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' . 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

5. Informatie architectuur Midoffice Om te komen tot de inrichting van een ICT ondersteuning van de in het vorige hoofdstuk beschreven processen wordt dit procesmodel in dit hoofdstuk nader uitgewerkt tot een informatiemodel. Daarmee wordt zicht verkregen op de gewenste eindsituatie rondom Midoffice problematiek, terwijl toch de aansluiting met de bestaande situatie in tact wordt gelaten. Het migratievraagstuk om van de huidige situatie naar de in dit hoofdstuk gewenste eindsituatie gekomen is het onderwerp van het volgende hoofdstuk.

5.1. Architectuurprincipes De volgende architectuurprincipes worden gehanteerd bij de inrichting van een informatiemodel voor de inrichting van een midoffice ‘nieuwe stijl’: •

Breng een scheiding aan in een data-, logica- en presentatielaag Bij het bouwen van applicaties wil men de applicatie zo flexibel mogelijk opbouwen zodat deze met verschillende kanalen kan communiceren en snel aangepast kan worden als eisen aan de systeem functies veranderen. Tevens wordt hiermee de complexiteit zoveel mogelijk gereduceerd en het gemeenschappelijk gebruikt van diensten die in de verschillende lagen worden aangeboden bevorderd. Een beproefde wijze is het scheiden en ontkoppelen de gegevens-, logica- en presentatielaag, zodat wijzigingen eenvoudig te lokaliseren een aan te brengen zijn. − Datalaag: Verzorgt de opslag van alle gebruikte gegevens, bijvoorbeeld door middel van een (technisch) datamodel; − Logicalaag: Deze laag bestaat uit gegevensbeherende en vergarende functies en worden aangeboden in de vorm van services (webservices). Ook de applicatiefuncties (logica) wordt waar mogelijk aangeboden in de vorm van services. Deze laag vormt het communicatiemedium tussen enerzijds de gegevenslaag en anderzijds de presentatielaag plaats; − Presentatielaag: Verzorgen van de afhandeling van de interactie met de gebruiker.

•

Breng een scheiding aan tussen regie en uitvoering in elk proces Procesgerichte benadering voor de inrichting van een midoffice in plaats van functionele of applicatiegerichte benadering. Laat allereerst de behoefte van de klant en vervolgens de processen leidend zijn voor de inrichting van de systemen.

•

Maak gebruik van wereldwijd geaccepteerde standaarden Maak géén gebruik van proprietary leveranciersgebonden oplossingen. Om er enkele te noemen: XML, XSD, SOAP, WSDL, BPEL en webservices.

•

Maak gebruik van BPM technologie Dit impliceert ontkoppeling van sturing en uitvoering. Dit betekent, dat de inrichting en bundeling van uitvoeringsprocessen onafhankelijk kan worden gerealiseerd en onderhouden. Daarmee wordt geborgd, dat de nieuwe informatiestructuur flexibel kan

24-5-2006

Pagina 33

worden aangepast aan veranderende organisatiestructuren. Knelpunten die met BPM opgelost kunnen worden: − Snel aanpassen van processen binnen huidige complexe hiërarchische structuren is niet mogelijk; − Processen lopen over organisatiegrenzen heen. De regie hiervan verloopt niet goed. Hierdoor ontstaan veel onnodige coördinatiekosten; − Er gaat veel tijd en geld verloren aan overbodige handelingen, indirecte werkzaamheden en activiteiten als gevolg van foutafhandeling. De informatiearchitectuur heeft betrekking op de inrichting van de informatiehuishouding. In de context van dit rapport heeft het in het bijzonder betrekking op de informatiehuishouding van de gemeentelijke dienstverlening aan haar klanten (burgers en bedrijven). De informatiearchitectuur heeft betrekking op alle informatie, niet slechts op dat wat geautomatiseerd is: ook nietgeautomatiseerde informatie kan een onderdeel zijn van de dienstverlening. Deze informatie wordt daar waar mogelijk wel gedigitaliseerd voor presentatie in een webomgeving.

5.2. Applicatie architectuur

3

Onderstaande afbeelding, ontleend aan de NORA , geeft een weergave van de basisapplicatie architectuur:

Figuur 10: Basis applicatie architectuur overheidsorganisaties

Een korte toelichting bij de onderdelen uit deze figuur: •

3

Interactie Deze component is verantwoordelijk voor het afhandelen van alle interactie met burgers en bedrijven. Daarbij wordt gebruik gemaakt van verschillende kanalen. Afhankelijk van de eigenschappen van een kanaal worden verschillende acties ondernomen om de

NORA, versie 0.7.9

24-5-2006

Pagina 34

informatie zodanig te structureren, dat achterliggende componenten hiermee kunnen omgaan. Zo zal een poststuk ingescand worden en van indicatieve gegevens voorzien, alvorens het beschikbaar wordt gemaakt voor de rest van de informatiestructuur. •

Besturing Deze component ontvangt aanvragen van burgers en bedrijven en stuurt de rest van de informatiestructuur aan. Daarbij wordt tevens management rapportage onttrokken aan de binnengekomen vragen en de afhandeling daarvan. De component besturing kan gebruik maken van het Primaire Proces en van Ondersteunende Processen. Dienstverlening wordt meestal uitgevoerd onder gebruikmaking van beide functies. Als voorbeeld moge dienen een aanvraag voor een bouwvergunning, waarin het Primaire Proces zorg draagt voor de beoordeling en het verlenen (of niet) van de vergunning. Ondersteunende processen worden gebruikt om bijvoorbeeld leges voor de vergunning te innen.

•

Primair proces In het Primaire Proces wordt de dienstverlening aan de burger gestalte gegeven. Hierin spelen handmatige componenten evenzeer een rol als geautomatiseerde. Een beoordelingprocedure door de Welstandscommissie voor een bouwvergunning is een typisch voorbeeld voor een handmatig proces. Het afgeven van een uittreksel uit het persoonsregister is een typisch voorbeeld van een geautomatiseerd proces.

•

Data opslag Deze component is verantwoordelijk voor het beheer en de toegang tot gestructureerde informatie. Denk hierbij bijvoorbeeld aan persoonsgegevens of aan leerling-gegevens. Het betreft hierbij dus zowel basisgegevens als gegevens, die typisch zijn voor de uitoefening van een taak van de gemeente.

•

Documentenopslag Deze component is verantwoordelijk voor het beheer en de toegang tot ongestructureerde informatie, zoals gescande documenten en dossiers.

•

Ondersteuning Deze component is verantwoordelijk voor het leveren van hulpdiensten t.b.v. de gehele organisatie.

In grote lijnen komt deze informatie architectuur overeen met de inzichten van de Werkgroep Referentiemodel Midoffice. Het Procesmodel van deze werkgroep geeft echter meer inzicht in de wijze, waarop processen in relatie tot elkaar staan en deze afhankelijkheden zijn niet zonder meer terug te vinden in het Nora model. Op de volgende pagina is een schema opgenomen van de Werkgroep Referentiemodel Midoffice, waarin het procesmodel vertaald is in een Service Georiënteerde Architectuur (SGA).

24-5-2006

Pagina 35

Figuur 11: Informatie model Midoffice

Ieder van de processen uit het procesmodel is daarbij vertaald in een servicemodule, waarin de uitvoering van het proces gestalte is gegeven. Deze services zijn aan elkaar gekoppeld via een Dienstenbus, waarlangs informatie-uitwisseling kan plaatsvinden. In het hieruit resulterende schema kan echter niet worden afgeleid welke relatie deze services met elkaar onderhouden. Dit is ook in overeenstemming met de architectuurprincipes van een Service Georiënteerde Architectuur. De relatie tussen deze services wordt in een Service Georiënteerde Architectuur expliciet gemaakt d.m.v. een service t.b.v. de processturing. In het schema is deze dan ook toegevoegd met de naam BPM (Business Process Management). Deze services is verantwoordelijk voor het aansturen van de overige services in de context van de diensten die moeten worden verleend. Deze service doet dat door de benodigde servicemodules aan te sturen met de correcte informatie voor het verlenen van een dienst en in de goede volgorde. De specificaties voor deze Orkestratiefuncties worden gevormd door het Procesmodel Midoffice. Aan de hand van een aantal voorbeelden wordt hieronder geïllustreerd hoe het Informatiemodel functioneert.

24-5-2006

Pagina 36

Voorbeelden: • Een burger wil een dakkapel op zijn huis bouwen en vraagt zich af aan welke spelregels hij zich moet houden. Via het kanaal Internet gaat hij op zoek naar informatie. De Business Process Manager (BPM) ontvangt de vraag en vraagt de service Classificeren Klantvraag om wat voor soort vraag het hier gaat. Het antwoord is, dat er gevraagd wordt om informatie, waarna BPM de vraag doorspeelt naar de service Informatie Ontsluiting. Via de Product Catalogus wordt de burger geïnformeerd over de spelregels, die gelden voor het plaatsen van een dakkapel. De burger ontvangt de informatie, dat hiervoor een bouwvergunning benodigd is en welke criteria daarvoor gelden. •

Dezelfde burger besluit, dat op grond van de verkregen informatie, dat hij een lichte bouwvergunning dient aan te vragen en vraagt dan ook om het betreffende formulier. BPM ontvangt de vraag en stuurt de vraag via Classificeren Klantvraag aan de service Informatie Ontsluiting om het formulier voor te bereiden (van te voren in te vullen) met de gegevens van de burger. Via de service Internet Kanaal biedt BPM vervolgens het formulier aan de burger aan. De burger vult het formulier in en verzendt dit formulier. BPM stuurt vervolgens het formulier via de service Classificeren Klantvraag naar de service Registreren Zaak. Registreren Zaak creëert de Zaak en het elektronische dossier en BPM stuurt vervolgens de Zaak naar de service Beheren Zaak. Beheren Zaak maakt de voorbereidingen voor het aansturen van de eerste stap in het Behandelproces, waarna BPM het betreffende Behandelproces aanstuurt. Deze Behandelprocessen zijn soms belegd in bestaande Legacy systemen, maar soms is het Legacy systeem reeds fijnmaziger ontsloten en in de Informatie architectuur aanwezig in de vorm van een Behandeldienst. Na het uitvoeren van een stap levert het betreffende Behandelproces de uitkomst van deze stap terug aan BPM, waarna via Beheren Zaak de volgende stap wordt aangestuurd. Op deze wijze wordt het gehele proces doorlopen, totdat er een besluit is om de vergunning te verlenen of af te wijzen. Gedurende het doorlopen van de stappen, wordt voortdurend door Beheren Zaak de status bijgehouden, zodat een vraag van de Burger naar deze status beantwoord kan worden. Nadat een besluit is genomen regelt Behandelen Zaak de afwerking van de Zaak door deze te publiceren, de betrokkenen te informeren en de Zaak te archiveren.

Zoals het procesmodel verder is uitgewerkt in detailschema, zo moet ook het Informatiemodel verder worden verfijnd, door de detailschema’s van het procesmodel daarin te verwerken. Op deze uitwerking wordt hieronder ingegaan. In bijlage B is een lijst opgenomen met alle services uit het Informatiemodel.

24-5-2006

Pagina 37

5.2.1. Kanalen Het schema van de service Kanalen wordt hieronder getoond:

Figuur 12: Kanalen

In het schema is te zien, dat er een onderscheid wordt gemaakt, conform het procesmodel aan in een tweetal groeperingen in de kanalen: de Directe Kanalen en de Indirecte Kanalen. Het schema voorziet verder in een service t.b.v. het Uniformeren van de vragen via de verschillende kanalen in een gelijksoortig formaat.

5.2.2. Classificeren Klantvraag Hieronder staat het subschema van Classificeren Klantvraag:

Figuur 13: Classificeren Klantvraag

24-5-2006

Pagina 38

In het detailschema komen in overeenstemming met het procesmodel de volgende services voor: 1. Bepaal Prioriteit (Wachtrij). De beschrijving van deze service komt overeen met het proces Queue Management uit het procesmodel; 2. Aanvullen klantbeeld, conform het procesmodel; 3. Identificeren, conform het procesmodel. De invulling van de functionaliteit van dit proces kan bijvoorbeeld worden gedaan m.b.v. DigiD. Tevens is een service “Kanaal eigenschappen” toegevoegd. Deze service is noodzakelijk omdat bij het bepalen van de prioriteit mede op grond van Kanaal eigenschappen moet worden vastgesteld welke prioriteit het beantwoorden van de vraag heeft. De service “Kanaaleigenschappen” heeft dan ook de eigenschap, dat deze de benodigde prioriteit voor vraagafhandeling kan opleveren.

5.2.3. Assisteren en Informeren Klant Het subschema Assisteren en Informeren klant ziet er als volgt uit:

Figuur 14: Assisteren en Informeren Klant

Conform het procesmodel zijn in dit schema de volgende services terug te vinden: 1. Vastleggen klantprofiel; 2. Raadplegen Productcatalogus; 3. Zoeken via Vraagtrechter; 4. Zoeken via zoekdienst; 5. Publiceren; 6. Opvragen status zaak; 7. Completeren aanvraag.

24-5-2006

Pagina 39

De inhoudelijke beschrijvingen van deze services zijn geheel conform het procesmodel. Er is een additionele service Kanaaleigenschappen toegevoegd om de overige processen behulpzaam te kunnen zijn bij het vaststellen van de soorten inhoud, die een kanaal kan verwerken.

5.2.4. Registreren Zaak Het detailschema van Registreren Zaak ziet er als volgt uit:

Figuur 15: Registreren Zaak

Vanuit het procesmodel zijn de volgende services in het schema opgenomen: 1. Inhoudelijk controleren intake; 2. Toekennen voorlopig zaaktype; 3. Creëren Zaak. Tevens is een proces toegevoegd voor het kunnen afhandelen van betalingen. Teneinde de betalingsvorm te kunnen afstemmen op het kanaal, dat is gehanteerd voor de aanvraag, is de service Kanaaleigenschappen weer toegevoegd.

24-5-2006

Pagina 40

5.2.5. Beheren Zaak Het schema voor het Beheren van een Zaak ziet er als volgt uit:

Figuur 16: Beheren Zaak

Conform het procesmodel zijn hierin de volgende services opgenomen: 1. Sturen en Bewaken zaak; 2. Bijwerken Zaak; 3. Melden Interne status; 4. Melden Klantstatus. Tijdens de analyse van het Informatiemodel heeft de werkgroep Midoffice vastgesteld, dat er tevens services dienen te zijn met betrekking tot: 5. Opschorten Zaak. Deze services wordt uitgevoerd op het moment, dat Behandelen Zaak vaststelt, dat een zaak tijdelijk moet worden opgeschort. Opschorten Zaak kan tevens worden gebruikt om de zaak opnieuw te activeren. 6. Archiveren Zaak. Na beëindiging van de behandeling van een zaak, dient deze gearchiveerd te worden conform de archiefwet. De service Archiveren Zaak doet dit, door alle relevante informatie m.b.t. de zaak te archiveren. Teneinde de aansluiting tussen het procesmodel en het informatiemodel volledig te houden, dient het procesmodel te worden uitgebreid met de toegevoegde processen.

24-5-2006

Pagina 41

5.2.6. Behandelen Zaak Het schema voor de uitwerking van de service Behandelen Zaak ziet er als volgt uit:

Figuur 17: Behandelen Zaak

Overeenkomstig het procesmodel zijn de volgende services onderkend: 1. 2. 3. 4. 5.

Accepteren Zaak; Toekennen Definitief Zaaktype; Beoordelen Ontvankelijkheid; Behandelen Zaak; Terugmelding verzorgen.

In toevoeging daarop heeft de werkgroep onderkend, dat er een additionele service moet worden toegevoegd, die vervolgens in het procesmodel is verwerkt: 6. Publiceren Besluit. Elke handeling in een Zaakafhandeling leidt op enig moment tot een afronding. Dit is Publiceren besluit genoemd, hoewel dit zo eenvoudig kan zijn als het meedelen van een genomen beslissing aan de aanvragen burger.

5.3. Service klassen In het hierboven gepresenteerde Informatiemodel worden services in twee niveaus uiteengerafeld. In het hoofdschema worden services als “Assisteren en Informeren klant” gehanteerd als een service op topniveau, die later in een detailschema worden uitgesplitst in services op een lager niveau. Dit proces kan worden herhaald, totdat het niveau van elementaire services zijn bereikt. Er ontstaat daardoor een hiërarchie van elementaire en samengestelde services.

24-5-2006

Pagina 42

Definitie: Elementaire service Een elementaire services is een service, die op het laagste niveau een service verleent in een voor de business betekenisvolle wijze. Definitie: Samengestelde service Een Samengestelde service is een service, die een voor de business betekenisvolle service verleent door gebruik te maken van elementaire services en aan dit samenstel van services waarde toe te voegen door een eigen unieke combinatie van transformaties. Deze definities betekenen, dat hoger niveau services opgebouwd worden uit lager niveau services, waarbij er telkens waarde wordt toegevoegd door de wijze van combineren. Het schema hieronder illustreert dit:

Figuur 18: Een hiërarchie van services

Er is in dit hoofdstuk nog geen uitspraak gedaan over de vraag of services handmatig of geautomatiseerd worden uitgevoerd. Het antwoord op deze vraag is simpel: allebei. Zowel handmatige als geautomatiseerde services komen voor. Ook combinaties van beide, d.w.z. handmatige services, die wel door geautomatiseerde services worden ondersteund, maar waar menselijk beoordelingsvermogen nodig is voor het kunnen leveren van de service.

5.4. De rol van Business Process Management Zodra er sprake is van een hiërarchie van services wordt er ook orkestratie op meerdere niveaus uitgevoerd. Iedere service is immers verantwoordelijk voor het zelfstandig afwikkelen van alle benodigde bewerkingen om de service te kunnen leveren. Als daarbij andere services worden gebruikt, kan dit heel goed worden gerealiseerd d.m.v. een voor de service specifieke workflow. Ook deze workflow wordt derhalve hiërarchisch van aard. De hierboven getoonde figuur illustreert dit eveneens. Definitie: Business Process Management (BPM)

24-5-2006

Pagina 43

BPM kan worden gezien als een middel voor het managen van de business met de bedrijfsprocessen als centrale structuur. Definitie: Workflow Management (WFM) Het orkestreren van services binnen het werkgebied van een samengestelde service. Deze definitie sluit aan bij een ander onderscheid, dat vaak wordt gemaakt tussen BPM en WFM. Met WFM wordt vaak ook bedoeld, dat er een handmatige component is in het bewerkingsproces, dat door de WFM wordt ondersteund. Deze handmatige bewerkingen worden dan ondersteund door geautomatiseerde componenten. Denk daarbij bijvoorbeeld aan een callcenter. Hier wordt een handmatig proces (callcenter medewerker, die een klant te woord staat) ondersteund door een geautomatiseerd systeem om het gesprek te registreren, informatie te vergaren, via een systematische vragenlijst het probleemgebied in kaart te brengen en oplossingen voor te stellen vanuit een Kennisdatabase. De centrale sturing van de werkwijze van de callcenter medewerker wordt meestal vanuit een WFM component begeleid. Hetzelfde speelt meestal bij samengestelde services. Vaak is ook daar sprake van een handmatige component, die wordt bijgestaan door geautomatiseerde services. De sturing van deze samengestelde service wordt in dat geval eveneens verricht vanuit de WFM component. Dit borgt tevens, dat de samengestelde service op een gestandaardiseerde wijze kan worden aangestuurd vanuit andere services, die aan de betreffende samengestelde service behoefte hebben. Resultaten worden eveneens op een gestandaardiseerde manier terugontvangen. Het niveau, waarop sprake is van BPM of WFM is dan ook arbitrair. In feite convergeren deze begrippen binnen het kader van een SGA naar hetzelfde.

5.5. Het zakens ysteem als centrale spil In de huidige werkwijze binnen gemeenten is de informatie over zaken van een burger vaak verspreid over meerdere legacy applicaties of verspreid over verschillende overheden. Dit maakt het lastig zo niet onmogelijk om vanuit een frontoffice applicatie een overzicht van alle voor een burger relevante zaakinformatie te krijgen. Om dit probleem op te lossen zal alle zaakinformatie van een burger of bedrijf, centraal op één plek ter beschikking moeten komen. Hierdoor kan een frontoffice applicatie op eenvoudige wijze alle voor de klant relevante informatie ophalen en tonen. Tevens wordt hiermee de voorziening geboden om ook andere frontoffice kanalen binnen en buiten de gemeente de zaakgegevens te laten ontsluiten. Het GFO (Gemeentelijk Functioneel Ontwerp) ‘Zaken’ schrijft de minimale set van gegevens voor (met definities en technische specificaties) die als standaard geldt om centraal de basiskenmerken van een ‘zaak’ te kunnen verzamelen en gegevens over de ‘zaak’ te kunnen halen uit verspreide informatiesystemen. Het GFO Zaken definieert een ‘zaak’ als een samenhangende hoeveelheid werk met een gedefinieerde aanleiding en een gedefinieerd resultaat, waarvan kwaliteit en doorlooptijd bewaakt

24-5-2006

Pagina 44

moeten worden. Het GFO Zaken ontsluit en koppelt op een centraal punt de basisinformatie die op een zaak betrekking heeft: • de lopende en afgesloten procedures (zaken); • de status van procedures; • het subject (de burger, het bedrijf) dat het verzoek heeft gedaan; • de betrokkenen; • de actor het organisatieonderdeel, de medewerker) die het verzoek behandelt; • de stap in de procedure, waarmee de link naar het proces wordt gelegd; • de gekoppelde objecten en • het daarop betrokken adres. Zoals hierboven al besproken is het Business Process Management vooral verantwoordelijk voor de aansturing van services voor het afhandelen van vragen van burger en bedrijf. Het GFO “Zaken” kan daarbij worden gezien als de bijbehorende gegevensstructuur, waarin de onderhanden zaak wordt bijgehouden. De services, die gebundeld zijn in “Registreren Zaak” en “Beheren Zaak” bewerken deze gegevensstructuur op aangeven van BPM.

5.6. De rol van de Dienstenbus Hiervoor is benadrukt dat voor het realiseren van een SGA, services op een open en gestandaardiseerde manier met elkaar moeten kunnen communiceren. Dit resulteert in een aantal eisen die aan het communicatiemedium moeten worden gesteld. Deze eisen kunnen worden ingedeeld in een drietal groepen: 1. Robuustheid. In deze groep worden eisen ondergebracht, die te maken hebben met de robuustheid van de oplossing; 2. Gebruiksgemak. Deze tweede groep heeft als doel om eisen te formuleren om services te ontlasten van het bijhouden van veel boekhouding om met andere services te kunnen communiceren; 3. Flexibiliteit. Deze laatste groep bevat eisen, die beogen om de flexibiliteit en inzetbaarheid van het communicatiemedium te optimaliseren. Eisen, die tot de eerste groep Robuustheid behoren zijn: 1. De beschikbaarheid van het communicatie medium moet zeer hoog zijn. Het is immers de essentiële ruggengraat van de gehele organisatie. Zodra de communicatie tussen services verloren gaat, functioneert de gehele organisatie niet meer; 2. Het communicatiemedium moet blijven zorgdragen voor haar communicatietaak, zelfs als de omstandigheden dit moeilijk maken. Dit houdt bijvoorbeeld in, dat het communicatiemedium moet kunnen omgaan met het (lokaal) wegvallen van verbindingen, maar ook met het (tijdelijk) uitvallen van zenders en ontvangers van informatie; 3. Transparantie. Het communicatiemedium moet in staat zijn om eenduidig te kunnen rapporteren over de verzonden berichten, het moment van ontvangst en aflevering en eventuele problemen tijdens het verzendingsproces;

24-5-2006

Pagina 45

4. Servicegraad. Het communicatiemedium dient garanties te kunnen geven voor de snelheid, waarmee berichten kunnen worden gecommuniceerd en deze ook achteraf kunnen waarmaken. De tweede groep Gebruiksgemak kent de volgende eisen: 1. Het communicatiemedium moet voor alle services gebruikt kunnen worden. Ook als services verschillende talen spreken, moet het communicatiemedium in staat zijn hiertussen een brug te slaan; 2. Het communicatiemedium dient faciliteiten te bevatten om een bericht van een afzender naar meerdere geadresseerden te verzenden (abonnementen service); 3. Het communicatiemedium dient te beschikken over een repertoire aan open en gestandaardiseerde interfaces, waarvan services gebruik kunnen maken; 4. Het communicatiemedium dient te beschikken over een repertoire aan open en gestandaardiseerde protocollen, waarmee berichten kunnen worden samengesteld en verstuurd; 5. Het communicatiemedium dient faciliteiten te bieden om te kunnen achterhalen welke services beschikbaar en bereikbaar zijn. De derde groep Flexibiliteit bevat de volgende eisen: 1. Het communicatiemedium moet de vertaling van logische adressen naar fysieke adressen voor zijn rekening nemen om het mogelijk te maken om services onafhankelijk van het gebruikte communicatiemedium te kunnen inrichten; 2. Het communicatie medium dient zodanig te worden ingericht, dat deze onafhankelijk blijft van de inrichting van de services. Dit betekent bijvoorbeeld, dat het communicatiemedium vervangen kan worden zonder de services aan te tasten. Geen van de hierboven genoemde eisen aan het communicatiemedium doet een uitspraak over de te volgen technische implementatie. De keuze voor deze implementatiesoorten is afhankelijk van het gewicht dat een organisatie toekent aan de hierboven geïnventariseerde eisen. Om tot een gefundeerde keuze voor een technische oplossing te komen is het noodzakelijk deze oplossing af te beelden op de bovengenoemde eisen, de eisen een wegingsfactor te geven om tenslotte in deze beslissingmatrix een gewogen keuze te bepalen. In het hoofdstuk Technische Architectuur wordt dit nader uitgewerkt.

5.7. Inrichting van de frontoffice Kanaalonafhankelijkheid In het informatiemodel wordt de frontoffice ingericht met het serviceproces Kanalen. Daarmee worden alle kanalen, zoals balie, telefoon, post, internet, voice response, informatiezuilen, gebundeld tot één plek, waarmee burger en bedrijven interactie hebben. Ook elektronische communicatie met Ketenpartners vindt plaats via deze Kanalen koppeling. Om uiting te geven aan het feit, dat deze frontoffice inspeelt op de persoonlijke leefwereld van burger en bedrijf is hieronder deze frontoffice aangeduid als “Mijn Loket”. Het internetkanaal is daarbij een belangrijke

24-5-2006

Pagina 46

component, waarin informatieverschaffing en dienstverlening bij uitstek persoonlijk kunnen worden toegesneden. Gebruik van een portaal Het internetkanaal in de frontoffice wordt ingericht m.b.v. een portaal. Vanuit dit portaal worden alle onderliggende diensten aangeboden, waarbij het portaal zelf zorgdraagt voor authenticatie, autorisatie en de inrichting van persoonlijke voorkeuren voor de bediening van het portaal. Het internetkanaal van Mijn Loket is uiteraard slechts één kanaal in het grote aantal, waarvan de gemeente zich bedient en/of gaat bedienen. Aangezien het Referentiemodel Midoffice uitgaat van een kanaalonafhankelijk midoffice worden antwoorden naar aanleiding van klantvragen aan het Kanaal proces teruggegeven in een Uniform formaat. Het Portaal hoeft zich derhalve slechts te bekommeren om het uitpakken van dit Uniform formaat in een voor het Portaal geschikte representatie. Mijn Loket als integrator met ketenpartners Hoewel Mijn Loket primair is gedacht als een conventionele Website t.b.v. communicatie met de browser van een burger of een bedrijf, is er geen beperking aan de representatie, die met een dergelijk Portaal kan worden aangeboden. Naast het toepassen van een normale browser door de burger of het bedrijf biedt dit mogelijkheden om mobiele apparatuur, zoals telefoons of PDA’s, als kanaal via vrijwel dezelfde informatiestructuur te bedienen. Een geheel andere klasse van toepassingsmogelijkheden ontstaat als het Portaal van Mijn Loket tevens ingezet wordt met een representatie in de vorm van webservices. Op basis van aldus beschikbaar gemaakte services stelt de gemeente zich beschikbaar als een volwaardige B2B partner in de communicatie met andere overheidsinstellingen en vooral ook het bedrijfsleven. In een later stadium kan een dergelijke elektronische uitwisseling van gegevens ook met burgers gaan plaatsvinden. Hiermee biedt de gemeente de mogelijkheid tot een volledig geautomatiseerde verwerking bij zichzelf, maar tevens bij de aangesloten partnerorganisatie, het bedrijfsleven. Daarmee wordt optimale invulling gegeven aan het concept van Administratieve Lastenverlichting. Doorgroei in een keten van services Een frontoffice met achterliggend midoffice en backoffice voor een bepaald gebied van zorg (een afdeling, een dienst of een gehele gemeente) kan worden gezien als een samengestelde service voor dat gebied van zorg. Dit biedt mogelijkheden voor een kleinschalig begin en stapsgewijs doorgroeien. Deze eigenschap leidt er echter ook toe, dat er principieel geen einde is aan de combinatiemogelijkheden van deze frontoffices en backoffices van verschillende organisaties in eenzelfde keten of daarbuiten. Immers, via webservices kunnen alle organisaties voor het aanreiken van functionaliteit een beroep doen op services van een andere organisatie in of buiten de keten. Het is in principe zelfs denkbaar, dat er meerdere aanbieders zullen zijn van gelijksoortige services met onderscheidende kwaliteit- of economische kenmerken. Een vergelijking met accountantskantoren voor het voeren van een boekhouding of incassobureaus voor het vorderen van gelden ligt voor de hand. Er zijn op de markt meerdere aanbieders van

24-5-2006

Pagina 47

dergelijke services, waarvan organisaties (inclusief gemeenten) gebruik maken op grond van kwaliteitskenmerken die hen het meest aanspreken. Als dit model wordt doorgetrokken naar een situatie, waarin deze services elektronisch beschikbaar zijn, met van te voren te bepalen kenmerken, is het zelfs denkbaar, dat Business Rules een geautomatiseerde selectie kunnen maken uit de beschikbare services op grond van nauwkeurig in te regelen parameters van de aanvragende organisatie. Er is geen reden te veronderstellen, dat hieraan geografische grenzen moeten worden gesteld. De markt (afnemers en aanbieders) voor dergelijke services is in principe even groot als de connectiviteit van het Internet.

5.8. Invulling met standaard componenten De procesarchitectuur van het Referentiemodel is opgezet met behulp van generieke dienstverleningsprocessen. Daar hoort ook generieke dienstverleningsfunctionaliteit bij. Deze functionaliteit dient nader geïnventariseerd en gecategoriseerd te worden. In bijlage C staat hiertoe een eerste aanzet. Uitgangspunten voor deze eerste opzet is: • we brengen functionaliteit op het hoogste niveau onder als we deze als zelfstandige component kunnen inzetten / aanschaffen / laten ontwikkelen; • in de omschrijving van de functionaliteit moet altijd een werkwoord voorkomen; • per functionaliteit kunnen we een relatie leggen naar het proces in de procesarchitectuur, zodat we vanuit deze architectuur per proces de bijbehorende functionaliteit kunnen genereren. Het is een project op zich om dit overzicht compleet te krijgen. En het zal daarna de nodige inspanning om het overzicht actueel te houden. Elke landelijke ontwikkeling die de informatievoorziening van gemeenten raakt, kan tot aanpassing van het overzicht leiden. Wat kunnen we er mee? Het overzicht kan dienen als basis voor een aanbesteding. Gemeenten kunnen snel duidelijk maken welke functionaliteit gewenst is per component/thema. Leveranciers kunnen zodoende snel duidelijk maken welke functionaliteit zij kunnen leveren. Gemeenten kunnen snel in kaart brengen over welke functionaliteit men beschikt en welke functionaliteit met welke prioriteit gerealiseerd moet worden. Als elke gemeente per functionaliteit aangeeft met welk instrument deze is ingevuld, is dit waardevolle informatie voor gemeenten die de functionaliteit nog moeten realiseren. Er ontstaat de mogelijkheid om via benchmarks te meten hoever men met de e-gemeente is gevorderd. Bij landelijke ontwikkelingen met gevolgen voor de informatievoorziening van gemeenten, dient de architect van de landelijke projectgroep rekening te houden met de gemeentelijke informatiearchitectuur. De ontwikkeling kan pas aan gemeenten worden aangeboden, als helder is wat de gevolgen zijn met betrekking tot de noodzakelijke functionaliteit.

24-5-2006

Pagina 48

6. Technische architectuur Midoffice In dit hoofdstuk wordt ingegaan op de verschillende componenten van een midoffice. De nadruk ligt hierbij op de techniek. Vragen die hierbij aan de orde komen zijn: • Welke onderdelen van de midoffice blijven in de gehele migratiestrategie; • Welke componenten van de midoffice leveren het meeste resultaat.

6.1. Applicatie Integratie In het vorige hoofdstuk is het toekomstbeeld geschetst van een procesgerichte benadering van dienstverlening. De huidige applicatie architectuur sluit hier over het algemeen niet op aan. De eisen die aan een procesgerichte applicatie architectuur op basis van Service Georiënteerde principes wordt gesteld zijn: 1. het bewerkstelligen van gegevensconsistentie over alle procesonderdelen van de applicatie architectuur heen; 2. Een werkproces uit meerdere handelingen die ieder met een aparte component worden ondersteund; 3. Samengestelde toepassingen. Dit zijn aan elkaar gekoppelde componenten, waarbij iedere component een stap in een werkproces ondersteunt op basis van een eigen informatiearchitectuur. Veel van de huidige door gemeenten gebruikte applicaties zijn afkomstig uit het client-server tijdperk. Kenmerk van deze applicaties is dat ze ieder een eigen informatie-, proces- en objectmodel kennen. Daarbij wordt bovendien veelal gewerkt met een nogal gevarieerde lijst van dbms' en (database management systeem), programmeertalen, besturingssystemen en andere middleware. De samenwerking tussen deze bestaande applicaties en applicatiemodules wordt in de huidige situatie vaak op diverse wijzen geïmplementeerd. Vindt deze koppeling plaats op de presentatielaag, dan worden bijvoorbeeld screenscrapers en integratieservers ingezet. Is sprake van integratie op het niveau van gegevens of bedrijfsregels, dan worden RPC' s (Remote Procedure Call), ORB' s (Object Request Brokers), webservices of middleware ingezet. Gaat het om een koppeling die zich rechtstreeks op de onderliggende databases richt, dan wordt meestal gebruik gemaakt van databasekoppelingen, ODBC (Open Database Connectivity) of ETL-tool (Extract Transform Load). Deze applicaties zijn over het algemeen niet eenvoudig te ontsluiten. Integratie van deze applicaties in de huidige praktijk is erg complex, duur, foutgevoelig en slecht onderhoudbaar. Een Service Georiënteerde Architectuur benadering kan bij de realisatie van applicatie integratie een belangrijke rol vervullen. SGA is gebaseerd op twee principes: • het opsplitsen van een grote klus in kleine stapjes (modulariteit); • gebruiken van een goed gedefinieerde interface om individuele modules af te schermen van de buitenwereld (inkapseling of encapsulation).

24-5-2006

Pagina 49

Dit betekent dat een Service Georiënteerde applicatie zich veel makkelijker in een samengestelde toepassing laat opnemen dan een oud monolithisch systeem. Een applicatie gebaseerd op een Service Georiënteerde Architectuur bevordert bovendien het hergebruik van functionaliteit.

6.2. Webservices Webservices zijn gebaseerd op open standaarden conform specificaties van het World Wide Web Consortium (kortweg W3C). Services kunnen onderling op elkaar worden aangesloten via een servicebus of dienstenbus. Hierdoor kan een synchrone berichtenuitwisseling tussen services worden gerealiseerd.

6.3. Koppelingen Communicatie tussen twee applicaties kan grofweg op twee manieren plaatsvinden: synchroon en asynchroon. Synchrone communicatie is te vergelijken met een telefoongesprek. De ene applicatie maakt verbinding met een andere, stelt de vraag en wacht op het antwoord. Asynchrone communicatie is te vergelijken met e-mail. De ene applicatie stelt een vraag, maar hoeft niet te wachten op het antwoord. De vragende applicatie heeft ook geen harde garantie dat de vraag binnen bepaalde tijd beantwoord zal zijn, maar kan ondertussen wel doorgaan met andere dingen. Beide varianten hebben voor- en nadelen. De meest opvallende daarbij zijn: • Bij synchrone communicatie heeft de vragende applicatie meer zicht op wanneer het antwoord beschikbaar is. Er is geen garantie dat de verbinding tot stand komt (denk bijvoorbeeld aan een telefoon in gesprek), maar als die er is kan de vrager wachten tot het antwoord er is. • Bij asynchrone communicatie kan de vrager doorgaan met andere activiteiten. • Het asynchrone model is gemakkelijker schaalbaar te maken dan het synchrone model. De vrager heeft geen precies beeld nodig van de applicatie die zijn vraag beantwoordt, en zodoende kunnen er dus meer kandidaten zijn. • Het is mogelijk om met het asynchrone model een synchroon model te imiteren. In dit geval stuurt de vrager een bericht en wacht net zo lang tot het antwoord binnen is. • In de praktijk is synchrone communicatie efficiënter te implementeren dan asynchrone communicatie. Met name het idee van sessies (vergelijk met een telefoongesprek) is bij synchrone communicatie eenvoudig. Binnen een sessie kennen vrager en beantwoorder elkaar en kunnen ze efficiënt met elkaar communiceren. Bij het gebruik van webservices voor koppeling gelden de volgende aandachtspunten: • Er is geen gegevensintegratie en -verrijking mogelijk is, waardoor bij uitvraag uit meerdere back office systemen inconsistente antwoorden en andere ongemakken kunnen voorkomen. • Daarnaast zijn webservices in hun aard synchroon. Dit betekent dat bij de aanvraag direct response wordt verwacht. Het risico hierbij is dat het totale proces binnen de orkestratie zo zwak is als de zwakste schakel: bij het niet beschikbaar zijn van één van de systemen ligt de hele keten plat.

24-5-2006

Pagina 50

Voor integratie, bijvoorbeeld naar backoffice applicaties, kunnen een aantal mogelijke oplossingen worden ingezet. De 2 meest wenselijke zijn het gebruik van een broker (berichtenmakelaar) of een service bus (vaak aangeduid als Enterprise Service Bus, ESB of dienstenbus). In de komende paragrafen wordt de rol van de broker respectievelijk dienstenbus toegelicht.

6.4. Broker Een Broker is verantwoordelijk voor het afhandelen van het berichtenverkeer tussen het midoffice en de backoffices en het converteren van de diverse berichtenformaten die in de verschillende backoffices verschillend van formaat of techniek kunnen zijn. Bovendien levert de broker een belangrijke bijdrage in het opheffen van de communicatie problemen die zouden kunnen ontstaan, doordat het front en midoffice 24x7 beschikbaar moeten zijn, terwijl dat met de meeste backoffices niet mogelijk is. De derde functie die de broker vervult is het sturen van workflow. Sommige berichten moeten door meer dan een backoffice worden verwerkt (bijvoorbeeld een adreswijziging van een burger moet worden verwerkt door vrijwel alle Back Office systemen die bij de gemeente worden gebruikt). De broker ontvangt het bericht en bezorgt het in het juiste formaat (translatie en transformatie) op het juiste moment via de juiste route bij de juiste applicatie (Business Process Management, kortweg BPM). Teneinde de broker op de backoffice aan te kunnen sluiten is echter een adapter nodig, die bij de meest gangbare backoffices een ingewikkeld proces moet afhandelen om transacties te activeren in de backoffice. Dit komt omdat de meeste backoffices niet zijn ingericht voor het kunnen verwerken van geautomatiseerde transacties vanuit een ander geautomatiseerd systeem. Deze adapter kan gericht zijn op aansluiting op de applicatielogica (API, screenscraping, webservice) of aansluiten op dataniveau, zoals gegevens ophalen of muteren op databaseniveau door middel van bijvoorbeeld SQL. Aansluiten van backoffice applicaties kan zowel synchroon (direct) als asynchroon (buffer), zodat het elektronisch loket 24/7 beschikbaar is, ook als het backoffice dit niet is. Zo kunnen ook aanvragen die meerdere back office applicaties raken worden verwerkt, waarbij de broker het proces ‘orkestreert’ om deze aanvragen in de juiste volgorde langs de betreffende applicaties te leiden (bijvoorbeeld een bouwvergunning: eerst het GBA, dan percelen, bestemmingsplannen, welstand, milieu, bouw- en woningtoezicht enzovoort) Berichten moeten niet alleen in het juiste formaat maar ook op de juiste wijze worden aangeboden. Hiertoe dienen adapters: software die de informatieoverdracht tussen de broker en de verschillende front- en back office applicaties regelt. Een adapter realiseert een extern koppelvlak met een applicatie, waarbij gestandaardiseerde (functionele en technische) protocollen worden gebruikt.

6.5. Dienstenbus Om een Service Georiënteerde Architectuur (SGA) te implementeren moeten zowel de applicaties als de infrastructuur de SGA principes ondersteunen. Om een applicatie geschikt te maken voor

24-5-2006

Pagina 51

SGA moeten interfaces ontwikkeld worden op bestaande of nieuwe functies. Om de infrastructuur geschikt te maken moeten er faciliteiten gemaakt worden voor de routering van service aanvragen naar de juiste service providers. Hierbij moet rekening worden gehouden worden met het feit dat services eenvoudig kunnen worden vervangen door nieuwe implementaties. Een Enterprise Service Bus (ESB), ook wel Dienstenbus genoemd, beschikt over de kwaliteiten die dit mogelijk maken. Een Dienstenbus dient over de volgende kenmerken te beschikken: • De bus moet het mogelijk maken om applicaties asynchroon met elkaar te laten communiceren door middel van een publish/subscribe mechanisme; • De communicatie tussen applicaties moet onafhankelijk zijn van protocollen en berichtenformaat; • De bus is verantwoordelijk voor de communicatie tussen applicaties; • De bus is verantwoordelijk voor de regievoering van services tussen applicaties door het bewaken en samenstellen van diensten. Hiervoor moet de bus op de hoogte zijn van welke applicatie welke dienst verleent. Onderstaande figuur geeft de samenhang tussen de verschillende componenten van een Dienstenbus weer:

Figuur 19: Dienstenbus (Enterprise Service Bus)

Door deze kenmerken te combineren kan een dienstenbus als volgt worden gedefinieerd: Een Dienstenbus is een communicatiesysteem tussen applicaties met de kwaliteiten om de regie tussen diensten uit te voeren. Hieronder wordt ingegaan op de verschillende onderdelen binnen een dienstenbus. Wachtrij/Routering

24-5-2006

Pagina 52

Te vergelijken met de functionaliteit van een traditionele broker. Deze functionaliteit verzorgt voor de services die op de berichtenbus zijn geplaatst, de juiste routering naar andere services. Daarbij geldt dat voor asynchrone communicatie de mogelijkheid bestaat om te wachten op een antwoordbericht van een aangeroepen service. Abonnementendienst Hiermee wordt het mechanisme bedoeld, waarbij een leverende applicatie zich niet hoeft te bekommeren om geïnteresseerde gebruikende applicaties. De Dienstenbus zorgt er middels een abonnementensysteem voor, dat gebruikende applicaties zich kunnen abonneren op de diensten van vooraf bepaalde leverende applicaties. De Dienstenbus zorgt er daarbij voor, dat aan eisen van authenticatie en autorisatie worden voldaan. Berichtentransformatie Uit te wisselen gegevens tussen services in XML formaat kunnen worden getransformeerd. Als taal wordt hiervoor vaak XSLT gebruikt. Ook andere talen zijn mogelijk Berichtenvalidatie Voor de uitwisseling van berichten kan binnen een Dienstenbus gebruik worden gemaakt van XML Schema’s. Hiermee kan de structuur, inhoud en semantiek van berichten worden gegarandeerd. Diensten regievoering Voor de regie of orkestratie van de verschillende services op de berichtenbus, zijn specifieke diensten beschikbaar. Als standaard taal voor deze orkestratie lijkt BPEL (Business Process Execution Language) of BPEL4WS (BPEL for Webservices) over de beste kaarten te beschikken. BPEL wordt ondersteund door o.a. Microsoft, SAP, IBM en BEA en is een op XML gebaseerde taal waarmee een bedrijfsproces formeel wordt beschreven. In de procesbeschrijving wordt o.a. informatie vastgelegd over de uit te wisselen gegevens, regels waaraan gegevens moet voldoen en hoe omgegaan dient te worden met mogelijke overtredingen op deze regels. BPEL wordt vooral toegepast voor procesintegratie van applicaties met behulp van webservices. Het voorziet in een methodiek om het gebruik van de functies binnen de te integreren applicaties te coördineren binnen het bedrijfsproces, de zogenoemde orkestratie van de bedrijfsprocessen. De huidige BPEL specificatie wordt bewaakt door OASIS en lijkt zich te ontwikkelen tot een duidelijke standaard voor de afhandeling van meerdere synchrone en asynchrone services in samenwerkende en transactionele processtromen. De kern van BPEL ligt in: • het gebruik van webservices en WSDL (Web Services Description Language); • het gebruik van XML voor data uitwisseling; • het aanbod van standaard werkwijzen voor synchrone en asynchrone berichtuitwisseling. Diensten bekendmaking Een service waarbij diensten zichzelf kunnen aanbieden. Hierbij vraagt de Dienstenbus voor de uitvoering van een specifieke processtap een service die deze dienst kan leveren. Dit gebeurt met behulp van de webstandaard UDDI (Universal Description, Discovery, and Integration) wat te vergelijken is met een bibliotheek waarin verwijzingen naar via het internet beschikbare

24-5-2006

Pagina 53

webservices staan. Services die aan de juiste criteria voldoen kunnen zich hierbij aanbieden. Op basis van bedrijfsregels zoals SLA’s (welke in een business rules repository zijn vastgelegd) wordt dan de meest geschikte service geselecteerd. Naar verwachting zal het nog enkele jaren duren voordat deze functionaliteit op grote schaal beschikbaar is in te implementeren ESB oplossingen. Diensten validatie Het onderdeel van de Dienstenbus dat de validatie van geschikte services op basis van binnen de ESB vastgelegde bedrijfsregels voor zijn rekening neemt. De validatie bepaalt of services in aanmerking komen om bij bekendmaking, zoals hierboven beschreven, geselecteerd te worden. Ook hiervoor geldt dat dit voorlopig nog niet beschikbaar zal zijn in ESB oplossingen.

6.6. StUF StUF (Standaard Uitwisselings Formaat) is het standaard berichtenformaat voor gemeenten om de uitwisseling van gegevens tussen verschillende automatiseringssystemen binnen een gemeente mogelijk te maken. Om elektronische dienstverlening te realiseren zijn immers vaak gegevens nodig uit verschillende systemen. Door de afspraken hierover vast te leggen in een standaard, wordt bovendien voorkomen dat er in elke gemeente maatwerk moet worden ontwikkeld om de koppelingen te realiseren. Medio april 2006 heeft EGEM in samenwerking met de StUF Community, de definitieve versie van de StUF 2.0-serie vastgesteld: StUF 2.04 (EGEM aanbeveling). Deze eindversie heeft de doopnaam StUF XML gekregen omdat het verrijkt is met diverse XML-technologieën zoals SOAP, XSD schema en WSDL. StUF XML is een generieke standaard die voor willekeurige sectoren gebruikt kan worden. Om echter te komen tot concrete gegevensuitwisseling moet deze ingevuld worden voor een bepaalde sector. Voor een belangrijke sector is deze nu ingevuld en beschikbaar, namelijk voor basisgegevens met StUF-BG 2.04. De huidige StUF standaard voorziet nog niet in een berichtenuitwisseling volgens een Service Georienteerde Architectuur. Hiertoe dient de in een nieuwe versie (StUF 3.0) een uitbreiding te worden gegeven aan de huidige standaard. De versie zal naar verwachting het gebruik van services ondersteunen met de daarbij behorende definities in de vorm van XSD en WSDL beschrijvingen.

6.7. Portaal Portaalsoftware wordt om de volgende redenen ingezet: 1. Single Sign-on; 2. Personificatie van de lay-out van de webpagina’s; 3. Doorkoppelen naar achterliggende applicaties. Het is vooral het hierboven genoemde punt 3 dat nader aandacht behoeft. Doorkoppelen naar achterliggende applicaties kan worden gerealiseerd door middel van referenties naar deze applicaties via URL’s. Dit wordt meestal aangeduid als linken van applicaties. Dit mechanismen werken niet optimaal in een Service Georiënteerde Architectuur, omdat er inbreuk wordt gemaakt

24-5-2006

Pagina 54

op het uitgangspunt van vrij beschikbare services, die tot applicaties worden gesmeed via orkestratie ofwel Business Process Management. Zodra echter ook het achterliggende midoffice en backoffice gebaseerd is op Service Georiënteerde Architectuur ontstaat een interessant alternatief voor deze doorkoppelingen. Het achterliggende midoffice systeem kan immers in zijn geheel worden beschouwd als een achterliggende applicatie. De doorkoppeling kan dus altijd plaatsvinden naar hetzelfde entrypoint voor deze applicatie, namelijk de Business Process Manager (BPM). Deze BPM neemt als het ware de taak van het Portaal over, om de onderliggende vraag te dirigeren naar de meest geschikte service voor het uitvoeren van het gevraagde. Tevens levert deze service dan het bijbehorende antwoord. Zo beschouwd kan de rol van het Portaal zich beperken tot de volgende activiteiten: 1. Vertalen van de vraag naar een Uniform formaat; 2. Aanroepen van de Business Process Manager; 3. Terugontvangen van een antwoord in Uniform formaat; 4. Vertalen van het antwoord in een voor het Portaal geschikte representatie; 5. Teruggeven van het antwoord aan de aanvragende burger/bedrijf. De gehele kracht van het achterliggende midoffice kan op deze wijze gemobiliseerd worden voor het beantwoorden van aanvragen. Bovendien neemt deze kracht automatisch toe, naarmate de achterliggende midoffice verder wordt uitgebouwd. Zijn in het achterliggende midoffice services geoutsourced, dan blijven deze toch voortdurend automatisch beschikbaar voor het beantwoorden van vragen via het portaal. Indien deze functionaliteit van doorkoppelen naar de midoffice wordt ondergebracht in een standaard portlet, kan deze meerdere keren worden toegepast voor verschillende applicaties, waarmee een gebruiker op de bekende wijze een pagina kan componeren (Personificatie).

24-5-2006

Pagina 55

7. Transitiestrategie voor het Midoffice In dit hoofdstuk wordt ingegaan op de wijze waarop het midoffice binnen de gemeente zich kan ontwikkelen in de richting van een Service Georiënteerde Architectuur. Daarvoor worden allereerst de verschillende ontwikkelstadia voor het midoffice geschetst. Vervolgens wordt de route voor gemeenten aangegeven voor de overgang van de huidige gefragmenteerde architectuur naar een Service georiënteerde architectuur. Hierbij wordt een onderscheid gemaakt in korte termijn (binnen een jaar), middellange termijn (tussen de 1 en 5 jaar) en de lange termijn (langer dan 5 jaar).

7.1. Stadia van het Midoffice Om een beeld te geven van de fasen die bij de inrichting van een midoffice kunnen worden onderscheiden, is het goed stil te staan bij de verschillende stadia van een midoffice. In de komende 4 paragrafen worden de te onderscheiden stadia bij de inrichting van het Midoffice behandeld. 7.1.1. Eén Loket (Multi-Channel)

Figuur 20: Eén Loket (Multi-Channel)

In dit stadium is er één gemeenschappelijk loket voor de klanten van de gemeente gerealiseerd. Daarbij kenmerkt dit stadium zich nog wel door een sterke verkokering binnen de gemeentelijke dienstverlening aan de achterkant, de backoffices. Afdelingen zijn hier sterk sectoraal ingedeeld waarbij iedere afdeling zijn eigen systemen en gegevensverzamelingen beheert. De communicatie tussen de voorkant en de backoffices verloopt via provisorische en organisatorisch geregelde distributiekanalen. Deze distributiestructuur tussen kanalen en backoffices is door haar veelheid aan koppelingen (N x M) complex en foutgevoelig.

24-5-2006

Pagina 56

7.1.2. Organisatorisch Midoffice

Figuur 21: Organisatorisch Midoffice

Er bestaat in dit stadium een ingericht frontoffice met ondersteuning voor meerdere kanalen. Aan de achterkant, de backoffices, is nog steeds sprake van een sectorale indeling van de verschillende diensten. Tussen kanalen aan de voorkant en de sectoraal ingedeelde backoffices is nu een organisatorisch midoffice ingericht. Dit vormt de schakeling tussen het front- en backoffice. Het organisatieonderdeel dat voor dit midoffice verantwoordelijk is, zorgt op procedurele wijze voor de koppeling. Vaak gebeurt dit door de aanvragen aan de voorkant handmatig over te tikken in de systemen van de backoffices (de ‘draaistoel’ of ‘Alt-TabMidOffice’). Het aantal koppelpunten is in dit stadium ten opzichte van het in de vorige paragraaf (7.1.1) geschetste stadium sterk gereduceerd, namelijk N + M koppelingen (in plaats van N X M).

24-5-2006

Pagina 57

7.1.3. Technisch Midoffice

Figuur 22: Technisch Midoffice

Eén frontoffice met meerdere kanalen. In dit stadium worden de verschillende kanalen van het Eloket ook gebruikt door de medewerkers frontoffice van de gemeente. Tussen de kanalen aan de voorkant en de sectorgerichte backoffices is een volwaardig elektronisch midoffice gepositioneerd. Dit midoffice zorgt voor de automatische routering tussen front- en backoffice. De volgende onderdelen zijn binnen dit midoffice te onderkennen: Broker: dit zorgt op automatische wijze voor de routering van gegevens tussen de front- en backoffices. Hierbij behoort een orkestratiefunctie (BPM) waarin kan worden vastgelegd op welke wijze gegevensstromen dienen te worden gerouteerd. Gegevensmagazijn: hierin worden de voor het frontoffice benodigde gegevens vastgelegd. Dit is nodig om 24 x 7 beschikbaarheid van de elektronische dienstverlening aan de voorkant te kunnen garanderen. Deze gegevens zijn statisch (niet veranderlijk) van aard en worden daarmee ook aangeduid als koude data. Zakenmagazijn: hierin wordt de orkestratie tussen de front- en verschillende backoffices bijgehouden en de statussen van de aanvragen (of intakes) vanuit het frontoffice worden hierin vastgelegd. Deze gegevens zijn dynamisch (veranderlijk) van aard en worden daarmee ook aangeduid als warme data. Aan de achterkant (backoffices) kunnen in bovenstaand figuur nu ook de verschillende landelijke voorzieningen basisregistraties worden onderkend. Deze landelijke registraties worden gekoppeld aan de gemeentelijke registraties welke sectoraal zijn georganiseerd binnen de verschillende

24-5-2006

Pagina 58

backoffice afdelingen) en voeden daarmee het gegevensmagazijn zoals deze nu in het midoffice is vormgegeven.

7.1.4. Midoffice conform Service Georiënteerde Architectuur

Figuur 23: Midoffice in een Service Georiënteerde Architectuur

In dit stadium wordt het midoffice steeds meer het hart van de gemeentelijke informatievoorziening. Eenvoudige producten (zoals een Uittreksel, Parkeervergunning of WOZtaxatie, -aanslag en bezwaar) schuiven op van het backoffice naar het midoffice. Basis- en procesgegevens komen steeds meer centraal beschikbaar met als voordeel dat hierop een betere sturing op zowel operationeel (orkestratie) als tactisch en strategisch niveau mogelijk wordt. In dit stadium is te zien hoe dit zich verhoudt met het in paragraaf 5.2 geschetste Informatiemodel Midoffice. Daarin is tevens de verschuiving van traditionele legacy taaksystemen naar taakdiensten als services te herkennen.

24-5-2006

Pagina 59

7.2. Routeplan In dit hoofdstuk worden de volgende termijnscenario’s uitgewerkt: Korte termijn: Gericht op een termijn van ongeveer een jaar. Noodzakelijke aanpassingen die op korte termijn dienen te gebeuren. Korte termijnoplossingen kenmerken zich in de praktijk vaak door beperkte houdbaarheid, bijvoorbeeld omdat bewerkelijke handmatige actie nodig is doordat oplossing niet goed onderhoudbaar is. Middellange termijn: Gericht op een termijn van tussen 1 en 5 jaar. De oplossing die hier uit voorkomt, is structureler dan korte termijn oplossing, noodzakelijk als houdbaarheid ‘op raakt’ en lange termijn oplossing niet op tijd komt. Lange termijn: Langer dan 5 jaar. Structureel, flexibel, maar niet snel beschikbaar en vaak afhankelijk van andere processen zoals beslissingstrajecten. 7.2.1. Korte termijn Op korte termijn is het aan te bevelen de aandacht te richten op het inrichten van een geautomatiseerd frontoffice. Het is wenselijk dat gemeenten voor een aantal eenvoudige transacties het mogelijk maken dat burgers een aanvraag via het webkanaal elektronisch kunnen aanbieden en de status van hun aanvraag kunnen volgen. Om dit te bereiken dient de aanvraag elektronisch via een webformulier te kunnen worden ingediend en opgeslagen. Bij voorkeur dient deze registratie plaats te vinden in een daartoe speciaal ingericht midoffice zakenregister van de gemeente. De medewerker van de dienst moet de aanvraag in het Zakensysteem accepteren. In het ideale geval zal de aanvraag dan automatisch worden gerouteerd naar het betreffende backoffice (systeem), in veel gevallen wordt de aanvraag handmatig ingevoerd in het legacy backoffice systeem. De afhandeling van de zaak gebeurt vervolgens geheel in het backoffice. Het Zakensysteem wordt (handmatig of elektronisch) gevoed met statuswijzigingen en bijzonderheden die voor de klant van belang zijn. De klant wordt via emailnotificaties van statuswijzigingen op de hoogte gesteld en kan de voortgang volgen door in te loggen op het Mijn Loket onderdeel van het gemeentelijke portaal. 7.2.2. Middellange termijn Op de middellange termijn zal niet alleen de aanvraag, maar het hele product in elektronische vorm aan klanten en ketenpartners op elektronische wijze moeten worden aangeboden. In deze zienswijze staat het zakensysteem centraal. Zowel de klant als de medewerker die de zaak behandelt werken in dit scenario uiteindelijk in hetzelfde Zakensysteem. In tegenstelling tot het korte termijn scenario wordt niet het Zakensysteem door het bronsysteem (legacy) op de hoogte gehouden van de voortgang, maar wordt het legacysysteem bij afronding van de zaak door het Zakensysteem bijgewerkt. Het Zakensysteem is in dit geval het bronsysteem.

24-5-2006

Pagina 60

Deze strategie kan voor een selectie van producten of voor alle producten in het legacysysteem worden toegepast. Door toepassing van deze “salamitactiek” kan het legacysysteem eventueel in zijn geheel worden vervangen. Voordeel van deze strategie van vernieuwing per product is dat de doorlooptijd in vergelijking met de vervanging van een heel systeem veel korter is, en dat de nieuwe functionaliteit snel voor de klant c.q. ketenpartner beschikbaar is. Nadeel van deze variant is dat er maatregelen moeten worden genomen om de synchronisatie met de legacy goed te laten verlopen. Hiervoor moet functionaliteit worden gerealiseerd en beheer worden ingericht. Bij volledige systeemvervanging is dat niet nodig. De voorwaarden voor gemeenten om succesvol een Migratiestrategie op middellange termijn te starten is dat de basisgegevens van de gemeente uit de legacysystemen worden geïsoleerd (in de kernregistraties) en middels webservices ter beschikking gesteld voor gemeenschappelijk gebruik door medewerkers, klanten en ketenpartners. Adviezen om de volgende ontwikkelingen te ondersteunen: • Start met de inrichting van een generiek, voor alle gemeentelijke diensten te gebruiken, zakensysteem. In dit zakensysteem liggen de procesgegevens van alle gemeentelijke zaken opgeslagen. De inhoudelijke gegevens (zaakdossiers) worden eveneens opgeslagen in het zakensysteem. Het zakensysteem wordt geïmplementeerd als een horizontaal document management systeem t.b.v. de frontoffice en midoffice. Backoffice medewerkers raadplegen en muteren dit systeem bij de behandeling van zaken. •

Bestaande legacy systemen zijn nu vaak gebouwd zonder echte scheiding van bedrijfslogica en gebruikersinterface. Voor toekomstig te ontwikkelen systemen is het gewenst om deze strikte scheiding wel aan te brengen waarbij zowel de logica als de gebruikersinterface als zelfstandig opererende en aan te roepen services ter beschikking kan worden gesteld. Door deze scheiding en het tussenliggende open koppelvlak van services ontstaan de mogelijkheden om nieuwe applicaties te “componeren” uit bestaande componenten.

•

Bestaande applicaties worden omgebouwd naar een service georiënteerde applicatie volgens een 3 lagen architectuur (gegevens-, logica- en presentatielaag). De gegevenslaag is in veel client-server systemen in aanleg reeds aanwezig, maar niet via een open koppelvlak aan elkaar verbonden. Door dit koppelvlak op basis van services te herbouwen ontstaat de mogelijkheid om de gegevens van de applicatie te bewerken zonder gebruik te maken van de ingebouwde businesslogica en presentatielaag. Dit kan in sommige gevallen een goede route opleveren om nieuwe services te realiseren op basis van een bestaande gegevensstructuur en implementatie.

•

Afscheid nemen van bestaande gesloten legacy applicaties welke niet conform SGA principes te ontsluiten zijn. Maak de keuze voor open applicaties (Open standaarden, Open source) gebaseerd op SGA principes. Hierbij dient wel te worden opgemerkt dat dit niet zonder slag of stoot zal gaan. De bedrijfsvoering binnen de gemeente is vaak georganiseerd rondom bestaande ICT oplossingen waarmee een sterke afhankelijkheid met deze legacy applicaties is ontstaan. Daarbij gelden vaak langdurige contracten en

24-5-2006

Pagina 61

bindende afspraken met leveranciers en andere partijen die niet eenvoudig op te heffen zijn. •

Inrichting van een stabiele omgeving voor de toegang tot basisgegevens. Hierbij speelt de kernregistratie een cruciale rol. Door een kernregistratie in te richten worden gemeenten ontkoppeld van het nog voortdurend bewegende veld van basisregistraties. Op basis van ontwerpen van het programma Stroomlijning Basisgegevens en het Programma Architectuur van ICTU kan een gegevensmodel worden geïmplementeerd in de kernregistratie die kan worden afgebeeld op de op enig moment voorhanden databases met basisgegevens. De rest van de ICT structuur van de gemeente kan hierop worden gebaseerd, omdat deze stabiel blijft. Zodra één of meer basisregistraties hun intrede doen, wordt de afbeelding van de kernregistratie op de onderliggende gegevensdatabases aangepast. Voor de rest van de gemeentelijke infrastructuur is dit transparant. Zodra het stelsel basisregistraties definitief in volledige omvang is ontwikkeld en ingevoerd, kan eventueel een deel van deze kernregistratie worden afgebouwd, omdat deze gegevens dan via de basisregistraties beschikbaar zijn. Deze beschrijving van de kernregistratie gaat uit van het beschikbaar maken van gegevens voor lezen. Hieraan is ook de eerste behoefte. Een tweede behoefte aan muteren van gegevens ontstaat op basis van twee verschijnselen: −

Muterende processen worden uit een bijhoudingsadministratie overgebracht naar de frontoffice. Een voorbeeld hiervan kan zijn het doorgeven van een adreswijziging. Op middellange termijn kan worden volstaan met het handmatig verwerken van dit soort mutaties. Zolang via raadplegen kan worden vastgesteld, dat de mutatie in principe zou kunnen worden uitgevoerd is het handmatig aanbrengen van de mutatie geen arbeidsintensieve taak.

−

Gebruikende processen van basisgegevens stellen vast, dat deze niet overeenkomen met hun gegevens. In dit geval dient gebruik te worden gemaakt van een terugmeldingsprocedure aan de bijhoudingsadministratie. De kernregistratie kan hiervoor zodanig worden ingericht, dat ook dergelijke gegevens tijdelijk worden vastgelegd tot het moment, waarop de bijhoudingsadministratie een onderzoeksprocedure heeft uitgevoerd, waarna vaak de basisgegevens zijn bijgewerkt. Na het voltooien van de onderzoeksprocedure kan het extra vastgehouden gegeven uit de terugmeldingsprocedure komen te vervallen.

•

Samenbrengen van bestaande initiatieven voor de ontsluiting van de organisatie naar burger/bedrijf en ketenpartners. Mijn Loket kan hierbij als een eerste iteratie worden beschouwd.

•

Start met de inrichting van de besturingsstructuur, die in hoofdstuk 4 is beschreven. Het is daarbij wenselijk, dat er minimaal reeds een zakensysteem volgens het GFO Zaken beschikbaar is (de services “Registreren Zaak” en “Beheren Zaak”). Initiatieven uit de vorige punten worden binnen deze besturingsstructuur geordend en systematisch verder uitgebreid. Het vormgeven van afhandelingprocessen en –services kan daarbij stapsgewijs worden ingevuld. Voor processen, waarvoor nog geen ondersteunende

24-5-2006

Pagina 62

serviceprocessen beschikbaar zijn worden deze (tijdelijk) vervangen door een handmatige interface. •

Besteedt meer dan gebruikelijke aandacht aan het verkrijgen en behouden van inzicht in de kwantiteiten van informatiestromen. Zet hiervoor vroegtijdig een goed rapportagesysteem op, zodat het nemen van vervolgstappen kan worden gestuurd door informatie uit het functioneren van de actuele situatie

7.2.3. Lange termijn 4 Uit het onderzoek “Van trendvolger tot elektronische superstore” wordt de daarin aangereikte strategie voor de lange termijn voor gemeenten relevant geacht. Deze aanpak bevat grofweg de volgende hoofdactiviteiten: • Inrichten aansturing en beleggen verantwoordelijkheden; • Uitvoeren gemeentebrede inventarisatie van wat er aan initiatieven reeds loopt; • Uitwerken gemeentebrede visie elektronische dienstverlening; • Nader invullen van de randvoorwaarden voor een succesvolle elektronische dienstverlening: − Processen; − ICT-infrastructuur; − Gegevens en gegevensverzamelingen; − Praktische en juridische kwesties; − Organiseren van wilskracht. • Inhoudelijk verder ontwikkelen van elektronische diensten en producten; • Selecteren en implementeren bouwstenen van de elektronische dienstverlening; • Inrichting van de benodigde besturingsstructuur in de Informatie architectuur voor het kunnen aansluiten van nieuw te ontwikkelen componenten in een gemeenschappelijk raamwerk. Veel gemeenten hebben reeds stappen gezet op deze weg, maar vaak is dit niet als expliciet actieplan benoemd. Ook is er vaak geen directe koppeling tussen gemeentelijke beleidsthema’s zoals veiligheid, handhaving en de bijdrage van ICT initiatieven aan deze beleidsthema’s. Juist voor het ontwikkelen van gemeentelijke dienstverlening onder architectuur is het van belang verbinding te leggen met beleidsthema’s en doelstellingen zodat het ontwikkelen van deze architectuur direct ook een zichtbare bijdrage levert aan deze beleidsthema’s. Zoals eerder gezegd: ontwikkelen onder architectuur kan kleinschalig starten. Dit biedt de mogelijkheid om stap voor stap de architectuur in te voeren via projecten die een bijdrage leveren aan de beleidsdoelstellingen (zoals 65% dienstverlening online, eenmalig gegevensuitvraag, administratieve lastenverlichting, fraudebestrijding). Kortom: de gemeenten hebben de ruimte om gezien de eigen situatie en de landelijke ontwikkelingen een specifiek migratiescenario op te zetten. Dit wordt in de volgende paragraaf nader uitgewerkt. 4

“Van trendvolger tot elektronische superstore”, Universiteit van Tilburg, Ordina, maart 2006

http://www.egem.nl/kennisbank/externeomgeving/routeplanneregemeente/bzk-van-trendvolgertot-elektronische-superstore.pdf/download

24-5-2006

Pagina 63

7.3. Scenario’s Zoals in de vorige paragraaf is aangegeven kan de migratie naar een Service Georiënteerde Architectuur in stapjes uitgevoerd worden. Daarbij zijn lokale keuzen van een gemeente en de landelijke ontwikkelingen en verplichtingen richtinggevend. Hieronder wordt aan de hand van twee 5 schema’s aangegeven op welke wijze een gemeente tot een eigen scenario kan komen.

Gemeente Burgers

Gemeente Klanten

ipatie c i t r a rp Burge having Hand

e bli u P

ke

ns e i d

tv

Ad m on ini tb str ur ea atie uc ve ra la tis ste er ing n,

E-gemeente

nin e l er

g

serviceketen

transacties loket

Gemeente Ketenpartners

Figuur 24: Scenario voor E-gemeente

De gemeente onderhoudt relaties met burgers, klanten en ketenpartners. De gemeente heeft een relatie met burgers doordat burgers de leden van de gemeenteraad kiezen. Ook bij de handhaving heeft een gemeente relaties met burgers, bijvoorbeeld bij de bestrijding van fraude. Daarnaast heeft de gemeente een dienstverlenende relatie met klanten. Denk bijvoorbeeld aan het verstrekken van een paspoort of het verlenen van een bouwvergunning. Tenslotte heeft een gemeente ook veel contact met andere overheden en bedrijfsleven bij het uitvoeren van taken. Denk aan het CWI en re-integratiebedrijven in het kader van de bijstandsuitkering. De interactie tussen gemeente en haar relaties kan vergaand ondersteund worden met ICT. In het bovenstaande model worden drie fasen onderkend, te weten het aanbieden van elektronische loketten, het online verrichten van transacties en het (her)inrichten van de serviceketen. Via de elektronische loketten wordt informatie verstrekt over diensten en producten. Voor de afhandeling moet de cliënt zich richten tot een fysiek loket van een overheidsinstelling. Met online transacties kunnen diensten en producten tijd- en plaatsonafhankelijk worden afgenomen, zoals bij de inkomstenbelasting en het verkrijgen van een uittreksel uit het bevolkingsregister. Na het 5

Gebaseerd op een artikel van R. During in Face-to-face. Jaargang 2, nummer 1, voorjaar 2004, Capgemini

24-5-2006

Pagina 64

(her)inrichten van de serviceketen is het mogelijk het leveren van diensten en producten volledig achter de schermen plaats te laten vinden, zoals bij de kinderbijslag waar de burger niet meer om hoeft te De mate waarin gemeenten de relaties gaat ondersteunen met ICT hangt af van de doelstellingen en ambities die een gemeente heeft. De ene gemeente kan het primaat leggen bij het verbeteren van de publieke dienstverlening, de ander op handhaving (fraudebestrijding) of bijvoorbeeld ketensamenwerking. Vanuit deze gemeentelijke doelstellingen kan nagegaan worden welke ICT initiatieven een belangrijke bijdrage leveren aan deze gemeentelijke doelstellingen. Hieruit kunnen prioriteiten gesteld worden. Daarnaast zijn er ook landelijke, soms verplichte, ontwikkelingen die zonder meer uitgevoerd moeten worden. Ook deze ontwikkelingen kunnen in verband gebracht worden met de doelstellingen van de gemeente. Ter illustratie is hieronder een voorbeeld opgenomen waarin een aantal ICT gerelateerde projecten gekoppeld zijn aan doelgroep, doelstelling en fasering.

E-gemeente

Opschonen Databestanden (handhaving)

Gemeente Burgers

Basis registraties Besluiten On-line

Multi-channel Digitaal loket (SUWI) toekomst

Mijn loket Eén digitaal loket Gemeente Klanten

serviceketen

…

transacties Digitaal loket (SUWI) beperkte opzet WMO-loket

loket

Gemeente Ketenpartners

Figuur 25: Scenario voor E-gemeenten met ICT gerelateerde projecten

De mate waarin de migratie naar een Service Georiënteerde Architectuur kan plaatsvinden is sterk afhankelijk van de ambitie die een individuele gemeente heeft. De komst van veel landelijke initiatieven biedt een kans om tegelijk met de implementatie van die landelijke initiatieven, zoals basisregistraties, de gemeentelijke architectuur stap voor stap service gericht te maken. Daarmee wordt overigens tegelijk bewerkstelligd dat de implementatie van andere toekomstige ontwikkelingen vereenvoudigd wordt. Immers, op het moment dat de architectuur meer en meer

24-5-2006

Pagina 65

servicegericht is zullen aanpassingen van de ICT ondersteuning binnen een gemeente steeds 6 eenvoudiger worden.

6

De suggestie is gedaan om een hulpmiddel te ontwikkelen waarmee een gemeente, ten tijde van het invoeren van allerlei projecten, de omvorming naar SGA kan monitoren. Een vragenlijst die projecten hierop toetst en een monitor voor de algehele architectuur zou een mooi instrument zijn om bijvoorbeeld jaarlijks de stand van zaken op te maken.

24-5-2006

Pagina 66

Bijlage A. Midoffice Woordenboek Hieronder is een alfabetisch woordenboek opgenomen van alle terminologie, die de werkgroep gedurende haar werkzaamheden is tegengekomen in relatie tot het begrip Midoffice. Per begrip wordt een definitie gegeven en de raakvlakken met andere begrippen kort aangeduid. Begrip Omschrijving Abonnementen Geeft een burger of een medewerker de mogelijkheid om bij verschillende onderwerpen aan te geven of signalering gewenst is via mijnloket, email, telefoon of sms. Zich door intekening of betaling van het recht verzekeren op geregelde ontvangst van een krant, een tijdschrift enz. of tijdelijke gebruikmaking van een instelling Afspraken Maakt het mogelijk een beschikbaar tijdstip als afspraak te selecteren waarbij rekening wordt gehouden met de agenda' s van de behandelende medewerkers. Mondelinge of schriftelijke overeenkomst Architectuur Architectuur is als benadering en begrip afkomstig uit de wereld van informatievoorziening. Een architectuur beschrijft de samenhangende structuur van de informatievoorziening, de daarmee te ondersteunen bedrijfsomgeving en de benodigde technische componenten. De architectuur van een organisatie omvat ook de manier waarop de informatievoorziening bijdraagt aan de doelstellingen van de organisatie, plus de veranderstrategie die nodig is om die doelstellingen te realiseren. Het architectuurmodel van de Elektronische Overheid onderscheidt drie lagen: bedrijfsarchitectuur, informatiearchitectuur en de ICT- of technische architectuur. Invulling geven aan een architectuur waarmee nieuwe doelstellingen zoals de andere overheid worden gerealiseerd, vergt investeringen. Bestaande applicaties en systemen moeten worden aangepast of vervangen, processen moeten worden vernieuwd en de organisatie als geheel moet zich nieuwe werkwijzen eigen maken Asynchrone communicatie Communicatie tussen mensen en/of systemen die niet gelijktijdig online zijn. Bijvoorbeeld e-mail. Authenticatie Proces waarbij een computer of applicatie nagaat of een gebruiker, andere computer of applicatie daadwerkelijk is wie hij beweert te zijn. Authenticatie gebeurt meestal door het aanloggen met een gebruikersnaam en wachtwoord. 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. Autorisatie Maakt het mogelijk per autorisatieobject (groepen) een geautoriseerde te kunnen koppelen en groepen geautoriseerden (rollen) aan te kunnen maken, wordt aangeroepen vanuit andere functionaliteit met als input het autorisatieobject, een eventuele parameter en een gebruikersnummer en als output of deze gebruiker

24-5-2006

Pagina 67

geautoriseerd is. Machtiging, verlening van een bevoegdheid. Backoffice Afdelingen en medewerkers die geen direct contact met klanten onderhouden, maar het leveren van diensten aan klanten ondersteunen, bijvoorbeeld ontwikkel-, administratieve en kantoorafdelingen en systeembeheer. Afdelingen en medewerkers die ondersteuning bieden aan de dienstverlening, maar zelf geen direct contact met klanten hebben. Zoals het systeembeheer, administratieve afdelingen en ontwikkel- en kantoorafdelingen Balie Intake Maakt het baliemedewerkers mogelijk intakes in het zakensysteem op te slaan en mogelijk intakes ten behoeve van primaire processen te verzorgen, zodat het bijbehorende werkproces gestart wordt. Basisgegevens Incl Geometrie Kopie van gegevens vanuit backoffice registraties, conform nieuwe versie GFO basisgegevens, op te leveren door EGEM/SBG projectgroep. Basisregistratie De authentieke landelijke registraties van personen, gebouwen, adressen, kadaster, topografie en ondernemingen en andere organisaties Beschikkingen Een beschikking is een subproduct van een hoofdproduct, net zoals een klacht. Registratie van alle beschikkingen een set gegevens conform het GFO zaken. Macht om over iets naar goedvinden te beschikken, besluit dat iets wettelijk of juridisch regelt. Beslisboom Een hiërarchie van vragen die de gebruiker naar de juiste beslissing leidt. Dit maakt het mogelijk webformulieren of vragen op webformulieren te selecteren. Zie ook , een beslisboom kan functioneren als vraagtrechter. Bestuurlijke Publicaties Groepeert de publicaties in vergaderingagendapunten, waarbij (Raads Informatie Systeem) ook raadsleden (woordvoerders, indieners moties) worden gekoppeld. Betalen Een functionaliteit die het mogelijk maakt het verschuldigde bedrag) aan de rechthebbende te doen toekomen. Maakt het mogelijk gebruikers te laten betalen. BPEL

24-5-2006

BPEL staat voor “Business Process Execution Language” en is een specificatie ondersteund door o.a. Microsoft, SAP, IBM en BEA. BPEL is een op XML gebaseerde taal waarmee een bedrijfsproces formeel wordt beschreven. In de procesbeschrijving wordt o.a. informatie vastgelegd over de uit te wisselen gegevens, regels waaraan gegevens moet voldoen en hoe omgegaan dient te worden met mogelijke overtredingen op deze regels. BPEL wordt vooral toegepast voor procesintegratie van applicaties met behulp van webservices. Het voorziet in een methodiek om het gebruik van de functies binnen de te integreren applicaties te coördineren binnen het bedrijfsproces, de zogenoemde orkestratie van de bedrijfsprocessen.

Pagina 68

Business Process Management (BPM)

Regievoering over services in de context van de diensten die moeten worden verleend. BPM kan worden opgevat als een specifieke service die de voor de afhandeling van een proces de benodigde servicemodules aanstuurt met de correcte informatie voor het verlenen van de dienst en dat daarbij doet in de juiste volgorde.

Broker

Een broker is een softwarematig verleende dienst die zorgt dat de inhoud van het ene systeem automatisch doorgegeven wordt naar één of meerdere andere systemen. Vaak ook aangeduid als Berichtenmakelaar.

Catalogus Management

Mogelijkheid om de (product)catalogus te beheren. Catalogus management is hetzelfde als assortimentsmanagement. Dienstverlening bepaalt het aan te bieden assortiment met de vrijgegeven kanalen en de diepgang. Een rechtstreekse conversatie via internet (synchrone communicatie) Hiermee kan de inhoud van webpagina’s (content) van een website worden onderhouden, beheerd en gepubliceerd zonder dat technische kennis noodzakelijk is. Het systeem haalt content, structuur en vormgeving uit verschillende bronnen. De vormgeving is doorgaans vastgelegd in sjablonen (templates). De content wordt in de juiste vormgeving op de juiste plaats in de structuur gepubliceerd. Met behulp van een editor kunnen teksten worden gemaakt die rechtstreeks in het CMS kunnen worden gebruikt. Hiermee krijgt de organisatie een integraal beeld van de klant waardoor het mogelijkheid wordt om op structurele en analytische wijze de dienstverlening naar de klant te verhogen. Maakt het mogelijk om voor alle kanalen van het klantcontactmoment de zaak/case/dossier erbij kunnen zoeken. Een Dienstenbus is een communicatiesysteem tussen applicaties met de kwaliteiten om de regie tussen diensten uit te voeren. De aan te sluiten applicaties hebben bij voorkeur een (web) service als verschijningsvorm. Dit is echter niet noodzakelijk, door middel van adapters zal het ook mogelijk zijn om bijvoorbeeld traditionele legacy applicaties te aan te koppelen. Gemeenschappelijk systeem van en voor de overheid. Overheidsinstellingen kunnen met DigiD de identiteit verifiëren van klanten die gebruik maken van haar elektronische diensten. Op dit moment kent DigiD deze klanten een gebruikersnaam met wachtwoord toe. Naar verwachting komt DigiD in de tweede helft van 2005 beschikbaar voor bedrijven. Informatie achter slot en grendel klaargezet voor beantwoording van de klantvraag: doe mij alles wat je van me weet. Relatie met Authenticatie/ CMS/ DMS zaak en basisregistraties. Maakt het mogelijk documenten te creëren volgens huisstijltemplates op basis van in te geven tekstblokken en

Chat Content Management Systeem (CMS)

Customer Relationship Management (CRM)

Dienstenbus

DigiD

Digitale Kluis

Document Creatie

24-5-2006

Pagina 69

automatisch op te halen gegevens. Document Management Systeem (DMS)

Dossiers E-Loket E-Mail Management Faq Favorieten

Formulierontwerp

Maakt het mogelijk om elektronische, niet gestructureerde informatie te beheren. Met een Electronic Document Management Systeem (EDMS) kunnen elektronische documenten beheerd worden gedurende hun gehele levenscyclus, inclusief o.a. registratie en versiecontrole, document integriteit, opzoeken, raadplegen, verspreiden en archivering. Beheren van dossiers, documenten binnen deze dossiers en versie van deze documenten. Groepeert producten, webformulier en zaakfunctionaliteit en levert een elektronische/webgebaseerde view op relevante informatie. Centraal beheer van e-mail binnen een organisatie. Dit kan in het DMS. Maakt het mogelijk vragen met bijbehorende antwoorden in te voeren en te tonen, moet sorteerprioriteiten ondersteunen, ook op basis van aantal raadplegingen. Geeft gebruikers de mogelijkheid verwijzingen naar functionaliteit of naar externe webadressen te groeperen op één webpagina, waarbij tevens kan worden aangegeven welke favorieten op de persoonlijke portaal pagina moeten verschijnen. Voordat een formulier gepubliceerd wordt moet het ontworpen worden. Ontwerp en publicatie worden vaak gedaan m.b.v. een formulierensysteem. Zie relatie e-formulieren, Resultmaker.

Forum

Maakt het mogelijk om te reageren op vragen, opmerkingen of tips van anderen waarbij de ' gesprekken'bewaard blijven en voor iedereen te lezen zijn. Dit te vergelijken met een prikbord waarop iedereen kan meelezen en reageren. Hierdoor kunnen meerdere mensen er profijt van hebben.

Geautomatiseerde Telefonische Informatie Verstrekking

Maakt het mogelijk om allerlei informatie die de klant via de website kan opvragen óók via de telefoon kan opvragen, menugestuurd, volledige geautomatiseerd.

Gebruikersprofiel

Een gebruikersprofiel is informatie over de registratie van een geïdentificeerde internetgebruiker die bepalend is voor de wijze waarop de gepersonifieerde informatie van de burger in zijn elektronisch loket wordt getoond. Dit bepaalt wat de gebruiker krijgt te zien aan content en conform autorisatieregels alsmede voorkeursinstellingen in het gepersonifieerde portaal. Geeft systemen de mogelijkheid zich te abonneren op wijzigingen (basis)gegevens en deze te importeren in de eigen systemen. Geeft de mogelijkheid om opmerkingen m.b.t. (basis)gegevens te kunnen invoeren en bewaken. Op het moment dat waarden van basisgegevens conflicteren moet er feedback ontstaan naar de authentieke bron. De verantwoordelijke voor de authentieke bron bepaalt de waarheid en daarmee de uiteindelijke waarde. Hierin worden gegevens op gestandaardiseerde wijze vastgelegd. Bevat in ieder geval alle bekende basisregistraties.

Gegevens Distributie Gegevens Distributie Feedback

Gegevensmagazijn

24-5-2006

Pagina 70

Gemeentelijk Functioneel Ontwerp (GFO)

Identificatie Intake Internetkassa Kaart Aanbodgericht Kaart Loketgericht Kennissysteem

Kernregistraties

Ketenintegratie

Ketenpartners Klantbeeld Klantcontactcentrum Koppelvlak Management Informatie

Meta-Informatie MijnLoket Mobiel Intake

24-5-2006

Beschrijft de minimale set van gegevens voor (met definities en technische specificaties) die als standaard geldt om centraal de basiskenmerken van een ‘zaak’ te kunnen verzamelen en gegevens over de ‘zaak’ te kunnen halen uit verspreide informatiesystemen Een "zaak" is in het GFO Zaken gedefinieerd als: een samenhangende hoeveelheid werk met een gedefinieerde aanleiding en een gedefinieerd resultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden. Een vraag, aanvraag, melding of verzoek van een burger leidt tot een zaak. GFO zaken is het brandpunt van de gegevensdefinities, omdat in een zaak/ dossier alle voor de klant relevante gegevens samen komen. Zie Start van het proces (1ste stap) Mogelijkheid om burgers elektronische betaling te laten verrichten. Deze mogelijkheid wordt verzorgd door de BNG. Geeft als basis de kaart, waarbij veel verschillende gegevens zijn op te vragen Maakt het mogelijk bij een productbeschrijving of op een webformulier kaartinformatie te tonen of op basis van de kaart een locatie te selecteren Tot nog toe komen kennissystemen alleen voor in de vorm van een beslisboom of een verzameling (ongestructureerde) gegevens met een (geavanceerde) zoekfunctie. De verplichte basisregistraties aangevuld met de gemeentebrede registraties als medewerkerregistratie (personeel), bedrijfsvoeringregistratie (financiën) en de productencatalogus Maakt het mogelijk om zaakinformatie uit te wisselen met andere organisaties. Door het aansluiten van de processen van de organisaties wordt een betere dienstverlening naar de burger mogelijk. Organisaties die onderdeel uit maken van de ketenintegratie. Integraal overzicht van de gegevens betreffende een klant. Wordt meestal bereikt door gegevens uit BO systemen te verzamelen in een CRM systeem. Een front office dat het totale assortiment van de gemeente kan aanbieden. Een beschrijving van de elektronische communicatie tussen twee (of meer) softwareapplicaties. Een koppelvlak is een specificatie. Gegevens welke inzicht geven in geleverde prestaties. Dit biedt een handvat om toekomstige prestaties tijdig te beïnvloeden. Het geeft informatie over de realisatie van strategische doelstellingen en laat zien hoe de operationele processen worden uitgevoerd. Maakt het mogelijk elk (basis)gegeven te omschrijven Portaal met gepersonifieerde pagina' s gericht op basisgegevens, zaken, bekendmakingen en abonnementen. Is voor mij hetzelfde als een web intake, geen aparte component?

Pagina 71

Navigatie Nieuwsbericht Persoonlijke Internet Pagina (PIP)

Poll Portaal Post Intake

Pro-actieve Diensten

Procesbeschrijvingen Procesbewaking Procesondersteuning (WorkFlow Management of WFM) Productencatalogus

Profielen Projecten Publicatie Bekendmakingen Publicatie Persbericht

24-5-2006

Maakt het mogelijk om op verschillende niveaus navigatiemenu’s te kunnen samenstellen. Maakt het mogelijk nieuwsberichten in te voeren en te tonen. Een internet-pagina bij de overheid die burgers zelf kunnen inrichten (voorheen e-dossier). Het is de bedoeling dat op deze pagina persoonlijke gegevens en informatie komen te staan over alle lopende contacten van de burger met de overheid. Eigen gegevens die daarbij van belang zijn, worden zo langs één weg toegankelijk en kunnen makkelijker meervoudig gebruikt [z.a.] worden. Een PIP kan verder worden gebruikt om persoonlijke voorkeursopties in te stellen voor het ontvangen van bijvoorbeeld attenderingen en statusberichten van de overheid. In de zomer van 2005 is op rijksniveau besloten het streefbeeld van een PIP in een stapsgewijs, geleidelijk realisatietraject aan bestuurlijke partners voor te leggen. Zie ook organisatieoverzicht: Burger@overheid en Advies.overheid Zie ook <MijnLoket>. Opinie peiling via het internet of intranet Maakt het mogelijk om thema websites te maken, moet mogelijkheden hebben gepersonifieerde pagina' s te tonen Geeft per gescand document "ter afhandeling" de mogelijkheid een zaaktype te selecteren, kenmerken in te voeren, basisregistraties (aanvrager, betreft en eventueel nog andere), correspondentiegegevens in te geven. Tegenhanger (ander kanaal) van webintake. Hiermee worden diensten bedoeld die aangeboden worden aan de klant zonder aanvraag van de klant. Hiervoor moeten voorzieningen (signaleringsfuncties) aanwezig zijn in de geautomatiseerde systemen. Maakt het mogelijk een proces m.b.t. een zaaktype te beschrijven; kan worden aangeroepen vanuit zaaksysteem Het besturen, beveiligen en controleren van technologische Processen. Maakt het mogelijk de diverse stappen in een proces geautomatiseerd te ondersteunen. Hierdoor wordt het voor de gemeentelijke dienstverleningspraktijk mogelijk het proces met betrekking tot een zaak(dossier) te ondersteunen. Maakt het mogelijk per product een beschrijving te geven en te verwijzen naar webformulieren. VIND is een voorkomen van een productencatalogus, combineert een vraagtrechter met een beschrijving van een product. Bevat configuratievoorkeuren en instellingen voor een bepaalde gebruiker van het portaal. Maakt het mogelijk projecten te administreren en te bewaken; verwijzingen naar projectdocumenten in het dossiersysteem; genereren tussenrapportages Toont zaken en beschikkingen via het zakensysteem, ook via de kaart Maakt het mogelijk persberichten in te voeren en te tonen. Is vaak onderdeel van het CMS.

Pagina 72

Publicatie Wet en Regelgeving Maakt het mogelijk kenmerken van verordeningen te registreren en te publiceren Routering Het bepalen van een route van afzender naar bestemming Single Sign-On (SSO) Maakt het mogelijk slechts één maal te hoeven aanloggen. Gebruiker-, inlog- en sessiegegevens worden in dit geval op één centrale plek beheerd. Er kan dan van alle onderliggende (web) applicaties gebruik worden gemaakt zonder dat opnieuw hoeft te worden aangelogd. Wordt vaak afgekort als SSO. Smoelenboek Geeft organisatieonderdelen de mogelijkheid teksten in te voeren m.b.t. organisatieonderdelen, functies en medewerkers; toont deze teksten in combinatie met gegevens uit de basisregistratie medewerkers, zoals foto' s van de medewerkers Statusinformatie Synchrone communicatie Telefonische Intake Telefoongids Usermanagement Verordeningen Versieverschil Vraagtrechter Web Intake Webformulier Website/Intranet Winkelwagentje Workflow Management Zaaktype

Zaken Zakenmagazijn Zakensysteem

24-5-2006

Informatie aan de indiener van een aanvraag over de voortgang van afhandeling van de aanvraag Direct contact tussen meerdere personen of partijen. Bijvoorbeeld Chat Maakt het medewerkers van een callcenter mogelijk intakes in het zakensysteem op te slaan. Zie ook andere intakes (post, email, mobiel, balie etc.). Toont (telefoon)gegevens uit de basisregistratie medewerkers Zie Betreft specifiek documenttype in het dossiersysteem. Mogelijkheid generieke verordeningen informatie op te slaan (zoals organisatieonderdelen). Geeft op basis van twee documenten de verschillen Maakt het mogelijk producten te selecteren op basis van levensgebeurtenissen of thema' s Selecteert op basis van XML bestanden het juiste zaaktype, kenmerken, aanvrager, betreft en correspondentiegegevens (zie ook andere intakes). Een (HTML) formulier op het inter- of intranet. Deze webformulieren kunnen worden gegenereerd, gepubliceerd en gevolgd. Webserver-functionaliteit, SSL Maakt het mogelijk te bestellen producten te groeperen totdat de bestelling is geplaatst Beheersen van de werkstromen binnen een organisatie. Bepaalt het proces van afhandeling van de klantaanvraag. Voor ieder zaaktype zijn bedrijfsregels vastgelegd in de vorm van een beslisboom. Hiermee wordt voorgeschreven op welke wijze de aanvraag binnen het gemeentelijke proces moet worden afgehandeld. Tevens kan bij een zaaktype worden vastgelegd hoe de kwaliteit en doorlooptijd bewaakt moeten worden. Registreert van alle zaken een set gegevens conform het GFO zaken Zie In het zakensysteem worden op centraal niveau alle relevante gegevens over een zaak opgeslagen en beschikbaar gesteld. Het gaat hierbij onder meer om informatie over de status van

Pagina 73

Zoeken

24-5-2006

procedures, degene die een verzoek heeft ingediend, het organisatieonderdeel dat het verzoek behandelt en het moment van binnenkomst van de aanvraag Maakt het mogelijk de verschillende zoekindexen op verschillende wijzen te doorzoeken

Pagina 74

Bijlage B. Lijst Services Midoffice Service Internet Telefoon Balie Chat Post E-mail SMS Uniformeren vraag

Stap uit procesmodel 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8

Identificeren Aanvullen klantbeeld Bepaal prioriteit (Wachtrij, queuemanagement)

2.1 2.2 2.3

Vastleggen klantprofiel Raadplegen productcatalogus Zoeken via vraagtrechter Zoeken via zoekdienst Publiceren Opvragen status zaak Completeren aanvraag

3.1 3.2 3.3 3.4 3.5 3.6 3.7

Inhoudelijk controleren intake Toekennen voorlopig zaaktype Creëren zaak Betalen

4.1 4.2 4.3 -

Sturen en bewaken zaak Bijwerken zaak Melden interne status Melden klantstatus Pro-actieve diensten verlenen Opschorten zaak Archiveren zaak

5.1 5.2 5.3 5.4 5.5 5.6 5.7

Accepteren zaak Toekennen definitief zaaktype Beoordelen ontvankelijkheid Behandelen zaak

6.1 6.2 6.3 6.4

24-5-2006

Pagina 75

Terugmelding verzorgen Publiceren besluit

24-5-2006

6.5 6.6

Pagina 76

Bijlage C. Functionaliteiten versus Diensten In onderstaande lijst staat een eerste opzet van de mapping van bestaande software componenten naar de processtappen of diensten zoals deze in het procesmodel Midoffice zijn onderkend. Een korte toelichting bij de tabel: Op het hoogste niveau definiëren we component/themafunctionaliteit (C). Per component/thema definiëren we (sub)functionaliteit (F). Als deze functionaliteit afhankelijk is van een relatie naar een andere component (R) geven we dit aan. Als er m.b.t. de component een standaard geldt, waar aan moet worden voldaan, benoemen we deze standaard (S). Als er een landelijke component is, die elke gemeente dient te gebruiken, benoemen we deze als instrument (I).

C component/thema omschrijving functionaiteit, instrument, standaard C zaken gebaseerd op GFO-Zaken registreren zaak via postkanaal registreren zaak via webformulier kanaal registreren zaak via telefonie kanaal registreren zaak via balie kanaal registreren zaak via webservice administreren zaak (zetten status, registreren kenmerken) opvragen status zaak opschorten zaak zaak voorzien van geometrische gegevens leveren zaakinformatie mijnloket administreren besluiten / beschikkingen administreren beperkingen leveren gegevens zaken / beschikkingen advies.overheid.nl leveren gegevens beperkingen i.h.k.v. wkpb versturen ontvangstbevestigingen

24-5-2006

relatie naar component /thema

proces nr

proces beschrijving

S F

4.3

Creëren zaak

F

4.3

Creëren zaak

F

4.3

Creëren zaak

F

4.3

Creëren zaak

F

4.3

Creëren zaak

F

4.2 4.3

F F F

3.6 5.6 ?

Toekennen Voorlopig zaaktype Creëren zaak Opvragen Status zaak Opschorten zaak

F

3.6

Opvragen Status zaak

F

6.6

Publiceren Besluit

F F

6.6 ?

Publiceren Besluit

F

?

F

5.4

Melden Klantstatus

Pagina 77

versturen signaleringen via email versturen signaleringen via sms beheren kenmerken i.h.k.v. dsp bewaren / vernietigen documenten o.b.v. dsp kenmerken aanmaken zaakdossier

F

5.5

F

5.5

F

5.2

Pro-actieve Diensten verlenen Pro-actieve Diensten verlenen Bijwerken zaak

F

5.7

Archiveren zaak

1.8

Uniformeren klantvraag

koppelen zaak aan natuurlijk persoon koppelen zaak aan nietnatuurlijk persoon koppelen zaak aan adres

R

2.2

Aanvullen klantbeeld

2.2

Aanvullen klantbeeld

2.2

Aanvullen klantbeeld

3.6 6

Opvragen Status zaak Behandelen zaak

1.8 ?

Uniformeren klantvraag

3.6 6.6

Beheerfunctionaliteit Opvragen Status zaak Beheerfunctionaliteit Beheerfunctionaliteit Publiceren besluit

1.8 1.8

Uniformeren klantvraag Uniformeren klantvraag

1.8

Uniformeren klantvraag

-

Beheerfunctionaliteit

-

Beheerfunctionaliteit

6.6

Publiceren Besluit

R

R R

dossiers en doc Kern registraties Kern registraties Kern registraties kaart funct betaal funct

tonen kaart m.b.t. zaak R vewerken betaling zaak R functionaliteit C dossiers en documenten aanmaken dossier F opnemen document in F verschillende dossiers beheren versie documenten F tonen dossier F beheren verordeningen F beheren bestuurlijke stukken F leveren gegevens F verordeningen advies.overheid.nl email opnemen in dossier F xml-bestanden opnemen in F dossier converteren office-document F naar pdf genereren verschillen tussen F versies beheren persberichten met F thema' s op basis van profiel persoonlijke internet pagina beheren nieuwsberichten met F thema' s op basis van profiel persoonlijke internet pagina creëren document in huisstijl R document op basis van sjabloon creatie C kernregistraties (gemeentelijke basisgegevens) gebaseerd op EGEM S basisgegevens model beheren meta-informatie per F entiteit

24-5-2006

Kernregistraties (gegevensverzameling)

Pagina 78

beheren meta-informatie per attribuut opvragen historie per entiteit

F

opvragen historie per attribuut

F

opnemen geometrie bij entiteiten selecteren natuurlijk persoon selecteren niet-nauurlijk persoon selecteren adres tonen gegevens natuurlijk persoon tonen gegevens niet-natuurlijk persoon tonen gegevens adres leveren gegevens mijnloket C webformulieren ontwerpen webformulier beheren versie webformulier opnemen beslisboom in webformulier valideren gegevens op basis van basisgegevens

F

hergebruiken webformulieronderdelen opnemen uitleg per webformulier-veld opnemen documenten als bijlagen gebruiken door fomedewerker namens klant authenticeren via inlogcode en wachtwoord opnemen gegevens natuurlijk persoon in webformulier opnemen gegevens nietnatuurlijk persoon in webformulier opnemen gegevens adres in webformulier aanmaken zaak op basis van gegevens webformulier opnemen kaart in webformulier t.b.v. geometrie m.b.t. zaak betalen zaak C mijnloket persoonlijke internet pagina

24-5-2006

F F

2.2 2.2

Kernregistraties (gegevensverzameling) Kernregistraties (gegevensverzameling) Kernregistraties (gegevensverzameling) Kernregistraties (gegevensverzameling) Aanvullen klantbeeld Aanvullen klantbeeld

F F

2.2 2.2

Aanvullen klantbeeld Aanvullen klantbeeld

F

2.2

Aanvullen klantbeeld

F F

2.2 2.2

Aanvullen klantbeeld Aanvullen klantbeeld

F F F

-

Beheerfunctionaliteit Beheerfunctionaliteit Beheerfunctionaliteit

F

4.1 6

F

-

Inhoudelijk controleren intake Behandelen zaak Beheerfunctionaliteit

F

-

Beheerfunctionaliteit

F

1

Kanalen

authenticati e Kern registraties Kern registraties

2.1

Identificeren

2.2

Aanvullen klantbeeld

2.2

Aanvullen klantbeeld

2.2

Aanvullen klantbeeld

R

Kern registraties zaken

2.2

Aanvullen klantbeeld

R

kaart funct

2.2

Aanvullen klantbeeld

R

betaal funct

6

Behandelen zaak

F

F R R R R

I

Pagina 79

tonen mijn zaken beheren mijn profiel

F F

3.6 3.1

tonen mijn gegevens terugmelden m.b.t. gegevens (genereren terugemelding zaak) tonen producten op basis van thema' s/ levensgebeurtenissen C productencatalogus / e-loket selecteren op basis van thema' s/ levensgebeurtenissen op basis van mijnloket leveren gegevens mijnloket

F F

3.6

F

3.2

Raadplegen Product catalogus

F

3

tonen veelgestelde vragen per product opnemen informatie producten (t.b.v. zoektool onder redactie) tonen kaart m.b.t. product aanroepen afspraak functionaliteit C kaart functionaliteit leveren kaart m.b.t. product

F

3.2

F

3.2

Assisteren en Informeren Klant Raadplegen Product catalogus Raadplegen Product catalogus

leveren kaart m.b.t. webformulier leveren kaart m.b.t. zaak C document creatie baseren op sjablonen tonen in de huisstijl C authenticatie digid authenticeren via inlogcode en wachtwoord terugmelden verzoek authenticeren uitbreiden met sms C raadsinformatie beheren documenten per vergaderpunt beheren thema per vergaderpunt op basis van profiel persoonlijke internet pagina beheren moties per vergaderpunt

24-5-2006

Opvragen status zaak Vastleggen in klantprofiel Opvragen status zaak

F

R R

kaart funct afspraken

F

3

Assisteren en Informeren klant Assisteren en Informeren klant Assisteren en Informeren klant

F

3

F

3

F F

-

Beheerfunctionaliteit Beheerfunctionaliteit

I F

2.1

Identificeren

F

3.7

F

2.1

Complementeren aanvraag Identificeren

F

-

Beheerfunctionaliteit

F

-

Beheerfunctionaliteit

F

-

Beheerfunctionaliteit

Pagina 80

C

C

C

C

C

beheren sprekers per vergaderpunt beheren fracties en fractieleden beheren commissies en commissieleden beheren audiofragmenten per vergaderpunt oproepen bestuurlijke stukken via dossier functionaliteit afspraken authenticeren via inlogcode en wachtwoord opnemen gegevens natuurlijk persoon in afspraak wegschrijven afspraak als zaak nieuwberichten beheer nieuwsberichten met thema' s op basis van profiel persoonlijke internet pagina persberichten beheren persberichten met thema' s op basis van profiel persoonlijke internet pagina+D80+D82 betaal functionaliteit ogone ? betalen via i-deal betalen via creditcard betalen via automatische incasso interactieve functionaliteit aanbieden forum

F

-

Beheerfunctionaliteit

F

-

Beheerfunctionaliteit

F

-

Beheerfunctionaliteit

F

-

Beheerfunctionaliteit

R

dossiers en doc

3.5

Publiceren

R

authenticati e Kern registraties zaken

2.1

Identificeren

4

Registreren zaak

R

dossiers en doc

-

Beheerfunctionaliteit

R

dossiers en doc

-

Beheerfunctionaliteit

I F F F

6 6 6

Behandelen zaak Behandelen zaak Behandelen zaak

F

3

aanbieden poll

F

3

aanbieden chat

F

3

Assisteren en Informeren Klant Assisteren en Informeren Klant Assisteren en Informeren Klant

R R

Zoeken producten

3.2

Zoeken nieuwsberichten Zoeken via vraagtrechter

3.4 3.3

24-5-2006

Raadplegen Product Catalogus Zoeken via zoekdienst Zoeken va vraagtrechter

Pagina 81