Delft

Aandacht voor digitale dienstverlening betekent aandacht voor iedere schakel in de hele informatieketen van KIS: balie, beleid, bedrijf, bestand en beheer. Er lijkt niets tegen het snel scoren met een nieuw digitaal product aan de virtuele balie. Maar als dat product niet past in een keten van standaards blijft het slechts bij een cosmetische vernieuwing, omdat de organisatie de verwachtingen niet kan waarmaken. Investeringen in dienstverlening beperken zich dus niet tot de ‘buitenkant’. Pas als alle schakels in de keten erop zijn berekend, zal de verbetering van digitale dienstverlening aan de (virtuele) balie echt van de grond komen.

Dit hoofdstuk geeft een beschrijving van de schakels in de informatieketen en legt een relatie met bestaande nota’s.

3.1De schakel Balie-informatie

De gemeente ontwikkelt een geïntegreerde balie voor transactie, interactie en communicatie met burgers. De kwaliteit van dienstverlening staat hoog in het vaandel van de gemeente, want de publieksfuncties (aan de balie en ‘op straat’) vormen het gemeentelijke visitekaartje. Delft brengt daarom samenhang in de loketten waar de burger terecht kan voor alle producten en diensten van de gemeente. Bij een call center kan de burger op afstand per telefoon alle vragen en opmerkingen kwijt. Het virtuele loket van de overheid op het internet maakt communicatie mogelijk zonder de beperkingen van plaats en tijd. Op internet is de gemeente vierentwintig uur per dag, zeven dagen per week toegankelijk.

Daarnaast wordt het mogelijk om op elektronische wijze formulieren op te vragen voor een grote hoeveelheid van diensten, zoals kapvergunningen en uittreksels uit het bevolkingsregister. De burger kan de formulieren vervolgens na invulling direct terugsturen. Hierna gaat het gemeentelijke apparaat ermee aan het werk. Het systeem attendeert burgers op bij elkaar horende aanvragen of producten, de zogenaamde vraagpatronen. De technologie die de balie ondersteunt in haar dienstverlenende activiteiten aan de burgers is ook het internet.

De ‘Nota Internetbeleid’ beschrijft het Delftse ambitieniveau met betrekking tot de balie. Delft streeft naar een laagdrempelige website, met actuele en accurate informatie. Ook zal de website een rol spelen als platform voor vormen van informele en formele interactieve beleidsvorming. Naast medium voor het verstrekken van informatie gaat de website in de komende jaren steeds meer functioneren als front office van de digitale dienstverlening. De website handelt uiteindelijk de hele dienst via het internet af. Dit betekent ook dat Delft dan over een omgeving moet beschikken die optimaal geautomatiseerd is. De interactie via het internet vindt in de meeste gevallen plaats via e-mail. Hiervoor moet een e-mail protocol worden ontwikkeld.

De balie is de belangrijkste plek binnen de gemeente waar dienstverlening plaatsvindt. Het Dienstverleningsconcept beschrijft hoe Delft die dienstverlening wil verbeteren. Gemeentelijke dienstverlening wordt voor een belangrijk deel bepaald door de eisen van rechtmatigheid en rechtsgelijkheid. Deze geven deze dienstverlening een eigen spanning. Rechtsgelijkheid vraagt om eenheid van beleid en uitvoering, terwijl dienstverlening daarentegen om differentiatie vraagt. Dit brengt met zich mee dat de dienstverlening constant in de gaten gehouden en waar nodig verbeterd moet worden. Verantwoording afleggen aan de burger neemt hierbij een centrale plaats in (zie burgerjaarverslag bij 5.2).

3.2De schakel Beleidsinformatie

Gemeentelijk beleid raakt belangen van burgers. De burger moet het proces van beleidsvorming kunnen volgen en er invloed op uitoefenen als hij dat wil. Ook moet hij toegang kunnen hebben tot informatie over de uitvoering van beleid en over de monitoring van resultaten.

De volgende schakel in de informatieketen is beleidsinformatie. Beleidsinformatie ondersteunt de ontwikkeling, uitvoering en evaluatie van het beleid. Dit is vooral het terrein van het cluster Wijk- en Stadszaken. De nota ‘Visie interactieve beleidsvorming’ gaat nader in op de werkwijze, de instrumenten en de ICT-randvoorwaarden. De hierbij behorende technologie is die van het extranet: een afgeschermd deel van het internet waar betrokken personen met elkaar kunnen communiceren en discussiëren voor de ontwikkeling van beleid en de besluitvorming erover. Hierbij worden discussiegroepen onderscheiden naar thema en naar doelgroep. Een thematische discussiegroep wordt gevormd op basis van een beleidsthema, terwijl de tweede categorie uitgaat van een kenmerk van de deelnemers: bijvoorbeeld inwoners van een wijk. In dit laatste geval maken we gebruik van wijksites. De Nota Internetbeleid gaat nader in op dit onderscheid in relatie tot internetportalen, zoals www.delft.nl/jongeren en www.wippolder.nl. 

Bij beleidsinformatie wordt ook gedacht aan informatie over wet- en regelgeving en andere randvoorwaarden die aan (gemeentelijke) producten en diensten ten grondslag liggen. Beschikbaarheid van deze informatie maakt een verdere verdieping in een specifiek onderwerp erg eenvoudig. Wijzigingen hierin worden rechtstreeks door de betrokken afdeling verwerkt. De informatie is dus altijd up-to-date. Burgers kunnen zich aanmelden om door de gemeente automatisch op de hoogte te worden gehouden van ontwikkelingen op die gebieden waarvoor interesse bestaat, inclusief gemeentelijke documenten en raadsstukken.

3.3De schakel Bedrijfsinformatie

Deze schakel in de informatieketen gaat over het interne proces, de bedrijfsvoering, van de gemeente. De gemeente combineert de juiste middelen om producten en diensten te leveren. Intern wordt met besturing de basis gelegd voor een goede dienstverlening aan de burger, voor snelle en accurate service, voor een efficiënte levering van producten, maar ook voor pro- actieve dienstverlening.

Voor een organisatie die een goede  waardering door klanten, medewerkers en de maatschappij als één van de sturende principes hanteert, is een scherp en actueel beeld van de eigen performance essentieel. Meten is weten, en gelukkig weten we ook al veel. Op verschillende plekken in de organisatie worden kwaliteit en kwantiteit al gemonitord. Een voorbeeld hiervan is het BAVAK-systeem bij de publieksbalie: een computersysteem dat informatie over wachttijden, bezettingsgraad van de balies, producten verschaft –noodzakelijk om klanten goed en efficiënt van dienst te kunnen zijn. Een ander voorbeeld is het tevredenheidsonderzoek onder medewerkers of de benchmarking bij Werk, Inkomen en Zorg, waarvan de uitkomsten een drijfveer vormen voor de invoering van het INK-managementmodel. Dit soort instrumenten stelt ons in staat te kunnen (bij)sturen en vooral te kunnen anticiperen.

Voor het definiëren van de resultaten waarop zal worden gemeten, wordt uitgegaan van de vijf ‘burgerwaarden’: toegankelijkheid, doeltreffendheid, betrouwbaarheid, controleerbaarheid en doelmatigheid (paragraaf 4 gaat nader in op deze burgerwaarden). Deze waarden worden concreet gemaakt in meetbare normen, waaraan de processen in de digitale dienstverlening moeten voldoen. Dit wordt vastgelegd in duidelijke afspraken die op (mate van) realisatie kunnen worden gecontroleerd. Dit sluit aan bij de aanbevelingen uit het rapport van de Rekenkamercommissie.

3.4De schakel Bestandsinformatie

Basisgegevens zijn de bron voor bewerkingen die worden gebruikt bij de besturing, het beleid en het contactencentrum van de gemeente. Basisgegevens worden eenmalig op een vaste plaats verzameld in basisregistraties. De kwaliteit van de basisgegevens is gegarandeerd door een basisadministratie waarin is geregeld hoe medewerkers de gegevens vastleggen en beheren.

Bestandsinformatie is die informatie die door en in een gemeente is verzameld en die op diverse werkplekken inzetbaar is. Daarbij moet sprake zijn van eenmalige en eenduidige vastlegging op een afgesproken plaats met afspraken over wie verantwoordelijk is voor onder meer opbouw en mutatie en wie mag raadplegen. De gemeente Delft sluit met betrekking tot de bestandsinformatie aan bij de landelijke ontwikkelingen (stroomlijning basisgegevens). Landelijk zijn zes authentieke basisregistraties erkend. Twee van deze registraties zijn al bestaand, namelijk het GBA en de kadastrale registratie. De overige vier registraties zijn in ontwikkeling: het basisbedrijvenregister, het gebouwenregister, het geografisch kernbestand en de nationale adressenregistratie. Naast deze zes externe registraties kent de gemeente Delft ook nog drie interne registraties: financiën, personeel en documentaire informatie. De bestandsinformatie die door deze basisregistraties wordt ontsloten moet toegankelijk zijn op de werkplekken van daarvoor geautoriseerde medewerkers.

De gemeente Delft heeft haar registraties toegankelijk gemaakt en met elkaar verbonden. Daardoor worden gegevens zo veel mogelijk éénmalig vastgelegd en meervoudig gebruikt. Ook voor de burger is dit handig. Eenmalig vastgelegde gegevens over een burger kunnen dan op een later moment bij een volgend contact worden hergebruikt, naar gelang de wens van de klant. Ook wordt een uittreksel van de aanwezige informatie voor de burger toegankelijk gemaakt in een extranet-omgeving.

In contacten met de gemeente moet de burger niet worden geconfronteerd met het feit dat er verschillende basissystemen binnen de organisatie aanwezig zijn. De uitvoering van processen achter de front office zal plaatsvinden in de gemeentelijke back office, door externe partners, dan wel door de back office in samenwerking met externe partners. Digitalisering maakt dit mogelijk. Nodig zijn standaardpakketten, vermindering van het aantal applicaties en het werken met basisregistraties. Een naadloze aansluiting van de front office op de back office vergt overigens bijzondere aandacht. Delft investeert in deze koppeling, waarvoor de term mid office gangbaar is.

3.5De schakel Beheer en Beveiliging informatie

Delft is met haar interne infrastructuur op de goede weg. Dat geldt echter minder voor haar digitale dienstverlening. Binnen en buiten de gemeentelijke overheid komt een veelheid aan initiatieven tot ontwikkeling die een belangrijke bijdrage kunnen leveren aan de realisering van de ambities. Er is veel te leren. De gemeente Delft wil leren van al deze ontwikkelingen en deze inbedden in haar aanpak. Daarnaast realiseert de gemeente ook zelf projecten die een positieve bijdrage leveren aan de optimalisering van dienstverlening en interactieve beleidsontwikkeling en zo aan een beter functionerende Delftse samenleving.

Ede

Balie

Het internetloket is een nieuw loket, naast de overige loketten. Er is geen sprake van integrale dienstverlening (multi channel) met specifieke doelstellingen

De vragen worden afzonderlijk beantwoord. Van integrale dienstverlening is alleen binnen specifieke sectoren sprake.

Het beheer van het digitale loket moet nog georganiseerd worden. Bij ICT komt technische capaciteit. Voor het inhoudelijk beheer vallen we terug op de afdeling communicatie (webbeheer).

Beleid

Vanuit CZ wordt een concernbreed innovatieprogramma gerealiseerd. De nadruk ligt op dienstverlening en communicatie. Interactieve beleidsontwikkeling, horizontale uitwisseling of samenwerking met externe partijen zijn niet aan de orde.

Bestuurlijk gezien bestaan er weinig beleidskaders. Het gaat om de bestaande zaken ook in digitale vorm om te zetten waardoor de voordelen van digitale communicatie beschikbaar komen (24/7, vanuit de huiskamer enzovoorts).

Bedrijf

Het bestuur hecht veel waarde aan de verbetering van de bedrijfsvoering maar wil daarvoor geen doelen formuleren.

Bestuur en management hebben geen andere doelstellingen dan digitale dienstverlening, zoals verbetering van rekenschap, procesbeheersing, opruimen informatiehuis of iets anders.

Bestand

Het platform gegevensbeheer is kwakkelend en kent weinig prioriteit binnen het management. Opbouwen van concernbrede klanten- en gegevensbestanden is ondergesneeuwd door de technische complexiteit.

Er is geen kosten/baten verhaal over gegevensbeheer.

Ambtelijk worden er tussen afdelingen afspraken gemaakt over het gedeeld gebruik maken van gegevensbestanden, maar van concernbrede beleid is nauwelijks sprake.

Op ambtelijk niveau ontstaat er steeds meer begrip voor architectuurdenken en de nut en noodzaak hiervan. Echter, hoe een gemeentelijke architectuur er uit kan zien binnen de gemeente Ede en hoe deze geïmplementeerd zou kunnen worden is nog volstrekt onduidelijk.

Emmen

VRAAG A1: Hebt u de samenhang in uw informatiehuishouding geexpliciteerd?

De samenhang in de Emmense informatiehuishouding is niet geëxpliciteerd. Het totaalplaatje  (“the big picture”) ontbreekt. Op bepaalde terreinen (dienstnivo) zoals Geo-info en info m.b.t. de sociale kolom, is wel een aanzet gegeven om de samenhang  in de informatiehuishouding inzichtelijk te maken. Dit is voornamelijk op het niveau van applicaties. De gegevensrelaties tussen de verschillende systemen is niet geëxpliciteerd. Ook zijn de informatiestromen tussen de verschillende organisatienivo´s onvoldoende in kaart gebracht (managementlagen en operationeel nivo).

VRAAG A2: Zoja, welke ordeningsmethodiek hanteert u daarbij?

Er is geen expliciete ordeningsmethodiek gehanteerd in termen van balieinfo, beleidsinfo, bedrijfsinfo, beheer- /beveiligingsinfo.

VRAAG A3: Kunt u deze ordeningsmethodiek vertalen naar de hiervoor besproken keten?

Deze informatievormen kunnen wel op het primaire proces van de publieksdienst geprojecteerd worden.

Figuur 1: hoofdbedrijfsproces PublieksDienst

In het hoofdbedrijfsproces van de PublieksDienst zijn de volgende stappen te onderscheiden:

vraag

Hiermee zet de klant (burger, instelling of bedrijf) het proces in gang. De vraag kan betrekking hebben op één of meer producten. Dit is afhankelijk van het patroon waaruit de behoefte van de klant voortkomt. Bijvoorbeeld: er kan naast een inritvergunning ook een kapvergunning nodig zijn. De vraag kan op verschillende manieren worden gesteld: telefonisch, elektronisch (e-mail of website), per post of fysiek aan de balie.

1. routeren

De vraag wordt voor afhandeling in een bepaalde richting gedirigeerd. Dat kan op meer manieren. Bijvoorbeeld fysiek door de klant te verwijzen naar een loket aan de balie of op de website waar de klant menugestuurd zelf de route kiest. In veel gevallen maakt ook de registratie van de aanvraag onderdeel uit van de routering. Een bepaalde categorie aanvragen wordt direct doorverwezen voor afhandeling elders (figuur 3, route 3c). De PublieksDienst verricht dan geen intake en is niet verantwoordelijk voor de voortgang van het proces. Voor andere aanvragen geldt, dat ze (geheel of gedeeltelijk) door de PublieksDienst worden afgehandeld.

2. intake

In deze stap is de klant nog direct betrokken bij de verwerking van de aanvraag. De klant moet bijvoorbeeld aantonen, dat hij degene is voor wie hij zich uitgeeft (legitimeren) en de gegevens van de aanvraag worden ingevuld en gecontroleerd op juistheid. Door gebruik te maken van een digitale handtekening en ICT kan de intake ook elektronisch worden uitgevoerd. De klant voert daarmee onafhankelijk van plaats en tijdstip (een deel van) het proces zelfstandig uit, zo mogelijk inclusief het maken en leveren; zie figuur 2. Het proces verloopt zo voor de klant sneller en is efficiënter voor de organisatie.

figuur 2: deels elektronische afhandeling van de vraag

3. maken

In deze stap wordt het product ook daadwerkelijk gemaakt. Het maken kan variëren van een eenvoudige handeling tot meer complexe werkzaamheden, bijvoorbeeld toetsing aan wet- en regelgeving

4. leveren

Het product wordt door de PublieksDienst geleverd aan de klant. De levering kan zowel elektronisch als aan de balie plaatsvinden. De producten kunnen ook buiten de PublieksDienst gemaakt zijn. Het leveren van een product betekent niet dat de klant altijd krijgt waar hij om vraagt. De levering kan bijvoorbeeld bestaan uit een beschikking, die de vraag van de klant niet honoreert.

5. nazorg

Voor sommige producten die de PublieksDienst heeft geleverd is nazorg (service) nodig. Dit kan verschillende vormen aannemen, bijvoorbeeld het bewaken van de geldigheidsduur van een reisdocument.

In de eerste stap “routering” is sprake van balieinfo, de burger wil iets weten.  Bij de intake (stap 2) wil de burger weten of hij aan de voorwaarden voldoet (beleidsinfo). Het bestellen start bij stap 3 (maken). Dit kan door het invullen van een digitaal formulier, dat vervolgens wordt gebruikt voor:

•   of handmatig verwerking door de bureaucratie,

•   of voor volledige geautomatiseerde afhandeling van de aanvraag.

Hoe digitaler het proces verloopt, hoe hoger de eisen die gesteld worden aan de gegevens, omdat er geen sprake meer is van tussenkomst van de bureaucratie (voor bv. gegevenscontroles). De regie over de gegevens(verwerking) moet daarmee naar de burger verschuiven.  Die moet na kunnen gaan welke gegevens van hem gebruikt worden voor de verwerking van de aanvraag en hij moet kunnen volstaan met het éénmalig verstrekken van (mutatie)gegevens. De burger moet de bewaker van zijn/haar eigen gegevens kunnen zijn. Die rol kan de burger alleen maar goed vervullen als:

•   De binnengemeentelijke informatiehuishouding goed gestroomlijnd is met basisregistraties als fundament.

Den Haag

Ja

GCC (telefonie)

Stadsdeelkantoor (fysieke balie)

Website

4.   De totstandkoming van een Haagse architectuur

Het is heel lang gemeengoed geweest dat overheids- (maar ook commerciële) organisaties hun diensten aanbod- gericht verleenden. De interne organisatie van de gemeente was hierbij leidend; het aanbod volgt de kanalen van die organisatie. En zo kon het gebeuren dat in de stad tientallen loketten ontstonden van waaruit verkokerde en gefragmenteerde diensten werden verleend.

Verkokering volgt echter niet de logica van de burger. Die verlangt van de overheid samenhang in de dienstverlening. Deze gaat er van uit dat diensten of producten, zeker die welke logisch bij elkaar horen, vanuit één loket en geïntegreerd worden aangeboden en geleverd. Denk bijvoorbeeld aan het verlenen van een vergunning voor een invalidenparkeerplaats, waarbij meerdere gemeentelijke diensten zijn betrokken. Den Haag heeft de ambitie uitgesproken om haar dienstverlening klantgericht te organiseren. En zeker de elektronische variant ervan (via het web) moet op de leest van de één-loket benadering zijn geschoeid. Om deze ambitie te kunnen waarmaken is het onontkoombaar dat het dienstverleningsproces opnieuw georganiseerd wordt. Je moet een werkwijze  - in Den Haag noemen we dat een architectuur - bedenken die de gewenste samenhang waarmaakt. Die Haagse architectuur is in de loop der jaren met vallen en opstaan gegroeid. Zij is gebaseerd op het beginsel van de kleinste eenheden. Dit wil zeggen dat de architectuur geen star geheel is, doch is gebaseerd op bouwstenen, Lego-blokjes. Heel belangrijk is dat die bouwstenen op elkaar passen; het afspreken van standaards is daarvoor een voorwaarde. Deze bouwstenen ondersteunen de gedachte dat er sprake is van een dienstverleningsketen. Het Haagse programma waarbinnen de Haagse aanpak wordt gerealiseerd heet Het Glazen Stadhuis.

4.1 De basis: de vraag stuurt het aanbod

Om de door de burger gewenste dienstverlening helder te krijgen is in de Haagse aanpak eerst vastgesteld in welke rollen de burger in contact treedt met de gemeente en wat hij in elk van die rollen van de gemeente verwacht. Het gemeentelijke aanbod moet daar immers op worden afgestemd. Het belang van deze aanpak is dat je hiermee de burger in staat stelt de gemeente in haar totaliteit, als eenheid,  te beschouwen. Aspecten als interne verkokering worden daarmee geëlimineerd. Den Haag heeft in dit proces gebruik gemaakt van het vraag-aanbod-model van Henk Bos (Informatiehuis BV). Dit model onderscheidt 5 burgerrollen, waarop de gemeente antwoordt met een overeenkomstig aanbod.

4.2 Rollen in vraag en aanbod

4.2.1   Bezoeker / Balie-informatie

De eerste rol is die van een bezoeker die iets wil en zich bij de gemeente oriënteert om te bekijken of deze hem behulpzaam kan zijn. Hij kan deze informatie aan een fysiek loket proberen te krijgen, maar hij kan er ook voor kiezen deze informatie aan een virtuele balie (de Haagse website) te halen. Het aanbod van de gemeente richt zich dus op informatieontsluiting: bijvoorbeeld in de vorm van een productencatalogus of op nieuws-informatie. Het sleutelwoord hierbij is toegankelijkheid.

4.2.2   Beïnvloeder / Beleidsinformatie

Wanneer de bezoeker heeft vastgesteld dat de gemeente inderdaad het door hem gewenste product kan leveren, zal hij willen weten onder welke voorwaarden dat kan. Welke regels zijn van toepassing en komt hij überhaupt wel in aanmerking? Dit is het moment waarop de gemeente met aanvullende informatie op de proppen moet komen: de wet- en regelgeving en beleidsregels. Er moet anders gezegd in deze fase een confrontatie plaatsvinden tussen de persoonlijke omstandigheden van de burger en de toepasselijke regelgeving. De uitkomst van dat proces geeft antwoord op de vraag van de burger omtrent het wel/niet in aanmerking komen. Beslissing-ondersteunende systemen (beslisbomen) helpen de burger hierbij; dit is een kwaliteitsaspect van de dienstverlening.

Het kan zijn dat de burger het niet eens is met het gemeentelijke beleid. Of misschien wil de gemeente zelf wel dat beleid aanpassen. In die gevallen kan de burger ervoor kiezen te participeren in een beleidsvormingstraject. De gemeente facilieert dit soms in de vorm van discussiepanels, interactieve beleidsvormingsprocessen, enz.

Wanneer beleidsbeïnvloeding aan de orde is gaat beleidsinformatie vooraf aan balie-informatie. Deze tweedeling zou het model echter onnodig complex maken. Bedenk immers dat de waarde van het model vooral zit in het logisch ordenen van soorten informatie. Het is een middel om de aanpak beheersbaar te houden.

4.2.3   Betaler / Bedrijfsvoeringsinformatie

De volgende gedaante die de burger kan innemen is die van klant, hier Betaler genoemd. Vastgesteld is dan inmiddels dat de gemeente het gewenste product inderdaad aan hem kan leveren. De klant besluit nu tot het aangaan van een transactie. De gemeente facilieert dit in zijn aanbod. In zijn algemeenheid start het proces met het invullen van een transactieformulier. Daar moet de klant zijn persoonlijke gegevens op invullen. Soms heeft de gemeente die al in zijn bezit en is het handig als die alvast in het formulier zijn voorbedrukt. Sterker nog: de klant mag van de gemeente verlangen dat niet opnieuw om die gegevens wordt gevraagd. Belangrijk is ook dat de identiteit van de klant wordt vastgesteld. Verder is het niet uitgesloten dat de klant voor het gewenste product moet betalen. Ook dat moet mogelijk zijn via de web-transactie. En wanneer de levering noodzakelijkerwijs langere tijd in beslag neemt zal de klant de voortgang willen volgen; dit alles kan het beeld van betrouwbaarheid voor de klant verhogen.

4.2.4   Bewaker / Bestandsinformatie

Zoals gezegd wordt bij het verwerken van transacties gebruik gemaakt van in de gemeentelijke administraties aanwezige gegevens. De klant heeft er belang bij dat die gegevens correct zijn en dat hij die niet onnodig behoeft aan te leveren. Eenmalige verstrekking zou voldoende moeten zijn. De gemeente moet de klant ook de mogelijkheid bieden zijn eigen gegevens te controleren. Verder moet thematische ontsluiting van gegevens mogelijk zijn.  Om dit allemaal te kunnen waarmaken moet de gemeente haar gegevens ordenen volgens het principe van de enkelvoudige opslag, meervoudig gebruik. Een stelsel van kernregistraties en een daarbij behorende centrale beheersorganisatie vormen hiervoor de oplossing.

4.2.5   Browser / Beheer- en beveiligings-informatie

Tenslotte verlangt de klant dat de gemeente zorgvuldig en op een veilige manier met zijn gegevens omgaat. Ook moet hij altijd via het net met de gemeente kunnen communiceren. Het antwoord van de gemeente moet zijn dat zij op een procesoverstijgend niveau het beheer van haar ICT-middelen heeft georganiseerd. Kwaliteit wordt bevorderd door het maken van afspraken via zogenaamde dienstverleningsovereenkomsten. Voor de gemeentelijke medewerkers geldt bovendien dat de eigen webplekken aan standaards moeten voldoen.

Uit het vorenstaande blijkt dus dat in het transactieproces de klant/burger een aantal keren van rol verandert. Er is dan ook geen sprake van een standaard vraagpatroon van de burger. De gemeente moet haar informatie-huishouding dusdanig inrichten dat zij adequaat kan inspelen op die wisselende rollen.

4.3 Het gemeentelijke aanbod logisch geordend: een proeve van een architectuur

Nadat was vastgesteld welke functies er allemaal in een elektronische transactieproces aan de orde konden zijn, is geprobeerd deze te ordenen in een logisch plaatje, een functionele architectuur. Zie hieronder. In de linkerkolom zijn de vraagpatronen benoemd, aan de rechterkant de aanbod-rollen van de gemeente. In het midden zijn volgtijdelijk de belangrijkste bouwstenen beschreven die nodig zijn om in het transactieproces de aanbodkant te kunnen ondersteunen. Ook de relaties tussen de componenten zijn getekend.

Om dit model in de praktijk te verwezenlijken zijn vanuit de concerndirectie Bestuursdienst/POI de gemeentelijke diensten uitgenodigd desbetreffende projecten in te dienen. Daarbij moet het mes aan twee kanten snijden: behalve dat meegewerkt wordt aan de realisering van de concern-architectuur, mag het betreffende project ook bijdragen aan de verbetering van de eigen bedrijfsvoering. In de praktijk betekent dit dat in de projecten veelal een of meerdere (op de burger gerichte) producten zijn ingebouwd. Bijvoorbeeld werd de ontwikkeling van een kernregistratie voor natuurlijke personen tegelijkertijd gekoppeld aan de vernieuwing van het GBA systeem. Het realiseren van een formulierenserver is beproefd aan de hand van het product parkeervergunningen, enz. De door de diensten gehonoreerde projecten zijn financieel ondersteund met concern-middelen voor het programma Het Glazen Stadhuis. Vanaf 2001 wordt de Haagse aanpak mede bekostigd met een rijksbijdrage van het ministerie van BZK in het kader van het programma Superpilots BZK.  

Naarmate meer projecten worden opgeleverd is het steeds belangrijker geworden te sturen op de aansluiting op elkaar van de individuele componenten. Daartoe is een apart project Koppelvlakken gestart.

4.4 Gegevens en beveiligingsniveau

Gaandeweg de rit is het ook noodzakelijk gebleken meer op detailniveau vast te leggen hoe de onderlinge gegevensstromen in zijn werk gaan en welke niveau’s van beveiliging nodig zijn. Want duidelijk is wel: hoe verder de klant wordt toegelaten tot in de gemeentelijke administraties des te belangrijker wordt het aspect beveiliging. Daarnaast is het absoluut een voorwaarde dat er een strikte scheiding werd gemaakt tussen systemen en gegevens die binnen de gemeentelijke diensten werden gebruikt voor de eigen bedrijfsvoering en tussen die welke voor het elektronische dienstverleningsproces nodig waren. Dit leidt tot het volgende model.

De verticale rode lijnen markeren de domeinen. De volgende domeinen zijn gedefinieerd:

•de omgeving van de gemeentelijke diensten (dienstgebonden Intranet). Hierbinnen functioneren de dienstspecifieke processystemen. Er is in principe geen verbinding tussen deze laag en de Internetlaag. Diensten kunnen er wel zelf toe besluiten om de poort even open te zetten voor het up- of downloaden van gegevens. Dit voor zover actualisering dit nodig maakt. Het gaat dan vooral voor het actualiseren van de kernregistraties met gegevens uit de processystemen (b.v. GBA);

•het binnen-gemeentelijke Intranet. Binnen dit domein kunnen de Haagse ambtenaren toegang krijgen tot daarbinnen ontsloten applicaties en gegevensverzamelingen;

•de publiek toegankelijke Internet-omgeving. Binnen deze omgeving hebben burgers toegang tot de presentatie- (website) en applikatieservers (Raadsinformatiesysteem, productencatalogus, formulierenserver, alsmede tot de Centrale Digitale Sleutel (het identificatie- en authenticatiestelsel);

•de verticale liftschacht rechts symboliseert de Xtranet-omgeving die open staat voor daartoe (met de CDS) bevoegde klanten. Zij krijgen via dit kanaal toegang tot de kernregistraties en tot de Klantengegevensbank (BGG). De BGG is een database waarin transactiegegevens met individuele burgers zijn vastgelegd. Een klant kan alleen zijn eigen gegevens raadplegen.

Naast domeinen zijn er (horizontale) lagen die het beveiligingsniveau weergeven. Naarmate je dieper in de organisatie binnentreedt neemt het aantal beveiligingslagen toe. Van buiten naar binnen onderscheiden we:

•de gebruikerslaag. Dit is de laag waarbinnen eindgebruikers toegang hebben tot gemeentelijke systemen;

•de presentatielaag. Dit is de laag waarbinnen de webservers ontsloten worden. Voor de burger is dat de Haagse website, voor de Haagse ambtenaren ook de dienstgebonden en concern Intranetservers;

•de applicatielaag, waarbinnen toepassingen toegankelijk worden gemaakt;

•de gegevenslaag. De laag waarbinnen de dienstgebonden, de gemeenschappelijke en de voor de klant toegankelijke gegevens zijn opgeslagen.

De rode lijnen zelf geven de beveiligingslagen (zogenaamde proxies) weer. De blauwe lijnen illustreren in hoeverre rechtstreekse gegevensuitwisseling mogelijk is.

Het blauw gemarkeerde gedeelte in de tekening presenteert de wijze van en niveau waarop het beheer plaatsvindt.

4.5 Het tijdpad waarbinnen de Haagse architectuur moet zijn gerealiseerd

Het programma Het Glazen Stadhuis is in het jaar 2000 van start gegaan. Het loopt in 2004 af, evenals de rijksbekostiging. De architectuur moet dan zo veel mogelijk gerealiseerd zijn.

Met alleen het opbouwen van een technische omgeving heb je nog geen elektronische dienstverlening. Daarvoor is meer nodig: de organisatie moet er klaar voor zijn, de wil (cultuur) aanwezig en de gemeentelijke medewerkers erop voorbereid. Eerst dan kunnen dienstverleningsproducten daadwerkelijk in deze omgeving worden aangeboden. Hiervoor lopen afzonderlijke projecten, die ook na 2004 doorlopen en optrekken met het programma Klantgerichtheid (Majesteit). Met dit programma streeft Den Haag ernaar in 2007 de meest klantgerichte stad van Nederland te zijn. Het project de Haagse Informatieschool zorgt voor het opleiden van de medewerkers.

4.6 Integratie met particuliere elektronische dienstverlening

De boven beschreven architectuur heeft betrekking op alleen de gemeentelijke dienstverlening. Er zijn in de stad echter nog veel meer partijen met wie de burger transacties aangaat: andere overheden, bedrijven, verenigingen, stichtingen en individuele burgers. Soms hangt particuliere dienstverlening nauw samen met gemeentelijke dienstverlening. Dit is bijvoorbeeld aan de orde bij huwelijken. De gemeente is dan slechts één van de partijen om een huwelijksdag tot een succes te maken. Onze gemeente wil ook aan die integrale dienstverlening een flinke push geven. Daarvoor zijn en worden op het Residentie.net portalen opgericht waarbinnen die dienstverlening gebundeld is. Portalen in oprichting of inmiddels gereed zijn het Sportportaal, Brandveiligheidsportaal, Onderwijsportaal, Ondernemersportaal, Politiek portaal en het Huwelijksportaal.

5.   De projecten: de bouwstenen in de keten

In het hoofdstuk over de totstandkoming van de Haagse architectuur is aangegeven dat deze zijn grond vindt in de rollen die de burger speelt tijdens het transactieproces. Volgtijdelijk zijn die rollen, vraagpatronen:

(vraag:)        Bezoeker - Beïnvloeder - Betaler - Bewaker - Browser.

(aanbod:)          Balie - Beleid - Bedrijfsvoering - Bestand - Beheer/Beveiliging.

Nu de rolpatronen bekend zijn kunnen we daarmee vaststellen welke componenten, bouwstenen, nodig zijn om de informatiebehoeften in die rollen te kunnen bevredigen. We doen dit door nogmaals het globale transactieproces af te lopen weer vanuit het perspectief van de vragende burger. Vooraf moet worden opgemerkt dat die bouwstenen moeten worden opgevat als gemeentebreed in te zetten standaards. Standaardisatie vormt de ruggengraat van de Haagse aanpak.