Gemeente Alphen aan den Rijn

Gemeente Alphen aan den Rijn Second opinion Informatiearchitectuur, PvE en investeringsbudget programma elektronische dienstverlening 2005/2006

M&I/Argitek Steupelstraat 50 3065 JE Rotterdam Postbus 8046 3009 AA Rotterdam

T:010-2356983 F:010-2029708 [email protected] www.argitek.nl 15 maart 2006

Gemeente Alphen aan den Rijn: second opinion

INHOUDSOPGAVE Samenvatting ................................................................................................................1 1

2

3

4

Inleiding ..............................................................................................................3 1.1

Opdracht ....................................................................................................................... 3

1.2

Ervaring ........................................................................................................................ 3

1.3

Aanpak.......................................................................................................................... 3

Ambities ..............................................................................................................5 2.1

Doelstellingen............................................................................................................... 5

2.2

Second opinion ............................................................................................................. 6 2.2.1 Informatiearchitectuur ..................................................................................... 6 2.2.2 Programma van Eisen ...................................................................................... 6

Second opinion ...................................................................................................7 3.1

Informatiearchitectuur .................................................................................................. 7

3.2

Programma van Eisen................................................................................................... 8

3.3

Budget .......................................................................................................................... 9

3.4

Fasering ........................................................................................................................ 9 3.4.1 Basisregistraties ............................................................................................. 10 3.4.2 Document management .................................................................................. 10 3.4.3 Front-/midoffice.............................................................................................. 11 3.4.4 Relatiebeheer (CRM)...................................................................................... 11

3.5

Planning...................................................................................................................... 12

Bijlagen .............................................................................................................13 4.1

Toelichting: midoffice................................................................................................ 13

4.2

Toelichting: PvE......................................................................................................... 15

4.3

Toelichting: basisregistraties...................................................................................... 21

4.4

Toelichting: E-dossiers............................................................................................... 22

4.5

Toelichting: producten ............................................................................................... 23

4.6

Presentatie: kick-off ................................................................................................... 24 Apart bijgevoegd ........................................................................................................ 24

4.7

Presentatie: beleidsoverleg ......................................................................................... 24 Apart bijgevoegd ........................................................................................................ 24

4.8

Presentatie: kerngroep ................................................................................................ 24 Apart bijgevoegd ........................................................................................................ 24

Inhoudsopgave


SAMENVATTING Second opinion Voor een Europese aanbesteding op het gebied van E-dienstverlening heeft de gemeente Alphen aan den Rijn aan M&I opdracht gegeven haar hierbij te adviseren. De doelstelling van de eerste fase van dit adviestraject betreft een second opinion ten aanzien van: •

Informatiearchitectuur (paragraaf 3.1) De beoogde ‘front-, mid- en backoffice architectuur’ is de manier om een moderne infrastructuur voor elektronische dienstverlening te realiseren. Het EGEM-project Referentiemodel Midoffice dat thans ten einde loopt hanteert eveneens een dergelijke architectuur. De second opinion komt er op neer dat de informatiearchitectuur op enkele onderdelen na gehandhaafd kan blijven.

•

Programma van Eisen (paragraaf 3.2) De gemeente Alphen aan den Rijn heeft een prima document heeft opgeleverd, met een iets te grote ambitie. De beperking wordt gevormd door capaciteit enerzijds en het absorptievermogen van de organisatie anderzijds. Afzonderlijke onderdelen zijn meestal echter afdoende onderkend en beschreven, maar bij enkele punten kunnen additionele opmerkingen gemaakt worden:

•

Investeringsbudget (paragraaf 3.3) Voor wat betreft het eerste jaar zijn de middelen waarschijnlijk voldoende. Eventuele latere toevoegingen vergen vanzelfsprekend aanvullende investeringen. De echte bottleneck zit echter in beschikbare capaciteit: de gereserveerde capaciteit vwb vrijgemaakte uren wordt schromelijk onderschat. Daarom is een fasering opgesteld met een viertal speerpunten:

Fasering 1. Basisregistraties: BR’s (paragraaf 3.4.1) Dit betreft een pilot waarbij Burgerzaken en Geo-informatie de invoering van twee specifieke basisregistraties gaan voorbereiden: natuurlijke personen (BSN) en gebouwen. Voor wat betreft datadistributie is de dominantie van Centric in Alphen een gegeven. Door DDS4all te overwegen kan datadistributie buiten het PvE blijven en separaat bij Centric worden uitgevraagd. 2. Elektronische dossiers: DMS (paragraaf 3.4.2) Dit betreft een pilot bij Sociale Zaken (bijzondere bijstand). Zo wordt in een hanteerbare setting ervaring opgedaan met de ‘hogere’ fasen van document management. Bij succes kan dan ook op gecontroleerde wijze tot bredere uitrol overgegaan. Aldus ontstaat er de ruimte om in een rustige omgeving met DSP en beoogde lay-out van het E-dossier aan de slag te gaan. 3. Front-/midoffice: FO/MO (paragraaf 3.4.3) Dit betreft de aanbesteding conform het (aangepaste) PvE, waarmee een gemeentebrede basis wordt gelegd voor (elektronische) dienstverlening. Hiermee worden allereerst zeven producten gerealiseerd, verdeeld over 4 thema’s, waarbij soms niet verder kan worden gegaan dan fase 2. De functionaliteiten uit het PvE corresponderen met die thema’s conform de volgende tabel:

1


Vraaggeleiding E-formulieren Authenticatie / autorisatie Personalisatie E-betalen Broker (BPM) Adapters Workflow (WFM) Gegevensmagazijn Zakenmagazijn Geo-informatie (GIS) Klantcontact (CRM) Managementinformatie

Sociale Zaken V tzt V V nvt tzt tzt evt V V nvt V V

Ruimtebeheer V V V V V V V evt V V V V V

Burgerzaken V V V V nvt V evt V V V V V V

Financiën V tzt V V nvt tzt tzt V V V evt V V

4. Relatiebeheer: CRM (paragraaf 3.4.4) Voor relatiebeheer is kanaalonafhankelijke registratie van klantcontacten het uitgangspunt. Hierbij wordt gebruik gemaakt van dezelfde front-/midoffice infrastructuur met een belangrijke rol voor het zakenmagazijn. Op dezelfde wijze kan webintake gebruikt worden voor poststukken, E-mails en baliebezoeken. Aldus ontstaat in het zakenmagazijn een klanthistorie, inclusief status, correspondentie, etc. Hoewel ook EGEM dit uitdraagt, is deze markt nog niet uitgekristalliseerd. Planning •

Fase 1 (2006): speerpunten -

•

Aanbesteding, implementatie en ingebruikname front-/midoffice Pilot document management (E-dossiers) bij SoZa / Werk & Bijstand (RfP DIS4GWS) Pilot Basisregistraties: natuurlijke personen (BSN) en gebouwen bij Burgerzaken en Geo Pilot Relatiebeheer (CRM) bij SCA

Fase 2 (2007): uitbouw -

Uitbouw E-dienstverlening via front-/midoffice: meer producten Uitbouw DMS-pilot (indien succesvol): meer processen / afdelingen Uitbouw basisregistraties (evt met DDS4all): meer objecttypen Uitbouw relatiebeheer: meer kanalen / toepassingen

M.b.t. de speerpunten zijn in fase 1 de volgende functionaliteiten uit het PvE van toepassing:

Vraaggeleiding E-formulieren Authenticatie / autorisatie Personalisatie E-betalen Broker (BPM) Adapters Workflow (WFM) Gegevensmagazijn Zakenmagazijn Geo-informatie (GIS) Klantcontact (CRM) Managementinformatie Document management Datadistributie

BR’s X X X X X X X X V X V X X X V

DMS X X X X X X X X X X X X X V X

FO/MO V V V V V V V V V V evt V V X X

CRM V V V V X evt X V V V evt V V X evt

2


1

INLEIDING

1.1

Opdracht

Voor de beoogde Europese aanbesteding van functionaliteiten op het gebied van E-dienstverlening, waaronder een zogeheten ‘midoffice’, heeft de gemeente Alphen aan den Rijn aan M&I/Argitek en M&I/Partners (hierna kortweg M&I) opdracht gegeven haar te adviseren bij de voorbereiding, het selectieproces en het beoordelen van de uiteindelijke realisatie van de aanbesteding. De doelstelling van de eerste fase van dit adviestraject, welke wordt afgesloten met de onderhavige rapportage, betreft een zogeheten ‘second opinion’ ten aanzien van een drietal aspecten van het programma elektronische dienstverlening: • • •

De informatiearchitectuur Het Programma van Eisen Het investeringsbudget

1.2

Ervaring

M&I beschikt over ruime ervaring op het gebied van informatiearchitecturen, niet in de laatste plaats voor wat betreft de (elektronische) overheid. Doordat zij zelf geen implementaties uitvoert, noch allianties heeft met productleveranciers of systeemhuizen, kan M&I onafhankelijk adviseren bij pakket- en leveranciersselectie. Daarnaast begeleidt zij regelmatig (Europese) aanbestedingen. Eind 2005 heeft M&I in opdracht van het Programmabureau Elektronische Gemeenten (EGEM) een inventarisatie uitgevoerd voor zowel de vraag- (gemeenten) als aanbodzijde (leveranciers) van de markt voor gemeentelijke midoffice oplossingen (zie voor deze ‘Marktverkenning Midoffice’ de EGEM-site: http://www.egem.nl/kennisbank/informatievoorziening/uitwisseling/midofficerapport Momenteel rondt M&I het vervolgonderzoek af, waarbij in opdracht van EGEM en de gemeenten Zoetermeer, Utrecht en Rotterdam enkele toonaangevende gemeentelijke midoffice oplossingen in een laboratoriumopstelling ‘hands on’ wordt geëvalueerd. Tenslotte is M&I door EGEM gevraagd om een gezamenlijke aanbesteding van enkele gemeenten inzake een specifiek gemeentelijke midoffice oplossing te begeleiden. Het uitgangspunt daarbij wordt gevormd door de aanstaande resultaten van de EGEM-werkgroep Referentiemodel Midoffice en de evaluatiecriteria zoals gehanteerd in het voornoemde laboratoriumonderzoek.

1.3

Aanpak

De aanpak de eerste fase van dit adviestraject was als volgt: •

Informatiearchitectuur - Deskresearch: bestuderen documentatie informatiearchitectuur - Interviews: auteurs / stakeholders informatiearchitectuur - Aanvullend onderzoek - Analyse, samenvatting en conclusies - Terugkoppeling met projectleider

3

Gemeente Alphen aan den Rijn: second opinion •

Programma van Eisen - Deskresearch: bestuderen documentatie / Programma van Eisen - Interviews: inkoop / samenstellers Programma van Eisen - Aanvullend onderzoek - Suggesties op functioneel gebied - Terugkoppeling met projectleider

•

Investeringsbudget - Deskresearch: bestuderen documentatie / investeringsbudget - Interviews: opstellers / stakeholders investeringsbudget - Aanvullend onderzoek - Analyse, samenvatten en conclusies - Terugkoppeling met projectleider

De afgelopen periode heeft M&I, ten behoeve van deze second opinion, intensief met verschillende belanghebbenden binnen de gemeente Alphen aan den Rijn van gedachten gewisseld, vooral met de zogeheten ‘kerngroep’ (Nicoline Jansen, Dominique Omes, Richard Elschot, Nico Kooij). Daarbij heeft prof. Wouter J. Keller van M&I een drietal presentaties gegeven, welke onderdeel uitmaken van deze rapportage en zijn openomen in de bijlagen. Naast een aantal ‘reguliere’ bijeenkomsten met de kerngroep, hebben bovendien de volgende ‘buitengewone’ bijeenkomsten plaatsgevonden: •

Intake: adviesopdracht

•

Kick-off (introductie: zie presentatie bijlage 4.2)

•

Interviews: architectuur / budget -

Algemeen (Richard Elschot, Ronald de Ruijter) E-dossiers (Nico Kooij, Mario Huliselan) Relatiebeheer (Coen Verhagen, Lex Noyon) Basisregistraties (Martin Abrahams)

•

Beleidsoverleg (tussenrapportage: zie presentatie bijlage 4.7)

•

Interviews: Programma van Eisen -

•

Financiën / WOZ (Yvonne Vooren, Dick Miedema) Bouwen en Wonen / Ruimtebeheer (Nardy Beckers, Rees Hennekam) Burgerzaken / SCA (Coen Verhagen, Bart Beeren) Sociale Zaken (Henk Brouwer, Siem Noordermeer)

Kerngroep (second opinion: zie presentatie bijlage 4.8)

4


2

AMBITIES

2.1

Doelstellingen

De doelstelling zoals geformuleerd in de I-visie Dienstverlening naar de burger, dienstverlening bij de burger van gemeente Alphen aan den Rijn is het verhogen van de kwaliteit van dienstverlening, onder andere door meer gebruik te maken van het elektronische medium. Hiertoe is een Programma Elektronische Dienstverlening opgezet en een vooronderzoek uitgevoerd, waarvan de resultaten zijn weergegeven in het Fasedocument voorbereidingsfase uitvoering informatie visie. Hieruit komt de volgende ambitie naar voren: •

Aanschaf van een generieke voorziening (functionaliteiten) welke de drager vormt voor de elektronische dienstverlening en de koppeling bewerkstelligt tussen het front- en backoffice (midoffice).

•

Het faciliteren van het frontoffice voor wat betreft veel gestelde vragen, afhandelen meldingen en doorgeleiding van aanvragen naar het backoffice, inclusief voortgangsbewaking (ongeacht de wijze waarop een klant contact legt).

•

Het faciliteren van de thema’s Bouwen en Wonen / Ruimteheer, Financiën / WOZ, Klantcontact, Sociale Zaken en Burgerzaken door per thema 1 à 2 producten te realiseren tot en met fase 3 (dat wil zeggen elektronische verwerking) van elektronische dienstverlening.

De beoogde uitwerking van de voornoemde thema’s naar concrete producten is als volgt:

1 2 3 4 5 6 7

Producten Aanvraag lichte bouwvergunning Bezwaar gemeentelijke belastingen Inzage taxatiegegevens Aanvraag bijzondere bijstand Algemene informatievraag Meldingen openbaar gebied Verhuisbericht doorgeven

Thema‘s Bouwen en wonen / Ruimtebeheer Financiën / WOZ Financiën / WOZ Sociale Zaken Burgerzaken / klantcontact (SCA) Burgerzaken / klantcontact (SCA) Burgerzaken

Voor de eerste fase van het Programma Elektronische Dienstverlening gelden de volgende ambities en deliverables: •

Geïmplementeerde functionaliteiten ter ondersteuning van de frontoffice.

•

Realisatie van elektronische dienstverlening voor overige producten.

•

Geïmplementeerde functionaliteiten voor de gewenste koppeling tussen front- en backoffice (midoffice).

•

Werkwijze voor het uitbreiden van de gerealiseerde elektronische dienstverlening in de diepte (t/m fase 4) en het realiseren van nieuwe elektronische dienstverlening in de breedte.

•

Inzicht in een doorgroeitraject waarbij eind 2007, conform de rijksdoelstelling, voor 65% van de producten elektronische dienstverlening mogelijk is.

5


2.2

Second opinion

2.2.1

Informatiearchitectuur

De gemeente Alphen aan den Rijn heeft voor het Programma Elektronische Dienstverlening in haar I-visie reeds een globale informatiearchitectuur opgesteld. Deze architectuur omvat respectievelijk een (multi-channel) frontoffice, midoffice en backoffice:

Als onderdeel van deze eerste fase van het adviestraject zal M&I een second opinion geven op deze informatiearchitectuur. 2.2.2

Programma van Eisen

In het kader van de beoogde aanbesteding van functionaliteiten op het gebied van E-dienstverlening heeft de gemeente Alphen aan den Rijn bovendien een uitgebreid Programma van Eisen opgesteld. Als onderdeel van deze eerste fase van het adviestraject zal M&I een second opinion geven op dit Programma van Eisen.

6


3

SECOND OPINION

3.1

Informatiearchitectuur

De beoogde ‘front-, mid- en backoffice architectuur’ wordt momenteel gezien als de geëigende manier om een moderne en toekomstgerichte infrastructuur voor (elektronische) dienstverlening te realiseren. Ook het EGEM-project Referentiemodel Midoffice, dat momenteel een gemeentelijke referentiearchitectuur voor het midoffice ontwerpt, hanteert een dergelijke architectuur. Binnen deze architectuur wordt een centrale plaats ingenomen door het zogeheten ‘midoffice’. Het midoffice is echter niet slechts een architectuurconcept maar laat zich ook concreet maken als een verzameling functionaliteiten die de processen en bijbehorende applicaties in front- en backoffice met elkaar verbindt (zie toelichting bijlage 4.1). De betreffende functionaliteiten zijn dan ook als zodanig opgenomen in het oorspronkelijke PvE van de gemeente Alphen aan den Rijn. Op basis van de reeds beschikbare schets van de beoogde informatiearchitectuur, het bijbehorende (oorspronkelijke) PvE en verschillende aanvullende gesprekken (zie paragraaf 1.3), zijn een aantal elementen uit dit PvE gehaald. Deze elementen zullen, met name vanwege de beperkte beschikbare capaciteit, niet in de integrale aanbesteding worden meegenomen. De overige functionaliteiten resulteren, analoog aan de voornoemde ‘front-, mid- en backoffice architectuur’, in het volgende functionele architectuurplaatje:

Deze functionele architectuur vertoont weliswaar grote gelijkenis met de architectuurschets van de gemeente Alphen aan den Rijn, maar verschilt daar desalniettemin op enkele essentiële punten van. De verschillende ‘kanalen’ (balie, post, telefoon, web, E-mail en fax) zijn weggelaten. Elk van de elementen aan de linkerkant van de functionele architectuur hebben betrekking op de‘website’ zoals opgenomen in de geschetste informatiearchitectuur. Hierbij maakt het aldaar genoemde onderdeel ‘raadsinformatie’ in de functionele architectuur deel uit van het element ‘webpublicatie’.

7


De second opinion ten aanzien van de informatiearchitectuur komt er grofweg op neer dat deze, met uitzondering van document management, zo goed als gehandhaafd blijft. De verschillende aspecten uit de informatiearchitectuur van de gemeente Alphen aan den Rijn komen terug in de geschetste functionele architectuur. Voor wat betreft klantcontacten klachtenregistratie, alsmede workflow management functionaliteit worden voorlopig geen separate producten aangeschaft. Evenals de zaakbehandelaar worden deze functionaliteiten vooralsnog door middel van de combinatie van midoffice broker en gegevens- en zakenmagazijn gerealiseerd (fase 1).

3.2

Programma van Eisen

Allereerst dient in dit kader opgemerkt dat de gemeente Alphen aan den Rijn dienaangaande een prima document heeft opgeleverd, hoewel er wellicht sprake is van een iets te grote ambitie. Men wil teveel tegelijk, waarbij beperking gevormd wordt door de beschikbaarheid van eigen mensen enerzijds en het absorptievermogen van de organisatie anderzijds. Desalniettemin zijn afzonderlijke onderdelen in de meeste gevallen afdoende onderkend en beschreven. Op een aantal punten kunnen echter additionele opmerkingen gemaakt worden: •

Er is sprake van een eventuele upgrade van het CMS naar een nieuwe release. Hoewel er vragen waren met betrekking tot de eventuele gevolgen hiervan voor de uitkomst van de aanbesteding, doet één en ander nauwelijks terzake. Indien een integratie met Seneca als wens dan wel als eis wordt meegenomen in het PvE worden mogelijk één of meer oplossingen uitgesloten, maar dat heeft niets met de eventuele upgrade van doen; een oplossing integreert doorgaans wel of juist niet met Seneca.

•

Het opnemen van complexe beslisbomen in het Programma van Eisen wordt niet afgeraden, doch hooguit als wens en niet als eis. Voorzover er naast of in aanvulling op vraaggeleiding nog behoefte is aan specifieke zoekfunctionaliteit, dient deze in het PvE te worden opgenomen.

•

Sommige E-loket oplossingen gaan standaard vergezeld van een product/dienstencatalogus; men zal zich moeten uitspreken of de huidige PDC gehandhaafd blijft of deze ook wordt aanbesteed.

•

Voor het uiteindelijke PvE is integratie met de huidige tool voor identity management (Microsoft Active Directory), onder andere voor zogeheten ‘Single Sign-On’ (SSO), vereist.

•

Voorzover er naast of in aanvulling op reguliere vraaggeleiding nog behoefte is aan specifieke (geavanceerde) zoekfunctionaliteit, dient deze als zodanig in het PvE te worden opgenomen.

•

Desgewenst kunnen omtrent de (toekomstige) incorporatie van het GouwIT WOZ-portaal reeds bepaalde eisen/randvoorwaarden worden meegenomen in het PvE.

•

Ten behoeve van de functionaliteit voor het beantwoorden van algemene informatievragen dient te worden opgemerkt dat, voorzover men daarbij van (geavanceerde) zoekfunctionaliteit en/of beslisbomen gebruik wil maken, zulks in het huidige PvE niet voldoende scherp is geformuleerd.

Een inhoudelijke toelichting op de afzonderlijke onderdelen van het PvE is opgenomen in bijlage 4.2. Ten opzichte van het oorspronkelijke PvE ontbreken de functionaliteiten contactregistratie, managementinformatie en geo-informatie aldaar. Document management en datadistributie worden niet in het uiteindelijke PvE meegenomen. Hiervoor zullen, evenals voor contactregistratie, pilots gestart worden (zie verderop). Managementinformatie en geo-informatie zullen als zodanig wel in het uiteindelijke PvE van de front-/midoffice aanbesteding worden meegenomen.

8


In het eerste geval betreft het een eis ten aanzien van de minimale kwaliteit en kwantiteit, in het tweede geval vooral een wens/eis ten aanzien van (koppeling met) het huidige GIS FlexiWeb/Argis. Afgezien van deze koppeling is in beide functionaliteiten bij het oorspronkelijke PvE voorzien. In de volgende fase van dit adviestraject zal M&I met de gemeente Alphen aan den Rijn het PvE afronden, eisen en wensen bepalen, wegingen toekennen en beoordelingsprocedure vaststellen. Resumerend kan gesteld worden dat het oorspronkelijke Programma van Eisen van de gemeente Alphen aan den Rijn op de meeste punten degelijk is opgesteld. Op een aantal punten is echter nog aanscherping vereist, met name voor wat betreft de specifieke inrichting van het gegevens- en zakenmagazijn ten behoeve van de beoogde functionaliteiten (contactregistratie, melding openbaar gebied, statusvolging en dergelijke). Daarnaast kunnen aandachtpunten uit de taxonomie van het laboratoriumonderzoek aanleiding zijn om op specifieke punten het PvE verder aan te scherpen.

3.3

Budget

Middelen Ten aanzien van het beschikbare budget voor het programma E-dienstverlening, zoals opgenomen in de betreffende begroting, kan kort en goed worden opgemerkt dat zulks -althans voor wat betreft het eerste jaar- naar alle waarschijnlijkheid afdoende is. Hierbij dient overigens direct opgemerkt te worden dat uitsluitend naar ‘out of pocket’-kosten is gekeken. Eventuele latere toevoegingen vergen vanzelfsprekend een aanvullende investering.

Capaciteit De echte bottleneck zit echter in de mate waarin er interne capaciteit kan worden vrijgemaakt om één en ander te kunnen realiseren. In de huidige opzet schort hier namelijk nog wel iets aan; de gereserveerde capaciteit in termen van vrijgemaakte uren wordt schromelijk onderschat. Bovendien betreft het hier voor het overgrote deel personen die het er, oneerbiedig gezegd, ‘bij doen’. Dit terwijl de huidige en toekomstige ontwikkelingen met betrekking tot ICT en aanpalende gebieden nu juist van gemeenten verlangen dat zij de omslag maken van een ‘productieorganisatie’ naar een ‘projectorganisatie’. Met name in de nabije toekomst zal verandering voor gemeenten welhaast de enige constante zijn. Dit vereist echter een totaal andere benadering met bijbehorende organisatie (meer capaciteit op I&A) en vaardigheden (projectmatig werken). Gezien de voornoemde, beperkte capaciteit in combinatie met het feit dat het absorptievermogen van een organisatie met betrekking tot verandering slechts beperkt is, is in overleg met de gemeente Alphen aan den Rijn een fasering opgesteld waarbij een viertal speerpunten wordt onderkend. In de beoogde fasering wordt aanvankelijk slechts één van deze speerpunten (te weten ‘front-/midoffice’) in de volle breedte opgepakt, terwijl voor elk van de overige drie een pilot wordt geïnitieerd. Eén en ander wordt toegelicht in de volgende paragraaf.

3.4

Fasering

Gezien het voorgaande argumentatie (paragraaf 3.3) is een fasering opgesteld waarbij een viertal speerpunten wordt onderkend. In deze fasering wordt aanvankelijk slechts één speerpunt (te weten ‘front-/midoffice’) in de volle breedte opgepakt, terwijl voor elk van de overige drie eerst een pilot wordt geïnitieerd. Hierna wordt elk van de vier speerpunten afzonderlijk toegelicht.

9


3.4.1

Basisregistraties

Ten aanzien van basisregistraties (zie toelichting in bijlage 4.3) is besloten deze nog niet op korte termijn over de volle breedte in te voeren. Niet alleen is daartoe op dit moment nog geen noodzaak, maar ook is het in dezen verstandig om eerst op kleinere schaal ervaring op te doen. Aldus kan men leren van de ervaringen die hieromtrent bij andere gemeenten zullen worden opgedaan. In het kader van de pilot basisregistraties zullen de afdelingen Burgerzaken en Geo-informatie de invoering van een tweetal specifieke basisregistraties gaan voorbereiden. Dit betreft natuurlijke personen (BSN) en gebouwen. In dat kader kan worden gewezen op een rapport dat is opgesteld in opdracht van het Ministerie van VROM. De ‘Handreiking implementatie basisregistraties adressen en gebouwen’ (www.vrom.nl) geeft een adequaat overzicht van de stappen die een gemeente moet doorlopen om te komen tot een stelsel van basisregistraties. Hoewel bij de inventarisatie en bestandsvergelijking van de betreffende gegevensverzamelingen geografie component gebruikt kan worden, is dat bij burgers niet het geval. In het oorspronkelijke Programma van Eisen van de gemeente Alphen aan den Rijn was bovendien ‘datadistributie’ opgenomen. Dit heeft betrekking op distributie van gestructureerde (basis)gegevens tussen verschillende (basis)registraties: tussen backoffice applicaties onderling, maar bijvoorbeeld ook met een eventueel gegevensmagazijn. Een datadistributievoorziening wordt dan ook wel een ‘backoffice broker’ genoemd. Hoewel deze in architectuurplaatjes meestal ‘achter’ de verschillende backofficesystemen gepositioneerd wordt, is er een ontwikkeling zichtbaar waarbij datadistributie ondergebracht wordt in de midoffice broker. Dit laatste is echter meer iets voor de langere termijn. Hoewel de beschrijving van ‘datadistributie’ de schijn kan wekken het een technische oplossing behelst, is er een niet te onderschatten organisatorische component. Natuurlijk is het primair een technische voorziening die gegevensdistributie vanuit het bronbestand over verschillende afnemers realiseert. Invoering van een systeem van basisregistraties/bronbestanden heeft echter behoorlijke organisatorische consequenties en vergt een niet geringe ‘cultuuromslag’ van alle betrokkenen. Dit het geheel van organisatorische afspraken en dergelijke rondom het opvoeren, inzien en muteren van gestructureerde gegevens wordt aangeduid als ‘administratieve organisatie’ (AO). Waar men wellicht gewoon is een eigen ‘schaduwbestand’ te onderhouden, wordt men verplicht (!) gebruik te maken van het gemeentelijke bronbestand. De kwaliteit en integriteit daarvan staat of valt niet met de technische voorziening (dat is ‘slechts’ en noodzakelijke voorwaarde), doch juist met de organisatorische afspraken daaromheen, bijvoorbeeld de plicht tot terugmelding bij lokale onjuistheden. Deze worden in het betreffende bronbestand hersteld, waarna datadistributie ervoor zorgdraagt dat mutaties de aangesloten systemen worden doorgevoerd (abonnement). Hoewel er meerdere oplossingen van verschillende leveranciers op de markt zijn, moet dominantie van applicaties van Centric in Alphen aan den Rijn als gegeven worden beschouwd. Door dan ook het Centric product te overwegen (DDS4all), wordt de technische implementatie wat eenvoudiger. Aldus kan de selectie van een datadistributie oplossing eenvoudig buiten het Programma van Eisen worden gehouden en desgewenst separaat bij Centric worden uitgevraagd. 3.4.2

Document management

Voor wat betreft document management is, om een aantal redenen, besloten deze functionaliteit vooralsnog niet gemeentebreed aan te besteden. De ervaring leert dat de gemeentebrede uitrol van elektronische dossiers een ingrijpende zaak is en geen ruimte overlaat voor andere activiteiten (qua capaciteit en middelen). Bovendien brengen dergelijke operaties een zeer groot risico met zich mee, zodat het verstandig is om eerst op kleinere schaal ervaring op te doen hiermee. 10


Ten aanzien van elektronische dossiers is besloten te beginnen met een relatief kleinschalige pilot bij Sociale Zaken. Hierbij worden ook de aanbevelingen uit het rapport van Getronics/PinkRoccade gevolgd. Zo wordt in een kleinere setting ervaring opgedaan met de ‘hogere’ fasen van document management (zie toelichting bijlage 4.3). Bij succes heeft dit ook een gunstige uitstraling op de rest van de organisatie, wat in de toekomst mogelijk tot minder weerstand leidt. Voor de pilot is het proces ‘bijzondere bijstand’ gekozen. Hier is support van het management en enthousiasme van de medewerkers, hetgeen een voorwaarde is voor het welslagen, maar ook een reden voor het succes. Het betreft immers een beperkt groepje medewerkers in een afgebakend gebied. Hoewel voor een kleinschalige pilot ook reeds een behoorlijke infrastructuur moet worden opgetuigd, maakt dat het geheel meer beheersbaar en de kans op succes groter. Bij succes kan ook snel besloten worden tot bredere uitrol van E-dossiers bij Sociale Zaken, waarbij de opgedane kennis en ervaring van pas komt. Bovendien wordt aldus ruimte geschapen om met het DSP aan de slag te gaan, zonder interferentie van een zwaar DMS-traject, en kan er in een relatief rustige omgeving begonnen worden met het vaststellen van de beoogde lay-out van het E-dossier. 3.4.3

Front-/midoffice

Dit betreft de aanbesteding van de functionaliteiten zoals genoemd in het PvE. Met deze investering in een front-/midoffice infrastructuur wordt een gemeentebrede basis gelegd voor (elektronische) dienstverlening. Hiermee wordt allereerst een aantal producten gerealiseerd, waarbij soms niet verder kan worden gegaan dan fase 2. Het betreft 7 producten verdeeld over 4 thema’s (zie ook de toelichting in bijlage 4.5). De verschillende functionaliteiten uit het PvE corresponderen met de genoemde thema’s zoals aangegeven in onderstaande tabel:

Vraaggeleiding E-formulieren Authenticatie / autorisatie Personalisatie E-betalen Broker (BPM) Adapters Workflow (WFM) Gegevensmagazijn Zakenmagazijn Geo-informatie (GIS) Klantcontact (CRM) Managementinformatie

Sociale Zaken V tzt V V nvt tzt tzt evt V V nvt V V

Ruimtebeheer V V V V V V V evt V V V V V

Burgerzaken V V V V nvt V evt V V V V V V

Financiën V tzt V V nvt tzt tzt V V V evt V V

Een ‘tzt’ geeft aan dat van de betreffende functionaliteit in dat specifieke geval weliswaar nog geen sprake is, maar dat de front-/midoffice infrastructuur volledig is voorbereid om deze te realiseren; voor Financiën als GouwIT wordt ‘aangehaakt’ op de informatiearchitectuur en voor Sociale Zaken als er met E-formulieren en (op termijn) mogelijk zelfs met adapters gewerkt gaat worden. 3.4.4

Relatiebeheer (CRM)

Voor Relatiebeheer is kanaalonafhankelijke registratie van klantcontacten het uitgangspunt. Hierbij wordt gebruik gemaakt van dezelfde front-/midoffice infrastructuur (zie vorige paragraaf). Hierbij is een belangrijke rol voor het zakenmagazijn, waarin de daadwerkelijke registratie van klantcontacten plaatsvindt, en het webintake systeem. Met deze laatste vindt immers de daadwerkelijke registratie van klantcontacten plaats voorzover dit niet automatisch geschiedt. 11


In tegenstelling tot het webkanaal, waarbij de contactregistratie wel automatisch kan plaatsvinden, zal een medewerker in het callcenter het klantcontact middels een formulier moeten registreren. Op dezelfde wijze kan het webintake systeem bijvoorbeeld ook gebruikt worden voor het registreren van poststukken, E-mails en baliebezoeken. Aldus ontstaat in het zakenmagazijn een klanthistorie, inclusief statusinformatie, correspondentie en dergelijke. Hoewel dit ook het beeld is dat EGEM voor ogen heeft bij de referentiearchitectuur is dit aan de aanbodzijde van de markt (gemeentelijke front-/midoffice oplossingen) nog niet uitgekristalliseerd. Hiertoe zal in het PvE dan ook een vrij uitgebreide beschrijving moeten worden opgenomen.

3.5

Planning

Fase 1 (2006): speerpunten • Aanbesteding, implementatie en ingebruikname front-/midoffice • Pilot document management (E-dossiers) bij SoZa / Werk & Bijstand (RfP DIS4GWS) • Pilot Basisregistraties: natuurlijke personen (BSN) en gebouwen bij Burgerzaken en Geo • Pilot Relatiebeheer (CRM) bij SCA M.b.t. de speerpunten zijn in fase 1 de volgende functionaliteiten uit het PvE van toepassing:

Speerpunten Functionaliteiten Vraaggeleiding E-formulieren Authenticatie / autorisatie Personalisatie E-betalen Broker (BPM) Adapters Workflow (WFM) Gegevensmagazijn Zakenmagazijn Geo-informatie (GIS) Klantcontact (CRM) Managementinformatie Document management Datadistributie

Front-/ midoffice V V V V V V V V V V evt V V X X

Document management X X X X X X X X X X X X X V X

Basisregistraties X X X X X X X X V X V X X X V

Relatiebeheer V V V V X evt X V V V evt V V X evt

Fase 2 (2007): uitbouw • Uitbouw E-dienstverlening via front-/midoffice: meer producten • Uitbouw DMS-pilot (indien succesvol): meer processen / afdelingen • Uitbouw basisregistraties (evt met DDS4all): meer objecttypen • Uitbouw relatiebeheer: meer kanalen / toepassingen

12


4

BIJLAGEN

4.1

Toelichting: midoffice

In het EGEM-project ‘Architecturen, Referentiemodellen en Standaarden’ wordt momenteel hard gewerkt aan het ontwikkelen van een praktische gemeentelijke referentiearchitectuur. Hoewel het hier vooralsnog slechts een voorlopige versie betreft (de actualisering is thans gaande), tekenen zich hierin reeds de contouren af van een zogeheten ‘front-, mid- en backoffice’ architectuur. Hierbij bewerkstelligt een zogeheten ‘midoffice’ de verbinding tussen het front- en het backoffice wanneer deze functioneel, technisch en/of procesmatig van elkaar worden gescheiden (de zogeheten ‘knip’). •

Frontoffice Het frontoffice vormt de presentatielaag van de gemeentelijke organisatie naar de buitenwereld. Dit heeft bijvoorbeeld betrekking op klantcontacten als het stellen van vragen en het aanvragen van producten. Tegenwoordig heeft een gemeente via veel verschillende kanalen contact met de buitenwereld: schriftelijk (post), telefonisch (callcenter), elektronisch (website, E-mail) en fysiek (balie). Dit noopt tot kanaalsynchronisatie, waarbij klantcontacten op uniforme wijze geschieden en de informatie via ieder kanaal actueel, correct en inhoudelijk congruent is. Het uitgangspunt voor het frontoffice is de klant; van daaruit worden de specialismen (backoffice) aangesproken.

•

Backoffice Het backoffice daarentegen vormt juist het hart van de organisatie waar zich, onzichtbaar voor de buitenwereld, de primaire (gegevensverwerkende) processen afspelen. Voor het backoffice is het specialisme het uitgangspunt; van daaruit worden de producten aan de klanten geleverd. In het backoffice werken ambtenaren bijvoorbeeld aan de afhandeling van een productaanvraag; men stuurt een ontvangstbevestiging, controleert of de aanvraag ontvankelijk is, verifieert verstrekte gegevens, voert een inhoudelijke beoordeling uit en stelt de uiteindelijke beschikking op, welke tenslotte naar de klant wordt verstuurd.

•

Midoffice De ontkoppeling van front-, en backoffice door middel van een zogeheten midoffice vormt het uitgangspunt van een dergelijke architectuur. Het midoffice als architectuurconcept bevindt zich tussen het front- en backoffice. Als zodanig is het een verzameling functionaliteiten die zowel de processen als de bijbehorende applicaties en data in front- en backoffice met elkaar verbindt. Het midoffice vormt als het ware een ‘tussenlaag’ waarlangs alle front- en backoffice systemen via één generiek (ont)koppelvlak worden ontsloten (zie figuur: frontoffice [FO], backoffice [BO] en het midoffice [MO] daartussen). Zo worden ook ongewenste afhankelijkheden uitgebannen. Aldus kunnen bovendien aanvragen die verschillende backoffice applicaties raken vanuit één centraal punt (het midoffice) elektronisch worden afgehandeld. Een aanvraag tot het bouwen van een garage bijvoorbeeld kent aspecten die betrekking hebben op meerdere backoffice systemen: een bouwvergunning, een eventuele kapvergunning en eisen met betrekking tot welstand, milieu, bestemmingsplannen en dergelijke. Het automatiseren van een dergelijk proces vereist centrale sturing, welke verzorgd wordt door het midoffice.

13


Het voornoemde EGEM referentiemodel onderkent de volgende vier principes voor het geheel van front-, mid- en backoffice: •

Het frontoffice ondersteunt vraaggestuurde, integrale, consistente en uniforme dienstverlening aan burgers, bedrijven en medewerker via de verschillende kanalen. In het backoffice vindt verdere procesuitvoering plaats op basis van product-/sectorgerichte specialismen.

•

De wederzijdse afhankelijkheid tussen front- en backoffice is expliciet gemaakt ter specificatie van het midoffice. Het frontoffice gebruikt de processen en gegevens van de backoffice als basis voor integrale beantwoording van klantvragen. Het backoffice (basisregistraties, bronbestanden) worden (deels) geactualiseerd en gestimuleerd via de frontoffice processen.

•

Het midoffice, waarin integratie-, distributie- en coördinatiefuncties worden gedacht, is op bedrijfsniveau weliswaar moeilijk aanwijsbaar maar vindt met name een positie in de applicatie-, data- en platformniveaus van de architectuur.

•

Op bedrijfsniveau komt het midoffice tot uiting in de vorm van afhankelijkheden tussen front- en backoffice activiteiten, gebeurtenissen en objecten zoals bedrijfs- en coördinatieregels voor de gewenste procesgang.

Er kan echter op verschillende wijze invulling gegeven worden aan het midoffice concept. Zo wordt er bijvoorbeeld een onderscheid gemaakt tussen zogeheten ‘dunne’ en ‘dikke’ midoffices. Hoewel de voornoemde marktverkenning overwegend gericht was op dunne midoffices, is er bij gemeenten momenteel een onmiskenbare trend naar dikke midoffices waarneembaar is. •

Dun midoffice Het dunne midoffice fungeert uitsluitend als ‘makelaar’ (broker) voor elektronische berichten en als zodanig derhalve geen geheugen heeft (stateless) maar hooguit een beperkte set replica’s van gegevens uit het backoffice in een gegevensmagazijn. Dit betreft uitsluitend zogeheten ‘koude’ data (read-only), zoals bijvoorbeeld een kopie van het GBA voor DigiD-authenticatie. Een dun midoffice is daarmee vooral een technische voorziening, waarbij door middel van elektronische berichten aanvragen vanuit het frontoffice (webintake) via het midoffice (broker) door middel van adapters rechtstreeks naar het backoffice worden geleid (zogeheten ‘straight through processing’).

14


Dik midoffice Bij het dikke midoffice groeien front- en midoffice naar elkaar toe en vervaagt het onderscheid. Het geheel krijgt daardoor als het ware de functie van een vooruitgeschoven backoffice. Hierbij wordt rondom het midoffice een soort publieksdienst gevormd, waar voor bepaalde producten en diensten (een deel van) de backoffice taken naar worden overgeheveld. Een dik midoffice heeft als zodanig dus wel een eigen geheugen (statefull) en bevat derhalve naast koude data in een gegevensmagazijn ook zogeheten ‘warme’ data (bijvoorbeeld proces- en statusinformatie) in een zakenmagazijn. Een dik midoffice is daarmee een meer organisatorische voorziening. Doordat de voor een technische midoffice benodigde adapters nog beperkt beschikbaar zijn, is bij gemeenten momenteel een onmiskenbare trend naar dergelijke organisatorische midoffices waarneembaar.

4.2 •

Toelichting: PvE

Webpublicatie Dit betreft de content management omgeving van waaruit de benodigde informatie (‘content’) op het web wordt gepubliceerd. In het geval van de gemeente Alphen aan den Rijn heeft zulks dan ook betrekking op de SmartSite omgeving, het huidige contentmanagement systeem (CMS). In het programma van Eisen is geen sprake van content management functionaliteit, aangezien men deze niet wil aanbesteden; het huidige systeem functioneert immers naar behoren. Ook ‘raadsinformatie’ wordt hiertoe gerekend.

•

Vraaggeleiding Dit betreft de wijze waarop klanten (burgers/bedrijven) begeleid kunnen worden om vanuit hun ‘vraag’ bij het juiste product te komen. Hiertoe bestaan bepaalde zoekmogelijkheden (zogeheten ‘vraagpatronen’), zoals op alfabet, levensgebeurtenis of via een alfabetische lijst. Daarnaast is zoeken op vrije tekst (zogeheten ‘full text search’) een belangrijke functionaliteit die nog wel eens wordt vergeten. Eén en ander sluit immers goed aan bij de intuïtieve beleving van klanten, bijvoorbeeld door ervaring met zoekmachines als Google. Door middel van een heldere structuur in de product/dienstencatalogus (PDC) en de genoemde vraagpatronen, kunnen klanten redelijkerwijs verwacht worden juiste product te kunnen vinden. Op dit moment wordt binnen de gemeente Alphen aan den Rijn gebruik gemaakt van de PDC van SmartSite. Sommige E-loket oplossingen gaan echter standaard vergezeld van een dergelijke PDC, zodat men zich zal moeten uitspreken of men met de huidige PDC verder wil. Daarnaast overweegt de gemeente Alphen aan den Rijn gebruik te gaan maken van geavanceerde vraaggeleiding middels een kennissysteem (zogeheten ‘beslisbomen’). Een dergelijk systeem zou in de eerste plaats voor vraaggeleiding door de medewerkers in het frontoffice (callcenter) moeten dienen, maar kan desgewenst ook op het web worden ingezet. Het werken met dergelijke beslisbomen is weliswaar een adequate manier om de beoogde vraaggeleiding te realiseren, doch dergelijke systemen staan nog relatief in de kinderschoenen. Bovendien kan (het leeuwendeel van) de beoogde functionaliteit gerealiseerd worden middels een krachtige E-formulieren oplossing (zie verderop), hetgeen ook voor andere (toekomstige) ontwikkelingen van belang is. Het opnemen van complexe beslisbomen in het Programma van Eisen raadt M&I als zodanig niet af, doch hooguit als wens en niet als eis. Voorzover er naast of in aanvulling op vraaggeleiding nog behoefte is aan specifieke zoekfunctionaliteit, dient deze als zodanig in het PvE worden opgenomen. Voor beide geldt echter wel dat de gewenste functionaliteit afdoende helder en volledig beschreven dient te worden. 15


Elektronische formulieren Eén van de belangrijkste onderdelen van de functionele architectuur wordt gevormd door de functionaliteit op het gebied van elektronische formulieren. Deze zogeheten ‘webintake’ betreft het kunnen creëren, publiceren, (doen) invullen en verwerken van elektronische formulieren. Dit betreft eerst en vooral elektronisch in te vullen (web)formulieren en dus niet zozeer uit te printen (PDF-)formulieren. Daarnaast zal men dergelijke elektronische (web)formulieren op termijn ook voor de additionele kanalen willen gaan gebruiken, zoals ten behoeve van het SCA (balie en callcenter) en op de iets termijn zelfs voor postregistratie. Hiertoe is echter wel bepaalde (extra) functionaliteit vereist, waarmee reeds bij de aanbesteding rekening gehouden dient te worden. Dit betreft bijvoorbeeld zaken als authenticatie en autorisatie (zie ook verderop), zodat het bijvoorbeeld mogelijk wordt dat een SCA-medewerker op een bepaald formulier een specifiek veld wel kan invullen of anderszins informatie kan zien, welke voor een klant onzichtbaar is. Het verwerken van een webformulier door het webintake systeem geschiedt door de aanvraag als elektronisch bericht (XML) te verzenden. Het kunnen meesturen van bijlagen in de vorm van een document is een belangrijke functionaliteit, evenals het kunnen afvangen van fouten (zogeheten ‘validatie’). Ten behoeve van de, al dan (voorlopig) niet geautomatiseerde verwerking van de aldus verzamelde gegevens in het backoffice (zie verderop) is het namelijk van groot belang om deze gegevens zo schoon mogelijk aangeleerd te krijgen. Tenslotte is in dit kader nog de mate van intelligentie waarmee de formulieren kunnen worden uitgerust, bijvoorbeeld de mogelijkheid tot het overslaan van (groepen) velden en het vooraf invullen van gegevens (zogeheten ‘prefill’), een aandachtpunt. In het kader van het laboratoriumonderzoek naar gemeentelijke midoffice oplossingen dat thans door M&I/Argitek wordt uitgevoerd en waarin webintake functionaliteit een prominente plaats inneemt, staan in de dienovereenkomstige onderdelen van de zogeheten taxonomie verschillende aandachtspunten welke niet als zodanig in het oorspronkelijke PvE van de gemeente Alphen aan den Rijn voorkomen. Een dergelijke ‘taxonomie’ behelst een hiërarchische ordening van hoofden subcriteria, op basis waarvan enkele toonaangevende gemeentelijke midoffice oplossingen in een proefopstelling ‘hands on’ wordt geëvalueerd. Ook voor andere onderdelen van het PvE staan in deze taxonomie nog enkele additionele aandachtpunten welke als aanvulling op het oorspronkelijke PvE kunnen worden meegenomen.

•

Authenticatie en autorisatie Authenticatie en autorisatie hebben niet alleen betrekking op het klantdomein (zoals DigiD), maar ook op het medewerkerdomein. Indien men immers de elektronische formulieren ook aan de balie en in het callcenter wil kunnen gebruiken, hetgeen op zichzelf reeds bepaalde voordelen heeft, is een adequaat autorisatiemodel van groot belang. Met name de verschillende niveaus waarop geautoriseerd kan worden (individu, groep) en op welk niveau er vervolgens bepaalde rechten kunnen worden toegekend (liefst op veldniveau), zijn hierbij zwaarwegende issues. Ook ten behoeve van de ‘generieke applicatie’ functionaliteit van het midoffice (zie verderop) is het van groot belang in welke mate dergelijke functionaliteit kan worden ‘doorgegeven’. Voor wat betreft het uiteindelijke PvE is de integratie met de huidige tool voor identity management (Microsoft Active Directory), onder andere voor zogeheten ‘Single Sign-On’ (SSO), dan ook een vereiste. In het voornoemde midoffice laboratoriumonderzoek is dergelijke functionaliteit (SSO, integratie met identity management tools en dergelijke) dan ook expliciet meegenomen.

16


Personalisatie Binnen het kader van elektronische dienstverlening heeft personalisatie dikwijls betrekking op ‘Mijn gemeente’-functionaliteit: de persoonlijke internetpagina (PIP) Mijn Alphen aan den Rijn. Dit betreft doorgaans een onderdeel van de gemeentelijke website waar klanten, nadat ze zijn geauthenticeerd, toegang toe krijgen teneinde persoonlijke berichtgevingen zoals de status van lopende productaanvragen in te zien. Daarnaast bieden gemeenten burgers de mogelijkheid om de eigen (GBA-)gegevens te verifiëren of persoonlijke kennisgevingen te ontvangen. Denk aan proactieve meldingen (“uw rijbewijs verloopt volgende week”), informatieverstrekking op basis van een eigen interesseprofiel of locatiegebonden berichtgeving (zoals bouwvergunningen in de eigen buurt). In het kader van deze laatste opmerking dient opgemerkt te worden dat hierbij de geografische component van gegevens (dwz de XY-coördinaten) een belangrijke rol spelen. Deze vormen immers de ‘sleutel’ op basis waarvan dergelijke informatie kan worden ontsloten. Tenslotte in dit kader nog de opmerking dat de voornoemde ‘Mijn Gemeente’-functionaliteit binnen Alphen aan den Rijn ook wel ‘portal’-functionaliteit genoemd wordt. Omdat een portal als zodanig ook een bepaald type applicatie behelst, waarbij personalisatie overigens een belangrijk aspect is, kan hierover dus mogelijk (spraak)verwarring ontstaan.

•

Elektronisch betalen In de gemeentelijke context heeft elektronisch betalen betrekking op de functionaliteit zoals deze tot voor kort door de BNG-internetkassa en inmiddels door Ogone wordt geleverd. Hoewel één en ander redelijk triviaal lijkt en de meeste leveranciers de betreffende functionaliteit weliswaar aanbieden, is er weldegelijk verschil in de wijze waarop. Immers, hoewel dergelijke ‘uitstapjes’ naar externe omgevingen binnen een websessie ogenschijnlijk synchroon overkomen, zijn ze ten principale asynchroon. Het is bijvoorbeeld heel wel mogelijk dat op enig moment de verbinding wegvalt, net op het moment dat de betaling als zodanig geaccordeerd wordt ‘teruggegeven’. Het is dan ook raadzaam om bij de beoordeling van de offertes en/of de daaropvolgende Proof of Concept (PoC), goed te letten op hoe de betreffende leveranciers omgaan met dergelijke zaken.

•

Business process management (BPM) Een broker (letterlijk: ‘makelaar’) ontvangt de elektronische berichten van het webintake systeem (E-formulieren) en bezorgt het in het juiste formaat (translatie en transformatie) op het juiste moment via de juiste route bij de juiste backoffice applicatie(s). Dergelijke berichtenoftewel ‘messaging’-functionaliteit kan zowel synchroon (direct) als asynchroon (‘message queueing’) zijn uitgevoerd, waarbij in het laatste geval het bericht wordt gebufferd zolang een backoffice applicatie, om wat voor reden dan ook, tijdelijk niet beschikbaar is. Zoals gezegd kunnen aldus bovendien aanvragen die meerdere backoffice applicaties betreffen als het ware worden ‘georkestreerd’, waarbij de broker een aanvraag in de juiste volgorde langs elk van de betreffende applicaties leidt. Dergelijke procesorkestratie wordt ook wel ‘business process management’ genoemd (BPM). BPM dient vooral niet verward te worden met workflow management (WFM), omdat BPM per definitie uitsluitend plaatsvindt tussen ‘machines’ (computers / applicaties) onderling, terwijl WFM ook een menselijke component kent (taakbakjes, werkvoorraden en dergelijke). BPM en WFM worden gezamenlijk ook wel BPA genoemd (‘business process automation’). Overigens hebben de meeste moderne brokers ook wel in meer of mindere mate de mogelijkheid om, door middel van taakbakjes en dergelijke, dit menselijke aspect vorm te geven.

17


•

Adapters Berichten moeten niet alleen in het juiste formaat maar ook op de juiste wijze aan de betreffende applicatie(s) worden aangeboden. Hiertoe dienen adapters: software die de informatieoverdracht tussen de broker en de verschillende front- en backoffice applicaties regelt. Een adapter realiseert een extern koppelvlak met een applicatie, waarbij gebruik gemaakt wordt van gestandaardiseerde (functionele en technische) protocollen. De integratiefunctionaliteit van een adapter kan op drie verschillende niveaus plaatsvinden: -

Integratie op dataniveau Indien een applicatie op dataniveau wordt geïntegreerd met de broker (bijvoorbeeld middels een ODBC- of JDBC-koppeling) kan de broker er weliswaar gegevens uithalen (lezen) maar is het niet raadzaam deze te wijzigen (schrijven) omdat de business logica van de applicatie dan wordt veronachtzaamd (risico op inconsistenties), waarmee dus sprake is van een soort ‘read-only’ integratie.

-

Integratie op presentatieniveau Voor integratie op presentatieniveau wordt ook wel de term ‘screenscraping’ gebezigd. Door middel van scripts kunnen applicaties worden benaderd om gegevens te lezen en/of schrijven. Hiertoe wordt een ‘virtuele’ gebruiker gecreëerd die de betreffende applicatie kan aanroepen middels zogenaamde ‘remote procedure calls’ (RPC’s). Gegevensinvoer vindt aldus plaats via de businesslogica van de betreffende applicatie. De beperkte flexibiliteit, foutgevoeligheid en onderhoudsintensiviteit van dergelijke adapters is echter reden om het gebruik ervan niet aan te bevelen. Aangezien integratie op presentatieniveau geen medewerking van de betreffende leverancier vereist, is dit vooralsnog echter de enige manier om via business logica gegevens in te voeren voor applicaties waarvan dergelijke interfaces (nog) niet worden vrijgegeven.

-

Integratie op applicatieniveau Omdat bij integratie op applicatieniveau gebruik wordt gemaakt van de betreffende business logica, geniet deze vorm van integratie over het algemeen de voorkeur. Dit biedt immers de mogelijkheid om mutaties aan te brengen op de gestructureerde gegevens van een applicatie zonder risico’s op inconsistenties. Dergelijke schrijftoegang op applicatieniveau vereist echter de medewerking van de betreffende leverancier.

18


Het nadeel van integratie op presentatie- of dataniveau is ook dat het niet te standaardiseren is. Dat betekent dat voor elke koppeling met behulp van ODBC/JDBC dan wel RPC’s een stuk maatwerk nodig is (onderhoudsintensief). Aangezien de beschikbaarheid van adapters op applicatieniveau vooralsnog te wensen over laat, met name voor de meest gebruikte backoffice applicaties (in het bijzonder van Centric en PinkRoccade), laat de beoogde efficiencywinst nog even op zich wachten. Efficiencywinst echter allesbehalve de beste (primaire) drijfveer om een dergelijke ‘front-, mid- en backoffice’-architectuur te realiseren. De geëigende benadering is veeleer gedreven door de wens om dienstverlening te verbeteren. Hierbij betaalt de investering in de benodigde infrastructuur (de onderliggende architectuur) zich aanvankelijk vooral terug in kwalitatief en kwantitatief betere (elektronische) dienstverlening. Hoewel er in het begin wel een zekere efficiencywinst gerealiseerd zal kunnen worden, vooral als (kwalitatief en kwantitatief) betere dienstverlening voor dezelfde kosten, volgen de daadwerkelijke kostenbesparingen echter pas op de wat langere termijn (wanneer de voornoemde adapters breder beschikbaar komen). Zonder dergelijke adapters is de volledig geautomatiseerde verwerking van een aanvraag in het desbetreffende backoffice systeem (zogeheten ‘straight through processing’) immers niet mogelijk. Indien men daadwerkelijk in een backoffice applicatie wil ‘schrijven’, dient hiertoe en allen tijde de desbetreffende business logica te worden gehanteerd, zulks om foute invoer te voorkomen. Deze volledig geautomatiseerde verwerking wordt ook wel aangeduid als ‘fase 3’ vanelektronische dienstverlening. Ten aanzien van elektronische dienstverlening hanteert M&I/Argitek doorgaans een model waarin een viertal verschillende fasen wordt onderscheiden:

Fase Fase 0 Fase 1 Fase 2 Fase 3 Fase 4

Publicatie Formulier (papier) PDF-formulier Webformulier Webformulier Webformulier

Intake Handmatig (papier) Handmatig (papier) Elektronisch Elektronisch Elektronisch

Verwerking Handmatig (papier) Handmatig (papier) Handmatig (papier) Elektronisch Elektronisch

Levering Handmatig (papier) Handmatig (papier) Handmatig (papier) Handmatig (papier) Elektronisch

Voor wat betreft dit fasemodel elektronische dienstverlening dient opgemerkt te worden dat niet alle producten zich ook daadwerkelijk lenen voor elektronische levering (fase 4). Ook wanneer dit voor een specifiek product wel zo is, bijvoorbeeld voor een elektronisch GBA-uittreksel, zullen er met de beoogde afnemers (voor een GBA-uittreksel zijn dit bijvoorbeeld scholen) echter afspraken gemaakt moeten worden om te zorgen dat de klant ermee terecht kan. De beschikbaarheid van die adapters op applicatieniveau laat vooralsnog te wensen over, met name voor de meest gebruikte gemeentelijke backoffice applicaties (van Centric en PinkRoccade). Dat neemt niet weg dat er de laatste tijd hard gewerkt wordt aan dergelijke ‘koppelvlakken’ (onder andere in de gelijknamige EGEM-werkgroep). Op de korte termijn zal men voor de meeste producten echter niet verder komen dan fase 2 van elektronische dienstverlening. Voor producten die verwerkt moeten worden in backoffice systemen van ‘kleinere’ leveranciers kan men doorgaans echter op meer bereidwilligheid rekenen ten aanzien van de realisatie van adapters op applicatieniveau. Overigens zijn dergelijke adapters dus zoals gezegd niet vereist voor producten waarbij slechts in het backoffice ‘gelezen’ hoeft te worden, net zo min als voor producten waar in het geheel geen specifieke backoffice applicatie bij betrokken is. Dit laatste betreft de zogeheten ‘backoffice’-loze producten (zie verderop), waarvan de administratieve afhandeling in bijvoorbeeld spreadsheets, (Word-)documenten en/of eenvoudige databases plaatsvindt.

19


Ten behoeve van het laboratoriumonderzoek van M&I/Argitek heeft Centric overigens een tweetal echt ‘open’ koppelvlakken (op basis van XML en webservices) beschikbaar gesteld. Het betreft adapters voor BWT4all (lichte bouwvergunning) en PIV4all (GBA-uittreksel), welke vooralsnog echter uitsluitend voor dit laboratoriumonderzoek zijn bedoeld. Hoewel zulks wellicht nog enigszins voorbarig is, kan hieruit voorzichtig de conclusie worden getrokken dat ook leveranciers die hieromtrent tot op heden zeer terughoudend waren (zoals Centric), dit mogelijk heroverwegen. •

Gegevensmagazijn Het gegevensmagazijn, ook wel aangeduid als ‘operational data store’ (ODS), dient voor opslag van gestructureerde (basis)gegevens uit het backoffice. Deze worden naar een centrale database in de DMZ gekopieerd, alwaar ze 24x7 ‘read-only’ beschikbaar zijn, ook wanneer het backoffice dit niet is (zogeheten ‘koude data’). Het gegevensmagazijn dient bijvoorbeeld voor authenticatie met DigiD- en het voorinvullen van formulieren. De synchronisatiefrequentie (bijv. één keer per dag) van het gegevensmagazijn bepaalt de actualiteit ervan. Een centraal gegevensmagazijn stelt echter ook eisen aan de administratieve organisatie rondom de betreffende (basis)gegevens, zoals met betrekking tot syntax en semantiek ervan. Dit vergt goede organisatorische en procedurele afspraken met de bronhouders van de desbetreffende gegevens. Eén en ander is dan ook nauw verwant met de actuele problematiek van de invoering van de zogeheten ‘basisregistraties’.

•

Zakenmagazijn In tegenstelling tot het gegevensmagazijn wordt in het zakenmagazijn ook geschreven. Het zakenmagazijn bevat dan ook zogenaamde ‘warme data’ oftewel procesgegevens van zowel lopende als afgehandelde zaken (wie, wat, wanneer en dergelijke). Een ingevuld formulier leidt tot een zaak: een samenhangende hoeveelheid werk met een welgedefinieerde aanleiding en resultaat waarvan kwaliteit en doorlooptijd bewaakt moet worden. Het is dan ook gebruikelijk het zakenmagazijn in te richten volgens het GFO-zaken, hoewel dit nog geen formele status heeft. Eén van de belangrijkste functies van het zakenmagazijn heeft betrekking op het ontsluiten van statusinformatie. Het zakenmagazijn neemt in de visie op elektronische dienstverlening een prominente plaats in; hierin komt immers de zaakgerichte werkwijze tot uitdrukking. Het zakenmagazijn vormt als zodanig namelijk de verbinding tussen de werkprocessen, de procesinformatie en de authentieke registraties, door middel van het opbouwen van zogeheten zaakdossiers waarin al deze aspecten tot uitdrukking komen. Daarnaast vormt het zakenmagazijn de omgeving waarin, analoog aan het ‘dikke’ midoffice concept, de ‘backoffice-loze’ producten worden geregistreerd en afgehandeld. Hierdoor ontstaat in het midoffice als het ware een soort ‘generieke applicatie’, waardoor de afhandeling van (eenvoudige) producten zoveel mogelijk ‘naar voren’ (frontoffice) kan worden gebracht. Eén en ander vereist echter wel een adequate inrichting van het midoffice, met name rondom het zakenmagazijn.

•

Workflow management (WFM) Ten behoeve van de voornoemde ‘generieke applicatie’ is mogelijk ook (een lichte vorm van) workflow management nodig. Dit zou dan vooral de werkoverdracht bij de behandeling van ‘zaken’ betreffen, waarbij het werk tussen de overdrachtsmomenten door de gemeente Alphen aan den Rijn als zogeheten ‘zaakbehandelaar’ wordt aangeduid. In de beoogde opzet (‘dik’ midoffice) wordt de omgeving waarbinnen die zaken geregistreerd en afgehandeld worden gevormd door de interface op het zakenmagazijn. Hierin kun bijvoorbeeld de status van een zaak (zoals een aanvraag) worden gewijzigd, welke desgewenst ook aan de aanvrager getoond kan worden. Zoals gezegd hebben de meeste moderne brokers ook wel in meer of mindere mate de mogelijkheid om, door middel van taakbakjes en dergelijke, dergelijke workflow vorm te geven.

20


4.3

Toelichting: basisregistraties

Vanuit de landelijke overheid worden een aantal zogeheten basisregistraties ingevoerd, waarbij van een drietal de verantwoordelijkheid bij de lokale overheid wordt neergelegd. De gedachte achter het concept ‘basisregistraties’ heeft betrekking op het feit dat de betreffende gegevens slechts eenmaal worden uitgevraagd en vervolgens door verschillende instanties worden gebruikt. Hoewel er op termijn mogelijk meer basisregistraties zullen worden ingevoerd, ligt de prioriteit voor gemeenten op dit moment bij natuurlijke personen, adressen en gebouwen. Bedoeling is dat de basisregistratie natuurlijke personen reeds in 2007 wordt ingevoerd, terwijl de overige basisregistraties (adressen en gebouwen) voor 2009 op de rol staan:

Op gemeentelijk niveau moeten ten aanzien van basisregistraties echter een aantal bestuurlijke afspraken worden gemaakt die corresponderen met de wettelijke regelingen op nationaal niveau. De vier hoofdthema’s van die afspraken zijn: •

Gebruikers mogen de gegevens zonder nader onderzoek voor hun werkproces gebruiken (zij mogen ervan uitgaan de gegevens correct zijn).

•

Gebruik van de registraties is verplicht voor alle afdelingen.

•

Gebruikers (afnemers) hebben een zogeheten ‘terugmeldplicht’.

•

Er is duidelijkheid over de verantwoordelijkheden.

Om een systeem van dergelijke basisregistraties te kunnen bewerkstelligen dient de gemeente Alphen aan den Rijn haar eigen interne gegevenshuishouding echter wel op orde te hebben. Immers, ook op het niveau van een individuele gemeente kan het concept ‘eenmalige uitvraag, meervoudig gebruik’ worden toegepast voor verschillende objecttypen. Hoewel de opzet vergelijkbaar is met het landelijke stelsel, spreken we in dit geval niet van basisregistraties maar van ‘bronbestanden’(een gemeentelijk bronbestand is dan ook conceptueel identiek aan een landelijke basisregistratie, zij het één niveau lager).

21


Dit concept heeft betrekking op het feit dat per objecttype (bijvoorbeeld ‘adressen’) één bestand aangewezen wordt dat daarvoor als ‘bron’ fungeert, ook voor alle andere gegevensverzamelingen binnen de gemeente waarin het betreffende objecttype voorkomt. Teneinde de integriteit van de afzonderlijke gegevensverzamelingen te waarborgen dient dit ‘bronbestand’ het enige te zijn waarin nieuwe gelijksoortige ‘objecten’ opgevoerd of reeds bestaande gemuteerd worden. Het is daarnaast mogelijk om, ook indien er niet één specifiek bronbestand in het backoffice is aan te wijzen voor een specifiek objecttype, hiervoor het gegevensmagazijn in het midoffice te benutten. Deze bevat dan zogeheten ‘koude’ kopieën uit de verschillende desbetreffende gegevensverzamelingen.

4.4

Toelichting: E-dossiers

Voor het werken met elektronische dossiers, hanteert M&I/Argitek doorgaans het onderstaande model. Hierin worden vier opeenvolgende fasen onderscheiden, waarbij steeds sprake is van een toenemende complexiteit (zowel technisch als organisatorisch).

•

Fase 0 In fase 0 gaat alles nog op papier en is er geen sprake van (elektronisch) document management.

•

Fase 1 (‘digitaal raadplegen’) In fase 1 word het ‘statische archief’ gedigitaliseerd. Dit heeft betrekking op elektronische documenten en dossiers die niet meer aan verandering onderhevig zijn ( ‘koud archief’). Hierbij kiest men ervoor om vanaf een bepaald moment alle dossiers die worden afgesloten te gaan digitaliseren en vanaf dan nog slechts elektronisch te bewaren. Wel kan men eventueel raadplegen middels het uitprinten van het/de desbetreffende document(en), waarbij als het ware een fysiek exemplaar (kopie) van een digitaal document of dossier wordt geproduceerd. Bij een digitaal ‘statisch archief’ is sprake van ‘read-only’ toegang; de documenten en dossiers zijn niet meer aan verandering onderhevig. Het reeds bestaande archief kan men gewoon intact laten, met terugwerkende kracht stelselmatig gaan digitaliseren, of elke keer als een papieren dossier wordt ‘aangeraakt’ dit digitaliseren (om te voorkomen dat documenten en/of dossiers worden gedigitaliseerd die vervolgens nooit meer worden geraadpleegd).

•

Fase 2 (‘digitaal muteren’) In fase 2 wordt overgegaan tot digitalisering van het ‘dynamische archief’. Dit is een flinke stap vooruit aangezien er niet slechts uit de dossiers gelezen wordt maar ook digitaal in gemuteerd. Dit heeft een behoorlijke weerslag op de organisatie, omdat van medewerkers een wezenlijk andere manier van werken wordt vereist. Hoewel het voor raadpleging vanzelfsprekend is toegestaan om documenten te printen, zal elke wijziging op die documenten ook in het digitale dossier doorgevoerd moeten worden. 22


Fase 3 (‘digitaal proces’) In fase 3 tenslotte wordt, in aanvulling op fase 2, bovendien het gehele proces gedigitaliseerd, waarbij dus ook de aansturing van het werkproces digitaal geschiedt (workflow management).

4.5

Toelichting: producten

1 2 3 4 5 6 7 •

Producten Aanvraag lichte bouwvergunning Bezwaar gemeentelijke belastingen Inzage taxatiegegevens Aanvraag bijzondere bijstand Algemene informatievraag Meldingen openbaar gebied Verhuisbericht doorgeven

Thema‘s Bouwen en Wonen / Ruimtebeheer Financiën / WOZ Financiën / WOZ Sociale Zaken Burgerzaken / klantcontact (SCA) Burgerzaken / klantcontact (SCA) Burgerzaken

Aanvraag lichte bouwvergunning (thema Ruimtebeheer) Deze functionaliteit wordt meegenomen in het PvE en kan in het kader van de aanbesteding mogelijk zelfs dienst doen als ‘Proof of Concept’ (PoC). Omdat Centric reeds te kennen heeft gegeven de adapter, welke zij in het kader van het laboratoriumonderzoek heeft ontwikkeld, in productie te gaan nemen, kan hiervoor wel fase 3 bereikt worden (zogeheten ‘elektronische verwerking’). Door middel van deze adapter kan bovendien automatisch een statusupdate naar het midoffice (zakenmagazijn) worden gestuurd. Voor de gemeente kan dit een flinke ontlasting van met name het callcenter betekenen. Onderzoek heeft uitgewezen dat een zeer groot deel van de vragen in het callcenter betrekking heeft op de status van (product)aanvragen. Aangezien de zogeheten ‘vormbeslissing’ van een bouwaanvraag op termijn mogelijkerwijs in het frontoffice zal worden gedaan, dient de betreffende status echter ook handmatig omgezet te kunnen worden.

•

Inzage taxatiegegevens en bezwaar gemeentelijke belastingen (thema Financiën) Deze functionaliteit wordt momenteel gerealiseerd middels het WOZ-portaal van GouwIT. Aangezien hiertoe pas recentelijk een investering is gedaan, zal -om ‘kapitaalvernietiging’ te vermijden- deze voorlopig gehandhaafd blijven. Dat neemt niet weg dat bepaalde aanvullende functionaliteiten, zoals DigiD, hieraan worden toegevoegd. Onderwijl kan met GouwIT in overleg worden getreden om te bewerkstelligen dat de betreffende functionaliteit binnen de geschetste informatiearchitectuur gebracht kan worden. Desgewenst kunnen hieromtrent reeds enkele randvoorwaarden worden meegenomen in het PvE.

•

Aanvraag bijzondere bijstand (thema Sociale Zaken) Voor deze functionaliteit is besloten nog geen interactief webformulier in te zetten, maar te volstaan met een PDF-formulier. Wel kan worden overwogen om, via het web, statusinformatie te ontsluiten over de voortgang. Hoewel Centric hiertoe nog geen ‘open’ koppelvlak op GWS4all heeft gedefinieerd, kan men altijd de status handmatig in het zakenmagazijn omzetten. Voor de klant heeft zulks niet alleen de schijn van geavanceerde elektronische dienstverlening, maar voor de gemeente kan dit zoals gezegd een flinke ontlasting van oa het callcenter betekenen.

23


Algemene informatievraag (thema Burgerzaken) Ten behoeve van de functionaliteit voor het beantwoorden van algemene informatievragen dient te worden opgemerkt dat, voorzover men hier van (geavanceerde) zoekfunctionaliteit en/of beslisbomen gebruik wil maken, zulks in het huidige PvE niet voldoende scherp is geformuleerd. In de planning zoals opgenomen in de presentatie voor het beleidsoverleg (zie bijlage 4.7) is bij de volgende fase een zogeheten kennisbank opgenomen. Een dergelijke kennisbank is bedoeld om zoveel mogelijk van de aanwezige relevante informatie binnen de gemeente Alphen aan den Rijn op een eenduidige manier te kunnen ontsluiten in het frontoffice, zodat de medewerkers aldaar hieruit kunnen putten bij het beantwoorden van informatievragen.

•

Meldingen openbaar gebied thema (thema Burgerzaken) Voor wat betreft de meldingen openbaar gebied geldt dat de desbetreffende functionaliteit volledig gerealiseerd zal worden op basis van de front-/midoffice infrastructuur zoals deze in het PvE wordt beschreven. Als zodanig is dit een voorbeeld van een zogeheten ‘backoffice-loos’ product. Zoals gezegd fungeert de front-/midoffice infrastructuur daarbij als een soort ‘generieke applicatie’ waarin relatief eenvoudige producten zoals de melding openbaar gebied kunnen worden geregistreerd en afgehandeld (zie paragraaf 3.2)..

•

Verhuisbericht doorgeven (thema Burgerzaken) Ook het doorgeven van een verhuisbericht vormt een onderdeel van de initiële uitrol voor wat betreft elektronische dienstverlening, zij het waarschijnlijk slecht tot fase 2. Hiervoor heeft Centric immers nog geen ‘open’ koppelvlak beschikbaar gesteld op PIV4all. Desalniettemin zijn er wel leveranciers van front-/midoffice producten die op dit gebied reeds een eigen oplossing hebben gerealiseerd.

4.6

Presentatie: kick-off

Apart bijgevoegd

4.7

Presentatie: beleidsoverleg

Apart bijgevoegd

4.8

Presentatie: kerngroep

Apart bijgevoegd

24

Gemeente Alphen aan den Rijn

Recommend Documents